JP5157554B2 - 送信装置、コンテンツ送信システム、コンテンツ送信方法及びコンピュータプログラム - Google Patents

Description

本発明は、コンテンツデータを送信する際に、送信先を確認するための技術に関するものである。なお、本明細書中において、「コンテンツ」とは、文書、画像、またはそれら組み合わせた情報などを言い、また、「コンテンツデータ」とは、上記コンテンツを表すデータを言う。

従来、送信側から受信側にコンテンツを送信し、受信側で印刷を行う場合、ファクシミリなどが利用されていた。ファクシミリによる場合、送信に人手や時間は要しないものの、通信費用が発生し、また、受信側で受け取って印刷されるコンテンツ自体も高品質なものを期待できないという問題があった。

一方、近年では、インターネットの発達などによって、情報を無料に近い低コストで送信することが可能となっている。また、高性能なプリンタや複合機などの開発によって、家庭内でも、比較的低コストで、高品質な印刷を行うことができるようになってきている。

そこで、パーソナルコンピュータや複合機などを含む送信装置から、上記したインターネットなどのネットワークを介して、プリンタや複合機などを含む受信装置に、コンテンツデータを、低コストで、かつ、高品質にて配信することができる、システムの開発が待たれている。

なお、ネットワークを利用した情報の送信に関しては、例えば、下記の特許文献に記載のものが知られている。

特開２００５−１０９７０１号公報 特開２００３−１７８０２８号公報 特表２００５−５１６３２０号公報

上記したシステムでは、送信装置から受信装置にコンテンツデータを送信する場合に、例えば、送信装置において、送信先（受信装置）を特定するための情報（送信先のアドレスなど）をユーザが手入力した場合に、入力間違いによって、ユーザの意図しない送信先にコンテンツデータを送信してしまい、その送信先において、そのデータによってコンテンツが印刷され、閲覧されてしまうという恐れがあった。

従って、本発明の目的は、上記した従来技術の課題を解決し、コンテンツデータを送信する場合に、コンテンツデータの送信に先立ち、送信先を確認し得るようにするための技術を提供することにある。

本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。

［適用例１］
受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記受信装置との間でセッションの確立を行う際に、前記仲介サーバとの間で認証処理を行う送信装置であって、
制御部と、報知部と、を備え、
前記セッションの確立を行う際に、前記制御部は、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信して、前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記報知部によって報知させることを特徴とする送信装置。

このように、適用例１の送信装置では、コンテンツデータの送信に先立つセッション確立の際に、制御部が、仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信することにより、仲介サーバから、認証要求レスポンスを受け取るようにしている。そして、制御部は、レスポンスの受信をトリガとして、コンテンツデータの送信先に関する情報を報知部によって報知させるようにしている。これにより、この適用例１の送信装置によれば、コンテンツデータの送信に先立ち、送信側ユーザは送信先の確認を行うことができる。

［適用例２］
適用例１に記載の送信装置において、
格納部をさらに備え、
前記セッションの確立を行う際に、前記制御部は、前記仲介サーバに対し、リクエストを送信して、前記仲介サーバから、前記認証情報を生成するために必要な認証情報生成用情報を含む認証要求レスポンスが返信されたら、前記格納部に、前記認証情報生成用情報を格納させることを特徴とする送信装置。

このように、適用例２の送信装置では、仲介サーバにリクエストを送信して、仲介サーバから認証情報を生成するために必要な認証情報生成用情報を取得し、格納部に格納することにより、セッションの確立を行うために必要な、正しい認証情報を生成することができる。

［適用例３］
適用例１に記載の送信装置において、
格納部をさらに備え、
前記仲介サーバに対し前記送信装置に関する登録を行う際に、前記制御部は、前記仲介サーバに対し、リクエストを送信し、前記仲介サーバから、前記認証情報を生成するために必要な認証情報生成用情報を含む認証要求レスポンスが返信されたら、前記格納部に、前記認証情報生成用情報を格納させることを特徴とする送信装置。

セッション確立の際に、仲介サーバから送信装置に送付される認証情報生成用情報が、登録時に送付される認証情報生成用情報と同一のものであることが保証されている場合には、このように、送信装置が、登録時に、仲介サーバから認証情報生成用情報を取得して、格納部に格納しておくことにより、セッションの確立を行う際に、認証情報生成用情報の取得を目的として、仲介サーバにリクエストを送信する必要が無くなるため、その分、仲介サーバとの間の信号のやりとりを減らすことができる。

［適用例４］
適用例２または適用例３に記載の送信装置において、
操作部をさらに備え、
前記送信先に関する情報の報知後、前記操作部を介して送信許可の指示がなされた場合に、前記制御部は、前記格納部に格納されている前記認証情報生成用情報を用いて、正しい認証情報を生成し、前記仲介サーバに対し、生成した前記正しい認証情報を付加して、リクエストを送信することを特徴とする送信装置。

このように、送信側ユーザによる送信先の確認の結果、送信側ユーザが送信を許可した場合、送信装置が、仲介サーバに対し、生成した前記正しい認証情報を付加して、リクエストを送信することにより、仲介サーバでは認証が通り、セッションの確立処理を続行でき、最終的に、コンテンツデータの受信装置への送信が可能となる。

