JP2009239497A - データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム - Google Patents

Abstract

【課題】送信先が通信中である場合に、送信装置がリダイアルを繰り返すことになく、送信先の通信中の状態が解放された後に受信装置にコンテンツなどのデータを送信することができるようにする。
【解決手段】送信装置１００が、コンテンツデータの送信を行うべく、ＩＮＶＩＴＥリクエストを送信した際に、受信装置２００が他の装置と通信中である場合、送信装置１００が、受信装置２００から４１５ Ｕｎｓｕｐｐｏｒｔｅｄ Ｍｅｄｉａ Ｔｙｐｅレスポンスを受信すると、送信装置１００は、そのコンテンツデータの送信に関して待機状態となる。受信装置２００において、他の装置との通信が終了したら、受信装置２００が、再送要求を出すべく、ボディ部が空のＩＮＶＩＴＥリクエストを送信し、送信装置１００が、その再送要求を受けると、コンテンツデータの送信を行うべく、２００ ＯＫレスポンスを返信する。
【選択図】図１

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」を置く。

本実施例において、送信装置１００及び受信装置２００のＳＩＰ−ＵＲＩは、それぞれ、以下の通りとする。
送信装置１００：sip:a@hoge.com
受信装置２００：sip:b@hoge.com

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

Ｂ−２．送信準備動作：
まず、送信側では、例えば、送信側ユーザが、送信装置１００において、送信したい画像などのコンテンツを読取部１１２で読み取らせ、コンテンツデータとしてメモリ１０４に格納させる。その上で、送信側ユーザは、操作部１０８を介して、メモリ１０４に格納されたコンテンツデータの中から、送信したいコンテンツデータを特定すると共に、送信したい送信先のＳＩＰ−ＵＲＩを、送信装置１００に入力する。

本実施例では、送信装置１００のＣＰＵ１０２は、送信すべきコンテンツに、一意に識別できるコンテンツＩＤを割り振って、コンテンツの管理を行うようにしている。コンテンツＩＤとしては、例えば、英数字の組み合わせや数字列などを用いることができる。なお、送信装置１００が、今回、送信しようとしているコンテンツのコンテンツＩＤは、「１０１」であるものとする。

また、コンテンツデータとしては、予め、メモリ１０４内に用意されているものを用いるてもよく、また、送信先のＳＩＰ−ＵＲＩとしては、予め、送信先リストなどに登録されているものを用いてもよい。

その後、送信側ユーザが、操作部１０８を介して、送信開始の指示を送信装置１００に入力すると、ＣＰＵ１０２は、通信部１０６からＳＩＰサーバ３００を介して、受信装置２００との間でセッションの確立を開始する。

Ｂ−３．セッション確立動作開始：
図３は通常時における送信装置１００と受信装置２００との間のセッション確立処理のシーケンスを示す説明図である。図３において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。

そこで、送信装置１００において、ＣＰＵ１０２は、自身のＩＰアドレスを受信装置２００に伝えるために、ＩＮＶＩＴＥリクエストのボディの中に送信装置１００のＩＰアドレス（実際には、送信装置１００に接続されるルータのグローバルＩＰアドレス）を挿入し、そのＩＮＶＩＴＥリクエストを、通信部１０６からＳＩＰサーバ３００を介して受信装置２００に送信する。

そして、ＣＰＵ１０２は、ＩＮＶＩＴＥリクエストの送信を開始すると、まず、メモリ１０４内に用意されている未送信リスト１２０に、図４に示すような送信に関するレコードを保存する。

図４は図１の未送信リスト１２０に保存されるレコードの一例を示す説明図である。図４に示すように、未送信リスト１２０では、１つのレコードは、インデックス，送信先，コンテンツＩＤ，再送要求待ちフラグの各項目から成る。各項目の意味は、それぞれ、以下の通りである。
インデックス：リスト上のレコードの順番を示すものである。
コンテンツＩＤ：前述したとおり、送信装置１００において、送信しようとしているコンテンツを一意に識別できるものである。
送信先：受信側のＳＩＰ−ＵＲＩが入る。
再送要求待ちフラグ：受信側が通信中で送信ができなかった場合は、フラグとして「１」が設定され、初回の送信時には「０」が設定される。

