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

Abstract

【課題】オフロード先のプロセッサを適切に選択すること。【解決手段】携帯端末装置１０は、アプリケーションプログラムからセンシングのリクエストを受け付け、リクエストを受け付けたセンシングを実現するセンサにより出力されるイベントがアプリケーションプログラムから指定された通知条件を満たすか否かを判定する条件判定を実行させるプロセッサの候補を特定し、プロセッサの候補ごとに、センサが出力するイベントとイベントが発生する頻度とが対応付けられた頻度データのうちリクエストを受け付けたセンシングに対応するイベントの頻度を用いて、条件判定の実行時にプロセッサの候補が消費する電力の評価値を算出し、評価値が最良であるプロセッサの候補を選択する。【選択図】図１

Description

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

各種のセンシングを利用するアプリケーションプログラムがスマートフォンに代表される携帯端末装置に搭載されている。かかる携帯端末装置の多機能化に伴って、携帯端末装置に複数のプロセッサが搭載される場合がある。さらに、スマートグラスやスマートウォッチなどのウェアラブルデバイスの発展に伴って、携帯端末装置に搭載されるプロセッサは、ウェアラブルデバイスに搭載されるプロセッサとも接続されることもある。

ここで、携帯端末装置でセンシングが実行される場合、センサによりセンシングされたイベントが所定の通知条件を満たすか否かの条件判定をプロセッサに実行させることによってオフロードを実現する場合がある。すなわち、上記の条件判定によって、通知条件を満たす場合に絞ってアプリケーションプログラムへの通知を実施させる。これによって、アプリケーションプログラムがプロセッサ上で動作する時間を低減し、携帯端末装置の省電力化に寄与することを目指す。

特開２００７−１７２３２２号公報 特開２０１０−１０２５４０号公報

しかしながら、上記の技術では、携帯端末装置が使用される環境によってオフロード先として適切なプロセッサは異なるので、オフロード先のプロセッサを適切に選択することができない場合がある。

１つの側面では、本発明は、オフロード先のプロセッサを適切に選択できるセンシング制御プログラム及び携帯端末装置を提供することを目的とする。

一態様のセンシング制御プログラムは、コンピュータに、アプリケーションプログラムからセンシングのリクエストを受け付け、前記リクエストを受け付けたセンシングを実現するセンサにより出力されるイベントが前記アプリケーションプログラムから指定された通知条件を満たすか否かを判定する条件判定を実行させるプロセッサの候補を特定し、前記プロセッサの候補ごとに、センサが出力するイベントと前記イベントが発生する頻度とが対応付けられた頻度データのうち前記リクエストを受け付けたセンシングに対応するイベントの頻度を用いて、前記条件判定の実行時に前記プロセッサの候補が消費する電力の評価値を算出し、前記評価値が最良であるプロセッサの候補を選択する処理を実行させる。

オフロード先のプロセッサを適切に選択できる。

図１は、実施例１に係る携帯端末装置の機能的構成を示すブロック図である。 図２は、実施例１に係るミドルウェア実行部の機能的構成を示すブロック図である。 図３は、条件判定に関する消費電力の評価モデルの一例を説明する図である。 図４は、通知条件の一例を示す図である。 図５Ａは、プロセッサデータの一例を示す図である。 図５Ｂは、頻度データの一例を示す図である。 図５Ｃは、評価値の算出結果の一例を示す図である。 図６Ａは、頻度データの一例を示す図である。 図６Ｂは、評価値の算出結果の一例を示す図である。 図７は、実施例１に係るプロセッサの選択処理の手順を示すフローチャートである。 図８は、実施例１に係る頻度データの更新処理の手順を示すフローチャートである。 図９は、実施例２に係る携帯端末装置の機能的構成を示すブロック図である。 図１０は、実施例２に係るミドルウェア実行部の機能的構成を示すブロック図である。 図１１は、センシング及び条件判定に関する消費電力の評価モデルの一例を説明する図である。 図１２は、動作電力データの一例を示す図である。 図１３は、総合評価値の算出結果の一例を示す図である。 図１４は、実施例２に係るプロセッサの選択処理の手順を示すフローチャートである。 図１５は、実施例１〜実施例３に係るセンシング制御プログラムを実行するコンピュータの一例について説明するための図である。

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

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

かかるセンシング制御の一環として、携帯端末装置１０は、条件判定を実行させるプロセッサの消費電力の評価にセンシングのリクエストに対応するイベントによりプロセッサが動作する頻度を加えてプロセッサを選択する。これによって、携帯端末装置１０は、例えば、オフロード先のプロセッサを適切に選択する。ここで言う「オフロード先のプロセッサ」とは、アプリケーションプログラムから指定された通知条件にしたがって条件判定を実行させるプロセッサのことを指す。

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

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

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

ＢＬＥチップ１１ａは、他の装置との間でＢＬＥによる通信を実行するチップである。

一側面として、ＢＬＥチップ１１ａは、ＢＬＥ対応のデバイスをセンシングすることができる。例えば、ＢＬＥチップ１１ａは、ＢＬＥチップ１１ａの通信圏内でＢＬＥ対応のデバイスの検出に成功した場合に、イベント「detect」を制御部１４へ出力する。また、ＢＬＥチップ１１ａは、検出に成功していたＢＬＥ対応のデバイスが消失した場合に、イベント「lost」を制御部１４へ出力する。なお、ここでは、近距離無線通信の一例としてＢＬＥを例示したが、他の規格により近距離無線通信が実行されることとしてもかまわない。

歩行センサ１１ｂは、歩行データを採取するセンサである。

一側面として、歩行センサ１１ｂには、３軸の加速度センサなどのモーションセンサを採用できる。例えば、歩行データの一例として、モーションセンサから採取される３軸の加速度データを用いて、歩行や速歩などをセンシングすることができる。さらに、地磁気センサまたはジャイロセンサなどから得られる姿勢成分と併せることによってより高精度な歩行データをセンシングすることもできる。例えば、歩行センサ１１ｂは、歩行の開始が検出された場合にイベント「start」をコプロセッサ１２ｂへ出力する一方で、歩行の停止が検出された場合にイベント「stop」をコプロセッサ１２ｂへ出力するといったセンシングを実現できる。

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

さらに、携帯端末装置１０は、図１に示すように、携帯端末装置１０に搭載されるプロセッサの一例として、コプロセッサ１２ｂを有する。

コプロセッサ１２ｂは、後述の制御部１４の演算処理を補助するプロセッサである。例えば、図１の例で言えば、歩行センサ１１ｂによるセンシングを制御するマイクロプロセッサ、いわゆるマイコンとして実装される。

一実施形態として、コプロセッサ１２ｂは、歩行センサ１１ｂの制御を実行すると共に、上記の条件判定を実行することができる。例えば、コプロセッサ１２ｂは、歩行センサ１１ｂにより出力されるイベント、ＢＬＥチップ１１ａにより出力されるイベントもしくはこれらの組合せに設定された通知条件にしたがって条件判定を実行する。そして、コプロセッサ１２は、上記の通知条件を満たす場合に絞って制御部１４で実行されるアプリケーションプログラムへの通知を実行する。これによって、制御部１４上でアプリケーションプログラムが動作する時間を低減する。

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

記憶部１３は、制御部１４で実行されるＯＳ（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）などのハードワイヤードロジックによっても実現できる。

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

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

これらのうち、ドライバ実行部１５ａは、ＢＬＥチップ１１ａに対応するドライバを実行する一方で、ドライバ実行部１５ｂは、コプロセッサ１２ｂに対応するドライバを実行する。

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

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

