JPWO2009125760A1 - コンテンツ配信システム及びそれに用いるコンテンツ配信方法 - Google Patents

Abstract

【課題】 スウォームを構成するシーダーの割合を大きくし、各リーチャーがアクセス回線のダウンロード帯域に近いレートでダウンロードすることが可能なコンテンツ配信システムを提供する。【解決手段】 コンテンツ配信システムは、コンテンツをダウンロード中のリーチャー（ピア１−１−１〜１−１−７，１−２−１〜１−２−５，１−３−１〜１−３−７）に対して、そのダウンロード完了後にコンテンツを提供するシーダー（ピア１−１−１〜１−１−７，１−２−１〜１−２−５，１−３−１〜１−３−７）となるようにインセンティブを与えている。【選択図】図１

Description

本発明はコンテンツ配信システム及びそれに用いるコンテンツ配信方法に関し、特にコンテンツを受信するピアが、コンテンツ配信サーバだけでなく、受信ピア間でコンテンツの送受信を行うコンテンツ配信システムに関する。

コンテンツの配信方法としては、コンテンツ配信元のサーバからコンテンツ配信先のクライアントにデータをダウンロードするクライントサーバモデルに加えて、コンテンツ配信先のクライアント同士でダウンロードしたコンテンツを配信しあうことで配信元サーバの負荷を削減するＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）モデルが存在する。Ｐ２Ｐを利用したコンテンツ配信で最も普及しているのがビットトレント［ＢｉｔＴｏｒｒｅｎｔ（登録商標）］である（例えば、非特許文献１参照）。

図１１はビットトレントを利用した本発明に関連するコンテンツ配信システムの全体構成例を示すブロック図である。ビットトレントでは、図１１に示すように、コンテンツ単位でスウォーム（Ｓｗａｒｍ）２’（２’−１〜２’−３）と呼ばれるピアツーピアネットワークが構築される。

各スウォーム２’（２’−１〜２’−３）は、複数のピア（Ｐｅｅｒ）１’（１’−１−１〜１’−１−７，１’−２−１〜１’−２−５，１’−３−１〜１’−３−７，）と、トラッカー（Ｔｒａｃｋｅｒ）３’（３’−１〜３’−３）と、トレントＷｅｂサーバ（Ｔｏｒｒｅｎｔ Ｗｅｂ Ｓｅｒｖｅｒ）４（４−１〜４−３）とから構成される。トラッカー３’は、新規接続者にピアのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを教えるサーバである。

コンテンツのダウンロードを希望するユーザは、トレントＷｅｂサーバ４経由でコンテンツの情報及びトラッカー３’のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を入手する。該ユーザは、ビットトレントクライアントを利用してコンテンツをダウンロードする。ビットトレントクライアントは、ピア１’としてトラッカー３’にアクセス後、スウォーム２’に参加してコンテンツのダウンロードを行う。

図１２はビットトレントを利用した本発明に関連するコンテンツ配信システムの詳細構成例を示すブロック図である。ピア１’（１’−１−１）は、接続ピア管理部１０と、接続ピア送受信部１１と、転送制御部１２とから構成される。転送制御部１２は、アップロード（Ｕｐｌｏａｄ）管理部１２０と、ダウンロード（Ｄｏｗｎｌｏａｄ）管理部１２１とから構成される。

トラッカー３’（３’−１）は、ピアリスト（Ｐｅｅｒ Ｌｉｓｔ）３０と、ピアリスト応答部３１とから構成される。トラッカー３’は、スウォーム２’（２’−１）に参加している全てのピアの一覧をピアリスト３０にて管理する。ピアリスト３０では、スウォームに参加している各ピア１’に関してリーチャー（Ｌｅｅｃｈｅｒ）／シーダー（Ｓｅｅｄｅｒ）を区別して管理する。つまり、ピアリスト３０では、ＰｅｅｒＩＤ（ピア識別情報）とＴｙｐｅ（タイプ）とを対応付けて管理しており、Ｔｙｐｅにてリーチャー（Ｌｅｅｃｈｅｒ）／シーダー（Ｓｅｅｄｅｒ）を区別して管理している。

リーチャーは、コンテンツのダウンロードを希望するピアであり、コンテンツをダウンロードしつつ、他のリーチャーに対してアップロードを実行する。これ対して、シーダーは、既にコンテンツの全てを保有して他のリーチャーに対してアップロードだけを実施するピアである。シーダーとなるのは、コンテンツの配布をしようとしているピア、もしくはコンテンツのダウンロードを完了したピアである。

コンテンツのダウンロードを希望するするピア（＝リーチャー）は、ピア１’内の接続ピア管理部１０から、トラッカー３’に対して接続可能な複数のピアのリストを要求する。トラッカー３’内のピアリスト応答部３１は、スウォーム参加を希望してきたピアをピアリスト３０に登録すると共に、ピアリスト３０から複数のピアをランダム（Ｒａｎｄｏｍ）に選択して、ピア１’に応答を返す。尚、シーダー同士での通信は無意味であるため、接続ピアがシーダーの時には、ピアリスト３０の応答にシーダーが含まれないような選択処理が行われる。

ピア１’は、定期的にトラッカー３’にアクセスするＫｅｅｐ Ａｌｉｖｅ処理によってスウォーム２’に参加していることを継続的に通知する。また、ピア１’は、スウォーム２’から離脱する際に、トラッカー３’に離脱する旨を通知する。トラッカー３’は、あるピアに対するＫｅｅｐ Ａｌｉｖｅ Ｔｉｍｅｏｕｔが発生したり、あるピアが離脱することが通知されたりした場合には、ピアリスト３０から該当ピアを削除する。

ピア１’の接続ピア管理部１０は、トラッカー３’から接続可能なピアのリストを受信すると、接続ピア送受信部１１経由でリスト内の各ピアとの接続を行う。以後、ピア１’（１’−１−１〜１’−１−７）間の通信は、接続ピア送受信部１１を介して実行される。

スウォーム２’内で転送されるコンテンツは、固定長サイズのピース（Ｐｉｅｃｅ）に分割され、各ピアは、ピース単位でデータの送受信を行う。各ピアは、自身がどのピースを保有しているかの情報を、常時、他のピアに通知することで、接続したピア間では、互いに相手がどのピースを保有しているのかを、常時、把握している。

ダウンロード管理部１２０は、接続ピアからダウンロードしたいかどうかを、「ｉｎｔｅｒｅｓｔ ｆｌａｇ」というフラグによって通知する。アップロード管理部１２１は、ダウンロードを希望しているピアの中からアップロード対象のピアを選択して「ｃｈｏｋｅ／ｕｎｃｈｏｋｅ ｆｌａｇ（ｕｎｃｈｏｋｅがアップロード許可）」を送出する。

一般に、アップロード対象のピア数は、接続ピアのほんの一部である。厳密な値は、運用時のパラメータ設定に依存するが、例えば、接続ピア数が５０であっても、アップロード許可するピアの数はたかだか４程度である。このアップロード対象のピアを選択する際に、自分に多くのコンテンツをダウンロードしてくれるユーザを優先的に選択することがビットトレントの重要な特徴であり、これはＴｉｔ ｆｏｒ Ｔａｔ戦略と呼ばれている。

