メタデータ検索方法、利用者端末、およびメタデータ検索プログラム
【課題】 Ｐ２Ｐ環境において、ネットワーク内の全てのメタデータの中から必要なデータを高速に検索する。
【解決手段】 各メタデータはＸＭＬの１個以上の要素に分割され、識別子と合わせてメタデータＤＢ１４１にて管理される。メタデータの要素毎に期待値が設定され、これに端末資源値と掛け合わせ、重み値が生成される。重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータルーティングテーブル１２３を生成する。該テーブルに従って優先度の高い利用者端末にメタデータをコピーし、検索クリエを転送する。キャッシュデータ配置または検索キーの転送先を決定する。
【解決手段】 各メタデータはＸＭＬの１個以上の要素に分割され、識別子と合わせてメタデータＤＢ１４１にて管理される。メタデータの要素毎に期待値が設定され、これに端末資源値と掛け合わせ、重み値が生成される。重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータルーティングテーブル１２３を生成する。該テーブルに従って優先度の高い利用者端末にメタデータをコピーし、検索クリエを転送する。キャッシュデータ配置または検索キーの転送先を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）環境においてメタデータを検索する方法に関する。
【背景技術】
【０００２】
従来の検索に関する技術には以下のようなものがある。
・インターネット上の検索システムとして、メタデータやコンテンツそのものを特定の端末（または専用のクラスタ）に集中的に保管してインデクシングを管理する、非特許文献１に代表されるようなディレクトリ型検索システムや非特許文献２や非特許文献３に代表されるような全文検索型システムなどがある。
・Ｐ２Ｐネットワークにおける代表的な検索手法としては、非特許文献５や非特許文献４（Ｃｏｎｔｅｎｔ−Ａｄｄｒｅｓｓａｂｌｅ Ｎｅｔｗｏｒｋ）などの分散ハッシュテーブル（ＤＨＴ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）を用いた手法があり、Ｐ２Ｐネットワーク内で目的のメタデータ（検索対象）に完全一致するメタデータを高速に検索可能である。
・代表的なＰ２ＰツールであるＦｒｅｅｎｅｔでは、ネットワーク内の近隣のｐｅｅｒ(利用者端末)に対し、ファイル名とコンテンツ名のハッシュ値を用い発見の可能性の高いルートから優先的に検索パケットをルーティングするｄｅｐｔｈ−ｆｉｒｓｔ方式をとっており、検索キーの情報がクラスタ化されることで、より高速化・効率化されている。
・非特許文献６等に代表されるＰ２Ｐネットワークにおけるキャッシング方式では、上記のような集中的な保管ではなく、分散的なメタデータの保管が可能となる。検索に成功したメタデータやよく参照されるメタデータを検索に用いられた経路（利用者から第３者ｐｅｅｒを経由して目的のメタデータを持つｐｅｅｒまでの経路）等にキャッシュさせることで、何度も参照されるメタデータは各ｐｅｅｒのより近くに存在する（検索距離＝検索ホップ数を短くする）ことになり、その結果、高速な検索が可能となる。極端な例でいえば、全てのメタデータを全てのｐｅｅｒでキャッシュすれば、どのような検索を行っても、最も高速（検索距離が０）に検索することが可能であるが、当然全てのｐｅｅｒが膨大なキャッシュ用のディスクスペースを用意できなければならない。それを、例えば参照の多い（または一度参照された）メタデータだけをキャッシュすることで、検索の効率をあまり落とさずに、大幅にディスクスペースを削減できる。
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｙａｈｏｏ．ｃｏｍ／
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ．ｇｏｏ．ｎｅ．ｊｐ／
【非特許文献３】ｈｔｔｐ：／／ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ／
【非特許文献４】ＣＡＮ： ｈｔｔｐ：／／ｈｏｍｅｐａｇｅ３．ｎｉｆｔｙ．ｃｏｍ／ｔｏｒｅｍｏｒｏ／ｐ２ｐ／ｄｈｔ１．ｈｔｍｌ
【非特許文献５】Ｃｈｏｒｄ： ｈｔｔｐ：／／ｈｏｍｅｐａｇｅ３．ｎｉｆｔｙ．ｃｏｍ／ｔｏｒｅｍｏｒｏ／ｐ２ｐ／ｄｈｔ２．ｈｔｍｌ
【非特許文献６】ｈｔｔｐ：／／ｅ-ｗｏｒｄｓ．ｊｐ／ｗ／ｗｉｎｎｙ．ｈｔｍｌ
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記の従来の技術では以下のような問題がある。
・集中的に管理する方式は、ネットワーク上の全てのメタデータを管理するインデクシングサーバの維持管理に膨大なコストを必要とする。
・ＤＨＴに依存する方式は、検索キーのハッシュ値を元に対応するメタデータを保持するＰｅｅｒを絞り込み検索する方式であるため、検索キーと検索対象が完全一致する検索では高速な検索が可能であるが、検索キーが検索対象の部分集合である部分一致型の検索の実現は難しい。
・Ｆｒｅｅｎｅｔでは近隣のｐｅｅｒが保持するルーティングテーブルをメタデータ毎（ファイル名毎）に持つ必要があり、ネットワーク内のコンテンツが多種多様化するとルーティングテーブルがオーバーフローし非効率な検索となる問題や、検索要求が成功する毎にルーティングテーブルを追加するため、初期状態では非効率な検索となる。
・キャッシング方式は、一部の人気のあるコンテンツ・メタデータを、多数の利用者が参照することで効率性が上がるが、多くのメタデータが参照されるようになると、ディスクスペースを節減するために、古いメタデータを廃棄するタイミングが早くなり、効率性が落ちる。また、目的のメタデータが初めて参照される場合ではまったく効果が無いため、コンテンツが多種多様化すると効果が薄くなる。
【０００４】
本発明の目的は、上記従来のメタデータ検索技術の問題を解決し、Ｐ２Ｐ環境において、検索キーと検索対象の部分一致可能で、かつ必要な検索にトラフィックを大幅に削減し、かつ高速化のためのキャッシュのために必要なディスクスペースを大幅に押さえて、ネットワーク内の全てのメタデータの中から必要なメタデータを高速に検索するメタデータ検索方法、利用者端末を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のメタデータ検索方法は、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理するステップと、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成するステップと、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータのプッシュ型配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成するステップと、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーするステップと、
利用者端末から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送し、検索クリエが転送されてくると、自利用者端末内に目的のメタデータが存在するか調べるステップを
有する。
【０００６】
このメタデータ管理方法によって、多品種のメタデータが生成されても非常に少ない資源で管理できる。
【０００７】
このメタデータルーティングテーブル生成方法により、最大でも一つの利用者端末にメタデータの要素の数しかメタデータルーティングテーブルが作られないため、テーブルのオーバーフローなどの問題を防止できる。
【０００８】
分割されたメタデータをそのメタデータルーティングテーブルに従ってプッシュ的に近隣の各利用者端末に配置する。メタデータが転送されてきた利用者端末はそのメタデータをキャッシュメタデータＤＢで管理する。それを繰り返すことでネットワーク内における近隣の中で比較的重み値の高い利用者端末にその要素のメタデータが集まる。
【０００９】
検索要求時は、ある利用者の検索クエリ（メタデータ同様にＸＭＬ等の構造化された記述を行う）をそのメタデータルーティングテーブルに従ってルーティング（優先度による転送）を行うことで、その利用者が要求するメタデータを高速に発見することができる。まずはメタデータ要素によって検索クエリを転送していくことで、検索キーと検索対象が完全一致する必要がなく、大まかな範囲での絞込み検索を実現する。
【００１０】
これらにより、利用者は要求するメタデータの例えばファイル名などを完全に知らなくても、その一部分、または更新された日付や権利などのメタデータの一部を指定することで、要求するメタデータを高速に発見することができる。ネットワーク全体で見れば、少ない資源でこれを実現できる。
【発明の効果】
【００１１】
Ｐ２Ｐネットワーク上で、各利用者端末は近隣の利用者端末の情報だけで全ての処理を行うため、検索時に全ネットワークに対してフラッディングを行う必要がないにも関わらず、各利用者端末は最大でも要素の数のルーティングテーブルを持つだけで全ネットワークからの検索が可能となり、テーブル数の爆発がおきない。
【００１２】
メタデータはＸＭＬ要素毎に各利用者端末で管理されるため、メタデータをそのままキャッシュするよりも利用者端末の資源が抑えられる。
【００１３】
メタデータの要素によって範囲を絞ったルーティングが可能になるため、目的のメタデータを発見するために無駄な検索クエリを転送することがなく、不必要にネットワーク帯域を消費しない。同様の理由により、高速に目的のメタデータを発見できる。
【００１４】
これらの利点より、様々な端末（デジタルカメラや携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）やパソコンなど）が存在するＰ２Ｐネットワーク上で多種多様なコンテンツが流通するサービス、例えば個人が様々な媒体を使ってコンテンツ発信できるようなネットワーク上のサービスでの、タイトルや作成日時や二次利用の権利など利用形態に応じた高速な検索が可能となる。
【発明を実施するための最良の形態】
【００１５】
次に、本発明の実施の形態について図面を参照して説明する。
【００１６】
図１は本発明が適用されるＰ２Ｐネットワークの一例を示している。このＰ２Ｐネットワークは４つの利用者端末１〜４で構成されている。
【００１７】
図２は利用者端末１〜４の構成図である。利用者端末１〜４はアプリケーション１１とメタデータルーティングテーブル管理部１２と検索要求管理部１３とメタデータ管理部１４とＰ２Ｐネットワーク管理部１５で構成されている。メタデータルーティングテーブル管理部１２は期待値テーブル１２１と重み値テーブル１２２とメタデータルーティングテーブル１２３を含んでいる。検索要求管理部１３はクエリ転送部１３１とクエリ照合部１３２を含んでいる。メタデータ管理部１４はメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２を含んでいる。
【００１８】
アプリケーション１１は利用者に対するヒューマンインターフェース（検索画面や結果表示など）を提供する。Ｐ２Ｐネットワーク管理部１５は他の利用者端末と通信する機能を有している。メタデータ管理部１４は、コンテンツのメタデータを、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の構造化されたメタデータの要素単位で、メタデータを特定できる識別子を付けて分割して管理する。メタデータルーティングテーブル管理部１２は、メタデータの要素に対して利用者がどのくらいその要素を利用して検索等を行うかを表す期待値（期待値テーブル１２１に格納）、または、システムによって割り振られる値と、その利用者が利用する利用者端末の資源（利用可能なディスクスペースやＣＰＵ能力など）を表す端末資源値の積によって重み付けを行い、自利用端末の近隣の１つ以上の利用者端末の重みの値（重み値テーブル１２２に格納）によってメタデータのルーティングテーブル１２３を生成する。メタデータルーティングテーブル管理部１２はＰ２Ｐネットワーク管理部１５を介して、メタデータルーティングテーブル１２３に従って最も優先度の高い近隣の利用者端末にメタデータをコピーする。クエリ転送部１３１は、利用者から要求された検索クエリをメタデータルーティングテーブル１２３に従って近隣の利用者端末に転送する。クエリ照合部１３２は検索クエリが転送されてくると自利用者端末のメタデータＤＢ１４１内に目的のメタデータが存在するかを調べる。
【００１９】
［第１の実施形態］
［処理１］
利用者端末１のアプリケーション１１は、表１に示すようなメタデータを登録する。
【００２０】
【表１】
【００２１】
登録されたメタデータは、メタデータ管理部１４によって、図３に示すように、一つのメタデータ（通常は一つのコンテンツに対して一つのメタデータ）をＸＭＬの１個以上の要素毎に分割し、メタデータをネットワーク内で一意に識別することができる識別子と合わせて、メタデータ管理部１４のメタデータＤＢ１４１においてＸＭＬ形式で管理される。識別子は、例えばＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ：ｈｔｔｐ:／／ｗｗｗ．ａｔｍａｒｋｉｔ．ｃｏ．ｊｐ／ｉｃｄ／ｒｏｏｔ／５２／９４０８４０５２．ｈｔｍｌ）を用いることでＰ２Ｐネットワークの中で一意に決めることができる。
【００２２】
［処理２］
メタデータルーティング管理部１２は、表２に示すメタデータの要素毎に、利用者が設定した期待値を期待値テーブル１２１で管理する。
【００２３】
【表２】
【００２４】
期待値は、利用者の近い将来の一定時間における検索要求のうち、ある要素を対象に行う頻度等の予測である。例えば、利用者端末１では、表１に示すメタデータの要素のうち、日付で検索する頻度が高いため、表２に示すように利用者端末１では日付の期待値が０．６と、タイトル、作者の要素に比べて最も高くなっている。また、表２に示すように一つのコンテンツのメタデータでの期待値の合計は一定である。表３に示すように、メタデータルーティングテーブル管理部１２はメタデータ期待値に、利用者が設定したディスクスペース許可量、ＣＰＵ能力等の値を正規化した端末資源値と掛け合わせた値をメタデータ重み値とし、メタデータ重み値テーブル１２２で管理する。例えば、表３のように利用者端末１では端末資源値０．５であるため、タイトル要素の期待値０．２×０．５＝０．１をタイトル要素の重み値となる。
【００２５】
【表３】
【００２６】
［処理３］
図４〜図６にメタデータの配置方法とルーティングテーブル生成方法の例を示す。
【００２７】
まず、重み値の転送通知を全利用者端末で行う。Ｐ２Ｐネットワーク管理部１５は表３に示す利用者端末１で設定されたメタデータ要素の重み値を、図４に示す、利用者端末１が隣接する利用者端末である利用者端末２と利用者端末３に通知する。同様に、利用者端末２は隣接する利用者端末１と３と４に重み値を通知する。これを繰り返し、全ての利用者端末１〜４が自身と隣接する全ての利用者端末の重み値を知る。
【００２８】
［処理４］
次に、メタデータルーティングテーブル１２３を作成する。利用者端末１のメタデータルーティングテーブル管理部１２は隣接する利用者端末である利用者端末２と３の中で要素１である＜タイトル＞の重み値の最も高い利用者端末である利用者端末３を優先度最高とし、次に要素１の重み値の高い利用者端末２、その次に要素１の重み値の高い端末１の順番で優先度をつけ、図５に示すようにメタデータルーティングテーブル１２３を作成する。例えば図４では、利用者端末１の要素１の重み値は０．１で、隣接する利用者端末である利用者端末２の要素１の重み値は０．０６、利用者端末３の要素１の重み値は０．４８であり、３つの利用者端末１〜３の中で最も要素１の重み値が高いのは利用者端末３であるので、利用者端末１の要素１の最優先ルーティング先は利用者端末３となる。同様に、他の要素２や要素３についても優先度をつける。他の利用者端末についても同様の処理を行い、図５に示す全てのメタデータルーティングテーブル１２３が作成される。
【００２９】
［処理５］
次に、メタデータのプッシュ型の配置を行う。図６に示す利用者端末１のメタデータルーティングテーブル管理部１２はＰ２Ｐネットワーク管理部１５を介して、は図５に示すメタデータルーティングテーブル１２３における、要素１の優先度の最も高い利用者端末３に、利用者端末１の持つメタデータ＃１を全てコピーする（図６の矢印）。コピーされたメタデータ＃１は利用者端末３のキャッシュメタデータＤＢ１４２に蓄積される。同様に、利用者端末１で要素３のメタデータルーティングテーブル１２３の最優先である利用者端末３に、メタデータ＃３を全てコピーする。要素２のメタデータルーティングテーブル１２３の最優先端末は利用者端末１自身であるので、コピーしない。同様に、利用者端末３では要素１のメタデータルーティングテーブル１２３によりメタデータ１を利用者端末４にコピーし、要素２のメタデータルーティングテーブル１２３によりメタデータ＃２を利用者端末１にコピーする。また、利用者端末１からコピーされたメタデータ＃１、３についても、利用者端末３のメタデータルーティングテーブル１２３に従ってコピーを行う。全ての利用者端末１〜４で全ての要素について同様の処理を行うと、図６に示すように、自身がもともと持っていたメタデータはメタデータＤＢ１４１にそのまま残り、ネットワーク内の他の各利用者端末のメタデータは、要素毎にキャッシュメタデータＤＢ１４２に蓄積される。
【００３０】
［処理６］
図６において、利用者端末１のアプリケーション１１から、要素１である「タイトル」に含まれる「ｘｃｖ」文字列の検索を行う。検索クエリは図７に示すような形式で表せ、検索キーと検索要素の組み合わせである。まず、検索クエリを入力されたアプリケーション１１は、検索要求管理部１３に検索クエリを渡す。まず、利用者端末内のメタデータを検索するため、クエリ照合部１３２が検索要求管理部１３が受け取った検索クエリについて、メタデータ管理部１４に利用者端末内の検索を要求する。メタデータ管理部１４は利用者端末自身のメタデータＤＢ１４１およびキャッシュメタデータＤＢ１４２の中で、検索要素が「タイトル」で検索キーが「ｘｃｖ」であるメタデータを検索する。検索に適合した場合には検索を終了し、結果をアプリケーション１１に返す。検索に適合しなかった場合には、検索要求管理部１３に結果を返し、処理７に続く。ただし、複数個の検索結果を必要とする場合は、ここで検索が適合した場合でも、検索要求管理部１３に結果を返し、処理７に続く。ここでは、利用者端末１のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中に検索要素「タイトル」で検索キー「ｘｃｖ」のメタデータは存在しないため、検索要求管理部１３に結果を返し、処理７に続く。
【００３１】
［処理７］
次に、検索要求管理部１３はクエリ転送部１３１に対して、検索クエリを図５に示すメタデータルーティングテーブル１２３に従って転送するよう指示する。この場合では検索要素「タイトル」は要素１に該当するため、利用者端末１の要素１のメタデータルーティングテーブル１２３の最優先度である利用者端末３に対してクエリ転送部１３１から検索クエリを転送する。
【００３２】
［処理８］
検索クエリを受信した利用者端末３のクエリ照合部１３２は、処理６と同様に、自身のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中で検索要素「タイトル」で検索キー「ｘｃｖ」であるメタデータを検索する。検索に適合した場合には検索を終了し、結果をアプリケーション１１に返す。検索適合が失敗した場合には検索要求管理部１３に結果を返し、処理９に続く。ただし、複数個の検索結果を必要とする場合は、ここで検索適合が成功した場合でも、検索要求管理部１３に結果を返し、処理９に続く。ここでは、利用者端末３のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中に検索要素「タイトル」で検索検索「ｘｃｖ」のメタデータは存在しないため、検索要求管理部１３に結果を返し、処理９に続く。
【００３３】
［処理９］
次に、利用者端末３の検索要求管理部１３は処理７と同様に検索クエリを図５に示すメタデータルーティングテーブル１２３に従って転送するよう指示する。この場合では検索要素「タイトル」は要素１に該当するため、利用者端末３の要素１のメタデータルーティングテーブル１２３の最優先度である利用者端末４に対してクエリ転送部１３１から検索クエリを転送する。
【００３４】
［処理１０］
利用者端末３から検索クエリを受信した利用者端末４の検索要求管理部１３は、自身のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中で検索要素「タイトル」で検索キー「ｘｃｖ」であるメタデータをクエリ照合部１３２により照合し、該当メタデータを発見する。複数個の検索結果を必要とする場合は、ここで検索適合が成功した場合でも、上記の処理を繰り返し、最終的に検索クエリの転送先がなくなるまで、または指定する検索結果の個数のメタデータを発見するまで続ける。検索結果の個数を制限しない場合には、適合するメタデータを全て発見する。
【００３５】
［第２の実施形態］
第１の実施形態の場合よりも利用者端末数の多い、図８に示すＰ２Ｐネットワークにおける実施形態を示す。
【００３６】
第１の実施形態と同様にメタデータが生成され、重み値が決まる。図８では一つの要素についてのメタデータの存在とその重み値を示す。ここでは仮に全ての利用者端末が何らかのメタデータを持っているとしているが、その限りではない。第１の実施形態と同様にメタデータルーティングテーブルを作成する。ここでは、図８に示す矢印の方向に最優先のメタデータルーティングテーブルが作られる。端末２、６、７については、隣接する利用者端末の中で自身が最も重み値が高いため、最優先のルーティング先は自身となる。第１の実施形態と同様にメタデータルーティングテーブルに従ってメタデータをコピーし、図９のようになる。
【００３７】
図９に示す利用者端末１である検索クエリにより検索要求を行った場合、端末１のメタデータルーティングテーブル１２３に従い、自身のメタデータＤＢ１４１およびキャッシュメタデータＤＢ１４２を照合した後に利用者端末２に検索クエリを転送する。利用者端末２には多くの利用者端末からメタデータが集まっているため、検索に適合する確率が高い。仮に利用者端末２に適合するメタデータが無かったとしても、次に優先度の高い利用者端末４に検索クエリを転送し、利用者端末４では次点のルーティング先である端末７にクエリを転送し、より多くのメタデータが集まる利用者端末を優先的に検索可能である。その結果、検索クエリをネットワーク内に無駄に転送することなく、適合するメタデータを発見できる。
【００３８】
［第３の実施形態］
複数の検索クエリにおけるＡＮＤ検索およびＯＲ検索の場合の処理を示す。ここでは２個の検索クエリでＡＮＤ検索またはＯＲ検索を行う場合を示す。
【００３９】
メタデータの生成からメタデータルーティングテーブルを生成してメタデータをプッシュ的に配置するまでは第１の実施形態の処理１）〜５）と同様である。
【００４０】
次に、図１０に示すように、それぞれの検索クエリは独立に、第１の実施形態と同様の処理を行い、それぞれの検索キーに適合するメタデータを発見（ステップ１０１）した後、利用者端末１のキャッシュメタデータＤＢ１４２に保管する（ステップ１０３）。その後、ＡＮＤ検索の場合は、メタデータ管理部１４内において、共通する識別子を持つメタデータのみ選択（ステップ１０３）して表示する。ＯＲ検索の場合は、ステップ１０３を行わず、全てのメタデータが表示の対象となる。
【００４１】
なお、利用者端末の機能は専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間の間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。
【図面の簡単な説明】
【００４２】
【図１】本発明が適用されるＰ２Ｐネットワークの一例を示す図である。
【図２】利用者の端末の構成を示す図である。
【図３】要素毎のメタデータの一例を示す図である。
【図４】メタデータルーティングの一例（初期状態）を示す図である。
【図５】メタデータルーティングテーブルの一例（ルーティングテーブルの例）を示す図である。
【図６】メタデータルーティングの一例（メタデータのプッシュ型キャッシュ）を示す図である。
【図７】検索クエリの例を示す図である。
【図８】第２の実施形態のＰ２Ｐネットワークの例を示す図である。
【図９】第２の実施形態のＰ２Ｐネットワークのメタデータ移動後を示す図である。
【図１０】本発明の第３の実施形態で、ＡＮＤ検索およびＯＲ検索の一連の処理の例を示す図である。
【符号の説明】
【００４３】
１〜８ 利用者端末
１１ アプリケーション
１２ メタデータルーティングテーブル管理部
１２１ 期待値テーブル
１２２ 重み値テーブル
１２３ メタデータルーティングテーブル
１３ 検索要求管理部
１３１ クエリ転送部
１３２ クエリ照合部
１４ メタデータ管理部
１４１ メタデータＤＢ
１４２ キャッシュメタデータＤＢ
１５ Ｐ２Ｐネットワーク管理部
１０１〜１０３ ステップ
【技術分野】
【０００１】
本発明はＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）環境においてメタデータを検索する方法に関する。
【背景技術】
【０００２】
従来の検索に関する技術には以下のようなものがある。
・インターネット上の検索システムとして、メタデータやコンテンツそのものを特定の端末（または専用のクラスタ）に集中的に保管してインデクシングを管理する、非特許文献１に代表されるようなディレクトリ型検索システムや非特許文献２や非特許文献３に代表されるような全文検索型システムなどがある。
・Ｐ２Ｐネットワークにおける代表的な検索手法としては、非特許文献５や非特許文献４（Ｃｏｎｔｅｎｔ−Ａｄｄｒｅｓｓａｂｌｅ Ｎｅｔｗｏｒｋ）などの分散ハッシュテーブル（ＤＨＴ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）を用いた手法があり、Ｐ２Ｐネットワーク内で目的のメタデータ（検索対象）に完全一致するメタデータを高速に検索可能である。
・代表的なＰ２ＰツールであるＦｒｅｅｎｅｔでは、ネットワーク内の近隣のｐｅｅｒ(利用者端末)に対し、ファイル名とコンテンツ名のハッシュ値を用い発見の可能性の高いルートから優先的に検索パケットをルーティングするｄｅｐｔｈ−ｆｉｒｓｔ方式をとっており、検索キーの情報がクラスタ化されることで、より高速化・効率化されている。
・非特許文献６等に代表されるＰ２Ｐネットワークにおけるキャッシング方式では、上記のような集中的な保管ではなく、分散的なメタデータの保管が可能となる。検索に成功したメタデータやよく参照されるメタデータを検索に用いられた経路（利用者から第３者ｐｅｅｒを経由して目的のメタデータを持つｐｅｅｒまでの経路）等にキャッシュさせることで、何度も参照されるメタデータは各ｐｅｅｒのより近くに存在する（検索距離＝検索ホップ数を短くする）ことになり、その結果、高速な検索が可能となる。極端な例でいえば、全てのメタデータを全てのｐｅｅｒでキャッシュすれば、どのような検索を行っても、最も高速（検索距離が０）に検索することが可能であるが、当然全てのｐｅｅｒが膨大なキャッシュ用のディスクスペースを用意できなければならない。それを、例えば参照の多い（または一度参照された）メタデータだけをキャッシュすることで、検索の効率をあまり落とさずに、大幅にディスクスペースを削減できる。
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｙａｈｏｏ．ｃｏｍ／
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ．ｇｏｏ．ｎｅ．ｊｐ／
【非特許文献３】ｈｔｔｐ：／／ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ／
【非特許文献４】ＣＡＮ： ｈｔｔｐ：／／ｈｏｍｅｐａｇｅ３．ｎｉｆｔｙ．ｃｏｍ／ｔｏｒｅｍｏｒｏ／ｐ２ｐ／ｄｈｔ１．ｈｔｍｌ
【非特許文献５】Ｃｈｏｒｄ： ｈｔｔｐ：／／ｈｏｍｅｐａｇｅ３．ｎｉｆｔｙ．ｃｏｍ／ｔｏｒｅｍｏｒｏ／ｐ２ｐ／ｄｈｔ２．ｈｔｍｌ
【非特許文献６】ｈｔｔｐ：／／ｅ-ｗｏｒｄｓ．ｊｐ／ｗ／ｗｉｎｎｙ．ｈｔｍｌ
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記の従来の技術では以下のような問題がある。
・集中的に管理する方式は、ネットワーク上の全てのメタデータを管理するインデクシングサーバの維持管理に膨大なコストを必要とする。
・ＤＨＴに依存する方式は、検索キーのハッシュ値を元に対応するメタデータを保持するＰｅｅｒを絞り込み検索する方式であるため、検索キーと検索対象が完全一致する検索では高速な検索が可能であるが、検索キーが検索対象の部分集合である部分一致型の検索の実現は難しい。
・Ｆｒｅｅｎｅｔでは近隣のｐｅｅｒが保持するルーティングテーブルをメタデータ毎（ファイル名毎）に持つ必要があり、ネットワーク内のコンテンツが多種多様化するとルーティングテーブルがオーバーフローし非効率な検索となる問題や、検索要求が成功する毎にルーティングテーブルを追加するため、初期状態では非効率な検索となる。
・キャッシング方式は、一部の人気のあるコンテンツ・メタデータを、多数の利用者が参照することで効率性が上がるが、多くのメタデータが参照されるようになると、ディスクスペースを節減するために、古いメタデータを廃棄するタイミングが早くなり、効率性が落ちる。また、目的のメタデータが初めて参照される場合ではまったく効果が無いため、コンテンツが多種多様化すると効果が薄くなる。
【０００４】
本発明の目的は、上記従来のメタデータ検索技術の問題を解決し、Ｐ２Ｐ環境において、検索キーと検索対象の部分一致可能で、かつ必要な検索にトラフィックを大幅に削減し、かつ高速化のためのキャッシュのために必要なディスクスペースを大幅に押さえて、ネットワーク内の全てのメタデータの中から必要なメタデータを高速に検索するメタデータ検索方法、利用者端末を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のメタデータ検索方法は、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理するステップと、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成するステップと、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータのプッシュ型配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成するステップと、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーするステップと、
利用者端末から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送し、検索クリエが転送されてくると、自利用者端末内に目的のメタデータが存在するか調べるステップを
有する。
【０００６】
このメタデータ管理方法によって、多品種のメタデータが生成されても非常に少ない資源で管理できる。
【０００７】
このメタデータルーティングテーブル生成方法により、最大でも一つの利用者端末にメタデータの要素の数しかメタデータルーティングテーブルが作られないため、テーブルのオーバーフローなどの問題を防止できる。
【０００８】
分割されたメタデータをそのメタデータルーティングテーブルに従ってプッシュ的に近隣の各利用者端末に配置する。メタデータが転送されてきた利用者端末はそのメタデータをキャッシュメタデータＤＢで管理する。それを繰り返すことでネットワーク内における近隣の中で比較的重み値の高い利用者端末にその要素のメタデータが集まる。
【０００９】
検索要求時は、ある利用者の検索クエリ（メタデータ同様にＸＭＬ等の構造化された記述を行う）をそのメタデータルーティングテーブルに従ってルーティング（優先度による転送）を行うことで、その利用者が要求するメタデータを高速に発見することができる。まずはメタデータ要素によって検索クエリを転送していくことで、検索キーと検索対象が完全一致する必要がなく、大まかな範囲での絞込み検索を実現する。
【００１０】
これらにより、利用者は要求するメタデータの例えばファイル名などを完全に知らなくても、その一部分、または更新された日付や権利などのメタデータの一部を指定することで、要求するメタデータを高速に発見することができる。ネットワーク全体で見れば、少ない資源でこれを実現できる。
【発明の効果】
【００１１】
Ｐ２Ｐネットワーク上で、各利用者端末は近隣の利用者端末の情報だけで全ての処理を行うため、検索時に全ネットワークに対してフラッディングを行う必要がないにも関わらず、各利用者端末は最大でも要素の数のルーティングテーブルを持つだけで全ネットワークからの検索が可能となり、テーブル数の爆発がおきない。
【００１２】
メタデータはＸＭＬ要素毎に各利用者端末で管理されるため、メタデータをそのままキャッシュするよりも利用者端末の資源が抑えられる。
【００１３】
メタデータの要素によって範囲を絞ったルーティングが可能になるため、目的のメタデータを発見するために無駄な検索クエリを転送することがなく、不必要にネットワーク帯域を消費しない。同様の理由により、高速に目的のメタデータを発見できる。
【００１４】
これらの利点より、様々な端末（デジタルカメラや携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）やパソコンなど）が存在するＰ２Ｐネットワーク上で多種多様なコンテンツが流通するサービス、例えば個人が様々な媒体を使ってコンテンツ発信できるようなネットワーク上のサービスでの、タイトルや作成日時や二次利用の権利など利用形態に応じた高速な検索が可能となる。
【発明を実施するための最良の形態】
【００１５】
次に、本発明の実施の形態について図面を参照して説明する。
【００１６】
図１は本発明が適用されるＰ２Ｐネットワークの一例を示している。このＰ２Ｐネットワークは４つの利用者端末１〜４で構成されている。
【００１７】
図２は利用者端末１〜４の構成図である。利用者端末１〜４はアプリケーション１１とメタデータルーティングテーブル管理部１２と検索要求管理部１３とメタデータ管理部１４とＰ２Ｐネットワーク管理部１５で構成されている。メタデータルーティングテーブル管理部１２は期待値テーブル１２１と重み値テーブル１２２とメタデータルーティングテーブル１２３を含んでいる。検索要求管理部１３はクエリ転送部１３１とクエリ照合部１３２を含んでいる。メタデータ管理部１４はメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２を含んでいる。
【００１８】
アプリケーション１１は利用者に対するヒューマンインターフェース（検索画面や結果表示など）を提供する。Ｐ２Ｐネットワーク管理部１５は他の利用者端末と通信する機能を有している。メタデータ管理部１４は、コンテンツのメタデータを、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の構造化されたメタデータの要素単位で、メタデータを特定できる識別子を付けて分割して管理する。メタデータルーティングテーブル管理部１２は、メタデータの要素に対して利用者がどのくらいその要素を利用して検索等を行うかを表す期待値（期待値テーブル１２１に格納）、または、システムによって割り振られる値と、その利用者が利用する利用者端末の資源（利用可能なディスクスペースやＣＰＵ能力など）を表す端末資源値の積によって重み付けを行い、自利用端末の近隣の１つ以上の利用者端末の重みの値（重み値テーブル１２２に格納）によってメタデータのルーティングテーブル１２３を生成する。メタデータルーティングテーブル管理部１２はＰ２Ｐネットワーク管理部１５を介して、メタデータルーティングテーブル１２３に従って最も優先度の高い近隣の利用者端末にメタデータをコピーする。クエリ転送部１３１は、利用者から要求された検索クエリをメタデータルーティングテーブル１２３に従って近隣の利用者端末に転送する。クエリ照合部１３２は検索クエリが転送されてくると自利用者端末のメタデータＤＢ１４１内に目的のメタデータが存在するかを調べる。
【００１９】
［第１の実施形態］
［処理１］
利用者端末１のアプリケーション１１は、表１に示すようなメタデータを登録する。
【００２０】
【表１】
【００２１】
登録されたメタデータは、メタデータ管理部１４によって、図３に示すように、一つのメタデータ（通常は一つのコンテンツに対して一つのメタデータ）をＸＭＬの１個以上の要素毎に分割し、メタデータをネットワーク内で一意に識別することができる識別子と合わせて、メタデータ管理部１４のメタデータＤＢ１４１においてＸＭＬ形式で管理される。識別子は、例えばＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ：ｈｔｔｐ:／／ｗｗｗ．ａｔｍａｒｋｉｔ．ｃｏ．ｊｐ／ｉｃｄ／ｒｏｏｔ／５２／９４０８４０５２．ｈｔｍｌ）を用いることでＰ２Ｐネットワークの中で一意に決めることができる。
【００２２】
［処理２］
メタデータルーティング管理部１２は、表２に示すメタデータの要素毎に、利用者が設定した期待値を期待値テーブル１２１で管理する。
【００２３】
【表２】
【００２４】
期待値は、利用者の近い将来の一定時間における検索要求のうち、ある要素を対象に行う頻度等の予測である。例えば、利用者端末１では、表１に示すメタデータの要素のうち、日付で検索する頻度が高いため、表２に示すように利用者端末１では日付の期待値が０．６と、タイトル、作者の要素に比べて最も高くなっている。また、表２に示すように一つのコンテンツのメタデータでの期待値の合計は一定である。表３に示すように、メタデータルーティングテーブル管理部１２はメタデータ期待値に、利用者が設定したディスクスペース許可量、ＣＰＵ能力等の値を正規化した端末資源値と掛け合わせた値をメタデータ重み値とし、メタデータ重み値テーブル１２２で管理する。例えば、表３のように利用者端末１では端末資源値０．５であるため、タイトル要素の期待値０．２×０．５＝０．１をタイトル要素の重み値となる。
【００２５】
【表３】
【００２６】
［処理３］
図４〜図６にメタデータの配置方法とルーティングテーブル生成方法の例を示す。
【００２７】
まず、重み値の転送通知を全利用者端末で行う。Ｐ２Ｐネットワーク管理部１５は表３に示す利用者端末１で設定されたメタデータ要素の重み値を、図４に示す、利用者端末１が隣接する利用者端末である利用者端末２と利用者端末３に通知する。同様に、利用者端末２は隣接する利用者端末１と３と４に重み値を通知する。これを繰り返し、全ての利用者端末１〜４が自身と隣接する全ての利用者端末の重み値を知る。
【００２８】
［処理４］
次に、メタデータルーティングテーブル１２３を作成する。利用者端末１のメタデータルーティングテーブル管理部１２は隣接する利用者端末である利用者端末２と３の中で要素１である＜タイトル＞の重み値の最も高い利用者端末である利用者端末３を優先度最高とし、次に要素１の重み値の高い利用者端末２、その次に要素１の重み値の高い端末１の順番で優先度をつけ、図５に示すようにメタデータルーティングテーブル１２３を作成する。例えば図４では、利用者端末１の要素１の重み値は０．１で、隣接する利用者端末である利用者端末２の要素１の重み値は０．０６、利用者端末３の要素１の重み値は０．４８であり、３つの利用者端末１〜３の中で最も要素１の重み値が高いのは利用者端末３であるので、利用者端末１の要素１の最優先ルーティング先は利用者端末３となる。同様に、他の要素２や要素３についても優先度をつける。他の利用者端末についても同様の処理を行い、図５に示す全てのメタデータルーティングテーブル１２３が作成される。
【００２９】
［処理５］
次に、メタデータのプッシュ型の配置を行う。図６に示す利用者端末１のメタデータルーティングテーブル管理部１２はＰ２Ｐネットワーク管理部１５を介して、は図５に示すメタデータルーティングテーブル１２３における、要素１の優先度の最も高い利用者端末３に、利用者端末１の持つメタデータ＃１を全てコピーする（図６の矢印）。コピーされたメタデータ＃１は利用者端末３のキャッシュメタデータＤＢ１４２に蓄積される。同様に、利用者端末１で要素３のメタデータルーティングテーブル１２３の最優先である利用者端末３に、メタデータ＃３を全てコピーする。要素２のメタデータルーティングテーブル１２３の最優先端末は利用者端末１自身であるので、コピーしない。同様に、利用者端末３では要素１のメタデータルーティングテーブル１２３によりメタデータ１を利用者端末４にコピーし、要素２のメタデータルーティングテーブル１２３によりメタデータ＃２を利用者端末１にコピーする。また、利用者端末１からコピーされたメタデータ＃１、３についても、利用者端末３のメタデータルーティングテーブル１２３に従ってコピーを行う。全ての利用者端末１〜４で全ての要素について同様の処理を行うと、図６に示すように、自身がもともと持っていたメタデータはメタデータＤＢ１４１にそのまま残り、ネットワーク内の他の各利用者端末のメタデータは、要素毎にキャッシュメタデータＤＢ１４２に蓄積される。
【００３０】
［処理６］
図６において、利用者端末１のアプリケーション１１から、要素１である「タイトル」に含まれる「ｘｃｖ」文字列の検索を行う。検索クエリは図７に示すような形式で表せ、検索キーと検索要素の組み合わせである。まず、検索クエリを入力されたアプリケーション１１は、検索要求管理部１３に検索クエリを渡す。まず、利用者端末内のメタデータを検索するため、クエリ照合部１３２が検索要求管理部１３が受け取った検索クエリについて、メタデータ管理部１４に利用者端末内の検索を要求する。メタデータ管理部１４は利用者端末自身のメタデータＤＢ１４１およびキャッシュメタデータＤＢ１４２の中で、検索要素が「タイトル」で検索キーが「ｘｃｖ」であるメタデータを検索する。検索に適合した場合には検索を終了し、結果をアプリケーション１１に返す。検索に適合しなかった場合には、検索要求管理部１３に結果を返し、処理７に続く。ただし、複数個の検索結果を必要とする場合は、ここで検索が適合した場合でも、検索要求管理部１３に結果を返し、処理７に続く。ここでは、利用者端末１のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中に検索要素「タイトル」で検索キー「ｘｃｖ」のメタデータは存在しないため、検索要求管理部１３に結果を返し、処理７に続く。
【００３１】
［処理７］
次に、検索要求管理部１３はクエリ転送部１３１に対して、検索クエリを図５に示すメタデータルーティングテーブル１２３に従って転送するよう指示する。この場合では検索要素「タイトル」は要素１に該当するため、利用者端末１の要素１のメタデータルーティングテーブル１２３の最優先度である利用者端末３に対してクエリ転送部１３１から検索クエリを転送する。
【００３２】
［処理８］
検索クエリを受信した利用者端末３のクエリ照合部１３２は、処理６と同様に、自身のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中で検索要素「タイトル」で検索キー「ｘｃｖ」であるメタデータを検索する。検索に適合した場合には検索を終了し、結果をアプリケーション１１に返す。検索適合が失敗した場合には検索要求管理部１３に結果を返し、処理９に続く。ただし、複数個の検索結果を必要とする場合は、ここで検索適合が成功した場合でも、検索要求管理部１３に結果を返し、処理９に続く。ここでは、利用者端末３のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中に検索要素「タイトル」で検索検索「ｘｃｖ」のメタデータは存在しないため、検索要求管理部１３に結果を返し、処理９に続く。
【００３３】
［処理９］
次に、利用者端末３の検索要求管理部１３は処理７と同様に検索クエリを図５に示すメタデータルーティングテーブル１２３に従って転送するよう指示する。この場合では検索要素「タイトル」は要素１に該当するため、利用者端末３の要素１のメタデータルーティングテーブル１２３の最優先度である利用者端末４に対してクエリ転送部１３１から検索クエリを転送する。
【００３４】
［処理１０］
利用者端末３から検索クエリを受信した利用者端末４の検索要求管理部１３は、自身のメタデータＤＢ１４１とキャッシュメタデータＤＢ１４２の中で検索要素「タイトル」で検索キー「ｘｃｖ」であるメタデータをクエリ照合部１３２により照合し、該当メタデータを発見する。複数個の検索結果を必要とする場合は、ここで検索適合が成功した場合でも、上記の処理を繰り返し、最終的に検索クエリの転送先がなくなるまで、または指定する検索結果の個数のメタデータを発見するまで続ける。検索結果の個数を制限しない場合には、適合するメタデータを全て発見する。
【００３５】
［第２の実施形態］
第１の実施形態の場合よりも利用者端末数の多い、図８に示すＰ２Ｐネットワークにおける実施形態を示す。
【００３６】
第１の実施形態と同様にメタデータが生成され、重み値が決まる。図８では一つの要素についてのメタデータの存在とその重み値を示す。ここでは仮に全ての利用者端末が何らかのメタデータを持っているとしているが、その限りではない。第１の実施形態と同様にメタデータルーティングテーブルを作成する。ここでは、図８に示す矢印の方向に最優先のメタデータルーティングテーブルが作られる。端末２、６、７については、隣接する利用者端末の中で自身が最も重み値が高いため、最優先のルーティング先は自身となる。第１の実施形態と同様にメタデータルーティングテーブルに従ってメタデータをコピーし、図９のようになる。
【００３７】
図９に示す利用者端末１である検索クエリにより検索要求を行った場合、端末１のメタデータルーティングテーブル１２３に従い、自身のメタデータＤＢ１４１およびキャッシュメタデータＤＢ１４２を照合した後に利用者端末２に検索クエリを転送する。利用者端末２には多くの利用者端末からメタデータが集まっているため、検索に適合する確率が高い。仮に利用者端末２に適合するメタデータが無かったとしても、次に優先度の高い利用者端末４に検索クエリを転送し、利用者端末４では次点のルーティング先である端末７にクエリを転送し、より多くのメタデータが集まる利用者端末を優先的に検索可能である。その結果、検索クエリをネットワーク内に無駄に転送することなく、適合するメタデータを発見できる。
【００３８】
［第３の実施形態］
複数の検索クエリにおけるＡＮＤ検索およびＯＲ検索の場合の処理を示す。ここでは２個の検索クエリでＡＮＤ検索またはＯＲ検索を行う場合を示す。
【００３９】
メタデータの生成からメタデータルーティングテーブルを生成してメタデータをプッシュ的に配置するまでは第１の実施形態の処理１）〜５）と同様である。
【００４０】
次に、図１０に示すように、それぞれの検索クエリは独立に、第１の実施形態と同様の処理を行い、それぞれの検索キーに適合するメタデータを発見（ステップ１０１）した後、利用者端末１のキャッシュメタデータＤＢ１４２に保管する（ステップ１０３）。その後、ＡＮＤ検索の場合は、メタデータ管理部１４内において、共通する識別子を持つメタデータのみ選択（ステップ１０３）して表示する。ＯＲ検索の場合は、ステップ１０３を行わず、全てのメタデータが表示の対象となる。
【００４１】
なお、利用者端末の機能は専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間の間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。
【図面の簡単な説明】
【００４２】
【図１】本発明が適用されるＰ２Ｐネットワークの一例を示す図である。
【図２】利用者の端末の構成を示す図である。
【図３】要素毎のメタデータの一例を示す図である。
【図４】メタデータルーティングの一例（初期状態）を示す図である。
【図５】メタデータルーティングテーブルの一例（ルーティングテーブルの例）を示す図である。
【図６】メタデータルーティングの一例（メタデータのプッシュ型キャッシュ）を示す図である。
【図７】検索クエリの例を示す図である。
【図８】第２の実施形態のＰ２Ｐネットワークの例を示す図である。
【図９】第２の実施形態のＰ２Ｐネットワークのメタデータ移動後を示す図である。
【図１０】本発明の第３の実施形態で、ＡＮＤ検索およびＯＲ検索の一連の処理の例を示す図である。
【符号の説明】
【００４３】
１〜８ 利用者端末
１１ アプリケーション
１２ メタデータルーティングテーブル管理部
１２１ 期待値テーブル
１２２ 重み値テーブル
１２３ メタデータルーティングテーブル
１３ 検索要求管理部
１３１ クエリ転送部
１３２ クエリ照合部
１４ メタデータ管理部
１４１ メタデータＤＢ
１４２ キャッシュメタデータＤＢ
１５ Ｐ２Ｐネットワーク管理部
１０１〜１０３ ステップ
【特許請求の範囲】
【請求項１】
ネットワークを通じて、電子化されたコンテンツを公開・検索・発見するためのメタデータを検索する方法において、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理するステップと、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成するステップと、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータのプッシュ型配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成するステップと、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーするステップと、
利用者から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送し、前記検索クエリが転送されてくると自利用者端末内に目的のメタデータが存在するか調べるステップと
を有するメタデータ検索方法。
【請求項２】
前記メタデータが存在しないか、存在してもさらに検索を続ける場合には、前記メタデータルーティングテーブルにしたがって次の利用者端末に前記検索クエリを転送する、請求項１に記載のメタデータ検索方法。
【請求項３】
最も優先度の高い利用者端末への転送先が無くなった場合、次点で優先度の高い利用者端末、その次に優先度の高い利用者端末と、順次優先度の低い利用者端末へ検索クエリ転送することでネットワーク内の全ての利用者端末に前記検索クエリを転送する、請求項２に記載のメタデータ検索方法。
【請求項４】
Ｐ２Ｐネットワークを構成する利用者端末において、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理する手段と、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成する手段と、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値をもつ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、キャッシュデータ配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成する手段と、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーする手段と、
利用者から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送する手段と、
前記検索クエリが転送されてくると、自利用者端末内に目的のメタデータが存在するか調べる手段と
を有することを特徴とする利用者端末。
【請求項５】
請求項１から３のいずれかの方法をコンピュータに実行させるメタデータ検索プログラム。
【請求項１】
ネットワークを通じて、電子化されたコンテンツを公開・検索・発見するためのメタデータを検索する方法において、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理するステップと、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成するステップと、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値を持つ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、メタデータのプッシュ型配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成するステップと、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーするステップと、
利用者から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送し、前記検索クエリが転送されてくると自利用者端末内に目的のメタデータが存在するか調べるステップと
を有するメタデータ検索方法。
【請求項２】
前記メタデータが存在しないか、存在してもさらに検索を続ける場合には、前記メタデータルーティングテーブルにしたがって次の利用者端末に前記検索クエリを転送する、請求項１に記載のメタデータ検索方法。
【請求項３】
最も優先度の高い利用者端末への転送先が無くなった場合、次点で優先度の高い利用者端末、その次に優先度の高い利用者端末と、順次優先度の低い利用者端末へ検索クエリ転送することでネットワーク内の全ての利用者端末に前記検索クエリを転送する、請求項２に記載のメタデータ検索方法。
【請求項４】
Ｐ２Ｐネットワークを構成する利用者端末において、
構造化されたメタデータの１つ以上の要素とその内容である値の組み合わせと、同じく構造化されたメタデータをネットワーク内で一意に識別できる識別子とを一つの単位として管理する手段と、
前記メタデータの要素に対して、利用者が近い将来の一定時間における検索要求のうち、ある要素を対象に検索を行う頻度の予測である期待値、またはシステムによって割り振られる値と、端末資源値と掛け合わせた値によって重み値を生成する手段と、
前記重み値を要素毎に近隣の利用者端末に通知し、それを全利用者端末が行うことで近隣の利用者端末の中で最も高い重み値をもつ利用者端末を知り、それを繰り返すことで近隣の利用者端末の中でメタデータの要素毎に重み値の高い利用者端末に優先度を付けることで、キャッシュデータ配置または検索クエリの転送先を決定するメタデータルーティングテーブルを生成する手段と、
前記メタデータルーティングテーブルに従って最も優先度の高い近隣の利用者端末に前記メタデータをコピーする手段と、
利用者から要求された検索クエリを前記メタデータルーティングテーブルに従って近隣の利用者端末に転送する手段と、
前記検索クエリが転送されてくると、自利用者端末内に目的のメタデータが存在するか調べる手段と
を有することを特徴とする利用者端末。
【請求項５】
請求項１から３のいずれかの方法をコンピュータに実行させるメタデータ検索プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００６−６５６３６（Ｐ２００６−６５６３６Ａ）
【公開日】平成１８年３月９日（２００６．３．９）
【国際特許分類】
【出願番号】特願２００４−２４８４９８（Ｐ２００４−２４８４９８）
【出願日】平成１６年８月２７日（２００４．８．２７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成１８年３月９日（２００６．３．９）
【国際特許分類】
【出願日】平成１６年８月２７日（２００４．８．２７）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]