JP6332915B2

JP6332915B2 - 情報処理装置、情報処理方法及びプログラム

Info

Publication number: JP6332915B2
Application number: JP2013126127A
Authority: JP
Inventors: 健介安間
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-06-14
Filing date: 2013-06-14
Publication date: 2018-05-30
Anticipated expiration: 2033-06-14
Also published as: US20140372587A1; US9923972B2; JP2015001830A

Description

本発明は、情報処理装置、情報処理システム、情報処理装置の制御方法及びプログラムに関する。

デバイスの小型化や無線ＬＡＮの普及により、持ち運び可能なサイズのデバイスがネットワークに接続するようになってきた。更に、ユーザはこれらのデバイスを複数個持ち、用途に応じて利用することが増えてきた。ここでは、スマートフォンと一眼レフカメラの例を挙げる。これら２つのデバイスを持つユーザは、高機能なアプリケーションを利用する時はスマートフォンを利用し、写真を撮る時は一眼レフカメラを利用する。

ところで、メッセージを様々なデバイスに割り当てる技術として、ピーツーピーシステムによる分散処理が知られている。これは、最も処理負荷が低いデバイスにメッセージを転送する技術である。

この負荷分散処理技術をユーザが複数のデバイスを利用する環境に適用した場合、ユーザの意図したデバイスにメッセージが配送されないことがある。実際にユーザが利用しているデバイスに対してメッセージを送信したい場合においても、意図に反して処理負荷の低い別のデバイスに送信されてしまうことがあるからである。

また、ユーザは相手ユーザに対して、現在利用しているデバイスのネットワーク環境（ＩＰアドレス、ポート番号など）を通知しなければならず、相手ユーザが現在利用しているデバイスに対して直接メッセージを送信することはできない。

特許文献１では、移動機器の状態に応じて、発信前に移動機器の状態を知ることによって、移動機器に対して発信可能かどうかを決定する技術が開示されている。

特開2006-157672号公報

しかしながら、特許文献１に記載の技術をユーザが複数のデバイスを持っている場合に適用しても、それぞれのデバイスの状態に応じて、独立してそれぞれのデバイスが発信可能な状態かどうかを判別するだけであり、ユーザの持つ複数のデバイスから適したデバイスを選択することはできない。

結果として、複数のデバイスを保持するユーザは、予め決まったデバイスのネットワーク環境を通知した上でそのデバイスを利用しなければ通信できないため、ユーザビリティが低下するという課題がある。

上記の課題に鑑み、本発明は、ユーザが所望するデバイスにメッセージを到達させることを目的とする。

上記の目的を達成する本発明に係る情報処理装置は、
デバイスの状態を検出するセンサから、前記センサが検出した前記デバイスの状態を示す情報を受信するデバイス状態受信手段と、
前記デバイス状態受信手段により受信された情報が示すデバイスの状態を管理する管理手段と、
メッセージを受信するメッセージ受信手段と、
前記メッセージ受信手段が受信したメッセージを送信する送信先のデバイスを、前記メッセージ受信手段が受信したメッセージの宛先に対応する複数のデバイスから、前記管理手段が管理している複数のデバイスの状態に基づいて選択する選択手段と、
前記選択手段により選択されたデバイスへ、前記メッセージ受信手段が受信したメッセージを送信する送信手段と、
前記メッセージ受信手段により受信されたメッセージを前記選択手段により選択されたデバイスへ前記送信手段が送信したことを、前記メッセージ受信手段により受信されたメッセージの宛先に対応する複数のデバイスのうち、前記選択手段により選択されたデバイス以外のデバイスに通知する通知手段と、
を備えることを特徴とする。

本発明によれば、ユーザが所望するデバイスにメッセージを到達させることが可能となる。

本発明の一実施形態に係る情報処理システムの構成例を示す図。本発明の一実施形態に係る情報処理装置１０６のモジュール構成図。本発明の一実施形態に係るカメラ１０１のモジュール構成図。本発明の一実施形態に係る情報処理装置１０６がセンサ情報を受信した際の処理の手順を示すフローチャート。本発明の一実施形態に係る情報処理装置１０６がメッセージを受信した際の処理の手順を示すフローチャート。本発明の一実施形態に係る情報処理装置１０６が一定時間毎に実行する処理の手順を示すフローチャート。本発明の一実施形態に係る情報処理システムのシーケンス図。本発明の一実施形態に係るカメラ１０３のユーザインタフェースの一例を示す図。本発明の一実施形態に係る各装置とXMPPのアドレスとの対応を示す図。本発明の一実施形態に係るカメラ１０３からユーザＡ宛のメッセージを送信した際の宛先の遷移を示す図。本発明の一実施形態に係る、ユーザＢがカメラ１０３からユーザＡ宛にコンテンツを送信した際のシーケンス図。本発明の一実施形態に係る情報処理装置１０６がメッセージを受信した時の処理の手順を示すフローチャート。

以下、本発明の各実施形態について、添付の図面を参照して説明する。

（第１実施形態）
図１は、本発明の一実施形態に係る情報処理システムの構成例を示す図である。１００は、ネットワークである。本実施形態におけるネットワーク１００は、インターネット、WAN (Wide Area Network)、LAN (Local Area Network)などの複合であっても実現できる。

１０１は、ユーザＡのカメラである。カメラ１０１は、情報処理装置１０６に、XMPPサーバ１０５を介して、センサ情報を送信する。１０２は、ユーザＡのスマートフォンである。スマートフォン１０２は、情報処理装置１０６に、XMPPサーバ１０５を介して、センサ情報を送信する。１０３は、ユーザＢのカメラである。カメラ１０３は、情報処理装置１０７に、XMPPサーバ１０５を介して、センサ情報を送信する。

１０４は、ユーザＢのプリンタである。プリンタ１０４は、情報処理装置１０７に、XMPPサーバ１０５を介して、センサ情報を送信する。１０５は、XMPP（eXtensive Message and Presence Protocol）のサーバ機能を有するXMPPサーバである。XMPPサーバ１０５は、カメラ１０１、スマートフォン１０２、カメラ１０３、プリンタ１０４、情報処理装置１０６、情報処理装置１０７からの接続を受け付け、メッセージ交換を行う。本実施形態において、ＸＭＰＰサーバ１０５は、xxx.co.jp（ユーザＡのドメイン）とyyy.co.jp（ユーザＢのドメイン）を管理する。

１０６は、ユーザＡの情報処理装置である。情報処理装置１０６は、ユーザＡとデバイスの関係性、ユーザＡに係るデバイス（カメラ１０１、スマートフォン１０２）のセンサ情報の管理を行う。さらに、情報処理装置１０６は、ユーザＡ、カメラ１０１、スマートフォン１０２に対するメッセージを受信し、メッセージ内容やデバイスのセンサ情報に応じて、宛先を選択し、メッセージを送信する。

１０７は、ユーザＢの情報処理装置である。情報処理装置１０７は、ユーザＢとデバイスの関係性、ユーザＢに係るデバイス（カメラ１０３、プリンタ１０４）のセンサ情報の管理を行う。さらに、情報処理装置１０７は、ユーザＢ、カメラ１０３、プリンタ１０４に対するメッセージを受信し、メッセージ内容やデバイスのセンサ情報に応じて、宛先を選択し、メッセージを送信する。

図２は、本発明の一実施形態に係る情報処理装置１０６のモジュール構成図である。情報処理装置１０７についても同様の構成である。２００は、各モジュールを接続するバスである。２０１は、画像や各種グラフィカルユーザインターフェース（ＧＵＩ）を表示する表示部である。

