JP2022524639A - ピア・トゥ・ピアネットワークにおけるストリーミングコンテンツの配信方法 - Google Patents

Abstract

本発明は、クライアントデバイス（１１、１２）のピア・トゥ・ピアネットワーク（１０）内で配信されるコンテンツを、クライアントデバイス（１１）の読み取り装置で連続して読み取る方法に関し、上記コンテンツは、複数の品質レベルで利用可能なセグメントシーケンスから構成され、上記読み取り装置は、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され；クライアントデバイス（１１）は、ピア・トゥ・ピアネットワーク（１０）内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリ（Ｍ１）を含み、当該方法は、クライアントデバイス（１１）のデータ処理手段（１１０）による以下の工程：（ａ）読み取り装置からの１つのセグメントのリクエストの受信工程；（ｂ）読み取り装置の上記ＡＢＲ論理に対して決められた応答期限の満了時に第１のバッファメモリ（Ｍ１）から上記セグメントの応答を供給する工程の実施を含むことを特徴とする。

Description

本発明は、ピア・トゥ・ピアネットワークにおけるストリーミングコンテンツの配信方法に関する。

「ストリーミング」（仏語では「ｌｅｃｔｕｒｅ ｅｎ ｃｏｎｔｉｎｕ（連続再生））は、「生配信」すなわち、クライアントデバイスによるインターネットからの回収につれて行われる音声フローまたは映像フローの再生技術をさす。そのため、これは、読み取りを可能にする前に音声または映像コンテンツのデータ全体を回収することが必要なダウンロードとは対照的である。

ストリーミングの場合、コンテンツの保存は一時的かつ部分的であり、データは、クライアントのバッファメモリ（一般にはＲＡＭ）に連続してダウンロードされ、ただちにデコードされ、出力インターフェース（モニタおよび／またはスピーカ）に送信されたのち、新しいデータに切り替えられる。

一般に、コンテンツは、ストリーミングサーバで利用提供される。サーバへのアクセスを望むクライアントは、第１のセグメントをそこから回収するためにリクエストを送信する（セグメントとは、一般には数秒の再生に対応するコンテンツのデータブロックを意味する）。コンテンツのビットレートを読み取り可能にするためにバッファメモリ（ｂｕｆｆｅｒ）内に十分にデータがある場合、再生が開始される。背景では、コンテンツの続きをバッファメモリに絶えず供給するためにフローがダウンロードされ続ける。

しかし、このアプローチは、多数のクライアントが同じコンテンツを同時に読み取ろうとする場合は限界がある：サーバが飽和し、再生をスムーズにするのに十分なビットレートでコンテンツを供給できなくなり、様々な乱れが発生する。

最近では、それに代わって「ピア・トゥ・ピアネットワーク」（Ｐ２Ｐ、仏語ではｐａｉｒ－ａ－ｐａｉｒ）に基づく設計が提案されており、この設計では、各クライアントが他のクライアントに対して１つのサーバすなわちピアとして作用する。コンテンツの再生を開始した１つのピアは、すでに受信したセグメントを他のピアに再送することができ、以下同様に行われるので、関与するクライアント数に関係なく配信が容易になる。この設計は、たとえば国際公開第２０１２／１５４２８７号パンフレットに記載されており、満足のいくものである。

しかし、大部分の再生装置は、いわゆるアダプティブ・ビットレート（英語の「Ａｄａｐｔｉｖｅ ＢｉｔＲａｔｅ」、ＡＢＲ）論理を使用しており、Ｐ２Ｐと組み合わせると様々な問題を提起することが分かっている。

ＡＢＲの一般的な考え方は、１つのピアの「キャパシティ」に応じて、回収されたセグメントの品質を自動的に変えられるようにするというものである。より詳しくは、各セグメントは、複数のビットレートすなわちデータビットレートに対応する複数の品質レベルで利用可能である。実際、よりよい品質のセグメントは、より高い解像度を有し、圧縮が少なく、毎秒当たりの画像数が一段と多いことなどが分かっており、したがって品質が低い同じセグメントよりも容量が多いので、より高いデータビットレートを持続させることが必要である。

一般に、確認された通過帯域、および／またはバッファメモリの充填率という２つの基準からみて、ＡＢＲは、選択可能な最高品質を各セグメントに対して自動的に決定することをめざしている。

前者の場合、推定された通過帯域がよりよい品質をサポートするのに十分であるとアルゴリズムにより判断された場合、当該アルゴリズムは、上記通過帯域に接続するようにクライアントに命令を与える（あるいは、その反対に通過帯域が低すぎる場合は品質を下げる命令を与える）。後者の場合、原理は、バッファメモリを様々なインターバルに分割することにあり、各インターバルは、バッファメモリの充填が増えるにつれてますます高い（あるいは充填が減ればますます低い）品質に対応する。

いずれの場合も、ＡＢＲアルゴリズムがＰ２Ｐストリーミングのコンテキストでの使用に本質的な不適合性を持つというわけではないが、問題は、ＡＢＲアルゴリズムが単純なストリーミングシナリオで動作するように設計されており、すなわち、コンテンツサーバからのリクエストで全てのセグメントが回収されることにある。

ところで、実務上、Ｐ２Ｐストリーミングは、再生装置が実際にリクエストを行う前に、専用のＰ２ＰキャッシュにＰ２Ｐでセグメントをダウンロードすることによって「プレバッファリング」を実施する。なぜなら、Ｐ２Ｐストリーミングの目的は、オリジンコンテンツサーバのポーリングをできるだけ少なくする（それも最後の手段として行う）ことにあるからである。すなわち、このサーバに対するセグメントの直接リクエストは、映像バッファ内にもはやセグメントがなく再生が遮断される（「ｒｅ－ｂｕｆｆｅｒｉｎｇ（リバッファリング）」）リスクがある場合しか実施されず、そうでない場合は、Ｐ２Ｐネットワークが最大限に拠り所にされる。

