(57)【要約】【課題】送信端末から情報出力装置である印刷端末に出力条件である印刷条件を伝達するための技術を提供する。【解決手段】コンテンツデータの送信に先立ち、パーソナルコンピュータ１０４及び印刷端末１０８は、ＳＩＰに従って、ＳＩＰサーバ１０６を介して、両者の間におけるセッションの確立を行う。そのセッションの確立を行う過程において、パーソナルコンピュータ１０４は、印刷端末１０８にＳＩＰサーバ１０６を介して、印刷端末１０８においてコンテンツデータに基づき印刷を行う際の印刷条件を送信する。【選択図】図８
2009193567.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツデータを、ネットワークを介して情報出力装置へ伝送する送信端末であって、
前記コンテンツデータの送信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記情報出力装置との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき情報の出力を行う際の出力条件を送信する、送信端末。
【請求項２】
請求項１に記載の送信端末において、
読取条件に基づいて画像を読み取り、得られた画像データを前記コンテンツデータとして取得する画像読取部をさらに備えると共に、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記読取条件を前記出力条件として送信する、送信端末。
【請求項３】
請求項１または請求項２に記載の送信端末において、
前記シグナリングプロトコルは、ＳＩＰであって、
前記制御部は、前記情報出力装置に前記仲介サーバを介して、前記ＳＩＰにおけるＩＮＶＩＴＥリクエストを送信する際、前記ＩＮＶＩＴＥリクエスト中に前記出力条件を含ませる、送信端末。
【請求項４】
請求項１ないし請求項３のうちの任意の１つに記載の送信端末において、
前記制御部は、前記出力条件として、複数の条件を送信する、送信端末。
【請求項５】
請求項４に記載の送信端末において、
前記制御部は、前記セッションの確立後に、前記情報出力装置に対し、前記コンテンツデータとして、複数のデータを送信することを予定している場合、前記複数の条件は、前記複数のデータにそれぞれ対応する条件である、送信端末。
【請求項６】
請求項１ないし請求項５のうちの任意の１つに記載の送信端末において、
前記制御部は、前記セッションの確立後、データ転送用のプロトコルに従って、前記コンテンツデータとして、前記出力条件に対応したデータを送信する、送信端末。
【請求項７】
ネットワークを介して送信端末から伝送されたコンテンツデータを受信して、前記コンテンツデータに基づき情報の出力を行う情報出力装置であって、
前記コンテンツデータの受信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記送信端末との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を受信した場合、前記出力条件に対する応答を、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
【請求項８】
請求項７に記載の情報出力装置において、
前記制御部は、受信した前記出力条件での前記情報の出力が可能か否かを判断し、その判断結果を、前記応答として送信する、情報出力装置。
【請求項９】
請求項７または請求項８に記載の情報出力装置において、
前記制御部は、前記セッションの確立を行う過程において、前記出力条件として、前記複数の条件を受信した場合、前記複数の条件の中から所望の条件を選択し、その選択結果を前記出力条件に対する応答として、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
【請求項１０】
コンテンツデータを、ネットワークを介して伝送するコンテンツ伝送システムであって、
前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、
前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて情報の出力を行う情報出力装置と、
前記ネットワークに接続される仲介サーバと、
を備え、
前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置は、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行うと共に、
前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を送信する、コンテンツ伝送システム。
【請求項１１】
コンテンツデータをネットワークを介して伝送するコンテンツ伝送システムにおいて、前記コンテンツデータに基づいて情報の出力を行う際の出力条件を伝送するための出力条件伝送方法であって、
前記コンテンツ伝送システムは、前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて前記情報の出力を行う情報出力装置と、前記ネットワークに接続される仲介サーバと、を備え、
前記出力条件伝送方法は、
（ａ）前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置が、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行う工程と、
（ｂ）前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記出力条件を送信する工程と、
を備える出力条件伝送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータをネットワークを介して伝送するための技術に関するものである。なお、本明細書中において、「コンテンツ」とは、画像や音声などの情報を言い、「コンテンツデータ」とは、上記コンテンツを表すデータを言う。なお、上記コンテンツのうち、画像など、印刷可能なものを「印刷コンテンツ」と言う場合がある。
【背景技術】
【０００２】
従来、企業が顧客に広告などを配信する場合、郵送やファクシミリなどが利用されていた。また、通信教育分野などにおいて、教材提供企業が受講者に教材などを配信する場合も、同様に、郵送やファクシミリなどが利用されていた。
【０００３】
郵送による場合、広告や教材などの印刷コンテンツ自体は、高品質で印刷されたものを提供できるものの、送付に多数の人手を要し、多くのコストがかかると共に、送付にも時間を要するという問題がある。
【０００４】
また、ファクシミリによる場合は、郵送に比較して、送付に人手や時間は要しないものの、通信費用は発生し、また、顧客先で受け取る印刷コンテンツ自体も高品質なものを期待できないという問題がある。
【０００５】
一方、近年では、インターネットの発達などによって、情報を無料に近い低コストで伝送することが可能となっている。また、高性能なプリンタや複合機などの開発によって、家庭内でも、比較的低コストで、高品質な印刷を行うことができるようになってきている。
【０００６】
そこで、パーソナルコンピュータやサーバなどを含む送信端末から、上記したインターネットなどのネットワークを介して、プリンタや複合機などを含む印刷端末に、印刷コンテンツのデータを、低コストで、かつ、高品質にて配信することができる、システムの開発が待たれている。
【０００７】
なお、ネットワークを利用した情報の伝送に関しては、例えば、下記の特許文献に記載のものが知られている。
【特許文献１】特開２００５−１０９７０１号公報
【特許文献２】特開２００３−１７８０２８号公報
【特許文献３】特表２００５−５１６３２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記したシステムでは、送信端末から印刷端末に印刷コンテンツのデータを送信する場合に、送信端末から印刷端末に用紙サイズや印刷品質などの印刷条件を伝えないと、印刷端末では、デフォルトで設定されている印刷条件でしか、その印刷コンテンツを印刷できないことになる。そこで、そのような印刷条件を送信端末から印刷端末に如何にして伝えるかが課題となる。
【０００９】
なお、このような課題は、送信端末から印刷端末に印刷コンテンツのデータを送信する場合に限らず、送信端末からディスプレイ等に画像などのコンテンツのデータを送信する場合に、解像度などの表示条件を送信端末からディスプレイ等に如何にして伝えるか、或いは、送信端末からオーディオ装置等に音声などのコンテンツのデータを送信する場合に、ミュート状態などの音声出力条件を送信装置からオーディオ装置等に如何にして伝えるかなど、共通の課題である。
なお、以下において、印刷端末，ディスプレイ，オーディオ装置などを、総称して、情報出力装置と言う場合があり、印刷条件，表示条件，音声出力条件などを、総称して、情報出力装置において情報の出力を行う際の条件、すなわち、出力条件と言う場合がある。
【００１０】
従って、本発明の目的は、上記した従来技術の課題を解決し、送信端末から情報出力装置に出力条件を伝達するための技術を提供することにある。
【課題を解決するための手段】
【００１１】
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
【００１２】
［適用例１］
コンテンツデータを、ネットワークを介して情報出力装置へ伝送する送信端末であって、
前記コンテンツデータの送信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記情報出力装置との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき情報の出力を行う際の出力条件を送信する、送信端末。
【００１３】
このように、適用例１の送信端末では、情報出力装置にコンテンツデータを送信する場合に、その送信に先立ち、情報出力装置との間のセッションの確立を行う過程において、情報出力装置へ仲介サーバを介して、出力条件を伝達することができる。従って、情報出力装置では、送信されたコンテンツデータについて、送信端末から伝達された出力条件に従って情報の出力を行うことができるため、情報出力装置において、コンテンツデータに基づく情報出力結果として、送信側ユーザの希望に沿った情報出力結果を得ることができる。
【００１４】
［適用例２］
適用例１に記載の送信端末において、読取条件に基づいて画像を読み取り、得られた画像データを前記コンテンツデータとして取得する画像読取部をさらに備えると共に、
前記制御部は、前記セッションの確立を行う過程において、前記情報出力装置に前記仲介サーバを介して、前記読取条件を前記出力条件として送信する、送信端末。
【００１５】
このように、送信端末が、読取条件に基づいて画像を読み取り、得られた画像データをコンテンツデータとすると共に、セッションの確立を行う過程において、情報出力装置に仲介サーバを介して、上記読取条件を出力条件として送信することにより、情報出力装置では、送信端末からのコンテンツデータについて、送信された出力条件、すなわち、画像を読み取った際の読取条件に従って情報の出力を行うことができるため、送信側ユーザの希望に沿った情報出力結果を得ることができる。
【００１６】
［適用例３］
適用例１または適用例２に記載の送信端末において、前記シグナリングプロトコルは、ＳＩＰであって、
前記制御部は、前記情報出力装置に前記仲介サーバを介して、前記ＳＩＰにおけるＩＮＶＩＴＥリクエストを送信する際、前記ＩＮＶＩＴＥリクエスト中に前記出力条件を含ませる、送信端末。
【００１７】
このように、シグナリングプロトコルがＳＩＰである場合、ＩＮＶＩＴＥリクエスト中に出力条件を含ませることにより、送信端末と情報出力装置との間のセッションの確立を行う過程において、送信端末から情報出力装置へ出力条件を確実に伝達することができる。
【００１８】
［適用例４］
適用例１ないし適用例３のうちの任意の１つに記載の送信端末において、前記制御部は、前記出力条件として、複数の条件を送信する、送信端末。
【００１９】
このように、送信端末が、出力条件として複数の条件を送信することにより、情報出力装置では、それら条件の中から、所望の条件を選択することができる。
【００２０】
［適用例５］
適用例４に記載の送信端末において、前記制御部は、前記セッションの確立後に、前記情報出力装置に対し、前記コンテンツデータとして、複数のデータを送信することを予定している場合、前記複数の条件は、前記複数のデータにそれぞれ対応する条件である、送信端末。
【００２１】
このように、適用例５の送信端末では、コンテンツデータとして複数のデータを送信する場合、各データ毎に対応した出力条件を設定して、情報出力装置へ伝達することができる。
【００２２】
［適用例６］
適用例１ないし適用例５のうちの任意の１つに記載の送信端末において、前記制御部は、前記セッションの確立後、データ転送用のプロトコルに従って、前記コンテンツデータとして、前記出力条件に対応したデータを送信する、送信端末。
【００２３】
このように、送信端末が、コンテンツデータとして、情報出力装置へ伝達した出力条件に対応したデータを、情報出力装置へ送信することにより、情報出力装置では、そのコンテンツデータに基づいて情報の出力を行うことにより、送信側ユーザの希望に沿った情報出力結果を得ることができる。
【００２４】
［適用例７］
ネットワークを介して送信端末から伝送されたコンテンツデータを受信して、前記コンテンツデータに基づき情報の出力を行う情報出力装置であって、
前記コンテンツデータの受信に先立ち、シグナリングプロトコルに従って、前記ネットワークに接続される仲介サーバを介して、前記送信端末との間におけるセッションの確立を行う制御部を備え、
前記制御部は、前記セッションの確立を行う過程において、前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を受信した場合、前記出力条件に対する応答を、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
【００２５】
このように、適用例７の情報出力装置では、送信端末との間のセッションの確立を行う過程において、送信端末へ仲介サーバを介して、伝達された出力条件に対し、応答を返すことができる。
【００２６】
［適用例８］
適用例７に記載の情報出力装置において、前記制御部は、受信した前記出力条件での前記情報の出力が可能か否かを判断し、その判断結果を、前記応答として送信する、情報出力装置。
【００２７】
このように、情報出力装置が、受信した出力条件での情報の出力が可能か否かの判断結果を送信端末へ返すことにより、送信端末では、情報出力装置側において希望する出力条件を把握することができ、その出力条件に対応したコンテンツデータを情報出力装置へ送信することができる。
【００２８】
［適用例９］
適用例７または適用例８に記載の情報出力装置において、前記制御部は、前記セッションの確立を行う過程において、前記出力条件として、前記複数の条件を受信した場合、前記複数の条件の中から所望の条件を選択し、その選択結果を前記出力条件に対する応答として、前記送信端末に前記仲介サーバを介して送信する、情報出力装置。
【００２９】
このように、情報出力装置が、複数の条件の中から所望の条件を選択し、その選択結果を送信端末に返すことにより、送信端末では、情報出力装置側において希望する出力条件を把握することができ、その出力条件に対応したコンテンツデータを情報出力装置へ送信することができる。
【００３０】
［適用例１０］
コンテンツデータを、ネットワークを介して伝送するコンテンツ伝送システムであって、
前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、
前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて情報の出力を行う情報出力装置と、
前記ネットワークに接続される仲介サーバと、
を備え、
前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置は、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行うと共に、
前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記情報出力装置において前記コンテンツデータに基づき前記情報の出力を行う際の出力条件を送信する、コンテンツ伝送システム。
適用例１０のコンテンツ伝送システムによれば、適用例１と同様の効果を奏することができる。
【００３１】
［適用例１１］
コンテンツデータをネットワークを介して伝送するコンテンツ伝送システムにおいて、前記コンテンツデータに基づいて情報の出力を行う際の出力条件を伝送するための出力条件伝送方法であって、
前記コンテンツ伝送システムは、前記ネットワークに接続され、前記コンテンツデータを前記ネットワークを介して送信する送信端末と、前記ネットワークに接続され、前記送信端末からの前記コンテンツデータを受信し、前記コンテンツデータに基づいて前記情報の出力を行う情報出力装置と、前記ネットワークに接続される仲介サーバと、を備え、
前記出力条件伝送方法は、
（ａ）前記コンテンツデータの送信に先立ち、前記送信端末及び前記情報出力装置が、シグナリングプロトコルに従って、前記仲介サーバを介して、前記送信端末と前記情報出力装置との間におけるセッションの確立を行う工程と、
（ｂ）前記セッションの確立を行う過程において、前記送信端末は、前記情報出力装置に前記仲介サーバを介して、前記出力条件を送信する工程と、
を備える出力条件伝送方法。
適用例１１の出力条件伝送方法によれば、適用例１と同様の効果を奏することができる。
【００３２】
なお、本発明は、上記した送信端末や情報出力装置やコンテンツ伝送システムなどの装置発明の態様や出力条件伝送方法などの方法発明の態様に限ることなく、それら方法や装置を構築するためのコンピュータプログラムとしての態様や、そのようなコンピュータプログラムを記録した記録媒体としての態様など、種々の態様で実現することも可能である。
【発明を実施するための最良の形態】
【００３３】
以下、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１の実施例：
Ａ−１．実施例の構成：
Ａ−２．実施例の動作：
Ａ−３．実施例の効果：
Ｂ．第２の実施例：
Ｂ−１．実施例の構成：
Ｂ−２．実施例の動作：
Ｂ−３．実施例の効果：
Ｃ．第３の実施例：
Ｃ−１．実施例の構成：
Ｃ−２．実施例の動作：
Ｃ−３．実施例の効果：
Ｄ．第４の実施例：
Ｄ−１．実施例の構成：
Ｄ−２．実施例の動作：
Ｄ−３．実施例の効果：
Ｅ．変形例：
【００３４】
Ａ．第１の実施例：
Ａ−１．実施例の構成：
図１は本発明の第１の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
【００３５】
図１に示すとおり、本実施例のコンテンツ伝送システムは、パーソナルコンピュータ１０４と、ＳＩＰ（Session Initiation Protocol）サーバ１０６と、情報出力装置である印刷端末１０８と、で構成される。このうち、パーソナルコンピュータ１０４は、印刷コンテンツ（広告や通信教材など）の配信を希望する送信側ユーザによって管理される。印刷端末１０８は、配信された印刷コンテンツを受け取る受信側ユーザによって管理される。ＳＩＰサーバ１０６は、例えば、ネットワークサービス提供業者などによって管理される。
【００３６】
パーソナルコンピュータ１０４、ＳＩＰサーバ１０６、及び印刷端末１０８は、インターネットを含む、いわゆるブロードバンドネットワーク１１０を介して接続されている。
【００３７】
本実施例では、広告や通信教材などの印刷コンテンツは、コンテンツデータとして、後ほど詳述するように、パーソナルコンピュータ１０４によって、印刷端末１０８にＰＵＳＨ型で配信される。ここで、このような印刷のために用いられるコンテンツデータとしては、例えば、ＪＰＥＧデータ、ＧＩＦデータ、ＰＮＧデータ、ＴＩＦＦデータ、プレーンテキストデータ、ＨＴＭＬデータ、ＰＤＦデータ、ＰｏｓｔＳｃｒｉｐｔ（登録商標）データなど、画像やドキュメントを表現することが可能な各種データを用いることができる。また、印刷端末で用いられるプリンタ等の機種が分かっている場合には、印刷データの形態で配信するようにしてもよい。また、ここで、「ＰＵＳＨ型」とは、端末側が情報をリクエストしなくても、サーバ側が一方的に情報を端末に送り出して配信する方法を言う。なお、コンテンツデータの配信、すなわち、装置間におけるコンテンツデータの伝送には、データ転送プロトコルの一種であるＨＴＴＰ（Hypertext Transfer Protocol）を用いるようにしている。
【００３８】
また、本実施例では、上述したコンテンツデータの配信に先立って、シグナリングプロトコルの一種であるＳＩＰ（Session Initiation Protocol）を用いて、ＳＩＰサーバ１０６を介して、装置間、すなわち、パーソナルコンピュータ１０４と印刷端末１０８との間におけるセッションの確立を行うようにしている。さらに、本実施例では、このセッションの確立を行う過程において、パーソナルコンピュータ１０４から印刷端末１０８へ、ＳＩＰサーバ１０６を介して、コンテンツデータに基づき印刷を行う際の印刷条件を伝達するようにしている。ここで、「セッション」とは、端末などのノード間でメディアストリームを送受信する関係を言う。また、印刷条件としては、用紙サイズ（例えば、Ａ４，Ｂ５，Ｌ判など）や、印刷色（カラー，モノクロなど）や、印刷品質（品質レベル１，品質レベル２など）などが挙げられる。
【００３９】
図２は図１におけるパーソナルコンピュータ１０４の主要構成を示すブロック図である。図２に示すように、パーソナルコンピュータ１０４は、プログラムを実行することにより種々の処理や制御を行うＣＰＵ１０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部１２と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部１３と、プログラムを格納したり、データや情報を格納したりするためのメモリ１４と、取得したデータや情報などを表示するためのモニタ１５と、を主として備えている。このうち、メモリ１４は、データや情報として、後述するような、配信依頼情報１６や、コンテンツデータ１７や、印刷条件データベース１８などを格納することが可能である。
【００４０】
図３は図１におけるＳＩＰサーバ１０６の主要構成を示すブロック図である。図３に示すように、ＳＩＰサーバ１０６は、サーバコンピュータによって構成されており、プログラムを実行することにより種々の処理や制御を行うＣＰＵ２０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部２２と、プログラムを格納したり、データや情報を格納したりするためのメモリ２４と、を主として備えている。このうち、メモリ２４は、情報として、後述するような、登録情報２６などを格納することが可能である。なお、ＳＩＰサーバ１０６は、上記構成要素以外にも、キーボードやポインティングデバイスなどの入力部やモニタなどの表示部などを備えているが、図では省略されている。
【００４１】
図４は一般的なＳＩＰサーバの種別を示す説明図である。一般に、ＳＩＰサーバは、機能に応じて、図４に示すような種別に分けることができる。
【００４２】
レジストラは、ＳＩＰクライアント（すなわち、ＳＩＰユーザエージェント）からの登録要求を受け付けて、ＳＩＰクライアントのＳＩＰアドレス（すなわち、ＳＩＰ  ＵＲＩ（Uniform Resource Identifier））や位置情報（すなわち、ＩＰ（Internet Protocol）アドレスなど）を、ロケーションサーバに登録する。
【００４３】
ロケーションサーバは、ＳＩＰクライアントやサーバのＳＩＰアドレスや位置情報などを格納するデータベースである。
【００４４】
プロキシサーバは、ＳＩＰクライアント間において、リクエストやレスポンスを中継するサーバであって、ＳＩＰクライアント間におけるセッションの確立などを仲介する。
【００４５】
リダイレクトサーバは、ＳＩＰクライアントからの問い合わせに対して、通信したい相手先の位置情報を通知する。
【００４６】
プレゼンスサーバは、ＳＩＰクライアントに関するプレゼンス情報を取得し、管理すると共に、それらのプレゼンス情報を他のＳＩＰクライアントに提供する。
【００４７】
図５は図１における印刷端末１０８の主要構成を示すブロック図である。印刷端末１０８は、図１に示すとおり、パーソナルコンピュータ１１２と、そのパーソナルコンピュータ１１２にＵＳＢケーブルなどで接続されたプリンタ１１４と、によって構成されている。このうち、パーソナルコンピュータ１１２は、図５に示すように、プログラムを実行することにより種々の処理や制御を行うＣＰＵ３０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部３２と、プログラムを格納したり、データや情報を格納したりするためのメモリ３４と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部４０と、取得したデータや情報などを表示するためのモニタ４２と、外部接続されたプリンタ１１４などにデータを出力するための出力インタフェース（Ｉ／Ｆ）部４６と、を主として備えている。このうち、メモリ３４は、データや情報として、コンテンツデータ３６やコンテンツ情報３８などを格納することが可能である。
【００４８】
なお、本実施例では、印刷端末１０８の構成として、パーソナルコンピュータ１１２とそのパーソナルコンピュータ１１２にＵＳＢケーブルなどで直接接続されるプリンタ１１４と、で構成される形態を採用するようにしたが、印刷端末の構成としては、種々の形態を採ることができる。
【００４９】
例えば、プリンタ１１４に代えて、複合機を用いる形態であってもよい。または、パーソナルコンピュータ１１２と、そのパーソナルコンピュータ１１２にＬＡＮケーブルなどでＬＡＮ（ローカルエリアネットワーク）を介して接続されたネットワーク対応の複合機もしくはプリンタと、で構成される形態であってもよい。または、パーソナルコンピュータ１１２と、そのパーソナルコンピュータ１１２にＬＡＮケーブルなどでＬＡＮを介して接続されたネットワークアダプタと、そのネットワークアダプタにＵＳＢケーブルなどで接続された複合機もしくはプリンタと、で構成される形態であってもよい。
【００５０】
さらには、ＩＰ（Internet Protocol）通信プリンティング対応の複合機もしくはプリンタのみで構成される形態であってもよい。ＩＰ通信プリンティング対応の複合機もしくはプリンタは、ＳＩＰ  ＵＲＩなどグローバルなアドレスを直接扱うことができるため、ブロードバンドルータなどを介して、インターネットなどのブロードバンドネットワークに直接接続したとしても、それらネットワーク上の装置との間でデータをやりとりすることが可能だからである。なお、ここで、ＩＰ通信プリンティングとは、以下の条件を満たす印刷方式を言う。
・ネットワークを用いた印刷方式である。
・通信プロトコルとしてＳＩＰなどの呼制御プロトコルを用いる。
・対応する端末間同士でコンテンツデータの送受信が可能である。
・パーソナルコンピュータを含む他の機器の仲介なしにコンテンツデータの直接印刷が可能である。
【００５１】
なお、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線ＬＡＮや、ブルートゥースや、赤外線など、無線で接続されてもよい。
【００５２】
また、インターネットを含むネットワーク１１０では、グローバルＩＰアドレスが割り当てられるのに対し、ＬＡＮなどのプライペートネットワークでは、プライペートＩＰアドレスが割り当てられることが多い。そのような場合、いわゆるＮＡＴ（Network Address Translation）越えの問題が存在するが、一般に知られているように、ＮＡＴ越えの方法として、ＵＰｎＰ（Universal Plug and Play）の技術や、ＳＴＵＮ（Simple Traversal of UDP through NAT）の技術や、ＴＵＲＮ（Traversal Using Relay NAT）の技術や、ＩＣＥ（Interactive Connectivity Establishment）の技術などを用いることによって、そのような問題は解決することができる。
【００５３】
なお、本実施例において、パーソナルコンピュータ１０４は、請求項における送信端末に、ＳＩＰサーバ１０６は、請求項における仲介サーバに、印刷端末１０８は、請求項における情報出力装置に、それぞれ相当し、また、パーソナルコンピュータ１０４のＣＰＵ１０またはパーソナルコンピュータ１１２のＣＰＵ３０は、請求項における制御部に、それぞれ相当する。
【００５４】
Ａ−２．実施例の動作：
図１において、まず、パーソナルコンピュータ１０４や印刷端末１０８は、それぞれ、起動すると、ＳＩＰサーバ１０６にＳＩＰクライアントとしてアクセスする。そして、パーソナルコンピュータ１０４、印刷端末１０８は、アクセスしたＳＩＰサーバ１０６にそれぞれ登録要求を出し、自己のＳＩＰ  ＵＲＩやＩＰアドレスなどの情報を送信する（破線矢印１２６，１２８）。ＳＩＰサーバ１０６は、レジストラ，ロケーションサーバとして機能し、図３に示すように、そのＣＰＵ２０は、通信部２２を介して、登録要求を受け付け、送信された情報を登録情報２６としてメモリ２４に登録する。
【００５５】
この結果、ＳＩＰサーバ１０６は、パーソナルコンピュータ１０４及び印刷端末１０８の登録情報を有することになる。登録情報２６は、各端末毎に、そのＳＩＰ  ＵＲＩと、そのＩＰアドレスと、が対応付けて、ＣＰＵ２０によって管理される。
【００５６】
ここで、ＳＩＰ  ＵＲＩは、例えば、「sip:user@west.com」という形式の識別子で表される。先頭には、ＳＩＰであることを示す識別子（スキーム）を置き（「sip」）、次にユーザ識別子を置き（「user」）、「@」で区切って、ホスト名を置く（「west.com」）という形式になっている。なお、ユーザ識別子には、ユーザＩＤや電話番号などが用いられる。また、ホスト名には、完全修飾ドメイン名（ＦＱＤＮ：Fully Qualified Domain Name）やＩＰアドレスが用いられる。さらに、ホスト名の後には、ポート番号や、オプションパラメータなどを置くことも可能である。また、ＳＩＰ  ＵＲＩに代えて、ＳＩＰのセキュアなＵＲＩとして、ＳＩＰＳ  ＵＲＩを用いることもできる。その場合、スキームとして、「sips」を置く。
【００５７】
こうして、ＳＩＰに関する事前準備が完了したら、ＳＩＰを利用した、装置間におけるセッションの確立を行うことが可能となる。
【００５８】
そこで、まず、送信側では、配信したい印刷コンテンツが用意されており、図２に示すパーソナルコンピュータ１０４のメモリ１４に、コンテンツデータ１７として格納されている。また、その印刷コンテンツを印刷端末側で印刷させる際の印刷条件も用意されており、メモリ１４内の印刷条件データベース１８において、管理されている。さらに、その印刷コンテンツを配信すべき各配信先のリストも用意されており、メモリ１４に、配信依頼情報１６として格納されている。
【００５９】
その後、パーソナルコンピュータ１０４のＣＰＵ１０は、配信依頼情報１６を読み出し、それに含まれる配信先リストを解析する。配信先リストには、配信先として、印刷端末１０８などのＳＩＰ  ＵＲＩが記載されている。そして、パーソナルコンピュータ１０４のＣＰＵ１０は、その配信先リストに従って、例えば、まず、印刷端末１０８を、コンテンツデータの送信先として決定する。
【００６０】
本実施例では、上述したとおり、コンテンツデータの配信に先立ち、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションの確立を行う過程において、パーソナルコンピュータ１０４から印刷端末１０８へ、ＳＩＰサーバ１０６を介して、印刷条件を伝達する。
【００６１】
そこで、まず、印刷条件の伝達処理について説明する前に、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションの確立処理シーケンスについて、図６を用いて説明する。
【００６２】
図６は図１におけるパーソナルコンピュータ１０４と印刷端末１０８の間のセッション確立処理のシーケンスを示す説明図である。図６において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。
【００６３】
パーソナルコンピュータ１０４は、自己のＩＰアドレスを印刷端末１０８に伝えるために、印刷端末１０８に向かって送信するＩＮＶＩＴＥリクエストのボディの中に、パーソナルコンピュータ１０４のＩＰアドレスを含ませる。一方、印刷端末１０８も、自己のＩＰアドレスをパーソナルコンピュータ１０４に伝えるために、パーソナルコンピュータ１０４に向かって送信する２００  ＯＫレスポンスのボディの中に、印刷端末１０８のＩＰアドレスを含ませる。
【００６４】
こうして、パーソナルコンピュータ１０４から送信したＡＣＫリクエストが、印刷端末１０８に到達したら、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションは確立されたことになる。
【００６５】
その後、パーソナルコンピュータ１０４は、２００  ＯＫレスポンスより取得した印刷端末１０８のＩＰアドレスに基づいて、印刷端末１０８に、ＳＩＰサーバ１０６を介することなく、直接アクセスして、図１の白抜き矢印１２２で示すように、ＨＴＴＰに従ってコンテンツデータをＰＵＳＨ型で配信する。
【００６６】
印刷端末１０８は、配信されたコンテンツデータの受信が完了したら、再び、ＳＩＰに従って、ＢＹＥリクエストをＳＩＰサーバ１０６を介してパーソナルコンピュータ１０４に送信する。パーソナルコンピュータ１０４は、ＢＹＥリクエストを受信すると、２００  ＯＫレスポンスを、ＳＩＰサーバ１０６を介して印刷端末１０８に返す。これにより、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションが解消される。
【００６７】
以上が、セッション確立処理のシーケンスである。このようなセッション確立を行う過程において、本実施例では、パーソナルコンピュータ１０４から印刷端末１０８へＩＮＶＩＴＥリクエストを送信する際に、そのボディの中に、伝達したい印刷条件を含ませて、送信するようにしている。
【００６８】
ＳＩＰでは、装置間におけるセッションの確立を行う際、メディア・セッションの内容を記述するのに、一般に、ＳＤＰ（Session Description Protocol）を用いている。本実施例では、この既存のＳＤＰに対し、送信すべき印刷条件について、図７に示すような対応付けをなすようにしている。
【００６９】
図７は既存のＳＤＰと印刷条件との対応関係を示す説明図である。図７において、「印刷条件タイプ」は、ＳＤＰの規定で「ペイロードタイプ」と呼ばれるものに相当する。なお、印刷色については、既存のＳＤＰから独自の拡張を行っており、印刷条件としては、カラー印刷またはモノクロ印刷の何れか一方を指定するものとする。
【００７０】
また、以下の説明は、ＳＤＰオファ／アンサモデルに基づいて行うものとする。ここで、オファ／アンサモデルに簡単に説明する。まず、セッションを確立する２つのＳＩＰ  ＵＡ（ユーザエージェント）をそれぞれ、オファ側（Offer：提案者），アンサ側（Answer：回答者）とする。そして、オファ側から２者間で確立するセッションの提案となるセッション／メディア情報を含むＳＤＰ記述文書（オファ）を送信し、この提案を受けてアンサ側が回答となるセッション／メディア情報を含むＳＤＰ記述文書（アンサ）を返信する。この一連のメッセージ交換によって、セッションの確立を行うフレームワークが「オファ／アンサモデル」である。従って、本実施例では、オファ側とは、送信側、すなわち、パーソナルコンピュータ１０４を指し、アンサ側とは、受信側、すなわち、印刷端末１０８を指す。
【００７１】
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、配信したい印刷コンテンツとして、１つの印刷コンテンツＣが用意されており、その印刷コンテンツＣを印刷端末側で印刷させる際の印刷条件として、以下の２つの印刷条件を指定することが可能となっているものとする。なお、印刷条件タイプは、図７に示した内容と対応している。
ａ．印刷条件タイプ０：Ａ４，カラー，品質レベル１
ｂ．印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１
【００７２】
また、本実施例では、上記印刷コンテンツＣとして、印刷条件毎に、その印刷条件に応じたコンテンツデータがそれぞれ用意されているものとする。
ａ．印刷条件タイプ０：Ａ４，カラー，品質レベル１
→コンテンツデータ：image_a4_color.jpg
ｂ．印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１
→コンテンツデータ：image_b5_gray.jpg
【００７３】
但し、本実施例では、オファ側（送信側）からアンサ側（受信側）へは、１つの印刷コンテンツについて、１つの印刷条件しか伝達できないものとする。従って、用意した印刷コンテンツＣについては、上記した指定可能な２つの印刷条件のうち、１つの印刷条件しか印刷端末１０８へ送信することができない。そこで、本実施例では、上記２つの印刷条件のうち、デフォルトの印刷条件として、ａの「印刷条件タイプ０：Ａ４，カラー，品質レベル１」が設定されているものとし、この印刷条件をまず印刷端末１０８へ伝達するものとする。
【００７４】
図８は図１のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。図８において、左側は、オファ側、すなわち、パーソナルコンピュータ１０４での処理を示し、右側は、アンサ側、すなわち、印刷端末１０８での処理を示している。
【００７５】
オファ側（送信側）では、まず、印刷コンテンツＣについて、伝達したい印刷条件があるか否かを判断し（ステップＳ１０２）、この場合、伝達したい印刷条件があるので、ステップＳ１０４に処理が進む。そして、オファ側（送信側）では、伝達したい印刷条件として、デフォルトの「印刷条件タイプ０：Ａ４，カラー，品質レベル１」を、ＳＤＰによって、ＩＮＶＩＴＥリクエストのボディに記述する（ステップＳ１０４）。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
【００７６】
ここで、「m=」行（１行目）の最後尾に記載されている数字の部分が、ＳＤＰにおけるペイロードタイプを指定する部分であり、本実施例では、印刷条件タイプを指定する部分となっている。従って、この場合、数字は「0」であり、「印刷条件タイプ０」であることを表している。また、２〜３行目には、この「0」についての設定内容が記載されている。
【００７７】
次に、オファ側（送信側）では、こうして得られたＩＮＶＩＴＥリクエストを、アンサ側（受信側）に対して送信する（ステップＳ１０６）。この後、オファ側（送信側）は、アンサ側（受信側）からのレスポンスの受信待ちの状態となる（ステップＳ１０８）。
【００７８】
一方、オファ側（送信側）からのリクエストの受信待ちの状態にあった（ステップＳ１１６）アンサ側（受信側）では、オファ側（送信側）から送信されてきたＩＮＶＩＴＥリクエストを受信すると、そのボディ内のＳＤＰによる記述内容を解析し、記述されている印刷条件について自身が対応可能（すなわち、印刷可能）であるかどうかを判断する（ステップＳ１１８）。具体的には、まず、「m=」行の最後尾に記載されている数字を評価する。今、その数字として、「0」が指定されているため、アンサ側（受信側）は、オファ側（送信側）から伝達された印刷条件は、「印刷条件タイプ０：Ａ４，品質レベル１」であると認識する。さらに、２行下に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
【００７９】
そこで、判断の結果、その印刷条件について、アンサ側（受信側）で対応可能な場合は、その印刷条件を保持する（ステップＳ１２０）。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、その印刷条件をメモリ３４内にコンテンツ情報３８の一部として保存する。
【００８０】
さらに、アンサ側（受信側）では、その印刷条件を、ＳＤＰによって、２００  ＯＫレスポンスのボディに記述する（ステップＳ１２１）。すなわち、オファ側（送信側）から伝達されたＳＤＰによる記述内容を、２００  ＯＫレスポンスのボディにコピーする。このときのＳＤＰによる記述内容は、オファ側（送信側）からのＩＮＶＩＴＥリクエストにおける記述内容と同じで、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
【００８１】
次に、アンサ側（受信側）では、こうして得られた２００  ＯＫレスポンスを、オファ側（送信側）に返信する（ステップＳ１２２）。この後、アンサ側（受信側）では、コンテンツデータの受信待ちの状態（受信待機）となる（ステップＳ１２４）。
【００８２】
反対に、ステップＳ１１８の判断の結果、上記印刷条件について、アンサ側（受信側）で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する（ステップＳ１３０）。
【００８３】
次に、アンサ側（受信側）では、生成したエラーレスポンスを、オファ側（送信側）に返信する（ステップＳ１３２）。この後、アンサ側（受信側）では、ＳＩＰによる通信を終了する（ステップＳ１３４）。
【００８４】
一方、アンサ側（受信側）からのレスポンスの受信待ちとなっていたオファ側（送信側）では、アンサ側（受信側）からのレスポンスが返信されてくると、そのレスポンスが、２００  ＯＫレスポンスであるかどうかの判断をする（ステップＳ１１０）。
【００８５】
判断の結果、２００  ＯＫレスポンスである場合は、コンテンツデータの送信を開始する（ステップＳ１１２）。具体的には、前述したとおり、印刷コンテンツＣとして、印刷条件「印刷条件タイプ０：Ａ４，カラー，品質レベル１」に対応して用意されているコンテンツデータは、「image_a4_color.jpg」であるので、このコンテンツデータがアンサ側（受信側）に送信される。
【００８６】
これに対し、コンテンツデータの受信待ちの状態であったアンサ側（受信側）は、送信されてきたコンテンツデータの受信を開始する（ステップＳ１２６）。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８では、パーソナルコンピュータ１１２のＣＰＵ３０が、通信部３２を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ３４にそのコンテンツデータ３６を保存する。
【００８７】
受信が完了した後（ステップＳ１２８）、アンサ側（受信側）では、オファ側（送信側）からの次の印刷コンテンツの受信待ちの状態（オファ側からのリクエスト受信待ちの状態）となる（ステップＳ１１６）。同時に、ステップＳ１２２において保持していた印刷条件、すなわち、「印刷条件タイプ０：Ａ４，カラー，品質レベル１」に従って、コンテンツデータに基づく印刷を開始する。具体的には、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、メモリ３４からコンテンツデータ３６を読み出すと共に、コンテンツ情報３８に含まれる印刷条件（すなわち、オファ側（送信側）から伝達された印刷条件）を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ１１４において印刷実行可能なデータ形式に変換する。ＣＰＵ３０は、印刷命令と共に、変換後のコンテンツデータをプリンタ１１４に送信すると、プリンタ１１４は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
【００８８】
こうして、アンサ側（受信側）である印刷端末１０８では、配信されたコンテンツデータについて、オファ側（送信側）から伝達された印刷条件に従った印刷結果を得ることができる。
【００８９】
一方、オファ側（送信側）において、上記判断の結果、２００  ＯＫレスポンスでない場合、すなわち、アンサ側（受信側）から返信されてきたレスポンスがエラーレスポンスである場合には、オファ側（送信側）では、デフォルトの印刷条件である「印刷条件タイプ０：Ａ４，カラー，品質レベル１」以外に、伝達したい印刷条件として、指定可能な印刷条件があるかどうかを判断する（ステップＳ１０２）。
【００９０】
前述したとおり、指定可能な印刷条件として、デフォルトの印刷条件である、ａの「印刷条件タイプ０：Ａ４，カラー，品質レベル１」以外に、ｂの「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」があるため、オファ側（送信側）では、再度、伝達したい印刷条件として、「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」を、ＳＤＰによって、ＩＮＶＩＴＥリクエストのボディに記述して（ステップＳ１０４）、そのＩＮＶＩＴＥリクエストを、アンサ側（受信側）に送信する（ステップＳ１０６）。
【００９１】
このときのＳＤＰによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=fmtp:gray
------------------------
この後の処理については、上記したステップＳ１０８以降の処理と同じになる。
【００９２】
なお、ステップＳ１０２における判断の結果、例えば、デフォルトの印刷条件である「印刷条件タイプ０：Ａ４，カラー，品質レベル１」以外に、指定可能な印刷条件が無かった場合や、あるいは、再度伝達した印刷条件「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」でもってしても、アンサ側（受信側）において対応が不可能な場合は、ＳＩＰによる通信を終了する（ステップＳ１１４）。
【００９３】
Ａ−３．実施例の効果：
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションの確立を行う過程において、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、ＳＩＰサーバ１０６を介して、印刷条件を伝達することができる。従って、アンサ側（受信側）である印刷端末１０８では、配信されたコンテンツデータについて、オファ側（送信側）から伝達された印刷条件に従って印刷を行うことができるため、アンサ側（受信側）において、送信側ユーザの希望に沿った印刷結果を出力させることができる。
【００９４】
Ｂ．第２の実施例：
上記した第１の実施例においては、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、印刷条件を伝達する際に、１つの印刷コンテンツについては、１つの印刷条件しか伝達できないものとしていた。これに対し、本実施例では、オファ側（送信側）からアンサ側（受信側）へ、１つの印刷コンテンツについて、複数の印刷条件を伝達することを可能とし、アンサ側（受信側）では、それら複数の印刷条件の中から対応可能な印刷条件をオファ側（送信側）へ返信するものである。
【００９５】
Ｂ−１．実施例の構成：
本実施例において、コンテンツ伝送システムの構成自体は、図１に示した第１の実施例の場合と同じであり、また、システムの構成要素である各装置の構成自体も、図２〜図５に示した第１の実施例の場合と同じであるので、それらについての説明は省略する。
【００９６】
Ｂ−２．実施例の動作：
上記したとおり、本実施例が、第１の実施例と異なるのは印刷条件の伝達処理であり、その他の動作内容は第１の実施例と同様であるため、以下の説明では、異なる点を中心に説明することとする。
【００９７】
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、配信したい印刷コンテンツとして、１つの印刷コンテンツＣが用意されており、その印刷コンテンツＣを印刷端末側で印刷させる際の印刷条件として、以下の３つの印刷条件を指定することが可能となっているものとする。なお、印刷条件タイプは、図７に示した内容と対応している。
ａ．印刷条件タイプ０：Ａ４，カラー，品質レベル１
ｂ．印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１
ｃ．印刷条件タイプ７：Ｌ判，カラー，品質レベル２
【００９８】
また、本実施例では、上記印刷コンテンツＣとして、印刷条件毎に、その印刷条件に応じたコンテンツデータがそれぞれ用意されているものとする。
ａ．印刷条件タイプ０：Ａ４，カラー，品質レベル１
→コンテンツデータ：image_a4_color.jpg
ｂ．印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１
→コンテンツデータ：image_b5_gray.jpg
ｃ．印刷条件タイプ７：Ｌ判，カラー，品質レベル２
→コンテンツデータ：image_l_color.jpg
【００９９】
なお、本実施例では、上記したとおり、オファ側（送信側）からアンサ側（受信側）へは、１つの印刷コンテンツについて、複数の印刷条件を伝達することが可能となっている。従って、本実施例では、用意した印刷コンテンツＣについては、上記した指定可能な３つの印刷条件の全てを印刷端末１０８へ伝達するものとする。
【０１００】
図９は本実施例のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。図９においても、図８の場合と同様に、左側は、オファ側、すなわち、パーソナルコンピュータ１０４での処理を示し、右側は、アンサ側、すなわち、印刷端末１０８での処理を示している。
【０１０１】
オファ側（送信側）では、まず、印刷コンテンツＣについて、伝達したい印刷条件として、上記した指定可能な３つの印刷条件の全てを取得し（ステップＳ２０２）、それら印刷条件を、ＳＤＰによって、ＩＮＶＩＴＥリクエストのボディに記述する（ステップＳ２０４）。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
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=」行（１行目）の最後尾に記載されている数字の部分は、上述したとおり、印刷条件タイプを指定する部分となっており、この場合、数字は「0」，「3」，「7」であって、「印刷条件タイプ０」「印刷条件タイプ３」，「印刷条件タイプ７」であることを表している。「m=」行に続く、「a=」行（２〜７行目）には、各数字に対応する設定内容が記載されている。すなわち、２〜３行目には、この「0」についての設定内容が、４〜５行目には、この「3」についての設定内容が、６〜７行目には、この「7」についての設定内容が、それぞれ記載されている。
【０１０３】
次に、オファ側（送信側）では、こうして得られたＩＮＶＩＴＥリクエストを、アンサ側（受信側）に対して送信する（ステップＳ２０６）。この後、オファ側（送信側）は、アンサ側（受信側）からのレスポンスの受信待ちの状態となる（ステップＳ２０８）。
【０１０４】
一方、オファ側（送信側）からのリクエストの受信待ちの状態にあった（ステップＳ２１８）アンサ側（受信側）では、オファ側（送信側）から送信されてきたＩＮＶＩＴＥリクエストを受信すると、そのボディ内のＳＤＰによる記述内容を解析し、記述されている印刷条件について自身が対応可能（すなわち、印刷可能）であるかどうかを判断する（ステップＳ２２０）。具体的には、ボディ内のＳＤＰによる記述内容のうち、まず、前述した行番号の１行目に当たる「m=」行について解析する。
-----------------------------------------
1 :   m=audio 49170 RTP/AVP 0 3 7
-----------------------------------------
【０１０５】
ＳＤＰの規定では、この「m=」行の最後尾に記載されている数字の部分（上記の例では「0」，「3」，「7」）は優先順位となっており、アンサ側（受信側）では、この順番で評価を行う。
【０１０６】
そこで、アンサ側（受信側）では、まず、１番目の数字を評価する。今、１番目の数字として「0」が指定されているため、アンサ側（受信側）では、印刷条件は「印刷条件タイプ０：Ａ４，品質レベル１」であると認識する。さらに、この「0」についての設定内容は、前述したとおり行番号の２〜３行目に記載されており、３行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
【０１０７】
そして、アンサ側（受信側）では、この１番目の印刷条件、すなわち、「印刷条件タイプ０：Ａ４，カラー，品質レベル１」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その１番目の印刷条件を保持する（ステップＳ２２２）。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、その１番目の印刷条件をメモリ３４内にコンテンツ情報３８の一部として保存する。
【０１０８】
さらに、アンサ側（受信側）では、その１番目の印刷条件を、ＳＤＰによって、２００  ＯＫレスポンスのボディに記述する（ステップＳ２２３）。このときのＳＤＰによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=fmtp:color
------------------------
【０１０９】
次に、アンサ側（受信側）では、こうして得られた２００  ＯＫレスポンスを、オファ側（送信側）に返信する（ステップＳ２２４）。この後、アンサ側（受信側）では、コンテンツデータの受信待ちの状態（受信待機）となる（ステップＳ２２６）。なお、このように、アンサ側（受信側）では、複数の印刷条件をオファ側（送信側）に返信することはない。
【０１１０】
通常、ＶｏＩＰ（Voice over Internet Protocol）などに利用されるソフトフォンや機器などの場合、「m=」行は、１つのメディアについて１つしか存在しない。例えば、以下の記述は、音声と映像の送受信を行うための記述であるが、このように異なるメディア（音声と映像）を同時に送受信するためには、各メディアについて「m=」行をそれぞれ記述し、各「m=」行の下に、それぞれ、そのメディアに関する属性を記述することになる。
-----------------
m=audio ・・・
a=rtpmap・・・
a=・・・
m=video・・・
a=rtpmap・・・
a=・・・
-----------------
【０１１１】
一方、例えば、以下のような記述（音声の送受信のために２つのセッションを確立する）は、許されていないことが多い。この場合、音声通話が正しく行われなくなるからである。
-----------------
m=audio ・・・
a=rtpmap・・・
a=・・・
m=audio・・・
a=rtpmap・・・
a=・・・
-----------------
【０１１２】
そこで、本実施例では、印刷条件を「m=audio・・・」と記載し、見かけ上は音声メディアとして、１つだけ指定可能なものとして扱うこととする。
【０１１３】
さて、上記判断の結果、１番目の印刷条件、すなわち、「印刷条件タイプ０：Ａ４，カラー，品質レベル１」について、アンサ側（受信側）で対応が不可能な場合は、次に、２番目の数字を評価する。今、２番目の数字として「3」が指定されているため、アンサ側（受信側）では、印刷条件は「印刷条件タイプ３：Ｂ５，品質レベル１」であると認識する。さらに、この「3」についての設定内容は、前述したとおり行番号の４〜５行目に記載されており、５行目に記載された「a=fmtp:gray」から、モノクロでの印刷であると認識する。
【０１１４】
そして、アンサ側（受信側）では、この２番目の印刷条件、すなわち、「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その２番目の印刷条件を保持する。
【０１１５】
さらに、アンサ側（受信側）では、その２番目の印刷条件を、ＳＤＰによって、２００  ＯＫレスポンスのボディに記述して、その２００  ＯＫレスポンスを、オファ側（送信側）に返信する。
【０１１６】
このときのＳＤＰによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=fmtp:gray
------------------------
【０１１７】
また、上記判断の結果、２番目の印刷条件について、アンサ側（受信側）で対応が不可能な場合は、続いて、３番目の数字を評価する。今、３番目の数字として「7」が指定されているため、アンサ側（受信側）では、印刷条件は「印刷条件タイプ７：Ｌ判，品質レベル２」であると認識する。さらに、この「7」についての設定内容は、前述したとおり行番号の６〜７行目に記載されており、７行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識する。
【０１１８】
そして、アンサ側（受信側）では、この３番目の印刷条件、すなわち、「印刷条件タイプ７：Ｌ判，カラー，品質レベル２」について、自身が対応可能であるかどうかを判断する。判断の結果、対応可能な場合は、その３番目の印刷条件を保持する。
【０１１９】
さらに、アンサ側（受信側）では、その３番目の印刷条件を、ＳＤＰによって、２００  ＯＫレスポンスのボディに記述して、その２００  ＯＫレスポンスを、オファ側（送信側）に返信する。
【０１２０】
このときのＳＤＰによる記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。
------------------------
m=audio 49170 RTP/AVP 7
a=rtpmap:7 LPC/8000
a=fmtp:color
------------------------
【０１２１】
さらに、上記判断の結果、３番目の印刷条件についても、アンサ側（受信側）で対応が不可能な場合、すなわち、オファ側（送信側）から伝達された全ての印刷条件について、アンサ側（受信側）で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する（ステップＳ２３２）。
【０１２２】
次に、アンサ側（受信側）では、生成したエラーレスポンスを、オファ側（送信側）に返信する（ステップＳ２３４）。この後、アンサ側（受信側）では、ＳＩＰによる通信を終了する（ステップＳ２３６）。
【０１２３】
一方、アンサ側（受信側）からのレスポンスの受信待ちとなっていたオファ側（送信側）では、アンサ側（受信側）からのレスポンスが返信されてくると、そのレスポンスが、２００  ＯＫレスポンスであるかどうかの判断をする（ステップＳ２１０）。
【０１２４】
判断の結果、２００  ＯＫレスポンスである場合は、そのボディ内のＳＤＰによる記述内容を解析し（ステップＳ２１２）、その記述内容に基づく印刷条件に対応したコンテンツデータの送信を開始する（ステップＳ２１４）。例えば、２００  ＯＫレスポンスのボディに、アンサ側（受信側）で対応可能な印刷条件として、上記した２番目の印刷条件、すなわち、「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」が記述されているものとすると、印刷コンテンツＣとして、その印刷条件「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」に対応して用意されているコンテンツデータは、上述したとおり「image_b5_gray.jpg」であるので、このコンテンツデータがアンサ側（受信側）に送信される。
【０１２５】
これに対し、コンテンツデータの受信待ちの状態であったアンサ側（受信側）は、送信されてきたコンテンツデータの受信を開始する（ステップＳ２２８）。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８では、パーソナルコンピュータ１１２のＣＰＵ３０が、通信部３２を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ３４にそのコンテンツデータ３６を保存する。
【０１２６】
受信が完了した後（ステップＳ２３０）、アンサ側（受信側）では、オファ側（送信側）からの次の印刷コンテンツの受信待ちの状態（オファ側からのリクエスト受信待ちの状態）となる（ステップＳ２１８）。同時に、ステップＳ２２２において保持していた印刷条件、すなわち、「印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１」に従って、コンテンツデータに基づく印刷を開始する。具体的には、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、メモリ３４からコンテンツデータ３６を読み出すと共に、コンテンツ情報３８に含まれる印刷条件（すなわち、オファ側（送信側）から伝達された印刷条件）を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ１１４において印刷実行可能なデータ形式に変換する。ＣＰＵ３０は、印刷命令と共に、変換後のコンテンツデータをプリンタ１１４に送信すると、プリンタ１１４は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
【０１２７】
こうして、アンサ側（受信側）である印刷端末１０８では、オファ側（送信側）から伝達された複数の印刷条件の中から、アンサ側（受信側）で対応可能な印刷条件を選択し、配信されたコンテンツデータについて、その選択した印刷条件に従った印刷結果を得ることができる。
【０１２８】
一方、オファ側（送信側）において、上記判断の結果、２００  ＯＫレスポンスでない場合、すなわち、アンサ側（受信側）から返信されてきたレスポンスがエラーレスポンスである場合には、アンサ側（受信側）で何れの印刷条件も対応が不可能であったので、ＳＩＰによる通信を終了する（ステップＳ２１６）。
【０１２９】
Ｂ−３．実施例の効果：
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションの確立を行う過程において、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、ＳＩＰサーバ１０６を介して、複数の印刷条件を伝達することができる。また、アンサ側（受信側）では、その複数の印刷条件の中から、自身で対応可能な印刷条件を選択して、オファ側（送信側）に回答し、オファ側（送信側）では、その回答された印刷条件に対応したコンテンツデータをアンサ側（受信側）へ送信することができる。従って、アンサ側（受信側）である印刷端末１０８では、複数の印刷条件の中から選択した印刷条件に従って、コンテンツデータに基づき印刷を行うことができるため、アンサ側（受信側）において、送信側ユーザの希望だけでなく、受信側ユーザの希望にも沿った印刷結果を出力させることができる。
【０１３０】
Ｃ．第３の実施例：
上記した第１及び第２の実施例においては、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、１つの印刷コンテンツしか同時に送信できないものとしていた。これに対し、本実施例では、オファ側（送信側）からアンサ側（受信側）へ、複数の印刷コンテンツを同時に送信することを可能とするものである。なお、ここで、「複数の印刷コンテンツを同時に送信する」とは、確立された同じセッション内において、複数の印刷コンテンツのデータを順次送信するという意味である。
【０１３１】
Ｃ−１．実施例の構成：
本実施例において、コンテンツ伝送システムの構成自体は、図１に示した第１の実施例の場合と同じであり、また、システムの構成要素である各装置の構成自体も、図２〜図５に示した第１の実施例の場合と同じであるので、それらについての説明は省略する。
【０１３２】
Ｃ−２．実施例の動作：
本実施例が、第１の実施例と異なるのは、実質的には印刷条件の伝達処理であり、その他の動作内容は第１の実施例と同様であるため、以下の説明では、異なる点を中心に説明することとする。
【０１３３】
それでは、本実施例における印刷条件の伝達処理について説明する。本実施例では、送信側において、以下に示すとおり、配信したい印刷コンテンツとして、３つの印刷コンテンツＣ１〜Ｃ３が用意されており、それら印刷コンテンツＣ１〜Ｃ３について、印刷端末側で印刷させる際の印刷条件がそれぞれ対応して用意されているものとする。なお、印刷条件タイプは、図７に示した内容と対応している。
ａ．印刷コンテンツＣ１
→コンテンツデータ：image1.jpg
→印刷条件タイプ０：Ａ４，カラー，品質レベル１
ｂ．印刷コンテンツＣ２
→コンテンツデータ：image2.jpg
→印刷条件タイプ３：Ｂ５，モノクロ，品質レベル１
ｃ．印刷コンテンツＣ３
→コンテンツデータ：image3.jpg
→印刷条件タイプ７：Ｌ判，カラー，品質レベル２
【０１３４】
なお、本実施例では、上記したとおり、オファ側（送信側）からアンサ側（受信側）へは、複数の印刷コンテンツを同時に送信することが可能となっている。従って、本実施例では、オファ側（送信側）で用意した３つの印刷コンテンツＣ１〜Ｃ３中から、アンサ側（受信側）で対応可能な複数の印刷コンテンツをアンサ側（受信側）に同時に送信するものとする。
【０１３５】
図１０は本実施例のコンテンツ伝送システムにおける印刷条件伝達処理のうち、オファ側の処理の流れを示すフローチャートであり、図１１は同じく印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。すなわち、図１０はパーソナルコンピュータ１０４での処理を示し、図１１は印刷端末１０８での処理を示している。
【０１３６】
オファ側（送信側）では、まず、配信したい３つの印刷コンテンツＣ１〜Ｃ３について、それぞれ、そのファイル名と、対応する印刷条件と、を取得し（ステップＳ３０２）、それらファイル名及び印刷条件を、ＳＤＰによって、ＩＮＶＩＴＥリクエストのボディに記述する（ステップＳ３０４）。具体的な記述内容は、例えば、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
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=」行（第１行）の最後尾に記載されている数字の部分は、上述したとおり、印刷条件タイプを指定する部分となっており、この場合、数字は「0」，「3」，「7」であって、「印刷条件タイプ０」「印刷条件タイプ３」，「印刷条件タイプ７」であることを表している。「m=」行に続く、「a=」行（２〜１０行目）には、各数字に対応する設定内容が記載されている。すなわち、２〜４行目には、この「0」についての設定内容が、５〜７行目には、この「3」についての設定内容が、８〜１０行目には、この「7」についての設定内容が、それぞれ記載されている。
【０１３８】
第２の実施例の場合に比較して、これら記載内容のうち、４，７，１０行目に、配信したい印刷コンテンツのファイル名が追加されている点で異なる。これら４，７，１０行目の記述は、通常のＳＤＰの規定にはない、独自の拡張となる。
【０１３９】
前述したように、通常のＳＤＰの規定では、「m=」行の最後尾の数字（ペイロードタイプの指定）部分が優先順位となっている。上記した第２の実施例では、アンサー側（受信側）において、この順番で評価を行い、対応可能な印刷条件（メディア設定）があった時点で２００  ＯＫレスポンスをオファ側（送信側）に返信するようにしていた。従って、アンサ側（受信側）では、複数の印刷条件（メディア設定）を返信することはなかったい。そのため、第２の実施例では、オファ側（送信側）からアンサ側（受信側）へ一度に送信可能な印刷コンテンツは１つのみということになっていた。
【０１４０】
これに対し、本実施例では、ＳＤＰの規定を独自に拡張することで、オファ側（送信側）からアンサ側（受信側）へ、複数の印刷コンテンツの同時送信に対応するようにしている。具体的には、「m=」行の最後尾の数字部分は、優先順位として扱うのではなく、送信される印刷コンテンツの種別を示すものとする。
【０１４１】
従って、各数字に「0」，「3」，「7」に対応する印刷コンテンツ、及びその設定内容は以下の通りとなる。
「0」：
→印刷コンテンツＣ１
→コンテンツデータ：image1.jpg
→印刷条件タイプ０：Ａ４，カラー，品質レベル１
「3」：
→印刷コンテンツＣ２
→コンテンツデータ：image2.jpg
→印刷条件タイプ３：Ａ５，モノクロ，品質レベル１
「7」:
→印刷コンテンツＣ３
→コンテンツデータ：image3.jpg
→印刷条件タイプ７：Ｌ判，カラー，品質レベル２
【０１４２】
次に、オファ側（送信側）では、こうして得られたＩＮＶＩＴＥリクエストを、アンサ側（受信側）に対して送信する（ステップＳ３０６）。この後、オファ側（送信側）は、アンサ側（受信側）からのレスポンスの受信待ちの状態となる（ステップＳ３０８）。
【０１４３】
一方、オファ側（送信側）からのリクエストの受信待ちの状態にあった（ステップＳ３２０）アンサ側（受信側）では、オファ側（送信側）から送信されてきたＩＮＶＩＴＥリクエストを受信すると、そのボディ内のＳＤＰによる記述内容を解析し、自身が対応可能（すなわち、印刷可能）な印刷条件を持つ印刷コンテンツがあるかどうかを判断する（ステップＳ３２２）。具体的には、ボディ内のＳＤＰによる記述内容のうち、まず、前述した行番号の１行目に当たる「m=」行について解析する。
-----------------------------------------
1 :   m=audio 49170 RTP/AVP 0 3 7
-----------------------------------------
【０１４４】
アンサ側（受信側）では、１番目の数字「0」から順に評価を行い、続く「a=」行の解析も行いながら、その数字に対応する印刷コンテンツについて、設定されている印刷条件に従い、自身が対応可能であるか否かを判断する。例えば、１番目の数字「0」の場合、アンサ側（受信側）では、印刷条件が「印刷条件タイプ０：Ａ４，品質レベル１」であると認識し、この「0」についての設定内容は、前述したとおり行番号の２〜４行目に記載されているため、３行目に記載された「a=fmtp:color」から、カラーでの印刷であると認識し、４行目に記載された「a=file:image1.jpg」から、ファイル名が「image1.jpg」であると認識する。そして、アンサ側（受信側）では、このファイル名「image1.jpg」の印刷コンテンツについて、「印刷条件タイプ０：Ａ４，カラー，品質レベル１」に従い、自身が対応可能であるかどうかを判断することになる。
【０１４５】
本実施例では、例えば、以下に示すごとく、１番目の数字「0」及び３番目の数字「7」に対応する２つの印刷コンテンツについて、それぞれ、設定されている印刷条件に従い、アンサ側（受信側）で対応可能であるものとする。すなわち、アンサ側（受信側）において、対応可能な印刷コンテンツ及びその印刷条件は、以下の通りとなる。
「0」：
→印刷コンテンツＣ１
→コンテンツデータ：image1.jpg
→印刷条件タイプ０：Ａ４，カラー，品質レベル１
「7」:
→印刷コンテンツＣ３
→コンテンツデータ：image3.jpg
→印刷条件タイプ７：Ｌ判，カラー，品質レベル２
【０１４６】
そこで、アンサ側（受信側）では、それら対応可能な印刷コンテンツの印刷条件及びファイル名を保持する（ステップＳ３２４）。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、その印刷条件及びファイル名をメモリ３４内にコンテンツ情報３８の一部として保存する。なお、図５において、ファイル名については図示されていない。
【０１４７】
さらに、アンサ側（受信側）では、それら対応可能な印刷コンテンツの印刷条件及びファイル名を、ＳＤＰによって、２００  ＯＫレスポンスのボディに記述する（ステップＳ３２６）。記述内容は、以下のようになる。但し、印刷条件に関する部分のみを示した。また、先頭の数字は説明のために用いる行番号である。
-----------------------------------------
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
-----------------------------------------
【０１４８】
次に、アンサ側（受信側）では、こうして得られた２００  ＯＫレスポンスを、オファ側（送信側）に返信する（ステップＳ３２８）。この後、アンサ側（受信側）では、コンテンツデータの受信待ちの状態（受信待機）となる（ステップＳ３３０）。
【０１４９】
一方、ステップＳ３２２の判断の結果、何れの印刷コンテンツについても、設定されている印刷条件では、アンサ側（受信側）で対応が不可能な場合は、エラーレスポンスとして、「415 Unsupported Media Type」もしくは「488 Not Acceptable Here」レスポンスを生成する（ステップＳ３４２）。
【０１５０】
次に、アンサ側（受信側）では、生成したエラーレスポンスを、オファ側（送信側）に返信する（ステップＳ３４４）。この後、アンサ側（受信側）では、ＳＩＰによる通信を終了する（ステップＳ３４６）。
【０１５１】
一方、アンサ側（受信側）からのレスポンスの受信待ちとなっていたオファ側（送信側）では、アンサ側（受信側）からのレスポンスが返信されてくると、そのレスポンスが、２００  ＯＫレスポンスであるかどうかの判断をする（ステップＳ３１０）。
【０１５２】
判断の結果、２００  ＯＫレスポンスである場合は、そのボディ内のＳＤＰによる記述内容を解析し、その記述内容に基づいて、用意されている３つの印刷コンテンツＣ１〜Ｃ３の中から、送信すべき印刷コンテンツを決定し（ステップＳ３１２）、決定したコンテンツデータの送信を開始する（ステップＳ３１４）。具体的には、ボディ内のＳＤＰによる記述内容のうち、まず、以下に示す、前述した行番号の１行目に当たる「m=」行について解析し、それに続く「a=」行の解析を行う。
-----------------------------------------
1 :   m=audio 49170 RTP/AVP 0 7
-----------------------------------------
【０１５３】
解析の結果、オファ側（送信側）では、１番目の数字「0」及び３番目の数字「7」に対応する２つの印刷コンテンツＣ１，Ｃ３を、送信すべき印刷コンテンツであるとして決定する。また、本実施例では、決定したそれら印刷コンテンツについて、Ｃ１，Ｃ３の順で、コンテンツデータを送信することになる（ステップＳ３１４，Ｓ３１６）。すなわち、オファ側（送信側）から送信される印刷コンテンツ及びその印刷条件は、以下の通りとなる。
「0」：
→印刷コンテンツＣ１
→コンテンツデータ：image1.jpg
→印刷条件タイプ０：Ａ４，カラー，品質レベル１
「7」:
→印刷コンテンツＣ３
→コンテンツデータ：image3.jpg
→印刷条件タイプ７：Ｌ判，カラー，品質レベル２
【０１５４】
これに対し、コンテンツデータの受信待ちの状態であったアンサ側（受信側）は、送信されてきたコンテンツデータの受信を開始する（ステップＳ３３２）。すなわち、まず、ファイル名「image1.jpg」のコンテンツデータ（印刷コンテンツＣ１）を受信し、次に、ファイル名「image1.jpg」のコンテンツデータ（印刷コンテンツＣ３）を受信することになる。具体的には、図５に示すように、アンサ側（受信側）である印刷端末１０８では、パーソナルコンピュータ１１２のＣＰＵ３０が、通信部３２を介して、送信されてきたコンテンツデータを受信すると、一時的にメモリ３４にそのコンテンツデータ３６を保存する。
【０１５５】
そして、アンサ側（受信側）では、まず、印刷コンテンツＣ１のコンテンツデータ（ファイル名「image1.jpg」）の受信が完了したら（ステップＳ３３２）、ステップＳ３２４において保持していた、印刷コンテンツＣ１についての印刷条件、すなわち、「印刷条件タイプ０：Ａ４，カラー，品質レベル１」を取得し（ステップＳ３３４）、そのコンテンツデータに基づく印刷を開始する（ステップＳ３３６）。具体的には、アンサ側（受信側）である印刷端末１０８において、パーソナルコンピュータ１１２のＣＰＵ３０が、メモリ３４から、コンテンツ情報３８に含まれるファイル名に基づき、コンテンツデータ３６を読み出すと共に、コンテンツ情報３８に含まれる印刷条件を読み出し、その印刷条件に従って、コンテンツデータに所望の処理を施し、プリンタ１１４において印刷実行可能なデータ形式に変換する。ＣＰＵ３０は、印刷命令と共に、変換後のコンテンツデータをプリンタ１１４に送信すると、プリンタ１１４は、そのコンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
【０１５６】
同時に、アンサ側（受信側）では、受信すべき印刷コンテンツがあるかどうかを判断し（ステップＳ３２８）、ある場合には、コンテンツデータの受信待ちの状態（受信待機）を経て（ステップＳ３３０）、次の印刷コンテンツＣ３について、コンテンツデータ（ファイル名「image3.jpg」）の受信を開始する（ステップＳ３３２）。その後、アンサ側（受信側）では、受信が完了したら（ステップＳ３３２）、ステップＳ３２４において保持していた、印刷コンテンツＣ３についての印刷条件、すなわち、「印刷条件タイプ７：Ｌ判，カラー，品質レベル２」を取得し（ステップＳ３３４）、そのコンテンツデータに基づく印刷を開始する（ステップＳ３３６）。アンサ側（受信側）では、全ての印刷コンテンツについて、受信・印刷を完了したら、オファ側（送信側）からの次の印刷コンテンツの受信待ちの状態（オファ側からのリクエスト受信待ちの状態）となる（ステップＳ３２０）。
【０１５７】
こうして、アンサ側（受信側）である印刷端末１０８では、オファ側（送信側）から同時に送信された複数の印刷コンテンツについて、オファ側（送信側）から伝達された印刷条件に従った印刷結果を得ることができる。
【０１５８】
一方、オファ側（送信側）において、上記判断の結果、２００  ＯＫレスポンスでない場合、すなわち、アンサ側（受信側）から返信されてきたレスポンスがエラーレスポンスである場合には、アンサ側（受信側）で何れの印刷条件も対応が不可能であったので、ＳＩＰによる通信を終了する（ステップＳ３１８）。
【０１５９】
Ｃ−３．実施例の効果：
本実施例によれば、コンテンツデータの配信に先立って、パーソナルコンピュータ１０４と印刷端末１０８との間のセッションの確立を行う過程において、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、ＳＩＰサーバ１０６を介して、複数の印刷コンテンツについて、その印刷条件及びファイル名を伝達することができる。また、アンサ側（受信側）では、その複数の印刷コンテンツの中から、その印刷コンテンツについて設定されている印刷条件に従い、自身で対応可能な印刷コンテンツを選択して、オファ側（送信側）に回答し、オファ側（送信側）では、その回答された印刷コンテンツのコンテンツデータをアンサ側（受信側）へ送信することができる。この結果、オファ側（送信側）であるパーソナルコンピュータ１０４からアンサ側（受信側）である印刷端末１０８へ、複数の印刷コンテンツを同時に送信することができ、アンサ側（受信側）において、複数の印刷コンテンツについて、送信側ユーザ，受信側ユーザの双方の希望に沿った印刷結果を出力させることができる。
【０１６０】
Ｄ．第４の実施例：
上記した第１の実施例では、送信側において、配信したいコンテンツデータや、印刷端末側でそのコンテンツデータに基づき印刷させる際の印刷条件は、予め、それぞれ用意されており、図２に示したパーソナルコンピュータ１０４のメモリ１４に格納されていたが、本発明は、これに限定されるものではない。例えば、送信側において、画像をスキャナで読み取り、その読み取った画像データをコンテンツデータとすると共に、その画像を読み取った際の読取条件を、印刷端末側でそのコンテンツデータに基づき印刷させる際の印刷条件として用いるようにしてもよく、そのような実施例について、以下、説明する。
【０１６１】
Ｄ−１．実施例の構成：
図１２は本発明の第４の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
【０１６２】
図１２に示すとおり、本実施例のコンテンツ伝送システムが、第１の実施例におけるコンテンツ伝送システムと異なる点は、印刷コンテンツの配信を希望する送信側ユーザによって管理される送信端末２０４が、パーソナルコンピュータ２１２と、そのパーソナルコンピュータ２１２にＵＳＢケーブルなどで接続されたスキャナ２１４と、によって構成されている点である。なお、その他の構成は、第１の実施例と同じであるので、同一の符号を付し、それらについての説明は省略する。
【０１６３】
図１３は図１２における送信端末２０４の主要構成を示すブロック図である。パーソナルコンピュータ２１２は、図１３に示すように、プログラムを実行することにより種々の処理や制御を行うＣＰＵ５０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部５２と、プログラムを格納したり、データや情報を格納したりするためのメモリ５４と、キーボードやポインティングデバイスなどから成り、ユーザからの指示を入力するための入力部６０と、取得したデータや情報などを表示するためのモニタ６２と、外部接続されたスキャナ２１４などからデータを入力するための入力インタフェース（Ｉ／Ｆ）部６４と、を主として備えている。このうち、メモリ５４は、データや情報として、配信依頼情報５６や、コンテンツデータ５７や、読取条件設定情報５８などを格納することが可能である。
【０１６４】
なお、本実施例では、送信端末２０４の構成として、パーソナルコンピュータ２１２とそのパーソナルコンピュータ２１２にＵＳＢケーブルなどで直接接続されるスキャナ２１４と、で構成される形態を採用するようにしたが、送信端末の構成としては、種々の形態を採ることができる。
【０１６５】
例えば、スキャナ２１４に代えて、複合機を用いる形態であってもよい。または、パーソナルコンピュータ２１２と、そのパーソナルコンピュータ２１２にＬＡＮケーブルなどでＬＡＮを介して接続されたネットワーク対応の複合機もしくはスキャナと、で構成される形態であってもよい。または、パーソナルコンピュータ２１２と、そのパーソナルコンピュータ２１２にＬＡＮケーブルなどでＬＡＮを介して接続されたネットワークアダプタと、そのネットワークアダプタにＵＳＢケーブルなどで接続された複合機もしくはスキャナで構成される形態であってもよい。さらには、前述したようなＩＰ通信プリンティング対応の複合機のみで構成される形態であってもよい。
【０１６６】
また、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線ＬＡＮや、ブルートゥースや、赤外線など、無線で接続されてもよい。
【０１６７】
なお、本実施例において、スキャナ２１４は、請求項における画像読取部に、ＳＩＰサーバ１０６は、請求項におけるプレゼンスサーバに、それぞれ相当する。
【０１６８】
Ｄ−２．実施例の動作：
図１２に示すように、まず、送信端末２０４において、パーソナルコンピュータ２１２が、起動すると、ＳＩＰサーバ１０６に、ＳＩＰクライアントとしてアクセスして、登録要求を出し、自己のＳＩＰ  ＵＲＩやＩＰアドレスなどの情報を送信する（破線矢印１２６）。これにより、ＳＩＰサーバ１０６は、登録要求を受け付け、パーソナルコンピュータ２１２から送信された情報を、図３に示したように、登録情報２６としてメモリ２４に登録する。また、印刷端末１０８についても、同様に、その登録情報がＳＩＰサーバ１０６に登録されている。
【０１６９】
次に、送信側ユーザが、自己の管理する送信端末２０４において、図１３に示すパーソナルコンピュータ２１２の入力部６０を操作して、専用のプログラム（図示せず）を起動すると、ＣＰＵ５０は、そのプログラムを実行して、モニタ６２に読取条件設定画面（図示せず）を表示させる。続いて、送信側ユーザは、入力部６０を操作して、その読取条件設定画面内において、スキャナ２１４による画像の読み取りに関し、送信側ユーザが希望する読取条件を入力する。読取条件としては、用紙サイズ（すなわち、プレスキャンのサイズ、例えば、Ａ４，Ｂ５，Ｌ判など）や、読取色（カラー，モノクロなど）や、読取品質（品質レベル１，品質レベル２など）などが挙げられる。ＣＰＵ５０は、入力部６０を介して、読取条件が入力されると、その読取条件を読取条件設定情報５８としてメモリ５４に格納する。
【０１７０】
その後、送信側ユーザが、入力部６０を操作して、画像の読み取り開始を指示すると、ＣＰＵ５０は、メモリ５４から読取条件設定情報５８を読み出し、それに含まれている読取条件を取得する。そして、ＣＰＵ５０は、入力Ｉ／Ｆ部６４を介して、スキャナ２１４に対し、その読取条件を伝達する共に、画像の読み取り開始を命令し、それにより、スキャナ２１４は、その読取条件に従った画像の読み取りを開始する。その後、スキャナ２１４が、読み取った画像データを出力すると、ＣＰＵ５０は、その画像データを入力Ｉ／Ｆ部６４を介して受け取り、コンテンツデータ５７として、メモリ５４に格納する。
【０１７１】
また、送信側では、印刷コンテンツを配信したい配信先のリストが用意されており、パーソナルコンピュータ２１２のメモリ５４に、配信依頼情報５６として格納されている。そこで、ＣＰＵ５０は、その配信依頼情報５６を読み出し、それに含まれる配信先リストを解析する。配信先リストには、配信先として、印刷端末１０８などのＳＩＰ  ＵＲＩが記載されている。そして、ＣＰＵ５０は、その配信先リストに従って、例えば、まず、印刷端末１０８を、コンテンツデータの送信先として決定する。
【０１７２】
こうして、コンテンツデータの送信先が決定されると、送信端末２０４のパーソナルコンピュータ２１２は、第１の実施例で述べたとおり、送信先である印刷端末１０８との間のセッションの確立を行う。
【０１７３】
このセッションの確立を行うに際し、パーソナルコンピュータ２１２のＣＰＵ５０は、まず、メモリ５４から読取条件設定情報５８を読み出し、それに含まれている読取条件を取得する。そして、このセッション確立を行う過程において、ＣＰＵ５０は、取得した読取条件を、コンテンツデータに基づいて印刷を行う際の印刷条件として、印刷端末１０８へ送信する。送信の方法としては、第１の実施例で述べたとおり、ＩＮＶＩＴＥリクエストをパーソナルコンピュータ２１２から印刷端末１０８へ送信する際に、ＳＤＰにより、そのＩＮＶＩＴＥリクエストのボディに印刷条件（読取条件）を記述することによって送信する。例えば、読取条件が、「用紙サイズ：Ａ４，読取色：カラー，読取品質：品質レベル１」である場合には、印刷条件として、図７に示した「印刷条件タイプ０：Ａ４，カラー，品質レベル１」をＩＮＶＩＴＥリクエストのボディに記述することになる。
【０１７４】
その後は、第１の実施例で述べたとおり、パーソナルコンピュータ２１２は、印刷端末１０８との間のセッションの確立を完了したら、メモリ５４に格納していたコンテンツデータ５７をＨＴＴＰを用いて印刷端末１０８へ送信し、印刷端末１０８では、先に受け取った印刷条件に従い、コンテンツデータに基づいて印刷を行い、印刷コンテンツを出力する。
【０１７５】
Ｄ−３．実施例の効果：
本実施例では、送信端末２０４において、画像をスキャナ２１４で読み取り、その読み取った画像データをコンテンツデータ５７として印刷端末１０８へ配信すると共に、その画像を読み取った際の読取条件を、印刷端末１０８側でそのコンテンツデータに基づき印刷させる際の印刷条件として、印刷端末１０８との間のセッションの確立を行う過程において、印刷端末１０８へ送信している。従って、印刷端末１０８では、配信されたコンテンツデータについて、送信された印刷条件、すなわち、画像を読み取った際の読取条件に従って印刷を行うことができるため、送信側ユーザの希望に沿った印刷結果を出力させることができる。
【０１７６】
Ｅ．変形例：
なお、本発明は上記した実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。
【０１７７】
上記した各実施例においては、印刷条件は、コンテンツデータ１７とは、別データとして、印刷条件データベースに１８において管理されていたが、本発明はこれに限定されるものではない。例えば、印刷条件は、コンテンツデータ自身のヘッダに埋め込まれていてもよい。また、印刷条件は、コンテンツデータとは関係なく、送信側（オファ側）機器もしくはソフトウェアにデフォルト設定として保持されていてもよい。
【０１７８】
上記した第１及び第２の実施例では、オファ側（送信側）では、同一の印刷コンテンツについて、印刷条件毎に、その印刷条件に応じたコンテンツデータを用意していたが、本発明はこれに限定されるものではない。例えば、オファ側（送信側）において、高画質なコンテンツデータを用意し、アンサ側（受信側）に送信する際に、そのコンテンツデータを、アンサ側（受信側）で対応可能な印刷条件に最適な形式（解像度や色など）に変換して、送信するようにしてもよい。また、オファ側（送信側）であるパーソナルコンピュータ１０４に直接またはネットワークを介して接続する専用サーバを用意して、上記印刷条件に適した形式へのコンテンツデータの変換を、その専用サーバにおいて実行させるようにしてもよい。
【０１７９】
上記した第３の実施例では、アンサ側（受信側）において、ステップＳ３２４で、対応可能な印刷コンテンツの印刷条件及びファイル名を保持するようにしていたが、本発明はこれに限定されるものではない。例えば、ステップＳ３１４，Ｓ３３２で、オファ側（送信側）からアンサ側（受信側）へ、それら印刷コンテンツのコンテンツデータを送信する際に、そのコンテンツデータのヘッダに印刷条件を埋め込んで送信し、アンサ側（受信側）において、そのコンテンツデータを受信した際に、そのコンテンツデータのヘッダを解析して、埋め込まれていた印刷条件を取得するようにしてもよい。この場合、アンサ側（順側）では、ステップＳ３２４で、印刷条件及びファイル名を保持する必要はない。
【０１８０】
上記した第４の実施例では、読取条件を設定し、その読取条件に従ってスキャナ２１４による画像の読み取りを行うようにしていたが、複数の異なる読取条件を設定して、同じ画像について、それぞれ、異なる読取条件で画像の読み取りを行い、複数のコンテンツデータを取得するようにしてもよい。すなわち、この場合、同一の画像について、複数の読取条件が設定され、それら読取条件毎に、その読取条件に応じたコンテンツデータが取得されることになる。第４の実施例では、上述したとおり、読取条件は印刷条件として扱われるので、言い換えれば、同一の印刷コンテンツについて、複数の印刷条件が用意され、それら印刷条件毎に、その印刷条件に応じたコンテンツデータが用意されたこととなる。
【０１８１】
よって、第１の実施例で述べたように、パーソナルコンピュータ２１２から印刷端末１０８へ送信された印刷条件（すなわち、読取条件）が、印刷端末１０８において対応が不可能な場合には、別の印刷条件（すなわち、読取条件）を印刷端末１０８へ送信するようにすることも可能となる。また、第２の実施例で述べたように、パーソナルコンピュータ２１２から印刷端末１０８へ、１つの印刷コンテンツについて、複数の印刷条件（すなわち、複数の読取条件）を送信して、印刷端末１０８では、それら複数の印刷条件の中から対応可能な印刷条件をパーソナルコンピュータ２１２へ返信するようにすることも可能となる。
【０１８２】
また、第４の実施例において、複数の画像を用意し、それら画像をスキャナ２１４で読み取る際の読取条件も、各画像に対応して設定するようにして、各画像について、対応する読取条件で画像の読み取りを行い、複数のコンテンツデータを取得するようにしてもよい。すなわち、この場合、異なる画像について、それぞれ、対応する読取条件が設定され、各画像毎に、対応する読取条件に応じたコンテンツデータが取得されることになる。第４の実施例では、上述したとおり、読取条件は印刷条件として扱われるので、言い換えれば、複数の印刷コンテンツについて、それぞれ、対応する印刷条件が用意され、各印刷コンテンツ毎に、対応する印刷条件に応じたコンテンツデータが用意されたこととなる。
【０１８３】
よって、第３の実施例で述べたように、パーソナルコンピュータ２１２から印刷端末１０８へは、複数の印刷コンテンツについて、それら印刷条件（すなわち、読取条件）及びファイル名を同時に送信して、印刷端末１０８では、それら複数の印刷コンテンツの中から対応可能な印刷コンテンツについて、その印刷条件及びファイル名をパーソナルコンピュータ２１２へ返信するようにすることも可能となる。
【０１８４】
上記した各実施例においては、ネットワークとして、インターネットを含むブロードバンドネットワークを利用したが、携帯電話網や、公衆電話網などを利用するようにしてもよい。
【０１８５】
上記した各実施例においては、シグナリングプロトコルの一種であるＳＩＰを利用したが、本発明はこれに限定されるものではなく、Ｈ．３２３や、ＭＧＣＰ（Media Gateway Control Protocol）、ＭＥＧＡＣＯ（Media Gateway Control）などを用いるようにしてもよい。また、上記した実施例においては、データ転送プロトコルの一種であるＨＴＴＰを利用していたが、本発明はこれに限定されるものではなく、ＦＴＰや、ＲＴＰ（Realtime Transport Protocol）、ＩＲＣ（Internet Relay Chat）、ＴＥＬＮＥＴなどを用いるようにしてもよい。また、セッション確立やデータ伝送を行うために、Ｓｋｙｐｅ（登録商標）やインスタントメッセージング（instant messaging）を利用するようにしてもよい。Ｓｋｙｐｅやインスタントメッセージングに限らず、その他、グローバルアドレスの管理やプレゼンスサービス機能を有する類似の各種技術を利用するようにしてもよい。
【０１８６】
上記した各実施例では、ＳＩＰサーバをプロキシサーバとして機能させ、セッションの確立の仲介を行わせていたが、ＳＩＰでは、ＳＩＰクライアント同士が互いのＳＩＰ  ＵＲＩとＩＰアドレスを分かっていれば、ピアツーピアでセッションの確立を行うことが可能であるため、そのような場合には、ＳＩＰクライアント同士の間で、ＳＩＰサーバの仲介なしに、直接、セッションの確立を行うようにしてもよい。
【０１８７】
上記した各実施例では、オファ側（送信側）であるパーソナルコンピュータからアンサ側（受信側）印刷端末に対して、コンテンツデータをＰＵＳＨ型で配信するようにしていたが、ＰＵＬＬ型で配信するようにしてもよい。ここで、「ＰＵＬＬ型」とは、端末がサーバにデータ配信をリクエストして、その結果、サーバが端末にデータを配信する方法を言う。
【０１８８】
上記した各実施例では、ネットワーク上の位置情報として、ＩＰアドレスを利用するようにしていたが、ＭＡＣ（Media Access Control）アドレスを利用するようにしてもよい。
【０１８９】
上記した各実施例では、印刷条件としては、用紙サイズや、印刷品質や、印刷色などを挙げたが、その他、用紙種類（普通紙，光沢紙など）や、自動画像補正技術機能のＯＮ／ＯＦＦなどを含めるようにしてもよい。
【０１９０】
上記した各実施例では、送信端末、すなわち、オファ側（送信側）を、パーソナルコンピュータ１０４で構成するようにしていたが、本発明はこれに限定されるものではなく、例えば、コンテンツ提供者からの依頼に基づき、コンテンツ提供者に代わって、印刷コンテンツの配信を行うコンテンツ配信サーバによって構成するようにしてもよい。また、この場合、印刷条件については、そのコンテンツ提供者の過去の履歴から印刷条件を決定するようにしてもよいし、コンテンツ提供者毎に予め印刷条件を登録しておいてもよい。
【０１９１】
上記した各実施例では、情報出力装置として、印刷端末を用いる場合を例として説明したが、本発明はこれに限定されるものではなく、例えば、送信端末からディスプレイに画像などのコンテンツのデータを送信する場合に、ディスプレイの解像度などの表示条件を送信端末からディスプレイに伝える場合にも適用することができ、或いは、送信端末からオーディオ装置に音声などのコンテンツのデータを送信する場合に、ミュート状態などの音声出力条件を送信装置からオーディオ装置に伝える場合にも適用することができる。また、その他の情報出力装置として、電話やテレビなどを用いる場合にも適用することが可能である。
【図面の簡単な説明】
【０１９２】
【図１】本発明の第１の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
【図２】図１におけるパーソナルコンピュータ１０４の主要構成を示すブロック図である。
【図３】図１におけるＳＩＰサーバ１０６の主要構成を示すブロック図である。
【図４】一般的なＳＩＰサーバの種別を示す説明図である。
【図５】図１における印刷端末１０８の主要構成を示すブロック図である。
【図６】図１におけるパーソナルコンピュータ１０４と印刷端末１０８の間のセッション確立処理のシーケンスを示す説明図である。
【図７】既存のＳＤＰと印刷条件との対応関係を示す説明図である。
【図８】図１のコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。
【図９】本発明の第２の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理の流れを示すフローチャートである。
【図１０】本発明の第３の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理のうち、オファ側の処理の流れを示すフローチャートである。印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。
【図１１】本発明の第３の実施例としてのコンテンツ伝送システムにおける印刷条件伝達処理のうち、アンサ側の処理の流れを示すフローチャートである。
【図１２】本発明の第４の実施例としてのコンテンツ伝送システムの概略構成を示すブロック図である。
【図１３】図１２における送信端末２０４の主要構成を示すブロック図である。
【符号の説明】
【０１９３】
１０…ＣＰＵ
１２…通信部
１３…入力部
１４…メモリ
１５…モニタ
１６…配信依頼情報
１７…コンテンツデータ
１８…印刷条件データベース
２０…ＣＰＵ
２２…通信部
２４…メモリ
２６…登録情報
３０…ＣＰＵ
３２…通信部
３４…メモリ
３６…コンテンツデータ
３８…コンテンツ情報
４０…入力部
４２…モニタ
４６…出力Ｉ／Ｆ部
５０…ＣＰＵ
５２…通信部
５４…メモリ
５６…配信依頼情報
５７…コンテンツデータ
５８…読取条件設定情報
６０…入力部
６２…モニタ
６４…入力Ｉ／Ｆ部
１０４…パーソナルコンピュータ
１０６…ＳＩＰサーバ
１０８…印刷端末
１１０…ブロードバンドネットワーク
１１２…パーソナルコンピュータ
１１４…プリンタ
２０４…送信端末
２１２…パーソナルコンピュータ
２１４…スキャナ
【図１】
2009193567.tif 000003
【図２】
2009193567.tif 000004
【図３】
2009193567.tif 000005
【図４】
2009193567.tif 000006
【図５】
2009193567.tif 000007
【図６】
2009193567.tif 000008
【図７】
2009193567.tif 000009
【図８】
2009193567.tif 000010
【図９】
2009193567.tif 000011
【図１０】
2009193567.tif 000012
【図１１】
2009193567.tif 000013
【図１２】
2009193567.tif 000014
【図１３】
2009193567.tif 000015