JP5369821B2 - 検索仲介システム - Google Patents

Description

本願発明は、開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムに係り、特に、実情報保有登記型検索仲介方式を包含できる検索式中継・回答集約型の検索仲介システムに関する。

近年、物流管理や物品所在管理の情報を、企業を超えて共有することが求められている。ｅｂＸＭＬ（electronic business XML）に代表されるように、そのための基本情報の取得の仕組み、情報共有・交換の枠組みや交換される情報の項目の共通化が整備されつつある。この共通化された情報共有・交換の枠組みを利用して企業の業務情報を蓄積したデータベースを既存あるいは潜在の取引先に必要に応じて検索させることで、円滑な事業運営をはかることも始まりつつある。

一方、インターネット上にデータ処理機機能を公開するＸＭＬ Ｗｅｂサービスの所在を電話帳的に公表するＵＤＤＩの仕組みの上で、ＸＭＬ Ｗｅｂサービスの接続方法を示すＷＳＤＬを公開してデータベース検索を提供する取り組みがある（特許文献１参照）。

しかしながら、このデータベースにどれについてのデータが格納されているか、これについてのデータはどのデータベースに格納されているかを知ることは検索するまで判らない。通常の一般向けＷｅｂコンテンツについては、クローラーエンジンが無人アクセスしてキャッシュを溜め込み、これを検索させてもとの所在を回答するＧｏｏｇｌｅなどの検索サイトがある。しかしながら、業務機密を維持し、事業上の配慮で特定の相手を選別してデータの所在を伝える仕組みは、ＥＵ ＢＲＩＤＧＥ Ｐｒｏｊｅｃｔなどの実験的な取り組みがあるが、まだ実用化されていない。

自社が管理する情報を公開することは、それにより新たな顧客を開拓することができるという利点を有している。しかしながら、情報を無条件に公開すると、競合相手にも手の内を明かしてしまうことになるという問題もある。これは情報の内容はもちろん、データベースの所在自体も、潜在取引先には周知させたいが、産業スパイやクラッキング妨害などを予防するためにも競合相手など不都合な相手には秘匿しておきたいという矛盾した要求を抱えることになる。標準化されたデータ共有・交換の手法が普及しつつある今日、この恩恵として共通の基盤で結ばれることにより、これまでには出会うことの無かったより有利な取引関係が新たに結ばれる好機が潜在している。しかしながら、基盤として共通化されていてもその存在や所在を探知することは依然として困難がある。

このため、情報の内容自体、又情報の所在の有無やその場所を開示しつつも、開示の要求元に応じて、これらの開示を制限することができる、検索対象とする情報開示の仲介を提供するためのシステムが提案されている。以下、検索仲介システムと呼ぶ。

このような検索仲介システムとして、実情報の保有を仲介システムに届け出て、当該実情報を探索している検索者に実情報の保有ＤＢへのアクセスパスを回答させる実情報保有「登記型」の検索仲介方式が外部で提案されている。以下、このような仲介システムを登記型検索仲介システムと呼ぶ。又、以下において、登記型の検索仲介の概念を図１に基づいて説明する。

図１は、登記型方式における検索者Ｃ、検索仲介システム、及び実情報ＤＢの関係を示す概念図である。

図１における「１」〜「５」は、それぞれ、以下に列挙する第１〜第５ステップであり、この順に、検索対象の実情報を登録してから検索者Ｃに利用されるまでの処理の流れを示すものである。

第１ステップ：実情報データベースＲ（リソース：一例としてＥＰＣ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ (以下ＥＰＣＩＳ）)が実情報を保有し、検索者Ｃに供与可能なことを、サマリーレコード（後述）を自己作成し開示対象者の範囲を指定して仲介システムＤに実情報の保有照会を許可する「データ供与公表」として登記する。

第２ステップ：検索者（クライアント）Ｃが仲介システムＤに関心のある物品所在・取扱い実情報の保有ＤＢを登記型仲介システムＩに「保有先探索」として問い合わせる。

第３ステップ：仲介システムＤは開示条件に適合している検索者Ｃに実情報所在先うち、開示が許諾される実情報データベースＲそれぞれへのアクセスパスを紹介する。

第４ステップ：検索者Ｃは個別の実情報データベースＲそれぞれと直接接触して当該ＤＢで実情報検索を行う許諾を得てから、実検索式を送付する（アクセスを最初から拒絶される場合もあり、その場合は、実情報検索は不能）。

第５ステップ：実情報データベースＲは検索者Ｃの身元を判断して、自身の方針に即して内容を秘匿修正（粒度処理）して、検索者Ｃから求められた詳細データを回答する。

この図１に例示される登記型方式は、保有する実情報の各レコードに対して、仲介サービス規格に基づく限定的な検索キー「サマリーキー」によって該当するレコード群の所在のみを回答する「サマリーレコード」を実情報ＤＢ側で自己作成し、仲介システムの登記簿に登録させることを基本構成としている。「サマリーキー」と「サマリーレコード」については、先例があるがまだ標準規格として制定されているものが無いため、この概念を実現するに足る想定例を後述する。又、サマリーレコードとサマリーキーを実記録レコードや実検索式から作成する方法についても、まだ何の方法も規定としては示されていない。このため、以下では、概念が成立することを示すために、実在する検索規格“ＥＰＣＩＳ”を参考にした仮想例を取り扱う。

次に、図２は、登記型方式での仲介システム間の提携による所在探索範囲の拡大と、その効果による単一範囲外への実検索の概要を示す全体構成図である。

実情報保有Ｒ３〜５は、情報保有登記Ｄ２に実情報の保有登記と所在開示を担当させる傘下に加盟している。実情報保有Ｒ６、７は、別の情報保有登記Ｄ３に加盟している。

検索クライアントＣ１２は、所在探索者としてＤ２に加入している。

Ｄ２とＤ３は、お互いの探索加入者を相互に紹介し、加入者の身元と探索料金の清算を保証し、傘下の実情報ＤＢ群の所在開示を斡旋する提携契約を取り交わしている。

図１のステップに沿って、提携探索の流れを説明する。所在探索の回答ステップ３と、実検索の回答ステップ５は、簡略化のため省略する。図２中には、各ステップをＳ１、Ｓ1’〜とＳを付けた番号で転記している。

第１ステップ：各実情報ＤＢ＝リソースＲはそれぞれの加盟先の仲介システム＝登記データベースＤに、「データ供与公表」を登記する。

第２ステップ：Ｃ２から加入先のＤ２に探索が掛かると、Ｄ２は傘下から登記された「データ供与公表」を検索して該当実情報の保有を届けて出ているＲ３を抽出するとともに、ステップ２´として提携先のＤ３にも波及探索を依頼する。間接探索を受けたＤ３は、傘下のＲ７が該当の実情報を保有していることを回答する。

第４ステップ：直接加入先のＤ２からＲ３とＲ７の所在を探知したＣ２は、Ｒ３とＲ７それぞれに接触して検索許諾交渉を試み、許諾された場合にはＳ４及びＳ４´として実情報検索式を送付して、求める実情報を（各ＤＢの開示する範囲で）取得する。

これに対し登記型の検索仲介方式とは異なる検索仲介方式として、検索者の実検索式を加盟するＤＢ群に複写中継し各ＤＢの回答を集約して一括回答する検索式「中継」・回答集約型の検索仲介システムがある（特許文献２参照）。以下、簡略に、このような仲介システムを中継型検索仲介システムと呼ぶ。

図３は、検索式中継・回答集約方式の概念図である。

この図では、中継型検索仲介システムＩにおいて、検索式を中継し、又回答を集約する検索仲介システムＩの基本動作や基本概念が示される。この図において、「１」〜「６」は、以下に説明する第１〜第６動作処理を示す。括弧書き内の記述は、中継型の本質では無いが、その特徴であるより高度な付帯処理について一括して述べたものである。

第１動作処理：実情報保有ＤＢ Ｒが所在アクセスパスと実情報の開示対象者を仲介システムＱに登録する。

