(57)【要約】【課題】ファイル名だけではなく、ファイルの内容を対象とした情報検索が可能で、使い勝手のよいピアツーピア型のファイル共有システムを提供することを課題とする。を課題とする。【解決手段】ファイル共有システムは、共有文書を実ファイルデータとメタデータの組合わせとして蓄積管理するものである。各ノードコンピュータに、メタデータの内容と検索条件とを照合して検索条件に該当する文書かどうかを判定する型プラグインと、ピアツーピアネットワークプロトコルにより他のノードコンピュータと通信するネットワークエンジンと、検索条件を入力し検索結果を表示する対話インターフェース機能と、それを利用してネットワーク全体に対して文書検索および管理を行う検索エンジンと、を備えて上記課題を解決する。共有文書型を階層的に自由に定義でき、型プラグインはその型に応じて用意する。【選択図】  図１１
2004157826.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードコンピュータが対等な関係で協調動作する文書共有ネットワークシステムであって、
このシステムに接続される各ノードコンピュータは、共有文書を、実ファイルデータと実ファイルデータを定められた項目毎に記述するメタデータとの組合わせであるデータセットとして各ノードコンピュータのそれぞれの記憶装置に保持するものであって、
さらに各ノードコンピュータが、
蓄積されている個々のデータセットに含まれるメタデータを参照する型プラグインと、
ピアツーピアネットワークプロトコルにより他のノードコンピュータと情報のやり取りを行うネットワークエンジンと、
前記ネットワークエンジンと前記型プラグインを用いてデータセットの検索、参照、転送、登録を実行する検索エンジンと、
利用者が前記検索エンジンに指示を与え、また検索エンジンによる検索結果を表示するグラフィカルユーザーインターフェースと、
を備えて、指定された検索条件を各データセットのメタデータと比較することにより該当するデータセットを抽出して検索結果として提示することが可能なピアツーピア型文書共有ネットワークシステム。
【請求項２】
請求項１に記載のピアツーピア型文書共有ネットワークシステムにおいて、前記メタデータは基本となるメタデータの型に発展部分を加えて新しいメタデータの型（メタデータ型）を次々に定義することが可能であって、システムに蓄積される共有文書をメタデータの型によって分類して蓄積管理することを可能とし、前記型プラグインは、共有文書のメタデータ型に応じて備えられることを特徴とするピアツーピア型文書共有ネットワークシステム。
【請求項３】
請求項２に記載のピアツーピア型文書共有ネットワークシステムにおいて、蓄積管理されている共有文書を検索する際は、一つメタデータ型を検索型として指定することにより、共有文書のうち検索型に一致するメタデータ型および検索型を基本の型とするメタデータ型に該当するデータセットを検索対象として限定することができることを特徴とするピアツーピア型文書共有ネットワークシステム。
【請求項４】
請求項２に記載のピアツーピア型文書共有ネットワークシステムにおいて、ある１つの型プラグインは、対応するメタデータ型のその型に対応した固有部分のメタデータのみを参照し、それ以外の基本部分のメタデータは、その基本となったメタデータ型の型プラグインを呼出すことを必要なだけ繰返すことにより、処理対象のデータセットのメタデータの前記型プラグインに対応するメタデータ型で記述される範囲を参照することを特徴とするピアツーピア型文書共有ネットワークシステム。
【請求項５】
請求項２に記載のピアツーピア型文書共有ネットワークシステムにおいて、共有文書を登録する場合に提供されるユーザーインターフェースは、新しく登録される文書のメタデータ型に応じて提供されることを特徴とするピアツーピア型文書共有ネットワークシステム。
【請求項６】
請求項３に記載のピアツーピア型文書共有ネットワークシステムにおいて、検索を始める際に検索条件を指定するユーザーインターフェースは、指定された検索型に応じて提供されることを特徴とするピアツーピア型文書共有ネットワークシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ピアツーピアネットワークにおける文書共有システムに関する。
【０００２】
【従来技術】
事業所などで構築されるＬＡＮでは、これまでクライアントサーバー型のネットワークを構築するのが普通であった。クライアントサーバーシステムの場合、ネットワークに接続されているコンピュータが、クライアントとサーバーに役割分担されている。このようなシステムではネットワークに接続されるコンピュータは、グラフィカルユーザーインターフェース（ＧＵＩ）を備えて利用者の操作入力に従って様々な要求や仕事の依頼を発するクライアントと、クライアントからの要求依頼に迅速に応えるサーバーとに分けられる。多くの場合ネットワークに接続されたパソコンがクライアントとなり、大容量記憶装置と高性能ＣＰＵを備えた高価で高性能の専用サーバー機がサーバーとなる。一方、最近では、ネットワークに接続されるパソコンのＣＰＵ性能の向上、ディスク容量の大型化により、ネットワークに接続されるコンピュータをクライアントとサーバーに分けないピアツーピア型ネットワーク（以下Ｐ２Ｐ型）が注目されてきている。
【０００３】
Ｐ２Ｐ型では、全てのコンピュータがクライアントでありサーバーとしても機能する。専用サーバ機を必要としないため費用も安価に済むことから、小規模なＬＡＮでファイルやプリンタを共有するのに向いている。一方、ファイルを共有させているコンピュータに負荷がかかるので、大規模なネットワークを構築するには適していない。だが、Ｎａｐｓｔａｒ（非特許文献１）やＧｎｕｔｅｌｌａ（非特許文献２）のようにインターネット上でユーザ同士のファイルを直接やり取りする技術も表れている。
【０００４】
Ｎａｐｓｔａｒ、Ｇｎｕｔｅｌｌａは、インターネット上でファイルを交換するためのプロトコルを定め、コンピュータに搭載されるＰ２Ｐネットワークエンジンがこのプロトコルにしたがって情報をやり取りすることにより、利用者は所望のファイルを保有する相手を見つけ、これを参照したり複製することができる。
【０００５】
【非特許文献１】
河内  正夫，  小柳  恵一著「Ｐ２Ｐインターネットの新世紀」
電気通信協会  ；  ＩＳＢＮ：  ４８８５４９０１９７  ；２００２年５月
【非特許文献２】
山村  恭平著「グヌーテラでいこう！―インターネットの世界に革命を起こす怪物ソフト『Ｇｎｕｔｅｌｌａ』」  ベストセラーズ  ；  ＩＳＢＮ：  ４５８４１６５２６２  ；２００１年１月
【０００６】
【発明が解決しようとする課題】
Ｎａｐｓｔａｒ、Ｇｎｕｔｅｌｌａでは、所望の情報の要求、検索は全てファイル名を対象として検索される。即ち検索文字列を含むファイル名を持つファイルを探すだけである。したがって、例えば、全文検索的な形態での情報検索はできないという制約があった。
【０００７】
本発明はこのような問題点を考慮してなされたものであり、ファイル名だけではなく、ファイルの内容を対象とした情報検索が可能で、使い勝手のよいピアツーピア型のファイル共有システムを提供することを課題とする。
【０００８】
【課題を解決するための手段】
課題を解決するための第１の発明は、
複数のノードコンピュータが対等な関係で協調動作する文書共有ネットワークシステムであって、その第１の態様は、
このシステムに接続される各ノードコンピュータは、共有文書を、実ファイルデータと実ファイルデータを定められた項目毎に記述するメタデータとの組合わせであるデータセットとして各ノードコンピュータのそれぞれの記憶装置に保持するものであって、さらに各ノードコンピュータが、
蓄積されている個々のデータセットに含まれるメタデータを参照する型プラグインと、ピアツーピアネットワークプロトコルにより他のノードコンピュータと情報のやり取りを行うネットワークエンジンと、前記ネットワークエンジンと前記型プラグインを用いてデータセットの検索、参照、転送、登録を実行する検索エンジンと、利用者が前記検索エンジンに指示を与え、また検索エンジンによる検索結果を表示するグラフィカルユーザーインターフェースと、を備えて、指定された検索条件を各データセットのメタデータと比較することにより該当するデータセットを抽出して検索結果として提示することが可能なピアツーピア型文書共有ネットワークシステムである。
【０００９】
共有蓄積文書をデータセットの形で管理し、検索時にメタデータを参照することにより、ピアツーピア型文書共有システムにおいてファイル名以外の検索語による共有文書の検索処理が可能となる。
【００１０】
課題を解決するための第１の発明の第２の態様は、
第１の態様に係るピアツーピア型文書共有ネットワークシステムにおいて、前記メタデータは基本となるメタデータに発展部分を加えて新しいメタデータの型（メタデータ型）を次々に定義することが可能であって、システムに蓄積される共有文書をメタデータの型によって分類して蓄積管理することを可能とし、前記型プラグインは、共有文書のメタデータ型に応じて備えられることを特徴とするピアツーピア型文書共有ネットワークシステムである。
【００１１】
第１の発明に係るシステムにおいて情報を管理する単位であるデータセットは、実ファイルデータ（実データ）とメタデータから構成される。実データとは共有文書の内容そのものである。一方、メタデータは、実データに関して定められた幾つかの項目の名前（項目名、タグ等）とその値（項目値）の集まりである。したがって、メタデータに含まれる項目名が一致するかどうかによって共有文書を同値類に分類する「文書型」が定まる。これを「メタデータ型」と呼ぶ。利用者は必要に応じて新しい文書型を定義でき、定義した文書型（メタデータ型）に応じた型プラグインによりメタデータを参照できる。このような管理体系をとることにより、環境が変わり蓄積すべき文書の性質が変化しても共有文書の管理を柔軟にかつ容易に行うことが可能となる。
【００１２】
課題を解決するための第１の発明の第３の態様は、
第２の態様に係るピアツーピア型文書共有ネットワークシステムにおいて、蓄積管理されている共有文書を検索する際は、一つのメタデータ型を検索型として指定することにより、前記検索エンジンは、共有文書のうち検索型に一致するメタデータ型および検索型を基本の型とするメタデータ型に該当するデータセットを検索対象として限定することができることを特徴とするピアツーピア型文書共有ネットワークシステムである。
【００１３】
検索型を指定することにより、検索型とその型から派生した型の文書を検索対象とできる。このような検索方法は、文書管理の観点から合理的である。派生した型の文書も基本となる型のメタデータを全て含んでいるからである。
【００１４】
課題を解決するための第１の発明の第４の態様は、
第２の態様に係るピアツーピア型文書共有ネットワークシステムにおいて、ある１つの型プラグインは、対応するメタデータ型のその型に対応した固有部分のメタデータのみを参照し、それ以外の基本部分のメタデータは、その基本となったメタデータ型の型プラグインを呼出すことを必要なだけ繰返すことにより、処理対象のデータセットのメタデータの前記型プラグインに対応するメタデータ型で記述される範囲を参照することを特徴とするピアツーピア型文書共有ネットワークシステムである。
【００１５】
第１の発明のシステムでは、型プラグインを基本の型からその様々な発展型まで、全て備える必要があるが、型プラグインをこのように構成し実現することは、新しい型を定義した時、その型に対応した新しい型プラグインの作成を容易にする。新しい型プラグインは、その元となった型プラグインが何かを知っていて、新たに付加されたメタデータに関する処理だけを行えばよいからである。
【００１６】
第２の態様に係るピアツーピア型文書共有ネットワークシステムにおいては、共有文書を登録する場合に提供されるユーザーインターフェースは、新しく登録される文書のメタデータ型に応じて提供されることが望ましい。利用者は、その文書のメタデータとして必要な情報を漏れなく登録することができるからである。
【００１７】
第３の態様に係るピアツーピア型文書共有ネットワークシステムにおいては、検索を始める際に検索条件を指定するユーザーインターフェースは、指定された検索型に応じて提供されることが望ましい。利用者は、その文書のメタデータとして定義されている項目の全てに関して必要なだけ検索条件を指定することができるからである。
【００１８】
【発明の実施の形態】
以下図面を用いて、本発明の実施形態を説明してゆく。図１は、本発明の一実施形態に係るＰ２Ｐ文書共有システム１（以下システム１）の概念図である。図１で１０はネットワークに接続される各コンピュータを示している。なおシステム１を構成する各コンピュータをノードコンピュータまたは単にノードと呼ぶ。各ノードは、存在を知っている他のノードと相互に接続されている。図１の左部分は、１台のノードコンピュータ１０の内部を示したものである。一つのノードには検索エンジン１１、幾つかのプラグイン１２、ネットワークエンジン１３、共有文書を蓄積管理するファイルデータベース２０が備えられている。ファイルデータベース２０は、共有文書をデータセット２１の形式で保持する。一つのデータセット２１は、実ファイル２１１と、実ファイルに何が記載されているか、あるいは、実ファイルの文書としての性質等、を定められた項目毎に記述したメタデータ２１０から構成される。
【００１９】
まず、本システムにおいて情報を管理する単位であるデータセットについて説明する。１つのデータセットは実ファイルデータとメタデータから構成される。この様子を図３に示した。「メタデータ」とは「実データ」に対する言葉であって、「実データについてのデータ」が原義である。実データが意味するものを示すデータとして使用されることが多い。システム１では、実データとは共有文書の内容そのものである。一方、メタデータは、実データに関して定められた幾つかの項目の名前（項目名、タグ）とその値（項目値）の集まりである。したがってメタデータに含むべき項目を適当に設定することにより、実データを読込まなくても、メタデータを参照することで、共有文書の内容の要旨や共有文書の何らかの属性を知ることができる。また、複数の共有文書のメタデータの項目名のリストが一致すれば、それらは同じ種類（同じ型）の共有文書であるということができる。つまりメタデータは共有文書を同値類に分類する「文書型」を定める。これを「メタデータ型」と呼ぶ。
【００２０】
さらに、システム１では、１つのメタデータ型を基本として、これに幾つかの新規な項目名を付加することにより新しいメタデータ型を定義することができる。
このようにしてメタデータ型の系列を作ることができる。図４は、このようなメタデータ型の系列の例を示している。図４では、メタデータ型Ａと記されたメタデータを基礎として、これに新たな項目Ｂ１，Ｂ２、・・を付加してメタデータ型Ｂとし、さらに新たな項目Ｃ１を付加してメタデータ型Ｃを定義した例を示している。このメタデータ型Ａ→メタデータ型Ｂ→メタデータ型Ｃの系列において、メタデータ型Ａ（Ｂ）はメタデータ型Ｂ（Ｃ）の基本となる型であり親の型ということができる。あるいは、メタデータ型Ｂ（Ｃ）はメタデータ型Ａ（Ｂ）を継承し新たな項目Ｂ１，Ｂ２、・・（Ｃ１）を付加してより発展させたものということもできる。また、型Ａは型Ｂ、Ｃの上位の型であり、型Ｃは型Ａ，Ｂの下位の型であるということができる。また、メタデータ型Ｂ（Ｃ）を定義する時に新たに付加した項目Ｂ１，Ｂ２、・・（Ｃ１）を便宜上「固有メタデータ型Ｂ（Ｃ）」と呼ぶことにする。固有メタデータ型Ｂは、メタデータ型Ｂとそれより下位のメタデータ型に含まれるが、メタデータ型Ｂより上位のメタデータ型には含まれない。
【００２１】
図１の説明に戻る。検索エンジン１１は、各ノード１０に備えられる。ノード１０で起動された検索エンジン１１が他のノードで動作する検索エンジン１１と互いに定められたＰ２Ｐプロトコルで情報をやり取りしてＰ２Ｐの検索処理を実現する。実際の検索処理は必要に応じて次々に呼出される型プラグイン１２がその役目をになう。またＰ２Ｐプロトコルで情報のやり取りを行うために、検索エンジン１１はネットワークエンジン１３を利用する。また、検索エンジン１１は、検索条件入力または共有文書の登録のためにメタデータの型（正確には固有メタデータ型）に応じて用意されたグラフィカルユーザーインターフェース（ＧＵＩ）を利用する。ＧＵＩ機能により利用者の検索要求を受付け、また検索結果を表示出力し、ファイル取込みの指示を受付ける。
【００２２】
型プラグイン１２は、処理対象の共有文書のメタデータを参照して、その文書に対する要求された処理を実行する。特に検索条件に関してその文書がヒットするかどうかの処理を行う。型プラグイン１２は、メタデータ型に対応して、すなわち文書型に対応して用意される。詳細は後述する。
【００２３】
ネットワークエンジン１３は、ピアツーピアのネットワークプロトコル（アプリケーション階層のプロトコル）によるノード間の通信を可能にするプログラムである。ネットワークエンジン１３は、非特許文献２に示されているコンピュータプログラムを利用してもよい。図２に、このネットワークプロトコルにより、あるコンピュータが情報の検索を行い所望の情報を入手するまでの流れを説明する。
【００２４】
図２では、ノードＡが検索要求を発した場合を示している。ノードＡは予め定められている検索順路にしたがってノードＢに対して検索要求メッセージを伝える。ノードＢはこのメッセージを受取ると自分の中に該当するデータが存在するかどうかを調べる（▲１▼）。自分の中に無い場合は次のノードであるＣに検索要求メッセージを流す。今度はノードＣが該当するデータが存在するかどうかを調べる（▲２▼）。該当するデータを保持していることが確認された場合は、ノードＣはノードＢにその旨応答を返す。ノードＢは、ノードＣに該当するデータがあるという内容の応答をノードＡに返す（▲３▼）。ノードＡは、ノードＣにデータを要求するメッセージを送る。ノードＣは、該当するデータをノードＡに送付する（▲４▼）。こうして、検索メッセージとそれに対する応答が伝言ゲームのようにやり取りされて、サーバー／クライアントの区別のないまったく平等なネットワークにおいて情報の検索と調達が行われる。なお、実際のプロトコルでは、検索要求の発散を防ぐため、ｌｉｆｅｔｉｍｅという概念がある。検索要求は一定の整数であるｌｉｆｅｔｉｍｅの値（例えば「＝５ノード」）を持って発生し。ノードを通過する度にｌｉｆｅｔｉｍｅを消費していき、０になるとその検索要求は次ノードに転送されない。
【００２５】
次に、図６及び図７より、システム１のファイル共有機能が実際にどのように動作するのかを例により説明する。図６左側の図は、説明例で前提とする文書型の系列を示す。図６右側の図は説明例で前提とするピアツーピアの伝言経路を示す。説明例は、本人（ｍｕｒａｔａ）が自分のコンピュータから文書の題名に「○×△」を含む共有文書を検索し、入手するまでのシステム１の動作を示す。
【００２６】
まず、利用者（ｍｕｒａｔａ）は、ｍｕｒａｔａのコンピュータ上でＧＵＩメニューから提案書型の文書検索を選択し（図７の▲１▼−１）、検索項目を設定する。ここでは、題名に「○×△」を指定する。したがって題名に「○×△」を含む提案書型のデータセットが検索されることとなる（図７の▲１▼−２）。検索クエリーは、定められた伝言経路に従ってｓｕｚｕｋｉ、ｔａｎａｋａの２つのノードに伝えられる（図７の▲２▼、▲３▼）。
【００２７】
ノードｓｕｚｕｋｉは、自身が保有しているデータベース２０に該当するデータセットが存在するかどうかを調べ、さらに、下位の伝言経路に存在する下位のノードに検索クエリを転送する。（図７の▲２▼−１）。
【００２８】
ノードｔａｎａｋａでは同様に、自身が保有しているデータベース２０に該当するデータセットが存在するかどうかを調べ（図７の▲３▼−１）、さらに、下位のノードｍｉｎａｍｉに検索クエリを転送する（図７の▲４▼）。ノードｍｉｎａｍｉでは同様に、自身が保有しているデータベース２０に該当するデータセットが存在するかどうかを調べ（図７の▲４▼−１）、該当するデータセットが存在する場合は、「ｍｉｎａｍｉに該当するデータ有り」の旨と該当するデータセットのメタデータをノードｔａｎａｋａに返す（図７の▲４▼−２）。ノードｔａｎａｋａは、そのレスポンスをｍｕｒａｔａに中継する（図７の▲３▼−２）
【００２９】
ノードｍｕｒａｔａでは、検索クエリに対して返ってくる応答を集めて、検索結果画面を構成し、利用者に表示する（図７の▲５▼）。検索結果画面には、該当するデータセットの題名、所有者（存在するノード）、データセットの型が一覧表で表示される。利用者はこのリストからダウンロードしたいデータセットを選択する。すると、ダウンロード選択されたデータセットが存在する各ノードへ直接ダウンロード要求が発信される（図７の▲６▼）。
【００３０】
ダウンロード要求を受けたノードは指定されたデータセットを直接ノードｍｕｒａｔａへ転送する（図７の▲６▼−２）。このようにして、ピアツーピアネットワークにおいて、共有ファイルの検索、転送が行われる。
【００３１】
次に、図６、図７により説明した動作を実現するシステム１の構成を説明してゆく。以下の説明の前に、以下の説明の具体例として使用する３種類のメタデータ型を図８に定義する。図８（ａ）は報告書型のメタデータ（Ｍ０１）の内容を示す。報告書型のメタデータＭ０１は、「文書タイトル」「作成者」「作成日」の項目から構成される。図８（ｂ）は会議報告書型のメタデータ（Ｍ０１２）の内容を示す。会議報告書型は報告書型のメタデータＭ０１に「会議名」「出席者」「開催日時」の項目のセット（Ｍ０２）を加えたものである。図８（ｃ）は出張報告書型のメタデータ（Ｍ０１３）の内容を示す。出張報告書型は報告書型のメタデータＭ０１に「出張先」「同行者」「出張日時」の項目のセット（Ｍ０３）を加えたものである。図８（ｄ）は、報告書型、会議報告書型、出張報告書型の３つの文書型の親子関係を表す系統図である。なお実際のメタデータは項目名だけでなくその値および固有メタデータ型の型名（「報告書型」など）を含んでいる。
【００３２】
また、以下の説明では、「（１つの）共有文書」と「（１つの）データセット」、「文書型」と「メタデータ型」を同義の用語として用いる。「（１つの）共有文書」および「文書型」は利用者の観点で用いる用語であり、「（１つの）データセット」および「メタデータ型」はコンピュータシステムの観点で用いる用語であるが、実体として同じ物を指すからである。
【００３３】
図１２および図１３は、検索エンジン１１の動作全体を説明する概略フローチャートである。図１２および図１３は、一つのフローチャートを紙面の都合上２つに分けて示したものである。以下、この概略フローにより検索エンジン１１の動作を概略説明する。
【００３４】
検索エンジン１１は、ノードコンピュータが立上がると必ず起動される。まず初期設定処理を行う（Ｓ０１）。初期設定処理はノードコンピュータのＯＳやシステムの実装方式に依存するが、ネットワークエンジン１３を起動していつでも他のノードとのピアツーピアプロトコルによる通信を可能な状態にしておくこと、検索処理の実行に使用する一時記憶領域や各種状態フラグを初期状態にすること等の処理を行う。初期設定が終ればいつでも検索処理の受付けが可能な状態となるので、検索条件入力画面インターフェースを呼出すアイコンをコンピュータ画面上に表示する（Ｓ０５）。これで利用者は、検索を行いたい時は、前記アイコンをクリックすることによりいつでも検索条件入力画面を表示させることが可能となる。
【００３５】
その後は、検索エンジン１１は、イベント待ちの状態となる（Ｓ０９）。ここでのイベントは、主なものは、検索アイコンの選択、検索要求発生、ファイル転送要求発生、検索結果受付け、ファイル転送要求の返答受付け、検索要求受付け、検索結果中継受付け、ファイル転送要求受付けである。なお、検索エンジン１１の機能としては、この他に、共有文書の登録・変更処理のための操作画面の呼出し、と登録・変更処理の指示等の対話操作によって生ずるイベントも発生するが、以下の説明では、検索エンジン１１の主たる機能である検索処理に関わる動作に絞って説明する。
【００３６】
検索アイコン選択イベントを検索エンジン１１が検知すると、検索エンジン１１は、まず、検索する型（検索型）を選択するＧＵＩ画面を表示し（Ｓ１７）、利用者に検索型を選択させる。次に、利用者画選択した検索型に応じた検索条件入力画面が表示され（Ｓ１９）、利用者は、その画面で検索条件を入力する。
【００３７】
図９に、検索条件入力を行う際のＧＵＩの画面例を示す。図９（ａ）は、検索型を選択するＧＵＩ画面である。図９（ｂ）〜（ｄ）はそれぞれ、検索型として報告書型、会議報告書型、出張報告書型を選択した場合に、表示される検索条件指定画面である。
【００３８】
検索要求イベントが発生するのは、利用者が図９（ｂ）〜（ｄ）にて検索条件を入力した後検索ボタンを押した時である。この時、検索エンジン１１は、ネットワークエンジン１３を通じて、経路上の次のノードに検索リクエストを発行させる（Ｓ１０）。検索リクエストには、利用者が入力した検索条件の他に、検索リクエストのＩＤ番号、検索要求元ノードのＩＤ、ｌｉｆｅｔｉｍｅの初期値、等の情報が含まれる。検索エンジン１１は、このＩＤ番号のリクエストが検索中である（自ら発した検索リクエストに対するレスポンス待ちの状態である）ことを示すフラグを立てる（Ｓ１２）。
【００３９】
ファイル転送要求イベントが起きるのは、利用者が検索結果一覧画面から、特定のファイルを選択してファイル転送要求ボタンを押した時である。検索エンジン１１は、ネットワークエンジン１３を通じて、当該データセットを有するノードにファイル転送リクエストを発行させる（Ｓ２０）。
【００４０】
自ら発行したファイル転送リクエストに対するレスポンスがかえってきた時は、ファイルデータを取込む（Ｓ４０）。これで一連の処理は終了する。
【００４１】
次に、図１３に沿って、中継ノードの検索エンジン１１の処理を説明する。
【００４２】
まず、手前のノードから検索リクエストを受けた（中継した）場合は、検索エンジン１１は、ネットワークエンジン１３を通じて経路上の次のノードに検索リクエストを中継する（Ｓ５０）。ただし、ネットワークエンジン１３は、検索リクエストのｌｉｆｅｔｉｍｅが零の場合はもはや中継を行わない。また中継する場合は、ｌｉｆｅｔｉｍｅの値を１減じて中継する。そして、自ノードの検索処理を実行する（Ｓ５２）。検索処理結果は、検索処理が終り次第、手前（上位）のノードに返送する（Ｓ６２）。
【００４３】
また、経路上の下位のノードから検索結果を受けた場合は、そのまま経路上の上位のノードに中継する（Ｓ６２）。
【００４４】
自ノード宛てのファイル転送リクエストを受けた時は、当該ファイルのコピーを要求元ノードへ直接返送する（Ｓ７０）。
【００４５】
図１４のフローチャートは、ステップＳ５２の自ノードの検索処理の流れをさらに詳しく説明するものである。以下、図１４に沿って自ノードの検索処理を説明する。
【００４６】
まず、当該ノードに存在する未調査のデータセットを１つ選択する（Ｓ８０）。次に、調査対象データセットの文書型が指定された検索型と一致するかそれより下位の型であるかを検査する。含まない場合はステップＳ８８にジャンプする。含む場合は、指定された検索型のプラグイン１２を呼出し、これに、検索条件データを引き渡して、このプラグイン１２による検索を実行させる（Ｓ８４）。プラグイン１２は、後述するように、必要な場合はその内部でさらに別のプラグイン（「親の型」のプラグイン）を呼出すなどしてメタデータ中に検索条件データにヒットする部分があるかどうか調べて、その結果（ヒットしたかどうか）を検索エンジン１１に返す。検索エンジン１１はその結果を一時記録する（Ｓ８６）。そしてまだ未調査のデータセットが自ノードに存在かどうかチェックして（Ｓ８８）、存在する場合はステップＳ８０に戻る。存在しない場合は、自ノードについて全ての検索が終了したことになる。
【００４７】
図１４のフローチャートで、検索エンジン１１からどのようなタイミングで型プラグイン１２が呼出されるか述べた。型プラグイン１２は、自ノードの検索処理（Ｓ５２）において、特定の１個のデータセットが、与えられた検索条件にヒットするかしないかの結果を返す働きを担う。図５は、ステップＳ８４の型プラグイン１２による検索処理をさらに詳しく説明するフローチャートである。以下、図５に沿って検索エンジン１１から呼出された型プラグイン１２の処理を説明する。
【００４８】
まず、呼出された型プラグイン１２が処理対象とする項目の値（固有メタデータ）について、検索条件に該当する部分があるかどうかを検査する（Ｓ１０１）。該当する（ヒットした）場合は、調べたデータセットは検索結果リストに加えるべきものとして、ヒットしたことを戻り値にセットして呼出し元にリターンする（Ｓ１０５）。ヒットしなかった場合は、呼出されたプラグインに上位の型があるかどうかチェックして（Ｓ１０７）、上位の型プラグインがなければ、このデータセットではヒットしなかったということを戻り値としてセットして呼出し元にリターンする（Ｓ１１３）。以上の二つのケースは、この型プラグインで結果が確定する場合である。ステップＳ１０７で上位の型プラグインが存在する場合は、検索条件データを引渡して上位の型プラグインを呼出す（Ｓ１０９）。上位のプラグインでは、同様の判断処理が行われる。上位のプラグインの戻り値をそれを呼出したプラグインの戻り値としてセットして呼出し元にリターンする（Ｓ１１１）。
【００４９】
以上が、型プラグイン１２による検索処理動作である。本システムでは、検索型に対する固有メタデータから出発して、メタデータの内容が検索条件にヒットするまで、次々に上位の型プラグインが呼出される。各型プラグインは自分の担当範囲（対応する固有メタデータ）だけ調べてヒットしない場合は、それ以上の処理は親の型の型プラグインに処理を委譲する。このようなシステムの構成を採用することにより、新しい文書型を定義したときに対応する型プラグインの実現が容易となり、柔軟な文書共有システムが実現できる。
【００５０】
次に図１０および図１１により図５のフローチャートの動作を実現する型プラグイン１２の構成を説明する。型プラグイン１２は、メタデータの中の固有メタデータ型に対応して備える必要がある。基本の型（親の型、上位の型）の発展型として新しく定義したメタデータ部分を処理する必要があるからである。図１１は、固有会議報告書型Ｍ０２に対応した型プラグインをクラスオブジェクトとして実現する場合の論理的な構成を表現した図である。クラスオブジェクトＰ０２は型定義情報Ｐ０２０を保持する。型定義情報Ｐ０２０には、型の名前（会議報告書型）、固有メタデータを定義する項目定義情報、親プラグインの型プラグインＩＤまたは型名が記録される。また、クラスオブジェクトＰ０２は検索結果伝達手段Ｐ０２１、固有メタデータ検索手段Ｐ０２２、親プラグインへの検索委譲手段Ｐ０２３の各メソッドを備える。
【００５１】
固有メタデータ検索手段Ｐ０２２は図５のフローチャートで説明した動作の主要部分を実行する。検索結果伝達手段Ｐ０２１は、この型プラグインで処理した結果を呼出し元（子の型プラグインまたは検索エンジン１１）に返す処理を担当する。親プラグインへの検索委譲手段Ｐ０２３は、ステップＳ１０９で検索の処理を上位の型プラグインへ移す制御を実行する。
【００５２】
図１０は、固有報告書型Ｍ０１に対応した型プラグインをクラスオブジェクトとして実現する場合の論理的な構成を表現した図である。クラスオブジェクトＰ０１は型定義情報Ｐ０１０を保持する。型定義情報Ｐ０１０には、型の名前（報告書型）、固有メタデータを定義する項目定義情報、親プラグインの型プラグインＩＤまたは型名が記録される。また、クラスオブジェクトＰ０１は検索結果伝達手段Ｐ０１１、固有メタデータ検索手段Ｐ０１２の各メソッドを備える。親の型プラグインは存在しないので親プラグインへの検索委譲手段Ｐ０１３は備えていない。
【００５３】
なお、クラスオブジェクトＰ０１、Ｐ０２に、メタデータの登録・変更を行う手段をメソッドとして付加すれば、Ｐ０１，Ｐ０２により、文書検索だけでなく、共有文書のメタデータの登録・変更も行うことが可能となる。
【００５４】
以上、本システムの実施形態を詳しく説明した。このシステムによる文書検索の特徴をまとめると以下の通りである。ある検索型、例えば報告書型で検索すると、その発展型である会議報告書型、出張報告書型文書も検索の対象となる。しかし、その場合、会議報告書型、出張報告書型文書は、報告書型文書として扱われるので、報告書型プラグインのみ働き、会議報告書型プラグイン・出張報告書型文書プラグインは働かない。すなわち発展型の固有部分のメタ情報は検索に関与しない。したがって、文書の型を基本型からその発展型へ階層的に定義してゆくことができるが、そのような型の系統樹は、初めから固定されている必要はなく、必要に応じて後から新しい型を定義して新しい型のデータセットを蓄積できる。そのようにしても、従来から存在する型に関して検索する場合は支障なく検索することができる。また追加した新しい型による検索ができるようファイル共有システムをバージョンアップする場合には、発展部分のメタ情報だけを扱う型プラグインを作成しこれを各利用者に配布するだけでよい。
【００５５】
例えば、最初は報告書型だけが定義され、報告書型として幾つかの共有文書が蓄積された後、会議報告書型が定義され、会議報告書型共有文書が蓄積されたとしても、報告書型で検索を行う時は、全ての共有文書が検索対象となる。本システムのこのような特徴は、多数の利用者が対等の関係で利用するＰ２Ｐファイル共有システムに運用の柔軟さを与える。蓄積する文書に適したメタ情報を定義することは、その文書を作成した目的に依存するが、文書を作成する目的は、その時にファイル共有システムを利用する構成員の活動テーマ等に依存し、構成員の活動テーマは一定ではなく、時とともに変化するからである。
【００５６】
【発明の効果】
以上詳しく説明したように本システムによれば、ファイル名だけで検索するのではなく、メタ情報により検索可能なＰ２Ｐ型のファイル共有システムを実現することができ、さらに、ファイル共有システム稼動後に、蓄積する文書の型を追加する必要が生じても、容易に柔軟に対応できるという顕著な効果を奏する。
【図面の簡単な説明】
【図１】本発明の実施形態に係るピアツーピアネットワークシステム１を構成するノードコンピュータの概要を説明する図である。
【図２】ピアツーピアネットワークプロトコルを説明する図である。
【図３】データセットの構造を説明する図である。
【図４】メタデータの構成例を説明する図である。
【図５】型プラグイン１２の働きを説明するフローチャートである。
【図６】システム１の検索処理動作を説明する図である。
【図７】システム１の検索処理動作を説明する図である。
【図８】説明で用いる３種類のメタデータ型の説明図である。
【図９】検索処理を行うためのＧＵＩ画面例である。
【図１０】報告書型プラグインを説明する構成図である。
【図１１】会議報告書型プラグインを説明する構成図である。
【図１２】ピアツーピアネットワークプロトコルを説明する図である。
【図１３】データセットの構造を説明する図である。
【図１４】メタデータの構成例を説明する図である。
【符号の説明】
１            文書共有ネットワークシステム
１０        ノードコンピュータ
１１        検索エンジン
１２        型プラグイン
１３        ピアツーピアネットワークエンジン
Ｐ０１    報告書型プラグイン
Ｐ０１０                報告書型プラグインの型定義情報
Ｐ０１１                報告書型プラグインの検索結果伝達手段
Ｐ０１２                報告書型プラグインの固有メタデータ検索手段
Ｐ０２    会議報告書型プラグイン
Ｐ０２０                会議報告書型プラグインの型定義情報
Ｐ０２１                会議報告書型プラグインの検索結果伝達手段
Ｐ０２２                会議報告書型プラグインの固有メタデータ検索手段
Ｐ０２３                会議報告書型プラグインの親プラグインへの検索委譲手段
【図１】
2004157826.tif 000003
【図２】
2004157826.tif 000004
【図３】
2004157826.tif 000005
【図４】
2004157826.tif 000006
【図５】
2004157826.tif 000007
【図６】
2004157826.tif 000008
【図７】
2004157826.tif 000009
【図８】
2004157826.tif 000010
【図９】
2004157826.tif 000011
【図１０】
2004157826.tif 000012
【図１１】
2004157826.tif 000013
【図１２】
2004157826.tif 000014
【図１３】
2004157826.tif 000015
【図１４】
2004157826.tif 000016