JP2006333034A - 通信方法、通信システム、通信装置、プログラム - Google Patents

Abstract

【課題】データ容量やネットワーク環境の影響を受けることなく、ＳＩＰの呼制御を利用してデータ転送ができるようにする。
【解決手段】送信端末と受信端末との間では、呼制御機能とデータ転送用の通信機能とをそれぞれ独立したプロトコルで行なうが、それぞれのプロトコルを組み合わせることによりデータ転送を実現する。この際、複数の通信方式のうちの一方の通信方式に従ってデータ通信を試行し、この試行に失敗したときには他方の通信方式に従ってデータ通信を試行する。複数の通信方式のうちの何れかを種々試行することで、データ容量やネットワーク環境などの影響を受けることなく、実環境に応じた適正な通信方式を決定して、その決定した通信方式に従って、端末間で直接にあるいはデータ保存手段を利用してデータ転送ができるようになる。
【選択図】図１９

Description

本発明は、通信方法、この通信方法を実行する通信システムおよび通信装置、並びに通信装置を制御するプログラムに関する。

複数の端末間での通信が可能なネットワークにおいては様々な形態のネットワークがある。伝送プロトコルとしてＩＰ（Internet Protocol ）を利用するＩＰネットワークが広く知られている。

また、ＩＰネットワークでは、たとえば、ＩＰ電話やテレビ会議システムなどのように、音声や映像などのメディア通信を端末間で行なう仕組みも考えられており、企業ネットワークの構築など、近年、注目されている。

ここで、音声や映像などのメディア通信を行なうときには、たとえば、ＩＰ網に接続された端末間でメディア通信用のセッションの設定、変更、開放、完了応答などの呼制御をする必要があり、セッション制御用のプロトコルとして、ＳＩＰ（Session Initiation Protocol ）が注目されている。このＳＩＰは、たとえば、ＩＰネットワーク上で、電話の呼設定を実現するためのアプリケーション層プロトコルであり、ＩＥＴＦ（Internet Engineering Task Force ）で標準化されている。ＳＩＰは、アプリケーション層でセッションの設定に必要なＩＰアドレス情報や、発着端末間で使用するＲＴＰ（Real-time Transport Protocol）のＩＰアドレス情報の送受信に用いられる。ＲＴＰは、たとえば、ＩＰパケットで音声を送るＶｏＩＰ（Voice over IP ）サービスや動画を送るサービスなどで使用される実時間データ転送プロトコルであり、ＩＥＴＦ（Internet Engineering Task Force ）で標準化されている。

たとえば、近年では、呼制御プロトコルとしてのＳＩＰは、ＶｏＩＰ（インターネット電話）などを中心に広く用いられるようになり、ＳＩＰサーバを中心とするサービス基盤も整えられてきた。現在では、ＩＭ（インスタントメッセージング）サービスなどもＳＩＰを用いて実現されることが多いが、ＳＩＰは端末間で音声ファイルや画像ファイルなどの実データの転送（ファイル転送ともいう）を実現する機能は有していない。このため、ＳＩＰ以外の標準プロトコルや独自プロトコルを組み合わせることにより、このファイル転送機能を実現するいくつかの方式が提案されている（特許文献１，２を参照）。

特開2004-147128号公報 特開2004-147128号公報

しかしながら、特許文献１，２に記載の仕組みを始めとする従来の仕組みは、一般的なＶｏＩＰの呼制御では用いないＳＩＰメッセージを利用するため、ＳＩＰサーバの種類によっては通信処理がデータ転送の完了前に遮断される、あるいはＮＡＴ（Network Address Translation ）やファイアウォールを透過できない、などの問題があり、環境によらず通信を確実に行なうことのできる標準的な方法は存在しないのが現状である。

たとえば、ＳＩＰの呼制御における応答処理は通常直ちに行なわれる必要がある一方で、実データの転送（送受信）に要する時間はデータ容量に関わるのである程度の時間を要するので、ＳＩＰメッセージに直接にデータを添付して受信側に送信すると、要求される呼制御の応答処理期間内に実データの転送処理が完了しない場合が起こり得る。

また、通常、ＳＩＰ端末においては、端末相互間で通信を行なう際、データ転送を行なうために双方向で１つずつのデータチャネルを開設する必要がある。また、データチャネルを開設するために呼接続を行なう必要があり、１つの呼接続チャネルと２つのデータチャネルを開設することになる。呼接続チャネルは通常、既知のポートが割り当てられているが、データチャネルは呼制御手順において動的に決定されるためファイアウォール越しに通信する場合や、ネットワーク通信装置がＮＡＴを介して通信を行なっている場合には、決定されたデータチャネルのポートがファイアウォールやＮＡＴを通過できず、通信ができなくなるという不具合を生じる。

本発明は、上記事情に鑑みてなされたものであり、データ容量やネットワーク環境の影響を受けることなく、データ通信を確実に行なうことのできる仕組みを提供することを目的とする。

本発明に係る仕組みにおいては、先ず、通信装置には、呼制御処理を行なう呼制御処理部と、データ転送処理を行なうデータ転送処理部と、通信処理に関わる動作を制御する制御部とを設ける。なお、データ転送処理部は、送信側の通信装置にあってはデータ送信処理部であり、受信側の通信装置にあってはデータ受信処理部である。呼制御処理部は、たとえばＳＩＰに従った呼制御処理を行なうものであるのがよい。

データ通信処理に際しては、送信側と受信側の各通信装置間では、呼制御機能とデータ転送用の通信機能とをそれぞれ独立したプロトコルで行なうが、それぞれのプロトコルを組み合わせることにより、直接にまたはデータ保存手段（装置外部のものであってもよいし、自装置に内蔵のデータ保存部であってもよい）を介してデータ転送を実現する。

ここで、制御部は、複数の通信方式のうちの一方の通信方式に従ってデータ通信を試行し、この試行に失敗したときには他方の通信方式に従ってデータ通信を試行する点に大きな特徴を有する。

複数の通信方式のうちの何れかを種々試行することで、データ容量やネットワーク環境などの影響を受けることなく、実環境に応じた適正な通信方式を決定して、その決定した通信方式に従って、端末間で直接にあるいはデータ保存手段を利用してデータ転送ができるようになる。

また従属項に記載された発明は、本発明の仕組みのさらなる有利な具体例を規定する。さらに、本発明に係るプログラムは、本発明に係る通信処理を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なものである。なお、プログラムは、コンピュータ読取り可能な記憶媒体に格納されて提供されてもよいし、有線あるいは無線による通信手段を介した配信により提供されてもよい。

たとえば、データ容量および／または通信処理の面において低度の通信方式からより高度の通信方式の順に試行を行なうのがよい。たとえば、メッセージサイズやファイルデータサイズなどの取り扱い得る送信データ容量がより小容量である低度の通信方式から、扱い得る送信データ容量がより大容量である高度の通信方式の順に試行を行なうとよい。また、通信処理制御の側面においては、手順が少なく処理制御がより簡易である低度の通信方式から、手順が増え処理制御が複雑になるより高度の通信方式の順に試行を行なうとよい。より低度の通信方式からより高度の通信方式の順に試行を繰り返すようにすることで、その時点の環境に即した好適な通信方式を用いてデータ転送を効率よく行なうことができる。

また送信するデータを保存するデータ保存手段を設けておけば、データ送信の際にはデータ送信要求通知に直接にデータを添付するのではなく、送信するデータをデータ保存部に保存しておくことができる。この場合、送信側の通信装置の呼制御処理部は、データ保存部に保存したデータに対応する受信側の通信装置に公開可能なアドレスを受信側の通信装置に通知する。この通知を受けた受信側の通信装置は、送信側の通信装置からのデータ送信要求に対応する受信完了応答通知を何時行なうかに関わりなく、その公開可能なアドレスにアクセスすることで送信側の通信装置が公開するデータを取得することができる。

なお、データ保存手段は、送信側の通信装置に内蔵のものであってもよいし、外部に用意されたものを使用することもできる。ここで、送信側の通信装置に対しての外部からのアクセスを遮断するＮＡＴやファイアウォールなどの遮断手段が設けられているシステムの場合、送信側の通信装置の呼制御処理部は、送信するデータに対応した受信側の通信装置に公開可能なアドレスをＮＡＴなどの遮断手段から取得し、この取得したアドレスを受信側の通信装置に通知すればよい。

また、送信側の通信装置が、送信するデータに対応した受信側の通信装置に公開可能なアドレスをＮＡＴなどの遮断手段から取得する機能を備えていない場合には、送信側の通信装置に対して遮断手段の外側に配されている外部のデータ保存手段を利用することもできる。この場合にも、送信側の通信装置の呼制御処理部は、送信するデータに対応した受信側の通信装置に公開可能なアドレスをＮＡＴなどの遮断手段から取得し、この取得したアドレスを受信側の通信装置に通知すればよい。

何れの場合も、送信データに対応した公開アドレスを受信側に通知し、受信側では通知されたアドレスにアクセスするので、ファイアウォール越しに通信する場合や通信装置がＮＡＴを介して通信する場合でも、適切にデータ転送を行なうことができる。

また、受信側でのデータ受信処理を完了した時点で送信側に完了通知を行ない、送信側では、完了通知を受信した時点で、保存手段に保存しておいたデータを削除するのが望ましい。

本発明によれば、送信側と受信側の各通信装置間で、呼制御機能とデータ転送用の通信機能とをそれぞれ独立したプロトコルを組み合わせてデータ通信処理を行なうに際して、複数の通信方式のうちの何れか一方の通信方式に従ってデータ通信を試行し、この試行に失敗したときには他の通信方式に従ってデータ通信を試行するようにしたので、データ容量やネットワーク環境などの影響を受けることなく、データ通信を確実に行なうことができるようになる。

以下、図面を参照して本発明の実施形態について詳細に説明する。

なお、最初に、本実施形態で適用する各種通信方式についてその概要を説明し、その後に、これらの各種通信方式の中から実情に沿う最適なものを選択して、実際に通信を行なう手順について説明する。

＜第１方式および第２方式を実現するシステム構成＞
図１は、第１の通信方式や第２の通信方式（以下第１／第２方式ともいう）を実現するネットワークシステム構成の一例を示す図である。図示するように、この第１／第２方式用のネットワークシステム１は、送信側のデータ転送装置である送信端末２２と、受信側のデータ転送装置である受信端末２４と、ＷＷＷ（ＨＴＴＰ；Hypertext Transfer Protocol ）サーバやＦＴＰ（File Transfer Protocol）サーバ機能を持つＳＩＰ（Session Initiation Protocol）サーバ装置４０とが、インターネットなどの通信網９０に相互接続されて構成されている。

ＳＩＰサーバ装置４０は、通信網９０に接続された端末間でデータ通信用のセッションの設定、変更、開放、完了応答などの呼制御処理を行なう際の代行処理を行なうもので、プロキシ（proxy ；代理）機能を持つＳＩＰプロキシサーバである。

受信端末２４は、たとえばＨＴＴＰ準拠のデータ送受信プロトコルを用いるＷＷＷサーバのデータに対するブラウズ、他リンクへのジャンプ、記録出力、転送などの処理を行なうためのＷＷＷ通信機能を有する。送信端末２２と受信端末２４とを纏めてデータ通信装置２０と呼ぶ。図では、送信端末２２から受信端末２４にデータを送信する点に着目して示しているが、アプリケーションによっては双方向通信を行なう場合もあり、この場合には、各データ通信装置２０には、送信端末２２と受信端末２４の双方の機能が組み込まれることになる。