ここで、アプリケーションプログラムは、ミドルウェア実行部１７で実行されるミドルウェアに対し、センシングのリクエストを行う場合がある。例えば、会議システムや広告システムに関するアプリケーションプログラムの場合、アプリケーションプログラムは、所定の表示装置に設置されたＢＬＥビーコンを検知した場合に、携帯端末装置１０及び表示装置をＢＬＥ通信を介して接続する場面が挙げられる。このような場面では、アプリケーションプログラムは、ミドルウェアに対し、ＢＬＥセンシング及び歩行センシングのリクエストと共に、一例として、「歩行停止中にＢＬＥでモニタを検知していたら通知」といった通知条件が通知される場合がある。

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

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

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

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

特定部１７ｂは、条件判定を実行させるオフロード先のプロセッサ候補を特定する処理部である。

一実施形態として、特定部１７ｂは、アプリ実行部１６が実行するアプリケーションプログラムからセンシングのリクエストを受け付けた場合、当該リクエストに関するセンシングを実現するセンサを特定する。その上で、特定部１７ｂは、先のようにして特定された各センサがイベントの出力先とするプロセッサを特定する。例えば、リクエストがＢＬＥセンシングの場合、ＢＬＥチップ１１ａのイベントの出力先としてＣＰＵ１４が特定される。また、リクエストが歩行センシングの場合、歩行センサ１１ｂのイベントの出力先としてコプロセッサ１２ｂが特定される。このようにして特定されたプロセッサが１種類である場合、条件判定に用いるイベントを他のプロセッサの中継を介して得ずともよいので、以降の電力の評価を省いて、センサがイベントを出力するプロセッサをそのままオフロード先のプロセッサとして選択させることができる。また、リクエストがＢＬＥセンシング及び歩行センシングの両方の場合、ＢＬＥチップ１１ａのイベントの出力先としてＣＰＵ１４が特定されると共に、歩行センサ１１ｂのイベントの出力先としてコプロセッサ１２ｂが特定される。このようにして特定されたプロセッサが２種類である場合、いずれのプロセッサを選択するにしても、条件判定に用いるイベントを他のプロセッサの中継を介して得ることになる。この場合、いずれのプロセッサを選択した方が電力の消費が少なくて済むかによって後述の選択部によりオフロード先のプロセッサが選択される。

算出部１７ｃは、オフロード先のプロセッサ候補ごとに、リクエストに関するセンシングを実現するセンサが出力するイベントの頻度を用いて条件判定時にプロセッサ候補のデバイスにより消費する電力の評価値を算出する処理部である。

ここで、一例として、算出部１７ｃは、プロセッサ候補の消費電力を下記の仮定にしたがって評価する。例えば、ＢＬＥチップ１１ａや歩行センサ１１ｂなどのセンサからイベントが出力される度にプロセッサにより条件判定が実施される。このため、プロセッサがイベント発生時に絞って動作すると仮定する。すなわち、プロセッサ候補のプロセッサは、センサからイベントを受け付けた場合にパワーオンし、当該イベントの条件判定を実行した後にスリープ状態に遷移すると仮定する。この場合、消費電力は、次のようにモデル化することによって評価できる。

図３は、条件判定に関する消費電力の評価モデルの一例を説明する図である。図３に示すグラフの縦軸は、消費電力（Ｗ）を指し、また、横軸は、時間（ｔ）を指す。図３には、１回あたりの条件判定でプロセッサに消費させる電力量がＰｐ（Ｗｈ）として右肩上がりの塗りつぶしにより示されている。図３に示すように、１回あたりの条件判定でプロセッサに消費させる電力量がＰｐであるとしたとき、この電力量Ｐｐに対し、条件判定に用いるセンシングのイベントが発生する頻度Ｆｓを乗じることによって消費電力を評価できる。すなわち、算出部１７ｃは、算出式「Ｐｐ×Ｆｓ」によって消費電力を計算する。この計算をリクエストに対応する各イベントにわたって合計し、ΣＰｐ・Ｆｓを求めることにより、プロセッサ候補の消費電力の評価値を算出する。

より具体的には、算出部１７ｃは、プロセッサ候補ごとの消費電力の評価値ΣＰｐ・Ｆｓを求める前段階として、リクエストに対応するイベントごとに評価値を計算する。すなわち、算出部１７ｃは、記憶部１３を参照し、プロセッサごとに当該プロセッサが１回あたりの条件判定で消費する電力量Ｐｐを始め、プロセッサのウェイク時間などが対応付けられたプロセッサデータ１３ａを読み出すと共に、イベントごとに当該イベントが発生する頻度Ｆｓなどが対応付けられた頻度データ１３ｂを読み出す。その上で、算出部１７ｃは、頻度データ１３ｂに含まれるイベントのうち計算対象とするイベントに対応付けられた頻度Ｆｓと、プロセッサデータ１３ａに含まれる電力量Ｐｐのうちプロセッサ候補のプロセッサに対応付けられた電力量Ｐｐとを乗算することによって計算対象とするイベントの評価値を算出する。このとき、プロセッサ候補がプロセッサ候補以外の他のプロセッサの中継を介して条件判定に用いるイベントを得る場合、イベントの発生に応答して他のプロセッサもスリープ状態から起動することになる。この場合、算出部１７ｃは、当該計算対象とするイベントに関し、プロセッサ候補の消費電力量Ｐｐ・Ｆｓに、他のプロセッサの消費電力量Ｐｐ´・Ｆｓも加算することによって計算対象とするイベントの評価値を求める。その上で、算出部１７ｃは、各イベントの評価値を合計することによってプロセッサ候補の消費電力の評価値ΣＰｐ・Ｆｓを算出する。

選択部１７ｄは、オフロード先のプロセッサを選択する処理部である。

一実施形態として、選択部１７ｄは、算出部１７ｃによりプロセッサ候補ごとに消費電力の評価値が算出された場合に、消費電力の評価値が最良であるプロセッサ候補を選択する。例えば、上記の例のように、値が低いほど評価が高い評価値が算出される場合、各プロセッサ候補の間で評価値が最小であるプロセッサ候補をオフロード先のプロセッサとして選択する。その後、選択部１７ｄは、選択結果にしたがってアプリケーションプログラムの通知条件をオフロード先のプロセッサに設定する。例えば、ＣＰＵ１４以外のプロセッサが選択された場合、アプリケーションプログラムから受け付けた通知条件のソースコードをドライバ実行部１５ｂ等で実行されるドライバにコンパイラさせた上でオフロード先のプロセッサへ出力することもできる。

条件判定部１７ｅは、条件判定を実行する処理部である。

一実施形態として、条件判定部１７ｅは、選択部１７ｄによりＣＰＵ１４がオフロード先のプロセッサとして選択された場合に、選択部１７ｄにより設定された通知条件にしたがって条件判定を実行する。ここでは、一例として、「歩行停止中にＢＬＥでモニタを検知していたら通知」といった通知条件が設定された場合の条件判定を例示する。この場合、条件判定部１７ｅは、ＢＬＥチップ１１ａによりイベント「detect」が出力された場合にＢＬＥの状態を示す「blestate」の値を「true」に更新する一方で、ＢＬＥチップ１１ａによりイベント「lost」が出力された場合に「blestate」の値を「false」に更新する。また、条件判定部１７ｅは、歩行センサ１１ｂによりイベント「start」が出力された場合に歩行の状態を示す「walkstate」の値を「true」に更新する一方で、歩行センサ１１ｂによりイベント「stop」が出力された場合に「walkstate」の値を「false」に更新する。これらの状態の遷移を管理しつつ、条件判定部１７ｅは、「blestate」の値が「true」であり、かつ「walkstate」の値が「false」である場合に、通知条件を満たすと判定する。なお、通知条件が同一であれば、条件判定部１７ｅで実行される条件判定も、コプロセッサ１２ｂで実行される条件判定も同様の処理が実行されるのは言うまでもない。

