WO2013076920A1

WO2013076920A1 - マスター機器、連携サービス管理システム、及び連携サービス管理方法

Info

Publication number: WO2013076920A1
Application number: PCT/JP2012/006896
Authority: WO
Inventors: 幸田岡; 田中　敬一
Original assignee: パナソニック株式会社
Priority date: 2011-11-25
Filing date: 2012-10-26
Publication date: 2013-05-30
Also published as: US20140115025A1; US9332061B2; JPWO2013076920A1; CN103229522A

Abstract

デバイス情報取得部は、周辺機器からアドホックネットワークを介してデバイス情報を取得する。連携サービス決定部は、連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを決定する。配信スクリプト決定部は、クライアント機器のデバイス情報と、実行対象の連携サービスのスペック要件とを照合し、クライアント機器のクライアントＵＩを決定する。スクリプト配信部は、配信スクリプト決定部により決定されたクライアントＵＩを各クライアント機器に配信する。

Description

マスター機器、連携サービス管理システム、及び連携サービス管理方法

　本発明は、ネットワークを介して接続された機器が相互に通信し、連携してサービスを実行する、連携サービスの技術に関するものである。

　近年、スマートフォンやタブレット端末などの個人ユーザ向け高機能端末が普及している。これら端末は、アンドロイド（Ａｎｄｒｏｉｄ：登録商標）やｉＯＳ等のプラットフォームを搭載し、様々なアプリケーションをダウンロードして実行する環境を備えている。

　これに伴い、屋内外問わず様々な場所で複数の機器を接続し、各機器を相互に連携させてユーザにサービスを提供する連携サービスの利用拡大が想定されている。

　複数の機器上にアプリケーションを配信して、連携サービスを実現する従来の技術として、例えば、下記の従来技術が知られている。

　例えば、非特許文献１、２には、タブレット端末又はスマートフォンとテレビとを連携させ、タブレット端末又はスマートフォンの操作で、テレビにコンテンツを表示させるアップル（Ａｐｐｌｅ）社のエアープレイ（Ａｉｒｐｌａｙ）という技術が開示されている。この技術では、機器の組み合わせが固定の連携サービスを構成する専用アプリケーションを、予め、各機器に個別インストールし、インストールしたアプリを実行することで連携サービスが実現されている。

　特許文献１では、ネットワークゲートウェイが、プログラム配信サイトからのプログラム更新要求や配下に接続された各機器からの要求に応答して、プログラム配信サイトからプログラムを受信し、受信したプログラムを各機器に配信する技術が開示されている。

　しかしながら、上記の非特許文献１、２の技術では、（１）タブレット端末及びテレビといった予め組み合わせることが分かっている固定の組み合わせ機器以外の機器間で連携サービスを提供できないという問題がある。また、（２）連携サービスを実行する各機器において、連携サービスを実現するためのアプリケーションをインターネット等のアクセスポイントのある外部ネットワークからインストールさせる必要がある。

　したがって、非特許文献１、２の技術では、アクセスポイントを介することなく機器同士が通信するアドホックネットワーク（自律分散型ネットワーク）を使って連携サービスを実現しようとした場合、各機器に連携サービスを実現するためのアプリケーションがインストールされていなければ、連携サービスを実現することができないという課題があった。

　また、特許文献１の技術では、ゲートウェイを介することなく各機器にアプリケーションを配信することができないため、各機器がゲートウェイに接続できない環境下にある場合、各機器にアプリケーションを配信することができないという課題がある。

　そのため、一度、各機器に連携サービスを実行するためのアプリケーションをインストールしたとしても、その機器をアドホックネットワークに接続した場合、各機器でインストールされているアプリケーションのバージョン等に不整合が発生すると、連携サービスを実行することができないという課題がある。

特開２００１－２２２５００号公報

［ｏｎｌｉｎｅ］アップル（Apple）社ホームページ、［２０１１年１１月２日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ａｐｐｌｅ．ｃｏｍ／ｊｐ／ｉｐａｄ／ｆｅａｔｕｒｅｓ／ａｉｒｐｌａｙ．ｈｔｍｌ＞［ｏｎｌｉｎｅ］アップル（Apple）社ホームページ、［２０１１年１１月２日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ａｐｐｌｅ．ｃｏｍ／ｊｐ／ｉｐｏｄｔｏｕｃｈ／ｆｅａｔｕｒｅｓ／ａｉｒｐｌａｙ．ｈｔｍｌ＞

　本発明の目的は、自律分散型ネットワークにおいて連携サービスを実現することができる技術を提供することである。

　本発明の一態様によるマスター機器は、自律分散型ネットワークにおいて、複数の機器を互いに連携させて実行される連携サービスを管理するマスター機器であって、複数の連携サービスに関して、各連携サービスを実行する際に前記機器で必要となるアプリケーションに関する情報と前記アプリケーションを実行するために要求される前記機器のスペック要件とを規定する連携サービス情報を管理する連携サービス情報管理部と、前記自律分散型ネットワークを介して検出された１又は複数の周辺機器から周辺機器のスペックを規定するデバイス情報を取得するデバイス情報取得部と、前記周辺機器から前記連携サービスに使用される１又は複数のクライアント機器を決定し、決定したクライアント機器とネットワーク接続を確立する接続管理部と、前記連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを決定する連携サービス決定部と、前記クライアント機器のデバイス情報と、前記実行対象の連携サービスの前記スペック要件とに基づき、前記クライアント機器のアプリケーションを決定するアプリケーション決定部と、前記アプリケーション決定部により決定されたアプリケーションを前記クライアント機器に配信するアプリケーション配信部と、前記アプリケーション配信部により配信されたアプリケーションの起動指示を前記クライアント機器に行う連携サービスライフサイクル管理部とを備える。

本発明の実施の形態１における連携サービス管理システムの一例を示す機能ブロック図である。デバイス情報取得部が周辺機器から取得するデバイス情報の一例を示した図である。本発明の実施の形態１における連携サービス構成の一例を示す模式図である。連携サービス情報管理部が管理する連携サービス情報の一例を示す図である。連携サービスの決定、ネットワーク接続の確立、及びクライアントＵＩの決定までの処理の一例を示すシーケンス図である。図５に続くシーケンス図であり、配信方法１を採用した場合のシーケンス図である。図５に続くシーケンス図であり、配信方法２を採用した場合のシーケンス図である。マスター機器において、ユーザがネットワークを選択する際にディスプレイに表示される画面遷移の一例を示す図である。マスター機器において、連携サービスを開始する際にディスプレイに表示される画面遷移の一例を示した図である。マスター機器において、ユーザが連携サービスを選択する際にディスプレイに表示される画面遷移の一例を示した図である。（Ａ）はクライアント機器としてＡ、Ｂの２台の機器が存在する場合を示し、（Ｂ）はクライアント機器としてＡ～Ｃの３台の機器が存在する場合を示している。本発明の実施の形態２における連携サービス管理システムの一例を示す機能ブロック図である。本発明の実施の形態２における連携サービスの構成の一例を示す模式図である。連携サービスの決定、ネットワーク接続の確立、及びクライアントＵＩの決定までの処理の一例を示すシーケンス図である。図１３に続くシーケンス図であり、配信方法１を採用した場合のシーケンス図である。図１３に続くシーケンス図であり、配信方法２を採用した場合のシーケンス図である。

　以下本発明の実施の形態について、図面を参照しながら説明する。なお、これらの図面は、本発明が採用しうる技術的特徴を説明するために用いられるものであり、記載されている装置の構成及び処理などは、特に特定的な記載がない限り、それのみに限定する趣旨ではなく、単なる説明例である。

　（実施の形態１）
　本発明の実施の形態１による連携サービス管理システムは、外部ネットワークに接続するためのアクセスポイントがない環境下において、周りにある機器と自律分散型ネットワークを構築し、各機器のスペック（性能）に適合するアプリケーションを各機器に配信して連携サービスを実現する。ここで、自律分散型ネットワークとは、アクセスポイントや基地局に依存せず、多数の端末が自律分散的にルーターと同様の役割を担い、数珠つなぎの通信を実現するネットワークであり、例えば、アドホックネットワークが該当する。

　（構成の説明）
　図１は、本発明の実施の形態１における連携サービス管理システム１００１の一例を示す機能ブロック図である。連携サービス管理システム１００１は、マスター機器１１０１及びクライアント機器１２０１を備える。

　連携サービス管理システム１００１は、互いに通信しあいながら連携サービスを実行する複数の機器により実現される。連携サービスとしては、一例として、マスター機器１１０１と１又は複数のクライアント機器１２０１とで一つの画像を分割して表示するものが挙げられる。

　連携サービスを実行する機器は、例えばスマートフォン、タブレット端末、ＴＶ、レコーダのように、ＣＰＵなどの処理装置（図示せず）と、プログラムを記憶するメモリと、ハードディスクなどの記録媒体と、ネットワーク接続やネットワーク通信を行なうための通信装置（図示せず）などのハードウェアを備えている。そして、連携サービスを実行する機器は、記録媒体に記録されたプログラムを処理装置にて実行させることにより、ネットワーク接続機能を実現する。また、連携サービスを実行する機器は、表示した操作画面に対するユーザからの操作、或いは、ネットワーク接続された他機器からの操作により種々の処理が実行可能である。

　また、記録媒体に記録されるプログラムというのは、例えば、本実施の形態にて後述するシーケンスに係る処理、連携サービスを実行する機器を構成する要素の動作を実現するためのプログラムである。

　また、記録媒体に記録されたプログラムをＣＰＵにて実行させるのではなく、プログラムをＣＰＵにて実行させて実現できる動作を、集積回路を用いて構成をしても良い。集積回路を用いる構成を採用すれば、対応するプログラムを記録媒体に記録する必要はなくなる。

　連携サービスを実行する機器は、マスター側機能、クライアント側機能の両方又はいずれか一方を搭載する。連携サービスを実行する際には、一つの機器がマスター側機能を実行してマスター機器１１０１となり、その他の１又は複数の機器がクライアント側機能を実行してクライアント機器１２０１となる。

　マスター機器１１０１及びクライアント機器１２０１は、ネットワークＮＴにより接続される。本実施の形態では、ネットワークＮＴとして、ＷｉＦｉ（登録商標）やＷｉＦｉＤｉｒｅｃｔ等の無線ネットワークを例に挙げて説明する。但し、これは、一例であり、ネットワークＮＴとしては、有線ネットワークを採用してもよいし、ＷｉＦｉ（登録商標）及びＷｉＦｉＤｉｒｅｃｔ以外の他の無線ネットワークを採用してもよいし、有線ネットワーク及び無線ネットワークが混在するネットワークを採用してもよい。

　ＷｉＦｉの規格は、例えば、ＷｉＦｉ　Ａｌｌｉａｎｃｅにて規定されている。ＷｉＦｉ　Ａｌｌｉａｎｃｅでは機器がアクセスポイント（ＡＰ）を経由して通信するインフラストラクチャモードと、機器同士が直接通信するアドホックモードとが規定されている。マスター機器１１０１及びクライアント機器１２０１がアドホックモードを選択すると、ネットワークＮＴはアドホックネットワークとなる。

　マスター機器１１０１は、周辺機器の中からネットワーク接続を確立するクライアント機器１２０１を決定し、決定したクライアント機器１２０１に接続依頼を送信し、連携サービスを実行するためのアプリケーション（以下、ＵＩ（ユーザインターフェイス）アプリと記述する。）を決定し、決定したＵＩアプリをクライアント機器１２０１に配信し、クライアント機器１２０１にＵＩアプリの実行を指示する。

　クライアント機器１２０１は、マスター機器１１０１からの接続依頼を受けて、アドホックネットワークへの参加を決定し、マスター機器１１０１から配信されたＵＩアプリを受信し、マスター機器１１０１からの指示を受けて、受信したＵＩアプリを起動する。

　（マスター機器１１０１の機能の概要）
　マスター機器１１０１は、下記の（１）～（５）の機能を備えている。

　（１）複数の連携サービスに関して、各連携サービスを実行する際に各機器で必要となるＵＩアプリに関する情報とＵＩアプリを実行するために要求される各機器のスペック要件とを規定する連携サービス情報（図４参照）を管理する機能。

　（２）連携サービス情報に規定されたスペック要件と周辺機器のデバイス情報とを照合し、実行可能な連携サービスを抽出し、抽出した連携サービスの一覧をユーザに提示し、ユーザの指示に基づき、実行対象の連携サービスを決定し、決定した連携サービスを実行するためのマスター側のＵＩアプリを起動する機能。

　（３）周辺機器のデバイス情報をユーザに提示し、連携するクライアント機器１２０１を決定し、決定したクライアント機器１２０１に接続依頼を送信し、ネットワーク接続を確立する機能。

　（４）ＵＩアプリを実行するために要求される機器のスペック要件と、クライアント機器１２０１のデバイス情報とを照合し、クライアント機器１２０１に配信するＵＩアプリを決定する機能。

　（５）クライアント機器１２０１にＵＩアプリを配信し、起動指示を行う機能。

　（クライアント機器１２０１の機能の概要）
　クライアント機器１２０１は、下記の（１）、（２）の機能を備えている。

　（１）マスター機器１１０１からの接続依頼を受けて連携サービスのネットワークに参加する機能。

　（２）マスター機器１１０１から配信されたＵＩアプリを受信し、マスター機器からの起動指示を受けて、受信したＵＩアプリを起動する機能。

　以下、図１に示すマスター機器１１０１及びクライアント機器１２０１の構成の詳細を説明する。

　（マスター機器１１０１の説明）
　マスター機器１１０１は、機器接続管理部１１０２、連携サービス構成管理部１１０３、連携サービスライフサイクル管理部１１０４、コンテンツ共有部１１０５、ＵＩアプリ実行エンジン１１０６、アプリケーション１１０７、及びネットワーク通信部１１０８を備える。

