JP6673096B2 - デバイス選択方法、デバイス選択プログラム及びデバイス選択装置 - Google Patents

Description

本発明は、デバイス選択方法、デバイス選択プログラム及びデバイス選択装置に関する。

スマートフォン、タブレット端末、ウェアラブルコンピュータ等のデバイスの多様化に伴って様々なＩｏＴ（Internet of Things）サービスが実現されている。このようなＩｏＴ（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）、サービスエリア、開始時刻および継続時間などの項目を含むデータを採用できる。ここで言う「サービスＩＤ」とは、ＩｏＴサービスを識別する情報を指す。また、「サービスエリア」とは、ＩｏＴサービスが実施される領域を指し、一例として、代行デバイス５０が存在する位置を基準に定義することができる。例を挙げれば、代行デバイス５０の位置を中心とし、中心から所定の距離、例えば１０ｍ以内の領域をサービスエリアとして定義したり、これを重心として定める多角形状の領域をサービスエリアとして定義したりすることができる。また、「開始時刻」とは、ＩｏＴサービスが開始された時刻を指す。また、「継続時間」とは、ＩｏＴサービスが開始されてから終了されるまでの期間を指し、ここで言う継続時間は履歴であるので実測値が保存される。

図３は、サービス利用履歴データ１３ａの一例を示す図である。図３には、一例として、３件の履歴に関するエントリが抜粋して示されている。図３に示すエントリのうち上から１番目のエントリと上から３番目のエントリは、いずれもサービスＩＤ「０００１」で識別されるＩｏＴサービスに関する履歴である一方で、上から２番目のエントリは、サービスＩＤ「０００２」で識別されるＩｏＴサービスに関する履歴である。例えば、上から１番目のエントリによれば、サービスＩＤ「０００１」で識別されるＩｏＴサービスがサービスエリア「Ｅ２」で１２月１１日の９時から２時間３０分間にわたって実施されたことを意味する。これに対し、上から３番目のエントリによれば、サービスＩＤ「０００１」で識別されるＩｏＴサービスがサービスエリア「Ｅ２」で１２月１３日の９時３０分から２時間にわたって実施されたことを意味する。

バッテリデータ１３ｂは、バッテリに関するデータである。

一実施形態として、バッテリデータ１３ｂには、デバイスＩＤ、残量、時刻およびタイミングなどの項目を含むデータを採用できる。ここで言う「デバイスＩＤ」とは、ＩｏＴデバイスを識別する情報を指し、バッテリにより駆動するユーザデバイス３０の識別情報が保存される。このデバイスＩＤには、任意の体系の識別子を採用できる。例えば、ＩｏＴシステム１によって採番されるＩＤを用いることもできれば、各ＩｏＴデバイスが持つ個体の識別番号、例えば製造番号などをデバイスＩＤとして用いることもできる。また、「残量」とは、ＩｏＴデバイスのバッテリ残量を指す。また、「時刻」とは、バッテリ残量が測定された時刻を指す。また、「タイミング」とは、バッテリ残量が測定された時機を指し、例えば、ＩｏＴサービスの「開始」または「終了」に分類される。

図４は、バッテリデータ１３ｂの一例を示す図である。図４には、上述の通り、デバイスＩＤ、残量、時刻およびタイミングなどの項目が含まれるが、この段階ではエントリが存在しない状態が例示されている。

デバイスデータ１３ｃは、ＩｏＴデバイスに関するデータである。

一実施形態として、デバイスデータ１３ｃには、デバイスＩＤ、種別、サービスエリア及び特性などの項目を含むデータを採用できる。ここで言う「種別」とは、ＩｏＴデバイスの分類を指し、一例として、ＩｏＴデバイスがユーザデバイス３０または代行デバイス５０のいずれかに該当するのかが保存される。例えば、ＩｏＴデバイスがユーザデバイス３０である場合、種別のフィールドには「人」が登録される一方で、ＩｏＴデバイスが代行デバイス５０である場合、種別のフィールドには「場」が登録される。また、「特性」とは、ＩｏＴデバイスの特性を指し、一例として、ＩｏＴデバイスによりセンシングされるメディアデータの品質のレベルが保存される。

図５は、デバイスデータ１３ｃの一例を示す図である。図５には、説明の便宜上、３つのＩｏＴデバイスに関するエントリが抜粋して例示されているが、実装時には、上記のデバイス選択サービスに加入するユーザに所有権または使用権があるユーザデバイス３０、及び、各サービスエリアに存在する代行デバイス５０に関するエントリが登録される。図５に示すエントリのうち上から１番目のエントリは、デバイスＩＤ「user30」で識別されるＩｏＴデバイスがユーザデバイス３０であり、このユーザデバイス３０が高品質のメディアデータをセンシングできることを意味する。また、上から２番目のエントリは、デバイスＩＤ「agent50A」で識別されるＩｏＴデバイスがサービスエリア「Ｅ１」にある代行デバイス５０Ａであり、この代行デバイス５０Ａが高品質のメディアデータをセンシングできることを意味する。さらに、上から３番目のエントリは、デバイスＩＤ「agent50B」で識別されるＩｏＴデバイスがサービスエリア「Ｅ２」にある代行デバイス５０Ｂであり、この代行デバイス５０Ｂでは低品質のメディアデータしかセンシングできないことを意味する。

なお、図５には、上から１番目のエントリ、すなわちユーザデバイス３０のエントリに含まれるサービスエリアのフィールドをブランクとする場合を例示したが、ユーザデバイス３０から収集される位置情報を現在地として登録することもできる。また、デバイスデータ１３ｃには、ＩｏＴデバイスが有するセンシング能力を識別できる情報がさらに含まれることとしてもかまわない。すなわち、ＩｏＴサービスの中には、映像を使用するもの、音声を使用するもの、さらには、映像＋音声を使用するものも存在する。このため、ユーザデバイス３０からリクエストを受け付けたＩｏＴサービスに用いられるメディアデータの条件、すなわち映像、音声または映像＋音声といった条件を満たすＩｏＴデバイスをサーバ装置１０が識別するために、ＩｏＴデバイスが有するセンシング能力を識別できる情報をデバイスデータ１３ｃに含めることもできる。

デバイス使用履歴データ１３ｄは、ＩｏＴデバイスが使用された履歴に関するデータである。

一実施形態として、デバイス使用履歴データ１３ｄには、サービスＩＤ、デバイスＩＤ、開始時刻および消費率などの項目を含むデータを採用できる。ここで言う「開始時刻」とは、ＩｏＴサービスに用いるメディアデータのセンシングが開始される時刻を指す。また、「消費率」とは、ＩｏＴデバイスのバッテリ消費率を指し、外部電源に接続されないユーザデバイス３０を対象としてその値が保存される。

図６は、デバイス使用履歴データ１３ｄの一例を示す図である。図６には、一例として、図３に示した３件のＩｏＴサービスで用いられたＩｏＴデバイスの履歴に対応する。図６に示すエントリのうち上から１番目のエントリは、サービスＩＤ「０００１」で識別されるＩｏＴサービスがデバイスＩＤ「agent50B」で識別されるＩｏＴデバイスにより１２月１３日の９時３０分に開始されたことを意味する。このエントリでは、消費率のフィールドがブランクとされている。これは、デバイスＩＤ「agent50B」で識別されるＩｏＴデバイスが代行デバイス５０であることを意味する。また、上から２番目のエントリは、サービスＩＤ「０００２」で識別されるＩｏＴサービスがデバイスＩＤ「agent50A」で識別されるＩｏＴデバイスにより１２月１２日の１０時に開始されたことを意味する。このエントリでも、消費率のフィールドがブランクとされているので、デバイスＩＤ「agent50A」で識別されるＩｏＴデバイスも代行デバイス５０であることを意味する。さらに、上から３番目のエントリは、サービスＩＤ「０００１」で識別されるＩｏＴサービスがデバイスＩＤ「user30」で識別されるＩｏＴデバイスにより１２月１１日の９時に開始されたことを意味する。このエントリでは、消費率のフィールドに２０％／ｈの値が格納されている。これは、デバイスＩＤ「user30」で識別されるＩｏＴデバイスがユーザデバイス３０であり、サービスＩＤ「０００１」で識別されるＩｏＴサービスに使用したことで、１時間あたり２０％のバッテリを消費したことを意味する。

なお、図３〜図６には、サービス利用履歴データ１３ａ、バッテリデータ１３ｂ、デバイスデータ１３ｃ及びデバイス使用履歴データ１３ｄの各データがテーブル形式で記憶部１３に格納される場合を例示したが、これに限定されない。例えば、各データは、ＸＭＬ（Extensible Markup Language）などのマークアップ言語によりタグ形式で記述されるデータであってもよいし、ＣＳＶ（Comma-Separated Values）などのようにカンマや改行により記述されるデータであってもかまわない。

制御部１５は、各種のプログラムや制御データを格納する内部メモリを有し、これらによって各種の処理を実行するものである。

