JP5434181B2

JP5434181B2 - 検索仲介システム

Info

Publication number: JP5434181B2
Application number: JP2009071004A
Authority: JP
Inventors: 憲朗伊藤; 昌宏川口; 一樹加藤; 秋奈横田
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2009-03-23
Filing date: 2009-03-23
Publication date: 2014-03-05
Anticipated expiration: 2029-03-23
Also published as: JP2010224840A

Description

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

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

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

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

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

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

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

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

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

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

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

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

この図１に例示される登記型方式は、保有する実情報の各レコードに対して、仲介サービス規格に基づく限定的な検索キー「サマリーキー」によって該当するレコード群の所在のみを回答する「サマリーレコード」を実情報ＤＢ側で自己作成し、仲介システムの登記簿に登録させることを基本構成としている。

「サマリーキー」と「サマリーレコード」については、先例があるがまだ標準規格として制定されているものが無いため、この概念を実現するに足る想定例を後述する。又、サマリーレコードとサマリーキーを実記録レコードや実検索式から作成する方法についても、まだ何の方法も規定としては示されていない。このため、以下では、概念が成立することを示すために、実在する検索規格“ＥＰＣＩＳ”を参考にした仮想例を取り扱う。

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

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

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

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

ここで、図１のステップに沿って、図２において、提携探索の流れを説明する。所在探索の回答ステップ３と、実検索の回答ステップ５は、簡略化のため省略する。

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

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

第３ステップ：間接探索を受けたＤＢ２３は、傘下のＤＢ３７が該当の実情報を保有していることを回答する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明は、中継型検索仲介システムの傘下にいる実情報ＤＢが改修負荷無しに、普及で先行している登記型の検索仲介方式としての所在探索に互換対応させることを実現する検索仲介システムを提供することを課題とする。更に、中継型の弱点とされる無効検索式の拡散をも低減させることを課題とする。

本発明は、開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、利用者端末の検索に供するデータベース情報の登記簿に、実情報ＤＢ側から検索対象の情報の登記代行の依頼を受け、この処理を行う代行受託実情報ＤＢ群管理部と、仲介対象である実情報データベースが保有する情報の要約を登録する登記簿と、上記登記簿に登録する情報を生成する手段と、登記型方式の探索依頼に対して、前記登記簿を参照して所在回答を行う登記型探索対応部と、登記型方式の実検索依頼を受付け、前記実情報データベースの検索結果を回答する実検索式受付回答部と、上記実検索式受付回答部の中継依頼に応じて、前記実情報データベースを検索し検索結果を取得する中継処理部と、を具備し、前記登記型探索対応部は、実際に回答される探索事後の実情報の検索許諾交渉先、及びその後の実検索先は、前記実情報データベースへのアクセスパスではなく、検索仲介システム自身へのアクセスパスとするようにしたことにより、前記課題を解決したものである。

又、仲介型の付帯機能として、最初から完全非開示か否かを判定するための開示方針設定票の情報を保存する実情報ＤＢ別開示方針ＤＢと、前記実情報ＤＢ別開示方針ＤＢの前記開示方針設定票を検索して、最初から完全非開示か否かを判定する依頼実検索式管理部と、を更に具備したものである。

更に、登記型方式の実検索許諾依頼に対して、依頼者の開示身元が検索者アカウント要件ポリシーに合致するか否かの判定に基づき許諾（拒絶）通知を行うアカウント管理部を具備する。

又、中継型検索仲介を行う傘下の実データベースに対する検索に際し、検索者の開示身元属性と各実情報ＤＢが登録した対象区分に基づいた粒度フィルタ処理を行う粒度処理部を、更に具備することができる。

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

本願発明によれば、中継型検索仲介システムでありながら、異方式の登記型検索仲介システムとしての問い合わせに対応し、加盟する実情報ＤＢを改修させずに登記型に間接的に対応させることができる。又、実情報保有ＤＢの標準規格である常置検索機能を利用して、常置検索式を作成して常置依頼し、初回回答から登記型の実情報保有登記簿を代行作成するとともに、更新情報のみを仲介システムが適時取得し、新回答から更新データを作成して登記簿を維持する加盟ＤＢ登記簿管理を行うことができる。更に、中継型検索仲介システムの代行情報粒度フィルター用の検索者類別に基づく、登記型における開示対象者制限を自動実行することも可能である。又、実情報を保有するＤＢへのアクセスパスだけを回答されて事後に度重なるアクセス交渉が必至となる登記型に対して、これが不要で、情報管理にも利点のある中継型検索仲介システムでありながら、登記型の問い合わせや相互融通に対応でき、且つ、加盟するＤＢ群に在来の標準検索のための仕様のまま改修の負担を求めずに登記型に参加できる機能を提供することができる。

このような付帯サービスが無ければ、登記型に加盟するためには、実情報ＤＢは、以上のような電文による検索許諾交渉に自力で対応し、動的に許諾管理を行う機能を自ら実装する改修を施すことが必須となる。

裸の登記型方式においては、この紹介状に記載された個別のサマリーキーについての所在開示の結果、実情報ＤＢの所在が暴露され、実検索を許諾しなかったとしても、紹介状に提示されたサマリーキー対象事物に関する実情を保持している＝当該物品の（取扱）当事者であることが露見してしまう。露見した実情報保有者をその事業特性ごとに突き合わせると、ある特定定商品の流通状況がほぼ完全に解明できることは明らかである。これにより、探索者が（公正取引上の不当行為として）上流や下流と推定される取引先にその商材の取引に関する圧力を掛けるなど、事業存続の危機を招き兼ねない事態の懸念も現実化する。これに対して、実情報ＤＢは、中継型の傘下に入り、実検索の受付を仲介システムに負わせて裏に隠れることで、この懸念から完全に開放され得る。この点からも、例え登記型の所在探索・検索仲介方式が主流として普及していたとしても、実情報ＤＢは中継型のサービスに加盟する重大な理由が残る。

実情報保有登記型の検索仲介方式における検索者、検索仲介システム、及び実情報ＤＢの関係を示す概念図登記型方式での仲介システムの提携による探索波及の概要ブロック図検索式中継・回答集約型の検索仲介方式における検索者、検索仲介システム、及び実情報ＤＢの関係を示す概念図本発明における、検索式中継・回答集約方式をもとにした登記型方式への代行登記による互換作用の基本概念図登記型方式から中継型方式の領域を利用させる仕組みの概要と、異方式の仲介システム間の提携による探索波及の概要のブロック図本発明における互換機能を実現するハードウェア構成図本発明を実現する中継システムの全体的な機能構成を示すブロック図上記実施形態におけるサマリーレコード代行作成過程の概要を示すフローチャート本発明における中継システムが、登記型の所在探索に回答する機能連携チャート本発明における中継システムが、代理検索先として実検索許諾交渉を処理する機能連携チャート本発明における中継システムが、代理検索先として実検索を中継し、回答を集約して応答する機能連携チャート登記型仲介用のサマリーレコードとサマリーキーの仮想例を示す線図実情報保有登記型方式におけるサマリーキー仮想例と実検索式・結果を示す線図探索者開示身元を制限した提携探索に利用できるサマリーキーの線図粒度フィルター設定利用の機能ブロック図開示方針ＤＢ３０５の開示方針設定票管理テーブル利用記録項目別の開示粒度処理規則を示す線図検索者クラス別の利用記録項目の開示粒度設定票を示す線図検索者/実情報ＤＢ開設者間での身元開示方針対応表を示す線図検索者の身元属性と実情報ＤＢ開設者属性に対する開示方針を示す線図内容開示交渉条件を付記した識別子取扱記録への実検索式を示す線図検索許諾交渉の代行窓口の開示判定結果を記録した所在応答履歴簿を示す線図第６実施形態における登記型仲介システムが発行するアクセスパス回答とその電子紹介状部分の線図自動検索許諾交渉に使用する身元状部を含む紹介状例登記型傘下に中継型が加盟する連携形態を示すブロック図

図４は、図３で説明した中継型方式を基礎にして、登記型仲介方式にも互換させる代行登記を行う中継・集約方式の概念を示すフローチャートである。

本実施形態では、元来は図３の検索式を中継し各回答を集約する中継型検索仲介システムＩが、システム情報を保有する登記型検索仲介システムと同等に振る舞うための仕組みを備えている。

