(57)【要約】    【課題】  ＴＣＰ／ＩＰプロトコルを用いることによってセキュリティを確保しつつ、リアルタイム性のある通信を実現した通信技術を得る。    【解決手段】  第１のクライエント装置２０および第２のクライエント装置２４とサーバ装置２との間で、ＴＣＰ／ＩＰのセッションが開設される。セッションが確立すると、第２のクライエント２４は、データを受信するためのＨＴＴＰ（Ｓ）データ受信リクエストを、サーバ装置２２に送信する。同様にして、第１のクライエント装置２０の送信リクエスト手段３２は、データを送信するためのＨＴＴＰ（Ｓ）データ送信リクエストを、サーバ装置２２に送信する。サーバ装置２２は、第1のクライエント装置２０から、ＨＴＴＰ（Ｓ）リクエストによって、所定単位に分割した画像・音声を受信する。さらに、これを、ＨＴＴＰ（Ｓ）のレスポンスとして、第2のクライエント装置２４に転送する。【選択図】  図７
2007150666.tif 000002
【特許請求の範囲】
【請求項１】
(d)サーバ装置と、当該サーバ装置と通信可能な(e)第１〜第ｎのクライエント装置とを備えた通信システムであって、
前記第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(e3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求をサーバ装置に送信する手段と、
(e5)サーバからのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(e6)サーバ装置からのコンテンツデータを受信する手段と、
を備えており、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
を備えたことを特徴とする通信システム。
【請求項２】
第１〜第ｎのクライエント装置とともに通信システムを構築するサーバ装置であって、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
を備えたことを特徴とするサーバ装置。
【請求項３】
第１〜第ｎのクライエント装置とともに通信システムを構築するサーバ装置をコンピュータによって実現するためのサーバプログラムであって、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
をコンピュータによって実現するためのサーバプログラム。
【請求項４】
請求項１〜３のいずれかのシステム、装置またはプログラムにおいて、
前記サーバ装置は、
(d8)受信した第1〜第ｎのコンテンツデータを記録するための第１〜第ｎバッファを備え、
前記送信手段は、第１〜第ｎのバッファから第１〜第ｎのコンテンツデータを読み出して送信し、
前記受信手段は、第１〜第ｎのバッファのそれぞれについて、バッファに余裕があれば、受信したコンテンツデータをバッファに記録し、バッファに余裕がなければ、受信したコンテンツデータをバッファに記録しないか、または、バッファに記録されたコンテンツデータのいずれかを削除して受信したコンテンツデータをバッファに記録する処理を行うことを特徴とするもの。
【請求項５】
請求項４のシステム、装置またはプログラムにおいて、
前記受信手段は、バッファに所定以上のコンテンツデータが記録されればバッファに余裕がないと判断することを特徴とするもの。
【請求項６】
請求項４のシステム、装置またはプログラムにおいて、
前記受信手段は、受信したコンテンツデータのタイムスタンプが現在時刻よりも所定時間以上の差があれば、バッファに余裕がないと判断することを特徴とするもの。
【請求項７】
請求項１〜６のいずれかのシステム、装置またはプログラムにおいて、
前記送信手段は、所定時間以上送信すべきコンテンツデータがない場合には、ダミーデータを送信することを特徴とするもの。
【請求項８】
請求項１〜７のいずれかのシステム、装置またはプログラムにおいて、
前記第1〜第ｎのクライエント装置のそれぞれは、
(e7)制御データ受信のために、ＴＣＰ／ＩＰの制御下りセッション開設要求をサーバ装置に送信する手段と、
(e8)開設されたセッションにおいて、制御データ受信のために、リクエストを送信する手段と、
(e9)制御下りセッションにより、サーバ装置からレスポンスとして制御データを受信する手段と、
(e10)制御データ送信のために、ＴＣＰ／ＩＰの制御上りセッション開設要求をサーバ装置に送信する手段と、
(e11)制御上りセッションにより、リクエストとしてサーバ装置に対し制御データを送信する手段と、
を備えたことを特徴とするもの。
【請求項９】
請求項１〜８のいずれかのシステム、装置またはプログラムにおいて、
前記サーバ装置は、
(d9)制御データのためのＴＣＰ／ＩＰの制御下りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、  (d10)制御下りセッションを用いて、レスポンスとして制御データを送信する手段と、
(d11)制御データのためのＴＣＰ／ＩＰの制御上りセッション開設要求を第１〜第ｎのクライエント装置から受けて、セッション開設許諾を送信する手段と、  (d12)制御上りセッションにより、リクエストとして制御データを受信する手段と、
を備えたことを特徴とするもの。
【請求項１０】
請求項１〜９のいずれかのシステム、装置またはプログラムにおいて、
前記サーバ装置は、第１〜第ｎのクライエント装置のいずれかから、制御上りセッションによって、通信を終了する旨の制御データを受け取った場合に、他のクライエント装置に対し、制御下りセッションを用いて、当該終了するクライエント装置を特定した制御データを送信することを特徴とするもの。
【請求項１１】
請求項１０のシステム、装置またはプログラムにおいて、
前記サーバ装置は、第1〜第ｎのクライエント装置のいずれかとのコンテンツデータの送信または受信に障害がある場合にも、通信を終了する旨の制御データを受け取った場合と同様の処理を行うことを特徴とするもの。
【請求項１２】
請求項１０または１１のシステム、装置またはプログラムにおいて、
前記終了するクライエント装置を特定した制御データを受信したクライエント装置は、当該終了するクライエント装置のコンテンツデータを受信するために開設していたサーバ装置との間のセッションを終了することを特徴とするもの。
【請求項１３】
請求項１〜１２の通信システムにおいて、
前記クライエント装置の各機能の一部または全部は、クライエント装置がサーバ装置に接続した際に、サーバ装置からダウンロードされるクライエントプログラムによって実現されることを特徴とするもの。
【請求項１４】
サーバ装置とともに通信システムを構築するクライエント装置であって、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(e3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e5)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(e6)サーバ装置からのコンテンツデータを受信する手段と、
を備えたクライエント装置。
【請求項１５】
サーバ装置とともに通信システムを構築するクライエント装置をコンピュータによって実現するためのクライエントプログラムであって、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(e3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e5)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(e6)サーバ装置からのコンテンツデータを受信する手段と、
をコンピュータによって実現するためのクライエントプログラム。
【請求項１６】
請求項１４または１５の装置またはプログラムにおいて、
サーバ装置から、終了するクライエント装置を特定した制御データを受信すると、当該終了するクライエント装置のコンテンツデータを受信するために開設していたサーバ装置との間のセッションを終了することを特徴とするもの。
【請求項１７】
請求項１４〜１６の装置またはプログラムにおいて、
前記クライエント装置は、
(e7)制御データ受信のために、ＴＣＰ／ＩＰの制御下りセッション開設要求をサーバ装置に送信する手段と、
(e8)開設されたセッションにおいて、制御データ受信のために、リクエストを送信する手段と、
(e9)制御下りセッションにより、サーバ装置からレスポンスとして制御データを受信する手段と、
(e10)制御データ送信のために、ＴＣＰ／ＩＰの制御上りセッション開設要求をサーバ装置に送信する手段と、
(e11)制御上りセッションにより、リクエストとしてサーバ装置に対し制御データを送信する手段と、
を備えたことを特徴とするもの。
【請求項１８】
サーバ装置と、当該サーバ装置と通信可能な第１〜第ｎのクライエント装置とを備えた通信方法であって、
前記第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰの上りセッション開設要求をサーバ装置に送信し、
(e2)サーバ装置からのＴＣＰ／ＩＰの上りセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信し、
(e3)コンテンツデータを所定単位ごとにサーバ装置に送信し、
(e4)コンテンツデータ受信のために、ＴＣＰ／ＩＰの下りセッション開設要求をサーバ装置に送信し、
(e5)サーバからのＴＣＰ／ＩＰの下りセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信し、
(e6)サーバ装置からのコンテンツデータを受信し、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設し、
(d2)第1〜第ｎのクライエント装置から、第１〜第ｎの各上りセッションによって、ＨＴＴＰプロトコルの連続的送信リクエストを受信し、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設し、
(d4)第1〜第ｎのクライエント装置から、第１〜第ｎの各下りセッションによって、ＨＴＴＰプロトコルの連続的受信リクエストを受信し、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信し、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを第１〜第ｎのバッファに記憶し、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信することを特徴とする通信方法。
【請求項１９】
(a)サーバ装置と、当該サーバ装置と通信可能な(b)第１のクライエント装置および(c)第２のクライエント装置とを備えた通信システムであって、
前記第１のクライエント装置は、
(b1)コンテンツデータのために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(b2)サーバ装置からのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(b3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
を備えており、
前記第２のクライエント装置は、
(c1)コンテンツデータのために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(c2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(c3)サーバ装置からのコンテンツデータを受信する手段と、
を備えており、
前記サーバ装置は、
(a1)第1のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a2)第２のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a3)第1のクライエント装置からのＨＴＴＰプロトコルの送信リクエストを受信する手段と、
(a4)第２のクライエント装置からのＨＴＴＰプロトコルの受信リクエストを受信する手段と、
(a5)前記送信リクエストを受けた後に、第1のクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(a6)受信したコンテンツデータを、前記受信リクエストを送信してきた第2のクライエント装置に送信する手段と、
を備えたことを特徴とする通信システム。
【請求項２０】
第１のクライエント装置、第２のクライエント装置とともに通信システムを構築する前記サーバ装置であって、
(a1)第1のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a2)第２のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a3)第1のクライエント装置からのＨＴＴＰプロトコルの送信リクエストを受信する手段と、
(a4)第２のクライエント装置からのＨＴＴＰプロトコルの受信リクエストを受信する手段と、
(a5)前記送信リクエストを受けた後に、第1のクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(a6)受信したコンテンツデータを、前記受信リクエストを送信してきた第2のクライエント装置に送信する手段と、
を備えたことを特徴とするサーバ装置。
【請求項２１】
第１のクライエント装置、第２のクライエント装置とともに通信システムを構築する前記サーバ装置を、コンピュータによって実現するためのプログラムであって、
(a1)第1のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a2)第２のクライエント装置からのＴＣＰ／ＩＰのセッション開設要求を受けて開設許諾を送り返す手段と、
(a3)第1のクライエント装置からのＨＴＴＰプロトコルの送信リクエストを受信する手段と、
(a4)第２のクライエント装置からのＨＴＴＰプロトコルの受信リクエストを受信する手段と、
(a5)前記送信リクエストを受けた後に、第1のクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(a6)受信したコンテンツデータを、前記受信リクエストを送信してきた第2のクライエント装置に送信する手段と、
をコンピュータにより実現するためのサーバプログラム。
【請求項２２】
(b1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(b2)サーバ装置からのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(b3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(c1)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(c2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(c3)サーバ装置からのコンテンツデータを受信する手段と、
を備えたクライエント装置。
【請求項２３】
クライエント装置をコンピュータによって実現するためのプログラムであって、
(b1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(b2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、送信データサイズを不明とするＨＴＴＰプロトコルの送信リクエストをサーバ装置に送信する手段と、
(b3)コンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(c1)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(c2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、受信データサイズを不明とするＨＴＴＰプロトコルの受信リクエストをサーバ装置に送信する手段と、
(c3)サーバ装置からのコンテンツデータを受信する手段と、
をコンピュータによって実現するためのクライエントプログラム。
【請求項２４】
(d)サーバ装置と、当該サーバ装置と通信可能な(e)第１〜第ｎのクライエント装置とを備えた通信システムであって、
前記第１〜第ｎのクライエント装置は、それぞれ、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってコンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e3)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e4)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってサーバ装置からのコンテンツデータを受信する手段と、
を備えており、
前記サーバ装置は、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
を備えたことを特徴とする通信システム。
【請求項２５】
クライエント装置とともに通信システムを構築するサーバ装置であって、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
を備えたサーバ装置。
【請求項２６】
クライエント装置とともに通信システムを構築するサーバ装置をコンピュータによって実現するためのサーバプログラムであって、
(d1)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの上りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの上りセッションを開設する手段と、
(d3)第1〜第ｎのクライエント装置から、それぞれＴＣＰ／ＩＰの下りセッション開設要求を受けて、それぞれに開設許諾を送り返し、第１〜第ｎの下りセッションを開設する手段と、
(d5)第１〜第ｎの各上りセッションによって、第1〜第ｎのクライエント装置から送信されてくるコンテンツデータを受信する手段と、
(d6)第１〜第ｎのクライエント装置から受信した第１〜第ｎのコンテンツデータを記憶する第１〜第ｎのバッファと、
(d7)第1〜第ｎのバッファから第1〜第ｎコンテンツデータを読み出して、各コンテンツデータを、それぞれ、第１〜第ｎのクライエント装置のうちの他のクライエント装置に、第1〜第ｎの下りセッションを用いて連続的に送信する手段と、
をコンピュータによって実現するためのサーバプログラム。
【請求項２７】
サーバ装置とともに通信システムを構築するクライエント装置であって、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってコンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e3)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e4)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってサーバ装置からのコンテンツデータを受信する手段と、
を備えたクライエント装置。
【請求項２８】
サーバ装置とともに通信システムを構築するクライエント装置をコンピュータによって実現するためのクライエントプログラムであって、
(e1)コンテンツデータ送信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e2)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってコンテンツデータを所定単位ごとにサーバ装置に送信する手段と、
(e3)コンテンツデータ受信のために、ＴＣＰ／ＩＰのセッション開設要求をサーバ装置に送信する手段と、
(e4)サーバからのＴＣＰ／ＩＰのセッション開設許諾を受けて、当該セッションによってサーバ装置からのコンテンツデータを受信する手段と、
をコンピュータによって実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は通信システムに関し、特にＴＣＰ／ＩＰプロトコルをベースとしつつ、クライエントから他のクライエントへコンテンツデータを連続的に通信することを可能とする技術に関するものである。
【背景技術】
【０００２】
テレビ会議やテレビ電話のシステムにおいて、専用線に代えて、インターネットを使用することが行われている。この際一般には、ＵＤＰプロトコルやＲＴＰプロトコル(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)また、上記実施形態では、制御データの通信においてＴＣＰ／ＩＰのセッション確立後、セッションを終了することなくＨＴＴＰのリクエストを出している。しかし、ＴＣＰ／ＩＰのバージョンによっては、このようなことができない。その場合には、ＨＴＴＰのリクエスト一回ごとに、ＴＣＰ／ＩＰのセッションを開設すればよい。
【図面の簡単な説明】
【０１９８】
【図１】ＲＴＰプロトコルによる通信を示す図である。
【図２】ＵＤＰ／ＲＴＰプロトコルによる、ルータを介した通信を示す図である。
【図３】ＨＴＴＰプロトコルによる、ルータを介した通信を示す図である。
【図４】この発明の一実施形態による通信システムの全体構成を示す図である。
【図５】通信システムの概要を示す図である。
【図６】通信システムの機能ブロック図である。
【図７】通信システムの機能ブロック図である。
【図８】クライエント装置のハードウエア構成を示す図である。
【図９】サーバ装置のハードウエア構成を示す図である。
【図１０ａ】初期設定と制御データ受信準備のフローチャートである。
【図１０ｂ】画像音声データ通信のフローチャートである。
【図１０ｃ】画像音声データ通信のフローチャートである。
【図１１】ＨＴＴＰリクエストのデータ形式である。
【図１２】ログイン中ユーザを記録したテーブルである。
【図１３】セッション対応テーブルである。
【図１４】セッション対応テーブルである。
【図１５】クライエント装置における処理フローチャートである。
【図１６】クライエント装置における処理フローチャートである。
【図１７】サーバ装置における処理フローチャとである。
【図１８】３台以上のクラエント装置を接続する場合の例である。
【図１９】通信処理を示すフローチャートである。
【図２０】サーバ装置と各クライエント装置との間に形成されたセッションを示す図である。
【図２１】受信プロセス、送信プロセスとバッファとの関係を示す図である。
【図２２】クライエント装置におけるディスプレイ表示である。
【図２３】サーバ装置と各クライエント装置との間に形成されたセッションを示す図である。
【図２４】サーバ装置におけるフローチャートである。
【図２５】ＨＴＴＰプロトコルを用いない場合のフローチャートである。
【符号の説明】
【０１９９】
２０・・・第１のクライエント装置
２２・・・サーバ装置
２４・・・第２のクライエント装置
３４・・・コンテンツ送信手段
４２・・・コンテンツデータ受信手段
４４・・・バッファ
４６・・・コンテンツデータ送信手段
５２・・・コンテンツ受信手段
【図１】
2007150666.tif 000003
【図２】
2007150666.tif 000004
【図３】
2007150666.tif 000005
【図４】
2007150666.tif 000006
【図５】
2007150666.tif 000007
【図６】
2007150666.tif 000008
【図７】
2007150666.tif 000009
【図８】
2007150666.tif 000010
【図９】
2007150666.tif 000011
【図１０ａ】
2007150666.tif 000012
【図１０ｂ】
2007150666.tif 000013
【図１０ｃ】
2007150666.tif 000014
【図１１】
2007150666.tif 000015
【図１２】
2007150666.tif 000016
【図１３】
2007150666.tif 000017
【図１４】
2007150666.tif 000018
【図１５】
2007150666.tif 000019
【図１６】
2007150666.tif 000020
【図１７】
2007150666.tif 000021
【図１８】
2007150666.tif 000022
【図１９】
2007150666.tif 000023
【図２０】
2007150666.tif 000024
【図２１】
2007150666.tif 000025
【図２２】
2007150666.tif 000026
【図２３】
2007150666.tif 000027
【図２４】
2007150666.tif 000028
【図２５】
2007150666.tif 000029