(57)【要約】【課題】ピアツーピア（Ｐ２Ｐ）ネットワークを利用したコンテンツ配信システムにおいて、コンテンツを直ぐに閲覧したいユーザが可能な限り早く動画を閲覧することを可能とする。【解決手段】高優先ダウンロードピアと、低優先ダウンロードピア、アップロード専用ピアを区別し、直ぐに動画を閲覧した高優先ダウンロードピアをピアツーピア（Ｐ２Ｐ）ネットワークに追加する際に、合わせて低優先ダウンロードピア及びアップロード専用ピアの追加を行い高優先ダウンロードピア数の相対数を低く抑え、高優先ダウンロードピアに対して高優先でのダウンロード処理を提供する。【選択図】図１
2009151531.tif 000002
【特許請求の範囲】
【請求項１】
属性クラス毎に分類された複数のピアと、
前記複数のピアの各々の状態を管理するピア管理サーバと、
属性クラス毎のピア数が属性クラスピア追加管理条件を満足するように前記複数のピアの管理を行い、前記複数のピアのうち所定のピアから所定の属性クラスへの追加要求が行われた際に、ピア追加要求条件を満足できない場合、前記ピア管理サーバに問い合わせを行い、前記ピア管理サーバから、前記ピア追加要求条件を満足するように選択された他の属性クラスのピアに基づいて作成された支援用ピアリストを取得し、前記追加要求を行ったピアと前記支援用ピアリスト内のピアとをピアツーピア（Ｐ２Ｐ）ネットワークに追加するトラッカーと
を含む
コンテンツ配信システム。
【請求項２】
請求項１に記載のコンテンツ配信システムであって、
前記ピア追加要求条件は、「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」であり、
前記属性クラスピア追加管理条件は、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」である
コンテンツ配信システム。
【請求項３】
請求項１又は２に記載のコンテンツ配信システムであって、
前記トラッカーは、コンテンツのダウンロードが完了したピアからダウンロード完了の通知を受けると、該ピアを削除予約リストの末尾に追加し、ピア削除管理条件を満足する範囲で、前記削除予約リストの先頭のエントリを管理対象から削除し、前記ピアツーピア（Ｐ２Ｐ）ネットワークからのピアの離脱を許可する
コンテンツ配信システム。
【請求項４】
請求項３に記載のコンテンツ配信システムであって、
前記ピア削除管理条件は、「（高優先ダウンロードピア数＋γ）＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」である
コンテンツ配信システム。
【請求項５】
請求項１乃至４のいずれか一項に記載のコンテンツ配信システムであって、
前記ピア管理サーバは、前記支援用ピアリストを作成する場合、アップロード専用ピアの選択を行い、前記選択されたアップロード専用ピアでピア追加条件を満足できない場合、低優先ダウンロードピアの選択を行う
コンテンツ配信システム。
【請求項６】
請求項１乃至５のいずれか一項に記載のコンテンツ配信システムであって、
前記ピア管理サーバは、前記支援用ピアリストを作成する場合、アップロード専用ピアの選択を行う際に保有コンテンツの少ないピアを優先する
コンテンツ配信システム。
【請求項７】
請求項１乃至６のいずれか一項に記載のコンテンツ配信システムであって、
前記ピア管理サーバは、前記支援用ピアリストを作成する場合、低優先ダウンロードピアの選択を行う際に、将来コンテンツが閲覧される可能性の高いピアを優先して選択する
コンテンツ配信システム。
【請求項８】
請求項７に記載のコンテンツ配信システムであって、
前記ピア管理サーバは、将来コンテンツが閲覧される可能性の高いピアを選択する際に、前記各ピアを利用するユーザ同士が知り合いであるかどうかを判別するためのピア関係性テーブルを参照し、知り合いを何人経由すれば到達できるかを示す知り合いホップ数に基づいて、高優先ダウンロードピアとの知り合いホップ数が小さいピアを優先的に低優先ダウンロードピアとして割り当てる
コンテンツ配信システム。
【請求項９】
ピアからのダウンロード要求に応じて、ピアの要求クラスをチェックし、前記要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加し、前記要求クラスが高優先ダウンロードであれば、ピア追加要求条件を満足しているかどうかをチェックし、前記ピア追加要求条件を満足している場合、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加する要求クラスチェック手段と、
前記ピア追加要求条件を満足しない場合、前記ピアの状態を管理するピア管理サーバに対して、前記ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行う問い合わせ手段と、
前記ピア管理サーバに対する問い合わせ結果を確認し、前記ピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブルに含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとして前記ピアツーピア（Ｐ２Ｐ）ネットワークに追加する問い合わせ結果確認手段と
を具備する
トラッカー。
【請求項１０】
請求項９に記載のトラッカーであって、
前記ピア追加要求条件は、「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」であり、
前記属性クラスピア追加管理条件は、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」である
トラッカー。
【請求項１１】
請求項９又は１０に記載のトラッカーであって、
離脱要求のあったピアを削除予約リストの末尾に追加するリスト管理手段と、
ピア削除管理条件を満足しているかどうかをチェックし、前記ピア削除管理条件を満足する場合、前記削除予約リストにエントリが存在するかどうかをチェックし、前記削除予約リストにエントリが存在する場合、前記削除予約リストの先頭のエントリにあるピアをピアツーピア（Ｐ２Ｐ）ネットワークから削除する条件チェック手段と
を更に具備する
トラッカー。
【請求項１２】
請求項１１に記載のトラッカーであって、
前記ピア削除管理条件は、「（高優先ダウンロードピア数＋γ）＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」である
トラッカー。
【請求項１３】
請求項９乃至１２のいずれか一項に記載のトラッカーであって、
前記問い合わせ手段は、問い合わせ処理時に、前記ピア管理サーバに対して属性クラスピア追加管理条件とコンテンツＩＤを通知する
トラッカー。
【請求項１４】
ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なアイドル状態のピアを示すアイドルピア管理リスト、及び支援用ピアを示す支援用ピアリストを管理するテーブル管理手段と、
前記アイドルピア管理リストを参照し、トラッカーから通知されたコンテンツＩＤのコンテンツを保有するピアを検索し、前記コンテンツを保有するピアが存在する場合、前記コンテンツを保有するピアを前記支援用ピアリストに追加するピア検索手段と、
前記支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックし、前記支援用ピアリストが前記支援用ピア数条件を満足する場合、前記支援用ピアリストを確定し、前記支援用ピアリストを前記トラッカーに通知し、前記支援用ピアリストに追加されたピアを、前記アイドルピア管理リストから削除する条件チェック手段と
を具備する
ピア管理サーバ。
【請求項１５】
請求項１４に記載のピア管理サーバであって、
前記ピア検索手段は、前記支援用ピア数条件を満足する数のアップロード専用ピアを見つけられず、支援用ピアリストが支援用ピア数条件を満足しなかった場合、低優先ダウンロードピアの検索を行う
ピア管理サーバ。
【請求項１６】
請求項１５に記載のピア管理サーバであって、
前記条件チェック手段は、前記支援用ピア数条件を満足するだけの低優先ダウンロードピアが存在しない場合、条件未達として、前記トラッカーに応答を返す
ピア管理サーバ。
【請求項１７】
請求項１５又は１６に記載のピア管理サーバであって、
前記条件チェック手段は、前記支援用ピア数条件を満足する低優先ダウンロードピアが発見できた場合、発見できたアップロード専用ピアと低優先ダウンロードピアを前記支援用ピアリストに追加し、前記支援用ピアリストを確定し、前記支援用ピアリストを前記トラッカーに通知する
ピア管理サーバ。
【請求項１８】
請求項１５乃至１７のいずれか一項に記載のピア管理サーバであって、
低優先ダウンロードピアを選択する際の候補が複数存在する際に、知り合いを何人経由すれば到達できるかを示す知り合いホップ数に基づいて、高優先ダウンロードピアとの知り合いホップ数が小さいピアを優先的に低優先ダウンロードピアとして割り当てる関係性管理手段
を更に具備する
ピア管理サーバ。
【請求項１９】
属性クラス毎に分類された複数のピアの各々の状態を管理するステップと、
属性クラス毎のピア数が属性クラスピア追加管理条件を満足するように前記複数のピアの管理を行い、前記複数のピアのうち所定のピアから所定の属性クラスへの追加要求が行われた際に、ピア追加要求条件を満足できない場合、前記ピア追加要求条件を満足するように他の属性クラスのピアを選択して支援用ピアリストを作成するステップと、
前記追加要求を行ったピアと前記支援用ピアリスト内のピアとをピアツーピア（Ｐ２Ｐ）ネットワークに追加するステップと
を含む
コンテンツ配信方法。
【請求項２０】
請求項１９に記載のコンテンツ配信方法であって、
前記ピア追加要求条件は、「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」であり、
前記属性クラスピア追加管理条件は、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」である
コンテンツ配信方法。
【請求項２１】
請求項１９又は２０に記載のコンテンツ配信方法であって、
コンテンツのダウンロードが完了したピアからダウンロード完了の通知を受けると、該ピアを削除予約リストの末尾に追加し、ピア削除管理条件を満足する範囲で、前記削除予約リストの先頭のエントリを管理対象から削除し、前記ピアツーピア（Ｐ２Ｐ）ネットワークからのピアの離脱を許可するステップ
を更に含む
コンテンツ配信方法。
【請求項２２】
請求項２１に記載のコンテンツ配信方法であって、
前記ピア削除管理条件は、「（高優先ダウンロードピア数＋γ）＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」である
コンテンツ配信方法。
【請求項２３】
請求項１９乃至２２のいずれか一項に記載のコンテンツ配信方法であって、
前記支援用ピアリストを作成する場合、アップロード専用ピアの選択を行い、前記選択されたアップロード専用ピアでピア追加条件を満足できない場合、低優先ダウンロードピアの選択を行うステップ
を更に含む
コンテンツ配信方法。
【請求項２４】
請求項１９乃至２３のいずれか一項に記載のコンテンツ配信方法であって、
前記支援用ピアリストを作成する場合、アップロード専用ピアの選択を行う際に保有コンテンツの少ないピアを優先するステップ
を更に含む
コンテンツ配信方法。
【請求項２５】
請求項１９乃至２４のいずれか一項に記載のコンテンツ配信方法であって、
前記支援用ピアリストを作成する場合、低優先ダウンロードピアの選択を行う際に、将来コンテンツが閲覧される可能性の高いピアを優先して選択するステップ
を更に含む
コンテンツ配信方法。
【請求項２６】
請求項２５に記載のコンテンツ配信方法であって、
将来コンテンツが閲覧される可能性の高いピアを選択する際に、前記各ピアを利用するユーザ同士が知り合いであるかどうかを判別するためのピア関係性テーブルを参照し、知り合いを何人経由すれば到達できるかを示す知り合いホップ数に基づいて、高優先ダウンロードピアとの知り合いホップ数が小さいピアを優先的に低優先ダウンロードピアとして割り当てるステップ
を更に含む
コンテンツ配信方法。
【請求項２７】
コンピュータをトラッカーとして機能させるためのプログラムであって、
ピアからのダウンロード要求に応じて、ピアの要求クラスをチェックし、前記要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加し、前記要求クラスが高優先ダウンロードであれば、ピア追加要求条件を満足しているかどうかをチェックし、前記ピア追加要求条件を満足している場合、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加するステップと、
前記ピア追加要求条件を満足しない場合、前記ピアの状態を管理するピア管理サーバに対して、前記ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行うステップと、
前記ピア管理サーバに対する問い合わせ結果を確認し、前記ピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブルに含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとして前記ピアツーピア（Ｐ２Ｐ）ネットワークに追加するステップと
を、コンピュータに実行させるための
プログラム。
【請求項２８】
請求項２７に記載のプログラムであって、
前記ピア追加要求条件は、「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」であり、
前記属性クラスピア追加管理条件は、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」である
プログラム。
【請求項２９】
請求項２７又は２８に記載のプログラムであって、
離脱要求のあったピアを削除予約リストの末尾に追加するステップと、
ピア削除管理条件を満足しているかどうかをチェックし、前記ピア削除管理条件を満足する場合、前記削除予約リストにエントリが存在するかどうかをチェックし、前記削除予約リストにエントリが存在する場合、前記削除予約リストの先頭のエントリにあるピアをピアツーピア（Ｐ２Ｐ）ネットワークから削除するステップと
を、更にコンピュータに実行させるための
プログラム。
【請求項３０】
請求項２９に記載のプログラムであって、
前記ピア削除管理条件は、「（高優先ダウンロードピア数＋γ）＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」である
プログラム。
【請求項３１】
請求項２７乃至３０のいずれか一項に記載のプログラムであって、
問い合わせ処理時に、前記ピア管理サーバに対して属性クラスピア追加管理条件とコンテンツＩＤを通知するステップ
を、更にコンピュータに実行させるための
プログラム。
【請求項３２】
コンピュータをピア管理サーバとして機能させるためのプログラムであって、
ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なアイドル状態のピアを示すアイドルピア管理リスト、及び支援用ピアを示す支援用ピアリストを設定するステップと、
前記アイドルピア管理リストを参照し、トラッカーから通知されたコンテンツＩＤのコンテンツを保有するピアを検索し、前記コンテンツを保有するピアが存在する場合、前記コンテンツを保有するピアを前記支援用ピアリストに追加するステップと、
前記支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックし、前記支援用ピアリストが前記支援用ピア数条件を満足する場合、前記支援用ピアリストを確定し、前記支援用ピアリストを前記トラッカーに通知するステップと、
前記支援用ピアリストに追加されたピアを、前記アイドルピア管理リストから削除するステップと
を、コンピュータに実行させるための
プログラム。
【請求項３３】
請求項３２に記載のプログラムであって、
前記支援用ピア数条件を満足する数のアップロード専用ピアを見つけられず、支援用ピアリストが支援用ピア数条件を満足しなかった場合、低優先ダウンロードピアの検索を行うステップ
を、更にコンピュータに実行させるための
プログラム。
【請求項３４】
請求項３３に記載のプログラムであって、
前記支援用ピア数条件を満足するだけの低優先ダウンロードピアが存在しない場合、条件未達として、前記トラッカーに応答を返すステップ
を、更にコンピュータに実行させるための
プログラム。
【請求項３５】
請求項３３又は３４に記載のプログラムであって、
前記支援用ピア数条件を満足する低優先ダウンロードピアが発見できた場合、発見できたアップロード専用ピアと低優先ダウンロードピアを前記支援用ピアリストに追加し、前記支援用ピアリストを確定し、前記支援用ピアリストを前記トラッカーに通知するステップ
を、更にコンピュータに実行させるための
プログラム。
【請求項３６】
請求項３３乃至３５のいずれか一項に記載のプログラムであって、
低優先ダウンロードピアを選択する際の候補が複数存在する際に、知り合いを何人経由すれば到達できるかを示す知り合いホップ数に基づいて、高優先ダウンロードピアとの知り合いホップ数が小さいピアを優先的に低優先ダウンロードピアとして割り当てるステップ
を、更にコンピュータに実行させるための
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システムに関して、特にコンテンツを受信するピアが、コンテンツ配信サーバだけでなく受信ピア間でコンテンツの送受信を行うコンテンツ配信システムに関する。
【背景技術】
【０００２】
昨今インターネット上で様々な動画サービスが提供されているが、サービス形態としては大きく以下の３種類に分類できる。
（１）放送型ストリーミングサービス
（２）オンデマンドストリーム再生サービス
（３）ダウンロード型サービス
【０００３】
（１）放送型ストリーミングサービス
放送型ストリーミングサービスとは、ある番組を決まった時間に閲覧対象ユーザに対して提供するサービスである。一般的に、放送型ストリーミングサービスは、主にＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）のサービスとして提供される。放送型ストリーミングサービスでは、同一番組を同時に多数のユーザに転送するため、マルチキャスト機能をサポートしたネットワーク機器を利用することで、ネットワーク内で効率よく高品質の動画を配信することが可能である。ＩＳＰのようにネットワーク内を完全に制御できる場合、動画マルチキャスト配信に適したネットワークを構築することが可能であるが、インターネット全体で高品質のマルチキャストサービスを提供することは困難である。また、動画配信サービスの提供対象は、ＩＳＰと契約したユーザのうち、基本契約料に加えて追加料金を払った限定的ユーザであることが多い。従って、利用ユーザ数が限られ変動も少ないことから、インターネット全体に無料でサービスを提供する場合に比べて、急激にアクセス数・トラフィック量が変動することは少なく制御が容易である。
【０００４】
（２）オンデマンドストリーム再生サービス
オンデマンドストリーム再生サービスとは、ユーザが閲覧したい動画を選択してその場で閲覧するようなサービスである。オンデマンドストリーム再生では、動画閲覧クライアントで一定量の動画がダウンロードされると再生が開始される。放送型ストリーミングサービスと比べてユーザは自分の見たい動画を自由に選択し、見たい時に自由に閲覧することが可能である。
【０００５】
オンデマンドストリーム再生サービスの代表例として、「ＹｏｕＴｕｂｅ（登録商標）」（非特許文献１）がある。昨今、「ＹｏｕＴｕｂｅ（登録商標）」の急速な普及によりインターネットユーザは、インターネット上で気楽に動画を閲覧することが可能となった。「ＹｏｕＴｕｂｅ（登録商標）」で提供されている画質は、解像度「３２０ｘ２４０」、フレームレート「３０ｆｐｓ」、データレート「３２０ｋｂｐｓ」と比較的低品質の動画が使用されている。しかし、このような低品質の動画を提供するにも毎月１億円以上のネットワーク回線を利用しているといわれており、インターネット上で多数のユーザに動画サービスを提供するために如何に高いコストが必要となるかが分かる。これは、動画を提供する配信サーバにアクセス負荷が集中し配信サーバから各ユーザの合計ダウンロード帯域を満足する大容量のネットワーク回線を利用する必要があるからである。
【０００６】
（３）ダウンロード型サービス
ダウンロード型サービスとは、閲覧したい動画を完全にダウンロードしてから、後から閲覧再生するような方式である。直ぐに再生する必要が無いため、動作再生レートよりも高いダウンロード帯域を保障する必要が無く他の方式に比べて制約条件が緩い。最近では、ダウンロード型サービスを低コストで実現する方式として、ピアツーピア（Ｐ２Ｐ：Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）ネットワークを利用した動画メディア配信サービスが出現している。ここでは、ピア（Ｐｅｅｒ）は、ピアツーピア（Ｐ２Ｐ）ネットワーク上のノード（ｎｏｄｅ）を示す。ピアツーピア（Ｐ２Ｐ）を利用した動画配信サービスでは、各ピアは、サーバから動画コンテンツをダウンロードするだけでなく、ピア同士でもコンテンツの送受信を行うことでサーバの負荷を軽減する。結果、サービス提供業者が動画コンテンツ配信サービス提供するための、機器設置コスト・ネットワークコストを大幅に削減することが可能となる。
【０００７】
以下、従来のコンテンツ配信システムの例として特にファイル配布用のピアツーピア（Ｐ２Ｐ）プロトコルとして広く普及している「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」（非特許文献２）を利用したコンテンツ配信システムに関して説明する。
【０００８】
「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」では、コンテンツ毎にスワンプ（ｓｗａｍｐ）と呼ばれるピアツーピア（Ｐ２Ｐ）ネットワークを構築する。ピアツーピア（Ｐ２Ｐ）ネットワークに属するピアはトラッカー（Ｔｒａｃｋｅｒ）と呼ばれるサーバにより管理される。コンテンツのダウンロードを希望するピアは、トラッカーに対してピアツーピア（Ｐ２Ｐ）ネットワークへの参加を要求する。トラッカーは、ピアのリストを返す。コンテンツは、固定長サイズのピースに分割される。各ピアは、ピース単位でデータの送受信を行う。各ピアは、他のピアと接続し、他のピアがコンテンツのどのピースを有しているかの情報を入手する。各ピアは、接続ピアに対してダウンロードしたいかどうかを「Ｉｎｔｅｒｅｓｔ  ｆｌａｇ」により通知する。次に各ピアは、各接続ピアから受信した「Ｉｎｔｅｒｅｓｔ  ｆｌａｇ」をチェックし、ダウンロードを要求してきたピアの中から、アップロード対象のピアを選択して、「ｃｈｏｋｅ／ｕｎｃｈｏｋｅ  ｆｌａｇ」を送出する。ここでは、「ｃｈｏｋｅ／ｕｎｃｈｏｋｅ  ｆｌａｇ」は、「ｃｈｏｋｅ」がダウンロード許可を示し、「ｕｎｃｈｏｋｅ」がアップロード許可を示す。このアップロード対象のピアを選択する際に、自分に多くのコンテンツをダウンロードしてくれるユーザを選択する動作をすることが重要な特徴である。これは、「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」と呼ばれる。この「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」に従って、定期的にアップロード対象のピアを更新し、お互いにコンテンツの送受信を行うことで、ネットワーク全体の転送スループットを向上させている。但し、実際には、例外的にコンテンツの全てを有してアップロードのみを行うアップロード専用ピアも存在する。このようなアップロード専用ピアは、シード（Ｓｅｅｄ）と呼ばれる。このようなアップロード専用ピアは、アップロード速度の高いピアを優先して選択する。
【０００９】
次に、接続ピアよりアップロード許可を得たピアは、自身のダウンロードしたいピースの中で、最も保有するピアの数の少ないピースを選択してダウンロードする。この仕組みを「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」と呼ぶ。「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」を利用することで、全てのピースが均等にネットワーク上に配布されるようになるため、特定のピースが足りなくなって全体のダウンロード効率が劣化するという状況を防止できる。
【００１０】
この「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」と、「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」を利用した「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」は、高い総転送スループットを実現するピーツーピーコンテンツ配布方式として、事実上の標準プロトコルとして利用されている。
【００１１】
なお、関連する技術として、特開２００４−０７２６０３号公報（特許文献１）に「障害回復システム」が開示されている。
この関連技術では、第１のピアが何らかの理由によりシステムより離脱する。第２のピアは、第１のピアの離脱を検知し障害回復処理が開始される。第２のピアは、待機ピアが登録されているか検索し、待機ピアのアドレス情報を得る。第２のピアは、待機ピアに対して離脱ピアの発生を通知し、待機ピアは、直ちにテイクオーバを行う。テイクオーバとは、隣接ピアとの間でピア情報の交換を行い、それぞれの隣接ピア情報格納表の内容を更新することである。
【００１２】
また、特開２００４−２４６７９０号公報（特許文献２）に「コンテンツ配信方法」が開示されている。
この関連技術では、ピア・トゥ・ピア型コンテンツ配信を実施する。構成要素は、コンテンツをパケットに分割して配信するコンテンツ配信サーバ装置と、コンテンツ配信サーバ装置から送出されたコンテンツを受信するクライアント装置群と、コンテンツ配信サーバ装置およびクライアント装置との接続関係を制御するトポロジ制御装置とで構成される。クライアント装置群に含まれる各々のクライアント装置は他のクライアント装置から要求があれば他のクライアント装置に対しコンテンツを配信する。
【００１３】
また、特開２００４−２６０２７９号公報（特許文献３）に「ピアグループの構成方法」が開示されている。
この関連技術では、新規参加ピアから、その参加対象のピアグループの任意のメンバに対して、ピアグループ参加依頼がなされる。ピアグループ参加依頼を受けたピアは、新規参加ピアから渡されたピアグループ属性情報と、自らの保有するピアグループ属性情報とが一致するか判定し、一致する場合には参加ＯＫのピア参加依頼応答を返す。
【００１４】
また、特開２００５−２３５１７７号公報（特許文献４）に「同時に存在するクライアントによるサービスへのアクセスを制御するためのアーキテクチャ」が開示されている。
この関連技術では、システムは、申込者のアカウントに対する１つ又は複数のルールの強制を容易にするルールコンポーネントを含む。ルールは、例えば、同時に接続されるクライアントの数に関する制限等を含む。
【００１５】
また、特開２００６−１４８６４８号公報（特許文献５）に「ユーザ端末接続制御方法および装置」が開示されている。
この関連技術では、認証サーバが備えるユーザ管理テーブルは、優先ＭＡＣアドレス、最大接続数等を含む。優先ＭＡＣアドレスは、インターネットに優先的に接続すべきユーザ端末のＭＡＣアドレスを示す。
【００１６】
【特許文献１】特開２００４−０７２６０３号公報
【特許文献２】特開２００４−２４６７９０号公報
【特許文献３】特開２００４−２６０２７９号公報
【特許文献４】特開２００５−２３５１７７号公報
【特許文献５】特開２００６−１４８６４８号公報
【非特許文献１】＜ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／＞
【非特許文献２】＜ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇ／ｐｒｏｔｏｃｏｌ．ｈｔｍｌ＞  ”Ｉｎｃｅｎｔｉｖｅｓ  Ｂｕｉｌｄ  Ｒｏｂｕｓｔｎｅｓｓ  ｉｎ  ＢｉｔＴｏｒｒｅｎｔ”，  Ｂ．  Ｃｏｈｅｎ，  Ｉｎ  Ｐｒｏｃ．  ｏｆ  １ｓｔ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｅｃｏｎｏｍｉｃｓ  ｏｆ  Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ  Ｓｙｓｔｅｍｓ  （Ｊｕｎｅ  ２００３）
【発明の開示】
【発明が解決しようとする課題】
【００１７】
コンテンツ配信システムを提供するに当たり、ネットワーク・サーバ機器、及び、ネットワーク回線にコストをかけずにサービスを提供するためには、コンテンツをダウンロードするピア間でコンテンツの送受信を行う「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」のようなピアツーピア（Ｐ２Ｐ）ネットワークを利用したコンテンツ配信方法の利用が有力である。
【００１８】
しかし、例えば、「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」において、転送効率を向上させるために導入されている「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」や「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」は、動画コンテンツをストリーム再生することには向いていない。
【００１９】
まず、「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」では、コンテンツを十分にアップロード可能なピアでなければ、十分なダウンロードレートでコンテンツをダウンロードできない。また、「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」では、コンテンツを順番にダウンロードできないため、全てのピースがそろわなければコンテンツを再生できない。
【００２０】
上記の特性から、ピアツーピア（Ｐ２Ｐ）を利用したコンテンツ配信システムでは、ダウンロード型サービスで提供されることが一般的であり、オンデマンドストリーム再生サービスを実現することは困難である。
【００２１】
また、基本サービスとしてダウンロード型サービスを提供する場合においても、直ぐに動画を閲覧したいユーザと、直ぐに閲覧する必要の無いユーザが存在する。直ぐに動画を閲覧したいユーザに対しては、可能な限り早く動画が閲覧できる状態にする必要がある。
【００２２】
本発明の目的は、コンテンツ配信システムにおいて、ある動画コンテンツに関して、（１）コンテンツを直ぐに閲覧したいユーザ、（２）将来閲覧する可能性の高いユーザ、（３）閲覧する可能性の低いユーザ等、様々なユーザが混在する場合に、コンテンツを直ぐに閲覧したいユーザが可能な限り早く動画を閲覧することが可能なコンテンツ配信システム、コンテンツ配信方法、及びプログラムを提供することである。
【課題を解決するための手段】
【００２３】
本発明のコンテンツ配信システムは、属性クラス毎に分類された複数のピアと、複数のピアの各々の状態を管理するピア管理サーバと、属性クラス毎のピア数が属性クラスピア追加管理条件を満足するように複数のピアの管理を行い、複数のピアのうち所定のピアから所定の属性クラスへの追加要求が行われた際に、ピア追加要求条件を満足できない場合、ピア管理サーバに問い合わせを行い、ピア管理サーバから、ピア追加要求条件を満足するように選択された他の属性クラスのピアに基づいて作成された支援用ピアリストを取得し、追加要求を行ったピアと支援用ピアリスト内のピアとをピアツーピア（Ｐ２Ｐ）ネットワークに追加するトラッカーとを含む。ここでは、ピア追加要求条件は、「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」であり、属性クラスピア追加管理条件は、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」である。但し、実際には、これらの例に限定されない。
【００２４】
本発明に係るトラッカーは、要求クラスチェック手段と、問い合わせ手段と、問い合わせ結果確認手段とを具備する。要求クラスチェック手段は、ピアからのダウンロード要求に応じて、ピアの要求クラスをチェックし、要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加し、要求クラスが高優先ダウンロードであれば、ピア追加要求条件を満足しているかどうかをチェックし、ピア追加要求条件を満足している場合、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加する。問い合わせ手段は、ピア追加要求条件を満足しない場合、ピアの状態を管理するピア管理サーバに対して、ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行う。問い合わせ結果確認手段は、ピア管理サーバに対する問い合わせ結果を確認し、ピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブルに含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとしてピアツーピア（Ｐ２Ｐ）ネットワークに追加する。  
【００２５】
本発明に係るピア管理サーバは、テーブル管理手段と、ピア検索手段と、条件チェック手段とを具備する。テーブル管理手段は、ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なアイドル状態のピアを示すアイドルピア管理リスト、及び支援用ピアを示す支援用ピアリストを管理する。ピア検索手段は、アイドルピア管理リストを参照し、トラッカーから通知されたコンテンツＩＤのコンテンツを保有するピアを検索し、コンテンツを保有するピアが存在する場合、コンテンツを保有するピアを支援用ピアリストに追加する。条件チェック手段は、支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックし、支援用ピアリストが支援用ピア数条件を満足する場合、支援用ピアリストを確定し、支援用ピアリストをトラッカーに通知し、支援用ピアリストに追加されたピアを、アイドルピア管理リストから削除する。
【００２６】
本発明のコンテンツ配信方法は、属性クラス毎に分類された複数のピアの各々の状態を管理するステップと、属性クラス毎のピア数が属性クラスピア追加管理条件を満足するように複数のピアの管理を行い、複数のピアのうち所定のピアから所定の属性クラスへの追加要求が行われた際に、ピア追加要求条件を満足できない場合、ピア追加要求条件を満足するように他の属性クラスのピアを選択して支援用ピアリストを作成するステップと、追加要求を行ったピアと支援用ピアリスト内のピアとをピアツーピア（Ｐ２Ｐ）ネットワークに追加するステップとを含む。  
【００２７】
本発明のプログラムは、コンピュータをトラッカーとして機能させるためのプログラムであって、ピアからのダウンロード要求に応じて、ピアの要求クラスをチェックし、要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加し、要求クラスが高優先ダウンロードであれば、ピア追加要求条件を満足しているかどうかをチェックし、ピア追加要求条件を満足している場合、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加するステップと、ピア追加要求条件を満足しない場合、ピアの状態を管理するピア管理サーバに対して、ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行うステップと、ピア管理サーバに対する問い合わせ結果を確認し、ピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブルに含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとしてピアツーピア（Ｐ２Ｐ）ネットワークに追加するステップとを、コンピュータに実行させるためのプログラムである。
【００２８】
本発明の他のプログラムは、コンピュータをピア管理サーバとして機能させるためのプログラムであって、ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なアイドル状態のピアを示すアイドルピア管理リスト、及び支援用ピアを示す支援用ピアリストを設定するステップと、アイドルピア管理リストを参照し、トラッカーから通知されたコンテンツＩＤのコンテンツを保有するピアを検索し、コンテンツを保有するピアが存在する場合、コンテンツを保有するピアを支援用ピアリストに追加するステップと、支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックし、支援用ピアリストが支援用ピア数条件を満足する場合、支援用ピアリストを確定し、支援用ピアリストをトラッカーに通知するステップと、支援用ピアリストに追加されたピアを、アイドルピア管理リストから削除するステップとを、コンピュータに実行させるためのプログラムである。
【発明の効果】
【００２９】
ピアツーピア（Ｐ２Ｐ）ネットワークを利用したコンテンツ配信システムにおいて、コンテンツを直ぐに閲覧したいユーザが可能な限り早く動画を閲覧することを可能とする。
【発明を実施するための最良の形態】
【００３０】
以下に、本発明の第１実施形態について添付図面を参照して説明する。
図１に、本実施形態におけるコンテンツ配信システム１００の構成例を示す。
本発明のコンテンツ配信システムは、ピア１と、配信サーバ２と、ピア管理サーバ３と、トラッカー４を備える。
【００３１】
ピア１（１−ｉ、ｉ＝１〜ｎ：ｎはピア数）は、コンテンツ配信システムに接続するピアであり、コンテンツ群をダウンロードする。配信サーバ２は、コンテンツ配信システム上に配信するコンテンツ群を保有する。なお、配信サーバ２は、アップロード専用ピアであるため、ピア１と同じくコンテンツ配信システムに接続するピアとすることができる。ピア管理サーバ３は、コンテンツ配信システムに接続するピアの管理を行う。トラッカー４は、スワンプ（ｓｗａｍｐ）と呼ばれるピアツーピア（Ｐ２Ｐ）ネットワークを構築する。スワンプ（ｓｗａｍｐ）は、あるコンテンツをダウンロード又はアップロードするピアのグループである。このとき、トラッカー４は、コンテンツ毎にピアのリスト（ピアリスト）を管理する。ピアリストは、トラッカー４自身が管理するピアツーピア（Ｐ２Ｐ）ネットワークに含まれるピアのリストである。ここで、ピア管理サーバ３が、トラッカー４を含む場合も考えられる。この場合、ピア管理サーバ３とトラッカー４は、同一のサーバ上に実装された機能となる。なお、ピア管理サーバ３とトラッカー４の機能に関しては、専用のサーバ上で実現しても良いが、ピアツーピア（Ｐ２Ｐ）ネットワーク上で分散ハッシュテーブル（ＤＨＴ：Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ）を利用して機能を分散的に実現しても良い。実際、「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」では、トラッカー４をサーバに実装する以外に、ＤＨＴを利用した実装も存在する。
【００３２】
ピア管理サーバ３は、ピア管理テーブルを作成し、ピア１の状態を管理する。ピア管理テーブルは、テーブルエントリとして、ピアを一意に識別するためのピアＩＤと、ピア１の保有するコンテンツを一意に識別するための保有コンテンツＩＤリストを有する。ピア管理テーブルは、アイドル状態、すなわち、ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なピア１のリストであることが好適である。但し、実際には、ピア管理テーブルは、アイドル状態以外のピアを含むリストとすることも可能である。この場合、ピア管理テーブルは、テーブルエントリとして、更に、ピアの状態を示すステータスを有する。ピア管理サーバ３は、ピア管理テーブルにピアの状態を示す項目を設けることで、アイドル状態のピアを判別可能になり、ピア管理テーブルをアイドルピア管理リストとして使用することができるようになる。また、ピア管理サーバ３は、ピア管理テーブルとは別に、アイドル状態のピアを示すアイドルピア管理リストを作成するようにしても良い。
【００３３】
図２に、ピア管理テーブルの例を示す。
ピア管理テーブルは、「ピアＩＤ」と、「保有コンテンツＩＤ  Ｌｉｓｔ」を有する。「ピアＩＤ」は、ピア管理サーバ３が管理しているピア１を一意に識別するための識別情報である。「保有コンテンツＩＤ  Ｌｉｓｔ」は、ピア１の保有するコンテンツを一意に識別するための保有コンテンツＩＤを示したものである。ここでは、ピア管理テーブルは、アイドル状態のピアのみ表示している。図示しないが、ピア管理テーブルは、更に、「ステータス」を有していても良い。「ステータス」は、ピア１の状態を示すステータス情報である。
【００３４】
トラッカー４は、配信コンテンツ毎に存在し、コンテンツのピースを送受信するピア１の管理を行う。配信コンテンツの各々には、コンテンツＩＤが割り当てられている。従って、トラッカー４は、コンテンツＩＤで識別可能である。
【００３５】
なお、複数のコンテンツを一つにまとめることで、複数のコンテンツを一つのグループコンテンツとしてとらえることが可能である。トラッカー４の管理対象、すなわち、コンテンツＩＤの付与される対象は、そのようなグループコンテンツ単位とすることも想定される。従って、トラッカー４の管理対象は、厳密に一つのコンテンツファイルに限定されるものでは無い。
【００３６】
ピア１は、コンテンツのダウンロードが必要な状態であることを識別すると、該当コンテンツのピア一覧を管理するトラッカー４に対してコンテンツのダウンロードを要求する。
【００３７】
ユーザは専用ピアを利用して動画コンテンツの閲覧を行うが、動画コンテンツの閲覧方法としては閲覧するコンテンツをその場で選んで直ぐに再生する方法と、何らかの方法で事前にダウンロードされた動画を後からゆっくり閲覧する場合の２通りが考えられる。例えば、ユーザが予めあるジャンルの番組を閲覧登録しておいたとすると、該当ジャンルの番組が発行されると、自動的にユーザのピアを動画がダウンロードされる。ユーザは、後からダウンロードされた動画をチェックし閲覧する。
【００３８】
図３のフローチャートを参照して、ピア１がトラッカー４に対してコンテンツのダウンロードを要求した場合のピア追加処理の動作について説明する。
（１）ステップＳ１０１
ピア１は、トラッカー４に対してコンテンツのダウンロード要求を行う。すなわち、ピア１は、トラッカー４に対して、ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへの追加要求を行う。
（２）ステップＳ１０２
トラッカー４は、ダウンロード要求に応じて、ピア１の要求クラスをチェックする。ここでは、トラッカー４は、ピア１の要求クラスが高優先ダウンロードであるかどうかの確認を行う。
（３）ステップＳ１０３
トラッカー４は、要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへの追加要求を許可する。ここでは、トラッカー４は、要求クラスが高優先ダウンロードでなければ、ピア１を低優先ダウンロードピアとしてピアリストに追加する。ピアリストは、トラッカー４自身が管理するピアツーピア（Ｐ２Ｐ）ネットワークに含まれるピアのリストである。このとき、トラッカー４は、低優先ダウンロードピアのみを登録したピアリストを作成し、このピアリストの末尾にピア１を追加するようにしても良い。
（４）ステップＳ１０４
トラッカー４は、要求クラスが高優先ダウンロードであれば、次に、ピア追加要求条件を満足しているかどうかをチェックする。
ピア追加要求条件は、例えば、以下の式である。
「高優先ダウンロードピア数＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」
ここでは、α＝０．５、β＝２とする。α、βの値は、任意に設定可能である。このとき、トラッカー４は、α、βの値を算出又は選択するようにしても良い。例えば、トラッカー４は、自身の管理するピアツーピア（Ｐ２Ｐ）ネットワークのトラフィック（ｔｒａｆｆｉｃ）を監視し、ダウンロード要求があった時のトラフィックに応じて、α、βの値を算出又は選択するようにしても良い。
（５）ステップＳ１０５
トラッカー４は、ピア追加要求条件を満足している場合、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへの追加要求を許可する。ここでは、トラッカー４は、ピア１を高優先ダウンロードピアとしてピアリストに追加する。このとき、トラッカー４は、高優先ダウンロードピアのみを登録したピアリストを作成し、このピアリストの末尾にピア１を追加するようにしても良い。
（６）ステップＳ１０６
トラッカー４は、ピア追加要求条件を満足しない場合、ピア管理サーバ３に対して、ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行う。ここでは、トラッカー４は、ピア管理サーバ３のピア管理テーブル内に、ピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在するかどうかの問い合わせを行う。
（７）ステップＳ１０７
トラッカー４は、ピア管理サーバ３から問い合わせ結果を受信すると、問い合わせ結果のチェックを行う。ここでは、トラッカー４は、問い合わせ結果を参照して、ピア管理テーブル内にピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在するかどうかの確認を行う。
（８）ステップＳ１０８
トラッカー４は、ピア管理テーブル内にピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブルに含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとしてピアリストに追加する。このとき、トラッカー４は、ピア管理サーバ３に対して、支援用ピアを、ピア管理サーバ３側で管理されている支援用ピアリストに追加するように要求するようにしても良い。
（９）ステップＳ１０９
トラッカー４は、要求元のピア１を高優先ダウンロードピアとしてピアリストに追加する。
（１０）ステップＳ１１０
トラッカー４は、ピア管理サーバ３への問い合わせ結果において、ピア管理テーブル内にピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在しない場合、ピア１のピア追加要求を拒絶する。
（１１）ステップＳ１１１
トラッカー４は、ピア１のピア追加要求を拒絶した場合、高優先ダウンロードでは無く、低優先ダウンロードを行うかどうかをチェックする。このとき、トラッカー４は、低優先ダウンロードを行うかどうかについて、ピア１に問い合わせるようにしても良い。また、トラッカー４は、ピア１のピア追加要求を拒絶した場合、自動的に低優先ダウンロードを行うようにしても良い。
（１２）ステップＳ１１２
トラッカー４は、低優先ダウンロードを行う場合、ピア１を低優先ダウンロードピアとしてピアリストに追加する。
（１３）ステップＳ１１３
トラッカー４は、低優先ダウンロードを行わない場合、ピア１を追加せずに終了する。
【００３９】
次に、図４のフローチャートを参照して、トラッカー４がピア管理サーバ３に対して支援用ピアの追加要求問い合わせ処理を行う際の動作について説明する。
（１）ステップＳ２０１
トラッカー４は、ピア管理サーバ３に対して支援用ピアの追加要求問い合わせ処理を行う。このとき、トラッカー４は、問い合わせ処理時に、ピア管理サーバ３に対して属性クラスピア追加管理条件とコンテンツＩＤを通知する。
属性クラスピア追加管理条件は、例えば以下のようになる。
「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞＝１」
ここでは、α＝０．５、β＝２とする。α、βの値は、任意に設定可能である。このとき、トラッカー４は、α、βの値を算出するようにしても良い。例えば、トラッカー４は、自身の管理するピアツーピア（Ｐ２Ｐ）ネットワークのトラフィック（ｔｒａｆｆｉｃ）を監視し、ダウンロード要求があった時のトラフィックに応じて、α、βの値を算出又は選択するようにしても良い。
（２）ステップＳ２０２
ピア管理サーバ３は、アップロード専用ピア（シード）の検索を行う。具体的には、ピア管理サーバ３は、トラッカー４から要求のあったコンテンツＩＤのコンテンツを保有するピアであって、アイドルピア管理リストに存在するピアを見つける。ここでは、アイドルピア管理リストは、ピア管理テーブルとする。ピア管理サーバ３は、条件を満足するピア１が複数存在する場合、例えば、保有コンテンツの少ないピアを優先して選択する。保有コンテンツの少ないピアを選択する理由は、保有コンテンツの多いピア１の方が他のコンテンツでシードとして利用可能性が高いからである。
（３）ステップＳ２０３
ピア管理サーバ３は、アイドルピア管理リストに存在するピアを発見した場合、該当ピアを支援用ピアとして支援用ピアリストに追加し、該当ピア追加後の支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックする。支援用ピア数条件は、属性クラスピア追加管理条件及びピア追加要求条件を満足するために設定される。例えば、上記の属性クラスピア追加管理条件において、「高優先ダウンロードピア数＝５」、「低優先ダウンロードピア数＝５」、「アップロード専用ピア数＝１」である場合、「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＝４．５」となり、「高優先ダウンロードピア数＝５」よりも小さくなり、ピア追加要求条件を満たしていない。そのため、ピア追加要求条件を満たすための支援用ピアを追加する必要がある。
上記の場合、支援用ピア数条件は、例えば以下のようになる。
「（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）＞０．５」
ここでは、α＝０．５、β＝２とする。
（４）ステップＳ２０４
ピア管理サーバ３は、支援用ピアリストが支援用ピア数条件を満足する場合、支援用ピアリストを確定し、トラッカー４に応答を返す。
（５）ステップＳ２０５
ピア管理サーバ３は、支援用ピア数条件を満足する数のアップロード専用ピアを見つけられず、支援用ピアリストが支援用ピア数条件を満足しなかった場合、低優先ダウンロードピアの検索を行う。
（６）ステップＳ２０６
ピア管理サーバ３は、支援用ピア数条件を満足するだけの低優先ダウンロードピアが存在するかチェックする。ここでは、ピア管理サーバ３は、低優先ダウンロードピアを発見した場合、該当低優先ダウンロードピアを支援用ピアとして支援用ピアリストに追加し、該当低優先ダウンロードピア追加後の支援用ピアリストが支援用ピア数条件を満足するかどうかをチェックする。
（７）ステップＳ２０７
ピア管理サーバ３は、支援用ピア数条件を満足するだけの低優先ダウンロードピアが存在しない場合、条件未達として、トラッカー４に応答を返す。
（８）ステップＳ２０８
ピア管理サーバ３は、支援用ピア数条件を満足する低優先ダウンロードピアが発見できた場合、これまでの検索で発見できた全てのアップロード専用ピアと低優先ダウンロードピアを支援用ピアリストに追加した状態で、支援用ピアリストを確定し、トラッカー４に応答を返す。このとき、ピア管理サーバ３は、支援用ピアとしてスワンプ（ｓｗａｍｐ）に追加されたピアを、アイドルピア管理リストから削除する。ここでは、スワンプは、ある特定コンテンツに対して構築されるピアツーピア（Ｐ２Ｐ）ネットワークを示す。
【００４０】
次に、本発明のコンテンツ配信システムにおいて、あるコンテンツに関してピアツーピア（Ｐ２Ｐ）を利用してどのようにコンテンツ配信の制御を行うかに関して説明する。
【００４１】
トラッカーは、あるコンテンツに所属するピアのリスト（ピアリスト）を管理する。各ピアは、転送クラスとして高優先ダウンロードピア、低優先ダウンロードピア、アップロード専用ピアのいずれかに分類される。ピア間でのデータ転送は、高優先ダウンロードピアと低優先ダウンロードピアとの間で優先制御を実現する以外は、基本的に「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」プロトコルの動作と同様の転送処理を行うものとする。なお、本実施形態では、「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」プロトコルに優先制御機能を追加した場合の実施例を示すが、ピアツーピア（Ｐ２Ｐ）の転送プロトコルとしては「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」に限定されるものでは無い。
【００４２】
各ピアは、スワンプ参加時に、トラッカーよりピアリストを取得する。コンテンツは固定長のピースに分割され、ピース単位で転送される。ピアは、ピアリスト内の各ピアと接続し、各ピアの有するピースの情報を取得する。
【００４３】
次に、ピアは、各ピアの保有するピース情報から、自分の保有しないピースを持っているかどうかの情報を「Ｉｎｔｅｒｅｓｔ  ｆｌａｇ」として通知する。ピア間で「Ｉｎｔｅｒｅｓｔ  ｆｌａｇ」を交換することで、ピアは、自分に接続している各ピアが自分からダウンロードしたいピースを有しているかどうかを判定できる。
【００４４】
次に、ピアは、予め設定された数の接続ピアに対してダウンロードを許可する。「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」では、ダウンロードの許可を「ｕｎｃｈｏｋｅ」と呼ぶ。ピアは、ダウンロードを許可するピアの選択に際し、高優先ダウンロードピアよりも低優先ダウンロードピアを優先して選択する点が通常の「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」との差分となる。選択の方法としては、常に高優先ダウンロードピアを優先する方法や、一定の割合で高優先ダウンロードピアと低優先ダウンロードピアを選択する方法等が考えられる。
【００４５】
ピアは、接続ピアからダウンロード許可が出た場合、どのピースを選択するかを決定して実際にダウンロード許可する。「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」では、ピースの選択では、「Ｒａｒｅｓｔ  Ｆｉｒｓｔ」という最も保有するピアの少ないピースをダウンロードすることで、全てのピースがネットワーク上で均等に分散されるようにしているが、高優先ダウンロードピアは、別のピース選択ルールに従うことも考えられる。例えば、高優先ダウンロードピアが、動画コンテンツのダウンロードを行う場合、ピースを先頭から順番にダウンロードすることで、コンテンツが全てそろわなくてもストリーム再生を実現することが可能となる。
【００４６】
「ＢｉｔＴｏｒｒｅｎｔ（登録商標）」では、「Ｒａｒｅｓｔ  Ｆｉｒｓｔ」アルゴリズムは、ピースの均等分散を促進しスワンプ全体の転送効率を向上させるために重要な原則であり、高優先ダウンロードピアがこの原則と異なる振る舞いをすることは、一見、スワンプ全体の転送効率を低下させるように思われる。しかし、本発明のコンテンツ配信システムでは、スワンプ内の高優先ダウンロードピア数、低優先ダウンロードピア数、アップロード専用ピア数を定められた条件に従うように制御しているため、高優先ダウンロードピアが、ピースの均等分散を阻害する振る舞いを行っても、低優先ダウンロードピアが、ピースが均等分散されるように、より少ないピースを選択ダウンロードする。従って、高優先ダウンロードピアに比べて十分な数の低優先ダウンロードピアが存在すれば、ネットワーク全体としてはピースが均等に分散される状態を維持することが可能である。
【００４７】
次に、図５のフローチャートを参照して、ピア１がコンテンツのダウンロードを完了し、トラッカー４に対してスワンプからの削除を要求する処理の動作について説明する。
（１）ステップＳ３０１
ピア１は、コンテンツのダウンロードが完了すると、トラッカー４に対して該当スワンプから離脱しても良いかどうかを問い合わせる。ここでは、ピア１は、コンテンツのダウンロード完了後、トラッカー４に対して離脱要求を行う。
（２）ステップＳ３０２
トラッカー４は、離脱要求のあったピア１を削除予約リストの末尾に追加する。ここでは、トラッカー４は、ピア１からの離脱要求に応じて、ピア１を削除予約リストの末尾に追加する。
（３）ステップＳ３０３
トラッカー４は、ピア削除管理条件を満足しているかどうかをチェックする。
ピア削除管理条件は、例えば以下のように定義される。
「（高優先ダウンロードピア数＋γ）＜（低優先ダウンロードピア数×α）＋（アップロード専用ピア数×β）」
ここでは、α＝０．５、β＝２、γ＝３とする。α、β、γの値は、任意に設定可能である。このとき、トラッカー４は、α、β、γの値を算出するようにしても良い。例えば、トラッカー４は、自身の管理するピアツーピア（Ｐ２Ｐ）ネットワークのトラフィック（ｔｒａｆｆｉｃ）を監視し、ダウンロード要求があった時のトラフィックに応じて、α、β、γの値を算出又は選択するようにしても良い。なお、上記の例で、γ＝０とすれば、ピア追加要求条件とピア削除管理条件は同一となる。ピア追加要求条件とピア削除管理条件は同一であっても良いが、ピア削除管理条件を厳しく設定することで、一定数の高優先ダウンロードピアを無条件で追加することが可能となる。
（４）ステップＳ３０４
トラッカー４は、ピア削除管理条件を満足してない場合、処理を終了する。
（５）ステップＳ３０５
トラッカー４は、ピア削除管理条件を満足する場合、削除予約リストにエントリが存在するかどうかをチェックする。なお、エントリは、削除予約リストに追加されたピア、すなわち、離脱要求のあったピアを示す。
（６）ステップＳ３０６
トラッカー４は、削除予約リストにエントリが存在しない場合、処理を終了する。
（７）ステップＳ３０７
トラッカー４は、削除予約リストにエントリが存在する場合、先頭のエントリを削除対象として、トラッカー４の管理対象から削除する。
（８）ステップＳ３０８
トラッカー４は、削除対象となったエントリを、ピア管理サーバ３のピア管理テーブルに、ピアの支援が可能なものとして登録する。
【００４８】
削除予約リストからのピア削除処理は、ピア削除条件を満足しなくなるか、削除予約リストからエントリが存在しなくなるまで繰り返し実行される。
【００４９】
以下に、本発明の第２実施形態について説明する。
【００５０】
本実施形態では、ピア管理サーバ３は、各ピアを利用するユーザ同士が知り合いであるかどうかを判別するためのピア関係性テーブルを保有する。ピア１は、他のピア１が自分の知り合いであるかどうかを通知する。
【００５１】
ここでは、ピア管理サーバ３は、ピア関係性テーブルを用いて、各ピアの関係性に関して管理する。各ピアの関係性とは、利用ユーザ同士が知り合い登録をしている等の情報である。ここでは、各ピアの関係性は、知り合いを何人経由すれば到達できるかを示す知り合いホップ数で表されるものとする。なお、ピア管理サーバ３は、ピアとピアとの関係性に基づいて、知り合いホップ数を自動的に算出するようにしても良い。但し、実際には、これらの例に限定されない。
【００５２】
ピア管理サーバ３は、低優先ダウンロードピアを選択する際の候補が複数存在する際に、高優先ダウンロードを要求したピアと知り合い登録されているピアを優先的に割り当てる。低優先ダウンロードの候補の中に直接の知り合いが存在しない場合、高優先ダウンロードピアと「知り合いの知り合い」関係にあるピアを選択する。
【００５３】
高優先ダウンロード要求したピア１は、直ぐにコンテンツを閲覧して、同様の嗜好性を持つ知り合いに対してコンテンツを紹介する可能性が高いので、知り合い同士のピアを低優先ダウンロードピアとして割り当てた方が、将来、コンテンツを閲覧する可能性が高いと考えられる。
【００５４】
図６を参照して、本発明のコンテンツ配信システムにおけるピア１と、ピア管理サーバ３と、トラッカー４の構成例について説明する。但し、これらは一例に過ぎず、実際にはこれらの例に限定されない。
【００５５】
ピア１（１−ｉ、ｉ＝１〜ｎ）は、ピア追加要求手段１１と、ピース管理手段１２と、関係性通知手段１３を備える。
【００５６】
ピア追加要求手段１１（１１−ｉ、ｉ＝１〜ｎ）は、トラッカー４に対してコンテンツのダウンロード要求を行うことにより、ダウンロードピアとしてピアリストへの追加要求を行う。また、ピア追加要求手段１１は、コンテンツのダウンロード完了後、トラッカー４に対して離脱要求を行うことにより、削除予約リストへの追加要求を行う。
【００５７】
ピース管理手段１２（１２−ｉ、ｉ＝１〜ｎ）は、コンテンツのピースを管理し、ピア間でピースを送受信する。なお、ピースは、コンテンツを固定長サイズに分割したものである。ここでは、ピース管理手段１２は、コンテンツを構成する全てのピースを取得し、取得されたピースからコンテンツを再構成した時点で、コンテンツのダウンロード完了と判断する。
【００５８】
関係性通知手段１３（１３−ｉ、ｉ＝１〜ｎ）は、各ピアの関係性についてピア管理サーバ３に通知する。なお、関係性通知手段１３は、ピア間で相互に関係性を更新するようにしても良い。
【００５９】
なお、配信サーバ２の構成例は、ピア１と同じでも良い。配信サーバ２の場合、ピア追加要求手段１１は、トラッカー４に対してコンテンツのダウンロード要求を行わず、アップロード専用ピアとしてピアリストへの追加要求を行う。
【００６０】
ピア管理サーバ３は、テーブル管理手段３１と、ピア検索手段３２と、条件チェック手段３３と、関係性管理手段３４を備える。
【００６１】
テーブル管理手段３１は、ピア管理テーブル３１１と、ピア関係性テーブル３１２と、アイドルピア管理リスト３１３と、支援用ピアリスト３１４を管理する。ピア管理テーブル３１１は、テーブルエントリとして、ピアを一意に識別するためのピアＩＤと、ピア１の保有するコンテンツを一意に識別するための保有コンテンツＩＤリストを有する。ピア関係性テーブル３１２は、各ピアを利用するユーザ同士が知り合いであるかどうかを示す。ここでは、ピア関係性テーブル３１２は、知り合いを何人経由すれば到達できるかを示す知り合いホップ数を有する。アイドルピア管理リスト３１３は、アイドル状態、すなわち、ピアツーピア（Ｐ２Ｐ）ネットワークに追加可能なピア１のリストである。なお、アイドルピア管理リスト３１３は、ピア管理テーブル３１１と同一でも良い。支援用ピアリスト３１４は、支援用ピアを示す。支援用ピアは、属性クラスピア追加管理条件及びピア追加要求条件を満足するように選択された他の属性クラスのピアである。
【００６２】
ピア検索手段３２は、アップロード専用ピア（シード）の検索を行う。例えば、ピア検索手段３２は、アイドルピア管理リスト３１３に存在するピアから、トラッカー４から通知されたコンテンツＩＤのコンテンツを保有するピアを見つける。このとき、ピア検索手段３２は、アイドルピア管理リスト内に該当ピアを発見した場合、該当ピアを支援用ピアリスト３１４に追加する。また、ピア検索手段３２は、支援用ピアリスト３１４が支援用ピア数条件を満足しなかった場合、低優先ダウンロードピアの検索を行う。
【００６３】
条件チェック手段３３は、支援用ピアリスト３１４が支援用ピア数条件を満足するかどうかをチェックする。また、条件チェック手段３３は、支援用ピアリスト３１４が支援用ピア数条件を満足する場合、支援用ピアリスト３１４を確定し、確定された支援用ピアリスト３１４を通知するため、トラッカー４に応答を返す。また、条件チェック手段３３は、支援用ピア数条件を満足するだけの低優先ダウンロードピアが存在しない場合、条件未達として、トラッカー４に応答を返す。更に、条件チェック手段３３は、支援用ピア数条件を満足する低優先ダウンロードピアが発見できた場合、発見できたアップロード専用ピアと低優先ダウンロードピアを支援用ピアリスト３１４に追加し、支援用ピアリスト３１４を確定し、確定された支援用ピアリスト３１４を通知するため、トラッカー４に応答を返す。このとき、条件チェック手段３３は、支援用ピアとしてスワンプ（ｓｗａｍｐ）に追加されたピアを、アイドルピア管理リスト３１３から削除する。すなわち、条件チェック手段３３は、支援用ピアリスト３１４に追加されたピアを、アイドルピア管理リスト３１３から削除する。
【００６４】
関係性管理手段３４は、ピア関係性テーブル３１２を用いて、各ピアの関係性に関して管理する。関係性管理手段３４は、低優先ダウンロードピアを選択する際の候補が複数存在する際に、高優先ダウンロードを要求したピアと知り合い登録されているピアを優先的に割り当てる。関係性管理手段３４は、低優先ダウンロードの候補の中に直接の知り合いが存在しない場合、高優先ダウンロードピアと「知り合いの知り合い」関係にあるピアを選択する。また、関係性管理手段３４は、関係性通知手段１３からの通知に基づいて、ピア関係性テーブル３１２を更新する。
【００６５】
トラッカー４は、要求クラスチェック手段４１と、リスト管理手段４２と、条件チェック手段４３と、問い合わせ手段４４と、問い合わせ結果確認手段４５を備える。
【００６６】
要求クラスチェック手段４１は、ピア追加要求手段１１からのダウンロード要求に応じて、ピア１の要求クラスをチェックする。要求クラスチェック手段４１は、要求クラスが低優先ダウンロードであれば、低優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加する。要求クラスチェック手段４１は、要求クラスが高優先ダウンロードであれば、ピア追加要求条件を満足しているかどうかをチェックし、ピア追加要求条件を満足している場合、要求クラスチェック手段４１は、高優先ダウンロードピアとしてピアツーピア（Ｐ２Ｐ）ネットワークへ追加する。なお、ピア追加要求条件を満足しているかどうかをチェックは、条件チェック手段４３が行うようにしても良い。
【００６７】
リスト管理手段４２は、ピアリスト４２１と、削除予約リスト４２２を管理する。ピアリスト４２１は、コンテンツ毎のピアのリストである。ここでは、ピアリスト４２１は、トラッカー４自身が管理するピアツーピア（Ｐ２Ｐ）ネットワークに含まれるピアのリストである。リスト管理手段４２は、ピアツーピア（Ｐ２Ｐ）ネットワークへ追加されたピア１をピアリスト４２１に追加する。なお、ピアリスト４２１は、低優先ダウンロードピア、高優先ダウンロードピア、アップロード専用ピア、及び支援用ピアの夫々に対して、個別に用意するようにしても良い。削除予約リスト４２２は、離脱要求のあったピア１を示すリストである。リスト管理手段４２は、離脱要求のあったピア１を削除予約リスト４２２の末尾に追加する。
【００６８】
条件チェック手段４３は、属性クラスピア追加管理条件を設定する。なお、条件チェック手段４３は、ピア追加要求条件を満足するように、属性クラスピア追加管理条件の値（例えば、α、βの値）を算出する。また、条件チェック手段４３は、ピア削除管理条件を満足しているかどうかをチェックし、ピア削除管理条件を満足する場合、削除予約リスト４２２にエントリが存在するかどうかをチェックし、削除予約リスト４２２にエントリが存在する場合、先頭のエントリを削除対象として、トラッカー４の管理対象から削除する。すなわち、条件チェック手段４３は、削除予約リスト４２２の先頭のエントリにあるピアをピアツーピア（Ｐ２Ｐ）ネットワークから削除する。
【００６９】
問い合わせ手段４４は、ピア管理サーバ３への問い合わせを行う。例えば、問い合わせ手段４４は、ピア追加要求条件を満たすように低優先ダウンロードピア及びアップロード専用ピアの追加が可能かどうかの問い合わせを行う。
【００７０】
問い合わせ結果確認手段４５は、ピア管理サーバ３から問い合わせ結果を受信すると、問い合わせ結果のチェックを行う。例えば、問い合わせ結果確認手段４５は、問い合わせ結果を参照して、ピア管理テーブル３１１内にピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在するかどうかの確認を行う。問い合わせ結果確認手段４５は、ピア管理テーブル３１１内にピア追加要求条件を満たす低優先ダウンロードピア及びアップロード専用ピアが存在する場合、ピア管理テーブル３１１に含まれる低優先ダウンロードピア及びアップロード専用ピアを、支援用ピアとしてピアツーピア（Ｐ２Ｐ）ネットワークに追加する。
【００７１】
本発明により、所定のコンテンツに関するスワンプに関して、高優先ダウンロードピア数を低優先ダウンロードピア数とアップロード専用ピア数に比べて十分に少ない状態に維持することで常に高優先ダウンロードピアに対して十分な品質でコンテンツのダウンロードが可能なことを保証することが可能となる。
【００７２】
また、低優先ダウンロードピアの選択においては、将来ダウンロードする可能性の高いピアを優先して選択することで、該当ピア１が将来高優先ダウンロードピアになる可能性を提言し、コンテンツ配信システム全体での高優先ダウンロードピアの数を小さく抑えることが可能である。他の高優先ダウンロードピアのダウンロード速度を高速化することが可能である。
【００７３】
すなわち、本発明のコンテンツ配信システムは、以下のような特徴を有する。
本発明のコンテンツ配信システムは、コンテンツの配信元となる配信サーバと、コンテンツを受信する複数のピアと、コンテンツもしくは複数のコンテンツ群毎にコンテンツをダウンロードするピアを管理するトラッカーと、ピア全体の状態を管理するピア管理サーバとを含む。該トラッカーの管理するピア間で、コンテンツもしくはコンテンツ群毎のピアツーピア（Ｐ２Ｐ）ネットワークが構成される。該ピアは、該ピアツーピア（Ｐ２Ｐ）ネットワークを利用して、サーバからだけでなく他のピアからもコンテンツをダウンロードする機能を有する。このコンテンツ配信システムにおいて、ピアは複数の属性クラスに分類される。トラッカーは管理するピア群において、属性クラス毎のピア数が予め設定された属性クラスピア追加管理条件を満足するようにピアの管理を行う。トラッカーは、ピアからある属性クラスへの追加を要求された際にピア追加要求条件を満足できない場合、ピア管理サーバに問い合わせを行う。ピア管理サーバは、ピア追加要求条件を満足するように、他の属性クラスのピアを選択して支援用ピアリストを作成しトラッカーに応答する。トラッカーは、追加要求を行ったピアとピア管理サーバからの支援用ピアリストを自身の管理するピアツーピア（Ｐ２Ｐ）ネットワークに追加することでピア追加要求条件を満足するように維持する。ここでは、ピアがスワンプに参加する際に、ピアリストから支援用ピアを追加する。
【００７４】
本発明のコンテンツ配信システムにおいて、コンテンツのダウンロードが完了したピアは、トラッカーにコンテンツのダウンロード完了を通知すると、トラッカーは該ピアを削除予約リストに追加し、トラッカーは、ピア削除管理条件を満足する範囲で、トラッカーの管理するピアツーピア（Ｐ２Ｐ）ネットワークからのピアの離脱を許可する。ここでは、ピアがコンテンツダウンロード完了した際に、条件を満足している時のみ離脱する。
【００７５】
本発明のコンテンツ配信システムにおいて、ピアの属性クラスとして、高優先ダウンロードクラスと、低優先ダウンロードクラスと、アップロード専用クラスとが存在し、高優先ダウンロードクラスに属するピアが低優先ダウンロードクラスに属するピアよりも優先してコンテンツをダウンロードする。すなわち、高優先・低優先・アップロード専用のそれぞれの属性クラスが存在する。
【００７６】
本発明のコンテンツ配信システムにおいて、ピア管理サーバが、支援用ピアを選択する処理において、まず、アップロード専用ピアの選択を行い、アップロード専用ピアだけでピア追加条件を満足できない場合、次に低優先ダウンロードピアの選択を行う。すなわち、アップロード専用又は低優先のピアを選択する。
【００７７】
本発明のコンテンツ配信システムにおいて、ピア管理サーバが支援用ピアを選択する処理において、アップロード専用ピアの選択を行う際に保有コンテンツの少ないピアを優先する。
【００７８】
本発明のコンテンツ配信システムにおいて、ピア管理サーバが支援用ピアを選択する処理において、低優先ダウンロードピアの選択を行う際に将来該当コンテンツを閲覧する可能性の高いピアを優先して選択する。
【００７９】
ピア管理サーバは、各ピアを利用するユーザ同士が知り合いであるかどうかを判別するためのピア関係性テーブルを保有する。ピアは、他のピアが自分の知り合いであるかどうかを通知する手段を有する。ピアとピアとの関係性は知り合いを何人経由すれば到達できるかを示す知り合いホップ数で表される。将来該当コンテンツを閲覧する可能性の高いピアを選択する際に、ピア関係性テーブルにアクセスし、高優先ダウンロードピアとの知り合いホップ数が小さいピアを優先的に低優先ダウンロードピアとして割り当てる。
【００８０】
本発明のコンテンツ配信システムにおいて、配信サーバが動画コンテンツの配信を行い、ピアがコンテンツをダウンロードする際に高優先ダウンロードピアはコンテンツを先頭から順番にダウンロードする。
【００８１】
以上のように、本発明では、所定のコンテンツに関してダウンロード処理を行うピアツーピア（Ｐ２Ｐ）ネットワークを構築するに当たり、ピアを高優先ダウンロードピア、低優先ダウンロードピア、アップロード専用ピアに分類して、高優先ダウンロードピアは、利用ユーザの要求する品質を満足するような制御を行うために、低優先ダウンロードピアよりも優先してコンテンツのダウンロードを行う仕組みを導入する。
【００８２】
また、あるコンテンツに関して、ピアが直ぐにコンテンツを閲覧可能なように高優先ダウンロードを要求した際に、トラッカーが、高優先ダウンロードピアと低優先ダウンロードピアとアップロード専用ピアとの間の制約条件を満足するかをチェックする。制約条件を満足しない場合、ピア管理サーバに問い合わせを行い、適宜、低優先ダウンロードピアとアップロード専用ピアの追加割り当てを行うことで、高優先ダウンロードピアに比べて十分に多くの低優先ダウンロードピアとアップロード専用ピアが存在する状態を保持する。高優先ダウンロードピアの数が十分に小さければ、高優先ダウンロードピアが「Ｔｉｔ−ｆｏｒ−Ｔａｔ戦略」や「Ｒａｒｅｓｔ  Ｆｉｒｓｔ機構」を無視してコンテンツを優先的にダウンロードしても、低優先ダウンロードピアやアップロード専用ピアによりピアツーピア（Ｐ２Ｐ）ネットワーク全体としては統計的に十分な転送レートでコンテンツをダウンロード可能なネットワークの状態を保持することが可能である。
【００８３】
ピア管理サーバが、低優先ダウンロードピアを選択するに当たっては、将来的に該当コンテンツを閲覧する可能性の高いピアを選択する。該当コンテンツを閲覧する可能性の高いピアを選択することによって、該当ピアがコンテンツを閲覧する場合、コンテンツは既にダウンロードされていることからダウンロードの待ち時間が不要となり、ユーザの利便性・満足度が向上する。また、該当ピアが、高優先ダウンロードピアとしてコンテンツをダウンロードすることが不要となることで、結果的に高優先ダウンロードピア数を削減し、ピアツーピア（Ｐ２Ｐ）ネットワークを安定状態とすることが可能である。
【図面の簡単な説明】
【００８４】
【図１】図１は、本発明のコンテンツ配信システムの構成図である。
【図２】図２は、ピア管理テーブルの例を示す図である。
【図３】図３は、スワンプにピアを追加する際のトラッカーでの処理のフローチャートである。
【図４】図４は、スワンプにピアを追加する際にピア管理サーバ問い合わせ処理のフローチャートである。
【図５】図５は、スワンプからピアを削除する処理のフローチャートである。
【図６】図６は、ピアと、ピア管理サーバと、トラッカーの構成例を示すブロック図である。
【符号の説明】
【００８５】
１（−ｉ、ｉ＝１〜ｎ）…  ピア
１１…  ピア追加要求手段
１２…  ピース管理手段
１３…  関係性通知手段
２…  配信サーバ
３…  ピア管理サーバ
３１…  テーブル管理手段
３１１…  ピア管理テーブル
３１２…  ピア関係性テーブル
３１３…  アイドルピア管理リスト
３１４…  支援用ピアリスト
３２…  ピア検索手段
３３…  条件チェック手段
３４…  関係性管理手段
４…  トラッカー
４１…  要求クラスチェック手段
４２…  リスト管理手段
４２１…  ピアリスト
４２２…  削除予約リスト
４３…  条件チェック手段
４４…  問い合わせ手段
４５…  問い合わせ結果確認手段
１００…  コンテンツ配信システム
【図１】
2009151531.tif 000003
【図２】
2009151531.tif 000004
【図３】
2009151531.tif 000005
【図４】
2009151531.tif 000006
【図５】
2009151531.tif 000007
【図６】
2009151531.tif 000008