JP7150549B2 - サービス制御システムおよび方法 - Google Patents

Description

本発明は、概して、サービスの制御に関し、例えば、ロボットとロボットの外部にある機器との連携に関する。

非特許文献１によれば、ロボットは、ロボットが備えるマイクやカメラのほか、ロボットの外部にある機器（例えば、ロボットの管理サーバに直接通信できる機器（例えば、環境カメラやデジタルサイネージ））を活用することで、サービスロボット単体では実現できないサービスを提供する。

吉内英也、松田知紘、戴競択著、「サービスロボット向け外部機器連携制御技術の検討」 電子情報通信学会２０１８年総合大会講演論文集、電子情報通信学会出版 、２０１８年３月６日発行、D-22-4インデクス。

昨今、ロボットに関する研究開発が加速しており、商業施設（店舗や銀行等）や公共施設（空港、駅、役所、病院等）等の様々な場所において、ロボットによるサービス（接客、案内、通訳、介護、対話等）の提供について実用化が進められている。人が従来行っていた業務をロボットに代替させることで、労働力確保の問題の解消や人件費の抑制等の様々な効果が期待される。

ところで、ロボット（例えばサービスロボット）が様々な人間（例えば従業員）の代替になれるには多様で複雑な業務を遂行できるようになる必要がある。しかし、それを実現するには、外部の機器とのやり取りのために、いわゆる入力手段（例えばセンサー）、処理手段（例えばプログラム）、または出力手段（例えばイネーブラー）といった不足の手段をロボットに増やす必要がある。これらの手段をロボットに全部集結することがコスト的にまたは技術的に非現実なので、ロボットの外部に既に存在する機能を利用するほうが実現しやすい。

上記非特許文献１には、サービスロボット以外の機器をサービスロボットシステム内で管理し、当該サービスロボットと連携させる方法が開示されているが、他システムが備える入力手段、処理手段、または出力手段といった手段と、当該サービスロボットと、の連携については開示されていない。

上述の課題は、ロボットが業務としてのサービスを実行する場合に限らず、ロボット以外の機器がサービスを実行する場合についてもあり得る。

サービス制御システムが、ネットワークに接続された複数のローカルシステムが提供可能な複数の連携サービスに関する情報を含んだ管理情報を管理する。複数のローカルシステムの各々は、一つ以上のローカル装置を含む。複数の連携サービスの各々は、少なくとも一つの他の連携サービスと連携することが可能なサービスである。サービス制御システムは、対象ローカル装置（複数のローカルシステムのうちのいずれかのローカルシステムにおける一のローカル装置）から、希望のサービスに関する情報である希望情報が関連付けられたリクエストを受け付ける。サービス制御システムは、当該リクエストに関連付けられている情報を満たす、一つ以上の連携サービスの連鎖である連携サービス連鎖を、管理情報を基に設計する。サービス制御システムは、当該連携サービス連鎖を示す情報である連鎖情報を、対象ローカル装置に送信する。

一つのローカル装置が多様で複雑なサービスを遂行できる。

一実施例に係る連携サービスシステムの構成の例を示す図である。 仲介装置の構成例を示す図である。 ローカル装置の構成例を示す図である。 サービス分類テーブルの構成例を示す図である。 連携サービステーブルの構成例を示す図である。 標準アクションテーブルの構成例を示す図である。 標準シナリオ定義テーブルの構成例を示す図である。 提供者テーブルの構成例を示す図である。 提供可能サービステーブルの構成例を示す図である。 利用可能サービステーブルの構成例を示す図である。 提供中サービステーブルの構成例を示す図である。 利用中サービステーブルの構成例を示す図である。 分類更新メッセージの構成の例を示す図である。 サービス更新メッセージの構成例を示す図である。 アクション更新メッセージの構成例を示す図である。 シナリオ更新メッセージの構成例を示す図である。 提供者更新メッセージの構成例を示す図である。 対応結果通知メッセージの構成例を示す図である。 バージョン変更周知メッセージの構成例を示す図である。 調査依頼メッセージの構成例を示す図である。 設計依頼メッセージの構成例を示す図である。 調査依頼返答メッセージの構成例を示す図である。 設計依頼返答メッセージの構成例を示す図である。 サービス依頼メッセージの構成例を示す図である。 サービス依頼返答メッセージの構成例を示す図である。 アクション実行状態通知メッセージの構成例を示す図である。 終了通知返答メッセージの構成例を示す図である。 管理プログラムが行う処理の一例を示すフローチャートである。 仲介プログラムが行う処理の一例を示すフローチャートである。 連鎖設計処理の一例を示すフローチャートである。 利用申請プログラムが行う処理の一例を示すフローチャートである。 利用実行プログラムが行う処理の一例を示すフローチャートである。 利用実行処理の一例を示すフローチャートである。 ローカル管理プログラムが行う処理の一例を示すフローチャートである。 依頼受付プログラムが行う処理の一例を示すフローチャートである。 提供実行プログラムが行う処理の一例を示すフローチャートである。 提供実行処理の一例を示すフローチャートである。 メッセージシーケンスの第１の例を示す図である。 メッセージシーケンスの第２の例を示す図である。 連携サービスまたは連携サービス連鎖を検索するためのＧＵＩ（Graphical User Interface）とその検索結果を表示するためのＧＵＩとの一例を示す図である。

以下の説明では、「インターフェースデバイス部」は、一つ以上のインターフェースデバイスでよい。当該一つ以上のインターフェースデバイスは、下記のうちのいずれでもよい。
・Ｉ／Ｏ（Input/Output）デバイスと遠隔の表示用計算機とのうちの少なくとも一つに対するＩ／Ｏインターフェースデバイス。表示用計算機に対するＩ／Ｏインターフェースデバイスは、通信インターフェースデバイスでよい。少なくとも一つのＩ／Ｏデバイスは、ユーザインターフェースデバイス、例えば、キーボードおよびポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・一つ以上の通信インターフェースデバイス。一つ以上の通信インターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

以下の説明では、「メモリ部」は、一つ以上のメモリでよい。少なくとも一つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。メモリ部は、主に、プロセッサ部による処理の際に使用される。

また、以下の説明では、「ＰＤＥＶ部」は、一つ以上のＰＤＥＶでよい。「ＰＤＥＶ」は、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）、例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。ＰＤＥＶ部は、ＲＡＩＤグループであってもよい。「ＲＡＩＤ」は、Redundant Array of Independent (or Inexpensive) Disksの略である。

また、以下の説明では、「記憶部」は、メモリ部およびＰＤＥＶ部のうちの少なくともメモリ部を含む。

また、以下の説明では、「プロセッサ部」は、一つ以上のプロセッサでよい。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。一つ以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。一部のプロセッサは、処理の一部または全部を行うハードウェア回路でもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部および／またはインターフェース部を用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有する装置またはシステム）とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。また、以下の説明において、二つ以上のプログラムが一つのプログラムとして実現されてもよいし、一つのプログラムが二つ以上のプログラムとして実現されてもよい。

また、以下の説明では、「ｘｘｘテーブル」（または「ｘｘｘメッセージ」）といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」（または「ｘｘｘメッセージ」）を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブル（および各メッセージ）の構成は一例であり、一つのテーブル（または一つのメッセージ）は、二つ以上のテーブル（または二つ以上のメッセージ）に分割されてもよいし、二つ以上のテーブル（または二つ以上のメッセージ）の全部または一部が一つのテーブル（または一つのメッセージ）であってもよい。

また、以下の説明では、「仲介装置」は、一以上の計算機で構成されてよい。具体的には、例えば、計算機が表示デバイスを有していて計算機が自分の表示デバイスに情報を表示する場合、当該計算機が仲介装置でよい。また、例えば、第１計算機（例えばサーバ）が表示用情報を遠隔の第２計算機（表示用計算機（例えばクライアント））に送信し表示用計算機がその情報を表示する場合（第１計算機が第２計算機に情報を表示する場合）、第１計算機と第２計算機とのうちの少なくとも第１計算機が仲介装置でよい。仲介装置が「表示用情報を表示する」ことは、当該装置が有する表示デバイスに表示用情報を表示することであってもよいし、当該装置が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。

また、以下の説明では、「連携サービス連鎖」は、一つ以上の連携サービスで構成された連携サービス群である。「連携サービス」は、連携サービス連鎖の構成要素となるサービスであって、他の連携サービスと連携可能なサービスである。例えば、検索という連携サービスと、表示という連携サービスの組合せが、検索を行い検索の結果を表示するという連携サービス連鎖に相当する。

図１は、一実施例に係る連携サービスシステムの構成例を示す図である。

連携サービスシステムは、仲介装置（ＣＳＢ（Cooperation Service Broker）とよばれてもよい）１と、管理端末５と、複数のローカルシステム３とを備える。仲介装置１、管理端末５および複数のローカルシステム３が、ネットワーク４に接続される。管理端末５は、仲介装置１の表示用計算機の一例でよく、例えば、キーボードやポインティングデバイスのような入力デバイスと、液晶ディスプレイのような表示デバイスとを有する。

各ローカルシステム３は、連携サービスの利用と提供の少なくとも一方を行うシステムである。複数のローカルシステム３のうちの一つ以上のローカルシステム３が異なる複数の連携サービスを提供する。各ローカルシステム３は、一つ以上のローカル装置（ＣＳＬＭ（Cooperation Service Local Manager）と呼ばれてもよい）２を備える。ローカル装置２としては、プロセッサ、マイクロフォン、スピーカ、表示デバイス等を採用することができる。

複数のローカルシステム３のうちの少なくとも一つのローカルシステム３が、当該ローカルシステム３が提供する連携サービスに代えてまたは加えて当該ローカルシステム３以外の一つ以上の連携サービスで構成された連携サービス連鎖を提供する。例えば、各ローカルシステム３は、自分の連携サービス（機能）を提供する提供者となることもできれば、他のローカルシステム３の連携サービスを求める依頼者および利用者となることもできる。以下の説明では、「依頼者」および「利用者」は、連携サービスの依頼者および利用者、典型的には、連携サービスの依頼を出し当該依頼に応答して提供された連携サービスを利用するローカルシステム３（または、当該ローカルシステム３における一つ以上のローカル装置２）を意味する。また、「提供者」は、連携サービスの提供者、典型的には、連携サービスの依頼に応答して当該連携サービスを提供するローカルシステム３（または、当該ローカルシステム３における一つ以上のローカル装置２）を意味する。

ネットワーク４は、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、ＷＡＮ（Wide Area Network）など、一または複数の種類のネットワークで構成してもよい。

本実施例の概要は次の通りである。すなわち、本実施例では、サービスロボット（ローカル装置２の一例）が当該ロボットを含むシステム３に代えてまたは加えて当該ロボットを含まない他のシステム３が提供するサービスを含んだ一つ以上のサービスを連携することで、多様なサービスを提供する。具体的には、例えば、下記（１）および（２）のうち少なくとも（１）が行われる。
（１）サービスロボットが仲介装置１に希望の連携サービスまたはサービス分類を伝えると、仲介装置１が、当該希望に沿った適切な連携サービスまたは連携サービス連鎖を提案する。サービスロボットが、その提案を受けて、連携サービスまたは連携サービス連鎖を選び、選んだ連携サービスまたは連携サービス連鎖を利用する。連携サービスまたは連携サービス連鎖の提案と利用を実現するために、全ローカルシステム３において、連携サービスの定義と、その実行に必要なインプットの定義と、その実行によるアウトプットの定義と、連携サービスに必要なアクションといった要素が標準化されている。
（２）連携サービスを提供することで提供者が得られる対価と、連携サービスを利用することで利用者にかかる対価が定義される。

図２は、仲介装置１の構成例を示す図である。

仲介装置１においては、マイクロプロセッサからなるＣＰＵ（Central Processing Unit）１１（プロセッサ部の一例）にバス１２を介して記憶装置１３(ＰＤＥＶ部の一例)、メモリ１４（メモリ部の一例）、および通信インターフェース１５（インターフェース部の一例）が接続されている。

通信インターフェース１５は、ＣＰＵ１１の制御の下で、ネットワーク４により規定される通信プロトコルに従い、ネットワーク４に接続しているローカルシステム３のローカル装置２および管理端末５と通信を行う。通信プロトコルとしては、例えばＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）等を使用するが、他の通信プロトコルを使用することも可能である。

記憶装置１３には、サービス分類テーブル１３１と、連携サービステーブル１３２と、標準アクションテーブル１３３と、標準シナリオ定義テーブル１３４と、提供者テーブル１３５といったテーブルが格納されている。

メモリ１４には、仲介プログラム１４１と、管理プログラム１４２といったプログラムが格納されている。

図３は、ローカル装置２の構成例を示す図である。

ローカル装置２においては、マイクロプロセッサからなるＣＰＵ２１にバス２２を介して記憶装置２３、メモリ２４、および通信インターフェース２５が接続されている。ローカル装置２は、典型的には、図３に例示のように、ＣＰＵ２１やメモリ２４といった計算機リソースを備える装置であるが、仲介装置１と通信可能な他のローカル装置２から制御される装置であってもよい。

通信インターフェース２５は、ＣＰＵ２１の制御の下で、ネットワーク４により規定される通信プロトコルに従い、ネットワーク４に接続しているほかのローカルシステム３のローカル装置２および仲介装置１と通信を行う。

記憶装置２３には、提供可能サービステーブル２３１と、利用可能サービステーブル２３２と、提供中サービステーブル２３３と、利用中サービステーブル２３４といったテーブルが格納されている。

メモリ２４には、ローカル管理プログラム２４１と、依頼受付プログラム２４２と、利用申請プログラム２４３と、利用実行プログラム２４４と、提供実行プログラム２４５といったプログラムが格納されている。

図４は、サービス分類テーブル１３１の構成例を示す図である。

サービス分類テーブル１３１は、木構造または包含関係にあるサービス分類の関係に関する情報を保持する。具体的には、例えば、サービス分類テーブル１３１は、バージョン情報１３１０１を格納する。また、サービス分類テーブル１３１は、サービス分類毎にエントリを有する。各エントリが、分類ＵＵＩＤ１３１０２、分類名１３１０３、下位分類名１３１０４、下位分類ＵＵＩＤ１３１０５、および有効性１３１０６といった情報を記憶する。各エントリに記憶される情報の説明については、一つのサービス分類を例に取る（図４の説明において「対象分類」）。

分類ＵＵＩＤ１３１０２は、対象分類のＵＵＩＤ（Universally Unique Identifier）を示す。各分類のＵＵＩＤは、連携サービスシステムにおいて一意の（重複の無い）ＩＤである。

分類名１３１０３は、対象分類の名称を示す。当該名称は、例えば、対象分類に属する連携サービスの性質の内容を人間が理解できる文字列である。

下位分類名１３１０４は、対象分類の下位分類の名称を示す。下位分類ＵＵＩＤ１３１０５は、当該下位分類のＵＵＩＤを示す。なお、対象分類の下位に直列になった複数の分類が存在する場合、下位分類名１３１０４は、子分類（対象分類の下位に存在する分類のうち対象分類の最も近くに存在する分類）の名称を示し、下位分類ＵＵＩＤ１３１０５は、当該子分類のＵＵＩＤを示す。

有効性１３１０６は、下位分類名１３１０４の表す分類が対象分類（分類名１３１０３の表す分類）に所属する関係が成立しているかどうかを示す。有効性１３１０６の値は「有効」または「無効」がある。従って、上述したように、本テーブル１３１が、連携サービスシステムの管理対象となる連携サービスの分類体系（サービス分類の関係）を示す情報を保存している。本テーブル１３１を用いて、連携サービスシステムに関与するプログラムそしてシステムに関与する人間が、性質の近い二つ以上の連携サービスを見つけることがきる。一つのサービス分類に複数の下位分類（複数の子分類）が所属することが考えられる。

