JP6801657B2 - 情報処理装置、情報処理方法及びコンピュータプログラム - Google Patents

Description

本開示は、情報処理装置、情報処理方法及びコンピュータプログラムに関する。

ネットワーク関連の技術の発達に伴い、ネットワークに接続することが出来る装置も小型化する傾向が進んでいる。すなわち、１人のユーザが複数のネットワークに接続可能な装置を保持すること多くなってきている。

また、ソフトウェアやデータなどをインターネットなどのネットワークを通じて利用するクラウドコンピューティングも普及してきており、クラウドコンピューティングを利用した様々なサービスが展開されている。クラウドを利用したサービスにおいては、そのサービス毎に利用するデバイスが異なることが多く、また複数のデバイスを連携させて利用することも多い。例えば特許文献１には、デバイスを連携させるための技術が開示されている。

特開２００３−３２１７６号公報

クラウドを利用したサービスを利用する際に、そのサービスで利用するデバイスを連携させる際に、事前登録しておくケースが多い。しかし、１人のユーザが複数のネットワークに接続可能な装置を保持する場合、それらの装置をすべて事前登録するのは非常に手間が掛かることが容易に想定できる。

そこで本開示では、ネットワーク上のサービスを利用する装置同士の連携処理を容易に実行することが可能な、新規かつ改良された情報処理装置、情報処理方法及びコンピュータプログラムを提案する。

本開示によれば、ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼する制御部を備える、情報処理装置が提供される。

また本開示によれば、ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することを含む、情報処理方法が提供される。

また本開示によれば、ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することをコンピュータに実行させる、コンピュータプログラムが提供される。

また本開示によれば、提供するネットワーク上のサービスにおけるユーザを識別するユーザ識別子と、前記サービスを利用する第１の装置を識別するデバイス識別子との連携に関する処理を実行する制御部を備え、前記制御部は、前記第１の装置と異なる第２の装置のデバイス識別子と前記ユーザ識別子との連携に関する処理を行う際に、所定の条件に基づいて前記第１の装置のデバイス識別子と前記ユーザ識別子との連携を解除するかどうかを判断する、制御装置が提供される。

以上説明したように本開示によれば、ネットワーク上のサービスを利用する装置同士の連携処理を容易に実行することが可能な、新規かつ改良された情報処理装置、情報処理方法及びコンピュータプログラムを提供することができる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の実施の形態の前提について示す説明図である。 同実施形態の前提について示す説明図である。 同実施形態に係るデバイス１００の機能構成例を示す説明図である。 同実施形態に係るサービス２００の機能構成例を示す説明図である。 同実施形態の実施例１の動作を説明する説明図である。 同実施形態の実施例１の動作を説明する説明図である。 サービス２００が保持する情報の例を示す説明図である。 同実施形態の実施例１の動作を説明する説明図である。 同実施形態の実施例１の動作を説明する説明図である。 同実施形態の実施例１の動作を説明する説明図である。 あるサブデバイス１００ｂによる、サービス２００へのサブデバイスの連携登録等の確認方法を示す説明図である。 同実施形態の実施例２の動作を説明する説明図である。 同実施形態の実施例３の動作を説明する説明図である。 同実施形態の実施例３の動作を説明するシーケンス図である。 同実施形態の実施例４の動作を説明する説明図である。 サーバの概略的な構成の一例を示すブロック図である。 デバイスのハードウェア構成例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．本開示の一実施形態
１．１．概要
１．２．実施例１
１．３．実施例２
１．４．実施例３
１．５．実施例４
２．ハードウェア構成例
３．まとめ

＜１．本開示の一実施形態＞
［１．１．概要］
まず、本開示の実施の形態について詳細に説明する前に、本開示の実施の形態の概要を説明する。

ネットワーク関連の技術の発達に伴い、ネットワークに接続することが出来る装置も小型化する傾向が進んでいる。すなわち、１人のユーザが複数のネットワークに接続可能な装置を保持すること多くなってきている。

また、ソフトウェアやデータなどをインターネットなどのネットワークを通じて利用するクラウドコンピューティングも普及してきており、クラウドコンピューティングを利用した様々なサービスが展開されている。クラウドを利用したサービスにおいては、そのサービス毎に利用するデバイスが異なることが多く、また複数のデバイスを連携させて利用することも多い。

クラウドを利用したサービスを利用する際に、そのサービスで利用するデバイスを連携させる際に、事前に連携登録しておくケースが多い。しかし、１人のユーザが複数のネットワークに接続可能な装置を保持する場合、それらの装置をすべて事前登録するのは非常に手間が掛かることが容易に想定できる。

また、クラウドを利用したサービスの利用中に、連携の対象となるデバイスを変更する際に、デバイスの追加、変更、削除の登録を行うのは非常にユーザにとって手間がかかるし、場合によっては、ユーザよる連携登録のし忘れも起りうる。サービスの利用前や利用途中にこのような手間がかかっていれば、ユーザが使いたいときにすぐにサービスが利用できない不便を被ることにもなりうる。

そこで本件開示者は、上述した点に鑑み、ネットワーク上のサービスを利用する装置同士の連携処理を容易に実行することが可能な技術について鋭意検討を行った。その結果、本件開示者は、ネットワーク上の所定のサービスで規定された所定の条件を他の装置との関係が満たすと装置同士の連携処理を実行することで、ユーザの利便性を大幅に向上させることが可能な技術を考案するに至った。

以上、本開示の実施の形態の概要について説明した。

［１．２．実施例１］
続いて、いくつか実施例を挙げて本開示の実施の形態について詳細に説明する。本開示の実施の形態の前提を、図１を用いて説明する。図１は、本開示の実施の形態の前提について示す説明図である。

本開示の実施の形態では、サービスはクラウドコンピューティング（以下、単にクラウドとも称する）を利用したものとなっている。ユーザ１０はこのクラウドを利用したサービス（クラウドサービス）２００を利用するにあたり、そのユーザが保持するスマートフォンやウェアラブル端末などの、クラウドサービスとネットワーク的に接続可能なデバイス１００ａを持っている。本実施形態では、ユーザ１０が所有しているデバイスの１つをメインデバイスと称する。メインデバイスとなり得るのは、クラウドを利用したサービス２００と通信可能なデバイスであれば何でも良い。例えばユーザが所持するスマートフォン、タブレット端末、パーソナルコンピュータ、据え置き型または携帯型のゲーム機、テレビ、自動車等の、クラウドを利用したサービス２００と通信出来る機能を有しうるあらゆる機器がメインデバイスとなり得る。

まずユーザ１０は、対象となるサービス２００を利用するための契約などを得ることで、そのサービスが利用可能な状態となる。この契約時には、各々のユーザ１０のメインデバイス１００ａを利用するかどうかは問わない。しかし、メインデバイス１００は、このサービス２００を利用する上で必ず必要となるデバイスの１つであると定義する。

メインデバイス１００ａは、サービス２００と直接情報をやり取りするための通信機能を有する。さらに、メインデバイス１００ａは、サービス２００がその利用者を識別するためのユーザ識別子を保持する。ただし、本実施形態では、ユーザは、自然人とは限定しない。ユーザは、法人やグループなど、サービスを受けることが可能となる対象すべてに相当する。

サービス２００は、ユーザ１０からの要求に応じて、そのユーザに対してサービスを利用可能な状態とすると、当該ユーザ１０に、ユーザＩＤなどのサービスにおける利用者を識別する識別子を発行する。メインデバイス１００ａは、サービス２００が提供するクラウドサービスを受けるために必要なユーザＩＤなどの情報をサービス２００に送信する。サービス２００は、メインデバイス１００ａから送られてくる情報に基づいたサービスをメインデバイス１００ａに提供する。

ユーザ１０は、メインデバイス１００ａの他に複数のデバイスを所持しうる。メインデバイス１００ａとは異なるデバイスをサブデバイスと称する。メインデバイスとなり得るのは、メインデバイスと直接的に、または他のデバイスを介して通信可能なデバイスであれば何でも良い。すなわち、サブデバイスは必ずしもサービス２００と通信可能でなくてもよい。例えばユーザが所持するスマートフォン、タブレット端末、パーソナルコンピュータ、据え置き型または携帯型のゲーム機、テレビ、ヘッドマウントディスプレイ、眼鏡型や腕時計型その他のウェアラブルデバイス、冷蔵庫や電子レンジその他の電化製品、スポーツで使用する道具等の、近距離または遠距離の通信機能を有しうるあらゆる機器がサブデバイスとなり得る。

図２は、本開示の実施の形態の前提について示す説明図である。図２には、メインデバイス１００ａに加えて、ｎ個のサブデバイス１００ｂ、１００ｃ、・・・、１００ｘが図示されている。サブデバイス１００ｂ、・・・は、メインデバイス１００ａとの間の相互通信はもちろん、サービス２００との相互通信や、他のサブデバイス１００ｂ、・・・との間の相互通信を行う機能を有する。

ユーザ１０は、サービス２００を利用する際に、メインデバイス１００ａ以外に利用するサブデバイス１００ｂ、・・・からの情報や機能などを必要とするために、これらのサブデバイス１００ｂ、・・・をメインデバイス１００ａに連携する連携デバイスとしてサービス２００に認識させる必要がある。なお、本実施形態では、連携するとは、あるユーザが使用するデバイスとしてデバイス同士が連携していることをいう。

本実施形態では、サブデバイス１００ｂ、・・・をメインデバイス１００ａの連携デバイスとしてサービス２００に認識させるために、サービス２００で規定された所定の条件を満たしたかどうかをメインデバイス１００ａで判断する。ここで、サービス２００で規定された所定の条件としては、例えばユーザ１０がサブデバイス１００ｂ、・・・に触れたり、近づいたりする等の、ユーザ１０とサブデバイス１００ｂ、・・・との接触や相対的な位置関係であってもよい。またサービス２００で規定された所定の条件としては、サブデバイス１００ｂ、・・・のバッテリ残量や動作可能時間が所定値以上であること、であってもよい。すなわちサービス２００は、所定のバッテリ残量や動作可能時間以上でなければ、そのサブデバイス１００ｂ、・・・が連携登録出来ないようにしてもよい。

以上、本開示の実施の形態の前提について説明した。続いて、本実施形態に係るメインデバイス１００ａやサブデバイス１００ｂ、・・・の機能構成例について説明する。なお、以下の説明では、メインデバイス１００ａやサブデバイス１００ｂ、・・・を総称する際には単にデバイス１００とも称する。