従って、今回、未送信リスト１２０に保存されるレコードは、図４に示すように、インデックスが「１」で、送信先が、受信装置２００のＳＩＰ−ＵＲＩである「sip:b@hoge.com」となっており、コンテンツＩＤが、上記したとおり「１０１」となっており、再送要求待ちフラグは、送信が初回であるため、「０」となっている。

こうして、未送信リスト１２０に送信に関するレコードを保存した後、ＣＰＵ１０２は、受信装置２００からのレスポンス待ちの状態となる。

これに対し、受信装置２００では、ＣＰＵ２０２が、送信されたＩＮＶＩＴＥリクエストを通信部２０６を介して受信すると、まず、メモリ２０４内に用意されている未受信リスト２２２に、図５に示すような受信に関するレコードを保存する。

図５は図１の未受信リスト２２２に保存されるレコードの一例を示す説明図である。図５に示すように、未受信リスト２２２では、１つのレコードは、インデックス，送信元の各項目から成る。各項目の意味は、それぞれ、以下の通りである。
インデックス：リスト上のレコードの順番を示すものである。
送信元：コンテンツを送信してきた送信側のＳＩＰ−ＵＲＩが入る。

このように、受信側の場合、送信側とは異なり、未受信リスト２２２にレコードとして保存するのは、送信元のＳＩＰ−ＵＲＩだけであり、コンテンツのＩＤは保存しない。

従って、今回、未受信リスト２２２に保存されるレコードは、図５に示すように、インデックスが「１」で、送信元が、送信装置１００のＳＩＰ−ＵＲＩである「sip:a@hoge.com」となっている。

Ｂ−４．受信可能である場合：
こうして、未受信リスト２２２に受信に関するレコードを保存すると、次に、ＣＰＵ２０２は、自身（受信装置２００）の通信状況を判断し、その結果、送信装置１００からのコンテンツデータの受信が可能である場合には、２００ ＯＫレスポンスを、送信装置１００に対して返信する。

すなわち、ＣＰＵ２０２は、自身のＩＰアドレスを送信装置１００に伝えるために、２００ ＯＫレスポンスのボディの中に受信装置２００のＩＰアドレス（実際には、受信装置２００に接続されるルータのグローバルＩＰアドレス）を挿入し、その２００ ＯＫレスポンスを、通信部２０６からＳＩＰサーバ３００を介して送信装置１００に送信する。

また、ＣＰＵ２０２は、図５に示す未受信リスト２２２から、送信元が送信装置１００となっている（すなわち、「sip:a@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除する。

これに対し、送信装置１００では、ＣＰＵ１０２が、通信部１０６を介して、受信装置２００からの２００ ＯＫレスポンスを受信すると、セッションを確立すべく、図３に示す、以降の処理を続行する。そして、送信装置１００から送信されたＡＣＫリクエストが、ＳＩＰサーバ３００を介して、受信装置２００に到達したら、送信装置１００と受信装置２００との間のセッションは確立されたことになる。

その後、送信装置１００において、ＣＰＵ１０２は、２００ ＯＫレスポンスから取得した受信装置２００のＩＰアドレスに基づいて、受信装置２００に、ＳＩＰサーバ３００を介することなく、直接アクセスして、ＨＴＴＰに従ってコンテンツデータをＰＵＳＨ型で送信する。そして、送信が完了すると、ＣＰＵ１０２は、図４に示す未送信リスト１２０から、送信先が受信装置２００となっている（すなわち、「sip:ｂ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除する。

