JP6070321B2 - 携帯情報端末、制御方法、制御プログラム - Google Patents

Description

本技術は、携帯情報端末、制御方法、制御プログラムに関する。

例えばスマートフォンなどの携帯情報端末は、通常のデスクトップＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）用ＯＳと同様、ユーザが多種多様なアプリ（アプリケーション）を自由にダウンロード及びインストールすることができる為、それぞれのアプリが要求するＣＰＵの動作周波数を事前に把握することは困難である。同様に、アプリ開発者も、多種多様な携帯情報端末で、どの程度のＣＰＵ性能が必要であるかを把握することは困難である為、アプリ毎に必要なＣＰＵの動作周波数に基づき、携帯情報端末のＣＰＵの動作周波数を決定することはできない。

デスクトップ用マルチタスクＯＳでのＣＰＵ動作周波数制御を説明する。

先ず、ユーザもしくはミドルウェアに於いて、ＣＰＵ動作周波数ポリシ（ＣＰＵの動作周波数を変更するアルゴリズム、動作周波数の上限値及び下限値、アルゴリズムや上限値及び下限値の継続時間）を指定して、ＯＳカーネルに動作周波数の制御を指示する。ＯＳカーネルは、ＣＰＵ利用率と動作周波数ポリシに基づき、ＣＰＵの動作周波数の目標値を決定して、ＣＰＵの制御回路ドライバに動作周波数の制御を実施させる。

ところが、従来技術にかかるＣＰＵ動作周波数制御は、ＣＰＵの利用率の観測後に実施される為、なんらかの負荷が発生してからＣＰＵの動作周波数が上昇するまでに時間がかかる。このため、瞬間的に高い処理能力が必要となった場合、ユーザの体感性能が劣化することがある。

さらに、ＣＰＵ動作周波数制御モジュールに於いて、ＣＰＵの動作周波数の上昇が遅れると、以下のような問題も生じる。例えば携帯情報端末のスリープモードを解除する場合、先ず、ＯＳカーネルが所定時間スリープを禁止するタイマを設定して、続いて該タイマが切れるまでに、ミドルウェアやアプリがスリープ禁止の設定を実行する。ところが、スリープモードの解除では、大量の処理が発生する。もし、ＣＰＵ動作周波数制御モジュールによる、ＣＰＵの動作周波数の上昇制御が遅れると、発生した大量の処理をＣＰＵが処理しきれずに、スリープモードの解除前にＯＳカーネルのスリープ禁止タイマが切れることがある。即ち、携帯情報端末をスリープモードから復帰させる為に電源ボタンを押下したにも関わらず、スリープモードの解除前に再度スリープモードに遷移することがある。スリープモードに遷移しないまでも、電源ボタンを押下してから実際に携帯情報端末が操作可能になるまでに膨大な時間がかかり、ユーザの操作性を損なうこともある。

このような問題を解決する為、ブースト（以下、ｂｏｏｓｔとする）という仕組みが存在する。ｂｏｏｓｔは、ＣＰＵ動作周波数制御モジュールの制御パラメータである動作周波数の下限値をＣＰＵ動作周波数制御モジュールの外部から変更して、ＣＰＵの動作周波数を瞬時に新たな下限値以上の動作周波数に変更する仕組みである。ｂｏｏｓｔを使用すれば、瞬時に高い処理能力が必要なイベントが発生した際に、ＣＰＵの動作周波数の下限値が一時的に急上昇するので、イベントを確実に処理することができる。

特開２０１０−３９７９１号公報

ところで、従来技術にかかるｂｏｏｓｔは、ユーザが携帯情報端末の画面をＯＦＦからＯＮに切り替えるときなど、もっともＣＰＵの処理能力が必要となる場面に用いられてきた。このため、ＣＰＵ動作周波数制御モジュールに与える動作周波数の下限値やｂｏｏｓｔの持続時間は、最大の性能要求を満足できるように決められていた。それゆえ、高い処理能力を必要としないイベントが発生したときには、ｂｏｏｓｔを動作させることで、無駄な消費電力が発生していた。

開示の技術によれば、ＣＰＵの能力不足を避けつつ、消費電力を削減できる携帯情報端末、制御方法、制御プログラムを提供する。

開示の技術の一観点によれば、ＣＰＵの動作周波数を制御する携帯情報端末に於いて、 前記携帯情報端末の状態を取得する状態取得部と、前記状態の変更後かつ前記状態の取得に関する時間の経過前に発生するイベントの検知を契機に、前記ＣＰＵの動作周波数の下限値を上昇させる制御部と、を備える携帯情報端末、が提供される。

本開示の技術の一観点によれば、ＣＰＵの能力不足を避けつつ、消費電力を削減することができる。