一実施形態として、制御部１５は、中央処理装置、いわゆるＣＰＵ（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）が測定する緯度および経度を取得することができる。この他、第１の取得部１５ａは、ユーザデバイス３０からユーザデバイス３０が収容されるセルの基地局、例えばアクセスポイントなどの位置情報を取得することもできる。このアクセスポイントの位置情報は、そのままユーザデバイス３０の位置情報として用いることもできるし、ユーザデバイス３０の受信電波強度等から割り出されるユーザデバイス３０及びアクセスポイント間の距離を用いてユーザデバイス３０の位置情報を求めることもできる。

続いて、第１の取得部１５ａは、記憶部１３に記憶されたデバイスデータ１３ｃに含まれる代行デバイス５０のサービスエリアのうち、ユーザデバイス３０の位置情報が含まれるサービスエリアを識別する。例えば、第１の取得部１５ａは、代行デバイス５０のサービスエリアごとに当該サービスエリアとして定義された領域にユーザデバイス３０の位置情報が含まれるか否かを判定する。この結果、ユーザデバイス３０の位置情報が含まれるサービスエリアが存在する場合、当該サービスエリアに対応付けられた代行デバイス５０がセンシングデバイスの選択肢として抽出される。なお、ユーザデバイス３０の位置情報が含まれるサービスエリアが存在しない場合、ユーザデバイス３０の代わりにメディアデータのセンシングを実施できる代行デバイス５０がユーザデバイス３０の周辺に存在しないことが判明する。この場合、後述の選択部１５ｄによりユーザデバイス３０がメディアデータのセンシングを実施するセンシングデバイスとして選択される。

そして、第１の取得部１５ａは、記憶部１３に記憶されたサービス利用履歴データ１３ａに新規のエントリを作成した上で、当該エントリにサービスＩＤ、サービスエリア及び開始時刻を対応付けて登録する。例えば、第１の取得部１５ａは、サービスＩＤのフィールドには、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤを登録し、サービスエリアのフィールドには、ユーザデバイス３０の位置情報が含まれるサービスエリアを登録し、開始時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻を開始時刻として登録する。

その後、第１の取得部１５ａは、ユーザデバイス３０からバッテリ残量を取得する。例えば、第１の取得部１５ａは、ユーザデバイス３０上で動作するＯＳまたはバッテリドライバにより提供されるＡＰＩ（Application Programming Interface）にしたがってバッテリ残量を取得することができる。その上で、第１の取得部１５ａは、記憶部１３に記憶されたバッテリデータ１３ｂに新規のエントリを作成した上で、当該エントリにデバイスＩＤ、残量、時刻及びタイミングを対応付けて登録する。例えば、第１の取得部１５ａは、デバイスＩＤのフィールドには、ＩｏＴサービスの開始要求を行うユーザデバイス３０のデバイスＩＤを登録し、残量のフィールドには、ユーザデバイス３０から取得されたバッテリ残量を登録し、時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻を開始時刻として登録し、タイミングのフィールドには、ＩｏＴサービスの開始要求が受け付けられた局面であるので開始を登録する。

第１の推定部１５ｂは、ＩｏＴサービスの継続時間を推定する処理部である。以下では、ＩｏＴサービスの継続時間のことを「サービス継続時間」と記載する場合がある。

一実施形態として、第１の推定部１５ｂは、記憶部１３に記憶されたサービス利用履歴データ１３ａのエントリのうち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤと一致し、かつユーザデバイス３０の位置情報が含まれるサービスエリアと一致するエントリを抽出する。このとき、サービス利用履歴データ１３ａから複数のエントリが抽出された場合、第１の推定部１５ｂは、各エントリに含まれる継続時間に所定の統計処理を行うことにより、継続時間の代表値を算出する。例えば、第１の推定部１５ｂは、各エントリに含まれる継続時間を平均することにより、継続時間の推定値を算出する。この結果として算出された継続時間の推定値がサービス継続時間として以降の処理で用いられる。このようにサービスＩＤ及びサービスエリアが共通するエントリを抽出するのは、開始が要求されたＩｏＴサービスと同一のＩｏＴサービスが同一のサービスエリアで実施された履歴をサービス継続時間の推定に用いるためであり、これによって、今回のＩｏＴサービスが実施される場合にも履歴の継続時間と同等の継続時間が再現される可能性を期待できるからである。

なお、ここでは、一例として、サービスＩＤ及びサービスエリアの一致を条件にしてエントリを抽出する場合を例示したが、エントリの抽出条件は必ずしもＡＮＤ条件でなくともよく、ＯＲ条件とすることもできる。例えば、サービスＩＤが一致するエントリを抽出することとしてもよいし、サービスエリアが一致するエントリを抽出することとしてもよいし、サービスＩＤ及びサービスエリアのうち少なくとも１つが一致するエントリを抽出することとしてもかまわない。この他、上記のエントリの抽出条件に更なる条件を加重することもできる。例えば、サービスＩＤとサービスエリアが共通しても、ユーザによってサービス継続時間に個人差が生じることもある。このことから、サービス利用履歴データ１３ａのフィールドにユーザの識別情報、例えばユーザＩＤを追加し、ユーザＩＤがさらに共通するエントリを抽出することとしてもよい。また、ユーザにより使用されるＩｏＴデバイスによってサービス継続時間に差が生じることもある。このことから、サービス利用履歴データ１３ａのエントリにＩｏＴサービスに使用されたＩｏＴデバイスの識別情報、すなわちデバイスＩＤを追加し、デバイスＩＤがさらに共通するエントリを抽出することとしてもかまわない。

第２の推定部１５ｃは、ＩｏＴデバイスのバッテリ持続時間を推定する処理部である。

一実施形態として、第２の推定部１５ｃは、記憶部１３に記憶されたデバイス使用履歴データ１３ｄのエントリのうち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤと一致し、かつＩｏＴサービスの開始を要求するユーザデバイス３０が持つデバイスＩＤと一致するエントリを抽出する。このとき、サービスＩＤ及びデバイスＩＤが一致するエントリの抽出に成功した場合、第２の推定部１５ｃは、下記の分岐ａの通り、バッテリ持続時間の推定を行う。また、サービスＩＤ及びデバイスＩＤが一致するエントリの抽出に失敗した場合、開始要求が行われたＩｏＴサービスが開始要求元のユーザデバイス３０を用いて実施された履歴がないことが判明する。この場合、第２の推定部１５ｃは、エントリの抽出条件を緩め、デバイス使用履歴データ１３ｄのエントリのうちＩｏＴサービスの開始を要求するユーザデバイス３０が持つデバイスＩＤと一致するエントリを抽出する。そして、デバイスＩＤが一致するエントリの抽出に成功した場合、第２の推定部１５ｃは、下記の分岐ｂの通り、バッテリ持続時間の推定を行う。一方、デバイスＩＤが一致するエントリの抽出に失敗した場合、開始要求元のユーザデバイス３０を用いてＩｏＴサービスが実施された履歴がないことが判明する。この場合、第２の推定部１５ｃは、下記の分岐ｃの通り、バッテリ持続時間の推定を行う。

（イ）分岐ａ
第２の推定部１５ｃは、サービスＩＤ及びデバイスＩＤが一致するエントリが複数であるか否かを判定する。このとき、サービスＩＤ及びデバイスＩＤが一致するエントリが複数である場合、第２の推定部１５ｃは、各エントリに含まれるバッテリ消費率に所定の統計処理を行うことにより、バッテリ消費率の代表値を算出する。例えば、第２の推定部１５ｃは、各エントリに含まれるバッテリ消費率を平均する計算を行うことにより、バッテリ消費率の平均値を算出する。一方、サービスＩＤ及びデバイスＩＤが一致するエントリが１つである場合、当該エントリのバッテリ消費率がそのまま代表値として用いられる。このようにして算出されたバッテリ消費率の代表値を用いて、第２の推定部１５ｃは、ＩｏＴサービスの開始を要求するユーザデバイス３０のバッテリ持続時間を推定する。例えば、第２の推定部１５ｃは、当該ユーザデバイス３０のバッテリ残量をバッテリ消費率の平均値で除算する計算を行うことにより、バッテリ持続時間の推定値を算出する。このようにサービスＩＤ及びデバイスＩＤが共通するエントリを抽出するのは、開始が要求されたＩｏＴサービスと同一のＩｏＴサービスで同一のＩｏＴデバイスが用いられた履歴のバッテリ消費率をバッテリ持続時間の推定に用いるためであり、これによって、今回のＩｏＴサービスが実施される場合にも履歴のバッテリ消費率と同等のバッテリ消費率が再現される可能性を期待できるからである。

