JP4303541B2 - 検索方法及び検索ブローカ - Google Patents

Description

本発明は、Ｗｅｂサービスのような複数のサービスの階層的な組み合わせによって実現されるサービスに関し、特に、クライアント及びサーバのサービス利用に関する多様なポリシーを反映したサービス検索方法及びサービスを検索する検索ブローカに関する。

インターネットのような計算機ネットワークに接続された複数の計算機で分散処理を行うために、クライアント・サーバ方式が一般的に用いられている。この分散処理では、非特許文献１に示されるＣＯＲＢＡ（Common Object Request Broker Architecture）、ＣＯＭ（Component Object Model）やＲＭＩ（Remote Method Invocation）等の分散オブジェクト技術によって、機能的に粒度の大きい処理を「モジュール」として部品化し、それらを組み合わせて１つのサービスを提供することが可能である。

これらのモジュールの組み合わせは、実行前に予め静的にモジュールの結合を決定しておくことも可能だが、「レジストリ」と呼ばれるモジュール情報のデータベースを利用して、動的にモジュールを選択し結合することも可能である。レジストリは、主にサービスの内容とサービスの呼び出し方法が格納されている。なお、前述した分散オブジェクト技術は、固有の通信プロトコルを使用しており、また、一般的にファイアウォールを通過できないので、主に企業内ＬＡＮ（Local Area Network）内で利用されている。

一方、ＷＷＷ（World Wide Web）の通信プロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）や電子メールのプロトコルであるＳＭＴＰ（Simple Message Transfer Protocol）は、元々、外部（インターネット）とのデータ通信を主に考慮されているので、ファイアウォールを越えて外側のサーバとのデータのやり取りが容易にできるように設計されている。また、ＸＭＬ（eXtensible Markup Language）と呼ばれるデータ記述メタ言語によって、計算機に依存しない、柔軟性の高いテキストベースのデータ記述方法が普及しつつある。

そして、これらの技術を背景に、「Ｗｅｂサービス」と呼ばれる分散オブジェクト技術が新たに開発されている。Ｗｅｂサービスという言葉は、ＷＷＷを利用したサービス一般やＨＴＴＰ／ＸＭＬベースのＲＰＣ（Remote Procedure Call）といった広義の定義と、ＳＯＡＰ（Simple Object Access Protocol）／ＵＤＤＩ（Universal Directory and Discovery Interface）／ＷＳＤＬ（Web Service Description Language）を中心技術とした狭義の定義とがあるが、本明細書では、Ｗｅｂサービスは後者の狭義の定義とする。このＷｅｂサービスは、通信プロトコルとしてＨＴＴＰやＳＭＴＰを利用するため、企業内はもとより、企業間における分散システムの構築が期待されている。

非特許文献２に示されるＷｅｂサービスにおけるＷＳＤＬによってサービスのインターフェイスが記述される。ＷＳＤＬの定義には、サービス実行時に、クライアントがサーバに送信するメッセージのデータ形式の定義と、サーバがクライアントに返信するサービスの実行結果メッセージのデータ形式の定義とが含まれている。また、ＷＳＤＬ記述にはサービスが提供されている場所に関する情報も含まれており、通常その場所に関する情報は、サーバのＵＲＬ（Uniform Resource Locator）によって示される。

これらのクライアント・サーバ間のメッセージは、ＸＭＬを用いて記述され、クライアントプログラム又はサーバプログラムによって、プログラムの内部形式からＸＭＬ形式に変換され、ネットワーク経由で転送される。Ｗｅｂサービスでは、このＸＭＬ形式のメッセージを、ＳＯＡＰと呼ばれるプロトコルを用いてクライアント・サーバ間で送受信する。ＳＯＡＰは、通常はインターネットの標準プロトコルであるＨＴＴＰ（Hypertext Transfer Protocol）によってカプセル化されて送信される。

このように、Ｗｅｂサービスは、サービスのインターフェイスの明確な定義によって、サービスのネットワーク内における部品（コンポーネント）化が容易となっている。また、Ｗｅｂサービスでは、ＨＴＴＰを基盤の通信プロトコルとして利用可能なので、ネットワーク透過性が非常に高く、部品の可搬性が高い。

Ｗｅｂサービスは、前述のＣＯＲＢＡ、ＣＯＭ、ＲＭＩと同様に、各々のＷｅｂサービスモジュールが提供するサービスの部品を組み合わせ、より大きなサービス機能を実現することが可能である。つまり、サービスモジュールによる部品（サービス部品）を組み合わせることで、サービス構築の生産性を向上することができる。また、既にあるサービス部品を用いて新しいサービスが構築できるので、サービスプロバイダは、自身が提供するサービスのみに注力できるようになり、サービスの提供に必要なコストが削減できる。

このサービス部品は、再利用を可能とするために、レジストリによって管理されており、レジストリによってサービス部品のインターフェイス記述と共に保管される。レジストリは、サービス部品を登録し、要求があると、インターフェイスや機能によって検索する。新しいサービスを構築しようとするサービスプロバイダは、レジストリからサービス部品を検索することで構築しようとするサービスに必要なサービス部品を調達する。そして、サービス部品を結合することで新しいサービスを構成する。サービス部品の結合は、予め利用するサービス部品を決めておくことも、サービス実行時に動的にレジストリを検索し、新しいサービスを構成することも可能である。

このような分散オブジェクトシステムにおいては、各サービス部品は一般に階層構造を持ち、あるサービス部品は、依存する他のサービスの部品によって構成されている。このような階層構造を持ったサービスでは、一般にそれを構成する個々のサービス部品間のつながりは疎であり、公開されているインターフェイス定義とその機能によって結合されているのみである。それぞれのサービス部品は、単体で特定の機能を提供し、多くの場合、個々のサービス部品が別のサービス提供会社（サービスプロバイダ）によって提供されている。

このように、サービス部品がレジストリに豊富に登録されている状態になると、サービスプロバイダが階層構造を持つサービスを提供するときには、サービスプロバイダは、提供しようとするサービスに固有の部分（例えばユーザのインターフェイス）だけを実現すればよく、サービスに固有でない部分に関しては、レジストリから検索したサービス部品を利用する。

