JP6330526B2 - センシング制御プログラム及び携帯端末装置 - Google Patents

Description

本発明は、センシング制御プログラム及び携帯端末装置に関する。

各種のセンシングを用いたアプリケーションプログラムがスマートフォンに代表される携帯端末装置に搭載されている。かかる携帯端末装置の多機能化に伴って、携帯端末装置に同種のセンサが複数搭載されることがある。

国際公開第２０１０／１０７１０７号 特開２００３−１５７１５５号公報

しかしながら、上記の技術では、必ずしもセンシングを実行するのに選択されるセンサがセンシングの実行に選択されないセンサよりも消費電力が小さいとは限らず、センシングの消費電力を抑制できない場合がある。

１つの側面では、本発明は、センシングの消費電力を抑制できるセンシング制御プログラム及び携帯端末装置を提供することを目的とする。

一態様のセンシング制御プログラムは、コンピュータに、１つまたは複数のセンシングを実現するセンサまたは前記センサを制御するドライバの組合せごとに前記センシングの実行時に動作させるデバイスを特定し、特定されたデバイスが前記センシングにより消費する電力を前記組合せごとに算出し、前記電力が最小である組合せを選択する処理を実行させる。

センシングの消費電力を抑制できる。

図１は、実施例１に係る携帯端末装置の機能的構成を示すブロック図である。 図２は、実施例１に係るミドルウェア実行部の機能的構成を示すブロック図である。 図３は、動作電力データの一例を示す図である。 図４は、対応関係テーブルの構成例を示す図である。 図５は、消費電力の算出結果の一例を示す図である。 図６は、対応関係テーブルの構成例を示す図である。 図７は、消費電力の算出結果の一例を示す図である。 図８は、実施例１に係るセンシング制御の手順を示すフローチャートである。 図９は、実施例２に係る携帯端末装置の機能的構成を示すブロック図である。 図１０は、実施例２に係るミドルウェア実行部の機能的構成を示すブロック図である。 図１１は、リクエストデータの遷移例を示す図である。 図１２は、実施例２に係る第１のセンシング制御の手順を示すフローチャートである。 図１３は、実施例２に係る第２のセンシング制御の手順を示すフローチャートである。 図１４は、実施例３に係る携帯端末装置の機能的構成を示すブロック図である。 図１５は、実施例３に係るミドルウェア実行部の機能的構成を示すブロック図である。 図１６は、動作状態データの遷移例を示す図である。 図１７は、消費電力の算出結果の一例を示す図である。 図１８は、動作状態データの遷移例を示す図である。 図１９は、消費電力の増分に関する算出結果の一例を示す図である。 図２０は、実施例３に係るセンシング制御の手順を示すフローチャートである。 図２１は、実施例１〜実施例４に係るセンシング制御プログラムを実行するコンピュータの一例について説明するための図である。

以下に添付図面を参照して本願に係るセンシング制御プログラム及び携帯端末装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［携帯端末装置の構成］
まず、本実施例に係る携帯端末装置の機能的構成について説明する。図１は、実施例１に係る携帯端末装置１０の機能的構成を示すブロック図である。図１に示す携帯端末装置１０は、携帯端末装置１０上で動作するアプリケーションプログラムが要求するセンシングを携帯端末装置１０の制御下にあるセンサを用いて実行するセンシング制御を実行するものである。

かかるセンシング制御の一環として、携帯端末装置１０は、同一のセンシングを実現できるセンサが携帯端末装置１０の制御下にあるセンサの中に複数通り存在する場合に、他のセンサを用いてセンシングを実行する場合よりも消費電力が少ないセンサを選択する。これによって、携帯端末装置１０は、例えば、センシングの消費電力を抑制する。

一実施形態として、携帯端末装置１０は、上記のセンシング制御をＡＰＩ（Application Programming Interface）として携帯端末装置１０上で動作するアプリケーションプログラム等へ提供するセンシング制御プログラムをミドルウェアとして各種のコンピュータにインストールさせることによって実装できる。かかるセンシング制御プログラムは、パッケージソフトウェアとして提供されることとしてもよいし、オンラインソフトウェアとして提供されることとしてもかまわない。例えば、上記のセンシング制御プログラムは、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信端末のみならず、タブレット端末やスレート端末などを含む携帯端末装置にインストールさせることができる。これによって、携帯端末装置１０に上記のセンシング制御を実行させることができる。

なお、ここでは、上記のセンシング制御プログラムがインストールされる装置の一例として、携帯端末装置１０を例示して以下の説明を行うが、必ずしもセンシング制御プログラムが携帯端末装置１０にインストールされずともよい。例えば、上記のセンシング制御プログラムは、パーソナルコンピュータを始めとする据置き型の端末装置を含む情報処理装置全般にインストールさせることができる。

図１に示すように、携帯端末装置１０は、センサ類の一例として、ＢＬＥ（Bluetooth（登録商標） Low Energy）チップ１１ａと、歩行センサ１１ｂと、ＢＬＥチップ１１ｃと、歩行センサ１１ｄとを有する。

ＢＬＥチップ１１ａ及びＢＬＥチップ１１ｃは、いずれも他の装置との間でＢＬＥによる通信を実行するチップである。これらＢＬＥチップ１１ａ及びＢＬＥチップ１１ｃの各々は、ＢＬＥ対応のデバイスをセンシングすることができる。なお、ここでは、近距離無線通信の一例としてＢＬＥを例示したが、他の規格により近距離無線通信が実行されることとしてもかまわない。

これらのうち、ＢＬＥチップ１１ａは、制御部１４が実行するドライバによって他のデバイスを介在させずに使用される一方で、ＢＬＥチップ１１ｃと制御部１４が実行するドライバとの間には、センサマイコン１２ｃｄが介在する点が異なる。

これらＢＬＥチップ１１ａ及びＢＬＥチップ１１ｃには、図示しないマイクロコンピュータが搭載される。かかるマイクロコンピュータは、所定の通知条件、例えば閾値判定等を満たす場合に絞って制御部１４への通知を実行する。これによって、ＢＬＥのセンシングを実行する場合、通知条件を満たすまで制御部１４をスリープ状態にできる。

歩行センサ１１ｂ及び歩行センサ１１ｄは、いずれも歩行データを採取するセンサである。これらのうち、歩行センサ１１ｂは、制御部１４が実行するドライバによって他のデバイスを介在させずに使用される一方で、ＢＬＥチップ１１ｃと制御部１４が実行するドライバとの間には、センサマイコン１２ｃｄが介在する点が異なる。

一実施形態として、歩行センサ１１ｂ及び歩行センサ１１ｄには、３軸の加速度センサなどのモーションセンサを採用できる。例えば、歩行データの一例として、モーションセンサから採取される３軸の加速度データを用いて、歩行や速歩などをセンシングすることができる。さらに、地磁気センサまたはジャイロセンサなどから得られる姿勢成分と併せることによってより高精度な歩行データをセンシングすることもできる。

さらに、携帯端末装置１０は、図１に示すように、センシングプロセッサの一例として、センサマイコン１２ｃｄを有する。

センサマイコン１２ｃｄは、ＢＬＥチップ１１ｃ及び歩行センサ１１ｄによるセンシングを制御するマイクロプロセッサ、いわゆるマイコンである。

一実施形態として、センサマイコン１２ｃｄは、ＢＬＥチップ１１ｃ及び歩行センサ１１ｄからのセンサ出力を組み合わせて複合的な通知条件を判定することができる。そして、センサマイコン１２ｃｄは、上記の通知条件を満たす場合に絞って制御部１４への通知を実行する。これによって、センサマイコン１２ｃｄの制御下にあるセンサがセンシングを実行する場合、通知条件を満たすまで制御部１４をスリープ状態にできる。

さらに、携帯端末装置１０は、図１に示すように、携帯端末装置１０における主記憶装置としての記憶部１３と、中央演算装置としての制御部１４とを有する。

記憶部１３は、制御部１４で実行されるＯＳ（Operating System）、ミドルウェア及びアプリケーションプログラムなどの各種プログラムに用いられるデータを記憶する記憶デバイスである。

一実施形態として、記憶部１３は、携帯端末装置１０における主記憶装置として実装される。例えば、記憶部１３には、各種の半導体メモリ素子、例えばＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）やフラッシュメモリを採用できる。また、記憶部１３は、補助記憶装置として実装することもできる。この場合、ＵＳＢ（Universal Serial Bus）メモリやＳＤ（Secure Digital）カードなどのリムーバブルメディアの他、ＳＳＤ（Solid State Drive）などを採用できる。

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