２０２は、ユーザＡとユーザＡの保持するカメラ１０１とスマートフォン１０２とを関連付けて、それぞれのセンサ情報を管理するデバイス管理部である。デバイス管理部２０２は、カメラ１０１およびスマートフォン１０２のセンサ情報の履歴をデータベースに保存し、管理する。デバイス管理部２０２は、ユーザＡとユーザＡの宛先アドレス（XMPP JID）、カメラ１０１およびスマートフォン１０２の宛先アドレス（XMPP JID）を管理する。これらの宛先情報は、予め設定しておいてもよいし、カメラ１０１及び／又はスマートフォン１０２から入力してもよい。２０３は、カメラ１０１およびスマートフォン１０２のセンサ情報に応じて、送信先のデバイスを選択する選択部である。

２０４は、カメラ１０１およびスマートフォン１０２からセンサ情報を受信するセンサ情報受信部である。本実施形態では、カメラ１０１およびスマートフォン１０２から直接センサ情報を受け取っているが、これに限らず、他のＰＣ（パーソナルコンピュータ）などを介して受信してもよい。センサ情報とは、タッチセンサ、光学センサ、圧力センサ、ジャイロセンサ、角度センサ、ＧＰＳ、画像センサ、音センサ、磁気センサ、ソフトセンサの１つまたは複合により検出された情報である。

センサ情報はこれ以外の物理的なセンサやソフト的なセンサで取得した情報であっても良い。また、カメラ１０１およびスマートフォン１０２のセンサ情報を、カメラ１０１およびスマートフォン１０２の周囲にあるセンサデバイスから受信してもよい。例えば、物体認識センサ、人感センサ、監視カメラなどの画像センサなどである。ここでは、物体や人物に関連するセンサを挙げたがこれに限らず音声センサなど他のセンサであっても良い。

２０５は、ユーザやデバイスからのメッセージを受信するメッセージ受信部である。２０６は、ユーザやデバイスにメッセージを送信するメッセージ送信部である。２０７は、メッセージ受信部２０５で受信したメッセージの内容を判断するメッセージ内容判断部である。メッセージ内容判断部２０７は、メッセージが同報や通知であるか、操作であるかなどの判断を行う。また、メッセージが操作である場合はメッセージのコマンド（例えば、プリント、コピー、画像取得など）によっての判断を行っても良い。本実施形態では、メッセージの内容を同報や通知、操作などによって判断したが、これに限るものではない。

２０８は、センサ情報の更新頻度を調整する更新頻度調整部である。更新頻度調整部２０８は、カメラ１０１およびスマートフォン１０２からのセンサ情報量、カメラ１０１およびスマートフォン１０２の処理負荷、情報処理装置１０６の処理負荷に応じて、更新頻度の計算を行う。例えば、情報処理装置１０６の処理量がx（bps）、デバイス（カメラ１０１乃至スマートフォン１０２）の処理量がy（bps）、帯域幅がb（bps）、センサ情報のデータ量がd（bps）であるとする。この時、更新頻度の最大間隔は、e (sec) = min{b, d} / min{x, y}で示すことができる。なお、本実施形態では上式を用いたがこれに限らず、固定的に掛かる処理時間、ネットワークの遅延やネットワークの揺らぎ、帯域遅延積、データ送受信のウインドウサイズのメモリ量などを用いてもよい。また、これらの情報の少なくとも何れか１つを使用して更新頻度の計算を行ってもよい。

情報処理装置１０７は、情報処理装置１０６と同様の構成である。なお本実施形態では別々の装置として記載しているが、これに限らず、同一の装置内にあってもよい。また、他の情報処理装置と共にサーバやクラウド上に分散的に配置する構成であっても実現できる。

図３は、本発明の一実施形態に係るカメラ１０１のモジュール構成図である。スマートフォン１０２、カメラ１０３についても同様の構成である。プリンタ１０４はこの構成に印刷機能が追加される。本実施形態では、カメラ、スマートフォン、プリンタを例にあげたが、これに限らず、別のデバイス（例えば、タブレット、ビューワ、スキャナ）であっても良い。

３００は、各モジュールを接続するバスである。３０１は、画像や各種グラフィカルユーザインターフェース（ＧＵＩ）を表示する表示部である。３０２は、画像を撮影する撮影部である。

３０３は、カメラ１０１の周囲の変化、ユーザの利用状況、アプリケーションの状態などのセンサ情報を収集するセンサ情報収集部である。カメラ１０１内の情報だけでなく、カメラ１０１周辺にある外部センサを探索し、そこからセンサ情報を取得してもよい。例えば、外部の温度センサ、湿度センサ、監視カメラなどが考えられる。

３０４は、センサ情報収集部３０３で収集したセンサ情報を情報処理装置１０６に送信するセンサ情報送信部である。本実施形態では、センサ情報送信部３０４は、XMPPを利用して、XMPPサーバ１０５を介して、情報処理装置１０６にセンサ情報を送信する。これに限らず、REST（Representational State Transfer）やSOAP（Simple Object Access Protocol）といったウェブサービスを用いて、情報処理装置１０６に送信してもよい。

３０５は、メッセージを受信するメッセージ受信部である。３０６は、ユーザ乃至デバイスを宛先とするメッセージを送信するメッセージ送信部である。３０７は、センサ情報を情報処理装置１０６に送信する更新頻度を変更する更新頻度変更部である。３０８は、センサ情報を情報処理装置１０６に送信するかを判断するセンサ情報判断部である。

図４は、本発明の一実施形態に係る情報処理装置１０６がセンサ情報を受信した際の処理の手順を示すフローチャートである。

Ｓ４０１において、センサ情報受信部２０４は、カメラ１０１およびスマートフォン１０２からセンサ情報を受信し、Ｓ４０２に進む。Ｓ４０２において、デバイス管理部２０２は、受信したセンサ情報をそれぞれのデバイスに関連付けて保存し、Ｓ４０３に進む。Ｓ４０３において、選択部２０３は、デバイス管理部２０２によって管理されているデバイス（ユーザＡのデバイス）のセンサ情報の比較を行い、Ｓ４０４に進む。

Ｓ４０４において、選択部２０３は、比較結果に応じて、優先すべきデバイスを選択する。例えば、照度センサとジャイロセンサが、一定値以上の数値を示している場合、デバイスはポケット（カバン）から出されて利用されていると判断することができる。ここでは、利用されているデバイスを選択する。このＳ４０４での選択結果に応じて、後述の図８（ｂ）の８０６で示す表示を行う。同様に、友人側の８１１についての表示を行う（図８については、後で詳しく述べる）。

なお本実施形態では、照度センサとジャイロセンサについての例を示したが、これに限るものではない。例えば、選択部２０３はセンサ情報から利用頻度や利用日時を取得し、これらの情報からデバイスを選択してもよい。より具体的には、ユーザの利用頻度がより高いデバイス、または、ユーザの利用日時がより近いデバイスを選択する。それ以外にも、タッチセンサによる最後に画面をタッチした時間、音センサで周囲の音の大きさを解析した結果、角度センサによるデバイスの動きなどを用いても、デバイスが利用されていると判断することができる。また、デバイスのＣＰＵパワー、メモリ残量、ネットワーク帯域幅、接続しているネットワークタイプ（ＷｉＦｉ，３Ｇ，ＬＴＥなど）、磁気センサなどを利用しても良いし、アプリケーションの利用ログを利用しても良い。これらの複合によって、デバイス選択の判断の精度を向上させることができる。

図５は、本発明の一実施形態に係る情報処理装置１０６がメッセージを受信した際の処理の手順を示すフローチャートである。

