JP5269208B2 - データ配信方法及び装置 - Google Patents

Description

本発明はデータ配信方法及び装置、特にデータ配信制御方法及び装置に関する。

ビデオ・オン・デマンド（ＶｏＤ）サービスは、ユーザがビデオ・コンテンツを選択して視聴することを可能にする。ＶｏＤシステムは、セット・トップ・ボックス（ＳＴＢ）、ディジタル・ビデオ・レコーダ、パーソナル・ビデオ・レコーダ、ポータブル・メディア・プレイヤ、コンピュータ、移動電話機又はＶｏＤクライアントを有するＰＤＡの様なデバイスへ、リアルタイムで見るストリーム・コンテンツ又は任意の時間に見るダウンロード・コンテンツの何れかを送信する。ビデオ・オン・デマンド・ダウンロード及びストリーミングは、ユーザが、その都合の良い時にビデオ・コンテンツを視聴することを可能にするが、ＶＣＲ、ＤＶＤレコーダ又はＤＶＲを使用して以前に記録した伝送情報を再生する場合には、従来から利用可能な機能（即ち停止、早送り、巻き戻し）もユーザに提供する。

ＶｏＤコンテンツは、ヘッド・エンド・システムとして参照する、幾つかの中央サーバからユーザに配信することができる。マルチキャストは、複数のユーザにコンテンツを配信するのに非常に効率的であるが、マルチキャスト配信は、オン・デマンドでの相互作用をユーザに提供しないので、ＶｏＤサービスは、通常、コンテンツを配信するために、ユニキャスト機構（例えばＨＴＴＰ）に依存する。しかしながら、多数のユーザに多量のコンテンツを同時に配信する場合、これらユニキャスト配信機構は、非効率的であり、よって、限られたＣＰＵ能力及び保存容量しか持たないヘッド・エンド・システムには課題であり得る。

これらの課題を克服するために、ピア・ツー・ピア（Ｐ２Ｐ）機構が、ＶｏＤコンテンツを配信するために利用され得る。Ｐ２Ｐシステムでは、ネットワークのピア数が大きければ大きいほど、利用可能である保存容量及びＣＰＵ能力は大きくなる。この様に、ネットワークに十分なピア数があると、Ｐ２Ｐ機構は非常に効率的であり得る。Ｐ２ＰによるＶｏＤシステムでは、ヘッド・エンドＶｏＤサーバから、複数のユーザのＶｏＤクライアント・デバイスに、コンテンツは“プル”又は“プッシュ”される。これらＶｏＤクライアントは、所望のビデオ・コンテンツを取得するために、他のピアＶｏＤクライアント・デバイスによりアクセスされ得る。

プル機構を使用する場合、ＶｏＤコンテンツは、ヘッド・エンドからの初期送信中に、“ライブ”にそのコンテンツにアクセスするＶｏＤクライアントにより取得される。これらＶｏＤクライアントは、他のユーザがこのコンテンツを見る場合、他のＶｏＤクライアントによりアクセスされ、コンテンツのソースとして利用され、それにより時間シフト・サービスを可能にする。図１は、コンテンツが、ヘッド・エンドからピアによりプルされるＰ２ＰのＶｏＤシステムの例を示している。実行するステップは以下の通りである。

Ａ１．複数のＶｏＤクライアント１は、各々独立にサービス・プロバイダのＶｏＤサーバ２からのコンテンツの“ライブ”ストリームへの参加を選択する。例えば、これは視聴者がＴＶ番組の送信時に視聴する番組を選択することに相当する。

Ａ２．これらＶｏＤクライアント１は、マルチキャスト・グループに参加し、ＶｏＤサーバ２から所望のコンテンツの受信を開始する。ＶｏＤサーバ２は、映画の様な事前に記録したコンテンツを配信することができ、ライブ・スポーツ・イベントの様なライブ・コンテンツをストリーミングすることができる。

Ａ３．コンテンツを受信すると、各ＶｏＤクライアント１は、コンテンツをそのメモリに保存する。ＶｏＤクライアント１がコンテンツの保存に成功すると、ＶｏＤクライアント１は、このことをトラッカ３に報告する。トラッカ３は、どのコンテンツがどこに保存されているかを追跡する機能ブロックである。このトラッカ３は、ヘッド・エンド・システムに統合することもでき、ヘッド・エンド・システムから分離して配置することもでき、例えばＤＨＴに基づく分散システムであり得る。

Ａ４．ある時間の後に、別のＶｏＤクライアント４は、このコンテンツを要求する。トラッカ３は、現在オンラインであり、かつ、そのコンテンツを所有し、よって、要求されたコンテンツのソースとして動作できるＶｏＤクライアント又はＶｏＤクライアントのセットを通知することで、その様な要求に応える。

Ａ５．コンテンツは、要求したＶｏＤクライアント４により、ソースとなるＶｏＤクライアント１からＰ２Ｐ様式でダウンロードされる。要求したＶｏＤクライアント４のユーザは、この場合、時間シフト様式でコンテンツを視聴することができる。

プッシュ機構は、ＶｏＤクライアントがコンテンツを要求してない場合でさえ、ヘッド・エンドにおいて、ＶｏＤサーバが、ＶｏＤクライアントにコンテンツを配信することを可能にする。ここでは、保存デバイスは常に１つ以上のマルチキャスト・グループを聴取しており、保存デバイスは、ヘッド・エンドのＶｏＤサーバがこれらのグループにプッシュするあらゆるコンテンツを受信することを想定している。図２は、ヘッド・エンドからＶｏＤクライアントへコンテンツをプッシュするＰ２ＰのＶｏＤシステムの例を示している。実行するステップは以下の通りである。

Ｂ１．ＶｏＤサーバ２は、複数のＶｏＤクライアント１に亘り保存されるコンテンツを準備する。コンテンツは、複数のＶｏＤクライアントに送信され、保存されるのに適した“ブロック”に分割され得る。ヘッド・エンド・システムの論理では、次いで、このコンテンツを保存すべき１つ以上のＶｏＤクライアント１を選択する。選択されるＶｏＤクライアント１は、オンラインでなければならない。