第１の実施形態にかかる携帯情報端末のハードウェア構成の概略図である。 第１の実施形態にかかる携帯情報端末の機能ブロックの概略図である。 第１の実施形態にかかるｂｏｏｓｔモジュールの詳細な機能ブロックの概略図である。 第１の実施形態にかかる端末状態パラメータテーブルの概略図である。 第１の実施形態にかかるｂｏｏｓｔのフローチャートである。 第１の実施形態にかかるｂｏｏｓｔの具体例の説明図である。 第２の実施形態にかかる携帯情報端末の機能ブロックの概略図である。 第２の実施形態にかかるｂｏｏｓｔのフローチャートである。 第２の実施形態にかかるｂｏｏｓｔの具体例の説明図である。

［第１の実施形態］
以下、図１〜図６を参照して、第１の実施形態を説明する。

本実施形態では、携帯情報端末１００に発生するイベントの種別に基づき、ｂｏｏｓｔの制御パラメータを変更することで、ＣＰＵの能力不足を回避しつつ消費電力の削減をはかる。

例えば、画面ＯＦＦから画面ＯＮへの切り替えや緊急地震速報のプッシュ通知などのイベントは、ＣＰＵの能力不足による処理遅延や処理中断が許されない為、このようなイベントが発生した場合には、事前に用意された、あらゆるイベントを確実に処理できる制御パラメータを使用して、ｂｏｏｓｔ（最優先クラスｂｏｏｓｔ）を実行する。

一方、例えばメールチェックなどの、ＣＰＵの能力不足が許されるイベントが発生した場合には、消費電力を削減する為に、携帯情報端末の端末状態に紐付けられた制御パラメータを使用して、ｂｏｏｓｔ（標準クラス用ｂｏｏｓｔ）を実行する。

しかし、携帯情報端末に発生した特定のイベントに起因して、端末状態が変更した場合、携帯情報端末による端末状態の把握が遅延することがある。このため、端末状態の変更直後にＣＰＵの能力不足が許される別イベントが発生した場合、変更後の端末状態に紐付けられた制御パラメータを使用して、ｂｏｏｓｔ（標準クラス用ｂｏｏｓｔ）を実行できないことがある。従って、特定のイベントに起因する端末状態の変更後の所定時間は、事前に決められた、通常のイベントを確実に処理できる制御パラメータを使用して、ｂｏｏｓｔ（中優先クラスｂｏｏｓｔ）を実行する。

［携帯情報端末１００のハードウェア］
図１は、第１の実施形態にかかる携帯情報端末１００のハードウェア構成の概略図である。本実施形態では、携帯情報端末１００として、例えばスマートフォンやタブレットＰＣなどの携帯型の情報処理装置を想定する。

図１に示すように、携帯情報端末１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、メインメモリ１０２、補助メモリ１０３、クロック供給回路１０４、電圧供給回路１０５、電源回路１０６、バッテリ１０７、外部給電部１０８、ディスプレイ１０９、タッチスクリーン１１０、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１１１、センサ１１２、をハードウェアモジュールとして備える。これらのハードウェアモジュールは、バス１１３により相互接続されている。

ＣＰＵ１０１は、ベースバンドＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ）ではなく、アプリケーションプログラムを実行するプロセッサを想定している。ＣＰＵ１０１は、クロック供給回路１０４から供給されるクロック信号と、電圧供給回路１０５から供給される電圧と、により動作して、携帯情報端末１００の各種ハードウェアモジュールを制御する。さらに、ＣＰＵ１０１は、補助メモリ１０３に格納された各種プログラムをメインメモリ１０２に読み出すとともに、該メインメモリ１０２に読み出した各種プログラムを実行することで、各種機能を実現する。各種機能の詳細は、後述することとする。

メインメモリ１０２は、ＣＰＵ１０１により実行される各種プログラムを格納する。さらに、メインメモリ１０２は、ＣＰＵ１０１のワークエリアとして使用され、ＣＰＵ１０１による処理に必要な各種データを記憶する。メインメモリ１０２としては、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを用いても良い。

補助メモリ１０３は、携帯情報端末１００を動作させる各種プログラムを格納している。各種プログラムとしては、例えば、携帯情報端末１００により実行されるアプリケーションプログラムのほか、アプリケーションプログラムの実行環境であるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）などがある。本実施形態にかかる制御プログラムも補助メモリ１０３に格納されている。補助メモリ１０３としては、例えば、ハードディスクやフラッシュメモリ等の不揮発メモリを用いても良い。

クロック供給回路１０４は、ＣＰＵ１０１に供給する為のクロック信号を生成する。電圧供給回路１０５は、電源回路１０６から供給される電力に基づき、ＣＰＵ１０１に供給する為の可変電圧を生成する。

電源回路１０６は、バッテリ１０７から供給される電力を、電源線（図示しない）を介して、携帯情報端末１００の各種ハードウェアモジュールに供給する。但し、外部給電部１０８に外部電源（図示しない）が接続されている場合、電源回路１０６は、外部給電部１０８から供給される電力を、携帯情報端末１００の各種ハードウェアモジュールに供給しても良い。バッテリ１０７は、電源回路１０６に電力を供給する。バッテリ１０７としては、例えばリチウムイオン電池等の電池を使用しても良い。

ディスプレイ１０９は、ＣＰＵ１０１により制御され、画像情報を表示する。タッチスクリーン１１０は、ディスプレイ１０９に貼り付けられ、ユーザの指先やペン先などで接触された位置情報を入力する。