このサービス部品の市場が形成されると、特定のサービス部品の種類に対しては、複数のサービスプロバイダが同種のサービスを提供することも生ずる。すなわち、サービスを構成しようとするときに、特定のサービスのレジストリを検索すると、複数のサービス部品が検索結果として得られる。この複数のサービス部品から、１つのサービス部品を選択することは、サービスを提供するサービスプロバイダの意思（ポリシー）に依存している。クライアントが、複数のサービス部品の中から一つのサービス部品を選ぶ基準は、上層のサービスを提供するサービスプロバイダに対するクライアントのポリシー、又はサービスの内容に対するクライアントのポリシー等によって行われる。
「Common Object Request Broker Architecture: Core Specification」，Object Management Group,Inc. 「Web Service Description Language」，World Wide Web Consortium

前述のように、階層構造を持つサービスを提供するための基盤が普及するにつれて、個々のサービス部品（要素サービス）が提供するサービスの内容とクライアントのサービスに対する要求との適合性が問題になる。クライアントのサービスに対する要求は多様であり、例えば、サービスの品質に関わるもの、サービスを提供しているサービスプロバイダの信用に基づいたものなど多種多様である。このような様々なクライアントのサービスに対する要求（クライアントのポリシー）の全てに適合する単一のサービスを用意することは困難である。

サービスに多様なクライアントのポリシーを適用する方法には、サービスの実行時のパラメータとして、クライアントのポリシーを指定し、サービス側で入力されたポリシーに従ってサービスを実行するという方法がある。しかし、この方法では、サービスの階層構造が大きくなるにつれてパラメータ数が膨大なものになってしまうという欠点がある。パラメータ数の増加は、クライアントの使い勝手の悪化や、要素サービスを提供するサービスプロバイダによるサービスの実装コストの増大を招くため、要素サービスの提供そのものが困難になる。また、上層の要素サービスが、全ての下層要素サービスについてのパラメータを予め想定して受け付けることも困難である。

このようなサービスの構成に対するポリシー適用の必要性から、本発明は以下の（Ａ）〜（Ｃ）のサービス提供方法を提供することを目的とする。

（Ａ）サービスに対して、要求ごとにパラメータを指定するのではなく、予めクライアントのポリシー情報を定義しておき、実行時にそのクライアントのポリシー情報を参照して、サービスの構成を変更できるような枠組みを提供する。

（Ｂ）クライアントのポリシー情報は、プライバシーや機密情報に相当するものも多く、要素サービスに対して開示することは問題である。従って、要素サービスに対して、ポリシーを開示せずに下層サービスの検索が可能となる仕組みを提供する。

（Ｃ）クライアントのポリシー以外にも、要素サービスプロバイダ自身のポリシーを反映する仕組みが必要である。要素サービス提供者には独自のノウハウがあるので、このノウハウを反映したいという要求を満たす。

前述のように、サービスの構成について、クライアントのポリシーを反映することが困難な理由は、サービスを提供する基盤に、クライアントのポリシーを適用するための枠組みが提供されていないためである。

そのため本発明は、サービスの構成に関するポリシーを適用するための枠組みを与える。具体的には、前述の（Ａ）〜（Ｃ）の課題に対応して、以下の（Ａ）〜（Ｃ）の手段を提供する。

（Ａ）クライアントのポリシー情報を蓄積するポリシーデータベースを設ける。また、ポリシー情報を要求に応じてポリシーデータベースから取得し返送するポリシー管理サーバを設ける。そして、要素サービスが次段の要素サービスを検索する際に、後述する（Ｂ）の手段を用いて、クライアントのポリシーによりフィルタリングされた要素サービスのリストを得る。検索要求を行った要素サービスは、クライアントのポリシーが反映された要素サービスのリスト（一覧）から適当な要素サービスを呼び出す。これにより、クライアントのポリシーを反映した形で要素サービスを動的に構成することが可能となる。

（Ｂ）クライアントのポリシーデータベース及びポリシー管理サーバは、クライアントの要求を受け付ける窓口サーバの管理下に設ける。また、要素サービスの検索とポリシーの反映を代行する検索ブローカを設ける。この検索ブローカは、要素サービスから次段の要素サービスの検索依頼を受け付け、次のようにクライアントのポリシーを反映した検索結果、具体的には、要素サービスのリストを検索要求元に返送する。まず、ポリシー管理サーバにクライアントのポリシーを問い合わせ取得する。次に、レジストリから検索要求元が要求する要素サービスを検索し要素サービスの一覧を取得する。次に、取得した要素サービスの一覧から、取得したポリシーに適合する要素サービスのみ抽出する。最後に、抽出した要素サービス一覧を要素サービス検索依頼元に返送する。以上により、クライアントのポリシー情報を、要素サービス検索要求元に公開することなく、クライアントのポリシーを反映した形でサービスを動的に構成することが可能となる。

（Ｃ）要素サービスに、要素サービス自身のノウハウ等のポリシーを格納した要素サービスプロバイダポリシーデータベースを設ける。要素サービスは検索ブローカの検索結果に対して要素サービスプロバイダポリシーデータベースのポリシーを適用し、次段の要素サービスを決定する。これにより、要素サービスプロバイダが持つノウハウを要素サービス選択の指標に利用することができる。さらに、要素サービスは、前段の要素サービスに、自身の処理結果を返送する際、要素サービスが利用した次段の要素サービスの評価項目（クライアントに対する評価項目）を合わせて返送する。窓口サーバは、次段サービスから収集された評価項目をサービス利用後のクライアントに提示して、クライアントの評価を受ける。クライアントの評価、すなわち、各要素サービスの評価を、再帰的に要素サービスプロバイダポリシーデータベースに反映させる。なお、ポリシーは、クライアントの信用度（利用頻度等）を用いて、信用度の高いユーザの場合は自動的に反映し、信用度の低いユーザの場合はオペレータを経由し手動で反映させる。これにより、要素サービスプロバイダのノウハウでもある要素サービスプロバイダポリシーデータベースを拡充することが可能となる。

ユーザがポリシーを定義することにより、ユーザの手を煩わせることなくサービスの構築（カスタマイズ）が可能となる。また、ユーザのポリシー情報を要素サービス提供サーバに公開しないので、要素サービス提供サーバの提供会社での個人情報の悪用や、要素サービス提供サーバの提供会社がクラッキングされて個人情報が漏洩する問題が生じることがない。これは、情報が広範囲にあればあるほど情報の保護は容易でないという点から、本発明のように、情報（ポリシー）を局所的に管理、利用する方が情報漏洩の危険性が低くなるためである。

