携帯端末、消費電力制御プログラムおよび消費電力制御方法
【課題】アプリケーションの動作状態に基づいて携帯電話の消費電力を抑えることができる、携帯端末を提供する。
【解決手段】携帯端末１０は、リチウムイオン電池３０を電源として用いる。また、携帯端末１０は、天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションを実行し、携帯端末１０の消費電力を抑える省電力状態を設定することが可能である。消費電力に相関する平均電流値は、ＣＰＵ２０の処理によって取得される。そして、省電力状態が設定されているときに、終了属性が「可」のアプリケーションは、強制終了される。さらに、省電力状態なくなったときには、強制終了されたアプリケーションが、強制終了される前の動作状態で実行される。
【解決手段】携帯端末１０は、リチウムイオン電池３０を電源として用いる。また、携帯端末１０は、天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションを実行し、携帯端末１０の消費電力を抑える省電力状態を設定することが可能である。消費電力に相関する平均電流値は、ＣＰＵ２０の処理によって取得される。そして、省電力状態が設定されているときに、終了属性が「可」のアプリケーションは、強制終了される。さらに、省電力状態なくなったときには、強制終了されたアプリケーションが、強制終了される前の動作状態で実行される。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、携帯端末に関し、特にたとえば電池を電源として利用する、携帯端末に関する。
【背景技術】
【０００２】
この種の装置の一例が、特許文献１に開示されている。この背景技術は、電池からの電圧が電源制御部によって送受信部、ベースバンド部、ＣＰＵ、ＬＣＤ制御部およびＬＣＤ駆動部などに供給されることで動作する携帯型無線通信装置である。ＬＣＤ駆動部には、ＬＣＤおよびキー操作部からのキー入力を伝えるＬＣＤ制御部が接続される。そして、キー操作部からのキー入力または着呼が一定時間なければ、電源制御部とＬＣＤ駆動部との間にあるスイッチがオフとなり、ＬＣＤ駆動部への電圧供給が停止され、ＬＣＤがオフ状態となる。つまり携帯型無線通信装置をパワーセービングモードに移行させる。
【０００３】
また、非特許文献１に開示されている背景技術では、携帯電話の消費電力を抑える「長持ちモード」について記載されている。この「長持ちモード」は、メインディスプレイ、キーおよびイルミネーションの照明や、サブディスプレイの表示時間や、ＥＺアプリおよびＰＣサイトビューアーによる処理の一部を制限することで、携帯電話の消費電力を抑える。
【特許文献１】特開平１０−３０４０３１号公報［H04M 1/00, H04Q 7/38］
【非特許文献１】Ｗ６４ＳＡ ｂｙ ＳＡＮＹＯ 取扱説明書 （６８−６９頁）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１の背景技術では、ＬＣＤ駆動部へ供給される電圧がスイッチによってオン／オフされることでパワーセービングモードに移行するが、ＣＰＵで実行されるアプリケーションを終了させることで、携帯型無線通信装置の消費電力を制御するような技術は開示されていない。
【０００５】
また、非特許文献１の「長持ちモード」では、ＥＺアプリおよびＰＣサイトビューアーによる処理の一部を制限することができるが、ＥＺアプリおよびＰＣサイトビューアーの動作状態に基づいて、処理を制限するようなことはできない。
【０００６】
また、コンピュータでは、キーボード操作が一定時間されない場合に、ＣＰＵを一時的に停止するスリープモードに移行させることで、消費電力を抑える技術が提案されているが、携帯電話のＣＰＵは、基地局との間欠受信を行うため、携帯電話のＣＰＵをスリープモードにすることはできない。
【０００７】
それゆえに、この発明の主たる目的は、新規な、携帯端末を提供することである。
【０００８】
この発明の他の目的は、アプリケーションの動作状態に基づいて携帯電話の消費電力を抑えることができる、携帯端末を提供することである。
【課題を解決するための手段】
【０００９】
この発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、この発明の理解を助けるために記述する実施形態との対応関係を示したものであって、この発明を何ら限定するものではない。
【００１０】
第１の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末であって、消費電力相関値を取得する取得手段、通常状態から省電力状態に遷移したかを判断する判断手段、および判断手段によって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了手段を備える。
【００１１】
第１の発明では、携帯端末（１０）は、電池（３０）を電源として用い、複数のアプリケーション（天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションなど）を実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能である。取得手段（２０、Ｓ３−Ｓ７）は、消費電力相関値を取得する。判断手段（２０、Ｓ２１、Ｓ３７）は、通常状態から省電力状態に遷移したかを判断する。終了手段（２０、Ｓ３５）は、判断手段によって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する。たとえば、消費電力は、携帯端末で実行されるアプリケーションの動作状態によって変動し、携帯端末で実行されるアプリケーションが多くなると、携帯端末の消費電力も大きくなる。そして、終了手段は、消費電力相関値が閾値より大きくなると、実行される複数のアプリケーションの少なくとも１つを終了する。
【００１２】
第１の発明によれば、消費電力相関値から携帯端末で実行されるアプリケーションの動作状態を判断して、アプリケーションを終了させることができるため、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。さらに、省電力状態を考慮しない仕様のアプリケーションが携帯端末に設定されたとしても、携帯端末の消費電力を抑えることができる。
【００１３】
第２の発明は、第１の発明に従属し、所定時間毎に電池の電圧値を計測する計測手段、および計測手段によって計測された電圧値を記憶する記憶手段をさらに備え、取得手段は、記憶手段によって記憶された電圧値から消費電力相関値を算出する算出手段を含む。
【００１４】
第２の発明では、計測手段（２８ｂ）は、所定時間（１００ｍｓ）毎に電池の電圧値を計測する。記憶手段（２６）は、計測手段によって計測された電圧値を記憶する。算出手段（２０、Ｓ５、Ｓ７）は、記憶手段によって記憶された電圧値から消費電力相関値を算出する。たとえば、消費電力相関値は、５秒間分の電圧値を電流値に変換した後に、５秒間分の電流値を平均した値である。つまり、算出手段は、電流値から平均電流値を算出し、取得手段は、平均電流値を消費電力相関値として取得する。
【００１５】
第２の発明によれば、電池から供給される電圧の電圧値を利用して、消費電力相関値を算出することができるようになる。
【００１６】
第３の発明は、第２の発明に従属し、記憶手段は、複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報を含む属性テーブルをさらに記憶し、終了手段は、属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる。
【００１７】
第３の発明では、記憶手段は、複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報（終了属性）を含む属性テーブル（３４２）をさらに記憶する。そして、終了手段は、属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる。
【００１８】
第３の発明によれば、使用者は、属性情報に従って終了させるアプリケーションを選択することができるため、省電力状態であっても終了させてはならないアプリケーションが終了されないように設定することができる。
【００１９】
第４の発明は、第３の発明に従属し、判断手段は、省電力状態から通常状態に遷移したかをさらに判断し、終了手段によって終了されたアプリケーションの識別情報を記憶する第１識別情報記憶手段、および判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第１識別情報記憶手段によって記憶された識別情報に基づいて、終了されたアプリケーションを復帰させる復帰手段をさらに備える。
【００２０】
第４の発明では、判断手段は、省電力状態から通常状態に遷移したかをさらに判断する。第１識別情報記憶手段（２０、Ｓ３３）は、終了手段によって終了されたアプリケーションの識別情報（アプリＩＤ）を記憶する。復帰手段（２０、Ｓ６１）は、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第１識別情報記憶手段によって記憶された識別情報に基づいて、終了されたアプリケーションを復帰させる。
【００２１】
第４の発明によれば、終了させたアプリケーションは、携帯端末が省電力状態から通常状態に遷移すれば復帰されるため、使用者は、省電力状態を意識することなく携帯端末のアプリケーションを実行させることができる。
【００２２】
第５の発明は、第３の発明または第４の発明に従属し、入力を受け付ける入力受け付け手段、判断手段によって通常状態から省電力状態に遷移したと判断されたとき、属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する第２識別情報記憶手段、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する第１表示手段、および第１表示手段によって終了されなかったアプリケーションの名前が表示された後に、入力受け付け手段が終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、終了されなかったアプリケーションの第１属性情報を終了可能に変更する第１変更手段をさらに備える。
【００２３】
第５の発明では、入力受け付け手段（２２）は、入力を受け付ける。第２識別情報記憶手段（２０、Ｓ２９）は、判断手段によって通常状態から省電力状態に遷移したと判断されたとき、属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する。第１表示手段（２０、Ｓ４１）は、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する。第１変更手段（２０、Ｓ４５）は、第１表示手段によって終了されなかったアプリケーションの名前が表示された後に、入力受け付け手段が終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、終了されなかったアプリケーションの第１属性情報を終了可能に変更する。たとえば、入力受け付け手段は、キー入力装置であり、第１変更手段は、第１属性情報を変更するキー入力がされたときに、第１属性情報を変更する。
【００２４】
第５の発明によれば、使用者は、省電力状態で終了されなかったアプリケーションについて、次に省電力状態に遷移したときには終了されるように、設定することができる。
【００２５】
第６の発明は、第４の発明または第５の発明に従属し、属性テーブルは、複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報をさらに含み、復帰手段は、終了されたアプリケーションの第２属性情報が復帰可能であるとき、終了させたアプリケーションを復帰させる。
【００２６】
第６の発明では、属性テーブルは、複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報（復帰属性）をさらに含む。そして、復帰手段は、終了されたアプリケーションの第２属性情報が復帰可能であるとき、終了させたアプリケーションを復帰させる。
【００２７】
第６の発明によれば、使用者は、有料サイトなどを閲覧中のアプリケーションが終了されたとき、復帰することで追加料金を請求されないように、アプリケーションが復帰されないように設定することができる。
【００２８】
第７の発明は、第６の発明に従属し、判断手段によって省電力状態から通常状態に遷移したと判断され、かつ終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する第２表示手段、および第２表示手段によって復帰不可能なアプリケーションの名前が表示された後に、入力受け付け手段が復帰不可能なアプリケーションの第２属性情報を変更する入力を受け付けたとき、復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する第２変更手段をさらに備える。
【００２９】
第７の発明では、第２表示手段（２０、Ｓ５３）は、判断手段によって省電力状態から通常状態に遷移したと判断され、かつ終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する。第２変更手段（２０、Ｓ５７）は、第２表示手段によって復帰不可能なアプリケーションの名前が表示された後に、入力受け付け手段が復帰不可能なアプリケーションの第２属性情報を変更する入力を受け付けたとき、復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する。
【００３０】
第７の発明によれば、使用者は、復帰されないように設定されているアプリケーションであっても、次に省電力状態から通常状態に遷移したときには復帰されるように、設定することができる。
【００３１】
第８の発明は、第４の発明ないし第７の発明のいずれかに従属し、第１識別情報記憶手段は、終了されたアプリケーションの動作状態をさらに記憶し、復帰手段は、第１識別情報記憶手段によって記憶された動作状態に基づいて、終了されたアプリケーションが終了される前の動作状態となるように復帰させる。
【００３２】
第８の発明では、第１識別情報記憶手段は、終了されたアプリケーションの動作状態をさらに記憶する。そして、復帰手段は、第１識別情報記憶手段によって記憶された動作状態に基づいて、終了されたアプリケーションが終了される前の動作状態となるように復帰させる。
【００３３】
第８の発明によれば、終了させる前の動作状態で復帰させることができるため、使用者は、省電力状態を意識することなく携帯端末のアプリケーションを実行させることができる。
【００３４】
第９の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末のプロセサ（２０）に、消費電力相関値を取得する取得ステップ（Ｓ３−Ｓ７）、通常状態から省電力状態に遷移したかを判断する判断ステップ（Ｓ２１、Ｓ３７）、および判断ステップによって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了ステップ（Ｓ３５）を実行させるための、消費電力制御プログラムである。
【００３５】
第９の発明でも、第１の発明と同様に、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【００３６】
第１０の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末の消費電力制御方法であって、消費電力相関値を取得する取得ステップ（Ｓ３−Ｓ７）、通常状態から省電力状態に遷移したかを判断する判断ステップ（Ｓ２１、Ｓ３７）、および判断ステップによって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了ステップ（Ｓ３５）を含む、消費電力制御方法である。
【００３７】
第１０の発明も、第１の発明と同様に、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【発明の効果】
【００３８】
この発明によれば、消費電力相関値から実行されるアプリケーションの動作状態を判断して、アプリケーションを終了させることができるため、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【００３９】
この発明の上述の目的、その他の目的、特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００４０】
図１を参照して、携帯端末１０は、二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給する電源回路２８を含む。また、電源回路２８が二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給している場合には、電源オン状態と呼ぶことにする。同様に、電源回路２８が二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給していない場合には、電源オフ状態と呼ぶことにする。電源回路２８は、電源オフ状態で、入力受け付け手段であるキー入力装置２２によって電源オン操作がされると起動され、電源オフ状態で、キー入力装置２２による電源オフ操作がされると停止される。さらに、電源オフ状態であっても、電源回路２８は、リチウムイオン電池３０の充電に応答して起動され、リチウムイオン電池３０の充電が完了するのに応答して停止される。また、充電とは、リチウムイオン電池３０が図示しない外部充電器から電流の供給を受けることで、電気エネルギーを蓄えることを言う。
【００４１】
キー入力装置２２によって発呼操作が行われると、ＣＰＵ２０（プロセサまたはコンピュータと呼ばれることもある。）は、ＣＤＭＡ方式に対応する無線通信回路１４を制御して発呼信号を出力する。出力された発呼信号は、アンテナ１２から送出され、基地局を含む移動通信網に送信される。そして、通話相手が応答操作を行うと、通話可能状態が確立される。また、無線通信回路１４は、基地局との送受信を行う送受信回路１４ａと、受話音声信号などのアナログ信号をデジタル信号に変調または高周波信号などのデジタル信号をアナログ信号に復調するＢＢ（ＢａｓｅＢａｎｄ）回路１４ｂなどを含む。
【００４２】
通話可能状態に移行した後にキー入力装置２２によって通話終了操作が行われると、ＣＰＵ２０は、無線通信回路１４を制御して、基地局を含む移動通信網に通話終了信号を送信する。通話終了信号の送信後、ＣＰＵ２０は、通話処理を終了する。また、先に通話相手から通話終了信号を受信した場合も、ＣＰＵ２０は、通話処理を終了する。さらに、通話相手によらず、移動通信網から通話終了信号を受信した場合も、ＣＰＵ２０は通話処理を終了する。
【００４３】
携帯端末１０の電源がオンである状態で通話相手からの発呼信号がアンテナ１２によって捉えられると、無線通信回路１４は、着信をＣＰＵ２０に通知する。ＣＰＵ２０は、着信通知に記述された発信元情報をＬＣＤ制御回路３２に制御されるＬＣＤモニタ３４に表示させ、図示しない着信通知用のスピーカから着信音を出力する。キー入力装置２２によって応答操作が行われると、通話可能状態が確立される。また、ＬＣＤ制御回路３２は、電源回路２８から電圧を供給され、ＬＣＤ制御回路３２自身とＬＣＤモニタ３４とを駆動させる。
【００４４】
通話可能状態では、次のような処理が実行される。通話相手から送信された変調音声信号（高周波信号）は、アンテナ１２によって受信される。受信された変調音声信号は、無線通信回路１４によって復調処理および復号処理を施される。これによって得られた受話音声信号は、スピーカ１８から出力される。また、マイク１６によって取り込まれた送話音声信号は、無線通信回路１４によって符号化処理および変調処理を施される。これによって生成された変調音声信号は、上述と同様、アンテナ１２を利用して送信される。
【００４５】
携帯端末１０は、カメラアプリケーションを実行することが可能である。カメラアプリケーションは、オートフォーカス処理によって、被写体にピントの合った写真画像データを記憶する。具体的には、キー入力装置２２によってカメラアプリケーションを実行する操作が行われると、ＣＰＵ２０は、カメラ制御回路３６にカメラアプリケーションを実行するために必要な命令を与える。カメラ制御回路３６は、イメージセンサ３８およびフォーカスレンズ４０を制御し、イメージセンサ３８によって取得された披写界の光学像を写真画像データに変換する。そして、ＣＰＵ２０は、カメラ制御回路３６から得られる、被写体にピントを合わせた写真画像データを圧縮画像データに変換してフラッシュメモリ２４に記憶する。また、このカメラアプリケーションでは、撮影する写真画像のサイズをＷＱＶＧＡ（２４０×４００）、ＶＧＡ（６４０×４８０）およびＵＸＧＡ（１６００×１２００）から選択することが可能である。
【００４６】
また、キー入力装置２２によってネットワーク１００を介するデータ通信操作が行われると、ＣＰＵ２０は、無線通信回路１４を制御して天気情報サーバ１１０とのデータ通信を行う。天気情報サーバ１１０はＨＤＤ１１２を備え、ＨＤＤ１１２には最新の天気図の画像データおよびその天気図の画像データに対応する気象予報士のコメントを録音した音声データが記憶される。つまり、携帯端末１０の使用者は、携帯端末１０によって天気情報サーバ１１０とのデータ通信を行うことで、最新の天気図および気象予報士のコメントなどを容易に得ることができる。
【００４７】
図２は、電源回路２８の詳細な構成を示す図解図である。電源回路２８は、制御部２８ａ、計測部２８ｂ、変圧部２８ｃ、供給部２８ｄおよび抵抗Ｒから構成される。制御部２８ａは、電源回路２８用のＣＰＵであり、たとえば、供給部２８ｄを制御することで、システム全体に供給する電圧を制御する。
【００４８】
計測部２８ｂは、たとえばデジタル電圧計であり、計測手段として機能する。そして、計測部２８ｂは、抵抗Ｒの両端から得られる電圧値を計測し、制御部２８ａに出力する。この抵抗Ｒは、リチウムイオン電池３０から供給される電圧の電圧値を計測するために、電源回路２８とリチウムイオン電池３０との間に設けられる。たとえば、計測部２８ｂが計測した電圧値が、３．６８Ｖであれば、「３．６８」の数値が制御部２８ａに出力される。
【００４９】
そして、制御部２８ａは、所定時間毎、たとえば１００ｍｓ毎に計測部２８ｂから出力された電圧値をＲＡＭ２６に記憶させる。たとえば、制御部２８ａは、計測部２８ｂから「３．６８」の数値が出力されていれば、ＲＡＭ２６に「３．６８」の数値を記憶させる。また、ＲＡＭ２６は、ＣＰＵ２０と制御部２８ａとからデータの書き込みが可能なデュアルポートＲＡＭであり、記憶手段として機能する。
【００５０】
また、制御部２８ａは５秒間毎にＣＰＵ２０へ通知を行い、ＣＰＵ２０は５秒間毎にＲＡＭ２６に蓄積された電圧値のログデータを取得する。なお、電圧値を計測する周期は、１００ｍｓより短い時間であってもよいし、１００ｍｓより長い時間であってもよい。
【００５１】
変圧部２８ｃは、リチウムイオン電池３０から取得した電圧を昇圧または降圧することで、携帯端末１０に内蔵される複数の回路のそれぞれに適した電圧に変圧する。また、変圧部２８ｃは、複数の異なる電圧を出力することが可能である。供給部２８ｄは、変圧部２８ｃから得られた電圧を、制御部２８ａに指示された複数の回路のそれぞれに供給する。たとえば、制御部２８ａは、ＣＰＵ２０からＬＣＤ制御回路３２への電圧供給を停止する指示がされると、供給部２８ｄを制御することでＬＣＤ制御回路３２への電圧供給を停止する。
【００５２】
なお、他の実施例では、内蔵ＲＡＭを備える電源回路２８を利用し、シングルポートＲＡＭを利用するようにしてもよい。つまり、制御部２８ａは、１００ｍｓ毎に計測部２８ｂから出力された電圧値を内蔵ＲＡＭに記憶し、制御部２８ａは、５秒間毎にＣＰＵ２０へ通知を行うとともに、内蔵ＲＡＭに記憶した電圧値のログデータをＣＰＵ２０に出力する。
【００５３】
ＣＰＵ２０は、携帯端末１０の消費電力を抑えるために、通常状態から省電力状態に遷移させることが可能である。具体的には、省電力状態では、キー入力装置２２によって一定時間のキー入力が検出されない場合に、ＬＣＤ制御回路３２への電圧供給を停止し、ＬＣＤモニタ３４およびＬＣＤ制御回路３２の電源をオフにすることで、消費電力を抑える。さらに、省電力状態では、ＬＣＤ制御回路３２の電源をオフにした後に、間欠受信を行うことで消費電力を抑える。間欠受信とは、５秒間毎にＣＰＵ２０が無線通信回路１４の電源をオンして無線通信を行い、無線通信を行わない間は、無線通信回路１４の電源がオフにされる。そして、制御部２８ａからＣＰＵ２０への５秒間毎の通知は、間欠受信のタイミングと同期される。つまり、ＣＰＵ２０は、間欠受信を行うときに、制御部２８ａからの通知に基づいて、電圧値のログデータを取得する。
【００５４】
なお、電流値がＲＡＭ２６に記録され始めるのは、ＬＣＤ制御回路３２の電源をオフにした後に、一定間（たとえば、３分）経過してからとする。また、本実施例の通常状態とは、消費電力が制限されることなく携帯端末１０が動作している状態とする。さらに、間欠受信のタイミングは５秒間毎に限らず、携帯電話会社毎に、任意のタイミングであってもよい。
【００５５】
ここで、省電力状態におけるＣＰＵ２０によって実行されるアプリケーションを強制終了させることで、省電力状態における携帯端末１０の消費電力をさらに抑える制御について説明する。
【００５６】
具体的には、実行されるアプリケーションのそれぞれは、強制終了可能か不可能かの属性情報が設定される。そして、ＣＰＵ２０は、実行されるアプリケーションを管理し、５秒間分の電圧値のログデータから、消費電力に相関する値（消費電力相関値）として、電流値の平均値（平均電流値）を求め、閾値を超えていれば、強制終了可能な属性情報を持つアプリケーションを強制終了させる。つまり、閾値を超えている場合には、想定外の電力が消費されていると判断することができる。
【００５７】
図３は、実行アプリ一覧テーブルの詳細を示す図解図である。この実行アプリ一覧テーブルは、ＣＰＵ２０によって実行されるアプリケーションの一覧が記憶される。アプリＩＤの欄には、ＣＰＵ２０が実行するアプリケーションを識別するための識別情報として、「００ＦＦ」などの１６進数値が記憶される。また、アプリケーション名の欄には、アプリＩＤに対応するアプリケーション名が記憶される。たとえば、アプリＩＤが「００ＦＦ」であれば天気情報取得アプリケーションであり、アプリＩＤが「０１００」であればブラウザアプリケーションであり、アプリＩＤが「０１０１」であればカメラアプリケーションである。
【００５８】
この天気情報取得アプリケーションは、定期的に天気情報サーバ１１０とのデータ通信を行い、最新の天気図や、天気予報士のコメントを録音した音声データなどを取得するアプリケーションである。また、図４は、天気情報取得アプリケーションによって取得された天気図の表示例を示す図解図である。ＬＣＤモニタ３２には、状態表示範囲５０および画像表示範囲５２が表示される。状態表示範囲５０には、アンテナ１２の感度、リチウムイオン電池３０の電池残容量および現在時刻などが表示される。画像表示範囲５２には、天気情報取得アプリケーションによって取得された天気図が表示される。また、状態表示範囲５０および画像表示範囲５２については、他の表示例について同様であるため、他の表示例では簡単のため詳細な説明を省略する。
【００５９】
なお、画像表示範囲５２には、実行された機能（アプリケーション）に応じて様々な画像が表示される。また、携帯電話１０の待機状態で表示する画像を「壁紙画像」と呼ぶ。
【００６０】
図３に戻って、ブラウザアプリケーションは、天気情報サーバ１１０以外のサーバとデータ通信を行うことで、画像や文字列のデータを取得するアプリケーションである。たとえば、使用者は、壁紙画像を配布するサイトなどにアクセスすることで、様々な壁紙画像を取得することができる。また、壁紙画像を配布するサイトには、壁紙画像を表示すると、壁紙画像に対する料金を払う必要がある「有料サイト」もある。
【００６１】
図５は、強制終了テーブルの詳細を示す図解図である。強制終了テーブルは、省電力状態で平均電流値が閾値を超えた場合に、強制終了されたアプリケーションのアプリＩＤ、アプリケーション名およびその強制終了されたアプリケーションの動作状態を記憶するためのテーブルである。アプリＩＤの欄には、強制終了されたアプリケーションのアプリＩＤが記憶される。アプリケーション名の欄には、アプリＩＤの欄に対応して強制終了されたアプリケーションの名前が記憶される。そして、動作状態の欄には、アプリＩＤの欄に対応して強制終了されたアプリケーションの動作状態が記憶される。つまり、図５に示す強制終了テーブルには、アプリＩＤが「０１００」、つまりブラウザアプリケーションが、「ｈｔｔｐ：／／ｗｐａｐｅｒ．ｎｅ．ｊｐ」のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）で示される有料サイトを閲覧中に強制終了され、アプリＩＤが「０１０１」、つまりカメラアプリケーションが「ＶＧＡ撮影モード」で動作中に強制終了されたことが記憶される。
【００６２】
図６は、強制終了不可テーブルの詳細を示す図解図である。強制終了不可テーブルは、省電力状態で平均電流値が閾値を超えたとしても、強制終了させることができないアプリケーションのアプリＩＤおよびアプリケーション名を記憶するためのテーブルである。アプリＩＤの欄は、強制終了させることができないアプリケーションのアプリＩＤを記憶する。アプリケーション名の欄は、アプリＩＤの欄に対応して、アプリケーション名が記憶される。
【００６３】
図７は、属性情報テーブルの詳細を示す図解図である。属性情報テーブルは、携帯端末１０で実行されるアプリケーション全ての属性情報を記憶するテーブルであり、属性情報とは、強制終了可能か不可能かを示す終了属性情報と、強制復帰可能か不可能かを示す復帰属性情報とである。アプリＩＤの欄には、携帯端末１０で実行されるアプリケーションのアプリＩＤが記憶される。アプリケーション名の欄は、アプリＩＤの欄に対応してアプリケーションの名前が記憶される。終了属性の欄には、アプリＩＤの欄に対応して、「可」または「不可」が記憶される。つまり、終了属性の欄において、「可」は強制終了可能である終了属性情報を示し、「不可」は強制終了不可能である終了属性情報を示す。
【００６４】
たとえば、強制終了させることができるブラウザアプリケーションおよびカメラアプリケーションが記憶される行の終了属性の欄には「可」が記憶される。一方、強制終了させることができない天気情報取得アプリケーションが記憶される行の終了属性の欄には「不可」が記憶される。つまり、天気情報取得アプリケーションは、定期的に最新の天気図などの天気情報を取得するため、省電力状態でも最新の天気図を取得するように、終了属性が「不可」として記憶される。
【００６５】
また、アプリケーションを強制終了させた後に、省電力状態でなくなった場合に、強制終了されたアプリケーションを強制復帰させるか否かを示す復帰属性が記憶される。復帰属性の欄には、「可」、「不可」または「−」が記憶される。つまり、復帰属性の欄において、「可」は強制復帰可能である復帰属性情報を示し、「不可」は強制復帰不可能である復帰属性情報を示し、「−」は復帰属性情報が記憶されていないことを示す。また、「−」は、終了属性が「不可」である場合に記憶される。
【００６６】
たとえば、強制復帰させることができるカメラアプリケーションが記憶される行の復帰属性の欄には「可」が記憶される。また、強制復帰させることができないブラウザアプリケーションが記憶される行の復帰属性の欄には「不可」が記憶される。そして、終了属性の欄に「不可」が記憶される天気情報取得アプリケーションが記憶される行の復帰属性の欄には「−」が記憶される。
【００６７】
また、属性情報テーブルに記憶される終了属性と復帰属性とは、携帯端末１０にプレインストールされているアプリケーションの場合には、携帯端末１０の設計者によって予め設定される。そして、使用者によってインストールされるアプリケーションの場合には、インストールするときに、終了属性および復帰属性が設定される。ただし、使用者によってインストールされるアプリケーションが属性情報テーブルに終了属性および復帰属性を設定する仕様になっていなければ、終了属性が「不可」と記憶される。
【００６８】
さらに、携帯端末１０の設計者または使用者は、属性情報テーブルの内容を任意に変更可能なアプリケーションを設定することで、有料サイトなどを閲覧中のブラウザアプリケーションが終了されたとき、復帰することで追加料金を請求されないように、ブラウザアプリケーションが復帰されないように設定することができる。
【００６９】
図８は、ＲＡＭ２６のメモリマップを示す図解図である。ＲＡＭ２６のメモリマップ３００には、プログラム記憶領域３０２およびデータ記憶領域３０４が含まれる。プログラムおよびデータの一部は、フラッシュメモリ２４から一度にまたは必要に応じて部分的にかつ順次的に読み出され、ＲＡＭ２６に記憶され、そしてＣＰＵ２０などで処理される。
【００７０】
プログラム記憶領域３０２は、携帯端末１０を動作させるためのプログラムを記憶する。携帯端末１０を動作させるためのプログラムは、アプリケーション管理プログラム３１０、省電力プログラム３１２、電流値監視プログラム３１４、強制終了／強制復帰制御プログラム３１６および天気情報取得プログラム３１８などから構成される。アプリケーション管理プログラム３１０は、使用者の操作に応じて携帯端末１０で実行されるプログラムの一覧を表示するためのプログラムであり、図３に示す実行アプリ一覧テーブルを作成する。省電力プログラム３１２は、リチウムイオン電池３０の消費電力を抑えるためのプログラムであり、通常状態でキー入力装置２２によって一定時間のキー入力が検出されない場合に携帯端末１０を通常状態から省電力状態に遷移させる。さらに、省電力プログラム３１２は、省電力状態でキー入力装置２２によってキー入力が検出された場合に省電力状態から通常状態に遷移させる。
【００７１】
電流値監視プログラム３１４は、リチウムイオン電池３０の電流値を監視するためのプログラムである。強制終了／強制復帰制御プログラム３１６は、省電力状態においてＣＰＵ２０で実行されるアプリケーションの強制終了と、終了されたアプリケーションの強制復帰とを制御するためのプログラムである。天気情報取得プログラム３１８は、天気情報サーバ１１０から、定期的に最新の天気情報を取得するためのプログラムである。また、この天気情報取得プログラム３１８は、使用者によってインストールされたプログラムである。
【００７２】
なお、図示は省略するが、携帯端末１０を動作させるためのプログラムは、通話を行うためのプログラム、メールの送受信を行うプログラム、カメラアプリケーションを実行するためのプログラム、ブラウザアプリケーションを実行するためのプログラムなども含む。
【００７３】
データ記憶領域３０４には、ダウンロードデータバッファ３３０が設けられる。また、データ記憶領域３０４には、天気情報データ３３２、電圧値ログデータ３３４、実行アプリ一覧テーブルデータ３３６、強制終了不可テーブルデータ３３８、強制終了テーブルデータ３４０、属性情報テーブルデータ３４２および写真画像データ３４４が記憶されるとともに、省電力フラグ３４６および電流値フラグ３４８が設けられる。
【００７４】
ダウンロードデータバッファ３３０は、ブラウザアプリケーションによって取得した文字列や画像を、ＬＣＤモニタ３４に表示するために一時記憶するためのバッファである。
【００７５】
天気情報データ３３２は、天気情報取得アプリケーションによって取得された最新の天気情報のデータである。また、定期的に最新の天気情報を取得する度に、天気情報データ３３２は更新される。電圧値ログデータ３３４は、計測部２８ｂによって計測されたリチウムイオン電池３０の電圧値から構成される。また、電圧値ログデータ３３４は、ＣＰＵ２０によって読み出される毎にリセットされる。実行アプリ一覧テーブルデータ３３６は、アプリケーション管理プログラム３１０によって作成され、図３に示すテーブルデータである。また、実行アプリ一覧テーブルデータ３３６に記憶されるアプリＩＤおよびアプリケーション名は、ＣＰＵ２０によって実行されるアプリケーションによって変化する。強制終了不可テーブルデータ３３８は、省電力状態で平均電流値が閾値を超えたとしても、強制終了させることができないアプリケーションのアプリＩＤおよびアプリケーション名を記憶するためのテーブルデータ（図６参照）である。
【００７６】
強制終了テーブルデータ３４０は、省電力状態で平均電流値が閾値を超えた場合に、強制終了されたアプリケーションのアプリＩＤ、アプリケーション名およびその強制終了されたアプリケーションの動作状態を記憶するためのテーブルデータ（図５参照）である。属性情報データ３４２は、携帯端末１０で実行することが可能な各アプリケーションの終了属性と復帰属性とを記憶するテーブルデータ（図７参照）である。写真画像データ３４６は、カメラアプリケーションによって撮影された写真画像のデータである。
【００７７】
省電力フラグ３４６は、携帯端末１０の状態が省電力状態であるかを判断するフラグである。たとえば、省電力フラグ３４６は、１ビットのレジスタで構成される。省電力フラグ３４６が成立（オン）されると、レジスタにはデータ値「１」が設定され、省電力フラグ３４６が不成立（オフ）されると、レジスタにはデータ値「０」が設定される。また、省電力フラグ３４６のオン／オフは省電力プログラムによって切り替えられる。
【００７８】
電流値フラグ３４８は、平均電流値が閾値を超えたか否かを判断するフラグである。たとえば、電流値フラグ３４８は、１ビットのレジスタで構成される。電流値フラグ３４８が成立（オン）されると、レジスタにはデータ値「１」が設定され、電流値フラグ３４８が不成立（オフ）されると、レジスタにはデータ値「０」が設定される。
【００７９】
なお、図示は省略するが、データ記憶領域３０４には、アドレス帳のデータなどが記憶されるとともに、携帯端末１０の動作に必要な他のカウンタやフラグも設けられる。
【００８０】
ＣＰＵ２０は、図９に示す電流値監視処理および図１０−図１２に示す強制終了／強制復帰制御処理などを含むタスクを並列的に実行する。
【００８１】
図９は電流値監視処理を示すフロー図である。図９を参照して、ステップＳ１では、電源回路２８からの通知が有るか否かを判断する。つまり、制御部２８ａが５秒間毎に行う通知があったか否かを判断する。ステップＳ１で“ＮＯ”であれば、つまり制御部２８ａからの通知がなければ、ステップＳ１の処理を繰り返し実行する。一方、ステップＳ１で“ＹＥＳ”であれば、つまり制御部２８ａからの通知が有れば、ステップＳ３で電圧値ログデータ３３４を取得する。つまり、５秒間分のリチウムイオン電池３０の電圧値のログデータをＲＡＭ２６から取得する。続いて、ステップＳ５では、電流値に変換する。つまり、ＲＡＭ２６から取得した電圧値のそれぞれを数１に基づいて、電流値に変換する。また、抵抗Ｒとは、図２に示す、計測部２８ｂとリチウムイオン電池３０との間に設けられた抵抗Ｒである。なお、数１に示す右辺の分母は、リチウムイオン電池３０の内部抵抗などを考慮した抵抗値であってもよい。
【００８２】
［数１］
電流値＝取得した電圧値／抵抗Ｒの抵抗値
続いて、ステップＳ７では、平均電流値を算出する。つまり、変換した５秒間分の電流値を平均して平均電流値を算出する。したがって、ステップ３で、５秒間分の電圧値のログデータをＲＡＭ２６から取得し、ステップＳ５で、取得した電圧値のログデータを電流値に変換し、ステップＳ７で、変換した５秒間分の平均電流値を算出するため、ステップＳ３−Ｓ７の処理を実行するＣＰＵ２０は、消費電力相関値を取得する取得手段として機能する。さらに、ステップＳ５、Ｓ７で電圧値のログデータから消費電力相関値を算出するため、ステップＳ５、Ｓ７の処理を実行するＣＰＵ２０は、算出手段として機能する。
【００８３】
続いて、ステップＳ９では、平均電流値が閾値を超えているか否かを判断する。この閾値とは、携帯端末１０を駆動させるために最低限必要なアプリケーションが実行された状態での平均電流値を閾値とする。つまり、ステップＳ７で算出された平均電流値が、携帯端末１０を駆動させるために最低限必要なアプリケーションが実行された状態での平均電流値を超えているか否かを判断する。なお、閾値は、携帯端末１０が工場から出荷されたときに設定される。また、閾値は、使用者によって任意に設定できるようになっていてもよい。
【００８４】
ステップＳ９で“ＹＥＳ”であれば、つまり平均電流値が閾値を超えていれば、ステップＳ１１で電流値フラグ３４８をオンにして、ステップＳ１に戻る。一方、ステップＳ９で“ＮＯ”であれば、つまり平均電流値が閾値を超えていなければ、電流値フラグ３４８をオフにして、ステップＳ１に戻る。
【００８５】
図１０は強制終了／強制復帰制御処理を示すフロー図である。ステップＳ２１では、省電力状態か否かを判断する。つまり、省電力フラグ３４６がオンであるか否かを判断する。したがって、ステップＳ２１の処理を実行するＣＰＵ２０は、判断手段として機能する。
【００８６】
ステップＳ２１で“ＮＯ”であれば、つまり省電力フラグ３４６がオフであれば、ステップＳ２１の処理を繰り返し実行する。一方、ステップＳ２１で“ＹＥＳ”であれば、つまり省電力フラグ３４６がオンであれば、ステップＳ２３で実行中のアプリケーションが有るか否かを判断する。つまり、図３に示す実行アプリ一覧テーブルを参照して、実行中のアプリケーションが有るか否かを判断する。ステップＳ２３で“ＮＯ”であれば、つまり実行中のアプリケーションがなければ、ステップＳ２１に戻る。一方、“ＹＥＳ”であれば、つまり実行中のアプリケーションが有れば、ステップＳ２５で電流値フラグ３４８がオンであるか否かを判断する。つまり、消費電力相関値である平均電流値が閾値を超えたか否かを判断する。
【００８７】
ステップＳ２５で“ＮＯ”であれば、つまり電流値フラグ３４８がオフであればステップＳ２１に戻る。一方、ステップＳ２５で“ＹＥＳ”であれば、つまり電流値フラグ３４８がオンであれば、ステップＳ２７で強制終了不可のアプリケーションが実行中か否かを判断する。つまり、実行アプリ一覧テーブルに記憶される複数のアプリＩＤを取得し、図７に示す属性情報テーブルのアプリＩＤの欄において、取得したアプリＩＤを検索し、実行中のアプリケーションのそれぞれの終了属性が「不可」であるか否かを判断する。
【００８８】
ステップＳ２７で“ＮＯ”であれば、つまり終了属性が「不可」のアプリケーションが実行されていなければ、ステップＳ３１に進む。一方、ステップＳ２７で“ＹＥＳ”であれば、つまり終了属性が「不可」のアプリケーションが実行されていれば、ステップＳ２９で強制終了できないアプリケーションのアプリＩＤを記憶する。つまり、図６に示す強制終了不可テーブルに、強制終了できないアプリケーションのアプリＩＤを記憶する。したがって、ステップＳ２９の処理を実行するＣＰＵ２０は、識別情報記憶手段として機能する。
【００８９】
たとえば、天気情報取得アプリケーションが実行されていれば、実行アプリ一覧テーブルには、天気情報取得アプリケーションのアプリＩＤ「００ＦＦ」を取得することができる。そして、属性情報テーブルのアプリＩＤにおいて、取得したアプリＩＤ「００ＦＦ」を検索すると、アプリＩＤの欄に「００ＦＦ」が記憶される行に対応する終了属性が「不可」であるため、ステップＳ２７では“ＹＥＳ”と判断され、ステップＳ２９で、天気情報取得アプリケーションのアプリＩＤおよびアプリケーション名が強制終了不可テーブルに記憶される。
【００９０】
ステップＳ３１では、強制終了可能なアプリケーションが実行中か否かを判断する。つまり、実行アプリ一覧テーブルに記憶される各アプリＩＤを取得し、属性情報テーブルのアプリＩＤの欄において取得したアプリＩＤを検索し、実行中のアプリケーションそれぞれの終了属性が「可」であるか否かを判断する。ステップＳ３１で“ＮＯ”であれば、つまり終了属性が「可」のアプリケーションが実行されていなければ、ステップＳ３７に進む。一方、ステップＳ３１で“ＹＥＳ”であれば、つまり終了属性が「可」のアプリケーションが実行されていれば、ステップＳ３３で強制終了するアプリケーションのアプリＩＤおよび動作状態を記憶する。つまり、終了属性が「可」である実行中のアプリケーションのアプリＩＤおよび動作状態を記憶する。したがって、ステップＳ３３の処理を実行するＣＰＵ２０は、識別情報記憶手段として機能する。なお、処理を行う順番は異なるが、本実施例では、ステップＳ３３の処理を実行するＣＰＵ２０が第１識別情報記憶手段として機能し、ステップＳ２９の処理を実行するＣＰＵ２０が第２識別情報記憶手段として機能する。
【００９１】
たとえば、図５を参照して、終了属性が「可」であり、壁紙画像を表示する有料サイトを表示中のブラウザアプリケーションと、ＶＧＡ撮影モードのカメラアプリケーションとが実行中である場合に、強制終了テーブルには、ブラウザアプリケーションのアプリＩＤと、アプリケーション名と、壁紙画像を表示する有料サイトのＵＲＬおよび「有料サイト閲覧中」の文字列とが記憶される。さらに、強制終了テーブルには、カメラアプリケーションのアプリＩＤと、アプリケーション名と、ＶＧＡ撮影モードであることを示す文字列が記憶される。
【００９２】
続いて、ステップＳ３５では、強制終了可能なアプリケーションを終了する。つまり、終了属性が「可」である実行中のアプリケーションを終了する。また、実行中のアプリケーションを終了と同時に、実行アプリ一覧テーブルを更新する。そして、ステップＳ３５の処理を実行するＣＰＵ２０は、終了手段として機能する。
【００９３】
続いて図１１を参照して、ステップＳ３７では、省電力状態を解除したか否かを判断する。つまり、省電力フラグ３４６がオフにされたか否かを判断する。したがって、ステップＳ２１の処理を実行するＣＰＵ２０と同様に、ステップＳ３７の処理を実行するＣＰＵ２０は、判断手段として機能する。
【００９４】
ステップＳ３７で“ＮＯ”であれば、つまり省電力フラグ３４６がオンであれば、ステップＳ３７の処理を繰り返し実行する。一方、“ＹＥＳ”であれば、たとえば、キー入力装置２２に対してキー入力がされ、省電力フラグ３４６がオフにされば、ステップＳ３９で強制終了不可のアプリケーションが実行されていたか否かを判断する。つまり、強制終了不可テーブルにおいて、アプリＩＤおよびアプリケーション名が記憶されているか否かを判断する。ステップＳ３９で“ＮＯ”であれば、つまり強制終了不可テーブルにアプリＩＤおよびアプリケーション名が記憶されていなければ、ステップＳ４７に進む。
【００９５】
また、ステップＳ３９で“ＹＥＳ”であれば、つまり強制終了不可テーブルにアプリＩＤおよびアプリケーション名が記憶されていれば、ステップＳ４１で強制終了不可のアプリケーションの属性を変更するか否かを確認する。つまり、強制終了不可テーブルに記憶されたアプリケーションの終了属性を変更するポップアップをＬＣＤモニタ３４に表示する。たとえば、図６に示す強制終不可テーブルに、天気情報取得アプリケーションが記憶されていれば、図１３（Ａ）に示すポップアップが表示される。図１３（Ａ）を参照して、壁紙画像を表示する画像表示範囲５２には、ポップアップ５４が表示される。さらに、ポップアップ５４内には、天気情報取得アプリケーションの名前を含んで、終了属性を変更するか否かを確認する文章と、キー入力装置２２によってチェックすることが可能なチェックボックス５４ａ、５４ｂとが表示される。したがって、ステップＳ４１の処理を実行するＣＰＵ２０は、第１表示手段として機能する。
【００９６】
続いて図１１に戻って、ステップＳ４３で属性を変更する操作がされたか否かを判断する。たとえば、図１３（Ａ）に示すポップアップ５４内のチェックボックス５４ａ、５４ｂにおいて、終了属性を変更することを認めるチェックボックス５４ａにチェックがされた後に、確定操作がされたか否かを判断する。ステップＳ４３で“ＮＯ”であれば、つまりチェックボックス５４ｂにチェックがされた後に確定操作がされれば、ステップＳ４７に進む。一方、ステップＳ４３で“ＹＥＳ”であれば、つまりチェックボックス５４ａにチェックがされた後に確定操作がされれば、ステップＳ４５で強制終了不可のアプリケーションの属性を強制終了可に変更する。つまり、終了属性を変更するか否かを確認したアプリケーションにおいて、属性情報テーブルに記憶される終了属性を「不可」から「可」に変更する。たとえば、天気情報取得アプリケーションの終了属性が「不可」から「可」に変更される。したがって、ステップＳ４５の処理を実行するＣＰＵ２０は、第１変更手段として機能する。なお、天気情報取得アプリケーションの終了属性が「不可」から「可」に変更されると、復帰属性は「不可」に設定される。
【００９７】
これによって、使用者は、省電力状態で強制終了されなかったアプリケーションについて、次に省電力状態に遷移したときには強制終了されるように、終了属性を変更することができる。
【００９８】
なお、復帰属性は「可」に設定されるようになっていてもよいし、アプリケーションの種類によって、「可」または「不可」が選択されるようになっていてもよい。また、終了属性が「不可」のアプリケーションが複数実行される場合には、それぞれのアプリケーションにおいて、終了属性を変更するか否かが確認される。
【００９９】
続いて、ステップＳ４７では、強制終了されたアプリケーションが有るか否かを判断する。つまり、強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されているか否かを判断する。ステップＳ４７で“ＮＯ”であれば、つまり強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されていなければ、ステップＳ４９で各テーブルをリセットし、ステップＳ２１に戻る。つまり、強制終了テーブルと強制終了不可テーブルとに記憶されている各項目を消去する。
【０１００】
また、ステップＳ４７で“ＹＥＳ”であれば、つまり強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されていれば、図１２に示すステップＳ５１で強制復帰不可のアプリケーションが有るか否かを判断する。つまり、強制終了テーブルに記憶されるアプリＩＤを取得し、属性情報テーブルのアプリＩＤの欄において、取得したアプリＩＤを検索する。そして、該当するアプリケーションの復帰属性が「不可」であるか否かを判断する。ステップＳ５１で“ＮＯ”であれば、つまり復帰属性が「不可」のアプリケーションが実行されていなければ、ステップＳ５９に進む。一方、ステップＳ５１で“ＹＥＳ”であれば、つまり復帰属性が「不可」のアプリケーションが実行されていれば、ステップＳ５３で強制復帰不可のアプリケーションの属性を変更するか否かを確認する。つまり、アプリケーションの復帰属性を「不可」から「可」に変更するか否かを確認する。たとえば、復帰属性が「不可」のブラウザアプリケーションが実行されていた場合に、図１３（Ｂ）に示すポップアップ５６が表示される。図１３（Ｂ）を参照して、画像表示範囲５２には、ポップアップ５６が表示される。さらに、ポップアップ５６内には、ブラウザアプリケーションの名前を含めて、復帰属性を変更するか否かを確認する文章と、キー入力装置２２によって入力可能なチェックボックス５６ａ、５６ｂとが表示される。したがって、ステップＳ５３の処理を実行するＣＰＵ２０は、第２表示手段として機能する。
【０１０１】
続いて、ステップＳ５５では、属性情報を変更する操作がされたか否かを判断する。たとえば、図１３（Ｂ）に示すポップアップ５６内のチェックボックス５６ａ、５６ｂにおいて、復帰属性を変更することを認めるチェックボックス５６ａにチェックされた後に、確定操作がされたか否かを判断する。ステップＳ５５で“ＮＯ”であれば、つまりチェックボックス５６ｂにチェックがされた後に確定操作がされれば、ステップＳ５９に進む。一方、ステップＳ５５で“ＹＥＳ”であれば、つまりチェックボックス５６ａにチェックがされた後に確定操作がされれば、ステップＳ５７で強制復帰不可のアプリケーションの属性を強制復帰に変更する。したがって、ステップＳ５７の処理を実行するＣＰＵ２０は、第２変更手段として機能する。
【０１０２】
たとえば、図１３（Ｂ）を参照して、チェックボックス５６ａにチェックがされた後に確定操作がされれば、属性情報テーブルの復帰属性の欄において、ブラウザアプリケーションの復帰属性が「不可」から「可」に変更される。つまり、使用者は、復帰されないように設定されているアプリケーションであっても、復帰属性を変更することで、復帰できるようにすることができる。
【０１０３】
なお、復帰属性が「不可」のアプリケーションが複数実行されていた場合には、それぞれのアプリケーションにおいて、復帰属性を変更するか否かを確認する。
【０１０４】
続いて、ステップＳ５９では、強制復帰可のアプリケーションが有るか否かを判断する。つまり、強制終了テーブルに登録されているアプリＩＤから、属性情報テーブルを参照して復帰情報が「可」のアプリケーションが記憶されているか否かを判断する。ステップＳ５９で“ＮＯ”であれば、つまり復帰情報が「可」のアプリケーションが強制復帰テーブルに記憶されていなければ、ステップＳ２１に戻る。一方、ステップＳ５９で“ＹＥＳ”であれば、つまり復帰情報が「可」のアプリケーションが強制復帰テーブルに記憶されていれば、ステップＳ６１で強制復帰可のアプリケーションを実行し、強制終了前の動作状態に復帰させる。たとえば、強制終了テーブルに記憶される、復帰属性が「可」であるカメラアプリケーションをＶＧＡ撮影モードで実行する。また、アプリケーションを復帰させると同時に、実行アプリ一覧テーブルを更新する。
【０１０５】
つまり、省電力状態でなくなれば、復帰属性が「可」の強制復帰させたアプリケーションは、強制終了される前の動作状態で実行される。よって、使用者は、省電力状態を意識することなくアプリケーションを実行させることができる。そして、ステップＳ６１の処理を実行するＣＰＵ２０は、復帰手段として機能する。
【０１０６】
続いて、ステップＳ６３では、各テーブルをリセットしてステップＳ２１に戻る。つまり、ステップＳ４９と同様に強制終了テーブルと強制終了不可テーブルとをリセットする。
【０１０７】
以上の説明から分かるように、携帯端末１０は、リチウムイオン電池３０を電源として用い、天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションを実行し、間欠受信をすることで、携帯端末１０の消費電力を抑える省電力状態または通常状態をとることが可能である。消費電力相関値である平均電流値は、ステップＳ３−Ｓ７の処理によって取得される。そして、省電力フラグ３４６がオンであるときに、終了属性が「可」のアプリケーションは、ステップＳ３５の処理によって強制終了される。
【０１０８】
さらに、省電力フラグ３４６がオフ、つまり省電力状態でなくなったときには、強制終了されたアプリケーションが強制復帰される。
【０１０９】
これによって、平均電流値からＣＰＵ２０によって実行されるアプリケーションの動作状態を判断し、アプリケーションを強制終了させることができるため、携帯端末１０では、アプリケーションの動作状態に基づいて携帯端末１０の消費電力を抑えることができる。
【０１１０】
また、ＣＰＵ２０によって実行されるアプリケーションの仕様が、天気情報取得アプリケーションのように、携帯端末１０の省電力状態が考慮されていなくとも、携帯端末１０の設計者が意図する省電力状態とすることができる。そして、本願発明は、事業者に申請することで誰でも開発することができるＢｒｅｗなどのアプリケーションプラットフォームを採用する携帯端末１０において大きな効果を発揮する。つまり、携帯端末１０の設計者とアプリケーションの設計者とは異なる会社であることが多いため、省電力状態で、携帯端末１０の設計者が意図しない動作を行うアプリケーションが開発されても、携帯端末１０の設計者が意図する省電力状態とすることができる。
【０１１１】
なお、携帯端末１０の消費電力相関値として平均電流値を用いたが、電池残容量の差分を利用してもよい。たとえば、消費電力相関値がリチウムイオン電池３０における電池残容量の差分であれば、まず、リチウムイオン電池３０における充電完了状態が１００％、放電状態が０％となる電池残容量値を、電圧値のログデータと同様に１００ｍｓ毎に記憶する。そして、各電池残容量値において直前の電池残容量値との差分値を求め、５秒間分の電池残容量値の差分値から平均差分値を求め、平均差分値が閾値を超えていれば、アプリケーションを強制終了するようにする。
【０１１２】
また、省電力プログラム３１２および電流監視プログラム３１４による処理は、携帯端末１０のミドルウェアまたはＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）によって処理されてもよい。
【０１１３】
さらに、携帯端末１０の通信方式には、ＣＤＭＡ方式、Ｗ‐ＣＤＭＡ方式、ＴＤＭＡ方式に限らず、ＰＨＳ方式などを採用してもよい。また、携帯電話１０のみに限らず、携帯型ゲーム機，携帯型音楽プレイヤおよびＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｅｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの電池を電源として採用する携帯端末１０であってもよい。
【０１１４】
さらに、強制終了されたアプリケーションまたは強制復帰するアプリケーションは、アドレス帳のアプリケーションや、ゲームのアプリケーションなどであってもよい。また、二次電池としてリチウムイオン電池３０を採用したが、鉛蓄電池、ニッケル水素電池、ナトリウムイオン電池、金属空気電池および亜鉛臭素電池などであってもよい。さらに、二次電池だけに限らず、燃料電池や、一次電池であるマンガン電池などでもよい。
【図面の簡単な説明】
【０１１５】
【図１】図１は本発明の一実施例の携帯端末を示すブロック図である。
【図２】図２は図１に示す電源回路の詳細な構成の一例を示す図解図である。
【図３】図３は図１に示すＲＡＭに記憶される実行アプリ一覧テーブルの詳細な構成を示す図解図である。
【図４】図４は図１に示す携帯端末で実行されるアプリケーションの表示例を示す図解図である。
【図５】図５は図１に示すＲＡＭに記憶される強制終了テーブルの詳細な構成を示す図解図である。
【図６】図６は図１に示すＲＡＭに記憶される強制終了不可テーブルの詳細な構成を示す図解図である。
【図７】図７は図１に示すＲＡＭに記憶される属性情報テーブルの詳細な構成を示す図解図である。
【図８】図８は図１に示すＲＡＭのメモリマップの一例を示す図解図である。
【図９】図９は図１に示すＣＰＵの電流値監視処理を示すフロー図である。
【図１０】図１０は図１に示すＣＰＵの強制終了／強制復帰制御処理を示すフロー図である。
【図１１】図１１は図１に示すＣＰＵの強制終了／強制復帰制御処理の他の一部であって、図１０に後続するフロー図である。
【図１２】図１２は図１に示すＣＰＵの強制終了／強制復帰制御処理のその他の一部であって、図１１に後続するフロー図である。
【図１３】図１３は図１に示すＬＣＤモニタに表示されるポップアップの表示例を示す図解図である。
【０１１６】
１０ … 携帯端末
２０ … ＣＰＵ
２２ … キー入力装置
２６ … ＲＡＭ
２８ … 電源回路
２８ａ …制御部
２８ｂ …計測部
３０ … リチウムイオン電池
３２ … ＬＣＤ制御回路
３４ … ＬＣＤモニタ
【技術分野】
【０００１】
この発明は、携帯端末に関し、特にたとえば電池を電源として利用する、携帯端末に関する。
【背景技術】
【０００２】
この種の装置の一例が、特許文献１に開示されている。この背景技術は、電池からの電圧が電源制御部によって送受信部、ベースバンド部、ＣＰＵ、ＬＣＤ制御部およびＬＣＤ駆動部などに供給されることで動作する携帯型無線通信装置である。ＬＣＤ駆動部には、ＬＣＤおよびキー操作部からのキー入力を伝えるＬＣＤ制御部が接続される。そして、キー操作部からのキー入力または着呼が一定時間なければ、電源制御部とＬＣＤ駆動部との間にあるスイッチがオフとなり、ＬＣＤ駆動部への電圧供給が停止され、ＬＣＤがオフ状態となる。つまり携帯型無線通信装置をパワーセービングモードに移行させる。
【０００３】
また、非特許文献１に開示されている背景技術では、携帯電話の消費電力を抑える「長持ちモード」について記載されている。この「長持ちモード」は、メインディスプレイ、キーおよびイルミネーションの照明や、サブディスプレイの表示時間や、ＥＺアプリおよびＰＣサイトビューアーによる処理の一部を制限することで、携帯電話の消費電力を抑える。
【特許文献１】特開平１０−３０４０３１号公報［H04M 1/00, H04Q 7/38］
【非特許文献１】Ｗ６４ＳＡ ｂｙ ＳＡＮＹＯ 取扱説明書 （６８−６９頁）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１の背景技術では、ＬＣＤ駆動部へ供給される電圧がスイッチによってオン／オフされることでパワーセービングモードに移行するが、ＣＰＵで実行されるアプリケーションを終了させることで、携帯型無線通信装置の消費電力を制御するような技術は開示されていない。
【０００５】
また、非特許文献１の「長持ちモード」では、ＥＺアプリおよびＰＣサイトビューアーによる処理の一部を制限することができるが、ＥＺアプリおよびＰＣサイトビューアーの動作状態に基づいて、処理を制限するようなことはできない。
【０００６】
また、コンピュータでは、キーボード操作が一定時間されない場合に、ＣＰＵを一時的に停止するスリープモードに移行させることで、消費電力を抑える技術が提案されているが、携帯電話のＣＰＵは、基地局との間欠受信を行うため、携帯電話のＣＰＵをスリープモードにすることはできない。
【０００７】
それゆえに、この発明の主たる目的は、新規な、携帯端末を提供することである。
【０００８】
この発明の他の目的は、アプリケーションの動作状態に基づいて携帯電話の消費電力を抑えることができる、携帯端末を提供することである。
【課題を解決するための手段】
【０００９】
この発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、この発明の理解を助けるために記述する実施形態との対応関係を示したものであって、この発明を何ら限定するものではない。
【００１０】
第１の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末であって、消費電力相関値を取得する取得手段、通常状態から省電力状態に遷移したかを判断する判断手段、および判断手段によって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了手段を備える。
【００１１】
第１の発明では、携帯端末（１０）は、電池（３０）を電源として用い、複数のアプリケーション（天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションなど）を実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能である。取得手段（２０、Ｓ３−Ｓ７）は、消費電力相関値を取得する。判断手段（２０、Ｓ２１、Ｓ３７）は、通常状態から省電力状態に遷移したかを判断する。終了手段（２０、Ｓ３５）は、判断手段によって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する。たとえば、消費電力は、携帯端末で実行されるアプリケーションの動作状態によって変動し、携帯端末で実行されるアプリケーションが多くなると、携帯端末の消費電力も大きくなる。そして、終了手段は、消費電力相関値が閾値より大きくなると、実行される複数のアプリケーションの少なくとも１つを終了する。
【００１２】
第１の発明によれば、消費電力相関値から携帯端末で実行されるアプリケーションの動作状態を判断して、アプリケーションを終了させることができるため、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。さらに、省電力状態を考慮しない仕様のアプリケーションが携帯端末に設定されたとしても、携帯端末の消費電力を抑えることができる。
【００１３】
第２の発明は、第１の発明に従属し、所定時間毎に電池の電圧値を計測する計測手段、および計測手段によって計測された電圧値を記憶する記憶手段をさらに備え、取得手段は、記憶手段によって記憶された電圧値から消費電力相関値を算出する算出手段を含む。
【００１４】
第２の発明では、計測手段（２８ｂ）は、所定時間（１００ｍｓ）毎に電池の電圧値を計測する。記憶手段（２６）は、計測手段によって計測された電圧値を記憶する。算出手段（２０、Ｓ５、Ｓ７）は、記憶手段によって記憶された電圧値から消費電力相関値を算出する。たとえば、消費電力相関値は、５秒間分の電圧値を電流値に変換した後に、５秒間分の電流値を平均した値である。つまり、算出手段は、電流値から平均電流値を算出し、取得手段は、平均電流値を消費電力相関値として取得する。
【００１５】
第２の発明によれば、電池から供給される電圧の電圧値を利用して、消費電力相関値を算出することができるようになる。
【００１６】
第３の発明は、第２の発明に従属し、記憶手段は、複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報を含む属性テーブルをさらに記憶し、終了手段は、属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる。
【００１７】
第３の発明では、記憶手段は、複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報（終了属性）を含む属性テーブル（３４２）をさらに記憶する。そして、終了手段は、属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる。
【００１８】
第３の発明によれば、使用者は、属性情報に従って終了させるアプリケーションを選択することができるため、省電力状態であっても終了させてはならないアプリケーションが終了されないように設定することができる。
【００１９】
第４の発明は、第３の発明に従属し、判断手段は、省電力状態から通常状態に遷移したかをさらに判断し、終了手段によって終了されたアプリケーションの識別情報を記憶する第１識別情報記憶手段、および判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第１識別情報記憶手段によって記憶された識別情報に基づいて、終了されたアプリケーションを復帰させる復帰手段をさらに備える。
【００２０】
第４の発明では、判断手段は、省電力状態から通常状態に遷移したかをさらに判断する。第１識別情報記憶手段（２０、Ｓ３３）は、終了手段によって終了されたアプリケーションの識別情報（アプリＩＤ）を記憶する。復帰手段（２０、Ｓ６１）は、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第１識別情報記憶手段によって記憶された識別情報に基づいて、終了されたアプリケーションを復帰させる。
【００２１】
第４の発明によれば、終了させたアプリケーションは、携帯端末が省電力状態から通常状態に遷移すれば復帰されるため、使用者は、省電力状態を意識することなく携帯端末のアプリケーションを実行させることができる。
【００２２】
第５の発明は、第３の発明または第４の発明に従属し、入力を受け付ける入力受け付け手段、判断手段によって通常状態から省電力状態に遷移したと判断されたとき、属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する第２識別情報記憶手段、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する第１表示手段、および第１表示手段によって終了されなかったアプリケーションの名前が表示された後に、入力受け付け手段が終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、終了されなかったアプリケーションの第１属性情報を終了可能に変更する第１変更手段をさらに備える。
【００２３】
第５の発明では、入力受け付け手段（２２）は、入力を受け付ける。第２識別情報記憶手段（２０、Ｓ２９）は、判断手段によって通常状態から省電力状態に遷移したと判断されたとき、属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する。第１表示手段（２０、Ｓ４１）は、判断手段によって省電力状態から通常状態に遷移したと判断されたとき、第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する。第１変更手段（２０、Ｓ４５）は、第１表示手段によって終了されなかったアプリケーションの名前が表示された後に、入力受け付け手段が終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、終了されなかったアプリケーションの第１属性情報を終了可能に変更する。たとえば、入力受け付け手段は、キー入力装置であり、第１変更手段は、第１属性情報を変更するキー入力がされたときに、第１属性情報を変更する。
【００２４】
第５の発明によれば、使用者は、省電力状態で終了されなかったアプリケーションについて、次に省電力状態に遷移したときには終了されるように、設定することができる。
【００２５】
第６の発明は、第４の発明または第５の発明に従属し、属性テーブルは、複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報をさらに含み、復帰手段は、終了されたアプリケーションの第２属性情報が復帰可能であるとき、終了させたアプリケーションを復帰させる。
【００２６】
第６の発明では、属性テーブルは、複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報（復帰属性）をさらに含む。そして、復帰手段は、終了されたアプリケーションの第２属性情報が復帰可能であるとき、終了させたアプリケーションを復帰させる。
【００２７】
第６の発明によれば、使用者は、有料サイトなどを閲覧中のアプリケーションが終了されたとき、復帰することで追加料金を請求されないように、アプリケーションが復帰されないように設定することができる。
【００２８】
第７の発明は、第６の発明に従属し、判断手段によって省電力状態から通常状態に遷移したと判断され、かつ終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する第２表示手段、および第２表示手段によって復帰不可能なアプリケーションの名前が表示された後に、入力受け付け手段が復帰不可能なアプリケーションの第２属性情報を変更する入力を受け付けたとき、復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する第２変更手段をさらに備える。
【００２９】
第７の発明では、第２表示手段（２０、Ｓ５３）は、判断手段によって省電力状態から通常状態に遷移したと判断され、かつ終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する。第２変更手段（２０、Ｓ５７）は、第２表示手段によって復帰不可能なアプリケーションの名前が表示された後に、入力受け付け手段が復帰不可能なアプリケーションの第２属性情報を変更する入力を受け付けたとき、復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する。
【００３０】
第７の発明によれば、使用者は、復帰されないように設定されているアプリケーションであっても、次に省電力状態から通常状態に遷移したときには復帰されるように、設定することができる。
【００３１】
第８の発明は、第４の発明ないし第７の発明のいずれかに従属し、第１識別情報記憶手段は、終了されたアプリケーションの動作状態をさらに記憶し、復帰手段は、第１識別情報記憶手段によって記憶された動作状態に基づいて、終了されたアプリケーションが終了される前の動作状態となるように復帰させる。
【００３２】
第８の発明では、第１識別情報記憶手段は、終了されたアプリケーションの動作状態をさらに記憶する。そして、復帰手段は、第１識別情報記憶手段によって記憶された動作状態に基づいて、終了されたアプリケーションが終了される前の動作状態となるように復帰させる。
【００３３】
第８の発明によれば、終了させる前の動作状態で復帰させることができるため、使用者は、省電力状態を意識することなく携帯端末のアプリケーションを実行させることができる。
【００３４】
第９の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末のプロセサ（２０）に、消費電力相関値を取得する取得ステップ（Ｓ３−Ｓ７）、通常状態から省電力状態に遷移したかを判断する判断ステップ（Ｓ２１、Ｓ３７）、および判断ステップによって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了ステップ（Ｓ３５）を実行させるための、消費電力制御プログラムである。
【００３５】
第９の発明でも、第１の発明と同様に、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【００３６】
第１０の発明は、電池（３０）を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態の状態をとることが可能な携帯端末の消費電力制御方法であって、消費電力相関値を取得する取得ステップ（Ｓ３−Ｓ７）、通常状態から省電力状態に遷移したかを判断する判断ステップ（Ｓ２１、Ｓ３７）、および判断ステップによって通常状態から省電力状態に遷移したと判断され、かつ消費電力相関値が閾値を超えたとき、複数のアプリケーションの少なくとも１つを終了する終了ステップ（Ｓ３５）を含む、消費電力制御方法である。
【００３７】
第１０の発明も、第１の発明と同様に、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【発明の効果】
【００３８】
この発明によれば、消費電力相関値から実行されるアプリケーションの動作状態を判断して、アプリケーションを終了させることができるため、アプリケーションの動作状態に基づいて携帯端末の消費電力を抑えることができる。
【００３９】
この発明の上述の目的、その他の目的、特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００４０】
図１を参照して、携帯端末１０は、二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給する電源回路２８を含む。また、電源回路２８が二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給している場合には、電源オン状態と呼ぶことにする。同様に、電源回路２８が二次電池であるリチウムイオン電池３０の電圧に基づく電源をシステム全体に供給していない場合には、電源オフ状態と呼ぶことにする。電源回路２８は、電源オフ状態で、入力受け付け手段であるキー入力装置２２によって電源オン操作がされると起動され、電源オフ状態で、キー入力装置２２による電源オフ操作がされると停止される。さらに、電源オフ状態であっても、電源回路２８は、リチウムイオン電池３０の充電に応答して起動され、リチウムイオン電池３０の充電が完了するのに応答して停止される。また、充電とは、リチウムイオン電池３０が図示しない外部充電器から電流の供給を受けることで、電気エネルギーを蓄えることを言う。
【００４１】
キー入力装置２２によって発呼操作が行われると、ＣＰＵ２０（プロセサまたはコンピュータと呼ばれることもある。）は、ＣＤＭＡ方式に対応する無線通信回路１４を制御して発呼信号を出力する。出力された発呼信号は、アンテナ１２から送出され、基地局を含む移動通信網に送信される。そして、通話相手が応答操作を行うと、通話可能状態が確立される。また、無線通信回路１４は、基地局との送受信を行う送受信回路１４ａと、受話音声信号などのアナログ信号をデジタル信号に変調または高周波信号などのデジタル信号をアナログ信号に復調するＢＢ（ＢａｓｅＢａｎｄ）回路１４ｂなどを含む。
【００４２】
通話可能状態に移行した後にキー入力装置２２によって通話終了操作が行われると、ＣＰＵ２０は、無線通信回路１４を制御して、基地局を含む移動通信網に通話終了信号を送信する。通話終了信号の送信後、ＣＰＵ２０は、通話処理を終了する。また、先に通話相手から通話終了信号を受信した場合も、ＣＰＵ２０は、通話処理を終了する。さらに、通話相手によらず、移動通信網から通話終了信号を受信した場合も、ＣＰＵ２０は通話処理を終了する。
【００４３】
携帯端末１０の電源がオンである状態で通話相手からの発呼信号がアンテナ１２によって捉えられると、無線通信回路１４は、着信をＣＰＵ２０に通知する。ＣＰＵ２０は、着信通知に記述された発信元情報をＬＣＤ制御回路３２に制御されるＬＣＤモニタ３４に表示させ、図示しない着信通知用のスピーカから着信音を出力する。キー入力装置２２によって応答操作が行われると、通話可能状態が確立される。また、ＬＣＤ制御回路３２は、電源回路２８から電圧を供給され、ＬＣＤ制御回路３２自身とＬＣＤモニタ３４とを駆動させる。
【００４４】
通話可能状態では、次のような処理が実行される。通話相手から送信された変調音声信号（高周波信号）は、アンテナ１２によって受信される。受信された変調音声信号は、無線通信回路１４によって復調処理および復号処理を施される。これによって得られた受話音声信号は、スピーカ１８から出力される。また、マイク１６によって取り込まれた送話音声信号は、無線通信回路１４によって符号化処理および変調処理を施される。これによって生成された変調音声信号は、上述と同様、アンテナ１２を利用して送信される。
【００４５】
携帯端末１０は、カメラアプリケーションを実行することが可能である。カメラアプリケーションは、オートフォーカス処理によって、被写体にピントの合った写真画像データを記憶する。具体的には、キー入力装置２２によってカメラアプリケーションを実行する操作が行われると、ＣＰＵ２０は、カメラ制御回路３６にカメラアプリケーションを実行するために必要な命令を与える。カメラ制御回路３６は、イメージセンサ３８およびフォーカスレンズ４０を制御し、イメージセンサ３８によって取得された披写界の光学像を写真画像データに変換する。そして、ＣＰＵ２０は、カメラ制御回路３６から得られる、被写体にピントを合わせた写真画像データを圧縮画像データに変換してフラッシュメモリ２４に記憶する。また、このカメラアプリケーションでは、撮影する写真画像のサイズをＷＱＶＧＡ（２４０×４００）、ＶＧＡ（６４０×４８０）およびＵＸＧＡ（１６００×１２００）から選択することが可能である。
【００４６】
また、キー入力装置２２によってネットワーク１００を介するデータ通信操作が行われると、ＣＰＵ２０は、無線通信回路１４を制御して天気情報サーバ１１０とのデータ通信を行う。天気情報サーバ１１０はＨＤＤ１１２を備え、ＨＤＤ１１２には最新の天気図の画像データおよびその天気図の画像データに対応する気象予報士のコメントを録音した音声データが記憶される。つまり、携帯端末１０の使用者は、携帯端末１０によって天気情報サーバ１１０とのデータ通信を行うことで、最新の天気図および気象予報士のコメントなどを容易に得ることができる。
【００４７】
図２は、電源回路２８の詳細な構成を示す図解図である。電源回路２８は、制御部２８ａ、計測部２８ｂ、変圧部２８ｃ、供給部２８ｄおよび抵抗Ｒから構成される。制御部２８ａは、電源回路２８用のＣＰＵであり、たとえば、供給部２８ｄを制御することで、システム全体に供給する電圧を制御する。
【００４８】
計測部２８ｂは、たとえばデジタル電圧計であり、計測手段として機能する。そして、計測部２８ｂは、抵抗Ｒの両端から得られる電圧値を計測し、制御部２８ａに出力する。この抵抗Ｒは、リチウムイオン電池３０から供給される電圧の電圧値を計測するために、電源回路２８とリチウムイオン電池３０との間に設けられる。たとえば、計測部２８ｂが計測した電圧値が、３．６８Ｖであれば、「３．６８」の数値が制御部２８ａに出力される。
【００４９】
そして、制御部２８ａは、所定時間毎、たとえば１００ｍｓ毎に計測部２８ｂから出力された電圧値をＲＡＭ２６に記憶させる。たとえば、制御部２８ａは、計測部２８ｂから「３．６８」の数値が出力されていれば、ＲＡＭ２６に「３．６８」の数値を記憶させる。また、ＲＡＭ２６は、ＣＰＵ２０と制御部２８ａとからデータの書き込みが可能なデュアルポートＲＡＭであり、記憶手段として機能する。
【００５０】
また、制御部２８ａは５秒間毎にＣＰＵ２０へ通知を行い、ＣＰＵ２０は５秒間毎にＲＡＭ２６に蓄積された電圧値のログデータを取得する。なお、電圧値を計測する周期は、１００ｍｓより短い時間であってもよいし、１００ｍｓより長い時間であってもよい。
【００５１】
変圧部２８ｃは、リチウムイオン電池３０から取得した電圧を昇圧または降圧することで、携帯端末１０に内蔵される複数の回路のそれぞれに適した電圧に変圧する。また、変圧部２８ｃは、複数の異なる電圧を出力することが可能である。供給部２８ｄは、変圧部２８ｃから得られた電圧を、制御部２８ａに指示された複数の回路のそれぞれに供給する。たとえば、制御部２８ａは、ＣＰＵ２０からＬＣＤ制御回路３２への電圧供給を停止する指示がされると、供給部２８ｄを制御することでＬＣＤ制御回路３２への電圧供給を停止する。
【００５２】
なお、他の実施例では、内蔵ＲＡＭを備える電源回路２８を利用し、シングルポートＲＡＭを利用するようにしてもよい。つまり、制御部２８ａは、１００ｍｓ毎に計測部２８ｂから出力された電圧値を内蔵ＲＡＭに記憶し、制御部２８ａは、５秒間毎にＣＰＵ２０へ通知を行うとともに、内蔵ＲＡＭに記憶した電圧値のログデータをＣＰＵ２０に出力する。
【００５３】
ＣＰＵ２０は、携帯端末１０の消費電力を抑えるために、通常状態から省電力状態に遷移させることが可能である。具体的には、省電力状態では、キー入力装置２２によって一定時間のキー入力が検出されない場合に、ＬＣＤ制御回路３２への電圧供給を停止し、ＬＣＤモニタ３４およびＬＣＤ制御回路３２の電源をオフにすることで、消費電力を抑える。さらに、省電力状態では、ＬＣＤ制御回路３２の電源をオフにした後に、間欠受信を行うことで消費電力を抑える。間欠受信とは、５秒間毎にＣＰＵ２０が無線通信回路１４の電源をオンして無線通信を行い、無線通信を行わない間は、無線通信回路１４の電源がオフにされる。そして、制御部２８ａからＣＰＵ２０への５秒間毎の通知は、間欠受信のタイミングと同期される。つまり、ＣＰＵ２０は、間欠受信を行うときに、制御部２８ａからの通知に基づいて、電圧値のログデータを取得する。
【００５４】
なお、電流値がＲＡＭ２６に記録され始めるのは、ＬＣＤ制御回路３２の電源をオフにした後に、一定間（たとえば、３分）経過してからとする。また、本実施例の通常状態とは、消費電力が制限されることなく携帯端末１０が動作している状態とする。さらに、間欠受信のタイミングは５秒間毎に限らず、携帯電話会社毎に、任意のタイミングであってもよい。
【００５５】
ここで、省電力状態におけるＣＰＵ２０によって実行されるアプリケーションを強制終了させることで、省電力状態における携帯端末１０の消費電力をさらに抑える制御について説明する。
【００５６】
具体的には、実行されるアプリケーションのそれぞれは、強制終了可能か不可能かの属性情報が設定される。そして、ＣＰＵ２０は、実行されるアプリケーションを管理し、５秒間分の電圧値のログデータから、消費電力に相関する値（消費電力相関値）として、電流値の平均値（平均電流値）を求め、閾値を超えていれば、強制終了可能な属性情報を持つアプリケーションを強制終了させる。つまり、閾値を超えている場合には、想定外の電力が消費されていると判断することができる。
【００５７】
図３は、実行アプリ一覧テーブルの詳細を示す図解図である。この実行アプリ一覧テーブルは、ＣＰＵ２０によって実行されるアプリケーションの一覧が記憶される。アプリＩＤの欄には、ＣＰＵ２０が実行するアプリケーションを識別するための識別情報として、「００ＦＦ」などの１６進数値が記憶される。また、アプリケーション名の欄には、アプリＩＤに対応するアプリケーション名が記憶される。たとえば、アプリＩＤが「００ＦＦ」であれば天気情報取得アプリケーションであり、アプリＩＤが「０１００」であればブラウザアプリケーションであり、アプリＩＤが「０１０１」であればカメラアプリケーションである。
【００５８】
この天気情報取得アプリケーションは、定期的に天気情報サーバ１１０とのデータ通信を行い、最新の天気図や、天気予報士のコメントを録音した音声データなどを取得するアプリケーションである。また、図４は、天気情報取得アプリケーションによって取得された天気図の表示例を示す図解図である。ＬＣＤモニタ３２には、状態表示範囲５０および画像表示範囲５２が表示される。状態表示範囲５０には、アンテナ１２の感度、リチウムイオン電池３０の電池残容量および現在時刻などが表示される。画像表示範囲５２には、天気情報取得アプリケーションによって取得された天気図が表示される。また、状態表示範囲５０および画像表示範囲５２については、他の表示例について同様であるため、他の表示例では簡単のため詳細な説明を省略する。
【００５９】
なお、画像表示範囲５２には、実行された機能（アプリケーション）に応じて様々な画像が表示される。また、携帯電話１０の待機状態で表示する画像を「壁紙画像」と呼ぶ。
【００６０】
図３に戻って、ブラウザアプリケーションは、天気情報サーバ１１０以外のサーバとデータ通信を行うことで、画像や文字列のデータを取得するアプリケーションである。たとえば、使用者は、壁紙画像を配布するサイトなどにアクセスすることで、様々な壁紙画像を取得することができる。また、壁紙画像を配布するサイトには、壁紙画像を表示すると、壁紙画像に対する料金を払う必要がある「有料サイト」もある。
【００６１】
図５は、強制終了テーブルの詳細を示す図解図である。強制終了テーブルは、省電力状態で平均電流値が閾値を超えた場合に、強制終了されたアプリケーションのアプリＩＤ、アプリケーション名およびその強制終了されたアプリケーションの動作状態を記憶するためのテーブルである。アプリＩＤの欄には、強制終了されたアプリケーションのアプリＩＤが記憶される。アプリケーション名の欄には、アプリＩＤの欄に対応して強制終了されたアプリケーションの名前が記憶される。そして、動作状態の欄には、アプリＩＤの欄に対応して強制終了されたアプリケーションの動作状態が記憶される。つまり、図５に示す強制終了テーブルには、アプリＩＤが「０１００」、つまりブラウザアプリケーションが、「ｈｔｔｐ：／／ｗｐａｐｅｒ．ｎｅ．ｊｐ」のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）で示される有料サイトを閲覧中に強制終了され、アプリＩＤが「０１０１」、つまりカメラアプリケーションが「ＶＧＡ撮影モード」で動作中に強制終了されたことが記憶される。
【００６２】
図６は、強制終了不可テーブルの詳細を示す図解図である。強制終了不可テーブルは、省電力状態で平均電流値が閾値を超えたとしても、強制終了させることができないアプリケーションのアプリＩＤおよびアプリケーション名を記憶するためのテーブルである。アプリＩＤの欄は、強制終了させることができないアプリケーションのアプリＩＤを記憶する。アプリケーション名の欄は、アプリＩＤの欄に対応して、アプリケーション名が記憶される。
【００６３】
図７は、属性情報テーブルの詳細を示す図解図である。属性情報テーブルは、携帯端末１０で実行されるアプリケーション全ての属性情報を記憶するテーブルであり、属性情報とは、強制終了可能か不可能かを示す終了属性情報と、強制復帰可能か不可能かを示す復帰属性情報とである。アプリＩＤの欄には、携帯端末１０で実行されるアプリケーションのアプリＩＤが記憶される。アプリケーション名の欄は、アプリＩＤの欄に対応してアプリケーションの名前が記憶される。終了属性の欄には、アプリＩＤの欄に対応して、「可」または「不可」が記憶される。つまり、終了属性の欄において、「可」は強制終了可能である終了属性情報を示し、「不可」は強制終了不可能である終了属性情報を示す。
【００６４】
たとえば、強制終了させることができるブラウザアプリケーションおよびカメラアプリケーションが記憶される行の終了属性の欄には「可」が記憶される。一方、強制終了させることができない天気情報取得アプリケーションが記憶される行の終了属性の欄には「不可」が記憶される。つまり、天気情報取得アプリケーションは、定期的に最新の天気図などの天気情報を取得するため、省電力状態でも最新の天気図を取得するように、終了属性が「不可」として記憶される。
【００６５】
また、アプリケーションを強制終了させた後に、省電力状態でなくなった場合に、強制終了されたアプリケーションを強制復帰させるか否かを示す復帰属性が記憶される。復帰属性の欄には、「可」、「不可」または「−」が記憶される。つまり、復帰属性の欄において、「可」は強制復帰可能である復帰属性情報を示し、「不可」は強制復帰不可能である復帰属性情報を示し、「−」は復帰属性情報が記憶されていないことを示す。また、「−」は、終了属性が「不可」である場合に記憶される。
【００６６】
たとえば、強制復帰させることができるカメラアプリケーションが記憶される行の復帰属性の欄には「可」が記憶される。また、強制復帰させることができないブラウザアプリケーションが記憶される行の復帰属性の欄には「不可」が記憶される。そして、終了属性の欄に「不可」が記憶される天気情報取得アプリケーションが記憶される行の復帰属性の欄には「−」が記憶される。
【００６７】
また、属性情報テーブルに記憶される終了属性と復帰属性とは、携帯端末１０にプレインストールされているアプリケーションの場合には、携帯端末１０の設計者によって予め設定される。そして、使用者によってインストールされるアプリケーションの場合には、インストールするときに、終了属性および復帰属性が設定される。ただし、使用者によってインストールされるアプリケーションが属性情報テーブルに終了属性および復帰属性を設定する仕様になっていなければ、終了属性が「不可」と記憶される。
【００６８】
さらに、携帯端末１０の設計者または使用者は、属性情報テーブルの内容を任意に変更可能なアプリケーションを設定することで、有料サイトなどを閲覧中のブラウザアプリケーションが終了されたとき、復帰することで追加料金を請求されないように、ブラウザアプリケーションが復帰されないように設定することができる。
【００６９】
図８は、ＲＡＭ２６のメモリマップを示す図解図である。ＲＡＭ２６のメモリマップ３００には、プログラム記憶領域３０２およびデータ記憶領域３０４が含まれる。プログラムおよびデータの一部は、フラッシュメモリ２４から一度にまたは必要に応じて部分的にかつ順次的に読み出され、ＲＡＭ２６に記憶され、そしてＣＰＵ２０などで処理される。
【００７０】
プログラム記憶領域３０２は、携帯端末１０を動作させるためのプログラムを記憶する。携帯端末１０を動作させるためのプログラムは、アプリケーション管理プログラム３１０、省電力プログラム３１２、電流値監視プログラム３１４、強制終了／強制復帰制御プログラム３１６および天気情報取得プログラム３１８などから構成される。アプリケーション管理プログラム３１０は、使用者の操作に応じて携帯端末１０で実行されるプログラムの一覧を表示するためのプログラムであり、図３に示す実行アプリ一覧テーブルを作成する。省電力プログラム３１２は、リチウムイオン電池３０の消費電力を抑えるためのプログラムであり、通常状態でキー入力装置２２によって一定時間のキー入力が検出されない場合に携帯端末１０を通常状態から省電力状態に遷移させる。さらに、省電力プログラム３１２は、省電力状態でキー入力装置２２によってキー入力が検出された場合に省電力状態から通常状態に遷移させる。
【００７１】
電流値監視プログラム３１４は、リチウムイオン電池３０の電流値を監視するためのプログラムである。強制終了／強制復帰制御プログラム３１６は、省電力状態においてＣＰＵ２０で実行されるアプリケーションの強制終了と、終了されたアプリケーションの強制復帰とを制御するためのプログラムである。天気情報取得プログラム３１８は、天気情報サーバ１１０から、定期的に最新の天気情報を取得するためのプログラムである。また、この天気情報取得プログラム３１８は、使用者によってインストールされたプログラムである。
【００７２】
なお、図示は省略するが、携帯端末１０を動作させるためのプログラムは、通話を行うためのプログラム、メールの送受信を行うプログラム、カメラアプリケーションを実行するためのプログラム、ブラウザアプリケーションを実行するためのプログラムなども含む。
【００７３】
データ記憶領域３０４には、ダウンロードデータバッファ３３０が設けられる。また、データ記憶領域３０４には、天気情報データ３３２、電圧値ログデータ３３４、実行アプリ一覧テーブルデータ３３６、強制終了不可テーブルデータ３３８、強制終了テーブルデータ３４０、属性情報テーブルデータ３４２および写真画像データ３４４が記憶されるとともに、省電力フラグ３４６および電流値フラグ３４８が設けられる。
【００７４】
ダウンロードデータバッファ３３０は、ブラウザアプリケーションによって取得した文字列や画像を、ＬＣＤモニタ３４に表示するために一時記憶するためのバッファである。
【００７５】
天気情報データ３３２は、天気情報取得アプリケーションによって取得された最新の天気情報のデータである。また、定期的に最新の天気情報を取得する度に、天気情報データ３３２は更新される。電圧値ログデータ３３４は、計測部２８ｂによって計測されたリチウムイオン電池３０の電圧値から構成される。また、電圧値ログデータ３３４は、ＣＰＵ２０によって読み出される毎にリセットされる。実行アプリ一覧テーブルデータ３３６は、アプリケーション管理プログラム３１０によって作成され、図３に示すテーブルデータである。また、実行アプリ一覧テーブルデータ３３６に記憶されるアプリＩＤおよびアプリケーション名は、ＣＰＵ２０によって実行されるアプリケーションによって変化する。強制終了不可テーブルデータ３３８は、省電力状態で平均電流値が閾値を超えたとしても、強制終了させることができないアプリケーションのアプリＩＤおよびアプリケーション名を記憶するためのテーブルデータ（図６参照）である。
【００７６】
強制終了テーブルデータ３４０は、省電力状態で平均電流値が閾値を超えた場合に、強制終了されたアプリケーションのアプリＩＤ、アプリケーション名およびその強制終了されたアプリケーションの動作状態を記憶するためのテーブルデータ（図５参照）である。属性情報データ３４２は、携帯端末１０で実行することが可能な各アプリケーションの終了属性と復帰属性とを記憶するテーブルデータ（図７参照）である。写真画像データ３４６は、カメラアプリケーションによって撮影された写真画像のデータである。
【００７７】
省電力フラグ３４６は、携帯端末１０の状態が省電力状態であるかを判断するフラグである。たとえば、省電力フラグ３４６は、１ビットのレジスタで構成される。省電力フラグ３４６が成立（オン）されると、レジスタにはデータ値「１」が設定され、省電力フラグ３４６が不成立（オフ）されると、レジスタにはデータ値「０」が設定される。また、省電力フラグ３４６のオン／オフは省電力プログラムによって切り替えられる。
【００７８】
電流値フラグ３４８は、平均電流値が閾値を超えたか否かを判断するフラグである。たとえば、電流値フラグ３４８は、１ビットのレジスタで構成される。電流値フラグ３４８が成立（オン）されると、レジスタにはデータ値「１」が設定され、電流値フラグ３４８が不成立（オフ）されると、レジスタにはデータ値「０」が設定される。
【００７９】
なお、図示は省略するが、データ記憶領域３０４には、アドレス帳のデータなどが記憶されるとともに、携帯端末１０の動作に必要な他のカウンタやフラグも設けられる。
【００８０】
ＣＰＵ２０は、図９に示す電流値監視処理および図１０−図１２に示す強制終了／強制復帰制御処理などを含むタスクを並列的に実行する。
【００８１】
図９は電流値監視処理を示すフロー図である。図９を参照して、ステップＳ１では、電源回路２８からの通知が有るか否かを判断する。つまり、制御部２８ａが５秒間毎に行う通知があったか否かを判断する。ステップＳ１で“ＮＯ”であれば、つまり制御部２８ａからの通知がなければ、ステップＳ１の処理を繰り返し実行する。一方、ステップＳ１で“ＹＥＳ”であれば、つまり制御部２８ａからの通知が有れば、ステップＳ３で電圧値ログデータ３３４を取得する。つまり、５秒間分のリチウムイオン電池３０の電圧値のログデータをＲＡＭ２６から取得する。続いて、ステップＳ５では、電流値に変換する。つまり、ＲＡＭ２６から取得した電圧値のそれぞれを数１に基づいて、電流値に変換する。また、抵抗Ｒとは、図２に示す、計測部２８ｂとリチウムイオン電池３０との間に設けられた抵抗Ｒである。なお、数１に示す右辺の分母は、リチウムイオン電池３０の内部抵抗などを考慮した抵抗値であってもよい。
【００８２】
［数１］
電流値＝取得した電圧値／抵抗Ｒの抵抗値
続いて、ステップＳ７では、平均電流値を算出する。つまり、変換した５秒間分の電流値を平均して平均電流値を算出する。したがって、ステップ３で、５秒間分の電圧値のログデータをＲＡＭ２６から取得し、ステップＳ５で、取得した電圧値のログデータを電流値に変換し、ステップＳ７で、変換した５秒間分の平均電流値を算出するため、ステップＳ３−Ｓ７の処理を実行するＣＰＵ２０は、消費電力相関値を取得する取得手段として機能する。さらに、ステップＳ５、Ｓ７で電圧値のログデータから消費電力相関値を算出するため、ステップＳ５、Ｓ７の処理を実行するＣＰＵ２０は、算出手段として機能する。
【００８３】
続いて、ステップＳ９では、平均電流値が閾値を超えているか否かを判断する。この閾値とは、携帯端末１０を駆動させるために最低限必要なアプリケーションが実行された状態での平均電流値を閾値とする。つまり、ステップＳ７で算出された平均電流値が、携帯端末１０を駆動させるために最低限必要なアプリケーションが実行された状態での平均電流値を超えているか否かを判断する。なお、閾値は、携帯端末１０が工場から出荷されたときに設定される。また、閾値は、使用者によって任意に設定できるようになっていてもよい。
【００８４】
ステップＳ９で“ＹＥＳ”であれば、つまり平均電流値が閾値を超えていれば、ステップＳ１１で電流値フラグ３４８をオンにして、ステップＳ１に戻る。一方、ステップＳ９で“ＮＯ”であれば、つまり平均電流値が閾値を超えていなければ、電流値フラグ３４８をオフにして、ステップＳ１に戻る。
【００８５】
図１０は強制終了／強制復帰制御処理を示すフロー図である。ステップＳ２１では、省電力状態か否かを判断する。つまり、省電力フラグ３４６がオンであるか否かを判断する。したがって、ステップＳ２１の処理を実行するＣＰＵ２０は、判断手段として機能する。
【００８６】
ステップＳ２１で“ＮＯ”であれば、つまり省電力フラグ３４６がオフであれば、ステップＳ２１の処理を繰り返し実行する。一方、ステップＳ２１で“ＹＥＳ”であれば、つまり省電力フラグ３４６がオンであれば、ステップＳ２３で実行中のアプリケーションが有るか否かを判断する。つまり、図３に示す実行アプリ一覧テーブルを参照して、実行中のアプリケーションが有るか否かを判断する。ステップＳ２３で“ＮＯ”であれば、つまり実行中のアプリケーションがなければ、ステップＳ２１に戻る。一方、“ＹＥＳ”であれば、つまり実行中のアプリケーションが有れば、ステップＳ２５で電流値フラグ３４８がオンであるか否かを判断する。つまり、消費電力相関値である平均電流値が閾値を超えたか否かを判断する。
【００８７】
ステップＳ２５で“ＮＯ”であれば、つまり電流値フラグ３４８がオフであればステップＳ２１に戻る。一方、ステップＳ２５で“ＹＥＳ”であれば、つまり電流値フラグ３４８がオンであれば、ステップＳ２７で強制終了不可のアプリケーションが実行中か否かを判断する。つまり、実行アプリ一覧テーブルに記憶される複数のアプリＩＤを取得し、図７に示す属性情報テーブルのアプリＩＤの欄において、取得したアプリＩＤを検索し、実行中のアプリケーションのそれぞれの終了属性が「不可」であるか否かを判断する。
【００８８】
ステップＳ２７で“ＮＯ”であれば、つまり終了属性が「不可」のアプリケーションが実行されていなければ、ステップＳ３１に進む。一方、ステップＳ２７で“ＹＥＳ”であれば、つまり終了属性が「不可」のアプリケーションが実行されていれば、ステップＳ２９で強制終了できないアプリケーションのアプリＩＤを記憶する。つまり、図６に示す強制終了不可テーブルに、強制終了できないアプリケーションのアプリＩＤを記憶する。したがって、ステップＳ２９の処理を実行するＣＰＵ２０は、識別情報記憶手段として機能する。
【００８９】
たとえば、天気情報取得アプリケーションが実行されていれば、実行アプリ一覧テーブルには、天気情報取得アプリケーションのアプリＩＤ「００ＦＦ」を取得することができる。そして、属性情報テーブルのアプリＩＤにおいて、取得したアプリＩＤ「００ＦＦ」を検索すると、アプリＩＤの欄に「００ＦＦ」が記憶される行に対応する終了属性が「不可」であるため、ステップＳ２７では“ＹＥＳ”と判断され、ステップＳ２９で、天気情報取得アプリケーションのアプリＩＤおよびアプリケーション名が強制終了不可テーブルに記憶される。
【００９０】
ステップＳ３１では、強制終了可能なアプリケーションが実行中か否かを判断する。つまり、実行アプリ一覧テーブルに記憶される各アプリＩＤを取得し、属性情報テーブルのアプリＩＤの欄において取得したアプリＩＤを検索し、実行中のアプリケーションそれぞれの終了属性が「可」であるか否かを判断する。ステップＳ３１で“ＮＯ”であれば、つまり終了属性が「可」のアプリケーションが実行されていなければ、ステップＳ３７に進む。一方、ステップＳ３１で“ＹＥＳ”であれば、つまり終了属性が「可」のアプリケーションが実行されていれば、ステップＳ３３で強制終了するアプリケーションのアプリＩＤおよび動作状態を記憶する。つまり、終了属性が「可」である実行中のアプリケーションのアプリＩＤおよび動作状態を記憶する。したがって、ステップＳ３３の処理を実行するＣＰＵ２０は、識別情報記憶手段として機能する。なお、処理を行う順番は異なるが、本実施例では、ステップＳ３３の処理を実行するＣＰＵ２０が第１識別情報記憶手段として機能し、ステップＳ２９の処理を実行するＣＰＵ２０が第２識別情報記憶手段として機能する。
【００９１】
たとえば、図５を参照して、終了属性が「可」であり、壁紙画像を表示する有料サイトを表示中のブラウザアプリケーションと、ＶＧＡ撮影モードのカメラアプリケーションとが実行中である場合に、強制終了テーブルには、ブラウザアプリケーションのアプリＩＤと、アプリケーション名と、壁紙画像を表示する有料サイトのＵＲＬおよび「有料サイト閲覧中」の文字列とが記憶される。さらに、強制終了テーブルには、カメラアプリケーションのアプリＩＤと、アプリケーション名と、ＶＧＡ撮影モードであることを示す文字列が記憶される。
【００９２】
続いて、ステップＳ３５では、強制終了可能なアプリケーションを終了する。つまり、終了属性が「可」である実行中のアプリケーションを終了する。また、実行中のアプリケーションを終了と同時に、実行アプリ一覧テーブルを更新する。そして、ステップＳ３５の処理を実行するＣＰＵ２０は、終了手段として機能する。
【００９３】
続いて図１１を参照して、ステップＳ３７では、省電力状態を解除したか否かを判断する。つまり、省電力フラグ３４６がオフにされたか否かを判断する。したがって、ステップＳ２１の処理を実行するＣＰＵ２０と同様に、ステップＳ３７の処理を実行するＣＰＵ２０は、判断手段として機能する。
【００９４】
ステップＳ３７で“ＮＯ”であれば、つまり省電力フラグ３４６がオンであれば、ステップＳ３７の処理を繰り返し実行する。一方、“ＹＥＳ”であれば、たとえば、キー入力装置２２に対してキー入力がされ、省電力フラグ３４６がオフにされば、ステップＳ３９で強制終了不可のアプリケーションが実行されていたか否かを判断する。つまり、強制終了不可テーブルにおいて、アプリＩＤおよびアプリケーション名が記憶されているか否かを判断する。ステップＳ３９で“ＮＯ”であれば、つまり強制終了不可テーブルにアプリＩＤおよびアプリケーション名が記憶されていなければ、ステップＳ４７に進む。
【００９５】
また、ステップＳ３９で“ＹＥＳ”であれば、つまり強制終了不可テーブルにアプリＩＤおよびアプリケーション名が記憶されていれば、ステップＳ４１で強制終了不可のアプリケーションの属性を変更するか否かを確認する。つまり、強制終了不可テーブルに記憶されたアプリケーションの終了属性を変更するポップアップをＬＣＤモニタ３４に表示する。たとえば、図６に示す強制終不可テーブルに、天気情報取得アプリケーションが記憶されていれば、図１３（Ａ）に示すポップアップが表示される。図１３（Ａ）を参照して、壁紙画像を表示する画像表示範囲５２には、ポップアップ５４が表示される。さらに、ポップアップ５４内には、天気情報取得アプリケーションの名前を含んで、終了属性を変更するか否かを確認する文章と、キー入力装置２２によってチェックすることが可能なチェックボックス５４ａ、５４ｂとが表示される。したがって、ステップＳ４１の処理を実行するＣＰＵ２０は、第１表示手段として機能する。
【００９６】
続いて図１１に戻って、ステップＳ４３で属性を変更する操作がされたか否かを判断する。たとえば、図１３（Ａ）に示すポップアップ５４内のチェックボックス５４ａ、５４ｂにおいて、終了属性を変更することを認めるチェックボックス５４ａにチェックがされた後に、確定操作がされたか否かを判断する。ステップＳ４３で“ＮＯ”であれば、つまりチェックボックス５４ｂにチェックがされた後に確定操作がされれば、ステップＳ４７に進む。一方、ステップＳ４３で“ＹＥＳ”であれば、つまりチェックボックス５４ａにチェックがされた後に確定操作がされれば、ステップＳ４５で強制終了不可のアプリケーションの属性を強制終了可に変更する。つまり、終了属性を変更するか否かを確認したアプリケーションにおいて、属性情報テーブルに記憶される終了属性を「不可」から「可」に変更する。たとえば、天気情報取得アプリケーションの終了属性が「不可」から「可」に変更される。したがって、ステップＳ４５の処理を実行するＣＰＵ２０は、第１変更手段として機能する。なお、天気情報取得アプリケーションの終了属性が「不可」から「可」に変更されると、復帰属性は「不可」に設定される。
【００９７】
これによって、使用者は、省電力状態で強制終了されなかったアプリケーションについて、次に省電力状態に遷移したときには強制終了されるように、終了属性を変更することができる。
【００９８】
なお、復帰属性は「可」に設定されるようになっていてもよいし、アプリケーションの種類によって、「可」または「不可」が選択されるようになっていてもよい。また、終了属性が「不可」のアプリケーションが複数実行される場合には、それぞれのアプリケーションにおいて、終了属性を変更するか否かが確認される。
【００９９】
続いて、ステップＳ４７では、強制終了されたアプリケーションが有るか否かを判断する。つまり、強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されているか否かを判断する。ステップＳ４７で“ＮＯ”であれば、つまり強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されていなければ、ステップＳ４９で各テーブルをリセットし、ステップＳ２１に戻る。つまり、強制終了テーブルと強制終了不可テーブルとに記憶されている各項目を消去する。
【０１００】
また、ステップＳ４７で“ＹＥＳ”であれば、つまり強制終了テーブルにアプリＩＤ、アプリケーション名および動作状態が記憶されていれば、図１２に示すステップＳ５１で強制復帰不可のアプリケーションが有るか否かを判断する。つまり、強制終了テーブルに記憶されるアプリＩＤを取得し、属性情報テーブルのアプリＩＤの欄において、取得したアプリＩＤを検索する。そして、該当するアプリケーションの復帰属性が「不可」であるか否かを判断する。ステップＳ５１で“ＮＯ”であれば、つまり復帰属性が「不可」のアプリケーションが実行されていなければ、ステップＳ５９に進む。一方、ステップＳ５１で“ＹＥＳ”であれば、つまり復帰属性が「不可」のアプリケーションが実行されていれば、ステップＳ５３で強制復帰不可のアプリケーションの属性を変更するか否かを確認する。つまり、アプリケーションの復帰属性を「不可」から「可」に変更するか否かを確認する。たとえば、復帰属性が「不可」のブラウザアプリケーションが実行されていた場合に、図１３（Ｂ）に示すポップアップ５６が表示される。図１３（Ｂ）を参照して、画像表示範囲５２には、ポップアップ５６が表示される。さらに、ポップアップ５６内には、ブラウザアプリケーションの名前を含めて、復帰属性を変更するか否かを確認する文章と、キー入力装置２２によって入力可能なチェックボックス５６ａ、５６ｂとが表示される。したがって、ステップＳ５３の処理を実行するＣＰＵ２０は、第２表示手段として機能する。
【０１０１】
続いて、ステップＳ５５では、属性情報を変更する操作がされたか否かを判断する。たとえば、図１３（Ｂ）に示すポップアップ５６内のチェックボックス５６ａ、５６ｂにおいて、復帰属性を変更することを認めるチェックボックス５６ａにチェックされた後に、確定操作がされたか否かを判断する。ステップＳ５５で“ＮＯ”であれば、つまりチェックボックス５６ｂにチェックがされた後に確定操作がされれば、ステップＳ５９に進む。一方、ステップＳ５５で“ＹＥＳ”であれば、つまりチェックボックス５６ａにチェックがされた後に確定操作がされれば、ステップＳ５７で強制復帰不可のアプリケーションの属性を強制復帰に変更する。したがって、ステップＳ５７の処理を実行するＣＰＵ２０は、第２変更手段として機能する。
【０１０２】
たとえば、図１３（Ｂ）を参照して、チェックボックス５６ａにチェックがされた後に確定操作がされれば、属性情報テーブルの復帰属性の欄において、ブラウザアプリケーションの復帰属性が「不可」から「可」に変更される。つまり、使用者は、復帰されないように設定されているアプリケーションであっても、復帰属性を変更することで、復帰できるようにすることができる。
【０１０３】
なお、復帰属性が「不可」のアプリケーションが複数実行されていた場合には、それぞれのアプリケーションにおいて、復帰属性を変更するか否かを確認する。
【０１０４】
続いて、ステップＳ５９では、強制復帰可のアプリケーションが有るか否かを判断する。つまり、強制終了テーブルに登録されているアプリＩＤから、属性情報テーブルを参照して復帰情報が「可」のアプリケーションが記憶されているか否かを判断する。ステップＳ５９で“ＮＯ”であれば、つまり復帰情報が「可」のアプリケーションが強制復帰テーブルに記憶されていなければ、ステップＳ２１に戻る。一方、ステップＳ５９で“ＹＥＳ”であれば、つまり復帰情報が「可」のアプリケーションが強制復帰テーブルに記憶されていれば、ステップＳ６１で強制復帰可のアプリケーションを実行し、強制終了前の動作状態に復帰させる。たとえば、強制終了テーブルに記憶される、復帰属性が「可」であるカメラアプリケーションをＶＧＡ撮影モードで実行する。また、アプリケーションを復帰させると同時に、実行アプリ一覧テーブルを更新する。
【０１０５】
つまり、省電力状態でなくなれば、復帰属性が「可」の強制復帰させたアプリケーションは、強制終了される前の動作状態で実行される。よって、使用者は、省電力状態を意識することなくアプリケーションを実行させることができる。そして、ステップＳ６１の処理を実行するＣＰＵ２０は、復帰手段として機能する。
【０１０６】
続いて、ステップＳ６３では、各テーブルをリセットしてステップＳ２１に戻る。つまり、ステップＳ４９と同様に強制終了テーブルと強制終了不可テーブルとをリセットする。
【０１０７】
以上の説明から分かるように、携帯端末１０は、リチウムイオン電池３０を電源として用い、天気情報取得アプリケーション、カメラアプリケーション、ブラウザアプリケーションを実行し、間欠受信をすることで、携帯端末１０の消費電力を抑える省電力状態または通常状態をとることが可能である。消費電力相関値である平均電流値は、ステップＳ３−Ｓ７の処理によって取得される。そして、省電力フラグ３４６がオンであるときに、終了属性が「可」のアプリケーションは、ステップＳ３５の処理によって強制終了される。
【０１０８】
さらに、省電力フラグ３４６がオフ、つまり省電力状態でなくなったときには、強制終了されたアプリケーションが強制復帰される。
【０１０９】
これによって、平均電流値からＣＰＵ２０によって実行されるアプリケーションの動作状態を判断し、アプリケーションを強制終了させることができるため、携帯端末１０では、アプリケーションの動作状態に基づいて携帯端末１０の消費電力を抑えることができる。
【０１１０】
また、ＣＰＵ２０によって実行されるアプリケーションの仕様が、天気情報取得アプリケーションのように、携帯端末１０の省電力状態が考慮されていなくとも、携帯端末１０の設計者が意図する省電力状態とすることができる。そして、本願発明は、事業者に申請することで誰でも開発することができるＢｒｅｗなどのアプリケーションプラットフォームを採用する携帯端末１０において大きな効果を発揮する。つまり、携帯端末１０の設計者とアプリケーションの設計者とは異なる会社であることが多いため、省電力状態で、携帯端末１０の設計者が意図しない動作を行うアプリケーションが開発されても、携帯端末１０の設計者が意図する省電力状態とすることができる。
【０１１１】
なお、携帯端末１０の消費電力相関値として平均電流値を用いたが、電池残容量の差分を利用してもよい。たとえば、消費電力相関値がリチウムイオン電池３０における電池残容量の差分であれば、まず、リチウムイオン電池３０における充電完了状態が１００％、放電状態が０％となる電池残容量値を、電圧値のログデータと同様に１００ｍｓ毎に記憶する。そして、各電池残容量値において直前の電池残容量値との差分値を求め、５秒間分の電池残容量値の差分値から平均差分値を求め、平均差分値が閾値を超えていれば、アプリケーションを強制終了するようにする。
【０１１２】
また、省電力プログラム３１２および電流監視プログラム３１４による処理は、携帯端末１０のミドルウェアまたはＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）によって処理されてもよい。
【０１１３】
さらに、携帯端末１０の通信方式には、ＣＤＭＡ方式、Ｗ‐ＣＤＭＡ方式、ＴＤＭＡ方式に限らず、ＰＨＳ方式などを採用してもよい。また、携帯電話１０のみに限らず、携帯型ゲーム機，携帯型音楽プレイヤおよびＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｅｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの電池を電源として採用する携帯端末１０であってもよい。
【０１１４】
さらに、強制終了されたアプリケーションまたは強制復帰するアプリケーションは、アドレス帳のアプリケーションや、ゲームのアプリケーションなどであってもよい。また、二次電池としてリチウムイオン電池３０を採用したが、鉛蓄電池、ニッケル水素電池、ナトリウムイオン電池、金属空気電池および亜鉛臭素電池などであってもよい。さらに、二次電池だけに限らず、燃料電池や、一次電池であるマンガン電池などでもよい。
【図面の簡単な説明】
【０１１５】
【図１】図１は本発明の一実施例の携帯端末を示すブロック図である。
【図２】図２は図１に示す電源回路の詳細な構成の一例を示す図解図である。
【図３】図３は図１に示すＲＡＭに記憶される実行アプリ一覧テーブルの詳細な構成を示す図解図である。
【図４】図４は図１に示す携帯端末で実行されるアプリケーションの表示例を示す図解図である。
【図５】図５は図１に示すＲＡＭに記憶される強制終了テーブルの詳細な構成を示す図解図である。
【図６】図６は図１に示すＲＡＭに記憶される強制終了不可テーブルの詳細な構成を示す図解図である。
【図７】図７は図１に示すＲＡＭに記憶される属性情報テーブルの詳細な構成を示す図解図である。
【図８】図８は図１に示すＲＡＭのメモリマップの一例を示す図解図である。
【図９】図９は図１に示すＣＰＵの電流値監視処理を示すフロー図である。
【図１０】図１０は図１に示すＣＰＵの強制終了／強制復帰制御処理を示すフロー図である。
【図１１】図１１は図１に示すＣＰＵの強制終了／強制復帰制御処理の他の一部であって、図１０に後続するフロー図である。
【図１２】図１２は図１に示すＣＰＵの強制終了／強制復帰制御処理のその他の一部であって、図１１に後続するフロー図である。
【図１３】図１３は図１に示すＬＣＤモニタに表示されるポップアップの表示例を示す図解図である。
【０１１６】
１０ … 携帯端末
２０ … ＣＰＵ
２２ … キー入力装置
２６ … ＲＡＭ
２８ … 電源回路
２８ａ …制御部
２８ｂ …計測部
３０ … リチウムイオン電池
３２ … ＬＣＤ制御回路
３４ … ＬＣＤモニタ
【特許請求の範囲】
【請求項１】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末であって、
消費電力相関値を取得する取得手段、
前記通常状態から前記省電力状態に遷移したかを判断する判断手段、および
前記判断手段によって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了手段を備える、携帯端末。
【請求項２】
所定時間毎に前記電池の電圧値を計測する計測手段、および
前記計測手段によって計測された電圧値を記憶する記憶手段をさらに備え、
前記取得手段は、前記記憶手段によって記憶された電圧値から前記消費電力相関値を算出する算出手段を含む、請求項１記載の携帯端末。
【請求項３】
前記記憶手段は、前記複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報を含む属性テーブルをさらに記憶し、
前記終了手段は、前記属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる、請求項２記載の携帯端末。
【請求項４】
前記判断手段は、前記省電力状態から前記通常状態に遷移したかをさらに判断し、
前記終了手段によって終了されたアプリケーションの識別情報を記憶する第１識別情報記憶手段、および
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断されたとき、前記第１識別情報記憶手段によって記憶された識別情報に基づいて、前記終了されたアプリケーションを復帰させる復帰手段をさらに備える、請求項３記載の携帯端末。
【請求項５】
入力を受け付ける入力受け付け手段、
前記判断手段によって前記通常状態から前記省電力状態に遷移したと判断されたとき、前記属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する第２識別情報記憶手段、
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断されたとき、前記第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する第１表示手段、および
前記第１表示手段によって前記終了されなかったアプリケーションの名前が表示された後に、前記入力受け付け手段が前記終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、前記終了されなかったアプリケーションの第１属性情報を終了可能に変更する第１変更手段をさらに備える、請求項３または４記載の携帯端末。
【請求項６】
前記属性テーブルは、前記複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報をさらに含み、
前記復帰手段は、前記終了されたアプリケーションの第２属性情報が復帰可能であるとき、前記終了させたアプリケーションを復帰させる、請求項４または５記載の携帯端末。
【請求項７】
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断され、かつ前記終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する第２表示手段、および
前記第２表示手段によって前記復帰不可能なアプリケーションの名前が表示された後に、前記入力受け付け手段が前記復帰不可能なアプリケーションの前記第２属性情報を変更する入力を受け付けたとき、前記復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する第２変更手段をさらに備える、請求項６記載の携帯端末。
【請求項８】
前記第１識別情報記憶手段は、前記終了されたアプリケーションの動作状態をさらに記憶し、
前記復帰手段は、前記第１識別情報記憶手段によって記憶された動作状態に基づいて、前記終了されたアプリケーションが終了される前の動作状態となるように復帰させる、請求項４ないし７のいずれかに記載の携帯端末。
【請求項９】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末のプロセサに、
消費電力相関値を取得する取得ステップ、
前記通常状態から前記省電力状態に遷移したかを判断する判断ステップ、および
前記判断ステップによって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了ステップを実行させるための、消費電力制御プログラム。
【請求項１０】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末の消費電力制御方法であって、
消費電力相関値を取得する取得ステップ、
前記通常状態から前記省電力状態に遷移したかを判断する判断ステップ、および
前記判断ステップによって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了ステップを含む、消費電力制御方法。
【請求項１】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末であって、
消費電力相関値を取得する取得手段、
前記通常状態から前記省電力状態に遷移したかを判断する判断手段、および
前記判断手段によって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了手段を備える、携帯端末。
【請求項２】
所定時間毎に前記電池の電圧値を計測する計測手段、および
前記計測手段によって計測された電圧値を記憶する記憶手段をさらに備え、
前記取得手段は、前記記憶手段によって記憶された電圧値から前記消費電力相関値を算出する算出手段を含む、請求項１記載の携帯端末。
【請求項３】
前記記憶手段は、前記複数のアプリケーションのそれぞれが終了可能か不可能かを示す第１属性情報を含む属性テーブルをさらに記憶し、
前記終了手段は、前記属性テーブルに含まれる第１属性情報が終了可能を示すアプリケーションのみを終了させる、請求項２記載の携帯端末。
【請求項４】
前記判断手段は、前記省電力状態から前記通常状態に遷移したかをさらに判断し、
前記終了手段によって終了されたアプリケーションの識別情報を記憶する第１識別情報記憶手段、および
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断されたとき、前記第１識別情報記憶手段によって記憶された識別情報に基づいて、前記終了されたアプリケーションを復帰させる復帰手段をさらに備える、請求項３記載の携帯端末。
【請求項５】
入力を受け付ける入力受け付け手段、
前記判断手段によって前記通常状態から前記省電力状態に遷移したと判断されたとき、前記属性テーブルに含まれる第１属性情報が終了不可能を示すアプリケーションの識別情報を記憶する第２識別情報記憶手段、
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断されたとき、前記第２識別情報記憶手段によって記憶された識別情報に基づいて、終了されなかったアプリケーションの名前を表示する第１表示手段、および
前記第１表示手段によって前記終了されなかったアプリケーションの名前が表示された後に、前記入力受け付け手段が前記終了されなかったアプリケーションの第１属性情報を変更する入力を受け付けたとき、前記終了されなかったアプリケーションの第１属性情報を終了可能に変更する第１変更手段をさらに備える、請求項３または４記載の携帯端末。
【請求項６】
前記属性テーブルは、前記複数のアプリケーションのそれぞれが復帰可能か不可能かを示す第２属性情報をさらに含み、
前記復帰手段は、前記終了されたアプリケーションの第２属性情報が復帰可能であるとき、前記終了させたアプリケーションを復帰させる、請求項４または５記載の携帯端末。
【請求項７】
前記判断手段によって前記省電力状態から前記通常状態に遷移したと判断され、かつ前記終了されたアプリケーションの第２属性情報が復帰不可能を示すとき、復帰不可能なアプリケーションの名前を表示する第２表示手段、および
前記第２表示手段によって前記復帰不可能なアプリケーションの名前が表示された後に、前記入力受け付け手段が前記復帰不可能なアプリケーションの前記第２属性情報を変更する入力を受け付けたとき、前記復帰不可能なアプリケーションの第２属性情報を復帰可能に変更する第２変更手段をさらに備える、請求項６記載の携帯端末。
【請求項８】
前記第１識別情報記憶手段は、前記終了されたアプリケーションの動作状態をさらに記憶し、
前記復帰手段は、前記第１識別情報記憶手段によって記憶された動作状態に基づいて、前記終了されたアプリケーションが終了される前の動作状態となるように復帰させる、請求項４ないし７のいずれかに記載の携帯端末。
【請求項９】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末のプロセサに、
消費電力相関値を取得する取得ステップ、
前記通常状態から前記省電力状態に遷移したかを判断する判断ステップ、および
前記判断ステップによって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了ステップを実行させるための、消費電力制御プログラム。
【請求項１０】
電池を電源として用い、複数のアプリケーションを実行し、間欠受信を行うことで消費電力を抑える省電力状態または通常状態をとることが可能な携帯端末の消費電力制御方法であって、
消費電力相関値を取得する取得ステップ、
前記通常状態から前記省電力状態に遷移したかを判断する判断ステップ、および
前記判断ステップによって前記通常状態から前記省電力状態に遷移したと判断され、かつ前記消費電力相関値が閾値を超えたとき、前記複数のアプリケーションの少なくとも１つを終了する終了ステップを含む、消費電力制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１０−５６７００（Ｐ２０１０−５６７００Ａ）
【公開日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願番号】特願２００８−２１７４８７（Ｐ２００８−２１７４８７）
【出願日】平成２０年８月２７日（２００８．８．２７）
【出願人】（０００００６６３３）京セラ株式会社 (13,660)
【Ｆターム（参考）】
【公開日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願日】平成２０年８月２７日（２００８．８．２７）
【出願人】（０００００６６３３）京セラ株式会社 (13,660)
【Ｆターム（参考）】
[ Back to top ]