そのため、再生装置が非常に高い明白な通過帯域を有するという見方がなされる。なぜなら、セグメントは、それらが要求された後、Ｐ２Ｐキャッシュからバッファメモリ内に数分の１秒でチャージ可能であるからである。さらに、映像バッファの充填率は人為的に高くされる。

これによって、ネットワークの実際のキャパシティとは無関係に、現行の品質が最大品質ではない場合、品質を高めるというＡＢＲの制御不能な決定がなされるが、ネットワークは必ずしもこの品質をサポートすることができない。

したがって、よくてもフロー品質の不安定な揺れがみられ、最悪の場合には再生が繰り返し遮断されて、コンテンツサーバの無駄なポーリングが多くなる。

ＡＢＲ論理を制御できるようにすることが望ましいが、残念ながら、この論理はしばしば再生装置に固有のものであってアクセスしづらく、ましてや修正がしにくい。そのため、Ｐ２Ｐストリーミングコンテンツでは、あらゆるＡＢＲアルゴリズムを制御するように構成することが望ましい。

本発明は、この状況を改善するものである。

したがって、本発明は、クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツを、クライアントデバイスの再生装置で連続して再生する方法に関し、上記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、上記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され；クライアントデバイスが、ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリを含んでおり、当該方法は、クライアントデバイスのデータ処理手段による以下の工程：
（ａ）再生装置からの１つのセグメントのリクエストの受信工程
（ｂ）再生装置の前記ＡＢＲ論理に対して決められた応答期限の満了時に第１のバッファメモリから上記セグメントを応答として供給する工程
の実施を含むことを特徴とする。

この方法は、応答への人為的な期限の付加を介したＡＢＲアルゴリズムへの情報回帰を巧みに提案している。

限定的ではない有利な数々の特徴によれば：
・上記ＡＢＲ論理は、セグメント受信ビットレートを示す少なくとも１つのパラメータに応じて、上記セグメントリクエストの品質レベルを計算可能な第１の関数により決定される。
・第２の関数が、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータに応じて工程（ａ）で上記応答期限を計算可能である。
・第２の関数が、第１の関数に基づいて構成される。
・第２の関数が、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータに対して単調である。
・クライアントデバイスが、再生装置による再生に適したフォーマットでセグメントを保存するように構成された第２のバッファメモリをさらに含み、上記セグメントが、工程（ｂ）で第２のバッファメモリに供給される。
・セグメント受信ビットレートを示す上記パラメータが、第２のバッファメモリの充填レベルおよび／または通過帯域である。
・工程（ａ）は、計算された応答期限に応じて次のセグメントリクエストの品質レベルの予測を含む。
・この方法は、次のセグメントリクエストの品質レベルの上記予測の検証工程（ｃ）を含む。
・この方法は、予測された品質レベルと実際にリクエストされた品質レベルとに基づく第２の関数の学習を含む。
・リクエストされたセグメントが、第１のバッファメモリでは不完全に利用可能であり、工程（ａ）が、セグメントを回収し終わるのに必要な推定時間に応じて計算された応答期限の修正を含み、工程（ｂ）では、このセグメントが、修正された応答期限の満了時にできるだけ早く完全に供給される。

第２の側面によれば、本発明は、クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツを再生装置で連続して再生するデバイスを提案し、上記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、上記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され；クライアントデバイスが、ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリと、データ処理手段とを含み、当該デバイスは、データ処理手段が、再生装置からセグメントのリクエストを受信すると、上記再生装置のＡＢＲ論理に対して決められた応答期限の満了時に第１のバッファメモリから上記セグメントを応答として供給するように構成されていることを特徴とする。

第３および第４の側面によれば、本発明は、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、第１の側面による方法を実行するためのコード命令を含む、コンピュータプログラム製品と、情報処理装置による読み取りが可能な保存手段とを提案し、当該情報処理装置では、コンピュータプログラム製品が、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、第１の側面による方法を実行するためのコード命令を含む。

本発明の他の特徴および長所は、好ましい実施形態の以下の説明を読めば明らかになるであろう。この説明では、以下の添付図面を参照する。

本発明による方法の実施のためのアーキテクチャを示す図である。 本発明による方法の好ましい１つの実施形態を示す図である。

アーキテクチャ
図１を参照すると、本発明は、図示されたようなネットワーク１内で配信されるコンテンツの連続再生方法を提案する。ネットワーク１は、ここでは、大規模通信ネットワークであり、特にインターネットである。このネットワーク１は、クライアントデバイス１１、１２のピア・トゥ・ピアネットワーク１０を含む。各クライアントデバイス１１、１２は、一般に、ネットワーク１に接続されたスマートホン、ＰＣ、タブレット等のパーソナル情報機器であり、プロセッサ等のデータ処理手段１１０と、コンテンツ再生用のインターフェースと、ＲＡＭおよび／またはマスメモリ等のデータ保存手段とを有する。

再生は、再生装置すなわち、データ処理手段１１０により実行されるアプリケーションであり、これは多様な性質を持つことが可能であって、たとえば専用アプリケーション、特にＨＴＭＬ５に対応するインターネットブラウザ、オペレーティングシステムのモジュール等とすることができる。

以下の説明では、再生装置が「現状のまま」にあり、すなわち、本発明による方法の実施に対してもＰ２Ｐストリーミングに対しても修正されていないと仮定する。特に、再生装置は、アダプティブ・ビットレートＡＢＲ（Ａｄａｐｔａｔｉｖｅ Ｂｉｔｒａｔｅ）の制御論理を実施し、すなわち、上記読み込まれるコンテンツが、複数の品質で利用可能なセグメントシーケンスから構成されており、再生装置は、このＡＢＲ論理に従ってどの品質をリクエストするかを自動的に決定することができる。多様な品質が、種々の異なるビットレートすなわち、可変単位時間（したがってセグメント）毎のデータ容量に対応する。当然のことながら、よりよい品質のコンテンツはより大きなビットレートを必要とすることが分かる。

