JP2010238143A - ノード装置、ノード処理プログラム及び検索方法 - Google Patents

Abstract

【課題】ノード装置自身が、カタログ検索がされる可能性が高いコンテンツデータのカタログ情報を記憶して、その検索を簡便かつ迅速に実行する。
【解決手段】ネットワークを介して互いに通信可能な複数のノード装置を備え、複数のコンテンツデータにそれぞれに対応する検索情報を各ノード装置間で分散して保存する情報通信システムに含まれるノード装置であって、コンテンツデータの公開日時を表す公開日時情報を含む検索情報を取得し、その検索情報が所定の規則に従って定められた担当範囲の検索情報であると判定された場合、その検索情報を担当検索情報記憶手段に記憶し、また、取得された検索情報が、新規公開予定のコンテンツデータの検索情報であると判定された場合、その検索情報を新規公開検索情報記憶手段に記憶し、担当検索情報記憶手段または新規公開検索情報記憶手段に記憶された検索情報に基づいて、コンテンツデータを検索する。
【選択図】図３

Description

本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型のコンテンツ配信システムに関する。特に、本発明は、複数のコンテンツデータが複数のノード装置に分散して保存されたコンテンツ配信システム等の技術分野に関する。

一般的に、この種のコンテンツ配信システムは、複数のノード装置により構成される。コンテンツデータは、複数のノード装置に分散保存されている。特許文献１には、コンテンツ配信システムの各ノード装置がコンテンツカタログ情報を有する技術が開示されている。コンテンツカタログ情報は、コンテンツデータの属性情報（例えば、コンテンツ名、ジャンル、アーティスト名等）が記述された情報である。各ノード装置は、コンテンツカタログ情報を取得する。当該コンテンツカタログ情報に記述された属性情報に基づき、各ノード装置は、ユーザーが所望するコンテンツデータを取得することが可能になっている。このようなコンテンツカタログ情報は、複数のノード装置において共通に使用される共用情報である。

具体的に特許文献１には、各ノード装置が所定の規則に従って定められた担当範囲のコンテンツデータのカタログ情報を分散して記憶することが開示されている。各ノード装置間でカタログ検索要求が行われることで、コンテンツデータのカタログ情報を互いに利用し合うことで、検索が実行される。

特開２００７−２８０３０３号公報

新規に公開されるコンテンツデータは、一般的に多数のノード装置から取得を要求される。新規に公開されるコンテンツデータを取得する場合も、特許文献１に記載される方法でコンテンツデータが検索される。しかしながら、各ノード装置は、各ノード装置自身が担当する範囲のコンテンツデータの属性情報しか記憶していない。そのため、新規に公開されるコンテンツデータを取得するとき、新規に公開されるコンテンツデータを要求する多数のノード装置からカタログ検索の要求が行われる。ネットワークを介して他のノード装置へカタログ検索要求が頻繁に行われるため、ネットワーク負荷が増大するという問題が生じていた。

本発明は、以上の点等に鑑みてなされたものであり、ノード装置自身が、カタログ検索がされる可能性が高いコンテンツデータのカタログ情報を記憶して、カタログ検索処理を簡便かつ迅速に実行することができるノード装置、ノード処理プログラム、検索方法を提供することを課題とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備え、前記複数のノード装置間で利用可能な複数のコンテンツデータにそれぞれに対応する検索情報を各前記ノード装置間で分散して保存する情報通信システムに含まれる前記ノード装置であって、少なくとも前記コンテンツデータの公開日時を表す公開日時情報を含む前記検索情報を取得する検索情報取得手段と、前記検索情報取得手段により取得された検索情報が、所定の規則に従って定められた担当範囲の検索情報であるか否かを判定する検索情報判定手段と、前記検索情報判定手段により、前記担当範囲であると判定された検索情報を記憶する担当検索情報記憶手段と、前記公開日時情報に基づいて、前記取得された検索情報が、新規公開予定のコンテンツデータの検索情報であるか否かを判定する判定手段と、前記判定手段により新規公開予定のコンテンツデータの検索情報であると判定された場合、前記取得された検索情報を記憶する新規公開検索情報記憶手段と、前記担当検索情報記憶手段または前記新規公開検索情報記憶手段に記憶された検索情報に基づいて、前記コンテンツデータを検索するコンテンツデータ検索手段と、を有することを特徴とするノード装置である。

上記課題を解決するために、請求項２に記載の発明は、請求項１に記載のノード装置において、前記検索情報判定手段により、前記担当範囲の検索情報でないと判定されたとき、前記新規公開検索情報記憶手段は、前記判定された検索情報を記憶することを特徴とするノード装置である。

上記課題を解決するために、請求項３に記載の発明は、請求項１または請求項２に記載のノード装置において、前記新規公開検索情報記憶手段に前記検索情報を記憶できる所定の記憶容量があるか否かを判定する記憶判定手段と、前記記憶判定手段により、前記所定の記憶容量がないと判定されたとき、所定の規則に従って前記新規公開検索情報記憶手段から所定の前記検索情報を削除する検索情報削除手段とを備えることを特徴とするノード装置である。

上記課題を解決するために、請求項４に記載の発明は、請求項３に記載のノード装置において、現在の日時を表す現在日時情報を取得する現在日時取得手段を備え、前記検索情報削除手段は、前記所定の規則として前記現在日時情報と前記公開日時情報との時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置である。

上記課題を解決するために、請求項５に記載の発明は、請求項４に記載のノード装置において、前記検索情報削除手段は、前記現在日時情報より前記公開時刻情報が過去の日時であり、且つ、前記時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置である。

上記課題を解決するために、請求項６に記載の発明は、請求項４に記載のノード装置において、前記検索情報削除手段は、前記現在日時情報より前記公開時刻情報が未来の日時であり、且つ、前記時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置である。

上記課題を解決するために、請求項７に記載の発明は、請求項１乃至請求項６の何れか一項に記載のノード装置において、前記新規公開検索情報記憶手段の記憶可能容量は、担当検索情報記憶手段の記憶可能容量よりも大きいことを特徴とするノード装置である。

上記課題を解決するために、請求項８に記載の発明は、コンピュータを、請求項１乃至７の何れか一項に記載のノード装置として機能させることを特徴とするノード処理プログラムである。

上記課題を解決するために、請求項９に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備え、前記複数のノード装置間で利用可能な複数のコンテンツデータにそれぞれに対応する検索情報を各前記ノード装置間で分散して保存する情報通信システムに含まれる前記ノード装置における検索方法であって、少なくとも前記コンテンツデータの公開日時を表す公開日時情報を含む前記検索情報を取得する工程と、取得された検索情報が、所定の規則に従って定められた担当範囲の検索情報であるか否かを判定する工程と、前記担当範囲であると判定された検索情報を担当検索情報記憶手段に記憶する工程と、前記公開日時情報に基づいて、前記取得された検索情報が、新規公開予定のコンテンツデータの検索情報であるか否かを判定する工程と、新規公開予定のコンテンツデータの検索情報であると判定された場合、前記取得された検索情報を新規公開検索情報記憶手段記憶する工程と、前記担当検索情報記憶手段または前記新規公開検索情報記憶手段に記憶された検索情報に基づいて、前記コンテンツデータを検索する工程と、を有することを特徴とする検索方法である。

本発明によれば、検索される可能性が高い新規公開予定のコンテンツのカタログ情報を記憶したので、簡便かつ迅速にコンテンツデータの検索を行なうことができる。

本実施形態に係るデータファイル分散保存システムＳにおける各ノード装置の接続態様の一例を示す図である。 ノードＮｎの概要構成例を示すブロック図である。 ノードＮｎにおける制御部１１のメイン処理を示すフローチャートである。 ステップＳ１６の「レコード保存処理（Ａ）」を示すフローチャートである。 ステップＳ１８、ステップＳ８５の「レコード保存処理（Ｂ）」を示すフローチャートである。 ステップＳ３５、ステップＳ４４の「新規公開カタログ保存処理」を示すフローチャートである。 ステップＳ２３の「メッセージ受信処理」を示すフローチャートである。 ステップＳ６４の「カタログ更新処理」を示すフローチャートである。 ステップＳ６９の「事前保存処理」を示すフローチャートである。

以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態では、コンテンツ分散保存システムを本発明の情報通信システムの一例として説明する。

１．コンテンツ分散保存システムの構成及び動作概要
始めに、図１等を参照して、本実施形態に係るコンテンツ分散保存システムＳの構成及び動作概要について説明する。

図１は、本実施形態に係るコンテンツ分散保存システムＳにおける各ノード装置の接続態様の一例を示す図である。

図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４ａ、４ｂ、ＤＳＬ（Digital Subscriber Line）回線事業者の装置５ａ、５ｂ、ＦＴＴＨ（Fiber To The Home）回線事業者の装置６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク８が構築されている。なお、図１の例におけるネットワーク８には、データをパケット転送するためのルータが、適宜挿入されているが図示を省略している。また、ネットワーク８は、現実世界の通信ネットワークである。

このようなネットワーク８には、複数のノード装置Ｎｎ（ｎ＝１，２，３・・・の何れか）が接続されている。なお、ノード装置Ｎｎは、以下の説明において、ノードと言う。