［適用例５］
適用例２または適用例３に記載の送信装置において、
操作部をさらに備え、
前記送信先に関する情報の報知後、前記操作部を介して送信不許可の指示がなされた場合に、前記制御部は、前記仲介サーバに対し、キャンセルのためのリクエストを送信することを特徴とする送信装置。

このように、送信側ユーザによる送信先の確認の結果、送信側ユーザが送信を許可しない場合、送信装置が、仲介サーバに対し、キャンセルのためのリクエストを送信することにより、セッション確立及びコンテンツデータの送信は中止されるので、送信側ユーザの意図しない送信先にコンテンツデータを送信してしまい、その送信先において、そのデータによってコンテンツが印刷され、閲覧されてしまうという恐れがなくなる。

［適用例６］
適用例１ないし適用例５のうちの任意の１つに記載の送信装置において、
前記制御部は、一定の条件を満たす場合に、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信することを特徴とする送信装置。

このように構成することにより、一定の条件を満たす場合にのみ、送信側ユーザに、送信先の確認を行わせるようにすることができる。

［適用例７］
送信装置から受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記送信装置と前記受信装置との間でセッションの確立を行う際に、前記送信装置と前記仲介サーバとの間で認証処理を行うコンテンツ送信システムであって、
前記送信装置は、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信して、前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記送信装置の備える報知部によって報知することを特徴とするコンテンツ送信システム。
このように、適用例７のコンテンツ送信システムによれば、適用例１と同様の効果を奏することができる。

［適用例８］
送信装置から受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記送信装置と前記受信装置との間でセッションの確立を行う際に、前記送信装置と前記仲介サーバとの間で認証処理を行うコンテンツ送信方法であって、
（ａ）前記送信装置が、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信する工程と、
（ｂ）前記仲介サーバが、前記リクエストを受信し、前記送信装置に対し、認証要求レスポンスを返信する工程と、
（ｃ）前記送信装置が、前記認証要求レスポンスを受信したら、前記コンテンツデータの送信先に関する情報を前記送信装置の備える報知部によって報知する工程と、
を備えるコンテンツ送信方法。
このように、適用例８のコンテンツ送信方法によれば、適用例１と同様の効果を奏することができる。

［適用例９］
受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記受信装置との間でセッションの確立を行う際に、コンピュータによって前記仲介サーバとの間で認証処理を行うためのコンピュータプログラムであって、
前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信する機能と、
前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記コンピュータの備える報知部によって報知させる機能と、
を前記コンピュータに実現させるためのコンピュータプログラム。
このように、適用例９のコンピュータプログラムによれば、適用例１と同様の効果を奏することができる。

なお、本発明は、上記した送信装置やコンテンツ送信システムなどの装置発明の態様や、コンテンツ送信方法などの方法発明の態様や、それら方法や装置を構築するためのコンピュータプログラムとしての態様に限ることなく、そのようなコンピュータプログラムを記録した記録媒体としての態様など、種々の態様で実現することも可能である。

以下、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１の実施例：
Ａ−１．実施例の構成：
Ａ−２．実施例の動作：
Ａ−３．実施例の効果：
Ｂ．第２の実施例：
Ｂ−１．実施例の動作：
Ｂ−２．実施例の効果：
Ｃ．変形例：

Ａ．第１の実施例：
Ａ−１．実施例の構成：
図１は本発明の第１の実施例としてのコンテンツ送信システムの概略構成を示すブロック図である。

図１に示すとおり、本実施例のコンテンツ送信システムは、送信装置である複合機１０２と、受信装置である複合機１０４と、ＳＩＰ（Session Initiation Protocol）サーバ１０６と、で構成される。このうち、複合機１０２は、コンテンツの送信を希望する送信側ユーザによって管理され、複合機１０４は、送信されたコンテンツを受け取る受信側ユーザによって管理される。ＳＩＰサーバ１０６は、例えば、ネットワークサービス提供業者などによって管理される。

複合機１０２，１０４及びＳＩＰサーバ１０６は、インターネットを含む、いわゆるブロードバンドネットワーク１０８を介して接続されている。

本実施例では、文書，画像などのコンテンツは、コンテンツデータとして、後ほど詳述するように、送信側の複合機１０２によって、受信側の複合機１０４にＰＵＳＨ型で送信される。ここで、このような送信されるコンテンツデータとしては、例えば、ＪＰＥＧデータ、ＧＩＦデータ、ＰＮＧデータ、ＴＩＦＦデータ、プレーンテキストデータ、ＨＴＭＬデータ、ＰＤＦデータ、ＰｏｓｔＳｃｒｉｐｔ（登録商標）データなど、画像やドキュメントを表現することが可能な各種データを用いることができる。また、受信側で用いられる複合機１０４の機種が分かっている場合には、印刷データの形態で配信するようにしてもよい。また、ここで、「ＰＵＳＨ型」とは、端末側が情報をリクエストしなくても、サーバ側が一方的に情報を端末に送り出す方法を言う。なお、コンテンツデータの送信、すなわち、装置間におけるコンテンツデータの伝送には、データ転送プロトコルの一種であるＨＴＴＰ（Hypertext Transfer Protocol）を用いるようにしている。