バージョン情報１３１０１は、本テーブル１３１のバージョン（具体的には、サービス分類の関係の最新のパターンを意味する最新のバージョン）を示す。パターン更新ごとに（サービス分類の関係が更新されるごとに）一定のルールでバージョン情報１３１０１も変更される。

図５は、連携サービステーブル１３２の構成例を示す図である。

連携サービステーブル１３２は、連携サービスに関する情報を保持する。具体的には、例えば、連携サービステーブル１３２は、連携サービス毎にエントリを有する。各エントリは、サービスＵＵＩＤ１３２０１と、サービス名１３２０２と、分類名１３２０３と、分類ＵＵＩＤ１３２０４と、インプット１３２０５と、インプット定義１３２０６と、インプットＵＵＩＤ１３２０７と、アウトプット１３２０８と、アウトプット定義１３２０９と、アウトプットＵＵＩＤ１３２１０と、有効性１３２１１と、バージョン１３２１２といった情報を記憶する。以下、一つの連携サービスを例に取る（図５の説明において「対象サービス」）。

サービスＵＵＩＤ１３２０１は、対象サービスのＵＵＩＤを示す。サービス名１３２０２は、対象サービスの名称を示す。当該名称は、例えば、対象サービスの内容を人間が理解できる文字列である。

分類名１３２０３は、対象サービスが所属するサービス分類を示す。分類ＵＵＩＤ１３２０４は、当該サービス分類のＵＵＩＤを示す。

インプット１３２０５が、対象サービスの実行に必要なインプットを示す。インプット（インプットしての材料）は、連携サービスの性質によって様々な形態が考えられ、例えば実際の物体や、ある事象の状態や、ある通信手段で送られた情報などでもありえる。インプット定義１３２０６が、当該インプットの定義を示す。インプットＵＵＩＤ１３２０７は、当該インプットのＵＵＩＤを示す。

連携サービスの依頼者と提供者を設計または管理する人間が事前にインプット定義１３０２６を通して、このインプットに対する理解について、コンセンサスを取っていることが望ましい。例えば、「短距離荷物運搬」という連携サービスがあり、運搬の対象が、インプット１３２０５およびインプット定義１３２０６により示される。例えば、インプット１３２０５は「５Ｋｇ以下の縦横高さの合計が１６０ｃｍ以内の立方体」である。運搬能力のないサービスロボットを作っている設計者が連携サービス「短距離荷物運搬」のインプット定義１３２０６を理解し、サービスロボットが荷物の配達任務を人間にアサインされたら、連携サービス「短距離荷物運搬」を依頼するというロジックをプログラミングなどの手段で実現することができる。同様に、短距離で荷物を運搬できる自動台車ロボットが連携サービス「短距離荷物運搬」を正しく提供するためには、運搬対象が「５Ｋｇ以下の縦横高さの合計が１６０ｃｍ以内の立方体」と想定した上で自動台車ロボットを設計することが必要である。

アウトプット１３２０８は、対象サービスの実行によって生み出した成果としてのアウトプットを示す。アウトプット定義１３２０９が、当該アウトプットの定義を示す。アウトプットＵＵＩＤ１３２１０は、当該アウトプットのＵＵＩＤを示す。

インプットＵＵＩＤ１３２０７とアウトプットＵＵＩＤ１３２１０は同じ識別システムに属す識別子であり、両者の値が同じであれば、これらが指しているインプットとアウトプットは同じである。例えば、連携サービス「Ａ」のアウトプットＵＵＩＤ１３２１０は連携サービス「Ｂ」のインプットＵＵＩＤ１３０２７と同じである場合は、連携サービス「Ａ」のアウトプットが連携サービス「Ｂ」のインプットになれる。従って、連携サービス「Ａ」と連携サービス「Ｂ」の順次組み合わせが「連携サービス連鎖」である。

有効性１３２１１は、対象サービスが現在連携サービスシステムに取り扱われているかどうかを示す。有効性１３２１１「無効」は、対象サービスの依頼者が対象サービスを依頼することができず、対象サービスの提供者も対象サービスを提供することもできないことを意味する。

バージョン１３２１２は、対象サービスのバージョンを示す。対象サービスに対応した情報１３２０１～１３２１１の少なくとも一部が更新された場合、対象サービスのバージョン１３２１２が一定のルールで変更される。

図６は、標準アクションテーブル１３３の構成例を示す図である。

標準アクションテーブル１３３は、連携サービスの実行において実行される処理の単位であるアクションに関する情報を保持する。標準アクションテーブル１３３は、アクション毎に、エントリを有する。各エントリは、アクションＵＵＩＤ１３３０１と、アクション名１３３０２と、サービス名１３３０３と、サービスＵＵＩＤ１３３０４と、アクション定義１３３０５と、バージョン１３３０６といった情報を記憶する。以下、一つのアクションを例に取る（図６の説明において「対象アクション」）。

アクションＵＵＩＤ１３３０１は、対象アクションのＵＵＩＤを示す。アクション名１３３０２は、対象アクションの名称を示す。当該名称は、対象アクションの内容を人間が理解できる文字列である。

「アクション」というのは、連携サービスを実現するために、連携に関与した依頼者と提供者が連携中で実際に行う処理である。アクション定義１３３０５は、当該処理（対象アクション）の定義を示す。依頼者と提供者が対象アクションを実行する際に当該アクション定義１３３０５に従う。一つの連携サービスの実行のためには、依頼者と提供者が決まった順番通りに指定されたアクションを適切なタイミングに実行する必要があり、この詳細は後述する標準シナリオ定義テーブル１３４に規定されている。

同じアクションは複数の連携サービスに実行されることがあり、所属関係は一対一とは限らない。サービス名１３３０３およびサービスＵＵＩＤ１３３０４は、対象アクションが属する一つ以上の連携サービスの各々の名称およびＵＵＩＤを示す。

アクション定義１３３０５は、提供者および依頼者を管理または開発する人間向けの情報でよく、例えば、対象アクションの詳細を説明する文章や、対象アクションに関わる標準名や、対象アクションにかかわるウェブサイトのＵＲＬなどの、人間が対象アクションの形態や効果に対してコンセンサスをとるために必要な情報である。

バージョン１３３０６は、対象アクションのバージョンを示す。対象アクションに対応した情報１３３０１～１３３０５の少なくとも一部の変更が発生したら、バージョン１３３０６が一定のルールで変更される。

図７は、標準シナリオ定義テーブル１３４の構成例を示す図である。

標準シナリオ定義テーブル１３４は、連携サービス毎に用意されるテーブルであり、連携サービスの実行として行われる一つ以上のアクションとその実行順序とに関する情報を保持する。標準シナリオ定義テーブル１３４は、サービスＵＵＩＤ１３４０１と、バージョン情報１３４０２とを格納する。サービスＵＵＩＤ１３４０１は、本テーブル１３４に対応した連携サービスのＵＵＩＤを示す。バージョン情報１３４０２は、本テーブル１３４のバージョンを示す。本テーブル１３４に任意の箇所に変更が発生したら、バージョン情報１３４０２が一定のルールで変更される。ここで言う変更は、例えば、タイミング１３４０７の変更や、アクション内容の添削や、順番１３４０３の変更などであると考えられる。

また、本テーブル１３４は、本テーブル１３４に対応した連携サービスの実行として行われる一つ以上のアクションの各々についてエントリを有する。各エントリは、アクション順番１３４０３と、アクションＵＵＩＤ１３４０４と、アクション名１３４０５と、実行者１３４０６と、実行タイミング１３４０７と、必須フラグ１３４０８と、バージョン１３４０９といった情報を格納する。以下、一つのアクションを例に取る（図７の説明において「対象アクション」）。

アクションＵＵＩＤ１３４０４とアクション名１３４０５は、対象アクションのＵＵＩＤと名称を示し、標準アクションテーブル１３３に従う。

実行者１３４０６は、対象アクションを実行する主体であり、例えば、依頼者、提供者、または、対象アクションが属するいずれかの連携サービスに関与する全員でよい。タイミング１３４０７は、対象アクションを実行するタイミングを示す、必須フラグ１３４０８は、対象アクションの実行が必須であるかどうかを示す。バージョン１３４０９は、対象アクションの実行前提になる最低バージョン（対象アクションに対応したバージョンの下限値）を示す。

図８は、提供者テーブル１３５の構成例を示す図である。

提供者テーブル１３５は、提供者に関する情報を保持する。提供者が、本テーブル１３５を通して、連携サービスを提供する様々な条件を開示することができる。依頼者が、本テーブル１３５を通して、提供者を見つけることができる。提供者テーブル１３５は、連携サービス毎にエントリを有する。各エントリは、サービス名１３５０１と、サービスＵＵＩＤ１３５０２と、提供者名１３５０３と、提供者ＵＵＩＤ１３５０４と、通信窓口１３５０５と、提供場所１３５０６と、提供時間１３５０７と、対価１３５０８といった情報を記憶する。以下、一つの連携サービスを例に取る（図８の説明において「対象サービス」）。

サービス名１３５０１とサービスＵＵＩＤ１３５０２は、対象サービスの名称とＵＵＩＤを示し、連携サービステーブル１３２に従う。

提供者名１３５０３は、対象サービスの提供者の名称を示す。提供者ＵＵＩＤ１３５０４は、当該提供者のＵＵＩＤ（例えば、提供者の身分を識別または認証するために必要なＩＤ）を示す。通信窓口１３５０５は、対象サービスの依頼の送信先、典型的には、提供者のインターフェース（例えば、対象サービスの実行中に行われる様々な通信（データ通信や、アクションの実施タイミングを制御する通信など）の際の提供者側インターフェース）を示す。

提供場所１３５０６は、対象サービスの提供場所（対象サービスを提供できる場所）を示している。連携サービスの提供場所としては、例えば、あるエリア内、建物内、建物の中の特定階層や部屋、または、ピンポイントのスポット（あるいは、場所の制限なし）などが考えられる。対象サービスに関与するローカルシステム３が提供場所に対する理解が同じであること確保するために、提供者が決まったルール（例えば、ＧＰＳの座標群、建物の住所、室内座標系、あるいは事前の合意）に随って開示することが望ましい。

提供時間１３５０７は、対象サービスを提供できる時間帯を示す。

対価１３５０８は、対象サービスを提供するたびに受け取る対価（例えば報償額）を示す。対価は、対象サービスの提供のインセンティブの一例であり、金銭に限られないでよい。

図９は、提供可能サービステーブル２３１の構成例を示す図である。

提供可能サービステーブル２３１は、本テーブル２３１を格納するローカルシステム３（図９の説明において対象システム３）が提供可能な連携サービスに関する情報を保持している。上述した提供者テーブル１３５は、提供者のリスト相当であることに対して、提供可能サービステーブル２３１は、依頼者から連携サービスの依頼を受けた提供者がこの依頼に対応するかどうかを判断するために使用される。本テーブル２３１は、対象システム３が提供可能な連携サービス毎に、サービス名２３０１と、サービスＵＵＩＤ２３１０２と、開始時間２３１０４と、同時数２３１０８と、対価２３１０１と、バージョン２３１０７と、シナリオ内容２３１０８といった情報を記憶する。以下、一つの連携サービスを例に取る（図９の説明において「対象サービス」）。

サービス名２３１０１は、対象サービスの名称を示しており、サービスＵＵＩＤ２３１０２との対応関係は、連携サービステ－ブル１３２に随う。

提供場所２３１０３は、提供者テーブル１３５における提供場所１３５０６に一致する。

同時数２３１０５は、対象システム３が対象サービスを同時に提供できる数を示す。

対価２３１０６は、対象サービスを提供するたびに受け取る対価（例えば報償額）であり、提供者テーブル１３５の対価１３５０８に一致する。

バージョン２３１０７は、シナリオ内容２３１０８に保存されているシナリオのバージョンを示す。当該シナリオに対応したバージョン情報１３４０２（標準シナリオ定義テーブル１３４内のバージョン情報１３４０２）とバージョン２３１０７が一致していない場合は、後述する更新処理で更新が行われる。

シナリオ内容２３１０８は、標準シナリオ定義テーブル１３４が有する情報１３４０３～１３４０９に対応した情報２３１０８１～２３１０８７に加えて、内部コマンド２３１０８８という情報を含む。内部コマンド２３１０８８は、標準アクションテーブル１３３にリストアップされたアクションを対象システム３内で実行するコマンドを示している。本実施例において、二つ以上のローカルシステム３の内部構造や稼動原理が異なるため、アクションを実行するための命令、条件およびコマンドのうちの少なくとも一つも異なる。内部コマンド２３１０８８の詳細は後述する。

図１０は、利用可能サービステーブル２３２の構成例を示す図である。

利用可能サービステーブル２３２は、本テーブル２３２を格納するローカルシステム３（図１０の説明において対象システム３）が利用可能な連携サービスに関する情報を保持している。本テーブル２３２は、対象システム３が提供可能な連携サービス毎に、サービス名２３２０１と、サービスＵＵＩＤ２３２０２と、対価２３２０３と、バージョン２３２０４と、シナリオ内容２３２０５といった情報を記憶する。以下、一つの連携サービスを例に取る（図１０の説明において「対象サービス」）。

サービス名２３２０１は、対象サービスの名称を示しており、サービスＵＵＩＤ２３２０２との対応関係は、連携サービステ－ブル１３２に従う。

対価２３２０３は、対象サービスを利用するたびに対象サービスの提供者に支払う対価（例えば報償額の最大値）を示す。

バージョン２３２０４は、シナリオ内容２３２０５に保存されているシナリオのバージョンを示す。当該シナリオに対応したバージョン情報１３４０２（標準シナリオ定義テーブル１３４内のバージョン情報１３４０２）とバージョン２３２０４が一致していない場合は、後述する更新処理で更新が行われる。

シナリオ内容２３２０５は、図１０が示すシナリオ内容２３１０８と同様に、標準シナリオ定義テーブル１３４が有する情報１３４０３～１３４０９に対応した情報２３２０５１～２３２０５７に加えて、内部コマンド２３２０５８という情報を含む。内部コマンド２３２０５８については図１０に示した内部コマンド２３１０８８と同様である。

図１１は、提供中サービステーブル２３３の構成例を示す図である。

提供中サービステーブル２３３は、本テーブル２３３を格納するローカルシステム３（図１１の説明において対象システム３）が提供している連携サービスの状態に関する情報を保持している。本テーブル２３３は、対象システム３が提供中の連携サービス毎に、サービス番号２３３０１と、進行状態２３３０２と、サービス名２３３０３と、サービスＵＵＩＤ２３３０４と、利用者名２３３０５と、利用者ＵＵＩＤ２３３０６と、通信窓口２３３０７と、提供開始時刻２３３０８と、提供終了時刻２３３０９といった情報を記憶する。以下、一つの連携サービスを例に取る（図１１の説明において「対象サービス」）。

サービス番号２３３０１は、対象サービスを制御および管理するために使われる臨時番号である（当該番号の使い方については後述する）。

進行状態２３３０２は、対象サービスの進行状態を示す。

サービス名２３３０３は、対象サービスの名称を示し、サービスＵＵＩＤ２３３０４との対応関係は、連携サービステ－ブル１３２に従う。

利用者名２３３０５は、対象サービスの利用者（典型的には、対象サービスを利用するローカルシステム３）の名称を示す。利用者ＵＵＩＤ２３３０６は、当該利用者のＵＵＩＤを示す。

