JP3559471B2 - 設定情報サーバ装置、利用者計算機及び設定情報配送方法 - Google Patents
設定情報サーバ装置、利用者計算機及び設定情報配送方法 Download PDFInfo
- Publication number
- JP3559471B2 JP3559471B2 JP09375899A JP9375899A JP3559471B2 JP 3559471 B2 JP3559471 B2 JP 3559471B2 JP 09375899 A JP09375899 A JP 09375899A JP 9375899 A JP9375899 A JP 9375899A JP 3559471 B2 JP3559471 B2 JP 3559471B2
- Authority
- JP
- Japan
- Prior art keywords
- setting information
- search
- information server
- request
- search request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークに接続された利用者計算機が必要とする、ネットワーク、および実行アプリケーションプログラムの設定情報の自動化を可能とする設定情報サーバ装置、利用者計算機及び設定情報配送方法に関する。
【０００２】
【従来の技術】
計算機システムの小型化、低価格化やネットワーク環境の充実に伴って、計算機システムの利用は急速にかつ種々の分野に広く拡大し、また集中型システムから分散型システムへの移行が進んでいる。特に近年では計算機システム自体の進歩、能力向上に加え、コンピュータ・ネットワーク技術の発達・普及により、オフィス内のファイルやプリンタなどの資源共有のみならず、オフィス外、１組織外とのコミニュケーション（電子メール、電子ニュース、ファイルの転送など）が可能になり、これらが広く利用されはじめた。特に近年では、世界最大のコンピュータネットワーク「インターネット（Ｉｎｔｅｒｎｅｔ）」の利用が普及しており、インターネットと接続し、公開された情報、サービスを利用したり、逆にインターネットを通してアクセスしてくる外部ユーザに対し、情報、サービスを提供することで、新たなコンピュータビジネスが開拓されている。またインターネット利用に関して、新たな技術開発、展開がなされている。
【０００３】
このようなコンピュータネットワークの普及に伴い、様々な業種においてネットワークサービスを活用した計算機（ＰＣ）の利用が行われている。これらネットワークサービスを利用したり実現するアプリケーションは、各々のネットワークで固有の環境情報を基にした設定を必要とする。一方、ＰＣの小型化と軽量化に伴い、自分の端末を持ち歩き、移動先（外出先）でそのＰＣを利用するという使い方が広まってきている。
【０００４】
一方、電話には電話帳、郵便には郵便番号表、各々の会社には社員名簿や内線電話帳というように、現実社会にはいろいろな形態の特定の情報を集めたデータベースが存在する。これらの情報は画一的に集中管理できるものとは限らない。例えば、郵便番号は郵政省のような郵便番号を決定できる機関によって一元的に管理されるべきであったり、電話番号は各地方の電話局によって分散管理されるべきであったりする。このような管理単位がまちまちな対象に関しての情報の管理を統合し統一手順で情報取得できるようにしたデータベースをディレクトリと呼び、ＩＴＵ−Ｔ（ｔｈｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｔａｎｄａｒｄｉｓａｔｉｏｎ ｓｅｃｔｏｒ ｏｆ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）でＸ．５００規格として標準化されている。また、インターネットプロトコルでの使用を前提としたディレクトリをアクセスするためのプロトコルとしてＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）がＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準化されている。ディレクトリは幅広い情報の配送サービスシステムとして活用されることが可能である。同様のネットワーク上で各種情報の自動取得に用いられるプロトコルとして、ＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＡＣＡＰ（Ａｐｐｌｉｃａｔｉｏｎ ＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）も同様にＩＥＴＦで標準化が行われている。アプリケーションの設定情報の自動取得と設定において、情報配送機能については、これらのプロトコルいずれを使用しても実現が可能である。
【０００５】
【発明が解決しようとする課題】
上記のように近年、計算機は小型化、軽量化による普及により、様々な業種のオフィスで使用されるようになった。これに伴い、計算機に精通していないユーザの増加が進んでいる。しかし、既存のアプリケーションプログラムの設定には、ある水準の知識や経験が必要であり、アプリケーションプログラムを正しく動作させることができない原因の１つとなり得る。
【０００６】
特に、計算機を持ち歩いて移動先でネットワークサービスを使用するためには、移動先ネットワークに見合った設定をアプリケーション対応に行なう必要があり、設定作業は容易なものとは限らず、必要以上の時間を浪費したり、設定の不備のためにネットワークサービスを受けられない場合があり得る。
【０００７】
また、ネットワーク対応の設定情報は、当該ネットワークの管理者に問い合わせなければ取得できない場合も多く、利用者の設定のたびに管理者へ負担がかかる場合もある。以上のように、ネットワークサービスを利用するアプリケーションを始めとする種々のアプリケーションの設定には、利用者と管理者の工数が必要であるため、設定の自動化が望まれている。
【０００８】
そこで、前述のディレクトリによる情報配送サービスを応用して、アプリケーションプログラムの設定情報の配送にディレクトリを用い、ユーザの設定作業を自動化することが考えられる。この場合、例えば、移動先のネットワークにＬＤＡＰサーバを設置して、利用者計算機から、必要な設定情報をＬＤＡＰに基づいて問い合わせを行い、応答情報を必要なアプリケーションに設定する、という処理を行う。
【０００９】
しかしながら、１台のＬＤＡＰサーバで、いかなる規模の移動先ネットワークをも対象として処理を行うのは、事実上困難である。例えば、実際の運用を考えると、運用組織同様に階層的なネットワーク構造になっており、全体で共通の設定情報を与える部分と各部署ネットワークで独自の設定を行う部分が存在するのが普通である。つまり、従来、ディレクトリに基づく情報配送を行う場合、階層的なネットワーク構造を考慮して情報配送サーバ側が柔軟に連携して必要な情報の提供を行ったり、利用者計算機の側で与えられた情報を自身の位置を考慮して適切に利用することができず、アプリケーションプログラムへの情報設定などにおいて不都合を生じていた。
【００１０】
本発明は、上記事情を考慮してなされたものであり、ネットワーク（インターネットやイントラネット）上を移動する利用者計算機が移動先でプログラムを動作する際に、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバからも設定情報取得が可能で、この結果をもとに自分の現在位置を考慮して適切なアプリケーションプログラムへの設定情報の自動設定を可能とする設定情報サーバ装置、利用者計算機及び設定情報配送方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明（請求項１）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持するための第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、前記第２の保持手段にリンク情報が保持されている設定情報サーバ装置と通信する通信手段と、受信した第１の設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果、および該検索範囲指定を適切な値に修正した第２の設定情報検索要求を自装置と連鎖する他の設定情報サーバ装置へ前記通信手段を介して送信しその返答として該他の設定情報サーバ装置から得た検索結果の少なくとも一方を含む設定情報検索結果を、該第１の設定情報検索要求の要求元装置に配送するための制御を行う制御手段とを備えたことを特徴とする。
【００１２】
本発明（請求項２）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持する第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、下位の設定情報サーバ装置から検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）が無指定の状態に設定された設定情報検索要求を受信した場合、前記第２の保持手段を参照し、自装置が最上位の設定情報サーバ装置でないならば、自装置の上位の設定情報サーバ装置に検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）が無指定の状態に設定された設定情報検索要求を送信して該上位の設定情報サーバ装置から得た設定情報を、元の要求元へ配送し、自装置が最上位の設定情報サーバ装置であるならば、下位の設定情報サーバ装置に検索範囲指定を該下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第１の制御手段と、上位の設定情報サーバ装置から検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に自装置とあらかじめ関連付けられている検索範囲指定の値が設定された設定情報検索要求を受信した場合、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきと判断されれば、該自装置の下位の設定情報サーバ装置に検索範囲指定を更に該自装置の下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該自装置の下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送し、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきでないと判断されれば、前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第２の制御手段とを備えたことを特徴とする。
【００１３】
本発明（請求項３）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持するための第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、利用者計算機と通信する通信手段と、利用者計算機から受信した設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果と、前記第２の保持手段を利用して得られる自装置と連鎖する他の設定情報サーバ装置および該他の設定情報サーバ装置に設定情報検索要求を出す際に検索範囲指定に設定すべき適切な検索開始点を示す通知情報との少なくとも一方を、該利用者計算機に配送するための制御を行う制御手段とを備えたことを特徴とする。
【００１４】
好ましくは、前記第１の保持手段に保持されている設定情報の影響範囲は、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述されているようにしてもよい。
【００１５】
好ましくは、受信した前記設定情報検索要求に含まれる、ネットワーク中における場所を示す情報と、前記第１の保持手段に保持されている前記設定情報の影響範囲とを比較することによって、前記第１の保持手段から該当する設定情報を検索するようにしてもよい。
【００１６】
好ましくは、設定情報サーバ装置内部（例えば、設定情報サーバ間の通信、自装置内の設定情報の検索等）で使用する標準プロトコル（例えば、ＬＤＡＰ）とは異なるプロトコル（例えば、ＡＣＡＰ、ＡＣＡＰ）によって、前記利用者計算機に対する設定情報検索配送サービスを提供するためのプロトコル変換を行うプロトコル変換手段を更に備えるようにしてもよい。
【００１７】
好ましくは、前記プロトコル変換手段は、サービス・ロケーション・プロトコル（ＳＬＰ：Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、サービス情報配送要求メッセージ、サービス情報配送メッセージ、サービス情報登録メッセージの各々と、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むようにしてもよい。
【００１８】
好ましくは、前記プロトコル変換手段は、アプリケーション・コンフィグレーション・アクセス・プロトコル（ＡＣＡＰ：Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続コマンド、サービス情報配送要求コマンド、サービス情報配送コマンド、サービス情報登録コマンドの各々と、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むようにしてもよい。
【００１９】
好ましくは、前記設定情報の内容を記述する属性の値として、該設定情報の内容の実際の記憶箇所を示す情報（例えば、他のディレクトリエントリやｆｔｐサイトをＵＲＬで指定し、そこに設定情報本体を置く）を記述するようにしてもよい。
【００２１】
本発明（請求項１０）は、プログラムの設定情報の検索要求に使用すべき標準プロトコル（例えば、ＬＤＡＰ）が特定のものに定められている設定情報サーバ装置から、自装置上で動作中のプログラムの要求する設定情報を取得する利用者計算機であって、自装置上で動作中のプログラムの出力する、設定情報を取得するための設定情報検索要求であって、前記標準プロトコルとは異なるプロトコル（例えば、ＳＬＰ、ＡＣＡＰ）による設定情報検索要求を、該標準プロトコルによる設定情報検索要求に変換する手段と、前記標準プロトコルによる設定情報検索要求をネットワークを介して送信し、これに対する応答として配送された、該標準プロトコルによる応答メッセージを、前記プログラムが使用する前記プロトコルによる応答メッセージに変換して、該動作中のプログラムに渡す手段とを備えたことを特徴とする。
【００２２】
好ましくは、前記設定情報サーバ装置からの前記設定情報検索要求に対する応答メッセージに、他の設定情報サーバ装置を紹介する情報が含まれている場合には、該他の設定情報サーバ装置にも設定情報検索要求を送信させる手段を更に備えるようにしてもよい。
【００２３】
好ましくは、前記設定情報検索要求の検索範囲指定に設定すべき適切な値が分からない場合には、該検索範囲指定を無指定（ＢａｓｅＯｂｊｅｃｔ）の状態に設定するようにしてもよい。
【００２４】
好ましくは、前記設定情報検索要求には、その送信時に自装置が属する場所情報を付加するようにしてもよい。
【００２５】
好ましくは、配送された設定情報のうちに、同一の設定項目に対して内容の相違する複数の設定情報が存在する場合に、前記設定情報とともに配送された、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述された該設定情報の影響範囲を示す情報に基づいて（例えば、決定的な表記部分から設定情報の優先度を判定することで）、採用すべき設定情報を選択する手段を更に備えるようにしてもよい。
【００２６】
本発明（請求項１５）は、プログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置の設定情報配送方法であって、受信した第１の設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持する第１の保持手段を検索する手順、および自装置と連鎖する、自装置の上位または下位のサブドメインを管理対象としている他の設定情報サーバ装置へ、該第１の設定情報検索要求の検索範囲指定を適切な値に修正した第２の設定情報検索要求を送信する手順のうちの少なくとも一方の手順を実行し、前記検索により得られる設定情報および前記第２の設定情報検索要求に対する返答として前記他の設定情報サーバ装置から得られる設定情報のうち、前記手順を実行して得られたものを、前記第１の設定情報検索要求の要求元装置に配送することを特徴とする。
【００２７】
本発明（請求項１６）は、プログラムの設定情報を保持する設定情報サーバ装置に利用者計算機が設定情報検索要求を送信し、これに応じて該設定情報サーバ装置が該利用者計算機に該当する設定情報を配送する設定情報配送方法であって、利用者計算機は、自装置が属する場所情報を含む設定情報検索要求を設定情報サーバ装置に送信し、前記設定情報検索要求を受信した設定情報サーバ装置は、自装置内に記憶された設定情報のうち、該設定情報に対応して記憶されている、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述された影響範囲（スコープ）と、該設定情報検索要求に含まれる場所情報とを比較し、該場所情報に合致する影響範囲を持つ設定情報を検索結果として抽出し、前記設定情報サーバ装置は、前記設定情報検索要求を送信した前記利用者計算機に、前記検索により得られた前記設定情報を配送することを特徴とする。
【００２８】
本発明によれば、各ネットワークドメインに配置された上位／下位の情報設定サーバ装置が、連鎖機能により連携することで、例えば利用者計算機が移動先でプログラムを動作する際に、利用者計算機は自装置が接続したネットワークドメインの情報設定サーバ装置に検索要求を出すだけで、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行うことができる。また、この結果をもとに、自装置の現在位置を考慮した適切なアプリケーションプログラムへの設定情報の自動設定が可能になる。
【００２９】
あるいは、各設定情報サーバ装置が、連携動作する代わりに、関連する設定情報サーバ装置を利用者計算機に紹介するようにしても、移動計算機が紹介された各設定情報サーバ装置に検索要求を出すことにより、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行うことができる。
【００３０】
また、設定情報サーバ装置への設定情報の登録において、該設定情報とともに、該設定情報の影響範囲（該設定情報が適用される範囲）を非決定的な表記により記述して併せて登録する。この影響範囲と、利用者計算機の現在位置を示す情報により、効果的な検索もしくは配送すべき設定情報の絞り込みが可能となる。
【００３１】
さらに、プロトコル変換機能を適宜、適所に設けることにより、例えば、設定情報サーバ装置間の問い合わせに使用するプロトコルと、設定情報サーバと利用者計算機との間で使用するプロトコルが異なっても、対応することができる。
【００３２】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００３３】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００３４】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３５】
（通信システムの基本構成例）
図１に、本発明の実施の形態に係わる通信システムの基本構成の一例を示す。
【００３６】
図１の通信システムは、イントラネットを構築しており、当該イントラネットに部門毎のネットワークと、全社を管理するネットワークが接続されている様子を示している。図１の例では、全社設定情報サーバ（図中、１）が接続されているネットワーク＃１と部門Ａ設定情報サーバ（図中、１１）が接続されているネットワーク＃２、部門Ａ−１設定情報サーバ（図中、１１１）が接続されているネットワーク＃３、部門Ｂ設定情報サーバ（図中、１２）が接続されているネットワーク＃４は、全社イントラネット（図中、６）で接続されており、相互に通信可能状態にある場合を想定している（各々の設定情報サーバ（１，１１，１１１）の構成は基本的には同様である）。また、利用者計算機（以下、ユーザＰＣ）２は、部門Ａ−１ネットに接続され（以下、部門Ａ−１ネットに接続されたユーザＰＣ２をユーザＰＣ（Ａ−１−ａ）と記述する）、そのユーザＰＣ（Ａ−１−ａ）上では、様々なアプリケーションプログラムが実行される場合を想定する。なお、図１の通信システムには別のサーバ装置やＰＣが接続されていてもよいし、該通信システムが外部のインターネット等と接続可能であってもよい。
【００３７】
一般的に、アプリケーションプログラムを使用するためには、様々なユーザ依存、ネットワーク依存、あるいは使用環境依存な設定が必要である。なお、ここでは、「アプリケーションプログラム」は、純然たるアプリケーションプログラムの他に、アプリケーションプログラムとしての性質、機能もしくは側面を有するソフトウェア全般を含むものとする。従って、「アプリケーションプログラムの設定情報」は、いわゆるブラウザ・ソフトやワープロ・ソフト等の設定情報の他に、上記のようなソフトウェアのアプリケーションプログラムとしての性質、機能もしくは側面を持つ部分に関する設定情報を含むものとする。
【００３８】
本実施形態では、所定の「アプリケーションプログラムの設定情報（以下、設定情報と略す）」に関して、部門Ａで共通な設定情報を「部門Ａ設定情報サーバ」に、部門Ａ−１で共通な設定情報を「部門Ａ−１設定情報サーバ」に、部門Ｂで共通な設定情報を「部門Ｂ設定情報サーバ」に、全社で共通な設定情報を「全社設定情報サーバ」に分散して記憶・管理させるものとする。ここで、共通な設定情報とは、環境依存である設定情報や、ネットワーク依存の設定情報、計算機の管理者が推奨する設定情報などを含む。
【００３９】
ユーザＰＣ２は、「ＰＣの起動時」、「ＰＣの移動時」、「ユーザが使用するアプリケーションプログラムの起動時」、「ユーザが指定した契機」、「自動設定のためのアプリケーションプログラムによる定期的や不定期な契機」といった様々な契機（どの契機によるかはＯＳやアプリケーションプログラム等によって異なりうる）で、設定情報サーバへ設定情報検索要求を送信する。
【００４０】
ユーザＰＣ２から設定情報検索要求を受けた設定情報サーバ（例えば、部門Ａ−１設定情報サーバ１１１）は、該設定情報検索要求の内容に基づいて、検索処理等の所定の処理を行って（詳しくは後述するように必要に応じて他の設定情報サーバと連携をとって）、ユーザＰＣ２に検索された設定情報を返答する。また、別の方法としては、設定情報サーバは、他の設定情報サーバと連携をとる代わりに、ユーザＰＣ２に、該他の設定情報サーバを紹介する方法も考えられる。
【００４１】
以下では、ユーザＰＣの構成、設定情報サーバの構成、設定情報の分散記憶・管理形態や設定情報の検索、ユーザＰＣおよび設定情報サーバの全体シーケンス、プロトコル変換装置等について、順次説明していく。
【００４２】
なお、本実施形態では、ユーザＰＣと設定情報サーバとの間の手続き、設定情報サーバの相互間での手続きに、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を標準として用いる場合を代表例として説明する。
【００４３】
（ユーザＰＣの構成例）
以下、ユーザＰＣの構成例について説明する。
【００４４】
最初に、ユーザの使用するアプリケーションプログラム自身が設定情報の自動取得に対応している場合のユーザＰＣ２の構成について説明する。
【００４５】
図２に、この場合のユーザＰＣ２の構成例を示す。図２に示されるように、ユーザＰＣ２は、ネットワーク通信装置２２１、ＳＬＰ・ＬＤＡＰプロトコル変換装置２２７やＡＣＡＰ・ＬＤＡＰプロトコル変換装置２２８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００４６】
図２では、アプリケーションプログラム（２２４）が設定情報を自動取得するためのメッセージの送出経路を示している。
【００４７】
まず、当該アプリケーションプログラムが、ＬＤＡＰを用いて設定情報を取得する機能やＳＬＰ（ＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ），ＡＣＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）といった設定情報の自動取得に用いられるプロトコルに対応していて、ネットワーク上に置かれた設定情報サーバが各々のプロトコルに対応している場合、（クライアント要求経路１）により、ネットワークに向けて設定情報検索要求を送出する。
【００４８】
設定情報サーバの発見には、ＤＨＣＰの拡張部分を用いたサーバ情報の配布を用いることや、ブロードキャストやマルチキャストによるサーバ発見技術、属しているドメインに特定の文字列を付加したホスト名による特定など、様々な方法がある。なお、ＬＤＡＰにおける設定情報検索要求に関しては後述する。また、その他のプロトコルの要求メッセージは、それぞれのプロトコル仕様に従ったメッセージとする。
【００４９】
次に、アプリケーションプログラムがＳＬＰ，ＡＣＡＰをはじめとする自動設定に関して使用できるプロトコルに対応しているが、ネットワーク上に置かれた設定情報サーバがＬＤＡＰのみに対応している場合、各々のプロトコルに応じた（クライアント要求経路２）、（クライアント要求経路３）、…により、設定情報検索要求を送出する。送出された設定情報検索要求は、各々のプロトコルからＬＤＡＰへ変換されるべく、該当するプロトコル変換装置（２２７，２２８）を経由してＬＤＡＰの設定情報検索要求としてネットワークに送出される。なお、クライアントにおけるプロトコル変換の詳細については後述する。
【００５０】
その後、設定情報サーバから配送された設定情報は、それぞれの設定情報検索要求が通った経路を遡り、当該アプリケーションプログラムへ配送される。
【００５１】
なお、図２のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、図１の設定情報サーバが対応可能なプロトコル（本実施形の場合、少なくともＬＤＡＰプロトコル）に対応しているアプリケーションプログラムのみ、本設定情報検索サービスを受けられることになる。
【００５２】
続いて、当該アプリケーションプログラムが設定情報の自動取得に対応していないために自動設定装置を用いた場合のユーザＰＣ２の構成について説明する。
【００５３】
図３に、この場合のユーザＰＣ２の構成例を示す。図３に示されるように、ユーザＰＣ２は、ネットワーク通信装置２４１、自動設定装置２４２を備えており、自動設定装置２４２は、設定取得制御装置２４２１、取得設定情報データベース２４２２、設定情報反映装置２４２３、ＬＤＡＰクライアント装置２４２４、ＳＬＰクライアント装置２４２７やＡＣＡＰクライアント装置２４２８などのＬＤＡＰプロトコル以外のプロトコルによるクライアント装置を備えている。
【００５４】
前述した契機によって設定情報の自動取得が行なわれる場合、自動設定装置２４２は、まず、どのアプリケーションプログラム（２４４）に対して何の設定を何のプロトコルを用いて自動化するのかを必要に応じてユーザに指定され、次に、設定取得制御装置２４２１は、ネットワーク上に設置されている設定情報サーバが提供しているプロトコルに応じて、ＬＤＡＰクライアント装置２４２４、ＳＬＰクライアント装置２４２７あるいはＡＣＡＰクライアント装置２４２８などを動作させて、（クライアント要求経路１）、（クライアント要求経路２）、…などを通じて、ネットワーク上に設定情報検索要求を送出する。
【００５５】
設定情報サーバの発見に関しては、上記のユーザの使用するアプリケーションプログラム自身が設定情報の自動取得に対応している場合と同様である。また、ＬＤＡＰにおける設定情報検索要求に関しては後述する。その他のプロトコルの要求メッセージは、それぞれのプロトコル仕様に従ったメッセージとする。
【００５６】
その後、設定情報サーバから配送された設定情報は、それぞれの設定情報検索要求が通った経路を遡り、取得設定情報データベース２４２２へ配送される。そして、取得設定情報データベース２４２２から設定情報反映装置２４２３に対して、当該アプリケーションへ設定情報の反映の指示が送られ、必要な設定ファイルやレジストリの項目の変更を行なう。また、必要ならば、当該アプリケーションプログラムの再起動やシグナリング、ユーザＰＣの再起動を行なう場合もある。
【００５７】
なお、図３のクライアント装置は一例であり、クライアント装置としては最低限、図１の設定情報サーバが対応可能なプロトコルのうちの一つに対応するもの（本実施形態の場合、ＬＤＡＰクライアント装置）を構えればよい。
【００５８】
（設定情報サーバの構成例）
次に、ＬＤＡＰ，ＳＬＰ，ＡＣＡＰをはじめとする、設定情報の自動配送に使用されるプロトコルに対応した設定情報サーバ（１，１１，１１１）の構成例について説明する。
【００５９】
最初に、分散ディレクトリをＬＤＡＰのみで実現した場合の設定情報サーバの構成について説明する。
【００６０】
図４に、この場合の設定情報サーバの構成例を示す。図４に示されるように、設定情報サーバは、ネットワーク通信装置１２１、ＬＤＡＰクライアント装置１２２、ディレクトリ検索装置１２３、ディレクトリ装置１２４、連鎖制御装置１２５、ＬＤＡＰサーバ装置１２６、ＳＬＰサーバプロトコル変換装置１２７やＡＣＡＰサーバプロトコル変換装置１２８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００６１】
ネットワークによって送信されてきた設定情報検索要求は、ＬＤＡＰ，ＳＬＰ，ＡＣＡＰ，その他の設定情報の自動配送に用いられるプロトコルの種別に従った、ＬＤＡＰサーバ装置１２６、ＳＬＰサーバプロトコル変換装置１２７、ＡＣＡＰサーバプロトコル変換装置１２８、その他の設定情報の自動配送に用いられるプロトコルのサーバのプロトコル変換装置（図示せず）に渡される。サーバにおけるプロトコル変換の詳細については後述する。
【００６２】
そして、設定情報検索要求の内容に従い、ディレクトリ検索装置１２３によってディレクトリ装置１２４内の情報検索を行なう。ディレクトリ装置１２４の検索では、後述する設定情報検索要求内に含まれた、ユーザＰＣの現在の位置情報から、有効である設定情報の検索を行なう。なお、位置情報やそれにともなう設定情報の検索方法については後述する。また、ディレクトリ内の設定情報の格納方法についても後述する。
【００６３】
検索の結果、関連情報が他の設定情報サーバに存在する旨の情報（後述するサーバリンク情報）が得られた場合、当該サーバリンク情報に従って、連鎖制御装置１２５で適切な設定情報検索要求に変換し、ＬＤＡＰクライアント装置１２２を経て、リンク先設定情報サーバに設定情報検索要求を送出し、関連設定情報を受け取る。
【００６４】
リンク先設定情報サーバは、必要に応じて、同様な連鎖動作を行なう。なお、連鎖動作の詳細な手順については後述する。
【００６５】
なお、図４のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）による手続きの可能なユーザＰＣのみを設定情報検索サービスの対象とすることになる。
【００６６】
続いて、既存の分散ディレクトリ実現手段を用いた場合の設定情報サーバの構成について説明する。
【００６７】
図５に、この場合の設定情報サーバの構成例を示す。図５に示されるように、設定情報サーバは、ネットワーク通信装置１４１、ディレクトリ検索装置１４３、ディレクトリ装置１４４、ＬＤＡＰサーバ装置１４６、ＳＬＰサーバ装置１４７やＡＣＡＰサーバ装置１４８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００６８】
上記の分散ディレクトリをＬＤＡＰのみで実現した場合と同様の手順でディレクトリ装置１４４の検索まで行なう。また、同様にディレクトリ装置１４４の検索では、後述する設定情報検索要求内に含まれた、ユーザＰＣの現在の位置情報から、有効である設定情報の検索を行なう。その検索によって、他の設定情報サーバの管理下にある設定情報を必要とする場合、ディレクトリサーバ（設定情報サーバ）間でディレクトリエントリ情報の相互交換を行なうＤＳＰ（Ｄｉｒｅｃｔｏｒｙ Ｓｙｓｔｅｍ Ｐｒｏｔｏｃｏｌ）、または、分散データベースを実現するプロトコルを用いて、自設定情報サーバに必要情報を取得して、検索処理を完了する。
【００６９】
なお、図５のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）による手続きの可能なユーザＰＣのみを設定情報検索サービスの対象とすることになる。
【００７０】
次に、図４の設定情報サーバの連鎖制御装置について説明する。
【００７１】
連鎖制御装置１２５は、ユーザＰＣから受け取った設定情報検索要求の検索開始点の指定である「ｂａｓｅＯｂｊｅｃｔ」を吟味する。
【００７２】
そこで、自ディレクトリ装置１２４の管理しているディレクトリ情報木の上位（木構造で管理されているディレクトリエントリの根に近い部分であることを上位と呼ぶ）に検索の必要がある場合には、自設定情報サーバが受信した設定情報検索要求のｂａｓｅＯｂｊｅｃｔの指定をそのままに、自設定情報サーバから上位設定情報サーバへの問い合わせを行なう。
【００７３】
また、自設定情報サーバの管理しているディレクトリ情報木の下位（上位に対して、葉に近い方を下位と呼ぶ）である場合は、自ディレクトリ装置１２４内を検索する。この検索により、自ディレクトリ装置１２４の管理しているディレクトリ情報木の下位の設定情報サーバへの関連情報を発見した場合は、関連情報に記述されている、当該設定情報サーバが管理しているディレクトリ情報木内を指すｂａｓｅＯｂｊｅｃｔを指定して、問い合わせを行なう。
【００７４】
これらの他の設定情報サーバへの問い合わせの結果として得られた設定情報は、自設定情報サーバの検索結果と併せて、ユーザＰＣに送り返す。
【００７５】
なお、上記では述べていないが、必要に応じて設定情報サーバからの設定情報検索要求によって、更に連鎖を行なう場合もある。このように、クライアント−サーバの関係による単純な連鎖を繰り返すことは、複雑な分散ディレクトリや分散データベースの実現を必要としないため、実装が容易になる。
【００７６】
（設定情報をディレクトリデータベースに格納する方法、ＬＤＡＰによる設定情報検索要求の記述方法等）
次に、設定情報をディレクトリデータベースに格納する方法と、ＬＤＡＰによる設定情報検索要求の記述方法について説明する。
【００７７】
設定情報の格納方法は、ディレクトリエントリの識別名や属性名で設定情報の種別を表し、各々の値で設定値を記述する。識別名で設定情報の種別を表す場合の例を図６に示し、属性名で設定情報の種別を表す場合の例を図７に示す。
【００７８】
例えば、図６（ａ）や図７（ｂ）では、設定情報の種別は“ＨＴＴＰｐｒｏｘｙ“であり、そのホスト名は“ｐｒｏｘｙ．ｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐ”であり、そのポート番号は“１０８０”であることが記述されている。
【００７９】
なお、図６（ｂ）のディレクトリエントリ例の属性ｄｅｆａｕｌｔＣｏｎｆのように、実際の設定情報そのものを別ディレクトリエントリにしてＵＲＬなどによって、実際の設定情報の所在（設定情報リンク）を示すことにより、設定情報の集約を図ることが可能である。設定情報リンクにより、ディレクトリ情報木の構成に依存した共通設定情報の管理だけでなく、ディレクトリ情報木の構造とは独立した共通設定情報の実現が可能となる。また、設定情報の変更や更新は、設定情報リンク先の集約されている情報の変更、および、更新で完了するため、変更に要する工数を抑えることができる上、変更完了までの時間の短縮を図ることができる。
【００８０】
また、図７では、複数の設定情報を記述可能である。
【００８１】
ところで、当該ディレクトリエントリが、設定情報を属性として保持していることを示すために、次の２つの手法のどちらかが必要となる。一方は、ディレクトリエントリのクラスを表すｏｂｊｅｃｔＣｌａｓｓ属性の値として設定情報クラスに属する値（例えば、“ｃｏｎｆｉｇｕｒｅ”）を付与する方法、一方は、ディレクトリエントリに設定情報のみが持ち得る属性（例えば、属性名“ｃｏｎｆｉｇｕｒａｔｉｏｎ”）を付与する方法である。ｏｂｊｅｃｔＣｌａｓｓを用いた例を図８に、ｃｏｎｆｉｇｕｒａｔｉｏｎ属性を用いた例を図９に示す。
【００８２】
いずれの手法にせよ、設定情報サーバ内の設定情報の格納方法をユーザＰＣが知らない場合でも、ｏｂｊｅｃｔＣｌａｓｓが“ｃｏｎｆｉｇｕｒｅ”であるものを取得する検索、または、属性として“ｃｏｎｆｉｇｕｒａｔｉｏｎ“を持っているエントリを取得する検索によって、設定情報の取得が可能となる。それぞれの場合の、設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の例を、図１０、図１１に示す。
【００８３】
また、設定情報の格納方法についての知識をユーザＰＣが持ち合わせている場合、設定情報検索要求で条件を指定することにより、特定の設定情報のみを取得することが可能である。この場合の設定情報検索要求の例を、図１２に示す。図１２では、識別名のＣＮ（ｃｏｍｍｏｎＮａｍｅ）に設定情報種別が指定されている場合に、“ＨＴＴＰｐｒｏｘｙ”の設定情報を取得するための設定情報検索要求を示している。
【００８４】
（スコープ）
次に、ディレクトリエントリが保持している設定情報の影響範囲もしくは適用範囲（例えば、ドメイン名）を規定する方式について説明する。
【００８５】
設定情報の影響範囲もしくは適用範囲（以下、スコープと呼ぶ）の記述のために、スコープ属性を付与する。ただし、記述には、ワイルドカードや正規表現を用いた、非決定的な記述方法を使用する。スコープの属性の例を、図１３（ａ），（ｂ）に示す。
【００８６】
スコープは、属性ｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅの値として保持され、ドメイン名のようなネットワーク識別子やｅｍａｉｌアドレスのようなユーザ識別子で表現される。ワイルドカード（図中の“＊”）や正規表現を用いることにより、一意のドメインや特定ドメインのユーザだけでなく、多彩なサブネットの指定や、複数ドメインを行き来するユーザに対して共通設定を配送することを実現できる。
【００８７】
また、このスコープは、複数の設定情報サーバで分散管理された、同一のサービスやアプリケーションプログラムに対する設定情報の、優先順位を表現することも可能である。例えば、ドメインｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｃｏ．ｊｐにおける設定情報として、ｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅ＝“＊．ｆｏｏ．ｈｏｇｅ．ｃｏ．ｊｐ”のディレクトリエントリとｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅ＝“＊．ｈｏｇｅ．ｃｏ．ｊｐ”のディレクトリエントリとがある場合は、全社のディレクトリエントリが、より適切な設定情報であることを判別できる。従って、例えば、非決定的な記述がなされたスコープと、ユーザＰＣ（例えば、Ａ−１−ａ）の決定的な記述による現在位置を示すドメイン名を比較した場合、決定的な部分同士の最長一致比較を行ない、優先順位を決定することが可能となる。また、例えば、スコープまでも同一の設定情報が複数ある場合は、更に、ディレクトリエントリの識別名を基に（ディレクトリ情報木の上位または下位を基準にするなどの方法で）、設定情報の優先順位を判断する場合もあり得る。
【００８８】
一方、設定情報検索要求に、現在の位置情報としてのドメイン名を指定したスコープを指示することにより、設定情報サーバ側の検索範囲の絞り込みが可能である。この場合の設定情報検索要求の例を図１４に示す。この設定情報検索要求を受け取った設定情報サーバは、自ディレクトリ装置内のディレクトリエントリの検索結果の取得や、分散による他自動設定サーバへの連鎖問い合わせやＤＳＰ、および、分散データベースプロトコルによる情報取得の際に、無駄な範囲の検索を排除することが出来る。
【００８９】
なお、ユーザＰＣは、設定情報検索要求に、複数のドメイン名（例えば、移動元のホームポジションとなる位置および移動後の現在の位置のドメイン名）を指定したスコープを指示できるようにしてもよい。
【００９０】
（サーバリンク情報）
次に、ディレクトリ情報木を協調しながら分散管理している設定情報サーバ間の関連情報であるサーバリンク情報を図１５（ａ），（ｂ）に示す。
【００９１】
図１５に示すように、サーバリンク情報も通常のディレクトリエントリとして保持される。ただし、そのエントリの属性であるｌｉｎｋＴｏは制御属性と呼ばれ、設定情報サーバの連鎖制御、および参照（紹介）制御に用いられるための属性である。ｌｉｎｋＴｏ属性の値として、ＵＲＬ表記を用いることができる。また、ｌｉｎｋＴｏ属性には該当するサーバのホスト名のみを記述し、その設定情報サーバが管理権限を持つ開始点の識別名を別の属性（図１５の例では、ｌｉｎｋＢａｓｅＯｂｊｅｃｔ）で示してもよい。
【００９２】
以下、ディレクトリ情報木を表記する場合、上位ネットワーク、または、下位ネットワークの関係で隣接する設定情報サーバ間は、図１５に示されているようなサーバリンク情報によって、お互いの関係を保持していることを前提とする。
【００９３】
また、各々の設定情報サーバは、自サーバが管理権限を持っているディレクトリ情報木の開始点の情報（識別名）を、設定情報サーバの管理者の設定により保持していることも前提とする。このため、上記のサーバリンク情報と管理権限の開始点の情報から、上記の上位設定情報サーバ、および、下位の設定情報サーバの判別が可能である。
【００９４】
（動作シーケンス例１）
次に、図１の環境における、ディレクトリ情報木の構成例を図１６に示す。
【００９５】
図１６は、ＨＴＴＰｐｒｏｘｙに関する設定情報は全社で共通のため、全社設定情報サーバによって管理され、部門Ａ−１にあるプリンタサーバについての設定情報は、部門Ａ−１設定情報サーバで管理される場合を仮定している。また、部門Ａ−１設定情報サーバは、自分の管理しているディレクトリ情報木の上位は部門Ａ設定情報サーバが管理していることを知っている。また、部門Ａ設定情報サーバは、全社設定情報サーバが上位を、部門Ａ−１設定情報サーバが下位を管理していることを知ってる。さらに、全社設定情報サーバは、部門Ａ設定情報サーバが下位を管理していること（下位へのリンクと呼ぶ）を知っているとする。
【００９６】
このとき、設定情報サーバが、分散ディレクトリの実装を行なわずに、連鎖制御装置によって管理されている状況の、部門Ａ−１のネットワーク（ｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐサブネット）に接続されていたユーザＰＣ（Ａ−１−ａ）が設定情報を自動取得する場合の動作シーケンスを図１７に示す。
【００９７】
なお、図１７においては、各サーバの動作上、第１番目〜第５番目の要求と第５番目〜第１番目の配送とがそれぞれ対応してなされるものであり、従って、例えば、部門Ａ−１設定情報サーバにおいて、第１番目の配送（部門Ａ設定情報サーバへのｐｒｉｎｔｅｒＳｅｒｖｅｒ情報の配送）は、受信した第１番目の要求（ユーザＰＣ（Ａ−１−ａ）からのｂａｓｅＯｂｊｅｃｔが“”の要求）とは、独立して行われる。
【００９８】
また、この場合の設定情報サーバの構成例を図４に示す。
【００９９】
ユーザＰＣ（Ａ−１−ａ）は、ＤＨＣＰや手設定などによりネットワークの設定（ＩＰアドレス，ネームサーバ，経路制御）は完了しているものとする。まず、設定情報サーバについて、ドメイン名に特定の名前を付加したホスト名の使用、自動設定用マルチキャストアドレスの使用、ブロードキャストによる設定情報サーバの検索方法の使用、手設定による指示といった手法に代表されるサーバ探索の方式により、設定情報サーバ探索を完了する。
【０１００】
次に、ｂａｓｅＯｂｊｅｃｔを“”（ｎｕｌｌ）とした（ユーザＰＣは適切なｂａｓｅＯｂｊｅｃｔを知っているとは限らないため、ここでは無指定の要求を想定している）、図１８に例示するような設定情報検索要求（ＬＤＡＰ ｓｅａｒｃｈメッセージ）を設定情報サーバに送信する。
【０１０１】
設定情報検索要求を受信した部門Ａ−１設定情報サーバは、ｂａｓｅＯｂｊｅｃｔが指定されてないので、なるべく最上位の木から検索を開始するために、受け取った設定情報検索要求を基に、上位の設定情報サーバである部門Ａ設定情報サーバに連鎖問い合わせを行なう。
【０１０２】
部門Ａ設定情報サーバは、同様に、全社設定情報サーバに問い合わせを行なう。
【０１０３】
全社設定情報サーバでは、更に上位の設定情報の検索の必要性はない（そのように設定する、または上位サーバへの関連を記述しない）。そこで、ディレクトリ装置を検索し、“ＯＵ＝Ａ”以下に関しての情報は部門Ａ設定情報サーバが保持していることと、ＨＴＴＰｐｒｏｘｙの設定情報を知る。そこで、ｂａｓｅＯｂｊｅｃｔを“Ｏ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ“とした、当該設定情報検索要求（ＬＤＡＰ ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）を部門Ａ設定情報サーバに転送する。
【０１０４】
それを受信した部門Ａ設定情報サーバは、全社設定情報サーバと同様に動作し、“ＯＵ＝Ａ−１”以下に関しての情報は部門Ａ−１設定情報サーバが保持していることを知り、ｂａｓｅＯｂｊｅｃｔを“Ｏ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ， ＯＵ＝Ａ−１”として、当該設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）を部門Ａ−１設定情報サーバの転送する。
【０１０５】
それを受信した部門Ａ−１設定情報サーバは、自ディレクトリ装置の検索の結果、ｐｒｉｎｔｅｒ Ｓｅｒｖｅｒの設定情報を得る。そして、その検索結果（ｐｒｉｎｔｅｒＳｅｒｖｅｒ）を設定情報として、部門Ａ設定情報サーバに配送する。
【０１０６】
さらに、それを受信した部門Ａ設定情報サーバは、その配送された設定情報（ｐｒｉｎｔｅｒＳｅｒｖｅｒ）を、全社設定情報サーバに配送する。
【０１０７】
全社設定情報サーバは、自検索結果であるＨＴＴＰｐｒｏｘｙと、受信したｐｒｉｎｔｅｒＳｅｒｖｅｒとを設定情報として、部門Ａ設定情報サーバに配送する。
【０１０８】
ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報を受信した部門Ａ設定情報サーバは、部門Ａ−１設定情報サーバにそれらを配送する。
【０１０９】
最後に、部門Ａ−１設定情報サーバは、収集した設定情報（この場合、ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報）をユーザＰＣ（Ａ−１−ａ）に配送する。
【０１１０】
以上の手順を踏むことにより、分散した設定情報サーバ間の設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の無限ループを回避しつつ、関連するディレクトリの探索を行なうことが出来る。
【０１１１】
配送された設定情報を受信したユーザＰＣ（Ａ−１−ａ）は、設定情報に従って設定を反映する。
【０１１２】
なお、受信した設定情報に、ＨＴＴＰｐｒｏｘｙに関する設定情報が複数あるといった重複があるような場合には、例えば、スコープを示す属性を検査し、ワイルドカード（または、正規表現における任意の値にマッチする特殊記号）を除いた部分で最長マッチのような評価関数を用いることにより、設定情報を選択して該当しないものを除去し、重複を排除することが出来る。
【０１１３】
（動作シーケンス２）
次に、図１のネットワークで、図１６のディレクトリ情報木の構成において、すべての設定情報サーバが分散ディレクトリを実現するプロトコルであるＤＳＰや、分散データベースを実現するためのプロトコルを備えた場合の動作シーケンスを、図１９に示す。なお、実際には、これらのプロトコルでは、情報の一貫性、妥当性を保護するための複雑な機構が働き、設定情報サーバ間の手続は図１９に示すほど容易なものではなく多様なものであるが、図１９はこれを概念的に簡単化して表現したものである。
【０１１４】
なお、この場合の設定情報サーバの構成例を図５に示す。
【０１１５】
ユーザＰＣ（Ａ−１−ａ）は、ｂａｓｅＯｂｊｅｃｔを“”（ｎｕｌｌ）とした設定情報検索要求を部門Ａ−１設定情報サーバに送信する。
【０１１６】
ユーザＰＣ（Ａ−１−ａ）から設定情報検索要求を受け取った部門Ａ−１設定情報サーバは、分散されたディレクトリ情報木の全体を取得するために、ＤＳＰまたは分散データベースプロトコルで情報収集を行なう。
【０１１７】
最後に、部門Ａ−１設定情報サーバは、収集した設定情報（この場合、ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報）をユーザＰＣ（Ａ−１−ａ）に配送する。
【０１１８】
（動作シーケンス３）
次に、ＬＤＡＰの機能であるサーバの参照（ｒｅｆｅｒｒａｌ）の提示のみによる、クライアント自身の連鎖動作を適用した場合の本自動設定システムについて説明する。
【０１１９】
図１のネットワークで、図１６のディレクトリ情報木の構成における動作シーケンスを図２０に示す。
【０１２０】
なお、図２０においては、ユーザＰＣの手続が全体で一連の手続きとなる。また、各サーバでは、第１番目〜第５番目の要求の受信と第１番目〜第５番目の配送とがそれぞれ対応してさなれるものであり、従って、例えば、部門Ａ−１設定情報サーバにおける最初の要求受信／配送と、最後の要求受信／配送とは、独立して行われる。
【０１２１】
また、この場合の設定情報サーバの構成例は、図５において設定情報サーバ間通信の機能を持たず、連携すべき相手となる設定情報サーバを、ユーザＰＣに紹介するようにしたものである。
【０１２２】
ユーザＰＣ（Ａ−１−ａ）はｂａｓｅＯｂｊｅｃｔを指定しないで部門Ａ−１設定情報サーバに問い合わせる。部門Ａ−１サーバは、なるべく最上位の木から検索を開始するために、受け取った設定情報検索要求を基に、上位の設定情報サーバである部門Ａ設定情報サーバを紹介する。
【０１２３】
その紹介に従い、部門Ａ設定情報サーバに問い合わせると、同様に全社設定情報サーバの紹介を受ける。
【０１２４】
ユーザＰＣ（Ａ−１−ａ）は、全社設定情報サーバに同様に問い合わせると、ＨＴＴＰｐｒｏｘｙの設定情報と、ｂａｓｅＯｂｊｅｃｔをＯ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａとして問い合わせる旨の部門Ａ設定情報サーバの紹介を受ける。
【０１２５】
それに従い、部門Ａ設定情報サーバに問い合わせると、ｂａｓｅＯｂｊｅｃｔをＯ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ， ＯＵ＝Ａ−１として問い合わせる旨の部門Ａ−１設定情報サーバの紹介を受ける。
【０１２６】
さらにそれに従い、部門Ａ−１設定情報サーバに問い合わせると、ｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報を受け取って、自動設定情報の取得は完了する。
【０１２７】
このように、参照の提示による紹介に従ってユーザＰＣ（Ａ−１−ａ）が個々に問い合わせると、手順の増加とそれぞれの設定情報サーバでの認証情報の管理が必要となるが、分散された個々の情報に関するユーザ対応のきめ細かな権限の制御が可能である。
【０１２８】
（動作シーケンス４）
ここで、図１６のディレクトリ情報木の構成で、図２１に示すように、ユーザＰＣ（Ａ−ａ）がネットワーク２に接続された場合について説明する。
【０１２９】
この場合、ユーザＰＣ（Ａ−ａ）は、図２２の設定情報検索要求を送信する。
【０１３０】
図２３に、設定情報サーバが、連鎖制御装置で実装されている場合の動作シーケンスを示す。
【０１３１】
ユーザＰＣ（Ａ−ａ）は、部門Ａ設定情報サーバに設定情報検索要求を送り、連鎖して全社設定情報サーバに設定情報検索要求が届き、下位の検索として再び部門Ａ設定情報サーバに検索要求が渡される。ここで、源の検索要求は、ネットワーク２に接続されたユーザＰＣ（Ａ−ａ）によるものなので、スコープとしてｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐが指定されている。
【０１３２】
部門Ａ設定情報サーバは、部門Ａ−１設定情報サーバへの関連を知っているが、スコープ外であることから連鎖は行なわない。
【０１３３】
以下、要求を遡るように設定情報が配送されていく。
【０１３４】
すべての設定情報サーバが分散ディレクトリを実現するプロトコルであるＤＳＰや、分散データベースを実現するためのプロトコルを備えた場合においても、また、参照に対応したユーザＰＣ（Ａ−１−ａ）による連鎖制御においても同様である。
【０１３５】
（プロトコル変換装置）
次に、図２の構成例のユーザＰＣにおけるプロトコル変換装置の一例として、ＳＬＰ・ＬＤＡＰプロトコル変換装置について説明する。
【０１３６】
設定情報は、図６のようにサービス単位でのディレクトリエントリを作成し、識別名（属性）ＣＮにそのサービス種別を記述しているとする。
【０１３７】
本ＳＬＰ・ＬＤＡＰプロトコル装置は、ＳＬＰにのみ対応した（もしくはＬＤＡＰには対応していないがＳＬＰには対応している）アプリケーションプログラムがＳＬＰを用いて行なうネットワーク上のサービスに関する情報取得動作を終端し、ＬＤＡＰを用いた設定情報取得動作として変換し、設定情報を取得できるようにするためのものである。ただし、ＳＬＰに関する設定は、ユーザにより完了しておかなければならない。
【０１３８】
ＳＬＰによって設定情報を取得するアプリケーションプログラムは、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔメッセージを送出しＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージを受信することで、ネットワーク上に存在するすべてのサービスを知り、Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを送出しＳｅｒｖｉｃｅ Ｒｅｐｌｙを受信することで、サービスを提供しているサーバの所在を知ることとする。そして、必要に応じてＡｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔメッセージの送信とＡｔｔｒｉｂｕｔｅ Ｒｅｐｌｙメッセージの受信により、当該サービスの属性を得ることとする。
【０１３９】
まず、ＳＬＰのＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔメッセージから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図２４（ａ），（ｂ）に示す。
【０１４０】
Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔの＜ＰＲＬｉｓｔ＞は、以前使用したＳＬＰサーバを指定するもので、設定情報検索要求の送出先（ＬＤＡＰとしての接続先）として使用することも出来るが、通常は上述の設定情報サーバの探索によって接続先を決定する。この指定がない場合や、この指定があってもｌｏｃａｌｈｏｓｔを指し示している場合も、上述の設定情報サーバの探索を行なう（むしろ、無意味に指定があるよりも、＜ＰＲＬｉｓｔ＞の指定がない場合やｌｏｃａｌｈｏｓｔ指定の方が好ましいと言える）。ＮａｍｉｎｇＡｕｔｈｏｒｉｔｙは、結果の範囲を指定する機能を持つ指定であるが、ＬＤＡＰには該当する機能が存在しないので無視する。＜ｓｃｏｐｅ−ｌｉｓｔ＞は、対象とするサービスをスコープとして指定できる。＜ｓｃｏｐｅ−ｌｉｓｔ＞がＤＥＦＡＵＬＴの場合は、ユーザＰＣ（例えば、Ａ−１−ａ）の接続されたネットワークのドメイン名をｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅとして指定したｆｉｌｔｅｒを記述する。＜ｓｃｏｐｅ−ｌｉｓｔ＞がＤＥＦＡＵＬＴ以外の値の場合は、その値をｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅとして指定したｆｉｌｔｅｒを記述する。また、ａｔｔｒｓとして、結果として欲しい属性値をＣＮに絞ることにより、サービス種別のみを得ることで無駄な通信を避けることが出来る。この要求により、設定情報サーバは、当該設定情報検索要求に従ったディレクトリエントリ（設定情報）のサービス種別（ＣＮ）の情報を返す。
【０１４１】
次に、この受け取ったサービス種別の情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔ）からＳＬＰのＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージへの変換の例を、図２５（ａ），（ｂ）に示す。
【０１４２】
受信したＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔには、検索結果として設定情報のサービス単位に存在するディレクトリエントリのサービス種別を示すＣＮ属性の値が入っている。従って、ＳＬＰ Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージの＜ｓｒｖｔｙｐｅ−ｌｉｓｔ＞に入れて、アプリケーションプログラムに返送する。
【０１４３】
次に、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージから設定情報検索要求への変換の例を、図２６（ａ），（ｂ）に示す。
【０１４４】
＜ＰＲＬｉｓｔ＞，＜ｓｃｏｐｅ−ｌｉｓｔ＞は、先の例と同様である。＜ｓｅｒｖｉｃｅ−ｔｙｐｅ＞の指定は、自動設定情報（ＬＤＡＰ）のＣＮの指定に相当する。ｐｒｅｄｉｃａｔｅ ｓｔｒｉｎｇは、ＳＬＰの仕様上、ＬＤＡＰのｆｉｌｔｅｒを記述することになっているので、該当するｆｉｌｔｅｒ条件を追加する。ＳＬＰ ＳＰＩは、ＳＬＰクライアント／サーバ間のセキュリティーパラメータインデックスなので、設定情報検索要求では無視する。この要求により、指定されたサービスに関する設定情報が受信できる。
【０１４５】
次に、この受信した設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）からＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージへの変換の例を、図２７（ａ），（ｂ）に示す。
【０１４６】
受信したメッセージに含まれるサービス種別情報（ＣＮ属性），ホスト名情報（ｈｏｓｔｎａｍｅ属性）とポート番号情報（ｐｏｒｔＮｕｍｂｅｒ属性）を、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージ中のＵＲＬに記述し、結果として返送する。受信した設定情報が、ネットワーク上のサービスに関係しない（ホスト名情報とポート番号情報を保持していない）場合は、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージには変換せずに無視する。
【０１４７】
次に、ＳＬＰ Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図２８（ａ），（ｂ）に示す。
【０１４８】
＜ＰＲＬｉｓｔ＞，＜ｓｃｏｐｅ−ｌｉｓｔ＞，ＳＬＰ ＳＰＩは先の例と同様である。ＵＲＬは、記述内容からサービス種別，ホスト名，ポート番号の指定を読みとり、ＣＮ，ｈｏｓｔｎａｍｅ，ｐｏｒｔＮｕｍｂｅｒ属性への条件指定に変換する。＜ｔａｇ−ｌｉｓｔ＞は、結果として受け取りたい属性の指定なので、ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージのａｔｔｒｓとして列挙し、それらの結果を受け取れるようにする。＜ｔａｇ−ｌｉｓｔ＞が省略された場合はａｔｔｒｓも省略し、すべての属性を受け取るようにする。この要求により、指令されたサービスに関する属性を受信できる。
【０１４９】
次に、この受信した属性の情報である設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）からＳＬＰ Ａｔｔｒｉｂｕｔｅ Ｒｅｐｌｙへの変換の例を、図２９（ａ），（ｂ）に示す。
【０１５０】
受信したＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔの属性を、＜ａｔｔｒ−ｌｉｓｔ＞に列挙する。
【０１５１】
なお、ＳＬＰのサービス情報登録メッセージと、ＬＤＡＰの情報登録メッセージとの間の変換も同様に可能である。
【０１５２】
これまで述べたようにＳＬＰ・ＬＤＡＰプロトコル変換装置を用いることで、メッセージの変換を行なうことで、ＳＬＰにのみ対応したアプリケーションプログラムに対して、自動的に設定情報を与えることが出来る（ただし、ＳＬＰで用いられるセキュリティー機能とＬＤＡＰのセキュリティー機能を透過に機能させることは実現できていない）。これまでに述べていないＳＬＰメッセージや、個々のＳＬＰとＬＤＡＰのメッセージに含まれている様々な情報は変換の必要がないものであるが、アプリケーションプログラムとＳＬＰ・ＬＤＡＰ変換装置間や、ＳＬＰ・ＬＤＡＰ変換装置と設定情報サーバ間で、それぞれのＳＬＰ，ＬＤＡＰのプロトコル仕様に従った振舞を行なわなければならない。
【０１５３】
次に、図１のネットワークで、図１６のディレクトリ情報木の構成において、上記ＳＬＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスを、図３０に示す。
【０１５４】
図３０では、アプリケーションプログラムは、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ， Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ， Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔの順にＳＬＰメッセージを送信する。それぞれのＳＬＰメッセージは、ＳＬＰ・ＬＤＡＰプロトコル変換装置で受信され、ＬＤＡＰのメッセージに変換されて、部門Ａ−１設定情報サーバに送信される。部門Ａ−１設定情報サーバと関連する部門Ａ設定情報サーバ，全社設定情報サーバの動作は、以前に述べてきた連鎖動作などを同様に行なう。また、ＳＬＰ・ＬＤＡＰ変換装置がＬＤＡＰのメッセージとして受信した検索結果は、それぞれのＳＬＰ Ｒｅｐｌｙメッセージとしてアプリケーションプログラムに返送され、アプリケーションプログラムはその情報で自動設定を行なう。
【０１５５】
ところで、アプリケーションプログラムとＳＬＰ・ＬＤＡＰプロトコル変換装置間、および、ＳＬＰ・ＬＤＡＰプロトコル変換装置と自動設定サーバ間の認証に関しては、各々の間での認証に関する制御は独立に行なうことで対処する。つまり、アプリケーションプログラムがＳＬＰ・ＬＤＡＰプロトコル変換装置との間で交わす認証方式および認証情報は、ＳＬＰ・ＬＤＡＰプロトコル変換装置が自動設定サーバとの間で交わす認証方式および認証情報とは無関係にする。従って、設定情報サーバがユーザを認証して設定情報の操作を行なう場合には、ユーザはアプリケーションプログラムに関しての認証制御を事前設定するのではなく、ＳＬＰ・ＬＤＡＰプロトコル変換装置に関しての認証制御を事前設定する。また、自動設定サーバから得た設定情報を、今後に見込まれるＳＬＰによる問い合わせのために、ＳＬＰ・ＬＤＡＰプロトコル変換装置でキャッシュすることも可能である。
【０１５６】
次に、図２の構成例のユーザＰＣにおけるプロトコル変換装置の一例として、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置について述べる。
【０１５７】
設定情報は、図６のようにサービス単位でのディレクトリエントリを作成し、識別名（属性）ＣＮにそのサービス種別を記述しているとする。
【０１５８】
本ＡＣＡＰ・ＬＤＡＰプロトコル装置は、ＡＣＡＰにのみ対応した（もしくはＬＤＡＰには対応していないがＡＣＡＰには対応している）アプリケーションプログラムがＡＣＡＰを用いて行なう各種設定情報の取得動作を終端し、ＬＤＡＰを用いた設定情報取得動作として変換し、設定情報を取得できるようにするためのものである。ただし、ＡＣＡＰに関する設定は、ユーザにより完了しておかなければならない。
【０１５９】
ＡＣＡＰによって設定情報を取得するアプリケーションプログラムは、ＡＣＡＰサーバに接続するとＡＵＴＨＥＮＴＩＣＡＴＥコマンドによって認証を行ない、ＳＥＡＲＣＨコマンドによって設定情報の検索と取得を行なうことで、アプリケーションプログラムに必要な設定情報を取得する。
【０１６０】
まず、ＡＣＡＰの認証のパラメータとＬＤＡＰのＢｉｎｄ Ｒｅｑｕｅｓｔメッセージの変換の例を、図３１（ａ）〜（ｄ）に示す（ただし、図３１におけるＬＤＡＰのメッセージは、概念的なものを表現たものであり、実際に図３１のようなメッセージ構成になっていることを意味しているものではない）。
【０１６１】
ＡＣＡＰでは、接続後に認証を完了するためにＡＵＴＨＥＮＴＩＣＡＴＥコマンドと、その引数として認証手法の指定を送信する。ＡＣＡＰでは、認証方法にはＡＮＯＮＹＭＯＵＳを指定する。変換装置はＡＣＡＰ ＡＵＴＨＥＮＴＩＣＡＴＥコマンドをＬＤＡＰ ＢｉｎｄＲｅｑｕｅｓｔメッセージに変換して送信し、その返事として受け取るＬＤＡＰ ＢｉｎｄＲｅｐｌｙをＡＵＴＥＮＴＩＣＡＴＥコマンドに対するサーバの応答として返す。
【０１６２】
次に、ＡＣＡＰ ＳＥＡＲＣＨコマンドから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図３２（ａ），（ｂ）に示す。
【０１６３】
ＡＣＡＰのＳＥＡＲＣＨコマンドのＬＩＭＩＴ，ＭＡＫＥＣＯＮＴＥＸＴ，ＮＯＩＮＨＥＬＩＴ，ＳＯＲＴオプションは、ＬＤＡＰには該当する機能が存在しないため変換の対象ではない。ただし、その他のＨＡＲＤＬＩＭＩＴ，ＲＥＴＵＲＮは、それぞれＬＤＡＰにおけるｓｉｚｅｌｉｍｉｔ，ａｔｔｒｓの指定に相当する。ＨＡＲＤＬＩＭＩＴはｓｉｚｅｌｉｍｉｔにそのまま入れ、ＲＥＴＵＲＮは、内容として列挙されている属性名をａｔｔｒｓとして列挙することで変換が可能である。また、ＡＣＡＰ ＳＥＡＲＣＨコマンドの検索条件の論理式に使用する、ＡＬＬ， ＡＮＤ， ＣＯＭＰＡＲＥ， ＮＯＴ， ＯＲ， ＰＲＥＦＩＸ， ＲＡＮＧＥ， ＳＵＢＳＴＲＩＮＧは、それぞれ、ＬＤＡＰのＳｅａｒｃｈ Ｒｅｑｕｅｓｔのｆｉｌｔｅｒにおける、＆，−，！，＝，＝〜，＜，＞と＊の組合せで実現できる。ここで、設定情報のディレクトリエントリとＡＣＡＰのエントリ構造の違いから、設定情報である属性だけでなく、ＡＣＡＰのエントリ構造における名前をａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅ属性によって保持させていることを前提としている。これは、設定情報だけを扱うＡＣＡＰに対し、不確定の様々な情報を扱うディレクトリでは、ＡＣＡＰのエントリ構造を再現する保証が出来ないためであり、再現するよりもより現実的な解決策だからである。
【０１６４】
ＤＥＰＴＨの値が０の場合は、ａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅは完全一致、１以上の場合はａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅは指定された検索開始点を示す名前が先頭に含まれる比較を行なうようにｆｉｌｔｅｒに記述する。
【０１６５】
一方、ディレクトリエントリの木構造を、ＡＣＡＰのそれと一致させることが出来る場合は、ａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅ属性は不要となる。この場合のＡＣＡＰ ＳＥＡＲＣＨコマンドから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図３３（ａ），（ｂ）に示す。
【０１６６】
この場合は、ＡＣＡＰの検索開始点をＬＤＡＰのｂａｓｅＯｂｊｃｔに一致させて検索を行なっている。この場合、ＡＣＡＰのＳＥＡＲＣＨコマンドのＤＥＰＴＨの値が０の場合は、ＬＤＡＰの検索範囲を指定するＳｅａｒｃｈ ＲｅｑｕｅｓｔのｓｃｏｐｅにはｂａｓｅＯｂｊｅｃｔを、ＤＥＰＴＨが１の場合はｓｃｏｐｅにはｓｉｎｇｌｅ Ｌｅｖｅｌを、ＤＥＰＴＨが２以上の場合はｓｃｏｐｅをｗｈｏｌｅ Ｓｕｂｔｒｅｅに指定することでＬＤＡＰのディレクトリ内の探索範囲を（ＬＤＡＰの機能によって）制御することが可能なように変換できる。この要求によって受信した設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）のエントリの属性名と属性値を順次返送することで、ＡＣＡＰサーバの結果として返すことが出来る。
【０１６７】
なお、ＡＣＡＰのサービス情報登録コマンドと、ＬＤＡＰの情報登録メッセージとの間の変換も同様に可能である。
【０１６８】
次に、図１のネットワークで、図３４のディレクトリ情報木の構成において、上記ＡＣＡＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスを、図３５に示す。
【０１６９】
図３５では、アプリケーションプログラムは、ＡＵＴＨＥＮＴＩＣＡＴＥ， ＳＥＡＲＣＨ， ＬＯＧＯＵＴの順にＡＣＡＰコマンドを送信する。アプリケーションプログラムは、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドを送信し、匿名での接続を行なう。それを当該プロトコル変換装置が受信し、ＬＤＡＰ Ｂｉｎｄメッセージを部門Ａ−１自動設定サーバに送信する。そして部門Ａ−１自動設定サーバからのＬＤＡＰ Ｂｉｎｄ Ｒｅｓｐｏｎｃｅメッセージを受信して、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドの応答を返送する。
【０１７０】
次に、アプリケーションプログラムは必要な設定である／ＨＴＴＰ／以下（ａｃａｐＤａｔａｓｅｔＮａｍｅ＝／ＨＴＴＰ／＊）を検索すべく、ＡＣＡＰ ＳＥＡＲＣＨコマンドを送信し、当該プロトコル変換装置が受信し、先の例のように設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔ）に変換したメッセージを部門Ａ−１設定情報サーバに送信する。部門Ａ−１設定情報サーバと関連する部門Ａ設定情報サーバ，全社設定情報サーバの動作は、以前に述べてきた連鎖といった動作を同様に行なう。また、ＡＣＡＰ・ＬＤＡＰ変換装置がＬＤＡＰのメッセージとして受信した検索結果は、ＡＣＡＰ ＳＥＡＲＣＨコマンドの返答としてアプリケーションプログラムに返送され、アプリケーションプログラムはその情報で自動設定を行なう。
【０１７１】
ところで、アプリケーションプログラムとＡＣＡＰ・ＬＤＡＰプロトコル変換装置間、および、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置と自動設定サーバ間の認証に関しては、上記のＳＬＰ・ＬＤＡＰプロトコル変換装置の場合と同様に、各々の間での認証に関する制御は独立に行なうことで対処する。また、ＳＬＰ・ＬＤＡＰプロトコル変換装置と同様に、自動設定サーバから得た設定情報を、今後に見込まれるＡＣＡＰによる問い合わせのために、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置でキャッシュすることも可能である。
【０１７２】
最後に、図４および図５の設定情報サーバに設置されている、ＳＬＰサーバプロトコル変換装置とＡＣＡＰサーバプロトコル変換装置について、図１のネットワークを例に述べる。ＳＬＰサーバプロトコル変換装置は、ユーザＰＣのアプリケーションプログラムがＳＬＰに対応しているが、ＳＬＰ・ＬＤＡＰプロトコル変換装置を持っていない場合に使用される。ユーザＰＣとＳＬＰサーバプロトコル変換装置間の動作は、ＳＬＰの仕様に従う。一方、ＳＬＰサーバプロトコル変換装置がユーザＰＣから受信する、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ， Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ， Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔメッセージは、上記、ＳＬＰ・ＬＤＡＰプロトコル変換装置の場合と同様の方法でＬＤＡＰのメッセージとして解釈され、ディレクトリ装置の検索を実施する（実際に、変換される必要はないが、してもよい）。また、ＡＣＡＰサーバプロトコル変換装置についても、ＳＬＰサーバ変換装置と同様で、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドとＳＥＡＲＣＨコマンドはＡＣＡＰ・ＬＤＡＰプロトコル変換装置と同様の方法でＬＤＡＰメッセージとして解釈し、ディレクトリ装置の検索を実施する（実際に、変換される必要はないが、してもよい）。
【０１７３】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１７４】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１７５】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１７６】
【発明の効果】
本発明によれば、各ネットワークドメインに配置された上位／下位の情報設定サーバ装置が連携することで（あるいは、他の情報設定サーバ装置を利用者計算機に紹介することで）、例えば利用者計算機が移動先でプログラムを動作する際に、利用者計算機は自装置が接続したネットワークドメインの情報設定サーバ装置に検索要求を出すだけで、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行い、自装置の現在位置を考慮した適切なアプリケーションプログラムへの設定情報の自動設定が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る通信システムのネットワーク構成例を示す図
【図２】本発明の一実施形態に係る利用者計算機の一構成例を示す図
【図３】本発明の一実施形態に係る利用者計算機の他の構成例を示す図
【図４】本発明の一実施形態に係る設定情報サーバの一構成例を示す図
【図５】本発明の一実施形態に係る設定情報サーバの他の構成例を示す図
【図６】設定情報の格納形式の一例を示す図
【図７】設定情報の格納形式の他の例を示す図
【図８】ｏｂｊｅｃｔＣｌａｓｓによる設定情報の記述例を示す図
【図９】ｃｏｎｆｉｇｕｒａｔｉｏｎ属性による設定情報の記述例を示す図
【図１０】ｏｂｊｅｃｔＣｌａｓｓによる設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１１】ｃｏｎｆｉｇｕｒａｔｉｏｎ属性による設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の他の例を示す図
【図１２】条件付け設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１３】スコープを用いた設定情報の格納形式の一例を示す図
【図１４】スコープを指定した設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１５】サーバリンク情報の格納形式の一例を示す図
【図１６】設定情報のディレクトリ情報木の構成例を示す図
【図１７】情報取得動作シーケンスの一例を示す図
【図１８】設定情報検索要求の一例を示す図
【図１９】情報取得動作シーケンスの他の例を示す図
【図２０】情報取得動作シーケンスのさらに他の例を示す図
【図２１】本発明の一実施形態に係る通信システムのネットワーク構成例を示す図
【図２２】設定情報検索要求の他の例を示す図
【図２３】情報取得動作シーケンスのさらに他の例を示す図
【図２４】Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２５】Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図２６】Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２７】Ｓｅｒｖｉｃｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図２８】Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２９】Ａｔｔｒｉｂｕｔｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図３０】ＳＬＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスの一例を示す図
【図３１】ＡＵＴＨＥＮＴＩＣＡＴＥ（ＡＣＡＰ）の変換例について説明するための図
【図３２】ＳＥＡＲＣＨ（ＡＣＡＰ）の一変換例について説明するための図
【図３３】ＳＥＡＲＣＨ（ＡＣＡＰ）の他の変換例について説明するための図
【図３４】設定情報のディレクトリ情報木の構成例を示す図
【図３５】ＡＣＡＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスの一例を示す図
【符号の説明】
１…全社設定情報サーバ
１１…部門Ａ設定情報サーバ
１１１…部門Ａ−１設定情報サーバ
１２…部門Ｂ設定情報サーバ
２…ユーザＰＣ
６…イントラネット
２２１，２４１，１２１，１４１…ネットワーク通信装置
２２４，２４４…アプリケーションプログラム
２２７…ＳＬＰ・ＬＤＡＰプロトコル変換装置
２２８…ＡＣＡＰ・ＬＤＡＰプロトコル変換装置
２４２…自動設定装置
２４２１…設定取得制御装置
２４２２…取得設定情報データベース
２４２３…設定情報反映装置
１２２，２４２４…ＬＤＡＰクライアント装置
２４２７…ＳＬＰクライアント装置
２４２８…ＡＣＡＰクライアント装置
１２３，１４３…ディレクトリ検索装置
１２４，１４４…ディレクトリ装置
１２５…連鎖制御装置
１２６，１４６…ＬＤＡＰサーバ装置
１２７，１４７…ＳＬＰサーバプロトコル変換装置
１２８，１４８…ＡＣＡＰサーバプロトコル変換装置
【発明の属する技術分野】
本発明は、ネットワークに接続された利用者計算機が必要とする、ネットワーク、および実行アプリケーションプログラムの設定情報の自動化を可能とする設定情報サーバ装置、利用者計算機及び設定情報配送方法に関する。
【０００２】
【従来の技術】
計算機システムの小型化、低価格化やネットワーク環境の充実に伴って、計算機システムの利用は急速にかつ種々の分野に広く拡大し、また集中型システムから分散型システムへの移行が進んでいる。特に近年では計算機システム自体の進歩、能力向上に加え、コンピュータ・ネットワーク技術の発達・普及により、オフィス内のファイルやプリンタなどの資源共有のみならず、オフィス外、１組織外とのコミニュケーション（電子メール、電子ニュース、ファイルの転送など）が可能になり、これらが広く利用されはじめた。特に近年では、世界最大のコンピュータネットワーク「インターネット（Ｉｎｔｅｒｎｅｔ）」の利用が普及しており、インターネットと接続し、公開された情報、サービスを利用したり、逆にインターネットを通してアクセスしてくる外部ユーザに対し、情報、サービスを提供することで、新たなコンピュータビジネスが開拓されている。またインターネット利用に関して、新たな技術開発、展開がなされている。
【０００３】
このようなコンピュータネットワークの普及に伴い、様々な業種においてネットワークサービスを活用した計算機（ＰＣ）の利用が行われている。これらネットワークサービスを利用したり実現するアプリケーションは、各々のネットワークで固有の環境情報を基にした設定を必要とする。一方、ＰＣの小型化と軽量化に伴い、自分の端末を持ち歩き、移動先（外出先）でそのＰＣを利用するという使い方が広まってきている。
【０００４】
一方、電話には電話帳、郵便には郵便番号表、各々の会社には社員名簿や内線電話帳というように、現実社会にはいろいろな形態の特定の情報を集めたデータベースが存在する。これらの情報は画一的に集中管理できるものとは限らない。例えば、郵便番号は郵政省のような郵便番号を決定できる機関によって一元的に管理されるべきであったり、電話番号は各地方の電話局によって分散管理されるべきであったりする。このような管理単位がまちまちな対象に関しての情報の管理を統合し統一手順で情報取得できるようにしたデータベースをディレクトリと呼び、ＩＴＵ−Ｔ（ｔｈｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｔａｎｄａｒｄｉｓａｔｉｏｎ ｓｅｃｔｏｒ ｏｆ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）でＸ．５００規格として標準化されている。また、インターネットプロトコルでの使用を前提としたディレクトリをアクセスするためのプロトコルとしてＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）がＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準化されている。ディレクトリは幅広い情報の配送サービスシステムとして活用されることが可能である。同様のネットワーク上で各種情報の自動取得に用いられるプロトコルとして、ＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＡＣＡＰ（Ａｐｐｌｉｃａｔｉｏｎ ＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）も同様にＩＥＴＦで標準化が行われている。アプリケーションの設定情報の自動取得と設定において、情報配送機能については、これらのプロトコルいずれを使用しても実現が可能である。
【０００５】
【発明が解決しようとする課題】
上記のように近年、計算機は小型化、軽量化による普及により、様々な業種のオフィスで使用されるようになった。これに伴い、計算機に精通していないユーザの増加が進んでいる。しかし、既存のアプリケーションプログラムの設定には、ある水準の知識や経験が必要であり、アプリケーションプログラムを正しく動作させることができない原因の１つとなり得る。
【０００６】
特に、計算機を持ち歩いて移動先でネットワークサービスを使用するためには、移動先ネットワークに見合った設定をアプリケーション対応に行なう必要があり、設定作業は容易なものとは限らず、必要以上の時間を浪費したり、設定の不備のためにネットワークサービスを受けられない場合があり得る。
【０００７】
また、ネットワーク対応の設定情報は、当該ネットワークの管理者に問い合わせなければ取得できない場合も多く、利用者の設定のたびに管理者へ負担がかかる場合もある。以上のように、ネットワークサービスを利用するアプリケーションを始めとする種々のアプリケーションの設定には、利用者と管理者の工数が必要であるため、設定の自動化が望まれている。
【０００８】
そこで、前述のディレクトリによる情報配送サービスを応用して、アプリケーションプログラムの設定情報の配送にディレクトリを用い、ユーザの設定作業を自動化することが考えられる。この場合、例えば、移動先のネットワークにＬＤＡＰサーバを設置して、利用者計算機から、必要な設定情報をＬＤＡＰに基づいて問い合わせを行い、応答情報を必要なアプリケーションに設定する、という処理を行う。
【０００９】
しかしながら、１台のＬＤＡＰサーバで、いかなる規模の移動先ネットワークをも対象として処理を行うのは、事実上困難である。例えば、実際の運用を考えると、運用組織同様に階層的なネットワーク構造になっており、全体で共通の設定情報を与える部分と各部署ネットワークで独自の設定を行う部分が存在するのが普通である。つまり、従来、ディレクトリに基づく情報配送を行う場合、階層的なネットワーク構造を考慮して情報配送サーバ側が柔軟に連携して必要な情報の提供を行ったり、利用者計算機の側で与えられた情報を自身の位置を考慮して適切に利用することができず、アプリケーションプログラムへの情報設定などにおいて不都合を生じていた。
【００１０】
本発明は、上記事情を考慮してなされたものであり、ネットワーク（インターネットやイントラネット）上を移動する利用者計算機が移動先でプログラムを動作する際に、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバからも設定情報取得が可能で、この結果をもとに自分の現在位置を考慮して適切なアプリケーションプログラムへの設定情報の自動設定を可能とする設定情報サーバ装置、利用者計算機及び設定情報配送方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明（請求項１）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持するための第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、前記第２の保持手段にリンク情報が保持されている設定情報サーバ装置と通信する通信手段と、受信した第１の設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果、および該検索範囲指定を適切な値に修正した第２の設定情報検索要求を自装置と連鎖する他の設定情報サーバ装置へ前記通信手段を介して送信しその返答として該他の設定情報サーバ装置から得た検索結果の少なくとも一方を含む設定情報検索結果を、該第１の設定情報検索要求の要求元装置に配送するための制御を行う制御手段とを備えたことを特徴とする。
【００１２】
本発明（請求項２）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持する第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、下位の設定情報サーバ装置から検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）が無指定の状態に設定された設定情報検索要求を受信した場合、前記第２の保持手段を参照し、自装置が最上位の設定情報サーバ装置でないならば、自装置の上位の設定情報サーバ装置に検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）が無指定の状態に設定された設定情報検索要求を送信して該上位の設定情報サーバ装置から得た設定情報を、元の要求元へ配送し、自装置が最上位の設定情報サーバ装置であるならば、下位の設定情報サーバ装置に検索範囲指定を該下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第１の制御手段と、上位の設定情報サーバ装置から検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に自装置とあらかじめ関連付けられている検索範囲指定の値が設定された設定情報検索要求を受信した場合、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきと判断されれば、該自装置の下位の設定情報サーバ装置に検索範囲指定を更に該自装置の下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該自装置の下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送し、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきでないと判断されれば、前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第２の制御手段とを備えたことを特徴とする。
【００１３】
本発明（請求項３）は、利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持するための第１の保持手段と、自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、利用者計算機と通信する通信手段と、利用者計算機から受信した設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果と、前記第２の保持手段を利用して得られる自装置と連鎖する他の設定情報サーバ装置および該他の設定情報サーバ装置に設定情報検索要求を出す際に検索範囲指定に設定すべき適切な検索開始点を示す通知情報との少なくとも一方を、該利用者計算機に配送するための制御を行う制御手段とを備えたことを特徴とする。
【００１４】
好ましくは、前記第１の保持手段に保持されている設定情報の影響範囲は、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述されているようにしてもよい。
【００１５】
好ましくは、受信した前記設定情報検索要求に含まれる、ネットワーク中における場所を示す情報と、前記第１の保持手段に保持されている前記設定情報の影響範囲とを比較することによって、前記第１の保持手段から該当する設定情報を検索するようにしてもよい。
【００１６】
好ましくは、設定情報サーバ装置内部（例えば、設定情報サーバ間の通信、自装置内の設定情報の検索等）で使用する標準プロトコル（例えば、ＬＤＡＰ）とは異なるプロトコル（例えば、ＡＣＡＰ、ＡＣＡＰ）によって、前記利用者計算機に対する設定情報検索配送サービスを提供するためのプロトコル変換を行うプロトコル変換手段を更に備えるようにしてもよい。
【００１７】
好ましくは、前記プロトコル変換手段は、サービス・ロケーション・プロトコル（ＳＬＰ：Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、サービス情報配送要求メッセージ、サービス情報配送メッセージ、サービス情報登録メッセージの各々と、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むようにしてもよい。
【００１８】
好ましくは、前記プロトコル変換手段は、アプリケーション・コンフィグレーション・アクセス・プロトコル（ＡＣＡＰ：Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続コマンド、サービス情報配送要求コマンド、サービス情報配送コマンド、サービス情報登録コマンドの各々と、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）の接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むようにしてもよい。
【００１９】
好ましくは、前記設定情報の内容を記述する属性の値として、該設定情報の内容の実際の記憶箇所を示す情報（例えば、他のディレクトリエントリやｆｔｐサイトをＵＲＬで指定し、そこに設定情報本体を置く）を記述するようにしてもよい。
【００２１】
本発明（請求項１０）は、プログラムの設定情報の検索要求に使用すべき標準プロトコル（例えば、ＬＤＡＰ）が特定のものに定められている設定情報サーバ装置から、自装置上で動作中のプログラムの要求する設定情報を取得する利用者計算機であって、自装置上で動作中のプログラムの出力する、設定情報を取得するための設定情報検索要求であって、前記標準プロトコルとは異なるプロトコル（例えば、ＳＬＰ、ＡＣＡＰ）による設定情報検索要求を、該標準プロトコルによる設定情報検索要求に変換する手段と、前記標準プロトコルによる設定情報検索要求をネットワークを介して送信し、これに対する応答として配送された、該標準プロトコルによる応答メッセージを、前記プログラムが使用する前記プロトコルによる応答メッセージに変換して、該動作中のプログラムに渡す手段とを備えたことを特徴とする。
【００２２】
好ましくは、前記設定情報サーバ装置からの前記設定情報検索要求に対する応答メッセージに、他の設定情報サーバ装置を紹介する情報が含まれている場合には、該他の設定情報サーバ装置にも設定情報検索要求を送信させる手段を更に備えるようにしてもよい。
【００２３】
好ましくは、前記設定情報検索要求の検索範囲指定に設定すべき適切な値が分からない場合には、該検索範囲指定を無指定（ＢａｓｅＯｂｊｅｃｔ）の状態に設定するようにしてもよい。
【００２４】
好ましくは、前記設定情報検索要求には、その送信時に自装置が属する場所情報を付加するようにしてもよい。
【００２５】
好ましくは、配送された設定情報のうちに、同一の設定項目に対して内容の相違する複数の設定情報が存在する場合に、前記設定情報とともに配送された、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述された該設定情報の影響範囲を示す情報に基づいて（例えば、決定的な表記部分から設定情報の優先度を判定することで）、採用すべき設定情報を選択する手段を更に備えるようにしてもよい。
【００２６】
本発明（請求項１５）は、プログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置の設定情報配送方法であって、受信した第１の設定情報検索要求の検索範囲指定（ＢａｓｅＯｂｊｅｃｔ）に応じて、自装置が管理対象とするネットワークドメインを影響範囲（スコープ）とする設定情報を保持する第１の保持手段を検索する手順、および自装置と連鎖する、自装置の上位または下位のサブドメインを管理対象としている他の設定情報サーバ装置へ、該第１の設定情報検索要求の検索範囲指定を適切な値に修正した第２の設定情報検索要求を送信する手順のうちの少なくとも一方の手順を実行し、前記検索により得られる設定情報および前記第２の設定情報検索要求に対する返答として前記他の設定情報サーバ装置から得られる設定情報のうち、前記手順を実行して得られたものを、前記第１の設定情報検索要求の要求元装置に配送することを特徴とする。
【００２７】
本発明（請求項１６）は、プログラムの設定情報を保持する設定情報サーバ装置に利用者計算機が設定情報検索要求を送信し、これに応じて該設定情報サーバ装置が該利用者計算機に該当する設定情報を配送する設定情報配送方法であって、利用者計算機は、自装置が属する場所情報を含む設定情報検索要求を設定情報サーバ装置に送信し、前記設定情報検索要求を受信した設定情報サーバ装置は、自装置内に記憶された設定情報のうち、該設定情報に対応して記憶されている、任意の値を示す記号を含む表記（例えば、ワイルドカードまたは正規表現といった表記）を用いて記述された影響範囲（スコープ）と、該設定情報検索要求に含まれる場所情報とを比較し、該場所情報に合致する影響範囲を持つ設定情報を検索結果として抽出し、前記設定情報サーバ装置は、前記設定情報検索要求を送信した前記利用者計算機に、前記検索により得られた前記設定情報を配送することを特徴とする。
【００２８】
本発明によれば、各ネットワークドメインに配置された上位／下位の情報設定サーバ装置が、連鎖機能により連携することで、例えば利用者計算機が移動先でプログラムを動作する際に、利用者計算機は自装置が接続したネットワークドメインの情報設定サーバ装置に検索要求を出すだけで、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行うことができる。また、この結果をもとに、自装置の現在位置を考慮した適切なアプリケーションプログラムへの設定情報の自動設定が可能になる。
【００２９】
あるいは、各設定情報サーバ装置が、連携動作する代わりに、関連する設定情報サーバ装置を利用者計算機に紹介するようにしても、移動計算機が紹介された各設定情報サーバ装置に検索要求を出すことにより、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行うことができる。
【００３０】
また、設定情報サーバ装置への設定情報の登録において、該設定情報とともに、該設定情報の影響範囲（該設定情報が適用される範囲）を非決定的な表記により記述して併せて登録する。この影響範囲と、利用者計算機の現在位置を示す情報により、効果的な検索もしくは配送すべき設定情報の絞り込みが可能となる。
【００３１】
さらに、プロトコル変換機能を適宜、適所に設けることにより、例えば、設定情報サーバ装置間の問い合わせに使用するプロトコルと、設定情報サーバと利用者計算機との間で使用するプロトコルが異なっても、対応することができる。
【００３２】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００３３】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００３４】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３５】
（通信システムの基本構成例）
図１に、本発明の実施の形態に係わる通信システムの基本構成の一例を示す。
【００３６】
図１の通信システムは、イントラネットを構築しており、当該イントラネットに部門毎のネットワークと、全社を管理するネットワークが接続されている様子を示している。図１の例では、全社設定情報サーバ（図中、１）が接続されているネットワーク＃１と部門Ａ設定情報サーバ（図中、１１）が接続されているネットワーク＃２、部門Ａ−１設定情報サーバ（図中、１１１）が接続されているネットワーク＃３、部門Ｂ設定情報サーバ（図中、１２）が接続されているネットワーク＃４は、全社イントラネット（図中、６）で接続されており、相互に通信可能状態にある場合を想定している（各々の設定情報サーバ（１，１１，１１１）の構成は基本的には同様である）。また、利用者計算機（以下、ユーザＰＣ）２は、部門Ａ−１ネットに接続され（以下、部門Ａ−１ネットに接続されたユーザＰＣ２をユーザＰＣ（Ａ−１−ａ）と記述する）、そのユーザＰＣ（Ａ−１−ａ）上では、様々なアプリケーションプログラムが実行される場合を想定する。なお、図１の通信システムには別のサーバ装置やＰＣが接続されていてもよいし、該通信システムが外部のインターネット等と接続可能であってもよい。
【００３７】
一般的に、アプリケーションプログラムを使用するためには、様々なユーザ依存、ネットワーク依存、あるいは使用環境依存な設定が必要である。なお、ここでは、「アプリケーションプログラム」は、純然たるアプリケーションプログラムの他に、アプリケーションプログラムとしての性質、機能もしくは側面を有するソフトウェア全般を含むものとする。従って、「アプリケーションプログラムの設定情報」は、いわゆるブラウザ・ソフトやワープロ・ソフト等の設定情報の他に、上記のようなソフトウェアのアプリケーションプログラムとしての性質、機能もしくは側面を持つ部分に関する設定情報を含むものとする。
【００３８】
本実施形態では、所定の「アプリケーションプログラムの設定情報（以下、設定情報と略す）」に関して、部門Ａで共通な設定情報を「部門Ａ設定情報サーバ」に、部門Ａ−１で共通な設定情報を「部門Ａ−１設定情報サーバ」に、部門Ｂで共通な設定情報を「部門Ｂ設定情報サーバ」に、全社で共通な設定情報を「全社設定情報サーバ」に分散して記憶・管理させるものとする。ここで、共通な設定情報とは、環境依存である設定情報や、ネットワーク依存の設定情報、計算機の管理者が推奨する設定情報などを含む。
【００３９】
ユーザＰＣ２は、「ＰＣの起動時」、「ＰＣの移動時」、「ユーザが使用するアプリケーションプログラムの起動時」、「ユーザが指定した契機」、「自動設定のためのアプリケーションプログラムによる定期的や不定期な契機」といった様々な契機（どの契機によるかはＯＳやアプリケーションプログラム等によって異なりうる）で、設定情報サーバへ設定情報検索要求を送信する。
【００４０】
ユーザＰＣ２から設定情報検索要求を受けた設定情報サーバ（例えば、部門Ａ−１設定情報サーバ１１１）は、該設定情報検索要求の内容に基づいて、検索処理等の所定の処理を行って（詳しくは後述するように必要に応じて他の設定情報サーバと連携をとって）、ユーザＰＣ２に検索された設定情報を返答する。また、別の方法としては、設定情報サーバは、他の設定情報サーバと連携をとる代わりに、ユーザＰＣ２に、該他の設定情報サーバを紹介する方法も考えられる。
【００４１】
以下では、ユーザＰＣの構成、設定情報サーバの構成、設定情報の分散記憶・管理形態や設定情報の検索、ユーザＰＣおよび設定情報サーバの全体シーケンス、プロトコル変換装置等について、順次説明していく。
【００４２】
なお、本実施形態では、ユーザＰＣと設定情報サーバとの間の手続き、設定情報サーバの相互間での手続きに、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を標準として用いる場合を代表例として説明する。
【００４３】
（ユーザＰＣの構成例）
以下、ユーザＰＣの構成例について説明する。
【００４４】
最初に、ユーザの使用するアプリケーションプログラム自身が設定情報の自動取得に対応している場合のユーザＰＣ２の構成について説明する。
【００４５】
図２に、この場合のユーザＰＣ２の構成例を示す。図２に示されるように、ユーザＰＣ２は、ネットワーク通信装置２２１、ＳＬＰ・ＬＤＡＰプロトコル変換装置２２７やＡＣＡＰ・ＬＤＡＰプロトコル変換装置２２８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００４６】
図２では、アプリケーションプログラム（２２４）が設定情報を自動取得するためのメッセージの送出経路を示している。
【００４７】
まず、当該アプリケーションプログラムが、ＬＤＡＰを用いて設定情報を取得する機能やＳＬＰ（ＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ），ＡＣＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）といった設定情報の自動取得に用いられるプロトコルに対応していて、ネットワーク上に置かれた設定情報サーバが各々のプロトコルに対応している場合、（クライアント要求経路１）により、ネットワークに向けて設定情報検索要求を送出する。
【００４８】
設定情報サーバの発見には、ＤＨＣＰの拡張部分を用いたサーバ情報の配布を用いることや、ブロードキャストやマルチキャストによるサーバ発見技術、属しているドメインに特定の文字列を付加したホスト名による特定など、様々な方法がある。なお、ＬＤＡＰにおける設定情報検索要求に関しては後述する。また、その他のプロトコルの要求メッセージは、それぞれのプロトコル仕様に従ったメッセージとする。
【００４９】
次に、アプリケーションプログラムがＳＬＰ，ＡＣＡＰをはじめとする自動設定に関して使用できるプロトコルに対応しているが、ネットワーク上に置かれた設定情報サーバがＬＤＡＰのみに対応している場合、各々のプロトコルに応じた（クライアント要求経路２）、（クライアント要求経路３）、…により、設定情報検索要求を送出する。送出された設定情報検索要求は、各々のプロトコルからＬＤＡＰへ変換されるべく、該当するプロトコル変換装置（２２７，２２８）を経由してＬＤＡＰの設定情報検索要求としてネットワークに送出される。なお、クライアントにおけるプロトコル変換の詳細については後述する。
【００５０】
その後、設定情報サーバから配送された設定情報は、それぞれの設定情報検索要求が通った経路を遡り、当該アプリケーションプログラムへ配送される。
【００５１】
なお、図２のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、図１の設定情報サーバが対応可能なプロトコル（本実施形の場合、少なくともＬＤＡＰプロトコル）に対応しているアプリケーションプログラムのみ、本設定情報検索サービスを受けられることになる。
【００５２】
続いて、当該アプリケーションプログラムが設定情報の自動取得に対応していないために自動設定装置を用いた場合のユーザＰＣ２の構成について説明する。
【００５３】
図３に、この場合のユーザＰＣ２の構成例を示す。図３に示されるように、ユーザＰＣ２は、ネットワーク通信装置２４１、自動設定装置２４２を備えており、自動設定装置２４２は、設定取得制御装置２４２１、取得設定情報データベース２４２２、設定情報反映装置２４２３、ＬＤＡＰクライアント装置２４２４、ＳＬＰクライアント装置２４２７やＡＣＡＰクライアント装置２４２８などのＬＤＡＰプロトコル以外のプロトコルによるクライアント装置を備えている。
【００５４】
前述した契機によって設定情報の自動取得が行なわれる場合、自動設定装置２４２は、まず、どのアプリケーションプログラム（２４４）に対して何の設定を何のプロトコルを用いて自動化するのかを必要に応じてユーザに指定され、次に、設定取得制御装置２４２１は、ネットワーク上に設置されている設定情報サーバが提供しているプロトコルに応じて、ＬＤＡＰクライアント装置２４２４、ＳＬＰクライアント装置２４２７あるいはＡＣＡＰクライアント装置２４２８などを動作させて、（クライアント要求経路１）、（クライアント要求経路２）、…などを通じて、ネットワーク上に設定情報検索要求を送出する。
【００５５】
設定情報サーバの発見に関しては、上記のユーザの使用するアプリケーションプログラム自身が設定情報の自動取得に対応している場合と同様である。また、ＬＤＡＰにおける設定情報検索要求に関しては後述する。その他のプロトコルの要求メッセージは、それぞれのプロトコル仕様に従ったメッセージとする。
【００５６】
その後、設定情報サーバから配送された設定情報は、それぞれの設定情報検索要求が通った経路を遡り、取得設定情報データベース２４２２へ配送される。そして、取得設定情報データベース２４２２から設定情報反映装置２４２３に対して、当該アプリケーションへ設定情報の反映の指示が送られ、必要な設定ファイルやレジストリの項目の変更を行なう。また、必要ならば、当該アプリケーションプログラムの再起動やシグナリング、ユーザＰＣの再起動を行なう場合もある。
【００５７】
なお、図３のクライアント装置は一例であり、クライアント装置としては最低限、図１の設定情報サーバが対応可能なプロトコルのうちの一つに対応するもの（本実施形態の場合、ＬＤＡＰクライアント装置）を構えればよい。
【００５８】
（設定情報サーバの構成例）
次に、ＬＤＡＰ，ＳＬＰ，ＡＣＡＰをはじめとする、設定情報の自動配送に使用されるプロトコルに対応した設定情報サーバ（１，１１，１１１）の構成例について説明する。
【００５９】
最初に、分散ディレクトリをＬＤＡＰのみで実現した場合の設定情報サーバの構成について説明する。
【００６０】
図４に、この場合の設定情報サーバの構成例を示す。図４に示されるように、設定情報サーバは、ネットワーク通信装置１２１、ＬＤＡＰクライアント装置１２２、ディレクトリ検索装置１２３、ディレクトリ装置１２４、連鎖制御装置１２５、ＬＤＡＰサーバ装置１２６、ＳＬＰサーバプロトコル変換装置１２７やＡＣＡＰサーバプロトコル変換装置１２８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００６１】
ネットワークによって送信されてきた設定情報検索要求は、ＬＤＡＰ，ＳＬＰ，ＡＣＡＰ，その他の設定情報の自動配送に用いられるプロトコルの種別に従った、ＬＤＡＰサーバ装置１２６、ＳＬＰサーバプロトコル変換装置１２７、ＡＣＡＰサーバプロトコル変換装置１２８、その他の設定情報の自動配送に用いられるプロトコルのサーバのプロトコル変換装置（図示せず）に渡される。サーバにおけるプロトコル変換の詳細については後述する。
【００６２】
そして、設定情報検索要求の内容に従い、ディレクトリ検索装置１２３によってディレクトリ装置１２４内の情報検索を行なう。ディレクトリ装置１２４の検索では、後述する設定情報検索要求内に含まれた、ユーザＰＣの現在の位置情報から、有効である設定情報の検索を行なう。なお、位置情報やそれにともなう設定情報の検索方法については後述する。また、ディレクトリ内の設定情報の格納方法についても後述する。
【００６３】
検索の結果、関連情報が他の設定情報サーバに存在する旨の情報（後述するサーバリンク情報）が得られた場合、当該サーバリンク情報に従って、連鎖制御装置１２５で適切な設定情報検索要求に変換し、ＬＤＡＰクライアント装置１２２を経て、リンク先設定情報サーバに設定情報検索要求を送出し、関連設定情報を受け取る。
【００６４】
リンク先設定情報サーバは、必要に応じて、同様な連鎖動作を行なう。なお、連鎖動作の詳細な手順については後述する。
【００６５】
なお、図４のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）による手続きの可能なユーザＰＣのみを設定情報検索サービスの対象とすることになる。
【００６６】
続いて、既存の分散ディレクトリ実現手段を用いた場合の設定情報サーバの構成について説明する。
【００６７】
図５に、この場合の設定情報サーバの構成例を示す。図５に示されるように、設定情報サーバは、ネットワーク通信装置１４１、ディレクトリ検索装置１４３、ディレクトリ装置１４４、ＬＤＡＰサーバ装置１４６、ＳＬＰサーバ装置１４７やＡＣＡＰサーバ装置１４８などのＬＤＡＰプロトコル以外のプロトコルとＬＤＡＰプロトコルとの間のプロトコル変換装置を備えている。
【００６８】
上記の分散ディレクトリをＬＤＡＰのみで実現した場合と同様の手順でディレクトリ装置１４４の検索まで行なう。また、同様にディレクトリ装置１４４の検索では、後述する設定情報検索要求内に含まれた、ユーザＰＣの現在の位置情報から、有効である設定情報の検索を行なう。その検索によって、他の設定情報サーバの管理下にある設定情報を必要とする場合、ディレクトリサーバ（設定情報サーバ）間でディレクトリエントリ情報の相互交換を行なうＤＳＰ（Ｄｉｒｅｃｔｏｒｙ Ｓｙｓｔｅｍ Ｐｒｏｔｏｃｏｌ）、または、分散データベースを実現するプロトコルを用いて、自設定情報サーバに必要情報を取得して、検索処理を完了する。
【００６９】
なお、図５のプロトコル変換装置は一例であり、プロトコル変換装置としてどのような標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）以外のプロトコルに対応するものを何種類備えても構わないし、プロトコル変換装置を備えなくても構わない。ただし、プロトコル変換装置を備えない場合には、標準プロトコル（本実施形態の場合、ＬＤＡＰプロトコル）による手続きの可能なユーザＰＣのみを設定情報検索サービスの対象とすることになる。
【００７０】
次に、図４の設定情報サーバの連鎖制御装置について説明する。
【００７１】
連鎖制御装置１２５は、ユーザＰＣから受け取った設定情報検索要求の検索開始点の指定である「ｂａｓｅＯｂｊｅｃｔ」を吟味する。
【００７２】
そこで、自ディレクトリ装置１２４の管理しているディレクトリ情報木の上位（木構造で管理されているディレクトリエントリの根に近い部分であることを上位と呼ぶ）に検索の必要がある場合には、自設定情報サーバが受信した設定情報検索要求のｂａｓｅＯｂｊｅｃｔの指定をそのままに、自設定情報サーバから上位設定情報サーバへの問い合わせを行なう。
【００７３】
また、自設定情報サーバの管理しているディレクトリ情報木の下位（上位に対して、葉に近い方を下位と呼ぶ）である場合は、自ディレクトリ装置１２４内を検索する。この検索により、自ディレクトリ装置１２４の管理しているディレクトリ情報木の下位の設定情報サーバへの関連情報を発見した場合は、関連情報に記述されている、当該設定情報サーバが管理しているディレクトリ情報木内を指すｂａｓｅＯｂｊｅｃｔを指定して、問い合わせを行なう。
【００７４】
これらの他の設定情報サーバへの問い合わせの結果として得られた設定情報は、自設定情報サーバの検索結果と併せて、ユーザＰＣに送り返す。
【００７５】
なお、上記では述べていないが、必要に応じて設定情報サーバからの設定情報検索要求によって、更に連鎖を行なう場合もある。このように、クライアント−サーバの関係による単純な連鎖を繰り返すことは、複雑な分散ディレクトリや分散データベースの実現を必要としないため、実装が容易になる。
【００７６】
（設定情報をディレクトリデータベースに格納する方法、ＬＤＡＰによる設定情報検索要求の記述方法等）
次に、設定情報をディレクトリデータベースに格納する方法と、ＬＤＡＰによる設定情報検索要求の記述方法について説明する。
【００７７】
設定情報の格納方法は、ディレクトリエントリの識別名や属性名で設定情報の種別を表し、各々の値で設定値を記述する。識別名で設定情報の種別を表す場合の例を図６に示し、属性名で設定情報の種別を表す場合の例を図７に示す。
【００７８】
例えば、図６（ａ）や図７（ｂ）では、設定情報の種別は“ＨＴＴＰｐｒｏｘｙ“であり、そのホスト名は“ｐｒｏｘｙ．ｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐ”であり、そのポート番号は“１０８０”であることが記述されている。
【００７９】
なお、図６（ｂ）のディレクトリエントリ例の属性ｄｅｆａｕｌｔＣｏｎｆのように、実際の設定情報そのものを別ディレクトリエントリにしてＵＲＬなどによって、実際の設定情報の所在（設定情報リンク）を示すことにより、設定情報の集約を図ることが可能である。設定情報リンクにより、ディレクトリ情報木の構成に依存した共通設定情報の管理だけでなく、ディレクトリ情報木の構造とは独立した共通設定情報の実現が可能となる。また、設定情報の変更や更新は、設定情報リンク先の集約されている情報の変更、および、更新で完了するため、変更に要する工数を抑えることができる上、変更完了までの時間の短縮を図ることができる。
【００８０】
また、図７では、複数の設定情報を記述可能である。
【００８１】
ところで、当該ディレクトリエントリが、設定情報を属性として保持していることを示すために、次の２つの手法のどちらかが必要となる。一方は、ディレクトリエントリのクラスを表すｏｂｊｅｃｔＣｌａｓｓ属性の値として設定情報クラスに属する値（例えば、“ｃｏｎｆｉｇｕｒｅ”）を付与する方法、一方は、ディレクトリエントリに設定情報のみが持ち得る属性（例えば、属性名“ｃｏｎｆｉｇｕｒａｔｉｏｎ”）を付与する方法である。ｏｂｊｅｃｔＣｌａｓｓを用いた例を図８に、ｃｏｎｆｉｇｕｒａｔｉｏｎ属性を用いた例を図９に示す。
【００８２】
いずれの手法にせよ、設定情報サーバ内の設定情報の格納方法をユーザＰＣが知らない場合でも、ｏｂｊｅｃｔＣｌａｓｓが“ｃｏｎｆｉｇｕｒｅ”であるものを取得する検索、または、属性として“ｃｏｎｆｉｇｕｒａｔｉｏｎ“を持っているエントリを取得する検索によって、設定情報の取得が可能となる。それぞれの場合の、設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の例を、図１０、図１１に示す。
【００８３】
また、設定情報の格納方法についての知識をユーザＰＣが持ち合わせている場合、設定情報検索要求で条件を指定することにより、特定の設定情報のみを取得することが可能である。この場合の設定情報検索要求の例を、図１２に示す。図１２では、識別名のＣＮ（ｃｏｍｍｏｎＮａｍｅ）に設定情報種別が指定されている場合に、“ＨＴＴＰｐｒｏｘｙ”の設定情報を取得するための設定情報検索要求を示している。
【００８４】
（スコープ）
次に、ディレクトリエントリが保持している設定情報の影響範囲もしくは適用範囲（例えば、ドメイン名）を規定する方式について説明する。
【００８５】
設定情報の影響範囲もしくは適用範囲（以下、スコープと呼ぶ）の記述のために、スコープ属性を付与する。ただし、記述には、ワイルドカードや正規表現を用いた、非決定的な記述方法を使用する。スコープの属性の例を、図１３（ａ），（ｂ）に示す。
【００８６】
スコープは、属性ｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅの値として保持され、ドメイン名のようなネットワーク識別子やｅｍａｉｌアドレスのようなユーザ識別子で表現される。ワイルドカード（図中の“＊”）や正規表現を用いることにより、一意のドメインや特定ドメインのユーザだけでなく、多彩なサブネットの指定や、複数ドメインを行き来するユーザに対して共通設定を配送することを実現できる。
【００８７】
また、このスコープは、複数の設定情報サーバで分散管理された、同一のサービスやアプリケーションプログラムに対する設定情報の、優先順位を表現することも可能である。例えば、ドメインｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｃｏ．ｊｐにおける設定情報として、ｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅ＝“＊．ｆｏｏ．ｈｏｇｅ．ｃｏ．ｊｐ”のディレクトリエントリとｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅ＝“＊．ｈｏｇｅ．ｃｏ．ｊｐ”のディレクトリエントリとがある場合は、全社のディレクトリエントリが、より適切な設定情報であることを判別できる。従って、例えば、非決定的な記述がなされたスコープと、ユーザＰＣ（例えば、Ａ−１−ａ）の決定的な記述による現在位置を示すドメイン名を比較した場合、決定的な部分同士の最長一致比較を行ない、優先順位を決定することが可能となる。また、例えば、スコープまでも同一の設定情報が複数ある場合は、更に、ディレクトリエントリの識別名を基に（ディレクトリ情報木の上位または下位を基準にするなどの方法で）、設定情報の優先順位を判断する場合もあり得る。
【００８８】
一方、設定情報検索要求に、現在の位置情報としてのドメイン名を指定したスコープを指示することにより、設定情報サーバ側の検索範囲の絞り込みが可能である。この場合の設定情報検索要求の例を図１４に示す。この設定情報検索要求を受け取った設定情報サーバは、自ディレクトリ装置内のディレクトリエントリの検索結果の取得や、分散による他自動設定サーバへの連鎖問い合わせやＤＳＰ、および、分散データベースプロトコルによる情報取得の際に、無駄な範囲の検索を排除することが出来る。
【００８９】
なお、ユーザＰＣは、設定情報検索要求に、複数のドメイン名（例えば、移動元のホームポジションとなる位置および移動後の現在の位置のドメイン名）を指定したスコープを指示できるようにしてもよい。
【００９０】
（サーバリンク情報）
次に、ディレクトリ情報木を協調しながら分散管理している設定情報サーバ間の関連情報であるサーバリンク情報を図１５（ａ），（ｂ）に示す。
【００９１】
図１５に示すように、サーバリンク情報も通常のディレクトリエントリとして保持される。ただし、そのエントリの属性であるｌｉｎｋＴｏは制御属性と呼ばれ、設定情報サーバの連鎖制御、および参照（紹介）制御に用いられるための属性である。ｌｉｎｋＴｏ属性の値として、ＵＲＬ表記を用いることができる。また、ｌｉｎｋＴｏ属性には該当するサーバのホスト名のみを記述し、その設定情報サーバが管理権限を持つ開始点の識別名を別の属性（図１５の例では、ｌｉｎｋＢａｓｅＯｂｊｅｃｔ）で示してもよい。
【００９２】
以下、ディレクトリ情報木を表記する場合、上位ネットワーク、または、下位ネットワークの関係で隣接する設定情報サーバ間は、図１５に示されているようなサーバリンク情報によって、お互いの関係を保持していることを前提とする。
【００９３】
また、各々の設定情報サーバは、自サーバが管理権限を持っているディレクトリ情報木の開始点の情報（識別名）を、設定情報サーバの管理者の設定により保持していることも前提とする。このため、上記のサーバリンク情報と管理権限の開始点の情報から、上記の上位設定情報サーバ、および、下位の設定情報サーバの判別が可能である。
【００９４】
（動作シーケンス例１）
次に、図１の環境における、ディレクトリ情報木の構成例を図１６に示す。
【００９５】
図１６は、ＨＴＴＰｐｒｏｘｙに関する設定情報は全社で共通のため、全社設定情報サーバによって管理され、部門Ａ−１にあるプリンタサーバについての設定情報は、部門Ａ−１設定情報サーバで管理される場合を仮定している。また、部門Ａ−１設定情報サーバは、自分の管理しているディレクトリ情報木の上位は部門Ａ設定情報サーバが管理していることを知っている。また、部門Ａ設定情報サーバは、全社設定情報サーバが上位を、部門Ａ−１設定情報サーバが下位を管理していることを知ってる。さらに、全社設定情報サーバは、部門Ａ設定情報サーバが下位を管理していること（下位へのリンクと呼ぶ）を知っているとする。
【００９６】
このとき、設定情報サーバが、分散ディレクトリの実装を行なわずに、連鎖制御装置によって管理されている状況の、部門Ａ−１のネットワーク（ｂｏｏ．ｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐサブネット）に接続されていたユーザＰＣ（Ａ−１−ａ）が設定情報を自動取得する場合の動作シーケンスを図１７に示す。
【００９７】
なお、図１７においては、各サーバの動作上、第１番目〜第５番目の要求と第５番目〜第１番目の配送とがそれぞれ対応してなされるものであり、従って、例えば、部門Ａ−１設定情報サーバにおいて、第１番目の配送（部門Ａ設定情報サーバへのｐｒｉｎｔｅｒＳｅｒｖｅｒ情報の配送）は、受信した第１番目の要求（ユーザＰＣ（Ａ−１−ａ）からのｂａｓｅＯｂｊｅｃｔが“”の要求）とは、独立して行われる。
【００９８】
また、この場合の設定情報サーバの構成例を図４に示す。
【００９９】
ユーザＰＣ（Ａ−１−ａ）は、ＤＨＣＰや手設定などによりネットワークの設定（ＩＰアドレス，ネームサーバ，経路制御）は完了しているものとする。まず、設定情報サーバについて、ドメイン名に特定の名前を付加したホスト名の使用、自動設定用マルチキャストアドレスの使用、ブロードキャストによる設定情報サーバの検索方法の使用、手設定による指示といった手法に代表されるサーバ探索の方式により、設定情報サーバ探索を完了する。
【０１００】
次に、ｂａｓｅＯｂｊｅｃｔを“”（ｎｕｌｌ）とした（ユーザＰＣは適切なｂａｓｅＯｂｊｅｃｔを知っているとは限らないため、ここでは無指定の要求を想定している）、図１８に例示するような設定情報検索要求（ＬＤＡＰ ｓｅａｒｃｈメッセージ）を設定情報サーバに送信する。
【０１０１】
設定情報検索要求を受信した部門Ａ−１設定情報サーバは、ｂａｓｅＯｂｊｅｃｔが指定されてないので、なるべく最上位の木から検索を開始するために、受け取った設定情報検索要求を基に、上位の設定情報サーバである部門Ａ設定情報サーバに連鎖問い合わせを行なう。
【０１０２】
部門Ａ設定情報サーバは、同様に、全社設定情報サーバに問い合わせを行なう。
【０１０３】
全社設定情報サーバでは、更に上位の設定情報の検索の必要性はない（そのように設定する、または上位サーバへの関連を記述しない）。そこで、ディレクトリ装置を検索し、“ＯＵ＝Ａ”以下に関しての情報は部門Ａ設定情報サーバが保持していることと、ＨＴＴＰｐｒｏｘｙの設定情報を知る。そこで、ｂａｓｅＯｂｊｅｃｔを“Ｏ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ“とした、当該設定情報検索要求（ＬＤＡＰ ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）を部門Ａ設定情報サーバに転送する。
【０１０４】
それを受信した部門Ａ設定情報サーバは、全社設定情報サーバと同様に動作し、“ＯＵ＝Ａ−１”以下に関しての情報は部門Ａ−１設定情報サーバが保持していることを知り、ｂａｓｅＯｂｊｅｃｔを“Ｏ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ， ＯＵ＝Ａ−１”として、当該設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）を部門Ａ−１設定情報サーバの転送する。
【０１０５】
それを受信した部門Ａ−１設定情報サーバは、自ディレクトリ装置の検索の結果、ｐｒｉｎｔｅｒ Ｓｅｒｖｅｒの設定情報を得る。そして、その検索結果（ｐｒｉｎｔｅｒＳｅｒｖｅｒ）を設定情報として、部門Ａ設定情報サーバに配送する。
【０１０６】
さらに、それを受信した部門Ａ設定情報サーバは、その配送された設定情報（ｐｒｉｎｔｅｒＳｅｒｖｅｒ）を、全社設定情報サーバに配送する。
【０１０７】
全社設定情報サーバは、自検索結果であるＨＴＴＰｐｒｏｘｙと、受信したｐｒｉｎｔｅｒＳｅｒｖｅｒとを設定情報として、部門Ａ設定情報サーバに配送する。
【０１０８】
ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報を受信した部門Ａ設定情報サーバは、部門Ａ−１設定情報サーバにそれらを配送する。
【０１０９】
最後に、部門Ａ−１設定情報サーバは、収集した設定情報（この場合、ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報）をユーザＰＣ（Ａ−１−ａ）に配送する。
【０１１０】
以上の手順を踏むことにより、分散した設定情報サーバ間の設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の無限ループを回避しつつ、関連するディレクトリの探索を行なうことが出来る。
【０１１１】
配送された設定情報を受信したユーザＰＣ（Ａ−１−ａ）は、設定情報に従って設定を反映する。
【０１１２】
なお、受信した設定情報に、ＨＴＴＰｐｒｏｘｙに関する設定情報が複数あるといった重複があるような場合には、例えば、スコープを示す属性を検査し、ワイルドカード（または、正規表現における任意の値にマッチする特殊記号）を除いた部分で最長マッチのような評価関数を用いることにより、設定情報を選択して該当しないものを除去し、重複を排除することが出来る。
【０１１３】
（動作シーケンス２）
次に、図１のネットワークで、図１６のディレクトリ情報木の構成において、すべての設定情報サーバが分散ディレクトリを実現するプロトコルであるＤＳＰや、分散データベースを実現するためのプロトコルを備えた場合の動作シーケンスを、図１９に示す。なお、実際には、これらのプロトコルでは、情報の一貫性、妥当性を保護するための複雑な機構が働き、設定情報サーバ間の手続は図１９に示すほど容易なものではなく多様なものであるが、図１９はこれを概念的に簡単化して表現したものである。
【０１１４】
なお、この場合の設定情報サーバの構成例を図５に示す。
【０１１５】
ユーザＰＣ（Ａ−１−ａ）は、ｂａｓｅＯｂｊｅｃｔを“”（ｎｕｌｌ）とした設定情報検索要求を部門Ａ−１設定情報サーバに送信する。
【０１１６】
ユーザＰＣ（Ａ−１−ａ）から設定情報検索要求を受け取った部門Ａ−１設定情報サーバは、分散されたディレクトリ情報木の全体を取得するために、ＤＳＰまたは分散データベースプロトコルで情報収集を行なう。
【０１１７】
最後に、部門Ａ−１設定情報サーバは、収集した設定情報（この場合、ＨＴＴＰｐｒｏｘｙとｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報）をユーザＰＣ（Ａ−１−ａ）に配送する。
【０１１８】
（動作シーケンス３）
次に、ＬＤＡＰの機能であるサーバの参照（ｒｅｆｅｒｒａｌ）の提示のみによる、クライアント自身の連鎖動作を適用した場合の本自動設定システムについて説明する。
【０１１９】
図１のネットワークで、図１６のディレクトリ情報木の構成における動作シーケンスを図２０に示す。
【０１２０】
なお、図２０においては、ユーザＰＣの手続が全体で一連の手続きとなる。また、各サーバでは、第１番目〜第５番目の要求の受信と第１番目〜第５番目の配送とがそれぞれ対応してさなれるものであり、従って、例えば、部門Ａ−１設定情報サーバにおける最初の要求受信／配送と、最後の要求受信／配送とは、独立して行われる。
【０１２１】
また、この場合の設定情報サーバの構成例は、図５において設定情報サーバ間通信の機能を持たず、連携すべき相手となる設定情報サーバを、ユーザＰＣに紹介するようにしたものである。
【０１２２】
ユーザＰＣ（Ａ−１−ａ）はｂａｓｅＯｂｊｅｃｔを指定しないで部門Ａ−１設定情報サーバに問い合わせる。部門Ａ−１サーバは、なるべく最上位の木から検索を開始するために、受け取った設定情報検索要求を基に、上位の設定情報サーバである部門Ａ設定情報サーバを紹介する。
【０１２３】
その紹介に従い、部門Ａ設定情報サーバに問い合わせると、同様に全社設定情報サーバの紹介を受ける。
【０１２４】
ユーザＰＣ（Ａ−１−ａ）は、全社設定情報サーバに同様に問い合わせると、ＨＴＴＰｐｒｏｘｙの設定情報と、ｂａｓｅＯｂｊｅｃｔをＯ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａとして問い合わせる旨の部門Ａ設定情報サーバの紹介を受ける。
【０１２５】
それに従い、部門Ａ設定情報サーバに問い合わせると、ｂａｓｅＯｂｊｅｃｔをＯ＝ｈｏｇｅ ｃｏｒｐ．， ＯＵ＝Ａ， ＯＵ＝Ａ−１として問い合わせる旨の部門Ａ−１設定情報サーバの紹介を受ける。
【０１２６】
さらにそれに従い、部門Ａ−１設定情報サーバに問い合わせると、ｐｒｉｎｔｅｒＳｅｒｖｅｒの設定情報を受け取って、自動設定情報の取得は完了する。
【０１２７】
このように、参照の提示による紹介に従ってユーザＰＣ（Ａ−１−ａ）が個々に問い合わせると、手順の増加とそれぞれの設定情報サーバでの認証情報の管理が必要となるが、分散された個々の情報に関するユーザ対応のきめ細かな権限の制御が可能である。
【０１２８】
（動作シーケンス４）
ここで、図１６のディレクトリ情報木の構成で、図２１に示すように、ユーザＰＣ（Ａ−ａ）がネットワーク２に接続された場合について説明する。
【０１２９】
この場合、ユーザＰＣ（Ａ−ａ）は、図２２の設定情報検索要求を送信する。
【０１３０】
図２３に、設定情報サーバが、連鎖制御装置で実装されている場合の動作シーケンスを示す。
【０１３１】
ユーザＰＣ（Ａ−ａ）は、部門Ａ設定情報サーバに設定情報検索要求を送り、連鎖して全社設定情報サーバに設定情報検索要求が届き、下位の検索として再び部門Ａ設定情報サーバに検索要求が渡される。ここで、源の検索要求は、ネットワーク２に接続されたユーザＰＣ（Ａ−ａ）によるものなので、スコープとしてｆｏｏ．ｈｏｇｅ．ｎｅ．ｊｐが指定されている。
【０１３２】
部門Ａ設定情報サーバは、部門Ａ−１設定情報サーバへの関連を知っているが、スコープ外であることから連鎖は行なわない。
【０１３３】
以下、要求を遡るように設定情報が配送されていく。
【０１３４】
すべての設定情報サーバが分散ディレクトリを実現するプロトコルであるＤＳＰや、分散データベースを実現するためのプロトコルを備えた場合においても、また、参照に対応したユーザＰＣ（Ａ−１−ａ）による連鎖制御においても同様である。
【０１３５】
（プロトコル変換装置）
次に、図２の構成例のユーザＰＣにおけるプロトコル変換装置の一例として、ＳＬＰ・ＬＤＡＰプロトコル変換装置について説明する。
【０１３６】
設定情報は、図６のようにサービス単位でのディレクトリエントリを作成し、識別名（属性）ＣＮにそのサービス種別を記述しているとする。
【０１３７】
本ＳＬＰ・ＬＤＡＰプロトコル装置は、ＳＬＰにのみ対応した（もしくはＬＤＡＰには対応していないがＳＬＰには対応している）アプリケーションプログラムがＳＬＰを用いて行なうネットワーク上のサービスに関する情報取得動作を終端し、ＬＤＡＰを用いた設定情報取得動作として変換し、設定情報を取得できるようにするためのものである。ただし、ＳＬＰに関する設定は、ユーザにより完了しておかなければならない。
【０１３８】
ＳＬＰによって設定情報を取得するアプリケーションプログラムは、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔメッセージを送出しＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージを受信することで、ネットワーク上に存在するすべてのサービスを知り、Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージを送出しＳｅｒｖｉｃｅ Ｒｅｐｌｙを受信することで、サービスを提供しているサーバの所在を知ることとする。そして、必要に応じてＡｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔメッセージの送信とＡｔｔｒｉｂｕｔｅ Ｒｅｐｌｙメッセージの受信により、当該サービスの属性を得ることとする。
【０１３９】
まず、ＳＬＰのＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔメッセージから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図２４（ａ），（ｂ）に示す。
【０１４０】
Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔの＜ＰＲＬｉｓｔ＞は、以前使用したＳＬＰサーバを指定するもので、設定情報検索要求の送出先（ＬＤＡＰとしての接続先）として使用することも出来るが、通常は上述の設定情報サーバの探索によって接続先を決定する。この指定がない場合や、この指定があってもｌｏｃａｌｈｏｓｔを指し示している場合も、上述の設定情報サーバの探索を行なう（むしろ、無意味に指定があるよりも、＜ＰＲＬｉｓｔ＞の指定がない場合やｌｏｃａｌｈｏｓｔ指定の方が好ましいと言える）。ＮａｍｉｎｇＡｕｔｈｏｒｉｔｙは、結果の範囲を指定する機能を持つ指定であるが、ＬＤＡＰには該当する機能が存在しないので無視する。＜ｓｃｏｐｅ−ｌｉｓｔ＞は、対象とするサービスをスコープとして指定できる。＜ｓｃｏｐｅ−ｌｉｓｔ＞がＤＥＦＡＵＬＴの場合は、ユーザＰＣ（例えば、Ａ−１−ａ）の接続されたネットワークのドメイン名をｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅとして指定したｆｉｌｔｅｒを記述する。＜ｓｃｏｐｅ−ｌｉｓｔ＞がＤＥＦＡＵＬＴ以外の値の場合は、その値をｃｏｎｆｉｇｕｒａｔｉｏｎＳｃｏｐｅとして指定したｆｉｌｔｅｒを記述する。また、ａｔｔｒｓとして、結果として欲しい属性値をＣＮに絞ることにより、サービス種別のみを得ることで無駄な通信を避けることが出来る。この要求により、設定情報サーバは、当該設定情報検索要求に従ったディレクトリエントリ（設定情報）のサービス種別（ＣＮ）の情報を返す。
【０１４１】
次に、この受け取ったサービス種別の情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔ）からＳＬＰのＳｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージへの変換の例を、図２５（ａ），（ｂ）に示す。
【０１４２】
受信したＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔには、検索結果として設定情報のサービス単位に存在するディレクトリエントリのサービス種別を示すＣＮ属性の値が入っている。従って、ＳＬＰ Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙメッセージの＜ｓｒｖｔｙｐｅ−ｌｉｓｔ＞に入れて、アプリケーションプログラムに返送する。
【０１４３】
次に、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔメッセージから設定情報検索要求への変換の例を、図２６（ａ），（ｂ）に示す。
【０１４４】
＜ＰＲＬｉｓｔ＞，＜ｓｃｏｐｅ−ｌｉｓｔ＞は、先の例と同様である。＜ｓｅｒｖｉｃｅ−ｔｙｐｅ＞の指定は、自動設定情報（ＬＤＡＰ）のＣＮの指定に相当する。ｐｒｅｄｉｃａｔｅ ｓｔｒｉｎｇは、ＳＬＰの仕様上、ＬＤＡＰのｆｉｌｔｅｒを記述することになっているので、該当するｆｉｌｔｅｒ条件を追加する。ＳＬＰ ＳＰＩは、ＳＬＰクライアント／サーバ間のセキュリティーパラメータインデックスなので、設定情報検索要求では無視する。この要求により、指定されたサービスに関する設定情報が受信できる。
【０１４５】
次に、この受信した設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）からＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージへの変換の例を、図２７（ａ），（ｂ）に示す。
【０１４６】
受信したメッセージに含まれるサービス種別情報（ＣＮ属性），ホスト名情報（ｈｏｓｔｎａｍｅ属性）とポート番号情報（ｐｏｒｔＮｕｍｂｅｒ属性）を、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージ中のＵＲＬに記述し、結果として返送する。受信した設定情報が、ネットワーク上のサービスに関係しない（ホスト名情報とポート番号情報を保持していない）場合は、ＳＬＰ Ｓｅｒｖｉｃｅ Ｒｅｐｌｙメッセージには変換せずに無視する。
【０１４７】
次に、ＳＬＰ Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図２８（ａ），（ｂ）に示す。
【０１４８】
＜ＰＲＬｉｓｔ＞，＜ｓｃｏｐｅ−ｌｉｓｔ＞，ＳＬＰ ＳＰＩは先の例と同様である。ＵＲＬは、記述内容からサービス種別，ホスト名，ポート番号の指定を読みとり、ＣＮ，ｈｏｓｔｎａｍｅ，ｐｏｒｔＮｕｍｂｅｒ属性への条件指定に変換する。＜ｔａｇ−ｌｉｓｔ＞は、結果として受け取りたい属性の指定なので、ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージのａｔｔｒｓとして列挙し、それらの結果を受け取れるようにする。＜ｔａｇ−ｌｉｓｔ＞が省略された場合はａｔｔｒｓも省略し、すべての属性を受け取るようにする。この要求により、指令されたサービスに関する属性を受信できる。
【０１４９】
次に、この受信した属性の情報である設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）からＳＬＰ Ａｔｔｒｉｂｕｔｅ Ｒｅｐｌｙへの変換の例を、図２９（ａ），（ｂ）に示す。
【０１５０】
受信したＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔの属性を、＜ａｔｔｒ−ｌｉｓｔ＞に列挙する。
【０１５１】
なお、ＳＬＰのサービス情報登録メッセージと、ＬＤＡＰの情報登録メッセージとの間の変換も同様に可能である。
【０１５２】
これまで述べたようにＳＬＰ・ＬＤＡＰプロトコル変換装置を用いることで、メッセージの変換を行なうことで、ＳＬＰにのみ対応したアプリケーションプログラムに対して、自動的に設定情報を与えることが出来る（ただし、ＳＬＰで用いられるセキュリティー機能とＬＤＡＰのセキュリティー機能を透過に機能させることは実現できていない）。これまでに述べていないＳＬＰメッセージや、個々のＳＬＰとＬＤＡＰのメッセージに含まれている様々な情報は変換の必要がないものであるが、アプリケーションプログラムとＳＬＰ・ＬＤＡＰ変換装置間や、ＳＬＰ・ＬＤＡＰ変換装置と設定情報サーバ間で、それぞれのＳＬＰ，ＬＤＡＰのプロトコル仕様に従った振舞を行なわなければならない。
【０１５３】
次に、図１のネットワークで、図１６のディレクトリ情報木の構成において、上記ＳＬＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスを、図３０に示す。
【０１５４】
図３０では、アプリケーションプログラムは、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ， Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ， Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔの順にＳＬＰメッセージを送信する。それぞれのＳＬＰメッセージは、ＳＬＰ・ＬＤＡＰプロトコル変換装置で受信され、ＬＤＡＰのメッセージに変換されて、部門Ａ−１設定情報サーバに送信される。部門Ａ−１設定情報サーバと関連する部門Ａ設定情報サーバ，全社設定情報サーバの動作は、以前に述べてきた連鎖動作などを同様に行なう。また、ＳＬＰ・ＬＤＡＰ変換装置がＬＤＡＰのメッセージとして受信した検索結果は、それぞれのＳＬＰ Ｒｅｐｌｙメッセージとしてアプリケーションプログラムに返送され、アプリケーションプログラムはその情報で自動設定を行なう。
【０１５５】
ところで、アプリケーションプログラムとＳＬＰ・ＬＤＡＰプロトコル変換装置間、および、ＳＬＰ・ＬＤＡＰプロトコル変換装置と自動設定サーバ間の認証に関しては、各々の間での認証に関する制御は独立に行なうことで対処する。つまり、アプリケーションプログラムがＳＬＰ・ＬＤＡＰプロトコル変換装置との間で交わす認証方式および認証情報は、ＳＬＰ・ＬＤＡＰプロトコル変換装置が自動設定サーバとの間で交わす認証方式および認証情報とは無関係にする。従って、設定情報サーバがユーザを認証して設定情報の操作を行なう場合には、ユーザはアプリケーションプログラムに関しての認証制御を事前設定するのではなく、ＳＬＰ・ＬＤＡＰプロトコル変換装置に関しての認証制御を事前設定する。また、自動設定サーバから得た設定情報を、今後に見込まれるＳＬＰによる問い合わせのために、ＳＬＰ・ＬＤＡＰプロトコル変換装置でキャッシュすることも可能である。
【０１５６】
次に、図２の構成例のユーザＰＣにおけるプロトコル変換装置の一例として、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置について述べる。
【０１５７】
設定情報は、図６のようにサービス単位でのディレクトリエントリを作成し、識別名（属性）ＣＮにそのサービス種別を記述しているとする。
【０１５８】
本ＡＣＡＰ・ＬＤＡＰプロトコル装置は、ＡＣＡＰにのみ対応した（もしくはＬＤＡＰには対応していないがＡＣＡＰには対応している）アプリケーションプログラムがＡＣＡＰを用いて行なう各種設定情報の取得動作を終端し、ＬＤＡＰを用いた設定情報取得動作として変換し、設定情報を取得できるようにするためのものである。ただし、ＡＣＡＰに関する設定は、ユーザにより完了しておかなければならない。
【０１５９】
ＡＣＡＰによって設定情報を取得するアプリケーションプログラムは、ＡＣＡＰサーバに接続するとＡＵＴＨＥＮＴＩＣＡＴＥコマンドによって認証を行ない、ＳＥＡＲＣＨコマンドによって設定情報の検索と取得を行なうことで、アプリケーションプログラムに必要な設定情報を取得する。
【０１６０】
まず、ＡＣＡＰの認証のパラメータとＬＤＡＰのＢｉｎｄ Ｒｅｑｕｅｓｔメッセージの変換の例を、図３１（ａ）〜（ｄ）に示す（ただし、図３１におけるＬＤＡＰのメッセージは、概念的なものを表現たものであり、実際に図３１のようなメッセージ構成になっていることを意味しているものではない）。
【０１６１】
ＡＣＡＰでは、接続後に認証を完了するためにＡＵＴＨＥＮＴＩＣＡＴＥコマンドと、その引数として認証手法の指定を送信する。ＡＣＡＰでは、認証方法にはＡＮＯＮＹＭＯＵＳを指定する。変換装置はＡＣＡＰ ＡＵＴＨＥＮＴＩＣＡＴＥコマンドをＬＤＡＰ ＢｉｎｄＲｅｑｕｅｓｔメッセージに変換して送信し、その返事として受け取るＬＤＡＰ ＢｉｎｄＲｅｐｌｙをＡＵＴＥＮＴＩＣＡＴＥコマンドに対するサーバの応答として返す。
【０１６２】
次に、ＡＣＡＰ ＳＥＡＲＣＨコマンドから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図３２（ａ），（ｂ）に示す。
【０１６３】
ＡＣＡＰのＳＥＡＲＣＨコマンドのＬＩＭＩＴ，ＭＡＫＥＣＯＮＴＥＸＴ，ＮＯＩＮＨＥＬＩＴ，ＳＯＲＴオプションは、ＬＤＡＰには該当する機能が存在しないため変換の対象ではない。ただし、その他のＨＡＲＤＬＩＭＩＴ，ＲＥＴＵＲＮは、それぞれＬＤＡＰにおけるｓｉｚｅｌｉｍｉｔ，ａｔｔｒｓの指定に相当する。ＨＡＲＤＬＩＭＩＴはｓｉｚｅｌｉｍｉｔにそのまま入れ、ＲＥＴＵＲＮは、内容として列挙されている属性名をａｔｔｒｓとして列挙することで変換が可能である。また、ＡＣＡＰ ＳＥＡＲＣＨコマンドの検索条件の論理式に使用する、ＡＬＬ， ＡＮＤ， ＣＯＭＰＡＲＥ， ＮＯＴ， ＯＲ， ＰＲＥＦＩＸ， ＲＡＮＧＥ， ＳＵＢＳＴＲＩＮＧは、それぞれ、ＬＤＡＰのＳｅａｒｃｈ Ｒｅｑｕｅｓｔのｆｉｌｔｅｒにおける、＆，−，！，＝，＝〜，＜，＞と＊の組合せで実現できる。ここで、設定情報のディレクトリエントリとＡＣＡＰのエントリ構造の違いから、設定情報である属性だけでなく、ＡＣＡＰのエントリ構造における名前をａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅ属性によって保持させていることを前提としている。これは、設定情報だけを扱うＡＣＡＰに対し、不確定の様々な情報を扱うディレクトリでは、ＡＣＡＰのエントリ構造を再現する保証が出来ないためであり、再現するよりもより現実的な解決策だからである。
【０１６４】
ＤＥＰＴＨの値が０の場合は、ａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅは完全一致、１以上の場合はａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅは指定された検索開始点を示す名前が先頭に含まれる比較を行なうようにｆｉｌｔｅｒに記述する。
【０１６５】
一方、ディレクトリエントリの木構造を、ＡＣＡＰのそれと一致させることが出来る場合は、ａｃａｐ Ｄａｔａｓｅｔ Ｎａｍｅ属性は不要となる。この場合のＡＣＡＰ ＳＥＡＲＣＨコマンドから設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）への変換の例を、図３３（ａ），（ｂ）に示す。
【０１６６】
この場合は、ＡＣＡＰの検索開始点をＬＤＡＰのｂａｓｅＯｂｊｃｔに一致させて検索を行なっている。この場合、ＡＣＡＰのＳＥＡＲＣＨコマンドのＤＥＰＴＨの値が０の場合は、ＬＤＡＰの検索範囲を指定するＳｅａｒｃｈ ＲｅｑｕｅｓｔのｓｃｏｐｅにはｂａｓｅＯｂｊｅｃｔを、ＤＥＰＴＨが１の場合はｓｃｏｐｅにはｓｉｎｇｌｅ Ｌｅｖｅｌを、ＤＥＰＴＨが２以上の場合はｓｃｏｐｅをｗｈｏｌｅ Ｓｕｂｔｒｅｅに指定することでＬＤＡＰのディレクトリ内の探索範囲を（ＬＤＡＰの機能によって）制御することが可能なように変換できる。この要求によって受信した設定情報（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｓｕｌｔメッセージ）のエントリの属性名と属性値を順次返送することで、ＡＣＡＰサーバの結果として返すことが出来る。
【０１６７】
なお、ＡＣＡＰのサービス情報登録コマンドと、ＬＤＡＰの情報登録メッセージとの間の変換も同様に可能である。
【０１６８】
次に、図１のネットワークで、図３４のディレクトリ情報木の構成において、上記ＡＣＡＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスを、図３５に示す。
【０１６９】
図３５では、アプリケーションプログラムは、ＡＵＴＨＥＮＴＩＣＡＴＥ， ＳＥＡＲＣＨ， ＬＯＧＯＵＴの順にＡＣＡＰコマンドを送信する。アプリケーションプログラムは、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドを送信し、匿名での接続を行なう。それを当該プロトコル変換装置が受信し、ＬＤＡＰ Ｂｉｎｄメッセージを部門Ａ−１自動設定サーバに送信する。そして部門Ａ−１自動設定サーバからのＬＤＡＰ Ｂｉｎｄ Ｒｅｓｐｏｎｃｅメッセージを受信して、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドの応答を返送する。
【０１７０】
次に、アプリケーションプログラムは必要な設定である／ＨＴＴＰ／以下（ａｃａｐＤａｔａｓｅｔＮａｍｅ＝／ＨＴＴＰ／＊）を検索すべく、ＡＣＡＰ ＳＥＡＲＣＨコマンドを送信し、当該プロトコル変換装置が受信し、先の例のように設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔ）に変換したメッセージを部門Ａ−１設定情報サーバに送信する。部門Ａ−１設定情報サーバと関連する部門Ａ設定情報サーバ，全社設定情報サーバの動作は、以前に述べてきた連鎖といった動作を同様に行なう。また、ＡＣＡＰ・ＬＤＡＰ変換装置がＬＤＡＰのメッセージとして受信した検索結果は、ＡＣＡＰ ＳＥＡＲＣＨコマンドの返答としてアプリケーションプログラムに返送され、アプリケーションプログラムはその情報で自動設定を行なう。
【０１７１】
ところで、アプリケーションプログラムとＡＣＡＰ・ＬＤＡＰプロトコル変換装置間、および、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置と自動設定サーバ間の認証に関しては、上記のＳＬＰ・ＬＤＡＰプロトコル変換装置の場合と同様に、各々の間での認証に関する制御は独立に行なうことで対処する。また、ＳＬＰ・ＬＤＡＰプロトコル変換装置と同様に、自動設定サーバから得た設定情報を、今後に見込まれるＡＣＡＰによる問い合わせのために、ＡＣＡＰ・ＬＤＡＰプロトコル変換装置でキャッシュすることも可能である。
【０１７２】
最後に、図４および図５の設定情報サーバに設置されている、ＳＬＰサーバプロトコル変換装置とＡＣＡＰサーバプロトコル変換装置について、図１のネットワークを例に述べる。ＳＬＰサーバプロトコル変換装置は、ユーザＰＣのアプリケーションプログラムがＳＬＰに対応しているが、ＳＬＰ・ＬＤＡＰプロトコル変換装置を持っていない場合に使用される。ユーザＰＣとＳＬＰサーバプロトコル変換装置間の動作は、ＳＬＰの仕様に従う。一方、ＳＬＰサーバプロトコル変換装置がユーザＰＣから受信する、Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ， Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ， Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔメッセージは、上記、ＳＬＰ・ＬＤＡＰプロトコル変換装置の場合と同様の方法でＬＤＡＰのメッセージとして解釈され、ディレクトリ装置の検索を実施する（実際に、変換される必要はないが、してもよい）。また、ＡＣＡＰサーバプロトコル変換装置についても、ＳＬＰサーバ変換装置と同様で、ＡＵＴＨＥＮＴＩＣＡＴＥコマンドとＳＥＡＲＣＨコマンドはＡＣＡＰ・ＬＤＡＰプロトコル変換装置と同様の方法でＬＤＡＰメッセージとして解釈し、ディレクトリ装置の検索を実施する（実際に、変換される必要はないが、してもよい）。
【０１７３】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１７４】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１７５】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１７６】
【発明の効果】
本発明によれば、各ネットワークドメインに配置された上位／下位の情報設定サーバ装置が連携することで（あるいは、他の情報設定サーバ装置を利用者計算機に紹介することで）、例えば利用者計算機が移動先でプログラムを動作する際に、利用者計算機は自装置が接続したネットワークドメインの情報設定サーバ装置に検索要求を出すだけで、自身が接続したネットワークドメインの情報設定サーバに加え、より上位または下位のドメインを管理する情報設定サーバ装置からも設定情報取得を行い、自装置の現在位置を考慮した適切なアプリケーションプログラムへの設定情報の自動設定が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る通信システムのネットワーク構成例を示す図
【図２】本発明の一実施形態に係る利用者計算機の一構成例を示す図
【図３】本発明の一実施形態に係る利用者計算機の他の構成例を示す図
【図４】本発明の一実施形態に係る設定情報サーバの一構成例を示す図
【図５】本発明の一実施形態に係る設定情報サーバの他の構成例を示す図
【図６】設定情報の格納形式の一例を示す図
【図７】設定情報の格納形式の他の例を示す図
【図８】ｏｂｊｅｃｔＣｌａｓｓによる設定情報の記述例を示す図
【図９】ｃｏｎｆｉｇｕｒａｔｉｏｎ属性による設定情報の記述例を示す図
【図１０】ｏｂｊｅｃｔＣｌａｓｓによる設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１１】ｃｏｎｆｉｇｕｒａｔｉｏｎ属性による設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の他の例を示す図
【図１２】条件付け設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１３】スコープを用いた設定情報の格納形式の一例を示す図
【図１４】スコープを指定した設定情報検索要求（ＬＤＡＰ Ｓｅａｒｃｈ Ｒｅｑｕｅｓｔメッセージ）の一例を示す図
【図１５】サーバリンク情報の格納形式の一例を示す図
【図１６】設定情報のディレクトリ情報木の構成例を示す図
【図１７】情報取得動作シーケンスの一例を示す図
【図１８】設定情報検索要求の一例を示す図
【図１９】情報取得動作シーケンスの他の例を示す図
【図２０】情報取得動作シーケンスのさらに他の例を示す図
【図２１】本発明の一実施形態に係る通信システムのネットワーク構成例を示す図
【図２２】設定情報検索要求の他の例を示す図
【図２３】情報取得動作シーケンスのさらに他の例を示す図
【図２４】Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２５】Ｓｅｒｖｉｃｅ Ｔｙｐｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図２６】Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２７】Ｓｅｒｖｉｃｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図２８】Ａｔｔｒｉｂｕｔｅ Ｒｅｑｕｅｓｔ（ＳＬＰ）の変換例について説明するための図
【図２９】Ａｔｔｒｉｂｕｔｅ Ｒｅｐｌｙ（ＳＬＰ）の変換例について説明するための図
【図３０】ＳＬＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスの一例を示す図
【図３１】ＡＵＴＨＥＮＴＩＣＡＴＥ（ＡＣＡＰ）の変換例について説明するための図
【図３２】ＳＥＡＲＣＨ（ＡＣＡＰ）の一変換例について説明するための図
【図３３】ＳＥＡＲＣＨ（ＡＣＡＰ）の他の変換例について説明するための図
【図３４】設定情報のディレクトリ情報木の構成例を示す図
【図３５】ＡＣＡＰ・ＬＤＡＰプロトコル変換装置の動作シーケンスの一例を示す図
【符号の説明】
１…全社設定情報サーバ
１１…部門Ａ設定情報サーバ
１１１…部門Ａ−１設定情報サーバ
１２…部門Ｂ設定情報サーバ
２…ユーザＰＣ
６…イントラネット
２２１，２４１，１２１，１４１…ネットワーク通信装置
２２４，２４４…アプリケーションプログラム
２２７…ＳＬＰ・ＬＤＡＰプロトコル変換装置
２２８…ＡＣＡＰ・ＬＤＡＰプロトコル変換装置
２４２…自動設定装置
２４２１…設定取得制御装置
２４２２…取得設定情報データベース
２４２３…設定情報反映装置
１２２，２４２４…ＬＤＡＰクライアント装置
２４２７…ＳＬＰクライアント装置
２４２８…ＡＣＡＰクライアント装置
１２３，１４３…ディレクトリ検索装置
１２４，１４４…ディレクトリ装置
１２５…連鎖制御装置
１２６，１４６…ＬＤＡＰサーバ装置
１２７，１４７…ＳＬＰサーバプロトコル変換装置
１２８，１４８…ＡＣＡＰサーバプロトコル変換装置
Claims (16)
- 利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、
自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持するための第１の保持手段と、
自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、
前記第２の保持手段にリンク情報が保持されている設定情報サーバ装置と通信する通信手段と、
受信した第１の設定情報検索要求の検索範囲指定に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果、および該検索範囲指定を適切な値に修正した第２の設定情報検索要求を自装置と連鎖する他の設定情報サーバ装置へ前記通信手段を介して送信しその返答として該他の設定情報サーバ装置から得た検索結果の少なくとも一方を含む設定情報検索結果を、該第１の設定情報検索要求の要求元装置に配送するための制御を行う制御手段とを備えたことを特徴とする設定情報サーバ装置。 - 利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、
自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持する第１の保持手段と、
自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、
下位の設定情報サーバ装置から検索範囲指定が無指定の状態に設定された設定情報検索要求を受信した場合、前記第２の保持手段を参照し、自装置が最上位の設定情報サーバ装置でないならば、自装置の上位の設定情報サーバ装置に検索範囲指定が無指定の状態に設定された設定情報検索要求を送信して該上位の設定情報サーバ装置から得た設定情報を、元の要求元へ配送し、自装置が最上位の設定情報サーバ装置であるならば、下位の設定情報サーバ装置に検索範囲指定を該下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第１の制御手段と、
上位の設定情報サーバ装置から検索範囲指定に自装置とあらかじめ関連付けられている検索範囲指定の値が設定された設定情報検索要求を受信した場合、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきと判断されれば、該自装置の下位の設定情報サーバ装置に検索範囲指定を更に該自装置の下位の設定情報サーバ装置とあらかじめ関連付けられている検索範囲指定の値に修正した設定情報検索要求を送信して該自装置の下位の設定情報サーバ装置から得た設定情報および前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送し、自装置の下位の設定情報サーバ装置に設定情報検索要求を出すべきでないと判断されれば、前記第１の保持手段を検索して得た設定情報を、元の要求元へ配送するための制御を行う第２の制御手段とを備えたことを特徴とする設定情報サーバ装置。 - 利用者計算機上で動作するプログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置であって、
自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持するための第１の保持手段と、
自装置が管理対象とするネットワークドメインに含まれる下位のサブドメインを管理対象としている下位の設定情報サーバ装置へのリンク情報、および自装置が管理対象とするネットワークドメインを下位のサブドメインとして含む上位のサブドメインを管理対象としている上位の設定情報サーバ装置へのリンク情報の少なくとも一方を保持するための第２の保持手段と、
利用者計算機と通信する通信手段と、
利用者計算機から受信した設定情報検索要求の検索範囲指定に応じて、前記第１の保持手段に保持された設定情報を検索して得た検索結果と、前記第２の保持手段を利用して得られる自装置と連鎖する他の設定情報サーバ装置および該他の設定情報サーバ装置に設定情報検索要求を出す際に検索範囲指定に設定すべき適切な検索開始点を示す通知情報との少なくとも一方を、該利用者計算機に配送するための制御を行う制御手段とを備えたことを特徴とする設定情報サーバ装置。 - 前記第１の保持手段に保持されている設定情報の影響範囲は、任意の値を示す記号を含む表記を用いて記述されていることを特徴とする請求項１ないし３のいずれか１項に記載の設定情報サーバ装置。
- 受信した前記設定情報検索要求に含まれる、ネットワーク中における場所を示す情報と、前記第１の保持手段に保持されている前記設定情報の影響範囲とを比較することによって、前記第１の保持手段から該当する設定情報を検索することを特徴とする請求項４に記載の設定情報サーバ装置。
- 設定情報サーバ装置内部で使用する標準プロトコルとは異なるプロトコルによって、前記利用者計算機に対する設定情報検索配送サービスを提供するためのプロトコル変換を行うプロトコル変換手段を更に備えたことを特徴とする請求項１ないし５のいずれか１項に記載の設定情報サーバ装置。
- 前記プロトコル変換手段は、サービス・ロケーション・プロトコルの接続メッセージ、サービス情報配送要求メッセージ、サービス情報配送メッセージ、サービス情報登録メッセージの各々と、ライトウェイト・ディレクトリ・アクセス・プロトコルの接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むことを特徴とする請求項７に記載の設定情報サーバ装置。
- 前記プロトコル変換手段は、アプリケーション・コンフィグレーション・アクセス・プロトコルの接続コマンド、サービス情報配送要求コマンド、サービス情報配送コマンド、サービス情報登録コマンドの各々と、ライトウェイト・ディレクトリー・アクセス・プロトコルの接続メッセージ、検索要求メッセージ、検索結果配送メッセージ、情報登録メッセージの各々との間の変換を行う手段を含むことを特徴とする請求項７に記載の設定情報サーバ装置。
- 前記設定情報の内容を記述する属性の値として、該設定情報の内容の実際の記憶箇所を示す情報を記述したことを特徴とする請求項１ないし８のいずれか１項に記載の設定情報サーバ装置。
- プログラムの設定情報の検索要求に使用すべき標準プロトコルが特定のものに定められている設定情報サーバ装置から、自装置上で動作中のプログラムの要求する設定情報を取得する利用者計算機であって、
自装置上で動作中のプログラムの出力する、設定情報を取得するための設定情報検索要求であって、前記標準プロトコルとは異なるプロトコルによる設定情報検索要求を、該標準プロトコルによる設定情報検索要求に変換する手段と、
前記標準プロトコルによる設定情報検索要求をネットワークを介して送信し、これに対する応答として配送された、該標準プロトコルによる応答メッセージを、前記プログラムが使用する前記プロトコルによる応答メッセージに変換して、該動作中のプログラムに渡す手段とを備えたことを特徴とする利用者計算機。 - 前記設定情報サーバ装置からの前記設定情報検索要求に対する応答メッセージに、他の設定情報サーバ装置を紹介する情報が含まれている場合には、該他の設定情報サーバ装置にも設定情報検索要求を送信させる手段を更に備えたことを特徴とする請求項１０に記載の利用者計算機。
- 前記設定情報検索要求の検索範囲指定に設定すべき適切な値が分からない場合には、該検索範囲指定を無指定の状態に設定することを特徴とする請求項１０または１１に記載の利用者計算機。
- 前記設定情報検索要求には、その送信時に自装置が属する場所情報を付加することを特徴とする請求項１０ないし１２のいずれか１項に記載の利用者計算機。
- 配送された設定情報のうちに、同一の設定項目に対して内容の相違する複数の設定情報が存在する場合に、前記設定情報とともに配送された、任意の値を示す記号を含む表記を用いて記述された該設定情報の影響範囲を示す情報に基づいて、採用すべき設定情報を選択する手段を更に備えたことを特徴とする請求項１０ないし１３のいずれか１項に記載の利用者計算機。
- プログラムの設定情報を記憶し、外部からの設定情報検索要求に応じて該当する設定情報を配送する設定情報サーバ装置の設定情報配送方法であって、
受信した第１の設定情報検索要求の検索範囲指定に応じて、自装置が管理対象とするネットワークドメインを影響範囲とする設定情報を保持する第１の保持手段を検索する手順、および自装置と連鎖する、自装置の上位または下位のサブドメインを管理対象としている他の設定情報サーバ装置へ、該第１の設定情報検索要求の検索範囲指定を適切な値に修正した第２の設定情報検索要求を送信する手順のうちの少なくとも一方の手順を実行し、
前記検索により得られる設定情報および前記第２の設定情報検索要求に対する返答として前記他の設定情報サーバ装置から得られる設定情報のうち、前記手順を実行して得られたものを、前記第１の設定情報検索要求の要求元装置に配送することを特徴とする設定情報配送方法。 - プログラムの設定情報を保持する設定情報サーバ装置に利用者計算機が設定情報検索要求を送信し、これに応じて該設定情報サーバ装置が該利用者計算機に該当する設定情報を配送する設定情報配送方法であって、
利用者計算機は、自装置が属する場所情報を含む設定情報検索要求を設定情報サーバ装置に送信し、
前記設定情報検索要求を受信した設定情報サーバ装置は、自装置内に記憶された設定情報のうち、該設定情報に対応して記憶されている、任意の値を示す記号を含む表記を用いて記述された影響範囲と、該設定情報検索要求に含まれる場所情報とを比較し、該場所情報に合致する影響範囲を持つ設定情報を検索結果として抽出し、
前記設定情報サーバ装置は、前記設定情報検索要求を送信した前記利用者計算機に、前記検索により得られた前記設定情報を配送することを特徴とする設定情報配送方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09375899A JP3559471B2 (ja) | 1999-03-31 | 1999-03-31 | 設定情報サーバ装置、利用者計算機及び設定情報配送方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP09375899A JP3559471B2 (ja) | 1999-03-31 | 1999-03-31 | 設定情報サーバ装置、利用者計算機及び設定情報配送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000285053A JP2000285053A (ja) | 2000-10-13 |
| JP3559471B2 true JP3559471B2 (ja) | 2004-09-02 |
Family
ID=14091344
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP09375899A Expired - Fee Related JP3559471B2 (ja) | 1999-03-31 | 1999-03-31 | 設定情報サーバ装置、利用者計算機及び設定情報配送方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3559471B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4564766B2 (ja) * | 2003-03-20 | 2010-10-20 | 株式会社リコー | 印刷環境共用サービス提供装置、印刷環境共用サービス提供方法、印刷環境共用サービス提供プログラム及び記録媒体 |
| JP4265658B2 (ja) | 2007-01-25 | 2009-05-20 | セイコーエプソン株式会社 | 処理応答装置、処理要求装置およびそれらの方法 |
| CN102761520B (zh) * | 2011-04-26 | 2015-04-22 | 国际商业机器公司 | 认证信息处理方法和系统 |
| JP2014102816A (ja) * | 2012-10-26 | 2014-06-05 | Ricoh Co Ltd | 設定支援装置、設定支援システム、及び設定支援方法 |
-
1999
- 1999-03-31 JP JP09375899A patent/JP3559471B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000285053A (ja) | 2000-10-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5102841B2 (ja) | プロキシを伴う分散ディレクトリのための方法、プロキシ・サーバ、及びプロキシ・ディレクトリ・システム | |
| US6470332B1 (en) | System, method and computer program product for searching for, and retrieving, profile attributes based on other target profile attributes and associated profiles | |
| EP1517508B1 (en) | Method and apparatus for representing and applying network topological data | |
| US6553368B2 (en) | Network directory access mechanism | |
| US5812779A (en) | Storage medium and system for managing and distributing data objects of different types between computers connected to a network | |
| US6247017B1 (en) | Server-client communication over a network | |
| US6651047B1 (en) | Automated referential integrity maintenance | |
| EP1333389A2 (en) | Directory server software architecture | |
| US6973463B2 (en) | Replication architecture for a directory server | |
| US6363375B1 (en) | Classification tree based information retrieval scheme | |
| US7051114B1 (en) | System and method for integrating directory servers | |
| CA2313043A1 (en) | Communications network | |
| US7523170B1 (en) | Service locator technique implemented in a data network | |
| US20030212797A1 (en) | Setting management system for network connection | |
| EP2006781A1 (en) | Method, apparatus and system for indexing and searching DNS zone records | |
| JP3559471B2 (ja) | 設定情報サーバ装置、利用者計算機及び設定情報配送方法 | |
| US20020174225A1 (en) | Fractional replication in a directory server | |
| US7313598B1 (en) | Method and apparatus for partial replication of directory information in a distributed environment | |
| JP2002244979A (ja) | 電子メールシステム | |
| Pöhlsen et al. | Integrating a decentralized web service discovery system into the internet infrastructure | |
| Nasal | Automating IP Host Data Collection on a LAN | |
| JP2000357119A (ja) | ディレクトリ・サービス・システム | |
| Installation et al. | ARIS and EGIIS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040217 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040419 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040518 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040521 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090528 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090528 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100528 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110528 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |