JP2010108391A - ノード装置、ノード処理プログラム及び利用状況管理方法 - Google Patents

Abstract

【課題】コンテンツの利用状況を収集する処理にかかる負荷を複数のノード装置に分散させる。
【解決手段】ネットワークを介して互いに通信可能な複数のノード装置間で複数のコンテンツを利用可能に構成されたコンテンツ分散保存システムであって、前記ノード装置は、他の前記ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信する情報受信手段と、前記情報受信手段が受信した前記利用関連情報の宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該利用関連情報に係るコンテンツＩＤやコンテンツ名等のコンテンツデータを特定する情報を含む利用ログ情報を記録する利用ログ情報記録手段と、管理サーバからの利用ログ情報の送信要求に応じて、又は、所定の日時に至ると、前記利用ログ情報記録手段にて記録された前記利用ログ情報を前記管理サーバに送信する送信手段を有する。
【選択図】図４

Description

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

この種のピアツーピア型の通信システムにおいて、映画及び音楽等のコンテンツデータであって、複数のコンテンツの複製データ（以下、「レプリカ」という）を複数のノード装置に分散して保存（配置）させ、各ノード装置間でレプリカを利用可能とした分散保存システムが知られており、これにより、対故障性やアクセスの分散性が高められている。このように分散保存されたレプリカの所在は、例えば特許文献１に開示されるような分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用して効率良く検索可能になっている。

このようなコンテンツ分散保存システムにおいて、その利用率を向上させるために、コンテンツの視聴ランキング等を表示して人気のあるコンテンツを示すことで、ユーザに対して作品（コンテンツ）や作品に関する情報を検索する手間を省くサービスが考えられる。

このようなサービス等において、各コンテンツが視聴された回数を管理するために、視聴回数を集計管理する集計用のサーバ装置や、ＤＲＭ（Digital Right Management）等によりコンテンツに対して視聴制限を設け、当該視聴のためのライセンスキーを発行するサーバ装置をシステム内に設置させる方法が考えられる。
特開２００７−０３４６３０号公報

しかし、このような方法では、各ノード装置がコンテンツを視聴する毎にサーバ装置にアクセスがされるため、サーバ装置に過大な処理負担を課すこととなり、コンテンツ分散保存システムにて提供されるコンテンツが増えるほど、また、当該システムに参加するノード装置が増え、レプリカの数が増えるほど、この処理負担が増大し続けるという問題が生じる。

本発明は、このような問題等に鑑みてなされたものであり、コンテンツの利用状況を収集する処理にかかる負荷を複数のノード装置に分散させたノード装置、ノード処理プログラム及び利用状況管理方法を提供することを課題とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置間で複数のコンテンツデータを利用可能に構成されたコンテンツ分散保存システムであって、前記各コンテンツデータの利用状況を管理する管理サーバを備え、前記各ノード装置を識別するノードＩＤ等のノード装置識別情報であって、前記各コンテンツデータを識別するコンテンツＩＤ等のコンテンツ識別情報と所定の関係にある前記ノード装置識別情報を有するノード装置に、前記各コンテンツデータに関する情報が、それぞれ管理されるよう構成された前記コンテンツ分散保存システムにおける前記ノード装置であって、他の前記ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信する情報受信手段と、前記情報受信手段が受信した前記利用関連情報の宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該利用関連情報に係るコンテンツＩＤやコンテンツ名等のコンテンツデータを特定する情報を含む利用ログ情報を記録する利用ログ情報記録手段と、前記管理サーバからの利用ログ情報の送信要求に応じて、又は、所定の日時に至ると、前記利用ログ情報記録手段にて記録された前記利用ログ情報を前記管理サーバに送信する送信手段と、を有することを特徴とするノード装置である。

この発明によれば、コンテンツデータに関する情報を管理するノード装置が、各ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信して利用ログ情報として収集して記録し、管理サーバへ送信するよう構成したので、コンテンツの利用状況の収集にかかる負荷を複数のノード装置に分散させることができる。

上記課題を解決するために、請求項２に記載の発明は、請求項１に記載のノード装置であって、前記情報受信手段は、前記他のノード装置からコンテンツデータを保存している前記ノード装置のアドレス情報を問い合わせる所在問い合わせメッセージを前記利用関連情報として受信し、前記利用ログ情報記録手段は、前記所在問い合わせメッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該所在問い合わせメッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を利用ログ情報として記録することを特徴とするノード装置である。

この発明によれば、コンテンツデータに関する情報を管理するノード装置が、他のノード装置が送信した、コンテンツデータを保存しているノード装置を問い合わせる所在問い合わせメッセージ（クエリ）を利用関連情報として受信し、所在問い合わせメッセージにて問い合わされたコンテンツを特定する情報を利用ログ情報として記録することができるので、コンテンツデータに関する情報を管理するノード装置は、比較的容易な構成でコンテンツの利用状況の収集を行なうことができる。

上記課題を解決するために、請求項３に記載の発明は、請求項１に記載のノード装置であって、前記情報受信手段は、前記他のノード装置からコンテンツデータを当該他のノード装置にて保存したことを通知する保存通知メッセージを前記利用関連情報として受信し、前記利用ログ情報記録手段は、前記保存通知メッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該保存通知メッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を記録することを特徴とするノード装置である。

この発明によれば、コンテンツデータに関する情報を管理するノード装置が、他のノード装置が送信した、コンテンツデータを保存したことを通知する保存通知メッセージ（パブリッシュ）を利用関連情報として受信し、保存通知メッセージにて保存が通知されたコンテンツを特定する情報を利用ログ情報として記録することができるので、コンテンツデータに関する情報を管理するノード装置は、比較的容易な構成でコンテンツの利用状況の収集を行なうことができる。

上記課題を解決するために、請求項４に記載の発明は、請求項１に記載のノード装置であって、前記情報受信手段は、前記他のノード装置からコンテンツデータを視聴したことを通知する視聴通知メッセージを前記利用関連情報として受信し、前記利用ログ情報記録手段は、前記視聴通知メッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該視聴通知メッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を記録することを特徴とするノード装置である。

この発明によれば、コンテンツデータに関する情報を管理するノード装置が、他のノード装置が送信した、コンテンツデータを視聴したことを通知する視聴通知メッセージを利用関連情報として受信し、視聴通知メッセージにて視聴通知されたコンテンツを特定する情報を利用ログ情報として記録することができる。

上記課題を解決するために、請求項５に記載の発明は、請求項１乃至請求項４のいずれか一項に記載のノード装置であって、前記利用ログ情報記録手段は、前記利用関連情報を受信した日時を、当該利用関連情報に係るコンテンツデータを特定する情報と対応付けて前記利用ログ情報として記録することを特徴とするノード装置である。