一実施形態として、制御部１４は、中央処理装置、いわゆるＣＰＵ（Central Processing Unit）として実装される。以下では、制御部がＣＰＵとして実装される場合を想定し、制御部のことを「ＣＰＵ」と記載して説明する場合がある。なお、制御部１４は、必ずしも中央処理装置として実装されずともよく、ＭＰＵ（Micro Processing Unit）として実装されることとしてもよい。また、制御部１４は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによっても実現できる。

制御部１４は、各種のプログラムを実行することによって下記の処理部を仮想的に実現する。例えば、制御部１４は、図１に示すように、ドライバ実行部１５ａと、ドライバ実行部１５ｂと、センサマイコンドライバ実行部１５ｃｄと、アプリ実行部１６と、ミドルウェア実行部１７とを有する。

ドライバ実行部１５ａ、ドライバ実行部１５ｂ及びセンサマイコンドライバ実行部１５ｃｄは、いずれも携帯端末装置１０の制御下にあるセンサを制御をするソフトウェア、いわゆるドライバを実行する処理部である。

これらのうち、ドライバ実行部１５ａは、ＢＬＥチップ１１ａに対応するドライバを実行し、さらに、ドライバ実行部１５ｂは、歩行センサ１１ｂに対応するドライバを実行する。また、センサマイコンドライバ実行部１５ｃｄは、センサマイコン１２ｃｄに対応するドライバを実行する。

アプリ実行部１６は、各種のアプリケーションプログラムを実行する処理部である。

一実施形態として、アプリ実行部１６は、任意のアプリケーションプログラムを実行することができる。かかるアプリケーションプログラムは、携帯端末装置１０にプリインストールされたものであってもよいし、外部装置からダウンロードされたものであってもよいし、有線または無線により接続されるリムーバブルメディアから取得されたものであってもかまわない。例えば、アプリ実行部１６は、ユーザの操作によってアプリケーションプログラムの起動が指示された場合に当該アプリケーションプログラムを起動させる。また、アプリ実行部１６は、バックグラウンドでアプリケーションを動作させることもできる。この場合、アプリケーションプログラムは、携帯端末装置１０のメーカまたはアプリケーションプログラムの発行元などによって定められた条件にしたがって携帯端末装置１０のユーザから与えられた権限の範囲内で動作する。なお、マルチタスクにより複数のアプリケーションプログラムが並行して実行されることとしてもかまわない。

ここで、アプリケーションプログラムは、ミドルウェア実行部１７で実行されるミドルウェアに対し、センシングのリクエストを行う場合がある。例えば、ＳＮＳ（Social Networking Service）やゲームに関するアプリケーションプログラムが実行されている場合、近距離無線通信によるすれ違い通信が他の端末となされる場合がある。この場合、アプリケーションプログラムからミドルウェアへＢＬＥのセンシングが指示される。また、健康管理に関するアプリケーションプログラム、すなわち消費カロリー等を計算するアプリケーションプログラムが実行されている場合、消費カロリーの計算に歩行や速歩の歩数が用いられる場合がる。この場合、アプリケーションプログラムからミドルウェアへ歩行のセンシングが指示される。

ミドルウェア実行部１７は、ミドルウェアとして提供されるセンシング制御プログラムを実行する処理部である。

図２は、実施例１に係るミドルウェア実行部１７の機能的構成を示すブロック図である。図２に示すように、ミドルウェア実行部１７は、受付部１７ａと、特定部１７ｂと、算出部１７ｃと、選択部１７ｄと、指示部１７ｅとを有する。

受付部１７ａは、アプリケーションプログラムから各種の指示を受け付ける処理部である。

一実施形態として、受付部１７ａは、アプリ実行部１６によって実行されるアプリケーションプログラムからセンシング制御プログラムが提供するＡＰＩにしたがってセンシングのリクエストを受け付ける。かかるセンシングのリクエストには、一例として、センシングの種別を始め、その他の各種情報、例えばセンシング期間などを含めることができる。このようにしてセンシングのリクエストを受け付けた場合、受付部１７ａは、リクエストを特定部１７ｂへ通知する。

特定部１７ｂは、アプリケーションプログラムからリクエストを受け付けた１または複数のセンシングを実現するセンサまたはドライバの組合せごとにセンシングの実行時に動作させるデバイスを特定する処理部である。

一実施形態として、特定部１７ｂは、アプリ実行部１６が実行中のアプリケーションプログラムからセンシングのリクエストを受け付けた場合、当該リクエストに関するセンシングを実現するドライバの組合せを導出する。例えば、特定部１７ｂは、受付部１７ａがリクエストを受け付けたセンシングを実行可能であるか否かを制御部１４で実行中の各ドライバ実行部１５ａ、１５ｂ及び１５ｃｄに問い合わせることによってドライバの組合せを導出する。また、特定部１７ｂは、センシングの種別とドライバの組合せとの対応関係が規定された対応関係テーブルを参照し、リクエストを受け付けたセンシングの種別に対応付けられたドライバの組合せを検索することによってドライバの組合せを導出することとしてもかまわない。このように、特定部１７ｂは、上記の問合せまたは検索のいずれによってもドライバの組合せを導出することができる。このとき、特定部１７ｂは、リクエストを受け付けたセンシングを実現するドライバの組合せが複数通りにわたって存在する場合、全てのドライバの組合せを導出する。なお、ここでは、一例として、ドライバの組合せを抽出することとしたが、センサの組合せを導出することとしてもかまわない。

その後、特定部１７ｂは、ドライバの組合せのうちドライバの組合せを１つ選択する。続いて、特定部１７ｂは、先に選択されたドライバの組合せからセンシングの実行時に動作させるデバイスを特定する。すなわち、特定部１７ｂは、センシングを実行するのに末端のハードウェアであるセンサだけを動作させればよいのか、センサ出力を用いた判定を実行できるＣＰＵ１４も動かさないといけないのか、あるいはセンサマイコン１２ｃｄ等のセンシングプロセッサをＣＰＵ１４の代わりに動かせばよいのかを特定する。このことから、上記のデバイスには、センサを始め、プロセッサが含まれることもある。以下では、センシングの実行時に動作させるデバイスのことを「動作デバイス」と記載する場合がある。このとき、上記の問合せの場合、センシングの可否とともに、センシングの実行が可能である場合には、動作デバイスを併せて返信させることとすればよい。また、上記の検索の場合、上記の対応関係テーブルの項目として動作デバイスをさらに対応付けておくこととすればよい。

算出部１７ｃは、動作デバイスがセンシングにより消費する電力を組合せごとに算出する処理部である。

一実施形態として、算出部１７ｃは、特定部１７ｂによって動作デバイスが特定される度に、記憶部１３に記憶された動作電力データ１３ａを参照して、各デバイスがセンシングで消費する電力を算出する。例えば、動作電力データ１３ａには、デバイス及び動作電力などの項目が対応付けられたデータを採用できる。図３は、動作電力データ１３ａの一例を示す図である。図３には、ＢＬＥチップ１１ａ、歩行センサ１１ｂ、ＢＬＥチップ１１ｃ、歩行センサ１１ｄ、センサマイコン１２ｃｄ、ＣＰＵ１４の各デバイスの動作電力が例示されている。例えば、図３の例では、同じＢＬＥセンサであっても、ＢＬＥチップ１１ａが動作するのに３ｍＡを消費するのに対し、ＢＬＥチップ１１ｃは動作に２ｍＡしか消費しないことを意味する。さらに、ＣＰＵ１４の動作電力は最大の２０ｍＡであり、他のデバイスに比べて、倍以上の電力が動作に消費されることも意味している。これを用いて、算出部１７ｃは、センシングの実行時に動作させる各デバイスに対応する動作電力を検索する。その上で、算出部１７ｃは、各デバイスの動作電力を合計することによって各デバイスがセンシングを実行する場合の消費電力を算出する。

選択部１７ｄは、センシングの実行時における消費電力が最小である組合せを選択する処理部である。