　機器接続管理部１１０２は、デバイス情報取得部１１２１及び接続管理部１１２２を備える。デバイス情報取得部１１２１は、周辺機器からアドホックネットワークを介してデバイス情報を取得する。また、デバイス情報取得部１１２１は、マスター機器１１０１が備える各構成要素からの要求に応じて、周辺機器からデバイス情報を取得し、取得したデバイス情報を各構成要素に提供する。

　図２は、デバイス情報取得部１１２１が周辺機器から取得するデバイス情報の一例を示した図である。図２に示すようにデバイス情報は、列２０１１～２０１３を備えている。

　列２０１１にはデバイス情報のカテゴリ名が記載されている。列２０１２にはデバイス情報の各要素名が記載されている。列２０１３には各要素の値が記載されている。行２００１には、デバイス識別子が記載されている。デバイス識別子は、機器を一意に特定するための情報である。デバイス識別子としては例えば、ＵＤＮ（Ｕｎｉｑｕｅ　Ｄｅｖｉｃｅ　Ｎａｍｅ）が採用される。

　行２００２～２００４には、ユーザに提示する情報が記載されており、人が視認できる情報が記載されている。具体的には、行２００２～２００４のそれぞれには、アイコン（ｉｃｏｎ　ｕｒｌ）、デバイス名（ｆｒｉｅｎｄｌｙ　Ｎａｍｅ）、概要説明（ｍｏｄｅｌ　Ｄｅｓｃｒｉｐｔｉｏｎ）が記載されている。

　行２００５～２０１１には、デバイスの種別・機能情報が記載されている。デバイスの種別・機能情報としては、マスター機器１１０１が解釈可能な情報であって、接続する機器の決定、連携サービスの決定、配信するＵＩの決定に使う情報が記載されている。具体的には、デバイスの種別・機能情報として、デバイス種別（ｄｅｖｉｃｅ　Ｔｙｐｅ）、製造者（ｍａｎｕｆａｃｔｕｒｅｒ）、モデル名（ｍｏｄｅｌ　Ｎａｍｅ）、モデル番号（ｍｏｄｅｌ　Ｎｕｍｂｅｒ）、搭載ＯＳ（ＯＳ）、解像度（ｒｅｓｏｌｕｔｉｏｎ）、及びサポート機能（ｓｕｐｐｏｒｔ＿ｆｕｎｃｔｉｏｎ）が含まれる。

　行２００１～２００８の各要素は、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ）規定のデバイスディスクリプション（Ｄｅｖｉｃｅ　ｄｅｓｃｒｉｐｔｉｏｎ）情報が採用されている。図２に示すデバイス情報は、このデバイスディスクリプション情報に加えて、更に行２００９～２０１１に示す搭載ＯＳ、解像度、及びサポート機能の要素が記載されている。搭載ＯＳは機器が搭載するオペレーションシステムの名称を示す。解像度は、機器のディスプレイの解像度を示す。サポート機能は、クライアント機能を備えているか、マスター機能を備えているか、タッチ操作機能を備えているかといった機器がサポートする機能を示す。

　なお、デバイス情報としては、接続する機器の決定、連携サービスの決定、配信するＵＩアプリの決定に利用できる情報であれば他の情報を採用してもよい。

　図１に戻り、デバイス情報取得部１１２１は、ネットワーク接続が確立されていない周辺機器からデバイス情報を取得する場合、例えば、ＷｉＦｉＤｉｒｅｃｔに規定のデバイス検索、又はサービス検索等のプロトコルを用いてデバイス情報を取得すればよい。

　また、デバイス情報取得部１１２１は、ネットワーク接続が確立されている周辺機器からデバイス情報を取得する場合、例えば、ＷｉＦｉＤｉｒｅｃｔに規定のデバイス検索、サービス検索のプロトコルや、ＵＰｎＰに規定のＤｅｖｉｃｅ　ｄｉｓｃｏｖｅｒｙ等のプロトコルを用いてデバイス情報を取得すればよい。

　なお、デバイス情報を取得するプロトコルとしては、上記のデバイス情報を取得でき、且つ、連携サービス管理システム１００１を構築する機器間で共通のプロトコルであれば、どのようなプロトコルを採用してもよい。

　接続管理部１１２２は、周辺機器からクライアント機器１２０１を決定し、クライアント機器１２０１に接続依頼を行い、クライアント機器１２０１からの応答に従ってネットワーク接続を確立する。

　なお、接続管理部１１２２は、例えば、ＷｉＦｉＤｉｒｅｃｔに規定のプロトコルを用いてクライアント機器１２０１とネットワーク接続を確立すればよい。

　連携サービス構成管理部１１０３は、連携サービス情報管理部１１３１、連携サービス決定部１１３２、配信スクリプト決定部１１３３（アプリケーション決定部の一例）、スクリプト配信部１１３４（アプリケーション配信部の一例）を備えている。

　以下、本発明の実施の形態１における種々の用語について説明する。連携サービスとは、複数の機器が連携して実行するサービスあって、具体的には、１つのマスター機器１１０１と１又は複数のクライアント機器１２０１とを接続して実現されるサービスである。連携サービスを実行するためには、各機器上で実行するＵＩアプリが必要となる。

　ＵＩアプリとは、連携サービスを構成する各機器においてＵＩ（ユーザインターフェイス）を実現するためのアプリケーションである。このＵＩアプリは、例えば、Ｊａｖａｓｃｒｉｐｔ（登録商標）等のスクリプト言語で記述される。マスター機器１１０１で起動されるＵＩアプリをマスターＵＩ（Ｍａｓｔｅｒ　ＵＩ、マスターアプリケーションの一例）と呼び、クライアント機器１２０１で起動されるＵＩアプリをクライアントＵＩ（Ｃｌｉｅｎｔ　ＵＩ、クライアントアプリケーションの一例）と呼ぶ。

　マスターＵＩは、マスター機器１１０１において、連携サービスが選択された後、最初に起動されるアプリケーションである。このマスターＵＩは、クライアント機器１２０１とマスター機器１１０１とのネットワーク接続を確立してネットワークを構築する処理や、クライアント機器１２０１にクライアントＵＩを配信し、配信したクライアントＵＩの起動を指示する処理等を行う。

　クライアントＵＩは、クライアント機器１２０１において、マスター機器１１０１からの起動指示を受けて起動するアプリケーションである。

　その他、本実施の形態では、連携サービスとは独立のＵＩアプリとしてサービスセレクトＵＩ（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔ　ＵＩ）がある。サービスセレクトＵＩは、マスター機器１１０１において、複数の連携サービスが存在する場合に実行されるアプリケーションであり、複数の連携サービスの中から実行対象となる一つの連携サービスを選択するアプリケーションである。

　図３は、本発明の実施の形態１における連携サービス構成の一例を示す模式図である。連携サービス情報管理部１１３１は、一つのサービスセレクトＵＩ、複数の連携サービス、及び各連携サービスを構成するＵＩアプリ（マスターＵＩ又はクライアントＵＩ）を管理する。

　マスター機器１１０１は、最初にサービスセレクトＵＩを起動し、サービスセレクトＵＩが連携サービスを選択した際に、選択された連携サービスを構成するマスターＵＩを起動する。図３では、マスター機器１１０１は、２つの連携サービス３００１、３００２を備えている。連携サービス３００１は、マスター機器１１０１と２つのクライアント機器１２０１とで行われる連携サービスである。連携サービス３００２は、マスター機器１１０１と１つのクライアント機器１２０１とで行われる連携サービスである。

　例えば、サービスセレクトＵＩが、ユーザの指示に基づき、連携サービス３００１を選択したとすると、連携サービス３００１のマスターＵＩが起動される。一方、サービスセレクトＵＩが、ユーザの指示に基づき、連携サービス３００２を選択したとすると、連携サービス３００２のマスターＵＩが起動される。

　なお、連携サービスが一つしか存在しない場合には、マスター機器１１０１は、サービスセレクトＵＩを起動せずに、直接、連携サービスを構成するマスターＵＩを起動してもよい。

　マスターＵＩ、クライアントＵＩ、及びサービスセレクトＵＩは、それぞれ、アプリケーション１１０７を構成し、ＵＩアプリ実行エンジン１１０６によりスクリプトデータがデコードされることで実現される。

　図１に戻り、連携サービス情報管理部１１３１は、図４に示す連携サービス情報を管理する。図４は、連携サービス情報管理部１１３１が管理する
連携サービス情報の一例を示す図である。連携サービス情報は、連携サービスリスト４００１及びＵＩアプリリスト４００２を備えている。

　連携サービスリスト４００１は、マスター機器１１０１で実行可能な連携サービスに関する情報を格納するテーブルであり、サービスＩＤ、サービスバージョン、サービス名、ディスクリプション（Ｄｅｓｃｒｉｐｔｉｏｎ）、及びＵＩアプリリストのフィールドを備えている。

　サービスＩＤのフィールドには、各連携サービスに対して一意に付与された識別コードが格納されている。サービスバージョンのフィールドには、各連携サービスのバージョン名が格納されている。サービス名のフィールドには、各連携サービスに対する名前が格納されている。ディスクリプションのフィールドには、各連携サービスの簡単な説明を記述する文字列が格納されている。ＵＩアプリリストのフィールドには、各連携サービスに対するＵＩアプリリスト４００２が格納されている。

　ＵＩアプリリスト４００２は、連携サービスを実行するにあたりマスター機器１１０１及びクライアント機器１２０１で必要となるＵＩアプリの情報のフィールドと、各ＵＩアプリを実行する際に要求される機器のスペック要件のフィールドとを備えるテーブルである。

　ＵＩアプリの情報のフィールドは、更に、ＩＤ、ＵＩタイプ（ＵＩ　Ｔｙｐｅ）、及びファイルパス（Ｆｉｌｅ　ｐａｔｈ）のフィールドに分けられる。ＩＤのフィールドには、各ＵＩアプリに対して一意に付与された識別コードが格納されている。

　ＵＩタイプのフィールドには、ＵＩアプリがマスターＵＩであるかクライアントＵＩであるかを示す情報が格納されている。図４の例では、ＵＩアプリがマスターＵＩであれば、ＵＩタイプのフィールドには“Ｍａｓｔｅｒ＿ＵＩ”が格納され、ＵＩアプリがクライアントＵＩであれば、ＵＩタイプのフィールドに“Ｃｌｉｅｎｔ＿ＵＩ”が格納されている。ファイルパスのフィールドには、各ＵＩアプリの格納場所を示すファイルパスが格納されている。

　スペック要件のフィールドは、更に、デバイス種別（Ｄｅｖｉｃｅ　Ｔｙｐｅ）、メーカ名（Ｍａｎｕｆａｃｔｕｒｅｒ）、ＯＳ、解像度、及びサポート機能のフィールドに分けられる。デバイス種別のフィールドには、機器の種類が格納されている。メーカ名のフィールドには、機器のメーカ名が格納されている。ＯＳのフィールドには、機器が実装するＯＳの名称が格納されている。解像度のフィールドには、機器の解像度が格納されている。例えば、行４０２１の解像度のフィールドには、“０－３２０ｐｘ（ｓｍａｒｔ　ｐｈｏｎｅ）”が格納されている。これは、行４０２１のＵＩアプリを実行するためには、解像度が３２０ピクセル以下のスマートフォンであることが要求される。

　行４０２２の解像度のフィールドには、“３２１－９００ｐｘ（ｔａｂｌｅｔ）”が格納されている。これは、行４０２２のＵＩアプリを実行するためには、解像度が３２１ピクセル以上、且つ、９００ピクセル以下のタブレット端末であることが要求される。

　サポート機能のフィールドには、機器が備える機能が格納されている。例えば、行４０２１のサポート機能のフィールドには、“機器連携マスター側機能、タッチ操作”が格納されている。これは、行４０２１のＵＩアプリを実行するには、タッチ操作が可能であり、且つ、図１に示すマスター機器１１０１の機能を備える機器であることが要求される。

　また、行４０２２のサポート機能のフィールドには、“機器連携クライアント側機能、タッチ操作”が格納されている。これは、行４０２２のＵＩアプリを実行するには、タッチ操作が可能であり、且つ、図１に示すクライアント機器１２０１の機能を備える機器であることが要求される。

　なお、連携サービス情報は、図４の例に限定されず、実行する連携サービスを決定することができ、且つ、各機器に配信するＵＩアプリを決定できる情報を持つものであれば、どのようなものを採用してもよい。

　図１に戻り、連携サービス決定部１１３２は、連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを決定する。ここで、連携サービス決定部１１３２は、以下に示すサービス決定方法１、２を用いて連携サービスを決定すればよい。

　（サービス決定方法１）
　サービス決定方法１は、接続管理部１１２２がクライアント機器１２０１を決定する前に、連携サービス決定部１１３２が連携サービスを決定する方法である。

　この場合、連携サービス決定部１１３２は、デバイス情報取得部１１２１により取得された１又は複数の周辺機器のデバイス情報と、図４に示す連携サービス情報に規定されたスペック要件と比較し、実行可能な連携サービスを抽出する。そして、連携サービス決定部１１３２は抽出した連携サービスの選択依頼をアプリケーション１１０７（サービスセレクトＵＩ）に行う。アプリケーション１１０７は抽出された連携サービスをユーザに提示し、ユーザに指示された連携サービスを連携サービス決定部１１３２に通知する。そして、連携サービス決定部１１３２は、通知された連携サービスを、実行対象の連携サービスとして決定する。

　具体的には、アプリケーション１１０７は、連携サービス決定部１１３２により抽出された連携サービスの一覧を表示装置（図略）に表示する。そして、アプリケーション１１０７は、操作装置（図略）を操作してユーザに指示された連携サービスを受け付ける。そして、アプリケーション１１０７は、受け付けた連携サービスを連携サービス決定部１１３２に通知する。

　図４の例において、連携サービス決定部１１３２は、行４０２２又は行４０２３のスペック要件を満たすデバイス情報がデバイス情報取得部１１２１により取得された場合、写真交換サービスが実行可能な連携サービスであると判定すればよい。

　そして、接続管理部１１２２は、実行対象の連携サービスのスペック要件と周辺機器のデバイス情報とを比較し、実行対象の連携サービスに使用されるクライアント機器１２０１を決定する。