データ通信装置２０としては、たとえばテレビ会議システムなどに用いられる画像通信装置が適用される。もちろん、画像通信装置に限らず、ＩＰ電話用の通信装置など、インターネット網などを利用する通信に適したその他の一般的な情報通信装置にも適用可能である。

これらデータ通信装置２０（送信端末２２および受信端末２４）やＳＩＰサーバ装置４０には、たとえばＣＳＭＡ／ＣＤ方式などによる通信機能を実現する機能部が設けられ、またそれらを認識するためのプライベートＩＰアドレスが割り当てられている。

ネットワークシステム１では、ＳＩＰサーバ装置４０を介することで、データ通信装置２０（送信端末２２および受信端末２４）間でＳＩＰを利用して呼制御を行ない、また所定のデータを送信端末２２から受信端末２４に転送する。これにより、ＳＩＰサービス基盤上で呼接続が可能な端末間（本例では送信端末２２と受信端末２４との間）で、音声ファイルや画像ファイルなどの任意のデータファイルを転送することが可能となる。

これらの仕組みは、たとえば、インターネット電話（ＶｏＩＰ；Voice over IP）、インターネットテレビ電話、テレビ会議システム、あるいはインスタントメッセージング（ＩＭ；Instant Message）などの機能を有するデータ通信装置２０を構成する機能部により実現される場合もあれば、これらに実装されるアプリケーションソフトウエアに搭載されることで実現される場合もある。

何れにしても、このようなネットワークシステム１においては、送信側のデータ通信装置２０（送信端末２２）はＳＩＰサーバ装置４０を介して受信側のデータ通信装置２０（受信端末２４）にデータ通信処理を要求し、また受信側のデータ通信装置２０（受信端末２４）は、ＳＩＰサーバ装置４０を介して送信端末２２にデータ通信処理の要求に対応した応答処理を発するが、送信端末２２と受信端末２４との間での実データの通信処理（データ転送処理）はＳＩＰサーバ装置４０を介することなく両端末間で直接に行なう。

＜データ通信装置の構成例＞
図２は、データ通信装置２０の一構成例を示すブロック図である。図示するように、データ通信装置２０は、画像処理や通信処理などに関わる処理を行なうアプリケーション部２１０と、データ通信装置２０の各部を制御するコントローラ部２２０と、ＨＴＴＰプロトコルに従ってデータ転送のための通信処理を行なうＨＴＴＰプロトコル処理部２３２およびＦＴＰプロトコルに従ってデータ転送のための通信処理を行なうＦＴＰプロトコル処理部２３４などの各種のプロトコル処理部を有するデータ転送プロトコル処理部２３０と、ＳＩＰプロトコルに従ってデータ転送のための通信処理（特に呼制御処理）を行なうＳＩＰプロトコル処理部（ＳＩＰ＿ＵＡ）２５０と、データ転送プロトコル処理部２３０が送信するデータを一時保管するデータ保存手段としての一時データ保存部２６０とを備えている。つまり、送信するデータを一時保管するデータ保存手段の一例であるデータ保存部を、送信端末２２が内蔵している。

アプリケーション部２１０は、コントローラ部２２０と接続されており、データ転送相手装置の発見およびデータ転送を実現する機能を持つ。コントローラ部２２０は、少なくとも、通信処理に関わる動作を制御する機能を持ち、アプリケーション部２１０やデータ転送プロトコル処理部２３０やＳＩＰプロトコル処理部２５０や一時データ保存部２６０を適宜制御する。

データ転送プロトコル処理部２３０は、実データの通信処理（データ転送処理）を行なうデータ転送処理部の一例であって、送信端末２２にあってはデータ送信処理部、受信端末２４にあってはデータ受信処理部となる。これに対して、ＳＩＰプロトコル処理部２５０は、呼制御処理部の一例であって、ＳＩＰおよびＳＤＰ（Session Description Protocol：詳細はＲＦＣ２３２７を参照）を用いて、通信網９０に接続された端末間でデータ通信用のセッションの設定、変更、開放、受信完了応答通知などの呼制御処理を行なう。

一時データ保存部２６０は、データ転送プロトコル処理部２３０のＨＴＴＰプロトコル処理部２３２およびＦＴＰプロトコル処理部２３４と内部接続され、送受信されるデータの処理領域として利用されるもので、このデータ通信装置２０に内蔵のデータ保存手段である。なお、第１の通信方式を実行するに当たっては、この一時データ保存部２６０は不要である。

＜第１の通信方式＞
図３は、図１に示したネットワークシステム１における第１の通信方式の手順を説明するシーケンス図である。また、図４は、第１の通信方式で用いられるリクエストメッセージ（データ送信要求通知）の一例を示す図である。ここでは、ＳＩＰのリクエストメッセージがデータ転送に用いられていることを示すために、リクエストＵＲＩ（Uniform Resource Identifier ）にパラメータ（ｕｓｅｒ＝ｄａｔａ）を付加するものとする。後述する他の通信方式においても同様である。

この第１の通信方式は、送信端末２２と受信端末２４との間に外部からのリクエストを遮断するネットワークアドレス変換装置（ＮＡＴ；Network Address Translation ）装置やファイアウォール（ＦＷ；FireWall）装置が存在せず、送信側のデータ通信装置２０（送信端末２２；グローバルＩＰ＝“1.2.3.4”）が外部から接続可能な場合であって、またデータ容量が少ない場合に用いて好適な通信方式である。なお、この第１の通信方式の処理手順は、特開２００５−０５１４４５号公報の図１に示されているものと基本的には同じである。

先ず送信端末２２（Ｔ１）は、ＦＴＰなどのデータ転送用の標準プロトコルを利用して接続可能な状態にし、呼制御用信号（ＩＮＶＩＴＥ信号やその他の信号）を送信メッセージ中に記述する。たとえば、自端末アドレスや受信端末アドレスやサーバアドレスなどの必要な情報をＩＮＶＩＴＥメソッドやＭＥＳＳＡＧＥメソッドなどの、ＳＩＰリクエストメッセージ中に記述する。

また、送信端末２２は、第１の通信方式の特徴部分として、ＳＩＰのリクエストメッセージのボディ部に、転送するデータを直接付加して、ＳＩＰサーバ装置４０（SIP Server）に送信する。図では、ＩＮＶＩＴＥメソッドを採用し、ＩＮＶＩＴＥリクエストメッセージにＪＰＥＧ画像データを付加した場合を示している。

ＩＮＶＩＴＥリクエストメッセージを受信したＳＩＰサーバ装置４０は、ＩＮＶＩＴＥリクエストメッセージ中のＩＮＶＩＴＥ ｓｉｐヘッダに付加されているデータ転送先の受信端末２４（Ｔ２）に、そのＩＮＶＩＴＥリクエストメッセージの必要部分を転送する。このＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信応答を示す応答メッセージ“200 OK”を、ＳＩＰサーバ装置４０を介して送信端末２２に返す。この応答メッセージ“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す。

ここで、第１の通信方式においては、図４に示すように、ＩＮＶＩＴＥリクエストメッセージ（Ａ）中のContent-Typeヘッダに付加するデータの種類（図ではｉｍａｇｅ／ｊｐｅｇ）を記述するとともに、Content-Lengthヘッダに付加するデータのサイズ（図中ではｘｘｘ）を記述する。

このように、第１の通信方式では、送信側から受信側に送るデータ送信要求通知に送信するデータを添付するようにしたので、後述する第２〜第４の通信方式と比べると低レベルの通信方式ではあるもの、応答処理期間内で完結できる程度にデータ容量が少ない場合には、複雑な処理を伴うことなく、データ通信を確実に行なうことができる。

ただし、図３から明らかなように、ＳＩＰの呼制御における応答処理が直ちに行なわれるので、実データの容量が大きい場合には、転送（送受信）処理の完了以前に受信完了応答通知が発せられることも起こり得る。その最大の理由は、ＳＩＰのプロトコル仕様上メッセージサイズに制約があることであり、送信データ容量の面においては、後述する第２の通信方式などよりは低度の通信方式である。

この場合、既存のＳＩＰサーバ（本実施形態のＳＩＰサーバ装置４０に相当）はサイズの大きいＳＩＰメッセージを遮断するものが多く、受信完了応答通知を受信端末２４から受信した送信端末２２において通信処理を終了させてしまうと、実際には、実データの転送処理が適正に完了しない場合が起こり得る。この問題を解消する仕組みが、より大容量のデータを扱い得る、送信データ容量の面においてより高度な通信方式である、次の第２の通信方式などである。

＜第２の通信方式＞
図５は、図１に示したネットワークシステム１における第２の通信方式の基本手順を説明するシーケンス図である。また、図６は、第２の通信方式の基本手順で用いられるリクエストメッセージ（Ａ）、ゲットメッセージ（Ｂ）、およびデータ送信時の応答メッセージ（Ｃ）の一例を示す図である。また、図７は、第２の通信方式の改良手順を説明するシーケンス図である。

この第２の通信方式は、送信端末２２と受信端末２４との間に外部からのリクエストを遮断するＮＡＴ装置やＦｉｒｅｗａｌｌ装置が存在しない点で第１の通信方式と共通するが、データ容量が所定値よりも大きい場合に用いて好適な通信方式であり、送信側のデータ通信装置２０においては、送信するデータを一時データ保存部２６０に格納するとともに、データ転送プロトコル処理部２３０から外部に公開するＨＴＴＰやＦＴＰのＵＲＬを取得してＳＩＰのＩＮＶＩＴＥリクエストメッセージ中に記述し、受信側のデータ通信装置２０からそのＵＲＬに対しＨＴＴＰやＦＴＰなどでデータの取得を実行する点に特徴を有する。なお、この第２の通信方式の処理手順は、特開２００４−１４７１２８号公報の図４に示されているものと基本的には同じである。

先ず図５に示す基本手順においては、送信端末２２（Ｔ１）は、送信するデータを一時データ保存部２６０（Ｔ１−ｗｏｒｋ）に格納し（図中のPut [Data] ）、ＨＴＴＰなどのデータ転送用の標準プロトコルを利用して接続可能な状態にし、アドレスやパスなどの必要な情報をＩＮＶＩＴＥメソッドやＭＥＳＳＡＧＥメソッドなどの、ＳＩＰリクエストメッセージ中に記述する。また、送信端末２２は、第２の通信方式の特徴部分として、ＳＩＰのＩＮＶＩＴＥリクエストメッセージ中に、送信するデータに対応する受信端末２４に公開可能なアドレス、たとえばＨＴＴＰのＵＲＬを記述して、データ送信要求を、ＳＩＰサーバ装置４０（SIP Server）を介して受信端末２４に発する。

この際には、送信端末２２は、一時データ保存部２６０に送信するデータを格納しておき、データ転送プロトコル処理部２３０（ＨＴＴＰプロトコル処理部２３２やＦＴＰプロトコル処理部２３４）から外部に公開するＵＲＬ（Uniform Resource Locators ）を取得し、これを図６（Ａ）に示すように、ＩＮＶＩＴＥリクエストメッセージ（Ａ）中のContent-Typeヘッダに記述する。この例では、ＵＲＬを“http://1.2.3.4/someimage.jpeg”としている（図中の＊３印行を参照）。

なお、このとき、図６（Ａ）に示すように、ＩＮＶＩＴＥリクエストメッセージ（Ａ）中のContent-Typeヘッダに付加するデータの種類（図ではｍｅｓｓａｇｅ／ｅｘｔｅｒｎａｌ−ｂｏｄｙ；）を記述するとともに、ＡＣＣＥＳＳ−ＴＹＰＥヘッダにアクセスの種類（図中ではＵＲＬ）を記述する。

