(57)【要約】サービス属性を有するサービスの特性を記述する少なくとも一つのサービスオントロジーとを使用した通信システムで報知される少なくとも１つのサービスを見出す方法により、ユーザー本位かつパーソナル化されたサービスディスカバリーが提供される。 ディスカバリー文は、クエリータームの関数として記述され、ディスカバリー文と適合するサービス属性を有するサービスが、サービスオントロジーの構文を使用して見出される。
2006526186.tif 000002
【特許請求の範囲】
【請求項１】
サービス特性およびサービス属性を記述する少なくとも１つのサービスオントロジーを使用して、通信システムで報知される少なくとも１つのサービスを見出す方法において、
サービスディスカバリーのクエリータームを受信するステップと、
クエリータームの関数としてディスカバリー文を記述するステップと、
サービスオントロジーの構文を使用する前記ディスカバリー文に適合するサービス属性を有するサービスを見出すステップと
を有する方法。
【請求項２】
サービスオントロジーがサービス特性の序列を記述することを特徴とする請求項１に記載の方法。
【請求項３】
前記サービス特性の序列が階層的に与えられることを特徴とする請求項２に記載の方法。
【請求項４】
前記ディスカバリー文を記述するステップが、用例パターンを反映するパラメータで前記クエリータームを拡張するステップを有することを特徴とする請求項１ないし３のいずれか一つに記載の方法。
【請求項５】
利用可能な用例パターンの有無を評価するステップをさらに有することを特徴とする請求項４に記載の方法。
【請求項６】
利用可能な用例パターンがないときにデフォルトの用例パターンを採択するステップをさらに有することを特徴とする請求項５に記載の方法。
【請求項７】
利用可能な用例パターンがあるときに、ユーザーグループのサービスコンテクストを反映する予め登録された用例パターンを採択することを特徴とする請求項５に記載の方法。
【請求項８】
クエリータームを用例パターンに割り当てるステップをさらに有することを特徴とする請求項７に記載の方法。
【請求項９】
クエリータームを用例パターンに割り当てるステップが
クエリーパラメータの種類およびその値と、用例パターンパラメータの種類およびその値とを比較するステップと、
前記比較結果にしたがって、クエリータームと最も適合する用例パターンを選択するステップとを
有することを特徴とする請求項８に記載の方法。
【請求項１０】
前記ディスカバリー文を記述するステップが、ユーザープリファレンスを反映するパラメータで前記クエリータームを拡張するステップを有することを特徴とする請求項１ないし９のいずれか一つに記載の方法。
【請求項１１】
前記ディスカバリー文を記述するステップが、ユーザープリファレンスあるいはユーザーパターンの少なくとも一つを表すソフト制約パラメータで前記クエリータームを拡張するステップを有することを特徴とする請求項４ないし１０のいずれか一つに記載の方法。
【請求項１２】
前記ディスカバリー文を記述するステップが、ユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つを表すハード制約パラメータで前記クエリータームを拡張するステップを有することを特徴とする請求項４ないし１１のいずれか一つに記載の方法。
【請求項１３】
ソフト制約パラメータあるいはハード制約パラメータの少なくとも一つが、以前のサービスアプリケーション、ユーザープリファレンスの収集、サービスドメインの知識表現、あるいは仮定したユーザーの意図から導出されることを特徴とする請求項１１又は１２に記載の方法。
【請求項１４】
前記サービスディスカバリーをおこなうステップが、前記クエリータームとともに受信した情報、あるいは、ユーザープロフィールデータの少なくとも一つにしたがって、ディスカバリーのためにサービスオントロジーを選択するステップを有することを特徴とする請求項１ないし１３のいずれか一つに記載の方法。
【請求項１５】
前記ディスカバリーングサービスが、続くサービスディスカバリーの開始点をサービスオントロジーの中で決定するステップを有することを特徴とする請求項１ないし１４のいずれか一つに記載の方法。
【請求項１６】
サービスディスカバリーの開始点の決定が、
前記クエリータームを開始概念として前記サービスオントロジーに含めるステップと、
前記開始概念に後続する概念をサービスディスカバリーの開始点として設定するステップと
によりおこなわれることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記サービスを見出すステップが、記述されたディスカバリー文について前記サービスオントロジーを横行するステップを有することを特徴とする請求項１ないし１６のいずれか一つに記載の方法。
【請求項１８】
サービスディスカバリーを繰り返すためにディスカバリー文を緩和するステップをさらに有することを特徴とする請求項１ないし１７のいずれか一つに記載の方法。
【請求項１９】
前記ディスカバリー文がサービスオントロジーの緩和序列にしたがって緩和されることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記ディスカバリー文がユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つにしたがって緩和されることを特徴とする請求項１８又は１９に記載の方法。
【請求項２１】
前記ディスカバリー文がソフト制約について緩和されることを特徴とする請求項２０に記載の方法。
【請求項２２】
緩和序列が部分序列であることを特徴とする請求項１８ないし２１のいずれか一つに記載の方法。
【請求項２３】
サービス特性およびサービス属性を記述する少なくとも１つのサービスオントロジーを使用して、通信システムで報知される少なくとも１つのサービスを見出す装置において、
サービス特性およびサービス属性を記述する少なくとも１つのサービスオントロジーを記憶する記憶部と、
サービスディスカバリーのクエリータームを受信する受信部と、
クエリータームの関数としてディスカバリー文を記述するディスカバリー文生成部と、
サービスオントロジーの構文を使用する前記ディスカバリー文と適合するサービス属性を有するサービスを見出すディスカバリー部と、
を有する装置。
【請求項２４】
前記記憶部がサービス特性の序列とともにサービスオントロジーを記憶することを特徴とする請求項２３に記載の装置。
【請求項２５】
前記記憶部がサービス特性の序列を階層的に記憶することを特徴とする請求項２４に記載の装置。
【請求項２６】
ディスカバリー文生成部が、用例パターンを反映するパラメータで前記クエリータームを拡張する拡張部を有すること特徴とする請求項２３ないし２５のいずれか一つに記載の装置。
【請求項２７】
前記ディスカバリー文生成部が、利用可能な用例パターンの有無を評価する用例パターン部を有することを特徴とする請求項２６に記載の装置。
【請求項２８】
前記用例パターン部が、利用可能な用例パターンがないときにデフォルトの用例パターンを採択することを特徴とする請求項２７に記載の装置。
【請求項２９】
前記用例パターン部が、利用可能な用例パターンがあるときに、ユーザーグループのサービスコンテクストを反映する予め登録された用例パターンを採択することを特徴とする請求項２７に記載の装置。
【請求項３０】
前記用例パターン部がさらにクエリータームを用例パターンに割り当てることを特徴とする請求項２９に記載の装置。
【請求項３１】
前記用例パターン部が、
クエリーパラメータの種類とその値と、用例パターンパラメータの種類とその値とを比較し、
前記比較結果にしたがってクエリータームと最も適合する用例パターンを選択することにより、
クエリータームを用例パターンに割り当てることを特徴とする請求項３０に記載の装置。
【請求項３２】
ユーザープリファレンスを反映するパラメータで前記クエリータームを拡張する拡張部をさらに有することを特徴とする請求項２３ないし３１のいずれか一つに記載の装置。
【請求項３３】
サービスのサービスユーザ構想で前記クエリータームを拡張する拡張部を有することを特徴とする請求項２３ないし３１のいずれか一つに記載の装置。
【請求項３４】
前記ディスカバリー文生成部が、ユーザープリファレンスあるいは用例パターンの少なくとも一つを表すソフト制約パラメータで前記クエリータームを拡張するソフト制約部を有することを特徴とする請求項２６ないし３２のいずれか一つに記載の装置。
【請求項３５】
前記ディスカバリー文生成部が、ユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つを表すハード制約パラメータで前記クエリータームを拡張するハード制約部を有することを特徴とする請求項２６ないし３２のいずれか一つに記載の装置。
【請求項３６】
ソフト制約パラメータあるいはハード制約パラメータの少なくとも一つが 、以前のサービスアプリケーション、ユーザープリファレンスの収集、サービスドメインの知識表現、あるいは仮定したユーザーの意図から導出されることを特徴とする請求項３４に記載の装置。
【請求項３７】
前記ディスカバリー部が、前記クエリータームとともに受信した情報、あるいはユーザープロフィールデータの少なくとも一つにしたがって、ディスカバリーのためにサービスオントロジーを選択するサービスオントロジー選択部を有することを特徴とする請求項２３ないし３６のいずれか一つに記載の装置。
【請求項３８】
前記ディスカバリー部が、続くサービスディスカバリーの開始点を決定する開始点をサービスオントロジーの中で決定する決定部を有することを特徴とする請求項２３ないし３７のいずれか一つに記載の装置。
【請求項３９】
前記開始点決定部が、
前記クエリータームを開始概念としてサービスオントロジーに含め、
前記開始概念に序列で後続する概念をサービスディスカバリーの開始点として設定することにより、
サービスディスカバリーの開始点を決定することを特徴とする請求項３８に記載の装置。
【請求項４０】
前記ディスカバリー部が、記述されたディスカバリー文について前記サービスオントロジーを横行するサービスオントロジー横断部を有することを特徴とする請求項２３ないし３９のいずれか一つに記載の装置。
【請求項４１】
前記ディスカバリーが、サービスディスカバリーを繰り返すためにディスカバリー文を緩和する緩和部を有することを特徴とする請求項２３ないし４０のいずれか一つに記載の装置。
【請求項４２】
前記緩和部が、サービスオントロジーの緩和序列にしたがってディスカバリー文を緩和することを特徴とする請求項４１に記載の装置。
【請求項４３】
前記緩和部が、ユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つにしたがってディスカバリー文を緩和することを特徴とする請求項４１又は４２に記載の装置。
【請求項４４】
前記緩和部が、少なくとも１つのソフト制約についてディスカバリー文を緩和することを特徴とする請求項４３に記載の装置。
【請求項４５】
前記緩和部が、種々のサービス構想にしたがってディスカバリー文を緩和することを特徴とする請求項４１に記載の装置。
【請求項４６】
前記緩和部が、前記緩和序列を部分序列として決定することを特徴とする請求項４１ないし４５のいずれか一つに記載の装置。
【請求項４７】
一つのネットワークノードと、サービス提供プラットフォームのネットワークノードと、ウェブサービスプラットフォームのネットワークノードを含む一群から選択された、請求項２３ないし４６のいずれか一つに記載の装置。
【請求項４８】
少なくとも１つのサービスオントロジーを使用して報知される少なくとも１つのサービスを見出す装置の内部メモリに直接ロード可能であり、この装置のプロセッサで実行されると請求項１ないし２２のいずれかの方法のステップを実行するソフトウェアコード部分を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスディスカバリーの方法とその装置に関し、特に、サービス特性およびサービス属性を記述するサービスオントロジーに基づく協調型サービスディスカバリーの方法と装置に関する。
【背景技術】
【０００２】
本明細書で考えるサービスとは、サービスディスカバリーおよびサービスインタラクションを提供する包括的サービスプラットフォーム、例えば、ウェブサービスプラットフォームまたは第３世代移動通信環境に次ぐサービス提供プラットフォームにより提供されるサービスをいう。
【０００３】
多様なサービスが増加しているので、ユーザーが個別のタスクとニーズを充足する適切なサービスを見出して選択するときに、そのユーザーをサポートすることが必須となる。適切な機能を提供するサービスをユーザーが見出そうとするとき、各サービスが提供する種々の対象や情報の使い勝手について、ユーザーに特定の趣向があることが普通である。
【０００４】
ユーザーをサポートする現在公知の方法は、例えば、いわゆる「ウェブサービスパラダイム」(W3C, Web Service Activity (Architecture Domain), http://www.w3.org/2002/ws、２００２年)に基づいている。
【０００５】
サービスディスカバリーの方法には、第１に、「The UDDI Technical White Paper、http://www.uddi.org」に記載のＵＤＤＩ(Universal Description and Discovery）がある。ＵＤＤＩは、ディスカバリーのために、インターネットに広がるレジストリのネットワークを提供し、サービス提供者の情報とサービス起動の詳細情報を職業別電話帳（イエローブック）の形式で収集する。現在、ＵＤＤＩが広く使用されているが、ＵＤＤＩには重大な欠陥がある。ＵＤＤＩでは検索がキーワード検索に限定され、柔軟な形式ではサービスディスカバリーが提供されていない。
【０００６】
サービスディスカバリーの別の方法には、ＷＳＤＬ（Web Service Description Language、Web Service Description Language WSDL 1.1, E. Christensen, F. Curbera、G. Meredith, S. Weerawarana, http://www.w3.org/TR/2001/NOTE-wsdl-20010315、２００１年）、あるいはｅｂＸＭＬ（公式ウェブサイトhttp://www.ebXML.org）がある。現在のところ、ビジネス−ビジネス間（Ｂ２Ｂ）サービス提供環境では、ＷＳＤＬあるいはｅｂＸＭＬがサービスカタログの実装に積極的に使用されている。しかし、依然としてこれらの方法には、サービスのパーソナル化という有用な概念が欠落している。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
以上をまとめると、現在のところ、限られた範囲でユーザー本位であり、かつ、限られた範囲でパーソナル化されたサービスディスカバリーしか提供されていない。しかし、サービス数が今後増大することが見込めるから、個別のニーズと個別の期待を充足する適切なサービスを、サービスを受けるユーザー（以下、サービスユーザと称する）が続けて選択できるように、サービスディスカバリーを提供することが重要である。
【課題を解決するための手段】
【０００８】
上記を鑑み、本発明の課題は、ユーザー本位かつパーソナル化されたサービスディスカバリーを提供することである。
【０００９】
本発明によれば、この課題は、通信システムで報知される少なくとも１つのサービスを見出す方法（サービスディスカバリー）により解決される。なお、本発明では、サービスの報知は、サービス特性およびサービス属性を記述する、いわゆる「サービスオントロジー」を使用しておこなわれると仮定する。サービスディスカバリーのクエリータームの受信後、ディスカバリー文が、クエリータームの関数として構成される。続いて、サービスオントロジーおよびサービスオントロジーの構文を使用して記述されたディスカバリー文とで表現されたサービス属性に最も適合するサービスを検索することによりおこなわれる。
【００１０】
本発明の重要かつ優れている点は、サービス特性およびサービス属性を記述するサービスオントロジーでサービスディスカバリーに利用可能な情報を使用する、すなわち、サービスディスカバリーに協調型の方法を使用することである。サービスディスカバリーは、パラメータとしてのクエリータームと、サービスの報知を担うサービスパラメータとを、１対１で比較することによりおこなわれるだけでなく、サービスオントロジーの構文を使用してサービス属性とディスカバリー文との間の適合度を求めることによってもおこなわれる。
【００１１】
特に、サービスディスカバリー用に報知されるサービス群全体の中からディスカバリー文に適合あるいはほぼ適合するサービス属性を有するサービスのサブセットをディスカバリー文の構成からより効率的に見出すことができるので、サービスオントロジーの構文を使用することによりサービスディスカバリー中に収集されるサービスカタログとのインタラクションが改善される。
【００１２】
なぜなら、構文にしたがうと、サービス属性が関連するサービスは、サービスオントロジーの中の非常に近接した位置に配置されるので、サービスディスカバリーがランダムにではなく、ユーザーの志向に基づく方法でおこなわれるからである。このことにより、見出されるサービスの数およびサービス選択中のユーザーの負担が格段に軽減される。
【００１３】
また、本発明の重要かつ優れている点は、サービスの申し出に引き続いておこなわれるサービスの選択、また、引き続いておこなわれるサービスの実施の前提条件として、サービスディスカバリーが効率的におこなわれることである。すなわち、効率的かつ効果的なサービスディスカバリーにより、サービスのパーソナル化された選択と実行が可能となる。
【００１４】
本発明の別の好適実施形態では、用例パターンを反映する情報により、最初に提示されるクエリータームを拡張することが提案されている。
【００１５】
なお、用例パターンは、サービスコンテクストおよびユーザーグループについての典型的用例を反映する。典型的用例パターンを考慮することにより、クエリータームを拡張して、サービスディスカバリー中のパーソナル化の程度を向上させることができる。
【００１６】
あるユーザーグループのメンバーがクエリータームとともに、サービスディスカバリーがそのメンバー側の負荷を削減するために絶対必要と考える最小量の情報しか提示しない傾向がある場合には、このことは特にあてはまる。典型的なサービスアプリケーションのシナリオで利用できる、例えば長期にわたって、あるいは同一のユーザーグループの別のサービスユーザから手に入る用例パターンを使用することは、サービスディスカバリー中のパーソナル化の程度を向上させる。
【００１７】
本発明の別の好適実施形態によれば、クエリータームの提示の後、用例パターンが利用できるか否かが確認される。この用例パターンを利用できないときにはデフォルトの標準用例パターンを得て、用例パターンを利用できるときには既存の用例パターンを得ることが好ましい。
【００１８】
本発明の好適実施形態では、デフォルトの用例パターンへのフォールバックがサポートされるので、パーソナル化の質が改善される。
【００１９】
本発明の別の好適実施形態によれば、提示されたクエリータームに対して用例パターンが決定される。クエリーパラメータの種類および値は、用例パターンについて定義されているパラメータの種類および値と比較されることが好ましい。続いて、最適な比較結果により、受信したクエリータームに対して最適な用例パターンの選択が可能となる。
【００２０】
この好適実施形態の重要かつ優れている点は、引き続きおこなわれるパーソナル化されたディスカバリーのために用例パターンを自動選択することにより、サービスユーザをサポートすることである。すなわち、本発明は、サービスディスカバリーの質を改善するだけではなく、サービスユーザがこのサービスディスカバリーを容易に開始できるようにしている。
【００２１】
本発明の別の好適実施形態によれば、ユーザープリファレンスを表すパラメータを用いてクエリータームを拡張することによってディスカバリー文を記述することが提案されている。
【００２２】
上記用例パターンの使用とは別に、本発明の好適実施形態は、専属サービスユーザに対してパーソナル化の効果を有する。
【００２３】
すなわち、サービスユーザは、個人のニーズおよび趣向に応じてディスカバリー処理をチューンナップするオプションを有する。ディスカバリー文を記述するときにユーザープリファレンスおよびユーザープロフィールを指定してクエリータームを拡張することにより、サービスディスカバリー中のパーソナル化の程度を最適化できる。
【００２４】
本発明の別の好適実施形態によれば、ディスカバリー文を記述するステップは、サービスのサービスユーザ構想でクエリータームを拡張するステップを有する。
【００２５】
本発明のこの好適実施形態の重要かつ優れている点は、サービスユーザのサービス構想にしたがわないでサービスオントロジーが特定のサービス構想を表現しているときでさえ、クエリータームを適切に拡張することにより、サービスユーザのサービス構想をディスカバリー処理に統合することができることである。
【００２６】
例えば、サービスオントロジーが、サービスの地域構想に沿ってレストランサービスの報知を進めることができる一方、サービスユーザが風味によってレストランサービスを考慮することがある。なお、サービスユーザ構想によるクエリータームの拡張により、サービスディスカバリー処理はサービスオントロジーの構成に依存しなくなる。
【００２７】
本発明の別の好適実施形態によれば、サービスディスカバリーは、ディスカバリーのための複数のサービスオントロジーに依拠し。サービスディスカバリーの前に適切なサービスオントロジーが選択される。サービスオントロジーの選択は、クエリータームとともに受信される情報にしたがって、あるいはユーザープロフィールデータにしたがっておこなわれることが好ましい。
【００２８】
この好適実施形態の重要かつ優れた点は、本発明に係るサービスディスカバリーが静的かつ単一のサービスオントロジーに限定されることはなく、一つのサービスカタログで動作する複数のサービスオントロジーにサポートされることである。なお、パーソナル化およびカスタマイズは、特にクエリータームで与えられる情報を評価することにより提供される。
【００２９】
また、重要かつ優れている別の点は、サービスオントロジーの選択がユーザープロフィールデータにより駆動できることである。これにより、たとえサービスユーザがそのプリファレンスあるいはサービスアプリケーションの長期間の習慣を反映する情報をクエリータームとともに提示しないときでも、サービスディスカバリーのために適切なサービスオントロジーを選択することができる。
【００３０】
また、本発明の別の好適実施形態は、サービスオントロジーにおける開始点の識別に関する。なお、クエリータームおよび関連するサービス属性の構文を、例えばクエリータームの構文にしたがってサービス特性を表現するようにサービスオントロジーを修正して、サービスオントロジーに従属させるあるいは統合することが提案されている。これにより、従属されたクエリータームにサービスオントロジー中で続く要素をサービスディスカバリーの開始点として使用することができる。
【００３１】
本発明のこの好適実施形態の重要かつ優れている点は、サービスディスカバリーの前にサービスオントロジーを適切に修正することによりディスカバリー処理全体の効率を格段に向上できることである。また、サービスオントロジーを修正することにより、既存のサービスオントロジー管理のメカニズムおよびアルゴリズムを利用してサービスディスカバリーを提供することができる。
【００３２】
本発明の別の好適実施形態によれば、記述されたディスカバリー文にしたがってサービスオントロジーを横行することが提案されている。サービスディスカバリーの結果を向上させるために、繰り返しサービスオントロジーの横行がおこなわれることが好ましい。
【００３３】
本発明のこの好適実施形態の重要かつ優れている点は、サービスオントロジーの横行中にサービスオントロジーの構文と組み合わせてパーソナル化情報をディスカバリー文が運ぶことにより得られる効果である。
【００３４】
これにより、記述されたディスカバリー文とサービスオントロジーによりモデル化されたサービスのサービス属性との間の適合を見出す効率が向上する。この理由は、サービスオントロジーの構文を、例えば序列付けられたサービスオントロジーの階層を上り下りすることにより利用することにより、報知された全てのサービスについて時間のかかる走査を回避することができるからである。逆に、パーソナル化された制約の点でサービスディスカバリーには不適切な候補であるサービスの申し出そのものを枝打ちすることにより、サービスディスカバリーに利用可能な解決空間を効率的に走査することができる。
【００３５】
同時に、パーソナル化によりディスカバリー文に表現されているユーザープリファレンスを反映しないサービスを枝打ちすることも可能になるので、得られるサービス数は格段に減少する。
【００３６】
本発明の別の好適実施形態によれば、サービスオントロジーの横行を繰り返す間に、ディスカバリー文を緩和させることが提案されている。
【００３７】
本発明のこの好適実施形態の重要かつ優れている点は、例えばユーザープリファレンスあるいは用例パターンパラメータを緩和させることにより、サービス構想を変更することにより、あるいは種々のサービスオントロジーを使用することにより、サービスディスカバリー出力が生成されるまで、ディスカバリー文を連続してパーソナル化のためにチューンナップできることである。
【００３８】
なお、より高度のパーソナル化を実現するために、本発明に係る緩和は、最も一般的な意味で、制約を付加することも、ディスカバリー文にすでに付加された制約をさらに制限することもある。このことは、ディスカバリーのシナリオがサービスオントロジーの横行により多数のサービスを見出すことができるときに特にあてはまる。この状況では、ユーザープリファレンスをさらに指定し、したがって、サービスディスカバリーの質をさらに最適化する余地が残っている。
【００３９】
この点、本発明によれば、ディスカバリー文を再構成するときに、用例パターン、ユーザープリファレンス、あるいはユーザー指定のサービス構想を使用してクエリータームを拡張することができる。言い換えると、ユーザーのパーソナル化を指定する情報は２回、すなわち、ディスカバリー文を最初に記述するときと、繰り返しおこなわれるサービスオントロジーの横行の間ディスカバリー文を緩和する間で使用される。
【００４０】
この方法が重要かつ優れている点は、ディスカバリー文とサービスオントロジーを進むサービス属性との所望する程度の適合が一番最初からわからないときに、サービスディスカバリーをさらに処理する方法を決定するときのあいまいさを回避できることである。また、緩和の程度を決定するためにユーザープリファレンスを反映するデータを含めることにより、サービスディスカバリーがユーザープリファレンスに沿った方向でおこなわれるようにガイドされ、したがって効率およびサービスディスカバリーの質が向上する。
【００４１】
また、サービスユーザの構想に沿った緩和により、サービスオントロジーの構文を上書きすることができる。すなわち、また、ディスカバリー文について所望する程度の適合が一番最初から利用できないと仮定すると、サービスオントロジーにおけるサービスの申し出の構成方法とは異なる、利用可能なサービスについてのサービスユーザの視点を含めることにより、サービスディスカバリーの戦略を変更することができる。
【００４２】
本発明の別の好適実施形態によれば、少なくとも１つのサービスオントロジーを使用して報知される少なくとも１つのサービスを見出す装置の内部メモリに直接ロード可能であり、この装置のプロセッサで実行されると本発明のディスカバリー処理を実行するソフトウェアコードを含むコンピュータプログラムが提供される。 
【００４３】
したがって、本発明は、本発明の方法ステップをコンピュータあるいはプロセッサシステムに実装することも提供する。つまり、この実装により、コンピュータシステムあるいはより具体的にはプロセッサで使用するための、例えば少なくとも１つのサービスオントロジーを使用して報知される少なくとも１つのサービスを見出す装置に含まれるコンピュータプログラムが提供される。
【００４４】
本発明の機能を定義するプログラムは、コンピュータ/プロセッサに、多様な形態で持ち込むことができる。この形態には、書込み不能な記憶媒体、例えば、プロセッサあるいはコンピュータ入出力装置から読むことができるＲＯＭまたはＣＤ−ＲＯＭディスク等の読み込み専用記憶装置に永久に記憶された情報；書き込み可能な記憶媒体、すなわち、フロッピーディスクおよびハードディスクドライブに記憶された情報； あるいはモデムあるは他のインターフェース装置を介したネットワークや電話網等の通信媒体によりコンピュータ/プロセッサにもたらされる情報を含むが、これらに限定されることはない。
【００４５】
現在でもすでに多様なサービスによりユーザーはその特定のタスクをおこなうために種々の競合するサービスから選択しなければならないから、本発明は、全体として、サービスディスカバリー、サービス選択および、サービスの組立の鍵となるサービスディスカバリーにおけるパーソナル化を提供する。 
【００４６】
多様性が数１０倍に増加すると予測できるので、このことは特に、ネットワークのシームレス統合にあてはまる。特に、適切なサービスディスカバリーのみが利用可能かつ適切なサービスの選択を示すのであるから、本発明の意味でのサービスディスカバリーにより、続いておこなわれるサービス選択の適切なパーソナル化がおこなわれるようになるであろう。
【００４７】
また、パーソナル化され、自動化されたサービスディスカバリーにより、構造化されていない複数のサービスへのサービスタスクへの適合性評価のための面倒な手動アクセスを回避することができる。適切なサービスオントロジーで表現されているときに、クエリータームを拡張し、かつ、サービスディスカバリーのために構成される要件を緩和するために、関連性についてのサービスユーザーの概念、用例パターンあるいはユーザープリファレンスを使用することにより、サービスの提供が向上され、見出されたサービスの使い勝手が向上する。
【００４８】
また、本発明に係るサービスディスカバリーは、例えばセマンティックウェブサービス、プロアクティブサービス、インテリジェントエージェント等の、任意の種類のサービスプラットフォームに適していて、データベースシステムの技術、知識工学、および人工知能の公知手法を利用できる。
【００４９】
また、サービスディスカバリーのパーソナル化により、サービス提供のための多量の装置、例えば、有線電話、無線電話、無線ハンドヘルド端末、インターネットに接続されたデスクトップ端末、無線ＬＡＮに接続されたラップトップ端末、ポケットベル、等々に適合させることができ、また、サービスユーザの種々の役割、例えば承認を求める従業者、プロジェクトチームのメンバーである従業者、出張中の従業者の役割、および個人としてサービスを利用するユーザーの役割に適合させることができ、また、移動中に変動するサービス提供コンテクスト、例えばオフィス環境、飛行機等にも適合することができる。これらのいかなる状況でも、情報のオーバーロードを避けつつ、サービスの提供を容易とすることができる。
【発明を実施するための最良の形態】
【００５０】
本発明のベストモードと好適実施形態の記載の全体において、以下に列挙する用語は、以下に示すように理解されるべきである。
【００５１】
制約とは、サービスディスカバリー中に充足されるべきクエリーパラメータあるいは属性の集合をいう。制約は、サービスインターフェースあるいはサービス出力に課される。
【００５２】
サービスとは、ソフトウェアオブジェクトあるいはネットワークエンティティであり、他のサービスあるいはエンドユーザーとインタラクションし、特定の機能あるいは複数の機能をカプセル化する。サービスは、明確なインターフェースを有する。
【００５３】
ハード制約とは、必ず守るべき制約をいう。
【００５４】
クエリータームとは、サービスカタログあるいはサービス自体と通信するために使用されるフレーズをいう。クエリータームは、ハード制約あるいはソフト制約の観点からユーザーニーズを表現する。クエリー言語は、クエリータームを表現するために定義、使用され、例えば、標準データベースシステムにより実装されるカタログ/サービスのための構造化クエリー言語ＳＱＬである。クエリータームには、セマンティックの記述も含めることができる。
【００５５】
クエリー緩和/拡張とは、制約（通常はソフト制約）の新規追加により、あるいは、与えられたあるいは関連するユーザープリファレンスについてソフト制約/ハード制約を明示的に緩和することにより与えられたクエリータームを再構成することをいう。
【００５６】
サービスカタログについて、自動化された報知および顧客からのディスカバリーについて、サービスが特別なネットワークエンティティ/ノード、すなわちサービスカタログに登録、報知される。カタログは、ネットワークの複数のノードに配布できる。ウェブサービスでは、ＵＤＤＩレポジトリがカタログとしてよく使用される。
【００５７】
セマンティックサービス記述とは、セマンティックに意味のあるサービスの報知のための言語によるサービスの記述を、例えば、キーワードならびにＤＡＭＬ−Ｓあるいはセマンティックウェブ等のオントロジーに基づく記述をいう。
【００５８】
サービス構想とは、サービスオントロジーで報知されるサービスについてのサービスユーザの視点を、例えば、サービスユーザの志向を反映する種々のサービス属性を考慮することによって反映するものをいう。サービスオントロジーは、種々のサービスディスカバリー処理を内在するサービス構想により構成あるいは再構成される。
【００５９】
サービスオントロジーとは、サービス属性あるいはサービス概念における特定のサービス構想に対する部分序列、例えば「〜よりも良い」型の序列あるいは「これは優（Ａ）」型の序列をいう。典型的な場合、利用可能なサービスに構造を持たせてサービスディスカバリーを提供するために、サービスオントロジーでは、サービス属性あるいはサービス概念は階層化される。
【００６０】
ソフト制約とは、例えばユーザープリファレンス等の可能ならば守る制約をいう。
【００６１】
ユーザープリファレンスとは、自然に順序付けされる領域で、関連する項目の間の部分序列（私はＢよりもＡを好む。私は、ＣよりもＡを好む。等々。)により、あるいは概略値によるソフト制約(サービス価格を最小化する。最も近くのサービスを探す。直近の飛行日を予約する。等々。)により、ユーザーの意向を表現するために使用されるものをいう。ユーザープリファレンスは、知識表現の一般的手法を使用して、セマンティック形式で表現することもできる。
【００６２】
用例パターンとは、サービスユーザのグループのプリファレンスおよび典型的なサービス使用条件を反映するソフトサービス制約あるいはハードサービス制約の集合をいう。      
【００６３】
ユーザープロフィールとは、サービスユーザに関連付けられたハード/ソフト制約の集合をいう。ユーザープロフィールは、通信システムの任意の場所で、例えばネットワークノードのネットワーク側で、あるいは移動端末等の端末のエンドユーザー側で保守される。
【００６４】
ウェブサービスとは、ＵＲＩ（Uniform Resource Identificator）によって識別される特別なサービスをいう。インターフェースおよびフロントページはＸＭＬを用いて定義および記述される。普通の場合、この定義は、(集中)サービスカタログにより他のソフトウェアシステムから見出すことができる。引き続いて、これらのソフトウェアシステムは、インターネットプロトコルにより運ばれるＸＭＬベースのメッセージを使用して、ウェブサービスと、その記載されている定義にしたがってインタラクションすることができる。
【００６５】
図１は、本発明におけるサービス提供を説明する概念図を示す。
図１に示し、ここまでに説明したように、サービス１０は、少なくとも１つの機能１２をカプセル化する。ネットワーク１６において、機能１２は、既定のインターフェース１４により提供される。ソフトウェアオブジェクト、ネットワークエンティティ、あるいはこれらの組み合わせのいずれでサービスが提供されるかによらずに、他のサービスあるいはサービスのエンドユーザーとのインタラクションが、サービスの実行に必要な情報の交換を可能とするサービスの署名により実現される。なお、本発明は、特定の種類のネットワークに限定されない、例えば、移動通信ネットワーク、インターネット、局所ネットワーク、集中ネットワーク、異種混在ネットワーク、ピアーツーピアネットワーク等、あるいはこれらが任意に組み合わされたものにも適用できる。
【００６６】
すなわち、サービス型パラメータあるいは等価な署名パラメータが具現化された後、そのサービス要求によりサービスを起動することができる。本発明は、特定の種類のサービスに限定されると理解されるべきではないが、典型的かつ非限定な例には、ウェブサービス、i-モード（登録商標）サービス、他の分散サービスパラダイム（例えばＣＯＲＢＡ、ＪＩＮＩ、ＪＸＴＡ等）がある。
【００６７】
図１に示すように、 サービスカタログ１８は、ネットワーク１６で提供される種々のサービスを登録、報知するために提供される。サービスカタログは、ネットワーク１６の複数のノードに配布できる。 サービスカタログ１６は、抽象的レベルのサービス記述を、例えば上記に説明したサービスオントロジーに基づくセマンティックサービス記述を使用して、サービスの報知および宣伝を実現する。
【００６８】
以上説明してきたように、クエリータームに基づく抽象的なサービス記述を使用するサービスディスカバリーが、サービスユーザによるサービス選択の前提となることは明らかである。
【００６９】
以下に説明するように、本発明は、サービスディスカバリー法を格段に改善する。本発明によれば、サービスディスカバリーは、サービスの抽象的な記述に基づくだけではなく、サービスディスカバリーをパーソナル化するためのユーザープリファレンスで強化されたサービスディスカバリー法にも基づいている。
【００７０】
図２は、本発明に係るサービスディスカバリーを提供するウェブサービス提供方法を示す。
また、図２に示すように、本発明では、既存の複数の方法と組み合わせて、サービス記述とサービス報知とを拡張することができる。
【００７１】
サービスディスカバリーは、ウェブサービスのオンラインレジストリへの取り組みとして、ＵＤＤＩによりおこなうことができる。または、ＸＭＬベースの用語としてＷＳＤＬ、ＳＯＡＰ（Simple Object Access Protocol）、サービス要求とサービス記述とを比較するＥ−Ｓｐｅａｋ、およびワークフローの観点からサービス記述を提供する図２には示されていないｅｂＸＭＬによりおこなうこともできる。
【００７２】
図３は、サービスディスカバリーをサポートする本発明に係るセマンティックサービス提供方法を示す。
【００７３】
ＤＡＭＬ−Ｓは、ウェブサービスを記述するオントロジーに基づく方法であり、共通のサービスオントロジーを提供することを志向している。ＤＡＭＬ−Ｓのデザインは、ＤＡＭＬ＋ＯＩＬ（D. Connolly et al. DAML+OIL Reference Description, W3C note, ２００１年１２月）の上に構築され、セマンティックウェブ・マークアップ言語の階層的アプローチにしたがっている。ＤＡＭＬ−Ｓは、エージェントとユーザーにウェブサービスをディスカバリーし、起動し、構成することを可能とするオントロジーを提供することを志向している。ＤＡＭＬ−Ｓオントロジーの構造は、３層からなり、サービスを報知しディスカバリーングするためのサービスプロフィールと、サービスの動作を詳細に記述するプロセスモデルと、メッセージの交換によりサービスと相互運用する方法の詳細を記述するサービスグラウンディングとを有する。
【００７４】
図３に示すように、別のセマンティックサービスディスカバリーの例は、ウェブサービス・モデリングフレームワークＷＳＭＦである。ＷＳＭＦは、サービスの事前/事後調整およびサービスモデルを記述する。ＷＳＭＦは、種々のコンポーネントの間に最大限のメディエーションを同時に提供しつつ、ウェブサービスアプリケーションを実装する種々のコンポーネントを強力に分離することを目的としている。ＷＳＭＦは、ＤＡＭＬ−Ｓ等のコンプリヘンシブオントロジー上に構築され、サービス要求を解決するために、サービス志向レポジトリおよびメディエイタの概念を提供する。
【００７５】
上記のように、サービスディスカバリーの種々の標準を図２および図３を参照して説明してきた。これらの標準が、本発明の範囲を限定しないことは明らかである。また、以下に説明する機能はいずれも、ハードウェア、ソフトウェア、あるいはこれらの組み合わせで実現できる。
【００７６】
ここまで説明したように、本発明は、オントロジーに基づくディスカバリーが、ユーザープリファレンス、種々のユーザーサービス構想、および標準用例パターンを利用するという、ユーザー本位のサービス提供のパーソナル化に関する。なお、本発明に係るサービスオントロジーは、特定のサービス構想についてのサービス属性の部分序列として理解できる。普通の場合、利用可能なサービスを構造化してサービスディスカバリーを提供するために、サービスオントロジーはサービス属性を階層化する。
【００７７】
図４は、少なくとも１つのサービスオントロジーを使用して、例えば通信システムで報知されるサービスを少なくとも１つ見出す装置の概念図を示す。
【００７８】
図１に示すように、ディスカバリー装置２０は、記憶部２２、クエリーターム受信部２４、ディスカバリー文生成部２６および、ディスカバリー部２８を備える。
【００７９】
図５は、図４に示すディスカバリー装置２０の動作フローチャートを示す。
図５に示すように、受信部は、サービスディスカバリーのために、サービスユーザからクエリータームを受信する（ステップＳ１０）。次に、ディスカバリー文生成部２６は、クエリータームの関数としてディスカバリー文を記述する（ステップＳ１２）。
【００８０】
ディスカバリー文生成部２６は、用例パターン、用法プリファレンス、サービス構想、あるいはその少なくとも一つの使用によりクエリータームの構文機能を充実させるために、記憶部２２にアクセスする。以下に、その詳細を説明する。
【００８１】
図５に示すように、ディスカバリー部２８は、ディスカバリー文中のサービス制約とサービスオントロジー中を進むサービス属性およびその属性値との適合を探すことにより、サービスディスカバリーをおこなう（ステップＳ１４）。なお、ディスカバリー部２８は、 サービスディスカバリー中に記憶部２２にアクセスして、サービスオントロジーおよびサービス特性を示すその構造を使用する。
【００８２】
また、ディスカバリー部２８は、サービスオントロジーを進むサービスとディスカバリー文とが適合するまで、ディスカバリー文を再構成することにより、サービスディスカバリーを繰り返し実行することができる。
【００８３】
図６（ａ）および図６（ｂ）は、本発明に係るサービスオントロジーの構文の典型例を示す。
図６（ａ）および図６（ｂ）に示すように、サービスオントロジーは、サービス属性の部分序列として、すなわち、非周期的有向性グラフとして現れる。このグラフでは、複数のノードのそれぞれがサービス属性を表現し、有向性エッジはこの複数のサービス属性の間の関係を表現している。
【００８４】
図６（ａ）、（ｂ）に示すように、サービスの具現化は、サービスオントロジー中を進むサービス属性の具現化を表現するためにサービスオントロジーのノードに無向性エッジを介して接続したサービスノードとして表現できる。
なお、図６（ａ）に示すサービスオントロジーはサービス特性のサブセットにおける部分序列を表現し、図６（ｂ）に示すサービスオントロジーは、部分序列のより具体的な形式、すなわち、サービス特性のサブセットおよび構想についての階層を表現している。
【００８５】
図７は、図４に示すディスカバリー文生成部２６の概念図を示す。
図７に示すように、ディスカバリー文生成部２６は、拡張部３０、用例パターン部３２、ハード制約部３４、およびソフト制約部３６を備える。
【００８６】
図７に示す拡張部３０の動作の詳細を説明する。まず、用例パターンは、ユーザーグループに対するサービス用例の典型的コンテクストを反映する。また、用例パターンの使用について、サービスディスカバリーのために提示されるクエリータームが、サービス提供の典型的シナリオ、例えば、普段のレストランでの夕食あるいは仕事上のレストランでの会食に関連すると仮定する。
【００８７】
また、ユーザープリファレンスによる拡張とは、典型的な場合ユーザープロフィールに反映されるサービスユーザに特有なプリファレンスを考慮することを意味する。
【００８８】
さらに、本発明に係るサービス構想は、例えば、アジアの料理あるいはヨーロッパの料理といった地域の構想に沿った、あるいは、スパイシーあるいはマイルドといった味の構想に沿ったレストランの分類にしたがったサービス記述の種々の観点を意味する。
【００８９】
図８は、図７に示す拡張部３０の動作フローチャートを示す。
図８に示すように、用例パターンにより拡張されているか否か確認される（ステップＳ１６）。拡張されている場合には、典型的用例パターンを反映するパラメータで、クエリータームを拡張することにより、ディスカバリー文が記述される（ステップＳ１８）。
【００９０】
拡張されていない場合には、ステップＳ２０に進み、ユーザープリファレンスがサービスディスカバリー中に考慮されたか否かを確認する。考慮されているときは、ステップＳ２２に処理が進み、ユーザープロフィールから例えば得たユーザープリファレンスに、あるいは直接サービスユーザにより提供されたユーザープリファレンスにしたがってクエリータームを拡張することにより、ディスカバリー文が記述される。
【００９１】
そうでなければ、ステップＳ２４に処理が進み、ユーザーに特有なサービス構想がサービスディスカバリー中に考慮されたか否かを確認する。考慮されたときには、ステップＳ２６に処理が進み、ユーザーが指定するサービス構想にしたがってクエリータームを拡張することによりディスカバリー文が構成される。 考慮されていなければ、処理が終了する。
【００９２】
図８は、拡張部の動作ステップの序列を、例えば、用例パターン、ユーザープリファレンス、およびサービス概念の考慮にしたがって定めるフローチャートを示しているが、この序列は相互に自由に交換できる。したがって、この図は本発明の範囲を限定するものではない。
【００９３】
以下、擬似コード表示を参照して、拡張部３０の動作の詳細を説明する。繰り返すが、この表示は本発明の範囲を限定するものではない。
【００９４】
擬似コードを使用してディスカバリー文を記述する基本スキームは、次のように表現できる。
2006526186.tif 000003
【００９５】
なお、「DISCOVER」という用語は、サービスディスカバリーが具体的なオントロジーおよびそのオントロジーにおける具体的な開始点に対して開始されるという事実を反映している。
この点から、FROM節における特定のパラメータ値により具現化されたクエリータームパラメータが、サービスディスカバリー用サービスオントロジー中を進むサービスの申し出のサービスパラメータと比較される。
【００９６】
本発明によれば、サービスディスカバリーにおけるパーソナル化された制約を反映するユーザーに特有な情報を使用して、この基本スキームを拡張することが提案されている。
【００９７】
第１の拡張は、用例パターンによる拡張であり、次のように擬似コード表示で表現できる。
2006526186.tif 000004
【００９８】
以下に説明するように、用例パターンの使用について、本発明は、用例パターンの自動処理に関する実施形態も含んでいる。
【００９９】
図９は、図７に示す用例パターン部３２の動作フローチャートを示す。
図９に示すように、サービスディスカバリーに利用できる用例パターンの有無を確認する（ステップＳ２８）。利用できる用例パターンがない場合には、デフォルトの用例パターンが採択される（ステップＳ３０）。一方利用できる用例パターンがある場合には、クエリータームに対して利用可能な用例パターンが採択される（ステップＳ３２）。
【０１００】
図９に示すように、用例パターン得るためのクエリータームの設定は、クエリーターム中のパラメータの比較とベストマッチの選択によりおこなわれる（ステップＳ３４）。生成された結果は、サービスディスカバリーのために、適切なディスカバリー文の構成に使用される。
【０１０１】
ここまで用例パターンを用いるディスカバリー文の拡張を説明してきたが、本発明の別の実施形態は、ユーザープリファレンスを用いるクエリータームの拡張によるディスカバリー文の構成に関する。
【０１０２】
なお、ユーザープリファレンスのコンシダレーションの擬似コード表示は、次のように与えられる。繰り返すが、この表示は本発明の範囲を限定するものではない。
2006526186.tif 000005
【０１０３】
これより、この擬似コード表示が、PREFERRING文およびPRIOR TO文にしたがって、例えばparameters user_ preference_1, ..., user_preference_nとユーザープリファレンスに順序を与えることにより、ユーザープリファレンスを表現していることは明らかである。
【０１０４】
このユーザープリファレンスの序列の表現によれば、ディスカバリー文の構成中に、例えばサービス属性として、あるいは属性値の好ましい範囲として表現されるユーザープリファレンスを含めることもできる。また本発明は、例えば次のようにユーザープリファレンスのOR結合を使用して設定した序列と組み合わせて、このユーザープリファレンスの論理和を含めることもできる。
2006526186.tif 000006
【０１０５】
なお、ユーザープリファレンスのＯＲ結合により、サービスオントロジーで与えられる構文から逸脱することができる。すなわち、サービスオントロジーの構文に厳密に制限されることなく、サービスオントロジーを自由に横行することができる。
【０１０６】
また、用例パターンおよびユーザープリファレンスの両組み合わせからディスカバリー文の構成中におけるクエリータームの拡張もおこなうことができる。
【０１０７】
また、ユーザープリファレンスを表すパラメータについてだけではなく、用例パターンを表すパラメータについても、次のようにこれらの論理和をとることができる。
2006526186.tif 000007
【０１０８】
本発明の別の実施形態は、サービスディスカバリー用ディスカバリー文の構成中におけるサービス構想のコンシダレーションに関する。ここまで概略を説明したように、サービス構想は、サービスオントロジーによりサポートされるサービスのビューを表現する。
【０１０９】
なお、受信クエリータームの補足として、ユーザーの好むサービス構想を、例えばＡＮＤ結合によりディスカバリー文に含めることができる。この擬似コード表示では、対応する表現が次のように表現できる。繰り返すが、この表示は本発明の範囲を限定するものではない。
2006526186.tif 000008
【０１１０】
なお、上記擬似コード表示を理解するために、PREFERRING-節で与えられるユーザープリファレンスとは別に、任意に指定されるユーザープリファレンスは、WHERE-節に記載されたユーザー構想について常に考慮される。これより、サービスディスカバリー中に種々のサービス構想に留意することができる。
【０１１１】
本発明に係るディスカバリー文を記述する別の実施形態は、ユーザープリファレンス、用例パターン、およびサービス構想をディスカバリー文で表現する方法に関する。
【０１１２】
図７に示すように、ディスカバリー文生成部２６は、ハード制約部３４とソフト制約部３６とを備える。
ハード制約部３４は、必ず実現されるハード制約として拡張クエリータームを表現する。また、ソフト制約部３６は、実現すべきソフト制約として拡張クエリータームを表現する。
【０１１３】
与えられた擬似コード表現では、WHERE-節にハード制約が組み込まれ、PREFERRING-節にソフト制約が組み込まれている。
【０１１４】
また、クエリータームの拡張についての情報は、ユーザープロフィールあるいは用例パターンプロフィールから収集することができる。このような知識のレポジトリは、以前使用されたサービスの考慮、ユーザープリファレンスの収集、サービスドメインの知識表現、および仮定したユーザーの意図から構築することができる。
【０１１５】
上記のように、ディスカバリー文をフォーミュレーティングする本発明に係る種々の実施形態を図７ないし９を参照して説明してきた。以下、図１０と図１１を参照して、サービスディスカバリーの実施形態を説明する。
【０１１６】
図１０は、図４に示されたディスカバリー部２８の概念図を示す。
図１０に示すように、図４に示されたディスカバリー部２８は、サービスオントロジー選択部３８、開始位置決定部４０、サービスオントロジー横断部４２、および緩和部４４を備える。
【０１１７】
図１１は、図１０に示すディスカバリー部２８とそのサブユニット３８〜４４の動作フローチャートを示す。
図１１に示すように、サービスオントロジー選択部３８は、開始サービスオントロジーを選択する（ステップＳ３６）。なお、２以上のサービスオントロジーがサービスディスカバリーに利用できるときにのみ、このステップＳ３６が実行される。
【０１１８】
また、本発明に係るサービスオントロジーの選択は、クエリータームにより得られる情報あるいはユーザープロフィールデータに依拠する。選択されるサービスオントロジーは、サービスディスカバリーの対象に最も適合するものである。
【０１１９】
図１１に示すように、開始位置決定部４０は、サービスディスカバリーのために、サービス特性の順で開始点を決定する（ステップＳ３８）。本発明によれば、クエリータームを開始概念としてサービスオントロジーに含め、開始概念に続く概念をサービスディスカバリーの開始点に設定することも提案されている。
【０１２０】
図１１に示すように、サービスオントロジー横断部４２は、記述されたディスカバリー文と選択されたサービスオントロジーにより報知されたサービス特性とを比較するために、このディスカバリー文に基づいて、選択されたサービスオントロジーを横行する（ステップＳ４０）。
【０１２１】
図１１に示すように、サービスオントロジー横断部４２は、サービスディスカバリーの成否を評価する（ステップＳ４２）。サービスディスカバリーに成功したときは、サービスディスカバリー処理は終了する。サービスディスカバリーに失敗したときは、サービスディスカバリー処理は、別の確認ステップＳ４４に進み、サービスディスカバリーの繰り返し数の上限に到達したか否かを評価する。上限に到達した場合には、サービスディスカバリー処理は終了する。
【０１２２】
図１１に示すように、サービスディスカバリーが未完であり、かつ繰返し数が上限に到達していない場合には、サービスディスカバリー処理はステップＳ４６に進み、緩和部が、ディスカバリー文を緩和させる（ステップＳ４６）。
【０１２３】
なお、例えば複数のサービスオントロジーが利用可能であるときには、種々のサービスオントロジーを選択してサービスディスカバリーを再び繰り返すことができるから、サービスディスカバリー中の緩和はオプションである。
【０１２４】
また、ユーザープリファレンス、用例パターン、あるいはサービス構想を反映するデータを例えばハード制約あるいはソフト制約として考慮して、ディスカバリー文の緩和をおこなうことができる。
【０１２５】
さらに緩和させることは、制約を弱め、制約を無視し、あるいは以前のディスカバリー文を使用して横行するときにサービスオントロジー中に適切な相手がなくなることを意味する。
【０１２６】
図１１に示すように、ディスカバリー文がステップＳ４６で緩和されるか否かによらず、サービスディスカバリーをさらに繰り返すために、この処理はステップＳ３６に戻る。
【０１２７】
以上、本発明の種々の実施形態と好適実施形態とを説明した。以下、図１２と図１３とを参照して、レストラン選択にこれらの実施形態を適用した例を説明する。
【０１２８】
以下の例では、サービスオントロジーがOntoEdit（Ontoprise, Ontology Engineering Workbench, OntoEdit, http://www.ontoprise.com）により生成され、「Preference SQL, Design, Implementation, Experiences（W. Kesling, G. Kostler, Proc. Of the Int. Conf. On Very Large Data Bases (VLDB´02)、香港、中国、２００２年）」に説明されている概念に沿った協調型データベースクエリー言語がディスカバリー文の構成に使用されることを仮定している。また、これから本発明の範囲が制約されることはないものとする。
【０１２９】
次の例は、地元のレストランのレストランサービスを、例えば移動端末を使用して見出そうとするサービスユーザに関する。
【０１３０】
この例では、サービスユーザは、夕食にレストランサービスを探すことができる。広東料理のレストランを予約するという要求を指定すると、サービスディスカバリーにより適切なサービスが得られるべきである。
【０１３１】
なお、図１２は、本発明に係るディスカバリー法の使用の一例として、レストランサービスのオントロジーを示す。図１３は、レストランサービスおよび、図１２に示すレストランサービスのオントロジーにしたがう依拠関係とを示す。
【０１３２】
図１２と図１３に示すレストランサービスのオントロジーは、サービス構想としての地方料理に集中している。また、クエリータームの拡張として異なる用例パターン：ビジネス/カジュアルが利用可能であると仮定することができる。
【０１３３】
ＳＱＬタイプの宣言型クエリー言語を使用すると、ディスカバリー文は次のように構成できる。
SELECT      grounding (service)
FROM        Cantonese
WHERE       category = casual.
【０１３４】
このディスカバリー文が適切なサービスを出力しないとき、あるいはサービスユーザが満足していない場合には、ディスカバリー文は、サービスオントロジーの構造に沿って、次のように広東料理から中華料理に緩和される。
SELECT          grounding (service)
FROM            Chinese
WHERE           category = casual.
この緩和は、適合する店（例えば山東楼）を見出すまで繰り返される。
【０１３５】
図１４に示すように、協調型リトリーブ技術を使用すると、一連の関連するディスカバリー文を単一のディスカバリー文に記載することが可能となる。ここまでに全体として説明したように、このディスカバリー文は、以下のサービス記述を含む協調型データベースで実行することができる。
SELECT      grounding (service)
FROM        Restaurant
WHERE      category = casual
PREFERRING (concept(service)) = Cantonese
PRIOR TO (concept(service)) = Chinese
PRIOR TO (concept(service)) = Asian.
【０１３６】
この例で、サービスディスカバリーを改善するために、サービスユーザの情報を含めることができる。サービスユーザが好みのレストランの様式を明確にわかっていると仮定できることがある。例えば、重要な顧客を歓待するためには、高級なフランス料理レストランあるいは和食レストラン、これらが無理な場合には小粋なイタリア料理店を好むと仮定できる場合がある。これらのユーザープリファレンスを含めるために、次のようにディスカバリー文を協調型リトリーブ用に再構成することができる。
SELECT      grounding (service)
FROM        Restaurant
WHERE      category = casual
PREFERRING (concept(service)) = French
OR (concept(service)) = Japanese
PRIOR TO (concept(service)) = Italian.
【０１３７】
ここまで全体として参照してきたサービスディスカバリーをパーソナル化する方法とは別の方法に、サービスディスカバリー中にサービス構想を考慮することがある。なお、サービスユーザがその趣向を明確に述べずに、飲食店の特定のサービス構想に依拠すると仮定できることがある。
【０１３８】
図１２および図１３に示すように、基本サービスオントロジーは、地域に基づく緩和を地理的領域のサービス構想におこなう。しかし、サービスユーザは、それぞれの地域ではなく、例えばホットかつスパイシーな食味の食べ物等、食味を重視して種々の飲食店を理解していることもある。すなわち、食味に基づくサービス構想を抱いていることもある。
【０１３９】
この点、例えば、インド料理レストランについてのクエリータームは、次のように食味に基づくサービス構想について拡張する必要があるであろう。
SELECT    grounding (service)
FROM      Restaurant
WHERE    category = business
AND    foodFlavour = hot
AND    foodFlavour = spicy
PREFERRING (concept(service)) = Indian
PRIOR TO (concept(service)) = Asian.
【０１４０】
この構文と図１２と図１３に示すサービスオントロジーとが与えられると、インド料理から辛くてスパイシーなアジア料理レストランサービスに向かって緩和がサービスディスカバリー中におこなわれる。食味が辛くてスパイシーと報知されているサービスを見出すことができないので、サービスディスカバリーは、サービスユーザのサービス構想を反映するハード制約により、他のアジア料理サービスの全てを無視し、最終的にレストランサービス「クオリティテキメキ」を見出す。
【０１４１】
以上説明した例もまた、協調型ディスカバリー文の構成および、引き続いておこなわれるこのディスカバリー文の例えば協調型データベース等のサービスカタログへの提示により、サービスディスカバリーが有効にパーソナル化できることを示している。本発明によれば、ユーザープリファレンスが明示的に与えられるときだけではなく、ユーザー指定のサービス構想でもこのことが可能である。
【０１４２】
また、適切な用例パターンにより、多様なサービスアプリケーションに役に立つ設定と、各ユーザーに使用可能なプリファレンスの特定の例とを含む実用的なデフォルトのモデルが提供される。
【図面の簡単な説明】
【０１４３】
【図１】本発明におけるサービス提供を説明する概念図である。
【図２】サービス選択をサポートするために、ウェブサービスを提供する、本発明に係る方法を示す図である。
【図３】サービス選択をサポートするために、セマンティックウェブサービスを提供する、本発明に係る方法を示す図である。
【図４】サービスオントロジーを使用することによりサービスディスカバリーをおこなう、本発明に係る装置の概念図である。
【図５】図４に示す装置の動作フローチャートである。
【図６】（ａ）、（ｂ）サービスオントロジーの構文の典型例である。
【図７】図４に示すディスカバリー文生成部の概念図である。
【図８】図７に示す拡張部の動作フローチャートである。
【図９】図７に示す用例パターン部の動作フローチャートである。
【図１０】図４に示すディスカバリー部の概念図である。
【図１１】図１０に示すディスカバリー部およびそのサブユニットの動作うフローチャートである。
【図１２】本発明に係るディスカバリーメカニズムの適用例として示すレストランサービスのオントロジーである。
【図１３】図１２に示すレストランサービスのオントロジーにしたがうレストランサービスおよび依拠関係を示す図である。
【図１４】本発明に係る、ステップバイステップ緩和および協調型ディスカバリー文の構成を示す図である。
【図１】
2006526186.tif 000009
【図２】
2006526186.tif 000010
【図３】
2006526186.tif 000011
【図４】
2006526186.tif 000012
【図５】
2006526186.tif 000013
【図６】
2006526186.tif 000014
【図７】
2006526186.tif 000015
【図８】
2006526186.tif 000016
【図９】
2006526186.tif 000017
【図１０】
2006526186.tif 000018
【図１１】
2006526186.tif 000019
【図１２】
2006526186.tif 000020
【図１３】
2006526186.tif 000021
【図１４】
2006526186.tif 000022
【手続補正書】
【提出日】平成18年1月23日(2006.1.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信システムで報知される少なくとも１つのサービスを見出す方法において、
サービス特性の序列を記述する少なくとも１つのサービスオントロジーをサービスクエリーとして受信するステップと、
前記サービスオントロジーの関数としてディスカバリー文を記述するステップと、
前記サービスオントロジーに示された序列を使用して前記ディスカバリー文に適合するサービス属性を有するサービスを見出すステップと
を有する方法。
【請求項２】
前記サービスオントロジー中におけるサービス特性の序列が階層的に与えられることを特徴とする請求項１に記載の方法。
【請求項３】
前記ディスカバリー文を記述するステップが、用例パターンを反映するパラメータで前記サービスクエリーを拡張するステップを有することを特徴とする請求項１又は２に記載の方法。
【請求項４】
クエリーパラメータの種類およびその値と、用例パターンパラメータの種類およびその値とを比較するステップと、
前記比較結果にしたがって、サービスクエリーと最も適合する用例パターンを選択するステップとを
有するサービスクエリーを用例パターンに割り当てるステップをさらに有することを特徴とする請求項３に記載の方法。
【請求項５】
前記ディスカバリー文を記述するステップが、ユーザープリファレンスを反映するパラメータで前記サービスクエリーを拡張するステップを有することを特徴とする請求項１ないし４のいずれか一つに記載の方法。
【請求項６】
前記ディスカバリー文を記述するステップが、ユーザープリファレンスあるいはユーザーパターンの少なくとも一つを表すソフト制約パラメータで前記サービスクエリーを拡張するステップを有することを特徴とする請求項３ないし５のいずれか一つに記載の方法。
【請求項７】
前記ディスカバリー文を記述するステップが、ユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つを表すハード制約パラメータで前記サービスクエリーを拡張するステップを有することを特徴とする請求項３ないし５のいずれか一つに記載の方法。
【請求項８】
前記サービスを見出すステップが、続くサービスディスカバリーの開始点をサービスオントロジーの中で決定するステップを有し、
サービスディスカバリーの開始点の決定が、
ユーザのサービスに対する見解を反映する開始概念として、前記サービスクエリーを前記サービスオントロジーに含めるステップと、
前記開始概念に後続する概念をサービスディスカバリーの開始点として設定するステップと
によりおこなわれることを特徴とする請求項１ないし７のいずれか一つに記載の方法。
【請求項９】
前記サービスを見出すステップが、記述されたディスカバリー文について前記サービスオントロジーを横行するステップを有することを特徴とする請求項１ないし８のいずれか一つに記載の方法。
【請求項１０】
サービスディスカバリーを繰り返すために、サービスオントロジーに示された緩和序列にしたがってディスカバリー文を緩和するステップをさらに有することを特徴とする請求項１ないし９のいずれか一つに記載の方法。
【請求項１１】
通信システムで報知される少なくとも１つのサービスを見出す装置において、
サービス特性およびサービス属性を記述する少なくとも１つのサービスオントロジーをサービスクエリーとして記憶する記憶部と、
サービス特性の序列を記述する少なくとも１つのサービスオントロジーをサービスクエリーとして受信する受信部と、
前記サービスオントロジーの関数としてディスカバリー文を記述するディスカバリー文生成部と、
サービスオントロジーに示された序列を使用して前記ディスカバリー文に適合するサービス属性を有するサービスを見出すディスカバリー部と、
を有する装置。
【請求項１２】
前記記憶部が、前記サービスオントロジー中におけるサービス特性の序列を階層的に記憶することを特徴とする請求項１１に記載の装置。
【請求項１３】
ディスカバリー文生成部が、用例パターンを反映するパラメータで前記サービスクエリーを拡張する拡張部を有すること特徴とする請求項１１又は１２に記載の装置。
【請求項１４】
クエリーパラメータの種類とその値と、用例パターンパラメータの種類とその値とを比較し、
前記比較結果にしたがってサービスクエリーと最も適合する用例パターンを選択することにより、
サービスクエリーを用例パターンに割り当てる
用例パターン部を有する
ことを特徴とする請求項１３に記載の装置。
【請求項１５】
ユーザープリファレンスを反映するパラメータで前記サービスクエリーを拡張する拡張部を有することを特徴とする請求項１１ないし１４のいずれか一つに記載の装置。
【請求項１６】
前記ディスカバリー文生成部が、ユーザープリファレンスあるいは用例パターンの少なくとも一つを表すソフト制約パラメータで前記サービスクエリーを拡張するソフト制約部を有することを特徴とする請求項１３ないし１５のいずれか一つに記載の装置。
【請求項１７】
前記ディスカバリー文生成部が、ユーザープリファレンス、用例パターン、あるいはサービス構想の少なくとも一つを表すハード制約パラメータで前記サービスクエリーを拡張するハード制約部を有することを特徴とする請求項１３ないし１５のいずれか一つに記載の装置。
【請求項１８】
前記ディスカバリー部が、
前記サービスクエリーを開始概念としてサービスオントロジーに含め、
前記開始概念に序列で後続する概念をサービスディスカバリーの開始点として設定することにより、
続くサービスディスカバリーの開始点を決定する開始点をサービスオントロジーの中で決定する開始点決定部を有することを特徴とする請求項１１ないし１７のいずれか一つに記載の装置。
【請求項１９】
前記ディスカバリー部が、記述されたディスカバリー文について前記サービスオントロジーを横行するサービスオントロジー横断部を有することを特徴とする請求項１１ないし１８のいずれか一つに記載の装置。
【請求項２０】
前記ディスカバリー部が、サービスディスカバリーを繰り返すために、サービスオントロジーの緩和序列にしたがって、ディスカバリー文を緩和する緩和部を有することを特徴とする請求項１１ないし１９のいずれか一つに記載の装置。
【請求項２１】
少なくとも１つのサービスオントロジーを使用して報知される少なくとも１つのサービスを見出す装置の内部メモリに直接ロード可能であり、この装置のプロセッサで実行されると、請求項１ないし１０のいずれかの方法をその装置に実行させるソフトウェア部分コードを含むコンピュータプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
サービスディスカバリーの別の方法には、ＷＳＤＬ（Web Service Description Language、Web Service Description Language WSDL 1.1, E. Christensen, F. Curbera、G. Meredith, S. Weerawarana, http://www.w3.org/TR/2001/NOTE-wsdl-20010315、２００１年）、あるいはｅｂＸＭＬ（公式ウェブサイトhttp://www.ebXML.org）がある。現在のところ、ビジネス−ビジネス間（Ｂ２Ｂ）サービス提供環境では、ＷＳＤＬあるいはｅｂＸＭＬがサービスカタログの実装に積極的に使用されている。しかし、依然としてこれらの方法には、サービスのパーソナル化という有用な概念が欠落している。
【特許文献１】国際公開０２／０９５６２４号パンフレット
【特許文献２】特開２０００−１３７７３８号公報
【特許文献３】特開２０００−０８２０６７号公報
【国際調査報告】
2006526186.tif 000023
2006526186.tif 000024
2006526186.tif 000025