このＴｉｔ ｆｏｒ Ｔａｔ戦略に従って、定期的にアップロード対象のピアを更新し、互いにコンテンツの送受信をしあうことで、高速にアップロードを実行するピア程、優先的にダウンロードをすることが可能になる。各ピアは、高速なダウンロードを実現するために、他のピアに高速にアップロードする必要があり、積極的にアップロード処理を実施する。

ピアツーピアネットワークのスループットは、ピアがどれだけ積極的にアップロードを実施するかに依存する。ビットトレントは、Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略をアップロードピア選択アルゴリズムに組み入れることでネットワーク全体の転送ループットを向上させている。但し、シーダーの場合には、ダウンロード処理を行わないため、アップロードピアの選択を行う際に、アップロード速度の高いピアを優先して選択する。

次に、接続ピアよりアップロード許可を得たピアは、ダウンロード管理部１２１において、ダウンロード対象ピースの中で、最も保有するピア数の少ないピースを選択してダウンロード要求する。この仕組みをＲａｒｅｓｔ Ｆｉｒｓｔ機構と呼ぶ。本発明に関連するコンテンツ配信システムでは、Ｒａｒｅｓｔ Ｆｉｒｓｔ機構を利用することで、全てのピースが均等にネットワーク上に配布されるようになるため、特定のピースが足りなくなって全体のダウンロード効率が劣化する状況を防止することができる。

このＴｉｔ−ｆｏｒ−Ｔａｔ戦略と、Ｒａｒｅｓｔ Ｆｉｒｓｔ機構とを利用したビットトレントは、ピアツーピアネットワーク全体で高い転送スループットを実現するＰ２Ｐコンテンツ配布方式として最も多く利用されている。

尚、図１１では、スウォーム毎に独立にピア、トラッカー、トレントＷｅｂサーバが存在するが、一つのトラッカーやトレントＷｅｂサーバが複数のスウォームを管理するのが一般的である。また、ピアは、複数のスウォームに同時に参加することも可能である。

"Ｉｎｃｅｎｔｉｖｅｓ Ｂｕｉｌｄ Ｒｏｂｕｓｔｎｅｓｓ ｉｎ ＢｉｔＴｏｒｒｅｎｔ（登録商標）"，Ｂ．Ｃｏｈｅｎ，Ｉｎ Ｐｒｏｃ．ｏｆ １ｓｔ Ｗｏｒｋｓｈｏｐ ｏｎ Ｅｃｏｎｏｍｉｃｓ ｏｆ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｓｙｓｔｅｍｓ（Ｊｕｎｅ ２００３）（ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌ）

本発明に関連するコンテンツ配信システムでは、スウォーム内の各リーチャーの平均受信スループットは、
ＬｅｅｃｈｅｒＤｏｗｎ
＝ＬｅｅｃｈｅｒＵｐ
＋ＳｅｅｄｅｒＵｐ＊ＳｅｅｄｅｒＮｕｍ／ＬｅｅｃｈｅｒＮｕｍ
という式にて計算される。ここで、ＬｅｅｃｈｅｒＤｏｗｎ：リーチャーの平均ダウンロード速度、ＬｅｅｃｈｅｒＵｐ：リーチャーの平均アップロード速度、ＳｅｅｄｅｒＵｐ：シーダーの平均アップロード速度、ＳｅｅｄｅｒＮｕｍ：シーダーの数、ＬｅｅｃｈｅｒＮｕｍ：リーチャーの数である。

ビットトレントでは、各リーチャーは、ダウンロードが完了した際、総アップロード容量が総ダウンロード容量より小さい場合にシーダーとなり、総アップロード容量が総ダウンロード容量を超えるまではアップロードをし続けることが推奨されている。

ピアは、コンテンツのダウンロード中、高速にアップロードする方が高速にダウンロードできるため、積極的にアップロード処理を行う。しかしながら、ダウンロード完了後はアップロードを継続しても特にメリットが発生しないため、ダウンロード完了後にスウォームとの接続を切断するユーザが多い。そのため、リーチャー数に比べてシーダー数は極端に小さい状態となりやすい。

リーチャーの平均ダウンロード速度は、リーチャーからのアップロード分とシーダーからのアップロード分との合計となる。しかしながら、リーチャー数がシーダー数に比べて極端に大きい場合には、リーチャーの平均ダウンロード速度がリーチャーの平均アップロード速度とほとんど変わらなくなる。

実際には、各リーチャーのダウンロード速度にはばらつきがあり、平均ダウンロード速度よりも高速にダウンロードできるピアもあれば、逆に平均ダウンロード速度よりも低速にしかダウンロードできないピアも存在する。また、ダウンロードのボトルネック箇所がアクセス回線ではなく、ネッワーク内部に存在する場合、各リーチャーのアップロード速度はアクセス回線よりも小さくなってしまう。

そこで、本発明の目的は上記の問題点を解消し、スウォームを構成するシーダーの割合を大きくし、各リーチャーがアクセス回線のダウンロード帯域に近いレートでダウンロードすることができるコンテンツ配信システム及びそれに用いるコンテンツ配信方法を提供することにある。

本発明によるコンテンツ配信システムは、コンテンツをダウンロード中のリーチャーに対して、そのダウンロード完了後に前記コンテンツを提供するシーダーとなるようにインセンティブを与えている。

本発明による他のコンテンツ配信システムは、ダウンロード対象のコンテンツ毎のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークである複数のスウォームを含むコンテンツ配信システムであって、
前記スウォームは、前記コンテンツのダウンロード及びアップロードを実行する複数のピアと、前記スウォームに参加するピアの一覧を管理する手段と、前記ピアに付与されたインセンティブの変動量を算出する通貨変動量算出手段と、前記ピア間で優先的にデータを送受信するための優先転送契約を結ぶことを許可・管理する優先契約管理手段とを備え、
前記ピアは、前記ピア間でアップロードしたデータ量及びダウンロードしたデータ量を前記通貨変動量算出手段に通知する転送量通知手段と、前記優先契約管理手段に対して前記優先転送契約を要求する優先契約要求手段と、前記ピア間での転送を行う転送制御手段と、前記優先転送契約を行ったピアとの間で優先的に転送を行う優先転送制御手段とを備え、
前記通貨変動量算出手段は、前記ピア間のアップロードしたデータ量及びダウンロードしたデータ量に応じて前記インセンティブの増減量を算出しかつその算出結果に基づく要求を前記コンテンツを受信するピア毎に前記インセンティブの保有量の管理を行う通貨管理手段に対して通知し、
前記通貨管理手段は、前記通貨変動量算出手段からの要求に応じて前記インセンティブの量を更新し、
前記優先契約要求手段は、前記インセンティブの保有量に基づいて前記優先契約管理手段に対して前記優先転送契約を要求している。

本発明によるコンテンツ配信方法は、コンテンツをダウンロード中のリーチャーに対して、そのダウンロード完了後に前記コンテンツを提供するシーダーとなるようにインセンティブを与えている。