また、受信装置２００が、コンテンツデータの受信が完了したら、送信装置１００において、ＣＰＵ１０２は、再び、ＳＩＰに従って、ＢＹＥリクエストをＳＩＰサーバ３００を介して受信装置２００に送信する。受信装置２００において、ＣＰＵ２０２が、ＢＹＥリクエストを受信すると、２００ ＯＫレスポンスを、ＳＩＰサーバ３００を介して送信装置１００に返す。これにより、送信装置１００と受信装置２００との間のセッションが解消される。また、受信装置２００では、ＣＰＵ２０２が、受信したコンテンツデータに基づいて、印刷部２１４を制御して印刷を実行し、印刷されたコンテンツを出力する。

こうして、受信装置２００において、送信装置１００からのコンテンツデータの受信が可能である場合には、両者の間でセッションの確立がなされ、送信装置１００から受信装置２００へコンテンツデータの送信が行われる。

Ｂ−５．通信中である場合：
図６は受信装置２００が他の装置と通信中である場合における送信装置１００と受信装置２００との間の処理のシーケンスを示す説明図である。図６において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。

受信装置２００において、ＣＰＵ２０２が、自身（受信装置２００）の通信状況を判断した結果、自身（受信装置２００）が他の装置（図示せず）と通信中であり、送信装置１００からのコンテンツデータの受信が不可能である場合には、ＣＰＵ２０２は、図６に示すように、４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスを、送信装置１００に対して返信する。ここで、４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスとは、ＩＮＶＩＴＥリクエストを受け取ったときに、既に別の通信を行っているなどの理由で、今回の通信を始めることができないということを送信元に知らせるためのレスポンスである。

また、ＣＰＵ２０２は、他の装置と通信中である場合は、図５に示す未受信リスト２２２において、レコードをそのままの状態で保持しておく。その後、他の装置との通信が終了すると、ＣＰＵ２０２は、後述する再送要求処理に移る。

これに対し、送信装置１００では、ＣＰＵ１０２が、通信部１０６を介して、受信装置２００からの４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスを受信すると、ＡＣＫリクエストを送信し、セッションを終了する。

図７は図１の未送信リスト１２０に保存されているレコードについて、４８６ Ｂｕｓｙ Ｈｅｒｅレスポンス受信後の状態を示す説明図である。

また、ＣＰＵ１０２は、今回、受信装置２００が通信中でデータの送信ができなかったため、図４に示す未送信リスト１２０のうち、送信先が受信装置２００となっている（すなわち、「sip:ｂ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）について、図７に示すように、再送要求待ちフラグを「０」から「１」に変更する。そして、送信装置１００のＣＰＵ１０２は、受信装置２００に対するデータ送信に関し、受信装置２００から再送要求が届くまで、待機状態となる。

ところで、上記した例では、同一の送信先に対して、送信したいコンテンツデータは１つであったため、未送信リスト１２０では、１つのレコードに対して、含まれているコンテンツＩＤは１つであった。しかし、同一の送信先に対して、送信したいコンテンツデータが複数ある場合には、未送信リスト１２０は、図８に示す如くになる。

図８は図１の未送信リスト１２０に保存されるレコードの他の例を示す説明図である。図８に示す未送信リスト１２０では、送信先が２箇所あり（すなわち、「sip:ｂ@hoge.com」と「sip:ｃ@hoge.com」）、各送信先について、送信したいコンテンツデータがそれぞれ２つあることを示している。すなわち、１つの送信先に対し、複数のコンテンツＩＤが紐付けられており、再送要求待ちフラグについても、コンテンツＩＤ毎ではなく、１つの送信先に紐付けられている。これは、後述する再送時において、その送信先に対して、紐付けられている全てのコンテンツデータを一括で送信することを目的としている。

一方、受信装置２００において、他の装置との通信中に、別の複数の装置からコンテンツデータ送信の打診があった場合に、未受信リスト２２２は、図９に示す如くになる。

