"複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいることを特徴とする方法。請求項1記載の方法において、前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とする方法。請求項2記載の方法において、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とする方法。請求項2記載の方法において、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とする方法。複数のコンピュータの間でデータを伝送するシステムであって、前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えていることを特徴とするシステム。請求項5記載のシステムにおいて、前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とするシステム。請求項6記載のシステムにおいて、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。請求項7記載のシステムにおいて、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいることを特徴とする方法。請求項9記載の方法において、前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とする方法。請求項10記載の方法において、前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち1つであることを特徴とする方法。複数のコンピュータの間でデータを伝送するシステムであって、前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する手段と、前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する手段と、を備えていることを特徴とするシステム。請求項12記載のシステムにおいて、前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とするシステム。請求項13記載のシステムにおいて、前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち1つであることを特徴とするシステム。コンピュータの読み取り記録媒体に格納され、請求項1~4及び請求項9~11のうちいずれか1つの方法を前記コンピュータに実行させることを特徴とするコンピュータプログラム。請求項12記載のコンピュータプログラムを提供することを特徴とするコンピュータ読み取り可能な記録媒体。マルチポイントツーマルチポイント通信システムの可能性に関してはほとんど研究されてこなかった。第1態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいる方法を提供する。一態様において、前記複数のコンピュータがツリー構造を用いてリンクされている方法が提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。他の態様において、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。第2態様において、本発明は、複数のコンピュータの間でデータを伝送するシステムであって、前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えているシステムが提供される。一態様において、前記複数のコンピュータがツリー構造を用いてリンクされているシステムが提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。第3態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいる方法を提供する。第4態様において、本発明は、コンピュータの読み取り記録媒体に格納され、第1態様又は第3態様の方法を前記コンピュータに実行させるコンピュータプログラムを提供する。第5態様において、本発明は、第4態様のコンピュータプログラムを提供するコンピュータ読み取り可能な記録媒体を提供する。明細書においてデータdataという用語は、コンピュータシステムにより利用されうる任意のデータの集合を包含する広い概念を意味している。データは、例えば、マルチメディアファイル例えば、音響映像ファイル、映像ファイル、データファイルなど、電子メール、インスタントメッセージ若しくはあらゆる潜在的な情報の断片等の他の情報集合である。データは必要に応じて暗号化されてもよい。複数のコンピュータシステムの間であらゆるタイプのデータを伝送するためのシステム又は方法、特に、インターネット等の通信ネットワークを介して遠く離れて接続されている複数のコンピュータシステムの間で圧縮された又は非圧縮の映像及び音声ファイル等のマルチメディアファイルを伝送するためのシステム又は方法に関連して本発明の実施形態が記述される。ただし、本発明は記載された実施形態に限定されず、任意の数かつ任意の構成のコンピュータシステムの間でのあらゆる形式の電子ファイルの伝送に適用されうることを理解されたい。図1A及び図1Bに示されているように、それぞれが一又は複数のサーバコンピュータ102,104の形態である複数のコンピュータ装置の間でデータファイルが伝送される。コンピュータ102及び104は、ローカルネットワーク又は広域ネットワークの形態の通信ネットワーク108を通じて接続され、かつ、TCP/IPプロトコル等のパケットスイッチプロトコルを用いて通信する。コンピュータ102及び104のそれぞれは、マザーボード、CPUcentralprocessingunit110、RAMrandomaccessmemory112、ハードディスク114及びネットワーク用ハードウェア116を含む適当なコンピュータハードウェアを備えている。コンピュータ102及び104のそれぞれは、ハードウェアに加えて、オペレーティングシステム例えば、URLがhttpwwwredhatcom、httpwwwsusecom及びhttpwwwubuntucomであるウェブサイト等、多数のプロバイダからインターネット経由で取得可能なLinuxOSなどを備えている。オペレーティングシステムは、ハードディスクに収められ、ハードウェアと協働してソフトウェアアプリケーションが実行されうる環境を提供する。コンピュータ102及び104のそれぞれは、データファイルを受信かつ送信するための標準的なソフトウェア及びTCP/IPソケット等のハードウェアを有する受信モジュールを備えている。図1B及び図1Cには、本実施形態のシステムが詳細に示されている。図1Bには、ピアpeerP1~P11のバーチャル表現アバターを示す符号A1~A11とともにバーチャルクラウドの一部分が示されている。図1Cに示されているように、P1~P11は、基礎となるインターネット又はイントラネットに対するピアツーピアオーバーレイネットワークを構成する。ピアP1に対応するA1等、バーチャルクラウドのあらゆるメンバーを勘案し、臨場型の音響及び映像通信に限定されると仮定する。ジェスチャー、触覚及びユーザが創出したコンテンツ等の他のタイプのメディアの伝播は類似しているものの異なる要求があるため、本実施形態においては勘案されない。A1の視覚的範囲及び聴覚的範囲のそれぞれは、図1Bに実線及び破線のそれぞれにより示されている。対称性すなわち、バーチャルクラウドの各メンバーA1~A11が、ウォール等のバリヤが存在しない場合、相互に視聴可能であるを仮定すると、P1の音声及び映像は、聴覚的かつ視覚的場面に包含されるレンジに存在するすべてのピアに届けられる必要がある。これは、音声に関してはP2~P7、映像に関してはP1~P5及びP11に相当する。さらに、A5~A7はA1から遠く離れており、当該ピアに対してA1の音声は大きな遅れを伴って伝達され、かつ、空間的な正確性が低下した状態になる。同様に、バーチャル間隔が大きいため、A3、A5及びA11は、A1の映像について低い解像度及びフレームレートを許容することができる。しかし、このQoSQualityofServiceの変化は、バーチャルクラウドにおける現在は位置に依存しており、バーチャルスペースでアバターA1~A11が動くことにより時間経過とともに変化する。IPレイヤーにおけるネイティブマルチキャストサポートが存在しない場合、マルチポイントツーマルチポイントコンテンツの伝播のためのユニキャストモデルは図1Cに示されているように理解されうる。図1Cを乱雑にすることを回避するため、P1の映像配信のみが示されている。しかし、各ピアは、聴覚的又は視覚的範囲におけるピアの部分集合に対して音声及び映像の両方をユニキャストする必要がある。したがって、バーチャルクラウド全体に対して、平均でmDNのユニキャストフローが必要とされる。ここでmはメディアのタイプ例えば音声及び映像の数であり、Nは参加者の数であり、密度Dは書くピアノ通信範囲内に存在する参加者の平均数である。P1に着目し、かつ、rが映像のビットレートだと仮定すると、このピアノ映像を配信するために必要とされるアップロードキャパシティの平均はrDである。後述するように、映像フローの間のQoS差別化を用いることによりこの値は低減されうる。この目的で用いられる2つの可能性があるコーディング技術が、レイヤードコーディング及びマルチプルディスクリプションコーディングである。両方の場合、バーチャルワールドにおいて著しく離れているピアに対する映像フローは、図1Cに薄い矢印で示されている映像パケットの部分集合を含んでいるのみであろう。受信側において、各ピアは、聴覚的範囲及び視覚的範囲における全員から多数のユニキャストフローを受信する。平均的に、このダウンロードキャパシティは、ユニキャスト配信の場合のアップロードキャパシティと同じである。マルチキャストスキームの形式を用いることによりアップロードキャパシティの要求を低減することが考えられるが、ダウンロードキャパシティを低減させる唯一の途は前記のようにQoS差別化の採用であることに注意を要する。ネイティブマルチキャストサポートがIPレイヤーに存在する場合、P1は、アップロードキャパシティの要求を著しく低減する一の映像フローをマルチキャストフローとして送信すれば足りる。IPマルチキャストは、同一リンクを通じた重複フローを解消することにより、ネットワーク送信キャパシティの利用効率を向上させる。マルチキャストに対して最短経路ツリーが用いられることが仮定され、かつ、マルチキャストフローの複製及びルーティングに必要な付加的な処理が無視された場合、各フローが接するレイテンシlatencyはユニキャストの場合に近いものになる。ダウンロードキャパシティは同一のままに維持され、マルチキャストがQoS差別化を提供しない場合には悪化することはない。マルチキャストのためのピアツーピアモデルコンテンツ配信のためのピアツーピアマルチキャストを生じさせるためには3つの手法がある。ここでは、例として、P1の映像伝播のための単一のマルチキャストツリーが考察される。しかし、マルチポイントツーマルチポイント通信セッションは、平均的にmN個のオーバーレイマルチキャストツリーを必要とし、各ピアは、ソース、リレー又はリーフノードとして‘mDm’個のマルチキャストコネクションに参加するとともに、当該ツリーの形成及び補修のオーバーヘッドに貢献する。バーチャルクラウド及び攪拌churnピアの参加及び離脱は、マルチキャストツリーの変化に変換される。平均的に、参加者のバーチャルムーブメント又は攪拌は、再計算されかつ他のピアに通信される必要がある‘mDm’個のマルチキャストツリーに影響を及ぼす。以下の実施例を明確化するため、各参加者の視覚的範囲が3つのゾーンに分割されていると仮定する図2B参照。レシピエントがゾーン1に存在する場合、映像のための最高ビットレートが必要とされる。ゾーン2及び3は、映像送信のために段階的に低いビットレートを必要とする。これは、3つのディスクリプションを有するマルチプルディスクリプションコーディングスキーム、又は階層レイヤードコーディングが用いられることにより実現される。以降、明確化のため、連続するゾーンにおけるビットレートの減少をモデル化するため、単一のパラメータが用いられる。換言すると、レシピエントがゾーン1からゾーン2へ移動した場合又はゾーン2からゾーン3に移動した場合、映像ビットレートが因子αα≦1だけ低下する。メインプロファイルH.264ITUInternationalTelecommunicationUnionにより開発された映像コーディングスキームを用いて暗号化された多数のトーキングヘッド映像について実験結果が得られた。映像の質の変化は、α~0.65がビットレート低下率についてよい近似であることが確認された。マルチキャストツリー形成スキーム図2Aは、ピア同士の物理的間隔がコスト計量として用いられる最短経路マルチキャストツリーが生成される場合を示している。マルチキャスト用のピアツーピアアルゴリズムとして最も一般的なものが適用される。ピアは、通信遅れの直接検出、又は周知のランドマークを基準とする測定等、物理的近似性を近似する多数のアルゴリズムを利用することができる。最良の結果のため、このような情報はすべてのピアに対して有効なものとされ、かつ、矛盾がないように維持される。QoS差別化を考慮に入れるための付加的なアルゴリズムがないと、送信キャパシティの一部が無駄になる。例えば、P5がP1に対してゾーン3に存在し、ビットレートα2rの映像を要求した場合、より質の高いコンテンツを要求する他のピアに至る唯一の経路であるため、当該映像はフルレートでダウンロードされる必要がある。一方、図2Bは、バーチャルシーンにおける複数のピアの配置に基づき、アバター間のバーチャル距離が第1のコスト計量として用いてマルチキャストツリーが構築されている場合を示している。このスキームの利点は、マルチメディアコンテンツがツリーの下方に移動した場合、多くのホップが横断され、かつ、遅れが大きくなる点である。しかし、バーチャル距離も増加し、これは、知覚インパクトが弱い、より長い遅れをピアが許容することができることを意味する。例えば、A1に最も近いアバターA2及びA4は、A5への経路が3つのオーバーレイホップを有する一方経路P1-P2-P3-P5、最小の遅れを伴って音声及び映像を受け取る直接的なオーバーレイ経路P1-P2及びP1-P4。直感的に、視覚的範囲における3つのゾーンが示され、かつ、αが一のゾーンから他のゾーンへの映像の質低下に関連するビットレート低減因子を表わし、A1及びA5のバーチャル間隔のためにこの遅れのインパクトは弱くなる。映像パケットはツリーを下方に移動し、リレーされる映像レイヤー又はディスクリプションの数が減らされること等により、続くホップにおいてリレーされる情報量が減少する。このため、遅れ及びビットレートに関するQoS差別化は、オーバーヘッドがほとんどない又は皆無の当該手法の自然な結果である。当該手法の他の利点は、ツリー構造に関するトポロジー情報の変換が不要である点である。これは、全員に対する一貫したバーチャル環境を表わす状態に関する情報の変換を通じて、バーチャルトポロジーの詳細が、各ピアにとってすでに有効なものであるためである。これにより、マルチキャストツリーの構築のためのアルゴリズムの開発、及びピアの再組織化を伴わないバーチャルムーブメント又は攪拌の結果としてのリペアが促される。ルート最適化の基礎としてバーチャル間隔を用いることの鍵となる短所は、バーチャル環境に近いアバターが、物理的に遠く離れており、送信キャパシティの利用が不十分になるということである。前記例において、A1の音声及び映像が、バーチャル近接性に基づいてA2に送信され、さらにA3に送信される。P1及びP2がオーストラリアにいる一方、P2が英国にいると仮定する。A1のコンテンツがA2に届けられるためには英国に行く必要があるという事実は、当該ピアが相互通信する際の助けとはならない。しかし、A1のデータがA3に届けられるために英国から戻ってこなくてはならない点が関心事項である。図2Cに示されている第3の手法は、前記2つのスキームの欠点を補い合うハイブリッドスキームである。この場合、物理的距離は最短経路ツリーを生成するために用いられるが、アルゴリズムはバーチャルゾーンに応じた3つの連続する段階に対して適用される。前記例において、第1段階ではP1とゾーン1におけるその他のすべてのピアとの最短経路ツリーが生成される。このツリーは、第2段階ではゾーン2におけるピアを包含するように拡張される。最終段階において、ゾーン3におけるピアがツリーに参加する。この目的は、キャパシティ利用効率を過剰に犠牲にすることなく、QoS差別化スキームを改良することにある。簡単のため、マルチキャストツリー形成のための前述の3つの方法のそれぞれは、物理的仮想的及びハイブリッドモデルのそれぞれとして参照される。実験結果前記3つの方法を試験するため、3個のトランジットと、平均8個のルータをそれぞれが有する24個のスタブドメインとを有するトランジット-スタブネットワークトポロジーがシミュレーションされた。当該トポロジーにおけるノードペア間の最大遅れは約380msであり、これはネットワークのインフラストラクチャの地理的間隔を表わしている。合計5000のピアがスタブノードに無作為に連結されている。スモールバーチャルクラウドをシミュレートするため、各ランにおいて20のピアが当該プールから抽出され、200×200サイズの矩形状のバーチャル環境において対応するアバターの無作為の配置が形成される。このサイズ測定ユニットを用いて、ゾーン1、2及び3のそれぞれの距離が50、100及び150ユニットのそれぞれであると仮定される。さらに、ゾーン1、2及び3のそれぞれにおける許容レイテンシは、100、200及び400msのそれぞれである。キーとなる特性を変化させる2つのパラメータが用いられる。第1パラメータは前記のように定義されたαである。このパラメータは乗算因子であり、これによりゾーン2及び3について映像ビットレートが低減されるのはもちろんのこと、使用されている映像コーディングの種類及び要求されている映像表現の質に依存する。当該パラメータを[0.1,1.0]の範囲で変化させることにより、ビットレートに関するQoS差別化の効率がモデル化される。すなわち、α=1.0は、通信ゾーンを横断するビットレート差別化が不可能であることを表わし、α=0.1は、ゾーン2及び3を横断する際に映像ビットレートが1桁又は2桁だけ低下することを表わしている。βと記載される第2パラメータは、ネットワークの地理的スケールを変化させる。これは、各ネットワークリンクの遅れにこの因子を乗じることにより実現される。前述のように、本来のトポロジーにおけるノードペア間の最大遅れは約380msである。[0.1,5.0]の範囲でβを変化させることにより、標準的な街又は州に相応するスケールのネットワークから地球ネットワークに至るまでシミュレーションが可能になる。明らかに、ラージスケールネットワークにおいてレイテンシバイオレーションの蓋然性が高くなり、かつ、遅れ制御に関するあらゆる不適当な設計の影響がより顕在化される。次の結果を得るため、各トポロジーが20個の異なるノードセットを有し、かつ、各ノードセットが20個のアバターを包含するような、10個の異なる物理的ネットワークトポロジーが形成される。したがって、各グラフにおける点は、200回のシミュレーション実施の結果例えば平均値である。送信効率結果の第1集合は、ピアのアップロードキャパシティの要求及びマルチポイントツーマルチポイント映像の配布コストを低下させる際の3個のマルチキャストスキーム物理的仮想的及びハイブリッドの効率を示している。図3Aにおいて正規化された合計アップロードキャパシティコストが縦軸に示されている。このコストは、図1Cに示されているユニキャストスキームに関して正規化されている。横軸はパラメータαの範囲0.1~1.0を示している。このグラフから、ピアツーピアマルチキャストスキームが、ユニキャストの場合と比較して、合計アップロードキャパシティのピアによる利用効率をなんら改善できていないことは明らかである。ビットレートの差別化の可能性がある場合α<1、物理的マルチキャストのパフォーマンスは、ユニキャストよりもかなり劣る。この結果は次のように説明できる。ソースからの音楽ファイルのダウンロード等、単一のマルチキャストに関して、ピアツーピアのマルチキャストは、ソースへのアップロードコストを低下させ、かつ、当該ロードを参加しているすべてのピアに対して配信するのに有用である。この場合でも、合計アップロードコストは同じままであるが、ピアが当該合計のシェアを占めることによりスケーラビリティが向上する。マルチポイントツーマルチポイントコンテンツ配信シナリオに関して、各ピアはソースであるのみならず、他のマルチキャストツリーのリレーノードでもある。各マルチキャストツリーは、そのソースのアップロードキャパシティを分配するが、全体的に合計は同じままであり、複数のピアの平均アップロードコストは変化しない。われわれのモデルにはパケットサイズの細かさに関して仮定はなされていないので、事実、配布のためにコンテンツを小さいブロック例えばビットトレントに分割することを含むピアツーピアマルチキャストスキームについてこの結論は正しい。物理的マルチキャスト手法は、前述のようにQoS差別化に際しての当該スキームの非効率性のため、α<1.0のユニキャストと比較して劣る図2A参照。アップロードキャパシティ基準に関するピアツーピアマルチキャストの唯一の長所は、合計は同じであるにもかかわらず、複数のピアの間でのロード配信が、マルチキャストツリーの形成方法と、当該ツリーにおける特定ピアの中心性centralityに依存することである。シミュレーションにおいて、ユニキャストアップロードコストは多少均一に配分される一方、他のスキームではピアの間で顕著な相違がある。賢明な設計により、特にピアの間に不均質が存在する場合には当該設計が利点となる。例えば、いくつかのピアが、スーパーピアの役割を果たし、能力が劣る他のピアのロードを低下させてもよい。図3Bにおけるグラフは、ネットワークインフラストラクチャにより生じる合計送信コストを示している。これは、リンクコスト本実施形態では距離に比例するが掛け合わせられるのに用いられるビットレートとして定義されている。物理的及びハイブリッド手法の両方が、より少数の高コストリンクの使用により、合計送信コストを適度に低下させるという結果をもたらすことがわかる。この利益は、ビットレートに関するQoS差別化が不可能である場合により顕著になる。差別化が増大した場合、ユニキャストのパフォーマンスはマルチキャストに著しく近接することになる。遅れバイオレーション先に議論したように、許容通信レイテンシはバーチャル距離に依存する。ここで述べるモデルにおいて、3つのゾーンが使用され、かつ、許容最大遅れが100、200及び400msのそれぞれに設定されている。しかし、本考察の結論を一般化するため、図4A及び図4Bの横軸に示されているように、ネットワークの地理的スケールが広範囲にわたって変更される。図4Aは、許容レイテンシを超えている相互通信コネクションの様子を示している。通信コネクションは、相互に相手方の視覚的範囲に存在する2個のアバターのあらゆるアクティブマルチメディア交換を包含する。予想通り、ネットワークサイズパラメータβを増加させることにより、この数は増加する。レイテンシの最小化のため、最善の移送方法は、映像配信のために最短経路ルート及び単一のオーバーレイホップが採用されるユニキャストスキームである。物理的及びハイブリッドスキームは段階的にパフォーマンスが悪く、仮想的スキームはパフォーマンスが最悪である。レイテンシバイオレーションの程度を評価することも重要である。そのために図4Bには計量の1つが例示されている。この計量は、許容レベルに関して正規化された超過レイテンシの合計を表わしている。隔離に際して、この計量は物理的に直感的な尺度に変換されず、対比ツールとして役立つ。図4Bに示されているように、さまざまなスキームの間のギャップは、レイテンシ制御に関する相対的なパフォーマンスを示している。結論チャット及び電子メール等の現在のツールに加えて、バーチャルクラウドのメンバー同士の自然な通信に対する必要性は、ユーザがより相関的かつ現実的なマルチメディア経験を望むにつれてますます増大しているようである。マルチポイントツーマルチポイントのマルチメディア通信サービスに対する初期の多大な要望がある。ピアツーピアマルチキャストは、ポピュラーなコンテンツ伝送技術である。しかし、マルチポイントツーマルチポイントマルチメディア通信の伝送のための当該スキームの利益は限界である。大半の場合、より単純なユニキャスト方法はオーバーレイマルチキャストと同等であり、さらには優れていることも多い。マルチキャストのためのIPレイヤーサポートが欠如している場合、関心範囲制御及びQoS差別化は、サービス伝送のキャパシティ要求を低減するのに有効なツールである。オーバーレイマルチキャストの1つの利益は、ピアの間の不均質性の利益を享受するような不均質な方法によりピアの間のアップロードコストを分配することができることにある。これらの場合、マルチキャストスキームは、増加したレイテンシのコスト及びツリーを成立させかつ補修するためのより複雑なコントロールシステムにおいていくつかの利益をもたらす。換言すると、技術の組み合わせを用いること及び前記ハイブリッドモデルを用いることにより、接続された複数のコンピュータシステム間のより効率的なデータ伝送方法論が確立される。当該方法論は、ソーシャルネットワーク及び複数のユーザのバーチャル環境に関する発展中の市場における用途を見出す。他の変更された実施形態本発明の広い概念から乖離することなく、前記実施形態に対してさらなるサービスが追加されてもよい。例えば、ソフトウェアアプリケーションが、他のコンピュータシステム図示略における他のソフトウェアアプリケーションと相互作用するように構成されていてもよい。実施形態は、携帯電話機を含むモバイルコンピュータデバイスに適用されてもよい。このような他の実施形態は当業者の創作能力の範囲内の事項である。一実施形態において、ソフトウェアアプリケーションは、一又は複数の中央サーバにおいて動作するように構成されているアプリケーションであってもよい。アプリケーションは、インターネット等の公的又は私的ネットワークを通じて、適当な遠隔端末からアクセスされてもよい。ソフトウェアアプリケーションが他のコンピュータシステム及びデータベースのうち一方又は両方にインターフェイスしている場合、インターネット、占有ネットワーク例えば、組織の異なるオフィス間の私的な接続、802.11標準ネットワーク等のワイヤレスネットワーク、又は限定されないものの、電話回線、GSM、CDMA、EDGE若しくは3Gモバイル電話通信ネットワーク、又はマイクロ波リンクを含む電話通信ネットワークを含む適当なネットワークを通じてデータが通信されてもよい。前記実施形態が、開発者による利用のためにAPIapplicationprogramminginterfaceを介して又はAPIとして改良されてもよいこと、又は他のソフトウェアアプリケーションにおけるコードとして改良されてもよいことが理解されるはずである。一般に、ソフトウェアアプリケーションが、特定の機能を発揮する又は支援するようなルーティン、プログラム、オブジェクト、コンポーネント及びデータファイルを有しているので、ソフトウェアアプリケーションが多数のルーティン、オブジェクト及びコンポーネントに分配されるが、前記実施形態及び本発明の概念と同等の機能性を発揮することが理解されるはずである。当該変形及び改良は当業者の通常の創作能力の範囲内のことである。前記実施形態に関する記載は、当業者が本発明を実施又は使用するために十分なものである。記載された特定の実施形態に関して本発明が説明されたが、当業者にとって当該実施形態にさまざまな改良を加えることは明確なことであり、ここで定義された包括的原則は、本発明の思想又は範囲から乖離することなく、他の実施形態に対して適用されうる。したがって、本実施形態は、すべてに関して例示的なものであり、かつ、限定的ではないと考えられるべきである。"