図３は、本実施形態に係るデバイス１００の機能構成例を示す説明図である。図３に示したデバイス１００は、メインデバイス１００ａまたはサブデバイス１００ｂ、・・・のいずれかであり得る。以下、図３を用いて本実施形態に係るデバイス１００の機能構成例について説明する。

図３に示したように、本実施形態に係るデバイス１００は、通信部１１０と、記憶部１２０と、出力部１３０と、センサ１４０と、処理部１５０と、を含んで構成される。

通信部１１０は、情報を無線または有線によって送受信する。例えば、通信部１１０は、サービス２００との間や、他のデバイス１００との間の情報の送受信を行う。通信部１１０は、例えばセルラー通信機能、Ｗｉ−Ｆｉ通信機能、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信機能などを有しうる。

記憶部１２０は、デバイス１００の動作のためのプログラム及びデータを一時的にまたは恒久的に記憶する。例えば、記憶部１２０は、情報取得部１５１が取得した情報を、一時的にまたは恒久的に記憶する。記憶部１２０は、制御部１５３が各種制御のために使用するデータを記憶しうる。記憶部１２０は、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどで構成されうる。

本実施形態では、記憶部１２０は、デバイス１００を一意に識別するための情報を記憶する。デバイス１００を一意に識別するための情報のことを本実施形態ではデバイス識別子とも称する。

出力部１３０は、ユーザ１０へ情報を通知するために各種情報を出力する機能を有する。出力部１３０による情報の出力は、例えば制御部１５３の制御によって行われうる。出力部１３０は、例えば情報を文字や画像で出力するディスプレイ、情報を音で出力するスピーカ、情報を振動で出力するバイブレータなどで構成されうる。

センサ１４０は、様々な状態をセンシングするデバイスである。センサ１４０には、例えば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）、ＧＬＯＮＡＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）、ＢＤＳ（ＢｅｉＤｏｕ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）、ｉＢｅａｃｏｎ等の現在位置を取得するセンサ、カメラ、深度情報付きカメラ、人感センサ、マイク、加速度センサ、角速度センサ等が含まれ得る。

センサ１４０が取得した情報は処理部１５０に随時送られる。そして処理部１５０は、センサ１４０から送られてくる情報に基づいて各種処理を実行する。

処理部１５０は、デバイス１００の様々な機能を提供する。処理部１５０は、情報取得部１５１及び制御部１５３を含む。なお、処理部１５０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部１５０は、これらの構成要素の動作以外の動作も行い得る。

情報取得部１５１は、通信部１１０が受信した信号から、種々の情報を取得する。また情報取得部１５１は、デバイス１００の動作のための情報やプログラムを記憶部１２０から取得しうる。また情報取得部１５１は、センサ１４０が取得した様々な情報を取得する。

制御部１５３は、デバイス１００の動作を制御するものである。本実施形態では、制御部１５３は、他のデバイス１００の存在を検知し、との間の関係がサービス２００で規定された所定の条件を満たしたかどうかを判断する。制御部１５３は、他のデバイス１００との間の関係がサービス２００で規定された所定の条件を満たしたと判断した場合、自装置と、その他のデバイス１００との連携処理をサービス２００に依頼する。本実施形態では、連携処理とは、あるユーザが使用するデバイスであるとして情報を登録するための処理のことをいう。

制御部１５３は、自装置と、その他のデバイス１００との連携処理をサービス２００に依頼する際に、サービス２００が提供するサービスにおけるユーザを識別するユーザ識別子と、新たに連携しようとするデバイス１００のデバイス識別子とをサービス２００に送信する。サービス２００で連携処理が行われると、ユーザを識別するユーザ識別子と、新たに連携しようとするデバイス１００のデバイス識別子との紐付けが行われる。

制御部１５３が、他のデバイス１００の存在をどのように検知するかは、様々な方法を採りうる。例えば制御部１５３は、センサ１４０が他のデバイス１００の接触を検出したことで他のデバイス１００の存在を検知してもよく、情報取得部１５１が取得した他のデバイス１００の位置が、自装置のセンサ１４０で取得した位置から所定の範囲内に存在していることを検出したことで他のデバイス１００の存在を検知してもよい。

以上、図３を用いて本実施形態に係るデバイス１００の機能構成例について説明した。続いて本実施形態に係るサービス２００の機能構成例について説明する。

図４は、本開示の一実施形態に係るサービス２００の機能構成例を示す説明図である。以下、図４を用いてサービス２００の機能構成例について説明する。

図４に示したように、サービス２００は、通信部２１０と、記憶部２２０と、処理部２３０と、を備える。

（通信部２１０）
通信部２１０は、情報を送受信する。例えば、通信部２１０は、他のノード、例えばデバイス１００への情報を送信し、他のノードからの情報を受信する。本実施形態では、通信部２１０は、デバイス１００間の連携処理の依頼を受信しうる。

（記憶部２２０）
記憶部２２０は、サービス２００の動作のためのプログラム及びデータを一時的にまたは恒久的に記憶する。例えば、記憶部２２０は、情報取得部２３１が取得した情報を、一時的にまたは恒久的に記憶する。記憶部２２０は、制御部２３３が各種制御のために使用するデータを記憶しうる。記憶部２２０は、例えばハードディスクドライブやソリッドステートドライブなどで構成されうる。本実施形態では、記憶部２２０は、例えばユーザ識別子を含んだユーザ情報が管理されているテーブルと、ユーザ識別子とデバイス識別子とが紐付けられているテーブルと、を保持しうる。ユーザ識別子を含んだユーザ情報が管理されているテーブルと、ユーザ識別子とデバイス識別子とが紐付けられているテーブルと、の具体例は後に詳述する。

（処理部２３０）
処理部２３０は、通信資源取引サーバ３００の様々な機能を提供する。処理部３３０は、情報取得部２３１及び制御部２３３を含む。なお、処理部２３０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２３０は、これらの構成要素の動作以外の動作も行い得る。

（情報取得部２３１）
情報取得部２３１は、サービス２００の動作のための情報や、他のノードから受信した情報を取得する。情報取得部２３１は、サービス２００の動作のための情報やプログラムを記憶部２２０から取得しうる。本実施形態では、情報取得部２３１は、通信部２１０が受信した、デバイス１００間の連携処理の依頼を通信部２１０から取得する。

（制御部２３３）
制御部２３３は、サービス２００の動作を制御する。制御部２３３は、情報取得部２３１が取得した情報に基づいて動作しうる。本実施形態では、制御部２３３は、デバイス１００からの要求に応じて、デバイス１００間の連携処理を実行する。制御部２３３は、デバイス１００間の連携処理を実行すると、記憶部２２０に保存されている、ユーザ識別子とデバイス識別子とが紐付けられているテーブルの内容を更新するとともに、必要に応じて、連携処理の依頼を送信したデバイス１００へ連携処理の結果を送信する。

制御部２３３は、既に１つ以上のサブデバイスのデバイス識別子がユーザ識別子と連携されている状態で、さらに別のサブデバイスに対する連携登録の依頼がデバイス１００から送られてくると、新たなサブデバイスの連携に関する処理を行う際に、所定の条件に基づいて、既に連携されているサブデバイスのデバイス識別子とユーザ識別子との連携を解除するかどうかを判断しても良い。

例えば、連携可能となるサブデバイスの数が上限に達していたら、制御部２３３は、新たなサブデバイスの連携を行うか、連携を拒否するかを判断する。新たなサブデバイスを連携する場合は、既に連携しているサブデバイスの連携を解除しなければならないので、所定の条件に基づいて解除する。制御部２３３による、サブデバイスの連携の例については後に詳述する。

以上、図４を用いてサービス２００の機能構成例に説明した。なお図４に示したサービス２００は、１台のサーバ装置で構成されていても良く、複数のサーバ装置で構成されていても良い。

続いて、実施例１の動作について説明する。図５は、本実施形態の実施例１の動作を説明する説明図である。図５に示したのは、ユーザ１０が既にメインデバイス１００ａを所有しており、新たにサブデバイス１００ｂを連携させる際の動作を示す説明図である。なお、以降の説明において、各デバイスの内部の処理は、図３に示した制御部１５３が実行する。制御部１５３は、内部の処理を実行するにあたり、情報取得部１５１が取得した情報を適宜用いるものとする。またサービス２００の内部の処理は、図４に示した制御部２３３が実行する。制御部２３３は、内部の処理を実行するにあたり、情報取得部２３１が取得した情報を適宜用いるものとする。

ユーザ１０が既にメインデバイス１００ａを所有している状態で、ユーザ１０がサブデバイス１００ｂを触ったり、サブデバイス１００ｂとメインデバイス１００ａとの距離が所定の距離以下になったりするなど、サービス２００で規定された所定の条件を満たすと（ステップＳ１１）、メインデバイス１００ａは、サブデバイス１００ｂの存在を検知する（ステップＳ１２）。

サブデバイス１００ｂの存在を検知したメインデバイス１００ａは、デバイス識別子の送信をサブデバイス１００ｂに要求する。サブデバイス１００ｂは、要求に応じてメインデバイス１００ａへデバイス識別子を送信する（ステップＳ１３）。サブデバイス１００ｂのデバイス識別子を受信したメインデバイス１００ａは、保持しているユーザ識別子と共にサブデバイス１００ｂのデバイス識別子をサービス２００に送信し、サブデバイス１００ｂを自ユーザのデバイスとして連携登録するよう依頼する（ステップＳ１４）。連携登録とは、サービス２００が発行した利用者を識別する識別子と、各デバイスが持っているデバイスの識別子とを紐づける処理のことをいう。

図５の例では、メインデバイスが保持しているユーザ識別子と、新たに連携登録しようとするサブデバイス１００ｂのデバイス識別子をサービス２００に送信していたが、メインデバイスは、保持しているユーザ識別子の他に、サービス２００が提供するサービスにおけるユーザを識別する情報（ユーザアカウントなど）をサービス２００に送信しても良い。

図６は、本実施形態の実施例１の動作を説明する説明図である。図６に示したのは、ユーザ１０が既にメインデバイス１００ａ及びサブデバイス１００ｂを所有しており、新たにサブデバイス１００ｃを連携させる際の動作を示す説明図である。