また、各ノードＮｎには、固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。そして、本実施形態に係るコンテンツ分散保存システムＳは、これらのノードＮｎのうち、図１の上部枠１００内に示すように、何れか複数のノードＮｎの参加により形成されるピアツーピア方式のネットワークシステムとなっている。

なお、図１の上部枠１００内に示すネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するオーバーレイネットワーク９であり、論理的なネットワークである。かかるオーバーレイネットワーク９は、特定のアルゴリズム、例えば、ＤＨＴを利用したアルゴリズムにより実現される。そして、コンテンツ分散保存システムＳに参加している各ノードＮｎには、所定桁数からなる固有の識別情報であるノードＩＤが割り当てられている。なお、“コンテンツ分散保存システムＳに参加している”とは、言い換えれば、“オーバーレイネットワーク９に参加している”ことと同義である。なお、ノードＩＤはノード装置識別情報の一例である。

また、ノードＩＤは、例えば、各ノードＮｎに個別に割り当てられたＩＰアドレス或いは製造番号を共通のハッシュ関数によりハッシュ化した値である。例えば、ハッシュ関数ＳＨＡ−１等により得たｂｉｔ長が１６０ｂｉｔ等の値をノードＩＤとし、各ノードＮｎのノードＩＤが一つのＩＤ空間に偏りなく分散して配置されることになる。

また、各ノードＮｎは、夫々、ＤＨＴを用いたルーティングテーブルを保存している。このルーティングテーブルは、コンテンツ分散保存システムＳ上における各種メッセージの転送先を規定しており、具体的には、ＩＤ空間内で適度に離れたノードＮｎのノード情報が複数登録されている。ノード情報は、当該ノードＮｎのノードＩＤとアドレス情報を含むものであり、当該アドレス情報は、例えば、ＩＰアドレスとポート番号等を含む。

ところで、コンテンツ分散保存システムＳにおいては、内容の異なる様々な映画、アニメ、音楽等のコンテンツの複製データが所定のファイル形式で複数のノードＮｎに分散して保存されており、各ノードＮｎ間で当該レプリカを利用可能になっている。なお、以下の説明において、“コンテンツの複製データ”を、「レプリカ」又は「コンテンツデータ」と言う。

例えば、ノードＮ５には、タイトルがＸＸＸの映画のコンテンツのレプリカが保存されており、一方、ノードＮ３には、タイトルがＹＹＹの映画のコンテンツのレプリカが保存されるというように、複数のノードＮｎに分散されて保存されている。なお、以下の説明において、“レプリカ（コンテンツデータ）を保存するノードＮｎ”を「コンテンツ保存ノード」という。

また、これらのコンテンツのレプリカには、夫々、コンテンツのタイトルなどのコンテンツ名及びコンテンツＩＤ等の情報が付加されている。このコンテンツＩＤは、コンテンツ毎に固有の識別情報であり、コンテンツ識別情報の一例である。例えば、コンテンツ名＋任意の数値や、コンテンツの先頭数バイト等の数値が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて生成される。そして、コンテンツＩＤは、ノードＩＤと同一のＩＤ空間に配置される。或いは、システム管理者が、コンテンツ毎に一意のＩＤ値を付与しても良い。なお、この場合もノードＩＤと同一ビット長となるようなコンテンツＩＤを付与し、ノードＩＤとコンテンツＩＤが同一のＩＤ空間に存在するよう構成する。なお、ＩＤ空間については、特開２００６−１９７４００号公報、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

このように分散保存されているコンテンツのレプリカの所在、つまり、当該レプリカを保存したノードＮｎのノード情報と当該コンテンツのコンテンツＩＤ等の組が含まれるインデックス情報が、当該コンテンツのレプリカの所在を管理しているノードＮｎ等により記憶、管理されるようになっている。なお、以下の説明において、“レプリカの保存”を“レプリカの記憶”又は“レプリカのキャッシュ”ともいい、“コンテンツのレプリカの所在を管理しているノードＮｎ”を“ルートノード”という。

このようなコンテンツ分散保存システムＳにおいて、コンテンツデータをダウンロードする際には、コンテンツをリクエストするユーザーノードが、先ず、サーバ装置の一例であるコンテンツ分散保存システムＳを運営する管理者の管理サーバ等から各ノードＮｎにマルチキャスト送信等により配布されたカタログ情報を参照して取得したいコンテンツのコンテンツＩＤを取得する。

そして、ユーザーノードは、コンテンツ保存ノードの所在を検索すべく、取得したコンテンツＩＤを含む検索メッセージ（クエリ）を生成する。そして、生成したクエリをルーティングテーブルに従ってルートノードに向けて送出し、ルートノードからコンテンツのコンテンツデータを保存するコンテンツ保存ノードのアドレス情報を送信してもらう。そして、当該アドレス情報に従って、コンテンツ保存ノードにアクセスして、コンテンツ送信要求メッセージを送信する。その後、そこからそのコンテンツのコンテンツデータをダウンロードする。或いは、ユーザーノードからクエリを受信したルートノードが、コンテンツ保存ノードに対してユーザーノードのアドレス情報を含むコンテンツ送信要求メッセージを送信し、これにより、ユーザーノードが、上記コンテンツ保存ノードからそのコンテンツのコンテンツデータをダウンロードすることもできる。

なお、このようなＤＨＴを用いたルーティングテーブルや、当該ルーティングテーブルを利用した各ノードＮｎ間におけるメッセージの転送については、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

管理サーバ等から各ノードＮｎにマルチキャスト送信等により配布されるカタログ情報には、コンテンツの検索情報の一例としてのレコードが記憶されている。

コンテンツのレコードとは、コンテンツの属性情報であり、例えば、コンテンツＩＤ、コンテンツの公開期間を示す公開期間情報、コンテンツの検索用キーワード、コンテンツの評価値、コンテンツタイトル、ジャンル、アーティスト名、出演者、監督名等である。なお、公開期間情報には、公開日時の一例である公開開始日時を示す公開日時情報と、公開終了日時を示す公開終了日時情報を含む。なお、属性情報の詳細は、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

このようなコンテンツのレコードは、ユーザーが所望のコンテンツデータを特定する場合の要素であり、多くのコンテンツデータの中から所望のコンテンツデータを検索するための検索条件としての検索キーワードとしても利用される。例えば、ユーザーが検索キーワードとして「ジャズ」を入力すると、レコードに「ジャズ」に該当する全てのコンテンツデータが検索され、検索結果がユーザーに選択可能に提示されることになる。検索結果として、検索されたコンテンツデータのレコードを提示してもよい。

ところで、オーバーレイネットワーク９に参加している各ノードＮｎが、夫々、マルチキャストによって配布されたカタログ情報の全部を記憶する形態の場合、コンテンツ分散保存システムＳ上に投入されるコンテンツの数が膨大になると、カタログ情報のデータ量も大きくなりすぎて１台のノードＮｎにおけるカタログ情報を記憶する記憶領域に記憶しきれないという事態が想定される。

そこで、本実施形態では、各ノード毎にコンテンツデータの担当範囲を決め、各ノードＮｎが、自己の担当範囲のコンテンツのレコードが記憶されたカタログ情報を記憶するように構成し、カタログ情報を複数のノードで分散するよう構成した。

ここで、「担当範囲」は、所定の規則に従って定められ、例えば、ノードＩＤとコンテンツＩＤとの最上位桁目からの一致すべき桁数を示す「Ｒａｎｇｅ」で表される。例えば、Ｒａｎｇｅ＝１の場合、少なくとも最上位桁目が一致すべきことを意味し、Ｒａｎｇｅ＝２の場合、少なくとも最上位桁目及びその次の桁目が一致すべきことを意味しており、当該Ｒａｎｇｅは、担当範囲が広くなるほど、小さくなる桁数を示している。

そして、夫々のノードＮｎは、上記Ｒａｎｇｅを記憶しており、自己のノードＩＤのうちＲａｎｇｅにて示される桁数分の所定桁目が一致するコンテンツＩＤを有するコンテンツデータを、自己の担当範囲のコンテンツデータとして、そのレコードが記憶されたカタログ情報を記憶する。例えば、ノードＩＤが「０１３２」でＲａｎｇｅ＝１であるノードは、少なくとも最上位桁目が「０」であるコンテンツＩＤを有する全てのコンテンツデータを、自己の担当範囲のコンテンツデータとしてそのレコードが記憶されたカタログ情報を記憶することになる。

また、ノードＩＤが「１００１」でＲａｎｇｅ＝２であるノードは、少なくとも最上位桁目から２桁目までが「１０」であるコンテンツＩＤを有する全てのコンテンツデータを、担当範囲のコンテンツデータとしてそのレコードが記憶されたコンテンツカタログ情報を記憶することになる。なお、Ｒａｎｇｅ＝０の場合、カタログ情報の全部を記憶することになる。

なお、各ノードＮｎは、自己の担当範囲外のコンテンツデータのレコードが記憶されたカタログ情報を記憶することを妨げるものではなく、最低限自己の担当範囲のコンテンツデータのレコードについては、他のノードＮｎに対して記憶していることを保証するものである。