図９は図１の未受信リスト２２２に保存されるレコードの他の例を示す説明図である。図９に示す未受信リスト２２２では、送信元が２箇所であった場合（すなわち、「sip:ａ@hoge.com」と「sip:ｄ@hoge.com」）を示している。

なお、受信装置２００において、他の装置との通信中に、別の１つの装置から複数の異なるコンテンツデータについての送信の打診（すなわち、ＩＮＶＩＴＥリクエストの送信）がある場合も考えられる。例えば、他の装置との通信中に、送信装置１００（すなわち、「sip:a@hoge.com」）から、最初に或るコンテンツデータについての送信の打診があり、引き続き他の装置との通信中に、再び、同じ送信装置１００（すなわち、「sip:a@hoge.com」）から、最初の送信打診とは異なる別のコンテンツデータについての送信の打診がある場合である。このような場合には、受信装置２００において、ＣＰＵ２０２は、まず、未受信リスト２２２内に、同じ送信元に関するレコードが保存されているどうかを判断し、同じ送信元に関するレコードが既に保存されていれば、未受信リスト２２２の更新は行わない。反対に、同じ送信元に関するレコードが保存されてない場合には、その送信元についてのレコードを追加して保存するようにする。これは、受信装置２００では、未受信リスト２２２にある送信元に対して、１つずつコンテンツデータの再送を要求するのではなく、受信することのできなかったコンテンツデータを全て一括で再送してもらうことを目的としている。

Ｂ−６．再送要求処理：
前述した通り、受信装置２００において、他の装置との通信が終了すると、ＣＰＵ２０２は、再送要求処理に移行し、まず、メモリ２０４内の未受信リスト２２２を参照する。参照した結果、未受信リスト２２２に、１つもレコードが保存されていない場合、すなわち、未受信リスト２２２が空の場合には、ＣＰＵ２０２は、直前の他の装置との通信中に、別の何れの装置からもコンテンツデータ送信の打診（すなわち、ＩＮＶＩＴＥリクエストの送信）がなかったものとして、待機状態となる。

反対に、参照した結果、未受信リスト２２２に、１つ以上のレコードが保存されている場合には、ＣＰＵ２０２は、他の装置との通信中に、別の装置からコンテンツデータ送信の打診（すなわち、ＩＮＶＩＴＥリクエストの送信）があったものと判断し、未受信リスト２２２に保存されている先頭のレコードから順番に、以下の処理を行う。

まず、ＣＰＵ２０２は、未受信リスト２２２のうち、対象となるレコードから送信元のＳＩＰ−ＵＲＩを取得する。次に、ＣＰＵ２０２は、そのＳＩＰ−ＵＲＩに基づき、送信元に対して、コンテンツデータの再送要求を行う。具体的には、送信元に対して、ＩＮＶＩＴＥリクエストを送信する。但し、そのＩＮＶＩＴＥリクエストは、常のＩＮＶＩＴＥリクエストとは異なり、ボディ部が空となっている。すなわち、この送信元に対して行われる再送要求は、特定のコンテンツデータの再送を要求しているではなく、送信したいコンテンツデータがあれば、全て送信するよう、要求するものだからである。また、このように、ボディ部が空であるＩＮＶＩＴＥリクエストを送信することにより、ＩＮＶＩＴＥリクエストを受け取った側、すなわち、送信元では、ボディ部が空であるか否かでもって、通常のコンテンツデータ送信の打診であるのか、それとも、コンテンツデータの再送要求であるかを判断することができる。

これに対し、送信元である送信装置１００では、ＣＰＵ１０２が、受信装置２００からＩＮＶＩＴＥリクエストを受信すると、まず、自身（送信装置１００）の通信状況を判断する。判断の結果、自身（送信装置１００）が他の装置（図示せず）と通信中でない場合には、次に、ＣＰＵ１０２は、受信したＩＮＶＩＴＥリクエストについて、前述した通り、ボディ部が空であるか否かを判断する。判断の結果、ボディ部が空であった場合、ＣＰＵ１０２は、そのＩＮＶＩＴＥリクエストは、コンテンツデータの再送要求であると判断する。