この発明によれば、利用ログ情報として、コンテンツデータを特定する情報と対応付けて利用関連情報を受信した日時を記録するので、管理サーバにて、コンテンツデータのより詳細な利用状況を把握することができる。

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

上記課題を解決するために、請求項７に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置間で複数のコンテンツデータを利用可能に構成されたコンテンツ分散保存システムであって、前記各コンテンツデータの利用状況を管理する管理サーバを備え、前記各ノード装置を識別するノード装置識別情報であって、前記各コンテンツデータを識別するコンテンツ識別情報と所定の関係にある前記ノード装置識別情報を有するノード装置に、前記各コンテンツデータに関する情報が、それぞれ管理されるよう構成された前記コンテンツ分散保存システムにおける利用状況管理方法であって、前記ノード装置が、他の前記ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信する工程と、受信した前記利用関連情報の宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該利用関連情報に係るコンテンツデータを特定する情報を含む利用ログ情報を利用ログ情報記録手段に記録する工程と、前記管理サーバからの利用ログ情報の送信要求に応じて、又は、所定の日時に至ると、前記利用ログ情報記録手段に記録された前記利用ログ情報を前記管理サーバに送信する工程と、を有することを特徴とする利用状況管理方法である。

本発明によれば、コンテンツデータに関する情報を管理するノード装置が、各ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信して利用ログ情報として収集して記録し、管理サーバへ送信するよう構成したので、コンテンツの利用状況の収集にかかる負荷を複数のノード装置に分散させることができる。

以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、映画や音楽などのコンテンツが分散保存されたコンテンツ分散保存システムに本発明を適用した場合の実施形態である。

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

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

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

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

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

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

更に、コンテンツ分散保存システムＳは、各コンテンツの利用状況を管理する管理サーバＣＳを備える。

管理サーバＣＳは、各コンテンツのルートノードから、コンテンツが各ノードＮｎにて視聴（利用）されたことを示す利用ログ情報を受信して、コンテンツの利用報告を受ける。なお、ルートノードや利用ログ情報については後に詳細に説明する。

コンテンツ分散保存システムＳへの参加は、参加していないノードＮｎ（例えば、ノードＮ８）が、参加している任意のノードＮｎ（例えば、当該システムＳに常時参加しているコンタクトノード）に対して参加要求を示す参加メッセージを送信することによって行われる。

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

コンテンツ分散保存システムＳに参加している１台のノードＮｎは、該システムＳに参加している全てのノードＮｎのうち、必要最低限のノードＮｎのノード情報をルーティングテーブルに登録しておき、ノード情報を知らない（記憶していない）ノードＮｎについては、各ノードＮｎ間で互いに各種メッセージを転送し合って届けてもらうようになっている。

このようなＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

ところで、コンテンツ分散保存システムＳにおいては、内容の異なる様々なコンテンツ（例えば、映画や音楽等）の複製データ（レプリカ）が所定のファイル形式で複数のノードＮｎに分散して保存（格納）されており、各ノードＮｎ間で当該レプリカを利用可能になっている。例えば、ノードＮ５には、タイトルがＸＸＸの映画のコンテンツのレプリカが保存されており、一方、ノードＮ３には、タイトルがＹＹＹの映画のコンテンツのレプリカが保存されるというように、複数のノードＮｎ（以下、「コンテンツ保持ノード」という）に分散されて保存されている。

また、これらのコンテンツのレプリカには、夫々、コンテンツ名（タイトル）及びコンテンツＩＤ（コンテンツ毎に固有の識別情報（コンテンツ識別情報の一例））等の情報が付加されている。このコンテンツＩＤは、例えば、コンテンツ名＋任意の数値（或いは、コンテンツの先頭数バイトでも良い）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて生成される（ノードＩＤと同一のＩＤ空間に配置）。或いは、システム管理者が、コンテンツ毎に一意のＩＤ値（ノードＩＤと同一ビット長）を付与しても良い。この場合は、コンテンツ名とそのコンテンツＩＤの対応が書かれたコンテンツカタログ情報が、全ノードＮｎに配布される。

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

例えば、タイトルがＸＸＸの映画のコンテンツのレプリカについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ４により管理され、タイトルがＹＹＹの映画のコンテンツのレプリカについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ７により管理される。また、このようなルートノードは、例えば、コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する（所定の関係の一例）ノードＮｎであるように定められる。

そして、あるノードＮｎのユーザが、所望するコンテンツのレプリカを取得したい場合、当該レプリカの取得を望むノードＮｎ（以下、「ユーザノード」という）は、当該ユーザにより選択されたコンテンツのコンテンツＩＤ及び自己のアドレス情報（ＩＰアドレスなど）等を含むコンテンツ所在問合せ（検索）メッセージ（クエリ）を生成し、これを自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送出する。つまり、ユーザノードは、コンテンツ所在問合せメッセージを、ルートノードに向けて（ルートノード宛に）送出する（ルートノードにコンテンツのレプリカの所在を問い合わせる）。これにより、コンテンツ所在問合せ（検索）メッセージ（クエリ）は、コンテンツＩＤをキーとするＤＨＴルーティングによって最終的にルートノードに到着することになる。

なお、各ノードＮｎにおいてユーザにより選択されるべきコンテンツのコンテンツ名及びコンテンツＩＤ等の属性情報は、例えばコンテンツ分散保存システムＳを運営する運営者によるセンターサーバ（図示しない）から全てのノードＮｎに配信されるコンテンツカタログ情報に記述されている。

また、上記コンテンツ所在問合せメッセージに含まれるコンテンツＩＤは、ユーザノードによって、コンテンツ名が上記共通のハッシュ関数によりハッシュ化されて生成されるようにしても良い。なお、ＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

上記コンテンツ所在問合せ（検索）メッセージ（クエリ）を受信したルートノードは、これに含まれるコンテンツＩＤに対応するインデックス情報をインデックスキャッシュから取得して、当該インデックス情報を、該コンテンツ所在問合せメッセージ（クエリ）の送信元であるユーザノードに対して返信する。こうしてインデックス情報を取得したユーザノードは、当該インデックス情報に含まれるあるコンテンツ保持ノードのアドレス情報等に基づいて当該コンテンツ保持ノードにアクセスして、コンテンツ送信要求メッセージを送信し、そこからコンテンツのレプリカをダウンロード（取得）することが可能になる。なお、当該インデックス情報には、例えば複数のコンテンツ保持ノードのノード情報が含まれていることもある（同一のコンテンツのレプリカが複数のコンテンツ保持ノードに保存されている場合）。かかる場合、ユーザノードは、当該複数のコンテンツ保持ノードのうち一つのコンテンツ保持ノードを選択し、選択したコンテンツ保持ノードに接続してコンテンツのレプリカをダウンロードすることができる。