また、本実施例では、上述したコンテンツデータの送信に先立って、シグナリングプロトコルの一種であるＳＩＰ（Session Initiation Protocol）を用いて、ＳＩＰサーバ１０６を介して、装置間、すなわち、複合機１０２と複合機１０４との間におけるセッションの確立を行うようにしている。さらに、本実施例では、このセッションの確立を行う過程において、ＳＩＰサーバ１０６を利用して、複合機１０２にて、送信先の確認処理を行うようにしている。ここで、「セッション」とは、端末などのノード間でメディアストリームを送受信する関係を言う。

図２は図１における複合機１０２または１０４の主要構成を示すブロック図である。複合機１０２または１０４は、図２に示すように、プログラムを実行することにより種々の処理や制御を行うＣＰＵ５０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部５２と、プログラムを格納したり、データや情報を格納したりするためのメモリ５４と、タッチパネルなどから成り、ユーザからの指示などを入力するための操作部５６と、液晶パネルなどから成り、取得したデータや情報などを表示するための表示部５８と、イメージセンサなどから成り、原稿などの紙からコンテンツである画像などを読み取るための読取部６０と、プリンタコントローラやプリンタエンジンなどから成り、コンテンツの印刷を行うための印刷部６２と、を主として備えている。このうち、メモリ５４は、データや情報として、コンテンツデータ５５などを格納することが可能である。また、通信部５２は、ＬＡＮケーブルなどを介してネットワーク１０８に接続されている。

なお、本実施例において、送信側の複合機１０２は、請求項における送信装置に、受信側の複合機１０４は、請求項における受信装置に、ＳＩＰサーバ１０６は、請求項における仲介サーバに、それぞれ相当する。また、送信側の複合機１０２において、ＣＰＵ５０は、請求項における制御部に、表示部５８は、請求項における報知部に、メモリ５４は、請求項における格納部に、操作部５６は、請求項における操作部に、それぞれ相当する。

図３は図１におけるＳＩＰサーバ１０６の主要構成を示すブロック図である。図３に示すように、ＳＩＰサーバ１０６は、サーバコンピュータによって構成されており、プログラムを実行することにより種々の処理や制御を行うＣＰＵ７０と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部７２と、プログラムを格納したり、データや情報を格納したりするためのメモリ７４と、を主として備えている。このうち、メモリ７４は、情報として、後述するような、登録情報７５などを格納することが可能である。なお、ＳＩＰサーバ１０６は、上記構成要素以外にも、キーボードやポインティングデバイスなどの入力部やモニタなどの表示部などを備えているが、図では省略されている。

図４は一般的なＳＩＰサーバの種別を示す説明図である。一般に、ＳＩＰサーバは、機能に応じて、図４に示すような種別に分けることができる。

レジストラは、ＳＩＰクライアント（すなわち、ＳＩＰユーザエージェント）からの登録要求を受け付けて、ＳＩＰクライアントのＳＩＰアドレス（すなわち、ＳＩＰ ＵＲＩ（Uniform Resource Identifier））や位置情報（すなわち、ＩＰ（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」を置く。

こうして、ＳＩＰに関する事前準備が完了したら、ＳＩＰを利用した、装置間におけるセッションの確立及びデータの送信を行うことが可能となる。

本実施例におけるコンテンツ送信システムは、ＨＴＴＰダイジェスト認証をサポートするＳＩＰのシステムによって構成されており、セッションの確立を行う過程においても、登録時と同様に、ＳＩＰサーバ１０６から送信装置である複合機１０２に対して、認証要求が為される。

ここで、本実施例との比較のために、比較例として、認証要求が為されない場合のセッション確立処理のシーケンスについて説明する。

図５は認証要求が為されない場合における複合機１０２，１０４の間のセッション確立処理のシーケンスを示す説明図である。図５において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。

送信側の複合機１０２は、自己のＩＰアドレスを受信側の複合機１０４に伝えるために、ＩＮＶＩＴＥリクエストのボディの中に複合機１０２のＩＰアドレス（実際には、複合機１０２に接続されるルータのグローバルＩＰアドレス）を挿入し、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６を介して複合機１０４に送信する。一方、受信側の複合機１０４も、自己のＩＰアドレスを送信側の複合機１０２に伝えるために、２００ ＯＫレスポンスのボディの中に複合機１０４のＩＰアドレス（実際には、複合機１０４に接続されるルータのグローバルＩＰアドレス）を挿入し、その２００ ＯＫレスポンスを、ＳＩＰサーバ１０６を介して複合機１０２に送信する。

そして、複合機１０２から送信したＡＣＫリクエストが、ＳＩＰサーバ１０６を介して、複合機１０４に到達したら、送信側の複合機１０２と受信側の複合機１０４との間のセッションは確立されたことになる。

その後、送信側の複合機１０２は、２００ ＯＫレスポンスより取得した複合機１０４のＩＰアドレスに基づいて、受信側の複合機１０４に、ＳＩＰサーバ１０６を介することなく、直接アクセスして、ＨＴＴＰに従ってコンテンツデータをＰＵＳＨ型で送信する。