本発明による他のコンテンツ配信方法は、ダウンロード対象のコンテンツ毎のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークである複数のスウォームを含むシステムに用いるコンテンツ配信方法であって、
前記スウォームに、前記コンテンツのダウンロード及びアップロードを実行する複数のピアと、前記スウォームに参加するピアの一覧を管理する手段と、前記ピアに付与されたインセンティブの変動量を算出する通貨変動量算出手段と、前記ピア間で優先的にデータを送受信するための優先転送契約を結ぶことを許可・管理する優先契約管理手段とを設け、
前記ピアに、前記ピア間でアップロードしたデータ量及びダウンロードしたデータ量を前記通貨変動量算出手段に通知する転送量通知手段と、前記優先契約管理手段に対して前記優先転送契約を要求する優先契約要求手段と、前記ピア間での転送を行う転送制御手段と、前記優先転送契約を行ったピアとの間で優先的に転送を行う優先転送制御手段とを設け、
前記通貨変動量算出手段が、前記ピア間のアップロードしたデータ量及びダウンロードしたデータ量に応じて前記インセンティブの増減量を算出しかつその算出結果に基づく要求を前記コンテンツを受信するピア毎に前記インセンティブの保有量の管理を行う通貨管理手段に対して通知し、
前記通貨管理手段が、前記通貨変動量算出手段からの要求に応じて前記インセンティブの量を更新し、
前記優先契約要求手段が、前記インセンティブの保有量に基づいて前記優先契約管理手段に対して前記優先転送契約を要求している。

本発明は、上記のような構成及び動作とすることで、スウォームを構成するシーダーの割合を大きくし、各リーチャーがアクセス回線のダウンロード帯域に近いレートでダウンロードすることができるという効果が得られる。

次に、本発明の実施の形態について図面を参照して説明する。まず、本発明によるコンテンツ配信システムの概要について説明する。本発明によるコンテンツ配信システムでは、コンテンツをダウンロード中のリーチャー（Ｌｅｅｃｈｅｒ）に対して、そのダウンロード完了後に、コンテンツを提供するシーダー（Ｓｅｅｄｅｒ）となるようにインセンティブ（Ｉｎｃｅｎｔｉｖｅ）（以下、通貨とする）を与えている。

これによって、本発明によるコンテンツ配信システムでは、スウォーム（Ｓｗａｒｍ）を構成するシーダーの割合を大きくし、各リーチャーがアクセス回線のダウンロード帯域に近いレートでダウンロードすることを可能としている。ここで、スウォームは、ダウンロード対象のコンテンツ毎のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークである。

本発明によるコンテンツ配信システムでは、ピア（Ｐｅｅｒ）毎の保有通貨（インセンティブ）を管理する通貨管理部を配備し、各ピアは、ピア間とのコンテンツのアップロード・ダウンロードデータ量を通知する手段を有している。スウォーム内の通貨変動量算出手段は、各ピアのアップロード貢献量に応じて保有通貨量を算出する手段を有することによって、ピアの保有通貨がアップロードデータ量に基づいて増加する。ピアは、入手した通貨を利用して、他のスウォームコンテンツを優先的にダウンロードする。これによって、ピアは、ダウンロードしたコンテンツを他のピアにアップロードすることによって通貨を入手する。

本発明によるコンテンツ配信システムでは、ピアが入手した通貨を利用することで、他のコンテンツを優先的にダウンロードすることが可能となるため、コンテンツダウンロード後にもシーダーとなり、アップロード処理を継続実行する理由付けが発生する。

結果として、本発明によるコンテンツ配信システムでは、スウォーム内のシーダーの比率が増加し、リーチャーはアップロード速度よりも高いダウンロード速度でコンテンツを取得することが可能となる。

図１は本発明の第１の実施の形態によるコンテンツ配信システムの全体構成例を示すブロック図である。図１において、本発明の第１の実施の形態によるコンテンツ配信システムは、複数のスウォーム２（２−１〜２−３）と、通貨管理部５とから構成される。各スウォーム２（２−１〜２−３）は、複数のピア１（１−１−１〜１−１−７，１−２−１〜１−２−５，１−３−１〜１−３−７）と、トラッカー（Ｔｒａｃｋｅｒ）３（３−１〜３−３）と、トレントＷｅｂサーバ（Ｔｏｒｒｅｎｔ Ｗｅｂ Ｓｅｒｖｅｒ）４（４−１〜４−３）とから構成される。

図２は本発明の第１の実施の形態によるコンテンツ配信システムの詳細構成例を示す図である。図２において、ピア１（１−１−１）は、接続ピア管理部１０と、接続ピア送受信部１１と、転送制御部１２と、優先転送制御部１３と、優先契約要求部１４と、転送量通知部１５とから構成される。

トラッカー３（３−１）は、ピアリスト（Ｐｅｅｒ Ｌｉｓｔ）３０と、ピアリスト応答部３１と、優先契約管理部３２と、ＣｏｎｔｅｎｔＲａｔｅ更新部３３と、転送量受信部３４と、通貨変動量算出部３５とから構成される。トラッカー３は、スウォーム２（２−１）に参加しているピアの管理を行うと共に、スウォーム２に参加するピアがコンテンツを送受信することによる通貨の増減量の算出、ピア間での優先転送契約の管理を実施する。

通貨管理部５は、Ｃｕｒｒｅｎｃｙテーブル（Ｔａｂｌｅ）５１と、Ｃｕｒｒｅｎｃｙ更新部５０とから構成され、ＰｅｅｒＩＤ（ピア識別情報）で特定されるピア毎に保有通貨の管理を行う。

ピア１内の接続ピア管理部１０は、スウォーム２への参加時に、トラッカー３内のピアリスト応答部３１に対してスウォーム２に参加することを通知し、トラッカー３から接続可能なピアの一覧を取得する。接続ピア管理部１０は、入手したピアの一覧を接続ピア送受信部１１に通知し、接続ピア送受信部１１は、各ピアとの接続を行う。

転送制御部１２のアップロード（Ｕｐｌｏａｄ）管理部（図示せず）は、アップロード対象のピアをＴｉｔ ｆｏｒ Ｔａｔ戦略に基づいて選択する。転送制御部１２のダウンロード管理部（図示せず）は、ダウンロード許可されたピアからのダウンロード対象のピース（Ｐｉｅｃｅ）の選択を行う。

転送量通知部１５は、どのピアからアップロード及びダウンロードを行ったかを定期的にトラッカー３内の転送量受信部３４に通知する。

通貨変動量算出部３５は、転送量受信部３４より入手されるピア間でのデータ転送量と、ＣｏｎｔｅｎｔＲａｔｅ管理部３３から入手されるＣｏｎｔｅｎｔＲａｔｅと、優先契約管理部３２から入力される契約種別とに基づいてピア間での通貨の増減を算出し、その算出結果に基づいた要求を通貨管理部５内のＣｕｒｒｅｎｃｙ更新部５０に通知する。

