(57)【要約】【課題】ユーザ要求にマッチしたＷｅｂサービス情報をより多く得られるアプリケーションプログラムプラン生成システムを実現する。【解決手段】本発明のアプリケーションプログラムプラン生成方法は、１つのアプリケーションプログラムに関して、事前条件の述語とユーザデータの述語とのマッチング、及び、事後条件の述語とユーザ要求の述語とのマッチングを行う第１のステップを含む。さらに、１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、事前条件の述語と第１のステップにおいてマッチングの取れていないユーザデータの述語を含む第１の述語とのマッチング、及び、事後条件の述語と第１のステップにおいてマッチングの取れていないユーザ要求の述語を含む第２の述語とのマッチングを行う第２のステップが吹くまれる。【選択図】　図７
2004062536.tif 000002
【特許請求の範囲】
【請求項１】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データをストアする第１のメモリ部と、
述語で記述されたユーザに関するユーザデータをストアする第２のメモリ部と、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するプラン生成部とを有し、
前記プラン生成部は、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の処理と、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２の処理と、
を実行することを特徴とするアプリケーションプログラムプラン生成装置。
【請求項２】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データをストアする第１のメモリ部と、
述語で記述されたユーザに関するユーザデータをストアする第２のメモリ部と、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するプラン生成部とを有し、
前記プラン生成部は、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の処理と、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３の処理と、
を実行することを特徴とするアプリケーションプログラムプラン生成装置。
【請求項３】
前記プラン生成部は、前記第１の処理の結果及び前記第２の処理の結果に基づいて、複数のアプリケーションプログラムの組合せの情報を出力することを特徴とする請求項１に記載のアプリケーションプログラムプラン生成装置。
【請求項４】
前記プラン生成部は、前記第１の処理の結果及び前記第３の処理の結果に基づいて、複数のアプリケーションプログラムの組合せの情報を出力することを特徴とする請求項２に記載のアプリケーションプログラムプラン生成装置。
【請求項５】
前記アプリケーションプログラムは、インターネットを介してアクセス可能なＷｅｂサービスであることを特徴とする請求項１から請求項４のいずれかに記載のアプリケーションプログラムプラン生成装置。
【請求項６】
前記第１の述語は、さらに前記事後条件の述語を含むことを特徴とする請求項１、請求項３又は請求項５に記載のアプリケーションプログラムプラン生成装置。
【請求項７】
前記プラン生成部は、前記第１の処理と前記第２の処理を、前記アプリケーションプログラム定義データ毎に、実行することを特徴とする請求項１、請求項３、請求項５又は請求項６に記載のアプリケーションプログラムプラン生成装置。
【請求項８】
前記第２の処理は、前記第１の処理を再帰的に呼び出して実行されることを特徴とする請求項１、請求項３、請求項５、請求項６又は請求項７に記載のアプリケーションプログラムプラン生成装置。
【請求項９】
前記プラン生成部は、前記第１の処理と前記第３の処理を、前記アプリケーションプログラム定義データ毎に、実行することを特徴とする請求項２、請求項４又は請求項５に記載のアプリケーションプログラムプラン生成装置。
【請求項１０】
前記第３の処理は、前記第１の処理を再帰的に呼び出して実行されることを特徴とする請求項２、請求項４、請求項５又は請求項９に記載のアプリケーションプログラムプラン生成装置。
【請求項１１】
さらに、各ノードに述語が定義され、複数のレベルの階層構造を持った複数のノードのツリー構造を有するオントロジ辞書部を有し、
前記ユーザ要求に含まれる述語が、前記レベルに応じて、変更されることを特徴とする請求項１から請求項１０のいずれかに記載のアプリケーションプログラムプラン生成装置。
【請求項１２】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、
述語で記述されたユーザに関するユーザデータと、を用いて、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成方法であって、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１のステップと、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２のステップと、
を有することを特徴とするアプリケーションプログラムプラン生成方法。
【請求項１３】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、
述語で記述されたユーザに関するユーザデータと、を用いて、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成方法であって、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１のステップと、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３のステップと、
を有することを特徴とするアプリケーションプログラムプラン生成方法。
【請求項１４】
さらに、前記第１のステップの処理結果及び前記第２のステップの処理結果に基づいて、複数のアプリケーションプログラムの組合せの情報を出力する第３のステップを有することを特徴とする請求項１２に記載のアプリケーションプログラムプラン生成方法。
【請求項１５】
さらに、前記第１のステップの処理結果及び前記第３のステップの処理結果に基づいて、複数のアプリケーションプログラムの組合せの情報を出力する第４のステップを有することを特徴とする請求項１３に記載のアプリケーションプログラムプラン生成方法。
【請求項１６】
前記アプリケーションプログラムは、インターネットを介してアクセス可能なＷｅｂサービスであることを特徴とする請求項１２から請求項１５のいずれかに記載のアプリケーションプログラムプラン生成方法。
【請求項１７】
前記第１の述語は、さらに前記事後条件の述語を含むことを特徴とする請求項１２、請求項１４又は請求項１６に記載のアプリケーションプログラムプラン生成方法。
【請求項１８】
前記第１のステップと前記第２のステップは、前記アプリケーションプログラム定義データ毎に、実行されることを特徴とする請求項１２、請求項１４、請求項１６又は請求項１７に記載のアプリケーションプログラムプラン生成方法。
【請求項１９】
前記第２のステップは、前記第１のステップを再帰的に呼び出して実行されることを特徴とする請求項１２、請求項１４、請求項１６、請求項１７又は請求項１８に記載のアプリケーションプログラムプラン生成方法。
【請求項２０】
前記第１のステップと前記第３のステップは、前記アプリケーションプログラム定義データ毎に、実行されることを特徴とする請求項１３、請求項１５又は請求項１６に記載のアプリケーションプログラムプラン生成方法。
【請求項２１】
前記第３のステップは、前記第１のステップを再帰的に呼び出して実行されることを特徴とする請求項１３、請求項１５、請求項１６又は請求項２０に記載のアプリケーションプログラムプラン生成方法。
【請求項２２】
さらに、各ノードに述語が定義され、複数のレベルの階層構造を持った複数のノードのツリー構造を有するオントロジ辞書データを用いて、
前記ユーザ要求に含まれる述語が、前記レベルに応じて、変更されることを特徴とする請求項１２から請求項２１のいずれかに記載のアプリケーションプログラムプラン生成方法。
【請求項２３】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、
述語で記述されたユーザに関するユーザデータと、を用いて、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成用のプログラムであって、
コンピュータに、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の機能と、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２の機能とを実現させるためのプログラム。
【請求項２４】
請求項２３に記載のプログラムを記録した記録媒体。
【請求項２５】
事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、
述語で記述されたユーザに関するユーザデータと、を用いて、
前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成用のプログラムであって、
コンピュータに、
１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の機能と、
前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３の機能とを実現させるためのプログラム。
【請求項２６】
請求項２５に記載のプログラムを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションプログラムプラン生成装置、アプリケーションプログラムプラン生成方法、プログラム及び記録媒体に関し、特に、ネットワークを介してアクセス可能な複数のアプリケーションプログラムに関するアプリケーションプログラムプラン生成装置、アプリケーションプログラムプラン生成方法、プログラム及び記録媒体に関する。
【０００２】
【従来の技術】
最近、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ　Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，ａｎｄ　Ｉｎｔｅｇｒａｔｉｏｎ）という技術が注目されている。ＵＤＤＩは、インターネット上に存在するＷｅｂサービスを検索・照会することができるシステムである。具体的には、ＵＤＤＩでは、インターネット上にどのようなＷｅｂサービスがあるかという情報をレジストリというデータベースに登録しておき、そのデータベースを、第三者が検索し、必要なＷｅｂサービスを探し出すことができるようになっている。レジストリに登録されているデータは、サービス名、登録者、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等である。Ｗｅｂサービスを提供している企業等が、レジストリにこれらのデータを登録する。
【０００３】
従って、Ｗｅｂサービスの検索者は、そのサービスに関する言葉をキーワードとして、レジストリのデータを検索することによって、必要とするＷｅｂサービスを見つけることができる。
【０００４】
【発明が解決しようとする課題】
しかし、サービス検索者が入力したキーワードに基づいて、レジストリのデータの検索が行われる場合、サービス検索者が使用した用語が、あるＷｅｂサービスについてＷｅｂサービス提供企業等が、レジストリに登録した用語と異なると、そのＷｅｂサービスは検索結果に含まれなくなる。例えば、そのＷｅｂサービスについて登録された用語の中には、サービス検索者が使用した複数の用語の一部のみしか含まれていないときは、そのＷｅｂサービスの機能は、サービス検索者の要求を満足しないものとして、検索結果には含まれない。
【０００５】
そのため、複数のＷｅｂサービスを連携して利用すれば、サービス検索者の要求が満たされる場合があっても、そのような複数のＷｅｂサービスの組み合わせが連携プランとして提示されることはなかった。
【０００６】
【課題を解決するための手段】
そこで、本発明は、複数のＷｅｂサービスを連携して利用すれば、サービス検索者の要求が満たされるプランを提示することができるアプリケーションプログラムプラン生成システムを提供することを目的とする。
【０００７】
本発明のアプリケーションプログラムプラン生成装置は、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データをストアする第１のメモリ部と、述語で記述されたユーザに関するユーザデータをストアする第２のメモリ部と、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するプラン生成部とを有し、前記プラン生成部は、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の処理と、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２の処理とを実行する。
【０００８】
本発明のアプリケーションプログラムプラン生成装置は、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データをストアする第１のメモリ部と、述語で記述されたユーザに関するユーザデータをストアする第２のメモリ部と、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するプラン生成部とを有し、前記プラン生成部は、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の処理と、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３の処理とを実行。
【０００９】
本発明のアプリケーションプログラムプラン生成方法は、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、述語で記述されたユーザに関するユーザデータと、を用いて、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成方法であって、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１のステップと、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２のステップとを有する。
【００１０】
本発明のアプリケーションプログラムプラン生成方法は、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、述語で記述されたユーザに関するユーザデータと、を用いて、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成方法であって、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１のステップと、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１のステップにおいてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３のステップと、を有する。
【００１１】
本発明のプログラムは、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、述語で記述されたユーザに関するユーザデータと、を用いて、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成用のプログラムであって、コンピュータに、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の機能と、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事前条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザデータの述語を含む第１の述語とのマッチング、及び、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第２の述語とのマッチングを行う第２の機能とを実現させる。
【００１２】
本発明のプログラムは、事前条件と事後条件が述語によって定義されたデータであって、ネットワークを介してアクセス可能な複数のアプリケーションプログラムの定義情報に関するアプリケーションプログラム定義データと、述語で記述されたユーザに関するユーザデータと、を用いて、前記複数のアプリケーションプログラムの中から、述語で記述されたユーザ要求を満足するアプリケーションプログラムに関する情報をプランとして生成するアプリケーションプログラムプラン生成用のプログラムであって、コンピュータに、１つのアプリケーションプログラムに関して、前記事前条件の述語と前記ユーザデータの述語とのマッチング、及び、前記事後条件の述語と前記ユーザ要求の述語とのマッチングを行う第１の機能と、前記１つのアプリケーションプログラム以外の他のアプリケーションプログラムに関して、前記事後条件の述語と前記第１の処理においてマッチングの取れていない前記ユーザ要求の述語を含む第３の述語とのマッチングを行う第３の機能とを実現させる。
【００１３】
本発明の記録媒体は、本発明のプログラムを記録した記録媒体である。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
【００１５】
まず図１に基づき、本実施の形態に係わるシステムの構成を説明する。図１は、本実施の形態に係わるアプリケーションプログラムプラン提示システムの構成を示す構成図である。
【００１６】
１は、ウエブサーバ装置（以下、ウエブサーバという）であり、２は、ユーザが操作するパーソナルコンピュータ（以下、ＰＣという）である。
【００１７】
ウエブサーバ１及び複数のＰＣ２はインターネット３に接続されている。４は、Ｗｅｂサービス用プログラムを有するサービス提供コンピュータである。４−１から４−ｎ（ｎは整数）からなるｎ台のサービス提供コンピュータも、ウエブサーバ１および複数のＰＣ２と同様に、インターネット３に接続されている。
【００１８】
Ｗｅｂサービスは、インターネットを利用してアクセス可能なアプリケーションプログラムである。（従って、以下、Ｗｅｂサービスは、アプリケーションプログラムともいう。）人間あるいはコンピュータプログラムであるユーザは、インターネットを介して、そのアプリケーションプログラムを呼び出すことによって、そのアプリケーションプログラムを実行し、実行結果を利用することができる。
【００１９】
アプリケーションプログラムプラン提示システムは、後述するように、ユーザであるＰＣ２からの要求を受信すると、その要求を満たすＷｅｂサービスに関する情報を、複数のＷｅｂサービスを組み合せた連携プランも含むプランとして、ＰＣ２へ送信して提示するシステムである。
【００２０】
なお、プランとは、アプリケーションプログラム定義データ、例えば、Ｗｅｂサービスの識別子の情報を含む情報である。さらに、プランの中でも連携プランは、アプリケーションプログラム定義データの組合せ情報であって、例えば、順序付けられたＷｅｂサービスの識別子の系列の情報を含む情報である。ここでは、系列の情報は、後述するように、識別子の間を「；」で区切って表現される。Ｗｅｂサービスに関する情報としては、Ｗｅｂサービスの識別子、Ｗｅｂサービスの呼び出しに必要なパラメータ、Ｗｅｂサービスの機能のデータ等である。ＰＣ２からの要求は、人間がＰＣ２を操作してＰＣ２からウエブサーバ１へ送信されるか、あるいはＰＣ２において実行されるコンピュータプログラムによって生成されてウエブサーバ１へ送信される。
【００２１】
なお、以下は、アプリケーションプログラムが、インターネットを利用したＷｅｂサービスである例を用いて説明するが、インターネットでない通信回線を利用してアクセス可能なアプリケーションプログラムであってもよい。
【００２２】
ウエブサーバ１には、インターネット４上にどのようなＷｅｂサービスがあるかというＷｅｂサービスデータが、後述するレジストリというデータベースに予め登録されている。ユーザは、その登録、すなわちストアされたＷｅｂサービスデータを検索して、Ｗｅｂサービスに関する情報、例えばそのユーザが利用したいＷｅｂサービスの有無、その呼び出し方法等の情報の提供を受けることができる。
【００２３】
図２は、図１のウエブサーバ１の構成を示す構成図である。アプリケーションプログラムプランの生成及び提示装置であるウエブサーバ装置１は、プラン生成部１１と、ユーザデータ部１２と、オントロジ辞書部１３と、Ｗｅｂサービスデータ部１４とを含む。ユーザデータ部１２、オントロジ辞書部１３及びＷｅｂサービスデータ部１４のデータは、夫々対応するメモリ装置にストアされている。プラン生成部１１は、ユーザの要求を満たすＷｅｂサービスに関する情報を生成する処理を行なうプログラムである。オントロジ辞書部１３は、ユーザ要求、Ｗｅｂサービス等を記述する述語を関連付けて体系化したデータベースである。ここで述語とは、述語論理による記法をいう。具体的には、複数のノードがツリー形式で関連付けられ、各ノードにおいて述語が定義されている。Ｗｅｂサービスデータ部１４は、Ｗｅｂサービスの定義情報であるＷｅｂサービスデータを含み、レジストリにＷｅｂサービスデータが登録されている。
【００２４】
プラン生成部１１は、ユーザ要求解析部１５と、連携プラン生成部１６を含む。ユーザ要求解析部１５は、インターネット３を介して受信した、ユーザであるＰＣ２からの要求の解析処理を行うプログラムである。ユーザ要求解析部１５と、連携プラン生成部１６の処理内容は後述する。
【００２５】
なお、ユーザデータ部１２、オントロジ辞書部１３及びＷｅｂサービスデータ部１４は、ウエブサーバ１内に設けずに、別途設けたネットワーク（図示せず）を介してウエブサーバ１と接続された別の情報処理装置内のメモリ装置に設けるようにしてもよい。
【００２６】
図３は、ユーザデータ部１２のデータ構成を説明するための図である。ここでは、あるユーザの２つのデータのみを示すが、ユーザデータ部１２には複数のユーザの複数のデータがストアされている。
【００２７】
図３において、各ユーザデータは、識別子２１、ユーザ識別子２２、述語２３及び利用可否２４の４つの項目のデータを含む。ユーザデータは、ユーザの条件情報、利用実績情報等に関するデータである。識別子２１は、各ユーザデータの識別のためのデータである。ユーザ識別子２２は、ユーザを識別するためのデータである。
【００２８】
述語２３は、ユーザの条件、利用実績等の内容を述語により記述されたデータである。利用可否２４は、連携プラン生成部１６において、そのユーザデータを利用するか否かを示すデータである。
【００２９】
ユーザデータ２５は、識別子２１が、「Ｄ１」であり、ユーザ識別子２２が、「田中」であり、述語２３が、「ＬｏｃａｔｅｄＡｔ（田中，東京）」であり、利用可否２４が、「可」であることを示している。
【００３０】
ここでは、述語２３において、「ＬｏｃａｔｅｄＡｔ」の部分は、述語記号であり、「（田中，東京）」の部分は、引数である。従って、述語２３の「ＬｏｃａｔｅｄＡｔ（田中，東京）」は、「ユーザである田中は、東京に住んでいる」ことを意味している。利用可否データ２４の「可」は、「ユーザデータ２５は、後述するプラン生成時に利用される」ことを意味している。同様に、ユーザデータ２６は、識別子２１が、「Ｄ２」であり、ユーザ識別子２２が、「田中」であり、述語２３が、「ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ（田中，Ａ社）」であり、利用可否２４が、「否」であることを示している。ここで、述語２３の「ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ（田中，Ａ社）」は、「ユーザである田中は、Ａ社のマイレージのアカウントを持っている」ことを意味している。利用可否データ２４の「否」は、「ユーザデータ２６は、後述するプラン生成時に利用されない」ことを意味している。
【００３１】
図４は、オントロジ辞書部１３のデータ構造を説明するための図である。オントロジ辞書部１３は、述語が分類された述語の辞書のデータであり、ノードとノード間を結ぶリンクからなる。図４において、識別子として、「旅行」というラベルが付けられたルートノード３１は、４つのノード３２、３３、３４、３５とリンクが張られて、すなわち結ばれている。ノード３２には、「旅行代理店」というラベルが付けられ、ノード３３には、「飛行機」というラベルが付けられ、ノード３４には、「鉄道」というラベルが付けられ、ノード３５には、「ホテル」というラベルが付けられている。ノード３３は、さらにノード３６と結ばれている。ノード３６には、「飛行機＋マイレージ」というラベルが付けられている。ノード３５は、さらにノード３７、３８と結ばれている。ノード３７には、「ホテル＋マイレージ」というラベルが付けられ、ノード３８には、「ホテル＋リピート割引」　というラベルが付けられている。
【００３２】
各ノードには、述語が定義、すなわち関連付けられている。言い換えると、各ノードは、その定義された述語の集合のデータを有している。図４において、Ｐの式は、述語の集合を示している。例えば、ノード３１には、２つの述語が定義され、ノード３１は、２つの述語、すなわち、「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｌｏｃａｔｉｏｎ）」と「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）」の２つの述語の集合のデータを有していることを示している。ノード３２は、１つの述語、すなわち、「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｌｏｃａｔｉｏｎ）」の１つの述語の集合のデータを有していることを示している。
【００３３】
図４に示すように、オントロジ辞書部１３は、ノード３１をレベル０（ゼロ）とし、ノード３１と結ばれたノード３２から３５をレベル１とし、レベル１のノードと結ばれたノード３６から３８をレベル２とする階層構造を持った、述語のツリー構造を有する。このオントロジ辞書部１３のデータを利用するときに、利用されるレベルが予め指定される。例えば、指定されたレベルが０（ゼロ）であると、レベル１とレベル２の用語は利用されない。指定されたレベルが１であると、レベル０とレベル１の用語は利用されるが、レベル２の用語は利用されない。指定されたレベルが２であると、レベル０、レベル１及びレベル２の用語が利用される。このように、利用される用語の深さを指定することによって、関連する用語の範囲を変更することができる。
【００３４】
例えば、ユーザからの要求に基づいて後述する論理式データを生成するときにこのオントロジ辞書部１３の辞書データを利用するとする。そのとき、レベルが０（ゼロ）に指定されると、ユーザ要求の用語のみの述語が用いられて論理式データが生成される。もしも、レベルが１に指定されると、ユーザ要求の用語に加えて、その用語と結ばれているレベル１の用語も併せて用いられて論理式データが生成される。
【００３５】
図５は、Ｗｅｂサービスデータ部１４のデータ構成を説明するための図である。図５は、７つのＷｅｂサービスデータ４１から４７の例を示す。図５において、各Ｗｅｂサービスデータは、Ｗｅｂサービスの定義情報としての、サービスＩＤ、述語、サービス内容、事前条件及び事後条件の項目に関するのＷｅｂサービス記述データを含む。
【００３６】
サービスＩＤは、各Ｗｅｂサービスの識別子データである。Ｗｅｂサービスデータ４１では、サービスＩＤは「Ｓ１」である。
【００３７】
述語は、述語記号と引数からなり、カッコ内が引数である。Ｗｅｂサービスデータ４１では、「ＴｒａｖｅｌＡｇｅｎｃｙＳｅｒｖｉｃｅ」が述語記号であり、カッコ内の「ｕｓｅｒ，ｆｒｏｍ，ｔｏ」が変数である。述語は、そのＷｅｂサービスにおいて、受けられるサービスの内容を示す。従って、Ｗｅｂサービスデータ４１では、「ＴｒａｖｅｌＡｇｅｎｃｙＳｅｒｖｉｃｅ」のサービスを受けられることを示している。
【００３８】
サービス内容には、そのＷｅｂサービスのサービスの内容が記述され、その記述は自然言語である。Ｗｅｂサービスデータ４１において、サービス内容は、「旅行代理店」に関するものであることが示されている。
【００３９】
事前条件は、そのＷｅｂサービスを受けるための必要条件であり、述語で記述される。従って、サービス検索者は、Ｗｅｂサービスデータ４１の事前条件「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」を満たすと、そのＷｅｂサービスを利用することができる。
【００４０】
事後条件は、そのＷｅｂサービスを受けた結果としてどうなるか、すなわち効果であり、述語で記述される。Ｗｅｂサービスデータ４１は、論理式「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）∧ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）　∧ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」で効果が表現される。すなわち、Ｗｅｂサービスデータ４１では、事後条件は、３つの述語の論理積である。
【００４１】
なお、述語、事前条件及び事後条件において、引数は変数である。
【００４２】
同様に、Ｗｅｂサービス４２は、サービスＩＤが「Ｓ２」であり、「ｕｓｅｒ，ｆｒｏｍ，ｔｏ」を引数とする「ＡｉｒｌｉｎｅＳｅｒｖｉｃｅ」のサービスを受けられることを示している。サービス内容は、「飛行機」に関するものである。事前条件は、述語「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」であり、事後条件は、「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）∧ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」であることを示している。Ｗｅｂサービスデータ４２では、事後条件は、２つの述語の論理積である。
【００４３】
同様に、Ｗｅｂサービスデータ４３から４７についても、サービスＩＤ、述語、サービス内容、事前条件及び事後条件が定義されている。
【００４４】
このような各種データを用いて、どのようにサービス検索者の要求が満たされるプランが提示されるかを、以下、例を用いて説明する。
【００４５】
ここでは、ある人が旅行をする場合に、その旅行について種々の情報を提供してくれるＷｅｂサービスを探す場合について説明する。
【００４６】
まず、ユーザであるＰＣ２からインターネット４を介してウエブサーバ１へ、旅行に関するＷｅｂサービスを探す要求データが送信される。このとき、ユーザであるＰＣ２は、予め決められたプログラムに基づいて、旅行をする者、出発地及び目的地等の要求データを生成し、ウエブサーバ１へ送信する。例えば、「田中」さんが、「東京」から「大阪」へ旅行し、「大阪」で宿泊する旅行するのだが、その旅行に関するＷｅｂサービスを探したい、旨の要求データがＰＣ２からウエブサーバ１へ送信される。
【００４７】
次は、送信される要求データの例を示す。
【００４８】
（式１）
Ｔｒａｖｅｌｅｄ（田中，東京，大阪）∧ＳｔａｙｅｄＡｔ（田中，大阪）
この要求データは、２つの述語の論理積の論理式形式のデータである。
【００４９】
なお、この要求データは、ＰＣ２において生成されてもよいし、あるいはＰＣ２から送信されたデータに基づいて、ウエブサーバ１において生成されてもよい。
【００５０】
この要求データを受信したウエブサーバ１は、受信した要求データに基づいて、ユーザデータとして「田中」さんが含まれていることを検出することができる。従って、ウエブサーバ１は、図３のユーザデータ部１２のデータを検索し、「田中」さんに関するユーザデータを抽出する。その結果、図３に示す２つのユーザデータが抽出されたとする。
【００５１】
次に、事前条件の述語とユーザデータの述語のマッチングを行う。マッチングとは、２つの述語が一致しているか否かのチェックをいう。述語のマッチングは、述語の述語記号と引数を記号あるいは記号列とみなし、２つの記号、すなわち文字列が一致するか否かで判定を行うことをいう。なお、図３に示すように、ユーザデータ２６については、利用可否のデータが「否」となっているので、「ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ」は、マッチングの対象から除かれる。従って、「田中」さんのユーザデータの中にある「ＬｏｃａｔｅｄＡｔ」の述語記号が、Ｗｅｂサービスデータの事前条件の中の述語記号と一致するものがあるかを判断される。図５のＷｅｂサービスデータにおいては、「ＬｏｃａｔｅｄＡｔ」の述語記号を事前条件に含むものとしては、７つ全てのＷｅｂサービスデータが該当する。
【００５２】
そして、事前条件の「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」の変数に値を入れて単一化（ユニフィケーション（ｕｎｉｆｉｃａｔｉｏｎ））することによって、述語データが生成される。ここで、単一化とは、述語の変数の値をある値に置き換えてマッチさせることをいう。なお、ここの例では、ユーザデータの「ＬｏｃａｔｅｄＡｔ（田中，東京）」と事前条件の「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」とを比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京という単一化によって、「ＬｏｃａｔｅｄＡｔ（田中，東京）」という述語が生成される。
【００５３】
次に、式１に示す要求データに含まれる述語に基づいて、単一化によって、事後条件の述語が生成される。Ｗｅｂサービスデータ４１においては、論理式「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）∧ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）∧ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」に、上記式１の値を入れることによって、事後条件の論理式「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）∧ＳｔａｙｅｄＡｔ（田中，大阪）∧ＬｏｃａｔｅｄＡｔ（田中，大阪）」のデータが生成される。なお、ここで、「ＬｏｃａｔｅｄＡｔ（田中，大阪）」は、「田中」さんが移動した結果、「田中」さんが「大阪」にいることを示す。
【００５４】
また、あるＷｅｂサービスの事前条件の単一化に成功すると、同じ単一化は、そのＷｅｂサービスの事後条件にも適用される。すなわち、事前条件と独立して、事後条件の単一化が行われるのではない。
【００５５】
事前条件の述語の単一化、あるいはマッチングに失敗すれば、そのＷｅｂサービスを受けることができず、さらに、事前条件の述語が生成できても、単一化により得られた事後条件の述語が、ユーザ要求の述語を満足していなければ、サービス検索者はそのＷｅｂサービスを利用することはできない。
【００５６】
図５の例であれば４１から４７の７つのＷｅｂサービスにおいて、事前条件の述語の生成はできるが、Ｗｅｂサービスデータ４１以外は、ユーザの要求を満足する事後条件の述語を生成することができない。よって、Ｗｅｂサービスデータ４１のみがユーザの要求を満足することになるので、Ｗｅｂサービス４１を、ユーザの要求に対するプランの１つとすることができる。
【００５７】
以上は、１つのＷｅｂサービスによってユーザの要求が満足されるかを判断している。本実施の形態では、さらに、複数のＷｅｂサービスを組み合せることによって、すなわち、複数のＷｅｂサービスの連携をとることによってユーザの要求を満足するプランがあるか否かを判断する。
【００５８】
例えば、Ｗｅｂサービスデータ４２と４４の場合、事後条件に記述記号がＳｔａｙｅｄＡｔである述語が存在しないので、「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）」について述語を生成することができないが、「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）」と「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）」については単一化によって「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」と「ＬｏｃａｔｅｄＡｔ（田中，大阪）」の２つの述語を生成することができる。
【００５９】
次に、その述語を事前条件として、Ｗｅｂサービスデータの中で、「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）」について述語を生成することができるＷｅｂサービスデータがあるか否かを探す。すなわち、一つのＷｅｂサービスデータでは、ユーザの要求するＷｅｂサービスを提供できないが、組み合せて連携をとることによってユーザの要求を満足するＷｅｂサービスを提供できる、他のＷｅｂサービスデータを探す。
【００６０】
具体的には、まず、生成された述語データと、他のＷｅｂサービスデータの事前条件の述語データとのマッチングをとる。言い換えれば、あるＷｅｂサービスデータにおいて、生成された事後条件である述語を事前条件としたときに、生成される事後条件が、未だ満たされていないユーザ要求の述語を生成するか否かをチェックする。
【００６１】
例えば、Ｗｅｂサービス４２に対しては、事後条件の述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」と述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」が生成される。生成された述語を優先することによって、述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」を事前条件として、Ｗｅｂサービス４２以外のサービスについて、事後条件を生成する。そして、そのＷｅｂサービス４２以外のサービスについて生成された事後条件と、Ｗｅｂサービス４２で生成された事後条件とを組み合せることによって、ユーザの要求を満たすかを判断する。
【００６２】
例えば、Ｗｅｂサービス４２とＷｅｂサービス４３を比べると、Ｗｅｂサービス４３の事前条件には、「ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ」を含むため、Ｗｅｂサービスデータ４２とユーザデータでは、事前条件を満たさない。しかし、Ｗｅｂサービス４５の事前条件は、述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」のみであり、Ｗｅｂサービスデータ４２とユーザデータを用いることにより、Ｗｅｂサービス４５の事前条件を満たす。さらに、Ｗｅｂサービスデータ４５の事後条件は、「ＳｔａｙｅｄＡｔ（田中，大阪）」と「ＬｏｃａｔｅｄＡｔ（田中，大阪）」である。よって、Ｗｅｂサービスデータ４２と４５を組み合わせることによって、ユーザ要求を満足することができる。
【００６３】
同様に、Ｗｅｂサービスデータ４４と４５を組み合せてもユーザ要求を満足することができる。
【００６４】
以上のように、複数のＷｅｂサービスを組み合せて連携をとることによってユーザ要求を満足することができるか否かの判断をすることによって、ウエブサーバ１は、ユーザ要求に対して、一つのＷｅｂサービスで賄えるＷｅｂサービスだけでなく、複数のＷｅｂサービスを組合せも含めたプランを、ユーザ要求を満たすものとして、回答することができる。
【００６５】
例えば、次のようなプランを提示する。
【００６６】
プランＰ＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝
すなわち、ここでは、１つのＷｅｂサービスＳ１と、２つの組合せからなるＷｅｂサービスＳ２とＳ５と、２つの組合せからなるＷｅｂサービスＳ４とＳ５との、３つの選択肢に関するＷｅｂサービスの情報がユーザに提示される。Ｓ２とＳ５の組合せでは、Ｓ２のサービスを受けた後に、Ｓ５のサービスを受けるとユーザの要求を満足するＷｅｂサービスを受けることができることを意味している。
【００６７】
要約すると、以上のように、ユーザから宿泊をする旅行をしたいので、それに関するＷｅｂサービスを知りたい旨の要求をウエブサーバ１が受信すると、ウエブサーバ１は、交通手段を提供するＷｅｂサービス４２又は４４と、宿泊手段を提供するＷｅｂサービス４５とを組み合せることによって、Ｗｅｂサービス４１と同様にユーザの要求を満足するＷｅｂサービスの情報も含むプランを、ＰＣ２へ提供する。従って、１つのＷｅｂサービスだけでユーザの要求を満たすＷｅｂサービスの情報に加えて、複数のＷｅｂサービスを組み合せてユーザの要求を満たすＷｅｂサービスの情報も、ユーザに提供されるので、従来に比べ、ユーザは、ユーザの要求を満足するより多くの情報を得ることができる。
【００６８】
言い換えると、従来であれば、ユーザ要求を満足する１つのＷｅｂサービスのみを探索してユーザに回答していたが、本実施の形態によれば、ユーザ要求を満足する複数の組合せのＷｅｂサービスも探索するので、ユーザには選択の幅が広がる。
【００６９】
次に、ウエブサーバ１において実行される処理の内容について、図６及び図７を用いて説明する。
【００７０】
図６は、プラン生成部１１の全体の処理の流れを示すフローチャートである。
【００７１】
まず、ＰＣ２からユーザ要求を受信すると、図２のユーザ要求解析部１５は、受信した要求データを解析し、論理式形式の要求データの生成処理を行う。具体的には、ＰＣ２から送信された要求データが述語を含む論理式形式の要求データでないときは、ユーザ要求解析部１５は、受信した要求データを解析し、その受信した要求データに基づいて、式１に示す論理式形式の要求データを生成して、その要求データを連携プラン生成部１６へ供給する。また、ユーザ要求解析部１５は、受信した要求データを解析した結果、受信した要求データが、既に述語を含む論理式形式の要求データであると判断したときは、ユーザ要求解析部１５は論理式形式の要求データの生成処理は行わないで、その要求データを連携プラン生成部１６へ供給する。
【００７２】
なお、受信した要求データの解析結果に基づいて、要求データの生成処理は、オントロジ辞書部１３のデータを用いて、指定されたレベルまでの用語を関連付けて論理式形式の要求データの生成を行う。
【００７３】
そして、図６に示すように、連携プラン生成部１６は、ユーザデータとユーザ要求とを用いて、ユーザ要求を満たすプランを生成するためにプラン生成手続き処理を実行する（ステップ（以下、Ｓと略す）１）。ここで用いられるユーザデータは、ユーザデータの述語の集合Ｉであり、ユーザ要求は、生成された述語の集合Ｇである。プラン生成手続きの内容は、図７で説明する。
【００７４】
ウエブサーバ１は、生成されたプランを、ユーザ要求を送信したＰＣ２へ返す、すなわち送信する（Ｓ２）。生成されるプランは、プランの集合Ｐである。
【００７５】
次に、連携プラン生成部１６が実行するプラン生成手続きの処理内容を図７を用いて説明する。図７は、図６のプラン生成手続き処理（Ｓ１）の詳細な流れを示すフローチャートである。
【００７６】
まず、Ｓ１１において、プランのデータをクリアする（Ｓ１１）。すなわちプランの集合Ｐには何も含まれていない状態となる。
【００７７】
次に、Ｓ１２の処理において、Ｗｅｂサービスデータの中からＷｅｂサービス記述ｓを選択する。ここでは、まず、図５の４１のＷｅｂサービス記述が選択される。
【００７８】
そして、Ｓ１３において、選択されたＷｅｂサービス記述ｓの事前条件の述語集合Ｑが、ユーザデータの述語の集合Ｉに含まれるか否かが判断される。すなわち、選択されたＷｅｂサービス記述ｓの事前条件の述語集合Ｑと、ユーザデータの述語の集合Ｉとのマッチングが取られる。Ｗｅｂサービスデータ４１の事前条件とユーザデータ２５を比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京という単一化をすると、Ｗｅｂサービスデータ４１の事前条件の述語は、「ＬｏｃａｔｅｄＡｔ（田中，東京）」となり、ユーザデータ２５に含まれる。従って、Ｓ１３でＹｅｓとなって、Ｓ１４の処理に移行する。なお、Ｓ１３でＮｏの場合は、後述するＳ１７の処理へ移行する。
【００７９】
Ｓ１４では、ユーザデータの集合Ｉを適用した事前条件の述語に基づいて生成される事後条件の述語の集合Ｒが求められる。例えば、ユーザデータの「ＬｏｃａｔｅｄＡｔ（田中，東京）」を、Ｗｅｂサービスデータ４１の事前条件の述語として、事後条件の述語の求めると、述語の集合｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＳｔａｙｅｄＡｔ（田中，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝が得られる。
【００８０】
この生成された事後条件の述語の集合Ｒが、ユーザ要求の述語の集合Ｇを含むか否かが判断される（Ｓ１５）。すなわち、生成された事後条件の述語の集合Ｒと、ユーザ要求の述語の集合Ｇとのマッチングが取られる。Ｗｅｂサービスデータ４１であれば、事後条件の述語集合Ｒは、｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＳｔａｙｅｄＡｔ（田中，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝であり、ユーザ要求の述語集合Ｇは、｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＳｔａｙｅｄＡｔ（田中，大阪）　｝であるので、事後条件の述語の集合Ｒは、ユーザ要求の述語の集合Ｇを含む。従って、Ｗｅｂサービスデータ４１の場合は、Ｓ１５でＹｅｓとなり、Ｓ１６の処理へ移行する。Ｓ１６では、ｓをプラン集合Ｐに加える。式で表すと、
Ｐ＝Ｐ∪｛ｓ｝
である。Ｗｅｂサービスデータ４１のサービスＩＤであるＳ１がプラン集合Ｐに加えられる。すなわち、Ｐ＝｛Ｓ１｝となる。
【００８１】
その後、Ｓ１７の処理へ移行し、全てのＷｅｂサービスの記述をチェックしたかが判断される。図５の例であれば、Ｗｅｂサービスデータ４１の他に４２から４７の６つのＷｅｂサービス記述が残っているので、Ｓ１７でＮｏとなって、Ｓ１２の処理へ戻る。
【００８２】
次に、Ｗｅｂサービスデータ４２について、上述した処理と同様の処理を行なう。Ｓ１２の処理において、Ｗｅｂサービスデータの中からＷｅｂサービス記述ｓを選択する。ここでは、図５の４２の記述が選択される。
【００８３】
そして、Ｓ１３において、選択されたＷｅｂサービス記述ｓの事前条件の述語集合Ｑが、ユーザデータの集合Ｉに含まれるか否かが判断される。Ｗｅｂサービスデータ４２の事前条件とユーザデータ２５を比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京という単一化をすると、Ｗｅｂサービスデータ４２の事前条件の述語は、「ＬｏｃａｔｅｄＡｔ（田中，東京）」となり、ユーザデータ２５に含まれる。従って、Ｓ１３でＹｅｓとなって、Ｓ１４の処理に移行する。
【００８４】
Ｓ１４では、ユーザデータの集合Ｉを適用した事前条件の述語に基づいて生成される事後条件の述語の集合Ｒが求られる。例えば、ユーザデータの「ＬｏｃａｔｅｄＡｔ（田中，東京）」を、Ｗｅｂサービスデータ４２の事前条件の述語として、事後条件の述語の求めると、述語の集合｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝が得られる。
【００８５】
この生成された事後条件の述語の集合Ｒが、ユーザ要求の述語の集合Ｇを含むか否かが判断される（Ｓ１５）。Ｗｅｂサービスデータ４２であれば、事後条件の述語集合Ｒは、｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝であり、ユーザ要求の述語集合Ｇは、｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＳｔａｙｅｄＡｔ（田中，大阪）　｝であるので、事後条件の述語の集合Ｒは、ユーザ要求の述語集合Ｇを含まない。従って、Ｗｅｂサービスデータ４２の場合は、Ｓ１５でＮｏとなり、Ｓ１８の処理へ移行する。
【００８６】
Ｓ１８では、まず、ユーザデータの集合Ｉの述語の中で、選択されたＷｅｂサービス記述ｓの事前条件とマッチングの取れていないもの、および記述ｓの事後条件の述語ｘを集合（Ｉ’）にセットする。式で表すと、
【００８７】
【式２】
2004062536.tif 000003
である。すなわち、Ｉ’＝｛Ｉの述語の中で、選択されたＷｅｂサービス記述ｓの事前条件の述語とマッチングが取れていないもの｝∪｛選択されたＷｅｂサービス記述ｓの事後条件の述語｝である。
【００８８】
Ｗｅｂサービスデータ４２の場合、ユーザデータの集合Ｉの述語の中で、選択されたＷｅｂサービス記述ｓの事前条件とマッチングの取れていないものはないので、事後条件の述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」と「ＬｏｃａｔｅｄＡｔ（田中，大阪）」が集合（Ｉ’）にセットされる。
【００８９】
次に、ユーザ要求の集合Ｇの述語の中で、選択されたＷｅｂサービス記述ｓの事後条件とマッチングが取れていないものを集合（Ｇ’）にセットする。式で表すと、
【００９０】
【式３】
2004062536.tif 000004
である。すなわち、Ｇ’＝｛Ｇの述語の中で、選択されたＷｅｂサービス記述ｓの事後条件の述語とマッチングが取れていないもの｝である。
【００９１】
Ｗｅｂサービスデータ４２の場合、述語「ＳｔａｙｅｄＡｔ（田中，大阪）」がマッチングが取れていないものなので、集合（Ｇ’）にセットされる。
【００９２】
さらに、プラン生成手続きを再帰的に呼び、その結果をプラン集合Ｐ’にセットする。式で表すと、
（式４）
Ｐ’＝プラン生成手続き（Ｉ’，Ｇ’）
である。Ｗｅｂサービスデータ４２の場合、集合（Ｉ’）は、｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝であり、集合（Ｇ’）は、｛ＳｔａｙｅｄＡｔ（田中，大阪）｝となる。従って、集合（Ｉ’）と集合（Ｇ’）に基づいて、図７の処理を再帰的に呼び、その結果のプラン集合（Ｐ’）が生成される。
【００９３】
Ｓ１８の処理の後、Ｓ１９の処理が実行される。Ｓ１９では、集合Ｐ’が空集合か否かが判断される。集合Ｐ’が空集合であれば、Ｓ１９でＹｅｓとなってＳ１７の処理へ移行する。集合Ｐ’が空集合でないとき、Ｓ１９でＮｏとなり、Ｓ２０の処理へ移行する。Ｓ２０では、再帰的に求めたプランの先頭にｓを追加し、プランの集合Ｐに加える。式で表すと、
【００９４】
【式５】
2004062536.tif 000005
である。Ｗｅｂサービスデータ４２の場合、Ｗｅｂサービスデータ４５がプランＰ’に含まれるので、集合Ｐは、Ｗｅｂサービスデータ４１のＳ１に、Ｗｅｂサービスデータ４２の「Ｓ２，Ｓ５」を加え、集合Ｐは、｛Ｓ１，Ｓ２；Ｓ５｝となる。すなわち、Ｓ２の後に続けてＷｅｂサービスＳ５を呼ぶことによって、ユーザ要求を満たすことができるプランが追加される。
【００９５】
Ｓ１７の処理に移行し、次のＷｅｂサービスデータ４３について、同様に、図７の処理が実行される。Ｗｅｂサービスデータ４３では、事前条件が、「ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｆｒｏｍ）∧ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（ｕｓｅｒ，ａｉｒｌｉｎｅ）」であり、ユーザデータ２６の利用可否では否となっているので、Ｓ１３でＮｏとなる。
【００９６】
次のＷｅｂサービスデータ４４について、同様に、図７の処理が実行される。Ｗｅｂサービスデータ４４についての詳細な処理の説明は省略するが、略Ｗｅｂサービスデータ４２と同様の処理結果となり、集合ＰにＷｅｂサービスデータ４４の「Ｓ４，Ｓ５」が加わるので、集合Ｐは、｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝となる。すなわち、Ｓ４の後に続けてＷｅｂサービスＳ５を呼ぶことによって、ユーザ要求を満たすことができるプランが追加される。
【００９７】
以下同様に、Ｗｅｂサービスデータ４７まで、図７の処理が実行される。従って、図６及び図７の処理の結果として、ユーザには集合Ｐの結果に基づいて、ユーザ要求を満たす３つのプランのデータが、ウエブサーバ１から、ＰＣ２へ送信される。すなわち、集合Ｐ（＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝）のデータが、ユーザ要求を送信したＰＣ２へ返され、ユーザに提示される。なお、ここでは、ＷｅｂサービスデータのＷｅｂサービス記述の識別子の系列データが、複数個返されているが、識別子以外のデータが返されてもよい。
【００９８】
以上のように、ユーザは、単に、ユーザ要求を満たす１つのＷｅｂサービスの情報が得られるだけでなく、複数のＷｅｂサービスを連携して利用することによってユーザ要求を満たす場合のＷｅｂサービスの情報も得られる。
【００９９】
従って、ユーザは、従来に比べて、要求にマッチしたＷｅｂサービス情報をより多く得られる。
【０１００】
ところで、上述した例では、図３のユーザデータの利用可否が「否」になっていたが、次に、そのユーザデータ２６の利用可否が「可」になっている場合について、説明する。
【０１０１】
ユーザデータ２６の利用可否が「可」になっているので、ユーザデータ集合Ｉは、｛ＬｏｃａｔｅｄＡｔ（田中，東京），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝である。
【０１０２】
ＷｅｂサービスＳ１、Ｓ２については上述した処理と同じであるので、説明は省略する。
【０１０３】
ＷｅｂサービスＳ３については、事前条件の述語集合｛ＬｏｃａｔｅｄＡｔ（田中，東京），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝は、ユーザデータ集合Ｉに含まれるので、Ｓ１３でＹｅｓとなる。そして、事後条件の述語の集合｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪）　，ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）　｝は、ユーザ要求の述語集合Ｇを含んでいないので、Ｓ１５でＮｏとなり、その結果、Ｓ１８へ移行する。
【０１０４】
Ｓ１８では、集合（Ｉ’）が生成される。すなわち、Ｉ’＝｛Ｉの述語の中で、Ｓ３の事前条件の述語とマッチングが取れていないもの｝∪｛Ｓ３の事後条件の述語｝＝｛｝∪｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪）　，ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）｝＝｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪）　，ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）｝となる。
【０１０５】
そして集合（Ｇ’）が生成される。すなわち、Ｇ’＝｛Ｇの述語の中で、Ｓ３の事後条件の述語とマッチングが取れていないもの｝＝｛ＳｔａｙｅｄＡｔ（田中，大阪）｝となる。
【０１０６】
そして、Ｉ’とＧ’に基づいて、プラン生成手続きを再帰的に呼び、実行して、「ＳｔａｙｅｄＡｔ（田中，大阪）」を満足するＷｅｂサービスを探索することになる。
【０１０７】
その結果、Ｓ６の事前条件の述語集合｛ＬｏｃａｔｅｄＡｔ（田中，東京），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝は、集合（Ｉ’）に含まれるので、Ｓ１３でＹｅｓとなり、さらに、事後条件の述語集合｛ＳｔａｙｅｄＡｔ（田中，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）｝は、集合（Ｇ’）を含むので、Ｓ１５でＹｅｓとなって、結果として、「Ｓ３；Ｓ６」がプランＰに追加される。すなわち、集合Ｐ（＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ３；Ｓ６，Ｓ４；Ｓ５｝）のデータが、ユーザ要求を送信したＰＣ２へ返される。
【０１０８】
また、上記と同じ場合について、すなわち、ある人が旅行をする場合に、その旅行について種々の情報を提供してくれるＷｅｂサービスを探す場合について、別の実施例を説明する。
【０１０９】
まず、ユーザであるＰＣ２からインターネット４を介してウエブサーバ１へ、旅行に関するＷｅｂサービスを探す要求データが送信される。このとき、ユーザであるＰＣ２は、予め決められたプログラムに基づいて、旅行をする者、出発地及び目的地等の要求データを生成し、ウエブサーバ１へ送信する。例えば、「田中」さんが、「東京」から「大阪」へ旅行し、「大阪」で宿泊する旅行するのだが、その旅行に関するＷｅｂサービスを探したい、旨の要求データがＰＣ２からウエブサーバ１へ送信される。
【０１１０】
次は、送信される要求データの例を示す。
【０１１１】
（式１）
Ｔｒａｖｅｌｅｄ（田中，東京，大阪）∧ＳｔａｙｅｄＡｔ（田中，大阪）
この要求データは、２つの述語の論理積の論理式形式のデータである。
【０１１２】
なお、この要求データは、ＰＣ２において生成されてもよいし、あるいはＰＣ２から送信されたデータに基づいて、ウエブサーバ１において生成されてもよい。
【０１１３】
この要求データを受信したウエブサーバ１は、受信した要求データに基づいて、ユーザデータとして「田中」さんが含まれていることを検出することができる。従って、ウエブサーバ１は、図３のユーザデータ部１２のデータを検索し、「田中」さんに関するユーザデータを抽出する。その結果、図３に示す２つのユーザデータが抽出されたとする。
【０１１４】
次に、事後条件の述語と要求データの述語のマッチングを行う。マッチングとは、２つの述語が一致しているか否かのチェックをいう。述語のマッチングは、述語の述語記号と引数を記号あるいは記号列とみなし、２つの記号、すなわち文字列が一致するか否かで判定を行うことをいう。すなわち、要求データ（式１）の述語記号の中に、Ｗｅｂサービスデータの事後条件の中の述語記号と一致するものがあるかを判断される。図５のＷｅｂサービスデータにおいては、「Ｔｒａｖｅｌｅｄ」と「ＳｔａｙｅｄＡｔ」の２つの述語記号を事後条件に含むものとしては、Ｗｅｂサービスデータ４１だけが該当する。
【０１１５】
そして、事後条件の「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）」と「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）」の変数ｕｓｅｒ，　ｆｒｏｍ，　ｔｏ　に値を入れて単一化（ユニフィケーション（ｕｎｉｆｉｃａｔｉｏｎ））することによって、述語データが生成される。ここで、単一化とは、述語の変数の値をある値に置き換えてマッチさせることをいう。なお、ここの例では、要求データの「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」、「ＳｔａｙｅｄＡｔ（田中，大阪）」と、事後条件の「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）」、「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｔｏ）」とを比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京、ｔｏ＝大阪という単一化が行われ、事後条件から「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」、「ＳｔａｙｅｄＡｔ（田中，大阪）」、「ＬｏｃａｔｅｄＡｔ（田中，大阪）」という３つの述語が生成される。
【０１１６】
次に、あるＷｅｂサービスの事後条件の単一化に成功すると、同じ単一化は、そのＷｅｂサービスの事前条件にも適用される。すなわち、事後条件と独立して、事前条件の単一化が行われるのではない。要求データとＷｅｂサービスデータ４１の事後条件で成功した単一化　ｕｓｅｒ＝田中、ｆｒｏｍ＝東京、ｔｏ＝大阪　を、事前条件「Ｌｏｃａｔｅｄ（ｕｓｅｒ，ｆｒｏｍ）」に適用すると、「ＬｏｃａｔｅｄＡｔ（田中，東京）」という述語が生成される。
【０１１７】
一方、事後条件の述語の単一化、あるいはマッチングに失敗すれば、そのＷｅｂサービスを受けることができず、さらに、事後条件の述語が生成できても、単一化により得られた事前条件の述語が、ユーザデータの述語によって満足されなければ、サービス検索者はそのＷｅｂサービスを利用することはできない。
【０１１８】
図５の例であれば４１から４７の７つのＷｅｂサービスにおいて、事後条件の述語の生成はできるが、Ｗｅｂサービスデータ４１以外は、ユーザデータを満足する事前条件の述語を生成することができない。よって、Ｗｅｂサービスデータ４１のみがユーザ要求を満足するプランの１つとすることができる。
【０１１９】
以上は、１つのＷｅｂサービスによってユーザの要求が満足されるかを判断している。本実施の形態では、さらに、複数のＷｅｂサービスを組み合わせることによって、すなわち、複数のＷｅｂサービスの連携をとることによってユーザの要求を満足するプランがあるか否かを判断する。
【０１２０】
例えば、Ｗｅｂサービスデータ４５の場合，事前条件に述語記号がＴｒａｖｅｌｅｄである述語が存在しないので、「Ｔｒａｖｅｌｅｄ」についてユーザ要求データの述語とマッチングをとることができないが，「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｌｏｃａｔｉｏｎ）」については単一化によって「ＳｔａｙｅｄＡｔ（田中，大阪）」という述語を生成することができる。この単一化によって、事前条件の「ＬｏｃａｔｅｄＡｔ（田中，大阪）」という述語を生成できる。
【０１２１】
次に、その述語を事後条件として、Ｗｅｂサービスデータの中で、「Ｔｒａｖｅｌｅｄ（ｕｓｅｒ，ｆｒｏｍ，ｔｏ）」について述語を生成することができるＷｅｂサービスデータがあるか否かを探す。すなわち、一つのＷｅｂサービスデータでは、ユーザの要求するＷｅｂサービスを提供できないが、組み合わせて連携をとることによってユーザの満足するＷｅｂサービスを提供できる、他のＷｅｂサービスデータを探す。
【０１２２】
具体的には、まず、生成された述語データと、他のＷｅｂサービスデータの事後条件の述語データとのマッチングを取る。言い換えれば、あるＷｅｂサービスデータにおいて、生成された事前条件である述語を事後条件としたときに、生成される事前条件が、ユーザデータの述語を生成するか否かをチェックする。
【０１２３】
例えば、Ｗｅｂサービス４５に対しては、事前条件の述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」が生成される。生成された述語を優先することによって、述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」を事後条件として、Ｗｅｂサービス４５以外のサービスについて、事前条件を生成する。そして、そのＷｅｂサービス４５以外のサービスについて生成された事前条件がユーザデータによって満たされるかを判断する。
【０１２４】
例えば、Ｗｅｂサービス４５とＷｅｂサービス４７を比べると、どちらの事後条件にも述語記号「ＳｔａｙｅｄＡｔ」が含まれており、単一化によって、Ｗｅｂサービスデータ４５の事後条件，および４７の事後条件は、要求データの述語「ＳｔａｙｅｄＡｔ（田中，大阪）」を満たす。Ｗｅｂサービス４７の事前条件は述語記号「ＨａｖｅＳｔａｙｅｄＡｔ」を含んでおり、ユーザデータでは事前条件を満たさず、他のどのＷｅｂサービスの事後条件も述語記号「ＨａｖｅＳｔａｙｅｄＡｔ」を含まない。一方、Ｗｅｂサービス４２の事後条件は、述語記号「Ｔｒａｖｅｌｅｄ」と「ＬｏｃａｔｅｄＡｔ」の２つあり、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京、ｔｏ＝大阪という単一化によって、述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪」と「ＬｏｃａｔｅｄＡｔ（田中，大阪）」という述語が生成される。述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」は要求データを満たし、述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」はＷｅｂサービス４５の事前条件の述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」を満たす。さらに、Ｗｅｂサービスデータ４２の事前条件は「ＬｏｃａｔｅｄＡｔ（田中，東京）」であるり、ユーザデータによって満たされる。よって、Ｗｅｂサービスデータ４２と４５を組み合わせることによって、ユーザデータを満足する。
【０１２５】
同様に、Ｗｅｂサービスデータ４４と４５を組み合せてもユーザ要求を満足することができる。
【０１２６】
以上のように、複数のＷｅｂサービスを組み合せて連携をとることによってユーザ要求を満足することができるか否かの判断をすることによって、ウエブサーバ１は、ユーザ要求に対して、一つのＷｅｂサービスで賄えるＷｅｂサービスだけでなく、複数のＷｅｂサービスを組合せも含めたプランを、ユーザ要求を満たすものとして、回答することができる。
【０１２７】
例えば、次のようなプランを提示する。
【０１２８】
プランＰ＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝
すなわち、ここでは、１つのＷｅｂサービスＳ１と、２つの組合せからなるＷｅｂサービスＳ２とＳ５と、２つの組合せからなるＷｅｂサービスＳ４とＳ５との、３つの選択肢に関するＷｅｂサービスの情報がユーザに提示される。Ｓ２とＳ５の組合せでは、Ｓ２のサービスを受けた後に、Ｓ５のサービスを受けるとユーザの要求を満足するＷｅｂサービスを受けることができることを意味している。
【０１２９】
要約すると、以上のように、ユーザから宿泊をする旅行をしたいので、それに関するＷｅｂサービスを知りたい旨の要求をウエブサーバ１が受信すると、ウエブサーバ１は、交通手段を提供するＷｅｂサービス４２又は４４と、宿泊手段を提供するＷｅｂサービス４５とを組み合せることによって、Ｗｅｂサービス４１と同様にユーザの要求を満足するＷｅｂサービスの情報も含むプランを、ＰＣ２へ提供する。従って、１つのＷｅｂサービスだけでユーザの要求を満たすＷｅｂサービスの情報に加えて、複数のＷｅｂサービスを組み合せてユーザの要求を満たすＷｅｂサービスの情報も、ユーザに提供されるので、従来に比べ、ユーザは、ユーザの要求を満足するより多くの情報を得ることができる。
【０１３０】
言い換えると、従来であれば、ユーザ要求を満足する１つのＷｅｂサービスのみを探索してユーザに回答していたが、本実施の形態によれば、ユーザ要求を満足する複数の組合せのＷｅｂサービスも探索するので、ユーザには選択の幅が広がる。
【０１３１】
次に，ウエブサーバ１において実行される処理の内容について、図８及び図９を用いて説明する。
【０１３２】
図８は、プラン生成部１１の全体の処理の流れを示すフローチャートである。
【０１３３】
まず、ＰＣ２からユーザ要求を受信すると、図２のユーザ要求解析部１５は、受信した要求データを解析し、論理式形式の要求データの生成処理を行う。具体的には、ＰＣ２から送信された要求データが述語を含む論理式形式の要求データでないときは、ユーザ要求解析部１５は、受信した要求データを解析し、その受信した要求データに基づいて、式１に示す論理式形式の要求データを生成して、その要求データを連携プラン生成部１６へ供給する。また、ユーザ要求解析部１５は、受信した要求データを解析した結果、受信した要求データが、既に述語を含む論理式形式の要求データであると判断したときは、ユーザ要求解析部１５は論理式形式の要求データの生成処理は行わないで、その要求データを連携プラン生成部１６へ供給する。
【０１３４】
なお、受信した要求データの解析結果に基づいて、要求データの生成処理は、オントロジ辞書部１３のデータを用いて、指定されたレベルまでの用語を関連付けて論理式形式の要求データの生成を行う。
【０１３５】
そして、図８に示すように、連携プラン生成部１６は、ユーザデータとユーザ要求とを用いて、ユーザ要求を満たすプランを生成するためにプラン生成手続き処理を実行する（ステップ（以下、Ｓと略す）３）。ここで用いられるユーザデータは、ユーザデータの述語の集合Ｉであり、ユーザ要求は、生成された述語の集合Ｇである。プラン生成手続きの内容は、図９で説明する。
【０１３６】
ウエブサーバ１は、生成されたプランを、ユーザ要求を送信したＰＣ２へ返す、すなわち送信する（Ｓ４）。生成されるプランは、プランの集合Ｐである。
【０１３７】
次に、連携プラン生成部１６が実行するプラン生成手続きの処理内容を図９を用いて説明する。図９は、図８のプラン生成手続き処理（Ｓ３）の詳細な流れを示すフローチャートである。
【０１３８】
まず、Ｓ３１において、プランのデータをクリアする（Ｓ３１）。すなわちプランの集合Ｐには何も含まれていない状態となる。
【０１３９】
次に、Ｓ３２の処理において、Ｗｅｂサービスデータの中からＷｅｂサービス記述ｓを選択する。ここでは、まず、図５の４１のＷｅｂサービス記述が選択される。
【０１４０】
そして、Ｓ３３において、選択されたＷｅｂサービス記述ｓの事後条件の述語集合Ｒと、ユーザ要求データの述語の集合Ｇとの間に共通の述語が含まれるか否かが判断される。すなわち、選択されたＷｅｂサービス記述ｓの事後条件の述語集合Ｒと、ユーザ要求ータの述語の集合Ｇとのマッチングが取られる。Ｗｅｂサービスデータ４１の事後条件とユーザ要求データの述語（式１）を比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京、ｔｏ＝大阪という単一化をすると、Ｗｅｂサービスデータ４１の事後条件は、「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）∧ＳｔａｙｅｄＡｔ（田中，大阪）∧ＬｏｃａｔｅｄＡｔ（田中，大阪）」となり、ユーザ要求データの式１を満たしている。従って、Ｓ３３でＹｅｓとなって、Ｓ３４の処理に移行する。なお、Ｓ３３でＮｏの場合は、後述するＳ３７の処理へ移行する。
【０１４１】
Ｓ３４では、ユーザ要求データの集合Ｇを適用した事後条件の述語に基づいて生成される事前条件の述語の集合Ｑが求められる。例えば、ユーザ要求データの「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」と「ＳｔａｙｅｄＡｔ（田中，大阪」を、Ｗｅｂサービスデータ４１の事後条件の述語として、事前条件の述語を求めると、述語の集合｛ＬｏｃａｔｅｄＡｔ（田中，東京）　｝が得られる。
【０１４２】
この生成された事前条件の述語の集合Ｑが、ユーザデータの述語の集合Ｉを含むか否かが判断される（Ｓ３５）。すなわち、生成された事前条件の述語の集合Ｑと、ユーザデータの述語の集合Ｉとのマッチングが取られる。Ｗｅｂサービスデータ４１であれば、事前条件の述語集合Ｑは、｛　ＬｏｃａｔｅｄＡｔ（田中，東京）　｝であり、ユーザデータの述語集合Ｉは、｛　ＬｏｃａｔｅｄＡｔ（田中，東京）　｝であるので、事前条件の述語の集合Ｑは、ユーザデータの述語の集合Ｉに含まれる。従って、Ｗｅｂサービスデータ４１の場合は、Ｓ３５でＹｅｓとなり、Ｓ３６の処理へ移行する。Ｓ３６では、ｓをプラン集合Ｐに加える。式で表すと、
Ｐ＝Ｐ∪｛ｓ｝
である。Ｗｅｂサービスデータ４１のサービスＩＤであるＳ１がプラン集合Ｐに加えられる。すなわち、Ｐ＝｛Ｓ１｝となる。
【０１４３】
その後、Ｓ３７の処理へ移行し、全てのＷｅｂサービスの記述をチェックしたかが判断される。図５の例であれば、Ｗｅｂサービスデータ４１の他に４２から４７の６つのＷｅｂサービス記述が残っているので、Ｓ３７でＮｏとなって、Ｓ３２の処理へ戻る。
【０１４４】
次に、Ｗｅｂサービスデータ４２について、上述した処理４１と同様の処理を行なう。Ｓ３２の処理において、Ｗｅｂサービスデータの中からＷｅｂサービス記述ｓを選択する。ここでは、図５の４２の記述が選択される。
【０１４５】
そして、Ｓ３３において、選択されたＷｅｂサービス記述ｓの事後条件の述語集合Ｒとユーザ要求データの集合Ｇが共通の述語を含むか否かが判断される。Ｗｅｂサービスデータ４２の事後条件の述語とユーザ要求データの式１の述語を比較し、ｕｓｅｒ＝田中、ｆｒｏｍ＝東京、ｔｏ＝大阪という単一化をすると、述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」が共通に含まれるため、Ｓ３３でＹｅｓとなって、Ｓ３４の処理に移行する。
【０１４６】
Ｓ３４では、ユーザ要求データの集合Ｇを適用した事後条件の述語に基づいて生成される事前条件の述語の集合Ｑが求られる。上述のＷｅｂサービスデータ４２の事前条件の述語を求めると、述語の集合｛　ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝が得られる。
【０１４７】
この生成された事前条件の述語の集合Ｑが、ユーザデータの述語の集合Ｉに含まれるか否かが判断される（Ｓ３５）。Ｗｅｂサービスデータ４５であれば、事前条件の述語集合Ｑは、｛　ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝であり、ユーザデータの述語集合Ｉは、｛　ＬｏｃａｔｅｄＡｔ（田中，東京）　｝であるので、事前条件の述語の集合Ｑは、ユーザデータの述語集合Ｉを含まない。従って、Ｗｅｂサービスデータ４５の場合は、Ｓ３５でＮｏとなり、Ｓ３８の処理へ移行する。
【０１４８】
Ｗｅｂサービスデータ４３、４４についてもＷｅｂサービスデータ４２と同様に、事前条件の述語集合はユーザデータの述語集合Ｉに含まれない。
【０１４９】
次に、Ｗｅｂサービスデータ４５について、上述した処理４１と同様の処理を行なう。Ｓ３２の処理において、Ｗｅｂサービスデータの中からＷｅｂサービス記述ｓを選択する。ここでは、図５の４５の記述が選択される。
【０１５０】
そして、Ｓ３３において、選択されたＷｅｂサービス記述ｓの事後条件の述語集合Ｒとユーザ要求データの集合Ｇが共通の述語を含むか否かが判断される。Ｗｅｂサービスデータ４５の事後条件とユーザ要求データの式１を比較し、ｕｓｅｒ＝田中、ｌｏｃａｔｉｏｎ＝大阪という単一化をすると、Ｗｅｂサービスデータ４５の事後条件の述語は、「ＳｔａｙｅｄＡｔ（田中，大阪）　∧　ＬｏｃａｔｅｄＡｔ（田中，大阪）」となり、ユーザ要求データの式１の「ＳｔａｙｅｄＡｔ（田中，大阪）」を満たす。従って、Ｓ３３でＹｅｓとなって、Ｓ３４の処理に移行する。
【０１５１】
Ｓ３４では、ユーザ要求データの集合Ｇを適用した事後条件の述語に基づいて生成される事前条件の述語の集合Ｑが求られる。例えば、ユーザ要求データの「Ｔｒａｖｅｌｅｄ（田中，大阪）」と「ＳｔａｙｅｄＡｔ（田中，大阪）」を、Ｗｅｂサービスデータ４５の事後条件の述語として、事前条件の述語を求めると、述語の集合｛　ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝が得られる。
【０１５２】
この生成された事前条件の述語の集合Ｑが、ユーザデータの述語の集合Ｉに含まれるか否かが判断される（Ｓ３５）。Ｗｅｂサービスデータ４５であれば、事前条件の述語集合Ｑは、｛　ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝であり、ユーザデータの述語集合Ｉは、｛　ＬｏｃａｔｅｄＡｔ（田中，東京）　｝であるので、事前条件の述語の集合Ｑは、ユーザデータの述語集合Ｉに含まれない。従って、Ｗｅｂサービスデータ４５の場合は、Ｓ３５でＮｏとなり、Ｓ３８の処理へ移行する。
【０１５３】
Ｓ３８では、まず、ユーザ要求データの集合Ｇの述語の中で、選択されたＷｅｂサービス記述ｓの事後条件とマッチングの取れていないもの、および記述ｓの事前条件の述語ｘを集合（Ｇ’）にセットする。式で表すと、
【０１５４】
【式６】
2004062536.tif 000006
である。すなわち、Ｇ’＝｛Ｇの述語の中で、選択されたＷｅｂサービス記述ｓの事後条件の述語とマッチングが取れていないもの｝∪｛選択されたＷｅｂサービス記述ｓの事前条件の述語｝である。
【０１５５】
Ｗｅｂサービスデータ４５の場合、ユーザ要求データの集合Ｇの述語の中で、選択されたＷｅｂサービス記述ｓの事後条件とマッチングの取れていない述語「Ｔｒａｖｅｌｅｄ（田中，東京，大阪）」と、事前条件の述語「ＬｏｃａｔｅｄＡｔ（田中，大阪）」が集合（Ｇ’）にセットされる。
【０１５６】
次に、プラン生成手続きを再帰的に呼び、その結果をプラン集合Ｐ’にセットする。式で表すと、
（式７）
Ｐ’＝プラン生成手続き（Ｉ，Ｇ’）
である。Ｗｅｂサービスデータ４５の場合、集合（Ｇ’）は、｛　Ｔｒａｖｅｌｅｄ（田中，東京，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪）　｝となる。従って、集合（Ｉ）と集合（Ｇ’）に基づいて、図９の処理を再帰的に呼び、その結果のプラン集合（Ｐ’）が生成される。
【０１５７】
Ｓ３８の処理の後、Ｓ３９の処理が実行される。Ｓ３９では、集合Ｐ’が空集合か否かが判断される。集合Ｐ’が空集合であれば、Ｓ３９でＹｅｓとなってＳ３７の処理へ移行する。集合Ｐ’が空集合でないとき、Ｓ３９でＮｏとなり、Ｓ４０の処理へ移行する。Ｓ４０では、再帰的に求めたプランの末尾にｓを追加し、プランの集合Ｐに加える。式で表すと、
【０１５８】
【式８】
2004062536.tif 000007
である。Ｗｅｂサービスデータ４５の場合、Ｗｅｂサービスデータ４２と４４がプランＰ’に含まれるので、集合Ｐは、Ｗｅｂサービスデータ４１のＳ１に、Ｗｅｂサービスデータ４５の「Ｓ２；Ｓ５」と「Ｓ４；Ｓ５」を加え、集合Ｐは、｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝となる。すなわち、Ｓ２の後に続けてＷｅｂサービスＳ４、あるいはＳ５を呼ぶことによってユーザ要求を満たすことができる、２つのプランが追加される。
【０１５９】
Ｓ３７の処理に移行し、次のＷｅｂサービスデータ４６について、同様に、図９の処理が実行される。Ｗｅｂサービスデータ４６では、事後条件が、「ＳｔａｙｅｄＡｔ（ｕｓｅｒ，ｌｏｃａｔｉｏｎ）∧ＬｏｃａｔｅｄＡｔ（ｕｓｅｒ，ｌｏｃａｔｉｏｎ）∧ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（ｕｓｅｒ，ａｉｒｌｉｎｅ）∧ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（ｕｓｅｒ，ａｉｒｌｉｎｅ）」であり、ユーザデータ２６の利用可否では否となっているので、Ｓ３３でＮｏとなる。
【０１６０】
以下同様に、Ｗｅｂサービスデータ４７まで、図９の処理が実行される。従って、図８及び図９の処理の結果として、ユーザには集合Ｐの結果に基づいて、ユーザ要求を満たす３つのプランのデータが、ウエブサーバ１から、ＰＣ２へ送信される。すなわち、集合Ｐ（＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ４；Ｓ５｝）のデータが、ユーザ要求を送信したＰＣ２へ返され、ユーザに提示される。なお、ここでは、ＷｅｂサービスデータのＷｅｂサービス記述の識別子の系列データが、複数個返されているが、識別子以外のデータが返されてもよい。
【０１６１】
以上のように、ユーザは、単に、ユーザ要求を満たす１つのＷｅｂサービスの情報が得られるだけでなく、複数のＷｅｂサービスを連携して利用することによってユーザ要求を満たす場合のＷｅｂサービスの情報も得られる。
【０１６２】
従って、ユーザは、従来に比べて、要求にマッチしたＷｅｂサービス情報をより多く得られる。
【０１６３】
ところで、上述した例では、図３のユーザデータの利用可否が「否」になっていたが、次に、そのユーザデータ２６の利用可否が「可」になっている場合について、説明する。
【０１６４】
ユーザデータ２６の利用可否が「可」になっているので、ユーザデータ集合Ｉは、｛ＬｏｃａｔｅｄＡｔ（田中，東京），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝である。
【０１６５】
ＷｅｂサービスＳ１からＳ５については上述した処理と同じであるので、説明は省略する。
【０１６６】
ＷｅｂサービスＳ６については、事後条件の述語集合｛　ＳｔａｙｅｄＡｔ（田中，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）　｝は、ユーザ要求データの述語集合Ｇと共通の述語集合を持っているので、Ｓ３３でＹｅｓとなる。そして、事前条件の述語の集合｛　ＬｏｃａｔｅｄＡｔ（田中，大阪），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝は、ユーザデータの述語集合Ｉに含まれないので、Ｓ３５でＮｏとなり、その結果、Ｓ３８へ移行する。
【０１６７】
Ｓ３８では、集合（Ｇ’）が生成される。すなわち、Ｇ’＝｛Ｇの述語の中で、Ｓ６の事後条件の述語とマッチングが取れていないもの｝∪｛Ｓ６の事前条件の述語｝＝｛　Ｔｒａｖｅｌｅｄ（田中，東京，大阪）　｝∪｛　ＬｏｃａｔｅｄＡｔ（田中，大阪），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝＝｛Ｔｒａｖｅｌｅｄ（田中，東京，大阪），　ＬｏｃａｔｅｄＡｔ（田中，大阪）　，ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝となる。
【０１６８】
そして、ＩとＧ’に基づいて、プラン生成手続きを再帰的に呼び、実行して、「Ｔｒａｖｅｌｅｄ　（田中，東京，大阪）」を満足するＷｅｂサービスを探索することになる。
【０１６９】
その結果、Ｓ３の事後条件の述語集合｛　Ｔｒａｖｅｌｅｄ（田中，東京，大阪），ＬｏｃａｔｅｄＡｔ（田中，大阪），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社），ＧｏｔＭｉｌｅａｇｅＰｏｉｎｔｓ（田中，Ａ社）　｝は、集合（Ｇ’）と共通の述語を持つので、Ｓ３３でＹｅｓとなり、さらに、事前条件の述語集合｛　ＬｏｃａｔｅｄＡｔ（田中，東京），ＨａｖｅＭｉｌｅａｇｅＡｃｃｏｕｎｔ　（田中，Ａ社）　｝は、集合（Ｉ）に含まれるので、Ｓ３５でＹｅｓとなって、結果として、「Ｓ３；Ｓ６」がプランＰに追加される。すなわち、集合Ｐ（＝｛Ｓ１，Ｓ２；Ｓ５，Ｓ３；Ｓ６，Ｓ４；Ｓ５｝）のデータが、ユーザ要求を送信したＰＣ２へ返される。
【０１７０】
以上のように、本実施の形態によれば、ユーザは、従来に比べて、要求にマッチしたＷｅｂサービス情報をより多く得られる。
【０１７１】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態が説明されている。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０１７２】
なお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のアプリケーションプログラムプラン生成システムを実現することができる。
【０１７３】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【０１７４】
【発明の効果】
以上説明したように、本発明によれば、ユーザ要求にマッチしたＷｅｂサービス情報をより多く得られるアプリケーションプログラムプラン生成システムを実現することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるアプリケーションプログラムプラン生成システムの構成を示す構成図である。
【図２】図１のウエブサーバの構成を示す構成図である。
【図３】ユーザデータ部のデータ構成を説明するための図である。
【図４】オントロジ辞書部のデータ構成を説明するための図である。
【図５】Ｗｅｂサービスデータ部のデータ構成を説明するための図である。
【図６】連携プラン生成部の全体の処理の流れを示すフローチャートである。
【図７】図６のプラン生成手続き処理の詳細な流れを示すフローチャートである。
【図８】連携プラン生成部の全体の処理の流れの他の例を示すフローチャートである。
【図９】図８のプラン生成手続き処理の詳細な流れを示すフローチャートである。
【符号の説明】
１・・・ウエブサーバ
２・・・ＰＣ
３・・・インターネット
４・・・サービス提供コンピュータ
１１・・・プラン生成部
１２・・・ユーザデータ部
１３・・・オントロジ辞書部
１４・・・Ｗｅｂサービスデータ
【図１】
2004062536.tif 000008
【図２】
2004062536.tif 000009
【図３】
2004062536.tif 000010
【図４】
2004062536.tif 000011
【図５】
2004062536.tif 000012
【図６】
2004062536.tif 000013
【図７】
2004062536.tif 000014
【図８】
2004062536.tif 000015
【図９】
2004062536.tif 000016