ネットワークＩ／Ｆ１１１は、ＣＰＵ１０１により制御され、例えばメールやツイッターの受信などのインターフェースとして機能する。

センサ１１２は、携帯情報端末１００の状態情報（端末状態）を取得する。センサ１１２としては、例えば加速度センサ、ジャイロセンサ、照度センサ、地磁気センサ、傾きセンサ、加圧センサ、接近センサ、温度センサ、などが想定される。

［携帯情報端末１００の機能ブロック］
図２は、第１の実施形態にかかる携帯情報端末１００の機能ブロックの概略図である。

図２に示すように、携帯情報端末１００は、ＣＰＵ動作周波数制御モジュール２０１、ｂｏｏｓｔモジュール２０２、スケジューラ２０３、ミドルウェア・ドライバ２０４、を備える。

ＣＰＵ動作周波数制御モジュール２０１、ｂｏｏｓｔモジュール２０２、スケジューラ２０３、ミドルウェア・ドライバ２０４は、何れもＣＰＵ１０１がメインメモリ１０２に制御プログラムを読み込むとともに、該メインメモリ１０２に読み込んだ制御プログラムを実行することで実現される。

ＣＰＵ動作周波数制御モジュール２０１は、ＣＰＵ１０１の負荷と、制御パラメータと、に基づき、ＣＰＵ１０１の動作周波数を制御する。制御パラメータは、例えばＣＰＵ１０１の動作周波数を変更する制御アルゴリズム、動作周波数の上限値及び下限値、制御アルゴリズムや動作周波数の上限値及び下限値の継続時間、などを含む。例えば、動作周波数の下限値を１００ＭＨｚ、継続時間を２秒とすると、ＣＰＵ動作周波数制御モジュール２０１は、制御パラメータの設定後２秒間、１００ＭＨｚ以上の動作周波数でＣＰＵ１０１を動作させることとなる。

ｂｏｏｓｔモジュール２０２は、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ＣＰＵ動作周波数制御モジュール２０１の制御パラメータを書き換える。さらに、ｂｏｏｓｔモジュール２０２は、携帯情報端末１００の端末状態に基づき、ｂｏｏｓｔモジュール２０２が管理する標準クラス用パラメータを書き換える。ｂｏｏｓｔモジュール２０２は、標準クラス用パラメータの他、中優先クラス用パラメータ及び最優先クラス用パラメータを管理する。中優先クラス用パラメータ及び最優先クラス用パラメータは、何れも事前に決められた固定値である。ｂｏｏｓｔモジュール２０２の詳細は、後述することとする。

スケジューラ２０３は、ＯＳカーネルのシステム状態情報からＣＰＵ１０１の負荷を取得する。ＣＰＵ１０１の負荷としては、例えばＣＰＵ利用率を使用しても良い。

ミドルウェア・ドライバ２０４は、ミドルウェアもしくはデバイスドライバとして機能する。例えば、ミドルウェア・ドライバ２０４は、イベントの発生を契機に、ｂｏｏｓｔモジュール２０２にｂｏｏｓｔ依頼を通知する。イベントとしては、例えば画面ＯＦＦから画面ＯＮへの切り替え（スリープモードからの復帰）、緊急地震速報のプッシュ通知、画面操作、メールのサーバチェック（以下、メールチェックとする）、などを想定する。なお、本実施形態では、画面ＯＦＦから画面ＯＮへの切り替えや緊急地震速報のプッシュ通知を、ＣＰＵ１０１の能力不足（処理能力の不足や低下など）が許されないイベントとし、画面操作やメールチェックを、ＣＰＵ１０１の能力不足が許されるイベントとする。ｂｏｏｓｔ依頼は、イベントの発生に起因するｂｏｏｓｔの開始指示である。ｂｏｏｓｔ依頼は、少なくともイベント内容を含む。

（ｂｏｏｓｔモジュール２０２の詳細）
図３は、第１の実施形態にかかるｂｏｏｓｔモジュール２０２の詳細な機能ブロックの概略図である。

図３に示すように、ｂｏｏｓｔモジュール２０２は、ｂｏｏｓｔ制御部２０２ａ、パラメータ判定部２０２ｂ、ｂｏｏｓｔ受付Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０２ｃ、タイマ２０２ｄ、標準クラス用パラメータ格納部２０２ｅ、中優先クラス用パラメータ格納部２０２ｆ、最優先クラス用パラメータ格納部２０２ｇ、を含む。

ｂｏｏｓｔ制御部２０２ａは、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃからの最優先ｂｏｏｓｔ依頼もしくは非最優先ｂｏｏｓｔ依頼に基づき、標準クラス用パラメータ格納部２０２ｅ、中優先クラス用パラメータ格納部２０２ｆ、最優先クラス用パラメータ格納部２０２ｇから標準クラス用パラメータ、中優先クラス用パラメータ、最優先クラス用パラメータの何れかを取得して、ＣＰＵ動作周波数制御モジュール２０１の制御パラメータに設定する。