Ｃｕｒｒｅｎｃｙ更新部５０は、通貨変動量算出部３５からの要求内容に基づいてＣｕｒｒｅｎｃｙテーブル５１にアクセスし、各ピアの保有通貨量を更新する。

各ピア１は、アップロード処理を実行することによって通貨を入手する。ピア１は、入手した通貨を利用して、自分のダウンロードしたいコンテンツを保有するスウォーム２から、コンテンツを通常の接続よりも優先的にダウンロードする権利を購入する。

具体的に説明すると、ピア１は、優先契約要求部１４を通じて、トラッカー３内の優先契約管理部３２に対して、通常のピアよりも優先的にダウンロードする権利の購入を要求する。優先的にダウンロード権利を購入したピア、もしくは該ピアと接続するピアは、優先転送制御部１３にて通常よりもコンテンツを優先的にダウンロードもしくはアップロードする処理を実施する。

ピア１は、コンテンツをアップロードすることで通貨を入手し、入手した通貨を利用して他のコンテンツを優先的にダウンロードすることが可能となる。あるコンテンツでアップロードすることが他のコンテンツを高速にダウンロードするメリットにつながるため、ピア１は、コンテンツのダウンロード完了後にもシーダーとなり、アップロード処理を継続実行する理由付けが発生する。

次に、ＣｏｎｔｅｎｔＲａｔｅの動的算出について説明する。ＣｏｎｔｅｎｔＲａｔｅ管理部３３は、動的にＣｏｎｔｅｎｔＲａｔｅを変更することが可能である。ＣｏｎｔｅｎｔＲａｔｅの変更方法としては、いくつかの種類が考えられる。この場合には、ＣｏｎｔｅｎｔＲａｔｅが高いものほどアップロードが推奨され、ダウンロードが抑制される効果がある。

ＣｏｎｔｅｎｔＲａｔｅの変更方法は、
（１）ＣｏｎｔｅｎｔＲａｔｅ＝リーチャー数／シーダー数
という式でＣｏｎｔｅｎｔＲａｔｅを動的に算出する場合には、シーダーの割合が少ないほどＣｏｎｔｅｎｔＲａｔｅが高くなり、アップロードが推奨される。
（２）ＣｏｎｔｅｎｔＲａｔｅ
＝リーチャー総アップロードレート／シーダー総アップロードレート
という式でＣｏｎｔｅｎｔＲａｔｅを動的に算出する場合には、シーダーの割合が少ないほどＣｏｎｔｅｎｔＲａｔｅが高くなり、アップロードが推奨される点は（１）と同じであるが、実際のアップロードトラフィックレートを利用することで、各ピアのアップロード能力を考慮してＣｏｎｔｅｎｔＲａｔｅを設定する。
（３）コンテンツ運用業者によってＣｏｎｔｅｎｔＲａｔｅを設定する場合には、コンテンツ運用業者が高速ダウンロードを実行可能としたコンテンツに関してＣｏｎｔｅｎｔＲａｔｅを大きく設定することで、より多くのシーダーを集めるようにする。
という方法がある。

ＣｏｎｔｅｎｔＲａｔｅを変更する際には、ＣｏｎｔｅｎｔＲａｔｅの急激な変動を抑制するために、ＣｏｎｔｅｎｔＲａｔｅの更新周期を１時間に１度程度と長めに設定したり、加重平均等を利用して段階的に変更していくことも考えられる。

本発明の第１の実施の形態によるコンテンツ配信システムにおける優先制御の具体例について説明する。本実施の形態では、通貨を利用した優先制御として、リーチャーがシーダーから継続的にコンテンツをダウンロードする権利を購入する。

図３は図２のトラッカー３内の優先契約管理部３２の構成例を示すブロック図である。図３において、優先契約管理部３２は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０と、記憶部３２１とから構成される。記憶部３２１は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト（Ｌｉｓｔ）３２１１と、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１２と、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３とを記憶する。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト３２１１上でＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを実行中のシーダーとリーチャーとの組を管理する。Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１２では、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの相手が見つかっていないリーチャーが管理され、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３では、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの相手が見つかっていないシーダーが管理される。

ピア１は、トラッカー３に対して、
・ＣｏｎｔｅｎｔＩＤ：Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ対象のＣｏｎｔｅｎｔＩＤ
・ＰｅｅｒＩＤ：要求を行うピアのＩＤ
・Ｓｅｅｄｅｒ Ｆｌａｇ：１＝シーダー，０＝リーチャー
・ウェイトフラグ（Ｗａｉｔ Ｆｌａｇ）：１＝Ｗａｉｔ，０＝ｎｏｔ Ｗａｉｔ、対向ピアが見つからなかった場合にＷａｉｔｉｎｇリストに登録して待つかどうかを示す情報というパラメータをつけてＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの要求を行う。

図４は図３のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０におけるシーダーがＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求した際の動作を示すフローチャートである。図５は図３のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０におけるリーチャーがＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求した際の動作を示すフローチャートである。図６は図２のピア１における対向ピアとＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を実施する際の動作を示すフローチャートである。

図７は本発明の第１の実施の形態におけるシーダーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示すシーケンスチャートであり、図８は本発明の第１の実施の形態におけるリーチャーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示すシーケンスチャートである。これら図１〜図８を参照して本発明の第１の実施の形態によるコンテンツ配信システムの動作について説明する。

図４には、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを希望するシーダーが、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇをトラッカー３に要求した際のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０の動作フローを示している。

シーダーを希望するピアが、トラッカー３に対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの要求を行うと、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１３をチェックする（図４ステップＳ１）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１３が空の場合、ウェイトフラグをチェックし（図４ステップＳ６）、ウェイトフラグが“１”の時のみＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３に追加する（図４ステップＳ７）。そして、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、該シーダーに対して、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ対象のリーチャーが存在しないことを通知する（図４ステップＳ８）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１３が空でない場合、リストから最も早くリストに登録されたリーチャーを選択し（図４ステップＳ２）、リストから選択したリーチャーを消去し（図４ステップＳ３）、シーダーとリーチャーとのペア（Ｐａｉｒ）をＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト３２１１に状態（ｓｔａｔｅ）＝ネゴシエーティング（ｎｅｇｏｔｉａｔｉｎｇ）として登録する（図４ステップＳ４）。そして、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、該シーダーに対して、対象リーチャーのＰｅｅｒＩＤを通知する（図４ステップＳ５）。

図５には、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを希望するリーチャーが、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇをトラッカー３に要求した際のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０の動作フローを示している。

