Nothing Special   »   [go: up one dir, main page]

JP2009193567A - 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法 - Google Patents

送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法 Download PDF

Info

Publication number
JP2009193567A
JP2009193567A JP2008267080A JP2008267080A JP2009193567A JP 2009193567 A JP2009193567 A JP 2009193567A JP 2008267080 A JP2008267080 A JP 2008267080A JP 2008267080 A JP2008267080 A JP 2008267080A JP 2009193567 A JP2009193567 A JP 2009193567A
Authority
JP
Japan
Prior art keywords
content data
transmission
printing
condition
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2008267080A
Other languages
English (en)
Inventor
Masanobu Nishitani
正信 西谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Seiko Epson Corp
Original Assignee
Seiko Epson Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Seiko Epson Corp filed Critical Seiko Epson Corp
Priority to JP2008267080A priority Critical patent/JP2009193567A/ja
Priority to US12/291,772 priority patent/US20090122343A1/en
Publication of JP2009193567A publication Critical patent/JP2009193567A/ja
Withdrawn legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Facsimiles In General (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)

Abstract

【課題】送信端末から情報出力装置である印刷端末に出力条件である印刷条件を伝達するための技術を提供する。
【解決手段】コンテンツデータの送信に先立ち、パーソナルコンピュータ104及び印刷端末108は、SIPに従って、SIPサーバ106を介して、両者の間におけるセッションの確立を行う。そのセッションの確立を行う過程において、パーソナルコンピュータ104は、印刷端末108にSIPサーバ106を介して、印刷端末108においてコンテンツデータに基づき印刷を行う際の印刷条件を送信する。
【選択図】図8

Description