　図４の例において、写真交換が実行対象の連携サービスとして決定された場合、接続管理部１１２２は、行４０２２又は行４０２３のスペック要件を満たすデバイス情報を持つ周辺機器をクライアント機器１２０１として決定すればよい。

　この場合、接続管理部１１２２は、行４０２２又は行４０２３のスペック要件を満たす周辺機器が複数存在する場合、アプリケーション１１０７を介して周辺機器をユーザに提示し、ユーザにより選択された１又は複数の周辺機器をクライアント機器１２０１として決定してもよい。

　具体的には、接続管理部１１２２は、スペック要件を満たす複数の周辺機器の一覧の表示依頼をアプリケーション１１０７に通知する。そして、アプリケーション１１０７は、複数の周辺機器の一覧を表示装置（図略）に表示する。そして、アプリケーション１１０７は、操作装置（図略）を操作してユーザに指示された周辺機器を受け付ける。そして、アプリケーション１１０７は、受け付けた周辺機器を接続管理部１１２２に通知する。

　サービス決定方法１を用いた場合、まず、周辺機器のスペックから実行可能な連携サービスが抽出される。そして、抽出された連携サービスの中からユーザは実行対象の連携サービスを選択することができる。そのため、ユーザが選択した連携サービスのスペック要件を満たす周辺機器が存在しない事態を防止することができる。その結果、ユーザが選択した連携サービスを実行することができない事態が発生することを回避することができる。

　（サービス決定方法２）
　サービス決定方法２は、まず、接続管理部１１２２がクライアント機器１２０１を決定し、その後、連携サービス決定部１１３２が連携サービスを決定する方法である。

　この場合、接続管理部１１２２は、例えば、周辺機器のデバイス情報をユーザに提示し、ユーザからクライアント機器１２０１を選択する指示を受け付けることで、クライアント機器１２０１を決定する。

　そして、連携サービス決定部１１３２は、クライアント機器１２０１のデバイス情報と連携サービス情報に規定されたスペック要件とを照合し、実行可能な連携サービスを抽出し、抽出した連携サービスを、アプリケーション１１０７（サービスセレクトＵＩ）を介してユーザに提示し、ユーザからの指示に基づき、実行対象の連携サービスを決定する。

　具体的には、連携サービス決定部１１３２は、抽出した連携サービスの一覧の表示依頼をアプリケーション１１０７に通知する。そして、アプリケーション１１０７は、連携サービスの一覧を表示装置（図略）に表示する。そして、アプリケーション１１０７は、操作装置（図略）を操作してユーザに指示された連携サービスを実行対象の連携アプリケーションとして受け付ける。

　なお、連携サービス決定部１１３２は、連携サービス情報をアプリケーション１１０７に通知し、連携サービスの決定をアプリケーション１１０７に委ねてもよい。この場合、アプリケーション１１０７は、連携サービス決定部１１３２と同様にして、サービス決定方法１又はサービス決定方法２を用いて実行対象の連携サービスを決定すればよい。

　配信スクリプト決定部１１３３は、クライアント機器１２０１のデバイス情報と、実行対象の連携サービスのスペック要件とを照合し、クライアント機器１２０１のクライアントＵＩを決定する。ここで、配信スクリプト決定部１１３３は下記のアプリ決定方法１、２を用いてクライアントＵＩを決定すればよい。

　（アプリ決定方法１）
　アプリ決定方法１は、配信スクリプト決定部１１３３自身が、連携サービス情報（図４参照）のスペック要件と、クライアント機器１２０１のデバイス情報とを参照することでクライアントＵＩを決定する方法である。

　図４の例において、ＯＳが“ＯＳ＿Ａ”、解像度が“３２１－９００ｐｘ（tablet）”、サポート機能が“連携クライアント側機能、タッチ操作”のデバイス情報がデバイス情報取得部１１２１により取得されたとする。

　この場合、配信スクリプト決定部１１３３は、このデバイス情報を持つクライアント機器１２０１のクライアントＵＩとして、行４０２２のクライアントＵＩを決定する。

　ここで、あるクライアント機器１２０１につきクライアントＵＩの候補が複数存在したとする。例えば、ＯＳが“ＯＳ＿Ａ”、解像度が“３２１－９００ｐｘ（tablet）”、サポート機能が“機器連携クライアント側機能、タッチ操作”のデバイス情報がデバイス情報取得部１１２１により取得され、このスペック要件を満たすクライアントＵＩが図４において２種類以上記述されていたとする。この場合、このデバイス情報を持つクライアント機器１２０１は複数のクライアントＵＩの候補を持つことになる。

　この場合、配信スクリプト決定部１１３３は、アプリケーション１１０７（マスターＵＩ）にクライアントＵＩの決定依頼を行う。すると、アプリケーション１１０７は、複数のクライアントＵＩの候補をユーザに提示し、ユーザに選択されたクライアントＵＩを配信するクライアントＵＩとして決定してもよい。

　ここで、アプリケーション１１０７は、複数のクライアントＵＩの候補の一覧を表示装置（図略）に表示する。そして、アプリケーション１１０７は、操作装置（図略）を操作してユーザにより指示されたクライアントＵＩをユーザが選択したクライアントＵＩとして決定すればよい。

　なお、アプリケーション１１０７は、複数のクライアントＵＩの候補の中から自身が定める所定の基準に従って１つのクライアントＵＩを決定してもよい。

　所定の基準としては、連携サービスの目的、用途、又は使用するユーザの好み等応じて予め定められた基準を採用すればよい。このように、複数のクライアントＵＩの候補が存在する場合、クライアントＵＩの判定をアプリケーション１１０７に委ねることにより、アプリケーション１１０７の基準に準拠するクライアントＵＩを決定することができ、フレキシブルにクライアントＵＩを決定することができる。

　（アプリ決定方法２）
　アプリ決定方法２は、配信スクリプト決定部１１３３がアプリケーション１１０７（マスターＵＩ）に連携サービス情報を通知し、アプリケーション１１０７に各クライアント機器１２０１のクライアントＵＩの決定を委ねる手法である。この場合、アプリケーション１１０７はアプリ決定方法１にて説明した手法、すなわち、配信スクリプト決定部１１３３がクライアントＵＩを決定する手法と同じ手法を用いてクライアントＵＩを決定すればよい。このように、アプリケーション１１０７にクライアントＵＩの決定を委ねることで、例えば、あるクライアント機器１２０１に対して複数のクライアントＵＩの候補がある場合、アプリケーション１１０７と配信スクリプト決定部１１３３との間でデータを送受することなく、１つのクライアントＵＩを決定することができる。

　スクリプト配信部１１３４は、配信スクリプト決定部１１３３により決定されたクライアントＵＩを各クライアント機器１２０１に配信する。

　具体的には、スクリプト配信部１１３４は、アプリケーション１１０７（サービスセレクトＵＩ又はマスターＵＩ）からの指示を受けて、配信スクリプト決定部１１３３にて決定したスクリプトを各機器に配信する。

　より具体的には、スクリプト配信部１１３４は、アプリケーション１１０７にクライアントＵＩを配信するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を提供し、アプリケーション１１０７から実行対象の連携サービスのＩＤが指定されることより、配信スクリプト決定部１１３３にて決定されたクライアントＵＩを各クライアント機器１２０１に配信する。ここで、スクリプト配信部１１３４は、配信方法１、２を用いてクライアントＵＩを配信する。

　（配信方法１）
　配信方法１は、クライアントＵＩのスクリプトデータをクライアント機器１２０１に配信し、クライアント機器１２０１が備える記憶装置に（ローカル領域）に記憶させる方法である。この場合、クライアントＵＩの起動指示時に、クライアント機器１２０１はローカル領域に記憶したクライアントＵＩを起動することになる。

　（配信方法２）
　配信方法２は、マスター機器１１０１にＨＴＴＰサーバの機能を実行させ、クライアント機器１２０１に、マスター機器１１０１で保持されているクライアントＵＩのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）を送信する方法である。この場合、クライアントＵＩの起動要求時に、クライアント機器１２０１は、マスター機器１１０１に保持されているクライアントＵＩのＵＲＩを指定してクライアントＵＩを起動することになる。

　配信方法１の場合には、例えば、クライアントＵＩのスクリプトデータの送信と併せて、実行対象となる連携サービスのＩＤ及びクライアントＵＩのＩＤをクライアント機器１２０１に送信しておく。すると、クライアント機器１２０１は、クライアントＵＩの起動時に連携サービスのＩＤ及びクライアントＵＩのＩＤを指定することでクライアントＵＩを起動することが可能となる。

　配信方法２の場合には、例えば、以下の３つの配信方法２－１～２－３が採用できる。

　（配信方法２－１）
　スクリプト配信部１１３４は、クライアントＵＩのＵＲＩの送信時に、実行対象の連携サービスのＩＤ、及びクライアントＵＩのＩＤをクライアント機器１２０１に送信しておく。

　そして、連携サービスライフサイクル管理部１１０４は、クライアントＵＩの起動時に、実行対象の連携サービスのＩＤ又は配信したクライアントＵＩのＩＤを指定して、クライアント機器１２０１にクライアントＵＩの起動指示を行う。

　（配信方法２－２）
　スクリプト配信部１１３４は、クライアントＵＩのＵＲＩの送信時に、実行対象の連携サービスのＩＤ、配信するクライアントＵＩのＩＤを送信しないが、連携サービスライフサイクル管理部１１０４が、クライアントＵＩの起動時に、配信するクライアントＵＩのＵＲＩを指定して、クライアント機器１２０１にクライアントＵＩの起動指示を行う。

　（配信方法２－３）
　配信方法２－３は、クライアントＵＩのＵＲＩの送信処理とクライアントＵＩの起動要求とをひとつの処理に統合する方法である。この場合、スクリプト配信部１１３４は、クライアントＵＩのＵＲＩを送信せず、連携サービスライフサイクル管理部１１０４がクライアントＵＩのＵＲＩを指定してクライアント機器１２０１にクライアントＵＩの起動指示を行う。

　ここで、クライアント機器１２０１のスクリプト受信部１２３１が、受信したクライアントＵＩを、連携サービスの実行終了後にも保持する構成をとる場合、スクリプト配信部１１３４は、下記の構成を採用すればよい。

　すなわち、スクリプト配信部１１３４は、クライアント機器１２０１のスクリプト受信部１２３１から保存しているクライアントＵＩのＩＤ及びクライアントＵＩのバージョンを取得し、取得したクライアントＵＩのＩＤ及びバージョンが配信スクリプト決定部１１３３にて決定されたクライアントＵＩのＩＤ及びバージョンと一致しているか否かを判定する。そして、スクリプト配信部１１３４は、クライアントＵＩのＩＤ及びバージョンが一致していないと判定した場合、クライアントＵＩのスクリプトデータを配信するようにすればよい。一方、スクリプト配信部１１３４は、クライアントＵＩのＩＤ及びバージョンが一致していると判定した場合、クライアントＵＩのスクリプトデータを配信しないようにすればよい。

　連携サービスライフサイクル管理部１１０４は、連携サービスを構成するＵＩアプリの実行制御を行う。

　具体的には、連携サービスライフサイクル管理部１１０４は、以下の機能を備える。

　（１）連携サービスライフサイクル管理部１１０４は、マスターＵＩと、各クライアント機器１２０１に配信したクライアントＵＩとを同期起動及び同期終了させる。この場合、連携サービスライフサイクル管理部１１０４は、マスターＵＩから連携サービスのサービスＩＤが指定されて同期起動又は同期終了が指示されると、指定されたサービスＩＤを持つ連携サービスを構成するマスターＵＩとクライアントＵＩとを同期起動又は同期終了させる。

　（２）連携サービスライフサイクル管理部１１０４は、連携サービスを構成するクライアントＵＩを実行するいずれかのクライアント機器１２０１からクライアントＵＩの終了を検知する。

　（３）連携サービスライフサイクル管理部１１０４は、クライアントＵＩを同期起動及び同期終了させるためのＡＰＩ、クライアントＵＩを実行中のクライアント機器１２０１のＩＰアドレスの取得するためのＡＰＩ、及びクライアントＵＩの終了を検知するためのＡＰＩを提供する。

　ここで、連携サービスを構成するＵＩアプリの同期起動は、スクリプト配信部１１３４が配信方法１の方法を用いる場合には、下記の方法を採用すればよい。すなわち、連携サービスライフサイクル管理部１１０４は、ＵＩアプリ実行エンジン１１０６にマスターＵＩのＵＲＩを引き渡して起動指示を行い、且つ、各クライアント機器１２０１のクライアント側ライフサイクル管理部１２０４にクライアントＵＩのＩＤを引き渡して起動指示を行えばよい。

　また、連携サービスを構成するＵＩアプリの同期起動は、スクリプト配信部１１３４が配信方法２の方法を用いる場合には、下記の方法を採用すればよい。すなわち、連携サービスライフサイクル管理部１１０４は、ＵＩアプリ実行エンジン１１０６にマスターＵＩのＵＲＩを引き渡して起動指示を行い、且つ、各クライアント機器１２０１のクライアント側ライフサイクル管理部１２０４にマスター機器１１０１上のクライアントＵＩのＩＤ又はＵＲＩを引き渡して起動指示を行えばよい。

　また、連携サービスを構成するＵＩアプリの同期起動は、スクリプト配信部１１３４が配信方法２－３の方法を採用する場合には、下記の方法を採用すればよい。すなわち、連携サービスライフサイクル管理部１１０４は、ＵＩアプリ実行エンジン１１０６にマスターＵＩのＵＲＩを引き渡して起動指示を行い、且つ、各クライアント機器１２０１のクライアント側ライフサイクル管理部１２０４にマスター機器１１０１上のクライアントＵＩのＵＲＩを引き渡して起動指示を行えばよい。

　連携サービスを構成するＵＩアプリを同期終了させる場合、連携サービスライフサイクル管理部１１０４は、ＵＩアプリ実行エンジン１１０６と、各クライアント機器１２０１のクライアント側ライフサイクル管理部１２０４に終了指示を行えばよい。