通知部１７ｆは、各種の通知を実行する処理部である。

一側面として、通知部１７ｆは、ＢＬＥチップ１１ａまたは歩行センサ１１ｂからイベントが出力された場合に、条件判定部１７ｅにイベントを通知する。また、条件判定部１７ｅまたはコプロセッサ１２ｂの条件判定部により通知条件を満たすと判定された場合に、アプリ実行部１６により実行されるアプリケーションプログラムに通知条件を満たす旨の通知を行う。

更新部１７ｇは、頻度データ１３ｂを更新する処理部である。

一実施形態として、更新部１７ｇは、選択部１７ｄによりオフロード先のプロセッサが選択された上でリクエストに対応するセンシングが開始された後に、当該センシングに対応するイベントごとに測定開始時刻を図示しない内部メモリに記録する。そして、更新部１７ｇは、アプリケーションプログラムからセンシングの停止指示を待機する。その後、更新部１７ｇは、アプリケーションプログラムからセンシングの停止指示を受け付けた場合、各イベントの測定終了時刻を内部メモリに記録する。その上で、更新部１７ｇは、測定終了時刻から測定開始時刻を差し引くことによって各イベントの測定期間を算出する。そして、更新部１７ｇは、測定終了時刻及び測定開始時刻で定める測定期間内におけるイベントの発生回数をＣＰＵ１４内の条件判定部１７ｅまたはそれ以外で条件判定を実行する他のプロセッサから取得する。続いて、更新部１７ｇは、センシングが実行されていたイベントごとに、今回のセンシングで測定された測定期間と、前回までのセンシングで累積された測定期間とを累積加算すると共に、今回のセンシングで測定された発生回数と、前回までのセンシングで累積された発生回数とを累積加算する。そして、更新部１７ｇは、今回のセンシングで測定された発生回数が累積加算された発生回数の累積値を、今回のセンシングで測定された測定期間が累積加算された測定期間の累積値で除算することによって頻度、例えば回／ｈをイベントごとに計算する。その後、更新部１７ｇは、記憶部１３に記憶された頻度データ１３ｂのうち計算が実行されたイベントの頻度を先に計算された頻度に上書き更新する。これによって、イベントが発生する頻度の実測値を頻度データ１３ｂとして採取できる。

なお、ここでは、一例として、頻度データ１３ｂには更新部１７ｇにより頻度の実測値が設定される場合を例示したが、必ずしも実測値であらずともよい。例えば、イベントが実施で頻度が実測されていない場合などには、デフォルト値を代わりに登録しておくこととしてもできる。

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

［具体例］
次に、図４〜図５を用いて、本実施例に係るセンシング制御の具体例について説明する。図４は、通知条件の一例を示す図である。図５Ａは、プロセッサデータ１３ａの一例を示す図である。図５Ｂは、頻度データ１３ｂの一例を示す図である。図５Ｃは、評価値の算出結果の一例を示す図である。なお、図５Ｂに示した頻度データ１３ｂは、携帯端末装置１０が利用者Ａに使用された場合に更新部１７ｇによりイベントごとに更新された頻度であり、図５Ｃの評価値の算出結果は、図５Ｂに示した頻度データ１３ｂを用いて算出された場合の算出結果であることとする。

ここでは、一例として、アプリケーションプログラムからセンシングのリクエストと共に、図４の上段に示す通知条件のソースコードが受け付けられた場合を想定する。図４に示す１行目のｉｆ文の場合、ＢＬＥセンサによりイベント「detect」が出力された場合にＢＬＥの状態を示す「blestate」の値を「true」に設定することが定義されている。さらに、図４に示す２行目のｉｆ文の場合、ＢＬＥセンサによりイベント「lost」が出力された場合にＢＬＥの状態を示す「blestate」の値を「false」に設定することが定義されている。また、図４に示す３行目のｉｆ文の場合、歩行センサによりイベント「start」が出力された場合に歩行の状態を示す「walkstate」の値を「true」に設定することが定義されている。さらに、図４に示す４行目のｉｆ文の場合、歩行センサによりイベント「stop」が出力された場合に歩行の状態を示す「walkstate」の値を「false」に設定することが定義されている。また、図４に示す５行目のｉｆ文の場合、「blestate」の値が「true」であり、かつ「walkstate」の値が「true」でない場合にアプリケーションプログラムへの通知を実行することが定義されている。

このような通知条件がパーズされた場合、図４の下段に示すように、条件判定に用いられるイベントがＢＬＥ「detect」、ＢＬＥ「lost」、歩行「start」、歩行「stop」の４つであることを判別できる。

そして、センシングのリクエストがＢＬＥセンシング及び歩行センシングの両方の場合、ＢＬＥチップ１１ａのイベントの出力先としてＣＰＵ１４が特定されると共に、歩行センサ１１ｂのイベントの出力先としてコプロセッサ１２ｂが特定される。このため、オフロード先のプロセッサ候補として、ＣＰＵ１４及びコプロセッサ１２ｂが特定されることになる。

（Ａ１）ＣＰＵ１４で条件判定を実行する場合の評価値（利用者Ａ）
プロセッサ候補をＣＰＵ１４とする場合、次のようにして、各イベントの評価値が算出される。

例えば、イベント「detect」の場合、ＢＬＥチップ１１ａからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５回／ｈ）との積であるＰｐ×Ｆｓの計算結果「１．５」がイベント「detect」の評価値として算出される。

さらに、イベント「lost」の場合にも、ＢＬＥチップ１１ａからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５回／ｈ）との積であるＰｐ×Ｆｓの計算結果「１．５」がイベント「lost」の評価値として算出される。

一方、イベント「start」の場合、歩行センサ１１ｂからの出力をコプロセッサ１２ｂの中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ・Ｆｓ「９＝０．３×３０」が算出される。さらに、コプロセッサ１２ｂに対応する電力量Ｐｐ´（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ´・Ｆｓ「０．９＝０．０３×３０」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「９．９」がイベント「start」の評価値として算出される。

さらに、イベント「stop」の場合にも、歩行センサ１１ｂからの出力をコプロセッサ１２ｂの中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ・Ｆｓ「９＝０．３×３０」が算出される。さらに、コプロセッサ１２ｂに対応する電力量Ｐｐ´（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ´・Ｆｓ「０．９＝０．０３×３０」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「９．９」がイベント「start」の評価値として算出される。

このようにして計算された各イベントの評価値の合計が利用者Ａのプロセッサ候補「ＣＰＵ１４」の消費電力の評価値として算出される。すなわち、図５Ｃに示すように、イベント「detect」の評価値「１．５」、イベント「lost」の評価値「１．５」、イベント「start」の評価値「９．９」及びイベント「stop」の評価値「９．９」を合計することによってプロセッサ候補「ＣＰＵ１４」の消費電力の評価値「２２．８」が算出される。

（Ａ２）コプロセッサ１２ｂで条件判定を実行する場合の評価値（利用者Ａ）
プロセッサ候補をコプロセッサ１２ｂとする場合、次のようにして、各イベントの評価値が算出される。

例えば、イベント「detect」の場合、ＢＬＥチップ１１ａからの出力をＣＰＵ１４の中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちコプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５回／ｈ）との積Ｐｐ・Ｆｓ「０．１５＝０．０３×５」が算出される。さらに、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ´（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５回／ｈ）との積Ｐｐ・Ｆｓ「１．５＝０．３×５」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「１．６５」がイベント「detect」の評価値として算出される。