ＡＢＲ論理の概念については後で詳しく述べるが、本発明による方法の範囲ではＡＢＲ論理を制御可能にする必要はなく、またこの論理を認識している必要もないことを単に理解されたい。すなわち、本発明による方法は完全に普遍的であり、どんな基準のベースでどんなＡＢＲ論理を実施するどんな再生装置にも適合することができる。ＡＢＲ論理はあらかじめ決定されており、クライアントソフトウェア（後述する）はこの論理の支配だけを受けると仮定する。

さらに、クライアントデバイス１１（より詳しくはそのデータ保存手段）は、一般にはＲＡＭの２つの領域である２個のバッファメモリＭ１、Ｍ２（「バッファ」とも呼ばれる）を有し、各々が、（後述するように異なるやり方で）一時的にコンテンツの全部または一部を保存することができる（一時的とは、セグメントが読み取られた直後にこのメモリから削除されることを意味する：直接ダウンロードした場合のように長期的に保存されることはない。たとえばブラウザを介した再生の場合、全てのセグメントは、遅くとも、映像が流されるブラウザまたはタブが閉じられたときに通常は削除される（すなわちバッファメモリが再び初期化される）。

第１のバッファメモリＭ１は、「ピア・トゥ・ピアキャッシュ」と呼ばれる。このメモリは、いわゆる「未処理の」フォーマットでセグメントを保存する。未処理のセグメントとは、ピア・トゥ・ピアネットワーク１０内での伝送に適しているがクライアントデバイス１１での再生には適さないフォーマットにあることを意味する。

第２のバッファメモリＭ２は、「映像バッファ」と呼ばれる。このメモリは、再生装置により制御され、いわゆる「変換された」フォーマットでセグメントを保存する。変換されたセグメントとは、クライアントデバイス１１での再生（特に再生装置）に適しているがピア・トゥ・ピアネットワーク１０内での伝送には適していないフォーマットに未処理のセグメントから変換されたことを意味し、これについては後述する。

最初に説明したように、クライアントデバイス１１、１２は、ピア・トゥ・ピアネットワーク１０の「ピア」（「ノード」とも呼ばれる）である。

「ピア・トゥ・ピアネットワーク１０のクライアントデバイス１１、１２」とは、ピア・トゥ・ピアネットワークプロトコルによりネットワーク１内で接続される数々のデバイスを意味する。換言すれば、各ピアのデータ処理手段が個々のプログラム（クライアントソフトウェア「ピアエージェント」と呼ばれる）を実施し、これは、ピア・トゥ・ピアの使用のために、たとえば再生装置（たとえばウェブブラウザの拡張機能）に組み込まれ、また専用アプリケーションの対象になり、さらには搭載された他の全てのソフトウェア（たとえばインターネットアクセス装置のプレーヤまたはマルチメディア装置すなわち「セットアップボックス」）に組み込み可能である。本発明による方法は、このクライアントソフトウェアを介して主にインプリメントされる。本発明の以下の説明では、クライアントソフトウェアが再生装置と通信してセグメントを補給するが、再生装置は独立して動作すると仮定する。より詳しくは、再生装置の役割は再生自体、すなわちセグメントの返却であり、それに対してクライアントソフトウェアの役割は単に、再生装置のためのセグメントの取得であり、クライアントソフトウェアは、再生装置の動作、特にそのＡＢＲ論理の支配を受ける。

前述のように、ピア・トゥ・ピアネットワークまたは「ピア・トゥ・ピア」あるいはＰ２Ｐは、ネットワーク１内で分散された下位ネットワークであり、中央サーバを経由せずにネットワーク１０の２個のクライアントデバイス１１、１２の間で直接データを伝送することができる。そのため、全てのクライアントデバイス１１、１２がクライアントの役割とサーバの役割を同時に果たすことができる。したがって、ピア１１、１２は「シーダー」（仏語では「ｓｅｍｅｕｒｓ」、すなわちデータ配布者）および／または「リーチャー（仏語では「ｓａｎｇｓｕｅｓ」すなわちデータ受信者）」として定義される。

上記コンテンツは、特に音声または映像コンテンツであり、すなわち一定の持続時間を持つメディアであって、ピア・トゥ・ピアネットワーク１０に接続されたサーバ２のデータ保存手段に保存されたセグメントシーケンス（いわゆる「再生リスト」、英語の「ｐｌａｙｌｉｓｔ」）から構成され、前述のように複数の品質レベルで入手することができる。セグメントの長さはあらかじめ決まっていて、一般にはコンテンツの１～２秒であるが、この長さは数分の１秒から約１０秒に及ぶことがある。１つの所定のコンテンツの全てのセグメントの長さは一般に同じであり、ここではｐと記す。

サーバ２は、ネットワーク１に有利には存在するコンテンツサーバ（いわゆるＣＤＮ）であり、ピア・トゥ・ピアネットワーク１０に接続される。換言すれば、所定のストリーミングプロトコルに従って多様なコンテンツのセグメントを利用提供するインターネットネットワーク１の１つ（または複数の）サーバに関する。たとえば、セグメントが、プレイリストファイル「ｍ３ｕ８」にリストされた「ｔｓ」ファイルである、ＨＬＳ（「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」）の例が挙げられる。ＨＬＳは、コンテンツのためにＭＰＥＧ２フォーマットを含む。同様に、ＤＡＳＨストリーミング、Ｓｍｏｏｔｈ ｓｔｒｅａｍｉｎｇまたはＨＤＳの各プロトコルが挙げられる。ＷｅｂＲＴＣタイプのプロトコルを介してピア間で未処理のセグメントをやり取り可能である。

サーバ２は、最初にどのピアもコンテンツを持たない限りにおいて（サーバ２からこのピア１１、１２への最初の伝送前）、セグメントの最初のソースである。コンテンツはその全体がもともとサーバ２に保存されており（前述のＶＯＤの場合）、あるいは、リアルタイムで生成され（ライブストリーミングまたは生配信ストリーミングの場合）、後者の場合は、これを構成するセグメントリストがダイナミックに変化する。