受信側の複合機１０４が、コンテンツデータの受信が完了したら、送信側の複合機１０２は、再び、ＳＩＰに従って、ＢＹＥリクエストをＳＩＰサーバ１０６を介して複合機１０４に送信する。受信側の複合機１０４は、ＢＹＥリクエストを受信すると、２００ ＯＫレスポンスを、ＳＩＰサーバ１０６を介して複合機１０２に返す。これにより、送信側の複合機１０２と受信側の複合機１０４との間のセッションが解消される。以上が、認証要求が為されない場合のセッション確立処理のシーケンスである。

これに対し、本実施例では、前述したとおり、セッションの確立を行う過程においても、登録時と同様に、ＳＩＰサーバ１０６から送信装置である複合機１０２に対して、認証要求が為される。これにより、送信装置である複合機１０２において、コンテンツデータの送信に先立って、送信先の確認を行い得るようにしている。

そこで、まず、送信側では、例えば、送信側ユーザが、複合機１０２において、送信したい画像などのコンテンツを読取部６０で読み取らせ、コンテンツデータ５５としてメモリ５４に格納させる。その上で、送信側ユーザは、そのコンテンツを送信したい送信先のＳＩＰアドレスを、操作部５６を介して入力する。このとき、送信先のＳＩＰアドレスを入力する方法としては、ＳＩＰアドレスを１文字ずつ手入力する方法と、複合機１０２に予め設定されているアドレス帳を呼び出して、表示部５８にリスト表示させ、その中から所望のＳＩＰアドレスを選択入力する方法と、がある。

そこで、複合機１０２のＣＰＵ５０は、送信側ユーザによって送信先のＳＩＰアドレスが手入力されたか否かを判定する。判定の結果、手入力ではなく、アドレス帳の中から選択入力されたと判定した場合には、セッション確立処理のシーケンスは、図６に示すような通常の認証シーケンスとなる。

図６は手入力でないと判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。図６において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。なお、図６では、１００ Ｔｒｙｉｎｇ以降の処理シーケンス（受信側の複合機１０４についての処理シーケンスを含む）については、図５に示した認証要求が為されない場合の処理シーケンスと同様であるので、省略してある。すなわち、図６における［５］の１００ Ｔｒｙｉｎｇが、図５における［２］の１００ Ｔｒｙｉｎｇに相当している。

図６に示すように、まず、送信側の複合機１０２において、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストを、通信部５２を介してＳＩＰサーバ１０６に送信する。これに対し、ＳＩＰサーバ１０６において、ＣＰＵ７０は、図５に示した認証要求をしない場合と異なり、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ というレスポンスを、通信部７２を介して複合機１０２に返信する。このとき、ＳＩＰサーバ１０６のＣＰＵ７０は、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄレスポンスにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、ＨＴＴＰダイジェスト認証に関するパラメータ（すなわち、チャレンジ値）を付加して、そのレスポンスを返信するようにしている。このチャレンジ値が、認証情報を生成するために必要な情報となる。

複合機１０２において、ＣＰＵ５０は、返信されたレスポンスを受信すると、ＡＣＫリスクエストを送信する。さらに、ＣＰＵ５０は、受信したレスポンスを解析し、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからチャレンジ値を取得し、そのチャレンジ値と送信側のユーザＩＤ，パスワードとを用いて、レスポンス値を算出する。このレスポンス値が認証情報となる。そして、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、そのレスポンス値を付加し、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析して、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからレスポンス値を取得し、そのレスポンス値が正しい値であれば、認証を通し、送信側である複合機１０４との通信を許可して、受信したＩＮＶＩＴＥリクエストをそのまま複合機１０４に送信する。これ以降の処理は、図５に示した認証要求が為されない場合の処理シーケンスと同様となる。

一方、複合機１０２において、送信側ユーザによって送信先のＳＩＰアドレスが手入力されたと判定した場合は、セッション確立処理のシーケンスは、送信先確認処理を伴う認証シーケンスとなる。

図７は手入力であると判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。図７においても、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。また、１００ Ｔｒｙｉｎｇ以降の処理シーケンス（受信側の複合機１０４についての処理シーケンスを含む）については、図５に示した認証要求が為されない場合の処理シーケンスと同様であるので、省略してある。すなわち、図７における［８］の１００ Ｔｒｙｉｎｇが、図５における［２］の１００ Ｔｒｙｉｎｇに相当している。

図７に示すように、まず、送信側の複合機１０２において、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストをＳＩＰサーバ１０６に送信する。これに対し、ＳＩＰサーバ１０６において、ＣＰＵ７０は、図６の場合と同様に、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ レスポンスを複合機１０２に返信する。このとき、ＳＩＰサーバ１０６のＣＰＵ７０は、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダにチャレンジ値を付加して、そのレスポンスを返信する。

複合機１０２において、ＣＰＵ５０は、返信されたレスポンスを受信すると、ＡＣＫリスクエストを送信する。さらに、ＣＰＵ５０は、受信したレスポンスを解析し、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからチャレンジ値を取得し、そのチャレンジ値をメモリ５４に一時的に格納する。そして、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、何ら値を付加することなく、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析するが、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、値が無いため、認証を通すことなく、再度、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄレスポンスを複合機１０２に返信する。