（ロ）分岐ｂ
第２の推定部１５ｃは、デバイスＩＤが一致するエントリが複数であるか否かを判定する。このとき、デバイスＩＤが一致するエントリが複数である場合、第２の推定部１５ｃは、各エントリに含まれるバッテリ消費率に所定の統計処理を行うことにより、バッテリ消費率の代表値を算出する。例えば、第２の推定部１５ｃは、各エントリに含まれるバッテリ消費率を平均する計算を行うことにより、バッテリ消費率の平均値を算出する。一方、デバイスＩＤが一致するエントリが１つである場合、当該エントリのバッテリ消費率がそのまま代表値として用いられる。このようにして算出されたバッテリ消費率の代表値を用いて、第２の推定部１５ｃは、ＩｏＴサービスの開始を要求するユーザデバイス３０のバッテリ持続時間を推定する。例えば、第２の推定部１５ｃは、当該ユーザデバイス３０のバッテリ残量をバッテリ消費率の平均値で除算する計算を行うことにより、バッテリ持続時間の推定値を算出する。このようにデバイスＩＤが共通するエントリを抽出するのは、開始が要求されたＩｏＴサービスとは異なるＩｏＴサービスの履歴であっても同一のＩｏＴデバイスが用いられた履歴をバッテリ持続時間の推定に用いることで、今回のＩｏＴサービスが実施される場合にも一定の再現性を期待できるからである。

（ハ）分岐ｃ
第２の推定部１５ｃは、予め定められたバッテリ消費率の設定値を用いて、ＩｏＴサービスの開始を要求するユーザデバイス３０のバッテリ持続時間を推定する。例えば、ユーザデバイス３０の製品名ごとに当該製品のカタログスペックとして公表されたバッテリ消費率が対応付けられたカタログデータを参照して、第２の推定部１５ｃは、ＩｏＴサービスの開始を要求するユーザデバイス３０に対応するバッテリ消費率の設定値を呼び出すことができる。

なお、ここでは、一例として、サービスＩＤ及びデバイスＩＤの一致を条件にしてエントリを抽出する場合を例示したが、エントリの抽出条件は必ずしもＡＮＤ条件でなくともよく、ＯＲ条件とすることもできる。例えば、サービスＩＤが一致するエントリを抽出することとしてもよいし、デバイスＩＤが一致するエントリを抽出することとしてもよいし、サービスＩＤ及びデバイスＩＤのうち少なくとも１つが一致するエントリを抽出することとしてもかまわない。この他、上記のエントリの抽出条件に更なる条件を加重することもできる。例えば、特定の場所において、無線ネットワークの電波が弱く、通信を用いるサービス利用にかかる消費電力が大きくなるなど、デバイスＩＤとサービスＩＤが共通しても、場所によってバッテリ消費率が異なる場合がある。このことから、デバイス使用履歴データ１３ｄのエントリにサービスエリアのフィールドを追加し、サービスエリアがさらに共通するエントリを抽出することとしてもかまわない。また、デバイスを使用するユーザの使い方によってバッテリ消費率が異なる場合がある。このことから、デバイス使用履歴データ１３ｄのエントリにユーザＩＤのフィールドを追加し、ユーザＩＤがさらに共通するエントリを抽出することとしてもかまわない。

選択部１５ｄは、ユーザデバイス３０及び代行デバイス５０のうちいずれかのデバイスをセンシングデバイスとして選択する処理部である。

一実施形態として、選択部１５ｄは、第２の推定部１５ｃにより推定されたバッテリ持続時間と、第１の推定部１５ｂにより推定されたサービス継続時間との大小関係を比較する。すなわち、選択部１５ｄは、バッテリ持続時間がサービス継続時間よりも長いか否か、すなわちバッテリ持続時間＞サービス継続時間であるか否かを判定する。ここで、バッテリ持続時間がサービス継続時間よりも長い場合、すなわちバッテリ持続時間＞サービス継続時間である場合、ユーザデバイス３０にメディアデータをセンシングさせたとしてもバッテリ切れによりＩｏＴサービスが中断される可能性が低いと判断できる。この場合、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択する。一方、バッテリ持続時間がサービス継続時間よりも長くない場合、すなわちバッテリ持続時間≦サービス継続時間である場合、バッテリ切れによりＩｏＴサービスが中断される可能性が高いと判断できる。この場合、選択部１５ｄは、ユーザデバイス３０の位置情報が含まれるサービスエリアに対応付けられた代行デバイス５０をセンシングデバイスとして選択する。

このようにセンシングデバイスが選択された後、選択部１５ｄは、記憶部１３に記憶されたデバイス使用履歴データ１３ｄに新規のエントリを作成した上で、当該エントリにサービスＩＤ、デバイスＩＤおよび開始時刻を対応付けて登録する。例えば、選択部１５ｄは、サービスＩＤのフィールドには、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤを登録し、デバイスＩＤのフィールドには、センシングデバイスとして選択されたＩｏＴデバイスが持つデバイスＩＤを登録し、開始時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻を開始時刻として登録する。この段階では、一時間断面のバッテリ残量しか明らかでないので、消費率のフィールドはブランクのままとされる。

その後、選択部１５ｄは、メディアデータのセンシング及び伝送をセンシングデバイスに指示する。その後、センシングデバイスから伝送される音声または映像のストリームデータを復号化し、復号化されたメディアデータが所定の出力先、例えばＩｏＴサービスに対応するアプリケーションプログラムに出力されることになる。これによって、ＩｏＴサービスに対応するアプリケーションプログラムにより、メディアデータを用いてＩｏＴサービスが提供されることになる。

なお、代行デバイス５０が複数存在する場合、その中から１つを選択する。この択一の選択基準は特定の基準に限定されないが、一例として、複数の代行デバイス５０のうちデバイスデータ１３ｃの特性のフィールドに格納された品質が最高である代行デバイス５０を選択することができる。

第２の取得部１５ｅは、ユーザデバイス３０から各種の情報を取得する処理部である。

一実施形態として、第２の取得部１５ｅは、選択部１５ｄによりセンシングデバイスが選択された場合、当該センシングデバイスの選択により提供が開始されたＩｏＴサービスの開始要求を行ったユーザデバイス３０から終了要求を受け付けるのを待機する。そして、第２の取得部１５ｅは、当該ユーザデバイス３０からＩｏＴサービスの終了要求を受け付けた場合に動作を開始する。

このようにＩｏＴサービスの終了要求が受け付けられた場合、第２の取得部１５ｅは、選択部１５ｄにより選択されたセンシングデバイスにメディアデータのセンシング及び伝送の終了を指示する。これによって、ＩｏＴサービスの提供が終了されることになる。続いて、第２の取得部１５ｅは、制御部１５が実行するＯＳ等により管理されるタイムスタンプからＩｏＴサービスの終了要求が受け付けられた時刻を終了時刻として取得する。そして、第２の取得部１５ｅは、記憶部１３に記憶されたサービス利用履歴データ１３ａのエントリのうち、ＩｏＴサービスの終了要求と共に受け付けたサービスＩＤと一致し、ＩｏＴサービスの開始時に識別されたサービスエリアと一致し、かつ継続時間のフィールドがブランクであるエントリを抽出する。ここでは、あくまで一例として、ＩｏＴサービスの開始時に識別されたサービスエリアを用いることとしたが、終了時にユーザデバイス３０の位置情報を取得して当該位置情報が属するサービスエリアを改めて識別することとしてもかまわない。その後、第２の取得部１５ｅは、先に抽出されたエントリに含まれる開始時刻と、先に取得された終了時刻とを比較する。例えば、第２の取得部１５ｅは、終了時刻から開始時刻を減算する計算、すなわち終了時刻−開始時刻を行うことにより、当該終了要求が受け付けられたＩｏＴサービスの継続時間を算出する。その上で、第２の取得部１５ｅは、記憶部１３に記憶されたサービス利用履歴データ１３ａのエントリが持つ継続時間のフィールドに先に算出された継続時間を登録する。なお、ここでは、開始時刻と終了時刻の差分から継続時間を算出する場合を例示したが、開始時刻からの時間経過を計測することにより、継続時間を導出することとしてもかまわない。

続いて、第２の取得部１５ｅは、記憶部１３に記憶されたデバイスデータ１３ｃのエントリのうち、選択部１５ｄにより選択されたセンシングデバイスが持つデバイスＩＤを持つエントリを抽出する。そして、第２の取得部１５ｅは、先に抽出されたエントリに含まれる種別のフィールドが「人」であるか否か、すなわちセンシングデバイスがユーザデバイス３０であるか否かを判定する。なお、センシングデバイスがユーザデバイス３０でない場合、すなわちセンシングデバイスが代行デバイス５０である場合、代行デバイス５０は外部電源に接続されているので、必ずしもバッテリ消費率を算出せずともかまわない。

一方、センシングデバイスがユーザデバイス３０である場合、ユーザデバイス３０のバッテリ消費率を履歴として残すために次のような処理が実行される。すなわち、第２の取得部１５ｅは、記憶部１３に記憶されたデバイス使用履歴データ１３ｄのエントリのうち、終了要求が行われたＩｏＴサービスのサービスＩＤ及び選択部１５ｄにより選択されたセンシングデバイスが持つデバイスＩＤのペアを含み、かつ当該ＩｏＴサービスの開始時刻と一致するエントリを抽出する。続いて、第２の取得部１５ｅは、記憶部１３に記憶されたバッテリデータ１３ｂに新規のエントリを作成した上でＩｏＴサービスの終了要求を行うユーザデバイス３０から取得されたバッテリ残量を登録する。例えば、第２の取得部１５ｅは、デバイスＩＤのフィールドには、ＩｏＴサービスの終了要求を行うユーザデバイス３０のデバイスＩＤを登録し、残量のフィールドには、ユーザデバイス３０から取得されたバッテリ残量を登録し、タイミングのフィールドには、ＩｏＴサービスの終了要求が受け付けられた局面であるので終了を登録する。

