JP4690387B2 - 好ましくはストリーミング・システムに適用される配布方法 - Google Patents

Description

本発明は、請求項１によるネットワークに関する。

例えばインターネットを介したビデオおよび／または音声ストリーミングなどに関する問題は、一般の送信システムがかなり複雑な制御およびデータ帯域幅を必要とすることである。

ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｈｅｏｒｙ ｐａｐｅｒ"Ａ Ｌｉｎｅａｒ Ｔｉｍｅ Ｅｒａｓｕｒｅ−Ｒｅｓｉｌｉｅｎｔ Ｃｏｄｅ Ｗｉｔｈ Ｎｅａｒｌｙ Ｏｐｔｉｍａｌ Ｒｅｃｏｖｅｒｙ"ｂｙ Ａｌｏｎ ａｎｄ Ｌｕｂｙ，１９９６ Ｉｎｔｅｒｎｅｔ Ｓｏｃｉｅｔｙ ＲＦＣ−ｄｏｃｕｍｅｎｔ ３４５３"Ｔｈｅ Ｕｓｅ ｏｆ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ） ｉｎ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ"ｂｙ Ｌｕｂｙ ｅｔ ａｌ，２００２ 米国特許第６，３０７，４８７号 米国特許第６，３２０，５２０号 米国特許第６，３７３，４０６号 米国特許第６，４１１，２２３号 米国特許第６，４８６，８０３号 米国特許第６，６１４，３６６号

本発明は、少なくとも１つのデータ・ライブ・ストリーミング・ブロードキャスタＬＳＢおよび少なくとも２つのライブ・ストリーミング受信側ＬＳＲを含むデータ・ライブ・ストリーミング・システムであって、
前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲがピアツーピア・ストリーミング・ネットワークの少なくとも一部分を形成し、
前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲがそれぞれ、前記ピアツーピア・ストリーミング・ネットワークの他のライブ・ストリーミング受信側ＬＳＲへのピアツーピア・ストリーミングを生成する手段を含み、他のストリーミング受信側ＬＳＲへの前記ピアツーピア・ストリーミングが、前記少なくとも１つのライブ・ストリーミング・ブロードキャスタＬＳＢからのデータの損失耐性のあるコード表現（ｌｏｓｓ ｒｅｓｉｌｉｅｎｔ ｃｏｄｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を含む、データ・ライブ・ストリーミング・システムに関する。

一般にコード・セグメントの形の損失耐性のあるコード表現の一般的な手法によれば、これらのコードは、広義には、入力データを、主として任意に選択されたコード・セグメントの数が完全な入力データを再現するのに十分であり得る、損失耐性のあるコードのコード・セグメント数に変調することができるコードを指す。この数は、例えばリードソロモンベースのコードを使用する場合、予め定められた数に固定されてもよく、あるいは、例えばＬＴベースのコードと関連する何らかの所望の閾値に対応する数としてもよい。一般に、入力データの再現、すなわち復号化にそれ以上のコード・セグメントが当然として適用され得ることが実情であるが、コード・セグメントのこうした使用は一般に不必要とみなされる。

一般に、データ・ライブ・ストリーミング・システムは、流されたデータがある遅延、好ましくは非常に低い遅延と同期されるように、データをいくつかの受信側に流すシステムを指す。同期は、例えば音声および／またはビデオの従来の一斉送信のものと似た性質の、例えばインターネットや例えばイントラネットなどのデータ送信を介した何人かのユーザへの一斉送信を容易にする。

本発明によれば、ピアツーピア・ネットワークは、広義には、全体的なシステム機能に貢献することによってすべてのピアが参加するピアの任意のネットワークとして理解される。したがって、本発明の意味でのピアツーピア・ネットワークは、例えばグリッド技術ベースのネットワーク、個々のピアがどれほどでもシステム機能に貢献するサーバベースのネットワーク、個々のピアがシステム機能に等しく貢献するネットワークなどを含む。

本発明のデータ・ライブ・ストリーミング・システムは、実際には、５，５．０００、１．０００．０００、５００．０００．０００など、任意の数のライブ・ストリーミング受信側ＬＳＲとともに使用することができる。より多くの受信側にサービスが提供されるほど、利点が際だつようになるが、システムは、５、１０、２０人の参加者のテレビ電話会議にも、３０．０００、３００．０００、３．０００．０００人の視聴者がいる生のＴＶ番組の場合にも、同様に使用することができる。

本発明によって使用される符号化アルゴリズムは、消去コードまたは損失耐性のあるコードとも呼ばれる任意の種類の順方向誤り訂正符号に基づいてもよく、またはそのうちの必ずしも固定されていないあるサイズの実質的に任意のサブセットのみが入力を再現できるように必要とされる、入力に基づいていくつかのパケットの生成を可能にする他の任意のタイプのコードに基づいてもよい。こうしたコードには、例えばリードソロモンベースのコード、トルネードベースのコード、ＬＴベースのコード、Ｒａｐｔｏｒコードなどがある。その他の適したコードのタイプは、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｈｅｏｒｙ ｐａｐｅｒ“Ａ Ｌｉｎｅａｒ Ｔｉｍｅ Ｅｒａｓｕｒｅ−Ｒｅｓｉｌｉｅｎｔ Ｃｏｄｅ Ｗｉｔｈ Ｎｅａｒｌｙ Ｏｐｔｉｍａｌ Ｒｅｃｏｖｅｒｙ”ｂｙ Ａｌｏｎ ａｎｄ Ｌｕｂｙ，１９９６、Ｉｎｔｅｒｎｅｔ Ｓｏｃｉｅｔｙ ＲＦＣ−ｄｏｃｕｍｅｎｔ ３４５３“Ｔｈｅ Ｕｓｅ ｏｆ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ） ｉｎ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ”ｂｙ Ｌｕｂｙ ｅｔ ａｌ，２００２、およびＤｉｇｉｔａｌ Ｆｏｕｎｔａｉｎ，Ｉｎｃ．の特許、米国特許第６，３０７，４８７号、米国特許第６，３２０，５２０号、米国特許第６，３７３，４０６号、米国特許第６，４１１，２２３号、米国特許第６，４８６，８０３号、および米国特許第６，６１４，３６６号などの文献に記載されており、参照により本明細書に組み込まれる。

さらに、本発明によれば、ライブ・ストリーミングという用語は広義に理解されることに留意されたい。したがって、これは、基本的に、少なくとも次の２つの状況、例えば、生のＴＶ番組、サッカーの試合やデータ取得装置からデータを流すときなど、情報が流されるのと実質的に同時に情報が利用可能になるが、必ずしも受信側によって同時にモニタに表示されたり、使用されたりするとは限らず、すなわち将来使用するためにその情報を受信側の場所に格納し、および／またはすぐに表示し、したがってストリーミングが情報の作成に実質的に同期されることを得る第１のセットアップ、およびブロードキャスタが、映画、音声ファイル、コンピュータ・プログラムなど、格納されている情報にアクセスでき、情報が受信側によって表示または使用されるのと実質的に一致して流される、すなわちストリーミングが情報の実際の使用に実質的に同期される第２のセットアップに適用され得る。これらのセットアップの間に、またはこれらのセットアップに加えて、ライブ・イベントのタイムシフト・ストリーミングなどさらにいくつかの可能性がある。本発明によるライブ・ストリーミングの用語の範囲内のその他のセットアップは、いくつかの受信側が、ライブ・イベント、映画、データベース・アップデート、コンピュータ・プログラムなど、ストリームの内容とは無関係に、実質的に同期してストリームを受信することを含む。

本発明の一実施形態に従って、前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲのそれぞれが、他のストリーミング受信側へのピアツーピア・ストリーミングを生成する前記手段によって入力データＩの少なくとも１つの一意の部分的な符号化表現（ｕｎｉｑｕｅ ｐａｒｔｉａｌ ｅｎｃｏｄｅｄ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）ＵＰＲを提供する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記一意の部分的な符号化表現ＵＰＲのうちの少なくとも２つがデータの完全な表現を形成する場合、本発明の有利な一実施形態が得られている。

本発明によれば、様々な損失耐性のあるコード化技術を適用することができ、さらに、技術の様々な寸法係数を適用することができる。したがって、入力データの符号化は、一般に、選択された適した最低数のコード・セグメントによって表されるように寸法設定することができる。例えば、ブロードキャスタを元とするデータである入力データを、例えば最低１００個のコード・セグメントによって表すことができる。一般に、こうした場合、コード・セグメントの受信側が生成されたコード・セグメントのサブセット、すなわち最低数のサブセットのみを選択し、使用できるように、選択された最低数のコード・セグメントより多くのコード・セグメントが生成されなければならない。このように、コード・セグメントの損失、またはある所望のコードを選択または取得する自由を得ることができる。最低数は、特定の数、または符号化されたコード・セグメントの数に関連する割合の両方を指し得る。したがって、損失耐性のあるコード化技術は、大量のコード・セグメントの生成を容易にするが、生成された損失耐性のあるセグメントの数は、好ましい実施形態では、例えば６４個の損失耐性のあるセグメントから完全な表現が確立され得るセットアップにおいて、参加しているピア当たり、例えば８個である。しかし、特定の実施形態の特定の例での損失耐性のあるセグメントの好ましい数は、データ・サイズ、ネットワーク・タイプ、ダウンロード、アップロード、および一般にピアごとに異なる個々のピアの処理能力、好ましいデータ・レートなど、いくつかのパラメータにかなり依存する。

本発明の一実施形態に従って、他のストリーミング受信側へのピアツーピア・ストリーミングを生成する前記手段が、実質的に、入力データＩのＭ個の一意の部分的な符号化表現ＵＰＲを提供し、ライブ・ストリーミング・ブロードキャスタＬＳＢから流されたデータがＮ個の一意の部分的な符号化表現ＵＰＲのサブセットによって完全に、または概ね表される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、個数Ｍが実質的にライブ・ストリーミング受信側ＬＳＲの数に対応する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、少なくとも１つのライブ・ストリーミング・ブロードキャスタＬＳＢから流されたデータが、リードソロモンベースの損失耐性のあるコード・セグメントによって符号化されるＮ個の一意の部分的な符号化表現ＵＰＲのサブセットによって完全に表される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、ライブ・ストリーミング・ブロードキャスタＬＳＢから流されたデータが、ＬＴベースの損失耐性のあるコード・セグメントによって符号化されるＮ個の一意の部分的な符号化表現ＵＰＲのサブセットによって概ね表される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲのうちの少なくとも１つが、データのＮ個の一意の部分的な符号化表現ＵＰＲを復号することによって、前記ライブ・ストリーミング・ブロードキャスタＬＳＢからの符号化データを再生成し、前記Ｎ個の一意の部分的な符号化表現ＵＰＲのうちの少なくとも１つ、好ましくは少なくとも１０個が他のライブ・ストリーミング受信側ＬＳＲによって生成される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、データの前記損失耐性のあるコード表現がフレームで提供される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記フレームが、前記ライブ・ストリーミング・ブロードキャスタＬＳＢによって実質的に生成され、連続して送信されるタイム・フレームを含む場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記少なくとも１つのライブ・ストリーミング・ブロードキャスタＬＳＢへのデータのストリーミングが連続するフレームで構築され、実質的に、各フレームが、前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲへのデータ表現の初期送信によって開始され、前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲが前記データ表現またはその派生物を、損失耐性のあるコード・セグメントとして他のライブ・ストリーミング受信側ＬＳＲに流し、受信側が、Ｎ個の一意の損失耐性のあるコード・セグメントを集め、前記少なくとも１つのライブ・ストリーミング・ブロードキャスタＬＳＢから送信された前記フレームを、ライブ・ストリーミング信号として再生成する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ピアツーピアがグリッドベースのシステムを含む場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記データがビデオおよび／または音声ストリームを含む場合、本発明の有利な一実施形態が得られている。