ユーザ１０が既にサービス２００においてメインデバイス１００ａと連携済みのサブデバイス１００ｂを所有している状態で、ユーザ１０がサブデバイス１００ｂとは別のサブデバイス１００ｃを触ったり、サブデバイス１００ｃとメインデバイス１００ａとの距離が所定の距離以下になったりするなど、サービス２００で規定された所定の条件を満たすと（ステップＳ２１）、サブデバイス１００ｂは、サブデバイス１００ｃの存在を検知する（ステップＳ２２）。サブデバイス１００ｃの存在の検知は、例えば情報取得部１５１が取得した情報に基づき、制御部１５３が実行する。

サブデバイス１００ｃの存在を検知したサブデバイス１００ｂは、デバイス識別子の送信をサブデバイス１００ｃに要求する。サブデバイス１００ｃは、サブデバイス１００ｂへデバイス識別子を送信する（ステップＳ２３）。サブデバイス１００ｃのデバイス識別子を受信したサブデバイス１００ｂは、取得したサブデバイス１００ｃのデバイス識別子をメインデバイス１００ａに送る（ステップＳ２４）。そしてメインデバイス１００ａは、保持しているユーザ識別子と共にサブデバイス１００ｃのデバイス識別子をサービス２００に送信し、サブデバイス１００ｃを自ユーザのデバイスとして連携するよう依頼する（ステップＳ２５）。

メインデバイス１００ａを所有しているユーザ１０とサブデバイス１００ｂ、・・・との接触や近接の認識は、例えば接触センサによる認識や、映像または音声での解析による認識などの方法やそれらの方法の組み合わせで持って実現されうる。つまり、一方が何等かの信号発し、他方がそれを受信して解析し、認識することで、双方で相互に認識できる仕組みがあればよい。信号以外でも、磁力による電磁誘導など、２つのデバイス間で影響を及ぼしあうことで、互いにデバイスを認識するという方法でメインデバイス１００ａを所有しているユーザ１０とサブデバイス１００ｂ、・・・との接触や近接を認識してもよい。

また各デバイスは、デバイス間の相対的な位置関係を、ＧＰＳやＷｉ−Ｆｉの電波強度などを用いた絶対位置情報を利用する方法や、デバイス間で直接センシングする方法などを利用したり、それらの方法の組み合わせを用いたりすることで検出してもよい。

他にも、メインデバイス１００ａとサブデバイス１００ｂ、・・・との接触や相対的な位置関係だけでなく、サブデバイス１００ｂ、・・・が特定の絶対位置の範囲内に入った場合にも、自動的にサービス２００で連携登録されるようにしてもよい。絶対位置情報を利用する場合には、特定の範囲内に対象となるサブデバイス１００ｂ、・・・が位置したことをメインデバイス１００ａが検出し、メインデバイス１００ａからサービス２００に自動的に連携登録されるようにしてもよい。サブデバイス１００ｂ、・・・の絶対位置の特定は、ＧＰＳやＷｉ−Ｆｉの電波強度を用いた方法などの絶対位置情報を利用する方法やその組み合わせで実現されうる。

ユーザ識別子にデバイス識別子が紐づけられたデバイスは、そのサービスを利用する上で必要となる情報や機能を他のデバイスに提供することができる。ここでのデバイス識別子とは、サービスから見れば必ずグローバルに一意にデバイスを特定できる情報とする。サービス２００は、複数の情報を組み合わせて一意に特定することが出来れば、複数の情報を組み合わせたものをデバイス識別子の代用としてもよい。

図７は、サービス２００が保持する情報の例を示す説明図である。図７には、ユーザ情報が管理されているテーブルと、ユーザ識別子とデバイス識別子とが紐付けられているテーブルとが示されている。これらの情報は例えば記憶部２２０に記憶されている。サービス２００は、ユーザ識別子とデバイス識別子とが紐付けられているテーブルを保持しておくことで、どのユーザにどのデバイスが紐付いているかを管理することが出来る。図７の例では、ユーザ識別子が「ｕｓｅｒ１」のユーザが、サービス２００を利用する３つのデバイスを有していることが示されている。

すなわち、メインデバイス１００ａからサービス２００に対して連携登録の依頼や連係の解除の依頼が送信されることで、図７に示したユーザ識別子とデバイス識別子とが紐付けられているテーブルの内容が更新されることになる。ユーザ識別子とデバイス識別子とが紐付けられているテーブルの内容を更新する処理が、サービス２００が実行するデバイスの連携に関する処理となる。

なお、１つのサブデバイスは、複数の利用者のユーザ識別子に紐付けられてもよい。１つのサブデバイスが複数の利用者のユーザ識別子に紐付けられる場合、そのサブデバイスで提供可能な情報や機能を、紐づいた全てのユーザに対して提供するのか、一部のユーザにのみ提供するのかは、サービス２００が提供するクラウドサービスの内容に依存してもよい。

サブデバイスの連携登録時に、例えばキャリブレーション等の調整機能をそのサブデバイスに動作させる必要がある場合には、この調整機能も自動的に行われるようにしてもよい。言い換えれば、サブデバイスのキャリブレーション等の調整機能が行わせ、調整機能が動作しない場合にはサービス２００での連携登録が失敗するというようにしてもよい。例えば、サブデバイスを連携登録して、サブデバイスが有するマイクをメインデバイスから使用できるようにする場合、メインデバイスは、サブデバイスに対してマイクの集音時に最初の数秒間はノイズの検知を行わせて、サブデバイスが検知したノイズのレベルに応じて、サブデバイスにマイクのレベルを調整させるようにしてもよい。

一度連携登録したサブデバイスに対する連携登録の解除も可能である。サブデバイスの連携登録の解除についても、メインデバイスやサブデバイスは、相対的または絶対的な位置関係が変化したり、サブデバイスが一定時間無反応になったりするなどの、サービス２００で定められた条件を満たすことで自動的に行われる。

この連携登録の解除が行われた場合に、既に連携しているデバイス（メインデバイス及びサブデバイス）への通知は必須ではない。もちろん、連携登録の解除が行われたことを通知してなんらかのアクションを起こすケースは考えられるが、それはサービス２００が提供しているクラウドサービスのポリシーに依存するものとする。後述するように、サービスのプロファイルや、デバイスのプロファイルに基づいて、連携登録の解除が行われたことの通知の有無を個々に決定できるようにしてもよい。

サービス２００が定めた条件によっては、既に連携登録されたサブデバイスが別のサブデバイスに新しく置き換わったとして認識することも可能とする。既に連携登録されたサブデバイスが別のサブデバイスに新しく置き換わったとして認識する場合、サービス２００は、既に連携登録されているサブデバイスは自動的に連携を解除して、新しいサブデバイスを新しく連携登録する。

サブデバイスを新規に連携登録するのか、別のサブデバイスと置き換えて連携登録するのかを識別するための方法の例を示す。

まず、各サブデバイスは、デバイスタイプなどの、サービス２００での連携登録時に利用される情報が書かれたデバイスプロファイルを持つ。サービス２００は、デバイスの連携の判断に必要となる情報が書かれたサービスプロファイルを持つ。

サービスプロファイルが持つ情報としては以下の様なものが考えられる。もちろん、サービスプロファイルは、以下で挙げた情報以外の情報を持たせるための拡張が可能なように設計されていてもよい。

サービスプロファイルが持つ情報としては、例えば、サービスを一意に識別するサービス識別子、サービスを利用する際に連携が必要なデバイスプロファイル要件と、その要件を満たすデバイスの個数（最小数と最大数）が含まれうる。デバイスプロファイル要件は、デバイスプロファイルＩＤのみでもよいし、デバイスプロファイルＩＤに加えて他の情報が使われてもよい。デバイスの個数の最小数と最大数の使われ方としては、必ず１つ必要とする場合には、最小数及び最大数が共に１に設定される。また、最小数を０に、最大数を１にすることで、あるデバイスプロファイル要件を満たすデバイスをオプションで１つだけ連携させることが実現できる。

またサービスプロファイルが持つ情報として、サブデバイスの連携条件や優先度が含まれうる。サービス２００は、サブデバイスの連携条件や優先度を基に、連携処理を実行したり、デバイスの最大数が超えた場合にどのデバイスを優先して連携状態としたりするかを判断することができる。

デバイスプロファイルが持つ情報としては以下の様なものが考えられる。もちろん、デバイスプロファイルは、以下で挙げた情報以外の情報を持たせるための拡張が可能なように設計されていてもよい。

デバイスプロファイルが持つ情報としては、デバイスプロファイルを一意に識別するデバイスプロファイルＩＤ、デバイスの接続許可に関する情報等が含まれうる。デバイスの接続許可に関する情報には、例えば公開範囲に関する定義が含まれうる。公開範囲に関する条件やレベル等はデバイスプロファイルには規定せず、ここでは公開範囲に関する条件定義という情報があるということのみをデバイスプロファイルに定義する。その公開範囲条件やレベル等は、サービス２００が提供するクラウドサービスの内容に応じて自由にプログラマブルに定義できるようにしてもよい。

またデバイスプロファイルが持つ情報には、そのデバイスがプライベートなものなのか、パブリックなものなのかを識別する情報が含まれていても良い。パブリックなものであれば、そのデバイスが例えば家や学校のような信頼性が担保されている場所に置かれているものか、そのような場所以外の信頼性が担保されていない場所に置かれているものか、を識別する識別する情報が、デバイスプロファイルに含まれていても良い。

メインデバイスは、他のデバイスを連携させようとする際に、そのデバイスのデバイスプロファイルを参照し、家や学校のような信頼性が担保されている場所に置かれていればそのデバイスを信頼して連携登録をサービス２００に依頼し、そうでない場所に置かれているデバイスであればそのデバイスを信頼せず、連携登録をサービス２００に依頼しないようにしてもよい。

それぞれのデバイス１００は、そのデバイスを有しているユーザに関する情報であるユーザプロファイルを保持していても良い。そして、メインデバイス１００ａとサブデバイス１００ｂとが連携されようとする際に、メインデバイス１００ａは、ユーザプロファイルの参照によって、そのメインデバイス１００ａとサブデバイス１００ｂとが連携可能かどうかを判断しても良い。