また、ユーザの評価を要素サービス提供サーバの提供会社のポリシーデータベースにフィードバックさせることにより、要素サービス提供会社のポリシー情報を自動的に保守、拡充が可能となる。

図１は本発明の第１の実施の形態のサービス提供システムの構成を示すブロック図である。第１の実施の形態は、旅行業界を例として、ユーザが旅行代理店を通じて、現地観光サービス、ホテル、バス等の予約を行うサービスを提供するものである。

このサービス提供システムは、ユーザが操作を行うクライアント１００、ユーザの窓口となる窓口サーバ１０１、及び、要素サービスを提供する要素サービス提供サーバ（現地観光ツアーサービス１０４、バスサービス１０５、ホテルサービス１０６）等から構成されている。

クライアント１００は、ユーザが操作し、サービスの提供を要求し、その結果を受け取る端末であって、Ｗｅｂ（World Wide Web）ブラウザや専用のクライアントプログラムが動作している。窓口サーバ１０１は、ユーザからのサービス要求の窓口となるサーバであり、ユーザからのサービス要求を受け取ると、検索ブローカ１０７にユーザのポリシー情報と、要素サービスの提供を行う次段の要素サービス提供サーバと、を問い合わせる。問い合わせ結果に基づいて、他の要素サービス提供サーバ（次段の要素サービス提供サーバ）にサービスの提供を依頼する。

ユーザは、クライアント１００から窓口サーバ１０１にアクセスし（２１１０）、サービスの利用を開始し、サービスを要求する。窓口サーバ１０１は、ユーザの要求を受け付けると、ユーザの要求の処理（例えば、ホテルサービスと現地観光地サービスの予約）を行うために、検索ブローカ１０７に対して、要求されたサービスを提供する要素サービス提供サーバの検索要求を送信する（２１１１）。本実施形態では、まず、現地観光地ツアーを予約し、次にホテルを予約する。なお、この順番は逆でもよいし、同時に実行することも可能である。

窓口サーバ１０１から現地観光ツアー予約のためのサービス検索要求（２１１１）を受け付けた検索ブローカ１０７は、ポリシー管理サーバ１０２に現地観光ツアーサービスに関するユーザのポリシーを問い合わせる（２１１２）。問い合わせを受け付けたポリシー管理サーバ１０２は、ポリシーデータベース１０３から現地観光ツアーサービスに関するユーザのポリシー情報を取得し、その結果を検索ブローカ１０７に返送する（２１１３）。次に、検索ブローカ１０７は、レジストリ管理サーバ１０８に窓口サーバ１０１の検索要求（現地観光ツアーサービス）に適合するサービスを提供する要素サービス提供サーバを問い合わせる（２１１４）。問い合わせを受け付けたレジストリ管理サーバ１０８は、レジストリデータベース１０９を検索して、検索条件に適合する要素サービス提供サーバの一覧を返送する（２１１５）。次に、検索ブローカ１０７は、要素サービス提供サーバの一覧に対して、ユーザのポリシー情報を適用して、ユーザの要求するサービスを提供する要素サービス提供サーバの情報のみを抽出し、その結果を窓口サーバ１０１に返送する（２１１６）。

窓口サーバ１０１は、要素サービス提供サーバ１０４（現地観光ツアーサービスＡ）の情報が検索ブローカ１０７から検索結果として返送されると、要素サービス提供サーバ１０４を呼び出して、サービスの処理を依頼する（２１１７）。呼び出された要素サービス提供サーバ１０４は、依頼された処理を行うと共に、窓口サーバ１０１と同様にして検索ブローカ１０７を介してユーザのポリシーに適合した次段の要素サービス提供サーバを検索し（２１１８）、結果である要素サービス提供サーバ１０５の情報を受け取る（２１１９）。同様に、要素サービス提供サーバ１０５も検索ブローカ１０７を介して要素サービス提供サーバを検索し（２１２１）、さらに次段の要素サービス提供サーバの情報を受け取ると（２１２２）、さらに次段の要素サービス提供サーバに処理を依頼し（２１２３）、処理の結果を受け取る（２１２４）。要素サービス提供サーバ１０４は、次段の要素サービス提供サーバの処理が終了し処理の結果を受け取ると（２１２５）、全てのサービスの処理の結果を窓口サーバ１０１に送る（２１２６）。

この一連の処理によって現地観光ツアーサービスが呼び出され、処理（観光ツアーの予約）が完了する。

次に、窓口サーバ１０１は、ホテル予約のためのサービスを呼び出す。ホテルサービスの呼び出しについても、同様に検索ブローカ１０７で要素サービス提供サーバを検索し、処理を依頼し（２１２７）、ホテルの予約の結果を受け取る（２１２８）。

このように、窓口サーバ１０１は、検索ブローカ１０７を介してユーザのポリシーに適合する要素サービス提供サーバを検索し、サービスを実行する。この、要素サービス提供サーバを呼び出す処理を再帰的に行うことで、複合的なサービスを実現することができる。

図２は、窓口サーバ１０１の詳細を示すブロック図である。

窓口サーバ１０１は、クライアントインターフェイス部２００、ユーザ管理部２０１、要素サービス処理部２０２、次段サービス呼び出し部２０３、検索ブローカ問い合わせ部２０４等を備えている。

クライアントインターフェイス部２００は、ユーザの要求を受け付け、ユーザに処理の結果を送り、処理の結果を提示することで、対話的なインターフェイスとして機能する。このクライアントインターフェイス部２００は、一般的にはＨＴＴＰ（Hypertext Transfer Protocol）プロトコルを利用したＷｅｂ（World Wide Web）インターフェイスが用いられるが、独自プロトコルを利用した独自のインターフェイスでもよい。

ユーザ管理部２０１は、ユーザのアカウントやセッションＩＤの管理を行う。階層サービスの提供を受けるユーザは、窓口サーバ１０１に予め登録を行い、ユーザ個別のアカウントを取得する。登録したユーザは、ポリシー情報をポリシーデータベース１０３に入力する。このユーザの登録によって一度入力したポリシー情報を再度入力することなく、その後も利用することができる。また、窓口サーバ１０１は、ユーザがサービスの要求を行う際は、その要求に対してセッションＩＤを割り振る。窓口サーバ１０１は、セッションＩＤを用いることで、他のユーザや他のサービス要求と処理が重複することなく処理をすることができる。