第２動作処理：検索者Ｃが身元（と身元開示範囲）を仲介システムＱに登録する。

第３動作処理：検索者Ｃは検索式を仲介システムＱに投げる。

第４動作処理：仲介システムＩは開示対象に該当する実情報データベースＲに検索式を複写して配布する。

第５動作処理：仲介検索式の複写配布を受けた実情報データベースＲは、自身の方針に即して開示できる範囲で（標準）、結果を仲介システムＱに回答する。

第６動作処理：仲介システムＱは実情報データベースＲごとの回答を連結して一括で検索者Ｃに回答する。

このような中継型検索仲介システムＱには、登記型検索仲介システムＤに対し、次に列挙する優位点が挙げられる。

１. 検索者Ｃからは、仲介システムＩは単体の仮想実情報データベースＲ´にしか見えない。実情報データベースＲからは、仲介システムＱは単体の既知の検索者Ｃ´にしか見えない。つまり、上下双方とも基本動作として仲介システムＱを意識することは無い＝在来の検索手段から何の改変も必要ない。

２. 登記型が避けられない、所在探索後の初対面の実情報データベースＲと検索者Ｃの間の検索許諾交渉を完全に省くことができる。登記型では、実検索先が多数にわたる場合、逆側からは、頻繁に新規許諾交渉が殺到する場合、この事後交渉は重大な負担を強いることになる。

３. 検索者Ｃ、実情報データベースＲとも相手に対して匿名性を保つこともできる。
実情報データベースＲへの中継と検索者Ｃへの回答は、仲介システムＱの借り名義だけで済ますこともできる。ペナルティーを課して匿名を制限することもできる。

４. 最終的に供与する実情報をＤＢ側で自在に絞ることができる。
中継システムは全ての回答情報を触ることもできるので、開示項目・内容の制限＝粒度処理を実情報データベースＲは中継システムＱに委託することで、自身はそれ用の改修をせずに済ますこともできる。

５. 中継システムＱは、全回答トラフィックを測定・観察することができるので、実情報データベースＲに代わって無改修で情報量課金ができる。そのほか、情報内容のコントロールサービスを多岐に展開することができる。

特開２００６−１４６２９３号公報 特開２００９−１５５５２号公報

しかしながら、前述した登記型検索仲介システム、及び中継型検索仲介システムを比較すると、互いに他方にはない短所が見受けられる。

まず、登記型検索仲介方式では、中継型検索仲介システムに比較すると、実検索の許諾交渉に及ばなくても実情報の保有先が露見する（情報保有秘匿性で劣る）、実情報保有者側が事前に精密な開示対象者の適合属性を指定する必要がある（開示制限で劣る）、情報アクセス権取得後にも実情報保有ＤＢと個別に自動化が難しい検索許諾交渉が避けられない（事後折衝で劣る）、実検索とは別立ての登記データ作成や検索データ作成が必要（改修負荷で劣る）といった短所がある。

一方、中継型検索仲介方式は、以上の登記型方式の欠点を解消し、平常の実検索と同一のより軽便な利用方法でありながら、高度なデータ処理支援機能も提供できる点で優位にある。しかしながら、登記型検索仲介は、試験的にも実施例があり、普及面においては先行している。

本発明は、普及で先行している登記型の検索仲介方式としての所在探索に互換対応しながら、中継型の恩恵である傘下の利用者の改修負荷の解消を実現する検索仲介システムを提供することを課題とする。

本発明は、開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、ネットワークを介して、実情報ＤＢから回答を集める検索結果受領部と、検索者の開示身元に応じて、各ＤＢ指定の粒度処理を該回答に対して行う開示粒度処理部と、検索者から委託された実検索式に基づいて、実検索を代行実施する登記型仲介機能部と、を具備し、検索者から実情報ＤＢに対する検索を中継する機能を備えると共に、登記型から探査した実情報保有ＤＢ群に対して、検索者開示身元に基づき検索許諾交渉を行い、実検索を代行実施する代行実情報取得部を、前記登記型仲介機能部において備えたことにより、前記課題を解決したものである。

又、検索者から委託された実検索式から、登記型仲介サービスを利用するためのサマリーキーを作成するサマリーキー作成部と、検索者の開示身元に基づいて、検索する実情報が所在する実情報保有ＤＢを探索する実情報所在探索部とを、前記登記型仲介機能部において備えたものである。

又、前記ネットワークに接続する中継型検索仲介システムのサーバーからの粒度処理済み回答、及び、前記ネットワークに接続する登記型検索仲介システムのサーバーから前記登記型仲介機能部により代行取得した回答を合併する統合回答合併部と、該回答に基づいて、実検索結果として一括回答する実情報回答部と、を備えることができる。

加えて、中継型の情報提供料、及び、代行仲介・回答取得処理に要した費用を検索者アカウントごとに集計する課金管理ＤＢと、該課金管理ＤＢに対する集計、及び精算に関する処理を行なう検索クライアントアカウント管理部と、を備えるものである。

次に、本発明は、開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、利用者端末からの実検索式を含む実検索要求を受け付ける実検索式受付部と、傘下の実情報データベースに対して前記実検索式により検索をかける検索式依頼部と、検索結果を取得する検索結果受領部と、受けつけた前記実検索式からサマリーキーを作成するサマリーキー作成部と、作成した前記サマリーキーに基づき外部の登記型検索仲介機に所在探索を行う実情報所在探索部と、前記登記型検索仲介機に実情報検索を依頼し、検索結果を取得する代行実情報取得部と、実検索依頼部が取得した検索結果と代行実情報取得部が取得した検索結果を統合して実情報回答を作成する統合回答合併部と、実情報回答を利用者端末に送付する実情報回答部と、を具備することにより、前記課題を解決したものである。

ここで、前記実情報所在探索部が、多段波及の探索動作を行なうものであって、提携先のデータベースへ前記サマリーキーを送信するときは、自らが受けた該サマリーキー中のホップ数を１つ減じて転記するようにしてもよい。

次に、上記の検索仲介システムとして、コンピュータを機能させるソフトウエアプログラムを提供することも可能である。

本願発明によれば、中継型検索仲介システムでありながら、登記型検索仲介システムと連携し、あるいは、他の中継型検索仲介システムと連携して、検索者から依頼される検索を中継し、該中継型検索仲介システムの傘下の実情報ＤＢから回答を集め、検索者の開示身元に応じて、各ＤＢ指定の粒度処理を該回答に対して行うことができる。中継型検索仲介システム自らが、登記型検索仲介システムへの実情報所在問い合わせに対応し、加盟する検索クライアントを改修させずに登記型参加の実情報ＤＢ検索に対応させることができる。

又、委託された実検索式から、登記型の実情報保有登記簿検索用のサマリーキーを代行作成し、検索クライアントの身元開示指示に基づき、登記型仲介システムに代理問合せして実情報ＤＢ所在を取得することができる。更には、検索クライアントの身元開示指示に基づき、中継型システムが実情報ＤＢと接続交渉し、実検索式を複写配布して実情報を代行取得することができる。更に、中継型の代行情報粒度処理を経た中継型傘下の実情報ＤＢからの回答と、登記型傘下から代行取得した回答を合併し、仮想単体実ＤＢとして回答することができる。

更には、中継型の情報提供単価類型と、外部の登記型仲介・実情報取得費を合算して検索者に課金することができる。