ここでサービス２００は、連携可能となるサブデバイスのデバイスタイプの上限数をサービスのプロファイルに設定しておく。上限数の設定により、サービス２００は、新しくサブデバイスを連携登録するタイミングで、同じプロファイルのデバイスの連携数が上限に達していないならば、新規に連携登録を行い、既に上限に達しているならば、既に連携している同じプロファイルのサブデバイスを解除する。

図８は、本実施形態の実施例１の動作を説明する説明図である。図８に示したのは、ユーザ１０が既にメインデバイス１００ａ及びサブデバイス１００ｂを所有しており、新たにサブデバイス１００ｃを連携させる際の動作を示す説明図である。なお、図８に示した動作例は、メインデバイス１００ａがサブデバイス１００ｃの存在を検知したところから開始されるものとする。

メインデバイス１００ａがサブデバイス１００ｃの存在を検知すると、メインデバイス１００ａは、サブデバイス１００ｃに対してデバイス識別子及びデバイスタイプの送信を要求する（ステップＳ３１）。サブデバイス１００ｃは、要求に応じてメインデバイス１００ａへデバイス識別子及びデバイスタイプを送信する。

サブデバイス１００ｃからデバイス識別子及びデバイスタイプを取得したメインデバイス１００ａは、保持しているユーザ識別子と共にサブデバイス１００ｃのデバイス識別子をサービス２００に送信し、サブデバイス１００ｃを自ユーザのデバイスとして連携するよう依頼する（ステップＳ３２）。

メインデバイス１００ａからデバイス識別子及びデバイスタイプを取得したサービス２００は、デバイスの登録情報を確認して、デバイスの登録数が、そのデバイスタイプの上限数に既に達しているかどうかを判断する。例えば、あるデバイスタイプは、最大で１つのサブデバイスのみが登録可能で有るとサービスのプロファイルに設定されており、そのデバイスタイプのサブデバイスの情報が新たに送られてきた場合、サービス２００は、既に登録されているサブデバイスの連携登録を解除し、新たにデバイス識別子が送られてきたサブデバイスの連携登録を行う。

図８の例では、サブデバイス１００ｂ、サブデバイス１００ｃのデバイスタイプがデバイスタイプＡであり、このデバイスタイプＡは、最大で１つのサブデバイスのみが登録可能で有るとサービス２００のプロファイルに設定されているとする。この場合、サービス２００は、新たにデバイス識別子が送信されてきたサブデバイス１００ｃの連携登録を行い（ステップＳ３３）、既に登録されているサブデバイス１００ｂの連携登録を解除する（ステップＳ３４）。

解除されうるサブデバイスの候補が複数ある場合には、サービス２００は、例えば相対的位置や利用頻度などのサービスとして認識することが出来る情報に対する条件に基づいて自動的に判断してもよい。サービスの利用中に連携登録の更新が可能であるかについても、サービスのプロファイルに規定されうる。従って、クラウドサービスを利用している最中のサブデバイスは連携登録の更新は不可とサービスのプロファイルで規定されていれば、サービス２００は、デバイス識別子が新たに送られてきても、連携登録の更新をしない。

また、解除されうるサブデバイスの候補が複数ある場合には、サービス２００は、例えば最も古く連携登録されたサブデバイスを解除するようにしてもよく、製造年月日が最も古いサブデバイスを解除するようにしてもよい。もちろんサービス２００は、その他の指標を用いて連携を解除するサブデバイスを決定しうる。

サブデバイスは、サービス２００と直接通信を行ってもよく、メインデバイスを介してサービス２００と接続されていてもよい。もちろん、サブデバイスは多段で接続されていてもよく、サブデバイスとクラウドのサービス２００との通信経路は問わない。

図９は、本実施形態の実施例１の動作を説明する説明図である。図９に示したのは、ユーザ１０が既にメインデバイス１００ａを所有しており、新たにサブデバイス１００ｂを連携させる際の動作を示す説明図である。

ユーザ１０が既にメインデバイス１００ａを所有している状態で、ユーザ１０がサブデバイス１００ｂを触ったり、サブデバイス１００ｂとメインデバイス１００ａとの距離が所定の距離以下になったりするなど、サービス２００で規定された所定の条件を満たすと、メインデバイス１００ａは、サブデバイス１００ｂの存在を検知して、サブデバイス１００ｂにユーザ識別子を送信する（ステップＳ４１）。サブデバイス１００ｂの存在の検知は、例えば情報取得部１５１が取得した情報に基づき、制御部１５３が実行する。

サブデバイス１００ｂは、メインデバイス１００ａからユーザ識別子が送信されると、ユーザ識別子と共にサブデバイス１００ｂのデバイス識別子をサービス２００に送信し、当該ユーザ識別子を有するユーザのデバイスとしてサブデバイス１００ｂを連携登録するよう依頼する（ステップＳ４２）。サービス２００は、サブデバイス１００ｂを連携登録し、その連携登録の結果をメインデバイス１００ａに通知する（ステップＳ４３）。

このように、メインデバイス１００ａからユーザ識別子をサブデバイス１００ｂに渡すことによっても、サブデバイス１００ｂを連携させることが可能になる。しかし、ユーザ識別子という重要な情報を信頼の出来ないサブデバイスに渡すと、そのサブデバイスによって悪用される恐れもある。従って、例えばデバイスの信頼度のようなパラメータを設定し、そのデバイスの信頼度が所定の閾値を超えていれば、メインデバイス１００ａはユーザ識別子をサブデバイスに渡すことが出来るようにしてもよい。

図１０は、本実施形態の実施例１の動作を説明する説明図である。図１０に示したのは、ユーザ１０が既にメインデバイス１００ａ及びサブデバイス１００ｂを所有しており、新たにサブデバイス１００ｃを連携させる際の動作を示す説明図である。

ユーザ１０が既にメインデバイス１００ａ及びサブデバイス１００ｂを所有している状態で、ユーザ１０がサブデバイス１００ｃを触ったり、サブデバイス１００ｃとメインデバイス１００ａとの距離が所定の距離以下になったりするなど、サービス２００で規定された所定の条件を満たすと、メインデバイス１００ａは、サブデバイス１００ｃの存在を検知して、サブデバイス１００ｃにユーザ識別子を送信する（ステップＳ５１）。サブデバイス１００ｃの存在の検知は、例えば情報取得部１５１が取得した情報に基づき、制御部１５３が実行する。

サブデバイス１００ｃは、メインデバイス１００ａからユーザ識別子が送信されると、ユーザ識別子と共にサブデバイス１００ｃのデバイス識別子を、メインデバイス１００ａに連携しているサブデバイス１００ｂに送信する（ステップＳ５２）。サブデバイス１００ｂは、メインデバイス１００ａからユーザ識別子及びサブデバイス１００ｃのデバイス識別子が送信されると、ユーザ識別子及びサブデバイス１００ｃのデバイス識別子をサービス２００に送信し、当該ユーザ識別子を有するユーザのデバイスとしてサブデバイス１００ｃを連携登録するよう依頼する（ステップＳ５３）。サービス２００は、サブデバイス１００ｃを連携登録し、その連携登録の結果をメインデバイス１００ａに通知する（ステップＳ５４）。

なお、図１０に示した動作例において、サブデバイス１００ｃは、メインデバイス１００ａからユーザ識別子を受信する際に、自装置のデバイス識別子を送信するサブデバイス１００ｂに関する情報も受信する。サブデバイス１００ｂに関する情報には、サブデバイス１００ｃがサブデバイス１００ｂに情報を送信するために必要な情報が含まれうる。

なお、デバイス間の通信には、既存の携帯通信網を利用してもよく、Ｗｉ−Ｆｉ等のアクセスポイントを介した通信を利用してもよく、Ｂｌｕｅｔｏｏｔｈ等の機器間の直接的な通信を利用してもよい。そして、最終的にはいずれかのデバイスがクラウドサービスに接続できればよい。

サービス２００は、サブデバイスの連携登録やその解除、サブデバイスの置き換えを自動的に行う仕組みのフォールバックプラン等の用途として、ユーザによって手動で連携登録や解除や置き換えを行う仕組みを有していてもよい。

また各デバイスは、サービス２００へのサブデバイスの連携登録やその解除、サブデバイスの置き換えの際に、その操作が適切に完了したことや逆に失敗したことを、視覚的、聴覚的、触覚的にユーザに通知しうる。

図１１は、あるサブデバイス１００ｂによる、サービス２００へのサブデバイスの連携登録等の確認方法を示す説明図である。サブデバイス１００ｂは、サービス２００へのサブデバイスの連携登録等をユーザに通知するために、ユーザの視覚に訴えるために表示装置１３０ａから情報を出力してもよく、聴覚に訴えるために発音装置１３０ｂから情報を出力してもよく、触覚に訴えるために振動装置１３０ｃから情報を出力してもよい。また、ユーザ１０がＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ；人工知能）のようなデジタルデータを直接理解できるプログラム等である場合に、そのＡＩが認識できるための特定のデータをデータ送信装置１３０ｄから送信してもよい。

上述した２つのプロファイル（サービスプロファイルとデバイスプロファイル）が持つ情報は互いに独立に定義されうるが、サービス２００は、この２つのプロファイルを組み合わせて使うことになる。また、クラウドサービスごとにそれぞれサービスプロファイルの定義を持つことが可能とする。クラウドサービスごとにそれぞれサービスプロファイルの定義を持つのは、クラウドサービスの利用形態に応じてサービスプロファイルを変えられるようにするためである。どのサービスプロファイルを利用するかは、各々のサービスが適切に判断するものとする。

同様に、各デバイスも複数のデバイスプロファイルを持っていてもよい。それぞれのサブデバイスが提供できる機能が１つだけとは限らないからである。サブデバイスは連携登録時には複数のデバイスプロファイルをサービスに提供し、そのサブデバイスが有する機能のうち、どの機能を連携して利用するかについては、各デバイスが、サービスに提供されたデバイスプロファイルを用いて判断してもよい。

ここで、上述した実施例１を具体的なサービスに適用した場合の応用例を示す。

（応用例１：ウェアラブルデバイスを利用したオンラインゲーム）
この応用例１では、ユーザがクラウドベースの技術を利用したオンラインゲームをする際に、ゲームコンソールや据え置きのテレビなどの表示デバイス以外に、ユーザが手に持って利用するモーションコントローラなどのセンシングデバイスや、リストバンド型のウェアラブルデバイス、ＡＲ（拡張現実）やＶＲ（仮想現実）等の映像が表示可能なヘッドマウンドディプレイ等を利用するゲームを想定する。

