(57)【特許請求の範囲】
【請求項１】
複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する主配信システムと、
前記配信情報を識別するための配信情報識別情報と、当該配信情報を蓄積している前記ノード装置である蓄積装置を識別するための蓄積装置識別情報と、を含む配信情報所在情報を記憶する補助記憶手段を備える補助装置と、当該補助装置を管理する管理手段を備える管理装置と、により構成される補助システムと、
を含む配信システムであって、
前記主配信システムは、前記配信情報の所在を管理するノード装置であって、前記配信情報所在情報を記憶する所在情報記憶手段を備える前記ノード装置を含んでおり、
前記配信情報の所在は、当該配信情報を識別するための配信情報識別情報の値と等しい値又は一番近い値を有する識別情報が付与された前記ノード装置により管理されるものであり、
前記補助記憶手段は、前記所在情報記憶手段に記憶可能な前記配信情報所在情報の数より多い数の当該配信情報所在情報が記憶可能とされており、
更に前記主配信システムは、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて、前記補助装置の当該主配信システム内への補助参加を要求する補助要請情報を前記管理手段に出力する補助要請情報出力手段を備える前記ノード装置である制御装置を含み、
当該補助要請情報を取得した前記管理手段は、
前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成する生成手段と、
前記生成手段により生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認する確認手段と、
前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる指示手段と、
を備えることを特徴とする配信システム。
【請求項２】
請求項１に記載の主配信システムに含まれている制御装置であって、
前記要求情報出力手段を備えることを特徴とする制御装置。
【請求項３】
請求項２に記載の制御装置において、
前記補助要請情報出力手段は、前記配信情報所在情報の数が予め設定された閾値以上になったとき、前記補助要請情報を前記管理手段に出力することを特徴とする制御装置。
【請求項４】
請求項２又は３に記載の制御装置において、
前記主配信システム内に前記補助装置が参加している場合において、前記特定配信情報に対応する前記配信情報所在情報の数が所定の閾値未満となったとき、当該参加している補助装置を前記主配信システムから離脱させることを要求する離脱要求情報を前記管理手段に出力する離脱要求情報出力手段を更に備えることを特徴とする制御装置。
【請求項５】
請求項１に記載の補助システムに含まれている管理装置であって、
前記管理手段を備えることを特徴とする管理装置。
【請求項６】
請求項５に記載の管理装置において、
前記管理手段は、
前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成する生成手段と、
前記生成手段により生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認する確認手段と、
前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる指示手段と、
を備えることを特徴とする管理装置。
【請求項７】
請求項６に記載の管理装置において、
前記管理手段は、前記主配信システム内に前記補助装置が参加している場合において、当該参加している補助装置を前記主配信システムから離脱させることを要求する離脱要求情報を取得したとき、当該補助装置に対して前記主配信システムから離脱する旨の離脱指示情報を送信する離脱指示情報送信手段を更に備えることを特徴とする管理装置。
【請求項８】
請求項１に記載の補助システムに含まれている補助装置であって、
前記補助記憶手段を備えることを特徴とする補助装置。
【請求項９】
請求項８に記載の補助装置において、
前記補助記憶手段における前記配信情報所在情報の記憶可能数が、前記所在情報記憶手段における前記配信情報所在情報の記憶可能数の少なくとも二倍であることを特徴とする補助装置。
【請求項１０】
請求項８又は９に記載の補助装置において、
前記主配信システムに参加する際、前記特定配信情報を配信するために必要な配信制御情報であって前記配信情報所在情報を含む配信制御情報を、前記主配信システム内のいずれかの前記ノード装置から取得する取得手段と、
前記取得した配信制御情報を、前記補助記憶手段内に記憶させて前記特定配信情報の配信に供させる記憶制御手段と、
を備えることを特徴とする補助装置。
【請求項１１】
請求項１に記載の主配信システム内のいずれかの前記ノード装置に含まれるコンピュータを、請求項２から４のいずれか一項に記載の制御装置として機能させることを特徴とする制御装置用プログラム。
【請求項１２】
請求項１に記載の補助システム内の前記管理装置に含まれるコンピュータを、請求項５から７のいずれか一項に記載の管理手段として機能させることを特徴とする管理装置用プログラム。
【請求項１３】
請求項１に記載の補助システム内の前記補助装置に含まれるコンピュータを、請求項８から１０のいずれか一項に記載の補助装置として機能させることを特徴とする補助装置用プログラム。
【請求項１４】
複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する主配信システムと、
前記配信情報を識別するための配信情報識別情報と、当該配信情報を蓄積している前記ノード装置である蓄積装置を識別するための蓄積装置識別情報と、を含む配信情報所在情報を記憶する補助記憶手段を備える補助装置と、当該補助装置を管理する管理手段を備える管理装置と、により構成される補助システムと、
を含む配信システムであって、
前記主配信システムは、前記配信情報の所在を管理するノード装置であって、前記配信情報所在情報を記憶する所在情報記憶手段を備える前記ノード装置を含んでおり、
前記配信情報の所在は、当該配信情報を識別するための配信情報識別情報の値と等しい値又は一番近い値を有する識別情報が付与された前記ノード装置により管理されるものであり、
前記補助記憶手段は、前記所在情報記憶手段に記憶可能な前記配信情報所在情報の数より多い数の当該配信情報所在情報が記憶可能とされる前記配信システムにおいて実行される配信システム制御方法であって、
前記ノード装置である制御装置が、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて、前記補助装置の当該主配信システム内への補助参加を要求する補助要請情報を前記管理手段に出力する補助要請情報出力工程と、
当該補助要請情報を取得した前記管理手段が、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成し、当該生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認し、当該ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる工程と、
を含むことを特徴とする配信システム制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、配信システム、制御装置及び制御装置用プログラム、管理装置及び管理装置用プログラム、補助装置及び補助装置用プログラム並びに配信システム制御方法の技術分野に属し、より詳細には、インターネット等のネットワークを介して映画等のコンテンツ（配信情報）を配信する配信システム及び配信システム制御方法、当該配信システムに含まれる制御装置及び制御装置用プログラム、管理装置及び管理装置用プログラム並びに補助装置及び補助装置用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワークを介して上記コンテンツを蓄積しているサーバ等に端末装置からアクセスし、その端末装置において視聴が所望されているコンテンツを当該端末装置に配信して視聴する、いわゆるコンテンツ配信についての研究開発が盛んである。
【０００３】
ここで、従来の上記コンテンツ配信を行う配信システムの基本的構成は、例えば下記特許文献１に例示されるように、コンテンツの配信を所望する端末装置から上記ネットワークを介してそのコンテンツを蓄積するサーバ等に接続し、その接続を確立した上で所望するコンテンツの配信、即ち当該コンテンツの伝送をその端末装置において受ける構成となっている。
【０００４】
一方、近年では、上記コンテンツ配信を行う配信システムの他の構成として、いわゆるＰ２Ｐ（Peer to Peer）グリッド型の配信システム（以下、単に配信システムと称する）がある。ここで、当該配信システムとは、上記ネットワークを用いて上記コンテンツの配信を行う配信システムであって、当該ネットワークに属する端末装置間で、当該コンテンツに相当するコンテンツデータが相互に直接授受される（換言すれば、コンテンツを複数の端末装置間で共有する）配信システムであり、その配信システムに加入している全ての端末装置が、上記サーバとしての機能を有すると共に上記コンテンツの配信を受ける配信先装置としての機能をも備える配信システムである（なお、以下の説明では当該端末装置を単にノードと称する）。
【０００５】
そして、当該配信システムにおいては、あるノードにおいてコンテンツの配信を受けようとする場合、そのノードにおいては、配信を所望するコンテンツに相当するコンテンツデータを蓄積している他のノードを上記ネットワーク上において識別するためのノード識別情報と、そのコンテンツを他のコンテンツから識別するためのコンテンツ識別情報と、を対とした情報（以下、当該情報を単にインデックス情報と称する）を参照し、このインデックス情報内のノード識別情報により示されるノードから所望のコンテンツの配信を受ける必要がある。
【０００６】
そこで、一般の配信システムにおいては、例えば下記特許文献２に例示されるように、一又は複数のコンテンツに関する上記インデックス情報を、纏めて複数のノード内に夫々記憶（分散記憶）させ、これをそのコンテンツの配信を受けるノードから参照する構成とされている。より具体的には、例えば当該配信システムを構成するネットワークがインターネットである場合には、配信が所望されるコンテンツを特定できる検索情報（例えば映画のタイトル名）とそれを記憶しているノードのＩＰ（Internet Protocol）アドレスとの組を認識し、そのＩＰアドレスを手掛かりとして所望するコンテンツの授受を行う必要がある。
【０００７】
従って、上記配信システムの如き不特定多数のノードがコンテンツを共有し合うような配信システムにおいては、全てのコンテンツの検索情報とそれを記憶しているノードのＩＰアドレスとの組を各ノードが認識しておくことが必要となる。
【０００８】
しかしながら、ネットワークに接続されているノードの数が多くなった場合、各ノードにおける物理的な記録可能量の制限等が理由となって、全てのコンテンツの検索情報とそのコンテンツを記憶しているノードのＩＰアドレスを各ノードが夫々に記録しておくことは現実的ではない（例えば、ネットワークに百万台のノードが接続されている場合、その百万台分のＩＰアドレスを各ノードが互いに全て記録しておくことは全く現実的ではない）。
【０００９】
また、各ノードが全てのコンテンツの検索情報とそれを記憶するノードのＩＰアドレスを記録しておく場合、ネットワーク内の各ノードにおける電源スイッチのオン／オフが頻繁な場合（例えば当該ノードをパーソナルコンピュータにより実現する場合は頻繁に電源スイッチが操作され得ることになる）にも、各ノードに記録されたＩＰアドレス等の更新が頻繁になり、現実的にはネットワーク全体としての運用が困難となる。
【００１０】
そこで、上述したような問題点に対処すべく、必要最低限のノードのＩＰアドレス情報のみを記録し、そのＩＰアドレスを認識していない他のノードに対しては、そのノードに配信すべきメッセージを他のノードを介して転送して届け、また、各ノードが必要最低限のインデックス情報のみを記録するという仕組みの配信システムが研究されており、その一つに、インターネット等の物理的なネットワーク上に、いわゆるＤＨＴ（Distributed Hash Table；分散ハッシュテーブル）を利用して論理的なオーバーレイネットワークを構築し、当該オーバーレイネットワーク上においてコンテンツの配信を行う配信システムがある。
【００１１】
次に、当該ＤＨＴを用いた配信システムについて、概要を説明する。なお、以下の説明は、上記物理的なネットワークではなく上記オーバーレイネットワークに注目して当該配信システムを説明するものである。
【００１２】
上記ＤＨＴを用いた配信システムでは、上記オーバーレイネットワーク上において、各ノードを相互に識別するためのノードＩＤ（Identification）を当該各ノードに付与する。このとき、当該ノードＩＤは、それらが参加している配信システム内において各ノード毎にユニークな、即ち他のノードとは異なる番号を付与する。この番号は、そのネットワークにおけるノードの最大運用台数を収容できるだけのビット数（ビット長）を有するものとなる。より具体的には、例えば１２８ビットのノードＩＤを用いれば、最大で、２１２８≒３４０×１０３６台のノードを一つのネットワーク内に接続することができる。そして、当該ノードＩＤとして一般的には、ノード自体に付与されているＩＰアドレスやいわゆるＭＡＣ（Media Access Control）アドレス、或いはノード自体の製造番号等の、当該ノード毎に固有の値に対してハッシュ関数を適用して得られる値を用いる。
【００１３】
次に、上記ＤＨＴを用いた配信システムでは、その配信システムによって配信されるコンテンツ自体にも、それに対応する上記コンテンツ識別情報として、当該オーバーレイネットワーク上において他のコンテンツとは異なるユニークなコンテンツＩＤを付与する。このコンテンツＩＤのビット長も上記ノードＩＤのビット長と同一とされる。そして、当該コンテンツＩＤとして一般的には、そのコンテンツのタイトルを示すタイトルデータ、コンテンツを構成するデータの属性を示す属性データ、コンテンツを構成するデータのうち先頭から数バイト分のデータ等に対してハッシュ関数を適用して得られる値を用いる。
【００１４】
更に上記ＤＨＴを用いた配信システムにおいては、ノードの当該配信システムへの参加及び脱退（離脱）が頻繁に行われても、各ノードが負う負荷の分散が適切に行われる必要があり、この点につき下記非特許文献１には、当該配信システムにおいて、ノードの当該配信システムに対する参加及び脱退（離脱）が頻繁に行われる場合であっても、適切に負荷分散を行うための技術が開示されている。
【００１５】
一方、上述して来た配信システムにおいて、あるコンテンツに相当する一つのコンテンツデータに対して、それらを複製した複製データ（以下、当該複製データを単にレプリカと称する）を複数用意し、当該配信システムに参加している複数のノードにこれらのレプリカを分散して配置しておく（分散保存しておく）ことで、当該配信システムにおける耐故障性や各コンテンツ等に対するアクセスの分散性を高める手法が知られている。
【特許文献１】特開２０００−１２２９５４号公報
【特許文献２】特開２００４−２６５２７３号公報
【非特許文献１】「分散ハッシュテーブルの軽量な負荷分散手法の検討」  社団法人  電子情報通信学会  信学技報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、上述したレプリカを例えばアクセス頻度等に応じて当該配信システム内において動的に増やし続け、多くのコンテンツ保持ノードに保存させていくと、上記インデックス情報を記憶するノードの記憶領域の容量は有限であるため、当該記憶領域が容量オーバーとなり（つまり、それ以上インデックス情報を記憶しておけないという状況に至り）、上記レプリカを増やしても、これらのレプリカへのアクセス負荷をそれ以上分散できないという問題が生じる。
【００１７】
また、当該インデックス情報が多くなると、当該インデックス情報の記憶可能数がそれほど多くないノードにおいては、その配信要求の多いコンテンツに対応するインデックス情報により、そのノードに記憶されているインデックス情報の大半が占められてしまうこととなり、結果として、それほど人気のない（換言すれば、配信要求数が多くない）コンテンツに対応するインデックス情報の記憶数が減少してしまうと言う問題点があった。
【００１８】
そして、この問題点は、それほど人気のないコンテンツ（裏を返せば、人気はないけれど配信要求がゼロではないコンテンツ）の配信を希望する場合、対応するインデックス情報を配信システム内において発見できる可能性が低下することに繋がり、結果として、そのコンテンツの配信に支障を来す場合があると言う問題点に繋がることとなる。
【００１９】
そこで、本発明は上記の各問題点に鑑みて為されたもので、その課題は、不人気コンテンツのインデックス情報の記憶数が低減することによって当該インデックス情報に対応するコンテンツが配信不能状態となることを防止し、配信システムとしての利便性及び配信効率の向上に資することが可能な配信システム及び配信システム制御方法、当該配信システムに含まれる制御装置及び制御装置用プログラム、管理装置及び管理装置用プログラム並びに補助装置及び補助装置用プログラムを提供することにある。
【課題を解決するための手段】
【００２０】
上記の課題を解決するために、請求項１に記載の発明は、複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する主配信システムと、前記配信情報を識別するための配信情報識別情報と、当該配信情報を蓄積している前記ノード装置である蓄積装置を識別するための蓄積装置識別情報と、を含む配信情報所在情報を記憶する補助記憶手段を備える補助装置と、当該補助装置を管理する管理手段を備える管理装置と、により構成される補助システムと、を含む配信システムであって、前記主配信システムは、前記配信情報の所在を管理するノード装置であって、前記配信情報所在情報を記憶する所在情報記憶手段を備える前記ノード装置を含んでおり、前記配信情報の所在は、当該配信情報を識別するための配信情報識別情報の値と等しい値又は一番近い値を有する識別情報が付与された前記ノード装置により管理されるものであり、前記補助記憶手段は、前記所在情報記憶手段に記憶可能な前記配信情報所在情報の数より多い数の当該配信情報所在情報が記憶可能とされており、更に前記主配信システムは、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて、前記補助装置の当該主配信システム内への補助参加を要求する補助要請情報を前記管理手段に出力する補助要請情報出力手段を備える前記ノード装置である制御装置を含み、当該補助要請情報を取得した前記管理手段は、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成する生成手段と、前記生成手段により生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認する確認手段と、前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる指示手段と、を備える。
【００２２】
上記の課題を解決するために、請求項２に記載の発明は、請求項１に記載の主配信システムに含まれている制御装置であって、前記要求情報出力手段を備える。
【００２４】
上記の課題を解決するために、請求項３に記載の発明は、前記配信情報所在情報の数が予め設定された閾値以上になったとき、前記補助要請情報を前記管理手段に出力するように構成される。
【００２６】
上記の課題を解決するために、請求項４に記載の発明は、請求項２又は３に記載の制御装置において、前記主配信システム内に前記補助装置が参加している場合において、前記特定配信情報に対応する前記配信情報所在情報の数が所定の閾値未満となったとき、当該参加している補助装置を前記主配信システムから離脱させることを要求する離脱要求情報を前記管理手段に出力する離脱要求情報出力手段を更に備える。
【００２８】
上記の課題を解決するために、請求項５に記載の発明は、請求項１に記載の補助システムに含まれている管理装置であって、前記管理手段を備える。
【００３０】
上記の課題を解決するために、請求項６に記載の発明は、請求項５に記載の管理装置において、前記管理手段は、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成する生成手段と、前記生成手段により生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認する確認手段と、前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる指示手段と、を備える。
【００３２】
上記の課題を解決するために、請求項７に記載の発明は、請求項６に記載の管理装置において、前記管理手段は、前記主配信システム内に前記補助装置が参加している場合において、当該参加している補助装置を前記主配信システムから離脱させることを要求する離脱要求情報を取得したとき、当該補助装置に対して前記主配信システムから離脱する旨の離脱指示情報を送信する離脱指示情報送信手段を更に備える。
【００３４】
上記の課題を解決するために、請求項８に記載の発明は、請求項１に記載の補助システムに含まれている補助装置であって、前記補助記憶手段を備える。
【００３６】
上記の課題を解決するために、請求項９に記載の発明は、請求項８に記載の補助装置において、前記補助記憶手段における前記配信情報所在情報の記憶可能数が、前記所在情報記憶手段における前記配信情報所在情報の記憶可能数の少なくとも二倍であるように構成される。
【００３８】
上記の課題を解決するために、請求項８又は９に記載の補助装置において、前記主配信システムに参加する際、前記特定配信情報を配信するために必要な配信制御情報であって前記配信情報所在情報を含む配信制御情報を、前記主配信システム内のいずれかの前記ノード装置から取得する取得手段と、前記取得した配信制御情報を、前記補助記憶手段内に記憶させて前記特定配信情報の配信に供させる記憶制御手段と、を備える。
【００４４】
上記の課題を解決するために、請求項１１に記載の発明は、請求項１に記載の主配信システム内のいずれかの前記ノード装置に含まれるコンピュータを、請求項２から４のいずれか一項に記載の制御装置として機能させる。
【００４８】
上記の課題を解決するために、請求項１２に記載の発明は、請求項１に記載の補助システム内の前記管理装置に含まれるコンピュータを、請求項５から７のいずれか一項に記載の管理手段として機能させる。
【００５４】
上記の課題を解決するために、請求項１３に記載の発明は、請求項１に記載の補助システム内の前記補助装置に含まれるコンピュータを、請求項８から１０のいずれか一項に記載の補助装置として機能させる。
【００５８】
上記の課題を解決するために、請求項１４に記載の発明は、複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する主配信システムと、前記配信情報を識別するための配信情報識別情報と、当該配信情報を蓄積している前記ノード装置である蓄積装置を識別するための蓄積装置識別情報と、を含む配信情報所在情報を記憶する補助記憶手段を備える補助装置と、当該補助装置を管理する管理手段を備える管理装置と、により構成される補助システムと、を含む配信システムであって、前記主配信システムは、前記配信情報の所在を管理するノード装置であって、前記配信情報所在情報を記憶する所在情報記憶手段を備える前記ノード装置を含んでおり、前記配信情報の所在は、当該配信情報を識別するための配信情報識別情報の値と等しい値又は一番近い値を有する識別情報が付与された前記ノード装置により管理されるものであり、前記補助記憶手段は、前記所在情報記憶手段に記憶可能な前記配信情報所在情報の数より多い数の当該配信情報所在情報が記憶可能とされる前記配信システムにおいて実行される配信システム制御方法であって、前記ノード装置である制御装置が、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて、前記補助装置の当該主配信システム内への補助参加を要求する補助要請情報を前記管理手段に出力する補助要請情報出力工程と、当該補助要請情報を取得した前記管理手段が、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成し、当該生成された前記識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在しているか否かを確認し、当該ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させる工程と、を含む。
【発明の効果】
【００６０】
以上説明したように、請求項１または１４に記載の発明によれば、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて補助要請情報を管理手段に出力し、当該補助要請情報に対応して配信情報所在情報の記憶可能数が主配信システム内のノード装置より多い補助装置を主配信システムに参加させるので、主配信システムに属するノード装置において、当該配信情報に対する配信要求の集中により当該配信情報に対応する配信情報所在情報の数が増大することに起因する他の配信情報に対応する配信情報所在情報の記憶数の低減を防止できる。更に、請求項１に記載の発明によれば、補助要請情報を取得した前記管理手段は、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成し、この識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させるので、より迅速且つスムーズに補助装置を主配信システムに参加させることができる。
【００６１】
また、請求項２または１１に記載の発明によれば、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて補助要請情報を管理手段に出力し、当該補助要請情報に対応して管理装置により配信情報所在情報の記憶可能数が主配信システム内のノード装置より多い補助装置が主配信システムに参加させられるので、主配信システムに属するノード装置において、当該配信情報に対する配信要求の集中により当該配信情報に対応する配信情報所在情報の数が増大することに起因する他の配信情報に対応する配信情報所在情報の記憶数の低減を防止できる。
【００６２】
更に、請求項５または１２に記載の発明によれば、補助要請情報を取得した前記管理手段は、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成し、この識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させるので、より迅速且つスムーズに補助装置を主配信システムに参加させることができる。
【００６３】
更にまた、請求項８または１３に記載の発明によれば、前記所在情報記憶手段に記憶されている前記配信情報所在情報の中で、一の前記配信情報である特定配信情報に対応する前記配信情報所在情報の数に基づいて、管理装置の管理の下、配信情報所在情報の記憶可能数が主配信システム内のノード装置より多い補助装置が主配信システムに参加するので、主配信システムに属するノード装置において、当該配信情報に対する配信要求の集中により当該配信情報に対応する配信情報所在情報の数が増大することに起因する他の配信情報に対応する配信情報所在情報の記憶数の低減を防止できる。
【００６５】
従って、請求項１、２、５、８、１１乃至１４に夫々記載の発明によれば、配信情報所在情報の記憶数が低減することによって当該配信情報所在情報に対応する他の配信情報が配信不能状態となることを防止し、主配信システムにおける利便性及び配信効率の向上に資することができる。
【００６６】
請求項３に記載の発明によれば、請求項２に記載の発明の効果に加えて、配信情報所在情報の数が閾値以上になったとき補助要請情報を出力するので、現実の配信要求数又は複製情報の数に基づいて判定することで、効率的に主配信システムと補助システムとの間の連携を行うことができる。
【００６７】
請求項４に記載の発明によれば、請求項２又は３に記載の発明の効果に加えて、前記特定配信情報に対応する前記配信情報所在情報の数が所定の閾値未満となったとき、主配信システム内に参加している補助装置を主配信システムから離脱させることを要求する離脱要求情報を管理手段に出力するので、特定配信情報の配信状況が改善されたときは補助装置を主配信システムから離脱させることで、元の主配信システムの状態に復帰させることができると共に、以後の配信状況の悪化に備えて補助システムを待機させることができる。
【００６８】
請求項６に記載の発明によれば、請求項５に記載の発明の効果に加えて、補助要請情報を取得した前記管理手段は、前記制御装置を識別するための制御装置識別情報の値が、前記特定配信情報を識別するための配信情報識別情報の値と等しいとき、当該配信情報識別情報の値に対して直近に大きい値又は直近に小さい値を有する識別情報を生成し、この識別情報と等しい識別情報が付与された前記ノード装置が前記主配信システム内に既に存在していないときは、当該識別情報を前記補助装置に対して割り振り、当該補助装置へ前記主配信システムへの参加を指示し、当該補助装置に当該主配信システム内における前記特定配信情報の所在を管理させるので、より迅速且つスムーズに補助装置を主配信システムに参加させることができる。
【００７１】
請求項７に記載の発明によれば、請求項６に記載の発明の効果に加えて、主配信システム内に参加している補助装置をその主配信システムから離脱させることを要求する離脱要求情報を取得したとき、当該補助装置に対して主配信システムから離脱する旨の離脱指示情報を送信するので、主配信システムに参加していた補助装置を迅速に管理装置の管理下に戻すことができる。
【００７２】
請求項９に記載の発明によれば、請求項８に記載の発明の効果に加えて、補助記憶手段における配信情報所在情報の記憶可能数が、所在情報記憶手段における配信情報所在情報の記憶可能数の少なくとも二倍であるので、主配信システムにおける特定配信情報の配信状態の改善のために十分な機能を持った補助装置を当該主配信システムに参加させることができる。
【００７３】
請求項１０に記載の発明によれば、請求項８又は９に記載の発明の効果に加えて、主配信システムに参加する際、主配信システム内のいずれかのノード装置から配信制御情報を取得し、その取得した配信制御情報を補助記憶手段内に記憶させて特定配信情報の配信に供させるので、簡易且つ迅速な処理で補助装置を主配信システムに参加させ、直ちに特性配信情報の配信に供させることができる。
【発明を実施するための最良の形態】
【００８８】
次に、本発明を実施するための最良の形態について、図面に基づいて説明する。なお、以下に説明する実施形態は、インターネット等のネットワークを用いて上記コンテンツの配信を行う上記配信システムに対して本発明を適用した場合の実施の形態である。
【００８９】
（Ｉ）本発明の原理
初めに、本発明の実施形態について具体的に説明する前に、本発明の原理につき、実施形態に係る配信システムの概要と共に説明する。
【００９０】
（Ａ）配信システムの概要
先ず、実施形態に係る配信システムの概要につき、図１及び図２を用いて説明する。なお、図１及び図２は当該配信システムの概要を示す模式図である。
【００９１】
一般に、上述したＤＨＴを用いた配信システムにおいては、対応するノードＩＤ及びコンテンツＩＤが相互に同じビット長で表現されていることも関連して、当該配信システム内の上記ノード及びコンテンツを、同一のリング状の仮想的なＩＤ空間上に点在するものとして考えることができる。即ち、一のノードを●で表示し且つ一のコンテンツを○で表示する図１（ａ）に示すように、コンテンツが属するリングＲcとノードが属するリングＲnとを仮想的に同心円状に想定し、更に各リングＲc及びＲnにおいて反時計回りに各ＩＤの値が増加すると規定すると、各ノード又は各コンテンツは、各リングＲc及びＲn上に重なることなく存在すると仮定できるのである。なお、各ＩＤを上記の例のように１２８ビット長で表現すると桁数が多くなりすぎるので、図１（ａ）においては、説明の簡略化のために、各ＩＤのビット長を３２ビットとして表現している（以下、同様）。そして、上述したように各ＩＤの値を決めるに当たってハッシュ関数を用いたことに起因して、各ノード及び各コンテンツは、上記各リングＲc及びＲn上に偏ることなく概ね分散して存在することとなる。
【００９２】
一方、上記ＤＨＴを用いた配信システムでは、「あるコンテンツＩＤが付与されているコンテンツを管理するノードは、そのコンテンツＩＤの値に一番近い値を有するノードＩＤが付与されているノード」とされている。
【００９３】
ここで、「近い」とは、その配信システムに関する各種規定等において一貫してさえいればどのような定義付けでも良いのであるが、具体的には例えば、「そのコンテンツＩＤの値を超えない値であって且つＩＤとしての値同士の差が最も小さいもの」というように定義付けられる。
【００９４】
より具体的には、例えば図１（ａ）に例示するように、ノードＩＤの値が「Ａ０３３４０５５」であるノードとノードＩＤの値が「Ａ０３３４０ＦＦ」であるノードとがリングＲn上で隣り合って存在しているとすると、コンテンツＩＤの値が「Ａ０３３４０８０」であるコンテンツは、ノードＩＤの値が「Ａ０３３４０５５」であるノードが管理することになる。なお、図１（ａ）では、○のコンテンツを管理する端末情報を、当該各○から伸びた矢印で示している。このようにすると、多数のノードで分散して様々なコンテンツを管理することができる。
【００９５】
このとき、「管理」とは、そのコンテンツＩＤが付与されているコンテンツをその中に記録しているという意味ではなく、そのコンテンツが記録されているノードの所在（例えばＩＰアドレス等）を認識しているとの意味である。実際にコンテンツが記録されているノードと管理するノードとが異なっても良いし、或いは管理するノード内にその管理対象であるコンテンツが記録されていても良い。
【００９６】
そして、上述したコンテンツ管理用のノードを「ルートノード」と称する。ルートノードは、それが管理することとされているコンテンツを示すコンテンツＩＤと、当該コンテンツＩＤにより示されるコンテンツが記録されているノードのＩＰアドレスと、の対から少なくともなる上記インデックス情報を記録し、これを配信システム内の他のノードから参照可能に記録する。このインデックス情報内に、そのコンテンツのタイトルやその属性（ジャンル）等が含まれる場合もある。
【００９７】
また、異なるコンテンツを夫々示すコンテンツＩＤが偶然に近い値となり、その値に近い値のノードＩＤを有するノードが他に存在しない場合には、一つのルートノードが複数のコンテンツに対応する複数のインデックス情報を記録することとなる。更に、同一のコンテンツが異なる複数のノード内に記録されている場合であって、その同一のコンテンツを記録しているノードが偶然に一つのルートノードに近い場合、当該ルートノードには、同一のコンテンツが夫々に記録されている複数のノードのインデックス情報が記録されることとなる。上述してきたルートノード内のインデックス情報ＥＸの一例を図１（ｂ）に示す。
【００９８】
更に、実際に各コンテンツ自体を記録しているノードを「コンテンツホルダ」と称する。このとき、当該コンテンツホルダ自体は本来的にはノードであるから、そのノードＩＤは、図１（ａ）におけるリングＲn上に存在していることになる。
【００９９】
次に、上記ＤＨＴを用いた配信システムにおいて、上述したように全てのノードのＩＰアドレスを各ノード夫々が記録する必要性を排除するための工夫の一つであるＤＨＴ（ルーティングテーブル）自体について説明する。
【０１００】
実施形態に係るＤＨＴには、図１に例示したＩＤ空間を段階的なレベル毎にレベル数を上げつつ細分化（例えば、レベル１の場合は当該ＩＤ空間を四分割）していき、そのレベル毎（段階的に細分化した領域毎）に、任意のノードのノードＩＤとそのＩＰアドレスとを対としたルーティング情報が記述されている。そして、例えばコンテンツの配信元情報を要求するための配信元問い合わせ情報をそのインデックス情報が記録されているルートノードに転送する場合、このルーティング情報を参照しつつ当該問い合わせ情報を目的のルートノードまで転送する。即ち、ＤＨＴにおけるレベルが上がる度に、ルーティング先のノードＩＤが到達しようとするルートノードのノードＩＤに一桁ずつ合致していき、最終的に当該到達しようとするルートノードに上記要求情報が到達することになる。
【０１０１】
なお、ＤＨＴを用いた配信システムにおいては、上述した如き問い合わせ情報（クエリ）や、そのコンテンツの配信自体を要求する配信要求情報、及び後述する公開メッセージ、などを単に「メッセージ」と称している。そして、上述した仕組みのＤＨＴを使うと、上記メッセージを図１に例示する如き上記ＩＤ空間内で効率よく目的のノードまで転送することができる。なお、以下の説明においては、コンテンツホルダにおいて新たにコンテンツが記録された場合に、それを他のノードから発見可能にする（公開する）ために、当該コンテンツホルダにおいて生成されるメッセージを公開メッセージと称し、後述するリクエスタからルートノード又は後述するキャッシュノードに対して送信するメッセージを配信元問い合わせメッセージと称する。
【０１０２】
ここで、上述したようにルートノードのノードＩＤの値は、そのルートノードがコンテンツを管理しているコンテンツホルダのノードＩＤの値に最も近いのであるから、上記配信元問い合わせメッセージは、当該配信要求メッセージにより要求されているコンテンツホルダに到達する直前に、配信要求対象のコンテンツを管理するルートノードに到達することになる。そして、当該配信元問い合わせメッセージを受け取ったルートノードは、その配信元問い合わせメッセージにより要求されているコンテンツを蓄積しているコンテンツホルダのＩＰアドレス等を、当該配信元問い合わせメッセージの発信元まで返信する。即ち、ルートノード内に記録されているインデックス情報（図１（ｂ）参照）の中から、当該配信元問い合わせメッセージにより要求されているコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等が配信元問い合わせメッセージの発信元であるノードまで返信される。このようなＤＨＴの活用により、効率的に所望のコンテンツの所在が例えば配信要求元において認識できるのである。なお、上述したコンテンツの配信要求元であるノードを、以下「リクエスタ」と称する。
【０１０３】
次に、あるノードに新たなコンテンツが蓄積された場合における当該コンテンツの登録処理について説明する。
【０１０４】
新しいコンテンツがノード、即ちそのコンテンツのコンテンツホルダに蓄積されると、そのコンテンツホルダは、配信システム内の他のノードに対してそのコンテンツが蓄積されたことを公開することになる。
【０１０５】
即ち、あるノードに新たなコンテンツが蓄積されたとき、当該蓄積されたコンテンツに対するコンテンツホルダとなるそのノードは、蓄積されたコンテンツのタイトル等に基づき、当該コンテンツに対応するコンテンツＩＤを算出する。
【０１０６】
次に、当該コンテンツホルダは、算出されたコンテンツＩＤと同じ値を有するノードＩＤを有するノードを到達先として（そのノードＩＤを有するノードが実在するかどうかに拘わらず）、公開メッセージを送信する。この公開メッセージは、そのコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等を含むものであり、上記ＤＨＴの記述に従って各ルーティング先を介して各レベルの到達先としてのノードに順次転送される。
【０１０７】
そして、最も近い値のノードＩＤを有するノードに到達すると、そのノードはその後にその公開メッセージを転送すべきノードがＩＤ空間内に存在しないことを認識して（ＤＨＴで桁合わせをすると、次に転送すべきノードが自分自身であることを認識する）、この時点で当該公開メッセージが到達しているノードが新たなコンテンツを管理するルートノードとなることになる。そして、当該ルートノードとなったノードは、公開メッセージ含まれているコンテンツＩＤ及びコンテンツホルダを示すＩＰアドレス並びに属性情報等を図１（ｂ）に例示するインデックス情報ＥＸとして記録する。
【０１０８】
次に、実施形態に係る配信システムにおける「キャッシュノード」なる概念について、図２を用いて説明する。なお、図２及び後述の図３においては、ルートノードを二重丸で示し、コンテンツホルダを内部に×が記された○で示し、リクエスタを内部に｜が記された○で示し、後述するキャッシュノードを内部に＋が記された○で示し、他の一般のノードは●で示す。
【０１０９】
上述したＤＨＴを用いたルーティングによりリクエスタＲＱ１乃至ＲＱ３からの配信元問い合わせメッセージＱＲmsgをルートノードＲＮ（又はコンテンツホルダＣＨ）に転送する場合、その転送経路（図２（ａ）及び図２（ｂ）において破線で示す）は、図２（ａ）に示すように上述した公開メッセージＰＵＢmsgが辿った経路（図２（ａ）及び図２（ｂ）において実線で示す）と似た経路となるので、この経路上にある各ノード（図２（ａ）において符号ＣＮで示す）においても図１（ｂ）に例示するインデックス情報ＥＸを記録しておけば、当該経路を経る配信元問い合わせメッセージＱＲmsgに対応して、その到達先であるルートノードＲＮ又はコンテンツホルダＣＨに当該配信元問い合わせメッセージＱＲmsgが到達する前に、早い段階で当該配信元問い合わせメッセージＱＲmsgに対応する回答をリクエスタＲＱ１乃至ＲＱ３まで返信することができる。
【０１１０】
即ち、配信システム内に公開されたコンテンツの配信を要求するリクエスタＲＱ１乃至ＲＱ３が、そのコンテンツが記録されているノード（即ちコンテンツホルダＣＨ）のＩＰアドレスを要求する旨の配信元問い合わせメッセージＱＲmsgを送信すると、当該配信元問い合わせメッセージＱＲmsgは各ノード内のＤＨＴに記述されているルーティング先を転送されルートノードＲＮに近づいていく。そして、最終的には、その経路がコンテンツホルダＣＨからの公開メッセージＰＵＢmsgの経路と合流して、ルートノードＲＮに到達する。
【０１１１】
ここで、図２（ａ）に示したリングＲc上の経路を木構造に置き換えると図２（ｂ）に示した如きものとなるが、これを一般には「スパニングツリー」と称する。
【０１１２】
なお、この「スパニングツリー」なる用語は、元々はＩＰルータの接続がループ状にならないようにするためのルータ技術の中で使われる用語ではあるが、図２（ｂ）に示す場合でも、ループにならない転送経路のツリーがコンテンツＩＤ毎に一つ定義できる（当該図２（ｂ）では省略されているが、その時点で配信システム内に参加している全てノードを含んだスパニングツリーを記述することができる）。
【０１１３】
一方、図２（ａ）に示したように、各リクエスタＲＱから送信された配信元問い合わせメッセージＱＲmsgの経路とコンテンツホルダＣＨから送信された公開メッセージＰＵＢmsgの経路とは、それら経路上のいずれかのノードにおいていずれ交わる。そこで、公開用の公開メッセージＰＵＢmsgをルートノードＲＮまで到達させる経路上にあるノード夫々に当該公開メッセージＰＵＢmsgに含まれているインデックス情報ＥＸを、一時的に記録可能な一時記録領域に記録させつつ（即ち、一時的にキャッシュさせつつ）当該公開メッセージＰＵＢmsgの転送を行う。そうすれば、リクエスタＲＱからの配信元問い合わせメッセージＱＲmsgに対する返信を、ルートノードＲＮに至る経路上の配信元問い合わせメッセージＱＲmsgが到達したノードから、配信元問い合わせメッセージＱＲmsgがルートノードＲＮに到達する前に行うことができるのである。このようにルートノードＲＮ以外のノードであってインデックス情報ＥＸを一時的に記録しているノードを、以下「キャッシュノード」ＣＮと称する。
【０１１４】
一方、本発明に係るＤＨＴを用いた配信システムにおいて、当該配信システム内に参加しているコンテンツホルダＣＨが多くなることで配信可能なコンテンツが種類及び数共に増大してくると、当該各コンテンツに夫々対応しているインデックス情報ＥＸが、図３に例示するスパニングツリーに見られるように、ルートノードＲＮ又はキャッシュノードＣＮの夫々について数多く記憶されることになる。
【０１１５】
そして、これに加えて、図３に例示するように、一つのルートノードＲＮ又はキャッシュノードＣＮの夫々に複数のコンテンツに対応するインデックス情報ＥＸが記録されており、更に一つのコンテンツにつき、同一のコンテンツを記録する複数のコンテンツホルダＣＨを示すインデックス情報ＥＸが記録されるようになり、当該ルートノードＲＮ又はキャッシュノードＣＮに記憶されるインデックス情報ＥＸの数も増大していくこととなる。
【０１１６】
このとき、当該配信システムにおいて、あるコンテンツに対する配信要求が増大してくる（即ち、そのコンテンツが人気コンテンツとなる）と、そのコンテンツを蓄積しているコンテンツホルダＣＨの数が少ないと、増大する配信需要に対応できず、配信遅延や配信不可能状態が発生してしまうことになる。
【０１１７】
これに対応すべく、上記配信システムにおいては、配信要求（上記配信元問い合わせメッセージＱＲmsgを含む。以下、同じ）が多く発生しているコンテンツについては、他のノード内に当該コンテンツの複製（いわゆるレプリカ）を蓄積させることで、配信元のコンテンツホルダＣＨとしての機能を配信システム内で分散することで、当該配信要求の増大に対応する場合が多い。そしてこの場合にも、図３に例示するように、同一のコンテンツＩＤについて異なるＩＰアドレスを含む上記インデックス情報ＥＸが更に増大することとなる。
【０１１８】
（Ｂ）本発明の原理
次に、概要を上述した配信システムを前提とする本発明に原理について、図４を用いて説明する。
【０１１９】
上述したような、同一のコンテンツＩＤについて異なるＩＰアドレスを含む上記インデックス情報ＥＸが配信システム内において増大することに備え、本発明に係る配信システムＳは、図４に示すように、上記Ｐ２Ｐ型の配信システムと同様の構成を備える主配信システムＳＭの他に、物理的なネットワークとしては当該主配信システムＳＭ内に参加しているノードＮ又はルートノードＲＮとの間でメッセージ等の授受が可能とされてはいるが、普段は当該主配信システムＳＭには参加していない補助システムＳＰを備える。
【０１２０】
そして、当該補助システムＳＰは、主配信システムＳＭ内に参加している各ノードＮ又はルートノードＲＮ夫々におけるインデックス情報ＥＸの記憶可能量よりも多くの（より望ましくは２倍以上）インデックス情報ＥＸを記憶することが可能である複数のヘルパーノードＳＮと、これら複数のヘルパーノードＳＮの配信システムＳＭへの参加又は脱退を司る補助サーバＳＰＭとにより構成されている。
【０１２１】
この構成において、主配信システムＳＭ内において、特定のコンテンツ（当該特定コンテンツのコンテンツＩＤを、仮に「１２３４」とする）に対する配信要求が増大する（即ち、その特定コンテンツの人気が上昇する）ことで当該特定コンテンツのレプリカが主配信システムＳＭ内の多数のノードに夫々蓄積されて来ると、例えば図４に示すルートノードＲＮ内のインデックスメモリＣＭ１では、当該特定コンテンツ（コンテンツＩＤ＝１２３４）に対応するインデックス情報ＥＸがその記憶領域の大半を占めてしまうこととなる。そして、その結果として、当該特定コンテンツ以外の他のコンテンツ（換言すれば、不人気コンテンツであり、図４に例示するインデックスメモリＣＭ１内で言えばコンテンツＩＤが「８８ｄ３」であるコンテンツ）に対応するインデックス情報ＥＸが記憶される余地が少なくなってしまう。このことは、当該不人気コンテンツの配信を所望するリクエスタＲＱから見ると、その不人気コンテンツの配信元となるコンテンツホルダＣＨを発見する機会が損なわれてしまう等の配信障害を招来することを意味する。
【０１２２】
そこで、本発明では、上述した理由により例えばルートノードＲＮ内のインデックスメモリＣＭ１内でインデックス情報ＥＸの記憶数につき、コンテンツ間での過剰な不均衡が発生する状態となったときは、補助サーバＳＰＭの制御の元、主配信システムＳＭ内のノードＮ又はルートノードＲＮよりもインデックス情報ＥＸの記憶可能数が大きいインデックスメモリＣＭ２を備えるヘルパーノードＳＮを臨時に主配信システムＳＭ内に参加させ、当該主配信システムＳＭ内において広範囲のコンテンツに対応するインデックス情報ＥＸの一時記憶に供させる。これに加えて、ヘルパーノードＳＮのノードＩＤを人気が集中しているコンテンツのコンテンツＩＤに一致させて参加させることで、当該ヘルパーノードＳＮを上記特定コンテンツ（コンテンツＩＤ＝「１２３４」）に対する新たなルートノードＲＮとして稼働させる。
【０１２３】
このヘルパーノードＳＮの主配信システムＳＭへの臨時参加は、そのインデックスメモリＣＭ１内においてコンテンツまでの過剰な不均衡が発生しているルートノードＲＮからの援助依頼メッセージＲＭＧを補助サーバＳＰＭが受け取ることから開始され、その援助依頼メッセージＲＭＧを受け取った補助サーバＳＰＭがヘルパーノードＳＮの一つに参加指示メッセージＣＭＧを送信することにより、当該ヘルパーノードＳＮの主配信システムＳＭへの臨時参加が実際に実行される。
【０１２４】
このようにヘルパーノードＳＮを主配信システムＳＭに臨時参加させることで、当該ヘルパーノードＳＮは、上記特定コンテンツ（コンテンツＩＤ＝「１２３４」）に対する新たなルートノードＲＮとなり、当該ヘルパーノードＳＮ内のインデックスメモリＣＭ２には、図４に例示するように、上記特定コンテンツ（コンテンツＩＤ＝「１２３４」）に対応するインデックス情報ＥＸが多数記憶されることとなり、上述した如き配信障害の招来は未然に防止できることとなる。
【０１２５】
（II）実施形態
次に、上述した原理に則った本発明に係る実施形態について、具体的に図５乃至図９を用いて説明する。なお、以下に説明する第１実施形態に係る配信システムでは、説明の簡略化のため、当該配信システム内に上記キャッシュノードＣＮが存在していないものとして説明する。
【０１２６】
始めに、実施形態に係るノードの概要構成について図５を用いて説明する。なお、図５は実施形態に係るノードの概要構成を示すブロック図である。また、実施形態においては、上記コンテンツホルダＣＨ、リクエスタＲＱ、ルートノードＲＮ、その他のノードＮ、補助サーバＳＰＭ及びヘルパーノードＳＮは、インデックスメモリＣＭの記憶容量を除き、基本的に全て同一のハードウエア構成を有するものであるので、それらを代表して一般のノードＮの構成について、図５を用いてその概要を説明する。
【０１２７】
図５に示すように、実施形態に係る配信システムに含まれているノードＮは、演算機能を有するＣＰＵ、作業用ＲＡＭ（Random Access Memory）、各種データ及びプログラムを記録するＲＯＭ（Read Only Memory）等から構成された制御部１１と、上記コンテンツ自体としてのコンテンツデータ、上記ＤＨＴ及びその他の必要なプログラム等を記録保存（格納）すると共に上記インデックス情報ＥＸを記憶するための上記インデックスメモリＣＭを兼ねるＨＤＤ等から構成された記憶部１２（上記コンテンツデータは、その配信前はコンテンツホルダＣＨとしてのノードＮ内の記憶部１２内にのみ記録されている）と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコード（符号化）されたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ（Cathode Ray Tube）又は液晶ディスプレイ等よりなる表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ／Ａ（Digital/Analog）変換した後これを増幅器等により増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノードＮとの間の情報の通信制御を行なうための通信部２０と、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する入力部（例えば、キーボード、マウス或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【０１２８】
そして、制御部１１におけるＣＰＵが記憶部１２等に記録された各種プログラムを実行することにより、制御部１１が、リクエスタＲＱ、ルートノードＲＮ、コンテンツホルダＣＨ、補助サーバＳＰＭ、ヘルパーサーバＳＮ又はそれら以外の一般のノードＮのいずれか一つとしての全体動作を統括制御する。
【０１２９】
なお、上記ノードＮが本発明に係る制御装置としてのルートノードＲＮである場合は、記憶部１２が所在情報記憶手段として機能し、制御部１１が要求情報出力手段及び離脱要求情報出力手段として機能する。また、上記ノードＮが本発明に係る管理装置としての補助サーバＳＰＭである場合は、制御部１１が識別情報設定手段及び離脱指示情報送信手段として機能する。更に、上記ノードＮが本発明に係る補助装置としてのヘルパーノードＳＮである場合は、記憶部１２が補助記憶手段としての機能し、制御部１１が取得手段及び記憶制御手段として機能する。
【０１３０】
次に、ノード一般（ルートノードＲＮ、コンテンツホルダＣＨ及びリクエスタＲＱを含む）としての基本的な共通動作、ルートノードＲＮ、補助サーバＳＰＭ及びヘルパーノードＳＮに分けて、実施形態に係る動作について説明する。
【０１３１】
（Ａ）ノードとしての一般動作
先ず、実施形態に係るノードＮとしての一般動作、即ち、主配信システムＳＭ内のノードＮとしての基本的な共通動作を、図６を用いて説明する。なお、図６は実施形態に係るノードＮとしての一般動作を示すフローチャートであり、制御部１１により実行される。
【０１３２】
図６に示すように、実施形態に係るノードＮとしての共通動作においては、先ず、制御部１１は、当該ノードＮを起動するための初期化処理を行い（ステップＳ１）、主配信システムＳＭにそのノードＮが参加するための参加要求メッセージを、当該ノードＮが主配信システムＳＭに参加するに当たっての仲介役となる他のノードＮであるコンタクトノードに送信し（ステップＳ２）、その参加の可否の回答を待つ（ステップＳ３）。そして、そのノードＮが主配信システムＳＭ内に参加できない何らかの理由（たとえば、主配信システムＳＭに新規に参加する場合には料金が発生することとされている場合においてその料金の支払いが確認されない場合等）があるときは（ステップＳ３；ＮＯ）、その旨をそのノードＮの表示部１６に表示する等してその使用者に告知して（ステップＳ１５）、当該ノードＮとしての実施形態に係る処理を終了する。
【０１３３】
一方、ステップＳ３の判定において、そのノードＮが主配信システムＳＭ内に参加することが許可される場合は（ステップＳ３；ＹＥＳ）、そのコンタクトノードから主配信システムＳＭにおいてその時に有効な上記ルーティング情報を取得して記憶し（ステップＳ４）、更に新規に参加したノードＮが主配信システムＳＭ内の他のノードＮに配信可能なコンテンツを記憶している場合には、上記コンテンツホルダＣＨとしてそのコンテンツに対応する上記公開メッセージＰＵＢmsgを生成して主配信システムＳＭ内に送信する（ステップＳ５）。
【０１３４】
そして、記憶部１２内の後述する再生指示フラグ及び後述する端末終了指示フラグを「０」に初期化すると共に、新たに参加したノードＮの使用者に対して、主配信システムＳＭ内において配信を受けることが可能なコンテンツを検索して選択する等のためのスレッド（当該スレッドの詳細は、後ほど図７を用いて説明する）を起動する処理を行う（ステップＳ６）。
【０１３５】
ここで、上記再生指示フラグとは、ノードＮの使用者が上記入力部２１を用いて行う入力操作により視聴を希望するコンテンツを選択決定したときに「１」となる制御部１１内のフラグであり、一方、端末終了指示フラグは、当該使用者が入力部２１を用いてノードＮの使用を終了する旨の操作を行ったときに「１」となる制御部１１内のフラグである。
【０１３６】
そして、当該スレッドにおける処理により当該各指示フラグが更新されて「１」に変化することを待機すると共に、参加した主配信システムＳＭの他のノードＮからの各種メッセージの受信を待機する（ステップＳ７、Ｓ８；ＮＯ）。
【０１３７】
そして、使用者によるいずれかの指示フラグの変化又はいずれかのメッセージの受信がされたときは（ステップＳ８；ＹＥＳ）、再生指示フラグが「１」であるか否か、即ち使用者によるコンテンツの配信要求操作があったか否かを確認する（ステップＳ９）。
【０１３８】
ステップＳ９の判定において、使用者による当該配信要求操作があったときは（ステップＳ９；ＹＥＳ）、当該ノードＮは以後上記リクエスタＲＱとして動作することとなるので、その配信が所望されるコンテンツの発見処理又はその取得後の再生処理を実行する（ステップＳ１３）。なお、再生指示フラグが「１」になったときは、それと同時にスレッド処理中にユーザが選択したコンテンツのコンテンツＩＤが記憶されているので、そのコンテンツＩＤを用いて発見・再生処理が行われる。
【０１３９】
そして、コンテンツの再生が開始した後は、再生指示フラグを「０」に戻して（ステップＳ１６）、次の配信要求等に備えて上記ステップＳ７の処理に移行する。
【０１４０】
一方、ステップＳ９の判定において、ステップＳ８における処理が使用者による配信要求操作でないときは（ステップＳ９；ＮＯ）、ステップＳ８における処理は、配信要求操作以外の入力操作か、或いは他のメッセージの受信処理であったこととなるので、メッセージ受信があったか否かを確認する（ステップＳ１０）。そして、メッセージの受信処理だったときは（ステップＳ１０；ＹＥＳ）、当該受信したメッセージに対応する処理（具体的には、ルーティング情報の更新処理、他のノードＮへのメッセージの転送処理等）を行い（ステップＳ１４）、上記ステップＳ７の処理に移行する。
【０１４１】
他方、ステップＳ１０の判定において、未だいずれのメッセージも受信していないときは（ステップＳ１０；ＮＯ）、次に、先ほどの入力操作が、当該ノードＮとしての動作を終了する旨の操作であったか否かを確認する（ステップＳ１１）。そして、当該操作がされていないときは（ステップＳ１１；ＮＯ）、無効な操作がなされたと見なし、上記ステップＳ８の処理に移行する。
【０１４２】
これに対し、ノードＮとしての動作を終了する旨の操作が為されたときは（ステップＳ１１；ＹＥＳ）、脱退メッセージ等の主配信システムＳＭへの送信処理等の脱退処理を実行し（ステップＳ１２）、実施形態に係るノードＮとしての動作を終了する。
【０１４３】
次に、上記ステップＳ６の処理の一部として実行される、上記スレッドの内容について具体的に図７を用いて説明する。なお、図７は、当該スレッドの内容を示すフローチャートである。
【０１４４】
当該スレッドとして具体的には、図７に示すように、コンテンツ検索及び選択操作のためのスレッドが開始されると、先ず、コンテンツ検索用の予め設定された検索画面を表示部１６に表示する。
【０１４５】
ここで、当該検索画面としては、例えば、その検索画面としての表題が表示される表題欄と、コンテンツのタイトルを手掛かりとして検索を行う際に当該タイトルが入力されるタイトル入力欄と、そのコンテンツに出演している俳優等の名前を手掛かりとして検索を行う際に当該名前が入力される名前入力欄と、そのコンテンツの監督の名前を手掛かりとして検索を行う際に当該名前が入力される名前入力欄と、そのコンテンツを端的に示すキーワードを手掛かりとして検索を行う際に当該キーワードが入力されるキーワード入力欄と、入力された検索条件を用いてコンテンツを検索させる際に操作する検索操作ボタンと、その他の種々の情報を表示するための情報表示欄と、当該情報の続きを表示させるために操作される操作ボタンと、ノードＮとしての動作終了を指示するための終了ボタンと、他の種々の情報が表示される情報表示欄と、を含む検索画面が表示部１６上に表示される（ステップＳ６０）。
【０１４６】
当該検索画面が表示されると、先ずタイトル入力欄を文字入力可能とし（ステップＳ６１）、その後に入力部２１におけるいずれかのキーの操作又はボタンの操作を待機する（ステップＳ６２）。そして、入力部２１内の図示しない上下キーが操作されたときは（ステップＳ６３；ＹＥＳ）、文字入力可能とする検索画面内の欄を、例えば上記名前入力欄等の他の入力欄に移動させ（ステップＳ６６）、上記ステップＳ６２に戻って次の入力操作を待機する。
【０１４７】
また、上記入力操作が上下キーを用いたものでないときは（ステップＳ６３；ＮＯ）、次に、入力部２１内の図示しない左右キー、文字キー又は削除キー等が操作されたか否かを確認する（ステップＳ６４）。そして、いずれかの文字等の入力が実行されたときは（ステップＳ６４；ＹＥＳ）、その時点で文字入力可能とされている入力欄において、その入力された文字等を用いた検索キーワードの編集処理（より具体的には、検索キーワードの確定処理等）が実行され（ステップＳ６７）、再度上記ステップＳ６２に戻って次の入力操作を待機する。
【０１４８】
他方、ステップＳ６４の判定において、文字キー等の操作が為されていないときは（ステップＳ６４；ＮＯ）、次に検索実行ボタンが操作されたか否かを確認する（ステップＳ６５）。そして、当該検索実行ボタンも操作されていないときは（ステップＳ６５；ＮＯ）、最後に、上記終了ボタンが操作されたか否かを確認し（ステップＳ６８）、当該終了ボタンも操作されていないときは（ステップＳ６８；ＮＯ）、上記ステップＳ６２に戻って更なる入力操作を待機する。
【０１４９】
一方、ステップＳ６８の判定において、終了ボタンが操作されたときは（ステップＳ６８；ＹＥＳ）、上記端末終了指示フラグの値を制御部１１内において「１」に設定し（ステップＳ６９）、上記ステップＳ６２に戻って更なる入力操作を待機する。
【０１５０】
他方、上記ステップＳ６５の判定において上記検索実行ボタンが操作されたときは（ステップＳ６５；ＹＥＳ）、この時点で各入力欄に入力されている検索キーワードでカタログの検索を行うことが確定したことになる。これを用いて、現在記憶部１２内に記憶されているコンテンツ検索のためのカタログの中から、上記確定された検索キーワードに一致するタイトル等を有するコンテンツを抽出し（ステップＳ７０）、その抽出した内容をリスト表示する（ステップＳ７１）。このとき、当該リストは、コンテンツ再生表示画面とは別画面により検索結果一覧表として表示部１６に表示される。
【０１５１】
ステップＳ７１の処理により検索結果一覧表が表示部１６に表示された後は、いずれかのボタン又はキーの操作を待機しつつ（ステップＳ７２）、上記戻るボタンが操作されたか否かを確認する（ステップＳ７４）。そして、当該戻るボタンが操作されたときは（ステップＳ７４；ＹＥＳ）、上記ステップＳ６０に戻って検索画面の新たな表示から処理を繰り返す（ステップＳ６０乃至Ｓ７１）。
【０１５２】
他方、ステップＳ７４の判定において、上記戻るボタンも操作されていないときは（ステップＳ７４；ＮＯ）、最後に、上記視聴ボタンが操作されたか否かを確認する（ステップＳ７５）。そして、当該視聴ボタンも操作されていないは（ステップＳ７５；ＮＯ）、上記ステップＳ７２に戻って次の入力操作を待機し、操作されたときは（ステップＳ７５；ＹＥＳ）、当該視聴対象となっているコンテンツのコンテンツＩＤを制御部１１内に記憶させると共に当該制御部１１内の再生指示フラグを「１」に設定し（ステップＳ７６）、再度上記ステップＳ６２に戻って次の入力操作を待機する。
【０１５３】
（Ｂ）ルートノードとしての動作
次に、実施形態に係るルートノードＲＮ（図４参照）としての動作を、図８を用いて説明する。なお、図８は実施形態に係る主配信システムＳＭ内のルートノードＲＮとしての動作を示すフローチャートであり、当該ルートノードＲＮとして機能するノードＮ内の制御部１１により実行される。また、図８に示すルートノードＲＮとしての処理は、上記図６及び図７を用いて説明した通常のノードＮとしてのメッセージ処理（図６ステップＳ１４参照）等とは全く独立して、例えば一定時間毎に定期的に開始される処理（即ち、例えばタイマー起動による割り込み処理）であり、図８に示す処理自体が終了した時点で元の通常の処理に戻ることになる。
【０１５４】
図８に示すように、実施形態に係るルートノードＲＮとしての動作においては、先ず、そのルートノードＲＮがインデックス情報ＥＸを記憶しているコンテンツを蓄積しているコンテンツホルダＣＨにおける配信要求の集中度（換言すれば、当該ルートノードＲＮ内のインデックスメモリＣＭが、図４に例示するインデックスメモリＣＭ１のような不均衡状態になる可能性）を確認する（ステップＳ２０、Ｓ２１）。
【０１５５】
このステップＳ２０の動作として具体的には、例えば、当該ルートノードＲＮ内の記憶部１２におけるインデックス情報ＥＸの記憶領域の情報量に比べて、特定のコンテンツに対応するインデックス情報ＥＸの数（即ち、当該特定のコンテンツのレプリカの数）が当該記憶領域の大半を占めているか否かや、その特定のコンテンツに相当するコンテンツデータを蓄積しているコンテンツホルダＣＨに対する配信要求数の増加度、或いは当該コンテンツホルダＣＨに対する単位時間当たりの配信要求数等を、予め設定されている閾値との比較により判定する。
【０１５６】
そして、当該配信要求の集中度が高いと判定されるときは（ステップＳ２１；ＹＥＳ）、補助サーバＳＰＭに対して上記援助依頼メッセージＲＭＧを送信済みか否かを確認し（ステップＳ２２）、送信済みでないときは（ステップＳ２２；ＮＯ）、直ちにヘルパーノードＳＮの主配信システムＳＭへの参加を求める援助依頼メッセージＲＭＧを補助サーバＳＰＭに送信して（ステップＳ２３）、ノードＮとしての上記した通常の処理（図６及び図７参照）に戻る。
【０１５７】
なお、当該補助サーバＳＰＭに接続するための情報（より具体的には、例えば当該補助サーバを示すＩＰアドレス又はポート番号）は、例えば、実施形態に係るノードＮの工場出荷時において、記憶部１２を構成するハードディスク内か、或いは制御部１１内の図示しないＲＯＭ（Read Only Memory）に記憶されているものである。
【０１５８】
また、当該援助依頼メッセージＲＭＧの具体的内容としては、少なくとも、当該援助依頼メッセージＲＭＧを送信するルートノードＲＮのＩＰアドレス、当該ルートノードＲＮに対応するノードＩＤ及び当該援助依頼メッセージＲＭＧの対象であるコンテンツ（人気コンテンツ）に対応するコンテンツＩＤが含まれている。なお、援助依頼メッセージＲＭＧとしてはこの他に、ヘルパーノードＳＮを求める緊急度を示す指標等を含ませても良い。
【０１５９】
一方、ステップＳ２２の判定において、援助依頼メッセージＲＭＧを送信済みであるときは（ステップＳ２２；ＹＥＳ）、ノードＮとしての上記した通常の処理（図６及び図７参照）に戻る。
【０１６０】
他方、上記ステップＳ２１の判定において、対象となっているコンテンツに対する配信要求の集中度が高いと判定されないときは（ステップＳ２１；ＮＯ）、上記援助依頼メッセージＲＭＧを補助サーバＳＰＭに対して送信済みか否かを確認し（ステップＳ２５）、送信済みでないときは（ステップＳ２５；ＮＯ）、配信要求の集中度が低いためそもそも当該援助依頼メッセージＲＭＧを送信する必要事態がないことになるため、そのままノードＮとしての上記した通常の処理（図６及び図７参照）に戻る。
【０１６１】
また、上記ステップＳ２５の判定において、援助依頼メッセージＲＭＧが送信済みであるときは（ステップＳ２５；ＹＥＳ）、対象となっているコンテンツに対する配信要求の集中度が高いと判定されない（上記ステップＳ２１；ＮＯ参照）が故にヘルパーノードＳＮが主配信システムＳＭ内に参加している必要がなくなっているので、以降に改めて参加する機会が発生する場合のために当該ヘルパーノードＳＮを主配信システムＳＭから離脱させて元の補助システムＳＰ内に返却すべく、援助解除メッセージをそのルートノードＲＮから補助サーバＳＰＭに送信し（ステップＳ２８）、上記ノードＮとしての上記した通常の処理（図６及び図７参照）に戻る。
【０１６２】
なお、図８には図示していないが、ルートノードＲＮとしてノードＮは、上記援助依頼メッセージＲＭＧ及び援助解除メッセージの発生に対応してヘルパノードＳＮが主配信システムＳＭに参加又は脱退することで、現在対象となっている（人気）コンテンツのルートノードＲＮとしての機能を果たす必要がなくなったり、或いは再びその機能を開始することとなったりすることになる。より具体的には、例えば、上記援助依頼メッセージＲＭＧ及び援助解除メッセージ等のメッセーＭＧの授受に対応してルートノードＳＮとしてのノードＮに記憶されているルーティング情報が更新されることで、ルートノードＲＮとしての機能を果たしたり果たさなくなったりするのである。
【０１６３】
（Ｃ）補助サーバとしての動作
次に、実施形態に係る補助サーバＳＰＭ（図４参照）としての動作を、図９を用いて説明する。なお、図９は実施形態に係る補助システムＳＰ内の補助サーバＳＰＭとしての動作を示すフローチャートであり、当該補助サーバＳＰＭとして機能するノードＮ内の制御部１１により実行される。また、図９に示す補助サーバＳＰＭとしての処理は、その電源がオンとされた以降当該電源がオフとされるまで繰り返し実行される無限ループパターンの処理である。
【０１６４】
図９に示すように、実施形態に係る補助サーバＳＰＭとしての動作においては、先ず、主配信システムＳＭ内の任意のノードＮからのメッセージの受信を待機する（ステップＳ３０）。
【０１６５】
そして、何らかのメッセージを受信したら、その受信したメッセージが、補助サーバＳＰＭにとって有効なメッセージか否か、即ち、上記援助依頼メッセージＲＭＧ又は上記援助解除メッセージのいずれかであるか否かを確認する（ステップＳ３２）。
【０１６６】
受信したメッセージが上記援助依頼メッセージＲＭＧ又は上記援助解除メッセージのいずれでもないときは（ステップＳ３２；ＮＯ）、当該受信したメッセージを無視して、上記ステップＳ３０に戻って待機状態を継続する。
【０１６７】
一方、ステップＳ３２の判定において、受信したメッセージが上記援助依頼メッセージＲＭＧ又は上記援助解除メッセージのいずれかであるときは（ステップＳ３２；ＹＥＳ）、次に、その受信したメッセージが援助依頼メッセージＲＭＧであるか否かを確認する（ステップＳ３３）。
【０１６８】
ステップＳ３３の判定において、受信したメッセージが援助依頼メッセージＲＭＧでないときは（ステップＳ３３；ＮＯ）、受信したメッセージは援助解除メッセージであることになるので、現在主配信システムＳＭに参加しているヘルパーノードＳＮのうち当該援助解除メッセージを送信してきたルートノードＲＮからの上記援助依頼メッセージＲＭＧに対応して主配信システムＳＭに参加させたヘルパーノードＳＮに対して、当該主配信システムＳＭから脱退して補助システムＳＰに戻る旨の脱退指示メッセージを送信し（ステップＳ３４）、その脱退を確認後にヘルパーノードＳＮを管理するために補助サーバＳＰＭ内に記憶されている管理リストを更新して（ステップＳ３５）、その後上述してきた動作を繰り返す。
【０１６９】
ここで、当該管理リストとしては、上記援助解除メッセージに対応して主配信システムＳＭから脱退させるヘルパーノードＳＮを特定すべく、上記援助依頼メッセージＲＭＧに対応して主配信システムＳＭに参加させたヘルパーノードＳＮのＩＰアドレスと、当該援助依頼メッセージＲＭＧを送信してきたルートノードＲＮ（即ち、上記援助解除メッセージを送信してきたノードＮ）のＩＰアドレスと、を対応付けた一覧表（換言すれば、どのルートノードＲＮからの援助依頼メッセージＲＭＧに応答してどのヘルパーノードＳＮを主配信システムＳＭに参加させたかを示す対応表）が、当該管理リストとして補助サーバＳＰＭ内の記憶部１２に記憶されている。
【０１７０】
一方、ステップＳ３３の判定において、受信したメッセージが援助依頼メッセージＲＭＧであるときは（ステップＳ３３；ＹＥＳ）、次に、主配信システムＳＭ内に参加させることが可能なヘルパーノードＳＮが実際にあるか否か（即ち、他の用途に用いられていない空き状態のヘルパーノードＳＮがあるか否か）を確認する（ステップＳ３６）。
【０１７１】
そして、空き状態のヘルパーノードＳＮがないときは（ステップＳ３６；ＮＯ）、当該管理下にあるいずれかのヘルパーノードＳＮが空き状態になるまで待機すべく予め定められた一定時間待機し（ステップＳ３７）、再度ステップＳ３６に戻って空き状態のヘルパーノードＳＮがあるか否かの判定を行うことを繰り返す。
【０１７２】
他方、ステップＳ３６の判定において、空き状態のヘルパーノードＳＮがあるときは（ステップＳ３６；ＹＥＳ）、次に、援助依頼メッセージＲＭＧを送信して来たルートノードＲＮのノードＩＤの値が、援助依頼メッセージＲＭＧを送信して来たルートノードＲＮが管理しているコンテンツを示すコンテンツＩＤの値と等しいか否かを確認する（ステップＳ３８）。
【０１７３】
ここで、ノードＩＤのｂｉｔ長は、一般には１２８ｂｉｔ乃至１６０ｂｉｔと長いので、ルートノードＲＮのノードＩＤとコンテンツＩＤが正確に一致する確率は非常に低い。このため、ヘルパーノードＳＮのノードＩＤをコンテンツＩＤに完全に一致させて、ルートノードＲＮとして参加させることが、ほぼ確実に可能である。しかしながら一方で、当該一致する確率は全くの「０」ではないので、上記ステップＳ３８の処理に係る判定が必要になるのである。
【０１７４】
そして、当該ルートノードＲＮのノードＩＤの値とコンテンツＩＤの値とが等しくないときは（ステップＳ３８；ＮＯ）、空き状態にあるヘルパーノードＳＮのいずれかに対して、その時に援助依頼メッセージＲＭＧの対象となっている（配信要求が集中している）コンテンツを示すコンテンツＩＤの値と同一の値を有するノードＩＤを割り振り、更に当該援助依頼メッセージＲＭＧを送信して来たルートノードＲＮを上記コンタクトノードとして主配信システムＳＭに参加することを指示する参加指示メッセージＣＭＧを送信し（ステップＳ４４）、上記ステップＳ３５の処理に移行する。
【０１７５】
ここで、ステップＳ３８の判定において、当該ルートノードＲＮのノードＩＤの値とコンテンツＩＤの値とが等しいときにおいて、仮に空き状態にあるヘルパーノードＳＮのいずれかに対して、その時に援助依頼メッセージＲＭＧの対象となっている（配信要求が集中している）コンテンツを示すコンテンツＩＤの値と同一の値を有するノードＩＤを割り振った上で主配信システムＳＭに参加させると、一つの配信システム内に同一のノードＩＤのノードが２つ併存することとなる。
【０１７６】
そこで、この事態を回避すべく、ルートノードＲＮのノードＩＤの値とコンテンツＩＤの値とが等しいときは（ステップＳ３８；ＹＥＳ）、現在の当該コンテンツＩＤの値に「１」を加算した値を有するノードＩＤを新たに生成し（ステップＳ３９）、その新たに生成されたノードＩＤと等しいノードＩＤを既に有している他のノードが主配信システムＳＭ内に既に存在しているか否かを確認する（ステップＳ４０、Ｓ４１）。より具体的には、例えば当該新たに生成されたノードＩＤを宛先としてルートノード確認メッセージ（上記ＤＨＴに基づいて転送されるタイプのメッセージ）を主配信システムＳＭ内に送信し、実際に現時点でルートノードＲＮとして機能しているノードＮのノードＩＤの返信を受ける（換言すれば、当該コンテンツＩＤに相当するコンテンツを管理するノードＮがどのノードＮであるかを問い合わせる旨のメッセージを送信してその返答を受ける）。
【０１７７】
そして、新たに生成されたノードＩＤと等しいノードＩＤを既に有している他のノードが主配信システムＳＭ内に既に存在しているときは（ステップＳ４１；ＹＥＳ）、当該新たに生成したノードＩＤの値に更に「１」を加えて新たなノードＩＤを再度生成し（ステップＳ４３）、上記ステップＳ４０に戻って再度同じ判定を行う。
【０１７８】
一方、ステップＳ４１の判定において、新たに生成されたノードＩＤと等しいノードＩＤを既に有している他のノードが主配信システムＳＭ内に存在していないときは（ステップＳ４１；ＮＯ）、当該空き状態にあるヘルパーノードＳＮのいずれかに対して、そのときの値のノードＩＤを割り振り、更に当該援助依頼メッセージＲＭＧを送信して来たルートノードＲＮを上記コンタクトノードとして主配信システムＳＭに参加することを指示する参加指示メッセージＣＭＧを当該空き状態にあるヘルパーノードＳＮに送信し（ステップＳ４２）、上記ステップＳ３５の処理に移行する。
【０１７９】
このように、コンテンツＩＤの値に完全に一致するノードＩＤを持つノードＮが既に存在していた場合は、ヘルパーノードＳＮのノードＩＤを、コンテンツＩＤから少しずらした値にして上で主配信システムＳＭに参加させることで、新たなルートノードＲＮになることはできないが、ルートノードＲＮに限りなく近いノードＩＤを持つノード（準ルートノード）として働かせることができる。この場合、人気コンテンツのインデックス情報の記憶を負担するという効果は若干下がるものの、一般には上記キャッシュノードＣＮとして働くことができるので、ある一定の効果を得ることができる。
【０１８０】
（Ｄ）ヘルパーノードとしての動作
最後に、実施形態に係るヘルパーノードＳＮ（図４参照）としての動作を、図１０を用いて説明する。なお、図１０は実施形態に係る補助システムＳＰ内のヘルパーノードＳＮとしての動作を示すフローチャートであり、当該補助サーバＳＰＭとして機能するノードＮ内の制御部１１により実行される。
【０１８１】
図１０左に示すように、実施形態に係るヘルパーノードＳＮとしての動作においては、先ず、当該ヘルパーノードＳＮとしての起動処理を行い、補助サーバＳＰＭからの参加指示メッセージＣＭＧの待機状態に入る（ステップＳ５０、Ｓ５０Ａ；ＮＯ）。
【０１８２】
そして、当該参加指示メッセージＣＭＧが受信されたときは（ステップＳ５０Ａ；ＹＥＳ）、主配信システムＳＭにそのヘルパーノードＳＮが参加し、ＤＨＴとしてのメッセージ処理を行うためのスレッドを起動し（ステップＳ５１）、当該主配信システムＳＭに参加後は、上述した如く当該参加指示メッセージＣＭＧの対象となっているコンテンツのルートノードＲＮ或いは、ルートノードＲＮに限りなく近いノードＩＤを持つノード（準ルートノード）として機能する。
【０１８３】
次に、当該ヘルパーノードＳＮとして動作中においては、定期的に以下に説明するステップＳ５２乃至Ｓ５６の処理を繰り返す。即ち、当該コンテンツに対する配信要求に対する集中状態の自然解消を待つべく予め設定された一定時間待機している間に（ステップＳ５２）、当該集中状態を確認する（ステップＳ５３、Ｓ５４）。
【０１８４】
ここで、当該ステップＳ５３及びＳ５４の動作として具体的には、上記図８ステップＳ２０の場合と同様に、例えば、当該ヘルパーノードＳＮ内の記憶部１２におけるインデックス情報ＥＸの記憶領域の情報量に比べて、特定のコンテンツに対応するインデックス情報ＥＸの数（即ち、当該特定のコンテンツのレプリカの数）が当該記憶領域の大半を占めているか否かや、その特定のコンテンツに相当するコンテンツデータを蓄積しているコンテンツホルダＣＨに対する配信要求数の増加度、或いは当該コンテンツホルダＣＨに対する単位時間当たりの配信要求数等を、予め設定されている閾値と比較することにより判定することとすればよいが、このステップＳ５３及びＳ５４の判定処理は、上記ステップＳ２０の場合と異なり配信要求の集中状態が解消されているか否かを判定することが目的であるので、当該ステップＳ２０の判定で用いた閾値と異なる閾値を用いてステップＳ５４の場合の判定を行っても良い。
【０１８５】
次に、上記ステップＳ５３及びＳ５４の確認処理において、配信要求の集中度が集中状態であると判定されないときは（ステップＳ５４；ＮＯ）、上記ステップＳ５１として開始した一般のＤＨＴを用いた処理を終了させ（ステップＳ５６）、上記ステップＳ５０の処理に戻って参加指示メッセージＣＭＧの待機状態に入る。
【０１８６】
一方、ステップＳ５３及びＳ５４の確認処理において、当該コンテンツに対する配信要求が依然として集中しているときは（ステップＳ５４；ＹＥＳ）、補助サーバＳＰＭからの上記脱退指示メッセージを受信したか否かを確認する（ステップＳ５５）。そして、当該脱退指示メッセージを受信していないときは（ステップＳ５５；ＮＯ）、上記ステップＳ５２の処理に移行し、引き続き当該コンテンツに対応するルートノードＲＮ或いは準ルートノードとして機能しつつ、上記ステップＳ５２乃至Ｓ５５の処理を繰り返す。
【０１８７】
他方、ステップＳ５５の判定において、脱退指示メッセージを受信したときは（ステップＳ５５；ＹＥＳ）、上記ステップＳ５１として開始したＤＨＴメッセージ処理スレッドを終了させ（ステップＳ５６）、上記ステップＳ５０の処理に戻って参加指示メッセージＣＭＧの待機状態に入る。
【０１８８】
次に、上記ステップＳ５１として開始したＤＨＴメッセージ処理スレッドについて、具体的に図１０右に示すフローチャートを用いて説明する。なお、このフローチャートは、図６に示したフローチャートから、コンテンツ要求・再生等の処理を除いたものに相当する。
【０１８９】
図１０右に示すように、当該ＤＨＴメッセージ処理スレッドにおいては、ステップＳ５０の処理において受信した参加指示メッセージＣＭＧに対応して主配信システムＳＭ内に参加すべく、上記参加要求メッセージを、当該ヘルパーノードＳＮが主配信システムＳＭに参加するに当たっての仲介役となるコンタクトノードに送信し（ステップＳ５７）、その後、当該参加要求メッセージに対する返信メッセージを含むメッセージの待機状態に入る（ステップＳ５８；ＮＯ）。なお、このステップＳ５７の実行に伴い、当該コンタクトノードはその時点で記憶している上記インデックス情報ＥＸ全てを返信メッセージに添付するようにしても良い。ヘルパーノードＳＮは、この情報を元に、自己のインデックス情報ＥＸを構築すると、すみやかにルートノードＲＮとしての機能を発揮することができる。
【０１９０】
そして、当該受信待機中においていずれかのメッセージを受信したときは（ステップＳ５８；ＹＥＳ）、当該受信したメッセージの種類に対応した種々のメッセージ処理を行い（ステップＳ５９（図６ステップＳ１４参照））、その後上記ステップＳ５８に戻ってメッセージ受信の待機状態に入る。
【０１９１】
以上説明したように、実施形態に係る配信システムＳの動作によれば、特定の人気コンテンツに対する配信要求が閾値以上となったとき援助依頼メッセージＲＭＧを補助サーバＳＰＭに出力し、当該援助依頼メッセージＲＭＧに対応してヘルパーノードＳＮを主配信システムＳＭに参加させるので、主配信システムＳＭに属するノードにおいて、当該人気コンテンツに対する配信要求の集中により当該人気コンテンツに対応するインデックス情報ＥＸの数が増大することに起因する他のコンテンツに対応する他のインデックス情報ＥＸの記憶数の低減を防止できる。
【０１９２】
従って、当該他のインデックス情報ＥＸの記憶数が低減することによって当該他のインデックス情報ＥＸに対応する他のコンテンツが配信不能状態となることを防止し、主配信システムＳＭにおける利便性及び配信効率の向上に資することができる。
【０１９３】
更に、単位時間当たりの配信要求の数又はレプリカの数の少なくともいずれか一方に基づいて、人気コンテンツに対する配信要求が閾値以上になったか否かを判定するので、現実の配信要求数又はレプリカの数に基づいて判定することで、効率的に主配信システムＳＭと補助システムＳＰとの間の連携を行うことができる。
【０１９４】
更にまた、人気コンテンツに対する配信要求が所定の閾値未満となったとき、主配信システムＳＭ内に参加しているヘルパーノードＳＮを主配信システムＳＭから離脱させるので、人気コンテンツの配信状況が改善されたときはヘルパーノードＳＮを主配信システムＳＭから離脱させることで、元の主配信システムＳＭの状態に復帰させることができると共に、以後の配信状況の悪化に備えて補助システムＳＰを待機させることができる。
【０１９５】
また、ヘルパーノードＳＮのノードＩＤの値を人気コンテンツに対応するコンテンツＩＤの値に相当する値に設定して主配信システムＳＭ内に参加させ、当該主配信システムＳＭ内における当該人気コンテンツの配信の制御に供させるので、当該参加させたヘルパーノードＳＮを確実に人気コンテンツの配信制御に供させることができる。
【０１９６】
更に、ルートノードＲＮのノードＩＤの値が、人気コンテンツに対応するコンテンツＩＤの値に相当する値であるとき、ヘルパーノードＳＮを識別するためのノードＩＤの値を人気コンテンツに対応するコンテンツＩＤの値に関連する値に設定して主配信システムＳＭ内に参加させるので、主配信システムＳＭにおけるコンテンツの配信に与える影響を与えることなくヘルパーノードＳＮを主配信システムＳＭに参加させることができる。
【０１９７】
また、人気コンテンツに対応するコンテンツＩＤの値に関連する値が、人気コンテンツに対応するコンテンツＩＤの値に対して直近に大きい値であるので、より迅速且つスムーズにヘルパーノードＳＮを主配信システムＳＭに参加させることができる。
【０１９８】
更に、主配信システムＳＭ内に参加しているヘルパーノードＳＮをその主配信システムＳＭから離脱させるとき、当該ヘルパーノードＳＮに対して主配信システムＳＭから脱退する旨の脱退指示メッセージを送信するので、主配信システムＳＭに参加していたヘルパーノードＳＮを迅速に補助サーバＳＰＭの管理下に戻すことができる。
【０１９９】
更にまた、ヘルパーノードＳＮにおけるインデックス情報ＥＸの記憶可能数が、主配信システムＳＭ内のノードにおけるインデックス情報ＥＸの記憶可能数の少なくとも二倍であるので、主配信システムＳＭにおける人気コンテンツの配信状態の改善のために十分な機能を持ったヘルパーノードＳＮを当該主配信システムＳＭに参加させることができる。
【０２００】
また、主配信システムＳＭに参加する際、主配信システムＳＭ内のルートノードＲＮからルーティング情報を取得し、その取得したルーティング情報をヘルパーノードＳＮ内に記憶させて人気コンテンツの配信に供させるので、簡易且つ迅速な処理でヘルパーノードＳＮを主配信システムＳＭに参加させ、直ちに人気コンテンツの配信に供させることができる。
【０２０１】
なお、上述した実施形態では、主配信システムＳＭへヘルパーノードＳＮを参加させる際のノードＩＤを、既に存在しているコンテンツＩＤ又はノードＩＤとの関係で「１」ずつ増大させつつ設定した（図９ステップＳ３９、Ｓ４３参照）が、これ以外に、「１」ずつ減少させるようにして設定してもよい。この構成によっても、上記実施形態と同様の作用効果を奏することができる。
【０２０２】
また、上述した実施形態では、主配信システムＳＭ内にキャッシュノードＣＮが存在しない場合について説明したが、実施形態におけるルートノードＲＮの機能のうち本発明に係る部分は、そのままキャッシュノードＣＮに適用することも可能である。
【０２０３】
更に、上述した図８乃至図１０に示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係るルートノードＲＮ、補助サーバＳＰＭ及びヘルパーノードＳＮ内の制御部１１として夫々機能させることも可能である。
【産業上の利用可能性】
【０２０４】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【０２０５】
【図１】実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である
【図２】実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】実施形態に係る配信システムの概要を示す模式図（III）である。
【図４】本発明の原理を説明する図である。
【図５】実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図６】実施形態に係るノードにおける共通動作の全体を示すフローチャートである。
【図７】実施形態に係るノードにおける共通動作の細部を示すフローチャートである。
【図８】実施形態に係るルートノードにおける動作を示すフローチャートである。
【図９】実施形態に係る補助サーバにおける動作を示すフローチャートである。
【図１０】実施形態に係るヘルパーノードおける動作を示すフローチャートである。
【符号の説明】
【０２０６】
１１    制御部
１２    記憶部
１３    バッファメモリ
１４    デコーダ部
１５    映像処理部
１６    表示部
１７    音声処理部
１８    スピーカ
２０    通信部
２１    入力部
２２    バス
Ｒc、Ｒn    リング
ＥＸ    インデックス情報
ＣＨ    コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３    リクエスタ
ＲＮ    ルートノード
ＣＮ    キャッシュノード
ＰＵＢmsg    公開メッセージ
ＱＲmsg    配信元問い合わせメッセージ
Ｎ    ノード
ＲＴ    返信情報
ＳＭ    主配信システム
ＣＭ１、ＣＭ２    インデックスメモリ
ＳＰ    補助システム
Ｓ    配信システム
ＳＰＭ    補助サーバ
ＳＮ    ヘルパーノード
ＲＭＧ    援助依頼メッセージ
ＣＭＧ    参加指示メッセージ
【図１】
0004735371.tif 000002
【図２】
0004735371.tif 000003
【図３】
0004735371.tif 000004
【図４】
0004735371.tif 000005
【図５】
0004735371.tif 000006
【図６】
0004735371.tif 000007
【図７】
0004735371.tif 000008
【図８】
0004735371.tif 000009
【図９】
0004735371.tif 000010
【図１０】
0004735371.tif 000011