登記型検索仲介システムは、従来技術として別分野で既に普及しており、容易に実情報の所在探査に利用できるとされ、ＥＵＢＲＩＤＧＥプロジェクト内など先行実施事例もある。これが現在と当分は多数派を占めていたとしても、以下の中継型検索仲介システムＩからの互換方式を提供することにより、実情報データベースＲが中継型検索仲介システムＩの基本メリットと高度な付帯サービスを享受しながら、登記型検索仲介システムＩに参加している検索者Ｃに対しても、この先は中継型傘下の実情報データベースＲが保有する情報資源をも検索中継によって利用できるようにすることができる。

この図において、「１」「１．１」〜「６」は、以下に説明する第１〜第６動作処理を示す。図４及び以下の括弧書き内の記述は、同じく中継型の本質では無いが、その特徴であるより高度な付帯処理について一括して述べたものである。

第１動作処理：中継型検索仲介システムＩにのみ対応した実情報保有ＤＢが、所在アクセスパスと実情報の開示対象者（と粒度限度）を仲介システムＩに登録する。この第１動作処理は、次の第１.１動作処理及び第１.２動作処理を含む。

第１.１動作処理：仲介システムＩが、実情報データベースＲの保有記録の変化差分を検知するよう依頼する。

第１.２動作処理：実情報データベースＲは、前回の通知からの記録差分を通知して、仲介システムＩに保有登記と供与公表を代行させる。

第２動作処理：登記型検索仲介システムＩの検索者Ｃが、身元（と開示範囲）を登記型検索仲介システムＩに登録する。この第２動作処理は、次の第２.１動作処理及び第２.２動作処理を含む。

第２.１動作処理：登記型の検索者Ｃが、関心のある物品所在・取扱い実情報の保有ＤＢを、登記型検索仲介システムＩに「保有先探索」として問い合わせる。

第２.２動作処理：仲介システムＩは、代行登記簿に該当があり、開示条件に適合する場合に、仲介システムＩ自身を保有先として、検索者Ｃに実検索受付の代行表明を回答する。

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

第４動作処理：仲介システムＩは、（代行登記簿に該当があり）開示対象に該当する実情報データベースＲに検索式を複写して配布する。

図５に基づいて、本実施形態において、登記型検索仲介システムＤＢ２２から見た中継型検索仲介システムＤＢ２１との相互連携と互換実現の概要について説明する。

登記型検索仲介システムが先行して普及しているネットワーク環境下において、中継型検索仲介システムＤＢ２１が登記型探索対応部２００を備えることにより、登記型検索仲介システムＤＢ２２と同等の登記簿照会の機能を有するように見せる。

以下、図５の概要機能ブロックの連携作用を説明する。

第０動作処理：登記対象実情報の常置検索取得
中継型ＤＢ２１は、本発明の構成要素である代行登記機能部３００を動作させて、サマリーレコードを新規／訂正／方針変更として代行登記するための、図中丸番号“０”で示す常置検索を参加の実情報ＤＢ３１、３２に依頼し、該当する実情報レコードが定常的に報告が上がって来る。

第１動作処理：サマリーレコード代行作成と代行登記
図中丸番号“１”ａに示すように、代行登記機能部３００で取得した新規／訂正／方針変更登記の対象となる実情報から当該サマリーレコードを作成し、代行登記を実行するよう、自己の登記型探索対応部２００に対して依頼する。登記型探索対応部２００は、これを実行し、登記型としての探索に備える。

第２動作処理：登記型探索の開始と仲介システム間提携による探索の波及
検索クライアントＱＣ１２は、自己が加入する登記型中継システムＤＢ２２に、図中丸番号“２”で示すように所在探索を依頼する。ＤＢ２２は自己の傘下の実情報ＤＢ３６、３７の登記簿を検索するとともに、提携関係にあるＤＢ２１に対して、図中丸番号“２”ａで示すように波及探索を依頼する。ＤＢ２１は、登記型の探索を登記型探索対応部２００で受け、自己準備したサマリーレコードを検索して該当するＤＢ３１、３２を抽出する。しかしながら、ＤＢ２１は、ＤＢ２２とは異なり、ＤＢ３１、３２へのアクセスパスではなく、その検索代理窓口としてのＤＢ２１自身のアカウント管理部１０２への許諾交渉パスを唯一のものとして回答する。実情報ＤＢ３１、３２への直接の許諾交渉アクセスパスはＱＣ１２へは秘匿される。

第３動作処理：実検索への許諾交渉
検索クライアントＱＣ１２は、図中丸番号“３”で示すように、ＤＢ２２が紹介した実情報ＤＢ３７に対して検索許諾交渉を試み、検索アカウントを取得する（一方的に拒絶される場合もあり、その場合は図中丸番号“４”で示す処理の実検索は不可能となる）。検索クライアントＱＣ１２は、図中丸番号“３”ａで示すように、ＤＢ２２が間接的に紹介した中継型検索仲介システムＤＢ２１のアカウント管理部１０２に対しても検索許諾交渉を試みる。後述の理由により、ＤＢ２１は緩やかな審査でＤＢ２１の実検索受付部１０１への検索アカウントを発給する。

第４動作処理：実検索の実現
検索クライアントＱＣ１２は、図中丸番号“３”で示す処理が成功した場合のみ、実情報ＤＢ３７に対して図中丸番号“４”で示す処理の実検索を試み、元来、求めていた実情報レコードを取得する（ＤＢ３７の恣意で空文が回答される場合もある）。検索クライアントＱＣ１２は、許諾を得た中継型検索仲介システムＤＢ２１の実検索式受付回答部１０１に対して図中丸数字“４”ａで示す処理の実検索を試みる。ＤＢ２１は、中継型本来の動作として、実検索式受付回答部１０１で受けた実検索式をＤＢ３１、３２に、上記の丸番号“４”ａで示す処理として中継し、それぞれの回答を（それぞれの実情報ＤＢが指定する程度で内容制限を施して、）集約し、一括で実検索式受付回答部１０１から検索クライアントＱＣ１２に回答する。

これにより、中継型検索仲介システムＤＢ２１傘下の実情報データベースＤＢ３１、３２は、登記型検索者ＱＣ１２に対しても実情報を提供する機会が得られる。逆に、登記型検索者ＱＣ１２は、中継型検索仲介システムＤＢ２１傘下にある実情報データベースＲからも所望の実情報を取得することができる。双方いずれも、それぞれの探査・検索方式にだけ対応しておればよく、互換方式を利用していることを意識する必要は無い。

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

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

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

同じく各コンピュータは、複数通信セッションを生み出す源となる複数のソフトウェアプログラムを同時並行で内部連携させながら動作させることが必須となる。そのため、中央演算装置はプロセス間領域干渉を防ぐ機能を持つ揮発記憶装置とつながって、マルチプロセスの機能を持つことが最低限要求される。又、このプロセス間連携を実現するための内部通信装置（データバス）が必要である。又、動作させるソフトウェアプログラムを定常的に格納し、通信とプロセス処理によって得たデータを永続的に保持する永続記憶装置（ハードディスク）が必要である。但し、これらいずれも今日の汎用コンピュータの常識的な構成であり、特段の物ではない。

なお、中継システムＩ０１（ＤＢ２１）と実情報ＤＢ３１は、汎用サーバーコンピュータとして特徴付けをしている。これは、取り扱う情報量がその他のクライアント型より格段に多く、同時動作させるプロセスと通信セッションも同種のものが並行して別の内容を取扱いながら動作することに起因している。そのため、これらサーバーコンピュータは、多数のマルチプロセス中央演算装置を搭載し、広大な揮発記憶装置を備え、且つ、これらを高速に並行切替え接続するプロセス間サービスバスと呼ばれる強化された内部通信装置を備える。更に、ここで交信・処理されるデータは、全体システムの寿命のある限り維持され続け、且つ、時には書換えの衝突が起きるほど頻繁に内外から読み書きされる。これを処理するため、これらサーバー系システムの永続記憶装置は、単なるハードディスク上のファイルシステムでは不十分となるため、データベース管理システムを必須とする。但し、これも汎用的なものであれば十分である。

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

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

