(57)【要約】      （修正有）【課題】複数の名前空間や名前解決機構を使い分けることができ、ユビキタスサービスに柔軟に対応できる名前解決システムを提供する。【解決手段】ネットワーク100を介してユーザ端末501と複数の名前解決機構との間に仲介装置701を接続する。仲介装置701は、ユーザ端末から送られてきた名前解決要求を受信した際、受信した名前解決要求のリソース識別情報と関連する名前解決機構を検索し、得られた名前解決機構のエントリポイントに当該名前解決要求を転送する。名前解決要求を受信したエントリポイントは、当該名前解決機構に含まれるリゾルバに当該名前解決要求を転送する。名前解決機構のリゾルバは、当該名前解決要求に含まれるリソースを指定する名前識別情報から当該リソースのアドレスを求め、得られたリソースのアドレスをエントリポイントを介して仲介装置に送信し、仲介装置からユーザ端末に転送する。【選択図】図１
2005094485.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に分散管理されているリソースについて、ユーザからのアクセスに応じて目的とするリソースのアドレスを当該ユーザに提供する名前解決システムにおいて、
ネットワークに接続され、リソース識別情報と当該リソース識別情報により指定されるリソースのアドレスとの関係を格納した記憶手段を有する１個又は複数個のリゾルバから構成され、少なくとも１個のエントリポイントが指定されている複数の名前解決機構と、
ネットワークを介して前記複数の名前解決機構及びユーザ端末に接続され、ユーザ端末から送られてきた名前解決要求を受信し、対応する名前解決機構のエントリポイントに転送する１個又は複数個の仲介装置とを具え、
前記仲介装置は、受信した名前解決要求に含まれるリソース識別情報からリソースを指定する名前及び当該名前が属する名前空間識別情報又は名前解決を行う名前解決機構の識別情報を取り出す手段と、名前空間識別情報と当該名前空間に含まれる名前について名前解決を行う名前解決機構の識別情報との関係を格納した記憶手段とを有し、ユーザ端末から送られてきた名前解決要求を受信した際、受信した名前解決要求に含まれるリソース識別情報から関連する名前解決機構を求め、得られた名前解決機構のエントリポイントに当該名前解決要求を転送し、
前記名前解決要求を受信したエントリポイントは、当該名前解決機構に含まれるリゾルバに当該名前解決要求を転送し、
名前解決要求を受信した名前解決機構のリゾルバは、当該名前解決要求に含まれるリソースを指定する名前から当該リソースのアドレスを求め、得られたリソースのアドレスをエントリポイントを介して仲介装置に送信し、仲介装置からユーザ端末に返送することを特徴とする名前解決システム。
【請求項２】
請求項１に記載の名前解決システムにおいて、前記ユーザ端末から仲介装置に送信される名前解決要求に含まれるリソース識別情報が、目的とするリソースを指定する名前と、当該名前が属する名前空間識別情報又は名前解決を行う名前解決機構の識別情報とを含むことを特徴とする名前解決システム。
【請求項３】
請求項１に記載の名前解決システムにおいて、前記ユーザ端末から仲介装置に送信される名前解決要求に含まれるリソース識別情報が、目的とするリソースを特定する名前だけを含み、前記仲介装置は、受信したリソース識別情報に含まれる名前から当該名前が属する名前空間識別情報を取り出す手段を有し、得られた名前空間識別情報に基づいて対応する名前解決機構のエントリポイントに当該名前解決要求を転送することを特徴とする名前解決システム。
【請求項４】
請求項１から３までのいずれか１項に記載の名前解決システムにおいて、前記名前空間識別情報をURIにより表記することを特徴とする名前解決システム。
【請求項５】
請求項１から４までのいずれか１項に記載の名前解決システムにおいて、前記エントリポイントとしてサーバ又はリゾルバが指定され、エントリポイントとして指定されたサーバ又はリゾルバは、当該名前解決機構に含まれるリゾルバのアドレス情報を有し、仲介装置から名前解決要求を受信した際、保持するリゾルバのアドレス情報に基づいて名前解決要求をリゾルバに転送することを特徴とする名前解決システム。
【請求項６】
請求項1から４までのいずれか１項に記載の名前解決システムにおいて、前記名前解決機構の識別情報として各名前解決機構のエントリポイントのアドレス情報を用いることを特徴とする名前解決システム。
【請求項７】
請求項１から６までのいずれか1項に記載の名前解決システムにおいて、前記名前解決機構は、エントリポイントを動的に変更する手段を有し、エントリポイントを変更した場合当該名前解決機構に接続されていれている仲介装置にエントリポイント変更情報を送信することを特徴とする名前解決システム。
【請求項８】
請求項７に記載の名前解決システムにおいて、前記仲介装置は、名前解決機構とそのエントリポイントのアドレスとの関係を規定したアドレス情報を記憶する手段を有し、名前解決機構からエントリポイントの変更情報を受け取った際、前記アドレス情報を更新することを特徴とする名前解決システム。
【請求項９】
請求項１から７までのいずれか１項に記載の名前解決システムにおいて、前記名前解決機構として、異なる形式の複数の名前解決機構を有することを特徴とする名前解決システム。
【請求項１０】
請求項９に記載の名前解決システムにおいて、前記名前解決機構として、ドメインネームシステム（DNS）及びインテンショナルネーミングシステム（INS）を含むことを特徴とする名前解決システム。
【請求項１１】
請求項１０に記載の名前解決システムにおいて、前記DNSのエントリポイントとして名前サーバを有し、前記INSのエントリポイントとしてブートストラップサーバを有することを特徴とする名前解決システム。
【請求項１２】
請求項１に記載の名前解決システムにおいて、前記ユーザ端末から仲介装置に送信される名前解決要求が、複数のリソース識別情報を有する論理式を含み、前記仲介装置は、各名前空間に対応する各名前解決機構のエントリポイントに当該名前解決要求をそれぞれ転送し、各名前解決機構から送られてきたアドレスについて集合演算処理を実行し、当該演算処理の結果として得られたアドレスをユーザ端末に返送することを特徴とする名前解決システム。
【請求項１３】
請求項１２に記載の名前解決システムにおいて、前記ユーザ端末から仲介装置に送信される名前解決要求に含まれるリソース識別情報が、目的とするリソースを特定する名前識別情報だけを含み、前記仲介装置は、受信したリソース識別情報に含まれる名前から当該名前が属する名前空間識別情報を取り出す手段を有し、得られた名前空間識別情報に基づいて対応する複数の名前解決機構のエントリポイントに当該名前解決要求をそれぞれ転送することを特徴とする名前解決システム。
【請求項１４】
名前解決システムに用いられ、ユーザ端末から送られてきた名前解決要求を対応する名前解決機構に転送し、名前解決機構から送られてきたリソースのアドレスをユーザ端末に転送する仲介装置であって、
ユーザ端末及び名前解決機構との間においてデータ転送を行う通信手段と、
ユーザ端末から送られてきた名前解決要求のリソース識別情報から、目的とするリソースを指定する名前及び当該名前が属する名前空間の識別情報又は名前解決を行う名前解決機構の識別情報を取り出す手段と、
名前空間識別情報と当該名前空間に属する名前について名前解決を行う名前解決機構との関係を格納した記憶手段とを具え、
ユーザ端末から送られてきた名前解決要求を対応する名前解決機構に転送し、名前解決機構から送られてきた目的とするリソースのアドレスをユーザ端末に転送することを特徴とする仲介装置。
【請求項１５】
請求項１４に記載の仲介装置において、さらに、受信したリソース識別情報に含まれる名前から当該名前が属する名前空間の識別情報を取り出す手段を有し、取り出された名前空間識別情報に対応する名前解決機構に当該名前解決要求を転送することを特徴とする仲介装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に分散管理されている複数のリソースについて、ユーザからのアクセスに応じて目的とするリソースのアドレス又は識別子を提供する名前解決システム、特にユビキタスサービスに柔軟に対応できると共に複数の名前空間や名前解決機構を使い分けることができる名前解決システムに関するものである。
【背景技術】
【０００２】
ファイルなどのリソースをネットワークを介して利用するシステムにおいて、ファイル名などの「名前」を与えて、「名前」に対応するリソースのある場所のアドレスを回答する名前解決機構は、今後のデータ通信ネットワークで、非常に重要な位置を占めると考えられる。名前と名前解決のシステムを用いることで、ユーザは、リソースの名前さえ記憶していれば、実際のネットワークアドレスを知ることなく、目的のリソースを利用できる。なお、システム内で実際に名前解決を実行する装置はリゾルバと呼ばれる。
【０００３】
名前解決機構のうち、現在、最もよく知られているのは、インターネットのDNS（Domain Name System）である。このシステムは、メールアドレスやURLに含まれるFQDN（Fully Qualified Domain Name）を「名前」として与えると、対応するIPアドレスを回答するものである。DNSは、FQDNを構成するドメインが階層化されていることを利用し、リゾルバの構成も階層化している。このため、システムの規模が増大しても、比較的効率的に名前解決を実行できるが、名前空間が階層構成でない場合は、適用に問題が生じる。
【０００４】
一般的な名前空間を対象にした名前解決を水平分散のリゾルバ構成の下で行うことで、大規模化しても効率的に動作する機構として、CAN（Content Addressable Network）と称されている研究結果（例えば、非特許文献１参照）及びChordと称されている研究結果（例えば、非特許文献２参照）が発表された。これらの機構は、名前をハッシュ関数によりハッシュキーに変換することで名前空間の分割及び名前解決の分散処理を機械的に行う技術である。CANやChordでは、DNSと異なり、リゾルバ間のネットワークはアドホッ
クに構築され、システムを利用するユーザ端末の増大に柔軟に対応できる。ユーザ端末がCANやChordを利用するには、エントリポイントとして稼動中のリゾルバを1つ知る必要があるが、リゾルバの構成がアドホックネットワークであるため個々のリゾルバのシステムヘの接続は断続的となり、エントリポイントを固定的に指定することが困難である。
【０００５】
今後の情報流通ネットワークで主要なサービスとなり得るユビキタスサービスは、空間的制約を超越した「いつでも、どこでも、誰とでも」情報流通が可能になるというサービスであるが、内容的には、移動性に対応できる通信サービスとは、かなり内容の異なる広範なサービス概念を含む。例えば、(1)無線タグを物や人に貼り付け、無線タグリーダをいろいろな場所に設置することで、物や人の場所や状態（例えば、在庫か否か）などを管理、把握、又は利用する無線タグサービスや、(2)微小なセンサをばら撒き、それらのセンサから送られてくる種々のセンシング情報を元に、多様なアプリケーションを提供するセンシングサービスなどが含まれる。これらユビキタスサービスを実現する上では、名前として現在一般的に用いられているホスト名やファイル名などは、リソース自体の情報を含まず、名前とリソースの対応を把握するのが困難である。ユビキタスサービスに好適な名前としてセンシングサービスについて例示する。ある特定のセンシング情報を得たい場合、どんなセンシング情報であるかを表現する自己説明的な名前が望ましく、例えば、（センシング項目名、センシング場所、センシング時刻）を名前とすることが考えられる。
その名前から、同情報を有するセンサのアドレス、あるいは、センサ情報を格納したデータベースのアドレスを取得することが名前解決となる。
【０００６】
INS〈Intentional Naming System〉と称されるMITの研究結果（例えば、非特許文献3参照）は、自己説明的な名前に基づく名前解決を行うシステムである。名前は互いに依存関係を持つ複数の属性とその値によって構成され、依存関係は木構造で表される。INSもまた、CANやChordと同様にリゾルバの構成がアドホックネットワークとなっている。ただしINSでは、固定的なエントリポイントとして稼動中のリゾルバのリストを管理するブートストラップサーバを用意している。このほかに、ユビキクスサービスにおける名前解決関連技術としては、Auto-IDセンタ構想（例えば、非特許文献４）やユビキタスID（例ば、非特許文献５）のように物流管理を主な管理対象とし、固定フォーマットのコードで名前を表現し、固定的なリゾルバ網を構成することでスケール性を確保することが期待されるものがある。
【０００７】
膨大な数のリソースを対象に名前空間をセマンティクス（意味論）で分割し、分割された名前空間の部分毎にDNSと同様の構成を持つ名前解決機構を構築し、ユーザ端末が目的のリソースに対応するセマンティクスに応じて名前解決機構を使い分ける機構の研究成果（例えば、非特許文献６参照）が発表された。また、DNSにおけるリゾルバ（ネームサーバ）の所在および可用性をユーザ端末が予め自律的に把握しておくことで、ユーザの要求に応じて適切なリゾルバを自動発見する機構の研究成果（非特許文献７参照）が発表された。
【０００８】
【非特許文献１】S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, “A scalable content-addressable network, ”In Proc. Of  ACM SIGCOMM ’01 Aug.2001.
【非特許文献２】Ｉ．Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for internet applications, “In Proc. of the ACM SIGCOMM2001, Aug.2001.
【非特許文献３】W. Adjie-Winoto, E.Schwartz, 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.
【非特許文献４】http://www.autoidcenter.org/main.asp
【非特許文献５】http://udicenter.org
【非特許文献６】伝宝  浩史，谷  英明，Ubiquitous環境下における名前解決についての見当，”2003年電子情報通信学会総合大会B-7-6,Mar.2003.
【非特許文献７】山田  竜也，嶋田  雄二郎，栄光宏，”ユビキタスネットワークにおける名前解決の諸問題とその解決法方式の提案，”マルチメディア，分散，協調とモバイル（DICOMO2003）シンポジウム，June2003.
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ユビキタスサービスを含む今後の情報流通ネットワークに用いられる名前に関しては、要求条件の違いや歴史的経緯から、複数種類の名前空間や名前解決機構が用いられ、ユーザが目的とするリソースの種別あるいは利用法の違いにより、これら複数の名前空間や名前解決機構を使い分けることが予測される。名前空間および名前解決機構の数が固定的で少なければ、ユーザ端末が直接、各名前解決機構のエントリポイントを把握することも十分可能であるが、多様かつ膨大な数のリソースを対象に、今後多くの名前空間や名前解決機構が構築され、それらの中にエントリポイントが動的に変更されるアドホックな機構も含まれる可能性がある。
【００１０】
このような環境では、個々の名前空間および名前解決機構を利用する上で必要となるエントリポイントなどの情報をユーザ端末の側で管理するのは困難であるため、リゾルバの出現及び消滅に起因するエントリポイントの動的な変更をユーザ端末に意識させず、名前解決を行う仕組みが必要となる。
同様に、リソース（正確には、リソースを保有する端末又は装置）の側でも、名前とアドレスの組合せを登録又は変更すべき個別名前解決機構のエントリポイントを把握するのは困難であるため、エントリポイントの動的な変更をリソースにも意識させない環境が望ましい。
また、ユーザの利便性を向上させるべく名前の記述性を高める上で、複数の名前空間を組み合わせた名前によるリソースの指定をユーザに許容し、このような複雑な名前を、個々の名前空間や名前解決機構と連携させて解決するサービスも求められる。
複数の名前解決機構あるいはエントリポイントを使い分けるための機構に関する研究成果が既に発表されているが、それらは名前解決機構のエントリポイントの動的な変更、および複数の名前空間を組み合わせた名前の名前解決を想定していない。
【００１１】
本発明の目的は、ユビキタスサービスに柔軟に対応でき、複数の名前空間や名前解決機構を使い分けることができる名前解決システムを提供することにある。
また、本発明の別の目的は、多数の名前空間や名前解決機構が構築され名前解決機構のエントリポイントが動的に変更されても柔軟に対応できる名前解決システムを提供することにある。
さらに、本発明の別の目的は、複数の名前空間を組み合わせた名前を用いてリソースが指定された場合であっても、複数の名前解決機構が連携して名前解決できる名前解決システムを実現することにある。
【課題を解決するための手段】
【００１２】
本発明による名前解決システムは、ネットワーク上に分散管理されているリソースについて、ユーザからのアクセスに応じて目的とするリソースのアドレスを当該ユーザに提供する名前解決システムにおいて、
ネットワークに接続され、リソース識別情報と当該リソース識別情報により指定されるリソースのアドレスとの関係を規定したリソースアドレス情報を有する１個又は複数個のリゾルバから構成され、少なくとも１個のエントリポイントが指定されている複数の名前解決機構と、
ネットワークを介して前記複数の名前解決機構及びユーザ端末に接続され、ユーザ端末から送られてきた名前解決要求を受信し、対応する名前解決機構のエントリポイントに転送する１個又は複数個の仲介装置とを具え、
前記仲介装置は、受信した名前解決要求に含まれるリソース識別情報からリソースを指定する名前及び当該名前が属する名前空間識別情報又は名前解決を行う名前解決機構の識別情報を取り出す手段と、名前空間識別情報と当該名前空間に含まれる名前について名前解決を行う名前解決機構の識別情報との関係を格納した記憶手段とを有し、ユーザ端末から送られてきた名前解決要求を受信した際、受信した名前解決要求に含まれるリソース識別情報から関連する名前解決機構を求め、得られた名前解決機構のエントリポイントに当該名前解決要求を転送し、
前記名前解決要求を受信したエントリポイントは、当該名前解決機構に含まれるリゾルバに当該名前解決要求を転送し、
名前解決要求を受信した名前解決機構のリゾルバは、当該名前解決要求に含まれるリソースを指定する名前識別情報から当該リソースのアドレスを求め、得られたリソースのアドレスをエントリポイントを介して仲介装置に送信し、仲介装置からユーザ端末に返送することを特徴とする。
【００１３】
本発明による名前解決システムにおいては、ユーザ端末と複数の名前解決機構との間にネットワークを介して仲介装置が接続されているので、ユーザ端末からの名前解決要求は、仲介装置により対応する名前解決機構が選定され、複数の名前空間や複数の名前解決機構に対して柔軟に対応することができる。特に、形式の異なる複数の名前解決機構が連携することができるので、一層効率良く名前解決を実行することができる。
【００１４】
本発明による名前解決システムの好適実施例は、ユーザ端末から仲介装置に送信される名前解決要求のリソース識別情報が、目的とするリソースを特定する名前だけを含み、前記仲介装置は、リソースを特定する名前から当該名前が属する名前空間の識別情報を識別ないし判別する手段を有し、得られた名前空間識別情報に基づいて対応する名前解決機構のエントリポイントに当該名前解決要求を転送することを特徴とする。このように、仲介装置が名前情報から当該名前が属する名前空間を判別ないし取り出す手段を有することにより、仲介装置は、ユーザから送られてきた名前解決要求に含まれるリソース識別情報がリソースを特定する名前だけを含む場合であっても名前から対応する名前空間を取り出して対応する名前解決機構に当該名前解決要求を転送し、名前と名前空間の両方を含む場合名前空間に基づいて対応する名前解決機構のエントリポイントに当該名前解決要求を転送することができる。この結果、ユーザは、名前空間を知らなくても、目的とするリソースの名前だけから当該リソースのネットワーク上に管理されているアドレスを知ることができる。
【００１５】
本発明による名前解決システムの好適実施例は、前解決機構が、エントリポイントを動的に変更する手段を有し、エントリポイントを変更した場合当該名前解決機構に接続されていれている仲介装置にエントリポイント変更情報を送信することを特徴とする。このように、エントリポイントが動的に変更されることを許容する名前解決システムの場合、システムが構築された後に多数の名前空間や名前解決システムが新たに構築される場合にも柔軟に対応することができ、特に新たなリゾルバが出現し又は既存のリゾルバが消滅した場合であってもユーザ端末に対してエントリポイントの動的な変更を意識させることなく名前解決を実行することができる。
【００１６】
本発明による名前解決システムの別の好適実施例は、ユーザ端末から仲介装置に送信される名前解決要求に含まれるリソース識別情報が、複数の名前空間に属する名前情報を含む論理式により表され、前記仲介装置は、各名前空間に対応する各名前解決機構のエントリポイントに当該名前解決要求をそれぞれ転送し、各名前解決機構から送られてきたアドレスについて集合演算処理を実行することを特徴とする。本例では、リソースを指定する名前が複数の名前空間にわたる論理式により表される場合であっても、仲介装置が各名前空間に対応する名前解決機構に当該名前解決要求を転送し、得られたアドレスについて集合演算処理を実行するので、最良の名前解決の結果を得ることができる。
【発明の効果】
【００１７】
本発明は、今後、リソースの多様化を反映して数多く出現する可能性がある名前空間および個別名前解決機構の使い分け、活用を容易にすることができる。
IDにより名前空間および個別名前解決機構をメタ体系化し、個別名前解決機構のエントリポイントの動的な変更を、場合によっては個別名前解決機構の存在自体をユーザに意識させずに、名前解決を行う環境を実現する。また、実施例1に記述するように、ユーザ端末とエントリポイントとの間の通信を仲介装置ヘリダイレクトするNAT装置を配置することにより、ユーザ端末にブローカの機能を透過的に提供する環境の実現も可能である。
さらに、ユーザ端末からの名前の解決要求のみならず、リソース（正確には、リソースを保有する端末・装置）からの名前とアドレスの登録・変更要求についても、個別名前解決機構のエントリポイントの動的な変更を意識せずに実行する環境を実現することができる。
さらに、複数の名前空間を組み合わせた名前の名前解決を可能にする。
【発明を実施するための最良の形態】
【００１８】
図１は本発明による名前解決システムの一例を示す線図である。インターネットなどのデータ通信ネットワーク１００上に複数の個別の名前解決機構を使い分ける名前解決機構を構築する。図１において、符号１０１は名前解決機構全体を示し、本発明による名前解決機構１０１は同一システムの又は異なるシステムの複数の個別の名前解決機構を含み、本例では２つの名前解決機構２０１と２０２を具える。例えば、個別名前解決機構２０１としてDNSを用い、名前解決機構２０２としてINSを用いることができる。各名前解決機構２０１及び２０２は１個又は複数の名前解決装置（リゾルバ）を有すると共に１つ又はそれ以上のエントリポイントをそれぞれ有する。従って、各名前解決機構は、エントリポイントが指定されたリゾルバ網と解することもできる。ここで、符号３０１はDNS２０１のエントリポイント（ネームサーバ）を示し、符号３０２はINS２０２のエントリポイント（ブートストラップサーバ）を示す。ネットワーク１００には複数のユーザ端末５０１が接続され、これらのユーザ端末は、例えば通信機能を有するパーソナルコンピュータとすることができる。各ユーザ端末からの名前解決要求アクセスはネットワーク１００を介して名前解決についての仲介装置として機能するブローカ７０１に送信され、ブローカ７０１により当該アクセスに含まれる名前空間に対応する名前解決機構が選択され、選択された名前解決機構のエントリポイントに転送される。また、名前解決機構２０１又は２０２からの名前解決要求に対する回答であるリソースのアドレスは、ブローカ７０１を介してユーザ端末に転送される。
尚、図面を明瞭にするため2つの個別名前解決機構だけを示したが、勿論3つ以上の個別名前解決機構を有する名前解決機構への適用が可能である。また、個別名前解決機構のエントリポイントおよびブローカを1つだけ示したが、各名前解決機構は複数のエントリポイントを指定することも可能である。さらに、本例では、単一のブローカ７０１だけを具えるが、複数のブローカを有することも可能である。
【００１９】
本例では、名前解決機構２０１及び２０２はエントリポイントとして指定された１つのサーバとネットワークを介して接続された複数のリゾルバとを有するものとする。各リゾルバは、リソースを指定する名前識別情報とリソースのアドレスとの関係を規定したアドレス情報をそれぞれ有し、エントリポイントから名前解決要求を受信した際当該名前解決要求に含まれる名前識別情報に基づいて対応するリソースのアドレスを検索し、その結果をエントリポイントに返送する。尚、各リゾルバは、対応するアドレスが検索できなかった場合、別のリゾルバに当該名前解決要求を転送し、別のリゾルバが名前解決を実行する。尚、各リゾルバは、名前解決機構に対してアドホックに接続されることも可能であり、リゾルバとして消滅した場合又は新たにリゾルバとなった場合等の動的な変更が行われた場合、これらリゾルバのアドレス情報はエントリポイントに送信され、エントリポイントにおいて管理するものとする。
【００２０】
図２はユーザ端末及びブローカの一例の構成を示す線図である。初めに、ユーザ端末について説明する。ユーザ端末５０１には2つのプログラムを搭載する。第一のプログラムは、目的のリソースの名前とその名前に対応する名前空間あるいは当該名前について名前解決を行う名前解決機構の識別情報（ID）をリソース識別情報として含む名前解決要求を任意のブローカヘ送信するプログラム601であり、第二のプログラムは、ブローカ７０１より目的のリソースに対応するアドレスを受信するプログラム602である。プログラム601は、ユーザにより起動され、ユーザが目的とするリソースの名前と名前解決機構のIDを入力すると、プログラム６０１はこれらの情報を任意のブローカヘ送信し、プログラム602を起動して終了する。尚、第一のプログラムは、名前空間を含まず目的とするリソースを特定する名前情報だけを含む場合についても適用される。
【００２１】
ユーザは、名前解決機構がＤＮＳの場合、リソースを指定する名前の識別情報としてリソースを格納したホストのドメイン名を用い、名前空間としてドメイン名を表示するフォーマットを用いことができる。すなわち、名前空間は、名前の集合体と解することができる。また、名前空間を識別するIDとして、例えばWebサービスで文書の識別に用いられているURI（Uniform Resource Identifier）などを用いることができる。また、個別名前解決機構のIDとしては、例えばブートストラップサーバなどのエントリポイントを構成するサーバのアドレスなどを用いることができる。
【００２２】
本発明では、ユーザ端末と名前解決機構との間にブローカ７０１が介在し、ブローカが各名前解決機構のエントリポイントに関する情報を有するので、ユーザ端末が想定するエントリポイントと実際に稼動中のエントリポイントを一致させる必要が無く、ユーザは名前解決機構のエントリポイントのアドレスを知る必要はない。そのため、個別名前解決機構のIDとして使用するエントリポイントは仮想的な存在で構わず、そのアドレス対応して何らかの装置を用意しなくともよい。名前とIDの宛先にはブローカに対応する名前あるいはアドレスを用いるが、個々のブローカに割当てられた名前（例えば、DNSのFQDN）や固定アドレスを用いても、全ブローカ共通のIPv6のwell-known-site-local-unicast addressを使用してもよい。前者の場合、予めユーザ端末に任意の（通常は最寄の）ブローカのアドレスを記憶させる。ユーザ端末からブローカヘ名前とIDを送信する方法は、名前とIDを一つの通信メッセージで送信しても、二つのメッセージに分けても良い。前者の場合、通信メッセージをXMLなどの記述性の高い言語で記述することが考えられる。また、個別名前解決機構のIDをエントリポイントのアドレスとする場合には、webのキャッシュサーバヘの接続制御の一種であるtransparent cachingと同様に、ユーザ端末からエントリポイントヘ直接送信された名前解決の要求をNAT（Network Address Translation）装置でリダイレクトして、名前とIDの組合せをユーザ端末に「透過的に」ブローカに到達させることも可能である。このとき、ブローカからはNAT装置がユーザ端末に見え、ユーザ端末からはNAT装置がエントリポイントに見える（NAT装置はブローカからの回答をエントリポイントからの回答であるように見せかけて送信する）。尚、プログラム602はプログラム601が名前とIDを送信したブローカよりアドレス（ときにはアドレス群）を受信して終了する。
【００２３】
次に、各名前解決機構のエントリポイントについて説明する。名前解決機構（DNS）のエントリポイント301には、2つのプログラムが搭載されている。第一のプログラムは、エントリポイントとして指定されたリゾルバあるいはブートストラップサーバを動的に選びなおすプログラム401であり、第二のプログラムはエントリポイントの変更を任意のブローカに通知するプログラム402である。本発明による名前解決システムは、ユビキタスサービスに柔軟に対応することができ、名前解決機構のエントリポイントが変更されることも許容される。そして、エントリポイントが変更された場合、その変更情報はブローカに送信され、ブローカは各名前解決機構のエントリポイントを管理する。
【００２４】
次に、ブローカ（仲介装置）の構成について説明する。一例として、ブローカの701には9つのプログラムを搭載することができる。第一のプログラムは、各個別名前解決機構ヘアクセスする際のエントリポイントに指定されたリゾルバあるいはブートストラップサーバのアドレスのリストを管理するプログラム801である。第二のプログラムは、名前空間を識別するIDと個別の名前解決機構を識別するIDとの対応関係を規定する情報を管理するプログラム802である。第三のプログラムは、ユーザ端末より目的のリソースの名前識別情報と、その名前に対応する名前空間あるいは個別名前解決機構のIDを受信するプログラム803である。第四のプログラムは、ユーザ端末より受信した名前空間あるいは個別名前解決機構のIDに適合するエントリポイントを選択するプログラム804である。第五のプログラムは、個別名前解決機構のエントリポイントヘユーザ端末より受信した名前を解決する要求を転送するプログラム805である。第六のプログラムは、エントリポイントから転送された目的とする名前に対応するアドレスを受信するプログラム806。第七のプログラムは、ヘエントリポイントから受信したアドレスをユーザ端子ヘ回答するプログラム807。第八のプログラムは、リゾルバあるいはブートストラップサーバからの通知を受け、各個別名前解決機構のエントリポイントのリストを更新するプログラム808。第九のプログラムは、エントリポイントの変更を他のブローカに通知し、ブローカ間の情報共有を行うプログラム809である。尚、ユーザ端末から送信されてくる名前解決要求のリソース識別情報として名前空間を含まず名前情報だけが含まれる場合にも柔軟に対応するため、リソースを指定する名前識別情報から対応する名前空間を取り出すプログラムも具えることができ、このようなプログラムとしてシグニチャパターンマッチング法を利用したプログラムを用いることができる。ここで、シグニチェパターンマッチングとは、各名前空間に特有の文字列あるいはビット列をプログラムに予め記録しておき、受信したリソース識別情報に含まれる名前を構成する文字列又はビット列とのパターンマッチングを行うことで当該名前が属する名前空間を推定する手法である。ただし、シグニチャマッチングの適用は、なんらかの文字列あるいはビット列によって名前空間が一意に特定できる場合に限られる。
【００２５】
プログラム801およびプログラム802は、常に起動されており、後述するプログラム804からの要求に応じてエントリポイントのリストあるいはIDの情報を回答する。プログラム803も、常に起動されており、ユーザ端末から名前とIDを受信するのを待ち、プログラム804を起動して受信した名前とIDを渡し、再びユーザ端末からの受信を待つ。プログラム804は、個別名前解決機構のIDに対応するエントリポイントをプログラム801に要求し、対応するエントリポイントが複数回答された場合は適当なエントリポイントを選択し、これをプログラム805へ渡して終了する。プログラム804は、プログラム803から渡されたIDが名前空間のIDの場合は、プログラム801への要求に先立ち、名前空間のIDに対応する個別名前解決機構のIDをプログラム802へ要求する。
【００２６】
名前空間と個別名前解決機構は一対一に対応する必要は無い。個別名前解決機構の実現方式と当該方式を用いるネットワーク上の個別名前解決機構も一対一に対応する必要は無く、同一の方式を用いる複数の個別名前解決機構が存在し得る（特に、アドホックにリゾルバ間のネットワークを構成する方式において）。また、各リソースが個々の名前空間や個別名前解決機構に排他的に分割される必要もない。プログラム802における名前空間と個別名前解決機構の対応を規定する情報は、新たな名前空間あるいは個別名前解決機構が出現したり、既存の名前空間や個別名前解決機構が破棄される度に更新される。新たな名前空間あるいは個別名前解決機構が出現した場合は、それらに一意性が保証されたIDを割り振る。さらに、新方式の個別名前解決機構が出現した場合は、名前解決の要求や回答を処理する手順やメッセージフォーマットなどを外部からブローカに記憶させる。プログラム804の複数のエントリポイントから適当な候補を選択する方法としては、単純なラウンドロビンや、あるいはネットワーク上の距離（経路のホップ数や実効帯域）やエントリポイントの能力・負荷（反応速度や選択した回数・頻度）、安定性（例えば、システムヘの接続時間の長さ）などのメトリックに基づく判断が考えられる。
【００２７】
プログラム805は、プログラム804から渡されたエントリポイントヘ、プログラム803が受信した名前解決要求を転送し、プログラム806を起動して終了する。プログラム806は、プログラム804が選択したエントリポイントからアドレス（ときにはアドレス群）を受信するのを待ち、プログラム807を起動して受信したアドレスを渡して終了する。プログラム807は、プログラム806から渡されたアドレスをユーザ端末へ回答して終了する。
【００２８】
プログラム808は、常に起動されており、リゾルバあるいはブートストラップサーバにより構成されるエントリポイントの更新通知を待ち、エントリポイントのリストを更新するとともに、プログラム809を起動して更新通知の内容を渡して終了する。プログラム809は、プログラム808から渡された更新通知の内容をネットワーク100を介して他のブローカに通知し終了する。
【００２９】
［実施例2］
図3は本発明による名前解決システムに用いるブローカ及びユーザ端末の実施例２の構成を示す。図２で用いた構成要素と同一の構成要素には同一符号を付して説明する。実施例1と実施例2の相違点は、異なる名前空間に属する複数の条件の論理式で構成される名前を扱う手段の有無である。
実施例２のユーザ端末には、実施例1のプログラム601に類似のプログラム611と、実施例１のプログラム602の2つのプログラムが搭載されている。プログラム611は、ユーザにより起動され、ユーザにより入力され異なる複数の名前空間に属する複数の条件の論理式で構成される名前および当該名前を構成する各条件に対応する名前空間あるいは個別名前解決機構のIDを任意のブローカヘ送信し、プログラム612を起動して終了する。プログラム611が送信する通信メッセージは、XMLなどの記述性の高い言語で記述することが考えられる）。ユーザ端末が送信する通信メッセージの一例を図４に示す。
【００３０】
実施例2のブローカには、実施例1のプログラム801および802と、実施例1のプログラム803に類似のプログラム813と、実施例1のプログラム804に類似のプログラム814と、実施例1のプログラム805に類似のプログラム815と、実施例1のプログラム806に類似のプログラム816と、実施例1のプログラム807〜809と、異なる名前空間に属する複数の条件の論理式で構成される名前を個々の条件に分解し且つ各条件の関係を表す論理式を保持するプログラム810と、論理式に従ってアドレス群の集合演算を行うプログラム811の11種類のプログラムが搭載されている。
【００３１】
プログラム813は、常に起動されており、ユーザ端末から通信メッセージを受信するのを待ち、通信メッセージが複数の条件の論理式を含む場合はプログラム810を起動してユーザ端末から受信した通信メッセージを渡し、受信した通信メッセージが単一の条件式で記述されている場合プログラム814を起動して通信メッセージを渡して終了する。
【００３２】
プログラム810は通信メッセージを、名前を構成する各条件、およびそれらの関係を表す論理式、および各条件に対応する名前空間あるいは個別名前解決機構のIDに分解し、なお且つ条件毎に複数のプログラム814を並列に起動して条件とIDを渡し、さらにプログラム811を起動して論理式および並列度（並列実行の数）を渡して終了する。
【００３３】
プログラム814は、プログラム813により起動された場合は、実施例1のプログラム804の処理を実行し、一方プログラム810により起動された場合は、実施例1のプログラム804の処理を実行するとともにプログラム815に対して並列実行である旨を通知する。プログラム815は、実施例1のプログラム805の処理を実行し、プログラム814より並列実行である旨を通知された場合は、プログラム816に対して並列実行である旨を通知する。プログラム816は、実施例1のプログラム806の処理を実行し、プログラム815より並列実行である旨を通知された場合は受信したアドレスをプログラム811へ渡して終了し、そうでなければプログラム807を起動して受信したアドレスを渡して終了する。
【００３４】
プログラム811は、並列度の数だけ並列実行されたプログラム816からアドレスが渡されるのを待ち、渡されたアドレス群に対しプログラム810から渡された論理式に従って集合演算を行い、プログラム807を起動して集合演算の結果を渡して終了する。尚、集合演算処理として、例えば複数の名前解決機構から転送されたアドレスについてAND又はOR演算処理を行うことができる。例えば、ANDの演算処理を行う場合共通して現れるアドレスが抽出され、OR演算処理が行われる場合全ての候補のアドレスが出力される。
【図面の簡単な説明】
【００３５】
【図１】本発明による名前解決システムの一例を示す線図である。
【図２】ユーザ端末及びブローカの一例を示す線図である。
【図３】第２実施例のユーザ端末及びブローカの構成を示す線図である。
【図４】実施例2におけるユーザ端末が送信する通信メッセージの一例を示す線図である。
【符号の説明】
【００３６】
１００  ネットワーク
１０１  名前解決機構
３０１，３０２  エントリポイント
５０１  ユーザ端末
７０１  ブローカ
【図１】
2005094485.tif 000003
【図２】
2005094485.tif 000004
【図３】
2005094485.tif 000005
【図４】
2005094485.tif 000006