Ｒａｎｇｅをどのように設定するかは、各ノード毎に任意であるが、例えば、担当範囲のカタログ情報を記憶する担当検索情報記憶領域の記憶容量が小さいほど狭く、記憶容量が大きいほど広く設定するよう構成してもよい。

このように、オーバーレイネットワーク９に参加している各ノードには、少なくとも自己の担当範囲のコンテンツデータのレコードが記憶されたカタログ情報が記憶されているものとする。その他、例えば、カタログ情報の受信処理など、各ノードＮｎが有する担当範囲のカタログ情報の詳細については、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

ところで、コンテンツデータは、公開前に、公開後の利用に備えてコンテンツ分散保存システムＳに参加する各ノードＮｎに事前に保存する場合がある。このような公開前のコンテンツデータの事前保存は、コンテンツデータを提供する管理サーバ等が、コンテンツ分散保存システムＳに参加するノードＮｎに、新規公開予定のコンテンツのコンテンツデータを事前保存するよう指示する事前保存指示メッセージをマルチキャスト送信する。指示を受けた各ノードＮｎが指示されたコンテンツの所在を検索（クエリ送信）する。コンテンツ保存ノードから新規公開予定のコンテンツのコンテンツデータを取得して後述する自己の記憶部に記憶する。このような事前保存指示は、管理サーバ等が各ノードＮｎにそれぞれ指示する構成でもよいが、管理サーバ等の負担軽減のため、各ノードＮｎ間で当該事前保存指示メッセージを転送し合う。当該メッセージを受信したノードＮｎがそれぞれ指示に従ってコンテンツデータを取得し保存するよう構成してもよい。

本実施形態では、各ノードＮｎは、公開前に各ノードＮｎに事前保存されている新規公開予定のコンテンツのレコードが記憶されたカタログ情報も記憶するよう構成する。

新規公開予定のコンテンツとは、公開間近のコンテンツであり、コンテンツ分散保存システムＳ内の各ノードＮｎで利用可能となる日時（公開日時）が所定期間以内であるコンテンツを言う。所定期間は、例えば、数日、一週間などと定めることができ、コンテンツの種類や評価値、又はコンテンツ分散保存システムＳに参加しているノードＮｎの数等の条件を比較考量して管理サーバ又は当該ノードＮｎ自身が決定する。

そして、ノードＮｎは、例えば、ユーザーによってキーワードや公開期間の範囲指定などの条件が入力され、コンテンツの検索要求がされた際には、他のノードＮｎに対して後述する「カタログ検索処理」を行なう前に、先ず、自己が記憶しているカタログ情報を参照して検索を行なう。

このように、各ノードＮｎは、自己の担当範囲のコンテンツのカタログ情報だけでなく、カタログ検索が要求される可能性が高い、新規公開予定のコンテンツのカタログ情報を記憶するよう構成したので、カタログ検索を行なう際に、これらのカタログ情報を参照することができ、コンテンツデータの検索を簡便且つ迅速に行なうことができる。

更に、各ノードＮｎは、カタログ検索でヒットしたコンテンツのレコードを記憶してもよい。カタログ検索でヒットしたコンテンツは、言わば、ユーザーの嗜好に沿ったコンテンツともいえる。従って、各ノードＮｎが、カタログ検索でヒットしたコンテンツのレコードが記憶されたカタログ情報を後述する自己の記憶部に記憶すれば、新たにカタログ検索を行なう際に、これまでのカタログ検索でヒットしたコンテンツのレコードが記憶されたカタログ情報を参照してコンテンツデータの検索をより簡便且つ迅速に行なうことができる。

なお、以下の説明において、自己の担当範囲のカタログ情報を「ローカルカタログ」と称する。新規公開予定のコンテンツのカタログ情報を「新規公開カタログ」と称する。カタログ検索でヒットしたコンテンツのカタログ情報を「検索結果カタログ」と称する。

２.ノードＮｎの構成及び機能
次に、図２を参照して、ノードＮｎの構成及び機能について説明する。

図２は、ノードＮｎの概要構成例を示すブロック図である。

各ノードＮｎは、制御部１１と、記憶部１２と、バッファメモリ１３と、デコーダ部１４と、映像処理部１５と、表示部１６と、音声処理部１７と、スピーカ１８と、通信部２０と、入力部２１とから構成される。制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、通信部２０、及び入力部２１はバス２２を介して相互に接続されている。制御部１１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成される。制御部１１は、本実施形態のコンピュータとして機能する。記憶部１２は、各種データ及び各種プログラム等を記憶保存（格納）するためを記憶するハードディスク等から構成される。例えば、記憶部１２はコンテンツのレプリカを記憶する。また、システムＳ１又はＳ２に参加後は、記憶部１２はインデックスキャッシュ、ＤＨＴ等を記憶する。バッファメモリ１３は、受信されたコンテンツのレプリカ等を一時蓄積する。デコーダ部１４は、エンコードされたビデオデータ（映像情報）およびオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）する。コンテンツが映像や音声を含む場合に、デコーダ部１４は、コンテンツのレプリカに含まれるエンコードされたビデオデータおよびオーディオデータ等をデコードする。映像処理部１５は、デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する。表示部１６は、映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等である。音声処理部１７は、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する。スピーカ１８は、音声処理部１７から出力されたオーディオ信号を音波として出力する通信部２０は、ネットワーク８を通じて他のノードＮｎ等間の情報の通信制御を行なう。入力部２１は、ユーザーからの指示を受け付け、指示に応じた指示信号を制御部１１へ通信する。入力部２１は、例えば、キーボード、マウス、或いは、操作パネル等である。

なお、ノードＮｎとしては、パーソナルコンピュータ、ＳＴＢ（Set Top Box）、通信カラオケ装置、或いは、ＴＶ受信機等が適用可能である。

記憶部１２は、コンテンツデータキャッシュ領域を有し、コンテンツ分散保存システムＳに参加する他のノードＮｎや管理サーバ等から取得したコンテンツデータが当該コンテンツデータキャッシュ領域に記憶される。

また、記憶部１２には、キャッシュリストが記憶されている。当該キャッシュリストは、コンテンツデータキャッシュ領域に記憶しているコンテンツデータのコンテンツ名、コンテンツＩＤなど、コンテンツデータに関する情報がそれぞれ対応付けて登録されている。更に、後述する保存コンテンツデータのチェック処理の際、或いは、コンテンツ送信要求メッセージに応じてコンテンツを送信した際など、コンテンツデータのチェックが行なわれた時間が最終チェック時間として登録されている。

また、記憶部１２には、当該ノードＮｎ自身のアドレス情報及びノードＩＤと、ルーティングテーブルが記憶される。更に、自己が所在を管理するコンテンツの情報と、当該コンテンツを保存するコンテンツ保存ノードの情報がインデックスキャッシュとして記憶される。自己が所在を管理するコンテンツの情報とは、コンテンツのコンテンツＩＤであり、コンテンツ保存ノードの情報はノード情報である。これらコンテンツＩＤとノード情報の組が含まれるインデックス情報がインデックスキャッシュとして記憶される。

また、記憶部１２には、カタログ情報の担当範囲を決定するための自己のＲａｎｇｅが記憶されている。

更に、記憶部１２は、担当検索情報記憶領域と新規公開検索情報記憶領域と検索結果検索情報記憶領域とを有する。担当検索情報記憶領域には、ローカルカタログが記憶されている。新規公開検索情報記憶領域には、新規公開カタログが記憶されており、検索結果検索情報記憶領域には検索結果カタログが保存されている。

このような構成において、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、全体を統括制御し、コンテンツ分散保存システムＳへの参加により上述したユーザーノード、中継ノード、ルートノード、コンテンツ保存ノードの少なくとも何れか一つのノードとしての処理を行なうようになっている。

また、制御部１１は、本発明のノード処理プログラムを実行することにより、本発明における検索情報取得手段、検索情報判定手段、担当検索情報記憶手段、判定手段、新規公開検索情報記憶手段、コンテンツデータ検索手段、記憶判定手段、現在日時取得手段等として機能する。なお、上記ノード処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。

３．ノードＮｎの処理
ノードＮｎにおける処理を、図を参照して詳しく説明する。

３−１．メイン処理
図３は、コンテンツ分散保存システムＳに参加している任意のノードＮｎにおける制御部１１のメイン処理を示すフローチャートであり、コンテンツ分散保存システムＳへの参加後、例えば、コンタクトノードへのアクセスの後に本発明のノード処理が読み出され処理が開始する。

先ず、制御部１１は、当該ノードＮｎ自身の電源がオフとされたか否かを判定し（ステップＳ１０）、電源がオフとされた場合（ステップＳ１０：Ｙｅｓ）には処理を終了し、電源がオフとされていない場合（ステップＳ１０：Ｎｏ）には、所定条件に基づいてコンテンツの検索要求受付がされたか否かを判定する（ステップＳ１１）。具体的には、例えば、ユーザーによって入力部２１が操作され、キーワードや公開期間の範囲指定などの条件が入力されコンテンツの検索要求が受け付けられたか否かを判定する。