複合機１０２において、ＣＰＵ５０は、返信されたレスポンスを再度受信すると、ＡＣＫリスクエストを送信した後、表示部５８の画面上に、送信先のＳＩＰアドレスと、送信予定のコンテンツデータのファイル名と、をそれぞれ表示させ、送信側ユーザに、送信先の確認を促す。送信側ユーザは、その画面表示を見て、送信先のＳＩＰアドレスに間違いがないかの確認を行う。確認を行った結果、送信先に間違いがなく、その送信先へのコンテンツデータの送信を許可してよい場合には、送信側ユーザは、操作部５６を介して送信許可を指示する。

送信許可の指示が為されると、ＣＰＵ５０は、先にメモリ５４に格納しておいたチャレンジ値を読み出し、そのチャレンジ値と送信側のユーザＩＤ，パスワードとを用いて、レスポンス値を算出する。そして、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、そのレスポンス値を付加し、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析して、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからレスポンス値を取得し、そのレスポンス値が正しい値であれば、認証を通し、送信側である複合機１０４との通信を許可して、受信したＩＮＶＩＴＥリクエストをそのまま複合機１０４に送信する。これ以降の処理は、図５に示した認証要求が為されない場合の処理シーケンスと同様となる。

一方、送信側ユーザが、送信先のＳＩＰアドレスについての確認を行った結果、例えば、入力間違いに気付いて、その送信先へのコンテンツデータの送信を取り止めるべきと判断し、操作部５６を介して送信不許可を指示した場合には、図８に示すような処理シーケンスとなる。

図８は送信不許可が指示された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。図８においても、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。また、図８において、［１］のＩＮＶＩＴＥから［６］のＡＣＫまでの処理シーケンスは、図７における［１］のＩＮＶＩＴＥから［６］のＡＣＫまでの処理シーケンスと同じである。

送信不許可の指示が為されると、複合機１０２において、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストではなく、ＣＡＮＣＥＬリクエストをＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＣＡＮＣＥＬリクエストを受信すると、２００ ＯＫレスポンスを複合機１０２に返信した後、確認のメッセージとして、リクエストが中断された旨を示す４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄというレスポンスを複合機１０２に送信する。これに対し、複合機１０２は、ＡＣＫリクエストを返し、一連のシーケンスが終了する。

Ａ−３．実施例の効果：
本実施例では、送信先のＳＩＰアドレスが送信側ユーザによる手入力であった場合には、コンテンツデータの送信に先立つセッション確立の際に、ＳＩＰサーバ１０６からチャレンジ値を含むレスポンスを受け取った後、送信装置である複合機１０２は、故意にレスポンス値を付加することなく、ＩＮＶＩＴＥリクエストをＳＩＰサーバ１０６に送信することにより、ＳＩＰサーバ１０６から、再度、レスポンス（Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）を受け取るようにしている。そして、このレスポンスの受信をトリガとして、複合機１０２は、画面に送信先のＳＩＰアドレス等を表示させ、送信側ユーザに送信先の確認を促すようにしている。これにより、本実施例によれば、複合機１０２において、コンテンツデータの送信に先立ち、送信側ユーザは送信先の確認を行うことができる。また、確認の結果、送信先が間違いであれば、送信側ユーザは、送信不許可を指示することにより、セッション確立及びコンテンツデータの送信は中止されるので、送信側ユーザの意図しない送信先にコンテンツデータを送信してしまい、その送信先において、そのデータによってコンテンツが印刷され、閲覧されてしまうという恐れはない。さらに、本実施例では、ＳＩＰにおける既存の認証システムを利用しているため、ＳＩＰサーバ１０６において、特別な仕組みを用意する必要がない。

Ｂ．第２の実施例：
第１の実施例においては、セッション確立の際に、ＳＩＰサーバ１０６から送信装置である複合機１０２に送付されるチャレンジ値が、登録時に送付されるチャレンジ値と異なる場合であっても、対処することが可能であるが、セッション確立の際に、ＳＩＰサーバ１０６から複合機１０２に、登録時に送付されるチャレンジ値と同一の値が送付されることが保証されている場合には、以下のような実施形態を採ることも可能である。そのような実施形態について、第２の実施例として説明する。

本発明の第２の実施例としての画像格納システムの構成は、図１に示した第１の実施例の場合と同様であるので、それらについての説明は省略する。

本実施例においては、送信装置である複合機１０２が、登録時にＳＩＰサーバ１０６から送付されてくるチャレンジ値をキャッシュする機能を有している点が、第１の実施例の場合と異なる。