本発明は、コンテンツデータをネットワークを介して伝送するための技術に関するものである。なお、本明細書中において、「コンテンツ」とは、画像や音声などの情報を言い、「コンテンツデータ」とは、上記コンテンツを表すデータを言う。なお、上記コンテンツのうち、画像など、印刷可能なものを「印刷コンテンツ」と言う場合がある。
従来、企業が顧客に広告などを配信する場合、郵送やファクシミリなどが利用されていた。また、通信教育分野などにおいて、教材提供企業が受講者に教材などを配信する場合も、同様に、郵送やファクシミリなどが利用されていた。
郵送による場合、広告や教材などの印刷コンテンツ自体は、高品質で印刷されたものを提供できるものの、送付に多数の人手を要し、多くのコストがかかると共に、送付にも時間を要するという問題がある。
また、ファクシミリによる場合は、郵送に比較して、送付に人手や時間は要しないものの、通信費用は発生し、また、顧客先で受け取る印刷コンテンツ自体も高品質なものを期待できないという問題がある。
一方、近年では、インターネットの発達などによって、情報を無料に近い低コストで伝送することが可能となっている。また、高性能なプリンタや複合機などの開発によって、家庭内でも、比較的低コストで、高品質な印刷を行うことができるようになってきている。
そこで、パーソナルコンピュータやサーバなどを含む送信端末から、上記したインターネットなどのネットワークを介して、プリンタや複合機などを含む印刷端末に、印刷コンテンツのデータを、低コストで、かつ、高品質にて配信することができる、システムの開発が待たれている。
なお、ネットワークを利用した情報の伝送に関しては、例えば、下記の特許文献に記載のものが知られている。
特開2005−109701号公報 特開2003−178028号公報 特表2005−516320号公報
上記したシステムでは、送信端末から印刷端末に印刷コンテンツのデータを送信する場合に、送信端末から印刷端末に用紙サイズや印刷品質などの印刷条件を伝えないと、印刷端末では、デフォルトで設定されている印刷条件でしか、その印刷コンテンツを印刷できないことになる。そこで、そのような印刷条件を送信端末から印刷端末に如何にして伝えるかが課題となる。
なお、このような課題は、送信端末から印刷端末に印刷コンテンツのデータを送信する場合に限らず、送信端末からディスプレイ等に画像などのコンテンツのデータを送信する場合に、解像度などの表示条件を送信端末からディスプレイ等に如何にして伝えるか、或いは、送信端末からオーディオ装置等に音声などのコンテンツのデータを送信する場合に、ミュート状態などの音声出力条件を送信装置からオーディオ装置等に如何にして伝えるかなど、共通の課題である。
なお、以下において、印刷端末,ディスプレイ,オーディオ装置などを、総称して、情報出力装置と言う場合があり、印刷条件,表示条件,音声出力条件などを、総称して、情報出力装置において情報の出力を行う際の条件、すなわち、出力条件と言う場合がある。
従って、本発明の目的は、上記した従来技術の課題を解決し、送信端末から情報出力装置に出力条件を伝達するための技術を提供することにある。
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
[適用例1]
コンテンツデータを、ネットワークを介して情報出力装置へ伝送する送信端末であって、
前記コンテンツデータの送信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記情報出力装置との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき情報の出力を行う際の出力条件を送信する、送信端末。
このように、適用例1の送信端末では、情報出力装置にコンテンツデータを送信する場合に、その送信に先立ち、情報出力装置との間のセッションの確立を行う過程において、情報出力装置へ仲介サーバを介して、出力条件を伝達することができる。従って、情報出力装置では、送信されたコンテンツデータについて、送信端末から伝達された出力条件に従って情報の出力を行うことができるため、情報出力装置において、コンテンツデータに基づく情報出力結果として、送信側ユーザの希望に沿った情報出力結果を得ることができる。
[適用例2]
適用例1に記載の送信端末において、読取条件に基づいて画像を読み取り、得られた画像データを前記コンテンツデータとして取得する画像読取部をさらに備えると共に、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記読取条件を前記出力条件として送信する、送信端末。
このように、送信端末が、読取条件に基づいて画像を読み取り、得られた画像データをコンテンツデータとすると共に、セッションの確立を行う過程において、情報出力装置に仲介サーバを介して、上記読取条件を出力条件として送信することにより、情報出力装置では、送信端末からのコンテンツデータについて、送信された出力条件、すなわち、画像を読み取った際の読取条件に従って情報の出力を行うことができるため、送信側ユーザの希望に沿った情報出力結果を得ることができる。
[適用例3]
適用例1または適用例2に記載の送信端末において、前記シグナリングプロトコルは、SIPであって、
前記制御部は、前記情報出力装置に前記仲介サーバを介して、前記SIPにおけるINVITEリクエストを送信する際、前記INVITEリクエスト中に前記出力条件を含ませる、送信端末。
このように、シグナリングプロトコルがSIPである場合、INVITEリクエスト中に出力条件を含ませることにより、送信端末と情報出力装置との間のセッションの確立を行う過程において、送信端末から情報出力装置へ出力条件を確実に伝達することができる。
[適用例4]
適用例1ないし適用例3のうちの任意の1つに記載の送信端末において、前記制御部は、前記出力条件として、複数の条件を送信する、送信端末。
このように、送信端末が、出力条件として複数の条件を送信することにより、情報出力装置では、それら条件の中から、所望の条件を選択することができる。
[適用例5]
適用例4に記載の送信端末において、前記制御部は、前記セッションの確立後に、前記情報出力装置に対し、前記コンテンツデータとして、複数のデータを送信することを予定している場合、前記複数の条件は、前記複数のデータにそれぞれ対応する条件である、送信端末。
このように、適用例5の送信端末では、コンテンツデータとして複数のデータを送信する場合、各データ毎に対応した出力条件を設定して、情報出力装置へ伝達することができる。
[適用例6]
適用例1ないし適用例5のうちの任意の1つに記載の送信端末において、前記制御部は、前記セッションの確立後、データ転送用のプロトコルに従って、前記コンテンツデータとして、前記出力条件に対応したデータを送信する、送信端末。
このように、送信端末が、コンテンツデータとして、情報出力装置へ伝達した出力条件に対応したデータを、情報出力装置へ送信することにより、情報出力装置では、そのコンテンツデータに基づいて情報の出力を行うことにより、送信側ユーザの希望に沿った情報出力結果を得ることができる。
[適用例7]
ネットワークを介して送信端末から伝送されたコンテンツデータを受信して、前記コンテンツデータに基づき情報の出力を行う情報出力装置であって、
前記コンテンツデータの受信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記送信端末との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を受信した場合、前記出力条件に対する応答を、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
このように、適用例7の情報出力装置では、送信端末との間のセッションの確立を行う過程において、送信端末へ仲介サーバを介して、伝達された出力条件に対し、応答を返すことができる。
[適用例8]
適用例7に記載の情報出力装置において、前記制御部は、受信した前記出力条件での前記情報の出力が可能か否かを判断し、その判断結果を、前記応答として送信する、情報出力装置。
このように、情報出力装置が、受信した出力条件での情報の出力が可能か否かの判断結果を送信端末へ返すことにより、送信端末では、情報出力装置側において希望する出力条件を把握することができ、その出力条件に対応したコンテンツデータを情報出力装置へ送信することができる。
[適用例9]
適用例7または適用例8に記載の情報出力装置において、前記制御部は、前記セッションの確立を行う過程において、前記出力条件として、前記複数の条件を受信した場合、前記複数の条件の中から所望の条件を選択し、その選択結果を前記出力条件に対する応答として、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
このように、情報出力装置が、複数の条件の中から所望の条件を選択し、その選択結果を送信端末に返すことにより、送信端末では、情報出力装置側において希望する出力条件を把握することができ、その出力条件に対応したコンテンツデータを情報出力装置へ送信することができる。
[適用例10]
コンテンツデータを、ネットワークを介して伝送するコンテンツ伝送システムであって、
前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、
前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて情報の出力を行う情報出力装置と、
前記ネットワークに接続される仲介サーバと、
を備え、
前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置は、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行うと共に、
前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を送信する、コンテンツ伝送システム。
適用例10のコンテンツ伝送システムによれば、適用例1と同様の効果を奏することができる。
[適用例11]
コンテンツデータをネットワークを介して伝送するコンテンツ伝送システムにおいて、前記コンテンツデータに基づいて情報の出力を行う際の出力条件を伝送するための出力条件伝送方法であって、
前記コンテンツ伝送システムは、前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて前記情報の出力を行う情報出力装置と、前記ネットワークに接続される仲介サーバと、を備え、
前記出力条件伝送方法は、
(a)前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置が、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行う工程と、
(b)前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記出力条件を送信する工程と、
を備える出力条件伝送方法。
適用例11の出力条件伝送方法によれば、適用例1と同様の効果を奏することができる。
なお、本発明は、上記した送信端末や情報出力装置やコンテンツ伝送システムなどの装置発明の態様や出力条件伝送方法などの方法発明の態様に限ることなく、それら方法や装置を構築するためのコンピュータプログラムとしての態様や、そのようなコンピュータプログラムを記録した記録媒体としての態様など、種々の態様で実現することも可能である。
以下、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
A.第1の実施例:
A−1.実施例の構成:
A−2.実施例の動作:
A−3.実施例の効果:
B.第2の実施例:
B−1.実施例の構成:
B−2.実施例の動作:
B−3.実施例の効果:
C.第3の実施例:
C−1.実施例の構成:
C−2.実施例の動作:
C−3.実施例の効果:
D.第4の実施例:
D−1.実施例の構成:
D−2.実施例の動作:
D−3.実施例の効果:
E.変形例:
A.第1の実施例:
A−1.実施例の構成:
図1は本発明の第1の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
図1に示すとおり、本実施例のコンテンツ伝送システムは、パーソナルコンピュータ104と、SIP(Session Initiation Protocol)サーバ106と、情報出力装置である印刷端末108と、で構成される。このうち、パーソナルコンピュータ104は、印刷コンテンツ(広告や通信教材など)の配信を希望する送信側ユーザによって管理される。印刷端末108は、配信された印刷コンテンツを受け取る受信側ユーザによって管理される。SIPサーバ106は、例えば、ネットワークサービス提供業者などによって管理される。
パーソナルコンピュータ104、SIPサーバ106、及び印刷端末108は、インターネットを含む、いわゆるブロードバンドネットワーク110を介して接続されている。
本実施例では、広告や通信教材などの印刷コンテンツは、コンテンツデータとして、後ほど詳述するように、パーソナルコンピュータ104によって、印刷端末108にPUSH型で配信される。ここで、このような印刷のために用いられるコンテンツデータとしては、例えば、JPEGデータ、GIFデータ、PNGデータ、TIFFデータ、プレーンテキストデータ、HTMLデータ、PDFデータ、PostScript(登録商標)データなど、画像やドキュメントを表現することが可能な各種データを用いることができる。また、印刷端末で用いられるプリンタ等の機種が分かっている場合には、印刷データの形態で配信するようにしてもよい。また、ここで、「PUSH型」とは、端末側が情報をリクエストしなくても、サーバ側が一方的に情報を端末に送り出して配信する方法を言う。なお、コンテンツデータの配信、すなわち、装置間におけるコンテンツデータの伝送には、データ転送プロトコルの一種であるHTTP(Hypertext Transfer Protocol)を用いるようにしている。
また、本実施例では、上述したコンテンツデータの配信に先立って、シグナリングプロトコルの一種であるSIP(Session Initiation Protocol)を用いて、SIPサーバ106を介して、装置間、すなわち、パーソナルコンピュータ104と印刷端末108との間におけるセッションの確立を行うようにしている。さらに、本実施例では、このセッションの確立を行う過程において、パーソナルコンピュータ104から印刷端末108へ、SIPサーバ106を介して、コンテンツデータに基づき印刷を行う際の印刷条件を伝達するようにしている。ここで、「セッション」とは、端末などのノード間でメディアストリームを送受信する関係を言う。また、印刷条件としては、用紙サイズ(例えば、A4,B5,L判など)や、印刷色(カラー,モノクロなど)や、印刷品質(品質レベル1,品質レベル2など)などが挙げられる。
図2は図1におけるパーソナルコンピュータ104の主要構成を示すブロック図である。図2に示すように、パーソナルコンピュータ104は、プログラムを実行することにより種々の処理や制御を行うCPU10と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部12と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部13と、プログラムを格納したり、データや情報を格納したりするためのメモリ14と、取得したデータや情報などを表示するためのモニタ15と、を主として備えている。このうち、メモリ14は、データや情報として、後述するような、配信依頼情報16や、コンテンツデータ17や、印刷条件データベース18などを格納することが可能である。
図3は図1におけるSIPサーバ106の主要構成を示すブロック図である。図3に示すように、SIPサーバ106は、サーバコンピュータによって構成されており、プログラムを実行することにより種々の処理や制御を行うCPU20と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部22と、プログラムを格納したり、データや情報を格納したりするためのメモリ24と、を主として備えている。このうち、メモリ24は、情報として、後述するような、登録情報26などを格納することが可能である。なお、SIPサーバ106は、上記構成要素以外にも、キーボードやポインティングデバイスなどの入力部やモニタなどの表示部などを備えているが、図では省略されている。
図4は一般的なSIPサーバの種別を示す説明図である。一般に、SIPサーバは、機能に応じて、図4に示すような種別に分けることができる。
レジストラは、SIPクライアント(すなわち、SIPユーザエージェント)からの登録要求を受け付けて、SIPクライアントのSIPアドレス(すなわち、SIP URI(Uniform Resource Identifier))や位置情報(すなわち、IP(Internet Protocol)アドレスなど)を、ロケーションサーバに登録する。
ロケーションサーバは、SIPクライアントやサーバのSIPアドレスや位置情報などを格納するデータベースである。
プロキシサーバは、SIPクライアント間において、リクエストやレスポンスを中継するサーバであって、SIPクライアント間におけるセッションの確立などを仲介する。
リダイレクトサーバは、SIPクライアントからの問い合わせに対して、通信したい相手先の位置情報を通知する。
プレゼンスサーバは、SIPクライアントに関するプレゼンス情報を取得し、管理すると共に、それらのプレゼンス情報を他のSIPクライアントに提供する。
図5は図1における印刷端末108の主要構成を示すブロック図である。印刷端末108は、図1に示すとおり、パーソナルコンピュータ112と、そのパーソナルコンピュータ112にUSBケーブルなどで接続されたプリンタ114と、によって構成されている。このうち、パーソナルコンピュータ112は、図5に示すように、プログラムを実行することにより種々の処理や制御を行うCPU30と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部32と、プログラムを格納したり、データや情報を格納したりするためのメモリ34と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部40と、取得したデータや情報などを表示するためのモニタ42と、外部接続されたプリンタ114などにデータを出力するための出力インタフェース(I/F)部46と、を主として備えている。このうち、メモリ34は、データや情報として、コンテンツデータ36やコンテンツ情報38などを格納することが可能である。
なお、本実施例では、印刷端末108の構成として、パーソナルコンピュータ112とそのパーソナルコンピュータ112にUSBケーブルなどで直接接続されるプリンタ114と、で構成される形態を採用するようにしたが、印刷端末の構成としては、種々の形態を採ることができる。
例えば、プリンタ114に代えて、複合機を用いる形態であってもよい。または、パーソナルコンピュータ112と、そのパーソナルコンピュータ112にLANケーブルなどでLAN(ローカルエリアネットワーク)を介して接続されたネットワーク対応の複合機もしくはプリンタと、で構成される形態であってもよい。または、パーソナルコンピュータ112と、そのパーソナルコンピュータ112にLANケーブルなどでLANを介して接続されたネットワークアダプタと、そのネットワークアダプタにUSBケーブルなどで接続された複合機もしくはプリンタと、で構成される形態であってもよい。
さらには、IP(Internet Protocol)通信プリンティング対応の複合機もしくはプリンタのみで構成される形態であってもよい。IP通信プリンティング対応の複合機もしくはプリンタは、SIP URIなどグローバルなアドレスを直接扱うことができるため、ブロードバンドルータなどを介して、インターネットなどのブロードバンドネットワークに直接接続したとしても、それらネットワーク上の装置との間でデータをやりとりすることが可能だからである。なお、ここで、IP通信プリンティングとは、以下の条件を満たす印刷方式を言う。
・ネットワークを用いた印刷方式である。
・通信プロトコルとしてSIPなどの呼制御プロトコルを用いる。
・対応する端末間同士でコンテンツデータの送受信が可能である。
・パーソナルコンピュータを含む他の機器の仲介なしにコンテンツデータの直接印刷が可能である。
なお、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線LANや、ブルートゥースや、赤外線など、無線で接続されてもよい。
また、インターネットを含むネットワーク110では、グローバルIPアドレスが割り当てられるのに対し、LANなどのプライペートネットワークでは、プライペートIPアドレスが割り当てられることが多い。そのような場合、いわゆるNAT(Network Address Translation)越えの問題が存在するが、一般に知られているように、NAT越えの方法として、UPnP(Universal Plug and Play)の技術や、STUN(Simple Traversal of UDP through NAT)の技術や、TURN(Traversal Using Relay NAT)の技術や、ICE(Interactive Connectivity Establishment)の技術などを用いることによって、そのような問題は解決することができる。
なお、本実施例において、パーソナルコンピュータ104は、請求項における送信端末に、SIPサーバ106は、請求項における仲介サーバに、印刷端末108は、請求項における情報出力装置に、それぞれ相当し、また、パーソナルコンピュータ104のCPU10またはパーソナルコンピュータ112のCPU30は、請求項における制御部に、それぞれ相当する。
A−2.実施例の動作:
図1において、まず、パーソナルコンピュータ104や印刷端末108は、それぞれ、起動すると、SIPサーバ106にSIPクライアントとしてアクセスする。そして、パーソナルコンピュータ104、印刷端末108は、アクセスしたSIPサーバ106にそれぞれ登録要求を出し、自己のSIP URIやIPアドレスなどの情報を送信する(破線矢印126,128)。SIPサーバ106は、レジストラ,ロケーションサーバとして機能し、図3に示すように、そのCPU20は、通信部22を介して、登録要求を受け付け、送信された情報を登録情報26としてメモリ24に登録する。
この結果、SIPサーバ106は、パーソナルコンピュータ104及び印刷端末108の登録情報を有することになる。登録情報26は、各端末毎に、そのSIP URIと、そのIPアドレスと、が対応付けて、CPU20によって管理される。
ここで、SIP URIは、例えば、「sip:user@west.com」という形式の識別子で表される。先頭には、SIPであることを示す識別子(スキーム)を置き(「sip」)、次にユーザ識別子を置き(「user」)、「@」で区切って、ホスト名を置く(「west.com」)という形式になっている。なお、ユーザ識別子には、ユーザIDや電話番号などが用いられる。また、ホスト名には、完全修飾ドメイン名(FQDN:Fully Qualified Domain Name)やIPアドレスが用いられる。さらに、ホスト名の後には、ポート番号や、オプションパラメータなどを置くことも可能である。また、SIP URIに代えて、SIPのセキュアなURIとして、SIPS URIを用いることもできる。その場合、スキームとして、「sips」を置く。
こうして、SIPに関する事前準備が完了したら、SIPを利用した、装置間におけるセッションの確立を行うことが可能となる。
そこで、まず、送信側では、配信したい印刷コンテンツが用意されており、図2に示すパーソナルコンピュータ104のメモリ14に、コンテンツデータ17として格納されている。また、その印刷コンテンツを印刷端末側で印刷させる際の印刷条件も用意されており、メモリ14内の印刷条件データベース18において、管理されている。さらに、その印刷コンテンツを配信すべき各配信先のリストも用意されており、メモリ14に、配信依頼情報16として格納されている。
その後、パーソナルコンピュータ104のCPU10は、配信依頼情報16を読み出し、それに含まれる配信先リストを解析する。配信先リストには、配信先として、印刷端末108などのSIP URIが記載されている。そして、パーソナルコンピュータ104のCPU10は、その配信先リストに従って、例えば、まず、印刷端末108を、コンテンツデータの送信先として決定する。
本実施例では、上述したとおり、コンテンツデータの配信に先立ち、パーソナルコンピュータ104と印刷端末108との間のセッションの確立を行う過程において、パーソナルコンピュータ104から印刷端末108へ、SIPサーバ106を介して、印刷条件を伝達する。
そこで、まず、印刷条件の伝達処理について説明する前に、パーソナルコンピュータ104と印刷端末108との間のセッションの確立処理シーケンスについて、図6を用いて説明する。
図6は図1におけるパーソナルコンピュータ104と印刷端末108の間のセッション確立処理のシーケンスを示す説明図である。図6において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。
パーソナルコンピュータ104は、自己のIPアドレスを印刷端末108に伝えるために、印刷端末108に向かって送信するINVITEリクエストのボディの中に、パーソナルコンピュータ104のIPアドレスを含ませる。一方、印刷端末108も、自己のIPアドレスをパーソナルコンピュータ104に伝えるために、パーソナルコンピュータ104に向かって送信する200 OKレスポンスのボディの中に、印刷端末108のIPアドレスを含ませる。
こうして、パーソナルコンピュータ104から送信したACKリクエストが、印刷端末108に到達したら、パーソナルコンピュータ104と印刷端末108との間のセッションは確立されたことになる。
その後、パーソナルコンピュータ104は、200 OKレスポンスより取得した印刷端末108のIPアドレスに基づいて、印刷端末108に、SIPサーバ106を介することなく、直接アクセスして、図1の白抜き矢印122で示すように、HTTPに従ってコンテンツデータをPUSH型で配信する。
印刷端末108は、配信されたコンテンツデータの受信が完了したら、再び、SIPに従って、BYEリクエストをSIPサーバ106を介してパーソナルコンピュータ104に送信する。パーソナルコンピュータ104は、BYEリクエストを受信すると、200 OKレスポンスを、SIPサーバ106を介して印刷端末108に返す。これにより、パーソナルコンピュータ104と印刷端末108との間のセッションが解消される。
以上が、セッション確立処理のシーケンスである。このようなセッション確立を行う過程において、本実施例では、パーソナルコンピュータ104から印刷端末108へINVITEリクエストを送信する際に、そのボディの中に、伝達したい印刷条件を含ませて、送信するようにしている。
SIPでは、装置間におけるセッションの確立を行う際、メディア・セッションの内容を記述するのに、一般に、SDP(Session Description Protocol)を用いている。本実施例では、この既存のSDPに対し、送信すべき印刷条件について、図7に示すような対応付けをなすようにしている。
図7は既存のSDPと印刷条件との対応関係を示す説明図である。図7において、「印刷条件タイプ」は、SDPの規定で「ペイロードタイプ」と呼ばれるものに相当する。なお、印刷色については、既存のSDPから独自の拡張を行っており、印刷条件としては、カラー印刷またはモノクロ印刷の何れか一方を指定するものとする。
また、以下の説明は、SDPオファ/アンサモデルに基づいて行うものとする。ここで、オファ/アンサモデルに簡単に説明する。まず、セッションを確立する2つのSIP UA(ユーザエージェント)をそれぞれ、オファ側(Offer:提案者),アンサ側(Answer:回答者)とする。そして、オファ側から2者間で確立するセッションの提案となるセッション/メディア情報を含むSDP記述文書(オファ)を送信し、この提案を受けてアンサ側が回答となるセッション/メディア情報を含むSDP記述文書(アンサ)を返信する。この一連のメッセージ交換によって、セッションの確立を行うフレームワークが「オファ/アンサモデル」である。従って、本実施例では、オファ側とは、送信側、すなわち、パーソナルコンピュータ104を指し、アンサ側とは、受信側、すなわち、印刷端末108を指す。
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、配信したい印刷コンテンツとして、1つの印刷コンテンツCが用意されており、その印刷コンテンツCを印刷端末側で印刷させる際の印刷条件として、以下の2つの印刷条件を指定することが可能となっているものとする。なお、印刷条件タイプは、図7に示した内容と対応している。
a.印刷条件タイプ0:A4,カラー,品質レベル1
b.印刷条件タイプ3:B5,モノクロ,品質レベル1
また、本実施例では、上記印刷コンテンツCとして、印刷条件毎に、その印刷条件に応じたコンテンツデータがそれぞれ用意されているものとする。
a.印刷条件タイプ0:A4,カラー,品質レベル1
→コンテンツデータ:image_a4_color.jpg
b.印刷条件タイプ3:B5,モノクロ,品質レベル1
→コンテンツデータ:image_b5_gray.jpg
但し、本実施例では、オファ側(送信側)からアンサ側(受信側)へは、1つの印刷コンテンツについて、1つの印刷条件しか伝達できないものとする。従って、用意した印刷コンテンツCについては、上記した指定可能な2つの印刷条件のうち、1つの印刷条件しか印刷端末108へ送信することができない。そこで、本実施例では、上記2つの印刷条件のうち、デフォルトの印刷条件として、aの「印刷条件タイプ0:A4,カラー,品質レベル1」が設定されているものとし、この印刷条件をまず印刷端末108へ伝達するものとする。
図8は図1のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。図8において、左側は、オファ側、すなわち、パーソナルコンピュータ104での処理を示し、右側は、アンサ側、すなわち、印刷端末108での処理を示している。
オファ側(送信側)では、まず、印刷コンテンツCについて、伝達したい印刷条件があるか否かを判断し(ステップS102)、この場合、伝達したい印刷条件があるので、ステップS104に処理が進む。そして、オファ側(送信側)では、伝達したい印刷条件として、デフォルトの「印刷条件タイプ0:A4,カラー,品質レベル1」を、SDPによって、INVITEリクエストのボディに記述する(ステップS104)。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
ここで、「m=」行(1行目)の最後尾に記載されている数字の部分が、SDPにおけるペイロードタイプを指定する部分であり、本実施例では、印刷条件タイプを指定する部分となっている。従って、この場合、数字は「0」であり、「印刷条件タイプ0」であることを表している。また、2〜3行目には、この「0」についての設定内容が記載されている。
次に、オファ側(送信側)では、こうして得られたINVITEリクエストを、アンサ側(受信側)に対して送信する(ステップS106)。この後、オファ側(送信側)は、アンサ側(受信側)からのレスポンスの受信待ちの状態となる(ステップS108)。
一方、オファ側(送信側)からのリクエストの受信待ちの状態にあった(ステップS116)アンサ側(受信側)では、オファ側(送信側)から送信されてきたINVITEリクエストを受信すると、そのボディ内のSDPによる記述内容を解析し、記述されている印刷条件について自身が対応可能(すなわち、印刷可能)であるかどうかを判断する(ステップS118)。具体的には、まず、「m=」行の最後尾に記載されている数字を評価する。今、その数字として、「0」が指定されているため、アンサ側(受信側)は、オファ側(送信側)から伝達された印刷条件は、「印刷条件タイプ0:A4,品質レベル1」であると認識する。さらに、2行下に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
そこで、判断の結果、その印刷条件について、アンサ側(受信側)で対応可能な場合は、その印刷条件を保持する(ステップS120)。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、その印刷条件をメモリ34内にコンテンツ情報38の一部として保存する。
さらに、アンサ側(受信側)では、その印刷条件を、SDPによって、200 OKレスポンスのボディに記述する(ステップS121)。すなわち、オファ側(送信側)から伝達されたSDPによる記述内容を、200 OKレスポンスのボディにコピーする。このときのSDPによる記述内容は、オファ側(送信側)からのINVITEリクエストにおける記述内容と同じで、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
次に、アンサ側(受信側)では、こうして得られた200 OKレスポンスを、オファ側(送信側)に返信する(ステップS122)。この後、アンサ側(受信側)では、コンテンツデータの受信待ちの状態(受信待機)となる(ステップS124)。
反対に、ステップS118の判断の結果、上記印刷条件について、アンサ側(受信側)で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する(ステップS130)。
次に、アンサ側(受信側)では、生成したエラーレスポンスを、オファ側(送信側)に返信する(ステップS132)。この後、アンサ側(受信側)では、SIPによる通信を終了する(ステップS134)。
一方、アンサ側(受信側)からのレスポンスの受信待ちとなっていたオファ側(送信側)では、アンサ側(受信側)からのレスポンスが返信されてくると、そのレスポンスが、200 OKレスポンスであるかどうかの判断をする(ステップS110)。
判断の結果、200 OKレスポンスである場合は、コンテンツデータの送信を開始する(ステップS112)。具体的には、前述したとおり、印刷コンテンツCとして、印刷条件「印刷条件タイプ0:A4,カラー,品質レベル1」に対応して用意されているコンテンツデータは、「image_a4_color.jpg」であるので、このコンテンツデータがアンサ側(受信側)に送信される。
これに対し、コンテンツデータの受信待ちの状態であったアンサ側(受信側)は、送信されてきたコンテンツデータの受信を開始する(ステップS126)。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108では、パーソナルコンピュータ112のCPU30が、通信部32を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ34にそのコンテンツデータ36を保存する。
受信が完了した後(ステップS128)、アンサ側(受信側)では、オファ側(送信側)からの次の印刷コンテンツの受信待ちの状態(オファ側からのリクエスト受信待ちの状態)となる(ステップS116)。同時に、ステップS122において保持していた印刷条件、すなわち、「印刷条件タイプ0:A4,カラー,品質レベル1」に従って、コンテンツデータに基づく印刷を開始する。具体的には、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、メモリ34からコンテンツデータ36を読み出すと共に、コンテンツ情報38に含まれる印刷条件(すなわち、オファ側(送信側)から伝達された印刷条件)を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ114において印刷実行可能なデータ形式に変換する。CPU30は、印刷命令と共に、変換後のコンテンツデータをプリンタ114に送信すると、プリンタ114は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
こうして、アンサ側(受信側)である印刷端末108では、配信されたコンテンツデータについて、オファ側(送信側)から伝達された印刷条件に従った印刷結果を得ることができる。
一方、オファ側(送信側)において、上記判断の結果、200 OKレスポンスでない場合、すなわち、アンサ側(受信側)から返信されてきたレスポンスがエラーレスポンスである場合には、オファ側(送信側)では、デフォルトの印刷条件である「印刷条件タイプ0:A4,カラー,品質レベル1」以外に、伝達したい印刷条件として、指定可能な印刷条件があるかどうかを判断する(ステップS102)。
前述したとおり、指定可能な印刷条件として、デフォルトの印刷条件である、aの「印刷条件タイプ0:A4,カラー,品質レベル1」以外に、bの「印刷条件タイプ3:B5,モノクロ,品質レベル1」があるため、オファ側(送信側)では、再度、伝達したい印刷条件として、「印刷条件タイプ3:B5,モノクロ,品質レベル1」を、SDPによって、INVITEリクエストのボディに記述して(ステップS104)、そのINVITEリクエストを、アンサ側(受信側)に送信する(ステップS106)。
このときのSDPによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=fmtp:gray
------------------------
この後の処理については、上記したステップS108以降の処理と同じになる。
なお、ステップS102における判断の結果、例えば、デフォルトの印刷条件である「印刷条件タイプ0:A4,カラー,品質レベル1」以外に、指定可能な印刷条件が無かった場合や、あるいは、再度伝達した印刷条件「印刷条件タイプ3:B5,モノクロ,品質レベル1」でもってしても、アンサ側(受信側)において対応が不可能な場合は、SIPによる通信を終了する(ステップS114)。
A−3.実施例の効果:
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ104と印刷端末108との間のセッションの確立を行う過程において、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、SIPサーバ106を介して、印刷条件を伝達することができる。従って、アンサ側(受信側)である印刷端末108では、配信されたコンテンツデータについて、オファ側(送信側)から伝達された印刷条件に従って印刷を行うことができるため、アンサ側(受信側)において、送信側ユーザの希望に沿った印刷結果を出力させることができる。
B.第2の実施例:
上記した第1の実施例においては、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、印刷条件を伝達する際に、1つの印刷コンテンツについては、1つの印刷条件しか伝達できないものとしていた。これに対し、本実施例では、オファ側(送信側)からアンサ側(受信側)へ、1つの印刷コンテンツについて、複数の印刷条件を伝達することを可能とし、アンサ側(受信側)では、それら複数の印刷条件の中から対応可能な印刷条件をオファ側(送信側)へ返信するものである。
B−1.実施例の構成:
本実施例において、コンテンツ伝送システムの構成自体は、図1に示した第1の実施例の場合と同じであり、また、システムの構成要素である各装置の構成自体も、図2〜図5に示した第1の実施例の場合と同じであるので、それらについての説明は省略する。
B−2.実施例の動作:
上記したとおり、本実施例が、第1の実施例と異なるのは印刷条件の伝達処理であり、その他の動作内容は第1の実施例と同様であるため、以下の説明では、異なる点を中心に説明することとする。
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、配信したい印刷コンテンツとして、1つの印刷コンテンツCが用意されており、その印刷コンテンツCを印刷端末側で印刷させる際の印刷条件として、以下の3つの印刷条件を指定することが可能となっているものとする。なお、印刷条件タイプは、図7に示した内容と対応している。
a.印刷条件タイプ0:A4,カラー,品質レベル1
b.印刷条件タイプ3:B5,モノクロ,品質レベル1
c.印刷条件タイプ7:L判,カラー,品質レベル2
また、本実施例では、上記印刷コンテンツCとして、印刷条件毎に、その印刷条件に応じたコンテンツデータがそれぞれ用意されているものとする。
a.印刷条件タイプ0:A4,カラー,品質レベル1
→コンテンツデータ:image_a4_color.jpg
b.印刷条件タイプ3:B5,モノクロ,品質レベル1
→コンテンツデータ:image_b5_gray.jpg
c.印刷条件タイプ7:L判,カラー,品質レベル2
→コンテンツデータ:image_l_color.jpg
なお、本実施例では、上記したとおり、オファ側(送信側)からアンサ側(受信側)へは、1つの印刷コンテンツについて、複数の印刷条件を伝達することが可能となっている。従って、本実施例では、用意した印刷コンテンツCについては、上記した指定可能な3つの印刷条件の全てを印刷端末108へ伝達するものとする。
図9は本実施例のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。図9においても、図8の場合と同様に、左側は、オファ側、すなわち、パーソナルコンピュータ104での処理を示し、右側は、アンサ側、すなわち、印刷端末108での処理を示している。
オファ側(送信側)では、まず、印刷コンテンツCについて、伝達したい印刷条件として、上記した指定可能な3つの印刷条件の全てを取得し(ステップS202)、それら印刷条件を、SDPによって、INVITEリクエストのボディに記述する(ステップS204)。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 3 7
2 : a=rtpmap:0 PCMU/8000
3 : a=fmtp:color
4 : a=rtpmap:3 GSM/8000
5 : a=fmtp:gray
6 : a=rtpmap:7 LPC/8000
7 : a=fmtp:color
-----------------------------------------
ここで、「m=」行(1行目)の最後尾に記載されている数字の部分は、上述したとおり、印刷条件タイプを指定する部分となっており、この場合、数字は「0」,「3」,「7」であって、「印刷条件タイプ0」「印刷条件タイプ3」,「印刷条件タイプ7」であることを表している。「m=」行に続く、「a=」行(2〜7行目)には、各数字に対応する設定内容が記載されている。すなわち、2〜3行目には、この「0」についての設定内容が、4〜5行目には、この「3」についての設定内容が、6〜7行目には、この「7」についての設定内容が、それぞれ記載されている。
次に、オファ側(送信側)では、こうして得られたINVITEリクエストを、アンサ側(受信側)に対して送信する(ステップS206)。この後、オファ側(送信側)は、アンサ側(受信側)からのレスポンスの受信待ちの状態となる(ステップS208)。
一方、オファ側(送信側)からのリクエストの受信待ちの状態にあった(ステップS218)アンサ側(受信側)では、オファ側(送信側)から送信されてきたINVITEリクエストを受信すると、そのボディ内のSDPによる記述内容を解析し、記述されている印刷条件について自身が対応可能(すなわち、印刷可能)であるかどうかを判断する(ステップS220)。具体的には、ボディ内のSDPによる記述内容のうち、まず、前述した行番号の1行目に当たる「m=」行について解析する。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 3 7
-----------------------------------------
SDPの規定では、この「m=」行の最後尾に記載されている数字の部分(上記の例では「0」,「3」,「7」)は優先順位となっており、アンサ側(受信側)では、この順番で評価を行う。
そこで、アンサ側(受信側)では、まず、1番目の数字を評価する。今、1番目の数字として「0」が指定されているため、アンサ側(受信側)では、印刷条件は「印刷条件タイプ0:A4,品質レベル1」であると認識する。さらに、この「0」についての設定内容は、前述したとおり行番号の2〜3行目に記載されており、3行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
そして、アンサ側(受信側)では、この1番目の印刷条件、すなわち、「印刷条件タイプ0:A4,カラー,品質レベル1」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その1番目の印刷条件を保持する(ステップS222)。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、その1番目の印刷条件をメモリ34内にコンテンツ情報38の一部として保存する。
さらに、アンサ側(受信側)では、その1番目の印刷条件を、SDPによって、200 OKレスポンスのボディに記述する(ステップS223)。このときのSDPによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
次に、アンサ側(受信側)では、こうして得られた200 OKレスポンスを、オファ側(送信側)に返信する(ステップS224)。この後、アンサ側(受信側)では、コンテンツデータの受信待ちの状態(受信待機)となる(ステップS226)。なお、このように、アンサ側(受信側)では、複数の印刷条件をオファ側(送信側)に返信することはない。
通常、VoIP(Voice over Internet Protocol)などに利用されるソフトフォンや機器などの場合、「m=」行は、1つのメディアについて1つしか存在しない。例えば、以下の記述は、音声と映像の送受信を行うための記述であるが、このように異なるメディア(音声と映像)を同時に送受信するためには、各メディアについて「m=」行をそれぞれ記述し、各「m=」行の下に、それぞれ、そのメディアに関する属性を記述することになる。
-----------------
m=audio ・・・
a=rtpmap・・・
a=・・・
m=video・・・
a=rtpmap・・・
a=・・・
-----------------
一方、例えば、以下のような記述(音声の送受信のために2つのセッションを確立する)は、許されていないことが多い。この場合、音声通話が正しく行われなくなるからである。
-----------------
m=audio ・・・
a=rtpmap・・・
a=・・・
m=audio・・・
a=rtpmap・・・
a=・・・
-----------------
そこで、本実施例では、印刷条件を「m=audio・・・」と記載し、見かけ上は音声メディアとして、1つだけ指定可能なものとして扱うこととする。
さて、上記判断の結果、1番目の印刷条件、すなわち、「印刷条件タイプ0:A4,カラー,品質レベル1」について、アンサ側(受信側)で対応が不可能な場合は、次に、2番目の数字を評価する。今、2番目の数字として「3」が指定されているため、アンサ側(受信側)では、印刷条件は「印刷条件タイプ3:B5,品質レベル1」であると認識する。さらに、この「3」についての設定内容は、前述したとおり行番号の4〜5行目に記載されており、5行目に記載された「a=fmtp:gray」から、モノクロでの印刷であると認識する。
そして、アンサ側(受信側)では、この2番目の印刷条件、すなわち、「印刷条件タイプ3:B5,モノクロ,品質レベル1」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その2番目の印刷条件を保持する。
さらに、アンサ側(受信側)では、その2番目の印刷条件を、SDPによって、200 OKレスポンスのボディに記述して、その200 OKレスポンスを、オファ側(送信側)に返信する。
このときのSDPによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=fmtp:gray
------------------------
また、上記判断の結果、2番目の印刷条件について、アンサ側(受信側)で対応が不可能な場合は、続いて、3番目の数字を評価する。今、3番目の数字として「7」が指定されているため、アンサ側(受信側)では、印刷条件は「印刷条件タイプ7:L判,品質レベル2」であると認識する。さらに、この「7」についての設定内容は、前述したとおり行番号の6〜7行目に記載されており、7行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
そして、アンサ側(受信側)では、この3番目の印刷条件、すなわち、「印刷条件タイプ7:L判,カラー,品質レベル2」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その3番目の印刷条件を保持する。
さらに、アンサ側(受信側)では、その3番目の印刷条件を、SDPによって、200 OKレスポンスのボディに記述して、その200 OKレスポンスを、オファ側(送信側)に返信する。
このときのSDPによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 7
a=rtpmap:7 LPC/8000
a=fmtp:color
------------------------
さらに、上記判断の結果、3番目の印刷条件についても、アンサ側(受信側)で対応が不可能な場合、すなわち、オファ側(送信側)から伝達された全ての印刷条件について、アンサ側(受信側)で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する(ステップS232)。
次に、アンサ側(受信側)では、生成したエラーレスポンスを、オファ側(送信側)に返信する(ステップS234)。この後、アンサ側(受信側)では、SIPによる通信を終了する(ステップS236)。
一方、アンサ側(受信側)からのレスポンスの受信待ちとなっていたオファ側(送信側)では、アンサ側(受信側)からのレスポンスが返信されてくると、そのレスポンスが、200 OKレスポンスであるかどうかの判断をする(ステップS210)。
判断の結果、200 OKレスポンスである場合は、そのボディ内のSDPによる記述内容を解析し(ステップS212)、その記述内容に基づく印刷条件に対応したコンテンツデータの送信を開始する(ステップS214)。例えば、200 OKレスポンスのボディに、アンサ側(受信側)で対応可能な印刷条件として、上記した2番目の印刷条件、すなわち、「印刷条件タイプ3:B5,モノクロ,品質レベル1」が記述されているものとすると、印刷コンテンツCとして、その印刷条件「印刷条件タイプ3:B5,モノクロ,品質レベル1」に対応して用意されているコンテンツデータは、上述したとおり「image_b5_gray.jpg」であるので、このコンテンツデータがアンサ側(受信側)に送信される。
これに対し、コンテンツデータの受信待ちの状態であったアンサ側(受信側)は、送信されてきたコンテンツデータの受信を開始する(ステップS228)。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108では、パーソナルコンピュータ112のCPU30が、通信部32を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ34にそのコンテンツデータ36を保存する。
受信が完了した後(ステップS230)、アンサ側(受信側)では、オファ側(送信側)からの次の印刷コンテンツの受信待ちの状態(オファ側からのリクエスト受信待ちの状態)となる(ステップS218)。同時に、ステップS222において保持していた印刷条件、すなわち、「印刷条件タイプ3:B5,モノクロ,品質レベル1」に従って、コンテンツデータに基づく印刷を開始する。具体的には、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、メモリ34からコンテンツデータ36を読み出すと共に、コンテンツ情報38に含まれる印刷条件(すなわち、オファ側(送信側)から伝達された印刷条件)を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ114において印刷実行可能なデータ形式に変換する。CPU30は、印刷命令と共に、変換後のコンテンツデータをプリンタ114に送信すると、プリンタ114は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
こうして、アンサ側(受信側)である印刷端末108では、オファ側(送信側)から伝達された複数の印刷条件の中から、アンサ側(受信側)で対応可能な印刷条件を選択し、配信されたコンテンツデータについて、その選択した印刷条件に従った印刷結果を得ることができる。
一方、オファ側(送信側)において、上記判断の結果、200 OKレスポンスでない場合、すなわち、アンサ側(受信側)から返信されてきたレスポンスがエラーレスポンスである場合には、アンサ側(受信側)で何れの印刷条件も対応が不可能であったので、SIPによる通信を終了する(ステップS216)。
B−3.実施例の効果:
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ104と印刷端末108との間のセッションの確立を行う過程において、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、SIPサーバ106を介して、複数の印刷条件を伝達することができる。また、アンサ側(受信側)では、その複数の印刷条件の中から、自身で対応可能な印刷条件を選択して、オファ側(送信側)に回答し、オファ側(送信側)では、その回答された印刷条件に対応したコンテンツデータをアンサ側(受信側)へ送信することができる。従って、アンサ側(受信側)である印刷端末108では、複数の印刷条件の中から選択した印刷条件に従って、コンテンツデータに基づき印刷を行うことができるため、アンサ側(受信側)において、送信側ユーザの希望だけでなく、受信側ユーザの希望にも沿った印刷結果を出力させることができる。
C.第3の実施例:
上記した第1及び第2の実施例においては、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、1つの印刷コンテンツしか同時に送信できないものとしていた。これに対し、本実施例では、オファ側(送信側)からアンサ側(受信側)へ、複数の印刷コンテンツを同時に送信することを可能とするものである。なお、ここで、「複数の印刷コンテンツを同時に送信する」とは、確立された同じセッション内において、複数の印刷コンテンツのデータを順次送信するという意味である。
C−1.実施例の構成:
本実施例において、コンテンツ伝送システムの構成自体は、図1に示した第1の実施例の場合と同じであり、また、システムの構成要素である各装置の構成自体も、図2〜図5に示した第1の実施例の場合と同じであるので、それらについての説明は省略する。
C−2.実施例の動作:
本実施例が、第1の実施例と異なるのは、実質的には印刷条件の伝達処理であり、その他の動作内容は第1の実施例と同様であるため、以下の説明では、異なる点を中心に説明することとする。
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、以下に示すとおり、配信したい印刷コンテンツとして、3つの印刷コンテンツC1〜C3が用意されており、それら印刷コンテンツC1〜C3について、印刷端末側で印刷させる際の印刷条件がそれぞれ対応して用意されているものとする。なお、印刷条件タイプは、図7に示した内容と対応している。
a.印刷コンテンツC1
→コンテンツデータ:image1.jpg
→印刷条件タイプ0:A4,カラー,品質レベル1
b.印刷コンテンツC2
→コンテンツデータ:image2.jpg
→印刷条件タイプ3:B5,モノクロ,品質レベル1
c.印刷コンテンツC3
→コンテンツデータ:image3.jpg
→印刷条件タイプ7:L判,カラー,品質レベル2
なお、本実施例では、上記したとおり、オファ側(送信側)からアンサ側(受信側)へは、複数の印刷コンテンツを同時に送信することが可能となっている。従って、本実施例では、オファ側(送信側)で用意した3つの印刷コンテンツC1〜C3中から、アンサ側(受信側)で対応可能な複数の印刷コンテンツをアンサ側(受信側)に同時に送信するものとする。
図10は本実施例のコンテンツ伝送システムにおける印刷条件伝達処理のうち、オファ側の処理の流れを示すフローチャートであり、図11は同じく印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。すなわち、図10はパーソナルコンピュータ104での処理を示し、図11は印刷端末108での処理を示している。
オファ側(送信側)では、まず、配信したい3つの印刷コンテンツC1〜C3について、それぞれ、そのファイル名と、対応する印刷条件と、を取得し(ステップS302)、それらファイル名及び印刷条件を、SDPによって、INVITEリクエストのボディに記述する(ステップS304)。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 3 7
2 : a=rtpmap:0 PCMU/8000
3 : a=fmtp:color
4 : a=file:image1.jpg
5 : a=rtpmap:3 GSM/8000
6 : a=fmtp:gray
7 : a=file:image2.jpg
8 : a=rtpmap:7 LPC/8000
9 : a=fmtp:color
10 : a=file:image3.jpg
-----------------------------------------
ここで、「m=」行(第1行)の最後尾に記載されている数字の部分は、上述したとおり、印刷条件タイプを指定する部分となっており、この場合、数字は「0」,「3」,「7」であって、「印刷条件タイプ0」「印刷条件タイプ3」,「印刷条件タイプ7」であることを表している。「m=」行に続く、「a=」行(2〜10行目)には、各数字に対応する設定内容が記載されている。すなわち、2〜4行目には、この「0」についての設定内容が、5〜7行目には、この「3」についての設定内容が、8〜10行目には、この「7」についての設定内容が、それぞれ記載されている。
第2の実施例の場合に比較して、これら記載内容のうち、4,7,10行目に、配信したい印刷コンテンツのファイル名が追加されている点で異なる。これら4,7,10行目の記述は、通常のSDPの規定にはない、独自の拡張となる。
前述したように、通常のSDPの規定では、「m=」行の最後尾の数字(ペイロードタイプの指定)部分が優先順位となっている。上記した第2の実施例では、アンサー側(受信側)において、この順番で評価を行い、対応可能な印刷条件(メディア設定)があった時点で200 OKレスポンスをオファ側(送信側)に返信するようにしていた。従って、アンサ側(受信側)では、複数の印刷条件(メディア設定)を返信することはなかったい。そのため、第2の実施例では、オファ側(送信側)からアンサ側(受信側)へ一度に送信可能な印刷コンテンツは1つのみということになっていた。
これに対し、本実施例では、SDPの規定を独自に拡張することで、オファ側(送信側)からアンサ側(受信側)へ、複数の印刷コンテンツの同時送信に対応するようにしている。具体的には、「m=」行の最後尾の数字部分は、優先順位として扱うのではなく、送信される印刷コンテンツの種別を示すものとする。
従って、各数字に「0」,「3」,「7」に対応する印刷コンテンツ、及びその設定内容は以下の通りとなる。
「0」:
→印刷コンテンツC1
→コンテンツデータ:image1.jpg
→印刷条件タイプ0:A4,カラー,品質レベル1
「3」:
→印刷コンテンツC2
→コンテンツデータ:image2.jpg
→印刷条件タイプ3:A5,モノクロ,品質レベル1
「7」:
→印刷コンテンツC3
→コンテンツデータ:image3.jpg
→印刷条件タイプ7:L判,カラー,品質レベル2
次に、オファ側(送信側)では、こうして得られたINVITEリクエストを、アンサ側(受信側)に対して送信する(ステップS306)。この後、オファ側(送信側)は、アンサ側(受信側)からのレスポンスの受信待ちの状態となる(ステップS308)。
一方、オファ側(送信側)からのリクエストの受信待ちの状態にあった(ステップS320)アンサ側(受信側)では、オファ側(送信側)から送信されてきたINVITEリクエストを受信すると、そのボディ内のSDPによる記述内容を解析し、自身が対応可能(すなわち、印刷可能)な印刷条件を持つ印刷コンテンツがあるかどうかを判断する(ステップS322)。具体的には、ボディ内のSDPによる記述内容のうち、まず、前述した行番号の1行目に当たる「m=」行について解析する。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 3 7
-----------------------------------------
アンサ側(受信側)では、1番目の数字「0」から順に評価を行い、続く「a=」行の解析も行いながら、その数字に対応する印刷コンテンツについて、設定されている印刷条件に従い、自身が対応可能であるか否かを判断する。例えば、1番目の数字「0」の場合、アンサ側(受信側)では、印刷条件が「印刷条件タイプ0:A4,品質レベル1」であると認識し、この「0」についての設定内容は、前述したとおり行番号の2〜4行目に記載されているため、3行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識し、4行目に記載された「a=file:image1.jpg」から、ファイル名が「image1.jpg」であると認識する。そして、アンサ側(受信側)では、このファイル名「image1.jpg」の印刷コンテンツについて、「印刷条件タイプ0:A4,カラー,品質レベル1」に従い、自身が対応可能であるかどうかを判断することになる。
本実施例では、例えば、以下に示すごとく、1番目の数字「0」及び3番目の数字「7」に対応する2つの印刷コンテンツについて、それぞれ、設定されている印刷条件に従い、アンサ側(受信側)で対応可能であるものとする。すなわち、アンサ側(受信側)において、対応可能な印刷コンテンツ及びその印刷条件は、以下の通りとなる。
「0」:
→印刷コンテンツC1
→コンテンツデータ:image1.jpg
→印刷条件タイプ0:A4,カラー,品質レベル1
「7」:
→印刷コンテンツC3
→コンテンツデータ:image3.jpg
→印刷条件タイプ7:L判,カラー,品質レベル2
そこで、アンサ側(受信側)では、それら対応可能な印刷コンテンツの印刷条件及びファイル名を保持する(ステップS324)。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、その印刷条件及びファイル名をメモリ34内にコンテンツ情報38の一部として保存する。なお、図5において、ファイル名については図示されていない。
さらに、アンサ側(受信側)では、それら対応可能な印刷コンテンツの印刷条件及びファイル名を、SDPによって、200 OKレスポンスのボディに記述する(ステップS326)。記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 7
2 : a=rtpmap:0 PCMU/8000
3 : a=fmtp:color
4 : a=file:image1.jpg
5 : a=rtpmap:7 LPC/8000
6 : a=fmtp:color
7 : a=file:image3.jpg
-----------------------------------------
次に、アンサ側(受信側)では、こうして得られた200 OKレスポンスを、オファ側(送信側)に返信する(ステップS328)。この後、アンサ側(受信側)では、コンテンツデータの受信待ちの状態(受信待機)となる(ステップS330)。
一方、ステップS322の判断の結果、何れの印刷コンテンツについても、設定されている印刷条件では、アンサ側(受信側)で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する(ステップS342)。
次に、アンサ側(受信側)では、生成したエラーレスポンスを、オファ側(送信側)に返信する(ステップS344)。この後、アンサ側(受信側)では、SIPによる通信を終了する(ステップS346)。
一方、アンサ側(受信側)からのレスポンスの受信待ちとなっていたオファ側(送信側)では、アンサ側(受信側)からのレスポンスが返信されてくると、そのレスポンスが、200 OKレスポンスであるかどうかの判断をする(ステップS310)。
判断の結果、200 OKレスポンスである場合は、そのボディ内のSDPによる記述内容を解析し、その記述内容に基づいて、用意されている3つの印刷コンテンツC1〜C3の中から、送信すべき印刷コンテンツを決定し(ステップS312)、決定したコンテンツデータの送信を開始する(ステップS314)。具体的には、ボディ内のSDPによる記述内容のうち、まず、以下に示す、前述した行番号の1行目に当たる「m=」行について解析し、それに続く「a=」行の解析を行う。
-----------------------------------------
1 : m=audio 49170 RTP/AVP 0 7
-----------------------------------------
解析の結果、オファ側(送信側)では、1番目の数字「0」及び3番目の数字「7」に対応する2つの印刷コンテンツC1,C3を、送信すべき印刷コンテンツであるとして決定する。また、本実施例では、決定したそれら印刷コンテンツについて、C1,C3の順で、コンテンツデータを送信することになる(ステップS314,S316)。すなわち、オファ側(送信側)から送信される印刷コンテンツ及びその印刷条件は、以下の通りとなる。
「0」:
→印刷コンテンツC1
→コンテンツデータ:image1.jpg
→印刷条件タイプ0:A4,カラー,品質レベル1
「7」:
→印刷コンテンツC3
→コンテンツデータ:image3.jpg
→印刷条件タイプ7:L判,カラー,品質レベル2
これに対し、コンテンツデータの受信待ちの状態であったアンサ側(受信側)は、送信されてきたコンテンツデータの受信を開始する(ステップS332)。すなわち、まず、ファイル名「image1.jpg」のコンテンツデータ(印刷コンテンツC1)を受信し、次に、ファイル名「image1.jpg」のコンテンツデータ(印刷コンテンツC3)を受信することになる。具体的には、図5に示すように、アンサ側(受信側)である印刷端末108では、パーソナルコンピュータ112のCPU30が、通信部32を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ34にそのコンテンツデータ36を保存する。
そして、アンサ側(受信側)では、まず、印刷コンテンツC1のコンテンツデータ(ファイル名「image1.jpg」)の受信が完了したら(ステップS332)、ステップS324において保持していた、印刷コンテンツC1についての印刷条件、すなわち、「印刷条件タイプ0:A4,カラー,品質レベル1」を取得し(ステップS334)、そのコンテンツデータに基づく印刷を開始する(ステップS336)。具体的には、アンサ側(受信側)である印刷端末108において、パーソナルコンピュータ112のCPU30が、メモリ34から、コンテンツ情報38に含まれるファイル名に基づき、コンテンツデータ36を読み出すと共に、コンテンツ情報38に含まれる印刷条件を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ114において印刷実行可能なデータ形式に変換する。CPU30は、印刷命令と共に、変換後のコンテンツデータをプリンタ114に送信すると、プリンタ114は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
同時に、アンサ側(受信側)では、受信すべき印刷コンテンツがあるかどうかを判断し(ステップS328)、ある場合には、コンテンツデータの受信待ちの状態(受信待機)を経て(ステップS330)、次の印刷コンテンツC3について、コンテンツデータ(ファイル名「image3.jpg」)の受信を開始する(ステップS332)。その後、アンサ側(受信側)では、受信が完了したら(ステップS332)、ステップS324において保持していた、印刷コンテンツC3についての印刷条件、すなわち、「印刷条件タイプ7:L判,カラー,品質レベル2」を取得し(ステップS334)、そのコンテンツデータに基づく印刷を開始する(ステップS336)。アンサ側(受信側)では、全ての印刷コンテンツについて、受信・印刷を完了したら、オファ側(送信側)からの次の印刷コンテンツの受信待ちの状態(オファ側からのリクエスト受信待ちの状態)となる(ステップS320)。
こうして、アンサ側(受信側)である印刷端末108では、オファ側(送信側)から同時に送信された複数の印刷コンテンツについて、オファ側(送信側)から伝達された印刷条件に従った印刷結果を得ることができる。
一方、オファ側(送信側)において、上記判断の結果、200 OKレスポンスでない場合、すなわち、アンサ側(受信側)から返信されてきたレスポンスがエラーレスポンスである場合には、アンサ側(受信側)で何れの印刷条件も対応が不可能であったので、SIPによる通信を終了する(ステップS318)。
C−3.実施例の効果:
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ104と印刷端末108との間のセッションの確立を行う過程において、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、SIPサーバ106を介して、複数の印刷コンテンツについて、その印刷条件及びファイル名を伝達することができる。また、アンサ側(受信側)では、その複数の印刷コンテンツの中から、その印刷コンテンツについて設定されている印刷条件に従い、自身で対応可能な印刷コンテンツを選択して、オファ側(送信側)に回答し、オファ側(送信側)では、その回答された印刷コンテンツのコンテンツデータをアンサ側(受信側)へ送信することができる。この結果、オファ側(送信側)であるパーソナルコンピュータ104からアンサ側(受信側)である印刷端末108へ、複数の印刷コンテンツを同時に送信することができ、アンサ側(受信側)において、複数の印刷コンテンツについて、送信側ユーザ,受信側ユーザの双方の希望に沿った印刷結果を出力させることができる。
D.第4の実施例:
上記した第1の実施例では、送信側において、配信したいコンテンツデータや、印刷端末側でそのコンテンツデータに基づき印刷させる際の印刷条件は、予め、それぞれ用意されており、図2に示したパーソナルコンピュータ104のメモリ14に格納されていたが、本発明は、これに限定されるものではない。例えば、送信側において、画像をスキャナで読み取り、その読み取った画像データをコンテンツデータとすると共に、その画像を読み取った際の読取条件を、印刷端末側でそのコンテンツデータに基づき印刷させる際の印刷条件として用いるようにしてもよく、そのような実施例について、以下、説明する。
D−1.実施例の構成:
図12は本発明の第4の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
図12に示すとおり、本実施例のコンテンツ伝送システムが、第1の実施例におけるコンテンツ伝送システムと異なる点は、印刷コンテンツの配信を希望する送信側ユーザによって管理される送信端末204が、パーソナルコンピュータ212と、そのパーソナルコンピュータ212にUSBケーブルなどで接続されたスキャナ214と、によって構成されている点である。なお、その他の構成は、第1の実施例と同じであるので、同一の符号を付し、それらについての説明は省略する。
図13は図12における送信端末204の主要構成を示すブロック図である。パーソナルコンピュータ212は、図13に示すように、プログラムを実行することにより種々の処理や制御を行うCPU50と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部52と、プログラムを格納したり、データや情報を格納したりするためのメモリ54と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部60と、取得したデータや情報などを表示するためのモニタ62と、外部接続されたスキャナ214などからデータを入力するための入力インタフェース(I/F)部64と、を主として備えている。このうち、メモリ54は、データや情報として、配信依頼情報56や、コンテンツデータ57や、読取条件設定情報58などを格納することが可能である。
なお、本実施例では、送信端末204の構成として、パーソナルコンピュータ212とそのパーソナルコンピュータ212にUSBケーブルなどで直接接続されるスキャナ214と、で構成される形態を採用するようにしたが、送信端末の構成としては、種々の形態を採ることができる。
例えば、スキャナ214に代えて、複合機を用いる形態であってもよい。または、パーソナルコンピュータ212と、そのパーソナルコンピュータ212にLANケーブルなどでLANを介して接続されたネットワーク対応の複合機もしくはスキャナと、で構成される形態であってもよい。または、パーソナルコンピュータ212と、そのパーソナルコンピュータ212にLANケーブルなどでLANを介して接続されたネットワークアダプタと、そのネットワークアダプタにUSBケーブルなどで接続された複合機もしくはスキャナで構成される形態であってもよい。さらには、前述したようなIP通信プリンティング対応の複合機のみで構成される形態であってもよい。
また、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線LANや、ブルートゥースや、赤外線など、無線で接続されてもよい。
なお、本実施例において、スキャナ214は、請求項における画像読取部に、SIPサーバ106は、請求項におけるプレゼンスサーバに、それぞれ相当する。
D−2.実施例の動作:
図12に示すように、まず、送信端末204において、パーソナルコンピュータ212が、起動すると、SIPサーバ106に、SIPクライアントとしてアクセスして、登録要求を出し、自己のSIP URIやIPアドレスなどの情報を送信する(破線矢印126)。これにより、SIPサーバ106は、登録要求を受け付け、パーソナルコンピュータ212から送信された情報を、図3に示したように、登録情報26としてメモリ24に登録する。また、印刷端末108についても、同様に、その登録情報がSIPサーバ106に登録されている。
次に、送信側ユーザが、自己の管理する送信端末204において、図13に示すパーソナルコンピュータ212の入力部60を操作して、専用のプログラム(図示せず)を起動すると、CPU50は、そのプログラムを実行して、モニタ62に読取条件設定画面(図示せず)を表示させる。続いて、送信側ユーザは、入力部60を操作して、その読取条件設定画面内において、スキャナ214による画像の読み取りに関し、送信側ユーザが希望する読取条件を入力する。読取条件としては、用紙サイズ(すなわち、プレスキャンのサイズ、例えば、A4,B5,L判など)や、読取色(カラー,モノクロなど)や、読取品質(品質レベル1,品質レベル2など)などが挙げられる。CPU50は、入力部60を介して、読取条件が入力されると、その読取条件を読取条件設定情報58としてメモリ54に格納する。
その後、送信側ユーザが、入力部60を操作して、画像の読み取り開始を指示すると、CPU50は、メモリ54から読取条件設定情報58を読み出し、それに含まれている読取条件を取得する。そして、CPU50は、入力I/F部64を介して、スキャナ214に対し、その読取条件を伝達する共に、画像の読み取り開始を命令し、それにより、スキャナ214は、その読取条件に従った画像の読み取りを開始する。その後、スキャナ214が、読み取った画像データを出力すると、CPU50は、その画像データを入力I/F部64を介して受け取り、コンテンツデータ57として、メモリ54に格納する。
また、送信側では、印刷コンテンツを配信したい配信先のリストが用意されており、パーソナルコンピュータ212のメモリ54に、配信依頼情報56として格納されている。そこで、CPU50は、その配信依頼情報56を読み出し、それに含まれる配信先リストを解析する。配信先リストには、配信先として、印刷端末108などのSIP URIが記載されている。そして、CPU50は、その配信先リストに従って、例えば、まず、印刷端末108を、コンテンツデータの送信先として決定する。
こうして、コンテンツデータの送信先が決定されると、送信端末204のパーソナルコンピュータ212は、第1の実施例で述べたとおり、送信先である印刷端末108との間のセッションの確立を行う。
このセッションの確立を行うに際し、パーソナルコンピュータ212のCPU50は、まず、メモリ54から読取条件設定情報58を読み出し、それに含まれている読取条件を取得する。そして、このセッション確立を行う過程において、CPU50は、取得した読取条件を、コンテンツデータに基づいて印刷を行う際の印刷条件として、印刷端末108へ送信する。送信の方法としては、第1の実施例で述べたとおり、INVITEリクエストをパーソナルコンピュータ212から印刷端末108へ送信する際に、SDPにより、そのINVITEリクエストのボディに印刷条件(読取条件)を記述することによって送信する。例えば、読取条件が、「用紙サイズ:A4,読取色:カラー,読取品質:品質レベル1」である場合には、印刷条件として、図7に示した「印刷条件タイプ0:A4,カラー,品質レベル1」をINVITEリクエストのボディに記述することになる。
その後は、第1の実施例で述べたとおり、パーソナルコンピュータ212は、印刷端末108との間のセッションの確立を完了したら、メモリ54に格納していたコンテンツデータ57をHTTPを用いて印刷端末108へ送信し、印刷端末108では、先に受け取った印刷条件に従い、コンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
D−3.実施例の効果:
本実施例では、送信端末204において、画像をスキャナ214で読み取り、その読み取った画像データをコンテンツデータ57として印刷端末108へ配信すると共に、その画像を読み取った際の読取条件を、印刷端末108側でそのコンテンツデータに基づき印刷させる際の印刷条件として、印刷端末108との間のセッションの確立を行う過程において、印刷端末108へ送信している。従って、印刷端末108では、配信されたコンテンツデータについて、送信された印刷条件、すなわち、画像を読み取った際の読取条件に従って印刷を行うことができるため、送信側ユーザの希望に沿った印刷結果を出力させることができる。
E.変形例:
なお、本発明は上記した実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。
上記した各実施例においては、印刷条件は、コンテンツデータ17とは、別データとして、印刷条件データベースに18において管理されていたが、本発明はこれに限定されるものではない。例えば、印刷条件は、コンテンツデータ自身のヘッダに埋め込まれていてもよい。また、印刷条件は、コンテンツデータとは関係なく、送信側(オファ側)機器もしくはソフトウェアにデフォルト設定として保持されていてもよい。
上記した第1及び第2の実施例では、オファ側(送信側)では、同一の印刷コンテンツについて、印刷条件毎に、その印刷条件に応じたコンテンツデータを用意していたが、本発明はこれに限定されるものではない。例えば、オファ側(送信側)において、高画質なコンテンツデータを用意し、アンサ側(受信側)に送信する際に、そのコンテンツデータを、アンサ側(受信側)で対応可能な印刷条件に最適な形式(解像度や色など)に変換して、送信するようにしてもよい。また、オファ側(送信側)であるパーソナルコンピュータ104に直接またはネットワークを介して接続する専用サーバを用意して、上記印刷条件に適した形式へのコンテンツデータの変換を、その専用サーバにおいて実行させるようにしてもよい。
上記した第3の実施例では、アンサ側(受信側)において、ステップS324で、対応可能な印刷コンテンツの印刷条件及びファイル名を保持するようにしていたが、本発明はこれに限定されるものではない。例えば、ステップS314,S332で、オファ側(送信側)からアンサ側(受信側)へ、それら印刷コンテンツのコンテンツデータを送信する際に、そのコンテンツデータのヘッダに印刷条件を埋め込んで送信し、アンサ側(受信側)において、そのコンテンツデータを受信した際に、そのコンテンツデータのヘッダを解析して、埋め込まれていた印刷条件を取得するようにしてもよい。この場合、アンサ側(順側)では、ステップS324で、印刷条件及びファイル名を保持する必要はない。
上記した第4の実施例では、読取条件を設定し、その読取条件に従ってスキャナ214による画像の読み取りを行うようにしていたが、複数の異なる読取条件を設定して、同じ画像について、それぞれ、異なる読取条件で画像の読み取りを行い、複数のコンテンツデータを取得するようにしてもよい。すなわち、この場合、同一の画像について、複数の読取条件が設定され、それら読取条件毎に、その読取条件に応じたコンテンツデータが取得されることになる。第4の実施例では、上述したとおり、読取条件は印刷条件として扱われるので、言い換えれば、同一の印刷コンテンツについて、複数の印刷条件が用意され、それら印刷条件毎に、その印刷条件に応じたコンテンツデータが用意されたこととなる。
よって、第1の実施例で述べたように、パーソナルコンピュータ212から印刷端末108へ送信された印刷条件(すなわち、読取条件)が、印刷端末108において対応が不可能な場合には、別の印刷条件(すなわち、読取条件)を印刷端末108へ送信するようにすることも可能となる。また、第2の実施例で述べたように、パーソナルコンピュータ212から印刷端末108へ、1つの印刷コンテンツについて、複数の印刷条件(すなわち、複数の読取条件)を送信して、印刷端末108では、それら複数の印刷条件の中から対応可能な印刷条件をパーソナルコンピュータ212へ返信するようにすることも可能となる。
また、第4の実施例において、複数の画像を用意し、それら画像をスキャナ214で読み取る際の読取条件も、各画像に対応して設定するようにして、各画像について、対応する読取条件で画像の読み取りを行い、複数のコンテンツデータを取得するようにしてもよい。すなわち、この場合、異なる画像について、それぞれ、対応する読取条件が設定され、各画像毎に、対応する読取条件に応じたコンテンツデータが取得されることになる。第4の実施例では、上述したとおり、読取条件は印刷条件として扱われるので、言い換えれば、複数の印刷コンテンツについて、それぞれ、対応する印刷条件が用意され、各印刷コンテンツ毎に、対応する印刷条件に応じたコンテンツデータが用意されたこととなる。
よって、第3の実施例で述べたように、パーソナルコンピュータ212から印刷端末108へは、複数の印刷コンテンツについて、それら印刷条件(すなわち、読取条件)及びファイル名を同時に送信して、印刷端末108では、それら複数の印刷コンテンツの中から対応可能な印刷コンテンツについて、その印刷条件及びファイル名をパーソナルコンピュータ212へ返信するようにすることも可能となる。
上記した各実施例においては、ネットワークとして、インターネットを含むブロードバンドネットワークを利用したが、携帯電話網や、公衆電話網などを利用するようにしてもよい。
上記した各実施例においては、シグナリングプロトコルの一種であるSIPを利用したが、本発明はこれに限定されるものではなく、H.323や、MGCP(Media Gateway Control Protocol)、MEGACO(Media Gateway Control)などを用いるようにしてもよい。また、上記した実施例においては、データ転送プロトコルの一種であるHTTPを利用していたが、本発明はこれに限定されるものではなく、FTPや、RTP(Realtime Transport Protocol)、IRC(Internet Relay Chat)、TELNETなどを用いるようにしてもよい。また、セッション確立やデータ伝送を行うために、Skype(登録商標)やインスタントメッセージング(instant messaging)を利用するようにしてもよい。Skypeやインスタントメッセージングに限らず、その他、グローバルアドレスの管理やプレゼンスサービス機能を有する類似の各種技術を利用するようにしてもよい。
上記した各実施例では、SIPサーバをプロキシサーバとして機能させ、セッションの確立の仲介を行わせていたが、SIPでは、SIPクライアント同士が互いのSIP URIとIPアドレスを分かっていれば、ピアツーピアでセッションの確立を行うことが可能であるため、そのような場合には、SIPクライアント同士の間で、SIPサーバの仲介なしに、直接、セッションの確立を行うようにしてもよい。
上記した各実施例では、オファ側(送信側)であるパーソナルコンピュータからアンサ側(受信側)印刷端末に対して、コンテンツデータをPUSH型で配信するようにしていたが、PULL型で配信するようにしてもよい。ここで、「PULL型」とは、端末がサーバにデータ配信をリクエストして、その結果、サーバが端末にデータを配信する方法を言う。
上記した各実施例では、ネットワーク上の位置情報として、IPアドレスを利用するようにしていたが、MAC(Media Access Control)アドレスを利用するようにしてもよい。
上記した各実施例では、印刷条件としては、用紙サイズや、印刷品質や、印刷色などを挙げたが、その他、用紙種類(普通紙,光沢紙など)や、自動画像補正技術機能のON/OFFなどを含めるようにしてもよい。
上記した各実施例では、送信端末、すなわち、オファ側(送信側)を、パーソナルコンピュータ104で構成するようにしていたが、本発明はこれに限定されるものではなく、例えば、コンテンツ提供者からの依頼に基づき、コンテンツ提供者に代わって、印刷コンテンツの配信を行うコンテンツ配信サーバによって構成するようにしてもよい。また、この場合、印刷条件については、そのコンテンツ提供者の過去の履歴から印刷条件を決定するようにしてもよいし、コンテンツ提供者毎に予め印刷条件を登録しておいてもよい。
上記した各実施例では、情報出力装置として、印刷端末を用いる場合を例として説明したが、本発明はこれに限定されるものではなく、例えば、送信端末からディスプレイに画像などのコンテンツのデータを送信する場合に、ディスプレイの解像度などの表示条件を送信端末からディスプレイに伝える場合にも適用することができ、或いは、送信端末からオーディオ装置に音声などのコンテンツのデータを送信する場合に、ミュート状態などの音声出力条件を送信装置からオーディオ装置に伝える場合にも適用することができる。また、その他の情報出力装置として、電話やテレビなどを用いる場合にも適用することが可能である。
本発明の第1の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。 図1におけるパーソナルコンピュータ104の主要構成を示すブロック図である。 図1におけるSIPサーバ106の主要構成を示すブロック図である。 一般的なSIPサーバの種別を示す説明図である。 図1における印刷端末108の主要構成を示すブロック図である。 図1におけるパーソナルコンピュータ104と印刷端末108の間のセッション確立処理のシーケンスを示す説明図である。 既存のSDPと印刷条件との対応関係を示す説明図である。 図1のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。 本発明の第2の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。 本発明の第3の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理のうち、オファ側の処理の流れを示すフローチャートである。印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。 本発明の第3の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。 本発明の第4の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。 図12における送信端末204の主要構成を示すブロック図である。
符号の説明
10…CPU
12…通信部
13…入力部
14…メモリ
15…モニタ
16…配信依頼情報
17…コンテンツデータ
18…印刷条件データベース
20…CPU
22…通信部
24…メモリ
26…登録情報
30…CPU
32…通信部
34…メモリ
36…コンテンツデータ
38…コンテンツ情報
40…入力部
42…モニタ
46…出力I/F部
50…CPU
52…通信部
54…メモリ
56…配信依頼情報
57…コンテンツデータ
58…読取条件設定情報
60…入力部
62…モニタ
64…入力I/F部
104…パーソナルコンピュータ
106…SIPサーバ
108…印刷端末
110…ブロードバンドネットワーク
112…パーソナルコンピュータ
114…プリンタ
204…送信端末
212…パーソナルコンピュータ
214…スキャナ