実情報保有登記型の検索仲介方式における検索者、検索仲介システム、及び実情報ＤＢの関係を示す概念図 登記型方式での仲介システムの提携による探索波及の概要ブロック図 検索式中継・回答集約型の検索仲介方式における検索者、検索仲介システム、及び実情報ＤＢの関係を示す概念図 検索者Ｃ、中継型検索仲介システムＱ、登記型検索仲介システムＤ、及び実情報ＤＢの関係を示す概念図 中継型方式から登記型方式の領域を利用させる仕組みの概要と、異方式の仲介システム間の提携による探索波及の概要のブロック図 識別子取扱記録とこれを変換し所在開示方針を反映させた登記型仲介用のサマリーレコードの仮想例を示す線図 実情報保有登記型方式におけるサマリーキー仮想例と実検索式・結果を示す線図 探索者開示身元を制限した提携探索に利用できるサマリーキーの線図 検索者アカウントの身元属性と開示指令設定票の線図 本発明における互換機能を実現するハードウェア構成図 本発明を実現する中継システムの全体的な機能構成を示すブロック図 前記実施形態において、中継型から登記型検索仲介方式を利用させる連携動作フローチャート 実検索式中の波及制御のための臨時の指示項目例を示す線図 登記型探索に互換する中継型検索中継システムが、多段の登記型方式の提携探索を利用するブロック図 多段提携探索のホップ数を指定したサマリーキー例の線図

以下、図を用いて本発明の実施の形態を詳細に説明する。

図４は、本発明が適用された実施形態における検索者Ｃ、中継型検索仲介システムＱ、登記型検索仲介システムＤ、及び実情報ＤＢ Ｒの関係を示す概念図である。

図４における「１」〜「６」は、それぞれ、以下に列挙する第１〜第６ステップであり、この順に、検索者Ｃから実検索の依頼を受け、該実検索に対して応答するまでの処理の流れを示すものである。

第１ステップ：実情報データベースＲ（リソース：一例としてＥＰＣＩＳ）が実情報を保有し、検索者に供与可能なことを、サマリーレコード（後述）を自己作成し開示対象者の範囲を指定して登記型仲介システムＤに実情報の保有照会を許可する「データ供与公表」として登記する。

第２ステップ：検索者Ｃの身元と、実情報保有ＤＢ側への身元開示範囲を、検索者側が中継型仲介システムＱに登録する。身元開示範囲の登録により、実情報の提供者側への検索者Ｑの身元開示を制限することができる。

第３ステップ：検索者Ｃは、所望する実情報を検索するため、その実検索式を中継型仲介システムＱに投げる。

第４ステップ：中継型仲介システムＱは、実検索式からサマリーキー（後述）を作成し、登記型中継システムＤに検索者Ｃの開示身元でサマリーキーを投げて、保有先を代行探索する。

第５ステップ：登記型中継システムＤから保有先を得た中継型仲介システムＱは、実情報データベースＲに検索者Ｃの開示身元で検索許諾交渉を試み、実検索式を投げて実情報データベースＲの実情報を代行取得する。ここで代行取得される回答は、実情報データベースＲが設定している開示範囲内であり、今回の検索者Ｃの開示身元に対応し、開示された実情報の範囲内となる。

第６ステップ：中継型仲介システムＱは、実情報ＤＢごとの回答を連結して、一括で検索者に回答する。

次に、図５は、本実施形態の中継型方式から登記型方式のサービス領域を利用させる仕組みの概要と、異方式の仲介システム間の提携による探索波及の概要のブロック図である。

本実施形態の中継型検索仲介システムＱ０１は図４のＱに相当し、以下に説明するような第１〜第１２動作処理により、在来型の検索クライアントＣ１（図４のＣに対応）に対して、登記型検索仲介を意識することなく、登記型サービスＤ２（図４のＤに相当）に加盟している実情報Ｒ１〜Ｒ５（図４のＲ）に対しても一斉検索を提供することができる。

なお、この図５において、図中丸番号“１”、図中丸番号“４”及び“５”は、前述の図４の第１ステップ、第４ステップ及び第５ステップに対応する。説明見出し中のＰ＊の符号は、後にこのブロックの連携フローを示す図８の説明で使用する。

第１動作処理Ｐ１（第１ステップ）：検索クライアントＣ１は、情報保有登記型の検索仲介を代行できる中継型検索仲介システムＱ０１から実情報を検索できる許諾を受けている。

第２動作処理：中継型検索仲介システムＱ０１は、実情報保有Ｒ１及びＲ２から実情報を媒介検索できる許諾を受けている。

第３動作処理Ｐ３（第３ステップ）：検索クライアントＣ１は、Ｑ０１に実検索式を送付し、関心のある実情報を収集するよう依頼する。

第４動作処理Ｐ４-Ｐ４’（第４ステップ）：中継型検索仲介システムＱ０１は、Ｃ１から依頼された実検索式から所定の簡略化を施し実情報サマリーキーを作成する。提携関係にある情報保有登記型Ｄ２に委託し、Ｄ２に登記されている実情報の所在パスの回答を求める。

第５動作処理Ｐ５：（第４ステップの応答）Ｄ２はＱ０１に該当実情報を保有する実情報保有ＤＢ群、Ｒ５へのアクセスパスを回答し、下位の請求に自己の登記簿利用料を加えて請求する。

第６動作処理（第５ａステップ）：Ｑ０１は自己が直接に媒介検索できるＲ１とＲ２を実検索式で代行検索し、該当実情報を取得する。

第７動作処理 Ｐ７-Ｐ７’（第５ステップ）：Ｑ０１は第４ステップの結果として取得したＲ４へのアクセスパスを使用し、検索者Ｃ１が指定している開示身元を提示して検索許諾交渉を試み、許諾された場合にはＲ４の検索アカウントを取得する。

第８動作処理 Ｐ８-Ｐ８’（第５ステップの続き）：Ｑ０１は、第７動作処理で獲得したＲ４が発行した検索アカウントを使用し、実検索式をＲ５へ送信し、該当実情報を取得する。

第９動作処理（第６ステップ）：Ｑ０１は、代行検索で取得した該当情報の重複を消し込んで合併し、第３ステップの回答としてＣ１に実情報を戻し、合算された全ステップの登記簿利用料に自己の検索代行料を加えて請求する。

以上のように、検索者Ｃ１が直接に実情報Ｒ４の存在を探索して探知し、これと検索許諾交渉を行って実検索を実現するという、登記型に必須の工程を全く経ることなく、検索者Ｃ１は登記型仲介方式に参加している、通常ならば接続不能な実情報ＤＢからも所望の実情報を取得することができる。

次に、サマリーレコードとサマリーキーについて、具体例を説明する。

サマリーレコード及びサマリーキーは、登記型の検索仲介方式に固有な交換・保持データであり、本発明の背景技術に属するものである。この両者は研究段階としてＥＵ ＢＲＩＤＧＥ プロジェクトにおいて実装ＸＭＬスキーマ案が提示されているが、標準規格として制定されているものはまだ無い。本発明は、識別子を持った物品の取扱記録を説明の題材に使用しているが、ＩＳＯ−１５４５９等やＵＲＩなど、産業界で共通に標準化された識別子で特定できる事物全てを対象とすることができる。そこで図６は、物品の取扱記録と、識別子を持つ業務伝票を想定して、識別子取扱い記録の実情報レコードと登記型仲介用のサマリーレコードの推定例（仮想例）を示す線図である。又、図７は、図をもとにしたサマリーキーの仮想例と実検索式・結果を示す線図である。

現時点において、登記型検索仲介システムはまだ規格化されていないので、どういう種類の識別子を対象とした記録を仲介するのか、そのサマリーレコードの検索特定キーに何の項目を選定するのか、確定していない。サマリーキーはこの項目内容を直接に名指しする、乃至はワイルドカード等で限定的に絞り込むことが前提になるため、同じく未確定にある。

以下で、サマリーレコードとサマリーキーがどういったものであるか、登記型の検索仲介の概念を示す図１が示唆する仮想例をもとに、登記型の概念が成立する過程として図５を追いながら説明する。

保有登録サマリーレコードは、実情報レコードの中から、Ｄ２他が問い合わせ対応対象とするサマリーキー種別に対応する主キーとなる個体特定（区分・範囲）番号と、実情報を取得するためにアクセス許諾を求めるべき実情報Ｒ３〜Ｒ５他へのネットワークパス、及びそのネットワークパスの開示・非開示・個別交渉の対象とする検索者の特定（区分・範囲）からなる。

