JP2009505502A - ピア・ツー・ピアコミュニティのためのマルチソース且つ復元力のあるビデオ・オン・デマンドストリーミングシステム - Google Patents

Abstract

集中型のビデオ・オン・デマンド（ＶｏＤ）システムでは制限的なコンテンツおよび制限的な保存能力しか提供されない。ピア・ツー・ピアネットワークによりユーザはピア間で直接的にコンテンツを広範に共有することができるが、ピア間のコネクションは制限的なアップリンク帯域幅を有していることがあり、また信頼性が低い可能性がある。本発明によればこれらの問題を解消するために、同種のピア・ツー・ピアネットワーク内の１つまたは複数のソースからのストリーミングデータの高品質且つ復元力のある送信が行われるシステムおよび方法が提案される。

Description

著作権
本願明細書の開示内容の一部は著作権保護を目的とする資料を含む。著作権の所有者は、特許商標庁に申請または記録されている限りにおいて、特許明細書またはその開示のいずれかによるファクシミリの複製に対しては異議を申し立てない。しかしながらそれ以外に関しては全ての所有権は完全に保有される。

関連出願の相互参照
本願は、いずれの発明の名称も"A Multi-Source and Resilient Video Streaming System for Peer-to-Peer Networks"であり、また本願と発明者が同一である、２００５年８月１２日付で出願されたＵＳ仮出願60/708,020（整理番号2005P14442US）および２００５年１２月１２日付で出願されたＵＳ仮出願60/749,730（整理番号2005P22668US）の利益を主張するものであり、また参照によりそれらを本願の一部とする。

技術分野
本発明は、ピア・ツー・ピア加入者コミュニティネットワークにおける１つまたは複数のソースからのストリーミングデータ、より詳細にはオン・デマンドストリーミングデータに関する。

背景技術
セットトップボックス（ＳＴＢ）は、テレビ受像機がＴＶ番組の再生および記録のようなサービスに関してサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。ＳＴＢのパーソナルビデオレコーダ（ＰＶＲ）機能を使用することにより、ユーザは放送されたコンテンツを後で視聴するために記録することができる。

ビデオ・オン・デマンド（ＶｏＤ）システムにより、ユーザは特定のＴＶ番組または他のビデオコンテンツの再生、また場合によってはＳＴＢを使用したそれらの記録を要求することができる。典型的なＶｏＤシステムにおいては、ユーザはＳＴＢを使用して集中型のサービスプロバイダのネットワークに接続することができ、またサービスプロバイダによって提供された利用可能なコンテンツのセレクションを検索するために電子番組表（ＥＰＧ）を使用し、視聴のために番組を選択することができる。ビデオデータは典型的には、ストリーミングデータとしてサービスプロバイダのネットワークを介してユーザのＳＴＢへと伝送される。

また一般的に、ピア・ツー・ピアネットワークによりユーザは同一のネットワークプロトコルおよびソフトウェアを共有し、ユーザを相互に接続することができ、またユーザそれぞれのリソースに直接的にアクセスすることができる。例えば、サービスプロバイダはピア・ツー・ピアネットワークを提供し、コンピュータユーザは自身のコンピュータをそのネットワークに接続し、ユーザそれぞれのリソース、例えばディジタルコンテンツファイルに直接的にアクセスすることができる。サービスプロバイダはピア・ツー・ピアネットワークを提供し、他のデバイス、例えばＳＴＢのユーザは自身のデバイスをそのネットワークに接続し、ビデオコンテンツおよびＴＶ番組が記憶されているユーザそれぞれのリソースに直接的にアクセスすることができる。加入者コミュニティピア・ツー・ピアネットワークにより加入者のコミュニティは相互に直接的にリソースにアクセスすることができる。ユーザは１つまたは複数のピアからデータを典型的にはストリーミングデータとして受信することにより、データをダウンロードすることができる。

サービスプロバイダのネットワークの恒常的に増加している帯域幅および復元力のある要求は１つの挑戦であるが、慣例のストリーミングソリューションではこれらの要求を維持ですることはできない。図１に示されているような現在のＶｏＤソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば２４時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、ＶｏＤシステムの加入者が見たいコンテンツを選択することができ、またコンテンツを見たいときにそのコンテンツを選択できたならば（すなわちオン・デマンド）、ＶｏＤアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減ることになる。

発明の概要
したがって、殊にＶｏＤシステムを拡大するために、本発明はＳＴＢ間のピア・ツー・ピア（ｐ２ｐ）ネットワークに関する。各ＳＴＢは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はＶｏＤ・ツー・ピア（Ｖ２Ｐ）と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアＳＴＢはネットワーク内の他のＳＴＢからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のＶ２Ｐネットワークは事実上加入者コミュニティのためのＶｏＤシステムとなり、このＶｏＤシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび／または記録されたコンテンツを取得し視聴することができる。

典型的には、加入者コミュニティはＳＴＢのセットを含んでいるので、Ｖ２ＰはＳＴＢからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているＶ２Ｐシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなＶ２Ｐシステムは、復元力があり（resilient）且つ高品質のビデオストリーミングに対して責任を負う。

特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは、ダウンロード可能および記録可能なコンテンツを供給するよう動作するサービスプロバイダを含み、このコンテンツはダウンロードまたは記録された後にストリーミングデータとして供給することができる。またシステムは、サービスプロバイダと関連し、且つテレビ受像機との接続に適したデバイスの加入者コミュニティピア・ツー・ピアネットワークを含む。さらにシステムは、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、能動的な供給側およびバックアップ的な供給側を含む供給側のセットとを含む。各供給側はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、各供給側はサービスプロバイダもしくは１つまたは複数の他のノードからコンテンツをダウンロードおよび／または記録した後にオン・デマンドストリーミングデータを供給するよう機能する。受信器は、この受信器による要求に応じて供給側のセットにおける１つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。

別の特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークをサービスプロバイダの加入者に提供するステップと、ダウンロードおよび／または記録され、続けてストリーミングデータとしてオン・デマンドで供給される、ダウンロード可能および記録可能なコンテンツを提供するステップと、加入者コミュニティピア・ツー・ピアネットワークと関連する検索エンジンを提供するステップとを有する。本方法は、加入者を加入者コミュニティピア・ツー・ピアネットワークに接続するステップと、加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索し、１つまたは複数の他の加入者からストリーミングデータとしてそのようなダウンロードおよび／または記録されたコンテンツをオン・デマンドで受信するために、各加入者に検索エンジンの使用を許可するステップとを有する。

さらに別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークと、この加入者コミュニティピア・ツー・ピアネットワークにおけるノードであるストリーミングデータの受信器と、ストリーミングデータの供給側のセットとを有する。供給側のセットは能動的な供給側のセットとバックアップ的な供給側のセットとを有し、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含む。オン・デマンドで受信されるべきストリーミングデータの各ブロックに関して、受信器は、ＦＥＣエンコーディング・オーバヘッド比を使用し、このＦＥＣエンコーディング・オーバヘッド比を用いてＦＥＣエンコーディングされたブロックの個別に割り当てられた少なくとも１つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグし、ＦＥＣエンコーディングされたブロックのセグメントを受信し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、ＦＥＣエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶し、各能動的な供給側とのネットワークコネクションの性能を監視し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施する。

別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークにおける候補供給側のセットから能動的な供給側のセットとなるべき供給側のセットを選択し、候補供給側のセットからバックアップ的な供給側のセットとなるべき別の供給側のセットを選択するステップを有する。本方法は、受信されるべきストリーミングデータの各ブロックに関して、ＦＥＣエンコーディング・オーバヘッド比を使用するステップを有し、このＦＥＣエンコーディング・オーバヘッド比を用いてＦＥＣエンコーディングされたブロックの個別に割り当てられた少なくとも１つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグするステップを有し、ＦＥＣエンコーディングされたブロックのセグメントを受信するステップを有し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、ＦＥＣエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶するステップを有し、各能動的な供給側とのネットワークコネクションの性能を監視するステップを有し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視するステップを有し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施するステップを有する。

別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、ストリーミングデータを有する供給側のセットとを含み、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含み、またストリーミングデータの各ブロックに関して、各供給側は、使用されるべきＦＥＣエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またＦＥＣエンコーディング・オーバヘッド比を使用したブロックのＦＥＣエンコーディングにより生じるＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分を受信し、またＦＥＣエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信するよう動作する。

別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。加入者コミュニティピア・ツー・ピアネットワークにおいて受信器によって受信されるべきストリーミングデータの各ブロックに関して、本方法は、使用されるべきＦＥＣエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またＦＥＣエンコーディング・オーバヘッド比を使用したブロックのＦＥＣエンコーディングにより生じるＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分の受信、またＦＥＣエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートでの受信器への送信を含む。

別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでストリーミングビデオデータを受信するステップと、通常の速度に対応する再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、通常の速度よりも速い速度でバッファから記憶されているストリーミングビデオデータを再生するステップとを有する。本方法はまた、アンダーフロー状態についてバッファを監視するステップを有し、ここでストリーミングレートは再生レートよりも低く、またアンダーフロー状態の検出に基づき、事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップを有する。

さらに別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップと、通常の視聴速度に対応する通常の再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップとを有する。本方法はまた、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信するステップと、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータをバッファから通常の再生速度よりも速い再生レートで再生するステップを含む。

本発明のこれらの特定の実施形態および他の特定の実施形態を以下ではより詳細に説明する。

図面の簡単な説明
本明細書に組み込まれ、また本明細書の一部をなす添付の図面は本発明の種々の実施形態を示し、また以下の説明と関連してそれらの実施形態の説明に使用される。便宜上、全ての図面を通して同一の構成要素または同様の構成要素には同一の参照番号が付されている。
図１は、慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを実施するためのシステムを示す。
図２は、ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて、慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを拡大するためのシステムの実施形態を示す。
図３は、ロングテールを表すグラフを示す。
図４は、ＶｏＤ・ツー・ピア（Ｖ２Ｐ）システムの実施形態を示す。
図５は、Ｖ２Ｐシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。
図６は、Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。
図７は、ピア選択順位方程式のグラフを示す。
図８は、ストリーム管理モジュールの詳細を含む、Ｖ２Ｐ受信器を表すブロック図を示す。
図９は、動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。
図１０は、バッファ管理スキーマを表すグラフを示す。
図１１は、コネクション監視に使用される単純なバイナリツリーを示す。
図１２は、一連のＭＰＥＧフレームを示す。
図１３は、早送り動作をシミュレートするためにビデオデータ間に挿入されたビデオクリップを示す。
図１４は、Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。
図１５は、Ｖ２Ｐシステムを評価するための例示的なセットアップを示す。
図１６は、高帯域幅環境において実施されているＶ２Ｐシステムを示す。
図１７は、Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。
図１８は、ＴＶ視聴行動およびロングテールを表すグラフを示す。
図１９Ａは、Ｖ２Ｐシステムが標準画質（ＳＤ）品質で供給することができる、並行するストリームの数を表すグラフを示す。
図１９Ｂは、Ｖ２ＰシステムがＳＤ品質で供給することができる、ストリームの最大数または累積数を表すグラフを示す。
図２０Ａは、Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。
図２０Ｂは、Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。
図２１Ａは、Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。
図２１Ｂは、Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。
図２２は、Ｖ２Ｐシステムの保存の側面を表すグラフを示す。
図２３は、共通のビデオフレームを識別するための方法を説明するフローチャートである。

実施例の詳細な説明
上述したように、殊にＶｏＤシステムを拡大するために、本発明はＳＴＢ間のピア・ツー・ピア（ｐ２ｐ）ネットワークに関する。各ＳＴＢは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はＶｏＤ・ツー・ピア（Ｖ２Ｐ）と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアＳＴＢはネットワーク内の他のＳＴＢからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のＶ２Ｐネットワークは事実上加入者コミュニティのためのＶｏＤシステムとなり、このＶｏＤシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび／または記録されたコンテンツを取得し視聴することができる。

典型的には、加入者コミュニティはＳＴＢのセットを含んでいるので、Ｖ２ＰはＳＴＢからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているＶ２Ｐシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなＶ２Ｐシステムは、復元力があり且つ高品質のビデオストリーミングに対して責任を負う。

有利には、サービスプロバイダが提供するＶ２Ｐサービスにより、このサービスプロバイダによって管理されているｐ２ｐネットワーク全体への違法的なビデオ配布を阻止することができる。殊に、サービスプロバイダは加入者ＳＴＢによって記録されるコンテンツをサービスプロバイダによって提供されるコンテンツに制限することができるので、新たなビデオコンテンツをＳＴＢに導入するメカニズムは存在しない（すなわち加入者が関与している限りシステムは閉じられている）。ピアＳＴＢ間でのビデオコンテンツのそれ以降の共有は、サービスプロバイダの顧客（加入者）であるＳＴＰピアの閉じられたコミュニティに制限されている。コンテンツの違法な共有が行われることなく、いずれかのパーソナルコンピュータ（ＰＣ）または他の適切なデバイスをｐ２ｐネットワークに接続できるようにこのｐ２ｐネットワークを拡張することができる。

本発明によればサービスプロバイダに関しては、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムおよび方法の種々の実施形態が考えられる。サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムの１つの実施形態は、テレビ受像機と接続されるよう適合されたデバイスの加入者コミュニティピア・ツー・ピアネットワークと、ダウンロードまたは記録された後にストリーミングデータとして供給できるダウンロード可能および記録可能なコンテンツを提供するサービスプロバイダとを含む。このシステムにおいてはコンテンツの受信器とコンテンツを提供するストリーミングデータの供給側のセットとが存在し、この供給側には能動的な供給側とバックアップ的な供給側が含まれる。各供給側は、サービスプロバイダもしくは１つまたは複数の他のノードからコンテンツをダウンロードまたは記録した後にオン・デマンドストリーミングデータを供給するよう機能する。その種のシステムにおける受信器は、この受信器による要求に応じて供給側のセットにおける１つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。受信器および供給側はそれぞれ加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、また各ノードとしてセットトップボックス、またはテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合されている他のデバイスが考えられる。サービスプロバイダは加入者コミュニティにおけるノードによってダウンロードまたは記録可能なオーディオデータ、ビデオデータまたはその両方のようなコンテンツを供給し、またこのダウンロードまたは記録可能なコンテンツを供給側として動作するノードからストリーミングデータとして供給することができる。

種々の実施形態によれば、そのようなシステムを検索エンジンによって向上させることができ、この検索エンジンによりユーザはコンテンツブラウザを使用してコンテンツを検索し、またコンテンツ推薦によって推薦されるコンテンツを受信することができる。別の実施形態によれば、このシステムをさらにインセンティブマネージャによって向上させることができ、このインセンティブマネージャはストリーミングセッションへの関与に関してコンテンツの所有者、サービスプロバイダおよび供給側に報酬を与える。別の実施形態によれば、このシステムを付加的にディジタル権利マネージャによって向上させることができ、このディジタル権利マネージャはコンテンツの違法な配布を阻止する。

前述との関連において、特定の実施形態によれば、本発明はサービスプロバイダの加入者に対して加入者コミュニティピア・ツー・ピアネットワークを提供し、加入者をこのネットワークに接続した後に、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供する方法に関する。本方法は、ダウンロードおよび／または記録され、続けてストリーミングデータとしてオン・デマンドで供給することができる、ダウンロード可能および記録可能なコンテンツの提供を含む。また本方法は、加入者コミュニティピア・ツー・ピアネットワークと関連した検索エンジンの提供と、各加入者による検索エンジンの使用およびオン・デマンドで選択されたデータの受信の許可を含む。殊に、加入者は加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索するために検索エンジンを使用する。続いて、加入者はそのようなダウンロードおよび／または記録されたコンテンツをストリーミングデータとして１つまたは複数の他の加入者からオン・デマンドで受信する。