リーチャーを希望するピアが、トラッカー３に対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの要求を行うと、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、まず、リーチャーがＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇに必要なｄｅｐｏｓｉｔを保有しているかどうかを通貨管理部５に対して問い合わせ（図５ステップＳ１１）、ｄｅｐｏｓｉｔを保有していなければ（不足）、要求を拒絶して処理を終了する。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、ｄｅｐｏｓｉｔを保有している場合、通貨管理部５からｄｅｐｏｓｉｔ分の通貨を取得する（図５ステップＳ１２）。さらに、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３をチェックする（図５ステップＳ１３）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３が空の場合、ウェイトフラグをチェックし（図５ステップＳ１８）、ウェイトフラグが“１”の時のみＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト３２１２に追加する（図５ステップＳ１９）。そして、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、該リーチャーに対して、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ対象のシーダーが存在しないことを通知する（図５ステップＳ２０）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト３２１３が空でない場合、リストから最も早くリストに登録されたシーダーを選択し（図５ステップＳ１４）、リストから選択したシーダーを消去し（図５ステップＳ１５）、シーダーとリーチャーとのペアをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト３２１１に状態＝ネゴシエーションとして登録する（図５ステップＳ１６）。そして、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、該リーチャーに対して、対象のシーダーのＰｅｅｒＩＤを通知する（図５ステップＳ１７）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求しているピア、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ対象の対向ピアが通知された時には（図４ステップＳ５，図５ステップＳ１７）、該対向ピアに対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの実行要求を行う。

図６には図２のピア１における対向ピアとＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を実施する際の動作を示している。

ピア１は、対向ピアに対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの実行を要求し（図６ステップＳ２１）、対向ピアからＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの許可応答が返ってきた場合（図６ステップＳ２２）、トラッカー３に対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ接続が成功したことを通知する（図６ステップＳ２３）。

ピア１は、許可応答が返ってこない場合（図６ステップＳ２２）、トラッカー３に対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ接続が失敗したことを通知すると共に（図６ステップＳ２４）、再度、トラッカー３に対してＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの対向ピア取得を要求する（図６ステップＳ２５）。

Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、ピア１からＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの接続成功を通知されると（図６ステップＳ２３）、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト３２１１の該当エントリ（Ｅｎｔｒｙ）の状態をネゴシエーションからランニング（ｒｕｎｎｉｎｇ）に変更する。

また、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部３２０は、ピアからＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの接続が失敗したことが通知されると（図６ステップＳ２４）、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリスト３２１１から該当エントリを削除する。

図７には、シーダーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示し、図８には、リーチャーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示している。

次に、通貨管理部５について説明する。まず、通常のコンテンツの送受信における通貨の変動について述べる。

コンテンツの送受信を行ったピアは、通貨管理部５に対して、ＰｅｅｒＩＤ、ＣｏｎｔｅｎｔＩＤ、対向ＰｅｅｒＩＤ、時刻、転送種別、Ｕｐｌｏａｄ Ｂｙｔｅ量、Ｄｏｗｎｌｏａｄ Ｂｙｔｅ量という情報を定期的に送出する。

通貨管理部５は、収集した情報を元にピア間での通貨の増減を算出する。各ピアの通貨の増減量は、
通貨の増減量
＝（Ｕｐｌｏａｄ Ｂｙｔｅ量−Ｄｏｗｎｌｏａｄ Ｂｙｔｅ量）
＊ＣｏｎｔｅｎｔＲａｔｅ
という式にて算出される。

ここで、注意しなければならないのは、ピア間で完全な時刻同期がとれているわけではないので、同一時刻に２つのピアから収集したＵｐｌｏａｄ Ｂｙｔｅ量／Ｄｏｗｎｌｏａｄ Ｂｙｔｅ量の情報が一致するとは限らない点である。よって、ピア間の転送量情報の算出に当たっては、両方のピアから収集された情報の平均値を利用する。

図９は図２に示す通貨管理部５で算出される通貨の増減例を示す図である。実際には、２つのピアからのデータ転送量の収集及び価格の更新タイミングは同時に行う必要がなく、それぞれ、半分の値を更新すればよい。

コンテンツ配信システム内では、２つのピアのアップロード・ダウンロード量を比較し、不正な申告を行っているピアを検出した場合に取得通貨を無効化し、コンテンツ配信システムの利用停止等のペナルティを与える等の不正アクセス対策も必要である。

また、本実施の形態では、通貨の変動量を算出した結果、通貨の減少量がピアの保有通貨よりも大きくなることが考えられる。そのような際の通貨の管理方法としてはいくつかの運用が考えられる。この運用の一つの方法としては、保有通貨が０以下にならないようにすることである。

次に、コンテンツの基本価値であるＣｏｎｔｅｎｔＲａｔｅについて説明する。ＣｏｔｅｎｔＲａｔｅは、Ｃｏｎｔｅｎｔを１ｂｙｔｅ送受信するための価格であり、Ｃｏｎｔｅｎｔの需要に応じて変動する。

トラッカー３は、Ｃｏｎｔｅｎｔに関して、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを実施しているピアの数（Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇテーブルのエントリ数）であるＮｕｍＣｏｎｓｔａｎｔＳｅｅｄｉｎｇＵｓｉｎｇと、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求しているピアの数（Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｒｅｑｕｅｓｔリストのエントリ数）であるＮｕｍＣｏｎｓｔａｎｔＳｅｅｉｎｄｇＲｅｑｕｅｓｔｅｒとを定期的に報告する。

通貨管理部５は、トラッカー３よりＮｕｍＣｏｎｓｔａｎｔＳｅｅｄｉｎｇＵｓｉｎｇとＮｕｍＣｏｎｓｔａｎｔＳｅｅｄｉｎｇＲｅｑｕｅｓｔｅｒの情報とを受信すると、該当ＣｏｎｔｅｎｔのＣｏｎｔｅｎｔＲａｔｅを、
ＣｏｎｔｅｎｔＲａｔｅ
＝１＋α＊（ＮｕｍＣｏｎｓｔａｎｔＳｅｅｄｉｎｇＵｓｉｎｇ
＋ＮｕｍＣｏｎｓｔａｎｔＳｅｅｄｉｎｇＲｅｑｕｅｓｔｅｒ）
という式で得られる値に更新する。上記の式において、αは定数パラメータ（例えば、α＝０．１）である。

ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇの理由数及び要求数が多い程、Ｃｏｎｔｅｎｔの人気が高いと判断されるので、Ｃｏｎｔｅｎｔの基本価格であるＣｏｎｔｅｎｔＲａｔｅも高い値となる。

さらに、本実施の形態におけるＣｏｎｓｔａｎｔＳｅｅｄｉｎｇの価格について説明する。ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ契約を行った場合のピア間の通貨の変動は、通常の通貨変動とは異なり、以下のように計算される。尚、ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇのＣｏｎｔｅｎｔＲａｔｅは、ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ契約が結ばれた際のＣｏｎｔｅｎｔＲａｔｅを利用し、契約実行中は変動が無いものとする。

リーチャー側の支出金額は、
契約料：ＣｏｎｔｅｎｔＬｅｎｇｔｈ＊β＊ＣｏｎｔｅｎｔＲａｔｅ
転送料：Ｄｏｗｎｌｏａｄ Ｂｙｔｅ量＊γ＊ＣｏｎｔｅｎｔＲａｔｅ
Ｄｅｐｏｓｉｔ：ＣｏｎｔｅｎｔＬｅｎｇｔｈ＊（β＋γ）
＊ＣｏｎｔｅｎｔＲａｔｅ
となる。