本発明は、
少なくとも１つの入力データＩブロードキャスタＩＢと、
入力代表データＩＲＤを前記少なくとも１つの入力ブロードキャスタＩＢから入力データＩの複数のＭ個の一意の部分的な符号化表現ＵＰＲに変換する複数のピアＰとを含むネットワークであって、
前記Ｍ個の一意の部分的な符号化表現の複数のコード・サブセットＷ１，Ｗ２，Ｗ３，．．が前記入力データＩの異なるＮ個の一意の部分的な符号化表現ＵＰＲを含み、各サブセットＷ１，Ｗ２，Ｗ３，．．が前記入力データＩを表し、ＮがＭ―１未満である、ネットワークにさらに関する。

本発明によれば、複数のコード・サブセットは、一般に非常に大きい数を含み、ほとんど一般的に、こうしたサブセットは、一般に、使用可能なＭ個の異なる一意の部分的な符号化表現ＵＰＲのいずれの中から選択することができる。

ネットワークがデータの全体的な所望の非中央の符号化／復号化を行うように構成されていないピアをさらに含み得ることに留意されたい。

さらに、Ｎ個の一意の部分的な表現とは、正しくは最低数の表現を指し、さらに、そのように望まれる場合、一般に重複した表現がサブセットに含まれてもよいことに留意されたい。

本発明の好ましい実施形態によれば、一意の部分的な符号化表現は、表現が一意のキーによって符号化されるという意味で一意である。

当然、時として現在適用されているコード化の定理にもよるが、生成された部分的な符号化表現の任意のユーザが実際に、必要な符号化情報を、情報の重複がほとんどなく、または好ましくは情報の重複無しで確実に受信するために、一意の部分的な符号化表現の配布を、非常にわずかの中央制御によって、または中央制御無しでさえ行うことができることは、本発明のかなり有利な特徴である。言い換えれば、少なくとも１つのコード・サブセットを集めようとしている考え得るユーザは、実際に、最終的にＮ個の、または少なくとも１つの主要な任意の部分的な符号化表現を集めることを選択し、次いで適用されたコード化の定理に従って復号することによって、完全な入力が確立され得ることを認識することができる。この特徴は、使用可能なすべての部分的な符号化表現が一意である、すなわち少なくとも一意のキーによって生成されたという事実に基づいている。したがって、入力データのリードソロモンベースの符号化の場合、特定の数、Ｎ個の一意の任意の部分的な符号化表現が集められ、これによって完全な入力データの再現を可能にすることができる。異なるピアが重複した符号化表現を生成した場合はそうではない。

しかし、本発明に従ってサブネットワークが個々に動作するように、いくつかのネットワークを結合することができることに留意されたい。このように、サブネットワーク間のこうした部分的な符号化表現の任意の通信を阻止することによって、部分的な符号化表現の一意性を確実にすることができる。サブネットワークは、例えば、インターネットの地理的に決定された部分を含み得る。

本発明によって使用される符号化アルゴリズムは、消去コードまたは損失耐性のあるコードとも呼ばれる任意の種類の順方向誤り訂正符号に基づいてもよく、またはそのうちの必ずしも固定されていないあるサイズの実質的に任意のサブセットのみが入力を再現できるように必要とされる、入力に基づいていくつかのパケットの生成を可能にする他の任意のタイプのコードに基づいてもよい。こうしたコードには、例えばリードソロモンベースのコード、トルネードベースのコード、ＬＴベースのコード、Ｒａｐｔｏｒコードなどがある。その他の適したコードのタイプは、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｈｅｏｒｙ ｐａｐｅｒ“Ａ Ｌｉｎｅａｒ Ｔｉｍｅ Ｅｒａｓｕｒｅ−Ｒｅｓｉｌｉｅｎｔ Ｃｏｄｅ Ｗｉｔｈ Ｎｅａｒｌｙ Ｏｐｔｉｍａｌ Ｒｅｃｏｖｅｒｙ”ｂｙ Ａｌｏｎ ａｎｄ Ｌｕｂｙ，１９９６、Ｉｎｔｅｒｎｅｔ Ｓｏｃｉｅｔｙ ＲＦＣ−ｄｏｃｕｍｅｎｔ ３４５３“Ｔｈｅ Ｕｓｅ ｏｆ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ） ｉｎ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ”ｂｙ Ｌｕｂｙ ｅｔ ａｌ，２００２、およびＤｉｇｉｔａｌ Ｆｏｕｎｔａｉｎ，Ｉｎｃ．の特許、米国特許第６，３０７，４８７号、米国特許第６，３２０，５２０号、米国特許第６，３７３，４０６号、米国特許第６，４１１，２２３号、米国特許第６，４８６，８０３号、および米国特許第６，６１４，３６６号などの文献に記載されており、参照により本明細書に組み込まれる。

本発明の一実施形態に従って、前記入力ピアのそれぞれが入力データＩの前記Ｍ個の一意の部分的な符号化表現ＵＰＲのうちの１つを生成する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記コード・サブセットＷ１，Ｗ２，Ｗ３．．のうちの少なくとも１つ、好ましくはすべてが前記入力データＩの符号化バージョンを表す場合、本発明の有利な一実施形態が得られている。

本発明によれば、許可されたユーザにより、または少なくとも暗黙的に、まずは、プッシュ技術またはプル技術によってコード・サブセットを集め、次いで最終的にコード・サブセットを復号することによって、好ましくは完全な入力データが復号可能でなければならない。ユーザは、入力データの復号化バージョンまたは表現がいわゆるユーザにとって理解できるような程度に情報を実際に復号するために、例えば、符号化についての、または少なくとも促進された復号化についての十分な情報を有しているピアとすることができる。一般に、適したコード構造は、符号化された入力データを完全に復号化し得ることを容易にする。

本発明の一実施形態に従って、前記コード・サブセットＷ１，Ｗ２，Ｗ３．．のうちの少なくとも１つがＬＴベースのコードによって符号化される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って適用可能ないくつかの符号化技術のうちの１つは、いわゆるＬＴコードまたはトルネード・コードである。コード・サブセットがこうしたコード化技術によって符号化された一意の部分的な符号化表現を含む場合、こうしたコードの部分的な表現の復号は、一般に、サブセットがコード化された入力データより多くのデータ・コンテンツに対応する符号化されたデータ・パケットを含むことを必要とする。コード・サブセットの必要な使用可能なデータ・パケットの範囲は、少なくともコード・サブセットが一意の部分的な符号化表現である限り、主に、選択され適用されたコード化方法に関連付けられているいわゆる閾値に依存する。

本発明の一実施形態に従って、前記コード・サブセットＷ１，Ｗ２，Ｗ３．．のうちの少なくとも１つがリードソロモンベースのコードによって符号化される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ネットワークが、前記サブセットＷ１，Ｗ２，Ｗ３．．のうちの少なくとも１つを集め、前記サブセットＷ１，Ｗ２，Ｗ３．．のうちの少なくとも１つを、符号化データに対応するデータに復号することができる、少なくとも２つの受信側ピアＲＰを含む場合、本発明の有利な一実施形態が得られている。

本発明によれば、集められたコード・サブセットは、ユーザ、すなわち符号化された入力データを再生成するための受信側ピアＲＰによって有利に集めることができる。言い換えれば、ブロードキャスタから受信側ピアへの入力データの送信が得られ、入力ブロードキャスタ以外の複数のピアによって実行される部分的なデータ処理によって送信が得られることに留意されたい。

本発明の一実施形態に従って、前記少なくとも２つの受信側ピアＲＰによって行われる収集が、他のピアのうちの少なくとも１つ、好ましくは複数のピアへの要求に基づいて行われる場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記少なくとも２つの受信側ピアＲＰによって行われる収集が、他のピアのうちの少なくとも１つ、好ましくは複数のピアによって行われるプッシュ送信に基づいて行われる場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ピアＰのうちの少なくとも１つが受信側ピアＲＰを形成する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記入力代表データＩＲＤが少なくとも２つの中間ピアＩＰによって少なくとも部分的に確立される場合、本発明の有利な一実施形態が得られる。

本発明によれば、少なくとも２つの中間ピアＩＰだけによって、または入力ブロードキャスタが一部の用途において入力データの前符号化またはある種の準備を有利に行い得るという意味で入力データ・ブロードキャスタとともに、入力代表データが有利に提供され得る。あるいは、符号化のすべてまたは大部分が中間ピアによって配布され、実行され得る。

本発明の一実施形態に従って、前記中間ピアＩＰが入力代表データＩＲＤを確立するように構成されている中間処理工程をさらに含む場合、本発明の有利な一実施形態が得られている。

したがって、有利には、入力代表データを一意の部分的な符号化表現に変換する前のある１段階またはいくつかの段階で、入力代表データの処理および確立のために、中間ピアが提供されてもよい。こうした処理には、例えば、符号化／復号化、データの乗算、適した経路指定ルーチンによる入力代表データの経路指定などがある。

本発明の一実施形態に従って、前記ピアＰのうちの少なくとも１つが中間ピアＩＰを形成する場合、本発明の有利な一実施形態が得られている。

本発明の好ましい実施形態によれば、いくつかのピアは、有利には、すなわちいわゆる中間ピアとして働き、同時に入力代表データを少なくとも１つの入力ブロードキャスタから入力データＩの複数のＭ個の一意の部分的な符号化表現ＵＰＲに変換するピアのうちの１つとしても働く、入力代表データの処理の両方に参加してもよい。言い換えれば、一部のピアは、同時に２つのタイプのピアとして働くことができる。当然、こうした二重の機能は、入力ブロードキャスタからピアへのデータの有効な移送が提供されるように、必要なコード処理の適した並列または直列構造化によって容易にする必要がある。

本発明の一実施形態に従って、ピアＰの総数が５個より多く、好ましくは５０個より多く、さらに好ましくは２００個より多く、中間ピアＩＰの数がピアの総数の１／５から１／１００の間、好ましくはピアの総数の１／２５から１／５０の間である場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態によれば、中間ピアの数は、所望のデータ配布を行うように、有利に最適化されるべきである。

しかし、本発明によれば、中間ピアの数は、２つからピアの総数までのどれかとすることができることに留意されたい。中間ピアの選択は、例えば、個々のピアのダウンロードおよびアップロードの能力、およびその一部がストリーミング・セッション中に変わる可能性さえある他のパラメータに依存するため、一般に、特定の実施形態の特定の場合にかなり依存する。

