(57)【要約】  目標データ配信レートによる協同ファイル配布のための方法および装置が提供される。協同ファイル配布システムでは、ファイルは、少なくとも１つのファイルのための目標配信レートを取得し、信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースからファイルの少なくとも一部を取得し、信頼性の低いデータ配信レートが目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースからファイルの少なくとも一部を取得することによって提供される。１つまたは複数の信頼性の低いデータソースは、ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む。１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む。スロットル・レートは、目標配信レートを実質的に維持するように調整することができる。目標配信レートは、１つまたは複数のビジネスルールに基づいて動的に決定することができる。
2010538590.tif 000002
【特許請求の範囲】
【請求項１】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するための方法であって、
前記少なくとも１つのファイルのための目標配信レートを取得することと、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得することと、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得することと
を含む方法。
【請求項２】
前記１つまたは複数の信頼性の低いデータソースは、前記ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む、請求項１に記載の方法。
【請求項３】
前記１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む、請求項１に記載の方法。
【請求項４】
複数のサーバが、前記ファイルの様々な部分を単一のセンダに実質的に同時に提供する、請求項３に記載の方法。
【請求項５】
前記スロットル・レートは、前記信頼性の低いデータソースからデータを受信するための所望のレートである、請求項１に記載の方法。
【請求項６】
前記目標配信レートと、前記１つまたは複数の信頼性の低いデータソースからの現在の信頼性の低いデータ配信レートに基づいて、初期スロットル・レートを計算するステップをさらに含む、請求項１に記載の方法。
【請求項７】
１つまたは複数の信頼性の高いデータソースに前記ファイルの前記一部を求める要求のサイズおよびレートが、前記スロットル・レートに基づく、請求項１に記載の方法。
【請求項８】
前記スロットル・レートを動的に調整するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記スロットル・レートが、前記目標配信レートを実質的に維持するように調整される、請求項１に記載の方法。
【請求項１０】
前記スロットル・レートが、前記１つまたは複数の信頼性の高いデータソースからの飽和状態を回避するように調整される、請求項１に記載の方法。
【請求項１１】
前記飽和状態は、前記目標配信レートを達成するのに十分な期間内に要求されたデータが配信されないときに発生する、請求項１０に記載の方法。
【請求項１２】
前記目標配信レートが、１つまたは複数のビジネスルールに基づいて動的に決定される、請求項１に記載の方法。
【請求項１３】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するためのシステムであって、
メモリと、
前記メモリに結合される少なくとも１つのプロセッサであって、
前記少なくとも１つのファイルのための目標配信レートを取得し、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得し、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得する
ように動作可能な少なくとも１つのプロセッサと
を含むシステム。
【請求項１４】
前記１つまたは複数の信頼性の低いデータソースは、前記ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む、請求項１３に記載のシステム。
【請求項１５】
前記１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む、請求項１３に記載のシステム。
【請求項１６】
前記スロットル・レートは、前記信頼性の低いデータソースからデータを受信するための所望のレートである、請求項１３に記載のシステム。
【請求項１７】
前記プロセッサが、前記目標配信レートと、前記１つまたは複数の信頼性の低いデータソースからの現在の信頼性の低いデータ配信レートとに基づいて、初期スロットル・レートを計算するようにさらに構成される、請求項１３に記載のシステム。
【請求項１８】
１つまたは複数の信頼性の高いデータソースに前記ファイルの前記一部を求める要求のサイズおよびレートが、前記スロットル・レートに基づく、請求項１３に記載のシステム。
【請求項１９】
前記スロットル・レートが、前記目標配信レートを実質的に維持するように調整される、請求項１３に記載のシステム。
【請求項２０】
前記スロットル・レートが、前記１つまたは複数の信頼性の高いデータソースからの飽和状態を回避するように調整される、請求項１３に記載のシステム。
【請求項２１】
前記目標配信レートが、１つまたは複数のビジネスルールに基づいて動的に決定される、請求項１３に記載のシステム。
【請求項２２】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するための製造物品であって、実行されたときに
前記少なくとも１つのファイルのための目標配信レートを取得するステップと、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得するステップと、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得するステップと
を実施する１つまたは複数のプログラムを含む機械可読媒体を含む
製造物品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信方法およびシステムに関し、より詳細には、ユーザ間で１つまたは複数のファイルを共有するための協同的で安全な方法およびシステムに関する。
【背景技術】
【０００２】
ソフトウェア、音楽またはビデオファイルなど、人気のある大規模デジタルファイルのプロバイダは、そのようなファイルを配信するためにますます多くの帯域幅を求める要求と歩調を合わせなければならない。
【０００３】
ファイルの人気が高まるにつれて、より多くのユーザがそのファイルを要求するようになり、ファイルを配信するためにより多くの帯域幅が必要とされる。例えば、従来のハイパーテキスト転送プロトコル（ＨＴＴＰ）ファイル配信技法を用いた場合、帯域幅要求は、要求ユーザの数につれて線形に増大し、速やかに法外な費用のかかるものになる。
【０００４】
ピアツーピア・コンテンツ共有を使用してサーバにおけるファイル配信の帯域幅要求を低減するための多くの技法が提出または提案されてきた。しばしば「協同配布」と呼ばれるピアツーピア・コンテンツ共有モデルでは、サーバから１つまたは複数のファイルをダウンロードした１つまたは複数のユーザは、他のユーザとそのファイルを共有することができる。協同配布モデルは、要求ユーザの数に応じて拡大縮小される信頼性の高い方式でサーバが大規模ファイルを配信することを可能にする。利点の中でもとりわけ、協同配布モデルは、既存ユーザの十分に利用しきれていないアップストリーム帯域幅を利用する。
【０００５】
例えば、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｄｏｃｕｍｅｎｔａｔｉｏｎ．ｈｔｍｌまたはＢｒａｍ  Ｃｏｈｅｎ、「Ｉｎｃｅｎｔｉｖｅｓ  Ｂｕｉｌｄ  Ｒｏｂｕｓｔｎｅｓｓ  ｉｎ  ＢｉｔＴｏｒｒｅｎｔ」、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｂｉｔｔｏｒｒｅｎｔｅｃｏｎ．ｐｄｆ（２００３年５月２２日）において説明されている、ＢｉｔＴｏｒｒｅｎｔ（商標）ファイル配布システムは、協同配布技法の一例である。多数のユーザが、ＢｉｔＴｏｒｒｅｎｔファイル配布システムを使用して、同じ時間に同じファイルをダウンロードしている場合、様々なユーザが、そのファイルの一部を互いにアップロードしあう。言い換えると、ＢｉｔＴｏｒｒｅｎｔユーザは、完全なファイルが取得されるまで、そのユーザが有するファイルの一部を、他のユーザが有する他の必要な一部と交換する。このようにして、ファイルをアップロードするコストは、ファイルのユーザに再配分され、人気のあるファイルをホストするコストは、より手ごろなものになる。加えて、２００５年３月３１日に出願された「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｏｆｆｌｉｎｅ  Ｃｏｏｐｅｒａｔｉｖｅ  Ｆｉｌｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｕｓｉｎｇ  Ｃａｃｈｅ  Ｎｏｄｅｓ」と題する米国特許出願第１１／０９６，１９３号は、ユーザ間で転送されるファイルを保存するために１つまたは複数のストレージプロキシを使用する、協同ファイル配布システムを開示している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許出願第１１／０９６，１９３号
【特許文献２】米国特許出願第１１／０９６，１９４号
【特許文献３】米国特許出願第１１／１５０，５３２号
【特許文献４】米国特許出願第１１／１７１，７４８号
【特許文献５】米国特許出願第１１／５１９，９９０号
【非特許文献】
【０００７】
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｄｏｃｕｍｅｎｔａｔｉｏｎ．ｈｔｍｌ
【非特許文献２】Ｂｒａｍ  Ｃｏｈｅｎ、「Ｉｎｃｅｎｔｉｖｅｓ  Ｂｕｉｌｄ  Ｒｏｂｕｓｔｎｅｓｓ  ｉｎ  ＢｉｔＴｏｒｒｅｎｔ」、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｂｉｔｔｏｒｒｅｎｔｅｃｏｎ．ｐｄｆ（２００３年５月２２日）
【非特許文献３】ＢｉｔＴｏｒｒｅｎｔ  Ｐｒｏｔｏｃｏｌ、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌ
【非特許文献４】ＢｉｔＴｏｒｒｅｎｔ  Ｇｕｉｄｅ、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｇｕｉｄｅ．ｈｔｍｌ
【発明の概要】
【発明が解決しようとする課題】
【０００８】
そのような協同ファイル配布システムは、コスト対効果に優れた方式で大規模ファイルを配布するための効率的なメカニズムを提供するが、多くの制限を課されており、それが克服されれば、協同ファイル配布の有用性および効率をさらに高めることができる。特に、所望のデータ配信レートなど、所望のサービス品質を保証することが難しい。したがって、目標データ配信レートを満たすことができる、改良された協同ファイル配布システムが必要とされている。また別に、ウェブサーバなどのより信頼性の高いデータソースを用いてピアツーピア・コンテンツ共有を補足する、協同ファイル配布システムが必要とされている。
【課題を解決するための手段】
【０００９】
一般に、目標データ配信レートによる協同ファイル配布のための方法および装置が提供される。本発明の一態様によれば、協同ファイル配布システムにおいて、少なくとも１つのファイルが提供される。例示的な方法は、少なくとも１つのファイルのための目標配信レートを取得するステップと、信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースからファイルの少なくとも一部を取得するステップと、信頼性の低いデータ配信レートが目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースからファイルの少なくとも一部を取得するステップとを含む。１つまたは複数の信頼性の低いデータソースは、ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む。１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む。
【００１０】
スロットル・レートは、信頼性の低いデータソースからデータを受信するための所望のレートとすることができる。一実施形態では、初期スロットル・レートは、目標配信レートと、１つまたは複数の信頼性の低いデータソースからの現在の信頼性の低いデータ配信レートとに基づいて計算される。信頼性の高いデータソースにファイルの一部を求める要求のサイズおよび／またはレートは、スロットル・レートに基づくことができる。スロットル・レートは、目標配信レートを実質的に維持するように調整することができる。加えて、スロットル・レートは、１つまたは複数の信頼性の高いデータソースからの飽和状態を回避するように調整することができる。目標配信レートは、１つまたは複数のビジネスルールに基づいて動的に決定することができる。
【００１１】
本発明ならびに本発明のさらなる特徴および利点のより完全な理解は、以下の詳細な説明および図面を参照することによって得られる。
【図面の簡単な説明】
【００１２】
【図１】本発明が動作できるネットワーク環境を示す図である。
【図２】本発明の特徴を含む制御サーバの例示的な一実施の概要ブロック図である。
【図３】図１のレシーバの例示的な一実施の概要ブロック図である。
【図４】図２の目標配信レート・ルールベース（ｔａｒｇｅｔ  ｄｅｌｉｖｅｒｙ  ｒａｔｅ  ｒｕｌｅｂａｓｅ）の例示的な一実施からのサンプルテーブルである。
【図５】図２の目標レート決定プロセスのための例示的な疑似コードを示す図である。
【図６】図３の目標配信レート維持プロセスのための例示的な疑似コードを示す図である。
【図７】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図８】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図９】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１０】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１１】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１２】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１３】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１４】本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオの１つを示す図である。
【図１５】本発明の協同ファイル共有システムにおいてコンテンツをダウンロードするために図１の様々なエンティティによって実行される例示的な通信および他の処理を示す、ＵＭＬ記法による通信シーケンス図である。
【発明を実施するための形態】
【００１３】
本発明は、目標データ配信レートによる協同ファイル配布のための方法および装置を提供する。本発明の一態様によれば、ピアツーピア・コンテンツ共有は、例えばＨＴＴＰプロトコルを使用してデータを配信するウェブサーバまたはコンテンツ配信ネットワーク（ＣＤＮ：ｃｏｎｔｅｎｔ  ｄｅｌｉｖｅｒｙ  ｎｅｔｗｏｒｋ）などの、１つまたは複数の信頼性の高いデータソースからのデータで補足される。このようにして、目標データ配信レートを達成することができる。本発明のさらなる態様によれば、非常に高いデータレートでデータを提供できる信頼性の高いデータソース（例えばＣＤＮ）にデータを要求する、帯域幅目標アルゴリズムが開示される。一般に、このアルゴリズムは、ピアツーピア・データ配信レートを低減させることなく、目標配信レートを達成するために必要とされるだけの量のデータを要求する。このようにして、本発明の様々な実施形態は、より低コストの信頼性の低いデータソースの利用を最大化し、信頼性の高いデータソースの利用を最小化する。
【００１４】
本発明のさらなる態様によれば、目標ビットレートは、例えば、受け手のサービスクラス、発行者のサービスクラス、コンテンツ（例えば、ビデオ符号化ビットレートに一致させる）、ユーザ・アクティビティ（例えば、ユーザがビデオを見ている場合は必要とされる速さでデータを配信し、またはユーザがビデオを見ていない場合はより低い速度で効率的により多くのデータを配信する）、および他のビジネスルール（例えば、コンテンツがリリースされた直後の最初の１週間はより高い目標ビットレート、その後の「ロングテール」配信はより低いビットレート）に基づいて、動的に決定することができる。本発明の別の態様によれば、複数のウェブサーバが、与えられたファイルの様々な部分を単一のセンダに実質的に同時に提供する。
【００１５】
図１は、本発明が動作できるネットワーク環境を示している。図１に示されるように、図３に関連して以下でさらに説明されるレシーバ３００に１つまたは複数のファイルを送信することを望むセンダ１１０は、協同ファイル配布システム１００を使用する。協同ファイル配布システム１００は、本発明の特徴および機能を提供するように本明細書において変更された、例えばＢｉｔＴｏｒｒｅｎｔもしくはＰａｎｄｏファイル配布システム（またはそれらの組合せ）を使用して実施することができる。ＢｉｔＴｏｒｒｅｎｔファイル配布システムについてのより詳細な説明は、例えば、ＢｉｔＴｏｒｒｅｎｔ  Ｐｒｏｔｏｃｏｌ、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌまたはＢｉｔＴｏｒｒｅｎｔ  Ｇｕｉｄｅ、ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｃｏｍ／ｇｕｉｄｅ．ｈｔｍｌを参照されたく、その各々は参照により本明細書に組み込まれる。Ｐａｎｄｏファイル配布システムは、Ｐａｎｄｏ  Ｕｓｅｒｓ’  Ｇｕｉｄｅ（ｗｗｗ．ｐａｎｄｏ．ｃｏｍ／ｈｅｌｐ）で説明されている、Ｐａｎｄｏ  Ｐｌａｔｆｏｒｍ  １．７．１．０（ｗｗｗ．ｐａｎｄｏ．ｃｏｍ／ｄｏｗｎｌｏａｄからダウンロード可能）を使用して実施することができ、その各々は参照により本明細書に組み込まれる。代替システムは、ｅＤｏｎｋｅｙおよびＧｎｕｔｅｌｌａを含む。
【００１６】
本明細書で後ほど説明されるように、協同ファイル配布システム１００は、本発明の特徴および機能を提供するように本明細書において変更された、ＢｉｔＴｏｒｒｅｎｔファイル配布システムのトラッカを使用して実施できるトラッカ２００を含む。加えて、協同ファイル配布システム１００は、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｏｆｆｌｉｎｅ  Ｃｏｏｐｅｒａｔｉｖｅ  Ｆｉｌｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｕｓｉｎｇ  Ｃａｃｈｅ  Ｎｏｄｅｓ」と題する米国特許出願第１１／０９６，１９３号で説明されるような、１つまたは複数のストレージプロキシ１２０を任意選択的に利用する。
【００１７】
しばしば「協同配布」と呼ばれるピアツーピア・コンテンツ共有モデルでは、サーバからファイルをダウンロードしたしばしばスウォーム１３０と呼ばれる１つまたは複数のユーザは、レシーバ３００などの他のユーザとファイルを共有することができる。先に指摘されたように、本発明は、センダ１１０およびスウォーム１３０などの１つまたは複数の信頼性の低いデータソース１４０からのピアツーピア・コンテンツ共有を、例えばＨＴＴＰプロトコルを使用してデータを配信するウェブサーバまたはコンテンツ配信ネットワーク（ＣＤＮ）などの１つまたは複数の信頼性の高いデータソース１５０からのデータで補足する。
【００１８】
図２は、制御サーバ２００の例示的な一実施の概略ブロック図である。図２ではもっぱら単一のサーバとして示されているが、制御サーバ２００は、任意選択的に、別個のトラッカ、サービス、およびデータベースなど、多くの異なるサーバとして実施することができる。例えば、２００５年９月１２日に出願された「Ｓｅｃｕｒｉｔｙ  Ｔｅｃｈｎｉｑｕｅｓ  ｆｏｒ  Ｃｏｏｐｅｒａｔｉｖｅ  Ｆｉｌｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ」と題する米国特許出願第１１／５１９，９９０号を参照されたい。
【００１９】
図２に示され、図４および図５にそれぞれ関連して以下でさらに説明されるように、例示的な制御サーバ２００は、目標配信レート・ルールベース４００と、目標レート決定プロセス５００を含む。一般に、目標レート決定プロセス５００は、目標配信レート・ルールベース４００内の１つまたは複数の例示的なビジネスルールに基づいて、クライアントのために初期目標レートを動的に決定する。ビジネスルールは、例えば、受け手のサービスクラス、発行者のサービスクラス、コンテンツ（例えば、ビデオ符号化ビットレートに一致させる）、およびユーザ・アクティビティ（例えば、ユーザがビデオを見ている場合は必要とされる速さでデータを配信し、またはユーザがビデオを見ていない場合はより低い速度で効率的により多くのデータを配信する）のうちの１つまたは複数に基づくことができる。
【００２０】
図３は、図１のレシーバ３００の例示的な一実施の概略ブロック図である。図３に示され、図６および図１５にそれぞれ関連して以下でさらに説明されるように、例示的なレシーバ（クライアント）３００は、目標配信レート維持プロセス６００と、ダウンロードプロセス１５００を含む。一般に、クライアント３００は、（制御サーバ２００から受信した）目標レートと、１つまたは複数の信頼性の低いデータソース１４０からのクライアントの現在のレートに基づいて目標配信レートを計算するために、例示的な目標配信レート維持プロセス６００を実施する。その後、目標配信レート維持プロセス６００は、与えられた目標レートに一致させようとしてスロットル・レートを変更する。その後、変更されたスロットル・レートは、ファイルの一部を求めるＨＴＴＰ要求のサイズおよびレートを決定するために、クライアント３００によって使用される。
【００２１】
図４は、目標配信レート・ルールベース４００の例示的な一実施からのサンプルテーブルである。図４に示されるように、例示的な目標配信レート・ルールベース４００は、ファイルの初期目標レートを決定する多くのビジネスルールを含む。例えば、図４に示されるように、例示的なルール４１０は、発行者が目標データ配信レートをビデオストリームの符号化ビットレートに一致するように設定することを可能にする。このようにして、発行者に金を浪費させる（すなわちＣＤＮを使用して必要とされるよりも速いビットレートで配信を行わせる）ことなく、ユーザはスムーズな再生（すなわち十分なデータ）を得る。
【００２２】
ルール４２０は、発行者が発行後に目標データ配信レートを設定することを可能にする。例えば、発行者は、すべてのファイルを発行することができ、その後、立ち返って、既存スウォーム１３０の現実のビデオ再生性能に基づいて、目標ビットレートを設定することができる。例えば、再生が調和の欠けたものである場合、コンテンツを再発行することなく、再生がスムーズになるまで目標配信レートを引き上げることができる。
【００２３】
ルール４３０は、発行者が「ホット」コンテンツに対してはより高い性能目標を設定し、「カタログ」コンテンツに対してはより低い性能目標を設定することを可能にする。コンテンツは、旧作化、売上率、および販売促進など、よく知られたビジネスルールに基づいて、「ホット」特性付けと「カタログ」特性付けの間を動的に移動することができる。
【００２４】
ルール４４０は、発行者がコンテンツ価格に基づいて性能目標を設定することを可能にする。例えば、プレミアム・コンテンツには、より速い／より高い配信コストを割り当てることができ、ディスカウント・コンテンツには、より遅い／より低い配信コストを割り当てることができる。同様に、ルール４５０は、プレミアム・メンバシップを有するダウンローダが非会員よりも速いダウンロードを得ることを可能にする。例えば、無料サービス会員は、５０ＫＢｐｓの目標配信レートで受信することができ、一方、有料会員は、１５０ＫＢｐｓの目標配信レートで受信することができる。
【００２５】
ルール４６０は、発行できる目標レートを発行者のサービスクラスが制限することを可能にする。例えば、特定のビデオが１Ｍｂｐｓで符号化でき、１Ｍｂｐｓの目標レート用に構成できるのに、そのビデオがディスカウント発行者アカウントによって発行されたならば、クライアントのダウンロード目標は、５００Ｋｂｐｓに制限されることがある。発行者がアカウントをアップグレードした場合、そのビデオの目標レートを動的に１Ｍｂｐｓに引き上げることができる。
【００２６】
ルール４７０は、多数のビジネスルールを調整し、またはそれらに優先順位を付けることを可能にする。例えば、発行者が５００Ｋｂｐｓに制限されたディスカウント発行アカウントを使用してビデオ用に１Ｍｂｐｓの目標レートを要求した場合であっても、ダウンローダがたまたまプレミアム会員であるならば、そのダウンローダは依然として、５００Ｋｂｐｓのレートの代わりに１Ｍｂｐｓのレートで受信することができる。
【００２７】
図４に示された例示的な目標配信レート・ルールベース４００はサーバ側のビジネスルールを示しているが、１つまたは複数のクライアント側のビジネスルール（すなわち目標を達成したとクライアントが決定するかどうか）を利用することもできる。例えば、ダウンロードが自動的であり、ユーザが見ていない場合（例えば夜間のＲＳＳダウンロード）、配信効率を最大化するために、クライアント３００は、サーバが指図する目標の代わりに、最小性能目標（例えば１ＫＢ／ｓまたはサーバによって提供される別のレート）を目標に設定する。サーバは、（能動的使用または自動的使用など）様々なユーザ状態に対して様々な性能目標配信レートを提供することもできる。
【００２８】
図５は、図２の目標レート決定プロセス５００の例示的な疑似コードを示している。図５に示されるように、例示的な目標レート決定プロセス５００は、最初にステップ５１０において、与えられたファイルを送信するよう求める要求を受信する。その後、ステップ５２０において、目標レート決定プロセス５００は、目標配信レート・ルールベース４００にアクセスして、要求されたファイルの目標レートを動的に決定する。最後にステップ５３０において、必要に応じて信頼性の高いデータソースとともに使用するために、決定された目標レートが、適切なクライアントに提供される。
【００２９】
図６は、図３の目標配信レート維持プロセス６００の例示的な疑似コードを示している。一般に、クライアント３００は、（制御サーバ２００から受信した）目標レートと、１つまたは複数の信頼性の低いデータソース１４０からのクライアントの現在のレートに基づいて初期スロットル・レートを計算するために、例示的な目標配信レート維持プロセス６００を実施する。その後、目標配信レート維持プロセス６００は、与えられた目標レートに一致させようとしてスロットル・レートを変更する。その後、変更されたスロットル・レートは、ファイルの一部を求めるＨＴＴＰ要求のサイズおよびレートを決定するために、クライアント３００によって使用される。
【００３０】
図６に示されるように、例示的な目標配信レート維持プロセス６００は、最初にステップ６１０において、制御サーバ２００によって設定された目標レートに基づいて、初期「スロットル・レート」（すなわち信頼性の高いソースからデータを受信するための所望のレート）を選択する。例えば、そのレートは、目標レートからスウォーム１３０の配信レートを引いたレートに設定することができる。
【００３１】
その後、ステップ６１５において、信頼性の高いソースからブロックが到着するたびに、ステップ６２０〜ステップ６３５が実行される。ステップ６２０において、目標レートと測定された総配信レートの間の差として、「デルタ目標」値が計算される。
【００３２】
ステップ６２５において、スロットル・レートと（信頼性の高いソースに要求されたバイトの数、要求の開始時間、および要求の終了時間に基づいた）実際の信頼性の高い配信レートの間の差として、「デルタ飽和」値が計算される。
【００３３】
ステップ６３０において、「デルタ目標」値と「デルタ飽和」値のうちの小さいほうが選択される。最後にステップ６３５において、スロットル・レートがしかるべく調整される。例えば、選択されたデルタ値が負の場合、スロットル・レートは高く設定されすぎている（例えば、利用可能な帯域幅が飽和しているか、またはデータが目標レートよりも速く送られている）。同様に、選択されたデルタ値が正の場合、スロットル・レートは低すぎる。
【００３４】
加えて、ステップ６４０は、かなり長い間隔を置いて実行される。ステップ６４０において、総配信レートが目標レートを下回り、スロットル・レートがゼロであるかまたはゼロに近い場合、スロットル・レートが僅かに引き上げられる。上記の計算（ステップ６２０〜ステップ６３５）はブロックが到着した場合だけ実行されるので、ステップ６４０は、アルゴリズム６００が信頼性の高いソースを永久に塞ぐことがないようにする。ステップ６４０においてチェックが実行される頻度は、レート測定が実行される期間に基づく。例示的な一実施では、測定期間は、現在のところ２０秒であり、ステップ６４０におけるチェックは、１０秒おきに実行される。さらなる変形では、ステップ６４０におけるチェックは、総配信レートがある量だけ低下するたびに実行することができる。
【００３５】
ステップ６３５において、スロットル・レートは、例えば、選択されたデルタのある比率をスロットル・レートに加算することによって調整することができる。例示的な一実施では、新しいスロットル・レートは、以下のように計算される。
新しいスロットル・レート＝０．８×デルタ＋旧いスロットル・レート
さらなる変形では、スロットル・レートは、例えば、デルタの他の比率、デルタの積分、およびデルタの微分に基づいて調整することができる。
【００３６】
図７から図１４は、本発明に従って目標レートを調整するときに遭遇する可能性のある様々な例示的なシナリオを示している。図７のシナリオでは、（ピアツーピアなど）信頼性の低いデータソース１４０からのデータ配信レートは、指定された目標配信レートを超えている。したがって、信頼性の高いデータソース１５０からのデータは必要とされない。
【００３７】
図８では、（ピアツーピアなど）信頼性の低いデータソース１４０からのデータ配信レートは、目標データ配信レートよりも小さいが、信頼性の高いデータソース１５０への要求を使用して目標レートに達するために利用可能なクライアント帯域幅が十分に存在する。図８の例では、目標配信レート維持プロセス６００は、一定のデータサイズを有するデータブロックを求めるデータ要求を繰り返して発行するが、要求タイミングは様々である。当業者に明らかなように、ブロックサイズも様々とし得ること、または要求時間は一定に保ち得ることに留意されたい。
【００３８】
図８に示されるように、要求されるデータの量（Ｂ）および次の要求のタイミング（「要求期間」）は、信頼性の低いデータソース１４０からの現在のデータ配信レートと現在の目標データ配信レートの間の面積を「Ｂ」の面積が満たすように計算される。要求が発行された場合、要求は目標レートよりも迅速に満たされ（面積Ａ）、次の要求の前により低い速度でデータ配信が行われるギャップを残す。その結果、平均データ配信レートは、近似的に目標データ配信レートになる。信頼性の低いデータソース１４０からのデータ配信レートは時間とともに変化することができ、一定の平均データ配信レートを維持するために要求期間が変化する原因となることに留意されたい。図８では、信頼性の高いデータソース１５０からの追加的なデータ配信は「ＨＴＴＰデータ配信」と標記されているが、追加的なデータは任意のデータソースから任意のプロトコルを介して送信できることにさらに留意されたい。
【００３９】
図９は、利用可能な帯域幅の変化の影響を示している。ファイル転送用に利用可能な帯域幅は、例えば、コンピュータ上の別のアプリケーション、または共用ネットワーク上の別のコンピュータ上の別のアプリケーション、またはネットワーク環境の変化のせいで低下することがある。この帯域幅低下の影響は、信頼性の高いデータソース１５０へのＨＴＴＰ要求が、「面積」を変化させずに「より短くより幅広く」なることであり、これは同じ平均データレートで送信されることを意味する。
【００４０】
図１０は、目標データ配信レートを満たすには利用可能な帯域幅が不十分であるシナリオを示している。図１０は、配信できるよりも多くのデータを要求しようとした場合の影響を示している。図１０では、クライアント３００は、データ（Ａ２、Ｂ２、Ｃ２、Ｄ２、Ｅ２）を配信できるよりも迅速にＨＴＴＰ要求（Ａ、Ｂ、Ｃ、Ｄ、Ｅ）を発行している。したがって、信頼性の高いデータソース１５０からのＨＴＴＰデータが、スウォーム１３０からのピアツーピア・データに取って代わり、信頼性の低いデータソース１４０からのデータ配信レートを実質的に引き下げる。
【００４１】
図１１のシナリオでは、目標データ配信レートは、やはり利用可能な帯域幅よりも高い。アルゴリズム６００は、新しい変数である「所望」データ配信レートを導入する。所望データ配信レートは、最初は目標配信レートと同じであるが、コネクションが飽和していることをアルゴリズム６００が検出した場合、所望データ配信レートは、コネクションがもはや飽和していなくなるまで低下し、コネクションが利用可能な帯域幅を有する場合、目標レートが達成されるか、またはコネクションが飽和するまで上昇する。
【００４２】
アルゴリズム６００は、例えば、実際のＨＴＴＰ配信が次のＨＴＴＰ配信の所望開始時間の後に完了し、コネクションが要求されたデータを要求された期間内に配信できず、目標データ配信レートを達成できなかったことを示している場合に、コネクションが飽和していることを検出する。例えば、第２の要求（Ｂ２）がスケジュールされたとき（Ｂ）に発行できず、第３の要求（Ｃ２）がスケジュールされたとき（Ｃ）に発行できない場合、これは、所望データ配信レートを低下させる原因になる。所望配信レートが低下するので、要求期間は、最終的に要求期間が各要求を満たすのに必要とされる時間よりも僅かに長くなるまで長くなり、実際の要求時間（Ｄ２、Ｅ２）が、要求（Ｄ、Ｅ）によって満足されることを可能にする。
【００４３】
図１２は、アルゴリズム６００が利用可能な帯域幅の低下に適合して、利用可能な帯域幅を目標より低くさせるシナリオを示している。これは、例えば、ネットワーク環境の変化、またはネットワークリソースを消費するコンピュータ上の別のアプリケーションによって引き起こされることがある。スウォーム１３０からのデータ配信は、利用可能な帯域幅の低下後に引き出される第１のブロックだけに影響を与えるにすぎないことに留意されたい。アルゴリズム６００が適合されると、スウォーム１３０からのピアツーピア配信は、信頼性の高いデータソース１５０からのＨＴＴＰ配信から受ける影響を最低限にとどめて、継続することができる。
【００４４】
図１３は、アルゴリズム６００が利用可能な帯域幅の上昇に適合するシナリオを示している。所望データ配信レートが次第に上昇することに留意されたい。したがって、実際の配信レートの平均は、利用可能な帯域幅の上昇後にダウンロードされる最初の数ファイル部分については、目標よりもいくらか低いことがある。
【００４５】
図１４は、動的に変換する状況に適合するアルゴリズム６００を示している。図１４に示されるように、初期状況は、アルゴリズムが、ＨＴＴＰを介していくつかのデータを信頼性の高いデータソース１５０に要求することによって、目標データ配信レートを満たすことを可能にしている。その後、時間（１）において、利用可能な帯域幅が低下し、コネクションの飽和を引き起こす。アルゴリズム６００は、より僅かなデータを要求することによって適合し、スウォーム１３０からのピアツーピア・データ配信が回復することを可能にする。その後、時間（２）において、利用可能な帯域幅が回復し、転送が目標データ配信レートを達成することを可能にする。最後に、時間（３）において、信頼性の低いデータソース１４０からのデータ配信レートが上昇し、そのため、アルゴリズム６００は、ＨＴＴＰを介してデータを信頼性の高いデータソース１５０に要求することを停止する。
【００４６】
図１５は、協同ファイル共有システム１００においてコンテンツをダウンロードするために図１の様々なエンティティによって実行される例示的な通信および他の処理を示す、ＵＭＬ記法による通信シーケンス図１５００である。上で指摘されたように、図２ではもっぱら単一のサーバとして示されているが、制御サーバ２００は、任意選択的に、図１５に示されるように、別個のトラッカ２００Ａ、サービス２００Ｂ、およびデータベース２００Ｃなど、多くの異なるサーバとして実施することができる。
【００４７】
図１５に示されるように、ダウンロードプロセス１５００は、レシーバ３００とサービスプロセッサ２００Ｂの間のセッション開始メッセージ交換１５５０を使用して開始される。レシーバ３００は、任意選択的にノード識別子を提供し、サービスプロセッサ２００Ｂは、レシーバ３００が所望のファイルを受信するための適切な許可を有しているかどうかを判定する。レシーバ３００が承認されている場合、レシーバ３００は、例えば、セッション識別子と、レシーバノードが検証された旨の通知を含む、「セッション開始結果」メッセージを受信する。一実施では、サービスプロセッサ２００Ｂは、認証およびデータベースアクセスを制御することができる。
【００４８】
レシーバ３００がメッセージ交換１５５０によって確認された後、レシーバ３００は、メッセージ交換１５５５を使用してダウンロードを開始しようと試みる。一般に、レシーバ３００は、「ダウンロード開始」メッセージをサービスプロセッサ２００Ｂに送信する。（存在する場合に）所望のファイルに関連する信頼性の高いデータソース１５０を識別すると、サービスプロセッサ２００Ｂは、その情報をデータベース２００Ｃに保存し、その結果を、割り当てられたトラッカ２００Ａの識別情報、トークン、および決定された目標配信レートとともに、レシーバ３００に提供する。一般に、トラッカ・トークンは、さらなるデータベースアクセスを必要とせずに、トラッカ２００Ａのアクセスおよび使用を制御するために任意選択的に使用される。トークンは、トラッカ２００Ａによって暗号解除できる鍵である。情報の中でもとりわけ、トークンは、最終ｔｏｒｒｅｎｔ更新時間を含む。レシーバは、ＨＴＴＰ  ＵＲＬなどによって、信頼性の高いデータソースのアドレスを任意選択的に提供される。一実施では、ＨＴＴＰ  ＵＲＬは、ＤＳｔａｒｔメッセージに応答して提供され、トラッカ応答では提供されない。さらなる変形では、信頼性の高いデータソースのアドレスは、他の通信メカニズムで提供（例えば、Ｐａｎｄｏファイルに符号化、ＤＳｔａｒｔ応答で送信、トラッカによって送信）することができる。
【００４９】
レシーバ３００は、ｂｉｔ  ｔｏｒｒｅｎｔに割り当てられたトラッカ２００Ａを通知された後、レシーバ３００は、メッセージ交換１５６０において、トラッカ２００Ａに自らを告知する。図１５に示されるように、レシーバ３００は、告知メッセージをトラッカ２００Ａに送信する。告知メッセージは、トラッカ２００Ａがレシーバ３００を確認することを可能にする割り当てられたトークンを含む。告知メッセージは、告知間隔計算プロセスを実行するためにトラッカ２００Ａをトリガする。加えて、トークンに含まれるｔｏｒｒｅｎｔ更新時間に基づいて、トラッカ２００Ａは、メッセージ交換１５６５においてｔｏｒｒｅｎｔ識別子を使用してｔｏｒｒｅｎｔ情報を取得（更新）するために、サービスプロセッサ２００Ｂと通信する必要があることがある。
【００５０】
告知間隔計算プロセスを実施した後、トラッカ２００Ａは、告知応答をレシーバ３００に送信する。告知応答は、（信頼性の低いデータソース１４０および信頼性の高いデータソース１５０など）ファイルに関連するストレージプロキシ１２０およびセンダ１１０のリストならびに割り当てられた告知間隔を含む。
【００５１】
メッセージ交換１５７０において、レシーバ３００は、センダ１１０またはスウォーム１３０などの信頼性の低いデータソース１４０からファイルをダウンロードしようと試みる。同様に、目標データレートを維持する必要がある場合、レシーバ３００は、目標配信レート維持プロセス６００によって決定されたスロットル・レートに基づいて、ウェブサーバまたはストレージプロキシなどの信頼性の高いデータソース１５０からファイルの一部をダウンロードすることができる。その後、メッセージ交換１５７５において、レシーバ３００は、ダウンロードが完了したことをサービスプロセッサ２００Ｂに通知する。最後に、メッセージ交換１５８０において、レシーバ３００とサービスプロセッサ２００Ｂの間のセッションが終了する。
【００５２】
システムおよび製造物品の詳細
当技術分野で知られているように、本明細書で説明された方法および装置は、コンピュータ可読コード手段がその上に具現されたコンピュータ可読媒体をそれ自体が含む製造物品として分散することができる。コンピュータ可読プログラムコード手段は、本明細書で説明された方法を実行するためのステップの全部もしくは一部を実施するように、または本明細書で説明された装置を作成するようにコンピュータシステムと連携して動作可能である。コンピュータ可読媒体は、記録可能な媒体（例えば、フロッピディスク、ハードドライブ、コンパクトディスク、またはメモリカード）とすることができ、あるいは伝送媒体（例えば、光ファイバ、ワールドワイドウェブ、ケーブル、または時分割多元接続、符号分割多元接続、もしくは他の無線周波数チャネルを使用するワイヤレスチャネルを含むネットワーク）とすることができる。コンピュータシステムとともに使用するのに適した、情報を保存できる既知または開発中の任意の媒体を使用することができる。コンピュータ可読コード手段は、磁気媒体上の磁気変化またはコンパクトディスクの面上の高さ変化など、コンピュータが命令およびデータを読み取ることを可能にする任意のメカニズムである。
【００５３】
本明細書で説明されたコンピュータシステムおよびサーバは各々、本明細書で開示された方法、ステップ、および機能を実施するように関連プロセッサを構成するメモリを含む。メモリは、分散型または局所型とすることができ、プロセッサは、分散型または単独型とすることができる。メモリは、電気、磁気、もしくは光メモリ、またはこれらもしくは他のタイプのストレージデバイスの任意の組合せとして実施することができる。さらに、「メモリ」という用語は、関連プロセッサによってアクセスされるアドレス可能空間内のアドレスから読み取り、またはアドレスに書き込むことができる任意の情報を包含するように十分に広く解釈されるべきである。この定義を用いた場合、関連プロセッサはネットワークから情報を引き出すことができるので、ネットワーク上の情報もやはりメモリ内に存在する。
【００５４】
本明細書で示され説明された実施形態および変形は、本発明の原理を例示するものにすぎないこと、また本発明の範囲および主旨から逸脱することなく、様々な変更が当業者によって実施できることを理解されたい。
【図１】
2010538590.tif 000003
【図２】
2010538590.tif 000004
【図３】
2010538590.tif 000005
【図４】
2010538590.tif 000006
【図５】
2010538590.tif 000007
【図６】
2010538590.tif 000008
【図７】
2010538590.tif 000009
【図８】
2010538590.tif 000010
【図９】
2010538590.tif 000011
【図１０】
2010538590.tif 000012
【図１１】
2010538590.tif 000013
【図１２】
2010538590.tif 000014
【図１３】
2010538590.tif 000015
【図１４】
2010538590.tif 000016
【図１５】
2010538590.tif 000017
【手続補正書】
【提出日】平成22年5月20日(2010.5.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するための方法であって、
前記少なくとも１つのファイルのための目標配信レートを取得することと、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得することと、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得することと
を含む方法。
【請求項２】
前記１つまたは複数の信頼性の低いデータソースは、前記ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む、請求項１に記載の方法。
【請求項３】
前記１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む、請求項１に記載の方法。
【請求項４】
前記スロットル・レートは、前記信頼性の低いデータソースからデータを受信するための所望のレートである、請求項１に記載の方法。
【請求項５】
前記目標配信レートと、前記１つまたは複数の信頼性の低いデータソースからの現在の信頼性の低いデータ配信レートに基づいて、初期スロットル・レートを計算するステップをさらに含む、請求項１に記載の方法。
【請求項６】
１つまたは複数の信頼性の高いデータソースに前記ファイルの前記一部を求める要求のサイズおよびレートが、前記スロットル・レートに基づく、請求項１に記載の方法。
【請求項７】
前記スロットル・レートを動的に調整するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記スロットル・レートが、前記目標配信レートを実質的に維持するように、または前記１つまたは複数の信頼性の高いデータソースからの飽和状態を回避するように調整される、請求項１に記載の方法。
【請求項９】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するためのシステムであって、
メモリと、
前記メモリに結合される少なくとも１つのプロセッサであって、
前記少なくとも１つのファイルのための目標配信レートを取得し、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得し、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得する
ように動作可能な少なくとも１つのプロセッサと
を含むシステム。
【請求項１０】
前記１つまたは複数の信頼性の低いデータソースは、前記ファイルのセンダおよび１つもしくは複数のピアのうちの１つまたは複数を含む、請求項９に記載のシステム。
【請求項１１】
前記１つまたは複数の信頼性の高いデータソースは、１つもしくは複数のウェブサーバおよび１つもしくは複数のストレージプロキシのうちの１つまたは複数を含む、請求項９に記載のシステム。
【請求項１２】
前記プロセッサが、前記目標配信レートと、前記１つまたは複数の信頼性の低いデータソースからの現在の信頼性の低いデータ配信レートとに基づいて、初期スロットル・レートを計算するようにさらに構成される、請求項９に記載のシステム。
【請求項１３】
１つまたは複数の信頼性の高いデータソースに前記ファイルの前記一部を求める要求のサイズおよびレートが、前記スロットル・レートに基づく、請求項９に記載のシステム。
【請求項１４】
前記スロットル・レートが、前記目標配信レートを実質的に維持するように、または前記１つまたは複数の信頼性の高いデータソースからの飽和状態を回避するように調整される、請求項９に記載のシステム。
【請求項１５】
協同ファイル配布システムにおいて少なくとも１つのファイルを取得するための製造物品であって、実行されたときに
前記少なくとも１つのファイルのための目標配信レートを取得するステップと、
信頼性の低いデータ配信レートで１つまたは複数の信頼性の低いデータソースから前記ファイルの少なくとも一部を取得するステップと、
前記信頼性の低いデータ配信レートが前記目標配信レートを下回った場合、スロットル・レートに基づいて１つまたは複数の信頼性の高いデータソースから前記ファイルの少なくとも一部を取得するステップと
を実施する１つまたは複数のプログラムを含む機械可読媒体を含む
製造物品。
【国際調査報告】
2010538590.tif 000018
2010538590.tif 000019
2010538590.tif 000020