シーダー側の入手金額は、
転送料：Ｕｐｌｏａｄ Ｂｙｔｅ量＊（β＋γ）＊ＣｏｎｔｅｎｔＲａｔｅ
となる。ここで、β及びγは定数パラメータ（例えば、β＝γ＝１）である。また、ＣｏｎｔｅｎｔＬｅｎｇｔｈ：Ｃｏｎｔｅｎｔの長さである。

リーチャーは、ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ要求時にコンテンツを全てＣｏｎｓｔａｎｔＳｅｅｄｉｎｇによるダウンロードした量に相当するＤｅｐｏｓｉｔを支払う。ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ要求後、直ぐに契約が成立せずに、ＣｏｎｔｅｎｔＲａｔｅの変動があった場合には、再度、Ｄｅｐｏｓｉｔの算出を行い、差額の支払い、もしくは払い戻しを行う。

リーチャーが、最終的に支払うＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ料金は、契約料及び転送料であり、ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ契約終了時に、ｄｅｐｏｓｉｔからＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ料金を引いた額が払い戻される。

シーダーは、リーチャーに対するアップロード量に応じて転送料金を入手する。Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを実施するに当たって、リーチャーは、契約料が必要であるが、シーダーは、契約料を入手できず、アップロードのみにより通貨を入手する。

リーチャーは、契約料を必要とすることで、安易に契約を結んだり・破棄したりすることを抑制することができる。逆に、シーダーは、データアップロードのみにより通貨を入手することで、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの契約だけを実行してアップロードを行わない、もしくはデータレートを抑制するような状況を防止することができる。

リーチャーが、ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ契約を行ったシーダーから全てのＣｏｎｔｅｎｔを入手した時、リーチャーからシーダーに支払われる金額が一致する。そうでない場合には、通貨管理部５が差額を入手する。

リーチャーは、複数のシーダーと同時にＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ契約を結ぶことも可能であるが、各シーダーに契約料を払う必要がある。

ビットトレント［ＢｉｔＴｏｒｒｅｎｔ（登録商標）］では、ピアが高速にダウンロードするまでに時間がかかるが、本実施の形態では、スウォームに参加する際に特定のシーダーからコンテンツをダウンロードすることを保証することにより、ダウンロード開始直後から高速にダウンロードすることが可能となる。

また、ダウンロード対象のシーダーが途中で該当ピアへのアップロードを停止し、他のピアへアップロードすることがないため、安定してダウンロードすることが可能である。

図１０は本発明の第１の実施の形態におけるＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を実行しているシーダーのアップロード先ピアの選択例を示す図である。図１０において、シーダーと動作しているピアは、アップロード対象ピアとして、必ずＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を結んだピアを選択する。

その他のアップロードピアの選択は、通常のビットトレントのピア選択アルゴリズムに従う。通常、シーダーは、選択したピアのアップロードレートを監視し、アップロード速度の最も遅いピアは、定期的に接続が切断されるが、Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を結んだリーチャーは、継続的にシーダーからアップロードされることが保証される。

シーダーの他の動作及びリーチャーの動作は、特にビットトレントから変更を加えなくてもＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を結んだピア間で継続的にデータの転送が行われることが保証される。

尚、通貨変動量算出部３５は、通常転送時に、シーダーに対してアップロード容量×ＣｏｎｔｅｎｔＲａｔｅの通貨を付与する。ピアは、シーダーとなってアップロード処理を行うことで、初めて通貨を入手することが可能である。

このように、本実施の形態では、ピアが入手した通貨を利用することで、他のコンテンツを優先的にダウンロードすることが可能となるため、コンテンツダウンロード後にもシーダーとなり、アップロード処理を継続実行する理由付けが発生する。

よって、本実施の形態では、スウォーム内のシーダーの比率が増加し、リーチャーはアップロード速度よりも高いダウンロード速度でコンテンツを取得することが可能となる。

尚、上述した本発明のコンテンツ配信方法は、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）回線等のアップロード帯域に比べてダウンロード帯域が極端に大きい回線を利用するユーザが多いスウォームにおいても適用可能である。

例えば、ビットトレントを利用している多くのユーザが、ＡＤＳＬ回線等のダウンロード帯域に比べてアップロード帯域が極端に小さい回線を利用している場合、スウォームを構成するシーダーの割合が小さい状況では、リーチャーの平均ダウンロード速度が平均アップロード速度よりも大きくならず、アクセス回線のダウンロード帯域を十分に利用することができない。

このような場合でも、本発明では、上述したコンテンツ配信方法を用いることで、つまりスウォームを構成するシーダーの割合を大きくすることで、利用ユーザの多くがＡＤＳＬ回線等のダウンロード帯域に比べてアップロード帯域が極端に小さい回線を利用している状況においても、各リーチャーがアクセス回線のダウンロード帯域に近いレートでダウンロードすることが可能となる。

以上、実施形態（及び実施例）を参照して本願発明を説明したが、本願発明は上記実施形態（及び実施例）に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は２００８年４月９日に出願された日本出願特願２００８−１００９０８を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、スウォームを構成するシーダーの割合を大きくし、各リーチャーのピアがアクセス回線のダウンロード帯域に近いレートでダウンロードすることに貢献できるものである。

本発明の第１の実施の形態によるコンテンツ配信システムの全体構成例を示すブロック図である。 本発明の第１の実施の形態によるコンテンツ配信システムの詳細構成例を示す図である。 図２のトラッカー内の優先契約管理部の構成例を示すブロック図である。 図３のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部におけるシーダーがＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求した際の動作を示すフローチャートである。 図３のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理部におけるリーチャーがＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇを要求した際の動作を示すフローチャートである。 図２のピアにおける対向ピアとＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を実施する際の動作を示すフローチャートである。 本発明の第１の実施の形態におけるシーダーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示すシーケンスチャートである。 本発明の第１の実施の形態におけるリーチャーがＷａｉｔｉｎｇリストに入る場合のＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の動作例を示すシーケンスチャートである。 図２に示す通貨管理部で算出される通貨の増減例を示す図である。 本発明の第１の実施の形態におけるＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約を実行しているシーダーのアップロード先ピアの選択例を示す図である。 ビットトレントを利用した本発明に関連するコンテンツ配信システムの全体構成例を示すブロック図である。 ビットトレントを利用した本発明に関連するコンテンツ配信システムの詳細構成例を示すブロック図である。

１，１−１−１〜１−１−７，
１−２−１〜１−２−５，
１−３−１〜１−３−７ ピア
２，２−１〜２−３ スウォーム
３，３−１〜３−３ トラッカー
４，４−１〜４−３ トレントＷｅｂサーバ
５ 通貨管理部
１０ 接続ピア管理部
１１ 接続ピア送受信部
１２ 転送制御部
１３ 優先転送制御部
１４ 優先契約要求部
１５ 転送量通知部
３０ ピアリスト
３１ ピアリスト応答部
３２ 優先契約管理部
３３ ＣｏｎｔｅｎｔＲａｔｅ管理部
３４ 転送量受信部
３５ 通貨変動量算出部
５０ Ｃｕｒｒｅｎｃｙ更新部
５１ Ｃｕｒｒｅｎｃｙテーブル
３２０ ＣｏｎｓｔａｎｔＳｅｅｄｉｎｇ管理部
３２１ 記憶部
３２１１ Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ
Ｗｏｒｋｉｎｇ Ｐａｉｒリスト
３２１２ Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ
Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリスト
３２１３ Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ
Ｓｅｅｄｅｒ Ｗａｉｔｉｎｇリスト

