(57)【特許請求の範囲】
【請求項１】
複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置である蓄積装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する配信システムにおいて、
前記蓄積装置に蓄積される前記配信情報の夫々には、一の当該配信情報を他の当該配信情報から識別するための連続識別情報であって前記配信情報毎に値の大小関係が連続している連続識別情報と、当該配信情報を前記配信システム内において検索するための検索情報と、が、前記配信情報を配信する配信サーバ装置において予め付加されており、
前記蓄積装置は、
対応する前記連続識別情報が設定された新たな前記配信情報が、対応する前記検索情報と共に前記蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する前記検索情報及び前記連続識別情報を含む公開メッセージを前記ネットワークを介して各前記ノード装置に送信する送信手段を備え、
各前記ノード装置は、
前記検索情報と前記連続識別情報とを対応付けて記憶する記憶手段と、
各種情報を表示する表示手段と、
前記公開メッセージが前記ネットワークを介して送信されて来たとき、当該ノード装置において当該公開メッセージに含まれている前記連続識別情報を受信し、当該受信した連続識別情報と前記記憶手段内に記憶されている前記連続識別情報との間における連続性を、前記連続識別情報の値の大小関係を比較して確認する確認手段と、
前記連続性があることが確認されたとき、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記送信されて来た公開メッセージに含まれている前記検索情報及び前記連続識別情報を用いて更新する更新手段と、
前記更新手段によって前記検索情報が更新されたタイミングで更新後の当該検索情報を前記表示手段に表示する告知手段と、
を備えることを特徴とする配信システム。
【請求項２】
請求項１に記載の配信システムに含まれる蓄積装置であって、
前記配信手段を備えることを特徴とする蓄積装置。
【請求項３】
請求項２に記載の蓄積装置において、
前記確認手段は、前記新たに蓄積される配信情報に対応する前記連続識別情報と当該蓄積装置内の前記記憶手段に記憶されている前記連続識別情報との間における連続性を確認し、
前記更新手段は、前記連続性のあることが確認されたとき、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記新たに蓄積される配信情報に対応する前記検索情報及び前記連続識別情報を用いて更新することを特徴とする蓄積装置。
【請求項４】
請求項１に記載の配信システムに含まれるノード装置であって、
前記記憶手段と、
前記表示手段と、
前記確認手段と、
前記更新手段と、
前記告知手段と、
を備えることを特徴とするノード装置。
【請求項５】
請求項４に記載のノード装置において、
前記連続性がないことが確認されたとき、他の前記ノード装置内の前記記憶手段に記憶されている前記検索情報のうち前記連続性の中断部分に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報を取得するための取得メッセージを、他の前記ノード装置に向けて前記ネットワークを介して送信する取得メッセージ送信手段を更に備え、
前記更新手段は、前記送信された取得メッセージに対応して前記中断部分に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報が前記ネットワークを介して返信されて来たとき、当該返信されて来た連続識別情報及び検索情報を用いて前記記憶手段内の前記連続性識別情報及び前記検索情報を更新することを特徴とするノード装置。
【請求項６】
請求項４又は請求項５に記載のノード装置において、
前記検索情報内には、当該検索情報が対応する前記配信情報が前記配信システム内の各前記ノード装置に配信されるべき当該配信情報であるか否かを示す配信許可フラグが含まれており、
前記告知手段は、前記配信許可フラグにより前記配信システム内の各前記ノード装置に配信されるべき前記配信情報であることが示されている前記検索情報のみを前記表示手段に表示することを特徴とするノード装置。
【請求項７】
請求項６に記載のノード装置において、
前記配信許可フラグにより前記配信システム内の各前記ノード装置に配信されるべき前記配信情報でないことが示されている前記検索情報を前記記憶手段から削除する削除手段を更に備えたことを特徴とするノード装置。
【請求項８】
請求項４から請求項７のいずれか一項に記載のノード装置において、
他の前記ノード装置に対して送信すべきいずれかのメッセージを送信する際に、前記記憶手段に記憶されている前記連続識別情報のうち最も新しい当該連続識別情報である最新連続識別情報を当該メッセージに付加する付加手段と、
前記最新連続識別情報が付加された前記メッセージを、前記他のノード装置に対して送信するメッセージ送信手段と、
を備えることを特徴とするノード装置。
【請求項９】
請求項８に記載のノード装置からの前記メッセージを受信する請求項４から請求項７のいずれか一項に記載のノード装置において、
前記確認手段は、当該メッセージを前記ネットワークを介して取得したとき、当該取得したメッセージに含まれている前記最新連続識別情報と、前記記憶手段に記憶されている前記連続識別情報と、の間の前記連続性を、前記連続識別情報の値の大小関係を比較して確認し、
更に当該連続性がないことが確認されたとき、当該連続性が中断している範囲に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報を、前記配信システム内の他の前記ノード装置から取得する取得手段を備えることを特徴とするノード装置。
【請求項１０】
請求項４から請求項９のいずれか一項に記載のノード装置において、
前記確認手段は、前記送信されて来た連続識別情報と前記記憶手段内に記憶されている前記連続識別情報とが等しいか否かを確認すると共に、
前記送信されて来た連続識別情報と前記記憶されている連続識別情報とが等しいことが確認されたとき、前記記憶されている連続識別情報を用いて新たなメッセージを生成するメッセージ生成手段を更に備えることを特徴とするノード装置。
【請求項１１】
コンピュータを、請求項２又は請求項３に記載の蓄積装置として機能させることを特徴とする蓄積装置用プログラム。
【請求項１２】
コンピュータを、請求項４から請求項１０のいずれか一項に記載のノード装置として機能させることを特徴とするノード装置用プログラム。
【請求項１３】
複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置である蓄積装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する配信システムにおいて実行される配信システム制御方法において、
各前記ノード装置は、前記検索情報と前記連続識別情報とを対応付けて記憶する記憶手段と、各種情報を表示する表示手段と、を備え、
前記蓄積装置に蓄積される前記配信情報の夫々には、一の当該配信情報を他の当該配信情報から識別するための連続識別情報であって前記配信情報毎に値の大小関係が連続している連続識別情報と、当該配信情報を前記配信システム内において検索するための検索情報と、が、前記配信情報を配信する配信サーバ装置において予め付加されており、
対応する前記連続識別情報が設定された新たな前記配信情報が、対応する前記検索情報と共に前記蓄積装置内に蓄積されたとき、当該蓄積装置において、当該新たな配信情報に対応する前記検索情報及び前記連続識別情報を含む公開メッセージを前記ネットワークを介して各前記ノード装置に送信する送信工程と、
各前記ノード装置において前記ネットワークを介して前記公開メッセージを取得したとき、当該各ノード装置において、当該公開メッセージに含まれている前記連続識別情報と前記記憶手段内に記憶されている前記連続識別情報との間における連続性を、前記連続識別情報の値の大小関係を比較して確認する確認工程と、
前記連続性があることが各前記ノード装置において確認されたとき、当該各ノード装置において、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記取得した公開メッセージに含まれている前記検索情報及び前記連続識別情報を用いて更新する更新工程と、
各前記ノード装置において、前記更新工程において前記検索情報が更新されたタイミングで更新後の当該検索情報を前記表示手段に表示する告知工程と、
を含むことを特徴とする配信システム制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、配信システム及び配信システム制御方法、蓄積装置及び蓄積装置用プログラム並びにノード装置及びノード装置用プログラムの技術分野に属し、より詳細には、インターネット等のネットワークを介して映画等のコンテンツ（配信情報）を配信する配信システム及び配信システム制御方法、当該配信システムに含まれる蓄積装置及び蓄積装置用プログラム並びにノード装置及びノード装置用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワークを介して上記コンテンツを蓄積しているサーバ等に端末装置からアクセスし、その端末装置において視聴が所望されているコンテンツを当該端末装置に配信して視聴する、いわゆるコンテンツ配信についての研究開発が盛んである。
【０００３】
ここで、従来の上記コンテンツ配信を行う配信システムの基本的構成は、例えば下記特許文献１に例示されるように、コンテンツの配信を所望する端末装置から上記ネットワークを介してそのコンテンツを蓄積するサーバ等に接続し、その接続を確立した上で所望するコンテンツの配信、即ち当該コンテンツに相当するコンテンツデータの伝送をその端末装置において受ける構成となっている。
【０００４】
一方、近年では、上記コンテンツ配信を行う配信システムの他の構成として、いわゆるＰ２Ｐ（Peer to Peer）グリッド型の配信システム（以下、単に配信システムと称する）がある。ここで、当該配信システムとは、上記ネットワークを用いて上記コンテンツの配信を行う配信システムであって、当該ネットワークに属する端末装置間で、当該コンテンツに相当するコンテンツデータが相互に直接授受される（換言すれば、コンテンツを複数の端末装置間で共有する）配信システムであり、その配信システムに加入している全ての端末装置が、上記サーバとしての機能を有すると共に上記コンテンツの配信を受ける配信先装置としての機能をも備える配信システムである（なお、以下の説明では当該端末装置を単にノードと称する）。
【０００５】
そして、当該配信システムにおいては、あるノードにおいてコンテンツの配信を受けようとする場合、そのノードにおいては、配信を所望するコンテンツに相当するコンテンツデータを蓄積している他のノードを上記ネットワーク上において識別するためのノード識別情報と、そのコンテンツを他のコンテンツから識別するためのコンテンツ識別情報と、を対とした情報（以下、当該情報をインデックス情報と称する）を参照し、このインデックス情報内のノード識別情報により示されるノードから所望のコンテンツの配信を受ける必要がある。
【０００６】
そこで、一般の配信システムにおいては、例えば下記特許文献２に例示されるように、一又は複数のコンテンツに関する上記インデックス情報を、纏めて複数のノード内に夫々記憶（分散記憶）させ、これをそのコンテンツの配信を受けるノードから参照する構成とされている。より具体的には、例えば当該配信システムを構成するネットワークがインターネットである場合には、配信が所望されるコンテンツを特定できる検索情報（例えば映画のタイトル名）とそれを記憶しているノードのＩＰ（Internet Protocol）アドレスとの組を認識し、そのＩＰアドレスを手掛かりとして所望するコンテンツの授受を行う必要がある。
【０００７】
従って、上記配信システムの如き不特定多数のノードがコンテンツを共有し合うような配信システムにおいては、全てのコンテンツの検索情報とそれを記憶しているノードのＩＰアドレスとの組を各ノードが認識しておくことが必要となる。
【０００８】
しかしながら、ネットワークに接続されているノードの数が多くなった場合、各ノードにおける物理的な記録可能量の制限等が理由となって、全てのコンテンツの検索情報とそのコンテンツを記憶しているノードのＩＰアドレスを各ノードが夫々に記録しておくことは現実的ではない（例えば、ネットワークに百万台のノードが接続されている場合、その百万台分のＩＰアドレスを各ノードが互いに全て記録しておくことは全く現実的ではない）。
【０００９】
また、各ノードが全てのコンテンツの検索情報とそれを記憶するノードのＩＰアドレスを記録しておく場合、ネットワーク内の各ノードにおける電源スイッチのオン／オフが頻繁な場合（例えば当該ノードをパーソナルコンピュータにより実現する場合は頻繁に電源スイッチが操作され得ることになる）にも、各ノードに記録されたＩＰアドレス等の更新が頻繁になり、現実的にはネットワーク全体としての運用が困難となる。
【００１０】
そこで、上述したような問題点に対処すべく、必要最低限のノードのＩＰアドレスを含むインデックス情報のみを記録し、そのＩＰアドレスを認識していない他のノードに対しては、そのノードに配信すべきコンテンツを他のノードを介して転送して届けるという仕組みの配信システムが研究されており、その一つに、いわゆるＤＨＴ（Distributed Hash Table；離散ハッシュテーブル）を用いた配信システムがある。
【００１１】
次に、当該ＤＨＴを用いた配信システムについて、概要を説明する。
【００１２】
上記ＤＨＴを用いた配信システムでは、各ノードを相互に識別するためのノードＩＤ（Identification）を当該各ノードに付与する。このとき、当該ノードＩＤは、それらが参加している配信システム内において各ノード毎にユニークな、即ち他のノードとは異なる番号を付与する。この番号は、そのネットワークにおけるノードの最大運用台数を収容できるだけのビット数（ビット長）を有するものとなる。より具体的には、例えば１２８ビットのノードＩＤを用いれば、最大で、２１２８≒３４０×１０３６台のノードを一つのネットワーク内に接続することができる。そして、当該ノードＩＤとして一般的には、ノード自体に付与されているＩＰアドレスやいわゆるＭＡＣ（Media Access Control）アドレス、或いはノード自体の製造番号等の、当該ノード毎に固有の値に対してハッシュ関数を適用して得られる値を用いる。
【００１３】
次に、上記ＤＨＴを用いた配信システムでは、その配信システムによって配信されるコンテンツ自体にも、それに対応する上記コンテンツ識別情報として、他のコンテンツとは異なるユニークなコンテンツＩＤを付与する。このコンテンツＩＤのビット長も上記ノードＩＤのビット長と同一とされる。そして、当該コンテンツＩＤとして一般的には、そのコンテンツのタイトルを示すタイトルデータ、コンテンツを構成するデータの属性を示す属性データ、コンテンツを構成するデータのうち先頭から数バイト分のデータ等に対してハッシュ関数を適用して得られる値を用いる。
【００１４】
しかしながら、上記ＤＨＴを用いた配信システムの弱点として、コンテンツＩＤが上記タイトルデータから算出された場合において、当該コンテンツを配信システム内において発見しようとする際に、当該コンテンツの正確なタイトルが予め判っていなければ当該コンテンツＩＤが算出できず、当該発見のための問い合わせ自体が失敗に終わってしまうということが挙げられる。
【００１５】
より具体的に例えば、「セイドンアドベンチャー」なるタイトルのコンテンツを取得したいと思ったときに、実際に配信されている当該コンテンツのタイトルが「セイドン・アドベンチャー」や「セイドンアドベンチャ」であると、これを発見できないことになる。これは、上述したコンテンツＩＤの算出方法では、タイトル自体は微妙な違いであっても当該異なるタイトルから算出されるコンテンツＩＤは全く異なることになるからである。つまり、所望するコンテンツの配信を使用者があるその操作するノードにおいて受けようとする場合、対応するコンテンツデータの配信を実際に受ける前に、そもそもその使用者が所望するコンテンツがどのようなタイトルで配信可能となっているか否かを検索・確認する必要がある。
【００１６】
そして、この問題に対処するには、当該配信システム内において実際に配信可能な（又は実際に配信されている）コンテンツの一覧を記載した検索用のカタログを、そのコンテンツの視聴装置となり得る全てのノード内に記憶させると良い。これにより、これを視聴するユーザは、このカタログを見ながら、何を視聴したいかを決めるのである。なおこのカタログには、対応するコンテンツのタイトルのみでなく、その監督名、出演している俳優名又は歌手名等の補助情報が記載されていても良い。この補助情報が多ければ多いほど、例えば、「「ジェームズメロン」監督の「カプリオ」主演の映画は配信されているか?」、といった複雑な検索が可能になる。更に言えば、各ノード間において公平性を担保する意味でも、全てのノードに同一且つ最新のカタログが記憶されていることが望ましい。
【００１７】
このために、従来の配信システムにおいては、例えば、当該配信システム内において配信可能な全コンテンツに夫々対応する最新の上記カタログを維持するための専用のカタログ配信サーバを設け、例えば毎週土曜日の午前０時に全てのノードがサーバにアクセスして、翌週公開される予定の新規コンテンツに対応するカタログレコードを含む新カタログをサーバから受信して、当該配信システム内の全端末装置内に記憶されているカタログを更新するという構成が考えられる。
【特許文献１】特開２０００−１２２９５４号公報
【特許文献２】特開２００４−２６５２７３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１８】
しかしながら、上述したカタログ配信サーバを用いた一元的なカタログの更新方法によると、当該更新タイミングである毎週土曜日の午前０時になると、当該カタログ配信サーバにおける処理負荷が急増することとなり、配信システム内に存在する端末装置の数が膨大になればなるほど、当該処理負荷は極端に増加することとなる。
【００１９】
そして、これに対応するためには、当該カタログ配信サーバを取り巻くネットワーク環境を含めて、当該処理負荷の増加に備えてカタログ配信サーバの装置としての規模を大きくしたり、或いはネットワーク用の回線を転送速度の大きいものに換装するなど、高価且つ規模の大きいカタログ配信サーバを設ける必要があり、更にその維持コストも増大するという問題点があった。
【００２０】
そこで、本発明は上記の各問題点に鑑みて為されたもので、その課題は、配信システムとしての維持管理等について不要なコスト及び労力を要することなく各端末装置におけるカタログデータを常に最新の状態に維持できることが可能な配信システム及び配信システム制御方法、当該配信システムに含まれる蓄積装置及び蓄積装置用プログラム並びにノード装置及びノード装置用プログラムを提供することにある。
【課題を解決するための手段】
【００２１】
上記の課題を解決するために、請求項１に記載の発明は、複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置であるコンテンツホルダ等の蓄積装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する配信システムにおいて、前記蓄積装置に蓄積される前記配信情報の夫々には、一の当該配信情報を他の当該配信情報から識別するためのシリアル番号等の連続識別情報であって前記配信情報毎に値の大小関係が連続している連続識別情報と、当該配信情報を前記配信システム内において検索するためのカタログデータ等の検索情報と、が、前記配信情報を配信する配信サーバ装置において予め付加されており、前記蓄積装置は、対応する前記連続識別情報が設定された新たな前記配信情報が、対応する前記検索情報と共に前記蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する前記検索情報及び前記連続識別情報を含む公開メッセージを前記ネットワークを介して各前記ノード装置に送信する制御部等の送信手段を備え、各前記ノード装置は、前記検索情報と前記連続識別情報とを対応付けて記憶する記憶部等の記憶手段と、各種情報を表示する表示部等の表示手段と、前記公開メッセージが前記ネットワークを介して送信されて来たとき、当該ノード装置において当該公開メッセージに含まれている前記連続識別情報を受信し、当該受信した連続識別情報と前記記憶手段内に記憶されている前記連続識別情報との間における連続性を、前記連続識別情報の値の大小関係を比較して確認する制御部等の確認手段と、前記連続性があることが確認されたとき、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記送信されて来た公開メッセージに含まれている前記検索情報及び前記連続識別情報を用いて更新する制御部等の更新手段と、前記更新手段によって前記検索情報が更新されたタイミングで更新後の当該検索情報を前記表示手段に表示する制御部等の告知手段と、を備える。
【００２２】
よって、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を手掛かりに各ノード装置の検索情報が更新され、その更新のタイミングで更新後の検索情報が表示手段に表示されるので、配信システム内における検索情報を常に最新の状態に維持して、使用者による配信情報の選択に直ちに供させることができる。
【００２３】
また、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００２４】
上記の課題を解決するために、請求項２に記載の発明は、請求項１に記載の配信システムに含まれる蓄積装置であって、前記配信手段を備える。
【００２５】
よって、新たな配信情報が当該蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する検索情報及び連続識別情報を含む公開メッセージをネットワークを介して各ノード装置に配信するので、当該各ノード装置において、連続識別情報の連続性を手掛かりに検索情報を更新し、その更新のタイミングで更新後の検索情報が表示手段に表示することで、配信システム内における検索情報を常に最新の状態に維持して配信情報の配信に直ちに供させることができる。
【００２６】
また、結果的に、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００２７】
上記の課題を解決するために、請求項３に記載の発明は、請求項２に記載の蓄積装置において、前記確認手段は、前記新たに蓄積される配信情報に対応する前記連続識別情報と当該蓄積装置内の前記記憶手段に記憶されている前記連続識別情報との間における連続性を確認し、前記更新手段は、前記連続性のあることが確認されたとき、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記新たに蓄積される配信情報に対応する前記検索情報及び前記連続識別情報を用いて更新するように構成される。
【００２８】
よって、新たに蓄積される配信情報に対応する連続識別情報との関係で既存の配信情報に対応する連続識別情報との間に連続性が認められるとき、当該蓄積装置内に記憶されている連続識別情報を、新たに蓄積される配信情報に対応する連続識別情報を用いて更新するので、蓄積装置に対して新たな配信情報が蓄積されたとき、迅速且つ自律的に当該蓄積装置内に記憶されている検索情報を更新することができる。
【００２９】
上記の課題を解決するために、請求項４に記載の発明は、請求項１に記載の配信システムに含まれるノード装置であって、前記記憶手段と、前記表示手段と、前記確認手段と、前記更新手段と、前記告知手段と、を備える。
【００３０】
よって、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を確認して各ノード装置の検索情報が更新され、更に当該更新されたタイミングで更新後の検索情報が使用者に対して告知されるので、配信システム内における検索情報を常に最新の状態に維持して直ちに告知することにより、使用者は配信情報の検索を最新の検索情報を用いて実行することができる。
【００３１】
また、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００３４】
上記の課題を解決するために、請求項５に記載の発明は、請求項４に記載のノード装置において、前記連続性がないことが確認されたとき、他の前記ノード装置内の前記記憶手段に記憶されている前記検索情報のうち前記連続性の中断部分に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報を取得するための取得メッセージを、他の前記ノード装置に向けて前記ネットワークを介して送信する制御部等の取得メッセージ送信手段を更に備え、前記更新手段は、前記送信された取得メッセージに対応して前記中断部分に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報が前記ネットワークを介して返信されて来たとき、当該返信されて来た連続識別情報及び検索情報を用いて前記記憶手段内の前記連続性識別情報及び前記検索情報を更新するように構成される。
【００３５】
よって、他のノード装置から送信されて来た検索情報に対応する連続識別情報との連続性が確認されないとき、その連続性の中断部分に対応する検索情報及び連続識別情報を、取得メッセージに対応して送信されて来た検索情報及び連続識別情報を用いて埋め合わせるので、各ノード装置において、自律的に検索情報の連続性を維持させることができる。
【００３６】
上記の課題を解決するために、請求項６に記載の発明は、請求項４又は請求項５に記載のノード装置において、前記検索情報内には、当該検索情報が対応する前記配信情報が前記配信システム内の各前記ノード装置に配信されるべき当該配信情報であるか否かを示す配信許可フラグが含まれており、前記告知手段は、前記配信許可フラグにより前記配信システム内の各前記ノード装置に配信されるべき前記配信情報であることが示されている前記検索情報のみを前記表示手段に表示するように構成される。
【００３７】
よって、検索情報内に含まれている公開メッセージにより配信されるべきとされている配信情報に対応する検索情報のみが表示手段に表示されるので、その時点で配信を受けることが可能な配信情報のみが検索対象となることで、システム管理者側の都合による配信の許可・不許可の変更を、全てのノード装置に効率的に適用できる。
【００３８】
上記の課題を解決するために、請求項７に記載の発明は、請求項６に記載のノード装置において、前記配信許可フラグにより前記配信システム内の各前記ノード装置に配信されるべき前記配信情報でないことが示されている前記検索情報を前記記憶手段から削除する制御部等の削除手段を更に備える。
【００３９】
よって、配信許可フラグにより配信されるべきものではないとされている配信情報に対応する検索情報が記憶手段から削除されるので、配信不可能な配信情報についての検索情報が誤って告知されることを防止しつつ、効率的に配信情報の検索を行うことができる。
【００４０】
上記の課題を解決するために、請求項８に記載の発明は、請求項４から請求項７のいずれか一項に記載のノード装置において、他の前記ノード装置に対して送信すべきいずれかのメッセージを送信する際に、前記記憶手段に記憶されている前記連続識別情報のうち最も新しい当該連続識別情報である最新連続識別情報を当該メッセージ付加する制御部等の付加手段と、前記最新連続識別情報が付加された前記メッセージを、前記他のノード装置に対して送信する制御部等のメッセージ送信手段と、を備える。
【００４１】
よって、他のノード装置に対してメッセージを送信する際に、記憶手段に記憶されている最新連続識別情報を付加して送信するので、当該最新連続識別情報を取得した当該他のノード装置において、いずれかのメッセージを取得する度に当該他のノード装置内に記憶されている検索情報を更新することで、当該検索情報を自律的に最新の状態に維持することができる。
【００４２】
上記の課題を解決するために、請求項９に記載の発明は、請求項８に記載のノード装置からの前記メッセージを受信する請求項４から８のいずれか一項に記載のノード装置において、前記確認手段は、当該メッセージを前記ネットワークを介して取得したとき、当該取得したメッセージに含まれている前記最新連続識別情報と、前記記憶手段に記憶されている前記連続識別情報と、の間の前記連続性を、前記連続識別情報の値の大小関係を比較して確認し、更に当該連続性がないことが確認されたとき、当該連続性が中断している範囲に相当する前記連続識別情報及び当該連続識別情報に対応する前記検索情報を、前記配信システム内の他の前記ノード装置から取得する取得手段を備える。
【００４３】
よって、いずれかのメッセージを取得したとき、それに含まれている最新連続識別情報との関係で自己の記憶手段内に記憶されている検索情報が最新のものであるか否かを判定し、最新のものでない場合は当該最新の検索情報を他のノード装置から取得するので、いずれかのメッセージを取得する度に連続識別情報を更新することで、当該連続識別情報を自律的に最新の状態に維持することができる。
【００４４】
上記の課題を解決するために、請求項１０に記載の発明は、請求項４から請求項９のいずれか一項に記載のノード装置において、前記確認手段は、前記送信されて来た連続識別情報と前記記憶手段内に記憶されている前記連続識別情報とが等しいか否かを確認すると共に、前記送信されて来た連続識別情報と前記記憶されている連続識別情報とが等しいことが確認されたとき、前記記憶されている連続識別情報を用いて新たなメッセージを生成する制御部等のメッセージ生成手段を更に備える。
【００４５】
よって、送信されて来た連続識別情報と記憶されている連続識別情報とが等しいことが確認されたとき、当該記憶されている連続識別情報を用いて新たなメッセージを生成するので、配信システム内の連続識別情報の更新状態を最新に保つことができる。
【００４６】
上記の課題を解決するために、請求項１１に記載の発明は、コンピュータを、請求項２又は請求項３に記載の蓄積装置として機能させる。
【００４７】
よって、当該コンピュータを請求項２に記載の蓄積装置として機能させる場合には、新たな配信情報が当該蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する検索情報及び連続識別情報を含む公開メッセージをネットワークを介して各ノード装置に配信するように当該コンピュータが機能するので、当該各ノード装置において、連続識別情報の連続性を手掛かりに検索情報を更新し、その更新のタイミングで更新後の検索情報が表示手段に表示することで、配信システム内における検索情報を常に最新の状態に維持して配信情報の配信に供させることができる。
【００４８】
また、結果的に、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００４９】
更に、当該コンピュータを請求項３に記載の蓄積装置として機能させる場合は、当該コンピュータを請求項２に記載の蓄積装置として機能させる場合に加えて、新たに蓄積される配信情報に対応する連続識別情報との関係で既存の配信情報に対応する連続識別情報との間に連続性が認められるとき、当該蓄積装置内に記憶されている連続識別情報を、新たに蓄積される配信情報に対応する連続識別情報を用いて更新するように当該コンピュータが機能するので、蓄積装置に対して新たな配信情報が蓄積されたとき、迅速且つ自律的に当該蓄積装置内に記憶されている検索情報を更新することができる。
【００５０】
上記の課題を解決するために、請求項１２に記載の発明は、コンピュータを、請求項４から請求項１０のいずれか一項に記載のノード装置として機能させる。
【００５１】
よって、当該コンピュータを請求項４に記載のノード装置として機能させる場合には、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を確認して各ノード装置の検索情報が更新され、更に当該更新されたタイミングで更新後の検索情報が使用者に対して告知されるように当該コンピュータが機能するので、配信システム内における検索情報を常に最新の状態に維持して直ちに告知することにより、配信情報の配信を最新の検索情報を用いて実行することができる。
【００５２】
また、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００５４】
更にまた、当該コンピュータを請求項５に記載のノード装置として機能させる場合は、当該コンピュータを請求項４に記載のノード装置として機能させる場合に加えて、他のノード装置から送信されて来た検索情報に対応する連続識別情報との連続性が確認されないとき、その連続性の中断部分に対応する検索情報及び連続識別情報を、取得メッセージに対応して送信されて来た検索情報及び連続識別情報を用いて埋め合わせるように当該コンピュータが機能するので、各ノード装置において、自律的に検索情報の連続性を維持させることができる。
【００５５】
また、当該コンピュータを請求項６に記載のノード装置として機能させる場合は、当該コンピュータを請求項４又は請求項５に記載のノード装置として機能させる場合に加えて、検索情報内に含まれている公開メッセージにより配信されるべきとされている配信情報に対応する検索情報のみが表示手段に表示されるように当該コンピュータが機能するので、その時点で配信を受けることが可能な配信情報のみが検索対象となることで、無駄なく効率的に配信情報の検索を行うことができる。
【００５６】
更に、当該コンピュータを請求項７に記載のノード装置として機能させる場合は、当該コンピュータを請求項６に記載のノード装置として機能させる場合に加えて、配信許可フラグにより配信されるべきものではないとされている配信情報に対応する検索情報が記憶手段から削除されるように当該コンピュータが機能するので、配信不可能な配信情報についての検索情報が誤って告知されることを防止しつつ、効率的に配信情報の検索を行うことができる。
【００５７】
更にまた、当該コンピュータを請求項８に記載のノード装置として機能させる場合は、当該コンピュータを請求項４から請求項７のいずれか一項に記載のノード装置として機能させる場合に加えて、他のノード装置に対してメッセージを送信する際に、記憶手段に記憶されている最新連続識別情報を付加して送信するので、当該最新連続識別情報を取得した当該他のノード装置において、いずれかのメッセージを取得する度に当該他のノード装置内に記憶されている検索情報を更新することで、当該検索情報を自律的に最新の状態に維持することができる。
【００５８】
また、当該コンピュータを請求項９に記載のノード装置として機能させる場合は、当該コンピュータを請求項４から請求項７のいずれか一項に記載のノード装置として機能させる場合に加えて、いずれかのメッセージを取得したとき、それに含まれている最新連続識別情報との関係で自己の記憶手段内に記憶されている検索情報が最新のものであるか否かを判定し、最新のものでない場合は当該最新の検索情報を他のノード装置から取得するように当該コンピュータが機能するので、いずれかのメッセージを取得する度に連続識別情報を更新することで、当該連続識別情報を自律的に最新の状態に維持することができる。
【００５９】
更に、当該コンピュータを請求項１０に記載のノード装置として機能させる場合は、当該コンピュータを請求項４から請求項９のいずれか一項に記載のノード装置として機能させる場合に加えて、送信されて来た連続識別情報と記憶されている連続識別情報とが等しいことが確認されたとき、当該記憶されている連続識別情報を用いて新たなメッセージを生成するので、配信システム内の連続識別情報の更新状態を最新に保つことができる。
【００６０】
上記の課題を解決するために、請求項１３に記載の発明は、複数のノード装置がネットワークを介して接続されて構成され、且つ、いずれかの前記ノード装置である蓄積装置内に蓄積されている配信情報を、他のいずれかの前記ノード装置に配信する配信システムにおいて実行される配信システム制御方法において、各前記ノード装置は、前記検索情報と前記連続識別情報とを対応付けて記憶する記憶手段と、各種情報を表示する表示手段と、を備え、前記蓄積装置に蓄積される前記配信情報の夫々には、一の当該配信情報を他の当該配信情報から識別するための連続識別情報であって前記配信情報毎に値の大小関係が連続している連続識別情報と、当該配信情報を前記配信システム内において検索するための検索情報と、が、前記配信情報を配信する配信サーバ装置において予め付加されており、対応する前記連続識別情報が設定された新たな前記配信情報が、対応する前記検索情報と共に前記蓄積装置内に蓄積されたとき、当該蓄積装置において、当該新たな配信情報に対応する前記検索情報及び前記連続識別情報を含む公開メッセージを前記ネットワークを介して各前記ノード装置に送信する送信工程と、各前記ノード装置において前記ネットワークを介して前記公開メッセージを取得したとき、当該各ノード装置において、当該公開メッセージに含まれている前記連続識別情報と前記記憶手段内に記憶されている前記連続識別情報との間における連続性を、前記連続識別情報の値の大小関係を比較して確認する確認工程と、前記連続性があることが各前記ノード装置において確認されたとき、当該各ノード装置において、前記記憶手段内に記憶されている前記検索情報及び前記連続識別情報を、前記取得した公開メッセージに含まれている前記検索情報及び前記連続識別情報を用いて更新する更新工程と、各前記ノード装置において、前記更新工程において前記検索情報が更新されたタイミングで更新後の当該検索情報を前記表示手段に表示する告知工程と、を含む。
【００６１】
よって、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を手掛かりに各ノード装置の検索情報が更新され、その更新のタイミングで更新後の検索情報が表示手段に表示されるので、配信システム内における検索情報を常に最新の状態に維持して、使用者による配信情報の選択に直ちに供させることができる。
【００６２】
また、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【発明の効果】
【００６３】
以上説明したように、請求項１又は請求項１３に記載の発明によれば、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を手掛かりに各ノード装置の検索情報が更新され、その更新のタイミングで更新後の検索情報が表示手段に表示されるので、配信システム内における検索情報を常に最新の状態に維持して配信情報の配信に直ちに供させることができる。
【００６４】
また、請求項１又は１４に記載の発明によれば、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００６５】
更に、請求項２に記載の発明によれば、新たな配信情報が当該蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する検索情報及び連続識別情報を含む公開メッセージをネットワークを介して各ノード装置に配信するので、当該各ノード装置において、連続識別情報の連続性を手掛かりに検索情報を更新し、その更新のタイミングで更新後の検索情報が表示手段に表示することで、配信システム内における検索情報を常に最新の状態に維持して配信情報の配信に直ちに供させることができる。
【００６６】
また、請求項２に記載の発明によれば、結果的に、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００６７】
更にまた、請求項４に記載の発明によれば、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を確認して各ノード装置の検索情報が更新され、更に当該更新された検索情報が使用者に対して告知されるので、配信システム内における検索情報を常に最新の状態に維持して告知することにより、配信情報の配信を最新の検索情報を用いて実行することができる。
【００６８】
また、請求項４に記載の発明によれば、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００６９】
従って、請求項１、請求項２、請求項４又は請求項１３のいずれか一項に記載の発明によれば、配信システムとしての維持管理等について不要なコスト及び労力を要することなく各ノード装置における検索情報を常に最新の状態に維持できることで、配信システムにおける配信情報の配信に対して利便性及び信頼性を向上させつつ当該配信を行うことができる。
【００７０】
また、請求項３に記載の発明によれば、請求項２に記載の発明の効果に加えて、新たに蓄積される配信情報に対応する連続識別情報との関係で既存の配信情報に対応する連続識別情報との間に連続性が認められるとき、当該蓄積装置内に記憶されている連続識別情報を、新たに蓄積される配信情報に対応する連続識別情報を用いて更新するので、蓄積装置に対して新たな配信情報が蓄積されたとき、迅速且つ自律的に当該蓄積装置内に記憶されている検索情報を更新することができる。
【００７２】
請求項５に記載の発明によれば、請求項４に記載の発明の効果に加えて、他のノード装置から送信されて来た検索情報に対応する連続識別情報との連続性が確認されないとき、その連続性の中断部分に対応する検索情報及び連続識別情報を、取得メッセージに対応して送信されて来た検索情報及び連続識別情報を用いて埋め合わせるので、各ノード装置において、自律的に検索情報の連続性を維持させることができる。
【００７３】
請求項６に記載の発明によれば、請求項４又は請求項５に記載の発明の効果に加えて、検索情報内に含まれている公開メッセージにより、配信されるべきとされている配信情報に対応する検索情報のみが表示手段に表示されるので、その時点で配信を受けることが可能な配信情報のみが検索対象となることで、無駄なく効率的に配信情報の検索を行うことができる。
【００７４】
請求項７に記載の発明によれば、請求項６に記載の発明の効果に加えて、配信許可フラグにより配信されるべきものではないとされている配信情報に対応する検索情報が記憶手段から削除されるので、配信不可能な配信情報についての検索情報が誤って告知されることを防止しつつ、効率的に配信情報の検索を行うことができる。
【００７５】
請求項８に記載の発明は、請求項４から請求項７のいずれか一項に記載の発明の効果に加えて、他のノード装置に対してメッセージを送信する際に、記憶手段に記憶されている最新連続識別情報を付加して送信するので、当該最新連続識別情報を取得した当該他のノード装置において、いずれかのメッセージを取得する度に当該他のノード装置内に記憶されている検索情報を更新することで、当該検索情報を自律的に最新の状態に維持することができる。
【００７６】
請求項９に記載の発明は、請求項８に記載の発明の効果に加えて、いずれかのメッセージを取得したとき、それに含まれている最新連続識別情報との関係で自己の記憶手段内に記憶されている検索情報が最新のものであるか否かを判定し、最新のものでない場合は当該最新の検索情報を他のノード装置から取得するので、いずれかのメッセージを取得する度に連続識別情報を更新することで、当該連続識別情報を自律的に最新の状態に維持することができる。
【００７７】
請求項１０に記載の発明によれば、請求項４から請求項９のいずれか一項に記載の発明の効果に加えて、送信されて来た連続識別情報と記憶されている連続識別情報とが等しいことが確認されたとき、当該記憶されている連続識別情報を用いて新たなメッセージを生成するので、配信システム内の連続識別情報の更新状態を最新に保つことができる。
【００７８】
請求項１１に記載の発明によれば、コンピュータを請求項２に記載の蓄積装置として機能させる場合には、新たな配信情報が当該蓄積装置内に蓄積されたとき、当該新たな配信情報に対応する検索情報及び連続識別情報を含む公開メッセージをネットワークを介して各ノード装置に配信するように当該コンピュータが機能するので、当該各ノード装置において、連続識別情報の連続性を手掛かりに検索情報を更新し、その更新のタイミングで更新後の検索情報が表示手段に表示することで、配信システム内における検索情報を常に最新の状態に維持して配信情報の配信に直ちに供させることができる。
【００７９】
また、結果的に、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００８０】
従って、配信システムとしての維持管理等について不要なコスト及び労力を要することなく各ノード装置における検索情報を常に最新の状態に維持できることで、配信システムにおける配信情報の配信に対して利便性及び信頼性を向上させつつ当該配信を行うことができる。
【００８１】
更に、コンピュータを請求項３に記載の蓄積装置として機能させる場合は、当該コンピュータを請求項２に記載の蓄積装置として機能させる場合に加えて、新たに蓄積される配信情報に対応する連続識別情報との関係で既存の配信情報に対応する連続識別情報との間に連続性が認められるとき、当該蓄積装置内に記憶されている連続識別情報を、新たに蓄積される配信情報に対応する連続識別情報を用いて更新するように当該コンピュータが機能するので、蓄積装置に対して新たな配信情報が蓄積されたとき、迅速且つ自律的に当該蓄積装置内に記憶されている検索情報を更新することができる。
【００８２】
請求項１２に記載の発明によれば、コンピュータを請求項４に記載のノード装置として機能させる場合には、新たな配信情報が蓄積装置内に蓄積されたとき、連続識別情報の連続性を確認して各ノード装置の検索情報が更新され、更に当該更新されたタイミングで更新後の検索情報が使用者に対して直ちに告知されるように当該コンピュータが機能するので、配信システム内における検索情報を常に最新の状態に維持して告知することにより、配信情報の配信を最新の検索情報を用いて実行することができる。
【００８３】
また、配信情報の蓄積に合わせて、各ノード装置内の検索情報が当該各ノード装置において自律的に更新されることとなるので、当該検索情報の更新・管理用に別途サーバ装置等を配信システム内に設ける必要がない。
【００８４】
従って、配信システムとしての維持管理等について不要なコスト及び労力を要することなく各ノード装置における検索情報を常に最新の状態に維持できることで、配信システムにおける配信情報の配信に対して利便性及び信頼性を向上させつつ当該配信を行うことができる。
【００８６】
また、当該コンピュータを請求項５に記載のノード装置として機能させる場合は、当該コンピュータを請求項４に記載のノード装置として機能させる場合に加えて、他のノード装置から送信されて来た検索情報に対応する連続識別情報との連続性が確認されないとき、その連続性の中断部分に対応する検索情報及び連続識別情報を、取得メッセージに対応して送信されて来た検索情報及び連続識別情報を用いて埋め合わせるように当該コンピュータが機能するので、各ノード装置において、自律的に検索情報の連続性を維持させることができる。
【００８７】
更に、当該コンピュータを請求項６に記載のノード装置として機能させる場合は、当該コンピュータを請求項４又は請求項５に記載のノード装置として機能させる場合に加えて、検索情報内に含まれている公開メッセージにより配信されるべきとされている配信情報に対応する検索情報のみが表示手段に表示されるように当該コンピュータが機能するので、その時点で配信を受けることが可能な配信情報のみが検索対象となることで、無駄なく効率的に配信情報の検索を行うことができる。
【００８８】
更にまた、当該コンピュータを請求項７に記載のノード装置として機能させる場合は、当該コンピュータを請求項６に記載のノード装置として機能させる場合に加えて、配信許可フラグにより配信されるべきものではないとされている配信情報に対応する検索情報が記憶手段から削除されるように当該コンピュータが機能するので、配信不可能な配信情報についての検索情報が誤って告知されることを防止しつつ、効率的に配信情報の検索を行うことができる。
【００８９】
また、当該コンピュータを請求項８に記載のノード装置として機能させる場合は、当該コンピュータを請求項４から請求項７のいずれか一項に記載のノード装置として機能させる場合に加えて、他のノード装置に対してメッセージを送信する際に、記憶手段に記憶されている最新連続識別情報を付加して送信するので、当該最新連続識別情報を取得した当該他のノード装置において、いずれかのメッセージを取得する度に当該他のノード装置内に記憶されている検索情報を更新することで、当該検索情報を自律的に最新の状態に維持することができる。
【００９０】
更に、当該コンピュータを請求項９に記載のノード装置として機能させる場合は、当該コンピュータを請求項８に記載のノード装置として機能させる場合に加えて、いずれかのメッセージを取得したとき、それに含まれている最新連続識別情報との関係で自己の記憶手段内に記憶されている検索情報が最新のものであるか否かを判定し、最新のものでない場合は当該最新の検索情報を他のノード装置から取得するように当該コンピュータが機能するので、いずれかのメッセージを取得する度に連続識別情報を更新することで、当該連続識別情報を自律的に最新の状態に維持することができる。
【００９１】
更にまた、当該コンピュータを請求項１０に記載のノード装置として機能させる場合は、当該コンピュータを請求項４から請求項９のいずれか一項に記載のノード装置として機能させる場合に加えて、送信されて来た連続識別情報と記憶されている連続識別情報とが等しいことが確認されたとき、当該記憶されている連続識別情報を用いて新たなメッセージを生成するように当該コンピュータが機能するので、配信システム内の連続識別情報の更新状態を最新に保つことができる。
【発明を実施するための最良の形態】
【００９２】
次に、本発明を実施するための最良の形態について、図面に基づいて説明する。なお、以下に説明する実施形態は、インターネット等のネットワークを用いて上記コンテンツの配信を行う上記配信システムに対して本発明を適用した場合の実施の形態である。
【００９３】
（Ｉ）本発明の原理
初めに、本発明の実施形態について具体的に説明する前に、本発明の原理につき、実施形態に係る配信システムの概要と共に説明する。
【００９４】
（Ａ）配信システムの概要
先ず、実施形態に係る配信システムの概要につき、図１及び図２を用いて説明する。なお、図１及び図２は当該配信システムの概要を示す模式図である。
【００９５】
一般に、上述したＤＨＴを用いた配信システムにおいては、対応するノードＩＤ及びコンテンツＩＤが相互に同じビット長で表現されていることも関連して、当該配信システム内の上記ノード及びコンテンツを、同一のリング状の仮想的なＩＤ空間上に点在するものとして考えることができる。即ち、一のノードを●で表示し且つ一のコンテンツを○で表示する図１（ａ）に示すように、コンテンツが属するリングＲcとノードが属するリングＲnとを仮想的に同心円状に想定し、更に各リングＲc及びＲnにおいて反時計回りに各ＩＤの値が増加すると規定すると、各ノード又は各コンテンツは、各リングＲc及びＲn上に重なることなく存在すると仮定できるのである。なお、各ＩＤを上記の例のように１２８ビット長で表現すると桁数が多くなりすぎるので、図１（ａ）においては、説明の簡略化のために、各ＩＤのビット長を３２ビットとして表現している（以下、同様）。そして、上述したように各ＩＤの値を決めるに当たってハッシュ関数を用いたことに起因して、各ノード及び各コンテンツは、上記各リングＲc及びＲn上に偏ることなく概ね分散して存在することとなる。
【００９６】
一方、上記ＤＨＴを用いた配信システムでは、「あるコンテンツＩＤが付与されているコンテンツを管理するノードは、そのコンテンツＩＤの値に一番近い値を有するノードＩＤが付与されているノード」とされている。
【００９７】
ここで、「近い」とは、その配信システムに関する各種規定等において一貫してさえいればどのような定義付けでも良いのであるが、具体的には例えば、「そのコンテンツＩＤの値を超えない値であって且つＩＤとしての値同士の差が最も小さいもの」というように定義付けられる。
【００９８】
より具体的には、例えば図１（ａ）に例示するように、ノードＩＤの値が「Ａ０３３４０５５」であるノードとノードＩＤの値が「Ａ０３３４０ＦＦ」であるノードとがリングＲn上で隣り合って存在しているとすると、コンテンツＩＤの値が「Ａ０３３４０８０」であるコンテンツは、ノードＩＤの値が「Ａ０３３４０５５」であるノードが管理することになる。なお、図１（ａ）では、○のコンテンツを管理するノードを、当該各○から伸びた矢印で示している。このようにすると、多数のノードで分散して様々なコンテンツを管理することができる。
【００９９】
このとき、「管理」とは、そのコンテンツＩＤが付与されているコンテンツをその中に記録しているという意味ではなく、そのコンテンツが記録されているノードの所在（例えばＩＰアドレス等）を認識しているとの意味である。実際にコンテンツが記録されているノードと管理するノードとが異なっても良いし、或いは管理するノード内にその管理対象であるコンテンツが記録されていても良い。
【０１００】
そして、上述したコンテンツ管理用のノードを「ルートノード」と称する。ルートノードは、それが管理することとされているコンテンツを示すコンテンツＩＤと、当該コンテンツＩＤにより示されるコンテンツが記録されているノードのＩＰアドレスと、の対から少なくともなる上記インデックス情報を記録し、これを配信システム内の他のノードから参照可能に記録する。
【０１０１】
また、異なるコンテンツを夫々示すコンテンツＩＤが偶然に近い値となり、その値に近い値のノードＩＤを有するノードが他に存在しない場合には、一つのルートノードが複数のコンテンツに対応する複数のインデックス情報を記録することとなる。更に、同一のコンテンツが異なる複数のノード内に記録されている場合であって、その同一のコンテンツを記録しているノードが偶然に一つのルートノードに近い場合、当該ルートノードには、同一のコンテンツが夫々に記録されている複数のノードのインデックス情報が記録されることとなる。上述してきたルートノード内のインデックス情報ＥＸの一例を図１（ｂ）に示す。
【０１０２】
更に、実際に各コンテンツ自体を記録しているノードを「コンテンツホルダ」と称する。このとき、当該コンテンツホルダ自体は本来的にはノードであるから、そのノードＩＤは、図１（ａ）におけるリングＲn上に存在していることになる。
【０１０３】
次に、上記ＤＨＴを用いた配信システムにおいて、上述したように全てのノードのＩＰアドレスを各ノード夫々が記録する必要性を排除するための工夫の一つであるＤＨＴ（以下、適宜ルーティングテーブルとも称する）自体について説明する。
【０１０４】
実施形態に係るＤＨＴには、図１に例示したＩＤ空間を段階的なレベル毎にレベル数を上げつつ細分化（例えば、レベル１の場合は当該ＩＤ空間を四分割）していき、そのレベル毎（段階的に細分化した領域毎）に、任意のノードのノードＩＤとそのＩＰアドレスとを対としたルーティング情報が記述されている。そして、例えばコンテンツの配信元情報を要求するための配信元問い合わせ情報をそのインデックス情報が記録されているルートノードに転送する場合、このルーティング情報を参照しつつ当該問い合わせ情報を目的のルートノードまで転送する。即ち、ＤＨＴにおけるレベルが上がる度に、ルーティング先のノードＩＤが到達しようとするルートノードのノードＩＤに一桁ずつ合致していき、最終的に当該到達しようとするルートノードに上記要求情報が到達することになる。
【０１０５】
なお、ＤＨＴを用いた配信システムにおいては、上述した如き問い合わせ情報（クエリ）や、そのコンテンツの配信自体を要求する配信要求情報、及び後述する公開メッセージ等を、単に「メッセージ」と称している。そして、上述した仕組みのＤＨＴを使うと、上記メッセージを図１に例示する如きＩＤ空間内で効率よく目的のノードまで転送することができる。
【０１０６】
また、上記メッセージには、上記ルーティング情報を用いたＤＨＴのルーティング機構によって転送されるタイプのメッセージと、それによって転送されないメッセージの二種類がある。そして、以下に説明する実施例に係るメッセージは、ほとんどが前者のタイプであるが、後で登場する配信要求メッセージは上記転送されないタイプのメッセージである。
【０１０７】
なお、以下の説明においては、コンテンツホルダにおいて新たにコンテンツが記録された場合に、それを他のノードから発見可能にする（公開する）ために当該コンテンツホルダにおいて生成されるメッセージを上記公開メッセージと称し、後述するリクエスタからルートノード又は後述するキャッシュノードに対して送信するメッセージを配信元問い合わせメッセージと称する。
【０１０８】
ここで、上述したようにルートノードのノードＩＤの値は、そのルートノードがコンテンツを管理しているコンテンツホルダのノードＩＤの値に最も近いのであるから、上記配信元問い合わせメッセージは、対応するコンテンツの配信を要求する配信要求メッセージ内に記述されているコンテンツホルダにその配信元問い合わせメッセージが到達する直前に、配信要求対象のコンテンツを管理するルートノードに到達することになる。そして、当該配信元問い合わせメッセージを受け取ったルートノードは、その配信元問い合わせメッセージにより要求されているコンテンツを蓄積しているコンテンツホルダのＩＰアドレス等を、当該配信元問い合わせメッセージの発信元まで返信する。即ち、ルートノード内に記録されているインデックス情報（図１（ｂ）参照）の中から、当該配信元問い合わせメッセージにより要求されているコンテンツを記録しているコンテンツホルダとしてのノードのＩＰアドレスが配信元問い合わせメッセージの発信元であるノードまで返信される。このようなＤＨＴの活用により、効率的に所望のコンテンツの所在が例えば配信要求元において認識できるのである。なお、上述したコンテンツの配信要求元であるノードを、以下「リクエスタ」と称する。
【０１０９】
次に、あるノードに新たなコンテンツが蓄積された場合における当該コンテンツの公開処理について説明する。
【０１１０】
新しいコンテンツがノード、即ちそのコンテンツのコンテンツホルダに蓄積されると、そのコンテンツホルダは、配信システム内の他のノードに対してそのコンテンツが蓄積されたことを公開することになる。
【０１１１】
即ち、あるノードに新たなコンテンツが蓄積されたとき、当該蓄積されたコンテンツに対するコンテンツホルダとなるそのノードは、蓄積されたコンテンツのタイトル等に基づき、当該コンテンツに対応するコンテンツＩＤを算出する。
【０１１２】
次に、当該コンテンツホルダは、算出されたコンテンツＩＤと同じ値を有するノードＩＤを有するノードを到達先として（そのノードＩＤを有するノードが実在するかどうかに拘わらず）、公開メッセージを送信する。この公開メッセージは、そのコンテンツを示すコンテンツＩＤ及びそのコンテンツホルダとしてのノードのＩＰアドレスを含むものであり、上記ＤＨＴの記述に従って各ルーティング先を介して各レベルの到達先としてのノードに順次転送される。
【０１１３】
そして、最も近い値のノードＩＤを有するノードに到達すると、そのノードはその後にその公開メッセージを転送すべきノードがＩＤ空間内に存在しないことを認識して（ＤＨＴで桁合わせをすると、次に転送すべきノードが自分自身であることを認識する）、この時点で当該公開メッセージが到達しているノードが新たなコンテンツを管理するルートノードとなることになる。そして、当該ルートノードとなったノードは、公開メッセージ含まれているコンテンツＩＤ及びコンテンツホルダを示すＩＰアドレスを図１（ｂ）に例示するインデックス情報ＥＸとして記録する。
【０１１４】
次に、実施形態に係る配信システムにおける「キャッシュノード」なる概念について、図２を用いて説明する。なお、図２及び後述の図３においては、ルートノードを二重丸で示し、コンテンツホルダを内部に×が記された○で示し、リクエスタを内部に｜が記された○で示し、後述するキャッシュノードを内部に＋が記された○で示し、他の一般のノードは●で示す。
【０１１５】
上述したＤＨＴを用いたルーティングによりリクエスタＲＱ１乃至ＲＱ３からの配信元問い合わせメッセージＱＲｍｓｇ（Query Message）をルートノードＲＮ（又はコンテンツホルダＣＨ）に転送する場合、その転送経路（図２（ａ）及び図２（ｂ）において破線で示す）は、図２（ａ）に示すように上述した公開メッセージＰＵＢｍｓｇ（Publish Message）が辿った経路（図２（ａ）及び図２（ｂ）において実線で示す）と似た経路となるので、この経路上にある各ノード（図２（ａ）において符号ＣＮで示す）においても図１（ｂ）に例示するインデックス情報ＥＸを記録しておけば、当該経路を経る配信元問い合わせメッセージＱＲｍｓｇに対応して、その到達先であるルートノードＲＮ又はコンテンツホルダＣＨに当該配信元問い合わせメッセージＱＲｍｓｇが到達する前に、早い段階で当該配信元問い合わせメッセージＱＲｍｓｇに対応する回答をリクエスタＲＱ１乃至ＲＱ３まで返信することができる。
【０１１６】
即ち、配信システム内に公開されたコンテンツの配信を要求するリクエスタＲＱ１乃至ＲＱ３が、そのコンテンツが記録されているノード（即ちコンテンツホルダＣＨ）のＩＰアドレスを要求する旨の配信元問い合わせメッセージＱＲｍｓｇを送信すると、当該配信元問い合わせメッセージＱＲｍｓｇは各ノード内のＤＨＴに記述されているルーティング先を転送されルートノードＲＮに近づいていく。そして、最終的には、その経路がコンテンツホルダＣＨからの公開メッセージＰＵＢｍｓｇの経路と合流して、ルートノードＲＮに到達する。
【０１１７】
ここで、図２（ａ）に示したリングＲc上の経路を木構造に置き換えると図２（ｂ）に示した如きものとなるが、これを一般には「スパニングツリー」と称する。
【０１１８】
なお、この「スパニングツリー」なる用語は、元々はＩＰルータの接続がループ状にならないようにするためのルータ技術の中で使われる用語ではあるが、図２（ｂ）に示す場合でも、ループにならない転送経路のツリーがコンテンツＩＤ毎に一つ定義できる（当該図２（ｂ）では省略されているが、その時点で配信システム内に参加している全てのノードを含んだスパニングツリーを記述することができる）。
【０１１９】
一方、図２（ａ）に示したように、各リクエスタＲＱから送信された配信元問い合わせメッセージＱＲｍｓｇの経路とコンテンツホルダＣＨから送信された公開メッセージＰＵＢｍｓｇの経路とは、それら経路上のいずれかのノードにおいていずれ交わる。そこで、公開用の公開メッセージＰＵＢｍｓｇをルートノードＲＮまで到達させる経路上にあるノード夫々に当該公開メッセージＰＵＢｍｓｇに含まれているインデックス情報ＥＸを、一時的に記録可能な一時記録領域に記録させつつ（即ち、一時的にキャッシュさせつつ）当該公開メッセージＰＵＢｍｓｇの転送を行う。そうすれば、リクエスタＲＱからの配信元問い合わせメッセージＱＲｍｓｇに対する返信を、ルートノードＲＮに至る経路上の配信元問い合わせメッセージＱＲｍｓｇが到達したノードから、配信元問い合わせメッセージＱＲｍｓｇがルートノードＲＮに到達する前に行うことができるのである。このようにルートノードＲＮ以外のノードであってインデックス情報ＥＸを一時的に記録しているノードを、一般にはキャッシュノードＣＮと称しているのである。
【０１２０】
（Ｂ）本発明の原理
次に、概要を上述した配信システムを前提とする本発明の原理について、図３を用いて説明する。
【０１２１】
上述した構成を備える配信システムにおいて、当該配信システム内において配信可能なコンテンツを検索するためのカタログは、上述したように各ノードが夫々同一且つ最新のものを記憶しておくことが望ましい。
【０１２２】
そこで、本発明では、各ノードに記憶されているカタログを、カタログ配信サーバ等の特別且つ大規模な装置を配信システム内に設けることなく、各ノードについて相互に同一且つ最新に維持する仕組みとして、新たなコンテンツに相当する新たなコンテンツデータを本発明に係るコンテンツホルダに記録（登録）する際、そのコンテンツデータに対応するシリアル番号が付加されたカタログレコード（一つ一つのタイトルに夫々対応して一つのカタログに含まれることとなる当該タイトル一つ分のカタログとしてのレコード）と共に新規コンテンツデータを当該コンテンツホルダに記録させる。
【０１２３】
この記録について具体的には、先ず、配信システムＳ全体を管理するシステム管理者側の図示しないコンテンツ投入装置（配信システム内に予め参加しているものとする）から、「システム管理者のデータセンタにある新規コンテンツを記録せよ」という旨の記録指示メッセージが、ランダムに選ばれたノードＩＤを有するノード宛に送信される。このとき、本発明に係るシリアル番号は、一つのコンテンツが新規投入される度に、上記システム管理者が「１」づつ増大させることで、異なるコンテンツに対応するカタログレコードが同一のシリアル番号を有することとなるのを回避している。
【０１２４】
即ち、図３に示すように、当該新たなコンテンツデータを蓄積していたサーバＳＶから当該コンテンツデータをコンテンツホルダＣＨに記録させる場合に、当該コンテンツを配信システムＳ内の各ノードＮにおいて検索する際に用いられる検索情報としてのカタログレコードＣＴＧＲを付加した記録指示メッセージＲＩｍｓｇ（Register Instruction Message: 上記コンテンツデータ自体は含まない）を生成して当該コンテンツホルダＣＨに記録を促す。
【０１２５】
このとき、当該カタログレコードＣＴＧＲには、例えば図３に例示するように、対応するコンテンツを検索するための「シリアル番号」、「コンテンツＩＤ（ＣＩＤ）」、「公開日」、「タイトル（コンテンツの名称）」、「配信許可フラグ」及び「検索キー」の各項目に相当する値（又は具体的内容）が記述されている。
【０１２６】
ここで、連続識別情報としての「シリアル番号」とは、各コンテンツ毎に異なって付与される連続番号であり、後からコンテンツホルダＣＨに登録されるコンテンツほど大きいシリアル番号が付される。なお、どのコンテンツにどのシリアル番号を付加するかについては、サーバＳＶを管理する管理者（換言すれば、配信システムＳにおける配信を管理する管理者）により選ばれるものであるが、基本的には、時系列に沿って、登録されるコンテンツが新しいほど連続番号としての番号が大きいものが付与される。
【０１２７】
また、「コンテンツＩＤ」は、原則としては上述した配信システムＳとしての一般的な規則に従って付与されるものである。しかしながら、本発明の場合は、カタログに全てのタイトルとコンテンツＩＤとの対応関係が記述されていることになるので、当該タイトルからハッシュ関数を用いてコンテンツＩＤを決めるという上記ＤＨＴにおける一般的な方法をとらずとも、コンテンツＩＤの重複さえなければ、任意の方法でコンテンツＩＤを付与しても良い。
【０１２８】
更に、「公開日」及び「タイトル」は、夫々、そのコンテンツが配信システムＳにおいて配信可能となる日（原則的には、コンテンツホルダＣＨ内に記録される日）及びそのコンテンツとしての名称が記述されている。
【０１２９】
更にまた、「配信許可フラグ」は、例えば著作権保護等の観点から、そのコンテンツが現時点において配信システムＳ内の各ノードＮに対して配信可能となっているか否かを示すフラグであり、具体的な値としては、配信可能となっているときは値「Ｅ」が記述されており、配信不可であるときは値「Ｄ」が記述されているものである。
【０１３０】
なお、当該配信許可フラグの活用方法としては、あるコンテンツを一旦カタログに登録したが、後になって、例えば、著作権保持者から配信を停止したいという意志変更があった場合や、コンテンツデータ自体に映像・音声のノイズがあった場合、或いはコンテンツ中の発言内容又は表現内容等が倫理的に不適切であることが判明した場合等、その配信を停止したい場合において、当該コンテンツを配信不可とするために用いることが可能である。
【０１３１】
即ち、本発明の方式では、投入したカタログレコードは増える一方であり、いずれかの当該カタログレコードを削除することが難しいため、このようなフラグを設けている。つまり、過去のカタログレコードは存在していても、同じコンテンツＩＤで新しいカタログレコードがあれば、そちら（即ち、シリアル番号が大きい方のカタログデータ）を優先して解釈するように構成することで、そのシリアル番号の大きい方のカタログレコードにおける配信許可フラグを「配信不可」としておけば、対応するコンテンツの配信を実行しないように制御することができるのである。
【０１３２】
最後に、「検索キー」には、例えば、そのコンテンツの製作者名（そのコンテンツが映画である場合はその監督名等）、コンテンツ内における登場人物名又はそれらを演じる俳優名、あらすじ、そのコンテンツを代表するキーワード等、が、各ノードＮにおける検索処理で当コンテンツに辿り付くための手掛かりとなる情報として記述されている。
【０１３３】
そして、このようなカタログレコードＣＴＧＲが、別ルートを介して記録されるコンテンツデータＣＤと共にコンテンツホルダＣＨ内に記録されると、上記公開メッセージＰＵＢｍｓｇが当該コンテンツホルダＣＨから当該各ノードＮに対して送信されることとなるが、この公開メッセージは、その公開メッセージＰＵＢｍｓｇにより公開されるコンテンツに対応するシリアル番号（換言すれば、その時点での最大値を有するシリアル番号）が付加された上で送信される。
【０１３４】
次に、本発明では、上記公開メッセージＰＵＢｍｓｇを含む全てのメッセージＭＳＧにつき、当該各メッセージＭＳＧがいずれかのノードＮから送信される際には、その時点でそのノードＮ内に記憶されているカタログにおけるシリアル番号の最大値が付加された上で送信される。これにより、当該メッセージＭＳＧを受信した他のノードＮにおいては、その時点で当該他のノードＮ内に記憶しているカタログにおけるシリアル番号と送信されてきたメッセージＭＳＧに含まれていたシリアル番号とを比較し、当該送信されてきたメッセージＭＳＧに含まれていたシリアル番号の方が大きい場合は、配信システムＳ内に、当該他のノードＮが認識していない新しいコンテンツが登録されているものと認識し、当該新たなコンテンツを検索するためのカタログに相当するカタログレコードＣＴＧＲを、そのメッセージＭＳＧの中継送信元のノードから、或いは配信システムＳ内の他のノードＮから自律的に取得する。
【０１３５】
以上の一連の処理が、上記シリアル番号を手掛かりとして各ノードＮにおいて自律的に実行されることにより、配信システムＳ内の各ノードＮが、相互に同一且つ最新のカタログレコードＣＴＧＲを自律的に取得することが可能となるのである。
【０１３６】
（II）実施形態
次に、上述した原理に則った本発明に係る実施形態について、具体的に図４乃至図１０を用いて説明する。なお、以下に説明する実施形態に係る配信システムでは、説明の簡略化のため、当該配信システム内に上記キャッシュノードＣＮが存在していないものとして説明する。
【０１３７】
始めに、実施形態に係るノードの概要構成について図４を用いて説明する。なお、図４は実施形態に係るノードの概要構成を示すブロック図である。また、実施形態においては、上記コンテンツホルダＣＨ、リクエスタＲＱ、ルートノードＲＮ及びその他のノードＮは、基本的に全て同一のハードウェア構成を有するものであるので、それらを代表して一般のノードＮの構成について、図４を用いてその概要を説明する。
【０１３８】
図４に示すように、実施形態に係る配信システムに含まれているノードＮは、演算機能を有するＣＰＵ、作業用ＲＡＭ（Random Access Memory）、各種データ及びプログラムを記録するＲＯＭ（Read Only Memory）等から構成された制御部１１と、上記コンテンツ自体としてのコンテンツデータ、上記ＤＨＴ及びその他の必要なプログラム等を記録保存（格納）すると共に上記インデックス情報ＥＸを記憶するためのＨＤＤ等から構成された記憶部１２（上記コンテンツデータは、その配信前はコンテンツホルダＣＨとしてのノードＮ内の記憶部１２内にのみ記録されている）と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコード（符号化）されたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ（Cathode Ray Tube）又は液晶ディスプレイ等よりなる表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ／Ａ（Digital/Analog）変換した後これを増幅器等により増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワークを通じて他のノードＮとの間の情報の通信制御を行なうための通信部２０と、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する入力部（例えば、キーボード、マウス或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【０１３９】
そして、制御部１１におけるＣＰＵが記憶部１２等に記録された各種プログラムを実行することにより、制御部１１が、リクエスタＲＱ、ルートノードＲＮ、コンテンツホルダＣＨ又はそれら以外の一般のノードＮのいずれか一つとしての全体動作を統括制御する。
【０１４０】
なお、上記ノードＮが本発明に係る蓄積装置としてのコンテンツホルダＣＨである場合は、制御部１１が配信手段として機能する。また、上記ノードＮが本発明に係るノード装置である場合は、記憶部１２が記憶手段として機能し、制御部１１が確認手段、更新手段、取得メッセージ送信手段、削除手段、付加手段及びメッセージ送信手段として機能し、表示部１６が告知手段として機能する。
【０１４１】
次に、ノード一般（ルートノードＲＮ、コンテンツホルダＣＨ及びリクエスタＲＱを含む）としての基本的な共通動作、コンテンツホルダＣＨの動作及びリクエスタＲＱの動作に分けて、実施形態に係る動作について説明する。
【０１４２】
（Ａ）ノードとしての一般動作
先ず、実施形態に係るノードＮとしての一般動作、即ち、配信システムＳ内のノードＮとしての基本的な共通動作を、図５を用いて説明する。なお、図５は実施形態に係るノードＮとしての一般動作を示すフローチャートであり、主として制御部１１を中心として実行される。
【０１４３】
図５に示すように、実施形態に係るノードＮとしての共通動作においては、先ず、制御部１１は、当該ノードＮを起動するための初期化処理を行い（ステップＳ１）、配信システムＳにそのノードＮが参加するための参加要求メッセージを、当該ノードＮが配信システムＳに参加するに当たっての仲介役となる他のノードＮであるコンタクトノードに送信し（ステップＳ２）、その参加の可否の回答を待つ（ステップＳ３）。そして、そのノードＮが配信システムＳ内に参加できない何らかの理由（たとえば、配信システムＳに新規に参加する場合には料金が発生することとされている場合においてその料金の支払いが確認されない場合等）があるときは（ステップＳ３；ＮＯ）、その旨をそのノードＮの表示部１６に表示する等してその使用者に告知して（ステップＳ１５）、当該ノードＮとしての実施形態に係る処理を終了する。
【０１４４】
一方、ステップＳ３の判定において、そのノードＮが配信システムＳ内に参加することが許可される場合は（ステップＳ３；ＹＥＳ）、そのコンタクトノードから配信システムＳにおいてその時に有効な上記ルーティング情報を取得して記憶し（ステップＳ４）、更に新規に参加したノードＮが配信システムＳ内の他のノードＮに配信可能なコンテンツを記憶している場合には、上記コンテンツホルダＣＨとしてそのコンテンツに対応する上記公開メッセージＰＵＢｍｓｇを生成して配信システムＳ内に送信する（ステップＳ５）。
【０１４５】
そして、記憶部１２内の後述する再生指示フラグ及び後述する端末終了指示フラグを「０」に初期化すると共に、新たに参加したノードＮの使用者に対して、配信システムＳ内において配信を受けることが可能なコンテンツを検索して選択する等のためのスレッド（当該スレッドの詳細は、後ほど図６を用いて説明する）を起動する処理を行う（ステップＳ６）。
【０１４６】
ここで、上記再生指示フラグとは、ノードＮの使用者が上記入力部２１を用いて行う入力操作により視聴を希望するコンテンツを選択決定したときに「１」となる制御部１１内のフラグであり、一方、端末終了指示フラグは、当該使用者が入力部２１を用いてノードＮの使用を終了する旨の操作を行ったときに「１」となる制御部１１内のフラグである。
【０１４７】
そして、当該スレッドにおける処理により当該各指示フラグが更新されて「１」に変化することを待機すると共に、参加した配信システムＳの他のノードＮからの各種メッセージの受信を待機する（ステップＳ８；ＮＯ）。
【０１４８】
そして、使用者によるいずれかの指示フラグの変化又はいずれかのメッセージの受信がされたときは（ステップＳ８；ＹＥＳ）、再生指示フラグが「１」であるか否か、即ち使用者によるコンテンツの配信要求操作があったか否かを確認する（ステップＳ９）。
【０１４９】
ステップＳ９の判定において、使用者による当該配信要求操作があったときは（ステップＳ９；ＹＥＳ）、当該ノードＮは以後上記リクエスタＲＱとして動作することとなるので、その配信が所望されるコンテンツの発見処理又はその取得後の再生処理を実行する（ステップＳ１３）。このステップＳ１３の処理についても、後ほど詳述する。
【０１５０】
なお、再生指示フラグが「１」になったときは、それと同時にスレッド処理中にユーザが選択したコンテンツのコンテンツＩＤが記憶されているので、そのコンテンツＩＤを用いて発見・再生処理が行われる。
【０１５１】
そして、コンテンツの再生が開始した後は、再生指示フラグを「０」に戻して（ステップＳ１６）、次の配信要求等に備えて上記ステップＳ８の処理に移行する。
【０１５２】
一方、ステップＳ９の判定において、ステップＳ８における処理が使用者による配信要求操作でないときは（ステップＳ９；ＮＯ）、ステップＳ８における処理は、配信要求操作以外の入力操作か、或いは他のメッセージＭＳＧの受信処理であったこととなるので、メッセージ受信があったか否かを確認する（ステップＳ１０）。そして、メッセージＭＳＧの受信処理だったときは（ステップＳ１０；ＹＥＳ）、当該受信したメッセージＭＳＧに対応する処理（具体的には、ルーティング情報の更新処理、他のノードＮへのメッセージＭＳＧの転送処理等）を行い（ステップＳ１４）、上記ステップＳ８の処理に移行する。このステップＳ１４の処理についても、後ほど詳述する。
【０１５３】
他方、ステップＳ１０の判定において、未だいずれのメッセージＭＳＧも受信していないときは（ステップＳ１０；ＮＯ）、次に、先ほどの入力操作が、当該ノードＮとしての動作を終了する旨の操作であったか否かを確認する（ステップＳ１１）。そして、当該操作がされていないときは（ステップＳ１１；ＮＯ）、無効な操作がなされたと見なし、上記ステップＳ８の処理に移行する。
【０１５４】
これに対し、ノードＮとしての動作を終了する旨の操作が為されたときは（ステップＳ１１；ＹＥＳ）、脱退メッセージ等の配信システムＳへの送信処理等の脱退処理を実行し（ステップＳ１２）、実施形態に係るノードＮとしての動作を終了する。
【０１５５】
次に、上記ステップＳ６の処理の一部として実行される、上記スレッドの内容について具体的に図６を用いて説明する。なお、図６は、当該スレッドの内容を示すフローチャートである。
【０１５６】
当該スレッドとして具体的には、図６に示すように、コンテンツ検索及び選択操作のためのスレッドが開始されると、先ず、コンテンツ検索用の予め設定された検索画面を表示部１６に表示する。
【０１５７】
ここで、当該検索画面について具体的に図７（ａ）を用いて例示しつつ説明すると、当該検索画面としては、その検索画面としての表題が表示される表題欄３０と、コンテンツのタイトルを手掛かりとして検索を行う際に当該タイトルが入力されるタイトル入力欄３１と、そのコンテンツに出演している俳優等の名前を手掛かりとして検索を行う際に当該名前が入力される名前入力欄３２と、そのコンテンツの監督の名前を手掛かりとして検索を行う際に当該名前が入力される名前入力欄３３と、そのコンテンツを端的に示すキーワード（図３に例示するカタログレコードＣＴＧＲ内の「検索キー」に相当するキーワード）を手掛かりとして検索を行う際に当該キーワードが入力されるキーワード入力欄３４と、入力された検索条件を用いて実際にカタログ内を検索させる際に操作する検索操作ボタン３５と、カタログの登録順に従って一覧として表示させる際に操作される一覧表示操作ボタン３６と、種々の情報を表示するための情報表示欄３８と、当該情報の続きを表示させるために操作される操作ボタン３９と、ノードＮとしての動作終了を指示するための終了ボタン４０と、他の種々の情報が表示される情報表示欄３７と、を含む検索画面が表示部１６上に表示される（ステップＳ６０）。
【０１５８】
当該検索画面が表示されると、先ずタイトル入力欄３１を文字入力可能とし（ステップＳ６１）、その後に入力部２１におけるいずれかのキーの操作又はボタンの操作を待機する（ステップＳ６２）。そして、入力部２１内の図示しない上下キーが操作されたときは（ステップＳ６３；ＹＥＳ）、文字入力可能とする検索画面内の欄を、例えば名前入力欄３２等の他の入力欄に移動させ（ステップＳ６６）、上記ステップＳ６２に戻って次の入力操作を待機する。
【０１５９】
また、上記入力操作が上下キーでないときは（ステップＳ６３；ＮＯ）、次に、入力部２１内の図示しない左右キー、文字キー又は削除キー等が操作されたか否かを確認する（ステップＳ６４）。そして、いずれかの文字等の入力が実行されたときは（ステップＳ６４；ＹＥＳ）、その時に文字入力可能とされている入力欄において、その入力された文字等を用いた検索キーワードの編集処理（より具体的には、検索キーワードの確定処理等）が実行され（ステップＳ６７）、再度上記ステップＳ６２に戻って次の入力操作を待機する。
【０１６０】
他方、ステップＳ６４の判定において、文字キー等の操作が為されていないときは（ステップＳ６４；ＮＯ）、次に検索実行ボタン３５が操作されたか否かを確認する（ステップＳ６５）。そして、当該検索実行ボタン３５も操作されていないときは（ステップＳ６５；ＮＯ）、最後に、終了ボタン４１が操作されたか否かを確認し（ステップＳ６８）、当該終了ボタン４１も操作されていないときは（ステップＳ６８；ＮＯ）、上記ステップＳ６３に戻って更なる入力操作を待機する。
【０１６１】
一方、ステップＳ６８の判定において、終了ボタン４１が操作されたときは（ステップＳ６８；ＹＥＳ）、上記端末終了指示フラグの値を制御部１１内において「１」に設定し（ステップＳ６９）、上記ステップＳ６２に戻って更なる入力操作を待機する。
【０１６２】
他方、上記ステップＳ６５の判定において検索実行ボタン３５が操作されたときは（ステップＳ６５；ＹＥＳ）、この時点で各入力欄に入力されている検索キーワードでカタログの検索を行うことが確定したことになる。即ち、現在記憶部１２内に記憶されているカタログの中から、上記確定された検索キーワードに一致するタイトル等を有するコンテンツを抽出し（ステップＳ７０）、その抽出した内容をリスト表示する（ステップＳ７１）。このとき、当該リストは、コンテンツ再生表示画面とは別画面により検索結果一覧表として表示される。
【０１６３】
ここで、当該検索結果一覧表について、図７（ｂ）を用いて説明する。
【０１６４】
当該検索結果一覧表としては、例えば図７（ｂ）に一覧表ＬＴとして例示するように、当該確定された検索キーワードに一致するタイトル等を有するコンテンツにつき、当該コンテンツのタイトル及び検索のためのキーワードが、上記カタログレコードＣＴＧＲの一部の情報を引用して一覧表示される。なお、図７（ｂ）においては、一覧表ＬＴ内においてその時点で選択されたコンテンツがハイライト表示されることを、ハッチングにより示している。
【０１６５】
また、当該一覧表ＬＴと同時に、当該一覧表ＬＴにおいて選択されるコンテンツを移動するための上下キー４１及び４２と、一覧表ＬＴを用いて選択されたコンテンツの視聴（再生）を開始する際に操作される視聴ボタン４３と、検索キーワードの再入力操作等を実行すべく図７（ａ）に示す検索画面を再度表示させるための戻るボタン４４と、が表示部１６に表示される。
【０１６６】
更に、当該一覧表ＬＴを表示する際には、当該抽出された（ステップＳ７０）カタログレコードＣＴＧＲに含まれる配信許可フラグ（図３参照）が、その時点で「Ｅ」、即ち、公開可能となっているもののみを表示する。即ち、同一のコンテンツＩＤがカタログ中に複数書かれていた場合、その中でシリアル番号が最大のものが有効であるので、最大シリアルのものが「Ｅ」であるコンテンツのみを表示し、最大シリアルのものが「Ｄ」であるコンテンツは一覧に表示しない。
【０１６７】
ステップＳ７１の処理により一覧表ＬＴが表示部１６に表示された後は、いずれかのボタン又はキーの操作を待機しつつ（ステップＳ７２）、選択対象のコンテンツを変更するために上記上下キー４１又は４２が操作されか否かを監視する（ステップＳ７３）。
【０１６８】
そして、上下キー４１又は４２が操作されたときは（ステップＳ７３；ＹＥＳ）、その操作された上下キー４１又は４２に合わせて一覧表ＬＴ内の表示コンテンツのハイライト表示を切り換え（ステップＳ７７）、再度上記ステップＳ７２に戻って次の入力操作を待機する。
【０１６９】
一方、ステップＳ７３の判定において、上下キー４１又は４２のいずれもが操作されていないときは（ステップＳ７３；ＮＯ）、次に、上記戻るボタン４４が操作されたか否かを確認する（ステップＳ７４）。そして、当該戻るボタン４４が操作されたときは（ステップＳ７４；ＹＥＳ）、上記ステップＳ６０に戻って検索画面の新たな表示から処理を繰り返す（ステップＳ６０）。
【０１７０】
他方、ステップＳ７４の判定において、戻るボタン４４も操作されていないときは（ステップＳ７４；ＮＯ）、最後に、視聴ボタン４３が操作されたか否かを確認する（ステップＳ７５）。そして、視聴ボタン４３も操作されていないときは、無効な入力ボタンが操作された場合であるので（ステップＳ７５；ＮＯ）、上記ステップＳ７２に戻って次の入力操作を待機し、操作されたときは（ステップＳ７５；ＹＥＳ）、当該視聴対象となっているコンテンツのコンテンツＩＤを制御部１１内に記憶させると共に当該制御部１１内の再生指示フラグを「１」に設定し（ステップＳ７６）、再度上記ステップＳ６２に戻って次の入力操作を待機する。
【０１７１】
次に、図５に示す上記ステップＳ１４の処理としての実施形態に係るメッセージＭＳＧの処理動作の詳細を、図８乃至図１０を用いて具体的に説明する。なお、図８は当該処理動作の全体を示すフローチャートであり、図９はメッセージＭＳＧの一つである上記記録指示メッセージＲＩｍｓｇをコンテンツホルダＣＨにおいて受信した時の動作を示すフローチャート等であり、図１０は実施形態に係るカタログレコードＣＴＧＲの更新の様子を示す例示する図である。
【０１７２】
図８に示す処理動作は、新たなメッセージＭＳＧ（図３参照）が他のいずれかのノードＮから送信されて来たときに実行される。
【０１７３】
即ち、先ず、メッセージＭＳＧが記録指示メッセージＲＩｍｓｇかどうかを判定する（ステップＳ３０）。そして、当該記録指示メッセージＲＩｍｓｇであれば（ステップＳ３０；ＹＥＳ）、当該記録指示メッセージＲＩｍｓｇを受信する処理を実行し（ステップＳ９５）、次の処理に備えて待機状態（図５ステップＳ８参照）に入る。なお、当該ステップＳ９５の処理については、後ほど詳述する。
【０１７４】
一方、上記ステップＳ３０の判定において、メッセージＭＳＧが記録指示メッセージＲＩｍｓｇでない場合は、メッセージＭＳＧ内のメッセージヘッダＭＨＤに含まれているcont_sn_max（この「cont_sn_max」なる情報は、他のいずれかのノードＮにおいて中継されて来るタイプのメッセージＭＳＧの場合、当該中継処理を行ったノードＮが夫々保持しているカタログ中の最大シリアル番号を示す情報であり、当該メッセージＭＳＧにおける「Received」フィールドと「Routed」フィールド内に夫々記述されている（図９（ｂ）参照）が、ステップＳ３１の処理ではそれらの中の最大の値を参照する）の値と、その時点でそのノードＮの記憶部１２に記憶されているカタログにおける最大のシリアル番号の値とを比較し、受信したメッセージＭＳＧ内のシリアル番号の値の方が大きいか否かを確認する（ステップＳ３１）。
【０１７５】
ステップＳ３１の判定において、受信したメッセージＭＳＧ内のシリアル番号の値の方が大きくないときは（ステップＳ３１；ＮＯ）、その時点で記憶部１２に記憶されている最大のシリアル番号の値を含むメッセージヘッダＭＨＤ（図９（ｂ）参照）を生成し（ステップＳ３６）、後述するステップＳ３７に移行する。このメッセージヘッダＭＨＤは、後ほどメッセージＭＳＧを他のノードＮに送信（転送）する際に使用されるものであり、詳細は後ほど説明する。
【０１７６】
一方、ステップＳ３１の判定において、受信したメッセージＭＳＧ内のシリアル番号の値の方が大きいときは（ステップＳ３１；ＹＥＳ）、受信したメッセージＭＳＧ内のシリアル番号に相当するカタログレコードＣＴＧＲのみを、当該メッセージＭＳＧを送信してきたノードＮに要求して取得し、更に当該取得したカタログレコードＣＴＧＲを用いて記憶部１２に記憶されているカタログを更新する（ステップＳ３２。図１２（ａ）参照）。
【０１７７】
次に、ステップＳ３１において判定したシリアル番号の大小関係における当該シリアル番号間の連続性の有無を確認する（ステップＳ３３）。このとき、通常は当該シリアル番号間が連続になることが多いが、例えば図８に示す処理が実行されているノードＮの電源が一時的にオフとされた場合であって、そのオフとされている間に新規コンテンツの投入が為され、その後に当該オフとなっていた電源が入れられてから更に別の新規コンテンツが投入された場合等においては、それらが連続した番号にならない場合がある。
【０１７８】
ステップＳ３３の判定において、各シリアル番号同士が連続しているときは（ステップＳ３３；ＮＯ）、その更新後の新しいカタログにおける最大のシリアル番号の値（即ち、上記受信したメッセージＭＳＧ内のシリアル番号の値）を含むメッセージヘッダＭＨＤ（図９（ｂ）参照）を生成し（ステップＳ３５）、後述するステップＳ３７の処理に移行する。
【０１７９】
一方、ステップＳ３３の判定において、ステップＳ３１の判定において比較対象となった二つのシリアル番号の間に上記中抜けが存在しているときは（ステップＳ３３；ＹＥＳ）、その中抜け部分に相当するシリアル番号を含むカタログレコードＣＴＧＲにつき、他のノードＮから、中抜け部分に相当するカタログレコードＣＴＧＲを取得する。このためには、その中抜け部分に相当するシリアル番号を含むカタログリストの取得メッセージ（Get Catalog List Message）を別途生成し、これを配信システムＳ内の任意のノードＮに対して送信する。
【０１８０】
ここで、当該取得メッセージの内容としては、上記中抜け部分を補填するために必要なシリアル番号が列記されている。このとき、当該必要なシリアル番号を全て列記する以外に、要求するシリアル番号の範囲の、先頭と最後のシリアル番号が記述されていても良い。
【０１８１】
更に、このときの宛先となるノードＮは、例えばランダムに決定する。また、当該カタログリスト取得メッセージはＤＨＴを用いて転送されるタイプのメッセージＭＳＧである。これにより、当該取得メッセージの転送途中において要求されたカタログレコードＣＴＧＲを記憶しているノードＮがあれば、そのノードＮが取得メッセージ送信元のノードＮまで対応する返信を行う（当該返信処理についての詳細は後述する）。
【０１８２】
そして、当該取得メッセージに対応した当該中抜け部分に相当するカタログレコードＣＴＧＲがいずれかのノードＮから返信されて来たとき、当該返信されて来たカタログレコードＣＴＧＲを用いて記憶部１２内のカタログ（の中抜け部分）を更新する（ステップＳ３４。図１２（ａ）参照）。このとき、当該配信許可フラグが「Ｄ」のカタログレコードＣＴＧＲを追加した場合は、対応するコンテンツを蓄積しているかどうかを検査して、もし蓄積している場合は、当該コンテンツデータを削除する動作も行う。そして、上記ステップＳ３５及びＳ３７の処理に移行する。
【０１８３】
ここまでの処理を言い換えると、配信システムＳ全体としてのシリアル番号が「１」増えたこと（即ち、新たなコンテンツが当該配信システムＳ内に投入されたこと）が、図８に示す処理が実行されているノードＮにおいて検知されたときは、メッセージＭＳＧの中継送信元のノードＮから最新のカタログレコードＣＴＧＲを取得すれば済むが、配信システムＳ全体としてのシリアル番号が「２」以上増えていた場合は、メッセージＭＳＧの中継送信元のノードＮから最新のカタログレコードＣＴＧＲを取得するだけでは上記中抜けが検知されることとなるので、他のノードＮからその中抜け部に相当するカタログレコードＣＴＧＲを取得してカタログとしての補完処理を更に行うのである。
【０１８４】
次に、受信した（ステップＳ３１参照）メッセージＭＳＧが、他のノードＮに転送すべきメッセージＭＳＧであるか否かを確認し（即ち、先ずそのメッセージＭＳＧのメッセージタイプが転送をするタイプであるか否かを判定して、転送すべきタイプであれば、ＤＨＴのルーティングテーブルを参照して、転送先が自分でないかどうかを判定する。ステップＳ３７）、当該転送すべきメッセージＭＳＧであるときは（ステップＳ３７；ＹＥＳ）、ステップＳ３５又はＳ３６の処理により生成されたメッセージヘッダＭＨＤをその先頭に含む当該転送すべきメッセージＭＳＧを生成して配信システムＳ内の他のノードＮに転送し（ステップＳ３８）、次の処理に備えて待機状態（図５ステップＳ８参照）に入る。
【０１８５】
他方、ステップＳ３７の判定において、他のノードＮに転送すべきメッセージＭＳＧでないときは（ステップＳ３７；ＮＯ）、そのノードＮ自身において当該受信したメッセージＭＳＧに対応する処理を行って（ステップＳ３９）、上記待機状態（図５ステップＳ８参照）に移行する。
【０１８６】
以上の動作が各ノードＮにおいて夫々実行されることで、当該各ノードＮにおける自律的なカタログレコードＣＴＧＲの更新が完了する。
【０１８７】
ここで、上記ステップＳ３９の処理としてはメッセージＭＳＧの種別毎に個別の処理を行うこととなる。
【０１８８】
一方、ステップＳ３０の判定において、当該メッセージＭＳＧが上記記録指示メッセージＲＩｍｓｇであった場合には（ステップＳ３０；ＹＥＳ）、図９（ａ）に示すフローチャートに対応する処理が実行される。ここで、図９（ａ）は、各ノードＮ（換言すれば、事後的にコンテンツホルダＣＨとなるノードＮ）において、新たなコンテンツデータを記録すべき旨の指示を示すメッセージとして、記録指示メッセージＲＩｍｓｇ（図３参照）が図示しないコンテンツ投入装置から送信され、それを受信したときに実行される処理を示すフローチャートである。なお、当該記録指示メッセージＲＩｍｓｇには、新規コンテンツに対応するカタログレコードＣＴＧＲが付加されている。
【０１８９】
図９（ａ）に示すように、上記記録指示メッセージＲＩｍｓｇを受信したノードＮ（コンテンツホルダＣＨとなるノードＮ）は、先ず当該記録指示メッセージＲＩｍｓｇのカタログレコードＣＴＧＲにおける配信許可フラグの内容を確認し（ステップＳ２０）、配信可能であるか否かを判断する（ステップＳ８０）。当該配信許可フラグが「Ｄ」である場合は（ステップＳ８０；ＮＯ）、当該コンテンツ投入装置からのコンテンツデータの取得は行わず、更に自ら記憶しているコンテンツの中に当該コンテンツがあれば、それを削除する処理を行って（ステップＳ８１）、ステップＳ２１の処理に移行する。
【０１９０】
なお、当該ステップＳ８１の処理について具体的には、当該コンテンツホルダＣＨとなるノードＮがそのコンテンツに相当するコンテンツデータを既に蓄積しているのであれば当該コンテンツデータを削除し、その後、下記に示す配信許可フラグが「Ｅ」である場合と同様にして、自信が記憶しているカタログの更新処理を実行する。また、当該ノードＮが当該コンテンツデータを蓄積していない場合において、それが削除されるタイミングは、上記ステップＳ３４におけるカタログの更新処理が実行されるときである。
【０１９１】
一方、ステップＳ８０の判定において、配信許可フラグが「Ｅ」である場合は（ステップＳ８０；ＹＥＳ）、上記カタログレコードＣＴＧＲに記述されているコンテンツを図示しないコンテンツ投入装置から取得する（ステップＳ８２）。
【０１９２】
次に、元の記録指示メッセージＲＩｍｓｇ内に含まれているカタログレコードＣＴＧＲのシリアル番号の値と、その時点で記憶部１２に記憶されているカタログにおける最大のシリアル番号の値とを比較し、記録指示メッセージＲＩｍｓｇ内のシリアル番号の値の方が大きいか否かを確認する（ステップＳ２１）。
【０１９３】
ステップＳ２１の判定において、記録指示メッセージＲＩｍｓｇ内のシリアル番号の値の方が大きくないときは（ステップＳ２１；ＮＯ）、その時点で記憶部１２に記憶されている最大のシリアル番号の値を含むメッセージヘッダＭＨＤ（図９（ｂ）参照）を生成し（ステップＳ２５）、後述するステップＳ２６に移行する。なお、図９（ｂ）においては、「cont_sn_max」で示される値のうち最大のものが現時点での最大のシリアル番号の値である。
【０１９４】
ここで、当該メッセージヘッダＭＨＤについて、より具体的に図９（ｂ）を用いて説明する。
【０１９５】
当該メッセージヘッダＭＨＤは、本実施形態で扱われる全てのメッセージＭＳＧ内でヘッダとして用いられるもので、後述する公開メッセージＰＵＢｍｓｇ送信（図９（ａ）ステップＳ２９）の際のヘッダとしても使用されるものである。メッセージヘッダＭＨＤの中の各フィールドについて説明すると、先ず「Return-Path」フィールドには、メッセージＭＳＧを送信した大元のノードＮのＩＰアドレスが記述されている。このとき、転送されるタイプのメッセージＭＳＧにおいても、その転送中において「Return-Path」フィールドの内容は変化しない。
【０１９６】
次に、「Received」フィールドには、どのノードＮから受け取ったメッセージＭＳＧであるかを示す情報が送信ノードＮのＩＰアドレスにより記述されている。このとき、転送されるタイプのメッセージＭＳＧにおいては、転送の都度、「Received」フィールドの内容が更新されることとなる。そして、本発明においては、当該「Received」フィールドにカタログ中の最大シリアル番号cont_sn_maxを記述することにしている（なお、当該「Received」フィールドに記述されている「version」情報は、本発明では使用しない）。
【０１９７】
次に、「Routed」フィールドに記述されている情報は、メッセージＭＳＧの転送履歴を示すものである。即ち、あるノードＮにおいて、それが他のノードＮから受信したメッセージＭＳＧを転送するときは、そのメッセージＭＳＧ内の「Received」フィールドの内容を「Routed」フィールドに移動させ、それまでの「Routed」フィールド内の情報を、一レコード分下にずらして記述し直す。これにより、メッセージＭＳＧの転送の度に「Routed」フィールドが増えていくことになる。
【０１９８】
次に、「Message-ID」フィールドに記述されている情報は、メッセージＭＳＧの重複到着を検知するために用いられる情報であり、送信元のノードＮのＩＰアドレス及び送信時刻等に基づきユニークな値が付与される。
【０１９９】
次に、「Message-Date」フィールドには、メッセージＭＳＧを送信した日付時刻が記述されており、例えば動作履歴への記録等の目的で使用されるものである。
【０２００】
更に、「Event-Type」フィールドは、当該メッセージＭＳＧの種別を示す情報が記述される。ステップＳ３９の処理としては、当該「Event-Type」フィールドに記述されている情報を参照して、メッセージＭＳＧの種類毎に異なる処理を実行することになる。
【０２０１】
最後に、「Contents-Id」フィールドには、その時に着目しているコンテンツのコンテンツＩＤが記述されている。例えば、上記公開メッセージＰＵＢｍｓｇにおいては、公開するコンテンツのコンテンツＩＤを記述する。また、配信元問い合わせメッセージＱＲｍｓｇにおいては、発見したいコンテンツのコンテンツＩＤを記述する。更に、メッセージＭＳＧの種別によっては、この「Contents-Id」フィールドが存在しないものもある。
【０２０２】
なお、図９（ｂ）においては、メッセージヘッダＭＨＤの詳細な説明のために「Routed」フィールドが記載されているが、後述するステップＳ２９の処理に供される公開メッセージＰＵＢｍｓｇは、一番大元のメッセージＭＳＧになる（転送されるタイプのメッセージＭＳＧではあるが、ここが一番初めの送信元になる）ので、「Routed」フィールドは後述するステップＳ２３及びＳ２５の段階では生成されないことになる。
【０２０３】
このように、本発明において用いられる各種メッセージＭＳＧには全て、各ノードＮが持つカタログ中の最大シリアル番号cont_sn_maxが記述されているのである。
【０２０４】
図９（ａ）に戻って、上記ステップＳ２１の判定において、記録指示メッセージＲＩｍｓｇ内のシリアル番号の値の方が大きいときは（ステップＳ２１；ＹＥＳ）、新たなカタログレコードＣＴＧＲがシステム管理者によって追加されて来たということであるから、そのカタログレコードＣＴＧＲを用いてその時点で記憶部１２に記憶されているカタログを更新し（ステップＳ２２）、更に、その更新後の新しいカタログにおける最大のシリアル番号の値（即ち、上記記録指示メッセージＲＩｍｓｇ内のシリアル番号の値）を含む上記メッセージヘッダＭＨＤを生成する（ステップＳ２３）。
【０２０５】
なお、上記ステップＳ２１の処理において記録指示メッセージＲＩｍｓｇ内のシリアル番号の値の方が大きくないと判定されるのは、既に配信システムＳ中に配信済みのコンテンツを記録すべき旨の記録指示メッセージＲＩｍｓｇが届いたときである。これは、人気のあるコンテンツの複製を、システム管理者側が余分に用意したいといった場合に行われるものである。
【０２０６】
次に、ステップＳ２１において判定したシリアル番号の大小関係において、比較対象となった二つのシリアル番号が連続したか否かを確認する（ステップＳ２６）。そして、当該確認の結果、それらが連続しているときは（ステップＳ２６；ＮＯ）、次に、図１及び図２を用いて示した配信システムＳとしての規則に則り、当該コンテンツホルダＣＨとなったノードＮがそのコンテンツに対応するルートノードＲＮを兼務するか否かを確認し（つまり、投入されたコンテンツのコンテンツＩＤが、自分のノードＩＤに近接しており、更にＤＨＴを参照しても転送すべきノードＮが他に発見できないときに、ルートノードＲＮとなる。ステップＳ２８）、ルートノードＲＮとはならないときは（ステップＳ２８；ＮＯ）、上記ステップＳ２５又はＳ２３の処理により生成したメッセージヘッダＭＨＤをその先頭に含む上記公開メッセージＰＵＢｍｓｇを生成して配信システムＳ内に送信し（ステップＳ２９）、コンテンツホルダＣＨとしての次の処理（例えば、上記リクエスタＲＱからの配信要求メッセージに対応する配信処理等）に備えて待機状態に入る。
【０２０７】
他方、上記ステップＳ２８の判定において、ルートノードＲＮとしての機能を兼務するときは（ステップＳ２８；ＹＥＳ）、そのまま処理を終了する。
【０２０８】
更に、上記ステップＳ２６の判定において、ステップＳ２１の判定において比較対象となった二つのシリアル番号が連続していない（即ち、それらの間に「中抜け」がある）ときは（ステップＳ２６；ＹＥＳ）、図８ステップＳ３４の処理と同様に、例えば図９（ａ）に示す処理が実行されているノードＮの電源が一時的にオフとされている間に投入された他のコンテンツ及び対応するカタログレコードＣＴＧＲが他のノードＮに存在するということを意味するので、上記ステップＳ３４の処理と同様にして、当該他のノードＮから中抜け部分に相当するカタログレコードＣＴＧＲを取得する。
【０２０９】
そして、当該中抜け部分に相当するカタログレコードＣＴＧＲがいずれかのノードＮから返信されて来たとき、当該送信されて来たカタログレコードＣＴＧＲをもって記憶部１２内のカタログレコードＣＴＧＲを更新し（ステップＳ２７）、上記ステップＳ２８の処理に移行する。
【０２１０】
次に、上記ステップＳ３４及びＳ２７における差分取得処理について、具体的な例として図１２（ａ）を用いて説明する。
【０２１１】
即ち、メッセージＭＳＧ（上記記録指示メッセージＲＩｍｓｇ（ステップＳ２７の場合）を含む）受信前の時点で記憶部１２内に記憶されているカタログレコードＣＴＧＲにより構成されるカタログが、図１２（ａ）に示すカタログリストＣＴＧＬ１であり、そのときに記録指示メッセージＲＩｍｓｇに含まれていたシリアル番号が「１０１１」であるとすると、上記ステップＳ３４及びＳ２７が開始される時点では、図１２（ａ）に示すカタログリストＣＴＧＬ２のようになり、シリアル番号「１００９」と「１０１０」が中抜けであると判定される（上記ステップＳ２６；ＹＥＳ、Ｓ３３；ＹＥＳ参照）。
【０２１２】
そこで、コンテンツホルダＣＨとなるノードＮ自身が認識していない他のカタログレコードＣＴＧＲが配信システムＳ内に存在していることを認識した当該ノードＮから、上記中抜け部分に相当するシリアル番号を含むカタログレコードＣＴＧＲの取得メッセージを他のノードＮに送信する（当該送信時における宛先のノードＩＤ自体は、例えばランダムに設定することができる）。この場合は、シリアル番号「１００９」と「１０１０」のカタログレコードＣＴＧＲを、当該他のノードＮに要求することになる。
【０２１３】
そして、当該取得メッセージは、上記ＤＨＴのルーティング動作に従って複数のノードＮに転送されていくが、それを受信した他のノードＮのうち、当該中抜け部分に相当するカタログレコードＣＴＧＲを記憶しているノードＮ（当該ノードＮ内に記憶されているカタログレコードＣＴＧＲとしては、そのシリアル番号が例えば「１００５」から「１０１１」まで連続したものが記憶されていることになる）は、その中抜け部分に相当するカタログレコードＣＴＧＲを含む差分データリストＣＴＧＬ−Ｓ（図１２（ａ）参照）を生成し、上記取得メッセージを送信したノードＮに返信する。
【０２１４】
これにより、当該差分データリストＣＴＧＬ−Ｓの返信を受けたノードＮ（コンテンツホルダＣＨ）は、自身の記憶部１２内に記憶されているカタログリストＣＴＧＬ２に差分データリストＣＴＧＬ−Ｓを合成し、その時点で最新のカタログを形成して記憶し直す。これにより、上記ステップＳ３４及びＳ２７が終了した時点でそのノードＮ内に記憶されているカタログでは、シリアル番号が、例えば「１００５」から「１０１１」まで連続していることになる。
【０２１５】
なお、カタログレコードＣＴＧＲの取得メッセージを送信した場合であっても、その取得メッセージを受信したいずれのノードＮも要求したカタログレコードＣＴＧＲを記憶してないこともあり得るが、その場合には当該「記憶していない」旨の返信が返るので、宛先のノードＩＤを別なランダムなノードＩＤに変えて、再試行することになる。
【０２１６】
なお、図１２（ａ）を用いた上述の説明では、カタログレコードＣＴＧＲの取得メッセージをランダムなノードＩＤ宛に送ったが、これを、中抜けのシリアル番号（複数ある場合は最大値）に対応するコンテンツのルートノードＲＮ宛としても良い。この場合は、当該ルートノードＲＮが最新のカタログを記憶している確率が高いので、上記のような「記憶していない」旨の返信が返ることは少なくなり、無駄な再試行を減らすことができる。
【０２１７】
しかしながらその一方で、最近の投入コンテンツに対するルートノードＲＮに、カタログレコードＣＴＧＲの取得メッセージが集中して到着することになり、当該ルートノードＲＮにおける処理負荷が過大になる可能性がある。これを回避するには、「コンテンツの投入日時」なる項目をカタログレコードＣＴＧＲに追加し、更に「cont_sn_max」に併記する形で、「最大シリアル番号に対応するコンテンツの投入日時」をメッセージヘッダＭＨＤにも追加し、各ノードＮはこれを受信した際に、投入日時から時間が経過していなければ（例えば３日経過していなければ）ルートノードＲＮ宛に送り、当該時間が経過していればランダムＩＤ宛に送るという方法を取れることが考えられる。
【０２１８】
以上のステップＳ３４及びＳ２７を含む動作が実行されることで、新たなコンテンツホルダＣＨとしてのカタログレコードＣＴＧＲの更新が完了する。また、新規投入されたコンテンツのカタログレコードＣＴＧＲは、初めはこのノードＮにしか存在しないが、先に説明したように、このノードＮが送信するメッセージＭＳＧ中の最新のシリアル番号を他のノードＮが検知するように構成することにより、最新のカタログレコードＣＴＧＲは、徐々に配信システムＳ内に拡散していくことになる。上記図８及び図９を用いて説明した処理では、最新のカタログレコードＣＴＧＲは、初めに公開メッセージＰＵＢｍｓｇにより伝播しているので、その転送経路にあるノードＮが、いち早く最新のカタログレコードＣＴＧＲに気付くことになり、この転送経路上のノードＮから順に、拡散されていく。
【０２１９】
（Ｂ）リクエスタとしての動作
次に、実施形態に係るリクエスタＲＱ（図２参照）としてのノードＮにおけるコンテンツの発見及びその再生動作（図５ステップＳ１３参照）の詳細を、図１０を用いて具体的に説明する。なお、図１０は当該リクエスタＲＱとしてのコンテンツ発見・再生処理の動作を示すフローチャートである。
【０２２０】
なお、図１０に示す処理が実行される前提として、リクエスタＲＱの使用者が図７を用いて説明した検索画面を用いることにより、いずれのコンテンツに対して配信要求をするか、が確定した状態（即ち、図６を用いて説明したスレッドによりコンテンツの選択が完了している状態）であるとする。
【０２２１】
リクエスタＲＱにおけるコンテンツ発見・再生処理としては、図１０に示すように、先ず、使用者が選択したコンテンツのコンテンツＩＤを、配信元問い合わせメッセージＱＲｍｓｇの例えば「Contents_Id」フィールド内に記述して、対応するルートノードＲＮに向けて送信する（ステップＳ４０）。即ち、ＤＨＴのルーティングテーブルを参照して、コンテンツＩＤに一番近い値のノードＩＤを有するノードＮに対して、上記配信元問い合せメッセージＱＲｍｓｇを送信する。そして、当該送信された配信元問い合せメッセージＱＲｍｓｇは、転送順序上の次のノードＮでも同様に転送処理され、最終的にルートノードＲＮに辿り着く。
【０２２２】
次に、当該配信元問い合わせメッセージＱＲｍｓｇを受信したルートノードＲＮは、自身に記憶されているインデックスキャッシュを参照して、当該コンテンツを蓄積しているノードＮのＩＰアドレスを返答して来るので、リクエスタＲＱでは当該問い合わせ応答メッセージを待つ（ステップＳ４１；ＮＯ）。
【０２２３】
そして、当該問い合わせ応答メッセージを受信したら（ステップＳ４１；ＹＥＳ）、その中に対応するコンテンツホルダＣＨを示すＩＰアドレスが記述されているはずであるので（ステップＳ４２）、当該ＩＰアドレスに基づき、そのコンテンツホルダＣＨとしてのノードＮに向けて、今度は上記配信要求メッセージを送信する（ステップＳ４３）。
【０２２４】
次に、当該配信要求メッセージを受信したコンテンツホルダＣＨは、当該配信要求メッセージの送信元であるリクエスタＲＱに向けてコンテンツ本体としてのコンテンツデータを送信してくるので、当該リクエスタＲＱはこれを受信する（ステップＳ４４）。
【０２２５】
そして、全てのコンテンツデータの受信が完了したら（ステップＳ４５；ＹＥＳ）、その再生処理（視聴処理）を行い（ステップＳ４６）、コンテンツデータの最後まで再生し終わったら（ステップＳ４７；ＹＥＳ）、リクエスタＲＱとしてのコンテンツ発見・再生処理を完了する。
【０２２６】
なお、図１０に示すコンテンツ発見・再生処理において、上述した検索画面（図７参照）と再生画面（コンテンツとしての画像が表示される画面）とは、夫々別個に表示部１６上に表示可能とするのが好ましい。即ち、当該コンテンツの再生中においても検索画面を表示させることができるように構成することが望ましい。このための構成として具体的には、例えば、上記再生画面の上にオーバーレイ表示（スーパーインポーズ表示）にて上記検索画面を重ねて表示するように構成しても良いし、或いは、表示部１６における一つの画面を二分割して夫々検索画面と再生画面とする構成でも良い。或いは、表示部１６を例えばＣＲＴ（Cathode Ray Tube）ディスプレイと液晶ディスプレイの二画面構成とし、夫々に検索画面又は再生画面のいずれか一方を表示させるように構成しても良い。
【０２２７】
更には、コンテンツの再生途中で、その再生を中止させるように構成することも可能である。
【０２２８】
（Ｃ）一般のノードとしての最適化処理の動作
次に、配信システムＳ内の各ノードＮにおいて実行される、上記配信許可フラグを用いた実施形態に係るカタログの最適化処理の動作について、図１１及び図１２（ｂ）を用いて説明する。なお、図１１は当該最適化処理の動作を示すフローチャートである。
【０２２９】
以下に説明する最適化処理は、各ノードＮにおいて、非公開とされたコンテンツを示すカタログレコードＣＴＧＲを記憶部１２内から削除することで、実際に再生（視聴）が可能なコンテンツに対応するカタログレコードＣＴＧＲのみを含むカタログを記憶部１２内に記憶させる処理である。
【０２３０】
ここで、当該最適化処理は、今まで上記配信許可フラグの値が「Ｅ」であったコンテンツに対して、当該コンテンツに対応し且つ配信許可フラグの値が「Ｄ」であるカタログレコードＣＴＧＲを新たに記録指示メッセージＲＩＭＧとして配信システムＳ内に投入することで公開済みのコンテンツを非公開にした場合、カタログの中に無駄な（即ち、公開不可能なコンテンツに対応する）カタログレコードＣＴＧＲが増えていくため、これを削除して記憶部１２の無駄な使用を抑制するためのものである。
【０２３１】
当該最適化処理は、予め設定された期間毎、又は予め設定された時刻毎、或いは、そのノードＮに記憶されているカタログリスト（図１２（ａ）参照）が更新される度、の少なくともいずれか一つのタイミングにおいて開始される。
【０２３２】
即ち、図１１に示すように、当該最適化処理においては、先ず、その時に記憶部１２内に記憶されているカタログレコードＣＴＧＲの番号（シリアル番号順に並べたときの先頭からの番号）を示すパラメータＩを初期化し（ステップＳ５０）、次に、Ｉ番目のカタログレコードＣＴＧＲにおける配信許可フラグの内容を確認する（ステップＳ５１）。そして、その内容が「Ｄ」でないときは（ステップＳ５１；ＮＯ）、パラメータＩの値をインクリメントし（ステップＳ５３）、更にそのインクリメント後のパラメータＩの値がその時に記憶部１２に記憶されている全カタログレコードＣＴＧＲの数より大きくなったか否かを確認する（ステップＳ５４）。
【０２３３】
ステップＳ５４の判定において、パラメータＩの値が当該全カタログレコードＣＴＧＲの数よりも大きくなっているときは（ステップＳ５４；ＹＥＳ）、現状では当該ノードＮが認識している全てのコンテンツが公開可能であって最適化処理の必要がないことになるので、そのまま当該最適化処理を完了する。
【０２３４】
一方、ステップＳ５４の判定において、パラメータＩの値が当該全カタログレコードＣＴＧＲの数よりも大きくなっていないときは（ステップＳ５４；ＮＯ）、当該インクリメント（ステップＳ５３）後のパラメータＩの値に相当するカタログレコードＣＴＧＲについて上記ステップＳ５１乃至Ｓ５４を実行すべく、当該ステップＳ５１の処理に戻る。
【０２３５】
他方、上記ステップＳ５２の判定において、その値が「Ｄ」である（即ち、新たに配信禁止となった）配信許可フラグを有するカタログレコードＣＴＧＲが発見されたときは（ステップＳ５２；ＹＥＳ）、次に、現在記憶部１２内に記憶されているカタログの中から削除されるべきコンテンツのコンテンツＩＤを示すパラメータdel_IDの値を、その配信許可フラグが「Ｄ」となっているコンテンツのコンテンツＩＤと同値とし（ステップＳ５５）、更に、上記パラメータＩと同様にその時に記憶部１２内に記憶されているカタログレコードＣＴＧＲの番号を示す他のパラメータＪを初期化し（ステップＳ５６）、Ｊ番目のカタログレコードＣＴＧＲにおける配信許可フラグの内容を確認する（ステップＳ５７）。
【０２３６】
次に、当該配信許可フラグの内容を確認したコンテンツのコンテンツＩＤが、その時点でのパラメータdel_IDの値を等しく（ステップＳ５８；ＹＥＳ）、且つその確認した配信許可フラグの値が「Ｅ」であるときは（ステップＳ５９；ＹＥＳ）、当該Ｊ番目のカタログレコードＣＴＧＲを削除し（ステップＳ９０）、パラメータＪの値をインクリメントする（ステップＳ９１）。そして、インクリメント後のパラメータＪの値がその時のパラメータＩの値以上となっているときは（ステップＳ９２；ＹＥＳ）、上記ステップＳ５１に戻って現在のパラメータＩの値で示される番号のカタログレコードＣＴＧＲについて上記ステップＳ５１乃至Ｓ９２の処理を繰り返す。
【０２３７】
一方、ステップＳ５８の判定において当該配信許可フラグの内容を確認したコンテンツのコンテンツＩＤが、その時点でのパラメータdel_IDの値を等しくないか（ステップＳ５８；ＮＯ）、又は上記ステップＳ５９の判定において、その確認した配信許可フラグの値が「Ｅ」でない場合は（ステップＳ５９；ＮＯ）、そのまま上記ステップＳ９１に移行する。
【０２３８】
以上説明した処理により、その時に記憶部１２内に記憶されているカタログの先頭から末尾までを順に検索し、その配信許可フラグの値が「Ｄ」であるコンテンツレコードＣＴＧＲが発見されたら（上記ステップＳ５２；ＹＥＳ参照）、そのコンテンツレコードＣＴＧＲのコンテンツＩＤと同じ値のコンテンツＩＤを有するコンテンツであって且つその配信許可フラグの値が「Ｅ」のカタログレコードＣＴＧＲがないかを、当該カタログの先頭から配信許可フラグが「Ｄ」であるカタログレコードＣＴＧＲが発見された位置まで検索して、当該配信許可フラグが「Ｅ」であるコンテンツレコードＣＴＧＲを削除することができる。
【０２３９】
次に、図１１に示した最適化処理について、具体的に図１２（ｂ）を用いて説明する。
【０２４０】
それまで公開可（即ち、配信許可フラグ＝「Ｅ」）だったコンテンツ（図１２（ｂ）に示す例においては、コンテンツＩＤが「４８７５」であるコンテンツ）が新たに公開不可（即ち、配信許可フラグ＝「Ｄ」）となった場合、その旨を示すカタログレコードＣＴＧＲは、新たなカタログレコードＣＴＧＲの更新として、図１２（ｂ）に例示するように同一のコンテンツＩＤに対して異なるシリアル番号（更に大きなシリアル番号。図１２（ｂ）に例示する場合はシリアル番号「１０１１」）が付加され、記録指示メッセージＲＩｍｓｇとして送信されて来る。
【０２４１】
そこで、図１１に示した処理では、図１２（ｂ）にハッチングで示す二つのカタログレコードＣＴＧＲのうち、シリアル番号「１００６」のカタログレコードをカタログリストＣＴＧＬ３内から削除する（ステップＳ９０）。
【０２４２】
以上の最適化処理により、各ノードＮにおいて、常に最新の公開可能なコンテンツに対応するカタログレコードＣＴＧＲのみを含むカタログが維持・記憶されることとなる。
【０２４３】
なお、上記最適化処理を行うと、カタログリストＣＴＧＬ内に中抜け部分がある状態（図１２（ａ）参照）ができることになる。そして、この中抜け部分については、一見すると再び上記差分取得処理（図８ステップＳ３４又は図９ステップＳ２７参照）により元に（連続するシリアル番号に）戻ってしまうように見えるが、図９ステップＳ２６又は図８ステップＳ３３の処理で中抜け部分があるか否かの判定時には、自己の持つカタログ内の最大シリアル番号より大きい範囲で当該判定を行っているので、そのようなことは起こらない。
【０２４４】
以上夫々説明したように、実施形態に係る各ノードＮ（コンテンツホルダＣＨ及びリクエスタＲＱを含む）における動作によれば、新たなコンテンツがコンテンツホルダＣＨ内に蓄積されたとき、各ノードに記憶されているカタログ内のシリアル番号の連続性を手掛かりに各ノードＮのカタログが更新されるので、配信システムＳ内におけるカタログを常に最新の状態に維持してコンテンツの配信に供させることができる。
【０２４５】
また、新たなコンテンツの蓄積に合わせて、各ノードＮ内のカタログが当該各ノードＮにおいて自律的に更新されることとなるので、当該カタログの更新・管理用に別途サーバ装置等を配信システムＳ内に設ける必要がない。新たなコンテンツが当該コンテンツホルダＣＨ内に蓄積されたとき、当該新たなコンテンツに対応するカタログレコードＣＴＧＲ及びシリアル番号を含む公開メッセージＰＵＢｍｓｇをネットワークを介してルートノードＲＮに配信するので、公開メッセージＰＵＢｍｓｇの転送経路上の各ノードＮにおいて、シリアル番号の連続性を手掛かりにカタログを更新することで、複数のノードＮのカタログを常に最新の状態に維持してコンテンツの配信に供させることができる。
【０２４６】
また、これらのノードＮが発するメッセージＭＳＧには、最新のシリアル番号が付加されて送信されるので、これを受信したノードＮもまた、カタログを最新状態に更新することとなり、配信システムＳ内の全てのノードＮのカタログが、次第に最新状態に更新されるようになる。これによりに、コンテンツの投入後の各ノードＮ間のメッセージ交換により、各ノードＮ内のカタログが当該各ノードＮにおいて自律的に更新されることとなるので、当該カタログの更新・管理用に別途サーバ装置等を配信システムＳ内に設ける必要がない。
【０２４７】
更にまた、新たなコンテンツがコンテンツホルダＣＨ内に蓄積されたとき、シリアル番号の連続性を確認して各ノードＮのカタログが更新され、更に当該更新されたカタログが使用者に対して告知されるので、使用者は、どのコンテンツの配信を希望するかを選択する際に、最新のカタログを用いて選択することができる。
【０２４８】
従って、配信システムＳとしての維持管理等について不要なコスト及び労力を要することなく各ノードＮにおけるカタログを常に最新の状態に維持できることで、配信システムＳにおけるコンテンツの配信に対して利便性及び信頼性を向上させつつ当該配信を行うことができる。
【０２４９】
また、新たに蓄積されるコンテンツに対応するシリアル番号との関係で既存のコンテンツに対応するシリアル番号との間に連続性が認められるとき、当該コンテンツホルダＣＨ内に記憶されている最大シリアル番号を、新たに蓄積されるコンテンツに対応するシリアル番号を用いて更新するので、コンテンツホルダＣＨに対して新たなコンテンツが蓄積されたとき、迅速且つ自律的に当該コンテンツホルダＣＨ内に記憶されているカタログを更新することができる。
【０２５０】
更に、カタログレコードＣＴＧＲが他のノードＮから送信されて来たとき、それに含まれているシリアル番号との連続性を確認し、当該連続性が確認されたとき、その送信されて来たシリアル番号を用いて今までの最大シリアル番号を更新するので、自律的に各ノードＮ内のカタログを更新することができる。
【０２５１】
また、他のノードＮから送信されて来たカタログレコードＣＴＧＲに対応するシリアル番号との連続性が確認されないとき、その連続性の中断部分に対応するカタログレコードリストＣＴＧＲＬを、他のノードＮから取得して埋め合わせるので、各ノードＮにおいて、自律的にカタログの連続性を維持させることができる。
【０２５２】
更に、カタログレコードＣＴＧＲ内に含まれている配信許可フラグにより配信されるべきとされているコンテンツに対応するカタログレコードＣＴＧＲの情報のみが告知（表示）されるので、一旦公開したコンテンツを、著作権保持者の都合等により、必要に応じて非公開とすることができる。
【０２５３】
更にまた、一旦公開された後に配信許可フラグにより配信されるべきものではないとされているコンテンツに対しては、複数のカタログレコードＣＴＧＲが存在することになるが、不要なカタログレコードＣＴＧＲが適宜削除されるので、カタログが無駄に肥大化することを防止しつつ、効率的にコンテンツの検索を行うことができる。
【０２５４】
また、他のノードＮに対してメッセージＭＳＧを送信する際に、記憶部１２に記憶されている最新のシリアル番号を付加して送信するので、当該最新のシリアル番号を取得した当該他のノードＮにおいて、いずれかのメッセージＭＳＧを取得する度に当該他のノードＮ内に記憶されているカタログを更新することで、当該カタログを自律的に最新の状態に維持することができる。
【０２５５】
更に、いずれかのメッセージＭＳＧを取得したとき、それに含まれている最新のシリアル番号との関係で自己の記憶部１２内に記憶されているカタログが最新のものであるか否かを判定し、最新のものでない場合は当該最新のカタログと自己が持つカタログとの差分のカタログレコードリストＣＴＧＲＬを他のノードＮから取得するので、自律的に最新の状態に維持することができる。
【０２５６】
なお、上述して来た実施形態では、再生すべきコンテンツを配信システムＳにおいて検索する際に本発明を適用する場合について説明したが、これ以外に、単に所望のコンテンツの配信のみを受けてこれを記録する場合に本発明を適用することも可能である。
【０２５７】
更に、上述した図５、図６及び図８乃至図１１に示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係るコンテンツホルダＣＨ、リクエスタＲＱ及び他のノードＮ内の制御部１１として夫々機能させることも可能である。
【０２５８】
更に、コンテンツの配信システムＳへの初期投入を記録指示メッセージＲＩｍｓｇとは別の方法で、例えば、ＣＤ−ＲＯＭ（Compact Disk - Read Only Memory）を、ノードＮの使用者に対して郵送して当該ノードＮに蓄積させる、という方式にすることも可能である。この場合は、図９（ａ）に示すフローチャートに対応する処理は、当該ＣＤ−ＲＯＭのノードＮにおける読み込みが完了して、新規コンテンツが当該ノードＮに記憶されたのをきっかけに開始されるように構成するのが好適である。
【０２５９】
或いは、各ノードＮがいわゆるＦＴＰ（File Transfer Protocol）サーバを機能させているという前提で、投入センタがＦＴＰクライアントとして当該ＦＴＰサーバに接続し、新規コンテンツファイルをＦＴＰで記録させる、という方法でも、新規投入が可能である。
【産業上の利用可能性】
【０２６０】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【０２６１】
【図１】実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である。
【図２】実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】本発明の原理を説明する図である。
【図４】実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図５】実施形態に係るノードにおける共通動作の全体を示すフローチャートである。
【図６】実施形態に係るノードにおける共通動作の細部を示すフローチャートである。
【図７】実施形態に係る検索画面等の構成を例示する図であり、（ａ）は当該検索画面の内容を例示する図であり、（ｂ）は一覧表の内容を例示する図である。
【図８】実施形態に係る一般のノードにおけるメッセージ処理の動作を示すフローチャートである。
【図９】実施形態に係るコンテンツホルダにおける記録指示メッセージの受信処理を示すフローチャート等であり、（ａ）は当該フローチャートであり、（ｂ）はメッセージヘッダの内容を例示する図である。
【図１０】実施形態に係るリクエスタにおけるコンテンツの取得／再生処理の動作を示すフローチャートである。
【図１１】実施形態に係る一般のノードにおける最適化処理の動作を示すフローチャートである。
【図１２】実施形態に係るカタログデータの更新等を例示する図であり、（ａ）は当該カタログデータの更新を例示する図であり、（ｂ）はカタログデータの最適化処理を例示する図である。
【符号の説明】
【０２６２】
１１    制御部
１２    記憶部
１３    バッファメモリ
１４    デコーダ部
１５    映像処理部
１６    表示部
１７    音声処理部
１８    スピーカ
２０    通信部
２１    入力部
２２    バス
３０    表題欄
３１    タイトル入力欄
３２、３３    名前入力欄
３４    キーワード入力欄
３５    検索操作ボタン
３６    一覧表示操作ボタン
３７、３８    情報表示欄
３９    操作ボタン
４０    終了ボタン
４１、４２    上下キー
４３    視聴ボタン
４４    戻るボタン
ＬＴ    一覧表
Ｒc、Ｒn    リング
ＥＸ    インデックス情報
ＣＨ    コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３    リクエスタ
ＲＮ    ルートノード
ＣＮ    キャッシュノード
ＰＵＢｍｓｇ    公開メッセージ
ＱＲｍｓｇ    配信元問い合わせメッセージ
Ｎ    ノード
Ｓ    配信システム
ＳＶ    サーバ
ＣＴＧＲ    カタログレコード
ＲＩｍｓｇ    記録指示メッセージ
ＭＳＧ    メッセージ
ＭＨＤ    メッセージヘッダ
ＣＴＧＬ１、ＣＴＧＬ２、ＣＴＧＬ３    カタログリスト
ＣＴＧＬ−Ｓ    差分データリスト
【図１】
0004779733.tif 000002
【図２】
0004779733.tif 000003
【図３】
0004779733.tif 000004
【図４】
0004779733.tif 000005
【図５】
0004779733.tif 000006
【図６】
0004779733.tif 000007
【図７】
0004779733.tif 000008
【図８】
0004779733.tif 000009
【図９】
0004779733.tif 000010
【図１０】
0004779733.tif 000011
【図１１】
0004779733.tif 000012
【図１２】
0004779733.tif 000013