実施例１を適用することで、ユーザは、これらのデバイスについて事前に連携登録をする必要がなくなる。すなわち、ユーザがモーションコントローラを握る、リストバンド型デバイスを装着する、ヘッドマウンドディスプレイを被るなどの行為をとると、サービス側は、自動的に各々のデバイスを連携登録する。サービス側が自動的に各々のデバイスを連携登録することで、ユーザは事前の連携登録なしに、これらのデバイスを用いたオンラインゲームを楽しむことが可能となる。この場合、メインデバイスは何でも良く、例えばゲームコンソールや据え置きのテレビ、ユーザが所持しているスマートフォンなどがメインデバイスとなり得る。

逆に、ユーザがゲームで遊んだ後には、モーションコントローラを離す、リストバンド型デバイスを外す、ヘッドマウンドディスプレイを外すなどの行為をとると、サービス側は、自動的に各々のデバイスの連携登録を解除する。サービス側が自動的に各々のデバイスの連携登録を解除することで、ユーザはオンラインゲームを楽しんだ後に、連携登録の解除のためには何もする必要が無い。

また、ゲームをプレイしている途中で、例えばユーザが身に付けたヘッドマウントディスプレイが故障してしまった場合には、予備のヘッドマウントディスプレイや、他のユーザのヘッドマウントディスプレイを借りて装着すると、サービス側が自動的にその新しいヘッドマウントディスプレイを連携登録する。サービス側が自動的に新しいヘッドマウントディスプレイを連携登録することで、ユーザは事前の連携登録なしに、新しいヘッドマウントディスプレイを用いたオンラインゲームを楽しむことが可能となる。

この場合、サービスはヘッドマウントディスプレイに対するデバイスプロファイルの提供を受けており、ヘッドマウントディスプレイに対するデバイスプロファイルを持っているデバイスが、ヘッドマウントディスプレイとみなされるものとする。さらにサービスは、ヘッドマウントディスプレイのプロファイルを持ったサブデバイスの数は、各々の利用者に対して高々１つであるという条件を持っていてもよい。このような条件を有していることにより、ユーザが新しいヘッドマウンドディスプレイを装着したことで、サービスは、それまで連携登録していたヘッドマウントディスプレイとの連携を自動的に解除することができる。

（応用例２：ゴルフの上達のための改善サービス）
応用例２では、実際にユーザがゴルフをラウンドした際に、クラブのスイング軌道や、ユーザがクラブで打ったゴルフボールの曲がりなどのデータを取得して、ゴルフ上達のための情報を提供するサービスを考える。

ユーザが使用するゴルフクラブ、キャディバッグ、ゴルフボールなどのゴルフ用品に予めセンサを埋め込んでおく。ゴルフクラブの場合は、センサによってスイング軌道やスイング速度、ゴルフボールがヒットしたヘッド上の位置や角度などを記録可能となっている。またゴルフボールの場合は、センサによって飛んだ軌道が記録できるようになっている。ただし、ゴルフクラブもゴルフボールもクラウドと直接通信できる機能は持っておらず、近距離に存在するデバイスに対して、各々のデバイス内部の情報を提供できる程度の通信機能を持っていればよい。

ユーザは、ゴルフをプレイする際に、ズボンのポケットなどにスマートフォン等のメインデバイスとなりうるデバイスを保持しているとする。ユーザがゴルフクラブを握ると、スマートフォンがそのゴルフクラブを認識して、サービス側に連携を依頼する。

ユーザがそのゴルフクラブでゴルフボールを打つと、その時点で打たれたゴルフボールをゴルフクラブが認識し、スマートフォン経由でサービス側に連携を依頼する。同様にティーなど他の道具もサービス側で連携登録される。

メインデバイスであるスマートフォン経由で、実際に使われたゴルフクラブやゴルフボールの識別子がクラウド上のサービスに送信されている。サービス側は、ユーザがどのゴルフクラブとゴルフボールが使われたのかを把握することが可能な状態となっている。

プレイ中のゴルフボールの軌道に関する情報はゴルフボールの中に蓄積され、各打のタイミングなどのスマートフォンとゴルフボールとが通信可能な距離になった場合に、その軌道情報がスマートフォンに送信される。スマートフォンは軌道情報を受信すると、その軌道情報をクラウド上のサービスに転送する。

同様に、各打のゴルフクラブのスイングの情報は、ユーザがゴルフボールを打ったタイミングでスマートフォンに送信される。スマートフォンはスイング情報を受信すると、そのスイング情報をクラウド上のサービスに転送する。この結果、サービスはユーザの実際のラウンド中に適宜データを収集することが可能となる。

そして、ユーザがラウンドを終了した時点では全てのデータが収集されているので、サービスは、そのデータを用いてユーザのプレイの診断を行って、次回のラウンドに活かせるアドバイスを含んだ診断結果をユーザに提供することが出来る。

普通、１人のユーザがゴルフのラウンド中に使用するゴルフボールは１つだけである。従って、サービス側は、ゴルフボールのプロファイルを持つデバイスの最大連携数を１と規定することで、ウォータハザードやＯＢ後などのようにユーザが別のゴルフボールを使った場合に、新しいゴルフボールを打ったタイミングで新しいゴルフボールを連携登録すると同時に、それまで使っていたゴルフボールの連携登録を解除することができる。また、ゴルフのラウンド中で使用可能なゴルフクラブの数は最大で１４本であるので、サービス側は、ゴルフクラブのプロファイルを持つデバイスの最大連携数を１４と規定すればよい。

ユーザは、ゴルフクラブやゴルフボールを新たに連携した時に、一連のゴルフの所作の中で連携されたかどうかを確認できる。例えば、ゴルフクラブは、ユーザがグリップした後にグリップ部分を振動させる等して、そのゴルフクラブがサービスで連携登録されたことをユーザに伝えることができる。また例えば、ゴルフボールは、ユーザがゴルフクラブで打った後に数秒間点灯する等して、そのゴルフボールがサービスで連携登録されたことをユーザに伝えることができる。

（応用例３：サッカーの試合のデータ化サービス）
応用例３では、サッカーの試合の内容をデータ化するサービスを考える。このケースでは、サブデバイスとして、選手の靴、サッカーボール、グラウンドを例に説明する。靴には、選手と所属チームとを識別できる情報が入っているとする。また、靴やボールの位置はグラウンドが識別可能であり、ボールは靴と接触することで、ボールに触れた靴から選手やチームの情報を受け取ることができるとする。

このサッカーの試合のデータ化サービスを利用する際に、試合前にそれぞれのデバイスの連携登録の作業をすることなく、このサービスが利用可能となることを、サッカーの試合経過を追って説明する。

試合が始まる前には、スマートフォン等のメインデバイスと連携しているサブデバイスがグラウンドのみである。このグラウンドは、スマートフォン等のメインデバイス経由でクラウド上のサービスに連携している。このグラウンドというサブデバイスは固定であるために、サービスの利用開始と同時に常に連携していることになる。

両チームの選手と、ボールがグランドに入る。この時に、グラウンドはボールと選手の靴が所定の領域内に入って来たことを検知して、ボールのプロファイルを持つサブデバイスであるサッカーボールを１つ、選手というプロファイルを持つサブデバイスである靴を人数分、サービスに登録する。

主審がキックオフの笛を鳴らして試合が始まると、そのタイミングで、ボールと靴は接することになり、ボールには、ボールと靴が接触した時刻が記録されると共に、その靴が持つ選手の情報が転送される。ボールと靴が接触した時刻及びその靴が持つ選手の情報は逐次ボールに転送されていくので、試合中はボールの中に勝手に情報が溜まっていく。もちろん、ボールではなく選手の靴の方に情報を溜めていくという方法でもよいし、また、ボールと靴の両方に情報を溜めていくという方法でもよい。

試合が進み、ボールがタッチラインを割った際に、マルチボールシステムの場合にはボールが変わることがある。ボールが変わる時、このサービスのプロファイルには、ボールというプロファイルを持つサービスは最大でも１つと規定しておくことで、新しいボールがグラウンドの中に入って来たタイミングで、連携されるボールが自動的にサービス側で置き換わる。

また、選手が治療等の為に一時的にピッチの外に出た場合、グラウンドはその範囲外に選手の靴が出たことが分かるので、そのタイミングでサービスに対して連携登録の解除を依頼しても良い。選手交代の場合も同様に、選手がグラウンドから出ると、メインデバイスは、サービスに対してその選手の靴の連携登録の解除を依頼し、新しい選手がグラウンドに入ると、サービスに対してその選手の靴の連携登録を依頼できる。

ハーフタイム間や、試合後等は、ボールや靴といったサブデバイスがグラウンドの外に出るので、メインデバイスは、サービスに対してそのタイミングで自動的に連携登録の解除を依頼できる。

この例ではグラウンド、ボール、靴というサブデバイスを例に説明したが、実際には、ゴール、キーパーの手袋なども連携させたとしても、ユーザに事前に連携させるための行動をさせることなく、サービスを利用するためにサブデバイスをサービスに連携登録させることが可能である。

なお、この応用例３でサッカーの試合のデータ化サービスを例に挙げたが、もちろん他の団体競技でも同様な処理を行って道具同士の連携が行われるようにしても良い。例えばカーリングを例に挙げると、カーリングで得点を出す際に、中心からの距離を人がコンパスのようなもので計測する際に、計測を人が行うのではなく、センサを使って自動的に測定できるシステムを含んだカーリング施設向けサービスが考えられる。カーリングは、それぞれのチームは４人で構成され、１つのエンドで各選手が２つずつストーンを投じるので、１つのチームが１つのエンドで投じるストーンは８つである。

従って、ゲームを開始する際に、各チーム８個のストーンがリンク上に置かれたことをトリガとして、チーム単位で８つのストーンをサブデバイスとして連携することで、ストーンで取得した情報のクラウドサービスへの送信が出来る。すなわち、カーリングで得点を出す際に、センサを使って中心からの距離を自動的に各ストーンが算出することで、クラウドサービス側で自動的に得点を算出することができる。その場合は、例えばストーンという属性を有するサブデバイスの下限及び上限を８に設定しておけば、チーム単位で８つのストーンをサブデバイスとして連携してからで無ければ、クラウドサービスを利用できないようにすることが可能となる。