その上で、第２の取得部１５ｅは、バッテリデータ１３ｂのエントリのうち、選択部１５ｄにより選択されたセンシングデバイスが持つデバイスＩＤと一致し、かつタイミングのフィールドが開始で当該ＩｏＴサービスの開始時刻と一致するエントリを抽出する。その後、第２の取得部１５ｅは、先に登録したバッテリ残量と抽出されたエントリに含まれるバッテリ残量の差分を求め、これと先に求められた継続時間からバッテリ消費率を算出する。例えば、第２の取得部１５ｅは、ＩｏＴサービスの開始時に登録されたバッテリ残量から終了時に登録されたバッテリ残量が減算されたバッテリ消費量を先に求められた継続時間で除算する計算、すなわち（開始時のバッテリ残量−終了時のバッテリ残量）／継続時間の計算を行う。これによって、バッテリ消費率が求まる。その後、第２の取得部１５ｅは、記憶部１３に記憶されたデバイス使用履歴データ１３ｄのエントリのうち、終了要求が行われたＩｏＴサービスのサービスＩＤ及び選択部１５ｄにより選択されたセンシングデバイスが持つデバイスＩＤのペアを含み、かつ消費率のフィールドがブランクであるエントリに先に算出されたバッテリ消費率を登録する。

［サービス開始時のデータ遷移］
次に、図７〜図１０を用いて、ＩｏＴサービスの開始要求時にセンシングデバイスの選択に用いるデータ遷移について説明する。図７〜図１０は、データ遷移の一例を示す図である。図７〜図１０には、ＩｏＴサービスの開始要求を受け付けた時点のサービス利用履歴データ１３ａ、バッテリデータ１３ｂ、デバイスデータ１３ｃ及びデバイス使用履歴データ１３ｄが図３〜図６に示したデータの状態に対応するとしたとき、そこからの遷移が示されている。

例えば、デバイスＩＤ「user30」で識別されるユーザデバイス３０からサービスＩＤ「０００１」で識別されるＩｏＴサービスの開始要求を受け付けた場合、ユーザデバイス３０から位置情報およびバッテリ残量が取得される。この結果、図３に示したサービス利用履歴データ１３ａ及び図４に示したバッテリデータ１３ｂが図７に示すサービス利用履歴データ１３ａ及びバッテリデータ１３ｂへ遷移する。

すなわち、ユーザデバイス３０の位置情報が属するサービスエリアが「Ｅ２」と識別された段階で、図７に示すように、サービス利用履歴データ１３ａには新規のエントリが作成される。このようにして新規に作成されたエントリのうち、サービスＩＤのフィールドには、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ「０００１」が登録される。さらに、サービスエリアのフィールドには、ユーザデバイス３０の位置情報から識別されたサービスエリア「Ｅ２」が登録される。さらに、開始時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻「１２月１４日 １０時００分」が開始時刻として登録される。

また、ユーザデバイス３０のバッテリ残量「８０％」が取得された段階で、図７に示すように、バッテリデータ１３ｂには新規のエントリ１３ｂ１が作成される。このようにして新規に作成されたエントリ１３ｂ１のうち、デバイスＩＤのフィールドには、ＩｏＴサービスの開始要求を行うユーザデバイス３０のデバイスＩＤ「user30」が登録される。さらに、残量のフィールドには、ユーザデバイス３０から取得されたバッテリ残量「８０％」を登録し、時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻「１２月１４日 １０時００分」が開始時刻として登録される。さらに、タイミングのフィールドには、ＩｏＴサービスの開始要求が受け付けられた局面であるので「開始」が登録される。

その後、サービス継続時間が推定される段階では、サービス利用履歴データ１３ａのエントリのうち図８に太線の矩形で囲って示された２つのエントリが参照される。すなわち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ「０００１」を含み、かつユーザデバイス３０の位置情報が含まれるサービスエリア「Ｅ２」を含む２つのエントリ、すなわち上から１番目のエントリ１３ａ１と上から３番目のエントリ１３ａ３が参照される。その後、上から１番目のエントリ１３ａ１の継続時間「２時間３０分」と上から３番目のエントリ１３ａ３の継続時間「２時間」との平均、すなわち「（２時間３０分＋２時間）／２」を計算することにより、サービス継続時間が「２時間１５分」と推定される。

また、ユーザデバイス３０のバッテリ持続時間が推定される段階では、デバイス使用履歴データ１３ｄのエントリのうち図９に太線の矩形で囲って示されたエントリが参照される。すなわち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ「０００１」を含み、かつＩｏＴサービスの開始を要求するユーザデバイス３０が持つデバイスＩＤ「user30」を含むエントリ、すなわち上から３番目のエントリ１３ｄ３が抽出される。その後、デバイスＩＤ「user30」で識別されるユーザデバイス３０のバッテリ残量「８０％」を上から３番目のエントリ１３ｄ３のバッテリ消費率「２０％／ｈ」で除算する計算、すなわち「８０％÷（２０％／ｈ）」を計算することにより、バッテリ持続時間が「４時間」と推定される。

このようにサービス継続時間及びバッテリ持続時間が推定された上で、図１０に示すように、サービス継続時間及びバッテリ持続時間の大小関係が比較される。本例では、バッテリ持続時間「４時間」＞サービス継続時間「２時間１５分」であるので、ユーザデバイス３０にメディアデータをセンシングさせたとしてもバッテリ切れによりＩｏＴサービスが中断される可能性が低いと判断できる。この場合、ユーザデバイス３０がセンシングデバイスとして選択される。その後、図１０に示すように、デバイス使用履歴データ１３ｄには新規のエントリが作成される。このようにして新規に作成されたエントリのうち、サービスＩＤのフィールドには、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ「０００１」が登録される。さらに、デバイスＩＤのフィールドには、センシングデバイスとして選択されたＩｏＴデバイスが持つデバイスＩＤ「user30」が登録される。さらに、開始時刻のフィールドには、ＩｏＴサービスの開始要求を受け付けた時刻「１２月１４日 １０時００分」が開始時刻として登録される。

なお、本例では、バッテリ持続時間＞サービス継続時間である場合を例示したが、次のようなケースではバッテリ持続時間≦サービス継続時間となり、代行デバイス５０がセンシングデバイスとして選択される。

例えば、ユーザデバイス３０のバッテリ消費率が大きくなるほどバッテリ持続時間が短くなり、代行デバイス５０が選択される可能性が高まる。例を挙げれば、バッテリ消費率が４０％／ｈまで上がると、バッテリ持続時間は「８０％÷（４０％／ｈ）」の計算により２時間となる。この場合、バッテリ持続時間「２時間」＜サービス継続時間「２時間１５分」となるので、サービスエリア「Ｅ２」に対応付けられた代行デバイス５０Ｂ、すなわちデバイスＩＤ「agent50B」がセンシングデバイスとして選択される。また、ユーザデバイス３０のバッテリ残量が小さいほどバッテリ持続時間が短くなり、代行デバイス５０が選択される可能性が高まる。例を挙げれば、バッテリ残量が３５％であるとした場合、バッテリ持続時間は「３５％÷（２０％／ｈ）」の計算により１時間４５分となる。この場合、バッテリ持続時間「１時間４５分」＜サービス継続時間「２時間１５分」となるので、サービスエリア「Ｅ２」に対応付けられた代行デバイス５０Ｂがセンシングデバイスとして選択される。

また、サービス継続時間が長くなるほど、代行デバイス５０が選択される可能性が高まる。例えば、サービス継続時間が４時間を超えると、バッテリ持続時間よりも長くなるので、サービスエリア「Ｅ２」に対応付けられた代行デバイス５０Ｂがセンシングデバイスとして選択されることになる。

［サービス終了時のデータ遷移］
次に、図１１及び図１２を用いて、ＩｏＴサービスの終了要求時におけるデータ遷移について説明する。図１１及び図１２は、データ遷移の一例を示す図である。図１１及び図１２には、ＩｏＴサービスの終了要求を受け付けた時点のサービス利用履歴データ１３ａ、バッテリデータ１３ｂ、デバイスデータ１３ｃ及びデバイス使用履歴データ１３ｄが図１０に示したデータの状態に対応するとしたとき、そこからの遷移が示されている。

例えば、デバイスＩＤ「user30」で識別されるユーザデバイス３０からサービスＩＤ「０００１」で識別されるＩｏＴサービスの終了要求を受け付けた場合、当該ＩｏＴサービスの開始時刻と終了時刻との差から継続時間が算出される。このとき、ＩｏＴサービスの終了要求を受け付けた時刻が１２時００分であったとしたとき、図１１に示す通り、継続時間は、終了時刻−開始時刻、すなわち「１２時００分−１０時００分」の計算により、２時間と算出される。このように算出された継続時間「２時間」がサービス利用履歴データ１３ａのエントリに追記される。