なお、ルートノードは、当該インデックス情報に含まれるアドレス情報等に示されたコンテンツ保持ノードに対してコンテンツ送信要求メッセージを送信し、これにより、ユーザノードは、上記コンテンツ保持ノードからそのレプリカをダウンロードすることもできる。

また、コンテンツ保持ノードから取得したコンテンツのレプリカを保存したユーザノードは、当該レプリカを保存したことをそのルートノードに知らせるために、当該レプリカのコンテンツＩＤ及び自己のノード情報が含まれる保存通知メッセージ（パブリッシュ）を生成し、該保存通知メッセージ（パブリッシュ）を、そのルートノードに向けて（ルートノード宛に）送出する。これにより、保存通知メッセージ（パブリッシュ）は、コンテンツ所在問合せ（検索）メッセージ（クエリ）と同じように、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになる。そして、該ルートノードは、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報を登録（インデックスキャッシュに記憶）することになる。こうして、上記ユーザノードは、新たに、上記コンテンツのレプリカを保持するコンテンツ保持ノードとなる。

なお、上記保存通知メッセージ（パブリッシュ）に含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報は、ルートノードに至るまでの転送経路におけるノードＮｎ（キャッシュノード）においても登録（キャッシュ）されるよう構成してもよい。この場合、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該キャッシュノードから当該インデックス情報を取得することもできる。

以上のようにルートノードはユーザノードから、コンテンツ所在問合せ（検索）メッセージ（以下、単に「クエリ」と言う）や、保存通知メッセージ（以下、単に「パブリッシュ」と言う）、又はコンテンツの視聴通知メッセージのコンテンツの利用に関連する情報である利用関連情報を受信すると、かかる利用関連情報を受信した日時やその他の情報（例えば、ユーザノードのノードＩＤ等）を、当該コンテンツを特定する情報（コンテンツＩＤやコンテンツ名）と対応付けて利用ログ情報として収集、記録する。

そして、各ルートノードは、収集した結果を、管理サーバＣＳからの要求に応じて、又は、定期的に（例えば、所定期間ごとに）管理サーバＣＳに送信する。

＜２. ルートノードによる利用ログ情報の収集＞
続いて、ルートノードによる利用ログ情報の収集について説明する。

ここでは、「クエリ」を「利用関連情報」とする場合、「パブリッシュ」を「利用関連情報」とする場合、「視聴通知メッセージ」を利用関連情報とする場合について、夫々説明する。

＜２−１．クエリを利用関連情報とする場合＞
図２は、ルートノードがクエリを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。当該図２は、オーバーレイネットワーク９に参加する各ノードＮｎを、各ノードＮｎのノードＩＤに基づいてＩＤ空間上に図示したものであって、反時計回りで（或いは時計回りで）ＩＤが増加するものとする。なお、以下に示す図３乃至図５においても同様である。

図２（Ａ）に示す例では、ノードＮ１４がユーザノードとなり、所望のコンテンツのコンテンツＩＤを含むクエリを当該コンテンツのルートノードに向けて送信している。

ノードＮ１４から送信されたクエリは、ルートノードであるノードＮ１０へ到達し、ルートノードであるノードＮ１０が、ノードＮ１４へクエリに含まれるコンテンツＩＤに対応するインデックス情報を自己のインデックスキャッシュから取得して、該クエリの送信元であるユーザノードに対して返信する。

そして、ルートノードであるノードＮ１０が、利用ログ情報として、クエリを受信した日時（受信日時）等を、当該コンテンツを特定する情報（コンテンツＩＤやコンテンツ名）と対応付けて記録する。

表１は、ルートノードが記録する利用ログ情報の一例であり、表１に示す例では、受信日時をコンテンツＩＤと対応付けて記録している。

なお、パブリッシュがルートノードに至るまでの転送経路におけるノードＮｎ（キャッシュノード）にも、コンテンツのインデックス情報が登録（キャッシュ）されるよう構成されている場合であって、当該キャッシュノードが、ユーザノードから送信されたクエリを受信した場合は、当該キャッシュノードがクエリに含まれるコンテンツＩＤに対応するインデックス情報を自己のインデックスキャッシュから取得して、ユーザノードに対して返信するよう構成する。

図２（Ｂ）に示す例では、キャッシュノードであるノードＮ１３が、ユーザノードに対してインデックス情報を返信している。

このように、キャッシュノードがインデックス情報を返信した場合にも、クエリはルートノードまで転送されるよう構成する。ルートノードが、当該コンテンツが検索された回数（ユーザノードからクエリが送信された回数）を洩れなく把握し、当該コンテンツの利用ログ情報を正確に記録するためである。

具体的には、キャッシュノードは、インデックス情報を返信後、クエリを他のノードＮｎへ転送する場合には、当該クエリに、インデックス情報が送信済みである旨を知らせる情報（例えば、フラグ「１」）を付加するよう構成する。クエリを受けたキャッシュノード又はルートノードは、インデックス情報が送信済みか否かをフラグ「１」の有無に基づいて判定し、インデックス情報が送信済みで無い場合にのみ、ユーザノードに対してインデックス情報を返信することができる。

＜２−２．パブリッシュを利用関連情報とする場合＞
図３は、ルートノードがパブリッシュを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。

図３に示す例では、ノードＮ１４がコンテンツ保持ノードであるノードＮ１８からコンテンツのレプリカを取得したので、当該コンテンツのコンテンツＩＤを含むパブリッシュを、当該コンテンツのルートノードに向けて送信している。

ノードＮ１４から送信されたパブリッシュは、ルートノードであるノードＮ１０へ到達し、ルートノードであるノードＮ１０が、利用ログ情報として、パブリッシュを受信した日時（受信日時）等を、当該コンテンツを特定する情報（コンテンツＩＤやコンテンツ名）と対応付けて記録する（表１参照）。

なお、コンテンツ保持ノードは、コンテンツのレプリカを保持（取得）した直後にパブリッシュを送信する他、定期的に（例えば、所定時間毎に）パブリッシュを送信するよう構成することもできる。パブリッシュの定期送信により、コンテンツのルートノードがコンテンツ分散保存システムＳを脱退した場合などに、新たなルートノードに対して確実にインデックス情報を登録させることができる。

このようなパブリッシュの定期送信は、コンテンツの視聴に伴う動作ではない。従って、ルートノードは、ユーザノードがコンテンツを視聴するために、当該コンテンツのレプリカを取得した直後に行なわれるパブリッシュのみを、利用ログ情報として記録するよう構成する。

具体的には、定期的に送信されるパブリッシュには、当該パブリッシュに、定期送信である旨を知らせる情報（例えば、フラグ「１」）を付加するよう構成し、ダウンロード直後に行なわれるパブリッシュと区別できるようにする。