Claims (11)

  1. コンテンツデータを、ネットワークを介して情報出力装置へ伝送する送信端末であって、
    前記コンテンツデータの送信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記情報出力装置との間におけるセッションの確立を行う制御部を備え、
    前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき情報の出力を行う際の出力条件を送信する、送信端末。
  2. 請求項1に記載の送信端末において、
    読取条件に基づいて画像を読み取り、得られた画像データを前記コンテンツデータとして取得する画像読取部をさらに備えると共に、
    前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記読取条件を前記出力条件として送信する、送信端末。
  3. 請求項1または請求項2に記載の送信端末において、
    前記シグナリングプロトコルは、SIPであって、
    前記制御部は、前記情報出力装置に前記仲介サーバを介して、前記SIPにおけるINVITEリクエストを送信する際、前記INVITEリクエスト中に前記出力条件を含ませる、送信端末。
  4. 請求項1ないし請求項3のうちの任意の1つに記載の送信端末において、
    前記制御部は、前記出力条件として、複数の条件を送信する、送信端末。
  5. 請求項4に記載の送信端末において、
    前記制御部は、前記セッションの確立後に、前記情報出力装置に対し、前記コンテンツデータとして、複数のデータを送信することを予定している場合、前記複数の条件は、前記複数のデータにそれぞれ対応する条件である、送信端末。
  6. 請求項1ないし請求項5のうちの任意の1つに記載の送信端末において、
    前記制御部は、前記セッションの確立後、データ転送用のプロトコルに従って、前記コンテンツデータとして、前記出力条件に対応したデータを送信する、送信端末。
  7. ネットワークを介して送信端末から伝送されたコンテンツデータを受信して、前記コンテンツデータに基づき情報の出力を行う情報出力装置であって、
    前記コンテンツデータの受信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記送信端末との間におけるセッションの確立を行う制御部を備え、
    前記制御部は、前記セッションの確立を行う過程において、前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を受信した場合、前記出力条件に対する応答を、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
  8. 請求項7に記載の情報出力装置において、
    前記制御部は、受信した前記出力条件での前記情報の出力が可能か否かを判断し、その判断結果を、前記応答として送信する、情報出力装置。
  9. 請求項7または請求項8に記載の情報出力装置において、
    前記制御部は、前記セッションの確立を行う過程において、前記出力条件として、前記複数の条件を受信した場合、前記複数の条件の中から所望の条件を選択し、その選択結果を前記出力条件に対する応答として、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
  10. コンテンツデータを、ネットワークを介して伝送するコンテンツ伝送システムであって、
    前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、
    前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて情報の出力を行う情報出力装置と、
    前記ネットワークに接続される仲介サーバと、
    を備え、
    前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置は、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行うと共に、
    前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を送信する、コンテンツ伝送システム。
  11. コンテンツデータをネットワークを介して伝送するコンテンツ伝送システムにおいて、前記コンテンツデータに基づいて情報の出力を行う際の出力条件を伝送するための出力条件伝送方法であって、
    前記コンテンツ伝送システムは、前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて前記情報の出力を行う情報出力装置と、前記ネットワークに接続される仲介サーバと、を備え、
    前記出力条件伝送方法は、
    (a)前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置が、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行う工程と、
    (b)前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記出力条件を送信する工程と、
    を備える出力条件伝送方法。