また、イベント「lost」の場合にも、ＢＬＥチップ１１ａからの出力をＣＰＵ１４の中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちコプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５回／ｈ）との積Ｐｐ・Ｆｓ「０．１５＝０．０３×５」が算出される。さらに、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ´（＝０．３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５回／ｈ）との積Ｐｐ・Ｆｓ「１．５＝０．３×５」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「１．６５」がイベント「lost」の評価値として算出される。

一方、イベント「start」の場合、歩行センサ１１ｂからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、コプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ・Ｆｓ「０．９＝０．０３×３０」がイベント「start」の評価値として算出される。

さらに、イベント「stop」の場合にも、歩行センサ１１ｂからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、コプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図５Ｂに示した頻度データ１３ｂの頻度のうちイベント「stop」に対応する頻度Ｆｓ（＝３０回／ｈ）との積Ｐｐ・Ｆｓ「０．９＝０．０３×３０」がイベント「stop」の評価値として算出される。

このようにして計算された各イベントの評価値の合計が利用者Ａのプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値として算出される。すなわち、図５Ｃに示すように、イベント「detect」の評価値「１．６５」、イベント「lost」の評価値「１．６５」、イベント「start」の評価値「０．９」及びイベント「stop」の評価値「０．９」を合計することによってプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「５．１」が算出される。

（Ａ３）オフロード先のプロセッサの選択結果（利用者Ａ）
以上のように、利用者Ａの場合、各プロセッサ候補の消費電力の評価値が算出されると、各プロセッサ候補の間で評価値が最小、すなわち「５．１」であるプロセッサ候補「コプロセッサ１２ｂ」がオフロード先のプロセッサとして選択される。このようにオフロード先のプロセッサがＣＰＵ１４以外のプロセッサである場合、図４の上段に示す通知条件は、バイトコード「４０ ００ ２１ ａｄ ３２ ｅ２・・・」などに変換した上でコプロセッサ１２ｂに設定することもできる。

（Ｂ１）ＣＰＵ１４で条件判定を実行する場合の評価値（利用者Ｂ）
図６Ａは、頻度データ１３ｂの一例を示す図である。図６Ｂは、評価値の算出結果の一例を示す図である。なお、図６Ａに示した頻度データ１３ｂは、携帯端末装置１０が利用者Ｂに使用された場合に更新部１７ｇによりイベントごとに更新された頻度であり、図６Ｂの評価値の算出結果は、図６Ａに示した頻度データ１３ｂを用いて算出された場合の算出結果であることとする。

プロセッサ候補をＣＰＵ１４とする場合、次のようにして、各イベントの評価値が算出される。

例えば、イベント「detect」の場合、ＢＬＥチップ１１ａからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５０回／ｈ）との積であるＰｐ×Ｆｓの計算結果「１５」がイベント「detect」の評価値として算出される。

さらに、イベント「lost」の場合にも、ＢＬＥチップ１１ａからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５０回／ｈ）との積であるＰｐ×Ｆｓの計算結果「１５」がイベント「lost」の評価値として算出される。

一方、イベント「start」の場合、歩行センサ１１ｂからの出力をコプロセッサ１２ｂの中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ・Ｆｓ「０．６＝０．３×２」が算出される。さらに、コプロセッサ１２ｂに対応する電力量Ｐｐ´（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ´・Ｆｓ「０．０６＝０．０３×２」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「０．６６」がイベント「start」の評価値として算出される。

さらに、イベント「stop」の場合にも、歩行センサ１１ｂからの出力をコプロセッサ１２ｂの中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「stop」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ・Ｆｓ「０．６＝０．３×２」が算出される。さらに、コプロセッサ１２ｂに対応する電力量Ｐｐ´（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「stop」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ´・Ｆｓ「０．０６＝０．０３×２」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「０．６６」がイベント「stop」の評価値として算出される。

このようにして計算された各イベントの評価値の合計が利用者Ｂのプロセッサ候補「ＣＰＵ１４」の消費電力の評価値として算出される。すなわち、図６Ｂに示すように、イベント「detect」の評価値「１５」、イベント「lost」の評価値「１５」、イベント「start」の評価値「０．６６」及びイベント「stop」の評価値「０．６６」を合計することによってプロセッサ候補「ＣＰＵ１４」の消費電力の評価値「３１．３２」が算出される。

（Ｂ２）コプロセッサ１２ｂで条件判定を実行する場合の評価値（利用者Ｂ）
プロセッサ候補をコプロセッサ１２ｂとする場合、次のようにして、各イベントの評価値が算出される。

例えば、イベント「detect」の場合、ＢＬＥチップ１１ａからの出力をＣＰＵ１４の中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちコプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５０回／ｈ）との積Ｐｐ・Ｆｓ「１．５＝０．０３×５０」が算出される。さらに、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ´（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「detect」に対応する頻度Ｆｓ（＝５０回／ｈ）との積Ｐｐ・Ｆｓ「１５＝０．３×５０」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「１６．５」がイベント「detect」の消費電力量として算出される。

また、イベント「lost」の場合にも、ＢＬＥチップ１１ａからの出力をＣＰＵ１４の中継を介して受け取ることになる。この場合、図５Ａに示したプロセッサデータ１３ａの電力量のうちコプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５０回／ｈ）との積Ｐｐ・Ｆｓ「１．５＝０．０３×５０」が算出される。さらに、図５Ａに示したプロセッサデータ１３ａの電力量のうちＣＰＵ１４に対応する電力量Ｐｐ´（＝０．３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「lost」に対応する頻度Ｆｓ（＝５０回／ｈ）との積Ｐｐ・Ｆｓ「１５＝０．３×５０」が算出される。その上で、Ｐｐ・Ｆｓ及びＰｐ´・Ｆｓの合計「１６．５」がイベント「lost」の消費電力量として算出される。

一方、イベント「start」の場合、歩行センサ１１ｂからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、コプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「start」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ・Ｆｓ「０．０６＝０．０３×２」がイベント「start」の評価値として算出される。

さらに、イベント「stop」の場合にも、歩行センサ１１ｂからの出力を他のプロセッサの中継を介さずに受け取ることができる。この場合、コプロセッサ１２ｂに対応する電力量Ｐｐ（＝０．０３ｍＷｈ）と、図６Ａに示した頻度データ１３ｂの頻度のうちイベント「stop」に対応する頻度Ｆｓ（＝２回／ｈ）との積Ｐｐ・Ｆｓ「０．０６＝０．０３×２」がイベント「stop」の評価値として算出される。

このようにして計算された各イベントの評価値の合計が利用者Ｂのプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値として算出される。すなわち、図５Ｃに示すように、イベント「detect」の評価値「１６．５」、イベント「lost」の評価値「１６．５」、イベント「start」の評価値「０．０６」及びイベント「stop」の評価値「０．０６」を合計することによってプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「３３．１２」が算出される。

（Ｂ３）オフロード先のプロセッサの選択結果（利用者Ｂ）
以上のように、利用者Ｂの場合、各プロセッサ候補の消費電力の評価値が算出されると、各プロセッサ候補の間で評価値が最小、すなわち「３１．３２」であるプロセッサ候補「ＣＰＵ１４」がオフロード先のプロセッサとして選択される。