ＩＮＶＩＴＥリクエストメッセージを受信したＳＩＰサーバ装置４０は、ＩＮＶＩＴＥリクエストメッセージ中のＩＮＶＩＴＥ ｓｉｐヘッダに付加されているデータ転送先の受信端末２４（Ｔ２）に、そのＩＮＶＩＴＥリクエストメッセージの必要部分を転送する。このＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信応答を示す応答メッセージ“200 OK”を、ＳＩＰサーバ装置４０を介して送信端末２２に返す。この応答メッセージ“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す。

応答メッセージ“ACK ”を受信した受信端末２４は、ＩＮＶＩＴＥリクエスト中のContent-Typeヘッダに記述されたデータ転送プロトコルの種類やアドレス情報に基づいて、ＷＷＷ通信機能を用いて送信側のデータ通信装置２０から通信データを受信する。たとえば、図６（Ｂ）に示すようなゲットメッセージ（Ｂ）を送信端末２２に発してデータの取得を試みる。ここでは、“http://1.2.3.4/someimage.jpeg HTTP/1.0”を送信端末２２に発する。このゲットメッセージ（Ｂ）を受信した送信端末２２は、図６（Ｃ）に示すような、データ付きの応答メッセージ（Ｃ）“200 OK”を受信端末２４に送信する。

このように、第２の通信方式では、送信端末２２と受信端末２４との間で、呼制御機能とデータ転送用の通信機能とをそれぞれ独立したプロトコルを組み合わせてデータ通信処理を行なうようにしたので、送信端末２２からのデータ送信要求に対応する受信完了応答通知を受信端末２４において何時行なうかに関わりなく、データ保存手段に保存しておいたデータを受信側に確実に転送することができる。実データの転送処理が完了していない時点で受信端末２４のＳＩＰプロトコル処理部２５０から受信完了応答通知が発せられ送信端末２２のＳＩＰプロトコル処理部２５０がそれを受信しても、双方のデータ転送プロトコル処理部２３０間でデータ転送処理を継続することができるからである。

＜第２の通信方式の改良手順＞
ここで、第２の通信方式の基本手順では、データ送信の初期段階で送信データを一時データ保存部２６０に格納するが、その後、この一時保存した送信データ（一時データの一例）を削除可能であるかどうかを送信端末２２自身で適切かつ効率的に判断することができないという問題がある。

たとえば、受信端末２４からの受信完了応答通知を受信したことをもってデータを削除することが考えられるが、図５から明らかなように、ＳＩＰの呼制御における応答処理は直ちに行なわれるので、実データの転送（送受信）処理以前にデータを削除することになるので採用できない。また、一時データ保存部２６０の容量は有限であるから、無限に保存すると、容量オーバーになった段階で第２の通信方式を実現できなくなる。あるいは、容量オーバーになった段階で古いものから順次削除することも考えられるが、この場合、本当に削除してよいものであったのかどうかの確認ができない。

そこで、本実施形態では、この第２の通信方式が持つ問題を解消するべく、以下のような仕組みを採る。すなわち、この問題を解決するためには、ＨＴＴＰなどのデータ転送プロトコルによるデータ転送の処理結果を、送信側のデータ通信装置２０である送信端末２２に通知されなければならない。ＳＩＰサーバ装置４０との接続性やネットワークトラフィックなどの観点から、この通知は拡張などを含まない通常のＳＩＰレスポンスにより行なわれるべきである。多くのＳＩＰリクエストは、プロトコル仕様上直ちにレスポンスが送信されなければならず、一定時間（ｔ０）以内にレスポンスが返されない場合リクエストは失敗したと扱われてしまう。しかしながら、ＨＴＴＰなどのデータ転送プロトコルによるデータ送信にはｔ０以上の時間を要することが大半である。

この問題は、一旦、受信端末２４から送信端末２２に暫定レスポンスを送信することで対処し得る。本例の場合、最終レスポンスの送信を延期できる唯一のリクエストである、ＩＮＶＩＴＥリクエストを暫定レスポンスに利用するのが好適であり、これにより、前述の問題を解決することができる。

つまり、ＨＴＴＰなどのデータ転送プロトコルを利用して送信端末２２と受信端末２４との間で実際のデータ転送を行なう第２の通信方式では、図７に示す改良手順のように、送信側のデータ通信装置２０（送信端末２２；Ｔ１）はＩＮＶＩＴＥリクエストによりＵＲＬなどの情報を、ＳＩＰサーバ装置４０を介して、受信側のデータ通信装置２０（受信端末２４；Ｔ２）に通知する。ＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信完了応答通知である受信完了応答を示す応答メッセージ“200 OK”を即時に返さずに、一旦、たとえば“183 Session Progress”などの暫定レスポンスをＳＩＰサーバ装置４０を介して送信端末２２に送信することで、最終応答の送信を延期する。

そして、受信端末２４は、ＨＴＴＰなどのデータ転送プロトコルによるデータの取得を行なう。つまり、ＩＮＶＩＴＥリクエスト中のContent-Typeヘッダに記述されたデータ転送プロトコルの種類やアドレス情報に基づいて、図６（Ｂ）に示すようなゲットメッセージ（Ｂ）を送信端末２２に発してデータの取得を試みる。このゲットメッセージ（Ｂ）を受信した送信端末２２は、図６（Ｃ）に示すような、データ付きの応答メッセージ“200 OK”を受信端末２４に送信する。

受信端末２４は、このデータ受信が完了した時点で、受信完了応答（ここでは特に最終レスポンス）を示す応答メッセージ“200 OK”を、ＳＩＰサーバ装置４０を介して送信端末２２に返す。

この応答メッセージ（最終レスポンス）“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す。また、応答メッセージ（最終レスポンス）“200 OK”を受信することにより、一時データ保存部２６０は、一時保存した送信データを削除する。受信端末２４側でのデータ受信処理が完了しているので、一時データ保存部２６０は、安全かつ確実にデータを削除することができる。

なお、図７に点線で示すように、受信端末２４がデータ転送プロトコルによるデータの取得に失敗した場合には、“404 Not Found ”などの失敗応答をＳＩＰサーバ装置４０を介して送信端末２２に送信する。この失敗応答を受信した送信端末２２は、この第２の通信方式によるデータ転送に失敗したことを判断することができる。この場合、送信端末２２は、一時データ保存部２６０からの一時保存した送信データの削除を行なわず、同じ第２の通信方式もしくはさらに高度な通信方式での通信を試みる。

＜第３方式を実現するシステム構成＞
図８は、第３の通信方式（以下第３方式ともいう）を実現するネットワークシステム構成の一例を示す図である。この第３方式のネットワークシステム１は、送信端末２２がＮＡＴ装置やファイアウォール装置などの外部からのアクセスを遮断する遮断手段の配下に存在し、第２の通信方式と同一の方法では受信端末２４からデータ転送プロトコルでの接続を行なうことができない、つまり送信側のデータ通信装置２０（送信端末２２）が外部から接続不可能な場合であって、プラグ・アンド・プレイ仕様のＵＰｎＰ（Universal Plug and Play ）などのＮＡＴ装置やファイアウォールを制御するための手段が提供されている場合に用いて好適な通信方式である。

通信処理制御の面においては、第２方式よりは手順が多くより複雑な処理制御が必要となり、より高度の通信方式にはなるが、ＮＡＴ装置やファイアウォールが存在することで第２方式（通信処理制御の面で第３方式よりも低度の通信方式）では対処できない環境下においても、この第３方式を適用することで対処可能となる。

具体的には、図示するように、この第３方式用のネットワークシステム１は、第１／第２方式用のネットワークシステム１に対して、データ通信装置２０と通信網９０との間に、外部からのアクセスを遮断するネットワークアドレス変換（ＮＡＴ）装置やファイアウォール（ＦＷ）装置などの遮断装置７０が設けられている点に特徴を有する。

ここで、ＮＡＴ装置は、閉域網であるＬＡＮ（Local Area Network）内のプライベートアドレスを有する通信端末と、インターネット内のグローバルアドレスを有する通信端末との間で通信を行なうためにアドレス変換を行なうものである。通常、インターネットに接続されるＬＡＮは、セキュリティ上の理由などから、プライベートＩＰ（Internet Protocol ）と呼ばれるローカルな環境のみで利用されるＩＰアドレスを振るのが一般的であるが、この場合には、ＬＡＮ内の端末からインターネットにアクセスをするには、外のネットワークとの接合点で接続要求端末のプライベートＩＰアドレスをインターネットで利用されるグローバルＩＰアドレスに変換する必要があり、ＮＡＴによりこれを実現するようになっている。

ＦＷ装置は、インターネットとＬＡＮとの間に置かれ、データ通信を管理し、外部からの攻撃や不正アクセスから内部ネットワークを守るものである。一例として、マルチホームのホスト（複数のネットワークに接続されている装置）がある規則に従ってパケットを転送したりブロックしたりするパケット・フィルタリング・ルータ型のものや、マルチホームのホスト上でカーネルによるパケット転送を禁止しデーモンにより認証とパケット転送を行なうプロキシサーバ型のものや、この両者を組み合わせたものなどを用いることができる。

＜第３の通信方式＞
図９は、図８に示したネットワークシステム１における第３の通信方式の基本手順を説明するシーケンス図である。また、図１０〜図１２は、第３の通信方式の基本手順で用いられる各種のメッセージの一例を示す図である。また、図１３は、第３の通信方式の改良手順を説明するシーケンス図である。

この第３の通信方式は、送信側のデータ通信装置２０（送信端末２２；プライベートＩＰ＝“1.2.3.100 ”）においては、送信するデータを一時データ保存部２６０に格納するとともに、データ転送プロトコル処理部２３０から外部に公開するＨＴＴＰやＦＴＰのＵＲＬを取得する点で第２の通信方式と共通するが、ＵＰｎＰを利用してＮＡＴ装置やＦＷ装置などの遮断装置７０においてこのＵＲＬに対応する外部アドレスポートを作成・取得し、これをＩＮＶＩＴＥリクエストメッセージ中に記述し、受信側のデータ通信装置２０（受信端末２４）からそのＵＲＬに対しＨＴＴＰやＦＴＰなどでデータの取得を実行する点に特徴を有する。

具体的には、先ず図９に示す基本手順においては、第２の通信方式と同様に、送信端末２２（Ｔ１）は、送信するデータを一時データ保存部２６０（Ｔ１−ｗｏｒｋ）に格納し（図中のPut [Data] ）、ＨＴＴＰなどのデータ転送用の標準プロトコルを利用して接続可能な状態にする。また、送信端末２２は、第３の通信方式の特徴部分として、ＵＰｎＰを利用してＮＡＴ装置やＦＷ装置などの遮断装置７０からＨＴＴＰのＵＲＬに対応する外部アドレスポートを取得する。

この際には、送信端末２２は、一時データ保存部２６０に送信するデータを格納しておき、データ転送プロトコル処理部２３０（ＨＴＴＰプロトコル処理部２３２やＦＴＰプロトコル処理部２３４）から外部に公開するＵＲＬ（Uniform Resource Locators ）を取得すると、先ずＵＰｎＰを利用してＮＡＴ装置やＦＷ装置などの遮断装置７０に対して、図１０（Ａ）に示すような、アドレス変換を要求する外部ＩＰアドレス要求メッセージ（Get External IP Address (Ａ)）を発する。外部ＩＰアドレス要求メッセージを受信した遮断装置７０は、ＵＲＬの対応する外部公開用のＩＰアドレスを生成し、図１０（Ｂ）に示すように、その外部ＩＰアドレスを含む応答メッセージ（Get External IP Address Response(Ｂ)）を送信端末２２に返す。この例では、新しい外部ＩＰアドレス（グローバルアドレス）として“10.20.30.40”を設定している（図中の＊印行を参照）。