Ｓ５０１において、メッセージ受信部２０５は、情報処理装置１０７からメッセージを受信し、Ｓ５０２に進む。Ｓ５０２において、メッセージ内容判断部２０７は、ユーザＡ宛のメッセージであるか、デバイス（カメラ１０１乃至スマートフォン１０２）宛のメッセージであるかの判断を行う。ユーザＡ宛のメッセージの場合、Ｓ５０３に進む。一方、デバイス宛のメッセージの場合、Ｓ５０８に進む。XMPPを利用して実現する場合、宛先アドレス（ユーザのアドレス、デバイスのアドレス）の形式について説明する。kensuke@xxx.co.jp（Bare JID）が宛先に入っている場合、ユーザＡ宛のメッセージである。また、宛先アドレスがkensuke@xxx.co.jp/camera（Full JID）である場合、カメラ１０１宛のメッセージである。宛先アドレスがkensuke@xxx.co.jp/smartphone（Full JID）である場合、スマートフォン１０２宛のメッセージである。ユーザ名のBare JIDにデバイス名のリソース情報を付与した形で表現される。尚、情報処理装置１０６は、kensuke@xxx.co.jp/virtualで示される。情報処理装置１０６、カメラ１０１、スマートフォン１０２のプライオリティは、情報処理装置１０６のプライオリティが一番高くなるように設定する。これによって、kensuke@xxx.co.jp宛のメッセージを受け取った時、情報処理装置１０６に送られるようになる。本実施形態では、XMPPの形式を利用するため、上記のような設計を行ったが、これに限らず、ユーザ宛のセッションを別に作成してもよい。例えば、kensuke@xxx.co.jp/userのセッションを情報処理装置１０６から生成し、ユーザ宛のメッセージはkensuke@xxx.co.jp/userに送ることとする。これによって、必ずユーザ宛のメッセージが情報処理装置１０６に到達することとなる。これ以外にも、SOAPやRESTなどのAPI（Application Programming Interface）を用いて、ユーザＡの全てのメッセージを情報処理装置１０６経由で交換してもよい。同様にユーザＢのメッセージは情報処理装置１０７が処理する。

各装置とXMPPのアドレスとの対応を示した表を図９に示す。カメラ１０１、スマートフォン１０２、カメラ１０３、プリンタ１０４のプライオリティについては-1が設定され、情報処理装置１０６、情報処理装置１０７のプライオリティについては0が設定される。ユーザＡの装置内で情報処理装置１０６のプライオリティを最も高く設定することによって、ＸＭＰＰサーバ１０５はユーザ宛のメッセージ（例えば、kensuke@xxx.co.jp宛）を情報処理装置１０６に送ることができる。情報処理装置１０７についても同様である。カメラ１０１、スマートフォン１０２、カメラ１０３、プリンタ１０４のプライオリティを-1に設定することで、XMPPサーバ１０５上でメッセージがコピーされなくなる。結果として、各デバイスは他のデバイス宛のメッセージを受け取らなくなる。これにより、不必要なメッセージを受信する必要がなくなり、デバイスの処理負荷を低減させる効果がある。

Ｓ５０３において、メッセージ内容判断部２０７は、メッセージに含まれるコマンドが通知であるか操作であるかの判断を行う。通知とは、イベント、Ｎｏｔｉｆｙ、ＡＣＫ、同報などの非同期的なお知らせである。操作とは、RPC（Remote Procedure Call）などの返答を必要とする同期的な命令である。操作には、例えば、コンテンツのコピーや移動、カメラファインダの遠隔操作などがある。メッセージに含まれるコマンドが通知であると判断された場合、Ｓ５０４に進む。一方、メッセージに含まれるコマンドが操作であると判断された場合、Ｓ５０９に進む。

Ｓ５０４において、選択部２０３は、デバイス管理部２０２から該当するデバイスのセンサ情報を取得し、そのセンサ情報が一定以上であるかの判断を行う。センサ情報が一定以上のデバイスが複数存在すると判断された場合、当該複数のデバイスを選択して、Ｓ５０５に進む。本実施形態では複数のデバイスを選択していたが、これに限らず１つであってもよい。一方、一定以上のセンサ情報のデバイスがないと判断された場合、Ｓ５０６に進む。たとえば、照度センサとジャイロセンサとの両方が一定値以上であったら、ユーザが利用している（ポケットから出して手に持っている）と判断する。例えば、ユーザＡがカメラ１０１を右手にスマートフォン１０２を左手にそれぞれを持って利用していると、両方のデバイスにメッセージが到達することになる。

Ｓ５０５において、メッセージ送信部２０６は、選択部２０３によって選択されたデバイスのためにメッセージを複製した後、選択されたデバイス全てにメッセージを送信し、処理を終了する。なお、本実施形態ではメッセージを複製して送信したが、XMPP以外のプロトコルを利用し、複数の宛先をサポートできるプロトコルであった場合には、複数の宛先に対するメッセージ送信であってもよい。

Ｓ５０６において、メッセージ送信部２０６は、選択部２０３によって選択されたデバイスがないため、デバイスの状態が変わるまでメッセージを保存し、処理を終了する。本実施形態では、メッセージの保存期間などを決めていないが、例えば１時間などメッセージの保存期間を決めても良い。また、メッセージそのものに有効期間が含まれており、その期間中しか保存しない構成でもよい。

Ｓ５０７において、選択部２０３は、センサ情報から最適なデバイスを選択する。例えば、画像の表示であれば、ユーザＡのデバイス（カメラ１０１とスマートフォン１０２）のそれぞれのセンサ情報から、ユーザＡの利用しているデバイス（ここでは、カメラ１０１）を選択する。本実施形態における選択方法は、前述のＳ４０４の処理と同様である。Ｓ４０４の時のセンサ情報との差分がない、または、差分が所定値よりも小さく、計算結果が同じになると予想される場合にはこの選択をスキップしてもよい。スキップする場合は、Ｓ４０４で選択されたデバイスを利用する。これによって、処理の工程を低減することができる。なお本実施形態では、Ｓ４０４と同様の処理を行ったが、これに限らず、操作の内容（プリントなのかコピーなのか）に応じて、詳細なアルゴリズムを変えても良い。以下ではプリントの場合の例を説明する。例えば、ユーザＡがカメラ１０１とプリンタを保持している時、カメラ１０１ではプリントを実行できないため、プリンタを選択する。プリンタにはメッセージを送信し、さらに、カメラ１０１にはプリンタを操作したこと（プリントしたこと）を通知するメッセージを送っても良い。これにより、よりきめ細やかなユーザの意図を選択に反映させることが可能となり、利便性が向上する。

さらに、メッセージの操作内容によって、デバイスのセンサ情報の処理を変更する例を示す。例えば、操作の内容が印刷であれば、ジョブが空いていて、かつ、ユーザが近くにいるデバイスを選択してもよい。メッセージの操作内容によって、デバイスのセンサ情報の処理アルゴリズムを切り替えることができるため、様々なシチュエーションに対応することができ、システムの汎用性やユーザビリティが向上する。

また、連続したメッセージの場合、連続したメッセージ群が別のデバイスに伝達されることを防ぐために、ある処理の塊は同じデバイスを選択してもよい。この場合、メッセージ内に連続した処理であることを示す識別子を付与した上で、メッセージ内容判断部２０７はその識別子と選択したデバイスとの関連付けを保持する。これにより、識別子に応じて選択したデバイスを検索することが可能となって、同じデバイスを選択することが可能となる。この処理はＳ５０７だけでなく、Ｓ５０４の選択にも適用できる。上記処理により、一連の処理において同一のデバイスを選択し送信することが可能となる。

Ｓ５０８において、メッセージ送信部２０６は、指定されたデバイスにメッセージを送信することを決定し、Ｓ５０９に進む。