また、デバイスＩＤ「user30」で識別されるユーザデバイス３０がセンシングデバイスとして選択されていたので、当該ＩｏＴサービスにおけるバッテリ消費率も算出される。すなわち、図１２に示すように、バッテリデータ１３ｂに新規のエントリを作成した上で、ＩｏＴサービスの終了要求を行うユーザデバイス３０から取得されたバッテリ残量「３５％」が登録される。そして、ＩｏＴサービスの開始時のバッテリ残量「８０％」からＩｏＴサービスの終了時のバッテリ残量「３５％」を減算する計算、すなわち「８０％−３５％」の計算により、バッテリ消費量が４５％と算出される。このようにして算出されたバッテリ消費量「４５％」を先に求められた継続時間「２時間」で除算する計算、すなわち「４５％÷２ｈ」の計算を行う。これによって、バッテリ消費率が２２．５％／ｈと求まる。その上で、バッテリ消費率「２２．５％／ｈ」がデバイス使用履歴データ１３ｄのエントリに追記される。

［処理の流れ］
次に、本実施例に係るサーバ装置１０の処理の流れについて説明する。なお、ここでは、ＩｏＴサービスの開始時に行われる（１）デバイス選択処理を説明した後に、ＩｏＴサービスの終了時に行われる（２）履歴更新処理を説明することとする。

（１）デバイス選択処理
図１３は、実施例１に係るデバイス選択処理の手順を示すフローチャートである。この処理は、一例として、ユーザデバイス３０からＩｏＴサービスの開始要求を受け付けた場合に開始される。

図１３に示すように、第１の取得部１５ａは、制御部１５が実行するＯＳ等により管理されるタイムスタンプからＩｏＴサービスの開始要求が受け付けられた時刻を開始時刻として取得する（ステップＳ１０１）。

そして、第１の取得部１５ａは、ユーザデバイス３０から位置情報を取得する（ステップＳ１０２）。続いて、第１の取得部１５ａは、記憶部１３に記憶されたデバイスデータ１３ｃに含まれる代行デバイス５０のサービスエリアのうち、ステップＳ１０２で取得されたユーザデバイス３０の位置情報が含まれるサービスエリアを識別する（ステップＳ１０３）。

その後、第１の取得部１５ａは、バッテリデータ１３ｂに作成された新規のエントリに、ＩｏＴサービスの開始要求を行うユーザデバイス３０のデバイスＩＤ、ユーザデバイス３０から取得されたバッテリ残量、ＩｏＴサービスの開始要求を受け付けた開始時刻およびユーザデバイス３０でバッテリ残量が測定されたタイミングである開始を対応付けて登録する（ステップＳ１０４）。

そして、ユーザデバイス３０の位置情報が含まれるサービスエリアが存在する場合（ステップＳ１０５Ｙｅｓ）、次のような処理を実行する。すなわち、第１の取得部１５ａは、サービス利用履歴データ１３ａに作成された新規のエントリに、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ、ステップＳ１０３で識別されたサービスエリア及びＩｏＴサービスの開始要求を受け付けた開始時刻を対応付けて登録する（ステップＳ１０６）。

続いて、第１の推定部１５ｂは、サービス利用履歴データ１３ａのエントリのうち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤと一致し、かつステップＳ１０３で識別されたサービスエリアと一致するエントリを抽出する（ステップＳ１０７）。その上で、第１の推定部１５ｂは、ステップＳ１０７で抽出されたエントリに含まれる継続時間を平均することにより、サービス継続時間を推定する（ステップＳ１０８）。

また、第２の推定部１５ｃは、デバイス使用履歴データ１３ｄのエントリのうち、ＩｏＴサービスの開始要求と共に受け付けたサービスＩＤと一致し、かつＩｏＴサービスの開始を要求するユーザデバイス３０が持つデバイスＩＤと一致するエントリを抽出する（ステップＳ１０９）。

その上で、第２の推定部１５ｃは、ステップＳ１０９で抽出されたエントリに含まれるバッテリ消費率が平均されたバッテリ消費率の平均値でステップＳ１０４で登録されたユーザデバイス３０のバッテリ残量を除算することにより、バッテリ持続時間を推定する（ステップＳ１１０）。

そして、選択部１５ｄは、バッテリ持続時間がサービス継続時間よりも長いか否か、すなわちバッテリ持続時間＞サービス継続時間であるか否かを判定する（ステップＳ１１１）。

ここで、バッテリ持続時間がサービス継続時間よりも長い場合、すなわちバッテリ持続時間＞サービス継続時間である場合（ステップＳ１１１Ｙｅｓ）、ユーザデバイス３０にメディアデータをセンシングさせたとしてもバッテリ切れによりＩｏＴサービスが中断される可能性が低いと判断できる。この場合、選択部１５ｄは、ユーザデバイス３０をセンシングデバイスとして選択する（ステップＳ１１２）。なお、ユーザデバイス３０の位置情報が含まれるサービスエリアが存在しない場合（ステップＳ１０５Ｎｏ）にも、ユーザデバイス３０がセンシングデバイスとして選択される（ステップＳ１１２）。

一方、バッテリ持続時間がサービス継続時間よりも長くない場合、すなわちバッテリ持続時間≦サービス継続時間である場合（ステップＳ１１１Ｎｏ）、バッテリ切れによりＩｏＴサービスが中断される可能性が高いと判断できる。この場合、選択部１５ｄは、ユーザデバイス３０の位置情報が含まれるサービスエリアに対応付けられた代行デバイス５０をセンシングデバイスとして選択する（ステップＳ１１３）。

上記のステップＳ１１２又は上記のステップＳ１１３によりセンシングデバイスが選択された後、選択部１５ｄは、次のような処理を実行する。すなわち、選択部１５ｄは、デバイス使用履歴データ１３ｄに作成された新規のエントリにＩｏＴサービスの開始要求と共に受け付けたサービスＩＤ、ステップＳ１１２又はステップＳ１１３で選択されたセンシングデバイスが持つデバイスＩＤ及びＩｏＴサービスの開始要求を受け付けた開始時刻を対応付けて登録する（ステップＳ１１４）。

その後、選択部１５ｄは、メディアデータのセンシング及び伝送をセンシングデバイスに指示することにより、ＩｏＴサービスの提供を開始し（ステップＳ１１５）、処理を終了する。

（２）履歴更新処理
図１４は、実施例１に係る履歴更新処理の手順を示すフローチャートである。この処理は、一例として、提供が開始されたＩｏＴサービスの開始要求を行ったユーザデバイス３０から終了要求を受け付けた場合に開始される。

図１４に示すように、第２の取得部１５ｅは、図１３に示したステップＳ１１１又はステップＳ１１２で選択されたセンシングデバイスにメディアデータのセンシング及び伝送の終了を指示することにより、ＩｏＴサービスの提供を終了する（ステップＳ３０１）。

続いて、第２の取得部１５ｅは、制御部１５が実行するＯＳ等により管理されるタイムスタンプからＩｏＴサービスの終了要求が受け付けられた時刻を終了時刻として取得する（ステップＳ３０２）。

そして、第２の取得部１５ｅは、ステップＳ３０２で取得された終了時刻からステップＳ１０４でサービス利用履歴データ１３ａのエントリに登録された開始時刻を減算する計算、すなわち終了時刻−開始時刻を行うことにより、当該終了要求が受け付けられたＩｏＴサービスの継続時間を算出する（ステップＳ３０３）。

その上で、第２の取得部１５ｅは、記憶部１３に記憶されたサービス利用履歴データ１３ａのエントリのうち、ＩｏＴサービスの終了要求と共に受け付けたサービスＩＤと一致し、ＩｏＴサービスの開始時に識別されたサービスエリアと一致し、かつ継続時間のフィールドがブランクであるエントリに、ステップＳ３０３で算出された継続時間を登録する（ステップＳ３０４）。

続いて、第２の取得部１５ｅは、デバイスデータ１３ｃのエントリのうち、ステップＳ１１１又はステップＳ１１２で選択されたセンシングデバイスが持つデバイスＩＤを持つエントリを抽出する（ステップＳ３０５）。そして、第２の取得部１５ｅは、ステップＳ３０５で抽出されたエントリに含まれる種別のフィールドが「人」であるか否か、すなわちセンシングデバイスがユーザデバイス３０であるか否かを判定する（ステップＳ３０６）。

このとき、センシングデバイスがユーザデバイス３０である場合（ステップＳ３０６Ｙｅｓ）、第２の取得部１５ｅは、次のような処理を実行する。すなわち、第２の取得部１５ｅは、デバイス使用履歴データ１３ｄのエントリのうち、終了要求が行われたＩｏＴサービスのサービスＩＤ及びステップＳ１１１又はステップＳ１１２で選択されたセンシングデバイスが持つデバイスＩＤのペアを含み、かつ当該ＩｏＴサービスの開始時刻と一致するエントリを抽出する（ステップＳ３０７）。