通信窓口２３３０７は、対象サービスの依頼に対する返事の送信先（対象サービスの利用者の窓口としての利用者側インターフェース）を示す。

提供開始時刻２３３０８および提供終了時刻２３３０９は、対象サービスの提供が実際に開始された時刻および当該提供の予定終了時刻を示す。

図１２は、利用中サービステーブル２３４の構成例を示す図である。

利用中サービステーブル２３４は、本テーブル２３４を格納するローカルシステム３（図１１の説明において対象システム３）が利用している連携サービスの状態に関する情報を保持している。本テーブル２３４は、対象システム３が利用中の連携サービス毎に、サービス番号２３４０１と、進行状態２３４０２と、サービス名２３４０３と、サービスＵＵＩＤ２３４０４と、提供者名２３４０５と、提供者ＵＵＩＤ２３４０６と、通信窓口２３４０７と、利用開始時刻２３４０８と、利用終了時刻２３４０９と、次サービス番号２３４１０といった情報を記憶する。

サービス番号２３４０１については、図１１に示したサービス番号２３３０１と同様である。進行状態２３０２は、対象サービスの進行状態を示す。サービス名２３４０３は、対象サービスを示し、サービスＵＵＩＤ２３４０４との対応関係は、連携サービステ－ブル１３２に従う。

提供者名２３４０５は、対象サービスの提供者（典型的には、対象サービスを提供するローカルシステム３）の名称を示す。提供者ＵＵＩＤ２３４０６は、当該提供者のＵＵＩＤを示す。提供者ＵＵＩＤ２３４０６は、前述した利用者ＵＵＩＤ２３３０６と、同じ編成系統に属すものである。例えば、あるローカルシステム３が利用者として連携サービスを利用しているときの利用者ＵＵＩＤを「１２３４５」とすると、このローカルシステム３が提供者として連携サービスを提供するときの提供者ＵＵＩＤも「１２３４５」である。

通信窓口２３４０７は、対象サービスの依頼の送信先（対象サービスの提供者の窓口としての提供者側インターフェース）を示す。

利用開始時刻２３４０８および利用終了時刻２３４０９は、対象サービスの利用が実際に開始された時刻および当該利用の予定終了時刻を示す。

次サービス番号２３４１０は、対象サービスを含んだ複数の連携サービスを連続的に利用する場合（すなわち、対象サービスを含んだ連携サービス連鎖を利用する場合）に有効な情報であり、対象サービスの次に利用する連携サービスに対応するサービス番号２３４０１を値として含む。

本実施例において使用されるメッセージを説明する。使用されるメッセージは例えばアプリケーション層でのメッセージである。以下の説明では、メッセージのペイロードにある内容を述べる。当該内容をデータとして送受信するためのカプセル化は通信手段により異なる。

図１３は、分類更新メッセージＭ１の構成例を示す図である。

分類更新メッセージＭ１は、サービス分類テーブル１３１の更新のためのメッセージである。分類更新メッセージＭ１は、送信元Ｍ１０１と、身分確認Ｍ１０２と、更新内容Ｍ１０３と、メッセージ番号Ｍ１０４とを含む。

送信元Ｍ１０１は、サービス分類テーブル１３１の中身を更新する主体のＩＤ（例えばＵＵＩＤ）を示す。身分確認Ｍ１０２は、このメッセージＭ１の送信元の認証用の情報（例えば送信元Ｍ１０１を基に生成された文字列）である。

更新内容Ｍ１０３は、更新種類Ｍ１０３０１と、分類ＵＵＩＤＭ１０３０２と、下位分類名Ｍ１０３０４と、下位分類ＵＵＩＤＭ１０３０５と、有効性Ｍ１０３０６といった情報を含む。更新種類Ｍ１０３０１は、当該更新が既存サービス分類の変更であるかあるいは新しいサービス分類の追加であるかといった更新種類を示す。更新内容Ｍ１０３にある他の項目の情報Ｍ１０３０２～Ｍ１０３０６の定義は、サービス分類テーブル１３１にある同名の情報１３１０２～１３１０６と同じである。

メッセージ番号Ｍ１０４は、このメッセージＭ１を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図１４は、サービス更新メッセージＭ２の構成例を示す図である。

サービス更新メッセージＭ２は、連携サービステーブル１３２の更新のためのメッセージである。サービス更新メッセージＭ２は、送信元Ｍ２０１と、身分確認Ｍ２０２と、更新内容Ｍ２０３と、メッセージ番号Ｍ２０４とを含む。

送信元Ｍ２０１は、連携サービステーブル１３２の中身を更新する主体のＩＤ（例えばＵＵＩＤ）を示す。身分確認Ｍ２０２は、このメッセージＭ２の送信元の認証用の情報（例えば送信元Ｍ２０１を基に生成された文字列）である。

更新内容Ｍ２０３は、更新種類Ｍ２０３０１と、サービスＵＵＩＤＭ２０３０２と、サービス名Ｍ２０３０３と、分類名Ｍ２０３０４と、分類ＵＵＩＤＭ２０３０５と、インプットＭ２０３０６と、インプットＵＵＩＤＭ２０３０７と、インプット定義Ｍ２０３０８と、サートプットＭ２０３０９と、アウトプットＵＵＩＤＭ２０３１０と、アウトプット定義Ｍ２０３１１と、有効性Ｍ２０３１２とを含む。更新種類Ｍ２０３０１は、当該更新が既存連携サービスの変更であるか、新しい連携サービスの追加であるかといった更新種類を示している。更新内容Ｍ２０３にある他の情報Ｍ２０３０２～Ｍ２０３１２の定義は、連携サービステーブル１３２にある同名の情報１３２０１～１３２１１と同じである。

メッセージ番号Ｍ２０４は、このメッセージＭ２を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図１５は、アクション更新メッセージＭ３の構成例を示す図である。

アクション更新メッセージＭ３は、標準アクションテーブル１３３の更新のためのメッセージである。アクション更新メッセージＭ３は、送信元Ｍ３０１と、身分確認Ｍ３０２と、更新内容Ｍ３０３と、メッセージ番号Ｍ３０４とを含む。

送信元Ｍ３０１は、標準アクションテーブル１３３の中身を更新する主体のＩＤ（例えばＵＵＩＤ）を示す。身分確認Ｍ３０２は、このメッセージＭ３の送信元の認証用の情報（例えば送信元Ｍ３０１を基に生成された文字列）である。

更新内容Ｍ３０３は、更新種類Ｍ３０３０１と、アクションＵＵＩＤＭ３０３０２と、アクション名Ｍ３０３０３と、サービス名Ｍ３０３０４と、サービスＵＵＩＤＭ３０３０５と、アクション定義Ｍ３０３０６とを含む。更新種類Ｍ３０３０１は、当該更新が既存標準アクションの変更であるか新しい標準アクションの追加であるかといった更新種類を示す。更新内容Ｍ３０３にある他の情報Ｍ３０３０２～Ｍ３０３０６の定義は、標準アクションテーブル１３３にある同名の情報１３３０１～１３３０５と同じである。

メッセージ番号Ｍ３０４は、このメッセージＭ３を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図１６は、シナリオ更新メッセージＭ４の構成例を示す図である。

シナリオ更新メッセージＭ４は、標準シナリオ定義テーブル１３４の更新のためのメッセージである。シナリオ更新メッセージＭ４は、送信元Ｍ４０１と、身分確認Ｍ４０２と、更新種類Ｍ４０３と、サービスＵＵＩＤＭ４０４と、更新内容Ｍ４０５と、メッセージ番号Ｍ４０６と、記憶されている。

送信元Ｍ４０１は、標準シナリオ定義テーブル１３４の中身を更新する主体のＩＤ（例えばＵＵＩＤ）を示す。身分確認Ｍ４０２は、このメッセージＭ４の送信元の認証用の情報（例えば送信元Ｍ４０１を基に生成された文字列）である。

更新種類Ｍ４０３は、更新内容Ｍ４０５にある情報は既存のシナリオの変更であるか、新しい標準シナリオ定義テーブル１３４の追加であるかといった更新種類を示している。

更新内容Ｍ４０５は、アクションＵＵＩＤＭ４０５０１と、アクション名Ｍ４０５０２と、実行者Ｍ４０５０３と、タイミングＭ４０５０４と、必須フラグＭ４０５０５とを含む。これらの情報Ｍ４０５０１～Ｍ４０５０５の定義は、標準シナリオ定義テーブル１３４にある同名の情報１３４０４～１３４０８と同じである。

メッセージ番号Ｍ４０６は、このメッセージＭ４を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図１７は、提供者更新メッセージＭ５の構成例を示す図である。

提供者更新メッセージＭ５は、提供者テーブル１３５の更新のためのメッセージである。提供者更新メッセージＭ５は、送信元Ｍ５０１と、身分確認Ｍ５０２と、更新種類Ｍ５０３と、更新内容Ｍ５０４と、メッセージ番号Ｍ５０５とを含む。

送信元Ｍ５０１は、提供者テーブル１３５の中身を更新する主体（つまり提供者）のＩＤ（例えばＵＵＩＤ）を示す。身分確認Ｍ５０２は、このメッセージＭ５の送信元の認証用の情報（例えば送信元Ｍ５０１を基に生成された文字列）である。

更新種類Ｍ５０３は、提供者が提供可能な新しい連携サービスを追加するのか、既存の提供可能な連携サービスを変更するのか、既存の提供可能な連携サービスを削除するのかといった更新種類を示している。

更新内容Ｍ５０４は、サービス名Ｍ５０４０１と、サービスＵＵＩＤＭ５０４０２と、提供者名Ｍ５０４０３と、提供者ＵＵＩＤＭ５０４０４と、通信窓口Ｍ５０４０５と、提供場所Ｍ５０４０６と、提供時間Ｍ５０４０７と、対価Ｍ５０４０８とを含む。これらの情報Ｍ５０４０１～Ｍ５０４０８の定義は、提供者テーブル１３５にある同名の情報１３５０１～１３５０８と同じである。

メッセージ番号Ｍ５０５は、このメッセージＭ５を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図１８は、対応結果通知メッセージＭ６の構成例を示す図である。

対応結果通知メッセージＭ６は、前述した分類更新メッセージＭ１と、サービス更新メッセージＭ２と、アクション更新メッセージＭ３と、シナリオ更新メッセージＭ４といったメッセージ（図１８の説明において「元メッセージ」）に対する返事である。対応結果通知メッセージＭ６は、送信先Ｍ６０１と、対応メッセージ番号Ｍ６０２と、対応結果Ｍ６０３とを含む。

送信先Ｍ６０１は、このメッセージＭ６の送信先、すなわち、元メッセージの送信元のＩＤ（例えばＵＵＩＤ）を示す。対応メッセージ番号Ｍ６０２は、元メッセージのメッセージ番号を示す。対応結果Ｍ６０３は、「更新成功」（図１８の例１を参照）、「権限承認失敗で拒否」（図１８の例２を参照）といったような、元メッセージに応答して行われた処理の結果を示す。

図１９は、バージョン変更周知メッセージＭ７の構成例を示す図である。

バージョン変更周知メッセージＭ７は、サービス分類テーブル１３１、連携サービステーブル１３２、標準アクションテーブル１３３、または標準シナリオ定義テーブル１３４といったテーブル（図１９の説明において「元テーブル」）にあるバージョン情報が更新されたことを周知するためのメッセージである。バージョン変更周知メッセージＭ７は、変更対象Ｍ７０１と、変更箇所Ｍ７０２と、前バージョン番号Ｍ７０３と、新バージョン番号Ｍ７０４とを含む。

変更対象Ｍ７０１は、元テーブルを示す。変更箇所Ｍ７０２は、変更が発生した連携サービスのサービスＵＵＩＤ、またはアクションＵＵＩＤを示す。複数の変更対象がある場合は、複数のサービスＵＵＩＤ、またはアクションＵＵＩＤを示す。前バージョン番号Ｍ７０３は、変更前のときのバージョンを示す。新バージョン番号Ｍ７０４は、変更後のときのバージョンを示す。

図１９によれば、例１は、サービス分類テーブル１３１に関し、全てのサービス分類に何らかの更新があったことを示す。例２は、標準シナリオ定義テーブル１３４に関し、一つの連携サービスの追加があったことを示す。例３は、連携サービステーブル１３２に関し、一つの連携サービスの削除があったことを示す。例４は、標準アクションテーブル１３３に関し、二つのアクションに何らかの更新があったことを示す。

図２０は、調査依頼メッセージＭ８の構成例を示す図である。

調査依頼メッセージＭ８は、連携サービスを利用したいローカルシステム３が希望の連携サービスを提供する提供者を探すために仲介プログラム１４１に送信するメッセージである。調査依頼メッセージＭ８は、送信元Ｍ８０１と、身分確認Ｍ８０２と、サービス名Ｍ８０３と、サービスＵＵＩＤＭ８０４と、場所条件Ｍ８０５と、時間条件Ｍ８０６と、対価Ｍ８０７と、メッセージ番号Ｍ８０８とを含む。

送信元Ｍ８０１は、このメッセージＭ８を出した依頼者の依頼者名（またはＵＵＩＤ）を示す。身分確認Ｍ８０２は、このメッセージＭ８の送信元の認証用の情報である。

サービス名Ｍ８０３およびサービスＵＵＩＤＭ８０４は、利用したい連携サービスの名称およびＵＵＩＤを示す。

場所条件Ｍ８０５、時間条件Ｍ８０６、および対価Ｍ８０７は、連携サービスを提供する場所に関する条件と、時間に関する条件と、対価に関する条件（例えば支払える報償の上限）とを示す。

メッセージ番号Ｍ８０８は、このメッセージＭ８を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図２１は、設計依頼メッセージＭ９の構成例を示す図である。

設計依頼メッセージＭ９は、サービス分類のみ（決まった連携サービスではなく）を希望した利用者の利用申請プログラム２４３から送信されるメッセージであり、連携サービス連鎖を設計してその連携サービス連鎖を提供できる連携サービスの提供者の集合を探すために仲介プログラム１４１に送信されるメッセージである。設計依頼メッセージＭ９は、送信元Ｍ９０１と、分類名Ｍ９０２と、分類ＵＵＩＤＭ９０３と、インプットＭ９０４と、インプットＵＵＩＤＭ９０５と、場所条件Ｍ９０６と、時間条件Ｍ９０７と、対価Ｍ９０８と、メッセージ番号Ｍ９０６とを含む。

送信元Ｍ９０１は、このメッセージＭ９を出した依頼者の依頼者名（またはＵＵＩＤ）を示す。

分類名Ｍ９０２および分類ＵＵＩＤＭ９０３は、希望した連携サービスの分類名およびＵＵＩＤを示す。

インプットＭ９０４とインプットＵＵＩＤＭ９０５は、依頼者が提供できるインプットとそれのＵＵＩＤとを示す。

場所条件Ｍ９０６、時間条件Ｍ９０７、および対価Ｍ９０８は、連携サービス連鎖が行われる場所に関する要件と、時間に関する条件と、対価に関する条件（例えば支払える報償の上限）とを示す。

メッセージ番号Ｍ９０６は、このメッセージＭ９を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図２２は、調査依頼返答メッセージＭ１０の構成例を示す図である。

調査依頼返答メッセージＭ１０は、仲介プログラム１４１が調査依頼メッセージＭ８に対して依頼者へ出した返事である。調査依頼返答メッセージＭ１０は、送信先Ｍ１００１と、対応メッセージ番号Ｍ１００２と、検索結果Ｍ１００３とを含む。