詳細には、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃから最優先ｂｏｏｓｔ依頼が通知された場合、ｂｏｏｓｔ制御部２０２ａは、最優先クラス用パラメータ格納部２０２ｇから最優先クラス用パラメータを取得して、ＣＰＵ動作周波数制御モジュール２０１の制御パラメータに設定する。ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃから非最優先ｂｏｏｓｔ依頼が通知された場合、ｂｏｏｓｔ制御部２０２ａは、タイマ２０２ｄからの後述する経過時間に基づき、標準クラス用パラメータ格納部２０２ｅもしくは中優先クラス用パラメータ格納部２０２ｆから、標準クラスパラメータもしくは中優先クラス用パラメータを取得して、ＣＰＵ動作周波数制御モジュール２０１の制御パラメータに設定する。

パラメータ判定部２０２ｂは、ミドルウェア・ドライバ２０４からの端末情報に基づき、標準クラス用パラメータ格納部２０２ｅに格納されている標準クラス用パラメータを更新する。具体的には、パラメータ判定部２０２ｂは、定期的にミドルウェア・ドライバ２０４から端末情報を取得して、端末情報が変化するたびに、変化後の端末情報に紐付けられた制御パラメータを端末状態パラメータテーブルＴから読み出して、標準クラス用パラメータ格納部２０２ｄの制御パラメータに書き込む。端末状態パラメータテーブルＴの詳細は、後述することとする。

ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼を受け付け、該ｂｏｏｓｔ依頼にかかるイベントの種別に基づき、最優先ｂｏｏｓｔ依頼もしくは非最優先ｂｏｏｓｔ依頼をｂｏｏｓｔ制御部２０２ａに通知する。最優先ｂｏｏｓｔ依頼を通知する場合、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、さらに、最優先ｂｏｏｓｔの発生をタイマ２０２ｄに通知する。

タイマ２０２ｄは、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃからの最優先ｂｏｏｓｔ発生通知に基づき、経過時間の計測を実行する。即ち、タイマ２０２ｄは、最優先ｂｏｏｓｔ依頼にかかるイベント発生後の経過時間を計測する。

標準クラス用パラメータ格納部２０２ｅは、標準クラス用パラメータを格納する。標準クラス用パラメータは、携帯情報端末１００の端末情報に基づき、動的に書き換えられる。標準クラス用パラメータを使用するｂｏｏｓｔを、標準クラスｂｏｏｓｔとする。

中優先クラス用パラメータ格納部２０２ｆは、中優先クラス用パラメータを格納する。中優先クラス用パラメータは、事前に決められた固定パラメータである。中優先クラス用パラメータを使用するｂｏｏｓｔを、中優先クラスｂｏｏｓｔとする。

最優先クラス用パラメータ格納部２０２ｇは、最優先クラス用パラメータを格納する。最優先クラス用パラメータは、事前に決められた固定パラメータである。最優先クラス用パラメータを使用するｂｏｏｓｔを、最優先クラスｂｏｏｓｔとする。中優先クラス用パラメータ及び最優先クラス用パラメータは、最優先クラスｂｏｏｓｔによるＣＰＵ１０１の処理能力が、中優先クラスｂｏｏｓｔによるＣＰＵ１０１の処理能力よりも大きくなるように設定される。

（端末状態パラメータテーブルＴ）
図４は、第１の実施形態にかかる端末状態パラメータテーブルＴの概略図である。

図４に示すように、端末状態パラメータテーブルＴは、携帯情報端末１００の端末状態毎に制御パラメータを記憶する。本実施形態にかかる端末状態パラメータテーブルＴでは、端末状態を画面のＯＮ／ＯＦＦ及び動作中のアプリ種別の組み合わせとし、制御パラメータをＣＰＵ１０１の動作周波数の下限値とする。

例えば、「画面：ＯＮ、動作中アプリ：メール」である端末状態「１」には、制御パラメータとして、動作周波数の下限値３００ＭＨｚが紐付けられている。「画面：ＯＦＦ，動作中アプリ：メール」である端末状態「２」には、制御パラメータとして、動作周波数の下限値１００ＭＨｚが紐付けられている。但し、本実施形態にかかる端末状態は、これに限定されるものではなく、画面のＯＮ／ＯＦＦや動作中のアプリ種別の他に、携帯情報端末１００への充電の有無などを組み合わせても良い。さらに、本実施形態にかかる制御パラメータは、動作周波数の下限値の他に、ｂｏｏｓｔの継続時間やｂｏｏｓｔのアルゴリズムなどを組み合わせも良い。

［ｂｏｏｓｔの処理フロー］
図５は、第１の実施形態にかかるｂｏｏｓｔのフローチャートである。

図５に示すように、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ｂｏｏｓｔの対象となるイベントが発生したかどうかを判断する（ステップＳ００１）。