Ｂ２．マルチキャスト・ストリーミングが、選択されたＶｏＤクライアント１に対して開始され、選択されたＶｏＤクライアント１のそれぞれは、ある信号プロトコルによりストリーミングに参加する。このコンテンツ配信に使用できるマルチキャス・トプロトコルの例は、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）(非特許文献１を参照）又は実時間伝送プロトコル（ＲＴＰ）(非特許文献２を参照）である。

Ｂ３．コンテンツの受信に成功して保存した各ＶｏＤクライアント１は、このことをトラッカ３に報告する。この報告は、ＶｏＤクライアントのＩＤ（例えばＩＰアドレス）及び受け入れたコンテンツの表示を含む。

Ｂ４．ある時間後、別のＶｏＤクライアント４が、そのコンテンツを要求する。トラッカ３は、現在オンラインであり、そのコンテンツを所有し、よって、要求されたコンテンツのソースとして動作できるＶｏＤクライアント又はＶｏＤクライアントのセットの（例えばそのＩＰアドレス）を通知して、その様な要求に応える。

Ｂ５．要求したＶｏＤクライアント４は、ソースであるＶｏＤクライアント１とＰ２Ｐセッションを開始する。要求されたコンテンツ・ブロックのセットは、要求したＶｏＤクライアント４により取得され、再構成され、描画される。要求したＶｏＤクライアント４のユーザは、よって、時間シフト様式でコンテンツを視聴することができる。

ＲＦＣ３９２６ ＲＦＣ３５５０

本発明の第１の態様によれば、ピア・ツー・ピア・ネットワークのピアが他のピアにデータを提供することを可能にするために、ピアにデータを配信する方法が提供される。本方法は、データ項目を保存するために必要なピアの最小数を事前に規定するステップと、１つ以上のデータ・サーバから、複数のデータ受信ピアにデータ項目を送信するステップと、データ項目を保存するために利用可能な十分な保存容量を有するデータ受信ピアの数が、事前に規定した最小数未満であるかを判定するステップと、最小数未満であれば、十分な保存容量を利用可能にするために、保存済データを削除するステップと、を含んでいる。

データ項目を保存するために利用可能な十分な保存容量を有するデータ受信ピアの数が、事前に規定した最小数未満であるかを判定するステップは、各データ受信ピアで、十分な保存容量を利用可能であれば、データ項目を保存して、データ項目の保存をトラッカに報告するステップと、トラッカにおいて、ピアが保存しているデータのレコードを維持し、データ項目が、事前に規定された最小数のピアで保存されているかを判定するステップと、を含むことができる。

十分な保存容量を利用可能にするために、保存済データを削除するステップは、トラッカにおいて、データ項目を保存していないデータ受信ピアを特定し、これらデータ受信ピアから削除できる保存済データを特定するために、ピアが保存しているデータのレコードを使用し、特定された保存済データを削除するために、データ項目を保存していないこれらデータ受信ピアに命令を送信するステップを含むことができる。データ項目を保存しないこれらデータ受信ピアにおいては、トラッカからの命令を受信すると、特定された保存済データを削除する。

本方法は、さらに、データ項目を保存していないこれらデータ受信ピアにおいて、保存済データの削除の後に、保存済データの削除をトラッカに報告するステップを含むことができる。トラッカでは、保存済データを削除したことの報告を受信し、ピアで保存されているデータのレコードを更新し、データ項目を保存していないこれらデータ受信ピアにデータ項目を再送信する命令をデータ・サーバに送信する。データ・サーバでは、データ項目を保存していないこれらデータ受信ピアにデータ項目を再送信する。

あるいは、データ項目を保存するために利用可能な十分な保存容量を有するデータ受信ピアの数が、事前に規定した最小数未満であるかを判定するステップは、データ・サーバにおいて、データ受信ピアに送信するデータ項目にメタデータ含めるステップを、含むことができ、メタデータは、少なくとも、ピアがデータ項目を保存しなければならないか否かを示している。データ受信ピアでは、データ項目を保存することが要求されているかを判定するためにメタデータを評価し、要求されていれば、十分な保存容量を利用可能であるかを判定する。

十分な保存容量を利用可能にするために、保存済データを削除するステップは、利用可能な十分な保存容量を持たないデータ受信ピアにおいて、削除できる保存済データを選択するステップと、選択したデータを削除するステップを含むことができる。

十分な保存容量を利用可能にするために、保存済データを削除するステップは、データ受信ピアにおいて、保存済データを選択するステップと、選択したデータの削除許可を要求するメッセージをトラッカに送信するステップと、許可を与えるか否かの応答をトラッカから受信するステップと、を含むことができる。

トラッカからの応答が許可を与えないものであれば、データ受信ピアにおいて、削除できる代わりの保存済データを選択し、代わりの保存済データの削除許可をトラッカに要求し、許可を与えるか否かの応答をトラッカから受信する。トラッカからの応答が許可を与えるものであれば、データ受信ピアにおいて、選択したデータを削除する。

あるいは、トラッカから応答が許可を与えないものであれば、データ受信ピアにおいて、削除できる代わりの保存済データを応答が特定しているかを判定する。トラッカからの応答が代わりの保存済データを特定していなければ、削除できる代わりの保存済データを選択し、代わりの保存済データの削除許可をトラッカに要求する。トラッカからの応答が、代わりの保存済データを特定していれば、代わりの保存済データを削除する。

本方法は、保存済データを削除したデータ受信ピアにおいて、データ項目を保存するステップと、保存済データの削除及びデータ項目の保存をトラッカに報告するステップと、をさらに含むことができる。

本発明の第２の態様によれば、ピア・ツー・ピア・ネットワークのピアを動作させる方法が提供される。本方法は、１つ以上のデータ・サーバからデータ項目を受信するステップと、データ項目を保存するために十分な保存容量を利用可能であるかを判定するステップと、を含んでいる。十分な保存容量が利用可能であれば、データ項目を保存し、データ項目の保存をトラッカに報告し、十分な保存容量が利用可能でなければ、トラッカから命令を受信すると、保存済データを削除する。本方法は、さらに、保存済データの削除の後に、保存済データの削除をトラッカに報告するステップと、１つ以上のデータ・サーバからデータ項目を受信するステップと、データ項目を保存するステップと、データ項目の保存をトラッカに報告するステップをさらに含むことができる。

本発明の第３の態様によれば、ピア・ツー・ピア・ネットワークのトラッカを動作させる方法が提供される。本方法は、ピアが保存したデータ項目の報告をこれらピアから受信するステップと、ピアが保存しているデータのレコードを維持するステップと、データ項目が、事前に規定した最小数のピアで保存されているかを判定するステップと、保存されていなければ、データ項目を保存していないピアを特定するステップと、データ項目を保存していないピアから削除できる保存済データを特定するステップと、選択したデータの削除を、データ項目を保存していない１つ以上のピアに命令するステップと、を含んでいる。本方法は、さらに、保存済データの削除の確認を受信すると、ピアが保存しているデータのレコードを更新するステップと、データ項目のそれらピアへの再送信を、１つ以上のデータ配信サーバに命令するステップと、を含むことができる。

本発明の第４の態様によれば、ピア・ツー・ピア・ネットワークのデータ・サーバを動作させる方法が提供される。本方法は、メタデータを含むデータ項目を１つ以上のピアに送信するステップを含み、メタデータは、少なくとも、ピアがデータ項目を保存しなければならないか否かをピアに示すものである。

本発明の第５の態様によれば、ピア・ツー・ピア・ネットワークのピアを動作させる方法が提供される。本方法は、１つ以上のデータ・サーバから、メタデータを含むデータ項目を受信するステップと、新たな項目を保存することを、ピアが要求されているかを判定するためにメタデータを評価するステップと、要求されていれば、データ項目を保存するために十分な保存容量を利用可能であるかを判定するステップと、を含んでいる。

データ項目を保存するために十分な保存容量を利用可能であれば、データ項目を保存し、トラッカにデータ項目の保存を報告する。データ項目を保存するために十分な保存容量を利用可能でなければ、削除できる保存済データを選択し、選択したデータを削除する。また、データ項目を保存するために十分な保存容量を利用可能でなければ、削除できる保存済データを選択し、選択したデータの削除の許可を要求するメッセージをトラッカに送信し、トラッカから応答を受信する。

トラッカからの応答が許可を与えるものであれば、保存済データを削除し、データ項目を保存し、トラッカにデータ項目の保存を報告する。トラッカからの応答が許可を与えないものであれば、削除できる代わりの保存済データを応答が特定しているかを判定する。トラッカからの応答が、代わりの保存済データを特定していれば、代わりの保存済データを削除し、データ項目を保存し、トラッカにデータ項目の保存を報告する。トラッカからの応答が、代わりの保存済データを特定していなければ、削除できる代わりの保存済データを選択し、代わりの保存済データの削除許可を要求するメッセージをトラッカに送信する。

本方法は、さらに、代わりの保存済データの削除の後に、データ項目を保存するステップと、代わりの保存済データの削除及びデータ項目の保存をトラッカに報告するステップと、を含むことができる。

本発明の第６の態様によれば、ピア・ツー・ピア・ネットワークのトラッカを動作させる方法が提供される。本方法は、ピアが保存しているデータの報告をピアから受信するステップと、ピアが保存しているデータのレコードを維持するステップと、幾つかの選択データの削除許可の要求をピアから受信するステップと、保存しているデータのレコードを使用して、選択データを削除できるかを判定するステップと、選択データの削除許可を与えるか否かを示す応答を要求を行ったピアに送信するステップと、を含んでいる。選択データを削除できないと判定すると、削除できる代わりのデータを特定するために、保存しているデータのレコードを使用し、選択データの削除許可は与えられないことを示し、かつ、代わりのデータを特定する応答を要求を行ったピアに送信する。

データは、ビデオを含むことができ、ピアは、ビデオ・オン・デマンド・システムにおけるクライアントを含むことができる。

本発明の第７の態様によれば、ピア・ツー・ピア・ネットワークにおけるピアとして動作する様に構成された装置が提供される。本装置は、データを保存するメモリ・ユニットと、データ・サーバからデータ項目を受信する受信機と、トラッカにメッセージを送信する送信機と、トラッカからメッセージを受信する受信機と、プロセッサ・ユニットと、を備えている。プロセッサ・ユニットは、データ項目を保存するために十分なメモリが利用可能であるかを判定し、十分なメモリが利用可能であれば、データ項目の保存を実行し、データ項目の保存成功をトラッカに報告するメッセージを生成し、十分なメモリが利用可能でなければ、トラッカからの命令を含むメッセージを受信すると、命令に従い保存済データの削除を実行し、保存済データの削除をトラッカに報告するメッセージを生成する。

本発明の第８の態様によれば、ピア・ツー・ピア・ネットワークにおけるトラッカとして動作する様に構成された装置が提供される。本装置は、ピアからメッセージを受信する受信機と、ピアにメッセージを送信する送信機と、データ・サーバにメッセージを送信する送信機と、ピアが保存しているデータのレコードを維持するメモリ・ユニットと、プロセッサ・ユニットと、を備えている。プロセッサ・ユニットは、データ項目の保存を報告するピアから、事前に規定した最小数のメッセージを、トラッカが受信したかを判定し、受信していなければ、削除できる保存済データを選択し、データ項目を保存していない１つ以上のピアに、保存済データの削除を命令するメッセージを生成し、保存済データの削除確認を受信すると、保存済データの削除が確認されたピアへのデータ項目の再送信を１つ以上のデータ・サーバに命令するメッセージを生成する。

本発明の第９の態様によれば、ピア・ツー・ピア・ネットワークにおけるデータ・サーバとして動作する様に構成された装置が提供される。本装置は、データを保存するメモリ・ユニットと、データ項目に含まれ、少なくとも、ピアがデータ項目を保存しなければならないか否かをピアに指示するメタデータを生成するプロセッサ・ユニットと、メタデータを含むデータ項目を１つ以上のピアに送信する送信機と、を備えている。

本発明の第１０の態様によれば、ピア・ツー・ピア・ネットワークにおけるピアとして動作する様に構成された装置が提供される。本装置は、データを保存するメモリ・ユニットと、１つ以上のデータ・サーバからメタデータを含むデータ項目を受信する受信機と、データ項目をピアで保存することが要求されているかを判定するために、メタデータを評価するプロセッサ・ユニットと、を備えている。データ項目の保存が意図されていれば、プロセッサ・ユニットは、データ項目を保存するために十分な保存容量を利用可能であるかを判定する。

十分な保存容量を利用可能であれば、プロセッサ・ユニットは、データ項目の保存を実行し、データ項目の保存をトラッカに報告するメッセージを生成することができる。十分な保存容量を利用可能でなければ、プロセッサ・ユニットは、削除できる保存済データを選択し、保存済データの削除を実行し、データ項目の保存を実行し、保存済データの削除及びデータ項目の保存をトラッカに報告するメッセージを生成することができる。装置は、トラッカにメッセージを送信する送信機をさらに備えることができる。

あるいは、十分な保存容量を利用可能でなければ、プロセッサ・ユニットは、削除できる保存済データを選択し、保存済データの削除許可を要求するトラッカへのメッセージを生成することができる。装置は、トラッカにメッセージを送信する送信機と、トラッカからメッセージを受信する受信機と、をさらに備えることができる。

トラッカの応答が、許可を与えるものであれば、プロセッサ・ユニットは、保存済データの削除を実行し、データ項目の保存を実行し、保存済データの削除及びデータ項目の保存をトラッカに報告するメッセージを生成することができる。トラッカからの応答が許可を与えるものでなければ、プロセッサ・ユニットは、削除できる代わりの保存済データを、応答が特定するかを判定する。トラッカからの応答が、代わりの保存済データを特定していれば、プロセッサ・ユニットは、代わりの保存済データの削除を実行し、データ項目の保存を実行し、代わりの保存済データの削除及びデータ項目の保存をトラッカに報告するメッセージを生成することができる。トラッカからの応答が、代わりの保存済データを特定していなければ、プロセッサ・ユニットは、削除できる代わりの保存済データを選択し、代わりの保存済データの削除許可を要求するトラッカへのメッセージを生成することができる。

本発明の第１１の態様によれば、ピア・ツー・ピア・ネットワークにおけるトラッカとして動作する様に構成された装置が提供される。本装置は、ピアからメッセージを受信する受信機と、ピアにメッセージを送信する送信機と、データ・サーバにメッセージを送信する送信機と、ピアが保存しているデータのレコードを維持するメモリ・ユニットと、プロセッサ・ユニットと、を備えており、プロセッサ・ユニットは、ピアからある保存済データの削除の許可要求を受信すると、保存済データを削除できるかを判定するために、保存しているデータのレコードを使用し、選択データの削除の許可を与えるか否かを示す、要求ピアへのメッセージを生成する。

保存済データを削除できないと判定すれば、プロセッサ・ユニットは、削除できる代わりの保存済データを特定するために、保存しているデータのレコードを使用することができ、保存済データの削除許可は与えられないこと、かつ、代わりの保存済データを特定する、要求ピアへのメッセージを生成することができる。

データはビデオを含むことができ、ピアはビデオ・オン・デマンド・システムにおけるクライアントを含むことができる。

コンテンツが、ヘッド・エンドからピアによりプルされるＰ２ＰのＶｏＤシステム例を示す図。 コンテンツが、ヘッド・エンドからピアにプッシュされるＰ２ＰのＶｏＤシステム例を示す図。 本発明の一実施形態によるデータ保存制御の方法例を示すフロー図。 本発明の一実施形態によるアクティブ・トラッカによるコンテンツ保存制御の簡略化した信号フロー例を示す図。 本発明の一実施形態によるアクティブ・トラッカが実行する処理例を示すフロー図。 本発明の一実施形態によるコンテンツ保存制御を行うＶｏＤクライアントの簡略化した信号フロー例を示す図。 本発明の一実施形態によるＶｏＤクライアントにより実行される処理例を示すフロー図。 本発明の一実施形態によるアクティブ・トラッカと協働するＶｏＤクライアントの簡略化した信号フロー例を示す図。 本発明の一実施形態によるアクティブ・トラッカと協働するＶｏＤクライアントが実行する処理例を示すフロー図。 本発明の一実施形態によるＶｏＤシステム例を概略的に示す図。

既存ピア・ツー・ピア技術の問題点は、集中システムにより選択されたピアへの特定データ項目の保存が保証されないことであると認識される。上記のビデオ・オン・デマンド・システムに関して、トラッカ機能は、どのピアがどのデータ項目を保持しているかを単に追跡するのみである。例えば、選択ピアの何れかが、さらなるデータ保存には、空き容量が不十分な場合がある。これは、データ保存に成功したピア数が、Ｐ２Ｐネットワークの適切なサービスには不十分である状況に繋がり得る。この問題を解決するために、データ保存制御の導入を提案し、運用会社のポリシーの要求により、十分な数のピアがデータを保存することを保証する。

ピアにおけるデータ保存を制御し得る方法を以下に説明する。本方法は、データ項目の保存に必要なピアの最小数を事前に規定するステップと、データ項目を複数のピアに送信するステップと、データが送信され、データ項目の保存に利用可能な保存容量を十分に有するピア数を判定するステップと、を含む。この数が事前に規定した最小数より小さいと判定されれば、少なくとも事前に規定したピアの最小数で、データ項目の保存に利用できる十分な保存容量を確保するために、以前に保存したデータが削除される。

図３はデータ保存制御の方法例を示すフロー図である。実行するステップは以下の通りである。

Ｃ１．データ配信サービス運用会社に属する集中システムは、配信すべきデータ項目の保存に必要なピアの最小数を判定するためのロジック又はポリシーを含んでいる。

Ｃ２．データ項目は、データ配信サービスのデータ・サーバから、複数のピアに送信される。このピア数は、少なくとも事前に規定したピアの最小数でなければならない。

Ｃ３．そのデータを送信したピアであって、データ項目の保存に利用できる十分な保存容量を有するピアの数を判定する。

Ｃ４．この数が事前に規定した最小数未満であるかが判定される。

Ｃ５．事前に規定した最小数未満ではない、つまり、ピア数が最小数以上であると判定されれば、さらなる動作を行わない。

Ｃ６．事前に規定した最小数未満であると判定されれば、少なくとも事前に規定した最小数のピアでデータ項目を保存するために利用できる十分な保存容量を確保するために、以前に保存したデータが削除される。

このデータ保存制御方法は、複数の方法で達成できる。例えば、１つの可能な解決策は、一旦、１つ以上のデータ配信サーバからデータを受信したとピアが報告した場合、データ保存をピアに明確に指令するための、アクティブ・トラッカの導入を含む。アクティブ・トラッカは、データ配信システムの運用会社が設定する保存要求の実施に責任を負う。

アクティブ・トラッカを使用する場合、ピア・ツー・ピア・データ配信システムの運用会社は、システムに見出さねばならないデータを特定するポリシー・セットを実施することができよう。例えばビデオ・オン・デマンド・システムで、これらポリシーは、１０，０００の映画がシステムのエンド・ユーザに常に利用可能でなければならない、最近の３週間に送信されたＴＶコンテンツがエンド・ユーザに利用可能でなければならない、といったことを特定できる。さらに、ＶｏＤシステムの運用会社は、Ｐ２Ｐネットワークの他のＶｏＤクライアントにコンテンツを提供するのに十分な数のソース数が存在することを確実にするために、最小数のＶｏＤクライアントがコンテンツを保存（例えば、所望の複製係数）することを要求するであろう。よって、アクティブ・トラッカが受信する、データ項目の保存を報告するピアからのメッセージ数がこの要求条件を満たさない場合、アクティブ・トラッカは、十分なメモリを空きにするために、他のコンテンツを削除することを命令し、あるＶｏＤクライアントにコンテンツの保存を“強いる”であろう。各ＶｏＤクライアントが保存しているコンテンツに関するアクティブ・トラッカの知見を、削除するコンテンツの適切な選択に使用し、対応するＶｏＤクライアントにそれを命令するアクティブ・トラッカによりこれを達成することができる。ヘッド・エンドのＶｏＤサーバから再送信する場合、これらＶｏＤクライアントは、十分なコンテンツを削除し、新たなコンテンツを保存するであろう。

図４はＶｏＤシステムにおけるアクティブ・トラッカによるコンテンツ保存制御の簡略化した信号フロー例を示している。実行するステップは以下の通りである。

Ｄ１．ＶｏＤクライアント１は、マルチキャストのプッシュ／プル・イベントによりヘッド・エンドのＶｏＤサーバ２からコンテンツを受信する。ＶｏＤサーバ２は、映画の様な事前に記録されたコンテンツを配信することや、ライブ・スポーツ・イベントの様なライブ・コンテンツをストリーミングすることができる。受信コンテンツは、ＶｏＤクライアント１に保存される。

Ｄ２．ＶｏＤクライアント１は、受信して保存したコンテンツを特定するための報告をアクティブ・トラッカ３に送信する。アクティブ・トラッカ３は、ＶｏＤクライアントから受信する報告を使用して、ＶｏＤクライアントに配信され保存されているコンテンツの完全な絵を描く。この情報は、総てのＶｏＤクライアントのコンテンツを管理するために使用される。

Ｄ３．報告数が、サービス運用会社が規定する要求数未満であれば、アクティブ・トラッカ３は、この問題の修正に必要なあらゆるアクションを取り、ＶｏＤクライアントにコンテンツを保存するための別の試みが行われることを保証するであろう。例えば、これらクライアントにコンテンツを保存する別の試行を行う前に、スペースを空けるために、あるコンテンツを削除することを、アクティブ・トラッカ３は、複数のＶｏＤクライアントに命令することができる。オプションとして、アクティブ・トラッカ３は、各ＶｏＤクライアントに保存されるコンテンツのさらなる管理法を決定することができる。例えば、アクティブ・トラッカは、クライアントにコンテンツの削除、コンテンツ有効日時の設定と、その後のコンテンツの削除若しくはコンテンツの別のクライアントへの移動を行わせるための命令を送信することができる。

Ｄ４．ＶｏＤクライアント１は、その後、アクティブ・トラッカ３からのあらゆる指令の受信を承認する。加えて、クライアントは、これら命令の動作結果をアクティブ・トラッカ３に報告することができる。

図５は、ＶｏＤシステムのアクティブ・トラッカが実行する処理例を示すフロー図である。実行するステップは以下の通りである。

Ｅ１．アクティブ・トラッカ３は、ヘッド・エンドのＶｏＤサーバ２が配信するコンテンツ項目に関係する複数の報告を受信する。

Ｅ２．一旦、ヘッド・エンドのＶｏＤサーバ２がコンテンツ配信を完了すると、アクティブ・トラッカ３は、ＶｏＤクライアント１から受信した保存成功報告の数が、ＶｏＤサービス運用会社により設定された要求条件（つまり、最小数／複製係数）を満たすか否かを判定する。

Ｅ３．アクティブ・トラッカ３が、十分な数の保存成功報告を受信したと判定すれば、アクティブ・トラッカ３はさらなる動作を行わない。

Ｅ４．アクティブ・トラッカ３が、受信した保存成功報告の数が不十分であると判定すれば、Ｐ２Ｐネットワークを形成するクライアントが保存するコンテンツに関するアクティブ・トラッカの知見を使用し、アクティブ・トラッカ３は、十分な保存容量を可能にするために、ＶｏＤクライアントから削除できるコンテンツを特定する。

Ｅ５．アクティブ・トラッカ３は、その後、適切なＶｏＤクライアントに選択したコンテンツを削除することを命令する。

Ｅ６．アクティブ・トラッカ３は、その後、命令した通り、コンテンツの削除が成功したことを確認する確認報告をＶｏＤクライアントから受信する。

Ｅ７．アクティブ・トラッカ３は、その後、ヘッド・エンドのＶｏＤサーバ２に、関連するＶｏＤクライアントにコンテンツを再送する様に命令する。

Ｅ８．アクティブ・トラッカ３は、その後、命令されたＶｏＤクライアントから、再送されたコンテンツの保存の保存成功報告を受信する。

既に概説した問題の代替解決策として、コンテンツ保存制御は、ＶｏＤクライアント自体により実行することができ、コンテンツが、Ｐ２Ｐネットワークに最初に配信されるときに、ＶｏＤクライアントは、ヘッド・エンドのＶｏＤサーバ２から受信する保存指令をアクティブに実行する。図６は、コンテンツ保存制御を行うＶｏＤクライアントの簡略化した信号フロー例を示している。実行するステップは以下の通りである。

Ｆ１．ＶｏＤクライアント１は、マルチキャストのプッシュ／プル・イベントによりヘッド・エンドのＶｏＤサーバ２からコンテンツを受信する。ヘッド・エンドのＶｏＤサーバ２は、コンテンツにメタデータも含め、このメタデータは、このコンテンツを保存すべきクライアントを表示する。受信メタデータは、コンテンツをクライアント・デバイスの一時的又は永久保存セグメントのいずれに保存すべきか、保存期間又はコンテンツの優先度等の、他の要求条件も表示することができる。

Ｆ２．ＶｏＤクライアント１は、このメタデータを評価し、コンテンツが、このクライアントによる保存を意図していることを判定する。例えば、各ＶｏＤクライアントは、ＶｏＤクライアントのグループのメンバであり、各グループは、特定コンテンツのセットを保存する責任を負う。その様に、グループの各ＶｏＤクライアントには、保存すべきコンテンツの判定に使用すべき規則セットが提供され、グループの要求条件を確認することができる。ＶｏＤクライアントは、その後、これらの規則に従い、このコンテンツを保存すべきかを判定するために、メタデータを評価することができる。グループのクライアントが、グループの要求条件に適合するコンテンツのみを保存する、このＶｏＤクライアント・グループ構成は、Ｐ２Ｐネットワークを形成するクライアントに亘るコンテンツの複製制御機構を提供する。

Ｆ３．ＶｏＤクライアント１が、このコンテンツの保存を意図するが、十分なメモリを持たなければ、ＶｏＤクライアント１は、以前に保存したどのコンテンツを削除すべきかを決定する。この決定は、以前に保存したコンテンツのメタデータで提供される情報を考慮し、ＶｏＤクライアントにプログラムされているロジックを使用して行うことができる。ＶｏＤクライアント１は、その後、特定したコンテンツを削除し、新たに受信したコンテンツを保存する。

Ｆ４．ＶｏＤクライアント１は、その後、クライアントがコンテンツの一部を現在有することを示す報告を、クライアントがそのコンテンツを保存する期間の様な、任意の他の関連する情報と共に、トラッカ３に送信する。以前に保存したコンテンツを削除した場合、ＶｏＤクライアント１は、この詳細もトラッカに報告する。

あるいは、ＶｏＤクライアントは、十分なメモリ容量が無くなるまで、ＶｏＤサーバから受信する総てのコンテンツの保存を試みるかもしれず、十分なメモリが無くなった場合、ＶｏＤクライアントは、コンテンツの保存が必要かを判定し、必要であれば、削除できる以前に保存したコンテンツを判定する。

図７は、コンテンツ項目と共に受信する保存命令をアクティブに実行する場合に、ＶｏＤクライアントが実行する処理例を示すフロー図である。実行するステップは以下の通りである。

Ｇ１．ＶｏＤクライアント１は、幾つかのコンテンツ及び関連するメタデータを受信する。

Ｇ２．ＶｏＤクライアント１は、その後、メタデータがこのコンテンツを保存すべきことを指示するか否かを判定する。これは、ＶｏＤクライアントの規則セットによるメタデータの評価を含み得る。

Ｇ３．このコンテンツの保存を必要でないと判定すると、その後、ＶｏＤクライアント１は、任意の必要な処理を継続するが、コンテンツは保存しない。

Ｇ４．このコンテンツの保存を必要と判定すると、その後、ＶｏＤクライアント１は、利用可能な十分な保存容量を有するか否かを判定する。ＶｏＤクライアント１が十分な保存容量を有すれば、処理はステップＧ７に進む。

Ｇ５．ＶｏＤクライアント１が、利用可能な十分な保存容量を持たなければ、その後、十分な保存容量を空けるために、以前に保存したコンテンツのどれを削除すべきか特定する。

Ｇ６．ＶｏＤクライアント１は、その後、特定したコンテンツを削除する。

Ｇ７．十分な保存容量が利用可能であるか、十分な保存容量を利用可能にしたならば、ＶｏＤクライアント１は、コンテンツを保存し、保存成功をトラッカ３に報告する。ＶｏＤクライアント１は、任意の削除コンテンツの詳細もトラッカ３に報告する。

再度、この処理の代替法として、ＶｏＤクライアントは、十分なメモリ容量が無くなるまで、ＶｏＤサーバから受信する総てのコンテンツの保存を試み、十分なメモリが無くなった場合、ＶｏＤクライアントは、その後、コンテンツの保存が必要かを判定し、必要であれば、削除できる以前に保存したコンテンツを判定する。

コンテンツにメタデータを含めることは、特定のＶｏＤクライアントが、受信するコンテンツを保存しなければならないか否かを、ヘッド・エンドのＶｏＤサーバが指定することを可能にする。典型的なシナリオでは、コンテンツのメタデータに優先度フラグを含めることで実行できる。イネイブルされている優先度フラグを有するコンテンツをＶｏＤクライアントが受信すると、ＶｏＤクライアントは、例えば、クライアントの現在の保存容量が一杯であれば、既存コンテンツを削除することにより、このコンテンツの保存に努力しなければならない。以前に保存したどのコンテンツを削除すべきかについての決定は、以前保存したコンテンツと共に受信したメタデータで提供される他の情報と組み合わせて、幾つかのプログラムされたロジックに基づきＶｏＤクライアントが行う。

問題の第３の代替解決策として、ＶｏＤクライアントにおけるコンテンツの保存は、クライアントとアクティブ・トラッカ間の協働によりを制御され得る。図８は、コンテンツ保存の制御のために、トラッカと協働するＶｏＤクライアントの簡略化した信号フロー例を示している。実行するステップは以下の通りである。

Ｈ１．ＶｏＤクライアント１は、マルチキャストのプッシュ／プル・イベントによりヘッド・エンドのＶｏＤサーバ２からコンテンツを受信する。ヘッド・エンドのＶｏＤサーバ２は、コンテンツにメタデータを含め、このメタデータは、コンテンツを保存すべきクライアントを表示する。受信メタデータは、コンテンツをクライアント・デバイスの一時的又は永久保存セグメントのいずれに保存すべきか、保存期間又はコンテンツの優先度等の、他の要求条件も表示することができる。

Ｈ２．ＶｏＤクライアント１は、コンテンツがクライアントでの保存を意図されているかを判定する。これは、ＶｏＤクライアントの規則セットによるメタデータの評価を含むであろう。

Ｈ３．ＶｏＤクライアント１は、コンテンツの受信をアクティブ・トラッカ３に報告する。

Ｈ４．ＶｏＤクライアント１はコンテンツの保存を要求されているが、そのために保存スペースを空ける必要があると判定すれば、クライアントのロジック又は規則により、削除する保存済みコンテンツの特定項目を選択できる。この場合、ＶｏＤクライアント１は、その後、選択したコンテンツの削除の許可を求めるメッセージをアクティブ・トラッカ３に送信する。

Ｈ５．運用会社の要求条件及び総ての他のクライアントに亘るＶｏＤクライアント１が選択したコンテンツの利用可能性に応じて、アクティブ・トラッカ３は、選択されたコンテンツの削除をクライアントに許可するか否かを判定し、判定に応じてクライアントに命令する。アクティブ・トラッカ３がＶｏＤクライアント１は選択コンテンツを削除すべきでないと判定すれば、アクティブ・トラッカ３は、クライアントが既に保存しているコンテンツに関するその知見を使用して、削除できるコンテンツを判定することができる。この場合、これらの命令は、ＶｏＤクライアント１にも返送される。

Ｈ６．クライアントは、アクティブ・トラッカ３の命令を確認する。アクティブ・トラッカ３が、クライアントにより選択されたコンテンツの削除許可要求を拒否し、削除できるコンテンツに関し何ら命令を発出しなければ、ＶｏＤクライアント１は、代替のコンテンツ項目を選択し、この代替のコンテンツの削除許可を求めるさらなるメッセージをアクティブ・トラッカ３に送信する。この処理は、クライアントが十分なコンテンツの削除を許可されるまで継続し得る。

図９はアクティブ・トラッカと協働し、コンテンツ項目と共に受信する保存命令をアクティブに実行するときの、ＶｏＤクライアントが実行する処理例を示すフロー図である。実行するステップは以下の通りである。

Ｉ１．ＶｏＤクライアント１は、幾つかのコンテンツ及び関連するメタデータを受信する。

Ｉ２．ＶｏＤクライアント１は、その後、メタデータを評価し、メタデータがこのコンテンツを保存すべきことを表示しているか否かを判定する。これは、ＶｏＤクライアントの規則セットによるメタデータの評価を含み得る。

Ｉ３．このコンテンツの保存が必要でないと判定すれば、その後、ＶｏＤクライアント１は、任意のコンテンツに必要な処理を継続するが、コンテンツは保存しない。

Ｉ４．このコンテンツの保存が必要であると判定すれば、その後、ＶｏＤクライアント１は、利用可能な十分な保存容量を有するか否かを判定する。十分な保存容量が利用可能であれば、処理はステップＩ１１に進む。

Ｉ５．ＶｏＤクライアント１が利用可能な十分な保存容量を持たなければ、その後、ＶｏＤクライアント１は、十分な保存容量を空けるために、以前に保存したどのコンテンツを特定する。

Ｉ６．ＶｏＤクライアント１は、その後、特定したコンテンツの削除の許可を求めるメッセージをアクティブ・トラッカ３に送信する。

Ｉ７．ＶｏＤクライアント１は、その後、ＶｏＤクライアントが特定したコンテンツを削除できるか否かを示す命令をアクティブ・トラッカ３から受信する。アクティブ・トラッカ３が、ＶｏＤクライアント１に特定したコンテンツの削除の許可を授与すれば、処理はステップＩ１０に進む。

Ｉ８．アクティブ・トラッカ３が、ＶｏＤクライアント１に特定したコンテンツの削除の許可を授与しなければ、ＶｏＤクライアント１は、アクティブ・トラッカ３からの、削除する代わりのコンテンツを特定する命令があるかを特定する。

Ｉ９．アクティブ・トラッカ３からの命令が、代わりに削除するコンテンツを特定しなければ、ＶｏＤクライアント１は、代わりのコンテンツを特定し、このコンテンツの削除の許可をアクティブ・トラッカ３に再度求める。処理はその後ステップＩ７に戻る。

Ｉ１０．アクティブ・トラッカ３が、ＶｏＤクライアント１が特定したコンテンツの削除の許可を授与するか、アクティブ・トラッカ３の命令が、代わりに削除するコンテンツを特定していれば、ＶｏＤクライアント１は、特定したコンテンツを削除する。

Ｉ１１．十分な保存容量が利用可能であるか、十分な保存容量を利用可能にしていれば、ＶｏＤクライアント１はコンテンツを保存し、保存成功をトラッカ３に報告する。

この処理の代わりに、ＶｏＤクライアントは、十分なメモリ容量が無くなるまで、ＶｏＤサーバから受信する総てのコンテンツの保存を試み、十分なメモリが無くなった場合、ＶｏＤクライアントは、コンテンツ保存の必要性を判定するであろう。コンテンツの保存が必要であれば、ＶｏＤクライアントは、その後、トラッカがＶｏＤクライアントに削除を許可する可能性のある保存済みコンテンツを判定する。

さらなる代替法として、提供されるメタデータは、保存が必要なことの簡単な指示ではなく、保存優先度を指示する。この場合、ＶｏＤクライアントにプログラムされるロジックは、このコンテンツの優先度を判定して、より低い優先度のコンテンツを削除することによりこのコンテンツの保存を必要とするかを判定する。さらに、メタデータは、それぞれが、保存期間又は有効日時に関連すする複数の優先度を含むことができ、コンテンツ項目の優先度は、例えばコンテンツの年数に応じて変化し得る。

上記方法は、データ配信サービスの運用会社に、クライアントが形成するＰ２Ｐネットワークでのデータ配信を制御し、それにより提供するＰ２Ｐ配信機構及び利点を使用する効果的なサービスを提供する。これらの方法は、データが、運用会社の要求条件及びサービスのユーザによるデータ要求の両方に十分に適合する様に利用可能であり、データ保存を複数クライアントに亘り制御できる様な柔軟性をも提供することを保証する。

図１０は、上記方法を実行することができるデータ配信システム例を概略的に示している。本システムは、複数のピア／クライアント１と、１つ以上のデータ・サーバ２と、１つ以上のトラッカ３と、を備えている。

ピア１は、上記方法の実行に適している。ピア１は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実行することができる。ピア１は、データを保存するメモリ・ユニット４と、１つ以上のデータ・サーバから新しいデータを受信し、トラッカからメッセージを受信する受信機５と、トラッカにメッセージを送信する送信機６と、プロセッサ・ユニット７と、を備えている。データ・サーバから受信するデータは、メタデータも含むことができる。プロセッサ・ユニット７は、上述した解決策の幾つか又は総ての実行に適している。

プロセッサ・ユニット７は、新たなデータの保存に十分なメモリが利用可能であるかを判定し、十分なメモリが利用可能であれば、新たなデータの保存を実行し、新たなデータの保存が成功したことをトラッカ３に報告するメッセージを生成し得る。十分なメモリが利用可能でない場合、トラッカの命令を含むメッセージを受信すると、プロセッサ・ユニット７は、トラッカ３の命令に従い、保存済データの削除を実行し、保存済データの削除をトラッカ３に報告するメッセージを生成し得る。

あるいは、プロセッサ・ユニット７は、任意の受信データに含まれる任意のメタデータを評価し、このデータのピア１での保存が意図されているかを判定することができる。新たなデータの保存が意図されていれば、その後、プロセッサ・ユニット７は、新たなデータを保存するために、十分なメモリを利用可能であるかを判定することができる。十分なメモリを利用可能であれば、プロセッサ・ユニット７は、新たなデータの保存を実行し、新たなデータの保存をトラッカ３に報告するメッセージを生成することができる。

十分なメモリを利用可能でなければ、プロセッサ・ユニット７は、削除できる保存済データを選択し、選択したデータの削除を実行し、新たなデータの保存を実行し、新たなデータの保存をトラッカ３に報告するメッセージを生成することができる。あるいは、十分なメモリを利用可能でなければ、プロセッサ・ユニット７は、削除できる保存済データを選択し、選択したデータの削除の許可を求めるトラッカ３へのメッセージを生成することができる。

トラッカ３の応答を受信し、トラッカ３の応答が許可を与えるものであれば、プロセッサ・ユニット７は、選択したデータの削除を実行し、新たなデータの保存を実行し、新たなデータの保存をトラッカ３に報告するメッセージを生成することができる。トラッカ３の応答が許可を与えるものでなければ、プロセッサ・ユニット７は、代わりに削除できる保存済データを特定しているかを判定することができる。

トラッカ３の応答が、代わりの保存済データを特定していれば、プロセッサ・ユニット７は、代わりの保存済データの削除を実行し、新たなデータの保存を実行し、新たなデータの保存をトラッカ３に報告するメッセージを生成することができる。トラッカ３の応答が、代わりの保存済データを特定していなければ、プロセッサ・ユニット７は、代わりに削除できる保存済データを選択し、代わりの保存済データの削除の許可を求めるトラッカ３へのメッセージを生成することができる。

データ・サーバ２は、上記方法の実行に適している。データ・サーバ２は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実行することができる。データ・サーバ２は、データを保存するメモリ・ユニット８と、メタデータを含むデータを１つ以上のピアに送信する送信機９と、を備えている。データ・サーバ２は、データに含めるメタデータを生成するプロセッサ・ユニット１０を含むことができ、メタデータは、ピアがデータ保存の意図を判定するために、ピアにより評価され得る。データ・サーバ２は、トラッカ３からの命令を受信する受信機１１も含むことができる。

トラッカ３は、上記方法の実行に適している。トラッカ３は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実行することができる。トラッカ３は、ピアからメッセージを受信する受信機１２と、ピアにメッセージを送信し、データ・サーバにメッセージを送信する送信機１３と、ピアが保存する総てのコンテンツのレコードを維持するメモリ・ユニット１４と、プロセッサ・ユニット１５と、を備えている。プロセッサ・ユニット１５は、上述した解決策の幾つか又は総ての実行に適している。

プロセッサ・ユニット１５は、ピア１から新たなデータの保存成功を報告する最小数のメッセージを、トラッカが受信したかを判定することができ、受信していなければ、保存の成功を報告しないピアから削除できる保存済データを選択し、選択したデータの削除を関係するピアに命令するメッセージを生成し、選択したデータの削除の確認を受信すると、１つ以上のデータ・サーバに、関係するピアへの新たなデータの再送信を命令するメッセージを生成することができる。

あるいは、プロセッサ・ユニット１５は、ピア１から、選択された幾つかのデータの削除許可の要求を受信すると、保存データのレコードを使用して、選択されたデータを削除できるかを判定し、選択されたデータの削除許可を与えるか否かを示す、要求ピアへのメッセージを生成することができる。選択されたデータは削除できないと判定すれば、プロセッサ・ユニット１５は、保存データのレコードを使用して削除できる代わりのデータを特定し、選択されたデータの削除許可を拒否することを示し、代わりのデータを特定する、要求ピアへのメッセージを生成することができる。

本発明の範囲を逸脱することなく上記実施形態には種々の修正を行うことができることは当業者により理解されよう。例えば、本発明をビデオ・オン・デマンド・サービスに関して説明したが、あらゆるデータの配信に等しく本発明を使用することができよう。加えて上述した通り、トラッカ機能はヘッド・エンド・システムに集中させることも、分離して配置することも、ＤＨＴの様な分散システムをベースにすることもできる。さらに、単一トラッカの使用ではなく、複数のトラッカを使用して論理的に単一であるトラッカを形成し、トラッカ機能をネットワークに比例する規模にすることを可能にする様に、トラッカ機能を実装することができる。

Claims (7)

1. ピア・ツー・ピア・ネットワークのピアが他のピアにデータを提供することを可能にするために、ピアにデータを配信する方法であって、
   １つ以上のデータ・サーバから、複数のデータ受信ピアにデータ項目を送信するステップと、
   前記データ項目を保存するために利用可能な十分な保存容量を有するデータ受信ピアの数が、事前に規定した最小数未満であるかを判定するステップと、
   前記最小数未満であれば、十分な保存容量を利用可能にするために、保存済データを削除するステップと、
   を含み、
   前記データ項目を保存するために利用可能な十分な保存容量を有するデータ受信ピアの数が、事前に規定した最小数未満であるかを判定する前記ステップは、
   各データ受信ピアで、十分な保存容量を利用可能であれば、前記データ項目を保存して、前記データ項目の保存をトラッカに報告するステップと、
   前記トラッカにおいて、前記ピアが保存しているデータのレコードを維持し、前記データ項目が、前記事前に規定された最小数のピアで保存されているかを判定するステップと、
   を含み、
   十分な保存容量を利用可能にするために、保存済データを削除する前記ステップは、
   前記トラッカにおいて、前記データ項目を保存していないデータ受信ピアを特定し、該データ受信ピアから削除できる保存済データを特定するために、前記ピアが保存しているデータの前記レコードを使用し、前記特定した保存済データを削除するために、前記データ項目を保存していないデータ受信ピアに命令を送信するステップと、
   前記データ項目を保存していないデータ受信ピアにおいて、前記トラッカからの命令を受信すると、前記特定した保存済データを削除するステップと、
   を含むことを特徴とする方法。
2. 前記データ項目を保存していないデータ受信ピアにおいて、前記保存済データの削除の後に、前記保存済データの削除を前記トラッカに報告するステップと、
   前記トラッカにおいて、前記保存済データを削除したことの報告を受信し、前記ピアが保存しているデータの前記レコードを更新し、前記データ項目を保存していないデータ受信ピアに前記データ項目を再送信させる命令を前記データ・サーバに送信するステップと、
   前記データ・サーバにおいて、前記データ項目を保存していないデータ受信ピアに前記データ項目を再送信するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
3. ピア・ツー・ピア・ネットワークのトラッカを動作させる方法であって、
   ピアが保存したデータ項目の報告を前記ピアから受信するステップと、
   前記ピアが保存しているデータのレコードを維持するステップと、
   前記データ項目が、事前に規定した最小数のピアで保存されているかを判定するステップと、
   保存されていなければ、前記データ項目を保存していないピアを特定し、前記データ項目を保存していないピアから削除できる保存済データを特定し、前記特定した保存済データの削除を、前記データ項目を保存していない１つ以上のピアに命令するステップと、
   を含むことを特徴とする方法。
4. 前記保存済データの削除の確認を受信すると、前記ピアが保存しているデータの前記レコードを更新し、前記保存済データの削除を行ったピアへの前記データ項目の再送信を、１つ以上のデータ配信サーバに命令するステップをさらに含む、
   ことを特徴とする請求項３に記載の方法。
5. 前記データ項目はビデオであり、前記ピアは、ビデオ・オン・デマンド・システムにおけるクライアントである、
   ことを特徴とする請求項１から４のいずれか１項に記載の方法。
6. ピア・ツー・ピア・ネットワークにおけるトラッカとして動作する様に構成された装置であって、
   ピアからメッセージを受信する受信機と、
   前記ピアにメッセージを送信する送信機と、
   データ・サーバにメッセージを送信する送信機と、
   前記ピアが保存しているデータのレコードを維持するメモリ・ユニットと、
   プロセッサ・ユニットと、
   を備えており、
   前記プロセッサ・ユニットは、データ項目の保存を報告するピアから、事前に規定した最小数のメッセージを、前記トラッカが受信したかを判定し、受信していなければ、削除できる保存済データを選択し、前記データ項目を保存していない１つ以上のピアに、前記保存済データの削除を命令するメッセージを生成し、前記保存済データの削除確認を受信すると、前記保存済データの削除が確認されたピアへの前記データ項目の再送信を１つ以上のデータ・サーバに命令するメッセージを生成する、
   ことを特徴とする装置。
7. 前記データ項目は、ビデオであり、前記ピアは、ビデオ・オン・デマンド・システムにおけるクライアントである、
   ことを特徴とする請求項６に記載の装置。

Images