一実施形態として、選択部１７ｄは、算出部１７ｃによって消費電力が算出される度に、それまでに算出された消費電力のうち最小値が保存される図示しない内部メモリを参照し、互いの消費電力の大小を比較する。このとき、選択部１７ｄは、算出部１７ｃによって算出された消費電力が内部メモリに保存された最小値よりも小さい場合、すなわち消費電力＜最小値である場合、算出部１７ｃによって算出された消費電力を内部メモリに上書き保存する。一方、算出部１７ｃによって算出された消費電力が内部メモリに保存された最小値以上である場合、すなわち消費電力≧最小値である場合には、内部メモリへの上書き保存は実行されない。また、内部メモリに最小値が保存されていない場合には、算出部１７ｃによって算出された消費電力が最小値としてそのまま保存される。その後、選択部１７ｄは、全ての組合せにわたって消費電力が算出された後に、内部メモリに保存された最小値がセンシングの実行時における消費電力として算出されていたドライバの組合せを選択する。

指示部１７ｅは、センシングの実行を指示する処理部である。

一実施形態として、指示部１７ｅは、選択部１７ｄによって選択された組合せに含まれるドライバに対し、動作デバイスを制御してセンシングを実行する指示を行う。この結果、リクエストに対応するセンシングが携帯端末装置１０で実行されることになる。このように、アプリケーションプログラムがＡＰＩにしたがってセンシングをリクエストすることによって携帯端末装置１０が搭載するセンサの利用手順をプログラミングせずともソースコードを作成できる。

なお、携帯端末装置１０は、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部を有することとしてもかまわない。例えば、携帯端末装置１０がタブレット端末やスレート端末として実装される場合には、入力デバイス、表示デバイスまたは表示かつ入力が可能なデバイスをさらに有することとしてもよい。また、携帯端末装置１０が移動体通信端末として実装される場合には、アンテナ、移動体通信網に接続する無線通信部、ＧＰＳ（Global Positioning System）受信機などの機能部をさらに有していてもかまわない。

［具体例］
次に、図４〜図７を用いて、本実施例に係るセンシング制御の具体例について説明する。図４及び図６は、対応関係テーブルの構成例を示す図である。図５及び図７は、消費電力の算出結果の一例を示す図である。このうち、図４及び図５には、ＢＬＥセンシングがリクエストされた場合の例が示される一方で、図６及び図７には、ＢＬＥセンシング及び歩行センシングがリクエストされた場合の例が示されている。なお、ここでは、一例として、従来技術の援用におけるセンシング制御と、本実施例に係るセンシング制御とを対比しながら両者の相違点を説明することとする。

（１）ＢＬＥセンシング
例えば、アプリケーションプログラムからＢＬＥセンシングのリクエストが受付部１７ａによって受け付けられた場合を想定する。このとき、例えば、特定部１７ｂによって図４に示す対応関係テーブルが検索される。この結果、ＢＬＥセンシングを実行可能なセンサを管理下に置くドライバとして、ＢＬＥチップ１１ａを制御するＢＬＥドライバ１５Ａと、ＢＬＥチップ１１ｃを制御するセンサマイコンドライバ１５ＣＤとが検索される。本例では、ＢＬＥセンシングだけがリクエストされているので、ＢＬＥドライバ１５Ａと、センサマイコンドライバ１５ＣＤとの２つの各々がドライバの組合せとして導出される。

上記の２つのドライバの組合せのうち、ＢＬＥドライバ１５Ａの組合せについては、ＢＬＥセンシングの実行時における動作デバイスとして、図４に示す対応関係テーブルからＢＬＥチップ１１ａが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ａに対応付けられた動作電力として３ｍＡが取得される。ここで、ＢＬＥドライバ１５Ａの組合せの場合、ＢＬＥチップ１１ａ以外に動作デバイスは存在しない。この結果、ＢＬＥドライバ１５Ａの組合せの場合、図５に示すように、ＢＬＥセンシングの実行時における消費電力が“３ｍＡ”と算出される。

一方、センサマイコンドライバ１５ＣＤの組合せについては、図５に示すように、ＢＬＥセンシングの実行時における動作デバイスとして、図４に示す対応関係テーブルからＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ｃに対応付けられた動作電力として２ｍＡが取得されるとともに、センサマイコン１２ｃｄに対応付けられた動作電力として４ｍＡが取得される。したがって、センサマイコンドライバ１５ＣＤの組合せの場合、図５に示すように、ＢＬＥセンシングの実行時における消費電力が“６ｍＡ（＝２ｍＡ＋４ｍＡ）”と算出される。

このように、ＢＬＥドライバ１５Ａの組合せにおける消費電力が“３ｍＡ”と求まり、センサマイコンドライバ１５ＣＤの組合せにおける消費電力が“６ｍＡ”と求まる。この場合、消費電力がより小さいＢＬＥドライバ１５Ａの組合せが選択される。この結果、ＢＬＥドライバ１５Ａに対し、ＢＬＥチップ１１ａを制御してＢＬＥセンシングを実行する指示が指示部１７ｅによって行われることになる。

したがって、本実施例に係るセンシング制御によれば、ＢＬＥセンシングのリクエストがあった場合、ＢＬＥドライバ１５Ａの組合せよりも消費電力が大きいセンサマイコンドライバ１５ＣＤの組合せにセンシングが指示されることを抑制できる。

（２）ＢＬＥセンシング＋歩行センシング
次に、アプリケーションプログラムからＢＬＥセンシング及び歩行センシングのリクエストが受付部１７ａによって受け付けられた場合を想定する。このとき、例えば、特定部１７ｂによって図６に示す対応関係テーブルが検索される。この結果、ＢＬＥセンシングを実行可能なセンサを管理下に置くドライバとして、ＢＬＥチップ１１ａを制御するＢＬＥドライバ１５Ａと、ＢＬＥチップ１１ｃを制御するセンサマイコンドライバ１５ＣＤとが検索される。これは、上記の（１）と同様である。さらに、歩行センシングを実行可能なセンサを管理下に置くドライバとして、歩行センサ１１ｂを制御する歩行センサドライバ１５Ｂと、歩行センサ１１ｄを制御するセンサマイコンドライバ１５ＣＤとが検索される。

これらのことから、ＢＬＥセンシング及び歩行センシングを実現するドライバの組合せとして、下記の（イ）〜（ニ）のドライバの組合せが導出できる。

（イ）ＢＬＥドライバ１５Ａ＋歩行センサドライバ１５Ｂの組合せ
（ロ）センサマイコンドライバ１５ＣＤ＋歩行センサドライバ１５Ｂの組合せ
（ハ）ＢＬＥドライバ１５Ａ＋センサマイコンドライバ１５ＣＤの組合せ
（ニ）センサマイコンドライバ１５ＣＤ＋センサマイコンドライバ１５ＣＤの組合せ

このうち、（イ）のドライバの組合せについては、ＢＬＥセンシングの実行時における動作デバイスとして、図６に示す対応関係テーブルからＢＬＥチップ１１ａが特定されるとともに、歩行センシングの実行時における動作デバイスとして、図６に示す対応関係テーブルから歩行センサ１１ｂ及びＣＰＵ１４が特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ａの動作電力として３ｍＡが取得され、歩行センサ１１ｂの動作電力として１ｍＡが取得され、さらに、ＣＰＵ１４の動作電力として２０ｍＡが取得される。したがって、（イ）のドライバの組合せの場合、図７に示すように、ＢＬＥセンシング及び歩行センシングの実行時における消費電力が“２４ｍＡ（＝１ｍＡ＋３ｍＡ＋２０ｍＡ）”と算出される。

また、（ロ）のドライバの組合せについては、ＢＬＥセンシングの実行時における動作デバイスとして、図６に示す対応関係テーブルからＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄが特定されるとともに、歩行センシングの実行時における動作デバイスとして、図６に示す対応関係テーブルから歩行センサ１１ｂ及びＣＰＵ１４が特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ｃの動作電力として２ｍＡが取得され、センサマイコン１２ｃｄの動作電力として４ｍＡが取得され、歩行センサ１１ｂの動作電力として１ｍＡが取得され、さらに、ＣＰＵ１４の動作電力として２０ｍＡが取得される。したがって、（ロ）のドライバの組合せの場合、図７に示すように、ＢＬＥセンシング及び歩行センシングの実行時における消費電力が“２７ｍＡ（＝２ｍＡ＋４ｍＡ＋１ｍＡ＋２０ｍＡ）”と算出される。