続いて、第２の取得部１５ｅは、ユーザデバイス３０により測定されたバッテリ残量を取得した上で、バッテリデータ１３ｂに作成された新規のエントリに、ＩｏＴサービスの終了要求を行うユーザデバイス３０のデバイスＩＤ、ユーザデバイス３０から終了要求時に取得されたバッテリ残量及びユーザデバイス３０でバッテリ残量が測定されたタイミングである終了を対応付けて登録する（ステップＳ３０８）。

そして、第２の取得部１５ｅは、ステップＳ１０５でＩｏＴサービスの開始時に登録されたバッテリ残量からステップＳ３０８でＩｏＴサービスの終了時に登録されたバッテリ残量が減算されたバッテリ消費量をステップＳ３０３で算出された継続時間で除算することにより、バッテリ消費率を算出する（ステップＳ３０９）。

その上で、第２の取得部１５ｅは、デバイス使用履歴データ１３ｄのエントリのうち、終了要求が行われたＩｏＴサービスのサービスＩＤ及びステップＳ１１１又はステップＳ１１２で選択されたセンシングデバイスが持つデバイスＩＤのペアを含み、かつ消費率のフィールドがブランクであるエントリにステップＳ３０９で算出されたバッテリ消費率を登録し（ステップＳ３１０）、処理を終了する。

なお、センシングデバイスがユーザデバイス３０でない場合、すなわちセンシングデバイスが代行デバイス５０である場合（ステップＳ３０６Ｎｏ）、代行デバイス５０は外部電源に接続されているので、必ずしもバッテリ消費率を算出せずともかまわない。この場合、そのまま処理が終了される。

［効果の一側面］
上述してきたように、本実施例に係るサーバ装置１０は、ユーザデバイス３０のバッテリ持続時間がサービス継続時間よりも長いか否かによってＩｏＴサービスに用いるメディアデータをユーザデバイス３０または代行デバイス５０のいずれにセンシングさせるのかを選択する。

したがって、本実施例に係るサーバ装置１０によれば、バッテリ切れによりＩｏＴサービスが中断されるのを抑制できる。さらに、ＩｏＴサービスの提供中にユーザデバイス３０のバッテリ切れが起こらない限り、ユーザデバイス３０の選択が優先されるので、代行デバイス５０によりセンシングされる場合に比べて高品質なメディアデータをＩｏＴサービスに用いることができる。さらに、バッテリ切れによってセンシングの主体がユーザデバイス３０から代行デバイス５０へ切り替わることも抑制できる。それ故、ＩｏＴサービスが開始されてから終了するまで一連のメディアデータを得ることができ、メディアデータに映像のコマ落ちや音切れなどが発生するのも抑制できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［ユーザデバイス３０の選択肢］
上記の実施例１では、１人のユーザにより携帯されるユーザデバイス３０が１つである場合を例示したが、ユーザにより携帯されるユーザデバイス３０は複数であってもかまわない。例えば、１人のユーザがヘッドマウントディスプレイ及びスマートウォッチを装着すると共にスマートフォンを携帯する状況も存在しうる。このような状況に対応するために、デバイスデータ１３ｃに所有者のフィールドを追加し、当該フィールドにＩｏＴデバイスの所有者のユーザＩＤを登録しておく。その上で、ＩｏＴサービスの開始要求を行うデバイスＩＤに対応付けられたユーザＩＤと一致するエントリをデバイスデータ１３ｃから抽出することにより、当該ユーザＩＤが付与されたユーザにより携帯されるユーザデバイス３０のデバイスＩＤの一覧を作成できる。この場合、一覧に含まれるユーザデバイス３０ごとにバッテリ持続時間を算出する。その上で、ユーザデバイス３０ごとに算出されたバッテリ持続時間のうち最大のバッテリ持続時間がサービス継続時間を超える場合、当該最大のバッテリ持続時間が算出されたデバイスＩＤを持つユーザデバイス３０をセンシングデバイスとして選択する。これによって、１人のユーザにより複数のユーザデバイス３０が携帯される場合でもセンシングデバイスを適切に選択できる。

［サービス継続時間の推定方法の応用例］
上記の実施例１では、上記のステップＳ１０６で抽出されたエントリの継続時間を平均することによりサービス継続時間を算出する場合を例示したが、平均以外の統計処理を行うことによりサービス継続時間を推定することもできる。例えば、上記のステップＳ１０６で抽出されたエントリの継続時間のうち最頻値や中央値をサービス継続時間として推定することもできる。この他、上記のステップＳ１０６で抽出されたエントリの継続時間のうち最大値をサービス継続時間として推定することもできる。これによって、履歴から推定するサービス継続時間が過小評価されるのを抑制できる結果、サービス継続時間の見積もりの甘さによりユーザデバイス３０のバッテリ切れが生じるのを抑制できる。

［バッテリ持続時間の推定方法の応用例］
上記の実施例１では、上記のステップＳ１０８で抽出されたエントリのバッテリ消費率を平均することによりバッテリ持続時間を算出する場合を例示したが、平均以外の統計処理を行うことによりバッテリ持続時間を推定することもできる。例えば、上記のステップＳ１０８で抽出されたエントリのバッテリ消費率のうち最頻値や中央値をサービス継続時間として推定することもできる。この他、上記のステップＳ１０８で抽出されたエントリのバッテリ消費率のうち最大値を用いてバッテリ持続時間として推定することもできる。これによって、履歴から推定するバッテリ持続時間が過大評価されるのを抑制できる結果、バッテリ持続時間の見積もりの甘さによりユーザデバイス３０のバッテリ切れが生じるのを抑制できる。

［再推定１］
上記の実施例１では、バッテリ持続時間の推定がＩｏＴサービスの開始要求を受け付けた段階に絞って行われる場合を例示したが、ユーザデバイス３０がセンシングデバイスとして選択された後も、改めてバッテリ持続時間を推定することもできる。例えば、サーバ装置１０は、ＩｏＴサービスが開始された後、所定の周期、例えば１０分間が経過する度にバッテリ持続時間を再推定することもできる。より具体的には、第１の取得部１５ａは、上記の周期が経過する度にユーザデバイス３０からバッテリ残量を取得する。そして、第２の推定部１５ｃは、ＩｏＴサービスの開始後に取得されたバッテリ残量と上記のステップＳ１０５で開始要求の受付時に取得されたバッテリ残量との差分をＩｏＴサービスの開始時刻からの経過時間で除算することにより、バッテリ持続時間を再推定する。このように過去の履歴から見積もられるバッテリ消費率の代わりにＩｏＴサービスの提供が開始されてから実際に消費されたバッテリ消費量の実測値からバッテリ持続時間を再推定する。その上で、選択部１５ｄは、再推定されたバッテリ持続時間が開始要求の受付時に推定されたサービス継続時間よりも長いか否かを判定する。このとき、バッテリ持続時間がサービス継続時間よりも長い場合、センシングデバイスをユーザデバイス３０のままとし、バッテリ持続時間がサービス継続時間以下である場合、センシングデバイスをユーザデバイス３０から代行デバイス５０へ切り替える。これによって、ＩｏＴサービスが開始されてからの経過時間が長くなるほどバッテリ持続時間の推定を正確に行うことができる結果、開始要求の受付時のバッテリ持続時間の推定に誤差がある場合でもユーザデバイス３０がバッテリ切れを起こす前にセンシングデバイスを代行デバイス５０に切り替えることができる。

［再推定２］
上記の実施例１では、サービス継続時間の推定がＩｏＴサービスの開始要求を受け付けた段階に絞って行われる場合を例示したが、ユーザデバイス３０がセンシングデバイスとして選択された後も、改めてサービス継続時間を推定することもできる。例えば、サーバ装置１０は、ＩｏＴサービスが開始された後、所定の周期、例えば１０分間が経過する度にサービス継続時間を再推定することもできる。より具体的には、第１の推定部１５ｂは、上記の周期が経過する度に、上記のステップＳ１０６で抽出されたエントリのうちＩｏＴサービスが開始されてからの経過時間よりも長い継続時間を持つエントリを再抽出する。その上で、第１の推定部１５ｂは、再抽出されたエントリの継続時間を用いて、サービス継続時間を再推定する。これによって、ＩｏＴサービスが開始されてからの経過時間よりも短い継続時間を持つ履歴をサービス継続時間の推定から除外して再推定を行うことができる。その上で、選択部１５ｄは、開始要求の受付時に推定されたバッテリ持続時間が再推定のサービス継続時間よりも長いか否かを判定する。このとき、バッテリ持続時間がサービス継続時間よりも長い場合、センシングデバイスをユーザデバイス３０のままとし、バッテリ持続時間がサービス継続時間以下である場合、センシングデバイスをユーザデバイス３０から代行デバイス５０へ切り替える。なお、本項で説明する「再推定２」は、前項で説明した「再推定１」と組み合わせて実施することもできる。すなわち、再推定されたバッテリ持続時間と、再推定されたサービス継続時間との比較により、センシングデバイスを選択することもできる。

［再推定のタイミング］
上記の「再推定１」及び上記の「再推定２」では、サービス継続時間やバッテリ持続時間の再推定が一定の周期で繰り返し実行される場合を例示したが、上記のステップＳ１０７で開始要求の受付時に推定されたサービス継続時間が経過した後に始めて再推定が実行されることとしてもよい。これによって、再推定にかかる処理負荷を軽減できる。