ルートノードは、受信したパブリッシュに付加された情報（フラグ）を確認して、ダウンロード直後のパブリッシュである場合のみ、利用ログ情報を記録する。

＜２−３．視聴通知メッセージを利用関連情報とする場合＞
図４は、ルートノードが視聴通知メッセージを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。

図４に示す例では、ノードＮ１４が、視聴を所望するコンテンツのレプリカを再生したときに（再生ボタン押下後など）、かかるコンテンツのコンテンツＩＤを含む視聴通知メッセージを、当該コンテンツのルートノードに向けて送信している。

ノードＮ１４から送信された視聴通知メッセージは、ルートノードであるノードＮ１０へ到達し、ルートノードであるノードＮ１０が、利用ログ情報として、視聴通知メッセージを受信した日時（受信日時）等を、当該コンテンツを特定する情報（コンテンツＩＤやコンテンツ名）と対応付けて記録する（表１参照）。

＜２−４．管理サーバＣＳへのコンテンツ利用報告＞
ルートノードは、上述の如く収集した利用ログ情報を管理サーバＣＳへ送信することにより、コンテンツの利用状況を管理サーバＣＳへ報告する。

図５（Ａ）に示す例では、管理サーバＣＳは、利用報告を所望するコンテンツのコンテンツＩＤを含む利用ログ情報要求メッセージを、かかるコンテンツのルートノードに向けて送信している。

利用ログ情報要求メッセージは、ルートノードであるノードＮ１０へ到達し、ノードＮ１０が、収集（記録）した利用ログ情報の中から、利用ログ情報要求メッセージに含まれるコンテンツＩＤの利用ログ情報を抽出して、管理サーバＣＳへ送信する。

なお、図５（Ｂ）に示す如く、ルートノードが収集（記録）した全ての利用ログ情報を定期的に（例えば、所定時間毎に）管理サーバＣＳへ送信するよう構成してもよい。

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

図６は、ノードＮｎの概要構成例を示す図である。

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

また、コンテンツ分散保存システムＳが、当該システムＳに参加する際のアクセス先となるコンタクトノードを備えている場合には、記憶部１２には当該コンタクトノードのアドレス情報（ＩＰアドレス及びポート番号など）等が記憶されている。更に、記憶部１２には、保存（記録）しているコンテンツのレプリカに関する情報（タイトル、コンテンツＩＤ等）を登録するための保存レプリカ管理テーブルが記憶されている。

記憶部１２は、インデックスキャッシュ、利用ログ情報を記録するための利用ログ情報記録手段としての記録ホルダを含んで構成される。

インデックスキャッシュには、自己が所在を管理するコンテンツの保持ノードであるノードＮｎのノード情報（ＩＰアドレスなどのアドレス情報を含む）と当該コンテンツのコンテンツＩＤの組が含まれるインデックス情報が記憶されている。

利用ログ情報記録ホルダは、自己が所在を管理するコンテンツの利用ログ情報を記録（格納）するためのものである。

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

また、制御部１１は、本発明における情報受信手段、利用ログ情報記録手段及び送信手段等として機能する。

なお、上記ノード処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。

＜４．各ノードＮｎの処理＞
続いて、各ノードＮｎにおける処理を、図を参照して詳しく説明する。

利用関連情報の種類や、管理サーバＣＳへのコンテンツ利用報告の方法が異なる以下の４つの実施例について説明する。
＜実施例１＞「クエリ」又は「パブリッシュ」を「利用関連情報」とし、管理サーバＣＳからの要求に応じてコンテンツ利用報告が行なわれる場合
＜実施例２＞「クエリ」又は「パブリッシュ」を「利用関連情報」とし、定期的に管理サーバＣＳにコンテンツ利用報告が行なわれる場合
＜実施例３＞「視聴通知メッセージ」を「利用関連情報」とし、管理サーバＣＳからの要求に応じてコンテンツ利用報告が行なわれる場合
＜実施例４＞「視聴通知メッセージ」を「利用関連情報」とし、定期的に管理サーバＣＳにコンテンツ利用報告が行なわれる場合

＜４−１．実施例１＞
初めに、「クエリ」又は「パブリッシュ」を「利用関連情報」とし、管理サーバＣＳからの要求に応じてコンテンツ利用報告が行なわれる場合の各ノードＮｎにおける処理を説明する。

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

先ず、制御部１１は、入力部２１を通じてユーザから視聴を所望するコンテンツを指定して再生指示がされたか否かを判定し（ステップＳ１０）、再生指示がされた場合には（ステップＳ１０：Ｙｅｓ）、指定されたコンテンツのコンテンツＩＤを含むクエリを生成し、当該コンテンツのルートノードに向けて生成したクエリを送信する（ステップＳ１１）。

次いで、ルートノードからコンテンツ保持ノードのインデックス情報を受信する（ステップＳ１２）と、インデックス情報に含まれるコンテンツ保持ノードのアドレス情報等に従い、コンテンツ保持ノードにコンテンツ送信要求メッセージを送信し（ステップＳ１３）、コンテンツ保持ノードからコンテンツのレプリカを取得（ダウンロード）して記憶部１２に記憶する（ステップＳ１４）。そして、取得したコンテンツのレプリカの再生処理を行なう。

続いて、取得したコンテンツ（レプリカ）のコンテンツＩＤを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する「パブリッシュ送信処理」を行なう（ステップＳ１５）。

「パブリッシュ送信処理」は、「クエリ」を「利用関連情報」とする場合には、ルーティングテーブルを参照して生成したパブリッシュを送信する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ送信処理」は後に図を用いて詳述する。

ステップＳ１０にて、再生指示がされていない場合には（ステップＳ１０：Ｎｏ）、他のノードＮｎからクエリを受信したか否かを判定し（ステップＳ１６）、クエリを受信した場合（ステップＳ１６：Ｙｅｓ）には、「クエリ受信処理」を行なう（ステップＳ１７）。

「クエリ受信処理」は、「パブリッシュ」を「利用関連情報」とする場合には、記憶部１２を参照して受信したクエリに含まれるコンテンツＩＤのインデックス情報が登録されていれば、当該インデックス情報をクエリの送信元のノードＮｎに返信し、登録されていなければ、ルーティングテーブルを参照してクエリを他のノードＮｎに転送する。一方、「クエリ」を「利用関連情報」とする場合の「クエリ受信処理」は後に図を用いて詳述する。

ステップＳ１６にて、クエリを受信していない場合には（ステップＳ１６：Ｎｏ）、他のノードＮｎからパブリッシュを受信したか否かを判定し（ステップＳ１８）、パブリッシュを受信した場合（ステップＳ１８：Ｙｅｓ）には、「パブリッシュ受信処理」を行なう（ステップＳ１９）。