（その他の応用例）
その他の応用例として、メインデバイスが自動車であり、サブデバイスがデジタルビデオカメラである例が考えられる。メインデバイスである自動車の運転席のダッシュボードの上などの所定の場所に、サブデバイスであるデジタルビデオカメラを置くことで、デジタルビデオカメラが、クラウドサービス上で自動車と連携される。自動車は、デジタルビデオカメラの機能である動画像の撮像機能を用いて、デジタルビデオカメラをドライブレコーダとして動作させることが可能になる。

［１．３．実施例２］
続いて、実施例２について説明する。この実施例２は、実施例１のようなシステムと同じようなシステムを想定する。つまりこの実施例２は、サービスに対して、利用者が必要とするデバイスを自動的に連携可能とするシステムを想定する。

この実施例２では、サブデバイスの連携登録の際に、ユーザに紐づいているサブデバイス間のネットワーク帯域の最適化を自動的に実行する。例えば、３Ｇ回線のみを使用できるサブデバイスと、４Ｇ（ＬＴＥ）回線を使用できるサブデバイスとが存在していれば、４Ｇ（ＬＴＥ）回線を使用できるサブデバイスが、サービスと通信するデバイスとして、サブデバイスの連携登録の際に選択される。ユーザに紐づいているデバイスの中の少なくとも１つデバイスが、全てのデバイスの状況を監視する機能を持っているとする。

デバイスの状況を監視する機能を持つデバイスは、各デバイスに対してネットワーク帯域情報を通知することで、デバイス間のネットワーク帯域を調整することができる。なお、デバイスの状況を監視する機能を持つデバイスが実行する帯域調整機能はプログラマブルであってもよい。帯域調整機能はプログラマブルであることで、サービスを利用するユーザ自身がネットワーク帯域を決定したり、サービスからネットワーク帯域の調整方法をダウンロードして、その調整方法に基づいて帯域を調整したりしてもよい。

デバイスの状況を監視する機能を持つデバイスが実行するのは、デバイス間のネットワークの帯域制御に限られない。例えば、デバイス間の音声キャリブレーションなども、ユーザによって調整するのではなく、デバイス間で自動的に行われうる。

図１２は、本実施形態の実施例２の動作を説明する説明図である。図１２に示したのは、デバイス間での音声キャリブレーションを自動的に行う際の動作例である。

あるサブデバイス１００ｂ、１００ｘが、スピーカなどの発音機能を用いて音を出力し（ステップＳ６１）、別のサブデバイス１００ｃが、マイクなどの聴覚機能を用いてその音を集音すると、サブデバイス１００ｃは集音した音をサービス２００に送信する（ステップＳ６２）。

サービス２００は、サブデバイス１００ｃから送信された音を解析し、キャリブレーションの必要があると判断すると、サブデバイス１００ｃに対して音声キャリブレーションの指示を送信する（ステップＳ６３）。この音声キャリブレーションの指示として、サブデバイスを指定してのキャリブレーションの指示が行われても良い。

サービス２００から音声キャリブレーションの指示を受けたサブデバイス１００ｃは、他のサブデバイス１００ｂ、・・・、１００ｘに対して、音声キャリブレーションの指示を伝える（ステップＳ６４）。サブデバイス１００ｃは、サービス２００から指定されたサブデバイスに対してのみ音声キャリブレーションの指示を伝えてもよい。

ここで、上述した実施例２を具体的なサービスに適用した場合の応用例を示す。

（応用例１：マルチスピーカによるサラウンドシステムの帯域制御と同期）
応用例１では、５．１チャンネルや２２．１チャンネルなどの、複数のスピーカを利用したサラウンドシステムの帯域制御と同期について考える。このシステムは、複数のスピーカを利用したサラウンドシステムを、ユーザが保持している様々なデバイスのスピーカ機能を連携させて、クラウド側から音楽をストリーム再生するようなサービスであるとする。

デバイスの中には、クラウド上のサービスと直接接続可能なデバイスと、連携している他のデバイス経由でクラウド上のサービスと接続可能となるデバイスとが存在する。クラウド上のサービスと直接接続可能な１つ以上のデバイスが、クラウド側から音声ストリームを取得する。クラウド側から音声ストリームを取得する際、クラウド上のサービスと直接通信が出来ないデバイスから出力する音声データは、直接接続可能なデバイス経由で取得することになる。ここで、デバイス間の負荷に偏りがなく、安定してストリーム再生ができるように、帯域の調整をデバイス間で常に行う。

また、このような仕組みでサラウンドシステムを実現した場合、デバイス間の通信環境によっては遅延が生じて、それぞれのスピーカから出力される音の同期がずれる可能性がある。そこでこのサラウンドシステムは、デバイス間で同期のずれを検知して自動的にキャリブレーションを行う。同期ずれの検知は、上述したように、スピーカから出力される音をあるデバイスがマイクで集音し、集音した音がずれていないかどうかで行われうる。

［１．４．実施例３］
続いて、実施例３について説明する。この実施例２は、実施例１のようなシステムと同じようなシステムを想定する。つまりこの実施例３は、サービスに対して、利用者が必要とするデバイスを自動的に連携可能とするシステムを想定する。

この実施例３では、デバイスを連携する際に、連携したデバイスが持つ全ての機能を利用可能とするのではなく、一部の機能のみを利用可能とする例を示す。具体的には、各々のデバイスが持つデバイスプロファイルに、連携時に公開可能な機能（アクセス権）を設定する。そして、デバイスが連携登録された時には、そのアクセス権に従って、そのデバイスが連携可能であるかをサービスで判断する。

図１３は、本開示の実施の形態の実施例３について説明するための説明図である。図１３は、クラウドサービスとして、連携しているサブデバイスのカメラのような撮影機能を用いて監視カメラの機能を果たす監視カメラサービス２００ａを例に挙げている。

監視カメラサービス２００ａは、所定の監視対象、例えば建物全体を監視し、その監視映像を解析して特定の対象物等を発見するようなクラウドサービスである。この監視カメラサービス２００ａは、監視映像の撮影には、建物に備え付けられている固定されたカメラ以外に、建物の近くの該当にある定点カメラや、建物の内部に存在するスマートフォンなど、建物の内部やその周辺に存在するカメラ機能を持つデバイスを活用することを考える。

監視カメラサービス２００ａは、通常時では、建物に備え付けのカメラでのみ監視映像の撮影を行う。しかし、特定の人や物を発見し、それを追従する場合には、監視カメラサービス２００ａは、他のカメラを備えるデバイスで撮影した映像も利用する。この際、すべてのスマートフォン等のカメラ機能を持つデバイスと連携できるのではなく、各々のデバイスが持つプロファイルで、カメラの機能に関して連携可能という状態になっているデバイスと連携する。

監視カメラサービス２００ａは、性能タイプが「Ａ」であるサブデバイスの撮影機能を利用することをサービスプロファイルで規定している。この場合、性能タイプが「Ａ」であるとデバイスプロファイルで規定されているサブデバイス１００ｂ、１００ｘは、監視カメラサービス２００ａによって撮影機能が利用されるが、性能タイプが「Ｂ」であるとデバイスプロファイルで規定されているサブデバイス１００ｃは、監視カメラサービス２００ａによって撮影機能が利用されない。このように、サービスプロファイルで規定されている機能をデバイスが有しているかどうかで、その機能が利用されるデバイスを異ならせることが出来る。

図１４は、実施例３における動作例を示すシーケンス図である。図１４に示したのは、メインデバイス１００ａがサブデバイス１００ｂのデバイスプロファイルと、サービス２００のサービスプロファイルとを取得して、サブデバイス１００ｂの機能を利用する際の動作例である。

まずメインデバイス１００ａがサブデバイス１００ｂの存在を検知すると（ステップＳ１０１）、メインデバイス１００ａは、サブデバイス１００ｂからデバイス識別子を取得する（ステップＳ１０２）。

サブデバイス１００ｂからデバイス識別子を取得すると、メインデバイス１００ａは、サブデバイス１００ｂのデバイス識別子をサービス２００へ送信することでサービス２００へ連携登録を依頼する（ステップＳ１０３）。サービス２００は、サブデバイス１００ｂの連携登録処理を実行し（ステップＳ１０４）、連携登録が完了したことを、メインデバイス１００ａへ通知する（ステップＳ１０５）。

連携登録の完了の通知を受けたメインデバイス１００ａは、サービス２００に対してサービスプロファイルを請求する（ステップＳ１０６）。メインデバイス１００ａは、サービスプロファイルの請求に応じてサービス２００から送られてくるサービスプロファイルを取得する（ステップＳ１０７）。

またメインデバイス１００ａは、サブデバイス１００ｂに対してデバイスプロファイルを請求する（ステップＳ１０８）。メインデバイス１００ａは、デバイスプロファイルの請求に応じてサブデバイス１００ｂから送られてくるデバイスプロファイルを取得する（ステップＳ１０９）。このサービスプロファイル及びデバイスプロファイルの取得順はもちろん逆でも構わない。

メインデバイス１００ａは、サブデバイス１００ｂのデバイスプロファイルと、サービス２００のサービスプロファイルとをチェックする（ステップＳ１１０）。メインデバイス１００ａは、チェックの結果、サブデバイス１００ｂのデバイスプロファイルがサービス２００のサービスプロファイルの条件に適していれば、サブデバイス１００ｂの機能を利用する（ステップＳ１１１）。

メインデバイス１００ａは、サブデバイス１００ｂのデバイスプロファイルと、サービス２００のサービスプロファイルとを取得して、それぞれの内容をチェックすることで、サービス２００のサービスプロファイルの条件に適していれば、サブデバイス１００ｂの機能を利用することができる。

なお、機能を軸にしたアクセス権だけでなく、連携元の人や、物などのデバイスを軸としたアクセス権や、時間を軸にしたアクセス権などが設定されていても良い。

実施例３によれば、デバイスプロファイルの内容に基づいてデバイスの機能の利用を制御することができるので、デバイスの持ち主が望まない連携登録や連携後の動作が勝手に行われることを避けることができる。

