(57)【要約】データ通信システム（１０）は、通信ネットワーク構成（６０）を介して複数のクライアントデバイス（３０）に連結された集中サーバ構成（２０）を含む。集中サーバ構成及びクライアントデバイスは、それらの間でデータを交換するように動作可能である。更に上記システムは、上記データを一次種類のデータ及び少なくとも二次種類のデータに割り振るように動作可能であり、上記一次種類のデータは、システム内で実質的に即座に伝達され、上記二次種類のデータは、クライアントデバイスにおける二次種類のデータの受信に応じてシステム内で伝達される確認応答に関連して、システム内で伝達される。上記サーバ構成が、バーチャルルーム、マルチポイントサーバ、マルチプレーヤサーバのようなサービスをホストするように動作可能であることにより、上記システム（１０）は、ビデオ会議サービス、ビデオ放送サービス、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスのうちの少なくとも１つを、クライアントデバイスを用いる当事者に提供するように動作可能である。【選択図】図１
2016527579.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク構成（６０）を介して複数のクライアントデバイス（３０）に連結された集中サーバ構成（２０）を含むデータ通信システム（１０）であって、前記集中サーバ構成（２０）及び前記クライアントデバイス（３０）は、それらの間でデータを交換するように動作可能であり、前記システム（１０）は、前記データを一次種類のデータ及び少なくとも二次種類のデータに割り振るように動作可能であり、前記一次種類のデータは、前記システム（１０）内で実質的に即座に伝達され、かつ少なくとも前記二次種類のデータは、前記クライアントデバイス（３０）のうちの１又は複数における前記二次種類のデータの受信に応じて前記システム（１０）内で伝達される対応確認応答（ＡＣＫ）に関連して、前記システム（１０）内で伝達される、データ通信システム（１０）。
【請求項２】
前記一次種類のデータはオーディオデータを含み、かつ前記二次種類のデータは画像データ及び／若しくはビデオデータ並びに／又は任意の他のデータを含む、請求項１に記載のデータ通信システム（１０）。
【請求項３】
前記クライアントデバイス（３０）は、少なくとも最初に、前記集中サーバ構成（２０）における同じ所定のＴＣＰ／ＵＤＰポートを介して接続され、その接続様式は、関与する全ての前記クライアントデバイス（３０）に対して接続セッションを作成する、請求項１に記載のデータ通信システム（１０）。
【請求項４】
前記通信ネットワーク構成（６０）の通信特性及び／又は前記クライアントデバイス（３０）のうちの１又は複数の通信特性を決定し、かつ前記決定された通信特性に応じて、前記１又は複数のクライアントデバイス（３０）へのデータパケット通信の１又は複数のレートを調整するように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項５】
前記通信ネットワーク構成（６０）の通信特性及び／又は前記クライアントデバイス（３０）のうちの１又は複数の通信特性を決定し、かつ前記決定された通信特性に応じて、前記１又は複数のクライアントデバイス（３０）へのデータパケット通信の最大セグメントサイズ（ＭＳＳ）を調整するように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項６】
前記１又は複数のクライアントデバイス（３０）のうちの少なくとも１つが、無線対応モバイル通信デバイス、無線接続パーソナルコンピュータ（ＰＣ）のうちの少なくとも１つである、請求項１に記載のデータ通信システム（１０）。
【請求項７】
少なくとも三次のデータを非タイムクリティカルな様式で前記クライアントデバイス（３０）間で伝達するように動作可能であり、前記少なくとも三次のデータはドキュメントに対応する、請求項１に記載のデータ通信システム（１０）。
【請求項８】
前記集中サーバ構成（２０）に伝達された前記一次種類のデータが、該集中サーバ構成（２０）から実質的に即座に、参加しているクライアントデバイス（３０）に再送信される様式で通信するように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項９】
前記一次種類のデータを最も高い優先度として伝達し、引き続いて前記二次データをより低い優先度として伝達するように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項１０】
前記クライアントデバイス（３０）に伝達するときに、一時的に、前記二次種類のデータを前記一次種類のデータよりも優先させるように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項１１】
前記通信ネットワーク構成（６０）は、少なくとも部分的に、ピアツーピア通信ネットワークとして実装される、請求項１に記載のデータ通信システム（１０）。
【請求項１２】
前記通信ネットワーク構成（６０）は、少なくとも部分的に、１又は複数のピアツーピアスタートポロジネットワークとして実装され、前記１又は複数のピアツーピアスタートポロジネットワークは、２つ以上の相互に通信するクライアントデバイス（３０）間で該１又は複数のピアツーピアスタートポロジネットワークを通じてデータを伝達するように動作可能である、請求項１１に記載のデータ通信システム（１０）。
【請求項１３】
前記１又は複数のピアツーピアスタートポロジネットワークは、前記集中サーバ構成（２０）を介したデータ通信を低減又は迂回するように動作可能である、請求項１２に記載のデータ通信システム（１０）。
【請求項１４】
前記通信ネットワーク構成（６０）は、少なくとも部分的に、１又は複数のピアツーピア通信リングとして実装され、前記１又は複数のピアツーピア通信リングは、２つ以上の相互に通信するクライアントデバイス（３０）間で該１又は複数のピアツーピア通信リングを通じてデータを伝達するように動作可能である、請求項１１に記載のデータ通信システム（１０）。
【請求項１５】
前記１又は複数のピアツーピア通信リングは、前記集中サーバ構成（２０）を介したデータ通信を低減又は迂回するように動作可能である、請求項１４に記載のデータ通信システム（１０）。
【請求項１６】
前記２つ以上の相互に通信するクライアントデバイス（３０）は、リングトポロジ及び／又はスタートポロジを用いる、構造化されたオーバレイネットワークを介して通信するように動作可能である、請求項１２又は１４に記載のデータ通信システム（１０）。
【請求項１７】
前記通信ネットワーク構成（６０）は、少なくとも部分的に、ＴＣＰ／ＩＰ及び／又はＵＤＰ／ＩＰを実装するインターネットを介して実装される、請求項１に記載のデータ通信システム（１０）。
【請求項１８】
前記データサーバ構成（２０）が、１又は複数のサービス、例えばバーチャルルーム、マルチポイントサーバ及び／又はマルチプレーヤサーバをホストするように動作可能であることにより、前記システム（１０）が、ビデオ会議サービス、ビデオ放送サービス、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスのうちの少なくとも１つを、前記クライアントデバイス（３０）を用いる当事者に提供するように動作可能である、請求項１に記載のデータ通信システム（１０）。
【請求項１９】
通信ネットワーク構成（６０）を介して複数のクライアントデバイス（３０）に連結された集中サーバ構成（２０）を含むデータ通信システム（１０）においてデータを伝達する方法であって、
（ａ）    前記集中サーバ構成（２０）及び前記クライアントデバイス（３０）を、それらの間でデータを交換するように動作させること、但し、前記システム（１０）は、前記データを一次種類のデータ及び少なくとも二次種類のデータに割り振るように動作可能であるものとする、並びに
（ｂ）    前記一次種類のデータを実質的に即座に前記システム（１０）内で伝達し、かつ少なくとも前記二次種類のデータを、前記クライアントデバイス（３０）のうちの１又は複数における前記二次種類のデータの受信に応じて前記システム（１０）内で伝達される対応確認応答（ＡＣＫ）に関連して、前記システム（１０）内で伝達すること、
を含む、方法。
【請求項２０】
前記一次種類のデータがオーディオデータを含むように、かつ前記二次種類のデータが画像データ及び／若しくはビデオデータ並びに／又は任意の他のデータを含むように準備することを含む、請求項１９に記載の方法。
【請求項２１】
請求項１９に記載の方法であって、
該方法は、最初に前記クライアントデバイス（３０）を、前記集中サーバ構成（２０）における同じ所定のＴＣＰ／ＵＤＰポートを介して接続することを含み、その接続様式は、関与する全ての前記クライアントデバイス（３０）に対して接続セッションを作成する、方法。
【請求項２２】
前記通信ネットワーク構成（６０）の通信特性及び／又は前記クライアントデバイス（３０）のうちの１又は複数の通信特性を決定し、かつ前記決定された通信特性に応じて、前記１又は複数のクライアントデバイス（３０）へのデータパケット通信の１又は複数のレートを調整するように、前記システム（１０）を動作させることを含む、請求項１９に記載の方法。
【請求項２３】
前記通信ネットワーク構成（６０）の通信特性及び／又は前記クライアントデバイス（３０）のうちの１又は複数の通信特性を決定し、かつ前記決定された通信特性に応じて、前記１又は複数のクライアントデバイス（３０）へのデータパケット通信の最大セグメントサイズ（ＭＳＳ）を調整するように、前記システム（１０）を動作させることを含む、請求項１９に記載の方法。
【請求項２４】
前記１又は複数のクライアントデバイス（３０）のうちの少なくとも１つが、無線対応モバイル通信デバイス、無線接続パーソナルコンピュータ（ＰＣ）のうちの少なくとも１つである、請求項１９に記載の方法。
【請求項２５】
請求項１９に記載の方法であって、
該方法は、少なくとも三次のデータを非タイムクリティカルな様式で前記クライアントデバイス（３０）間で伝達するように、前記システム（１０）を動作させることを含み、前記少なくとも三次のデータはドキュメントに対応する、方法。
【請求項２６】
前記集中サーバ構成（２０）に伝達された前記一次種類のデータが、該集中サーバ構成（２０）から実質的に即座に、参加しているクライアントデバイス（３０）に再送信される様式で、前記システム（１０）を動作させることを含む、請求項１９に記載の方法。
【請求項２７】
前記一次種類のデータを最も高い優先度として伝達し、引き続いて前記二次データをより低い優先度として伝達するように、前記システム（１０）を動作させることを含む、請求項１９に記載の方法。
【請求項２８】
前記クライアントデバイス（３０）に伝達するときに、一時的に、前記二次種類のデータを前記一次種類のデータよりも優先させるように、前記システム（１０）を動作させることを含む、請求項１９に記載の方法。
【請求項２９】
前記通信ネットワーク構成（６０）を、少なくとも部分的に、ピアツーピア通信ネットワークとして実装することを含む、請求項１９に記載の方法。
【請求項３０】
請求項２９に記載の方法であって、
該方法は、前記通信ネットワーク構成（６０）を、少なくとも部分的に、１又は複数のピアツーピアスタートポロジネットワークとして実装することを含み、
前記１又は複数のピアツーピアスタートポロジネットワークは、２つ以上の相互に通信するクライアントデバイス（３０）間で該１又は複数のピアツーピアスタートポロジネットワークを通じてデータを伝達するように動作可能である、
方法。
【請求項３１】
前記集中サーバ構成（２０）を介したデータ通信を低減又は迂回するように、前記１又は複数のピアツーピアスタートポロジネットワークを動作させることを含む、請求項３０に記載の方法。
【請求項３２】
請求項２９に記載の方法であって、
該方法は、前記通信ネットワーク構成（６０）を、少なくとも部分的に、１又は複数のピアツーピア通信リングとして実装することを含み、
前記１又は複数のピアツーピア通信リングは、２つ以上の相互に通信するクライアントデバイス（３０）間で該１又は複数のピアツーピア通信リングを通じてデータを伝達するように動作可能である、
方法。
【請求項３３】
前記集中サーバ構成（２０）を介したデータ通信を低減又は迂回するように、前記１又は複数のピアツーピア通信リングを動作させることを含む、請求項３２に記載の方法。
【請求項３４】
前記２つ以上の相互に通信するクライアントデバイス（３０）を、リングトポロジ及び／又はスタートポロジを用いる、構造化されたオーバレイネットワークを介して通信するように動作させることを含む、請求項３０又は３２に記載の方法。
【請求項３５】
前記通信ネットワーク構成（６０）を、少なくとも部分的に、ＴＣＰ／ＩＰ及び／又はＵＤＰ／ＩＰを実装するインターネットを介して実装することを含む、請求項１９に記載の方法。
【請求項３６】
請求項１９に記載の方法であって、
該方法が、前記データサーバ構成（２０）を、１又は複数のサービス、例えばバーチャルルーム、マルチポイントサーバ及び／又はマルチプレーヤサーバをホストするように動作させることを含むことにより、前記システム（１０）が、ビデオ会議サービス、ビデオ放送サービス、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスのうちの少なくとも１つを、前記クライアントデバイス（３０）を用いる当事者に提供するように動作可能である、方法。
【請求項３７】
非一時的機械可読データ記憶媒体上に記録されたソフトウェア製品であって、該ソフトウェア製品は、請求項１９に記載の方法を実施するためにコンピュータハードウェア（ＣＰＵ２１０）上で実行可能である、ソフトウェア製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、データ通信システム、例えば、オーディオ情報及びビデオ情報を相互に異なるクライアントデバイス間で伝達するデータ通信システムに関する。本願に開示される事項は、ピアツーピア通信システム及びマルチポイント通信システムと共に用いることができるだけでなく、ユニキャスト、マルチキャスト及びマルチユニキャスト（ＸＣＡＳＴ）ルーティングスキームにも好適である。更に本願は、上記データ通信システムを動作させる方法にも関する。更に本願は、非一時的（不揮発性）機械可読データ記憶媒体上に記録されたソフトウェアにも関し、上記ソフトウェアは、上述の方法を実施するためにコンピュータハードウェア上で実行可能である。
【背景】
【０００２】
データ通信ネットワーク、例えばインターネットを介したデータパケット通信を利用する通信システムがよく知られている。例えば、ボイスオーバーインターネットプロトコル（Ｖｏｉｃｅ−ｏｖｅｒ−Ｉｎｔｅｒｎｅｔ−Ｐｒｏｔｏｃｏｌ；ＶｏＩＰ）は長年にわたって知られており、Ｓｋｙｐｅ（スカイプ）電話及びビデオ会議サービスなどの現代の通信製品において利用されている（「Ｓｋｙｐｅ」は登録商標である）。複数の人がＶｏＩＰ及び関連するビデオ会議製品を利用するとき、ボイス情報及びビデオ情報は、著しく遅延することなく伝達されることが望ましいと認められ、さもなければ、会話又はビデオによる会議を維持することは、参加者にとって困難となる。ただし、インターネットは、データパケット通信ネットワークとなるように着想されたものであり、インターネット内では、データパケットが送信デバイスから受信デバイスへの多数の経路を利用する可能性がある。その結果、インターネットを用いて送信デバイスから受信デバイスへとデータパケットを即座に配信することはしばしば困難となり、ユーザが待ち時間を経験する可能性がある。上述の通信に関する問題は、既知の文書「リアルタイム  メッセージング  プロトコル（ＲＴＭＰ）スペシフィケーション、アドビ  ディベロパー  コネクション（Ｒｅａｌ−Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ （ＲＴＭＰ） ｓｐｅｃｉｆｉｃａｔｉｏｎ， Ａｄｏｂｅ Ｄｅｖｅｌｏｐｅｒ Ｃｏｎｎｅｃｔｉｏｎ）」において取り上げられている。
ＵＲＬ：http://www.adobe.com/devnet/rtmp.html
【０００３】
インターネットなどの通信ネットワークを利用する、既知のリアルタイム通信システム及びそれらの関連方法において遭遇する課題は、上記方法が、それらの実行にビデオコーデック及びオーディオコーデックを適切に組み込んでいないことである。そのようなコーデックを含むデバイスの処理能力は相互に異なることが多く、この処理能力は、受信したデータの処理速度、及び送信するデータの生成速度にも影響を与える。更に、インターネットなどを実装するために利用されるインフラストラクチャは、様々な個々のクライアントデバイスによって大きく異なる場合があり、例えば個々のクライアントデバイスの地理的位置によって異なる。複数の当事者間でオーディオ会議及び／又はビデオ会議を実行する場合、文の末尾の単語に対して数秒のオーディオ遅延が発生しただけでも、会議に参加している当事者に対して、その文を不鮮明な状態にしてしまう可能性がある。
【０００４】
このため、既知のリアルタイム通信システムは、データパケットの搬送に利用される通信インフラストラクチャ、例えば通信ネットワークの特性を考慮する必要があり、このようなインフラストラクチャは、様々な個々のクライアントデバイスによって大きく異なり得る。例えば、クライアントデバイス間などの当事者間で送信されるオーディオ情報は、数１０ミリ秒未満の遅延で搬送されることが望ましい。通常、そのような数１０ミリ秒の遅延は、ビデオ情報が同時に送信されない場合には達成され得る。所与の期間に関連するオーディオ情報と比較すると、同じ所与の期間に関連する、対応するビデオ情報に対して生成されるデータは、オーディオ情報のものと比較して、典型的にはサイズが少なくとも１０倍大きくなる。ただし、サイズにける対応するビデオデータに対するオーディオデータの比率は、ビデオ情報及びオーディオ情報に関連する品質基準、例えばビデオの画素フィールド解像度及びビデオのフレーム更新レートによって決まる。
【０００５】
上記のことから、例えばビデオ会議の状況において、複数の当事者間でインターネットなどの通信ネットワークを介してオーディオ情報及びビデオ情報を伝達する既知のシステムは、特に当事者が、相互に異なる関連データ処理特性を有する、相互に異なるデバイスを利用する場合、動作様式において最適ではないことを理解されたい。
【０００６】
以下の先行文献には、優先度に基づく信号送信に関する既知の技術の例が記載されている。
（ａ）    米国特許第ＵＳ５５７４９３４号（「プリエンプティブ  プライオリティベースド  トランスミッション  オブ  シグナルズ  ユージング  バーチャル  チャネルズ（Ｐｒｅ−ｅｍｐｔｉｖｅ ｐｒｉｏｒｉｔｙ−ｂａｓｅｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｏｆ ｓｉｇｎａｌｓ ｕｓｉｎｇ ｖｉｒｔｕａｌ ｃｈａｎｎｅｌｓ）」）、ミラシュラフィ（Ｍｉｒａｓｈｒａｆｉ）
（ｂ）    米国特許第ＵＳ８１２１１１７号（「アプリケーション  レイヤ  ネットワーク  トラフィック  プライオリタイゼーション（Ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｎｅｔｗｏｒｋ ｔｒａｆｆｉｃ ｐｒｉｏｒｉｔｉｚａｔｉｏｎ）」）、アムダール（Ａｍｄａｈｌ）
（ｃ）    欧州特許出願第ＥＰ２４０８２０５ Ａ１号（「ア  ビデオ  サーバ、ビデオ  クライアント  アンド  メソッド  オブ  スケーラブル  エンコーディング  ビデオ  ファイルズ（Ａ ｖｉｄｅｏ ｓｅｒｖｅｒ， ｖｉｄｅｏ ｃｌｉｅｎｔ ａｎｄ ｍｅｔｈｏｄ ｏｆ ｓｃａｌａｂｌｅ ｅｎｃｏｄｉｎｇ ｖｉｄｅｏ ｆｉｌｅｓ）」）、アルカテル  ルーセント（Ａｌｃａｔｅｌ Ｌｕｃｅｎｔ）
【０００７】
米国特許第ＵＳ５５７４９３４号には、２つ以上の種類の信号を送信するコンピュータシステムが記載されている。各々の種類の信号には優先度レベルが割り当てられる。特定の種類の信号は、それらが送信可能になったときに送信されるが、より高い優先度を有する、異なる種類の信号が送信可能になった場合は、この限りではない。その場合、低優先度信号の送信は中断され、高優先度信号の送信が可能になる。低優先度信号の送信は、高優先度信号の送信が完了した後に再開される。会議システムを対象とする好適な実施形態では、所与の会議セッションのオーディオ部分に対して高い品質が提供されるように、ビデオ、データ及び制御信号よりも高い優先度がオーディオ信号に割り当てられる。
【０００８】
同様に、米国特許第ＵＳ８１２１１１７号には、第７層であるアプリケーション層において、ネットワークトラフィックに優先順位を付ける技術が記載されている。ネットワークトラフィック管理デバイス（ｎｅｔｗｏｒｋ ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ ｄｅｖｉｃｅ；「ＮＴＭＤ」）は、着信メッセージを第２のネットワークに送信するために、第１のネットワークから第１のＴＣＰ／ＩＰ接続を介して受信する。ただし、ＮＴＭＤは、着信メッセージを第２のネットワーク上に送信する前に、例えば１又は複数の優先度をメッセージに割り当てるなど、いくつかの基準に従って上記着信メッセージを分類する。ＮＴＭＤは、分類されたメッセージを、そのメッセージ分類の順序に従って送信する。例えば、分類が優先度に基づく場合、第１の優先度メッセージは第２の優先度メッセージよりも先に送信される。
【０００９】
同様に、欧州特許出願第ＥＰ２４０８２０５ Ａ１号には、拡張可能な符号化ビデオファイルをビデオサーバからビデオクライアントへと配信する技術が記載されている。更に、記載されている当該技術は、ビデオサーバが、拡張可能な符号化ビデオファイルの１又は複数の基礎層を、第１の優先度クラスを用いる第１の接続を介して配信するように適合され、かつ拡張可能な符号化ビデオファイルの１又は複数の追加層を、第１の優先度クラスよりも低い優先度を有する第２の優先度クラスを用いる第２の接続を介して配信するように適合されることを含む。
【００１０】
本明細書では、表１において提供されるような頭字語及び定義が用いられる。
【００１１】
2016527579.tif 000003
【摘要】
【００１２】
本発明は、例えばオーディオ及びビデオ会議の構成におけるデータ処理能力に関して、強化されたサービス品質をローエンドクライアントデバイス及びハイエンドクライアントデバイスに対して提供する、改善されたデータ通信システムを提供することを目的とする。
【００１３】
本発明は、例えば、オーディオ及びビデオ会議の構成（ただし、これらに限定されない。）におけるデータ処理能力に関して、強化されたサービス品質をローエンドクライアントデバイス及びハイエンドクライアントデバイスに対して提供するデータ通信システムにおいてデータを伝達する、改善された方法を提供することも目的とする。
【００１４】
第１の態様によれば、添付の請求項１に記載のデータ通信システムが提供され、通信ネットワーク構成を介して複数のクライアントデバイスに連結された集中サーバ構成を含むデータ通信システムが提供され、上記集中サーバ構成及び上記クライアントデバイスはそれらの間でデータを交換するように動作可能であり、上記システムは上記データを一次種類のデータ、即ちタイムクリティカルなデータ、及び少なくとも二次種類のデータ、即ち非タイムクリティカル又は低タイムクリティカルなデータに割り振るように動作可能であり、上記一次種類のデータは上記システム内で実質的に即座に伝達され、かつ少なくとも上記二次種類のデータは、上記クライアントデバイスのうちの１又は複数における上記二次種類のデータの受信に応じて上記システム内で伝達される対応確認応答（ＡＣＫ）に関連して、上記システム内で伝達される。
【００１５】
本発明には、例えばクライアントデバイス、及びデータサーバ構成に対する該クライアントデバイスの関連通信リンクが相互に異なるデータ通信性能を有するときに、改善されたサービス品質をそれらクライアントデバイスに提供することができるという利点がある。
【００１６】
データの伝達に集中サーバを用いるか、又はデータをピアツーピア様式で伝達することができることを理解されたい。通信は、例えば再生が用いられたときに、クライアント間又はサーバとクライアントとの間で発生し得る。
【００１７】
クライアントから集中サーバへの直接的な接続が、クライアントからルートサーバ、そして集中サーバへの接続よりも低速である場合、別のサーバがルータとして、クライアントデバイスと集中サーバとの間でデータを交換することができる。ルートサーバは、任意の場所又はネットワーク内に存在してもよく、該ルートサーバは、クライアントに対する応答時間が集中サーバよりも短く、かつ異なるデータ種類のデータフローを制御することもできる。通信内に多くのクライアントが存在するとき、典型的には集中サーバが必要とされるか、又はいずれかのクライアントが集中サーバとして動作する必要がある。通信が２つのデバイス間のみで行われる場合、ピアツーピア通信が任意に利用される。ピアツーピア通信はマルチポイント通信、例えばピアツーピアリングと共に用いることもでき、クライアントはリングトポロジを用いる、構造化されたオーバレイネットワークを用いて相互に接続され、そのようなピアツーピアリングは２つ以上のピアツーピアノードを含み、該ピアツーピアノードは、それらの間及び／又は周辺でデータを交換する。即ち、そのようなピアツーピアリングは、複数の相互に通信するピアツーピアノードを含むリングトポロジに対応する。代替の種類のピアツーピア通信ネットワーク、例えばスタートポロジピアツーピアネットワークが、任意に利用される。この種類のピアツーピア通信は、場合によっては集中サーバから開始することができるが、通信中に集中サーバを積極的に用いる必要はない。クライアントは、いくつかの特性、例えば解像度、フレームレート、オーディオ品質などを変更する必要があると認識したときに、自ら確認応答を実行し、かつ自ら変更要求を作成する。集中サーバは全ての必要な制御及び調整を実行できるため、マルチパート通信では、集中サーバを用いることは有益であることが多いが、これは必須ではない。
【００１８】
任意に、上記データ通信システムでは、一次種類のデータがオーディオデータを含み、かつ二次種類のデータが画像データ及び／若しくはビデオデータ並びに／又は任意の他のデータを含む。
【００１９】
任意に、上記データ通信システムは、ビデオ会議サービス、ビデオ放送サービス（Ｙｏｕｔｕｂｅ、Ｎｅｔｆｌｉｘ、Ｖｉａｐｌａｙなど）、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスなどであってもよい（「Ｙｏｕｔｕｂｅ」、「Ｎｅｔｆｌｉｘ」、及び「Ｖｉａｐｌａｙ」は登録商標である）。
【００２０】
任意に、上記データ通信システムは、通信ネットワーク構成の通信特性及び／又はクライアントデバイスのうちの１又は複数の通信特性を決定し、かつ決定された通信特性に応じて、上記１又は複数のクライアントデバイスへのデータパケット通信の１又は複数のレートを調整するように動作可能である。クライアントは、受信したＡＣＫの間隔によって、リモート側ネットワーク及びＣＰＵの輻輳を測定する。更に、クライアントは、バッファの堆積度、ＣＰＵ負荷及び／又はビデオ／オーディオのレンダリング間隔を受信することによって、ローカルの計算量を測定する。更に、クライアントは、送信データ量及びローカルのＣＰＵリソースの使用量を、品質及び／又はフレームレートによって調整する。
【００２１】
任意に、決定された通信特性に関する調整が、確認応答（ＡＣＫ）が受信される時間間隔によってリモート側ネットワーク及びＣＰＵの輻輳を計測するクライアント、及び／又はローカルで実行される計算の量を、受信バッファの堆積度、ＣＰＵ負荷及び／若しくはビデオ／オーディオのレンダリング間隔に関して計測するクライアント、並びに／又は送信データ量及びローカルのＣＰＵリソースの使用量を品質及び／若しくはフレームレートによって調整するクライアントによって実装される。
【００２２】
任意に、上記データ通信システムは、通信ネットワーク構成の通信特性及び／又はクライアントデバイスのうちの１又は複数の通信特性を決定し、かつ決定された通信特性に応じて、上記１又は複数のクライアントデバイスに伝達されるデータパケットの最大セグメントサイズ（ＭＳＳ）を調整するように動作可能である。
【００２３】
任意に、上記データ通信システムでは、１又は複数のクライアントデバイスのうちの少なくとも１つが、無線対応モバイル通信デバイスである。
【００２４】
任意に、上記データ通信システムは、少なくとも三次のデータを非タイムクリティカルな様式でクライアントデバイス間で伝達するように動作可能であり、上記少なくとも三次のデータはドキュメントに対応する。
【００２５】
任意に、上記データ通信システムは、集中サーバ構成に伝達された一次種類のデータが、該集中サーバ構成から実質的に即座に、参加しているクライアントデバイスに再送信される様式で通信するように動作可能である。
【００２６】
任意に、上記データ通信システムは、一次種類のデータを最も高い優先度として伝達し、引き続いて二次データをより低い優先度として伝達するように動作可能である。
【００２７】
任意に、上記データ通信システムは、クライアントデバイスに伝達するときに、一時的に、二次種類のデータを一次種類のデータよりも優先させるように動作可能である。
【００２８】
任意に、上記データ通信システムでは、通信ネットワーク構成が、少なくとも部分的に、ピアツーピア通信ネットワークとして実装される。
【００２９】
任意に、上記データ通信システムでは、通信ネットワーク構成が、少なくとも部分的に、１又は複数のピアツーピアスタートポロジネットワークとして実装され、上記１又は複数のピアツーピアスタートポロジネットワークは、２つ以上の相互に通信するクライアントデバイス間で該１又は複数のピアツーピアスタートポロジネットワークを通じてデータを伝達するように動作可能である。更に任意に、上記データ通信システムでは、１又は複数のピアツーピアスタートポロジネットワークが、集中サーバ構成を介したデータ通信を低減又は迂回するように動作可能である。
【００３０】
任意に、上記データ通信システムでは、通信ネットワーク構成が、少なくとも部分的に、１又は複数のピアツーピア通信リングとして実装され、上記１又は複数のピアツーピア通信リングは、２つ以上の相互に通信するクライアントデバイス間で該１又は複数のピアツーピア通信リングを通じてデータを伝達するように動作可能である。更に任意に、上記データ通信システムでは、１又は複数のピアツーピア通信リングが、集中サーバ構成を介したデータ通信を低減又は迂回するように動作可能である。
【００３１】
更に任意に、上記データ通信システムでは、相互に通信するクライアントデバイスが、リング及び／又はスタートポロジを用いる、構造化されたオーバレイネットワークを介して通信するように動作可能である。
【００３２】
任意に、上記データ通信システムでは、通信ネットワーク構成が、少なくとも部分的に、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰを実装するインターネットを介して実装される。
【００３３】
任意に、上記データ通信システムでは、上記データサーバ構成が、１又は複数のサービス、例えばバーチャルルーム、マルチポイントサーバ及び／又はマルチプレーヤサーバをホストするように動作可能であることにより、上記システムが、ビデオ会議サービス、ビデオ放送サービス、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスのうちの少なくとも１つを、上記クライアントデバイスを用いる当事者に提供するように動作可能である。
【００３４】
第２の態様によれば、通信ネットワーク構成を介して複数のクライアントデバイスに連結された集中サーバ構成を含むデータ通信システムにおいてデータを伝達する方法であって、
（ａ）    上記集中サーバ構成及び上記クライアントデバイスを、それらの間でデータを交換するように動作させること、但し、上記システムは、上記データを一次種類のデータ及び少なくとも二次種類のデータに割り振るように動作可能であるものとする、並びに
（ｂ）    上記一次種類のデータを実質的に即座に上記システム内で伝達し、かつ少なくとも上記二次種類のデータを、上記クライアントデバイスのうちの１又は複数における上記二次種類のデータの受信に応じて上記システム内で伝達される対応確認応答（ＡＣＫ）に関連して、上記システム内で伝達することと、を含む方法が提供される。
【００３５】
任意に、上記方法は、一次種類のデータがオーディオデータを含むように、かつ二次種類のデータが画像データ及び／若しくはビデオデータ並びに／又は任意の他のデータを含むように準備することを含む。
【００３６】
任意に、上記方法は、ビデオ会議サービス、ビデオ放送サービス（Ｙｏｕｔｕｂｅ、Ｎｅｔｆｌｉｘ、Ｖｉａｐｌａｙなど）、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスなどのデータ通信システム内で用いられる。
【００３７】
任意に、上記方法は、通信ネットワーク構成の通信特性及び／又はクライアントデバイスのうちの１又は複数の通信特性を決定し、かつ決定された通信特性に応じて、上記１又は複数のクライアントデバイスへのデータパケット通信の１又は複数のレートを調整するように、システムを動作させることを含む。
【００３８】
任意に、上記方法は、通信ネットワーク構成の通信特性及び／又はクライアントデバイスのうちの１又は複数の通信特性を決定し、かつ決定された通信特性に応じて、上記１又は複数のクライアントデバイスへのデータパケット通信の最大セグメントサイズ（ＭＳＳ）を調整するように、システムを動作させることを含む。
【００３９】
任意に、上記方法では、１又は複数のクライアントデバイスのうちの少なくとも１つが、無線対応モバイル通信デバイスである。
【００４０】
任意に、上記方法は、少なくとも三次のデータを非タイムクリティカルな様式でクライアントデバイス間で伝達するように、システムを動作させることを含み、上記少なくとも三次のデータはドキュメントに対応する。
【００４１】
任意に、上記方法は、集中サーバ構成に伝達された一次種類のデータが、該集中サーバ構成から実質的に即座に、参加しているクライアントデバイスに再送信される様式で通信するように、システムを動作させることを含む。
【００４２】
任意に、上記方法は、一次種類のデータを最も高い優先度として伝達し、引き続いて二次データをより低い優先度として伝達するように、システムを動作させることを含む。
【００４３】
任意に、上記方法は、クライアントデバイスに伝達するときに、一時的に、二次種類のデータを一次種類のデータよりも優先させるようにシステムを動作させることを含む。
【００４４】
任意に、上記方法は、通信ネットワーク構成を、少なくとも部分的に、ピアツーピア通信ネットワークとして実装することを含む。
【００４５】
任意に、上記方法は、通信ネットワーク構成を、少なくとも部分的に、１又は複数のピアツーピアスタートポロジネットワークとして実装することを含み、上記１又は複数のピアツーピアスタートポロジネットワークは、２つ以上の相互に通信するクライアントデバイス間で該１又は複数のピアツーピアスタートポロジネットワークを通じてデータを伝達するように動作可能である。更に任意に、上記方法は、集中サーバ構成を介したデータ通信を低減又は迂回するように、１又は複数のピアツーピアスタートポロジネットワークを動作させることを含む。
【００４６】
任意に、上記方法は、通信ネットワーク構成を、少なくとも部分的に、１又は複数のピアツーピア通信リングとして実装することを含み、上記１又は複数のピアツーピア通信リングは、２つ以上の相互に通信するクライアントデバイス間で該１又は複数のピアツーピア通信リングを通じてデータを伝達するように動作可能である。更に任意に、上記方法は、集中サーバ構成を介したデータ通信を低減又は迂回するように、１又は複数のピアツーピア通信リングを動作させることを含む。
【００４７】
更に任意に、上記方法は、２つ以上の相互に通信するクライアントデバイスを、リングトポロジ及び／又はスタートポロジを用いる、構造化されたオーバレイネットワークを介して通信するように動作させることを含む。
【００４８】
任意に、上記方法は、通信ネットワーク構成を、少なくとも部分的に、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰを実装するインターネットを介して実装することを含む。
【００４９】
任意に、上記方法は、データサーバ構成を、１又は複数のサービス、例えばバーチャルルーム、マルチポイントサーバ及び／又はマルチプレーヤサーバをホストするように動作させることを含むことにより、システムが、ビデオ会議サービス、ビデオ放送サービス、テレビ会議サービス、マルチユーザゲームサービス、ビデオオンデマンドサービスのうちの少なくとも１つを、クライアントデバイスを用いる当事者に提供するように動作可能である。
【００５０】
第３の態様によれば、非一時的、即ち不揮発性機械可読データ記憶媒体上に記録されたソフトウェア製品であって、第２の態様に係る方法を実施するためにコンピュータハードウェア（ＣＰＵ）上で実行可能である、ソフトウェア製品が提供される。
【００５１】
本発明の特徴は、添付の特許請求の範囲に規定される発明の要旨から逸脱することなしに、様々な組合せにおいて組合せることが可能であることが理解される。
【００５２】
以下の図面を参照して、本発明の実施形態を単なる例示として説明する。
【図面の簡単な説明】
【００５３】
【図１】データサーバの集中構成を利用して、複数の相互に異なるクライアントデバイスＡ、Ｂ、Ｘに対してサービスを提供する、「Ｓｔａｒｗｉｎｄｏｗ（登録商標）Ｓｅｒｖｉｃｅ」として知られるデータ通信システムを示す図である（ＳｔａｒｗｉｎｄｏｗはＧｕｒｕｌｏｇｉｃ Ｍｉｃｒｏｓｙｓｔｅｍｓ Ｏｙの登録商標である）。
【図２】ファイアウォールを介して通信し、引き続いて集中データサーバを迂回することによって該集中データサーバに対するコンピュータ負荷を低減する、集中データサーバを経由した２つのクライアントデバイスＡとＢとの間のデータ交換を示す図である。
【図３】図１のデータ通信システム内に実装されるプロセスに関連するスレッド実行を示す図である。
【詳細説明】
【００５４】
添付図面における下線付きの数字は、下線付きの数字がその上に位置する要素、又は下線付きの数字が隣接する要素を示すために用いられる。下線付きでない数字は、下線付きでない数字と要素とを結ぶ線によって識別される要素に関連する。数字が下線付きでなく、それに関連付けられた矢印を伴う場合、下線付きでない数字は、矢印が指している要素全体を識別するために用いられる。
【００５５】
概略的に言えば、本願においては、ローエンド通信ネットワークを輻輳させず、かつローエンドＣＰＵを非常に短い時間内に過剰量のデータでブロックすることなく、同じリアルタイム通信セッションにおけるローエンドクライアント及びハイエンドクライアントに対するサービス品質（ｑｕａｌｉｔｙ−ｏｆ−ｓｅｒｖｉｃｅ；ＱｏＳ）に対処するように動作可能であるデータ通信システムが記載される。上記データ通信システムは、該データ通信システム内で送信されるデータを、一次種類のデータ及び二次種類のデータなどの複数の種類のデータに分類し、かつクライアントへのそのような種類のデータの配信を、例えば一次方法及び二次方法を利用して集中様式で管理することによって、上述のサービス品質（ＱｏＳ）を実現する。好ましくは、相対パケットレートが適宜選択され、かつデータ通信システム内で個々に合わせた確認応答スキームが利用される、最適化されたネットワーク利用法が用いられる。
【００５６】
本明細書に記載されている実施形態は、例えば、ビデオ会議ソリューションを提供することに関連して、即ち、あらゆるクライアントデバイス及びネットワーク種類に対してサービス品質（ＱｏＳ）を保証するために考案されたものである。例えば、そのようなビデオ会議ソリューションは、データ通信ネットワーク、例えばそれには限定されないが、インターネットを介して実装することができ、上記通信ネットワークの領域は、通信性能において相互に異なっていてもよく、かつ上記ビデオ会議ソリューションを提供するそのようなデータ通信ネットワークを介して連結されたデバイスは、該デバイスで受信されるデータの処理能力に関して、相互に異なっていてもよい。
【００５７】
上記ビデオ会議ソリューションは、２人以上の当事者が、サービスプロバイダのサーバに設けられたバーチャルルームを介して相互に通信可能に連結される、Ｓｔａｒｗｉｎｄｏｗの概念に従って実装されることが好ましく、上記サーバを通過する全ての情報は、該サーバに連結された全ての当事者に送信される。ただし、クライアントはサーバ又はサーバノードとしても動作し得る場合があり、その場合、実際の集中サーバは常に必要となる訳ではないことを理解されたい。再生においては、情報を保持及び配信する１台のみのクライアント及びサーバが存在してもよい。場合によっては、再生サービスは１台の送信クライアントと同様に動作し、クライアントと同様、リアルタイム通信に関する独自の問題を生じ得る。つまり、クライアント又はサーバでは、受信クライアントの特性に基づきデータ配信量を調整することが必要になる場合があり、例えば、そのような状況は、複数のクライアントが再生データを同時に受信し、それについて議論する場合に発生する。記録サービスも、受信クライアントとして理解され得る場合がある。記録サービスは、配信された情報を受信時の品質を用いて格納することが理想的であるが、場合によっては符号変換が必要になる。
【００５８】
上述のＳｔａｒｗｉｎｄｏｗの概念は、通信ネットワーク速度の違いによって実際に発生する問題、当事者のクライアントデバイスの処理能力の違いによる問題、並びに当事者のクライアントデバイスがサーバに通信可能に連結されるときに経由する、相互に異なるネットワークインフラストラクチャによる問題に対処し得る。
【００５９】
本明細書で説明される実施形態は、インターネットを介して実施されることが好ましいが、任意に、無線通信ネットワーク並びに光ファイバ及び有線接続ネットワークを利用する。現代のインターネットを利用する場合、上記インターネットはハイパーテキスト転送プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ；ＨＴＴＰ）を利用することが好ましい。上記プロトコルは、分散型かつ協調型のハイパーメディア情報システムを対象とするアプリケーションプロトコルである。実装において、ＨＴＴＰは、ネットワークを定義する論理リンクを用いて該ネットワークを構築するように動作可能であるオブジェクトの多重線形セットであり、上記リンクはしばしば、ノード間のネットワーク関係を定義する「ハイパーリンク」と称される。
【００６０】
ＨＴＴＰは、隣接するネットワーク要素がクライアントデバイスとサーバとの間の通信を可能にし得るように設計されている。インターネットの高トラフィックウェブサイトは、しばしば、アップストリームサーバに代わってコンテンツを配信するように動作可能であるウェブキャッシュサーバを利用することによって、データ及び／又はサービス配信の応答時間を改善する。更に、プライベートネットワーク境界でＨＴＴＰプロキシサーバを用いることによって、グローバルにルーティング可能なインターネットアドレスなしで、即ち外部サーバを介してメッセージを中継することによって、クライアントの通信を容易にすることが好ましい。
【００６１】
ＨＴＴＰリソースは、ユニフォームリソースロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ；ＵＲＬ）とも称されるユニフォームリソースアイデンティファイア（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ；ＵＲＩ）を用いることによって、所与のネットワーク上で識別され、かつ配置される。更に、ＵＲＩ及びハイパーリンクは、相互に結び付けられたハイパーテキストドキュメントのウェブを形成し得る、ハイパーテキストマークアップ言語（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ；ＨＴＭＬ）で表現される。
【００６２】
ＨＴＴＰは、便宜上「動詞（Ｖｅｒｂ）」と称される、識別したリソースに関して実行され得る所望のアクションを示すメソッドを定義する。上記リソースは、例えば、データファイルであるか、又は１若しくは複数のサーバ上に存在する実行可能オブジェクトからの出力である。表２において、ＨＴＴＰ「動詞」の例を提供する。
【００６３】
2016527579.tif 000004
【００６４】
本願に記載される実施形態では、当事者の複数のクライアントデバイスに通信可能に連結された集中サーバにおいてデータを処理するために、一次及び二次方法などの複数の方法を利用する。上記集中サーバは、Ｓｔａｒｗｉｎｄｏｗ又は類似のサービス構成で連結されることが好ましい。例えば、一次方法では、当事者のクライアントデバイスが、集中サーバにおける同じ所定のＴＣＰ／ＵＤＰポートを介して接続され、そのような接続様式は、関与する全ての当事者に対して特定の接続セッションを作成する。このセッションは、所与の当事者が上述のバーチャルルームに通信可能に接続されている限り、持続することが好ましい。更に、ユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ；ＵＤＰ）は非接続型であり、その結果、ユーザデータグラムプロトコル（ＵＤＰ）が利用されるときは、所与の通信セッションがソフトウェアアプリケーションレベルで制御されることを理解されたい。
【００６５】
本願に開示される実施形態を実施するためにコンピュータハードウェア上で実行されるソフトウェアアプリケーションは、上述の複数の方法、例えば一次方法及び二次方法を利用し、一次データ及び二次データを送信することによって相互に通信する。一次データは、例えば、タイムクリティカルなオーディオデータを含む。更に、二次データは、例えば、低タイムクリティカル又は非タイムクリティカルであることが多い、ビデオデータを含む。
【００６６】
上述のＳｔａｒｗｉｎｄｏｗ又は類似のサービス構成の動作中、オーディオデータを含む一次データは集中サーバに送信され、該集中サーバは、利用される通信又はコマンドプロトコルにかかわらず、所与のセッションの指定された当事者のクライアントデバイスへと、一次データを実質的に即座に再送信する。したがって、タイムクリティカルなオーディオデータとしての一次データは、Ｓｔａｒｗｉｎｄｏｗ又は類似のサービス内で決して確認されないため、所与の受信クライアントデバイスが再送信された一次データを受信するために待機させられることは決してなく、低タイムクリティカルなビデオデータとしての二次データは、ネットワーク接続若しくはセッションの当事者の受信デバイスの任意のＣＰＵをブロックすることも、又は氾濫させることもなく、Ｓｔａｒｗｉｎｄｏｗ若しくは類似のサービスを介して送信される。その理由は、上記セッションが確認応答によって制御されるためである。好ましくは、確認応答は次のパケットの送信／伝送を遅延させることができ、かつ、例えば品質を下げるか又は画像のサイズを小さくすることによってデータの量を減らす必要があるか否かを判断する目的で、上記遅延から、データがどれぐらい適切に伝達されたか、及び／又はデータの処理にどれぐらいの時間がかかるかを推測することができる。
【００６７】
上述の二次データは、セッションの当事者の所与のクライアントデバイスによって送信され、集中サーバで受信される。該集中サーバは、所与のセッションの他の当事者への再送信を実行し、該他の当事者は、確認応答を送信することによって、再送信された二次データの受信を確認する。二次データのそのようなフローを制御することによって、Ｓｔａｒｗｉｎｄｏｗ又は類似のサービスは、制限されたデータ帯域幅を有し得るローエンドネットワークを輻輳させることなく、かつローエンドＣＰＵを非常に短い時間内に過剰量のデータでブロックしないようにすることができる。対照的に、リアルタイム通信を対象とする、現代の知られている多くのプロトコルは、しばしば、２者の参加者同士の間のセッションにおいてのみ適切に動作し、より多くの参加者が所与のセッションに参加した場合、参加者のクライアントデバイスのＣＰＵ、及び所与のセッションに関連するデータフローを搬送するネットワークインフラストラクチャにとってのデータ処理要件は非常に厳しくなる。本願に記載される実施形態、例えばＳｔａｒｗｉｎｄｏｗサービスとして実施されるものは、受信したデータを処理する能力がより低い当事者のクライアントデバイスがセッション内に留まるように、再送信されるデータを制御することによって、クライアントデバイスのＣＰＵに対する過剰な要求が発生することを回避する。
【００６８】
ここで本願に開示される実施形態について、図１を参照して説明する。データ通信システムは、概して１０として示される。システム１０は、例えば、識別情報「ルーム８００１」が与えられた、Ｓｔａｒｗｉｎｄｏｗサービスとして実装されるサーバ２０を含む。サーバ２０と互換性があるクライアントデバイス３０、例えばＳｔａｒｗｉｎｄｏｗ対応クライアントデバイスは、クライアントデバイスＡ、Ｂ及びＸを含み、これらのクライアントデバイス３０は、所定のバーチャルルーム、例えばサーバ２０のＴＣＰポート８００１を介して実装された上述の「ルーム８００１」に接続することができる。任意に、所定のバーチャルルームへの接続は、識別及びアドレス指定がポートに依存しない、非接続型のユーザデータグラムプロトコル（ＵＤＰ）セッションとして実装され、例えば、識別及びアドレス指定は、任意に、ソケットレベルにおいて実装されるか、又はアプリケーションレベルコマンドを用いるなどの別の判定形式によって実装される。このバーチャルルームは恒久的に存在するか、又は該バーチャルルームは、システム１０を用いて作成された所与の通信セッションであることが好ましい。上記バーチャルルームは複数の当事者が相互に通信する環境を作り出し、Ｓｔａｒｗｉｎｄｏｗサービス又は類似のサービスは、上記セッションのける相互に接続された当事者全てのオーディオビジュアルデータを、制御された様式で送信するように動作可能である。
【００６９】
図１のシステム１０は、クライアントデバイス３０のＣＰＵのデータ処理性能、並びにクライアントデバイス３０に関連する通信ネットワークインフラストラクチャ、及びデータ通信容量及び／又は待ち時間などクライアントデバイス３０に関連する性能特性を考慮して、クライアントデバイス３０にデータを送信するように動作可能である。任意に、システム１０はいくつかのネットワークプロトコル及びオーディオビジュアル（ａｕｄｉｏ−ｖｉｓｕａｌ；ＡＶ）コーデックを利用する。ただし、システム１０の動作の重要な特徴は、サーバ２０が、クライアントデバイス３０において利用可能なデータ処理リソースを考慮しながら、サーバ２０とクライアントデバイス３０との間の一次データ及び二次データのフローを集中様式で管理することである。図１において、クライアントデバイス３０から見て、「ＴＸ」は、送信されるデータを示し、「ＲＸ」は、受信されるデータを示す。クライアントデバイス３０は、サーバ２０、即ちＳｔａｒｗｉｎｄｏｗサービス又は類似のサービスに対する少なくとも２つの接続又はＸクライアントに対して示された１つの２次元ＲＸ／ＴＸ接続を作成し、即ち、データを受信する少なくとも１つの接続、及びデータを送信する少なくとも１つの接続を作成する。任意に、ビデオ情報及びオーディオ情報に対して別々の接続を利用することが可能である。
【００７０】
図１のシステム１０は、１又は複数のルートサーバを経由してデータを送信するように動作可能である。通常、ルートサーバはバックボーンネットワーク内に存在するが、任意に、任意のネットワーク内に存在してもよい。更に、クライアントがルートサーバとして動作してもよい。通常、ルートサーバのネットワーク容量は、クライアントが接続されるネットワークよりも大きい。このため、クライアントから集中サーバへの直接的な接続が、クライアントからルートサーバ、そして集中サーバへの接続よりも低速である場合、別のサーバがルータとして、所与のクライアントデバイスと集中サーバとの間でデータを交換することができる。したがって、ルートサーバが用いられる場合、該ルートサーバは通常、クライアントネットワークにとって、集中サーバよりも地理的に優れた位置に存在する。ルートサーバは任意に、上述のＱｏＳの方法のように、様々なデータ種類のデータフローを制御する。二次データに関連する確認応答は、ルータサーバの有無に関わらずネットワーク容量の変化を考慮する。速度は常にネットワークの最も低速な部分によって制限されるため、通常は、ネットワークに対して用いられるルートサーバが、該ルートサーバの様々な側において、より高速であるか低速であるかは、それほど重要ではない。ルートサーバがデータを調整する能力を有する場合、該ルートサーバは任意にデータ調整を実行することもできる。
【００７１】
通信ネットワークを利用してクライアントデバイス３０をサーバ２０に連結し、システム１０が、上記通信ネットワークを最適な様式で利用するように動作可能であることが好ましい。動作中、サーバ２０は、各クライアントデバイス３０が処理することができる、例えばそれらのＣＰＵ内で処理することができる最大データパケットサイズを決定するために、クライアントデバイス３０の各々に最大転送単位（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ；ＭＴＵ）値を要求する。任意に、システム１０内の送信速度を向上させる目的で、システム１０の通信ネットワークは、ユーザデータグラムプロトコル（ＵＤＰ）をピアツーピアで利用し、かつ最適化されたパケットヘッダを利用することにより、例えば伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；ＴＣＰ）が要求する全てのデータパケットに対して確認応答を必要とすることなく、ピアツーピア通信をクライアントデバイス３０間に直接生じさせること等が可能になる。
【００７２】
上述の説明を要約すると、システム１０はサーバ２０を介して、データを少なくとも一次及び二次種類のデータとして処理する。更に、クライアントデバイス３０をサーバ２０に連結するために利用される通信ネットワークは最適化され、かつ確認応答はシステム１０内でカスタマイズされた様式で処理される。そのような特徴は、次に説明する実施形態において更に明らかになる。
【００７３】
システム１０内でデータパケットが伝達された結果、データはサーバ２０を介して送信されるが、このデータフローは、一次及び二次種類のデータを処理することによって制御される。このため、システム１０内の実際の通信では、少なくとも２つの種類のデータが区別され、かつ処理される。好ましくは、一次種類のデータはしばしば、タイムクリティカルなオーディオデータであり、このようなオーディオデータは、特にリアルタイム通信アプリケーションがシステム１０内で実行されているときに失効するため、古くなる前に迅速に伝達されなければならない。例えば、１つの文の最後の２つの単語が２秒遅延しただけでも、その文は理解不可能となり、即ち理解を達成するには遅すぎることが実際に確認されている。
【００７４】
システム１０内で伝達される二次種類のデータは、上述の一次種類のデータほどタイムクリティカルではないが、それでも可能な限り、システム１０内において、その理解可能性に悪影響を与えない程度の遅延で送信されることが好ましい。サーバ２０は、一次及び二次種類のデータの送信に関して通信を制御することによって、自身のサービス、例えばＳｔａｒｗｉｎｄｏｗサービスを提供し、各クライアントデバイス３０に対する一次種類のデータは、サーバ２０を介して遅延なしで、又は最小限の遅延で送信され、その結果、一次種類のデータは二次種類のデータよりも前に送信されるが、そのような一次種類のデータの優先順位付けが存在しない場合は、二次種類のデータがより早く到達する可能性がある。受信される二次データの一部は、例えば、新しい画像フレームが到達しているが、一部のクライアントへの古い画像フレームの送信が依然として開始されていない状況において、サーバから１又は複数のクライアントに決して送信されない可能性があることを理解されたい。利用されるコーデックが、その古いフレームを省略することができる場合、該フレームはそれらの１又は複数のクライアントに対して省略される。一次種類のデータ、例えばオーディオデータが原因で、通信ネットワーク又はクライアントデバイス３０のＣＰＵに対して極端に大きい作業負荷が発生することはない。その理由は、システム１０が、一次種類のデータが時間的に古くなるか、又は任意の他の理由で古くなった場合に、一次種類のデータを処理しないように動作可能であるためである。逆に、古い二次データがクライアントデバイス３０のうちの１又は複数によって受信され、かつ１又は複数の対応確認応答（ＡＣＫ）が１又は複数のクライアントデバイス３０によってサーバ２０に送り返されない限り新しい二次種類のデータがシステム１０内で送信されることはない点を除き、二次種類のデータは、一次種類のデータと実質的に類似した様式で処理される。クライアントデバイス３０のうちの１又は複数における二次種類のデータの受信に応じて該クライアントデバイス３０のうちの１又は複数によって送信される確認応答（ＡＣＫ）は、参照により本明細書に組み込まれる、ＲＦＣ ７９３「トランスミッション  コントロール  プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）」、ＵＲＬ：http://tools.ietf.org/html/rfc793、参照により本明細書に組み込まれるＲＦＣ７９１、ＵＲＬ：http://datatracker.ietf.org/doc/rfc791/、及び参照により本明細書に組み込まれる「インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）」、ＵＲＬ：http://en.wikipedia.org/wiki/Internet_Protocol等において定義されている、ＴＣＰ／ＩＰプロトコルに関するＡＣＫメッセージを用いて実行されることが技術的に好ましい。このＡＣＫメッセージは、ＴＣＰデータパケットのヘッダ内において送信されることが好ましく、したがって、上記ＡＣＫメッセージは、そのようなヘッダ内において伝達されることが好ましい。その理由は、受信されたデータパケットの確認応答が、１又は複数のクライアントデバイス３０のネットワークカード（ｎｅｔｗｏｒｋ ｃａｒｄ；ＮＩＣ）によってハードウェアレベルで実行されることにより��１又は複数のクライアントデバイス３０の主要ＣＰＵリソースを、そのような確認応答の目的で利用する必要性を回避することが好ましいからである。任意に、上述の受信されたＴＣＰデータパケットのＡＣＫ確認応答を利用することなく、カスタマイズされた確認応答構成を用いるなど、１又は複数の代替確認応答技術が利用される。
【００７５】
二次データ用にカスタマイズされた様式で確認応答を処理することに関しては、特にＵＤＰプロトコルが利用される場合、確認応答を実行する代替方法が任意に適用され得る。例えば、ＵＤＰプロトコルは既定で確認応答を用いないが、ストリーム内の現在のデータの特性に応じて、カスタマイズされた確認応答が、任意に、例えば各パケットに対して、又は５つのパケットごとに、又は各画像に対して数回、又は各画像に対して、又は５つの画像ごとなどに送信される。
【００７６】
１又は複数のクライアントデバイス３０からの確認応答（ＡＣＫ）メッセージの輻輳管理は、サーバ２０内、及び任意に１又は複数のクライアントデバイス３０においても実装される。更に、上記管理は、システム１０内で伝達される個別のデータパケット内に実装されることが好ましい。そのような輻輳管理は、システム１０がＣＰＵ及びネットワークリソースをクライアントデバイス３０ごとに制御することを可能にする。
【００７７】
システム１０内で提供されるサービスの機能に関連して、受信された二次種類のデータの確認応答は、対応する二次データパケットが受信かつ処理されたら可能な限り直ちに受信機から送信されることが好ましい。その理由は、そのような迅速な確認応答によって、利用される通信ネットワーク及びＣＰＵ負荷を最も効率的に管理することが可能になるためである。
このため、システム１０は、クライアントデバイス３０が通信ネットワークを輻輳させないように動作可能であり、かつ、性能が低く豊富なリソースを有していない、例えば、受信速度が恒久的に遅い可能性があるクライアントデバイス３０にサービスを提供する通信ネットワークを輻輳させ得る、大量の二次種類のデータを送信しないように動作可能である通信サービス、例えば上述のＳｔａｒｗｉｎｄｏｗサービスを提供することができる。更に、システム１０は、例えばユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ；ＵＳＢ）モデム又はＵＳＢネットワークスティックの動作特性の、例えば無線通信リンクを介した変化から生じる、通信ネットワークのデータ通信容量の変化に対処することができる。更に、システム１０は、一次種類のデータの送信時間も節約するように管理されることが好ましく、一次データパケットは常に二次データパケットよりも前に送信されることが好ましい。一次データを含むデータパケット内に空きがある場合、その空きは任意に、二次データによっても埋められることが好ましく、そのようにパケットデータ搬送容量を有効利用することによって、新しい一次データパケットをこのパケットの直後に配信することができるが、新しい二次データパケットが送信可能になるには、その前に上記一次データを含むデータパケットの確認応答が受信される必要がある。
【００７８】
システム１０の例示的実施形態では、一次オーディオデータパケットがリアルタイムで再生されることが好ましい。逆に、通常は１０倍の大きさを有し、かついくつかのデータパケットを含む、ビデオデータは、はるかに大きいＣＰＵ負荷を与えるため、一次データパケット、例えばオーディオデータに対する応答時間も直ちに長くなってしまう。このため、上述のように、二次データパケットは、例えばＳｔａｒｗｉｎｄｏｗサービスに関して上述されているような確認応答スキームを用いて確認される。
【００７９】
システム１０によって提供されるサービス、例えばＳｔａｒｗｉｎｄｏｗサービスでは、クライアントデバイス３０のいくつかが、ローエンドＣＰＵを備えるが、それにもかかわらず、そのクライアントデバイス３０のいくつかには、サーバ２０に対する十分に高速なネットワーク接続が提供され、かつ該クライアントデバイス３０は、Ｓｔａｒｗｉｎｄｏｗバーチャルルームに参加しており、二次画像データは該二次データの受信時に処理済みとして破棄及び確認され、その場合、ＣＰＵ負荷はローエンドＣＰＵを備えるクライアントデバイス３０において受信された一次データを処理するために軽減される。更に、上記サービスは、相対的に高速なクライアントデバイス３０の確認応答を時間的に遅延させることによって、ＣＰＵ負荷を軽減するか、又はローエンドＣＰＵを備えるクライアントデバイス３０、即ち低性能クライアントデバイス３０の通信ネットワーク容量を節約することもでき、その場合、システム１０は、画像周波数を二次データ内で提供されるものと同様に低減するように動作可能である。更に、システム１０は任意に、サーバ２０を制御することによって、サーバ２０によってホストされるバーチャルルームのビデオ解像度を定義するように動作可能であり、その場合、クライアントデバイス３０は、より小さい画像、例えば低解像度画像又はより限定された画像（例えば、背景の境界線を含まない参加者の顔のみ）を送信し、その結果、低性能クライアントデバイス３０のＣＰＵ負荷及び対応する関連通信ネットワークの負荷が軽減される。任意に、システム１０は、一次種類のデータのオーディオ情報を符号変換し、かつ／又は画像更新頻度及び／若しくは画像解像度を低減するように動作可能である。システム１０の動作におけるそのような調整によって、低性能クライアントデバイス３０は、システム１０内で一次及び二次種類の両方のデータフローに対処することができる。
【００８０】
好ましくは、クライアントデバイス３０は、システム１０内において、ＣＰＵ及び通信ネットワークリソースの制限内で実現可能な最も高い解像度及び品質で情報を受信及び送信することによって、クライアントデバイス３０を用いる当事者にとって最適な情報送信体験を提供する。クライアントデバイス３０は、任意に、スマートフォン、タブレットコンピュータ、ファブレットコンピュータ、ラップトップコンピュータ、パーソナルコンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ；ＰＣ）、パーソナルデータアシスタント（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ；ＰＤＡ）、無線対応手首装着型コンピュータのうちの１又は複数を含むが、これらに限定されない。
【００８１】
システム１０において、低性能クライアントデバイス３０のＣＰＵ負荷を軽減する最も効率的な様式は、独自のオーディオ及び画像の符号化を低減することによって実現され、これは例えば、品質を低下させること、フレームレートを低下させること、又は容量効率の低い符号化を用い、かつサーバがデータを更に圧縮することを可能にして計算負荷をサーバに移行することによって実現される。低性能クライアントデバイス３０を支援するそのような手法は、低性能クライアントデバイス３０における受信されたデータの復号化を低減することよりも大きな効果を有し、そのような調整は、システム１０において、上述の確認応答スキームを用いること並びに要求及び送信されるデータの特性を変更することの両方によって集中様式でクライアントデバイス３０への及び／又はクライアントデバイス３０からのデータ送信速度を検査する上記システムの能力により実現され得る。
【００８２】
システム１０がクライアントデバイス３０間で他の種類のデータ、例えば、ドキュメント、測定結果データなどの如何なるリアルタイム効果も有さないファイルを伝達するように指示された場合、上記他の種類のデータは、システム１０内において、一次及び二次種類のデータよりも低い優先度を有する三次種類のデータとして伝達されることが好ましい。このため、システム１０内では、その動作中に、該システムを通じて伝達されるデータの種類に対して、３つ以上の優先順位付けレベルが利用されることが好ましい。ただし、そのような優先順位付けは、動的に変化し得る様式でシステム１０内に実装されることが好ましく、その結果、場合によって優先順位付けが変更され、例えば、クライアントデバイス３０を用いる当事者間で開始された交渉中などに、ドキュメントデータがクライアントデバイス３０に配布される間、上記ドキュメントデータは数秒間、オーディオ及び／又はビデオデータよりも優先される。再生データは、リアルタイム効果を有さないデータとして、又は一次及び二次データを含むデータとして理解され得る。同時に再生データを視聴し、それについて議論することを希望する複数の当事者が存在する場合には、場合により上記再生データは最も高い優先度を有することができ、かつ通常の通信の一次データ及び二次データは、上記再生データよりも低い優先度を有する。ユーザが１人であり、他に再生データを視聴する人が存在しない場合、受信クライアントは１台のみ、かつ再生データを配信するクライアント又はサーバは１台のみになり得る。そのような状況では、再生データが典型的には一次データ及び二次データを含み、これらのデータは、他のクライアントから送信され、通信時に連結されるデータと同様に処理される。所与の記録が実行されたときに、記録デバイス、例えば通信におけるいずれかのクライアント、別の受信クライアント、サーバノード、ルータサーバ又はサーバは、帯域幅及び処理リソースに関する制限を有し得る。記録デバイスは、通常の受信クライアントに関する要求と同様に、一次データ及び二次データを用い、かつ帯域幅又は処理能力に依存し得る必要な品質調整を用いて、着信データに影響を与える。
【００８３】
システム１０の動作においては、上述のようにオーディオデータに最も高い優先度が与えられ、ビデオデータに二次優先度が与えられ、他の種類のデータに三次又はより低い優先度が与えられるのが最も一般的である。好ましくは、異なるデータ種類の送信に関する配分の比率目標が、任意にシステム１０内で利用され、その結果、システム１０内のデータ送信に関連する長時間の遅延が防止される。サーバ２０が、例えば、オーディオデータがクライアントデバイス３０のうちの１又は複数への通信リンクの全ての利用可能な帯域幅を利用していることを識別した場合、サーバ２０は、関連付けられたより低いデータフローレートを有する、より低い品質のオーディオ送信を指示し、例えば、オーディオダイナミックレンジ圧縮と組み合わせて、１６ビットオーディオ解像度から１０ビットオーディオ解像度、又は更に８ビットオーディオ解像度へと低下させるように動作可能である。
【００８４】
システム１０は、サーバ２０と通信するクライアントデバイス３０を連結する通信ネットワークに、ネットワーク最適化を適用するように動作可能であることが好ましい。そのようなネットワーク最適化は、例えば、接続されたクライアントデバイス３０をサーバ２０に連結するネットワークに最大転送単位（ＭＴＵ）値を要求することによって実装される。これにより、通信ネットワーク内の最弱通信リンクを識別し、引き続いて、上記最弱リンクに関連付けられたクライアントデバイス３０への送信に対する最大セグメントサイズ（ＭＳＳ）を、上記最弱リンクによって対応し得るレートで設定することができる。このＭＳＳ値は任意に、サーバ２０によってシステム１０の他のクライアントデバイス３０へと伝達される。そのようなネットワーク最適化は、以下のステップを有する方法を用いて実装されることが好ましい。
【００８５】
ステップ１：システム１０は、サーバ２０をクライアントデバイス３０に連結する最弱データリンクを決定し、例えば、所与のデータリンクに対するＭＴＵ値は１５００バイトである。このＭＴＵ値からＴＣＰヘッダバイトの数、即ち４０バイトを減算した１４６０バイトが使用可能である。この１４６０バイトがＭＳＳに相当する。
【００８６】
ステップ２：システム１０は、識別された最弱リンクのＭＳＳを利用することによって、所与のセッションに対するＭＳＳを決定する。
【００８７】
ステップ３：任意に、システム１０内で利用されるネーグルアルゴリズムが、システム１０内の輻輳制御を防止する目的で無効化され、これは、即ち、システム１０のソケット上でＴＣＰ＿ＮＯＤＥＬＡＹオプションを設定し、ネーグルアルゴリズムを無効化することによって実現される。そのようなネーグルアルゴリズムの無効化は望ましく、その理由は、ネーグルアルゴリズムが、特定の量のデータバイトが送信キューに追加されるまで待機し、その後、対応するデータパケットが送信されるためである。ネーグルアルゴリズムが無効化されると、システム１０は、上述のようにシステム１０のみによって決定されたサイズのデータパケットを送信することができる。
【００８８】
全２重、即ち２方向通信のパケットレートは、単位時間内に伝達されるパケットの量である。更に、パケットレートはシステム１０内でデータ通信に用いられるプロトコルに依存し、確認応答が必要な場合は、システム１０内で実現可能なパケットレートが低下する。その理由は、対応確認応答が上記送信機において受信されなかった場合に、システム１０の送信機がデータパケットを再送信する必要があるためである。ビデオ信号フレームは１つの画像を含み、対応するデータは通常、いくつかのネットワークデータパケットが送信されることを必要とする。更に、オーディオフレームは、指定された量の連続したオーディオサンプルを含む。ビデオデータ及びオーディオデータのどちらに関しても、両方の種類のフレームが、その対応するデータに加えて、ヘッダバイトを有する。
任意のヘッダ部内に、量に関する情報及び／又は性質に関する情報、例えばパケットが伝達されるのに必要な時間、画像面積又は何らかの他の量を示す情報が含まれている場合、そのような情報に対する所与のクライアントデバイス３０の消費能力を計算することができる。この消費又は吸収能力は、残りのデータと共に配信することができ、その場合、各クライアントデバイス３０及びサーバ２０は、この特定の量又は性質に合わせて、利用されるデータ送信速度を調整することができる。これにより、システム１０内で伝達される情報の種類間のバランスを、性質の柔軟性によって、例えば緊急度に応じて、及び／又はリソース要件に基づき維持することができる。調整される要素は、例えば、相対パケットレートに関する情報の種類及び／又は緊急度の種類である。上記要素を用いることによって、システム１０内における情報配信のバランスをクライアントデバイス３０ごとに維持することができ、その結果、各クライアントデバイス３０は、システム１０の動作時に、可能な最善の経験を得ることができる。
【００８９】
即ち、システム１０内では常に、データパケットの送信及び受信の両方のバランスを維持することができる。データパケットの送信及び受信はどちらも重要であることが多く、システム１０全体の動作は、状況に応じて最適化された様式で制御される。ただし、場合によっては、１台の所与のクライアントデバイス３０へのデータパケットの送信が、システム１０の別のクライアントデバイス３０へのデータパケットの送信よりも重要となる。更に、データパケットを送信するときのデータ通信レートは、データパケットを受信するときのデータ通信レートと大きく異なる場合があるため、そのような差異はシステム１０の動作を最適化するときに考慮される。
【００９０】
システム１０内でデータを伝達するときは、データパケットサイズが、上述のように決定されたＭＳＳ（ＭＴＵヘッダ）に設定されることが望ましい。任意に、相対パケットレートに関する情報は、ヘッダの任意部／データ部を含む。更に、システム１０内で動作時に発生する通信遅延は、実現される相対的なパケット通信レートの差異及び変化を計測することによって計算されることが好ましい。各クライアントデバイス３０は、クライアントデバイス３０によって送信されたデータパケットの受信遅延を、自身が送信したデータに含まれる相対パケットレートに関する情報を用いて、受信したパケットレートに関する情報から計算することが好ましい。
【００９１】
パケットレートは、例えば、サーバ２０とクライアントデバイス３０との間の確認応答の間隔に基づき、かつ／又は元のデータの最後のパケットが送信された時点と、最後のデータパケットの受信が確認された時点との間に経過した時間を計算することによって、定義することができる。このため、データ転送に必要な時間に加えて、上述のパケットレートメカニズムは、受信されたデータの処理に必要な時間を観察及び評価することもでき、したがってシステム１０は、処理時間の変化に対応し、かつシステム１０の受信クライアントデバイス３０において経験されるＣＰＵ処理負荷を推定することができる。
【００９２】
システム１０は、集中様式でデータを送信し、かつサーバ２０を迂回することを可能にする、個々に合わせた確認応答スキームを利用する。そのような動作様式は、任意に、例えば、システム１０内でＵＤＰピアツーピア通信手法を用いて実現することができる。ＵＤＰプロトコル自体は確認応答を用いず、単にデータグラムパケットを、それらが受信されるか否かをチェックすることなく送信する。任意に、システム１０内で利用されるＵＤＰピアツーピア通信方法は、接続されたデータパケット配列の最後のデータパケット内に、該最後のデータパケットで配列が終了することを受信クライアントデバイス３０に通知する追加メッセージを付加する。
【００９３】
更に、一旦ＵＤＰ送信機がサーバ２０に登録され、サーバ２０を介した所与の受信クライアントデバイス３０との通信を開始すると、上記ＵＤＰ送信機は、それ以降、残りの通信を受信クライアントデバイス３０に対して直接送信及び受信することができる。このため、図２では、３０Ｂによって示されたクライアントデバイスＢが、サーバ２０及び通信ネットワークであるインターネット６０を介して、３０Ａによって示されたクライアントデバイスＡにデータを送信することが望ましい。クライアントデバイス３０Ａ、３０Ｂは、それぞれ対応するファイアウォール７０、８０を介して保護される。通信１５０、１６０は、初期データ交換がクライアントデバイス３０Ａと３０Ｂとの間でサーバ２０を介して発生することを可能にし、それ以降のデータ交換は、通信１７０によって示されるように、クライアントデバイス３０Ａと３０Ｂとの間で直接実施される。好ましくは、データは、該データを受信するように動作可能であるクライアントデバイス３０Ａのピアツーピアポートに送信される。通信１７０を介して送信されるデータパケットは、全体が図３の２００によって示されるように、クライアントデバイス３０Ａ、３０ＢのＣＰＵによって管理されることが好ましい。図３に示すように、各々の種類のデータパケットは、その独自のスレッド２５０を、データを処理し、かつＣＰＵ２１０上で実行されるソフトウェアアプリケーション内で作成する。ＣＰＵ２１０は複数のプロセス２４０をホストし、かつスレッド２５０はＣＰＵ２１０のメモリスタック２６０を介して制御され、スレッドプロセスの結果は、メモリスタック２６０から対応する関連スレッド２５０へと送信される。着信データパケット２３０は着信パケットキュー２２０内に格納され、着信パケットキュー２２０は着信データパケット２３０をプロセス２５０に供給する。好ましくは、各データパケット２３０は、配列番号をそのヘッダ内に含めて搬送し、配列の最後のパケットが該配列の終端であることを通知する。
【００９４】
受信された各データパケット２３０は、ＣＰＵ２１０上で実行されるアプリケーションプロセス２４０内で、その独自のスレッド２５０において処理されることが好ましい。更に、着信パケットキュー２２０内の最後のデータパケット２３０は、データパケット２３０の配列全体が完全に受信されたことをプロセス２４０に通知するイベントを発生させる。例えば、データパケット２３０の配列が１００個のデータパケットを含む場合、一連のパケット１〜９９の各々は、独自の対応するスレッド２５０内で受信され、ＣＰＵ２１０を介して処理された後に終了するが、１００番目のデータパケット２３０は、データパケット２３０の配列を完結するものとして検出される。
【００９５】
システム１０は、例えば上述の様々な異なる実装において、品質が相互に異なる通信ネットワークインフラストラクチャを用いる、全く異なる種類のクライアントデバイス３０間の相互通信を、同じリアルタイム通信セッション、例えばビデオ会議セッションに参加させることを可能にする。より多くのクライアントデバイス３０が、無線媒体のノイズを発生させやすい、比較的制限された処理能力を有するモバイル無線デバイスである場合、システム１０は将来的にますます重要となる可能性がある。したがって、システム１０は、既存の情報処理システム内で用いられている通信プロトコルを変更することなく、該情報処理システム内で利用することができ、それにより、システム１０を既存の通信ネットワーク、例えばインターネット６０内で容易に実装することが可能になる。上記で明らかにされたように、上述の実施形態は、タイムクリティカルな一次データ及び非タイムクリティカルな二次データの両方を同時に送信及び受信することによって、リアルタイム通信を可能にする。そのような動作は、上記実施形態の動作を支援する通信ネットワーク内で利用されるプロトコルとは無関係に、一定のサービス品質（ＱｏＳ）を達成することを可能にする。
【００９６】
システム１０内では、最大セグメントサイズ（ＭＳＳ）を最適化すること、及びこれらのＭＳＳのデータコンテンツに優先順位を付けることによって、利用可能な通信ネットワークインフラストラクチャを最大限利用することが可能になる。システム１０内で動作中に提供される利点は、エネルギーの節約である。その理由は、不完全又は部分的なネットワークデータパケット２３０が送信されないためである。将来的にパケットに基づく通信は増加し、バッテリ駆動のモバイル通信デバイス内に実装されるため、そのようなエネルギーの節約は重要な利点となる。
【００９７】
システム１０は任意に、上述のように、少なくとも部分的にピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ；Ｐ２Ｐ）様式で実装されることを理解されたい。例えば、通信がピアツーピア（Ｐ２Ｐ）様式で実装される、インターネット６０などの通信ネットワークが利用される。更に、サーバ２０は追加で、又は代替として、分散様式で、例えば、自己組織的な様式で配置された複数の相互に通信するノードを用いることによって、ピアツーピア（Ｐ２Ｐ）様式で実装される。そのような実装には、それにより傍受に対するセキュリティの強化が実現されるという利点がある。このため、システム１０は任意に、第三者による妨害又は傍受が困難な分散様式で実装される。上述のように、システム１０内の通信は、例えば再生が用いられたときに、クライアント間又はサーバとクライアントとの間で発生し得る。ピアツーピア（Ｐ２Ｐ）様式の通信を対象とする様々なトポロジ、例えばリングトポロジ及び／又はスタートポロジが、任意に利用される。そのようなトポロジは、２つ以上のピアツーピアノードを利用することが好ましい。
【００９８】
上記に記載した発明の実施形態に対する変更は、添付の特許請求の範囲によって定義される発明の要旨から逸脱することのない限り可能である。本発明を説明し、また特許請求する際に用いられる「含む」又は「備える」（"ｉｎｃｌｕｄｉｎｇ"、"ｃｏｍｐｒｉｓｉｎｇ"）、「組み込む」（"ｉｎｃｏｒｐｏｒａｔｉｎｇ"）、「から成る」（"ｃｏｎｓｉｓｔｉｎｇ  ｏｆ"）、「有する」（"ｈａｖｅ"）、「である」（"ｉｓ"）等の表現は、非排他的な様式で理解されるべきことが意図されており、即ち明示されていない事項、成分又は要素が存在し得る。単数での表記は、複数にも関連するものと理解される。添付の特許請求の範囲における括弧内の数値は、請求項の理解を補助するためのものであり、それら請求項によって記載される主題を限定するものとして解釈してはならない。
【図１】
2016527579.tif 000005
【図２】
2016527579.tif 000006
【図３】
2016527579.tif 000007
【国際調査報告】
2016527579.tif 000008
2016527579.tif 000009
2016527579.tif 000010