この応答メッセージを受信した送信端末２２は、外部公開用のポートと、公開用のプロトコルと、公開用の内部ポートと、その内部ポートを開放するクライアント（送信端末２２自身）とを対応付け、そのポートマッピング情報を含む図１１（Ａ）に示すようなポートマッピングメッセージ（Add Port Mapping(Ｃ)）を遮断装置７０に発する。このポートマッピングメッセージを受信した遮断装置７０は、図１１（Ｂ）に示すような応答メッセージ（Add Port Mapping Response(Ｄ) ）を送信端末２２に返す。この例では、外部公開用のポートを“10080 ”、公開用の内部ポートを“80”、公開用のプロトコルを“TCP ”に設定している（図中の＊印行を参照）。遮断装置７０は、自身が備えるポートマッピング用のデータ保持部にこのポートマッピングの情報を記憶しておき、送信端末２２と受信端末２４との間でのこのポートマッピングに従った通信を許可するようにする。

応答メッセージを受信した送信端末２２は、ＮＡＴ装置やＦＷ装置などの遮断装置７０を利用して取得した情報を反映させて、図１２（Ａ）に示すように、外部ＩＰアドレスやパスとともに外部に公開するＵＲＬ（図では“http://10.20.30.40:10080/someimage.jpeg ”などの必要な情報をＩＮＶＩＴＥリクエストメッセージ（Ｅ）中のContent-Typeヘッダに記述して（図中の＊１，＊２，＊３印行を参照）、ＳＩＰサーバ装置４０（SIP Server）に送信する。

ＩＮＶＩＴＥリクエストメッセージを受信したＳＩＰサーバ装置４０は、ＩＮＶＩＴＥリクエストメッセージ中のＩＮＶＩＴＥ ｓｉｐヘッダに付加されているデータ転送先の受信端末２４（Ｔ２）に、そのＩＮＶＩＴＥリクエストメッセージの必要部分を転送する。このＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信応答を示す応答メッセージ“200 OK”を、ＳＩＰサーバ装置４０を介して送信端末２２に返す。この応答メッセージ“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す。

応答メッセージ“ACK ”を受信した受信端末２４は、ＩＮＶＩＴＥリクエスト中のContent-Typeヘッダに記述されたデータ転送プロトコルの種類やアドレス情報に基づいて、図１２（Ｂ）に示すようなゲットメッセージ（Ｆ）を送信端末２２に発してデータの取得を試みる。ここでは、“http://10.20.30.40:10080/someimage.jpeg ”を送信端末２２に発する。図８に示すネットワークシステム１では、受信端末２４からの送信端末２２への要求メッセージが遮断装置７０を通ることになるので、通常であればその要求メッセージは遮断されるのであるが、予め、外部アクセスを許可するためのポートマッピングが設定されているので、送信端末２２と受信端末２４との間でのそのポートマッピングに従った通信が許可されることになる。このゲットメッセージ（Ｆ）を受信した送信端末２２は、図１２（Ｃ）に示すような、データ付きの応答メッセージ（Ｇ）“200 OK”を受信端末２４に送信する。

つまり、第３の通信方式では、送信側のデータ通信装置２０（送信端末２２）における処理は第２の通信方式と異なるが、受信側のデータ通信装置２０（受信端末２４）では、アクセスするＵＲＬが異なるだけで、第２の通信方式と同じ手順でデータを取得することができる。

このように、第３の通信方式では、送信側の通信装置に対しての外部からのアクセスを遮断するＮＡＴやファイアウォールなどの遮断手段が設けられているシステムの場合に、送信端末２２のＳＩＰプロトコル処理部２５０が、送信するデータに対応した受信端末２４に公開可能なアドレスをＮＡＴなどの遮断装置７０から取得し、この取得したアドレスを受信端末２４に通知するようにしたので、受信端末２４側では、通知されたアドレスにアクセスすることで、ファイアウォール越しであっても適切にデータを受信することができる。

＜第３の通信方式の改良手順＞
ここで、第３の通信方式の基本手順では、データ送信の初期段階で、第２の通信方式と同様に送信データを一時データ保存部２６０に格納するし、さらにＵＰｎＰなどによりアドレス変換処理やポートマッピング作成処理などを行なうが、その後、一時保存した送信データ（一時データの一例）を削除可能であるかどうかを送信端末２２自身で適切かつ効率的に判断することができないし、ポートマッピング情報（一時データの他の一例）を削除可能であるかどうかを遮断装置７０自身で適切かつ効率的に判断することができないという問題がある。

一時データ保存部２６０や遮断装置７０が備えるポートマッピング用のデータ保持部の容量は有限であるから、無限に保存すると、容量オーバーになった段階で第３の通信方式を実現できなくなる。あるいは、容量オーバーになった段階で古いものから順次削除することも考えられるが、この場合、本当に削除してよいものであったのかどうかの確認ができない。

そこで、本実施形態では、この第３の通信方式が持つ問題を解消するべく、以下のような仕組みを採る。すなわち、この問題を解決するためには、第２の通信方式の改良手順と同様に、一旦、受信端末２４から送信端末２２に暫定レスポンスを送信することで対処することができ、本例の場合にも、最終レスポンスの送信を延期できる唯一のリクエストである、ＩＮＶＩＴＥリクエストを暫定レスポンスに利用するのが好適であり、これにより、前述の問題を解決することができる。

つまり、ＮＡＴ装置やＦＷ装置などの遮断装置７０においてＵＲＬに対応する外部アドレスポートを作成・取得するとともに、ＨＴＴＰなどのデータ転送プロトコルを利用して送信端末２２と受信端末２４との間で実際のデータ転送を行なう第３の通信方式では、図１３に示す改良手順のように、第２の通信方式と同様に、ＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信完了応答を示す応答メッセージ“200 OK”を即時に返さずに、一旦、たとえば“183 Session Progress”などの暫定レスポンスをＳＩＰサーバ装置４０を介して送信端末２２に送信することで、最終応答の送信を延期する。

また、応答メッセージ（最終レスポンス）“200 OK”を受信した送信端末２２は、ＵＰｎＰを利用してＮＡＴ装置やＦＷ装置などの遮断装置７０に対して、ポートマッピングの削除指示（Delete Port Mapping ）を発する。この削除指示を受信した遮断装置７０は、保存しておいたポートマッピング情報を削除するとともに、その応答メッセージ（Delete Port Mapping Response）を送信端末２２に返す。この応答メッセージを受信した送信端末２２は、ポートマッピングが削除された後に、一時保存した送信データを一時データ保存部２６０から安全かつ確実に削除することができる。なお、ここでは、ポートマッピングの削除指示とその応答確認の後に一時保存した送信データを削除するようにしているが、先に一時保存した送信データを削除してからポートマッピングの削除指示を発するようにしてもよい。

なお、図１３に点線で示すように、受信端末２４がデータ転送プロトコルによるデータの取得に失敗した場合には、“404 Not Found ”などの失敗応答をＳＩＰサーバ装置４０を介して送信端末２２に送信する。この失敗応答を受信した送信端末２２は、この第３の通信方式によるデータ転送に失敗したことを判断することができる。この場合、送信端末２２は、遮断装置７０に対するポートマッピング情報の削除指示や一時データ保存部２６０からの一時保存した送信データの削除を行なわず、同じ第３の通信方式もしくはさらに高度な通信方式での通信を試みる。

＜第４方式を実現するシステム構成＞
図１４は、第４の通信方式（以下第４方式ともいう）を実現するネットワークシステム構成の一例を示す図である。この第４方式のネットワークシステム１は、送信端末２２がＮＡＴ装置やＦＷ装置の配下に存在し、第２の通信方式と同一の方法では受信端末２４からデータ転送プロトコルでの接続を行なうことができない、つまり送信側のデータ通信装置２０（送信端末２２）が外部から接続不可能な場合であって、さらにＮＡＴ装置やＦＷ装置を制御するための手段も提供されていないが、ＮＡＴ装置やＦＷ装置の外部（つまりインターネットなどの通信網９０側）に存在する一時データ保存装置を利用できる場合に用いて好適な通信方式である。

通信処理制御の面においては、第３方式よりはさらに手順が増え複雑な処理制御が必要となり、さらに高度の通信方式にはなるが、ＮＡＴ装置やファイアウォールが存在しかつ自装置にはその制御手段が存在しないことで第３の通信方式（通信処理制御の面で第４方式よりも低度の通信方式）では対処できない環境下においても、この第４方式を適用することで対処可能となる。

具体的には、図示するように、この第４方式用のネットワークシステム１は、第３方式用のネットワークシステム１に対して、送信端末２２のデータ転送プロトコル処理部２３０が送信するデータを一時保管するデータ保存手段としての一時データ保存装置８０（グローバルＩＰ＝“10.20.30.100）”が遮断装置７０に接続されている。なお、図中点線で示すように、一時データ保存装置８０は、通信網９０に直接に接続されていてもよい。

一時データ保存装置８０は、遮断装置７０の送信端末２２に対して外側（つまり通信網９０側）の外部機器（本例では特に受信端末２４）から自由に接続可能なデータ転送装置の一例であるとともに、送信端末２２が備える一時データ保存部２６０と同様に、送信端末２２のデータ転送プロトコル処理部２３０のＨＴＴＰプロトコル処理部２３２およびＦＴＰプロトコル処理部２３４とネットワーク接続され、送受信されるデータの処理領域として利用される装置である。

＜一時データ保存装置の構成例＞
図１５は、第４方式用のネットワークシステム１にて用いられる一時データ保存装置８０の一構成例を示すブロック図である。図示するように、一時データ保存装置８０は、ＨＴＴＰプロトコルに従ってデータ転送のための通信処理を行なうＨＴＴＰプロトコル処理部８３２およびＦＴＰプロトコルに従ってデータ転送のための通信処理を行なうＦＴＰプロトコル処理部８３４などの各種のプロトコル処理部を有するデータ転送プロトコル処理部８３０と、データを一時保管する一時データ保存部８６０とを備えている。なお、図示を割愛するが、一時データ保存装置８０の各部を制御するコントローラ部も必要に応じて設けられてもよいし、コントローラ部を設けない場合には、外部のデータ通信装置２０が直接にリモートで一時データ保存装置８０の各部を制御するようにしてもよい。

データ転送プロトコル処理部８３０やその内部の各種のプロトコル処理部は、データ転送プロトコル処理部２３０などと同様の機能を備えたものである。一時データ保存部８６０は、一時データ保存部２６０と同様の機能を備えたものであり、データ転送プロトコル処理部２３０のＨＴＴＰプロトコル処理部２３２およびＦＴＰプロトコル処理部２３４と内部接続され、送受信されるデータの処理領域として利用される。

＜第４の通信方式＞
図１６は、図１４に示したネットワークシステム１における第４の通信方式の基本手順を説明するシーケンス図である。また、図１７は、第４の通信方式の基本手順で用いられる各種のメッセージの一例を示す図である。また、図１８は、第４の通信方式の改良手順を説明するシーケンス図である。

第１の通信方式では、一時データ保存部２６０が送信端末２２内に内蔵されているのに対して、この第４の通信方式では、一時データ保存装置８０が送信端末２２外においてＮＡＴ装置やＦＷ装置の外部から接続可能な状態で配置されているが、基本的な手順は第２の通信方式と同様である。