「ライブストリーミング」（すなわち「生配信ストリーミング」）は、たとえばコンサート、会議、スポーツの試合、ビデオゲームの勝負等の、同時に展開されている最中の「ライブ」イベントに結合されるコンテンツをリアルタイムで配信することを提案する。映画等の、すでに全体が存在しているコンテンツのストリーミングに比べて、ライブストリーミングで配信されるコンテンツは、実際には、結合されるイベントの展開につれて生成される。技術的には、テレビの生中継の場合と同様に、このようなコンテンツは、わずかな遅延だけで配信可能であり、ユーザはこうした遅延をできるだけ少なくすることを望んでいる。この遅延は通常は約１分であるが、約２０秒まで減らすことができる。これによって、各瞬間には、ほんの一握りのセグメント（せいぜい数１０個）だけの再生が利用可能になり、このリストのセグメントは、１つの循環すなわち、イベントが展開されて新しいセグメントが形成され、「老朽化し」、（所定の遅延の後に）クライアントにより受信されて読み取られ、最後にリストから出る、という循環に従ってダイナミックに更新される。

いま述べた事例（ライブストリーミング）では、コンテンツはむしろ連続フローとみなされるべきである。そのため、セグメントシーケンスはダイナミックであり、すなわち定期的に更新される。新しいセグメントが生成されるたびに、それがシーケンスの末尾に付加され、このシーケンスの最初のセグメント（最も古いセグメント）が削除される。他の全ては、循環メカニズムに従ってオフセットされ、これをＦＩＦＯリストに結びつけることができる。リストの第１のセグメント（最も古いセグメント）は、再生地点にあるセグメント、換言すれば「生配信」（したがってセグメントは読み取られるとすぐに再生リストから削除される）セグメントとすることができ、あるいは、遅延を伴うコンテンツの読み取りをコンテンツサーバが受け入れる場合は「過去の」セグメント（幾つかのプラットフォームが遅延２時間までのライブストリーミングを提案している）とすることができ、これをＤＶＲ（「デジタルビデオレコーダ」）と呼んでいる。

本発明による方法は、どのような状況でも実施可能である。

有利には、「トラッカー」と呼ばれるピア管理サーバ３がピア・トゥ・ピアネットワーク１０に同様に接続される。トラッカー３は、データ処理手段と保存手段とを有する。トラッカーは、（クライアントデバイス１１、１２の各々により用いられるクライアントソフトウェアを制御することによって）ピア１１、１２の間のやり取りを連携させるが、その一方で、データ伝送には直接含まれず、ファイルのコピーを持たない。

ＡＢＲ
前述のように、通過帯域（すなわち確認されたデータビットレート）と、第２のバッファメモリＭ２の充填レベル（または値、すなわち秒またはセグメント数あるいは比率）（場合によってはそれらの組み合わせ）とにそれぞれ基づいた、主に２種類のＡＢＲ論理がある。換言すれば、再生装置は、通過帯域および／または第２のバッファメモリＭ２のボリュームおよび／または充填率をモニタリングし、その結果、要求されているセグメントの品質レベルを修正するか否かの決定を下す。

一般に、いずれの場合も、セグメント受信ビットレートを示す少なくとも１つのパラメータに応じて選択すべき品質レベル（ビットレート）を計算可能な、第１の関数を用いてＡＢＲ論理を決定することができる。たとえば図２に示したグラフを参照されたい（左側部分が再生装置側を示し、右側部分がクライアントソフトウェア側を示す）。

セグメント受信ビットレートを示す上記パラメータは監視されるパラメータであると理解され、これは、「十分に早く」セグメントを受信すべきデバイス１１および／またはネットワーク１０の容量を示すどのようなパラメータであってもよい。先に説明したように、公知のＡＢＲ論理は、一般に、第２のバッファメモリＭ２の充填レベルおよび／または通過帯域をパラメータとして使用する。

ＡＢＲ論理タイプがどのようなものであろうと、上記の第１の関数は、最低品質の値と最大品質の値との間で単調関数であり、特に増加関数である。好ましい１つのモデルは、（２つの特異点で接続された）３つの断片による断片連続関数のモデルであり、第１と第３の断片が一定である。

そのため、図２の例では（左側部分）、第２のバッファメモリＭ２の充填レベル（秒で示す）に基づくＡＢＲ論理の例が示されており、次のようになっている：
－最小閾値Ｂ_ｍｉｎ以下の充填レベルでは、ビットレートが最低ビットレートＲ_ｍｉｎに等しい値に固定され（換言すれば、バッファは危険なまでに空であり、セグメントを得るのが難しいことを示しており、その場合、品質は最低であり、再充填が促される）；
－最大閾値Ｂ_ｍａｘ以上の充填レベルでは、ビットレートが最大ビットレートＲ_ｍａｘに等しい値に固定される（バッファは満杯であり、したがって、あえて最大品質にするリスクをとることはない）；
－２つの値の間にある場合、好ましくは直線の増加曲線が得られ（図２の例では、等式Ｒ＝Ｒ_ｍｉｎ＋（Ｂ－Ｂ_ｍｉｎ）^＊（Ｒ_ｍａｘ－Ｒ_ｍｉｎ）／（Ｂ_ｍａｘ－Ｂ_ｍｉｎ）である）、これは、バッファが満杯であればあるほど品質を高くできることを示す。

通過帯域に基づくＡＢＲ論理についても同様の曲線が得られる。

後述するように、本発明による方法は、ＡＢＲを、その論理を改ざんすることによってではなく、セグメントのリクエストに応じる前に付加される応答期限を用いてこの論理を調整することによって制御することを提案する。なぜなら、１つのセグメントの供給を単に遅延させることによって通過帯域と第２のバッファメモリＭ２の充填レベルとを人為的に制限し、それによって、セグメントに期待される品質に働きかけることができるからである。

そのため、図示された例では、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータ（したがって、ここでも同様に第２のバッファメモリＭ２の充填レベルである）に応じて上記応答期限を可能にする第２の関数を決定している。

