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

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

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

Info

Publication number
JP2009239497A
JP2009239497A JP2008081315A JP2008081315A JP2009239497A JP 2009239497 A JP2009239497 A JP 2009239497A JP 2008081315 A JP2008081315 A JP 2008081315A JP 2008081315 A JP2008081315 A JP 2008081315A JP 2009239497 A JP2009239497 A JP 2009239497A
Authority
JP
Japan
Prior art keywords
transmission
data
receiving
transmitting
request
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.)
Pending
Application number
JP2008081315A
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 JP2008081315A priority Critical patent/JP2009239497A/ja
Publication of JP2009239497A publication Critical patent/JP2009239497A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Facsimiles In General (AREA)
  • Facsimile Transmission Control (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】送信先が通信中である場合に、送信装置がリダイアルを繰り返すことになく、送信先の通信中の状態が解放された後に受信装置にコンテンツなどのデータを送信することができるようにする。
【解決手段】送信装置100が、コンテンツデータの送信を行うべく、INVITEリクエストを送信した際に、受信装置200が他の装置と通信中である場合、送信装置100が、受信装置200から415 Unsupported Media Typeレスポンスを受信すると、送信装置100は、そのコンテンツデータの送信に関して待機状態となる。受信装置200において、他の装置との通信が終了したら、受信装置200が、再送要求を出すべく、ボディ部が空のINVITEリクエストを送信し、送信装置100が、その再送要求を受けると、コンテンツデータの送信を行うべく、200 OKレスポンスを返信する。
【選択図】図1

Description

本発明は、コンテンツなどのデータを送信するためのデータ送信システムに関するものである。なお、本明細書中において、「コンテンツ」とは、文書、画像、またはそれら組み合わせた情報などを言い、また、「コンテンツデータ」とは、上記コンテンツを表すデータを言う。
従来、送信側から受信側にコンテンツを送信し、受信側で印刷を行う場合、ファクシミリなどが利用されていた。ファクシミリによる場合、送信に人手や時間は要しないものの、通信費用が発生し、また、受信側で受け取って印刷されるコンテンツ自体も高品質なものを期待できないという問題があった。
一方、近年では、インターネットの発達などによって、情報を無料に近い低コストで送信することが可能となっている。また、高性能なプリンタや複合機などの開発によって、家庭内でも、比較的低コストで、高品質な印刷を行うことができるようになってきている。
そこで、パーソナルコンピュータや複合機などを含む送信装置から、上記したインターネットなどのネットワークを介して、プリンタや複合機などを含む受信装置に、コンテンツデータを、低コストで、かつ、高品質にて配信することができる、システムの開発が待たれている。
なお、ネットワークを利用した情報の送信に関しては、例えば、下記の特許文献に記載のものが知られている。
特開2005−109701号公報 特開2003−178028号公報 特表2005−516320号公報
上記したシステムでは、送信先が通信中である場合、送信装置は、送信先の通信中の状態が解放されない限り、リダイアルを繰り返すことになるため、送信装置における通信処理の負荷が大きくなると共に、無駄な通信が発生してしまうという問題があった。
従って、本発明の目的は、上記した従来技術の課題を解決し、送信先が通信中である場合に、送信装置がリダイアルを繰り返すことになく、送信先の通信中の状態が解放された後に受信装置にコンテンツなどのデータを送信することができる技術を提供することにある。
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
[適用例1]
送信装置から受信装置にデータを送信するためのデータ送信システムであって、
前記送信装置が、前記受信装置に対し、前記データの送信を打診する旨の要求を送信した際に、前記受信装置が他の装置と通信中である場合、前記受信装置は、前記送信装置に対し、通信中である旨の応答を返信し、前記送信装置は、前記応答を受信したら、前記データの送信に関して待機状態となると共に、
前記受信装置は、前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信し、前記送信装置は、前記再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信することを特徴とするデータ送信システム。
このように、適用例1のデータ送信システムでは、送信装置が、データの送信を打診する旨の要求を出した際に、受信装置が他の装置と通信中である場合、送信装置が受信装置から通信中である旨の応答を受けると、データ送信に関して待機状態となるようにしている。従って、送信装置はリダイアルを繰り返すことがないため、送信装置における通信処理の負荷を抑制することでき、無駄な通信が発生する恐れもなくなる。
また、その後、他の装置との通信が終了したら、受信装置が送信装置にデータについての再送要求を出し、送信装置が、その再送要求を受けると、受信装置にデータの送信を行う旨の応答を返信するようにしている。従って、受信装置において、通信中の状態が解放されると、送信装置は、受信装置からの再送要求により、受信装置に対するデータの送信を実行することができる。
[適用例2]
適用例1に記載のデータ送信システムにおいて、
前記送信装置は、前記データを送信すべき送信先に関する情報と、送信すべき前記データに関する情報と、再送要求待ちの状態か否かを示す情報と、をリストで管理すると共に、
前記受信装置は、前記データの送信の打診を受けた送信元に関する情報をリストで管理することを特徴とするデータ送信システム。
このように、送信装置では、上記リストで管理することにより、送信先毎に、再送要求待ちの状態か否かを把握することができる。また、送信装置では、上記リストで管理することにより、再送要求を出すべき送信元を把握することができる。
[適用例3]
受信装置にデータを送信するための送信装置であって、
前記受信装置に対し、前記データの送信を打診する旨の要求を送信した後に、前記受信装置から、他の装置と通信中である旨の応答を受信したら、前記データの送信に関して待機状態となると共に、
前記受信装置から、前記データについての再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信することを特徴とする送信装置。
送信装置を、このように構成することにより、適用例1と同様の効果を奏することができる。
[適用例4]
送信装置から送信されたデータを受信するための受信装置であって、
前記送信装置から、前記データの送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信すると共に、
前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信することを特徴とする送信装置。
受信装置を、このように構成することにより、適用例1と同様の効果を奏することができる。
[適用例5]
送信装置から受信装置にデータを送信するためのデータ送信方法であって、
(a)前記送信装置が、前記受信装置に対し、前記データの送信を打診する旨の要求を送信する工程と、
(b)前記受信装置が、前記送信装置から、前記送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信する工程と、
(c)前記送信装置が、前記受信装置から、前記通信中である旨の応答を受信したら、前記データの送信に関して待機状態となる工程と、
(d)前記受信装置が、前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信する工程と、
(e)前記送信装置が、前記受信装置から、前記再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信する工程と、
を備えるデータ送信方法。
このように、適用例5のデータ送信方法によれば、適用例1と同様の効果を奏することができる。
[適用例6]
受信装置にデータを送信するためのコンピュータプログラムであって、
前記受信装置に対し、前記データの送信を打診する旨の要求を送信した後に、前記受信装置から、他の装置と通信中である旨の応答を受信したら、前記データの送信に関して待機状態となる機能と、
前記受信装置から、前記データについての再送要求を受信したら、前記受信装置に対し、前記データの送信を行う旨の応答を返信する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
このうように、適用例6のコンピュータプログラムによれば、適用例3と同様の効果を奏することができる。
[適用例7]
送信装置から送信されたデータを受信するためのコンピュータプログラムであって、
前記送信装置から、前記データの送信を打診する旨の要求を受信した際、他の装置と通信中である場合に、前記送信装置に対し、通信中である旨の応答を返信する機能と、
前記他の装置との通信が終了したら、前記送信装置に対し、前記データについての再送要求を送信する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
このうように、適用例7のコンピュータプログラムによれば、適用例4と同様の効果を奏することができる。
なお、本発明は、上記したデータ送信システムや送信装置や受信装置などの装置発明の態様や、データ送信方法などの方法発明の態様や、それら方法や装置を構築するためのコンピュータプログラムとしての態様に限ることなく、そのようなコンピュータプログラムを記録した記録媒体としての態様など、種々の態様で実現することも可能である。
以下、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
A.実施例の構成:
B.実施例の動作:
B−1.登録動作:
B−2.送信準備動作:
B−3.セッション確立動作開始:
B−4.受信可能である場合:
B−5.通信中である場合:
B−6.再送要求処理:
B−7.未送信リストに対応レコードが保存されている場合:
B−8.未送信リストに対応レコードが保存されていない場合:
B−9.再送要求でない場合:
B−10.送信装置が通信中である場合:
C.実施例の効果:
D.変形例:
A.実施例の構成:
図1は本発明の一実施例としてのデータ送信システムの概略構成を示すブロック図である。
図1に示すとおり、本実施例のデータ送信システムは、送信装置100と、受信装置200と、SIP(Session Initiation Protocol)サーバ300と、で構成される。このうち、送信装置100は、コンテンツなどのデータの送信を希望する送信側ユーザによって管理され、受信装置200は、送信されたデータを受け取る受信側ユーザによって管理される。SIPサーバ300は、例えば、ネットワークサービス提供業者などによって管理される。
送信装置100,受信装置200及びSIPサーバ300は、インターネットを含む、いわゆるブロードバンドネットワーク400を介して接続されている。
このうち、送信装置100及び受信装置200は、それぞれ、複合機で構成されている。すなわち、送信装置100及び受信装置200は、図1に示すように、プログラムを実行することにより種々の処理や制御を行うCPU102または202と、プログラムを格納したり、データや情報を格納したりするためのメモリ104または204と、ネットワークを介して他の装置との間で各種データや情報などの伝送を行う通信部106または206と、タッチパネルなどから成り、ユーザからの指示などを入力するための操作部108または208と、液晶パネルなどから成り、取得したデータや情報などを表示するための表示部110または210と、イメージセンサなどから成り、原稿などの紙からコンテンツである画像などを読み取るための読取部112または212と、プリンタコントローラやプリンタエンジンなどから成り、コンテンツの印刷を行うための印刷部114または214と、を主として備えている。このうち、通信部106または206は、LANケーブルなどを介してネットワーク400に接続されている。また、送信装置100のメモリ104には、未送信リスト120が、受信装置200のメモリ204には、未受信リスト222が、それぞれ用意されている。
一方、SIPサーバ300も、CPUやメモリなど、各種構成要素を備えているが、図では省略されている。
本実施例では、文書,画像などのコンテンツが、コンテンツデータとして、後ほど詳述するように、送信装置100によって、受信装置200にPUSH型で送信される。ここで、このような送信されるコンテンツデータとしては、例えば、JPEGデータ、GIFデータ、PNGデータ、TIFFデータ、プレーンテキストデータ、HTMLデータ、PDFデータ、PostScript(登録商標)データなど、画像やドキュメントを表現することが可能な各種データを用いることができる。また、ここで、「PUSH型」とは、端末側が情報をリクエストしなくても、サーバ側が一方的に情報を端末に送り出す方法を言う。なお、コンテンツデータの送信、すなわち、装置間におけるコンテンツデータの伝送には、データ転送プロトコルの一種であるHTTP(Hypertext Transfer Protocol)を用いるようにしている。
また、本実施例では、上述したコンテンツデータの送信に先立って、シグナリングプロトコルの一種であるSIP(Session Initiation Protocol)を用いて、SIPサーバ300を介して、装置間、すなわち、送信装置100と受信装置200との間におけるセッションの確立を行うようにしている。ここで、「セッション」とは、端末などのノード間でメディアストリームを送受信する関係を言う。
なお、本実施例において、送信装置100は、請求項における送信装置に、受信装置200は、請求項における受信装置に、それぞれ相当する。
図2は一般的なSIPサーバの種別を示す説明図である。一般に、SIPサーバは、機能に応じて、図2に示すような種別に分けることができる。
レジストラは、SIPクライアント(すなわち、SIPユーザエージェント)からの登録要求を受け付けて、SIPクライアントのSIPアドレス(すなわち、SIP−URI(Uniform Resource Identifier))や位置情報(すなわち、IP(Internet Protocol)アドレスなど)を、ロケーションサーバに登録する。ロケーションサーバは、SIPクライアントやサーバのSIPアドレスや位置情報などを格納するデータベースである。プロキシサーバは、SIPクライアント間において、リクエストやレスポンスを中継するサーバであって、SIPクライアント間におけるセッションの確立などを仲介する。リダイレクトサーバは、SIPクライアントからの問い合わせに対して、通信したい相手先の位置情報を通知する。プレゼンスサーバは、SIPクライアントに関するプレゼンス情報を取得し、管理すると共に、それらのプレゼンス情報を他のSIPクライアントに提供する。
また、インターネットを含むネットワーク400では、グローバル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)の技術などを用いることによって、そのような問題は解決することができる。
B.実施例の動作:
B−1.登録動作:
図1において、まず、送信装置100,受信装置200は、それぞれ、起動すると、SIPサーバ300にSIPクライアントとしてアクセスする。そして、送信装置100,受信装置200は、アクセスしたSIPサーバ300にそれぞれ登録要求を出し、自身のSIP−URIやIPアドレスなどの情報を送信する。SIPサーバ300は、レジストラ,ロケーションサーバとして機能し、送信装置100,受信装置200からの登録要求を受け付け、送信された情報を登録情報として登録する。
ここで、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」を置く。
本実施例において、送信装置100及び受信装置200のSIP−URIは、それぞれ、以下の通りとする。
送信装置100:sip:a@hoge.com
受信装置200:sip:b@hoge.com
こうして、SIPに関する事前準備が完了したら、SIPを利用した、装置間におけるセッションの確立及びデータの送信を行うことが可能となる。
B−2.送信準備動作:
まず、送信側では、例えば、送信側ユーザが、送信装置100において、送信したい画像などのコンテンツを読取部112で読み取らせ、コンテンツデータとしてメモリ104に格納させる。その上で、送信側ユーザは、操作部108を介して、メモリ104に格納されたコンテンツデータの中から、送信したいコンテンツデータを特定すると共に、送信したい送信先のSIP−URIを、送信装置100に入力する。
本実施例では、送信装置100のCPU102は、送信すべきコンテンツに、一意に識別できるコンテンツIDを割り振って、コンテンツの管理を行うようにしている。コンテンツIDとしては、例えば、英数字の組み合わせや数字列などを用いることができる。なお、送信装置100が、今回、送信しようとしているコンテンツのコンテンツIDは、「101」であるものとする。
また、コンテンツデータとしては、予め、メモリ104内に用意されているものを用いるてもよく、また、送信先のSIP−URIとしては、予め、送信先リストなどに登録されているものを用いてもよい。
その後、送信側ユーザが、操作部108を介して、送信開始の指示を送信装置100に入力すると、CPU102は、通信部106からSIPサーバ300を介して、受信装置200との間でセッションの確立を開始する。
B−3.セッション確立動作開始:
図3は通常時における送信装置100と受信装置200との間のセッション確立処理のシーケンスを示す説明図である。図3において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。
そこで、送信装置100において、CPU102は、自身のIPアドレスを受信装置200に伝えるために、INVITEリクエストのボディの中に送信装置100のIPアドレス(実際には、送信装置100に接続されるルータのグローバルIPアドレス)を挿入し、そのINVITEリクエストを、通信部106からSIPサーバ300を介して受信装置200に送信する。
そして、CPU102は、INVITEリクエストの送信を開始すると、まず、メモリ104内に用意されている未送信リスト120に、図4に示すような送信に関するレコードを保存する。
図4は図1の未送信リスト120に保存されるレコードの一例を示す説明図である。図4に示すように、未送信リスト120では、1つのレコードは、インデックス,送信先,コンテンツID,再送要求待ちフラグの各項目から成る。各項目の意味は、それぞれ、以下の通りである。
インデックス:リスト上のレコードの順番を示すものである。
コンテンツID:前述したとおり、送信装置100において、送信しようとしているコンテンツを一意に識別できるものである。
送信先:受信側のSIP−URIが入る。
再送要求待ちフラグ:受信側が通信中で送信ができなかった場合は、フラグとして「1」が設定され、初回の送信時には「0」が設定される。
従って、今回、未送信リスト120に保存されるレコードは、図4に示すように、インデックスが「1」で、送信先が、受信装置200のSIP−URIである「sip:b@hoge.com」となっており、コンテンツIDが、上記したとおり「101」となっており、再送要求待ちフラグは、送信が初回であるため、「0」となっている。
こうして、未送信リスト120に送信に関するレコードを保存した後、CPU102は、受信装置200からのレスポンス待ちの状態となる。
これに対し、受信装置200では、CPU202が、送信されたINVITEリクエストを通信部206を介して受信すると、まず、メモリ204内に用意されている未受信リスト222に、図5に示すような受信に関するレコードを保存する。
図5は図1の未受信リスト222に保存されるレコードの一例を示す説明図である。図5に示すように、未受信リスト222では、1つのレコードは、インデックス,送信元の各項目から成る。各項目の意味は、それぞれ、以下の通りである。
インデックス:リスト上のレコードの順番を示すものである。
送信元:コンテンツを送信してきた送信側のSIP−URIが入る。
このように、受信側の場合、送信側とは異なり、未受信リスト222にレコードとして保存するのは、送信元のSIP−URIだけであり、コンテンツのIDは保存しない。
従って、今回、未受信リスト222に保存されるレコードは、図5に示すように、インデックスが「1」で、送信元が、送信装置100のSIP−URIである「sip:a@hoge.com」となっている。
B−4.受信可能である場合:
こうして、未受信リスト222に受信に関するレコードを保存すると、次に、CPU202は、自身(受信装置200)の通信状況を判断し、その結果、送信装置100からのコンテンツデータの受信が可能である場合には、200 OKレスポンスを、送信装置100に対して返信する。
すなわち、CPU202は、自身のIPアドレスを送信装置100に伝えるために、200 OKレスポンスのボディの中に受信装置200のIPアドレス(実際には、受信装置200に接続されるルータのグローバルIPアドレス)を挿入し、その200 OKレスポンスを、通信部206からSIPサーバ300を介して送信装置100に送信する。
また、CPU202は、図5に示す未受信リスト222から、送信元が送信装置100となっている(すなわち、「sip:a@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除する。
これに対し、送信装置100では、CPU102が、通信部106を介して、受信装置200からの200 OKレスポンスを受信すると、セッションを確立すべく、図3に示す、以降の処理を続行する。そして、送信装置100から送信されたACKリクエストが、SIPサーバ300を介して、受信装置200に到達したら、送信装置100と受信装置200との間のセッションは確立されたことになる。
その後、送信装置100において、CPU102は、200 OKレスポンスから取得した受信装置200のIPアドレスに基づいて、受信装置200に、SIPサーバ300を介することなく、直接アクセスして、HTTPに従ってコンテンツデータをPUSH型で送信する。そして、送信が完了すると、CPU102は、図4に示す未送信リスト120から、送信先が受信装置200となっている(すなわち、「sip:b@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除する。
また、受信装置200が、コンテンツデータの受信が完了したら、送信装置100において、CPU102は、再び、SIPに従って、BYEリクエストをSIPサーバ300を介して受信装置200に送信する。受信装置200において、CPU202が、BYEリクエストを受信すると、200 OKレスポンスを、SIPサーバ300を介して送信装置100に返す。これにより、送信装置100と受信装置200との間のセッションが解消される。また、受信装置200では、CPU202が、受信したコンテンツデータに基づいて、印刷部214を制御して印刷を実行し、印刷されたコンテンツを出力する。
こうして、受信装置200において、送信装置100からのコンテンツデータの受信が可能である場合には、両者の間でセッションの確立がなされ、送信装置100から受信装置200へコンテンツデータの送信が行われる。
B−5.通信中である場合:
図6は受信装置200が他の装置と通信中である場合における送信装置100と受信装置200との間の処理のシーケンスを示す説明図である。図6において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。
受信装置200において、CPU202が、自身(受信装置200)の通信状況を判断した結果、自身(受信装置200)が他の装置(図示せず)と通信中であり、送信装置100からのコンテンツデータの受信が不可能である場合には、CPU202は、図6に示すように、486 Busy Hereレスポンスを、送信装置100に対して返信する。ここで、486 Busy Hereレスポンスとは、INVITEリクエストを受け取ったときに、既に別の通信を行っているなどの理由で、今回の通信を始めることができないということを送信元に知らせるためのレスポンスである。
また、CPU202は、他の装置と通信中である場合は、図5に示す未受信リスト222において、レコードをそのままの状態で保持しておく。その後、他の装置との通信が終了すると、CPU202は、後述する再送要求処理に移る。
これに対し、送信装置100では、CPU102が、通信部106を介して、受信装置200からの486 Busy Hereレスポンスを受信すると、ACKリクエストを送信し、セッションを終了する。
図7は図1の未送信リスト120に保存されているレコードについて、486 Busy Hereレスポンス受信後の状態を示す説明図である。
また、CPU102は、今回、受信装置200が通信中でデータの送信ができなかったため、図4に示す未送信リスト120のうち、送信先が受信装置200となっている(すなわち、「sip:b@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)について、図7に示すように、再送要求待ちフラグを「0」から「1」に変更する。そして、送信装置100のCPU102は、受信装置200に対するデータ送信に関し、受信装置200から再送要求が届くまで、待機状態となる。
ところで、上記した例では、同一の送信先に対して、送信したいコンテンツデータは1つであったため、未送信リスト120では、1つのレコードに対して、含まれているコンテンツIDは1つであった。しかし、同一の送信先に対して、送信したいコンテンツデータが複数ある場合には、未送信リスト120は、図8に示す如くになる。
図8は図1の未送信リスト120に保存されるレコードの他の例を示す説明図である。図8に示す未送信リスト120では、送信先が2箇所あり(すなわち、「sip:b@hoge.com」と「sip:c@hoge.com」)、各送信先について、送信したいコンテンツデータがそれぞれ2つあることを示している。すなわち、1つの送信先に対し、複数のコンテンツIDが紐付けられており、再送要求待ちフラグについても、コンテンツID毎ではなく、1つの送信先に紐付けられている。これは、後述する再送時において、その送信先に対して、紐付けられている全てのコンテンツデータを一括で送信することを目的としている。
一方、受信装置200において、他の装置との通信中に、別の複数の装置からコンテンツデータ送信の打診があった場合に、未受信リスト222は、図9に示す如くになる。
図9は図1の未受信リスト222に保存されるレコードの他の例を示す説明図である。図9に示す未受信リスト222では、送信元が2箇所であった場合(すなわち、「sip:a@hoge.com」と「sip:d@hoge.com」)を示している。
なお、受信装置200において、他の装置との通信中に、別の1つの装置から複数の異なるコンテンツデータについての送信の打診(すなわち、INVITEリクエストの送信)がある場合も考えられる。例えば、他の装置との通信中に、送信装置100(すなわち、「sip:a@hoge.com」)から、最初に或るコンテンツデータについての送信の打診があり、引き続き他の装置との通信中に、再び、同じ送信装置100(すなわち、「sip:a@hoge.com」)から、最初の送信打診とは異なる別のコンテンツデータについての送信の打診がある場合である。このような場合には、受信装置200において、CPU202は、まず、未受信リスト222内に、同じ送信元に関するレコードが保存されているどうかを判断し、同じ送信元に関するレコードが既に保存されていれば、未受信リスト222の更新は行わない。反対に、同じ送信元に関するレコードが保存されてない場合には、その送信元についてのレコードを追加して保存するようにする。これは、受信装置200では、未受信リスト222にある送信元に対して、1つずつコンテンツデータの再送を要求するのではなく、受信することのできなかったコンテンツデータを全て一括で再送してもらうことを目的としている。
B−6.再送要求処理:
前述した通り、受信装置200において、他の装置との通信が終了すると、CPU202は、再送要求処理に移行し、まず、メモリ204内の未受信リスト222を参照する。参照した結果、未受信リスト222に、1つもレコードが保存されていない場合、すなわち、未受信リスト222が空の場合には、CPU202は、直前の他の装置との通信中に、別の何れの装置からもコンテンツデータ送信の打診(すなわち、INVITEリクエストの送信)がなかったものとして、待機状態となる。
反対に、参照した結果、未受信リスト222に、1つ以上のレコードが保存されている場合には、CPU202は、他の装置との通信中に、別の装置からコンテンツデータ送信の打診(すなわち、INVITEリクエストの送信)があったものと判断し、未受信リスト222に保存されている先頭のレコードから順番に、以下の処理を行う。
まず、CPU202は、未受信リスト222のうち、対象となるレコードから送信元のSIP−URIを取得する。次に、CPU202は、そのSIP−URIに基づき、送信元に対して、コンテンツデータの再送要求を行う。具体的には、送信元に対して、INVITEリクエストを送信する。但し、そのINVITEリクエストは、常のINVITEリクエストとは異なり、ボディ部が空となっている。すなわち、この送信元に対して行われる再送要求は、特定のコンテンツデータの再送を要求しているではなく、送信したいコンテンツデータがあれば、全て送信するよう、要求するものだからである。また、このように、ボディ部が空であるINVITEリクエストを送信することにより、INVITEリクエストを受け取った側、すなわち、送信元では、ボディ部が空であるか否かでもって、通常のコンテンツデータ送信の打診であるのか、それとも、コンテンツデータの再送要求であるかを判断することができる。
これに対し、送信元である送信装置100では、CPU102が、受信装置200からINVITEリクエストを受信すると、まず、自身(送信装置100)の通信状況を判断する。判断の結果、自身(送信装置100)が他の装置(図示せず)と通信中でない場合には、次に、CPU102は、受信したINVITEリクエストについて、前述した通り、ボディ部が空であるか否かを判断する。判断の結果、ボディ部が空であった場合、CPU102は、そのINVITEリクエストは、コンテンツデータの再送要求であると判断する。
B−7.未送信リストに対応レコードが保存されている場合:
次に、CPU102は、そのINVITEリクエストにおけるToヘッダより、再送要求元のSIP−URI(すなわち、この場合、受信装置200のである「b@hoge.com」)を取得する。さらに、CPU102は、取得したSIP−URIに基づき、未送信リスト120内に、そのSIP−URIを含むレコードが保存されているかどうかを検索する。検索の結果、そのレコードが保存されている場合には、そのSIP−URIに対応した送信先から、再送要求があったことになるため、そのレコードについて、図4に示したように、再送要求待ちフラグを「1」から「0」に変更する。また、そのレコードが保存されていると言うことは、そのSIP−URIに対応した再送要求元、すなわち、受信装置200に対して、再送すべきコンテンツデータ(すなわち、未送信のコンテンツデータ)が存在するということであるため、それらコンテンツデータを特定するために、そのレコードに含まれる全てのコンテンツIDを取得する。
次に、CPU102は、コンテンツデータの再送を行うために、取得した各コンテンツIDに基づいて、そのコンテンツIDの本体であるコンテンツデータをメモリ104からそれぞれ読み出し、再送準備に入る。具体的には、CPU102は、200 OKレスポンスのボディ部に記述すべき内容を、SDP(Session Description Protocol)を用いて生成する。そして、再送準備が完了したら、CPU102は、受信装置200に対して、その200 OKレスポンスを送信する。
受信装置200では、CPU102が、この200 OKレスポンスを受信すると、SDPを用いて記述されたボディ部の内容を解析して、送信予定のコンテンツデータが印刷部214で印刷可能であるかどうかを判断する。印刷可能であれば、CPU202は、送信装置100に対して、ACKリクエストを送信する。通常、ACKリクエストには、ボディ部が含まれていないが、本実施例では、このような再送処理の場合、CPU202が、SDPを用いて印刷可能なコンテンツデータに対応した内容を、ACKリクエストのボディ部に付加した上で、そのACKリクエストを送信するようにしている。
このACKリクエストが受信装置200に到達すると、前述した通り、送信装置100と受信装置200との間のセッションが確立されたことになるため、送信装置100において、CPU102は、受信装置200に対し、先に読み出した全てのコンテンツデータ(すなわち、未送信であった全てのコンテンツデータ)を送信する。そして、送信が完了すると、CPU102は、未送信リスト120から、送信先が受信装置200となっている(すなわち、「sip:b@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除する。また、受信装置200でも、送信されたコンテンツデータの受信が完了すると、CPU202は、未受信リスト222から、送信元が送信装置100となっている(すなわち、「sip:a@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除する。
B−8.未送信リストに対応レコードが保存されていない場合:
図10は未送信リストに対応レコードが保存されていない場合における送信装置100と受信装置200との間の処理のシーケンスを示す説明図である。図10において、時間は上から下に向かって流れている。また、カギ括弧内の数の順番に、処理シーケンスは進んでいく。
送信装置100において、CPU102が、前述したように、取得したSIP−URIに基づき、未送信リスト120内に、そのSIP−URIを含むレコードが保存されているかどうかを検索した結果、そのレコードが保存されていない場合には、そのSIP−URIに対応した再送要求元、すなわち、受信装置200に対して、再送すべきコンテンツデータがないものとして、図10に示すように、415 Unsupported Media Typeレスポンスを、受信装置200に返信する。送信装置100において、何らかの理由で(例えば、送信側ユーザの気が変わったなど)、受信装置200に送信すべきコンテンツデータを削除してしまった場合などが、これに該当する。この場合においても、受信装置200では、CPU202が、未受信リスト222から、送信元が送信装置100となっている(すなわち、「sip:a@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除し、以降、再送要求は行わない。
B−9.再送要求でない場合:
ところで、送信装置100において、CPU102が、受信したINVITEリクエストについて、ボディ部が空であるか否かを判断した結果、ボディ部が空でなく、ボディ部が存在していた場合には、そのINVITEリクエストは、再送要求ではなく、通常のINVITEリクエストであると認識する。その場合、CPU102は、受信装置200から送信装置100へのデータの送信の打診が行われたものとして判断して、以降、処理を行う。また、この場合、受信装置200からの再送要求ではないため、CPU102は、未送信リスト120において、送信先が受信装置200となっている(すなわち、「sip:b@hoge.com」となっている)レコードについて、再送要求待ちフラグは「1」のままとして変更しない。
B−10.送信装置が通信中である場合:
さて、送信装置100において、CPU102が、受信装置200からINVITEリクエストを受信した際、前述したように、自身(送信装置100)の通信状況を判断するが、判断の結果、自身(送信装置100)が他の装置(図示せず)と通信中である場合には、受信装置200に対して、486 Busy Hereレスポンスを送信する。さらに、CPU102は、受信したINVITEリクエストについて、ボディ部が空であるか否かを判断し、ボディ部が空であった場合、そのINVITEリクエストが、コンテンツデータの再送要求であると判断する。そして、CPU102は、そのINVITEリクエストにおけるToヘッダより、再送要求元のSIP−URI(この場合、「sip:b@hoge.com」)を取得し、そのSIP−URIに基づき、未送信リスト120内に、そのSIP−URIを含むレコードが保存されているかどうかを検索する。検索の結果、そのレコードが保存されている場合には、そのレコードについて、再送要求待ちフラグを「1」から「0」に変更する。
これに対し、受信装置200では、CPU202が、送信装置100から486 Busy Hereレスポンスを受信すると、未受信リスト222から、送信元が送信装置100となっている(すなわち、「sip:a@hoge.com」となっている)レコード(すなわち、インデックスが「1」のレコード)を削除し、これにより、以降、送信装置100に対する再送要求は、行わないことになる。すなわち、送信装置100から、再送要求に対する送信処理ではなく、通常の送信処理としてやり直してもらう形となる。
一方、送信装置100では、他の装置との通信が終了した後、CPU102は、未送信リスト120を検索して、再送要求待ちフラグが「0」となっているレコードについそのレコードに含まれる送信先に対して、再び、送信処理を行う。今回は、再送要求ではないので、受信装置200に対しては、通常のボディ部が存在するINVITEリクエストを送信することになる。
なお、送信装置100において、他の装置との通信中であっても、CPU102が、受信したINVITEリクエストについて、ボディ部が空であるか否かを判断した結果、ボディ部が空でなく、ボディ部が存在していた場合には、CPU102は、そのINVITEリクエストが、再送要求ではなく、通常のINVITEリクエストであると認識する。従って、この場合、CPU102は、受信装置200からの再送要求ではないため、未送信リスト120において、送信先が受信装置200となっているレコードについて、再送要求待ちフラグは「1」のままとして変更しない。
C.実施例の効果:
以上説明したように、本実施例では、送信装置100が、コンテンツデータの送信を行うべく、INVITEリクエストを送信した際に、受信装置200が他の装置と通信中である場合、送信装置100が、受信装置200から415 Unsupported Media Typeレスポンスを受信すると、送信装置100は、そのコンテンツデータの送信に関して待機状態となるようにしている。従って、本実施例によれば、送信装置100は、リダイアルを繰り返すことがないため、送信装置100における通信処理の負荷を抑制することでき、無駄な通信が発生する恐れもなくなる。
また、その後、受信装置200において、他の装置との通信が終了したら、受信装置200が、再送要求を出すべく、ボディ部が空のINVITEリクエストを送信し、送信装置100が、その再送要求を受けると、コンテンツデータの送信を行うべく、200 OKレスポンスを返信するようにしている。従って、本実施例によれば、受信装置200において、通信中の状態が解放されると、送信装置100は、受信装置200からの再送要求により、受信装置200に対するデータの送信を実行することができる。
D.変形例:
なお、本発明は上記した実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。
上記した実施例では、送信装置100に、未送信リスト120を用意し、受信装置200に、未受信リスト222を用意するものとして説明したが、送信装置100,受信装置200は、何れも複合機で構成されているため、別の局面においては、送信装置100が、受信側(すなわち、受信装置)となり、受信装置200が、送信側(すなわち、送信装置)となり得る。従って、実際には、送信装置100,受信装置200の何れも、未送信リストと未受信リストの両方が用意されており、これら装置は、未送信リストと未受信リストの両方を管理することになる。
そこで問題となるのは、同じ相手方装置からの送信と受信が重なる場合である。すなわち、未送信リストと未受信リストの両方が存在(同じ相手方装置への未送信と同じ相手方装置からの未受信とが存在)する場合、何れのリストを優先すべきかが問題となる。このような場合、未受信リストを優先することが好ましい。すなわち、自装置に、未受信リストが存在する場合は、その未受信リストに関わる処理、すなわち再送要求処理を優先して行い、この再送要求処理が終了した段階で、未送信リストに関わるの処理に移行するものとする。再送要求に失敗すると(再送要求を出したが、相手方装置が他の装置と通信中だった場合)、未受信リストから、再送要求すべき送信元は一旦削除されるため、何れかのタイミングで、未受信リストは必ず空となる。未受信リストが空になった段階で、未送信リストに関する処理を行えばよい。
上記した実施例では、送信装置100及び受信装置200をそれぞれ複合機で構成するようにしていたが、本発明はこれに限定されるものではなく、例えば、パーソナルコンピュータや、ファクシミリや、プリンタなどを用いるようにしてもよい。また、装置同士は、ケーブルなど有線で接続される代わりに、いわゆる無線LANや、ブルートゥースや、赤外線など、無線で接続されてもよい。
上記した実施例においては、シグナリングプロトコルの一種である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サーバの種別を示す説明図である。 通常時における送信装置100と受信装置200との間のセッション確立処理のシーケンスを示す説明図である。 図1の未送信リスト120に保存されるレコードの一例を示す説明図である。 図1の未受信リスト222に保存されるレコードの一例を示す説明図である。 受信装置200が他の装置と通信中である場合における送信装置100と受信装置200との間の処理のシーケンスを示す説明図である。 図1の未送信リスト120に保存されているレコードについて、486 Busy Hereレスポンス受信後の状態を示す説明図である。 図1の未送信リスト120に保存されるレコードの他の例を示す説明図である。 図1の未受信リスト222に保存されるレコードの他の例を示す説明図である。 未送信リストに対応レコードが保存されていない場合における送信装置100と受信装置200との間の処理のシーケンスを示す説明図である。
符号の説明
100…送信装置
102…CPU
104…メモリ
106…通信部
108…操作部
110…表示部
112…読取部
114…印刷部
120…未送信リスト
200…受信装置
202…CPU
204…メモリ
206…通信部
214…印刷部
222…未受信リスト
300…SIPサーバ
400…ネットワーク

Claims (7)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008081315A JP2009239497A (ja) 2008-03-26 2008-03-26 データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008081315A JP2009239497A (ja) 2008-03-26 2008-03-26 データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム

Publications (1)

Publication Number Publication Date
JP2009239497A true JP2009239497A (ja) 2009-10-15

Family

ID=41252949

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008081315A Pending JP2009239497A (ja) 2008-03-26 2008-03-26 データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム

Country Status (1)

Country Link
JP (1) JP2009239497A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011151604A (ja) * 2010-01-21 2011-08-04 Oki Networks Co Ltd 信号処理装置及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011151604A (ja) * 2010-01-21 2011-08-04 Oki Networks Co Ltd 信号処理装置及びプログラム

Similar Documents

Publication Publication Date Title
US20090201535A1 (en) Posting server, sending terminal, posting server control method, and sending terminal control method
US8577954B2 (en) Posting server, content transmission system, and posting server control method
JP5245612B2 (ja) ポスティングサーバ、および、ポスティングサーバ制御方法
US20090201536A1 (en) Posting server, printing terminal, posting server control method, and printing terminal control method
JP5277855B2 (ja) 送信装置およびその方法
US7801160B2 (en) Communication apparatus and data transmission method thereof
JP2008113422A (ja) ファクシミリ伝送システム、受信装置および受信方法
US20090122343A1 (en) Transmission terminal, information output device, and content transmission system
JP5157554B2 (ja) 送信装置、コンテンツ送信システム、コンテンツ送信方法及びコンピュータプログラム
US20100118341A1 (en) Printer terminal and posting server
US7990560B2 (en) IP communication apparatus, IP communication system, and data transmission method thereof
JP2009239497A (ja) データ送信システム、それに用いる送信装置及び受信装置、データ送信方法、コンピュータプログラム
US8958098B2 (en) Communication device allowing proxy reception of data directed thereto, and control method and storage medium therefor
JP5659826B2 (ja) 通信装置、通信方法及び通信プログラム
JP4577183B2 (ja) 通信端末装置およびその制御方法
JP2009193567A (ja) 送信端末、情報出力装置、コンテンツ伝送システム及び出力条件伝送方法
JP2011244302A (ja) 通信システム
JP2009193538A (ja) コンテンツ伝送システム及び印刷装置特定方法
JP2009193540A (ja) コンテンツ伝送システム、仲介サーバ及び機種情報伝送方法
JP5568924B2 (ja) 印刷システム、配信サーバー、印刷端末、配信サーバー制御プログラム、印刷端末制御プログラム
JP2010113648A (ja) コンテンツ配信システム
JP2009081852A (ja) ファイル転送システムおよびその方法
JP2011049811A (ja) 印刷システム、配信サーバー、印刷端末、配信サーバー制御方法および制御プログラム、印刷端末制御方法および制御プログラム
JP2009080805A (ja) ファイル転送システムおよびその方法
JP2014116911A (ja) 情報処理装置、その制御方法、プログラム、及び画像処理装置