Ｓ５０９において、選択部２０３は、決定されたデバイスのセンサ情報に基づいて、当該デバイスが現在利用可能であるか否かを判断する。利用可能であると判断された場合、Ｓ５１０に進む。一方、利用不可能であると判断された場合、Ｓ５１１に進む。例えば、無線が混雑している、無線の電波強度が低い、カメラ撮影中など、ユーザが利用中であるが他の状況・状態によって利用できない等の判断を行う。なお本実施形態では、デバイスの選択と利用可能状態の確認を別々に行ったが、これに限らず、同時に実行してもよい。

Ｓ５１０において、メッセージ送信部２０６は、指定されたデバイスにメッセージを送信し、Ｓ５１１に進む。例えば、カメラ１０１に送信すると判断された場合、kensuke@xxx.co.jp/cameraにメッセージを送信する。

Ｓ５１１において、メッセージ送信部２０６は、カメラ１０１に送信したことを、ユーザＡの他のデバイスであるスマートフォン１０２に通知し、処理を終了する。デバイス管理部２０２が保持するユーザＡとデバイスとの関係情報を用いて、kensuke@xxx.co.jp/smartphoneを宛先として通知のメッセージを送信する。また、送信元のユーザＢのデバイス（カメラ１０３、プリンタ１０４）にもカメラ１０１にメッセージを送ったことを通知するメッセージを送信しても良い。情報処理装置１０６がユーザＢのデバイスに直接送っても良いし、情報処理装置１０７を介して送っても良い。また、ユーザＢのデバイスではなく、ユーザＢに対する通知（naoki@yyy.co.jp宛の通知）であってもよい。

Ｓ５１２において、メッセージ送信部２０６は、一時的にメッセージを保存し、処理を終了する。

本実施形態では、Ｓ５０６およびＳ５１２において、メッセージを保存したが、これに限らず、デバイスに通知した後、送信したデバイスが許可した時のみ保存し、許可しなかった時は破棄してもよい。

図６は、本発明の一実施形態に係る情報処理装置１０６が一定時間毎に実行する処理の手順を示すフローチャートである。

Ｓ６０１において、メッセージ送信部２０６は、一定時間待機し、その後Ｓ６０２に進む。Ｓ６０２において、メッセージ送信部２０６は、保存されたメッセージがあるか否かの判断を行う。メッセージ送信部２０６が保存されたメッセージがあると判断した場合、Ｓ６０３に進む。一方、メッセージ送信部２０６が保存されたメッセージがないと判断した場合、処理を終了する。本実施形態では、Ｓ５０６とＳ５１２においてメッセージが保存されることになる。

Ｓ６０３において、メッセージ内容判断部２０７は、ユーザＡ宛のメッセージであるか、デバイス（カメラ１０１乃至スマートフォン１０２）宛のメッセージであるかの判断を行う。ユーザＡ宛のメッセージであると判断された場合、Ｓ６０７に進む。一方、デバイス宛のメッセージであると判断された場合、Ｓ６０４に進む。Ｓ６０３はＳ５０２と同様の処理である。

Ｓ６０４において、選択部２０３は、宛先として指定されたデバイスのセンサ情報に基づいて、当該デバイスが現在利用可能であるか否かを判断する。利用可能であると判断された場合、Ｓ６０５に進む。一方、利用不可能であると判断された場合、処理を終了するＳ６０４はＳ５０９と同様の処理である。

Ｓ６０５において、メッセージ送信部２０６は、指定されたデバイス（たとえば、カメラ１０１）にメッセージを送信し、Ｓ６０６に進む（Ｓ５１０と同様の処理である）。Ｓ６０６において、メッセージ送信部２０６は、カメラ１０１にメッセージを送信したことを、ユーザＡの他のデバイスであるスマートフォン１０２に通知し、Ｓ６０９に進む（Ｓ５１１と同様の処理である）。

Ｓ６０７において、選択部２０３は、デバイス管理部２０２から該当するデバイスのセンサ情報を取得し、そのセンサ情報が一定以上であるか否かの判断を行う。センサ情報が一定以上のデバイスが１以上あると判断された場合、選択部２０３は、そのデバイスを選択し、Ｓ６０８に進む。一方、センサ情報が一定以上のデバイスがないと判断された場合、Ｓ６０９に進む。Ｓ６０７はＳ５０４と同様の処理である。

Ｓ６０８において、メッセージ送信部２０６は、メッセージを複製した後、選択部２０３によって選択されたデバイス全てにメッセージを送信し、Ｓ６０９に進む（Ｓ５０５と同様の処理である）。Ｓ６０９において、メッセージ送信部２０６は、送信が終了したメッセージを消去し、処理を終了する。

このように、メッセージを一時的に保存することで、デバイスの状況や状態によってメッセージが配送できないというリスクを低減することができる。これにより、デバイスを利用している利用者が、ある期間にメッセージが来るかも知れないのでデバイスを使わないようにするといった必要がなくなり、ユーザビリティが向上する。

図７は、本発明の一実施形態に係る情報処理システムのシーケンス図である。

情報処理装置１０６は、カメラ１０１およびスマートフォン１０２から受信したセンサ情報と帯域幅、情報処理装置１０６の処理速度からセンサ情報の更新頻度を決定する。更新頻度の計算方法については後述する。

Ｍ７０１において、情報処理装置１０６は、XMPPサーバ１０５を介して、決定した更新頻度をカメラ１０１に通知する。Ｍ７０２において、情報処理装置１０６は、XMPPサーバ１０５を介して、決定した更新頻度をスマートフォン１０２に通知する。

Ｍ７０３において、カメラ１０１は、XMPPサーバ１０５を介して、指定された更新頻度の間隔でセンサ情報を情報処理装置１０６に通知する。Ｍ７０４において、スマートフォン１０２は、XMPPサーバ１０５を介して、指定された更新頻度の間隔でセンサ情報を情報処理装置１０６に通知する。

この更新頻度は最大更新頻度であって、送信された値より小さい値であれば、デバイス側の都合で決定してよい。また、センサ情報の変更がない場合、センサ情報を通知しなくてもよい。本実施形態では、Ｍ７０３、Ｍ７０４はデバイス側から送信しているが、これに限らず、情報処理装置１０６側から定期的に取得しても良い。また、外部センサ（例えば備え付けの温度センサ）を用いている場合は、当該外部センサから更新頻度に合わせてセンサ情報を通知してもよい。

Ｍ７０５において、情報処理装置１０６は、カメラ１０１およびスマートフォン１０２から受信したセンサ情報を保存する。情報処理装置１０６は、ユーザＡのデバイス（カメラ１０１、スマートフォン１０２）の内から、それぞれのセンサ情報に応じて、優先すべきデバイスを選択する。

Ｍ７０６において、カメラ１０３は、XMPPサーバ１０５を介して情報処理装置１０７にユーザＡを宛先とするメッセージを送信する。Ｍ７０７において、情報処理装置１０７はXMPPサーバ１０５を介して情報処理装置１０６にユーザＡを宛先とするメッセージを送信する。

Ｍ７０８において、情報処理装置１０６は、メッセージ内容の解析を行う。情報処理装置１０６は、ユーザＡを宛先とするメッセージであり、メッセージ内容がファイルのコピー（操作）であると判断する。情報処理装置１０６は、ユーザＡに関連付けられているデバイスのセンサ情報の比較を行い、それらのデバイスからカメラ１０１を選択する。

Ｍ７０９において、情報処理装置１０６は、カメラ１０１が利用可能な状態か否かの確認を行う。カメラ１０１が利用可能でないと判断された場合、情報処理装置１０６は受信したメッセージを保存する。情報処理装置１０６は一定時間毎に利用状態の確認を行う。