第２の関数は、好ましくは、第１の関数に基づいて構成され（さらには学習される。これについては後述する）、すなわち、第２の関数によってＡＢＲ論理をマッピングすることができる。

したがって、１つの好ましい実施形態によれば、第２の関数は、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータに対して単調であり、一般には（特に、後述するような第２のバッファメモリＭ２の充填レベルに基づくＡＢＲ論理の場合には）、第１および第２の関数が、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータに対して同じ単調性（特に増加）を有する。実際、大抵の場合は、第２の関数がＡＢＲ論理の第１の関数に類似していることが分かっている（ここでも同様に２つの極値セグメントを含む３個の断片による断片連続関数）。同様に、たとえば図２の右側部分に示した対応する曲線を参照されたい。

マッピングは、たとえば、第１の関数の２つの点、特に、座標断片を接続する特異点｛Ｂ_ｍｉｎ，Ｒ_ｍｉｎ＝ｆ_１（Ｂ_ｍｉｎ）｝および｛Ｂ_ｍａｘ，Ｒ_ｍａｘ＝ｆ_１（Ｂ_ｍａｘ）｝を選択することからなり、２個の対応する点｛Ｂ_ｍｉｎ，ｐ_ｍｉｎ＝ｆ_２（Ｂ_ｍｉｎ）｝および｛Ｂ_ｍａｘ，ｐ_ｍａｘ＝ｆ_２（Ｂ_ｍａｘ）｝に基づいて第２の関数を構成することができる。好ましくは、第１の関数と同様の様相の単調性を有する第２の関数、特に、上記２つの点を介して接続される３個の断片による断片連続関数を構成する。

したがって、図２の例の右側部分では、第２の関数が次のように構成される：
－最小閾値Ｂ_ｍｉｎ以下の充填レベルでは、応答期限が最低値ｐ_ｍｉｎ、好ましくはゼロに固定され、すなわち、遅延が全く付加されない（換言すれば、バッファは危険なまでに空であり、受信したセグメントを直接供給するリスクを取らない）；
－最大閾値Ｂ_ｍａｘ以上の充填レベルでは、応答期限が最大値ｐ_ｍａｘ、好ましくは１つのセグメントの長さｐに固定され（これによって、映像バッファの充填率をこれ以上増加しなくてすみ、Ｐ２Ｐキャッシュは、１つ前のセグメントの全体が読まれたときのみ新しいセグメントを供給することによってマージンを保つ）；
－２つの値の間にある場合、好ましくは直線の増加曲線が得られ（図２の例では、等式ｐ＝ｐ_ｍｉｎ＋（Ｂ－Ｂ_ｍｉｎ）^＊（ｐ_ｍａｘ－ｐ_ｍｉｎ）／（Ｂ_ｍａｘ－Ｂ_ｍｉｎ）である）、これは、バッファが満杯であればあるほど応答期限を長くすることができるので、さらに高い充填率に到達できることを示す。

第１および第２の関数が、セグメント受信ビットレートを示す上記の少なくとも１つのパラメータに対して逆単調性を有することも同様に可能であり（すなわち、第１の関数が減少関数であるとき第２の関数が増加関数であり、またその逆もある）、これは特に、ＡＢＲ論理が通過帯域に基づいている場合にいえる（その場合、第１の関数が増加関数で第２の関数が減少関数である）。

本発明による方法は、応答期限を適用する所定の設計に制限されるものではなく、当該技術の専門家は、この考え方を、ＡＢＲ論理、再生装置により監視されるタイプのパラメータ、Ｐ２Ｐネットワークの挙動等に適合させることができる。一般に、ＡＢＲ論理を定義する第１の関数に基づいて、応答期限を定義する第２の関数を構成するだけで十分であることを理解されたい。

再生
以下の説明では、場合によっては他のデバイス１２および／またはサーバ２からコンテンツを回収中であるクライアントデバイス１１に焦点を当てる。すなわち、第１のバッファメモリＭ１は、少なくとも１つの品質レベルで少なくとも１つの未処理のセグメント、可能であれば、コンテンツを構成するシーケンスの下位シーケンスを、それ以降保存する。

その場合、この方法は、１つのセグメント、この場合には第２のバッファメモリＭ２に置くべき次のセグメント（必ずしも次の読み取りセグメントではない。一般には、バッファされた複数の先行セグメントがある）のリクエストの受信工程（ａ）を、デバイスの処理手段１１０が実施することから開始される。上記リクエストは再生装置から受信され、好ましくは、セグメントリクエストの品質レベルすなわちビットレートが（ＡＢＲ論理の適用により）決定される。

この段階では、上記セグメントは、再生装置によりリクエストされた品質で第１のバッファメモリＭ１において少なくとも部分的に（すなわち少なくとも１つのフラグメントで）利用可能である。このセグメント／当該セグメントのフラグメントが別の品質である場合、一般にはコンテンツサーバ２から直接これを回収しなければならないが、これは時間がないからである。

前述のように、工程（ａ）は、その場合、ＡＢＲ論理により監視されているパラメータ（セグメント受信ビットレートを示す上記の少なくとも１つのパラメータ）、好ましくは第２のバッファメモリＭ２の充填レベルおよび／または通過帯域に特に応じて、上記再生装置のＡＢＲ論理に対して決定された応答期限の計算を有利には含む。工程（ａ）は、場合によっては、セグメント受信ビットレートを示す上記パラメータの「測定」を含む。

前述のように、応答期限を決定する第２の関数は、応答期限の最小値と最大値との間で、セグメント受信ビットレートを示す上記パラメータと共に好ましくは増加する。

回収されたのが次のセグメントのフラグメントだけであった場合（いわばセグメントが不完全に利用される場合）、計算された応答期限がフラグメントの長さに応じて好ましくは修正され、実際には応答期限の１つのフラグメントだけを適用すべきであることを反映するようにされる。なぜなら、第２のバッファメモリＭ２にはフラグメントではなく完全なセグメントだけしか供給できないからであり、この考え方は、短縮された応答期限の後で完全にセグメントを供給するというものであって、第１のバッファメモリＭ１内でこのセグメントを完全にする（回収し終わる）時間に対応する待機期限が暗々裏にはすでにあることを反映している。そのため、工程（ａ）は、セグメントを回収し終わるのに必要な推定時間に応じて計算された応答期限の修正を含む。