まず、図６上段の物品追跡用サマリーレコードの記載について説明する。

１) 物品取扱い記録の実情報レコードから、物として認識される物品に振られた個体識別番号が、用途区分に関わり無く「主項目」として抽出される。もとになっている取扱い記録では荷物そのものの製品個体と、それを運んできた収容容器と分別されていたが、サマリーレコード上では単に物の区分として合併されている。その他の関連元項目は脱落させられる。これらの関連項目を主項目として別のサマリーレコードを登記することも考えられる（例：取扱い事業所を単位として、扱い物品の区分を探索する、など。）。

２) この主項目に対して検索キーを名指し、乃至は範囲として探査してきた場合に、実情報の保有先として回答されるＲ４へのネットワークアクセスパス（例：ＷｅｂサービスＵＲＬ）が記載される。

３) 開示対象者が、開示・非開示又は個別判断の区分の元、企業識別子の名指し特定、あるいは業種分類で指定されている。

事例では、企業識別子がハイフンで企業番号と傘下事業所をつないだコードを想定している。更に企業番号の上二桁が業種分類を表し、傘下の事業所を特定しないというワイルドカード“＊”を表記している。この上二桁は国や地域、あるいは化学や運輸など業界区分を表す場合もある。但し、これはあくまで仮想例であり、上位区分や企業番号の体系は、ＧＳ１ Ｃｏｍｐａｎｙ Ｐｒｅｆｉｘ、ＩＳＯ／ＩＥＣ１５４５９や、ＵＮ／ＣＥＦＡＣＴ Ｐａｒｔｎｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃｏｄｅなど多岐にわたるため、直接これに該当しない、乃至は片方しか満たさないパターンもある。その場合は、別のワイルドカード表記をするか、対象者表を別に作成してそれを参照するなどの方法で同等の効果を得ることができる。いずれにせよ探索者は、身元企業番号を提示して、これのどの制限区分に入るかを判定され、ＵＲＬの開示を受けられるか決定される。

次に、図６下段の伝票照会用サマリーレコードの記載について説明する。

１) 業務伝票から主項目を伝票識別番号として簡略化し、同じく照会先パスと開示対象者を記載したものである。

２) 業務伝票の照会サービスは物品の取扱い記録とは記載項目や検索方法が異なるため、異なるＵＲＬのＷｅｂサービスが照会先として記載されている。

次には、図７により、サマリーキーの記載について説明する。

１) サマリーキーは、サマリーレコードの主項目内の記載内容を特定、乃至は範囲指定するもので、それぞれ対象物の個体識別子、伝票番号を明示している。

２) サマリーキーは、主項目の異なるサマリーレコードごと、乃至は複数の主項目から抽出される照会先アクセスパスが論理積として重複するなどの検索演算を想定することもできる。

更に、図７により、サマリーキーの利用について説明する。

１) 探したい実情報を保有する実情報データベースのアクセスパスを情報保有登記型検索仲介システムに問い合わせるときは、本来の実検索に使用したい実検索式を、異なる種類の情報項目からなり、それぞれの主項目の種類に対応するサマリーキーに簡略化する。

２) 実情報保有者の開示方針に従って、検索者の身元（属性）によっては所在回答を拒絶される場合が発生する。その場合の事後検索は不可能である。

図８の「アクセスパス応答」は、図６のサマリーレコードとは、物品追跡用、伝票詳細用とも表記が異なるものとして図説している。格納・検索用のサマリーレコードは、サマリーキー項目を検索主キーとして使用することを前提としているのに対して、探索回答用の「アクセスパス応答」は、探索者がこれから接触すべき実情報の保有先アクセスパスが主項目であり、そのパス先に複数のサマリーキー事物の記録が同時に含まれていることを伝えるため、記載方法が変更されている。又、回答は所在が開示されたか否かの真偽の結果であり、所在開示の対象者指定は外部に開示されるべきでない項目として当然、削除されている。

図６のサマリーレコードと図７のサマリーキー及びアクセスパス応答は、もとになった実記録、実検索式、サマリーレコードが、それぞれスキーマが規定されたＸＭＬで表記されていれば、ＸＳＬＴを利用して、それぞれ容易に変換可能である。これに開示対象者や種別など、補足情報をＸＭＬ要素・属性として付記することでそれぞれは自動作成することができる。これらがＸＭＬではなく、固定長ＥＤＩデータや行、カラム構造の順序意味が規定されたＣＳＶデータであっても、その順序内容を別の意味順序に並び替え、特定順序に補足情報をいれることで同等の置換処理が可能である。

これまで提案されている登記型方式では、探索者は検索仲介システムの加入者であり、紹介される実情報ＤＢも同じ検索仲介システムに加盟していることを前提としている。しかしながら、これだけでは、検索仲介システムが世界で唯一の存在でない限り、探索の範囲が限定されることになる。そこで、図２の提携探索が検討されている。図２の登記型検索仲介システムＤ３が同種のＤ２から間接的に波及探索を受ける場合、図６と図７の素のサマリーレコードで開示判定を行うためには、図２に当てはめて説明すると、Ｄ２は登記型探索を行う探索者Ｃ２の身元企業番号を全開示しなければ、Ｄ３は開示対象者か否か判定できない。ここで、元来の探索者Ｃ２と波及探索を受ける提携先の登記型検索仲介システムＤ３は、直接の守秘契約関係が無いため、Ｃ２はＤ３を運営する未知の検索仲介サービス事業者に自らの身元と関心事が補足され、元来無関係のその加盟傘下の実情報ＤＢ群や別の加入探索者に露見しないか懸念があることも起き得る。

こうした波及探索における懸念を解消する手段として、探索者が直接加入している先の検索仲介システムが、提携先の他所の仲介システムに探索者の身元保証を行い、探索者の身元を全開示せずともその背景属性のみを提示して提携探索を実現する方法を示す。

図８は、図７の物品追跡用のサマリーキーに、「身元状」を付記した実施例の線図である。

波及探索をＣ２自身が行う際に、Ｃ２の身元企業番号を全開示せずに、業種、事業地域からなる事業者としての背景属性だけを提示し、それに虚偽が無いこと、探索に関わる費用やその後の一切の法的責任を負う実体が存在していて、その履行手段が提供できることを、Ｃ２が直接加入しているＤ２が保証していることを示している。「身元符号」は、Ｃ２の本当の身元企業番号を秘匿するための異名であり、その対応関係は、Ｃ２以外はこれを発行したＤ２だけが知っている。身元符号は今回の探索のみについて有効な使い捨てとすることも、今後も有効な恒常的なものとすることもできる。波及探索を受けたＤ３は、探索が完了するまで、この身元符号を用いて、秘匿された探索者を認識することになる。

身元状の真正は、身元を保証する仲介システムの公開鍵ハッシュ署名により担保される。Ｃ２は、この記載内容を自身が直接加入するＤ２への加入審査で届け出ておき、波及探索を依頼するときにどこまで自らの身元を晒すかをＤ２に伝えることで、届け出内容から開示する背景属性項目をＣ２が選択してその内容にＤ２の秘密鍵でのハッシュ署名を求めることで、このパートは作製される。

波及探索、乃至は直接の加入者で無い探索者からの探索において、Ｄ３は身元状が、Ｄ２が署名した真正であることは、Ｄ２の公開鍵でデコードしたハッシュ値と身元状本文のハッシュ値が合致することで容易に判別できる。この段階で、提示された身元属性が真実であり、Ｄ２に提携契約に基づいてその身元保証照会識別子をキーに探索費用の立替えやその後の責務履行を求めることができるが担保される。

部分的に開示された検索者身元が登記型探索として使用される過程について説明する。これまでに提案されている登記型方式では、探索とその後の検索許諾交渉、及び実検索を行う場合は、身元を全開示することを前提としている。本発明では、検索者の身元開示の度合いに応じて、登記型検索仲介方式の探索処理は、以下の１)〜３)のようになる。