窓口サーバ１０１は、クライアントインターフェイス部２００でユーザからのサービス要求（リクエスト）を受け付けると、まず、検索ブローカ問い合わせ部２０４が、検索ブローカ１０７に、処理を依頼するために呼び出す次段の要素サービス提供サーバを問い合わせる（図１の２１１１）。検索ブローカ１０７から問い合わせの結果を受け取ると（図１の２１１６）、次段サービス呼び出し部２０３は、問い合わせの結果に従って、次段の要素サービス提供サーバを呼び出す。なお、要素サービス処理部２０２は、窓口サーバの固有の処理を行う。窓口サーバ固有の処理とは、例えば、ユーザへのサービス利用料課金処理などである。

なお、要素サービス提供サーバ（１０４、１０５、１０６）は、この窓口サーバ１０１のクライアントインターフェイス部２００とユーザ管理部２０１とが除かれた構成であり、要素サービス処理部２０２、次段サービス呼び出し部２０３及び検索ブローカ問い合わせ部を備えている。

図３は、窓口サーバ１０１が検索ブローカ１０７に検索を依頼するための電文（図１の２１１１）の一例を示す説明図である。

電文内容は、本図のようにＸＭＬ（eXtensible Markup Language）形式で記載される。電文内容には最低限、検索するサービスの種別（３００）とユーザのセッションＩＤ（３０１）とが含まれる。サービス種別（３００）には、要素サーバの提供するサービスの内容が記載され、セッションＩＤ（３０１）には、要求を行ったユーザ（及びサービス要求）を示すための内容が記載される。図３に示す例では、サービス種別（３００）は“<service>”タグによって記載される「現地観光ツアーサービス」であり、セッションＩＤ（３０１）は“<session-id>”タグによって記載される「xyz1234567」である。

図４は、検索ブローカ１０７の詳細を示すブロック図である。

検索ブローカ１０７は、ポリシー問い合わせ部４００、検索受付部４０１、レジストリ検索部４０２、ポリシー反映部４０３等を備えている。

ポリシー問い合わせ部４００は、ユーザのポリシー情報をポリシー管理サーバ１０２に問い合わせる。検索受付部４０１は、窓口サーバや要素サービス提供サーバからの検索要求の受け付ける。また、検索受付部４０１は、検索結果を返送する検索結果送信部としても機能する。レジストリ検索部４０２は、レジストリ管理サーバ１０８に要求された要素サービスを提供する要素サービス提供サーバを問い合わせる。ポリシー反映部４０３は、レジストリ検索部４０２によって行った検索によって、レジストリ管理サーバ１０８から受け取った要素サービス提供サーバの一覧に対して、ユーザのポリシーを適用する。そして、ユーザのポリシーが示している条件に合致する要素サービス提供サーバのみを抽出（フィルタリング）して、ポリシー抽出部として機能する。

図５は、検索ブローカ１０７がポリシー管理サーバ１０２にポリシーの問い合わせを要求する電文（図１の２１１２）の一例を示す説明図である。

検索ブローカ１０７は、窓口サーバ１０１から送信された依頼電文（図３）を受け取ると、この電文からサービス種別（図３の３００）とユーザのセッションＩＤ（図３の３０１）とを抽出し、それぞれを、問い合わせ要求のサービス種別（５００）、ユーザのセッションＩＤ（５０１）として電文を生成し、これをポリシー管理サーバ１０２に送り、サービス種別のポリシーを問い合わせる。

図６は、ポリシー管理サーバ１０２の詳細を示すブロック図である。

ポリシー管理サーバ１０２は、クライアントインターフェイス６００、問い合わせ受付応答部６０１、データベース検索部６０２等を備えている。また、ポリシー管理サーバにはポリシーデータベース１０３が接続されている。

クライアントインターフェイス６００は、ユーザからのポリシー情報をポリシーデータベース１０３に書き込むことで新たにポリシー情報を生成し、又は、既に記録されている内容を更新する。問い合わせ受付応答部６０１は、検索ブローカ１０７からポリシーの問い合わせを受け付け、結果を検索ブローカ１０７に送信する。データベース検索部６０２は、ポリシー情報をポリシーデータベース１０３から検索する。

ポリシー管理サーバ１０２は、検索ブローカからポリシー検索要求（図５）を受け付けると、データベース検索部６０２により、サービスの種別（図５の５００）を検索キーとしてポリシーデータベース１０３を検索する。検索されたサービス種別に対するユーザのポリシー情報は、問い合わせ受付応答部６０１によって検索ブローカ１０７に返送される。

図７は、ポリシーデータベース１０３に記録されている内容の一例を示す表である。

ポリシーデータベース１０３は、ユーザ毎に図７のような表（テーブル）を持つ。このテーブルには、サービス種別毎に、複数（１個以上）のポリシー項目とポリシー条件とを持つ。例えば図７の場合は、「観光ツアーサービス」というサービス種別について、「介護サービス」というポリシー項目が「有り」というポリシー条件が記録されている。また、同じく「観光ツアーサービス」というサービス種別について、業者の「格付け」というポリシー項目が「ＡＡ以上」というポリシー条件が記録されている。

ポリシーデータベース１０３に記録されている内容のうち、ユーザに対応するテーブルを選択する方法は、セッションＩＤ（図５の５０１）と、ユーザのアカウント毎に割り当てたユーザ識別子と、を関連付けたテーブルを利用する。このテーブルは窓口サーバのユーザ管理部２０１が持っている。ポリシー管理サーバ１０２は、ポリシーの問い合わせがあったときに、窓口サーバに対してセッションＩＤを用いて問い合わせ、ユーザの情報を得る。

図８は、ポリシー管理サーバ１０２が検索ブローカ１０７に返送するポリシー情報（図１の２１１３）の一例を示す説明図である。

返送されるポリシー情報８００は、問い合わせ要求の中のサービス種別に対応するポリシー項目とポリシー条件を列挙したものとなる。図８の場合は、問い合わせ要求（図５）に対するポリシー情報の例であり、「観光ツアーサービス」というサービス種別（図５の５００）に対応するユーザのポリシー情報（「介護サービス」が「有り」、「格付け」が「ＡＡ以上」）が含まれる。

このように、検索ブローカ１０７は、ポリシーの問い合わせ要求（図１の２１１２、図５）に対する結果として、ユーザのポリシー情報（図１の２１１３、図８）を取得する。ポリシー情報を取得した検索ブローカ１０７は、次に要素サービスを提供する要素サービス提供サーバの情報をレジストリ管理サーバ１０８に問い合わせる。

