(57)【特許請求の範囲】
【請求項１】
パケット交換方式のネットワークを通じてクライアントにコンテンツファイルを配信するための方法であって、
前記クライアントに前記コンテンツファイルを配信するのに必要とされる適切なスループットである必要なスループットを決定するステップと、
前記クライアントに前記コンテンツファイルを配信するために、ピアツーピアファイル転送モデルを利用するピアツーピアネットワークにおいて利用可能なスループットを決定するステップと、
前記必要なスループットを前記利用可能なスループットと比較するステップと、
前記利用可能なスループットが前記必要なスループットより小さい場合、前記利用可能なスループットを、クライアント−サーバファイル転送モデルを利用するコンテンツ配信ネットワークによって提供される追加のスループットで補完するステップと、
前記ピアツーピアネットワークの前記利用可能なスループットと追加のスループットとを用いて、前記コンテンツファイルの一部を前記ピアツーピアネットワークを通じて配信し、さらに、前記コンテンツファイルの残りの部分を前記コンテンツ配信ネットワークを通じて配信するステップと、
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記ピアツーピアネットワークのピアとして用いられるバックアップサーバが、前記追加のスループットを提供することを特徴とする方法。
【請求項３】
請求項１に記載の方法において、前記ピアツーピアネットワークは、BitTorrent、kazaa、eDonkey、Gnutella、及び、Direct Connectからなる群から選択されたファイル転送プロトコルにしたがって動作することを特徴とする方法。
【請求項４】
請求項２に記載の方法において、前記バックアップサーバは、発信源となるクライアントとして機能するよう構成されていることを特徴とする方法。
【請求項５】
請求項１に記載の方法において、前記コンテンツファイルの前記必要なスループットを決定するステップは、前記コンテンツファイルに関して用いられる配信方式の決定を含むことを特徴とする方法。
【請求項６】
請求項１に記載の方法において、前記配信方式は、ストリーミングメディア方式又はファイルダウンロード方式からなる群から選択されることを特徴とする方法。
【請求項７】
パケット交換方式のネットワークを通じてクライアントにコンテンツファイルを配信するための方法であって、
前記コンテンツファイルの少なくとも一部を、ピアツーピアファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて配信するステップと、
前記コンテンツファイルの残りの部分を、クライアント−サーバファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて配信するステップと、
を含むことを特徴とする方法。
【請求項８】
請求項７に記載の方法において、前記コンテンツファイルの残りの部分を、クライアント−サーバファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて配信するステップは、ピアツーピアネットワークにおける利用可能なスループットが前記コテンツファイルを前記クライアントへ配信するのに十分ではないと決定された後、実行されることを特徴とする方法。
【請求項９】
請求項７に記載の方法において、前記コンテンツファイルの少なくとも一部を、ピアツーピアファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて配信するステップは、前記ピアツーピアネットワークにおいて利用可能なスループットが前記コンテンツファイルを配信するのに必要なスループットより小さい場合に、その利用可能なスループットを追加のスループットで補完するステップを含むことを特徴とする方法。
【請求項１０】
請求項９に記載の方法において、前記ピアツーピアネットワークのピアとして用いられるバックアップサーバが、前記追加のスループットを提供することを特徴とする方法。
【請求項１１】
請求項７に記載の方法において、前記ピアツーピア転送モデルは、BitTorrent、kazaa、eDonkey、Gnutella、及び、Direct Connectからなる群から選択されたファイル転送プロトコルにしたがって動作するピアツーピアネットワークを用いることを特徴とする方法。
【請求項１２】
請求項１０に記載の方法において、前記バックアップサーバは、発信源となるクライアントとして機能するよう構成されていることを特徴とする方法。
【請求項１３】
請求項９に記載の方法において、前記コンテンツファイルの必要なスループットを決定することは、前記コンテンツファイルに関して用いられる配信方式の決定を含むことを特徴とする方法。
【請求項１４】
請求項１３に記載の方法において、前記配信方式は、ストリーミングメディア方式又はファイルダウンロード方式からなる群から選択されることを特徴とする方法。
【請求項１５】
パケット交換方式のネットワークを通じてコンテンツファイルを受信するための方法であって、
前記コンテンツファイルの少なくとも一部を、ピアツーピアファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて受信するステップと、
前記コンテンツファイルの残りの部分を、クライアント−サーバファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて受信するステップと、
を含むことを特徴とする方法。
【請求項１６】
請求項１５に記載の方法において、前記コンテンツファイルの少なくとも一部を、ピアツーピアファイル転送モデルを利用する前記パケット交換方式のネットワークを通じて受信するステップは、前記ピアツーピアネットワークにおいて利用可能なスループットが前記コンテンツファイルを配信するのに必要なスループットより小さい場合に、その利用可能なスループットを追加のスループットで補完するステップを含むことを特徴とする方法。
【請求項１７】
請求項１５に記載の方法において、前記ピアツーピアネットワークのピアとして用いられるバックアップサーバが、前記追加のスループットを提供することを特徴とする方法。
【請求項１８】
請求項１５に記載の方法において、前記ピアツーピア転送モデルは、BitTorrent、kazaa、eDonkey、Gnutella、及び、Direct Connectからなる群から選択されたファイル転送プロトコルにしたがって動作するピアツーピアネットワークを用いることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
一般的に、本発明は、インターネットなどのようなパケット交換方式ネットワークを通じた一又は二以上のクライアントにコンテンツを配信するための技術に関する。より詳細には、ピアツーピアネットワーク及びコンテンツ配信ネットワーク（ＣＤＮ）を用いてクライアントにコンテンツを配信する方法及び装置に関する。
【背景技術】
【０００２】
ソフトウエアなどのような容量が大きく一般向けのデジタルファイルや、音楽ファイル、ビデオファイルの提供者は、そのようなファイルを配信するために帯域幅需要の増加に対応しなければならない。ファイルが流行するにつれて、多くのユーザがファイルを要求し、より多くの帯域幅がファイルの配信のために必要となる。例えば、従来のハイパーテキストトランスファープロトコル（ＨＴＴＰ）ファイルの配信技術の場合、帯域幅要求は、要求するユーザの数とともに線形的に増加し、すぐに、法外なものとなる。
【０００３】
したがって、インターネットなどのような通信ネットワークを通じたユーザへのコンテンツの配信についての改善が引き続き必要となる。
【発明の概要】
【０００４】
本発明によると、パケット交換方式のネットワークを通じたクライアントへのコンテンツファイルの配信のための方法及び装置が提供される。始めに、方法は、クライアントにコンテンツファイルを配信するのに必要とされる適切なスループットを決定する。次に、クライアントにコンテンツファイルを配信するためのピアツーピアネットワークで利用可能なスループットが決定される。必要なスループットと、利用可能なスループットを比較する。利用可能なスループットが必要なスループットより小さい場合、利用可能なスループットは、追加のスループットで補完される。そして、コンテンツは、パケット交換方式のネットワークを通じてクライアントに配信される。そのネットワークは、ピアツーピアネットワークの利用可能なスループット及び追加のスループットを利用する。
【０００５】
本発明の一つの側面によると、追加のスループットは、バックアップサーバによって提供されてもよい。そのバックアップサーバは、必要に応じて、ピアツーピアネットワークにおけるピアとして用いられる。
【０００６】
本発明の他の側面によると、追加のスループットは、コンテンツ配信ネットワーク（content delivery network）によって提供されてもよい。
【０００７】
本発明の他の側面によると、クライアントへのコンテンツの配信は、さらに、ピアツーピアネットワークを通じてコンテンツファイルの一部を配信し、そして、コンテンツ配信ネットワークを通じてそのコンテンツファイルの残りの部分を配信することを含んでいてもよい。
【０００８】
本発明の他の側面によると、ピアツーピアネットワークは、BitTorrent、kazaa、eDonkey、Gnutella、Direct Connectからなる群から選択されたファイル転送プロトコルにしたがって動作することが可能である。
【０００９】
本発明の他の側面によると、バックアップサーバは、発信源となるクライアントとして機能するよう構成されていてもよい。
【００１０】
本発明の他の側面によると、決定は、コンテンツファイルに関連して用いられる配信方法で構成されている。
【００１１】
本発明の他の側面によると、配信方式は、ストリーミングメディア方式又はファイルダウンロード方式からなる群から選択される。
【００１２】
本発明の他の側面によると、方法は、パケット交換方式のネットワークを通じてクライアントにコンテンツファイルを配信するために提供される。始めに、方法は、ピアツーピアファイル転送モデルを利用するパケット交換方式のネットワークを通じてコンテンツファイルの少なくとも一部を配信する。方法は、クライアント−サーバ用ファイル転送モデルを利用するパケット交換方式のネットワークを通じてコンテンツファイルの残りの部分を配信することによって続けられる。
【００１３】
本発明の他の側面によると、方法は、パケット交換方式のネットワークを通じてコンテンツファイルを受信するために提供される。始めに、方法は、ピアツーピアファイル転送モデルを利用するパケット交換方式のネットワークを通じてコンテンツファイルの少なくとも一部を受信する。方法は、クライアント−サーバ用ファイル転送モデルを利用するパケット交換方式のネットワークを通じてコンテンツファイルの残りの部分を受信することによって続けられる。
【図面の簡単な説明】
【００１４】
【図１】ピアツーピアファイル共有ネットワークの一実施例についての高水準のブロック図を示す。
【図２】ＣＤＮネットワークの一実施例についての高水準のブロック図を示す。
【図３】ピアツーピアモデルとコンテンツ配信モデルの両方を用いる混成ネットワークを示す。
【図４】図３で示されている混成ネットワークについてのリソースの最適な利用を決定するよう用いられ得るプロセスの一例を示すフローチャートである。その混成ネットワークは、クライアントにコンテンツファイルを配信するネットワークである。
【図５】図４のフローチャートにおけるステップをより詳細に示したフローチャートである。そのステップにおいて、ピアツーピアネットワークにおける利用可能なスループットは、バックアップピアサーバによってかそれとも、コンテンツ配信ネットワークのリソースを用いて、拡張されたとき決定される。
【００１５】
以下でより詳細に説明するように、本発明は、クライアント−サーバネットワークモデル又はコンテンツ配信ネットワークモデルと、ピアツーピアファイル転送モデルとの両方を用いて、コンテンツファイルをコンテンツの発信源から複数のクライアントへ転送することを可能にする。コンテンツファイルは、以下に限定しないが、データ、ビデオ、オーディオ、ｈｔｍｌページ、関連する組み込みオブジェクト、そして、それらの任意の組み合わせを含むことが可能である。特に、本発明は、クライアントがダウンロードを望む特定のコンテンツファイルについて所定の時に、どのダウンロードモデルが最も適しているかを動的に選択することが可能である。本発明の様々な特徴をより詳細に説明するまえに、ピアツーピアネットワークとコンテンツ配信ネットワークとの両方の記載を提示するつもりである。明確にするために、２つのモデルは、図１及び図２を参照して別々に説明する。
【００１６】
インターネット上でファイルを転送するのに最も一般的な方法は、クライアント−サーバモデルである。中心となるサーバは、ファイルを要求した各クライアントにそのファイル全てをｈｔｔｐ及びｆｔｐで送信する。クライアントは、サーバとのみ通信し、互いには通信しない。クライアント−サーバモデルの主な利点は、その単純さであって、つまりは、ユーザがサーバにログオンしてダウンロードプロセスを起動する。さらには、サーバがそのサーバ機能のタスクに専念する傾向があり、さらに、常時インターネットに接続されている限り、ファイルは、通常の場合、長期間利用可能となる。クライアント−サーバモデルの他の重要な有利点は、データスループット及びデータ待ち時間に関するクライアントに提供するサービス品質（Quality of Service）が、サーバによって大部分は制御され、そして、効率的に保証され得ることである。これに関連して、スループットは、単位時間当たりで送られるオーバーヘッドを伴わない実際のユーザデータ（すなわち、ペイロード）量を参照する。そのオーバーヘッドとは、スタートビットやエンドビットなどのようなプロトコルの情報のオーバーヘッド、ＴＣＯ／ＩＰのオーバーヘッド、ＨＴＴＰのオーバーヘッドなどである。スループットは、時間によって異なる可能性があり、そして、様々な要素に依存する可能性もある。その要素は、帯域幅や、待ち時間（すなわち、データの可能最少量を送るのに必要な最小時間）、ペイロードサイズ、パケットサイズ、ネットワーク負荷、ホップ要求数などある。
【００１７】
しかしながら、クライアント−サーバモデルは、最近リリースされているコンテンツなどのような大きい及び／又は人気のあるファイルに関する重大な問題を有する。特に、サーバが全ファイルを各クライアントに送信しなければならないことから、非常に多くの帯域幅及びサーバリソースを、各ファイルを配信するために用意しなければならない。結果として、サーバは、コンテンツの全配信コストを負担することとなる。これら問題のために、コンテンツ提供者は、時おり、いわゆるコンテンツ配信サービス提供者（content delivery service provider,  CDSP）を用いて、コンテンツ提供者の代わりにコンテンツを効果的に配信する。ＣＤＳＰは、コンテンツ配信ネットワーク（ＣＤＮ）を動作させる。ＣＤＮは、地域別に配布されるコンテンツ用配信ノードのネットワークである。そのノードは、サードパーティのコンテンツ提供者に代わって効果的にコンテンツを配信するために配置されている。所定のコンテンツファイルに関して要求を行ったエンドユーザからの要求は、“最良の”レプリカに向けられている。ここで、“最良”とは、コンテンツ提供者の起点となるサーバからアイテムを取得するのに必要な時間と比較してアイテムがクライアントに早く提供されることを意味する。コンテンツ配信ネットワークは、インターネット上に分散しているコンテンツ配信サーバ（ＣＤＳ）のセット、同様にドメインネームサーバ（ＤＮＳ）機構を備える。その機構は、最も近いＣＤＳへユーザ要求の経路を決定するよう用いられる。ユーザのブラウザから送られたＤＮＳ要求は、ＣＤＳＰのＤＮＳに向けられている必要がある。一つの技術は、発信元となるサイトについての“権限を有するＤＮＳ”となるために、発信元となるサイトのＤＮＳ機能を“引き継ぐ”ＣＤＳＰのためのものである。ＣＤＮは、クライアント−サーバモデル特有の問題を排除することはない。むしろ、それは、発信元となるコンテンツ提供者からファイルをダウンロードする負担をサードパーティへ単に移転させているだけである。
【００１８】
クライアント−サーバモデルを用いたファイル配信についての帯域幅要求を削減するために、多くの技術が提案されている。例えば、時に“共同配布（cooperative distribution）”と呼ばれるピアツーピアコンテンツ共有モデルにおいて、以前にファイルのダウンロードを行った一又は二以上のユーザは、他のユーザとファイルを共有することが可能である。共同配布モデルは、サーバが大きなファイルの配信を信頼性のある方式で実行することを可能にする。その方式は、要求中のユーザの数に対応する。他の利益では、共同配布モデルは、既存ユーザの活用されていないアップストリームの帯域幅を活用する。現在のピアツーピアネットワークの例は、BitTorrentや、kazaa、eDonkey、Gnutella、Direct Connect、そして、それと同等なものなどのようなシステムを含む。
【００１９】
例えば、BitTorrentファイル配布システムにおいて、コンテンツファイルは、ブロックに分割される。そして、ユーザは、同時に全てのブロックを含むピアの検索を試みる。複数のユーザが同じファイルを同時にダウンロードするとき、何人かのユーザは、ファイルのブロックを互いにアップロードする。言い換えると、BitTorrentユーザは、ファイルを完全に取得するまで、自身が持っているファイルのブロックと、他のユーザが有する他の要求ブロックを交換する。BitTorrentのキーとなる指針としては、ユーザがダウンロード（内側に受信する）を行うと同時にアップロード（外側に送信する）を行わなければならないことである。この方式において、ネットワークの帯域幅は、可能な限り効果的に利用される。そして、ファイルをアップロードするコストは、ファイルのユーザに再分配され、人気のあるファイルのホスティングのコストをより手ごろなものにする。より多くのユーザにシステムダウンがつきまとう傾向がある他のファイル転送プロトコルとは対照的に、BitTorrentは、人気のあるファイルに興味を持つ人の数が増えるにつれて、より良く機能するよう設計されている。
【００２０】
ピアツーピアコンテンツ共有モデルは、クライアントの利用可能なアップストリームの帯域幅を活用することから、クライアントへのコンテンツ配信に関連するコストを削減することが可能である。このようにして、他の方法である中央に集中しているダウンロードサーバに使われる帯域幅のコストを大幅に削減する。残念なことに、クライアントはコンテンツの配信者の完全な制御下には無いことから、クライアントにもたらされるサービス品質を保証することはできない。しかし、サービス品質は、活発にコンテンツをダウンロードするクライアントの数、そして、それらクライアントのアップリンクスピードに極めて依存する。
【００２１】
よって、本発明の発明者は、コンテンツ配信ネットワークによって代表されるようなクライアントサーバモデル、そして、ピアツーピアモデルのどちらも、コンテンツをクライアントに配信する目的に関して完全には満たしていないことを認識している。以下でより詳述する方法、システム、そして、技術は、両方のファイル共有技術を利用する。
【００２２】
図１は、ピアツーピアファイル共有ネットワークの一実施例についての高水準のブロック図を示す。そのネットワークにおいて、個々のノードは、インターネットなどのようなパケット交換方式ネットワーク１８０を通じて通信する。ここで説明する方法は、クライアントのピアによるファイル共有をサポートするようなネットワーク全てに大抵は適用可能であるが、以下の説明において、例示の目的のために、BitTorrentネットワークプロトコルを用いる。しかしながら、本発明は、任意かつ適切なプロトコルを用いて、他のピアツーピアネットワークや、中央に集中化させていないネットワーク、中央に集中化させたネットワークに対して、同等に適用可能である。その任意かつ適切なプロトコルは、Gnutella、eDonkey、kaZaA、Gnutella、Direct Connect、及び、それらと同等なものである。
【００２３】
図１において、サーバ１１１及び１１２などの一又は二以上のサーバは、ファイル（ＴＦＩＬＥ）１２４の保管場所として機能する。そのファイルは、クライアント１０１乃至１０４などのクライアントノード間で共有されるコンテンツファイルに関するメタデータを含む。BitTorrentとの関連で、ファイル１２４は、トレントファイル（torrent file）１２４としばしば呼ばれる。トレントファイル１２４は、追跡サーバ（tracker server）のＵＲＬ(以下で詳述する)や、配信されるコンテンツファイルにおける個々のブロックのための推奨されている名前、各ブロックのために用いられるブロック長、各ブロックのためのハッシュコードなどのような情報を含んでいてもよい。クライアントは、それらの情報を利用し、受信するデータの完全性を検証することが可能である。最初に、クライアント１０１乃至１０４のユーザは、所望のコンテンツファイルにアクセスする前に、トレントファイル１２４をダウンロードしなければならない。適切なトレントファイル１２４は、ユーザによって任意かつ従来の方式で配置されていてもよい。例えば、ユーザは、一又は二以上のサーバ１１１及び１１２のアドレスを前から知っていてもよい。これにより、直接、コンタクトを取って、トレントファイル１２４を直接ダウンロードすることが可能である。また、ユーザは、ウエブページを通じてトレントファイル１２４に関連付けされていてもよい。さらに、他の方法として、インターネットの検索エンジンを用いてトレントファイル１２４を検索することによって探すことも可能である。
【００２４】
クライアント１０１乃至１０４それぞれは、クライアント版のファイル共有プログラム（ＣＰＲＧ）１３０を用いて構成されている。クライアントプログラム１３０を用いて、トレントファイル１２４をダウンロードして開く。クライアントプログラム１３０は、追跡サーバ１４１及び１４２などの一又は二以上の追跡サーバをユーザのために表示する。その追跡サーバは、全てのクライアント又はピアの動作を連携させる。追跡サーバは、接続のみを管理し、配信対象のファイルのコンテンツについての情報は一切有していない。したがって、ユーザが大量であっても、追跡用の比較的制限された帯域幅で維持され得る。追跡サーバは、所望のコンテンツファイルのためのファイル共有プロセスに現在参加しているクライアントのリストを保持する。そして、ユーザは、コンテンツファイルのコピーを得るために、コンタクトを取る特定の追跡サーバの一つを選択する。クライアントプログラム１３０は、選択した追跡サーバと通信を確立する。追跡サーバは、クライアントプログラム１３０へ他のピアのリストを送信する。他のピアは、クライアント１０１乃至１０４が所望するコンテンツファイルのブロックを現在ダウンロードしているピアである。
【００２５】
例として、クライアント１０１及び１０２のユーザが、追跡サーバ１４１を選択する場合、それら個々のクライアントプログラム１３０は、追跡サーバ１４１の追跡プログラム１５０とコンタクトを取り、通信する。そして、追跡プログラム１５０は、ネットワークリストをコンタクト中のクライアント１０１及び１０２それぞれに送信し返す。ネットワークリストに含まれるものは、クライアント１０４のような“発信源となる”少なくとも一つのクライアントのためのコンタクト情報である。そのクライアントは、クライアント１０１及び１０２が取得を望んでいるコンテンツファイルのフルコピーを有する。同様に、ネットワークリストには、コンテンツファイルに関して追跡サーバ１４１に最近コンタクトを取ったクライアント１０１及び１０２などのクライアントのためのコンタクト情報が含まれる。クライアント１０１及び１０２のクライアントプログラム１３０は、コンテンツファイルをダウンロードするために、提供されたネットワークリストにおける情報を用いて、発信源となるクライアント１０４とのピアツーピア通信を確立し、互いに通信を確立する。クライアントは、それらピアとコンタクトを取り、コンテンツファイルの様々なブロックを取得する。トレントを共有するよう互いに接続しているそのようなピアのグループは、しばしばスウォームと呼ばれる。スウォームが最初の発信源のみを含む場合、クライアントは、発信源に直接接続し、ブロックの要求を開始する。ピアがスウォームに加わると同時に、ピアは、発信源から直接ダウンロードする代わりに、互いのブロックの交換を開始する。
【００２６】
最初に、発信源となるクライアント１０４は、ピアツーピアネットワークにおいて、配信のために利用可能な任意のブロックを有する唯一のクライアントであってもよい。また一方、ブロックがクライアントの一つにうまくダウンロードさたとき、そのクライアントのクライアントプログラム１３０は、ダウンロードに利用可能なブロックを有することを他のクライアントに知らせる。クライアント１０１及び１０２に加えて、より多くのクライアントがピアツーピアネットワークに参加するにしたがい、クライアントがスウォームダウンロードに参加するたびに、ピアツーピアネットワークの全てのクライアントへのコンテンツファイルの配布が迅速化するようさらに機能する。最終的には、コンテンツファイルの全てのブロックは、ピアツーピアネットワーク内で、発信源となるクライアント１０４以外のピアから利用可能となる可能性がある。そのとき、発信源となるクライアント１０４は、ピアツーピアネットワークから切断することが可能である。
【００２７】
ダウンロードが行われ集められたブロックの可用性を知らせる前に、最初に、クライアントプログラム１３０は、集められたブロックが適しているかを検証する。例えば、集められたブロックのためのハッシュコードを計算し、そして、提供されている既知のハッシュ値と計算したハッシュ値を比較することによって実行する。例えば、その提供されている既知のハッシュ値は、トレントファイル１２４において提供される。２つのハッシュ値が適合した場合、ブロックは、適しているとして決定される。この場合、クライアントプログラム１３０によって、ダウンロードするために集められたブロックに関しての可用性を他のピアツーピアクライアントに通知する。その一方で、２つのハッシュ値が適合しない場合、ブロックは破損しているとして決定される。この場合、集められたブロックについての個々のブロックは、破棄され、同じ発信元又は異なる発信元（すなわち、ピアツーピアネットワークの他のクライアント）から再度要求される。クライアントは、コンテンツファイル全てのブロックのダウンロードに成功することで、ピアツーピアネットワークから切断することが可能となる。それと同時に、他のクライアントは、ピアツーピアネットワークに参加し、ピアツーピアネットワークにおいて、残りのピアからコンテンツファイルをダウンロードすることが可能となる。そのような新たに参加したクライアントを通知するために、さらに、ネットワークリストにおける自身のコンタクト情報を保持するために、スウォームダウンロードに既に参加しているクライアントが、追跡サーバに定期的に再接続を行い、更新されたネットワークリストを取得ことは有用である。
【００２８】
図２は、ＣＤＮネットワークの一実施例についての高水準のブロック図を示す。図１及び図２、同様に以下の図において、同じ要素の表示は、同じ参照番号によって表示する。ネットワーク１００は、図１に示すようにクライアント１０１乃至１０４、そして、少なくとも一つのコンテンツ配信ネットワーク（ＣＤＮ）１７０を備える。そのネットワーク１００は、コンテンツ配信サービス提供者（ＣＤＳＰ）、パケット交換方式ネットワーク１８０（例えば、インターネット）、そして、発信元となるコンテンツ提供者ネットワーク１２０によって動作する。
【００２９】
コンテンツを要求するユーザが、クライアント１０１乃至１０４を利用する。ＣＤＳＰは、ＣＤＮ１７０及びパケット交換方式ネットワーク１８０を介したクライアント１０１乃至１０４とコンテンツ提供者ネットワーク１２０との間の接続を提供する。図１にＣＤＮ１７０を一つのみ説明的に示しているが、当業者であれば明らかなように、複数のＣＤＮ１７０をパケット交換方式ネットワーク１８０に接続してもよく、コンテンツをクライアントのコンピュータ装置に提供することが可能である。
【００３０】
コンテンツ提供者ネットワーク１２０は、複数の（発信元となる）コンテンツサーバ１２６1から１２６qまで（全体でコンテンツサーバ１２６）、そして、発信元となるドメインネームサービス（ＤＮＳ）１２８を備える。複数のコンテンツサーバ１２６が存在する実施例において、図２に例示として示すように、ルータ又はスイッチ１２２は、ユーザが要求したコンテンツと関連するコンテンツサーバ１２６への経路の情報及びそれからの経路の情報を決定するよう利用することができる。
【００３１】
コンテンツ配信ネットワーク（ＣＤＮ１７０）は、ネットワーク１７０のエッジにあるキャッシュサーバの１１０1から１１０qまでのセット（また、コンテンツ配信サーバ（ＣＤＳ）とも呼ばれる、全体でＣＤＳ１１０）、同様に、ドメインネームサーバ（ＤＮＳ）機構１０８を備える。そのドメインネームサーバは、最も近いＣＤＳ１１０へユーザの要求の経路を決定するよう用いられる。動作中に、クライアント１０１乃至１０４から送られるＤＮＳの要求は、ＣＤＳＰ１７０のＤＮＳ１０８に向けられる。例えば、これは、ＣＤＳＰ１７０が、発信元となるサイトのための“権限を有するＤＮＳ”となるために、発信元となるコンテンツ提供者ネットワーク１２０のＤＮＳ機能を“引き継ぐ”ことを可能にすることによって達成されてもよい。
【００３２】
コンテンツ配信サービス提供者（ＣＤＳＰ）は、発信元となるサイト（すなわち、コンテンツサーバ１２６）からネットワーク１８０のエッジにあるＣＤＳサーバ１１０へのコンテンツの配布を可能にする。ＣＤＳサーバは、コンテンツをクライアント１０１乃至１４に順に配信する。配布メカニズムは、プッシュ技術、又は、プル技術の両方に基づいてもよい。プッシュ技術は、地上リンク又は衛星リンクを通じて全てのエッジにあるサーバにデータをマルチキャストするなどの技術であり、プル技術は、プロキシによって利用される技術である。目的は、コンテンツファイルへのユーザアクセスによる待ち時間を削減することである。そして、その目的は、ユーザに最も近いＣＤＳのエッジにあるサーバからファイルを配信することによって達成される。
【００３３】
前述の通り、ピアツーピアネットワーク及びコンテンツ配信ネットワークは共に、それらの利点及び不利な点を有する。例えば、サーバは各クライアントに全ファイルを送信しなければならないことから、ＣＤＮは、非常に大きな帯域幅及びサーバリソースを必要とする。結果として、サーバは、コンテンツの配信コスト全てを負担する。しかしながら、ＣＤＮは、クライアントに提供するサービス品質の制御を最もよく行うことができる。その一方で、ピアツーピアネットワークは、中心となるサーバに掛かる負担を、クライアントのアップストリームにおける利用可能な帯域幅を利用することによって削減するが、クライアントに配信されるサービス品質の制御は劣化する。
【００３４】
本発明は、コンテンツ配信ネットワークモデルとピアツーピアネットワークモデルとの組み合わせを利用し、上述の問題及び制限を解消するようファイルをコンテンツの発信元から複数のクライアントへ転送する。多くの疑問は、使用する２つのネットワークモデルの適切な組み合わせを決定することで答えられるであろう。特に、最初は、どのくらい早くファイルをクライアントに送る必要があるかを決定すべきである。そして、最少のコストを用いて必要なスピードでデータをどの程度送ることができるか決定する必要がある。
【００３５】
ファイルをどの程度早くクライアントに送る必要があるか決定することにおいて、主要な検討事項は、クライアントが受信を望むメディアのタイプである。例えば、コテンツファイルがリアルタイムで（例えば、ストリーミングメディアファイルとして）配信される場合、ファイルをクライアントに単にダウンロードするときより、より高いスループット（例えば、ビットレート）が必要となるであろう。必要なスループットが決定すると、それは、ピアツーピアネットワークのスループットと比較される。ピアツーピアネットワークのスループットで十分である場合、このモデルは、コンテンツファイルを配信するよう用いられる。その一方で、ピアツーピアネットワークのスループットが十分ではない場合、ピアツーピアネットワークは、他の技術によるスループットの補完によってファイルを配信するよう用いることが可能となる。
【００３６】
ピアツーピアネットワークのスループットを補完又は拡張する一つの方法としては、バックアップのピアサーバと呼ばれるものを用いることである。配信対象のコンテンツファイルのコピーを含むバックアップのピアサーバは、追加のピアとして用いることができ、スウォームのスループットを向上させることが可能である。バックアップピアサーバは、配信対象のコンテンツファイルの完全なコピーを含んでいる場合、発信源となるクライアントであってもよい。特定のコンテンツファイルを配信するためにピアツーピアネットワークのスループットを上昇させる必要であるとき、バックアップピアサーバのリソースの起動のみを実行する必要がある。
【００３７】
ピアツーピアネットワークのスループットを補完又は拡張する他の方法としては、コンテンツ配信ネットワークを用いて、コンテンツファイルの一部をクライアントに配信することである。例えば、コテンツファイルの一部は、コンテンツ配信ネットワークによる配信のために予約されていてもよい。ファイルの予約されている部分は、ピアツーピアネットワークを通じて配信するのに必要なファイルのある割合（例えば、半分）又は所定のブロック数とすることが可能である。
【００３８】
図３は、図１及び図２でそれぞれ説明したピアツーピアネットワーク及びコンテンツ配信ネットワークを、２つのネットワークの動作を調整するよう用いられる状態サーバ（state server）１６０と一緒に示す。状態サーバ１６０は、コンテンツファイルのスループット要求、そして、ピアツーピアネットワークのスループットのキャパシティを監視する。さらに、状態サーバ１６０は、コンテンツ配信ネットワークのリソースを必要に応じて起動し、ファイルのスループット要求にしたがってコンテンツファイルを配信する。理解されるように、バックアップピアサーバ１９０は、ピアツーピアネットワークに追加のリソースを必要に応じて提供する。
【００３９】
通常、状態サーバ１６０は、図３に示したネットワークを連続して監視する。個々のピアクライアントは自由に参加／終了することが可能であるから、ネットワークにおける利用可能なスループットは絶え間なく変化しようとする。事実、ファイルの様々なブロックのスループットは、ブロック毎に概して異なる。例えば、２つのピアクライアントが所定のファイルのブロック全て（例えば、ブロック１乃至１０）を有し、他の２つのピアクライアントがブロック１及び２を有し、さらに異なる２つのピアクライアントがブロック３及び５を有する場合、ブロック１、２、３、及び、４は、最も利用し易いスループットを有し（６倍のクライアントスピード）、一方で、ピース５乃至１０は、より低いスループットを有する（２倍のクライアントスピード）。当然、この例は、アップロード速度が全てのピアクライアントについて同じであると仮定している。このため、スループットレートが動的に変化する可能性があることから、状態サーバ１６０は、スループットレートを絶え間なく監視すべきである。
【００４０】
図４は、コンテンツファイルをクライアントに配信するネットワークリソースの最適な利用を決定するよう用られ得るプロセスの一例を示すフローチャートである。そのプロセスは、ステップ２０５から始まり、その際、ピアツーピアネットワークは、クライアントが配信のために要求しているファイルのスループット要求を計算する。その計算は、ピアツーピアネットワーク内の追跡サーバによって又は任意かつ他の適切なエンティティによって、任意かつ既知の技術にしたがい実行され得る。スループット要求は、主にコンテンツがリアルタイムでの配信対象であるか、又は、その後の使用のためにダウンロードでの配信対象であるかに依存する。同様に、ステップ２１０において、ピアツーピアネットワークのスループットは、ファイルが配信されるときに決定される。ピアツーピアネットワークのスループットは、多くの事象に依存し、最も顕著であるところでは、スウォームにおける個々のクライアントのアップリンクにおける利用可能な帯域幅合計に依存する。必要なスループットと利用可能なスループットは、決定を行うステップ２１５で比較される。利用可能なスループットが必要なスループットと大体等しい又はより大きい場合、ステップ２２０において、コンテンツファイルは、ピアツーピアネットワークのみを用いてダウンロードされる。その一方で、ステップ２１５で、ピアツーピアネットワークの利用可能なスループットがファイルの配信に十分ではないと判定された場合、プロセスはステップ２２５を続行する。そのステップにおいて、ピアツーピアネットワークの利用可能なスループットは、バックアップピアサーバによってかそれとも、コンテンツ配信ネットワークのリソースを用いて、拡張されたとき決定される。決定を行うステップ２３０において、拡張したピアツーピアネットワークのスループットを、必要なスループットと比較する。この方式で拡張されたピアツーピアネットワークの利用可能なスループットが十分である場合、コンテンツファイルは、ステップ２３５において拡張したピアツーピアネットワークを用いて配信される。拡張したピアツーピアネットワークのスループットがコンテンツファイルを配信するのに依然として十分ではない場合、ステップ２４０において、コンテンツ配信ネットワークのみを用いてファイルを配信する。
【００４１】
図５は、図４のステップ２２５をより詳細に示したフローチャートである。そのステップにおいて、ピアツーピアネットワークの利用可能なスループットは、バックアップピアサーバによってかそれとも、コンテンツ配信ネットワークのリソースを用いて、拡張されたとき決定される。ステップ３０５において、ピアツーピアネットワークの利用可能なスループットは、バックアップピアサーバを用いて、拡張されたとき決定される。必要なスループットと利用可能なスループットは、決定を行うステップ３１０において比較される。利用可能なスループットが必要なスループットと大体等しい又はより大きい場合、ステップ３１５において、コンテンツファイルは、バックアップピアサーバを使って拡張したピアツーピアネットワークを用いてダウンロードされる。その一方で、決定を行うステップ３１０で、バックアップピアサーバを使って拡張したピアツーピアネットワークの利用可能なスループットがファイルの配信に十分ではないと判定された場合、プロセスはステップ３２０を続行する。そのステップにおいて、ピアツーピアネットワークの利用可能なスループットは、コンテンツ配信ネットワークのリソースを用いて、拡張されたとき決定される。
【００４２】
上述の本技術によってクライアントへ配信するコンテンツは、任意かつ他の手段による通信ネットワークを介してダウンロードや、ストリーミング、さらには、配信が行われる任意のタイプのファイルとすることが可能である。そのようなファイルは、以下に限定しないが、アプリケーションプログラム及び他の実行ファイルや、データファイル、オーディオ、ビデオ、マルチメディアファイル、オペレーティングシステムの構成要素、ドライバ、アップデート、そして、それらと同等なものを含むことが可能である。例えば、ある実施例において、ダウンロード対象のファイルは、家庭用電子機器（例えば、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）、ビデオカメラ、デジタルカメラ、ＭＰ３プレーヤ）と関連するソフトウエアプロダクトとすることも可能である。そのソフトウエアプロダクトは、家庭用電子機器の製造者又はベンダーによって利用可能となる。
【００４３】
ある場合には、クライアントへ配信する対象であるファイル又はソフトウエアプロダクトは、関連サービスによって配信されていてもよい。例えば、クライアントは、ウエブサイトにコンタクトすることで、そのウエブサイトは、家庭用電子機器の顧客に対して、プロダクトのアップデートや、サービスのアップデート、保証情報、さらには、顧客が利用可能な一連のサービスを管理する他の情報を提供する。他の実施例において、配信対象のファイルは、クライアントが中央サーバにアップロードするコンテンツファイル（例えば、ビデオ）とすることが可能である。そのコンテンツファイルは、他の家庭用電子機器と同期され、記憶され、及び／又は、他のクライアントと共有される。そのようなコンテンツファイルは、ここに説明した技術によって、他のクライアント又は他の家庭用電子機器に配信することが可能である。また、そのサービスは、顧客が、複数の家庭用電子機器を登録し、そして、各装置のためのサービスの認証を実行し、さらに、各装置の管理することを可能にするように、顧客に補助的なサービスを提してもよい。また、顧客は、ここに示した技術を用いて、装置を管理するためのプロフィール生成するサービスや、装置間のコンテンツを同期させるサービスを使用することが可能である。
【図１】
0005464423.tif 000002
【図２】
0005464423.tif 000003
【図３】
0005464423.tif 000004
【図４】
0005464423.tif 000005
【図５】
0005464423.tif 000006