コンテンツのオン・デマンドの受信に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおける１つまたは複数の供給側からストリーミングデータをオン・デマンドで受信するためのシステムおよび方法を提供する。そのようなシステムは受信器として機能するノードと、ストリーミングデータの供給側として機能するノードのセットと包含し、このノードのセットには能動的な供給側およびバックアップ的な供給側が含まれる。換言すれば、受信器ならびに供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。そのようなシステムにおける受信器はオーディオデータ、ビデオデータまたは両方を含むストリーミングデータを受信する。受信すべきストリーミングデータの各ブロックに関して、受信器はＦＥＣエンコーディング・オーバヘッド比を使用し、また各能動的な供給側に個別に割り当てられたデータレートで、ＦＥＣエンコーディング・オーバヘッド比を使用してＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分を送信することをシグナリングする。受信器はＦＥＣエンコーディングされたブロックのセグメントを受信し、セグメントの集合体に基づきＦＥＣエンコーディングされたブロックをデコーディングし、またデコーディングされたブロックをバッファに記憶する。ここで各セグメントは個別に割り当てられた小部分の一部を表す。受信器は能動的な供給側をそれぞれ有しているネットワークコネクションの性能を監視し、また結果としてオーバーフローまたはアンダーフローが生じる状態を検出するためにバッファを監視する。コネクションの性能およびバッファの状態に基づき、受信器はバッファのアンダーフローまたはオーバーフローへの到達を回避するために品質適合を実施する。監視によりストリーミングセッションの中間における供給側の障害またはコンテンツの削除が検出され、またこの供給側の障害およびコンテンツの削除を処理するために、能動的なセットに付加的なバックアップピア、能動的な供給側の間でのレートの再分布およびＦＥＣエンコーディング・オーバヘッド調整のような一連の技術が使用される。

既述のように、各受信器および各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、またその種の各デバイスをテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合させることができる。換言すれば、その種のデバイスは種々の実施形態に応じてセットトップボックス、パーソナルコンピュータまたはモバイル装置でよい。各デバイスは受信器、供給側またはその両方として機能することができる。供給側は１つまたは複数のメトリクスのあらゆる組み合わせに基づき選択される。このメトリクスには供給側の供給状態または受信状態、利用可能なアップリンク帯域幅、処理能力、信頼性記録（reliability history）、パス待ち時間、パケット損失および公平性が含まれる。供給側の信頼性記録は特定の実施形態に応じて、デバイス故障率、ネットワーク接続時間およびコンテンツアベイラビリティを基礎とする。公平性はロードバランシングおよび先行の選択記録を基礎とする。

特定の実施形態によれば、その種のシステムにおける受信器は、各能動的な供給側とのネットワークコネクションの性能の監視に基づいてストリーミングセッションに適合されるよう機能する。このようなネットワークコネクションの性能には、供給側がネットワークの不安定性、デバイス故障、またはストリーミングデータとして供給すべきコンテンツの削除を経験したか否かの検出を含む。また受信器は他の供給側から実際に受信したストリーミングデータのメトリクスに基づいて各ネットワークコネクションの性能を受動的に監視するよう機能する。また受信器は、目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを含むバッファの監視に基づいてストリーミングセッションを適合させる。必要に応じて受信器は能動的な供給側間のレート分布、供給側のセットまたはＦＥＣエンコーディングパラメータを動的に調整することができる。受信器は新たなデータレートを割り当てることによって、または新たなブロックの小部分を割り当てることによって、能動的な供給側間のレート分布を調整するよう機能する。受信器は種々の実施形態に応じて、能動的な供給側を付加または除去することによって、バックアップ的な供給側を能動的な供給側のセットに付加することによって、またはバックアップ的な供給側のセットに供給側を付加することによって能動的な供給側のセットを調整することができる。受信器は新たなＦＥＣエンコーディング・オーバヘッド比または新たなＦＥＣエンコーディングスキーマを使用することによって、ＦＥＣエンコーディングパラメータを調整することができる。ＦＥＣエンコーディング・オーバヘッド比を使用することによって、受信器は供給側によって使用されるべきＦＥＣエンコーディング・オーバヘッド比を１つのブロックの後続のＦＥＣエンコーディングにおいてセットすることができるか、単純に、ＦＥＣエンコーディング・オーバヘッド比を使用してＦＥＣエンコーディングされている事前エンコーディングされたブロックを選択するよう供給側にシグナリングすることができる。

その種のシステムにおける受信器は特定の実施形態に応じて、能動的な供給側のセット間でストリーミングデータのソースとして使用されるべきメディアファイルの複数の個々のコピーにおける共通の始点も求める。受信器は期間を規定し、また各能動的な供給側から基準オブジェクトのセットを受信する。期間は加入者コミュニティネットワークと接続されているデバイスのクロック同期に関連させてもよい。各基準オブジェクトはその期間内にメディアファイルの個々のコピーにおいて現われる基準フレームに対応する。受信器は、基準オブジェクトの全てのセットに共通する共通の基準オブジェクトを識別するために、受信した基準オブジェクトのセットを比較し、共通の基準オブジェクトに対応する基準フレームとなるよう始点をセットする。ビデオファイルにおいては、各基準フレームはビデオフレームであり、また各基準オブジェクトはハッシュ値である。

コンテンツのオン・デマンドの供給に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおけるストリーミングデータをオン・デマンドで供給するためのシステムおよび方法を提供する。その種の実施形態はこのネットワークにおけるノードである受信器と、ストリーミングデータの複数のブロックの供給側のセットとを包含し、供給側のセットにおける各供給側もこのネットワークにおけるノードである。供給されるストリーミングデータの各ブロックに関して、その種のシステムにおける各供給側は、使用されるべきＦＥＣエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータ比、またＦＥＣエンコーディング・オーバヘッド比を使用したブロックのＦＥＣエンコーディングにより生じるＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分を受信する。続いて各供給側はＦＥＣエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信する。

前記に付加的に、本発明の種々の実施形態はストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートするシステムおよび方法を含む。ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法の１つの実施形態は、ストリーミングビデオデータのストリーミングレートでの受信、受信したストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためのバッファへの記憶、ストリーミングレートが再生レートよりも低いアンダーフロー状態に関するバッファの監視、および記憶されているストリーミングビデオデータ間におけるバッファへの所定のビデオクリップの挿入を含む。

ストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートする方法の別の実施形態は、ストリーミングレートでのビデオファイルからのストリーミングビデオデータの受信、受信したストリーミングビデオデータを通常の視聴速度に対応する通常の再生レートで後に再生するためのバッファへの記憶を含む。この方法はさらに、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生または巻き戻し再生のための命令の受信、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータの受信、およびスピードアップされた再生レートでの再生をシミュレートするための、記憶されているストリーミングビデオデータのバッファからの通常の再生速度よりも速い再生レートでの再生を含む。その種の方法は、記憶されているストリーミングビデオデータ間における所定のビデオクリップのバッファへの挿入も含む。

以下の記述では、本発明の複数の実施形態および本発明の実践形式が示されている添付の図面を参照する。他の実施形態を使用することもでき、また本発明の範囲を逸脱することなく構造的および機能的な変更も行えるものと解される。

本発明の特定の実施形態を説明するためのコンテクストを提供するために、図１は慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを実現するシステムを示す。インフラストラクチャベースのメディアストリーミングまたは集中型のビデオ・オン・デマンド（ＶｏＤ）ソリューションは一般的に１つまたは複数のメディアサーバ、また通常はセットトップボックス（ＳＴＢ）であるクライアントのセットを有する。メディアサーバはクライアントへのメディアのオン・デマンドストリーミングに対して責任を有する。場合によっては、ＶｏＤシステムはさらにキャッシングプロキシを有することができる。図１に示されているように、サービスプロバイダＶｏＤシステム１００は管理インフラストラクチャ１１０、メディアサーバ１２０およびコンテンツライブラリ１３０を有する。ここではセットトップボックス（ＳＴＢ）として示されているクライアントデバイス１４０はサービスプロバイダ１００と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ１３０からオン・デマンドで受信する。管理インフラストラクチャ１１０はクライアントデバイス１４０からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダ１００とクライアントデバイス１４０との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ１２０は要求されたメディアの管理インフラストラクチャ１１０を介したコンテンツライブラリ１３０からクライアントデバイス１４０へのオン・デマンドでのストリーミングを実施する。

前述したように、図１に示されているような慣例のＶｏＤソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば２４時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、ＶｏＤシステムの加入者がまさに視聴したいコンテンツを見たいときに視聴できる権限が与えられれば（すなわちオン・デマンド）、ＶｏＤアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減る。

セットトップボックス（ＳＴＢ）は、このＳＴＢのパーソナルビデオレコーダ（ＰＶＲ）機能を使用したＴＶ番組の再生および記録のようなサービスに関してテレビ受像機がサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。本発明の１つの実施形態によれば、全ての加入者のＳＴＢはサービスプロバイダが管理するピア・ツー・ピア（ｐ２ｐ）ネットワークに接続され、したがってサービスプロバイダのネットワークのあらゆる加入者は、それらの加入者のＳＴＢにダウンロードおよび／または記録されたビデオコンテンツを他の加入者のＳＴＢにストリーミングすることができる。

例えば、いずれの加入者もサービスプロバイダによって提供されるあらゆるＴＶ番組または他のコンテンツを自身のＳＴＢにダウンロードおよび／または記録することができる。他の加入者にコンテンツを利用できるようにするために、コンテンツを自動的にサービスプロバイダのｐ２ｐネットワークに自動的に通知または登録することができる。ネットワークのいずれの加入者もこのコンテンツを検索し、視聴することができる。Ｖ２Ｐと称されるそのようなシステムはＳＴＢによって形成されるｐ２ｐネットワークに関するマルチソースビデオストリーミングシステムである。つまり、Ｖ２Ｐは複数のＳＴＢからの高品質且つ復元力のあるビデオストリーミングを提供する。

これに関して図２は、本発明の１つの実施形態によるコミュニティＶｏＤシステムを構築するために、ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを拡大するシステムを示す。図示されているように、サービスプロバイダＶｏＤシステム２００は管理インフラストラクチャ２１０、メディアサーバ２２０、コンテンツライブラリ２３０およびサービスプロバイダによって管理されるピア・ツー・ピア（ｐ２ｐ）ネットワーク２５０を有する。さらにｐ２ｐネットワーク２５０は、ここではセットトップボックス（ＳＴＢ）として示されているピアデバイス２６０ａ，２６０ｂ，２６０ｃ（以下ではピアデバイス２６０と称する）と拡張コンテンツライブラリ２７０ａおよび２７０ｂ（以下では拡張コンテンツライブラリ２７０と称する）を有する。拡張コンテンツライブラリ２７０はピアデバイス２６０に記憶されているダウンロードおよび／または記録されたコンテンツを有する。例えば、ピアデバイス２６０はコンテンツライブラリ２３０から管理インフラストラクチャ２１０を介してストリーミングされたメディアをダウンロードおよび／または記録および記憶することができる。ｐ２ｐネットワーク２５０に接続されているあらゆる加入者によって記録された拡張コンテンツを用いるＶｏＤシステムのコンテンツライブラリの拡張によりコンテンツの選択肢が増え、また共通のＶｏＤシステムが構築される。

特定の実施形態によれば、ここではセットトップボックス（ＳＴＢ）として示されているクライアントデバイス２４０はサービスプロバイダＶｏＤシステム２００と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ２３０から、または拡張コンテンツライブラリ２７０からオン・デマンドで受信する。管理インフラストラクチャ２１０はクライアントデバイス２４０からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダＶｏＤネットワーク２００とクライアントデバイス２４０との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ２２０は要求されたメディアの管理インフラストラクチャ２１０を介したコンテンツライブラリ２３０からクライアントデバイス２４０へのオン・デマンドでのストリーミングを実施する。またクライアントデバイス２４０は要求したメディアの拡張コンテンツライブラリ２７０からのオン・デマンドのストリーミングを要求することができる。ｐ２ｐネットワーク２５０はこれらの要求を処理し、またｐ２ｐネットワーク２５０とクライアントデバイス２４０との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアの拡張コンテンツライブラリ２７０からクライアントデバイス２４０へのオン・デマンドのストリーミングを実施する。

Ｖ２Ｐソリューションは必ずしも図１に示されているような集中型のＶｏＤソリューションに代わるものを意味していないが、図２に示されているように、そのようなソリューションについての補完的な分散型の拡張として使用することができる。ＶｏＤとＶ２Ｐは一緒に膨大な量のコンテンツを加入者にもたらすことができる。集中型のＶｏＤは非常に人気のある大多数のコンテンツプログラムを提供し続けることができ、これに対しＶ２Ｐはいわゆる「ロングテール」市場を提供することに良く適している。

図３は、ロングテールを表すグラフを示す。図３によれば、膨大な量になる余り人気のないアイテムの集合体を合計すれば組織に関して多額の利益になる可能性がある。多くのビジネスでは、少数のオーディエンスにのみ関心があるコンテンツアイテムを売ることによって利益を得ることができる。これらのあまり人気のないコンテンツアイテムはそのようなオンラインビジネスに関してロングテールを作り上げることができる。ロングテールからコンテンツアイテムを提供することにより、顧客は以前見つからなかったコンテンツを発見、購入、および照会することができる。同様にして、Ｖ２Ｐはビデオ・オン・デマンド市場に関するロングテール現象にレバレッジを導入することができ、これにより、それらのあまり人気のない番組の反復的な視聴から収入を得ているコンテンツ所有者およびサービスプロバイダの双方にとって強力なビジネスモデルが実現される。さらにＶ２ＰはこれらのＳＴＢリソースを供給する加入者に報酬を与える。

Ｖ２Ｐ技術は慣例のストリーミングソリューションでは取り組むことができなかった多くの技術的な要求（限定的なアップストリーム帯域幅や復元力が含まれる）に取り組んでいる。

現在では、ＤＳＬおよびケーブルモデムは家庭での使用に関する２つの一般的なブロードバンド技術である。両方とも非対称的な帯域幅特性を有する。つまりダウンロード帯域幅はアップロード帯域幅よりも高い。各ＳＴＢに対するアップロード帯域幅の制約を解消するために、Ｖ２Ｐはストリーミングソースとして複数のＳＴＢを使用し、また受信側のＳＴＢはこれらの複数の供給側からのストリーミングセッションを調整する。アップロード帯域幅もダウンロード帯域幅も増大したとしても、Ｖ２Ｐは対称的な帯域幅環境でも非対称的な帯域幅環境でも高品質且つ復元力のあるストリーミングを提供するために依然として使用することができる。

ネットワークおよびデバイスはまだ完璧なものではなく、つまり復元メカニズムは逆の条件を考慮するために設計されなければならない。ｘＤＳＬまたはケーブルモデムコネクションを介するＶ２Ｐストリームおよびネットワーク自体の信頼性が高くないので、不安定なネットワークを介する復元力のあるストリーミングがＶ２Ｐに関する１つの争点である。如何なる時点においてもＳＴＢはスイッチオフされる可能性がある。もしくはコンテントがストリーミングセッション中に削除される可能性がある。継続的且つ円滑なストリーミングを提供するために、Ｖ２Ｐは非常に耐性の高いエラー回復メカニズムを要求する。特定の実施形態によれば、Ｖ２Ｐはリンクならびにデバイスの不信頼性に取り組み、また高品質のストリーミングを提供するために、インテリジェントなピア選択、フォワード・エラー・コレクション（ＦＥＣ）、動的なレート分布、動的なバッファ管理、ネットワークトモグラフィを基礎とするコネクション監視のようなメカニズムの組合せを使用する。

図４は、ＶｏＤ・ツー・ピア（Ｖ２Ｐ）システムの実施形態を示す。図示されているように、Ｖ２Ｐシステム４００は受信器４１０、送信器４２０ａ，４２０ｂおよび４２０ｃ（以下では送信器と称する）、リソース管理フレームワーク（ＲＭＦ）４３０ならびにインセンティブマネージャ４４０を有する。また図４にはサービスプロバイダ４５０およびコンテンツ所有者４６０も示されている。ここではセットトップボックス（ＳＴＢ）として示されている受信器４１０は受信側のピアであり、送信器４２０からストリーミングメディアを受信する。ここではセットトップボックス（ＳＴＢ）として示されている送信器４２０は送信側のピアであるか、ストリーミングメディアの供給側である。受信器４１０は時には送信側のピアとしても動作できることを言及しておく。同様に、送信器４２０のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク（ＲＭＦ）４３０はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器４１０と送信器４２０との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またＲＭＦ４３０により受信器４１０は送信器４２０にダウンロードおよび／または記録され記憶されたストリーミング可能なコンテンツ、例えばメディアファイルについてＶ２Ｐシステム４００を検索することができる。またＲＭＦ４３０により受信器４１０はコンテンツ推薦を受信することができる。インセンティブマネージャ４４０はＶ２Ｐシステムを使用する会計状況を管理する。これには、ストリーミングメディアとして特定のコンテンツを受信した受信器への課金、ストリーミングメディアの供給側への報酬またコンテンツの各ストリーミングに対するサービスプロバイダ４５０およびコンテンツ所有者４６０への報酬が含まれる。