（ＡＢ４）まとめ
上述のように、携帯端末装置１０が使用される利用者によっては、オフロード先のプロセッサとして選択されるプロセッサに違いが生じる。このように、携帯端末装置が使用される環境が異なる場合でも、オフロード先として条件判定をより少ない消費電力で実行できるプロセッサを選択することができる。したがって、本実施例に係る携帯端末装置１０によれば、オフロード先のプロセッサを適切に選択できる。

［処理の流れ］
次に、本実施例に係る携帯端末装置１０の処理の流れについて説明する。なお、ここでは、携帯端末装置１０によって実行される（１）プロセッサの選択処理を説明してから、携帯端末装置１０によって実行される（２）頻度データ１３ｂの更新処理を説明することとする。

（１）プロセッサの選択処理
図７は、実施例１に係るプロセッサの選択処理の手順を示すフローチャートである。この処理は、一例として、アプリ実行部１６が実行するアプリケーションプログラムからセンシングのリクエストを受け付けた場合に実行される。

図７に示すように、アプリケーションプログラムからセンシングのリクエストを受け付けると（ステップＳ１０１）、受付部１７ａは、ステップＳ１０１でリクエストと共に受け付けた通知条件のソースコードを解析する（ステップＳ１０２）。

続いて、特定部１７ｂは、ステップＳ１０１で受け付けたリクエストに関するセンシングを実現する各センサがイベントの出力先とするプロセッサから、オフロード先とするプロセッサの候補を特定する（ステップＳ１０３）。

その後、算出部１７ｃは、ステップＳ１０３で特定されたプロセッサ候補のうちプロセッサ候補を１つ選択する（ステップＳ１０４）。続いて、算出部１７ｃは、ステップＳ１０２で通知条件から解析された各イベントが発生する頻度を用いて、条件判定時にステップＳ１０４で選択されたプロセッサ候補のプロセッサにより消費する電力の評価値を算出する（ステップＳ１０５）。

そして、ステップＳ１０３で特定された各プロセッサ候補ごとに消費電力の評価値が算出されるまで（ステップＳ１０６Ｎｏ）、ステップＳ１０４及びステップＳ１０５の処理を繰り返し実行する。

その後、ステップＳ１０３で特定された各プロセッサ候補ごとに消費電力の評価値が算出されると（ステップＳ１０６Ｙｅｓ）、選択部１７ｄは、各プロセッサ候補の間で評価値が最小であるプロセッサ候補をオフロード先のプロセッサとして選択する（ステップＳ１０７）。その上で、選択部１７ｄは、ステップＳ１０７で選択されたオフロード先のプロセッサに対し、アプリケーションプログラムの通知条件を設定し（ステップＳ１０８）、処理を終了する。

これによって、アプリケーションプログラムからリクエストを受け付けたセンシングがセンサにより実行されると共に、イベントの条件判定が実行されることになる。

（２）頻度データの更新処理
図８は、実施例１に係る頻度データの更新処理の手順を示すフローチャートである。この処理は、一例として、選択部１７ｄによりオフロード先のプロセッサが選択された上でリクエストに対応するセンシングが開始された場合に実行される。

図８に示すように、更新部１７ｇは、ステップＳ１０１で受け付けたセンシングに対応するイベントごとに測定開始時刻を内部メモリに記録する（ステップＳ３０１）。そして、更新部１７ｇは、アプリケーションプログラムからセンシングの停止指示を待機する（ステップＳ３０２）。なお、アプリケーションプログラムからセンシングの停止指示を受け付けるまで（ステップＳ３０３Ｎｏ）、ステップＳ３０２に戻ってセンシングの停止指示を待機する。

その後、アプリケーションプログラムからセンシングの停止指示を受け付けた場合（ステップＳ３０３Ｙｅｓ）、更新部１７ｇは、各イベントの測定終了時刻を内部メモリに記録する（ステップＳ３０４）。

その上で、更新部１７ｇは、測定終了時刻から測定開始時刻を差し引くことによって各イベントの測定期間を算出する（ステップＳ３０５）。そして、更新部１７ｇは、測定終了時刻及び測定開始時刻で定まる測定期間内におけるイベントの発生回数をＣＰＵ１４内の条件判定部１７ｅまたはそれ以外で条件判定を実行する他のプロセッサから収集する（ステップＳ３０６）。

続いて、更新部１７ｇは、センシングが実行されていたイベントごとに、今回のセンシングで測定された測定期間と、前回までのセンシングで累積された測定期間とを累積加算すると共に、今回のセンシングで測定された発生回数と、前回までのセンシングで累積された発生回数とを累積加算する（ステップＳ３０７）。

そして、更新部１７ｇは、今回のセンシングで測定された発生回数が累積加算された発生回数の累積値を、今回のセンシングで測定された測定期間が累積加算された測定期間の累積値で除算することによって頻度をイベントごとに計算する（ステップＳ３０８）。その後、更新部１７ｇは、記憶部１３に記憶された頻度データ１３ｂのうち計算が実行されたイベントの頻度をステップＳ３０８で計算された頻度に上書き更新し（ステップＳ３０９）、処理を終了する。

なお、図８に示したフローチャートでは、頻度を計算してから処理を終了することとしたが、図８に示す更新処理が実行される度に測定期間および発生回数をイベントごとに追加登録することによって頻度データを生成し、算出部１７ｃにより消費電力の評価値が算出される場合に先に生成された頻度データを参照することにより、各イベントの測定期間および発生回数から頻度を算出することとしてもかまわない。

［効果の一側面］
上述してきたように、本実施例に係る携帯端末装置１０は、条件判定を実行させるプロセッサの消費電力の評価にセンシングのリクエストに対応するイベントによりプロセッサが動作する頻度を加えてプロセッサを選択する。したがって、本実施例に係る携帯端末装置１０によれば、例えば、オフロード先のプロセッサを適切に選択できる。

さて、上記の実施例１では、オフロード先とするプロセッサ候補の消費電力を評価する場合を例示したが、評価対象とするデバイスはオフロード先とするプロセッサ候補に限定されない。そこで、本実施例では、一例として、アプリケーションプログラムからのリクエストに対応するセンシングを実現するセンサの消費電力をさらに評価する場合について説明する。

［携帯端末装置２０の構成］
図９は、実施例２に係る携帯端末装置２０の機能的構成を示すブロック図である。図９に示す携帯端末装置２０は、図１に示した携帯端末装置１０に比べて、コプロセッサ１２ｂが制御下に置くセンサが歩行センサ２１ｂ１及びＢＬＥチップ２１ｂ２の２つである他、記憶部２３が記憶するデータの内容と、ミドルウェア実行部２７が実行する処理内容とに相違点がある。なお、以下では、図１に示す機能部と同様の機能を発揮する機能部には同一の符号を付し、その説明を省略することとする。

このようにＢＬＥチップ２１ｂ２がコプロセッサ１２ｂの制御下にある場合、同一の内容のセンシングを実現できるＢＬＥセンサが携帯端末装置２０内に複数通り存在することになる。本実施例に係る携帯端末装置２０では、このような場合でも、他のセンサを用いてセンシングを実行する場合よりも消費電力が少ないセンサを選択することにより、センシングに消費する電力を抑制することを目指す。

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

特定部２７ｂは、図２に示した特定部１７ｂと同様、オフロード先とするプロセッサの候補を特定するが、アプリケーションプログラムからリクエストを受け付けた１または複数のセンシングを実現するセンサまたはドライバの組合せごとにセンシングの実行時に動作させるデバイスをさらに特定する点が異なる。

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