Ｂ−７．未送信リストに対応レコードが保存されている場合：
次に、ＣＰＵ１０２は、そのＩＮＶＩＴＥリクエストにおけるＴｏヘッダより、再送要求元のＳＩＰ−ＵＲＩ（すなわち、この場合、受信装置２００のである「b@hoge.com」）を取得する。さらに、ＣＰＵ１０２は、取得したＳＩＰ−ＵＲＩに基づき、未送信リスト１２０内に、そのＳＩＰ−ＵＲＩを含むレコードが保存されているかどうかを検索する。検索の結果、そのレコードが保存されている場合には、そのＳＩＰ−ＵＲＩに対応した送信先から、再送要求があったことになるため、そのレコードについて、図４に示したように、再送要求待ちフラグを「１」から「０」に変更する。また、そのレコードが保存されていると言うことは、そのＳＩＰ−ＵＲＩに対応した再送要求元、すなわち、受信装置２００に対して、再送すべきコンテンツデータ（すなわち、未送信のコンテンツデータ）が存在するということであるため、それらコンテンツデータを特定するために、そのレコードに含まれる全てのコンテンツＩＤを取得する。

次に、ＣＰＵ１０２は、コンテンツデータの再送を行うために、取得した各コンテンツＩＤに基づいて、そのコンテンツＩＤの本体であるコンテンツデータをメモリ１０４からそれぞれ読み出し、再送準備に入る。具体的には、ＣＰＵ１０２は、２００ ＯＫレスポンスのボディ部に記述すべき内容を、ＳＤＰ（Session Description Protocol）を用いて生成する。そして、再送準備が完了したら、ＣＰＵ１０２は、受信装置２００に対して、その２００ ＯＫレスポンスを送信する。

受信装置２００では、ＣＰＵ１０２が、この２００ ＯＫレスポンスを受信すると、ＳＤＰを用いて記述されたボディ部の内容を解析して、送信予定のコンテンツデータが印刷部２１４で印刷可能であるかどうかを判断する。印刷可能であれば、ＣＰＵ２０２は、送信装置１００に対して、ＡＣＫリクエストを送信する。通常、ＡＣＫリクエストには、ボディ部が含まれていないが、本実施例では、このような再送処理の場合、ＣＰＵ２０２が、ＳＤＰを用いて印刷可能なコンテンツデータに対応した内容を、ＡＣＫリクエストのボディ部に付加した上で、そのＡＣＫリクエストを送信するようにしている。

このＡＣＫリクエストが受信装置２００に到達すると、前述した通り、送信装置１００と受信装置２００との間のセッションが確立されたことになるため、送信装置１００において、ＣＰＵ１０２は、受信装置２００に対し、先に読み出した全てのコンテンツデータ（すなわち、未送信であった全てのコンテンツデータ）を送信する。そして、送信が完了すると、ＣＰＵ１０２は、未送信リスト１２０から、送信先が受信装置２００となっている（すなわち、「sip:ｂ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除する。また、受信装置２００でも、送信されたコンテンツデータの受信が完了すると、ＣＰＵ２０２は、未受信リスト２２２から、送信元が送信装置１００となっている（すなわち、「sip:ａ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除する。

Ｂ−８．未送信リストに対応レコードが保存されていない場合：
図１０は未送信リストに対応レコードが保存されていない場合における送信装置１００と受信装置２００との間の処理のシーケンスを示す説明図である。図１０において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。