仲介システムＩ０１（ＤＢ２１）は、そこで提供される高度付帯サービスを処理することを含め、膨大な通信・データ処理を担当することがある。このため、図６において、特に「 (群) 」と表記するように、同一のソフトウェア構成を持つハードウェアを並結する、乃至はそれぞれのソフトウェアプログラムを個別のハードウェア複数に搭載して、これをあたかも１台のシステムであるかのごとく連携動作させるクラスター構成にする場合がある。

異種ソフトウェアを分散させて搭載させる場合には、そのソフトウェア処理の特徴に応じて、組み付けるハードウェア装置要素の能力を異なるものにすることがある。例えば、登記型探索対応ソフトウェアを担当するハードウェアは、取り扱うサマリーレコードが膨大な場合には、データベース管理システム部やデータベース管理システムを、複数のハードウェアに分散させるクラスター構成にすることもある。

あるいは、実検索式中継・集約ソフトウェアを担当するハードウェアは、その内部の高度付帯サービスを実行するために、戻ってくる回答内容をＸＭＬのエレメント群単位に分解して、それぞれの単位について内容を計数したり書き換えたりするサブスレッドを多数起動して分担処理させる方法があり、これを効率的に実現するために、高速内部通信バスで接続されたマッシブクラスター中央演算装置と高速揮発記憶装置を備え、その性能向上には寄与しない永続記憶装置を省く構成とすることもできる。

一方、回答レコードが膨大である場合には、逆に強力な分散クラスターデータベースを組み付ける場合もある。膨大な数の検索クライアントから、その何倍もの実情報ＤＢに対して中継を求められる場合には、それぞれのセッションを処理するプロセスの並列は律速にならず、通信回線へのゲートがボトルネックになる場合もある。これを解決するために、ひとつのサーバーハードウェアに複数のマルチセッション通信装置を組み付け、それぞれが接続されている広域ネットワークの帯域幅を全体で使いきるまで通信性能を強化する方法も取られる。

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

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

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

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

図７は、本発明が適用された検索仲介システムの全体的な構成を示すブロック図である。

この図に示されるように、本実施形態においては、以下に説明する構成要件を備えている。これらの構成要件により、代行登記を実行する機能などが実現されている。以下では、図中で符号及び名称で示される各構成要件について説明する。

第１機能群(クライアント管理部)：中継型仲介システムＩ０１としてのクライアント管理用の機能部
１０１：実検索式受付回答部
中継型検索仲介システムの検索仲介の基本となる、実情報ＤＢと同等の実検索受付・回答インターフェイスをなす。

１０２：検索クライアントアカウント管理部
探索者からの許諾交渉の窓口となり、紹介状を審査して実検索者としての加入登録を受付ける。

第２機能群（登記型探索対応部）：登記型互換の仲介システムＤＢ２１としての探索対応用の機能部
２００：情報保有登記型・互換機能部
図５の登記型側の仲介システム２２と検索者ＱＣ１２から見た同類の仲介システムＤＢ２１に見える役割を担う。実際には仲介システムＩ０１の一部分のインターフェイスであり、単体としては存在しない。

２０１：登記型・所在探査対応部
登記型の仲介システム２２と検索者ＱＣ１２からの所在探索に応対する。

２０２：情報保有登記型・互換ＤＢ(登記簿)
代行登記したサマリーレコードを保持し、所在探索に対して該当登記の有無と内容を回答する。

第３機能群(代行登記機能部)：登記型互換の仲介システムＤＢ２１としてのサマリーレコード代行作成の機能部
３０１：代行受託実情報ＤＢ群管理部
登記型検索仲介システムに実情報保有登記を自力で行わず、中継型検索仲介システムのサービスの代行登記の利用を依頼している実情報ＤＢ群を管理する。

３０２：常置検索式生成部
実情報ＤＢ管理部３０１の指示を受け、代行先ＤＢの新規追加/更新記録を定期／適時に報告させる常置検索式を作成する。

３０３：サマリーレコード作成部
登記型サービスの規約が要求する特定項目「サマリーキー」対象項目を抽出したサマリーレコードを作成する。
登記型互換ＤＢ２０２にサマリーレコードを実情報ＤＢに代わって登記する。

３０４：実情報所在応答履歴ＤＢ
どこの探索者にどこの実情報ＤＢの登記についていつ回答したか拒否したか記録した「所在探索処置報告」と、これに付記される「紹介状」の識別子を保持する。

第４機能群（中継処理部）：中継・集約型のとしての実情報ＤＢ群に対する検索式中継・集約の機能部
４０１：依頼実検索式管理部
傘下のどの実情報ＤＢ群にどの検索者からのどの実検索を依頼するか、どの実情報ＤＢからのどの検索式への回答かを管理する。

４０２：検索式依頼部
中継型検索仲介システムの検索仲介の基本となる、検索クライアントと同等の実検索依頼・回答受け取りインターフェイスをなす。同期型の即答検索依頼を行う場合は、受領部４０３と同体に動作する。
傘下の実情報ＤＢ３１に許諾されている仲介システム自身のアカウントで実情報ＤＢ３１へ実検索を依頼する。

４０３：検索結果受領部
実情報ＤＢ３１等から、常置検索による非同期通信で検索結果を受け取る。

図８は、図７におけるサマリーレコードの代行作成・登記の処理の流れを概説したものである。第３機能群と第４機能群が前後してその各機能部が順次動作することにより実現されるが、交信の相手となる実情報ＤＢ３１とその実情報登録クライアントである識別子利用システム４１の内部機能構成を図７では省略しているため、機能群単位で概略を図示している。

以下、図７の個別機能部が連携する状況を追記して、流れを詳細に説明する。

図８から図１１の全ての外部通信は、ＡＳ２乃至はｅｂＸＭＬＭｅｓｓａｇｉｎｇＳｅｒｖｉｃｅに代表されるＴＣＰ／ＩＰ上でのＨＴＴＰ−ＰＯＳＴによるＸＭＬデータ送付を規定するプロトコルによって実現される。これ以外の通信方法でも実現可能である。内部通信は、図６で説明した疎結合拡張を含むサービスバスで交信される。

１．識別子利用システム５０による記録作成とＤＢ３１への記録登録
１）識別子取扱業務の設定
識別子利用記録手段５２は、取扱業務の背景情報を取得／設定し、利用記録への転記に備える。

２）識別子取扱業務記録の作成
識別子読取装置５１が識別子の出現を通知し、識別子利用記録手段５２は、業務背景情報を付記した識別子取扱記録を作成する。

３）識別子取扱記録の登録
識別子利用記録手段５２は、記録の登録・維持・利用を担当するＤＢ３１に識別子取扱記録を送付する。

２．ＤＢ３１から仲介システムＩ０１への検索中継委託と、サマリーレコード代行登録
１）検索仲介委託の申込み
ＤＢ３１は、代行受託実情報ＤＢ群管理部３０１に対して、仲介の対象を指定した開示指示票を添えて、検索仲介の委託を申し込む。代行受託実情報ＤＢ群管理部３０１は、情報保有登記型互換ＤＢ２０２に対して、ＤＢ３１分のサマリーレコードアカウントを作成するよう指示する。

２）サマリーレコード代行作成用常置検索発行
代行受託実情報ＤＢ群管理部３０１は、常置検索式生成部３０２に担当先の実情報ＤＢ３１への常置検索式の作成・常置依頼・更新を指示する。常置検索式は、通常は、変動分を対象識別子に関わらず差分を取り出すテンプレートをそのまま複写して作成する。実情報ＤＢからの依頼内容により、テンプレートを修正する場合もある。

３）常置検索登録
常置検索式生成部３０２は、ＤＢ３１に常置検索を仲介システム自身のアカウントで受付させるよう、依頼検索式管理部４０１に依頼する。依頼検索式管理部４０１は、常置検索式をＤＢ３１だけに中継するよう、検索式依頼部４０２に指示し、ＤＢ３１の常置検索管理部に定期・適時に常置検索式を実行するよう登録させる。

４）常置検索回答
識別子利用記録に変動があったＤＢ３１は、その常置検索管理部の動作として、変動結果を非同期の回答として検索結果受領部４０３に順次、回答を送信してくる。検索結果受領部４０３は、受領した非同期回答を実検索式管理部４０１に転送し、ここで代行登記用として自己依頼した常置検索の回答であることを判別する。（そうで無いものは、従来の中継型としての、元の依頼者への合併回答処理に回される。）