ここで、ｂｏｏｓｔの対象となるイベントが発生したと判断された場合（ステップＳ００１のＹｅｓ）、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、イベントが最優先クラスであるかどうかを判断する（ステップＳ００２）。なお、最優先クラスのイベントとは、例えば画面ＯＦＦから画面ＯＮへの切り替えや緊急地震速報のプッシュ通知などの、ＣＰＵ１０１の能力不足が許されないイベントである。

ここで、イベントが最優先クラスであると判断された場合（ステップＳ００２のＹｅｓ）、即ちＣＰＵ１０１の能力不足が許されない場合、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、ｂｏｏｓｔ制御部２０２ａに最優先ｂｏｏｓｔ依頼を通知する。ｂｏｏｓｔ制御部２０２ａは、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃからの最優先ｂｏｏｓｔ依頼に基づき、最優先クラスｂｏｏｓｔを実行する（ステップＳ００３）。具体的には、ｂｏｏｓｔ制御部２０２ａは、最優先クラス用パラメータ格納部２０２ｇから最優先クラス用パラメータを取得して、ＣＰＵ動作周波数制御モジュール２０１に書き込む。こうして、ＣＰＵ動作周波数制御モジュール２０１は、最優先クラス用パラメータを使用して、ＣＰＵ１０１の動作周波数を制御する。これにより、ＣＰＵ１０１は、例えば画面ＯＦＦから画面ＯＮへの切り替えや緊急地震速報のプッシュ通知などの、あらゆるイベントを確実に処理できる処理能力を発揮することとなる。

次に、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、タイマ２０２ｄに優先ｂｏｏｓｔの発生を通知して、タイマ２０２ｄに最優先クラスｂｏｏｓｔからの経過時間の計測を開始させる（ステップＳ００４）。

次に、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、再度、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ｂｏｏｓｔの対象となるイベントが発生したかどうかを判断する（ステップＳ００１）。

一方、イベントが最優先クラスであると判断されない場合（ステップＳ００２のＮｏ）、即ちＣＰＵ１０１の能力不足が許される場合、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、ｂｏｏｓｔ制御部２０２ａに非最優先ｂｏｏｓｔ依頼を通知する。ｂｏｏｓｔ制御部２０２ａは、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃからの非最優先ｂｏｏｓｔ依頼に基づき、最優先クラスｂｏｏｓｔからの経過時間がしきい値以上であるかどうかを判断する（ステップＳ００５）。

ここで、最優先クラスｂｏｏｓｔからの経過時間がしきい値以上であると判断された場合（ステップＳ００５のＹｅｓ）、ｂｏｏｓｔ制御部２０２ａは、最優先クラスｂｏｏｓｔ後の端末状態に紐付けられた標準クラス用パラメータが標準クラス用パラメータ格納部２０２ｅに記憶されたと判断して、標準クラスｂｏｏｓｔを実行する（ステップＳ００６）。具体的には、ｂｏｏｓｔ制御部２０２ａは、標準クラス用パラメータ格納部２０２ｅから標準クラス用パラメータを読み出して、ＣＰＵ動作周波数制御モジュール２０１に書き込む。こうして、ＣＰＵ動作周波数制御モジュール２０１は、標準クラス用パラメータを使用して、ＣＰＵ１０１の動作周波数を制御する。これにより、ＣＰＵ１０１は、それぞれのイベントを処理できる最適な処理能力を発揮することとなる。

次に、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、再度、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ｂｏｏｓｔの対象となるイベントが発生したかどうかを判断する（ステップＳ００１）。

一方、最優先クラスｂｏｏｓｔからの経過時間がしきい値以上であると判断されない場合（ステップＳ００５のＮｏ）、ｂｏｏｓｔ制御部２０２ａは、最優先クラスｂｏｏｓｔ後の端末状態に紐付けられた標準クラス用パラメータが標準クラス用パラメータ格納部２０２ｅに記憶されていないと判断して、中優先クラスｂｏｏｓｔを実行する（ステップＳ００７）。具体的には、ｂｏｏｓｔ制御部２０２ａは、中優先クラス用パラメータ格納部２０２ｆから中優先クラス用パラメータを読み出して、ＣＰＵ動作周波数制御モジュール２０１に書き込む。こうして、ＣＰＵ動作周波数制御モジュール２０１は、中優先クラス用パラメータを使用して、ＣＰＵ１０１の動作周波数を制御する。これにより、ＣＰＵ１０１は、あらゆる通常のイベント、即ち最優先クラスのイベントではないイベントを確実に処理できる処理能力を発揮することとなる。

次に、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、再度、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ｂｏｏｓｔの対象となるイベントが発生したかどうかを判断する（ステップＳ００１）。

一方、ｂｏｏｓｔの対象となるイベントが発生したと判断されない場合（ステップＳ００１のＮｏ）、パラメータ判定部２０２ｂは、ミドルウェア・ドライバ２０４からの各種情報に基づき、携帯情報端末１００の端末状態を特定する（ステップＳ００８）。具体的には、パラメータ判定部２０２ｂは、ミドルウェア・ドライバ２０４からの各種情報に基づき、画面のＯＮ／ＯＦＦや動作中アプリの種別などを取得して、携帯情報端末１００の端末状態を特定する。

