(57)【要約】【課題】全体としての消費電力及び騒音夫々を低下させることが可能なコンテンツ配信システムを提供する。【解決手段】ルートノードＲＮ又はキャッシュノードＣＮにリクエスタＲＱから参照可能に記録されたインデックス情報ＥＸＸ内に、コンテンツＩＤ及びコンテンツホルダＣＨのＩＰアドレスに加えて、そのルートノードＲＮ等をリクエスタＲＱに通知した時刻を示す通知時刻情報１００を含む補助情報ＨＰを追加する。ルートノードＲＮ又はキャッシュノードＣＮにおいては、最新に配信を始めたコンテンツホルダＣＨからから優先して選択し、リクエスタＲＱに通知する。【選択図】図３
2008293145.tif 000002
【特許請求の範囲】
【請求項１】
配信されるべき配信情報を蓄積する蓄積装置を示す蓄積装置情報を、一又は複数の当該蓄積装置について記憶する記憶手段を備える情報処理装置において、
各前記蓄積装置情報が夫々対応する前記蓄積装置を識別するための蓄積装置識別情報を、当該各蓄積装置情報が夫々対応する前記蓄積装置が蓄積している前記配信情報の配信を要求する配信要求装置に対して送信した時刻を示す送信時刻情報が、各前記蓄積装置情報に含まれており、
前記配信要求装置から前記配信を要求する配信要求情報が送信されて来たとき、当該配信要求情報を受信する受信手段と、
前記受信した配信要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置を示す前記蓄積装置情報を、前記記憶手段内において検索する検索手段と、
前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求情報を送信して来た前記配信要求装置に送信するに当たり、前記送信時刻が新しい前記蓄積装置識別情報を当該配信要求装置に送信する送信手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記蓄積装置情報には、当該蓄積装置情報が対応する前記蓄積装置において、前記配信要求情報により前記配信が要求されている前記配信情報が現在配信中であることを示す配信中情報が更に含まれており、
前記送信手段は、前記蓄積装置識別情報を送信するに当たり、前記配信中情報に基づいて、配信中の前記配信情報を蓄積している前記蓄積装置を識別するための当該蓄積装置識別情報のうち、前記送信時刻が新しい当該蓄積装置識別情報を前記配信要求装置に送信することを特徴とする情報処理装置。
【請求項３】
請求項２に記載の情報処理装置において、
前記配信中情報は、当該配信中情報に対応する前記配信情報の配信終了予測時刻を示す予測時刻情報であり、
前記送信手段は、前記蓄積装置識別情報を送信するに当たり、前記配信終了予測時刻が現在時刻より後の前記蓄積装置識別情報のみ前記配信要求装置に送信することを特徴とする情報処理装置。
【請求項４】
請求項１から３のいずれか一項に記載の情報処理装置において、
前記送信手段は、前記送信時刻が最も新しい前記蓄積装置識別情報のみを前記配信要求装置に送信することを特徴とする情報処理装置。
【請求項５】
請求項２から４のいずれか一項に記載の情報処理装置において、
前記送信手段は、前記配信中情報に基づき、配信中の前記配信情報がないとき、前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求装置に送信することを特徴とする情報処理装置。
【請求項６】
配信されるべき配信情報を蓄積する蓄積装置を示す蓄積装置情報を、一又は複数の当該蓄積装置について記憶する記憶手段を備える情報処理装置において実行される情報処理方法であって、
各前記蓄積装置情報が夫々対応する前記蓄積装置を識別するための蓄積装置識別情報を、当該各蓄積装置情報が夫々対応する前記蓄積装置が蓄積している前記配信情報の配信を要求する配信要求装置に対して送信した時刻を示す送信時刻情報が、各前記蓄積装置情報に含まれており、
前記配信要求装置から前記配信を要求する配信要求情報が送信されて来たとき、当該配信要求情報を受信する受信工程と、
前記受信した配信要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置を示す前記蓄積装置情報を、前記記憶手段内において検索する検索工程と、
前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求情報を送信して来た前記配信要求装置に送信するに当たり、前記送信時刻が新しい前記蓄積装置識別情報を当該配信要求装置に送信する送信工程と、
を含むことを特徴とする情報処理方法。
【請求項７】
コンピュータを、請求項１から５のいずれか一項に記載の情報処理装置として機能させることを特徴とする情報処理装置用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及び情報処理用プログラムの技術分野に属し、より詳細には、ネットワークを介して配信されるべき映画等のコンテンツ（配信情報）を、当該配信用に蓄積する蓄積装置及び当該蓄積装置からの当該配信情報の配信等を行う情報処理装置及び当該情報処理装置における情報処理方法並びに当該情報処理装置用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワーク技術は著しく進歩しつつあり、その中で、例えば下記特許文献１に開示されている如きコンテンツ配信システムに関する研究が行われている。
【０００３】
ここで、当該コンテンツ配信システムにおいて、例えば映画等のコンテンツは、その製作者又は管理者（当該製作者又は管理者を、以下単に管理者等と称する）により当該コンテンツ配信システム内のいずれかのコンテンツノードに対してネットワークを介して最初に配信され、当該各コンテンツノードにおいて蓄積／記憶される。なお、上記管理者等によりコンテンツ配信システム内に最初にコンテンツが配信されることを、以下、「コンテンツの投入」と称する。
【０００４】
そして、当該投入されたコンテンツをコンテンツ配信システム内において配信する場合には、当該コンテンツに相当する動画情報等を蓄積／記憶している上記コンテンツノードから、当該コンテンツの視聴を希望する者により操作されるリクエストノードに対して当該動画情報等が配信（伝送）される。
【０００５】
なお、当該「コンテンツノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００７１］を参照することができ、また当該「リクエストノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００６４］及び［００６５］を参照することができる。
【０００６】
また、上記コンテンツ配信システムにおいては、一旦投入されたコンテンツは、初期投入の後、最初に投入先となったコンテンツノードだけではなく、例えば分散ハッシュテーブル（いわゆるＤＨＴ（Distributed Hash Table））アルゴリズムに則って他のノード内にそのコンテンツの複製（レプリカ）が作成される。そして、当該レプリカが暫増的に作成されることで、最初に投入されたコンテンツノード以外にも、同一のコンテンツを蓄積／記憶するコンテンツノードがコンテンツ配信システム内に複数存在することとなる。これにより、配信元の分散が実現され、リクエストノードへの配信の迅速化及び安定化が図られることとなる。
【０００７】
なお、上記レプリカが作成されたノードを、以下、適宜「レプリカノード」と称する。また、上記ＤＨＴアルゴリズムについては、例えば下記特許文献１の明細書段落番号［００３９］乃至［００７２］並びに図１乃至図５の記載を参照することができる。
【０００８】
ここで、下記特許文献１に記載された上記ＤＨＴアルゴリズムに用いられるＤＨＴ内においては、各コンテンツノード又はレプリカノードについて相対的な重み付けがされていることがなかったため、配信が所望されているコンテンツを蓄積しているコンテンツノード又はレプリカノードについては、各ノードがほぼ均等の機会でもってそのコンテンツの配信の用に供されることとなっていた。
【特許文献１】特開２００６−１９７４００公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した特許文献１記載のコンテンツ配信システムでは、上述した如く配信が所望されるコンテンツを蓄積しているコンテンツノード又はレプリカノードの各々がほぼ均等にそのコンテンツの配信の用に供されることとなっていたため、コンテンツ配信システム全体としてみた場合に稼働しているコンテンツノード又はレプリカノードの数が増加することとなる。
【００１０】
この結果、多数のコンテンツノードやレプリカノードが一カ所に集められている例えば配信事業者等を想定する場合、その配信事業者等に係るコンテンツ配信システム全体としての消費電力が大きくなるという問題点があった。
【００１１】
そこで、本発明は、上記の各問題点に鑑みて為されたもので、その目的は、全体としての消費電力を低下させることが可能なコンテンツ配信システムに含まれるノード、当該ノードにおける情報処理方法及び当該ノード用のプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上記の課題を解決するために、請求項１に記載の発明は、配信されるべき配信情報を蓄積する蓄積装置を示す蓄積装置情報を、一又は複数の当該蓄積装置について記憶する記憶手段を備える情報処理装置において、各前記蓄積装置情報が夫々対応する前記蓄積装置を識別するための蓄積装置識別情報を、当該各蓄積装置情報が夫々対応する前記蓄積装置が蓄積している前記配信情報の配信を要求する配信要求装置に対して送信した時刻を示す送信時刻情報が、各前記蓄積装置情報に含まれており、前記配信要求装置から前記配信を要求する配信要求情報が送信されて来たとき、当該配信要求情報を受信する受信手段と、前記受信した配信要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置を示す前記蓄積装置情報を、前記記憶手段内において検索する検索手段と、前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求情報を送信して来た前記配信要求装置に送信するに当たり、前記送信時刻が新しい前記蓄積装置識別情報を当該配信要求装置に送信する送信手段と、を備える。
【００１３】
よって、配信要求装置に対して当該配信要求に対応する蓄積装置識別情報を送信するに当たり、配信が要求されている配信情報を蓄積する蓄積装置を示す蓄積装置識別情報のうち送信時刻が新しいものを送信するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００１４】
上記の課題を解決するために、請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記蓄積装置情報には、当該蓄積装置情報が対応する前記蓄積装置において、前記配信要求情報により前記配信が要求されている前記配信情報が現在配信中であることを示す配信中情報が更に含まれており、前記送信手段は、前記蓄積装置識別情報を送信するに当たり、前記配信中情報に基づいて、配信中の前記配信情報を蓄積している前記蓄積装置を識別するための当該蓄積装置識別情報のうち、前記送信時刻が新しい当該蓄積装置識別情報を前記配信要求装置に送信するように構成される。
【００１５】
よって、配信中情報を用いて、現在配信情報を配信中の蓄積装置から更に新たな配信を受けることができるので、消費電力の増大等をより効果的に抑制することができる。
【００１６】
上記の課題を解決するために、請求項３に記載の発明は、請求項２に記載の情報処理装置において、前記配信中情報は、当該配信中情報に対応する前記配信情報の配信終了予測時刻を示す予測時刻情報であり、前記送信手段は、前記蓄積装置識別情報を送信するに当たり、前記配信終了予測時刻が現在時刻より後の前記蓄積装置識別情報のみ前記配信要求装置に送信するように構成される。
【００１７】
よって、配信中情報が配信終了予測時刻であり、当該配信終了予想時刻が現在時刻よりも後の蓄積装置識別情報のみ配信要求装置に送信するので、確実に、配信を実行中の蓄積装置から更に新たな配信を受けることができる。
【００１８】
上記の課題を解決するために、請求項４に記載の発明は、請求項１から３のいずれか一項に記載の情報処理装置において、前記送信手段は、前記送信時刻が最も新しい前記蓄積装置識別情報のみを前記配信要求装置に送信するように構成される。
【００１９】
よって、送信時刻が最も新しい蓄積装置識別情報のみ配信要求装置に送信するので、処理を簡略化しつつ配信を実行中の蓄積装置から更に新たな配信を受けることができる。
【００２０】
上記の課題を解決するために、請求項５に記載の発明は、請求項２から４のいずれか一項に記載の情報処理装置において、前記送信手段は、前記配信中情報に基づき、配信中の前記配信情報がないとき、前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求装置に送信するように構成される。
【００２１】
よって、要求した配信情報を配信中の蓄積装置がない場合でも、いずれかの蓄積装置から必要な配信情報の配信を受けることができる。
【００２２】
上記の課題を解決するために、請求項６に記載の発明は、配信されるべき配信情報を蓄積する蓄積装置を示す蓄積装置情報を、一又は複数の当該蓄積装置について記憶する記憶手段を備える情報処理装置において実行される情報処理方法であって、各前記蓄積装置情報が夫々対応する前記蓄積装置を識別するための蓄積装置識別情報を、当該各蓄積装置情報が夫々対応する前記蓄積装置が蓄積している前記配信情報の配信を要求する配信要求装置に対して送信した時刻を示す送信時刻情報が、各前記蓄積装置情報に含まれており、前記配信要求装置から前記配信を要求する配信要求情報が送信されて来たとき、当該配信要求情報を受信する受信工程と、前記受信した配信要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置を示す前記蓄積装置情報を、前記記憶手段内において検索する検索工程と、前記検索された蓄積装置情報に対応する前記蓄積装置識別情報を前記配信要求情報を送信して来た前記配信要求装置に送信するに当たり、前記送信時刻が新しい前記蓄積装置識別情報を当該配信要求装置に送信する送信工程と、を含む。
【００２３】
よって、配信要求装置に対して当該配信要求に対応する蓄積装置識別情報を送信するに当たり、配信が要求されている配信情報を蓄積する蓄積装置を示す蓄積装置識別情報のうち送信時刻が新しいものを送信するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００２４】
上記の課題を解決するために、請求項７に記載の発明は、コンピュータを、請求項１から５のいずれか一項に記載の情報処理装置として機能させる。
【００２５】
よって、配信要求装置に対して当該配信要求に対応する蓄積装置識別情報を送信するに当たり、配信が要求されている配信情報を蓄積する蓄積装置を示す蓄積装置識別情報のうち送信時刻が新しいものを送信するように当該コンピュータが機能するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【発明の効果】
【００２６】
以上説明したように、本発明によれば、配信要求装置に対して当該配信要求に対応する蓄積装置識別情報を送信するに当たり、配信が要求されている配信情報を蓄積する蓄積装置を示す蓄積装置識別情報のうち送信時刻が新しいものを送信するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００２７】
従って、コンテンツ配信システム全体としての消費電力を低下させることが可能となる。
【発明を実施するための最良の形態】
【００２８】
次に、本発明を実施するための最良の形態について、図面に基づいて説明する。なお、以下に説明する実施形態は、インターネット等のネットワークを用いて上記コンテンツの配信を行う配信システムであって、当該ネットワークに属する端末装置間で、当該コンテンツが相互に直接授受される（換言すれば、コンテンツを複数の端末装置間で共有する）配信システム、すなわちいわゆるＰ２Ｐ（Pear to Pear）型の配信システムに対して本発明を適用した場合の実施の形態である。なお、以下の説明においては、上記端末装置を一般的に「ノード」と称することとする。
【００２９】
（Ｉ）本発明の原理
初めに、本発明の実施形態について具体的に説明する前に、本発明の原理につき、実施形態に係るＰ２Ｐ型配信システム（以下、単に配信システムと称する）の概要と共に説明する。
【００３０】
（Ａ）配信システムの概要
先ず、実施形態に係る配信システムの概要につき、図１及び図２を用いて説明する。なお、図１及び図２は当該配信システムの概要を示す模式図である。
【００３１】
上記特許文献１に記載されているＤＨＴを用いた配信システムでは、上記特許文献１にも一部記載されているが、その配信システムによって配信されるコンテンツ自体にも、他のコンテンツとは異なるユニークなコンテンツＩＤを付与する。このコンテンツＩＤのビット長も上記ノードＩＤのビット長と同一とされる。そして、当該コンテンツＩＤとして一般的には、そのコンテンツのタイトルを示すタイトルデータ、コンテンツを構成するデータの属性を示す属性データ、コンテンツを構成するデータのうち先頭から数バイト分のデータ等に対してハッシュ関数を適用して得られる値を用いる。
【００３２】
ここで、対応するノードＩＤ及びコンテンツＩＤが相互に同じビット長で表現されていることも関連して、上記ノード及びコンテンツは、同一のリング状の仮想的なＩＤ空間上に点在するものとして考えることができる。すなわち、一のノードを●で表示し且つ一のコンテンツを○で表示する図１（ａ）に示すように、コンテンツが属するリングＲcとノードが属するリングＲnとを仮想的に同心円状に想定し、更に各リングＲc及びＲnにおいて反時計回りに各ＩＤの値が増加すると規定すると、各ノード又は各コンテンツは、各リングＲc及びＲn上に重なることなく存在すると仮定できるのである。なお、各ＩＤを上記の例のように１２８ビット長で表現すると桁数が多くなりすぎるので、図１（ａ）においては、説明の簡略化のために、各ＩＤのビット長を３２ビットとして表現している（以下、同様）。そして、上述したように各ＩＤの値を決めるに当たってハッシュ関数を用いたことに起因して、各ノード及び各コンテンツは、上記各リングＲc及びＲn上に偏ることなく概ね分散して存在することとなる。
【００３３】
一方、上記ＤＨＴを用いた配信システムでは、「あるコンテンツＩＤが付与されているコンテンツを管理するノードは、そのコンテンツＩＤの値に一番近い値を有するノードＩＤが付与されているノード」とされている。
【００３４】
ここで、「近い」とは、その配信システムに関する各種規定等において一貫してさえいればどのような定義付けでも良いのであるが、具体的には例えば、「そのコンテンツＩＤの値を超えない値であって且つＩＤとしての値同士の差が最も小さいもの」というように定義付けられる。
【００３５】
より具体的には、例えば図１（ａ）に例示するように、ノードＩＤの値が「Ａ０３３４０５５」であるノードとノードＩＤの値が「Ａ０３３４０ＦＦ」であるノードとがリングＲn上で隣り合って存在しているとすると、コンテンツＩＤの値が「Ａ０３３４０８０」であるコンテンツは、ノードＩＤの値が「Ａ０３３４０５５」であるノードが管理することになる。なお、図１（ａ）では、○のコンテンツを管理する端末情報を、当該各○から伸びた矢印で示している。このようにすると、多数のノードで分散して様々なコンテンツを管理することができる。
【００３６】
このとき、「管理」とは、そのコンテンツＩＤが付与されているコンテンツをその中に記録しているという意味ではなく、そのコンテンツが記録されているノードの所在（例えばＩＰアドレス等）を認識しているとの意味である。実際にコンテンツが記録されているノードと管理するノードとが異なっても良いし、或いは管理するノード内にその管理対象であるコンテンツが記録されていても良い。
【００３７】
そして、上述したコンテンツ管理用のノードを「ルートノード」と称する。ルートノードは、それが管理することとされているコンテンツを示すコンテンツＩＤと、当該コンテンツＩＤにより示されるコンテンツが記録されているノードのＩＰアドレスと、の対からなるインデックス情報を記録し、これを配信システム内の他のノードから参照可能に記録する。このインデックス情報内に、そのコンテンツのタイトルやその属性（ジャンル）等が含まれる場合もある。
【００３８】
また、異なるコンテンツを夫々示すコンテンツＩＤが偶然に近い値となり、その値に近い値のノードＩＤを有するノードが他に存在しない場合には、一つのルートノードが複数のコンテンツに対応する複数のインデックス情報を記録することとなる。更に、同一のコンテンツが異なる複数のノード内に記録されている場合であって、その同一のコンテンツを記録しているノードが偶然に一つのルートノードに近い場合、当該ルートノードには、同一のコンテンツが夫々に記録されている複数のノードのインデックス情報が記録されることとなる。上述してきたルートノード内のインデックス情報ＥＸの一例を図１（ｂ）に示す。
【００３９】
更に、実際に各コンテンツ自体を記録しているノードを「コンテンツホルダ」と称する。このとき、当該コンテンツホルダ自体はノードであるから、そのノードＩＤは、図１（ａ）におけるリングＲn上に存在していることになる。
【００４０】
次に、上記ＤＨＴを用いた配信システムにおいて、上述したように全てのノードのＩＰアドレスを各ノード夫々が記録する必要性を排除するための工夫の一つであるＤＨＴ（ルーティングテーブル）自体について説明する。
【００４１】
実施形態に係るＤＨＴには、図１に例示したＩＤ空間を段階的なレベル毎にレベル数を上げつつ細分化（例えば、レベル１の場合は当該ＩＤ空間を四分割）していき、そのレベル毎（段階的に細分化した領域毎）に、任意のノードのノードＩＤとそのＩＰアドレスとを対としたルーティング情報が記述されている。そして、例えばコンテンツの配信元情報を要求するための配信元問い合わせ情報をそのインデックス情報が記録されているルートノードに転送する場合、このルーティング情報を参照しつつ当該問い合わせ情報を目的のルートノードまで転送する。すなわち、ＤＨＴにおけるレベルが上がる度に、ルーティング先のノードＩＤが到達しようとするルートノードのノードＩＤに一桁ずつ合致していき、最終的に当該到達しようとするルートノードに上記要求情報が到達することになる。
【００４２】
なお、ＤＨＴを用いた配信システムにおいては、上述した如き問い合わせ情報（クエリ）や、そのコンテンツの配信自体を要求する配信要求情報、及び後述する登録メッセージ、などを「メッセージ」と称している。そして、上述した仕組みのＤＨＴを使うと、上記メッセージを図１に例示する如き上記ＩＤ空間内で効率よく目的のノードまで転送することができる。なお、以下の説明においては、コンテンツホルダにおいて新たにコンテンツが記録された場合に、それを他のノードから発見可能にする（公開する）ために、当該コンテンツホルダにおいて生成されるメッセージを登録メッセージと称し、後述するリクエスタからルートノード又は後述するキャッシュノードに対して送信するメッセージを配信元問い合わせメッセージと称する。
【００４３】
ここで、上述したようにルートノードのノードＩＤの値は、そのルートノードがコンテンツを管理しているコンテンツホルダのノードＩＤの値に最も近いのであるから、上記配信元問い合わせメッセージは、当該配信要求メッセージにより要求されているコンテンツホルダに到達する直前に、配信要求対象のコンテンツを管理するルートノードに到達することになる。そして、当該配信元問い合わせメッセージを受け取ったルートノードは、その配信元問い合わせメッセージにより要求されているコンテンツを蓄積しているコンテンツホルダのＩＰアドレス等を、当該配信元問い合わせメッセージの発信元まで返信する。すなわち、ルートノード内に記録されているインデックス情報（図１（ｂ）参照）の中から、当該配信元問い合わせメッセージにより要求されているコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等が配信元問い合わせメッセージの発信元であるノードまで返信される。このようなＤＨＴの活用により、効率的に所望のコンテンツの所在が例えば配信要求元において認識できるのである。なお、上述したコンテンツの配信要求元であるノードを、以下「リクエスタ」と称する。
【００４４】
次に、あるノードに新たなコンテンツが蓄積された場合における当該コンテンツの登録処理について説明する。
【００４５】
新しいコンテンツがノード、すなわちそのコンテンツのコンテンツホルダに蓄積されると、そのコンテンツホルダは、配信システム内の他のノードに対してそのコンテンツが蓄積されたことを公開することになる。
【００４６】
すなわち、あるノードに新たなコンテンツが蓄積されたとき、当該蓄積されたコンテンツに対するコンテンツホルダとなるそのノードは、蓄積されたコンテンツのタイトル等に基づき、当該コンテンツに対応するコンテンツＩＤを算出する。
【００４７】
次に、当該コンテンツホルダは、算出されたコンテンツＩＤと同じ値を有するノードＩＤを有するノードを到達先として（そのノードＩＤを有するノードが実在するかどうかに拘わらず）、登録メッセージを送信する。この登録メッセージは、そのコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等を含むものであり、上記ＤＨＴの記述に従って各ルーティング先を介して各レベルの到達先としてのノードに順次転送される。
【００４８】
そして、最も近い値のノードＩＤを有するノードに到達すると、そのノードはその後にその登録メッセージを転送すべきノードがＩＤ空間内に存在しないことが認識して（ＤＨＴで桁合わせをすると、次に転送すべきノードが自分自身であることを認識する）、この時点で当該登録メッセージが到達しているノードが新たなコンテンツを管理するルートノードとなることになる。そして、当該ルートノードとなったノードは、登録メッセージ含まれているコンテンツＩＤ及びコンテンツホルダを示すＩＰアドレス並びに属性情報等を図１（ｂ）に例示するインデックス情報ＥＸとして記録する。
【００４９】
次に、実施形態に係る配信システムにおける「キャッシュノード」なる概念について、図２を用いて説明する。なお、図２及び後述の図３においては、ルートノードを二重丸で示し、コンテンツホルダを内部に×が記された○で示し、リクエスタを内部に｜が記された○で示し、後述するキャッシュノードを内部に＋が記された○で示し、他の一般のノードは●で示す。
【００５０】
上述したＤＨＴを用いたルーティングによりリクエスタＲＱ１乃至ＲＱ３からの配信元問い合わせメッセージＱrをルートノードＲＮ（又はコンテンツホルダＣＨ）に転送する場合、その転送経路（図２（ａ）及び図２（ｂ）において破線で示す）は、図２（ａ）に示すように上述した登録メッセージＱpが辿った経路（図２（ａ）及び図２（ｂ）において実線で示す）と似た経路となるので、この経路上にある各ノード（図２（ａ）において符号ＣＮで示す）においても図１（ｂ）に例示するインデックス情報ＥＸを記録しておけば、当該経路を経る配信元問い合わせメッセージＱrに対応して、その到達先であるルートノードＲＮ又はコンテンツホルダＣＨに当該配信元問い合わせメッセージＱrが到達する前に、早い段階で当該配信元問い合わせメッセージＱrに対応する回答をリクエスタＲＱ１乃至ＲＱ３まで返信することができる。
【００５１】
すなわち、配信システム内に公開されたコンテンツの配信を要求するリクエスタＲＱ１乃至ＲＱ３が、そのコンテンツが記録されているノード（すなわちコンテンツホルダＣＨ）のＩＰアドレスを要求する旨の配信元問い合わせメッセージＱrを送信すると、当該配信元問い合わせメッセージＱrは各ノード内のＤＨＴに記述されているルーティング先を転送されルートノードＲＮに近づいていく。そして、最終的には、その経路がコンテンツホルダＣＨからの登録メッセージＱpの経路と合流して、ルートノードＲＮに到達する。
【００５２】
ここで、図２（ａ）に示したリングＲc上の経路を木構造に置き換えると図２（ｂ）に示した如きものとなるが、これを実施形態においては「スパニングツリー」と称する。
【００５３】
図２（ａ）に示したように、各リクエスタＲＱから送信された配信元問い合わせメッセージＱrの経路とコンテンツホルダＣＨから送信された登録メッセージＱpの経路とは、それら経路上のいずれかのノードにおいていずれ交わる。そこで、公開用の登録メッセージＱpをルートノードＲＮまで到達させる経路上にあるノード夫々に当該登録メッセージＱpに含まれているインデックス情報ＥＸを、一時的に記録可能な一時記録領域に記録させつつ（すなわち、一時的にキャッシュさせつつ）当該登録メッセージＱpの転送を行う。そうすれば、リクエスタＲＱからの配信元問い合わせメッセージＱrに対する返信を、ルートノードＲＮに至る経路上の配信元問い合わせメッセージＱrが到達したノードから、配信元問い合わせメッセージＱrがルートノードＲＮに到達する前に行うことができるのである。このようにルートノードＲＮ以外のノードであってインデックス情報ＥＸを一時的に記録しているノードを、以下「キャッシュノード」ＣＮと称する。
【００５４】
（Ｂ）本発明の原理
次に、概要を上述した配信システムを前提とする本発明に原理について、図３を用いて説明する。
【００５５】
上述した配信システムにおけるインデックス情報ＥＸとしては、図１（ｂ）に例示した如きものであり、これには、当該インデックス情報ＥＸの夫々が対応するコンテンツ自体を示す情報（例えば図１（ｂ）に例示するタイトルやジャンル、或いは監督名等）の他は、対応するコンテンツＩＤ及びそのコンテンツが記録されている蓄積装置としてのコンテンツホルダＣＨのＩＰアドレス等のみであって、対応するコンテンツホルダＣＨ自体を示す上記ＩＰアドレス等を返信情報ＲＴとして対応するリクエスタＲＱに通知した時刻である通知時刻を示す情報は含まれていなかった。
【００５６】
そこで、図３に示すように、本発明では、このインデックス情報ＥＸの夫々に対して、当該インデックス情報ＥＸが対応するコンテンツが記録されているコンテンツホルダＣＨを示す上記ＩＰアドレス等をリクエスタＲＱに最新に通知した時刻である通知時刻を示す通知時刻情報１００と、その通知時刻において通知されたＩＰアドレスに対応するコンテンツホルダＣＨからの配信が終了する予想時刻である終了予測時刻を示す終了予測時刻情報１０１と、を夫々に含む補助情報ＨＰを夫々追加する。なお、図３においては、上記新たに追加される補助情報ＨＰを特徴的に示しており、元々インデックス情報ＥＸとして含まれていた上記コンテンツ自体を示す情報の記載は省略している。
【００５７】
そして、他のリクエスタＲＱがそのインデックス情報ＥＸを補助情報ＨＰと共に参照したときに、当該補助情報ＨＰに基づき、（他のリクエスタＲＱに対して）最新に配信を開始したコンテンツホルダＣＨから優先して接続し、当該配信を当該他のリクエスタＲＱと並行して当該接続されたコンテンツホルダＣＨから受けることとする。
【００５８】
これにより、例えば図４に例示するように、あるタイミングＴで見た場合において同一のコンテンツＣＴを配信している二つのコンテンツホルダＣＨがあった場合、第一のコンテンツホルダＣＨ（図４において「Ｎｏ．１」と示す）に接続するのではなく、同じコンテンツＣＴの配信を当該第一のコンテンツホルダＣＨよりも遅く開始した第二のコンテンツホルダＣＨ（図４において「Ｎｏ．２」と示す）に接続して当該第二のコンテンツホルダＣＨからその配信を受ける。
【００５９】
このようにすることで、同じコンテンツＣＴの配信につき、現在その配信を行っている第二のコンテンツホルダＣＨ以外の他のコンテンツホルダＣＨが新たなに配信のための稼働を開始することなく、その第二のコンテンツホルダＣＨから並行してコンテンツＣＴの配信を受けることで、結果として配信システム全体として稼働中のコンテンツホルダＣＨの数を減らし（換言すれば増加させないようにし）、当該全体としての消費電力及び騒音の低減を実現する。
【００６０】
なお、上記補助情報ＨＰに含まれる情報のうち、終了予測時刻情報１０１については、それを記憶しているルートノードＲＮにおいて、上記通知時刻情報１００により示される通知時刻に基づいてその通知対象となったコンテンツホルダＣＨからの配信開始時刻を予測し、更に当該配信対象たるコンテンツのデータ量からその配信所要時間を算出し、当該算出した配信所要時間を上記予測された配信開始時刻に加算することでその配信の終了予測時刻を算出して、対応する通知時刻情報１００と対にして記憶する。
【００６１】
また、以下の実施形態では、補助情報ＨＰが付加された本発明に係るインデックス情報を、インデックス情報ＥＸＸと称することとする。更に、図３では、一つのルートノードＲＮに複数のコンテンツに対応するインデックス情報ＥＸＸが記録されており、更に一つのコンテンツにつき、同一のコンテンツを記録する複数のコンテンツホルダＣＨを示すインデックス情報ＥＸＸが記録されている状態を例示している。
【００６２】
更にまた、当該インデックス情報ＥＸＸは、図３に示すルートノードＲＮだけでなく、上述したキャッシュノードＣＮにも同様のものが記録されており、これを参照することで、リクエスタＲＱからの配信元問い合わせメッセージＱrをルートノードＲＮまで到達させずとも、当該配信元問い合わせメッセージＱrに補助情報ＨＰを参照して対応する返信情報ＲＴを当該リクエスタＲＱまで返信することができる。
【００６３】
このように、本発明による補助情報ＨＰを含むインデックス情報ＥＸＸをルートノードＲＮ及びキャッシュノードＣＮが夫々記録しておくことで、（他のリクエスタＲＱに対して）最新に配信を開始しているコンテンツホルダＣＨから並列して所望のコンテンツの配信を受け、これにより配信システム全体としての消費電力及び騒音の低減が実現できるのである。
【００６４】
（II）実施形態
次に、上述した原理に則った本発明に係る実施形態について、具体的に図４乃至図７を用いて説明する。
【００６５】
初めに、実施形態に係るノードの概要構成について図４を用いて説明する。なお、図４は実施形態に係るノードの概要構成を示すブロック図である。また、本実施形態においては、上記コンテンツホルダＣＨ、リクエスタＲＱ、ルートノードＲＮ、キャッシュノードＣＮ及びその他のノードＮは、基本的に全て同一のハードウエア構成を有するものであるので、それらを代表して一般のノードＮの構成について、図４を用いてその概要を説明する。
【００６６】
図４に示すように、実施形態に係る配信システムに含まれているノードＮは、演算機能を有するＣＰＵ、作業用ＲＡＭ（Random Access Memory）、各種データ及びプログラムを記録するＲＯＭ（Read Only Memory）等から構成された制御部１１と、上記コンテンツ自体としてのコンテンツデータ、上記インデックス情報ＥＸＸ、上記ＤＨＴ及びその他の必要なプログラム等を記録保存（格納）するためのＨＤＤ等から構成された記録部１２（上記コンテンツデータは、その配信前はコンテンツホルダＣＨとしてのノードＮ内の記録部１２内にのみ記録されている）と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコード（符号化）されたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ（Cathode Ray  Tube）又は液晶ディスプレイ等よりなる表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ／Ａ（Digital/Analog）変換した後これを増幅器等により増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行なうための通信部２０と、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する入力部（例えば、キーボード、マウス或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記録部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【００６７】
そして、制御部１１におけるＣＰＵが記録部１２等に記録された各種プログラムを実行することにより、当該制御部１１が、リクエスタＲＱ、キャッシュノードＣＮ、ルートノードＲＮ、コンテンツホルダＣＨ又はそれら以外の一般のノードＮとしての全体動作を統括制御する。
【００６８】
なお、上記ノードＮが本発明に係る情報処理装置としてのルートノードＲＮ又はキャッシュノードＣＮである場合は、制御部１１が本発明に係る検索手段として機能し、記録部１２が本発明に係る記憶手段として機能し、通信部２０が受信手段及び送信手段として機能する。
【００６９】
次に、ルートノードＲＮ及びキャッシュノードＣＮ並びにリクエスタＲＱに分けて、実施形態に係る各ノードＮの動作について説明する。
【００７０】
（Ａ）ルートノード及びキャッシュノードにおける動作
初めに、実施形態に係るルートノードＲＮ及びキャッシュノードＣＮにおける動作について、図６を用いて説明する。なお、図６（ａ）は実施形態に係るルートノードＲＮ及びキャッシュノードＣＮにおけるメッセージ受信時の動作を示すフローチャートであり、図６（ｂ）は当該ルートノードＲＮとしての細部動作を示すフローチャートであり、図６（ｃ）は当該キャッシュノードＣＨとしての細部動作を示すフローチャートである。
【００７１】
図６に示すように、既に本発明に係るいずれかのインデックス情報ＥＸＸが蓄積されているルートノードＲＮ及びキャッシュノードＣＮにおいては、先ず、配信システム内のいずれかのノードＮから配信元問い合わせメッセージＱrを受け取ると、自らがルートノードＲＮ又はキャッシュノードＣＮのいずれであるかを確認し（ステップＳ１）、ルートノードＲＮである場合には（ステップＳ１；ルートノード）、当該ルートノードＲＮとしての図６（ｂ）に示す処理を実行する（ステップＳ１０）。
【００７２】
一方、ステップＳ１の確認において、自身がキャッシュノードＣＨである場合には（ステップＳ１；キャッシュノード）、当該キャッシュノードＣＨとしての図６（ｃ）に示す処理を実行する（ステップＳ２０）。
【００７３】
次に、上記ステップＳ１０に係るルートノードＲＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図６（ｂ）を用いて説明する。
【００７４】
上述したインデックス情報ＥＸＸを記録するルートノードＲＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、図６（ｂ）に示すように、先ず、当該配信元問い合わせメッセージＱrから、それを送信したリクエスタＲＱにおいて所望されているコンテンツを示すインデックス情報ＥＸＸを示す情報を抽出し、更に当該抽出した情報により示されているインデックス情報ＥＸＸを記憶部１２内において一又は複数個検索・抽出する（ステップＳ１１）。
【００７５】
次に、当該抽出されたインデックス情報ＥＸＸから上記通知時刻情報１００及び終了予測時刻情報１０１を抽出し（ステップＳ１２）、更に現在時刻が当該抽出された終了予測時刻情報１０１により示される終了予測時刻のいずれかより前であるか否かを確認する（ステップＳ１３）。
【００７６】
そして、現在時刻と比較して既に抽出された終了予測時刻情報１０１により示される終了予測時刻を全て過ぎているときは（ステップＳ１３；ＮＯ）、本実施形態に関する限り、いずれのインデックス情報ＥＸＸに対応するコンテンツホルダＣＨをリクエスタＲＱに返信してもよいこととなるため、上記ステップＳ１１の処理において抽出されたインデックス情報ＥＸＸの中から、例えば乱数的にいずれかのインデックス情報ＥＸＸを選択し、当該選択されたインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信する（ステップＳ１４）。
【００７７】
その後、当該ステップＳ１４の処理においてインデックス情報ＥＸＸを返信した時刻を上記通知時刻として当該インデックス情報ＥＸＸ内の通知時刻情報１００を更新する（ステップＳ１５）。
【００７８】
次に、当該更新した通知時刻に基づいてその通知対象となったコンテンツホルダＣＨからのリクエスタＲＱへの配信開始時刻を予測し、更に当該配信対象たるコンテンツのデータ量からその配信所要時間を算出し、当該算出した配信所要時間を上記予測された配信開始時刻に加算することでその配信の終了予測時刻を算出して、対応する終了予測時刻情報１０１を更新し（ステップＳ１６）、実施形態に係るルートノードＲＮとしての処理を終了して上記ステップＳ２に移行する。
【００７９】
一方、上記ステップＳ１３の判定において、現在時刻が終了予測時刻情報１０１により示される終了予測時刻前であるいずれかのインデックス情報ＥＸＸがあるときは（ステップＳ１３；ＹＥＳ）、そのインデックス情報ＥＸＸのうち通知時刻情報１００により示される通知時刻が最も遅い（換言すれば、対応するコンテンツの配信開始が最も遅い）インデックス情報ＥＸＸを検索し（ステップＳ１７）、その検索したインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信して（ステップＳ１８）、上記ステップＳ１５以降の処理に移行する。
【００８０】
次に、上記ステップＳ２０に係るキャッシュノードＣＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図６（ｃ）を用いて説明する。
【００８１】
上述したインデックス情報ＥＸＸを記録するキャッシュノードＣＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、図６（ｃ）に示すように、先ず、上記ステップＳ１１の処理と同様に、当該配信元問い合わせメッセージＱrに基づいてインデックス情報ＥＸＸを記憶部１２内において一又は複数個検索・抽出する（ステップＳ２１）。
【００８２】
次に、当該抽出されたインデックス情報ＥＸＸから上記通知時刻情報１００及び終了予測時刻情報１０１を抽出し（ステップＳ２２）、更に現在時刻が当該抽出された終了予測時刻情報１０１により示される終了予測時刻のいずれかより前であるか否かを確認する（ステップＳ２３）。
【００８３】
そして、現在時刻が終了予測時刻情報１０１により示される終了予測時刻前であるいずれかのインデックス情報ＥＸＸがあるときは（ステップＳ２３；ＹＥＳ）、そのインデックス情報ＥＸＸのうち通知時刻情報１００により示される通知時刻が最も遅いインデックス情報ＥＸＸを検索し（ステップＳ２４）、その検索したインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信する（ステップＳ２５）。
【００８４】
その後、当該ステップＳ２５の処理においてインデックス情報ＥＸＸを返信した時刻を上記通知時刻として当該インデックス情報ＥＸＸ内の通知時刻情報１００を更新する（ステップＳ２６）。
【００８５】
次に、上記ステップＳ１６の処理と同様にして、対応する終了予測時刻情報１０１を更新し（ステップＳ２７）、実施形態に係るキャッシュノードＣＮとしての処理を終了して上記ステップＳ３に移行する。
【００８６】
一方、上記ステップＳ２３の判定において、現在時刻と比較して既に抽出された終了予測時刻情報１０１により示される終了予測時刻を全て過ぎているときは（ステップＳ２３；ＮＯ）、本実施形態に関する限り、キャッシュノードＣＮが記憶しているいずれのインデックス情報ＥＸＸを返信しても無駄であるため、上記受信した配信元問い合わせメッセージＱrをＤＨＴに基づいて転送し（ステップＳ２８）、上記ステップＳ３の処理に移行する。
【００８７】
（Ｂ）リクエスタにおける動作
最後に、実施形態に係るリクエスタＲＱにおける動作について、図７を用いて説明する。なお、図７は実施形態に係るリクエスタＲＱにおける動作を示すフローチャートである。
【００８８】
図７に示すように、実施形態に係るリクエスタＲＱにおいては、先ず、使用者による所望のコンテンツの配信を要求する旨の操作が当該リクエスタＲＱ内の入力部２１において実行されると（ステップＳ３１）、当該リクエスタＲＱにおける制御部１１において当該配信要求されたコンテンツを示すコンテンツＩＤを算出する（ステップＳ３２）。そして、当該算出されたコンテンツＩＤを含む配信元問い合わせメッセージＱrを生成し、実施形態に係る配信システム内のネットワークにおけるスパニングツリー上でルートノードＲＮに向けて送信し（ステップＳ３３）、その送信結果としての所望するインデックス情報ＥＸＸの返信を待つ（ステップＳ３４）。
【００８９】
そして、送信した（ステップＳ３３）配信元問い合わせメッセージＱrに対応するインデックス情報ＥＸＸが受信できた場合は、その受信したインデックス情報ＥＸＸにより示されるコンテンツホルダＣＨに接続して（ステップＳ３５）所望するコンテンツの配信を受け（ステップＳ３６）、実施形態に係るリクエスタＲＱとしての処理を完了する。
【００９０】
以上夫々説明したように、実施形態に係るノードＮとしてのルートノードＲＮ、キャッシュノードＣＮ及びリクエスタＲＱの動作によれば、リクエスタＲＱに対して配信元問い合わせメッセージＱrに対応するインデックス情報ＥＸＸを送信するに当たり、配信が要求されているコンテンツを蓄積するコンテンツホルダＣＨを示すインデックス情報ＥＸＸのうち、通知時刻情報１００により示される通知時刻が新しいものを送信するので、現在配信中のコンテンツホルダＣＨから同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００９１】
従って、コンテンツ配信システム全体としての消費電力及び騒音夫々を低下させることが可能となる。
【００９２】
また、補助情報ＨＰが終了予測時刻情報１０１を含んでおり、当該終了予測時刻が現在時刻よりも後のインデックス情報ＥＸＸのみリクエスタＲＱに送信するので、確実に、配信を実行中のコンテンツホルダＣＨから更に新たな配信を受けることができる。
【００９３】
更に、通知時刻が最も新しいインデックス情報ＥＸＸのみリクエスタＲＱに送信するので、処理を簡略化しつつ配信を実行中のコンテンツホルダＣＨから更に新たな配信を受けることができる。
【００９４】
更にまた、要求したコンテンツを配信中のコンテンツホルダＣＨがない場合でも、いずれかのコンテンツホルダＣＨから必要なコンテンツの配信を受けることができる。
【００９５】
また、上述した図６及び図７に示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係る制御部１１として機能させることも可能である。
【産業上の利用可能性】
【００９６】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【００９７】
【図１】実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である
【図２】実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】本発明の原理を示す図（Ｉ）である。
【図４】本発明の原理を示す図（II）である。
【図５】実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図６】実施形態に係るルートノード及びキャッシュノードにおける動作をしめるフローチャートであり、（ａ）は配信元問い合わせメッセージ受信時の動作を示すフローチャートであり、（ｂ）はルートノードとしての動作の細部を示すフローチャートであり、（ｃ）はキャッシュノードとしての動作の細部を示すフローチャートである。
【図７】実施形態に係るリクエスタにおける動作を示すフローチャートである。
【符号の説明】
【００９８】
１１    制御部
１２    記録部
１３    バッファメモリ
１４    デコーダ部
１５    映像処理部
１６    表示部
１７    音声処理部
１８    スピーカ
２０    通信部
２１    入力部
２２    バス
１００    通知時刻情報
１０１    終了予測時刻情報
Ｒc、Ｒn    リング
ＥＸ、ＥＸＸ    インデックス情報
ＣＨ    コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３    リクエスタ
ＣＴ    コンテンツ
ＲＮ    ルートノード
ＣＮ    キャッシュノード
Ｑp    登録メッセージ
Ｑr    配信元問い合わせメッセージ
Ｎ    ノード
ＨＰ    補助情報
ＲＴ    返信情報
【図１】
2008293145.tif 000003
【図２】
2008293145.tif 000004
【図３】
2008293145.tif 000005
【図４】
2008293145.tif 000006
【図５】
2008293145.tif 000007
【図６】
2008293145.tif 000008
【図７】
2008293145.tif 000009