Ｍ７１０において、情報処理装置１０６は、カメラ１０１にメッセージを送信する。Ｍ７１１において、情報処理装置１０６は、スマートフォン１０２へ、カメラ１０１にメッセージを送信したことを通知する。Ｍ７１２において、情報処理装置１０６は、XMPPサーバ１０５を介して情報処理装置１０７へ、カメラ１０１にメッセージを送信したことを通知する。この時の通知はユーザＢ宛でも良いし、送信元のデバイスであるカメラ１０３でも良い。本実施形態では、ユーザＢ宛に通知を送信している。Ｍ７１３において、情報処理装置１０７は、XMPPサーバ１０５を介してカメラ１０３へ、メッセージを送信したことを伝える通知を行う。

図８（ａ）及び図８（ｂ）は、本発明の一実施形態に係るカメラ１０３のユーザインタフェースの一例を示す図である。図８（ａ）は、ユーザＢからみた自身が保持するデバイスである。８０１は、自ユーザのデバイスを表示するためのタグである。図８（ａ）の例ではこの８０１のタグが選択されている。８０２は、友達の一覧と友達のデバイスを表示するためのタグである。

８０３は、自ユーザのアイコンである。自ユーザの顔写真やアバターなどを表示する。このアイコンをロングタップすることで自ユーザの持つデバイスのセンサ情報の一覧を別ウインドウで閲覧できる。また、センサ情報から自ユーザの持つデバイスによって実行できるコマンドのリストを表示できる。本実施形態では、センサ情報とコマンドリストとを表示するが、これに限らない。

８０４は、カメラ１０３のアイコンである。このアイコンをロングタップすることで、カメラ１０３のセンサ情報を取得する。また、カメラ１０３宛のメッセージを送信するウインドウが開き、メッセージを作成後、カメラ１０３宛のメッセージを送信できる。この時のXMPPの宛先はnaoki@yyy.co.jp/cameraである。

８０５は、プリンタ１０４のアイコンである。このアイコンをロングタップすることで、プリンタ１０４のセンサ情報を取得する。また、プリンタ１０４宛のメッセージを送信できる。この時のXMPPの宛先はnaoki@yyy.co.jp/printerである。

８１２は、ユーザＢのデバイスの中から選択されたデバイスに付くマークである。本実施形態では、センサ情報の比較によって、カメラ１０３が選択されている。また、ユーザＢがプリンタ１０４の操作を行うと、情報処理装置１０７はプリンタ１０４のセンサ情報の更新からプリンタ１０４が利用されていると判断し、マーク８１２をアイコン８０５に付与する。このように、センサ情報の更新によってマーク８１２が移り変わる。ユーザはこのマーク８１２により情報処理装置１０７がどのデバイスを選択しているかを知ることができ、安心してデバイスを利用することができる。更に、ユーザにとって所望のデバイスが選択されていない場合、ユーザインタフェース（アイコンのダブルクリックなど）や音等を介して、所望のデバイスを情報処理装置１０７に通知できる。情報処理装置１０７は、この通知を累積しておき、今後のデバイスの選択に利用する。より高精度な選択が可能となり、利便性が向上する。

図８（ｂ）は、ユーザＢからみた友達の一覧と友達のデバイスである。ここでは、図８（ａ）との差分について詳しく述べる。図８（ｂ）の例では８０２の友人のタグが選択されている。

８０６は、ユーザＡのアイコンである。ユーザＡの顔写真やアバターなどを表示する。ここでは名前の付加情報（山田）を重畳して表示している。ユーザＡ（山田さん）のアイコンをクリックすると、ユーザＡが選択され、アイコン８０６の淵の幅が広くなる。アイコン８０６をロングタップすることで、ユーザＡの持つデバイスのセンサ情報の一覧を別ウインドウで閲覧できる。更にユーザＡにメッセージを送信することもできる。この時のユーザＡのXMPPの宛先はkensuke@xxx.co.jpとなる。

８０７は、ユーザＣのアイコンである。ユーザＣの顔写真やアバターなどを表示する。８０８は、ユーザＤのアイコンである。ユーザＤの顔写真やアバターなどを表示する。８０９は、ユーザＡのカメラ１０１のアイコンである。アイコン８０９をロングタップすることでカメラ１０１のセンサ情報を閲覧できる。更にカメラ１０１にメッセージを送信することもできる。この時のXMPPの宛先はkensuke@xxx.co.jp/cameraである。

８１０は、ユーザＡのスマートフォン１０２のアイコンである。アイコン８１０をロングタップすることでスマートフォン１０２のセンサ情報を閲覧できる。更にスマートフォン１０２にメッセージを送信することもできる。この時のXMPPの宛先はkensuke@xxx.co.jp/smartphoneである。

８１１は、ユーザＡのデバイスの中から選択されたデバイスに付くマークである。本実施形態では、センサ情報の比較によって、カメラ１０１が選択されている。また、ユーザＡがスマートフォン１０２の操作を行うと、情報処理装置１０６は、スマートフォン１０２のセンサ情報の更新からスマートフォン１０２が利用されていると判断し、マーク８１１をアイコン８１０に付与する。このように、センサ情報の更新によってマーク８１１が移り変わる。ユーザＢはこのマーク８１１により情報処理装置１０６がどのデバイスを選択しているかを予め知ることができる。なお、本実施形態ではマークを示したが、これに限らず、新しいアイコンを出したり、アイコンの種類を変えたり、他の視覚的な表現、音による読み上げなどの表現であっても良い。

このように、ユーザインタフェースへの表示や不図示の音出力部を介して、選択されたデバイスや現在利用可能なデバイスを、各デバイスに対応する名前、色付け、マーク、または音のうち少なくとも１つを使用して通知する。

また本実施形態では、ユーザインタフェースがカメラ１０３上にある例を説明したが、別のデバイス上にあっても良いし、情報処理装置１０６上にあっても良い。

以上説明したように、ユーザ宛のメッセージであった場合、デバイスのセンサ情報からデバイスを選択し、選択されたデバイスにメッセージを送信する。

本実施形態によれば、ユーザが所望するデバイスにメッセージを到達させることを可能とする。これによって、複数のデバイスを保持するユーザは、任意のデバイスを利用しているだけで、ユーザの利用しているデバイスにメッセージが到達し、便利になる。さらに、ユーザは、相手ユーザのデバイスではなく相手ユーザそのものに対してメッセージを送信すれば良く、相手ユーザが持つデバイスのネットワーク環境などの設定にかかる手間が省け、ユーザビリティが向上する。

（第２実施形態）
以下、添付の図面を参照して、第１実施形態との差異を中心に説明する。本実施形態では、情報処理装置１０６および情報処理装置１０７がメッセージを受信した時のメッセージの宛先処理について詳しく説明する。

図１１は、本発明の一実施形態に係る、ユーザＢがカメラ１０３からユーザＡ宛にコンテンツを送信した際のシーケンス図である。図１０（ａ）−（ｆ）は、図１１と関連した図であり、宛先の遷移を示す図である。

Ｍ１１０１において、カメラ１０３は、XMPPサーバ１０５を介して情報処理装置１０７にメッセージを送信する。図１０（ａ）はこの時のパケットの宛先と送信元を示す。To (hop-by-hop)はXMPPの宛先を示しnaoki@yyy.co.jp/virtualであり、From (hop-by-hop)はXMPPの送信元を示しnaoki@yyy.co.jp/cameraである。To (inner-header)はXMPPのペイロード領域に含まれる本実施形態のヘッダに含まれる宛先である。From (inner-header)はXMPPのペイロード領域に含まれる本実施形態のヘッダに含まれる送信元である。To (inner-header)およびFrom (inner-header)はXMPP形式の宛先を含んでいるがこれに限らず、名前であってもよい。その場合、システム上に名前をXMPP形式のアドレスに変換する機能を更に有するように構成すればよい。