　コンテンツ共有部１１０５は、マスター機器１１０１がクライアント機器１２０１と写真や動画等のコンテンツを共有する機能を提供する。コンテンツの共有は、例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ　Ｌｉｖｉｎｇ　Ｎｅｔｗｏｒｋ　Ａｌｌｉａｎｃｅ）のＣｏｎｔｅｎｔ　Ｄｉｒｅｃｔｏｒｙ　Ｓｅｒｖｉｃｅを用いて実現される。

　また、コンテンツ共有部１１０５は、マスター機器１１０１とクライアント機器１２０１との間で、コンテンツリスティング（クライアント機器１２０１のコンテンツをマスター機器１１０１に表示する）、コンテンツのダウンロード（クライアント機器１２０１のコンテンツをマスター機器１１０１にコピーする）、及びコンテンツのアップロード（マスター機器１１０１のコンテンツをクライアント機器１２０１にコピーする）等の機能を実現する。

　ＵＩアプリ実行エンジン１１０６は、マスターＵＩ等のマスター機器１１０１で実行されるＵＩアプリのスクリプトデータの所在であるＵＲＩが指定され、指定されたＵＲＩからマスターＵＩのスクリプトデータをロードしてアプリケーション１１０７を実現する。

　また、ＵＩアプリ実行エンジン１１０６は、例えば、ＨＴＭＬ５に対応するブラウザが提供する描画等のＡＰＩ、及びＰｈｏｎｅＧａｐが提供するＡＰＩをアプリケーション１１０７に提供する。

　アプリケーション１１０７は、ＵＩアプリ実行エンジン１１０６にスクリプトデータがロードされることで実現され、機器接続管理部１１０２、連携サービス構成管理部１１０３、連携サービスライフサイクル管理部１１０４、コンテンツ共有部１１０５、及びＵＩアプリ実行エンジン１１０６が提供するＡＰＩを利用して種々の処理を実行する。本実施の形態では、アプリケーション１１０７を構成するサービスセレクトＵＩ及びマスターＵＩは、ＵＩアプリ実行エンジン１１０６によって起動される。

　ネットワーク通信部１１０８は、例えば、アドホックモード及びインフラストラクチャモードに対応する通信モジュールにより構成され、マスター機器１１０１を構成する各構成要素から送信対象のデータが渡され、渡されたデータをクライアント機器１２０１に送信すると共に、クライアント機器１２０１から送信されるデータを取り込んで、各構成要素に供給する。その他、マスター機器１１０１は、ＤＬＮＡに準拠してデータを送受する機能及びＨＴＴＰサーバを起動する機能を備えている。

　具体的には、マスター機器１１０１は、デバイス情報取得部１１２１、接続管理部１１２２、連携サービス決定部１１３２、配信スクリプト決定部１１３３、スクリプト配信部１１３４、連携サービスライフサイクル管理部１１０４、コンテンツ共有部１１０５、及びＵＩアプリ実行エンジン１１０６から送信対象のデータを取り込む。

　（クライアント機器１２０１の説明）
　クライアント機器１２０１は、クライアント側機器接続管理部１２０２、クライアント側サービス構成管理部１２０３、クライアント側ライフサイクル管理部１２０４、コンテンツ共有部１１０５、ＵＩアプリ実行エンジン１１０６、アプリケーション１２０７、及びネットワーク通信部１２０８を備える。

　クライアント機器１２０１が備えるコンテンツ共有部１１０５及びＵＩアプリ実行エンジン１１０６は、マスター機器１１０１が備えるコンテンツ共有部１１０５及びＵＩアプリ実行エンジン１１０６と同じ機能を備えているため説明を省略する。

　クライアント側機器接続管理部１２０２は、デバイス情報提供部１２２１及びクライアント側接続管理部１２２２を備える。

　デバイス情報提供部１２２１は、マスター機器１１０１のデバイス情報取得部１１２１からの要求に応答して、クライアント機器１２０１のデバイス情報を返す。デバイス情報については、図２を用いて上述した。

　クライアント側接続管理部１２２２は、マスター機器１１０１の接続管理部１１２２からの接続依頼を受けて、アドホックネットワークに接続するか否かを決定し、決定結果をマスター機器１１０１の接続管理部１１２２に応答する。

　ここで、マスター機器１１０１からクライアント機器１２０１への接続依頼及びマスター機器１１０１への応答に関しては、例えば、ＷｉＦｉＤｉｒｅｃｔに規定のプロトコルに従って実現される。また、接続するか否かの決定は、例えば、接続依頼を行ったマスター機器１１０１の情報を表示装置（図略）に表示し、ユーザに接続依頼に同意するか否かを提示し、操作装置（図略）を操作して入力されたユーザの指示に基づき決定すればよい。

　クライアント側サービス構成管理部１２０３は、スクリプト受信部１２３１を備える。

スクリプト受信部１２３１は、マスター機器１１０１のスクリプト配信部１１３４から配信されたクライアントＵＩを受信して記録する。ここで、配信方法１が採用される場合、スクリプト受信部１２３１は、スクリプト配信部１１３４から送信されるクライアントＵＩのスクリプトデータを記録すればよい。

　なお、スクリプト受信部１２３１は、記録したスクリプトデータを連携サービス終了時に削除し、不要なデータを蓄積しないようにしてもよい。

　また、スクリプト受信部１２３１は、マスター機器１１０１のスクリプト配信部１１３４からクライアントＵＩの配信時に、配信予定のクライアントＵＩのＩＤ及びバージョンが、保存しているクライアントＵＩのＩＤ及びバージョンと一致するか否かを判定し、一致している場合のみ、クライアントＵＩを保存する構成としてもよい。

　また、スクリプト受信部１２３１は、マスター機器１１０１のスクリプト配信部１１３４からの問い合わせに応じて、保存しているクライアントＵＩのＩＤ及びバージョンを返答し、スクリプト配信部１１３４に配信予定のクライアントＵＩのＩＤ及びバージョンが、クライアント機器１２０１が保存しているクライアントＵＩのＩＤ及びバージョンと一致しているか否かを判定させる。そして、スクリプト受信部１２３１は、一致していない場合にのみクライアントＵＩを受信するようにしてもよい。

　また、スクリプト受信部１２３１は、マスター機器１１０１のスクリプト配信部１１３４から配信予定のクライアントＵＩのＩＤ及びバージョンを取得し、保存しているクライアントＵＩのＩＤ及びバージョンと一致しているか否かを判定し、一致していない場合にのみクライアントＵＩを受信する構成としてもよい。

　クライアント側ライフサイクル管理部１２０４は、マスター機器１１０１の連携サービスライフサイクル管理部１１０４からのクライアントＵＩの起動指示を受けて、スクリプト配信部１１３４が受信したクライアントＵＩの記録先のＵＲＩをクライアント機器１２０１のＵＩアプリ実行エンジン１１０６に通知し、クライアントＵＩを起動させる。

　ここで、スクリプト受信部１２３１が連携サービス実行後にクライアントＵＩを保存する構成をとる場合、クライアント側ライフサイクル管理部１２０４は下記の構成を採用すればよい。

　すなわち、クライアント側ライフサイクル管理部１２０４は、マスター機器１１０１の連携サービスライフサイクル管理部１１０４から引き渡された連携サービスのサービスＩＤ及びクライアントＵＩのＩＤと、スクリプト受信部１２３１が受信した連携サービスのサービスＩＤ及びクライアントＵＩのＩＤとの一致の有無を判定し、一致したと判定した場合にクライアントＵＩを起動するようにしてもよい。

　また、クライアント側ライフサイクル管理部１２０４は、マスター機器１１０１の連携サービスライフサイクル管理部１１０４からのクライアントＵＩの終了指示を受けると、クライアント機器１２０１のＵＩアプリ実行エンジン１１０６に終了指示を行う。

　また、クライアント側ライフサイクル管理部１２０４は、自機器上でクライアントＵＩを終了させる場合、自機器のＩＰアドレスを引数にして、マスター機器１１０１の連携サービスライフサイクル管理部１１０４に、クライアントＵＩの終了通知を行う。

　アプリケーション１２０７は、クライアント機器１２０１のＵＩアプリ実行エンジン１１０６がクライアントＵＩのスクリプトデータをデコードすることで実現され、クライアント機器１２０１が備えるコンテンツ共有部１１０５及びＵＩアプリ実行エンジン１１０６が提供するＡＰＩを利用して種々の処理を実行する。

　ネットワーク通信部１２０８は、例えば、アドホックモード及びインフラストラクチャモードに対応する通信モジュールにより構成され、クライアント機器１２０１を構成する各構成要素から送信対象のデータが渡され、渡されたデータをクライアント機器１２０１に送信すると共に、マスター機器１１０１から送信されるデータを取り込んで、各構成要素に供給する。その他、クライアント機器１２０１は、ＤＬＮＡに準拠してデータを送受する機能、及びＨＴＴＰクライアントを起動する機能を備えている。以上、本実施の形態におけるマスター機器１１０１、クライアント機器１２０１の構成を説明した。

　なお、図１において、機器接続管理部１１０２、連携サービス構成管理部１１０３、連携サービスライフサイクル管理部１１０４、コンテンツ共有部１１０５、ＵＩアプリ実行エンジン１１０６は、プログラムにより構成され、ＣＰＵに実行されて実現される。

　また、連携サービス構成管理部１１０３を構成する連携サービス情報管理部１１３１は、ハードディスク等の記憶装置と、その記憶装置を制御するプログラムにより構成され、ＣＰＵに実行されて実現される。

　また、ネットワーク通信部１１０８は、通信モジュール及びその通信モジュールを制御するプログラムにより構成され、ＣＰＵに実行されて実現される。また、これらのプログラムは、コンピュータをマスター機器として機能させるマスター機器プログラムとしてハードディスク等の図略の記憶装置に記憶され、ＣＰＵにロードされる。マスター機器プログラムは、例えば、ＤＶＤ－ＲＯＭ等のコンピュータ読取可能な記録媒体に記録されてユーザに提供される。また、このマスター機器プログラムは、ネットワークを介して接続されたサーバに保持させ、ダウンロードさせることでユーザに提供されてもよい。

　また、図１に示すマスター機器１１０１のアプリケーション１１０７以外のブロックを専用のハードウェア回路により構成してもよい。この場合、各ブロックを１つのチップに集積して集積回路としてもよい。

　また、図１において、クライアント側機器接続管理部１２０２、クライアント側サービス構成管理部１２０３、クライアント側ライフサイクル管理部１２０４、コンテンツ共有部１１０５、及びＵＩアプリ実行エンジン１２０６は、プログラムにより構成され、ＣＰＵに実行されて実現される。また、ネットワーク通信部１１０８は、通信モジュール及びその通信モジュールを制御するプログラムにより構成され、ＣＰＵに実行されて実現される。また、これらのプログラムは、コンピュータをクライアント機器として機能させるクライアント機器プログラムとしてハードディスク等の図略の記憶装置に記憶され、ＣＰＵにロードされる。クライアント機器プログラムは、例えば、ＤＶＤ－ＲＯＭ等のコンピュータ読取可能な記録媒体に記録されてユーザに提供される。また、このクライアント機器プログラムは、ネットワークを介して接続されたサーバに保持させ、ダウンロードさせることでユーザに提供されてもよい。

　また、図１に示すマスター機器１１０１のアプリケーション１２０７以外のブロックを専用のハードウェア回路により構成してもよい。この場合、各ブロックを１つのチップに集積して集積回路としてもよい。

　（処理説明）
　以下、本発明の実施の形態１における連携サービス管理システム１００１の処理の流れについて説明する。ここでは、連携サービスの決定、ネットワーク接続の確立、クライアントＵＩの決定、クライアントＵＩの配信、及び連携サービスの実行に関しての処理について説明する。

　図５は、連携サービスの決定、ネットワーク接続の確立、及びクライアントＵＩの決定に関する処理の一例を示すシーケンス図である。

　まず、マスター機器１１０１は、ユーザからの開始指示を受けてスタータを起動させる。ここで、ユーザからの開始指示としては、例えば、図９に示すようにマスター機器１１０１の表示装置（図略）に“機器連携ポータル”のアイコン９００１ａを表示し、ユーザにアイコン９００１ａをタッチさせる指示が採用される。

　例えば、マスター機器１１０１をアンドロイド（登録商標）のアプリケーションとして実現する場合には、スタータはＡｃｔｉｖｉｔｙ　Ｃｌａｓｓに相当する。次に、スタータは、連携サービス決定部１１３２にサービスセレクトＵＩの起動を要求する（Ｓ５００１）。

　次に、連携サービス決定部１１３２は、連携サービス情報管理部１１３１が管理するサービスセレクトＵＩのＵＲＩを取得し（Ｓ５００２）、ＵＩアプリ実行エンジン１１０６にＵＲＩを指定してサービスセレクトＵＩの起動指示を行う（Ｓ５００３）。これにより、ＵＩアプリ実行エンジン１１０６は、指定されたＵＲＩからサービスセレクトＵＩのスクリプトデータを読み出し、アプリケーション１１０７としてサービスセレクトＵＩを起動させる。

　次に、サービスセレクトＵＩは、連携サービス情報管理部１１３１がアプリケーション１１０７に提供するＡＰＩを利用して、連携サービス情報管理部１１３１に連携サービス情報の取得を要求し（Ｓ５００４）、連携サービス情報を取得する。

　次に、サービスセレクトＵＩは、機器接続管理部１１０２が提供するＡＰＩを利用して、機器接続管理部１１０２を介して周辺機器のデバイス情報を取得する（Ｓ５００５）。次に、サービスセレクトＵＩは、取得したデバイス情報と連携サービス情報とを照合し、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、実行対象の連携サービスを決定する（Ｓ５００５Ａ）。

　この場合、サービスセレクトＵＩは、図１０（Ａ）、（Ｂ）に示すように抽出した連携サービスをマスター機器１１０１のディスプレイに一覧表示し、いずれかの連携サービスをユーザにタッチさせることで、連携サービスを決定すればよい。