本発明の一実施形態に従って、前記入力代表データＩＲＤが前記ブロードキャスタＩＢから少なくとも２つの中間ピアＩＰ、好ましくは少なくとも４つの中間ピアＩＰに送信される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態によれば、データは、入力ブロードキャスタから少なくとも２つの、好ましくは少なくとも４つの中間ピアに送信され得る。このように、入力ブロードキャスタから個々のデータ要求側ピアへのデータの伝送は、入力要求側ピアといくつかのデータ・プロバイダ、すなわち中間ピアおよび任意選択でその他のピアとの間の送信として配布されてもよい。

入力代表データの受信側が実際にデータを必要としていることが確認される限り、データのプッシュもある程度までシステムによって促進することができるという意味で、データ要求側ピアの理解は、必ずしも絶対にデータ・プル機能に低減されるわけではないことに留意されたい。

本発明の一実施形態に従って、前記少なくとも２つの中間ピアＩＰが前記入力データＩのみの部分的な表現を受信する場合、本発明の有利な一実施形態が得られている。

この原理は、基本的に１対１のデータ送信との関連で示されているが、１対多、あるいは多対多の送信でさえ、本発明の範囲内で適用することができる。

本発明の一実施形態によれば、複数のサブセットは、一般に、必要なＮ個の一意の部分的な符号化表現が、少なくともこれらの部分的な符号化表現の比較的大きいグループ内で、またはそれらのいずれかによって結合されてもよいことを反映している。したがって、すべての部分的な表現が一意であることが好ましいが、潜在的な「ユーザ」がＮ個の一意の異なる部分的な表現を集めることができることが確認される限り、提供された部分的な表現のある程度の制御またはグループ化で間に合う場合がある。

したがって、例えば部分的な符号化表現のリードソロモンの符号化を適用するときの重要な特徴は、受信側が入力の全説明を取得する場合、入力情報を再生成／復号するだけであることである。他のタイプのコードを適用する場合、一般に、符号化入力データの１００％より大きい、何らかの確率の閾値が得られなければならない。

本発明の一実施形態に従って、一意の部分的な符号化表現ＵＰＲが異なる複数のピアによって生成される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、異なるピアによって部分的な符号化表現ＵＰＲを生成することによって一意の部分的な符号化表現ＵＰＲの一意性が確実にされる場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、少なくとも１つのピアＰが、プル・プロセスによって、入力代表データＩＲＤを集め、少なくとも１つの一意の部分的な符号化表現に変換する場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、少なくとも１つのピアＰが、プッシュ・プロセスによって、入力代表データＩＲＤを集め、少なくとも１つの一意の部分的な符号化表現に変換する場合、本発明の有利な一実施形態が得られている。

本発明によれば、ピアでのサブセットの収集は、プッシュ・プロセスおよびプル・プロセスによって行うことができる。言い換えれば、ピアは、自分自身の動きで、所望のコード・サブセットを集めることを決めるか、代わりに、使用可能なシステムが必要なコード・サブセットを下流にプッシュすることができる。本発明の好ましい実施形態では、個々のピアがプル・プロセスとしてデータを集める、すなわち、データが必要なときに他のピアに積極的に要求する。

本発明の一実施形態に従って、前記入力データがリアルタイム・ベースで少なくとも１つの入力データ・ブロードキャスタＩＢから送信される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記入力データＩがフレームでリアルタイム・ベースで少なくとも１つの入力データ・ブロードキャスタＩＢから送信される場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ネットワークがビデオ・ストリーミング・ネットワークである場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ネットワークが要求に応じてビデオ・ストリーミングを行っている場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ネットワークがライブビデオ・ストリーミングを行っている場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ネットワークがインターネットによって形成され、前記ピアＰがインターネットと通信するコンピュータを含む場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記ピアの少なくとも１つが、他のピアによって生成された入力データＩの部分的な符号化表現ＵＰＲを収集および／または使用することなく、入力代表データＩＲＤを、入力データＩの少なくとも１つの一意の部分的な符号化表現ＵＰＲに変換するコンピュータを含む場合、本発明の有利な一実施形態が得られている。

有利には、一部のピアは、単に、他のピアによって生成された部分的な符号化表現ＵＰＲを使用することなく、入力データＩの部分的な符号化表現ＵＰＲの非中央プロデューサとして働くことができるだけである。

本発明の一実施形態に従って、前記ピアの少なくとも１つが、
・ピアが少なくとも１つの部分的な符号化表現ＵＰＲを生成し、少なくとも１つのコード・サブセットＷ１，Ｗ２，Ｗ３，．．を取得するために他のピアによって生成された部分的な符号化表現を集め、少なくとも１つのコード・サブセットＷ１，Ｗ２，Ｗ３，．．を復号する少なくとも１つのモードと、
・ピアが単に、または主に少なくとも１つの部分的な符号化表現ＵＰＲのプロデューサとして働く少なくとも１つのアイドル・モードと
の間の切り替えを行うことができる場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、ピアが暗黙的または明示的に入力データＩで定義される場合、本発明の有利な一実施形態が得られている。

本発明の好ましい一実施形態によれば、ネットワークの一部分を形成する予定のピアは、例えば変換するピアおよび／または中間ピアおよび／または受信側ピアとして、符号化される／流されるデータで定義することができる。この特徴は、あるピアからもう一方のピアへの有利で非常に便利なデータの交換、特に、受信側ピアによる部分的な符号化表現の有利な取り出しを容易にする。

本発明の一実施形態に従って、符号化入力データＩがデータを定義するピアに関連付けられる場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記一意の部分的な符号化表現ＵＰＲが損失耐性のあるコードを含む場合、本発明の有利な一実施形態が得られている。

本発明の一実施形態に従って、前記入力データがビデオ・ストリーミングを含み、
前記ブロードキャスタＩＢがビデオ・ストリーミング・ブロードキャスタを含み、
前記複数のピアＰのうちの少なくとも２つがビデオ・ストリームの受信側を含む場合、本発明の有利な一実施形態が得られている。

本発明は、さらに、少なくとも１つのデータ・ライブ・ストリーミング・ブロードキャスタＬＳＢおよび少なくとも２つのライブ・ストリーミング受信側ＬＳＲを含む、上述した実施形態のいずれかによるライブ・ストリーミング・システムにおけるデータのストリーミングの方法であって、
前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲがピアツーピア・ストリーミング・ネットワークの少なくとも一部分を形成し、
前記少なくとも２つのライブ・ストリーミング受信側ＬＳＲがそれぞれ、前記ピアツーピア・ストリーミング・ネットワークの他のライブ・ストリーミング受信側ＬＳＲへのピアツーピア・ストリーミングを生成する手段を含み、他のストリーミング受信側ＬＳＲへの前記ピアツーピア・ストリーミングが、前記少なくとも１つのライブ・ストリーミング・ブロードキャスタＬＳＢからのデータの損失耐性のあるコード表現によって確立される、方法に関する。

本発明は、さらに、
少なくとも１つの入力データ・ブロードキャスタＩＢと、
入力代表データＩＲＤを前記少なくとも１つの入力ブロードキャスタＩＢから入力データＩの複数のＭ個の一意の部分的な符号化表現ＵＰＲに変換する複数のピアＰとを含む、上述した実施形態のいずれかによるネットワークにおいて入力データＩを配布する方法であって、
前記Ｍ個の一意の部分的な符号化表現の複数のコード・サブセットＷ１，Ｗ２，Ｗ３，．．が前記入力データＩのＮ個の異なる一意の部分的な符号化表現ＵＰＲを含み、各サブセットＷ１，Ｗ２，Ｗ３，．．が前記入力データＩを表し、ＮがＭ―１未満である、方法に関する。

本発明は、さらに、上述した実施形態のいずれかによるデータ・ライブ・ストリーミング・システムにおける損失耐性のあるコードの使用に関する。

本発明は、さらに、上述した実施形態のいずれかによるネットワークにおける損失耐性のあるコードの使用に関する。
以下では、図面を参照して本発明を説明する。

図１Ａは、入力ブロードキャスタＩＢおよび複数のピアＰを含むネットワークを示す。複数のピアＰは、入力代表データＩＲＤを前記少なくとも１つの入力ブロードキャスタＩＢから入力データの複数のＭ個の一意の部分的な符号化表現ＵＰＲに変換するよう構成されている。

生成された一意の部分的な表現を、理想的には、任意に、前記入力データのＮ個の異なる一意の部分的な符号化表現ＵＰＲをそれぞれ含む、前記Ｍ個の一意の部分的な符号化表現の多数のコード・サブセットＷｌ，Ｗ２，Ｗ３に結合することができる。

この説明では、一意のパケット、一意の表現などについて言及する際、一意性とは一般に、パケットまたは表現によって実際に含まれるデータではなく、パケットまたは表現が符号化されるキーに関係することを強調しておく。同じまたは異なるデータ・ブロックの符号化に使用されたときに、偶然に異なる２つのキーによって２つの等しいパケットが確立される可能性があるので、この区別は重要である。

図１Ｂは、入力代表データＩＲＤが入力ブロードキャスタからピアＰに送信される上述したネットワークの１段階を示している。

図１Ｃは、ピアＰが入力代表データを一意の部分的な符号化表現に変換し、それらをネットワークに提供することを示している。

図１Ｄは、本発明による中間構造の好ましい構造を示している。

図２は、リードソロモン技術を使用したコンテンツの配布の所望の中間状態を示している。これは、ネットワークＮＷ、およびネットワーク接続ＮＣによってネットワークに接続されたいくつかのピアＰを含んでいる。各ピアは、いくつかの送りパケット（ｆｅｅｄ ｐａｃｋｅｔ）ＦＰを含んでおり、図２の例では、８個の送りパケットがある。各送りパケットＦＰは、例えば６４個のパケットなど、いくつかの送りパケットに基づいて入力が再確立され得るような方法で、入力から導出されたリードソロモン記号を表す。リードソロモン技術は、理論上無制限の数の一意の送りパケットを促進するため、例えば８個の一意のパケットをそれぞれ含む、任意の数のピアがネットワークに接続されていてもよい。

任意のピアＰが、例えば５６個など足りない送りパケット数を非常に迅速かつ確実に集めて、入力を再確立できるようにすることができるため、図２に示した状況が望ましい。リードソロモン技術によって、ピアは、６４個のパケット、すなわち入力の確立に必要な数を得るために、他のピアのいずれかから任意の５６個のパケットを集めることができる。

図３は、図２を参照して上述した所望の状況を達成するために、送りパケットをピアに配布する簡単な方法を示している。これは、入力データＩ、および入力データＩから送りパケットＦＰを生成するリードソロモン生成器ＲＳＧを含む配布ピアＤＰを含む。配布ピアは、ネットワーク接続ＮＣによってネットワークＮＷに接続されている。図３は、さらに、ネットワーク接続ＮＣによってネットワークＮＷに接続されているいくつかのクライアント・ピアＣＰを含む。

配布ピアＤＰは、次に、図２の所望の状況が達成されるまで、入力データＩから一意の送りパケットＦＰを生成し、これらの送りパケットをクライアント・ピアＣＰに送信することができる。ピアの一部またはすべては、いったんパケットを十分集めると、ピアが送りパケットＦＰから配信されたデータＤＤを生成できるようにする配信済みデータ変換器ＤＤＴをさらに含み得る。配信済みデータＤＤは、好ましくは入力データＩに等しいものとする。

図４は、本発明のデータ配布方法の説明に使用される概念の一部を示している。一般に、いくつかのピアＰ１．．Ｐ５，ＰＮは、ネットワークＮＷによって互いにネットワーク接続ＣＮで接続されている。

