(57)【要約】受信ピアとして機能するビデオ・オン・デマンド・ピアツーピア・デバイスが、ビデオ・プレフィックスを記憶するよう適応されたローカル・キャッシュ・メモリ・デバイスを含む。ビデオ・プレフィックスのローカルな記憶は、関連するサーバー・デバイスのストリーミング容量に実質的に負担をかけることなく、要求されたビデオ・プログラムの再生の迅速な開始を許容する。受信ピア・デバイスのローカル・キャッシュ・メモリ中のビデオ・プレフィックスの記憶は、比較的低いネットワーク負荷の期間中に行われることができ、それによりネットワークおよびサーバーのスケジューリングが最適化される。ピアツーピア・ビデオ・オン・デマンド・システムにおいて受付制御を実行する方法および装置が含まれる。受付許可制御システムは、クライアントとして機能するピアツーピア・デバイスからの新たな要求をサポートするために十分なシステム容量があるかどうかを、他の要因のうちでも、受信ピア・デバイスとして機能するピアツーピア・デバイスにおける事前記憶されたビデオ・プレフィックスの存在に鑑みて、判定する。
2010517365.tif 000002
【特許請求の範囲】
【請求項１】
デジタル・ビデオ・ピアツーピア・デバイスであって：
当該ビデオ・ピアツーピア・デバイスにおいて、受付許可信号の受信に先立ってビデオ・プレフィックスを事前に記憶するよう適応されたローカル・キャッシュ・メモリ・デバイスと；
前記受付許可信号を受信し、応答して前記ビデオ・プレフィックスの再生を開始し、その後、前記ビデオ・プレフィックスに関係したビデオ番組データを受信するよう適応されたコントローラ・デバイスとを有する、
デジタル・ビデオ・ピアツーピア・デバイス。
【請求項２】
前記ローカル・キャッシュ・メモリ・デバイスが、サーバー・デバイス上に記憶された複数のビデオ番組にそれぞれ対応する複数のビデオ・プレフィックスのうちの一つであるビデオ・プレフィックスを含んでいる、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項３】
前記ローカル・キャッシュ・メモリ・デバイスが、前記ビデオ・プレフィックスを事前に記憶することを、低ネットワーク使用の期間中に行うよう適応されている、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項４】
前記ローカル・キャッシュ・メモリ・デバイスが電気機械式ディスク・ドライブ・デバイスを含む、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項５】
前記ローカル・キャッシュ・メモリ・デバイスが半導体メモリ・デバイスを含む、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項６】
前記デジタル・ビデオ・ピアツーピア・デバイスが第一のピアツーピア・デバイスであり、前記第一のピアツーピア・デバイスがサービス・ピア・デバイスとして機能するよう適応されており、前記コントローラ・デバイスが前記ビデオ・プレフィックスを通信ネットワークを通じて、受信ピア・デバイスとして機能するよう適応された第二のピアツーピア・デバイスに送信するよう適応されている、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項７】
前記ビデオ・プレフィックスが低ネットワーク使用の期間中に送信される、請求項６記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項８】
前記コントローラ・デバイスが、受付許可要求を受付許可制御デバイスに送るよう適応されており、前記受付許可制御デバイスが、前記ビデオ・ピアツーピア・クライアント・デバイスにおける事前キャッシングされたビデオ・プレフィックスの存在または不在を考慮するよう適応されている、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項９】
前記コントローラ・デバイスが、当該ビデオ・ピアツーピア・デバイスにおいてローカルにキャッシングされたビデオ・プレフィックスが利用可能でない場合、ストリーミングされたビデオ・プレフィックスをサーバーから受信するよう適応されている、請求項１記載のデジタル・ビデオ・ピアツーピア・デバイス。
【請求項１０】
ビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法であって：
ビデオ・オン・デマンド・システムに受付許可を要求する段階と；
前記ビデオ・オン・デマンド・システムへの受付許可を受信する段階と；
ローカル・キャッシュに事前記憶されたビデオ・プレフィックスに基づいてビデオ番組の第一の部分の再生を開始する段階と；
その後、前記ビデオ・オン・デマンド・システムの通信ネットワークからさらなるビデオ・サブクリップを受信する段階とを有する、
方法。
【請求項１１】
前記事前記憶されたビデオ・プレフィックスを電気機械式メモリ・デバイスに事前記憶する段階を含む、
請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１２】
前記事前記憶されたビデオ・プレフィックスを半導体メモリ・デバイスに事前記憶する段階を含む、
請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１３】
前記事前記憶されたビデオ・プレフィックスを前記ローカル・キャッシュに、低ネットワーク負荷の時間期間の間に事前記憶する段階を含む、
請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１４】
前記事前記憶されたビデオ・プレフィックスを、サーバー・デバイスからのデジタル・ビデオ・マルチキャスト・データの受信に応答して事前記憶する段階を含む、
請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１５】
サーバーによる前記ローカル・キャッシュに事前記憶されている前記ビデオ・プレフィックスの利用可能性の考慮に基づく前記受付許可を受信することを含む、
請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１６】
前記ビデオ番組の前記さらなるビデオ・サブクリップを再生する段階をさらに含む、請求項１０記載のビデオ・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１７】
マルチメディア・デバイスであって：
ピアツーピア通信のために通信ネットワークに結合されるよう適応されているコントローラ・デバイスと；
前記コントローラ・デバイスに結合された、再生のためにマルチメディア・プレフィックスを記憶するよう適応されたキャッシュ・メモリ・デバイスとを有し、前記再生は前記ネットワークからの前記プレフィックに関係したさらなるマルチメディア・データの受信に先立って始まる、
マルチメディア・デバイス。
【請求項１８】
前記マルチメディア・プレフィックスがオーディオ・プレフィックスを含む、請求項１７記載のマルチメディア・デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピア・ネットワーキングに、より詳細にはビデオ・オン・デマンド（ＶｏＤ）サービスのためのプレフィックス・キャッシングに関する。
【背景技術】
【０００２】
伝統的に、デジタル・ビデオはストリーミング・クライアント‐サーバー・モデルを使って提供されてきた。クライアントの受付許可要求〔アドミッション要求〕（ａｄｍｉｓｓｉｏｎ  ｒｅｑｕｅｓｔ）がサーバーで受信されるとき、サーバーは該サーバーがそのクライアントの要求にサービスするために十分なリソースをもつかどうか、およびサーバーとクライアントとの間の経路に沿って要求されたビデオの受け容れ可能な通信を許容するのに十分なバンド幅があるかどうかを確かめる。
【０００３】
サーバーにおける限られた計算および記憶リソースのため、およびサーバーとクライアントを接続するネットワークにおける限られたバンド幅のため、クライアント‐サーバー・ストリーミング・サービスのスケーラビリティは限られている。純粋にストリーミングするサービスに比較してパフォーマンスを改善するために、ピアツーピア技術が使用されてきた。
【０００４】
ピアツーピア・サービスでは、ピア・デバイスがクライアント式の機能とサーバー式の機能の両方を実装される。これは、サービスするピア・デバイスがサーバー・デバイスとして機能して、受信するピアがサービス・ピア・デバイスからコンテンツを受信することを許容する。任意の所与の時点においては、ピア・デバイスは、システムの現時点での要求に依存して受信ピア（ｒｅｃｅｉｖｉｎｇ  ｐｅｅｒ）および／またはサービス・ピア（ｓｅｒｖｉｎｇ  ｐｅｅｒ）として機能しうることは理解される。これは、サービス・ピアが必要なビデオ・データおよびＩ／Ｏ機能を有しており、サービス・ピアと受信ピアとの間で十分なネットワーク・バンド幅が利用可能である状況下で可能である。こうして、サービス品質を意識する（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  ａｗａｒｅ）ピアツーピアのビデオ・オン・デマンド・サービス（ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ  ｓｅｒｖｉｃｅ）は、伝統的なクライアント‐サーバー・サービス・モデルから得られるものに匹敵する閲覧品質を提供しつつ、サービス・ピアの上りリンク・バンド幅を利用することによってシステム容量を改善する。その間、サーバーは緊急のデータ要求にサービスするために利用可能であり続ける。
【０００５】
関連アプリケーションにおいて記載されるように、サーバーによってサービスされる一つの緊急データ要求は、受信ピアにおける即時の再生のためにビデオ番組データの先頭サブクリップ（ｌｅａｄｉｎｇ  ｓｕｂ  ｃｌｉｐ）をストリームする必要性である。これは、受信ピアがそうでなければ受付許可後に経験するであろう呈示の開始に対する遅延を軽減する。先頭サブクリップのストリーミングは、サーバー上でのかなりの負荷を表すことがあり、システム・スケーラビリティに悪影響を与えうる。実際、サーバーは、受付許可要求のレートが増すにつれて、急速に飽和されうる。その結果、追加的な受信ピア・デバイスが受け容れられなくなる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ピアツーピア・ライブ・ストリーミングにおいて、システム機能を犠牲にすることなくスタートアップ遅延を最小にすることは難しい。ピアツーピアのビデオ・オン・デマンド・サービスでは、不相応なスタートアップ遅延なしに非同期ユーザーがビデオ・データを共有することを許容することは、いまだ課題である。
【課題を解決するための手段】
【０００７】
本発明のある実施形態に基づくビデオ受信ピア・デバイスは、ビデオ・サーバーおよびサービス・ピア・デバイスの一つまたは複数から、同時並行のまたはその後の表示のためにビデオ信号を受信するよう適応される。ビデオ受信ピア・デバイスは、先頭サブクリップ（ビデオ・プレフィックスとしても知られる）を記憶するよう適応されたメモリ部分を含む。記憶されたプレフィックスは、ビデオ表示の迅速な開始および改善された受付許可パフォーマンスを許容する。
【０００８】
関係する諸アプリケーションは、パフォーマンス意識のあるピアツーピアのビデオ・オン・デマンド・サービスに、およびそのようなサービスのための受付許可制御に向けられる。これらのアプリケーションは、ピアツーピア・ダウンロードを伝統的なクライアント‐サーバー・ビデオ・オン・デマンド・サービス・モデルに組み込む。さまざまな実施形態において、ピアツーピア・ダウンロードが主要なデータ転送負荷を担い、サーバーに課される負荷を著しく軽減する。
【０００９】
ビデオ・オン・デマンド・サービスは、ユーザーが、ユーザーによって選択された時点において、ネットワーク上のビデオ・コンテンツを選択および視聴することを許容する。関係するアプリケーションは、ビデオ・オン・デマンドのセッティングにおいてコンテンツ共有を可能にするセグメント化されたピアツーピア・ビデオ共有モデルを含む。パフォーマンス問題は、パフォーマンスを意識するピアツーピア・データ・ダウンロード・アルゴリズムとサーバー支援された補足的ストリーミングとを組み込むことによって対処される。これらがまとまって、伝統的なクライアント‐サーバー・サービス・モデルによって提供されるパフォーマンスと同様の、だがより多くのユーザーをサポートするパフォーマンスを実現する。このシステムでは、サーバーはそのリソースの大半を、パフォーマンス要求を満たすための緊急データを提供することと、受信ピアがシステムに受付許可された後に受信ピアにビデオ・プレフィックスをストリーミングすることとに割く。しかしながら、先頭サブクリップを受信ピアにストリーミングすることへのサーバーの関与は、サーバー・バンド幅を消費し、受付許可できる受信ピアの数を制限する。
【００１０】
各受信ピアが一つまたは複数のビデオ番組のビデオ・プレフィックスをキャッシングすることを許容することによって、驚くべきパフォーマンス改善が与えられる。さまざまな実施形態において、そのようなプレフィックスの完全なセットがローカルにキャッシュされ、先頭サブクリップのストリーミングを完全に回避することを可能にする。これはシステム・スケーラビリティを著しく改善する。より一般には、受信ピア端における知覚されるパフォーマンスが改善される。本発明のピアツーピア・ダウンロード・アルゴリズムは、キャッシングされるビデオ・プレフィックスが利用可能であることを念頭に設計される。本発明は、先頭サブクリップのストリーミングをタイムシフトする、削減するまたはなくすことによって、受信ピアの知覚されるビデオ品質をさらに改善することに向けられる。本発明のさまざまな実施形態によれば、サーバーは実行すべきいくつかのタスクまたはサービスをもつ。それには、補足的ストリーミングを実行することおよびピアツーピア・ネットワーク内の受信ピアにコンテンツをアップロードすることが含まれる。本発明の諸実施形態によれば、ビデオ・プレフィックスは、サーバーから受信ピアのキャッシュ・メモリに、ネットワークおよび／またはサーバー需要が低い期間の間に送信される。サーバーにおける限られたバンド幅資源およびさまざまなサービスを提供しさまざまなタスクを実行するサーバーの責任のため、受信ピアの知覚されるビデオ品質がユーザーの期待を満たすよう受付許可制御（ａｄｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ）を実施することが重要である。キャッシングされたプレフィックスが利用可能であるとき、追加的なビデオ・オン・デマンド受信ピアをシステムに入れることを許容するために受付許可制御パラメータが選択されることができる。
【００１１】
本発明では、ピアツーピアのビデオ・オン・デマンド・サービスのための受付許可制御をサポートする方法および装置が、キャッシングされたビデオ・プレフィックスが利用可能であるまたは利用可能でありうるパフォーマンスを意識するビデオ・オン・デマンド・サービス環境におけるユーザーの知覚されるビデオ品質を改善するよう設計される。本発明の方法および装置は、現在のバンド幅使用およびバンド幅使用履歴をモニタリングし、要求がビデオ・オン・デマンド・システムに受付許可されることができるかどうかを判定するために、ビデオ・プレフィックスの利用可能性を考慮する。
【００１２】
したがって、ピアツーピアのビデオ・オン・デマンド・システムにおいて受付許可制御を実行するための方法および装置であって、必要なビデオ・プレフィックスがローカルにキャッシングされているビデオ再生デバイスからの新たな要求をサポートするのに十分なバンド幅があるかどうかを判定し、前記要求を既存の要求に対するサービス品質を犠牲にすることなく受付許可するのに十分なバンド幅があるかどうかを判定し、両方の判定する動作が肯定的である場合には前記新たな要求の受付許可を受け容れ、前記判定する動作のいずれかが否定的である場合には前記新たな要求の受付許可を拒否することを含むものが記載される。また、受付許可制御ユニットおよびデータ・エンジン・コンポーネントを含むピアツーピアのビデオ・オン・デマンド・システムにおけるビデオ再生デバイスにコンテンツを提供する装置も記載される。
【００１３】
本発明のある実施形態によれば、あらかじめ記憶されたビデオ・プレフィックスが利用可能であることにより、サーバー・バンド幅をストリーミング再生のために割り当てることなく、要求されたビデオ再生の実質的に即時の開始が許容される。ビデオ・プレフィックスをローカルなキャッシュ・メモリに事前記憶することによって、ユーザー要求と対応する再生開始との間の遅延が、ビデオ・プレフィックスのストリーミングされる再生に関連するサーバーおよびバンド幅コストを被ることなく、短縮されるか実質的に解消される。
【００１４】
ある実施形態では、ローカルなキャッシュ・メモリは磁気ディスク・ドライブを含む。別の実施形態では、ローカルなキャッシュ・メモリは光ディスク・ドライブを含む。本発明のさらにもう一つの実施形態では、ローカルなキャッシュ・メモリは動的ＲＡＭメモリ、静的ＲＡＭメモリ、フラッシュ・メモリ、プログラム可能な読み出し専用メモリまたは他のメモリ記憶デバイスの一つまたは複数を含む。
【００１５】
ビデオ再生デバイスは、これに限られないが、コンピュータ、ラップトップ、携帯情報端末（ＰＤＡ）およびモバイル・デバイスを含むビデオ（記憶されたビデオまたはライブ・ビデオ）を受信および再生する機能のある任意のデバイスであることを注意しておくべきである。ピアツーピア・ネットワークは有線ネットワークに限定されるものではなく、無線ネットワークでも有線ネットワークでもよく、あるいは有線および無線接続の両方を用いるハイブリッド・ネットワークでもよい。
【００１６】
ローカルにキャッシュされたビデオ・プレフィックスを用意することは、ビデオ・オン・デマンド・サーバーの負担を著しく軽減し、スケーラビリティおよびサービス品質の改善を許容する。さらに、時間的なネットワーク負荷に変動があるので、ネットワーク負荷が比較的低い期間の間にサーバーからローカル・クライアント・キャッシュへの先頭サブクリップの転送を行うことが許容される。
【００１７】
本発明のある実施形態によれば、ピアツーピア・ネットワーク・サーバーは、三つの型のサービスを受け持つ：（ｉ）事前キャッシングのためのビデオ・プレフィックスを受信ピア・メモリ・デバイスにアップロードする（この事前キャッシングが受信ピアがすぐ再生を開始することを可能にする）、（ｉｉ）その後のサブクリップのビデオ・コンテンツを、サーバーにより、ピアツーピア・ネットワークを通じて受信ピアにアップロードする、（ｉｉｉ）あるサブクリップ中に欠けているデータがあり、そのサブクリップの締め切りに達しているとき、受信ピアにサブクリップの補足的ストリーミングをサービスする。
【００１８】
本発明は、以下の詳細な説明を付属の図面との関連で読んだときに最もよく理解される。図面は、下記で簡単に説明される以下の図を含む。複数の図における似たような番号は同様の要素を表す。
【図面の簡単な説明】
【００１９】
【図１】本発明のある実施形態に基づくビデオ・オン・デマンド・システムの一部を示す図である。
【図２】本発明のある実施形態に基づくビデオ・オン・デマンド・システムのさらなる一部を示す図である。
【図３】本発明のある実施形態に基づくサーバー・デバイスのためのサーバー・アーキテクチャを示す図である。
【図４】本発明のある実施形態に基づく動作方法を流れ図の形で示す図である。
【図５】本発明のある実施形態に基づくビデオ・オン・デマンド・システムのための受付許可比のグラフ表現を示す図である。
【図６】本発明のある実施形態に基づくビデオ・オン・デマンド・システムのための平均ミス比のグラフ表現を示す図である。
【図７】本発明のある実施形態に基づくサーバー側のバンド幅要求のグラフ図解を示す図である。
【発明を実施するための形態】
【００２０】
以下の記述は、ピアツーピア・ビデオ・オン・デマンド・システムを用いた本発明を呈示する。しかしながら、当業者は、好ましい実施形態を含む呈示される実施形態が本発明を例示するものであって、限定することは意図されていないことを認識するであろう。したがって、本発明は、たとえばピアツーピア・オーディオ・オン・デマンド・システムおよび他のマルチメディア・システムを含む多様な実施形態において適用されてもよいことは理解される。
【００２１】
本発明は、上で論じた欠点を克服する。部分的には、本発明は、先頭マルチメディア・サブクリップ（オーディオおよび／またはビデオ先頭サブクリップのような）を、サービス要求に先立って、ピアツーピア・システムの受信ピア・デバイス（ピアツーピア・クライアント・デバイス）において記憶することによってシステム・パフォーマンスを驚くほど改善する。この先行のため、ビデオ・オン・デマンド・サービスの要求は、すぐ、即時の増分的な（ｉｎｃｒｅｍｅｎｔａｌ）サーバー負荷がほとんどあるいは全くなしに、受け容れられることができる。さらに、先頭サブクリップの記憶は先頭サブクリップの再生に先立ついかなる時点で行われることもできるので、先頭データ転送のタイムシフトにより、ネットワーク負荷スケジュールの最適化が許容できる。
【００２２】
インターネット上のビデオ・コンテンツに対する需要は、ピーク時における要求レートがトラフィック・ボリュームが最低の時の要求レートより数十、あるいは数百のオーダー大きいことがありうる時間的パターンをもつ。この種のトラフィック・パターンは、サーバーが、ネットワーク・トラフィックが軽いときにビデオ・プレフィックスをピアツーピア受信ピア（たとえばセットトップボックスのような）にプッシュすることを許容する。たとえば、サーバーは、メディア・ライブラリ中の各ビデオのプレフィックスを諸セットトップボックスに、ビデオ・コンテンツを要求するクライアントがあまりない平日の昼間にプッシュできる。さらに、当業者は今や、セットトップボックスのコストを有意に上げることなく、セットトップボックスのような受信ピア上に数百もの映画の短いプレフィックスを保持することが可能であることを認識するであろう。今やボトルネックとなる傾向があるのはネットワーク・バンド幅である。
【００２３】
以上の利益はなかでも、受信ピア・デバイスにおけるビデオ・プレフィックスの記憶のための受信ピア記憶デバイスを含むビデオ・オン・デマンド・システムにおいて見出される。記憶デバイスは、受信ピア要求の受付許可後、ビデオ・プレフィックスへの迅速なアクセスを許容する。このようにして、受信ピア・デバイスは、たとえば専用のサーバー・デバイスからあるいはサービス・ピア・デバイスからのストリーミングによるビデオ・プレフィクスの送達を待つことなく、要求されたビデオ番組をユーザーに呈示することを開始できる。このビデオ・プレフィクスのキャッシングは、たとえばサービス品質を意識する受付許可制御機能をもつシステムのようなビデオ・オン・デマンド・システムにおいて有利である。
【００２４】
図１は、本発明の例示的な実施形態に基づくデジタル・ビデオ・オン・デマンド・システム１００の一部を示している。システム１００は、サーバー・デバイス１０２およびピア・デバイス１０４を含む。図示した実施形態では、サーバー・デバイス１０２はサーバー制御部１０６およびサーバー記憶部１０８を含む。サーバー記憶部は、たとえばデジタル・ビデオ番組データといったデータを取り出し可能な形で記憶するよう適応される。一般に、複数のビデオ番組、たとえば１０７、１０９がサーバー記憶部１０８に記憶される。
【００２５】
ピア・デバイス１０４は、ピア・デバイス制御部１１２およびピア・デバイス記憶部１１４を含む。図示した実施形態では、ピア・デバイス制御部１１２は通信部１１６および再生部１１８を含む。当業者は、本願に開示される本発明の範囲内でさまざまな他の構成が可能であることを認識するであろう。
【００２６】
通信部１１６はビデオ番組データを受信し、そのデータをピア・デバイス記憶部１１４に記憶するよう適応されている。再生部１１８は、ピア・デバイス記憶部１１４から記憶されたデータの少なくとも一部分を取り出し、たとえばユーザーによって要求されたときにビデオ番組表示を生成するよう適応されている。のちにさらに詳細に述べるように、ピア・デバイス記憶部は、ユーザーが要求しうる個別のビデオ番組に対応する一つまたは複数の先頭サブクリップ１２０、１２２を記憶するよう適応される。
【００２７】
さまざまな実施形態において、サーバー記憶部１０８および／またはピア・デバイス記憶部１１４は磁気ハードディスク・ドライブとして実装される。当業者は、記憶デバイスとしてのディスク・ドライブの選択は数多くの可能な選択のうちの一つを表していることを認識するであろう。本発明の代替的な実施形態は、各種代替のうちでも、ピア記憶デバイスがフラッシュ・メモリ、消去可能なプログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、動的ランダム・アクセス・メモリ（ＤＲＡＭ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、磁気ＲＡＭ（ＭＲＡＭ）および相変化ランダム・アクセス・メモリ（ＰＲＡＭ）として実装されるピア記憶デバイスを含む。
【００２８】
サーバー・デバイス１０２は、信号伝達的にサーバー制御部１０６をインターネットなどのようなデジタル通信ネットワーク１２６に結合するよう適応されているサーバー・ネットワーク・インターフェース・デバイス１２４を含む。ピア・デバイス１０４も、信号伝達的にクライアント制御部１１２をデジタル通信ネットワーク１２６に結合するよう適応されているクライアント・ネットワーク・インターフェース・デバイス１２８を含む。このようにして、たとえばユーザー・コマンドに応答して、ピア・デバイス１０４は受付許可要求をサーバー・デバイス１０２に信号伝達でき、サーバー・デバイス１０２は受付許可信号、それに続いてビデオ番組データをピア・デバイス１０４（今や受信ピア・デバイス）に伝達できる。
【００２９】
図２は、より広いシステムのコンテキストにおいて図１の例示的なサーバー・デバイス１０２および受信ピア・デバイス１０４を示している。図のように、複数のさらなるピア・デバイス２１０、２１２がネットワーク１２６に信号伝達的に結合されている。非ピアツーピアの実施形態では、ビデオ・データはサーバー・デバイスから発し、クライアント・デバイスで受信される。ピアツーピア実施形態では、ピア・デバイス、たとえば１０４、２１０、２１２は受信ピア（またはクライアント）機能および送信ピア（またはサーバー）機能の組み合わせをもって実装される。このようにして、システムは、送信ピア・クライアント・デバイスの利用可能なアップロード・バンド幅を、サーバーのアップロード機能を補足するために利用できる。さらに、ネットワーク・バンド幅要求は、ネットワーク１２６のさまざまな部分１２９、１３１にわたって分散されることができる。関係するアプリケーションにおいて記載されるように、この機能は、ビデオ・オン・デマンド・システムの増加したスケーラビリティを許容する。
【００３０】
本発明のある実施形態では、ビデオ・プレフィックス・データ１２０、１２２（図１に示されるような）は、受信ピア・クライアント・デバイスにおいてサーバー・デバイスから直接、受信され、ローカルな記憶デバイス１０８に記憶される。本発明のあるさらなる実施形態では、ビデオ・プレフィックス・データは、クライアント・デバイスにおいてサーバー・デバイスから間接的に、たとえば介在する送信ピア・デバイス、たとえば２１０、２１２によって受信される。本発明のあるさらなる実施形態では、ビデオ・プレフィックス・データ１２０、１２２は、最大ネットワーク負荷に比べてネットワーク負荷が低レベルである比較的低負荷の時間期間の間に、サーバー・デバイスおよび／または介在ピア・デバイスから受信される。
【００３１】
本発明のある実施形態では、ローカルな記憶デバイス、たとえば１１４に記憶されているビデオ・プレフィックスの補足物は、サーバー・デバイス１０２の記憶デバイス１０８に記憶されているビデオ番組、たとえば１０７、１０９のそれぞれについて一つのビデオ・プレフィックスを含む。本発明の別の実施形態では、ローカルな記憶デバイス１１４に記憶されているビデオ・プレフィックスの補足物は、サーバー・デバイス１０２の記憶デバイス１０８に記憶されているビデオ番組のサブセットに対応する複数のビデオ・プレフィックスを含む。ビデオ番組のこのサブセットは、他の選択モードのうちでも、特定のユーザーの能動的な選択、あるいはそのようなユーザーの観察された視聴習癖に基づいて、あるいはより広いユーザー集団、たとえば全ユーザー集団の観察された視聴習癖に基づいて選択されてもよい。
【００３２】
図３は、本発明のある実施形態に基づく、プレフィックス・キャッシングに支援されたパフォーマンスを意識するピアツーピアのストリーミング・サーバーのアーキテクチャをブロック図の形で示している。サーバーは、二つのサブコンポーネントをもつデータ・エンジン・コンポーネントを含む。第一のサブコンポーネントはストリーミング・エンジンである。第二のサブコンポーネントはピアツーピア・ダウンロード器である。データ・エンジンおよびピアツーピア・ダウンロード器は、補足的ストリーミング・サービスおよびピアツーピア・ダウンロード・サービスをそれぞれ提供する。
【００３３】
このサーバーに対して新しい受付許可要求が受信されるとき、その要求は受付許可コントローラに回送される。受付許可コントローラ・プロセスからの結果に基づいて、サーバーは受付許可決定を要求元の受信ピア・デバイスに送り返す。受信ピア・デバイスが受付許可される場合、受付許可制御ユニットはデータ・エンジン・コンポーネントにこの決定を通知する。
【００３４】
肯定的な受付許可の決定を受信すると、受信ピアはすぐにキャッシングされたビデオ・プレフィックスをローカルな記憶から、もし利用可能であれば、再生し始める。もし利用可能なキャッシングされたビデオ・プレフィックスがなければ、ある実施形態によれば、サーバーは必要なプレフィックスを受信ピアにストリーミングする。同時並行して、データ・エンジン・コンポーネントは、ピアツーピア・ネットワークを通じて後続のサブクリップについてのデータのアップロードを開始する。データ優先度需要を満たすために必要であれば、サーバーは後続のサブクリップの補足的ストリーミングをも提供することができる。
【００３５】
図４は、本発明のある実施形態に基づくデジタル・ビデオ・システムの動作方法４００の一部を流れ図の形で示している。第一のステップ４０２において、新しい受信ピア・デバイスがビデオ番組データに対する要求を受付許可コントローラ・デバイスに提出する。要求を受信すると、受付許可コントローラ・デバイスは、新しい受信ピアの受付許可を許容するために（すなわち、そのビデオ番組をその受信ピアに供給するために）十分なリソース（たとえばバンド幅）が利用可能であるかどうかを判断する（４０４）。第一の選択肢では、新たな受信ピアの受付要求のためには不十分なリソースが利用可能であり、新たな受信ピアの受付許可は拒否される（４０６）。この場合、動作方法の図示した部分は終了する（４０８）。第二の選択肢４００では、新たな受信ピアの受付許可のために十分なリソースが利用可能である。その旨の信号が受信ピア・デバイスに送られ、受信ピアが以前にローカル・キャッシュに記憶されたビデオ・プレフィックス・データの再生を開始する（４１２）。その後、受信ピア・デバイスは要求されたビデオ番組のその後のビデオ・セグメントを受信するためにピアツーピア・ネットワークに加わる（４１４）。
【００３６】
本発明のある実施形態では、受信ピア・デバイスは、ローカル・キャッシュからビデオ・プレフィックス・データの再生を開始した後すぐ、第一のその後のビデオ・セグメントを探す。本発明のもう一つの実施形態では、クライアント・デバイスは、前記第一のその後のビデオ・セグメントを探すことを、ローカル再生キャッシュに記憶されているデータの量（すなわち、残り再生時間）がある確立された閾値を下回るまで延期する。
【００３７】
第一のその後のビデオ・セグメントの、およびより後刻のその後の毎ビデオ・セグメントの再生の間に、次のビデオ・セグメントの完全な受信に対する締め切りが設定される。図示した方法のさらなるステップ４１６では、次のビデオ・セグメントが締め切りの満了までに完全に受信された場合（４１８）、次のビデオ・セグメントの再生が始まる（４２０）。そうでない場合（４２２）、そのさらなるビデオ・サブクリップを完成させるための追加的データがサーバーから補足的ストリーミングにより受信される（４２４）。その後、次のビデオ・セグメントの再生が開始される（４２０）。
【００３８】
図示した方法のさらなるステップ４２６は、現在のビデオ・サブクリップがビデオ番組中の最後のビデオ・サブクリップであるかどうかの評価を含む。現在のビデオ・サブジェクトがビデオ番組の最後のビデオ・サブジェクトではない場合（４３０）、受信ピア・デバイスは、次のビデオ・サブクリップを受信するためにピアツーピア・ネットワークに再び加わる（４１４）。現在のビデオ・サブジェクトが現在のビデオ番組の最後のサブクリップである場合、本方法の図示した部分は終了する（４０８）。
【００３９】
さまざまな実施形態によれば、受付許可制御デバイスは、サーバー・デバイスと一体である。受付許可制御デバイスは、サーバーおよび／またはサービス・ピアの組み合わせが要求された番組のビデオ・データを受け容れ可能なサービス品質をもって提供できるかどうかを見きわめる。そのような構成は、サービス品質（ＱｏＳ）を意識する受付許可制御として知られている。
【００４０】
プレフィックス・キャッシングを用いると、パフォーマンスを意識するピアツーピアのストリーミング・サービスにおけるサーバーは、三つの型のサービスを受け持つ：（ｉ）事前キャッシングのためのビデオ・プレフィックスを受信ピア・メモリ・デバイスにアップロードする（この事前キャッシングが受信ピアがすぐ再生を開始することを可能にする）、（ｉｉ）その後のサブクリップのビデオ・コンテンツを、サーバーにより、ピアツーピア・ネットワークを通じて受信ピアにアップロードする、（ｉｉｉ）サブクリップ中に欠けているデータがあり、そのサブクリップの締め切りに達しているとき、受信ピアにサブクリップの補足的ストリーミングをサービスする。
【００４１】
ＢＷを全サーバー・バンド幅を表すのに使う。ＢＷｃｏｍｐ−ｓｔｒｅａｍｉｎｇは補足的ストリーミング（ｃｏｍｐｌｅｍｅｎｔａｒｙ  ｓｔｒｅａｍｉｎｇ）のために使われるバンド幅を表し、ＢＷｐ２ｐｄｏｗｎｌｏａｄｉｎｇはピアツーピア・ダウンロード（ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｄｏｗｎｌｏａｄｉｎｇ）のために使われるバンド幅を表す。重要な記号の定義を表１にまとめておく。
【００４２】
【表１】
2010517365.tif 000003
図５は、Ｃ＝１のときに単一のクライアントにサービスするためのサーバー・バンド幅使用の例を示している。ビデオは四つのサブクリップからなり、時刻Ｔ０に始まる。第一のサブクリップの内容はローカルにキャッシュされており、すぐ再生できる。後続の各サブクリップの締め切り時に、すなわち時刻Ｔ１、Ｔ２およびＴ３に、欠けているデータを埋めるために再生レートで補足的ストリーミングが開始される。ピアツーピア・ダウンロードは最初から始まり、最後のサブクリップの締め切り時に終わる。
【００４３】
補足的ストリーミングのレートはｒまたは０なので、補足的ストリーミング・バンド幅使用はベルヌーイ・ランダム変数によって近似できる。受付許可コントローラは、各サブクリップについて、補足的ストリーミングによって送信される必要があるデータの量を追跡している。この量はＳｃｏｍｐ−ｓｔｒｅａｍｉｎｇで表される。このサブクリップについての平均補足的ストリーミング・データ・レートは、Ｓｃｏｍｐ−ｓｔｒｅａｍｉｎｇ／Ｔである。ここで、Ｔはサブクリップ長である。受付許可コントローラは、平均補足的ストリーミング・レート情報
【数１】
2010517365.tif 000004
を維持する。その値は新しい平均補足的ストリーミング・レートが利用可能なときは常に更新される。具体的には、
【数２】
2010517365.tif 000005
重みαは、平均補足的ストリーミング・バンド幅使用がどのくらい迅速に現在値に追いつくかを決定する。実験によれば、０．９５付近の値が良好なパフォーマンス結果をもたらすことが示されている。
【００４４】
ここで
【数３】
2010517365.tif 000006
の分散を推定することに転じる。補足的ストリーミング・バンド幅使用を近似するためにベルヌーイ分布が使用される。前記分散は：
【数４】
2010517365.tif 000007
のように計算できる。
【００４５】
サーバーも、ピアツーピア・ネットワークを通じてユーザーたちに送信されたデータの量を追跡している。平均サーバー・ピアツーピア・アップロード・バンド幅
【数５】
2010517365.tif 000008
はサブクリップの締め切り時に更新される。Ｓｐ２ｐｄｏｗｎｌｏａｄｉｎｇによって、１サブクリップ長の間にピアツーピア・ネットワークを使ってユーザーに転送されるデータの量を表すと、
【数６】
2010517365.tif 000009
が得られる。統計が集められたら、次の公式を使って要求が受付許可されることができるかどうかが試験される。
【００４６】
【数７】
2010517365.tif 000010
ここで、Ｎはユーザー数、σは総合的な補足的ストリーミング・バンド幅の標準偏差、βは標準偏差重みである。
【００４７】
総合的な補足的ストリーミング・バンド幅使用は、Ｎｃｏｍｐ−ｓｔｒｅａｍｉｎｇ個のベルヌーイ・ランダム変数の和である。中央極限定理によれば、ランダム変数の和は正規分布によって近似でき、その標準偏差は式（５）
【数８】
2010517365.tif 000011
によって支配される。式（４）においてβは、要求されるバンド幅が高い確率で利用可能なバンド幅より小さくなることを確実にするよう３に選ばれる。こうして、ユーザーたちの閲覧品質は新しいクライアントの受付許可によって劣化しない。
【００４８】
図５は、プレフィックス・キャッシングのある、パフォーマンスを意識するピアツーピアのビデオ・オン・デマンド・ストリーミング・サービス環境におけるバンド幅使用を、サーバーの観点から示している。クライアントのキャッシュ・メモリにビデオ・プレフィックスを事前充填するために使われるサーバー・バンド幅は示されていない。この活動は、それに使われなければアイドルなバンド幅を使って実施されるからである。たとえば、ビデオ・プレフィックスは、低ネットワーク使用の時に受信ピア・キャッシュ・デバイスにプッシュされるのである。
【００４９】
本発明の利点は、改善された受付許可比を含む。受付許可比（ａｄｍｉｓｓｉｏｎ  ｒａｔｉｏ）は、ＶｏＤサービスを受信することが受付許可されるクライアント要求の割合として定義される。平均欠失分率（ａｖｅｒａｇｅ  ｍｉｓｓｉｎｇ  ｆｒａｃｔｉｏｎ）は、再生時間を逃すビデオ・コンテンツの割合として定義され、ユーザーの閲覧品質を示す。規格化負荷（ｎｏｒｍａｌｉｚｅｄ  ｗｏｒｋｌｏａｄ）はビデオの長さと要求レートとの積（すなわち、ビデオの長さ当たりの平均要求数）として定義される。
【００５０】
実験では、クライアントの平均上りリンク・バンド幅は再生レートより大きい。一つのビデオは、３６００秒の長さでシミュレートされ、プレフィックス・キャッシュ・サイズは平均してビデオ長さ全体の約３％である。
【００５１】
図６は、作業負荷が増すにつれての受付許可比の傾向を示している。見て取れるように、プレフィックス・キャッシングのあるＰＯＮＤＥＲは、ビデオ長さ当たり３６０個の要求まで９９％以上の受付許可レートで受け容れることができる。これは、プレフィックス・キャッシングなしのＰＯＮＤＥＲから得られるビデオ長当たり１２０個の要求の受付許可に比べて三倍ものパフォーマンス利得である。
【００５２】
大幅に増大した受付許可比（すなわちシステム・スケーラビリティ）とともに、プレフィックス・キャッシングは、プレフィックス・キャッシングなしのピアツーピアＶｏＤよりもよい閲覧品質を同様にユーザーにもたらしもする。図７に示されるように、システムがビデオ当たり３６０要求の点に達するときでさえ、平均欠失分率はいまだ０に近い。
【００５３】
図６および図７が導出される実験において、送信ピアの平均上りリンク・バンド幅は再生レートより大きい。３６００秒の長さをもつビデオ一つしかなく、プレフィックス・キャッシュ・サイズは平均してビデオ長さ全体の約３％である。
【００５４】
ビデオ・ライブラリ全体の３％の記憶スペースの増大がシステム・スケーラビリティを三倍持ち上げるという事実は、プレフィックス・キャッシング技術の有効性を明瞭に示している。
【００５５】
本発明がハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはそれらの組み合わせのさまざまな形で実装されうることは理解されるものである。好ましくは、本発明はハードウェアおよびソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは、プログラム記憶装置上に具体的に具現されたアプリケーション・プログラムとして実装される。該アプリケーション・プログラムはいかなる好適なアーキテクチャを有する機械にアップロードされ、該機械によって実行されてもよい。
【００５６】
ある実施形態では、前記機械は、一つまたは複数の中央処理ユニット（「ＣＰＵ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）および入出力（「Ｉ／Ｏ」）インターフェース（単数または複数）といったハードウェアをもつコンピュータ・プラットフォーム上で実装される。前記コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードをも含む。本稿に記載されたさまざまなプロセスおよび機能はマイクロ命令コードの一部もしくはアプリケーション・プログラムの一部（またはそれらの任意の組み合わせ）であってよく、オペレーティング・システムを介して実行される。さらに、追加的なデータ記憶装置および印刷装置といったさまざまな他の周辺装置がコンピュータ・プラットフォームに接続されていてもよい。
【００５７】
本発明のさまざまな実施形態において、受信ピア・デバイスにおいて、サーバー・デバイスから、あるいはサービスするピア・デバイスからのビデオ・プレフィックス・データのマルチキャストに応答して、ビデオ・プレフィックスが受信される。受信されるビデオ・プレフィックスは、選択プロファイルに基づいて、受信ピア・デバイスの、サービス・ピア・デバイスの、あるいはサーバー・デバイスの機能として選択されてもよい。たとえば、前記選択プロファイルは、受信ピア・デバイスに関連付けられたユーザーの閲覧選好を表してもよい。閲覧選好は、ユーザーによって入力されてもよいし、あるいは受信ピア・デバイスなどにおける閲覧履歴に基づいて自動的に発展されてもよい。本発明のもう一つの実施形態では、前記選択プロファイルは、たとえば、選択されたユーザー人口またはグローバルなユーザー人口の閲覧履歴に基づいていてもよい。さらにもう一つの実施形態では、受信ピア・デバイスは、特定のサーバー・デバイスまたはサービス・ピア・デバイスによって提供されるすべての利用可能なビデオ・プレフィックスを受信する。もう一つの実施形態では、ビデオ・プレフィックスはマルチキャストされず、特定の受信ピアに向けられる。
【００５８】
付属の図面に描かれている構成システム・コンポーネントおよび方法段階のいくつかは好ましくはソフトウェアにおいて実装されるので、システム・コンポーネント（またはプロセス段階）の間の実際の接続は、本発明がプログラムされる仕方に依存して異なることがありうる。本稿の教示を与えられれば、当業者は、本発明のこれらおよび同様の実装または構成を考えることができるであろう。
【図１】
2010517365.tif 000012
【図２】
2010517365.tif 000013
【図３】
2010517365.tif 000014
【図４】
2010517365.tif 000015
【図５】
2010517365.tif 000016
【図６】
2010517365.tif 000017
【図７】
2010517365.tif 000018
【手続補正書】
【提出日】平成21年7月22日(2009.7.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
デジタル・マルチメディア・ピアツーピア・デバイスであって：
当該マルチメディア・ピアツーピア・デバイスにおいて、受付許可信号の受信に先立ってマルチメディア・プレフィックスを記憶するよう適応されたローカル・キャッシュ・メモリと；
前記受付許可信号を受信し、応答して前記マルチメディア・プレフィックスの再生を開始し、その後、前記マルチメディア・プレフィックスに関係したマルチメディア番組データを受信するよう適応されたコントローラとを有し、前記受付許可制御は、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
デジタル・マルチメディア・ピアツーピア・デバイス。
【請求項２】
前記ローカル・キャッシュ・メモリ・デバイスが、サーバー・デバイス上に記憶された複数のマルチメディア番組にそれぞれ対応する複数のマルチメディア・プレフィックスのうちの一つであるマルチメディア・プレフィックスを含んでいる、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項３】
前記ローカル・キャッシュ・メモリ・デバイスが、前記マルチメディア・プレフィックスを記憶することを、低ネットワーク使用の期間中に行うよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項４】
前記ローカル・キャッシュ・メモリ・デバイスが電気機械式ディスク・ドライブ・デバイスを含む、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項５】
前記ローカル・キャッシュ・メモリ・デバイスが半導体メモリ・デバイスを含む、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項６】
前記デジタル・マルチメディア・ピアツーピア・デバイスが第一のピアツーピア・デバイスであり、前記第一のピアツーピア・デバイスがサービス・ピア・デバイスとして機能するよう適応されており、前記コントローラが前記マルチメディア・プレフィックスを通信ネットワークを通じて、受信ピア・デバイスとして機能するよう適応された第二のピアツーピア・デバイスに送信するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項７】
前記マルチメディア・プレフィックスが低ネットワーク使用の期間中に送信される、請求項６記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項８】
前記コントローラが、受付許可要求を受付許可制御デバイスに送るよう適応されており、前記受付許可制御デバイスが、前記マルチメディア・ピアツーピア・クライアント・デバイスにおける事前キャッシングされたマルチメディア・プレフィックスの存在または不在を考慮するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項９】
前記コントローラが、当該マルチメディア・ピアツーピア・デバイスにおいてローカルにキャッシングされたマルチメディア・プレフィックスが利用可能でない場合、ストリーミングされたマルチメディア・プレフィックスをサーバーから受信するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項１０】
マルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法であって：
マルチメディア・オン・デマンド・システムに受付許可を要求する段階と；
前記マルチメディア・オン・デマンド・システムへの受付許可を受信する段階と；
ローカル・キャッシュに記憶されたマルチメディア・プレフィックスに基づいてマルチメディア番組の第一の部分の再生を開始する段階と；
その後、前記マルチメディア・オン・デマンド・システムの通信ネットワークからさらなるマルチメディア・サブクリップを受信する段階とを有し、受付許可を受信することは、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
方法。
【請求項１１】
前記記憶されたマルチメディア・プレフィックスを電気機械式メモリ・デバイスに記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１２】
前記記憶されたマルチメディア・プレフィックスを半導体メモリ・デバイスに記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１３】
前記記憶されたマルチメディア・プレフィックスを前記ローカル・キャッシュに、低ネットワーク負荷の時間期間の間に記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１４】
前記記憶されたマルチメディア・プレフィックスを、サーバー・デバイスからのデジタル・マルチメディア・マルチキャスト・データの受信に応答して記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１５】
サーバーによる前記ローカル・キャッシュに記憶されている前記マルチメディア・プレフィックスの利用可能性の考慮に基づく前記受付許可を受信することを含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１６】
前記マルチメディア番組の前記さらなるマルチメディア・サブクリップを再生する段階をさらに含む、請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１７】
マルチメディア・デバイスであって：
ピアツーピア通信のために通信ネットワークに結合されるよう適応されているコントローラと；
前記コントローラに結合された、再生のためにマルチメディア・プレフィックスを記憶するよう適応されたキャッシュ・メモリとを有し、前記再生は前記ネットワークからの前記プレフィックに関係したさらなるマルチメディア・データの受信に先立って始まり、前記再生は受付許可信号を受信することを条件とし、前記受付許可信号の受信は、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
マルチメディア・デバイス。
【請求項１８】
前記マルチメディア・プレフィックスがオーディオ・プレフィックスを含む、請求項１７記載のマルチメディア・デバイス。
【手続補正書】
【提出日】平成21年12月14日(2009.12.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
デジタル・マルチメディア・ピアツーピア・デバイスであって：
当該マルチメディア・ピアツーピア・デバイスにおいて、受付許可信号の受信に先立ってマルチメディア・プレフィックスを記憶するよう適応されたローカル・キャッシュ・メモリと；
前記受付許可信号を受信し、応答して前記マルチメディア・プレフィックスの再生を開始し、その後、前記マルチメディア・プレフィックスに関係したマルチメディア番組データを受信するよう適応されたコントローラとを有し、前記受付許可信号の受信は、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
デジタル・マルチメディア・ピアツーピア・デバイス。
【請求項２】
前記ローカル・キャッシュ・メモリが、サーバー・デバイス上に記憶された複数のマルチメディア番組にそれぞれ対応する複数のマルチメディア・プレフィックスのうちの一つであるマルチメディア・プレフィックスを含んでいる、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項３】
前記ローカル・キャッシュ・メモリが、前記マルチメディア・プレフィックスを記憶することを、低ネットワーク使用の期間中に行うよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項４】
前記ローカル・キャッシュ・メモリが電気機械式ディスク・ドライブ・デバイスを含む、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項５】
前記ローカル・キャッシュ・メモリが半導体メモリ・デバイスを含む、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項６】
前記デジタル・マルチメディア・ピアツーピア・デバイスが第一のピアツーピア・デバイスであり、前記第一のピアツーピア・デバイスがサービス・ピア・デバイスとして機能するよう適応されており、前記コントローラが前記マルチメディア・プレフィックスを通信ネットワークを通じて、受信ピア・デバイスとして機能するよう適応された第二のピアツーピア・デバイスに送信するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項７】
前記マルチメディア・プレフィックスが低ネットワーク使用の期間中に送信される、請求項６記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項８】
前記コントローラが、受付許可要求を受付許可制御デバイスに送るよう適応されており、前記受付許可制御デバイスが、前記マルチメディア・ピアツーピア・クライアント・デバイスにおける事前キャッシングされたマルチメディア・プレフィックスの存在または不在を考慮するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項９】
前記コントローラが、当該マルチメディア・ピアツーピア・デバイスにおいてローカルにキャッシングされたマルチメディア・プレフィックスが利用可能でない場合、ストリーミングされたマルチメディア・プレフィックスをサーバーから受信するよう適応されている、請求項１記載のデジタル・マルチメディア・ピアツーピア・デバイス。
【請求項１０】
マルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法であって：
マルチメディア・オン・デマンド・システムに受付許可を要求する段階と；
前記マルチメディア・オン・デマンド・システムへの受付許可を受信する段階と；
ローカル・キャッシュに記憶されたマルチメディア・プレフィックスに基づいてマルチメディア番組の第一の部分の再生を開始する段階と；
その後、前記マルチメディア・オン・デマンド・システムの通信ネットワークからさらなるマルチメディア・サブクリップを受信する段階とを有し、受付許可を受信することは、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
方法。
【請求項１１】
前記記憶されたマルチメディア・プレフィックスを電気機械式メモリ・デバイスに記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１２】
前記記憶されたマルチメディア・プレフィックスを半導体メモリ・デバイスに記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１３】
前記記憶されたマルチメディア・プレフィックスを前記ローカル・キャッシュに、低ネットワーク負荷の時間期間の間に記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１４】
前記記憶されたマルチメディア・プレフィックスを、サーバー・デバイスからのデジタル・マルチメディア・マルチキャスト・データの受信に応答して記憶する段階を含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１５】
サーバーによる前記ローカル・キャッシュに記憶されている前記マルチメディア・プレフィックスの利用可能性の考慮に基づく前記受付許可を受信することを含む、
請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１６】
前記マルチメディア番組の前記さらなるマルチメディア・サブクリップを再生する段階をさらに含む、請求項１０記載のマルチメディア・オン・デマンド・ピアツーピア・デバイスの動作方法。
【請求項１７】
マルチメディア・デバイスであって：
ピアツーピア通信のために通信ネットワークに結合されるよう適応されているコントローラと；
前記コントローラに結合された、再生のためにマルチメディア・プレフィックスを記憶するよう適応されたキャッシュ・メモリとを有し、前記再生は前記ネットワークからの前記プレフィックに関係したさらなるマルチメディア・データの受信に先立って始まり、前記再生は受付許可信号を受信することを条件とし、前記受付許可信号の受信は、必要なマルチメディア・プレフィックスがローカルにキャッシュされているマルチメディア再生デバイスからの新しい受付許可要求をサポートするのに十分なバンド幅があるかどうかを判定し、既存の受付許可済みのユーザーに対するサービス品質を犠牲にすることなく前記要求を受付許可するのに十分なバンド幅があるかどうかを判定する結果を条件とする、
マルチメディア・デバイス。
【請求項１８】
前記マルチメディア・プレフィックスがオーディオ・プレフィックスを含む、請求項１７記載のマルチメディア・デバイス。
【国際調査報告】
2010517365.tif 000019
2010517365.tif 000020
2010517365.tif 000021