また、（ハ）のドライバの組合せについては、ＢＬＥセンシングの実行時における動作デバイスとして、図６に示す対応関係テーブルからＢＬＥチップ１１ａが特定されるとともに、歩行センシングの実行時における動作デバイスとして、図６に示す対応関係テーブルから歩行センサ１１ｄ及びセンサマイコン１２ｃｄが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ａの動作電力として３ｍＡが取得され、歩行センサ１１ｄの動作電力として１ｍＡが取得され、さらに、センサマイコン１２ｃｄの動作電力として４ｍＡが取得される。したがって、（ハ）のドライバの組合せの場合、図７に示すように、ＢＬＥセンシング及び歩行センシングの実行時における消費電力が“８ｍＡ（＝３ｍＡ＋１ｍＡ＋４ｍＡ）”と算出される。

また、（ニ）のドライバの組合せについては、ＢＬＥセンシングの実行時における動作デバイスとして、図６に示す対応関係テーブルからＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄが特定されるとともに、歩行センシングの実行時における動作デバイスとして、図６に示す対応関係テーブルから歩行センサ１１ｄ及びセンサマイコン１２ｃｄが特定される。ここで、（ニ）のドライバの組合せの場合、ＢＬＥセンシングの実行時及び歩行センシングの実行時の両方でセンサマイコン１２ｃｄが動作デバイスとして重複して特定される。このように動作デバイスが重複して特定される場合には、一方が削除して特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ｃの動作電力として２ｍＡが取得され、歩行センサ１１ｄの動作電力として１ｍＡが取得され、さらに、センサマイコン１２ｃｄの動作電力として４ｍＡが取得される。したがって、（ニ）のドライバの組合せの場合、図７に示すように、ＢＬＥセンシング及び歩行センシングの実行時における消費電力が“７ｍＡ（＝２ｍＡ＋１ｍＡ＋４ｍＡ）”と算出される。

このように、（イ）のドライバの組合せにおける消費電力が“２４ｍＡ”と求まり、（ロ）のドライバの組合せにおける消費電力が“２７ｍＡ”と求まり、（ハ）のドライバの組合せにおける消費電力が“８ｍＡ”と求まり、（ニ）のドライバの組合せにおける消費電力が“７ｍＡ”と求まる。この場合、消費電力が最小である（ニ）のドライバの組合せが選択される。この結果、センサマイコンドライバ１５ＣＤに対し、ＢＬＥチップ１１ｃ、歩行センサ１１ｄ及びセンサマイコン１２ｃｄを制御してＢＬＥセンシング及び歩行センシングを実行する指示が指示部１７ｅによって行われることになる。

したがって、本実施例に係るセンシング制御によれば、ＢＬＥセンシング及び歩行センシングのリクエストがあった場合でも、（ニ）のドライバの組合せよりも消費電力が大きい（イ）、（ロ）及び（ハ）のドライバの組合せにセンシングが指示されることを抑制できる。

（３）従来技術との対比
一方、従来技術の一例として、メディアファイルまたはストリームに対する各種の操作を行うためのプラットフォームを想定する。かかるプラットフォームでは、例えば、メディアファイルをデコードするモジュールが複数存在する場合に、モジュール別に設定された優先度にしたがっていずれのモジュールをデコードに用いるのかを選択するものである。

ここで、上記の従来技術を動作デバイスの選択に援用する場合、例えば、ＢＬＥセンシングについてはＢＬＥチップ１１ａ及びＢＬＥチップ１１ｃのいずれかを優先する設定がなされることなる。このようにいずれかのデバイスを優先する設定がなされる場合、アプリケーションプログラムからリクエストされるセンシングの内容によっては省電力化が実現できない場合がある。

例えば、ＢＬＥチップ１１ａを優先すると仮定したとき、ＢＬＥセンシング及び歩行センシングのリクエストがあった場合に、（イ）のドライバの組合せまたは（ハ）のドライバの組合せが選択されることになる。よって、従来技術に係るセンシング制御では、本実施例に係るセンシング制御のように、（ニ）のドライバの組合せを選択することはできず、省電力化は実現できない。一方、ＢＬＥチップ１１ｃを優先すると仮定したとしても、ＢＬＥセンシングだけがリクエストされた場合に、ＢＬＥチップ１１ｃを制御するセンサマイコンドライバ１５ＣＤの組合せが選択されることになる。よって、従来技術に係るセンシング制御では、本実施例に係るセンシング制御のように、ＢＬＥドライバ１５Ａの組合せを選択することはできず、省電力化は実現できない。

一方、本実施例に係るセンシング制御では、アプリケーションプログラムからリクエストされるセンシングがＢＬＥセンシングだけであっても、あるいはＢＬＥセンシング及び歩行センシングであっても、センシングの省電力化を実現できる。以上のことから、本実施例に係るセンシング制御によれば、アプリケーションプログラムからリクエストされるセンシングの内容に依存せずにセンシングの省電力化を実現できるので、従来技術に係るセンシング制御よりも省電力化の効果が高いことがわかる。

［処理の流れ］
次に、本実施例に係る携帯端末装置の処理の流れについて説明する。図８は、実施例１に係るセンシング制御の手順を示すフローチャートである。この処理は、アプリケーションプログラムからセンシングの実行指示を受け付けた場合に実行される。

図８に示すように、特定部１７ｂは、アプリケーションプログラムからリクエストを受け付けたセンシングを実現するドライバの組合せを導出する（ステップＳ１０１）。

続いて、特定部１７ｂは、ステップＳ１０１で導出されたドライバの組合せのうちドライバの組合せを１つ選択する（ステップＳ１０２）。そして、特定部１７ｂは、ステップＳ１０２で選択されたドライバの組合せからセンシングの実行時に動作させるデバイスを特定する（ステップＳ１０３）。

その後、算出部１７ｃは、記憶部１３に記憶された動作電力データ１３ａを参照して、ステップＳ１０３で特定された各デバイスがセンシングで消費する電力を算出する（ステップＳ１０４）。

ここで、選択部１７ｄは、ステップＳ１０４で算出された消費電力と、内部メモリに保存された消費電力の最小値とを比較する（ステップＳ１０５）。このとき、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値よりも小さい場合、すなわち消費電力＜最小値である場合（ステップＳ１０５Ｙｅｓ）、選択部１７ｄは、ステップＳ１０４で算出された消費電力を内部メモリに上書き保存する（ステップＳ１０６）。一方、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値以上である場合、すなわち消費電力≧最小値である場合（ステップＳ１０５Ｎｏ）には、内部メモリへの上書き保存は実行されず、ステップＳ１０７の処理へ移行する。

そして、全ての組合せにわたって消費電力と最小値との比較が実行されるまで（ステップＳ１０７Ｎｏ）、上記のステップＳ１０２〜ステップＳ１０６までの処理が繰返し実行される。

その後、全ての組合せにわたって消費電力と最小値との比較が実行されると（ステップＳ１０７Ｙｅｓ）、選択部１７ｄは、内部メモリに保存された最小値がセンシングの実行時における消費電力として算出されていたドライバの組合せを選択する（ステップＳ１０８）。これを受けて、指示部１７ｅは、ステップＳ１０８で選択された組合せに含まれるドライバに対し、動作デバイスを制御してセンシングを実行する指示を行い（ステップＳ１０９）、処理を終了する。

なお、図８に示したフローチャートでは、上記のステップＳ１０２〜ステップＳ１０６の処理を繰返し実行することとしたが、ステップＳ１０２〜ステップＳ１０４の処理を並行して実行し、その後、消費電力が最小であるドライバの組合せを選択することとしてもかまわない。

［効果の一側面］
上述してきたように、本実施例に係る携帯端末装置１０は、同一のセンシングを実現できる複数通りのセンサの組合せごとにセンシングの実行時に動作させるデバイスの消費電力を算出し、デバイスの消費電力が最小である組合せを選択する。したがって、本実施例に係る携帯端末装置１０によれば、センシングの消費電力を抑制できる。

さて、上記の実施例１では、１つのアプリケーションプログラムからリクエストを受け付けた場合を例示したが、複数のアプリケーションプログラムからセンシングのリクエストを受け付けることもできる。そこで、本実施例では、一例として、複数のアプリケーションプログラムからセンシングのリクエストを受け付ける場合について説明する。