「パブリッシュ受信処理」は、「クエリ」を「利用関連情報」とする場合には、受信したパブリッシュに含まれるコンテンツＩＤのインデックス情報を自己のインデックスクスキャッシュに登録する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ受信処理」は後に図を用いて詳述する。

ステップＳ１８にて、パブリッシュを受信していない場合には（ステップＳ１８：Ｎｏ）、利用ログ情報要求メッセージを受信したか否かを判定し（ステップＳ２０）、利用ログ情報要求メッセージを受信した場合（ステップＳ２０：Ｙｅｓ）には、「利用ログ情報要求メッセージ受信処理」を行なう（ステップＳ２１）。なお、「利用ログ情報要求メッセージ受信処理」については後に図を用いて詳述する。

そして、利用ログ情報要求メッセージを受信していない場合には（ステップＳ２０：Ｎｏ）、その他のメッセージを受信したか否かを判定し（ステップＳ２２）、その他のメッセージを受信した場合（ステップＳ２２：Ｙｅｓ）には、その他のメッセージに応じた処理を行なう（ステップＳ２３）。例えば、コンテンツ送信要求メッセージを受信した場合には、メッセージに含まれるコンテンツＩＤのレプリカを送信する。

ステップＳ２２にて、その他のメッセージを受信していない場合には（ステップＳ２２：Ｎｏ）、記憶部１２に記憶しているレプリカについて、パブリッシュの定期送信をすべき時刻か否かを判定する（ステップＳ２４）。所定時間毎にパブリッシュを送信する場合には、前回送信時刻から所定時間経過したか否かに基づいて判定すればよい。

判定の結果、パブリッシュの定期送信時刻である場合には（ステップＳ２４：Ｙｅｓ）、当該レプリカのコンテンツＩＤを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する「パブリッシュ送信処理」を行なう（ステップＳ２５）。

「パブリッシュ送信処理」は、「クエリ」を「利用関連情報」とする場合には、ルーティングテーブルを参照して生成したパブリッシュを送信する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ送信処理」は後に図を用いて詳述する。

なお、記憶部１２に記憶している全てのレプリカについて、パブリッシュの定期送信時刻であるか否かを判定し、定期送信時刻であればパブリッシュを送信するよう構成する。

そして、記憶部１２に記憶している全てのレプリカがパブリッシュの定期送信時刻でない場合（ステップＳ２４：Ｎｏ）、及び、ステップＳ１５、Ｓ１７、Ｓ１９、Ｓ２１、Ｓ２３及びＳ２５の処理の後、ステップＳ２６に移行して、電源がオフとなるまでステップＳ１０からステップＳ２６の処理を繰り返し行なう。

そして、電源がオフとなった場合に（ステップＳ２６：Ｙｅｓ）、処理を終了する。

＜４−１−１．「パブリッシュ」を「利用関連情報」とする場合の、ステップＳ１５及びステップＳ２５のパブリッシュ送信処理＞
図８は、上記ステップＳ１５及びステップＳ２５の「パブリッシュ送信処理」を示すフローチャートである。

かかる処理は、「パブリッシュ」を「利用関連情報」とする場合に、ステップＳ１５及びステップＳ２５にて行なわれる処理である。

先ず、制御部１１は、パブリッシュの定期送信か否かを判定する（ステップＳ３０）。

当該処理が、ステップＳ１５の「パブリッシュ送信処理」である場合には、上記ステップＳ１４でコンテンツのレプリカをダウンロードしたことによるパブリッシュであり、パブリッシュの定期送信でないため（ステップＳ３０：Ｎｏ）、ステップＳ３２の処理に移行する。

一方、ステップＳ２５の「パブリッシュ送信処理」である場合、つまり、ステップＳ２４の判定で、パブリッシュの定期送信時刻であると判定された場合には、パブリッシュの定期送信であるため（ステップＳ３０：Ｙｅｓ）、パブリッシュに定期送信である旨を知らせるためのフラグ「１」を付加する（ステップＳ３１）。

そして、パブリッシュをルートノードに向けて送信し（ステップＳ３２）、処理を終了する。

＜４−１−２．「クエリ」を「利用関連情報」とする場合の、ステップＳ１７のクエリ受信処理＞
図９は、上記ステップＳ１７の「クエリ受信処理」を示すフローチャートである。

かかる処理は、「クエリ」を「利用関連情報」とする場合に、ステップＳ１７にて行なわれる処理である。

先ず、制御部１１は、受信したクエリの転送先があるか否かに基づいて、自身がクエリに含まれるコンテンツＩＤのルートノードか否かを判定する（ステップＳ４０）。クエリの転送先がない場合にはルートノードであると判定され（ステップＳ４０：Ｙｅｓ）、クエリに含まれるコンテンツＩＤに対応するインデックス情報が、当該クエリの送信元であるユーザノードに送信済みであるか否かを判定する（ステップＳ４１）。具体的には、クエリにインデックス情報が送信済みである旨を知らせるためのフラグ「１」が付加されているか否かに基づいて判定され、フラグ「１」が付加されている場合には、インデックス情報は送信済みである（ステップＳ４１：Ｙｅｓ）ため、ステップＳ４３へ移行する。

一方、クエリにフラグ「１」が付加されていない場合には、インデックス情報は送信済みでない（ステップＳ４１：Ｎｏ）ので、記憶部１２のインデックスキャッシュからインデックス情報を取得して、クエリの送信元であるユーザノードに送信する（ステップＳ４２）。

次いで、制御部１１は、クエリに含まれるコンテンツＩＤにクエリの受信日時等を対応付けて利用ログ情報として記憶部１２の記録ホルダに記録し（ステップＳ４３）、処理を終了する。

一方、自身がルートノードでないと判定された場合（ステップＳ４０：Ｎｏ）、クエリに含まれるコンテンツＩＤに対応するインデックス情報が、当該クエリの送信元であるユーザノードに送信済みであるか否かを判定する（ステップＳ４４）。判定方法はステップＳ４１と同様である。

判定の結果、インデックス情報が送信済みである場合（ステップＳ４４：Ｙｅｓ）には、記憶部１２のルーティングテーブルを参照してクエリを他のノードＮｎに転送し（ステップＳ４５）、処理を終了する。

一方、インデックス情報が送信済みで無い場合（ステップＳ４４：Ｎｏ）には、記憶部１２のインデックスキャッシュに、該当するインデックス情報が登録（キャッシュ）されているか否かを判定し（ステップＳ４６）、登録されていない場合（ステップＳ４６：Ｎｏ）には、記憶部１２のルーティングテーブルを参照してクエリを他のノードＮｎに転送し（ステップＳ４９）、処理を終了する。