［選択中のユーザデバイス３０の継続使用］
また、途中でセンシングデバイスを切り替えるとサービス品質が低下するので、選択中のユーザデバイス３０を継続して使用するとバッテリ切れを起こすと判断した場合にのみ、選択中のユーザデバイス３０以外のユーザデバイス３０のバッテリ持続時間を再推定し、センシングデバイスを再選択することもできる。具体的には、バッテリ持続時間の推定を、全てのユーザデバイス３０ではなく、選択中のユーザデバイス３０についてのみ実施し、再推定したサービス継続時間と選択中のユーザデバイス３０のバッテリ持続時間を比較する。選択中のユーザデバイス３０のバッテリ持続時間がサービス継続時間より長い場合は、選択中のユーザデバイス３０をそのまま継続して再選択する。一方、選択中のユーザデバイス３０のバッテリ持続時間がサービス継続時間より短い場合は、選択中のユーザデバイス３０を継続して選択するとバッテリ切れを起こすと判断する。この判断の後、選択中のユーザデバイス３０以外のユーザデバイス３０について、バッテリ持続時間の再推定を実施してセンシングデバイスの再選択を実施する。これにより、選択中のユーザデバイス３０がバッテリ切れを起こさない限り、選択中のユーザデバイス３０を継続して使用することで、不必要なデバイス切替および切替に伴うサービス品質の低下を抑制できると共に、他のユーザデバイス３０のバッテリ持続時間の再推定やセンシングデバイスの再選択を実施しないことで、これらにかかる処理負荷を低減できる。

［センシングデバイスの切替えタイミング］
一定間隔で映像を撮像して伝送するサービスなど、センシングデバイスからの映像や音声をリアルタイムで伝送せずともよいＩｏＴサービスであれば、映像や音声を伝送せずともよい期間にセンシングデバイスを切り替えてもサービス品質は低下しない。そこで、ＩｏＴサービス毎にセンシングデバイスの切替可能タイミング、あるいは切替不能タイミングを管理しておき、選択中のセンシングデバイスとは異なるＩｏＴデバイスを再選択した場合には、上記の切替可能タイミング、あるいは上記の切替不能タイミング以外でセンシングデバイスを切り替える。なお、切替可能タイミング、切替不能タイミングは、例えば、定期的な時刻（毎時３０分など）やサービス開始からの経過時間（１０分間隔）などＩｏＴサービスの開始とともに静的に決まるタイミングでもよいし、音声が５分間ない状態など動的に決まるタイミングでもよい。これにより、センシングデバイスの切替によるサービス品質の低下を抑制できる。

［バッテリ残量の確保］
上記の実施例１では、ユーザデバイス３０のバッテリ残量を、当該ユーザデバイス３０をＩｏＴサービスに使用した際の過去のバッテリ消費率で除算したものをバッテリ持続時間として推定する場合を例示した。つまり、バッテリ持続時間は、当該ユーザデバイス３０をＩｏＴサービスにのみ使用する場合の想定で推定されている。ところが、ユーザは、ユーザデバイス３０をＩｏＴサービスに使用するためだけではなく、電子メールを作成したり、スケジュールを管理したり、あるいは他のサービスや作業を行ったりするためにも使用する。そのため、ユーザデバイス３０を使用してバッテリ残量が減りすぎると、これら別の目的のための使用ができなくなる。

そこで、上記のステップＳ１０９でバッテリ持続時間を推定する場合に、上記のステップＳ１０５で取得されるユーザデバイス３０のバッテリ残量ではなく、ＩｏＴサービスの利用後、別の目的のために残すマージンが減じられたバッテリ残量を、使用可能なバッテリ残量としてバッテリ持続時間の推定に用いる。別の目的のために残すバッテリ残量の決定方法はここでは限定しないが、一定量でもよいし、ユーザやユーザデバイス３０によって決定してもよいし、ユーザの当日の作業予定から算出してもよい。これにより、バッテリ残量を全てサービスに使用することを抑制し、ＩｏＴサービスの利用後もユーザデバイス３０を使用できる。

［デバイス選択の条件緩和］
上記の実施例１では、サービス継続時間とバッテリ持続時間を比較してセンシングデバイスを選択する場合を例示したが、ユーザデバイス３０の位置情報がサービスエリア外であり、かつ全てのユーザデバイス３０のバッテリ持続時間がサービス継続時間より短い場合、選択可能なセンシングデバイスが存在せず、ＩｏＴサービスを提供できない事態に陥る。そこで、複数のユーザデバイス３０を選択し、順に選択することでこれを解決することもできる。具体的には、開始要求の受付時に、サービス継続時間とバッテリ持続時間を比較し、バッテリ持続時間がサービス継続時間より短い場合には、複数のユーザデバイス３０のバッテリ持続時間を合算する。このように合算されたバッテリ持続時間がサービス継続時間より長い場合には、上記複数のユーザデバイス３０を順に選択し、ＩｏＴサービスに使用する。全てのユーザデバイス３０のバッテリ持続時間を合算してもサービス継続時間より短い場合、全てのユーザデバイス３０を順に使用してもＩｏＴサービスの利用中にバッテリ切れを起こすので、代行デバイス５０を選択する（ユーザデバイス３０の位置情報がサービスエリア外である場合はＩｏＴサービスは利用できない）。なお、ＩｏＴサービスに使用する複数のユーザデバイス３０の選択方法は特に限定しないが、例えばユーザデバイス３０のバッテリ持続時間が長いものから合算すればよい。これによって、バッテリ切れを起こさない単体のユーザデバイス３０が存在しない場合であっても、ＩｏＴサービスを利用できる。

［複数サービスの対応］
上記の実施例１では、１つのＩｏＴサービスが開始および終了する場合の処理について説明したが、多様なＩｏＴサービスが存在する環境では、複数のＩｏＴサービスが同時に利用されることもある。そこで、提供中の第１のサービスに加え、第１のサービスとは異なる第２のサービスを開始する時には、使用可能なデバイスのバッテリ残量と、ユーザデバイス３０が第１および第２のサービスのセンシングデバイスとして併用された際の過去のバッテリ消費率に基づいて、バッテリ持続時間を推定する。具体的には、デバイス使用履歴データ１３ｄには、対象デバイスを使用して利用した全てのＩｏＴサービスのサービスＩＤ、デバイスＩＤ、開始時刻、バッテリ消費率のレコードが含まれる。すなわち、利用した複数のＩｏＴサービスとデバイスの組合せ毎に、バッテリ消費率が保持される。

また、開始要求の受付時の処理として、第２の推定部１５ｃは、全てのユーザデバイス３０ごとに、以下に説明する処理を行う。これを具体的に説明すると、デバイス使用履歴データ１３ｄを参照して、デバイスＩＤがユーザデバイス３０のデバイスＩＤと同一であり、かつバッテリ消費率が空欄であるエントリを抽出する。以下、これをエントリＣと記載する。このエントリＣは、ユーザデバイス３０をセンシングデバイスとして選択中であるＩｏＴサービスの組合せを表し、よってユーザデバイス３０に対して最大１つしか見つからない。

エントリＣの抽出に成功した場合、デバイス使用履歴データ１３ｄを再び参照して、サービスＩＤが、エントリＣのサービスＩＤにＩｏＴサービスの開始が要求されたサービスＩＤを加えたもので、さらにデバイスＩＤがユーザデバイス３０のデバイスＩＤと同一であるエントリを抽出する。以下、これをエントリＤと記載する。エントリＤは、開始要求されたＩｏＴサービスにユーザデバイス３０を使用した場合に同時利用となるサービスの組合せに、ユーザデバイス３０を使用した過去の履歴である。

エントリＤが１つ以上見つかった場合、エントリＤのバッテリ消費率の平均を求め、ユーザデバイス３０のバッテリ残量を除算することにより、そのユーザデバイス３０のバッテリ持続時間を推定する。これは、同じサービスの組合せに同じデバイスを使用した際のバッテリ消費率は類似する可能性が高い想定に基づく。

エントリＤが１つも見つからない場合、すなわち同時利用となるサービスの組合せにユーザデバイス３０を使用したことがない場合、ユーザデバイス３０の現在のバッテリ消費率を、上記のステップＳ３０９の処理と同様の手順で求める。また、開始要求されたサービスにユーザデバイス３０を使用した場合のバッテリ消費率を、上記のステップＳ１０９の処理と同様の手順で求める。このようにして求めた２つのバッテリ消費率を合算したものを、使用中のサービスと開始要求されたサービスを同時利用した際のバッテリ消費率として、ユーザデバイス３０のバッテリ持続時間を推定する。

一方、エントリＣが見つからない場合、ユーザデバイス３０は現在どのサービスにも使用されていないため、開始要求されたサービスにユーザデバイス３０を使用した場合のバッテリ持続時間を、上記のステップＳ１０９の処理と同様の手順で求める。