JP2008267080A 2007-11-14 2008-10-16 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法 Withdrawn JP2009193567A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008267080A JP2009193567A (ja) 2007-11-14 2008-10-16 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法
US12/291,772 US20090122343A1 (en) 2007-11-14 2008-11-13 Transmission terminal, information output device, and content transmission system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2007295652 2007-11-14
JP2008006875 2008-01-16
JP2008267080A JP2009193567A (ja) 2007-11-14 2008-10-16 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法

Publications (1)

Publication Number Publication Date
JP2009193567A true JP2009193567A (ja) 2009-08-27

Family

ID=41075486

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008267080A Withdrawn JP2009193567A (ja) 2007-11-14 2008-10-16 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法

Country Status (1)

Country Link
JP (1) JP2009193567A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013025596A (ja) * 2011-07-22 2013-02-04 Brother Ind Ltd 通信装置
JP2014225923A (ja) * 2014-08-11 2014-12-04 ブラザー工業株式会社 印刷システム、印刷装置、及び印刷プログラム
US9383948B2 (en) 2010-12-27 2016-07-05 Brother Kogyo Kabushiki Kaisha Printing system, printing apparatus, and printing program

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135466A (ja) * 2000-10-20 2002-05-10 Canon Inc 出力システム及びその制御方法、及び媒体
JP2005216080A (ja) * 2004-01-30 2005-08-11 Seiko Epson Corp 印刷システム、印刷装置、印刷方法、および印刷指示送信プログラム
JP2006229394A (ja) * 2005-02-16 2006-08-31 Murata Mach Ltd 画像通信装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135466A (ja) * 2000-10-20 2002-05-10 Canon Inc 出力システム及びその制御方法、及び媒体
JP2005216080A (ja) * 2004-01-30 2005-08-11 Seiko Epson Corp 印刷システム、印刷装置、印刷方法、および印刷指示送信プログラム
JP2006229394A (ja) * 2005-02-16 2006-08-31 Murata Mach Ltd 画像通信装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9383948B2 (en) 2010-12-27 2016-07-05 Brother Kogyo Kabushiki Kaisha Printing system, printing apparatus, and printing program
US9729751B2 (en) 2010-12-27 2017-08-08 Brother Kogyo Kabushiki Kaisha Printing system, printing apparatus, and printing program
JP2013025596A (ja) * 2011-07-22 2013-02-04 Brother Ind Ltd 通信装置
JP2014225923A (ja) * 2014-08-11 2014-12-04 ブラザー工業株式会社 印刷システム、印刷装置、及び印刷プログラム