判定の結果、検索要求が受け付けられた場合（ステップＳ１１：Ｙｅｓ）には、制御部１１は、予め用意された「検索結果リスト」を０として初期化する（ステップＳ１２）。「検索結果リスト」は、検索を行なった結果を一時的に記憶するためのものであり、ＲＡＭ等に予め用意されている。

次いで、制御部１１は、記憶部１２に記憶した新規公開カタログと検索結果カタログを検索し、所定条件に該当するコンテンツがあれば、当該コンテンツの情報を検索結果として表示部１６に表示してユーザーに提示する（ステップＳ１３）。なお、所定条件に該当するコンテンツとは、言い換えれば、所定条件にヒットしたコンテンツである。また、検索結果としてユーザーに提示されるコンテンツの情報は、例えばコンテンツのレコード等であり、ステップＳ１３では、検索の結果ヒットしたコンテンツのレコードがユーザーに提示され、かつ、検索結果リストに登録される。

続いて、制御部１１は、「カタログ検索処理」を行なう（ステップＳ１４）。ここで実行される「カタログ検索処理」は、他のノードＮｎに対して検索要求メッセージを送信し、他のノードＮｎにて記憶されているローカルカタログ、新規公開カタログ又は検索結果カタログの中から所定条件に該当するコンテンツの検索処理を行なってもらい、当該他のノードＮｎから検索結果を返信してもらう処理である。なお、所定条件は検索要求メッセージに含んで送信すればよい。なお、当該「カタログ検索処理」の詳細については、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

また、ステップＳ１４におけるカタログ検索処理では、検索要求メッセージを受信した他のノードＮｎは、新規公開予定のコンテンツのレコードを検索結果と共に送信する。これにより、制御部１１は、検索結果と共に新規公開予定のコンテンツのレコードを受信する。なお、上記他のノードＮｎが、新規公開予定のコンテンツのレコードを保存していない場合には、新規公開予定のコンテンツのレコードを送信しない。

なお、ステップＳ１４における「カタログ検索処理」では、記憶部１２に記憶したローカルカタログ内も検索する。

そして、他のノードＮｎから取得した検索結果とローカルカタログを検索して取得した検索結果を表示部１６に表示してユーザーに提示する（ステップＳ１５）。

このとき検索結果リストには、ステップＳ１３にて、新規公開カタログと検索結果カタログを検索して得られた検索結果が登録されているが、ステップＳ１５では、検索結果リストに登録されていない検索結果のみを提示するよう構成してもよい。ステップＳ１３にて提示済みの検索結果が重複して提示されないようにするためである。

続いて、制御部１１は、「レコード保存処理（Ａ）」を行ない（ステップＳ１６）、検索結果として得られたレコードを保存する。なお、ステップＳ１６の「レコード保存処理（Ａ）」は後に詳述する。

そして、制御部１１は、ステップＳ１４の「カタログ検索処理」において、他のノードＮｎから新規公開予定のコンテンツのレコードを受信したか否かを判定する（ステップＳ１７）。

判定の結果、新規公開予定のコンテンツのレコードを受信していない場合（ステップＳ１７：Ｎｏ）には、ステップＳ１０へ移行し、新規公開予定のコンテンツのレコードを受信した場合（ステップＳ１７：Ｙｅｓ）には、「レコード保存処理（Ｂ）」を行ない（ステップＳ１８）、新規公開予定のコンテンツのレコードを保存する。なお、ステップＳ１８の「レコード保存処理（Ｂ）」は後に詳述する。

一方、ステップＳ１１において、検索要求が受け付けられていないと判定された場合（ステップＳ１１：Ｎｏ）には、制御部１１は、ステップＳ１３又はステップＳ１５にて提示した検索結果からコンテンツの選択がされたか否かを判定する（ステップＳ１９）。

具体的には、検索結果を提示されたユーザーが、入力部２１を操作することにより、検索結果の中からコンテンツデータの取得を所望するコンテンツの選択が行われたか否かを判定する。

判定の結果、コンテンツの選択がされた場合には（ステップＳ１９：Ｙｅｓ）、制御部１１は、選択されたコンテンツのコンテンツデータを保存するコンテンツ保存ノードのアドレス情報を取得する（ステップＳ２０）。具体的には、選択されたコンテンツのコンテンツＩＤをキーとするクエリの送信により、当該コンテンツのルートノードから当該コンテンツのコンテンツデータを保存するコンテンツ保存ノードのアドレス情報を返信してもらう。なお、クエリの送信から所定時間経過してもコンテンツ保存ノードのアドレス情報が取得できなかった場合には、管理サーバに問い合わせて、管理サーバからコンテンツ保存ノードのアドレス情報を取得してもよい。

続いて、制御部１１は、取得したアドレス情報に従ってコンテンツ保存ノードにアクセスし、コンテンツ保存ノードから選択されたコンテンツのコンテンツデータを取得する（ステップＳ２１）。なお、取得したコンテンツデータは、記憶部１２のコンテンツデータキャッシュ領域に記憶される。更に、制御部１１は、取得したコンテンツデータに関する情報をキャッシュリストに追加登録する。更に、コンテンツデータを記憶したことを他のノードＮｎに知らせるため、コンテンツデータの登録（パブリッシュ）処理を行なう。なお、コンテンツデータのパブリッシュ処理については、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

そして、ステップＳ１０へ移行する。なお、取得したコンテンツデータは、その後再生処理が行なわれるが、当該再生処理は、ステップＳ１０乃至ステップＳ２４の処理と並行して行ってもよい。

一方、ステップＳ１９において、コンテンツの選択がされていない場合（ステップＳ１９：Ｎｏ）には、制御部１１は、他のノードＮｎ又は管理サーバからメッセージを受信したか否かを判定する（ステップＳ２２）。

判定の結果、メッセージを受信した場合（ステップＳ２２：Ｙｅｓ）には、制御部１１は、「メッセージ受信処理」を行ない（ステップＳ２３）、ステップＳ１０へ移行する。なお、ステップＳ２３の「メッセージ受信処理」は、後に詳述する。

また、メッセージを受信していない場合（ステップＳ２２：Ｎｏ）には、制御部１１は、保存コンテンツデータのチェック処理を行ない（ステップＳ２４）、ステップＳ１０へ移行する。

ステップＳ２４の保存コンテンツデータのチェック処理は、記憶部１２のコンテンツデータキャッシュ領域に記憶しているコンテンツデータに対する処理である。例えば、コンテンツデータキャッシュ領域に記憶しているコンテンツデータの中に、例えば、既に公開期間が終了しているコンテンツデータがある場合には、そのコンテンツデータをコンテンツデータキャッシュ領域から削除する。公開期間が終了しているコンテンツデータとは、コンテンツのレコードに含まれる公開終了日時情報で示される公開終了日時が現在日時を経過している場合を言う。

また、現在日時とコンテンツの公開日時までの時間差に応じて、他のノードＮｎに対する事前保存指示メッセージを送信する場合には、残り期間をチェックし事前保存指示メッセージの送信タイミングか否かを判定し、送信タイミングであれば、事前保存指示メッセージを送信する。その他、コンテンツの評価値に基づいて、自己の記憶部１２に記憶されたコンテンツの保存優先順位が決定される場合に、当該保存優先順位を更新する等の処理もある。

保存コンテンツデータのチェック処理は、コンテンツのレコードに含まれる公開期間や評価値に基づいて行なわれるが、レコードを検索する際には、記憶部１２に記憶しているローカルカタログ、新規公開カタログ、検索結果カタログ、及び、他のノードＮｎに対して「カタログ検索処理」を行ない、レコードを検索する。

なお、ネットワーク負荷を抑制するため、他のノードＮｎに対する「カタログ検索処理」より先に、記憶部１２に記憶しているローカルカタログ、新規公開カタログ、検索結果カタログを検索するほうがよい。

また、特に、事前保存指示メッセージを他のノードＮｎにマルチキャスト転送するために、コンテンツの公開日時をチェックする場合には、当該事前保存指示メッセージにかかるコンテンツは新規公開予定のコンテンツであるため、当該コンテンツのレコードは、新規公開カタログに記憶されている可能性が高い。従って、この場合には、新規公開カタログを先に検索すれば、より迅速に検索することができる。

なお、上記ステップＳ２０において、取得を所望するコンテンツのコンテンツ保存ノードのアドレス情報をルートノードから取得しているが、クエリを受信したルートノードがコンテンツ保存ノードに対してユーザーノードのアドレス情報を含むコンテンツ送信要求メッセージを送信し、これにより、ユーザーノードは、上記コンテンツ保存ノードからそのコンテンツデータを取得するよう構成してもよい。

また、ステップＳ２４にて毎回保存コンテンツデータのチェック処理を行なわずとも、記憶部１２のコンテンツデータキャッシュ領域に記憶している各コンテンツデータについて、予め定めた所定期間毎に定期的にチェックを行なうよう構成してもよい。そして、定期チェックを行なった際、チェックした時間を用いて記憶部１２のチェックリストの最終チェック時間を更新する。

