(57)【特許請求の範囲】
【請求項１】
ユーザが所有している、あるいはメタ情報を参照する権利を有している物品や情報コンテンツ（以下、リソースと呼ぶ）について、ユーザからの要求に応じて、目的のリソース固有の識別ＩＤや当該リソースに関する１つ以上のメタ情報を記録あるいは回答するリソース情報検索システムにおいて、１つ以上のユーザ端末と、１つ以上のデータベースと名前解決機構によって構成され識別ＩＤを有する全てのリソースに対するリソース情報を保持する共通データベースシステムと、１つ以上のブローカと、ディレクトリサービスとがデータ通信ネットワーク上に配置され、
各ユーザ端末は、
(1)  ユーザが指定するリソースの検索や登録に用いられる識別ＩＤと、
(2)  ユーザが指定するリソースの検索や登録に用いられるメタ情報と、
(3)  登録要求・検索要求などを区別する命令コードと
を有し、
前記各ユーザ端末により、
(4)  前記リソースの識別ＩＤや前記メタ情報、および登録要求・検索要求を区別する命令コードを含み、登録及び検索用に用いられる、共通データベースシステムおよびディレクトリサービス用に同じフォーマットで構成された要求メッセージをブローカに送信するプロセスと、
(5)  前記ブローカから検索要求に対する回答を受信するプロセスと
を含み、
前記共通データベースシステムの各データベースは、
(6)  １つ以上のリソースについて、リソースの識別ＩＤとそれに対応する１つ以上のメタ情報を保持する表を有し、
前記共通データベースシステムの各データベースにより、
(7)  ブローカより要求メッセージを受信し、要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(8)  登録要求に対して前記プロセス(7)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(6)の表のエントリとして記録するプロセスと、
(9)  検索要求に対して前記プロセス(7)から要求メッセージに含まれる識別ＩＤを受け取り、該識別ＩＤに対応する前記(6)の表のエントリに記録されている１つ以上のメタ情報を回答するプロセスと、
(10)  検索要求に対する回答を要求メッセージの送信元のブローカへ返信するプロセスと
を含み、
前記共通データベースシステムの名前解決機構は、
(11)  リソースの識別ＩＤと、それに対応する担当データベースのアドレスを保持する表を有し、
前記共通データベースシステムの名前解決機構により、
(12)  ブローカより名前解決の要求メッセージを受信し、要求メッセージ内の識別ＩＤに基づいて、ユーザからの要求メッセージを処理する担当データベースを決定し、当該データベースのアドレスを送信元のブローカへ返信するプロセスを含み、
前記ブローカは、
(13)  ユーザ端末から要求メッセージを受信するプロセスと、
(14)  前記プロセス(13)で受信した要求メッセージに含まれる識別ＩＤに関する名前解決の要求メッセージを共通データベースシステム内の名前解決機構へ送信し、回答として担当データベースのアドレスを受信するプロセスと、
(15)  前記プロセス(13)で受信した要求メッセージの命令コードが登録要求の場合は当該要求メッセージに前記プロセス(14)を利用して得られる担当データベースのアドレスを追加したメッセージを、識別ＩＤを含まない検索要求の場合は当該要求メッセージをそのまま、ディレクトリサービスヘ転送するプロセスと、
(16)  前記ディレクトリサービスから検索要求に対する回答として１つ以上のアドレスを受信するプロセスと、
(17)  前記プロセス(14)あるいは前記プロセス(16)で受信したアドレスに対応する共通データベースシステム内の担当データベースヘ、前記プロセス(13)で受信した要求メッセージを転送するプロセスと、
(18)  前記プロセス(17)が要求メッセージを転送した担当データベースより検索要求に対する回答として１つ以上のメタ情報を受信し、ユーザ端末へ転送するプロセスと
を含み、
前記ディレクトリサービスは、
(A)  識別ＩＤを持つ全てのリソースについて識別ＩＤや１つ以上のメタ情報と担当データベースのアドレスの対応を保持する表と、
(B)  前記表の各エントリの登録回数と
を有し、
前記ディレクトリサービスにより、
(C)  ブローカより要求メッセージを受信し、要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(D)  登録要求に対して前記プロセス(C)から渡された要求メッセージに含まれる識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスの情報をセットにした情報を前記表のエントリとして記録し、当該エントリの登録回数を１つ加算するプロセスと、
(E)  検索要求に対して前記プロセス(C)から渡された要求メッセージに含まれる１つ以上のメタ情報に対応する１つ以上のエントリに記録されている担当データベースのアドレスを回答するプロセスと、
(F)  検索要求に対する回答として１つ以上の担当データベースのアドレスを要求メッセージの送信元のブローカヘ返信するプロセスと
を含むことを特徴とするリソース情報検索方法。
【請求項２】
請求項１に記載のリソース情報検索方法において、前記ブローカは、ユーザ端末とディレクトリサービスおよび共通データベース間におけるメッセージのスキーマ変換およびプロトコル変換を行うことを特徴とするリソース情報検索方法。
【請求項３】
請求項１又は２に記載の情報検索方法において、データ通信ネットワーク上に配置された各ユーザ用の個人データベースを更に具え、
前記ブローカにより、更に前記プロセス(13)で受信した要求メッセージを個人データベースに転送するプロセスを含み、
前記個人データベースは、
(19)  リソースについて、メタ情報をインデックスとし、それに対応する１つ以上の識別ＩＤを保持する表を有し、
前記個人データベースにより、
(20)  前記ブローカより要求メッセージを受信するプロセスと、
(21)  前記プロセス(20)で受信した要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(22)  前記プロセス(21)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(19)の表のエントリとして追加する登録処理プロセスと、
(23)  前記プロセス(21)から要求メッセージに含まれる１つ以上のメタ情報を受け取り、前記(19)の表から当該メタ情報に対応する１つ以上の識別ＩＤを逆引きし、要求メッセージの送信元のユーザ端末へ送信する検索処理プロセスと
を含むことを特徴とするリソース情報検索方法。
【請求項４】
ユーザが所有している、あるいはメタ情報を参照する権利を有している物品や情報コンテンツ（以下、リソースと呼ぶ）について、ユーザからの要求に応じて、目的のリソース固有の識別ＩＤや当該リソースに関する１つ以上のメタ情報を記録あるいは回答するリソース情報検索システムにおいて、データ通信ネットワーク上に配置された１つ以上のユーザ端末と、１つ以上のデータベースと名前解決機構によって構成され識別ＩＤを有する全てのリソースに対するリソース情報を保持する共通データベースシステムと、１つ以上のブローカと、ディレクトリサービスとを具え、
各ユーザ端末は、
(1)  ユーザが指定するリソースの検索や登録に用いられる識別ＩＤと、
(2)  ユーザが指定するリソースの検索や登録に用いられるメタ情報と、
(3)  登録要求・検索要求などを区別する命令コードと
を有し、
各ユーザ端末は、
(4)  前記リソースの識別ＩＤや前記メタ情報、および登録要求・検索要求を区別する命令コードを含み、登録及び検索用に用いられる、共通データベースシステムおよびディレクトリサービス用に同じフォーマットで構成された要求メッセージをブローカに送信する手段と、
(5)  前記ブローカから検索要求に対する回答を受信する手段と
を具え、
前記共通データベースシステムの各データベースは、
(6)  １つ以上のリソースについて、リソースの識別ＩＤとそれに対応する１つ以上のメタ情報を保持する表と、
(7)  ブローカより要求メッセージを受信し、内の命令コードより処理方法を決定する手段と、
(8)  登録要求に対して前記手段(7)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(6)の表のエントリとして記録する手段と、
(9)  検索要求に対して前記手段(7)から要求メッセージに含まれる識別ＩＤを受け取り、該識別ＩＤに対応する前記(6)の表のエントリに記録されている１つ以上のメタ情報を回答する手段と、
(10)  検索要求に対する回答を要求メッセージの送信元のブローカへ返信する手段と
を具え、
前記共通データベースシステムの名前解決機構は、
(11)  リソースの識別ＩＤと、それに対応する担当データベースのアドレスを保持する表と、
(12)  ブローカより名前解決の要求メッセージを受信し、要求メッセージ内の識別ＩＤに基づいて、ユーザからの要求メッセージを処理する担当データベースを決定し、当該データベースのアドレスを送信元のブローカへ返信する手段とを具え、
前記ブローカは、
(13)  ユーザ端末から要求メッセージを受信する手段と、
(14)  前記手段(13)で受信した要求メッセージに含まれる識別ＩＤに関する名前解決の要求メッセージを共通データベースシステム内の名前解決機構へ送信し、回答として担当データベースのアドレスを受信する手段と、
(15)  前記手段(13)で受信した要求メッセージの命令コードが登録要求の場合は当該要求メッセージに前記手段(14)を利用して得られる担当データベースのアドレスを追加したメッセージを、識別ＩＤを含まない検索要求の場合は当該要求メッセージをそのまま、ディレクトリサービスヘ転送する手段と、
(16)  前記ディレクトリサービスから検索要求に対する回答として１つ以上のアドレスを受信する手段と、
(17)  前記手段(14)あるいは前記手段(16)で受信したアドレスに対応する共通データベースシステム内の担当データベースヘ、前記手段(13)で受信した要求メッセージを転送する手段と、
(18)  前記手段(17)が要求メッセージを転送した担当データベースより検索要求に対する回答として１つ以上のメタ情報を受信し、ユーザ端末へ転送する手段と
を具え、
前記ディレクトリサービスは、
(A)  識別ＩＤを持つ全てのリソースについて識別ＩＤや１つ以上のメタ情報と担当データベースのアドレスの対応を保持する表と、
(B)  前記表の各エントリの登録回数と
を有し、
(C)  ブローカより要求メッセージを受信し、要求メッセージ内の命令コードより処理方法を決定する手段と、
(D)  登録要求に対して手段(C)から渡された要求メッセージに含まれる識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスの情報をセットにした情報を前記表のエントリとして記録し、当該エントリの登録回数を１つ加算する手段と、
(E)  検索要求に対して手段(C)から渡された要求メッセージに含まれる１つ以上のメタ情報に対応する１つ以上のエントリに記録されている担当データベースのアドレスを回答する手段と、
(F)  検索要求に対する回答として１つ以上の担当データベースのアドレスを要求メッセージの送信元のブローカヘ返信する手段と
を具えることを特徴とするリソース情報検索装置。
【請求項５】
請求項４に記載のリソース情報検索装置において、前記ブローカは、ユーザ端末とディレクトリサービスおよび共通データベース間におけるメッセージのスキーマ変換およびプロトコル変換を行う手段を具えることを特徴とするリソース情報検索装置。
【請求項６】
請求項４又は５に記載の情報検索装置において、データ通信ネットワーク上に配置された各ユーザ用の個人データベースを更に具え、
前記ブローカは、更に前記手段(13)で受信した要求メッセージを個人データベースに転送する手段を含み、
前記個人データベースは、
(19)  リソースについて、メタ情報をインデックスとし、それに対応する１つ以上の識別ＩＤを保持する表と、
(20)  前記ブローカより要求メッセージを受信する手段と、
(21)  前記手段(20)で受信した要求メッセージ内の命令コードより処理方法を決定する手段と、
(22)  前記手段(21)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(19)の表のエントリとして追加する登録処理手段と、
(23)  前記手段(21)から要求メッセージに含まれる１つ以上のメタ情報を受け取り、前記(19)の表から当該メタ情報に対応する１つ以上の識別ＩＤを逆引きし、要求メッセージの送信元のユーザ端末へ送信する検索処理手段と
を具えることを特徴とするリソース情報検索装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが所有している、あるいはメタ情報を参照できるなど何らかの利用権を有している、各々が固有の識別ＩＤを持つリソース（物品や情報コンテンツ）について、ユーザからの要求に応じて、目的のリソースの識別ＩＤやメタ情報を記録あるいは回答するリソース情報検索システムにおける、メタ情報から、該当するリソースの識別ＩＤや他のメタ情報を検索する方法、および当該情報検索方法を実施する装置に関するものである。
【背景技術】
【０００２】
今後の情報流通ネットワークで主要なサービスとなり得るユビキタスサービスは、空間的制約を超越した「いつでも、どこでも、誰とでも」情報流通が可能になるというサービスであるが、内容的には、移動性に対応できる通信サービスとは、かなり内容の異なる広範なサービス概念を含む。例えば、(1)無線タグを物や人に貼り付け、無線タグリーダをいろいろな場所に設置することで、物や人の場所や状態（例えば、在庫か否か）などを管理・把握・利用する無線タグサービスや、(2)微小なセンサをばら撤き、それらのセンサから送られてくる種類のセンシング情報を元に、多様なアプリケーションを提供するセンシングサービスなどが含まれる。(1)については既に、Ａｕｔｏ−ＩＤ構想（例えば、非特許文献１参照）のように、物流管理を主な管理対象とし、固定フォーマットのＩＤで物品／コンテンツの名前を表現し、このＩＤ単位で物品情報／コンテンツ情報の記録・回答を担当するデータベースを決定することでスケール性を確保するシステムの商用化が始まっている。
【０００３】
しかし、これらのユビキタスサービスにおける情報検索では、目的のリソースを指定する名前として、固定フォーマットのＩＤでは人が名前とリソースの対応を把握するのが困難であるため、どのようなリソースであるかを表現する自己説明的な名前を用いることが望ましい。この自己説明的な名前は、メタ情報の集合と考えることができる。ユビキタスサービスに好適な名前としてセンシングサービスでは、ある特定のセンシング情報を得たい場合、どんなセンシング情報であるか、例えば、センシング項目名、センシング場所、センシング時刻などを名前とすることが考えられる。その名前／メタ情報から、同情報を有するセンサ、あるいは、センサ情報を格納したデータベースのアドレスを取得する名前解決機構／ディレクトリサービスが求められる。
【０００４】
ＩＮＳ（International Naming System）と称されるＭＩＴの研究結果（例えば、非特許文敵２参照）は、自己説明的な名前を用いる名前解決機構／ディレクトリサービスである。ＩＮＳにおける名前は互いに依存関係を持つ複数のａｖペアと称される属性とその値の組み合わせによって構成され、依存関係は木構造で表される。ＩＮＳ／Ｔｗｉｎｅと称される同じくＭＩＴの研究結果（例えば、非特許文献３参照）は、ＩＮＳにおける名前を１つ以上のａｖペアの組み合わせからなるｓｔｒａｎｄと称するメタ情報に分解することにより、名前／メタ情報とリソースのアドレスの対応を複数のデータベースで分散管理するものである。個々のｓｔｒａｎｄに対応するリソースの数が膨大になり得るが、その場合は、ｓｔｒａｎｄ毎に所定の閾値までの数のリソースのみを記録することにより、名前解決結果／検索結果が不完全なものとなる一方でデータベースの過負荷を避ける。
【０００５】
【非特許文献１】「ＡＵＴＯ−ＩＤ  ＬＡＢＳ」、[on line]、[平成１６年２月９日検索]、インターネット＜URL：http://www.autoidlabs.org/＞
【非特許文献２】W.Adjie-Winoto, E.Scwartz, H. Balakrishnan and J. Lilley, ”The design and implementation of an intentional naming system” In Proc. of the 17th ACM Symposium on Operating Systems, Dec.1999.
【非特許文献３】Twine：Scalable International Resource Discovery for Pervasive Computing Environments”、[on line]、[平成１６年２月８日]、インターネット＜URL： http://nms.lcs.mit.edu/projects/twine/
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ユピキクスサービスを含む今後の情報流頴ネットワークにおいては、扱うリソースの多様化および数の爆発的な増加を反映して、リソースの自己説明的な名前やメタ情報に基づいてリソース自身あるいはリソースに関する情報の検索、所謂「逆引き」を可能にする仕組みが求められる。
自己説明的な名前やメタ情報に基づく情報検索に関する研究成果が既に発表されているが、それらは膨大な数のリノースを対象としたシステムを実現する上ではスケーラビリティの観点からの問題がある。また、固定フォーマットのＩＤに基づいて各データベースの担当（どのリソースの情報を記録・回答するか）を決定するシステムでは、メタ情報のみを用いた検索要求を想定していないため、この種のシステムで逆引きを行うには全データベースヘの確認が必要となり、実行時の処理効串が者しく悪化してしまう。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、請求項１に係る発明は、ユーザが所有している、あるいはメタ情報を参照する権利を有している物品や情報コンテンツ（以下、リソースと呼ぶ）について、ユーザからの要求に応じて、目的のリソース固有の識別ＩＤや当該リソースに関する１つ以上のメタ情報を記録あるいは回答するリソース情報検索システムにおいて、１つ以上のユーザ端末と、１つ以上のデータベースと名前解決機構によって構成され識別ＩＤを有する全てのリソースに対するリソース情報を保持する共通データベースシステムと、１つ以上のブローカと、ディレクトリサービスとがデータ通信ネットワーク上に配置され、
各ユーザ端末は、
(1)  ユーザが指定するリソースの検索や登録に用いられる識別ＩＤと、
(2)  ユーザが指定するリソースの検索や登録に用いられるメタ情報と、
(3)  登録要求・検索要求などを区別する命令コードと
を有し、
前記各ユーザ端末により、
(4)  前記リソースの識別ＩＤや前記メタ情報、および登録要求・検索要求を区別する命令コードを含み、登録及び検索用に用いられる、共通データベースシステムおよびディレクトリサービス用に同じフォーマットで構成された要求メッセージをブローカに送信するプロセスと、
(5)  前記ブローカから検索要求に対する回答を受信するプロセスと
を含み、
前記共通データベースシステムの各データベースは、
(6)  １つ以上のリソースについて、リソースの識別ＩＤとそれに対応する１つ以上のメタ情報を保持する表を有し、
前記共通データベースシステムの各データベースにより、
(7)  ブローカより要求メッセージを受信し、要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(8)  登録要求に対して前記プロセス(7)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(6)の表のエントリとして記録するプロセスと、
(9)  検索要求に対して前記プロセス(7)から要求メッセージに含まれる識別ＩＤを受け取り、該識別ＩＤに対応する前記(6)の表のエントリに記録されている１つ以上のメタ情報を回答するプロセスと、
(10)  検索要求に対する回答を要求メッセージの送信元のブローカへ返信するプロセスと
を含み、
前記共通データベースシステムの名前解決機構は、
(11)  リソースの識別ＩＤと、それに対応する担当データベースのアドレスを保持する表を有し、
前記共通データベースシステムの名前解決機構により、
(12)  ブローカより名前解決の要求メッセージを受信し、要求メッセージ内の識別ＩＤに基づいて、ユーザからの要求メッセージを処理する担当データベースを決定し、当該データベースのアドレスを送信元のブローカへ返信するプロセスを含み、
前記ブローカは、
(13)  ユーザ端末から要求メッセージを受信するプロセスと、
(14)  前記プロセス(13)で受信した要求メッセージに含まれる識別ＩＤに関する名前解決の要求メッセージを共通データベースシステム内の名前解決機構へ送信し、回答として担当データベースのアドレスを受信するプロセスと、
(15)  前記プロセス(13)で受信した要求メッセージの命令コードが登録要求の場合は当該要求メッセージに前記プロセス(14)を利用して得られる担当データベースのアドレスを追加したメッセージを、識別ＩＤを含まない検索要求の場合は当該要求メッセージをそのまま、ディレクトリサービスヘ転送するプロセスと、
(16)  前記ディレクトリサービスから検索要求に対する回答として１つ以上のアドレスを受信するプロセスと、
(17)  前記プロセス(14)あるいは前記プロセス(16)で受信したアドレスに対応する共通データベースシステム内の担当データベースヘ、前記プロセス(13)で受信した要求メッセージを転送するプロセスと、
(18)  前記プロセス(17)が要求メッセージを転送した担当データベースより検索要求に対する回答として１つ以上のメタ情報を受信し、ユーザ端末へ転送するプロセスと
を含み、
前記ディレクトリサービスは、
(A)  識別ＩＤを持つ全てのリソースについて識別ＩＤや１つ以上のメタ情報と担当データベースのアドレスの対応を保持する表と、
(B)  前記表の各エントリの登録回数と
を有し、
前記ディレクトリサービスにより、
(C)  ブローカより要求メッセージを受信し、要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(D)  登録要求に対して前記プロセス(C)から渡された要求メッセージに含まれる識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスの情報をセットにした情報を前記表のエントリとして記録し、当該エントリの登録回数を１つ加算するプロセスと、
(E)  検索要求に対して前記プロセス(C)から渡された要求メッセージに含まれる１つ以上のメタ情報に対応する１つ以上のエントリに記録されている担当データベースのアドレスを回答するプロセスと、
(F)  検索要求に対する回答として１つ以上の担当データベースのアドレスを要求メッセージの送信元のブローカヘ返信するプロセスと
を含むことを特徴とする。
【００１６】
この方法によれば、ディレクトリサービスに記録する情報をリソース単位ではなく担当データベース(目的のリソースの情報を記録しているデータベース)単位にすることにより、ディレクトリサービスの記憶量について、従来の自己説明的な名前を用いる名前解決機構をそのまま適用する場合と比較して、スケーラビリティを大幅に改善することができる。
【００１７】
請求項２に係る発明は、請求項１に記載のリソース情報検索方法において、前記ブローカは、ユーザ端末とディレクトリサービスおよび共通データベース間におけるメッセージのスキーマ変換およびプロトコル変換を行うことを特徴とする。
この方法によれば、ブローカがスキーマ変換およびプロトコル変換を行うことにより、ディレクトリサービスによる逆引き機能をユーザに透過的に提供することが可能である。
【００１８】
請求項３に係る発明は、請求項１又は２に記載の情報検索方法において、データ通信ネットワーク上に配置された各ユーザ用の個人データベースを更に具え、
前記ブローカにより、更に前記プロセス(13)で受信した要求メッセージを個人データベースに転送するプロセスを含み、
前記個人データベースは、
(19)  リソースについて、メタ情報をインデックスとし、それに対応する１つ以上の識別ＩＤを保持する表を有し、
前記個人データベースにより、
(20)  前記ブローカより要求メッセージを受信するプロセスと、
(21)  前記プロセス(20)で受信した要求メッセージ内の命令コードより処理方法を決定するプロセスと、
(22)  前記プロセス(21)から要求メッセージに含まれる識別ＩＤと１つ以上のメタ情報を受け取り、前記(19)の表のエントリとして追加する登録処理プロセスと、
(23)  前記プロセス(21)から要求メッセージに含まれる１つ以上のメタ情報を受け取り、前記(19)の表から当該メタ情報に対応する１つ以上の識別ＩＤを逆引きし、要求メッセージの送信元のユーザ端末へ送信する検索処理プロセスと
を含むことを特徴とする。
この方法によれば、ディレクトリサービスと個人データベースを併用することにより、識別ＩＤを持つ全リソースの情報を逆引きできるだけでなく、個々のユーザに管理可能な範囲の情報については個人データベースを用いて効率よく逆引きでる環境を実現することができる。
【００１９】
請求項４−６に係る発明は、請求項１−３に記載のリソース情報検索方法を実行するリソース情報検索装置であり、これらの発明も上述した請求項１−３に係る発明と同一の作用効果を奏すること勿論である。
【発明の効果】
【００２０】
以上の記載から明らかなように、本発明によれば、膨大な数のリソースを対象としたリソース情報検索機構において、リソースの多様化を反映して今後重要な役割を持つと予想される、自己説明的な名前やメタ情報に基づく情報検索、所謂「名前の逆引き」が容易に達成される。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施の形態について図面を参照して説明する。
【実施例１】
【００２２】
図１は、請求項１に記載のリソース情報検索方法を実現する請求項9に記載のリソース情報検索システム(装置)の実施例の基本構成を示す。
ここでリソース情報検索システムとは、ユーザが所有している、あるいはメタ情報を参照できるなど何らかの利用権を有している物品や情報コンテンツなどの各種リソースについて、ユーザからの要求に応じて、目的のリソース固有の識別ＩＤや当該リソースに関する１つ以上のメタ情報を記録あるいは回答するものである。なお、識別ＩＤやメタ情報の記録方怯としてハードステートとソフトステートが考えられるが、以下ではデータベースで一般的に用いられるハードステートを前提とする。ハードステートとは、登録された情報を明示的に削除されるまで恒久的に保持する方法であり、一方ソフトステートとは、登録された情報を一時的に保持し、一定期間の後に自動的に削除する方法である。
【００２３】
図１において、１０１はユーザ端末を示し、３０１は共通データベースシステム全体、３１１は担当データベースの１つ、３９１は共通データベースシステム内の名前解決機構をそれぞれ示し、５０１は個人データベースの１つを示し、これらはインターネットなどのデータ通信ネットワーク上に配置される。尚、図面を明瞭にするために、ユーザ端末、適当データベースおよび個人データベースを１つだけ示したが、それぞれ複数を配置することが可能であること勿論である．
例えば、リソース情報検索システムが物流における物品の所在を追跡することを目的としている場合では、リソース情報の登録・検索を行うユーザ端末は、消費者を含め、物品の流通経路の各地点に配置されることになる。
【００２４】
図２は実施例１におけるユーザ端末１０１の構成を示す。ユーザ端末１０１には、ユーザが指定するリソースの識別ＩＤ、ユーザが指定するリソースのメタ情報、登録・削除・更新・検索の各要求を識別する命令コード、共通データベースシステムあるいは個々の個人データベースを識別するデータベースの名前、前記の名前とアドレス（要求メッセージの送信先として用いる）の対応表の５種類の情報と、次の４つのプロセスを実行するプログラム２０１，２０２，２０３，２０４が搭載されている。
【００２５】
第１のプログラム２０１は、共通データベースシステムあるいは個人データベースヘの要求メッセージについて、ユーザからの要求に応じて、共通データベース内の名前解決機構および個人データベースを識別する名前とアドレスの対応表を用いて、送付先アドレス（要求メッセージ内の名前が共通データベースシステムを指す場合は共通データベースシステムの名前化帰結機構のアドレス、個人データベースを指す場合には当該個人データベースのアドレス）を決定するプロセスを実行する。
ここで要求メッセージは、ユーザが指定するリソースの識別ＩＤや当該リソースの１つ以上のメタ情報、および登録・削除・更新・検索を識別する命令コード、および共通データベースシステムあるいは個々の個人データベースを識別するデータベースの名前によって構成されている。識別ＩＤの例としてはＡｕｔｏ−ＩＤ構想のＥＰＣ（Electronic Product Code）が挙げられる。メタ情報の例としては、Ａｕｔｏ−ＩＤ構想のＰＭＬで記述されたものや、一般的なＸＭＬで記述されたもの、ＩＮＳ/Ｔｗｉｎｅのｓｔｒａｎｄなどが挙げられる。
【００２６】
第２のプログラム２０２は、プログラム２０１によって起動され、プログラム２０１で決定したアドレスが共通データベースシステム内の名前解決機構３９１のアドレスである場合に、識別ＩＤの名前解決要求を当該名前解決機構へ送信し、回答として担当データベース（当該識別ＩＤに対応するデータベースであり、当該識別ＩＤを持つリソースについて情報を記録・回答するデータベース）のアドレスを受信するプロセスを実行する。
【００２７】
第３のプログラム２０３は、プログラム２０１あるいはプログラム２０２によって起動され、プログラム２０１が決定した個人データベース５０１のアドレス、あるいはプログラム２０２が受信した担当データベース３ｌｌのアドレスに宛てて、要求メッセージを送信するプロセスを実行する。
【００２８】
第４のプログラム２０４は、プログラム２０３によって起動され、プログラム２０３が要求メッセージを送信した担当データベース３１１あるいは個人データベース５０１より、完了メッセージ、あるいは検索要求に対する回答である目的のリソースの識別ＩＤあるいは当該リソースのメタ情報の集合を受信するプロセスを実行する。
【００２９】
図３は実施例１における共通データベースシステムの構成を示す。共通データベースシステム３０１内の担当データベース３１１には、識別ＩＤとそれに対応するメタ情報を保持する表と、次の６つのプログラム４１１，４１２，４１３，４１４，４１５，４１６が、名前解決機構３９１には、識別ＩＤとそれに対応する担当データベースのアドレスを保持する表と、後述する３つのプログラム４９１，４９２，４９３がそれぞれ搭載されている。
【００３０】
担当データベース３ｌｌの第１のプログラム４１１は、要求メッセージを受信するプロセスを実行する。プログラム４１１は常に起動されている。
第２のプログラム４１２は、プログラム４１１によって起動され、プログラム４１１が受信した要求メッセージ中の命令コードより処理方法を決定し、各処理に対応するプログラム４１３〜４１６のいずれか１つのプログラムへ識別ＩＤや１つ以上のメタ情報を渡すプロセスを実行する。
【００３１】
第３のプログラム４１３は、プログラム４１２から識別ＩＤと１つ以上のメタ情報を受け取り、識別ＩＤとそれに対応するメタ情報を保持する表にエントリとして追加し、完了メッセージを要求メッセージの送信元へ返信する登録処理プロセスを実行する。ここで、表は識別ＩＤをインデクスとする。
【００３２】
第４のプログラム４１４は、プログラム４１２から識別ＩＤを受け取り、表から当該識別ＩＤに対応するエントリを削除し、完了メッセージを要求メッセージの送信元へ返信する削除処理プロセスを実行する。
【００３３】
第５のプログラム４１５は、プログラム４１２から識別ＩＤと１つ以上のメタ絹報を受け取り、表内の当該識別ＩＤに対応するエントリのメタ情報を上書きし、完了メッセージを要求メッセージの送信元へ返信する更新処理プロセスを実行する。
【００３４】
第６のプログラム４１６は、プログラム４１２から識別ＩＤを受け取り、表から当該識別ＩＤに対応する一つ以上のメタ情報を見つけ出し、回答として要求メッセージの送信元へ返信する検索処理プロセスを実行する。プログラム４１３〜４１６はプログラム４１２によって起動される。
【００３５】
名前解決機構３９１の第１のプログラム４９１は、名前解決の要求メッセージを受信するプロセスを実行する。プログラム４９１は常に起動されている。
弟２のプログラム４９２は、プログラム４９１によって起動され、プログラム４９１が受信した要求メッセージ内の識別ＩＤに基づいて、識別ＩＤとそれに対応する担当データベースのアドレスを保持する表から当該識別ＩＤの担当データベースのアドレスを決定するプロセスを実行する。やはりここでも、表は識別ＩＤをインデクスとする。
【００３６】
第３のプログラム４９３は、プログラム４９２によって起動され、プログラム４９２が決定したアドレスを要求メッセージの送信元へ返信するプロセスを実行する。
以上のようにして共通データベースシステム３０１は、識別ＩＤに基づいて、当該識別ＩＤを持つリソースについて情報を記録あるいは回答する。
【００３７】
図４は実施例１における個人データベース５０１の構成を示す。個人データベース５０１には、ユーザが何らかの利用権を有しているリソースについて識別ＩＤとそれに対応するメタ情報を保持する表と、次の６つのプログラム６０１，６０２，６０３，６０４，６０５，６０６が搭載されている。
【００３８】
第１のプログラム６０１は、要求メッセージを受信するプロセスを実行する。プログラム６０１は常に駆動されている。
第２のプログラム６０２は、プログラム６０１によって起動され、プログラム６０１が受信した要求メッセージ中の命令コードより処理方法を決定し、各処理に対応するプログラム６０３〜６０６のいずれか１つのプログラムへ、識別ＩＤや１つ以上のメタ情報を渡すプロセスを実行する。
【００３９】
第３のプログラム６０３は、プログラム６０２から識別ＩＤと１つ以上のメタ情報を受け取り、識別ＩＤとそれに対応するメタ情報を保持する表にエントリとして追加し、完了メッセージを要求メッセージの送信元へ返信する登録処理プロセスを実行する。ここでは、表はメタ情報をインデクスとする。
【００４０】
第４のプログラム６０４は、プログラム６０２からメタ情報を受け取り、表から当該メタ情報に対応するエントリを削除し、完了メッセージを要求メッセージの送信元へ返信する削除処理プロセスを実行する。
【００４１】
第５のプログラム６０５は、プログラム６０２から識別ＩＤと１つ以上のメタ情報を受け取り、表内の当該メタ情報に対応するエントリの識別ＩＤを上書きし、完了メッセージを要求メッセージの送信元へ返信する更新処理プロセスを実行する。
第６のプロセス６０６は、プログラム６０２からメタ情報を受け取り、表から当該メタ情報に対応する識別ＩＤあるいは他のメタ情報を見つけ出し、回答として要求メッセージの送信元へ返信する検索処理プロセスを実行する。プログラム６０３〜６０６はプログラム６０２によって起動される。
【００４２】
このようにして個人データベース５０１は、メタ情報に基づいて、当該メタ情報に対応するリソースについて情報を記録あるいは回答する。個人データベース５０１にリソースの識別ＩＤやメタ情報の登録が行われるのは、ユーザが当該リソースに対する何らかの利用権を得た場合であり、それは例えばそのリソースを購入して個人の所有物となった場合などである。
【実施例２】
【００４３】
図５は請求項２に記載のリソース情報検索方法を実現する請求項１０に記載のリソース情報検索システムの実施例の基本構成を示し、図６は実施例２におけるユーザ端末１０１及びブローカ７０１の構成を示す。本実施例２と実施例１とは、本例では要求メッセージを適切なデータベースへ転送するブローカ７０１を備える点が相違するのみであり、同一の構成要素は同一の符号で示してある。
【００４４】
図６に示すように、ユーザ端末１０１には、ユーザが指定するリソースの識別ＩＤ、ユーザが指定するリソースのメタ情報、登録・削除・更新・検索の各要求を識別する命令コード、共通データベースシステムあるいは個々の個人データベースを識別するデータベースの名前、前記名前とアドレス（要求メッセージの送信先として用いる）の対応表の５種類の情報と、次の２つのプログラ２０５，２０６が搭載されている。
【００４５】
第１のプログラム２０５は、要求メッセージを任意のブローカに送信するプロセスを実行する。ここで要求メッセージとは、実施例１のものと同じである。
第２のプログラム２０６は、プログラム２０５によって起動され、プログラム２０５が要求メッセージを送信したブローカより、完了メッセージ、あるいは回答である目的のリソースの識別ＩＤあるいは当該リソースのメタ情報の集合を受信するプロセスを実行する。
【００４６】
ここでは、ユーザ端末からブローカヘの要求メッセージの送信先アドレスは、明示的にブローカのアドレスのいずれかを指定していることを想定している。しかし、ユーザ端末がブローカの所在を把握しておらず、送信先アドレスに任意のアドレスを指定している場合にも、要求メッセージをブローカヘ到達させることが可能であり、これによりユーザおよびユーザ端末は「透過的に」要求メッセージをブローカヘ到達させることができる。その具体的な方法として、ｗｅｂのプロキシキャッシュヘの接続制御の一種であるトランスパレントキャッシングと同様に、ユーザ端未から任意のアドレスに向けて送信された要求メッセージをＮＡＴ（Network Address Translation）装置でリダイレクトする方法が挙げられる。
【００４７】
ブローカの７０１には、共通データベースシステムあるいは個々の個人データベースを識別するデータベースについての名前とアドレス（要求メッセージの送信先として用いる）の対応表と、次の６つのプログラム８０１，８０２，８０３，８０４，８０５，８０６が搭載されている。
【００４８】
第１のプログラム８０１は、ユーザ端末から要求メッセージを受信するプロセスを実行する。
第２のプログラム８０２は、プログラム８０１によって起動され、プログラム８０１が受信した共通データベースシステムあるいは個人データベースヘの要求メッセージについて、共通データベース内の名前解決機構および個人データベースを識別する名前とアドレスの対応表を用いて、送信先アドレス（要求メッセージ内の名前が共通データベースシステムを指す場合は共通データベースシステムの名前解決機構のアドレス、個人データベースを指す場合には当該個人データベースのアドレス）を決定するプロセスを実行する。
【００４９】
第３のプログラム８０３は、プログラム８０２において決定されたアドレスが共通データベースシステムの名前解決機構のアドレスである場合に起動され、プログラム８０１が受信した要求メッセージ内の識別ＩＤに対する名前解決の要求メッセージを当該名前解決機構へ送信し、回答として担当データベースのアドレスを受信するプロセスを実行する。
【００５０】
第４のプログラム８０４は、プログラム８０２において決定されたアドレスが個人データベースのアドレスである場合にはプログラム８０２により、そうでない場合にはプログラム８０３より起動され、前者の場合プログラム８０２が決定した個人データベースのアドレス、後者の場合プログラム８０３が受信した担当データベースのアドレスへ、要求メッセージを転送するプロセスを実行する。
【００５１】
第５のプログラム８０５は、プログラム８０４より起動され、プログラム８０４が転送した担当データベースあるいは個人データベースより、完了メッセージ、あるいは回答である目的のリソースの誠別ＩＤあるいは当該リソースのメタ情報の集合を受信するプロセスを実行する。
第６のプログラム８０６は、プログラム８０５より起動され、プログラム８０５が受信した完了メッセージ、あるいは回答をユーザ端末に転送するプロセスを実行する。
【００５２】
共通データベースシステム３０ｌの構成は、図３に示す実施例１のものと同等であり、実施例１に記載された情報群・プログラム群と同等の情報群・プログラム群が搭載されている。ただし、本例では、実施例１においてユーザ端末と通信を行うプログラムに関しては、ユーザ端末の代わりにブローカと通信を行う。
【００５３】
個人データベース５０１の構成は図４に示す実施例１のものと同等であり、実施例１に記載された情報群・プログラム群と同等の情報群・プログラム群が搭載れている。ただし、本例では、実施例１においてユーザ端末と通信を行うプログラムに関しては、ユーザ端末の代わりにブローカと通信を行う。
【００５４】
この実施例２では、要求メッセージを適切なデータベースへ転送する処理をブローカが代行するので、ユーザ端末の構成が簡単になる。
また、ブローカ７０１が、プログラム８０４において、要求メッセージを個人データベースに転送する際に、ユーザ端末から受信した要求メッセージと個人データベースが想定する要求メッセージのスキーマ（フォーマット）および使用プロトコルが異なる墳合は、スキーマ変換およびプロトコル変換を行い、同様に、プログラム８０５においても、必要に応じてスキーマ交換およびプロトコル変換を行うことにより、個人データベースによる逆引き機能をユーザに透過的に提供することができる(請求項３、１１)。
【実施例３】
【００５５】
本例は、インターネットなどのデータ通信ネットワーク上に構築される実施例１あるいは実施例２と同じ構成のリソース情報検索システムにおいて、ユーザ端末が扱う要求メッセージに含まれる共通データベースシステムあるいは個々の個人データベースを識別するデータベースの名前の代わりに、コンテキスト情報を用いて使用すべきデータベースを決定できるようにしたものであり、請求項４および１２に記載のリソース情報検索方法および装置の実施例に相当する。
【００５６】
コンテキスト情報の例としては、ユーザＩＤ情報、ユーザの位置情報などが挙げられる。コンテキスト情報は、各種センサなどを用いて自動的に得られるものが良い。オフィスにいる場合にはオフィス用データベースを使うなど、ユーザや利用状況により、使用すべき個人データベースは変化し、通常、ユーザはその都度データベースの名前を選択する必要があるが、こうしたコンテキスト情報をデータベースの名前の代わりに用いることにより、ユーザの負荷を低減することができる。
【００５７】
この目的のために、本例では、実施例１と同じ構成の場合には、ユーザ端末に搭載されたプログラム２０１の代わりに、ユーザからの共通あるいは個人データベースヘの要求メッセージに対し、コンテキスト情報とそれに対応する共通データベース内の名前解決機構および個人データベースのアドレスの対応表を用いて、要求メッセージ中のコンテキスト情報に対応する送信先アドレス（共通データベースシステムの名前解決機構ないしは個人データベースのアドレス）を決定するプログラムを搭載する。
また、実施例２と同じ構成の場合には、ブローカに搭載されたプログラム８０２の代わりに、プログラム８０１が受信した要求メッセージに対し、コンテキスト情報とそれに対応する共通データベース内の名前解決機構および傭人データベースのアドレスの対応表を用いて、要求メッセージ中のコンテキスト情報に対応する送信先アドレス（共通データベースシステムの名前解決機構ないしは個人データベースのアドレス）を決定するプログラムを搭載する。
【実施例４】
【００５８】
図７は請求項５に記載のリソース情報検索方法を実現する請求項１3に記載のリソース情報検索システムの実施例の基本構成を示し、図８は実施例４におけるブローカの構成を示し、図９は実施例４におけるディレクトリサービスの構成を示す。本例と実施例２、３との違いは、本例では固有の識別ＩＤを持つ全てのリソースに対して、メタ情報に基づくリソース情報検索を行うディレクトリサービス９０１を利用する点にある。尚、図と説明を明瞭、簡便にするために、個人データベースを省略したが、勿論、ディレクトリサービスと個人データベースを併用することが可能である。また、実施例２、３と対応する構成要素は同一の符号で示してある。
【００５９】
図８において、ユーザ端末１０１には、実施例２に記載された情報群およびプログラム群と同じものが搭載されている。ただし要求メッセージは、個人データベースを併用しない場合には、ユーザが指定するリソースの識別ＩＤや当該リソースの1つ以上のメタ情報、および登録・削除・更新・検索を識別する命令コードのみで構成することができる点が異なる。
共通データベースシステム３０１にも、実施例２に記載された情報群およびプログラム群と同じものが搭載されている。
【００６０】
ブローカの７０１には、６つのプログラム８０７，８０８．８０９，８１０，８１１，８１２が搭載されている。
第１のプログラム８０７は、ユーザ端末から要求メッセージを受信するプロセスを実行する。プログラム８０７は常に起動されている。
第２のプログラム８０８は、プログラム８０７によって起動され、プログラム８０７が受信した要求メッセージ内の識別ＩＤあるいは後述するプログラム８１２が受信した回答に含まれる識別ＩＤに対する名前解決の要求メッセージを当該名前解決機構へ送信し、回答として担当データベースのアドレスを受信するプロセスを実行する。
【００６１】
第３のプログラム８０９は、プログラム８０８によって起動され、プログラム８０８が受信したアドレスの担当データベースヘ、プログラム８０７が受信した要求メッセージを転送するプロセスを実行する。
【００６２】
第４のプログラム８１０は、プログラム８０７によって起動され、プログラム８０７が受信した要求メッセージの命令コードが登録・削除・更新のいずれか１つであるか又は命令コードが検索であり且つ要求メッセージ内に識別ＩＤが含まれないことを確認し、当該要求メッセージをディレクトリサービスに転送するプロセスを実行する。
【００６３】
第５のプログラム８１１は、プログラム８０９によって起動され、プログラム８０９が要求メッセージを転送した担当データベースより登録・削除・更新の各要求の完了メッセージ、あるいは検索要求に対する回答として識別ＩＤや１つ以上のメタ情報を受信し、ユーザ端末へ転送するプロセスを実行する。
第６のプログラム８１２は、プログラム８１０によって起動され、プログラム８１０が要求メッセージを転送したディレクトリサービスより登録・削除・更新の各要求の完了メッセージ、あるいは検索要求に対する回答として１つ以上の識別ＩＤを受信するプロセスを実行する。
【００６４】
以上のようにしてブローカ７０１は、ユーザ端末からの要求メッセージが登録・削除・更新のいずれかである塘合は、要求メッセージをディレクトリサービス９０１および、共通データベース内の名前解決機３９９１に指示される担当データタベース３１１へ、それぞれ転送する。一方、要求メッセージが検索である場合は、まず要求メッセージに識別ＩＤが含まれるか確認する。検索要求に諦別ＩＤが含まれるなら、ブローカ７０１は当該検索要求をそのまま共通データベースシステム３０１へ転送する。検索要求に識別ＩＤが含まれないなら、当該検索要求をディレクトリサービス９０１へ転送し、次に９０１より回答として得られた識別ＩＤについて名前解決機構３９１に名前解決を要求し、名前解決機構３９１より回答として指示された担当データベース３１１へ検索要求を改めて転送する。
【００６５】
ディレクトリサービスの９０１には、図９に示すように、識別ＩＤを持つ全リソースについての識別ＩＤとメタ情報の対応を保持する表と、６つのプログラムＡ０１〜Ａ０６が搭載されている。
第１のプログラムＡ０１は、常に起動されており、任意のブローカより転送される要求メッセージを受信し、要求メッセージ内の命令コードに対応してプログラムＡ０２〜Ａ０５のいずれか１つのプログラムヘ要求メッセージに含まれる識別ＩＤや１つ以上のメタ情報を渡すプロセスを実行する。
第２のプログラムＡ０２は、プログラムＡ０１によって起動され、プログラムＡ０１が受信した登録要求について識別ＩＤや１つ以上のメタ情報を受け取り、それらを識別ＩＤとメタ情報の対応を保持する表のエントリとして記録するプロセスを実行する。ここで、表はメタ情報をインデクスとする。
【００６６】
第３のプログラムＡ０３は、プログラムＡ０ｌによって起動され、プログラムＡ０１が受信した削除要求について識別ＩＤや１つ以上のメタ情報を受け取り、それらに対応する表のエントリを削除するプロセスを実行する。
第４のプログラムＡ０４は、プログラムＡ０ｌによって起動され、プログラムＡ０ｌが受信した更新要求について識別ＩＤや１つ以上のメタ情報を受け取り、それらに対応する表のエントリを更新するプロセスを実行する。
第５のプログラムＡ０５は、プログラムＡ０ｌによって起動され、プログラムＡ０１が受信した検索要求について１つ以上のメタ情報を受け取り、それらに対応する表のエントリに記録されている識別ＩＤを回答するプロセスを実行する。
【００６７】
第６のプログラムＡ０６は、プログラムＡ０２〜Ａ０６のいずれか１つのプログラムによって起動され、その起動したプログラムより登録・削除・更新の各要求の完了メッセージ、あるいは検索要求に対する回答として１つ以上の識別ＩＤを受け取り、プログラムＡ０１が受信した要求メッセージの送信元のブローカヘ送信するプロセスを実行する。
【００６８】
以上のように、本例では、ディレクトリサービスが、メタ情報に基づいて、当該メタ情報に対応するリソースについて情報（特に、識別ＩＤ）を記録あるいは回答する。
また、本例でも、ブローカ７０１が、プログラム８１０において、要求メッセージをディレクトリサービスに転送する際に、ユーザ端末から受信した要求メッセージとディレクトリサービスが想定する要求メッセージのスキーマ（フォーマット）および使用プロトコルが異なる場合は、スキーマ変換およびプロトコル変換を行い、同様に、プログラム８０９においても、必要に応じてスキーマ変換およびプロトコル変換を行うことにより、ディレクトリサービスによる逆引き機能をユーザに透過的に提供することができる(請求項７、１５)。
【実施例５】
【００６９】
図１０および図１１は請求項６に記載のリソース情報検索方法を実現する請求項１４に記載のリソース情報検索システムの実施例におけるブローカおよびディレクトリサービスの構成を示す。本実施例５と実施例４の違いは、ディレクトリサービスがメタ情報に対応するリソース情報として共通データベースシステム内の担当データベースのアドレスを記録あるいは回答するところにある。
【００７０】
ユーザ端末１０１には、実施例４に記載された情報群およびプログラム群と同じものが搭載されている。
共通データベースシステム３０１には、実施例２に記載されたプログラム群と同じプログラム群が搭載されている。
【００７１】
ブローカの７０１には、図１０に示すように、６つのプログラムが搭載されている。
第１のプログラム８０７は、実施例４に記載のプログラム８０７と同じである。
第２のプログラム８１３は、プログラム８０７あるいは後述するプログラム８１５によって起動され、プログラム８０７が受信した要求メッセージ内の識別ＩＤに対する名前解決の要求メッセージを当該名前解決機構へ送信し、回答として担当データベースのアドレスを受信するプロセスを実行する。
【００７２】
第３のプログラム８１４は、プログラム８１３あるいは後述するプログラム８１６によって起動され、プログラム８１３がアドレスを受信した担当データベースあるいはプログラム８１６が回答としてアドレスを受信した担当データベースへ、プログラム８０７が受信した要求メッセージを転送するプログラムを実行する。
第４のプログラム８１５は、プログラム８０７によって起動され、プログラム８０７が受信した要求メッセージの命令コードが登録・削除・更新のいずれかであるか又は命令コードが検索であり且つ要求メッセージ内に識別ＩＤが含まれないことを確認し、登録票求・削除要求・更新要求の場合は当該要求メッセージに、プログラム８１３より得られる担当データベースのアドレスを追加したメッセージを、識別ＩＤを含まない検索要求の場合は当該要求メッセージをそのまま、ディレクトリサービスへ転送するプロセスを実行する。
【００７３】
第５のプログラム８１１は、実施例４に記載のプログラム８１１と同じである。
第６のプログラム８１６は、プログラム８１５によって起動され、プログラム８１５が要求メッセージを転送したディレクトリサービスより登録・削除・更新の各要求の完了メッセージを受信する、あるいは検索要求に対する回答として１つ以上の担当データベースのアドレスを受信してプログラム８１４へ渡すプロセスを実行する。
【００７４】
以上のようにしてブローカ７０１は、ユーザ端末からの要求メッセージが登録・削除・更新のいずれかである場合は、共通データベース内の名前解決機構３９１に指示される担当データベース３１１へ転送し、且つ、共通データベースシステム内の名前解決槻構３９１を利用して得られる担当データベース３１１のアドレスを追加した要求メッセージをディレクトリサービス９０１へも転送する。一方、要求メッセージが検索である場合は、まず要求メッセージに識別１Ｄが含まれるか確認する。換索要求に識別ＩＤが含まれるなら、ブローカ７０１は当該検索要求をそのまま共通データベースシステム８０１へ転送する。検索要求に識別ＩＤが含まれないなら、当該検索要求をディレクトリサービス９０１へ転送し、次にディレクトリサービス９０１より回答としてアドレスが指示された担当データベース３１１へ検索要求を改めて転送する。
【００７５】
ディレクトリサービス９０１には、図１１に示すように、識別ＩＤを持つ全リソースについて識別ＩＤやメタ情報と担当データベースのアドレスの対応を保持する対応表と、該対応表の各エントリの登録回数の２種類の情報と、次の６つのプログラムが搭載されている。
第１のプログラムＡ０７は、常に起動されており、任意のブローカより転送される要求メッセージを受信し、要求メッセージ内の命令コードに対応してプログラムＡ０８−Ａ１１のいずれか１つのプログラムヘ、要求メッセージに含まれる識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスを渡すプロセスを実行する。
【００７６】
第２のプログラムＡ０８は、プログラムＡ０７によって起動され、プログラムＡ０７が受信した登録要求について識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスを受け取り、これらの情報を識別ＩＤやメタ情報と担当データベースの対応を保持する表のエントリとして記録し、当該エントリの登録回数を１つ加算するプロセスを実行する。ここで、表はメタ情報をインデックスとする。エントリの登録回数は、当該エントリに対応する担当データベースにおいて、当該エントリの識別ＩＤやメタ情報に対応するリソースが記録されている数を表している。
第３のプログラムＡ０９は、プログラムＡ０７によって起動され、プログラムＡ０７が受信した削除要求について識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスを受け取り、それらに対応する表のエントリの登持回数を１つ減算し、登録回数の値がゼロになる場合は当該エントリを削除するプロセスを実行する。
【００７７】
第４のプログラムＡ１０は、プログラムＡ０７によって起動され、プログラムＡ０７が受信した更新要求について識別ＩＤや１つ以上のメタ情報および担当データベースのアド
レスを受け取り、それらに対応する表のエントリを更新するプロセスを実行する。
第５のプログラムＡ１１はプログラムＡ０７によって起動され、プログラムＡ０７が受信した検索要求について識別ＩＤや１つ以上のメタ情報および担当データベースのアドレスを受け取り、それらに対応する表のエントリに記録されている担当データベースのアドレスを回答するプロセスを実行する。
第６のプログラムＡ１２は、プログラムＡ０８−Ａ１１のいずれか１つのプログラムによって起動され、その起動したプログラムより登録・削除・更新の各要求完了メッセージ、あるいは検索要求に対する回答として１つ以上の担当データベースのアドレスを受け取り、プログラムＡ０７が受信した要求メッセージの送信元のブローカヘ返信するプログラムを実行する。
【００７８】
以上のように、本例では、ディレクトリサービスはメタ情報に基づいて、当該メタ情報に対応するリソースについて特に担当データベースのアドレスを記録あるいは回答する。
また、本例でも、ブローカ７０１が、上記のプログラム８１５において、要求メッセージをディレクトリサービスに転送する際に、ユーザ端末から受信した要求メッセージとディレクトリサービスが想定する要求メッセージのスキーマ（フォーマット）および使用プロトコルが異なる場合は、スキーマ変換およびプロトコル変換を行い、同様に、プログラム８１４においても、必要に応じてスキーマ変換およびプロトコル変換を行うことにより、ディレクトリサービスによる逆引き機能をユーザに等価的に提供することができる(請求項７、１５)。
【００７９】
尚、上述した実施例４および５では、個人データベースを省略したが、ディレクトリサービスと個人データベースを併用することができること勿論であり、図１２はディレクトリサービスと個人データベースを併用したシステムの基本構成を示す。
【産業上の利用可能性】
【００８０】
本発明は、膨大な数のリソースを対象としたリソース情報検索機構において、リソースの多様化を反映して今後重要な役割を持つと予想される、自己説明的な名前やメタ情報に基づく情報検索、所謂「名前の逆引き」を容易にする。
【図面の簡単な説明】
【００８１】
【図１】本発明の実施例１のシステムの基本構成を示す図である。
【図２】実施例１におけるユーザ端末の構成を示す図である。
【図３】実施例１における共通データベースシステムの構成を示す図である。
【図４】実施例１における個人データベースの構成を示す図である。
【図５】本発明の実施例２、３のシステムの基本構成を示す図である。
【図６】実施例２におけるユーザ端末およびブローカの構成を示す図である。
【図７】実施例４，５のシステムの基本構成を示す図である。
【図８】実施例４におけるブローカの構成を示す図である。
【図９】実施例４におけるディレクトリサービスの構成を示す図である。
【図１０】実施例５におけるブローカの構成を示す図である。
【図１１】実施例５におけるディレクトリサービスの構成を示す図である。
【図１２】本発明のディレクトリサービスと個人データベースを併用したシステムの基本構成を示す図である。
【符号の説明】
【００８２】
１０１  ユーザ端末
３０１  共通データベースシステム
３１１  担当データベース
３９１  名前解決機構
５０１  個人データベース
７０１  ブローカ
９０１  ディレクトリサービス
【図１】
0004781631.tif 000002
【図２】
0004781631.tif 000003
【図３】
0004781631.tif 000004
【図４】
0004781631.tif 000005
【図５】
0004781631.tif 000006
【図６】
0004781631.tif 000007
【図７】
0004781631.tif 000008
【図８】
0004781631.tif 000009
【図９】
0004781631.tif 000010
【図１０】
0004781631.tif 000011
【図１１】
0004781631.tif 000012
【図１２】
0004781631.tif 000013