(57)【要約】【課題】ＩｏＴサービスに利用されるデバイスの切替え頻度を低減すること。【解決手段】サーバ装置１０は、第１端末が自装置にアクセス可能なエリアに入ってきた時刻と、アクセス不可になった時刻を検出し、検出した各時刻から算出されるアクセス可能時間を所定の記憶部に登録し、第２端末が自装置にアクセス可能であることを検出すると、記憶部に記憶したアクセス可能時間に基づいて、自装置または第２端末を選択する。【選択図】図２
2018129721.tif 000002
【特許請求の範囲】
【請求項１】
第１端末が自装置にアクセス可能なエリアに入ってきた時刻と、アクセス不可になった時刻を検出する検出部と、
検出した各時刻から定まるアクセス可能時間を記憶する記憶部と、
第２端末が自装置にアクセス可能であることを検出すると、前記記憶部に記憶したアクセス可能時間に基づいて、自装置または前記第２端末を選択する選択部と、
を有することを特徴とする通信装置。
【請求項２】
前記記憶部が記憶した複数のアクセス可能時間に所定の統計処理を行うことにより得られた統計値を前記第２端末のアクセス可能時間として推定する推定部をさらに有し、
前記選択部は、前記推定部が推定したアクセス可能時間が所定の閾値以上であるか否かにより、自装置または前記第２端末を選択することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記推定部は、前記記憶部が記憶した複数のアクセス可能時間の平均値を算出することにより前記第２端末のアクセス可能時間を推定することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記記憶部が記憶した複数のアクセス可能時間がクラスタリングされたクラスタのうち２つのクラスタを選択し、前記２つのクラスタごとに当該クラスタに含まれるアクセス可能時間の統計値を算出することにより第１のアクセス可能時間及び前記第１のアクセス可能時間よりも長い第２のアクセス可能時間を推定する推定部を有し、
前記選択部は、前記第１のアクセス可能時間が所定の閾値以上であるか否かにより自装置または前記第２端末を選択し、前記第２端末を選択した場合、前記第２端末が選択されてから前記第１のアクセス可能時間が経過した後に前記第２のアクセス可能時間が前記閾値以上であるか否かにより自装置または前記第２端末を選択することを特徴とする請求項１に記載の通信装置。
【請求項５】
第１端末が自装置にアクセス可能なエリアに入ってきた時刻と、アクセス不可になった時刻を検出し、
検出した各時刻から定まるアクセス可能時間を所定の記憶部に登録し、
第２端末が自装置にアクセス可能であることを検出すると、前記記憶部に記憶したアクセス可能時間に基づいて、自装置または前記第２端末を選択する、
処理がコンピュータにより実行されることを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信方法に関する。
【背景技術】
【０００２】
スマートフォン、タブレット端末、ウェアラブルコンピュータ等のデバイスの多様化に伴って様々なＩｏＴ（Internet  of  Things）サービスが実現されている。このようなＩｏＴサービスには、デバイスに搭載されたカメラやマイクなどによりセンシングされたメディアデータが活用される。例えば、人間の生活、行いや体験を、位置情報だけでなく、映像や音声などのメディアデータも含めて記録するライフログなどが知られている。
【０００３】
ここで、ＩｏＴサービスに利用されるＩｏＴデバイスがユーザにより携帯されるユーザデバイスである場合、その稼働にはバッテリの制約が生じる。このため、施設や施設内の区画などの各種の環境に設置された場デバイスにユーザデバイスによるＩｏＴサービスを代行させる場合がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−２１７０２３号公報
【特許文献２】特開２００４−３３６３１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の技術では、ＩｏＴサービスに利用されるデバイスが頻繁に切り替わる場合がある。
【０００６】
すなわち、ＩｏＴサービスが終了するまでユーザが一定の場所に留まる場合もあれば、ユーザの居場所が一定しない場合もある。このため、環境に設置された場デバイスを活用しようとしてもユーザの居場所が一定しなければ、ＩｏＴサービスに利用されるデバイスをユーザデバイスから場デバイスへ切り替えた後に再び場デバイスからユーザデバイスへ戻さなければならない事態に陥る。このように切替えが頻繁に発生すると、センシングの実行主体も頻繁に切り替わることになるので、ＩｏＴサービスの品質が低下してしまう。
【０００７】
１つの側面では、本発明は、ＩｏＴサービスに利用されるデバイスの切替え頻度を低減できる通信装置及び通信方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一態様では、第１端末が自装置にアクセス可能なエリアに入ってきた時刻と、アクセス不可になった時刻を検出する検出部と、検出した各時刻から定まるアクセス可能時間を記憶する記憶部と、第２端末が自装置にアクセス可能であることを検出すると、前記記憶部に記憶したアクセス可能時間に基づいて、自装置または前記第２端末を選択する選択部と、を有する。
【発明の効果】
【０００９】
ＩｏＴサービスに利用されるデバイスの切替え頻度を低減できる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るＩｏＴシステムの構成例を示す図である。
【図２】図２は、実施例１に係るサーバ装置の機能的構成を示すブロック図である。
【図３】図３は、アクセス履歴データの一例を示す図である。
【図４】図４は、アクセス履歴データの一例を示す図である。
【図５】図５は、実施例１に係るデバイス選択処理の手順を示すフローチャートである。
【図６】図６は、デバイス選択処理の応用例の手順を示すフローチャートである。
【図７】図７は、実施例１及び実施例２に係る通信プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して本願に係る通信装置及び通信方法について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１２】
［ＩｏＴシステム］
図１は、実施例１に係るＩｏＴシステムの構成例を示す図である。図１に示すＩｏＴシステム１は、ユーザデバイス３０又は場デバイス５０Ａ〜５０Ｃの中から、ＩｏＴサービスに用いるメディアデータのセンシングを実施させるＩｏＴデバイスを選択するデバイス選択サービスを提供するものである。
【００１３】
図１に示すように、ＩｏＴシステム１には、サーバ装置１０と、ユーザデバイス３０と、場デバイス５０Ａ〜５０Ｃとが含まれる。図１には、１つのユーザデバイス３０と、３つの場デバイス５０Ａ〜５０Ｃとを図示したが、任意の数のユーザデバイス及び場デバイスがサーバ装置１０に収容されることとしてもかまわない。以下では、場デバイス５０Ａ〜５０Ｃを総称する場合に「場デバイス５０」と記載する場合がある。
【００１４】
サーバ装置１０と、ユーザデバイス３０及び場デバイス５０との間は、ネットワークＮＷを介して接続される。このネットワークＮＷは、有線または無線を問わず、任意の通信網により構築することができる。さらに、ネットワークＮＷの一部には、有線または無線の通信網が混在してもよい。例えば、ネットワークＮＷには、ユーザデバイス３０を収容するセルに対応する最寄りの基地局やアクセスポイント等の中継装置が含まれてもかまわない。
【００１５】
サーバ装置１０は、ユーザデバイス３０に上記のデバイス選択サービスを提供するコンピュータである。
【００１６】
一実施形態として、サーバ装置１０は、パッケージソフトウェア又はオンラインソフトウェアとして、上記のデバイス選択サービスを実現するデバイス選択プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、サーバ装置１０は、上記のデバイス選択サービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記のデバイス選択サービスを提供するクラウドとして実装することとしてもかまわない。
【００１７】
ユーザデバイス３０は、ユーザにより携帯されるＩｏＴデバイスである。
【００１８】
一実施形態として、ユーザデバイス３０には、スマートフォン、携帯電話機やＰＨＳ（Personal  Handyphone  System）などの移動体通信端末のみならず、タブレット端末やスレート端末などを採用することができる。このようにハンドヘルド型の携帯端末装置に限定されず、ユーザデバイス３０には、ヘッドマウントディスプレイ、スマートグラスやスマートウォッチなどのウェアラブルデバイスの他、あらゆる携帯端末装置を採用することができる。
【００１９】
ユーザデバイス３０は、ユーザデバイス３０に搭載されるセンサを用いて、音声や映像などのメディアデータをセンシングすることができる。例えば、音声のセンシングには、ユーザデバイス３０に搭載されたマイクロフォンを用いることができる。このマイクロフォンは、特定の方向への指向性を有するものであってもよいし、無指向性のものであってもかまわない。また、映像のセンシングには、ユーザデバイス３０に搭載されたカメラを用いることができる。このカメラによって撮像される映像は、静止画であってもよいし、動画であってもよい。
【００２０】
場デバイス５０は、各種の環境に設置されるＩｏＴデバイスである。ここで言う「環境」とは、ＩｏＴデバイスが配置可能な場所であれば任意の場所を含んでよい。例えば、施設、施設に含まれるルームやテナント、または、施設、ルームもしくはテナントなどに区画されたブースやコンパートメントなどが挙げられる。
【００２１】
一側面として、場デバイス５０が有するＩＣＴ基盤、例えばネットワークの接続機能を始め、メディアのセンシング機能などは、上記のＩｏＴサービスを利用するユーザに開放される。すなわち、ユーザには、ＩｏＴサービスの利用に用いるアカウントが付与されており、このアカウントにユーザデバイス３０を介してログインすることにより、サーバ装置１０から上記のデバイス選択サービスの提供を受けることが可能な状態となる。
【００２２】
例えば、場デバイス５０には、据置き型または設置型のデバイスを採用することができる。例えば、入退室管理、監視や認証などの実現する観点から、環境にマイク付きのカメラが設けられる場合がある。このようなマイク付きのカメラは、ユーザデバイス３０で実施されるメディアデータのセンシングをサーバ装置１０からの指示にしたがって代行することができる。この他、マイクロフォンがマイク端子を介して接続された据置き型またはノート型のコンピュータ、例えばパーソナルコンピュータを場デバイス５０として実装することもできる。さらに、ゲートウェイ装置などの中継装置においてもＵＳＢ（Universal  Serial  Bus）端子を介して各種のデバイスを接続できるものが多いので、これを場デバイス５０として実装することもできる。この他、案内、広告、クーポンの発行等を目的に施設内にディスプレイ装置が配設されることがある。このディスプレイ装置に対する操作に視線認識、音声認識やジェスチャ認識などの技術が用いられる場合もある。この場合、ディスプレイ装置にはカメラやマイクが付設または内蔵されるので、このようなディスプレイ装置も場デバイス５０として実装することができる。このように、場デバイス５０には、商用電源等の外部電源に接続されたデバイスを採用できる。なお、ここでは、説明の便宜上、あくまで一例として、場デバイス５０が据置き型または設置型のデバイスである場合を例示するが、他のユーザにより携帯されるユーザデバイスを場デバイス５０とすることもできる。
【００２３】
このように、ＩｏＴシステム１では、ＩｏＴサービスに用いるメディアデータのセンシングを実行させるＩｏＴデバイスの選択肢として、ユーザデバイス３０に留まらず、場デバイス５０が加えられる。
【００２４】
すなわち、上記のユーザデバイス３０は、必ずしも外部電源に接続された状態で稼働できるとは限らず、バッテリから供給される電力により稼働する。このような状況の下、マイクやカメラが連続して駆動されると、バッテリの消費が激しくなる。この結果、ＩｏＴサービスが終了する前にユーザデバイス３０のバッテリ残量がなくなってしまう事態も起こりうる。
【００２５】
このようなバッテリ切れによりＩｏＴサービスの中断を抑制することを一側面として、サーバ装置１０は、メディアデータのセンシングをユーザデバイス３０の周囲に存在する場デバイス５０に代行させる。例えば、図１には、一例として、３つの場デバイス５０Ａ、５０Ｂ及び５０ＣがサービスエリアＥ１、Ｅ２およびＥ３に設置されている。このように、場デバイス５０Ａ、５０Ｂ及び５０Ｃの３つの他のデバイスにユーザデバイス３０におけるメディアデータのセンシングを代行させうる状況にある。例えば、図１に示すように、ユーザデバイス３０がサービスエリアＥ２に位置する場合、場デバイス５０Ｂにユーザデバイス３０におけるメディアデータのセンシングを代行させることができる。
【００２６】
しかしながら、ＩｏＴサービスが終了するまでユーザが一定の場所に留まる場合もあれば、ユーザの居場所が一定しない場合もある。このため、環境に設置された場デバイス５０を活用しようとしてもユーザの居場所が一定しなければ、ＩｏＴサービスに利用されるデバイスをユーザデバイス３０から場デバイス５０へ切り替えた後に再び場デバイス５０からユーザデバイス３０へ戻さなければならない事態に陥る。このように切替えが頻繁に発生すると、センシングの実行主体も頻繁に切り替わることになるので、ＩｏＴサービスの品質が低下してしまう。
【００２７】
そこで、本実施例に係るサーバ装置１０は、環境に設置された場デバイス５０へのアクセスが可能から不可になるまでの期間から推定したユーザデバイス３０のアクセス可能時間に基づいてＩｏＴサービスに用いるメディアデータのセンシングを場デバイス５０に切り替えるか否かを制御する。それ故、ユーザの居場所が一定しない可能性が高い場合、場デバイス５０への切替えを抑制できる。したがって、本実施例に係るサーバ装置１０によれば、ＩｏＴサービスに利用されるデバイスの切替え頻度を低減できる。このようにＩｏＴサービスに利用されるデバイスの切替え頻度が低減される結果、ＩｏＴサービスの品質が低下するのも抑制できる。さらに、ユーザが一定の場所に留まる可能性が高い場合、場デバイス５０へ切り替えることができる。このため、ユーザデバイス３０のバッテリ消費も抑えることができる。
【００２８】
［サーバ装置１０の構成］
図２は、実施例１に係るサーバ装置１０の機能的構成を示すブロック図である。図２に示すように、サーバ装置１０は、通信Ｉ／Ｆ（InterFace）部１１と、記憶部１３と、制御部１５とを有する。なお、図２には、データの授受の関係を表す実線が示されているが、図２には、説明の便宜上、最小限の部分について示されているに過ぎない。すなわち、各処理部に関するデータの入出力は、図示の例に限定されず、図示以外のデータの入出力、例えば処理部及び処理部の間、処理部及びデータの間、並びに、処理部及び外部装置の間のデータの入出力が行われることとしてもかまわない。
【００２９】
通信Ｉ／Ｆ部１１は、他の装置、例えばユーザデバイス３０や場デバイス５０との間で通信制御を行うインタフェースである。
【００３０】
一実施形態として、通信Ｉ／Ｆ部１１には、ＬＡＮ（Local  Area  Network）カードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１は、ユーザデバイス３０からＩｏＴサービスの開始要求または終了要求を受信したり、ユーザデバイス３０または場デバイス５０によりセンシングされたメディアデータを受信したりする。また、通信Ｉ／Ｆ部１１は、メディアデータのセンシング指示をユーザデバイス３０または場デバイス５０へ送信する。
【００３１】
記憶部１３は、制御部１５で実行されるＯＳ（Operating  System）を始め、上記のデバイス選択サービスを実現するアプリケーションプログラムなどの各種プログラムに用いられるデータを記憶する記憶デバイスである。
【００３２】
一実施形態として、記憶部１３は、サーバ装置１０における補助記憶装置として実装することができる。例えば、記憶部１３には、ＨＤＤ（Hard  Disk  Drive）、光ディスクやＳＳＤ（Solid  State  Drive）などを採用できる。なお、記憶部１３は、必ずしも補助記憶装置として実装されずともよく、サーバ装置１０における主記憶装置として実装することもできる。この場合、記憶部１３には、各種の半導体メモリ素子、例えばＲＡＭ（Random  Access  Memory)やフラッシュメモリを採用できる。
【００３３】
記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、場デバイスデータ１３ａと、アクセス履歴データ１３ｂとを記憶する。これらのデータ以外にも、次のような電子データを記憶することもできる。例えば、ユーザデバイス３０または場デバイス５０によりセンシングされるメディアデータの他、各種のＩｏＴサービスに関する定義、例えばＩｏＴサービスに用いるメディアデータの種類（音声、映像、音声＋映像など）やＩｏＴサービスの適用期間などの情報も併せて記憶することもできる。
【００３４】
場デバイスデータ１３ａは、場デバイス５０に関するデータである。
【００３５】
一実施形態として、場デバイスデータ１３ａには、デバイスＩＤ（IDentification）および位置などの項目を含むデータを採用できる。ここで言う「デバイスＩＤ」とは、ＩｏＴデバイスを識別する識別情報を指すが、ここでは、一例として、場デバイス５０のデバイスＩＤが場デバイスデータ１３ａとして保持されることとする。また、「位置」とは、ＩｏＴデバイスが所在する位置を指し、例えば、緯度や経度などのグローバルな座標であってもよいし、ローカルに定義された座標であってもかまわない。ここでは、あくまで一例として、場デバイスデータ１３ａにより場デバイス５０の位置を管理する場合を例示したが、場デバイス５０に限らず、ユーザデバイス３０の位置を管理することもできる。この場合、ユーザデバイス３０から位置情報が取得される度に当該ユーザデバイス３０のデバイスＩＤに対応するレコードが持つ位置のフィールドを更新することにより、ユーザデバイス３０の現在位置も含めてデバイスデータとして管理できる。
【００３６】
アクセス履歴データ１３ｂは、各場デバイス５０に対するユーザデバイス３０のアクセス履歴に関するデータである。
【００３７】
一実施形態として、アクセス履歴データ１３ｂには、場デバイス５０ごとに、デバイスＩＤ、開始時刻およびアクセス可能時間などの項目が対応付けられたデータを採用できる。ここで言う「デバイスＩＤ」とは、ＩｏＴデバイスを識別する識別情報を指すが、ここでは、一例として、ユーザデバイス３０のデバイスＩＤがアクセス履歴データ１３ｂとして保持されることとする。また、「開始時刻」とは、ユーザデバイス３０による場デバイス５０へのアクセスが可能になった時刻を指す。さらに、「アクセス継続期間」とは、ユーザデバイス３０による場デバイス５０へのアクセスが可能となった状態が継続する期間を指し、期間を示す情報と共にアクセス可能な状態が継続中であるか否かが２値情報などを通じてコンピュータにより識別可能な状態で保持される。
【００３８】
制御部１５は、サーバ装置１０の全体制御を行う処理部である。
【００３９】
一実施形態として、制御部１５は、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などのハードウェアプロセッサにより実装することができる。ここでは、プロセッサの一例として、ＣＰＵやＭＰＵを例示したが、汎用型および特化型を問わず、任意のプロセッサにより実装することができる。この他、制御部１５は、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などのハードワイヤードロジックによって実現されることとしてもかまわない。
【００４０】
制御部１５は、図示しない主記憶装置として実装されるＤＲＡＭ（Dynamic  Random  Access  Memory）やＳＲＡＭ（Static  Random  Access  Memory）などのＲＡＭのワークエリア上に、上記のネットワーク管理サービスの機能を実現するネットワーク管理プログラムを展開することにより、下記の処理部を仮想的に実現する。
【００４１】
制御部１５は、図２に示すように、検出部１５ａと、更新部１５ｂと、推定部１５ｃと、選択部１５ｄとを有する。
【００４２】
検出部１５ａは、場デバイス５０へのアクセスの可否を検出する処理部である。
【００４３】
一実施形態として、検出部１５ａは、ユーザデバイス３０及び場デバイス５０の地理的条件により、ユーザデバイス３０による場デバイス５０へのアクセスが可能であるか、あるいはユーザデバイス３０による場デバイス５０へのアクセスが不可であるかを検出する。
【００４４】
より詳細には、検出部１５ａは、ライフログ等のＩｏＴサービスが実施中であるユーザのアカウントに関連付けられたユーザデバイス３０のデバイスＩＤのリストを保持する図示しない内部メモリのワークエリアから、ユーザデバイス３０のデバイスＩＤを１つ選択する。続いて、検出部１５ａは、先に選択されたデバイスＩＤに対応するユーザデバイス３０から位置情報を取得する。例えば、検出部１５ａは、ユーザデバイス３０の位置情報として、ユーザデバイス３０に搭載されたＧＰＳ（Global  Positioning  System）受信機が測定する緯度および経度を取得することができる。この他、検出部１５ａは、ユーザデバイス３０からユーザデバイス３０が収容されるセルの基地局、例えばアクセスポイントなどの位置情報を取得することもできる。このアクセスポイントの位置情報は、そのままユーザデバイス３０の位置情報として用いることもできるし、ユーザデバイス３０の受信電波強度等から割り出されるユーザデバイス３０及びアクセスポイント間の距離を用いてユーザデバイス３０の位置情報を求めることもできる。その上で、検出部１５ａは、記憶部１３に記憶された場デバイスデータ１３ａを参照して、ユーザデバイス３０がアクセス可能な場デバイス５０を検索する。例えば、場デバイスデータ１３ａに含まれる場デバイス５０のデバイスＩＤごとに、当該デバイスＩＤに対応付けられた場デバイス５０の位置と、ユーザデバイス３０の位置情報とを比較することにより、ユーザデバイス３０からの距離が所定の範囲、例えば１０ｍ以内である場デバイス５０が存在するか否かが判定される。
【００４５】
なお、ここでは、ユーザデバイス３０による場デバイス５０へのアクセスが可能または不可であるかを地理的条件により判定する場合を例示したが、これに限定されない。例えば、ユーザデバイス３０から位置情報の代わりに、ＳＳＩＤ（Service  Set  Identifier）のリストを取得することができる。このようにユーザデバイス３０から取得されるＳＳＩＤのリストの中に、場デバイス５０に対応するＳＳＩＤが含まれるか否かにより、ユーザデバイス３０による場デバイス５０へのアクセスが可能または不可であるかを判定することもできる。
【００４６】
更新部１５ｂは、アクセス履歴データ１３ｂを更新する処理部である。
【００４７】
一側面として、更新部１５ｂは、検出部１５ａによりユーザデバイス３０からの距離が所定の範囲内である場デバイス５０が存在するか否かが検出される度に、次のような処理を実行する。例えば、ユーザデバイス３０からの距離が所定の範囲内である場デバイス５０が存在する場合、ユーザデバイス３０が場デバイス５０へアクセス可能であると推定できる。この場合、更新部１５ｂは、ユーザデバイス３０がアクセス可能である場デバイス５０に関するアクセス履歴の中に当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みであるか否かを判定する。ここで、ユーザデバイス３０がアクセス可能である場デバイス５０に関するアクセス履歴の中に当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが存在する場合でも、当該エントリのアクセス継続期間に含まれる２値情報としてアクセス可能な状態が継続中でないことを示す２値情報が保持される場合、同一のユーザデバイス３０のデバイスＩＤを有するエントリであっても別のアクセス履歴として扱うために、当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みでないと判定される。そして、更新部１５ｂは、当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みである場合、当該ユーザデバイス３０のアクセス履歴のエントリに含まれるアクセス継続期間を更新する。例えば、更新部１５ｂは、システム時刻等から参照される現時刻から開始時刻を差し引く計算により最新のアクセス継続期間を算出し、当該最新のアクセス継続期間を上書きする更新を行うことができる。一方、更新部１５ｂは、当該ユーザデバイス３０に関するアクセス履歴のエントリが作成済みでない場合、当該ユーザデバイス３０に関するアクセス履歴のエントリを新規に作成する。すなわち、更新部１５ｂは、ユーザデバイス３０がアクセス可能である場デバイス５０に関するアクセス履歴として、「デバイスＩＤ」のフィールドには、当該場デバイス５０へのアクセスが可能となったユーザデバイス３０のデバイスＩＤを格納し、「開始時刻」のフィールドには、当該場デバイス５０へのアクセスが可能となった現時刻、すなわちレコードの作成時刻を格納し、「アクセス継続期間」のフィールドには、ＮＵＬＬ値やゼロなどの値を格納した、新規エントリを作成する。
【００４８】
一方、ユーザデバイス３０からの距離が所定の範囲内である場デバイス５０が存在しない場合、ユーザデバイス３０が場デバイス５０へアクセス不可であると推定される。この場合、ユーザデバイス３０の代わりにメディアデータのセンシングを実施できる場デバイス５０がユーザデバイス３０の周辺に存在しないことが判明する。この場合、ＩｏＴサービスに用いるメディアデータのセンシングを場デバイス５０に実施させる余地がない。それ故、後述の選択部１５ｄによりユーザデバイス３０がメディアデータのセンシングを実施するセンシングデバイスとして選択されることになる。
【００４９】
推定部１５ｃは、ユーザデバイス３０が場デバイス５０にアクセス可能な時間を推定する処理部である。以下では、ユーザデバイス３０が場デバイス５０にアクセス可能な時間のことを「アクセス可能時間」と記載する場合がある。
【００５０】
一側面として、推定部１５ｃは、アクセス履歴データ１３ｂに新規エントリが作成された場合、処理を起動する。例えば、推定部１５ｃは、新規エントリが作成された場デバイス５０に関するアクセス履歴のエントリを読み出す。その上で、推定部１５ｃは、各エントリに含まれるアクセス継続期間に所定の統計処理を行う。この統計処理の一例として、最頻値、中央値、加重平均値や相加平均値などの各種の統計値を算出する処理を実行することができる。ここでは、一例として、各エントリのアクセス継続期間の平均値、すなわち相加平均値が算出される場合を例示する。これにより、各エントリのアクセス継続期間の平均値が「アクセス可能時間」として推定される。
【００５１】
選択部１５ｄは、ユーザデバイス３０及び場デバイス５０のうちいずれかのデバイスを、ＩｏＴサービスに用いるメディアデータのセンシングを実行させるデバイスとして選択する処理部である。以下では、ＩｏＴサービスに用いるメディアデータのセンシングを実行させるデバイスのことを「センシングデバイス」と記載する場合がある。
【００５２】
一側面として、選択部１５ｄは、推定部１５ｃにより推定されたアクセス可能時間と、所定の閾値とを比較することにより、センシングデバイスをユーザデバイス３０から場デバイス５０へ切り替えるか否かを判定する。このような閾値の一例として、ＩｏＴサービスごとに設定可能な最短継続時間を用いることができる。例えば、ライフログ等のＩｏＴサービスが利用される場合、メディアデータとして動画がセンシングされる。この場合、動画を撮像する撮像デバイスが短期間で切り替わると、撮影が行われる視点や撮像範囲などが頻繁に切り替わる動画しか得られないことになる。このことから、ユーザ、あるいはＩｏＴシステム１の設計者や管理者等から、最短で撮像デバイスが切り替わるのを許容できる時間、例えば１０分間などを「最短継続時間」として設定させることができる。
【００５３】
例えば、選択部１５ｄは、アクセス可能時間が最短継続時間以上であるか否か、すなわちアクセス可能時間≧最短継続時間であるか否かを判定する。ここで、アクセス可能時間≧最短継続時間である場合、最短継続時間以上の期間にわたってユーザデバイス３０の代わりに当該場デバイス５０をセンシングデバイスとして使用できることが期待できる。言い換えれば、センシングデバイスをユーザデバイス３０から場デバイス５０へ切り替えた後、最短継続時間未満でセンシングデバイスを場デバイス５０からユーザデバイス３０へ切り替える再切替えを抑制できる可能性が高いと推定できる。この場合、選択部１５ｄは、場デバイス５０をセンシングデバイスとして選択する。一方、アクセス可能時間≧最短継続時間でない場合、センシングデバイスをユーザデバイス３０から場デバイス５０へ切り替えた後、最短継続時間未満でセンシングデバイスを場デバイス５０からユーザデバイス３０へ切り替える再切替えを抑制できない可能性が高いと推定できる。この場合、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択する。
【００５４】
その後、選択部１５ｄは、メディアデータのセンシング及び伝送をセンシングデバイスに指示する。その後、センシングデバイスから伝送される音声または映像のストリームデータを復号化し、復号化されたメディアデータが所定の出力先、例えばＩｏＴサービスに対応するアプリケーションプログラムに出力されることになる。これによって、ＩｏＴサービスに対応するアプリケーションプログラムにより、メディアデータを用いてＩｏＴサービスが提供されることになる。
【００５５】
なお、アクセス可能時間が最短継続時間以上である場デバイス５０が複数存在する場合、その中から１つを選択する。この択一の選択基準は特定の基準に限定されないが、一例として、複数の場デバイス５０のうちユーザデバイス３０との距離が最短である場デバイス５０を選択したり、撮像や録音などを行うセンサとして最高の性能を持つセンサが搭載される場デバイス５０を選択することができる。
【００５６】
他の側面として、選択部１５ｄは、ＩｏＴサービスが実施中であるユーザのアカウントのうちセンシングデバイスとして場デバイス５０が選択されているユーザのアカウントごとに、次のような処理を実行する。すなわち、選択部１５ｄは、検出部１５ａによりユーザデバイス３０からの距離が所定の範囲内である場デバイス５０が存在しないと判定されるか、あるいはアクセス履歴データ１３ｂに含まれるアクセス継続期間に継続中でないことを示す２値情報が保存されるかを監視する。これらの条件のいずれかを満たす場合、ユーザデバイス３０の代わりにメディアデータのセンシングを実施できる場デバイス５０がユーザデバイス３０の周辺に存在しないことが判明する。この場合、ＩｏＴサービスに用いるメディアデータのセンシングを場デバイス５０に実施させる余地がない。それ故、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択する。
【００５７】
［センシングデバイスの選択方法の具体例］
次に、図３及び図４を用いて、センシングデバイスの選択方法の具体例について説明する。図３及び図４は、アクセス履歴データ１３ｂの一例を示す図である。図３及び図４には、道路上に設置された場デバイス５０Ａに関するアクセス履歴データ１３ｂＡと、店舗に設置された場デバイス５０Ｂに関するアクセス履歴データ１３ｂＢとが示されている。さらに、図３には、６月７日の１１時００分の時点のアクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢが示されており、図４には、６月７日の１１時１２分の時点のアクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢが示されている。また、図３及び図４には、場デバイス５０Ａ及び場デバイス５０Ｂへのアクセスが可能であるエリアが塗り潰しにより示されている。さらに、図３及び図４には、アクセス履歴データ１３ｂＢにエントリが存在するデバイスＩＤ「ｕｓｅｒ３０Ｃ」及び「ｕｓｅｒ３０Ｅ」のユーザデバイス３０Ｃ及びユーザデバイス３０Ｅの位置情報の軌跡、いわゆる動線が一点鎖線および二点鎖線により示されている。
【００５８】
このような状況の下、デバイスＩＤ「ｕｓｅｒ３０Ａ」のユーザデバイス３０Ａを携帯するユーザが図３及び図４に点線で示す位置情報の軌跡にしたがって移動する場合におけるセンシングデバイスの選択方法について説明する。
【００５９】
図３に点線の矢印で示すように、６月７日の１１時００分の時点では、デバイスＩＤ「ｕｓｅｒ３０Ａ」のユーザデバイス３０Ａが場デバイスデータ１３ａに含まれる場デバイス５０Ａの位置（ｘ１，ｙ１）から１０ｍ以内のエリアへ進入する。これに伴って、ユーザデバイス３０Ａによる場デバイス５０Ａへのアクセスが可能であることが検出部１５ａにより検出される。この段階では、場デバイス５０Ａのアクセス履歴データ１３ｂＡには、ユーザデバイス３０Ａのアクセス履歴のエントリが存在しないので、ユーザデバイス３０Ａのアクセス履歴のエントリが新規に作成される。すなわち、「デバイスＩＤ」のフィールドには、「ｕｓｅｒ３０Ａ」が格納され、「開始時刻」のフィールドには、現時刻である６月７日の１１時００分が格納されると共に、「アクセス継続期間」のフィールドには、「０：００」が格納された新規エントリがアクセス履歴データ１３ｂＡに作成される。
【００６０】
このように新規エントリが作成された場合、推定部１５ｃによりアクセス可能時間が推定される。すなわち、アクセス履歴データ１３ｂのうち新規エントリが作成された場デバイス５０Ａに関するアクセス履歴データ１３ｂＡの各エントリが参照される。これらのエントリのうち、新規エントリを除くと、図３に示すアクセス履歴データ１３ｂＡには、デバイスＩＤ「ｕｓｅｒ３０Ｂ」のユーザデバイス３０Ｂ、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｃ及びデバイスＩＤ「ｕｓｅｒ３０Ｄ」のユーザデバイス３０Ｄに関するアクセス履歴のエントリが含まれる。
【００６１】
これらデバイスＩＤ「ｕｓｅｒ３０Ｂ」、デバイスＩＤ「ｕｓｅｒ３０Ｃ」及びデバイスＩＤ「ｕｓｅｒ３０Ｄ」のエントリに含まれるアクセス継続時間が読み出される。すなわち、デバイスＩＤ「ｕｓｅｒ３０Ｂ」のユーザデバイス３０Ｂのアクセス継続期間として「２分」が読みされる。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｃのアクセス継続期間として「２分」が読み出される。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｄ」のユーザデバイス３０Ｄのアクセス継続期間として「５分」が読み出される。これらのアクセス継続期間を平均する計算、すなわち「（２分＋２分＋５分）／３」を行うことにより、アクセス可能時間を「３分」と推定できる。
【００６２】
このように推定されたアクセス可能時間に基づいてセンシングデバイスをユーザデバイス３０Ａから場デバイス５０Ａへ切り替えるか否かが選択部１５ｄにより判定される。すなわち、アクセス可能時間がＩｏＴサービスの最短継続時間以上であるか否かが判定される。ここで、場デバイス５０Ａは、道路に設置されたものであり、その道路を通行するユーザは、場デバイス５０Ａの周辺に留まらずに通過する可能性が高い。このような傾向が現れたアクセス可能時間にしたがって、センシングデバイスを場デバイス５０Ａへ切り替えるか否かを判断することができる。この例では、アクセス可能時間「３分」＜最短継続時間「１０分」である。このため、センシングデバイスは、ユーザデバイス３０Ａから場デバイス５０Ａへ切り替えられない。
【００６３】
その後、図４に点線の矢印で示すように、１１時０２分の時点では、デバイスＩＤ「ｕｓｅｒ３０Ａ」のユーザデバイス３０Ａが場デバイスデータ１３ａに含まれる場デバイス５０Ａの位置（ｘ１，ｙ１）から１０ｍ以内のエリアから脱出する。これに伴って、ユーザデバイス３０Ａによる場デバイス５０Ａへのアクセスが不可であることが検出部１５ａにより検出される。この段階では、場デバイス５０Ａのアクセス履歴データ１３ｂＡには、ユーザデバイス３０Ａのアクセス履歴のエントリが存在する。このため、ユーザデバイス３０Ａのアクセス履歴のエントリに含まれるアクセス継続期間が更新される。すなわち、現時刻である１１時０２分から開始時刻である１１時００分を差し引くことにより最新のアクセス継続期間「２分」が更新部１５ｂにより算出される。その上で、アクセス履歴データ１３ｂＡに含まれるエントリのうち、ユーザデバイス３０Ａのアクセス履歴のエントリに含まれるアクセス継続期間に当該最新のアクセス継続期間「２分」を上書きする更新が更新部１５ｂにより実行される。
【００６４】
そして、図４に点線の矢印で示すように、１１時１２分の時点では、デバイスＩＤ「ｕｓｅｒ３０Ａ」のユーザデバイス３０Ａが場デバイスデータ１３ａに含まれる場デバイス５０Ｂの位置（ｘ２，ｙ２）から１０ｍ以内のエリアへ進入する。これに伴って、ユーザデバイス３０Ａによる場デバイス５０Ｂへのアクセスが可能であることが検出部１５ａにより検出される。この段階では、場デバイス５０Ｂのアクセス履歴データ１３ｂＢには、ユーザデバイス３０Ａのアクセス履歴のエントリが存在しないので、ユーザデバイス３０Ａのアクセス履歴のエントリが新規に作成される。すなわち、「デバイスＩＤ」のフィールドには、「ｕｓｅｒ３０Ａ」が格納され、「開始時刻」のフィールドには、現時刻である６月７日の１１時１２分が格納されると共に、「アクセス継続期間」のフィールドには、「０：００」が格納された新規エントリがアクセス履歴データ１３ｂＡに作成される。
【００６５】
このように新規エントリが作成された場合、推定部１５ｃによりアクセス可能時間が推定される。すなわち、アクセス履歴データ１３ｂのうち新規エントリが作成された場デバイス５０Ｂに関するアクセス履歴データ１３ｂＢの各エントリが参照される。これらのエントリのうち、新規エントリを除くと、図４に示すアクセス履歴データ１３ｂＢには、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｃ及びデバイスＩＤ「ｕｓｅｒ３０Ｅ」のユーザデバイス３０Ｅに関するアクセス履歴のエントリが含まれる。
【００６６】
これらデバイスＩＤ「ｕｓｅｒ３０Ｃ」及びデバイスＩＤ「ｕｓｅｒ３０Ｅ」のエントリに含まれるアクセス継続時間が読み出される。すなわち、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｂのアクセス継続期間として「３０分」が読みされる。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｅ」のユーザデバイス３０Ｃのアクセス継続期間として「４２分（継続）」が読み出される。これらのアクセス継続期間を平均する計算、すなわち「（３０分＋４２分）／２」を行うことにより、アクセス可能時間を「３６分」と推定できる。
【００６７】
このように推定されたアクセス可能時間に基づいてセンシングデバイスをユーザデバイス３０Ａから場デバイス５０Ｂへ切り替えるか否かが選択部１５ｄにより判定される。ここで、場デバイス５０Ｂは、場デバイス５０Ａとは異なり、店舗に設置されたものであり、店舗内に訪れるユーザは、場デバイス５０Ｂが設置された店舗内に一定の期間にわたって滞在する可能性が高い。例えば、図４に一点鎖線の矢印で示される通り、デバイスＩＤ「Ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｃを携帯するユーザは、場デバイス５０Ａが設置された道路を通過した後に場デバイス５０Ｂが設置された店舗に訪れ、その後、３０分間にわたって店舗に滞在していたことがアクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢからわかる。さらに、図４に二点鎖線の矢印で示される通り、デバイスＩＤ「Ｕｓｅｒ３０Ｅ」のユーザデバイス３０Ｅを携帯するユーザは、場デバイス５０Ｂが設置された店舗に４２分間が経過した現時点でも滞在していることがアクセス履歴データ１３ｂＢからわかる。これらのことから、場デバイス５０Ｂは、場デバイス５０Ａよりもユーザデバイス３０Ａの代わりにセンシングデバイスとして使用できる期間が長くなる可能性が高い。このような傾向が現れたアクセス可能時間にしたがって、センシングデバイスを場デバイス５０Ｂへ切り替えるか否かを判断することができる。この例では、アクセス可能時間「３６分」＞最短継続時間「１０分」である。このため、センシングデバイスは、ユーザデバイス３０Ａから場デバイス５０Ｂへ切り替えられる。
【００６８】
以上のように、本実施例では、ユーザがＩｏＴサービスの最短継続時間以上の期間にわたって留まる可能性が低い環境に設置された場デバイス５０Ａへの切替えを抑制できる。したがって、本実施例によれば、ＩｏＴサービスに利用されるデバイスの切替え頻度を低減し、もってＩｏＴサービスの品質が低下するのを抑制することが可能である。また、本実施例では、ユーザがＩｏＴサービスの最短継続時間以上の期間にわたって留まる可能性が高い環境に設置された場デバイス５０Ｂへの切替えを実施することができる。それ故、ユーザデバイス３０の代わりに場デバイス５０をセンシングデバイスとして動作させ、もってユーザデバイス３０のバッテリ消費を抑えることも可能である。
【００６９】
加えて、本実施例では、場デバイス５０Ａまたは場デバイス５０Ｂへの切替え適否の判定に用いるアクセス可能時間の推定に、場デバイス５０Ａに関するアクセス履歴データ１３ｂＡまたは場デバイス５０Ｂに関するアクセス履歴データ１３ｂＢが用いられる。これらアクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢは、いずれも不特定のユーザデバイス３０のアクセス履歴から作成することができる。すなわち、アクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢは、必ずしも場デバイス５０Ａ及び場デバイス５０Ｂがセンシングデバイスとして選択されずとも、不特定のユーザが場デバイス５０Ａまたは場デバイス５０Ｂにアクセス可能なエリアをユーザデバイス３０を携帯して行動、例えば移動や滞在などを行うことにより作成できる。さらに、アクセス履歴データ１３ｂＡ及びアクセス履歴データ１３ｂＢは、必ずしも同一のＩｏＴサービスに利用されるユーザデバイス３０及び同一のユーザにより使用されるユーザデバイス３０のアクセス履歴から作成されずともかまわない。なぜなら、場デバイス５０が設置された環境にユーザが留まる時間の長さには、ユーザの個人差が現れるとしても、場デバイス５０が設置された環境にユーザが留まるか否かには、ユーザの個人差に依存する割合よりも環境の性質に依存する割合の方が高いからである。
【００７０】
なお、図３及び図４には、場デバイスデータ１３ａ及びアクセス履歴データ１３ｂの各データがテーブル形式で記憶部１３に格納される場合を例示したが、これに限定されない。例えば、各データは、ＸＭＬ（Extensible  Markup  Language）などのマークアップ言語によりタグ形式で記述されるデータであってもよいし、ＣＳＶ（Comma-Separated  Values）などのようにカンマや改行により記述されるデータであってもかまわない。
【００７１】
［処理の流れ］
図５は、実施例１に係るデバイス選択処理の手順を示すフローチャートである。この処理は、一例として、ＩｏＴサービスが実施中であるユーザのアカウントに対応するユーザデバイス３０が存在する限り、一定の周期で繰り返し実行される。
【００７２】
図５に示すように、検出部１５ａは、ＩｏＴサービスが実施中であるユーザのアカウントに関連付けられたユーザデバイス３０のデバイスＩＤのリストを保持する内部メモリのワークエリアから、ユーザデバイス３０のデバイスＩＤを１つ選択する（ステップＳ１０１）。
【００７３】
続いて、検出部１５ａは、ステップＳ１０１で選択されたデバイスＩＤに対応するユーザデバイス３０から位置情報を取得する（ステップＳ１０２）。その上で、検出部１５ａは、記憶部１３に記憶された場デバイスデータ１３ａを参照して、ユーザデバイス３０がアクセス可能な場デバイス５０を検索する（ステップＳ１０３）。
【００７４】
このとき、場デバイス５０がヒットする場合（ステップＳ１０４Ｙｅｓ）、更新部１５ｂは、アクセス履歴データ１３ｂのうちステップＳ１０１で選択されたユーザデバイス３０がアクセス可能である場デバイス５０に関するアクセス履歴の中に、当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みであるか否かを判定する（ステップＳ１０５）。なお、場デバイス５０がヒットしない場合（ステップＳ１０４Ｎｏ）、ステップＳ１０８の処理へ移行する。
【００７５】
そして、当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みである場合（ステップＳ１０５Ｙｅｓ）、更新部１５ｂは、当該ユーザデバイス３０のアクセス履歴のエントリに含まれるアクセス継続期間を更新する（ステップＳ１０６）。
【００７６】
一方、当該ユーザデバイス３０のデバイスＩＤを含むアクセス履歴のエントリが作成済みでない場合（ステップＳ１０５Ｎｏ）、更新部１５ｂは、当該ユーザデバイス３０に関するアクセス履歴のエントリを新規に作成する（ステップＳ１０７）。
【００７７】
その後、ステップＳ１０１で用いるリストの中に未選択のユーザデバイス３０のデバイスＩＤがなくなるまで（ステップＳ１０８Ｎｏ）、ステップＳ１０１からステップＳ１０７までの処理を繰り返し実行する。そして、ステップＳ１０１で用いるリストの中に未選択のユーザデバイス３０のデバイスＩＤがない場合（ステップＳ１０８Ｙｅｓ）、推定部１５ｃは、アクセス履歴データ１３ｂに新規エントリが作成されたか否かを判定する（ステップＳ１０９）。
【００７８】
このとき、アクセス履歴データ１３ｂに新規エントリが作成された場合（ステップＳ１０９Ｙｅｓ）、推定部１５ｃは、新規エントリが作成された場デバイス５０に関するアクセス履歴の各エントリに含まれるアクセス継続期間に所定の統計処理を行うことにより、「アクセス可能時間」を推定する（ステップＳ１１０）。なお、アクセス履歴データ１３ｂに新規エントリが作成されていない場合（ステップＳ１０９Ｎｏ）、そのまま処理を終了する。
【００７９】
続いて、選択部１５ｄは、ステップＳ１１０で推定されたアクセス可能時間が最短継続時間以上であるか否か、すなわちアクセス可能時間≧最短継続時間であるか否かを判定する（ステップＳ１１１）。
【００８０】
ここで、アクセス可能時間≧最短継続時間である場合（ステップＳ１１１Ｙｅｓ）、最短継続時間以上の期間にわたってユーザデバイス３０の代わりに当該場デバイス５０をセンシングデバイスとして使用できることが期待できる。言い換えれば、センシングデバイスをユーザデバイス３０から場デバイス５０へ切り替えた後、最短継続時間未満でセンシングデバイスを場デバイス５０からユーザデバイス３０へ切り替える再切替えを抑制できる可能性が高いと推定できる。この場合、選択部１５ｄは、場デバイス５０をセンシングデバイスとして選択し（ステップＳ１１２）、処理を終了する。
【００８１】
一方、アクセス可能時間≧最短継続時間でない場合（ステップＳ１１１Ｎｏ）、センシングデバイスをユーザデバイス３０から場デバイス５０へ切り替えた後、最短継続時間未満でセンシングデバイスを場デバイス５０からユーザデバイス３０へ切り替える再切替えを抑制できない可能性が高いと推定できる。この場合、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択し（ステップＳ１１３）、処理を終了する。
【００８２】
［効果の一側面］
上述してきたように、本実施例に係るサーバ装置１０は、環境に設置された場デバイス５０へのアクセスが可能から不可になる期間の履歴から推定したユーザデバイス３０のアクセス可能時間に基づいてＩｏＴサービスに用いるメディアデータのセンシングを場デバイス５０に切り替えるか否かを制御する。それ故、ユーザの居場所が一定しない可能性が高い場合、場デバイス５０への切替えを抑制できる。したがって、本実施例に係るサーバ装置１０によれば、ＩｏＴサービスに利用されるデバイスの切替え頻度を低減できる。このようにＩｏＴサービスに利用されるデバイスの切替え頻度が低減される結果、ＩｏＴサービスの品質が低下するのも抑制できる。さらに、ユーザが一定の場所に留まる可能性が高い場合、場デバイス５０へ切り替えることができる。このため、ユーザデバイス３０のバッテリ消費も抑えることができる。
【実施例２】
【００８３】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８４】
［アクセス可能時間の推定］
上記の実施例１では、新規エントリが作成された場デバイス５０に関するアクセス履歴の各エントリに含まれるアクセス継続期間を平均することによりアクセス可能時間を推定する場合を例示したが、アクセス可能時間の推定方法はこれに限定されない。例えば、各エントリに含まれるアクセス継続期間のうち、最悪値、すなわち場デバイス５０をこの先使用できる時間の最小値をアクセス可能時間として推定することもできる。これにより、アクセス可能時間の推定に誤りが生じた場合であっても、最短継続時間未満でセンシングデバイスを場デバイス５０からユーザデバイス３０へ切り替える再切替えを抑制できる。
【００８５】
例えば、図３に示す場デバイス５０Ａのアクセス可能時間を推定する場合、デバイスＩＤ「ｕｓｅｒ３０Ｂ」のユーザデバイス３０Ｂのアクセス継続期間として「２分」が読みされる。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｃのアクセス継続期間として「２分」が読み出される。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｄ」のユーザデバイス３０Ｄのアクセス継続期間として「５分」が読み出される。この場合、２分、２分および５分のうち最小値である２分がアクセス可能時間として推定される。また、図４に示す場デバイス５０Ｂのアクセス可能時間を推定する場合、デバイスＩＤ「ｕｓｅｒ３０Ｃ」のユーザデバイス３０Ｂのアクセス継続期間として「３０分」が読みされる。さらに、デバイスＩＤ「ｕｓｅｒ３０Ｅ」のユーザデバイス３０Ｃのアクセス継続期間として「４２分（継続）」が読み出される。この場合、３０分および４２分のうち最小値である３０分がアクセス可能時間として推定される。
【００８６】
［アクセス可能時間の推定２］
この他、推定部１５ｃは、場デバイス５０が設置される環境に対するユーザの滞在パターンが複数存在する場合に備えて、複数のアクセス可能時間を算出して場デバイス５０への切替えを制御することもできる。例えば、第１のアクセス可能時間とＩｏＴサービスの最短継続時間との比較により場デバイス５０への切替えを制御し、場デバイス５０への切替えが行われなかった場合、場デバイス５０へのアクセス可能な状態が継続する時間が第１のアクセス可能時間を越えると、第２のアクセス可能時間とＩｏＴサービスの最短継続時間との比較により場デバイス５０への切替えをさらに制御することもできる。
【００８７】
図６は、デバイス選択処理の応用例の手順を示すフローチャートである。図６に示すフローチャートには、図５に示すフローチャートからの変更部分が示されている。図５に示すステップＳ１０９以降の処理は、図６に示すステップＳ２０１〜ステップＳ２１１の処理に差し替えることができる。
【００８８】
図６に示すように、アクセス履歴データ１３ｂに新規エントリが作成された場合（ステップＳ１０９Ｙｅｓ）、推定部１５ｃは、新規エントリが作成された場デバイス５０に関するアクセス履歴の各エントリに含まれるアクセス継続期間にクラスタリングを実行する（ステップＳ２０１）。
【００８９】
そして、推定部１５ｃは、ステップＳ２０１のクラスタリングにより得られたクラスタのうちクラスタに含まれる要素の数が上位２つのクラスタを選択する（ステップＳ２０２）。その上で、推定部１５ｃは、ステップＳ２０２で選択された２つのクラスタごとに、当該クラスタに含まれるアクセス継続期間を平均することにより、２つのアクセス可能時間を推定する（ステップＳ２０３）。このように推定された２つのアクセス可能時間のうち短い方が第１のアクセス可能時間と識別される一方で、長い方が第２のアクセス可能時間と識別される。
【００９０】
続いて、選択部１５ｄは、ステップＳ２０３で推定された第１のアクセス可能時間が最短継続時間以上であるか否か、すなわち第１のアクセス可能時間≧最短継続時間であるか否かを判定する（ステップＳ２０４）。
【００９１】
このとき、第１のアクセス可能時間≧最短継続時間である場合（ステップＳ２０４Ｙｅｓ）、選択部１５ｄは、場デバイス５０をセンシングデバイスとして選択し（ステップＳ２０５）、処理を終了する。
【００９２】
一方、第１のアクセス可能時間≧最短継続時間でない場合（ステップＳ２０４Ｎｏ）、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択し（ステップＳ２０６）、第２のアクセス可能時間を用いる判定を予約するのに用いる再判断フラグを「ＴＲＵＥ」に設定し（ステップＳ２０７）、処理を終了する。
【００９３】
また、アクセス履歴データ１３ｂに新規エントリが作成されていない場合（ステップＳ１０９Ｎｏ）、選択部１５ｄは、再判断フラグにＴＲＵＥが設定されているか否か、すなわち再判断フラグ＝ＴＲＵＥであるか否かを判定する（ステップＳ２０８）。
【００９４】
このとき、再判断フラグ＝ＴＲＵＥである場合（ステップＳ２０８Ｙｅｓ）、選択部１５ｄは、再判断フラグがＴＲＵＥに設定されたユーザデバイス３０が場デバイス５０にアクセス可能となってから経過する経過時間が第１のアクセス可能時間以上であるか否か、経過時間≧第１のアクセス可能時間であるか否かを判定する（ステップＳ２０９）。
【００９５】
そして、経過時間≧第１のアクセス可能時間である場合、選択部１５ｄは、再判断フラグをＦＡＬＳＥに設定した上で、ステップＳ２０３で推定された第２のアクセス可能時間が最短継続時間以上であるか否か、すなわち第２のアクセス可能時間≧最短継続時間であるか否かを判定する（ステップＳ２１０及び２１１）。
【００９６】
ここで、第２のアクセス可能時間≧最短継続時間である場合（ステップＳ２１１Ｙｅｓ）、選択部１５ｄは、場デバイス５０をセンシングデバイスとして選択し（ステップＳ２０５）、処理を終了する。なお、第２のアクセス可能時間≧最短継続時間でない場合（ステップＳ２１１Ｎｏ）、場デバイス５０への切替えは実施せずにそのまま処理を終了する。
【００９７】
以上のような処理により、場デバイス５０が設置される環境に対するユーザの滞在パターンが複数に分岐する場合でも、分岐先の滞在パターンに合わせて複数のアクセス可能時間を推定して場デバイス５０への切替えを制御できる。例えば、図４の例で言えば、デバイス５０Ｂが設置された店舗では、店舗の前を通過するパターンと、店舗に入店して滞在するパターンとに二分される場合がある。この場合、前者のパターンに対応するクラスタから推定される第１のアクセス可能時間と最短継続時間との比較により場デバイス５０Ｂへの切替えが行われずとも、経過時間が第１のアクセス可能時間を経過後に後者のパターンに対応するクラスタから推定される第２のアクセス時間と最短継続時間との比較によりセンシングデバイスを場デバイス５０Ｂへ切り替えることができる。したがって、店舗周辺を通行するユーザが素通りする場合には、センシングデバイスをユーザデバイス３０のままに制御し、店舗周辺を通行するユーザが入店して滞在する場合には、センシングデバイスを場デバイス５０Ｂへ切り替えることができる。よって、再切替えの発生頻度をより効果的に低減できる。
【００９８】
［アクセス可能時間の推定３］
上記の実施例１では、異なる種類のＩｏＴサービスに関するエントリや異なるユーザデバイス３０に関するエントリもアクセス可能時間を推定する場合に用いる例を説明したが、ＩｏＴサービスの種類が同一であるエントリだけを抽出してアクセス可能時間を推定することもできるし、同一のユーザデバイス３０に関するエントリだけを抽出してアクセス可能時間を推定することもできるし、ＩｏＴサービスの種類が同一であり、かつ同一のユーザデバイス３０であるエントリを抽出してアクセス可能時間を推定することもできる。
【００９９】
［バッテリ残量］
上記の実施例１では、アクセス可能時間が最短継続時間以上でない場合、ユーザデバイス３０をセンシングデバイスとして選択する場合を例示したが、条件付きで場デバイス５０をセンシングデバイスとして選択することもできる。例えば、ユーザデバイス３０から取得されるバッテリ残量が所定の閾値、例えば２０％以下である場合、アクセス可能時間が最短継続時間以上でなくとも、場デバイス５０をセンシングデバイスとして選択することもできる。すなわち、図５に示すフローチャートの例で言えば、ステップＳ１０９Ｙｅｓの分岐へ進んだ後、ユーザデバイス３０からバッテリ残量を取得する処理と、バッテリ残量が所定の閾値以下であるか否かを判定する処理とを挿入する。そして、バッテリ残量が所定の閾値以下である場合、ステップＳ１１３の処理、すなわちユーザデバイス３０をセンシングデバイスとして選択する処理へ移行し、バッテリ残量が所定の閾値以下でない場合、ステップＳ１１０の処理へ移行することとすればよい。
【０１００】
［最短継続時間］
上記の実施例１では、ＩｏＴシステム１のユーザ、管理者や設計者等の関係者の指示入力により最短継続時間が設定される場合を例示したが、これに限定されず、メディア出力の頻度やタイミングから、ＩｏＴサービスの残り継続時間を推定することもできる。すなわち、上記の実施例１では、ＩｏＴサービスの一例として、ライフログを例示したが、ユーザデバイス３０に保存された音声コンテンツや映像コンテンツなどのコンテンツを外部の再生装置に送信し、外部の再生装置によりコンテンツを再生させることにより、外部の再生装置をジュークボックスのように扱うコンテンツ再生サービス等が利用される場合もある。このような場合、映像コンテンツまたは音声コンテンツの出力がメディアプレイヤ等により開始されてから終了するまでのメディア出力時間をユーザデバイス３０に計測させた上でメディア出力履歴データとして保存させる。その上で、一定周期、定期時刻、あるいは新規エントリの作成などのタイミングでメディア出力履歴データをサーバ装置１０にアップロードさせる。これにより、サーバ装置１０では、ユーザデバイス３０のデバイスＩＤごとにメディア出力履歴データを記憶部１３で管理することができる。例えば、ＩｏＴサービスとして、上記のコンテンツ再生サービスが実施される場合、当該サービスを利用するユーザデバイス３０のデバイスＩＤに対応するメディア出力履歴データからメディア出力時間を読み出し、メディア出力時間の統計値、例えば平均値を算出することにより、コンテンツ再生サービスの残り継続時間を算出することができる。この残り継続時間と、アクセス可能時間との比較により、場デバイス５０への切替え制御を実現できる。
【０１０１】
［デバイス選択の実行主体］
上記の実施例１では、図２に示す制御部１５により検出部１５ａ、更新部１５ｂ、推定部１５ｃ及び選択部１５ｄが実現される場合、すなわちデバイス選択処理の実行主体がサーバ装置１０である場合を例示したが、必ずしもサーバ装置１０がデバイス選択処理の実行主体でなくともかまわない。すなわち、場デバイス５０が有するプロセッサがＲＡＭ上にデバイス選択プログラムを展開することにより、検出部１５ａ、更新部１５ｂ、推定部１５ｃ及び選択部１５ｄを仮想的に実現することとしてもよい。この場合、１つの場デバイス５０が代表して他の場デバイス５０を含む全ての場デバイス５０を選択肢とする切替えを制御する場合、サーバ装置１０と同様の処理を実行することとすればよいし、場デバイス５０ごとに当該場デバイス５０及びユーザデバイス３０の中からセンシングデバイスを選択する場合、他の場デバイス５０の位置情報は必ずしも有さずともかまず、ＩｏＴサービスを実施中であるユーザデバイス３０のデバイスＩＤだけが識別できていればよい。
【０１０２】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、検出部１５ａ、更新部１５ｂ、推定部１５ｃまたは選択部１５ｄをサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、検出部１５ａ、更新部１５ｂ、推定部１５ｃまたは選択部１５ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもよい。また、記憶部に記憶される場デバイスデータ１３ａまたはアクセス履歴データ１３ｂの全部または一部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもかまわない。
【０１０３】
［通信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図７を用いて、上記の実施例と同様の機能を有する通信プログラムを実行するコンピュータの一例について説明する。
【０１０４】
図７は、実施例１及び実施例２に係る通信プログラムを実行するコンピュータのハードウェア構成例を示す図である。図７に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１０５】
ＨＤＤ１７０には、図７に示すように、上記の実施例１で示した検出部１５ａ、更新部１５ｂ、推定部１５ｃ及び選択部１５ｄと同様の機能を発揮する通信プログラム１７０ａが記憶される。この通信プログラム１７０ａは、図２に示した検出部１５ａ、更新部１５ｂ、推定部１５ｃ及び選択部１５ｄの各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。
【０１０６】
このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から通信プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、通信プログラム１７０ａは、図７に示すように、通信プロセス１８０ａとして機能する。この通信プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち通信プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、通信プロセス１８０ａが実行する処理の一例として、図５や図６に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。
【０１０７】
なお、上記の通信プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に通信プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から通信プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに通信プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから通信プログラム１７０ａを取得して実行するようにしてもよい。
【符号の説明】
【０１０８】
１    ＩｏＴシステム
１０    サーバ装置
１１    通信Ｉ／Ｆ部
１３    記憶部
１３ａ  場デバイスデータ
１３ｂ  アクセス履歴データ
１５    制御部
１５ａ  検出部
１５ｂ  更新部
１５ｃ  推定部
１５ｄ  選択部
３０    ユーザデバイス
５０Ａ，５０Ｂ，５０Ｃ    場デバイス
【図１】
2018129721.tif 000003
【図２】
2018129721.tif 000004
【図３】
2018129721.tif 000005
【図４】
2018129721.tif 000006
【図５】
2018129721.tif 000007
【図６】
2018129721.tif 000008
【図７】
2018129721.tif 000009