Ｍ１１０２において、情報処理装置１０７は、受信したメッセージ内容を確認し、図１０（ａ）から図１０（ｂ）の形式にヘッダの書き換えを行う。To(hop-by-hop)は、ユーザＡの情報処理装置１０６に送信するため、kensuke@xxx.co.jp/virtualに書き換えられる。From(hop-by-hop)は、ユーザＢの情報処理装置１０７から送信されることになるため、情報処理装置１０７のXMPPのJIDであるnaoki@yyy.co.jp/virtualに書き換えられる。次に、To(inner-header)は、ユーザＡ宛であるため、変更はない。From(inner-header)は、本メッセージの送信元であるnaoki@yyy.co.jp/cameraであるため、変更はない。本実施形態では、From(inner-header)をデバイスのままにしたが、これに限らず、naoki@yyy.co.jpに書き換えて、ユーザＢそのものとしてもよい。デバイスから書き換えない場合には送信したデバイスに送り返すことができるという利点があり、ユーザに書き換える場合にはユーザの持つデバイスの中で適したものをメッセージ返信時に情報処理装置が選択できるという利点がある。

Ｍ１１０３において、情報処理装置１０７は、XMPPサーバ１０５を介して情報処理装置１０６に図１０（ｂ）の形式に書き換えたメッセージを送信する。Ｍ１１０４において、情報処理装置１０６は、受信したメッセージ内容を確認し、図１０（ｂ）から図１０（ｃ）の形式にヘッダの書き換えを行う。To(hop-by-hop)は、情報処理装置１０６がユーザＡのデバイスから適したデバイスを選択し送信する（図５の処理）ため、kensuke@xxx.co.jp/cameraに書き換えられる。From(hop-by-hop)は、情報処理装置１０６から送信されることとなるため、情報処理装置１０６のXMPPのJIDであるkensuke@xxx.co.jp/virtualに書き換えられる。次に、To(inner-header)は、ユーザＡ宛であるため、変更はない。From(inner-header)は、本メッセージの送信元であるnaoki@yyy.co.jp/cameraであるため、変更はない。

Ｍ１１０５において、情報処理装置１０６は、XMPPサーバ１０５を介してカメラ１０１に、図１０（ｃ）の形式に書き換えたメッセージを送信する。Ｍ１１０６において、カメラ１０１はメッセージを受信し、メッセージ内容に応じてメッセージに含まれたコンテンツをカメラ１０１に保存する。コンテンツを受信したことを示す返答のメッセージをカメラ１０３に送信する。本実施形態では、from(inner-header)がデバイスを示しているため、返信先のデバイスを指定している。From(inner-header)がユーザである場合は、図１０（ａ）〜（ｃ）と同様（ユーザＡとユーザＢが入れ替わる点は異なる）に処理を行う。カメラ１０１は、図１０（ｃ）の宛先から図１０（ｄ）の宛先の返信用のパケットを生成する。To(hop-by-hop)は、ユーザＡの情報処理装置１０６の宛先であるkensuke@xxx.co.jp/virtualを書き入れる。From(hop-by-hop)は、カメラ１０１のJIDを書き入れる。To(inner-header)は、ユーザＢのカメラ１０３の宛先であるnaoki@yyy.co.jp/cameraを書き入れる。From(inner-header)は、ユーザＡのカメラ１０１の宛先であるkensuke@xxx.co.jp/cameraを書き入れる。

Ｍ１１０７において、カメラ１０１は、XMPPサーバ１０５を介して情報処理装置１０６に図１０（ｄ）の形式のメッセージを送信する。Ｍ１１０８において、情報処理装置１０６は、受信したメッセージ内容を確認し、図１０（ｄ）から図１０（ｅ）の形式にヘッダの書き換えを行う。情報処理装置１０６は、To(inner-header)からユーザＢの宛先を取り出す。To(hop-by-hop)は、取り出された宛先に情報処理装置を示すリソース情報（virtual）を付与した宛先（naoki@yyy.co.jp/virtual）に書き換えられる。From(hop-by-hop)は、情報処理装置１０６から送信されることとなるため、情報処理装置１０６のXMPPのJIDであるkensuke@xxx.co.jp/virtualに書き換えられる。次に、To(inner-header)は、ユーザＢのカメラ１０３宛であるため、変更はない。From(inner-header)は、本メッセージの送信元であるkensuke@xxx.co.jp/cameraであるため、変更はない。本実施形態では、デバイスを送信元としたが、これに限らず、ユーザＡを送信元（kensuke@xxx.co.jp）に書き換えてもよい。

Ｍ１１０９において、情報処理装置１０６は、XMPPサーバ１０５を介して情報処理装置１０７に図１０（ｅ）の形式のメッセージを送信する。Ｍ１１１０において、情報処理装置１０７は、受信したメッセージ内容を確認し、図１０（ｅ）から図１０（ｆ）の形式にヘッダの書き換えを行う。情報処理装置１０７は、To(inner-header)からユーザＢのカメラ１０３のJID（naoki@yyy.cp.jp/camera）が指定されていることを判断する。カメラ１０３のJIDが指定されているため、このJIDを持つデバイスへの送信のモードになる。To(hop-by-hop)は、情報処理装置１０７により、カメラ１０３の宛先（naoki@yyy.cp.jp/camera）に書き換えられる。From(hop-by-hop)は、情報処理装置１０７から送信されることとなるため、情報処理装置１０７のXMPPのJIDであるnaoki@yyy.co.jp/virtualに書き換えられる。次に、To(inner-header)は、ユーザＢのカメラ１０３宛であるため、変更はない。From(inner-header)は、本メッセージの送信元であるkensuke@xxx.co.jp/cameraであるため、変更はない。Ｍ１１１１において、情報処理装置１０７は、XMPPサーバ１０５を介してカメラ１０３に図１０（ｆ）の形式のメッセージを送信する。

尚、デバイスを指定して通信を行う場合は、図１０（ｄ）〜図１０（ｆ）の処理となる。返信を送り返す場合には、図１０（ｄ）〜図１０（ｆ）の宛先と送信元が、ユーザに合致するデバイスと情報処理装置に置き換わるだけであるため、説明を省略する。

次に図１２は、本発明の一実施形態に係る情報処理装置１０６がメッセージを受信した時の処理の手順を示すフローチャートである。ここでは、図５のフローチャートとの差異を中心に説明する。

Ｓ１２０１において、メッセージ受信部２０５は、メッセージ（第１のメッセージ）を受信し、Ｓ１２０２に進む。Ｓ１２０２において、メッセージ内容判断部２０７は、メッセージに含まれる宛先を解析し、Ｓ１２０３に進む。ここでの宛先とは図１０に示すXMPPの宛先（情報処理装置のアドレスを示す第１の送信先To(hop-by-hop)と、情報処理装置への送信を行った第１の送信元From(hop-by-hop)）、および、プロトコルの宛先（最終的な宛先を示す第２の送信先To(inner-header)と、メッセージを最初に送信した第２の送信元From(inner-header)）である。

Ｓ１２０３において、メッセージ内容判断部２０７は、To(inner-header)の宛先が自ユーザ（ユーザＡ宛）であるか他ユーザ（ユーザＡ宛以外の例えばユーザＢ宛）であるかの判断を行う。すなわち、第２の送信先To(inner-header)に基づいて、メッセージが情報処理装置１０６と関連する自ユーザを対象としているか、又は他ユーザを対象としているかを判断する。メッセージ内容判断部２０７は、デバイス管理部２０２が管理しているユーザ及びデバイスの宛先アドレスの情報を利用することで判断することができる。To(inner-header)の宛先が自ユーザを対象としていると判断された場合、Ｓ１２０４に進む（Ｍ１１０４に相当）。一方、To(inner-header)の宛先が他ユーザを対象としていると判断された場合、Ｓ１２０５に進む（Ｍ１１０２に相当）。