　図１０（Ａ）の例では、マスター機器１１０１のディスプレイには“動画再生”及び“写真交換”の連携サービスを示すアイコン１０１１ａ，１０１１ｂが一覧表示されている。また、図１０（Ｂ）の例では、“動画再生”、“写真交換”、及び“旅行計画”の連携サービスを示すアイコン１０１３ａ～１０１３ｃが一覧表示されている。これらのアイコンの中からユーザは希望する連携サービスのアイコンをタッチすることで、連携サービスを選択する。

　次に、サービスセレクトＵＩは、実行対象の連携サービスのサービスＩＤを連携サービス決定部１１３２に通知する（Ｓ５００６）。

　次に、連携サービス決定部１１３２は、連携サービス情報管理部１１３１が管理する連携サービス情報の中から、実行対象の連携サービスのＵＩアプリリスト４００２を参照し、ＵＩ種別が“Ｍａｓｔｅｒ＿ＵＩ”のＵＲＩを取得する（Ｓ５００７）。図４の例において実行対象の連携サービスが“写真交換”である場合、ファイルパスに格納された“Ｓ００１／Ｖ０３／ＡＰＰ０１ｍａｓｔｅｒ＿ｉｎｄｅｘ．ｈｔｍｌ”がＵＲＩとして取得される。

　ここで、連携サービス決定部１１３２は、マスター機器１１０１のデバイス情報が、実行対象の連携サービスのスペック要件を満たしていない場合、選択した連携サービスは実行できない情報を表示装置（図略）に表示してユーザに選択した連携サービスは実行できないことを提示する。そして、連携サービス決定部１１３２は、連携サービスの実行を停止すればよい。

　次に、連携サービス決定部１１３２は、ＵＩアプリ実行エンジン１１０６に取得したＵＲＩを指定してマスターＵＩの起動指示を行う（Ｓ５００８）。これにより、ＵＩアプリ実行エンジン１１０６は、指定されたＵＲＩからマスターＵＩのスクリプトデータを読み出し、アプリケーション１１０７としてマスターＵＩを起動させる。

　次に、マスターＵＩは、連携サービス情報管理部１１３１がアプリケーション１１０７に提供するＡＰＩを利用して、連携サービス情報管理部１１３１から実行対象の連携サービスのＵＩアプリリスト４００２を取得する（Ｓ５００９）。

　次に、マスターＵＩは、機器接続管理部１１０２が提供するＡＰＩを利用して、周辺機器のデバイス情報を機器接続管理部１１０２を介して取得する（Ｓ５０１０、Ｓ５０１１）。

　次に、マスターＵＩは、デバイス情報とＵＩアプリリスト４００２とを照合して、接続依頼を行うクライアント機器１２０１を決定する（Ｓ５０１１Ａ）。例えば、図４に示すＵＩアプリリスト４００２が取得されたとすると、行４０２２又は行４０２３のスペック要件を満たす周辺機器がクライアント機器１２０１として決定される。

　ここで、マスターＵＩは、スペック要件を満たす周辺機器の一覧を表示装置（図略）に表示することでユーザに問い合わせる。そして、マスターＵＩは、ネットワーク接続を確立させる周辺機器として操作装置（図略）を操作してユーザにより指定された周辺機器をクライアント機器１２０１として決定してもよい。

　次に、マスターＵＩは、機器接続管理部１１０２がアプリケーション１１０７に提供するＡＰＩを利用して、機器接続管理部１１０２にクライアント機器１２０１への接続依頼を要求する（Ｓ５０１２）。

　マスターＵＩから接続依頼の要求を受けた機器接続管理部１１０２は、クライアント側機器接続管理部１２０２に、接続依頼を行う（Ｓ５０１３）。クライアント側機器接続管理部１２０２は、マスター機器１１０１から接続依頼があったことを示す情報を表示装置（図略）に表示して、接続依頼があったことをユーザに提示する。そして、クライアント側機器接続管理部１２０２は、接続依頼に同意するか否かの指示をユーザから受け付け、指示結果を接続管理部１１２２に返答する（Ｓ５０１３Ａ）。

　この場合、クライアント側機器接続管理部１２０２はクライアント機器１２０１の表示装置（図略）に、接続依頼を行ったマスター機器１１０１の例えばユーザ名などを表示して、接続依頼があったことをユーザに提示すると共に、同意ボタン及び拒否ボタンを表示装置（図略）に表示し、同意ボタン又は拒否ボタンをユーザにタッチさせることで、接続依頼に同意するか否かをユーザに入力させればよい。

　返答を受けた機器接続管理部１１０２は、接続依頼に同意する指示結果を受けた場合は、この指示結果を送信したクライアント機器１２０１のデバイス情報及びＩＰアドレスをマスターＵＩに渡す（Ｓ５０１３Ｂ）。

　次に、マスターＵＩは、実行対象の連携サービスのサービスＩＤと、ネットワーク接続を確立したクライアント機器１２０１のＩＰアドレスリストとを指定して、連携サービス決定部１１３２にクライアントＵＩの決定依頼を行う（Ｓ５０１４）。

　次に、連携サービス決定部１１３２は、実行対象の連携サービスのＵＩアプリリスト４００２を連携サービス情報管理部１１３１から取得する（Ｓ５０１５）。

　次に、配信スクリプト決定部１１３３は、各クライアント機器１２０１のデバイス情報と連携サービス情報のスペック要件とを照合し、各クライアント機器１２０１に配信するクライアントＵＩを決定する（Ｓ５０１６）。

　次に、配信スクリプト決定部１１３３は、あるクライアント機器１２０１において、クライアントＵＩの候補が複数存在し、クライアントＵＩを一意に決定することができない場合、クライアントＵＩの候補を指定し、マスターＵＩにクライアントＵＩを決定するように問い合わせる（Ｓ５０１７）。この問い合わせを受けたマスターＵＩは、問い合わせのあったクライアント機器１２０１のクライアントＵＩの候補の中から、このクライアント機器１２０１に適したクライアントＵＩを決定し、決定結果を配信スクリプト決定部１１３３に通知する。

　このシーケンス図では、配信スクリプト決定部１１３３がクライアントＵＩを決定したが、これに限定されず、マスターＵＩがＵＩアプリリスト４００２及び各クライアント機器１２０１のデバイス情報を照合して、各クライアント機器１２０１のクライアントＵＩを決定してもよい。

　次に、配信スクリプト決定部１１３３は、各クライアント機器１２０１のクライアントＵＩを最終決定し（Ｓ５０１８）、決定通知をマスターＵＩに行う（Ｓ５０１９）。なお、Ｓ５０１６において、配信スクリプト決定部１１３３が各クライアント機器１２０１のクライアントＵＩを一意に決定することができた場合は、Ｓ５０１７において、配信スクリプト決定部１１３３は、マスターＵＩに決定通知を行えばよい。

　ここで、図５に示したシーケンス図ではサービスセレクトＵＩが連携サービスを決定し、マスターＵＩを起動した後に、マスターＵＩが、ネットワーク接続の確立とクライアントＵＩの決定依頼を行う順序であったが、本発明はこれに限定されない。すなわち、サービスセレクトＵＩがネットワーク接続の確立と、連携サービスの決定を行い、マスターＵＩを起動させる。その後、マスターＵＩが、クライアント機器１２０１のＩＰアドレスリストを指定したクライアントＵＩの決定依頼を配信スクリプト決定部１１３３に行う順序にしてもよい。

　図６は、図５に続くシーケンス図であり、上記の配信方法１を採用した場合のシーケンス図である。まず、マスターＵＩは、スクリプト配信部１１３４が提供するＡＰＩを利用して、クライアント機器１２０１のＩＰアドレスリスト、実行対象の連携サービスのサービスＩＤ、及びクライアントＵＩのＩＤを指定し、配信依頼をスクリプト配信部１１３４に行う（Ｓ６００１）。

　次に、スクリプト配信部１１３４は、各クライアント機器１２０１に配信するクライアントＵＩのスクリプトデータを連携サービス決定部１１３２から取得する（Ｓ６００２）。

　次に、スクリプト配信部１１３４は、各クライアント機器１２０１のスクリプト受信部１２３１に、クライアントＵＩのスクリプトデータ、クライアントＵＩのＩＤ、及び実行対象の連携サービスのサービスＩＤ等の情報を配信する（Ｓ６００３）。

　次に、スクリプト受信部１２３１は、受信したクライアントＵＩのスクリプトデータ、サービスＩＤ、及びクライアントＵＩのＩＤ等の情報を記録する（Ｓ６００４）。ここで、Ｓ６００４において、スクリプト受信部１２３１は、クライアント機器１２０１のキャッシュ領域にクライアントＵＩのスクリプトデータをキャッシュしてもよいし、クライアント機器１２０１のパーシステント領域にクライアントＵＩのスクリプトデータをインストールしてもよい。

　次に、スクリプト受信部１２３１は、スクリプトデータの記録終了通知をスクリプト配信部１１３４を介してマスターＵＩに行う（Ｓ６００４Ａ）。

　次に、マスターＵＩは、連携サービスライフサイクル管理部１１０４が提供するＡＰＩを利用して、実行対象の連携サービスの起動依頼を連携サービスライフサイクル管理部１１０４に行う（Ｓ６００５）。この起動依頼には、各クライアント機器１２０１のＩＰアドレスリストが含まれている。

　次に、マスターＵＩから起動依頼を受けた連携サービスライフサイクル管理部１１０４は、クライアント側ライフサイクル管理部１２０４に、実行対象の連携サービスのサービスＩＤ、クライアントＵＩのＩＤ、及び各クライアント機器１２０１のＩＰアドレスリストを通知し、クライアントＵＩの起動依頼を行う（Ｓ６００６）。

　次に、クライアント側ライフサイクル管理部１２０４は、サービスＩＤとクライアントＵＩのＩＤとを指定して、スクリプトデータが記録されたクライアントＵＩの所在であるローカルＵＲＩをスクリプト受信部１２３１から取得する（Ｓ６００７）。

　次に、クライアント側ライフサイクル管理部１２０４は、ローカルＵＲＩを指定してクライアントＵＩの起動依頼をＵＩアプリ実行エンジン１１０６に行う（Ｓ６００８）。次に、ＵＩアプリ実行エンジン１１０６は、ローカルＵＲＩからクライアントＵＩのスクリプトデータを読み出し、クライアントＵＩを起動する（Ｓ６００９）。これにより、マスター機器１１０１とクライアント機器１２０１とでＵＩアプリが同期して起動される。

　Ｓ６０１０～Ｓ６０１５は、マスター機器１１０１が連携サービスを終了させる際の処理を示している。まず、マスターＵＩは、クライアント機器１２０１のＩＰアドレスを指定し、終了依頼を連携サービスライフサイクル管理部１１０４に行う（Ｓ６０１０）。

　次に、連携サービスライフサイクル管理部１１０４は、終了対象となる連携サービスのサービスＩＤとクライアントＵＩのＩＤとを指定した終了依頼をクライアント側ライフサイクル管理部１２０４に行う（Ｓ６０１１）。

　次に、クライアント側ライフサイクル管理部１２０４は、スクリプト受信部１２３１から、起動中のクライアントＵＩのローカルＵＲＩを取得する（Ｓ６０１２）。次に、クライアント側ライフサイクル管理部１２０４は、ＵＩアプリ実行エンジン１１０６に起動中のクライアントＵＩの終了依依頼を行う（Ｓ６０１３）。これにより、ＵＩアプリ実行エンジン１１０６は、起動中のクライアントＵＩを終了する。次に、クライアント側ライフサイクル管理部１２０４は、クライアント機器１２０１（自身）のＩＰアドレスを指定した終了通知を連携サービスライフサイクル管理部１１０４に行う。次に、終了通知を受けた連携サービスライフサイクル管理部１１０４は、クライアント機器１２０１のＩＰアドレスを指定した終了通知をマスターＵＩに行う（Ｓ６０１５）。

　図７は、図５に続くシーケンス図であり、上記の配信方法２を採用した場合のシーケンス図である。まず、マスターＵＩは、スクリプト配信部１１３４が提供するＡＰＩを利用して、クライアント機器１２０１のＩＰアドレスリスト、実行対象の連携サービスのサービスＩＤ、及びクライアントＵＩのＩＤを指定した配信依頼をスクリプト配信部１１３４に行う（Ｓ７００１）。

　次に、スクリプト配信部１１３４は、各クライアント機器１２０１に配信するクライアントＵＩのＵＲＩを連携サービス決定部１１３２から取得する（Ｓ７００２）。このＵＲＩは、マスター機器１１０１が保持するクライアントＵＩのスクリプトデータのＵＲＩである。

　次に、スクリプト配信部１１３４は、取得したクライアントＵＩのＵＲＩ、クライアントＵＩのＩＤ、及び実行対象の連携サービスのサービスＩＤ等の情報をクライアント機器１２０１のスクリプト受信部１２３１に配信する（Ｓ７００３）。ここで、クライアントＵＩのスクリプトデータではなく、ＵＲＩがクライアント機器１２０１に送信されている点が、図６との相違点である。

　次に、スクリプト受信部１２３１は、受信したＵＲＩ、サービスＩＤ、及びクライアントＵＩのＩＤ等の情報を保持する。（Ｓ７００４）。

　次に、スクリプト受信部１２３１は、ＵＲＩ、サービスＩＤ、及びクライアントＵＩのＩＤ等の情報を保持したことを通知するための保持通知をスクリプト配信部１１３４を介してマスターＵＩに行う（Ｓ７００３Ａ）。

　次に、マスターＵＩは、連携サービスライフサイクル管理部１１０４が提供するＡＰＩを利用して、実行対象の連携サービスの起動依頼を連携サービスライフサイクル管理部１１０４に行う（Ｓ７００５）。この起動依頼には各クライアント機器１２０１のＩＰアドレスリストが含まれている。

　次に、マスターＵＩから起動依頼を受けた連携サービスライフサイクル管理部１１０４は、クライアント側ライフサイクル管理部１２０４に、サービスＩＤ、クライアントＵＩのＩＤ、及び各クライアント機器１２０１のＩＰアドレスリストを通知し、クライアントＵＩの起動依頼を行う（Ｓ７００６）。