図４に示されているＶ２Ｐシステムはマルチソースストリーミングシステムである。このことは、各ストリーミングセッションが１つの受信器と送信器または供給側のセットを含むことを意味している。１つの基本的な仮定は、各供給側が所定のコンテンツアイテムに対応するメディアファイルの同一のコピーを有しているということである。しかしながら、供給側のＳＴＢが同期しておらず、またそれらＳＴＢのメディアファイルのコピーが完全に同一でない場合には、特定の実施形態によるＶ２Ｐは複数の供給側からのストリーミングメディアを同期するメカニズムを提供する。以下ではこの同期メカニズムを詳細に説明する。Ｖ２Ｐはメディアファイルを（例えば１〜２秒の再生に適した）小さいデータブロックのセットに分割し、各ソースが同一のブロックの小部分を提供する。その結果、全ての供給側が１つのファイルの各ブロックに寄与することになる。

例えば、特定の実施形態によれば、パケット損失を許容するためにメディアファイルの各ブロックをフォワード・エラー・コレクション（ＦＥＣ）コードを用いて符号化することができる。ＦＥＣエンコーディングスキーマは２つのパラメータ（ｎ，ｋ）で表され、データブロック毎にｎ個のパケットがｋ個のパケット（但しｎ＞ｋ）の代わりに送信される。ｎ個のパケットの中からのいずれかのｋ個のパケットはブロックを再構築することができる。したがって、ストリーミングセッションはブロック毎に（ｎ−ｋ）個までのパケットの損失を許容することができる。ＦＥＣエンコーディング・オーバヘッド比αは次式のように定義される。

ＦＥＣエンコーディング・オーバヘッド比およびエンコーディングスキーマはストリーミングセッションに関するストリーミングレートおよびパケット損失許容度に対して多大な影響を及ぼす。したがってＦＥＣエンコーディング・オーバヘッド比をストリーミングセッションの特定のエンコーディングスキーマに関して確立することができる。１つの例において、ＦＥＣエンコーディング・オーバヘッド比は供給側によって使用されるべきエンコーディングパラメータを確立するために使用され、また別の例において、ＦＥＣエンコーディング・オーバヘッド比は特定のエンコーディングパラメータに適しているデータのＦＥＣエンコーディングされたブロックを選択するよう供給側にシグナリングするために使用することができる。一例として、図５は本発明の１つの実施形態によるＶ２Ｐシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。ストリーミングセッションは、特定のメディアファイルのような特定のコンテンツに関するストリーミング要求を行う受信器によって開始される。

ステップ５１０では、要求されたメディアファイルを供給することができる候補供給側のセットを取得する。候補供給側は、要求されたメディアファイルのコピーを有するピアである。例えば、受信器はＶ２Ｐシステムにおける特定のコンテンツを検索するために検索エンジンを使用して、コンテンツの候補供給側のセットを取得することができる。

ステップ５２０では、受信器が候補供給側のセットから能動的な供給側のセットおよびバックアップ的な供給側のセットを選択する。能動的な供給側は、要求されたメディアファイルを受信器にストリーミングするためにストリーミングセッション中に協力的に動作するピアである。バックアップ的な供給側は、１つまたは複数の能動的な供給側がネットワークの不安定性、デバイス故障またはコンテンツの損傷または削除に遭遇した場合に、ストリーミングセッション中に支援することができるピアである。受信器は種々の判定基準、例えばピアの状態、利用可能なアプリンク帯域幅、処理能力、信頼性記録、パス待ち時間、パスパケット損失および公平性のメトリクスなどに基づきピアを選択することができる。

ステップ５３０では、受信器が各能動的な供給側との制御コネクションを開始する。受信器は公知の多数の技術の中からいずれか１つを使用することができる。例えば、受信器は伝送制御プロトコル（ＴＣＰ）を使用して制御パケットを送信することができる。

ステップ５４０では、各能動的な供給側が受信器とのデータコネクションを開く。受信器は公知の多数の技術の中からいずれか１つを使用して、供給側からストリーミングデータを受信することができる。例えば、受信器はユーザデータグラムプロトコル（ＵＤＰ）を基礎とするスキーマを使用してストリーミングデータを受信することができる。

ステップ５５０では、受信器は各能動的な供給側にＦＥＣエンコーディングされたブロックの少なくとも１つの小部分を割り当てられたデータレートで送信するようシグナリングすることによって、供給側からのＦＥＣエンコーディングされたブロックの小部分を要求する。割り当てられたデータレートの合計は目標のストリーミングレートを表す。各能動的な供給側はＦＥＣエンコーディングされたブロックの一部を送信し、このブロックの一部は特定のＦＥＣエンコーディング・オーバヘッド比を有する特定のＦＥＣエンコーディングスキーマを使用してＦＥＣエンコーディングされている。各能動的な供給側は、ＦＥＣエンコーディングされたブロックの少なくとも１つの小部分を送信するための信号を受信器から受信すると、特定のＦＥＣエンコーディング・オーバヘッド比αを使用して特定のブロックをＦＥＣエンコーディングすることができる。択一的に各供給側は、１つまたは複数のＦＥＣエンコーディング・オーバヘッド比を使用してブロックを事前エンコーディングすることができ、また受信器からの信号の受信に応答して、事前エンコーディングされたブロックの一部を選択することができる。

ステップ５６０では、受信器がＦＥＣエンコーディングされたブロックの部分またはセグメントを受信する。ネットワークの不安定性、デバイス故障ならびにコンテンツの損傷または削除に起因して、受信器はＦＥＣエンコーディングされたブロックの要求した小部分を実際には全て受信できない可能性がある。受信器が受信する部分またはセグメントは、受信器がステップ５５０において要求したＦＥＣエンコーディングされたブロックの小部分に対応する。実際に受信した部分またはセグメントに基づき、受信器は実際の受信データレートを求めるために各能動的な供給側とのコネクションの性能を受動的に監視する。実際の受信データレートの合計は現在のストリーミングレートを表す。

ステップ５７０では、受信器がエンコーディングされたブロックの受信した部分またはセグメントに基づきブロックをデコーディングし、デコーディングされたブロックをバッファに記憶する。ブロックのデコーディングには、受信した部分またはセグメントからのＦＥＣエンコーディングされたブロックの再構築、再構築されたＦＥＣエンコーディングされたブロックのＦＥＣデコーディング、また使用される特定のビデオエンコーディングスキーマ（例えばＭＰＥＧ）に応じたＦＥＣデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。受信器は目下の再生レートでのバッファからの再生のためにデータを消費する。

ステップ５８０では、受信器がバッファの状態を検査する。目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを監視することによりバッファの状態を評価することができる。これらのメトリクスに依存して、バッファは３つのゾーン、すなわち加速ゾーン、快適ゾーンまたは減速ゾーンの内の１つにおいて動作することができる。例えば、バッファが快適ゾーンにおいて動作している場合には、受信器はステップ５８２ｂに進み、ストリーミングセッションを継続する。バッファが加速ゾーンまたは減速ゾーンにおいて動作している場合には、受信器はステップ５８２ａに進む。

ステップ５８２ａでは、受信器がバッファのオーバーフローまたはアンダーフローを回避するために１つまたは複数のストリーミングレート、能動的なセットにおける供給側およびエンコーディング・オーバヘッド比を必要に応じて調整する。いずれかの供給側が能動的な供給側のセットに加えられる場合には、ステップ５３０および５４０が実施される。

ステップ５８２ｂでは、受信器がストリーミングセッションは終了したか否かを求める検査を実施する。ストリーミングセッションが終了している場合には、プロセスがステップ５９０において終了する。ストリーミングセッションが終了していない場合には、プロセスはステップ５５０に戻る。

したがってＶ２Ｐにおけるストリーミングセッションの一例は以下のステップを含む：
１．先ず、受信器ピアＰ０はｐ２ｐネットワークの検索エンジンから候補供給側のセットを取得する。

２．候補供給側のセットから、受信器ピアＰ０は能動的な供給側としてピアＰ１，Ｐ２〜ＰＮのセットを選択し、またバックアップ的な供給側としてＰ１，Ｐ２〜ＰＭのセットを選択する。

３．受信器ピアＰ０は能動的なセットにおける各供給側との制御コネクションを開始することによりストリーミングセッションを始める。

４．制御コネクションを受信した後に、各供給側Ｐｉは受信器ピアＰ０とのデータコネクションを開く。

５．受信器ピアＰ０は各供給側に特定のエンコーディング・オーバヘッド比αでエンコーディングされた特定のブロックの小部分を送信するよう周期的にシグナリングする。

６．各供給側Ｐｉはファイルブロックをエンコーディングし、特定のレートにしたがいファイルファイルの小部分を送信する。

７．各ブロックに関して十分なデータを受信した後に、受信器ピアＰ０はブロック全体をデコーディングし、バッファに記憶する。受信器側における再生器はバッファからデータを使用する。

受信器ピアＰ０は、再生器に供給するためにデータが常にバッファ内に存在すること、またバッファオーバーフローを回避するためにバッファは一杯でないことを保証するためにネットワーク変化およびデバイス故障に反応する。必要に応じて、受信器ピアＰ０は１つまたは複数のバックアップ的なピアを能動的な供給側のセットに付加し、また新たに付加された幾つかのピアに対してステップを３〜４回繰り返す。

受信器ピアＰ０はセッションが終了するまでステップを５〜７回繰り返す。

図６はＶ２Ｐシステムのブロック図を示し、またさらに本発明の１つの実施形態による受信器を示す。この実施形態において、Ｖ２Ｐシステム６００は受信器６１０、送信器６２０、リソース管理フレームワーク（ＲＭＦ）６３０およびインセンティブマネージャ６４０を有する。受信器６１０はストリーミングデータを受信するために送信器６２０と対話する。受信器６１０はユーザがｐ２ｐネットワークを検索できるようにするためにＲＭＦ６３０と対話する。受信器６１０はインセンティブマネージャ６４０と対話し、このインセンティブマネージャ６４０はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。

図６によれば、受信器６１０はさらにピア選択モジュール６１１０、ストリーム管理モジュール６１２０、インタラクティビディ管理モジュール（この実施形態においては再生器モジュールと表記する）６１３０、品質適合モジュール６１４０、コンテンツ検索およびコンテンツ推薦モジュール６１５０、照会モジュール６１６０およびデータ管理モジュール６１７０を有する。

一時的に、ピア選択モジュール６１１０は能動的なピアおよびバックアップ的なピアまたは特定のコンテンツのストリーミングデータの供給側を選択するためにピア選択プロセスを使用する。ストリーム管理モジュール６１２０は能動的な供給側との制御コネクションおよびデータコネクションを管理し、能動的な供給側からのストリーミングデータを受信し、またストリーミングデータをデコーディングしてバッファに記憶する。またこのストリーム管理モジュール６１２０はバッファを管理し、ストリーミングレートを各能動的な供給側に動的に分布させ、受信器と各能動的な供給側との間のコネクションを監視し、またユーザからのインタラクティブな再生要求を管理する。この実施形態においては再生器６１３０モジュールとして示されているインタラクティビディ管理モジュール６１３０はインタラクティブな再生制御を提供し、またストリーム管理モジュール６１２０と対話するので、ユーザはストリーミングセッション中の一時停止、早送りおよび巻き戻しを行うことができる。品質適合モジュール６１４０はストリーム管理モジュール６１２０およびピア選択モジュール６１１０と対話し、ネットワークの不安定性、能動的な供給側の障害およびコンテンツの損傷または削除が生じた場合には、復元力があり且つ高品質のストリーミングを提供する。場合によっては、品質適合モジュール６１４０はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。

コンテンツ検索およびコンテンツ推薦モジュール６１５０はＲＭＦ６３０と対話し、特定の実施形態によれば、これによりユーザは特定のコンテンツを検索することができ、またコンテンツ推薦をユーザに提供することができる。参照モジュール６１６０はＲＭＦおよびピア選択モジュール６１１０と対話し、遠隔のピアに関する情報を取得する。データ管理モジュール６１７０は受信したストリーミングデータの受信器の局所的な記憶装置における記憶を管理する。以下ではこれらのモジュールをそれぞれ説明する。

ピア選択モジュール６１１０は能動的なピアのセットおよびバックアップ的なピアのセットを求めるためにピア選択プロセスを使用する。能動的なピアはストリーミングセッションのコンテンツを提供する。バックアップ的なピアはいずれかのＳＴＢの故障中、またその時点における能動的なピアが目標のストリーミングレートを提供することができないときにネットワークが不安定になっている間に活動状態になる。またバックアップ的なピアを、ストリーミングセッション中に１つまたは複数の能動的なピアがコンテンツを削除するか、コンテンツの損傷が生じると活動状態にすることができる。

この実施形態においては、ピア選択が２つのステップで実施される。第１のステップにおいては、ＲＭＦ６３０がストリーミングされるコンテンツを有する候補供給側のセットを戻す。典型的な候補供給側のセットの大きさは１５〜２０のピアである。メディアファイルの複数のコピーがネットワーク内で発見された場合、この選択プロセスは限定的なリソースを有するピアを排除する。ＲＭＦ６３０から候補供給側のセットを取得した後に、ピア選択モジュール６１１０は種々の判定基準に基づき能動的なピアのセットおよびバックアップ的なピアのセットを求める。例えば、後続のピアの状態、帯域幅、デバイス特性、信頼性、待ち時間、損失比および公平性に関する判定基準を使用することができる。

１．ピア状態（Ｓ）
ピアの状態をピア選択の間に考慮することができる。ピアがストリームを受信している場合には、アップリンクは使用することができない。しかしながら、受信側のピアが別のストリーミングセッションを提供することを決定し、アップリンクがこの提供のために完全に使用される場合には、受信するストリーミングの品質は劣化することになる。何故ならば、シグナリングプロトコルはアップリンクの小さい小部分を使用するからである。したがって、供給側としてアイドル状態のピアを使用することが望ましい。ピアのＳＥＲＶＩＮＧ（提供）状態またはＲＥＣＥＩＶＩＮＧ（受信）状態の間に、ピア選択モジュール６１１０はピアｉに対してＳ_i＝ａ_iを割り当て、ここでａは利用可能なリソースに基づき計算される。ピアがＩＤＬＥ（アイドル状態）であり、且つ提供のためのリソースを有する場合には通常Ｓ_i＝１である。

２．供給側の利用可能なアップリンク帯域幅（Ｂ）
ストリーミングセッションに関して過剰に多いピアまたは過剰に少ないピアを使用することは望ましくない。過剰に多いピアが使用される場合には、受信器は多数のコネクションを維持しなければならない。１つまたは２つの供給側が使用される場合には、１つの供給側の故障はストリーミング品質に非常に重大な影響を及ぼすことになる。ストリーミングレートがＲ₀である場合、ピア選択モジュール６１１０は、ピアｉが≧Ｒ₀／３を提供できる場合にはＢ_i＝１を割り当て、ピアが≧Ｒ₀／４を提供できる場合にはＢ_i＝０．７５を割り当て、これ以降は同様のことが繰り返される。

３．ＣＰＵ、記憶スペース（Ｃ）
ＳＴＢが適当なＣＰＵおよび記憶スペースを有する場合には、ピア選択モジュールはピアを受け入れることができる。ピア選択モジュールは、ピア状態がＳＥＲＶＩＮＧまたはＲＥＣＥＩＶＩＮＧでないときに、ピアｉがＣＰＵ４００ＭＨｚ以上を有し、且つＲＡＭが１２８ＭＢ以上であればＣ_i＝１を割り当てる。ＳＴＢがストリーミングセッションに関与するためには十分なリソースを有していない場合にはＣ_ｉ＝０である。

４．信頼性記録（Ｈ）
信頼性記録Ｈは如何なる時点においてもスイッチオフされる可能性のあるＳＴＢの信頼性を表す。ＳＴＢのコンテンツはストリーミングセッション中に削除される可能性がある。したがってＳＴＢの信頼性記録は復元力のあるストリーミングの提供に対して著しい影響を及ぼす。ピア選択モジュールは信頼性メトリクスに０〜１の値を割り当てる。

５．供給側から受信器までのパス待ち時間（Ｄ）
待ち時間または一方向遅延を、供給側が受信器からどれほど離れているかを決定するために使用することができる。供給側が非常に良好なリソースを有しているとしても、ピアが世界の反対側に位置している場合には、安定したレートでストリーミングを提供することはできない。供給側が受信器の同一のサブネット内に存在するか、受信器が存在している同一の地理的なロケーション内に供給側が存在する場合、通常の場合待ち時間は実際に低く、またこれらの供給側は受信器から遠く離れて存在している供給側を上回る性能を有する。ピア選択モジュールは、ピアｉが５０ｍｓ以下の往復遅延時間（以下ではＲＴＴと称する）の距離にある場合にはＤ_i＝１を割り当て、ピアｉが１００ｍｓ以下のＲＴＴの距離にある場合にはＤ_i＝０．５を割り当て、ピアｉが２００ｍｓ以上のＲＴＴの距離にある場合にはＤ_i＝０を割り当てる。