Similar Documents

Publication Publication Date Title
JP5277855B2 (ja) 送信装置およびその方法
JP5453745B2 (ja) ポスティングサーバ、コンテンツ伝送システム及びポスティングサーバ制御方法
JP5245612B2 (ja) ポスティングサーバ、および、ポスティングサーバ制御方法
US20090201535A1 (en) Posting server, sending terminal, posting server control method, and sending terminal control method
US20090201536A1 (en) Posting server, printing terminal, posting server control method, and printing terminal control method
US20090122343A1 (en) Transmission terminal, information output device, and content transmission system
JP5408120B2 (ja) 通信装置、通信装置のプログラムおよび通信装置の制御方法
US8902461B2 (en) Communication control apparatus and communication control system for transmitting a scanned image via a NGN
CN101437100A (zh) 发送终端、信息输出装置以及内容传送系统
JP2009193567A (ja) 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法
JP5157554B2 (ja) 送信装置、コンテンツ送信システム、コンテンツ送信方法及びコンピュータプログラム
US20100118341A1 (en) Printer terminal and posting server
JP2009193538A (ja) コンテンツ伝送システム及び印刷装置特定方法
JP2009193540A (ja) コンテンツ伝送システム、仲介サーバ及び機種情報伝送方法
JP5854793B2 (ja) 通信装置、その制御方法、および制御プログラム
JP2013058846A (ja) 通信制御装置、その制御方法、および制御プログラム
JP5870585B2 (ja) 通信装置及び通信システム
JP2009239497A (ja) データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム
US8527583B2 (en) Communication device including a communication start request output unit and a response notification acceptance unit, communication system, and computer-readable medium
JP2014176025A (ja) 中継装置及びfax送受信プログラム
JP2010113648A (ja) コンテンツ配信システム
JP2014116911A (ja) 情報処理装置、その制御方法、プログラム、及び画像処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110803

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121211

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20130122