本発明によれば、ピアＰ１．．Ｐ５，ＰＮは、一般に、中央処理装置（ＣＰＵ）、記憶手段、メモリ、キーボードやコンピュータのマウスなどの入力手段、コンピュータ・モニタなどを含むデスクトップ・コンピュータなどのパーソナル・コンピュータによって具体化される。しかし、ピアは、ネットワークＮＷによって他のピアに接続することができる任意の手段によって具体化され得ることを理解されたい。こうした代替の手段には、サーバ、セットトップ・ボックス、個人用デジタル補助装置（ＰＤＡ）、携帯電話、ラップトップ、ネットワーク対応テレビ、公開情報モニタなどがある。さらに、本発明によれば、上記による１台のコンピュータまたは均等物が複数のピアを含んでいてもよい。この実施形態では、複数のピアを含む１台のコンピュータは、好ましくは複数のネットワーク接続ＮＷも含む。ピアの数は、ＰＮと呼ばれるピア、および小さい点によっても示されており、その数に制限はない。

ネットワークは、好ましくはインターネットであるが、例えばローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）など公の接続に対して閉じているか開放されているかに関わらず、任意の種類のネットワークとすることができる。ネットワークＮＷは、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸなど任意のネットワーク・プロトコルに基づいていてよく、ケーブル、光導体、無線通信など、またはその組み合わせによって伝わる場合もある。ネットワークＮＷは、ハブ、スイッチ、ルータ、または他の任意の種類のネットワーク・ユニットを含み得る。ネットワーク接続ＮＣは、例えばＵＴＰケーブル、同軸ケーブル、光導体、無線ネットワーク、ＡＤＳＬ、ケーブルＴＶ接続、ＩＳＤＮ、正規の電話接続など、任意の種類のネットワーク接続、および例えばネットワーク・インターフェイス・カード（ＮＩＣ）、ハブ、ルータ、スイッチ、無線ルータ、モデム、ＡＤＳＬモデム、ケーブルモデム、ＩＳＤＮモデムなどを確立する任意の手段を含み得る。ネットワーク接続を介したピアとネットワークとの間の通信は、ＴＣＰ／ＩＰプロトコル・スイートの一部であるＵｎｒｅｌｉａｂｌｅ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）に基づくことが好ましいが、本発明のいくつかの実施形態において、他の任意のプロトコルまたはプロトコルの組み合わせを使用することができる。

本発明によれば、各ピアＰ１．．Ｐ５，ＰＮは、一般的なピアＰＮに関して、データ部分ＤＰおよび処理部分ＰＰを含むことが好ましい。しかし、データ部分および処理部分は、異なるピアに異なるように使用され得る。

図４にピアＰ１によって示されているピアは、そのデータ部分ＤＰ内に１組の入力データＩを含み得る。これらは、本発明の方法によって他のピアに配布されるべきデータである。その処理部分ＰＰでは、ピアＰ１は、入力データＩに基づいてコード・セグメントＣＳを生成するように構成されているコード・セグメント生成器ＣＳＧを含む。

本発明によれば、コード・セグメントは、さらにパケットを確立するために使用され得る前段階のパケットである。他の実施形態では、コード・セグメントは、最終段階のパケット・タイプ、または代替の中間パケット・タイプを示し得ることに留意されたい。

ピアは、代わりに、またはさらに、ピアＰ２によって示されているように、そのデータ部分ＤＰ内に少なくとも１つのコード・セグメントＣＳを、またその処理部分ＰＰ内にシード・パケット生成器ＳＰＧを含んでいてもよい。コード・セグメントＣＳは、ピアＰ１のコード・セグメント生成器ＣＳＧによって生成され、ネットワークＮＷおよびネットワーク接続ＮＣによってピアＰ１からピアＰ２に配信される。シード・パケット生成器ＳＰＧは、コード・セグメントＣＳに基づいて、シード・パケットＳＰを生成するように構成されている。

さらに、ピアは、代わりに、またはさらに、ピアＰ３によって示されているように、そのデータ部分ＤＰ内に、ピアＰ２、および同じ機能を備える他のピアからネットワークおよび接続によってピアＰ３に配信されるいくつかのシード・パケットＳＰを含んでいてもよい。図４の概念の概要には、８個のシード・パケットが示されている。その処理部分ＰＰでは、ピアＰ３は、いくつかのシード・パケットＳＰを送りパケットＦＰに変換するように構成されている送りパケット変換器ＦＰＴを含む。

さらに、ピアは、代わりに、またはさらに、ピアＰ４によって示されているように、そのデータ部分ＤＰ内に、ピアＰ３、および同じ機能を備える他のピアからネットワークおよび接続によってピアＰ４に配信されるいくつかの送りパケットＦＰを含んでいてもよい。図４の概念の概要には、８個の送りパケットが示されている。その処理部分ＰＰでは、ピアＰ４は、いくつかの送りパケットＦＰを、好ましくは入力データＩに等しい配信済みデータＤＤに変換するように構成されている配信済みデータ変換器ＤＤＴを含む。

最後に、ピアは、代わりに、またはさらに、ピアＰ５によって示されているように、そのデータ部分ＤＰ内に、ピアＰ４、および同じ機能を備える他のピアからネットワークおよび接続によってピアＰ５に配信される１組の配信済みデータＤＤを含んでいてもよい。配信済みデータＤＤは、好ましくは入力データＤＤに等しい。その処理部分ＰＰでは、ピアＰ５は、データが完全に配信されたので、配布プロセスで使用するように構成されている任意の処理手段を必ずしも含んでいるとは限らないが、処理部分は、例えばサブネットワークにおいて、配布プロセスを初めからやり直すために、ピアＰ１としてコード・セグメント生成器ＣＳＧを含んでいてもよい。さらに、ピアＰ５の処理部分は、ストリーミング・ビデオ・ビューアなど、配信済みデータＤＤを使用する処理手段を含むことが好ましい。

本発明によれば、上述した工程のうちの１つ、いくつか、またはすべてがピアのそれぞれまたは一部内に含まれていてもよいことに留意されたい。実際に、処理工程の送りパケット変換器ＦＰＴおよび配信済みデータ変換器ＤＤＴ、および対応するデータ部分のシード・パケットＳＰ、送りパケットＦＰ、および配信済みデータＤＤは、同じピア内に含まれていることが好ましい。したがって、図４の概念図におけるピアＰ３、Ｐ４、およびＰ５の作業は１つのタイプのピア内で処理されることが好ましいが、このピアがネットワークにおいていくつかのインスタンスを有していることが好ましい。

したがって、本発明による好ましい配布ネットワークは、図４のピアＰ１に対応する少なくとも１つのピア、図４のピアＰ２によるいくつかのピア、さらに、それぞれ図４のＰ３、Ｐ４、およびＰ５の集合によるいくつかのピアを含む。

図５は、本発明の配布方法の好ましい実施形態を示している。

ピアＰ１は、配布される入力データＩを含む。したがって、好ましい実施形態では任意のピアは任意の役割を有し得るが、ピアＰ１は、この場合、ブロードキャスタとして働くため、配布ピアまたはブロードキャスト・ピアとも呼ばれる。

ピアＰ１は、コード・セグメント生成器ＣＳＧによって、例えば８個など、いくつかのコード・セグメントＣＳを生成し、それらをいくつかのピアＰ２に送信する。本発明の好ましい実施形態において、全入力データＩに基づいて各コード・セグメントが生成される。しかし、代替実施形態において、コード・セグメントのすべての一部は、入力データＩの一部分のみに基づいて生成され得る。

最も簡単な実施形態において、各コード・セグメントＣＳは、一意かつ必須であり、すべてのコード・セグメントの全サイズは、入力データＩのサイズに対応する。したがって、入力データに対する各コード・セグメントのサイズは、例えば、８個の必要なコード・セグメントが生成された場合、入力データの１／８など、必要なコード・セグメントの数の逆数となる。

異なる実装によれば、絶対に必要な数よりも多くの一意のコード・セグメントおよび／または各コード・セグメントのより多くのコピーが有益であり得る。一意のコード・セグメントの考え得る数は、理論上無制限であるが、実際の実装形態では、一般に、２^３２個の考え得る一意のコード・セグメントに対応する３２ビットなど、特定の整数表現に依存する。

ブロードキャスタから送信されるすべてのコード・セグメントＣＳの全サイズは、少なくとも入力データＩのサイズである。したがって、ブロードキャスタは、少なくとも入力データＩの量に対応する量を送信する必要はあるが、必ずしもそれより多くを送信する必要はない。従来の配布方法によって、ブロードキャスタは、全入力データを、最終的な受信側のそれぞれに送信する必要がある、または受信側がツリー構造で配列される必要がある。

コード・セグメントＣＳを含むピアＰ２は、シード・パケット生成器ＳＰＧによってシード・パケットＳＰを生成する。シード・パケットは、ピアＰ３に送信される。各ピアＰ３は、いくつかのピアＰ２からシード・パケットを受信し、１つのピアＰ３によって受信されたシード・パケットＳＰは、それらが生成されたキーに関して互いに一致する必要がある。この一致を確実にするために、シード・パケットＳＰは、ピアＰ３からの要求に応じて生成されることが好ましく、Ｐ３は次いで、同じピアＰ３に配信されたシード・パケットＳＰの生成に使用すべきキーを指図することができる。

コード・セグメントがそれぞれ全入力データＩに基づいて生成される好ましい実施形態において、シード・パケットＳＰも全入力データに依存する。上述した代替実施形態において、シード・パケットは、必ずしもすべて全入力データに依存するとは限らない。

各ピアＰ３は、対応するキーによって生成されたいくつかの一意のシード・パケットＳＰを受信するはずである。すべてのコード・セグメントＣＳが一意かつ必須である上述した最も簡単な実施形態において、各ピアＰ３は、シード・パケット、すなわち各コード・セグメントを元とするシード・パケットを各ピアＰ２から受信するはずである。例えば、８個の一意の必要なコード・セグメントが存在している場合、各ピアＰ３は、８個のシード・パケットＳＰを受信するはずである。

したがって、コード・セグメントに対する各シード・パケットのサイズは、例えば、８個の必要なコード・セグメントが生成された場合、コード・セグメント・サイズの１／８、したがって入力データの１／６４など、必要なコード・セグメントの数の逆数となることが好ましい。

必要数以上の一意のコード・セグメントが存在する代替実施形態において、各ピアＰ３は、必要なコード・セグメントの数に対応する少なくともいくつかのシード・パケットを受信するはずであるが、より信頼性が高く、損失パケットに耐性がある配布方法を得るために、より多くのシード・パケットを受信することが好ましい場合がある。

各コード・セグメントのより多くのコピーが存在する代替実施形態において、ピアＰ３は、必要数のコード・セグメントに対応する、異なるコード・セグメントを元とする少なくともいくつかのシード・パケットを受信するはずである。ピアＰ３の送りパケット変換器ＦＰＴは、一意のコード・セグメントを元とする、対応する生成キーを備えるいくつかのシード・パケットを必要とする。

図５には、すべてのピアＰ３がすべてのピアＰ２からパケットを受信したとは限らず、ピアＰ２の数が必要数より多いことを示すことが図示されている。

