JP4382745B2 - 通信システム - Google Patents

Description

この発明は通信システムに関し、特にＴＣＰ／ＩＰプロトコルをベースとしつつ、クライエントから他のクライエントへコンテンツデータを連続的に通信することを可能とする技術に関するものである。

テレビ会議やテレビ電話のシステムにおいて、専用線に代えて、インターネットを使用することが行われている。この際一般には、ＵＤＰプロトコルやＲＴＰプロトコル(Real-time Transfer Protocol)などが用いられてきた。

図１に、ＲＴＰプロトコルを用いたテレビ電話における通信を示す。図では、音声データについてのみ示しているが、画像データについても同様にして伝送される。

まず、マイクから音声が取得されこれがサウンドボードに与えられる（ステップＳ１）。次に、サウンドボードは、これを所定の大きさに区切ってディジタルデータに変換する（ステップＳ２）。続いて、通信アプリケーションは、所定の大きさに区切られた音声データにＲＴＰヘッダを付加する（ステップＳ３）。次に、プロトコルスタックは、これにＩＰヘッダ、ＵＤＰヘッダを付加しパケットとして送信する（ステップＳ４）。

受信側では、このパケットを受けて、プロトコルスタックがＲＴＰヘッダの付いた音声データを抽出する（ステップＳ５）。次に、通信アプリケーションが、音声データのみを抽出してデバイスドライバに与える（ステップＳ６）。デバイスドライバはこれをアナログ音声信号に変換し（ステップＳ７）、サウンドボードを介してスピーカから出力する（ステップＳ８）。このようにして、音声が送信される。

ＵＤＰ／ＲＴＰプロトコルでは、受信側から送信側に対してデータを受領した旨の確認を送信しておらず、リアルタイム性の要求から迅速な処理が求められるテレビ電話などに向いているといえる。各パケットの容量は小さく、たとえ一つのパケットが消失したとしても、音声や画像の途切れは人間が知覚できない程度だからである。

上記のように、ＵＤＰ／ＲＴＰプロトコルによるデータ通信は、大量のデータをリアルタイムに送信する場合に、リアルタイム性の維持という点から有効である。

しかしながら、ＵＤＰ／ＲＴＰプロトコルでは、プロトコル自身において暗号化の仕組みが用意されておらず、別途ＶＰＮ(Virtual Private Network)のソフトウエアを送信側受信側に設けなければならなかった。ＵＤＰ／ＲＴＰプロトコルをセキュアに運用する為には、ＶＰＮを含めて、一般的に複雑なシステムと多額のコストを要するという問題があった。また、ＶＰＮによって送信側と受信側を接続すると、両者がＬＡＮで接続された状態と同じになる。そのため、送信側と受信側のネットワークポリシーを同じにしておかないと不具合を生じる可能性がある。したがって、送信側と受信側が同一の組織（会社）に属する場合には問題を生じにくいが、異なる組織間での通信には好ましくないという問題があった。

さらに、ルータを用いる場合、ＵＤＰ／ＲＴＰプロトコルでは、セキュリティの上で問題があった。これを説明したのが図２である。ＰＣ２とＰＣ６との間のデータのやりとりを示している。ルータ４は、ＰＣ２の側に設けられたものである。ＰＣ２のローカルアドレスは"172.16.2.10"、ＰＣ６のグローバルアドレスは"210.14.3.22"、ルータ４のグローバルアドレスは"210.17.3.1"である。ルータ４には一つのグローバルアドレス"210.17.3.1"が与えられており、このルータ４には、それぞれ異なるローカルアドレスを持つ複数のＰＣを接続することができる（図では１台のみを示している）。このようにルータを使用することで、1つのグローバルアドレスに対して複数のＰＣを接続することができる。

なお、図２では、説明の都合上ＰＣ２の側にのみルータ４を設けた構成を示しているが、ＰＣ６の側にもルータが設けられることが一般的である。

ＰＣ２、ルータ４、ＰＣ６には、それぞれ自身のポートと相手先のＩＰアドレスとの対応表が設けられている。

ＰＣ２からサーバ６にデータを送信する場合には、ＰＣ２からの送信時点では、発信元のポートとして指定した”5223”を用い、宛先にはサーバ６のグローバルアドレス及び所定ポートを指定する。したがって、宛先として”210.14.3.22:5230”、発信元としてＰＣ２のローカルアドレス”172.16.2.10:5223”を付加して送信する。

これを受け取ったルータ４は、テーブルを参照し、発信元アドレス及びポートを”210.17.3.1:5225”に変換し、サーバ６にインターネットにて転送する。サーバ６はこれをポート5230にて受信する。

サーバ６から、ＰＣ２に対してデータ通信をする場合には、サーバ６からの送信時点では、発信元のポートとして指定した”5020”を用い、宛先にはルータ４のグローバルアドレス及びポートを指定する。したがって、宛先として”210.17.3.1:5235”、発信元としてサーバ６のグローバルアドレス及び所定ポート”210.14.3.22:5020”を付加して送信する。

これを受け取ったルータ４は、テーブルを参照し、宛先アドレス及びポートを”210.16.2.10:5040”に変換し、ＰＣ２に転送する。ＰＣ２はこれをポート5040にて受信する。

UDP/RTPプロトコルでは、例えば上記の様に宛先のグローバルアドレス及びポートをＰＣ２とサーバ６で保持しかつ、ルータ４とＰＣ２のアドレス・ポート対照テーブルをルータ４に保持する事により、通信を行う事ができる。しかしながら、これを実現する為には、通常ルータ４の特定ポート（この例では”5235”）について、固定的に、外部からの通信を無条件で通過させる設定とする必要があり、これがいわゆるセキュリティー・ホールとなり、外部からの攻撃にさらされる恐れが大きくなる。（これについても、複雑な最新手法でリスクを低減する事は可能であるが、VPNと同様一般的に複雑なシステムと多額のコストを要する。）
これに対して、ＴＣＰ／ＩＰプロトコルは、セキュリティの面において上記ＵＤＰ／ＲＴＰプロトコルよりも優れている。この点を示すのが、図３である。

ＰＣ８の側にルータ１０が設けられている。クライエント８からサーバ１２に対する接続要求は、一旦、ルータ１０に送られる。この接続要求は、宛先アドレス"210.14.3.22"のポート"80"とされ（以下、"210.14.3.22:80"と表記する）、発信元はローカルアドレス"172.16.2.10:5223"とされる。これを受けたルータ１０は、その時点でローカルアドレスの特定ポートを動的に割り当てて対応テーブルを生成する。つまり、ポート５２２５に、"172.16.2.10:5223"を対応付ける。

そして、ルータ１０は、この対応テーブルにしたがって、発信元のローカルアドレスをルータのグローバルアドレス"210.17.3.1:5225"に変更して、接続要求を送信する。

これをポート80で受けたサーバ１２は、動的にポートを割り当てる。この例では、"5230"が割り当てられている。サーバ１２は、ポート5230と、発信元のアドレス"210.17.3.1:5225"との対応テーブルを生成する。

サーバ１２からのレスポンスは、宛先"210.17.3.1:5225"、発信元"210.14.3.22:5230"として送信される。

これを受けたルータ１０は、ポート5225からのリクエストに対するレスポンスであることを確認して、対応テーブルに従いアドレスを変換する。すなわち、宛先を"172.16.2.10:5223"に変更して、クライエント８に送信する。

このように、サーバ１２にとって、外部からのデータは全てポート８０を介して受信されるので、ポート８０に対するセキュリティだけを万全にすればよく、サーバ側のセキュリティ対策は比較的容易である。さらに、クライアント側のセキュリティについては、ルータ１０のポート”5225”は、動的に割当てられる上に、ルータの設定をインターネット接続で一般的な安全性の高い設定で運用可能である。この設定を、図３を例としてやや詳細に説明すれば、(1)内側から外側への通信（ＰＣ８〜ルータ１０〜サーバ１２）は無条件に、(2)外側から内側への通信は、内側から外側（ＰＣ８〜ルータ１０〜）へのリクエストに対するレスポンス（〜ルータ１０〜ＰＣ８８）のみを通過させるというものである。

さらに、ＴＣＰ／ＩＰプロトコルでは、クライエントであるＰＣ８にとって、リクエストに対するレスポンスでなければルータ１０が受付ないので、外部からの侵入に対して高いセキュリティを保持できる。

しかしながら、ＴＣＰ／ＩＰプロトコルをベースとするＨＴＴＰプロトコルは、クライエントとサーバとの間の通信プロトコルであり、テレビ電話などのようなクライエント間の通信には用いることができない。さらに、テレビ会議などのような多数のクライエント間の通信にも用いることはできない。

さらに、ＴＣＰ／ＩＰプロトコルは、データが相手方に到達したかどうかの確認を行ってから次のデータを送るようにしている。このため、通信障害などによって、あるデータが相手方に到達しない場合には、画像や音声がとぎれてしまうという問題があった。テレビ電話などのアプリケーションでは、すべてのデータが正確に到達することよりも、伝送のリアルタイム性の方が重要であるから、このような問題は致命的でもある。

そこで、この発明は、ＴＣＰ／ＩＰプロトコルを用いることによってセキュリティを確保しつつ、リアルタイム性のある通信を実現した通信技術を得ることを目的とする。

以下のこの発明のいくつかの側面を示す。