図９は、検索ブローカ１０７からレジストリ管理サーバ１０８への要素サービス提供サーバの問い合わせのための電文（図１の２１１４）の一例を示す説明図である。

検索ブローカ１０７は、レジストリ管理サーバ１０８に送信したポリシー問い合わせ要求（図５参照）の結果として受け取ったポリシー情報（図８）から、サービスの種別９００を抽出し、問い合わせ電文を生成して、レジストリ管理サーバ１０８にサービスの問い合わせを行う。

図１０は、レジストリ管理サーバ１０８の詳細を示すブロック図である。

レジストリ管理サーバ１０８は、検索受付部１０００、レジストリ検索部１００１等を備えている。また、どの要素サービス提供サーバがどのサービスを提供しているのかを対応付けて保持するレジストリデータベース１０９が接続されている。

検索受付部１０００は、検索ブローカ１０７からの問い合わせ（検索要求）を受け付け、検索結果を返送する。レジストリ検索部１００１は、レジストリデータベース１０９に記憶されたデータ中から、検索要求された要素サービスを提供する要素サービス提供サーバを検索する。レジストリ管理サーバ１０８は、検索ブローカ１０７から送られた要素サービス提供サーバの検索依頼（図１の２１１４、図９）を受け付けると、サービス種別（図９の９００）を検索キーとしてレジストリデータベース１０９を検索する。検索した結果は検索ブローカ１０７に返送する。

図１１は、レジストリデータベース１０９に保持されている内容の一例を示す表である。

レジストリデータベース１０９には、サービス種別、要素サービス提供サーバ、サービス内容が列挙され、これらを組としたテーブルとして保持されている。サービス内容は、要素サービス提供サーバを呼び出すためのインターフェイス（Ｉ／Ｆ）やサービスの品質等が記録される。要素サービス提供サーバを呼び出すためのインターフェイスは、要素サービス提供サーバを実際に呼び出す際に必要な技術的なインターフェイスであり、例えば、ＵＲＬ（Uniform Resource Locator）やＷＳＤＬ（Web Service Description Language）が用いられる。サービスの品質は、例えば、格付け情報や介護サービスの有無等のサービスの付加情報に関する情報である。

図１２は、レジストリ管理サーバ１０８が検索ブローカ１０７に返送する要素サービス提供サーバ一覧の電文（図１の２１１５）の一例を示す説明図である。

レジストリ管理サーバ１０８は、検索ブローカ１０７から送られた要素サービス提供サーバの検索依頼（図９）のサービス種別（図９の９００）を検索キーとしてレジストリデータベース１０９を検索し、検索の結果、適合する要素サービス提供サーバの一覧の情報を列挙した電文を生成し、検索ブローカ１０７に送る。この電文には、要素サービス提供サーバの名前（１２００）、要素サービス提供サーバを呼び出すためのインターフェイスであるＵＲＬ情報（１２０１）、要素サービス提供サーバのサービス付加情報（１２０２、１２０３）が記載されている。

なお、実際に要素サービス提供サーバを呼び出すための技術的なインターフェイスとして、本実施の形態では、ＵＲＬを記述し利用しているが（１２０１）、これを、ＷＳＤＬデータを記述し利用してもよい。

検索ブローカ１０７は、要素サービス提供サーバ検索依頼（図１の２１１４、図９）に対する結果として、要素サービス提供サーバの一覧（図１の２１１５、図１２）を取得する。そして、検索ブローカ１０７は、前述のように、取得した要素サービス提供サーバ一覧から取得したポリシー情報に適合する要素サービス提供サーバを抽出する。

図１３は、検索ブローカ１０７が窓口サーバ１０１に返送する要素サービスの電文（図１の２１１６）の一例を示す説明図である。

この電文には、検索ブローカ１０７が、図１の２１１３で取得したユーザのポリシー情報は一切含まれず、検索ブローカ１０７が、図１の２１１５で取得した要素サービス提供サーバの情報（及び、そのＵＲＬ等の技術的なインターフェイス）のうち、ユーザのポリシーに適合するもののみが返送される。

検索ブローカ１０７から電文を受け取った窓口サーバ１０１は、電文の内容に従って、次段の要素サービス提供サーバである現地観光ツアーサービスα（要素サービス提供サーバ１０４）を呼び出す（図１の２１１７）。

要素サービス提供サーバ１０４は、前述のように窓口サーバ１０１と同様のステップにより、検索ブローカ１０７を利用して次段の要素サービス提供サーバを検索し呼び出す。この一連の処理によって、各要素サービス提供サーバは階層的に構成され、処理の結果が順次前段の要素サービス提供サーバに送られ、最終的に、窓口サーバ１０１に処理結果がまとめられて、ユーザに対して結果を送ることができる。

以上説明したように、本発明の第１の実施の形態では、検索ブローカ１０７が、ポリシー管理サーバ１０２にクライアントのポリシーを問い合わせて、クライアントのポリシーを取得し、さらに、レジストリ管理サーバ１０８にユーザが要求する要素サービス提供サーバを問い合わせて、要素サービス提供サーバの情報を取得する。検索ブローカ１０７は、この取得結果のうちポリシーに適合する要素サービス提供サーバのみを抽出して、窓口サーバ１０１に送る。以上の処理により、クライアントのポリシー情報を要素サービス検索要求元である窓口サーバ１０１に公開することなく、ユーザのポリシーを反映した形でサービスを動的に構成することが可能となる。

次に、第２の実施の形態について説明する。

第２の実施の形態は、レジストリデータベース１０９に保持される内容が、パブリックＵＤＤＩ（Universal Directory and Discovery Interface）のような、基本的な情報（Ｗｅｂサービスの技術的なインターフェイスやサービス提供会社の所在など）のみの場合について説明する。なお第１の実施の形態と同一の作用を行う構成には同一の符号を付し、その説明は省略する。

図１４は、本発明の第２の実施の形態の検索ブローカ１０７の詳細を示すブロック図である。

本実施の形態の検索ブローカ１０７は、前述した第１の実施の形態の構成（図４）に加え、付加情報管理サーバ１４０１とのインターフェイスである付加情報検索部１４００を備えている。そして、付加情報検索部１４００には、付加情報管理サーバ１４０１がネットワークを介して接続されており、付加情報管理サーバ１４０１には付加情報データベース１４０２が接続されている。