この実施例３のように、メインデバイスが他のデバイスと連携する際に、連携したサブデバイスが持つ全ての機能を利用可能とするのではなく、一部の機能のみを利用可能とする場合、サブデバイスは、その機能だけを起動させてメインデバイスから使用できる状態にしても良い。例えば、サブデバイスがテレビであり、スピーカ機能だけをメインデバイスから連携しようとする場合、テレビ自体を起動させるのではなく、テレビのスピーカ機能だけが起動されて、そのスピーカ機能がメインデバイスから利用可能な状態になってもよい。

サブデバイスの一部の機能だけを起動させることで、機能の起動時間を短縮させたり、メインデバイスとの連携時におけるサブデバイスの消費電力を低減させたり、連携に必要が無い機能が起動していないことによってセキュリティを高めたりする効果を奏する。

［１．５．実施例４］
ここまでの実施例では、メインデバイスとサブデバイスという２種類のデバイスが規定されていた。しかし、場合によってはメインデバイスとなり得るデバイスが存在しない場合もある。実施例４では、そのようなメインデバイスとなり得るデバイスが存在しない場合を挙げて説明する。

例えば、コンタクトレンズ型のデバイスなど、侵襲性のデバイスをユーザが利用しているケースを考える。そのデバイスは、ユーザを識別できる情報（ユーザ識別子）を持っている。この侵襲性のデバイス自体は、クラウドサービスと通信する機能を持っている必要はない。ただし、ユーザ識別子を持っているデバイスが、クラウドサービスと通信する機能を持っていない場合は、連携するサブデバイスの１つがクラウドサービスと通信できる機能を有している必要がある。もちろん侵襲性のデバイスがクラウドサービスとの通信機能を持っていてもよいが、その場合には、上述した実施例１と同じ例として扱うことが可能となる。

図１５は、本開示の実施の形態の実施例４について説明するための説明図である。図１５は、ユーザ１０がメインデバイス１０１ａとして、デバイス自身はクラウドサービスと通信する機能を持たない侵襲性デバイスを装着している場合の動作例を示したものである。メインデバイス１０１ａは、ユーザ１０を識別できるユーザ識別子を内部で保持している。

サービス２００で利用するサブデバイス１００ｂを連携する際には、メインデバイス１０１ａはサービス２００と通信できないので、サブデバイス１００ｂは、ユーザ１０が使用している侵襲性のメインデバイス１０１ａを検知し、メインデバイス１０１ａが保持しているユーザ識別子を取得する（ステップＳ７１）。

サブデバイス１００ｂは、メインデバイス１０１ａからユーザ識別子を取得すると、サブデバイス１００ｂが、ユーザ識別子及び自身のデバイス識別子をサービス２００へ送信することで、サービス２００に連携登録を依頼する（ステップＳ７２）。もし、既に連携済みのサブデバイス１００ｃが存在していれば、サブデバイス１００ｂは、その連携済みのサブデバイス１００ｃへユーザ識別子及び自身のデバイス識別子を送り、サブデバイス１００ｃに対してサービス２００へ連携登録するよう依頼してもよい（ステップＳ７３）。

すなわち、この実施例４では、内部的には連携しているが、クラウド上のサービス２００が各々のサブデバイスを把握できていない可能性もあることを示している。実際にクラウド上のサービス２００が各々のサブデバイスを把握できるのは、そのサブデバイスの中に、クラウドと通信可能なサブデバイスと連携したタイミングということになる。

（応用例：ゴルフの上達のための改善サービス）
実施例４の応用例として、先に実施例１の応用例として示した、ゴルフの上達のための改善サービスに適当した場合の例を示す。先に示した例では、スマートフォンというメインデバイスが存在したが、この例では、ユーザが、ゴルフのプレイ中にスマートフォンをロッカーの中に仕舞う等して保持せずにプレイするような状況を考える。

この時、ユーザは、ユーザ識別子を持つデバイスとして、コンタクトレンズ型等の侵襲性のデバイスを身に着けているとする。ゴルフクラブやゴルフボールが持っている機能や性能は先の実施例１の応用例で示した物と同じとする。

ここで先の実施例１の応用例とは異なり、新たにゴルフバッグに通信機能を持たせるケースを考える。ユーザがゴルフバッグからゴルフクラブを抜き取る際に、そのゴルフクラブが連携登録される必要がある。このとき、ゴルフクラブはコンタクトレンズ型等の侵襲性のデバイスからユーザＩＤを取得して、取得したユーザＩＤと、自らが持つデバイス識別子とをゴルフバッグに送信する。

ゴルフバッグは、通信機能を利用してゴルフクラブから送信された情報をクラウドサービスに送信することで、ユーザがゴルフバッグから抜き取ったゴルフクラブの連携登録をクラウドサービスに依頼する。

ユーザがゴルフボールを打って、ゴルフクラブをゴルフバッグに仕舞うと、ゴルフクラブは、加速度センサなどによって得たスイング情報をゴルフバッグに送信する。ゴルフバッグは、ゴルフクラブから送信されたスイング情報をクラウドサービスに送信する。

連携するデバイスがゴルフボールの場合では、ユーザがゴルフバッグからゴルフボールを取り出す際に、ゴルフクラブの場合と同様に連携登録が行われる。そしてホールアウトした際など、再度ゴルフボールとゴルフバッグとが通信可能となる一定の距離以下になった際に、ゴルフボールが保持している軌道の情報が、ゴルフバッグ経由でクラウドサービスに送信されることになる。

このようにサービスを実現することで、ユーザがサービス２００を利用する際にスマートフォン等のメインデバイスが存在しない実施例４のようなケースでも、クラウド上のサービス２００が利用できる状況を作ることができる。

＜２．ハードウェア構成例＞
次に、図１６を参照して、本開示の一実施形態にかかるサービス２００のハードウェア構成について説明する。図１６は、サーバ７００の概略的な構成の一例を示すブロック図である。サーバ７００は、プロセッサ７０１、メモリ７０２、ストレージ７０３、ネットワークインタフェース７０４及びバス７０６を備える。

プロセッサ７０１は、例えばＣＰＵ（Central Processing Unit）又はＤＳＰ（Digital Signal Processor）であってよく、サーバ７００の各種機能を制御する。メモリ７０２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）を含み、プロセッサ７０１により実行されるプログラム及びデータを記憶する。ストレージ７０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。

ネットワークインタフェース７０４は、サーバ７００を通信ネットワーク７０５に接続するための有線通信インターフェースである。

バス７０６は、プロセッサ７０１、メモリ７０２、ストレージ７０３及びネットワークインタフェース７０４を互いに接続する。バス７０６は、速度の異なる２つ以上のバス（例えば、高速バス及び低速バス）を含んでもよい。

図１６に示したサーバ７００において、図４を参照して説明した処理部２３０に含まれる１つ以上の構成要素（情報取得部２３１及び／又は制御部２３３）は、プロセッサ７０１において実装されてもよい。一例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがサーバ７００にインストールされ、プロセッサ７０１が当該プログラムを実行してもよい。別の例として、サーバ７００は、プロセッサ７０１及びメモリ７０２を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムをメモリ７０２に記憶し、当該プログラムをプロセッサ７０１により実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてサーバ７００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるための上記プログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

次に、図１７を参照して、本開示の一実施形態にかかるデバイス１００のハードウェア構成について説明する。図１７は、本開示の実施形態にかかるデバイス１００のハードウェア構成例を示すブロック図である。上記の各アルゴリズムは、例えば、図１７に示す情報処理装置のハードウェア構成を用いて実行することが可能である。つまり、当該各アルゴリズムの処理は、コンピュータプログラムを用いて図１７に示すハードウェアを制御することにより実現される。

なお、この図１７に示したハードウェア９００のハードウェアの形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、ＰＨＳ、ＰＤＡ等の携帯情報端末、ゲーム機、接触式又は非接触式のＩＣチップ、接触式又は非接触式のＩＣカード、スピーカ、テレビ、モニタ、ウェアラブル機器、又は種々の情報家電がこれに含まれる。但し、上記のＰＨＳは、Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍの略である。また、上記のＰＤＡは、Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔの略である。

図１７に示すように、このハードウェア９００は、主に、ＣＰＵ９０２と、ＲＯＭ９０４と、ＲＡＭ９０６と、ホストバス９０８と、ブリッジ９１０と、を有する。さらに、このハードウェアは、外部バス９１２と、インターフェース９１４と、入力部９１６と、センシング部９１７と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６と、を有する。但し、上記のＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略である。また、上記のＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略である。そして、上記のＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略である。

ＣＰＵ９０２は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、又はリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ＲＯＭ９０４は、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する手段である。ＲＡＭ９０６には、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等が一時的又は永続的に格納される。

これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８を介して相互に接続される。一方、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続される。また、入力部９１６としては、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等が用いられる。さらに、入力部９１６としては、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントローラ（以下、リモコン）が用いられることもある。センシング部９１７は、図３に示したセンサ１４０に対応し、様々な状態をセンシングする装置である。例えば、センシング部９１７は人体の接触や近接、または他の装置の接触や近接をセンシングする装置である。センシング部９１７としては、例えば抵抗膜式や静電容量式のタッチセンサ等が用いられることもある。またセンシング部９１７は、他の装置から発せられた電波の電波強度、音の強さ、光の強さなどをセンシングするデバイスが用いられることもある。また例えば、センシング部９１７は、現在の位置をセンシングする装置である。

出力部９１８としては、例えば、ＣＲＴ、ＬＣＤ、ＰＤＰ、又はＥＬＤ等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、バイブレータ、又はファクシミリ等、取得した情報を利用者に対して視覚的、触覚的又は聴覚的に通知することが可能な装置である。但し、上記のＣＲＴは、Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅの略である。また、上記のＬＣＤは、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙの略である。そして、上記のＰＤＰは、Ｐｌａｓｍａ ＤｉｓｐｌａｙＰａｎｅｌの略である。さらに、上記のＥＬＤは、Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ Ｄｉｓｐｌａｙの略である。

記憶部９２０は、各種のデータを格納するための装置である。記憶部９２０としては、例えば、ハードディスクドライブ（ＨＤＤ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等が用いられる。但し、上記のＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略である。

ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、又はリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ ＤＶＤメディア、各種の半導体記憶メディア等である。もちろん、リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。但し、上記のＩＣは、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略である。

接続ポート９２４は、例えば、ＵＳＢポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ、ＲＳ−２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。但し、上記のＵＳＢは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略である。また、上記のＳＣＳＩは、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅの略である。