１) 検索者が身元詳細を全開示する場合：
検索者自身の身元属性の全て＝身元企業番号が開示される場合には、図６の開示・拒否対象の区分をそのまま適用する。ここでは開示対象の表記が、検索者の業界区分を現す数字コードに続いて企業固有番号が後続するコード体系を取っていることを想定している。これに対して、Ｄ２が保証する探索者の身元企業番号をこの所在開示方針と直接に照合することになる。

２) 検索者が身元非開示で業種属性と事業地域属性だけを開示する場合：
提携している登記型方式の仲介システムＤ２の加入者として身元保証された匿名で業種区分と事業地域のみを開示する探索者の代理であることを示す仮名の探索アカウント＝身元符号を提示して探索を求める。波及を受けた仲介システムは、その探索者の開示身元属性が図６の開示対象者のコード区分（乃至は分類対照表）に適合するかを対照表で変換して判定する。

３) 検索者が身元を全非開示にする場合：
自らが身元保証している匿名の探索者の代理として探索していることを明示して、登記型方式の仲介システムＤ２の身元符号を提示して、判定を求める。図６の例では、依頼側の仲介システムであるＤ２の身元符号が特定開示対象：6874-＊以外である場合、そのままでは開示の対象とはならない。開示交渉対象：7＊-＊・93＊-＊に該当する身元符号であれば、身元符号＝実際の身元がサマリーレコード登記者Ｒ６にＤ３から通知されて、Ｒ６自身の都度判断で可否が判定される。Ｄ２が特定の業界や地域の代表としてその傘下の探索を束ねている＝匿名になっている探索者Ｃ２がその加入資格を満たすという確証がある場合、その業界や地域の集団に対して物品追跡用サマリーレコードの特定開示対象をその代表であるＤ２の身元符号６８７４−に割り振ることで、その集団に対して一括して匿名探索を許諾することにもできる。

図８の例では、身元属性として業種（ドラッグストアーチェーン）と事業地域（千葉県）を開示しているが、この開示属性は検索許諾を判断するのに有用な項目を必要に応じて設定することができる。例えば、年商規模であったり、資本系列番号であってもよい。この具体的な拡張例を図９に示し、後段で説明する。しかしながら、開示する身元属性の部分開示が共通化されていない場合、これら属性で許諾可否のルールを設定してある程度、自動で判断させることは極めて困難となる。実情報所在の判定処理は、実際には検索者身元を全て開示させての交渉になるか、匿名を許すかのいずれかにしかならない。企業の業務機密に関わる記録を探索していることが前提であるので、匿名者に無分別に開示すると言うのは実際にはあり得ないし、そうした試みは自明として拒絶されることが当然である。しかしながら、本当の身元を開示させても、これを開示対象として事前にどうサマリーレコードに記載しておくかは、大きな困難を伴う。探索者は、サマリーレコードを登記する実情報ＤＢの設置者、乃至はそこに識別子取扱い記録を登録している実情報の所有権者と面識が無いことが当然である。この身元属性に基づく記法以外では、こうした未知の探索者をどう判定の事前に開示対象者としてサマリーレコード上に列記するのか、現実的な手段は無い。よって、実際には、最低でもこうした探索者属性を手がかりにしたクラス分け等の方法を取らない限り、所在開示の許諾は、全暴露した探索者身元を登記元にいちいち照会して、その都度、登記元が判断する以外に方法が無い。

探索における紹介状は、元来は所在パスの開示対象者に該当した探索者であることを登記型の検索仲介システムが保証するだけの仕組みで、検索許諾交渉に当たっては、身元を全開示することを余儀なくされる検索者の匿名性維持の課題の解決には役に立たない。しかしながら、ここに中継型方式の付帯機能である情報内容の開示制限のための身元属性による仕組みを利用することで、図８のような、身元属性を部分的に開示するだけで、それを元に実情報の所在パスの開示可否を、ある程度判断できる半匿名の探索とその後の許諾交渉・実検索が実行できるようになる。

ここで、もとになる中継型方式の身元属性による情報内容の開示制限の仕組みを説明する。

中継型検索仲介システムは、単に実検索式を複写して傘下の実情報ＤＢ群に配布し、それぞれの実情報ＤＢからの回答を集約して一括回答するだけでなく、この内部処理として回答内容の詳細さを改変して制限する付帯サービス、情報粒度フィルター処理（以下、粒度処理）を提供することができる。中継型検索仲介システムは、この情報の詳細さを改変する粒度処理を実現するに当たり、検索者、実情報ＤＢともに実際の身元を開示することなく、その背景属性のみを提示して、その区分のマッチングにより面識のない両者の匿名性を維持することができる。図９は、検索者の検索仲介サービスへの登録レコードであり、身元属性と身元開示方針設定指令を届け出ている例である。これをもとに図８に開示された探索時用の身元が反映されている。中継型の粒度処理には、この検索者の開示身元属性とこれに対応する実情報ＤＢが登録している実情報レコードの項目ごとに開示内容の粒度を指定する表が突合され、情報の詳細さを低減する粒度フィルター処理が実行される。

この身元の部分開示に使用する身元属性を登記型の検索仲介方式と共通化することにより、匿名性と実在の責任主体の存在を保証する仕組みが作られる。

図１０は、上記を実現する複数のシステムのハードウェア構成図である。

各ハードウェアの論理的な接続関係と識別名は、図５の構成をそのまま使用する。実情報ＤＢ群Ｒ１〜Ｒ５は、搭載ソフトウェアが異なるだけで、物理的な内部構成に差はないため、Ｒ５で代表させる。

ここに登場するシステムは、何れも標準的なＴＣＰ／ＩＰ通信で接続されたサーバー／クライアントコンピュータのハードウェア上で動作する複数のソフトウェアの同一装置内でのプロセス間連携、及び通信を介した別ハードウェアとの相互作用によって動作する。

各コンピュータは、別のシステム個体と相互作用を行うためのＴＣＰ／ＩＰ通信装置を備える。Ｃ１を除き、これ以外の装置は複数のシステム個体と、同時並行で別の領域のネットワークに接続する、あるいは同一ネットワーク上で異なる用途の通信セッションを捌く必要があるため、マルチセッションの通信機能を持つことが必須となる。Ｃ１は、時間経過ごとに作業が遷移し、その通信先は順次切り替えていくことで単一とすることも可能なため、マルチセッション通信の機能は必須ではない。しかしながら、現在のコンピュータハード構成の常識から、自ら望まずともマルチセッション機能を備える。

同じく各コンピュータは、複数通信セッションを生み出す源となる複数のソフトウェアプログラムを同時並行で内部連携させながら動作させることが必須となる。そのため、中央演算装置はプロセス間領域干渉を防ぐ機能を持つ揮発記憶装置とつながって、マルチプロセスの機能を持つことが最低限要求される。又、このプロセス間連携を実現するための内部通信装置（データバス）を備える。又、動作させるソフトウェアプログラムを定常的に格納し、通信とプロセス処理によって得たデータを永続的に保持する永続記憶装置（ハードディスク）を備える。但し、これらいずれも今日の汎用コンピュータの常識的な構成であり、特段の物ではない。但し、中継システムＱ０１、Ｄ２と実情報データベースＲ５は、汎用サーバーコンピュータとして特徴付けをしている。これは、取り扱う情報量がその他のクライアント型より格段に多く、同時動作させるプロセスと通信セッションも同種のものが並行して別の内容を取扱いながら動作することに起因している。そのため、これらサーバーコンピュータは、多数のマルチプロセス中央演算装置を搭載し、広大な揮発記憶装置を備え、かつこれらを高速に並行切替え接続するプロセス間サービスバスと呼ばれる強化された内部通信装置を備える。更に、ここで交信・処理されるデータは、全体システムの寿命のある限り維持され続け、かつ時には書換えの衝突が起きるほど頻繁に内外から読み書きされる。これを捌くため、これらサーバー系システムの永続記憶装置は、単なるハードディスク上のファイルシステムでは不十分となるため、データベース管理システムを必須とする。但し、これも汎用的なものであれば十分である。