図１５は、レジストリデータベース１０９に保持されている内容の一例を示す表である。レジストリデータベース１０９には、パブリックＵＤＤＩに基づいて、要素サービス提供サーバを呼び出すための技術的なインターフェイス（例えば、ＵＲＬ）や、サービス提供会社の所在地（例えば、住所）などの標準的な内容のみが格納されている。この場合、このレジストリデータベース１０９には、ユーザの要求するポリシー情報に対応する条件が格納されていないので、レジストリデータベース１０９の内容にユーザのポリシーを適用することは困難である。そこで、ポリシー情報に対応するための要素サービス提供サーバの付加的な情報を格納した付加情報データベース１４０２を設け、検索ブローカ１０７を、付加情報データベース１４０２に接続された付加情報管理サーバ１４０１に接続する。

図１６は、付加情報データベース１４０２の内容の一例を示す表である。

付加情報データベース１４０２は、要素サービス提供サーバの付加的な情報である。本実施の形態における付加情報としては、例えば、格付け情報、介護サービスの有無等がある。この付加情報を要素サービス提供サーバと対応させて格納しておく。また、付加情報データベース１４０２は、付加情報管理サーバ１４０１によって管理されており、検索ブローカ１０７の要求に従って付加情報データベース１４０２の内容を検索する。

次に、第２の実施の形態の検索ブローカ１０７が、付加情報データベース１４０２を参照し、検索した結果を窓口サーバ１０１（又は要素サービス提供サーバ）に返送する処理を、図１４及び図１を参照して説明する。

検索ブローカ１０７は、窓口サーバ１０１（又は、要素サービス提供サーバ１０４）から検索要求（２１１１、又は、２１１８）を受け付けると、まず、ポリシー管理サーバ１０２にユーザのポリシー情報を問い合わせる（２１１２）。問い合わせ要求を受け付けたポリシー管理サーバ１０２は、ポリシーデータベース１０３からユーザのポリシー情報を取得し、その結果を検索ブローカ１０７に送る（２１１３）。

次に、検索ブローカ１０７は、レジストリ管理サーバ１０８に、窓口サーバ１０１の要求に適合する要素サービス提供サーバを問い合わせる（２１１４）。問い合わせを受け付けたレジストリ管理サーバ１０８は、レジストリデータベース１０９を検索して、要求に適合する要素サービス提供サーバの一覧を返送する（２１１５）。

次に、検索ブローカ１０７は、取得した要素サービス提供サーバ一覧（２１１５）に対応する付加的な情報を、付加情報管理サーバ１４０１に問い合わせる（２４０３）。問い合わせを受け付けた付加情報管理サーバ１４０１は、付加情報データベース１４０２を検索して、要素サービス提供サーバ一覧に対する付加情報を検索ブローカ１０７に返送する（２４０５）。

次に、検索ブローカ１０７は、取得した要素サービス提供サーバ一覧と、取得した要素サービス提供サーバの付加情報との組み合わせに対して、ポリシー管理サーバ１０２より取得したポリシー情報に適合する要素サービス提供サーバを抽出する。そして、抽出した要素サービス提供サーバ一覧を検索要求元である窓口サーバ１０１（又は、要素サービス提供サーバ１０４）に返送する（２１１６、又は、２１１９）。

以上説明したように、本発明の第２の実施の形態によれば、要素サービス提供サーバの付加的な情報を持つデータベース（付加情報データベース１４０２）を持つことによって、レジストリ管理サーバ１０８が、パブリックＵＤＤＩのように基本的な情報しか持っていない場合においても、ポリシーに基づく要素サービス提供サーバの選択を実現することができる。

次に、本発明の第３の実施の形態について説明する。

本発明の第３の実施の形態では、窓口サーバ１０１及び要素サービス提供サーバが、ポリシー情報により要素サービス提供サーバを選択して、処理を実行する。なお、第１又は第２の実施の形態と同一の作用を行う構成には同一の符号を付し、その説明は省略する。

図１７は、第３の実施の形態の窓口サーバ１０１の詳細を示すブロック図である。窓口サーバ１０１は、サーバポリシーデータベース１７０１にサーバのポリシーを送り、ポリシーを反映するサーバポリシー反映部１７００が備えられている。また、窓口サーバ１０１には、自身のポリシー情報を格納するサーバポリシーデータベース１７０１が接続されている。

図１８は、第３の実施の形態の要素サービス提供サーバ１８００の詳細を示すブロック図である。要素サービス提供サーバ１８００は、サーバポリシーデータベース１８０２にサーバのポリシーを送り、ポリシーを反映するサーバポリシー反映部１８０１が備えられている。また、要素サービス提供サーバ１８００には、自身のポリシー情報を格納するサーバポリシーデータベース１８０２が接続されている。

サーバポリシーデータベース（１７０１、１８０１）に格納されたサーバポリシーの内容は、要素サービス提供サーバを運営する会社のノウハウに相当する。例えば、包括契約により特定の系列のホテルは安く利用できる、特定の組み合わせで利用すると安くなるという内容や、利用したユーザによる評価である。

次に、第３の実施の形態の窓口サーバ１０１の、サーバポリシーを反映した要素サービスの呼び出しについて、図１７、図１８及び図１を参照して説明する。

まず、窓口サーバ１０１が、ユーザからの要求を受け付けると、検索ブローカ問い合わせ部２０４は、検索ブローカ１０７に要素サービス提供サーバの検索要求を行い（２１１１）、結果として要素サービス提供サーバの一覧を取得して返送する（２１１８）。

結果を受け取った検索ブローカ問い合わせ部２０４は、取得した要素サービス提供サーバの一覧に、自身が持つサーバポリシー情報を適用し最適な要素サービス提供サーバを選択する。すなわち、取得した要素サービス提供サーバに関する情報をサーバポリシーデータベース１７０１から取得し、取得した情報に基づいて、最適な要素サービス提供サーバを選択する。

次に、次段サービス呼び出し部２０３は、選択した要素サービス提供サーバを呼び出し、サービスの処理を依頼する（２１１７）。

なお、この処理は、要素サービス提供サーバ１０４等においても同一である。

以上説明したように、本発明の第３の実施の形態では、ユーザのポリシー情報とは別に、要素サービス提供サーバに関するポリシーを各要素サービス提供サーバ（又は、窓口サーバ１０１）に備えたので、要素サービス提供サーバ自身が持つノウハウを、要素サービス提供サーバ選択の指針として利用することができる。

次に、第４の実施の形態について説明する。