［携帯端末装置２０の構成］
図９は、実施例２に係る携帯端末装置２０の機能的構成を示すブロック図である。図９に示す携帯端末装置２０は、図１に示した携帯端末装置１０に比べて、制御部２２がアプリ実行部１６の代わりにアプリ実行部２３ａ及び２３ｂを複数有する他、記憶部２１が記憶するデータの内容と、制御部２２が実行する処理内容とに相違点がある。なお、以下では、図１に示す機能部と同様の機能を発揮する機能部には同一の符号を付し、その説明を省略することとする。

アプリ実行部２３ａ及びアプリ実行部２３ｂは、図１に示したアプリ実行部１６と同様、各種のアプリケーションプログラムを実行する処理部である。これらアプリ実行部２３ａ及びアプリ実行部２３ｂの各々では、マルチタスクにより複数のアプリケーションプログラムが並行して実行される。以下では、アプリ実行部２３ａ及びアプリ実行部２３ｂを総称する場合に「アプリ実行部２３」と記載する場合がある。なお、図９には、２つのアプリ実行部を例示したが、３つ以上のアプリケーションプログラムが並行して実行されることとしてもよく、動作するアプリケーションプログラムの数に応じてアプリ実行部２３の数が増減する。

図１０は、実施例２に係るミドルウェア実行部２５の機能的構成を示すブロック図である。図１０に示すミドルウェア実行部２５は、図２に示したミドルウェア実行部１７に比べて、受付部２５ａ及び特定部２５ｂの処理内容に相違点がある。

受付部２５ａは、図１に示した受付部１７ａと同様、アプリケーションプログラムから各種の指示を受け付けるが、上記の実施例１で例示したセンシングの実行指示だけでなく、センシングの停止指示も受け付ける。

一実施形態として、受付部２５ａは、アプリ実行部２３が実行するアプリケーションプログラムからセンシングの実行指示またはセンシングの停止指示を受け付けた場合に、記憶部２１に記憶されたリクエストデータ２１ａを更新する。かかるリクエストデータ２１ａには、携帯端末装置２０で動作するアプリケーションがリクエスト中であるセンシングがリスト化された一覧を採用できる。例えば、受付部２５ａは、センシングの実行指示を受け付けた場合、当該実行指示を受け付けたセンシングをリクエストデータ２１ａに追加して登録する。また、受付部２５ａは、センシングの停止指示を受け付けた場合、当該停止指示を受け付けたセンシングをリクエストデータ２１ａから削除する。

特定部２５ｂは、図１に示した特定部１７ｂと同様、動作デバイスを特定するが、記憶部２１に記憶されたリクエストデータ２１ａが更新される度に、リクエストデータ２１ａにしたがってドライバの組合せごとに動作デバイスを特定する点が異なる。

［具体例］
次に、図１１を用いて、本実施例に係るセンシング制御の具体例について説明する。図１１は、リクエストデータ２１ａの遷移例を示す図である。図１１には、時刻ｔ０、時刻ｔ１、時刻ｔ２におけるリクエストデータ２１ａが例示されている。なお、図１１に示す「ｔ０」、「ｔ１」及び「ｔ２」の関係は、「ｔ０＜ｔ１＜ｔ２」であることとする。

図１１に示すように、時刻ｔ０でアプリケーションプログラムＸから歩行センシングがリクエストされていた状態から時刻ｔ１になってアプリケーションプログラムＹからＢＬＥセンシングがさらにリクエストされた状態に遷移する。この場合、ＢＬＥセンシング及び歩行センシングを実現するドライバの組合せの中から動作デバイスの消費電力が最小であるドライバの組合せを選択するセンシング制御が実行される。かかるセンシング制御の過程及び結果は、上記の実施例１の具体例（２）と同様となる。すなわち、（イ）〜（ニ）のドライバの組合せが導出された後に、消費電力が最小である（ニ）のドライバの組合せが選択されることになる。

その後、時刻ｔ２になってアプリケーションプログラムＸから歩行センシングの停止指示が受け付けられた状態に遷移する。この場合、ＢＬＥセンシングを実現するドライバの組合せの中から動作デバイスの消費電力が最小であるドライバの組合せを選択するセンシング制御が実行される。かかるセンシング制御の過程及び結果は、上記の実施例１の具体例（１）と同様となる。すなわち、ＢＬＥドライバ１５Ａの組合せ及びセンサマイコンドライバ１５ＣＤの組合せが導出された後に、消費電力が最小であるＢＬＥドライバ１５Ａの組合せが選択されることになる。

このように、本実施例に係るセンシング制御は、アプリケーションプログラムからリクエストされるセンシングの内容の変化に合わせてドライバの組合せを再選択する。すなわち、１つのアプリケーションプログラムによってセンシングの実行指示が行われている場合でも、複数のアプリケーションプログラムによってセンシングの実行指示が行われている場合、あるいは一部のアプリケーションプログラムによってセンシングの実行指示が行われた場合でも、消費電力が最小であるドライバの組合せを選択できる。この結果、本実施例に係るセンシング制御では、例えば、携帯端末装置２０で複数のアプリケーションプログラムが動作する場合でも、センシングの消費電力を抑制できる。

［処理の流れ］
次に、本実施例に係る携帯端末装置２０の処理の流れについて説明する。ここでは、携帯端末装置２０が実行する（１）第１のセンシング制御を説明した後に、（２）第２のセンシング制御を説明することとする。

（１）第１のセンシング制御
図１２は、実施例２に係る第１のセンシング制御の手順を示すフローチャートである。この処理は、アプリケーションプログラムからセンシングの実行指示を受け付けた場合に実行される。なお、図８に示したセンシング制御と同一の処理が実行されるステップには、同一の番号が付与されている。

図１２に示すように、アプリケーションプログラムからセンシングの実行指示が受け付けられた場合（ステップＳ２０１）、受付部２５ａは、ステップＳ２０１で実行指示が受け付けられたセンシングをリクエストデータ２１ａに追加して登録する（ステップＳ２０２）。

続いて、特定部２５ｂは、ステップＳ２０２で追加登録が行われた後のリクエストデータ２１ａにしたがってセンシングを実現するドライバの組合せを導出する（ステップＳ２０３）。

続いて、特定部２５ｂは、ステップＳ２０３で導出されたドライバの組合せのうちドライバの組合せを１つ選択する（ステップＳ１０２）。そして、特定部２５ｂは、ステップＳ１０２で選択されたドライバの組合せからセンシングの実行時に動作させるデバイスを特定する（ステップＳ１０３）。

その後、算出部１７ｃは、記憶部１３に記憶された動作電力データ１３ａを参照して、ステップＳ１０３で特定された各デバイスがセンシングで消費する電力を算出する（ステップＳ１０４）。

ここで、選択部１７ｄは、ステップＳ１０４で算出された消費電力と、内部メモリに保存された消費電力の最小値とを比較する（ステップＳ１０５）。このとき、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値よりも小さい場合、すなわち消費電力＜最小値である場合（ステップＳ１０５Ｙｅｓ）、選択部１７ｄは、ステップＳ１０４で算出された消費電力を内部メモリに上書き保存する（ステップＳ１０６）。一方、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値以上である場合、すなわち消費電力≧最小値である場合（ステップＳ１０５Ｎｏ）には、内部メモリへの上書き保存は実行されず、ステップＳ１０７の処理へ移行する。

そして、全ての組合せにわたって消費電力と最小値との比較が実行されるまで（ステップＳ１０７Ｎｏ）、上記のステップＳ１０２〜ステップＳ１０６までの処理が繰返し実行される。

その後、全ての組合せにわたって消費電力と最小値との比較が実行されると（ステップＳ１０７Ｙｅｓ）、選択部１７ｄは、内部メモリに保存された最小値がセンシングの実行時における消費電力として算出されていたドライバの組合せを選択する（ステップＳ１０８）。これを受けて、指示部１７ｅは、ステップＳ１０８で選択された組合せに含まれるドライバに対し、動作デバイスを制御してセンシングを実行する指示を行い（ステップＳ１０９）、処理を終了する。

（２）第２のセンシング制御
図１３は、実施例２に係る第２のセンシング制御の手順を示すフローチャートである。この処理は、アプリケーションプログラムからセンシングの停止指示を受け付けた場合に実行される。なお、図８に示したセンシング制御と同一の処理が実行されるステップには、同一の番号が付与されている。

図１３に示すように、アプリケーションプログラムからセンシングの停止指示が受け付けられた場合（ステップＳ３０１）、受付部２５ａは、ステップＳ３０１で停止指示が受け付けられたセンシングをリクエストデータ２１ａから削除する（ステップＳ３０２）。