クライアント系Ｃ１は、対人対面操作を前提に使用される。又、複数のソフトウェアプログラムを作業者が操作しながら業務を進める。そのため、マルチウィンドウ対人対話装置を備えることが望ましい。しかしながら、これは作業用ソフトウェアの作り方次第ではマルチウィンドウである必要は無い。そうであっても、現在のクライアントコンピュータは、マルチウィンドウを標準とするオペレーティングシステム付きで販売されるのが通例であるため、不要でもそうならざるを得ない。

各コンピュータは、ハードウェア要素の能力に強弱はあってもほぼ同じ構成を取るのに対して、それぞれの役割によって異なる複数のソフトウェアプログラムが搭載され、それぞれが順次、乃至は同時に連携して動作する。各ソフトウェアプログラムは、一般的なコンピュータ資源の利用方法を逸脱する物理的な動作は必要としない。前述のマルチセッション・プロセス間連携を取り仕切るＬＩＮＵＸ等の汎用オペレーティングシステムが管理するプロセススレッドとして、メモリー領域と内部通信及び永続記憶を割り当てられながら、それぞれのソフトウェアとして書かれた内部ロジックに基づいて、異なる振る舞いをする。特にサーバー系システムで動作するソフトウェアは、ひとつのソフトウェアプログラムも内部的には複数の異なる役割を果たすソフトウェアプログラム要素の複合体として構成され、それぞれのソフトウェア要素が、又同一のものが同時並行に別の内容を処理するべく動作する。更に、同種乃至は異種のソフトウェア要素が、別のソフトウェア要素の処理・通信結果を受けて、次のソフトウェア要素を起動乃至は依頼して処理を進めていく。それぞれは中央処理装置と揮発記憶装置上においてスレッドとして存在し、処理に使用する演算器や、揮発性乃至は永続（不揮発性）の記憶領域、内部乃至は外部への通信先が衝突しないよう、動作順序と範囲がオペレーティングシステムによって防御され管制される。

仲介システムＱ０１、及びＤ２は、そこで提供される高度付帯サービスを処理することを含め、膨大な通信・データ処理を担当することがある。このため、図１０中に特に「 (群) 」と表記するように、同一のソフトウェア構成を持つハードウェアを並結する、乃至はそれぞれのソフトウェアプログラムを個別のハードウェア複数に搭載して、これをあたかも１台のシステムであるかのごとく連携動作させるクラスター構成にする場合がある。異種ソフトウェアを分散させて搭載させる場合には、そのソフトウェア処理の特徴に応じて、組み付けるハードウェア装置要素の能力を異なるものにすることがある。例えば、Ｄ２で登記型探索対応ソフトウェアを担当するハードウェアは、取り扱うサマリーレコードが膨大な場合には、データベース管理システム部を複数のハードウェアに分散させるクラスター構成にすることもある。あるいは、Ｑ０１の実検索式中継・集約ソフトウェアを担当するハードウェアは、その内部の高度付帯サービスを実行するために、戻ってくる回答内容をＸＭＬのエレメント群単位に分解して、それぞれの単位について内容を計数したり書き換えたりするサブスレッドを多数起動して分担処理させる方法があり、これを効率的に実現するために、高速内部通信バスで接続されたマッシブクラスター中央演算装置と高速揮発記憶装置を備え、その性能向上には寄与しない永続記憶装置を省く構成とすることもできる。一方、回答レコードが膨大である場合には、逆に強力な分散クラスターデータベースを組み付ける場合もある。膨大な数の検索クライアントから、その何倍もの実情報ＤＢに対して中継を求められる場合には、それぞれのセッションを捌くプロセスの並列は律速にならず、通信回線へのゲートがボトルネックになる場合もある。これを解決するために、ひとつのサーバーハードウェアに複数のマルチセッション通信装置を組み付け、それぞれが接続されている広域ネットワークの帯域幅を全体で使いきるまで通信性能を強化する方法も取れる。

実情報データベースサーバーＲ５においても、膨大な実情報レコードを格納して検索させる場合には、クラスターデータベース構成を取る場合もある。本発明が克服すべき対案である登記型方式に対応した実情報データベースサーバーＲ５においては、許諾交渉とサマリーレコード自家作成のソフトウェアプログラムを搭載する必要がある。これ以外のソフトウェアプログラムは、ＥＰＣＩＳなど既存の標準検索規格が規定する動作を実現するために、市販されているものである。即ち、登記型に対応するためには、市販されていないこれらのソフトウェアをこの上に自力で構築して動作させる必要がある。

この場合いずれも、サービスバスは内部通信の範囲を越えて、ＴＣＰ／ＩＰ通信上のＸＭＬ Ｗｅｂサービス等による疎結合構成に拡張される。疎結合構成は、分散クラスターデータベースを基盤に実現されるものも市販されている。但し、このときのクラスター間のＴＣＰ／ＩＰネットワークは、広域ネットワークから分離された閉域ネットワークとされる。しかしながら、このクラスター間閉域ネットワークへは、ロードバランサーや高次レイヤースィッチを介して広域ネットワークに論理的に直接に接続している複数のハードウェアからのプロセストラフィックを流すことができる。拡張サービスバスもクラスターデータベースも現在のコンピュータ技術では常識的に広く知られたものであるため、動作の詳細説明は省く。

それぞれのハードウェアに搭載される個々のソフトウェアプログラムに固有の内部ロジックは、各機能部の内部動作として次に詳細に説明する。又、機能部乃至は外部のハードウェアとの相互のプロセス間通信は、それぞれを結ぶ連携動作として詳細に説明する。但し、データベース管理システムを基盤とする機能要素については、その動作をデータベースへの記録、検索、読み出しとしてそれを明示する。

これらハードウェアを結び付け、データ交信を実現するＴＣＰ／ＩＰネットワークは、通信先への接続を割り振るルーターの相互接続によって実現されるが、余りにも一般的なものであるので、説明を省く。広域、閉域と通信範囲の異なるネットワークは、物理的にルーターで遮断されている場合と、ＶＰＮとして仮想論理的に実現されている場合がある。前述のロードバランサーや高次レイヤースィッチもこのＴＣＰ／ＩＰネットワークの構成要素であり、各構成コンピュータ群からは透過的に意識することの無い存在である。これらも今日の通信技術の常識であるので説明しない。

図１１は、本実施形態の検索仲介システムＱ０１の全体的な構成を示すブロック図である。

この図に示されるように、本実施形態においては、以下に説明する構成要件を備えている。これらの構成要件により、中継型検索仲介システムから登記型検索仲介システムを利用させる機能などが実現されている。以下では、図中で符号及び名称で示される各構成要件について、第１の機能群である中継型機能群１００、及び第２の機能群である登記型仲介機能群２００に分けて説明する。

中継型機能群１００：中継型検索仲介システムとしての中継内部管理用の機能群
該中継型機能群１００は、以下の１０１から１１１のサブユニットから構成される。

１０１：実検索式受付部：中継型検索仲介システムの検索仲介の基本となる、実情報ＤＢと同等の実検索受付・回答インターフェイスをなす。

１０２：依頼実検索式管理部：傘下のどの実情報ＤＢ群にどの検索者からのどの実検索を依頼するかを管理する。

１０３：検索式依頼部：中継型検索仲介の基本となる、検索クライアントと同等の実検索依頼インターフェイスをなす。同期型の即答検索依頼を行う場合は、受領部１０７と同体に動作する。

１０４：検索クライアントアカウント管理部：検索者クライアントと開示身元設定を管理し、検索受付時の登録利用者照会に回答する、内部用のサブ データベース システムである。

１０５：実情報ＤＢ群管理部：登記型の仲介システムに実情報保有登記を自力で行わず、中継型サービスの代行登記の利用を依頼している実情報ＤＢ群を管理する。これも内部用のサブ データベース システムである。