第４の実施の形態は、前述した第３の実施の形態のサーバポリシー情報を、ユーザの評価等によってフィードバックすることができるよう構成されている。なお、第１乃至第３の実施の形態と同一の作用を行う構成には同一の符号を付し、その説明は省略する。

図１９を参照して、第４の実施の形態の、サーバポリシー情報の自動拡充について説明する。サーバポリシー情報の自動拡充とは、要素サービス提供サーバ１８００が呼び出した次段の要素サービス提供サーバ１９００、１９０１が提供したサービスを、利用したユーザに評価してもらい、その結果をサーバポリシー情報として反映する機構である。このサーバポリシーの自動拡充によって、要素サービス提供サーバのノウハウの拡充を図ることができる。

要素サービス提供サーバ１８００は、前段の要素サービス提供サーバからの呼び出し（２９０６）によって、自身のサービスを処理すると共に、次段の要素サービス提供サーバ（要素サービス提供サーバ１９００、要素サービス提供サーバ１９０１）、を呼び出し（２９０２、２９０４）、サービスの実行結果（２９０３、２９０５）を受領する。そして、サービスの結果を、前段の要素サービス提供サーバに返送する（２９０７）。

その際に、要素サービス提供サーバ１８００が利用した次段の要素サービスに対する評価項目を合わせて返送する。すなわち、、バス運行サービス（要素サービス提供サーバ１９００）及びホテルサービス（要素サービス提供サーバ１９０１）を次段の要素サービスとして呼び出しており、このバス運行サービスとホテルサービスとに対する評価項目について、前段の要素サービス提供サーバに送る。

図２０は、この評価項目の一例を示す表である。

バス運行サービスに対する評価項目は、「バスの乗り心地」、「乗務員の態度」がそれぞれ５段階で評価され、ホテルサービスに対する評価項目は、「ホテル従業員のサービス」、「部屋の質」がそれぞれ５段階で評価される。

なお、評価項目は要素サービス提供サーバを運営する会社ごとに個別に定義することも、サービス種別ごとに定義することも可能である。また、評価方法としては図２０の例のようなＮ段階評価や、可否などの定式化できるものでもよいし、意見、要望などフリーフォーマットで記載してもよい。

この評価項目の内容は順次前段の要素サービス提供サーバに送られ、最終的に全ての評価項目が、窓口サーバ１０１に送られる。そして、ユーザがサービスの提供を受けた際に、全ての評価項目が窓口サーバ１０１からクライアント１００に送られ、ユーザに提示される。ユーザは提示された評価項目の評価を行う。

ユーザが評価を行うと、ユーザの評価は、窓口サーバ１０１及び要素サービス提供サーバに送られる。なお、この際に、末端となる要素サービス提供サーバには、ユーザの評価は送られず、要素サービスの呼び出しを行った側の要素サービス提供サーバにのみユーザの評価が返送される。ユーザ評価を受け取った窓口サーバ１０１又は要素サービス提供サーバ１８００は、サーバポリシー反映部（１７００、１８０１）によって、ユーザによる評価をサーバポリシーデータベース（１７０１、１８０２）に反映する。

このサーバポリシー反映部（１７００、１８０１）は、ユーザ毎に設定した信用度を用いて、信用度の高いユーザの場合には、ユーザの評価を自動的に反映し、信用度の低いユーザの場合は、サーバポリシー反映部（１７００、１８０１）がその旨をオペレータに通知し、オペレータを経由して、オペレータによって有効な評価か否かを取捨選択し、手動で反映させるようにしてもよい。なお、信用度は、例えば、利用頻度が高いユーザは信用度を高くするよう設定するとよい。

また、ユーザの評価が、意見、要望などのフリーフォーマット記載されている場合にもオペレータを経由して手動で反映する。

なお、本実施の形態において、サーバ側のポリシーを反映するにあたっては、必ずしも検索ブローカの機構は必要ではなく、ＵＤＤＩなどの一般的なのレジストリを利用する構成でも可能である。

以上説明したように、本発明の第４の実施の形態によれば、ユーザが受けたサービスに対する評価を、要素サービス提供サーバを運営する会社のポリシーデータベースにフィードバックさせることにより、要素サービス提供サーバを運営する会社のノウハウであるポリシー情報を、自動的に拡充、保守が可能となる。

本発明は、前述した実施の形態で説明した旅行代理店における予約サービスの他、次のようなビジネスモデルに適用できる。

（ａ）株式売買等で、ポートフォリオを作成するサービスを利用する場合に、銘柄に関するポリシーを予めポリシーデータベースに入力しておく。該ポリシーを適用してポートフォリオ作成サービスを呼び出すと、様々な信託会社や証券会社のサービスから、ポリシーに適合するサービスを選択して実行することで、ポリシーに適合したポートフォリオを作成することができる。

（ｂ）ネットワーク分散した計算サービスを利用する際に、予め計算を依頼するサービスに関するポリシー（計算の信頼度、計算の終了時間）を入力しておく。該ポリシーを適用して計算サービスを呼び出すと、ポリシーに適合するサービスだけを利用して計算が行われる。

（ｃ）製品の部品調達サービスを利用するときに、予め部品メーカーや部品販売店に関するポリシーを入力しておく。該ポリシーを適用して部品調達サービスを利用するときに、ポリシーにマッチする部品調達が行われる。部品を構成する部品についても階層的にサービスが構成されていれば、全ての部品についてポリシーを反映させることが可能となる。

（ｄ）人材バンクから人材確保サービスを利用するときに、予め人材に関するポリシーを入力しておくと、該ポリシーを適用して人材確保サービスを利用すると、該ポリシーに適合した所望の人材が確保できる。

（ｅ）会社組織に属する社員がサービスを利用するときに、予め社員のポリシーデータベースに組織が反映するようにしておく。該ポリシーを適用してサービスを利用すると、社員によるサービスの実行が組織のポリシーに違反することがないようにすることができる。

そして、本発明を前述したサービスに適用することで、ユーザのプライバシーを侵害せずにポリシーベースの柔軟なカスタマイズが実現できるため、競合他社に対する差別化が可能となる。この差別化により、代理店は競合他社と比較してユーザに対してサービス利用料を多めに取ることが可能となる。また、サービス利用料を同等とした場合、サービスの利便性からユーザ数が増えると考えられるので、代理店の利益率は向上すると考えられる。何れにしろ代理店はユーザからある程度のオプション料金を受け取ることができると考えられる。