６．パスのパケット損失比（Ｌ）
パケット損失比はネットワークの信頼性を表す。損失比の範囲は０＜Ｌ＜１である。

７．公平性（Ｆ）
ピア選択メカニズムにおける第一の重要性はストリーミングの品質であり、したがってこのメカニズムは受信器に適したストリーミングセッションに関する最善のピアのセットを選択する。しかしながら、（リソース、信頼性および他のピア選択判定基準に関して）同等の品質を有する複数のピアを利用できる場合には、他のピアに比べて選択される頻度が低いピアに優先権が与えられる。

上記の判定基準に基づき、ピア選択モジュールは各ピアの順位を計算することができる。Ｒ_ｉがピアｉの順位を表す場合にはＲ_ｉを以下のように表すことができる：
Ｒ_ｉ＝Ｃ_ｉＳ_ｉ（Ｂ_ｉＤ_ｉ）Ｈ_ｉ（１−Ｌ_ｉ）。
ピア選択プロセスはこの順位に基づき上位のＮ＋Ｍ個のピアを選択する。種々のピアが（Ｎ＋Ｍ）番目の順位を有する場合には、ピア選択プロセスは公平性インデクス（Ｆ）が低いピアを選択し、全ての加入者はコンテンツアイテムを提供する機会を得て、またシステムから報酬を得る。

図７はピア選択順位方程式のグラフであり、また使用されるピア選択判定基準にしたがいピアの順位をどのように変更できるかを示す。例えば、図７には高帯域幅（例えば３８４Ｋｂｐｓ以上のアップリンク帯域幅）のピアの順位および低帯域幅（例えば１２８Ｋｂｐｓ以上のアップリンク帯域幅）のピアの順位が遅延および損失のメトリクスに関してプロットされている図示されているように、受信器から遠く離れて位置する高帯域幅のピアは受信器の近くに位置する低帯域幅のピアに比べて低い順位を有する可能性がある。

ネットワーク内のコンテンツを検索している間に、リソース管理フレームワーク（ＲＭＦ）６３０（図６を参照されたい）はコンテンツを有するピアの長いリストを戻すことができる。ピア選択アルゴリズムを検索結果の全体のリストに適用できない可能性がある。例えば、提供に従事しているピアまたはアップリンク容量が低いピアまたは地理的なロケーションにおいて遠く離れているピアを放棄することによって初期リストをフィルタリングすることはより効率的である。ピア選択アルゴリズムを実施するためにフィルタリングされたリストから例えば１５〜２０のピアのセットが使用され、また選択シーケンスはアップリンク容量および地理的なロケーションを基礎とする。ピア選択に必要とされる測定を初期バッファリング時間中に実際のメディアデータを用いて実施することができる。例えば、最初の１０秒間に各ピアは供給側の品質を求めるためにメディアファイルの一部を提供することができる。

ストリーミングセッションに関してどれほど多くの能動的なピアが要求されているかを求めるために、ピア選択モジュールは次式を使用することができる。

ここで、目標のストリーミングレート＝Ｒ₀
能動的なピアの数＝Ｎ
ピアｉによって提供されるレートｉ＝Ｒ⁰ _i
ピアｉからの初期ストリーミングレートＲ_ｉ＝βＲ⁰ _i（但しβは容量利用度。０＜β≦１であり、ピアｉは１００％の容量利用度以下で動作する）
ＦＥＣオーバヘッド＝α
ＦＥＣによるパケット損失許容度＝α／（１＋α）。

一例として、ストリーミングレートが１．１Ｍｂｐｓであり、α＝０．２０ＦＥＣである場合、要求されるストリーミングレートは１．３２Ｍｂｐｓである。各ピアはアップリンクストリーミング帯域幅Ｒ⁰ _i＝２５６Kｂｐｓを有するようになる。β＝０．８である場合にはＲ_i＝２４８である。したがってＮ＝７であり、ピア選択モジュールは５〜７個の能動的なピアをそれらのピアの出力帯域幅に基づき選択することができる。

図６を再び参照し、さらには図８を参照しながら、特定の実施形態によるストリーム管理モジュール６１２０を説明する。図８はＶ２Ｐ受信器のブロック図を示し、また本発明の１つの実施形態によるストリーム管理モジュールを示す。図８によれば、受信器８１０はストリーム管理モジュール８１２０および再生モジュール８１３０を有する。特定の実施形態によれば、ストリーム管理モジュール８１２０はストリームモジュール８１２１、受信データモジュール８１２２（この実施形態においては受信データ／ＦＥＣデコードモジュール８１２２として示されている）、バッファ管理モジュール８１２３、コネクション監視モジュール８１２４および動的レート分布モジュール８１２５を有する。

動作時に、ストリームモジュール８１２１は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉し、またデータブロックのどの部分をどのデータレートで送信するかを指示する制御パケットを能動的な供給側に送信する。この実施形態においては受信データ／ＦＥＣデコードモジュール８１２２として示されている受信データモジュール８１２２は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール８１２３に転送する。バッファ管理モジュール８１２３はデコーディングされたストリーミングデータを受信データモジュール８１２２から受信し、ユーザが一時停止、早送り、巻き戻しを行えるように再生モジュール８１３０と対話し、またバッファを管理し、さらにはバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール８１２５と対話する。コネクション監視モジュール８１２４は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール８１２５と対話する。動的レート分布モジュール８１２５はバッファ管理モジュール８１２３およびコネクション監視モジュール８１２４と対話し、またネットワークの不安定性およびデバイス故障に対処するためにストリーミングレートを能動的な供給側に動的に分布する。

ストリームモジュール８１２１は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉する。ストリームモジュール８１２１は、各供給側との１つの制御コネクションを開くことによって能動的なセットにおける全ての供給ピアとの通信を確立し、また理想的には、制御コネクションは信頼性が高いものであることが期待される。例えば、伝送制御プロトコル（ＴＣＰ）を使用することができる。またストリームモジュール８１２１は各供給側に受信器とのデータパスの確立に関する制御情報をシグナリングする。またストリームモジュール８１２１はデータブロックのどの部分がどのデータレートで送信されるかを指示する制御パケットを能動的な供給側に送信する。これは能動的な供給側間でのストリーミングレートの動的なレート分布をなす。制御パケットは送信すべきブロックの小部分およびデータレートを表す。レート分布は動的レート分布モジュール８１２５に由来する。

この実施形態においては受信データ／ＦＥＣデコードモジュール８１２２として示されている受信データモジュール８１２２は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール８１２３に転送する。受信データモジュール８１２２はストリームモジュール８１２１によって全ての能動的な供給側からデータを受信することが指示され、また能動的な供給側はこのモジュールとのデータパスを確立する。特定の実施形態によれば、Ｖ２Ｐはデータストリーミングに関してユーザデータグラムプロトコル（ＵＤＰ）のようなプロトコルを使用することができる。択一的に別の実施形態においては、Ｖ２ＰはＵＤＰを基礎とするあらゆる輻輳制御プロトコル、例えばデータグラム輻輳制御プロトコル（ＤＣＣＰ）などを使用することができる。ストリーミングデータの受信に基づき、受信データモジュール８１２２はこのストリーミングデータをバッファ管理モジュール８１２３に引き渡す前にデコーディングを行う。ブロックのデコーディングには、受信した部分またはセグメントからのＦＥＣエンコーディングされたブロックの再構築、再構築されたＦＥＣエンコーディングされたブロックのＦＥＣデコーディング、また使用される特定のビデオエンコーディングスキーマ（例えばＭＰＥＧ）に応じたＦＥＣデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。

バッファ管理モジュール８１２３はデコーディングされたストリーミングデータを受信データモジュール８１２２から受信し、ユーザが一時停止、早送りおよび巻き戻しを行えるよう再生モジュール８１３０と対話する。バッファ管理モジュール８１２３はバッファを管理し、またこのバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール８１２５と対話する。例えば、ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール８１２３はストリーミングレートを調整するために動的レート分布モジュール８１２５と対話する。またバッファ管理モジュールはメディアデータを再生するためにバッファには常にデータが存在することを保証する。例えば、再生は初期バッファリング時間（例えば１０秒）または短い宣伝の直後に開始することができる。その後、バッファ管理モジュール８１２３は目下の再生レートおよびストリーミングレートにより近い将来バッファは空にならないか、またはオーバーフローしないかを周期的に評価する。必要に応じて、動的レート分布モジュール８１２５によりストリーミングレートを相応に調整することができる。

図９は、本発明の１つの実施形態により、動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。このグラフにおいて、Ｂ（ｔ）は時間ｔにおいてバッファに記憶することができる最大累積データを表し、Ｐ（ｔ）は時間ｔにおいて再生器によって消費される累積データを表す。このグラフから見て取れるように、固定ビットレート（ＣＢＲ）のストリーミングレートはバッファオーバーフローまたはバッファアンダーフローを容易に引き起こす可能性がある。動的バッファ管理アルゴリズムはストリーミングレートを周期的に調整することによってこれらのシナリオを回避する。

例えば、固定ビットレート（ＣＢＲ）のストリーミングレートは、バッファが将来オーバーフローしないこと、もしくは空にならないことを保証することができない。何故ならばネットワーク状態は変化し、またピアがあらゆる時点において故障する可能性があるからである。したがって、複数のパラメータに基づきストリーミングレートを調整する動的バッファ管理技術を使用することができる。このパラメータの例として以下のものが挙げられる：
ａ）目下のバッファサイズ
ｂ）目下の再生レート
ｃ）目下のストリーミングレート。

図１０は、本発明の１つの実施形態によるバッファ管理スキーマを表すグラフを示す。図示されているように、バッファは３つの部分、すなわち加速ゾーン(０＜バッファサイズ＜Ｂ_min)、快適ゾーン（Ｂ_min＜バッファサイズ＜Ｂ_max）、減速ゾーン（バッファサイズ＞Ｂ_max）に分割されている。Ｂ_minおよびＢ_maxの値はシステムにおける許容バッファサイズに依存する。例えば、システムが３０秒のバッファリングを有することができる場合には、Ｂ_min＝１０秒およびＢ_max＝２０秒を選択することができる。ストリーミングレートは目下のバッファサイズならびに、目下のストリーミングレートおよび再生レートを使用して計算されるバッファの変化に基づき調整される。目下のバッファサイズがＢ_min以下であり、且つバッファサイズの変化が負である場合には、ストリーミングレートが高められる。ストリーミングレートは快適ゾーンにおいては変化しない。バッファサイズがＢ_maxを上回る場合には、ストリーミングレートが低められる。

レートを計算して目下のストリーミングレートを調整するために、バッファ管理モジュール８１２０はその時点におけるストリーミングレートの指数加重移動平均（ＥＷＭＡ）を使用する。一般的にＥＷＭＡは次式のように表される：
Ｒ_avg（ｔ）＝ｗＲ（ｔ）＋（１−ｗ）Ｒ_avg（ｔ−１）
ここで、０＜ｗ＜１は目下のその時点におけるサンプルまたは最近の記録を重み付けするための定数である。

例えば、バッファ管理モジュールはバッファサイズの各ゾーンに関してｗを規定する。バッファが加速ゾーンにおいて動作している場合には、ストリーミングレートを調整するために、その時点におけるストリーミングレートが強調されなければならない。したがってこのゾーンにおいてはｗに比較的高い重みが与えられている。バッファが快適ゾーンにおいて動作している場合には、平滑なストリーミングレートを計算するためにｗには比較的低い重みが与えられており、これは減速ゾーンにおいてストリーミングレートを調整するために使用することができる。減速ゾーンにおいては、ストリーミングレートをより積極的に減速するためにαに高い重みが与えられている。

図８を再び参照すると、コネクション監視モジュール８１２４は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール８１２５と対話する。コネクション監視は、供給側から受信器へのいずれかのデータパスに輻輳が生じていないか否か、またはいずれかのピアが故障していないか否かを検出するための有用なメカニズムである。例えば、受信器が特定の時間枠の間に所定のピアから何のデータも受信しない場合には、ピアがもはや生きていないことが想定される。

ネットワーク輻輳の個所を厳密に特定することは比較的困難である。ネットワーク輻輳の個所が既知である場合には、品質適合モジュール（図６の項目６１４０）は供給側と受信器との間の各コネクションをどのように処理するかを決定することができる。例えば、１つのコネクションしかネットワーク輻輳の影響を受けない場合には、他のコネクションはこの輻輳を克服するためにより高いレートでデータを提供することができる。しかしながら、コネクションの大部分に同時に輻輳が発生している場合には、バックアップ的なピアのセットからピアを付加し、それらのピアからの付加的なストリーミングにより輻輳の効果を緩和させることが必要となる。

コネクション監視モジュール８１２４は輻輳が生じているパスセグメントを識別するためにネットワークトモグラフィ技術を使用することができる。ネットワークトモグラフィの基本的な思想にはパケット「ストライプ」（すなわちバック・ツー・バック検査パケット）の使用が含まれ、このパケット「ストライプ」は目的地におけるストライプ内のパケット損失の相関を計算することによってリンク損失が推測される。損失を推測するために、ストライプと称される一連の検査パケットが１つのノードから０伝送遅延を有する他の２つのノードに送信される。パケットがいずれかの受信器に到達すると、このパケットが分岐点に到達していなければならないことを推測することができる。エンドホストに到達したパケットの数に基づき、全ての内部リンクに関する伝送成功確率を計算することができる。

コネクション監視モジュール８１２４はコネクションを受動的に監視する。すなわち、ストリーミング中に能動的な検査は行われない。コネクション監視モジュール８１２４はストリーミングデータを使用する。複数の供給側から１つの受信器へのデータが生じるのではなく、むしろ幾つかのネットワークトモグラフィ技術においては１つのソースから複数の受信器へのデータが生じる。

受信器が共有パスならびに固有のパスにおけるパケット損失の相関を取得できるようにするために、必要に応じて、適切なストライプのサイズを評価し、また供給側間においてパケットをどのように分割するかについての実験が実施される。供給側から受信器へのパスの特性を評価することもできる。図１１は、２つの供給側Ｓ₁およびＳ₂から１つの受信器Ｒへの単純なバイナリツリーを示す。供給側はブロックのパケットを送信するために時間と同期されているので、Ｓ₁およびＳ₂からのパケットが共有パスセグメントｋ→Ｒにおいて同様の輻輳を経験する確率が高い。Ｄ（Ｄ＝＜Ｄ₁，Ｄ₂＞）個のパケットのストライプを使用することができ、ここではＳ₁がＤ₁個のパケットを送信し、またＳ₂がＤ₂個のパケットを送信する。ＲがＳ₁からのストライプの全てのパケットを取得すると、Ｓ₂→ｋにおいてパケットが損失しない限り、ＲはＳ₂からのＤ₂個のパケットを受信する確率が高い。

図８を再び参照すると、動的レート分布モジュール８１２５はバッファ管理モジュール８１２３およびコネクション監視モジュール８１２４と対話し、また輻輳およびデバイス故障に起因するネットワークの不安定性に対処するためにストリーミングレートを能動的な供給側に動的に分布する。

動的レート分布モジュール８１２５は目下のストリーミングレートを何時でも変更することができる。ストリームモジュール８１２１は、新たなレートを規定するために制御信号を各時間枠に各能動的な供給側へ送信するコネクション監視モジュール８１２４はどのコネクションに輻輳が生じているかを検出し、バッファ管理モジュール８１２３は目下のストリーミングレートはどのようであるべきかを検出し、また動的レート分布モジュール８１２５は時間ｔにおいて各供給側がストリーミングを行うべきレートを検出する。続いて、ストリームモジュール８１２１は各供給側に制御パケットを送信し、新たなレートおよびファイルセグメントの新たなインデクスで供給側は次の時間枠において送信を行うべきことを通知する。

図８を参照しながら、ここでは再生モジュール８１３０として示されているインタラクティビディ管理モジュールを特定の実施形態にしたがい説明する。再生モジュール８１３０はインタラクティビティを提供するので、ユーザはストリーミングセッションを一時停止、早送り（ＦＦ）および巻き戻し（ＲＷ）することができる。以下において詳細に説明するこれらの各イベント中に、再生モジュール６１３０はこのイベントに基づき適切な動作を実施するバッファ管理モジュール８１２３に情報を通知する。