１０６：課金管理ＤＢ：検索仲介料金を検索者に集計し、配分を探索先と実情報を提供した実情報ＤＢに集計する。

１０７：検索結果受領部
実情報Ｒ１、３２から検索結果を受け取る。：受領した検索回答を、開示粒度処理部１０９に依頼検索式の識別と回答元を付記して回送する。

１０８：実情報ＤＢ別開示方針ＤＢ：実情報ＤＢが登録した検索者属性別に対する回答内容の精密さ「情報粒度」に対する変更ルール群である情報粒度設定を保持する。

１０９：開示粒度処理部：回答元ごとの開示方針に基づく粒度処理ルールを開示方針ＤＢ１０８から取得し、検索者の身元開示指示に基づき、適用される粒度変換ルールに則して、回答内容を粒度変更（場合により部分削除）する。

１１０：実情報回答部：中継型検索仲介の基本となる、実情報ＤＢと同等の実検索回答インターフェイスをなす。

１１１：統合回答合併部：中継型傘下からの回答と、代行登記型探索から代行検索した、登記型傘下からの外部調達回答を、１本の実情報ＤＢからの回答と同形式に合併し、実情報回答部１１０に回送する。

登記型仲介機能群２００：登記型互換としての探索用の機能群
該登記型仲介機能群２００は、以下の２０１から２０４のサブユニットから構成される。なお、登記型仲介機能群２００は、本発明の登記型仲介機能部に相当するものであり、検索者から委託された実検索式に基づいて、実検索を代行実施するものである。

２０１：サマリーキー作成部：実検索式から、登記型方式規約が定める特定項目「サマリーキー」対象項目を抽出したサマリーキーを作成する。

２０２：登記型 実情報所在探索部：提携関係にある登記型の仲介システムＤ２他に対して所在探索を掛ける。

２０３：代行実情報取得部：登記型探索で探知した所在アクセスパスに対して、指示された開示身元属性で検索許諾交渉をする。
検索許諾が得られた場合、実情報検索実行する。

２０４：外部費用決済部：登記型仲介システムＤ２がまとめて請求してくる、提携探索の費用、及び有償で実情報を提供した実情報Ｒ５他からの実情報提供費用を処理する。

図１２は、中継型検索仲介システムＱ０１が、Ｃ１からの登記型サービス領域へ波及する検索仲介の指示を実行するシステム間の連携フロー図である。図中のＰ＊（＊は該当する数字））で表示された連携パスは、図５の説明で述べた第＊動作処理の説明見出しＰ＊の番号に対応する。全体的な動作は、図５の説明で述べているので、検索者が登録している開示身元設定が代行検索に反映される過程を、図１２の中央、検索クライアントアカウント管理部１０４の動作として説明する。図９の検索クライアント・アカウント・テーブルには、身元属性として、一般的な企業名称や業種、所在地などの身元属性が登録され、又、探索時と、実検索時の業種別の身元開示指示、及び、探索時の仲介ホップ数、登記型の仲介サービスへの波及の可否について、指示も登録されている。ここでは、更に、登記型方式の領域へ検索仲介範囲を拡大する臨時の指示項目をもつ実検索式図１３も使用して、その動作を説明する。

第１動作ステップＳ１：開示範囲設定票登録
図５の説明の第１動作処理Ｐ１の一部として、検索クライアントＣ１は、アカウント管理部１０４に、探索時と、検索時の検索対象実情報ＤＢの背景属性ごとに、自身の身元を実名で全開示する、乃至は属性としてどの項目を開示するか、しないかを設定する図９の１レコードである身元開示設定票を登録する。

第２動作ステップＳ２：依頼者判別
検索クライアントＣ１が第３動作処理Ｐ３として中継型仲介群１００に実検索式を送信してきた場合、アカウント管理部１０４にアカウント識別子を紹介して、正規の検索者であることを認証する。このときアカウント管理部１０４は、登録されている身元開示方針設定指令票を照会回答として戻す。この元開示方針設定指令票は、中継型検索仲介の付帯サービスである、中継型傘下の実情報ＤＢ群Ｒ１・Ｒ２からの開示内容の制限処理の判定に利用される。

第３動作ステップＳ３：登記型探索・代行検索用の身元設定
中継型機能群１００に依頼された中継型一斉検索が、登記型への波及検索を臨時に指示した実検索式であると図１３の「登記波及：あり」と表記された部分から判断された場合、乃至は図９の検索者が登録している身元開示方針設定指令票の「波及方針」が「登記型に＊ホップ」と指定している場合、第４動作処理Ｐ４が発動され、実検索式を受け取ったサマリーキー作成部２０１は、登記型仲介群２００全体としてアカウント管理部１０４に図９の１レコードである、探索時と許諾交渉時、及び実検索時に検索者Ｃが開示する身元開示方針設定指令票を請求する。サマリーキー作成部２０１は、図１３の実検索式とる図９の身元開示方針設定指令票から、図１５の登記型探索用のサマリーキーを代行作成する。この代行作成されたサマリーキーを使用して、実情報所在探索部２０２は第４動作処理Ｐ４’の代行探索と、第７動作処理Ｐ７の許諾交渉を代行する。

ここで、本実施形態におけるホップ数制御について説明する。

図９の検索クライアント・アカウント・テーブルは探索時の仲介ホップ数の項目を持っている。これは、図１や図５の波及探索の形態では、提携先の検索仲介システムが１層だけであるのに対して、図１４に示すように、提携先の検索仲介システムが他所との提携関係を持つときに、直接の提携先のその提携先にも探索範囲を広げる再委託探索をすることもできる。ここで、仲介ホップ数とは、直接に加入している仲介サービスと提携している外部の仲介サービスを１次、２次と提携先に探索範囲を広げる仲介の段数を意味する。

ホップ数１であっても、直接加入している中継型の仲介サービスが５つの他所の仲介サービスと探索提携している場合は、これら全ての提携先に所在探索乃至は検索式中継が実行され、それぞれの仲介サービスに加盟している実情報ＤＢの所在アクセスパス、乃至は中継回答が直接加入先の中継サービスに収集されることになる。

ホップ数２以上の場合は、これら直接の提携先を越えて、提携先が更に提携している、又、別（場合によっては重複した）仲介サービスに対しても探索乃至は中継検索が実行され、それぞれの提携先に結果が収集され、最終的には直接加入先の仲介サービスに回収されて、探索乃至は中継検索が完了する。

ホップ数が少なくても、提携先が多ければ、探索や中継の範囲は乗数で広がり、ヒットする探知先や実データが膨大な量におよび、多額の仲介費用が発生する場合も起き得る。実はこの有償仲介のための課金の仕組みが登記型方式との互換機能を持つ中継型仲介サービスの重要な保障機能となっている。中継型はＤｏＳ攻撃や不正検索の温床になるとの指摘がされている。しかしながら、こうした過剰な探索・検索波及を意図した場合、検索者は、甚大な費用請求を受ける定めから逃れることはできないため、よほどの事情がない限り、そうした無謀な探索・検索は経済的に抑止される。

登記型の探索を含めた仲介を依頼する場合、実検索式からサマリーキーを代行作成させ、提携先の登記型探索の経費を負担し、検索許諾交渉を代行するための負荷費用も発生させることになる。こうした負担を減らしたい場合を考慮すると、無用に登記型の探索を行わせることは抑制したい場合がある。

ここで、図９の例では、登記型への波及探索と代行検索を依頼するか否かを「波及方針」の項目によりデフォルトの条件として登録するようにしている。この波及探索は、探索処理の依頼を受けたデータベースが、他のデータベースに対して該探索処理を依頼するように送信することで、該探索処理を他のデータベースに波及させてゆくものであり、実情報所在探索部２０２を中心にして行なわれる。又、このような探索処理の波及が、複数のデータベースにおいて、多数段に及ぶ場合もある（多段波及の探索動作）。この探索処理の波及は、提携先のデータベースに対して行なわれることになる。