送信先Ｍ１００１が、このメッセージＭ１０の送信先（調査依頼メッセージＭ８の送信元）の依頼者名（またはＵＵＩＤ）を示す。対応メッセージ番号Ｍ１００２は、調査依頼メッセージＭ８のメッセージ番号を示す。

検索結果Ｍ１００３は、提供者名Ｍ１００３０１と、提供者ＵＵＩＤＭ１００３０２と、通信窓口Ｍ１００３０３と、対価Ｍ１００３０４とを含む（図２２の例１を参照）。上記提供者名Ｍ１００３０１および提供者ＵＵＩＤＭ１００３０２は、仲介プログラム１４１が後述する処理で、調査依頼メッセージＭ８に記載された条件に対して見つけた提供者提供者候補名およびそれの提供者ＵＵＩＤを示す。通信窓口Ｍ１００３０３は、上記提供者候補が後述するサービス依頼メッセージＭ１２を受信する窓口（提供者側インターフェース）を示す。

なお、図２２の例２が示すように、検索結果として一つも候補が見つからなかった場合、検索結果Ｍ１００３は「ＮＵＬＬ」となる。

図２３は、設計依頼返答メッセージＭ１１の構成例を示す図である。

設計依頼返答メッセージＭ１１は、仲介プログラム１４１が設計依頼メッセージＭ９に対して依頼者へ出した返事である。設計依頼返答メッセージＭ１１は、送信先Ｍ１１０１と、対応メッセージ番号Ｍ１１０２と、検索結果Ｍ１１０３とを含む。

送信先Ｍ１１０１が、このメッセージＭ１１の送信先（設計依頼メッセージＭ９の送信元）の依頼者名（またはＵＵＩＤ）を示す。対応メッセージ番号Ｍ１１０２は、設計依頼メッセージＭ９のメッセージ番号を示す。

検索結果Ｍ１１０３は、順番Ｍ１１０３０１と、サービス名Ｍ１１０３０２と、分類名Ｍ１１０３０３と、インプットＭ１１０３０４と、インプットＵＵＩＤＭ１１０３０５と、インプット定義Ｍ１１０３０６と、アウトプットＭ１１０３０７と、アウトプットＵＵＩＤＭ１１０３０８と、アウトプット定義Ｍ１１０３０９と、提供者名Ｍ１１０３１０と、提供者ＵＵＩＤＭ１１０３１１と、通信窓口Ｍ１１０３１２と、対価Ｍ１１０３１３とを含む（図２３の例１を参照）。順番Ｍ１１０３０１は、連携サービス連鎖が含む連携サービスが提供される順番を示す。情報Ｍ１１０３０２～Ｍ１１０３０９の定義は、連携サービステーブル１３２にある同名の情報１３２０２、１３２０３および１３２０５～１３２１０と同じである。情報Ｍ１１０３１０～Ｍ１１０３１３の定義は、提供者テーブル１３５にある同名の情報１３５０３～１３５０５および１３５０８と同じである。

なお、設計依頼返答メッセージＭ１１は、連携サービス連鎖を構成する各連携サービスについて、当該連携サービスの利用（実行）において行われる一つ以上のアクションの各々に関する情報（例えば標準シナリオ定義テーブル１３４相当の情報）を含んでもよい。

図２４は、サービス依頼メッセージＭ１２の構成例を示す図である。

サービス依頼メッセージＭ１２は、連携サービスを希望した利用者の利用申請プログラム２４３から提供者候補の依頼受付プログラム２４２に送信されるメッセージであって、連携可否に関する問い合わせとしてのメッセージである。サービス依頼メッセージＭ１２は、送信元Ｍ１２０１と、身分確認Ｍ１２０２と、サービス名Ｍ１２０３と、サービスＵＵＩＤＭ１２０４と、場所条件Ｍ１２０５と、開始時刻範囲Ｍ１２０６と、終了時刻範囲Ｍ１２０７と、対価Ｍ１２０８と、メッセージ番号Ｍ１２０９と、通信窓口Ｍ１２１０とを含む。

情報Ｍ１２０１～Ｍ１２０５およびＭ１２０８の定義は、調査依頼メッセージＭ８における同名の情報Ｍ８０１～Ｍ８０５およびＭ８０７と同じである。

開始時刻範囲Ｍ１２０６と終了時刻範囲Ｍ１２０７は、連携サービスの利用開始時刻および利用終了時刻の各々の範囲を示す。

メッセージ番号Ｍ１２０９は、このメッセージＭ１２を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

通信窓口Ｍ１２１０は、上記提供者候補が後述するサービス依頼返答メッセージＭ１３を送信する送信先の窓口を示す。

図２５は、サービス依頼返答メッセージＭ１３の構成例を示す図である。

サービス依頼返答メッセージＭ１３は、提供者候補の依頼受付プログラム２４２がサービス依頼メッセージＭ１２に対して依頼者へ出して返事である。サービス依頼返答メッセージＭ１３は、送信元Ｍ１３０１と、対応メッセージ番号Ｍ１３０２と、返答内容Ｍ１３０３とを含む。

送信元Ｍ１３０１が、本メッセージＭ１３を送信する提供者の名称（またはＵＵＩＤ）を示す。対応メッセージ番号Ｍ１３０２は、サービス依頼返答メッセージＭ１３のメッセージ番号を示す。

返答内容Ｍ１３０３は、回答種類Ｍ１３０３０１と、利用開始時刻Ｍ１３０３０２と、利用終了時刻Ｍ１３０３０３とを含む。回答種類Ｍ１３０３０１は、サービス依頼メッセージＭ１２に対する回答の種類（例えば「承諾」または「拒否」）を示す。利用開始時刻Ｍ１３０３０２および利用終了時刻Ｍ１３０３０３は、提供者候補の依頼受付プログラム２４２が定めた連携サービスの開始時刻および終了予定時刻を示す。

図２６は、アクション実行状態通知メッセージＭ１４の構成例を示す図である。

アクション実行状態通知メッセージＭ１４は、連携サービスの実行中における該当アクションを実行し始めること、または終了したことを連携先となる利用者または提供者に通知するために使われるメッセージである。アクション実行状態通知メッセージＭ１４は、
送信元Ｍ１４０１と、サービス名Ｍ１４０２と、サービスＵＵＩＤＭ１４０３と、アクション順番Ｍ１４０４と、アクションＵＵＩＤＭ１４０５と、実行状態Ｍ１４０６と、メッセージ番号Ｍ１４０７とを含む。

送信元Ｍ１４０１は、このメッセージＭ１４を送る利用者名または提供者名を示す。

サービス名Ｍ１４０２とサービスＵＵＩＤＭ１４０３は、本メッセージＭ１４の対象であるアクションが属する連携サービス、すなわち、現在実行している連携サービスのサービス名およびそのサービスＵＵＩＤを示す。

アクションの順番Ｍ１４０４およびアクションＵＵＩＤＭ１４０５は、サービスＵＵＩＤＭ１４０３が指した標準シナリオ定義テーブル１３４にある同名の情報１３４０３および１３４０４に対応している。実行状態Ｍ１４０６は、当該アクションの実行を開始したかまたは終了したかといった状態を示す。

メッセージ番号Ｍ１４０７は、このメッセージＭ１４を識別するための番号であり、メッセージ送信前に一定のルールで生成された番号である。

図２７は、終了通知返答メッセージＭ１５の構成例を示す図である。

終了通知返答メッセージＭ１５は、アクション実行状態通知メッセージＭ１４に対する返事である。終了通知返答メッセージＭ１５は、送信元Ｍ１５０１と、対応メッセージ番号Ｍ１５０２と、受信確認Ｍ１５０３とを含む。

送信先Ｍ１５０１が、このメッセージＭ１５の送信先（アクション実行状態通知メッセージＭ１４の送信元）の名称（またはＵＵＩＤ）を示す。対応メッセージ番号Ｍ１５０２は、アクション実行状態通知メッセージＭ１４のメッセージ番号を示す。受信確認Ｍ１５０３は、アクション実行状態通知メッセージＭ１４を受信したことを示す。

以下、本実施例で行われる処理の一例を説明する。

図２８は、管理プログラム１４２が行う処理の一例を示すフローチャートである。

管理プログラム１４２は、起動したら、Ｓ１４２０１で、分類更新メッセージＭ１、サービス更新メッセージＭ２、アクション更新メッセージＭ３、シナリオ更新メッセージＭ４、または、提供者更新メッセージＭ５、の受信を待機する。上記メッセージのいずれかを受信したら（Ｓ１４２０２：Ｙｅｓ）、処理がＳ１４２０３に移る。

Ｓ１４２０３で、管理プログラム１４２は、上記受信したメッセージ（図２８の説明において「受信メッセージ」）に含まれた身分確認情報を確認し、当該受信メッセージが対応するテーブルを更新することの権限を当該受信メッセージの送信元が持っているかどうかを確認する。具体的には、例えば、管理プログラム１４２は、受信メッセージに含まれた身分確認情報と、更新対象のテーブル内の該当情報（例えば提供者ＵＵＩＤ）を基に生成される身分確認情報とが一致するか否かを判断する。

確認の結果が不通過である場合は（Ｓ１４２０４：Ｎｏ）、Ｓ１４２０８で、管理プログラム１４２は、当該結果を記述した対応結果通知メッセージＭ６を生成して受信メッセージの送信元に送信する。

一方、確認の結果が通過である場合は（Ｓ１４２０４：Ｙｅｓ）、Ｓ１４２０５で、管理プログラム１４２は、上記受信メッセージが提供者更新メッセージＭ５であるかどうかを判断する。

受信メッセージが提供者更新メッセージＭ５の場合は（Ｓ１４２０５：Ｙｅｓ）、Ｓ１４２０６で、管理プログラム１４２は、提供者更新メッセージＭ５内の更新種類Ｍ５０３に応じて当該メッセージＭ５内の更新内容Ｍ５０４を提供者テーブル１３５の相応箇所に反映するといった更新を行う。当該更新が終了したら、Ｓ１４２０７で、管理プログラム１４２は、今回の処理結果を記述した対応結果通知メッセージＭ６を生成して受信メッセージの送信元に返信する。

受信メッセージが提供者更新メッセージＭ５ではない場合は（Ｓ１４２０５：Ｎｏ）、Ｓ１４２０９で、管理プログラム１４２は、上記受信メッセージおよび当該受信メッセージが示す更新内容に応じて、相応の更新を行う。Ｓ１４２０９の具体例は、例えば下記ケース１～ケース４の通りである。

（ケース１）受信メッセージが分類更新メッセージＭ１であった場合：図４および図１３を用いて一例を説明する。先ず、管理プログラム１４２は、分類更新メッセージＭ１の更新内容Ｍ１０３の各行を読み込む。対象の行の更新種類Ｍ１０３０１が「変更」と記載されている場合は、管理プログラム１４２は、その行で記載された分類ＵＵＩＤ Ｍ１０３０２および下位分類ＵＵＩＤ Ｍ１０３０５を用いて、サービス分類テーブル１３１に保存された同じ行を検索する。当該行を見つけたら、管理プログラム１４２は、その行の各箇所の内容を更新する。ここでは、管理プログラム１４２は、更新内容Ｍ１０３の１行目の情報に応じて、「映像再生」の下位分類に「Ｌｏｃａｌ再生」が存在することの有効性を「有効」から「無効」に変更する。一方、対象の行の更新種類Ｍ１０３０１が「追加」と記載されている場合は、管理プログラム１４２は、その行の内容を、サービス分類テーブル１３１に追加する。更新内容Ｍ１０３の２行目から４行目によれば、管理プログラム１４２は、マルチメディア再生の下位分類にスライド再生の分類を追加し、スライド再生の下位分類に「Ｓｔｒｅａｍｉｎｇ再生」の分類を追加し、「Ｓｔｒｅａｍｉｎｇ再生」を最下位分類とする。最後に、管理プログラム１４２は、サービス分類テーブル１３１のバージョン情報１０１０１を一定のルールで更新する。

（ケース２）受信メッセージがサービス更新メッセージＭ２であった場合：図５および図１４を用いて一例を説明する。先ず、管理プログラム１４２は、サービス更新メッセージＭ２の更新内容Ｍ２０３の各行を読み込む。対象の行の更新種類Ｍ２０３０１が「変更」と記載されている場合は、管理プログラム１４２は、その行で記載されたサービスＵＵＩＤ Ｍ２０３０２を用いて、連携サービステーブル１３２に保存された同じ行を検索する。当該行を見つけたら、管理プログラム１４２は、その行の各箇所の内容を更新し、バージョン１３２１２を一定のルールで追記する。一方、対象の行の更新種類Ｍ２０３０１が「追加」と記載されている場合は、管理プログラム１４２は、その行の内容を、連携サービステーブル１３２に追加し、バージョン１３２１２を一定のルールで追記する。図５が示した例の更新内容の１行目と２行目の情報に応じて、ＤＶＤ再生およびＵＳＢ再生のサービスの有効性を「有効」から「無効」に変更する。管理プログラム１４２は、更新内容Ｍ２０３の３行目の情報に応じて、「Ｓｔｒｅａｍｉｎｇ再生」（分類のＵＵＩＤが「１３５１」）という分類に「Ｍ社製品スライド再生」という新しい連携サービスを追加する。

（ケース３）受信メッセージがアクション更新メッセージＭ３であった場合：図６および図１５を用いて一例を説明する。先ず、管理プログラム１４２は、アクション更新メッセージＭ３の更新内容Ｍ３０３の各行を読み込む。対象の行の更新種類Ｍ３０３０１が「更新」と記載されている場合は、管理プログラム１４２は、その行で記載されたアクションＵＵＩＤ Ｍ３０３０２を用いて、標準アクションテーブル１３３に保存された同じ行を検索する。当該行を見つけたら、管理プログラム１４２は、その行の各箇所の内容を更新し、バージョン１３３０６を一定のルールで追記する。一方、対象の行の更新種類Ｍ３０３０１が「追加」と記載されている場合は、管理プログラム１４２は、その行の内容を、連携サービステーブル１３２に追加し、バージョン１３３０６を一定のルールで追記する。

（ケース４）受信メッセージがシナリオ更新メッセージＭ４であった場合：図７および図１６を用いて一例を説明する。先ず、管理プログラム１４２は、シナリオ更新メッセージＭ４の更新種類Ｍ４０３が「追加」である場合は、サービスＵＵＩＤ Ｍ４０４および更新内容Ｍ４０５を用いて、新しい標準シナリオ定義テーブル１３４を作成する。一方、更新種類４０３が「変更」である場合は、管理プログラム１４２は、サービスＵＵＩＤ Ｍ４０４および更新内容Ｍ４０５を用いて、該当の標準シナリオ定義テーブル１３４を上書きする。最後に、管理プログラム１４２は、標準シナリオ定義テーブル１３４のバージョン情報１３４０２を一定のルールで更新する。

Ｓ１４２０９での更新が終了したら、Ｓ１４２１０で、管理プログラム１４２は、処理の結果を記述した対応結果通知メッセージＭ６を受信メッセージの送信元に返信する。そして、Ｓ１４２１１で、管理プログラム１４２は、テーブル更新を行ったことを記述したバージョン変更周知メッセージＭ７をブロードキャストする。変更（更新）のあったテーブルがサービス分類テーブル１３１である場合は、バージョン変更周知メッセージＭ７の変更箇所Ｍ７０２は「全域」である（サービス分類テーブル１３１はサービス分類を記録する複雑なテーブルであるため、変更が発生したら、テーブル全域が変更されたとみなされる）。一方、変更のあったテーブルが標準シナリオ定義テーブル１３４、連携サービステーブル１３２もしくは標準アクションテーブル１３３の場合は、バージョン変更周知メッセージＭ７の変更対象Ｍ７０１は、当該変更のあったテーブルの名称であり、変更箇所Ｍ７０２は、変更があるサービスもしくはアクションのＵＵＩＤである。なお、変更のあるサービスまたはアクションが複数存在する場合は、変更箇所Ｍ７０２、前バージョン番号Ｍ７０３、および新バージョン番号Ｍ７０４の各々に、同じ順番で相応する情報が記入されればよい。