Ｓ１２０４において、メッセージ内容判断部２０７は、To(inner-header)の宛先にリソース情報が付与されているかの判断を行う。ここでのリソース情報とはデバイスを示す識別子（smartphoneやcamera等）である。なお、情報処理装置１０６を示す識別子（実施形態中ではvirtual）が付与されていた場合、リソース情報がないとして処理される。To(inner-header)の宛先にリソース情報が付与されていると判断された場合、Ｓ１２０５に進む（Ｍ１１１０に相当）。一方、To(inner-header)の宛先にリソース情報が付与されていないと判断された場合、Ｓ１２０９に進む（Ｍ１１０４に相当）。

Ｓ１２０５において、デバイス管理部２０２は、リソース情報に対応するデバイスがユーザＡに関連付けられているか否かの確認を行う。ユーザＡに関連付けられているリソースがあると判断された場合（ユーザＡは指定されたデバイスを保持している）、Ｓ１２０６に進む。一方、ユーザＡに関連付けられているリソースがないと判断された場合（ユーザＡは指定されたデバイスを保持していない）、Ｓ１２２２に進む。

Ｓ１２０６において、メッセージ内容判断部２０７は、自ユーザのデバイス宛のメッセージと判断し、Ｓ１２０７に進む。Ｓ１２０７において、メッセージ送信部２０６は、To(hop-by-hop)をTo(inner-header)で指定されたリソース（デバイス）に書き換え、Ｓ１２０８に進む。なお本実施形態では、宛先の書き換えで説明したが、これに限らず、新たにメッセージを生成してもよい。また、メッセージ送信部でメッセージの生成および書き換えを行ったが、これに限らず、情報処理装置１０６内にメッセージ生成部を別途用意してもよい。

Ｓ１２０８において、メッセージ送信部２０６は、From(hop-by-hop)を送信元(kensuke@xxx.co.jp/virtual)に書き換え、Ｓ１２１９に進む。Ｓ１２０９において、メッセージ内容判断部２０７は、自ユーザ宛のメッセージであると判断し、Ｓ１２１０に進む。

Ｓ１２１０において、選択部２０３は、センサ情報に応じてユーザＡに関連付けられたデバイスから該当するデバイスを選択する。そしてメッセージ送信部２０６は、To(hop-by-hop)を、選択されたデバイスの宛先に書き換え、Ｓ１２１１に進む。

Ｓ１２１１において、メッセージ送信部２０６は、From(hop-by-hop)を送信元(kensuke@xxx.co.jp/virtual)に書き換え、Ｓ１２１２に進む。

Ｓ１２１２において、メッセージ内容判断部２０７は、メッセージの内容とセンサ情報とに応じてメッセージの複製を行い、Ｓ１２１９に進む。処理の方法は、図５のＳ５０３と同様である。

Ｓ１２１３において、メッセージ内容判断部２０７は、To(inner-header)にリソース情報（smartphone、camera等）が付与されているかの判断を行う（ユーザを指定しているかデバイスを指定しているかの判断を行う）。To(inner-header)にリソース情報が付与されていると判断された場合、Ｓ１２１４に進む（Ｍ１１０８に相当）。一方、To(inner-header)にリソース情報が付与されていないと判断された場合、Ｓ１２１５に進む（Ｍ１１０２に相当）。

Ｓ１２１４において、メッセージ内容判断部２０７は、他ユーザのデバイス宛のメッセージであると判断し、Ｓ１２１７に進む。Ｓ１２１５において、メッセージ内容判断部２０７は他ユーザ宛のメッセージであると判断し、Ｓ１２１６に進む。

Ｓ１２１６において、メッセージ送信部２０６は、To(inner-header)に情報処理装置１０７のリソース情報であるvirtual（第２のリソース情報）を付与し、Ｓ１２１７に進む。なお、本実施形態では情報処理装置１０７のリソース情報は予め決められていたが、これに限らず、リソース名を取得するためにサーバに問い合わせを行っても実現できる。

Ｓ１２１７において、メッセージ送信部２０６は、To(inner-header)のユーザ部分（リソース情報部分を抜いたnaoki@yyy.co.jp）を取り出す。メッセージ送信部２０６は、naoki@yyy.co.jpと情報処理装置１０７のリソース情報であるvirtual（第２のリソース情報）を連結し、naoki@yyy.co.jp/virtualを生成する。その後、メッセージ送信部２０６は、To(hop-by-hop)をnaoki@yyy.co.jp/virtualに書き換え、Ｓ１２１８に進む。

Ｓ１２１８において、メッセージ送信部２０６は、From(hop-by-hop)を送信元(kensuke@xxx.co.jp/virtual)に書き換え、Ｓ１２１９に進む。

Ｓ１２１９において、メッセージ内容判断部２０７は、デバイス管理部２０２で管理されているセンサ情報に基づいて、デバイスが利用可能か否かを判断する（図５のＳ５０９からの処理に相当する）。利用可能であると判断された場合、Ｓ１２２０に進む。一方、利用不可能であると判断された場合、Ｓ１２２１に進む。

Ｓ１２２０において、メッセージ送信部２０６は、XMPPサーバ１０５を介してメッセージを送信し、処理を終了する。Ｓ１２２１において、メッセージ送信部２０６は、メッセージを一時的に保存して、処理を終了する。図１２の処理によって一時的に保存されたメッセージは定期的にチェックされ、送信可能であれば送信される。

Ｓ１２２２において、メッセージ送信部２０６は、エラーである旨をメッセージのFrom(inner-header)の宛先に送信する。また、他ユーザからのメッセージであった場合は、情報処理装置に対してもエラーメッセージを送る。エラーメッセージは他ユーザのデバイスに直接送っても良いし、図１１に示すように情報処理装置を介した通信により、エラーが発生した場所から逆のパスを利用して返信しても良い。

本実施形態では、メッセージの宛先を一つに選んでいたが、これ限らず、第１実施形態で説明したように、メッセージ内容に応じて、メッセージを複製して複数の宛先に送信してもよい。

本実施形態では、XMPPを利用したが、これに限らず、別のメッセージを配送するプロトコルであってもよい。また、別のメッセージを配送するプロトコルとそのペイロードにある別のプロトコルとの複合であっても実現できる。

以上説明したように、本実施形態に係る情報処理装置は、メッセージを受信すると、メッセージ内容に含まれる第２の宛先からユーザ宛かデバイス宛かを判断する。第２の宛先やユーザ情報基づいて、第１の宛先の書き換えを行い、メッセージを送信する。

本実施形態によれば、宛先の書き換えを行うことで、円滑にメッセージ搬送を行うことができる。これにより、ユーザおよびデバイスを一元的に制御することが可能となり、ユーザの場所を意識しなくとも通信ができるようになり、複数のデバイスを利用するシーンでのユーザビリティが向上する。

（第３実施形態）
本実施形態では、公共スペースにあるプリンタ（不図示）やテレビ・モニタの処理についての説明を行う。例えば、ユーザＡがオフィスの公共スペースにあるプリンタ（不図示）の前に立つと、プリンタはユーザＡを人感センサで認識し、近くにある監視カメラ画像からユーザＡであることを認識する。ユーザＡは予め会社のセキュリティシステムに顔が登録されているため、監視カメラによってユーザＡであるという特定を行うことができる。ここでは監視カメラ画像によるユーザ識別を行ったが、これに限るものではない。ユーザ識別方法は、無線タグによる認証などの別方式の方式でも実現できる。ユーザＡは、一時的にオフィスの公共スペースにあるプリンタと関連付けができる。デバイス管理部２０２はセキュリティシステムからプリンタに関する宛先アドレスを取得する。その後、デバイス管理部２０２は、プリンタの宛先アドレス（system@zzz.co.jp/printer）と情報処理装置１０６内の宛先アドレス（kensuke@xxx.co.jp/printer）を関連付け登録する。