　次に、クライアント側ライフサイクル管理部１２０４は、サービスＩＤとクライアントＵＩのＩＤとを指定して、マスター機器１１０１上のクライアントＵＩのＵＲＩをスクリプト受信部１２３１から取得する（Ｓ７００７）。

　次に、クライアント側ライフサイクル管理部１２０４は、クライアントＵＩのＵＲＩを指定し、クライアントＵＩの起動依頼をＵＩアプリ実行エンジン１１０６に行う（Ｓ７００８）。次に、ＵＩアプリ実行エンジン１１０６は、クライアントＵＩのＵＲＩを指定し、クライアントＵＩのロード依頼をスクリプト配信部１１３４に行う（Ｓ７０１０）。これにより、マスター機器１１０１に格納されたクライアントＵＩのスクリプトデータがネットワーク経由でクライアント機器１２０１にロードされる。そして、ＵＩアプリ実行エンジン１１０６はロードされたクライアントＵＩのスクリプトデータをデコードして、クライアントＵＩを実行する。これにより、マスター機器１１０１とクライアント機器１２０１とでＵＩアプリが同期して起動する。

　Ｓ７０１１～Ｓ７０１６は、マスター機器１１０１が連携サービスを終了する際の処理であり、図６のＳ６０１１～Ｓ６０１６と同じであるため説明を省く。

　図８は、マスター機器１１０１において、ユーザがネットワークを選択する際に表示装置に表示される画面遷移の一例を示す図である。まず、表示装置には、種々の項目を設定するためのアイコン８００２が表示された画面８００１が表示される。アイコン８００２がユーザによりタッチされると、表示装置には画面８００４が表示される。

　画面８００４には、ネットワーク設定と表示されたアイコン８００３が表示されている。ユーザによりアイコン８００３がタッチされると、伝送路を選択するための画面８００５がディスプレイ（表示装置）に表示される。画面８００５には、ＷｉＦｉＤｉｒｅｃｔと表示されたアイコン８００６とＷｉＦｉと表示されたアイコン８００７とが表示されている。アイコン８００６がユーザによりタッチされると、マスター機器１１０１は通信路としてアドホックネットワークを選択する。一方、アイコン８００７がユーザによりタッチされると、マスター機器１１０１は、通信路として、アクセスポイントを介したネットワークを選択する。

　マスター機器１１０１は、通信路としてアドホックネットワークを選択すると、周辺機器を検索し、周辺機器に対してネットワーク接続を確立するための接続依頼（invitation）を行う。一方、マスター機器１１０１は、通信路としてアクセスポイントを介したネットワークを選択すると、アクセスポイントとネットワーク接続を確立し、アクセスポイントを介して他の機器と通信する。

　図９は、マスター機器１１０１において、連携サービスを開始する際にディスプレイに表示される画面遷移の一例を示した図である。まず、ユーザにより連携サービスの開始の指示が入力されると、画面９００１が表示される。画面９００１には、機器連携ポータルと記載されたアイコン９００１ａが表示されている。アイコン９００１ａがタッチされると、画面９００２がディスプレイに表示される。

　画面９００２は、図８の画面８００５と同様、伝送路を設定するための画面である。画面９００２において、ＷｉＦｉＤｉｒｅｃｔと記載されたアイコン９００２ａがユーザによりタッチされると、現在、ＷｉＦｉのネットワークに接続中であれば、伝送路をＷｉＦｉＤｉｒｅｃｔへ切り替えてよいか否かを確認するための画面９００３がディスプレイに表示される。

　一方、現在、ＷｉＦｉのネットワークに接続中でなければ、周辺機器を再検索するための画面９００７がディスプレイに表示される。

　画面９００３において、ＯＫと記載されたアイコン９００３ａがユーザにタッチされると、周辺機器が検索され、検索された周辺機器を一覧表示する画面９００４がディスプレイに表示される。画面９００４の例では、Ａ～Ｃの３台の機器が周辺機器として検索され、ディスプレイに表示されている。

　一方、画面９００３において、ｃａｎｃｅｌと記載されたアイコン９００３ｂがユーザにタッチされると、画面９００２がディスプレイに再度表示される。

　画面９００４において、ユーザにより周辺機器のうち、ネットワーク接続を確立させる機器、つまり、クライアント機器１２０１が選択され、“選択した機器を接続”と記載されたアイコン９００４ａがタッチされる。画面９００４の例では、ユーザによりＡ～Ｃの機器がクライアント機器１２０１としてユーザに選択されている。

　すると、選択されたクライアント機器１２０１に対して接続依頼が送信される。このとき、ディスプレイには、クライアント機器１２０１に接続依頼を送信していることを示す画面９００５が表示される。

　次に、ディスプレイにはネットワーク接続が確立されたクライアント機器１２０１が一覧表示された画面９００６が表示される。画面９００６の例では、Ａ～Ｃの３台のクライアント機器１２０１から、接続依頼に同意する旨の返答を受けたため、Ａ～Ｃの３台のクライアント機器１２０１が一覧表示されている。

　画面９００６において、ユーザにより確定と記載されたアイコン９００６ａがタッチされると、マスター機器１１０１とＡ～Ｃの３台のクライアント機器１２０１との間で連携サービスが実行される。

　画面９００７において、現在、Ａ、Ｂの２台の機器とネットワーク接続が既に確立されていることが示されている。再検索と記載されたアイコン９００７ａがユーザによりタッチされると、マスター機器１１０１は周辺機器を再検索し、ディスプレイには検索結果を示す画面９００８が表示される。

　画面９００８では、新たにＣが周辺機器として検索されたことが示されている。画面９００８において、ユーザによりＣがクライアント機器として選択され、“選択した機器を接続”と記載されたアイコン９００８ａがタッチされると、Ｃの機器に対して接続依頼を送信中であることを示す画面９００９がディスプレイに表示される。

　そして、Ｃのクライアント機器１２０１から接続依頼に同意する返答を受けると、既にネットワーク接続が確立されているＡ、Ｂのクライアント機器１２０１に加えて更に、Ｃのクライアント機器１２０１とネットワーク接続が確立されたことを示す画面９０１０がディスプレイに表示される。

　画面９０１０において、ユーザにより確定と記載されたアイコン９０１０ａがタッチされると、マスター機器１１０１とＡ～Ｃの３台のクライアント機器１２０１との間で連携サービスが実行される。

　画面９００２において、ＷｉＦｉと記載されたアイコン９００２ｂがユーザによりタッチされると、ＷｉＦｉによって既にネットワーク接続が確立されている機器を表示する画面９０１１がディスプレイに表示される。画面９０１１において、確定と記載されたアイコン９０１１ａがタッチされると、Ａ、Ｂの機器とマスター機器１１０１との間でアクセスポイントを介した通信が行われる。

　図１０（Ａ）、（Ｂ）は、マスター機器１１０１において、ユーザが連携サービスを選択する際にディスプレイに表示される画面遷移の一例を示した図である。図１０（Ａ）はクライアント機器１２０１としてＡ、Ｂの２台の機器が存在する場合を示し、図１０（Ｂ）はクライアント機器１２０１としてＡ～Ｃの３台の機器が存在する場合を示している。

　図１０（Ａ）の画面１０１０では、クライアント機器１２０１としてＡ、Ｂの２台の機器が一覧表示されている。画面１０１０において、ユーザにより確定と記載されたアイコン１０１０ａがタッチされると、ディスプレイには画面１０１１が表示される。

　画面１０１１には、Ａ、Ｂのクライアント機器１２０１で実行可能な連携サービスが一覧表示され、且つ、各連携サービスを実行する際に使用するクライアント機器１２０１が表示されている。画面１０１１の例では、動画再生と記載されたアイコン１０１１ａと、写真交換と記載されたアイコン１０１１ｂとが表示されている。また、アイコン１０１１ａの横にはＡと記載されたアイコンが表示され、動画再生の連携サービスを実行する場合、Ａのクライアント機器１２０１が使用されることが示されている。また、写真交換と記載されたアイコン１０１１ｂの横にはＢと記載されたアイコンが表示され、写真交換の連携サービスを実行する場合、Ｂのクライアント機器１２０１が使用されることが示されている。

　画面１０１１の例では、ユーザによりアイコン１０１１ｂがタッチされ、写真交換の連携サービスがユーザにより選択されている。したがって、マスター機器１１０１は、写真交換の連携サービスを実行するにあたりＢのクライアント機器１２０１で必要なクライアントＵＩを決定し、Ｂのクライアント機器１２０１に決定したクライアントＵＩを配信する。

　一方、画面１０１１において、ユーザにより動画再生が選択されると、動画再生の連携サービスを実行するにあたりＡのクライアント機器１２０１で必要なクライアントＵＩが決定され、Ａのクライアント機器１２０１に決定したクライアントＵＩが配信される。

　図１０（Ｂ）に示す画面１０１２では、マスター機器１１０１はＡ～Ｃの３台のクライアント機器１２０１とネットワーク接続を確立しているため、Ａ～Ｃの３台のクライアント機器１２０１が一覧表示されている。

　図１０（Ｂ）において、確定と記載されたアイコン１０１２ａがユーザによりタッチされると、画面１０１３が表示される。画面１０１３の例では、Ａ～Ｃのクライアント機器１２０１で実行可能な動画再生、写真交換、及び旅行計画の３つの連携サービスが一覧表示されている。

　そして、画面１０１３の例では、旅行計画と記載されたアイコン１０１３ｃがユーザによりタッチされている。したがって、旅行計画の連携サービスを実行するにあたり、Ａ、Ｃのクライアント機器１２０１で必要となるクライアントＵＩが決定され、Ａ、Ｃの２台のクライアント機器１２０１のそれぞれに決定されたクライアントＵＩが配信される。

　以上、実施の形態１による連携サービス管理システム１００１によれば、アクセスポイントがない環境下で、周辺にあるクライアント機器１２０１とアドホックネットワークが構築され、ネットワーク接続が確立されたクライアント機器１２０１のスペック要件を満たすクライアントＵＩがクライアント機器１２０１に配信される。そのため、アクセスポイントがない環境下においてもアドホックネットワークを用いた連携サービスを実現することができる。

　（実施の形態２）
　実施の形態１においては、連携サービス構成管理部１１０３において連携サービス情報が管理されていたが、本実施の形態では、アプリケーション１１１０７において連携サービス情報を管理し、この連携サービス情報を用いてクライアントＵＩを決定することを特徴とする。

　図１１は、本発明の実施の形態２における連携サービス管理システム１１００１の一例を示す機能ブロック図である。

　図１１において、図１と同じ構成要素については同じ符号を用い、説明を省略する。実施の形態２における連携サービス管理システム１１００１は、マスター機器１１１０１及びクライアント機器１２０１を備える。以下、実施の形態２におけるマスター機器１１１０１について説明する。

　（マスター機器１１１０１の説明）
　マスター機器１１１０１は、機器接続管理部１１０２、連携サービス構成管理部１１１０３、連携サービスライフサイクル管理部１１０４、コンテンツ共有部１１０５、ＵＩアプリ実行エンジン１１０６、アプリケーション１１１０７、及びネットワーク通信部１１０８を備える。

　連携サービス構成管理部１１１０３は、スクリプト配信部１１１３１を備える。スクリプト配信部１１１３１は、アプリケーション１１１０７の配信スクリプト決定部１１１７３が決定したクライアントＵＩを各クライアント機器１２０１に配信する。

　また、スクリプト配信部１１１３１は、アプリケーション１１１０７にクライアントＵＩを配信するためのインターフェイス（ＩＦ）を提供し、アプリケーション１１１０７からクライアント機器１２０１のＩＰアドレスリストと、各クライアント機器１２０１に配信するクライアントＵＩとが指定され、クライアントＵＩを各クライアント機器１２０１に配信する。

　なお、スクリプト配信部１１１３１は、実施の形態１で説明した配信方法１又は配信方法２を用いてクライアントＵＩをクライアント機器１２０１に配信すればよい。

　アプリケーション１１１０７は、連携サービス情報管理部１１１７１、連携サービス決定部１１１７２、及び配信スクリプト決定部１１１７３を備える。実施の形態１では、連携サービス情報管理部１１３１、連携サービス決定部１１３２、及び配信スクリプト決定部１１３３は、連携サービス構成管理部１１０３が備えていた。実施の形態２では、アプリケーション１１１０７が連携サービス情報管理部１１１７１、連携サービス決定部１１１７２、及び配信スクリプト決定部１１１７３を備えている。

　連携サービス情報管理部１１１７１は、連携サービス情報を管理する。実施の形態１の連携サービス情報管理部１１３１との相違は、連携サービス情報管理部１１１７１は、連携サービス情報を独自に管理している点にある。

　例えば、連携サービス情報管理部１１１７１は、ディスプレイに連携サービスの一覧を表示して、ユーザに連携サービスを決定させるためのＵＩを実現するためのディスクリプションデータを管理しており、このＵＩを用いてユーザに連携サービスを決定させる。例えば、連携サービス情報管理部１１１７１は、図４に示すＵＩアプリリスト４００２のスペック要件として、独自に管理するスペック要件を採用する。

　また、連携サービス情報管理部１１１７１は、ユーザの趣味等を予め入力させ、図４に示す連携サービスリスト４００１において、ユーザの趣味に合わない連携サービスを削除するようにしてもよい。また、連携サービス情報管理部１１１７１は、ユーザの年齢や性別等を予め入力させ、図４に示す連携サービスリスト４００１において、ユーザの年齢や性別等に適していない連携サービスを削除するようにしてもよい。

　また、連携サービス情報管理部１１１７１は、ユーザに好みのメーカや機種を入力させ、図４に示すＵＩアプリリスト４００２において、ユーザの好みのメーカや機種以外のＵＩアプリを削除するようにしてもよい。こうすることで、ユーザは、好みのメーカや機種をクライアント機器１２０１として連携サービスを行うことができる。