なお、ステップＳ１１の検索要求に対して検索を行なう際に、ステップＳ１３にて、ローカルカタログより先に新規公開カタログと検索結果カタログを検索しているが、ローカルカタログを先に検索してもよい。ローカルカタログを検索し、次に、新規公開カタログと検索結果カタログを検索し、最後に他のノードＮｎに対する「カタログ検索処理」を行なう場合には、「カタログ検索処理」にて記憶部１２のローカルカタログの検索は行なわない。

また、ステップＳ１１の検索要求に対して検索を行なう際に、新規公開カタログが記憶される新規公開検索情報記憶領域と、検索結果カタログが記憶される検索結果検索情報記憶領域と、ローカルカタログが記憶される担当検索情報記憶領域とを比較して、記憶容量が大きいカタログから順に検索を行なってもよい。

３−２．「レコード保存処理（Ａ）」
図４は、上記ステップＳ１６の「レコード保存処理（Ａ）」を示すフローチャートである。この処理は、例えば、検索結果リストに登録されたレコードを、ローカルカタログ又は新規公開カタログ又は検索結果カタログに保存する処理である。

先ず、制御部１１は、検索結果リストに登録されたレコード、つまり、保存対象のレコードが、自己の担当範囲のコンテンツのレコードであるか否かを判定する（ステップＳ３０）。具体的には、記憶部１２に記憶している自己のＲａｎｇｅとノードＩＤに基づいて、自己の担当範囲のコンテンツのレコードであるか否かを判定する。

例えば、Ｒａｎｇｅ＝０であって、ノードＩＤが「０１００」である場合には、保存対象のレコードに係るコンテンツのコンテンツＩＤが、少なくとも最上位桁目が「０」であるコンテンツＩＤである場合には、保存対象のレコードを自己の担当範囲のコンテンツのレコードであるとして判定する。

判定の結果、自己の担当範囲のコンテンツのレコードである場合（ステップＳ３０：Ｙｅｓ）には、制御部１１は、保存対象のレコードをローカルカタログに保存する（ステップＳ３１）。なお、保存対象のレコードが、ローカルカタログに既に保存されていれば、上書保存して処理を終了する。

一方、判定の結果、保存対象のレコードが、自己の担当範囲のコンテンツのレコードでない場合（ステップＳ３０：Ｎｏ）には、制御部１１は、新規公開カタログに保存対象のレコードが保存されているか否かを判定する（ステップＳ３２）。

判定の結果、新規公開カタログに保存対象のレコードが保存されている場合（ステップＳ３２：Ｙｅｓ）には、制御部１１は、保存対象のレコードを用いて新規公開カタログのレコードを上書保存して（ステップＳ３３）、処理を終了する。

一方、判定の結果、新規公開カタログに保存対象のレコードが保存されていない場合（ステップＳ３２：Ｎｏ）には、制御部１１は、保存対象のレコードが新規公開予定のコンテンツのレコードであるか否かを判定する（ステップＳ３２）。

判定の結果、保存対象のレコードが新規公開予定のコンテンツのレコードである場合（ステップＳ３４：Ｙｅｓ）には、制御部１１は、「新規公開カタログ保存処理」を行ない（ステップＳ３５）、処理を終了する。なお、ステップＳ３５の「新規公開カタログ保存処理」は、後に詳述する。

一方、保存対象のレコードが新規公開予定のコンテンツのレコードでない場合（ステップＳ３４：Ｎｏ）には、制御部１１は、保存対象のレコードを検索結果カタログに保存する（ステップＳ３６）。なお、保存対象のレコードが、検索結果カタログに既に保存されていれば、上書保存して処理を終了する。

検索結果リストに登録された全てのレコードに対してステップＳ３０乃至ステップＳ３６の処理を行ない、処理を終了する。

３−３．「レコード保存処理（Ｂ）」
図５は、上記ステップＳ１８の「レコード保存処理（Ｂ）」を示すフローチャートである。

この処理は、他のノードＮｎから検索結果と共に受信した新規公開予定のコンテンツのレコードを、ローカルカタログ又は新規公開カタログ又は検索結果カタログに保存する処理である。なお、他のノードＮｎから受信した新規公開予定のコンテンツのレコードを“保存対象のレコード”とする。また、ステップＳ１６の「レコード保存処理（Ａ）」と同様の処理については説明を省略する。

ステップＳ４０乃至ステップＳ４３の処理は、上述したステップＳ３０乃至ステップＳ３３の処理と同様であるため説明を省略する。

続いて、ステップＳ４２にて、新規公開カタログに保存対象のレコードが保存されているか否かを判定した結果、新規公開カタログに保存対象のレコードが保存されていない場合（ステップＳ４２：Ｎｏ）には、制御部１１は、「新規公開カタログ保存処理」を行ない（ステップＳ４４）、処理を終了する。なお、ステップＳ４４の「新規公開カタログ保存処理」は、後に詳述する。

３−４．「新規公開カタログ保存処理」
図６は、上述した「レコード保存処理（Ａ）」のステップＳ３５、及び「レコード保存処理（Ｂ）」のステップＳ４４にて行われる「新規公開カタログ保存処理」を示すフローチャートである。なお、「レコード保存処理（Ａ）」のステップＳ３５の「新規公開カタログ保存処理」である場合、検索結果リストに登録されたレコードをこの「新規公開カタログ保存処理」における“保存対象のレコード”とし、「レコード保存処理（Ｂ）」のステップＳ４４の「新規公開カタログ保存処理」である場合には、他のノードＮｎから受信した新規公開予定のコンテンツのレコードをこの「新規公開カタログ保存処理」における“保存対象のレコード”とする。

先ず、制御部１１は、保存対象のレコードが、保存判定条件を満たすか否かを判定する（ステップＳ５０）。保存判定条件とは、新規公開カタログが記憶される新規公開検索情報記憶領域に保存対象のレコードを記憶できる所定の記憶容量があるか否かを判定する条件であり、例えば、保存対象のレコードを新規公開カタログに登録した場合に、新規公開検索情報記憶領域の記憶容量に応じて予め定められた新規公開カタログに記憶されるレコードの上限数を超えないとする条件や、予め定められた新規公開カタログの上限容量を超えないとするなどの条件である。これら上限数や上限容量を超えない場合には、保存判定条件を満たすものとて判定する。また、“新規公開予定のコンテンツのレコードは必ず新規公開カタログに登録する”と規定されている場合には、常に保存判定条件を満たすとして判定する。なお、保存対象のレコードの容量が新規公開カタログが記憶される新規公開検索情報記憶領域の空き記憶容量以上である場合には、保存対象のレコードの容量分の空き記憶容量ができるまで以下のレコード削除処理を行なってもよい。

ステップＳ５０の判定の結果、保存判定条件を満たさない場合（ステップＳ５０：Ｎｏ）には、制御部１１は、新規公開カタログに記憶されているレコードに含まれる公開日時情報が示す公開日時と、保存対象のレコードに含まれる公開日時情報が示す公開日時を比較して、保存対象レコードに含まれる公開日時が一番未来であるか否かを判定する（ステップＳ５１）。まず、制御部１１は、現在の日時を示す現在日時情報を取得し、当該現在日時情報が示す現在日時と保存対象レコードの公開日時との時間差が、現在日時と新規公開カタログに記憶されているレコードの公開日時との時間差よりも大きいか否かを判定し、大きい場合には、保存対象レコードに含まれる公開日時が一番未来であると判定する。

判定の結果、保存対象レコードの公開日時が一番未来である場合（ステップＳ５１：Ｙｅｓ）には、制御部１１は、処理を終了する。新規公開カタログに記憶されているレコードと比較して、保存対象レコードの公開日時まで比較的余裕が有る場合、つまり、公開日時まで比較的時間が有る場合には、公開日時が直近のレコードと比べて、これから先、別のタイミングで当該レコードを保存する機会がある可能性が高い。従って、保存対象レコードの公開日時が一番未来である場合には、保存対象レコードを新規公開カタログに保存しないで、処理を終了する。

一方、判定の結果、保存対象レコードの公開日時が一番未来でない場合（ステップＳ５１：Ｎｏ）には、制御部１１は、新規公開カタログに既に記憶されているレコードのうち、所定の規則に従って削除レコードとして選択されたレコードを新規公開カタログから削除して（ステップＳ５２）、ステップＳ５０へ移行する。例えば、新規公開カタログに既に記憶されているレコードのうち、公開日時が一番未来のレコード、言い換えれば、現在日時と公開日時の時間差が一番大きいレコードを削除レコードとして選択し、新規公開カタログから削除する。

ステップＳ５０による判定の結果、保存判定条件を満たす場合（ステップＳ５０：Ｙｅｓ）には、制御部１１は、保存対象レコードを新規公開カタログに保存して（ステップＳ５３）処理を終了する。