情報処理装置１０６は、kensuke@xxx.co.jp/printerのデバイスに対するメッセージをsystem@zzz.co.jp/printerに転送することで、一時的にプリンタを利用できる。また、ユーザＡ宛のメッセージ（印刷）を受け取ると、ユーザＡのプリンタが選択され、印刷が開始される。このように、ユーザＡは簡単に公共スペースにあるデバイスを利用することができる。例えば、ユーザＡがメッセージ（プリント）を受信し、ユーザＡはプリンタを持っていなかった場合、カメラ１０１にメッセージ（プリント）を受信したことを表示する。ユーザＡは、公共スペースにあるプリンタに近づくだけで、プリントを実行できるようになる。

この時、ユーザＡはカメラ１０１を持っていきプリンタに近づけることにより、ユーザＡの承認を行っても良い。ユーザＡがプリンタから遠ざかると、監視カメラの撮影範囲からユーザＡが消えることを検知し、ユーザＡとプリンタとの紐付けを解除する。紐付けは、１度行われたら、半永久的に継続しても良いし、本実施形態のように、何かのトリガーによって解除しても良い。また、解除した後も、ログとして残っていて図８のデバイスとして表示しても良い。この時、デバイスは他の常に関連付けられているデバイスとは違った表示（例えば、グレーアウト）を行うことで、ユーザに分かりやすく構成できる。

また、テレビ、モニタ、プロジェクタにおいても同様の処理を行うことができる。この場合は、ユーザＡが近づくと、それを認識し、メッセージ（画像）を表示することができる。

本実施形態では、プリンタの宛先アドレスと情報処理装置内の宛先アドレスとの変換を行ったが、これに限らず、プリンタがkensuke@xxx.co.jp/printerのセッションを生成してもよい。これにより、情報処理装置１０６内の宛先アドレスの変換処理を低減することができる。

なお、ここでは物理的に近付くことでユーザＡと各種デバイスの紐付けを行うことを示したが、これに限らず、ユーザＡのデバイス操作による紐付け処理でも良い。

これによって、公共スペース（オフィスの共用スペース、公共機関の待合所、病院、コンビニなど）にあるデバイスを様々な人が簡単に利用できるようになり、利便性が向上する。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

デバイスの状態を検出するセンサから、前記センサが検出した前記デバイスの状態を示す情報を受信するデバイス状態受信手段と、
前記デバイス状態受信手段により受信された情報が示すデバイスの状態を管理する管理手段と、
メッセージを受信するメッセージ受信手段と、
前記メッセージ受信手段が受信したメッセージを送信する送信先のデバイスを、前記メッセージ受信手段が受信したメッセージの宛先に対応する複数のデバイスから、前記管理手段が管理している複数のデバイスの状態に基づいて選択する選択手段と、
前記選択手段により選択されたデバイスへ、前記メッセージ受信手段が受信したメッセージを送信する送信手段と、
前記メッセージ受信手段により受信されたメッセージを前記選択手段により選択されたデバイスへ前記送信手段が送信したことを、前記メッセージ受信手段により受信されたメッセージの宛先に対応する複数のデバイスのうち、前記選択手段により選択されたデバイス以外のデバイスに通知する通知手段と、
を備えることを特徴とする情報処理装置。
前記情報処理装置の処理負荷、デバイスの処理負荷、またはセンサ情報のデータ量の少なくとも何れか１つに基づいて、前記デバイス状態受信手段が前記デバイスの状態を示す情報を受信する間隔を調整する調整手段をさらに備えることを特徴とする請求項１に記載の情報処理装置。
前記デバイス状態受信手段は、ネットワークを介して前記デバイスの状態を示す情報を受信することを特徴とする請求項１又は２の何れか１項に記載の情報処理装置。
前記デバイス状態受信手段は、前記デバイスが有するセンサ又は前記デバイスの外部にあるセンサから、前記デバイスの状態を示す情報を受信することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
前記センサは、タッチセンサ、光学センサ、圧力センサ、ジャイロセンサ、角度センサ、ＧＰＳ、画像センサ、音センサ、磁気センサ、物体認識センサ、照度センサ、または人感センサの少なくとも一つを含むことを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
前記センサは、デバイスのＣＰＵの状態、デバイスのメモリの状態、デバイスが接続しているネットワークの状態、及びデバイスによるアプリケーションの利用状態の少なくとも何れかを検出することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
デバイスの状態を検出するセンサから、前記センサが検出した前記デバイスの状態を示す情報を受信するデバイス状態受信手段と、
前記デバイス状態受信手段により受信された情報が示すデバイスの状態を管理する管理手段と、
メッセージを受信するメッセージ受信手段と、
前記メッセージ受信手段が受信したメッセージを送信する送信先のデバイスを、前記メッセージ受信手段が受信したメッセージの宛先に対応する複数のデバイスから、前記管理手段が管理している複数のデバイスの状態に基づいて選択する選択手段と、
前記選択手段により選択されたデバイスへ、前記メッセージ受信手段が受信したメッセージを送信する送信手段とを備え、
前記センサは、タッチセンサ、光学センサ、圧力センサ、ジャイロセンサ、角度センサ、ＧＰＳ、画像センサ、音センサ、磁気センサ、物体認識センサ、照度センサ、または人感センサの少なくとも一つを含むことを特徴とする情報処理装置。
デバイスの状態を検出するセンサから、前記センサが検出した前記デバイスの状態を示す情報を受信するデバイス状態受信工程と、
前記デバイス状態受信工程において受信された情報が示すデバイスの状態を管理する管理工程と、
メッセージを受信するメッセージ受信工程と、
前記メッセージ受信工程において受信されたメッセージを送信する送信先のデバイスを、前記メッセージ受信工程において受信されたメッセージの宛先に対応する複数のデバイスから、前記管理工程において管理されている複数のデバイスの状態に基づいて選択する選択工程と、
前記選択工程において選択されたデバイスへ、前記メッセージ受信工程において受信されたメッセージを送信する送信工程と、
前記メッセージ受信工程において受信されたメッセージが前記選択工程において選択されたデバイスへ前記送信工程において送信されたことを、前記メッセージ受信工程において受信されたメッセージの宛先に対応する複数のデバイスのうち、前記選択工程において選択されたデバイス以外のデバイスに通知する通知工程と、
を有することを特徴とする情報処理方法。
デバイスの状態を検出するセンサから、前記センサが検出した前記デバイスの状態を示す情報を受信するデバイス状態受信工程と、
前記デバイス状態受信工程において受信された情報が示すデバイスの状態を管理する管理工程と、
メッセージを受信するメッセージ受信工程と、
前記メッセージ受信工程において受信されたメッセージを送信する送信先のデバイスを、前記メッセージ受信工程において受信されたメッセージの宛先に対応する複数のデバイスから、前記管理工程において管理されている複数のデバイスの状態に基づいて選択する選択工程と、
前記選択工程において選択されたデバイスへ、前記メッセージ受信工程において受信されたメッセージを送信する送信工程とを有し、
前記センサは、タッチセンサ、光学センサ、圧力センサ、ジャイロセンサ、角度センサ、ＧＰＳ、画像センサ、音センサ、磁気センサ、物体認識センサ、照度センサ、または人感センサの少なくとも一つを含むことを特徴とする情報処理方法。
請求項１乃至７の何れか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。