(57)【特許請求の範囲】
【請求項１】
複数のサービスのそれぞれについて複数の条件を対応づけて記憶し、かつ、前記複数の条件のそれぞれについて少なくとも１の値を対応づけて記憶する第１のデータベースに対するクエリの送信を通じて発見されるサービス群から少なくとも１のサービスを選択する方法であって、
コンピュータのプロセッサが、前記第１のデータベースにより記憶される前記複数のサービスの中から、クエリに含まれる第１の条件と対応づけられた複数のサービスを選択する第１のステップと、
前記プロセッサが、前記選択された複数のサービスのいずれかが前記第１の条件とは異なる第２の条件とも対応づけられている場合に、当該第２の条件を新たな制約として前記クエリに自動的に追加する第２のステップと、
前記プロセッサが、前記第２の条件が追加された前記クエリに含まれる前記第２の条件に、第２のデータベースから読み出した値を割り当て、前記選択された複数のサービスの中から、当該値が対応づけられた第２の条件と対応づけられたサービスであって、そのサービスに対応づけられた第２の条件が前記第１のデータベースにおいて前記割り当てられた値に対応づけられているサービスをさらに選択する第３のステップと
を備え、
前記第１及び第２の条件のうち少なくとも１の条件に割り当てられる値は、ユーザのサービスに対する嗜好又はサービスに固有の情報を示す値であることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス群から少なくとも１のサービスを選択する方法に関し、特に、サービスを目録化し広告するネットワークノードに対するサービス記述（service description）の送信を通じて発見されるサービス群から少なくとも１のサービスを選択する方法に関する。
【背景技術】
【０００２】
本明細書内で理解されるサービスは、例えば、Ｗｅｂサービスプラットフォームや、さらには第三世代以上の移動通信環境のサービス提供プラットフォーム等のサービスの発見とサービスとのインタラクションをサポートするあらゆるサービスプラットフォームを通じて提供されるサービスに関する。さて、サービスの種類の増加を鑑みると、個々のタスクやニーズを満たす適切なサービスを選択する際にユーザがサポートを受けることは必要不可欠である。適切な機能を提供するサービスを選択することはもちろんであるが、ユーザは、各サービスが提供するオブジェクトや情報を考慮した上での何らかのサービスに対する嗜好も有している。
そのようなサービスの典型例は、標準のインタフェースと通信プロトコルを提供し効率的かつ効果的なサービスとインタラクションのを目指すインターネットベースで分散型かつモジュラー型のアプリケーション等のＷｅｂサービスである。典型的なＷｅｂサービスアプリケーションには、企業間統合（business-to-business integration）、ビジネスプロセス統合及び管理（business process integration and management）、リソーシング（re-sourcing）及びコンテンツ配信がある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、それぞれのサービスの選択方法では、サービス記述に限られた語義のみが用いられる、ＵＤＤＩ（UDDI Technical White Paper、http://www.uddi.org.）、ＷＳＤＬ（E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/2001/NOTE-wsdl-20010315, 2001）又はｅｂＸＭＬ（ebXML.ebXML Web Site. http://www.ebXML.org.）等の標準的な仕様が利用されている。ＵＤＤＩの仕様は、職業別電話帳と同様の方法で機能することを意図しているため、サービスの名称及び／又はサービスが提供する機能の簡単な分類によってサービスが検索される。
その他のサービス選択方法では、ＤＡＭＬ‐Ｓ（A. Ankolenkar, M. Burstein, J. R. Hobbs, O. Lassila, D. L. Martin, D. McDermott, S. A. McIlraith, S. Narayanan, M. Paolucci, T. R. Payne, and K. Sycara. DAML-S: Web Service Description for the Semantic Web. In Proc. Of Int. Semantic Web Conf. (ISWC’02, Sardinia, Italy, LNCS 2342, Springer, 2002)）又はＷＳＭＦ（D. Fensel and C. Bussler. The Web Service Modeling Framework WSMF. To appear in Electronic Commerce Research and Applications. http://www.cs.vu.nl/~dieter/wese/wsmf.paper.pdf）等のセマンティックＷｅｂが利用されている。これらは、意味的に豊富な（semantically enriched）サービス記述を可能ならしめようとする最初の試みである。しかし、これらのコンセプトはまだ、以下においてオントロジとも呼ぶ、ユーザ／サービスプロファイリングのための知識ベースの記述（knowledge-based description）や、ユーザの要望の嗜好ベースの表現、又は選択プロセスにおける協力支援等の利用といった個別化（personalization）の問題を扱っているわけではない。その上、人間とサービスの間のインタラクションにおける相互接続性という、ここでは欠落しているコンセプトにも、個別化の欠如により深刻な問題が生じてしまう。
【課題を解決するための手段】
【０００４】
以上で説明した事情を鑑み、本発明は、ユーザ中心の個別化されたサービスの選択をサポートすることを目的としている。
本発明によれば、この目的は、サービスを目録化し広告するネットワークノードに対するサービス記述の送信を通じて発見されるサービス群から少なくとも１のサービスを選択する方法により実現される。この方法の第１ステップでは、クエリタームにより表現されるサービス目的に従って前記サービス群からサービスが事前選択される。第２ステップでは、サービスユーザの嗜好を表現するサービスパラメータを用いて前記クエリタームが拡張される。第３ステップでは、前記事前選択されたサービスに対するサービス要求を提示しサービス提案を受けるために前記拡張されたクエリタームがインスタンス化される。
このように、本発明の重要な特徴は、２段階アプローチによるサービス選択を行う点である。この方法では、まず、抽象的でインスタンス化されていないクエリタームに基づいてサービスの事前選択が行われる。次に、前記クエリタームをインスタンス化する前に、サービスユーザの嗜好を表現するサービスパラメータを用いて前記クエリタームの拡張が行われる。尚、拡張を行う際には、事前選択されたサービスによりサポートされているサービスパラメータのみが考慮される。
そして最後のステップでは、事前選択されたサービス又はサービスカタログに対してサービス要求を提示するためにクエリタームのインスタンス化が行われる。サービス要求は処理されると、インスタンス化されたサービスパラメータがどのようにサポートされるかを示すサービス提案が返される。
【０００５】
本発明の重要な利点は、サービス要求が自動的に拡張され、典型的な利用パターンから導出されるユーザ固有のニーズや要求又は明示的に供給される値により当該サービス要求の充実が図られる点である。また、クエリタームに適合しないサービスはすぐさま破棄されるため、不必要なサービス要求の処理に係るオーバーヘッドを回避することができる。
従って、本発明によれば、所定のサービス目的を実現可能なサービスを提案するサイトを瞬時に制限することにより、増え続けるサービスの処理が著しく改善されるのである。すなわち、所望のサービス機能を有するサービスのみがサービスユーザの目的に対するその有用性をチェックされるのである。
また、抽象的なクエリタームを使用して事前選択を行い、さらに、拡張されインスタンス化されたクエリタームを使用して最終的な選択を行う２段階アプローチによれば、最終的に生成されるサービス提案と、所望の目的及び利益についてユーザにより提供される方針及び嗜好とを比較することが可能になる。
本発明のさらに別の重要な利点は、あらゆるタイプのサービス提供プラットフォームを含めどのような環境にも容易に適用が可能な点である。
このように、本発明は、競合する様々なサービスの中からサービスを選択し所定の目的を実現する上でサービスの選択及び構成に重要な役割を果たすサービス選択時の個別化をサポートしている。
また、本発明は、様々なサービスが桁違いに増加することが予想されサービスの有用性が重要な成功要因となる、サービスを提供するネットワークのシームレスな統合を見込んでいる。
また、本発明に係る選択メカニズムでは、実行コストのような単純なサービスの有用性の基準が考慮されるだけではなく、サービスにより提供されるオブジェクトや情報の有用性がユーザのニーズに照らして考慮される。言い換えると、本発明の焦点はサービスの利用それ自体ではなく、サービスユーザの目的を考慮したサービス選択時のサポートにある。
サービスユーザは積極的で高度かつ個別化された方法でサービスの実行に必要なすべての段階でサポートされるため、サービスの質が本質的に向上する。
【０００６】
本発明の好ましい実施形態によれば、クエリタームの拡張は自動的に、すなわち事前選択されたサービスのシグニチャパラメータのうちクエリターム以外のシグニチャパラメータが自動的に特定されることにより行われてもよいし、ユーザによる明示的な指示を受けて行われてもよい。
本発明は、自動的に行われるのであれユーザ主導で行われるのであれ、最もフレキシブルなサービス選択の個別化を完全にサポートする。
従って、本発明はサービスユーザのニーズに応じた個別化を完全にサポートする。サービスユーザは既知の利用パターンに基づいたサービス選択の自動的な個別化を選択してもよいし、サービス選択ごとに詳細に好みを選択したい場合にはサービス選択時におけるインタラクションを選択してもよい。
【０００７】
本発明のさらに別の好ましい実施形態によれば、ソフト制約パラメータが、サービスユーザプロファイル、ユーザの嗜好、サービス領域に関する情報から導出される値や、ユーザにより指定される値を用いてインスタンス化される。
本発明の当該実施形態は、企業間、ピアツーピア、消費者間でやりとりされる様々なタイプのサービスに対応するのに非常に適している。
また、当該実施形態によれば、集中型のネットワークやサービスであることや、有線電話、無線電話、無線携帯機器、インターネット接続のデスクトップコンピュータ、ノート型コンピュータ、無線ＬＡＮ接続機器、ポケットベル等の装置の種類や、従業員、是認者、プロジェクトチーム、旅行関係のサービス業等のエンドユーザの役割や、家族等の個人的な事情等が考慮されたユーザ嗜好の表現が可能となる。
このように、それぞれ異なるサービスシナリオに応じて、サービスユーザプロファイル、ユーザの嗜好及び／又はサービス領域に関する情報に基づいた個別化が図られ、事情に応じて特定の種類のサービスが選択される。
【０００８】
本発明のさらに別の好ましい実施形態によれば、サービス選択を終了させるためにサービス提案の評価が行われる。ここでサービスの評価とは、サービスの有用性（サービスの精度やサービスの信頼性等を加えてもよい）とサービスの実行コストの得失評価を意味する。
当該実施形態はサービス選択時における個別化とサービスユーザに対するサポートの点でさらに進んでいる。尚、有用性の基準は、本発明のフレームワーク全体において可能な範囲で自由に選択可能である。
サービスの評価に用いる有用性の基準の典型例としては、費用関数、サービス間の特徴の比較、時間に関連した特徴の考慮、利用パターン等がある。
【０００９】
本発明のさらに別の好ましい実施形態によれば、サービス提案が所定の基準を満たさない場合にユーザの嗜好に沿ってクエリタームの緩和が行われる。尚、この緩和は、クエリタームとなるハード制約及びソフト制約の両方に対して行われてもよく、また所定の順序に従って行われてもよい。サービスの事前選択及び選択はクエリタームを使用して繰り返し実行され、より緩和されたサービス提案が生成されることが好ましい。
当該実施形態は、サービス要求が具体的でない結果生ずる情報の洪水や、逆にサービス要求が具体的過ぎる結果何も提示されないという事態を回避するのに特に有用である。
また、サービス要求の緩和及び修正は、モバイルサービスユーザのローミング、サービスの利用可否の変化、ユーザの嗜好の変化等、サービスを提供する状況が激しく変化する場合に特に有効である。
【００１０】
本発明のさらに別の好ましい実施形態によれば、複合的なサービスについてはサービス目的分解を用いてサービスの選択が行われる。
具体的には、まず、複雑なサービス目的がより複雑性の低い複数のサービス下位目的に分解される。次に、各下位目的についてすでに概説したように少なくとも１のサービスが選択される。最後に、下位目的について選択されたサービスの組み合わせの評価が行われる。
複合的なサービスの処理は、集中型のサービスや第三者のアプリケーションプラットフォームインタフェース等の増大するサービスの多様性を鑑みると非常に有用である。従って、サービス目的の分解はユーザ中心のサービスを提供する上で非常に有用である。
例えば、サービスユーザは、出張の手配について関心を払っていたとしても、フライトの予約、空港までのレンタカーの手配、会議場へのルートの確認、両替施設の確認、そしてレストランの予約など全体的なサービス目的を実現するためにどのようなタイプのサブサービスが必要となるかについては関心を払わないかもしれない。
サービス目的分解は増大する多様なサービスを念頭においている。サービスユーザが適切な結果を得られるまであらゆるサービスの提案を考慮することができるためには、単一のサービスの選択をサポートするだけではなく、サービスユーザによる選択を可能とする複数のサービスの組み合わせを個別に提案するためにサービスの分解というタスクが本発明のフレームワークにおいてサポートされる必要がある。
尚、サービスの分解は、ユーザプロファイル、利用パターン、ユーザグループごとに定められる好適な分解方法、又は過去のインタラクションから導出されるサービス利用履歴すなわち長期的なプロファイルに基づいて行われてもよい。
【００１１】
本発明のさらに別の好ましい実施形態によれば、サービス選択及び／又は分解がサービスの階層に対して反復的に適用される。
当該実施形態はサービス選択対象を下降型で（in a top-down manner）構造化する際のモジュール性（modularity）をサポートしている。最終的な選択及び分解／構成結果の全体的な質を向上させるために各抽象レベルに対して段階的なアプローチを採ることでクエリタームもまた体系的かつモジュール方式で個別化されてもよい。
【００１２】
本発明のさらに別の好ましい実施形態によれば、サービス選択装置の内部メモリに対し直接読み込み可能なコンピュータプログラムプロダクトであって、当該サービス選択装置のプロセッサ上で前記プロダクトが実行された際に創造的なステップを実行するソフトウェアコード部を備えるコンピュータプログラムプロダクトが提供される。
従って、本発明に係る創造的なステップがコンピュータやプロセッサシステム上において実現可能となる。このコンピュータプログラムプロダクトは、コンピュータシステム、より具体的にはサービス選択装置等のプロセッサが内蔵されたコンピュータシステムにおいて使用されるために提供される。
この本発明の機能を定義するプログラムは、様々な形態でコンピュータ／プロセッサに提供することができる。例えば、プロセッサや入出力アタッチメントにより読み取り可能なＲＯＭやＣＤ‐ＲＯＭ等の読み出し専用記憶媒体の情報として記憶させて提供したり、フロッピーディスクやハードディスク・ドライブ等の書き込み可能な記憶媒体の情報として記憶させて提供したり、モデムやその他インタフェース機器を介しインターネットや電話網等の通信媒体を通じて提供することができる。尚、このような媒体もまた本発明の実施形態の一つである。
【発明を実施するための最良の形態】
【００１３】
本発明のベストモードであり且つ好ましい実施形態の説明において使用される用語は以下のように解釈するものとする。
【００１４】
制約（Constraint）： 各サービス又は提案される結果により満たされるべき一組のクエリ属性。制約はサービスインタフェースか或いはサービス出力に課せられる。
【００１５】
サービス：サービスは、他のサービスやエンドユーザとのインタラクションを意図されたソフトウェアオブジェクト又はネットワークエンティティであり、一定の機能又は一組の機能群を有している。また、サービスは明確なインタフェースを有している。
【００１６】
ハード制約（Hard Constraint）：厳格に守られるべき制約。
【００１７】
クエリターム：サービスカタログ又はサービス自体と通信するために使用される語句である。クエリタームはハード／ソフト制約としてユーザのニーズを表現する。クエリタームを表現するために、標準的なデータベースシステムで使用されているＳＱＬ（Structured Query Language）等のクエリ言語が定義、使用される。尚、クエリタームはセマンティックな記述を含んでもよい。
【００１８】
クエリ緩和／拡張：ソフト制約等の新たな制約を追加したり、所定の又は関連するユーザ嗜好に関するソフト／ハード制約を明示的に緩和することにより所与のクエリタームを再構成すること。
【００１９】
サービスカタログ：サービスは、専門のネットワークエンティティ／ノード、すなわちサービスカタログにより登録され自動的に広告されることでクライアントにより発見される。尚、カタログはネットワーク内の複数のノードに分散されてもよい。Ｗｅｂサービスでは、ＵＤＤＩリポジトリがカタログとして使用されることが多い。
【００２０】
セマンティックサービス記述（Semantic Service Description）：キーワードや、ＤＡＭＬ‐Ｓ、セマンティックＷｅｂ等のオントロジベースの記述などの、あるサービスの広告をセマンティックで有意味なものとする口語的に表されたサービスの特徴。
【００２１】
サービスインタフェース：シグニチャ（signature）又はシグニチャパラメータとも呼ばれるサービスパラメータのリスト。サービスインタフェースは、順序付けされたリストとして定義され、サービスの呼び出し前にインスタンス化される必要がある。
【００２２】
サービスシグニチャ（Service Signature）： シグニチャパラメータとも呼ばれる一組のサービスパラメータであり、順序付けて配列され、サービスの呼び出しのために所定のパラメータタイプに明確化される。サービスパラメータはサービスの呼び出し前にインスタンス化される必要がある。
【００２３】
サービス要求：クエリタームに応じてインスタンス化されたシグニチャパラメータのリスト。
【００２４】
ソフト制約（Soft Constraint）：ユーザ嗜好のように可能であれば守られるべき制約。
【００２５】
ユーザ嗜好（User Preference）：ユーザ嗜好はユーザの希望を表現するために使用され、具体的には、関連性のある用語間の半順序（「私はＡよりもＢが好きだ」や「私はＣよりもＡを好む」等）や、数的に表されるソフト制約（「サービスの価格を最小限にする」、「最も近いサービスを探す」、「最近のフライト予約日を確保する」等）として表現される。尚、ユーザ嗜好は、知識表現（knowledge representation）における一般的な技術を利用してセマンティックな形式で表現されてもよい。
【００２６】
Ｗｅｂサービス：Ｗｅｂサービスは、ＵＲＩ（Uniform Resource Identificator）により識別されるサービスであり、このインタフェースとバインディングはＸＭＬを用いて定義、記述される。Ｗｅｂサービスの定義は、例えば（集中管理された）サービスカタログ等の他のソフトウェアシステムにより理解することができる。ソフトウェアシステムは、インターネットプロトコルで伝達されるＸＭＬベースのメッセージに基づき、Ｗｅｂサービスの定義に定められる方法でＷｅｂサービスとインタラクションを行う。
【００２７】
図１は、本発明におけるサービスの提供を例示する概念図である。
同図に示されるように、又すでに概説したように、サービス１０は、ネットワーク１６において明確なインタフェース１４を介して提供される少なくとも１の機能１２を有している。このサービスと他のサービス又はサービスエンドユーザとのインタラクションは、当該サービスの提供形態、すなわちソフトウェアオブジェクトであるかネットワークエンティティであるか或いはこれらの組み合わせであるかにかかわらず、サービスの呼び出しに必要な情報の交換を可能とするサービスシグニチャを介して行われる。尚、本発明の適用対象は特定のタイプのネットワークに限られず、例えば移動通信網、インターネット、ローカルネットワーク、集中型ネットワーク、ヘテロジーニアスネットワーク、ピアツーピアネットワーク又はこれらのいかなる組み合わせに対しても適用可能である。
要するに、サービスパラメータ、すなわちシグニチャパラメータがインスタンス化された後で、サービス要求を介してサービスが呼び出されるのである。尚、本発明の適用対象は決して特定のタイプのサービスに限られるわけではないが、典型的なサービスの例は、Ｗｅｂサービスや、ｉ−ｍｏｄｅサービス、その他ＣＯＲＢＡ、ＪＩＮＩ、ＪＸＴＡ等の分散型サービスパラダイムである。
【００２８】
図１に示されるように、サービスカタログ１８はネットワーク１６において提供される様々なサービスの登録及び広告を行う。尚、サービスカタログはネットワーク内の複数のノードに分散されてもよい。サービスカタログ１６は、すでに概説したようなセマンティックサービス記述等の抽象化されたレベルのサービス記述を用いてサービスの広告及び宣伝を行う。
以上の記載から明らかなように、サービスユーザのためのサービスの選択は、抽象的なサービス記述とクエリタームによるサービス発見に基づいており、サービスユーザにより選択されたサービスの呼び出しには、サービスシグニチャのインスタンス化が必要となる。
以下に説明するように、本発明によれば、サービスの選択が抽象的なサービス記述だけではなく、ユーザの嗜好を考慮したサービス判定メカニズムに基づいて行われるため、サービス選択のためのメカニズムが著しく改善される。
【００２９】
図２は、本発明に係るサービス選択装置の概念図である。
同図に示されるように、サービス管理装置とも呼ばれるサービス選択装置２０は、サービスを目録化し広告するネットワークノードに対するサービス記述の送信を通じて発見されるサービス群から少なくとも１のサービスを選択する。
また、同図に示されるように、当該サービス選択装置は、サービス発見部２２（ユーザにより特定のサービスが選択されている場合のようにサービスが発見されている場合には任意）、サービス事前選択部２４、クエリ拡張部２６及びサービス選択部２８を備えている。これらサービス選択装置の各サブユニットはバス３０を介して情報のやりとりを行う。
【００３０】
図３は、図２に示されるサービス選択装置とそのサブユニットの動作のフローチャートである。
以下では図２に示されるサービス選択装置の動作について詳細に説明するが、本発明に係るサービス選択は、単にサービス選択に形式的なサービス記述を用い、サービスの機能の詳細な検討という負担をユーザに負わせるのではなく、サービス選択時にユーザの嗜好を考慮することでユーザの目的の達成をサポートするものである。
図３に示されるように、サービス発見部２２はステップＳ１０を実行し、サービスユーザにより考案、提供されるサービス目的に基本的に合致するサービスの候補群を発見、特定する。このステップＳ１０におけるサービス発見とは、サービスを目録化し広告するネットワークノードに対してサービス記述を送信することである。
図３に示されるように、サービス事前選択部２４はステップＳ１２を実行し、所定のサービス目的に従って、発見されたサービスの候補群からサービスの事前選択を行う。ここでサービス目的がクエリタームにより表現されると仮定すると、サービスの事前選択とは、提示されたクエリタームを含むクエリをサポートしないサービスを破棄することを意味する。
図３に示されるように、クエリ拡張部２６はステップＳ１４を実行し、サービスユーザの嗜好を表現するサービスパラメータに基づいてクエリタームの拡張を行う。ここでクエリタームの拡張とは、事前選択されたサービスのシグニチャパラメータのうちクエリターム以外のシグニチャパラメータをソフト制約パラメータとして認識することである。
図３に示されるように、サービス選択部２８はステップＳ１６を実行し、事前選択されたサービスへのサービス要求を提示しサービス提案を受けるために、拡張されたクエリタームのインスタンス化を行う。サービス提案はユーザの嗜好を考慮して生成されるため、非常に効率的にユーザ目的の達成をサポートすることができる。
以上の記載から明らかなように、サービス選択の際にユーザの嗜好に基づいてクエリタームが拡張されるため、不適当なサービスが除外され選択の質が向上する。尚、シグニチャパラメータに基づく個別のサービス選択には、利用可能なサービスに対して適切なクエリタームを発見することを目的とする協調検索技術（cooperative retrieval technique）等の選択肢がある。
【００３１】
以下においてより詳細に説明するように、サービスユーザは、クエリタームの中で除外してはいけない制約や、除外してもよい制約、そして制約が除外される順序を自由に決定することができる。ここで、サービスユーザがセマンティックサービス記述から制約を除外するということは、ユーザがそのサービス特性を要求していないことを意味している。
サービスを選択するにあたり利用可能なサービスが数多く存在する場合には、ユーザプロファイルから長期間にわたり収集された嗜好や、直接ユーザにより指定された嗜好をソフト制約として表現してもよい。ソフト制約は、ハード制約と異なり、クエリタームが具体的すぎる結果として適切なサービス提案に至らない場合には緩和することができる。
図３に示されるように、サービス選択部３０は、最後にステップＳ１８を実行し、デジタルサービスの評価を行い、任意で選択されたデジタルサービスの呼び出しを行う。ここでデジタルサービスの評価とは、サービスの実行コストを考慮してサービスの有用性を検討することである。尚、本発明のサービス選択フレームワークには、サービスユーザに対するサービスの価値を表す関数として例えば費用関数、重み付き費用関数（weighted cost function）効用関数を適用する等、いかなるタイプの評価方法も適用可能である。
【００３２】
図４は、図２に示されるサービス選択装置のさらに詳細な概念図である。
同図に示されるように、サービス発見部２２は、セマンティック記述部３２とサービス目的分解部３４とを備えている。クエリ拡張部２６は、ソフト制約部３６とユーザインタフェース部３８とを備えている。サービス選択部２８は、インスタンス化部４０とサービス評価部４２とサービス提案表示部４４とクエリターム緩和部４６とを備えている。サービス選択装置は、さらにユーザ嗜好データベース４８と制御部５０とを備えている。
セマンティックサービス記述部３２は、セマンティックサービス記述を生成するためにサービス目的の受信及び処理を行う。この生成されたセマンティックサービス記述に基づいて、サービスカタログの関与の下サービス発見が行われる。
サービス目的分解部３４は、複雑なサービス目的を、より容易に達成可能な複数の下位目的に分解することにより、適切なセマンティックサービス記述を準備するサービス記述部をサポートする。
このサービス目的の分解によれば、例えば出張旅行というサービス目的は、移動、宿泊施設、会合場所の手配といった下位目的に分解される。
サービス目的分解部３４は、サービス目的の分解を行うにあたり、サービスユーザプロファイル情報、ユーザの嗜好、サービス領域に関する情報等を記憶しているユーザ嗜好データベース４８にアクセスすることができる。サービス目的分解の方法を示す利用パターンはユーザのグループごとにグループ化してもよい。サービス目的分解部は、利用可能なサービスとユーザ固有の情報に応じて下位目的の生成を行い、生成された下位目的をセマンティック記述部３２へ送る。
また、サービス目的分解部３４は、各下位目的に対して提供されるサービスの組み合わせの評価を可能とするために下位目的間の関係をモデル化する。下位目的間の関係は、例えばグラフ表現によりモデル化されうる。この場合、各下位目的はグラフのノードとして表され、下位目的を実現する各サービスは、当該サービスを呼び出す前に実現されるべき下位目的を表すノードから当該サービスによって実現される下位目的を表すノードに至る有向辺として表される。
【００３３】
次にクエリ拡張部２６の各サブユニットについて図４を参照して説明する。
ソフト制約部３６は、一組の事前選択されたサービスとそのシグニチャパラメータを受け取り、例えば事前選択された各サービスのシグニチャパラメータと当該サービスの発見に使用したクエリタームとの間の差異のように、事前選択されたサービスのシグニチャパラメータのうちクエリターム以外のシグニチャパラメータをソフト制約パラメータとして自動的に認識する。
インタフェース部３８は、サービスユーザによるシグニチャパラメータの入力をソフト制約として受け付ける。尚、インタフェース部３８は、サービス選択時の個別化の程度をさらに改善するためにソフト制約部３６とともに動作してもよい。
【００３４】
次にサービス選択部２８の各サブユニットについて図４を参照して説明する。
インスタンス化部４０は、サービスに対して提示するためにクエリタームのシグニチャパラメータに値を割り当てる。インスタンス化され提示されたシグニチャパラメータは処理されると、サービス提案を送出するために、インスタンス化されて具体化された値に基づいてサービスの利用可能性が評価される。
すなわち、サービスが、目的地までの直行便のようなある特定のユーザの目的を実現する機能を有しているか否かや、そのようなユーザ目的が、ある特定の日の目的地までの直行便の利用可能性のようにより詳細に定義された後でも本当に実現されうるか否かは影響を及ぼすのである。
また、インスタンス化部４０は、クエリタームのシグニチャパラメータをインスタンス化するだけでなく、例えばユーザ嗜好データベース４５の情報を考慮しつつソフト制約パラメータのインスタンス化も行う。従って、サービス選択の際には、ハード制約のみならずユーザの嗜好を表現するソフト制約も考慮される。
上記のように、自動的に生成されるにしろユーザによるものにしろソフト制約の追加とそれに続くインスタンス化はサービス選択時にユーザをサポートする上で必要不可欠である。特に、クエリパラメータがインスタンス化される際に、利用パターン、推定されるユーザの意図、利用方法についてのステレオタイプ等が考慮されることで効率的な個別化されたサービス提案の生成が可能となる。
生成されたサービス提案にサービス目的又はサービス下位目的を実現する複数の候補が含まれていると仮定すると、どのサービスを実際に呼び出すかという最終判断が行われる。
【００３５】
図４に示されるサービス評価部４２はサービス提案の評価を行う。ここでサービスの評価とは一般的にサービスの有用性とサービスの呼び出しコストとの間の得失評価を意味する。有用性の典型例は、信頼性、実行時間、実現可能なサービスの質であり、コストの典型例は、サービスプロバイダに請求される費用や通信費等であるが、本発明に適用される有用性及びコストの基準はこれらに限定されるものではない。
尚、最初のサービス目的が、すでに概説したようにグラフ表現によりされる複数の下位目的に分解されていると仮定した場合には、サービス評価部４２はサービスの評価を行うために有用性の値とコスト値を割り当て、例えばパスメトリックの計算に基づいてサービスの組み合わせの評価を行う。
尚、サービス提案からサービスが自動的に選択されるのではなく、サービスユーザによってサービスが選択されてもよい。この場合、サービス提案表示部４４がサービスの特徴とともにサービス提案を表示し、サービスユーザによる選択によってサービス選択プロセスは終了する。
【００３６】
次に本発明の重要な特徴の一つであるクエリターム拡張／緩和について説明する。
すでに概説したように、クエリ緩和／拡張とは、ソフト制約等の新たな制約を追加したり、所定の又は関連するユーザ嗜好に関するソフト／ハード制約を明示的に緩和することにより所与のクエリタームを再構成することである。
クエリターム拡張／緩和部４６は、提案されるサービスの効果によって実現されるべきクエリ属性の変更を行う。ここでサービスの性能に対する制約は、サービスインタフェースか又はサービスの効果に対して課せられる。
尚、拡張／緩和されたクエリタームを使用して反復的にサービス選択プロセスを実行する前に、既知のユーザ嗜好や利用パターン等や、ユーザとのインタラクションを考慮してサービスの拡張／緩和を行ってもよい。
【００３７】
次に、図４に示される制御部５０により制御されるサービス選択装置の動作の全体的な流れについて図５及び６を参照して説明する。
図５に示されるように、まず始めに、ステップＳ１０〜Ｓ１８を通してすでに概説したようにサービス提案が生成される。そしてステップＳ２０において、生成されたサービス提案が、サービス提案の自動評価を鑑みた場合に所定の基準を満たしているか、又はサービスユーザに示される所定の基準を満たしているかが判定される。この判定の結果が肯定的な場合にはサービス選択プロセスは終了する。一方、否定的な場合にはステップＳ２２が実行され、クエリタームの拡張／緩和が行われる。続いてステップＳ１０〜Ｓ１８が再び実行され修正されたサービス提案が生成される。このサービス提案の生成は、所定のサービス基準が満たされるか又はサービス提案の生成の反復回数が上限値に達するまで繰り返される。
【００３８】
サービス目的の分解により複数のサービスの組み合わせが提案された場合には、図６に示されるように、図５を参照して説明したサービス選択プロセスが各下位目的について反復的に実行される。
図６に示されるように、ステップ２４が実行されるとすでに概説したようにサービス目的が複数のサービス下位目的に分解される。次に、図５に示されるステップＳ１０〜Ｓ１８に対応するステップＳ２８が実行されると各下位目的に対して少なくとも１のサービスが選択される。このステップＳ２６の結果に基づきステップＳ２８が実行されると各下位目的に対して選択されたサービスの組み合わせの評価が行われる。
次に本発明の重要な特徴の一つである、サービス抽象（service abstraction）の複数の階層に対する本発明に係るサービス選択の反復的な適用について説明する。
図７に示されるように、サービス目的分解とサービス選択プロセスが反復的に適用されるとより具体的なサービスとなる。サービス目的の分解は必要に応じて行われ各階層ごとにサービス提案が生成される。
以上、本発明の様々な特徴と好ましい実施形態について説明してきたが、以下では本発明の基本的概念についてサービス選択の例を挙げて説明する。
【００３９】
ここで、マイケルという名前のユーザの存在を仮定する。彼はロサンゼルスの企業に勤め、ある特定の日にボストンで行われるビジネス会議に出席しなければならない。そのために必要なすべての準備を行うことは複雑な作業であり、適切なサービスを見つけるには非常に時間がかかる。特に、マイケルのタスクにとって適切でないサービスに対してまで個人的な要求や好みを提示することは非常に冗漫である。
上記のタスクには、必ずしも以下のものに限定されるわけではないが、大まかに言うと必要な移動手段の手配と、宿泊施設やレストランの予約と、ビジネス会議の時間と場所の設定とが含まれる。マイケルの好みによっては、接待の手配やスポーツ関連の娯楽、観光の発見等のその他のタスクも含まれる可能性がある。
すでに概説したように、タスクに適切なサービスが発見された後もマイケルは彼の個人的なニーズに最適な単一サービス又は複数のサービスの組み合わせについて対処しなければならない。しかし、増大するサービスの多様性を鑑みると、適切な結果を得るためにマイケルがすべてのサービス提案を閲覧することは期待できない。そこで、サービス目的分解とサービス選択のタスクがサポートされ、一組の利用可能なサービスか又はマイケルによる最終的な選択を可能とする複数のサービスの組み合わせが提供される。
【００４０】
図８は、マイケルのサービス目的、すなわちボストンへの出張の手配がサービス目的である場合のサービス目的分解の例を示している。
一般的に、サービスは、セマンティックＷｅｂ上で簡単なキーワード検索を行うことで発見されることが多いが、複数のサービスの組み合わせの発見は、本発明に係るサービス目的分解というコンセプトが既述のように導入されないと困難である。サービスの多様性や独立性のために、既存のモデルを用いてサービスの組み合わせを構成及び調整することは不可能である。
図８に示されるように、サービス目的を分解する際にはサービスユーザの個別性が特に考慮されなければならない。出発地点と会議場に応じて、サービス目的を実現する方法が複数考えられ、これらの方法には様々なサービスが含まれうる。
例えば、仮に出張に長距離の移動が伴う場合には、フライトを予約するサービスが含まれる可能性がある。しかし一方で、列車による移動を好むマイケルの嗜好に従ってサービスが選択されてもよい。
航空機は２つの空港の間の移動手段にすぎず、出張の手配というサービス目的は、例えば、利用可能な移動手段又は出発地点、到着地点として最も便利な２つの空港の発見、オフィス又はアパートから空港までの移動手段、選択された空港へのフライトの予約、空港から出張先又は会議場への移動手段に最終的に分解される。
【００４１】
図８に示されるように、又すでに概説しているように、サービス目的分解は有向グラフとして表すことができる。このサービス目的分解を経て、フライト予約サービスや列車予約サービス等のサービスがすでに概説しているように発見、選択される。
オフィスから空港までの移動手段はタクシー又は公共の交通手段に分解することが可能であり、この公共の交通手段はバス又は地下鉄に分解することができる。目的地の空港から出張先までの移動手段は単純にタクシーでもよいしレンタカーのような複雑なタスクを伴うものでもよい。通常このように複雑なタスクは複数のサブサービスにさらに分解されることになる。図８に示される例では、１２の異なる出張方法が示されている。
マイケルの出張の編成方法は、時間及び場所的な制約ごとに分類される彼の利用パターンに基づいて決定される。例えば、仮にマイケルが航空機を利用しかつ空港まで地下鉄を利用する場合には、空港まで至る路線が選択される必要があり、またフライトについては、搭乗手続きための時間を確保するために列車が空港に到着後しばらくしてから出発するものが選択される必要がある。
【００４２】
サービス目的分解にはこれという専用のアプローチは存在しないが、旅行会社等ではサービス目的分解に何らかの利用パターンやヒューリスティックスを用いている。例えば、彼らはまず旅行の距離や期間のような一般的なアプローチからスタートして適切な移動手段の選択やホテルの予約が必要であるか否かの判断を行い、その後で細部を詰めるのである。
サービスを設計する際には、サービスによりどのような機能が提供されるかが理解され考慮される。サービスの利用形態には様々な可能性があるが、典型的なクエリやサービス要求にはそのためのサービス目的分解の方法が存在する。このユーザグループごとに異なる典型的なサービスとのインタラクションは利用パターンと呼ばれる。この利用パターンはユーザの意図ごとに異なり、意図が異なれば異なる利用パターンが必要となる。
すでに概説したように、各ユーザグループはサービス目的の実現に関して何らかの典型的な方針を有しているため、各ユーザグループはそれぞれ別の利用パターンが割り当てられる。
例えば、出発地点及び目的地まで移動するためのサービスは常に必要でありこれらは利用方法により異なるが、サービスは常に列車の利用か又はフライトの予約に分解されることになる。一般的に列車は航空機よりも移動時間が長いが運賃は安価である。
ここでユーザグループを２つのグループに分類する場合、簡単なサービス目的分解の方針を割り当てることができる。例えば、金銭よりも時間の方がより重要なビジネス旅行者には、列車の利用は避けビジネスクラスの予約を行い、フライト時間を最小限にし、飛行機の乗り換えを避けるというようなビジネス旅行者向けのサービス分解パターンをデフォルトとして設定することができる。
【００４３】
サービス領域に関する情報もまた考慮される。例えば、出張旅行にとって到着時間等の制約を緩和することは旅行者について緩和するよりも難しい。典型的な旅行者向けの利用パターンでは金額により関心が向けられコストを最小限にするように設計される。従って、この場合では、列車の利用が適切な選択であり、ビジネスクラスでのフライトは望ましいものではない。
このように、利用パターンは、サービス目的を分解するためにユーザが適用する様々な方法の一表現と見ることができる。サービス下位目的への分解は、全体的なサービス目的を実現するサービス群の選択に直接的な影響を及ぼす。
【００４４】
ここで再びマイケルのケースに話を戻すと、ボストンの空港から出張先への移動は様々なサービス下位目的に分解することができる。空港でレンタカーを借りことも可能であるし、タクシー又は公共の交通手段を利用することも可能である。どのように分解されるかはユーザにかかっており、すなわち分解方法についての好悪という個別的な嗜好に基づいて個別的に決定されるのである。
尚、この分解方法についての好悪は一般的な利用パターンよりも優先的に考慮されることになる。例えば、サービスユーザが飛行機を利用することに恐怖を感じる場合には、たとえ彼が迅速な移動を好むビジネス旅行向けの利用パターンに該当したしても彼の個人的なプロファイルには彼が飛行機の利用を望まないことが記録されることになる。この場合、具体的なプロファイルは一般的なプロファイルよりも優先的に考慮されることになる。
【００４５】
図９は、例えば図８に示されるようにサービス分解が行われた場合のフライトの予約のようにサービス目的分解を経たサービス選択の一例を示している。
サービス選択時には、サービス（下位）目的を実現すると広告される、ハード制約をサポートするサービスが選択されるが、選択されるサービスの実行コスト等のパラメータはそれぞれ異なっている場合がある。そこで、本発明では、すでに概説しているように、サービスにより提供されるオブジェクトや情報について好ましいサービス特性をサービス選択時に追加することができる。
このため、以下で説明するサービス選択例から明らかなように、複数のサービスの中からサービスを選択することや、サービス（下位）目的を実現可能であるがユーザの嗜好に沿う好ましいサービス特性を有しないサービスを破棄することが容易になる。従って、本発明に係るサービス選択方法は、サービスユーザ固有の要求や要望に基づいてサービス要求を拡張することを特徴としている。所定のプロファイルに適合しないサービスはすぐさま破棄され、同程度に有用なサービス同士はユーザの方針に照らして比較される。協調的応答（cooperative answering）の技術を利用することにより、全くサービスが提示されないという事態を回避し、且つサービスユーザの長期的なプロファイルを考慮したより優れたサービス選択が可能になる。
【００４６】
図８に示される例においてマイケルがフライトを予約することを決定したと仮定する。
まず、フライトの予約というサービス目的を実現可能なサービスの候補が発見される必要がある。会議が１１月１０日の午後３時から開始されると仮定すると、出張先に向かう時間を考慮してマイケルは正午までに空港に到着する必要がある。さらにマイケルがビジネスクラスを希望していると仮定すると、彼の目的を表現するＳＱＬタイプのクエリは例えば次のように表される。
0004759269.tif 000002
【００４７】
そして下表に示す４つのサービスが発見されているものとする（図３及び図５のステップＳ１０参照）。
0004759269.tif 000003
【００４８】
次のステップでは、マイケルのハード制約をサポートするためにどのパラメータが必要であるかが確認される（図３及び図５のステップＳ１２参照）。
上記サービスクエリでは、出発地点、到着地点、到着日時、クラスが指定されているため、ビジネスクラスを利用できないエコノミーの空の旅がすぐさま破棄される。
次のステップでは、サービスのパラメータのうちハード制約以外のパラメータの確認が行われる（図３及び図５のステップＳ１４参照）。図９に示される例では、出発日時、航空会社、価格及び直行便が当該パラメータに該当する。
次のステップでは、マイケルの長期的なプロファイルに基づいてこれらの付加的なパラメータについての彼の嗜好が確認される（図３及び図５のステップＳ１６参照）。この結果、マイケルがデルタ航空を通常利用し、直行便を好むことが分かったと仮定する。また、フライト予約サービスの分野における一般的な嗜好も考慮されてもよい。例えば、移動時間が短い方が好まれる、すなわち到着日時に最も近い出発日時がより好まれるといった情報である。尚、この出張旅行の場合、好ましい価格については情報が与えられていないので、価格を示すシグニチャパラメータのインスタンス化は行われない。
【００４９】
次のステップでは、事前選択されたサービスに対して次のようにクエリの拡張が行われる（図３及び図５のステップＳ２０参照）。
0004759269.tif 000004
【００５０】
事前選択されたサービスに対して上記の拡張されたクエリが提示される結果、下表のようにサービス提案がなされるとする。
0004759269.tif 000005
尚、上記サービスの中には航空会社についての問い合わせが行われていないものもあるが、すべてのサービスがサービス提案において航空会社を提示できるものとする。簡単フライト予約サービスからは２つのフライトが提案されており、このうちＤ７６５は直行便であり、ＬＨ７３７は出発地点と到着日時の点で優れている。
【００５１】
サービス評価ステップが実行されると（図３及び図５のステップＳ１８参照）、簡単フライト予約のＤ７６５が航空会社と直行便の２つのソフト制約パラメータが最適であるため、この簡単フライト予約のＤ７６５が本発明に係るサービス選択の結果として提案されることになる。
尚、サービスの評価にその他の適切な方法を用いてもよく、例えばマイケルは移動時間が短いことを強く要求してもよい。また、サービスの評価を行わずにサービス選択を終了し、最終的にマイケルがサービスを決定してもよい。
一方、仮に1件もサービスが発見されなかった場合には、マイケルはクエリターム中のハード／ソフト制約を再検討する必要がある（図５のステップＳ２０及びＳ２２参照）。例えば、ビジネスクラスという制約を解除する必要があるかもしれない。
図５に示されるように、サービス選択がもう一度行われる場合には、以前に破棄されたエコノミーの空の旅もまた再び検討される必要がある。
【００５２】
以下では本願発明に係るさらに別のサービス選択例について説明する。
上述のサービス選択例のシナリオに引き続き、マイケルが例えば会議の後にボストンでレストランを予約したいと考えたと仮定する。また、マイケルは中国料理を提供する地元のレストランに決め、自身のＰＤＡ又は携帯電話を使って適当なサービスを発見するものとする。会議は午後７時に終わるものとし、彼はレストランに行くまでの時間を考慮して午後８時から席を予約したいと考えるものとする。また、彼はビジネス向きのレストランを予約したいと考えるものとする。このような彼の目的を表現するＳＱＬタイプのクエリは例えば次のように表される。
0004759269.tif 000006
【００５３】
そして下表に示す４つのサービスが発見されているものとする（図３及び図５のステップＳ１０参照）。
0004759269.tif 000007
上記のクエリにおいてＷｈｅｒｅ句に指定されたクエリタームはすべてハード制約である（図３及び図５のステップＳ１２参照）。すなわちマイケルは、この時点では別の日で予約することもビジネスパートナーをカジュアルスタイルのレストランでもてなすことも考えていない。
上記のクエリでは、予約日、予約時間及びカテゴリが指定されているため、カテゴリのシグニチャパラメータが提示されていないお持ち帰り四川料理はすぐさま破棄される。
このように、本発明に係る協調的サービス選択アルゴリズムでは、適切なサービスの選択に必要なプロセスが実行され、質の高い選択結果を得ることができる。ここで、例えばＷｅｂサービスにより管理可能なサービス目的が与えられたと仮定する。尚、長期的なユーザプロファイル及び／又は当該サービス分野における一般的な知識や一般的な語彙も考慮されてもよい。
【００５４】
次のステップでは、サービスのパラメータのうちハード制約以外のパラメータの確認が行われ（図３及び図５のステップＳ１４参照）、当該パラメータとして味、禁煙及び価格帯のシグニチャパラメータが特定される。そして次に、マイケルのＰＤＡ又は携帯電話に記憶された彼の長期的なプロファイルに基づいてこれらの付加的なパラメータについての彼の嗜好が確認される。
この結果、マイケルが通常ビジネスパートナーを高価なレストランに連れて行くことを好み、さらに彼は禁煙席を好むことが分かったと仮定する。また、当該サービス分野における一般的な嗜好も考慮されてもよい。例えば、誰もが指定した時間に近い予約時間を確保したい、すなわち指定した予約時間からの遅れが極力少ない予約時間を確保したいと考えるといった情報である。尚、このビジネスディナーの場合、好ましい味については情報が与えられていない。
【００５５】
次のステップでは、各サービスに対してクエリタームの拡張が行われ、拡張されたクエリタームがインスタンス化される（図３及び図５のステップＳ１６参照）。仮にdeclarative notionを用いた場合には、各レストランサービスに対して次の３つのインスタンス化されたクエリタームが提示される。
0004759269.tif 000008
【００５６】
以下のテーブルは提案されるサービスの一例を示している。
0004759269.tif 000009
上表に示されるように、各レストランサービスから、マイケルのハード制約と、ソフト制約として表現される嗜好とをサポートする最良のサービスが提示されている。尚、上記のクエリではレストランサービスに対して評価の問い合わせは行われていないが、サービスのいくつかはサービス提案において評価を提示できるものとする。
【００５７】
次のステップでは、提示されたサービス提案の評価が行われる（図３及び図５のステップＳ１８参照）。
お薦め広東料理サービスからは２つの予約案が提示されており、このうち一方は禁煙席であり、他方は予約時間の点で優れている。いずれの特徴もソフト制約であり、またマイケルにより互いの優劣が指定されていないため、いずれのサービス提案も同程度に良いものであると見なされる。
ウォンのグリルは、あらゆる点において例えば山東宿屋の予約案に劣っているため破棄される。
これ以上の絞り込みは自動的に行われなくともよい。これは、マイケルが禁煙席を強く要求したり、あるいは評価等の全く新しい特徴を考慮して最終的な判断を下す可能性があるためである。その他既知の方法を含めあらゆる適切なサービス評価方法が用いられてよい。仮にマイケルが常に予約時間を重要視するようであれば、この場合、山東宿屋が全体として最良の提案となる。また、サービスの評価を行わずにサービス選択を終了し、最終的にマイケルがサービスを決定してもよい。
一方、仮に１件もサービスが発見されなかった場合には、マイケルはクエリターム中のハード／ソフト制約を再検討する必要がある（図５のステップＳ２０及びＳ２２参照）。
仮にビジネスカテゴリという制約をマイケルが解除したとすると、サービス選択がもう一度行われる。この場合、以前に破棄されたお持ち帰り四川料理もまた再び検討される必要がある。
以上より明らかなように、サービスユーザは容易にソフト制約パラメータを使用することができ、また緩和の順序を決定することができる。ソフト制約はサービス要求をより具体化するために設定され、一般的な長期的嗜好よりも具体的でありこれと対立しさえする。そのため、ハード制約よりも後であり、かつクエリが長期的なユーザプロファイルから導出されるタームにより拡張される前にその判断が行われる必要がある。
【００５８】
図１０は、本発明に係るサービス選択をサポートするＷｅｂサービスを提供する方法を示している。
同図に示されるように、本発明は、サービス記述の改良への複数の既存のアプローチと組み合わせて適用してもよい。
サービスの発見は、ＵＤＤＩ（Universal Description, Discovery, and Integration）をＷｅｂサービスのオンラインレジストリの方法に利用して実現してもよい。代替手段としては、ＸＭＬベースの言語仕様であるＷＳＤＬ（Web Service Description Language）や、
ＳＯＡＰ（Simple Object Access Protocol）、サービス要求とサービス記述との比較を行うＥ‐Ｓｐｅａｋ、及び／又はワークフローの観点からサービス記述を提供するｅｂＸＭＬがある。
【００５９】
図１１は、本発明に係るサービス選択をサポートするセマンティックＷｅｂサービスを提供する方法を示している。
ＤＡＭＬ‐Ｓは、Ｗｅｂサービスを記述するためのオントロジベースのアプローチであり、サービスの共通のオントロジを提供することを目的としている。ＤＡＭＬ‐Ｓは、ＤＡＭＬ＋ＯＩＬ（ D. Connolly et al. DAML+OIL Reference Description, W3C note, December 2001）をベースにしており、セマンティックＷｅｂマークアップ言語に対して階層化アプローチをとっている。またＤＡＭＬ‐Ｓは、エージェント及びユーザがＷｅｂサービスの発見、呼び出し及び構成を行うことが可能となるオントロジの提供を目的としている。ＤＡＭＬ‐Ｓオントロジは３つの部分から構成され、具体的には、サービスの広告及び発見のためのサービスプロファイルと、サービスのプロセスを詳細に記述するプロセスモデルと、メッセージ交換を通じてサービスとどのように相互動作するかを詳細に記述するサービス接地（service grounding）から構成される。
図１１に示されるように、セマンティックＷｅｂの発見に用いられる代替手段としては、サービスモデルとともにサービスのプレコンディショニング及びポストコンディショニングについて記述するＷＳＭＦ（Web Service Modeling Framework）がある。ＷＳＭＦは、Ｗｅｂサービスアプリケーションを実装する多様なコンポーネントを分離する一方で、同時に異なるコンポーネント間の最大限の仲介を提供することを目的としている。また、ＷＳＭＦは、ＤＡＭＬ‐Ｓ等の包括的な（comprehensive）オントロジをベースにしており、サービス目的リポジトリや、サービス要求を解決する仲介者（mediator）というコンセプトを提供する。
【００６０】
以上、図１０及び図１１を参照してサービス発見のための様々な仕様について説明してきたが、これらは本発明の範囲を制限するものではない。また、以上概説してきたいずれの機能も、ハードウェア、ソフトウェア又はこれらの組み合わせを通じて実現することが可能である。
【図面の簡単な説明】
【００６１】
【図１】本発明におけるサービスの提供を例示する概念図である。
【図２】本発明に係るサービス選択装置の概念図である。
【図３】図２に示されるサービス選択装置の動作のフローチャートである。
【図４】図２に示されるサービス選択装置のさらに詳細な概念図である。
【図５】図４に示されるサービス選択装置の動作のフローチャートである。
【図６】図４に示されるサービス選択装置の動作の追加的なフローチャートである。
【図７】本発明に係る複数の階層のサービス目的抽象（service objective abstraction）に対するサービス分解／選択の反復適用を示している。
【図８】本発明に係るサービス目的分解の一例を示している。
【図９】本発明に係るサービス選択の一例を示している。
【図１０】本発明に係るサービス選択をサポートするＷｅｂサービスを提供する方法を示している。
【図１１】本発明に係るサービス選択をサポートするセマンティックＷｅｂサービスを提供する方法を示している。
【図１】
0004759269.tif 000010
【図２】
0004759269.tif 000011
【図３】
0004759269.tif 000012
【図４】
0004759269.tif 000013
【図５】
0004759269.tif 000014
【図６】
0004759269.tif 000015
【図７】
0004759269.tif 000016
【図８】
0004759269.tif 000017
【図９】
0004759269.tif 000018
【図１０】
0004759269.tif 000019
【図１１】
0004759269.tif 000020