なお、ステップＳ５２では、所定の規則の一例として、公開日時が一番未来のレコードを削除レコードとして選択し、新規公開カタログから削除しているが、例えば、公開日時が現在日時よりも過去であるレコード、言い換えれば、公開済みのコンテンツのレコードが新規公開カタログに記憶されている場合には、当該レコードを削除レコードとして選択してもよい。また、新規公開カタログに、公開済みのコンテンツのレコードが複数記憶されている場合には、レコードに含まれる公開日時情報が示す公開日時と現在日時との最も時間差が大きいレコードを削除レコードとして選択してもよい。また、新規公開カタログからランダムに削除レコードを選択してもよいし、あるいは、評価値に基づく保存優先順位が低いコンテンツのレコードを削除レコードとして選択してもよい。

３−５．「メッセージ受信処理」
図７は、上記ステップＳ２３の「メッセージ受信処理」を示すフローチャートである。

先ず、制御部１１は、他のノードＮｎから検索要求メッセージを受信したか否かを判定（ステップＳ６０）し、検索要求メッセージを受信した場合（ステップＳ６０：Ｙｅｓ）には、制御部１１は、「検索要求メッセージ受信処理」を行なう（ステップＳ６１）。

ここで実行される「検索要求メッセージ受信処理」は、他のノードＮｎから受信した検索要求メッセージに対して、記憶部１２に記憶しているローカルカタログ、新規公開カタログ及び検索結果カタログを参照して検索要求メッセージにて指定された所定条件を満たすコンテンツを検索する処理である。検索の際には、新規公開カタログが記憶される新規公開検索情報記憶領域と、検索結果カタログが記憶される検索結果検索情報記憶領域と、ローカルカタログが記憶される担当検索情報記憶領域とを比較して、記憶容量が大きいカタログから順に検索を行なってもよい。なお、公開前になると検索要求が頻繁に行なわれることから、ローカルカタログ及び検索結果カタログより先に新規公開カタログ内を検索すれば、迅速に検索を行なうことができる。なお、「検索要求メッセージ受信処理」の詳細については、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

そして、制御部１１は、ステップＳ６１にて検索された検索結果と、記憶部１２に記憶された新規公開カタログに記憶されているレコードを検索要求メッセージの送信元のノードＮｎに返信する（ステップＳ６２）。

一方、検索要求メッセージを受信していない場合（ステップＳ６０：Ｎｏ）には、制御部１１は、他のノードＮｎ又は管理サーバからレコードの新規登録メッセージ、変更メッセージ、又は削除メッセージを受信したか否かを判定する（ステップＳ６３）。レコードの新規登録メッセージ、変更メッセージ、又は削除メッセージは、管理サーバが新たなコンテンツをコンテンツ分散保存システムＳに投入する際、或いはコンテンツ分散保存システムＳに既に投入されたコンテンツのレコードが変更される際、或いは既に投入されているコンテンツがコンテンツ分散保存システムＳから削除される際に、当該管理サーバからマルチキャスト送信されるメッセージである。これらメッセージは、所定の規則に従って管理サーバからコンテンツ分散保存システムＳに参加する全ノードＮｎに対してマルチキャスト送信される。

管理サーバがこれらメッセージを全ノードＮｎに送信する場合もあれば、管理サーバから送信されたメッセージが所定の規則に従ってコンテンツ分散保存システムＳに参加する各ノードＮｎ間を転送されることにより、全ノードＮｎにマルチキャスト転送（送信）される場合もある。ここでは、管理サーバから送信されたメッセージが、所定の規則に従って各ノードＮｎ間を転送されるものとして説明する。

なお、サーバ装置の一例として、新たなコンテンツをコンテンツ分散保存システムＳに投入したり、既にコンテンツ分散保存システムＳに投入済みのコンテンツのレコードの更新やレコードの削除を管理するサーバを、管理サーバとは別に投入サーバとして設けてもよい。投入サーバは、コンテンツ分散保存システムＳを管理する管理者、又は当該管理者によって許可を得たコンテンツ提供業者等によって管理される。

ステップＳ６３の判定の結果、レコードの新規登録メッセージ、変更メッセージ、又は削除メッセージを受信した場合（ステップＳ６３：Ｙｅｓ）には、制御部１１は、「カタログ更新処理」を行なう（ステップＳ６４）。なお、ステップＳ６４の「カタログ更新処理」は、後に詳述する。

そして、制御部１１は、カタログ更新後、受信したレコードの新規登録メッセージ、変更メッセージ、又は削除メッセージを、所定の規則に従って他のノードＮｎにマルチキャスト転送し（ステップＳ６５）。処理を終了する。

次いで、制御部１１は、他のノードＮｎからコンテンツの検索メッセージ（クエリ）、コンテンツの登録メッセージ（パブリッシュ）、又はコンテンツの削除メッセージを受信したか否かを判定する（ステップＳ６６）。

判定の結果、コンテンツ送信要求メッセージ、コンテンツの検索メッセージ（クエリ）、コンテンツの登録メッセージ（パブリッシュ）、又はコンテンツの削除メッセージを受信した場合（ステップＳ６６：Ｙｅｓ）には、制御部１１は、各メッセージに応じた処理を行ない（ステップＳ６７）、処理を終了する。メッセージに応じた処理とは、例えば、コンテンツ送信要求メッセージを受信した場合には、メッセージに含まれるコンテンツＩＤのコンテンツデータをメッセージ送信元のノードＮｎに送信し、クエリを受信した場合には、記憶部１２のインデックスキャッシュにクエリに含まれるコンテンツＩＤのコンテンツ保存ノードのインデックス情報が登録されていれば、当該コンテンツ保存ノードのアドレス情報をメッセージ送信元のノードＮｎに送信する処理などである。なお、ステップＳ６６にて受信した各種メッセージに対する処理の詳細は、特開２００７‐２８０３０３号公報等で公知であるので、詳しい説明を省略する。

このように、メッセージに応じた処理を行なうことにより、中継ノード、ルートノード、コンテンツ保存ノードとしての処理を行なう。

なお、コンテンツ送信要求メッセージに対して、記憶部１２のコンテンツデータキャッシュ領域からメッセージに含まれるコンテンツＩＤのコンテンツデータを取得して送信する場合には、記憶部１２のローカルカタログ又は新規公開カタログ又は検索結果カタログを参照して当該コンテンツデータの公開期間情報をチェックし、公開終了日時が過ぎていない場合にのみコンテンツデータを送信するよう構成してもよい。この際、記憶部１２に記憶しているローカルカタログ、新規公開カタログ及び検索結果カタログに、送信するコンテンツデータのレコードが無い場合には、他のノードＮｎに対して「カタログ検索処理」を行ない、他のノードＮｎから送信するコンテンツデータのレコードを取得して公開終了日時をチェックすればよい。このように、コンテンツデータの送信前に公開終了日時をチェックすることにより、既に公開終了しているコンテンツデータを他のノードＮｎに送信することを防ぐことができる。チェックした時間を用いて記憶部１２の該当するコンテンツデータの最終チェック時間を更新する。

一方、ステップＳ６６の判定の結果、コンテンツ送信要求メッセージ、コンテンツの検索メッセージ（クエリ）、コンテンツの登録メッセージ（パブリッシュ）、コンテンツの削除メッセージ、を受信していない場合には（ステップＳ６６：Ｎｏ）、制御部１１は、他のノードＮｎ又は管理サーバから事前保存指示メッセージを受信したか否かを判定する（ステップＳ６８）。

事前保存指示メッセージを受信していない場合には（ステップＳ６８：Ｎｏ）、処理を終了し、事前保存指示メッセージを受信した場合には（ステップＳ６８：Ｙｅｓ）、制御部１１は「事前保存処理」を行ない（ステップＳ６９）、処理を終了する。ステップＳ６９の「事前保存処理」は、後に詳述する。

なお、ステップＳ６２にて新規公開カタログに記憶されているレコードを検索要求メッセージの送信元のノードＮｎに返信しているが、検索結果送信メッセージに当該レコードを付加するための空きデータ領域が無い場合には、レコードを付加して送信しなくともよい。検索結果送信メッセージにレコードを付加するための空きデータ領域が有る場合にのみ、レコードを付加して送信すればよい。

例えば、新規公開カタログに１０個のレコードが記憶されており、検索結果送信メッセージのデータ領域には、レコードを１００個付加できる場合について説明する。例えば、検索結果のレコードが９５個であった場合には、検索結果送信メッセージのデータ領域に格納可能なレコードの数は残り５個である。従って、新規公開カタログに記憶されているレコードから５個のレコードを抽出する。そして、９５個の検索結果のレコードと、５個の新規公開カタログのレコードを、検索結果送信メッセージに付加する。

なお、新規公開カタログに記憶されているレコードから５個のレコードを抽出する際には、公開日時が最も近いコンテンツのレコードから順に５個のレコードを抽出することとする。

３−６．「カタログ更新処理」
図８は、上記ステップＳ６４の「カタログ更新処理」を示すフローチャートである。

先ず、制御部１１は、ステップＳ６３で受信判定されたメッセージに含まれるレコードが、自己の担当範囲のコンテンツのレコードであるか否かを判定する（ステップＳ７０）。具体的には、記憶部１２に記憶している自己のＲａｎｇｅとノードＩＤに基づいて、自己の担当範囲のコンテンツのレコードであるか否かを判定する。詳細はステップＳ３０と同様であるため説明を省略する。