Claims (32)

1. コンテンツをダウンロード中のリーチャーに対して、そのダウンロード完了後に前記コンテンツを提供するシーダーとなるようにインセンティブを与えることを特徴とするコンテンツ配信システム。
2. 前記コンテンツを受信するピア毎に当該ピアの保有するインセンティブを管理する通貨管理手段を含み、
   前記ピア各々は、ピア間とのコンテンツのアップロードデータ量及びダウンロードデータ量を通知する手段を含み、
   前記スウォームは、前記ピア各々のアップロード貢献量に応じて前記インセンティブ量を算出する手段を含むことを特徴とする請求項１に記載のコンテンツ配信システム。
3. ダウンロード対象のコンテンツ毎のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークである複数のスウォームを含むコンテンツ配信システムであって、
   前記スウォームは、前記コンテンツのダウンロード及びアップロードを実行する複数のピアと、前記スウォームに参加するピアの一覧を管理する手段と、前記ピアに付与されたインセンティブの変動量を算出する通貨変動量算出手段と、前記ピア間で優先的にデータを送受信するための優先転送契約を結ぶことを許可・管理する優先契約管理手段とを有し、
   前記ピアは、前記ピア間でアップロードしたデータ量及びダウンロードしたデータ量を前記通貨変動量算出手段に通知する転送量通知手段と、前記優先契約管理手段に対して前記優先転送契約を要求する優先契約要求手段と、前記ピア間での転送を行う転送制御手段と、前記優先転送契約を行ったピアとの間で優先的に転送を行う優先転送制御手段とを有し、
   前記通貨変動量算出手段は、前記ピア間のアップロードしたデータ量及びダウンロードしたデータ量に応じて前記インセンティブの増減量を算出しかつその算出結果に基づく要求を前記コンテンツを受信するピア毎に前記インセンティブの保有量の管理を行う通貨管理手段に対して通知し、
   前記通貨管理手段は、前記通貨変動量算出手段からの要求に応じて前記インセンティブの量を更新し、
   前記優先契約要求手段は、前記インセンティブの保有量に基づいて前記優先契約管理手段に対して前記優先転送契約を要求することを特徴とするコンテンツ配信システム。
4. 前記優先契約管理手段は、前記ピアからの優先転送契約要求を受信し、アップロード処理を行うシーダーとダウンロード処理を行うリーチャーとに関して、前記優先転送契約を実行中のリーチャートとシーダーとの組をＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリストに保持し、対向のシーダーが見つかっていないリーチャーをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリストに保持し、対向のリーチャーが見つかっていないシーダーをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリストに保持するＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理手段を含み、
   前記シーダーとして前記優先転送契約を結んだピアの前記優先転送制御手段は、契約対象のリーチャーに対して継続的にコンテンツをアップロードし続けることを特徴とする請求項３に記載のコンテンツ配信システム。
5. 前記通貨変動量算出手段は、前記コンテンツ固有のＣｏｎｔｅｎｔＲａｔｅパラメータを保有し、前記ピア各々が前記スウォーム内でデータ転送を実施することによる前記インセンティブの変動量がＣｏｎｔｅｎｔＲａｔｅに比例して更新されることを特徴とする請求項３または請求項４に記載のコンテンツ配信システム。
6. 前記ピアは、定期的にアップロード・ダウンロードしたデータ量を通知し、
   前記通貨変動量算出手段は、前記ＣｏｎｔｅｎｔＲａｔｅを動的に更新する手段を含み、
   前記通貨変動量算出手段が一定期間に流れた前記ピア間のアップロードした量及びダウンロードした量に従って定期的に前記インセンティブの変動量を算出することを特徴とする請求項５に記載のコンテンツ配信システム。
7. 前記通貨変動量算出手段は、前記ピア間の転送時のインセンティブの変動量を前記コンテンツの（アップロード量―ダウンロード量）×ＣｏｎｔｅｎｔＲａｔｅによって算出することを特徴とする請求項５または請求項６に記載のコンテンツ配信システム。
8. 前記通貨変動量算出手段は、前記コンテンツを固定長サイズに分割したピース全てを保有してアップロード処理のみを行うシーダーに対して、前記ピア間の転送時のインセンティブの変動量を「アップロード量×ＣｏｎｔｅｎｔＲａｔｅ」によって算出することを特徴とする請求項５または請求項６に記載のコンテンツ配信システム。
9. 前記通貨変動量算出手段は、あるピアから対向ピアとのアップロード情報及びダウンロード情報を入手した際に、前記ピアと前記対向ピアとの量に対して（アップロード量−ダウンロード量）×ＣｏｎｔｅｎｔＲａｔｅ×１／２を前記ピア間の転送時のインセンティブの変動量として算出することを特徴とする請求項６に記載のコンテンツ配信システム。
10. 前記通貨変動量算出手段は、「ＣｏｎｔｅｎｔＲａｔｅ＝リーチャー数／シーダー数」として算出することを特徴とする請求項６に記載のコンテンツ配信システム。
11. 前記通貨変動量算出手段は、「ＣｏｎｔｅｎｔＲａｔｅ＝リーチャー総アップロード帯域／シーダー総アップロード帯域」として算出することを特徴とする請求項６に記載のコンテンツ配信システム。
12. 前記通貨変動量算出手段は、コンテンツ運用業者によって重要性の高いと指定されたコンテンツのＣｏｎｔｅｎｔＲａｔｅを高く設定することを特徴とする請求項６に記載のコンテンツ配信システム。
13. 前記通貨変動量算出手段は、前記ＣｏｎｔｅｎｔＲａｔｅを前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの契約数とリーチャー要求数が多いほど高い値に設定することを特徴とする請求項６に記載のコンテンツ配信システム。
14. 前記通貨変動量算出手段は、前記ＣｏｎｔｅｎｔＲａｔｅを「１＋（Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約数＋Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ要求数）×α」（αは固定パラメータ）として算出することを特徴とする請求項１３に記載のコンテンツ配信システム。
15. 前記優先契約管理手段は、前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの契約における前記シーダーの入手インセンティブと前記リーチャーの支払インセンティブとに関して、
    前記リーチャーが契約料とデータダウンロード量とに比例するデータダウンロードのインセンティブを支払い、
    前記シーダーがデータアップロード量に比例するデータアップロードのインセンティブを入手することを特徴とする請求項４に記載のコンテンツ配信システム。
16. 前記優先契約管理手段は、
    前記リーチャーが前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの要求時に、全てのコンテンツをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約によってダウンロードした額に相当する分のＤｅｐｏｓｉｔの支払を行い、
    前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の完了時に、当該Ｄｅｐｏｓｉｔから実際に前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇのリーチャー利用料との差分を入手することを特徴とする請求項１５に記載のコンテンツ配信システム。