(1)(2)(3)この発明に係る通信システムは、(d)サーバ装置と、当該サーバ装置と通信可能な(e)第１〜第ｎのクライエント装置とを備えた通信システムであって、
前記第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求をサーバ装置に送信する手段と、(e2)サーバからのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、(e3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求をサーバ装置に送信する手段と、(e5)サーバからのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、(e6)サーバ装置からのコンテンツデータを受信する手段とを備えており、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信する手段と、(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信する手段と、(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段とを備えている。

サーバ装置は、各クライエント装置からのコンテンツデータをＨＴＴＰの連続的送信リクエストによって受信し、これを、各クライエント装置からのＨＴＴＰ連続的受信リクエストによって各クライエント装置に対して転送するようにしている。したがって、ＨＴＴＰプロトコルを用いてセキュリティを確保しつつ、リアルタイム性のある通信を実現している。

(4)この発明に係るシステムは、サーバ装置が、(d8)受信した第1〜第ｎのコンテンツデータを記録するための第１〜第ｎバッファを備え、送信手段が、第１〜第ｎのバッファから第１〜第ｎのコンテンツデータを読み出して送信し、受信手段が、第１〜第ｎのバッファのそれぞれについて、バッファに余裕があれば、受信したコンテンツデータをバッファに記録し、バッファに余裕がなければ、受信したコンテンツデータをバッファに記録しないか、または、バッファに記録されたコンテンツデータのいずれかを削除して受信したコンテンツデータをバッファに記録する処理を行うことを特徴としている。

したがって、通信遅延が生じた場合には、コンテンツデータを破棄することによってリアルタイム性を維持することができる。

(5)この発明に係る通信システムは、受信手段が、バッファに所定以上のコンテンツデータが記録されればバッファに余裕がないと判断することを特徴としている。

したがって、通信遅延が生じたか否かの判断が容易である。

(6)この発明に係る通信システムは、受信手段が、受信したコンテンツデータのタイムスタンプが現在時刻よりも所定時間以上の差があれば、バッファに余裕がないと判断することを特徴としている。

したがって、通信遅延を正確に判定することができる。

(7)この発明に係る通信システムは、送信手段が、所定時間以上送信すべきコンテンツデータがない場合には、ダミーデータを送信することを特徴としている。

したがって、通信システムのいずれかの部位に、無データ状態の所定時間以上の継続によって接続を切断する機能があっても、接続を維持することができる。

(8)この発明に係る通信システムは、第1〜第ｎのクライエント装置のそれぞれが、(e7)制御データ受信のために、ＴＣＰ／ＩＰの制御下りセッション開設要求をサーバ装置に送信する手段と、(e8)開設されたセッションにおいて、制御データ受信のために、リクエストを送信する手段と、(e9)制御下りセッションにより、サーバ装置からレスポンスとして制御データを受信する手段と、(e10)制御データ送信のために、ＴＣＰ／ＩＰの制御上りセッション開設要求をサーバ装置に送信する手段と、(e11)制御上りセッションにより、リクエストとしてサーバ装置に対し制御データを送信する手段とを備えたことを特徴としている。

したがって、ＴＣＰ／ＩＰプロトコルを用いつつ、サーバ装置が積極的に制御データをクライエント装置に対して送信することができる。

(9)この発明に係る通信システムは、サーバ装置が、(d9)制御データのためのＴＣＰ／ＩＰの制御下りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、(d10)制御下りセッションを用いて、レスポンスとして制御データを送信する手段と、(d11)制御データのためのＴＣＰ／ＩＰの制御上りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、(d12)制御上りセッションにより、リクエストとして制御データを受信する手段とを備えたことを特徴としている。

したがって、ＴＣＰ／ＩＰプロトコルを用いつつ、サーバ装置が積極的に制御データをクライエント装置に対して送信することができる。

(10)この発明に係る通信システムは、サーバ装置が、第１〜第ｎのクライエント装置のいずれかから、制御上りセッションによって、通信を終了する旨の制御データを受け取った場合に、他のクライエント装置に対し、制御下りセッションを用いて、当該終了するクライエント装置を特定した制御データを送信することを特徴としている。

したがって、特定のクライエント装置の終了を他のクライエント装置に通知することができる。

(11)この発明に係る通信システムは、サーバ装置が、第1〜第ｎのクライエント装置のいずれかとのコンテンツデータの送信または受信に障害がある場合にも、通信を終了する旨の制御データを受け取った場合と同様の処理を行うことを特徴としている。

したがって、特定のクライエント装置の障害を他のクライエント装置に通知することができる。

(12)この発明に係る通信システムは、終了するクライエント装置を特定した制御データを受信したクライエント装置は、当該終了するクライエント装置のコンテンツデータを受信するために開設していたサーバ装置との間のセッションを終了することを特徴としている。

したがって、不要なセッションを停止することができる。

(13)この発明に係る通信システムは、クライエント装置の各機能の一部または全部は、クライエント装置がサーバ装置に接続した際に、サーバ装置からダウンロードされるクライエントプログラムによって実現されることを特徴とている。

したがって、クライエント装置に特別なプログラムを用意しなくとも、サーバ装置からプログラムをダウンロードしてシステムを構築することができる。

(18)この発明に係る通信方法は、サーバ装置と、当該サーバ装置と通信可能な第１〜第ｎのクライエント装置とを備えた通信方法であって、
第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求をサーバ装置に送信し、(e2)サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信し、(e3)コンテンツデータを所定単位ごとにサーバ装置に送信し、(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求をサーバ装置に送信し、(e5)サーバからのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信し、(e6)サーバ装置からのコンテンツデータを受信し、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設し、(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信し、(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設し、(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信し、(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信し、(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを第１〜第ｎのバッファに記憶し、(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信することを特徴としている。

サーバ装置は、各クライエント装置からのコンテンツデータをＨＴＴＰの連続的送信リクエストによって受信し、これを、各クライエント装置からのＨＴＴＰ連続的受信リクエストによって各クライエント装置に対して転送するようにしている。したがって、ＨＴＴＰプロトコルを用いてセキュリティを確保しつつ、リアルタイム性のある通信を実現している。

(19)この発明に係る通信システムは、(a)サーバ装置と、当該サーバ装置と通信可能な(b)第１のクライエント装置および(c)第２のクライエント装置とを備えた通信システムであって、
前記第１のクライエント装置は、
(b1)コンテンツデータのために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、(b2)サーバ装置からのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、(b3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段とを備えており、
前記第２のクライエント装置は、
(c1)コンテンツデータのために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、(c2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、(c3)サーバ装置からのコンテンツデータを受信する手段とを備えており、
前記サーバ装置は、
(a1)第1のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、(a2)第２のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、(a3)第1のクライエント装置からのＨＴＴＰプロトコルの送信リクエストを受信する手段と、(a4)第２のクライエント装置からのＨＴＴＰプロトコルの受信リクエストを受信する手段と、(a5)前記送信リクエストを受けた後に、第1のクライエント装置から送信されてくるコンテンツデータを受信する手段と、(a6)受信したコンテンツデータを、前記受信リクエストを送信してきた第2のクライエント装置に送信する手段とを備えたことを特徴としている。

サーバ装置は、各クライエント装置からのコンテンツデータをＨＴＴＰの連続的送信リクエストによって受信し、これを、各クライエント装置からのＨＴＴＰ連続的受信リクエストによって各クライエント装置に対して転送するようにしている。したがって、ＨＴＴＰプロトコルを用いてセキュリティを確保しつつ、リアルタイム性のある通信を実現している。

(24)この発明に係る通信システムは、(d)サーバ装置と、当該サーバ装置と通信可能な(e)第１〜第ｎのクライエント装置とを備えた通信システムであって、
前記第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってコンテンツデータを所定単位ごとにサーバ装置に送信する手段と、(e3)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、(e4)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってサーバ装置からのコンテンツデータを受信する手段とを備えており、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段とを備えたことを特徴としている。

サーバ装置は、各クライエント装置からのコンテンツデータをＴＣＰ／ＩＰの要求によって受信し、これを、各クライエント装置からのＴＣＰ／ＩＰ要求によって各クライエント装置に対して転送するようにしている。したがって、ＴＣＰ／ＩＰプロトコルを用いてセキュリティを確保しつつ、リアルタイム性のある通信を実現している。

この発明において、「コンテンツデータ」とは、画像データ(静止画、動画を問わない)、音声データ、文字データなどをいう。

「ＨＴＴＰプロトコル」とは、ＨＴＴＰプロトコルだけでなくこれに類するプロトコル、例えばＨＴＴＰ（Ｓ）プロトコルも含む概念である。

「連続的受信(送信)リクエスト」とは、ＨＴＴＰプロトコルなどのリクエスト・レスポンス型の通信方式において、連続的なリクエスト(レスポンス)の送信を求める要求である。実施形態では、chunkedコーディングがこれに対応する。

「所定単位ごと」とは、1回に送信するサイズを同じにする場合だけでなく、時間ごとのサイズ(bit per second)を同じにする場合を含む。さらに、毎回のサイズを変える場合も含む概念である。

「プログラム」とは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。

発明を実施するための形態

１．全体構成
図４に、この発明の一実施形態によるテレビ会議システムの全体構成を示す。第1のクライエント装置２０、第２のクライエント装置２４が、インターネット２６に接続されている。さらに、サーバ装置２２もインターネット２６に接続されている。第１のクライエント２０、第２のクライエント装置２４は、サーバ装置２２を介して、動画および音声の通信を行う。

図５に、このシステムによるデータ通信の概要を示す。第１のクライエント装置２０からの画像・音声データは、アップロードセッションU1によりサーバ装置２２に送信される。サーバ装置２２は、この画像・音声データをダウンロードセッションD2を用いて第２のクライエント装置２４に送信する。なお、ＴＣＰ／ＩＰ、ＨＴＴＰプロトコルでは、サーバ装置２２が主導となって第２のクライエント装置２４に対してデータを送ることはできない。本発明ではこれを実現しているが、その手法は後述する。このようにして、第１のクライエント装置２０から第２のクライエント装置２４に対し、画像・音声データが送信される。

なお、ＨＴＴＰプロトコルでは、クライエントからのリクエストに対するサーバのレスポンスという形式でデータの送信が行われる。この実施形態では、連続して画像・音声データを送信するため、データ送信ごとにリクエスト・レスポンスを行うのではなく、1つのリクエストに対して複数のレスポンスを送信する形式を用いている（chunked転送コーディング）。

第２のクライエント装置２４からの画像・音声データの送信も、同様にして行われる。第２のクライエント装置２４からの画像・音声データは、アップロードセッションU2によりサーバ装置２２に送信される。サーバ装置２２は、この画像・音声データをダウンロードセッションD1を用いて第１のクライエント装置２０に送信する。このようにして、第２のクライエント装置２４から第１のクライエント装置２０に対し、画像・音声データが送信される。

なお、この実施形態では、制御データにつき、上記の画像・音声のセッションとは別のセッションを形成するようにしている。制御データの伝送においては、画像・音声データと異なって、データ送信ごとにリクエスト・レスポンスを行う通常の方式を採用している。

図５に示すように、第1のクライエント装置２０とサーバ装置２２との間に制御データ用のセッションCU1,CU2を設けている。第１のクライエント装置２０からサーバ装置２２に制御データを送信する場合には、その都度、サーバ装置２２に対してリクエストを送信し、このリクエスト中に制御データを含める。

一方、サーバ装置２２から第1のクライエント装置２０に対して制御データを送信したい場合、サーバ装置２２はクライエントからのリクエストに対応するレスポンスしか送信することができないので問題となる。この実施形態では、第1のクライエント装置２０から予めリクエストを送信しておく。サーバ装置２２は、送信すべき制御データが生じた時点で、この予め受けているリクエストのレスポンスとして制御データを第1のクライエント装置２０に送信する。

第2のクライエント装置２４とサーバ装置２２との間においても同様にして制御データが送受信される。

図６、図７に、第１のクライエント装置２０、サーバ装置２２、第２のクライエント装置２４の機能ブロック図を示す。図６は制御データの通信に関する機能であり、図７は画像・音声データの通信に関する機能である。なお、図６、図７では、煩雑さを避けるために、第１のクライエント装置２０から、サーバ装置２２ないし第２のクライエント装置２４に対して、制御データ、画像・音声データを送信する場合の機能のみを表している。第２のクライエント装置２４から、サーバ装置２２ないし第１のクライエント装置２０に対して、制御データ、画像・音声データを送信する場合の機能は省略されているが、同じように設けられている。

図６において、第１のクライエント装置２０のセッション開設要求手段６０は、サーバ装置２２の開設許諾手段６４に対し、ＴＣＰ／ＩＰプロトコルによるセッション開設要求を送信する。これを受けた開設許諾手段６４は、開設許諾を送り返す。

通話の開始指令を受けるなど制御データ送信が必要である状態になると、クライエント装置２０のリクエスト手段６２は、ＨＴＴＰ（Ｓ）プロトコルによるリクエストを、サーバ装置２２の制御データ受信手段に送信する。この際、リクエスト手段６２は、リクエスト中に制御データを含めて送信することによって制御データの伝送を行う。

サーバ装置２２の制御データ受信手段６６は、このリクエストを受けて、これに含まれる制御データを取得する。このようにして、第１のクライエント装置２０からサーバ装置２２への制御データの送信が行われる。

第２のクライエント装置２４のセッション開設要求手段７０は、サーバ装置２２の開設許諾手段６４に対し、ＴＣＰ／ＩＰプロトコルによるセッション開設要求を送信する。これを受けた開設許諾手段６４は、開設許諾を送り返す。

開設許諾を受けた第２のクライエント装置２４のリクエスト手段７２は、サーバ装置２２の制御データ送信手段６８に対しＨＴＴＰ（Ｓ）プロトコルによるリクエストを送信する。制御データ送信手段６８は、送信すべき制御データがあるまで待機し、送信データが生じたら第２のクライエント装置２４に対して送信データを含めたレスポンスの送信を行う。したがって、第２のクライエント装置２４の制御データ受信待機手段７４は、リクエストに対するレスポンスを待機する状態となる。

サーバ装置２２から第２のクライエントに対して制御データを送信する必要が生じた際には、制御データ送信手段６８は、上記のレスポンスとして制御データを送信することができる。

第２のクライエント装置２４の制御データ受信待機手段７４が、レスポンスとして制御データを受信すると、リクエスト手段７２は、次の制御データ受信に備えて、サーバ装置２２に対してリクエストを送信する。

なお、１つのリクエストに対して複数のレスポンスを受け取ることのできるプロトコルであれば、第２のクライエント装置２４は、最初にリクエストを一度送るだけで、複数のレスポンスを受け取ることができる。

なお、上記では、第１のクライエント装置２０とサーバ装置２２の間、第２のクライエント装置２４とサーバ装置２２の間での制御データのやりとりを説明した。第１のクライエント装置２０と第２のクライエント装置２４との間で制御データをやりとりする場合には、サーバ装置２２の制御データ受信手段６６が受信した制御データを、制御データ送信手段６８に渡すことにより実現することができる。

図７に、画像・音声データの通信に関する機能を示す。第１のクライエント装置２０のセッション開設要求手段３０は、サーバ装置２２の開設許諾手段３６に対してＴＣＰ／ＩＰのセッション開設要求を送信する。これを受けて、開設許諾手段３６は、開設許諾を送信リクエスト手段３２に送り返す。これにより、第１のクライエント装置２０とサーバ装置２２との間に、ＴＣＰ／ＩＰのセッションが確立する。

第２のクライエント装置２４のセッション開設要求手段４８と、サーバ装置２２の開設許諾手段３６、受信リクエスト手段５０との間でも、同様にしてＴＣＰ／ＩＰのセッションが確立する。

セッションが確立すると、第２のクライエント２４の受信リクエスト手段５０は、サーバ装置２２からデータを受信するためのＨＴＴＰ（Ｓ）データ受信リクエストを、サーバ装置２２に送信する。このリクエストは、「データサイズ不明」つまりchunked転送コーディングとして行う。

同様にして、第１のクライエント装置２０の送信リクエスト手段３２は、サーバ装置２２にデータを送信するためのＨＴＴＰ（Ｓ）データ送信リクエストを、サーバ装置２２に送信する。このリクエストも、「データサイズ不明」つまりchunked転送コーディングとして行う。

次に、第１のクライエント装置２０のコンテンツ送信手段３４は、ＨＴＴＰ（Ｓ）リクエストによって、所定単位に分割した画像・音声を、サーバ装置２２のコンテンツデータ受信手段４２に送信する。chunked転送コーディングであるため、サーバ装置２２のコンテンツデータ受信手段４２は、一単位の画像・音声を受信してもレスポンスを行わない。したがって、第１のクライエント装置２０とサーバ装置２２のＨＴＴＰ接続状態は維持される。

コンテンツデータ受信手段４２によって受信された画像・音声は、バッファ４４に一時記憶される。コンテンツデータ送信手段４６は、バッファ４４から画像・音声を読み出して、ＨＴＴＰ（Ｓ）レスポンスによって、第２のクライエント装置２４のコンテンツ受信手段５２に送信する。chunked転送コーディングであるため、サーバ装置２２のコンテンツデータ送信手段４６は、レスポンスを送信しても、ＨＴＴＰ接続状態は維持される。

なお、サーバ装置２２と第２のクライエント装置２４との間の通信状態が悪いなどの理由によって、バッファ４４が満杯となった場合、画像・音声の廃棄処理を行う。つまり、コンテンツデータ送信手段４６は、バッファ４４に記憶された最も古い未送信データを削除し、新たに受信した画像・音声を記憶する。

以上のようにして、ＨＴＴＰプロトコルを用いつつ、第１のクライエント装置２０から第２のクライエント装置２４へ、画像・音声を送信することができる。

図においては、第１のクライエント装置２０から第２のクライエント装置２４に対して画像・音声を送信する機能を説明している。第２のクライエント装置２４から第１のクライエント装置２０にデータを送信する機能も、各装置に同様に備わっているが、図では省略した。第２のクライエント装置２４から第１のクライエント装置２０に対する画像・音声の送信も同様にして行われる。

なお、この実施形態においては、ＨＴＴＰ（Ｓ）プロトコルを用いているが、ＨＴＴＰと表示している。また、ＨＴＴＰ（Ｓ）プロトコルに代えて、ＨＴＴＰプロトコルを用いても良い。

２．クライエント装置２０、２４のハードウエア構成
図８に、クライエント装置２０、２４のハードウエア構成を示す。図において、括弧を付さない符号は第１のクライエント装置２０、括弧を付した符号は第２のクライエント装置２４を示している。

ＣＰＵ２０２には、メモリ２０４、ディスプレイ２０６、通信回路２０８、ハードディスク２１０、サウンドボード２１２、キーボード／マウス２１４が接続されている。

メモリ２０４は、ＣＰＵ２０２のワーク領域として使用される。ディスプレイ２０６は、画像を表示するためのものである。通信回路２０８は、インターネットに接続するためのものである。

ハードディスク２１０には、オペレーティングシステム（ＯＳ）２１６、電話会議のための通信プログラム２１８が記録されている。ＯＳ２１６は、ＴＣＰ／ＩＰプロトコルのためのプログラムを含んでいる。通信プログラム２１８は、画像・音声を送受信するためのものであり、ＯＳ２１６と協働してその機能を発揮する。なお、単独でその機能を発揮する通信プログラム２１８を用いてもよい。

サウンドボード２１２には、マイク２１３、スピーカ２１５が接続されている。サウンドボード２１２は、マイク２１３によって取得したユーザの音声を、ディジタルデータに変換する。また、音声信号をスピーカ２１５に与えて音声を出力する。

キーボード／マウス２１４は、ユーザの操作を受けて指令などを入力するためのものである。

カメラ２１９は、ユーザを撮像して、画像をディジタル出力するものである。

３．サーバ装置２２のハードウエア構成
図９に、サーバ装置２２のハードウエア構成を示す。ＣＰＵ２２２には、メモリ２２４、ディスプレイ２２６、通信回路２２８、ハーディスク２３０、キーボード／マウス２３２が接続されている。メモリ２２４は、ＣＰＵ２２２のワーク領域として用いられる。ディスプレイ２２６は、制御状態をモニタリングするための表示などを行うものである。

通信回路２２８は、インターネットに接続するためのものである。ハードディスク２３０には、ＯＳ２３４、電話会議のための通信プログラム２３６が記録されている。ＯＳ２３４は、ＴＣＰ／ＩＰプロトコルのためのプログラムを含んでいる。通信プログラム２３６は、画像・音声を送受信するためのものであり、ＯＳ２３４と協働してその機能を発揮する。なお、単独でその機能を発揮する通信プログラム２３６を用いてもよい。

４．通信処理
図１０ａ、図１０ｂ、図１０ｃに、このテレビ会議システムの処理を示す。第１のクライエント装置２０のＯＳ２１６・通信プログラム２１８のフローチャート、サーバ装置２２のＯＳ２３４・通信プログラム２３６のフローチャート、第２のクライエント装置２４のＯＳ２５６・通信プログラム２５８のフローチャートを示している。

(1)初期設定と制御データ受信準備
まず、図１０ａに示す処理によって、初期設定と制御データ受信のための準備を行う。

ユーザが第１のクライエント装置２０のキーボード２１４からサーバ装置２２のＵＲＬを指定する。これを受けて、ステップＳ１１において、第１のクライエント２０のＣＰＵ２０２は、通信回路２０８によりインターネットを介して、ＴＣＰ／ＩＰセッション開設要求をサーバ装置２２送信する。これに対し、サーバ装置２２は、セッション開設許諾を返信する（ステップＳ３１）。これにより、第１のクライエント装置２０とサーバ装置２２との間にＴＣＰ／ＩＰプロトコルのセッションが開設される。このセッションは、制御データのために用いられる。

同じように、ユーザが第２のクライエント装置２４のキーボード２５４からサーバ装置２２のＵＲＬを指定する。これを受けて、ステップＳ３１において、第２のクライエント２４のＣＰＵ２４２は、通信回路２４８によりインターネットを介して、ＴＣＰ／ＩＰセッション開設要求をサーバ装置２２送信する。これに対し、サーバ装置２２は、セッション開設許諾を返信する（ステップＳ３２）。これにより、第２のクライエント装置２４とサーバ装置２２との間にＴＣＰ／ＩＰプロトコルのセッションが開設される。このセッションは、制御データのために用いられる。

次に、第１のクライエント装置２０のＣＰＵ２０２は、制御データを含むＨＴＴＰリクエストをサーバ装置２２に対して送信する（ステップS１２）。この際、ＨＴＴＰリクエストのメッセージヘッダ部分Ｈ（図１１参照）に、制御データとして自らの装置ＩＤ（たとえば、"ID01"とする）を含めて送信する。これを受けたサーバ装置２２は（ステップS３３）、送られてきた装置ＩＤ"ID01"などをログイン中ユーザとしてメモリ２２４に記憶する（図１２参照）。

一方、第2のクライエント装置２４のＣＰＵ２４２も、制御データを含むＨＴＴＰリクエストをサーバ装置２２に対して送信する（ステップS５２）。この際、ＨＴＴＰリクエストのメッセージヘッダ部分Ｈ（図１１参照）に、制御データとして自らの装置ＩＤ（たとえば、"ID02"とする）を含めて送信する。これを受けたサーバ装置２２は（ステップS３４）、送られてきた装置ＩＤ"ID02"などをログイン中ユーザとしてメモリ２２４に記憶する（図１２参照）。

次に、サーバ装置２２のＣＰＵ２２２は、ステップＳ３３にて受けた、第1のクライエント装置２０からのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを送信する（ステップＳ３５）。この際、ＨＴＴＰレスポンスのメッセージヘッダ部分Ｈ（図１１参照）に、ＨＴＴＰプロトコルによるセッションＩＤ（ここでは0001）を付して送信する。さらに、制御データとしてメモリ２２４に記憶されているログインユーザのＩＤをヘッダ部分Ｈに含めて送信する。

この際、サーバ装置２２は、図１３のセッション対応テーブル８０（メモリ２２４）に、第1のクライエント装置２０（ID01）に対して制御データを送信するためのセッションのＩＤ（00001）を記録する。

レスポンスを受け取った第1のクライエント装置２０は、他のログインユーザのＩＤをメモリ２０４に記憶する。これにより、他にどのクライエント装置が接続されているかを知ることができる。この際、第1のクライエント装置２０は、カメラなどの初期設定を行う。

さらに、第1のクライエント装置２０では、図１４Ａに示すように、サーバ装置２２からの制御データを受信するためのセッションＩＤ(0001)を、セッション対応テーブル８２(メモリ２０４)に記録する。

次に、第１のクライエント装置２０は、サーバ装置２２から制御データを受け取ることができるように、上記セッションＩＤ(0001)を伴ったＨＴＴＰリクエストをサーバ装置２２に送信しておく（ステップＳ１４）。将来、サーバ装置２２が制御データを第1のクライエント２０に送る際には、このＨＴＴＰリクエストのレスポンスを用いることができる。このようにして、サーバ装置２２側からのデータ送信を可能としている。

なお、このセッションによってレスポンスを受けた第１のクライエント装置２０は、次の制御データ受信のために、リクエストを送信しておく。

上記と同様の処理がサーバ装置２２と第2のクライエント装置２４との間でも行われる。サーバ装置２２のＣＰＵ２２２は、ステップＳ３４にて受けた、第２のクライエント装置２４からのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを送信する（ステップＳ３６）。この際、ＨＴＴＰレスポンスのメッセージヘッダ部分Ｈ（図１１参照）に、ＨＴＴＰプロトコルによるセッションＩＤ（ここでは0002）を付して送信する。さらに、制御データとしてメモリ２２４に記憶されているログインユーザのＩＤをヘッダ部分Ｈに含めて送信する。

この際、サーバ装置２２は、図１３のセッション対応テーブル８０（メモリ２２４）に、第２のクライエント装置２４（ID02）に対して制御データを送信するためのセッションのＩＤ（0002）を記録する。

レスポンスを受け取った第２のクライエント装置２４は、他のログインユーザのＩＤをメモリ２４４に記憶する。これにより、他にどのクライエント装置が接続されているかを知ることができる。この際、第２のクライエント装置２４は、カメラなどの初期設定を行う。

さらに、第２のクライエント装置２４では、図１４Ｂに示すように、サーバ装置２２からの制御データを受信するためのセッションＩＤ(0002)を、セッション対応テーブル８４(メモリ２４４)に記録する。

次に、第２のクライエント装置２４は、サーバ装置２２から制御データを受け取ることができるように、上記セッションＩＤ(0002)を伴ったＨＴＴＰリクエストをサーバ装置２２に送信しておく（ステップＳ５４）。将来、サーバ装置２２が制御データを第２のクライエント２４に送る際には、このＨＴＴＰリクエストのレスポンスを用いることができる。このようにして、サーバ装置２２側からのデータ送信を可能としている。

なお、このセッションによってレスポンスを受けた第２のクライエント装置２４は、次の制御データ受信のために、リクエストを送信しておく。

なお、上記では、第1のクライエント２０、第２のクライエント２４に対してサーバ装置２２が制御データを送信するためのセッションを準備した。第1のクライエント２０、第２のクライエント２４からサーバ装置２２に対して制御データを送信するためのセッションは、その必要が生じた際にセッションを開設すればよい。

上記のようにして、初期設定と制御データ受信のための準備が整う。第1・第２のクライエント装置２０、２４における処理だけを示すフローチャートが図１５である。このフローチャートを用いて、上記の処理を再び説明すると次のようになる。なお、ステップＳ１１０は、図１０ａのステップＳ１１、Ｓ５１に、ステップＳ１１１は、ステップＳ１２、Ｓ５２に、ステップＳ１１２は、ステップＳ１３、Ｓ５３に対応する。

ステップS１１３では、ＨＴＴＰレスポンスとして受信した制御データが、どのような種類のものであるかを判断している。ここでは、他のクライエントが接続された旨の制御データを受け取っているので、ステップＳ１１７の他クライエント接続要求処理（画像・音声データの通信処理）を実行する。

(2)画像・音声データの通信処理
上記のようにして、初期設定と制御データ受信のための準備が整うと、図１０ｂ、図１０ｃに示す画像・音声データの通信処理を行う。

図１０ｂにおいて、第１のクライエント装置２０は、画像・音声のデータを送信するためのＴＣＰ／ＩＰセッションの開設要求を、サーバ装置２２に送信する（ステップＳ１５）。これを受けて、サーバ装置２２は、セッション開設許諾を返送する（ステップＳ３７）。

第２のクライエント装置２４は、画像・音声データを受信するためのＴＣＰ／ＩＰセッションの開設要求を、サーバ装置２２に送信する（ステップＳ５５）。これを受けて、サーバ装置２２は、セッション開設許諾を返送する（ステップＳ３８）。

これに続き、第２のクライエント装置２４は、レスポンスとしてサーバ装置２２からデータを受信できるように、ＨＴＴＰリクエストをサーバ装置２２に送信する（ステップＳ５６）。なお、この際のＨＴＴＰリクエストは、chunked転送コーディングとし、一つのリクエストに対して複数のレスポンスを受けることができるようにする。

なお、図においては1つのセッションしか示されていないが、画像データ送信用のセッションと、音声データ送信用のセッションがそれぞれ開設される。

一方、第１のクライエント装置２０は、サーバ装置２２に対し、それぞれのセッションの上でＨＴＴＰリクエストによって画像データ・音声データを所定単位ごとに送信する。なお、この画像データ・音声データは、マイク２１３、カメラ２１９から取得したものである。この際のＨＴＴＰリクエストは、chunked転送コーディングとし、複数のリクエストを連続して送信できるようにしている（ステップＳ１６、Ｓ１７・・）。

サーバ装置２２は、第１のクライエント装置２０から送信されてきた画像データ・音声データを受けると、メモリ２２４の第1のクライエント装置用のバッファに記録する。このバッファも、画像データ、音声データごとに設けられている。

続いて、サーバ装置２２は、第1のクライエント装置用のバッファから画像データ・音声データを読み出し、メモリ２２４に記憶している全てのログインクライエント（送信元のクライエントを除く）に対して、画像・音声データをレスポンスとして送信する（ステップＳ４０）。なお、図１０ｂの例では、相手方となるクライエントは第２のクライエント２４だけであるから、第２のクライエント２４に対してのみ画像データ・音声データの転送を行う。

第２のクライエント２４は、画像データ・音声データを受信して（ステップＳ５７）、ディスプレイ２４６、スピーカ２５５から出力する。以後、この転送処理が繰り返される（ステップＳ１７、Ｓ１８、Ｓ４１、Ｓ４２、Ｓ５８、Ｓ５９）。このようにして、第１のクライエント２０のユーザの画像、音声が、第２のクライエント２４のユーザに伝達される。

なお、第２のクライエント装置２４からサーバ装置２２に対する画像・音声データの送信も同じように、画像データ、音声データのセッションがそれぞれ設けられて行われる。

上記の通信処理は、クライエント装置の側だけで見ると、図１５の他クライエント接続要求処理（ステップＳ１１７)に該当する。他クライエント接続要求処理の詳細を、図１６に示す。左側が画像データ（音声データ）の送信処理であり、右側が画像データ（音声データ）の受信処理である。

図において、ステップＳ２０１、Ｓ３０１は、図１０ｂのステップＳ１５、Ｓ５５に対応し、ステップＳ２０２、Ｓ３０２は、図１０ｂのステップＳ１６、Ｓ５６に対応している。

ステップＳ２０２において、第１のクライエント装置２０または第２のクライエント装置２４（以下クライエント装置という）は、ＨＴＴＰリクエスト(送信要求)により、画像データ（音声データ）をサーバ装置２２に送信する（ステップＳ２０２）。具体的には、ＨＴＴＰリクエストのメッセージボディ部分Ｂ（図１１参照）に、画像データ（音声データ）を含めて送信する。なお、ここでは、連続して画像データ（音声データ）を送信できるようにしているので、サーバ装置２２からのレスポンスが返ってこない。つまり、サーバ装置２２によるセッションＩＤが決定されないので、クライエント装置は、自らのクライエントＩＤをＨＴＴＰリクエストのメッセージヘッダ部分Ｈ（図１１参照）に記述して送信する。

この際、クライエント装置は、図１４に示すセッションテーブル８２、８４の制御データ送信用のセッション識別子として、このクライエントＩＤを記録する。図１４では、クライエントＩＤ(ID01)(ID02)が記録されている。

次に、クライエント装置のＣＰＵは、ステップＳ２０３において、通信エラーが生じたかどうかを判断する。通信エラーやタイムアウトがなく正常にデータが送出できた場合には、続いて次に送るべき画像データ(音声データ）をＨＴＴＰリクエストとして送信する（ステップＳ２０４）。この際、上記のクライエントＩＤをヘッダ部分Ｈに記述して送信する。

なお、クライエント装置では、リアルタイムにカメラ２１９（２５９）やマイク２１３（２５３）から取得した画像データ（音声データ）を、メモリ２０４（２４４）にバッファリングし、これを所定単位ずつ読み出して送信する。

ステップS２０５では、通信エラーが生じたかどうかを判断する。通信エラーやタイムアウトがなく正常にデータが送出できた場合には、ステップS２０４に戻って、次の画像データ(音声データ)の送信を行う。

このようにして、連続的に画像データ(音声データ)を、サーバ装置２２に対して送信することができる。

クライエント装置は、自身が有する送信プログラムから通信エラーである旨を受けた場合や、正常にインターネットに送出できた旨の通知を所定時間経過しても受けなかった場合（タイムオーバー）には、ステップS２０３、S２０５において、ステップS２０６に分岐する。

ステップS２０６において、クライエント装置は、サーバ装置２２とのＴＣＰ／ＩＰセッション（受信）を終了する(ステップＳ２０６)。

さらに、クライエント装置は、キーボード／マウス２１４から終了指令が入力されたかを判断する（ステップＳ２０７）。終了指令が入力されていれば、画像・音声データの通信処理（他クライエント処理）を終了する。なお、終了指令がある場合には、制御データを送信するためのセッションをサーバとの間で開設し、終了する旨を伝える。

終了指令がなければ、相手方クライエント装置との通信を行うため、再度ステップＳ２０１以下を実行する。

上記のようにして、画像データ・音声データをサーバ装置に送信する処理が行われる。

上記と同じようにして、サーバ装置２２から画像データ・音声データを受信する処理が行われる（図１６の右側のフローチャート）。なお、受信処理においては、クライエント装置は、ＨＴＴＰリクエスト(受信要求)を行い(ステップＳ３０２)、ＨＴＴＰレスポンスとして所定単位の画像データ(音声データ)を連続して受信している（ステップＳ３０４）。クライエント装置の側からクライエントＩＤをセッション識別子として送信する点は同じである。

また、自身が有する受信プログラムから通信エラーである旨を受けた場合や、正常に受信できた旨の通知を所定時間経過しても受けなかった場合（タイムオーバー）には、通信エラーであると判定する。

上記に説明してきた画像・音声データの通信処理におけるサーバ装置２２のフローチャートを、図１７に示す。この図では、第1のクライエント装置２０からの画像データ（音声データ）を、第2のクライエント装置２４に転送する場合の処理を示している。第２のクライエント装置２４からの画像データ（音声データ）を、第１のクライエント装置２０に転送する場合の処理も同様である。図において、左側は受信プロセス、右側は送信プロセスである。

ステップＳ４０１は図１０ｂのステップＳ３７に対応し、ステップＳ４０２はステップＳ３９に対応する。また、ステップＳ５０２は図１０ｂのステップＳ３８に対応する。

受信プロセスのステップＳ４０２において、サーバ装置２２のＣＰＵ２２２は、第１のクライエント２０から画像データを伴うＨＴＴＰリクエスト（chunked送信要求）を受ける。なお、画像データと同じように、音声データについても並行して同様の処理がなされる。

送られてきたＨＴＴＰリクエストのヘッダには、クライエントＩＤが記述されているので（図１６、ステップＳ２０２参照）、サーバ装置２２は、いずれのクライエントからのデータであるかを判別することができる。また、画像データであるか、音声データであるかは、ヘッダに記述されたデータ形式を見ることによって判別できる。

次に、サーバ装置２２は、第１のクライエント用のバッファＢ１（メモリ２２４）がいっぱいであるかどうかを判断する（ステップＳ４０３）。バッファＢ１に余裕があれば、受信した画像データ（音声データ）をバッファＢ１に記録する。

サーバ装置２２は、クライエント装置２０から制御データ（図１６のステップＳ４０２によるセッションにて受け取る）として終了要求を受け取ったかどうかを判断する（ステップＳ４０５）。受け取っていなければ、画像データ（音声データ）の受信を継続し（ステップＳ４０６）、ステップＳ４０３を経て、ステップＳ４０４においてバッファＢ１に記録する。

受け取っていれば、第１のクライエント装置２０とのＴＣＰ／ＩＰセッションの全てを終了する（ステップＳ４０７）。さらに、第２のクライエント装置２４に対して、第１のクライエント装置２０が終了した旨を、制御データ（セッション0002）として送信する。この際、サーバ装置２２は、図１３のセッションテーブル８０を参照して、何れのセッションを用いるかを知ることができる。

これを受けた第２のクライエント装置２４は、サーバ装置２２との間の第１のクライエントからのデータを受信するためのＴＣＰ／ＩＰセッションを終了する（図示せず）。

一方、送信プロセスのステップＳ５０２において、サーバ装置２２のＣＰＵ２２２は、第２のクライエント２４からＨＴＴＰリクエスト（chunked受信要求）を受ける。なお、画像データと同じように、音声データについても並行して同様の処理がなされる。

送られてきたＨＴＴＰリクエストのヘッダには、クライエントＩＤが記述されているので（図１６、ステップＳ３０２参照）、サーバ装置２２は、いずれのクライエントからのデータであるかを判別することができる。また、画像データ、音声データのそれぞれのためにセッションが設けられているので、画像データであるか音声データであるかの区別が容易である。

次に、サーバ装置２２は、ステップS５０３において、バッファＢ１から画像データ（音声データ）を読み出す。読み出した画像データ（音声データ）を、ＨＴＴＰレスポンスとして、第２のクライエント装置２４に向けて送信する（ステップＳ５０４）。この際、サーバ装置２２は、ＨＴＴＰレスポンスのメッセージヘッダに、この画像データが第１のクライエント装置２０からの転送データであることを示すため転送元クライエントのＩＤを記述して送信する。

サーバ装置２２は、クライエント装置２４から制御データ（図１６のステップＳ３０７によるセッションにて受け取る）として終了要求を受け取ったかどうかを判断する（ステップＳ５０７）。受け取っていなければ、画像データ（音声データ）の読み出しと送信を継続（ステップＳ５０５、Ｓ５０６）する。

受け取っていれば、第２のクライエント装置２４とのＴＣＰ／ＩＰセッションの全てを終了する（ステップＳ５０８）。さらに、第１のクライエント装置２０に対して、第２のクライエント装置２４が終了した旨を、制御データ（セッション0001）として送信する。この際、サーバ装置２２は、図１３のセッションテーブル８０を参照して、何れのセッションを用いるかを知ることができる。

これを受けた第１のクライエント装置２０は、サーバ装置２２との間の第２のクライエントからのデータを受信するためのＴＣＰ／ＩＰセッションを終了する（図示せず）。

上記のようにして、第1のクライエント装置２０からの画像データ（音声データ）が、第２のクライエント装置２４に転送される。送信プロセスは、ステップＳ５０３において、バッファＢ１から画像データ（音声データ）を読み出すとともに、これをバッファＢ１から削除する。したがって、送信が順調に行われれば、バッファＢ１が満杯にならない。

しかし、画像データ（音声データ）の第2のクライエント装置２４への送信が、通信障害などによって遅れると、バッファＢ１が満杯になってしまう。この実施形態では、バッファＢ１が一杯になって受信した画像データの書き込みができなくなれば、バッファＢ１中の最も古いデータを削除して、受信したデータを書き込むようにしている。

このようにして、古い未送信の画像データ(音声データ)を廃棄することにより、リアルタイム性を維持するようにしている。

５．第2の実施形態
(1)実施形態の内容
上記実施形態では、１対１の通信、すなわちテレビ電話について説明した。しかし、図１８に示すように、クライエント装置が３台以上接続されたテレビ会議システムとして使用することができる。

このテレビ会議システムにおける初期設定と制御データ受信準備のフローチャートを、図１９に示す。この図では、ＴＣＰ／ＩＰのセッション開設処理は省略している。

第1のクライエント装置２０は、ＨＴＴＰリクエストをサーバ装置２２に送信する(ステップＳ１２)。サーバ装置２２は、これを受けて、クライエントＩＤ(ID01)をログイン中ユーザとして記録する（図１２参照）。

第2のクライエント装置２４は、ＨＴＴＰリクエストをサーバ装置２２に送信する(ステップＳ５２)。サーバ装置２２は、これを受けて、クライエントＩＤ(ID02)をログイン中ユーザとして記録する（図１２参照）。さらに、サーバ装置２２は、第1のクライエント装置２０、第2のクライエント装置２４に対し、レスポンスを返信する(ステップS３５、S３６)。この際、レスポンスに、ログイン中ユーザ情報を含める。

第１のクライエント装置２０、第２のクライエント装置２４は、制御データを受信するために、リクエストをサーバ装置２２に送信しておく(ステップS１４、S５４)。

第３のクライエント装置２５が、リクエストをサーバ装置２２に送信すると、サーバ装置２２は、クライエントＩＤ(ID03)をログイン中ユーザとして記録する（図１２参照）。さらに、サーバ装置２２は、ログイン中ユーザを含めたレスポンスを、第1のクライエント装置２０、第2のクライエント装置２４、第3のクライエント装置２５に送信する。

これを受けて、クライエント装置は、どの端末装置が接続されているかを知ることができる。なお、第３のクライエント装置２５が、制御データを受信するために、リクエストをサーバ装置２２に送信しておくのは他のクライエントと同じである(ステップS９５)。

図２０に、サーバ装置２２と各クライエント装置２０、２４、２５との間のデータ伝送路を示す。図１９にて説明した制御データ伝送のためのセッションＣＳ１、ＣＳ２、ＣＳ３が設けられている。また、図１９では説明しなかったが、クライエント装置２０、２４、２５からサーバ装置２２に対して制御データを伝送するためのセッションＣ１Ｓ、Ｃ２Ｓ、Ｃ３Ｓが設けられている。セッションＣ１Ｓ、Ｃ２Ｓ、Ｃ３Ｓは、通常のＨＴＴＰプロトコルによって、クライエント装置側からリクエストを行うことにより実現できる。

各クライエント装置とサーバ装置２２との間では、クライエント装置からサーバ装置２２に画像データ(音声データ)を送信するためのセッション、サーバ装置２２からクライエント装置に他の全てのクライエント装置からの画像データ(音声データ)を受信するためのセッションが設けられている。

第1のクライエント装置２０についていうと、セッションＶ１Ｓは画像データをサーバ装置２２に送信するためのもの、セッションＡ１Ｓは音声データをサーバ装置２２に送信するためのものである。また、セッションＶ２１は第２のクライエント装置２４の画像データを受信するためのもの、セッションＡ２１は第２のクライエント装置２４の音声データを受信するためのもの、セッションＶ３１は第３のクライエント装置２５の画像データを受信するためのもの、セッションＡ３１は第３のクライエント装置２５の音声データを受信するためのものである。

これらセッションは、図１０ｂ、図１０ｃと同じようにchunkedコーディングによる連続的なデータ転送を可能としたものである。たとえば、サーバ装置２２が、第1のクライエント装置２０から、セッションＶ１Ｓ、Ａ１Ｓによって、画像データ（音声データ）を受け取ると、そのヘッダの記述により、第1のクライエント装置２０からのデータであることを知る(図１６、Ｓ２０２参照）。サーバ装置２２は、この画像データ(音声データ)を、セッションＶ１２、Ａ１２を用いて、第２のクライエント装置２４に送信する。また、セッションＶ１３、Ａ１３を用いて、第３のクライエント装置２５に送信する。この際、ヘッダ中に、第１のクライエント装置２０からのデータであることを記述しておく。したがって、受け取ったクライエント装置は、いずれのクライエントからの画像データ(音声データ)であるかを判別することができる。

サーバ装置２２には、各クライエント装置ごと、画像・音声データごとに、バッファＢ１Ｖ、Ｂ１Ａ，Ｂ２Ｖ、Ｂ２Ａ、Ｂ３Ｖ、Ｂ３Ａを有している。

図２１に、第１のクライエント装置２０の画像データのためのバッファＢ１Ｖと、サーバ装置２２の受信プロセス、送信プロセスとの関係を示す。第１のクライエント装置２２のための受信プロセスは、第１のクライエント装置２０から画像データを受信し、バッファＢ１Ｖに記録する(図１７、ステップＳ４０２、Ｓ４０４、Ｓ４０６参照）。

第２のクライエント装置２４のための送信プロセスは、バッファＢ１Ｖから画像データを読み出して、第２のクライエント装置２４に送信する(図１７、ステップＳ５０３、Ｓ５０４、Ｓ５０５参照）。

第３のクライエント装置２５のための送信プロセスは、バッファＢ１Ｖから画像データを読み出して、第３のクライエント装置２５に送信する(図１７、ステップＳ５０３、Ｓ５０４、Ｓ５０５参照）。

上記の処理は、各クライエント装置において共通である。したがって、たとえば、第１のクライエント装置２０のディスプレイ２０６には、図２２に示すように、自らのカメラで取得した動画Ｐ１、他のクライエント装置２４、２５の動画Ｐ２、Ｐ３を表示することができる。

音声データは、バッファＢ１Ａを使って同様に得ることができる。このようにしてテレビ会議システムを実現することができる。

(2)クライエント装置終了時の処理
なお、あるクライエント装置のみが終了した場合（たとえば、当該クライエント装置において終了指令が入力された場合）には、当該クライエント装置に関する処理を終了しなければならない。この処理（図１５のステップＳ１１８）を、図２３を用いて説明する。

ここでは、第１のクライエント装置２０に終了指令が入力されたものとして説明する。終了指令が入力されると、クライエント装置２０は、サーバ装置２２に対して、終了要求を制御データとして送信する。サーバ装置２２は、その受領確認を、制御データとして返送する。これを受けて、第１のクライエント装置２０は、全てのＴＣＰ／ＩＰセッションを終了する。

一方、上記終了指令を受けたサーバ装置２２は、他のクライエント装置に対して、第１のクライエント装置２０が終了した旨を制御データとして通信する。図においては、第３のクライエント装置２５は示していないが、処理内容は第２のクライエント装置２４と同様である。したがって、以下、第２のクライエント装置２４について説明を行う。

サーバ装置２２から第１のクライエント装置２０が終了した旨を受け取った第２のクライエント装置２４は、受領の確認をサーバ装置２２に返信する。さらに、第１のクライエント装置２０の画像データ・音声データを受信するためにサーバ装置２２との間で形成したセッションＶ１２、Ａ１２を終了する。

上記のようにして、あるクライエント装置が終了した場合の処理を行うことができる。

(3)通信エラー時の処理
クライエント装置から終了要求がサーバ装置に送られてきた場合には、明確に処理をすることができる。しかし、障害などが生じた場合、終了処理を行わずにクライエント装置がプログラムを強制終了した場合などには、クライエント装置から終了指令は送られて来ない。しかし、このような場合にも、当該クライエント装置に対する終了処理を行う必要がある。そこで、この実施形態では、図２４に示すような処理をサーバ装置２２が行うことによってこれに対応している。

受信プロセスは、画像データ(音声データ)をクライエント装置（ここでは、第1のクライエント装置とする）から受信する(ステップＳ４５０)。受信プロセスは、自身が有する受信チェック機能により完全な受信ができたかどうかを判断する(ステップＳ４５１)。正常であれば、画像データ(音声データ)をバッファに記録する(ステップＳ４５２)。

異常受信が報告された場合や、正常受信が所定時間内に報告されなかった場合には、さらに、所定の待機時間を経過するまでに、第1のクライエント装置２０が復帰したかどうかを判断する。通信エラーが生じただけの場合には、図１６のステップＳ２０７、Ｓ２０１以下に示すように、第１のクライエント装置２０がＴＣＰ／ＩＰの再接続を行うので、復帰してくる可能性がある。しかし、強制終了した場合や、極めて重大な通信障害が生じた場合には、第１のクライエント装置２０は、復帰しない。

そこで、サーバ装置２２は、所定の待機時間を経過しても第１のクライエント装置２０が復帰しない場合には、他のクライエント装置に対して、第１のクライエント装置２０が終了した旨を制御データにより伝える。これにより、他のクライエント装置は、図２３と同じように第１のクライエント装置２０に対する終了処理を行うことができる。

サーバ装置２２は、送信プロセスにおいても同じように、送信エラー・タイムアウトを検知し、所定の待機時間経過後も復帰しないかどうかを判断して、上記と同様の処理を行っている。

６．その他の実施形態
(1)あるクライエントからサーバ装置を介して静止画を送信することもできる。この場合、静止画データを送信した後、サーバ装置２２から他のクライエント措置に対して、画像送信のためのセッションにおいて何もデータが送出されない状態が続くことになる。クライエント装置側のルータによっては、データが送られてこない状態が続くと、セッションを終了してしまうものもある。

そこで、サーバ装置２２は、所定の時間以上送信がされない画像データ・音声データのセッションにおいて、ダミーデータを送信するようにしている。このダミーデータは、ヘッダにダミーである旨が記述されているので、受信したクライエント装置側ではこれを無視することができる。

(2)制御データのセッションを用いて、文字データのやりとりをすることができる。クライエント装置は、制御データのヘッダに自己のクライエントＩＤを記述し、ボディに文字データを含めてサーバ装置２２に送信する。サーバ装置２２は、各クライエント装置からの文字データを受けて、いずれのクライエント装置からのデータであるかが分かるようにクライエントＩＤを付して各クライエント装置に送信する。

クライエント装置では、これを受けて、他のクライエント装置の文字データをディスプレイに表示することができる。

なお、あるクライエント装置から、特定のクライエント装置に対してのみ文字データを送信したい場合には、発信元クライエントＩＤだけでなく、送信先クライエントＩＤをヘッダに付して、サーバ装置２２に送信する。サーバ装置２２は、この送信先を見て、当該クライエント装置に対してのみ文字データを送信する。

この場合、画像データ・音声データと同じように、chunkedコーディングによって連続的に送受信しても良いが、文字データの容量は小さいので、制御データと同じようにリクエスト・レスポンスの形式にて送受信することが好ましい。

(3)上記実施形態では、ＴＣＰ／ＩＰプロトコル、ＨＴＴＰプロトコルを用いている。しかし、リクエスト、レスポンス形式を採用するプロトコルであれば適用することができる。

(4)また、上記実施形態では、ＨＴＴＰプロトコルを用いているが、図２５に示すように、ＴＣＰ／ＩＰプロトコルだけでも通信を行うことができる。図では、画像データ・音声データについてのみ示しているが、制御データについても同様である。

(5)上記実施形態においては、バッファが一杯になった場合にコンテンツデータを破棄している。しかし、各コンテンツデータに送信時（あるいは生成時）のタイムスタンプを付しておき、現在時刻と比べて所定以上の差があれば、コンテンツデータを破棄するようにしても良い。

(6)また、上記実施形態では、制御データの通信においてＴＣＰ／ＩＰのセッション確立後、セッションを終了することなくＨＴＴＰのリクエストを出している。しかし、ＴＣＰ／ＩＰのバージョンによっては、このようなことができない。その場合には、ＨＴＴＰのリクエスト一回ごとに、ＴＣＰ／ＩＰのセッションを開設すればよい。

ＲＴＰプロトコルによる通信を示す図である。 ＵＤＰ／ＲＴＰプロトコルによる、ルータを介した通信を示す図である。 ＨＴＴＰプロトコルによる、ルータを介した通信を示す図である。 この発明の一実施形態による通信システムの全体構成を示す図である。 通信システムの概要を示す図である。 通信システムの機能ブロック図である。 通信システムの機能ブロック図である。 クライエント装置のハードウエア構成を示す図である。 サーバ装置のハードウエア構成を示す図である。 初期設定と制御データ受信準備のフローチャートである。 画像音声データ通信のフローチャートである。 画像音声データ通信のフローチャートである。 ＨＴＴＰリクエストのデータ形式である。 ログイン中ユーザを記録したテーブルである。 セッション対応テーブルである。 セッション対応テーブルである。 クライエント装置における処理フローチャートである。 クライエント装置における処理フローチャートである。 サーバ装置における処理フローチャとである。 ３台以上のクラエント装置を接続する場合の例である。 通信処理を示すフローチャートである。 サーバ装置と各クライエント装置との間に形成されたセッションを示す図である。 受信プロセス、送信プロセスとバッファとの関係を示す図である。 クライエント装置におけるディスプレイ表示である。 サーバ装置と各クライエント装置との間に形成されたセッションを示す図である。 サーバ装置におけるフローチャートである。 ＨＴＴＰプロトコルを用いない場合のフローチャートである。

符号の説明

２０・・・第１のクライエント装置
２２・・・サーバ装置
２４・・・第２のクライエント装置
３４・・・コンテンツ送信手段
４２・・・コンテンツデータ受信手段
４４・・・バッファ
４６・・・コンテンツデータ送信手段
５２・・・コンテンツ受信手段

Claims (23)

1. (d)サーバ装置と、当該サーバ装置と通信可能な(e)第１〜第ｎのクライエント装置とを備えた通信システムであって、
   前記第１〜第ｎのクライエント装置は、それぞれ、
   (e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
   (e2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
   (e3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
   (e4)前記コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
   (e5)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
   (e6)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
   を備えており、
   前記サーバ装置は、
   (d1)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記上りセッションを開設する手段と、
   (d2)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
   (d3)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記下りセッションを開設する手段と、
   (d4)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
   (d5)前記第１〜第ｎの各上りセッションによって、前記第１〜第ｎのクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
   (d6)前記第１〜第ｎのクライエント装置から受信した前記第１〜第ｎの所定単位ごとのコンテンツデータを記憶する第１〜第ｎのバッファと、
   (d7)前記第１〜第ｎのバッファから前記所定単位ごとの第1〜第ｎコンテンツデータを読み出して、前記各コンテンツデータを、それぞれ、前記第１〜第ｎのクライエント装置のうちの他のクライエント装置に、対応する前記第１〜第ｎの下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
   を備えたことを特徴とする通信システム。
2. 第１〜第ｎのクライエント装置とともに通信システムを構築するサーバ装置であって、
   (d1)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記上りセッションを開設する手段と、
   (d2)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
   (d3)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記下りセッションを開設する手段と、
   (d4)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
   (d5)前記第１〜第ｎの各上りセッションによって、前記第１〜第ｎのクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
   (d6)前記第１〜第ｎのクライエント装置から受信した前記第１〜第ｎの所定単位ごとのコンテンツデータを記憶する第１〜第ｎのバッファと、
   (d7)前記第１〜第ｎのバッファから前記所定単位ごとの第１〜第ｎコンテンツデータを読み出して、前記各コンテンツデータを、それぞれ、前記第１〜第ｎのクライエント装置のうちの他のクライエント装置に、対応する前記第１〜第ｎの下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
   を備えたことを特徴とするサーバ装置。
3. 第１〜第ｎのクライエント装置とともに通信システムを構築するサーバ装置をコンピュータによって実現するためのサーバプログラムであって、
   (d1)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記上りセッションを開設する手段と、
   (d2)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
   (d3)前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記下りセッションを開設する手段と、
   (d4)前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
   (d5)前記第１〜第ｎの各上りセッションによって、前記第１〜第ｎのクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
   (d6)前記第１〜第ｎのクライエント装置から受信した前記第１〜第ｎの所定単位ごとのコンテンツデータを記憶する第１〜第ｎのバッファと、
   (d7)前記第１〜第ｎのバッファから前記所定単位ごとの第１〜第ｎコンテンツデータを読み出して、前記各コンテンツデータを、それぞれ、前記第１〜第ｎのクライエント装置のうちの他のクライエント装置に、対応する前記第１〜第ｎの下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
   をコンピュータによって実現するためのサーバプログラム。
4. 請求項１〜３のいずれかのシステム、装置またはプログラムにおいて、
   前記サーバ装置は、
   (d8)受信した第１〜第ｎのコンテンツデータを記録するための第１〜第ｎバッファを備え、
   前記送信手段は、第１〜第ｎのバッファから第１〜第ｎのコンテンツデータを読み出して送信し、
   前記受信手段は、第１〜第ｎのバッファのそれぞれについて、バッファに余裕があれば、受信したコンテンツデータをバッファに記録し、バッファに余裕がなければ、受信したコンテンツデータをバッファに記録しないか、または、バッファに記録されたコンテンツデータのいずれかを削除して受信したコンテンツデータをバッファに記録する処理を行うことを特徴とするもの。
5. 請求項４のシステム、装置またはプログラムにおいて、
   前記受信手段は、バッファに所定以上のコンテンツデータが記録されればバッファに余裕がないと判断することを特徴とするもの。
6. 請求項４のシステム、装置またはプログラムにおいて、
   前記受信手段は、受信したコンテンツデータのタイムスタンプが現在時刻よりも所定時間以上の差があれば、バッファに余裕がないと判断することを特徴とするもの。
7. 請求項１〜６のいずれかのシステム、装置またはプログラムにおいて、
   前記送信手段は、所定時間以上送信すべきコンテンツデータがない場合には、ダミーデータを送信することを特徴とするもの。
8. 請求項１〜７のいずれかのシステム、装置またはプログラムにおいて、
   前記第１〜第ｎのクライエント装置のそれぞれは、
   (e7)制御データ受信のために、ＴＣＰ／ＩＰの制御下りセッション開設要求をサーバ装置に送信する手段と、
   (e8)制御下りセッションにおいて、サーバ装置からの制御データを受信すると、次の制御データ受信のために、サーバ装置に対してリクエストを送信する手段と、
   (e9)制御下りセッションにより、サーバ装置からレスポンスとして制御データを受信する手段と、
   (e10)制御データ送信のために、ＴＣＰ／ＩＰの制御上りセッション開設要求をサーバ装置に送信する手段と、
   (e11)制御上りセッションにより、リクエストとしてサーバ装置に対し制御データを送信する手段と、
   を備えたことを特徴とするもの。
9. 請求項１〜８のいずれかのシステム、装置またはプログラムにおいて、
   前記サーバ装置は、
   (d9)制御データのためのＴＣＰ／ＩＰの制御下りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、 (d10)制御下りセッションを用いて、レスポンスとして制御データを送信する手段と、
   (d11)制御データのためのＴＣＰ／ＩＰの制御上りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、 (d12)制御上りセッションにより、リクエストとして制御データを受信する手段と、
   を備えたことを特徴とするもの。
10. 請求項１〜９のいずれかのシステム、装置またはプログラムにおいて、
    前記サーバ装置は、第１〜第ｎのクライエント装置のいずれかから、制御上りセッションによって、通信を終了する旨の制御データを受け取った場合に、他のクライエント装置に対し、制御下りセッションを用いて、当該終了するクライエント装置を特定した制御データを送信することを特徴とするもの。
11. 請求項１０のシステム、装置またはプログラムにおいて、
    前記サーバ装置は、第１〜第ｎのクライエント装置のいずれかとのコンテンツデータの送信または受信に障害がある場合にも、通信を終了する旨の制御データを受け取った場合と同様の処理を行うことを特徴とするもの。
12. 請求項１０または１１のシステム、装置またはプログラムにおいて、
    前記終了するクライエント装置を特定した制御データを受信したクライエント装置は、当該終了するクライエント装置のコンテンツデータを受信するために開設していたサーバ装置との間のセッションを終了することを特徴とするもの。
13. 請求項１〜１２のいずれかのシステム、装置またはプログラムにおいて、
    前記連続的送信リクエストおよび前記連続的なコンテンツデータ受信のためのリクエストは、chunked転送コーディングによることを特徴とするもの。
14. サーバ装置とともに通信システムを構築するクライエント装置であって、
    (e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
    (e2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
    (e3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
    (e4)前記コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
    (e5)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
    (e6)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
    を備えたクライエント装置。
15. サーバ装置とともに通信システムを構築するクライエント装置をコンピュータによって実現するためのクライエントプログラムであって、
    (e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
    (e2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
    (e3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
    (e4)前記コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
    (e5)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
    (e6)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
    をコンピュータによって実現するためのクライエントプログラム。
16. 請求項１４または１５の装置またはプログラムにおいて、
    サーバ装置から、終了するクライエント装置を特定した制御データを受信すると、当該終了するクライエント装置のコンテンツデータを受信するために開設していたサーバ装置との間のセッションを終了することを特徴とするもの。
17. 請求項１４〜１６の装置またはプログラムにおいて、
    前記クライエント装置は、
    (e7)制御データ受信のために、ＴＣＰ／ＩＰの制御下りセッション開設要求をサーバ装置に送信する手段と、
    (e8)制御下りセッションにおいて、サーバ装置からの制御データを受信すると、次の制御データ受信のために、サーバ装置に対してリクエストを送信する手段と、 (e9)制御下りセッションにより、サーバ装置からレスポンスとして制御データを受信する手段と、
    (e10)制御データ送信のために、ＴＣＰ／ＩＰの制御上りセッション開設要求をサーバ装置に送信する手段と、
    (e11)制御上りセッションにより、リクエストとしてサーバ装置に対し制御データを送信する手段と、
    を備えたことを特徴とするもの。
18. サーバ装置と、当該サーバ装置と通信可能な第１〜第ｎのクライエント装置とを備えた通信方法であって、
    (e1)前記第１〜第ｎのクライエント装置は、それぞれ、コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信し、
    (d1)前記サーバ装置は、前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの前記上りセッションを開設し、
    (e4)前記第１〜第ｎのクライエント装置は、それぞれ、前記コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信し、
    (d3)前記サーバ装置は、前記第１〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの前記下りセッション開設要求を受けて、それぞれに開設許諾を送り返して、第１〜第ｎの前記下りセッションを開設し、
    (e2)前記第１〜第ｎのクライエント装置は、それぞれ、前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信し、
    (d2)前記サーバ装置は、前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信し、
    (e5)前記第１〜第ｎのクライエント装置は、それぞれ、前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にし、
    (d4)前記サーバ装置は、前記第１〜第ｎのクライエント装置から、前記第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のための受信リクエストを受信し、
    (e3)前記第１〜第ｎのクライエント装置は、それぞれ、前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信し、
    (d5)前記サーバ装置は、前記第１〜第ｎの各上りセッションによって、前記第１〜第ｎのクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信し、
    (d6)前記サーバ装置は、前記第１〜第ｎのクライエント装置から受信した前記第１〜第ｎの所定単位ごとのコンテンツデータを記憶し、
    (d7)前記サーバ装置は、前記第１〜第ｎのバッファから前記所定単位ごとの第１〜第ｎコンテンツデータを読み出して、前記各コンテンツデータを、それぞれ、前記第１〜第ｎのクライエント装置のうちの他のクライエント装置に、対応する前記第１〜第ｎの下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信し、
    (e6)前記第１〜第ｎのクライエント装置は、それぞれ、前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信することを特徴とする通信方法。
19. (a)サーバ装置と、当該サーバ装置と通信可能な(b)第１のクライエント装置および(c)第２のクライエント装置とを備えた通信システムであって、
    前記第１のクライエント装置は、
    (b1)コンテンツデータのために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
    (b2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
    (b3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
    を備えており、
    前記第２のクライエント装置は、
    (c1)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
    (c2)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
    (c3)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
    を備えており、
    前記サーバ装置は、
    (a1)第１のクライエント装置からのＴＣＰ／ＩＰの前記上りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a2)第２のクライエント装置からのＴＣＰ／ＩＰの前記下りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a3)第１のクライエント装置から、前記上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
    (a4)第２のクライエント装置から、前記下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
    (a5)前記上りセッションによって、前記第１のクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
    (a6)受信したコンテンツデータを、前記第２のクライエント装置に対し、前記下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
    を備えたことを特徴とする通信システム。
20. 第１のクライエント装置、第２のクライエント装置とともに通信システムを構築する前記サーバ装置であって、
    (a1)第１のクライエント装置からのＴＣＰ／ＩＰの前記上りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a2)第２のクライエント装置からのＴＣＰ／ＩＰの前記下りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a3)第１のクライエント装置から、前記上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
    (a4)第２のクライエント装置から、前記下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
    (a5)前記上りセッションによって、前記第１のクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
    (a6)受信したコンテンツデータを、前記第２のクライエント装置に対し、前記下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
    を備えたことを特徴とするサーバ装置。
21. 第１のクライエント装置、第２のクライエント装置とともに通信システムを構築する前記サーバ装置を、コンピュータによって実現するためのプログラムであって、
    (a1)第１のクライエント装置からのＴＣＰ／ＩＰの前記上りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a2)第２のクライエント装置からのＴＣＰ／ＩＰの前記下りセッション開設要求を受けて開設許諾を送り返す手段と、
    (a3)第１のクライエント装置から、前記上りセッションによって、ＨＴＴＰプロトコルの前記連続的送信リクエストを受信する手段と、
    (a4)第２のクライエント装置から、前記下りセッションによって、ＨＴＴＰプロトコルの前記連続的なコンテンツデータ受信のためのリクエストを受信する手段と、
    (a5)前記上りセッションによって、前記第１のクライエント装置から、ＨＴＴＰプロトコルの前記連続的送信リクエストとして送信されてくる、前記所定単位ごとのコンテンツデータを受信する手段と、
    (a6)受信したコンテンツデータを、前記第２のクライエント装置に対し、前記下りセッションを用いて、前記連続的なコンテンツデータ受信のためのリクエストに対するレスポンスとして連続的に送信する手段と、
    をコンピュータにより実現するためのサーバプログラム。
22. (b1)コンテンツデータのために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
    (b2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
    (b3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
    (c1)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
    (c2)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
    (c3)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
    を備えたクライエント装置。
23. クライエント装置をコンピュータによって実現するためのプログラムであって、
    (b1)コンテンツデータのために、ＴＣＰ／ＩＰの上りセッション開設要求を前記サーバ装置に送信する手段と、
    (b2)前記サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの連続的送信リクエストを前記サーバ装置に送信する手段と、
    (b3)前記上りセッションにおける連続的送信リクエストとして、前記コンテンツデータを所定単位ごとに前記サーバ装置に対し送信する手段と、
    (c1)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求を前記サーバ装置に送信する手段と、
    (c2)前記サーバ装置からのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの連続的なコンテンツデータ受信のためのリクエストを前記サーバ装置に予め送信することにより、前記サーバ装置からの連続的なレスポンスを受信可能にする手段と、
    (c3)前記下りセッションにおける連続的なコンテンツデータ受信のためのリクエストに対する連続的なレスポンスとして、前記サーバ装置からの前記所定単位ごとのコンテンツデータを受信する手段と、
    をコンピュータによって実現するためのクライエントプログラム。

Images