判定の結果、自己の担当範囲のコンテンツのレコードである場合（ステップＳ７０：Ｙｅｓ）には、制御部１１は、受信したメッセージに含まれるレコードをローカルカタログに保存、又は上書保存、又はローカルカタログから削除して（ステップＳ７１）、処理を終了する。

受信したメッセージが新規登録メッセージであれば、新規登録レコードが含まれており、受信したメッセージが変更メッセージであれば、更新レコードが含まれており、受信したメッセージが削除メッセージであれば、削除レコードが含まれている。

そして、受信したメッセージが新規登録メッセージである場合には、当該メッセージに含まれる新規登録レコードをローカルカタログに保存し、受信したメッセージが変更メッセージである場合には、ローカルカタログに既に登録されているレコードを当該メッセージに含まれる更新レコードを用いて上書保存する。そして、受信したメッセージが削除メッセージである場合には、ローカルカタログに既に登録されているレコードのうち、当該削除メッセージに含まれるレコードに対応するレコードをローカルカタログから削除する。

一方、判定の結果、自己の担当範囲のコンテンツのレコードでない場合（ステップＳ７０：Ｎｏ）には、制御部１１は、新規公開カタログに受信したメッセージに含まれるレコードが保存されているか否かを判定する（ステップＳ７２）。

判定の結果、新規公開カタログに受信したメッセージに含まれるレコードが保存されている場合（ステップＳ７２：Ｙｅｓ）には、制御部１１は、受信したメッセージに含まれるレコードに基づいて、新規公開カタログのレコードを上書保存し、又は新規公開カタログから削除して（ステップＳ７３）、処理を終了する。

ステップＳ７２の判定の結果、新規公開カタログに受信したメッセージに含まれるレコードが保存されていない場合（ステップＳ７２：Ｎｏ）には、制御部１１は、検索結果カタログに受信したメッセージに含まれるレコードが保存されているか否かを判定する（ステップＳ７４）。

判定の結果、検索結果カタログに受信したメッセージに含まれるレコードが保存されていない場合（ステップＳ７４：Ｎｏ）には、処理を終了し、検索結果カタログに受信したメッセージに含まれるレコードが保存されている場合（ステップＳ７４：Ｙｅｓ）には、制御部１１は、受信したメッセージに含まれるレコードに基づいて、検索結果カタログのレコードを上書保存し、又は検索結果カタログから削除して（ステップＳ７５）、処理を終了する。

３−７．「事前保存処理」
図９は、上記ステップＳ６９の「事前保存処理」を示すフローチャートである。この処理は、上述した「メッセージ受信処理」のステップＳ６８で受信判定された事前保存指示メッセージにて事前保存指示されたコンテンツのコンテンツデータを取得して記憶部１２のコンテンツキャッシュ領域に記憶する処理である。

先ず、制御部１１は、事前保存指示メッセージにて事前保存指示されたコンテンツのレコードが、新規公開カタログに保存されているか否かを判定する（ステップＳ８０）。例えば、事前保存指示メッセージに、事前保存指示の対象となるコンテンツのコンテンツ名等が含まれており、新規公開カタログにメッセージに含まれるコンテンツ名に対応するコンテンツが保存されているか否かを判定する。

判定の結果、新規公開カタログに事前保存指示されたコンテンツのレコードが保存されていない場合（ステップＳ８０：Ｎｏ）には、制御部１１は、事前保存指示されたコンテンツのレコードが、ローカルカタログ又は検索結果カタログに保存されているか否かを判定する（ステップＳ８１）。

判定の結果、ローカルカタログ又は検索結果カタログに事前保存指示されたコンテンツのレコードが保存されていない場合（ステップＳ８１：Ｎｏ）には、制御部１１は、「カタログ検索処理」を行ない（ステップＳ８２）、他のノードＮｎにて記憶されている新規公開カタログ又はローカルカタログ又は検索結果コンテンツカタログの中から、事前保存指示されたコンテンツの検索処理を行なってもらい、当該他のノードＮｎから検索結果を返信してもらう処理である。なお、ステップＳ８２における「カタログ検索処理」では、記憶部１２に記憶したローカルカタログは検索しない。

そして、新規公開カタログに事前保存指示されたコンテンツのレコードが保存されている場合（ステップＳ８０：Ｙｅｓ）には、制御部１１は、当該新規公開カタログから事前保存指示されたコンテンツのレコードを取得する。

一方、ローカルカタログ又は検索結果カタログに事前保存指示されたコンテンツのレコードが保存されている場合（ステップＳ８１：Ｙｅｓ）、制御部１１は、当該ローカルカタログ又は検索結果カタログから事前保存指示されたコンテンツのレコードを取得する。

他方、ステップＳ８２の「カタログ検索処理」で他のノードＮｎに検索処理を行なってもらった場合には、当該他のノードＮｎから事前保存指示されたコンテンツのレコードを取得する。

次いで、制御部１１は、事前保存指示されたコンテンツのコンテンツデータを保存するコンテンツ保存ノードのアドレス情報を取得する（ステップＳ８３）。具体的には、制御部１１は、新規公開カタログ、ローカルカタログ、検索結果カタログ、又は、他のノードＮｎから取得したレコードから、コンテンツＩＤを抽出し、当該コンテンツＩＤをキーとするクエリの送信により、事前保存指示されたコンテンツのルートノードから、事前保存指示されたコンテンツのコンテンツデータを保存するコンテンツ保存ノードのアドレス情報を返信してもらう。なお、クエリの送信から所定時間経過してもコンテンツ保存ノードのアドレス情報が取得できなかった場合には、管理サーバに問い合わせて、管理サーバからコンテンツ保存ノードのアドレス情報を取得してもよい。

続いて、制御部１１は、取得したアドレス情報に従ってコンテンツ保存ノードにアクセスし、コンテンツ保存ノードから事前保存指示されたコンテンツのコンテンツデータを取得する（ステップＳ８４）。コンテンツデータ取得後に行なわれる登録処理（パブリッシュ）やキャッシュリストへの登録処理等は、ステップＳ２１と同様であるため、説明を省略する。なお、ステップＳ２１では取得後に再生処理を行なっているが、ここでは公開前のコンテンツデータを取得しているため、再生処理は行なわない。

そして、制御部１１は、「レコード保存処理（Ｂ）」を行なって（ステップＳ８５）、事前保存指示されたコンテンツのレコードをローカルカタログ又は新規公開カタログ又は検索結果カタログに保存し、処理を終了する。

なお、事前保存指示メッセージに事前保存指示されたコンテンツのコンテンツＩＤが含まれている場合には、上述したステップＳ８０乃至ステップＳ８２の処理は行なわず、事前保存指示メッセージに含まれるコンテンツＩＤに基づいてクエリ送信を行ってもよい。なお。この場合も、事前保存指示されたコンテンツのレコードを取得してステップＳ８５にてローカルカタログ又は新規公開カタログ又は検索結果カタログに保存しなければならないため、ローカルカタログ又は新規公開カタログ又は検索結果カタログを検索し、レコードを取得する処理は行なわなければならない。

また、ステップＳ８０又はステップＳ８１にて、事前保存指示されたコンテンツのレコードが、ローカルカタログ又は新規公開カタログ又は検索結果カタログに保存されていると判定されている場合には、「レコード保存処理（Ｂ）」は行なわなくともよい。

以上説明したように、本実施形態によれば、各ノードＮｎが、ローカルカタログだけでなく、検索される可能性が高い新規公開予定のコンテンツのカタログ情報を新規公開カタログとして記憶するよう構成したので、上記ステップＳ１３でカタログ検索を行なう際に、これらのカタログ情報を参照することができ、コンテンツデータの検索を簡便且つ迅速に行なうことができる。

さらに、本実施形態では、上記ステップＳ１６の「レコード保存処理（Ａ）」にて検索の結果ヒットした検索結果のコンテンツのレコードを検索結果カタログとして記憶したので、過去に検索した経験のある、いわば、ユーザーの好みにあったコンテンツのレコードが記憶された検索結果カタログを参照して、より簡便且つ迅速にコンテンツデータの検索を行なうことができる。

また、ノードＮｎは、上記ステップＳ３０及びステップＳ４０にて、保存対象のレコードが自己の担当範囲のコンテンツのレコードであるか否かを判定し、自己の担当範囲のコンテンツのレコードで無い場合にのみ、新規公開カタログや検索結果カタログに保存するよう構成したので、ローカルカタログとの重複記憶を防ぐことができる。

さらに、ステップＳ５０にて、新規公開カタログが記憶される新規公開検索情報記憶領域に保存対象のレコードを記憶できる所定の記憶容量があるか否かを判定し、所定の記憶容量が無い場合には、ステップＳ５２にて所定の規則に従って削除レコードとして選択されたレコードを新規公開カタログから削除して、保存対象のレコードを新規公開カタログに記憶するよう構成したので、新規公開カタログに保存対象のレコードを確実に記憶させることができる。