17. コンテンツをダウンロード中のリーチャーに対して、そのダウンロード完了後に前記コンテンツを提供するシーダーとなるようにインセンティブを与えることを特徴とするコンテンツ配信方法。
18. 前記コンテンツを受信するピア毎に当該ピアの保有するインセンティブを通貨管理手段が管理し、
    前記ピア各々が、ピア間とのコンテンツのアップロードデータ量及びダウンロードデータ量を通知し、
    前記スウォーム内において、前記ピア各々のアップロード貢献量に応じて前記インセンティブ量を算出することを特徴とする請求項１７に記載のコンテンツ配信方法。
19. ダウンロード対象のコンテンツ毎のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）ネットワークである複数のスウォームを含むシステムに用いるコンテンツ配信方法であって、
    前記スウォームに、前記コンテンツのダウンロード及びアップロードを実行する複数のピアと、前記スウォームに参加するピアの一覧を管理する手段と、前記ピアに付与されたインセンティブの変動量を算出する通貨変動量算出手段と、前記ピア間で優先的にデータを送受信するための優先転送契約を結ぶことを許可・管理する優先契約管理手段とを設け、
    前記ピアに、前記ピア間でアップロードしたデータ量及びダウンロードしたデータ量を前記通貨変動量算出手段に通知する転送量通知手段と、前記優先契約管理手段に対して前記優先転送契約を要求する優先契約要求手段と、前記ピア間での転送を行う転送制御手段と、前記優先転送契約を行ったピアとの間で優先的に転送を行う優先転送制御手段とを設け、
    前記通貨変動量算出手段が、前記ピア間のアップロードしたデータ量及びダウンロードしたデータ量に応じて前記インセンティブの増減量を算出しかつその算出結果に基づく要求を前記コンテンツを受信するピア毎に前記インセンティブの保有量の管理を行う通貨管理手段に対して通知し、
    前記通貨管理手段が、前記通貨変動量算出手段からの要求に応じて前記インセンティブの量を更新し、
    前記優先契約要求手段が、前記インセンティブの保有量に基づいて前記優先契約管理手段に対して前記優先転送契約を要求することを特徴とするコンテンツ配信方法。
20. 前記優先契約管理手段にＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理手段を設け、
    前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ管理手段が、前記ピアからの優先転送契約要求を受信し、アップロード処理を行うシーダーとダウンロード処理を行うリーチャーとに関して、前記優先転送契約を実行中のリーチャートとシーダーとの組をＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｗｏｒｋｉｎｇ Ｐａｉｒリストに保持し、対向のシーダーが見つかっていないリーチャーをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリストに保持し、対向のリーチャーが見つかっていないシーダーをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ Ｗａｉｔｉｎｇリストに保持し、
    前記シーダーとして前記優先転送契約を結んだピアの前記優先転送制御手段は、契約対象のリーチャーに対して継続的にコンテンツをアップロードし続けることを特徴とする請求項１９に記載のコンテンツ配信方法。
21. 前記通貨変動量算出手段が、前記コンテンツ固有のＣｏｎｔｅｎｔＲａｔｅパラメータを保有し、前記ピア各々が前記スウォーム内でデータ転送を実施することによる前記インセンティブの変動量がＣｏｎｔｅｎｔＲａｔｅに比例して更新されることを特徴とする請求項１９または請求項２０に記載のコンテンツ配信方法。
22. 前記ピアが、定期的にアップロード・ダウンロードしたデータ量を通知し、
    前記通貨変動量算出手段が、前記ＣｏｎｔｅｎｔＲａｔｅを動的に更新し、
    前記通貨変動量算出手段が一定期間に流れた前記ピア間のアップロードした量及びダウンロードした量に従って定期的に前記インセンティブの変動量を算出することを特徴とする請求項２１に記載のコンテンツ配信方法。
23. 前記通貨変動量算出手段が、前記ピア間の転送時のインセンティブの変動量を前記コンテンツの（アップロード量―ダウンロード量）×ＣｏｎｔｅｎｔＲａｔｅによって算出することを特徴とする請求項２１または請求項２２に記載のコンテンツ配信方法。
24. 前記通貨変動量算出手段が、前記コンテンツを固定長サイズに分割したピース全てを保有してアップロード処理のみを行うシーダーに対して、前記ピア間の転送時のインセンティブの変動量を「アップロード量×ＣｏｎｔｅｎｔＲａｔｅ」によって算出することを特徴とする請求項２１または請求項２２に記載のコンテンツ配信方法。
25. 前記通貨変動量算出手段が、あるピアから対向ピアとのアップロード情報及びダウンロード情報を入手した際に、前記ピアと前記対向ピアとの量に対して（アップロード量−ダウンロード量）×ＣｏｎｔｅｎｔＲａｔｅ×１／２を前記ピア間の転送時のインセンティブの変動量として算出することを特徴とする請求項２２に記載のコンテンツ配信方法。
26. 前記通貨変動量算出手段が、「ＣｏｎｔｅｎｔＲａｔｅ＝リーチャー数／シーダー数」として算出することを特徴とする請求項２２に記載のコンテンツ配信方法。
27. 前記通貨変動量算出手段が、「ＣｏｎｔｅｎｔＲａｔｅ＝リーチャー総アップロード帯域／シーダー総アップロード帯域」として算出することを特徴とする請求項２２に記載のコンテンツ配信方法。
28. 前記通貨変動量算出手段が、コンテンツ運用業者によって重要性の高いと指定されたコンテンツのＣｏｎｔｅｎｔＲａｔｅを高く設定することを特徴とする請求項２２に記載のコンテンツ配信方法。
29. 前記通貨変動量算出手段が、前記ＣｏｎｔｅｎｔＲａｔｅを前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの契約数とリーチャー要求数が多いほど高い値に設定することを特徴とする請求項２２に記載のコンテンツ配信方法。
30. 前記通貨変動量算出手段が、前記ＣｏｎｔｅｎｔＲａｔｅを「１＋（Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約数＋Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ Ｌｅｅｃｈｅｒ要求数）×α」（αは固定パラメータ）として算出することを特徴とする請求項２９に記載のコンテンツ配信方法。
31. 前記優先契約管理手段が、前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの契約における前記シーダーの入手インセンティブと前記リーチャーの支払インセンティブとに関して、
    前記リーチャーが契約料とデータダウンロード量とに比例するデータダウンロードのインセンティブを支払い、
    前記シーダーがデータアップロード量に比例するデータアップロードのインセンティブを入手することを特徴とする請求項２０に記載のコンテンツ配信方法。
32. 前記優先契約管理手段が、
    前記リーチャーの前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇの要求時に、全てのコンテンツをＣｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約によってダウンロードした額に相当する分のＤｅｐｏｓｉｔの支払を行い、
    前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇ契約の完了時に、当該Ｄｅｐｏｓｉｔから実際に前記Ｃｏｎｓｔａｎｔ Ｓｅｅｄｉｎｇのリーチャー利用料との差分を入手することを特徴とする請求項３１に記載のコンテンツ配信方法。

Images