たとえば、式ｐ'＝ｐ－ｔｄｗを適用することができる。ここでｐ'は、修正された応答期限であり、ｔｄｗは、セグメントを回収し終わるのに必要な推定時間である。したがって、完全なセグメントを供給する前の、時間ｔｄｗの待機＋ｐ'の適用は、ｐの適用と同等であるので、全体の期限は同じままである。

工程（ｂ）では、リクエストされた上記セグメントが、上記応答期限の満了時に第１のバッファメモリＭ１からリクエストに応えて供給される。「上記応答期限の満了時に供給される」とは、応答期限の満了前に（最高で満了時に、さらには、幾つかの事例に限っては応答後に。これについては後述する）、再生装置がセグメントを持たないようにすることを意味する。大抵の場合、セグメントは応答期限の満了時に一挙に伝送されるが、デバイス１１の内部で、これを「ストリーミングする」すなわち、第１のバッファメモリＭ１からセグメントを徐々に（少しずつ）伝送することも全く可能であり、それによって応答期限の満了時に（できるだけ早く）最終部分が伝送される（その場合、応答期限は、「セグメントの最終ビットの伝送期限」である）。実際、完全なセグメントだけを読み取り可能であるものの、幾つかの再生装置はセグメントの下位セグメントを受け入れ可能である。このような段階的な伝送は、セグメントが全体として受信されない限り、再生装置がこれを利用できず、したがって供給されたとはみなされないので何も変わることはないが、しかし通過帯域測定を容易にできる点に注目すべきである。

セグメントの１つのフラグメントだけが第１のバッファメモリＭ１で利用できる場合、また、応答期限が、当該セグメントを回収し終わるのに必要な推定時間に応じて修正された場合、通常、当該セグメントは、修正された応答期限の満了時に同様に工程（ｂ）に供給される。先に述べたように、供給が分割されることもあるが、完全なセグメントの下位セグメント（完全にダウンロードされた１つのセグメントから得られる連続セグメント片に対応する）と、不完全なセグメント（大抵はちぐはぐな複数片に対応する幾つかのデータ部分だけがダウンロードされる）とを混同してはならない。第１のバッファメモリＭ１では、完全に利用可能な１つのセグメントだけをリクエストに応えて供給可能であり（フラグメントではない）、その結果、ダウンロードに予想以上に時間がかかっても、修正された応答期限の満了時にはセグメントを完全に利用することができる。そのため、修正された応答期限の満了時に（すなわち満了前ではない）できるだけ早く完全なセグメントが供給されるが、しかし満了後の可能性もある。実務上、完全なセグメントは、次のような２つの条件すなわち、セグメントを完全に利用できる（そのダウンロードが終了している）ことと、修正された応答期限が満了したこととが検証されたときに供給される。

いずれの場合も、セグメントは、好ましくは第２のバッファメモリＭ２に供給され、そのような理由で、工程（ｂ）は、上記第１のバッファメモリＭ１のセグメントをデバイス１１での再生に適したフォーマットに変換することを含むことができる。この工程は、未処理のセグメントを、最初のものとは違ってデバイス１１の再生装置が読み取り可能な、変換されたセグメントに変えることからなる。

たとえば、再生装置がＨＴＭＬ５に適合するブラウザを組み込まれている場合、変換は、ブラウザのＭｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｓｉｏｎ（メディアソース拡張機能）ＡＰＩによって、セグメントの映像データをインジェクションすることからなる。

当然のことながら、工程（ｂ）は、有利には、第２のバッファメモリＭ２に保存された１つ前のセグメントの再生を同時に含むので、セグメントは「順に行われる」。工程（ｂ）で回収されたセグメントが読まれる順番がまもなくやってくる。

いまや、再生が続く限り、工程（ａ）と（ｂ）を繰り返すことができる：期限の適用によりＡＢＲが安定化し、最悪の場合、ＡＢＲの新たな決定が原因で再生装置によりリクエストされる品質レベルがやはり変わってしまう場合でも、セグメントはいまでは、リクエストされた新たな品質レベルに従ってＰ２Ｐネットワークから充填されるので、ユーザには何ら支障がない。

予測
特に好ましくは、工程（ａ）は、場合によっては行われるＡＢＲの次の決定の予測、すなわち、（工程（ａ）が次回生じたときの）次のセグメントリクエストの品質レベルの予測をさらに含む。

実際、ＡＢＲによりリクエストされる品質レベルが変わる場合、計算された応答期限を適用する前に、第１の関数の適用により品質レベルを決定することができる。

計算を容易にするように、長さｐの１つの完全なセグメントが供給されたと仮定する。そうすると、工程（ｂ）の終わりに、第２のバッファメモリＭ２の充填レベルがｐすなわちセグメントの長さ分だけ増加する。それに対して、応答期限ｐが経過すると、第２のバッファメモリＭ２のコンテンツの同じ時間が読み取られて消去されるので、前回の充填レベルＢ_ｎ－１に対して式Ｂ_ｎ＝Ｂ_ｎ－１＋ｐ－ｐ_ｎにより新たな充填レベルＢ_ｎを表すことができる（セグメントの受信ビットレートを示すパラメータが通過帯域である場合、同様の計算を実施できることに注目されたい）。したがって、次回のＡＢＲの決定を予測するためにｆ_１（Ｂ_ｎ）を計算し、場合によっては品質レベルの変更を先取りして適正な品質レベルで今後のセグメントを回収するだけでよい（「プリフェッチ」という）。かくして、ユーザが支障を受ける確率はさらに低くなる。

この方法は、工程（ｂ）の後に予測検証工程（ｃ）を含むことができる点が注目される（場合によっては次に生じる工程（ａ）と混同される）。