また、選択部１５ｄは、センシングデバイスを選択した後、デバイス使用履歴データ１３ｄに記録する際には、サービスＩＤに、ユーザデバイス３０を使用中のサービスＩＤと、開始要求されたサービスＩＤを全て記録する。同時に、上記のエントリＣに対して、上記のステップＳ３０９の処理と同様の手順でセンシングデバイスの現在のバッテリ消費率を計算して記録する。エントリＣがない場合は、ユーザデバイス３０はどのサービスにも使用されていなかったため、特に何もせずともかまわない。なお、ＩｏＴサービスの終了時は、上記の実施例１と同じである。以上の処理によって、単一のユーザデバイス３０を併用して、複数のＩｏＴサービスを利用できる。

ここで、複数のＩｏＴサービスに対して、それぞれ異なるユーザデバイス３０を使用すると、それぞれのユーザデバイス３０の使用に電力を消費してしまう。そこで使用中のユーザデバイス３０を同時利用できる場合には、優先的に選択する。具体的には、バッテリ持続時間の推定を、全てのユーザデバイス３０ではなく、いずれかのサービスに使用中のユーザデバイス３０についてのみ実施し、選択部１５ｄの処理において、使用中のユーザデバイス３０を継続して使用するとバッテリ切れを起こすと判断した場合にのみ、未使用のユーザデバイス３０について、バッテリ持続時間の推定を実施する。これによって、使用するデバイス数を削減し、複数のＩｏＴサービスを効率よく利用できる。

また、上記の処理において、他のＩｏＴサービスでは未使用のユーザデバイス３０を、開始要求されたＩｏＴサービスに使用する場合には、他のユーザデバイス３０を使用する他のＩｏＴサービスについて、使用を開始するユーザデバイス３０で同時利用できるか判定し、同時利用可能であればセンシングデバイスに切り替える。判定は、開始要求されたＩｏＴサービスを開始した後、他のユーザデバイス３０を使用する他のＩｏＴサービスについて、上記のバッテリ持続時間の推定を実施し、同時利用できるかを判定すればよい。これによって、使用するデバイス数を削減し、複数のＩｏＴサービスを効率よく利用できる。

ただしこのとき、センシングデバイスを切り替えるとサービス品質が低下してしまう。そこで、第１のサービスについて、使用中のユーザデバイス３０を継続して使用するか、開始要求された第２のサービスに使用したユーザデバイス３０に切り替えるかを、第１のサービスと第２のサービスのサービス継続時間に基づいて判断する。例えば、第１のサービスのサービス継続時間のうち、すでに半分以上が経過していればそのまま継続して使用してもよいし、第２のサービスのサービス継続時間が第１のサービスのサービス継続時間の残りより長い場合に、残りの時間全てを切替後のユーザデバイス３０で使用できるため切り替えてもよい。

［デバイス選択プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記の実施例と同様の機能を有するデバイス選択プログラムを実行するコンピュータの一例について説明する。

図１５は、実施例１及び実施例２に係るデバイス選択プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１５に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１５に示すように、上記の実施例１で示した第１の取得部１５ａ、第１の推定部１５ｂ、第２の推定部１５ｃ、選択部１５ｄ及び第２の取得部１５ｅと同様の機能を発揮するデバイス選択プログラム１７０ａが記憶される。このデバイス選択プログラム１７０ａは、図２に示した第１の取得部１５ａ、第１の推定部１５ｂ、第２の推定部１５ｃ、選択部１５ｄ及び第２の取得部１５ｅの各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０からデバイス選択プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、デバイス選択プログラム１７０ａは、図１５に示すように、デバイス選択プロセス１８０ａとして機能する。このデバイス選択プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうちデバイス選択プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、デバイス選択プロセス１８０ａが実行する処理の一例として、図１３〜図１４に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

なお、上記のデバイス選択プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にデバイス選択プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体からデバイス選択プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などにデバイス選択プログラム１７０ａを記憶させておき、コンピュータ１００がこれらからデバイス選択プログラム１７０ａを取得して実行するようにしてもよい。

１ ＩｏＴシステム
１０ サーバ装置
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ サービス利用履歴データ
１３ｂ バッテリデータ
１３ｃ デバイスデータ
１３ｄ デバイス使用履歴データ
１５ 制御部
１５ａ 第１の取得部
１５ｂ 第１の推定部
１５ｃ 第２の推定部
１５ｄ 選択部
１５ｅ 第２の取得部
３０ ユーザデバイス
５０Ａ，５０Ｂ，５０Ｃ 代行デバイス

Claims (9)

1. 第１のデバイスからサービスの開始要求を受け付ける処理と、
   前記第１のデバイスの位置情報を取得する処理と、
   エリアごとに前記サービスの提供が継続された継続時間の履歴が記憶されている記憶部を参照して、前記位置情報が属するエリアに対応する継続時間の履歴から前記サービスの継続時間を推定する処理と、
   前記開始要求の受付時における第１のデバイスのバッテリ残量と前記第１のデバイスのバッテリ消費率とから、前記第１のデバイスのバッテリ持続時間を推定する処理と、
   前記サービスの継続時間と前記バッテリ持続時間に基づいて、前記第１のデバイスまたは前記位置情報が属するエリアに設置された第２のデバイスを選択する処理と、
   前記第１のデバイスまたは前記第２のデバイスのうち選択されたデバイスに前記サービスに用いるメディアデータのセンシングを実行させる処理と、
   をコンピュータが実行することを特徴とするデバイス選択方法。
2. 前記選択する処理は、前記バッテリ持続時間が前記サービスの継続時間よりも長い場合に前記第１のデバイスを選択し、前記バッテリ持続時間が前記サービスの継続時間よりも長くない場合に前記第２のデバイスを選択することを特徴とする請求項１に記載のデバイス選択方法。
3. 前記推定する処理は、前記位置情報が属するエリアに対応する継続時間の履歴のうち前記サービスが開始されてからの経過時間よりも短い継続時間の履歴を除外して前記サービスの継続時間を再推定することを特徴とする請求項１または２に記載のデバイス選択方法。
4. 前記推定する処理は、前記サービスが開始されてからの経過時間が前記サービスの継続時間よりも大きい場合、前記サービスの継続時間の再推定を行うことを特徴とする請求項３に記載のデバイス選択方法。
5. 前記推定する処理は、前記開始要求の受付時における第１のデバイスのバッテリ残量および前記サービスの開始後に取得された第１のデバイスのバッテリ残量の差分と、前記サービスが開始されてからの経過時間とから求まる第１のデバイスのバッテリ消費率を用いて、前記第１のデバイスのバッテリ持続時間を再推定することを特徴とする請求項１〜４のいずれか１つに記載のデバイス選択方法。
6. 前記推定する処理は、前記位置情報が属するエリアに対応する継続時間の履歴のうち最大の継続時間を前記サービスの継続時間として推定することを特徴とする請求項１〜５のいずれか１つに記載のデバイス選択方法。
7. 前記推定する処理は、前記第１のデバイスのバッテリ消費率の履歴のうち最大のバッテリ消費率を用いて、前記第１のデバイスのバッテリ持続時間を推定することを特徴とする請求項１〜６のいずれか１つに記載のデバイス選択方法。
8. 第１のデバイスからサービスの開始要求を受け付ける処理と、
   前記第１のデバイスの位置情報を取得する処理と、
   エリアごとに前記サービスの提供が継続された継続時間の履歴が記憶されている記憶部を参照して、前記位置情報が属するエリアに対応する継続時間の履歴から前記サービスの継続時間を推定する処理と、
   前記開始要求の受付時における第１のデバイスのバッテリ残量と前記第１のデバイスのバッテリ消費率とから、前記第１のデバイスのバッテリ持続時間を推定する処理と、
   前記サービスの継続時間と前記バッテリ持続時間に基づいて、前記第１のデバイスまたは前記位置情報が属するエリアに設置された第２のデバイスを選択する処理と、
   前記第１のデバイスまたは前記第２のデバイスのうち選択されたデバイスに前記サービスに用いるメディアデータのセンシングを実行させる処理と、
   をコンピュータに実行させることを特徴とするデバイス選択プログラム。
9. 第１のデバイスからサービスの開始要求を受け付ける受付部と、
   前記第１のデバイスの位置情報を取得する取得部と、
   エリアごとに前記サービスの提供が継続された継続時間の履歴が記憶されている記憶部を参照して、前記位置情報が属するエリアに対応する継続時間の履歴から前記サービスの継続時間を推定する第１の推定部と、
   前記開始要求の受付時における第１のデバイスのバッテリ残量と前記第１のデバイスのバッテリ消費率とから、前記第１のデバイスのバッテリ持続時間を推定する第２の推定部と、
   前記サービスの継続時間と前記バッテリ持続時間に基づいて、前記第１のデバイスまたは前記位置情報が属するエリアに設置された第２のデバイスを選択する選択部と、
   前記第１のデバイスまたは前記第２のデバイスのうち選択されたデバイスに前記サービスに用いるメディアデータのセンシングを実行させる制御部と、
   を有することを特徴とするデバイス選択装置。

Images