その後、特定部２７ｂは、センサの組合せのうちセンサの組合せを１つ選択する。続いて、特定部２７ｂは、先に選択されたセンサの組合せからセンシングの実行時に動作させるデバイスを特定する。以下では、センシングの実行時に動作させるデバイスのことを「センシングデバイス」と記載する場合がある。このとき、上記の問合せの場合、センシングの可否とともに、センシングの実行が可能である場合には、センシングデバイスを併せて返信させることとすればよい。また、上記の検索の場合、上記の対応関係テーブルの項目としてセンシングデバイスをさらに対応付けておくこととすればよい。

算出部２７ｃは、図２に示した特定部１７ｂと同様、オフロード先のプロセッサ候補ごとに、条件判定時にプロセッサ候補のデバイスにより消費する電力の評価値を算出するが、センサもしくはドライバの組合せごとにセンシングデバイスがセンシングにより消費する電力をさらに算出する点が異なる。

一実施形態として、算出部２７ｃは、特定部２７ｂによってセンシングデバイスが特定される度に、記憶部２３に記憶された動作電力データ２３ａを参照して、各デバイスがセンシングで消費する電力を評価値として算出する。例えば、動作電力データ２３ａには、デバイス及び動作電力などの項目が対応付けられたデータを採用できる。これを用いて、算出部２７ｃは、センシングの実行時に動作させる各デバイスに対応する動作電力を検索する。その上で、算出部２７ｃは、各デバイスの動作電力を合計することによって各デバイスがセンシングを実行する場合の消費電力の評価値を算出する。

このようにセンシングデバイスの消費電力が算出されると、算出部２７ｃは、図１１に示す評価モデルにしたがってセンシング及び条件判定に消費される電力を評価する。図１１は、センシング及び条件判定に関する消費電力の評価モデルの一例を説明する図である。図１１に示すグラフの縦軸は、消費電力（Ｗ）を指し、また、横軸は、時間（ｔ）を指す。図１１には、センシングデバイスにより消費される電力がＰｓ（Ｗ）として右肩下がりの塗りつぶしにより示されると共に、１回あたりの条件判定でプロセッサに消費される電力量がＰｐ（Ｗｈ）として右肩上がりの塗りつぶしにより示されている。図１１に示すように、センシングデバイスは常時パワーオンされているので、条件判定を実行させるプロセッサにより消費させる電力ΣＰｐ・Ｆｓに、センシングデバイスにより消費される電力Ｐｓ、例えば総面積の時間平均の消費電力を加算することにより、条件判定で消費される電力に加えてセンシングで消費される電力を評価できる。すなわち、算出部２７ｃは、算出式「ΣＰｓ＋ΣＰｐ・Ｆｓ」によってセンシング及び条件判定の消費電力の総合評価値を計算する。

これにより、センサの組合せ及びプロセッサ候補のペアごとに総合評価値が算出されることになる。

［具体例］
次に、図１２及び図１３を用いて、本実施例に係るセンシング制御の具体例について説明する。図１２は、動作電力データ２３ａの一例を示す図である。図１３は、総合評価値の算出結果の一例を示す図である。なお、ここでは、図４に示した通知条件がアプリケーションプログラムから受け付けられると共に、図５Ａに示したプロセッサデータ１３ａ及び図５Ｂに示した頻度データ１３ｂが総合評価値の算出に用いられることとする。

例えば、アプリケーションプログラムからＢＬＥセンシング及び歩行センシングのリクエストが受付部１７ａによって受け付けられた場合、ＢＬＥセンシングを実行可能なセンサとして、ＢＬＥチップ１１ａと、ＢＬＥチップ２１ｂ２とが特定される。さらに、歩行センシングを実行可能なセンサとして、歩行センサ２１ｂ１が特定される。

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

（イ）ＢＬＥチップ１１ａ＋歩行センサ２１ｂ１の組合せ
（ロ）ＢＬＥチップ２１ｂ２＋歩行センサ２１ｂ１の組合せ

このうち、（イ）のセンサの組合せについては、図１２に示した動作電力データ２３ａを参照することによって、ＢＬＥチップ１１ａの動作電力として１０ｍＷが取得されると共に、歩行センサ２１ｂ１の動作電力として６ｍＷが取得される。したがって、（イ）のセンサの組合せの場合、ＢＬＥセンシング及び歩行センシングの実行時における消費電力の評価値が１６ｍＷ（＝１０ｍＷ＋６ｍＷ）と算出される。

また、（ロ）のセンサの組合せについては、図１２に示した動作電力データ２３ａを参照することによって、ＢＬＥチップ２１ｂ２の動作電力として１２ｍＷが取得されると共に、歩行センサ２１ｂ１の動作電力として６ｍＷが取得される。したがって、（ロ）のセンサの組合せの場合、ＢＬＥセンシング及び歩行センシングの実行時における消費電力の評価値が１８ｍＷ（＝１２ｍＷ＋６ｍＷ）と算出される。

ここで、上記（イ）のセンサの組合せの場合、ＢＬＥチップ１１ａのイベントの出力先としてＣＰＵ１４が特定されると共に、歩行センサ２１ｂ１のイベントの出力先としてコプロセッサ１２ｂが特定される。このため、オフロード先のプロセッサ候補として、ＣＰＵ１４及びコプロセッサ１２ｂの２つのプロセッサが特定されることになる。

（１）センサの組合せ（イ）＋プロセッサ候補「ＣＰＵ１４」
このうち、プロセッサ候補をＣＰＵ１４とする場合、次のようにして、各イベントの評価値が算出される。すなわち、上記の実施例１で説明したＡ１と同様に、イベント「detect」の評価値「１．５」、イベント「lost」の評価値「１．５」、イベント「start」の評価値「９．９」及びイベント「stop」の評価値「９．９」を合計することによってプロセッサ候補「ＣＰＵ１４」の消費電力の評価値「２２．８」が算出される。その上で、ＢＬＥセンシング及び歩行センシングの実行時における消費電力の評価値「１６」と、プロセッサ候補「ＣＰＵ１４」の消費電力の評価値「２２．８」とを合計することによって、図１３に示すように、総合評価値「３８．８」を算出することができる。

（２）センサの組合せ（イ）＋プロセッサ候補「コプロセッサ１２ｂ」
また、プロセッサ候補をコプロセッサ１２ｂとする場合、次のようにして、各イベントの評価値が算出される。すなわち、上記の実施例１で説明したＡ２と同様に、イベント「detect」の評価値「１．６５」、イベント「lost」の評価値「１．６５」、イベント「start」の評価値「０．９」及びイベント「stop」の評価値「０．９」を合計することによってプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「５．１」が算出される。その上で、ＢＬＥセンシング及び歩行センシングの実行時における消費電力の評価値「１６」と、プロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「５．１」とを合計することによって、図１３に示すように、総合評価値「２１．１」を算出することができる。

（３）センサの組合せ（ロ）＋プロセッサ候補「コプロセッサ１２ｂ」
一方、上記（ロ）のセンサの組合せの場合、ＢＬＥチップ２１ｂ２のイベントの出力先としてコプロセッサ１２ｂが特定されると共に、歩行センサ２１ｂ１のイベントの出力先としてコプロセッサ１２ｂが特定される。このため、オフロード先のプロセッサ候補として、コプロセッサ１２ｂだけが特定されることになる。この場合、全てのイベントを他のプロセッサの中継を介さずに受け取ることができるので、イベント「detect」の評価値「０．１５＝０．０３×５」、イベント「lost」の評価値「０．１５＝０．０３×５」、イベント「start」の評価値「０．９＝０．０３×３０」及びイベント「stop」の評価値「０．９＝０．０３×３０」を合計することによってプロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「２．１」が算出される。その上で、ＢＬＥセンシング及び歩行センシングの実行時における消費電力の評価値「１８」と、プロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値「２．１」とを合計することによって、図１３に示すように、総合評価値「２０．１」を算出することができる。