送信装置１００において、ＣＰＵ１０２が、前述したように、取得したＳＩＰ−ＵＲＩに基づき、未送信リスト１２０内に、そのＳＩＰ−ＵＲＩを含むレコードが保存されているかどうかを検索した結果、そのレコードが保存されていない場合には、そのＳＩＰ−ＵＲＩに対応した再送要求元、すなわち、受信装置２００に対して、再送すべきコンテンツデータがないものとして、図１０に示すように、４１５ Ｕｎｓｕｐｐｏｒｔｅｄ Ｍｅｄｉａ Ｔｙｐｅレスポンスを、受信装置２００に返信する。送信装置１００において、何らかの理由で（例えば、送信側ユーザの気が変わったなど）、受信装置２００に送信すべきコンテンツデータを削除してしまった場合などが、これに該当する。この場合においても、受信装置２００では、ＣＰＵ２０２が、未受信リスト２２２から、送信元が送信装置１００となっている（すなわち、「sip:ａ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除し、以降、再送要求は行わない。

Ｂ−９．再送要求でない場合：
ところで、送信装置１００において、ＣＰＵ１０２が、受信したＩＮＶＩＴＥリクエストについて、ボディ部が空であるか否かを判断した結果、ボディ部が空でなく、ボディ部が存在していた場合には、そのＩＮＶＩＴＥリクエストは、再送要求ではなく、通常のＩＮＶＩＴＥリクエストであると認識する。その場合、ＣＰＵ１０２は、受信装置２００から送信装置１００へのデータの送信の打診が行われたものとして判断して、以降、処理を行う。また、この場合、受信装置２００からの再送要求ではないため、ＣＰＵ１０２は、未送信リスト１２０において、送信先が受信装置２００となっている（すなわち、「sip:ｂ@hoge.com」となっている）レコードについて、再送要求待ちフラグは「１」のままとして変更しない。

Ｂ−１０．送信装置が通信中である場合：
さて、送信装置１００において、ＣＰＵ１０２が、受信装置２００からＩＮＶＩＴＥリクエストを受信した際、前述したように、自身（送信装置１００）の通信状況を判断するが、判断の結果、自身（送信装置１００）が他の装置（図示せず）と通信中である場合には、受信装置２００に対して、４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスを送信する。さらに、ＣＰＵ１０２は、受信したＩＮＶＩＴＥリクエストについて、ボディ部が空であるか否かを判断し、ボディ部が空であった場合、そのＩＮＶＩＴＥリクエストが、コンテンツデータの再送要求であると判断する。そして、ＣＰＵ１０２は、そのＩＮＶＩＴＥリクエストにおけるＴｏヘッダより、再送要求元のＳＩＰ−ＵＲＩ（この場合、「sip:ｂ@hoge.com」）を取得し、そのＳＩＰ−ＵＲＩに基づき、未送信リスト１２０内に、そのＳＩＰ−ＵＲＩを含むレコードが保存されているかどうかを検索する。検索の結果、そのレコードが保存されている場合には、そのレコードについて、再送要求待ちフラグを「１」から「０」に変更する。

これに対し、受信装置２００では、ＣＰＵ２０２が、送信装置１００から４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスを受信すると、未受信リスト２２２から、送信元が送信装置１００となっている（すなわち、「sip:ａ@hoge.com」となっている）レコード（すなわち、インデックスが「１」のレコード）を削除し、これにより、以降、送信装置１００に対する再送要求は、行わないことになる。すなわち、送信装置１００から、再送要求に対する送信処理ではなく、通常の送信処理としてやり直してもらう形となる。

一方、送信装置１００では、他の装置との通信が終了した後、ＣＰＵ１０２は、未送信リスト１２０を検索して、再送要求待ちフラグが「０」となっているレコードについそのレコードに含まれる送信先に対して、再び、送信処理を行う。今回は、再送要求ではないので、受信装置２００に対しては、通常のボディ部が存在するＩＮＶＩＴＥリクエストを送信することになる。