なお、送信端末２２と一時データ保存装置８０との間には、ＮＡＴ装置やＦＷ装置などの遮断装置７０が介在しているので、送信端末２２は、送信するデータを一時データ保存装置８０に格納するとともに、第３の通信方式と同様に、ＵＰｎＰを利用してＮＡＴ装置やＦＷ装置などの遮断装置７０から外部アドレスポート（グローバルＩＰアドレス）を取得し、これをＩＮＶＩＴＥリクエストメッセージ中に公開用のＵＲＬとともに記述し、受信側のデータ通信装置２０から一時データ保存装置８０にアクセスして、公開用のＵＲＬに対しＨＴＴＰやＦＴＰなどでデータの取得を実行する。

具体的には、先ず図１６に示す基本手順においては、送信端末２２（Ｔ１）は、ＨＴＴＰなどのデータ転送用の標準プロトコルを利用して接続可能な状態にする。また、送信端末２２は、インターネット内のグローバルアドレスを有する通信端末（本例では受信端末２４や一時データ保存装置８０）との間で通信を行なうためにプライベートＩＰアドレスに対応するグローバルＩＰアドレスを遮断装置７０から取得しておく。この例では、新しい外部ＩＰアドレス（グローバルアドレス）として“10.20.30.40”が設定されている。

送信端末２２は、ＦＴＰなどのデータ転送プロトコルを用いて送信するデータを一時データ保存装置８０（Temporary Storage ）に送信・格納するとともに（図中のPut [Data] ）、データ転送プロトコル処理部２３０（ＨＴＴＰプロトコル処理部２３２やＦＴＰプロトコル処理部２３４）から外部に公開するＵＲＬを取得し、図１７（Ａ）に示すように、ＮＡＴ装置やＦＷ装置などの遮断装置７０を利用して取得したグローバルアドレス情報を反映させた外部ＩＰアドレスやパスやＵＲＬなどの必要な情報をＩＮＶＩＴＥリクエストメッセージ（Ａ）中のContent-Typeヘッダに記述して（図中の＊１，＊２，＊３印行を参照）、ＳＩＰサーバ装置４０（SIP Server）に送信する。この例では、ＵＲＬを“http://10.20.30.100/tmp/T1/someimage.jpeg ”としている。

ＩＮＶＩＴＥリクエストメッセージを受信したＳＩＰサーバ装置４０は、ＩＮＶＩＴＥリクエストメッセージ中のＩＮＶＩＴＥ ｓｉｐヘッダに付加されているデータ転送先の受信端末２４（Ｔ２）に、そのＩＮＶＩＴＥリクエストメッセージの必要部分を転送する。このＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信応答を示す応答メッセージ“200 OK”を、ＳＩＰサーバ装置４０を介して送信端末２２に返す。この応答メッセージ“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す。

応答メッセージ“ACK ”を受信した受信端末２４は、ＩＮＶＩＴＥリクエスト中のContent-Typeヘッダに記述されたデータ転送プロトコルの種類やアドレス情報に基づいて、図１７（Ｂ）に示すようなゲットメッセージ（Ｂ）を一時データ保存装置８０に発してデータの取得を試みる。ここでは、“http://10.20.30.100/tmp/T1/someimage.jpeg HTTP/1.0”を一時データ保存装置８０に発する。このゲットメッセージ（Ｂ）を受信した一時データ保存装置８０は、図１７（Ｃ）に示すような、データ付きの応答メッセージ（Ｃ）“200 OK”を受信端末２４に送信する。

つまり、第４の通信方式では、送信側のデータ通信装置２０（送信端末２２）における処理は第２や第３の通信方式と異なるが、受信側のデータ通信装置２０（受信端末２４）では、アクセスするＵＲＬおよびアクセス先が異なるだけで、第２の通信方式と同じ手順でデータを取得することができる。

また、送信端末２２が、送信するデータに対応した受信端末２４に公開可能なアドレスをＮＡＴなどの遮断手段から取得する機能を備えていない場合であっても、送信端末２２に対して遮断装置７０の外側に配されている一時データ保存装置８０を利用することができる場合には、送信端末２２のＳＩＰプロトコル処理部２５０が、送信するデータに対応した受信端末２４に公開可能なアドレスを受信端末２４に通知するようにしたので、受信端末２４側では、通知されたアドレスにアクセスすることで、送信端末２２に対して遮断装置７０の外側に配された一時データ保存装置８０から適切にデータを受信することができる。

＜第４の通信方式の改良手順＞
ここで、第４の通信方式の基本手順では、第２の通信方式と略同様に、データ送信の初期段階で送信データを一時データ保存装置８０に格納するが、その後、この一時保存した送信データを削除可能であるかどうかを送信端末２２自身や一時データ保存装置８０自身で適切かつ効率的に判断することができないという問題がある。一時データ保存装置８０の容量は有限であるから、無限に保存すると、容量オーバーになった段階で第４の通信方式を実現できなくなる。あるいは、容量オーバーになった段階で古いものから順次削除することも考えられるが、この場合、本当に削除してよいものであったのかどうかの確認ができない。

そこで、本実施形態では、この第４の通信方式が持つ問題を解消するべく、以下のような仕組みを採る。すなわち、この問題を解決するためには、第２の通信方式の改良手順と同様に、一旦、受信端末２４から送信端末２２に暫定レスポンスを送信することで対処することができ、本例の場合にも、最終レスポンスの送信を延期できる唯一のリクエストである、ＩＮＶＩＴＥリクエストを暫定レスポンスに利用するのが好適であり、これにより、前述の問題を解決することができる。

つまり、送信端末２２側にＮＡＴ装置やＦＷ装置などの遮断装置７０が存在するが、その外部に外部のデータ通信装置２０（本例では受信端末２４）からアクセス可能な一時データ保存装置８０が存在する場合に、ＨＴＴＰなどのデータ転送プロトコルを利用して送信端末２２と受信端末２４との間で実際のデータ転送を一時データ保存装置８０を介在させて間接的に行なう第４の通信方式では、図１８に示す改良手順のように、第２の通信方式と同様に、ＩＮＶＩＴＥリクエストメッセージが転送された受信端末２４は、受信完了応答を示す応答メッセージ“200 OK”を即時に返さずに、一旦、たとえば“183 Session Progress”などの暫定レスポンスをＳＩＰサーバ装置４０を介して送信端末２２に送信することで、最終応答の送信を延期する。

また、応答メッセージ（最終レスポンス）“200 OK”を受信した送信端末２２は、一時保存させた送信データの削除指示（Delete Port Mapping ）を発する。この削除指示を受信した一時データ保存装置８０は、保存しておいた送信データを削除する。これにより、送信端末２２は、一時データ保存装置８０から安全かつ確実に送信データを削除することができる。

なお、図１８に点線で示すように、受信端末２４がデータ転送プロトコルによるデータの取得に失敗した場合には、“404 Not Found ”などの失敗応答をＳＩＰサーバ装置４０を介して送信端末２２に送信する。この失敗応答を受信した送信端末２２は、この第４の通信方式によるデータ転送に失敗したことを判断することができる。この場合、送信端末２２は、一時データ保存装置８０に対する送信データの削除指示を行なわず、同じ第４の通信方式もしくはさらに高度な通信方式での通信を試みる。

＜送信側のデータ転送方式選択アルゴリズム＞
図１９は、上述した第１〜第４の通信方式（第２〜第４の通信方式においては改良手順のもの）を利用して、ＳＩＰサービス基盤上で端末間での任意のデータ転送を実現するための送信側の処理手順を説明するフローチャートである。ここで、図１９は、送信側のデータ通信装置２０（送信端末２２）のコントローラ部２２０における処理アルゴリズム、特にデータ転送方式選択アルゴリズムを示す。

送信端末２２において、コントローラ部２２０は、第１〜第４の複数の通信方式の中から、受信端末２４との間のネットワーク環境や転送データの容量などを考慮して、その時点の状況に最適な通信方式を決定・選択してから実際のデータ転送を開始する。

具体的には、図１９に示すように、送信端末２２のコントローラ部２２０は先ず、アプリケーション部２１０からデータ転送要求を受け取ると（Ｓ１０）、送信データサイズがＳＩＰの仕様に基づき算出される最大値ＭＡＸＳＩＺＥ以下であるか否かを検査する（１２；判定１）。

送信データサイズがＳＩＰの仕様に基づき算出される最大値ＭＡＸＳＩＺＥ以下である場合には、コントローラ部２２０は、第１の通信方式に従った送信処理を試行するとともに（Ｓ１２−Ｙｅｓ，Ｓ１４）、第１の通信方式に従った送信処理が問題ないか否かを判断する（Ｓ１５）。コントローラ部２２０は、第１の通信方式に従った送信処理を試行して成功したときには、データ転送が完了すると、その旨をアプリケーション部２１０に通知する（Ｓ１５−成功，Ｓ２９）。この場合、事実上、ステップＳ１４での第１の通信方式に従った送信処理の試行が、実際のデータ転送処理となる。

一方、データサイズがＭＡＸＳＩＺＥより大きい場合（Ｓ１２−Ｎｏ）、または“200 OK；成功レスポンス”を受信端末２４から所定時間内に受信できないなど第１の通信方式に従った送信に失敗した場合には（Ｓ１５−失敗）、コントローラ部２２０は、さらに高度な通信方式である第２の通信方式が適用可能であるかを判断する。具体的には、先ず、コントローラ部２２０は、アプリケーションに設定された情報や他の方法を用いることで、ＨＴＴＰやＦＴＰなどのファイル転送プロトコルによる外部からの接続が可能であるネットワーク構成（図８）であるか否かを判断する（Ｓ１６；判定２）。

コントローラ部２２０は、このようなネットワーク構成（図８）であることが明確な場合、もしくはこのようなネットワーク構成（図８）でないことの判断が不可能である場合には（Ｓ１６−Ｙｅｓ or Ｕｎｋｎｏｗｎ）、第２の通信方式（改良手順）に従った送信処理を試行するとともに（Ｓ１８）、第２の通信方式（改良手順）に従った送信処理が問題ないか否かを判断する（Ｓ１９）。コントローラ部２２０は、第２の通信方式（改良手順）に従った送信処理を試行して成功したときには、データ転送が完了すると、その旨をアプリケーション部２１０に通知する（Ｓ１９−成功，Ｓ２９）。この場合、事実上、ステップＳ１８での第２の通信方式に従った送信処理の試行が、実際のデータ転送処理となる。

一方、ネットワーク構成（図８）でないことの判断が可能である場合には（Ｓ１６−Ｎｏ）、または“404 Not Found ；失敗レスポンス”を受信端末２４から受信するなど第２の通信方式（改良手順）に従った送信に失敗した場合には（Ｓ１９−失敗）、コントローラ部２２０は、さらに高度な通信方式である第３の通信方式が適用可能であるかを判断する。具体的には、コントローラ部２２０は、先ず、アプリケーションに設定された情報や他の方法を用いることで、ファイル転送プロトコルによる外部からの接続が不可能となっている要因（図８でのＮＡＴ装置やＦＷ装置などの遮断装置７０）がＵＰｎＰなどを用いて制御可能であるネットワーク構成（図８）であるか否かを判断する（Ｓ２０；判定３）。

コントローラ部２２０は、ＮＡＴ装置やＦＷ装置をＵＰｎＰなどを用いて制御可能であることが明確な場合、もしくは制御不可能であることの判断が不可能である場合には（Ｓ２０−Ｙｅｓ or Ｕｎｋｎｏｗｎ）、第３の通信方式（改良手順）に従った送信処理を試行するとともに（Ｓ２２）、第３の通信方式（改良手順）に従った送信処理が問題ないか否かを判断する（Ｓ２３）。コントローラ部２２０は、第３の通信方式（改良手順）に従った送信処理を試行して成功したときには、データ転送が完了すると、その旨をアプリケーション部２１０に通知する（Ｓ２３−成功，Ｓ２９）。この場合、事実上、ステップＳ２２での第３の通信方式に従った送信処理の試行が、実際のデータ転送処理となる。

