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