ここで、このように探索処理をデータベースに対して波及させる際、そのデータベースの実情報所在探索部２０２は、自らが受けたサマリーキー中のホップ数を１つ減じて、探索処理を波及させるデータベースに送信するサマリーキー中に転記する。なお、図９において、「波及方針」の項が「単一参加のみ」となっている検索者アカウントの場合、上記のような波及探索は行なわない（ゼロホップとなりホップなし）。

一方、前記の事前登録による波及制御を行うが、検索の事情によっては、登記型傘下にも対象を広げる、ホップ数を増やすなど、より広範な実情報収集を行わざるを得ない、乃至は逆にある程度目星が付いていて、デフォルトより探索・検索対象先を絞ることも行いたい。そのために、デフォルト設定を臨時に覆す指示データを図１３のように実検索式に含めることにより、臨時に波及をコントロールすることができる。

この波及指示についての追加項目は、中継乃至は代行検索される対象の実情報ＤＢ群には無用で、規定のスキーマ上、解釈できない項目になるため、依頼実検索式管理部１０２が中継を行う際、及び代行実情報取得部２０３が代行検索を実施する際には、これらの項目は制御に利用した後、これらの項目だけが除去されて中継乃至は代行検索に使用される。

図５の説明を拡張する方法で図１４の波及探索の動作を説明する。説明には、多段仲介のホップ数制御を指定する項目を拡張した探索用サマリーキーの例となる、図１５に示されるものを使用する。各ステップ番号は図４の連携パスの番号に一致し、同種の動作が別の相手に行われる場合には「ａ」、「ｂ」などを付記して拡張している。

第４動作処理（第４ステップ）：図９のデフォルトの指示乃至は第３ステップの依頼に、２次乃至はそれ以降の他所の登記型仲介サービスまで波及させる指示がある場合、Ｑ０１は、図中丸番号“４”で示す登記型への提携探索に、指示されたホップ数から１を減じたホップ数を初期値として記載した図１５のサマリーキーをＤ２に送信し、自己と提携先に登記されている該当実情報の所在パスの回答を求める。

第４ａステップ：Ｄ２は提携関係にあるＤ３及びその他に受託した実情報サマリーキーを複写再委託し、自己が受けたホップ数から１を減じたホップ数を添えて、それぞれに登記されている実情報の所在パスの回答を求める。

第４‘ｂステップ：再委託されたＤ３は、第４ａステップの再委託の波及ホップ数に達する、即ち、再委託先が受け取るホップ数が０になるまで同様に提携関係にある登記ＤＢに再委託を繰り返させる（図中は省略）。

第５動作処理（第４ｂステップの応答）：指定ホップ数に達した最深の段にある登記ＤＢから順に、それぞれが登記されている該当実情報を検索し、登記されているそれぞれの実情報の開示方針に合致する依頼である場合、保有する実情報保有ＤＢへのアクセスパスをそれぞれの委託元に回答し、登記簿利用料を請求する。

（第４ａステップの応答）：再委託先から回答を受け取った登記ＤＢは、複数の回答元からと自己の保有する登記元Ｒ４を名寄せして、必要に応じて重複を解消し、上段の深度にある依頼元登記ＤＢに回答し、下位の請求に自己の登記簿利用料を加えて請求する。

（第４ステップの応答）：Ｑ０１から依頼を受けたＤ２は、再委託先からの回答と自己のＲ４の登記を合併して重複を解消し、Ｑ０１に回答し、下位の請求に自己の登記簿利用料を加えて請求する。

第７動作処理（第５ステップ）：Ｑ０１は第４ステップの結果として取得したＲ４、Ｒ６へのアクセスパスを使用し、検索者Ｃ１が指定している開示身元を提示して検索許諾交渉を試み、許諾された場合にはＲ４、Ｒ６の検索アカウントを取得する。あわせてＲ１への検索式中継を実行する。

以上に説明したように、本実施形態によれば、中継型検索仲介システムでありながら、登記型検索仲介システムと連携し、単体としては在来型の中継型検索仲介システムにだけ対応した検索クライアントからの一斉検索依頼に回答するために、中継型検索仲介システムのサーバーは、他所の登記型検索仲介システムに対して、検索対象情報を保有する未知の実情報ＤＢの所在を代行問い合わせすることができる。又、該問い合わせに対して回答されたものの内、自身が検索受付窓口を委託されていなかった他所の実情報ＤＢに対して、接続交渉を行った上で、実検索を代行することができる。更に、検索式中継型の検索仲介サーバー自身が情報検索の代行窓口となっている、それぞれの実情報ＤＢからの検索結果を合併した検索結果を、検索クライアントに回答するとともに、累積された登記簿利用料と実検索実施費用を合算して一括請求することができる。

Ｃ…検索者（クライアント）
Ｑ…中継型検索仲介システム
Ｄ…登記型検索仲介システム
Ｒ、１〜８…実情報データベース（ＤＢ）
Ｃ１…在来型検索クライアント（自己での登記型探索機能を有しない）

Claims (7)

1. 開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、
   ネットワークを介して、実情報ＤＢから回答を集める検索結果受領部と、
   検索者の開示身元に応じて、各ＤＢ指定の粒度処理を該回答に対して行う開示粒度処理部と、
   検索者から委託された実検索式に基づいて、実検索を代行実施する登記型仲介機能部と、
   を具備し、検索者から実情報ＤＢに対する検索を中継する機能を備えると共に、
   登記型から探査した実情報保有ＤＢ群に対して、検索者開示身元に基づき検索許諾交渉を行い、実検索を代行実施する代行実情報取得部を、前記登記型仲介機能部において備えたことを特徴とする検索仲介システム。
2. 検索者から委託された実検索式から、登記型仲介サービスを利用するためのサマリーキーを作成するサマリーキー作成部と、
   検索者の開示身元に基づいて、検索する実情報が所在する実情報保有ＤＢを探索する実情報所在探索部とを、前記登記型仲介機能部において備えたことを特徴とする請求項１に記載の検索仲介システム。
3. 前記ネットワークに接続する中継型検索仲介システムのサーバーからの粒度処理済み回答、及び、前記ネットワークに接続する登記型検索仲介システムのサーバーから前記登記型仲介機能部により代行取得した回答を合併する統合回答合併部と、
   該回答に基づいて、実検索結果として一括回答する実情報回答部と、を備えたことを特徴とする請求項１又は請求項２に記載の検索仲介システム。
4. 中継型の情報提供料、及び、代行仲介・回答取得処理に要した費用を検索者アカウントごとに集計する課金管理ＤＢと、
   該課金管理ＤＢに対する集計、及び精算に関する処理を行なう検索クライアントアカウント管理部と、を備えたことを特徴とする請求項１乃至請求項３のいずれか１つに記載の検索仲介システム。
5. 開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、
   利用者端末からの実検索式を含む実検索要求を受け付ける実検索式受付部と、
   傘下の実情報データベースに対して前記実検索式により検索をかける検索式依頼部と、
   検索結果を取得する検索結果受領部と、
   受けつけた前記実検索式からサマリーキーを作成するサマリーキー作成部と、
   作成した前記サマリーキーに基づき外部の登記型検索仲介機に所在探索を行う実情報所在探索部と、
   前記登記型検索仲介機に実情報検索を依頼し、検索結果を取得する代行実情報取得部と、
   実検索依頼部が取得した検索結果と代行実情報取得部が取得した検索結果を統合して実情報回答を作成する統合回答合併部と、
   実情報回答を利用者端末に送付する実情報回答部と、
   を具備することを特徴とする検索仲介システム。
6. 前記実情報所在探索部が、多段波及の探索動作を行なうものであって、提携先のデータ
   ベースへ前記サマリーキーを送信するときは、自らが受けた該サマリーキー中のホップ数を１つ減じて転記することを特徴とする請求項１乃至請求項５のいずれか１つに記載の検索仲介システム。
7. 請求項１乃至請求項６のいずれか１つに記載の検索仲介システムとして、コンピュータを機能させるソフトウエアプログラム。

Images