次に、パラメータ判定部２０２ｂは、端末状態パラメータテーブルＴを参照して、携帯情報端末１００の端末状態に紐付けられた制御パラメータを取得する（ステップＳ００９）。例えば、端末状態が「画面：ＯＮ、動作中アプリ：メール」であれば、パラメータ判定部２０２ｂは、端末状態パラメータテーブルＴから端末状態「１」に紐付けられた制御パラメータ「下限値：３００ＭＨｚ」を取得することとなる。

次に、パラメータ判定部２０２ｂは、標準クラス用パラメータ格納部２０２ｅに格納された標準クラス用パラメータを、携帯情報端末１００の端末状態に紐付けられた制御パラメータに書き換える（ステップＳ０１０）。例えば、端末状態「１」であれば、パラメータ判定部２０２ｂは、標準クラス用パラメータを「下限値：３００ＭＨｚ」に更新することとなる。

［ｂｏｏｓｔの具体例］
図６は、第１の実施形態にかかるｂｏｏｓｔの具体例の説明図である。

図中のパート（ａ）は、ｂｏｏｓｔを実行したときのＣＰＵ１０１の処理能力及び処理負荷（実際の処理量）のグラフである。グラフでは、横軸を時間（ｓｅｃ）、縦軸を処理能力（ＭＨｚ）としている。実線は、ＣＰＵ１０１の処理能力、点線（破線）は、ＣＰＵ１０１の処理負荷である。図中のパート（ｂ）は、携帯情報端末１００の端末状態、端末状態の判定状況、ｂｏｏｓｔに使用するパラメータの関係である。

端末状態の判定状況が「判定済」かつ端末状態が「画面：ＯＦＦ、動作中アプリ：メール」である区間Ｒ１にメールチェックのイベントが発生すると、ｂｏｏｓｔモジュール２０２は、端末状態に紐付けられた標準クラス用パラメータを使用して、標準クラスｂｏｏｓｔを実施する。即ち、端末状態が「画面：ＯＦＦ、動作中アプリ：メール」であれば、携帯情報端末１００が意識的に操作されていないと推測できる為（ポケットに入っているなど）、ｂｏｏｓｔモジュール２０２は、端末状態に紐付けられた標準クラス用パラメータを使用することで、ＣＰＵ１０１の処理能力を低調に維持したまま、メールチェックのイベントを処理する。これにより、イベント処理の為の消費電力を削減する。

一方、画面ＯＦＦから画面ＯＮへの切り替えのイベントが発生すると、ｂｏｏｓｔモジュール２０２は、携帯情報端末１００の端末状態に関係なく、最優先クラス用パラメータを使用して、最優先クラスｂｏｏｓｔを実行する。即ち、画面ＯＦＦから画面ＯＮへの切り替えのイベントは、ＣＰＵ１０１の能力不足が許されないイベントである為、ｂｏｏｓｔモジュール２０２は、最優先クラス用パラメータを使用して、ＣＰＵ１０１の処理能力を大幅に上昇させることで、イベントを確実に処理することを優先する。

他方、画面ＯＦＦから画面ＯＮへの切り替えのイベント後の経過時間がしきい値未満である区間Ｒ２、即ちＣＰＵ１０１の能力不足が許されないイベント後の経過時間がしきい値未満である区間Ｒ２に画面操作やメールチェックなどのイベントが発生すると、ｂｏｏｓｔモジュール２０２は、イベントの種別に関係なく、中優先クラス用パラメータを使用して、中優先クラスｂｏｏｓｔを実行する。即ち、ＣＰＵ１０１の能力不足が許されないイベントの終了後は、例えば画面操作などの比較的高負荷のイベントが発生して、端末状態の判定終了が遅延することが予想される為、ｂｏｏｓｔモジュール２０２は、中優先クラス用パラメータを使用することで、イベントを確実に処理することを優先する。

以上のように、本実施形態では、携帯情報端末１００に発生したイベントが最優先クラスである場合、即ちＣＰＵ１０１の能力不足が許されない特定のイベントである場合、事前に用意された、あらゆるイベントを確実に処理できる制御パラメータ（最優先クラス用パラメータ）を使用して、最優先クラスｂｏｏｓｔを実行する。このため、ＣＰＵ１０１の能力不足に起因するイベント処理の失敗を回避することができる。

又、携帯情報端末１００に発生したイベントが最優先クラスでない場合、即ちＣＰＵ１０１の能力不足が許される場合、携帯情報端末１００の端末状態に紐付けられた制御パラメータ（標準クラス用パラメータ）を使用して、標準クラス用ｂｏｏｓｔを実行する。このため、携帯情報端末１００の端末状態に最適なｂｏｏｓｔが実行される為、無駄な消費電力を削減することができる。

さらに、携帯情報端末１００に発生した特定のイベントに起因する端末状態の変更後の所定期間は、事前に用意された、通常のイベントを確実に処理できる制御パラメータ（中優先クラス用パラメータ）を使用して、中優先クラス用ｂｏｏｓｔを実行する。このため、携帯情報端末１００の端末状態の変更直後でも、ＣＰＵ１０１の能力不足に起因するイベント処理の失敗を回避することができる。