５）サマリーレコード仮作成
代行登記用と判別した回答は、サマリーレコード作成部３０３に回送され、ここで、サマリーキー対象項目を検出して、開示方針を反映させていない仮サマリーレコードを作成する。

６）サマリーレコード完成
サマリーレコード作成部３０３は、ＤＢ３１の代行登録であることを通知して、代行受託実情報ＤＢ群管理部３０１からＤＢ３１が登録している開示指示票を取得し、その設定を仮サマリーレコードに反映させる。ＤＢ３１への実際のアクセスパスではなく、中継システムＩ０１の登記型所在探索応答部２０１を代理許諾交渉窓口としたＵＲＬをアクセスパスに書き込んで、サマリーレコードを完成させる。

７）サマリーレコード代行登記
サマリーレコード作成部３０３は、完成させたサマリーレコードを、ＤＢ３１のアカウント向けであることを明示して、情報保有登記型互換ＤＢ２０２に登記する。情報保有登記型互換ＤＢ２０２は、受け入れ時刻を付記して１回の代行登記を完成させる。

図９は、図７の互換機能群２００（＝登記型仲介システムとしてのＤＢ２１）が、登記型の探索クライアントＱＣ１２と探索インタラクションを行う連携フローチャートである。

これは、図５の説明では、同等のＤＢ２２からの波及探索であったものを、その後の流れを簡単に説明するため、ＱＣ１２が直接接続して来るものとしている。これは、登記型方式では、実情報ＤＢの所在だけではなく、登記型の仲介システムへのアクセスパスを回答して、その先は探索者が自力で解決するよう見放す方法が提案されていることを踏まえている。ここでは、ＱＣ１２は、ＤＢ２２の加入者ではないとしているが、これは、後述の紹介状連携で、提携先のＤＢ２２の保証の下で探索を許可しているものとする。

以下、図９の個別機能部が連携する状況を追記して、流れを詳細に説明する。第２機能群は、図８のサマリーレコード代行登記を行った先そのものであり、登記型互換ＤＢ２０２には、サマリーレコードが蓄積されているものとする。

Ｓ１：探索依頼
ＱＣ１２は、ＤＢ２１に、求める実情報の所在探索を依頼する。このとき、ＱＣ１２はＤＢ２１の提携先であるＤＢ２２の身元保証による身元を開示して、登記型探索対応部２０１にサマリーキーを送付してくる。

Ｓ２：サマリーレコード検索実行
登記型探索対応部２０１は、ＤＢ２２の身元保証による探索者であることを確認して、受信したサマリーキーで、登記型互換ＤＢ２０２に格納されているサマリーレコードを検索する。

Ｓ３：開示判定
登記型互換ＤＢ２０２は、保持するサマリーレコード中に、与えられたサマリーキーに該当するものを抽出し、回答する。登記型探索対応部２０１は、抽出されたサマリーレコードに記載された開示対象者に探索者ＱＣ１２が該当するか判定し、非該当のレコードを回答対象から除外する。

Ｓ４：所在開示応答と紹介状発行
登記型探索対応部２０１は、ＱＣ１２を開示対象者とするサマリーレコードのみを合併し、検索許諾交渉先ＵＲＬをＤＢ２１がＱＣ１２に対して開示判定したことを電子署名した「所在開示紹介状」（図２４により後述）を添付して、合併サマリーレコードをＱＣ１２に回答する。

Ｓ５：不成功時の再探索
ＱＣ１２は回答された実情報ＤＢ群の所在と見られる検索許諾交渉先ＵＲＬから、期待していた件数、乃至は特定の接続先が含まれて入るか判断し、不足と判断した場合は、探索時の開示身元をより明らかにする修正を施し、再度、探索を試みる。

Ｓ６：開示記録・紹介状登録
登記型探索対応部２０１は、いつ誰に所在開示を行ったか、その紹介状署名の識別子が何だったのかを、所在応答履歴ＤＢ３０４の所在応答履歴簿（図２３により後述）に記録する。又課金管理ＤＢ１１０に（身元保証している提携ＤＢ２２のアカウントに身元保証識別子を付記して）探索回答料を計上する。

引き続き、図１０を使用して、実情報ＤＢの所在を探知したＱＣ１２が検索許諾交渉を行う過程を説明する。

ＱＣ１２は、図２４のＤＢ２１が開示した検索許諾交渉を行う先のＵＲＬ及びＤＢ２１が自動検索許諾交渉に使用できる所在開示紹介状を取得している。しかしながら実際には、これは最終的な実情報ＤＢ３１への直接パスではなく、その代理窓口であるＤＢ２１のアカウント管理部１０２へのパスである。

図２４では、実情報ＤＢパスとだけ表記しているが、例のようにhttpsとして提示しても、許諾交渉先がその下位のポート番号乃至は〜／Ｎｅｇｏｔｉａｔｉｏｎ／のように、規約として共通に特定されていれば、交渉先パスを別に表記する必要はない。ＱＣ１２は、ＵＲＬとして表記されたドメイン、乃至はＩＰアドレスが検索仲介システムＩ０１の運営者のものであることはＩＣＡＮＮＩＣに照会するなどして知ることはできるが、ＤＢ３１を利用している事業者名を推定できるＤＢ３１への直接パスは秘匿されたままである。ＱＣ１２にはこれが不満であったとして、ＤＢ３１の所在開示ポリシーに基づいてＤＢ３１への直接パスの開示を受ける他の手段は無いため、ＤＢ２１のアカウント管理部１０２へのパスに対して許諾交渉を行うしかない。

Ｓ７：許諾交渉申込み(応答否認)：ＱＣ１２は、紹介状を提示して、アカウント管理部１０２へ検索許諾を要求する。アカウント管理部１０２は、自己の署名が無い紹介状を受信したと判断した場合は、仲介システムＩ０１を保護するため、ＨＴＴＰ−ＰＯＳＴプロトコルの通信完了応答を意図的に返さない、乃至は交信不成立のエラーコードを返し、ＤＢ２１が存在しない、乃至はＱＣ１２が期待している検索許諾交渉を受けるサービスタイプでないことを装うこともできる。

Ｓ８：紹介状照会：アカウント管理部１０２は、検索許諾交渉に添付された紹介状が、ＤＢ２１が発行したものであることが電子証明から確認できた場合、紹介状の識別子をキーに所在応答履歴ＤＢ３０４の所在応答履歴簿を検索する。

Ｓ９：応答履歴簿検索・許諾判定：所在応答履歴ＤＢ３０４は、紹介状の識別子キーが、探索対応部２０１が登録した「所在探索処置報告」に付記される「紹介状」の識別子に該当するかを照合し、実検索受け入れの１次審査を通過した登記型検索仲介システムの探索者であるかをアカウント管理部１０２に回答する。

アカウント管理部１０２は、ＱＣ１２が提示してきた開示身元と、ＤＢ２１が自ら定めた検索者アカウント要件ポリシーが合致するか判定する。

検索者アカウント要件ポリシーは、中継型の検索仲介サービスを利用できる検索者として検索仲介システムが許諾する対象の条件を定めたものである。たとえば、すべての身元を実名で開示し、法務的な実在と信用（支払い）手段を第三者が電子署名で証明している、乃至は、部分的に身元属性を開示して実名を通知してこないが、提携先の検索仲介システムが探索者の実在と信用、及び開示属性の真正を保障しているなどを規定することができる。

判定に使用する個々の項目をどう判定するかは、検索仲介サービスごとに異なってしかるべきだが、可否を判定する材料となる項目は、提携関係にある検索仲介サービス全体で共通化されることが望ましい。

Ｓ１０：拒絶回答・判定不備票：ＱＣ１２の開示身元が検索者アカウント要件ポリシーに適合しない場合、アカウント管理部１０２は開示身元の不備項目を列記した「判定不備票」をＱＣ１２に回答し、許諾交渉セッションを終了させる。判定不備票についても後述する。

Ｓ１１：許諾回答：ポリシーに適合するとアカウント管理部１０２が判断した場合は、ＱＣ１２の提示身元、乃至はその身元保証に識別子を発行して検索アカウントを仮登録する。合わせて、紹介状に含まれるサマリーキー事項に対してのみ、検索させる範囲制限をその仮アカウントに設定する。