先ず一時停止に関する制御を説明する。ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール８１２３は動的レート分布モジュール８１２５に新たなストリーミングレート、例えば０Ｋｂｐｓを分布することをシグナリングする。動的レート分布モジュール８１２５はストリームモジュール８１２１にストリーミングセッションを一時停止することをシグナリングする。ストリームモジュール８１２１は制御信号を各能動的な供給側に送信し、ストリーミングセッションが再開されるまで、または一時停止時間が経過するまで、ストリーミングセッションは一時停止される。ストリーミングセッションが一時停止されている間、受信器は能動的な供給側からのいかなる付加的なストリーミングデータも要求しない。ストリーミングセッションが再開されると、ストリームモジュール８１２１はストリーミングセッションを再開するために制御信号を各能動的な供給側に送信する。一時停止時間が経過すると、ストリーミングセッションは閉じられる。

次に早送り（ＦＦ）および巻き戻し（ＲＷ）に関する制御を説明する。受信器が局所的な記憶装置、例えばハードディスクを有している場合には、ＲＷ動作は既に記憶されているコンテンツに基づき実施される。そうでない場合には、ＲＷおよびＦＦを同様のやり方で実施することができる。複数のアプローチをＦＦ動作に関連付けることができる。１つ目のアプローチはＶＣＲのような平滑なインタラクティビディを提供するために別個のインタラクティブストリームを使用する。しかしながら、各メディアファイルに対して別個のインタラクティブストリームが要求されることになる。２つ目のアプローチは、付加的なストリームを使用せずに探索メカニズムを用いて早送りまたは巻き戻しを達成するソリューションである。

殊に、インタラクティブストリームを使用する場合には、ＦＦ動作は別個のストリーム（すなわちインタラクティブストリーム）および別個のバッファ（すなわちインタラクティブバッファ）を要求する。巻き戻し動作に関して、インタラクティブストリームは再生ストリームとは逆の順番で形成される。早送りおよび巻き戻しの間に供給側はストリームの１つのサブセットしか送信できず、オリジナルのストリームを送信しないので、別個のインタラクティブストリームが要求される。別個のインタラクティブストリームが使用されなければ、供給側はストリームをデコーディングし、関心のある適切なフレームを送信しなければならなくなる。それらをリアルタイムで達成することは不可能であろう。したがって、この技術は目標のＦＦ速度またはＲＷ速度を達成することができるフレームを有する別個のストリームを使用する。例えば、Ｘの加速係数を達成するために、再生器はＸフレーム以外の１つを要求する。しかしながらＭＰＥＧ技術においては、Ｉフレームおよび／またはＰフレーム無しではＢフレームをデコーディングすることができず、また先行のＩフレームまたはＰフレーム無しではＰフレームをデコーディングすることができない。したがって、Ｘフレーム以外の１つを送信しても早送りイベントにとっては十分ではない。

図１２は、ストリーミングセッションの一連のＭＰＥＧフレームを示す。加速係数５を得るためには、供給側はＩ，（Ｐ，Ｂ，Ｂ，Ｐ），（Ｉ，Ｂ，Ｂ，Ｐ）〜を送信する必要がある。何故ならば、Ｂフレームはデコーディングのために自身に隣接するフレームを両方とも必要とし、またＰフレームは先行のＩフレームまたはＰフレームを必要とするからである。したがって、ストリームを５倍加速させるためには、フレームの１／５以上が供給側によって送信されなければならない。その結果このプロセスによりＦＦおよびＲＷ中のストリーミングデータレートは高まる。ところが、ＤＳＬベースのネットワークにおけるストリーミングデータレートを高められない可能性がある。このＤＳＬベースのネットワークではダウンリンク速度が通常のストリーミングレートに対してのみ有効であることが多い。

ＦＦおよびＲＷ中の比較的低いデータレートを維持するために、特定の実施形態によればインタラクティブストリームを使用することができる。インタラクティブストリームを以下のように生成することができる。オリジナルのビデオマテリアルは圧縮の前にサブサンプリングされなければならない。Ｘ倍の早送り速度に関して、各Ｘ番目のビデオフレームはＭＰＥＧエンコーディングの前に適切なデバイスに記憶されなければならない。例えば４倍の早送り速度を達成するためには、各４番目のビデオフレームが使用される。このコンテンツは通常のやり方でＭＰＥＧエンコーディングされ、別個のファイルに記憶される。この方法により動きが非常に滑らかな非常に高品質のＦＦの視聴が実現されるが、サブサンプリングされた非圧縮のビデオの中間的な記憶が要求される。

サブサンプリング前処理および中間的な記憶という付加的な作業を回避するために、特定の実施形態によればＭＰＥＧ圧縮領域においてＦＦを達成することができる。各送信器はＦＦ中の要求を処理するために動的にＩフレームをトランスコーディングし、Ｉフレームを１つだけ有するＧＯＰ（Group of Pictures）を生成するために、このトランスコーディングされたＩフレームをシーケンスヘッダに含ませる。そのようなスキーマを実施するために、各送信器はＩフレームをオン・デマンドでトランスコーディングできなければならない。

図８を再び参照すると、インタラクティビディを提供するためにバッファ管理モジュール８１２３は２つのバッファ、すなわち標準的なストリーム用のバッファおよびインタラクティブストリーム用のバッファを維持する必要がある。標準的な再生が行われている間はユーザがＦＦまたはＲＷを選択できるようにバッファ管理モジュール８１２３はＩフレームのみをインタラクティブバッファに置き、再生モジュール８１３０はインタラクティブバッファからデータを即座に受信する。バッファ管理モジュール８１２３は、ユーザが通常の再生モードに戻るまで再生器にインタラクティブバッファからデータを供給する。ストリームモジュール８１２１は、この期間中にインタラクティブストリームからのデータを送信するよう各供給側に制御信号を送信するＮ個のＩフレームが既にインタラクティブバッファに存在するので、各供給側は１つのＩフレームを送信する。ユーザは１つのＩフレームから次のＩフレームに早送りすることができる。インタラクティブバッファにデータが存在しない場合には、再生モジュール８１３０はユーザによるＦＦ／ＲＷを許可せず、通常の再生を再開する。ユーザが通常の再生を再開すると、バッファ管理モジュール８１２３は標準バッファから再生モジュール８１３０にデータを供給する。標準バッファが通常の再生のために十分なデータを有していない場合には、標準バッファがフルレートでの再生のために十分なデータを有するまで数秒にわたりサブサンプリングされたデータを再生することができる。

特定の実施形態によれば、ＦＦ動作およびＲＷ動作をシミュレートするための択一的なアプローチにおいて、特定のインタラクティブストリームを有するという要求を回避するためにファイル探索が使用される。殊に、ユーザがＦＦまたはＲＷボタンを押すと、再生モジュール８１３０はＸ秒のビデオデータを再生し、次いで加速を達成するためにファイル内の適切な位置へとＹ秒ジャンプする。全ての供給側はＸ秒に対応するビデオデータを提供し、次のビデオデータを取り出すためにファイル内をＹ秒探索する。

特定の実施形態によれば、ＸおよびＹの値を設定することによって可変の加速を達成することができ、また加速係数を次式に従い計算することができる：

例えば、Ｘ＝２秒且つＹ＝６秒であれば、加速係数は４である。

再生モジュール８１３０が通常の速度でビデオデータを再生すると、ストリーミングデータ内の一時的な位置がジャンプに起因して前進するが、ユーザは加速係数を認識しない。したがって再生モジュール８１３０は通常の速度よりも速い速度でビデオデータを再生する。例えばＤＳＬネットワークにおいては加速を行えない可能性があるので、供給側が標準ストリーミングレートでストリーミングデータを送信し続けると、バッファはより高速な再生レートに起因して空になる可能性がある。この問題を解決するために、再生モジュール８１３０は受信器に局所的に記憶されている短いビデオクリップを再生することができる。短いビデオクリップをストリーミングデータのブロック間のバッファに挿入することができる。例えば、挿入されたビデオクリップはＦＦまたはＲＷイベントに基づいた動画化された「>>」または「<<」でよい。そのような短い動画化されたビデオクリップは、システムが幾つかの処理を実行していることを視聴者に知らせることができる。そのようなビデオクリップをストリーミングする必要がないように、ビデオクリップを受信器側において予め生成して記憶することもできる。

図１３は、一連のビデオデータおよび挿入されたビデオクリップを示す。図示されているように、再生モジュール８１３０は挿入されたビデオクリップが続く４秒のビデオクリップを再生し、１２秒ジャンプし、挿入されたビデオクリップが続く４秒のビデオクリップを再生し、さらに１２秒ジャンプし、また４秒のビデオクリップを再生する。再生モジュール８１３０は通常の速度の２倍の速度でビデオデータおよびビデオクリップを再生する。この実施例において、Ｘ＝４，Ｙ＝１２且つ挿入されたビデオクリップの長さがＸ＝４である場合には、加速係数は次式により与えられる。

上述したようなブロードバンドデータの受信に関してデータストリーミングの品質を改善するために使用される本発明の１つの態様は品質適合を含む（図６に示されているような品質適合モジュール６１４０を使用し、また図８に示されているようなストリーム管理モジュール８１２０を参照する）。品質適合は、復元力があり且つ高品質のストリーミングの提供にとって重要な要素である。ストリーミング品質はネットワークの不安定性およびデバイス故障が生じている間に劣化する。両方の問題に対処するために、Ｖ２Ｐは以下のようなメカニズムを使用する：
ａ）インテリジェントなバッファ管理
ｂ）コネクション監視
ｃ）動的なレート分布
ｄ）動的なＦＥＣエンコーディング／デコーディング
ｅ）能動的なピアの選択（Ｎ個の能動的なピア）
ｆ）バックアップ的なピアの選択（Ｍ個のバックアップ的なピア）。

最初の２つのメカニズムはエラー状態を検出し、輻輳の現在の箇所を識別するために使用される。残りの４つのメカニズムはネットワークの不安定性およびデバイス故障に対処するために使用される。これらの２つのシナリオを説明する。場合によっては、品質適合モジュール６１４０はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。

ネットワークの不安定性に対処するための品質適合プロセスを特定の実施形態にしたがい説明する。インターネットはベストエフォートサービスであり、いずれかのエンド・ツー・エンドパスの待ち時間、損失およびジッタのようなネットワークレイヤメトリクスは時間毎に変化する可能性がある。コネクション監視メカニズムはネットワークの輻輳の現在の箇所を識別することができる。例えば、Ｋ個のコネクションには何時でも品質的な劣化が生じるものとする。先ず、品質適合モジュール６１４０はストリーミングレートの合計が目標のストリーミングレートにまだ達していないか否かを検査する。このような条件が満たされていない場合には、良好なネットワーク状態を有する能動的な供給側が他の能動的な供給側によっては供給されないレートを調整するためにより一層供給するために、ストリーミングレートは再分布される。そのような動的なレート再分布は、能動的な供給側がその完全な容量よりも低いレートでストリーミングを行うように能動的なピアの選択が行われるので可能である。残りの超過容量を、各能動的な供給側からのストリーミングレートの動的な再分布に使用することができる。能動的な供給側が目標のストリーミングレートを提供できない場合、品質適合モジュール６１４０はピア選択モジュール６１１０に１つまたは複数のバックアップ的なピアを能動的なセットに付加することを指示することができる。全てのバックアップを付加した後に、能動的な供給側が高パケット損失のために依然として目標のストリーミングレートを提供できない場合は、品質適合モジュール６１４０はストリーム管理モジュール６１２０にＦＥＣエンコーディング・オーバヘッド比（α）を目下の損失率を基礎として高めることを指示する。例えば、α＝０．２０であり、且つ目下の損失率が３５％である場合、αの新たな値は将来の変更に耐えるために損失比に適合するよう調整される。損失比が暫くして下がると、適合モジュールは相応にαの値を下げる。

例として、品質適合モジュール６１４０は、ネットワークの不安定性に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム（アルゴリズム１）を説明する。図示されているアルゴリズムは、目下のストリーミングレートが目標ターゲットレートＲ₀よりも僅かに高いことを保証するためにδを使用し、さもなければ僅かなネットワーク不安定性を有し、ストリーミング品質は低下することになる。ラプタ符号（Raptor code）が使用される場合、δはラプタデコーディングのために必要とされる余剰データを表す。何故ならば、この符号はデコーディングのために本来のコンテンツよりも５％多いデータを要求するからである。

特定の実施形態によるこのアルゴリズムにおいては、ステップ１において、ストリーム管理モジュール６１２０のコネクション監視モジュール（例えば図８のコネクション監視モジュール８１２４）はＮ個の能動的な供給側を有するＮ個のコネクションを監視し、また時点ｔにおいて輻輳が生じているＫ個のコネクションを識別する。ステップ２においては、目下の合計ストリーミングレート（すなわち全てのＲ_ｉの和）が少なくともδだけ目標ストリーミングレートＲ₀を上回る場合、すなわち

である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール６１４０は何もしない。さもなければ、品質適合モジュール６１４０はステップ３において輻輳が生じていない能動的なセットにおける（Ｎ−Ｋ）個の「良好な」ピア間でのストリーミングレートの再分布を試みる。

これらの（Ｎ−Ｋ）個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの（Ｎ−Ｋ）個の「良好な」ピアの残りの超過容量を目標のストリーミングレートＲ₀を達成するために使用することができる。すなわち、（Ｎ−Ｋ）個の各「良好なピア」をその完全な容量Ｒ⁰ _iまでのレートでストリーミングすることができる。したがって、輻輳が生じているＫ個のピアに関する目下の合計ストリーミングレート（すなわち、これらのＫ個のピアに関する全てのＲ_iの和）に（Ｎ−Ｋ）個の「良好なピア」の完全な容量（すなわち、これらの（Ｎ−Ｋ）個のピアに関する全てのＲ⁰ _iの和）を足した合計が少なくともδだけ目標のストリーミングレートＲ₀を上回る場合、すなわち、

の場合、品質適合モジュール６１４０はストリーム管理モジュール６１２０に（例えば、動的レート分布モジュールを介して）、目標ストリーミングレートを達成するために（Ｎ−Ｋ）個の良好なピアにストリーミングレートを再分布することを指示する。さもなければステップ４において、品質適合モジュールはピア選択モジュール６１１０に、能動的な供給側の更新された数Ｎが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。

アルゴリズムはステップ３に戻り、品質適合モジュール６１４０はストリーム管理モジュール６１２０に（例えば動的レート分布モジュールを介して）、目標ストリーミングレートを達成するために（Ｎ−Ｋ）個の良好なピアにストリーミングレートを再分布することを指示する。ステップ４において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール６１４０はネットワークにおけるパケット損失を調整するためにエンコーディング・オーバヘッド比αを調整する。品質適合モジュール６１４０はまたピア選択モジュール６１１０に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。

別の態様はデバイス故障に対処するための品質適合プロセスである。殊に特定の実施形態によれば、ストリーミングセッションはＮ個の能動的なピアで始まり、各ピアはβの容量利用度を有する。Ｖ２Ｐは、ピアのうちの１つ（すなわちＳＴＢのうちの１つ）が故障している場合には、ピアのアップロード容量限界を上回ることなく能動的なセット内の残りのピアにストリーミングレートを即座に再分布できるようにβを選択する。したがって、１つのピアがいずれかの時点に故障すると、ストリーミングレートが残りの能動的な供給側にわたり再分布され、合計ストリーミングレートは目標レートを下回らない。２つまたはそれ以上のピアが同時に故障すると、品質適合モジュールは能動的な供給側にバックアップ的なピアを付加することができる。

例として、品質適合モジュールは、デバイス故障に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム（アルゴリズム２）を特定の実施形態にしたがい説明する。Ｋ個のデバイス（すなわちＳＴＢ）が故障すると、品質適合モジュール６１４０はストリーム管理モジュール６１２０に（例えば動的レート分布モジュールを介して）、能動的なセットにおける残りの供給側間でストリーミングレートを再分布することを指示する。品質適合モジュール６１４０はまたピア選択モジュール６１１０に、次のデバイス故障に取り組むために能動的な供給側のセットにバックアップ的なピアを付加することを指示する。能動的なセット内の残りの供給側が目標のレートを提供できず、且つネットワークにおいて高い損失が発生していない場合は、品質適合モジュール６１４０はストリーム管理モジュール６１２０に、目下の損失率を調整するためにＦＥＣエンコーディング・オーバヘッド比αを下げることを指示する。より多くの供給側が必要とされる場合、品質適合モジュール６１４０はピア選択モジュール６１１０に、バックアップのセットに付加的な供給側を付加することを指示する。バッファ管理モジュールは典型的に、再生モジュールが利用できるデコーディングされた５〜１０秒のデータを維持し、この場合、品質適合モジュール６１４０は目標ストリーミングレートを達成するために、能動的なセットにより多くのバックアップ的な供給側を付加することができる。

