(57)【要約】ピアツーピアのコンテンツオンデマンド・サービスのための対話的再生操作をサポートするための方法および装置であって、再生操作の検出およびサブクリップ型の検出を含むものが記載される。本方法および装置はまた、ストリーミングされた先頭サブクリップを受け取り、一組の必要とされるサブクリップを決定し、前記一組の必要とされるサブクリップのうちの一つを位置特定し、位置特定されたサブクリップをダウンロードする。
2009543439.tif 000002
【特許請求の範囲】
【請求項１】
ピアツーピアのコンテンツオンデマンド・サービスのための再生操作をサポートする方法であって：
再生操作を検出する段階と；
サブクリップ型を検出する段階とを有する方法。
【請求項２】
ストリーミングされた先頭サブクリップを受信する段階と；
必要とされるサブクリップの組を決定する段階と；
前記組の必要とされるサブクリップのうちの一つを位置特定する段階と；
前記位置特定されたサブクリップをダウンロードする段階とを有する、請求項１記載の方法。
【請求項３】
前記ピアツーピアのコンテンツオンデマンド・サービスがパフォーマンス意識がある、請求項１記載の方法。
【請求項４】
前記再生操作が前へのジャンプの再生操作である請求項２記載の方法であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
目標再生点を含むサブクリップをストリーミングする段階と；
サブクリップ締め切りを計算する段階と；
再生を開始する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項５】
前記再生操作が後へのジャンプの再生操作である請求項２記載の方法であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
目標再生点を含むサブクリップをストリーミングする段階と；
目標再生点を含むサブクリップにおいて再生を開始する段階と；
サブクリップ締め切りを計算する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項６】
前記再生操作が一時停止の再生操作である請求項２記載の方法であって、さらに：
再生を停止する段階と；
サブクリップのストリーミングを停止する段階と；
サブクリップのダウンロードを停止する段階と；
サブクリップの締め切りを無限大に設定する段階とを有する、
方法。
【請求項７】
前記再生操作が再開の再生操作である請求項６記載の方法であって、さらに：
新しいサブクリップ締め切りを計算する段階と；
サブクリップがストリーミングされていた場合、サブクリップのストリーミングを再開する段階と；
再生を開始する段階と；
前記一時停止動作が呼び出されたときにダウンロードされているところだったサブクリップがあればそのサブクリップのダウンロードを再開する段階とを有する、
方法。
【請求項８】
前記再生操作が早送りの再生操作である請求項２記載の方法であって、さらに：
速められた再生レートを計算する段階と；
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
サブクリップをストリーミングする段階と；
サブクリップ締め切りを計算する段階と；
再生を開始する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項９】
前記再生操作が早戻しの再生操作である請求項２記載の方法であって、さらに：
速められた再生レートを計算する段階と；
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
サブクリップをストリーミングする段階と；
再生を開始する段階と；
サブクリップ締め切りを計算する段階と；
前記ストリーミングされたサブクリップに先行するサブクリップをダウンロードする段階とを有する、
方法。
【請求項１０】
ピアツーピアのコンテンツオンデマンド・サービスのための再生操作をサポートする装置であって：
サブクリップ型を検出する手段と；
再生操作を検出する手段と；
を有する装置。
【請求項１１】
ストリーミングされた先頭サブクリップを受信する手段と；
必要とされるサブクリップの組を決定する手段と；
前記組の必要とされるサブクリップのうちの一つを位置特定する手段と；
前記位置特定されたサブクリップをダウンロードする手段とを有する、請求項１０記載の装置。
【請求項１２】
前記ピアツーピアのコンテンツオンデマンド・サービスがパフォーマンス意識がある、請求項１０記載の装置。
【請求項１３】
前記再生操作が前へのジャンプの再生操作である請求項１１記載の装置であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
目標再生点を含むサブクリップをストリーミングする手段と；
サブクリップ締め切りを計算する手段と；
再生を開始する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１４】
前記再生操作が後へのジャンプの再生操作である請求項１１記載の装置であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
目標再生点を含むサブクリップをストリーミングする手段と；
目標再生点を含むサブクリップにおいて再生を開始する手段と；
サブクリップ締め切りを計算する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１５】
前記再生操作が一時停止の再生操作である請求項１１記載の装置であって、さらに：
再生を停止する手段と；
サブクリップのストリーミングを停止する手段と；
サブクリップのダウンロードを停止する手段と；
サブクリップの締め切りを無限大に設定する手段とを有する、
装置。
【請求項１６】
前記再生操作が再開の再生操作である請求項１５記載の装置であって、さらに：
新しいサブクリップ締め切りを計算する手段と；
サブクリップがストリーミングされていた場合、サブクリップのストリーミングを再開する手段と；
再生を開始する手段と；
前記一時停止動作が呼び出されたときにダウンロードされているところだったサブクリップがあればそのサブクリップのダウンロードを再開する手段とを有する、
装置。
【請求項１７】
前記再生操作が早送りの再生操作である請求項１１記載の装置であって、さらに：
速められた再生レートを計算する手段と；
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
サブクリップをストリーミングする手段と；
サブクリップ締め切りを計算する手段と；
再生を開始する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１８】
前記再生操作が早戻しの再生操作である請求項１１記載の装置であって、さらに：
速められた再生レートを計算する手段と；
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
サブクリップをストリーミングする手段と；
再生を開始する手段と；
サブクリップ締め切りを計算する手段と；
前記ストリーミングされたサブクリップに先行するサブクリップをダウンロードする手段とを有する、
装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パフォーマンス意識のある（performance  aware）ピアツーピアのビデオオンデマンド・サービスのためのビデオ再生装置のユーザー対話性／操作のためのサポートに関する。
【背景技術】
【０００２】
ストリーミング・サービスを提供するために、伝統的にクライアント‐サーバー・サービス・モデルが使われてきた。クライアントがサーバーに要求を送り、サーバーがそのクライアントの要求にサービスするのに十分なりソースを有し、サーバーとクライアントの間の経路に沿って十分な帯域幅があれば、サーバーが次いでコンテンツをクライアントにストリーミングする。
【０００３】
サーバーにおける限られた計算および記憶リソースおよびサーバーとクライアントを接続するネットワークにおける限られた帯域幅のため、クライアント‐サーバー・ストリーミング・サービスではスケーラブル性が問題となってきた。近年、ピアツーピア技術がストリーミング・サービスに導入された。ピアがクライアントおよびサーバーの機能を実装され、コンテンツを能動的にキャッシュして他のピアにサービスすることにより、サーバーに課される負担を軽減し、帯域幅要求をネットワークにわたって分散させるのに寄与する。研究によれば、ピアツーピア技術はシステムのスケーラブル性を大幅に改善し、システムがずっと多くのユーザーにサービスできるようになることが示されている。
【０００４】
ピアツーピア・ネットワーキングを使ったストリーミング・メディア・サービスにおいて呈示されるスケーラブル性問題に取り組む著しい努力が費やされてきた。これらの努力は、二つの範疇、特にピアツーピア・ライブ・ストリーミングおよびピアツーピア保存ビデオ・ストリーミングまたはビデオオンデマンドに分類できる。どちらのサービスもユーザーに良好な視聴品質を提供しつつ多数のユーザーをサポートしようと努力するものであるが、両者は異なる技術的課題に直面してもいる。ピアツーピア・ライブ・ストリーミングでは、システムのスケーラブル性を犠牲にすることなく立ち上げ遅延を最小にすることが課題である。ピアツーピア・ビデオオンデマンド・サービスでは、非同期ユーザーが共有できるようにすることが課題である。
【０００５】
ピアツーピア・ストリーミング方式は、異なるデータ散布技術によっても区別される。二つのデータ散布方法が調査されている。特に、オーバーレイ・ベースのアプローチとデータ駆動のアプローチである。オーバーレイ・ベースのアプローチでは、ピアがメッシュまたはツリー構造を形成し、そこで、ピアの間に親子関係が形成される。子ピアはその親からデータを受け取る。対照的に、データ駆動アプローチにおけるピアは固定した親子関係はもたない。ピアは欠けているデータを探し、入手できるところではいつでも欠けているデータを取得する。オーバーレイ・ベースのアプローチは初期のピアツーピア努力において広く使われているが、データ駆動のアプローチは激動（churn）および非対称帯域幅の問題に効果的に対処するので一般的になりつつある。
【０００６】
従来技術の努力のほとんどは良好なスケーラブル性を示し、伝統的なクライアント‐サーバー・サービス・モデルに比べて多くのユーザーをサポートするものの、従来技術の方式は、性質上、最善努力であり、システム・パフォーマンス要求のサポートは完全に調査されてはいない。パフォーマンス意識のあるピアツーピアのビデオオンデマンド・サービスを使うことは、ビデオ再生装置とのユーザー対話性に関わる動作が異なる仕方で扱われなければならないということを意味する。今日まで、従来技術はそのようなビデオ再生動作を扱うことに対処してこなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
パフォーマンス意識のあるピアツーピアのビデオオンデマンド・サービスは、ユーザーが、好きなときにいつでもネットワークを通じてビデオ・コンテンツを選択し、視聴することを許容する。関係する出願において、セグメント化されたピアツーピア・ビデオ共有が記載された。これは、ビデオオンデマンド環境におけるコンテンツ共有を可能にした。パフォーマンスは、ピアツーピア・データ・ダウンロードおよびサーバーに支援された補足的ストリーミングによって対処された。
【０００８】
本発明は、パフォーマンス意識のあるピアツーピアのビデオオンデマンド・サービスのためのビデオ再生装置のためのユーザー対話性／操作をサポートすることに向けられる。そのような操作は、前／後へのジャンプ、一時停止／再開、早送りおよび早戻しを含む。
【課題を解決するための手段】
【０００９】
ピアツーピアのビデオオンデマンド・サービスのためのビデオ再生操作をサポートするための方法および装置であって、ビデオ再生操作の検出およびサブクリップ（sub-clip）型の検出を含むものが記載される。本方法および装置はまた、ストリーミングされた先頭（leading）ビデオ・サブクリップを受け取り、一組の必要とされるビデオ・サブクリップを決定し、前記一組の必要とされるビデオ・サブクリップのうちの一つを位置特定し、位置特定されたビデオ・サブクリップをダウンロードする。
【００１０】
本発明は、以下の詳細な記述を付属の図面とともに読むことで最もよく理解される。図面において、同様の符号は同様の要素を表す。
【発明を実施するための最良の形態】
【００１１】
ビデオオンデマンド・サービスのユーザーたちは、任意の所与の時点でビデオの異なる部分を見る。ユーザーの間でのコンテンツ共有を可能にし、ピアツーピア・ネットワークを通じて送達されるコンテンツの量を最大にするために、各ユーザーは再生されたコンテンツの部分的なコピーおよび／または完全なコピーをキャッシュする記憶容量をもつ。これは、ビデオ再生装置の急速に増大しつつある記憶容量を考えれば無理ではない想定である。なお、ビデオ再生装置は、ビデオ（保存されたビデオまたはライブ・ビデオ）を受信および再生する機能をもつ任意の装置であり、これに限られないが、コンピュータ、ラップトップ、携帯情報端末（PDA）およびモバイル・デバイスが含まれる。ピアツーピア・ネットワークは有線ネットワークに限定されず、無線もしくは有線のネットワークまたは有線および無線接続の両方を用いるハイブリッド・ネットワークのどれであってもよい。
【００１２】
本発明のセグメント化されたピアツーピアのビデオオンデマンド方法および装置では、ビデオ・クリップは、サブクリップ（sub-clip）と称される複数の等しい長さのセグメントに分割される。サブクリップの始まりの再生時刻は、このサブクリップの締め切り（deadline）として定義される。先頭（leading）サブクリップはビデオ再生装置にストリーミングされ、ユーザーは再生をすぐ開始できる。その間、後続のサブクリップのデータをあらかじめ取ってくるために、ピアツーピア・ネットワークがユーザーの間で確立される。本発明のシステム・パフォーマンス意識のある方式によれば、サブクリップのデータはその締め切りより前にあらかじめ取ってくる必要がある。いったんサブクリップの再生が始まったら、そのサブクリップのピアツーピア・ダウンロードは許されない。というのも、新たにダウンロードされたデータは時期遅れであるかもしれないからである。よりよいシステム・パフォーマンスのために、この点以降、もとのサーバーからの補足的ストリーミングが開始される。補足的ストリーミングについて以下に述べる。
【００１３】
例を使って、セグメント化されたピアツーピア・ビデオオンデマンドがどのようにしてはいってくる要求にサービスするかを示す。この例では、ユーザーはビデオ全体のコピーをキャッシュできると想定する。同じ技術は、ビデオ・コピーの一部だけがキャッシュされる場合であっても適用できる。さらに、サーバーは最初のサブクリップをストリーミングするのみで、後続のサブクリップのデータはピアツーピア・ネットワークを使ってダウンロードされると想定する。ストリーミングされるサブクリップの数を計算するアルゴリズムについて以下に呈示し、説明する。
【００１４】
ここで図１を参照すると、クライアント／ユーザー１は時刻t1にサーバーにビデオの要請／要求をする。サーバーはすぐサブクリップ１（最初のビデオ・サブクリップ）をクライアント１にストリーミングする。こうしてクライアント１はすぐに再生を開始できる。同時に、ピアツーピア・ネットワーク内でサブクリップ２をもっている／キャッシュしているピアを位置特定しようとする試みがなされる。この時点で、ピアツーピア・ネットワークにおける、サブクリップ２をもっている／キャッシュしている唯一のピアはサーバーである（このサーバーはピアとして振る舞うことができる）。クライアント１およびサーバー（少なくとも）はいずれも、ピアツーピア・ネットワークのメンバーである。時刻t2に、クライアント１はサブクリップ１を再生しており、サブクリップ２はサーバーからダウンロードされつつある（ストリーミングされるのではない）。クライアント／ユーザー２がサーバーに同じビデオの要請／要求をし、すぐサブクリップ１の再生を開始する。このサブクリップ１はサーバーからクライアント２にストリーミングされたものである。サーバーおよびクライアント１の両方がサブクリップ２のクライアント２へのダウンロード（ストリーミングではない）を開始する。この時点では、サーバー、クライアント１およびクライアント２が、前記ピアツーピア・ネットワークにおけるピアである。時刻t3において、クライアント３がサーバーに同じビデオの要請／要求をし、すぐサブクリップ１の再生を開始する。このサブクリップ１はサーバーからストリーミングされたものである。今では、クライアント１はサブクリップ３を再生しており、サブクリップ４のデータ／ビデオをダウンロードしている。クライアント２はサブクリップ２を再生しており、サブクリップ３のデータ／ビデオをダウンロードしている。この時点では、サーバー、クライアント１、クライアント２およびクライアント３（少なくとも）が、前記ピアツーピア・ネットワークのメンバーである。クライアント３はサブクリップ２をサーバー、クライアント１およびクライアント２からダウンロードできる。時間が進むにつれ、ピア・ビデオ再生が続く。図１において現在時刻t4で示されているように、ピアツーピア・ダウンロードは、現在再生されているサブクリップに続くサブクリップのデータをあらかじめ取ってくる。時刻t5までには、クライアント１はすでにそのビデオ再生を終え、システムを抜けている。クライアント２は最後のサブクリップを再生しており、クライアント３はサブクリップ４を再生し、サブクリップ５をダウンロードしている。サブクリップ５をダウンロードする目的のためには、サーバーおよび第二のクライアントが前記ピアツーピア・ネットワークのピアである。最後にはクライアント２もビデオ再生を終了後、システムから抜ける。クライアント３はサブクリップ５を視聴／再生し、サブクリップ５の終わりにシステムを抜ける。
【００１５】
上で論じたように、パフォーマンス問題（ユーザーにおける／ユーザーによるサブクリップの適時の到着）に対処するために格別な注意が払われるが、それでも、ピアツーピア・ダウンロードが休止するとき、一部のデータが締め切り時点までに（あるいは締め切りの少し前に）欠けていることがありうる。欠けているデータをストリーミングしてピア・ビデオ再生パフォーマンスをさらに向上させるためにどのようにサーバーを使うかについてこれから述べる。これは、本稿では補足的ストリーミング（complementary  streaming）と呼ばれる。締め切りが近づくにつれ、ピア・クライアントは欠失データ・ベクトルV欠失を用意する。これは、第一のフラグ、たとえば「1」を使ってあるブロックが受信されていることを示し、第二のフラグ、たとえば「0」を使ってブロックがまだ欠けていることを示すビットマップである。欠失データ・ベクトルはサーバーに送られる（信号伝達）。締め切りが近づくと、欠けているデータ／ビデオがピア・ビデオ再生の時間までに補充されうるよう、サーバーは欠けているデータを通常の再生レートでストリーミング送出しはじめる。
【００１６】
ユーザー対話性、すなわちビデオ装置再生操作は、ビデオオンデマンド・サービスの重要な側面である。前／後へのジャンプ操作を呼び出すユーザーは、クリップ内の任意の点から通常再生レートでビデオを再生することを欲する。意図される新しい再生点のことを、目標再生点（target  playback  point）またはTPPで表すものとする。TPPが現在の再生点より後である場合、それは前へのジャンプ（jump  forward）操作である。そうでなければ、後へのジャンプ操作（jump  backward）である。
【００１７】
上で図１に示したように、パフォーマンス意識のあるピアツーピア・ビデオオンデマンド・サービスには四つの型のサブクリップが存在する：空のサブクリップ、ダウンロードされるサブクリップ、ダウンロード進行中のサブクリップおよびストリーミングされるサブクリップである。目標再生点（TPP）がどのサブクリップの型に該当するかに依存して、前／後へのジャンプ操作は異なる仕方で処理される。以下では、サーバーから直接ストリーミングされる必要があるかもしれないサブクリップの最大数をどのように計算するかをまず述べる。そのTPPが該当するサブクリップの型および後続のサブクリップの型に基づく、ストリーミングされるサブクリップの実際の数についても述べる。最後に、前／後へのジャンプ操作をサポートするためにどのようにサブクリップ締め切りを修正するかについて述べる。
【００１８】
ストリーミングされるサブクリップの数は、目標再生点（TPP）のあとのデータがバッファ中に全くキャッシュされていないときに最大になる。そのようなシナリオでは、前／後へのジャンプ操作をサポートすることは、そのTPPから新しいビデオを開始するのと似ている。TPPがサブクリップiに該当するとする。以下では、k＞iとなるサブクリップkについてはキャッシュされたデータがないと想定して、ストリーミングされるサブクリップの最大数を計算する方法について述べる。
【００１９】
TPPからサブクリップiの終わりまでの時間期間はt残りで表され、ストリーミングされるサブクリップの最大数はn*で表される。すると、関係式
（r下りリンク−r再生）（t残り＋n*L）≧r再生L
が導かれる。ここで、r下りリンクは下りリンク速度、r再生は再生レート、Lはサブクリップの継続時間である。n*は整数でなければならず、サブクリップiより後のサブクリップの総数より大きくなることはないので、
【数１】
2009543439.tif 000003
となる。ここで、(.)+は非負関数、Nはサブクリップの総数である。
【００２０】
次に、ストリーミングされる必要のあるサブクリップの実際の数を調べる。パフォーマンス意識のあるピアツーピア・ビデオオンデマンド・サービスには四つの型のサブクリップがある：空のサブクリップ、ダウンロードされたサブクリップ、ストリーミングされるサブクリップおよびダウンロード進行中のサブクリップである。ストリーミングされるサブクリップおよびダウンロード進行中のサブクリップはいずれも、サブクリップ・データの一部をキャッシュしているので、よってここでは空のサブクリップと同じとして扱われる。これは問題を単純化し、こうして、ストリーミングされるサブクリップの保守的な数が計算される。データの一部がバッファ中で利用可能であっても補足的ストリーミングを適用することが推薦される。
【００２１】
図２は、早送り、前へのジャンプおよび後へのジャンプ操作についてのストリーミングされるサブクリップの実際の数を計算するプロセスのフローチャートである。２０５で、戻り値が初期化される。２１０で、現在サブクリップ・カウンタが次のサブクリップに初期化される。２１５で、現在サブクリップが完全にキャッシュされているかどうかを判定する。現在サブクリップが完全にキャッシュされていれば、２２０で、前記戻り値をもって戻る。現在サブクリップが完全にキャッシュされていない場合、２２５で戻り値をインクリメントし、２３０で、現在サブクリップ・カウンタをインクリメントする。このプロセスはn*個のサブクリップを通じて本質的にループする。サブクリップkが完全にキャッシュされていれば、下りリンク帯域幅全体が次の空のサブクリップのデータをダウンロードするために利用可能である。下りリンク速度は常に再生レートより大きいので（そうでなければそもそもビデオオンデマンド・サービスは提供できない）、空のサブクリップは締め切りの前に完全にダウンロードされる。したがって、サブクリップkよりあとの任意の空のサブクリップが締め切り前にダウンロードされることができ、直接ストリーミングは必要とされない。
【００２２】
次に、前／後へのジャンプ操作に対応するためにサブクリップ締め切りをどのように調節するかを考える。tを現在時刻、バー付きのdkをk番目のサブクリップの新しい締め切りとする。すると、i＜k＜Nについて、次の式
【数２】
2009543439.tif 000004
が導かれる。ここで、Lはサブクリップの継続時間である。
【００２３】
パフォーマンス意識のあるピアツーピア・ビデオオンデマンド・サービスにおける一時停止動作をサポートすることはストレートにできる。単にビデオ再生を停止し、進行中のストリーミングやダウンロードがあればそれを一時停止するだけである。ダウンロード・プロセスを延期するために、サブクリップ締め切りは無限大に変えられる。一時停止操作は、ストリーミングされるサブクリップおよびダウンロードされたサブクリップにおいてのみ生起することを注意しておく。
【００２４】
再開動作はサブクリップの型に依存して異なる仕方で処理される。サブクリップiでビデオが一時停止されているとする。現在サブクリップがストリーミングされるサブクリップであれば、ユーザーはビデオ再生装置を介してサーバーに再生を再開するよう信号伝達する。サーバーも一時停止操作が呼び出される前にストリーミングされるべきであると指定されていたサブクリップのストリーミングを再開する。この背後にある考え方は、一時停止操作はすべての動作が一時的に中断し、再開操作はシステム状態を変えることなくストリーミングを再開するということである。一方、サブクリップ締め切りは、一時停止操作によって生じた時間経過を反映するよう修正される。再開点から次のサブクリップi＋1の始めまでの再生時間がt残りであり、現在時刻がtであるとすると、新しい締め切りを計算するために式(2)が使われる。
【００２５】
一時停止点がダウンロードされたサブクリップに該当する場合には、ユーザーはビデオ再生装置を介して現在サブクリップの再生をすぐ再開し、ダウンロード・プロセスを再開し、後続のサブクリップの締め切りがやはり式(2)を使って修正される。
【００２６】
早送り操作のためには、ビデオは通常の再生レートより速いレートで再生される。早送り操作の高速化因子はδで表される。早送り操作の再生レートはδ・r再生である。
【００２７】
以下では、ストリーミングされるサブクリップの最大数n*をまず計算する。次いで、ストリーミングされるサブクリップの実際の数が計算される。最後に、サブクリップ締め切りの修正が実行される。前へのジャンプ操作と早送り操作との間に強い相関があることが明らかになるであろう。
【００２８】
再生開始点から現在サブクリップの終わりまでの時間期間はt残りで表される。早送り操作のための再生レートはr再生′と表される。すなわち、r再生′＝δ・r再生である。よって、次の関係式
（r下りリンク−r再生′）（t残り−n*L）／δ≧r再生L  （式3）
が導かれる。
【００２９】
なお、式(3)の左辺の第２項をδで割っているのは、再生レートが因子δだけ速まっていることを反映するためである。n*は整数でなければならず、N−iより大きくなることはないので、次の関係式
【数３】
2009543439.tif 000005
が導ける。
【００３０】
図２の方法は、ストリーミングされるサブクリップの実際の数を見出すために応用できる。i＜k＜Nとして、サブクリップkについての調節された締め切りは
【数４】
2009543439.tif 000006
となる。
【００３１】
早戻し操作についての残り時間は、現在再生点から現在サブクリップの始めまでの時間期間である。t残りを使って早戻し操作のための残り時間を表すと、ストリーミングされるサブクリップの最大数は：
【数５】
2009543439.tif 000007
となる。式(4)および式(6)は、最後の項を除いて似ている。この違いは、反対の再生方向によって説明できる。なお、早送りおよび早戻し操作はいずれも、どちらの方向にも複数の速度について実装できる。
【００３２】
図２に示されている方法は、早戻し操作のためのストリーミングされるサブクリップの実際の数を計算するためには、ほんの少し修正する必要があるだけである。より具体的には、kはステップ２３０において、i−1からi−n*に逆向きにループされる（デクリメントされる）。
【００３３】
1＜k＜iとして、サブクリップkについての締め切りは：
【数６】
2009543439.tif 000008
のように計算できる。
【００３４】
図３は、ビデオ再生装置の概略図である。ビデオ再生操作は、ビデオ再生装置上のボタンを通じて、あるいはリモコン装置のユーザーによって作動させられるボタンを介して、あるいはたとえば声コマンドによって作動させられるソフトウェア・コマンドを介してサポートされる。ビデオ再生操作を呼び出す手段は上に示されたこれらのものに限定されない。上に示されたものは単にそのようなビデオ再生操作を呼び出す手段の例示的な実施例である。
【００３５】
図４はユーザー／クライアント側からの許可（admission）制御プロセスを描いたフローチャートである。ユーザー／クライアント側では、ひとたびクライアントがサーバーから応答を受信すると、４０５で、N（サーバーからクライアントにストリーミングされるべきサブクリップの先頭（leading）数）の値を試験することによって要請／要求が許可されたかどうかを判定する検査が行われる。Nの値が0より大きい場合には、要請／要求は許可されており、４１０で、ユーザーはストリーミングされたN個のサブクリップを受信しはじめる。サーバー側でN＝−1と設定し、ユーザー／クライアント側でN＞0かどうかを試験することは、単に一つの可能な実装でしかないことを注意しておくべきである。要求許可試験はたとえば、フラグまたは他のいかなる好適な手段によって実装されることもできる。４１５で、現在サブクリップ数NcはN＋1（次のサブクリップ−ダウンロードされるべきサブクリップ）にセットされる。４２０で、ダウンロードすべきサブクリップがもっとあるかどうかを判定する試験が実行される。要請／要求が許可されなかったか、ビデオのすべてのサブクリップがユーザーによって受信されている場合には、プロセスは終了する。一方、４２５で、(N＋1)番目のサブクリップをもっている／キャッシュしている、ピアツーピア・ネットワーク内のピアが位置特定され、(N＋1)番目のサブクリップを該(N＋1)番目のサブクリップを必要としているピアにアップロードすることを開始する。４３０においてダウンロードのための締め切りd（現在時刻tに対して測定される）に達していないと判定される場合、４３５でダウンロードが継続される。４３０で締め切りd（現在時刻tに対して測定される）に達していると判定される場合、４４０で欠失データ・ベクトルが用意される。実は、欠失データ・ベクトルは締め切りより少し前に、あるいはダウンロードが締め切りdより前に完了できないと判定されるときに用意される。ダウンロードが締め切りより前に完了できない場合、４４５で、補足的ストリーミングが必要かどうかを判定する試験が実行される。補足的ストリーミングについて以下でより詳細に述べる。一方、４５５で現在サブストリップ・カウンタがインクリメントされる。システム・パフォーマンス（ユーザーによる締め切り前におけるサブクリップの到着）が満たされることを保証するために補足的ストリーミングが要求される場合、４５０で補足的ストリーミングが呼び出される。(N＋1)番目のサブクリップをダウンロードする締め切りdに到達すると、ユーザーは(N＋1)番目のサブクリップの再生を開始し、ピアツーピア・ネットワーク内のピアで次のサブクリップをもっている／キャッシュしているピアが位置特定され、ビデオ・サブクリップ・ダウンロード・プロセスを開始する。
【００３６】
図５は、ビデオ再生装置内でのビデオ再生操作のブロック図である。ここで、操作モジュールは制御モジュールによって指揮される。制御モジュールは何らかの再生要求について、対応するビデオ再生機能／操作モジュールを呼び出す。素直な再生操作は、関係した操作の主題であるので、ここでは議論しない。
【００３７】
図６は、本発明に基づく例示的な制御モジュールの操作のフローチャートである。６０５で、制御モジュールはサブクリップの型を判定する。操作の型は６１０、６２０、６３０、６４０、６５０および６６０によって判定される。ユーザーがサポートされていない機能を呼び出そうとしてボタンを押した場合（あるいはコマンドを声に出して言った場合）、それは無視される。一連の判断点の代わりに、単一の「型による場合分け」の判断点を実装することもできる。ビデオ再生操作が前へのジャンプ（JF:  jump  forward）である場合、６１５で、ストリーミングするために必要なサブクリップの最大数の決定がなされ；ストリーミングされるべきサブクリップの実際の数の決定が、すでに完全にキャッシュされているものに基づいてなされ；TPPを含むサブクリップのストリーミングが開始され（TPPを含むサブクリップが完全にキャッシュされていない場合）；新しいサブクリップ締め切りが計算され；再生が開始され；ストリーミングされたサブクリップより先のサブクリップのダウンロードが開始される。同じ手順は後へのジャンプ操作についても適用される。
【００３８】
ビデオ再生操作が一時停止操作である場合、６３５において、ビデオ再生が停止され；ストリーミングが停止され；ダウンロードが停止され；サブクリップ締め切りが無限大にセットされる。ビデオ再生操作が再開操作である場合、６４５において、新しいサブクリップ締め切りが再生操作の結果として計算され；サブクリップ（単数または複数）がストリーミングされていた場合にはサブクリップのストリーミングを再開し；ビデオ再生を開始し；ダウンロードされるべく予定されていたサブクリップがあればそのダウンロードを再開する。
【００３９】
ビデオ再生操作が早送り操作である場合、６５５で、新しい高速化された再生レートの計算がなされ；ストリーミングするために必要なサブクリップの最大数の決定がなされ；ストリーミングされるべきサブクリップの実際の数の決定が、すでに完全にキャッシュされているものに基づいてなされ；TPPを含むサブクリップのストリーミングが開始され（TPPを含むサブクリップが完全にキャッシュされていない場合）；新しいサブクリップ締め切りが計算され；再生が開始され；ストリーミングされたサブクリップより先のサブクリップのダウンロードが開始される。ストリーミングされるサブクリップの実際の数を計算する際に式(4)の代わりに式(6)を使うほかは、同様の手順が早戻し操作についても適用される。早送りおよび早戻しはどちらも、いずれの方向でも複数の速度について実装されることができることは覚えておくべきである。
【００４０】
本発明がさまざまな形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはその組み合わせで実装されうることは理解しておくべきである。好ましくは、本発明はハードウェアとソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは好ましくはプログラム記憶デバイス上に具体的に実現されたアプリケーション・プログラムとして実装される。アプリケーション・プログラムは、いかなる好適なアーキテクチャを有する機械にアップロードされ、これにより実行されてもよい。好ましくは、機械は、一つまたは複数の中央処理ユニット（CPU）、ランダム・アクセス・メモリ（RAM）および入出力（I/O）インターフェース（単数または複数）のようなハードウェアを有するコンピュータ・プラットフォーム上で実装される。コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードをも含む。本稿で記載されたさまざまなプロセスおよび機能は、オペレーティング・システムを介して実行されるマイクロ命令コードの一部あるいはアプリケーション・プログラムの一部（またはそれらの組み合わせ）であってもよい。さらに、追加的なデータ記憶装置および印刷装置のようなさまざまな他の周辺装置がコンピュータ・プラットフォームに接続されてもよい。
【００４１】
さらに、付属の図面に描かれている構成するシステム・コンポーネントおよび方法ステップの一部が好ましくはソフトウェアで実装されるので、システム・コンポーネント（またはプロセス・ステップ）の間の実際の接続は、本発明がプログラムされる仕方に依存して変わりうることは理解しておくべきである。本稿の教示を与えられれば、当業者は本発明のこれらおよび同様の実装または構成を考えることができるであろう。
【図面の簡単な説明】
【００４２】
【図１】本発明に基づくピアツーピア・ネットワークの概略図である。
【図２】ストリーミングされるサブクリップの実際の数を計算するプロセスのフローチャートである。
【図３】ビデオ再生装置の概略図である。
【図４】ユーザー／クライアント側からの許可制御プロセスを描いたフローチャートである。
【図５】ビデオ再生装置内でのビデオ再生操作のブロック図である。
【図６】本発明に基づく例示的な制御モジュールの動作のフローチャートである。
【図１】
2009543439.tif 000009
【図２】
2009543439.tif 000010
【図３】
2009543439.tif 000011
【図４】
2009543439.tif 000012
【図５】
2009543439.tif 000013
【図６】
2009543439.tif 000014
【手続補正書】
【提出日】平成21年1月21日(2009.1.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ピアツーピアのコンテンツオンデマンド・サービスのための再生操作をサポートする方法であって：
再生操作を検出する段階と；
前記再生操作のための目標再生点を決定する段階と；
前記目標再生点がはいるサブクリップの型を検出する段階とを有する方法。
【請求項２】
ストリーミングされた先頭サブクリップを受信する段階と；
必要とされるサブクリップの組を決定する段階と；
前記組の必要とされるサブクリップのうちの一つを位置特定する段階と；
前記位置特定されたサブクリップをダウンロードする段階とを有する、請求項１記載の方法。
【請求項３】
前記ピアツーピアのコンテンツオンデマンド・サービスがパフォーマンス意識がある、請求項１記載の方法。
【請求項４】
前記再生操作が前へのジャンプの再生操作である請求項２記載の方法であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
前記目標再生点を含むサブクリップをストリーミングする段階と；
サブクリップ締め切りを計算する段階と；
再生を開始する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項５】
前記再生操作が後へのジャンプの再生操作である請求項２記載の方法であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
目標再生点を含むサブクリップをストリーミングする段階と；
目標再生点を含むサブクリップにおいて再生を開始する段階と；
サブクリップ締め切りを計算する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項６】
前記再生操作が一時停止の再生操作である請求項２記載の方法であって、さらに：
再生を停止する段階と；
サブクリップのストリーミングを停止する段階と；
サブクリップのダウンロードを停止する段階と；
サブクリップの締め切りを無限大に設定する段階とを有する、
方法。
【請求項７】
前記再生操作が再開の再生操作である請求項６記載の方法であって、さらに：
新しいサブクリップ締め切りを計算する段階と；
サブクリップがストリーミングされていた場合、サブクリップのストリーミングを再開する段階と；
再生を開始する段階と；
前記一時停止動作が呼び出されたときにダウンロードされているところだったサブクリップがあればそのサブクリップのダウンロードを再開する段階とを有する、
方法。
【請求項８】
前記再生操作が早送りの再生操作である請求項２記載の方法であって、さらに：
速められた再生レートを計算する段階と；
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
サブクリップをストリーミングする段階と；
サブクリップ締め切りを計算する段階と；
再生を開始する段階と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする段階とを有する、
方法。
【請求項９】
前記再生操作が早戻しの再生操作である請求項２記載の方法であって、さらに：
速められた再生レートを計算する段階と；
ストリーミングすべきサブクリップの最大数を決定する段階と；
ストリーミングすべきサブクリップの実際の数を決定する段階と；
サブクリップをストリーミングする段階と；
再生を開始する段階と；
サブクリップ締め切りを計算する段階と；
前記ストリーミングされたサブクリップに先行するサブクリップをダウンロードする段階とを有する、
方法。
【請求項１０】
ピアツーピアのコンテンツオンデマンド・サービスのための再生操作をサポートする装置であって：
再生操作を検出する手段と；
前記再生操作のための目標再生点を決定する手段と；
前記目標再生点がはいるサブクリップの型を検出する手段とを有する装置。
【請求項１１】
ストリーミングされた先頭サブクリップを受信する手段と；
必要とされるサブクリップの組を決定する手段と；
前記組の必要とされるサブクリップのうちの一つを位置特定する手段と；
前記位置特定されたサブクリップをダウンロードする手段とを有する、請求項１０記載の装置。
【請求項１２】
前記ピアツーピアのコンテンツオンデマンド・サービスがパフォーマンス意識がある、請求項１０記載の装置。
【請求項１３】
前記再生操作が前へのジャンプの再生操作である請求項１１記載の装置であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
前記目標再生点を含むサブクリップをストリーミングする手段と；
サブクリップ締め切りを計算する手段と；
再生を開始する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１４】
前記再生操作が後へのジャンプの再生操作である請求項１１記載の装置であって、さらに：
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
目標再生点を含むサブクリップをストリーミングする手段と；
目標再生点を含むサブクリップにおいて再生を開始する手段と；
サブクリップ締め切りを計算する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１５】
前記再生操作が一時停止の再生操作である請求項１１記載の装置であって、さらに：
再生を停止する手段と；
サブクリップのストリーミングを停止する手段と；
サブクリップのダウンロードを停止する手段と；
サブクリップの締め切りを無限大に設定する手段とを有する、
装置。
【請求項１６】
前記再生操作が再開の再生操作である請求項１５記載の装置であって、さらに：
新しいサブクリップ締め切りを計算する手段と；
サブクリップがストリーミングされていた場合、サブクリップのストリーミングを再開する手段と；
再生を開始する手段と；
前記一時停止動作が呼び出されたときにダウンロードされているところだったサブクリップがあればそのサブクリップのダウンロードを再開する手段とを有する、
装置。
【請求項１７】
前記再生操作が早送りの再生操作である請求項１１記載の装置であって、さらに：
速められた再生レートを計算する手段と；
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
サブクリップをストリーミングする手段と；
サブクリップ締め切りを計算する手段と；
再生を開始する手段と；
前記ストリーミングされたサブクリップの後続のサブクリップをダウンロードする手段とを有する、
装置。
【請求項１８】
前記再生操作が早戻しの再生操作である請求項１１記載の装置であって、さらに：
速められた再生レートを計算する手段と；
ストリーミングすべきサブクリップの最大数を決定する手段と；
ストリーミングすべきサブクリップの実際の数を決定する手段と；
サブクリップをストリーミングする手段と；
再生を開始する手段と；
サブクリップ締め切りを計算する手段と；
前記ストリーミングされたサブクリップに先行するサブクリップをダウンロードする手段とを有する、
装置。
【手続補正書】
【提出日】平成21年5月11日(2009.5.11)
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正の内容】
【０００２】
ストリーミング・サービスを提供するために、伝統的にクライアント‐サーバー・サービス・モデルが使われてきた。クライアントがサーバーに要求を送り、サーバーがそのクライアントの要求にサービスするのに十分なリソースを有し、サーバーとクライアントの間の経路に沿って十分な帯域幅があれば、サーバーが次いでコンテンツをクライアントにストリーミングする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
ピアツーピア・ストリーミング方式は、異なるデータ散布技術によっても区別される。二つのデータ散布方法が調査されている。特に、オーバーレイ・ベースのアプローチとデータ駆動のアプローチである。オーバーレイ・ベースのアプローチでは、ピアがメッシュまたはツリー構造を形成し、そこで、ピアの間に親子関係が形成される。子ピアはその親からデータを受け取る。対照的に、データ駆動アプローチにおけるピアは固定した親子関係はもたない。ピアは欠けているデータを探し、入手できるところではいつでも欠けているデータを取得する。オーバーレイ・ベースのアプローチは初期のピアツーピア努力において広く使われているが、データ駆動のアプローチはチャーン（churn）および非対称帯域幅の問題に効果的に対処するので一般的になりつつある。
【国際調査報告】
2009543439.tif 000015
2009543439.tif 000016