仮アカウント識別子と検索可能なサマリーキー事項に制限されている限定通知が記載された、実検索を実行する＝検索仲介システムＩ０１に本加入するための登録フォームを、ＱＣ１２に許諾交渉の回答として送信する。

Ｓ１２：判定再検討：ＱＣ１２は、受け取った判定示唆票乃至は登録フォーム中に記載された限定通知を見て、身元開示限度を緩める修正をするか、その結果を受け入れるか決断する。

Ｓ１３：実検索者登録申請：ＱＣ１２は限定付きの許諾条件を受け入れる場合、実検索における身元開示範囲を登録フォームに追記して、アカウント管理部１０２に検索者登録を求める。

サマリーキー範囲内での制限を外させるために、実名を公表して完全アカウントを申請することもできる。この場合、決済手段と実検索送信時に使用する公開鍵も登録する。

Ｓ１４：実検索アカウント発行：アカウント管理部１０２は、登録状に記載されたＱＣ１２の身元開示範囲を仮アカウントに設定し、実検索が実効可能な実検索受付部１０１へのアクセスパスをアカウント票に添えて回答する。実名を明かさずに検索者登録を行う場合は、通常の検索者の公開鍵から身元が割れるため、実検索と決済に使用するＩ０１への送信鍵（ＱＣ１２専用に発行した秘密鍵の裏鍵：但し非公開）の発行。

図１１を使用して、実情報検索アカウントを取得したＱＣ１２が実検索を行う過程を説明する。

Ｓ１５：実検索依頼：ＱＣ１２は、渡された裏鍵と、自らの秘密鍵で実検索式を暗号化及び署名して実検索受付部１０１に送信する。実検索受付部１０１は、送信された実検索式に使用されている裏鍵が登録検索者向けかだけを判別し、正規で無いと判断した場合は、応答を返さない、乃至はエラーコードを返して以降の通信を終了する。

Ｓ１６：裏鍵のハッシュ照合が通る場合、実検索受付部１０１は、提示された検索アカウント識別子をアカウント管理部１０２に照会する。

Ｓ１７：アカウント管理部１０２は、アカウント識別子に該当する登録者の公開鍵と、検索許可サマリーキーを回答する。実検索受付部１０１は、登録公開鍵でデコードし、署名が登録者のものであることを確認する。検索範囲制限、中継先制限への処理は後述する。

Ｓ１８：実検索受付部１０１は、実検索式を中継処理群４００の依頼実検索式管理部４０１にＱＣ１２のアカウント情報を指示した依頼票を付けて実検索式を回送し、中継型としての代理検索を開始させる。

Ｓ１９：中継処理群４００は、実検索式をＤＢ３１（他）にＩ０１のアカウントで送付し、実検索の実行を依頼する。

Ｓ２０：ＤＢ３１は実検索式に該当する取扱記録を抽出し、中継処理群４００に回答する。中継処理群４００の依頼実検索式管理部４０１は、回答がＤＢ３１からのものであること、本当の依頼者がＱＣ１２であることを判別する。

Ｓ２１：オプションとして後述するため、省略。

Ｓ２２：中継処理群４００は、ＤＢ３１以外にも検索式を中継して回答を受けている場合は、それらを合併し、ＱＣ１２宛であることを示して、実検索受付部１０１に転送する。実検索受付部１０１は、合併実情報を一括でＱＣ１２に回答する。ＱＣ１２は、探索と実検索の目的が達成される。

Ｓ２３：中継処理群４００は、ＱＣ１２に提供した実情報の内容ごと、乃至は１回答としての情報提供料を回答元ごとに仕分けして、アカウント管理部１０２に通知する。

Ｓ２４：ＱＣ１２は、届け出ている決済手段に従って請求額を清算する。（図中省略）

Ｓ２５：代行実情報ＤＢ群管理部３０１は、ＤＢ３１へ回答寄与分の売上配分を通知する。

以上、図８から図１０の説明により、登記型の所在探索方法に互換して、中継型が傘下の実情報ＤＢ群からサマリーレコードを代行作成し、登記型の探索に実情報ＤＢの代理窓口として所在開示をする過程が説明される。

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

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

そこで、図１２は、物品の取扱記録と、識別子を持つ業務伝票を想定して、識別子取扱い記録の実情報レコードと登記型仲介用のサマリーレコードの推定例（仮想例）を示す線図である。又、図１３は、本実施形態におけるサマリーキー仮想例と実検索式・結果を示す線図である。

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

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

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

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

１) 物品取扱記録の実情報レコードから、物として認識される物品に振られた個体識別番号が、用途区分に関わり無く「主項目」として抽出される。もとになっている取扱記録では荷物そのものの製品個体と、それを運んできた収容容器と分別されていたが、サマリーレコード上では単に物の区分として合併されている。
その他の関連元項目は脱落させられる。これらの関連項目を主項目として別のサマリーレコードを登記することも考えられる。（例：取扱事業所を単位として、扱い物品の区分を探索する、など。）
２) この主項目に対して検索キーを名指し、乃至は範囲として探査してきた場合に、実情報の保有先として回答されるＤＢ３３へのネットワークアクセスパス（例：ＷｅｂサービスＵＲＬ）が記載される。

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

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

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

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

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

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

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

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

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

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

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

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

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

これまで提案されている登記型方式では、探索者は検索仲介システムの加入者であり、紹介される実情報ＤＢも同じ検索仲介システムに加盟していることを前提としている。しかしながら、これだけでは、検索仲介システムが世界で唯一の存在でない限り、探索の範囲が限定されることになる。

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

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

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

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

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

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

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

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

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

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

しかしながら、身元属性の部分開示が共通化されていない場合、実情報所在の開示処理は、実際には検索者身元を全て晒しての交渉になるか、匿名を貫くかのいずれかにしかならない。企業の業務機密に関わる記録を開示することをめぐって探索していることが前提であるので、匿名者に無分別に開示すると言うのは実際にはあり得ないし、そうした試みは自明として拒絶されることが当然である。

しかしながら、本当の身元を晒しても、これを開示対象として事前にどうサマリーレコードに記載しておくかは、大きな困難を伴う。探索者は、サマリーレコードを登記する実情報ＤＢの設置者、乃至はそこに識別子取扱い記録を登録している実情報の所有権者と面識が無いことが当然である。この身元属性に基づく記法以外では、こうした未知の探索者をどう判定の事前に開示対象者としてサマリーレコード上に列記するのか、現実的な手段は無い。

よって、実際には、最低でもこうした探索者属性を手がかりにしたクラス分け等の方法を取らない限り、所在開示の許諾は、全暴露した探索者身元を登記元にいちいち照会して、その都度、登記元が判断する以外に方法が無い。おそらくは、その判断は、全く面識の無い依頼者について人力で興信所に照会を掛けて、自社の審査基準と照合し、経営的な観点から最終判断を人が下すなど、電子システムでは実行不可能な過程を含むことになり、登記型が優位とされる即答性は根底から覆ることになる。それどころか、登記型方式自体が無意味になる可能性すらある。

これに対して本発明では、身元属性を部分的に開示する方法を実現し、当該事物に対する関心を寄せているのが誰であるのかを特定されることを防ぐ方法をも提示する。但し、ここで使用する身元開示方針や、所在開示方針は、後述する中継型の検索仲介に使用するために設計したものをそのまま転用する。それは、以下に説明するように、中継型の高度付帯機能である開示内容制限＝粒度フィルター処理のために設計した制限対象者の背景属性項目が、登記型の探索においても完全に互換動作を実現できることを背景としている。

先ず先に中継型の粒度フィルターの概要を説明する。

図１５は、図７の本発明の基本となる機能ブロック図に次の粒度処理に関係するブロックを追加したものである。それぞれの追加機能ブロックを説明する。なお、図１５は、粒度処理とその応用として後述する方針反映に直接関係しない、課金決済や記録作成登録に関する機能ブロックと内部・外部通信のメッセージパスを省略している。又、登記型探索に互換するための登記型探索対応群２００と、常置検索式作成部３０２、サマリーレコード作成部３０３、応答履歴ＤＢ３０４を省くと、粒度フィルター機能を付帯サービスとして提供できる検索式中継・回答集約型検索システム本来の姿になる。