上述したように、ステップ１においてはコネクション監視モジュールがＫ個の故障したＳＴＢを識別する。ステップ２においては、能動的なセットにおける残りの供給側の目下の合計ストリーミングレート（すなわち全てのＲ_ｉの和）が少なくともδだけ目標ストリーミングレートＲ₀を上回る場合、すなわち

である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール６１４０は何もしない。さもなければ、品質適合モジュール６１４０はステップ３において故障していない能動的なセットにおける（Ｎ−Ｋ）個の「良好な」ピア間でのストリーミングレートの再分布を試みる。これらの（Ｎ−Ｋ）個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの（Ｎ−Ｋ）個の「良好な」ピアの残りの超過容量を目標のストリーミングレートＲ₀を達成するために使用することができる。すなわち、（Ｎ−Ｋ）個の各「良好なピア」をその完全な容量Ｒ⁰ _iまでのレートでストリーミングすることができる。したがって、（Ｎ−Ｋ）個の「良好なピア」の完全な容量（すなわち、これらの（Ｎ−Ｋ）個のピアに関する全てのＲ⁰ _iの和）が少なくともδだけ目標のストリーミングレートＲ₀を上回る場合、すなわち、

の場合、品質適合モジュール６１４０はストリーム管理モジュール６１２０に（動的レート分布モジュールを介して）、目標ストリーミングレートを達成するために（Ｎ−Ｋ）個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール６１４０はピア選択モジュール６１１０に、能動的なセットにバックアップ的なピアを付加することを指示する。

さもなければステップ４において、品質適合モジュール６１４０はピア選択モジュール６１１０に、能動的な供給側の更新された数Ｎが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。ステップ４において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール６１４０はネットワークにおけるパケット損失を調整するためにＦＥＣエンコーディング・オーバヘッド比αを調整することができる。品質適合モジュール６１４０はストリーム管理モジュール６１２０に（例えば動的レート分布モジュールを介して）、目標ストリーミングレートを達成するために能動的なセットにおける（Ｎ−Ｋ）個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール６１４０はまたピア選択モジュール６１１０に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。

図６を再び参照し、特定の実施形態によるコンテンツ検索およびコンテンツ推薦モジュール６１５０を説明する。コンテンツ検索およびコンテンツ推薦モジュールによりユーザは自身が関心を持つコンテンツを検索することができる。ユーザインタフェース（ＵＩ）によりユーザは以下のような電子番組表（ＥＰＧ）データに基づきコンテンツを検索することができる：
ａ）タイトル、
ｂ）俳優／女優
ｃ）監督、
ｄ）年、
ｅ）国、
ｆ）ジャンル、
ｇ）賞、
ｈ）スポーツ、ＴＶドラマ、ニュース、コンサートなどのカテゴリ
ｉ）物語における何らかのキーワード。

参照モジュール６１６０は、動作の以下の詳細を前提として、ピアに関する情報の取得を容易にする。参照モジュール６１６０は、ＳＴＢのリソース情報、例えばＣＰＵ、メモリおよびアップストリーム帯域幅を参照するために遠隔のピアに試験を送信する。この試験は、例えばピアが目下アップロードまたはダウンロードを行っているか、もしくはアイドルモードであるかのような状態情報およびピアの信頼性記録の参照でよい。参照モジュール６１６０はピアのインセンティブ記録を戻すことができ、このインセンティブ記録をピア選択モジュール６１１０によるピア選択の間の公平性を調べるために使用することができる。

データ管理に関して、データ管理モジュールはストリーミングされたデータをハードディスクのような局所的な記憶装置に記憶することができる。例えばＵＤＰを使用して信頼性のないチャネルを介してストリーミングが行われると、セッション中に幾つかのパケットが失われる可能性がある。受信器はＦＦメカニズムの使用に基づき全てのパケットを有している必要はない。したがってデータ管理モジュール６１７０は、受信器が将来において供給側となるべく完全なファイルを有するために、ストリーミング後に能動的な供給側と接触し、それらの失われたセグメントをダウンロードすることができる。

供給側がどのように動作するかを理解するために、図１４はＶ２Ｐシステムのブロック図を示し、またさらに本発明の１つの実施形態による送信器（供給側）を示す。図１４によれば、Ｖ２Ｐシステム１４００は受信器１４１０、送信器１４２０、リソース管理フレームワーク（ＲＭＦ）１４３０、インセンティブマネージャ１４４０および電子番組表（ＥＰＧ）１４５０を有する。受信器１４１０はストリーミングデータを受信するために送信器１４２０と対話する。送信器１４２０はＲＭＦ１４３０と対話し、Ｖ２Ｐシステムにコンテンツを登録および通知する。送信器１４２０はインセンティブマネージャ１４４０と対話し、このインセンティブマネージャ１４４０はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器１４２０は電子番組表（ＥＰＧ）１４５０と対話し、これによりパーソナルビデオレコーダ（ＰＶＲ）拡張を使用したコンテンツの記録が可能になる。

図１４によれば、送信器１４２０はさらに特定の実施形態にしたがい、登録モジュール１４２１０、ストリーミング管理モジュール１４２２０、ＦＥＣエンコーディングモジュール１４２３０、リソース監視モジュール１４２４０およびＰＶＲ拡張モジュール１４２５０を有する。登録モジュール１４２１０はＳＴＢのリソースおよび統計を登録し、またｐ２ｐネットワークにコンテンツを通知する。ストリーミング管理モジュール１４２２０はデータを提供し、また制御信号を受諾するために受信器と通信する。ＦＥＣエンコーディングモジュール１４２３０はコンテンツアイテムに対応するメディアファイルにおけるブロックをＦＥＣエンコーディングする。リソース監視モジュール１４２４０はＳＴＢの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール１４２４０はストリーミングセッションに寄与した後にインセンティブマネージャ１４４０に報告を行う。ＰＶＲ拡張モジュール１４２５０は電子番組表（ＥＰＧ）１４５０と対話する。

登録モジュール１４２１０はＲＭＦ１４３０を介してｐ２ｐネットワークに自身のリソースおよび統計を登録する。またこの登録モジュール１４２１０はｐ２ｐネットワークに新たなメディアコンテンツを登録、通知または宣伝する。

ストリーミング管理モジュール１４２２０はデータを提供し、また制御信号を受諾するために受信器と通信する。送信器が新たなストリーミング要求を受諾した後に、ストリーミング管理モジュール１４２２０は受信器からの制御コネクションを受諾する。制御コネクションにしたがいストリーミング管理モジュール１４２２０は受信器とのデータコネクションを確立し、例えばハードディスクのような局所的な記憶装置からデータを読み出し、またデータコネクションを介してデータを送信する。データが事前エンコーディングされており、且つ目下のエンコーディングされたコンテンツのＦＥＣエンコーディング・オーバヘッド比αが受信器から要求されたαと一致する場合には、ストリーミング管理モジュール１４２２０は単にデータを読み出し、そのデータを受信器に送信する。新たなαを用いてデータをエンコーディングすることが必要である場合には、ストリーミング管理モジュール１４２２０はＦＥＣエンコーディングモジュール１４２３０と通信し、ＦＥＣエンコーディングが実施される。

ＦＥＣエンコーディングモジュール１４２３０はコンテンツアイテムに対応するメディアファイルのブロックをストリーミングのためにＦＥＣエンコーディングする。特定の実施形態によれば、Ｖ２Ｐが特定のＦＥＣエンコーディング・オーバヘッド比αを用いてメディアデータをエンコーディングするために使用することができる２つの例示的なＦＥＣ符号は広く公知のリード・ソロモン（Reed-Solomon）符号およびラプタ符号である。また別の実施形態においては、限定的なフィールドにわたるコーシー行列（Cauchy matrices）を基礎とし、また算術演算の代わりにＸＯＲを使用するリード・ソロモン消去符号（Reed-Solomon erasure code）は、慣例のリード・ソロモン符号を上回る高速なエンコーディングおよびデコーディングを達成するために使用することができる。

表２は、特定の実施形態による、変更されたリード・ソロモン消去符号を使用する例示なエンコーディング時間およびデコーディング時間を示す。例えば、映画ファイルを１．１Ｍｂｐｓで１秒のブロックまたは０．５秒のブロックに分割し、２０％のパケット損失が許容されるようエンコーディングされる。エンコーディング時間およびデコーディング時間には典型的に、２ＧＢメモリを備えた２．４ＧＨｚのＬｉｎｕｘマシンにおいてリード・ソロモン消去符号が実行されている。

表２に示されているように、エンコーディングはデコーディングよりも時間を要する。さらには、エンコーディング時間およびデコーディング時間はブロックの長さに関して線形ではない。ブロックサイズが過度に大きい場合、受信器はブロックをデコーディングする前にブロックの全てのパケットを受信するために長時間待機しなければならない。ブロックサイズが過度に小さい場合、１つのコネクションにおける突発的なパケット損失により大量のパケットが落ち、他のコネクションからの残りのパケットはブロックを回復するのに十分なデータを有さなくなる。１Ｍｂｐｓでのストリーミングに関しては、１秒のブロックサイズが典型的である。４００ＭＨｚ以上で実行するプロセッサおよび１２８ＭＢ以上のメモリを有するＳＴＢは、ネットワークの不安定性およびデバイス故障を調整するためにリード・ソロモン符号を使用するオン・デマンドエンコーディングを支援することができる。

図１４を参照すると、リソース監視モジュール１４２４０は新たなストリーミング要求を受諾または拒否するかを決定するためにＳＴＢの局所的なリソースおよび状態を監視する。また、ＰＶＲ拡張モジュール１４２５０は電子番組表（ＥＰＧ）１４５０と対話し、イベントの記録の管理を調整する。

図１５は、Ｖ２Ｐシステムの性能を評価するための例示的なセットアップを示す。図１５によれば、Ｖ２Ｐシステム１５００は受信器１５１０、送信器１５２０、インターネットサービスプロバイダ（ＩＳＰ）１５８０ａおよび１５８０ｂ（以下ではＩＳＰ１５８０と称する）およびインターネット１５９０を包含する。受信器１５１０および送信器１５２０はそれぞれ受信器モジュールと送信器モジュールの両方を有するようにコンフィギュレーションすることができるので、これらは送信器としても受信器としても動作することができる。ここではパーソナルコンピュータとして示されている各受信器１５１０および送信器１５２０を２つの異なるＩＳＰ１５８０を介してインターネット１５９０に接続することができる。送信器のセットを両方のＩＳＰ１５８０から選択することができるので、ストリーミングデータはインターネット１５９０を介して流れ、また受信器１５１０はネットワークの不安定性を経験する。ストリーミングセッション中に、デバイス故障をシミュレートするために送信器１５２０のうちの１つまたは複数の電源を落とすことができる。

特定の実施形態によれば、Ｖ２Ｐシステムを非対称ディジタル加入者線（ＡＤＳＬ）アクセスネットワークにおいて使用することができ、このネットワークにおいては各送信器が制限的なアップリンク容量を有し、またマルチ送信器ソリューションは送信器のセットからの全体のストリーミングレートを合計するために必要とされる。Ｖ２Ｐをより高い帯域幅のアクセスネットワーク、例えば２０Ｍｂｐｓ〜１００Ｍｂｐｓの範囲のアップリンク帯域幅を有するＦＴＴｘネットワークおよびｘＤＳＬネットワークにおいて使用するために実施することができる。特定の実施形態によれば、その種の環境においてＶ２Ｐは１．５Ｍｂｐｓのストリーミング（ＭＰＥＧ−４品質のビデオストリームに相当）、それどころか３〜５Ｍｂｐｓのストリーミング（ＭＰＥＧ−２品質のビデオストリームに相当）を送信するために複数の送信器を必要としない。１つの送信器が全体のストリーミングレートを容易に提供することができる。それにもかかわらず、特定の実施形態によれば、ネットワークの不安定性およびピアの故障が発生している場合には、復元力のあるストリーミングを提供するために、各ストリーミングセッションに関してバックアップ的なピアを使用することができる。このシナリオにおいては、Ｖ２Ｐの（Ｎ＋Ｍ）個のストリーミングモデルが（１＋Ｍ）になり、ストリーミングセッションは１つの能動的な供給側およびＭ個のバックアップ的な供給側を使用する。各ピアが高い利用可能なアップリンク帯域幅を有するので、ストリーミングセッションはＮ個の能動的な供給側をもはや要求しない。それにもかかわらず、復元力のあるストリーミングを提供するためにＭ個のバックアップが必要とされる可能性はある。各送信器は複数のストリーミングセッションを提供するために十分な容量を有しているので、１つのセッションに割り当てられたバックアップ的な供給側を容易に他のセッションの能動的な供給側にすることができる。

図１６に示されている特定の実施形態によれば、１つ以上のストリームを同時に提供するために送信器は十分なアップリンク帯域幅を有しているので、Ｖ２Ｐは複数のビデオストリームを並行して提供することができる。１つの送信器は複数のストリーミングセッションに複数のビデオを提供することができる。送信器はまた複数のストリーミングセッションにビデオの同一のコピーを提供することができる。このことは希少なビデオが多くの視聴者によって要求される場合には有効である。１つの供給側によって支援することができる並行したビデオストリームの数はＶ２Ｐによっては制限されないが、その代わりにＳＴＢのハードウェアＩ／Ｏ処理能力および利用可能なアップストリーム帯域幅によって制限される。高い帯域幅の環境でのＶ２Ｐの実施は以下のような幾つかの利点を有する：
ａ）１つの能動的な供給側および２つのバックアップがストリーミングセッションに必要とされる；したがってより多くのストリーミングセッションを支援することができる；
ｂ）コミュニティが利用できる特定のビデオのコピーの数は１つの供給側から提供することができる並行したストリームの数だけ増加される。このことは、多数の加入者によって記録されなかったビデオにとって殊に有効である；
ｃ）複数のビデオストリームが提供される場合であっても、同一の復元力能力をＶ２Ｐによって保証することができる。

したがって、Ｖ２Ｐは種々の同種のネットワークおよび異種のネットワークの環境において有用であることが分かった。

図１６は、本発明の１つの実施形態による、高帯域幅の環境において実施されているＶｏＤ・ツー・ピア（Ｖ２Ｐ）システムを示す。図１６によれば、Ｖ２Ｐシステム１６００は受信器１６１０ａ，１６１０ｂおよび１６１０ｃ（以下では受信器１６１０と称する）、送信器１６２０ａ，１６２０ｂおよび１６２０ｃ（以下では送信器１６２０と称する）およびリソース管理フレームワーク（ＲＭＦ）１６３０を有する。ここではＳＴＢとして示されている受信器１６１０は送信器１６２０ａからのストリーミングメディアを受信するピアを受領している。ここではＳＴＢとして示されている送信器１６２０は送信側のピアであるか、ストリーミングメディアの供給側である。受信器１６１０のいずれか１つは時には送信側のピアとしても動作できることを言及しておく。同様に、送信器１６２０のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク（ＲＭＦ）１６３０はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器１６１０と送信器１６２０との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またＲＭＦ１６３０により受信器１６１０は、ブロードキャストから記録した、または送信器から記録した、または送信器１６２０にダウンロードおよび記録されたストリーミング可能なコンテンツ、例えばメディアファイルについてＶ２Ｐシステム１６００を検索することができる。またＲＭＦ１６３０により受信器１６１０はコンテンツ推薦を受信することができる。

高帯域幅ネットワーク環境におけるストリーミングセッションによって要求される完全なストリーミングレートを提供するためには１つの送信器で十分であったとしても、（Ｎ＋Ｍ）個の能動的な供給側およびバックアップ的な供給側を基礎とするストリーミングモデルは、（１＋Ｍ）個の能動的な供給側およびバックアップ的な供給側に比べて全体のシステム利用度を高めることができる。（Ｎ＋Ｍ）個のストリーミングモデルを使用することにより、各供給側は全てのストリーミングレートを提供できる場合であってもその一部を提供する。以下にはシステム利用度の評価を説明する。

例えば：
コミュニティサイズ（ピアの数）＝Ｃ
乗算係数（各ピアが供給できるストリームの数）＝γ
各ストリーミングセッションに関する能動的な送信器の数＝Ｎ
各ストリーミングセッションに関するバックアップの数＝Ｍ
ストリーミングレート＝Ｒ
各ピアのアップリンク容量＝ｃ
と仮定し、考えられる並行したストリーミングセッションの数をＵとすると以下の関係が得られる。