Ｓ１４２０７またはＳ１４２１１での処理が終わったら、Ｓ１４２１２で、管理プログラム１４２が、外部からの終了コマンドを受信したか否かを判断する。判断結果が肯定の場合は（Ｓ１４２１２：Ｙｅｓ）、管理プログラム１４２が終了する。一方、判断結果が否定の場合は（Ｓ１４２１２：Ｎｏ）、処理がＳ１４２０１に戻る。

図２９は、仲介プログラム１４１が行う処理の一例を示すフローチャートである。

仲介プログラム１４１は、起動したら、Ｓ１４１０１で、調査依頼メッセージＭ８、または、設計依頼メッセージＭ９の受信を待機する。上記メッセージのいずれかを受信したら（Ｓ１４１０２：Ｙｅｓ）、Ｓ１４１０３で、仲介プログラム１４１は、上記受信したメッセージ（図２９の説明において「受信メッセージ」）に含まれた身分確認情報を基に、図２８のＳ１４２０３と同様に権限を確認する。

確認の結果が不通過である場合は（Ｓ１４１０４：Ｎｏ）、Ｓ１４１０８で、仲介プログラム１４１は、当該結果を記述した対応結果通知メッセージＭ６を生成して受信メッセージの送信元に送信する。

一方、確認の結果が通過である場合は（Ｓ１４１０４：Ｙｅｓ）、Ｓ１４１０５で、仲介プログラム１４１は、受信メッセージが調査依頼メッセージＭ８であるかどうかを判断する。

受信メッセージが調査依頼メッセージＭ８である場合は（Ｓ１４１０５：Ｎｏ）、Ｓ１４１０９で、仲介プログラム１４１は、調査依頼メッセージＭ８の場所条件Ｍ８０５、時間条件Ｍ８０６および対価Ｍ８０７が示す条件を満たした提供者を提供者テーブル１３５から検索する。この検索処理の一例を、図２０を用いて説明する。受信メッセージは、送信元「Ｈ社ロボット管理システム」が連携サービス「エレベータ乗用」を利用するために仲介プログラム１４１に送信されたメッセージであって、当該連携サービスを利用する場所条件Ｍ８０５、時間条件Ｍ８０６，および対価Ｍ８０７を含んだ調査依頼メッセージＭ８である。図８の例によれば、連携サービス「エレベータ乗用」の提供者として「Ａ社ビルシステム」および「Ｆ社昇降機管理システム」があるが、「Ｈ社ロボット管理システム」が指定した提供場所は「Ｂｕｉｌｄｉｎｇ＿Ａ」であるので、提供時間、対価を含めて全条件に満たした提供者は「Ａ社ビルシステム」のみである。そこで、Ｓ１４１１０で、仲介プログラム１４１は、この検索結果を記述した調査依頼返答メッセージＭ１０を生成して受信メッセージの送信元（依頼元）へ返信する。

受信メッセージが設計依頼メッセージＭ９である場合は（Ｓ１４１０５：Ｙｅｓ）、Ｓ１４１０６で、連鎖設計処理が行われる。つまり、可能な連携サービス連鎖が設計される。次に、Ｓ１４１０７で、仲介プログラム１４１は、設計の結果を記述した設計依頼返答メッセージＭ１１（連鎖設計処理で生成されたメッセージ）を受信メッセージの送信元（依頼元）に返送する。

Ｓ１４１０７またはＳ１４１１０での処理が終わったら、Ｓ１４１１１で、終了か否かが判断される。外部から終了コマンドを受信した等の理由により終了の場合は（Ｓ１４１１１：Ｙｅｓ）、仲介プログラム１４１が終了する。一方、終了ではない場合は（Ｓ１４１１１：Ｎｏ）、処理がＳ１４１０１に戻る。

図３０は、連鎖設計処理の一例を示すフローチャートである。

Ｓ１４１０６＿０１で、仲介プログラム１４１は、設計依頼メッセージＭ９内の場所条件Ｍ９０６、時間条件Ｍ９０７、対価Ｍ９０８および分類ＵＵＩＤＭ９０３に該当する候補を提供者テーブル１３５から検索する。図２１の例を用いて、これからの処理の一例を説明すると、次の通りである。すなわち、送信元９０１が「Ｈ社ロボット管理システム」であり、分類名Ｍ９０２は「映像再生」であり、インプットＭ９０４は「検索文」である。そして、このメッセージＭ９によると、場所条件Ｍ９０６は「Ｂｕｉｌｄｉｎｇ＿Ａ、Ｒｏｏｍ３０１」であり、時間条件Ｍ９０７は「２０１８/０９/１２の９：００から２０１８/０９/１２の１０：００まで」であり、対価Ｍ９０８は「５０」である。まず、仲介プログラム１４１は、サービス分類テーブル１３１から、「映像再生」（分類ＵＵＩＤ１３１０２＝１３４）というサービス分類を検索する、図４の例によれば、「映像再生」というサービス分類のなかに、「Ｓｔｒｅａｍｉｎｇ再生」（分類ＵＵＩＤ１３１０２＝１３４５）および「Ｌｏｃａｌ再生」（分類ＵＵＩＤ１３１０２＝１３４６）という下位分類がある。そして、仲介プログラム１４１は、連携サービステーブル１３２を参照して、「Ｓｔｒｅａｍｉｎｇ再生」および「Ｌｏｃａｌ再生」に所属する連携サービスが「ＨＴＴＰ Ｂｒｏｗｓｅｒ」（サービスＵＵＩＤ１３２０１＝Ｓ１３４５＿１）や、「ＤＶＤ再生」（サービスＵＵＩＤ１３２０１＝Ｓ１３４６＿２）や、「ＵＳＢ再生」（サービスＵＵＩＤ１３２０１＝Ｓ１３４６＿５）などのサービスがあることが分かる。仲介プログラム１４１は、提供者テーブル１３５から、場所条件Ｍ９０６である「Ｂｕｉｌｄｉｎｇ＿Ａ、Ｒｏｏｍ３０１」、時間条件Ｍ９０７である「２０１８/０９/１２の９：００から２０１８/０９/１２の１０：００まで」、および対価Ｍ９０８である「５０」という条件を満たす連携サービス「ＨＴＴＰ Ｂｒｏｗｓｅｒ」、「ＤＶＤ再生」、または「ＵＳＢ再生」を提供する提供者を検索する。検索の結果、「ＨＴＴＰ Ｂｒｏｗｓｅｒ」を提供する提供者「Ｓ社」が存在することが分かる。なお、条件として、場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８のうちの一部の条件は無くてもよい。また、場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８の各々について、条件を満たすとは、次の通りである。
・場所条件Ｍ９０６が場所を、提供場所１３５０６が示す場所が含むこと（これは、それらの場所が一致することを含む）。
・時間条件Ｍ９０７が示す時間を、提供時間１３５０７が示す時間が含むこと（これは、それらの時間が一致することを含む）。
・対価Ｍ９０８が示す対価よりも、対価１３５０８が示す対価の方が高いこと（これは、それらの対価が一致することを含む）。

続いて、Ｓ１４１０６＿０２で、仲介プログラム１４１は、これまでの検索結果で候補がいるかを判断する。

もし、「映像再生」というサービス分類に所属する連携サービスを提供し場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８が示す条件を満たした提供者がなければ（Ｓ１４１０６＿０２：Ｎｏ）、Ｓ１４１０６＿０９で、仲介プログラム１４１は、当該結果を記述した設計依頼返答メッセージＭ１１を生成することで、処理を終了する。

一方、提供者候補がいれば（Ｓ１４１０６＿０２：Ｙｅｓ）、Ｓ１４１０６＿０３で、仲介プログラム１４１は、各候補のインプット１３２０５と、設計依頼メッセージＭ９内のインプットＭ９０４とを比較する。ここでの比較処理について、これまで使っている例を用いて説明すると、次の通りである。連携サービステーブル１３２で「ＨＴＴＰ Ｂｏｒｗｓｅｒ」という連携サービスに対して、インプット１３２０５が「ＵＲＬ」（インプットＵＵＩＤ１３２０７＝７１２３）であることが分かる。一方、設計依頼メッセージＭ９内のインプットＭ９０４が「検索文」（インプットＵＵＩＤ１３２０７＝１２）である。比較の結果、「ＨＴＴＰ Ｂｏｒｗｓｅｒ」に必要なインプット１３２０５が設計依頼メッセージＭ９内のインプットＭ９０４と一致していない。仲介プログラム１４１は、このような比較をすべての候補について行う。

一致したサービス候補（連携サービスの候補）が存在しない場合は（Ｓ１４１０６＿０４：Ｙｅｓ）、Ｓ１４１０６＿０５で、仲介プログラム１４１は、連携サービステーブル１３２および提供者テーブル１３５を用いて、各不一致サービス候補（インプット１３２０５がインプットＭ９０４と一致しないサービス候補）について、当該不一致サービス候補のインプット１３２０５になれるアウトプット１３２０８を提供する（サービス候補のインプット１３２０５をアウトプット１３２０８として提供できる）連携サービスの提供者を検索する。具体的には、先ず、仲介プログラム１４１は、連携サービステーブル１３２から「ＵＲＬ」をアウトプット１３２０８とする連携サービスを検索する。図５の例によれば、「ＵＲＬ」をアウトプット１３２０８とする連記サービスは「ウェブ動画検索」である。実際の運用では、不一致サービス候補のインプット１３２０５になれるアウトプット１３２０８を提供してくれる連携サービスは複数存在すると考えられる。そして、仲介プログラム１４１は、提供者テーブル１３５を用いて、「ウェブ動画検索」を提供する提供者を検索する。図８の例では、「ウェブ動画検索」を提供する提供者として「Ｇ社」が存在することがわかる。

続いて、Ｓ１４１０６＿０６で、仲介プログラム１４１は、これまでのステップで検索した結果となった一つ以上のサービス連鎖の各々について、当該サービス連鎖にかかわる提供者の提供場所１３５０６、提供時間１３５０７および対価１３５０８と、設計依頼メッセージＭ９内の場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８とを比較し、当該一つ以上のサービス連鎖から、場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８が示す条件を満たしたサービス連鎖をリストアップする。例えば、図８の例によれば、「ウェブ動画検索」の提供者「Ｇ社」の提供場所１３５０６が「制限なし」で、提供時間１３５０７が「０AM－１２PM」で、対価１３５０８が「0／回」であり、「ＨＴＴＰ Ｂｒｏｗｓｅｒ」の提供者「Ｓ社」の各要件に矛盾がない。つまり、「ウェブ動画検索」の提供場所や提供時間は、「ＨＴＴＰ Ｂｒｏｗｓｅｒ」の提供場所および提供時間を含む。そして、両社の対価１３５０８の合計は４０であるため、設計依頼メッセージＭ９内の対価Ｍ９０８よりも小さい。従って、「ウェブ動画検索」と「HTTPブラウザ」との組み合わせは連携サービス連鎖の候補として、リストアップされる。続いて、Ｓ１４１０６＿０７で、仲介プログラム１４１は、前ステップでできたリストに候補となった連携サービス連鎖があるか否かを確認する。このリストに候補となった連携サービス連鎖がない場合は（Ｓ１４１０６＿０７：Ｎｏ）、連携サービス連鎖の設計の結果を失敗とし、処理がＳ１４１０６＿０９に移る。一方、リストに連携サービス連鎖の候補がある場合は（Ｓ１４１０６＿０７：Ｙｅｓ）、処理がＳ１４１０６＿０８に進む。実際の運用では、連携サービス連鎖の候補が複数存在する場合も考えられる。

Ｓ１４１０６＿０８で、仲介プログラム１４１は、最新の結果を一時保存する。具体的には、仲介プログラム１４１は、前のステップでリストアップされた連携サービス連鎖の候補に新しく追加された連携サービスを新たにサービス候補とする。これまでの例で言えば、この処理は次の通りである。すなわち、これまでできた連携サービス連鎖は「ウェブ動画検索」と「ＨＴＴＰ Ｂｒｏｗｓｅｒ」との組み合わせであり、「ウェブ動画検索」は、新しく連鎖に入れられた連携サービスであり、サービス候補とされる。Ｓ１４１０６＿０８が完了したら、処理がＳ１４１０６＿０３に戻る。つまり、再度、各サービス候補のインプット１３２０５と、設計依頼メッセージＭ９内のインプットＭ９０４とが比較される。一致がない場合は、処理が再びＳ１４１０６＿０５移る。これまでの例によれば、「ウェブ動画検索」はサービス候補である。図５に例示の連携サービステーブル１３２によると、「ウェブ動画検索」のインプット１３２０５が「検索文」（インプットＵＵＩＤ＝１３２０７）であり、設計依頼メッセージＭ９内のインプットＭ９０４「検索文」と一致している。従って、連携サービスの連鎖ができたので、処理がＳ１４１０６＿０９に移る。

つまり、連携設計処理によれば、仲介プログラム１４１は、設計依頼メッセージＭ９が示す条件（場所条件Ｍ９０６、時間条件Ｍ９０７および対価Ｍ９０８が示す条件）を満たすことを維持する範囲で、一致サービス候補（設計依頼メッセージＭ９内のインプットＭ９０４と一致するインプット１３２０５に対応したサービス候補）が見つかるまで、不一致サービス候補のインプット１３２０５になれるアウトプット１３２０８を提供する連携サービスを探し、見つかった連携サービスをサービス連鎖候補に加えていく。

図３１は、利用申請プログラム２４３が行う処理の一例を示すフローチャートである。

利用申請プログラム２４３は、起動したら、Ｓ２４４０１で、システム内部からの連携サービスの利用指令の受信を待機する。「システム内部」は、人間でもよいし、装置でもよいし、プログラムでもよい。利用指令の送り条件、送受信方法、フォーマットおよび内容は、システム内部の動作メカニズムに依存する。たとえば、人間がサービスロボット（ローカル装置２の一例）に対して「猫の動画が見たい」という話をしたという時、ロボットシステム（当該人間及び当該サービスロボットを含むローカルシステム３）の内部が下記のように処理を行うことが考えられる。

一例として、「動画が見たい」というリクエストに対して、何で動画を見るのか指定されていない。このため、サービスロボットが、この話を音声処理、語意分析などの処理を行った結果、この話の意味を「「猫」という「検索文」を用いて、「映像再生」というサービス分類にあるサービスを提供しなさい」と理解できる。そして、当該サービスロボットが、「映像再生」というサービス分類にある連携サービスは自分自身で実現できないと判断した場合、利用可能サービステーブル２３２を調べる。その結果、そのような連携サービスで利用できると分かった場合、当該サービスロボットにおいて、所定の機能（例えば、人間との対話を処理するプログラム）は、利用申請プログラム２４３に、「「検索文」を用いて「映像再生」というサービス分類にある連携サービスの利用を申請しなさい」という利用指令を送信する。