より詳しくは、ＡＢＲ論理は、リクエストされる「新しい」品質レベル、すなわち次のセグメントに対してリクエストされる品質レベルを計算するために再開され、このため、対応するセグメントリクエストがクライアントソフトウェアに送信される。検証は、次のセグメントに対して、予測された品質レベルと実際にリクエストされた品質レベルとを単に比較することからなる。

学習
第１の実施形態によれば、第１の関数を認識していると仮定し、この第１の関数に基づいて第２の関数を再構成する。

しかしながら、別のケースでは、再生装置が完全に閉じられている場合、第１の関数をうまく認識できず、さらには全く認識することができない。

その場合、特にＡＢＲの決定予測を学習手段として用いることによって、第１の関数および／または第２の関数を徐々に学習することができる：各セグメントに対して、工程（ｃ）で、予測と実際に下された決定とを比較し、すなわち予測された品質レベルと実際にリクエストされた品質レベルとを比較して、これにより学習ループを構成する。

特にデフォルト機能を起点とし、時間の経過と共にパラメータを変化させることによって、第１または第２の関数を推定可能である。たとえば、第１の関数は、３個のセグメントによる断片関数を仮定すると、４個のパラメータＢ_ｍｉｎ、Ｒ_ｍｉｎ、Ｂ_ｍａｘおよびＲ_ｍａｘの値を介してパラメータ化可能であり、また同様に第２の関数は、３個のセグメントによる断片関数を仮定すると、４個のパラメータＢ_ｍｉｎ、ｐ_ｍｉｎ、Ｂ_ｍａｘおよびｐ_ｍａｘの値を介してパラメータ化可能である（したがって、変数は全部で６個である）。

そのため、コンテンツの最初のセグメントでクライアントソフトウェアの応答期限の計算がおそらく不正確に行われ、それによって予想外のＡＢＲの決定がなされ、制御不能な品質レベルの変更が生じても、アルゴリズムは速やかに改善され、ＡＢＲ論理が完全に制御される。

学習アルゴリズム、たとえばニューロンネットワークを特に使用可能である。

学習がそれに基づいてなされるデータはセッション間で保存可能であり、それによって、以降の複数のセッション時の学習フェーズに関連する問題をなくし、あるいは制限する。

たとえば再生装置のバージョン番号の変更のような幾つかのファクタを用いて、バックアップされたパラメータを無効化し、新しい学習フェーズのために未使用のパラメータで再始動することができる。

代替的／補完的に、学習された機能はたとえばＰ２Ｐメッセージを介して他のピア１２に伝送され、あるいはピア３の管理サーバに伝送可能である。

デバイスとコンピュータプログラム製品
第２の側面によれば、本発明は、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質を選択するのに適した再生装置で本発明の方法によるコンテンツ再生方法を実施するためのクライアントデバイス１１に関する。

このデバイス１１は、先に説明したように：
セグメントシーケンスから構成されたコンテンツの少なくとも１つのセグメントを一時的に保存し、未処理の各セグメントがピア・トゥ・ピアネットワーク１０内でこれを伝送するのに適したフォーマットにある、第１のバッファメモリＭ１と；
再生装置による再生に適したフォーマットで上記コンテンツの少なくとも１つの変換されたセグメントを一時的に保存する第２のバッファメモリＭ２と；データ処理手段１１０と、
を含む。

データ処理手段１１０、一般にはプロセッサは、１つのセグメントのリクエストを受信すると、再生装置の上記ＡＢＲ論理に対して決定された応答期限の満了時に第１のバッファメモリＭ１への上記セグメントの供給（通常は第２のバッファメモリＭ２へのインジェクションによる、再生装置への供給）をインプリメントするように構成される。

別の側面によれば、本発明は、クライアントデバイス１１、１２のピア・トゥ・ピアネットワーク１０内で配信されたコンテンツの、本発明の第１の側面によるクライアントデバイス１１での連続再生方法を（データ処理手段、特にクライアントデバイス１１のデータ処理手段で）実行するためのコード命令と、このコンピュータプログラム製品がある情報処理装置（たとえば上記クライアントデバイス１１のメモリ）による読み取りが可能な保存手段とを含む、コンピュータプログラム製品に関する。

