(57)【要約】【課題】各ノード装置間における負担の差異を少なくし、不公平を低減させることが可能な通信システム、ノード装置、ノード処理プログラム、及びサーバ機能制御方法を提供する。【解決手段】ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムにおける前記ノード装置であって、前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する算出手段と、前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する判別手段と、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる制御手段と、を備える。【選択図】図６
2008236536.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムにおける前記ノード装置であって、
前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する算出手段と、
前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する判別手段と、
前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる制御手段と、
を備えることを特徴とするノード装置。
【請求項２】
請求項１に記載のノード装置において、
自ノード装置の稼動からの稼動時間を計測する稼動時間計測手段を更に備え、
前記制御手段は、前記サーバ機能を停止させた後、前記計測された稼動時間が予め設定された基準時間を経過した場合には、前記サーバ機能を復帰させることを特徴とするノード装置。
【請求項３】
前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、
前記サーバ機能には、前記ネットワークを介して他のノード装置からコンテンツデータの提供要求を示す提供要求メッセージを受信した場合に、当該提供要求に係るコンテンツデータを当該他のノード装置に対して送信する機能が含まれることを特徴とする請求項１に記載のノード装置。
【請求項４】
前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、
前記サーバ機能には、前記ネットワークを介してサーバ装置からコンテンツデータの投入要求を示す投入要求メッセージを受信した場合に、当該投入要求に係るコンテンツデータを前記他のノード装置から取得して保存する機能が含まれることを特徴とする請求項１に記載のノード装置。
【請求項５】
請求項３又は４に記載のノード装置において、  
他のノード装置からコンテンツデータを取得し保存した場合には、自己のノード情報を管理対象として登録させるための登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する登録メッセージ送出手段と、
自己が保存しているコンテンツデータを削除した場合には、自己のノード情報を管理対象から削除させるための削除メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する削除メッセージ送出手段と、
を更に備え、
前記制御手段は、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させ、且つ、自ノード装置が保存しているコンテンツデータを削除せずに、前記削除メッセージを当該コンテンツデータの管理元となるノード装置宛に送出させることを特徴とするノード装置。
【請求項６】
請求項５に記載のノード装置において、
前記制御手段は、前記サーバ機能を停止させた後当該サーバ機能を復帰させた場合には、前記登録メッセージを、前記削除されずに前記削除メッセージの送出対象になったコンテンツデータの管理元となるノード装置宛に送出させることを特徴とするノード装置。
【請求項７】
請求項４に記載のノード装置において、
前記制御手段は、前記サーバ機能の停止中に、前記投入要求メッセージを受信した場合には、当該投入要求メッセージを他のノード装置に転送する投入要求メッセージ転送手段を更に備えることを特徴とするノード装置。
【請求項８】
前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、
前記ノード装置は、他のノード装置からコンテンツデータを取得し保存した場合には、自己のノード情報を管理対象として登録させるための登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する登録メッセージ送出手段を更に備え、
前記制御手段は、前記サーバ機能の停止中に、ユーザから入力手段を介して指定されたコンテンツデータを前記他のノード装置から取得して保存した場合には、当該サーバ機能の復帰後に、前記登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出させることを特徴とする請求項１に記載のノード装置。
【請求項９】
前記複数のノード装置には複数のコンテンツデータが提供可能に分散保存されており、
前記制御手段は、前記サーバ機能の停止中に、他のノード装置から提供されたコンテンツデータを保存した場合には、当該コンテンツデータを保存させる依頼を示すコンテンツデータ保存依頼メッセージを任意のノード装置に送信する保存依頼メッセージ送信手段を更に備えることを特徴とする請求項１に記載のノード装置。
【請求項１０】
コンピュータを、請求項１乃至９の何れか一項に記載のノード装置として機能させることを特徴とするノード処理プログラム。
【請求項１１】
ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムであって、
前記ノード装置は、
前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する算出手段と、
前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する判別手段と、
前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる制御手段と、
を備えることを特徴とする通信システム。
【請求項１２】
ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムにおける前記ノード装置のサーバ機能制御方法であって、
前記ノード装置が、
前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する工程と、
前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する工程と、
前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる工程と、
を備えることを特徴とするサーバ機能制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型の通信システムの技術分野に関する。
【背景技術】
【０００２】
この種のピアツーピア型の通信システムにおいて、コンテンツデータのレプリカ（複製データ）を複数のノード装置に分散配置（分散保存）させておくコンテンツ分散保存システムが知られており、これにより、対故障性やアクセスの分散性が高められている。このように分散保存されたコンテンツデータのレプリカの所在は、例えば特許文献１に開示されるような分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用して効率良く検索可能になっている。当該ＤＨＴは、各ノード装置に記憶されており、当該ＤＨＴには、各種メッセージの転送先となるべき複数のノード装置を示すノード情報（例えば、ＩＰアドレス及びポート番号を含む）が登録されている。
【０００３】
そして、コンテンツ分散保存システムに参加しているノード装置は、所望のコンテンツデータの取得を望む場合、当該コンテンツデータのレプリカの所在を検索（発見）するためのメッセージ（クエリ）を他のノード装置に送出することにより、当該メッセージは、上記ＤＨＴにしたがって、中継のノード装置により当該コンテンツデータのレプリカの所在の管理元のノード装置に向かって転送され、最終的に当該メッセージが辿り着く上記管理元のノード装置から上記所在を示す情報を取得することになる。これにより、当該メッセージを送出したノード装置は、上記検索に係るコンテンツデータのレプリカを保存しているノード装置に対して、当該コンテンツデータのレプリカを要求し、当該コンテンツデータのレプリカの提供を受けることができる。
【特許文献１】特開２００６−１９７４００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、上記検索に係るコンテンツデータのレプリカを保存しているノード装置が、当該レプリカの要求に応じて、当該レプリカを提供する配信動作（他のノード装置のために稼動するサーバ機能の一つ）は、通常、当該レプリカを提供するノード装置のユーザが当該ノード装置を未使用の時でも行われる。
【０００５】
しかしながら、頻繁に要求されるコンテンツデータのレプリカを保存しているノード装置の場合、ユーザが使用していないにもかかわらず、上記配信動作のための時間が長くなり、消費電力が大きくなり、ひいては、負担する費用（例えば、電気代やメンテナンス代）が増大してしまうことになる。このため、各ノード装置間で、ユーザが負担する費用に差が生じ、不公平になることが想定される。
【０００６】
本発明は、以上の問題等に鑑みてなされたものであり、各ノード装置間における負担の差異を少なくし、不公平を低減させることが可能な通信システム、ノード装置、ノード処理プログラム、及びサーバ機能制御方法を提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムにおける前記ノード装置であって、前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する算出手段と、前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する判別手段と、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる制御手段と、を備えることを特徴とする。
【０００８】
この発明によれば、サーバ機能が稼動した実績を定量的に示す稼動実績値を算出し、算出された稼動実績値が、予め設定された基準値以上になったか否かを判別し、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させるように構成したので、当該基準値により、ノード装置の負担について上限値を持たせることができ（負担を一定枠に抑えることができ）、各ノード装置間における負担の差異を少なくし、不公平を低減させることができる。
【０００９】
請求項２に記載の発明は、請求項１に記載のノード装置において、自ノード装置の稼動からの稼動時間を計測する稼動時間計測手段を更に備え、前記制御手段は、前記サーバ機能を停止させた後、前記計測された稼動時間が予め設定された基準時間を経過した場合には、前記サーバ機能を復帰させることを特徴とする。
【００１０】
この発明によれば、基準時間を経過すればサーバ機能を復帰させることができるので、各ノード装置間における負担の差異を少なくしつつ、通信システムの安定的な運用を図ることができる。
【００１１】
請求項３に記載の発明は、請求項１に記載のノード装置において、前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、前記サーバ機能には、前記ネットワークを介して他のノード装置からコンテンツデータの提供要求を示す提供要求メッセージを受信した場合に、当該提供要求に係るコンテンツデータを当該他のノード装置に対して送信する機能が含まれることを特徴とする。
【００１２】
請求項４に記載の発明は、請求項１に記載のノード装置において、前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、前記サーバ機能には、前記ネットワークを介してサーバ装置からコンテンツデータの投入要求を示す投入要求メッセージを受信した場合に、当該投入要求に係るコンテンツデータを前記他のノード装置から取得して保存する機能が含まれることを特徴とする。
【００１３】
請求項５に記載の発明は、請求項３又は４に記載のノード装置において、他のノード装置からコンテンツデータを取得し保存した場合には、自己のノード情報を管理対象として登録させるための登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する登録メッセージ送出手段と、自己が保存しているコンテンツデータを削除した場合には、自己のノード情報を管理対象から削除させるための削除メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する削除メッセージ送出手段と、を更に備え、前記制御手段は、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させ、且つ、自ノード装置が保存しているコンテンツデータを削除せずに、前記削除メッセージを当該コンテンツデータの管理元となるノード装置宛に送出させることを特徴とする。
【００１４】
この発明によれば、当該削除メッセージ送信したノード装置への無駄なアクセス（例えば、コンテンツデータの提供要求のためのアクセス）を無くすことができる。
【００１５】
請求項６に記載の発明は、請求項５に記載のノード装置において、前記制御手段は、前記サーバ機能を停止させた後当該サーバ機能を復帰させた場合には、前記登録メッセージを、前記削除されずに前記削除メッセージの送出対象になったコンテンツデータの管理元となるノード装置宛に送出させることを特徴とする。
【００１６】
この発明によれば、当該登録メッセージを送出したノード装置への無駄なアクセス（例えば、コンテンツデータの提供要求のためのアクセス）を無くすことができる。
【００１７】
請求項７に記載の発明は、請求項４に記載のノード装置において、前記制御手段は、前記サーバ機能の停止中に、前記投入要求メッセージを受信した場合には、当該投入要求メッセージを他のノード装置に転送する投入要求メッセージ転送手段を更に備えることを特徴とする。
【００１８】
この発明によれば、サーバ機能停止中のノード装置の代わりにコンテンツデータを保存するノード装置を確保することができる。
【００１９】
請求項８に記載の発明は、請求項１に記載のノード装置において、前記複数のノード装置には複数のコンテンツデータが分散保存され、コンテンツデータを保存しているノード装置のノード情報は、他のノード装置からの問い合わせに応じて提供可能なように、当該コンテンツデータの管理元となるノード装置により管理されており、前記ノード装置は、他のノード装置からコンテンツデータを取得し保存した場合には、自己のノード情報を管理対象として登録させるための登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出する登録メッセージ送出手段を更に備え、前記制御手段は、前記サーバ機能の停止中に、ユーザから入力手段を介して指定されたコンテンツデータを前記他のノード装置から取得して保存した場合には、当該サーバ機能の復帰後に、前記登録メッセージを当該コンテンツデータの管理元となるノード装置宛に送出させることを特徴とする。
【００２０】
この発明によれば、当該登録メッセージを送出したノード装置への無駄なアクセス（例えば、コンテンツデータの提供要求のためのアクセス）を無くすことができる。
【００２１】
請求項９に記載の発明は、請求項１に記載のノード装置において、前記複数のノード装置には複数のコンテンツデータが提供可能に分散保存されており、前記制御手段は、前記サーバ機能の停止中に、他のノード装置から提供されたコンテンツデータを保存した場合には、当該コンテンツデータを保存させる依頼を示すコンテンツデータ保存依頼メッセージを任意のノード装置に送信する保存依頼メッセージ送信手段を更に備えることを特徴とする。
【００２２】
この発明によれば、サーバ機能停止中のノード装置の代わりにコンテンツデータを提供可能に保存するノード装置を確保することができる。
【００２３】
請求項１０に記載のノード処理プログラムの発明は、コンピュータを、請求項１乃至８の何れか一項に記載のノード装置として機能させることを特徴とする。
【００２４】
請求項１１に記載の発明は、ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムであって、前記ノード装置は、前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する算出手段と、前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する判別手段と、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる制御手段と、を備えることを特徴とする。
【００２５】
請求項１２に記載の発明は、ネットワークを介して互いに通信可能であり、他のノード装置のために稼動するサーバ機能を有する複数のノード装置を備えた通信システムにおける前記ノード装置のサーバ機能制御方法であって、前記ノード装置が、前記サーバ機能が稼動した実績を定量的に示す稼動実績値を算出する工程と、前記算出された稼動実績値が、予め設定された基準値以上になったか否かを判別する工程と、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させる工程と、を備えることを特徴とする。
【発明の効果】
【００２６】
本発明によれば、サーバ機能が稼動した実績を定量的に示す稼動実績値を算出し、算出された稼動実績値が、予め設定された基準値以上になったか否かを判別し、前記稼動実績値が前記基準値以上になった場合には、前記サーバ機能を停止させるように構成したので、当該基準値により、ノード装置の負担について上限値を持たせることができ（負担を一定枠に抑えることができ）、各ノード装置間における負担の差異を少なくし、不公平を低減させることができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ分散保存システムに本発明を適用した場合の実施形態である。
【００２８】
［１．コンテンツ分散保存システムの構成等］
始めに、図１等を参照して、本実施形態に係るコンテンツ分散保存システム（通信システムの一例）の概要構成等について説明する。
【００２９】
図１は、本実施形態に係るコンテンツ分散保存システムにおける各ノード装置の接続態様の一例を示す図である。
【００３０】
図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４ａ,４ｂ、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５ａ,５ｂ、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界の通信ネットワークであり、通信手段の一例）８が構築されている。なお、図１の例におけるネットワーク（通信ネットワーク）８には、データ（パケット）を転送するためのルータが適宜挿入されている。
【００３１】
このようなネットワーク８には、複数のノード装置（以下、「ノード」という）Ｎｎ（ｎ＝１，２，３・・・の何れか）が接続されている。また、各ノードＮｎには、固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。このような製造番号およびＩＰアドレスは、複数のノード間で重複しないものである。
【００３２】
そして、本実施形態に係るコンテンツ分散保存システムＳは、これらのノードＮｎのうち、図１の上部枠１００内に示すように、何れか複数のノードＮｎの参加により形成されるピアツーピア方式のネットワークシステムとなっている。なお、図１の上部枠１００内に示すネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するオーバーレイネットワーク９（論理的なネットワーク）である。かかるオーバーレイネットワーク９は、特定のアルゴリズム、例えば、ＤＨＴ（Distributed Hash Table）を利用したアルゴリズムにより実現される。
【００３３】
そして、コンテンツ分散保存システムＳ（言い換えれば、オーバーレイネットワーク９）に参加している各ノードＮｎには、所定桁数からなる固有の識別情報であるノードＩＤが割り当てられており、当該ノードＩＤは、例えば、各ノードＮｎに個別に割り当てられたＩＰアドレス或いは製造番号を共通のハッシュ関数（例えば、ＳＨＡ−１等）によりハッシュ化した値（例えば、ｂｉｔ長が１６０ｂｉｔ）であり、図３に示すような一つのＩＤ空間に偏りなく分散して配置されることになる。
【００３４】
なお、コンテンツ分散保存システムＳへの参加は、参加していないノードＮｎ（例えば、ノードＮ８）が、参加している任意のノードＮｎ（例えば、当該システムＳに常時参加しているコンタクトノード）に対して参加要求を示す参加メッセージを送信することによって行われる。
【００３５】
上記のように共通のハッシュ関数により求められた（ハッシュ化された）ノードＩＤは、当該ＩＰアドレス或いは製造番号が異なれば、同じ値になる確率が極めて低いものである。また、このノードＩＤは、ノードの最大運用台数を収容できるだけのｂｉｔ数を持たせる必要がある。例えば、１２８ｂｉｔの番号とすれば、2＾128＝340×10＾36台のノードを運用できる。なお、ハッシュ関数については公知であるので詳しい説明を省略する。
【００３６】
また、各ノードＮｎは、夫々、ＤＨＴを用いたルーティングテーブルを保持している。このルーティングテーブルは、コンテンツ分散保存システムＳ上における各種メッセージの転送先を規定しており、具体的には、ＩＤ空間内で適度に離れたノードＮｎのノードＩＤ、ＩＰアドレス及びポート番号を含むノード情報が複数登録されている。
【００３７】
コンテンツ分散保存システムＳに参加している１台のノードＮｎは、該システムＳに参加している全てのノードＮｎのうち、必要最低限のノードＮｎのノード情報をルーティングテーブルに登録しておき、ノード情報を知らない（記憶していない）ノードＮｎについては、各ノードＮｎ間で互いに各種メッセージを転送し合って届けてもらうようになっている。
【００３８】
ここで、図２及び図３を参照して、ＤＨＴを用いたルーティングテーブルについて詳しく説明する。
【００３９】
図２は、ノードＮ２が保持するＤＨＴを用いたルーティングテーブルの一例を示す図であり、図３は、ＤＨＴのＩＤ空間の一例を示す概念図である。
【００４０】
なお、図２及び図３の例においては、説明の便宜上、ノードＩＤのｂｉｔ長を２ｂｉｔ×３桁＝６ｂｉｔとし、各桁を４進数（０〜３の整数）で表している（実際には、もっと長いｂｉｔ長を用い、各桁も例えば４ｂｉｔに区切って０〜ｆの１６進数で表現する）。
【００４１】
図２の例において、ＤＨＴを用いたルーティングテーブルは、レベル１〜レベル３のテーブルからなり（複数のレベルに区分されており）、各レベルのテーブルエントリーには、エリア毎に、ノード情報として、ノードＩＤとこれに対応するノードＮｎのＩＰアドレス及びポート番号が対応付けられて登録されている。各レベルのテーブルにおける各エリアは、ＤＨＴのノードＩＤ空間を分割することにより得られるエリアである。例えば、図３に示すように、レベル１では、ＤＨＴのＩＤ空間全体が４分割され、“０００”〜“０３３”のノードＩＤが存在するエリアを０ＸＸのエリア、“１００”〜“１３３” のノードＩＤが存在するエリアを１ＸＸのエリア、“２００”〜“２３３” のノードＩＤが存在するエリアを２ＸＸのエリア、“３００”〜“３３３” のノードＩＤが存在するエリアを３ＸＸのエリアとする。また、レベル２では、レベル１のエリア（つまり、０ＸＸ〜３ＸＸのエリア）が更に４分割、例えば１ＸＸのエリアが４分割され、“１００”〜“１０３” のノードＩＤが存在するエリアを１０Ｘのエリア、“１１０”〜“１１３” のノードＩＤが存在するエリアを１１Ｘのエリア、“１２０”〜“１２３” のノードＩＤが存在するエリアを１２Ｘのエリア、“１３０”〜“１３３” のノードＩＤが存在するエリアを１３Ｘのエリアとする。
【００４２】
そして、例えば、ノードＮ２のノードＩＤが“１２２”とすると、図２に示すように、かかるノードＮ２のレベル１における１ＸＸのエリア（自己（つまり、自ノード）が存在するエリア）のテーブルには、自己のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録され、自己が存在しないエリア（つまり、０ＸＸのエリア、２ＸＸのエリア、及び３ＸＸのエリア）には、夫々、他の任意のノードＮｎのノードＩＤ及びＩＰアドレス等が登録されている。
【００４３】
また、かかるノードＮ２のレベル２における１２Ｘのエリア（自己が存在するエリア）のテーブルには、図２に示すように、自己のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録され、自己が存在しないエリア（つまり、１０Ｘのエリア、１１Ｘのエリア、及び１３Ｘのエリア）等には、夫々、他の任意のノードＮｎのノードＩＤ及びＩＰアドレス等が登録されている。
【００４４】
更に、かかるノードＮ２のレベル３には、図２に示すように、ノードＩＤが“１２０”〜“１２２”のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録されている。
【００４５】
なお、図２及び図３の例では、ノードＩＤのｂｉｔ長を３桁×２ｂｉｔとしたので、レベル１〜３の３レベル分のテーブルで網羅できるが、ノードＩＤのｂｉｔ長が増せば、その分のテーブルが必要となる（例えば、ノードＩＤのｂｉｔ長を１６桁×４ｂｉｔとした場合、１６レベル分のテーブルが必要となる）。
【００４６】
このように、本実施形態におけるＤＨＴを用いたルーティングテーブルでは、レベルが上がるほど、エリアが狭まっていくようになっている。
【００４７】
また、このようなＤＨＴは、例えば、未参加のノードがコンテンツ分散保存システムＳに参加する際に与えられることになる。
【００４８】
ところで、コンテンツ分散保存システムＳにおいては、内容の異なる様々なコンテンツ（例えば、映画や音楽等）データの夫々の複製データ（以下、「レプリカ」という）が複数のノードＮｎに分散して保存（格納）されている。
【００４９】
例えば、ノードＮ１及びノードＮ５には、タイトルがＸＸＸの映画のコンテンツデータのレプリカが保存されており、一方、ノードＮ３には、タイトルがＹＹＹの映画のコンテンツデータのレプリカが保存されるというように、複数のノードＮｎ（以下、「コンテンツ保持ノード」という）に分散されて保存される。
【００５０】
また、これらのコンテンツデータのレプリカには、夫々、コンテンツ名（タイトル）及びコンテンツＩＤ（コンテンツ毎に固有の識別情報）等の情報が付加されている。このコンテンツＩＤは、例えば、コンテンツ名＋任意の数値（或いは、当該コンテンツデータの先頭数バイトでも良い）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて生成される（ノードＩＤと同一のＩＤ空間に配置）。或いは、システム管理者が、コンテンツ毎に一意のＩＤ値（ノードＩＤと同一ビット長）を付与しても良い。この場合は、コンテンツ名とそのコンテンツＩＤの対応が書かれたコンテンツカタログ情報が、全ノードＮｎに配布される。
【００５１】
また、このように分散保存されているコンテンツデータのレプリカの所在、つまり、当該コンテンツデータのレプリカを保存したノードＮｎのノード情報に係るＩＰアドレス等と当該コンテンツデータに対応するコンテンツＩＤ等の組が含まれるインデックス情報が、当該コンテンツデータのレプリカの所在の管理元であるノードＮｎ（以下、「ルートノード」、又は「コンテンツ（コンテンツＩＤ）のルートノード」という）等により記憶（インデックスキャッシュに記憶）、管理されるようになっている。つまり、コンテンツデータのレプリカを保存しているノードＮｎのノード情報は、他のノードＮｎからの問い合わせに応じて提供可能なようにルートノードにより管理されている。
【００５２】
例えば、タイトルがＸＸＸの映画のコンテンツデータのレプリカについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ４により管理され、タイトルがＹＹＹの映画のコンテンツデータのレプリカについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ６により管理される（つまり、レプリカの所在が夫々のコンテンツデータ毎に管理される）。
【００５３】
すなわち、コンテンツ毎にルートノードが分けられるので負荷分散が図らており、しかも、同一（内容が同一）のコンテンツデータ（コンテンツＩＤが同一）のレプリカが、夫々、複数のコンテンツ保持ノードに保存されている場合であっても、かかるコンテンツデータのインデックス情報は、一つのルートノードで管理することができる。このため、各ルートノードは、コンテンツ分散保存システムＳにおいて自己がその所在を管理するコンテンツデータのレプリカの数（言い換えれば、当該レプリカを保存しているコンテンツ保持ノードの数）を認識している。
【００５４】
また、このようなルートノードは、例えば、コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノードＮｎであるように定められる。
【００５５】
そして、あるノードＮｎのユーザが、所望するコンテンツデータを取得したい場合、当該コンテンツデータの取得を望むノードＮｎ（以下、「ユーザノード」という）は、当該ユーザにより選択（例えば、全てのノードＮｎに配信されているコンテンツカタログ情報（コンテンツ名とコンテンツＩＤ等が記述されており、例えばコンテンツカタログ管理サーバ（図示せず）にて管理される）から選択）されたコンテンツデータ（例えば、コンテンツ名が選択される）のコンテンツＩＤ及び自己のＩＰアドレス等を含むコンテンツ所在問合せ（検索）メッセージ（クエリ）を生成し、これを自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送出する。つまり、ユーザノードは、コンテンツ所在問合せ（検索）メッセージを、ルートノードに向けて（ルートノード宛に）送出する。これにより、コンテンツ所在問合せ（検索）メッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによって最終的にルートノードに到着することになる。
【００５６】
ここで、ユーザノードは、当該ユーザによりコンテンツカタログ情報からコンテンツ名等が選択された場合だけでなく、例えばシステム管理者等のコンテンツ管理サーバからコンテンツ投入要求（保存要求）メッセージ（特定の新規コンテンツデータのコンテンツ名及びコンテンツＩＤ等を含み、コンテンツデータの投入要求を示す投入要求メッセージ）を受信した場合にも、コンテンツ所在問合せ（検索）メッセージ（クエリ）をルートノードに向けて（ルートノード宛に）送出する。このコンテンツ投入要求（保存要求）メッセージ（コンテンツデータの投入要求を示す投入要求メッセージであり、事前プッシュメッセージともいう）は、例えば新規コンテンツデータ（コンテンツカタログ情報により公開される前のコンテンツデータ）のレプリカを、コンテンツ分散保存システムＳにおいて所定数確保（保存）させるために、任意の複数のノードＮｎに配信されるものである。そして、所定数以上のレプリカがコンテンツ分散保存システムＳにおいて保存されると、当該新規コンテンツデータのコンテンツ名とコンテンツＩＤ等が記述されたコンテンツカタログ情報が各ノードＮｎに配信（これにより公開）されることになる。或いは、新規に投入するべき新規コンテンツデータの属性情報が記述されたコンテンツカタログ情報を全ノードＮｎに予め配布しておくが、当該コンテンツカタログ情報には、新規コンテンツデータの公開日が設定されており、公開日までは各ノードＮｎのユーザに公開されない（利用できない）ようにしておき、公開日が過ぎると、上記投入要求により事前に新規コンテンツデータを保存した各ノードＮｎ以外のノードＮｎにおいても、当該新規コンテンツデータをリクエストできるようになる。
【００５７】
このように、コンテンツ投入要求（保存要求）メッセージに応じて上記レプリカを取得して保存することは、他のノードＮｎに提供するためのものであるということができる。
【００５８】
また、上記コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤは、ユーザノードによって、コンテンツ名が上記共通のハッシュ関数によりハッシュ化されて生成されるようにしても良い。
【００５９】
図４は、ユーザノードから送出されたコンテンツ所在問合せ（検索）メッセージの流れの一例を、ＤＨＴのＩＤ空間にて示した概念図である。
【００６０】
図４の例において、例えば、ユーザノードであるノードＮ２は、自己のＤＨＴのレベル１のテーブルを参照して、コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードＮ３のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記コンテンツ所在問合せ（検索）メッセージ（クエリ）を送信する。
【００６１】
これに対して、ノードＮ３は、当該コンテンツ所在問合せ（検索）メッセージを受信し、自己のＤＨＴのレベル２のテーブルを参照して、当該コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードＮ４のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記コンテンツ所在問合せ（検索）メッセージを転送する。
【００６２】
これに対して、ノードＮ４は、当該コンテンツ所在問合せ（検索）メッセージを受信し、自己のＤＨＴのレベル３のテーブルを参照して、当該コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤが自分である、つまり、自分がそのコンテンツＩＤのルートノードであることを認識すると、当該コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤに対応するインデックス情報をインデックスキャッシュから取得して、当該インデックス情報を、該コンテンツ所在問合せメッセージの送信元であるユーザノードに対して返信する。これにより、ユーザノードは、所望のコンテンツデータのレプリカを保存している上記コンテンツ保持ノードである例えばノードＮ１に対して、コンテンツ送信要求メッセージ（コンテンツデータの提供要求を示す提供要求メッセージ）を送信し、そこから当該コンテンツデータのレプリカの提供を受けることが可能になる。
【００６３】
或いは、ルートノードであるノードＮ４は、当該インデックス情報に含まれるＩＰアドレス等に示されたコンテンツ保持ノードに対してコンテンツ送信要求メッセージ（ユーザノードのＩＰアドレス等を含み、当該ユーザノードに対してコンテンツデータの提供要求を示す提供要求メッセージ）を送信する。これにより、ユーザノードは、上記コンテンツ保持ノードである例えばノードＮ１から当該コンテンツデータのレプリカの提供を受けることが可能になる。
【００６４】
なお、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該ルートノードと同じインデックス情報をキャッシュしている中継ノード（例えば、ノードＮ３のキャッシュノード）から当該インデックス情報を取得（受信）することもできる。
【００６５】
このようにしてコンテンツデータのレプリカを取得、保存したユーザノードは、当該レプリカを保存したことをそのルートノードに知らせるために（言い換えれば、自己のノード情報を管理対象として登録させ、該システムＳに参加している他のノードＮｎに対して公開するために）、そのコンテンツデータのコンテンツＩＤ及び自己のＩＰアドレス等が含まれるパブリッシュ（登録通知）メッセージ（自己のノード情報を管理対象として登録させるための登録メッセージ）を生成し、該パブリッシュメッセージを、そのルートノードに向けて（ルートノード宛に）送出する。これにより、パブリッシュメッセージは、コンテンツ所在問合せ（検索）メッセージと同じように、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになり、該ルートノードは、受信したパブリッシュメッセージに含まれるＩＰアドレス等及びコンテンツＩＤの組を含むインデックス情報を登録（インデックスキャッシュ領域に記憶）することになる。こうして、上記ユーザノードは、新たに、上記コンテンツデータのレプリカを保持するコンテンツ保持ノードとなる。
【００６６】
なお、上記パブリッシュメッセージに含まれるＩＰアドレス等及びコンテンツＩＤの組を含むインデックス情報は、ルートノードに至るまでの転送経路における中継ノードにおいても登録（キャッシュ）される。
【００６７】
また、上記のように保存されたコンテンツデータのレプリカは、ユーザからの削除指示に応じて削除されるようになっており、当該レプリカが削除されると、削除されたレプリカに対応するコンテンツＩＤ及び自己（自ノードＮｎ）のＩＰアドレス等が含まれる削除通知メッセージ（自己のノード情報を管理対象から削除させるための削除メッセージ）が、そのルートノードに向けて（ルートノード宛に）送出されることになる。これにより、削除通知メッセージは、パブリッシュメッセージと同じように、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになり、該ルートノードは、自己のインデックス情報中から当該削除通知メッセージに含まれるコンテンツＩＤに対応付けられたＩＰアドレス等のノード情報を削除することになる。
【００６８】
なお、上記削除通知メッセージに含まれるコンテンツＩＤに対応付けられたＩＰアドレス等は、ルートノードに至るまでの転送経路における中継ノードにおいても削除される。
【００６９】
［２．ノードＮｎの構成及び機能等］
次に、図５を参照して、ノードＮｎの構成及び機能について説明する。
【００７０】
図５は、ノードＮｎの概要構成例を示す図である。
【００７１】
各ノードＮｎは、図５に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、各種データ（例えば、コンテンツデータのレプリカ、インデックス情報、ＤＨＴ等）及び各種プログラム等を記憶保存（格納）するためのＨＤ等から構成された記憶部１２と、受信されたコンテンツデータのレプリカ等を一時蓄積するバッファメモリ１３と、コンテンツデータのレプリカに含まれるエンコードされたビデオデータ（映像情報）およびオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ （Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノードＮｎや各種サーバ等との間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力手段としての入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、通信部２０、及び入力部２１はバス２２を介して相互に接続されている。なお、ノードＮｎとしては、パーソナルコンピュータ、ＳＴＢ（Set Top Box）、或いは、ＴＶ受信機等を適用可能である。また、記憶部１２には、コンテンツ分散保存システムＳに参加する際のアクセス先となるコンタクトノードのＩＰアドレス及びポート番号等が記憶されている。
【００７２】
このような構成において、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、全体を統括制御し、コンテンツ分散保存システムＳへの参加により上述したユーザノード、中継ノード、ルートノード、キャッシュノード、及びコンテンツ保持ノードの少なくとも何れか一つのノードとしての処理を行うようになっている。更に、当該制御部１１は、本発明における算出手段、判別手段、制御手段、稼動時間計測手段、登録メッセージ送出手段、削除メッセージ送出手段、及び投入要求メッセージ転送手段等として機能し、後述する処理を行うようになっている。
【００７３】
具体的には、制御部１１は、自ノードＮｎにおけるサーバ機能が稼動した実績を定量的に示すサーバ稼動実績値を算出し、当該算出された稼動実績値が、予め設定された基準値としてのサーバ稼動制限値（後述するパラメータ毎に適宜設定される値）以上になったか否かを判別し、当該サーバ稼動実績値が上記サーバ稼動制限値以上になった場合には、サーバ機能を停止させるようになっている。
【００７４】
ここで、サーバ機能の例としては、以下の（ｉ）と（ｉｉ）の少なくとも何れか一方の機能が挙げられる。
（ｉ）他のノードＮｎからのコンテンツ送信要求メッセージを受信した場合に、当該送信要求に係るコンテンツデータのレプリカを当該他のノードＮｎに対して送信する機能
（ｉｉ）コンテンツ管理サーバからのコンテンツ投入要求メッセージを受信した場合に、上述したようにコンテンツ所在問合せ（検索）メッセージをルートノードに向けて送出してインデックス情報を取得し、これに基づき、上記投入要求に係るコンテンツデータのレプリカを他のノードＮｎから取得して保存する機能
また、サーバ稼動実績値のパラメータ例としては、例えばサーバ機能が稼動している時間（積算値）、サーバ機能の稼動により消費した消費電力（積算値）、サーバ機能の稼動によりコンテンツデータのレプリカを他のノードＮｎに提供した回数（積算値）、サーバ機能の稼動により他のノードＮｎに提供したコンテンツデータのレプリカのデータ量（積算値）等が挙げられる。これらのサーバ稼動実績値は、上記サーバ機能が稼動した際に計測、積算されることになる。
【００７５】
なお、サーバ機能の稼動によりコンテンツデータのレプリカを他のノードＮｎに提供した回数に加えて（或いは、代えて）、サーバ機能の稼動によりコンテンツデータのレプリカを他のノードＮｎから取得し保存した回数（積算値）をサーバ稼動実績値のパラメータとしても良い。また、サーバ機能の稼動により他のノードＮｎに提供したコンテンツデータのレプリカのデータ量に加えて（或いは、代えて）、サーバ機能の稼動により他のノードＮｎから取得したコンテンツデータのレプリカのデータ量をサーバ稼動実績値のパラメータとしても良い。
【００７６】
また、これらのサーバ稼動実績値のパラメータのうち、どのパラメータを用いるかはノードＮｎへのソフトウェア初回インストール時の段階で設定されるか、或いは各ノードＮｎのユーザにより選択され設定される。また、複数のパラメータの組合せ（例えば、回数と消費電力）を用いても良い。
【００７７】
また、制御部１１は、自ノードＮｎの稼動からの稼動時間を計測（カウント）するようになっており、上記サーバ機能を停止させた後、当該稼動時間が予め設定された基準時間としての管理時間（例えば、２４時間）を経過した場合には、サーバ機能を復帰させ、上記稼動時間をリセット（管理時間毎にリセット）させるようになっている。
【００７８】
なお、上記ノード処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
【００７９】
［３．コンテンツ分散保存システムＳの動作］
次に、図６乃至図９を参照して、コンテンツ分散保存システムＳの動作について説明する。
【００８０】
図６は、ノードＮｎの制御部１１におけるメイン処理を示すフローチャートである。図７（Ａ）は、図６に示すコンテンツデータ取得処理１の詳細を示すフローチャートであり、図７（Ｂ）は、図８に示すコンテンツデータ取得処理２の詳細を示すフローチャートである。図８は、サーバ機能稼動中のメッセージ受信処理の詳細を示すフローチャートである。図９は、サーバ機能停止中のメッセージ受信処理の詳細を示すフローチャートである。
【００８１】
図６に示す処理は、任意のノードＮｎにおいて例えば電源オン（ＯＮ）になった場合に開始され、初期設定が行われた後、コンテンツ分散保存システムＳへの参加処理が実行される。この参加処理においては、当該ノードＮｎの制御部１１は、記憶部１２からコンタクトノードのＩＰアドレス及びポート番号を取得し、これに基づきコンタクトノードにネットワーク８を介して接続し、参加要求を示す参加メッセージ（自己のノードＩＤ及びノード情報等を含む）を送信する。これにより、当該ノードＮｎには、当該システムＳに参加している他のノードＮｎからＤＨＴを用いたルーティングテーブルが送信されることになり、受信したルーティングテーブルに基づき自己のＤＨＴを用いたルーティングテーブルを生成し、コンテンツ分散保存システムＳに参加が完了することになる。なお、ＤＨＴを用いたルーティングテーブルの生成方法は、本発明の直接の関係がないので、詳しい説明を省略する。また、コンタクトノードのＩＰアドレス等の情報は、例えばノードＮｎの出荷時、或いはソフトウェア初回インストール時の初期状態で記憶部１２に記憶される。
【００８２】
こうしてコンテンツ分散保存システムＳへの参加処理が完了すると、制御部１１は、管理時間Ｔａを初期値（例えば、２４時間）に、稼動時間Ｔｂを“０”に、サーバ稼動制限値Ｌｓを初期値に、サーバ稼動実績値Ｒｓを“０”に、サーバ停止フラグＦｓを“０”に、夫々設定（ＲＡＭの設定領域に記憶）する（ステップＳ１）。
【００８３】
なお、サーバ稼動制限値Ｌｓを初期値は、例えば、サーバ稼動実績値のパラメータが時間である場合「５時間」程度、該パラメータが消費電力である場合「１０００Ｗｈ（ワット時）」程度、該パラメータがレプリカを提供した回数である場合「５回」程度、該パラメータは提供したレプリカのデータ量である場合「５ギガバイト」程度として設定される（あくまでも一例）。
【００８４】
次いで、制御部１１は、タイマにより稼動時間Ｔｂの計測（カウント）を開始する（ステップＳ２）。
【００８５】
次いで、制御部１１は、電源ＳＷ（スイッチ）オンか否かを判別し（ステップＳ３）、電源ＳＷオンである場合には（ステップＳ３：ＹＥＳ）、ステップＳ３ａに進み、電源ＳＷオンでない場合には（ステップＳ３：ＮＯ）、ステップＳ５に進む。
【００８６】
ステップＳ３ａでは、制御部１１は、ユーザから入力部２１を介してコンテンツ検索指示があったか否かを判別する。ユーザからコンテンツ検索指示があった（例えば表示部１２上に表示されたコンテンツカタログ情報から、当該ユーザが所望のコンテンツデータのコンテンツ名等を入力部２１により選択（指定）してコンテンツ検索指示を行った）場合には（ステップＳ３ａ：ＹＥＳ）、ステップＳ４に進み、コンテンツ検索指示がない場合には（ステップＳ３ａ：ＮＯ）、ステップＳ５に進む。なお、ステップＳ４におけるコンテンツデータ取得処理１の詳細は後述する。
【００８７】
ステップＳ５では、制御部１１は、他のノードＮｎから送信されたメッセージを受信したか否かを判別し、当該メッセージを受信した場合には（ステップＳ５：ＹＥＳ）、ステップＳ６に進み、当該メッセージを受信していない場合には（ステップＳ５：ＮＯ）、ステップＳ９に進む。
【００８８】
ステップＳ６では、制御部１１は、サーバ停止フラグＦｓが“０”であるか否か（つまり、サーバ機能が稼動中であるか否か）を判別し、サーバ停止フラグＦｓが“０”である（つまり、サーバ機能が稼動中である）場合には（ステップＳ６：ＹＥＳ）、ステップＳ７のサーバ機能稼働中のメッセージ受信処理を行い（ステップＳ７）、サーバ停止フラグＦｓが“０”でない（“１”である、つまり、サーバ機能が停止中である）場合には（ステップＳ６：ＮＯ）、ステップＳ８のサーバ機能停止中のメッセージ受信処理を行い（ステップＳ８）、ステップＳ９に進む。なお、これらのメッセージ受信処理の詳細は後述する。
【００８９】
ステップＳ９では、制御部１１は、サーバ停止フラグＦｓが“０”であるか否かを判別し、サーバ停止フラグＦｓが“０”である場合には（ステップＳ９：ＹＥＳ）、ステップＳ１０に進み、サーバ停止フラグＦｓが“０”でない場合には（ステップＳ９：ＮＯ）、ステップＳ１３に進む。
【００９０】
ステップＳ１０では、サーバ稼動実績値Ｒｓがサーバ稼動制限値Ｌｓを超えたか（又は、サーバ稼動実績値Ｒｓがサーバ稼動制限値Ｌｓに達したか）否かを判別し、超えた（又は、達した）場合には（ステップＳ１０：ＹＥＳ）、ステップＳ１１に進み、超えない場合には（ステップＳ１０：ＮＯ）、ステップＳ１４に進む。
【００９１】
ステップＳ１１では、制御部１１は、サーバ停止フラグＦｓを“１”に設定してサーバ機能を停止させる。
【００９２】
次いで、制御部１１は、自己（自ノードＮｎ）が記憶部１２に保存しているコンテンツデータのレプリカを削除せずに、当該コンテンツデータに対応するコンテンツＩＤ及び自己（自ノードＮｎ）のノード情報が含まれる削除通知メッセージを、自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎ（つまり、当該コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノードＮｎ）に対して送信し（当該コンテンツＩＤのルートノード宛に通信部２０から送出させ）（ステップＳ１２）、ステップＳ１３に進む。こうして、当該削除通知メッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになり、該ルートノードは、受信した削除通知メッセージ含まれるコンテンツＩＤに対応付けられたノード情報を削除することになる。これにより、当該ノード情報が削除された後は、当該削除通知メッセージを送信したノードＮｎのノード情報は、ルートノードにより他のノードＮｎに通知されなくすることができ、当該削除通知メッセージを送信したノードＮｎへの無駄なアクセス（つまり、コンテンツデータの提供要求のためのアクセス）を無くすことができる。ただし、当該ノードＮｎのノード情報がインデックス情報から削除されても、タイムラグ等により、当該ノードＮｎにコンテンツデータの提供要求がなされる場合がありうる。
【００９３】
ステップＳ１３では、制御部１１は、パブリッシュメッセージをサーバ機能の復帰後に送信するために、上記ステップＳ１２で送出した削除通知メッセージに含まれるコンテンツＩＤをパブリッシュ待機リストに登録し、ステップＳ１４に進む。
【００９４】
ステップＳ１４では、制御部１１は、稼動時間Ｔｂが管理時間Ｔａを経過していない場合には（ステップＳ１４：ＮＯ）、ステップＳ１８に進む。一方、稼動時間Ｔｂが管理時間Ｔａを経過した場合には（ステップＳ１４：ＹＥＳ）、制御部１１は、サーバ停止フラグＦｓを“０”に設定し（その前にサーバ機能停止中（サーバ停止フラグＦｓ＝１）の場合、サーバ機能が復帰される一方、サーバ機能稼動中（サーバ停止フラグＦｓ＝０）の場合、そのまま維持されることになる）、更に、サーバ稼動実績値Ｒｓを“０”に、稼動時間Ｔｂを“０”に、夫々設定（リセット）する（ステップＳ１５）。
【００９５】
次いで、制御部１１は、パブリッシュ待機リストにコンテンツＩＤ（上記ステップＳ１３又は後述するステップＳ４７の処理で登録されたコンテンツＩＤ）が登録されているか否かを判別し（ステップＳ１６）、コンテンツＩＤが登録されていない場合には（ステップＳ１６：ＮＯ）、ステップＳ２に戻り、稼動時間Ｔｂの再計測を開始する。一方、パブリッシュ待機リストにコンテンツＩＤが登録されている場合には（ステップＳ１６：ＹＥＳ）、制御部１１は、登録されているコンテンツＩＤを含むパブリッシュメッセージを、自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送信し（当該コンテンツＩＤのルートノード宛に通信部２０から送出させる）（ステップＳ１７）、ステップＳ２に戻る。当該パブリッシュメッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになり、該ルートノードは、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報を登録することになる。このように、当該パブリッシュメセージは、サーバ機能の復帰後にルートノード向けて送出されることになるので、当該パブリッシュメセージを送信したノードＮｎへの無駄なアクセス（つまり、コンテンツデータの提供要求のためのアクセス）を無くすことができる。
【００９６】
ステップＳ１８におけるその他の処理では、例えば、ユーザからの入力部２１を介した再生指示に応じたコンテンツデータ再生処理（コンテンツデータのレプリカは、デコーダ部１４、映像処理部１５、表示部１６、音声処理部１７、及びスピーカ１８等を介して再生出力される）や、削除指示に応じたコンテンツデータ削除処理（コンテンツデータの削除が行われた場合、上述したように、削除されたレプリカに対応するコンテンツＩＤ等が含まれる削除通知メッセージがルートノード宛に送出される）が行われ、ステップＳ３に戻る。
【００９７】
次に、上記ステップＳ４におけるコンテンツデータ取得処理１では、図７（Ａ）に示すように、制御部１１は、コンテンツ所在問合せ（検索）処理を行う（ステップＳ４１）。かかるコンテンツ所在問合せ（検索）処理においては、制御部１１は、上記コンテンツ検索指示に係るコンテンツデータのコンテンツＩＤを含むコンテンツ所在問合せ（検索）メッセージを、自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送信し（当該コンテンツＩＤのルートノード宛に通信部２０から送出させる）、当該コンテンツＩＤのルートノードからインデックス情報を取得する。
【００９８】
次いで、制御部１１は、上述したコンテンツ送信要求メッセージを、上記取得したインデックス情報に含まれるＩＰアドレス等に基づき、コンテンツ保持ノードに対して送信する（ステップＳ４２）。これに応じて、コンテンツ保持ノードは、自身がサーバ機能稼動中であれば、上記コンテンツ送信要求メッセージにより指定されたコンテンツデータのレプリカを上記ユーザノード（当該コンテンツ送信要求メッセージを送信したノードＮｎ）へ送信することになり、自身がサーバ機能停止中であれば、コンテンツデータ提供不可メッセージを当該ユーザノードへ送信することになる。
【００９９】
そして、コンテンツ保持ノードから送信されたコンテンツデータのレプリカは、通信部２０を通じて受信されバッファメモリ１３に蓄積される。そして、制御部１１は、バッファメモリ１３に所定量の上記レプリカのデータが蓄積されたとき、当該レプリカのデータをバッファメモリ１３から記憶部１２に記憶保存（例えば、ＨＤの所定領域に書き込む）させる（ステップＳ４３）。こうして、順次当該レプリカのデータがバッファメモリ１３から記憶部１２に送られ記憶保存されていく。
【０１００】
次いで、制御部１１は、当該レプリカのデータが全て揃い、記憶保存された否かを判断し（ステップＳ４４）、全て記憶保存されていない場合には（ステップＳ４４：ＮＯ）、ステップ４３に戻り当該処理を継続し、全て記憶保存された場合には（ステップＳ４４：ＹＥＳ）、ステップＳ４５に進む。なお、当該レプリカのデータ量が少ない場合、バッファメモリ１３に全てのデータが揃ってから記憶部１２に記憶保存されるように構成しても良い。
【０１０１】
ステップＳ４５では、制御部１１は、サーバ停止フラグＦｓが“０”であるか否かを判別し、サーバ停止フラグＦｓが“０”である場合には（ステップＳ４５：ＹＥＳ）、ステップＳ４６に進み、サーバ停止フラグＦｓが“０”でない場合には（ステップＳ４５：ＮＯ）、ステップＳ４７に進む。
【０１０２】
ステップＳ４６では、制御部１１は、上記保存されたレプリカに係るコンテンツデータのコンテンツＩＤ等を含むパブリッシュメッセージを、自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送信（当該コンテンツＩＤのルートノード宛に通信部２０から送出させる）し、図６の処理に戻る。
【０１０３】
一方、ステップＳ４７では、制御部１１は、上述したようにパブリッシュメッセージをサーバ機能の復帰後に送信（上記ステップＳ１７の処理による）する（それまで待機させる）ために、上記保存されたレプリカに係るコンテンツデータのコンテンツＩＤをパブリッシュ待機リストに登録し、図６の処理に戻る。
【０１０４】
ここで、ステップＳ４７の処理後、当該制御部１１は、例えば自己のＤＨＴを用いたルーティングテーブルに登録された他のノードＮｎ（任意のノードＮｎ）を例えばランダムに選定し、当該選定したノードＮｎに対して、上記コンテンツＩＤ（パブリッシュ待機リストに登録したコンテンツＩＤ）を含むコンテンツデータ保存依頼メッセージ（自身が保存した上記コンテンツデータを保存させる依頼を示す）を送信するように構成しても良い。当該コンテンツデータ保存依頼メッセージを受信したノードＮｎは、当該メッセージに含まれるコンテンツＩＤと、自己のノード情報を含むコンテンツ所在問合せ（検索）メッセージを当該コンテンツＩＤのルートノード宛に送出することによりインデックス情報を取得し、当該インデックス情報に示されたコンテンツ保持ノードから当該コンテンツデータのレプリカを取得、保存し、パブリッシュメッセージをルートノード宛に送出することになる。これにより、サーバ機能停止中のノードＮｎの代わりにコンテンツ保持ノードを確保することができ、システム全体としてコンテンツデータの不足を解消することができる。
【０１０５】
次に、上記ステップＳ７のサーバ機能稼働中のメッセージ受信処理では、図８に示すように、制御部１１は、受信されたメッセージがコンテンツ所在問合せメッセージであるか否かを判別し（ステップＳ７１１）、コンテンツ所在問合せメッセージでない場合には（ステップＳ７１１：ＮＯ）、ステップＳ７１６に進む。一方、コンテンツ所在問合せメッセージである場合には（ステップＳ７１１：ＹＥＳ）、制御部１１は、所在問合せ対象のインデックス情報（コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応するインデックス情報）がインデックスキャッシュに記憶されているか否かを判別し（ステップＳ７１２）、記憶されている場合には（ステップＳ７１２：ＹＥＳ）、当該インデックス情報を該コンテンツ所在問合せメッセージの送信元であるユーザノードに対して送信し（ステップＳ７１３）、図６の処理に戻る。一方、当該インデックス情報が記憶されていない場合には（ステップＳ７１２：ＮＯ）、制御部１１は、自己（自ノードＮｎ）がルートノードであるか否かを判別（つまり、自己のルーティングテーブルを参照して、当該コンテンツ所在問合せメッセージに含まれるコンテンツＩＤと最も近いノードＩＤが自分であるか否かを判別）し（ステップＳ７１４）、自己がルートノードでない（つまり、中継ノードである）場合には（ステップＳ７１４：ＮＯ）、ステップＳ７１５に進み、自己がルートノードである場合には（ステップＳ７１４：ＹＥＳ）、図６の処理に戻る。
【０１０６】
ステップＳ７１５では、制御部１１は、受信されたコンテンツ所在問合せメッセージを、自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎ（つまり、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤと最も近いノードＩＤを有するノードＮｎ）に対して転送し（当該コンテンツＩＤのルートノード宛に通信部２０から送出させ）、図６の処理に戻る。
【０１０７】
ステップＳ７１６では、制御部１１は、受信されたメッセージがコンテンツ投入要求メッセージであるか否かを判別し、コンテンツ投入要求メッセージでない場合には（ステップＳ７１６：ＮＯ）、ステップＳ７１８に進む。一方、コンテンツ投入要求メッセージである場合には（ステップＳ７１６：ＹＥＳ）、図７（Ｂ）に示すコンテンツデータ取得処理２が行われる（ステップＳ７１７）。
【０１０８】
かかるコンテンツデータ取得処理２において、ステップＳ７１７１〜Ｓ７１７４までの処理は、上述した図７（Ａ）に示すステップＳ４１〜Ｓ４４までの処理と同様である。
【０１０９】
ここで、サーバ稼動実績値Ｒｓのパラメータが、例えばサーバ機能が稼動している時間である場合、制御部１１は、ステップＳ７１７３の処理におけるレプリカのデータの記憶部１２への記憶保存開始から終了（例えば、ＨＤへの書き込み開始から書き込み終了）までの間の時間を計測することになる。また、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動により消費した消費電力である場合、制御部１１は、ステップＳ７１７３の処理におけるレプリカのデータの記憶部１２への記憶保存開始から終了までの間に消費した消費電力を計測することになる。
【０１１０】
そして、制御部１１は、上記計測された時間（又は消費電力）を、サーバ稼動実績値Ｒｓに加算して、新たなサーバ稼動実績値Ｒｓを算出し（ステップＳ７１７５）、これを記憶（更新）する。
【０１１１】
なお、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動によりレプリカを提供又は取得した回数である場合、制御部１１は、ステップＳ７１７５において、サーバ稼動実績値Ｒｓに“１”を加算し、新たなサーバ稼動実績値Ｒｓを算出することになる。また、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動により提供又は取得したレプリカのデータ量である場合、制御部１１は、ステップＳ７１７５において、当該保存されたレプリカのデータ量をサーバ稼動実績値Ｒｓに加算し、新たなサーバ稼動実績値Ｒｓを算出することになる。
【０１１２】
次いで、制御部１１は、上述したステップＳ４６と同様、パブリッシュメッセージをルートノード宛に送出し（ステップＳ７１７６）、図８の処理に戻る。
【０１１３】
次に、ステップＳ７１８では、制御部１１は、受信されたメッセージがコンテンツ送信要求メッセージであるか否かを判別し、コンテンツ送信要求メッセージでない場合には（ステップＳ７１８：ＮＯ）、ステップＳ７２１に進む。一方、コンテンツ送信要求メッセージである場合には（ステップＳ７１８：ＹＥＳ）、コンテンツデータ提供（アップロード）処理を行う（ステップＳ７１９）。当該コンテンツ提供処理において、制御部１１は、受信されたコンテンツ送信要求メッセージにより指定されたコンテンツデータのレプリカを、記憶部１２から読み出し、所定データ単位のブロック毎に、当該コンテンツ送信要求メッセージの送信元のユーザノードに通信部２０を介して順次送信することになる。
【０１１４】
ここで、サーバ稼動実績値Ｒｓのパラメータが、例えばサーバ機能が稼動している時間である場合、制御部１１は、ステップＳ７１９の処理における、記憶部１２からのレプリカの読み出し開始から終了（送信終了）までの間の時間を計測することになる。また、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動により消費した消費電力である場合、制御部１１は、ステップＳ７１９の処理における、記憶部１２からのレプリカの読み出し開始から終了（送信終了）までの間に消費した消費電力を計測することになる。
【０１１５】
そして、制御部１１は、上記計測された時間（又は消費電力）を、サーバ稼動実績値Ｒｓに加算して、新たなサーバ稼動実績値Ｒｓを算出し（ステップＳ７２０）、これを記憶（更新）し、図６の処理に戻る。
【０１１６】
なお、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動によりレプリカを提供又は取得した回数である場合、制御部１１は、ステップＳ７２０において、サーバ稼動実績値Ｒｓに“１”を加算し、新たなサーバ稼動実績値Ｒｓを算出することになる。また、サーバ稼動実績値Ｒｓのパラメータが、サーバ機能の稼動により提供又は取得したレプリカのデータ量である場合、制御部１１は、ステップＳ７２０において、当該保存されたレプリカのデータ量をサーバ稼動実績値Ｒｓに加算し、新たなサーバ稼動実績値Ｒｓを算出することになる。
【０１１７】
次に、ステップＳ７２１では、制御部１１は、受信されたメッセージがパブリッシュメッセージであるか否かを判別し、パブリッシュメッセージでない場合には（ステップＳ７２１：ＮＯ）、ステップＳ７２５に進む。一方、パブリッシュメッセージである場合には（ステップＳ７２１：ＹＥＳ）、受信されたパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報を登録（インデックスキャッシュ領域に記憶）する（ステップＳ７２２）。
【０１１８】
次いで、制御部１１は、上記ステップＳ７１４と同様、自己がルートノードであるか否かを判別し（ステップＳ７２３）、自己がルートノードでない（つまり、中継ノードである）場合には（ステップＳ７２３：ＮＯ）、ステップＳ７２４に進み、自己がルートノードである場合には（ステップＳ７２３：ＹＥＳ）、図６の処理に戻る。
【０１１９】
ステップＳ７２４では、制御部１１は、受信されたパブリッシュメッセージを、自己のルーティングテーブルにしたがって他のノードＮｎに対して転送し、図６の処理に戻る。
【０１２０】
次に、ステップＳ７２５では、制御部１１は、受信されたメッセージが削除通知メッセージであるか否かを判別し、削除通知メッセージでない場合には（ステップＳ７２５：ＮＯ）、ステップＳ７２９に進む。一方、削除通知メッセージである場合には（ステップＳ７２５：ＹＥＳ）、受信された削除通知メッセージに含まれるコンテンツＩＤに対応付けられたノード情報を削除する（ステップＳ７２６）。
【０１２１】
次いで、制御部１１は、上記ステップＳ７１４と同様、自己がルートノードであるか否かを判別し（ステップＳ７２７）、自己がルートノードでない（つまり、中継ノードである）場合には（ステップＳ７２７：ＮＯ）、ステップＳ７２８に進み、自己がルートノードである場合には（ステップＳ７２７：ＹＥＳ）、図６の処理に戻る。
【０１２２】
ステップＳ７２８では、制御部１１は、受信された削除通知メッセージを、自己のルーティングテーブルにしたがって他のノードＮｎに対して転送し、図６の処理に戻る。
【０１２３】
なお、ステップＳ７２９における、その他のメッセージ受信処理においては、その他のメッセージ（例えば、参加メッセージ等）が受信された場合の処理が行われ、図６の処理に戻る。
【０１２４】
次に、上記ステップＳ８のサーバ機能停止中のメッセージ受信処理では、図９に示すように、制御部１１は、受信されたメッセージがコンテンツ所在問合せメッセージであるか否かを判別し（ステップＳ８１１）、コンテンツ所在問合せメッセージでない場合には（ステップＳ８１１：ＮＯ）、ステップＳ８１５に進む。一方、コンテンツ所在問合せメッセージである場合には（ステップＳ８１１：ＹＥＳ）、制御部１１は、自己（自ノードＮｎ）がルートノードであるか否かを判別し（ステップＳ８１２）、自己がルートノードでない（つまり、中継ノードである）場合には（ステップＳ８１２：ＮＯ）、コンテンツ所在問合せメッセージを自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して転送（サーバ機能停止中のためインデックス情報を送信することなく）し、図６の処理に戻る。一方、自己がルートノードである場合には（ステップＳ８１２：ＹＥＳ）、コンテンツ所在問合せメッセージ送信元のユーザノードに対して、サーバ機能停止中であることを示すサーバ機能停止メッセージを送信（サーバ機能停止中のためインデックス情報を送信することなく）し（ステップＳ８１３）、図６の処理に戻る。
【０１２５】
なお、インデックス情報の送信は、コンテンツデータのレプリカの送信に比べて、ノードＮｎの負担が非常に少ないことから、ステップＳ８１３において、サーバ機能停止メッセージに代えて、インデックス情報を該コンテンツ所在問合せメッセージの送信元であるユーザノードに対して送信するように構成しても良い。
【０１２６】
ステップＳ８１５では、制御部１１は、受信されたメッセージがコンテンツ投入要求メッセージであるか否かを判別し、コンテンツ投入要求メッセージでない場合には（ステップＳ８１６：ＮＯ）、ステップＳ８１７に進む。一方、コンテンツ投入要求メッセージである場合には（ステップＳ８１５：ＹＥＳ）、制御部１１は、例えば自己のＤＨＴを用いたルーティングテーブルに登録された他のノードＮｎをランダムに選定し、当該選定したノードＮｎに対して、上記受信されたコンテンツ投入要求メッセージを転送する（ステップＳ８１６）。当該コンテンツ投入要求メッセージの転送を受けたノードＮｎは、当該メッセージに含まれるコンテンツＩＤに基づき、コンテンツ所在問合せ（検索）メッセージを当該コンテンツＩＤのルートノード宛に送出することによりインデックス情報を取得し、当該インデックス情報に示されたコンテンツ保持ノードから当該コンテンツデータのレプリカを取得、保存し、パブリッシュメッセージをルートノード宛に送出することになる。これにより、サーバ機能停止中のノードＮｎの代わりにコンテンツ保持ノードを確保することができる。なお、受信されたメッセージがコンテンツ投入要求メッセージである場合、コンテンツ投入要求メッセージの送信元のサーバに対して、コンテンツデータ投入拒否メッセージ（投入要求に係るコンテンツデータを投入できないことを示す情報）を返信するように構成しても良い。或いは、コンテンツ投入要求メッセージの転送及びコンテンツデータ投入拒否メッセージの送信をせずに、サーバ機能の復帰後にステップＳ７１７のコンテンツデータ取得処理２を行うように構成しても良い。
【０１２７】
次に、ステップＳ８１７では、制御部１１は、受信されたメッセージがコンテンツ送信要求メッセージであるか否かを判別し、コンテンツ送信要求メッセージでない場合には（ステップＳ８１７：ＮＯ）、ステップＳ８１９に進む。一方、コンテンツ送信要求メッセージである場合には（ステップＳ８１７：ＹＥＳ）、サーバ機能停止中であるためコンテンツデータのレプリカの提供できないことを示すコンテンツ提供不可メッセージを、上記コンテンツ送信要求メッセージの送信元のユーザノードに送信し（ステップＳ８１８）、図６の処理に戻る。
【０１２８】
なお、ステップＳ８１９〜Ｓ８２７までの処理は、図８に示すステップＳ７２１〜Ｓ７２９までの処理と同様である。
【０１２９】
以上説明したように、上記実施形態によれば、ノードＮｎにおけるサーバ機能が稼動した実績を定量的に示すサーバ稼動実績値を算出し、当該算出された稼動実績値が、サーバ稼動制限値以上になったか否かを判別し、当該サーバ稼動実績値が上記サーバ稼動制限値以上になった場合には、サーバ機能を停止させるように構成したので、当該サーバ稼動制限値により、ノードＮｎの負担について上限値を持たせることができ（負担を一定枠に抑えることができ）、各ノードＮｎ間における負担（例えば、負担する費用（例えば、電気代やメンテナンス代））の差異を少なくし、不公平を低減させることができる。
【０１３０】
また、サーバ機能を停止させた後、当該稼動時間が予め設定された基準時間としての管理時間（例えば、２４時間）を経過した場合には、サーバ機能を復帰させ、上記稼動時間をリセット（管理時間毎にリセット）させるように構成したので、各ノードＮｎ間における負担の差異を低減させつつ、コンテンツ分散保存システムＳの安定的な運用（コンテンツデータのレプリカ授受に関する運用）を図ることができる。
【０１３１】
なお、上記実施形態におけるコンテンツ分散保存システムＳは、ＤＨＴを利用したアルゴリズムによって形成されることを前提として説明したが、本発明はこれに限定されるものではない。
【図面の簡単な説明】
【０１３２】
【図１】本実施形態に係るコンテンツ分散保存システムにおける各ノード装置の接続態様の一例を示す図である。
【図２】ノードＮ２が保持するＤＨＴを用いたルーティングテーブルの一例を示す図である。
【図３】ＤＨＴのＩＤ空間の一例を示す概念図である。
【図４】ユーザノードから送出されたコンテンツ所在問合せ（検索）メッセージの流れの一例を、ＤＨＴのＩＤ空間にて示した概念図である。
【図５】ノードＮｎの概要構成例を示す図である。
【図６】ノードＮｎの制御部１１におけるメイン処理を示すフローチャートである。
【図７】（Ａ）は、図６に示すコンテンツデータ取得処理１の詳細を示すフローチャートであり、（Ｂ）は、図８に示すコンテンツデータ取得処理２の詳細を示すフローチャートである。
【図８】サーバ機能稼動中のメッセージ受信処理の詳細を示すフローチャートである。
【図９】サーバ機能停止中のメッセージ受信処理の詳細を示すフローチャートである。
【符号の説明】
【０１３３】
８  ネットワーク
９  オーバーレイネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
２０  通信部
２１  入力部
２２  バス
Ｎｎ  ノード
Ｓ  コンテンツ分散保存システム
【図１】
2008236536.tif 000003
【図２】
2008236536.tif 000004
【図３】
2008236536.tif 000005
【図４】
2008236536.tif 000006
【図５】
2008236536.tif 000007
【図６】
2008236536.tif 000008
【図７】
2008236536.tif 000009
【図８】
2008236536.tif 000010
【図９】
2008236536.tif 000011