そして、記憶部１２のインデックスキャッシュに、該当するインデックス情報が登録されている場合には（ステップＳ４６：Ｙｅｓ）、インデックスキャッシュから当該インデックス情報を取得して、クエリの送信元であるユーザノードに送信する（ステップＳ４７）。

次いで、クエリにフラグ「１」を付加し（ステップＳ４８）、記憶部１２のルーティングテーブルを参照してクエリを他のノードＮｎに転送し（ステップＳ４９）、処理を終了する。

＜４−１−３．「パブリッシュ」を「利用関連情報」とする場合の、ステップＳ１９のパブリッシュ受信処理＞
図１０は、上記ステップＳ１９の「パブリッシュ受信処理」を示すフローチャートである。

かかる処理は、「パブリッシュ」を「利用関連情報」とする場合に、ステップＳ１９にて行なわれる処理である。

先ず、制御部１１は、パブリッシュに含まれるインデックス情報を、記憶部１２のインデックスキャッシュに登録する（ステップＳ５０）。

続いて、受信したパブリッシュの転送先があるか否かに基づいて、自身がパブリッシュに含まれるコンテンツＩＤのルートノードか否かを判定する（ステップＳ５１）。パブリッシュの転送先がない場合にはルートノードであると判定され（ステップＳ５１：Ｙｅｓ）、次いで、受信したパブリッシュが定期送信されたものであるか否かを判定する（ステップＳ５２）。具体的には、制御部１１は、パブリッシュに定期送信である旨を知らせるためのフラグ「１」が付加されているか否かに基づいて判定し、フラグ「１」が付加されている場合には、定期送信である（ステップＳ５２：Ｙｅｓ）ため、処理を終了する。

一方、パブリッシュにフラグ「１」が付加されていない場合には、定期送信でない（ステップＳ５２：Ｎｏ）ため、パブリッシュに含まれるコンテンツＩＤにパブリッシュの受信日時等を対応付けて利用ログ情報として記憶部１２の記録ホルダに記録して（ステップＳ５３）、処理を終了する。

そして、ステップＳ５１の判定において、自身がルートノードでないと判定された場合（ステップＳ５１：Ｎｏ）には、記憶部１２のルーティングテーブルを参照して、パブリッシュを他のノードＮｎに転送し（ステップＳ５４）、処理を終了する。

＜４−１−４．ステップＳ２１の利用ログ情報要求メッセージ受信処理＞
図１１は、上記ステップＳ２１の「利用ログ情報要求メッセージ受信処理」を示すフローチャートである。

先ず、制御部１１は、受信した利用ログ情報要求メッセージの転送先があるか否かに基づいて、自身が利用ログ情報要求メッセージに含まれるコンテンツＩＤのルートノードか否かを判定する（ステップＳ６１）。利用ログ情報要求メッセージの転送先がない場合にはルートノードであると判定され（ステップＳ６１：Ｙｅｓ）、記憶部１２の記録ホルダに記録した利用ログ情報のうち、受信した利用ログ情報要求メッセージに含まれるコンテンツＩＤの利用ログ情報を抽出して、管理サーバＣＳへ送信し（ステップＳ６２）、処理を終了する。

一方、自身がルートノードでないと判定された場合（ステップＳ６１：Ｎｏ）には、記憶部１２のルーティングテーブルを参照して、利用ログ情報要求メッセージを他のノードＮｎに転送し（ステップＳ６２）、処理を終了する。

＜４−２．実施例２＞
続いて、「クエリ」又は「パブリッシュ」を「利用関連情報」とし、定期的に管理サーバＣＳにコンテンツ利用報告が行なわれる場合の各ノードＮｎにおける処理を説明する。

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

かかる実施例２におけるノードＮｎの処理は、図７を用いて説明した実施例１の処理中の、利用ログ情報要求メッセージの受信にかかるステップＳ２０及びステップＳ２１の処理に相当する処理がなく、新たに、コンテンツの利用報告時刻か否かを判定して利用ログ情報を管理サーバＣＳへ送信する処理（ステップＳ１２２及びＳ１２３）が追加されている。その他の処理は実施例１の処理と同様であるため説明を省略する。

具体的には、図１２中、ステップＳ１１０乃至ステップＳ１１９の処理は、図７を用いて説明したステップＳ１０乃至ステップＳ１９の処理と同様であり、ステップＳ１２０及びステップＳ１２１の処理は、ステップＳ２２及びステップＳ２３の処理と同様であり、ステップＳ１２４乃至ステップＳ１２６の処理は、ステップＳ２４乃至ステップＳ２６の処理と同様である。

本実施例では、ステップＳ１２１にて、その他のメッセージを受信していないと判定されると（ステップＳ１２１：Ｎｏ）、ステップＳ１２２の処理に移行し、コンテンツの利用報告時刻か否かを判定する（ステップＳ１２２）。所定時間毎にコンテンツの利用報告を行なう場合には、前回送信時刻から所定時間経過したか否かに基づいて判定すればよく、予め定められた日時にコンテンツの利用報告を行なう場合には、予め定められた日時であるか否かに基づいて判定すればよい。

判定の結果、コンテンツの利用報告時刻である場合には（ステップＳ１２２：Ｙｅｓ）、記憶部１２の記録ホルダから利用ログ情報を取得して管理サーバＣＳに送信し（ステップＳ１２３）、ステップＳ１２６へ移行する。

一方、コンテンツの利用報告時刻でない場合（ステップＳ１２２：Ｎｏ）には、ステップＳ１２４へ移行する。

＜４−３．実施例３＞
続いて、実施例３の「視聴通知メッセージ」を「利用関連情報」とし、管理サーバＣＳからの要求に応じてコンテンツ利用報告が行なわれる場合の各ノードＮｎにおける処理を説明する。

図１３は、コンテンツ分散保存システムＳに参加している任意のノードＮｎにおける制御部１１のメイン処理を示すフローチャートであり、コンテンツ分散保存システムＳへの参加後に本発明のノード処理プログラムが読み出され処理が開始する。なお、上述した実施例１と同様の処理については説明を省略する。

先ず、制御部１１は、入力部２１を通じてユーザから視聴を所望するコンテンツを指定して再生指示がされたか否かを判定し（ステップＳ２１０）、再生指示がされた場合には（ステップＳ２１０：Ｙｅｓ）、指定されたコンテンツのコンテンツＩＤを含むクエリを生成し、当該コンテンツのルートノードに向けて生成したクエリを送信する（ステップＳ２１１）。

次いで、ルートノードからコンテンツ保持ノードのインデックス情報を受信する（ステップＳ２１２）と、コンテンツ保持ノードにコンテンツ送信要求メッセージを送信し（ステップＳ２１３）、コンテンツ保持ノードからコンテンツのレプリカを取得（ダウンロード）して記憶部１２に記憶する（ステップＳ２１４）。そして、取得したコンテンツのレプリカについて再生処理を行なう。