通信部９２６は、ネットワーク９３２に接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ用の通信カード、光通信用のルータ、ＡＤＳＬ用のルータ、又は接触又は非接触通信用のデバイス等である。また、通信部９２６に接続されるネットワーク９３２は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、又は衛星通信等である。但し、上記のＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略である。また、上記のＷＵＳＢは、Ｗｉｒｅｌｅｓｓ ＵＳＢの略である。そして、上記のＡＤＳＬは、Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅの略である。

図１７に示したハードウェア９００において、図３を参照して説明したデバイス１００の処理部１５０に含まれる１つ以上の構成要素（情報取得部１５１及び／又は制御部１５３）は、ＣＰＵ９０２において実装されてもよい。また図１７に示したハードウェア９００において、またドライブ９２２、リムーバブル記録媒体９２８、接続ポート９２４及び外部接続機器９３０は必須の構成では無い。また図１７に示したハードウェア９００において、図１１の表示装置１３０ａ、発音装置１３０ｂ、振動装置１３０ｃは出力部９１８として構成されうる。また図１７に示したハードウェア９００において、図１１のデータ送信装置１３０ｄは通信部９２６として構成されうる。

＜３．まとめ＞
以上説明したように本開示の実施の形態によれば、サービスが規定する所定の条件をデバイス間の関係が満たした場合に、サービスに対してデバイスの連携登録を依頼することが可能なデバイス及びサービスが提供される。

サービスが規定する所定の条件をデバイス間の関係が満たした場合に、サービスに対してデバイスの連携登録を依頼することで、サービスを利用する際に必要となるデバイスを予め登録する必要が無く、またその所定の条件を満たしたタイミングにおいて連携方法を変えることが出来る。従って本開示の実施の形態によれば、新たにデバイスを使用してサービスを利用する際のユーザの利便性を大きく向上させることができる。

本開示の実施の形態によれば、連携したデバイス間（メインデバイスとサブデバイスとの間、またはサブデバイス同士）で、自動的にネットワーク負荷を調整したり、キャリブレーションを行ったりすることが可能になり、ユーザのこのような処理を行う負荷を大きく低減させることが出来る。

本開示の実施の形態によれば、デバイスプロファイルに基づいたアクセス制御が可能になるので、デバイスの持ち主が望まない連携登録や連携後の動作が勝手に行われることを避けることができる。

本明細書の処理における処理ステップは、必ずしもフローチャート又はシーケンス図に記載された順序に沿って時系列に実行されなくてよい。例えば、処理における処理ステップは、フローチャート又はシーケンス図として記載した順序と異なる順序で実行されても、並列的に実行されてもよい。

また、本明細書の装置（例えば、端末装置、基地局もしくは制御エンティティ、又はそのモジュール）に備えられるプロセッサ（例えば、ＣＰＵ、ＤＳＰなど）を上記装置として機能させるためのコンピュータプログラム（換言すると、上記プロセッサに上記装置の構成要素の動作を実行させるためのコンピュータプログラム）も作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供されてもよい。また、上記コンピュータプログラムを記憶するメモリと、上記コンピュータプログラムを実行可能な１つ以上のプロセッサとを備える装置（例えば、完成品、又は完成品のためのモジュール（部品、処理回路若しくはチップなど））も提供されてもよい。また、上記装置の１つ以上の構成要素（例えば、情報取得部及び／又は制御部など）の動作を含む方法も、本開示に係る技術に含まれる。

また上述の説明で用いた機能ブロック図で示したそれぞれの機能ブロックの一部又は全部は、たとえばインターネット等のネットワークを介して接続されるサーバ装置で実現されてもよい。また上述の説明で用いた機能ブロック図で示したそれぞれの機能ブロックの構成は、単独の装置で実現されてもよく、複数の装置が連携するシステムで実現されても良い。複数の装置が連携するシステムには、例えば複数のサーバ装置の組み合わせ、サーバ装置と端末装置との組み合わせ等が含まれ得る。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼する制御部を備える、情報処理装置。
（２）
前記所定の条件は、前記第１の装置との位置関係が所定の関係となった場合であり、前記制御部は、前記第１の装置との位置関係が前記所定の関係となると前記処理を前記サービスへ依頼する、前記（１）に記載の情報処理装置。
（３）
前記所定の条件は、前記第１の装置が接触または近接したことであり、前記制御部は、前記第１の装置が接触または近接したことを検出すると前記処理を前記サービスへ依頼する、前記（１）に記載の情報処理装置。
（４）
前記制御部は、連携させた前記第１の装置との間で交換する情報を、前記第１の装置の属性に基づいて変化させる、前記（１）〜（３）のいずれかに記載の情報処理装置。
（５）
前記制御部は、前記処理の依頼の際に用いる情報を、前記第１の装置の信頼度に基づいて変化させる、前記（４）に記載の情報処理装置。
（６）
前記制御部は、前記第１の装置と異なる第２の装置との関係を認識して前記処理を前記サービスへ依頼する、前記（１）〜（５）のいずれかに記載の情報処理装置。
（７）
前記制御部は、連携させた前記第１の装置が持っている機能の少なくとも一部を使用する、前記（１）〜（６）のいずれかに記載の情報処理装置。
（８）
前記制御部は、連携させた前記第１の装置が持っている一部の機能のみを前記第１の装置で起動させる、前記（７）に記載の情報処理装置。
（９）
前記制御部は、前記第１の装置が持つ機能のアクセス権に基づいて連携する機能を決定する、前記（１）〜（８）のいずれかに記載の情報処理装置。
（１０）
前記制御部は、前記第１の装置から前記デバイス識別子を取得して、自装置が保持する前記ユーザ識別子との前記処理を前記サービスへ依頼する、前記（１）〜（９）のいずれかに記載の情報処理装置。
（１１）
前記制御部は、前記第１の装置から前記ユーザ識別子を取得して、自装置が保持する前記デバイス識別子との前記処理を前記サービスへ依頼する、前記（１）〜（９）のいずれかに記載の情報処理装置。
（１２）
前記制御部は、前記第１の装置の所定のパラメータが所定の条件を満たしていれば、該第１の装置に前記ユーザ識別子を提供する、前記（１１）に記載の情報処理装置。
（１３）
前記制御部は、前記ユーザ識別子に加え、前記サービスにおけるユーザを識別する情報を前記サービスへ送信する、前記（１）〜（１２）のいずれかに記載の情報処理装置。
（１４）
ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することを含む、情報処理方法。
（１５）
ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することをコンピュータに実行させる、コンピュータプログラム。
（１６）
提供するネットワーク上のサービスにおけるユーザを識別するユーザ識別子と、前記サービスを利用する第１の装置を識別するデバイス識別子との連携に関する処理を実行する制御部を備え、
前記制御部は、前記第１の装置と異なる第２の装置のデバイス識別子と前記ユーザ識別子との連携に関する処理を行う際に、所定の条件に基づいて前記第１の装置のデバイス識別子と前記ユーザ識別子との連携を解除するかどうかを判断する、制御装置。

１００ａ、１０１ａ メインデバイス
１００ｂ、１００ｃ サブデバイス

Claims (15)

1. ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼する制御部を備え、
   前記制御部は、
   前記第１の装置のバッテリ残量による該第１の装置の動作可能時間が所定値未満である場合には、前記処理を前記サービスへ依頼しない、情報処理装置。
2. 前記所定の条件は、前記第１の装置との位置関係が所定の関係となった場合であり、前記制御部は、前記第１の装置との位置関係が前記所定の関係となると前記処理を前記サービスへ依頼する、請求項１に記載の情報処理装置。
3. 前記所定の条件は、前記第１の装置が接触または近接したことであり、前記制御部は、前記第１の装置が接触または近接したことを検出すると前記処理を前記サービスへ依頼する、請求項１に記載の情報処理装置。
4. 前記制御部は、連携させた前記第１の装置との間で交換する情報を、前記第１の装置の属性に基づいて変化させる、請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記制御部は、前記処理の依頼の際に用いる情報を、前記第１の装置の信頼度に基づいて変化させる、請求項４に記載の情報処理装置。
6. 前記制御部は、前記第１の装置と異なる第２の装置との関係を認識して前記処理を前記サービスへ依頼する、請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記制御部は、連携させた前記第１の装置が持っている機能の少なくとも一部を使用する、請求項１〜６のいずれか１項に記載の情報処理装置。
8. 前記制御部は、連携させた前記第１の装置が持っている一部の機能のみを前記第１の装置で起動させる、請求項７に記載の情報処理装置。
9. 前記制御部は、前記第１の装置が持つ機能のアクセス権に基づいて連携する機能を決定する、請求項１〜８のいずれか１項に記載の情報処理装置。
10. 前記制御部は、前記第１の装置から前記デバイス識別子を取得して、自装置が保持する前記ユーザ識別子との前記処理を前記サービスへ依頼する、請求項１〜９のいずれか１項に記載の情報処理装置。
11. 前記制御部は、前記第１の装置から前記ユーザ識別子を取得して、自装置が保持する前記デバイス識別子との前記処理を前記サービスへ依頼する、請求項１〜９のいずれか１項に記載の情報処理装置。
12. 前記制御部は、前記第１の装置の所定のパラメータが所定の条件を満たしていれば、該第１の装置に前記ユーザ識別子を提供する、請求項１１に記載の情報処理装置。
13. 前記制御部は、前記ユーザ識別子に加え、前記サービスにおけるユーザを識別する情報を前記サービスへ送信する、請求項１〜１２のいずれか１項に記載の情報処理装置。
14. ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することを含む、情報処理方法であって、
    前記第１の装置のバッテリ残量による該第１の装置の動作可能時間が所定値未満である場合には、前記処理を前記サービスへ依頼しない、情報処理方法。
15. ネットワーク上の所定のサービスで規定された所定の条件を第１の装置との関係が満たすと、ユーザを識別するユーザ識別子と、前記第１の装置を識別するデバイス識別子とを前記サービスに送信し、前記ユーザ識別子とデバイス識別子との連携に関する処理を前記サービスへ依頼することをコンピュータに実行させる、コンピュータプログラムであって、
    前記第１の装置のバッテリ残量による該第１の装置の動作可能時間が所定値未満である場合には、前記処理を前記サービスへ依頼しない、コンピュータプログラム。

Images