一方、ＮＡＴ装置やＦＷ装置をＵＰｎＰなどを用いて制御不可能であることの判断が可能である場合には（Ｓ２０−Ｎｏ）、または“404 Not Found ；失敗レスポンス”を受信端末２４から受信するなど第３の通信方式（改良手順）に従った送信に失敗した場合には（Ｓ２３−失敗）、コントローラ部２２０は、さらに高度な通信方式である第４の通信方式が適用可能であるかを判断する。具体的には、コントローラ部２２０は、先ず、アプリケーションに設定された情報や他の方法を用いることで、データ転送プロトコルにより外部から接続可能な一時データ保存装置８０が存在するネットワーク構成（図１４）であるか否かを判断する（Ｓ２４；判定４）。

コントローラ部２２０は、このようなネットワーク構成（図１４）であることが明確な場合、もしくはこのようなネットワーク構成（図１４）でないことの判断が不可能である場合には（Ｓ２４−Ｙｅｓ or Ｕｎｋｎｏｗｎ）、第４の通信方式（改良手順）に従った送信処理を試行するとともに（Ｓ２６）、第４の通信方式（改良手順）に従った送信処理が問題ないか否かを判断する（Ｓ２７）。コントローラ部２２０は、第４の通信方式（改良手順）に従った送信処理を試行して成功したときには、データ転送が完了すると、その旨をアプリケーション部２１０に通知する（Ｓ２７−成功，Ｓ２９）。この場合、事実上、ステップＳ２６での第４の通信方式に従った送信処理の試行が、実際のデータ転送処理となる。

一方、ネットワーク構成（図１４）でないことの判断が可能である場合には（Ｓ２４−Ｎｏ）、または“404 Not Found ；失敗レスポンス”を受信端末２４から受信するなど第４の通信方式（改良手順）に従った送信に失敗した場合には（Ｓ２７−失敗）、コントローラ部２２０は、データ送信は失敗したものとして、その旨をアプリケーション部２１０に通知する（Ｓ２８）。

なお、この例では、複数の通信方式を、第１から第４へと、低レベルのものから高レベルのものに、段階的に試行するようにしていたが、このことは必須ではない。ただし、最初に低レベルの通信方式で試行し、失敗したらより高度の通信方式で試行するようにすることで、システム全体（端末の処理負荷だけでなくネットワーク負荷や通信コストなども含む）として、無駄のない効率的な通信処理が実現できる。

＜受信側の応答処理アルゴリズム＞
図２０は、上述した第１〜第４の通信方式（第２〜第４の通信方式においては改良手順のもの）を利用して、ＳＩＰサービス基盤上で端末間での任意のデータ転送を実現するための受信側の処理手順を説明するフローチャートである。ここで、図２０は、受信側のデータ通信装置２０（送信端末２４）のコントローラ部２２０における、受信したデータ転送用ＩＮＶＩＴＥリクエストに対する処理アルゴリズムを示す。

受信端末２４においては、コントローラ部２２０は、受信したデータのＩＮＶＩＴＥリクエストメッセージ中のContent-Typeヘッダを検査し、その検査結果に基づいて、所定の受信処理を行なう。

具体的には、図２０に示すように、受信端末２４のコントローラ部２２０は、先ず待ち状態にある（Ｓ５０−Ｎｏ）。待機状態中に、ＳＩＰプロトコル処理部２５０がリクエストＵＲＩにパラメータ“user＝data”が付加されているデータ転送用のＩＮＶＩＴＥリクエストを受信すると（Ｓ５０−Ｙｅｓ）、コントローラ部２２０は、リクエストメッセージ中のContent-Typeヘッダを検査する（Ｓ５４）。たとえば、“image/jpeg”と表記されＪＰＥＧデータが付加されている場合のように、リクエストメッセージのContent-Typeヘッダのボディ部に転送データが直接付加されている表記がされている場合には、コントローラ部２２０は、送信端末２２に対して“200 OK；成功レスポンス”を直ちに送信する（Ｓ５４−Ａ，Ｓ６０）。そして、ボディ部に付加されていた受信データを一時データ保存部２６０に格納し、アプリケーションに対してデータを受信した旨を通知し（Ｓ６２）、待ち状態（Ｓ５０）に戻る。なお、一時データ保存部２６０に一時的に保存しておいた受信データ（一時データの一例）は、アプリケーション部２１０により一時データ保存部２６０からデータ取得された段階で削除する。

一方、Content-Typeヘッダに、データ転送プロトコルでの接続先（ＵＲＬなど）が記述されているなど他のデータ転送プロトコルを利用してデータの取得を行なう旨や接続先に関する情報が記述されている場合には（Ｓ５４−Ｂ）、コントローラ部２２０は、送信端末２２に対して“183 Session Progress；暫定レスポンス”を送信した後（Ｓ５６）、記述に基づくデータ転送プロトコル（ＨＴＴＰやＦＴＰなど）を用いてデータ取得を試行する（Ｓ５８）。たとえば、Content-Typeヘッダの値が、“message/external-body; ACCESS-TYPE=URL; URL="http://10.20.30.40:10080/someimage.jpeg”であった場合は、ＨＴＴＰプロトコルを利用して、“http://10.20.30.40:10080/someimage.jpeg ”というＵＲＬに対しデータの取得を試行する。

データ取得に成功した場合には、コントローラ部２２０は、送信端末２２に対して“200 OK；成功レスポンス”を送信する（Ｓ５８−成功，Ｓ６０）。そして、ボディ部に付加されていた受信データを一時データ保存部２６０に格納し、アプリケーションに対してデータを受信した旨を通知し（Ｓ６２）、待ち状態（Ｓ５０）に戻る。なお、一時データ保存部２６０に一時的に保存しておいた受信データ（一時データの一例）は、アプリケーション部２１０により一時データ保存部２６０からデータ取得された段階で削除する。

一方、データ取得に失敗した場合には、コントローラ部２２０は、送信端末２２に対して“404 Not Found ；失敗レスポンス”を送信端末２２に送信した後に、待ち状態（Ｓ５０）に戻る（Ｓ５８−失敗，Ｓ６４）。

なお、受信端末２４は、データ受信に成功したときには、アプリケーション部２１０において、受信したデータに基づく所定のデータ処理を行なう。たとえば、ＩＰ電話のアプリケーションであれば、音声データに基づく音声情報をヘッドセット（音声情報入出力手段の一例）にてユーザに提供する。また、テレビ電話やテレビ会議のアプリケーションであれば、音声データに基づく音声情報をスピーカなどの音声情報出力手段にてユーザに提供するとともに、画像データに基づく画像をＬＣＤ（Liquid Crystal Display；液晶表示装置）やＣＲＴ（Cathode Ray Tube；陰極線管）などのモニタ装置（画像情報出力手段の一例）にてユーザに提供する。また、画像通信のアプリケーションであれば、たとえばＪＰＥＧデータを受信すると、復号処理部にて伸張（復号）した後、画像処理部において色材（たとえばトナーやインク）に応じた出力色（典型例はＣＭＫＹの４色）データに変換し、画像形成部において所定の出力媒体（典型例は出力用紙）上に画像を記録出力する。

このように、送信端末２２と受信端末２４とが、ＳＩＰサーバ装置４０を利用しつつ、連携した通信処理を行なうことにより、ＳＩＰプロトコルを拡張することなく、試行されたデータ転送方式の転送結果を送信側のデータ通信装置２０（送信端末２２）に通知を行なうことができる。複数の通信方式を順次試行する（好ましくは低レベルのものから高レベルのものに段階的に試行する）ことで、実環境に応じた適正な通信方式を使用して、端末間で直接にあるいは一時データ保存装置８０を利用して、データ転送ができる。また、受信端末２４がデータ受信を完了した時点で受信端末２４から送信端末２２に完了通知を行なうことで、送信端末２２側では、不要な一時データを安全かつ確実に削除することもできる。

以上説明したように、上記実施形態の通信処理によれば、データ容量や通信環境の影響を受けることなく、ＳＩＰサービス基盤上で呼接続が可能なデータ通信装置２０や、このデータ通信装置２０に組み込まれたソフトウエアアプリケーション同士で、音声や画像などのデータファイルなどの任意のデータを直接に転送することが、確実に実現できるようになる。

また、ＮＡＴやＦＷの内部に存在し、既存のデータ転送プロトコルのみでは直接にデータ転送を行なうことができない端末間の場合でも、第４の通信方式のように、ＮＡＴやＦＷの外部に存在する一時データ保存装置８０を利用するようにすることで、データ転送が可能になる。

また、ＳＩＰプロトコルの中で、通常の呼制御において必ず使用される部分（上記実施形態でのＩＮＶＩＴＥリクエスト）のみを使用して実現されるため、ＭＥＳＳＡＧＥリクエストやＮＯＴＩＦＹリクエストなどを用いる方法と比べると、既に運用されているＳＩＰ基盤上での使用に当たり、接続性の問題が生じ難い。

さらに、受信側のデータ通信装置２０（受信端末２４）がデータ転送試行結果をＳＩＰレスポンスにより送信側のデータ通信装置２０（送信端末２２）に通知することにより、送信端末２２は、複数のデータ転送方式を順次試行することができる。これにより、ネットワーク環境が未知の場合であっても、実環境に応じた適正な通信方式を使用して、データ転送を確実に実現することができるし、受信端末２４から送信端末２２にデータ転送の完了通知を行なうことで、不要な一時データを削除することもできる。

＜電子計算機を利用した構成に関して＞
なお、上記実施形態において、通信処理を行なう仕組みは、ハードウェア処理回路により構成することに限らず、その機能を実現するプログラムコードに基づき電子計算機（コンピュータ）を用いてソフトウェア的に実現することも可能である。

よって、本発明に係る通信処理方法や通信装置を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なプログラムあるいはこのプログラムを格納したコンピュータ読取可能な記憶媒体を発明として抽出することもできる。

電子計算機に一連の通信処理機能をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ（組込マイコンなど）、あるいは、ＣＰＵ（Central Processing Unit ）、論理回路、記憶装置などの機能を１つのチップ上に搭載して所望のシステムを実現するＳＯＣ（System On a Chip：システムオンチップ）、または、各種のプログラムをインストールすることで各種の機能を実行することが可能な汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。

記録媒体は、コンピュータのハードウェア資源に備えられている読取装置に対して、プログラムの記述内容に応じて、磁気、光、電気などのエネルギの変化状態を引き起こして、それに対応する信号の形式で、読取装置にプログラムの記述内容を伝達できるものである。

たとえば、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクＦＤを含む）、光ディスク（ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory ）、ＤＶＤ（Digital Versatile Disc）を含む）、光磁気ディスク（ＭＤ（Mini Disc ）を含む）、または半導体メモリなどよりなるパッケージメディア（可搬型の記憶媒体）により構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているＲＯＭやハードディスクなどで構成されてもよい。

また、ソフトウェアを構成するプログラムは、記録媒体を用いずに、記録媒体を介して提供されることに限らず、有線あるいは無線などの通信網を介して提供されてもよい。

たとえば、通信処理機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、ハードウェア処理回路にて構成する場合と同様の効果は達成される。この場合、記憶媒体から読み出されたプログラムコード自体が通信処理の機能を実現する。

また、コンピュータが読み出したプログラムコードを実行することで、通信処理を行なう機能が実現されるだけでなく、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（Operating Systems ；基本ソフト）などが実際の処理の一部または全部を行ない、その処理により通信処理を行なう機能が実現される場合であってもよい。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって通信処理を行なう機能が実現される場合であってもよい。