第１機能群：中継型仲介システムＩ０１としてのクライアント管理用の機能部
１０４：粒度処理部：
検索者の開示身元属性と各実情報ＤＢが登録した対象区分に基づいて、回答の内容の詳細さである情報粒度を低減させる書き換え「粒度フィルター」処理を行う。

第３機能群：サマリーレコード代行作成に転用された加盟実情報ＤＢ方針反映部
３０５：実情報ＤＢ別開示方針ＤＢ：情報提供者となる中継型傘下に加盟する各実情報ＤＢが登録する情報開示方針を保持する。

図１５に沿って、ＤＢ３１の指令票に従って粒度フィルター処理が進行する過程を示す。これは、図１１のＳ２１の説明でオプションとして省略した部分に当たる。

１）開示方針設定指令票の登録：
実情報ＤＢ３１は、ＤＢ管理部３０１に実情報開示方針設定指令票を登録する。これは、増設した開示方針ＤＢ３０５に格納される。

実情報開示方針設定指令票は、図１７に示されるＤＢ項目ごとの開示粒度レベルを、検索者カテゴリー別にどう組み合わせるかを２階層の図１７と図１８の複合テーブルで指定したものである。図１７自体は粒度フィルターサービスを提供する仲介システムＩ０１が利用者共通のメニューとして提示するもので、実情報開示方針設定指令票そのものには含まれない。図１８は、検索者カテゴリー別クラス設定表（図１８Ａ）と、クラス定義表（図１８Ｂ）の２階層で構成される。

２）登録身元属性
従来型検索者ＱＣ１１は、アカウント管理部１０２に図１９のＡ００３として実名で身元を登録している。又、身元開示方針設定指令票を届け出て、図２０の検索中継先の実情報ＤＢの背景属性ごとに開示する身元属性を登録している。

３）中継実行
ＱＣ１１は、図２１に例示する、対価を払ってでも期待する実情報の提供を受けるために開示制限を緩める交渉条件を付記した実情報検索式を受付部１０１に送付する。受付部１０１はＱＣ１１からの実検索であることを申し送りし、中継処理部を通して、交渉条件を取り除いて実検索式は傘下の実情報ＤＢ群に中継される。

このとき、依頼実検索式管理部４０１は、開示方針ＤＢ３０５を検索して図１８Ａの開示方針設定票を取得し、無条件不可乃至は例ではクラス１の対象として、ＱＣ１１の開示身元を指定しているＤＢ群を特定し、最初から完全非開示となることが自明のここへの中継を差し控える。

４）粒度フィルター処理
ＤＢ３１からの回答で検索者があることを識別して、依頼実検索式管理部４０１は、実情報を粒度処理部４０１に申し送る。粒度処理部４０１は、ＱＣ１１の開示身元設定をアカウント管理部１０２から、ＤＢ３１の開示方針設定票（図１８）を開示方針ＤＢ３０５から検索により取得する。粒度処理部４０１はこの双方を図１８Ａのクラス設定表で突合して適用される粒度クラスを決定し、図１８Ｂのクラス定義表からクラスごとの粒度処理ルールを図１７の粒度レベルに落とし込んでそれぞれの項目の内容を書き換える粒度フィルター処理を実行する。

図１７、図１８が複層構造のテーブルで構成されている理由は、情報項目ごとに開示レベルの異なるフィルタークラスを多様に設定し、それをどういった属性をもつ探索者・検索者に適用するか任意の組み合わせで設定するためである。クラス内のレベル構成を変更すれば、このクラスが適用される対象者全てに同時にこれを適用することができ、対象者との業務上の関係が変化した場合は、適用するクラスを切り替えることでその関係を明示的に示すことができる。

もちろん図１７のレベルを対象者ごとに直書きしたフラットテーブルも利用できるが、レベルの適用の判断は人手によることが多いと予見され、保守が煩雑なものとなる。検索仲介システムにおける開示判定には、設定の変更の都度更新される、事前にフラット展開したテーブルから直に読み取っても差し支えない。

本発明の探索者の開示身元の背景属性の部分開示による身元保証は、この粒度処理のための検索者の身元開示方針をもとにしている。この対になるものとして、実情報ＤＢの所在開示方針が、粒度フィルター処理のための対象者属性指定で反映される過程を説明する。

１）ＤＢ３１からサマリーレコード作成用の常置検索回答を受け取った作成部３０３は、開示方針ＤＢ３０５からＤＢ３１の開示方針設定票を検索する。図１８の開示対象者クラス表から図１７のクラス・レベル構成表をたどり、情報項目一切の全非開示に該当しない対象属性全てを所在開示対象としてサマリーレコードを完成させ、互換ＤＢ２０２に代行登記する。

このとき、各情報項目が全非開示で無い限り所在開示を行うのは、許諾交渉先として開示するパスが仲介システムＩ０１自身へのパスで、実情報ＤＢ３１へのパスではないこと、実検索に及んだとしても、粒度フィルターによってＤＢ３１の身元も含めて開示内容はＤＢ３１の意図どおりにいかようにも限定できること、そして、そうした粗い粒度であっても、ＤＢ３１が蓄積した実情報が販売される機会が作れることという、中継型ならではの事後メリットが控えているため、登記型の事前決断的な厳密さから開放されているためである。

２）登記型探索対応部２０１に登記型探索者ＱＣ１２が身元保証された開示属性を示して波及探索を掛けてきた場合、その開示属性が保証されている限り、それを互換ＤＢ２０２に設定した開示方針にそのまま突合する。

この方針は１）のように事後の粒度フィルター処理を前提に、通常の登記型のサマリーレコードより相当緩い基準で設定されているので、仲介システムＩ０１のアカウント管理部１０２を代理窓口としてＤＢ３１の存在は秘匿されたまま、多くの場合は所在開示の対象となる。

図１７〜図２０を利用して、実際の判定の動作を説明する。

図１９中のドラッグストアチェーンであるＡ００１の検索者が、図１８の方針に基づいた開示判定を受ける場合、身元詳細を伏せていたとしても、開示された業種属性が開示対象の「ドラッグストアチェーン」に該当するため、仲介システムＩ０１は、ＤＢ３１の所在（代理窓口）を開示する。

実情報ＤＢ３１が、小売業が設置した実情報ＤＢであって、検索者がＡ００２であったなら、実名を晒しての探索で無い場合となり、ここでは開示された業種区分が非開示の対象である「製薬業」なので、これには所在は開示されず、回答にはＤＢ３１へのアクセスパスは省かれる。（それ以外の開示に該当した実情報ＤＢへのパスは回答される）

なお、図１７に示される方針では、業種を明らかにしない者には、一切、非開示の設定であるので、ＤＢ３１へのアクセスパスは所在回答には含まれない。

図８のサマリーレコード代行作成過程の「２．サマリーレコード代行登録」中の６）で、「サマリーレコード作成部３０３は、実情報ＤＢ群管理部３０１からＤＢ３１が登録している開示指示票を取得し、その設定を仮サマリーレコードに反映させる」としているが、本発明によらない場合、この開示対象者の設定が、名指しか探索者の業界／地域区分や特定事業者の傘下事業所をワイルドカード表記する曖昧な指定しかできず、実情報保有者が意図したとおりに開示／非開示が制御されないことが懸念される。特に、企業識別子を異なるコード体系として許容するとなると、体系ごとにこれらの判別が困難になる。

実例として、ＧＳ１の企業コードは、企業の本籍国を識別する上位桁しかなく、業種を特定することはできない。ＪＥＤＣ標準企業コードは、業界区分を識別する上位桁しかなく、事業地域を特定することはできない。又、どちらも事業規模や資本／提携関係など開示の可否の要件となり得る項目を表す機能を持たない。

これに対して、本発明では、図１９に例示した以上に、情報の開示の方針として考慮するべき何れの事項も追加して詳細に設けることができ、それに対応する身元属性の申告を検索者に求めることができる。

開示方針ＤＢ３０５を新たに設けることにより、開示方針設定票がデータベースレコードとして容易に利用できることは、粒度フィルター処理とサマリーレコード代行作成への開示方針設定だけでなく、いったん登記したサマリーレコードの開示方針に、あとからＤＢ３１の都合で修正を施す場合にも効果を発揮する。その過程を２つの場面について、図１５を再度、使用して説明する。