なお、送信装置１００において、他の装置との通信中であっても、ＣＰＵ１０２が、受信したＩＮＶＩＴＥリクエストについて、ボディ部が空であるか否かを判断した結果、ボディ部が空でなく、ボディ部が存在していた場合には、ＣＰＵ１０２は、そのＩＮＶＩＴＥリクエストが、再送要求ではなく、通常のＩＮＶＩＴＥリクエストであると認識する。従って、この場合、ＣＰＵ１０２は、受信装置２００からの再送要求ではないため、未送信リスト１２０において、送信先が受信装置２００となっているレコードについて、再送要求待ちフラグは「１」のままとして変更しない。

Ｃ．実施例の効果：
以上説明したように、本実施例では、送信装置１００が、コンテンツデータの送信を行うべく、ＩＮＶＩＴＥリクエストを送信した際に、受信装置２００が他の装置と通信中である場合、送信装置１００が、受信装置２００から４１５ Ｕｎｓｕｐｐｏｒｔｅｄ Ｍｅｄｉａ Ｔｙｐｅレスポンスを受信すると、送信装置１００は、そのコンテンツデータの送信に関して待機状態となるようにしている。従って、本実施例によれば、送信装置１００は、リダイアルを繰り返すことがないため、送信装置１００における通信処理の負荷を抑制することでき、無駄な通信が発生する恐れもなくなる。

また、その後、受信装置２００において、他の装置との通信が終了したら、受信装置２００が、再送要求を出すべく、ボディ部が空のＩＮＶＩＴＥリクエストを送信し、送信装置１００が、その再送要求を受けると、コンテンツデータの送信を行うべく、２００ ＯＫレスポンスを返信するようにしている。従って、本実施例によれば、受信装置２００において、通信中の状態が解放されると、送信装置１００は、受信装置２００からの再送要求により、受信装置２００に対するデータの送信を実行することができる。

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

上記した実施例では、送信装置１００に、未送信リスト１２０を用意し、受信装置２００に、未受信リスト２２２を用意するものとして説明したが、送信装置１００，受信装置２００は、何れも複合機で構成されているため、別の局面においては、送信装置１００が、受信側（すなわち、受信装置）となり、受信装置２００が、送信側（すなわち、送信装置）となり得る。従って、実際には、送信装置１００，受信装置２００の何れも、未送信リストと未受信リストの両方が用意されており、これら装置は、未送信リストと未受信リストの両方を管理することになる。

そこで問題となるのは、同じ相手方装置からの送信と受信が重なる場合である。すなわち、未送信リストと未受信リストの両方が存在（同じ相手方装置への未送信と同じ相手方装置からの未受信とが存在）する場合、何れのリストを優先すべきかが問題となる。このような場合、未受信リストを優先することが好ましい。すなわち、自装置に、未受信リストが存在する場合は、その未受信リストに関わる処理、すなわち再送要求処理を優先して行い、この再送要求処理が終了した段階で、未送信リストに関わるの処理に移行するものとする。再送要求に失敗すると（再送要求を出したが、相手方装置が他の装置と通信中だった場合）、未受信リストから、再送要求すべき送信元は一旦削除されるため、何れかのタイミングで、未受信リストは必ず空となる。未受信リストが空になった段階で、未送信リストに関する処理を行えばよい。

上記した実施例では、送信装置１００及び受信装置２００をそれぞれ複合機で構成するようにしていたが、本発明はこれに限定されるものではなく、例えば、パーソナルコンピュータや、ファクシミリや、プリンタなどを用いるようにしてもよい。また、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線ＬＡＮや、ブルートゥースや、赤外線など、無線で接続されてもよい。

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

上記した実施例では、送信すべきデータとして、コンテンツデータを対象としていたが、コンテンツデータ以外のデータを対象とするようにしてもよい。