Ｂ−１．実施例の動作
図１において、第１の実施例の場合と同様に、まず、複合機１０２，１０４は、それぞれ、起動すると、ＳＩＰサーバ１０６にＳＩＰクライアントとしてアクセスする。そして、複合機１０２，１０４は、アクセスしたＳＩＰサーバ１０６にそれぞれ登録要求を出し、自己のＳＩＰ ＵＲＩやＩＰアドレスなどの情報を送信する。ＳＩＰサーバ１０６は、レジストラ，ロケーションサーバとして機能し、そのＣＰＵ７０は、通信部７２を介して、登録要求を受け付け、送信された情報を登録情報７５としてメモリ７４に登録する。具体的には、まず、複合機１０２，１０４において、ＣＰＵ５０が、ＳＩＰサーバ１０６に対し、通信部５２を介してＲＥＧＩＳＴＥＲリクエストを送信すると、ＳＩＰサーバ１０６において、ＣＰＵ７０は、複合機１０２，１０４に対し、４０１ Ｕｎａｕｔｈｏｒｉｚｅｄというレスポンスを返信する。このとき、ＳＩＰサーバ１０６において、ＣＰＵ７０は、４０１ Ｕｎａｕｔｈｏｒｉｚｅｄレスポンスにおいて、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダにチャレンジ値を付加して、そのレスポンスを返信する。それに対し、複合機１０２，１０４において、ＣＰＵ５０は、それぞれ、受信したレスポンスを解析し、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからチャレンジ値を取得し、そのチャレンジ値をメモリ５４に格納する。そして、さらに、ＣＰＵ５０は、自己のユーザＩＤ，パスワードと取得したチャレンジ値とを用いてレスポンス値を算出して、ＳＩＰサーバ１０６に対し、そのレスポンス値を含むＲＥＧＩＳＴＥＲリクエストを返す。ＳＩＰサーバ１０６は、返されたレスポンス値が正しい値であれば、認証を通し、上記した登録を行う。

こうして、ＳＩＰに関する事前準備が完了したら、ＳＩＰを利用した、装置間におけるセッションの確立及びデータの送信を行うことが可能となる。

そこで、送信側ユーザが、複合機１０２において、送信したいコンテンツを読取部６０で読み取らせ、コンテンツデータ５５としてメモリ５４に格納させた上で、そのコンテンツを送信したい送信先のＳＩＰアドレスを、操作部５６を介して入力すると、複合機１０２のＣＰＵ５０は、送信側ユーザによって送信先のＳＩＰアドレスが手入力されたか否かを判定する。判定の結果、手入力ではなく、アドレス帳の中から選択入力されたと判定した場合には、セッション確立処理のシーケンスは、以下のようになる。

まず、送信側の複合機１０２において、ＣＰＵ５０は、登録時にメモリ５４に格納しておいたチャレンジ値を読み出し、そのチャレンジ値と送信側のユーザＩＤ，パスワードとを用いて、レスポンス値を算出する。そして、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、そのレスポンス値を付加し、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析して、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからレスポンス値を取得し、そのレスポンス値が正しい値であれば、認証を通し、送信側である複合機１０４との通信を許可して、受信したＩＮＶＩＴＥリクエストをそのまま複合機１０４に送信する。これ以降の処理は、図５に示した認証要求が為されない場合の処理シーケンスと同様となる。

一方、複合機１０２において、送信側ユーザによって送信先のＳＩＰアドレスが手入力されたと判定した場合は、セッション確立処理のシーケンスは、送信先確認処理を伴う認証シーケンスとなる。

図９は手入力であると判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。図９においても、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。また、１００ Ｔｒｙｉｎｇ以降の処理シーケンス（受信側の複合機１０４についての処理シーケンスを含む）については、図５に示した認証要求が為されない場合の処理シーケンスと同様であるので、省略してある。すなわち、図９における［５］の１００ Ｔｒｙｉｎｇが、図５における［２］の１００ Ｔｒｙｉｎｇに相当している。

図９に示すように、まず、送信側の複合機１０２において、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、何ら値を付加することなく、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析するが、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、値が無いため、認証を通すことなく、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ レスポンスを複合機１０２に返信する。

複合機１０２において、ＣＰＵ５０は、返信されたレスポンスを受信すると、ＡＣＫリスクエストを送信した後、表示部５８の画面上に、送信先のＳＩＰアドレスと、送信予定のコンテンツデータのファイル名と、をそれぞれ表示させ、送信側ユーザに、送信先の確認を促す。送信側ユーザは、その画面表示を見て、送信先のＳＩＰアドレスに間違いがないかの確認を行い、送信先に間違いがなく、その送信先へのコンテンツデータの送信を許可してよい場合には、操作部５６を介して送信許可を指示する。

送信許可の指示が為されると、ＣＰＵ５０は、登録時にメモリ５４に格納しておいたチャレンジ値を読み出し、そのチャレンジ値と送信側のユーザＩＤ，パスワードとを用いて、レスポンス値を算出する。そして、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、そのレスポンス値を付加し、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＩＮＶＩＴＥリクエストを解析して、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダからレスポンス値を取得し、そのレスポンス値が正しい値であれば、認証を通し、送信側である複合機１０４との通信を許可して、受信したＩＮＶＩＴＥリクエストをそのまま複合機１０４に送信する。これ以降の処理は、図５に示した認証要求が為されない場合の処理シーケンスと同様となる。

一方、送信側ユーザが、送信先のＳＩＰアドレスについての確認を行った結果、入力間違いに気付いて、その送信先へのコンテンツデータの送信を取り止めるべきと判断し、操作部５６を介して送信不許可を指示した場合には、図１０に示すような処理シーケンスとなる。