一方、要素サービス提供会社は、ユーザ数が多ければ、自身の提供するサービスを利用してもらえる可能性が高いので、本発明の基盤上でサービスを提供したいと考えられる。その対価として代理店はポリシーサービス利用料を徴収することができる。

本発明の第１の実施の形態の、サービス提供システムの構成を示すブロック図である。 本発明の第１の実施の形態の、窓口サーバ１０１の詳細を示すブロック図である。 本発明の第１の実施の形態の、窓口サーバ１０１が検索ブローカ１０７に検索を依頼するための電文の一例を示す説明図である。 本発明の第１の実施の形態の、検索ブローカ１０７の詳細を示すブロック図である。 本発明の第１の実施の形態の、検索ブローカ１０７がポリシー管理サーバ１０２にポリシーの問い合わせを要求する電文の一例を示す説明図である。 本発明の第１の実施の形態の、ポリシー管理サーバ１０２の詳細を示すブロック図である。 本発明の第１の実施の形態の、ポリシーデータベース１０３に記録されている内容の一例を示す表である。 本発明の第１の実施の形態の、ポリシー管理サーバ１０２が検索ブローカ１０７に送るポリシー情報の一例を示す説明図である。 本発明の第１の実施の形態の、検索ブローカ１０７からレジストリ管理サーバ１０８への要素サービス提供サーバの問い合わせのための電文の一例を示す説明図である。 本発明の第１の実施の形態の、レジストリ管理サーバ１０８の詳細を示すブロック図である。 本発明の第１の実施の形態の、レジストリデータベース１０９に保持されている内容の一例を示す表である。 本発明の第１の実施の形態の、レジストリ管理サーバ１０８が検索ブローカ１０７に送る要素サービス提供サーバ一覧の電文の一例を示す説明図である。 本発明の第１の実施の形態の、検索ブローカ１０７が窓口サーバ１０１に送る要素サービスの電文の一例を示す説明図である。 本発明の第２の実施の形態の、検索ブローカ１０７の詳細を示すブロック図である。 本発明の第２の実施の形態の、レジストリデータベース１０９に保持されている内容の一例を示す表である。 本発明の第２の実施の形態の、付加情報データベース１４０２の内容の一例を示す表である。 本発明の第３の実施の形態の、窓口サーバ１０１の詳細を示すブロック図である。 本発明の第３の実施の形態の、要素サービス提供サーバ１８００の詳細を示すブロック図である。 本発明の第４の実施の形態の、要素サービス提供サーバを示すブロック図である。 本発明の第４の実施の形態の、評価項目の一例を示す表である。

符号の説明

１０１ 窓口サーバ
１０２ ポリシー管理サーバ
１０３ ポリシーデータベース
１０４、１０５、１０６、１８００、１９００、１９０１ 要素サービス提供サーバ
１０７ 検索ブローカ
１０８ レジストリ管理サーバ
１０９ レジストリデータベース
１４０１ 付加情報管理サーバ
１４０２ 付加情報データベース
１７０１、１８０２ サーバポリシーデータベース

Claims (4)

1. サービスを要求するクライアントと、前記クライアントからのサービスの要求の窓口となる窓口サーバと、階層的に構成されるサービスを提供するサーバと、前記クライアントが要求するサービスに対するポリシー情報を保持するポリシーデータベースと、前記サーバが提供するサービスの内容を保持するレジストリと、サービス検索要求に従ってサービスを提供するサーバを検索する検索ブローカと、に接続され、前記検索ブローカに対して行われる、サービスを提供するサーバの検索方法であって、
   前記窓口サーバは、下層のサーバを選択するための情報を格納する窓口サーバポリシーデータベースを備え、
   前記サーバは、下層のサーバを選択するための情報を格納するサーバポリシーデータベースを備え、
   前記窓口サーバが、前記クライアントからサービスの要求を受け付ける第１のステップと、
   前記窓口サーバが、前記検索ブローカに対して、前記要求されたサービスに適合するサーバの検索を要求する第２のステップと、
   前記窓口サーバが、前記要求されたサービスに適合するサーバの情報を前記検索ブローカから取得し、該サーバに対してサービスを要求する第３のステップと、
   前記窓口サーバからサービスの要求を受け付けたサーバが、要求されたサービスに適合するサーバの検索を前記検索ブローカに対して要求し、前記要求されたサービスに適合するサーバの情報を前記検索ブローカから取得し、該サーバに対してサービスを要求する第４のステップと、
   前記サーバが、前記第３又は第４のステップによって要求を受け付けたサービスの結果と共に、サービスを評価するための情報を、サービス要求元に送る第５のステップと、
   前記サーバが、前記サービスを評価するための情報に基づいて、前記クライアントによって行われた前記サーバのサービスの評価のうち、下層のサーバのサービスの評価を前記サーバポリシーデータベースに反映する第６のステップと、
   前記サーバが、前記クライアントに対して設定された信頼度と所定の基準値との比較結果に基づいて、前記サーバのサービスの評価を、前記窓口サーバポリシーデータベースに自動的に反映するか、前記窓口サーバポリシーデータベースに反映することをオペレータに問い合わせるか、を決定する第７のステップと、を有することを特徴とする検索方法。
2. 前記第３のステップは、要求されたサービスに適合するとして取得したサーバのうち、前記窓口サーバポリシーデータベースのポリシー情報に合致するサーバを抽出し、該抽出されたサーバに対してサービスを要求し、
   前記第４のステップは、要求されたサービスに適合するとして取得したサーバのうち、前記サーバポリシーデータベースのポリシー情報に合致するサーバを抽出し、該抽出されたサーバにサービスを要求することを特徴とする請求項１に記載の検索方法。
3. 前記窓口サーバは、サービスを要求した前記サーバからサービスの結果と共に、サービスを評価するための情報を受け取り、
   前記サービスを評価するための情報に基づいて、前記クライアントによって行われた前記サーバのサービスの評価を、前記窓口サーバポリシーデータベースに反映することを特徴とする請求項１に記載の検索方法。
4. 前記窓口サーバは、前記クライアントに対して設定された信頼度と所定の基準値との比較結果に基づいて、前記サーバのサービスの評価を、前記窓口サーバポリシーデータベースに自動的に反映するか、前記窓口サーバポリシーデータベースに反映することをオペレータに問い合わせるか、を決定することを特徴とする請求項３に記載の検索方法。

Images