ピアＰ３はそれぞれ、送りパケット変換器ＦＰＴによって、受信されたいくつかの一意のシード・パケットＳＰをいくつかの一意の送りパケットＦＰに変換する。確立された送りパケットは、ピアＰ４に送信される。しかし、好ましい実施形態において、ピアＰ４は、上述したように、ピアＰ３と同じピアである。

好ましくは、いくつかの数のシード・パケットＳＰが同じ数の送りパケットＦＰに変換される。したがって、例えば必要数のコード・セグメントＣＳが８個であり、したがって、ピアＰ３のそれぞれによって受信されたシード・パケットの数がそれに応じて８個である場合、ピアＰ４のそれぞれによって含まれる送りパケットの数は８個である。

ピアＰ３ごとに生成されたシード・パケットは、ピアＰ３ごとに異なるキーから生成されることが好ましいため、いくつかのコード・セグメントＣＳから１つのピアＰ３によって受信されるシード・パケットは、同じコード・セグメントＣＳから異なるピアＰ３によって受信されるシード・パケットとは異なることが好ましい。それによって、システム全体において一意の送りパケットが数多く確立されることが確実になる。

各送りパケットのサイズは、各シード・パケットのサイズと同じであることが好ましく、したがって、例えば、８個のコード・セグメントが必要である場合、コード・セグメント・サイズの１／８、したがって入力データの１／６４である。

ピアＰ４のそれぞれがいくつかの送りパケットＦＰ、例えば８個の送りパケットを含む場合、図２を参照して上述した望ましい中間状態が達成される。配布プロセスの残りは、いくつかのピアＰ４が、好ましくは入力データＩに等しい配信済みデータＤＤに変換するのに必要ないくつかの送りパケットＦＰを集めるまで、ピアＰ４が送りパケットＦＰをそれら自体に配布することを含む。

最も簡単な実施形態において、入力データＩの再確立に必要な送りパケットの数は、入力データのサイズに対する送りパケット・サイズの逆数である。例えば送りパケットが入力データＩの１／６４のサイズを有している場合、配信済みデータＤＤに変換するために、６４個の一意の送りパケットが必要とされる。

代替実施形態において、配信済みデータの再確立を確実にするために必要な送りパケットの数は、例えば一意の送りパケット６８個など、そのサイズの逆数よりわずかに大きくてもよい。

図６Ａから図９は、リードソロモンベースのコード化に従って、上述した異なるセグメントおよびパケットがどのように確立されるかを示している。この好ましい実施形態は、本発明の最も簡単な考え得る実施形態のうちの１つである。以下の説明は一例にすぎず、代替実施形態において、任意の数、サイズなどが異なっていてもよいことに留意されたい。

図６Ａから６Ｄは、コード・セグメントＣＳの確立を示している。図６Ａは、６４個の部分、Ｉ０，Ｉ１．．．Ｉ６３に分割される入力データＩを示している。この例では、入力データＩは、サイズ６４ｋＢ、すなわち６５５３６バイトのものと決定される。したがって各部分Ｉ０，Ｉ１．．．Ｉ６３は、１ｋＢ、すなわち１０２４バイトのサイズを有する。このサイズは、好ましくは、パケットの配布に使用されるネットワークおよびネットワーク接続によって最も容易に処理されるサイズに相当するものとし、１ｋＢのサイズは、インターネットなどＴＣＰ／ＩＰネットワークのプロトコルおよびネットワーク構成要素に非常によく適合する。

図６Ｂは、入力データ部分Ｉ０，Ｉ１．．．Ｉ６３のそれぞれが、いくつかのサブ部分Ｓ、この例では各サブ部分が１２８バイトのサイズを有する８個のサブ部分Ｓにさらに分割されることを示している。図６Ｂには、入力データ部分Ｉ３のサブ部分が示されている。したがってこれらのサブ部分は、Ｓ（Ｉ３，０），Ｓ（Ｉ３，１）．．．Ｓ（Ｉ３，７）と示されている。

図６Ｃは、入力データ部分Ｉ３から確立されたコード・セグメント部分Ｔの確立を示している。各コード・セグメント部分Ｔは、リードソロモン生成器ＲＳＧによって、コード・セグメント・キーＣＳＫ０，ＣＳＫ１．．．ＣＳＫ７に基づいて確立される。したがって、入力データ部分Ｉ３から確立されたコード・セグメント部分は、Ｔ（Ｉ３，ＣＳＫ０），Ｔ（Ｉ３，ＣＳＫ１）．．．Ｔ（Ｉ３，ＣＳＫ７）と示される。コード・セグメント・キーＣＳＫ０，ＣＳＫ１．．．ＣＳＫ７は異なるものとし、任意の値を有していてよく、したがって、理論上無制限の数のコード・セグメント部分Ｔが可能となる。使用されるコード・セグメント・キーの数は、この例では８個であり、生成されるコード・セグメントの数を決定する。この例のコード・セグメント部分Ｔは、１２８バイトのサイズを有する。

図６Ｃに示されるプロセスは、入力データ部分Ｉ０、Ｉ１．．．Ｉ６３ごとに実行され、したがって、この例では、合計８×６４＝５１２のコード・セグメント部分Ｔが確立される。

図６Ｄは、コード・セグメントＣＳを形成するために、いくつかのコード・セグメント部分Ｔがどのように結合されるかを示している。図６Ｄで、同じコード・セグメント・キーＣＳＫ５に基づいて生成されたすべてのコード・セグメント部分が、コード・セグメントＣＳ（ＣＳＫ５）を形成するために結合される。したがってこのコード・セグメントは、第１の入力データ部分Ｉ０から生成されたコード・セグメント部分Ｔ（Ｉ０，ＣＳＫ５）、第２の入力データ部分Ｉ１から生成されたコード・セグメント部分Ｔ（Ｉ１，ＣＳＫ５）などを含む。したがって、コード・セグメントＣＳは、全入力データＩに依存する。

５１２個すべてのコード・セグメント部分Ｔは、上述したように、そのコード・セグメント・キーＣＳＫ０，ＣＳＫ１．．．ＣＳＫ７に従ってソートされ、したがって８個のコード・セグメントＣＳ（ＣＳＫ０），ＣＳ（ＣＳＫ１）．．．ＣＳ（ＣＳＫ７）を形成する。したがって、各コード・セグメントＣＳは、６４×１２８＝８１９２バイト＝８ｋＢのサイズを有しており、これは入力データＩのサイズの１／８である。

コード・セグメントＣＳは、配布を開始するために、異なるピアに送信されることが好ましい。しかし、入力データ保持ピアから送信される全サイズは、入力データのサイズ、すなわち８×８ｋＢ＝６４ｋＢだけである。

本発明のより高度な実施形態では、より多くの異なるコード・セグメント・キー、すなわちＣＳＫ８，ＣＳＫ９，ＣＳＫ１０などを使用することによって、必要な８個以上のコード・セグメントが生成され得る。本発明によれば、配布プロセスを続行するには、生成されたコード・セグメントのうちの任意の８個で十分である。したがって、例えば１２個のコード・セグメントを生成し、送信することによって、最高４つのコード・セグメント保持ピアは、配布プロセスを危険にさらすことなく、その参加を放棄することができる。

本発明のより高度な代替実施形態において、異なるコード・セグメントの全組は、直接複製されてもよく、したがって重複、およびネットワークの異なる領域に送信されるコード・セグメントの組の各コピーが生成される。したがって、各ネットワーク領域において、必要なコード・セグメントのローカルのコピーが確立され得る。それによって、ネットワークのネックを回避する有利な方法が得られている。

図７Ａおよび７Ｂは、コード・セグメントＣＳに基づいて、シード・パケットＳＰがどのように生成されるかを示している。図７Ａは、６４個のコード・セグメント部分Ｔ（Ｉ０，ＣＳＫ５）．．．Ｔ（Ｉ６３，ＣＳＫ５）を含むコード・セグメントＣＳ（ＣＳＫ５）を示している。リードソロモン生成器ＲＳＧによって、シード・パケット・サブキーＳＰＫ２３−０，ＳＰＫ２３−１．．．ＳＰＫ２３−７に基づいて、いくつかのシード・パケット部分Ｕ（ＣＳＫ５，ＳＰＫ２３−０）．．．Ｕ（ＣＳＫ５，ＳＰＫ２３−７）が生成される。シード・パケット・サブキーは異なるものとし、任意の値を有していてよく、したがって、理論上無制限の数のシード・パケット部分Ｕが可能である。好ましくは、シード・パケット・サブキーの生成に、疑似ランダム・プロセス、または場合によって多数の異なるキーを確立する他の任意のプロセスが使用されてもよい。シード・パケット部分Ｕのそれぞれは、１２８バイトのサイズ、すなわち、コード・セグメントＣＳのサイズの１／６４のサイズを有している。

図７Ｂは、確立されたシード・パケット部分Ｕがシード・パケットＳＰ（ＣＳＫ５，ＳＰＫ２３）にどのように結合されるかを示している。したがって、シード・パケットは、８×１２８バイト＝１０２４バイト＝１ｋＢのサイズ、すなわち、コード・セグメントＣＳのサイズの１／８のサイズを得る。

シード・パケット・サブキーＳＰＫ２３−０，ＳＰＫ２３−１．．．ＳＰＫ２３−７は、シード・パケット・キーＳＰＫ２３から確立され、これは、任意の値を有していてよく、したがって、理論上無制限の数のシード・パケット・キーが可能となる。この例の２３個のシード・パケット・キーは、任意のシード・パケット・キーが使用されることを表している。

本発明の配布方法は、同じシード・パケット・キーＳＰＫ２３を備えるシード・パケットが、コード・セグメントＣＳ（ＣＳＫ０）．．．ＣＳ（ＣＳＫ７）ごとに確立されることを確実にする必要がある。コード・セグメントＣＳが異なるピアに配置されていることが好ましいため、対応するシード・パケット・キーの使用を確実にする何らかの方法が得られる必要がある。好ましい実施形態において、あるシード・パケットＳＰが送信されるべきピアにシード・パケット・キーを指図させることによって、これが確実になる。ピアは、すべてのコード・セグメント・ピアに同じキーを指図した場合、コード・セグメントのそれぞれから同じキーに基づいて確立されたシード・パケットを受信することができる。サブ・キーは、コード・セグメント・ピアのそれぞれにおいて、対応する方法で決定されなければならない。ピアを受信する異なるシード・パケットが異なるシード・パケット・キーを指図することを確実にするために、ピアは、ＩＤ番号、ＩＰアドレス、ＭＡＣアドレスなど、好ましくはそれ自体の何らかの一意の表現を使用することができる。２３個は、特定のピアのこうした一意の表現を示し得る。

図８Ａから８Ｃは、シード・パケットが送りパケットにどのように変換されるかを示している。図８Ａは、８個のコード・セグメント保持ピアから２３個によって表される１つのピアによって集められた８個のシード・パケットＳＰ（ＣＳＫ０，ＳＰＫ２３）．．．ＳＰ（ＣＳＫ７，ＳＰＫ２３）の集まりを示している。したがって、受信されたシード・パケットＳＰは、異なる８個のコード・セグメントから生成されるが、同じシード・パケット・キーＳＰＫ２３に基づいている。各シード・パケットが１ｋＢのサイズを有するため、ピアは、８個のシード・パケットを集めるために、合計８ｋＢを受信している。