（４）オフロード先のプロセッサの選択結果
以上のように、センサの組合せごとにプロセッサ候補別の消費電力の評価値が算出されると、全てのセンサの組合せ及びプロセッサ候補のペアのうち評価値が最小、すなわち「２０．１」であるセンサの組合せ（ロ）＋プロセッサ候補「コプロセッサ１２ｂ」のペアがオフロード先のプロセッサとして選択される。このように、条件判定で消費される電力にセンシングで消費される電力を加えて総合的に評価してオフロード先のプロセッサ及びセンシングデバイスを選択するので、消費電力をより効果的に削減できる。

［処理の流れ］
図１４は、実施例２に係るプロセッサの選択処理の手順を示すフローチャートである。この処理は、図７に示したフローチャートと同様に、アプリ実行部１６が実行するアプリケーションプログラムからセンシングのリクエストを受け付けた場合に実行される。

図１４に示すように、アプリケーションプログラムからセンシングのリクエストを受け付けると（ステップＳ５０１）、受付部１７ａは、ステップＳ５０１でリクエストと共に受け付けた通知条件のソースコードを解析する（ステップＳ５０２）。

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

その後、算出部２７ｃは、記憶部２３に記憶された動作電力データ２３ａを参照して、ステップＳ５０５で特定された各センシングデバイスの動作電力を合計することにより、ステップＳ５０４で選択されたセンサの組合せに関する消費電力の評価値を算出する（ステップＳ５０６）。

そして、特定部２７ｂは、ステップＳ５０５で特定されたセンシングデバイスがイベントの出力先とするプロセッサから、オフロード先とするプロセッサの候補を特定する（ステップＳ５０７）。

その後、算出部２７ｃは、ステップＳ５０７で特定されたプロセッサ候補のうちプロセッサ候補を１つ選択する（ステップＳ５０８）。続いて、算出部２７ｃは、ステップＳ５０２で通知条件から解析された各イベントが発生する頻度を用いて、条件判定時にステップＳ５０８で選択されたプロセッサ候補のプロセッサにより消費する電力の評価値を算出する（ステップＳ５０９）。

その上で、算出部２７ｃは、ステップＳ５０６で算出されたセンサの組合せに関する消費電力の評価値と、ステップＳ５０９で算出されたプロセッサ候補の消費電力の評価値とから総合評価値を算出する（ステップＳ５１０）。

そして、ステップＳ５０７で特定された全てのプロセッサ候補にわたって総合評価値が算出されるまで（ステップＳ５１１Ｎｏ）、ステップＳ５０８〜ステップＳ５１０の処理を繰り返し実行する。

その後、ステップＳ５０７で特定された全てのプロセッサ候補にわたって総合評価値が算出されると（ステップＳ５１１Ｙｅｓ）、ステップＳ５０３で導出された全てのセンサの組合せにわたって各プロセッサ候補ごとに総合評価値が算出されたか否かが判定される（ステップＳ５１２）。

そして、ステップＳ５０３で導出された全てのセンサの組合せにわたって各プロセッサ候補ごとに総合評価値が算出されるまで（ステップＳ５１２Ｎｏ）、ステップＳ５０４〜ステップＳ５１１の処理を繰り返し実行する。

その後、ステップＳ５０３で導出された全てのセンサの組合せにわたって各プロセッサ候補ごとに総合評価値が算出されると（ステップＳ５１２Ｙｅｓ）、選択部２７ｄは、全てのセンサの組合せ及びプロセッサ候補のペアのうち評価値が最小であるセンサの組合せ及びプロセッサ候補のペアを選択する（ステップＳ５１３）。

その上で、選択部２７ｄは、ステップＳ５１３で選択されたオフロード先のプロセッサに対し、アプリケーションプログラムの通知条件を設定すると共に、ステップＳ５１３で選択された組合せに含まれるセンサにセンシングを実行する指示を行い（ステップＳ５１４）、処理を終了する。

［効果の一側面］
上述してきたように、本実施例に係る携帯端末装置２０は、上記の実施例１に係る携帯端末装置１０と同様、携帯端末装置２０の制御下にある各プロセッサが動作する頻度を消費電力の評価に加えてオフロード先のプロセッサを選択する。したがって、本実施例に係る携帯端末装置２０によれば、例えば、オフロード先のプロセッサを適切に選択できる。

さらに、本実施例に係る携帯端末装置２０は、条件判定で消費される電力にセンシングで消費される電力を加えて総合的に評価してオフロード先のプロセッサ及びセンシングデバイスを選択する。それ故、本実施例に係る携帯端末装置２０によれば、消費電力をより効果的に削減できる。

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

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

［頻度データの応用例］
上記の実施例１及び実施例２では、１つのイベントにつき１つの頻度を対応付ける場合を例示したが、適用範囲がこれに限定される訳ではない。例えば、携帯端末装置１０または携帯端末装置２０は、１つのイベントにつき複数の時間帯別の頻度が対応付けられた頻度データを更新部１７ｇにより生成したり、これを用いて評価値の算出を算出部１７ｃまたは算出部２７ｃに実行させたりすることができる。このように、アプリケーションプログラムからリクエストを受け付けた時間帯に対応する頻度を評価値の算出に用いることにより、評価値の算出精度を向上させることができる。

［電力評価モデルの応用例１］
上記の実施例１及び実施例２では、１回あたりの条件判定でプロセッサに消費させる電力量Ｐｐに対し、条件判定に用いるセンシングのイベントが発生する頻度Ｆｓを乗じることによってオフロード先のプロセッサの消費電力を評価する場合を例示したが、適用範囲はこれに限定されない。

例えば、携帯端末装置１０または携帯端末装置２０は、通知条件から解析されたイベントごとに当該イベントでプロセッサが動作しない確率Ｐ（ｏｆｆ）をプロセッサのウェイク時間を用いて算出式「１−頻度×ウェイク時間」と表した上で、いずれのイベントでもプロセッサがウェイクしない組合せ確率ΠＰ（ｏｆｆ）を求める。かかる確率ΠＰ（ｏｆｆ）が求まると、「１−ΠＰ（ｏｆｆ）」により、いずれか１つのイベントによりプロセッサが動作する確率を導出できる。そうすると、いずれか１つのイベントによりプロセッサが動作する頻度Ｆｓ´は、「（１−ΠＰ（ｏｆｆ））／ウェイク時間」により算出することができる。このように、いずれか１つのイベントによりプロセッサが動作する確率「１−ΠＰ（ｏｆｆ）」に基づき、いずれか１つのイベントによりプロセッサが動作する頻度Ｆｓ´を求めることで、複数のイベントが重複して発生する場合に重複して発生するイベント間で消費電力を重複して計上するのを抑制できる結果、プロセッサ候補の評価値の算出精度をより向上させることができる。

例えば、図４に示した通知条件の下、プロセッサ候補がＣＰＵ１４である場合、イベント「detect」及びイベント「lost」の発生時には、ＢＬＥチップ１１ａからの出力を他のプロセッサの中継を介さずに受け取ることができる。一方で、イベント「start」及びイベント「stop」の発生時には、歩行センサ１１ｂからの出力をコプロセッサ１２ｂの中継を介して受け取ることになる。

