(57)【要約】【課題】  サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携装置を提供することを目的とする。【解決手段】  サービス連携装置４は、複数のサービス提供装置２によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件に基づいて、サービス提供装置２によるサービスの呼出順序を決定する呼出順序決定部４４と、サービスの呼出順序に応じてサービスを呼び出すサービス呼出部４８と、許容時間からサービス提供装置２の呼出に応じた経過時間の期待範囲を決定する経過時間期待範囲決定部４６と、サービス呼出部４８が呼び出したサービスの経過時間を計測する経過時間計測部５０と、サービスの経過時間が経過時間の期待範囲を外れる場合には、サービス呼出の途中結果に応じてサービスの呼出順序を再決定する呼出順序再決定部５２とを備える。【選択図】          図１
2006277098.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービス提供装置によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件に基づいて、前記サービス提供装置によるサービスの呼出順序を決定する決定手段と、
前記サービスの呼出順序に応じてサービスを呼び出す呼出手段と
を備えることを特徴とするサービス連携装置。
【請求項２】
前記許容時間を基に、前記サービス連携装置の処理状況に応じて、前記呼出順序を動的に再決定する再決定手段をさらに備えることを特徴とする請求項１に記載のサービス連携装置。
【請求項３】
前記許容時間から前記サービス提供装置の呼出に応じた経過時間の期待範囲を決定する期待範囲決定手段と、
前記呼出手段が呼び出したサービスの経過時間を計測する計測手段と、
前記サービスの経過時間が前記経過時間の期待範囲を外れる場合には、前記サービス呼出の途中結果に応じて前記決定手段が決定したサービスの呼出順序を再決定する再決定手段とをさらに備えることを特徴とする請求項１に記載のサービス連携装置。
【請求項４】
サービス連携の提供先の候補となる複数のサービス提供装置のサービス呼出用アドレス情報を含むサービス提供情報を記憶する記憶手段をさらに備え、
前記決定手段は、前記サービス提供情報を参照して前記サービスの呼出順序を決定することを特徴とする請求項１に記載のサービス連携装置。
【請求項５】
前記記憶手段は、前記複数のサービス提供装置の呼出順序を、入れ替え可能な複数のサービスを一つの集合として記憶することを特徴とする請求項４に記載のサービス連携装置。
【請求項６】
前記サービスの経過時間が前記経過時間の期待範囲を外れた場合には、前記再決定手段による呼出順序と、前記呼出手段によるサービス提供装置の呼出が前記再決定に応じて変化することを特徴とする請求項３に記載のサービス連携装置。
【請求項７】
前記再決定手段は、前記サービスの経過時間が前記経過時間の期待範囲を上回る場合には、並行して実行されるサービス数を増やし、それらのサービスのうちで最も処理が早く終わったサービスから得られた結果に基づいて以後の処理を継続し、並行する他のサービスについてはサービスの処理をキャンセルすることを特徴とする請求項２又は請求項３に記載のサービス連携装置。
【請求項８】
前記再決定手段は、前記サービスの経過時間が前記経過時間の期待範囲を下回る場合には、並行して実行されるサービス数を増やし、それらのサービスの結果を待って以後の処理を継続することを特徴とする請求項２又は請求項３に記載のサービス連携装置。
【請求項９】
前記サービスの処理結果をサービス依頼側へ通知する通知手段をさらに備えることを特徴とする請求項１に記載のサービス連携装置。
【請求項１０】
前記通知手段は、前記許容時間内に一連の処理が終了しなかった場合に、前記許容時間を延長するかどうかをサービス依頼側へ問い合わせることを特徴とする請求項９に記載のサービス連携装置。
【請求項１１】
前記サービス依頼条件を受け付ける依頼側要求受付手段をさらに備えることを特徴とする請求項１に記載のサービス連携装置。
【請求項１２】
前記依頼側要求受付手段は、前記許容時間内に一連の処理が終了しなかった場合に、前記許容時間を延長するかどうかをサービス依頼側へ問い合わせた結果を受け付けることを特徴とする請求項１１に記載のサービス連携装置。
【請求項１３】
個々のサービスの利用に関する合意を、個々のサービスと対応付けて記憶するサービス利用合意記憶手段と、
個々のサービスを利用した履歴を記憶するサービス利用履歴記憶手段とをさらに備え、
前記決定手段および前記再決定手段の少なくとも一方は、前記個々のサービスの利用に関する合意と前記個々のサービスを利用した履歴に基づいて、前記サービスの呼出順序を決定することを特徴とする請求項２又は請求項３に記載のサービス連携装置。
【請求項１４】
前記決定手段および前記再決定手段の少なくとも一方は、前記サービス利用合意記憶手段に記憶された合意と前記サービス利用履歴記憶手段に記憶された履歴に基づいて重み付けを行って、呼び出すサービスを決定することを特徴とする請求項１３に記載のサービス連携装置。
【請求項１５】
サービスの利用コストの上限値をサービス依頼側と対応付けて記憶するコスト上限設定記憶手段と、
個々のサービス呼出にかかった利用コストを検出する検出手段と、
前記検出手段で検出された利用コストをサービス依頼側ごとに集計する集計手段と、
前記集計手段で集計されたコスト使用量をサービス依頼側と対応付けて記憶するコスト使用量記憶手段とをさらに備え、
前記再決定手段は、前記サービスの利用コストの上限値と前記コスト使用量に応じて、前記サービスの呼出順序を決定することを特徴とする請求項２又は請求項３に記載のサービス連携装置。
【請求項１６】
サービス提供側からサービスの呼出先とサービスを呼び出すためのデータ構造とを受け付ける提供側登録受付手段と、
前記提供側登録受付手段で受け付けたサービスを記憶する提供側登録記憶手段とをさらに備えることを特徴とする請求項１に記載の記載のサービス連携装置。
【請求項１７】
複数のサービス提供装置によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件に基づいて、前記サービス提供装置によるサービスの呼出順序を決定する決定ステップと、
前記サービスの呼出順序に応じてサービスを呼び出すステップと
を有することを特徴とするサービス連携方法。
【請求項１８】
前記許容時間を基に、前記サービス連携装置の処理状況に応じて、前記呼出順序を動的に再決定するステップをさらに有することを特徴とする請求項１７に記載のサービス連携方法。
【請求項１９】
前記許容時間から前記サービス提供装置の呼出に応じた経過時間の期待範囲を決定するステップと、
前記呼び出したサービスの経過時間を計測するステップと、
前記サービスの経過時間が前記経過時間の期待範囲を外れる場合には、前記サービス呼出の途中結果に応じて前記決定したサービスの呼出順序を再決定するステップとをさらに有することを特徴とする請求項１７に記載のサービス連携方法。
【請求項２０】
前記サービスの経過時間が前記経過時間の期待範囲を上回る場合には、並行して実行されるサービス数を増やし、それらのサービスのうちで最も処理が早く終わったサービスから得られた結果に基づいて以後の処理を継続し、並行する他のサービスについてはサービスの処理をキャンセルするステップをさらに有することを特徴とする請求項１９に記載のサービス連携方法。
【請求項２１】
前記サービスの経過時間が前記経過時間の期待範囲を下回る場合には、並行して実行されるサービス数を増やし、それらのサービスの結果を待って以後の処理を継続するステップをさらに有することを特徴とする請求項１９に記載のサービス連携方法。
【請求項２２】
前記許容時間内に一連の処理が終了しなかった場合に、前記許容時間を延長するかどうかをサービス依頼側へ問い合わせるステップをさらに有することを特徴とする請求項１７に記載のサービス連携方法。
【請求項２３】
個々のサービスの利用に関する合意を、個々のサービスと対応付けて記憶するステップと、
個々のサービスを利用した履歴を記憶するステップとをさらに有し、
前記個々のサービスの利用に関する合意と個々のサービスを利用した履歴に基づいて、前記サービスの呼出順序を決定することを特徴とする請求項１７に記載のサービス連携方法。
【請求項２４】
個々のサービス呼出にかかった利用コストを集計するステップをさらに有し、
サービスの利用コストの上限値と前記利用コストに応じて、前記サービスの呼出順序を決定することを特徴とする請求項１７に記載のサービス連携方法。
【請求項２５】
サービス提供側からサービスの呼出先とサービスを呼び出すためのデータ構造とを受け付けるステップをさらに有することを特徴とする請求項１７に記載の記載のサービス連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に存在する複数のサービスを適宜連携して利用するサービス連携装置およびサービス連携方法に関する。
【背景技術】
【０００２】
ネットワーク上に存在する複数のサービスを適宜連携して利用するための従来技術として、個々のサービスを呼び出す順序を規定した情報（「ワークフローリスト」や「シナリオ」などと称される）を用意し、この情報を利用して複数のサービスを連携し、一連の処理を実現するものがあり、例えば、以下の公報に示されている。この従来技術には、例えば特許文献１に示されるように、サービスを呼び出す際のパラメータに応じて、一連の処理の開始前に、サービスを呼び出す順序を組み替えるものがある。
【０００３】
特許文献１に開示される例では、旅行予約のサービス連携が通常は「列車空席検索」→「列車予約」→「ホテル空室検索」→「ホテル予約」の順で行われるが、○市の旅行予約については「○市はホテル件数が少ないため、ホテルの検索、予約を優先する」という規則が適用されて、「ホテル空室検索」→「ホテル予約」→「列車空席検索」→「列車予約」の順序となる。さらに別の規則が同時に適用されて、ホテル空室検索で空室が見つからなかった場合には一連の処理がそれ以降実行されずに終了することが記載されている。
【０００４】
また、特許文献１に示されるように、同じ役割を果たすサービスが複数存在する場合は、これらを同時に利用し、そのいずれかの結果を利用するものがある。例えば、ホテル予約サービスが複数ある場合には、これらを同時に利用する。また、特許文献２に示されるように、サービス依頼側が必要としないサービスは利用しないように指定できるものがある。例えば、飛行機の利用の有無をサービス依頼側へ回答させ、サービス依頼側が飛行機を利用しない場合は飛行機予約サービスを呼び出さない。
【特許文献１】特開平１０−２５４９５８号公報
【特許文献２】特開２００３−３０３２３３号公報
【特許文献３】特開２００４−１１０６２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
サービス依頼側には、一連の処理にかかる時間に対して要求を持っていることが一般的である。
【０００６】
しかしながら従来技術では、サービス依頼側にサービスの呼び出し方に関して選択肢を与えること可能であるが、サービス依頼側の時間的要求と選択肢との関係を提示することはできない。サービス依頼側にとっては、処理全体に対する時間的要求は持っていても、どの選択肢を選べばその要求を満たすかを決めることは困難である。なぜならネットワーク上の複数のサービスが連携する処理の時間は、サービス提供側のネットワーク構成やそのサービス提供側からさらに別のサービスに処理を委譲する可能性といったサービス依頼側が知りうることが困難な状況や、輻輳の発生や突発的なサービスダウンなど予期が難しい要因などに影響を受けるためである。
【０００７】
また従来技術の多くの場合、一連の処理が起動された後では、利用するサービスやそれらの呼び出し順序が処理の途中経過に合わせて変更されることはない。これは、上述したネットワークサービスの特徴から生じる問題に対応できるものではない。
【０００８】
特許文献３に示される技術ではサービス連携側がサービス提供側のバックエンドシステムの情報を取得する構成が示されているが、個々のサービス提供側はサービス連携側と異なる企業体で運営される場合、セキュリティポリシーの観点から、サービス提供側のバックエンドシステムとサービス連携側の装置とを結ぶことを拒絶することがある。このような場合、特許文献３に示されるような構成を取ることはできない。また、個々のサービス提供側はサービス連携側と異なる企業体で運営されることが一般的であり、サービス利用には利用条件に関する合意とその遵守が必要である。
【０００９】
しかしながら従来技術では、どのようにして個々のサービス利用の合意を守りながら連携を行うのかについて考慮されていない。また、個々のサービス提供側はサービス連携側と異なる企業体で運営され、その利用にコスト（料金やポイントなど）がかかることが一般的である。サービス連携側が依頼側要求を満たすべく過度にサービス提供側を利用し、そのコストをサービス利用側に移転できない場合にはサービス連携側が経済的に立ちゆかなくなる可能性がある。しかしながら従来技術では、このようなサービス連携に関わるコストについて考慮されていない。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたもので、サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携装置およびサービス連携方法を提供することを目的とする。また本発明の別の目的は、サービス依頼側の時間に関する要求を反映させながら、サービス利用の合意を守るようなサービス連携装置およびサービス連携方法を提供することにある。また本発明の別の目的は、サービス依頼側の時間に関する要求を反映させながら、サービス連携に関わるコストを考慮したサービス連携装置およびサービス連携方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明は、複数のサービス提供装置によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件に基づいて、前記サービス提供装置によるサービスの呼出順序を決定する決定手段と、前記サービスの呼出順序に応じてサービスを呼び出す呼出手段とを備えるサービス連携装置である。これにより、サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携装置を提供できる。本発明のサービス連携装置は、前記許容時間を基に、前記サービス連携装置の処理状況に応じて、前記呼出順序を動的に再決定する再決定手段をさらに備える。
【００１２】
本発明のサービス連携装置は、前記許容時間から前記サービス提供装置の呼出に応じた経過時間の期待範囲を決定する期待範囲決定手段と、前記呼出手段が呼び出したサービスの経過時間を計測する計測手段と、前記サービスの経過時間が前記経過時間の期待範囲を外れる場合には、前記サービス呼出の途中結果に応じて前記決定手段が決定したサービスの呼出順序を再決定する再決定手段とをさらに備えることを特徴とする。これにより動的にサービスの呼出順序を変更することができる。
【００１３】
本発明のサービス連携装置は、サービス連携の提供先の候補となる複数のサービス提供装置のサービス呼出用アドレス情報を含むサービス提供情報を記憶する記憶手段をさらに備え、前記決定手段は、前記サービス提供情報を参照して前記サービスの呼出順序を決定することを特徴とする。前記記憶手段は、前記複数のサービス提供装置の呼出順序を、入れ替え可能な複数のサービスを一つの集合として記憶することを特徴とする。
【００１４】
本発明のサービス連携装置は、前記サービス依頼条件を記憶する依頼側要求記憶手段と、前記決定手段で決定されたサービスの呼出順序を記憶する呼出順序記憶手段と、前記期待範囲決定手段で決定された経過時間の期待範囲を前記サービス依頼条件と対応づけて記憶する経過時間期待範囲記憶手段と、前記サービス提供装置の呼出の途中結果を前記サービス依頼条件と対応づけて記憶する途中結果記憶手段と、前記経過時間計測手段により計測されたサービスの経過時間を、前記サービス依頼条件ごとに記憶する経過時間記憶手段とをさらに備える。
【００１５】
前記サービスの経過時間が前記経過時間の期待範囲を外れた場合には、前記再決定手段による呼出順序と、前記呼出手段によるサービス提供装置の呼出が前記再決定に応じて変化することを特徴とする。前記再決定手段は、前記サービスの経過時間が前記経過時間の期待範囲を上回る場合には、並行して実行されるサービス数を増やし、それらのサービスのうちで最も処理が早く終わったサービスから得られた結果に基づいて以後の処理を継続し、並行する他のサービスについてはサービスの処理をキャンセルすることを特徴とする。
【００１６】
前記再決定手段は、前記サービスの経過時間が前記経過時間の期待範囲を下回る場合には、並行して実行されるサービス数を増やし、それらのサービスの結果を待って以後の処理を継続することを特徴とする。本発明のサービス連携装置は、前記サービスの処理結果をサービス依頼側へ通知する通知手段をさらに備える。前記通知手段は、前記許容時間内に一連の処理が終了しなかった場合に、前記許容時間を延長するかどうかをサービス依頼側へ問い合わせることを特徴とする。本発明のサービス連携装置は、前記サービス依頼条件を受け付ける依頼側要求受付手段をさらに備えることを特徴とする。前記依頼側要求受付手段は、前記許容時間内に一連の処理が終了しなかった場合に、前記通知手段が前記許容時間を延長するかどうかをサービス依頼側へ問い合わせた結果を受け付けることを特徴とする。
【００１７】
本発明のサービス連携装置は、個々のサービスの利用に関する合意を、個々のサービスと対応付けて記憶するサービス利用合意記憶手段と、個々のサービスを利用した履歴を記憶するサービス利用履歴記憶手段とをさらに備え、前記決定手段および前記再決定手段の少なくとも一方は、前記個々のサービスの利用に関する合意と前記個々のサービスを利用した履歴に基づいて、前記サービスの呼出順序を決定することを特徴とする。本発明によれば、サービス依頼側の時間に関する要求を反映させながら、サービス利用の合意を守るようなサービス連携を提供できる。前記決定手段および前記再決定手段の少なくとも一方は、前記サービス利用合意記憶手段に記憶された合意と前記サービス利用履歴記憶手段に記憶された履歴に基づいて重み付けを行って、呼び出すサービスを決定することを特徴とする。
【００１８】
本発明のサービス連携装置は、サービスの利用コストの上限値をサービス依頼側と対応付けて記憶するコスト上限設定記憶手段と、個々のサービス呼出にかかった利用コストを検出する検出手段と、前記検出手段で検出された利用コストをサービス依頼側ごとに集計する集計手段と、前記集計手段で集計されたコスト使用量をサービス依頼側と対応付けて記憶するコスト使用量記憶手段とをさらに備え、前記再決定手段は、前記サービスの利用コストの上限値と前記コスト使用量に応じて、前記サービスの呼出順序を決定することを特徴とする。本発明によれば、サービス依頼側の時間に関する要求を反映させながら、サービス連携に関わるコストを考慮したサービス連携を提供できる。本発明のサービス連携装置は、サービス提供側からサービスの呼出先とサービスを呼び出すためのデータ構造とを受け付ける提供側登録受付手段と、前記提供側登録受付手段で受け付けたサービスを記憶する提供側登録記憶手段とをさらに備える。
【００１９】
本発明は、複数のサービス提供装置によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件に基づいて、前記サービス提供装置によるサービスの呼出順序を決定する決定ステップと、前記サービスの呼出順序に応じてサービスを呼び出すステップとを有する。本発明によれば、サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携を提供できる。本発明のサービス連携方法は、前記許容時間を基に、前記サービス連携装置の処理状況に応じて、前記呼出順序を動的に再決定するステップをさらに有する。
【００２０】
本発明は、前記許容時間から前記サービス提供装置の呼出に応じた経過時間の期待範囲を決定するステップと、前記呼び出したサービスの経過時間を計測するステップと、前記サービスの経過時間が前記経過時間の期待範囲を外れる場合には、前記サービス呼出の途中結果に応じて前記決定したサービスの呼出順序を再決定するステップとをさらに有する。本発明は、前記サービスの経過時間が前記経過時間の期待範囲を上回る場合には、並行して実行されるサービス数を増やし、それらのサービスのうちで最も処理が早く終わったサービスから得られた結果に基づいて以後の処理を継続し、並行する他のサービスについてはサービスの処理をキャンセルするステップをさらに有する。
【００２１】
本発明は、前記サービスの経過時間が前記経過時間の期待範囲を下回る場合には、並行して実行されるサービス数を増やし、それらのサービスの結果を待って以後の処理を継続するステップをさらに有する。本発明のサービス連携方法は、前記許容時間内に一連の処理が終了しなかった場合に、前記許容時間を延長するかどうかをサービス依頼側へ問い合わせるステップをさらに有する。
【００２２】
本発明のサービス連携方法は、個々のサービスの利用に関する合意を、個々のサービスと対応付けて記憶するステップと、個々のサービスを利用した履歴を記憶するステップとをさらに有し、前記個々のサービスの利用に関する合意と個々のサービスを利用した履歴に基づいて、前記サービスの呼出順序を決定することを特徴とする。本発明のサービス連携方法は、個々のサービス呼出にかかった利用コストを集計するステップをさらに有し、サービスの利用コストの上限値と前記利用コストに応じて、前記サービスの呼出順序を決定することを特徴とする。本発明のサービス連携方法は、サービス提供側からサービスの呼出先とサービスを呼び出すためのデータ構造とを受け付けるステップをさらに有することを特徴とする。
【発明の効果】
【００２３】
本発明によれば、サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携装置およびサービス連携方法を提供できる。また、サービス依頼側の時間に関する要求を反映させながら、サービス利用の合意を守るようなサービス連携装置およびサービス連携方法を提供できる。また、サービス依頼側の時間に関する要求を反映させながら、サービス連携に関わるコストを考慮したサービス連携装置およびサービス連携方法を提供できる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明を実施するための最良の形態について実施例を用いて説明する。
【実施例１】
【００２５】
以下、本発明の好適な実施の形態について図面に基づき詳細に説明する。図１は、本発明の第１実施形態に係わるサービス連携装置の構成を示す図である。図１に示すように、システム１は、サービス提供装置２Ａ〜２Ｎ、サービス依頼装置３およびサービス連携装置４を備える。これらはネットワーク５を介して接続されている。サービス連携装置４は、サービス集合記憶部４１、依頼側要求受付部４２、依頼側要求記憶部４３、呼出順序決定部４４、呼出順序記憶部４５、経過時間期待範囲決定部４６、経過時間期待範囲記憶部４７、サービス呼出部４８、途中結果記憶部４９、経過時間計測部５０、経過時間記憶部５１、呼出順序再決定部５２、処理結果通知部５３、入力部５４および制御部５５を備える。
【００２６】
図２は、図１で示したサービス提供装置２の具体例を示す図である。ここではサービス提供装置２は、ホテル予約提供装置２ａ、２ｂ、航空機予約提供装置２ｃ、２ｄ、レンタカー予約提供装置２ｅ、２ｆからなる。
【００２７】
図１に戻り、サービス集合記憶部４１は、サービス連携の提供先の候補となる複数のサービス提供装置のサービス呼出用アドレス情報を含むサービス提供情報を記憶する。このサービス集合記憶部４１は、前記複数のサービス提供装置の呼出順序を、入れ替え可能な複数のサービスを一つの集合として記憶する。依頼側要求受付部４２は、サービス依頼条件を受け付けるものであり、サービス依頼側から、サービス利用にかけることができる許容時間を少なくとも含む、サービス集合に関わる要求を受け付ける。
【００２８】
依頼側要求受付部４２は、許容時間内に一連の処理が終了しなかった場合に、許容時間を延長するかどうかをサービス依頼側へ問い合わせた結果を受け付ける。依頼側要求記憶部４３は、受け付けた依頼側要求を記憶する。呼出順序決定部４４は、複数のサービス提供装置によるサービス連携処理にかけることができる許容時間を含むサービス依頼条件（依頼側要求）に基づいて、サービス提供装置２による個々のサービスの呼出順序を決定する。呼出順序記憶部４５は、決定された呼出順序を記憶する。
【００２９】
経過時間期待範囲決定部４６は、許容時間からサービス提供装置の呼出に応じた経過時間の期待範囲を決定する。経過時間期待範囲記憶部４７は、決定された期待範囲を前記依頼側要求と対応づけて記憶する。サービス呼出部４８は、記憶された呼出順序とに応じて個々のサービスを呼び出す。途中結果記憶部４９は、サービス呼出の途中結果を依頼側要求と対応づけて記憶する。
【００３０】
経過時間計測部５０は、呼び出したサービスの経過時間を計測する。経過時間記憶部５１は、経過時間計測部５０により計測された経過時間を、記憶された依頼側要求ごとに記憶する。呼出順序再決定部５２は、許容時間を基に、サービス連携装置の処理状況に応じて、呼出順序を動的に再決定する。たとえば、呼出順序再決定部５２は、サービスの経過時間が経過時間の期待範囲を外れる場合には、サービス呼出の途中結果に応じて前記決定手段が決定したサービスの呼出順序を再決定する。たとえば、呼出順序再決定部５２は、依頼側要求ごとに経過時間期待範囲と前記経過時間とを比較し、経過時間が期待範囲を外れる場合には、途中結果記憶部４９に記憶された途中結果に応じて呼出順序を再決定する。処理結果通知部５３は、一連のサービスの処理結果をサービス依頼側へ通知する。
また、処理結果通知部５３は、許容時間内に一連の処理が終了しなかった場合に、許容時間を延長するかどうかをサービス依頼側へ問い合わせる。制御部５５は、本装置全体の処理を統括する。
【００３１】
上述したサービス集合記憶部４１には、呼出順序を入れ替え可能な複数のサービスが一つの集合として記憶されている。図２の例を用いると、この集合は次のようなデータとして記憶されている。
( (Htl1 || Htl2) && (Flt1 || Flt2) && (RntC1 || RntC2) )  ・・・（式１）
【００３２】
ここで、Ｈｔｌ１はホテル予約提供装置２ａを示す識別子、Ｆｌｔ１は航空機予約提供装置２ｃを示す識別子、ＲｎｔＣ１はレンタカー予約提供装置２ｅを示す識別子である。末尾番号が２の識別子は、末尾が１の場合と同様に、末尾番号が２の装置をそれぞれ示す。そして”｜｜”は、それで結ばれている項を一つ以上呼び出すこと示す。また”＆＆”は、それで結ばれている項を、順序を問わないが呼び出すことを示す。ただし後述するように、依頼側によって特定のサービスを利用しないことが示されている場合（例えば、レンタカーは使わない場合）、サービスの呼び出されない場合もある。
【００３３】
例えば、（Ｈｔｌ１ ｜｜ Ｈｔｌ２） は、Ｈｔｌ１とＨｔｌ２のいずれか、または両方を呼び出すことを示す。また例えば、（Ｈｔｌ１ ＆＆ ＦｌＴ２） であれば、Ｈｔｌ１→ＦｌＴ２の順序で呼び出すか、または、Ｆｌｔ２→Ｈｔｌ１の順序で呼び出す。またサービス集合記憶部４１には、前記識別子と対応付けて、各サービスを呼び出す際のネットワークアドレス、サービスを呼び出す際のデータ構造のスキーマと、サービスから返ってきた結果のデータ構造のスキーマとが記憶されている。これらは、いずれもＸＭＬ文書形式で記述されており、サービス呼出部が各サービスを呼び出して結果を得るとき、および、依頼側要求受付部４２がサービス依頼側装置３から送られてきた要求データを受け付けるときに解釈されて用いられる。
【００３４】
サービス集合記憶部４１中のデータは、入出力部５４を用いてデータ入力と編集が行われる。なお異なる実施の形態として、ネットワーク５上の他の装置からデータを取り込んだり、リモート編集機能を持たせるなど、ネットワーク上の他の装置と連携してデータ入力と編集を行えるようにしても良い。
【００３５】
依頼側要求受付部４２は、サービス依頼側装置３から送られてきた要求データを受け付け、依頼側要求記憶部４３にこれを記憶させる機能を持つ。また、許容時間内に一連の処理が終了しなかった場合に、許容時間を延長するかどうかをサービス依頼側に問い合わせた結果を受け付ける機能を持つ。なお、前記許容時間延長の問い合わせは処理結果通知部５３が行う。前記要求データはＸＭＬ文書で表現されており、データ構造のスキーマは事前に依頼側装置に保持されている。データ構造には、サービス集合に含まれる各サービスを呼び出すために必要なデータと、一連の処理で許容できる時間のデータとが含まれている。
【００３６】
前記データ構造には、図２の例で言えば、ホテル予約と航空機予約とレンタカー予約に必要なデータと、一連の予約処理で許容できる時間のデータとが含まれている。なお、各サービスを呼び出すために必要なデータは、サービス集合記憶部４１に記憶されている、サービスを呼び出す際のデータ構造のスキーマに準拠している。また、特定のサービスを利用しない場合（例えば、レンタカーは使わない場合）や、許容時間を定めない場合には、これらのデータにはｎｕｌｌ値が入るものとする。
【００３７】
呼出順序決定部４４は、ある依頼側要求とサービス集合記憶部に記憶された集合データから、その依頼側要求を処理するためのサービスの呼出順序を決定する機能を持つ。呼出順序の決定の際、集合データのうち”｜｜”で繋がれた識別子からは等確率で一つを選ぶ。また、”＆＆”で結ばれた識別子についても等確率で順序を決定する。図２の例では、
(Htl1→Flt1→RntC1)
(RntC2→Flt2→Htl1)
(Htl2→RntC2→Flt1)
といった呼出順序が可能であり、それぞれの呼出順序の確率は１／４８である。
【００３８】
決定された呼出順序は、依頼側要求と対応付けて呼出順序記憶部４５に記憶される。経過時間期待範囲決定部４６は、依頼側要求に含まれる許容時間に基づいて、一連の処理で費消される時間の期待範囲を決定する機能を持つ。
【００３９】
図６は、処理にかかる経過時間期待範囲の概念を説明する図である。依頼側要求を時刻ｔａに受け付け、その依頼側要求に許容時間としてＴａが指定されていたとする。このとき、処理結果は時刻ｔｒ＝ｔａ＋Ｔａまでに依頼側に通知しなければならない。サービスの呼出順序が決定され、最初のサービス呼出が時刻ｔｓに行われたとすると、一連の処理にかけられる時間（処理可能時間）Ｔｐ＝ｔｒ−ｔｓとなる。
【００４０】
なお、Ｔａがｎｕｌｌ値の場合は、その依頼側要求に含まれる予約希望日で最も早いものの４日前午前０時をｔｒとして以後の処理を行う。呼出順序決定部４４によって決定された呼出順序に含まれるサービス数をＮとし、処理可能時間ＴｐをＮ分割した区間を設ける。
【００４１】
図２の例ではＮ＝３であり、Ｔｐは３つの区間に分割される。本実施形態では、決定された呼出順序でｎ番目に呼び出すサービスから結果が返ってくる時刻は、前記Ｎ分割のｎ番目区間の始点となる時刻以後であり、かつ、終点となる時刻から余裕時間を引いたもの以前であることを期待する。そして余裕時間を（ｎ×Ｔｐ）／２Ｎ2とする。すなわち余裕時間は、最後に呼び出すサービスに対する余裕時間をＮ分割区間の半分の時間として、それ以前に呼び出すサービスに対しては等差的に時間を減らしたものとする。
【００４２】
したがって、図６に示すように、n番目に呼び出すサービスに対する時間に関する期待範囲Ｔｎは、始点となる時刻が
（（ｎ−１）×Ｔｐ）／Ｎ＋ｔｓ、
終点となる時刻が
（（ｎ×Ｔｐ）／Ｎ）−（（ｎ×Ｔｐ）／２Ｎ2）＋ｔｓ
＝（（（２Ｎ−１）×ｎ×Ｔｐ）／２Ｎ2）＋ｔｓ
となる。
【００４３】
経過時間期待範囲決定部４６は、ある依頼側要求の許容時間を延長する場合には経過時間期待範囲を再計算して、経過時間期待範囲記憶部４７に再計算結果を記憶させる。再計算は、依頼側要求受付時刻ｔｓのかわりに許容時間延長の受付時刻ｔｅを、許容時間として新たに延長された時間Ｔａ’を、サービス数Ｎのかわりに依頼側要求を処理する呼出順序でまだ呼び出していないサービスの数Ｍを用いて計算する。計算方法は上記と同様なので割愛する。なお、上述した経過時間期待範囲の計算方法は一例であり、他の計算方法を用いても構わない。例えば、過去の呼出実績から期待範囲を補正して計算しても良い。
【００４４】
経過時間計測部５０は、サービス呼出部４８がサービスを呼び出して結果が返ってくるまでの経過時間を計測し、経過時間を依頼側要求ごとに積算して経過時間記憶部５１に記憶させる機能を持つ。サービスの経過時間が経過時間の期待範囲を外れたときの対処は、呼出順序再決定部５２による呼出順序の再決定と、サービス呼出部４８によるサービス呼出が前記再決定に応じて変化することで実現される。
【００４５】
この対処の基本的な考え方は次の通りである。経過時間が期待範囲を上回っている場合には、その時点で処理中のサービスより早く処理が終了する可能性を別のサービスを並行利用することで試してみる。そして、それらの利用で最も早く得た結果のみを以後の一連の処理に採用し、並行する他のサービスは処理をキャンセルする。経過時間が期待範囲を下回っている場合にも現在処理しているサービスと別のサービスを並行利用するが、これは異なる結果を得られる可能性を試すものである。この場合には、並行するサービスの結果をすべて得てから、以後の一連の処理を実行する。
【００４６】
上述した考えに基づいて、呼出順序再決定部５２は、経過時間が期待範囲を外れている場合に、その時点で処理中のサービスと呼出順序とサービス集合とに基づいて、並行処理可能なサービスを探し出すとともに、探し出したサービスに応じて呼出順序を更新する。そしてサービス呼出部４８は、更新された呼出順序に応じたサービスの呼び出しとその結果の以後の処理への反映を行う。なお現在処理中のサービスは、サービス呼出部によって、呼出順序と対応づけて途中結果記憶部４９に記憶されている。
【００４７】
ここで呼出順序再決定部５２による再決定の手順を図２の例を用いながら説明する。呼出順序決定部４４が決定した呼出順序が（Ｈｔｌ１→Ｆｌｔ１→ＲｎｔＣ１）であり、現在Ｆｌｔ１が処理中であるとする。そして経過時間が期待範囲を上回ったとする。呼出順序再決定部５２は、Ｆｌｔ１と並行可能なサービスを、サービス集合の式１と現在の呼出順序とから探す。
【００４８】
まず、式１からＦｌｔ１と”｜｜”で結ばれたＦｌｔ２が呼び出し可能であることがわかる。次に、Ｆｌｔ１以降の呼出順序がＦｌｔ１→ＲｎｔＣ１であり、さらに式１からＦｌｔ１とＲｎｔＣ１の順序が入れ替え可能であることがわかる。したがって、Ｆｌｔ２とＲｎｔＣ１とがＦｌｔ１と並行処理可能なサービスとし、それらの結果が返ってきた場合の以後の呼出順序はそれぞれＦｌｔ２→ＲｎｔＣ１とＲｎｔＣ１→Ｆｌｔ１になる。呼出順序再決定部５２は、呼出順序記憶部４５に記憶される呼出順序を次のものに更新する。
【００４９】
(Htl1→(Flt1→RntC1；Flt2→RntC1；RntC1→Flt1｜Over))  ・・・（式２）
【００５０】
ここで”；”で結ばれた部分が並行処理可能なサービスとそれ以後の呼出順序を示す。これらに続いて”｜”の後の項目は、経過時間が期待範囲を上回った場合は”Ｏｖｅｒ”、下回った場合が”Ｕｎｄｅｒ”と記述する。この再決定が行われると、更新された呼出順序に基づいて、サービス呼出部４８がＦｌｔ２とＲｎｔＣ１を呼び出す。並行するＦｌｔ１, Ｆｌｔ２, ＲｎｔＣ１の結果の待ち方は、経過時間が期待範囲を上回っている場合と下回っている場合とで異なる。上回っている場合には、これら３つのうちの一つでも結果が返ってくれば、他の２つのサービスへ処理のキャンセルを通知する。
【００５１】
いま、返ってきた結果がＦｌｔ２によるものだとすると、Ｆｌｔ１とＲｎｔＣ１の処理をキャンセルさせる。そして、式２に規定されているように、呼出順序がＦｌｔ２の次になるＲｎｔＣ１を呼び出す。このサービス呼出の際には、Ｈｔｌ１の結果とＦｌｔ２の結果とが反映される。経過時間が期待範囲を下回っている場合、すなわち、式２の”Ｏｖｅｒ”のかわりに”Ｕｎｄｅｒ”が記述されている場合は、並行するＦｌｔ１, Ｆｌｔ２, ＲｎｔＣ１のすべての結果が返ってくるまで待ち、結果のうちから依頼側要求を最も満たしているもの（例えば、希望順位の高い予約が取れたもの）を一つ選ぶ。もし全ての結果が同程度に要求を満たしているならば、ランダムに一つを選ぶ。例えばＦｌｔ１が選ばれた場合は、式２に従いＲｎｔＣ１を次に呼び出す。
【００５２】
なお、並行するサービスの結果待ちの間に経過時間が期待範囲を上回ってしまった場合、呼出順序再決定部が呼出順序の”Ｕｎｄｅｒ”を”Ｏｖｅｒ”に書き換える。こうすることで、サービス呼出部の結果の待ち方が変わり、どれか一つでも結果が返っていれば以後の処理が継続される。
【００５３】
処理結果通知部５３は、サービス依頼側に一連の処理の結果を通知する機能を持つ。そして、処理結果が依頼側要求を満たす場合には依頼側に関わるデータ、すなわち、依頼側要求記憶部４３と経過時間記憶部５１と経過時間期待範囲記憶部４７と呼出順序記憶部４５と途中結果記憶部４９にそれぞれ記憶されたデータを削除する機能を持つ。また、許容時間内に一連の処理が終了しなかった場合に、許容時間を延長するかどうかをサービス依頼側に問い合わる機能を持つ。
【００５４】
図３乃至図５は、システムの処理フローチャートを示す図である。ステップＳ１１で、装置が停止でなく、ステップＳ１２で、サービス集合が編集される場合、ステップＳ１３で、サービス集合の編集内容を記憶する。ステップＳ１４で、依頼側要求を受け付けた場合、ステップＳ１５で、受け付けた依頼側要求を記憶し、ステップＳ１６で、前記要求に対する呼出順序を決定し記憶し、ステップＳ１７で、決定された呼出順序の最初のサービスを呼び出し、ステップＳ１８で、前記要求に対する経過時間期待範囲を決定し記憶する。ステップＳ１９で、処理中のサービスの経過時間を計測し、依頼側要求ごとの経過時間を更新する。
【００５５】
ステップＳ２０で、経過時間が期待範囲から外れる依頼側要求がある場合、ステップＳ２１で、前記要求に対する呼出順序を再決定し、ステップＳ２２で、再決定に基づいて、並行されるサービスを呼び出す。ステップＳ２３で、呼び出したサービスから結果が返っていない場合、図４の１に進む。ステップＳ２４で、経過時間が許容時間を超えた依頼側要求がある場合、ステップＳ２５で、サービス依頼側に許容時間を延長するかどうかを問い合わせる。ステップＳ２６で、サービス依頼側から許容時間延長に対する返答を受け、ステップＳ２７で、許容時間を延長しない場合、ステップＳ２８で、一連の処理が許容時間で終了しなけったことを依頼側へ通知し、ステップＳ２９で、依頼側要求に関わるデータを全ての記憶部から削除し、ステップＳ１１に戻る。
【００５６】
ステップＳ２７で、許容時間を延長する場合、ステップＳ３０で、記憶された依頼側要求の許容時間を、受け付けた値に更新し、ステップＳ３１で、呼出順序でまだ呼び出していないサービスの数と延長時間に応じて、経過時間期待範囲を更新する。ステップＳ２３で、呼び出したサービスから結果が返った場合、図５の２に進み、ステップＳ３２で、返った結果を途中結果として記憶する。ステップＳ３３で、結果を返したサービスと並行するものがない場合、ステップＳ３６に進む。ステップＳ３３で、結果を返したサービスと並行するものがある場合、ステップＳ３４で、前記並行は、許容時間が期待範囲を上回ることに起因しない場合、ステップＳ１１に戻る。
【００５７】
ステップＳ３４で、前記並行は、許容時間が期待範囲を上回ることに起因する場合、ステップＳ３５で、並行するサービスすべてに対して処理のキャンセルを通知する。ステップＳ３６で、呼出順序で次に呼び出すサービスがある場合、ステップＳ３９で、次のサービスを呼び出し、ステップＳ１１に戻る。ステップＳ３６で、呼出順序で次に呼び出すサービスがない場合、ステップＳ３７で、一連の処理結果を依頼側へ通知し、ステップＳ３８で、前記依頼側要求に関わるデータを全ての記憶部から削除し、ステップＳ１１に戻る。
【００５８】
なお、上述した呼出順序再決定とそれ以後の処理にもかかわらず、ネットワークの状態やサービスの稼働状況によっては許容時間までに一連の処理が終了しない可能性は残る。
【００５９】
本実施例においては、経過時間が許容時間を超えた場合には、サービス依頼側に許容時間を延長可能かどうかを問い合わせる。もし延長が可能であり、延長時間が指示された場合は、期待範囲を再計算して一連の処理を継続する。延長不可能であれば、サービス依頼側に要求を満たせなかったことを通知し、この依頼側要求に対する処理は終了する。
【００６０】
本実施例によれば、サービス利用側が規定した処理時間に応じて、サービスの連携を一連の処理の途中で動的に変更するので、サービス依頼側の時間に関する要求を反映させ、ネットワークサービスの状況に対応できるようなサービス連携が実現できる。
【実施例２】
【００６１】
次に、本発明の第２実施例について説明する。図７は、本発明の第２実施例に係わるシステムの構成を示す図である。図７に示すように、システム２０１は、サービス提供装置２Ａ〜２Ｎ、サービス依頼装置３およびサービス連携装置２０４を備える。これらはネットワーク５を介して接続されている。サービス連携装置２０４は、サービス集合記憶部４１、依頼側要求受付部４２、依頼側要求記憶部４３、呼出順序決定部４４、呼出順序記憶部４５、経過時間期待範囲決定部４６、経過時間期待範囲記憶部４７、サービス呼出部４８、途中結果記憶部４９、経過時間計測部５０、経過時間記憶部５１、呼出順序再決定部５２、処理結果通知部５３、入力部５４、制御部５５、サービス利用履歴記憶部２０５、サービス利用合意記憶部２０６を備える。
【００６２】
第１実施例との違いは、サービス利用合意記憶部２０６とサービス利用履歴記憶部２０５が存在し、これらに記憶されたデータに応じて呼出順序決定部４４と呼出順序再決定部５２が処理を行うことである。サービス利用合意記憶部２０６は、個々のサービスの利用に関する合意を、個々のサービスと対応付けて記憶するものであり、サービス集合記憶部４１に記憶されたサービス集合に含まれるサービスごとに、一定期間に最低何回サービスを利用するかが記憶されている。このデータは、サービス連携装置２０４の運営体とサービス提供装置２の運営体とが結んだ合意に基づいており、入出力部を用いて入力と編集が行われる。
【００６３】
サービス利用履歴記憶部２０５は、個々のサービスを利用した履歴を記憶するものであり、各サービスを呼び出した日時、および、呼出結果を一連の処理結果に最終的に採用したかどうかを含む、サービス利用の履歴データを記憶している。このデータは、サービス呼出部４８によって書き込まれる。呼出順序決定部４４は、個々のサービスの利用に関する合意と個々のサービスを利用した履歴に基づいて、サービスの呼出順序を決定する。また、呼出順序決定部４４は、呼び出すサービスを決定する際に、サービス利用合意記憶部２０６に記憶されたデータとサービス利用履歴記憶部２０５に記憶されたデータに基づいた重み付けを行って、呼び出すサービスを決定する。
【００６４】
図２の例において、Ｈｔｌ１が日２回以上、Ｈｔｌ２が日５回以上の利用が合意されており、今日はＨｔｌ１がまだ利用されていないがＨｔｌ２は既に２回されているとする。このときの重み付けはＨｔｌ１：Ｈｔｌ２＝２：３となり、この重みに従う確率でＨｔｌ１かＨｔｌ２が選ばれる。なお、サービスを呼び出しても結果が返ってこなかったり、その結果が一連の処理結果に最終的に採用されなかった場合は、この呼び出しは利用回数にカウントされない。呼出順序再決定部５２は、呼出順序の再決定の際に前記と同様の重み付けを行い、再決定を行う。他の機能部については上記実施例と同様なので説明を割愛する。
【００６５】
本実施例によれば、サービス提供側との合意とサービスの利用履歴とに応じて、サービスの連携を変化させるので、サービス依頼側の時間に関する要求を反映させながら、サービス利用の合意を守るようなサービス連携が実現できる。
【実施例３】
【００６６】
次に、本発明の第３実施例について説明する。図８は、本発明の第３実施例に係わるシステムの構成を示す図である。図８に示すように、システム３０１は、サービス提供装置２Ａ〜２Ｎ、サービス依頼装置３およびサービス連携装置３０４を備える。これらはネットワーク５を介して接続されている。サービス連携装置３０４は、サービス集合記憶部４１、依頼側要求受付部４２、依頼側要求記憶部４３、呼出順序決定部４４、呼出順序記憶部４５、経過時間期待範囲決定部４６、経過時間期待範囲記憶部４７、サービス呼出部４８、途中結果記憶部４９、経過時間計測部５０、経過時間記憶部５１、呼出順序再決定部５２、処理結果通知部５３、入力部５４、制御部５５、コスト使用量記憶部３０５、コスト上限設定記憶部３０６を備える。
【００６７】
第２実施例との違いは、コスト上限設定記憶部３０６とコスト使用量記憶部３０５が存在し、これらに記憶されたデータに応じて呼出順序再決定部５２が処理を行うことである。また、サービス集合記憶部４１に記憶されるデータ構造と、サービス呼出部４８の処理に違いがある。サービス集合記憶部４１に記憶されているデータ構造のうち、サービスから返ってきた結果のデータ構造には、そのサービスを利用したことに対するコスト使用量に関するデータが少なくとも含まれている。このコスト使用量に関するデータは、サービス呼出部４８がコスト使用量記憶部３０５にサービス依頼側ごとに積算して記憶させる。したがって、サービス呼出部４８が個々のサービス呼出にかかった利用コストを検出し、検出された利用コストをサービス依頼側ごとに集計するものである。
【００６８】
コスト上限設定記憶部３０６には、サービスの利用コストの上限値をサービス依頼側と対応付けて記憶する。このデータは入出力部５４を用いて入力と編集が行われる。呼出順序再決定部５２は、サービスの利用コストの上限値とコスト使用量に応じて、サービスの呼出順序を決定するものであり、コスト上限値とコスト使用量とを比較し、使用量が上限値を上回っている場合には、経過時間が期待範囲を下回っていても呼出順序の再決定は行わない。これにより、過度のサービス呼出を防ぐことができる。他の機能部については上記実施例と同様なので説明を割愛する。なお、コスト使用量記憶部３０５に記憶されたコスト使用量を定期的にクリアするように構成しても良い。これにより、例えば月ごとの利用制限など、サービス依頼側ごとの定期的なサービス利用管理が容易となる。
【００６９】
本実施例によれば、サービス利用コストに応じてサービスの連携を変化させるので、サービス依頼側の時間に関する要求を反映させながら、サービス連携に関わるコストを考慮したサービス連携が実現できる。
【実施例４】
【００７０】
次に、本発明の第４実施例について説明する。図９は、本発明の第４実施例に係わるシステム４０１の構成を示す図である。図９に示すように、システム４０１は、サービス提供装置２Ａ〜２Ｎ、サービス依頼装置３およびサービス連携装置４０４を備える。これらはネットワーク５を介して接続されている。
【００７１】
サービス連携装置４０４は、サービス集合記憶部４１、依頼側要求受付部４２、依頼側要求記憶部４３、呼出順序決定部４４、呼出順序記憶部４５、経過時間期待範囲決定部４６、経過時間期待範囲記憶部４７、サービス呼出部４８、途中結果記憶部４９、経過時間計測部５０、経過時間記憶部５１、呼出順序再決定部５２、処理結果通知部５３、入力部５４、制御部５５、提供側登録受付部４０５および提供側登録記録部４０６を備える。
【００７２】
実施例１との違いは、提供側登録受付部４０５と提供側登録記憶部４０６が存在することである。提供側登録受付部４０５は、サービス提供側からサービスの呼出先とサービスを呼び出すためのデータ構造とを受け付ける機能を持つ。提供側登録記憶部４０６は、提供側登録受付部４０５で受け付けたサービスを記憶する機能を持つ。前記記憶されたサービス登録は、サービス集合記憶部に記憶されるサービス集合を入力及び編集する際に選択的に利用される。
【００７３】
なお、本発明によるサービス連携方法は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ(Read Only Memory)、ＲＡＭ(Random Access Memory)等を用いて実現され、プログラムをハードディスク装置や、ＣＤ−ＲＯＭ、ＤＶＤまたはフレキシブルディスクなどの可搬型記憶媒体等からインストールし、または通信回路からダウンロードし、ＣＰＵがこのプログラムを実行することで、各ステップが実現される。
【００７４】
以上本発明の好ましい実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。
【図面の簡単な説明】
【００７５】
【図１】本発明の第１実施形態に係わるサービス連携装置の構成を示す図である。
【図２】本発明の第１実施例に係るシステムの構成例を示す図である。
【図３】システムの処理フローチャートを示す図である。
【図４】システムの処理フローチャートを示す図である。
【図５】システムの処理フローチャートを示す図である。
【図６】処理にかかる経過時間期待範囲の概念を説明する図である。
【図７】本発明の第２実施例に係わるシステムの構成を示す図である。
【図８】本発明の第３実施例に係わるシステムの構成を示す図である。
【図９】本発明の第４実施例に係わるシステム４０１の構成を示す図である。
【符号の説明】
【００７６】
１  システム                          ５３  処理結果通知部
２  サービス提供装置                  ５４  入力部
３  サービス依頼側装置                ５５  制御部
４  サービス連携装置                  １０１  システム
４１  サービス集合記憶部              ２０１  システム
４２  依頼側要求受付部                ２０４  サービス連携装置
４３  依頼側要求記憶部                ２０５  サービス利用履歴記憶部
４４  呼出順序決定部                  ２０６  サービス利用合意記憶部
４５  呼出順序記憶部                  ３０１  システム
４６  経過時間期待範囲決定部          ３０５  コスト使用量記憶部
４７  経過時間期待範囲記憶部          ３０６  コスト上限設定記憶部
４８  サービス呼出部                  ４０１  システム
４９  途中結果記憶部                  ４０４  サービス連携装置
５０  経過時間計測部                  ４０５  提供側登録受付部
５１  経過時間記憶部                  ４０６  提供側登録記憶部
５２  呼出順序再決定部                
【図１】
2006277098.tif 000003
【図２】
2006277098.tif 000004
【図３】
2006277098.tif 000005
【図４】
2006277098.tif 000006
【図５】
2006277098.tif 000007
【図６】
2006277098.tif 000008
【図７】
2006277098.tif 000009
【図８】
2006277098.tif 000010
【図９】
2006277098.tif 000011