もう一つの例として、人間がサービスロボットに対して「搬送ロボットでこの荷物をルーム３０１に運んでくれ」と話した時、当該サービスロボットは、その話の意味を「「荷物」を用いて、「短距離荷物運搬」というサービスを提供しなさい」と理解できる。そして、当該サービスロボットが、「短距離荷物運搬」という連携サービスは自分自身で実現できないと判断した場合、当該サービスロボットにおいて、所定の機能が、利用申請プログラム２４３に、「「荷物」を用いて「短距離荷物運搬」という連携サービスの利用を申請しなさい」という利用指令を送信する。

利用指令を受信したら、Ｓ２４３０２で、利用申請プログラム２４３は、当該利用指令を解読して、当該利用指令に連携サービスが指定されているか否かを判断する。また、当該利用指令を解読することで、インプットが特定される。

利用指令に連携サービスが指定されている場合は（Ｓ２４３０２：Ｙｅｓ）、利用申請プログラム２４３は、Ｓ２４３０３で、調査依頼メッセージＭ８を生成して仲介プログラム１４１に送信する。Ｓ２４３０４で、利用申請プログラム２４３は、当該調査依頼メッセージＭ８に応答して仲介プログラム１４１から調査依頼返答メッセージＭ１０を受信する。Ｓ２４３０５で、利用申請プログラム２４３は、受信したメッセージＭ１０で提供者の情報があるかどうかを確認する。

提供者の情報がなければ（Ｓ２４３０５：Ｎｏ）、Ｓ２４３０９で、利用申請プログラム２４３は、連携サービステーブル１３２およびサービス分類テーブル１３１を用いて、利用指令で指定された連携サービスの所属するサービス分類を確認する。なお、連携サービステーブル１３２にある分類名１３２０３及び分類ＵＵＩＤ１３２０４は、当該連携サービス直属の分類の名称およびＵＵＩＤであるが、場合によって、サービス分類テーブル１３１を用いて、この直属分類の上位にある分類を検索することも考えられる。そして、Ｓ２４３１０で、利用申請プログラム２４３は、Ｓ２４３０９で確認したサービス分類（または、Ｓ２４３０２で指定されたサービス分類）と上記特定されたインプットとを指定した設計依頼メッセージＭ９を生成して仲介プログラム１４１に送信する。Ｓ２４３１１で、利用申請プログラム２４３は、当該設計依頼メッセージＭ９に応答して仲介プログラム１４１から設計依頼返答メッセージＭ１１を受信する。

このメッセージＭ１１を受信したら、Ｓ２４３０６で、利用申請プログラム２４３は、下記（ａ）または（ｂ）、
（ａ）Ｓ２４３０４で受信した調査依頼返答メッセージＭ１０にある提供者名Ｍ１００３０１（複数ある可能性がある）および関連情報、
（ｂ）設計依頼返答メッセージＭ１１にある検索結果Ｍ１１０３の連携サービス連鎖の案（複数ある可能性がある）、
を抽出してシステム内部に報告する。報告の後、利用申請プログラム２４３は、システム内部から、当該報告に対する返信、具体的には、提供者の選定結果（いずれの提供者を選択したかを示す情報）を受信する。システム内部で上記の報告およびそれに対する返信の送受信方法や、提供者の選定基準は、例えば当該システム（ローカルシステム３）自身のメカニズムに依存してよい。例えばＴＣＰ／ＩＰプロトコルでの上記の報告の送信およびそれに対する返信の受信を行うことが考えられ、選定基準は、例えば、対価が低い連携サービス或いは連携サービスの連鎖を選ぶこと、あるいは関与する人間の意志、が考えられる。

Ｓ２４３０７で、利用申請プログラム２４３は、提供者の選定結果から、いずれかの提供者が選らばれているか否かを判断する。

少なくとも一つの提供者が選定されていたら（Ｓ２４３０７：Ｙｅｓ）、Ｓ２４３０８で、利用申請プログラム２４３は、当該選定結果を用いて、該当する提供者の依頼受付プログラム２４２に、サービス依頼メッセージＭ１２を送信する。Ｓ２４３１２で、利用申請プログラム２４３は、当該サービス依頼メッセージＭ１２に応答して送信先の提供者の依頼受付プログラム２４２から、サービス依頼返答メッセージＭ１３を、送信したサービス依頼メッセージＭ１２内の通信窓口Ｍ１２１０が示す窓口で受信する。提供者テーブル１３５に提供者が存在しても、連携サービスを依頼される時点でこの提供者が依頼内容どおりに対応できるかどうか保証されるとは限らないので、本実施例のように、サービス依頼メッセージＭ１２を送ることが望ましい。

Ｓ２４３１３で、利用申請プログラム２４３は、受信したすべてのサービス依頼返答メッセージＭ１３の返答内容Ｍ１３０３が「承諾」であるかを判断する。

すべての返答内容Ｍ１３０３が「承諾」である場合は（Ｓ２４３１３：Ｙｅｓ）、Ｓ２４３１４で、利用申請プログラム２４３は、利用中サービステーブル２３４に、関連情報を新規登録する。例えば、利用対象が、連携サービス連鎖ではない場合は、利用中サービステーブル２３４の進行状態２３４０２は「実施前」とされる。利用対象が、連携サービス連鎖である場合は、一連の連携サービスに関する情報が全て利用中サービステーブル２３４に登録されるが、最初の連携サービスの進行状態２３４０２は、「実施前」とされ、残りの連携サービスの進行状態２３４０２は、「連鎖待ち」とされ、次サービス番号２３４１０が、連鎖順番に基づく相応の連携サービス番号とされる。

すべての返答内容Ｍ１３０３が「承諾」ではない場合は（Ｓ２４３１３：Ｎｏ）、Ｓ２４３０６で、利用申請プログラム２４３は、システム内部に返答をする。

Ｓ２４３１５で、終了か否かが判断される。終了の場合は（Ｓ２４３１５：Ｙｅｓ）、利用申請プログラム２４３が終了する。一方、終了ではない場合は（Ｓ２４３１５：Ｎｏ）、処理がＳ２４３０１に戻る。

図３２は、利用実行プログラム２４４が行う処理の一例を示すフローチャートである。

利用実行プログラム２４４は、起動したら、Ｓ２４４０１で、利用中サービステーブル２３４をスキャンする。Ｓ２４４０２で、利用実行プログラム２４４は、進行状態２３４０２が「実施前」で、かつ利用開始時刻２３４０８が指定した時間になった連携サービスがあるか否かを判断する。

Ｓ２４４０２の判断結果が肯定の場合は（Ｓ２４４０２：Ｙｅｓ）、Ｓ２４４０３で、利用実行プログラム２４４は、進行状態２３４０２が「実施前」で現在時刻が利用開始時刻２３４０８になった連携サービスについて、利用実行処理を行う。

一方、Ｓ２４４０２の判断結果が否定の場合は（Ｓ２４４０２：Ｎｏ）、Ｓ２４４０５で、利用実行プログラム２４４は、進行状態２３４０２が「完了」である連携サービスがあるかどうかを判断する。「完了」である連携サービスがなければ（Ｓ２４４０５：Ｎｏ）、処理がＳ２４４０１に戻る。一方、「完了」である連携サービスがあれば（Ｓ２４４０５：ＹＥｓ）、Ｓ２４４０６で、利用実行プログラム２４４は、Ｓ２４４０２およびＳ２４４０５の判断結果をシステム内部に報告する。報告先のシステム内部は、利用実行プログラム２４４を実行する利用者のメカニズムに依存してよい。例えば、システム内部は、連携サービスの利用申請を利用実行プログラム２４４に対して起こしたインスタンスでよい。Ｓ２４４０６の後、Ｓ２４４０７で、利用実行プログラム２４４は、対象の連携サービス（進行状態２３４０２が「完了」である連携サービス）の次サービス番号２３４１０に一致するサービス番号２３４０１が利用中サービステーブル２３４にあるかどうかを確認する。当該番号２３４０１がなければ、処理がＳ２４４０９に進むが、当該番号２３４０１がある場合は、Ｓ２４４０８で、利用実行プログラム２４４は、当該番号２３４０１に対応する連携サービスの進行状態２３４０２を「実施前」と更新し、処理がＳ２４４０９に移る。Ｓ２４４０９で、利用実行プログラム２４４は、進行状態２３４０２「完了」である連携サービスのエントリを利用中サービステーブル２３４から削除する。

Ｓ２４４１０で、終了か否かが判断される。終了の場合は（Ｓ２４４１０：Ｙｅｓ）、利用実行プログラム２４４が終了する。一方、終了ではない場合は（Ｓ２４４１０：Ｎｏ）、処理がＳ２４４０１に戻る。

図３３は、利用実行処理のフローチャートである。なお、図３３の説明において、「対象サービス」は、進行状態２３４０２が「実施前」で現在時刻が利用開始時刻２３４０８になった連携サービスである。

利用実行プログラム２４４は、対象サービスのサービスＵＵＩＤ１３２０１と現在のアクションの順番「１」とを例えばメモリ２４のワーク領域に記録する初期化を行い、その際、連携サービスの進行状態２３４０２を「実施中」と更新する。そして、Ｓ２４４０３＿０２で、利用実行プログラム２４４は、記録されたサービスＵＵＩＤ１３２０１と順番とをキーに、利用可能サービステーブル２３２から、当該順番に対応しているアクションを特定する。このＳ２４４０３＿０２で特定されたアクションを、図３３の説明では「対象アクション」と言う。Ｓ２４４０３＿０３～Ｓ２４４０３＿０８とＳ２４４０３＿１１～Ｓ２４４０３＿１４の一方または両方が行われるかは、対象アクションを実行する主体がこの利用者であるか否かに応じて異なる。例えば対象アクションの実行者１３４０６（図７参照）が「全参加者」の場合、両方の処理が行われる。両方の処理が行われる場合、その両方の処理は並行処理でよい。先ず、Ｓ２４４０３＿０３からの処理を説明する。なお、Ｓ２４４０３＿１１～Ｓ２４４０３＿１４に相当する処理は、図３３が示す利用実行処理とは別に（例えば、別のローカルシステム３が行う利用実行処理に関連して）行われてもよい。

Ｓ２４４０３＿０３で、利用実行プログラム２４４は、対象アクションに対応した内部コマンド２３２０５８を利用可能サービステーブル２３２から特定し、この内部コマンド２３２０５８を用いて、システム内部に指令を出す。当該指令の送信先および上記内部コマンドの内容やフォーマットはシステム自身（利用者自身）のメカニズムに依存してよい。送信先が、例えば、アクションを実行するインスタンスであり、内部コマンドは例えばシステム内の実行関数であり、Ａｃｔ（アクションＵＵＩＤ,ｔ,ｘ,ｙ,ｚ）と表すとする。Ａｃｔはシステム内で実行可能な関数であり、アクションＵＵＩＤ、ｔ、ｘ、ｙ、ｚなどの引数を導入することで、アクションＵＵＩＤ２３２０５２の指すアクション名２３２０５３が意味するアクションがシステム内で行われる。

そして、Ｓ２４４０３＿０４で、利用実行プログラム２４４は、対象アクションの実行状態Ｍ１４０６「開始」を記述したアクション実行状態通知メッセージＭ１４を連携先に送信する。なお、「連携先」は、対象サービスの提供者であり、メッセージＭ１４の送信先は、調査依頼返答メッセージＭ１０または設計依頼返答メッセージＭ１１にある通信窓口が意味する窓口である。そして、Ｓ２４４０３＿０５で、利用実行プログラム２４４は、連携先から終了通知返答メッセージＭ１５を受信する。続いて、利用実行プログラム２４４は、Ｓ２４４０３＿０６で、実行させた指令（Ｓ２４４０３＿０３で出した指令）の実行完了の通知をシステム内部から受信する。続いて、Ｓ２４４０３＿０７で、利用実行プログラム２４４は、対象アクションの実行状態Ｍ１４０６「終了」を記述したアクション実行状態通知メッセージＭ１４を連携先に送信する。そして、Ｓ２４４０３＿０８で、利用実行プログラム２４４は、終了通知返答メッセージＭ１４を連携先から受信する。

一方、Ｓ２４４０３＿１１で、利用実行プログラム２４４は、連携先からアクション実行状態通知メッセージＭ１４を受信するまで待機する。それを受信したら、Ｓ２４４０３＿１２で、利用実行プログラム２４４は、終了通知返答メッセージＭ１５を連携先に送信する。そして、Ｓ２４４０３＿１３で、利用実行プログラム２４４は、連携先からのアクション実行状態通知メッセージＭ１４を受信するまで待機する。それを受信したら、Ｓ２４４０３＿１４で、利用実行プログラム２４４は、終了通知返答メッセージＭ１５を連携先に送信する。

Ｓ２４４０３＿０８、Ｓ２４４０３＿１４またはその両方の処理が完了したら、Ｓ２４４０３＿０９で、利用実行プログラム２４４は、利用可能サービステーブル２３２を参照して対象アクションが最後のアクションであるかどうかを確認する。対象アクションが最後のアクションではない場合は（Ｓ２４４０３＿０９：Ｎｏ）、Ｓ２４４０３＿１０で、利用実行プログラム２４４は、現在のアクション順番に１を加算し、処理が、Ｓ２４４０３＿０２に戻る。一方、対象アクションが最後のアクションである場合は（Ｓ２４４０３＿０９：Ｙｅｓ）、Ｓ２４４０３＿１５で、利用実行プログラム２４４は、利用中サービステーブル２３４で相応する行の進行状態２３４０２を「完了」と更新する。

図３４は、ローカル管理プログラム２４１が行う処理の一例を示すフローチャートである。

Ｓ２４１０２で、ローカル管理プログラム２４１は、システム内部からの更新指令（サービスローカル情報を更新する指令）、または、仲介プログラム１４１からのバージョン変更周知メッセージＭ７、の受信を待機する。いずれかが受信されたら処理がＳ２４１０２に移る。なお、「サービスローカル情報」とは、このローカル管理プログラム２４１を実行するシステム３が提供可能なまたは利用可能な連携サービスに関する情報であり、具体的には、例えば、提供可能サービステーブル２３１または利用可能サービステーブル２３２である。

Ｓ２４１０２で、ローカル管理プログラム２４１は、バージョン変更周知メッセージＭ７を受信したか否かを判断する。

Ｓ２４１０２の判断結果が肯定の場合は（Ｓ２４１０２：Ｙｅｓ）、Ｓ２４１０３で、ローカル管理プログラム２４１は、バージョン変更周知メッセージＭ７を解読し、解読の結果に従う更新通知をシステム内部に送信する。更新通知には内部コマンドが関連付けられておよい。送信先、および、更新通知（内部コマンド）の内容やフォーマットはシステム自身のメカニズムに依存してよい。例えば、送信先は、標準アクションテーブル１３３とシステム内部のアクションとの対応関係を管理するインスタンスでもよいし、当該対応関係を管理する管理者または開発者に対するユーザインターフェースを提供するサーバでもよい。内部コマンドは、例えば、システム内の実行関数であり、Version_Change（Action_Table,new_ver）と表されてよい。Version_Changeはシステム内で実行可能な関数であり、Action_Table,new_verを導入することで、標準アクションテーブル１３３が新しいバージョン（new_ver）が更新されたと意味する通知がシステム内で転送されたこととなってよい。バージョンの変更に伴って、更新内容を把握する方法は、例えば、標準アクションテーブル１３３とシステム内部のアクションとの対応関係を管理するインスタンス、管理者または開発者が別途で管理端末５経由で確認することが考えられる。