図８Ｂは、受信されたシード・パケットによって含まれるシード・パケット部分の並べ替えを示している。並べ替えによって、８個のシード・パケットＳＰ（ＣＳＫ０，ＳＰＫ２３）．．．ＳＰ（ＣＳＫ７，ＳＰＫ２３）が８個のコード化送りパケットＶ（ＳＰＫ２３−０）．．．Ｖ（ＳＰＫ２３−７）に変わる。並べ替えは、元のコード・セグメントではなく、そのシード・パケット・サブキーに従って、シード・パケット部分Ｕを配列することを含む。したがって、例えば、シード・パケット・サブキーＳＰＫ２３−０に基づいて生成されたすべてのシード・パケット部分Ｕ、すなわちシード・パケット部分Ｕ（ＣＳＫ０，ＳＰＫ２３−０），Ｕ（ＣＳＫ１，ＳＰＫ２３−０）．．．Ｕ（ＣＳＫ７，ＳＰＫ２３−０）は、コード化送りパケットＶ（ＳＰＫ２３−０）に結合される。この並べ替えのために、あるピアのコード・セグメントのそれぞれから生成されたシード・パケットが対応するシード・パケット・キーに基づいて生成されることが重要である。

シード・パケット部分Ｕが単に再配列されるだけであるため、コード化送りパケットＶのサイズは、シード・パケットＳＰのサイズに等しい。

図８Ｃは、コード化送りパケットＶ（ＳＰＫ２３−０），Ｖ（ＳＰＫ２３−１）．．．Ｖ（ＳＰＫ２３−７）が送りパケットＦＰ（ＳＰＫ２３−０），ＦＰ（ＳＰＫ２３−１）．．．ＦＰ（ＳＰＫ２３−７）にどのように変換されるかを示している。復号化は、逆リードソロモン変換器ＩＲＳＴによって行われる。送りパケットＦＰのサイズは、シード・パケットＳＰのサイズと同じであり、すなわち、この例では入力データＩのサイズの１／６４に対応する１ｋＢである。

この例の方法によって生成された送りパケットＦＰの１つの重要な特性は、好ましくは入力データＩに等しい配信済みデータＤＤが、任意の６４個の一意の送りパケットＦＰから逆リードソロモン変換ＩＲＳＴによって確立され得ることである。上記の例で、２３個によって表されるピアが８個の送りパケットを確立するため、ピアが配信済みデータＤＤを確立できるようにするために、５６個以上の送りパケットがピアによって確立され、または他のピアから集められなければならない。

図９は、いくつかの送りパケットＦＰが配信済みデータＤＤの確立をどのように可能にするかを示している。図８において、ピア２３からの８個の送りパケットＦＰ（ＳＰＫ２３−０），ＦＰ（ＳＰＫ２３−１）．．．ＦＰ（ＳＰＫ２３−７）、８個の送りパケットＦＰ（ＳＰＫ３４−０），ＦＰ（ＳＰＫ３４−１）．．．ＦＰ（ＳＰＫ３４−７）など、すなわちピアを確立する異なる送りパケットからの合計６４個の送りパケットが、逆リードソロモン変換によって、配信済みデータＤＤに変換され得る。

図１０は、図６Ａから９を参照して上述した本発明の実施形態、すなわちリードソロモンベースの符号化を使用する実施形態の符号化および復号化の技術の循環の性質を示している。図１０は、図６Ａから６Ｄを参照して説明したように、入力データＩがコード・セグメントＣＳの生成にどのように使用されるかを示している。さらに、図７Ａおよび７Ｂを参照して説明したように、コード・セグメントＣＳが、同じ行内のいくつかがシード・パケットＳＰと呼ばれるシード・パケット部分Ｕの生成にどのように使用されるかを示している。さらに、図８Ａから８Ｃを参照して説明したように、シード・パケット部分Ｕが送りパケットＦＰにどのように変換されるかを示している。また、最後に、図９を参照して説明したように、送りパケットＦＰが配信済みデータＤＤとも呼ばれる入力Ｉにどのように変換されるかを示している。

図１０には、異なるキーＣＳＫ０．．．ＣＳＫ９を備える１０個のコード・セグメントＣＳ（ＣＳＫ０）．．．ＣＳ（ＣＳＫ９）が示されている。理論上、一意のキーを備える考え得る数のコード・セグメントは、点で示されているように無制限である。各コード・セグメントから、理論上無制限の数のシード・パケット部分Ｕが生成され得る。シード・パケット部分Ｕの生成に使用されるキーは、実用上、この例では２３個または３４個などのグループ化キー（ｇｒｏｕｐｉｎｇ ｋｅｙ）、およびこの例では０個、１個、または２個などいくつかのサブ・キーによって決定されることが好ましい。サブ・キーは、疑似ランダム・プロセスによって、グループ化キーから生成されることが好ましい。送りパケットＦＰは、異なるコード・セグメント・キーを有するが、同じシード・パケット・キー、すなわちグループ化キーおよびサブ・キーの同じ組み合わせを有するシード・パケット部分Ｕから生成されるため、ある程度の同期の実際の必要性が生じる。

図１０には、さらに、異なるコード・セグメント・キーＳＰＫを有するが、この例ではＳＰＫ２３−０やＳＰＫ４１−１など、同じグループ化キー−サブ・キーの組み合わせを有するシード・パケット部分Ｕによって変換された９個の送りパケットＦＰ（ＳＰＫ２３−０）．．．ＦＰ（ＳＰＫ４１−２）が示されている。この図には、さらに、シード・パケット部分Ｕ（ＣＳＫ８，ＳＰＫ４１−０），Ｕ（ＣＳＫ８，ＳＰＫ４１−１）およびＵ（ＣＳＫ８，ＳＰＫ４１−２）を含むシード・パケットＳＰ（ＣＳＫ８，ＳＰＫ４１）の例が示されている。

図１１は、本発明のネットワークおよび配布方法の好ましい適用を示している。本出願は、例えばビデオおよび／または音声などのコンテンツの、例えばインターネットなどネットワークに接続されたいくつかのピアへのライブ・ストリーミングに関する。

図１１には、コンピュータとして示されているライブ・ストリーミング・ブロードキャスタＬＳＢが示されている。ライブ・ストリーミング・ブロードキャスタＬＳＢには、ビデオ・カメラＶＣが接続される。したがって、ビデオ・カメラによって録画されたビデオ・ストリームは、コンピュータ・モニタ上のピクチャによって、図１１に示されているライブ・ストリーミグ・ブロードキャスタＬＳＢから使用可能である。ライブ・ストリーミング・ブロードキャスタＬＳＢは、さらに、ネットワーク接続ＮＣによってネットワークＮＷに接続される。

ネットワークＮＷには、いくつかのライブ・ストリーミング受信側ＬＳＲも接続される。ライブ・ストリーミング受信側は、任意の種類のネットワーク対応装置とすることができ、したがって、図１１にはコンピュータ、ラップトップ、および個人用デジタル補助装置（ＰＤＡ）として示されている。ライブ・ストリーミング受信側は、任意の接続手段によってネットワークに接続されてもよく、したがってＰＤＡは、図１１には、無線ネットワーク接続ＷＮＣによって接続されるものとして示されている。

本発明のシステムおよび方法を図１１のネットワークおよびピアに適用することによって、ライブ・ストリーミング受信側ＬＳＲのそれぞれが、グリッド技術および損失耐性のある送信を使用して、有利な方法で、ライブ・ストリーミング・ブロードキャスタＬＳＢに接続されているビデオ・カメラＶＣによって録画されたビデオ・ストリームを受信することができるようになる。

図１１に示されている例は、単に、本発明の考え得る一実施形態であって、ビデオ・カメラＶＣの代わりに、またはそれとの組み合わせで、異なるタイプのカメラおよびマイクロフォン、再生装置、音声またはビデオ・ミキサー、格納されているマルチメディア・ファイルなど任意のソースのライブ・ストリーミング・コンテンツ、ライブ・ストリーミング・ブロードキャスタＬＳＢおよびライブ・ストリーミング受信側ＬＳＲの代わりに、またはそれとの組み合わせで、コンピュータ、ラップトップ、ＰＤＡ、携帯電話、サーバ、デジタル信号プロセッサ、プログラマブル・ゲート・アレイなどの専用処理手段、ネットワーク・ルータなど、処理手段を含む任意の種類のネットワーク対応装置、並びに図１１に示されているネットワークＮＷ、ネットワーク接続ＮＣ、および／または無線ネットワーク接続ＷＮＣの代わりに、またはそれとの組み合わせで、任意の種類のネットワークおよびネットワーク接続を使用することは本発明の範囲内であることに留意されたい。さらに、この実施形態は、インターネットを介して音声および／またはビデオなどのライブ・ストリーミングを配布するのに特に有利ではあるが、任意の種類のコンテンツ、例えば大きいデータ・ファイル、データベース、コンピュータ・プログラム、ビデオおよび音声ファイル、スチール写真などを配布するのに使用することもできる。

図１１の実施形態では、ライブ・ストリーミング・ブロードキャスタＬＳＢは、図１から図５を参照して上述した入力ブロードキャスタＩＢ、配布ピアＤＰまたはピアＰ１、および任意選択で、上述したその他のピア・カテゴリのうちの１つまたは複数を組み込んでいてもよい。ライブ・ストリーミング受信側ＬＳＲは、それぞれ、ピアＰ、中間ピアＩＰ、クライアント・ピアＣＰ、および／またはピアＰ２、Ｐ３、Ｐ４、およびＰ５のうちの任意の１つのまたは複数を組み込んでいてもよい。これらは、さらに、異なるセッションで、または同時に使用するライブ・ストリーミング・ブロードキャスタＬＳＢの機能を含んでいてもよい。

好ましい実施形態で、ライブ・ストリーミング・ブロードキャスタＬＳＢは、少なくとも入力データＩからコード・セグメントＣＳを生成する機能を含み、ライブ・ストリーミング受信側ＬＳＲはすべて、少なくともいくつかの送りパケットを配信済みデータＤＤ、すなわち入力データＩに変換する機能を含む。コード・セグメントＣＳからシード・パケットＳＰを生成する目的は、好ましい実施形態では、ある数のライブ・ストリーミング受信側または他のピアに割り当てられるが、それを行う機能は、実際にはピアのうちのいずれかによって含まれていてもよい。いくつかのシード・パケットＳＰを送りパケットＦＰに変換する目的は、すべての受信側に割り当てられることが好ましいが、代替実施形態では、いくつかのピアのためにとっておいてもよい。

本発明のライブ・ストリーミングのアプリケーションまたは他の任意のアプリケーションは、リードソロモンベースの損失耐性のある送信または他の任意の種類の損失耐性のある送信または順方向誤り訂正送信、例えばトルネードベース、ＬＴベース、Ｒａｐｔｏｒベースの符号化などに基づき得ることに留意されたい。