　このように、連携サービス情報の管理をアプリケーション１１１０７側に委ねることで、図４に示す連携サービス情報をアプリケーション１１１０７の用途や目的に適した連携サービス情報にカスタマイズすることができ、この連携サービス情報を用いてクライアントＵＩを決定することができる。

　なお、連携サービス情報管理部１１１７１、連携サービス決定部１１１７２、及び配信スクリプト決定部１１１７３は、アプリケーション１１１０７で起動されたマスターＵＩ又はイニシャル（Ｉｎｉｔｉａｌ　ＵＩ）により実現される。

　以下、本発明の実施の形態２における種々の用語について説明する。連携サービス、ＵＩアプリ、及びクライアントＵＩについては実施の形態１と同じである。マスターＵＩは、機能については実施の形態１と同じであるが、本実施の形態ではイニシャルＵＩによって起動される点が実施の形態１とは異なる。

　イニシャルＵＩは、マスター機器１１１０１により最初に起動される。そして、イニシャルＵＩは複数の連携サービスの中から、ユーザの指示に基づき、一つの連携サービスを決定し、決定した連携サービスを構成するマスターＵＩを起動する。

　図１２は、本発明の実施の形態２における連携サービスの構成の一例を示す模式図である。マスター機器１１１０１は、一つのイニシャルＵＩを管理し、最初にイニシャルＵＩを起動する。イニシャルＵＩは連携サービスを選択し、連携サービスを構成するマスターＵＩを起動する。図１２では、マスター機器１１１０１は、２つの連携サービス１２００１、１２００２を備えている。連携サービス１２００１は、マスター機器１１１０１と２つのクライアント機器１２０１とで行われる連携サービスである。連携サービス１２００２は、マスター機器１１１０１と１つのクライアント機器１２０１とで行われる連携サービスである。

　例えば、イニシャルＵＩが連携サービス１２００１を選択したとすると、連携サービス１２００１のマスターＵＩが起動される。一方、マスターＵＩが連携サービス１２００２を選択したとすると、連携サービス１２００２のマスターＵＩが起動される。

　図１１に戻り、連携サービス決定部１１１７２は、連携サービス決定部１１３２と同様、連携サービス情報管理部１１１７１が管理する連携サービス情報にしたがって、実行対象の連携サービスを決定する。

　配信スクリプト決定部１１１７３は、配信スクリプト決定部１１３３と同様、連携サービス情報管理部１１１７１により管理されている連携サービス情報にしたがって、各クライアント機器１２０１に配信するクライアントＵＩを決定する。

　なお、図１１に示すマスター機器１１１０１のアプリケーション１１１０７以外の各ブロックを、実施の形態１と同様、マスター機器プログラム、専用のハードウェア回路、或いは集積回路で構成してもよい。また、クライアント機器１２０１も実施の形態１と同様、クライアント機器プログラム、専用のハードウェア回路、或いは集積回路で構成してもよい。

　（処理説明）
　以下に、本発明の実施の形態２における連携サービス管理システム１１００１の処理の流れの一例を説明する。ここでは、連携サービスの決定、ネットワーク接続の確立、クライアントＵＩの決定、クライアントＵＩの配信、及び連携サービスの実行に関する処理について説明する。

　図１３は、連携サービスの決定、ネットワーク接続の確立、及びクライアントＵＩの決定に関する処理の一例を示すシーケンス図である。

　まず、マスター機器１１１０１は、ユーザからの開始指示を受けてスタータ（Ｓｔａｒｔｅｒ）を起動し、処理を開始する。ここで、ユーザからの開始指示は、例えば、図９に示すようにマスター機器１１１０１のディスプレイに“機器連携ポータル”のアイコン９００１ａを表示し、ユーザにアイコン９００１ａをタッチさせる指示が採用される。

　次に、スタータは、ＵＩアプリ実行エンジン１１０６にＵＲＩを指定してイニシャルＵＩの起動指示を行う。これにより、アプリケーション１１１０７としてイニシャルＵＩが起動される（Ｓ１３００１）。

　起動したイニシャルＵＩは、機器接続管理部１１０２が提供するＡＰＩを利用して、周辺機器のデバイス情報を取得する（Ｓ１３００２、Ｓ１３００３）。

　次に、イニシャルＵＩが備える連携サービス情報管理部１１１７１は、自身が管理する連携サービス情報と、取得したデバイス情報とを参照して、接続依頼を行うクライアント機器１２０１を決定し、機器接続管理部１１０２がアプリケーション１１１０７に提供するＡＰＩを利用して、クライアント機器１２０１に接続依頼要求を行う（Ｓ１３００４）。

　イニシャルＵＩからの接続依頼要求を受けた機器接続管理部１１０２は、クライアント機器１２０１のクライアント側機器接続管理部１２０２に、接続依頼を行う（Ｓ１３００５）。クライアント側機器接続管理部１２０２は、接続するか否かの判断を行い、マスター機器１１１０１の機器接続管理部１１０２に返答する。ここで、クライアント側機器接続管理部１２０２は、ユーザからの指示に基づき、接続するか否かを判断する。

　次に、機器接続管理部１１０２は、イニシャルＵＩにネットワーク接続を確立したクライアント機器１２０１のＩＰアドレス及びデバイス情報を返す。

　次に、イニシャルＵＩが備える連携サービス決定部１１１７２は、機器接続管理部１１０２が提供するＡＰＩを利用して、クライアント機器１２０１のデバイス情報を取得する（Ｓ１３００６）。

　次に、イニシャルＵＩが備える連携サービス決定部１１１７２は、連携サービス情報管理部１１１７１が管理する連携サービス情報とデバイス情報とを照合し、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、実行対象の連携サービスを決定する（Ｓ１３００７）。

　この場合、イニシャルＵＩが備える連携サービス決定部１１１７２は、図１０に示すように抽出した連携サービスをマスター機器１１０１のディスプレイに一覧表示し、いずれかの連携サービスをユーザにタッチさせることで、連携サービスを決定すればよい。

　次に、イニシャルＵＩが備える連携サービス決定部１１１７２は、連携サービス情報を構成するＵＩアプリリスト４００２を参照して、実行対象の連携サービスに対応するマスターＵＩを起動する（Ｓ１３００８）。

　次に、マスターＵＩが備える配信スクリプト決定部１１１７３は、各クライアント機器１２０１のデバイス情報と連携サービス情報管理部１１１７１が管理する連携サービス情報のスペック要件とを照合し（Ｓ１３００９）、各クライアント機器１２０１に配信するクライアントＵＩを決定する（Ｓ１３０１０）。

　ここで、図１３に示したシーケンスでは、イニシャルＵＩがネットワーク接続の確立と、連携サービスの決定とを行い、マスターＵＩを起動した後に、マスターＵＩがクライアント機器１２０１のＩＰアドレスを指定して、クライアントＵＩを決定する順序であったが、本発明はこれに限定されない。

　すなわち、イニシャルＵＩが連携サービスを決定し、マスターＵＩを起動した後に、マスターＵＩが、ネットワーク接続の確立とクライアントＵＩを決定する順序にしてもよい。

　図１４は、図１３に続くシーケンス図であり、上記の配信方法１を採用した場合のシーケンス図である。図１４において、実施の形態１にて説明した図６と同じ処理には、同じ符号を用い、説明を省略する。

　まず、マスターＵＩは、スクリプト配信部１１１３１が提供するＡＰＩを利用して、各クライアント機器１２０１のＩＰアドレスリストと、各クライアント機器１２０１に配信するクライアントＵＩのスクリプトデータ及びＩＤとを指定して、クライアントＵＩの配信依頼を行う（Ｓ１４００１）。

　次に、スクリプト配信部１１１３１は、各クライアント機器１２０１のスクリプト受信部１２３１に、クライアントＵＩのスクリプトデータ及びＩＤと、実行対象の連携サービスのサービスＩＤ等の情報を配信する（Ｓ１４００２）。

　以降、Ｓ６００４からＳ６００９の処理は、実施の形態１の図６にて説明した処理と同じため、説明を省略する。また、Ｓ６０１０～Ｓ６０１５は、実施の形態１と同様に、連携サービスを終了する際の処理の一例を示すシーケンスであるため、説明を省略する。

　図１５は、図１３に続くシーケンス図であり、上記の配信方法２を採用した場合のシーケンス図である。図１５において、図７と同じ処理には、同じ符号を用い、説明を省略する。

　まず、マスターＵＩは、スクリプト配信部１１１３１が提供するＡＰＩを利用して、各クライアント機器１２０１のＩＰアドレスリストと各クライアント機器１２０１に配信するクライアントＵＩのＵＲＩ及びＩＤとを指定して、クライアントＵＩの配信依頼を行う（Ｓ１５００１）。

　次に、スクリプト配信部１１１３１は、各クライアント機器１２０１のスクリプト受信部１２３１に、クライアントＵＩのＵＲＩ及びＩＤ、及びサービスＩＤ等の情報を配信する（Ｓ１５００２）。

　以降、Ｓ７００４からＳ７０１０の処理は実施の形態１の図７にて説明した処理と同じため、説明を省略する。また、Ｓ７０１１～Ｓ７０１６は、実施の形態１と同様に、連携サービスを終了する際の処理の一例を示すシーケンスであるため、説明を省略する。

　以上、実施の形態２による連携サービス管理システム１１００１によれば、実施の形態１の効果を得ることに加え、アプリケーション１１１０７の連携サービス情報管理部１１１７１が独自に管理する連携サービス情報を用いて、連携サービス及びクライアントＵＩが決定されるため、アプリケーション１１１０７の用途や目的に適する連携サービス及びクライアントＵＩを決定することができる。

　なお、上記の種々の実施の形態や、上記の種々の変形例を適宜組み合わせてもよい。また、上記の説明は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記の説明に限定されず、特許請求の範囲の記載によって示され、特許請求の範囲の記載と均等の意味及び範囲内での全ての変更が含まれることが意図される。

　（実施の形態の纏め）
　（１）本発明の一態様によるマスター機器は、自律分散型ネットワークにおいて、各機器を互いに連携させて実行される連携サービスを管理するマスター機器であって、複数の連携サービスに関して、各連携サービスを実行する際に各機器で必要となるアプリケーションに関する情報と前記アプリケーションを実行するために要求される各機器のスペック要件とを規定する連携サービス情報を管理する連携サービス情報管理部と、前記自律分散型ネットワークを介して検出された１又は複数の周辺機器から周辺機器のスペックを規定するデバイス情報を取得するデバイス情報取得部と、前記周辺機器から前記連携サービスに使用される１又は複数のクライアント機器を決定し、決定したクライアント機器とネットワーク接続を確立する接続管理部と、前記連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを決定する連携サービス決定部と、前記クライアント機器のデバイス情報と、前記実行対象の連携サービスの前記スペック要件とに基づき、前記クライアント機器のアプリケーションを決定するアプリケーション決定部と、前記アプリケーション決定部により決定されたアプリケーションを前記クライアント機器に配信するアプリケーション配信部と、前記アプリケーション配信部により配信されたアプリケーションの起動指示を前記クライアント機器に行う連携サービスライフサイクル管理部とを備える。

　この構成によれば、連携サービスを実行するために必要となるアプリケーションを持たない１又は複数のクライアント機器が自律分散型ネットワークに接続された場合であっても、各クライアント機器に連携サービスを実行するために必要となるアプリケーションが配信される。そのため、アクセスポイントを介することなく各機器が接続されて通信を行う自律分散型ネットワークにおいて、一つのマスター機器と１又は複数の機器とを接続して実現される機器連携サービスを実現することができる。

　また、各クライアント機器のスペックに適したアプリケーションが各クライアント機器に配信されるため、クライアント機器において配信されたアプリケーションが実行できないという事態が回避され、自律分散型ネットワークにおいて確実に連携サービスを実行することができる。

　（２）前記連携サービス決定部は、１又は複数の前記周辺機器のデバイス情報と前記連携サービス情報に規定されたスペック要件とに基づき、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、前記実行対象の連携サービスを決定し、前記接続管理部は、前記実行対象の連携サービスの前記スペック要件と前記周辺機器のデバイス情報とに基づき、前記実行対象の連携サービスに使用される１又は複数のクライアント機器を決定してもよい。

　この構成によれば、１又は複数の周辺機器のスペックから実行可能な連携サービスが抽出され、抽出された連携サービスの中からユーザは実行対象の連携サービスを選択することができる。そのため、ユーザが選択した連携サービスが実行できないといった事態を回避することができる。また、実行対象の連携サービスのスペック要件と１又は複数の周辺機器のデバイス情報とが照合され、実行対象の連携サービスが実行可能な周辺機器がクライアント機器として自動的に決定されるため、ユーザが周辺機器の中からクライアント機器を選択する手間を省くことができる。

　（３）前記接続管理部は、ユーザからの指示に基づき、前記周辺機器の中から１又は複数の前記クライアント機器を決定し、前記連携サービス決定部は、１又は複数の前記クライアント機器のデバイス情報と前記連携サービス情報に規定されたスペック要件とに基づき、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、前記実行対象の連携サービスを決定してもよい。

　この構成によれば、マスター機器のユーザは周辺機器の中から好みの周辺機器をクライアント機器として選択し、そのクライアント機器とマスター機器とで実行可能な連携サービスが抽出され、抽出された連携サービスの中からユーザは実行対象の連携サービスを決定することになる。そのため、全く知らないユーザの機器と連携サービスが行われることが防止され、ユーザの個人情報が別の機器のユーザに流出するといった事態を回避することができる。

　（４）前記アプリケーション決定部は、あるクライアント機器において前記実行対象の連携サービスの前記スペック要件を満たすアプリケーションが複数存在する場合、これらのアプリケーションをユーザに提示し、ユーザに選択されたアプリケーションを前記クライアント機器に配信するアプリケーションとして決定してもよい。

　この構成によれば、スペック要件を満たす複数のアプリケーションが存在する場合、ユーザは、これらのアプリケーションの中から好みのアプリケーションを選択することができる。