更新内容によって、システム３の利用可能サービステーブル２３２または提供可能サービステーブル２３１の内容を変更する可能性があり、その場合は、更新指令がローカル管理プログラム２４１に送られる。なお、どのように変更するのかはシステム内部のメカニズムに依存してよい。例えば、管理者または開発者が上記連携サービス標準の更新内容を解読し、システム内部のアクションとの対応関係を確認し、必要な場合は関数やパラメータを修正または添削したり、該当連携サービスを利用および提供の可否を変更したりするこが考えられる。ローカル管理プログラム２４１は、システム内部から更新指令を受信した場合は（Ｓ２４１０２：Ｎｏ）、Ｓ２４１０５で、更新指令の内容に応じて、利用可能サービステーブル２３２、または提供可能サービステーブル２３１を更新する。更新されたテーブルが提供可能サービステーブル２３１の場合（Ｓ２４１０６：Ｙｅｓ）、Ｓ２４１０７で、ローカル管理プログラム２４１は、提供者更新メッセージＭ５を生成し、管理プログラム１４２に送信する。Ｓ２４１０８で、ローカル管理プログラム２４１は、管理プログラム１４２から、提供者更新メッセージＭ５に対する対応結果通知メッセージＭ６を受信する。更新されたテーブルが提供可能サービステーブル２３１ではない場合は（Ｓ２４１０６：Ｎｏ）、処理がＳ２４１０９に移る。

Ｓ２４１０９で、終了か否かが判断される。終了の場合は（Ｓ２４１０９：Ｙｅｓ）、ローカル管理プログラム２４１が終了する。一方、終了ではない場合は（Ｓ２４１０９：Ｎｏ）、処理がＳ２４１０１に戻る。

図３５は、依頼受付プログラム２４２が行う処理の一例を示すフローチャートである。

依頼受付プログラム２４２は、起動したら、Ｓ２４２０１で、サービス依頼メッセージＭ１２の受信を待機する。サービス依頼メッセージＭ１２を受信すると、Ｓ２４２０２で、依頼受付プログラム２４２は、当該メッセージＭ１２を解読し、解読結果に応じて、提供可能サービステーブル２３１で対応可能であるかどうかを確認する。Ｓ２４２０２では、例えば、提供可能サービステーブル２３１とサービス依頼メッセージＭ１２の相応箇所が比較される。サービス依頼メッセージＭ１２で指定されている連携サービスが提供可能な連携サービスの一つとして存在し当該連携サービスがメッセージＭ１２内の情報Ｍ１２０５～Ｍ１２０８が示す条件を満たしていれば、対応可能であるとの判断結果が得られる。対応可能との判断結果が得られなかった場合（Ｓ２４２０３：Ｎｏ）、Ｓ２４２０６で、サービス依頼メッセージＭ１２は、回答種類Ｍ１３０３０１「拒否」を記述したサービス依頼返答メッセージＭ１３を生成して送信元（依頼元）へ送信する。なお、「送信元」は、具体的には、受信したサービス依頼メッセージＭ１２にある通信窓口Ｍ１２１０が示す窓口である。

一方、対応可能との判断結果が得られたら（Ｓ２４２０３：Ｙｅｓ）、Ｓ２４２０４で、依頼受付プログラム２４２は、提供中サービステーブル２３３に、当該サービスに関する情報を新規で登録する。そして、Ｓ２４２０５で、依頼受付プログラム２４２は、提供可能サービステーブル２３１を更新する。具体的には、依頼受付プログラム２４２は、当該サービスが利用可能となったため当該サービスに対応する同時数２３１０５を１減らす。もし、同時数２３１０５が「０」になった場合は、依頼受付プログラム２４２は、当該サービスに対応する開始時間２３１０４として一定のルールに従う情報で記入する（例えば、当該サービスの完了までの時間を考慮して、適切な時間を記入する）。続いて、Ｓ２４２０６で、依頼受付プログラム２４２は、回答種類Ｍ１３０３０１「承諾」、利用開始時刻Ｍ１３０３０２および利用終了時刻Ｍ１３０３０３などの情報を記述したサービス依頼返答メッセージＭ１３を生成して送信元（依頼元）へ送信する。

Ｓ２４２０７で、終了か否かが判断される。終了の場合は（Ｓ２４２０７：Ｙｅｓ）、依頼受付プログラム２４２が終了する。一方、終了ではない場合は（Ｓ２４２０７：Ｎｏ）、処理がＳ２４２０１に戻る。

図３６は、提供実行プログラム２４５が行う処理の一例を示すフローチャートである。

提供実行プログラム２４５は、起動したら、Ｓ２４５０１で、提供中サービステーブル２３３をスキャンする。Ｓ２４５０２で、提供実行プログラム２４５は、進行状態２３３０２が「実施前」で現在時刻が提供開始時刻２３３０８になった連携サービスがあるか否かを判断する。

Ｓ２４５０２の判断結果が肯定の場合は（Ｓ２４５０２：Ｙｅｓ）、Ｓ２４５０３で、提供実行プログラム２４５は、進行状態２３３０２が「実施前」で現在時刻が提供開始時刻２３３０８になった連携サービスについて、提供実行処理を行う。その後、Ｓ２４５０４で、提供実行プログラム２４５は、現在のアクションの順番を１と記憶する。

一方、Ｓ２４５０２の判断結果が否定の場合は（Ｓ２４５０２：Ｎｏ）、Ｓ２４５０５で、提供実行プログラム２４５は、進行状態２３３０２が「完了」である連携サービスがあるかどうかを判断する。「完了」である連携サービスがなければ（Ｓ２４５０５：Ｎｏ）、処理がＳ２４５０１に戻る。一方、「完了」である連携サービスがあれば（Ｓ２４５０５：Ｙｅｓ）、提供実行プログラム２４５は、Ｓ２４５０６で、進行状態２３３０２が「完了」である連携サービスに関する情報を提供中サービステーブル２３３から削除する。そして、Ｓ２４５０７で、提供実行プログラム２４５は、提供可能サービステーブル２３１を更新する。具体的には、提供実行プログラム２４５は、同時数２３１０５を１増やし、開始時間２３１０４として情報を一定のルールで記入する。

Ｓ２４５０８で、終了か否かが判断される。終了の場合は（Ｓ２４５０８：Ｙｅｓ）、提供実行プログラム２４５が終了する。一方、終了ではない場合は、処理がＳ２４５０１に戻る。

図３７は、提供実行処理の一例を示すフローチャートである。なお、図３７の説明において、「対象サービス」は、進行状態２３３０２が「実施前」で現在時刻が提供開始時刻２３３０８になった連携サービスである。

提供実行プログラム２４５は、対象サービスのサービスＵＵＩＤ１３２０１と現在のアクションの順番「１」とを例えばメモリ２４のワーク領域に記録する初期化を行い、その際、進行状態２３３０２を「実施中」と更新する。そして、Ｓ２４５０３＿０２で、提供実行プログラム２４５は、記録されたサービスＵＵＩＤ１３２０１と順番とをキーに、提供可能サービステーブル２３１から、当該順番に対応しているアクションを特定する。このＳ２４５０３＿０２で特定されたアクションを、図３７の説明では「対象アクション」と言う。Ｓ２４５０３＿０３～Ｓ２４５０３＿０８とＳ２４５０３＿１１～Ｓ２４５０３＿１４の一方または両方が行われるかは、対象アクションを実行する主体がこの提供者であるか否かに応じて異なる。例えば対象アクションの実行者１３４０６（図７参照）が「全参加者」の場合、両方の処理が行われる。両方の処理が行われる場合、その両方の処理は並行処理でよい。先ず、Ｓ２４５０３＿０３からの処理を説明する。なお、Ｓ２４５０３＿１１～Ｓ２４５０３＿１４に相当する処理は、図３７が示す提供実行処理とは別に（例えば、別のローカルシステム３が行う提供実行処理に関連して）行われてもよい。

Ｓ２４５０３＿０３で、提供実行プログラム２４５は、対象アクションに対応した内部コマンド２３１０８８を提供可能サービステーブル２３１から特定し、この内部コマンド２３１０８８を用いて、システム内部に指令を出す。当該指令の送信先および上記内部コマンドの内容やフォーマットはシステム自身（提供者自身）のメカニズムに依存してよい。この点については、図３３のＳ２４４０３＿０３と同様である。

そして、Ｓ２４５０３＿０４で、提供実行プログラム２４５は、対象アクションの実行状態Ｍ１４０６「開始」を記述したアクション実行状態通知メッセージＭ１４を連携先に送信する。なお、「連携先」は、対象サービスの依頼者であり、メッセージＭ１４の送信先は、サービス依頼メッセージＭ１２にある通信窓口Ｍ１２１０が示す窓口である。そして、Ｓ２４５０３＿０５で、提供実行プログラム２４５は、連携先からの終了通知返答メッセージＭ１５を受信する。続いて、提供実行プログラム２４５は、実行させた指令（Ｓ２４５０３＿０３で出した指令）の実行完了の通知をシステム内部から受信する。続いて、Ｓ２４５０３＿０７で、提供実行プログラム２４５は、対象アクションの実行状態Ｍ１４０６「終了」を記述したアクション実行状態通知メッセージＭ１４を連携先に送信する。そして、Ｓ２４５０３＿０８で、提供実行プログラム２４５は、終了通知返答メッセージＭ１５を連携先から受信する。

一方、Ｓ２４５０３＿１１で、提供実行プログラム２４５は、連携先からアクション実行状態通知メッセージＭ１４を受信するまで待機する。それを受信したら、Ｓ２４５０３＿１２で、提供実行プログラム２４５は、終了通知返答メッセージＭ１５を連携先に送信する。そして、Ｓ２４５０３＿１３で、提供実行プログラム２４５は、連携先からのアクション実行状態通知メッセージＭ１４を受信するまで待機する。それを受信したら、Ｓ２４５０３＿１４で、提供実行プログラム２４５は、終了通知返答メッセージＭ１５を連携先に送信する。

Ｓ２４５０３＿０８、Ｓ２４５０３＿１４またはその両方の処理が完了したら、Ｓ２４５０３＿０９で、提供実行プログラム２４５は、提供可能サービステーブル２３１を参照して対象アクションが最後のアクションであるかどうかを確認する。対象アクションが最後のアクションではない場合は（Ｓ２４５０３＿０９：Ｎｏ）、Ｓ２４５０３＿１０で、提供実行プログラム２４５は、現在のアクション順番に１を加算し、処理が、Ｓ２４５０３＿０２に戻る。一方、対象アクションが最後のアクションである場合は（Ｓ２４５０３＿０９：Ｙｅｓ）、Ｓ２４５０３＿１５で、提供実行プログラム２４５は、提供中サービステーブル２３３で相応する行の進行状態２３３０２を「完了」と更新する。

図３８は、メッセージシーケンスの第１の例を示す。図３８の説明において、利用者がサービスロボット（ローカル装置２の一例）を有するローカルシステムであると想定する（サービスロボットが連携サービスを提供することも考えられる）。なお、図３８では、利用者および提供者内のローカル装置２の図示を省略し、図３８を参照した説明でも、ローカル装置２の説明は省略する。

利用者内の利用申請プログラム２４３が、連携サービス「DVD再生」を申請せよという趣旨の内部コマンドを受け取って、仲介装置１の仲介プログラム１４１に、連携サービス「DVD再生」を指定した調査依頼メッセージＭ８を送信する（ＭＴ０１）。しかし、利用申請プログラム２４３が、仲介プログラム１４１から、連携サービス「DVD再生」を提供する提供者がいないことを表す調査依頼返答メッセージＭ１０を受信する（ＭＴ０２）。

そこで、利用申請プログラム２４３が、サービス分類「Ｓｔｒｅａｍｉｎｇ再生」を指定した設計依頼メッセージＭ９を仲介プログラム１４１に送信する（ＭＴ０３）。仲介プログラム１４１が、このメッセージＭ９に応じて、「ウェブ動画検索」を行った後に「ＨＴＴＰ Ｂｒｏｗｓｅｒ」を行うという連携サービス連鎖の提案と提供者候補とを表す設計依頼返答メッセージＭ１１を利用申請プログラム２４３に返す（ＭＴ０４）。

利用申請プログラム２４３が、この返答メッセージＭ１１を解読し、「ウェブ動画検索」と「HTTP Broswer]を提供する提供者ＡおよびＢ内の依頼受付プログラム２４２にそれぞれサービス依頼メッセージＭ１２を送信する（ＭＴ０５およびＭＴ０６）。その結果、提供者ＡおよびＢのいずれもが承諾し、提供者ＡおよびＢ内の依頼受付プログラム２４２が、それぞれ、利用申請プログラム２４３に、承諾を示すサービス依頼返答メッセージＭ１３を返す（ＭＴ０７およびＭＴ０８）。

そして、利用者内の利用実行プログラム２４４が、まず、「ウェブ動画検索」を利用するために、「ウェブ動画検索」を提供する提供者Ａ内の提供実行プログラム２４５と、「ウェブ動画検索」に属するアクション毎に、アクション実行状態通知メッセージＭ１４および終了通知返答メッセージＭ１５をやり取りする（ＭＴ０９、ＭＴ１０）。なお、図３８において、「ＭＴ０９－ｎＳ」と「ＭＴ１０－ｎＳ」の組は、ｎ番目のアクションの開始の通知と受信確認を意味し、「ＭＴ０９－ｎＥ」と「ＭＴ１０－ｎＥ」の組は、ｎ番目のアクションの完了（終了）の通知と受信確認を意味する。

「ウェブ動画検索」の終了後、利用実行プログラム２４４が、「ウェブ動画検索」の次の連携サービスである「ＨＴＴＰ Ｂｒｏｗｓｅｒ」を利用するために、「ＨＴＴＰ Ｂｒｏｗｓｅｒ」を提供する提供者Ｂ内の提供実行プログラム２４５と、「ＨＴＴＰ Ｂｒｏｗｓｅｒ」に属するアクション毎に、アクション実行状態通知メッセージＭ１４と終了通知返答メッセージＭ１５をやり取りする（ＭＴ１１、ＭＴ１２）。この連携サービス「ＨＴＴＰ Ｂｒｏｗｓｅｒ」が終了することで、連携サービス連鎖が完了する。なお、図３８において、「ＭＴ１１－ｎＳ」と「ＭＴ１２－ｎＳ」の組は、ｎ番目のアクションの開始の通知と受信確認を意味し、「ＭＴ１１－ｎＥ」と「ＭＴ１２－ｎＥ」の組は、ｎ番目のアクションの完了（終了）の通知と受信確認を意味する。

図３９は、メッセージシーケンスの第２の例を示す。なお、図３９でも、ローカルシステム３内のローカル装置２の図示を省略し、図３９を参照した説明でも、ローカル装置２の説明は省略する。

管理者が、管理端末５を利用して仲介装置１内のサービス分類テーブル１３１、連携サービステーブル１３２、標準アクションテーブル１３３、または標準シナリオ定義テーブル１３４を変更するために、分類更新メッセージＭ１、サービス更新メッセージＭ２、アクション更新メッセージＭ３、またはシナリオ更新メッセージＭ４を、仲介装置１内の管理プログラム１４２に送信したとする（ＭＴ２０）。そして、管理プログラム１４２が、受信したメッセージに応じたテーブル変更を行い、対応結果通知メッセージＭ６を返信する（ＭＴ２１）。

上記テーブル変更で、変更箇所に関連するバージョンが変わったので、仲介装置１内の管理プログラム１４２が、ネットワーク４に繋いでいる全ローカルシステム３（この例ではシステムＸおよびＹ）のローカル管理プログラム２４１にバージョン変更周知メッセージＭ７をブロードキャストする（ＭＴ２２）。その結果、システムＸおよびＹのうち、当該バージョン変更に応じて提供するサービスを変更する必要がシステムＸにおいてあるとする。このため、システムＸ内のローカル管理プログラム２４１が、管理プログラム１４２に、提供者更新メッセージＭ５を送信する（ＭＴ２３）。最後に、管理プログラム１４２が、当該メッセージＭ５の返事として、対応結果通知メッセージＭ６を返す（ＭＴ２４）。

