以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、映画や音楽などのコンテンツが分散保存されたコンテンツ分散保存システムに本発明を適用した場合の実施形態である。
<1.コンテンツ分散保存システムの構成及び動作概要>
始めに、図1等を参照して、本実施形態に係るコンテンツ分散保存システムの構成及び動作概要について説明する。
図1は、本実施形態に係るコンテンツ分散保存システムにおける各ノード装置の接続態様の一例を示す図である。
図1の下部枠101内に示すように、IX(Internet eXchange)3、ISP(Internet Service Provider)4a,4b、DSL(Digital Subscriber Line)回線事業者(の装置)5a,5b、FTTH(Fiber To The Home)回線事業者(の装置)6、及び通信回線(例えば、電話回線や光ケーブル等)7等によって、インターネット等のネットワーク(現実世界の通信ネットワーク)8が構築されている。なお、図1の例におけるネットワーク8には、データ(パケット)を転送するためのルータが、適宜挿入されているが図示を省略している。
このようなネットワーク8には、複数のノード装置(以下、「ノード」という)Nn(n=1,2,3・・・の何れか)が接続されている。また、各ノードNnには、固有の製造番号およびIP(Internet Protocol)アドレスが割り当てられている。そして、本実施形態に係るコンテンツ分散保存システムSは、これらのノードNnのうち、図1の上部枠100内に示すように、何れか複数のノードNnの参加により形成されるピアツーピア方式のネットワークシステムとなっている。
なお、図1の上部枠100内に示すネットワーク9は、既存のネットワーク8を用いて形成された仮想的なリンクを構成するオーバーレイネットワーク9(論理的なネットワーク)である。かかるオーバーレイネットワーク9は、特定のアルゴリズム、例えば、DHTを利用したアルゴリズムにより実現される。そして、コンテンツ分散保存システムS(言い換えれば、オーバーレイネットワーク9)に参加している各ノードNnには、所定桁数からなる固有の識別情報であるノードID(ノード装置識別情報の一例)が割り当てられている。
また、当該ノードIDは、例えば、各ノードNnに個別に割り当てられたIPアドレス或いは製造番号を共通のハッシュ関数(例えば、SHA−1等)によりハッシュ化した値(例えば、bit長が160bit)であり、一つのID空間に偏りなく分散して配置されることになる。
更に、コンテンツ分散保存システムSは、各コンテンツの利用状況を管理する管理サーバCSを備える。
管理サーバCSは、各コンテンツのルートノードから、コンテンツが各ノードNnにて視聴(利用)されたことを示す利用ログ情報を受信して、コンテンツの利用報告を受ける。なお、ルートノードや利用ログ情報については後に詳細に説明する。
コンテンツ分散保存システムSへの参加は、参加していないノードNn(例えば、ノードN8)が、参加している任意のノードNn(例えば、当該システムSに常時参加しているコンタクトノード)に対して参加要求を示す参加メッセージを送信することによって行われる。
また、各ノードNnは、夫々、DHTを用いたルーティングテーブルを保持している。このルーティングテーブルは、コンテンツ分散保存システムS上における各種メッセージの転送先を規定しており、具体的には、ID空間内で適度に離れたノードNnのノードID、アドレス情報(IPアドレス及びポート番号等)を含むノード情報が複数登録されている。
コンテンツ分散保存システムSに参加している1台のノードNnは、該システムSに参加している全てのノードNnのうち、必要最低限のノードNnのノード情報をルーティングテーブルに登録しておき、ノード情報を知らない(記憶していない)ノードNnについては、各ノードNn間で互いに各種メッセージを転送し合って届けてもらうようになっている。
このようなDHTを用いたルーティングテーブルについては、特開2006−197400号公報等で公知であるので、詳しい説明を省略する。
ところで、コンテンツ分散保存システムSにおいては、内容の異なる様々なコンテンツ(例えば、映画や音楽等)の複製データ(レプリカ)が所定のファイル形式で複数のノードNnに分散して保存(格納)されており、各ノードNn間で当該レプリカを利用可能になっている。例えば、ノードN5には、タイトルがXXXの映画のコンテンツのレプリカが保存されており、一方、ノードN3には、タイトルがYYYの映画のコンテンツのレプリカが保存されるというように、複数のノードNn(以下、「コンテンツ保持ノード」という)に分散されて保存されている。
また、これらのコンテンツのレプリカには、夫々、コンテンツ名(タイトル)及びコンテンツID(コンテンツ毎に固有の識別情報(コンテンツ識別情報の一例))等の情報が付加されている。このコンテンツIDは、例えば、コンテンツ名+任意の数値(或いは、コンテンツの先頭数バイトでも良い)が、上記ノードIDを得るときと共通のハッシュ関数によりハッシュ化されて生成される(ノードIDと同一のID空間に配置)。或いは、システム管理者が、コンテンツ毎に一意のID値(ノードIDと同一ビット長)を付与しても良い。この場合は、コンテンツ名とそのコンテンツIDの対応が書かれたコンテンツカタログ情報が、全ノードNnに配布される。
また、このように分散保存されているコンテンツのレプリカの所在、つまり、当該レプリカを保存したノードNnのノード情報と当該コンテンツのコンテンツID等の組が含まれるインデックス情報が、当該コンテンツのレプリカの所在を管理しているノードNn(以下、「ルートノード」、又は「コンテンツ(コンテンツID)のルートノード」という)等により記憶(インデックスキャッシュに記憶)、管理されるようになっている。
例えば、タイトルがXXXの映画のコンテンツのレプリカについてのインデックス情報は、そのコンテンツ(コンテンツID)のルートノードであるノードN4により管理され、タイトルがYYYの映画のコンテンツのレプリカについてのインデックス情報は、そのコンテンツ(コンテンツID)のルートノードであるノードN7により管理される。また、このようなルートノードは、例えば、コンテンツIDと最も近い(例えば、上位桁がより多く一致する)ノードIDを有する(所定の関係の一例)ノードNnであるように定められる。
そして、あるノードNnのユーザが、所望するコンテンツのレプリカを取得したい場合、当該レプリカの取得を望むノードNn(以下、「ユーザノード」という)は、当該ユーザにより選択されたコンテンツのコンテンツID及び自己のアドレス情報(IPアドレスなど)等を含むコンテンツ所在問合せ(検索)メッセージ(クエリ)を生成し、これを自己のDHTを用いたルーティングテーブルにしたがって他のノードNnに対して送出する。つまり、ユーザノードは、コンテンツ所在問合せメッセージを、ルートノードに向けて(ルートノード宛に)送出する(ルートノードにコンテンツのレプリカの所在を問い合わせる)。これにより、コンテンツ所在問合せ(検索)メッセージ(クエリ)は、コンテンツIDをキーとするDHTルーティングによって最終的にルートノードに到着することになる。
なお、各ノードNnにおいてユーザにより選択されるべきコンテンツのコンテンツ名及びコンテンツID等の属性情報は、例えばコンテンツ分散保存システムSを運営する運営者によるセンターサーバ(図示しない)から全てのノードNnに配信されるコンテンツカタログ情報に記述されている。
また、上記コンテンツ所在問合せメッセージに含まれるコンテンツIDは、ユーザノードによって、コンテンツ名が上記共通のハッシュ関数によりハッシュ化されて生成されるようにしても良い。なお、DHTルーティングについては、特開2006−197400号公報等で公知であるので、詳しい説明を省略する。
上記コンテンツ所在問合せ(検索)メッセージ(クエリ)を受信したルートノードは、これに含まれるコンテンツIDに対応するインデックス情報をインデックスキャッシュから取得して、当該インデックス情報を、該コンテンツ所在問合せメッセージ(クエリ)の送信元であるユーザノードに対して返信する。こうしてインデックス情報を取得したユーザノードは、当該インデックス情報に含まれるあるコンテンツ保持ノードのアドレス情報等に基づいて当該コンテンツ保持ノードにアクセスして、コンテンツ送信要求メッセージを送信し、そこからコンテンツのレプリカをダウンロード(取得)することが可能になる。なお、当該インデックス情報には、例えば複数のコンテンツ保持ノードのノード情報が含まれていることもある(同一のコンテンツのレプリカが複数のコンテンツ保持ノードに保存されている場合)。かかる場合、ユーザノードは、当該複数のコンテンツ保持ノードのうち一つのコンテンツ保持ノードを選択し、選択したコンテンツ保持ノードに接続してコンテンツのレプリカをダウンロードすることができる。
なお、ルートノードは、当該インデックス情報に含まれるアドレス情報等に示されたコンテンツ保持ノードに対してコンテンツ送信要求メッセージを送信し、これにより、ユーザノードは、上記コンテンツ保持ノードからそのレプリカをダウンロードすることもできる。
また、コンテンツ保持ノードから取得したコンテンツのレプリカを保存したユーザノードは、当該レプリカを保存したことをそのルートノードに知らせるために、当該レプリカのコンテンツID及び自己のノード情報が含まれる保存通知メッセージ(パブリッシュ)を生成し、該保存通知メッセージ(パブリッシュ)を、そのルートノードに向けて(ルートノード宛に)送出する。これにより、保存通知メッセージ(パブリッシュ)は、コンテンツ所在問合せ(検索)メッセージ(クエリ)と同じように、コンテンツIDをキーとするDHTルーティングによってルートノードに到着することになる。そして、該ルートノードは、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツIDの組を含むインデックス情報を登録(インデックスキャッシュに記憶)することになる。こうして、上記ユーザノードは、新たに、上記コンテンツのレプリカを保持するコンテンツ保持ノードとなる。
なお、上記保存通知メッセージ(パブリッシュ)に含まれるノード情報及びコンテンツIDの組を含むインデックス情報は、ルートノードに至るまでの転送経路におけるノードNn(キャッシュノード)においても登録(キャッシュ)されるよう構成してもよい。この場合、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該キャッシュノードから当該インデックス情報を取得することもできる。
以上のようにルートノードはユーザノードから、コンテンツ所在問合せ(検索)メッセージ(以下、単に「クエリ」と言う)や、保存通知メッセージ(以下、単に「パブリッシュ」と言う)、又はコンテンツの視聴通知メッセージのコンテンツの利用に関連する情報である利用関連情報を受信すると、かかる利用関連情報を受信した日時やその他の情報(例えば、ユーザノードのノードID等)を、当該コンテンツを特定する情報(コンテンツIDやコンテンツ名)と対応付けて利用ログ情報として収集、記録する。
そして、各ルートノードは、収集した結果を、管理サーバCSからの要求に応じて、又は、定期的に(例えば、所定期間ごとに)管理サーバCSに送信する。
<2. ルートノードによる利用ログ情報の収集>
続いて、ルートノードによる利用ログ情報の収集について説明する。
ここでは、「クエリ」を「利用関連情報」とする場合、「パブリッシュ」を「利用関連情報」とする場合、「視聴通知メッセージ」を利用関連情報とする場合について、夫々説明する。
<2−1.クエリを利用関連情報とする場合>
図2は、ルートノードがクエリを利用関連情報として、利用ログ情報を収集(記録)する様子を示す概念図である。当該図2は、オーバーレイネットワーク9に参加する各ノードNnを、各ノードNnのノードIDに基づいてID空間上に図示したものであって、反時計回りで(或いは時計回りで)IDが増加するものとする。なお、以下に示す図3乃至図5においても同様である。
図2(A)に示す例では、ノードN14がユーザノードとなり、所望のコンテンツのコンテンツIDを含むクエリを当該コンテンツのルートノードに向けて送信している。
ノードN14から送信されたクエリは、ルートノードであるノードN10へ到達し、ルートノードであるノードN10が、ノードN14へクエリに含まれるコンテンツIDに対応するインデックス情報を自己のインデックスキャッシュから取得して、該クエリの送信元であるユーザノードに対して返信する。
そして、ルートノードであるノードN10が、利用ログ情報として、クエリを受信した日時(受信日時)等を、当該コンテンツを特定する情報(コンテンツIDやコンテンツ名)と対応付けて記録する。
表1は、ルートノードが記録する利用ログ情報の一例であり、表1に示す例では、受信日時をコンテンツIDと対応付けて記録している。
なお、パブリッシュがルートノードに至るまでの転送経路におけるノードNn(キャッシュノード)にも、コンテンツのインデックス情報が登録(キャッシュ)されるよう構成されている場合であって、当該キャッシュノードが、ユーザノードから送信されたクエリを受信した場合は、当該キャッシュノードがクエリに含まれるコンテンツIDに対応するインデックス情報を自己のインデックスキャッシュから取得して、ユーザノードに対して返信するよう構成する。
図2(B)に示す例では、キャッシュノードであるノードN13が、ユーザノードに対してインデックス情報を返信している。
このように、キャッシュノードがインデックス情報を返信した場合にも、クエリはルートノードまで転送されるよう構成する。ルートノードが、当該コンテンツが検索された回数(ユーザノードからクエリが送信された回数)を洩れなく把握し、当該コンテンツの利用ログ情報を正確に記録するためである。
具体的には、キャッシュノードは、インデックス情報を返信後、クエリを他のノードNnへ転送する場合には、当該クエリに、インデックス情報が送信済みである旨を知らせる情報(例えば、フラグ「1」)を付加するよう構成する。クエリを受けたキャッシュノード又はルートノードは、インデックス情報が送信済みか否かをフラグ「1」の有無に基づいて判定し、インデックス情報が送信済みで無い場合にのみ、ユーザノードに対してインデックス情報を返信することができる。
<2−2.パブリッシュを利用関連情報とする場合>
図3は、ルートノードがパブリッシュを利用関連情報として、利用ログ情報を収集(記録)する様子を示す概念図である。
図3に示す例では、ノードN14がコンテンツ保持ノードであるノードN18からコンテンツのレプリカを取得したので、当該コンテンツのコンテンツIDを含むパブリッシュを、当該コンテンツのルートノードに向けて送信している。
ノードN14から送信されたパブリッシュは、ルートノードであるノードN10へ到達し、ルートノードであるノードN10が、利用ログ情報として、パブリッシュを受信した日時(受信日時)等を、当該コンテンツを特定する情報(コンテンツIDやコンテンツ名)と対応付けて記録する(表1参照)。
なお、コンテンツ保持ノードは、コンテンツのレプリカを保持(取得)した直後にパブリッシュを送信する他、定期的に(例えば、所定時間毎に)パブリッシュを送信するよう構成することもできる。パブリッシュの定期送信により、コンテンツのルートノードがコンテンツ分散保存システムSを脱退した場合などに、新たなルートノードに対して確実にインデックス情報を登録させることができる。
このようなパブリッシュの定期送信は、コンテンツの視聴に伴う動作ではない。従って、ルートノードは、ユーザノードがコンテンツを視聴するために、当該コンテンツのレプリカを取得した直後に行なわれるパブリッシュのみを、利用ログ情報として記録するよう構成する。
具体的には、定期的に送信されるパブリッシュには、当該パブリッシュに、定期送信である旨を知らせる情報(例えば、フラグ「1」)を付加するよう構成し、ダウンロード直後に行なわれるパブリッシュと区別できるようにする。
ルートノードは、受信したパブリッシュに付加された情報(フラグ)を確認して、ダウンロード直後のパブリッシュである場合のみ、利用ログ情報を記録する。
<2−3.視聴通知メッセージを利用関連情報とする場合>
図4は、ルートノードが視聴通知メッセージを利用関連情報として、利用ログ情報を収集(記録)する様子を示す概念図である。
図4に示す例では、ノードN14が、視聴を所望するコンテンツのレプリカを再生したときに(再生ボタン押下後など)、かかるコンテンツのコンテンツIDを含む視聴通知メッセージを、当該コンテンツのルートノードに向けて送信している。
ノードN14から送信された視聴通知メッセージは、ルートノードであるノードN10へ到達し、ルートノードであるノードN10が、利用ログ情報として、視聴通知メッセージを受信した日時(受信日時)等を、当該コンテンツを特定する情報(コンテンツIDやコンテンツ名)と対応付けて記録する(表1参照)。
<2−4.管理サーバCSへのコンテンツ利用報告>
ルートノードは、上述の如く収集した利用ログ情報を管理サーバCSへ送信することにより、コンテンツの利用状況を管理サーバCSへ報告する。
図5(A)に示す例では、管理サーバCSは、利用報告を所望するコンテンツのコンテンツIDを含む利用ログ情報要求メッセージを、かかるコンテンツのルートノードに向けて送信している。
利用ログ情報要求メッセージは、ルートノードであるノードN10へ到達し、ノードN10が、収集(記録)した利用ログ情報の中から、利用ログ情報要求メッセージに含まれるコンテンツIDの利用ログ情報を抽出して、管理サーバCSへ送信する。
なお、図5(B)に示す如く、ルートノードが収集(記録)した全ての利用ログ情報を定期的に(例えば、所定時間毎に)管理サーバCSへ送信するよう構成してもよい。
<3.ノードNnの構成及び機能>
次に、図6を参照して、ノードNnの構成及び機能について説明する。
図6は、ノードNnの概要構成例を示す図である。
各ノードNnは、図6に示すように、演算機能を有するCPU,作業用RAM,各種データおよびプログラムを記憶するROM等から構成されたコンピュータとしての制御部11と、各種データ(例えば、コンテンツのレプリカ、インデックスキャッシュ、ルーティングテーブル等)及び各種プログラム等を記憶保存(格納)するためのハードディスク等から構成された記憶部12と、受信されたコンテンツのレプリカ等を一時蓄積するバッファメモリ13と、コンテンツのレプリカに含まれるエンコードされたビデオデータ(映像情報)およびオーディオデータ(音声情報)等をデコード(データ伸張や復号化等)するデコーダ部14と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部15と、当該映像処理部15から出力されたビデオ信号に基づき映像表示するCRT,液晶ディスプレイ等の表示部16と、上記デコードされたオーディオデータをアナログオーディオ信号にD(Digital)/A(Analog)変換した後これをアンプにより増幅して出力する音声処理部17と、当該音声処理部17から出力されたオーディオ信号を音波として出力するスピーカ18と、ネットワーク8を通じて他のノードNn等間の情報の通信制御を行なうための通信部20と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部11に対して与える入力部(例えば、キーボード、マウス、或いは、操作パネル等)21と、を備えて構成され、制御部11、記憶部12、バッファメモリ13、デコーダ部14、通信部20、及び入力部21はバス22を介して相互に接続されている。なお、ノードNnとしては、パーソナルコンピュータ、STB(Set Top Box)、或いは、TV受信機等を適用可能である。
また、コンテンツ分散保存システムSが、当該システムSに参加する際のアクセス先となるコンタクトノードを備えている場合には、記憶部12には当該コンタクトノードのアドレス情報(IPアドレス及びポート番号など)等が記憶されている。更に、記憶部12には、保存(記録)しているコンテンツのレプリカに関する情報(タイトル、コンテンツID等)を登録するための保存レプリカ管理テーブルが記憶されている。
記憶部12は、インデックスキャッシュ、利用ログ情報を記録するための利用ログ情報記録手段としての記録ホルダを含んで構成される。
インデックスキャッシュには、自己が所在を管理するコンテンツの保持ノードであるノードNnのノード情報(IPアドレスなどのアドレス情報を含む)と当該コンテンツのコンテンツIDの組が含まれるインデックス情報が記憶されている。
利用ログ情報記録ホルダは、自己が所在を管理するコンテンツの利用ログ情報を記録(格納)するためのものである。
このような構成において、制御部11は、CPUが記憶部12等に記憶されたプログラム(本発明のノード処理プログラムを含む)を読み出して実行することにより、全体を統括制御し、コンテンツ分散保存システムSへの参加により上述したユーザノード、中継ノード、ルートノード、コンテンツ保持ノード、キャッシュノードの少なくとも何れか一つのノードとしての処理を行なうようになっている。
また、制御部11は、本発明における情報受信手段、利用ログ情報記録手段及び送信手段等として機能する。
なお、上記ノード処理プログラムは、例えば、ネットワーク8上の所定のサーバからダウンロードされるようにしてもよいし、例えば、CD−ROM等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。
<4.各ノードNnの処理>
続いて、各ノードNnにおける処理を、図を参照して詳しく説明する。
利用関連情報の種類や、管理サーバCSへのコンテンツ利用報告の方法が異なる以下の4つの実施例について説明する。
<実施例1>「クエリ」又は「パブリッシュ」を「利用関連情報」とし、管理サーバCSからの要求に応じてコンテンツ利用報告が行なわれる場合
<実施例2>「クエリ」又は「パブリッシュ」を「利用関連情報」とし、定期的に管理サーバCSにコンテンツ利用報告が行なわれる場合
<実施例3>「視聴通知メッセージ」を「利用関連情報」とし、管理サーバCSからの要求に応じてコンテンツ利用報告が行なわれる場合
<実施例4>「視聴通知メッセージ」を「利用関連情報」とし、定期的に管理サーバCSにコンテンツ利用報告が行なわれる場合
<4−1.実施例1>
初めに、「クエリ」又は「パブリッシュ」を「利用関連情報」とし、管理サーバCSからの要求に応じてコンテンツ利用報告が行なわれる場合の各ノードNnにおける処理を説明する。
図7は、コンテンツ分散保存システムSに参加している任意のノードNnにおける制御部11のメイン処理を示すフローチャートであり、コンテンツ分散保存システムSへの参加後(例えば、コンタクトノードへのアクセスの後)に本発明のノード処理プログラムが読み出され処理が開始する。
先ず、制御部11は、入力部21を通じてユーザから視聴を所望するコンテンツを指定して再生指示がされたか否かを判定し(ステップS10)、再生指示がされた場合には(ステップS10:Yes)、指定されたコンテンツのコンテンツIDを含むクエリを生成し、当該コンテンツのルートノードに向けて生成したクエリを送信する(ステップS11)。
次いで、ルートノードからコンテンツ保持ノードのインデックス情報を受信する(ステップS12)と、インデックス情報に含まれるコンテンツ保持ノードのアドレス情報等に従い、コンテンツ保持ノードにコンテンツ送信要求メッセージを送信し(ステップS13)、コンテンツ保持ノードからコンテンツのレプリカを取得(ダウンロード)して記憶部12に記憶する(ステップS14)。そして、取得したコンテンツのレプリカの再生処理を行なう。
続いて、取得したコンテンツ(レプリカ)のコンテンツIDを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する「パブリッシュ送信処理」を行なう(ステップS15)。
「パブリッシュ送信処理」は、「クエリ」を「利用関連情報」とする場合には、ルーティングテーブルを参照して生成したパブリッシュを送信する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ送信処理」は後に図を用いて詳述する。
ステップS10にて、再生指示がされていない場合には(ステップS10:No)、他のノードNnからクエリを受信したか否かを判定し(ステップS16)、クエリを受信した場合(ステップS16:Yes)には、「クエリ受信処理」を行なう(ステップS17)。
「クエリ受信処理」は、「パブリッシュ」を「利用関連情報」とする場合には、記憶部12を参照して受信したクエリに含まれるコンテンツIDのインデックス情報が登録されていれば、当該インデックス情報をクエリの送信元のノードNnに返信し、登録されていなければ、ルーティングテーブルを参照してクエリを他のノードNnに転送する。一方、「クエリ」を「利用関連情報」とする場合の「クエリ受信処理」は後に図を用いて詳述する。
ステップS16にて、クエリを受信していない場合には(ステップS16:No)、他のノードNnからパブリッシュを受信したか否かを判定し(ステップS18)、パブリッシュを受信した場合(ステップS18:Yes)には、「パブリッシュ受信処理」を行なう(ステップS19)。
「パブリッシュ受信処理」は、「クエリ」を「利用関連情報」とする場合には、受信したパブリッシュに含まれるコンテンツIDのインデックス情報を自己のインデックスクスキャッシュに登録する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ受信処理」は後に図を用いて詳述する。
ステップS18にて、パブリッシュを受信していない場合には(ステップS18:No)、利用ログ情報要求メッセージを受信したか否かを判定し(ステップS20)、利用ログ情報要求メッセージを受信した場合(ステップS20:Yes)には、「利用ログ情報要求メッセージ受信処理」を行なう(ステップS21)。なお、「利用ログ情報要求メッセージ受信処理」については後に図を用いて詳述する。
そして、利用ログ情報要求メッセージを受信していない場合には(ステップS20:No)、その他のメッセージを受信したか否かを判定し(ステップS22)、その他のメッセージを受信した場合(ステップS22:Yes)には、その他のメッセージに応じた処理を行なう(ステップS23)。例えば、コンテンツ送信要求メッセージを受信した場合には、メッセージに含まれるコンテンツIDのレプリカを送信する。
ステップS22にて、その他のメッセージを受信していない場合には(ステップS22:No)、記憶部12に記憶しているレプリカについて、パブリッシュの定期送信をすべき時刻か否かを判定する(ステップS24)。所定時間毎にパブリッシュを送信する場合には、前回送信時刻から所定時間経過したか否かに基づいて判定すればよい。
判定の結果、パブリッシュの定期送信時刻である場合には(ステップS24:Yes)、当該レプリカのコンテンツIDを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する「パブリッシュ送信処理」を行なう(ステップS25)。
「パブリッシュ送信処理」は、「クエリ」を「利用関連情報」とする場合には、ルーティングテーブルを参照して生成したパブリッシュを送信する。一方、「パブリッシュ」を「利用関連情報」とする場合の「パブリッシュ送信処理」は後に図を用いて詳述する。
なお、記憶部12に記憶している全てのレプリカについて、パブリッシュの定期送信時刻であるか否かを判定し、定期送信時刻であればパブリッシュを送信するよう構成する。
そして、記憶部12に記憶している全てのレプリカがパブリッシュの定期送信時刻でない場合(ステップS24:No)、及び、ステップS15、S17、S19、S21、S23及びS25の処理の後、ステップS26に移行して、電源がオフとなるまでステップS10からステップS26の処理を繰り返し行なう。
そして、電源がオフとなった場合に(ステップS26:Yes)、処理を終了する。
<4−1−1.「パブリッシュ」を「利用関連情報」とする場合の、ステップS15及びステップS25のパブリッシュ送信処理>
図8は、上記ステップS15及びステップS25の「パブリッシュ送信処理」を示すフローチャートである。
かかる処理は、「パブリッシュ」を「利用関連情報」とする場合に、ステップS15及びステップS25にて行なわれる処理である。
先ず、制御部11は、パブリッシュの定期送信か否かを判定する(ステップS30)。
当該処理が、ステップS15の「パブリッシュ送信処理」である場合には、上記ステップS14でコンテンツのレプリカをダウンロードしたことによるパブリッシュであり、パブリッシュの定期送信でないため(ステップS30:No)、ステップS32の処理に移行する。
一方、ステップS25の「パブリッシュ送信処理」である場合、つまり、ステップS24の判定で、パブリッシュの定期送信時刻であると判定された場合には、パブリッシュの定期送信であるため(ステップS30:Yes)、パブリッシュに定期送信である旨を知らせるためのフラグ「1」を付加する(ステップS31)。
そして、パブリッシュをルートノードに向けて送信し(ステップS32)、処理を終了する。
<4−1−2.「クエリ」を「利用関連情報」とする場合の、ステップS17のクエリ受信処理>
図9は、上記ステップS17の「クエリ受信処理」を示すフローチャートである。
かかる処理は、「クエリ」を「利用関連情報」とする場合に、ステップS17にて行なわれる処理である。
先ず、制御部11は、受信したクエリの転送先があるか否かに基づいて、自身がクエリに含まれるコンテンツIDのルートノードか否かを判定する(ステップS40)。クエリの転送先がない場合にはルートノードであると判定され(ステップS40:Yes)、クエリに含まれるコンテンツIDに対応するインデックス情報が、当該クエリの送信元であるユーザノードに送信済みであるか否かを判定する(ステップS41)。具体的には、クエリにインデックス情報が送信済みである旨を知らせるためのフラグ「1」が付加されているか否かに基づいて判定され、フラグ「1」が付加されている場合には、インデックス情報は送信済みである(ステップS41:Yes)ため、ステップS43へ移行する。
一方、クエリにフラグ「1」が付加されていない場合には、インデックス情報は送信済みでない(ステップS41:No)ので、記憶部12のインデックスキャッシュからインデックス情報を取得して、クエリの送信元であるユーザノードに送信する(ステップS42)。
次いで、制御部11は、クエリに含まれるコンテンツIDにクエリの受信日時等を対応付けて利用ログ情報として記憶部12の記録ホルダに記録し(ステップS43)、処理を終了する。
一方、自身がルートノードでないと判定された場合(ステップS40:No)、クエリに含まれるコンテンツIDに対応するインデックス情報が、当該クエリの送信元であるユーザノードに送信済みであるか否かを判定する(ステップS44)。判定方法はステップS41と同様である。
判定の結果、インデックス情報が送信済みである場合(ステップS44:Yes)には、記憶部12のルーティングテーブルを参照してクエリを他のノードNnに転送し(ステップS45)、処理を終了する。
一方、インデックス情報が送信済みで無い場合(ステップS44:No)には、記憶部12のインデックスキャッシュに、該当するインデックス情報が登録(キャッシュ)されているか否かを判定し(ステップS46)、登録されていない場合(ステップS46:No)には、記憶部12のルーティングテーブルを参照してクエリを他のノードNnに転送し(ステップS49)、処理を終了する。
そして、記憶部12のインデックスキャッシュに、該当するインデックス情報が登録されている場合には(ステップS46:Yes)、インデックスキャッシュから当該インデックス情報を取得して、クエリの送信元であるユーザノードに送信する(ステップS47)。
次いで、クエリにフラグ「1」を付加し(ステップS48)、記憶部12のルーティングテーブルを参照してクエリを他のノードNnに転送し(ステップS49)、処理を終了する。
<4−1−3.「パブリッシュ」を「利用関連情報」とする場合の、ステップS19のパブリッシュ受信処理>
図10は、上記ステップS19の「パブリッシュ受信処理」を示すフローチャートである。
かかる処理は、「パブリッシュ」を「利用関連情報」とする場合に、ステップS19にて行なわれる処理である。
先ず、制御部11は、パブリッシュに含まれるインデックス情報を、記憶部12のインデックスキャッシュに登録する(ステップS50)。
続いて、受信したパブリッシュの転送先があるか否かに基づいて、自身がパブリッシュに含まれるコンテンツIDのルートノードか否かを判定する(ステップS51)。パブリッシュの転送先がない場合にはルートノードであると判定され(ステップS51:Yes)、次いで、受信したパブリッシュが定期送信されたものであるか否かを判定する(ステップS52)。具体的には、制御部11は、パブリッシュに定期送信である旨を知らせるためのフラグ「1」が付加されているか否かに基づいて判定し、フラグ「1」が付加されている場合には、定期送信である(ステップS52:Yes)ため、処理を終了する。
一方、パブリッシュにフラグ「1」が付加されていない場合には、定期送信でない(ステップS52:No)ため、パブリッシュに含まれるコンテンツIDにパブリッシュの受信日時等を対応付けて利用ログ情報として記憶部12の記録ホルダに記録して(ステップS53)、処理を終了する。
そして、ステップS51の判定において、自身がルートノードでないと判定された場合(ステップS51:No)には、記憶部12のルーティングテーブルを参照して、パブリッシュを他のノードNnに転送し(ステップS54)、処理を終了する。
<4−1−4.ステップS21の利用ログ情報要求メッセージ受信処理>
図11は、上記ステップS21の「利用ログ情報要求メッセージ受信処理」を示すフローチャートである。
先ず、制御部11は、受信した利用ログ情報要求メッセージの転送先があるか否かに基づいて、自身が利用ログ情報要求メッセージに含まれるコンテンツIDのルートノードか否かを判定する(ステップS61)。利用ログ情報要求メッセージの転送先がない場合にはルートノードであると判定され(ステップS61:Yes)、記憶部12の記録ホルダに記録した利用ログ情報のうち、受信した利用ログ情報要求メッセージに含まれるコンテンツIDの利用ログ情報を抽出して、管理サーバCSへ送信し(ステップS62)、処理を終了する。
一方、自身がルートノードでないと判定された場合(ステップS61:No)には、記憶部12のルーティングテーブルを参照して、利用ログ情報要求メッセージを他のノードNnに転送し(ステップS62)、処理を終了する。
<4−2.実施例2>
続いて、「クエリ」又は「パブリッシュ」を「利用関連情報」とし、定期的に管理サーバCSにコンテンツ利用報告が行なわれる場合の各ノードNnにおける処理を説明する。
図12は、コンテンツ分散保存システムSに参加している任意のノードNnにおける制御部11のメイン処理を示すフローチャートであり、コンテンツ分散保存システムSへの参加後に本発明のノード処理プログラムが読み出され処理が開始する。
かかる実施例2におけるノードNnの処理は、図7を用いて説明した実施例1の処理中の、利用ログ情報要求メッセージの受信にかかるステップS20及びステップS21の処理に相当する処理がなく、新たに、コンテンツの利用報告時刻か否かを判定して利用ログ情報を管理サーバCSへ送信する処理(ステップS122及びS123)が追加されている。その他の処理は実施例1の処理と同様であるため説明を省略する。
具体的には、図12中、ステップS110乃至ステップS119の処理は、図7を用いて説明したステップS10乃至ステップS19の処理と同様であり、ステップS120及びステップS121の処理は、ステップS22及びステップS23の処理と同様であり、ステップS124乃至ステップS126の処理は、ステップS24乃至ステップS26の処理と同様である。
本実施例では、ステップS121にて、その他のメッセージを受信していないと判定されると(ステップS121:No)、ステップS122の処理に移行し、コンテンツの利用報告時刻か否かを判定する(ステップS122)。所定時間毎にコンテンツの利用報告を行なう場合には、前回送信時刻から所定時間経過したか否かに基づいて判定すればよく、予め定められた日時にコンテンツの利用報告を行なう場合には、予め定められた日時であるか否かに基づいて判定すればよい。
判定の結果、コンテンツの利用報告時刻である場合には(ステップS122:Yes)、記憶部12の記録ホルダから利用ログ情報を取得して管理サーバCSに送信し(ステップS123)、ステップS126へ移行する。
一方、コンテンツの利用報告時刻でない場合(ステップS122:No)には、ステップS124へ移行する。
<4−3.実施例3>
続いて、実施例3の「視聴通知メッセージ」を「利用関連情報」とし、管理サーバCSからの要求に応じてコンテンツ利用報告が行なわれる場合の各ノードNnにおける処理を説明する。
図13は、コンテンツ分散保存システムSに参加している任意のノードNnにおける制御部11のメイン処理を示すフローチャートであり、コンテンツ分散保存システムSへの参加後に本発明のノード処理プログラムが読み出され処理が開始する。なお、上述した実施例1と同様の処理については説明を省略する。
先ず、制御部11は、入力部21を通じてユーザから視聴を所望するコンテンツを指定して再生指示がされたか否かを判定し(ステップS210)、再生指示がされた場合には(ステップS210:Yes)、指定されたコンテンツのコンテンツIDを含むクエリを生成し、当該コンテンツのルートノードに向けて生成したクエリを送信する(ステップS211)。
次いで、ルートノードからコンテンツ保持ノードのインデックス情報を受信する(ステップS212)と、コンテンツ保持ノードにコンテンツ送信要求メッセージを送信し(ステップS213)、コンテンツ保持ノードからコンテンツのレプリカを取得(ダウンロード)して記憶部12に記憶する(ステップS214)。そして、取得したコンテンツのレプリカについて再生処理を行なう。
続いて、取得したコンテンツ(レプリカ)のコンテンツIDを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信(ステップS215)する。
そして、取得したコンテンツ(レプリカ)のコンテンツIDを含む視聴通知メッセージを生成し、当該コンテンツのルートノードに向けて生成した視聴通知メッセージを送信(ステップS216)し、ステップS229へ移行する。
一方、再生指示がされていない場合には(ステップS210:No)、他のノードNnからクエリを受信したか否かを判定し(ステップS217)、クエリを受信した場合(ステップS217:Yes)には、クエリに応じた処理を行なう(ステップS218)。具体的には、記憶部12を参照して受信したクエリに含まれるコンテンツIDのインデックス情報が登録されていれば、当該インデックス情報をクエリの送信元のノードNnに返信し、登録されていなければ、ルーティングテーブルを参照してクエリを他のノードNnに転送する。
クエリを受信していない場合には(ステップS217:No)、他のノードNnからパブリッシュを受信したか否かを判定し(ステップS219)、パブリッシュを受信した場合(ステップS219:Yes)には、パブリッシュに応じた処理を行なう(ステップS220)。具体的には、受信したパブリッシュに含まれるコンテンツIDのインデックス情報を自己のインデックスクスキャッシュに登録する。
パブリッシュを受信していない場合には(ステップS219:No)、利用ログ情報要求メッセージを受信したか否かを判定し(ステップS221)、利用ログ情報要求メッセージを受信した場合(ステップS221:Yes)には、「利用ログ情報要求メッセージ受信処理」を行なう(ステップS222)。
利用ログ情報要求メッセージを受信していない場合には(ステップS221:No)、視聴通知メッセージを受信したか否かを判定し(ステップS223)、視聴通知メッセージを受信した場合(ステップS223:Yes)には、「視聴通知メッセージ受信処理」を行なう(ステップS224)。なお、「視聴通知メッセージ受信処理」は、後に図を用いて詳述する。
そして、視聴通知メッセージを受信していない場合には(ステップS223:No)、その他のメッセージを受信したか否かを判定し(ステップS225)、その他のメッセージを受信した場合(ステップS225:Yes)には、その他のメッセージに応じた処理を行なう(ステップS226)。
その他のメッセージを受信していない場合には(ステップS225:No)、記憶部12に記憶しているレプリカについて、パブリッシュの定期送信時刻か否かを判定する(ステップS227)。
判定の結果、パブリッシュの定期送信時刻である場合には(ステップS227:Yes)、当該レプリカのコンテンツIDを含むパブリッシュを生成し、当該コンテンツのルートノードに向けて生成したパブリッシュを送信する(ステップS228)。このとき、パブリッシュにフラグ「1」を付加して送信する。
そして、パブリッシュの定期送信時刻でない場合(ステップS227:No)、及び、ステップS216、ステップS218、S220、S222、S224、S226及びS228の処理の後、ステップS229に移行して、電源がオフとなるまでステップS210からステップS229の処理を繰り返し行なう。
そして、電源がオフとなった場合に(ステップS229:Yes)、処理を終了する。
<4−3−1.ステップS224の視聴通知メッセージ受信処理>
図14は、上記ステップS224の「視聴通知メッセージ受信処理」を示すフローチャートである。
先ず、制御部11は、受信した視聴通知メッセージの転送先があるか否かに基づいて、自身が視聴通知メッセージに含まれるコンテンツIDのルートノードか否かを判定する(ステップS250)。視聴通知メッセージの転送先がない場合にはルートノードであると判定され(ステップS250:Yes)、視聴通知メッセージに含まれるコンテンツIDにパブリッシュの受信日時等を対応付けて利用ログ情報として記憶部12の記録ホルダに記録して(ステップS251)、処理を終了する。
そして、ステップS250の判定において、自身がルートノードでないと判定された場合(ステップS250:No)には、記憶部12のルーティングテーブルを参照して、視聴通知メッセージを他のノードNnに転送し(ステップS252)、処理を終了する。
<4−4.実施例4>
続いて、「視聴通知メッセージ」を「利用関連情報」とし、定期的に管理サーバCSにコンテンツ利用報告が行なわれる場合の各ノードNnにおける処理を説明する。
図15は、コンテンツ分散保存システムSに参加している任意のノードNnにおける制御部11のメイン処理を示すフローチャートであり、コンテンツ分散保存システムSへの参加後に本発明のノード処理プログラムが読み出され処理が開始する。
かかる実施例4におけるノードNnの処理は、図13を用いて説明した実施例3の処理中の、利用ログ情報要求メッセージの受信にかかるステップS221及びステップS222の処理に相当する処理がなく、新たに、コンテンツの利用報告時刻か否かを判定して利用ログ情報を管理サーバCSへ送信する処理(ステップS325及びS326)が追加されている。その他の処理は実施例3の処理と同様であるため説明を省略する。
具体的には、図15中、ステップS310乃至ステップS320の処理は、図13を用いて説明したステップS210乃至ステップS220の処理と同様であり、ステップS321乃至ステップS324の処理は、ステップS223乃至ステップS226の処理と同様であり、ステップS327乃至ステップS329の処理は、ステップS227乃至ステップS229の処理と同様である。
本実施例では、ステップS323にて、その他のメッセージを受信していないと判定されると(ステップS323:No)、ステップS325の処理に移行し、コンテンツの利用報告時刻か否かを判定する(ステップS325)。判定方法は実施例2のステップS122と同様であるため説明を省略する。
判定の結果、コンテンツの利用報告時刻である場合には(ステップS325:Yes)、記憶部12の記録ホルダから利用ログ情報を取得して管理サーバCSに送信して(ステップS326)、ステップS329へ移行し、一方、コンテンツの利用報告時刻でない場合(ステップS325:No)には、ステップS327へ移行する。
以上説明したように、各コンテンツのルートノードが、各ノードNnから、コンテンツの利用に関連する利用関連情報を受信すると、当該コンテンツのコンテンツID等を含む利用ログ情報を記録し、管理サーバCSからの要求に応じて、又は定期的に管理サーバへ送信するよう構成したので、コンテンツの利用状況の収集にかかる負荷を複数のノードNnにて分散させることができる。
また、クエリやパブリッシュを利用関連情報として利用するよう構成すれば、各コンテンツのルートノードは、コンテンツの利用状況を通知する別途のメッセージの送受信などを行なうことなく、コンテンツの利用ログ情報を記録することができる。
また、各ノードNnにてコンテンツの視聴が行なわれた際に、利用関連情報として視聴が行なわれたコンテンツのコンテンツIDを含む視聴通知メッセージをルートノードに送信し、ルートノードは当該視聴通知メッセージを利用関連情報として利用ログ情報を記録するよう構成することもできる。
さらに、ルートノードは、利用ログ情報として、利用関連情報を受信した日時をコンテンツIDと対応付けて記録することにより、ルートノードから利用状況報告を受けた管理サーバCSは、より詳細な利用状況を把握することができる。
なお、上記実施形態におけるコンテンツ分散保存システムSは、DHTを利用したアルゴリズムによって形成されることを前提として説明したが、本発明はこれに限定されるものではない。