この場合、条件判定でＣＰＵ１４が消費する電力の評価値Ｆｓ´・Ｐｐは、「｛１−（１−５×０．００２）×（１−５×０．００２）×（１−３０×０．００２）×（１−３０×０．００２）｝×０．３／０．００２」により「２０」と算出できる。また、条件判定でコプロセッサ１２ｂが消費する電力の評価値Ｆｓ´・Ｐｐは、「｛１−（１−３０×０．０００２）×（１−３０×０．０００２）｝×０．０３／０．０００２」により「１．８」と算出できる。したがって、プロセッサ候補をＣＰＵ１４とする場合の消費電力の評価値ΣＦｓ´・Ｐｐは、２１．８（＝２０＋１．８）と算出できる。これと比べて、上記の実施例１では、プロセッサ候補「ＣＰＵ１４」の消費電力の評価値は「２２．８」と算出されていることから、その差「１」の分、プロセッサ候補の評価値の算出精度を向上できていることがわかる。

一方、図４に示した通知条件の下、プロセッサ候補がコプロセッサ１２ｂである場合、イベント「detect」及びイベント「lost」の発生時には、ＢＬＥチップ１１ａからの出力をＣＰＵ１４の中継を介して受け取ることになる。一方で、イベント「start」及びイベント「stop」の発生時には、歩行センサ１１ｂからの出力を他のプロセッサの中継を介さずに受け取ることができる。

この場合、条件判定でＣＰＵ１４が消費する電力の評価値Ｆｓ´・Ｐｐは、「｛１−（１−５×０．００２）×（１−５×０．００２）｝×０．３／０．００２」により「３」と算出できる。また、条件判定でコプロセッサ１２ｂが消費する電力の評価値Ｆｓ´・Ｐｐは、「｛１−（１−３０×０．０００２）×（１−３０×０．０００２）×（１−５×０．０００２）×（１−５×０．０００２）｝×０．０３／０．０００２」により「２」と算出できる。したがって、プロセッサ候補をＣＰＵ１４とする場合の消費電力の評価値ΣＦｓ´・Ｐｐは、５（＝３＋２）と算出できる。これと比べて、上記の実施例１では、プロセッサ候補「コプロセッサ１２ｂ」の消費電力の評価値は「５．１」と算出されていることから、その差「０．１」の分、プロセッサ候補の評価値の算出精度を向上できていることがわかる。

［電力評価モデルの応用例２］
上記の実施例１及び実施例２では、プロセッサがイベント発生時に絞って動作するとの仮定の下、評価値を算出する場合を例示したが、必ずしも当該仮定に従わずともかまわない。例えば、携帯端末装置１０または携帯端末装置２０のＣＰＵ１４上で動作するＯＳからＣＰＵ１４のウェイク及びスリープに関する通知を受け付け、これらの通知により、一定の期間に占めるＣＰＵ１４のウェイク時間の割合もしくは一定の期間に占めるＣＰＵ１４のスリープ時間の割合を求める。その上で、算出部１７ｃまたは算出部２７ｃは、評価値の算出にＣＰＵ１４のウェイク時間の割合を乗じることにより、イベント以外の要因でプロセッサが動作する場合にＣＰＵ１４の動作電力を計上することにより、余計な電力を重複して計上することを抑制できる。

［条件判定の適用範囲］
条件判定としては、図４に示した単純なセンシング状態だけでなく、シーケンス等も利用できる。例えば、適用シーンの一例としては、工場で、手順通りに作業をしているかをチェックする場面が挙げられる。すなわち、各作業場所にＢＬＥビーコンを貼り付け、携帯端末装置で検知できるようにする。この場合には、一例として、通知条件に「歩行停止中に、作業場所の順番が異なっていたら通知する」という条件を設定できる。具体的には、歩行センサで歩行停止中かどうかをセンシングし、ＢＬＥチップでセンシングされた作業場所のＢＬＥビーコンが想定した順番と異なるかどうかを判定し、これら両方の条件をＡＮＤで満たす場合に、アプリケーションプログラムへ通知する通知条件が指定される。このような通知条件の場合にも、通知条件が解析された場合には、条件判定に用いられるイベントが、図４に示した例と同様、ＢＬＥ「detect」、ＢＬＥ「lost」、歩行「start」、歩行「stop」の４つであることを判別できる。このように、条件判定のアルゴリズムによらず、条件判定に用いるイベントを解析することができ、評価値の算出を行うことができることがわかる。

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

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

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

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

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

１０ 携帯端末装置
１１ａ ＢＬＥチップ
１１ｂ 歩行センサ
１２ｂ コプロセッサ
１３ 記憶部
１３ａ プロセッサデータ
１３ｂ 頻度データ
１４ 制御部
１５ａ，１５ｂ ドライバ実行部
１６ アプリ実行部
１７ ミドルウェア実行部
１７ａ 受付部
１７ｂ 特定部
１７ｃ 算出部
１７ｄ 選択部
１７ｅ 条件判定部
１７ｆ 通知部
１７ｇ 更新部

Claims (6)

1. コンピュータに、
   アプリケーションプログラムからセンシングのリクエストを受け付け、
   前記リクエストを受け付けたセンシングを実現するセンサにより出力されるイベントが前記アプリケーションプログラムから指定された通知条件を満たすか否かを判定する条件判定を実行させるプロセッサの候補を特定し、
   前記プロセッサの候補ごとに、センサが出力するイベントと前記イベントが発生する頻度とが対応付けられた頻度データのうち前記リクエストを受け付けたセンシングに対応するイベントの頻度を用いて、前記条件判定の実行時に前記プロセッサの候補が消費する電力の評価値を算出し、
   前記評価値が最良であるプロセッサの候補を選択する
   処理を実行させることを特徴とするセンシング制御プログラム。
2. 前記コンピュータに、
   前記センシングが開始されてから終了されるまでの期間と、前記期間でイベントが発生する回数とから定まる頻度をイベントごとに算出し、
   前記頻度データのうち前記算出されたイベントの頻度を更新する処理を実行させることを特徴とする請求項１に記載のセンシング制御プログラム。
3. 前記特定する処理は、前記リクエストを受け付けたセンシングを実現するセンサの組合せをさらに特定し、
   前記算出する処理は、前記センサの組合せごとに前記センシングの実行時に動作するデバイスで消費される電力の評価値を算出した上で、前記センシングの実行時に動作するデバイスで消費される電力の評価値と、前記条件判定の実行時に前記プロセッサの候補が消費する電力の評価値とから総合の評価値を算出し、
   前記選択する処理は、前記総合の評価値が最良であるセンサの組合せ及びプロセッサの候補のペアを選択することを特徴とする請求項１または２に記載のセンシング制御プログラム。
4. 前記特定する処理は、前記コンピュータに対する外部装置の接続または接続解除が検出された場合に、前記プロセッサの候補を特定する処理を実行することを特徴とする請求項１、２または３に記載のセンシング制御プログラム。
5. 前記頻度データは、センサが出力するイベントごとに前記イベントが発生する時間帯別の頻度が対応付けられたデータであることを特徴とする請求項１〜４のいずれか１つに記載のセンシング制御プログラム。
6. アプリケーションプログラムからセンシングのリクエストを受け付ける受付部と、
   前記リクエストを受け付けたセンシングを実現するセンサにより出力されるイベントが前記アプリケーションプログラムから指定された通知条件を満たすか否かを判定する条件判定を実行させるプロセッサの候補を特定する特定部と、
   前記プロセッサの候補ごとに、センサが出力するイベントと前記イベントが発生する頻度とが対応付けられた頻度データのうち前記リクエストを受け付けたセンシングに対応するイベントの頻度を用いて、前記条件判定の実行時に前記プロセッサの候補が消費する電力の評価値を算出する算出部と、
   前記評価値が最良であるプロセッサの候補を選択する選択部と
   を有することを特徴とする携帯端末装置。

Images