１．既存のサマリーレコードに設定済みの所在開示方針を修正する。

１）ＤＢ３１がＤＢ群管理部３０１に粒度開示方針の変更指令票（書式は図１８に同じ）を送付する。ＤＢ群管理部３０１は、開示方針ＤＢ３０５にこれを登録するとともに、登記型互換ＤＢ２０２を検索して、変更のあった開示方針に該当するサマリーレコードを検索する。

２）方針変更対象であるサマリーレコードを検索したＤＢ群管理部３０１は、設定票とサマリーレコードそれぞれの主キーをサマリーレコード作成部３０３に通知し、その変更再登記を指示する。

３）変更指示を受けたサマリーレコード作成部３０３は、主キーで開示方針ＤＢ３０５から設定票、登記型互換ＤＢ２０２からサマリーレコードを検索取得し、方針を書き換えた修正サマリーレコードに対して、置き換え主キーを明示して登記型互換ＤＢ２０２に修正登記する。

４）開示方針ＤＢ３０５は、図１６の開示方針設定票管理テーブルを保持する。これで変更指令票を版番号として管理し、各版の修正登記処理の未了／完了の反映状況ステータス管理を行う。サマリーレコード作成部３０３は、修正完了時にこのステータスを更新する。

この効果により、ＤＢ３１は、登記型用のサマリーレコードを代行作成させるだけでなく、登記型としての所在開示方針の変更も、それを意識することなく単に中継型の粒度フィルター設定の変更を指示しているつもりだけで、同時に達成することができる。
登記型互換ＤＢ２０２に蓄積されているサマリーレコードの開示方針上書きは、レコード数が膨大な場合には即座に反映できないことも起き得る。これに対処するため、第２の場面がある。

２．修正の間に合わないサマリーレコードを未反映の修正方針で臨時修正する。

５）探索対応部２０１は、登記型互換ＤＢ２０２から取得したサマリーレコードがＤＢ３１のものであることを読みとった後、開示方針ＤＢ３０５の図１６の管理方針設定票管理テーブルを検索して最新のＤＢ３１の方針設定票の反映状況ステータスを取得する。ステータスが未了の場合、方針設定票自体を取得する。

６）これに書かれた開示方針が、取得したサマリーレコードの開示方針と矛盾しないか検証する。衝突がある場合、サマリーレコードの作成／修正時刻が開示方針の記録時刻より古いことを確認して、新しい方針設定票に沿って開示判定を行う。

７）更新が間に合っていないと判断されたサマリーレコードは、探索対応部２０１が新しい開示方針に修正して登記型互換ＤＢ２０２に更新登記する。

臨時修正は、本来は省略可能である。処理を軽減するために、開示方針ＤＢ３０５の一括修正の反映状況のステータスだけを先に参照して、不要な場合はスキップすることも、必要な場合には確実に執行することもできる。

ここで、本実施形態における紹介状について説明する。

紹介状は、本来は登記型方式の探索後に不可避な、当事者間での検索許諾交渉の手間を緩和するものとして、実情報ＤＢが指定した所在開示対象者としての１次開示審査に合格した探索者であることを、仲介システムが開示した実情報ＤＢに申し送りするものとして提唱されている。しかしながら、サマリーレコード同様、記載内容やその取扱いを規定する規格はまだ制定されていない。類似する技術として、ＯｐｅｎＩＤが規格化されているが、これは一般向けの加盟サイト間でサービスと集客を融通し合うことが目的であり、個々の内容に依存して守秘性の高い事業情報である識別子取扱い記録を企業間で開示する用途においては、未知の相手に対しては特定の情報を開示するか否かの判断が必須となり適用が困難である。

例え紹介状が規格化されたとしても、所在紹介を受けた実情報ＤＢがこの紹介状をどう処理して判断するかは、それぞれの実装に委ねられる。検索者が身元を全開示して許諾交渉を求める場合は、前述のように紹介状は交渉最初期の通信確立に役立つが、実際の判断は相手次第ということになる。匿名で身元属性の一部だけを開示して交渉を求めるためには、紹介状よりもこれまでに述べた身元属性の共通化とその真正保証の相互信頼の仕組みの方がより重要である。

登記型方式においては、紹介状を重く信頼するという方法を採用することも考えられるが、その場合、身元保証の仕組みがあっても１次審査での開示可否の判定が深刻なものとならざるを得ない。又、実情報ＤＢ側にとっては、いったん許諾した検索者に実際に検索させる際、何をどこまで取得することを許すのか、それぞれ深刻な管理を自力で執行しなければならない負担が残る。

中継型の検索仲介システムは、この許諾交渉の代理当事者になることができ、その後の内容次第による開示制限を処理する粒度フィルターをも代行することができるため、発行した紹介状の事後のあしらいを自ら処理することが可能で、紹介状の発行基準を相当程度、緩やかにすることができる。これは、中継型仲介システムが傘下に加盟する実情報ＤＢに代わって検索許諾交渉と実検索を受ける代理所在回答にも同じ枠組みを流用しているに過ぎない。

紹介状そのものは、登記型の探索者と実情報ＤＢには、ある程度の効用があるが、中継型を下敷きにしている本発明においては、図２２の紹介状発行履歴簿を作成して、その後の検索制限に利用することが実際の目的であり、探索者への紹介状の発給自体はあまり重要ではない。

ここで、本実施形態における紹介状及び身元状について説明する。

図２３は、本発明で想定する検索仲介システムが発行する実情報所在アクセスパスの一部としての紹介状の例である。紹介状はこの探索回答であるアクセスパス応答電文の一部として、紹介状としての項目をそれぞれの実検索パスごとに付記する形態をとっている。この電文の構造は、探索者が各開示先乃至は拒絶元が何件あるかを、該当するサマリーキー集合ごとに識別された存在として把握できるよう考慮している。それぞれの紹介状項目は、紹介状としての識別子である「通し番号」を仲介システムが振り出し個別管理する。これはアクセスパス応答全体に対して紹介状が発行されたものではなく、個々の開示先に対して発給されたもので、その開示先だけに有効であることを示している。基本的には、タイムスタンプ認証と同じであり、この項目部分のハッシュ署名を付けることにより、署名者である検索仲介システムが真正を証明することで、流通性を保証する。紹介状には判定理由を記載することができる。所在が開示された場合には、それぞれのサマリーキーごとにどの許可条件が適用されたかを別の規約で共通化するべきＣ１、Ｓ１の符号で表示している。非開示の拒絶回答となった場合、何が原因で非開示とされたのかの判定理由を通知している。拒絶された探索者は、この理由をもとに、身元をどこまで晒して所望の情報にたどり着くか、決断する、乃至はこれ以上、望みがないことを知ることができる。

図２４は、図２３のアクセスパス回答の紹介状部分と、図１４の探索用サマリーキーの身元状部分をそれぞれ切り出して合体させた、検索許諾交渉に使用する身元状部を含む紹介状の例である。ここでは、身元部分開示で探索を以来した際に使用した直接加入している検索仲介システムＤＢ２２が発行した臨時の身元識別子と開示属性をそのまま使用している。許諾交渉が不調に終わった場合は、臨時の身元識別子を維持したまま、開示属性を増やすことで許諾される場合も出てくる。そこで、探索者Ｑ１２は加入する登記型の検索仲介システムＤＢ２２に開示属性を増やした身元状の再発行を求め、同じ臨時の身元識別子で増えた開示属性に対して新たな電子署名を得ることで、紹介状で識別されている所在開示した探索者と同一視されながら、許諾交渉を成功させることができる場合もある。中継型の検索仲介システムは、開示する所在アクセスパスは、実情報ＤＢではなく中継システム自身であり、とりあえず安易に検索許諾しても、受け付ける実検索式や供給する実情報を後処理でいかようにも制限する能力を備えるので、通常は、所在開示と検索許諾の判定を違える必要はない。但し、所在開示判定の時点から図１８Ａの情報開示方針設定票が修正される、乃至はＤＢ２２との提携が解消される、といった探索回答と検索許諾の時間差に起因する事態によって、方針が変更される場合もある。このように紹介状と身元状は、こうした事情の変化にもある程度対処する方法を提供する。