図１０は送信不許可が指示された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。図１０においても、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。また、図１０において、［１］のＩＮＶＩＴＥから［３］のＡＣＫまでの処理シーケンスは、図９における［１］のＩＮＶＩＴＥから［３］のＡＣＫまでの処理シーケンスと同じである。

送信不許可の指示が為されると、複合機１０２において、ＣＰＵ５０は、ＩＮＶＩＴＥリクエストではなく、ＣＡＮＣＥＬリクエストをＳＩＰサーバ１０６に送信する。

ＳＩＰサーバ１０６において、ＣＰＵ７０は、送信されたＣＡＮＣＥＬリクエストを受信すると、２００ ＯＫレスポンスを複合機１０２に返信した後、確認のメッセージとして、４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスを複合機１０２に送信する。これに対し、複合機１０２は、ＡＣＫリクエストを返し、一連のシーケンスが終了する。

Ｂ−２．実施例の効果：
本実施例では、送信先のＳＩＰアドレスが送信側ユーザによる手入力であった場合には、コンテンツデータの送信に先立つセッション確立の際に、送信装置である複合機１０２は、登録時に送付されたＳＩＰサーバ１０６からのチャレンジ値をキャッシュしていても、故意にレスポンス値を挿入することなく、ＩＮＶＩＴＥリクエストをＳＩＰサーバ１０６に送信することにより、ＳＩＰサーバ１０６から、レスポンス（Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）を受け取るようにしている。そして、このレスポンスの受信をトリガとして、複合機１０２は、画面に送信先のＳＩＰアドレス等を表示させ、送信側ユーザに送信先の確認を促すようにしている。これにより、本実施例によれば、第１の実施例と同様の効果を奏することができる。また、複合機１０２は、セッション確立の際に、登録時に受け取ってキャッシュしていたチャレンジ値を利用してレスポンス値を算出することができるので、チャレンジ値を受け取るためだけに、ＩＮＶＩＴＥリクエストをＳＩＰサーバ１０６に送信する必要がない。従って、その分、ＳＩＰサーバ１０６との間の信号のやりとりを減らすことができる。

Ｃ．変形例：
なお、本発明は上記した実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。

上記した各実施例においては、送信側の複合機１０２において、送信側ユーザにより送信先のＳＩＰアドレスが手入力されたか否かを判定し、手入力されたと判定した場合に、図７または図９に示す送信先確認処理を行うようにしていた。しかし、本発明はこれに限定されるものではない。

すなわち、送信装置（複合機１０２）において、例えば、「常に送信先確認処理を行う」というオプションを設け、そのオプションが選択された場合には、手入力するか、アドレス帳を用いて選択入力するかに関わらず、常に、送信先確認処理を行うようにしてもよい。

また、送信装置において、送信先毎に、前回、コンテンツデータの送信を行った時点からの経過時間を監視し、或る送信先について、その経過時間が一定時間を超えていたら、その送信先に関しては、送信先確認処理を行うようにしてもよい。こうすることにより、定期的に送信先確認処理が為されるため、例えば、送信先のＳＩＰアドレスが変更された場合でも、送信側ユーザは送信先確認によりＳＩＰアドレスの変更に気付くことができ、変更される前のＳＩＰアドレスにデータが送信されることを防止することができる。

さらに、送信装置において、送信すべきコンテンツデータの重要度に応じて、重要度の高いコンテンツデータを送信する場合には、送信先確認処理を行うようにしてもよい。なお、コンテンツデータが重要か否かについては、そのデータの内容を解析して、そのデータの種類に応じて判断したり、そのデータファイルの拡張子を見て判断したりしてもよい。

また、送信装置において、送信先のＳＩＰアドレスのドメイン名を見て、特定のプメイン名であれば、必ず、送信先確認処理を行うようにしてもよい。また、送信先が特定の相手先である場合には、必ず、送信先確認処理を行うようにしてもよい。

上記した各実施例では、送信装置（複合機１０２）は、ＳＩＰサーバ１０６から、４０７ Ｐｒｏｘｙ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄレスポンスを受け取るために、ＩＮＶＩＴＥリクエストにおいて、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダに、何ら値を付加することなく、そのＩＮＶＩＴＥリクエストを、ＳＩＰサーバ１０６に送信するようにしていたが、レスポンス値を付加しない代わりに、誤ったレスポンス値を付加するようにしてもよい。あるいは、Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダそのものを付加しないようにしてもよい。

上記した各実施例では、送信装置（複合機１０２）は、表示部５８の画面上に、送信先のＳＩＰアドレス等を表示して、送信側ユーザに、送信先の確認を促すようにしていたが、画面表示に代えて、または、画面表示と合わせて、音声にて、送信先のＳＩＰアドレスを送信側ユーザに知らせるようにしてよい。

上記した実施例においては、シグナリングプロトコルの一種であるＳＩＰを利用したが、本発明はこれに限定されるものではなく、Ｈ．３２３や、ＭＧＣＰ（Media Gateway Control Protocol）、ＭＥＧＡＣＯ（Media Gateway Control）などを用いるようにしてもよい。また、上記した実施例においては、データ転送プロトコルの一種であるＨＴＴＰを利用していたが、本発明はこれに限定されるものではなく、ＦＴＰや、ＲＴＰ（Realtime Transport Protocol）、ＩＲＣ（Internet Relay Chat）、ＴＥＬＮＥＴなどを用いるようにしてもよい。また、セッション確立やデータ送信を行うために、Ｓｋｙｐｅやインスタントメッセージング（instant messaging）を利用するようにしてもよい。Ｓｋｙｐｅやインスタントメッセージングに限らず、その他、グローバルアドレスの管理やプレゼンスサービス機能を有する類似の各種技術を利用するようにしてもよい。