続いて、特定部２５ｂは、ステップＳ３０２で削除が行われた後のリクエストデータ２１ａにしたがってセンシングを実現するドライバの組合せを導出する（ステップＳ３０３）。

続いて、特定部２５ｂは、ステップＳ３０３で導出されたドライバの組合せのうちドライバの組合せを１つ選択する（ステップＳ１０２）。そして、特定部２５ｂは、ステップＳ１０２で選択されたドライバの組合せからセンシングの実行時に動作させるデバイスを特定する（ステップＳ１０３）。

その後、算出部１７ｃは、記憶部１３に記憶された動作電力データ１３ａを参照して、ステップＳ１０３で特定された各デバイスがセンシングで消費する電力を算出する（ステップＳ１０４）。

ここで、選択部１７ｄは、ステップＳ１０４で算出された消費電力と、内部メモリに保存された消費電力の最小値とを比較する（ステップＳ１０５）。このとき、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値よりも小さい場合、すなわち消費電力＜最小値である場合（ステップＳ１０５Ｙｅｓ）、選択部１７ｄは、ステップＳ１０４で算出された消費電力を内部メモリに上書き保存する（ステップＳ１０６）。一方、ステップＳ１０４で算出された消費電力が内部メモリに保存された最小値以上である場合、すなわち消費電力≧最小値である場合（ステップＳ１０５Ｎｏ）には、内部メモリへの上書き保存は実行されず、ステップＳ１０７の処理へ移行する。

そして、全ての組合せにわたって消費電力と最小値との比較が実行されるまで（ステップＳ１０７Ｎｏ）、上記のステップＳ１０２〜ステップＳ１０６までの処理が繰返し実行される。

その後、全ての組合せにわたって消費電力と最小値との比較が実行されると（ステップＳ１０７Ｙｅｓ）、選択部１７ｄは、内部メモリに保存された最小値がセンシングの実行時における消費電力として算出されていたドライバの組合せを選択する（ステップＳ１０８）。

これを受けて、指示部１７ｅは、ステップＳ１０８で選択された組合せに含まれるドライバに対し、動作デバイスを制御してセンシングを実行する指示を行う（ステップＳ１０９）とともに、ステップＳ１０８で選択されたドライバの組合せに含まれなくなったドライバに対し、センシングを停止する指示を行い（ステップＳ３０４）、処理を終了する。

なお、図１３に示したフローチャートでは、上記のステップＳ１０９の処理を実行してから上記のステップＳ３０４の処理を実行する場合を例示したが、処理順序を入れ替えることとしてもよいし、両者の処理を並行して実行することもできる。

［効果の一側面］
上述してきたように、本実施例に係る携帯端末装置２０は、上記の実施例１に係る携帯端末装置１０と同様、同一のセンシングを実現できる複数通りのセンサの組合せごとにセンシングの実行時に動作させるデバイスの消費電力を算出し、デバイスの消費電力が最小である組合せを選択する。したがって、本実施例に係る携帯端末装置２０によれば、センシングの消費電力を抑制できる。

さらに、本実施例に係る携帯端末装置２０は、アプリケーションプログラムからリクエストされるセンシングの内容の変化に合わせてドライバの組合せを再選択する。それ故、本実施例に係る携帯端末装置２０では、携帯端末装置２０で複数のアプリケーションプログラムが動作する場合でも、センシングの消費電力を抑制できる。

さて、上記の実施例１では、リクエストデータ２１ａが更新される度にドライバの組合せが再選択される場合を例示したが、必ずしもドライバの組合せを再選択せずともかまわない。そこで、本実施例では、一例として、センシングのリクエストに追加があった場合に、リクエストの追加分のセンシングに関するドライバの組合せを追加して選択する場合について説明する。

［携帯端末装置３０の構成］
図１４は、実施例３に係る携帯端末装置３０の機能的構成を示すブロック図である。図１４に示す携帯端末装置３０は、図９に示した携帯端末装置２０に比べて、記憶部３１が記憶するデータの内容と、制御部３２が実行する処理内容とに相違点がある。なお、以下では、図１に示す機能部と同様の機能を発揮する機能部には同一の符号を付し、その説明を省略することとする。

図１５は、実施例３に係るミドルウェア実行部３３の機能的構成を示すブロック図である。図１５に示すミドルウェア実行部３３は、図１０に示したミドルウェア実行部２５に比べて、特定部３３ａ、算出部３３ｂ及び選択部３３ｃの処理内容に相違点がある。

特定部３３ａは、図１０に示した特定部２５ｂと同様、動作デバイスを特定する処理部であるが、記憶部３１に記憶されたリクエストデータ２１ａにアプリケーションプログラムからの実行指示に対応するリクエストが追加された場合に実行される処理内容が異なる。

一実施形態として、特定部３３ａは、リクエストデータ２１ａにセンシングのリクエストが追加された場合に、リクエストデータ２１ａの更新の前後で追加されたリクエストを特定する。以下では、リクエストデータ２１ａの更新の前後で追加されたリクエストのことを「追加リクエスト」と記載するとともに、追加リクエストに伴って追加して実行されるセンシングのことを「追加センシング」と記載する場合がある。その上で、特定部３３ａは、追加リクエストに関するセンシングを実現するドライバの組合せを導出する。以下では、全リクエストに関するセンシングを実現するドライバの組合せと区別する観点から、追加リクエストに関するセンシングを実現するドライバの組合せのことを「追加ドライバの組合せ」と記載する場合がある。その後、特定部３３ａは、追加ドライバの組合せのうち追加ドライバの組合せを１つ選択する。続いて、特定部３３ａは、先に選択された追加ドライバの組合せから追加リクエストのセンシングの実行時に動作させるデバイスを特定する。以下では、追加リクエストのセンシングの実行時に動作させるデバイスのことを「追加動作デバイス」と記載する場合がある。なお、追加ドライバの組合せの導出や動作デバイスの特定についても、上記の問合せまたは上記の検索によって同様に実行できる。

算出部３３ｂは、図１０に示した算出部１７ｃと同様、動作デバイスがセンシングにより消費する電力を組合せごとに算出するが、全ての動作デバイスの消費電力の代わりに、追加動作デバイスにより消費が増加する分の電力を算出する点が異なる。

一実施形態として、算出部３３ｂは、各追加動作デバイスの動作電力を合計することによって追加動作デバイスによる消費電力の増分を算出するが、追加リクエストを受け付ける前から動作されていた動作デバイスの動作電力は合計に加えない、もしくは合計から差し引く。例えば、算出部３３ｂは、記憶部３１に記憶された動作状態データ３１ａに含まれるデバイスのうち追加動作デバイスと同一のデバイスに対応する動作電力を、各追加動作デバイスの動作電力の合計値から減算する。かかる動作状態データ３１ａには、一例として、携帯端末装置３０の制御下にあるデバイスと、デバイスが動作しているか否かを示す動作状態とが対応付けられたデータを採用できる。これによって、追加ドライバの組合せごとに追加動作デバイスによる消費電力の増分が算出されることになる。

選択部３３ｃは、図１０に示した選択部１７ｄと同様、センシングの実行時における消費電力が最小である組合せを選択するが、全てのセンシングの代わりに、追加センシングの実行時における消費電力の増分が最小である組合せを選択する点が異なる。

一実施形態として、選択部３３ｃは、算出部３３ｂによって消費電力の増分が算出される度に、それまでに算出された消費電力の増分のうち最小増分値が保存される内部メモリを参照し、互いの消費電力の大小を比較する。このとき、選択部３３ｃは、算出部３３ｂによって算出された消費電力の増分が内部メモリに保存された最小増分値よりも小さい場合、すなわち増分＜最小増分値である場合、算出部３３ｂによって算出された消費電力の増分を内部メモリに上書き保存する。一方、算出部３３ｃによって算出された消費電力の増分が内部メモリに保存された最小増分値以上である場合、すなわち増分≧最小増分値である場合には、内部メモリへの上書き保存は実行されない。また、内部メモリに最小増分値が保存されていない場合には、算出部３３ｂによって算出された消費電力の増分が最小増分値としてそのまま保存される。その後、選択部３３ｃは、全ての組合せにわたって消費電力の増分が算出された後に、内部メモリに保存された最小増分値がセンシングの実行時における消費電力の増分として算出されていた追加ドライバの組合せを選択する。