図４０は、検索画面と結果画面の一例を示す図である。

検索画面６１は、連携サービスまたは連携サービス連鎖を検索するためのＧＵＩの一例である。結果画面６２は、その検索結果を表示するためのＧＵＩの一例である。ＧＵＩは、ユーザインターフェース（ＵＩ）の一例である。検索画面６１および結果画面６２は、例えば仲介装置１内の仲介プログラム１４１および管理プログラム１４２のうちの少なくとも一つにより管理端末５に提供される。

検索画面６１は、例えば、インプット１３２０５の選択を受け付けるＧＵＩ部品６１０１と、連携サービスのサービス名１３２０２またはサービス分類名１３１０３の選択を受け付けるＧＵＩ部品６１０２と、連携サービス実行に関する他の条件（例えば、場所条件、時間条件および対価）の入力または選択を受け付けるＧＵＩ部品６１０３と、検索実行の命令を受け付けるボタン６１０４とを含む。当該ボタン６１０４が押された場合、ＧＵＩ部品６１０１～６１０３を介して受け付けられた情報がメッセージが管理端末５から管理プログラム１４２に送られ、そのメッセージに応答した結果に従う情報が、結果画面６２に表示される。

結果画面６２は、検索結果の説明を表示するサブ領域６２０１と、連携サービスまたは連携サービス連鎖の検索結果を表示するメイン領域６２０２とを含む。メイン領域６２０２には、検索結果として例えば下記が表示される。
・インプット（例えば「検索文」）とアウトプット（例えば「映像再生」）をそれぞれ共通とする一つ以上の連携サービス連鎖の各々について、インプットを受けアウトプットを出すまでに実行される一つ以上の連携サービスとその順番。
・各連携サービス連鎖について、連携サービス毎に、当該連携サービスに関連付いている代表的な情報（例えば、サービス名（例えば「ウェブ動画検索」、提供者名（例えば「Ｚ社」）、対価（例えば「５／回」）。
・各連携サービス連鎖について、連携サービスペア毎に、一方の連携サービスから他方の連携サービスへのインプットを示す情報（例えば「ＵＲＬ」）。
・各連携サービス連鎖について、当該連携サービス連鎖の実行に必要な対価（例えば「２５／回」）、具体的には、当該連携サービス連鎖を構成する一つ以上の連携サービス連鎖にそれぞれ対応した一つ以上の対価の合計。

この発明は上記実施例に限定されるものではない。要するにこの発明は、上記実施例そのままに限定されるものではなく、この発明の要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施例に示される全構成要素から幾つかの構成要素が削除されてもよい。

なお、上記の説明を、下記のように総括することができる。なお、以下の説明では、「ｋｋｋ部」（インターフェース部、記憶部及びプロセッサ部を除く）の表現にて機能を説明することがあるが、当該機能は、「ｋｋｋプログラム」（ｋｋｋは名称）がプロセッサ部によって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））によって実現されてもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。

サービス制御システムは、ネットワーク４に接続された複数のローカルシステム３が提供可能な複数の連携サービスに関する情報を含んだ管理情報（例えば、テーブル１３１～１３５のうちの少なくとも一部を含んだ情報）を管理する管理部と、対象ローカル装置２（いずれかのローカルシステム３における一のローカル装置２）から、希望のサービスに関する情報である希望情報（例えば設計依頼メッセージＭ９が含む情報の少なくとも一部）が関連付けられたリクエスト（例えば設計依頼メッセージＭ９）を受け付ける仲介部とを有する。仲介部は、当該リクエストに関連付けられている情報を満たす連携サービス連鎖（一つ以上の連携サービスの連鎖）を、管理情報を基に設計する。仲介部は、当該連携サービス連鎖を示す情報である連鎖情報（例えば設計依頼返答メッセージＭ１１が含む情報の少なくとも一部）を、対象ローカル装置２に送信する。これにより、対象ローカル装置２が多様で複雑なサービスを遂行できる。

管理情報は、複数の連携サービスの各々について、当該連携サービスのインプットおよびアウトプットの定義であり複数のローカルシステム３において標準化された定義を含む。連携サービス連鎖において、一の連携サービスについて定義されたアウトプットと次の連携サービスについて定義されたインプットが同じである。これにより、二つ以上の連携サービスの連鎖を容易に設計することができる。

希望情報が、希望のサービスへのインプットの指定を含む。連携サービス連鎖における先頭の連携サービスについて定義されたインプットが、当該希望情報において指定されているインプットと同じである。これにより、所望の希望のサービスになるべく近い連携サービス連鎖の設計が可能である。

希望情報が、希望のサービスの提供場所に関する条件である場所条件を含む。管理情報は、複数の連携サービスの各々について、当該連携サービスの提供場所を示す情報を含む。連携サービス連鎖を構成する各連携サービスは、希望情報が含む場所条件を満たす提供場所に対応した連携サービスである。これにより、希望の提供場所で連携サービス連鎖が遂行されることを維持できる。

希望情報が、希望のサービスの提供時間に関する条件である時間条件を含む。管理情報は、複数の連携サービスの各々について、当該連携サービスの提供時間を示す情報を含む。連携サービス連鎖を構成する各連携サービスは、希望情報が含む時間条件を満たす提供時間に対応した連携サービスである。これにより、希望の提供時間に連携サービス連鎖が遂行されることを維持できる。

希望情報が、希望のサービスの利用にかかる対価に関する条件である対価条件を含む。管理情報は、複数の連携サービスの各々について、当該連携サービスの提供にかかる対価を示す情報を含む。連携サービス連鎖を構成する一つ以上の連携サービスにそれぞれ対応した一つ以上の対価に基づき定まる、当該連携サービス連鎖の対価は、希望情報が含む対価条件を満たす対価である。これにより、希望の対価以下の対価で連携サービス連鎖が遂行されることを維持できる。

希望情報が、当該希望のサービスの分類に関する情報を含む。管理情報が、複数の連携サービスの各々について、当該連携サービスが所属する分類を示す情報を含む。連携サービス連鎖を構成する各連携サービスは、希望情報が示す分類と同じ分類またはその分類に所属する分類に所属する連携サービスである。これにより、希望のサービスの分類という粗い指定で、希望のサービスと同じまたはそれに近い連携サービス連鎖の設計が可能である。

連鎖情報は、連携サービス連鎖を構成する各連携サービスについて、当該連携サービスの順番を示す情報である順番情報と、当該連携サービスを提供するローカルシステムに関する情報である提供者情報とを含む。これにより、対象ローカル装置２が、連携サービス連鎖を構成する一つ以上の連携サービスをどういった順序で実行し、いずれのローカルシステム３からいずれの連携サービスの提供を受ければよいかを特定することができる。

サービス制御システムは、更に、対象ローカル装置２が有する利用申請部および利用実行部を更に有する。利用申請部が、上記リクエストを送信する。利用実行部は、連鎖情報に従い連携サービス連鎖を実行する。具体的には、例えば、利用実行部が、連鎖情報に従う順序で連携サービス連鎖を構成する一つ以上の連携サービスを実行する。当該一つ以上の連携サービスの各々の実行において、当該連携サービスに対応した提供者情報が示すローカルシステムから提供される当該連携サービスを実行する。このようにして、対象ローカル装置２によって連携サービス連鎖を実行することを実現できる。

一つ以上の連携サービスの各々の実行において、利用実行部は、当該連携サービスに対応した提供者情報が示すローカルシステム３に、当該連携サービスの実行に必要なアクション毎に当該アクションの開始と終了を伝える。これにより、連携サービスを提供するローカルシステム３は、連携サービスの進捗を把握できる。

利用申請部が、連携サービス連鎖を構成する一つ以上の連携サービスの各々について、当該連携サービスを提供するローカルシステム３に、当該連携サービスの提供の依頼であるサービス依頼（例えばサービス依頼メッセージＭ１２）を出する。すべてのサービス依頼について連携サービスの提供の承諾が得られた場合に、利用申請部が、連鎖情報に含まれる情報であって、連携サービス連鎖を構成する各連携サービスの利用に必要な情報を登録する。これにより、連携サービス連鎖の一部の連携サービスを実行できないといったことを避けることができる。

サービス制御システムは、複数のローカルシステム３の各々における各ローカル装置２が有する依頼受付部を更に有する。連携サービス連鎖を構成する一つ以上の連携サービスの各々について、サービス依頼に、連携サービスが指定されており、かつ、当該連携サービスに関する条件（例えば、上述した場所条件、時間条件および対価条件のうちの少なくとも一つ）が関連付けられている。依頼受付部が、サービス依頼を受け付けた場合、当該サービス依頼で指定されている連携サービスが、当該サービス依頼に関連付けられている条件を満たしていれば、当該サービス依頼に対して提供の承諾を返す。これにより、条件を満たす連携サービス連鎖の設計と実行を維持することができる。

１：仲介装置

Claims (11)

1. ネットワークに接続された複数のローカルシステムが提供可能な複数の連携サービスに関する情報を含んだ管理情報を管理する管理部と、
   前記複数のローカルシステムの各々は、一つ以上のサービスロボットを含み、
   前記複数の連携サービスの各々は、少なくとも一つの他の連携サービスと連携することが可能なサービスであり、
   前記複数のローカルシステムのうちのいずれかのローカルシステムにおける一のサービスロボットである対象サービスロボットから、希望のサービスに関する情報である希望情報が関連付けられたリクエストを受け付け、当該リクエストに関連付けられている情報を満たす、二つ以上の連携サービスの連鎖である連携サービス連鎖を、前記管理情報を基に設計し、当該連携サービス連鎖を示す情報である連鎖情報を、前記対象サービスロボットに送信する仲介部と
   を有し、
   前記管理情報は、前記複数の連携サービスの各々について、当該連携サービスのインプットおよびアウトプットの定義であり前記複数のローカルシステムにおいて標準化された定義を含み、
   前記連携サービス連鎖において、一の連携サービスについて定義されたアウトプットと次の連携サービスについて定義されたインプットが同じであり、
   前記希望情報が、前記希望のサービスへのインプットの指定を含み、
   前記連携サービス連鎖における先頭の連携サービスについて定義されたインプットが、前記希望情報において指定されているインプットと同じである、
   サービス制御システム。
2. 前記希望情報が、前記希望のサービスの提供場所に関する条件である場所条件を含み、
   前記管理情報は、前記複数の連携サービスの各々について、当該連携サービスの提供場所を示す情報を含み、
   前記連携サービス連鎖を構成する各連携サービスは、前記希望情報が含む場所条件を満たす提供場所に対応した連携サービスである、
   請求項１に記載のサービス制御システム。
3. 前記希望情報が、前記希望のサービスの提供時間に関する条件である時間条件を含み、
   前記管理情報は、前記複数の連携サービスの各々について、当該連携サービスの提供時間を示す情報を含み、
   前記連携サービス連鎖を構成する各連携サービスは、前記希望情報が含む時間条件を満たす提供時間に対応した連携サービスである、
   請求項１に記載のサービス制御システム。
4. 前記希望情報が、前記希望のサービスの利用にかかる対価に関する条件である対価条件を含み、
   前記管理情報は、前記複数の連携サービスの各々について、当該連携サービスの提供にかかる対価を示す情報を含み、
   前記連携サービス連鎖を構成する二つ以上の連携サービスにそれぞれ対応した二つ以上の対価に基づき定まる、当該連携サービス連鎖の対価は、前記希望情報が含む対価条件を満たす対価である、
   請求項１に記載のサービス制御システム。
5. 前記希望情報が、当該希望のサービスの分類に関する情報を含み、
   前記管理情報が、前記複数の連携サービスの各々について、当該連携サービスが所属する分類を示す情報を含み、
   前記連携サービス連鎖を構成する各連携サービスは、前記希望情報が示す分類と同じ分類またはその分類に所属する連携サービスである、
   請求項１に記載のサービス制御システム。
6. 前記連鎖情報は、前記連携サービス連鎖を構成する各連携サービスについて、当該連携サービスの順番を示す情報である順番情報と、当該連携サービスを提供するローカルシステムに関する情報である提供者情報とを含む、
   請求項１に記載のサービス制御システム。
7. 前記対象サービスロボットが有する利用申請部および利用実行部を更に有し、
   前記利用申請部が、前記リクエストを送信し、
   前記利用実行部が、前記連鎖情報に従う順序で前記連携サービス連鎖を構成する二つ以上の連携サービスを実行し、
   当該二つ以上の連携サービスの各々の実行において、前記利用実行部は、当該連携サービスに対応した提供者情報が示すローカルシステムから提供される当該連携サービスを実行する、
   請求項６に記載のサービス制御システム。
8. 前記二つ以上の連携サービスの各々の実行において、前記利用実行部は、当該連携サービスに対応した提供者情報が示すローカルシステムに、当該連携サービスの実行に必要なアクション毎に当該アクションの開始と終了を伝える、
   請求項７に記載のサービス制御システム。
9. 前記利用申請部が、
   前記連携サービス連鎖を構成する二つ以上の連携サービスの各々について、当該連携サービスを提供するローカルシステムに、当該連携サービスの提供の依頼であるサービス依頼を出し、
   すべてのサービス依頼について連携サービスの提供の承諾が得られた場合に、前記連鎖情報に含まれる情報であって、前記連携サービス連鎖を構成する各連携サービスの利用に必要な情報を登録する、
   請求項７に記載のサービス制御システム。
10. 前記複数のローカルシステムの各々における各サービスロボットが有する依頼受付部を更に有し、
    前記連携サービス連鎖を構成する二つ以上の連携サービスの各々について、前記サービス依頼に、連携サービスが指定されており、かつ、当該連携サービスに関する条件が関連付けられており、
    前記依頼受付部が、前記サービス依頼を受け付けた場合、当該サービス依頼で指定されている連携サービスが、当該サービス依頼に関連付けられている条件を満たしていれば、当該サービス依頼に対して提供の承諾を返す、
    請求項９に記載のサービス制御システム。
11. （Ａ）コンピュータが、ネットワークに接続された複数のローカルシステムのうちのいずれかのローカルシステムにおける一のサービスロボットである対象サービスロボットから、希望のサービスに関する情報である希望情報が関連付けられたリクエストを受け付け、
    前記複数のローカルシステムの各々は、一つ以上のサービスロボットを含み、
    （Ｂ）コンピュータが、当該リクエストに関連付けられている情報を満たす、二つ以上の連携サービスの連鎖である連携サービス連鎖を、前記複数のローカルシステムが提供可能な複数の連携サービスに関する情報を含んだ管理情報を基に設計し、
    前記複数の連携サービスの各々は、少なくとも一つの他の連携サービスと連携することが可能なサービスであり、
    （Ｃ）コンピュータが、当該連携サービス連鎖を示す情報である連鎖情報を、前記対象サービスロボットに送信し、
    前記管理情報は、前記複数の連携サービスの各々について、当該連携サービスのインプットおよびアウトプットの定義であり前記複数のローカルシステムにおいて標準化された定義を含み、
    前記連携サービス連鎖において、一の連携サービスについて定義されたアウトプットと次の連携サービスについて定義されたインプットが同じであり、
    前記希望情報が、前記希望のサービスへのインプットの指定を含み、
    前記連携サービス連鎖における先頭の連携サービスについて定義されたインプットが、前記希望情報において指定されているインプットと同じである、
    サービス制御方法。
    

Images