（１＋Ｍ）モデルにおいて：
Ｃ＝１２００，Ｎ＝１，Ｍ＝２，Ｒ＝２Ｍｂｐｓ，γ＝５とすると、
Ｕ＝５（１２００／（１＋２））＝２０００。

（Ｎ＋Ｍ）モデルにおいて：
Ｃ＝１２００，Ｎ＝４，Ｍ＝２，Ｒ＝２，γ＝２０（各ピアがストリームの１／４を供給するので、γ＝４＊５＝２０）とすると、
Ｕ＝２０（１２００／（４＋２））＝４０００。

分析的なモデリングは（Ｎ＋Ｍ）モデルが高帯域幅環境における（１＋Ｍ）モデルよりも良好なリソース利用度を有することを表している。（Ｎ＋Ｍ）または（１＋Ｍ）のような静的なソリューションを使用する代わりに、適合的なメカニズムを使用することができる。例えば、Ｖ２Ｐが特定のリソースの十分なコピー（すなわち特定のビデオ）を有する場合には、良好なシステム利用度に関して（Ｎ＋Ｍ）個ストリーミングモデルを有利に使用することができる。他方では、Ｖ２Ｐシステムが特定のリソースのコピーを僅かしか有していない場合には、（１＋Ｍ）モデルを使用するストリーミングセッションを提供することができる。

システムの最大利用度を以下のように推定することができる。バックアップはネットワークの不安定性が生じている間、またはピア故障中に供給側を移行している間にのみデータの小部分を提供するので、各ピアはバックアップセッションのために自身の容量を確保する代わりに、能動的なセッションのために自身の容量を使用することができる。したがって、最大利用度Ｕは以下の関係によって表される：

上記の例に関して、（１＋Ｍ）モデルまたは（Ｎ＋Ｍ）モデルの両方にとっての最大システム利用度Ｕは６０００である。

Ｖ２Ｐシステムは低帯域幅ネットワーク環境および高帯域幅ネットワーク環境の同種のコミュニティにおいてより一般的に実施することができる。特定の実施形態によれば、送信器が複数のストリーミングセッションに寄与するための十分なリソースを有している場合にのみ、Ｖ２Ｐは所定の送信器を一度以上使用することができる。さもなければ、各送信器はいずれの所定の時点に１つのストリーミングセッションにおいてのみ使用される。図１７は、拡張された送信器アーキテクチャを示し、このアーキテクチャでは特定の実施形態によれば、１つの送信器は複数の受信器にストリームを提供することができる。各ストリームに関して、送信器は１つのストリーム管理スレッドを開く。ストリーム管理モジュールの各インスタンスは受信器との通信に関して責任を有し、また受信器によって送信された制御信号に基づき動作する。ストリーム管理モジュールの各インスタンスはまた受信器へのストリーミングビデオの提供に関して責任を有する。したがって、Ｖ２Ｐは高帯域幅環境において複数のサーバ状ストリーミングセッションを支援することができる。一般化されたＶ２Ｐは、複数のソースを使用するｐ２ｐネットワーク環境の利点も、一人のユーザから複数のストリーミングセッションを供給することによるサーバ状環境の利点も引き継ぐ。

この一般化されたマルチソース環境においては、送信器が自身の利用可能なリソースに基づき、可能な限り多くのストリーミングセッションに寄与することができる。並行するストリームＶ２Ｐの数を以下のような種々の因子に依存して支援することができる：
ａ）要求されたコンテンツアイテムを有するユーザの数
ｂ）各ユーザのアップリンク帯域幅
ｃ）所望のストリーミング品質。
例えば、Ｃ_l低帯域幅ピアおよびＣ_h高帯域幅ピアのコミュニティのためのＶ２Ｐシステムは、γＣ_h／（Ｎ＋Ｍ）＋Ｃ_l／（Ｎ＋Ｍ）までの高品質ストリーミングセッションを支援することができ、ここでγ≧１はどれほど多くのストリームに供給側が寄与することができるかを表す乗算係数である。低帯域幅環境においてはγ＝１ｍであるが、高帯域幅環境においてはγ≒５以上である。

図１７はＶ２Ｐシステムの１つの実施形態のブロック図を示し、またさらに本発明の１つの実施形態による送信器を示す。図１７によれば、Ｖ２Ｐシステム１７００は受信器１７１０、送信器１７２０、リソース管理フレームワーク（ＲＭＦ）１７３０、インセンティブマネージャ１７４０および電子番組表（ＥＰＧ）１７５０を有する。受信器１７１０はストリーミングデータを受信するために送信器１７２０と対話する。送信器１７２０はＲＭＦ１７３０と対話し、Ｖ２Ｐシステムにコンテンツを登録および通知する。送信器１７２０はインセンティブマネージャ１７４０と対話し、このインセンティブマネージャ１７４０はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器１７２０は電子番組表（ＥＰＧ）１７５０と対話し、これによりパーソナルビデオレコーダ（ＰＶＲ）拡張を使用したコンテンツの記録が可能になる。

図１７によれば、送信器１７２０はさらに登録モジュール１７２１０、ストリーミング管理モジュール１７２２０、ＦＥＣエンコーディングモジュール１７２３０、リソース監視モジュール１７２４０およびＰＶＲ拡張モジュール１７２５０を有する。登録モジュール１７２１０はＳＴＢのリソースおよび統計を登録し、またｐ２ｐネットワークにコンテンツを通知する。ストリーミング管理モジュール１７２２０の各々はデータを提供し、また制御信号を受諾するために受信器と通信する。ＦＥＣエンコーディングモジュール１７２３０はコンテンツアイテムに対応するメディアファイルにおけるブロックをエンコーディングする。リソース監視モジュール１７２４０はＳＴＢの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール１７２４０はストリーミングセッションに寄与した後にンティブマネージャ１７４０に報告を行う。また、ＰＶＲ拡張モジュール１７２５０は電子番組表（ＥＰＧ）１７５０と対話し、イベントの記録の管理を調整する。

図１８は、ロングテールを表すグラフを示す。広範な視聴行動を予測するために統計的なサンプリングを使用することができる。例えば、図１８はブロードキャスト番組の人気からどのようにロングテールが観測されるかを示す。

Ｖ２Ｐ配置の範囲をモデリングおよび理解するために考慮する変数が多数存在する。例えば、多くの番組を記録できるような範囲を決定するために所定のコミュニティサイズによってどれほど多くの番組が記録されるか、各送信器によってどれほど多くのストリームを供給することができるか、どれほど多くの並行するストリームを供給することができるか、どれほど多くの累積ストリームをネットワークにおいて供給することができるか、どれほど昔までＶ２Ｐシステムはコンテンツをアーカイブすることができるか、またどれほどの大きいディスクを各ＳＴＢは有しているべきかを評価する必要がある。例えば１つの評価として、加入者が視聴しようとするブロードキャストコンテンツの２５％を記録することが考えられる。例えばＴＶ番組のニールセン視聴率のような他のデータを、特定の番組を試聴する所定のコミュニティサイズにおける人気のパーセンテージを識別するために使用することができる。例えば、上位５００のＴＶ番組のための有効範囲を提供するＶ２Ｐシステムを以下のようにモデリングすることができる：
コミュニティのサイズ＝Ｃ（各ユーザはＰＶＲを有する）；
番組ｉの人気＝ｐ_i；且つ
番組を試聴するユーザが記録する確率＝ｒ_i；
とすると、コミュニティにおいて番組ｉが記録される確率ｘ_i＝ｐ_iｒ_i
また、
コミュニティにおいて番組ｉに関して記録されるコピーの平均数＝Ｃｐ_iｒ_i。

以下のシナリオが考慮される：
１．ＤＳＬネットワークを介する標準画質（Standard Definition：ＳＤ）品質ストリーミング（Ｎ＝３，Ｍ＝２）
２．ＤＳＬネットワークを介する準ＤＶＤ品質ストリーミング（Ｎ＝５，Ｍ＝２）
３．ファイバネットワークを介する準ＤＶＤまたはＤＶＤ品質ストリーミング（Ｎ＝１，Ｍ＝２）。

アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が正規の標準画質（ＳＤ）ＴＶであるＤＳＬネットワークに関して、能動的な送信器のセットは最大で３つ要求され、またバックアップ的な送信器のセットは最大で２つ要求される。

図１９Ａは、３つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、５０，０００世帯のコミュニティにおいては、Ｖ２Ｐは上位にランキングされている番組の３７５の並行するストリームを支援することができる。

図１９Ｂは、所定のコミュニティサイズに関してＶ２Ｐによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、Ｖ２Ｐは５０，０００のコミュニティサイズに関して２４，０００の並行するストリームを供給することができる。

アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が準ＤＶＤであるＤＳＬネットワークに関して、能動的な送信器のセットは最大で５つ要求され、またバックアップ的な送信器のセットは最大で２つ要求される。

図２０Ａは、３つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、５０，０００世帯のコミュニティにおいては、Ｖ２Ｐは上位にランキングされている番組の２００の並行するストリームを支援することができる。

図２０Ｂは、所定のコミュニティサイズに関してＶ２Ｐによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、Ｖ２Ｐは５０，０００のコミュニティサイズに関して１７，０００の並行するストリームを供給することができる。

アップストリーム帯域幅が１００Ｍｂｐｓであり、且つ５つの受信器にストリーミグされるべきビデオの品質が準ＤＶＤであるファイバネットワークに関して、能動的な送信器のセットは最大で１つ要求され、またバックアップ的な送信器のセットは最大で２つ要求される。

図２１Ａは、特定の実施形態による、３つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、２０，０００世帯のコミュニティにおいては、Ｖ２Ｐは上位にランキングされている番組の９２５の並行するストリームを支援することができる。

図２１Ｂは、所定のコミュニティサイズに関してＶ２Ｐによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、Ｖ２Ｐは２０，０００のコミュニティサイズに関して８０，０００の並行するストリームを供給することができる。

図２１Ｂに示されているように、Ｖ２Ｐはコミュニティのサイズを上回る総数の並行するストリームを供給することができ、これにより単一の世帯内の複数のＴＶへのストリーミングを支援することができる。またこのことは同種のネットワークを支援することができる。例えば、コミュニティはＰＶＲ機能を備えたＳＴＢまたはＰＶＲ機能を備えていないＳＴＢを含んでいる可能性がある。ＰＶＲ機能を備えていないＳＴＢはビデオストリームを受信することしかできず、ビデオストリームをネットワークに供給することはできない。また、コミュニティはＦＦＴＸまたはＤＳＬアクセスを備えたＳＴＢを含んでいる可能性がある。

特定の実施形態によれば、Ｖ２Ｐによって提供された保存能力のスケールを検出するために多数のパラメータが要因として考慮されなければならない。特定の実施形態に関するこれらのパラメータのうちの幾つかのパラメータおよび基本的な仮定条件の概略を以下に述べる。ＳＴＢディスクサイズ：
１Ｇｂ＝ＭＰＥＧ２ＳＤビデオで１時間まで
１／２Ｇｂ＝ＭＰＥＧ４準ＤＶＤビデオで１時間まで
１／３Ｇｂ＝ＭＰＥＧ４ＳＤビデオで１時間まで。

１日当たりの使用頻度：
ＰＶＲを有する加入者は１日５時間までＴＶを見ており、そのうちの２５％（１．２５時間まで）が記録される。

したがって、保存期間に関して要求されるＳＴＢディスクサイズが以下の式を用いて近似的に求められる：
ＳＴＢディスクサイズ＝月×３０×１．２５
ＳＴＢディスクサイズ＝月×３７．５。

よって３ヶ月の保存に関して要求されるディスクサイズは以下の通りである：
→ＳＴＢディスクサイズ 〜１２０Ｇｂ（ＭＰＥＧ２ＳＤ）
→ＳＴＢディスクサイズ 〜６０Ｇｂ（ＭＰＥＧ４準ＤＶＤ）
→ＳＴＢディスクサイズ 〜４０Ｇｂ（ＭＰＥＧ４ＳＤ）
図２２は、特定の実施形態による、Ｖ２Ｐシステムの保存の側面を表すグラフを示す。例えば、図２２によれば、Ｖ２ＰシステムはコミュニティサイズＭ（ただしＭ＝２０００）に関して最高でＮのレートの番組の完全な有効範囲を有することができる。

Ｖ２Ｐは複数ソースのビデオストリーミング技術を使用する。特定の実施形態によれば、本質的な前提条件は、ソースをその都度送信することによってストリーミングされるべきビデオファイルがエンコーディングされたフォーマット、ビットレートおよびビデオの開始フレームに関して正確に同一であるということである。

Ｖ２Ｐの１つの考えられる実施形態はＳＴＢ／ＰＶＲデバイスのｐ２ｐネットワークの範囲内である。ＳＴＢ／ＰＶＲデバイスの所有者は、記録しようとする番組の選択に関して種々のメカニズムを有する。例えば、１つのメカニズムは電子番組表（ＥＰＧ）を介するものである。

ＳＴＢのシステムクロックをサービスプロバイダのクロックに周期的に再同期させることができるので、このＳＴＢのクロックは事前に定められた許容範囲、例えば数秒の範囲にとどまる。この同期により、ＳＴＢ／ＰＶＲデバイスはブロードキャスト番組を記録するために適切にスケジューリングされることが保証される。このクロック差の明白な結果は、種々のSTB／ＰＶＲデバイス全てが正確に同時刻にブロードキャスト番組の記録を開始できず、したがって同じ開始フレームから記録を開始できないということである。したがって、Ｖ２Ｐが複数のＳＴＢ／ＰＶＲデバイスから記録された番組をストリーミングすることができるようになる前には、メカニズムはビデオファイル内の共通の開始フレームを識別するために必要とされる。

図２３は、本発明の１つの実施形態による、共通のビデオフレームを識別するための方法を説明するフローチャートである。ストリーミングセッションからのストリーミングビデオデータの受信に先行して、ストリーミングビデオデータを供給することになる供給側のセットを受信器は取得することができる。各供給側は、特定のコンテンツアイテム、例えばブロードキャスト番組に対応するビデオファイルの個々のコピーからストリーミングビデオデータを供給する。

このシーケンスにおいては、ステップ２３１０において受信器が時間窓を規定する。この時間窓は例えばブロードキャスト番組の開始時間を中心にして、事前に定められた同期許容範囲だけ時間的に前後に拡張された期間でよい。サービスプロバイダのネットワークに接続されているクライアントデバイス、例えばＳＴＢに関するクロックを数秒で同期させることができるので、典型的な同期許容範囲は３〜５秒でよい。

ステップ２３２０においては、受信器が各供給側から、関連する所定の時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトのセットを受信する。例えば、ＭＰＥＧコーディングされたビデオファイルのコンテクストにおいては、基準ビデオフレームの各セットは時間窓におけるビデオファイルの個々の各コピー内に現われる全てのＩフレームに対応することができる。各基準オブジェクトは基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を表すことができる。例えば各基準オブジェクトは、基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を使用して、公知のハッシング技術を用いて計算されたハッシュ値でよい。ハッシュ値を、ストリーミングセッションの発生に先行して供給側によって、前もって計算することができる。

ステップ２３３０においては、受信器が全ての供給側から受信した基準オブジェクトのセットを比較し、受信した基準オブジェクトの全てのセットに共通する共通の基準オブジェクトが識別される。ステップ２３４０においては、受信器がステップ２３４０において識別された共通の基準オブジェクトに対応するビデオフレームに開始フレームをセットする。

例えば、受信器はサービスプロバイダのＳＴＢ間でのクロックの同期許容範囲に関連する時間窓を規定する。クロックは典型的には数秒の許容範囲、例えば３〜５秒の範囲と同期される。電子番組表（ＥＰＧ）を用いて、供給側は番組の開始時間を発見し、共通の始点を発見するためにどれほど戻って、またどれほど進んでビデオファイル内を見るかを求めるために同期許容範囲を使用する。時間窓は例えばブロードキャストの開始時間を中心にして、期許容範囲だけ時間的に前後に拡張された期間でよい。供給側は、時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトを生成する。例えば、ＭＰＥＧコーディングされたビデオストリーム（ＭＰＥＧ２およびＭＰＥＧ４を含む）のコンテクストにおいては、各ＧＯＰ（Group of Picture）は他のＧＯＰに依存しない。供給側は、Ｉフレームである各ＧＯＰの開始を識別することができる。時間窓におけるビデオファイルの各供給側のコピー内に現われるＩフレームが比較のために必要とされる。送信器がＩフレームを受信器に送信する場合、この量のデータを短時間で送信することは技術的に不可能である。各供給側はＩフレームのハッシュ値を計算し、このハッシュ値を受信器に送信することができる。全てのＩフレームのハッシュ値を計算する代わりに、各Ｉフレームからの部分的なデータを用いてこのアルゴリズムを継続することができる。さらには、受信器からの要求に基づきハッシュ値を提供できるようにするために、それらのハッシュ値をオフラインで計算することができる。受信器がハッシュ値のセットを受信すると、受信器はそれらのハッシュ値を容易に比較することができ、またこの供給側のセット間でビデオファイルの始点を表す共通のＩフレームを発見することができる。