更に、ステップＳ５２にて、新規公開カタログに記憶されているレコードのうち、公開日時が一番未来のレコードを削除レコードとして選択、新規公開カタログから削除するよう構成した。これにより、新規公開カタログから削除しても比較的影響が少ないレコードを削除して保存対象のレコードを新規公開カタログに確実に保存させることができる。なお、新規公開カタログに記憶されているレコードのうち、当該レコードの公開日時の現在日時との時間差が大きいレコードから順に削除するよう構成してもよい。また、公開日時が未来であるか過去であるかを問わず、現在日時との時間差が大きいレコードから順に削除するよう構成してもよい。

また、管理サーバ等からマルチキャスト送信されたレコードを受信して、ローカルカタログ又は新規公開カタログ又は検索結果カタログに記憶するよう構成したので、受信したレコードが自己の担当範囲であれば、ローカルカタログに登録、更新を行ない、新規公開カタログ又は検索結果カタログに登録されているレコードであれば、受信したレコードを用いて更新を行なうことができる。

更に、上記ステップＳ６２で、検索結果と共に新規公開コンテンツのレコードを、検索要求メッセージの送信元の他のノードＮｎに送信し、これを受信した他のノードＮｎは、ステップ１７及びステップＳ１８で受信したレコードを保存するよう構成したので、管理サーバ又は投入サーバ等から新規公開コンテンツのレコードが新規登録メッセージとして各ノードにマルチキャスト送信された際に、ノードＮｎが稼動していなかった場合など、何らかの原因で当該メッセージを受信できず、自己の担当範囲のコンテンツのレコードが記憶できなかったとしても、各ノードＮｎ間で検索結果と共に新規公開コンテンツのレコードを教えあうことで、各ノードＮｎが、自己の担当範囲のコンテンツのレコードをローカルカタログに洩れなく記憶することができる。さらに、記憶できなかった新規登録メッセージにかかるレコードが、自己の担当範囲のコンテンツのレコードで無いとしても、各ノードＮｎ間で検索結果と共に新規公開コンテンツのレコードを教えあうことができるので、新規公開コンテンツのレコードを新規公開カタログに確実に記憶させることができる。

また、ローカルカタログ又は新規公開カタログ又は検索結果カタログが保存される領域を、担当検索情報記憶領域と新規公開検索情報記憶領域と検索結果検索情報記憶領域としてそれぞれ別個に設けたので、例えば、検索結果を記憶させることから大量のレコードが検索結果として得られた場合であっても、当該レコードを検索結果カタログに保存することに起因するローカルカタログ又は新規公開カタログからのレコードの追い出しを防止することができる。

なお、記憶部１２のコンテンツデータキャッシュ領域に記憶したコンテンツデータのレコードを保存コンテンツカタログとして記憶してもよい。この場合、コンテンツデータキャッシュ領域に記憶したコンテンツデータを他のノードＮｎに送信する際など、コンテンツデータの公開日時のチェックを行なう場合に、ローカルカタログ、新規公開カタログ又は検索結果カタログよりも先に保存コンテンツカタログを参照してレコード検索を行なえば、より迅速にチェックすることができる。

なお、保存コンテンツカタログを記憶する場合には、当該保存コンテンツカタログが記憶される記憶検索情報記憶領域を記憶部１２に新たに設けることとする。この記憶検索情報記憶領域は、担当検索情報記憶領域と新規公開検索情報記憶領域と検索結果検索情報記憶領域等と同じ記憶容量としてもよく、或いは、記憶検索情報記憶領域の記憶容量を１００Ｍバイトとし、担当検索情報記憶領域と新規公開検索情報記憶領域を５０Ｍバイトとし、検索結果検索情報記憶領域を３０Ｍバイトとする等、記憶検索情報記憶領域の記憶容量を他の領域の記憶容量よりも大きくすれば、コンテンツデータキャッシュ領域に記憶したコンテンツデータのレコードを確実に記憶させることができる。なお、新規公開検索情報記憶領域の記憶容量（記憶可能容量）を担当検索情報記憶領域の記憶容量（記憶可能容量）よりも大きくすれば、ローカルカタログのレコードよりも検索される確率の高い新規公開カタログのレコードを多く記憶させることができる。

また、記憶部１２に上記保存コンテンツカタログを記憶する際には、コンテンツデータをコンテンツデータキャッシュ領域に記憶する際に、当該コンテンツデータのレコードを取得して保存コンテンツカタログに保存すればよい。なお、「コンテンツデータをコンテンツデータキャッシュ領域に記憶する際」とは、例えばコンテンツデータの取得した後でもよく、或いは、取得するコンテンツデータを選択する際等、コンテンツデータの取得前であってもよい。

なお、上記コンテンツ分散保存システムＳは、ＤＨＴを利用したアルゴリズムによって形成されることを前提として説明したが、本発明はこれに限定されるものではない。

３ ＩＸ
４ａ、４ｂ ＩＳＰ
５ａ、５ｂ ＤＳＬ回線業者
６ ＦＴＴＨ回線業者
７ 通信回線
８ ネットワーク
９ オーバーレイネットワーク（Ｐ２Ｐネットワーク）
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
２０ 通信部
２１ 入力部
２２ バス
Ｎｎ ノード

Claims (9)

1. ネットワークを介して互いに通信可能な複数のノード装置を備え、前記複数のノード装置間で利用可能な複数のコンテンツデータにそれぞれに対応する検索情報を各前記ノード装置間で分散して保存する情報通信システムに含まれる前記ノード装置であって、
   少なくとも前記コンテンツデータの公開日時を表す公開日時情報を含む前記検索情報を取得する検索情報取得手段と、
   前記検索情報取得手段により取得された検索情報が、所定の規則に従って定められた担当範囲の検索情報であるか否かを判定する検索情報判定手段と、
   前記検索情報判定手段により、前記担当範囲であると判定された検索情報を記憶する担当検索情報記憶手段と、
   前記公開日時情報に基づいて、前記取得された検索情報が、新規公開予定のコンテンツデータの検索情報であるか否かを判定する判定手段と、
   前記判定手段により新規公開予定のコンテンツデータの検索情報であると判定された場合、前記取得された検索情報を記憶する新規公開検索情報記憶手段と、
   前記担当検索情報記憶手段または前記新規公開検索情報記憶手段に記憶された検索情報に基づいて、前記コンテンツデータを検索するコンテンツデータ検索手段と、
   を有することを特徴とするノード装置。
2. 請求項１に記載のノード装置において、
   前記検索情報判定手段により、前記担当範囲の検索情報でないと判定されたとき、前記新規公開検索情報記憶手段は、前記判定された検索情報を記憶することを特徴とするノード装置。
3. 請求項１または請求項２に記載のノード装置において、
   前記新規公開検索情報記憶手段に前記検索情報を記憶できる所定の記憶容量があるか否かを判定する記憶判定手段と、
   前記記憶判定手段により、前記所定の記憶容量がないと判定されたとき、所定の規則に従って前記新規公開検索情報記憶手段から所定の前記検索情報を削除する検索情報削除手段とを備えることを特徴とするノード装置。
4. 請求項３に記載のノード装置において、
   現在の日時を表す現在日時情報を取得する現在日時取得手段を備え、
   前記検索情報削除手段は、前記所定の規則として前記現在日時情報と前記公開日時情報との時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置。
5. 請求項４に記載のノード装置において、
   前記検索情報削除手段は、前記現在日時情報より前記公開時刻情報が過去の日時であり、且つ、前記時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置。
6. 請求項４に記載のノード装置において、
   前記検索情報削除手段は、前記現在日時情報より前記公開時刻情報が未来の日時であり、且つ、前記時刻差が大きい前記公開日時情報を有する前記検索情報から順番に削除することを特徴とするノード装置。
7. 請求項１乃至請求項６の何れか一項に記載のノード装置において、
   前記新規公開検索情報記憶手段の記憶可能容量は、担当検索情報記憶手段の記憶可能容量よりも大きいことを特徴とするノード装置。
8. コンピュータを、請求項１乃至請求項７の何れか一項に記載のノード装置として機能させることを特徴とするノード処理プログラム。
9. ネットワークを介して互いに通信可能な複数のノード装置を備え、前記複数のノード装置間で利用可能な複数のコンテンツデータにそれぞれに対応する検索情報を各前記ノード装置間で分散して保存する情報通信システムに含まれる前記ノード装置における検索方法であって、
   少なくとも前記コンテンツデータの公開日時を表す公開日時情報を含む前記検索情報を取得する工程と、
   取得された検索情報が、所定の規則に従って定められた担当範囲の検索情報であるか否かを判定する工程と、
   前記担当範囲であると判定された検索情報を担当検索情報記憶手段に記憶する工程と、
   前記公開日時情報に基づいて、前記取得された検索情報が、新規公開予定のコンテンツデータの検索情報であるか否かを判定する工程と、
   新規公開予定のコンテンツデータの検索情報であると判定された場合、前記取得された検索情報を新規公開検索情報記憶手段に記憶する工程と、
   前記担当検索情報記憶手段または前記新規公開検索情報記憶手段に記憶された検索情報に基づいて、前記コンテンツデータを検索する工程と、
   を有することを特徴とする検索方法。

Images