なお、通信処理を行なう機能を実現するプログラムコードを記述したファイルとしてプログラムが提供されるが、この場合、一括のプログラムファイルとして提供されることに限らず、コンピュータで構成されるシステムのハードウェア構成に応じて、個別のプログラムモジュールとして提供されてもよい。

たとえば図２１は、ＣＰＵやメモリを利用してソフトウェア的に通信処理を行なう機能を持つデータ通信装置２０を構成する、すなわちパーソナルコンピュータなどのコンピュータ（電子計算機）の機能を利用して通信処理をソフトウェア的に実現する場合のハードウェア構成の一例を示すブロック図である。

もちろん、このようなコンピュータを用いた構成に限らず、図２を用いて示したデータ通信装置２０の各機能部の処理をなす専用のハードウェアの組合せにより通信処理を行なう構成にすることもできる。ただし、ソフトウェアにより処理を実行させる仕組みとすることで、ハードウェアの変更を伴うことなく、処理手順などを容易に変更できる利点を享受できるようになる。

なお、通信処理機能をソフトウェアで実現する機能をデータ通信装置２０に組み込む形態の場合、図２１に示す電子計算機には、たとえば、ＩＰ電話やテレビ電話など従来の通信装置におけるものに準じたネットワークを介して外部とのデータを送受信するための制御プログラムなどのソフトウェアが組み込まれるが、そのソフトウェアには、少なくとも、上述した実施形態の通信処理を行なうプログラムモジュールが存在することとなる。

たとえば、コンピュータシステム９００は、コントローラ部９０１と、ハードディスク装置、フレキシブルディスク（ＦＤ）ドライブ、あるいはＣＤ−ＲＯＭ（Compact Disk ROM）ドライブ、半導体メモリコントローラなどの、所定の記憶媒体からデータを読み出したり記録したりするための記録・読取制御部９０２とを有する。

コントローラ部９０１は、ＣＰＵ（Central Processing Unit ）９１２、読出専用の記憶部であるＲＯＭ（Read Only Memory）９１３、随時書込みおよび読出しが可能であるとともに揮発性の記憶部の一例であるＲＡＭ（Random Access Memory）９１５、および不揮発性の記憶部の一例であるＲＡＭ（ＮＶＲＡＭと記述する）９１６を有している。ＮＶＲＡＭ９１６には、たとえば、一時データなどを格納することができる。この場合、ＮＶＲＡＭ９１６は、一時データ保存部２６０として機能することとなる。

上記において“揮発性の記憶部”とは、データ通信装置２０の電源がオフされた場合には、記憶内容を消滅してしまう形態の記憶部を意味する。一方、“不揮発性の記憶部”とは、データ通信装置２０のメイン電源がオフされた場合でも、記憶内容を保持し続ける形態の記憶部を意味する。記憶内容を保持し続けることができるものであればよく、半導体製のメモリ素子自体が不揮発性を有するものに限らず、バックアップ電源を備えることで、揮発性のメモリ素子を“不揮発性”を呈するように構成するものであってもよい。また、半導体製のメモリ素子により構成することに限らず、磁気ディスクや光ディスクなどの媒体を利用して構成してもよい。たとえば、ハードディスク装置を不揮発性の記憶部として利用できる。

また、コンピュータシステム９００は、ユーザインタフェースをなす機能部として、キーボードやマウスなどを有する指示入力部９０３と、操作時のガイダンス画面や処理結果などの所定の情報をユーザに提示する表示出力部９０４と、各機能部との間のインタフェース機能をなすインタフェース部（ＩＦ部）９０９とを有する。

表示出力部９０４は、表示制御部９４２と表示装置とを備える。表示装置としては、たとえば、データ通信装置２０に備えられる操作パネル部９４１を利用することができる。あるいは、ＣＲＴやＬＣＤなどでなるその他のディスプレイ部９４４を利用することもできる。

たとえば、表示制御部９４２が、表示パネル部９４１ａやテンキーやその他の操作キー９４１ｂなどからなる操作パネル部９４１やディスプレイ部９４４上に、ガイダンス情報や画像などを表示させる。また、各種の情報をユーザに通知する際の表示デバイスとしても利用される。なお、表示面上にタッチパネル９３２を有するディスプレイ部９４４とすることで、指先やペンなどで所定の情報を入力する指示入力部９０３を構成することもできる。

なお、コンピュータシステム９００には、通信処理に供されるデータに対する所定のデータ処理を行なう機能部分も設けられる。たとえば、画像通信のアプリケーションであれば、たとえば送信用の画像データを取得する機能部分として処理対象の画像を読み取る画像読取部（スキャナユニット）９０５と、処理済みの画像を所定の出力媒体（たとえば印刷用紙）に出力する画像形成部９０６とが設けられる。

画像読取部９０５は、画像入力端末の機能を備えており、たとえばＣＣＤ固体撮像素子の全幅アレイを使用して、読取位置へ送られた原稿に光を照射することで、原稿上の画像を読み取り、この読み取った画像を表す赤Ｒ、緑Ｇ、青Ｂのアナログビデオ信号をデジタル信号へ変換する。

画像形成部９０６は、たとえば画像読取部９０５にて得られた画像信号により表される画像や受信した画像データに基づき、電子写真式、感熱式、熱転写式、インクジェット式、あるいは同様な従来の画像形成処理を利用して、普通紙や感熱紙上に可視画像を形成する（印刷する）。

このため、画像形成部９０６は、たとえばイエローＹ，マゼンタＭ，シアンＣ，ブラックＫの２値化信号などの印刷出力用データを生成する画像処理部９６２と、たとえばラスタ出力スキャンベースやインクジェット方式などのプリントエンジン９６４とを備える。

また、テレビ電話やテレビ会議のアプリケーションであれば、音声データを取得するマイク９５２や画像情報を取得するカメラ９５４などの音声・画像情報入力手段と、音声情報を出力するスピーカ９５６などの音声情報出力手段や画像を出力するＬＣＤやＣＲＴなどの画像情報出力手段が設けられる。なお、画像情報出力手段は、表示出力部９０４を利用することができる。

また、ＩＰ電話のアプリケーションであれば、送信用の音声データを取得したり受信した音声データに基づく音声情報を出力する音声情報入出力手段の一例として、ヘッドセット９５８が設けられる。

インタフェース部９０９としては、処理データ（画像データを含む）や制御データの転送経路であるシステムバス９９１の他、たとえば、画像読取部９０５とのインタフェース機能をなすスキャナＩＦ部９９５、画像形成部９０６や他のプリンタとのインタフェース機能をなすプリンタＩＦ部９９６、およびインターネットなどのネットワークとの間の通信データの受け渡しを仲介する通信ＩＦ部９９９を有している。

なお、通信処理のための各機能部分の全ての処理をソフトウェアで行なうのではなく、これら機能部分の一部を専用のハードウェアにて行なう処理回路９０８を設けてもよい。ソフトウェアで行なう仕組みは、並列処理や連続処理に柔軟に対処し得るものの、その処理が複雑になるに連れ、処理時間が長くなるため、処理速度の低下が問題となる。これに対して、ハードウェア処理回路で行なうことで、高速化を図ったアクセラレータシステムを構築することができるようになる。アクセラレータシステムは、処理が複雑であっても、処理速度の低下を防ぐことができ、高いスループットを得ることができる。

たとえば、通信処理機能をデータ通信装置２０に適用した本実施形態の場合であれば、処理回路９０８としては、画像読取処理をなす読取処理部９８２や圧縮された画像情報を元の画像情報に復号（伸長）する機能をなす復号処理部９８４、あるいは印刷出力用の画像データを生成する画像処理機能をなす画像処理部９８８を個別に設けてもよい。

このような構成において、ＣＰＵ９１２は、システムバス９９１を介してシステム全体の制御を行なうものであり、図２に示したコントローラ部２２０に対応する。ＲＯＭ９１３は、ＣＰＵ９１２の制御プログラムなどを格納する。ＲＡＭ９１５は、ＳＲＡＭ（Static Random Access Memory ）などで構成され、プログラム制御変数や各種処理のためのデータなどを格納する。また、ＲＡＭ９１５は、所定のアプリケーションプログラムによって取得した電子ドキュメント（文字データのみに限らず画像データを含んでよい）や自装置に備えられている画像読取部９０５で取得した画像データ、さらには外部から取得した電子データなどを一時的に格納する領域を含んでいる。

たとえば、通信処理機能をコンピュータに実行させるプログラムは、ＣＤ−ＲＯＭなどの記録媒体を通じて配布される。あるいは、このプログラムは、ＣＤ−ＲＯＭではなくＦＤに格納されてもよい。また、ＭＯドライブを設け、ＭＯに前記プログラムを格納してもよく、またフラッシュメモリなどの不揮発性の半導体メモリカードなど、その他の記録媒体にプログラムを格納してもよい。さらに、他のサーバなどからインターネットなどのネットワークを経由してプログラムをダウンロードして取得したり、あるいは更新したりしてもよい。

なお、プログラムを提供するための記録媒体としては、ＦＤやＣＤ−ＲＯＭなどの他にも、ＤＶＤなどの光学記録媒体、ＭＤなどの磁気記録媒体、ＰＤなどの光磁気記録媒体、テープ媒体、磁気記録媒体、ＩＣカードやミニチュアカードなどの半導体メモリを用いることができる。記録媒体の一例としてのＦＤやＣＤ−ＲＯＭなどには、通信処理機能を実現する際の、一部または全ての機能を格納することができる。

また、ハードディスク装置は、制御プログラムによる各種処理のためのデータを格納したり、画像読取部９０５で取得した画像データや外部から受信した画像データなどを大量に一時的に格納したりする領域を含んでいる。また、ハードディスク装置、ＦＤドライブ、あるいはＣＤ−ＲＯＭドライブは、たとえば、ＣＰＵ９１２にコンテンツ取得やアドレス取得あるいはアドレス設定などの処理をソフトウェアにて実行させるためのプログラムデータを登録するなどのために利用される。

以上、本発明を実施形態を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で上記実施形態に多様な変更または改良を加えることができ、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれる。

また、上記の実施形態は、クレーム（請求項）にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。前述した実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組合せにより種々の発明を抽出できる。実施形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られる限りにおいて、この幾つかの構成要件が削除された構成が発明として抽出され得る。

たとえば、上記実施形態では呼制御処理にＳＩＰを利用したが、ＳＩＰに限らず、その他の呼制御処理を行なうプロトコル（現在規格化されているものに限らず、今後規格化されるであろう規格のものも含む）を使用してもよい。

また、第２，第３の通信方式においては、一時データ保存部２６０に送信するデータを一時的に保存していたが、このことは必須ではない。たとえば、送信する予定のデータに対応したアドレスを受信端末２４に通知し、受信端末２４からそのアドレスにアクセスがあったときに、送信するべき実データを取得してから受信端末２４側にそのデータをＨＴＴＰやＦＴＰにて送信するようにしてもよい。

また、図１９に示した送信側のデータ転送方式の選択アルゴリズムにおいては、第１〜第４の通信方式をこの順に（より低度のものからより高度の順に）試行するようにしていたが、どのような方式を試行するかは自由であるし、その順序も自由である。たとえば、第４の通信方式を実現するには、送信端末２２に対して遮断装置７０の外側に一時データ保存装置８０が配されていることが条件となるので、一時データ保存装置８０を用意するためのシステムコストがアップする。この点では、一時データ保存装置８０を備えないシステム構成を採ることが多いとも考えられる。このような場合には、第４の通信方式での試行を割愛して、第３の通信方式での試行に失敗したら直ちにその旨をアプリケーション部２１０に通知してもよい。