［具体例］
次に、図１６〜図１９を用いて、本実施例に係るセンシング制御の具体例について説明する。図１６及び図１８は、動作状態データ３１ａの遷移例を示す図である。図１７及び図１９は、消費電力の増分に関する算出結果の一例を示す図である。このうち、図１６及び図１７には、歩行センシングのリクエスト中にＢＬＥセンシングが追加してリクエストされた場合の例が示される一方で、図１８及び図１９には、ＢＬＥセンシングのリクエスト中に歩行センシングが追加してリクエストされた場合の例が示されている。

（１）ＢＬＥセンシングの追加リクエスト
例えば、時刻ｔ０に追加されたリクエストがＢＬＥセンシングである場合を想定する。この場合、上記の実施例１の具体例（１）と同様に、追加ドライバの組合せとして、図４に示した対応関係テーブルにしたがってＢＬＥドライバ１５Ａの組合せ及びセンサマイコンドライバ１５ＣＤの組合せが導出される。

このうち、ＢＬＥドライバ１５Ａの組合せに関する追加動作デバイスとして、図４に示した対応関係テーブルにしたがってＢＬＥチップ１１ａが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ａに対応付けられた動作電力として３ｍＡが取得される。ここで、図１６に示す時刻ｔ０の動作状態データ３１ａのうち追加動作デバイスに対応するＢＬＥチップ１１ａには、動作状態として「×」が設定されている。このため、ＢＬＥチップ１１ａは、追加前からの動作デバイスと重複しないので、ＢＬＥチップ１１ａの動作電力は相殺されず、追加動作デバイスによる消費電力の増分としてそのまま計上される。この結果、ＢＬＥドライバ１５Ａの組合せの場合、図１７に示すように、追加センシングの実行時における消費電力の増分が“３ｍＡ”と算出される。

また、センサマイコンドライバ１５ＣＤの組合せに関する追加動作デバイスとして、図４に示した対応関係テーブルにしたがってＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、ＢＬＥチップ１１ｃの動作電力として２ｍＡが取得されるとともに、センサマイコン１２ｃｄの動作電力として４ｍＡが取得される。ここで、図１６に示す時刻ｔ０の動作状態データ３１ａから追加動作デバイスに対応するＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄが検索される。このうち、ＢＬＥチップ１１ｃの動作状態には、「×」が設定されているが、リクエスト中の歩行センシングによって、センサマイコン１２ｃｄの動作状態には、「○」が設定されている。このため、ＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄの動作電力の合計値から、センサマイコン１２ｃｄの動作電力が差し引かれる。この結果、センサマイコンドライバ１５ＣＤの組合せの場合、図１７に示すように、追加センシングの実行時における消費電力の増分が“２ｍＡ（＝２ｍＡ＋４ｍＡ−４ｍＡ）”と算出される。

このように、ＢＬＥドライバ１５Ａの組合せにおける消費電力の増分が“３ｍＡ”と求まり、センサマイコンドライバ１５ＣＤの組合せにおける消費電力の増分が“２ｍＡ”と求まる。この場合、消費電力の増分がより小さいセンサマイコンドライバ１５ＣＤの組合せが選択される。この結果、センサマイコンドライバ１５ＣＤに対し、ＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄを制御してＢＬＥセンシングを実行する指示が指示部１７ｅによって行われることになる。これに伴って、図１６に示す時刻ｔ１の動作状態データ３１ａのように、ＢＬＥチップ１１ｃ及びセンサマイコン１２ｃｄの動作状態が「○」に更新される。

（２）歩行センシングの追加リクエスト
例えば、時刻ｔ０に追加されたリクエストがＢＬＥセンシングである場合を想定する。この場合、上記の実施例１の具体例（２）と同様に、追加ドライバの組合せとして、図６に示した対応関係テーブルにしたがって歩行センサドライバ１５Ｂの組合せ及びセンサマイコンドライバ１５ＣＤの組合せが導出される。

このうち、歩行センサドライバ１５Ｂの組合せに関する追加動作デバイスとして、図６に示した対応関係テーブルにしたがって歩行センサ１１ｂ及びＣＰＵ３２が特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、歩行センサ１１ｂの動作電力として１ｍＡが取得されるとともに、ＣＰＵ３２の動作電力として２０ｍＡが取得される。ここで、図１８に示す時刻ｔ０の動作状態データ３１ａのうち追加動作デバイスに対応する歩行センサ１１ｂ及びＣＰＵ３２には、いずれも動作状態として「×」が設定されている。このため、歩行センサ１１ｂ及びＣＰＵ３２は、追加前からの動作デバイスと重複しないので、歩行センサ１１ｂ及びＣＰＵ３２の動作電力の合計値は相殺されず、追加動作デバイスによる消費電力の増分としてそのまま計上される。この結果、歩行センサドライバ１５Ｂの組合せの場合、図１９に示すように、追加センシングの実行時における消費電力の増分が“２１ｍＡ”と算出される。

また、センサマイコンドライバ１５ＣＤの組合せに関する追加動作デバイスとして、図６に示した対応関係テーブルにしたがって歩行センサ１１ｄ及びセンサマイコン１２ｃｄが特定される。続いて、図３に示した動作電力データ１３ａを参照することによって、歩行センサ１１ｄの動作電力として１ｍＡが取得されるとともに、センサマイコン１２ｃｄの動作電力として４ｍＡが取得される。ここで、図１８に示す時刻ｔ０の動作状態データ３１ａから追加動作デバイスに対応する歩行センサ１１ｄ及びセンサマイコン１２ｃｄが検索される。ところが、歩行センサ１１ｄ及びセンサマイコン１２ｃｄには、いずれも動作状態として「×」が設定されている。このため、歩行センサ１１ｄ及びセンサマイコン１２ｃｄは、追加前からの動作デバイスと重複しないので、歩行センサ１１ｄ及びセンサマイコン１２ｃｄの動作電力の合計値は相殺されず、追加動作デバイスによる消費電力の増分としてそのまま計上される。この結果、センサマイコンドライバ１５ＣＤの組合せの場合、図１９に示すように、追加センシングの実行時における消費電力の増分が“５ｍＡ”と算出される。

このように、歩行センサドライバ１５Ｂの組合せにおける消費電力の増分が“２１ｍＡ”と求まり、センサマイコンドライバ１５ＣＤの組合せにおける消費電力の増分が“５ｍＡ”と求まる。この場合、消費電力の増分がより小さいセンサマイコンドライバ１５ＣＤの組合せが選択される。この結果、センサマイコンドライバ１５ＣＤに対し、歩行センサ１１ｄ及びセンサマイコン１２ｃｄを制御して歩行センシングを実行する指示が指示部１７ｅによって行われることになる。これに伴って、図１８に示す時刻ｔ１の動作状態データ３１ａのように、歩行センサ１１ｄ及びセンサマイコン１２ｃｄの動作状態が「○」に更新される。

（３）技術的意義の一側面
上記の具体例（１）及び（２）のように、本実施例に係るセンシング制御では、追加リクエストを受け付けた時点で動作中のデバイスをそのまま動作させながら、追加ドライバの組合せのうち消費電力の増分が最小である組合せを選択する。それ故、本実施例に係るセンシング制御によれば、例えば、追加リクエストを受け付けることによって動作デバイスが頻繁に切り替わり、携帯端末装置３０の動作が不安定になるのを抑制できる。

［処理の流れ］
図２０は、実施例３に係るセンシング制御の手順を示すフローチャートである。この処理は、アプリケーションプログラムからセンシングの実行指示を受け付けた場合に実行される。なお、図１２に示した第１のセンシング制御と同一の処理が実行されるステップには、同一の番号が付与されている。

図２０に示すように、アプリケーションプログラムからセンシングの実行指示が受け付けられた場合（ステップＳ２０１）、受付部２５ａは、ステップＳ２０１で実行指示が受け付けられたセンシングをリクエストデータ２１ａに追加して登録する（ステップＳ２０２）。

続いて、特定部３３ａは、ステップＳ２０２のリクエストデータ２１ａの更新の前後で追加されたリクエストを特定する（ステップＳ４０１）。その上で、特定部３３ａは、ステップＳ４０１で特定された追加リクエストに関するセンシングを実現する追加ドライバの組合せを導出する（ステップＳ４０２）。