続いて、取得したコンテンツ（レプリカ）のコンテンツＩＤを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信（ステップＳ２１５）する。

そして、取得したコンテンツ（レプリカ）のコンテンツＩＤを含む視聴通知メッセージを生成し、当該コンテンツのルートノードに向けて生成した視聴通知メッセージを送信（ステップＳ２１６）し、ステップＳ２２９へ移行する。

一方、再生指示がされていない場合には（ステップＳ２１０：Ｎｏ）、他のノードＮｎからクエリを受信したか否かを判定し（ステップＳ２１７）、クエリを受信した場合（ステップＳ２１７：Ｙｅｓ）には、クエリに応じた処理を行なう（ステップＳ２１８）。具体的には、記憶部１２を参照して受信したクエリに含まれるコンテンツＩＤのインデックス情報が登録されていれば、当該インデックス情報をクエリの送信元のノードＮｎに返信し、登録されていなければ、ルーティングテーブルを参照してクエリを他のノードＮｎに転送する。

クエリを受信していない場合には（ステップＳ２１７：Ｎｏ）、他のノードＮｎからパブリッシュを受信したか否かを判定し（ステップＳ２１９）、パブリッシュを受信した場合（ステップＳ２１９：Ｙｅｓ）には、パブリッシュに応じた処理を行なう（ステップＳ２２０）。具体的には、受信したパブリッシュに含まれるコンテンツＩＤのインデックス情報を自己のインデックスクスキャッシュに登録する。

パブリッシュを受信していない場合には（ステップＳ２１９：Ｎｏ）、利用ログ情報要求メッセージを受信したか否かを判定し（ステップＳ２２１）、利用ログ情報要求メッセージを受信した場合（ステップＳ２２１：Ｙｅｓ）には、「利用ログ情報要求メッセージ受信処理」を行なう（ステップＳ２２２）。

利用ログ情報要求メッセージを受信していない場合には（ステップＳ２２１：Ｎｏ）、視聴通知メッセージを受信したか否かを判定し（ステップＳ２２３）、視聴通知メッセージを受信した場合（ステップＳ２２３：Ｙｅｓ）には、「視聴通知メッセージ受信処理」を行なう（ステップＳ２２４）。なお、「視聴通知メッセージ受信処理」は、後に図を用いて詳述する。

そして、視聴通知メッセージを受信していない場合には（ステップＳ２２３：Ｎｏ）、その他のメッセージを受信したか否かを判定し（ステップＳ２２５）、その他のメッセージを受信した場合（ステップＳ２２５：Ｙｅｓ）には、その他のメッセージに応じた処理を行なう（ステップＳ２２６）。

その他のメッセージを受信していない場合には（ステップＳ２２５：Ｎｏ）、記憶部１２に記憶しているレプリカについて、パブリッシュの定期送信時刻か否かを判定する（ステップＳ２２７）。

判定の結果、パブリッシュの定期送信時刻である場合には（ステップＳ２２７：Ｙｅｓ）、当該レプリカのコンテンツＩＤを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する（ステップＳ２２８）。このとき、パブリッシュにフラグ「１」を付加して送信する。

そして、パブリッシュの定期送信時刻でない場合（ステップＳ２２７：Ｎｏ）、及び、ステップＳ２１６、ステップＳ２１８、Ｓ２２０、Ｓ２２２、Ｓ２２４、Ｓ２２６及びＳ２２８の処理の後、ステップＳ２２９に移行して、電源がオフとなるまでステップＳ２１０からステップＳ２２９の処理を繰り返し行なう。

そして、電源がオフとなった場合に（ステップＳ２２９：Ｙｅｓ）、処理を終了する。

＜４−３−１．ステップＳ２２４の視聴通知メッセージ受信処理＞
図１４は、上記ステップＳ２２４の「視聴通知メッセージ受信処理」を示すフローチャートである。

先ず、制御部１１は、受信した視聴通知メッセージの転送先があるか否かに基づいて、自身が視聴通知メッセージに含まれるコンテンツＩＤのルートノードか否かを判定する（ステップＳ２５０）。視聴通知メッセージの転送先がない場合にはルートノードであると判定され（ステップＳ２５０：Ｙｅｓ）、視聴通知メッセージに含まれるコンテンツＩＤにパブリッシュの受信日時等を対応付けて利用ログ情報として記憶部１２の記録ホルダに記録して（ステップＳ２５１）、処理を終了する。

そして、ステップＳ２５０の判定において、自身がルートノードでないと判定された場合（ステップＳ２５０：Ｎｏ）には、記憶部１２のルーティングテーブルを参照して、視聴通知メッセージを他のノードＮｎに転送し（ステップＳ２５２）、処理を終了する。

＜４−４．実施例４＞
続いて、「視聴通知メッセージ」を「利用関連情報」とし、定期的に管理サーバＣＳにコンテンツ利用報告が行なわれる場合の各ノードＮｎにおける処理を説明する。

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

かかる実施例４におけるノードＮｎの処理は、図１３を用いて説明した実施例３の処理中の、利用ログ情報要求メッセージの受信にかかるステップＳ２２１及びステップＳ２２２の処理に相当する処理がなく、新たに、コンテンツの利用報告時刻か否かを判定して利用ログ情報を管理サーバＣＳへ送信する処理（ステップＳ３２５及びＳ３２６）が追加されている。その他の処理は実施例３の処理と同様であるため説明を省略する。

具体的には、図１５中、ステップＳ３１０乃至ステップＳ３２０の処理は、図１３を用いて説明したステップＳ２１０乃至ステップＳ２２０の処理と同様であり、ステップＳ３２１乃至ステップＳ３２４の処理は、ステップＳ２２３乃至ステップＳ２２６の処理と同様であり、ステップＳ３２７乃至ステップＳ３２９の処理は、ステップＳ２２７乃至ステップＳ２２９の処理と同様である。

本実施例では、ステップＳ３２３にて、その他のメッセージを受信していないと判定されると（ステップＳ３２３：Ｎｏ）、ステップＳ３２５の処理に移行し、コンテンツの利用報告時刻か否かを判定する（ステップＳ３２５）。判定方法は実施例２のステップＳ１２２と同様であるため説明を省略する。

判定の結果、コンテンツの利用報告時刻である場合には（ステップＳ３２５：Ｙｅｓ）、記憶部１２の記録ホルダから利用ログ情報を取得して管理サーバＣＳに送信して（ステップＳ３２６）、ステップＳ３２９へ移行し、一方、コンテンツの利用報告時刻でない場合（ステップＳ３２５：Ｎｏ）には、ステップＳ３２７へ移行する。