また、第１〜第４の通信方式において、応答メッセージ“200 OK”を受信した送信端末２２は、その確認応答を示す応答メッセージ“ACK ”を、ＳＩＰサーバ装置４０を介して受信端末２４に返す例で説明したが、確認応答を示す応答メッセージ“ACK ”は、ＳＩＰサーバ装置４０を介さずに受信端末２４に返す方法もあり、そのようにしてもよい。

第１の通信方式や第２の通信方式を実現するネットワークシステム構成の一例を示す図である。 データ通信装置の一構成例を示すブロック図である。 図１に示したネットワークシステムにおける第１の通信方式の手順を説明するシーケンス図である。 第１の通信方式で用いられるリクエストメッセージの一例を示す図である。 図１に示したネットワークシステムにおける第２の通信方式の基本手順を説明するシーケンス図である。 第２の通信方式の基本手順で用いられるメッセージの一例を示す図である。 第２の通信方式の改良手順を説明するシーケンス図である。 第３の通信方式を実現するネットワークシステム構成の一例を示す図である。 図８に示したネットワークシステムにおける第３の通信方式の基本手順を説明するシーケンス図である。 第３の通信方式の基本手順で用いられる各種のメッセージの一例を示す図（その１）である。 第３の通信方式の基本手順で用いられる各種のメッセージの一例を示す図（その２）である。 第３の通信方式の基本手順で用いられる各種のメッセージの一例を示す図（その３）である。 第３の通信方式の改良手順を説明するシーケンス図である。 第４の通信方式を実現するネットワークシステム構成の一例を示す図である。 第４方式用のネットワークシステムにて用いられる一時データ保存装置の一構成例を示すブロック図である。 図１４に示したネットワークシステムにおける第４の通信方式の基本手順を説明するシーケンス図である。 第４の通信方式の基本手順で用いられる各種のメッセージの一例を示す図である。 第４の通信方式の改良手順を説明するシーケンス図である。 第１〜第４の通信方式を利用して任意のデータ転送を実現するための送信側の処理手順を説明するフローチャートである。 第１〜第４の通信方式を利用して任意のデータ転送を実現するための受信側の処理手順を説明するフローチャートである。 電子計算機を用いて通信装置を構成する場合のハードウェア構成の一例を示した図である。

符号の説明

１…ネットワークシステム、２０…データ通信装置、２２…送信端末、２４…受信端末、４０…ＳＩＰサーバ装置、７０…遮断装置、８０…一時データ保存装置、９０…通信網、２１０…アプリケーション部、２２０…コントローラ部、２３０…データ転送プロトコル処理部、２３２…ＨＴＴＰプロトコル処理部、２３４…ＦＴＰプロトコル処理部、２５０…ＳＩＰプロトコル処理部、２６０…一時データ保存部、８３０…データ転送プロトコル処理部、８３２…ＨＴＴＰプロトコル処理部、８３４…ＦＴＰプロトコル処理部、８６０…一時データ保存部

Claims (19)

1. 通信装置間においてネットワークを介して所定の方式に従ってデータ通信を行なう通信方法であって、
   複数の通信方式のうちの一方の通信方式に従って前記データ通信を試行し、当該試行に失敗したときには他方の通信方式に従って前記データ通信を試行する
   ことを特徴とする通信方法。
2. 送信側の通信装置と受信側の通信装置とがネットワーク接続されており、これら通信装置間において所定の方式に従ってデータ通信を行なう通信システムであって、
   前記送信側の通信装置は、複数の通信方式のうちの一方の通信方式に従って前記受信側の通信装置との間でデータ通信処理を試行し、当該試行に失敗したときには他方の通信方式に従って前記受信側の通信装置との間でデータ通信処理を試行する
   ことを特徴とする通信システム。
3. 前記送信側の通信装置は、複数の通信方式のうちのデータ容量および／または通信処理の面において低度の通信方式からより高度の通信方式の順に前記試行を行なう
   ことを特徴とする請求項２に記載の通信システム。
4. 前記通信処理を代行するサーバ装置をさらに備え、
   前記送信側の通信装置は、前記サーバ装置を介して前記受信側の通信装置に前記データ通信処理を要求し、
   前記受信側の通信装置は、前記サーバ装置を介して前記送信側の通信装置に前記データ通信処理の要求に対応した応答処理を発し、
   前記送信側の通信装置と前記受信側の通信装置との間での実データの通信処理は、前記サーバ装置を介することなく両者間で直接に行なう
   ことを特徴とする請求項２に記載の通信システム。
5. 前記サーバ装置は、前記送信側の通信装置と前記受信側の通信装置との間のＳＩＰに従った呼制御処理を代行する
   ことを特徴とする請求項４に記載の通信システム。
6. 前記送信側の通信装置は、ＳＩＰに従った呼制御処理により、前記受信側の通信装置に前記データ通信処理を要求し、
   前記受信側の通信装置は、ＳＩＰに従った呼制御処理により、前記送信側の通信装置に前記データ通信処理の要求に対応した応答処理を行なう
   ことを特徴とする請求項２に記載の通信システム。
7. 前記送信側の通信装置に対しての外部からのアクセスを遮断する遮断手段をさらに備えており、
   前記複数の通信方式は、
   前記遮断手段が、前記送信側の通信装置からの要求により前記送信側の通信装置が送信するデータに対応した前記受信側の通信装置に公開可能なアドレスを生成し、
   前記送信側の通信装置が、送信するデータに対応した前記受信側の通信装置に公開可能なアドレスを前記遮断手段から取得し、この取得したアドレスを前記受信側の通信装置に通知し、
   前記受信側の通信装置が、通知された前記アドレスにアクセスして前記送信側の通信装置が公開する前記データを取得する
   ものを含む
   ことを特徴とする請求項２に記載の通信システム。
8. 前記送信側の通信装置に対しての外部からのアクセスを遮断する遮断手段をさらに備えており、
   前記複数の通信方式は、
   前記遮断手段が、前記送信側の通信装置からの要求により前記送信側の通信装置が送信するデータに対応した前記受信側の通信装置に公開可能なアドレスを生成し、
   前記送信側の通信装置が、送信するデータに対応した前記受信側の通信装置に公開可能なアドレスを前記遮断手段から取得し、この取得した公開可能なアドレスを前記受信側の通信装置に通知し、
   前記受信側の通信装置が、前記公開可能なアドレスにアクセスして前記送信側の通信装置が公開する前記データを取得する
   ものを含む
   ことを特徴とする請求項２に記載の通信システム。
9. 前記複数の通信方式は、
   前記データ送信処理部が送信するデータを所定のデータ保存手段に保存し、
   前記呼制御処理部が、前記データ保存手段に保存したデータに対応する前記受信側の通信装置に公開可能なアドレスを前記受信側の通信装置に通知し、
   前記受信側の通信装置が、前記公開可能なアドレスにアクセスして前記送信側の通信装置が公開する前記データを取得する
   ものを含む
   ことを特徴とする請求項２に記載の通信システム。
10. 前記送信側の通信装置に対しての外部からのアクセスを遮断する遮断手段をさらに備えており、
    前記データ保存手段が、前記送信側の通信装置に対して前記遮断手段の外側に配されている
    ことを特徴とする請求項９に記載の通信システム。
11. 前記受信側の通信装置は、データの受信処理が完了する前には、前記送信側の通信装置からのデータ送信要求に対応する受信完了応答通知に代えて代用通知を前記送信側の通信装置に発し、前記データの受信処理が完了した時点で受信完了応答通知を前記送信側の通信装置に発し、
    前記送信側の通信装置は、送信するデータを所定のデータ保存手段に保持しておき、前記受信完了応答通知を受信した時点で、前記データ保存手段に保存しておいた前記データを削除する
    ことを特徴とする請求項２に記載の通信システム。
12. 送信側の通信装置と受信側の通信装置とがネットワーク接続されており、これら通信装置間において所定の方式に従ってデータ通信を行なう通信システムに用いられる通信装置であって、
    呼制御処理を行なう呼制御処理部と、
    データ送信処理を行なうデータ送信処理部と、
    通信処理に関わる動作を制御する制御部と
    を備え、
    前記制御部は、前記呼制御処理部とデータ送信処理部とを制御して、複数の通信方式のうちの一方の通信方式に従って前記受信側の通信装置との間でデータ通信処理を試行し、当該試行に失敗したときには他方の通信方式に従って前記受信側の通信装置との間でデータ通信処理を試行する
    ことを特徴とする通信装置。
13. 送信するデータを保存するデータ保存部をさらに備え、
    前記データ送信処理部は、送信するデータを前記データ保存部に保存し、
    前記呼制御処理部は、当該通信装置に対しての外部からのアクセスを遮断する遮断手段から、前記データ送信処理部が前記データ保存部に保存したデータに対応する前記受信側の通信装置に公開可能なアドレスを取得し、この取得した公開可能なアドレスを前記受信側の通信装置に通知する
    ことを特徴とする請求項１２に記載の通信装置。
14. 前記データ送信処理部は、送信するデータを所定のデータ保存手段に保存しつつ、前記データ保存手段に保存したデータに対応する前記受信側の通信装置に公開可能なアドレスとともにデータ送信要求を前記受信側の通信装置に発し、このデータ送信要求に対応する受信完了応答通知を前記受信側の通信装置から受信した時点で、前記データ保存手段に保存しておいた前記データを削除する
    ことを特徴とする請求項１２に記載の通信装置。
15. 前記データ保存手段としてのデータ保存部を自装置内にさらに備えている
    ことを特徴とする請求項１４に記載の通信装置。
16. 前記呼制御処理部は、ＳＩＰに従った呼制御処理を行なう
    ことを特徴とする請求項１２に記載の通信装置。
17. 送信側の通信装置と受信側の通信装置とがネットワーク接続されており、これら通信装置間において所定の方式に従ってデータ通信を行なう通信システムに用いられる通信装置であって、
    呼制御処理を行なう呼制御処理部と、
    データ受信処理を行なうデータ受信処理部と、
    通信処理に関わる動作を制御する制御部と
    を備え、
    前記制御部は、前記データ受信処理部におけるデータの受信処理が完了する前には、前記送信側の通信装置からのデータ送信要求に対応する受信完了応答通知に代えて代用通知を前記送信側の通信装置に発し、前記データの受信処理が完了した時点で受信完了応答通知を前記送信側の通信装置に発するように前記呼制御処理部を制御する
    ことを特徴とする通信装置。
18. ネットワーク接続された複数の通信装置間において所定の方式に従って、コンピュータを用いてデータ通信を行なうためのプログラムであって、
    前記コンピュータを、
    呼制御処理を行なう呼制御処理部と、
    データ送信処理を行なうデータ送信処理部と、
    前記呼制御処理部とデータ送信処理部とを制御して、複数の通信方式のうちの一方の通信方式に従って他方の通信装置との間でデータ通信処理を試行し、当該試行に失敗したときには他方の通信方式に従って前記他方の通信装置との間でデータ通信処理を試行する制御部と
    して機能させることを特徴とするプログラム。
19. ネットワーク接続された複数の通信装置間において所定の方式に従って、コンピュータを用いてデータ通信を行なうためのプログラムであって、
    前記コンピュータを、
    呼制御処理を行なう呼制御処理部と、
    データ受信処理を行なうデータ受信処理部と、
    前記データ受信処理部におけるデータの受信処理が完了する前には、他方の通信装置からのデータ送信要求に対応する受信完了応答通知に代えて代用通知を前記他方の通信装置に発し、前記データの受信処理が完了した時点で受信完了応答通知を前記他方の通信装置に発するように前記呼制御処理部を制御する制御部と
    して機能させることを特徴とするプログラム。
    

Images