その後、算出部３３ｂは、記憶部３１に記憶された動作状態データ３１ａを読み出し（ステップＳ４０３）、特定部３３ａは、ステップＳ４０２で導出された追加ドライバの組合せのうち追加ドライバの組合せを１つ選択する（ステップＳ４０４）。続いて、特定部３３ａは、ステップＳ４０４で選択された追加ドライバの組合せから追加リクエストのセンシングの実行時に動作させるデバイスを特定する（ステップＳ４０５）。

そして、算出部３３ｂは、ステップＳ４０３で読み出した動作状態データ３１ａを参照して、追加動作デバイスによる消費電力の増分を算出する（ステップＳ４０６）。

ここで、選択部３３ｃは、ステップＳ４０６で算出された消費電力の増分と、内部メモリに保存された消費電力の最小増分値とを比較する（ステップＳ４０７）。このとき、ステップＳ４０６で算出された消費電力の増分が内部メモリに保存された最小増分値よりも小さい場合、すなわち増分＜最小増分値である場合（ステップＳ４０７Ｙｅｓ）、選択部３３ｃは、ステップＳ４０６で算出された消費電力の増分を内部メモリに上書き保存する（ステップＳ４０８）。一方、ステップＳ４０６で算出された消費電力の増分が内部メモリに保存された最小増分値以上である場合、すなわち消費電力≧最小値である場合（ステップＳ４０７Ｎｏ）には、内部メモリへの上書き保存は実行されず、ステップＳ４０９の処理へ移行する。

そして、全ての組合せにわたって増分と最小増分値との比較が実行されるまで（ステップＳ４０９Ｎｏ）、上記のステップＳ４０４〜ステップＳ４０８までの処理が繰返し実行される。

その後、全ての組合せにわたって増分と最小増分値との比較が実行されると（ステップＳ４０９Ｙｅｓ）、選択部３３ｃは、内部メモリに保存された最小増分値が追加センシングの実行時における消費電力の増分として算出されていた追加ドライバの組合せを選択する（ステップＳ４１０）。そして、選択部３３ｃは、動作状態データ３１ａのうちステップＳ４１０で選択された追加ドライバの組合せに対応する追加動作デバイスの動作状態を動作中に更新する（ステップＳ４１１）。

さらに、指示部１７ｅは、ステップＳ４１０で選択された組合せに含まれる追加ドライバに対し、追加動作デバイスを制御してセンシングを実行する指示を行い（ステップＳ４１２）、処理を終了する。

［効果の一側面］
上述してきたように、本実施例に係る携帯端末装置３０は、上記の実施例１に係る携帯端末装置１０と同様、同一のセンシングを実現できる複数通りのセンサの組合せごとにセンシングの実行時に動作させるデバイスの消費電力を算出し、デバイスの消費電力が最小である組合せを選択する。したがって、本実施例に係る携帯端末装置３０によれば、センシングの消費電力を抑制できる。

さらに、本実施例に係る携帯端末装置３０は、追加リクエストを受け付けた時点で動作中のデバイスをそのまま動作させながら、追加ドライバの組合せのうち消費電力の増分が最小である追加ドライバの組合せを選択する。それ故、本実施例に係る携帯端末装置３０によれば、例えば、追加リクエストを受け付けることによって動作デバイスが頻繁に切り替わり、携帯端末装置３０の動作が不安定になるのを抑制できる。

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

［外部装置の搭載センサの利用］
上記の実施例１〜実施例３では、携帯端末装置１０〜３０が製品出荷時から搭載するセンサを例示したが、外部装置が搭載するセンサをセンシングに用いることもできる。例えば、歩数計や血圧計を持つ「スマートウォッチ」、加速度センサを持つ「指輪ガジェット」などのウェアラブルガジェットを有線または無線によって接続することによって携帯端末装置１０〜３０の制御下に加えることができる。この場合、ウェアラブルガジェット等の接続または接続解除が検出される度に、図１２及び図１３と同様の処理を携帯端末装置２０に実行させるたり、図２０と同様の処理を携帯端末装置３０に実行させたりすることができる。

［動作時間］
上記の実施例１〜実施例３では、消費電力を基準にドライバの組合せを選択する場合を例示したが、他の項目、例えば動作時間などをさらに選択基準に加えることもできる。例えば、携帯端末装置本体のバッテリと、携帯端末装置に接続されるガジェットのバッテリとが存在する場合を想定する。この場合、携帯端末装置は、デバイスとデバイスが電源とするバッテリとが対応付けられた電源データを用いて、バッテリごとに当該バッテリで動作するデバイスの消費電力の総和を算出する。そして、携帯端末装置は、バッテリごとに当該バッテリの残量が対応付けられたバッテリ残量データを用いて、バッテリ別の消費電力の総和から動作時間をドライバの組合せごとに算出する。続いて、携帯端末装置は、消費電力と動作時間から評価値をドライバの組合せごとに算出する。その上で、携帯端末装置は、評価値が最良である組合せを選択する。なお、評価値を算出せずとも、動作時間が所定時間以上である組合せのうち消費電力が最小である組合せを選択することとしてもかまわない。なお、消費電力を無視して動作時間が最長の組合せを選択するようにしてもよい。

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

図２１は、実施例１〜実施例４に係るセンシング制御プログラムを実行するコンピュータの一例について説明するための図である。図２１に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図２１に示すように、上記の実施例１〜実施例３で示したミドルウェア実行部と同様の機能を発揮するセンシング制御プログラム１７０ａが予め記憶される。このセンシング制御プログラム１７０ａについては、図２、図１０や図１５に示した各々の各機能部の各構成要素と同様、適宜統合又は分離してもよい。すなわち、ＨＤＤ１７０に格納される各データは、必ずしも全てのデータがＨＤＤ１７０に格納されておらずともよく、処理に用いるデータのみがＨＤＤ１７０に格納されればよい。

そして、ＣＰＵ１５０が、センシング制御プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図２１に示すように、センシング制御プログラム１７０ａは、センシング制御プロセス１８０ａとして機能する。このセンシング制御プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データをＲＡＭ１８０上のセンシング制御プロセス１８０ａに割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、センシング制御プロセス１８０ａは、図２、図１０や図１５に示した機能部にて実行される処理、例えば図８、図１２、図１３または図２０に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、必ずしも全ての処理部がＣＰＵ１５０上で動作せずともよく、処理に用いる処理部のみが仮想的に実現されればよい。

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

１０ 携帯端末装置
１１ａ，１１ｃ ＢＬＥチップ
１１ｂ，１１ｄ 歩行センサ
１２ｃｄ センサマイコン
１３ 記憶部
１３ａ 動作電力データ
１４ 制御部
１５ａ，１５ｂ ドライバ実行部
１５ｃｄ センサマイコンドライバ実行部
１６ アプリ実行部
１７ ミドルウェア実行部
１７ａ 受付部
１７ｂ 特定部
１７ｃ 算出部
１７ｄ 選択部
１７ｅ 指示部

Claims (5)

1. コンピュータに、
   １つまたは複数のセンシングを実現するセンサまたは前記センサを制御するドライバの組合せごとに前記センシングの実行時に動作させるデバイスを特定し、
   特定されたデバイスが前記センシングにより消費する電力を前記組合せごとに算出し、
   前記電力が最小である組合せを選択する
   処理を実行させることを特徴とするセンシング制御プログラム。
2. 前記特定する処理は、センシングの実行指示を受け付けた場合、前記センシングのうちいずれかのセンシングの停止指示を受け付けた場合、もしくは前記コンピュータに対する外部装置の接続または接続解除が検出された場合に、前記デバイスを特定する処理を実行することを特徴とする請求項１に記載のセンシング制御プログラム。
3. 前記特定する処理は、センシングの実行が指示された場合、当該指示によって追加されたセンシングを実現するセンサまたはドライバの組合せを対象に、前記デバイスを特定する処理を実行することを特徴とする請求項１に記載のセンシング制御プログラム。
4. 前記選択する処理は、前記組合せごとに算出された電力とともに、前記デバイスが動作する動作時間に基づいて前記組合せを選択することを特徴とする請求項１〜３のいずれか１つの記載のセンシング制御プログラム。
5. １つまたは複数のセンシングを実現するセンサまたは前記センサを制御するドライバの組合せごとに前記センシングの実行時に動作させるデバイスを特定する特定部と、
   特定されたデバイスが前記センシングにより消費する電力を前記組合せごとに算出する算出部と、
   前記電力が最小である組合せを選択する選択部と
   を有することを特徴とする携帯端末装置。

Images