別の側面によれば、本発明は、クライアントデバイス１１、１２のピア・トゥ・ピアネットワーク１０内で配信されたコンテンツの、本発明の第１の側面によるクライアントデバイス１１での連続再生方法を（データ処理手段、特にクライアントデバイス１１のデータ処理手段で）実行するためのコード命令と、このコンピュータプログラム製品がある情報処理装置（たとえば上記クライアントデバイス１１のメモリ）による読み取りが可能な保存手段とを含む、コンピュータプログラム製品に関する。
［項目１］
クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツをクライアントデバイスの再生装置で連続して再生する方法であって、上記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、上記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され、上記クライアントデバイスが、上記ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリを含む方法において、上記クライアントデバイスのデータ処理手段による以下の工程：
（ａ）上記再生装置からの１つのセグメントのリクエストの受信工程
（ｂ）上記再生装置の上記ＡＢＲ論理に対して決められた応答期限の満了時に上記第１のバッファメモリから上記セグメントを応答として供給する工程
を含む、方法。
［項目２］
上記ＡＢＲ論理は、セグメント受信ビットレートを示す少なくとも１つのパラメータに応じて、上記セグメントリクエストの品質レベルを計算可能な第１の関数により決定される、項目１に記載の方法。
［項目３］
第２の関数が、セグメント受信ビットレートを示す少なくとも１つの上記パラメータに応じて上記工程（ａ）で上記応答期限を計算可能である、項目２に記載の方法。
［項目４］
上記第２の関数が上記第１の関数に基づいて構成される、項目３に記載の方法。
［項目５］
上記第２の関数が、セグメント受信ビットレートを示す少なくとも１つの上記パラメータに対して単調である、項目３または４に記載の方法。
［項目６］
上記クライアントデバイスが、上記再生装置による再生に適したフォーマットでセグメントを保存するように構成された第２のバッファメモリをさらに含み、上記セグメントが上記工程（ｂ）で第２のバッファメモリに供給される、項目１から５のいずれか一項に記載の方法。
［項目７］
セグメント受信ビットレートを示す上記パラメータが、第２のバッファメモリの充填レベルおよび／または通過帯域である、項目２から５のいずれか一項と項目６との組み合わせに記載の方法。
［項目８］
上記工程（ａ）は、計算された応答期限に応じて次のセグメントリクエストの品質レベルの予測を含む、項目１から７のいずれか一項に記載の方法。
［項目９］
次のセグメントリクエストの品質レベルの上記予測の検証工程（ｃ）を含む、項目８に記載の方法。
［項目１０］
予測された品質レベルと実際にリクエストされた品質レベルとに基づく第２の関数の学習を含む、項目９に記載の方法。
［項目１１］
リクエストされたセグメントが、上記第１のバッファメモリでは不完全に利用可能であり、上記工程（ａ）が、上記セグメントを回収し終わるのに必要な推定時間に応じて計算された応答期限の修正を含み、工程（ｂ）では、上記セグメントが、修正された応答期限の満了時にできるだけ早く完全に供給される、項目１から１０のいずれか一項に記載の方法。
［項目１２］
クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツを再生装置で連続して再生するデバイスであって、上記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、上記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され、上記クライアントデバイスが、上記ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリと、データ処理手段とを含む、連続再生デバイスにおいて、
上記データ処理手段が、上記再生装置からセグメントのリクエストを受信すると、上記再生装置の上記ＡＢＲ論理に対して決められた応答期限の満了時に上記第１のバッファメモリから上記セグメントを応答として供給する、デバイス。
［項目１３］
コンピュータプログラム製品であって、上記プログラムがコンピュータにより実行されるとき、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、項目１から１１のいずれか一項に記載の方法を実行するためのコード命令を含む、製品。
［項目１４］
情報処理装置による読み取りが可能な保存手段であって、コンピュータプログラム製品が、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、項目１から１１のいずれか一項に記載の方法を実行するためのコード命令を含む、保存手段。

Claims (14)

1. クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツをクライアントデバイスの再生装置で連続して再生する方法であって、前記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、前記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され、前記クライアントデバイスが、前記ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリを含む方法において、前記クライアントデバイスのデータ処理手段による以下の工程：
   （ａ）前記再生装置からの１つのセグメントのリクエストの受信工程
   （ｂ）前記再生装置の前記ＡＢＲ論理に対して決められた応答期限の満了時に前記第１のバッファメモリから前記セグメントを応答として供給する工程
   を含む、方法。
2. 前記ＡＢＲ論理は、セグメント受信ビットレートを示す少なくとも１つのパラメータに応じて、前記セグメントリクエストの品質レベルを計算可能な第１の関数により決定される、請求項１に記載の方法。
3. 第２の関数が、セグメント受信ビットレートを示す少なくとも１つの前記パラメータに応じて前記工程（ａ）で前記応答期限を計算可能である、請求項２に記載の方法。
4. 前記第２の関数が前記第１の関数に基づいて構成される、請求項３に記載の方法。
5. 前記第２の関数が、セグメント受信ビットレートを示す少なくとも１つの前記パラメータに対して単調である、請求項３または４に記載の方法。
6. 前記クライアントデバイスが、前記再生装置による再生に適したフォーマットでセグメントを保存するように構成された第２のバッファメモリをさらに含み、前記セグメントが前記工程（ｂ）で第２のバッファメモリに供給される、請求項１から５のいずれか一項に記載の方法。
7. セグメント受信ビットレートを示す前記パラメータが、第２のバッファメモリの充填レベルおよび／または通過帯域である、請求項２から５のいずれか一項と請求項６との組み合わせに記載の方法。
8. 前記工程（ａ）は、計算された応答期限に応じて次のセグメントリクエストの品質レベルの予測を含む、請求項１から７のいずれか一項に記載の方法。
9. 次のセグメントリクエストの品質レベルの前記予測の検証工程（ｃ）を含む、請求項８に記載の方法。
10. 予測された品質レベルと実際にリクエストされた品質レベルとに基づく第２の関数の学習を含む、請求項９に記載の方法。
11. リクエストされたセグメントが、前記第１のバッファメモリでは不完全に利用可能であり、前記工程（ａ）が、前記セグメントを回収し終わるのに必要な推定時間に応じて計算された応答期限の修正を含み、工程（ｂ）では、前記セグメントが、修正された応答期限の満了時にできるだけ早く完全に供給される、請求項１から１０のいずれか一項に記載の方法。
12. クライアントデバイスのピア・トゥ・ピアネットワーク内で配信されるコンテンツを再生装置で連続して再生するデバイスであって、前記コンテンツが、複数の品質レベルで利用可能なセグメントシーケンスから構成され、前記再生装置が、アダプティブ・ビットレートＡＢＲ制御論理に従ってセグメントの品質レベルを選択するように構成され、前記クライアントデバイスが、前記ピア・トゥ・ピアネットワーク内での伝送に適したフォーマットでセグメントを保存するように構成された第１のバッファメモリと、データ処理手段とを含む、連続再生デバイスにおいて、
    前記データ処理手段が、前記再生装置からセグメントのリクエストを受信すると、前記再生装置の前記ＡＢＲ論理に対して決められた応答期限の満了時に前記第１のバッファメモリから前記セグメントを応答として供給する、デバイス。
13. コンピュータプログラム製品であって、前記プログラムがコンピュータにより実行されるとき、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、請求項１から１１のいずれか一項に記載の方法を実行するためのコード命令を含む、製品。
14. 情報処理装置による読み取りが可能な保存手段であって、コンピュータプログラム製品が、コンテンツサーバに接続されたクライアントデバイスのピア・トゥ・ピアネットワークにおけるストリーミングコンテンツ配信の、請求項１から１１のいずれか一項に記載の方法を実行するためのコード命令を含む、保存手段。

Images