さらに、本発明によれば、ライブ・ストリーミングという用語は広義に理解されることに留意されたい。したがって、これは、基本的に、少なくとも次の２つの状況、例えば、生のＴＶ番組、サッカーの試合やデータ取得装置からデータを流すときなど、情報が流されるのと実質的に同時に情報が利用可能になるが、必ずしも受信側によって同時にモニタに表示されたり、使用されたりするとは限らず、すなわち将来使用するためにその情報を受信側の場所に格納し、および／またはすぐに表示し、したがってストリーミングが情報の作成に実質的に同期されることを得る第１のセットアップ、およびブロードキャスタが、映画、音声ファイル、コンピュータ・プログラムなど、格納されている情報にアクセスでき、情報が受信側によって表示または使用されるのと実質的に一致して流される、すなわちストリーミングが情報の実際の使用に実質的に同期される第２のセットアップに適用され得る。これらのセットアップの間に、またはこれらのセットアップに加えて、ライブ・イベントのタイムシフト・ストリーミングなどさらにいくつかの可能性がある。本発明によるライブ・ストリーミングの用語の範囲内のその他のセットアップは、いくつかの受信側が、ライブ・イベント、映画、データベース・アップデート、コンピュータ・プログラムなど、ストリームの内容とは無関係に、実質的に同期してストリームを受信することを含む。

本発明のその他の有利な実施形態は、弾力性のある分散型データベースである。こうした実施形態の一例には、ブロードキャスタによってそれぞれ５００ＭＢのサイズの３つのコード・セグメントに分割される１０００ＭＢのデータのデータベースなどがある。これら３つのコード・セグメントは、地理的に異なる場所に配置することができ、この例では、例えばコード・セグメントを保持する少なくとも２台のコンピュータがいつでも稼働中であることを前提とする。例えば、１日当たり少なくとも１６時間稼働しており、残りの時間はメンテナンスのために終了しているコンピュータに各コード・セグメントを格納することができ、非稼働のタイム・スロットが３つのコンピュータ間で重ならないようにする。

１つまたは複数の分散ピアは、例えば５００ｋＢのサイズのデータをシード・パケットの形でいつでもダウンロードすることができ、すなわち、単一のピアは、可能な３つのうちの任意の２つの使用可能なコード・セグメントを元とする５００ｋＢをダウンロードすることができる。次いでピアは、このデータを、例えば配布、復号、バックアップなど他の用途など、その後使用する用意ができている１ＭＢの単一の送りパケットＵＰＲに変換することができる。それぞれ１ＭＢの、異なる１０００個のこうした作成済み送りパケットＵＰＲを含むサブセットＷにアクセスできる任意のピアは、符号化がリードソロモン原理に基づく場合、データベースを再構築することができる。他のタイプの符号化の場合、データベースを再構築する可能性が高くなるまでは、１０００個強のパケットを集める必要があり得る。さらに、例えば、９００個以上、１０００個未満の送りパケットを有するピアすべてに例えば１００個のパケットを直接配信してデータベースを再生させるために標準のマルチキャストを使用する必要がある場合、送りパケットＵＰＲの一部がデータベースから直接、すなわちブロードキャスタによって直接生成されることが望ましい。

データベースが例えば３つのコード・セグメントに分割された後に、他のコード・セグメントにアクセスすることなく、すなわち５００ＭＢの記憶スペースのみにアクセスして、こうしたコード・セグメントのいずれかまたはすべてから送りパケットＵＰＲを生成することができるため、上述した実施形態の有利な特徴は、異なるコード・セグメントの保持に必要なスペースに関する。

上述した実施形態のその他の有利な特徴は、安全な、すなわち機密のデータ送信である。例えば９９９ＭＢ未満の情報を送りパケットＵＰＲの形で受信した、または記憶容量がこの閾値未満のピアがデータベースのどの部分も再現できないように、符号化を実施することができる。したがって、個々の許可されていないピアが必要量を集めることができない限り、ピアがともに必要な量よりずっと多くのパケットを確立し、集めることができるため、データベースの１０００ＭＢのデータを安全かつ依然として損失耐性のある方法で配布することができる。

本発明のさらに代替の実施形態は、送りパケット変換の負荷バランシングを特徴とする。こうした実施形態の一例は、例えば１０００ＭＢのデータベースから例えばそれぞれ５００ＭＢの３つのコード・セグメントを確立し、単一のピア内に３つすべてのコード・セグメントを格納することを含む。次いでこの単一のピアは、並列で送りパケットＵＰＲを生成するために、それぞれ場合によって５００ＭＢの個別の有限の記憶容量のみにアクセスできるハイパー・スレッディング・アーキテクチャの３つの個別のプロセッサまたはスレッドを使用することができる。これは、例えば、送りパケットがマルチキャストを介して複数のピア、他のプロセッサ、または他のスレッドに配信されるセットアップで使用することができる。したがって、これに必要な計算リソースは、例えば場合によってそれぞれ有限の記憶アクセスを備える３つの異なるＣＰＵなどの３つの処理ユニットに平均される。さらに、これは、例えばバイオチップ、ニューラル・ネットワークなどの欠陥のある可能性のある計算、または欠陥のある極速ＣＰＵを備えるコンピュータ・アーキテクチャを容易にし、異なる３つの計算のうちの２つのみが正しい場合でさえ、依然として適切な送りパケットを生成することができる。

本発明のさらに別の実施形態は、特に定義されたポリシーに従って他のピアまたはピアのグループと提携するときに個々のピアまたはピアのグループがデータへのアクセスのみを得ることができる、制限されたデータ・アクセス・ポリシーを特徴とする。こうした実施形態のこの例では、ピアが、各グループが少なくとも１つのピアを有する異なるピアの４つのグループに分けられると仮定する。ブロードキャスタＩＢは、１０００ＭＢのデータ・ブロックから、それぞれ５００ＭＢのコード・セグメントを２つ確立し、これらのコード・セグメントを異なる２つの場所Ｑ１およびＱ２に送信し、次いで元のデータを破棄する。次いで場所Ｑ１およびＱ２のそれぞれは、ピアのグループごとに、１６５ＭＢ以下の異なるシード・パケット、あるいは送りパケットＵＰＲを確立するように制限される。したがって、ピア・グループは、合計で、３３０ＭＢ以上、すなわち各場所Ｑ１、Ｑ２から１６５ＭＢ以上の重複しないデータを得ることができない。したがって、ピア・グループは、受信されたデータを、重複しない送りパケットＵＰＲの形の３３０ＭＢ以下のデータに変換することができる。ピア・グループ内のピアは、確立された送りパケットを非常にうまく複製するが、３３０ＭＢを超える重複しない送りパケットを取得することはない。したがって、ピアがデータベースを再構築するには、常に、１０００ＭＢを超える一意の送りパケットＵＰＲを集めるために、４つすべての異なるピア・グループからデータを集めることが必要である。つまり、それ自体のグループから、またはＱ１およびＱ２から受信されたデータを変換することによって３３０ＭＢの送りパケットＵＰＲを取得し、次いで異なる２つのグループのピアから３３０ＭＢの送りパケットＵＰＲを、４つのグループの最後のピアから１０ＭＢを受信することができる。あるいは、異なる４つのグループまたは他の任意の構成から２５０ＭＢのデータを受信することができる。したがって、この実施形態は、データをいくつかのピアに配布することができるような方法でデータの配布を可能にするが、このグループのピアがデータベースを再現することができ得ることに他の３つのグループが同意したグループに属するピアによって再現できるだけであることを依然として保証する。ＩＢがそれを破棄した後、少なくとも４つのグループに広がる少なくとも４つのピアがデータの交換に同意する前は、システムのいずれの部分もデータベースの十分な知識を有してないことに留意されたい。

あるグループのピアが他のグループの任意のピアを知らず、したがって全データ量を取得する可能性がない代替実施形態において、すべてのピア・グループの知識を含むサーバなどの中央ピアは、それ自体の判断で、必要な他のピアの連絡情報を発信することによって、ピアの一部またはすべてが必要な送りパケットを集めることができるようにすることができる。それによって、図２に示された配布の望ましい中間状態を確立し、依然として誰がデータにアクセスできるか、およびいつアクセスできるかを制御することができる。これは、例えば、使用のために実際にリリースされる前に、映画や、新しいバージョンのゲームまたはコンピュータ・プログラムを配布するために使用することができる。

本発明の一実施形態によるネットワークの基本的原理を示す図である。 本発明の一実施形態によるネットワークの基本的原理を示す図である。 本発明の一実施形態によるネットワークの基本的原理を示す図である。 本発明の一実施形態によるネットワークの基本的原理を示す図である。 本発明の一実施形態による配布方法の所望の中間状態を示す図である。 上記の中間状態を達成する簡単な方法を示す図である。 本発明の一実施形態によるネットワーク上で適用可能な考え得る様々なピア・タイプを示す図である。 本発明による好ましい中間構造の全体的な原理を示す図である。 本発明の好ましい実施形態による前段階の入力代表データの確立のプロセスを示す図である。 本発明の好ましい実施形態による前段階の入力代表データの確立のプロセスを示す図である。 本発明の好ましい実施形態による前段階の入力代表データの確立のプロセスを示す図である。 本発明の好ましい実施形態による前段階の入力代表データの確立のプロセスを示す図である。 前段階の入力代表データに基づく入力代表データの生成を示す図である。 前段階の入力代表データに基づく入力代表データの生成を示す図である。 入力代表データの入力の一意の部分的な符号化表現への変換を示す図である。 入力代表データの入力の一意の部分的な符号化表現への変換を示す図である。 入力代表データの入力の一意の部分的な符号化表現への変換を示す図である。 一意の部分的な符号化表現の入力データへの変換による入力データの再確立を示す図である。 本発明の一実施形態の符号化／復号化の概念を示す図である。 ビデオのライブ・ストリーミングに使用する本発明の一実施形態を示す図である。

Claims (46)

1. データ・ライブ・ストリーミング・システムであって、
   ピアツーピア・ストリーミング・ネットワークの少なくとも一部分を形成する少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）と、
   複数のライブ・ストリーミング・受信側（ＬＳＲ）に配布される入力データ（Ｉ）を含む少なくとも１つのデータ・ライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）と、
   該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）がそれぞれ、該入力データ（Ｉ）表現を複数の損失耐性のある符号化表現に変換する手段と、該ピアツーピア・ストリーミング・ネットワークの他のライブ・ストリーミング受信側（ＬＳＲ）に該複数の損失耐性のある符号化表現を送信する手段とを含むデータ・ライブ・ストリーミング・システム。
