(57)【要約】【課題】装置間にてデータ共有する際に、ユーザによるデータの送信側・受信側の入力設定を不要としてユーザ操作を減らすことのできる送受信判定装置を提供する。【解決手段】センサ情報取得部2は、当該装置に加わる動きに関連するセンサ情報を時系列として取得する。イベント検知部4は、別装置と当該装置とが近接したイベントを検知する。送受信判定部3は、イベントが検知された時点までに取得されているセンサ情報に基づいて、当該装置が送信側又は受信側のいずれの役割であるかを判定する。データ通信部5は、判定された役割に従って、別装置との間でデータ通信を行う。【選択図】図１
2016009244.tif 000002
【特許請求の範囲】
【請求項１】
別装置との間でデータ通信を行いデータ共有する際の役割がデータの送信側又は受信側のいずれであるかを判定する送受信判定装置であって、
前記送受信判定装置に加わる動きに関連するセンサ情報を時系列として取得するセンサ情報取得部と、
別装置と前記送受信判定装置とが近接したイベントを検知するイベント検知部と、
前記イベントが検知された時点までに取得されている前記センサ情報に基づいて、前記役割が送信側又は受信側のいずれであるかを判定する送受信判定部と、
前記送信側又は受信側のいずれかに判定された役割に従って、別装置との間でデータ通信を行うデータ通信部と、を備えることを特徴とする送受信判定装置。
【請求項２】
前記送受信判定部は、前記イベントが検知された時点までに取得されている前記センサ情報と、所定のレファレンス動作が前記送受信判定装置に加わった際のセンサ情報である参照情報と、を比較して一致していると判断できるか否かにより、前記役割が送信側又は受信側のいずれであるかを判定することを特徴とする請求項１に記載の送受信判定装置。
【請求項３】
前記送受信判定部は、前記センサ情報と前記参照情報との差分に対する閾値判断により、前記役割が送信側又は受信側のいずれであるかを判定することを特徴とする請求項２に記載の送受信判定装置。
【請求項４】
前記送受信判定部は、前記センサ情報と前記参照情報との差分を求めるに際して、時系列上の非線形伸縮により予め対応付けたうえで、当該差分を求めることを特徴とする請求項３に記載の送受信判定装置。
【請求項５】
前記送受信判定部は、前記イベントが検知された時点までに取得されている前記センサ情報に基づいて、前記送受信判定装置の変動量を推定し、当該変動量に対する閾値判断により、前記役割が送信側又は受信側のいずれであるかを判定することを特徴とする請求項１に記載の送受信判定装置。
【請求項６】
前記送受信判定部において前記役割が送信側又は受信側のいずれであるか判定された判定履歴を保存する判定履歴データベースをさらに備え、
前記送受信判定は、前記前記イベントが検知された時点までに取得されている前記センサ情報より所定算出される量に対する閾値判断により、前記役割が送信側又は受信側のいずれであるかを判定し、当該閾値判断において前記判定履歴が、直近の判定結果がより再現されやすくなるように考慮されていることを特徴とする請求項１ないし５のいずれかに記載の送受信判定装置。
【請求項７】
前記送受信判定部は、近距離にありデータ共有の対象となる別装置の台数を取得し、当該台数と、前記イベントが検知された時点までに取得されている前記センサ情報と、に基づいて前記役割が送信側又は受信側のいずれであるかを判定することを特徴とする請求項１ないし６のいずれかに記載の送受信判定装置。
【請求項８】
前記送受信判定部は、前記台数を取得するに際して、Bluetooth（登録商標）を利用することを特徴とする請求項７に記載の送受信判定装置。
【請求項９】
前記イベント検知部は、NFCによるペアリングを開始しようとするイベントを検知することで、前記近接したイベントを検知することを特徴とする請求項１ないし８のいずれかに記載の送受信判定装置。
【請求項１０】
前記センサ情報は、加速度センサ及び／又はジャイロセンサにより取得された情報を含むことを特徴とする請求項１ないし９のいずれかに記載の送受信判定装置。
【請求項１１】
前記送受信判定装置は、前記役割が送信側又は受信側のいずれかに予め設定されており、
前記データ通信部は、前記送受信判定部により判定された役割が、前記いずれかに予め設定されている役割に一致する場合に、当該予め設定されている役割に従って、別装置との間でデータ通信を行うことを特徴とする請求項１ないし１０のいずれかに記載の送受信判定装置。
【請求項１２】
コンピュータを請求項１ないし１１のいずれかに記載の送受信判定装置として機能させることを特徴とするプログラム。
【請求項１３】
別装置との間でデータ通信を行いデータ共有する際の役割がデータの送信側又は受信側のいずれであるかを判定する送受信判定装置によって実行される方法であって、
前記送受信判定装置に加わる動きに関連するセンサ情報を時系列として取得するセンサ情報取得段階と、
別装置と前記送受信判定装置とが近接したイベントを検知するイベント検知段階と、
前記イベントが検知された時点までに取得されている前記センサ情報に基づいて、前記役割が送信側又は受信側のいずれであるかを判定する送受信判定段階と、
前記送信側又は受信側のいずれかに判定された役割に従って、別装置との間でデータ通信を行うデータ通信段階と、を備えることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、近くにあるデバイス間で情報を共有する際に、デバイスのセンサ情報を利用してデバイスが送信側か受信側かを自動で判定することにより、ユーザ操作を減らすことができる送受信判定装置、方法及びプログラムに関する。
【背景技術】
【０００２】
近くにいる人同士でスマートフォンのようなデバイスに格納されている連絡先や写真などを交換する際に、近距離の間での無線通信が利用されることがある。例えば、非特許文献1の一部のAndroid（登録商標）OSがサポートするAndroid Beamでは、ある端末で閲覧中のWebページ、画像、連絡先情報を、近距離無線通信の一種であるNFC (Near Field Communication)やBluetooth（登録商標）を利用して、別の端末に送ることができる。
【０００３】
また、非特許文献2のBump Technologies社のBumpというアプリケーションでは、物理的に近くにいるデバイス同士で、同時に振るといった特殊な操作を行った場合に、デバイスを特定し、画像や連絡先情報などを簡単に交換できるとされている。
【０００４】
また、特許文献1では、主にWi-Fi Direct（登録商標）の拡張を想定して、通信をしようとする複数の端末間でグループオーナー（アクセスポイントなど）の役割を果たす端末を決定する方法が示されている。通常のWi-Fi Directでは、端末に事前に設定されたグループオーナーになることをどれだけ希望するかの度合いを表す値に基づき、その大小で決定され、同一の値であった場合には、乱数により決定するといった仕組みが提供されている。このグループオーナー決定プロセスにおいて、端末の性能パラメータを考慮して決定することを提案しているのが特許文献1である。
【０００５】
また、特許文献2では、NFCを利用した通信をする際に、端末の内部に複数存在するNFC対応アプリケーションのうち、どのアプリケーションを優先的に利用するかを決定する仕組みを提供している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2012-186643号公報
【特許文献２】特開2013-041349号公報
【非特許文献】
【０００７】
【非特許文献１】次のＵＲＬで示されているインターネット・サイトhttp://www.android.com/about/
【非特許文献２】次のＵＲＬで示されているインターネット・サイトhttp://bu.mp/company/
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、以上のような従来技術においては、デバイス同士の間でデータ共有のためにデータの送信側と受信側とを決定するのに、ユーザが明示的に送信側又は受信側のいずれであるかを入力して各デバイスに設定することを要求され、ユーザ操作の手間がかかってしまうという課題があった。特に、頻繁にそのようなデータ共有が行われる場合を考えると、共有作業の都度ユーザの操作（手間）が必要となり、当該課題は顕著となる。
【０００９】
すなわち、非特許文献1では、端末同士を近づけた状態では、どちらのデバイスが送信側か受信側かは決定されておらず、ユーザが明示的にいずれの側であるかを設定する操作に紐付いて、送信側と受信側が決定される。すなわち、送信側・受信側の決定にユーザ操作が必要となる。
【００１０】
また、非特許文献2では、Bumpアプリケーションの状態に紐付いて、送信側と受信側を決定する。例えば、アプリケーションにおいて画像を閲覧している状態であれば送信側とて決定し、閲覧していない状態にあれば受信側として決定する。この場合、両方のデバイスが画像を閲覧している状態であったとすると、送信側と受信側の役割が決定できず、ユーザの操作による役割の決定が必要となってしまう。また、アプリケーションの状態から送信側・受信側の役割が決定できた場合であっても、そもそもアプリケーションの状態を設定するのに、ユーザ操作が必要となってしまう。
【００１１】
また、特許文献1では、デバイスの性能に紐付き、どちらがグループオーナーになるかを決定するが、画像を送るといったケースでは、どのデバイスがグループオーナーかを決めただけでは、送信側と受信側の判定することはそもそも不可能である。
【００１２】
さらに、特許文献2には、NFCを利用する際に、ユーザの過去の選択結果に応じて、アプリケーションの優先度を変更し、その優先度に応じてデバイス内部での利用アプリケーション決定するプロセスについて記載されている。ここで、利用アプリケーションを決定できたとしても、デバイス間での送信側と受信側の役割を決定することはできない。
【００１３】
本発明は、以上のような従来技術の課題に鑑み、デバイス間で情報を共有する際に決定する必要のある事項として、どちらのデバイスが情報を提供する送信側で、どちらのデバイスが情報を受け取る受信側であるかの決定におけるユーザの手間を低減することができ、これによってデバイス間でのスムーズな情報共有を実現する、送受信判定装置、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記目的を達成するため、本発明は、別装置との間でデータ通信を行いデータ共有する際の役割がデータの送信側又は受信側のいずれであるかを判定する送受信判定装置であって、前記送受信判定装置に加わる動きに関連するセンサ情報を時系列として取得するセンサ情報取得部と、別装置と前記送受信判定装置とが近接したイベントを検知するイベント検知部と、前記イベントが検知された時点までに取得されている前記センサ情報に基づいて、前記役割が送信側又は受信側のいずれであるかを判定する送受信判定部と、前記送信側又は受信側のいずれかに判定された役割に従って、別装置との間でデータ通信を行うデータ通信部と、を備えることを特徴とする。
【００１５】
また、本発明は、別装置との間でデータ通信を行いデータ共有する際の役割がデータの送信側又は受信側のいずれであるかを判定する送受信判定装置によって実行される方法であって、前記送受信判定装置に加わる動きに関連するセンサ情報を時系列として取得するセンサ情報取得段階と、別装置と前記送受信判定装置とが近接したイベントを検知するイベント検知段階と、前記イベントが検知された時点までに取得されている前記センサ情報に基づいて、前記役割が送信側又は受信側のいずれであるかを判定する送受信判定段階と、前記送信側又は受信側のいずれかに判定された役割に従って、別装置との間でデータ通信を行うデータ通信段階と、を備えることを特徴とする。
【００１６】
さらに、本発明は、プログラムであって、コンピュータを上記送受信判定装置として機能させることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、別装置と接近したイベントを検知された時点までに取得されたセンサ情報によって自動的に送信側又は受信側の役割が判定され、当該役割に従って自動でデータ通信が行われる。従って、ユーザの立場では、送受信判定装置に動きを加えるだけで、当該動きに対応するセンサ情報から自動的に送受信の役割が判定されることとなり、送受信の役割を手間のかかる明示的な入力方法によって設定する必要がなくなる。
【図面の簡単な説明】
【００１８】
【図１】一実施形態に係る送受信判定装置の機能ブロック図である。
【図２】センサ情報取得部の取得するセンサ情報の概念的な例を表形式で示す図である。
【図３】検知されるイベントの概念的な例を示す図である。
【図４】一実施形態に係る送受信判定装置の動作のフローチャートである。
【図５】センサ情報取得サイクルの実装の両場合を示す図である。
【図６】相手側の送受信判定装置が１台存在する場合の、システム全体としての動作の具体的な一例を模式的に示す図である。
【図７】予め取得され保存される参照情報の模式的な例を示す図である。
【図８】参照情報とセンサ情報とが似ており一致していると判定できるか否かの判断の模式的な例を示す図である。
【図９】伸縮利用の利点を模式的に示す図である。
【図１０】判定履歴DBにて保存される判定履歴の例を示す図である。
【図１１】両デバイスの送受信判定結果と対応する処理とを示す図である。
【図１２】本発明の送受信判定による効果の一例を示す図である。
【発明を実施するための形態】
【００１９】
図１は、本発明の一実施形態に係る送受信判定装置の機能ブロック図である。送受信判定装置10は、センサ部1、センサ情報取得部2、送受信判定部3、イベント検知部4、データ通信部5、参照情報登録部6、参照情報DB(データベース)7及び判定履歴DB(データベース)8を備える。送受信判定装置10は例えば、スマートフォン等の情報端末装置として実現することができる。各部の概要は以下の通りである。
【００２０】
センサ部1は、加速度センサ及び／又は角速度を取得するジャイロセンサその他といったような、動きに関連する物理量等を取得するセンサを含み、送受信判定装置10の動きに関連する情報を時系列上のセンサ情報として計測して、センサ情報取得部2又は参照情報登録部6に渡す。
【００２１】
なお、センサ部1は、送受信判定装置10の動きに関連する情報を取得できれば任意の種類のものを含んでよい。例えば、カメラで撮影した映像を解析して周知の動きベクトル等を算出する構成を含んでいてもよいが、この場合は送受信判定装置10自身の動きが適切に映像に反映されるように撮影が行われる必要がある。（自身が静止しているのに撮影されている景色は移動しているような撮影は好ましくない。）
【００２２】
センサ情報取得部2は、センサ部1の計測したセンサ情報の時系列を取得して、送受信判定部3に渡す。当該取得の際に、例えば加速度センサであれば、x,y,zの3軸の情報をすべて取得してもよいし、特定の軸の情報だけ取得してもよい。その他、ジャイロセンサで取得される角速度やスマートフォンのようなデバイスで取得されるようなセンサ情報を一部又は全部利用してもよい。
【００２３】
図２に、センサ情報取得部2の取得するセンサ情報の概念的な例を表形式で示す。表に示すように、縦方向に示す各時刻t=0, 1, 2, …, Tにおける横方向に示すN個のセンサ出力p1, p2, …, pNの値p1t, p2t, …, pNtを与えたものがセンサ情報となる。
【００２４】
送受信判定部3は、イベント検知部4からイベント検知の旨を受けた時刻以前の所定時間内にセンサ情報取得部2から得られたセンサ情報を解析して、当該所定時間内における送受信判定装置10の動きがどのようなものであったかを判定することに基づき、送受信判定装置10が別装置との間でデータ送受信を行う際にデータの送信側となるか受信側となるかを判定し、判定結果をデータ通信部5に渡す。
【００２５】
イベント検知部4は、送受信判定装置10のデバイス同士が接近したことをイベントとして検知し、検知した時点にて送受信判定部3に伝える。図３に、当該検知されるイベントの概念的な例を示すように、ある送受信判定装置10Aと別の送受信判定装置10Bとが物理的に十分に接近したときにイベントが検知される。当該各デバイス10A,10Bは、区別するためにA,Bを付してあるが、その構成は共に図１に示す送受信判定装置10と共通である。
【００２６】
なお、「送受信判定装置10」同士を区別して称する場合にはそれぞれを上記のように「デバイス10A,10B」等と呼ぶこととし、後述の図６においても当該デバイス10A,10Bの区別を同様に利用する。
【００２７】
イベント検知部4による当該イベント検知には、NFCにおけるタッチイベント（ペアリングを開始しようとするイベント）の検知などを利用できる。
【００２８】
データ通信部5は、送受信判定部3により判定された役割に従って、イベント検知部4によりイベント検知された別デバイス（に備わるデータ通信部5）との間でデータ通信を行う。送信側と判定されればデータを別デバイスへ向けて送信し、受信側と判定されればデータを別デバイスより受信する。
【００２９】
データ通信部5における当該データ送受には、イベント検知部4で利用したNFCで直接データを送受信してもよいし、NFCからBluetooth（登録商標）もしくはNFCからWi-Fi（登録商標）に通信方法を切り替えて、データを送受信してもよい。
【００３０】
参照情報登録部6及び参照情報DB7と、判定履歴DB8とは、それぞれ、実施形態によっては省略可能である。省略しない場合、次のように機能する。
【００３１】
参照情報登録部6は、後述するようなレファレンス動作をユーザが登録しようとする際に、当該レファレンス動作のセンサ情報の時系列を取得して、参照情報DB7に保存する。参照情報DB7に当該保存されたレファレンス動作のセンサ情報は、送受信判定部3が送受信の役割の判定を行う際に参照される。
【００３２】
なお、当該レファレンス動作のセンサ情報は、当該レファレンス動作が送受信判定装置10に加わったとした場合にセンサ部1が計測してセンサ取得部2が取得するのと同様のものである。参照情報登録部6では、当該同様のセンサ情報を、参照情報DB7への登録のために取得する。
【００３３】
判定履歴DB8は、送受信判定部3における送受信の役割の判定結果を履歴として保存し、最新の時点における送受信判定部3の送受信の役割判定のために、当該履歴を提供する。
【００３４】
図４は、一実施形態に係る送受信判定装置10の動作のフローチャートである。
【００３５】
ステップS1では、センサ部1を起動し、センサ情報取得部2がセンサ情報を時系列として取得することを開始してから、ステップS2へと進む。
【００３６】
ステップS2では、ユーザが送受信判定装置10に対して動作を加え、ステップS3へ進む。ステップS3では、イベント検知部4がデバイス同士の近接するイベント検知があったか否かが判断され、検知された場合にはステップS4へ進み、検知されていない場合にはステップS2へ戻る。
【００３７】
こうして、ステップS3でデバイス同士の近接するイベントが検知される時点まで、ユーザはステップS2において継続的に送受信判定装置10に動作を加えることとなる。なお、当該ステップS2は、ユーザがそのような所望の動作を行いうることを明確化するために図４において１つのステップとして示してある。従って、ユーザが送受信判定装置10を例えば机の上に置いたままにしており、自身で特段の動作を加えていない場合なども、ステップS2におけるユーザが加える動作に含まれる。
【００３８】
ステップS4では、ステップS3でイベント検知された時点までにセンサ情報取得部2により取得されたセンサ情報に基づき、当該送受信判定装置10自身が送信側又は受信側のいずれの役割に該当するかを送受信判定部3が判定し、ステップS5へ進む。
【００３９】
ここで、当該取得されたセンサ情報は、当該時点までに送受信判定装置10に加えられていた動作がどのようなものであったかを反映しているので、当該加えられていた動作に従って、送信側又は受信側の役割が判定されることとなる。当該役割判定の各実施形態については後述する。
【００４０】
また、センサ情報の取得のサイクルの実装に関しては、OS（オペレーティングシステム）側で取得する場合と、アプリ（アプリケーション）側で取得する場合が可能である。図５に、当該両場合を示す。
【００４１】
図５左側の[1]に「パタンA」として示すように、OS側で取得する場合は、OSが立ち上がったタイミング（ステップS11,S12）から電源が切れる（ステップS16,S17）まで、ユーザの動作に対応するセンサ情報を取得し続ける。一方で、図５右側の[2]に「パタンB」として示すように、アプリ側で取得する場合は、アプリが立ち上がったタイミング（ステップS22,S23）からアプリが終了する（ステップS25,S26）まで、ユーザの動作に対応するセンサ情報を取得し続ける。
【００４２】
なお、これら2つのパタンA,Bの違いは、図４のステップS4における判定を行う際に必要となる実際のセンサ情報の利用可能な長さに関係する。図５に示すように、パタンAではステップS12〜S14の間のセンサ情報が利用可能であり、パタンBではステップS23〜S24の間のセンサ情報が利用可能となる。
【００４３】
図４に戻り、ステップS5では、ステップS4において判定された役割に従って、データ通信部5がデータの送信又は受信を行い、図４のフローは終了する。
【００４４】
なお、送信するデータは、送信側となるデバイスにおいてユーザが予め設定しておく。例えば、写真閲覧アプリを起動して、ある写真を表示させている場合は、当該表示されている写真が送信対象をデータとする等の所定の設定を設けておき、ユーザは当該設定に従って予め送信データを設定しておく。受信側となるデバイスにおいては当該設定は省略されていてもよい。
【００４５】
以上、図４のフローにより、ある１台の送受信判定装置10についての動作を説明した。システム全体の動作としては、ステップS3における近接イベント検知対象であり、且つステップS5におけるデータ送受の相手側となる送受信判定装置10も１台以上存在することで、合計２台以上の送受信判定装置10が同様に動作している。
【００４６】
図６は、相手側の送受信判定装置10が１台存在する場合の、システム全体としての動作の具体的な一例を模式的に示す図である。(1)に示すように、ユーザAが送受信判定装置10Aを持ち、ユーザBが送受信判定装置10Bを持ち、当該両デバイス10A,10Bがある程度の距離をもって離れている状態にて、両デバイス10A,10Bが共に図４のステップS1を実行し、ステップS2,S3のループに入る。
【００４７】
図６の(2)に示すように、共にステップS2,S3のループに入った両デバイス10A,10Bに対して、ユーザA,Bがそれぞれ動作を加える。ここでは、ユーザAが動作MAとして示すような、デバイス10Aをデバイス10Bへ向けて直線的に近づける動作を行い、ユーザBはデバイス10Bを保持したまま動かさず、デバイス10Aの近接を待機している。この結果、(2)に示すように、両デバイス10A,10Bが十分に近接することで近接イベントE_ABが発生し、両デバイス10A,10Bは共に図４のステップS3におけるイベント検知で肯定判断を得て、ステップS4へ進む。
【００４８】
ここで、両デバイス10A,10Bが図４のステップS4にて、近接イベントE_ABが検知された時点までの動きがデバイス10Aは大きく、デバイス10Bは小さい（ほぼ静止している）ことにより、デバイス10Aがデータ送信側と判定し、デバイス10Bがデータ受信側と判定する。なお、当該判定は一例である。
【００４９】
当該判定の後にステップS5へ進み、当該判定に従ったデータ送受がなされている状態が、図６の(3)に示されている。すなわち、送信側と判定したデバイス10Aに備わるデータ通信部5Aより、受信側と判定したデバイス10Bに備わるデータ通信部5Bへ向けてデータが送信されている。
【００５０】
以上、図６の模式例や図４のフローにおいて特に、ユーザの立場では送受信を行う各デバイスにつき、何らかの動作（静止状態で保持することを含む）をステップS2,S3のループにおいて加え続けることで、最終的にステップS3で近接イベント（例えばデバイス同士が「タッチ」されること）が検知されるようにするだけでよい。この結果、ステップS4で各デバイスの送信側又は受信側の役割が判定され、直ちにステップS5において当該役割に従ってデータの送受信が行われ、デバイス間でのデータ共有が完了する。
【００５１】
すなわち、本発明では特に、ユーザが行う主要な作業としては、物理的な動作をデバイスに加えるだけで済み、この結果、デバイスが自動で送信・受信の役割を判定し、当該役割に従ってデータ共有が完了する。従って、ユーザは送信・受信の役割をメニュー表示から選択する等の明示的な入力作業の手間から解放されることとなる。
【００５２】
以下、送受信判定部3によるステップS4における送信側・受信側の判定の各実施形態を説明する。なお、ステップS3で相手側デバイスと近接したイベントが検知された時点に至るまでの所定時間範囲内で取得されたセンサ情報より送信側・受信側を判定するという枠組みは、各実施形態において共通である。
【００５３】
一実施形態では、参照情報登録部6及び参照情報DB7を利用して、送受信判定部3が参照情報を利用し、当該参照情報とセンサ情報とが一致していると判定できるか否かに基づき、送信側・受信側の判定を行う。
【００５４】
参照情報は、送受信判定装置10に所定の動作を加えた際にセンサ部１で計測されるセンサ情報をセンサ情報取得部2で取得するのと同様のものを、参照情報登録部6において予め取得し、参照情報DB7に保存しておく。当該参照情報を予め取得し保存しておくことは、図４のフローを実行する前に準備として実施しておく。
【００５５】
なお、参照情報はユーザが実際に送受信判定装置10に所望の動作を加えることによって登録してもよいし、ネットワーク上のサーバ等に予め各所定動作ごとの参照情報を（メーカー側等が準備して）保存しておき、ユーザが当該サーバ等から選択して取得するようにしてもよい。
【００５６】
そして、参照情報登録部6では、図４のフローのもとで、当該予め保存された参照情報と、イベント検知時点までの所定時間範囲でセンサ情報取得部2に取得されたセンサ情報とを比較し、一致していると判断できるか否かに基づいて、送信側・受信側の判定を行う。一致していると判断される場合に送信側と判定し、一致していないと判断される場合に受信側と判定してもよいし、その逆の判定を用いてもよい。こうして、参照情報として予め登録しておくものに対応する所定のレファレンス動作と同様とみなせる動作が送受信判定装置10に加えられたか否かにより、送信側・受信側の判定を行うことができる。
【００５７】
図７は、予め取得され保存される参照情報の模式的な例を示す図である。[1]に示すように、送受信判定装置10に加わる判定対象の所定の動作MAは、所定のxyz座標のもとでx軸方向に所定距離（例えば30cm）だけ動かして止めることを所定時間（例えば4秒間）で終えるという動作である。この場合、[2]に示すように、x軸方向の加速度が動かし始めの時間帯で正のピークとなり止まる前の時間帯で負のピークとなるという加速度センサ情報が参照情報として得られ、当該参照情報は[3]に示すように、参照情報DB7に保存される。
【００５８】
当該参照情報を利用する一実施形態において、参照情報DB7に保存された参照情報とセンサ情報取得部2に取得されたセンサ情報とを比較し、一致していると判断できるか否かの判定については、次のように、伸縮を考慮しない実施形態と伸縮を考慮する実施形態とが可能である。
【００５９】
まず、伸縮を考慮しない実施形態では、事前に登録しておいた動作に対応する参照情報の長さがT秒であったとすると、当該T秒の参照情報ref(i)(i=1, 2, …, T)と、イベント検知瞬間のT秒前までに取得したセンサ情報の時系列sig(i)(i=1, 2, …, T)とを比較する。その際の差分diffが所定の閾値TH以下であれば、現在の動作が参照動作に似ていることを意味するため、一致していると判定し、一方で、所定の閾値THより大きければ現在の動作が参照動作に似ていないことを意味するため、一致していないと判定する。
【００６０】
なお、差分diffは、例えば以下の式(1)のように絶対値和などで評価すればよい。参照情報ref(i)及びセンサ情報の時系列sig(i)におけるiはサンプル番号であり、「T秒」というときの実際の長さは「T×サンプル周期」秒である。当該i, T等をサンプル番号として説明することは以下の説明でも同様である。また、図２で示したように、参照情報ref(i)及びセンサ情報の時系列sig(i)はN次元(N≧1)の量である。
【００６１】
【数１】
2016009244.tif 000003
【００６２】
図８に当該似ており一致していると判定できるか否かの判断の模式的な例を示す。(1)に示す参照情報に対し、(2)に示すデバイスAで取得されたセンサ情報は一致判定され、(3)に示すデバイス10Bで取得されたセンサ情報は不一致判定される。なお、当該図８の
例は図６の例と対応している。
【００６３】
一方、伸縮を考慮する実施形態では、T秒分の参照情報ref(i)(i=1, 2, …, T)に対して、イベント検知瞬間前におけるT'秒分の取得したセンサ情報sig(i)(i=1, 2, …, T')とを対応付けたうえで差分を求めて、同様に閾値THによって判定することができる。当該対応付ける際は、T'秒分のデータがT秒分となるように、時系列方向に伸縮すればよい。伸縮の方法として、線形に伸縮してもよいし、非線形に伸縮してもよい。非線形に伸縮する際には、周知のDTW (Dynamic Time Warping；動的時間収縮法)などを利用すればよい。
【００６４】
なお、当該伸縮されるT'の値は、伸縮しないTの値と同様に、予め所定の値を与えておいてもよいし、ユーザ入力を受けて動的に決定されるようにしてもよい。例えば、ユーザ入力で特定される、動作を開始できるタイミング（アプリで画像を全画面表示したタイミングや動作開始ボタンを用意してそれを押したタイミングなど）からイベント検知前までの時間をT'としてもよい。
【００６５】
伸縮を考慮する実施形態の意義は以下の通りである。
【００６６】
すなわち、ユーザがデバイス同士を近づけてデータの交換が開始するまでに、スムーズに開始されないケースが想定される。例えば、ユーザAが自身のデバイス10Aを相手Bのデバイス10Bに近づけて「タッチ」させたはずにもかかわらず、図４のステップS3における近接イベントが検知されなかったために、デバイス10A,10B間でうまく通信が開始せず、通信を開始させようとして、自分Aのデバイス10Aと相手Bのデバイス10Bとの距離や向きを少し変えてみるといった試行錯誤の操作を行い、当該操作の後に近接イベントが検知される場合がある。
【００６７】
こういった場合において、取得したセンサ情報と参照情報の対応付けを伸縮なしにもしくは線形伸縮で行うと、ユーザとしては参照動作に似た動作を行ったつもりでも、うまく通信が開始されなかった際の余分な動作の影響を含んで、判定されるため、参照情報との誤差が大きくなることが考えられる。一方で、取得したセンサ情報と参照情報の対応付けを非線形伸縮で行うと、余分な動作の部分の影響を吸収した上で、参照情報との誤差を求められるため、ユーザの期待した判定と同じ判定をすることができるという利点がある。
【００６８】
図９に、当該伸縮利用の利点を模式的に示す。(1)に示す参照情報に対して、(2)に示すあるデバイスのセンサ情報においては、イベント検知前のT秒範囲内に、タッチしようと試行錯誤するが成功しない間の動作が含まれ、当該T秒範囲内のセンサ情報は参照情報とは似ていないため、伸縮を考慮しないと不一致判定が下されてしまう。伸縮を考慮してT'秒（ここではT'＞T）の範囲のセンサ情報を利用することにより、本来の参照情報に対応する動作を模したタッチ時の動作の部分が含まれるようになり、一致判定が正しく下されるようになる。
【００６９】
以上、送受信判定部3が参照情報を利用する一実施形態を説明した。次に、送受信判定部3が参照情報を利用せず、参照情報登録部6及び参照情報DB7が省略される一実施形態を説明する。
【００７０】
当該実施形態では、イベント検知前のT秒間に取得したセンサ情報sig(i)(i=1, 2, …, T)より送受信判定装置10の変動量var（動きの大きさ）を推定し、当該推定された変動量varが閾値THより大きいかそうでないかにより、送信側・受信側を判定する。ここで、以下のようなユーザインタフェース的な観点からは、変動量varが閾値THより大きい場合には送信側と判定し、閾値TH以下である場合には受信側と判定するようにすることが好ましいが、用途次第であるので逆の判定を行うようにしてもよい。
【００７１】
すなわち、送信側のユーザはデータを相手に渡そうとするので能動的になり、受信側のデバイスに近づけようと手を伸ばすなどして、結果的に大きな動きになる一方で、受信側のユーザは、データを受け取るので受動的になり、送信側のユーザのデバイスが近づいてくるのを待ち構えるといったことを行い、結果的に小さな動きになるのが、ユーザ動作として自然であるという観点である。
【００７２】
なお、変動量varは、例えば以下の式(2)のように各時刻の成分絶対値の和や、式(3)のように各時刻の時間微分成分絶対値等により推定することができる。その他、センサ情報sig(i)(i=1, 2, …, T)及びその各成分の時間微分その他の所定関数として変動量varを推定してもよい。特に、センサ情報sig(i)(i=1, 2, …, T)に基づいて動きを再現するという考え方に基づく所定関数（移動距離の算出関数など）を用いることが好ましい。
【００７３】
【数２】
2016009244.tif 000004
【００７４】
また、以上の参照情報を利用する／しないの各実施形態とそれぞれ組み合わせ可能な一実施形態として、ユーザのこれまでの判定履歴を考慮して、送受信判定を行うことも可能である。当該実施形態では、送受信判定部3は判定履歴DB8を利用する。
【００７５】
図１０は、判定履歴DB8にて保存される判定履歴の例を示す図である。図示するように、送受信判定部3において送受信判定を行った際に、その判定に対して、判定履歴ID、日時、判定結果を判定履歴DB8に格納する。
【００７６】
判定履歴DB8が当該保存する判定履歴を考慮して、送受信判定部3は、送受信の判定を行うことが可能である。例えば、デバイス10A, 10Bがあって、デバイス10Aを持つユーザが複数のデータをデバイス10Bに対して送りたいというケースを考える。この際に、デバイス10Aと10Bの間での１回目の送受信判定で、10Aは送信側と判定されていたとすると、その直後に行われる2回目の送受信判定も10Aが送信側と判定されやすくなっていたほうが望ましい可能性がある。
【００７７】
送受信判定の送信側と受信側の判定されやすさは、参照情報を利用しない実施形態の場合は変動量varに対する閾値により、また、参照情報を利用する実施形態の場合は参照情報との間の差分diffに対する閾値により、それぞれ制御することができる。
【００７８】
従って、もともと設定された閾値TH（当該履歴を利用しない場合の初期値としての閾値TH）に対して、判定履歴DB8が保存している判定履歴に応じて変化する係数αを導入することで、以下の式(4)のように、判定履歴を考慮した閾値TH'を設定可能である。
TH' = TH + α      …(4)
【００７９】
例えば、参照情報を利用する実施形態の場合で、参照情報とセンサ情報とが一致していると判定される場合に送信側と判定する場合は、最新の送受信判定結果が送信側と判定されていれば、αに正の値を設定することで、参照情報との差分diffが多少大きくても送信側と判定するようになる傾向を、初期の閾値THを用いた場合よりも強くすることができる。
【００８０】
また例えば、参照情報を利用しない実施形態の場合で、変動量varが大きい場合に送信側と判定する場合は、最新の送受信判定結果が送信側と判定されていれば、αに負の値を設定する（ただしTH'の値が正となる範囲）ことで、それほど極端に大きな動作を加えなくとも送信側と判定されるようにすることができる。
【００８１】
その他、各実施形態の各場合に応じて、最新の送受信判定結果と同じ結果が、初期の閾値THを用いた場合よりも閾値TH'を用いた方がより確実に得られるようにするような係数として、係数αを予め設定しておくことができる。すなわち、判定履歴に従って設定される係数αによって、送信側・受信側の判定に際して、直近の判定結果がより再現されやすくなるような形で、判定履歴を考慮した判定を行うことができるようになる。当該係数αの大きさは開発者やエンドユーザが設定すればよい。
【００８２】
さらに、最新の1個の判定履歴だけでなく、直近のN個（複数）の判定履歴を考慮して判定してもよい。その際は、上記の係数αをN個の判定履歴内に含まれる送信側／受信側の数に応じて増減するような形で設定してもよい。また、判定履歴における判定日時が3分以内の判定結果のみを考慮して判定するといったように、判定した日時情報を利用して直近の所定期間の判定履歴を考慮して送受信判定を行ってもよい。
【００８３】
以上の説明では、データ共有に際して一方のデバイスが送信側、もう一方のデバイスが受信側となることを前提としていた。実際には、両方のデバイスが共に送信側又は受信側と判定される場合もある。
【００８４】
この場合、所定の代替処理を行うように予め設定しておけばよい。例えば、ユーザに送信側もしくは受信側のどちらかを選択させるインタフェースを提示して、ユーザに操作を求めて決定してもよいし、もう一度デバイス同士を近づける行為（近接イベントを発生させる行為）を促すようユーザに通知して、再度の送受信判定により送信側及び受信側に分かれて判定されるようにしてもよい。図１１に、以上のまとめとして、両デバイス10A,10Bの送受信判定結果と対応する処理とを示す。
【００８５】
ただし、相手のデバイスが送信側か受信側かを知ることができるタイミングは、相手とのデータ通信を行った後である。そのため、自分のデバイスがどちら側と判定されたのかといった情報を、実際に交換したいデータに含めるもしくは交換したいデータをやりとりする前に送り合うといったことが必要となる。
【００８６】
以上の説明では、データ共有は２台のデバイス10A,10B間でなされる場合を例として説明してきたが、３台以上のデバイス間でも同様にデータ共有を行うことができる。
【００８７】
当該デバイス台数に関連する一実施形態では、互いにデータを送受信することでデータ共有を行うデバイスが何台いるかによって、利用する参照情報その他の送受信判定方法を変更してもよい。ここで、デバイスの台数を検出する方法は、Bluetooth（登録商標）などで検知されるデバイス数を数えてもよいし、ユーザの操作により、2人モードまたは3人以上モードを選択してもよい。それに応じて、利用する参照情報その他を切り替えることで、デバイス数に応じた適切な送受信判定方法を提供できる。参照情報を利用しない実施形態の場合でも同様に、閾値THをデバイス数毎に設定しておくことができる。
【００８８】
例えば、２台のデバイス間でデータ送受信を行う場合、前述のようにユーザインタフェース的な観点から、送信側のデバイスに加わる動作は積極的な大きな動作であり、受信側のデバイスに加わる動作は消極的な小さな動作であることが考えられたが、３台以上のデバイス間でデータ共有する際は、逆の方が便利となることも考えられる。
【００８９】
例えば、デバイス10Aから10B、10Cに対して、データを送信する場合を考える。送信側のデバイス10Aを持つユーザAはデバイス10Aを卓上に置き、デバイス10B、10Cを持つユーザB,Cがデバイス10Aに近づける動作をするといったことが考えられる。この際には、送信側であるデバイス10Aの移動量は小さく、受信側であるデバイス10B、10Cの移動量は大きい。
【００９０】
以上のように、2台のデバイス間でデータを送受信する場合と、3台以上のデバイス間でデータを送受信する場合とで、ユーザの動作のパタンが異なる可能性があるため、デバイス数に応じてデータ共有が行いやすいように、送受信判定の態様を変えておいてよい。
【００９１】
以上の説明では、送受信判定装置10は、送信側又は受信側のいずれの役割でも機能することができ、センサ情報に従っていずれの役割かを判定したうえで、判定された役割に従ってデータ通信を行うものとしていた。判定方式は全く同様として、送受信判定装置10の役割が送信側又は受信側のいずれか一方に固定されるように、ユーザ設定等で予め設定しておくという形（実際の送受信の役割に制約を設けておく形）でも、本発明は実施可能である。
【００９２】
例えば、デバイス10Aはユーザが携帯して写真撮影等を行うスマートフォンであり、デバイス10Bはユーザが部屋に固定設置しているパーソナルコンピュータ(PC)であり、データ共有は、デバイス10Aで外で撮影してきた写真をデバイス10Bへとバックアップするという用途のみに用いることが予め決まっているような場合である。
【００９３】
この場合、デバイス10Aは必ず送信側であり、デバイス10Bは必ず受信側となるが、本発明は次のように実施できる。すなわち、デバイス10A,10B同士で共に図４のフローを以上の説明と全く同様に実行するが、この際、ステップS5のみを次のように修正する。
【００９４】
すなわち、デバイス10Aが送信側と判定され、デバイス10Bが受信側と判定された場合のみに、デバイス10Aからデバイス10Bへのデータ送信を行うようにすればよい。そして、予め設定された役割と異なり、デバイス10Aが受信側と判定された場合と、デバイス10Bが送信側と判定された場合は、データ通信は実施しない。
【００９５】
すなわち、ステップS5においてデータ通信部5では、当該デバイスに予め設定されている送信側又は受信側の役割と一致する役割が、ステップS4において送受信判定部3により判定された場合のみに、当該予め設定され且つ判定された役割に従って、データ通信を実施する。逆に、予め設定されているのと一致しない役割がステップS4において送受信判定部3により判定された場合は、データ通信を行わない。
【００９６】
このように制約を設けて本発明を実施する場合でも、ユーザ動作によりデータ共有を行おうとする旨の情報を、ユーザの直感的な動作のみから取得して実際にデータ共有を実行させることができる。従って、ユーザの送信側・受信側のマニュアル設定の手間が不要となる本発明の効果が得られることとなる。
【００９７】
また、各デバイスでは、上記のように制約を設けて必ず送信側又は受信側のいずれか片方のみとして利用される設定（固定設定）と、制約を設けずにユーザ動作に従って送信側又は受信側の両方のうちいずれかとして利用される設定（可変設定）とを、用途に応じて使い分け可能なように、ユーザがマニュアル設定により切り替えて設定可能となっていてもよい。
【００９８】
デバイス10Aが可変設定で、デバイス10Bが例えば受信側のみの固定設定の際は、デバイス10Aとデバイス10Bとの間で近接イベントを発生させ、デバイス10Aが受信側（デバイス10Bに固定設定された役割）と判定された場合には、デバイス10Bは例外的に固定設定を解除して送信側として機能するようにしてもよい。こうして、普段はスマートフォンであるデバイス10AからPCであるデバイス10Bにデータをバックアップのために保存するという用途で利用するが、必要に応じて逆にPC(デバイス10B)からスマートフォン(デバイス10A)にデータを取り寄せてきて保存するようにする、といったことも可能となる。
【００９９】
図１２に、本発明の送受信判定による効果の一例を示す。デバイスAにある写真をデバイスBに送りたい場合、デバイスAにはアプリを介してその写真が表示されることが多い。デバイスAに送りたい写真が表示されているという表示上の条件に紐付けて、送信側と判定する。一方で、デバイスBに写真が表示されていなければ、待受状態として、受信側と判定する。この場合は、送信側と受信側の対が確立できているため、デバイスAからデバイスBに写真を送ることができる。
【０１００】
しかしながら、デバイスBにおいて、デバイスAと同様にアプリを介して写真が表示されている場合、デバイスBも送信側と判定されるため、図１２の左側に示す従来技術では、デバイスAもデバイスBも送信側と判定されてしまう。これは、表示上の条件と送受信者側の判定とを紐付けていることに起因するものである。
【０１０１】
一方で、図１２の右側に示す本発明は、表示上の条件とは独立して、データを交換しようとする際のユーザの動作に紐づけているため、デバイスAもデバイスBも写真が表示されている場合であっても、送信側と受信側を自動で判別して、デバイスAからデバイスBに写真を送ることができる。
【０１０２】
本発明は、コンピュータを送受信判定装置10として機能させるプログラムとしても提供可能である。当該コンピュータには、CPU（中央演算装置）、メモリ及び入出力I/Fといったような周知のハードウェア構成のものを利用可能である。なお、センサは当該コンピュータの外部に設けて、センサ情報を入力I/Fより取り込めばよい。
【０１０３】
以上、本発明によれば、デバイス間でデータを交換し共有する際に、送信及び受信を意図するユーザの動作に基づき、自動で送受信者の判定を行うことができる。自デバイスが送受信のどちらとして振る舞うべきかを選択するためのユーザ操作を軽減することができ、データ交換のユーザビリティが高まる。
【符号の説明】
【０１０４】
10…送受信判定装置、1…センサ部、2…センサ情報取得部、3…送受信判定部、4…イベント検知部、5…データ通信部、6…参照情報登録部、7…参照情報DB、8…判定履歴DB
【図１】
2016009244.tif 000005
【図２】
2016009244.tif 000006
【図３】
2016009244.tif 000007
【図４】
2016009244.tif 000008
【図５】
2016009244.tif 000009
【図６】
2016009244.tif 000010
【図７】
2016009244.tif 000011
【図８】
2016009244.tif 000012
【図９】
2016009244.tif 000013
【図１０】
2016009244.tif 000014
【図１１】
2016009244.tif 000015
【図１２】
2016009244.tif 000016