本発明の第１の実施例としてのコンテンツ送信システムの概略構成を示すブロック図である。 図１における複合機１０２または１０４の主要構成を示すブロック図である。 図１におけるＳＩＰサーバ１０６の主要構成を示すブロック図である。 一般的なＳＩＰサーバの種別を示す説明図である。 認証要求が為されない場合における複合機１０２，１０４の間のセッション確立処理のシーケンスを示す説明図である。 手入力でないと判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。 手入力であると判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。 送信不許可が指示された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。 本発明の第２の実施例としてのコンテンツ送信システムにおいて、手入力であると判定された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。 第２の実施例において、送信不許可が指示された場合におけるセッション確立処理のシーケンスの一部を示す説明図である。

符号の説明

５０…ＣＰＵ
５２…通信部
５４…メモリ
５５…コンテンツデータ
５６…操作部
５８…表示部
６０…読取部
６２…印刷部
７０…ＣＰＵ
７２…通信部
７４…メモリ
７５…登録情報
１０２，１０４…複合機
１０６…ＳＩＰサーバ
１０８…ネットワーク

Claims (9)

1. 受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記受信装置との間でセッションの確立を行う際に、前記仲介サーバとの間で認証処理を行う送信装置であって、
   制御部と、報知部と、を備え、
   前記セッションの確立を行う際に、前記制御部は、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信して、前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記報知部によって報知させることを特徴とする送信装置。
2. 請求項１に記載の送信装置において、
   格納部をさらに備え、
   前記セッションの確立を行う際に、前記制御部は、前記仲介サーバに対し、リクエストを送信して、前記仲介サーバから、前記認証情報を生成するために必要な認証情報生成用情報を含む認証要求レスポンスが返信されたら、前記格納部に、前記認証情報生成用情報を格納させることを特徴とする送信装置。
3. 請求項１に記載の送信装置において、
   格納部をさらに備え、
   前記仲介サーバに対し前記送信装置に関する登録を行う際に、前記制御部は、前記仲介サーバに対し、リクエストを送信し、前記仲介サーバから、前記認証情報を生成するために必要な認証情報生成用情報を含む認証要求レスポンスが返信されたら、前記格納部に、前記認証情報生成用情報を格納させることを特徴とする送信装置。
4. 請求項２または請求項３に記載の送信装置において、
   操作部をさらに備え、
   前記送信先に関する情報の報知後、前記操作部を介して送信許可の指示がなされた場合に、前記制御部は、前記格納部に格納されている前記認証情報生成用情報を用いて、正しい認証情報を生成し、前記仲介サーバに対し、生成した前記正しい認証情報を付加して、リクエストを送信することを特徴とする送信装置。
5. 請求項２または請求項３に記載の送信装置において、
   操作部をさらに備え、
   前記送信先に関する情報の報知後、前記操作部を介して送信不許可の指示がなされた場合に、前記制御部は、前記仲介サーバに対し、キャンセルのためのリクエストを送信することを特徴とする送信装置。
6. 請求項１ないし請求項５のうちの任意の１つに記載の送信装置において、
   前記制御部は、一定の条件を満たす場合に、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信することを特徴とする送信装置。
7. 送信装置から受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記送信装置と前記受信装置との間でセッションの確立を行う際に、前記送信装置と前記仲介サーバとの間で認証処理を行うコンテンツ送信システムであって、
   前記送信装置は、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信して、前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記送信装置の備える報知部によって報知することを特徴とするコンテンツ送信システム。
8. 送信装置から受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記送信装置と前記受信装置との間でセッションの確立を行う際に、前記送信装置と前記仲介サーバとの間で認証処理を行うコンテンツ送信方法であって、
   （ａ）前記送信装置が、前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信する工程と、
   （ｂ）前記仲介サーバが、前記リクエストを受信し、前記送信装置に対し、認証要求レスポンスを返信する工程と、
   （ｃ）前記送信装置が、前記認証要求レスポンスを受信したら、前記コンテンツデータの送信先に関する情報を前記送信装置の備える報知部によって報知する工程と、
   を備えるコンテンツ送信方法。
9. 受信装置にコンテンツデータを送信するのに先立ち、仲介サーバを介して前記受信装置との間でセッションの確立を行う際に、コンピュータによって前記仲介サーバとの間で認証処理を行うためのコンピュータプログラムであって、
   前記セッションの確立を行う際に、前記仲介サーバに対し、正しい認証情報を付加することなく、リクエストを送信する機能と、
   前記仲介サーバから、認証要求レスポンスが返信されたら、前記コンテンツデータの送信先に関する情報を前記コンピュータの備える報知部によって報知させる機能と、
   を前記コンピュータに実現させるためのコンピュータプログラム。

Images