図２３に示されている方法は、番組の正確な開始フレームの選択を保証するものではない。しかしながら、この方法はＳＴＢの同期許容範囲に相対的な番組の開始に近い開始フレームを選択する。特定の実施形態によれば、このアプローチの利点は分散型のソリューションであるということと、開始フレームを求めるためにビデオシーン分析が要求されないということである。

本明細書においては、ＳＴＢによって形成されるｐ２ｐネットワークのために設計されている、提案されたビデオストリーミングシステムＶ２Ｐの構成要素を種々の実施形態にしたがい説明した。特定の実施形態によれば、インテリジェントなピア選択、動的なバッファ管理、トモグラフィを基礎とするコネクション監視およびフォワード・エラー・コレクションコードなどの技術を使用して、Ｖ２Ｐはアップリンク帯域幅の制約を解消し、ネットワークの不安定性およびデバイス故障に対する復元力を達成することができる。特定の実施形態によれば、Ｖ２Ｐは多対一（many-to-one）のビデオストリーミングにおける一時停止、早送り、巻き戻しのようなインタラクティブな特徴をもたらす技術を提供する。Ｖ２Ｐはビデオストリーミングを光ファイバネットワークにおいて提供するよう拡張される。特定の実施形態によれば、光ファイバネットワークおよびＤＳＬネットワークの両方におけるリソース供給に関する詳細な分析モデルも提供される。特定の実施形態によるアルゴリズムは異なるユーザによって記録された全てのビデオコンテンツを同期するためにも提供され、Ｖ２Ｐは多対一のストリーミングモデルを使用してストリーミングを行うことができる。

要約すれば、種々の実施形態による本発明は、非対称的な帯域幅特性、また場合によっては信頼性が高くないコネクションを有する同種のピア・ツー・ピアネットワークにおいて、能動的な供給側およびバックアップ的な供給側を含む複数のソースを使用する高品質且つ復元力のあるビデオストリーミングを行う。種々の実施形態によれば、本発明は、インテリジェントなピア選択、ネットワークトモグラフィを基礎とするコネクション監視、動的なバッファ管理、動的なレート分布および動的なＦＥＣエンコーディングならびにデコーディングを含む複数のメカニズムを使用して、高品質且つ復元力のあるストリーミングを達成する。また本発明は一時停止、早送りおよび巻き戻しのようなインタラクティブな再生制御を効果的にシミュレートする。

本発明を有利な実施形態に関連させて説明したが、当業者であれば本発明の精神および範囲を逸脱することなく多数の変更および修正を行えることは明らかであり、したがってそのような変更および修正が本発明の範囲に含まれるべきことを意図するために、本発明は上述の方法論および構成の正確な詳細に制限されるものではない。

慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを実施するためのシステムを示す。 ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて、慣例のビデオ・オン・デマンド（ＶｏＤ）サービスを拡大するためのシステムの実施形態を示す。 ロングテールを表すグラフを示す。 ＶｏＤ・ツー・ピア（Ｖ２Ｐ）システムの実施形態を示す。 Ｖ２Ｐシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。 Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。 ピア選択順位方程式のグラフを示す。 ストリーム管理モジュールの詳細を含む、Ｖ２Ｐ受信器を表すブロック図を示す。 動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。 バッファ管理スキーマを表すグラフを示す。 コネクション監視に使用される単純なバイナリツリーを示す。 一連のＭＰＥＧフレームを示す。 早送り動作をシミュレートするためにビデオデータ間に挿入されたビデオクリップを示す。 Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。 Ｖ２Ｐシステムを評価するための例示的なセットアップを示す。 高帯域幅環境において実施されているＶ２Ｐシステムを示す。 Ｖ２Ｐシステムの１つの実施形態を表すブロック図を示す。 ＴＶ視聴行動およびロングテールを表すグラフを示す。 Ｖ２Ｐシステムが標準画質（ＳＤ）品質で供給することができる、並行するストリームの数を表すグラフを示す。 Ｖ２ＰシステムがＳＤ品質で供給することができる、ストリームの最大数または累積数を表すグラフを示す。 Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。 Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。 Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。 Ｖ２Ｐシステムが準ＤＶＤ品質で供給することができる、並行するストリームの数を表すグラフを示す。 Ｖ２Ｐシステムの保存の側面を表すグラフを示す。 共通のビデオフレームを識別するための方法を説明するフローチャートである。

Claims (38)

1. サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムにおいて、
   ダウンロードまたは記録された後にはストリーミングデータとして供給することができる、ダウンロード可能および記録可能なコンテンツを供給するサービスプロバイダを有し、
   前記サービスプロバイダと関連し、且つテレビ受像機との接続に適しているデバイスの加入者コミュニティピア・ツー・ピアネットワークを有し、
   前記サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器を有し、
   能動的な供給側およびバックアップ的な供給側を含む供給側のセットを有し、各供給側は前記サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、また各供給側は前記サービスプロバイダもしくは１つまたは複数の他のノードからコンテンツをダウンロードおよび／または記録した後にオン・デマンドストリーミングデータを供給し、
   前記受信器は、該受信器による要求に応じて前記供給側のセットにおける１つまたは複数の供給側からストリーミングされたストリーミングデータを受信することを特徴とする、システム。
2. 各デバイスはセットトップボックス（ＳＴＢ）またはパーソナルコンピュータ（ＰＣ）である、請求項１記載のシステム。
3. 前記ストリーミングデータはオーディオデータまたはビデオデータまたは、オーディオデータおよびビデオデータの両方である、請求項１記載のシステム。
4. さらに、前記加入者コミュニティピア・ツー・ピアネットワークの検索エンジンを有する、請求項１記載のシステム。
5. 前記検索エンジンはさらにコンテンツブラウザまたはコンテンツ推薦または、コンテンツブラウザおよびコンテンツ推薦の両方を有する、請求項４記載のシステム。
6. さらにインセンティブマネージャを有する、請求項１記載のシステム。
7. さらにディジタル権利マネージャを有する、請求項１記載のシステム。
8. サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供する方法において、
   加入者コミュニティピア・ツー・ピアネットワークをサービスプロバイダの加入者に提供するステップを有し、
   ダウンロードおよび／または記録され、ストリーミングデータとしてオン・デマンドで供給される、ダウンロード可能および記録可能なコンテンツを提供するステップを有し、
   前記加入者コミュニティピア・ツー・ピアネットワークと関連する検索エンジンを提供するステップを有し、
   前記加入者を前記加入者コミュニティピア・ツー・ピアネットワークに接続し、前記加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索し、１つまたは複数の前記他の加入者からストリーミングデータとしてダウンロードおよび／または記録された前記コンテンツをオン・デマンドで受信するために、各加入者に前記検索エンジンの使用を許可するステップを有することを特徴とする、方法。
9. 前記加入者のうちの１つまたは複数はセットトップボックス（ＳＴＢ）またはパーソナルコンピュータ（ＰＣ）である、請求項８記載の方法。
10. 前記ストリーミングデータはオーディオデータまたはビデオデータまたは、オーディオデータおよびビデオデータの両方である、請求項８記載の方法。
11. 前記検索エンジンはコンテンツブラウザまたはコンテンツ推薦または、コンテンツブラウザおよびコンテンツ推薦の両方を有する、請求項８記載の方法。
12. インセンティブマネージャを提供するステップをさらに有する、請求項８記載の方法。
13. ディジタル権利マネージャを提供するステップをさらに有する、請求項８記載の方法。
14. 加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信するシステムにおいて、
    加入者コミュニティピア・ツー・ピアネットワークを有し、
    前記加入者コミュニティピア・ツー・ピアネットワークにおけるノードである、ストリーミングデータの受信器を有し、
    能動的な供給側のセットおよびバックアップ的な供給側のセットを含む、ストリーミングデータの供給側のセットを有し、該供給側のセットにおける各供給側は前記加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、
    前記ストリーミングデータは複数のブロックを含み、且つオン・デマンドで受信されるべきストリーミングデータの各ブロックに関して前記受信器は、
    ＦＥＣエンコーディング・オーバヘッド比を使用し、
    前記ＦＥＣエンコーディング・オーバヘッド比を用いてＦＥＣエンコーディングされたブロックの個別に割り当てられた少なくとも１つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグし、
    前記ＦＥＣエンコーディングされたブロックのセグメントを受信し、ここで各セグメントは個別に割り当てられた前記小部分の少なくとも一部を表し、
    前記ＦＥＣエンコーディングされたブロックを前記セグメントの集合体に基づきデコーディングし、該デコーディングされたブロックをバッファに記憶し、
    各能動的な供給側とのネットワークコネクションの性能を監視し、
    結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するために前記バッファを監視し、
    前記ネットワークコネクションの性能および前記バッファの状態に基づいて、前記バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施することを特徴とする、システム。
15. 加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信する方法において、
    加入者コミュニティピア・ツー・ピアネットワークにおける候補供給側のセットから能動的な供給側のセットとなる供給側のセットを選択し、前記候補供給側のセットからバックアップ的な供給側のセットとなる別の供給側のセットを選択するステップを有し、
    受信されるべきストリーミングデータの各ブロックに関して、
    ＦＥＣエンコーディング・オーバヘッド比を使用するステップを有し、
    前記ＦＥＣエンコーディング・オーバヘッド比を用いてＦＥＣエンコーディングされたブロックの個別に割り当てられた少なくとも１つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグするステップを有し、
    前記ＦＥＣエンコーディングされたブロックのセグメントを受信するステップを有し、ここで各セグメントは個別に割り当てられた前記小部分の少なくとも一部を表し、
    前記ＦＥＣエンコーディングされたブロックを前記セグメントの集合体に基づきデコーディングし、該デコーディングされたブロックをバッファに記憶するステップを有し、
    各能動的な供給側とのネットワークコネクションの性能を監視するステップを有し、
    結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するために前記バッファを監視するステップを有し、
    前記ネットワークコネクションの性能および前記バッファの状態に基づいて、前記バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施するステップを有することを特徴とする、方法。
16. 前記ストリーミングデータはオーディオデータまたはビデオデータまたは、オーディオデータおよびビデオデータの両方である、請求項１５記載の方法。
17. 前記加入者コミュニティピア・ツー・ピアネットワークは、それぞれが供給側または受信器もしくは供給側および受信器の両方として動作する、セットトップボックス（STB）、パーソナルコンピュータ（ＰＣ）またはモバイル装置のいずれかの組合せを有する、請求項１５記載の方法。
18. 供給側のセットの選択は、供給側の供給状態または受信状態、利用可能なアップリンク帯域幅、処理能力、信頼性記録、パス待ち時間、パケット損失および公平性を含む１つまたは複数のメトリクスのいずれかの組み合わせを基礎とする、請求項１５記載の方法。
19. 信頼性記録はデバイス故障率、ネットワーク接続時間および供給側のコンテンツアベイラビリティのいずれかの組合せを基礎とする、請求項１８記載の方法。
20. 公平性はロードバランシングおよび供給側の先行の選択記録のいずれかの組合せを基礎とする、請求項１８記載の方法。
21. 各能動的な供給側との前記ネットワークコネクションの性能の監視は受動的であり、且つ前記供給側から実際に受信したストリーミングデータのメトリクスを基礎とする、請求項１５記載の方法。
22. 各能動的な供給側との前記ネットワークコネクションの性能の監視は、前記能動的な供給側はネットワークの不安定性を経験しているか否か、故障しているか否か、またはストリーミングデータとして供給されるべきコンテンツを削除しているか否かの検出を含む、請求項１５記載の方法。
23. 前記バッファの監視は目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートの監視を含む、請求項１５記載の方法。
24. 品質適合の実施は、
    レート分布の調整、
    供給側のセットの調整、
    ＦＥＣエンコーディングパラメータの調整
    のうちの１つまたは複数を含む、請求項１５記載の方法。
25. 前記レート分布の調整は、
    新たに割り当てられたデータレートの能動的な供給側への割り当て、
    新たに割り当てられた小部分の能動的な供給側への割り当て
    のうちの１つまたは複数を含む、請求項２４記載の方法。
26. 前記供給側のセットの調整は、
    前記能動的な供給側のセットからの能動的な供給側の除去、
    前記能動的な供給側のセットへのバックアップ的な供給側の付加、
    前記バックアップ的な供給側のセットへの候補供給側の付加、
    のうちの１つまたは複数を含む、請求項２４記載の方法。
27. エンコーディングパラメータの調整は、
    新たなＦＥＣエンコーディング・オーバヘッド比の使用、
    新たなＦＥＣエンコーディングスキーマの使用
    のうちの１つまたは複数を含む、請求項２４記載の方法。
28. 供給側の候補セットを前記加入者コミュニティピア・ツー・ピアネットワークの検索エンジンから取得するステップをさらに有する、請求項１５記載の方法。
29. ストリーミングデータの前記能動的な供給側のセット間でストリーミングデータのソースとして使用されるべきメディアファイルの１つまたは複数の個々のコピーにおける共通の始点を求めるステップをさらに有する、請求項１５記載の方法。
30. 前記動的な供給側のセット間でメディアファイルにおける共通の始点を求めるステップは、
    期間を規定するステップを有し、
    各能動的な供給側のセットから基準オブジェクトのセットを受信するステップを有し、ここで各基準オブジェクトは前記期間においてメディアファイル内に現われる基準フレームに対応し、
    基準オブジェクトの全てのセットに共通する共通の基準オブジェクトを識別するために、受信した基準オブジェクトのセットを比較するステップを有し、
    前記共通の基準オブジェクトに対応する基準フレームとなる共通の始点をセットするステップを有する、請求項２９記載の方法。
31. 前記メディアファイルはビデオファイルであり、各基準フレームはビデオフレームであり、各基準オブジェクトはハッシュ値である、請求項３０記載の方法。
32. 前記期間は前記加入者コミュニティピア・ツー・ピアネットワークと接続されているデバイスのクロック同期に関連する、請求項３０記載の方法。
33. 加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムにおいて、
    加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器を有し、
    ストリーミングデータを持つ供給側のセットを有し、該供給側のセットにおける各供給側は前記加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、
    前記ストリーミングデータは複数のブロックを含み、且つ供給されるべきストリーミングデータの各ブロックに関して各供給側は、
    使用されるべきＦＥＣエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、およびＦＥＣエンコーディング・オーバヘッド比を使用したブロックのＦＥＣエンコーディングにより生じるＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分を受信し、
    前記ＦＥＣエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信することを特徴とする、システム。
34. 加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法において、
    加入者コミュニティピア・ツー・ピアネットワークにおいて受信器によって受信されるべきストリーミングデータの各ブロックに関して、
    使用されるべきＦＥＣエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、およびＦＥＣエンコーディング・オーバヘッド比を使用したブロックのＦＥＣエンコーディングにより生じるＦＥＣエンコーディングされたブロックの個別に割り当てられた小部分を受信するステップを有し、
    前記ＦＥＣエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで前記受信器に送信するステップを有することを特徴とする、方法。
35. ＦＥＣエンコーディング・オーバヘッド比の使用は、前記ブロックの後続のＦＥＣエンコーディングに関するＦＥＣエンコーディング・オーバヘッド比のセット、または事前エンコーディングされたブロックを選択するためのＦＥＣエンコーディング・オーバヘッド比の使用を含む、請求項３４記載の方法。
36. ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
    ストリーミングビデオデータをストリーミングレートで受信するステップを有し、
    受信した前記ストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップを有し、
    記憶されている前記ストリーミングビデオデータを前記通常速度よりも速い速度で前記バッファから再生するステップを有し、
    前記ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップを有し、
    アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップを有することを特徴とする、方法。
37. ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
    ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップを有し、
    通常の視聴速度に対応する通常の再生レートで後に再生するために、受信したストリーミングビデオデータをバッファに記憶するステップを有し、
    スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップを有し、
    前記ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信し、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータを前記バッファから通常の再生速度よりも速い再生レートで再生するステップを有することを特徴とする、方法。
38. 事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップをさらに有する、請求項３７記載の方法。

Images