［第２の実施形態］
以下、図７−図９を参照して、第２の実施形態を説明する。但し、第１の実施形態と同等の構成、機能、作用については、説明を省略することとする。

本実施形態では、携帯情報端末１００Ａの充電直前、バッテリ１０７の電池残量の減少に付随して、携帯情報端末１００Ａが省エネモード（エコモード）に遷移していると想定する。なお、省エネモードとは、ＣＰＵ１０１の処理能力を抑制して、電力消費を削減するモードである。

携帯情報端末１００Ａが省エネモードであるときに、携帯情報端末１００Ａの充電が開始されると、消費電力を抑制する必要がなくなるが、ＣＰＵ１０１の処理能力が抑制されている為、充電直後、端末状態の判定終了が遅延することが予想される。このため、携帯情報端末１００Ａの端末状態の変更後（「非充電中」⇒「充電中」）、標準クラス用パラメータ格納部２０２ｅの制御パラメータが更新されるまで、消費電力を抑制する必要がないにも拘わらず、ＣＰＵ１０１の処理能力が抑制され、イベント処理に膨大な時間がかかることがある。

以上の問題を解決する為に、本実施形態では、例えば携帯情報端末１００Ａの充電開始からの経過時間がしきい値未満である場合、ｂｏｏｓｔモジュール２０２Ａは、携帯情報端末１００Ａの端末状態に依存しない中優先クラス用パラメータを使用して、中優先クラスｂｏｏｓｔを実行する。これにより、本実施形態では、携帯情報端末１００Ａの充電の開始直後に発生したイベントも確実に処理することができる。

（ｂｏｏｓｔモジュール２０２Ａの詳細）
図７は、第２の実施形態にかかる携帯情報端末１００Ａの機能ブロックの概略図である。

図７に示すように、第２の実施形態にかかる携帯情報端末１００Ａは、第１の実施形態にかかるｂｏｏｓｔモジュール２０２の代わりに、ｂｏｏｓｔモジュール２０２Ａを備える。

ｂｏｏｓｔモジュール２０２Ａは、ＣＰＵ１０１がメインメモリ１０２に制御プログラムを読み込むとともに、該メインメモリ１０２に読み込んだ制御プログラムを実行することで実現される。

ｂｏｏｓｔモジュール２０２Ａは、イベント通知Ｉ／Ｆ２０２ｈを含む。イベント通知Ｉ／Ｆ２０２ｈは、ミドルウェア・ドライバ２０４からのイベント情報を受け付ける。さらに、イベント通知Ｉ／Ｆ２０２ｈは、携帯情報端末１００Ａに特定のイベントが発生した場合、タイマ２０２ｄに特定イベントの発生を通知する。特定のイベントとしては、例えば携帯情報端末１００Ａへの充電開始である。

［ｂｏｏｓｔの処理フロー］
図８は、第２の実施形態にかかるｂｏｏｓｔのフローチャートである。

図８に示すように、イベント通知Ｉ／Ｆ２０２ｈは、ミドルウェア・ドライバ２０４からのイベント情報に基づき、特定のイベント、例えば携帯情報端末１００Ａへの充電が発生したかどうかを判断する（ステップＳ０２１）。

ここで、ｂｏｏｓｔの対象となる特定のイベントが発生したと判断された場合（ステップＳ０２１のＹｅｓ）、イベント受付Ｉ／Ｆ２０２ｈは、特定のイベントの発生をタイマ２０２ｄに通知して、特定のイベントからの経過時間の計測を開始させる（ステップＳ０２２）。

次に、イベント受付部Ｉ／Ｆ２０２ｈは、再度、ミドルウェア・ドライバ２０４からのイベント情報に基づき、特定のイベントが発生したかどうかを判断する（ステップＳ０２１）。

一方、特定のイベントが発生したと判断されない場合（ステップＳ０２１のＮｏ）、第１の実施形態と同様、ｂｏｏｓｔ受付Ｉ／Ｆ２０２ｃは、ミドルウェア・ドライバ２０４からのｂｏｏｓｔ依頼に基づき、ｂｏｏｓｔの対象となるイベントが発生したかどうかを判断する（ステップＳ００１）。以降の処理は、第１の実施形態と同等である。

［ｂｏｏｓｔの具体例］
図９は、第２の実施形態にかかるｂｏｏｓｔの具体例の説明図である。

図中のパート（ａ）は、ｂｏｏｓｔを実行したときのＣＰＵ１０１の処理能力及び処理負荷（実際の処理量）のグラフである。グラフでは、横軸を時間（ｓｅｃ）、縦軸を処理能力（ＭＨｚ）としている。実線は、ＣＰＵ１０１の処理能力、点線（破線）は、ＣＰＵ１０１の処理負荷である。図中のパート（ｂ）は、携帯情報端末１００Ａの端末状態、端末状態の判定状況、ｂｏｏｓｔに使用するパラメータの関係である。