　（５）前記アプリケーションは、前記マスター機器で実行されるマスターアプリケーションと、前記クライアント機器で実行されるクライアントアプリケーションとを含み、前記連携サービスライフサイクル部は、前記マスターアプリケーションと前記クライアントアプリケーションとを同期起動させてもよい。

　この構成によれば、クライアントアプリケーションとマスターアプリケーションとが同期して起動されるため、マスター機器及びクライアント機器の両方において一斉に連携サービスを開始することができる。

　（６）前記アプリケーション配信部は、前記アプリケーションのスクリプトデータを前記クライアント機器に配信して記憶させることで、前記アプリケーションを１又は複数の前記クライアント機器に配信してもよい。

　この構成によれば、クライアント機器は、アプリケーションの起動前にアプリケーションのスクリプトデータを記録し、アプリケーションの起動時にそのスクリプトデータを読み出すことでアプリケーションを起動することができる。そのため、クライアント機器は、アプリケーションを高速に起動させることができる。

　（７）前記アプリケーション配信部は、前記アプリケーション決定部により決定されたアプリケーションのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）を１又は複数の前記クライアント機器に配信してもよい。

　この構成によれば、クライアント機器は、マスター機器からアプリケーションのＵＲＩ（統一資源識別子）が配信され、アプリケーションの起動時にそのＵＲＩからアプリケーションを読み出すことでアプリケーションを起動することができる。そのため、アプリケーションを配信する際のデータ量を削減することができる。

　（８）前記アプリケーション配信部は、前記アプリケーションのＵＲＩの送信時に、前記実行対象の連携サービスのＩＤ及び前記アプリケーションのＩＤを前記クライアント機器に送信し、前記連携サービスライフサイクル管理部は、前記アプリケーションの起動時に、前記実行対象の連携サービスのＩＤ又は前記アプリケーションのＩＤを指定して、前記クライアント機器に前記アプリケーションの起動指示を行ってもよい。

　この構成によれば、アプリケーションのＵＲＩの送信時に併せて実行対象の連携サービスのＩＤ及びアプリケーションのＩＤが送信されている。そのため、アプリケーション配信部は、アプリケーションの起動時には連携サービスのＩＤ又はアプリケーションのＩＤを指定するだけでアプリケーションを起動することができる。

　（９）前記クライアント機器は、前記連携サービスの実行終了後も受信した前記アプリケーションを保持し、前記アプリケーション配信部は、前記アプリケーションのスクリプトデータの配信時に、前記クライアント機器から保存している前記アプリケーションのＩＤ及びバージョンを取得し、取得した前記アプリケーションのＩＤ及びバージョンが、前記アプリケーション決定部により決定されたアプリケーションのＩＤ及びバージョンと一致していない場合、前記アプリケーションのスクリプトデータを配信してもよい。

　この構成によれば、クライアント機器に対して一度配信されたアプリケーションはバージョンが変化した場合にのみ再度送信されることになる。そのため、アプリケーションを起動する都度、マスター機器はクライアント機器にアプリケーションを配信する必要がなくなる。

　（１０）前記連携サービス情報管理部は、ユーザにより予め入力された情報に基づき、ユーザの好みに適合しない連携サービスを前記連携サービス情報から削除してもよい。

　この構成によれば、サービス情報の中からユーザの好みに適合しない連携サービスが予め削除されるため、ユーザは、自身の好みに応じた連携サービスが含まれるように、連携サービス情報をカスタマイズすることができる。

　（１１）前記マスター機器は、前記デバイス情報取得部、前記接続管理部、前記アプリケーション配信部、及び連携サービスライフサイクル管理部から送信対象のデータを受け付けて、前記クライアント機器に送信し、且つ、前記クライアント機器から送信されるデータを受信するネットワーク通信部を更に備えてもよい。

　この構成によれば、マスター機器を構成する各ブロックは、ネットワーク通信部を介してクライアント機器と通信することになる。

　（１２）本発明の一態様による連携サービス管理システムは、自律分散型ネットワークにおいて、複数の機器を互いに連携させて実行される連携サービスを管理する連携サービス管理システムであって、前記マスター機器と、前記マスター機器に対して前記自律分散型ネットワークを介して接続された１又は複数のクライアント機器とを備え、前記クライアント機器は、前記マスター機器からの接続依頼を受けて、前記マスター機器とネットワーク接続を確立するか否かを決定し、決定結果を前記マスター機器へ返答するクライアント側接続管理部と、前記マスター機器から配信されたアプリケーションを前記マスター機器からの起動要求を受けて起動するクライアント側ライフサイクル管理部とを備える。

　この構成によれば、（１）の効果が得られる連携サービス管理システムを提供することができる。

　（１３）前記マスター機器の前記アプリケーション配信部は、前記アプリケーション決定部により決定されたアプリケーションのスクリプトデータを１又は複数の前記クライアント機器に配信して記憶させ、前記クライアント側ライフサイクル管理部は、前記起動要求を受けた際、記録したスクリプトデータを読み出すことで前記マスター機器から配信されたアプリケーションを起動することが好ましい。

　この構成によれば、（６）と同様の効果が得られる。

　（１４）前記マスター機器の前記アプリケーション配信部は、前記アプリケーション決定部により決定されたアプリケーションのＵＲＩを１又は複数の前記クライアント機器に配信し、前記クライアント側ライフサイクル管理部は、前記起動要求を受けた際、前記マスター機器から配信されたＵＲＩを指定することで前記アプリケーションを起動することが好ましい。

　この構成によれば、（７）と同様の効果が得られる。

　（１５）前記機器は、前記マスター機器の機能及び前記クライアント機器の両方の機能を備え、前記連携サービスを実行する際には、１つの機器が前記マスター機器の機能を実行し、残りの機器が前記クライアント機器の機能を実行することが好ましい。

　この構成によれば、マスター機器となる機器にはマスター機器の機能を実行させ、クライアント機器となる機器にはクライアント機器の機能を実行させることで連携サービスを実現することができる。

　本発明にかかる連携サービス管理システムは、製造産業において、継続的及び反復的に製造し、販売することができる。特に、連携サービスの制作と実行に携わる民生機器産業において利用できる。

Claims

　自律分散型ネットワークにおいて、複数の機器を互いに連携させて実行される連携サービスを管理するマスター機器であって、
　複数の連携サービスに関して、各連携サービスを実行する際に前記機器で必要となるアプリケーションに関する情報と前記アプリケーションを実行するために要求される前記機器のスペック要件とを規定する連携サービス情報を管理する連携サービス情報管理部と、
　前記自律分散型ネットワークを介して検出された１又は複数の周辺機器から周辺機器のスペックを規定するデバイス情報を取得するデバイス情報取得部と、
　前記周辺機器から前記連携サービスに使用される１又は複数のクライアント機器を決定し、決定したクライアント機器とネットワーク接続を確立する接続管理部と、
　前記連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを決定する連携サービス決定部と、
　前記クライアント機器のデバイス情報と、前記実行対象の連携サービスの前記スペック要件とに基づき、前記クライアント機器のアプリケーションを決定するアプリケーション決定部と、
　前記アプリケーション決定部により決定されたアプリケーションを前記クライアント機器に配信するアプリケーション配信部と、
　前記アプリケーション配信部により配信されたアプリケーションの起動指示を前記クライアント機器に行う連携サービスライフサイクル管理部とを備えるマスター機器。
　前記連携サービス決定部は、１又は複数の前記周辺機器のデバイス情報と前記連携サービス情報に規定されたスペック要件とに基づき、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、前記実行対象の連携サービスを決定し、
　前記接続管理部は、前記実行対象の連携サービスの前記スペック要件と前記周辺機器のデバイス情報とに基づき、前記実行対象の連携サービスに使用される１又は複数のクライアント機器を決定する請求項１記載のマスター機器。
　前記接続管理部は、ユーザからの指示に基づき、前記周辺機器の中から１又は複数の前記クライアント機器を決定し、
　前記連携サービス決定部は、１又は複数の前記クライアント機器のデバイス情報と前記連携サービス情報に規定されたスペック要件とに基づき、実行可能な連携サービスを抽出し、抽出した連携サービスをユーザに提示し、ユーザからの指示に基づき、前記実行対象の連携サービスを決定する請求項１記載のマスター機器。
　前記アプリケーション決定部は、あるクライアント機器において前記実行対象の連携サービスの前記スペック要件を満たすアプリケーションが複数存在する場合、これらのアプリケーションをユーザに提示し、ユーザに選択されたアプリケーションを前記クライアント機器に配信するアプリケーションとして決定する請求項１～３のいずれかに記載のマスター機器。
　前記アプリケーションは、前記マスター機器で実行されるマスターアプリケーションと、前記クライアント機器で実行されるクライアントアプリケーションとを含み、
　前記連携サービスライフサイクル管理部は、前記マスターアプリケーションと前記クライアントアプリケーションとを同期起動させる請求項１～４のいずれかに記載のマスター機器。
　前記アプリケーション配信部は、前記アプリケーションのスクリプトデータを前記クライアント機器に配信して記憶させることで、前記アプリケーションを１又は複数の前記クライアント機器に配信する請求項１～５のいずれかに記載のマスター機器。
　前記アプリケーション配信部は、前記アプリケーションのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）を１又は複数の前記クライアント機器に配信する請求項１～５のいずれかに記載のマスター機器。
　前記アプリケーション配信部は、前記アプリケーションのＵＲＩの送信時に、前記実行対象の連携サービスのＩＤ及び前記アプリケーションのＩＤを前記クライアント機器に送信し、
　前記連携サービスライフサイクル管理部は、前記アプリケーションの起動時に、前記実行対象の連携サービスのＩＤ又は前記アプリケーションのＩＤを指定して、前記クライアント機器に前記アプリケーションの起動指示を行う請求項７記載のマスター機器。
　前記クライアント機器は、前記連携サービスの実行終了後も受信した前記アプリケーションを保持し、
　前記アプリケーション配信部は、前記アプリケーションのスクリプトデータの配信時に、前記クライアント機器から保存している前記アプリケーションのＩＤ及びバージョンを取得し、取得した前記アプリケーションのＩＤ及びバージョンが、前記アプリケーション決定部により決定されたアプリケーションのＩＤ及びバージョンと一致していない場合、前記アプリケーションのスクリプトデータを配信する請求項１～８のいずれかに記載のマスター機器。
　前記連携サービス情報管理部は、ユーザにより予め入力された情報に基づき、ユーザの好みに適合しない連携サービスを前記連携サービス情報から削除する請求項１～９のいずれかに記載のマスター機器。
　前記デバイス情報取得部、前記接続管理部、前記アプリケーション配信部、及び連携サービスライフサイクル管理部から送信対象のデータを受け付けて、前記クライアント機器に送信し、且つ、前記クライアント機器から送信されるデータを受信するネットワーク通信部を更に備える請求項１～１０のいずれかに記載のマスター機器。
　自律分散型ネットワークにおいて、複数の機器を互いに連携させて実行される連携サービスを管理する連携サービス管理システムであって、
　請求項１～１１のいずれかに記載のマスター機器と、前記マスター機器に対して前記自律分散型ネットワークを介して接続された１又は複数のクライアント機器とを備え、
　前記クライアント機器は、
　前記マスター機器からの接続依頼を受けて、前記マスター機器とネットワーク接続を確立するか否かを決定し、決定結果を前記マスター機器へ返答するクライアント側接続管理部と、
　前記マスター機器から配信されたアプリケーションを前記マスター機器からの起動要求を受けて起動するクライアント側ライフサイクル管理部とを備える連携サービス管理システム。
　前記マスター機器の前記アプリケーション配信部は、前記アプリケーション決定部により決定されたアプリケーションのスクリプトデータを１又は複数の前記クライアント機器に配信して記憶させ、
　前記クライアント側ライフサイクル管理部は、前記起動要求を受けた際、記録したスクリプトデータを読み出すことで前記マスター機器から配信されたアプリケーションを起動する請求項１２記載の連携サービス管理システム。
　前記マスター機器の前記アプリケーション配信部は、前記アプリケーション決定部により決定されたアプリケーションのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）を１又は複数の前記クライアント機器に配信し、
　前記クライアント側ライフサイクル管理部は、前記起動要求を受けた際、前記マスター機器から配信されたＵＲＩを指定することで前記アプリケーションを起動する請求項１２記載の連携サービス管理システム。
　前記機器は、前記マスター機器の機能及び前記クライアント機器の両方の機能を備え、
　前記連携サービスを実行する際には、１つの機器が前記マスター機器の機能を実行し、残りの機器が前記クライアント機器の機能を実行する請求項１２～１４のいずれかに記載の連携サービス管理システム。
　自律分散型ネットワークにおいて、複数の機器を互いに連携させて実行される連携サービスを管理するマスター機器による連携サービス管理方法であって、
　前記マスター機器は、複数の連携サービスに関して、各連携サービスを実行する際に前記機器で必要となるアプリケーションに関する情報と前記アプリケーションを実行するために要求される前記機器のスペック要件とを規定する連携サービス情報を管理する連携サービス情報管理部を備え、
　前記自律分散型ネットワークを介して検出された１又は複数の周辺機器から周辺機器のスペックを規定するデバイス情報を前記マスター機器が取得するデバイス情報取得ステップと、
　前記周辺機器から前記連携サービスに使用される１又は複数のクライアント機器を前記マスター機器が決定し、決定したクライアント機器とネットワーク接続を前記マスター機器が確立する接続管理ステップと、
　前記連携サービス情報に規定された連携サービスの中から、ユーザからの指示に基づき、実行対象の連携サービスを前記マスター機器が決定する連携サービス決定ステップと、
　前記クライアント機器のデバイス情報と、前記実行対象の連携サービスの前記スペック要件とに基づき、前記クライアント機器のアプリケーションを前記マスター機器が決定するアプリケーション決定ステップと、
　前記アプリケーション決定ステップにより決定されたアプリケーションを前記クライアント機器に前記マスター機器が配信するアプリケーション配信ステップと、
　前記アプリケーション配信ステップにより配信されたアプリケーションの起動指示を、前記マスター機器が前記クライアント機器に行う連携サービスライフサイクル管理ステップとを備える連携サービス管理方法。