2. 該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）が該入力データ（Ｉ）表現を複数の損失耐性のある符号化表現に変換する該手段によって該入力データ（Ｉ）の少なくとも２つの一意の部分的な符号化表現（ＵＰＲ）を集合的に提供する請求項１に記載のデータ・ライブ・ストリーミング・システム。
3. 該一意の部分的な符号化表現（ＵＰＲ）のうちの少なくとも２つが、集合的に、データの完全な表現を形成する請求項１に記載のデータ・ライブ・ストリーミング・システム。
4. 該複数の損失耐性のある符号化表現が、該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）によって提供された該入力データ（Ｉ）のＭ個の一意の部分的な符号化表現（ＵＰＲ）を含み、該ライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）からの入力データ（Ｉ）が、該Ｍ個の一意の部分的な符号化表現（ＵＰＲ）のＮ個のサブセットによって表される請求項１乃至３の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
5. 一意の部分的な符号化表現（ＵＰＲ）のうちの該個数Ｍが実質的にライブ・ストリーミング受信側（ＬＳＲ）の数に対応する請求項４に記載のデータ・ライブ・ストリーミング・システム。
6. 該少なくとも１つのライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）からの入力データ（Ｉ）が、リードソロモンベースの損失耐性のあるコード・セグメントによって符号化されるＮ個の一意の部分的な符号化表現（ＵＰＲ）の１つのサブセットによって完全に表される請求項１乃至５の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
7. 該一意の部分的な符号化表現（ＵＰＲ）が、ＬＴベースの損失耐性のあるコード・セグメントによって符号化される請求項２乃至６の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
8. 該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）のうちの少なくとも１つが、データのＮ個の一意の部分的な符号化表現（ＵＰＲ）を復号することによって該ライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）からの符号化データを再生成し、該Ｎ個の一意の部分的な符号化表現（ＵＰＲ）のうちの少なくとも１つが他のライブ・ストリーミング受信側（ＬＳＲ）によって生成される請求項１乃至７の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
9. データの該損失耐性のあるコード表現がフレームで提供される請求項１乃至８の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
10. 該フレームが該ライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）によって生成され、連続して送信されるタイム・フレームを含む請求項９に記載のデータ・ライブ・ストリーミング・システム。
11. 該少なくとも１つのライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）からの入力データ（Ｉ）の表現が、連続するフレームで構築され、フレームの送信が、該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）へのデータ表現の初期送信によって開始され、該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）が、該データ表現又はその派生物を、損失耐性のあるコード・セグメントとして他のライブ・ストリーミング受信側（ＬＳＲ）に流し、受信側がＮ個の一意の損失耐性のあるコード・セグメントを集め、該少なくとも１つのライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）から送信された該フレームをライブ・ストリーミング信号として再生成する請求項１乃至１０の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
12. 該ピアツーピアがグリッドベースのシステムを含む請求項１乃至１１の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
13. 該データがビデオ及び／又は音声ストリームを含む請求項１乃至１２の何れか１項に記載のデータ・ライブ・ストリーミング・システム。
14. ネットワークであって、
    少なくとも１つの入力データ（Ｉ）ブロードキャスタ（ＩＢ）と、
    該少なくとも１つの入力ブロードキャスタ（ＩＢ）からの入力代表データ（ＩＲＤ）を入力データ（Ｉ）の複数のＭ個の一意の部分的な符号化表現（ＵＰＲ）に変換する複数のピア（Ｐ）とを含み、
    該Ｍ個の一意の部分的な符号化表現の複数のコード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）が、該入力データ（Ｉ）の異なるＮ個の一意の部分的な符号化表現（ＵＰＲ）を含み、該複数のコード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）の各々が、該入力データＩを表し、ＮがＭ−１未満である、ネットワーク。
15. 該複数のピア（Ｐ）の各々が、入力データ（Ｉ）の該Ｍ個の一意の部分的な符号化表現（ＵＰＲ）のうちの少なくとも１つを生成する請求項１４に記載のネットワーク。
16. 該コード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）のうちの少なくとも１つが、該入力データ（Ｉ）の符号化バージョンを表す請求項１４又は１５に記載のネットワーク。
17. 該コード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）のうちの少なくとも１つがＬＴベースのコードによって符号化される請求項１４乃至１６の何れか１項に記載のネットワーク。
18. 該コード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）のうちの少なくとも１つがリードソロモンベースのコードによって符号化される請求項１４乃至１７の何れか１項に記載のネットワーク。
19. 該ネットワークが、少なくとも２つの受信側ピア（ＲＰ）を含み、該少なくとも２つの受信側ピア（ＲＰ）が、該コード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）のうちの少なくとも１つを集め、該サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）のうちの少なくとも１つを該符号化データに対応するデータに復号する請求項１４乃至１８の何れか１項に記載のネットワーク。
20. 該少なくとも２つの受信側ピア（ＲＰ）によって行われる該収集が、該複数のピア（Ｐ）のうちの少なくとも１つへの要求に基づいて行われる請求項１９に記載のネットワーク。
21. 該少なくとも２つの受信側ピア（ＲＰ）によって行われる該収集が、該複数のピア（Ｐ）のうちの少なくとも１つによって行われるプッシュ送信に基づいて行われる請求項１９に記載のネットワーク。
22. 該複数のピア（Ｐ）の少なくとも１つが受信側ピア（ＲＰ）を形成する請求項１４乃至２１の何れか１項に記載のネットワーク。
23. 該入力代表データ（ＩＲＤ）が少なくとも２つの中間ピア（ＩＰ）によって少なくとも部分的に確立される請求項１４乃至２２の何れか１項に記載のネットワーク。
24. 該中間ピア（ＩＰ）が入力代表データ（ＩＲＤ）を確立するように構成されている中間処理工程をさらに含む請求項２３に記載のネットワーク。
25. 該複数のピア（Ｐ）の少なくとも１つが、中間ピア（ＩＰ）を形成する請求項１４乃至２４の何れか１項に記載のネットワーク。
26. 該複数のピア（Ｐ）の総数が５より多く、中間ピア（ＩＰ）の数がピア（Ｐ）の総数の１／５から１／１００の間である請求項２３乃至２５の何れか１項に記載のネットワーク。
27. 該入力代表データ（ＩＲＤ）が、該ブロードキャスタ（ＩＢ）から少なくとも２つの中間ピア（ＩＰ）に送信される請求項１４乃至２６の何れか１項に記載のネットワーク。
28. 該少なくとも２つの中間ピア（ＩＰ）が、該入力データ（Ｉ）の部分的な表現のみを受信する請求項２３乃至２７の何れか１項に記載のネットワーク。
29. 該一意の部分的な符号化表現（ＵＰＲ）が、該複数のピア（Ｐ）とは異なる複数のピアによって生成される請求項１４乃至２８の何れか１項に記載のネットワーク。
30. 該複数のピア（Ｐ）とは異なるピアによって該部分的な符号化表現（ＵＰＲ）を生成することによって該一意の部分的な符号化表現（ＵＰＲ）の一意性が確実にされる請求項１４乃至２９の何れか１項に記載のネットワーク。
31. 該複数のピア（Ｐ）のうちの少なくとも１つのピアが、プル・プロセスによって、入力代表データ（ＩＲＤ）を集め、少なくとも１つの一意の部分的な符号化表現に変換する請求項１４乃至３０の何れか１項に記載のネットワーク。
32. 該複数のピア（Ｐ）のうちの少なくとも１つのピアが、プッシュ・プロセスによって、入力代表データ（ＩＲＤ）を集め、少なくとも１つの一意の部分的な符号化表現に変換する請求項１４乃至３１の何れか１項に記載のネットワーク。
33. 該入力データ（Ｉ）がリアルタイム・ベースで該少なくとも１つの入力データ・ブロードキャスタ（ＩＢ）から送信される請求項１４乃至３２の何れか１項に記載のネットワーク。
34. 該入力データ（Ｉ）がフレームでリアルタイム・ベースで該少なくとも１つの入力データブロードキャスタ（ＩＢ）から送信される請求項１４乃至３３の何れか１項に記載のネットワーク。
35. 該ネットワークがビデオ・ストリーミング・ネットワークである請求項１４乃至３４の何れか１項に記載のネットワーク。
36. 該ネットワークが要求に応じてビデオ・ストリーミングを行っている請求項１４乃至３５の何れか１項に記載のネットワーク。
37. 該ネットワークがライブビデオ・ストリーミングを行っている請求項１４乃至３６の何れか１項に記載のネットワーク。
38. 該ネットワークが、インターネットによって形成され、該複数のピア（Ｐ）がインターネットと通信するコンピュータを含む請求項１４乃至３７の何れか１項に記載のネットワーク。
39. 該複数のピア（Ｐ）のうちの少なくとも１つが、他のピアによって生成された入力データ（Ｉ）の部分的な符号化表現（ＵＰＲ）を収集又は使用することなく、入力代表データ（ＩＲＤ）を入力データ（Ｉ）の少なくとも１つの一意の部分的な符号化表現（ＵＰＲ）に変換するコンピュータを含む請求項１４乃至３８の何れか１項に記載のネットワーク。
40. 該複数のピア（Ｐ）のうちの少なくとも１つが、複数のモードの間の切り替えを行うことができ、該複数のモードは、
    該複数のピア（Ｐ）のうちの少なくとも１つが、少なくとも１つの部分的な符号化表現（ＵＰＲ）を生成し、少なくとも１つのコード・サブセット（Ｗ１、Ｗ２、Ｗ３、）を取得するために、該複数のピア（Ｐ）とは異なる他のピアによって生成された部分的な符号化表現を集め、該少なくとも１つのコード・サブセット（Ｗ１、Ｗ２、Ｗ３、）を復号する少なくとも１つのモードと、
    該複数のピア（Ｐ）のうちの該少なくとも１つが、単に、又は主に少なくとも１つの部分的な符号化表現（ＵＰＲ）のプロデューサとして働く少なくとも１つのアイドル・モードとからなる請求項１４乃至３９の何れか１項に記載のネットワーク。
41. 該複数のピア（Ｐ）が、暗黙的又は明示的に該入力データ（Ｉ）で定義される請求項１４乃至４０の何れか１項に記載のネットワーク。
42. 該符号化入力データ（Ｉ）がデータを定義するピアに関連付けられる請求項１４乃至４１の何れか１項に記載のネットワーク。
43. 該一意の部分的な符号化表現（ＵＰＲ）が損失耐性のあるコードを含む請求項１４乃至４２の何れか１項に記載のネットワーク。
44. 該入力データ（Ｉ）がビデオ・ストリーミングを含み、
    該ブロードキャスタ（ＩＢ）がビデオ・ストリーミング・ブロードキャスタを含み、
    該複数のピア（Ｐ）のうちの少なくとも２つがビデオ・ストリームの受信側を含む請求項１４乃至４３の何れか１項に記載のネットワーク。
45. 入力データ（Ｉ）を含む少なくとも１つのデータ・ライブ・ストリーミング・ブロードキャスタ（ＬＳＢ）及び少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）を含む請求項１乃至１３の何れか１項に記載のライブ・ストリーミング・システムにおけるデータのストリーミングの方法であって、
    該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）が該入力データ（Ｉ）の表現を複数の損失耐性のある符号化表現に変換し、
    該少なくとも２つのライブ・ストリーミング受信側（ＬＳＲ）が該複数の損失耐性のある符号化表現を他のストリーミング受信側（ＬＳＲ）に送信する方法。
46. 少なくとも１つの入力データ・ブロードキャスタ（ＩＢ）と、
    該少なくとも１つの入力ブロードキャスタ（ＩＢ）からの入力代表データ（ＩＲＤ）を入力データ（Ｉ）の複数のＭ個の一意の部分的な符号化表現（ＵＰＲ）に変換する複数のピア（Ｐ）とを含む請求項１４乃至４４の何れか１項に記載のネットワークにおいて入力データ（Ｉ）を配布する方法であって、
    該Ｍ個の一意の部分的な符号化表現の複数のコード・サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）が該入力データ（Ｉ）のＮ個の異なる一意の部分的な符号化表現（ＵＰＲ）を含み、各サブセット（Ｗ１、Ｗ２、Ｗ３、．．．）が該入力データＩを表し、ＮがＭ−１未満である方法。

Images