端末状態の判定状況が「判定済」かつ端末状態が「充電：非充電中、モード：省エネ」である区間Ｒ３に画面操作のイベントが発生すると、ｂｏｏｓｔモジュール２０２Ａは、端末状態に紐付けられた標準クラス用パラメータを使用して、標準クラスｂｏｏｓｔを実施する。即ち、端末状態が「充電：非充電中、モード：省エネ」であれば、消費電力の削減を優先すべきである為、ｂｏｏｓｔモジュール２０２Ａは、端末状態に紐付けられた標準クラス用パラメータを使用することで、ＣＰＵ１０１の処理能力を低調に維持したまま、画面操作のイベントを処理する。これにより、イベント処理の為の消費電力の増加を回避する。

一方、携帯情報端末１００Ａの充電開始のイベント後の経過時間がしきい値未満である区間Ｒ４に画面操作のイベントが発生すると、ｂｏｏｓｔモジュール２０２Ａは、イベントの種別に関係なく、中優先クラス用パラメータを使用して、中優先クラスｂｏｏｓｔを実行する。即ち、充電開始の直後は、携帯情報端末１００Ａの端末状態の判定が終了していないことが予想される為、ｂｏｏｓｔモジュール２０２Ａは、事前に用意された、中優先クラス用パラメータを使用することで、イベントを確実に処理することを優先する。

以上のように、本実施形態にかかるｂｏｏｓｔモジュール２０２Ａは、特定のイベントの開始後の経過時間、例えば携帯情報端末１００Ａの充電開始後の経過時間がしきい値未満であれば、事前に用意しておいた中優先クラス用パラメータを使用して、中優先クラスｂｏｏｓｔを実行する為、例えば携帯情報端末１００Ａの充電開始直後の、端末情報を把握できない区間でも、ＣＰＵ１０１の能力不足に起因するイベント処理の失敗を回避することができる。

１００：携帯端情報末
１００Ａ：携帯情報端末
１０１：ＣＰＵ
２０１：ＣＰＵ動作周波数制御モジュール
２０２：ｂｏｏｓｔモジュール
２０２ａ：ｂｏｏｓｔ制御部
２０２ｂ：パラメータ判定部
２０２ｃ：ｂｏｏｓｔ受付Ｉ／Ｆ
２０２ｄ：タイマ
２０２ｅ：標準クラス用パラメータ格納部
２０２ｆ：中優先クラス用パラメータ格納部
２０２ｇ：最優先クラス用パラメータ格納部
２０２ｈ：イベント通知Ｉ／Ｆ
Ｔ：端末状態パラメータテーブル

Claims (7)

1. ＣＰＵの動作周波数を制御する携帯情報端末に於いて、
   前記携帯情報端末の状態を示す状態情報を取得する状態情報取得部と、
   前記状態情報に基づき前記状態の変更を検知し、前記状態の変更が検知されてから所定の時間の経過前に発生するイベントを処理する際、前記ＣＰＵの動作周波数の下限値を上昇させる制御部と、
   を備える携帯情報端末。
2. 請求項１に記載の携帯情報端末に於いて、
   前記制御部は、前記所定の時間の経過後に発生するイベントを処理する際、前記ＣＰＵの動作周波数の下限値を、前記状態に対応する値とする、携帯情報端末。
3. 請求項１又は２に記載の携帯情報端末に於いて、
   前記状態の変更は、前記携帯情報端末のスリープモードからの復帰もしくは前記携帯情報端末の充電に付随するものである、携帯情報端末。
4. ＣＰＵの動作周波数を制御する携帯情報端末の制御方法に於いて、
   前記携帯情報端末の状態を示す状態情報を取得し、
   前記状態情報に基づき前記状態の変更を検知し、
   前記状態の変更が検知されてから所定の時間の経過前に発生するイベントを処理する際、前記ＣＰＵの動作周波数の下限値を上昇させる、制御方法。
5. 請求項４に記載の制御方法に於いて、
   前記ＣＰＵは、前記携帯情報端末に搭載され、前記イベントを処理するＣＰＵである、制御方法。
6. ＣＰＵの動作周波数を制御する携帯情報端末の制御プログラムに於いて、
   前記制御プログラムは、前記携帯情報端末に、
   前記携帯情報端末の状態を示す状態情報を取得させ、
   前記状態情報に基づき前記状態の変更を検知させ、
   前記状態の変更が検知されてから所定の時間の経過前に発生するイベントを処理する際、前記ＣＰＵの動作周波数の下限値を上昇させる、制御プログラム。
7. 請求項１乃至３何れかに記載の携帯情報端末に於いて、
   前記動作周波数の制御に関する複数の値を有するパラメータを格納するパラメータ格納部を更に有し、
   前記制御部は、前記パラメータ格納部に格納された前記複数の値を有するパラメータのうち、何れかのパラメータを選択し、選択された前記パラメータに基づいて前記ＣＰＵの前記動作周波数を制御することにより、前記ＣＰＵの前記動作周波数の前記下限値を上昇させる
   ことを特徴とする携帯情報端末。
   

Images