以上説明したように、各コンテンツのルートノードが、各ノードＮｎから、コンテンツの利用に関連する利用関連情報を受信すると、当該コンテンツのコンテンツＩＤ等を含む利用ログ情報を記録し、管理サーバＣＳからの要求に応じて、又は定期的に管理サーバへ送信するよう構成したので、コンテンツの利用状況の収集にかかる負荷を複数のノードＮｎにて分散させることができる。

また、クエリやパブリッシュを利用関連情報として利用するよう構成すれば、各コンテンツのルートノードは、コンテンツの利用状況を通知する別途のメッセージの送受信などを行なうことなく、コンテンツの利用ログ情報を記録することができる。

また、各ノードＮｎにてコンテンツの視聴が行なわれた際に、利用関連情報として視聴が行なわれたコンテンツのコンテンツＩＤを含む視聴通知メッセージをルートノードに送信し、ルートノードは当該視聴通知メッセージを利用関連情報として利用ログ情報を記録するよう構成することもできる。

さらに、ルートノードは、利用ログ情報として、利用関連情報を受信した日時をコンテンツＩＤと対応付けて記録することにより、ルートノードから利用状況報告を受けた管理サーバＣＳは、より詳細な利用状況を把握することができる。

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

本実施形態に係るコンテンツ分散保存システムＳにおける各ノード装置の接続態様の一例を示す図である。 ルートノードがクエリを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。 ルートノードがパブリッシュを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。 ルートノードが視聴通知メッセージを利用関連情報として、利用ログ情報を収集（記録）する様子を示す概念図である。 ルートノードがコンテンツの利用状況を管理サーバＣＳへ報告する様子を示す概念図である。 ノードＮｎの概要構成例を示すブロック図である。 実施例１のノードＮｎにおける制御部１１のメイン処理を示すフローチャートである。 「パブリッシュ」を「利用関連情報」とする場合の、ステップＳ１５及びステップＳ２５の「パブリッシュ送信処理」を示すフローチャートである。 「クエリ」を「利用関連情報」とする場合の、ステップＳ１７の「クエリ受信処理」を示すフローチャートである。 「パブリッシュ」を「利用関連情報」とする場合の、ステップＳ１９の「パブリッシュ受信処理」を示すフローチャートである。 ステップＳ２１の「利用ログ情報要求メッセージ受信処理」を示すフローチャートである。 実施例２のノードＮｎにおける制御部１１のメイン処理を示すフローチャートである。 実施例３のノードＮｎにおける制御部１１のメイン処理を示すフローチャートである。 ステップＳ２２４の「視聴通知メッセージ受信処理」を示すフローチャートである。 実施例４のノードＮｎにおける制御部１１のメイン処理を示すフローチャートである。

符号の説明

８ ネットワーク
９ オーバーレイネットワーク（Ｐ２Ｐネットワーク）
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
２０ 通信部
２１ 入力部
２２ バス
Ｓ コンテンツ分散保存システム
Ｎｎ ノード
ＣＳ 管理サーバ

Claims (7)

1. ネットワークを介して互いに通信可能な複数のノード装置間で複数のコンテンツデータを利用可能に構成されたコンテンツ分散保存システムであって、前記各コンテンツデータの利用状況を管理する管理サーバを備え、前記各ノード装置を識別するノード装置識別情報であって、前記各コンテンツデータを識別するコンテンツ識別情報と所定の関係にある前記ノード装置識別情報を有するノード装置に、前記各コンテンツデータに関する情報が、それぞれ管理されるよう構成された前記コンテンツ分散保存システムにおける前記ノード装置であって、
   他の前記ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信する情報受信手段と、
   前記情報受信手段が受信した前記利用関連情報の宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該利用関連情報に係るコンテンツデータを特定する情報を含む利用ログ情報を記録する利用ログ情報記録手段と、
   前記管理サーバからの利用ログ情報の送信要求に応じて、又は、所定の日時に至ると、前記利用ログ情報記録手段にて記録された前記利用ログ情報を前記管理サーバに送信する送信手段と、
   を有することを特徴とするノード装置。
2. 請求項１に記載のノード装置であって、
   前記情報受信手段は、前記他のノード装置からコンテンツデータを保存している前記ノード装置のアドレス情報を問い合わせる所在問い合わせメッセージを前記利用関連情報として受信し、
   前記利用ログ情報記録手段は、前記所在問い合わせメッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該所在問い合わせメッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を利用ログ情報として記録することを特徴とするノード装置。
3. 請求項１に記載のノード装置であって、
   前記情報受信手段は、前記他のノード装置からコンテンツデータを当該他のノード装置にて保存したことを通知する保存通知メッセージを前記利用関連情報として受信し、
   前記利用ログ情報記録手段は、前記保存通知メッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該保存通知メッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を記録することを特徴とするノード装置。
4. 請求項１に記載のノード装置であって、
   前記情報受信手段は、前記他のノード装置からコンテンツデータを視聴したことを通知する視聴通知メッセージを前記利用関連情報として受信し、
   前記利用ログ情報記録手段は、前記視聴通知メッセージの宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該視聴通知メッセージに係るコンテンツデータを特定する情報を含む前記利用ログ情報を記録することを特徴とするノード装置。
5. 請求項１乃至請求項４のいずれか一項に記載のノード装置であって、
   前記利用ログ情報記録手段は、前記利用関連情報を受信した日時を、当該利用関連情報に係るコンテンツデータを特定する情報と対応付けて前記利用ログ情報として記録することを特徴とするノード装置。
6. コンピュータを、請求項１乃至５の何れか一項に記載のノード装置として機能させることを特徴とするノード処理プログラム。
7. ネットワークを介して互いに通信可能な複数のノード装置間で複数のコンテンツデータを利用可能に構成されたコンテンツ分散保存システムであって、前記各コンテンツデータの利用状況を管理する管理サーバを備え、前記各ノード装置を識別するノード装置識別情報であって、前記各コンテンツデータを識別するコンテンツ識別情報と所定の関係にある前記ノード装置識別情報を有するノード装置に、前記各コンテンツデータに関する情報が、それぞれ管理されるよう構成された前記コンテンツ分散保存システムにおける利用状況管理方法であって、
   前記ノード装置が、他の前記ノード装置からコンテンツデータの利用に関連する情報である利用関連情報を受信する工程と、
   受信した前記利用関連情報の宛先と自ノード装置のノード装置識別情報とが前記所定の関係にある場合、当該利用関連情報に係るコンテンツデータを特定する情報を含む利用ログ情報を利用ログ情報記録手段に記録する工程と、
   前記管理サーバからの利用ログ情報の送信要求に応じて、又は、所定の日時に至ると、前記利用ログ情報記録手段に記録された前記利用ログ情報を前記管理サーバに送信する工程と、
   を有することを特徴とする利用状況管理方法。

Images