図２２の所在応答履歴簿は、紹介状に記載されなかった「本来実情報ＤＢパス」の項目を持っている。これは、中継型検索仲介システムが、登記簿検索の時点で把握し、探索者には代行窓口だけを通知して秘匿した実情報本文の所在アクセスパスそのものである。これと代行窓口をすり替えて回答することに本発明の特徴がある。

中継型の検索仲介システムＩ０１は、この紹介状の発行履歴である所在応答履歴簿を、検索許諾とその後の検索制限に有効に利用する。図１１のＳ１７の説明で省略した検索式制限がこの所在応答履歴簿によって実行される手順を開設する。

１）紹介状照合
図１０のＳ７として、検索者ＱＣ１２が許諾交渉を求める際に提示する身元識別子と紹介状の識別子から、アカウント管理部１０２が所在応答履歴簿を検索して、ＱＣ１２に開示としたサマリーキーとその元になっている実情報を保有する本来実情報ＤＢパスを確認する。

２）制限アカウント発行
図１０のＳ１０の後の許諾判定後の検索アカウント仮登録において、ＱＣ１２のアカウントに開示サマリーキーとその本来実情報ＤＢパスを記録し、Ｓ１３、Ｓ１４の本登録を進める。

３）制限アカウント照会
図１１のＱＣ１２からの実検索アカウント照会Ｓ１６への回答として、Ｓ１７においてＱＣ１２に開示されたサマリーキーと本来実情報ＤＢパスの一覧を引き渡す。

４）実検索式制限修正
実検索受付部は、依頼された実検索式に対して、検索対象となる識別子取扱記録が、全ての項目が渡されたサマリーキー群との論理積を満たすように制限されるよう、修正を施す。

５）中継先制限
実検索式への制限修正の後、実検索受付部１０１は、中継処理群４００に対して、本来実情報ＤＢパスとして取得したサマリーキーに該当する実情報ＤＢを特定して、これだけに対して中継を行うよう、依頼する。

６）限定中継実行
中継処理群４００は、図１５の説明の３）中継実行の補足で述べた、通常の中継対象判定を省いて、本来実情報ＤＢパスに該当する実情報ＤＢ群にだけ、実検索式中継を実行する。

以上の措置により、登記型探索を経て接続してきた元来の中継型検索中継サービスの加入者でない、しかも身元を全開示しないゲスト検索者を加入する実情報ＤＢ群に最小のリスクで仲介することができる。この後、検索者ＱＣ１２の開示身元に対応する粒度フィルター処理による内容制限が更に掛けられ、情報保護は強化される。このときにも、実情報ＤＢからの開示方針設定表に特に指示が無くても、中継型検索集会システムの粒度処理部１０４の措置として、探索で判定したサマリーキーに該当しない同一区分の情報内容については削除するという、最強度の粒度処理を施すこともできる。こうした２次、３次の情報保護機能を駆使することができるため、登記型探索に互換する中継型仲介システムは、最初期の開示判定を緩やかな条件で実行することができる。

このように、従来の実検索方式にだけ対応した実情報ＤＢは、これら登記型互換機能を備えた検索式中継・回答集約型の検索仲介サービスに加盟することにより、何の改修もせずに登記型方式の検索仲介ネットワークに参加することができる。

ここで、以上に説明した実施形態を一部変形した、第２の実施形態について、以下において説明する。

図５の実施形態とは異なる形態で、中継型傘下の在来規格にだけ対応した実情報ＤＢ群が登記型方式の検索仲介に参加する形態がある。

図２５は、本実施形態の登記型検索仲介システムで動いている探索ネットワークの下において、中継型検索仲介システムのサービス自身を実情報保有者として登記型仲介システムに間接登記する形態を示すブロック図である。

本実施形態では、中継型検索仲介システムＩ０２の傘下には、登記型検索仲介システムに直接対応できない（する必要も無い）実情報ＤＢ群４１〜４４が加盟している。実情報の所在を中継型検索仲介システムのサービス自身として上位に登記しておくことで、実検索は、中継型検索仲介システムＩ０２のサービスが介在して受けることになり、中継型検索仲介システム傘下のＤＢ４１〜４４はそのまま中継型検索仲介システムの粒度フィルターなどの付帯サービスを受けることができる。

ここで、図５との違いは、代行作成したサマリーレコードを登記型検索仲介システムＤＢ２４の登記簿データベースに２次登記し、中継型傘下の実情報データベースが保有している情報に対しての所在の探索の照会には、ＤＢ２４が間接的にこれら実情報ＤＢの代理窓口である中継型検索仲介システムＩ０１へのアクセスパスを回答させる形態をとるところにある。

これは、中継型仲介システムが、傘下の実情報ＤＢ群と全く同じ実検索受付・回答部を備えることから、開示所在を仲介システムに振り替えて登記することで、登記型の探索者にも仲介システムにも通常の実情報ＤＢと全く等価に見えることで実現されるものである。但し、これは、図５と異なり、外部に登記した場合、後述の開示方針の変更があった場合に、過去の登記分に対して開示方針変更の修正登記が必要になる問題が生じる。

登記型方式においては、厳格に所在開示の可否を判定する必要がある。しかしながら、本発明においては、実際に回答される探索事後の実情報の検索許諾交渉先、及びその後の実検索先は、本当の実情報ＤＢ３１へのアクセスパスではなく、開示判定を下した、ただの代理人である中継型の検索仲介システムＩ０２自身へのアクセスパスそのものとなる。よって、開示対象かどうかを照合したサマリーレコードのいずれかに、開示対象に該当すると判定されるものが１件でもあれば、そのＯＲ集合として仲介システムＩ０２へのアクセスパスを開示することはやぶさかでは無い。たとえその最小の理由から仲介システムの所在を開示したとしても、実検索先は非開示としている実情報ＤＢに及ぶことはなく、又その本当の所在や、実情報を保持している事実までも、探索者には完全に隠蔽できるため、極めて緩い条件で事後の接触先を開示しても一向に差し支えない。

Ｃ…検索者（クライアント）
Ｉ…仲介システム
Ｒ、３１〜３８…実情報データベース（ＤＢ）
１１、１２…検索クライアント

Claims

開設者が異なる複数のデータベースを利用者端末から検索する際に、検索の仲介を行う検索仲介システムであって、
利用者端末の検索に供するデータベース情報の登記簿に、実情報ＤＢ側から検索対象の情報の登記代行の依頼を受け、この処理を行う代行受託実情報ＤＢ群管理部と、
仲介対象である実情報データベースが保有する情報の要約を登録する登記簿と、
上記登記簿に登録する情報を生成する手段と、
登記型方式の探索依頼に対して、前記登記簿を参照して所在回答を行う登記型探索対応部と、
登記型方式の実検索依頼を受付け、前記実情報データベースの検索結果を回答する実検索式受付回答部と、
上記実検索式受付回答部の中継依頼に応じて、前記実情報データベースを検索し検索結果を取得する中継処理部と、
を具備し、
前記登記型探索対応部は、実際に回答される探索事後の実情報の検索許諾交渉先、及びその後の実検索先は、前記実情報データベースへのアクセスパスではなく、検索仲介システム自身へのアクセスパスとすることを特徴とする検索仲介システム。
請求項１に記載の検索仲介システムであって、
仲介型の付帯機能として、最初から完全非開示か否かを判定するための開示方針設定票の情報を保存する実情報ＤＢ別開示方針ＤＢと、
前記実情報ＤＢ別開示方針ＤＢの前記開示方針設定票を検索して、最初から完全非開示か否かを判定する依頼実検索式管理部と、
を更に具備することを特徴とする検索仲介システム。
請求項１又は請求項２に記載の検索仲介システムであって、
登記型方式の実検索許諾依頼に対して、依頼者の開示身元が検索者アカウント要件ポリシーに合致するか否かの判定に基づき許諾（拒絶）通知を行うアカウント管理部を、更に具備することを特徴とする検索仲介システム。
請求項１乃至請求項３のいずれか１つに記載の検索仲介システムであって、
中継型検索仲介を行う傘下の実データベースに対する検索に際し、検索者の開示身元属性と各実情報ＤＢが登録した対象区分に基づいた粒度フィルタ処理を行う粒度処理部を、更に具備することを特徴とする検索仲介システム。