本発明の一実施例としてのデータ送信システムの概略構成を示すブロック図である。 一般的なＳＩＰサーバの種別を示す説明図である。 通常時における送信装置１００と受信装置２００との間のセッション確立処理のシーケンスを示す説明図である。 図１の未送信リスト１２０に保存されるレコードの一例を示す説明図である。 図１の未受信リスト２２２に保存されるレコードの一例を示す説明図である。 受信装置２００が他の装置と通信中である場合における送信装置１００と受信装置２００との間の処理のシーケンスを示す説明図である。 図１の未送信リスト１２０に保存されているレコードについて、４８６ Ｂｕｓｙ Ｈｅｒｅレスポンス受信後の状態を示す説明図である。 図１の未送信リスト１２０に保存されるレコードの他の例を示す説明図である。 図１の未受信リスト２２２に保存されるレコードの他の例を示す説明図である。 未送信リストに対応レコードが保存されていない場合における送信装置１００と受信装置２００との間の処理のシーケンスを示す説明図である。

符号の説明

１００…送信装置
１０２…ＣＰＵ
１０４…メモリ
１０６…通信部
１０８…操作部
１１０…表示部
１１２…読取部
１１４…印刷部
１２０…未送信リスト
２００…受信装置
２０２…ＣＰＵ
２０４…メモリ
２０６…通信部
２１４…印刷部
２２２…未受信リスト
３００…ＳＩＰサーバ
４００…ネットワーク

Claims (7)

1. 送信装置から受信装置にデータを送信するためのデータ送信システムであって、
   前記送信装置が、前記受信装置に対し、前記データの送信を打診する旨の要求を送信した際に、前記受信装置が他の装置と通信中である場合、前記受信装置は、前記送信装置に対し、通信中である旨の応答を返信し、前記送信装置は、前記応答を受信したら、前記データの送信に関して待機状態となると共に、
   前記受信装置は、前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信し、前記送信装置は、前記再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信することを特徴とするデータ送信システム。
2. 請求項１に記載のデータ送信システムにおいて、
   前記送信装置は、前記データを送信すべき送信先に関する情報と、送信すべき前記データに関する情報と、再送要求待ちの状態か否かを示す情報と、をリストで管理すると共に、
   前記受信装置は、前記データの送信の打診を受けた送信元に関する情報をリストで管理することを特徴とするデータ送信システム。
3. 受信装置にデータを送信するための送信装置であって、
   前記受信装置に対し、前記データの送信を打診する旨の要求を送信した後に、前記受信装置から、他の装置と通信中である旨の応答を受信したら、前記データの送信に関して待機状態となると共に、
   前記受信装置から、前記データについての再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信することを特徴とする送信装置。
4. 送信装置から送信されたデータを受信するための受信装置であって、
   前記送信装置から、前記データの送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信すると共に、
   前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信することを特徴とする送信装置。
5. 送信装置から受信装置にデータを送信するためのデータ送信方法であって、
   （ａ）前記送信装置が、前記受信装置に対し、前記データの送信を打診する旨の要求を送信する工程と、
   （ｂ）前記受信装置が、前記送信装置から、前記送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信する工程と、
   （ｃ）前記送信装置が、前記受信装置から、前記通信中である旨の応答を受信したら、前記データの送信に関して待機状態となる工程と、
   （ｄ）前記受信装置が、前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信する工程と、
   （ｅ）前記送信装置が、前記受信装置から、前記再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信する工程と、
   を備えるデータ送信方法。
6. 受信装置にデータを送信するためのコンピュータプログラムであって、
   前記受信装置に対し、前記データの送信を打診する旨の要求を送信した後に、前記受信装置から、他の装置と通信中である旨の応答を受信したら、前記データの送信に関して待機状態となる機能と、
   前記受信装置から、前記データについての再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信する機能と、
   をコンピュータに実現させるためのコンピュータプログラム。
7. 送信装置から送信されたデータを受信するためのコンピュータプログラムであって、
   前記送信装置から、前記データの送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信する機能と、
   前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信する機能と、
   をコンピュータに実現させるためのコンピュータプログラム。

Images