(57)【要約】  未来のイベントの予定開始時刻を補正し、消費電力を削減する。ＣＰＵ（１０１）は、検出部（５０１）によって、イベントリスト（２０２）に登録されているイベント、または、アプリ（２１０）から発生されたイベントのうち、現在時刻以後に実行される２つのイベントの予定開始時刻を検出する。検出後、ＣＰＵ（１０１）は、算出部（５０２）によって、２つのイベントの予定開始時刻が検出された場合、２つのイベントの予定開始時刻の差分を算出する。算出後、ＣＰＵ（１０１）は、補正部（５０３）によって２つのイベントのうち少なくともいずれか一方となる補正対象イベントの予定開始時刻を補正する。このとき、ＣＰＵ（１０１）は、算出された差分に基づいて、補正対象イベントの制約情報を順守する範囲内で、２つのイベントの予定開始時刻の間隔が短くなるように補正対象イベントの予定開始時刻を補正する。
2012081079.tif 000002
【特許請求の範囲】
【請求項１】
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出手段と、
前記検出手段によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出手段と、
前記算出手段によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記検出手段は、
前記現在時刻以前に実行された２つのイベントに対応する２つの先行イベントが実行された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記検出手段は、
前記２つの先行イベントの予定開始時刻が前記補正手段によって補正された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記補正手段は、
前記差分に基づいて、前記２つのイベントのうち前記検出手段によって遅く検出された方を前記補正対象イベントとして、前記補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記検出手段は、
前記現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと前記最も早く実行されるイベント以外となる他のイベントとを前記２つのイベントとして検出することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記補正手段は、
さらに、前記２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記補正手段は、
さらに、自装置の有する電力の残量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項８】
コンピュータが、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行することを特徴とする電力制御方法。
【請求項９】
コンピュータに、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行させることを特徴とする電力制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電力を制御する情報処理装置、電力制御方法、および電力制御プログラムに関する。
【背景技術】
【０００２】
近年、携帯電話や、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などの携帯端末装置は、マルチタスクＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を搭載する形態が増加している。マルチタスクＯＳを搭載する携帯端末装置の中には、機能やユーザインターフェイスの表現力や操作性が向上した、リッチクライアントソフトウェアを追加可能とする装置も存在する。また、携帯端末装置は、通話以外の様々な機能を有している。携帯端末装置は、たとえば、メール、Ｗｅｂブラウザ、ニュース、ブログ等の閲覧、地図、交通情報、ゲーム等のアプリケーション（以下、「アプリ」と呼称する）を実行することで様々な機能をユーザに提供する。【０００３】
このような様々な機能を提供する携帯端末装置は、提供する機能量につれて消費電力も増加していった。たとえば、マルチタスクＯＳを搭載する携帯端末装置の一例であるスマートフォンは、消費電力が大きい。また、提供される機能の中には、メール受信、ＲＳＳ（Ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｒａｍｅｗｏｒｋ  Ｓｉｔｅ  Ｓｕｍｍａｒｙ）更新などといった定期的に実行される処理によって、ユーザが操作していない状態でも、携帯端末装置のハードウェア、ソフトウェアを実行させる機能が存在する。このような機能により、さらに携帯端末装置の消費電力が増加していった。【０００４】
このような増加した消費電力を削減する技術として、たとえば、無線端末装置とサーバ間で、電池残量等の情報を相互に申告し、その内容に応じて、伝送速度、伝送方式、電源制御方式の設定をすることで、電池残量の減少を最小にするという技術が開示されている（たとえば、下記特許文献１を参照。）。【０００５】
また、消費電力を削減する他の技術として、パケットの到着時間を予測し、予測された到着時間を基に、電力を制限なしに使用するアクティブ状態から低電力状態に切り替え、または、低電力状態からアクティブ状態に切り替えるという技術が開示されている（たとえば、下記特許文献２を参照。）。【０００６】
さらに消費電力を削減する他の技術として、無線通信システムにおいて、基地局が通知するビーコン信号の送信周期を、端末局が要求した設定要求に基づいて設定するという技術が開示されている（たとえば、下記特許文献３を参照。）。特許文献３の技術によれば、端末局は、端末局上で実行されているメールアプリのチェック間隔と基地局のビーコンの送信周期とを一致させることで、ビーコン信号を受信するタイミングまで通信回路の電力供給をＯＦＦにでき、消費電力を削減することができる。【０００７】
また、定期的に実行される処理において情報を削減する技術として、親局からのパケットのポーリング時刻を、子局がデータベースに基づいて算出するという技術が開示されている（たとえば、下記特許文献４を参照。）。特許文献４の技術によれば、パケットに時刻情報を付加せずに済み、より多くのパケットを送受信することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平９−２０５３９６号公報
【特許文献２】特開２００２−１８５４７５号公報
【特許文献３】特開２００５−１３０４３６号公報（段落［００１５］、［００１６］）
【特許文献４】特開２００５−３３４４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した従来技術において、特許文献２にかかる技術では、携帯端末装置が送受信するデータ量を観測結果から予想しているため、大量のデータが発生した場合には、消費電力が増加するという問題があった。また、特許文献１、２、４にかかる技術では、様々な機能を提供するアプリが、携帯端末装置の想定内で動作するとは限らず、また、アプリが他のアプリとの動作とは無関係に動作し、消費電力が増加するという問題があった。【００１０】
また、特許文献３にかかる技術にて、基地局による送信処理をアプリ１、端末局によるメールアプリのチェック処理をアプリ２と想定すると、特許文献３にかかる技術を携帯端末装置に適用でき、アプリ１をアプリ２の動作に連携して動作させることができる。しかしながら、アプリが動作する時刻が変更されることで、アプリの動作制約に違反してしまう可能性があるという問題があった。【００１１】
本発明は、１側面では、消費電力を削減できる情報処理装置、電力制御方法、および電力制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するため、開示の情報処理装置は、現在時刻以後に実行される２つのイベントの予定開始時刻が検出された場合、２つのイベントの予定開始時刻の差分を算出し、算出された差分に基づいて、２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、２つのイベントの予定開始時刻の間隔が短くなるように補正対象イベントの予定開始時刻を補正する。
【発明の効果】
【００１３】
一態様によれば、消費電力を削減できるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】実施の形態にかかる携帯端末装置１００のハードウェアを示すブロック図である。
【図２】携帯端末装置１００のソフトウェアを示すブロック図である。
【図３】イベント管理ＡＰＩ２２２によって補正されたポーリング間隔にて、アプリ２１０を動作させる場合を示す説明図である。
【図４】イベント管理ＡＰＩ２２２とアプリ管理ＡＰＩ２２１の処理内容の一例を示す説明図である。
【図５】携帯端末装置１００の機能を示すブロック図である。
【図６】ポーリング間隔の補正例を示す説明図である。
【図７】ポーリング間隔Ｔを補正しない場合の携帯端末装置１００の消費電力量を示す説明図である。
【図８】ポーリング間隔Ｔを補正した場合の携帯端末装置１００の電力消費量を示す説明図である。
【図９】ポーリング間隔補正処理を示すフローチャート（その１）である。
【図１０】ポーリング間隔補正処理を示すフローチャート（その２）である。
【発明を実施するための形態】
【００１５】
以下に添付図面を参照して、本発明にかかる情報処理装置、電力制御方法、および電力制御プログラムの好適な実施の形態を詳細に説明する。本実施の形態では、情報処理の一例として、携帯端末装置を例として説明を行う。
【００１６】
（携帯端末装置１００のハードウェア）
図１は、実施の形態にかかる携帯端末装置１００のハードウェアを示すブロック図である。携帯端末装置１００は、マルチコアのＣＰＵ１０１、ＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０２を含む。また、携帯端末装置１００は、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）Ｉ／Ｆ１０３、タッチパネルＩ／Ｆ１０４、前面カメラＩ／Ｆ１０５、メモリ１０６、背面カメラＩ／Ｆ１０７、無線Ｉ／Ｆ１０８、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）Ｉ／Ｆ１０９、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）Ｉ／Ｆ１１０を含む。
【００１７】
なお、図１はＬＣＤＩ／Ｆ１０３、タッチパネルＩ／Ｆ１０４、前面カメラＩ／Ｆ１０５、背面カメラＩ／Ｆ１０７、無線Ｉ／Ｆ１０８、ＵＳＢＩ／Ｆ１０９、Ｗｉ−ＦｉＩ／Ｆ１１０を介して接続される各装置の図示を省略している。バス１１１で相互に接続されているＧＰＵ１０２〜Ｗｉ−ＦｉＩ／Ｆ１１０は、ＣＰＵ１０１による管理下で相互にデータの送受信を行うことができる。
【００１８】
ＣＰＵ１０１は携帯端末装置１００全体の動作制御を司る中央処理装置である。なお、ＣＰＵ１０１は、複数のコアを搭載するマルチコアプロセッサであってもよい。ＧＰＵ１０２はグラフィック処理に特有な計算処理を行う。ＬＣＤＩ／Ｆ１０３は液晶ディスプレイとのＩ／Ｆである。液晶ディスプレイは、カーソル、アイコンあるいはツールボックスを始め、文書、画像、機能情報などのデータを表示する。タッチパネルＩ／Ｆ１０４はタッチパネルとのＩ／Ｆである。たとえば、ユーザによりタッチパネルが押下されると、タッチパネルＩ／Ｆ１０４は、マウスダウンイベントが発生したとしてＣＰＵ１０１に通知する。
【００１９】
前面カメラＩ／Ｆ１０５および背面カメラＩ／Ｆ１０７はカメラとのＩ／Ｆである。メモリ１０６は主記憶装置および補助記憶装置である。具体的には、メモリ１０６は、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、フラッシュＲＯＭといった記憶装置である。ＲＯＭは、ブートプログラムなどのプログラムを記憶している。ＲＡＭは、ＣＰＵ１０１のワークエリアとして使用される。フラッシュＲＯＭは、ＯＳなどのシステムソフトウェアやアプリケーションソフトウェア、または前面カメラ、背面カメラから生成された画像、動画等を記憶している。
【００２０】
無線Ｉ／Ｆ１０８はアンテナなど無線デバイスとのＩ／Ｆである。ＵＳＢＩ／Ｆ１０９はＵＳＢ規格に対応した周辺機器とのＩ／Ｆである。周辺機器には、たとえば、ＳＤカード（登録商標）といったフラッシュメモリなどの記録媒体が存在する。Ｗｉ−ＦｉＩ／Ｆ１１０は無線ＬＡＮの標準規格である「ＩＥＥＥ    ８０２．１１  ａ／ＩＥＥＥ    ８０２．１１ｂ」に対応する無線ＬＡＮデバイスとのＩ／Ｆである。
【００２１】
図２は、携帯端末装置１００のソフトウェアを示すブロック図である。携帯端末装置１００は、アプリ２１０、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）２２０、ライブラリ２３０、カーネル２４０を有する。ＡＰＩ２２０〜カーネル２４０はＯＳ２０１が提供するソフトウェア群である。
【００２２】
アプリ２１０には、ブラウザアプリ２１１、電話アプリ２１２、ニュースアプリ２１３、メールアプリ２１４等が含まれる。ブラウザアプリ２１１は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、主にＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で得たＷｅｂページを閲覧するアプリである。電話アプリ２１２は、無線Ｉ／Ｆ１０８によって基地局に接続され、他の携帯端末装置、固定電話等と通話を行うアプリである。ニュースアプリ２１３は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、ＮＮＴＰ（Ｎｅｔｗｏｒｋ  Ｎｅｗｓ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で得たネットニュースを閲覧するアプリである。
【００２３】
メールアプリ２１４は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ）等によってメールの送受信を行うアプリである。なお、本実施の形態にかかるアプリ２１０は、それぞれ１プロセスとして実行していると想定する。具体的には、ブラウザアプリ２１１が一つのプロセスであり、電話アプリ２１２がまた別のプロセスである。
【００２４】
ＡＰＩ２２０は、ＯＳ２０１の一部の機能であり、アプリ２１０がＯＳ２０１の提供するライブラリ２３０にアクセスするためのインターフェイスである。ＡＰＩ２２０には、アプリ管理ＡＰＩ２２１、イベント管理ＡＰＩ２２２、タイマＡＰＩ２２３等が含まれる。
【００２５】
アプリ管理ＡＰＩ２２１は、液晶ディスプレイに表示されているアプリ２１０について、開始処理、終了処理、切り替え処理を行う。本実施の形態の特徴であるイベント管理ＡＰＩ２２２は、現在時刻以後に実行されるイベントが登録されているイベントリスト２０２と、携帯端末装置１００の電力情報とから、アプリ２１０のポーリング間隔を補正する。なお、イベントリスト２０２の記憶内容の例は、図４にて記述する。
【００２６】
イベント管理ＡＰＩ２２２は、具体的には、ブラウザアプリ２１１内のＷｅｂページのＨＴＭＬ等で指定された再読み込み間隔、または、メールアプリ２１４のＰＯＰサーバへのメール問い合わせ間隔等を補正する。また、イベント管理ＡＰＩ２２２は、イベントリスト２０２と電力情報をライブラリ２３０から取得する。タイマＡＰＩ２２３は、アプリ２１０、イベント管理ＡＰＩ２２２等から呼び出された時に時刻情報を提供する。
【００２７】
ライブラリ２３０は、ＯＳ２０１の一部の機能であり、アプリ２１０が利用できるサービス群を示す。ライブラリ２３０には、タイミング制御ライブラリ２３１、電力制御ライブラリ２３２、Ｊａｖａ（登録商標）ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）２３３が含まれる。
【００２８】
タイミング制御ライブラリ２３１は、タイマＡＰＩ２２３からの要求に従って時刻情報、たとえば現在時刻を取得する機能を有する。また、電力制御ライブラリ２３２は、イベント管理ＡＰＩ２２２の要求に従って電力情報を取得する。ＪａｖａＶＭ２３３は、アプリ２１０のいずれかの実行オブジェクトがネイティブコードとなる携帯端末装置１００の機械語で記載されておらず、Ｊａｖａの中間コードで記述されている場合に、携帯端末装置１００で実行可能にするライブラリである。もし、アプリ２１０内の全てのアプリがネイティブコードで記載されているならば、ＪａｖａＶＭ２３３は存在しなくてもよい。
【００２９】
カーネル２４０は、ＯＳ２０１の中核となるソフトウェアである。カーネル２４０には、デバイス制御部２４１、プロセス制御部２４２等が含まれる。デバイス制御部２４１は、携帯端末装置１００に接続されているデバイス２０３の制御を行う機能を有する。なお、デバイス２０３は、具体的には、ＬＣＤＩ／Ｆ１０３に接続される液晶ディスプレイ、前面カメラＩ／Ｆ１０５、背面カメラＩ／Ｆ１０７に接続されるカメラ、無線Ｉ／Ｆ１０８、Ｗｉ−ＦｉＩ／Ｆ１１０に接続されるアンテナである。さらに、デバイス２０３は、ＵＳＢＩ／Ｆ１０９に接続されるフラッシュメモリ等の記録媒体等も含まれる。
【００３０】
たとえば、デバイス制御部２４１は、ＬＣＤＩ／Ｆ１０３にアクセスすることにより液晶ディスプレイを制御する。プロセス制御部２４２は、携帯端末装置１００で実行されているプロセスを制御する機能を有する。たとえば、プロセス制御部２４２は、アプリ２１０で実行されているプロセスを優先度、時分割等によってＣＰＵ１０１に割り当てる。
【００３１】
図３は、イベント管理ＡＰＩ２２２によって補正されたポーリング間隔にて、アプリ２１０を動作させる場合を示す説明図である。なお、図３は図２からアプリ２１０、ＡＰＩ２２０を抽出した図である。
【００３２】
ニュースアプリ２１３、メールアプリ２１４はプロセス制御部２４２によりプロセス切り替えが行われる。イベント管理ＡＰＩ２２２は、ニュースアプリ２１３、メールアプリ２１４からイベントの実行要求が通知されると、次のイベントまでのポーリング間隔を補正する。タイマＡＰＩ２２３により時刻情報が提供され、補正されたポーリング間隔以後の時刻となった場合に、イベント管理ＡＰＩ２２２は、実行要求元のアプリ２１０にイベント予定開始時刻となったことを通知し、実行要求元のアプリ２１０がイベントを実行する。
【００３３】
図４は、イベント管理ＡＰＩ２２２とアプリ管理ＡＰＩ２２１の処理内容の一例を示す説明図である。イベント管理ＡＰＩ２２２は、イベントリスト２０２を管理しており、アプリ管理ＡＰＩ２２１は、イベントとアプリ２１０の関係を示した情報を保持している。符号４０１で示す説明図では、現在時刻が２０１０年４月３日１２：４０：４０におけるイベント管理ＡＰＩ２２２によるイベントリスト２０２の保持状態を示している。また、符号４０２で示す説明図では、アプリ管理ＡＰＩ２２１によるイベントとアプリ２１０の関係を示している。
【００３４】
符号４０１で示す説明図にて、イベントリスト２０２は、イベント管理ＡＰＩ２２２によって管理されており、アプリ２１０が指定した時刻をトリガとして発生するイベントのリストである。イベントの種類には、１回だけ発生するイベントと、定期的に繰り返されるイベントと、の２種類が存在する。符号４０１で示す説明図では、イベントリスト２０２にイベント４０３〜イベント４０６が登録されている。
【００３５】
イベントは、イベントＩＤ、種類、予定開始時刻という３つのフィールドを含む。イベントＩＤフィールドは、アプリ２１０と対応づけられたＩＤが格納されている。種類フィールドは、１回だけ発生するイベントか、定期的に繰り返されるイベントかを判断できる情報が格納されている。さらに、種類フィールドは、対象のイベントが定期的に繰り返されるイベントである場合に、どれぐらいの間隔で対象のイベントが実行されるかという時間の情報についても格納される。予定開始時刻フィールドは、対象のイベントが次に実行される時刻が格納されている。
【００３６】
符号４０２で示す説明図にて、アプリ管理ＡＰＩ２２１には、アプリ２１０のポインタが格納されている。それぞれのポインタに、イベントリスト２０２に登録されたイベントＩＤが関連付けられている。たとえば、ブラウザアプリ２１１は、イベントＩＤ：１と関連付けられている。電話アプリ２１２は、どのイベントとも関連付けられていない。ニュースアプリ２１３は、イベントＩＤ：３と関連付けられている。メールアプリ２１４は、イベントＩＤ：２およびイベントＩＤ：４と関連付けられている。
【００３７】
符号４０１と符号４０２で示す説明図より、たとえば、ブラウザアプリ２１１は、イベントＩＤが１であるイベント４０３を２０１０年４月３日１２：４０：５０に実行する。イベント４０３が特定のＷｅｂページの再読み込みを行うイベントである場合、ブラウザアプリ２１１は、予定開始時刻にＷｅｂページを再読み込みする。
【００３８】
同様に、ニュースアプリ２１３は、イベントＩＤが３であるイベント４０５を２０１０年４月５日９：１１：００に実行する。イベント４０５が前回の取得以降に投稿されたネットニュースを取得するイベントである場合、ニュースアプリ２１３は、指定された予定開始時刻にネットニュースを取得する。なお、イベント４０５は繰り返し発生するイベントであるため、イベント４０５の終了後、３日後となる２０１０年４月８日９：１１：００に実行される予定の新たなイベントがイベントリスト２０２に追加される。
【００３９】
同様に、メールアプリ２１４は、イベントＩＤが２であるイベント４０４を２０１０年４月３日１２：４３：３０に実行し、イベントＩＤが４であるイベント４０６を２０１０年４月３日１３：００：００に実行する。なお、ここではメールアプリ２１４がマルチアカウントに対応したソフトウェアであることを想定している。イベント４０４、イベント４０６がそれぞれのメールアカウントの新着メールチェックを実行するイベントである場合、メールアプリ２１４は、指定された予定開始時刻に新着メールチェックを実行する。このように、１つのアプリが複数のイベントを発生する場合も有り得る。発生された複数のイベントは、処理内容が等しい場合も存在するし、異なる場合も存在する。
【００４０】
なお、イベント４０４、イベント４０６は共に繰り返し発生するイベントであるため、イベント終了後に新たなイベントがイベントリスト２０２に登録される。たとえば、イベント４０４の終了後、イベント４０４の開始時刻から２０５秒後となる２０１０年４月３日１２：４６：５５に実行される予定の新たなイベントがイベントリスト２０２に登録される。また、イベント４０６の終了後、イベント４０６の開始時刻から１時間後となる２０１０年４月３日１４：００：００に実行される予定の新たなイベントがイベントリスト２０２に登録される。
【００４１】
（携帯端末装置１００の機能）
次に、携帯端末装置１００の機能について説明する。図５は、携帯端末装置１００の機能を示すブロック図である。携帯端末装置１００は、検出部５０１と、算出部５０２と、補正部５０３と、を含む。この制御部となる機能（検出部５０１〜補正部５０３）は、記憶装置に記憶されたプログラムをＣＰＵ１０１が実行することにより、その機能を実現する。記憶装置とは、具体的には、たとえば、図１に示したメモリ１０６、ＵＳＢＩ／Ｆ１０９に接続された記録媒体等である。
【００４２】
検出部５０１は、現在時刻以後に実行される２つのイベントの予定開始時刻を検出する機能を有する。たとえば、現在時刻を２０１０年４月３日１２：４１：００とし、イベント４０３は既に実行済でイベントリスト２０２からは削除されている場合を想定する。このとき、検出部５０１は、ブラウザアプリ２１１から発生した、現在時刻以後に実行されるイベントと、イベントリスト２０２に登録されているイベント４０４との予定開始時刻を検出する。または、検出部５０１は、イベントリスト２０２に登録されているイベント群から、２つのイベントの予定開始時刻を検出してもよい。
【００４３】
また、検出部５０１は、２つのイベントと同一処理内容で実行済の２つの先行イベントが実行された結果、２つの先行イベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。たとえば、前述のブラウザアプリ２１１から発生したイベントが繰り返し実行されるイベントであることを想定する。さらに、ブラウザアプリ２１１から発生したイベントと同一処理内容で実行済である先行イベントと、イベント４０４の２０５秒前に実行された先行イベントと、の処理時間が重ならなかった場合を想定する。このとき、検出部５０１は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻を検出する。なお、処理時間が重なっている状態とは、２つのイベントが両方とも実行されている時刻が存在する状態である。
【００４４】
また、検出部５０１は、先行する２つのイベントの予定開始時刻が補正部５０３によって補正された結果、先行する２つのイベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。補正部５０３による補正では、補正対象イベントの制約情報により、処理時間が重ならない場合も有り得る。このような場合、検出部５０１は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻を検出する。なお、制約情報の説明、および具体例の説明については、補正部５０３による説明文内で行う。
【００４５】
また、検出部５０１は、現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと最も早く実行されるイベント以外となる他のイベントとを２つのイベントとして検出してもよい。たとえば、現在時刻が２０１０年４月３日１２：４０：５０であれば、検出部５０１は、最も早く実行されるイベントとしてイベント４０４と、他のイベントとして、ブラウザアプリ２１１から発生したイベントを検出してもよい。または、イベント４０４は、他のイベントとして、イベント４０５、イベント４０６を検出してもよい。なお、検出されたデータは、ＣＰＵ１０１のレジスタ、キャッシュメモリ、メモリ１０６等の記憶領域に格納される。
【００４６】
算出部５０２は、検出部５０１によって２つのイベントの予定開始時刻が検出された場合、２つのイベントの予定開始時刻の差分を算出する機能を有する。たとえば、算出部５０２は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻の差分を算出する。ブラウザアプリ２１１から発生したイベントの予定開始時刻が２０１０年４月３日１２：４４：００であると想定すると、算出部５０２は、差分として、２０１０年４月３日１２：４３：３０−２０１０年４月３日１２：４４：００＝−３０［秒］を算出する。なお、算出された差分の値は、ＣＰＵ１０１のレジスタ、キャッシュメモリ、メモリ１０６等の記憶領域に格納される。
【００４７】
補正部５０３は、算出部５０２によって算出された差分に基づいて、２つのイベントの予定開始時刻の間隔が短くなるように２つのイベントのうち少なくともいずれか一方となる補正対象イベントの予定開始時刻を補正する機能を有する。また、補正部５０３は、補正対象イベントの制約情報を順守する範囲内で補正対象イベントの予定開始時刻を補正する。
【００４８】
制約情報は、補正対象イベントを実行するアプリ２１０の仕様等に基づく値である。具体的には、ブラウザアプリ２１１のポーリング間隔の仕様として、ポーリング間隔が短くなりサーバの負荷が増大することを回避するため、特定のＷｅｂページに対し、再読み込み間隔の最小値が設定されている場合が存在する。また、別の仕様として、特定のＷｅｂページに対し、１時間でアクセス可能な最大の回数が設定されている場合も存在する。
【００４９】
このような制約情報が存在する場合に、補正部５０３は、制約情報を順守する範囲内で補正対象イベントの予定開始時刻を補正する。たとえば、補正部５０３は、算出された差分が−３０［秒］となった場合、補正対象イベントとするブラウザアプリ２１１から発生したイベントの予定開始時刻に加算し、予定開始時刻は２０１０年４月３日１２：４３：３０となる。このとき、ブラウザアプリ２１１から発生したイベントと、イベント４０４の予定開始時刻が一致し、デバイス２０３の実行時間が纏められ、消費電力が削減できる。
【００５０】
もし、補正対象イベントの予定開始時刻となった２０１０年４月３日１２：４３：３０が制約情報を順守できない場合、補正部５０３は、制約情報を順守できる範囲内で補正対象イベントの予定開始時刻を補正する。たとえば、２０１０年４月３日１２：４３：４０以後でないと補正対象イベントを実行できないという制約情報であれば、補正部５０３は、補正対象イベントの予定開始時刻を２０１０年４月３日１２：４３：４０に補正する。なお、具体的な補正の例は、図６にて後述する。
【００５１】
また、補正部５０３は、２つのイベントのうち、検出部５０１によって遅く検出された方を補正対象イベントとして補正対象イベントの予定開始時刻を補正してもよい。たとえば、補正部５０３は、ブラウザアプリ２１１から発生したイベントとイベント４０４とが検出部５０１によって検出されていた場合、遅く検出されたブラウザアプリ２１１から発生したイベントを補正対象イベントとする。
【００５２】
また、補正部５０３は、２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、補正対象イベントの予定開始時刻を補正してもよい。また、補正部５０３は、自装置の有する電力の残量に基づいて、補正対象イベントの予定開始時刻を補正してもよい。イベントの消費電力量は、補正対象イベントの消費電力量であってもよいし、補正対象とならないイベントの消費電力量であってもよい。また、補正部５０３は、算出された差分、消費電力量、電力の残量等から、制約情報が順守されやすくなるようにポーリング時刻の補正を行い、補正されたポーリング時刻が制約情報を順守するか否かの判定は、アプリが行ってもよい。
【００５３】
図６は、ポーリング間隔の補正例を示す説明図である。携帯端末装置１００は、イベントのポーリング間隔をアプリ２１０が独自に設定するのではなく、アプリ２１０から提供された値に基づいて、ＯＳ２０１が最適なポーリング間隔に補正する。または、アプリ２１０が、算出されたポーリング間隔に基づいて、イベントの予定開始時刻を補正してもよい。図６によるポーリング間隔の補正の例を示す前に、補正の計算式の例を示す。イベント管理ＡＰＩ２２２は、下記（１）式に従ってポーリング間隔を補正する。
【００５４】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮ＝ＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１  …（１）
【００５５】
ただし、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮは、補正対象イベントの補正後の予定開始時刻を示している。なお、接尾記号である“＿ｅＮ”は、イベントリスト２０２に存在するイベントのうち、Ｎ番目に実行されるイベントであることを示している。また、Ｎは、自然数である。また、ＣｕｒｒｅｎｔＴｉｍｅは、現在時刻を示している。Ｔ＿Ａｐｌ１は、アプリ２１０に含まれるアプリ１の算出された補正後となるポーリング間隔を示している。イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ１について下記関数ｆ１によって算出する。
【００５６】
Ｔ＿Ａｐｌ１＝ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１）＊定数／（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＊ＢａｔｔｅｒｙＬｉｆｅ）
【００５７】
Ｐｏｌｌｉｎｇ＿Ａｐｌ１は、アプリ１の補正前のイベントの開始予定時刻を示している。なお、接尾記号である“＿Ａｐｌ１”は、対象の記号がアプリ１に関することを示している。また、Ｐｏｌｌｉｎｇ＿Ａｐｌ１は、現在時刻に、アプリ１が仕様等から決定したポーリング間隔を加算することで算出することができる。
【００５８】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１は、イベントリスト２０２に存在するイベントのうち、現在時刻以後で最も早く実行されるイベントの予定開始時刻であることを示している。以下、図６の説明において、現在時刻以後で最も早く実行されるイベントを実行するアプリをアプリ２と呼称する。このように、関数ｆ１は、第２項の分子部分である、アプリ１の補正前のイベントの開始予定時刻と現在時刻以後で最も早く実行されるイベントの予定開始時刻との差分に基づいて、補正後のポーリング間隔を算出する。
【００５９】
ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１は、アプリ１の消費電力量の指標を示している。消費電力量の指標は、１が最も消費電力量が大きく、値が大きくなるにつれ消費電力量が小さくなることを示している。たとえば、ＰｏｗｅｒＡｐｉＬｅｖｅｌは下記（２）式で算出できる。
【００６０】
ＰｏｗｅｒＡｐｉＬｅｖｅｌ＝（ＣＰＵ１０１の負荷が１００％である場合の消費電力／アプリの消費電力）  …（２）
【００６１】
（２）式を適用し、たとえば、ＣＰＵ１０１の負荷が１００％である場合の消費電力が３［ｍＷ］である場合に、３［ｍＷ］消費するアプリは、消費電力量の指標＝（３／３）＝１となる。また、１［ｍＷ］消費するアプリは、消費電力量の指標＝（３／１）＝３となる。
【００６２】
また、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔に制約を付与するため、制約情報として、上限値、下限値といった閾値に基づいて補正してもよい。たとえば、ブラウザアプリ２１１のポーリング間隔の仕様として、特定のＷｅｂページに対する再読み込み間隔の最小値が設定されている場合を想定する。このような制約が存在する場合、下限値を特定のＷｅｂページに対する再読み込み間隔の最小値とし、関数ｆ１による算出結果が下限値を下回った場合、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔを下限値に設定してもよい。
【００６３】
ＢａｔｔｅｒｙＬｉｆｅは携帯端末装置１００の電力の残量を示している。具体的には、ＢａｔｔｅｒｙＬｉｆｅは０〜１の数値で、０ならば電力の残量がない完全放電状態を示し、１ならば満充電状態を示す。定数は、０〜１の数値で、携帯端末装置１００全体の制約情報の一つであり、関数ｆ１の第２項を拡大、縮小するパラメータである。定数が０に近い場合、アプリ１とアプリ２の処理時間が重なるまで時間がかかるようになるが、携帯端末装置１００は、補正前のポーリング間隔を守り、制約情報を順守することを優先することになる。定数が１に近い場合、アプリ１とアプリ２の処理時間が重なるまでの時間が短くなり、携帯端末装置１００は、消費電力を削減することを優先することになる。
【００６４】
また、関数ｆ１によって、長期的な平均を取るとポーリング間隔はアプリ１が仕様等から決定したポーリング間隔に収束されるが、各ポーリング間隔は、直近の他のイベントのポーリングに近づくことになる。なお、イベントが１つしか存在しない場合、イベント管理ＡＰＩ２２２は、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１が存在しないため関数ｆ１を実行しない。したがって、該当のイベントの開始予定時刻は、Ｐｏｌｌｉｎｇ＿Ａｐｌ１に等しく、ポーリング間隔はアプリ１が仕様等から決定したポーリング間隔に等しくなる。
【００６５】
また、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ１について下記関数ｆ２によって算出してもよい。
【００６６】
Ｔ＿Ａｐｌ１＝ｆ２（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１）＊定数／ｅｘｐ（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＊ＢａｔｔｅｒｙＬｉｆｅ）
【００６７】
関数ｆ２は、関数ｆ１と比較して、ハードウェアの消費電力およびアプリ１の消費電力の影響を小さくすることができる。なお、関数ｆ１、関数ｆ２の分母が１未満になった場合、イベント管理ＡＰＩ２２２は、分母を１に置き換えて算出してもよい。理由としては、分母が１未満であるとき、関数ｆの結果が、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１となる２つのイベントの差分より大きい値となる可能性があるためである。分母を１に置き換えない場合、たとえば、補正対象イベントの予定開始時刻が他方のイベントの予定開始時刻以後である場合、補正対象イベントの予定開始時刻が他方のイベントの予定開始時刻以前の時刻で補正されてしまう可能性がある。
【００６８】
以下、関数ｆ１を用い、図６で示す例にてポーリング間隔の補正の例を示す。図６では、ブラウザアプリ２１１にて、イベント４０３の終了後に新たなイベントが発生した場合を例にして説明している。以下、説明の簡略化のため、図６〜図８における時刻の記載にて日時の指定がない場合は、２０１０年４月３日内の時刻とする。
【００６９】
ブラウザアプリ２１１は、イベント４０３を時刻ｔ１＝１２：４０：５０に実行開始し、時刻ｔ２＝１２：４１：００にて終了する。時刻ｔ２にて、時刻ｔ７＝１２：４４：００に実行開始されるイベント６０１がブラウザアプリ２１１から発生した場合、タイミング制御ライブラリ２３１は、イベント６０１をポーリング間隔の補正対象イベントとして処理を開始する。なお、時刻ｔ２の時点にて、イベントリスト２０２には、イベント４０４〜イベント４０６が存在すると想定する。現在時刻以後で最も早く実行されるイベントは、時刻ｔ３＝１２：４３：３０に実行開始されるイベント４０４となる。
【００７０】
ここで、関数ｆ１にてアプリ１を示していた“＿Ａｐｌ１”を、ブラウザアプリ２１１を示す“＿Ａｐｌ２１１”に置き換える。また、現在時刻以後で最も早く実行するイベントを示していた“＿ｅ１”を、イベント４０４を示す“＿Ｅ４０４”に置き換えて関数ｆ１を表現すると、下記（３）式を得る。
【００７１】
ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１、Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿Ｅ４０４−Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１）＊定数／（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１＊ＢａｔｔｅｒｙＬｉｆｅ）  …（３）
【００７２】
イベント管理ＡＰＩ２２２は、式（３）に、ブラウザアプリ２１１の情報として、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１＝３、Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１＝時刻ｔ７、定数＝１を代入する。また、イベント管理ＡＰＩ２２２は、式（３）に他の変数であるＣｕｒｒｅｎｔＴｉｍｅ＝時刻ｔ２、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿Ｅ４０４＝時刻ｔ３、ＢａｔｔｅｒｙＬｉｆｅ＝０．５を代入する。結果、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ２１１を算出し、下記（４）式を得る。
【００７３】
Ｔ＿Ａｐｌ２１１＝（時刻ｔ７−時刻ｔ２）＋（時刻ｔ３−時刻ｔ７）＊１／（３＊０．５）
＝１８０＋（−３０）／（１．５）
＝１６０［秒］  …（４）
【００７４】
イベント管理ＡＰＩ２２２は、（１）式に（４）式を代入し、下記（５）式を得ることで、イベント６０１の補正後の予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２を算出する。
【００７５】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２＝時刻ｔ２＋１６０
＝１２：４３：４０（時刻ｔ４）  …（５）
【００７６】
算出した結果、イベント６０１の処理時間は、時刻ｔ７〜時刻ｔ８＝１２：４４：１０から、時刻ｔ４〜時刻ｔ６＝１２：４３：５０に補正される。補正により、イベント６０１の処理時間と、イベント４０４の処理時間である時刻ｔ３〜時刻ｔ５＝１２：４３：４５とから、携帯端末装置１００は、処理時間が重なった時刻ｔ４〜時刻ｔ５についてデバイス２０３の実行時間を纏めることができる。これにより、携帯端末装置１００は、デバイス２０３の実行時間を減少させ、消費電力を削減することができる。
【００７７】
また、関数ｆ１および関数ｆ２にて、現在時刻以後で最も早く実行されるイベントの予定開始時刻を用いて算出していたが、補正前のイベントの予定開始時刻から最も近いイベントの予定開始時刻を用いて算出してもよい。たとえば、現在時刻が時刻ｔ２にて、電話アプリ２１２が、予定開始時刻が時刻ｔ９＝１３：０１：００となるイベント６０２を発生した場合を想定する。
【００７８】
このとき、イベント管理ＡＰＩ２２２は、イベントリスト２０２に登録されているイベントのうち、予定開始時刻が補正前のイベントであるイベント６０２の予定開始時刻から最も近いイベントであるイベント４０６の予定開始時刻を用いて算出してもよい。最も近いイベントを選択する場合、携帯端末装置１００は、発生されたイベントの予定開始時刻とイベントリスト２０２に登録済のイベント群との予定開始時刻との差分を算出し、最も小さい差分を、最も近いイベントとして選択する。最も近いイベントを選択することにより、補正前のイベントの開始予定時刻と未実行のイベントの予定開始時刻との差分が小さくなるため、制約情報を順守しても２つのイベントの処理時間が重なりやすくなり、消費電力を削減できる。
【００７９】
また、図６の例では新たに検出されたイベント６０１を補正対象イベントとしているが、携帯端末装置１００は、イベント６０１より早く検出されたイベント４０４を補正対象イベントとし、予定開始時刻を補正してもよい。また、携帯端末装置１００は、イベント６０１とイベント４０４の両イベントを補正対象イベントとしてもよい。
【００８０】
この場合、携帯端末装置１００は、たとえば、イベント６０１とイベント４０４の予定開始時刻の平均値＝（時刻ｔ３＋時刻ｔ７）／２＝１２：４３：４５を仮想的なイベントの予定開始時刻と設定する。続けて、携帯端末装置１００は、両イベントの予定開始時刻を、仮想的なイベントの予定開始時刻に基づいて補正してもよい。これにより、イベント６０１と仮想的なイベントとの予定開始時刻の間隔、イベント４０４と仮想的なイベントとの予定開始時刻の間隔は、いずれか一方が補正対象イベントであったときより短くなる。したがって、携帯端末装置１００は、制約情報を順守しやすくなり、さらに２つのイベントの処理時間が重なった場合、消費電力を削減することができる。
【００８１】
また、関数ｆ１および関数ｆ２では、ＰｏｗｅｒＡｐｉＬｅｖｅｌは、補正対象イベントを実行するアプリ１の消費電力量の指標ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１を代入していた。ここで、ＰｏｗｅｒＡｐｉＬｅｖｅｌは、アプリ２の消費電力量の指標を用いてもよい。
【００８２】
また、アプリ１の消費電力量の指標とアプリ２の消費電力量の指標のうち、消費電力量の指標の値が大きい方を選択して用いてもよい。消費電力量の指標の値が大きい場合、すなわち消費電力量が小さい方を選択する理由は次のとおりである。アプリの消費電力量が小さい場合、それに伴うデバイス２０３の消費電力量も小さくなる。大きい消費電力量となる実行時間と小さい消費電力量となる実行時間とが重なる場合、小さい消費電力量の分が、消費電力の最大の削減量となる。このように、消費電力の最大の削減量は小さい消費電力量の方に左右されるため、携帯端末装置１００は、消費電力量の指標の値が大きい方を選択することで、消費電力量の最大の削減量に基づいてポーリング間隔を補正することができる。
【００８３】
以下、イベント管理ＡＰＩ２２２によってポーリング間隔Ｔを補正しない場合と補正した場合の消費電力量の違いに関して、図７と図８にて説明を行う。図７、図８では、携帯端末装置１００の消費電力の詳細として、ブラウザアプリ２１１の消費電力量、メールアプリ２１４の消費電力量、ＯＳ２０１の消費電力量、デバイス２０３の消費電力量を算出する例を示す。続けて、算出された各消費電力量を合計して、携帯端末装置１００の消費電力量を計算する例を示す。
【００８４】
なお、図７、図８では以下の前提条件が存在する。初めに、消費電力量の計算にあたって、ＣＰＵ１０１、デバイス２０３の低電力モードの消費電力を０［ｍＷ］と想定する。また、図７、図８で示すデバイス２０３は、ブラウザアプリ２１１とメールアプリ２１４が共にアクセスするデバイスである。たとえば、デバイス２０３は、Ｗｉ−ＦｉＩ／Ｆ１１０に接続されるアンテナ等である。さらに、ブラウザアプリ２１１の補正前のポーリング間隔を１９０秒と想定し、メールアプリ２１４の補正前のポーリング間隔を２０５秒と想定する。
【００８５】
図７は、ポーリング間隔Ｔを補正しない場合の携帯端末装置１００の消費電力量を示す説明図である。符号７０１で示す説明図が、時間変化に伴うブラウザアプリ２１１と、メールアプリ２１４と、ＯＳ２０１と、デバイス２０３と、の消費電力を示しており、表７０２が、符号７０１で示す説明図における消費電力量を示している。
【００８６】
また、図７、図８では、ブラウザアプリ２１１のイベントとして、イベント４０３、イベント６０１、予定開始時刻が時刻ｔ１０＝１２：４７：１０であるイベント７０５が実行されることを想定する。同様に、メールアプリ２１４のイベントとして、予定開始時刻が時刻ｔ１＝１２：４０：０５であるイベント７０３、イベント４０４、予定開始時刻が時刻ｔ９＝１２：４６：５５であるイベント７０４が実行されることを想定する。
【００８７】
アプリ２１０の消費電力量は、アプリ２１０によるＣＰＵ１０１の消費電力×アプリ２１０のＣＰＵ１０１平均使用率×（ＣＰＵ１０１のアクティブ時間＋一定時間）となる。なお、ＣＰＵ１０１のアクティブ時間＋一定時間をアプリ２１０の処理時間と設定する。また、ＣＰＵ１０１の消費電力以外に、メモリ１０６、バス１１１の消費電力も存在するが、図７、図８での計算では、メモリ１０６、バス１１１の消費電力をＣＰＵ１０１の消費電力に含めて計算する。
【００８８】
たとえば、図７の例では、ブラウザアプリ２１１によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、ブラウザアプリ２１１のＣＰＵ１０１平均使用率を０．５０と設定する。また、ブラウザアプリ２１１の処理時間を、ＣＰＵ１０１のアクティブ時間７［秒］＋一定時間３［秒］＝１０［秒］とする。また、ＣＰＵ１０１は、アクティブ時間を終了すると、一定時間経過後に低電力モードに遷移する。
【００８９】
ブラウザアプリ２１１の処理間隔は、図７より、時刻ｔ３＝１２：４０：５０〜時刻ｔ４＝１２：４１：００と、時刻ｔ７＝１２：４４：００〜時刻ｔ８＝１２：４４：１０と、時刻ｔ１０〜時刻ｔ１１＝１２：４７：２０となる。以上の値より、ブラウザアプリ２１１の消費電力量は、２［ｍＷ］×０．５０×（７［秒］＋３［秒］）×３［回］＝３０［ｍＷ秒］となる。
【００９０】
同様に、メールアプリ２１４によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、メールアプリ２１４のＣＰＵ１０１平均使用率を０．４０とする。また、メールアプリ２１４の処理時間を、ＣＰＵ１０１のアクティブ時間１２［秒］＋一定時間３［秒］＝１５［秒］とする。メールアプリ２１４の処理間隔は、図７より、時刻ｔ１〜時刻ｔ２＝１２：４０：２０と、時刻ｔ５＝１２：４３：３０〜時刻ｔ６＝１２：４３：４５と、時刻ｔ９＝１２：４６：５５〜時刻ｔ１０となる。以上の値より、メールアプリ２１４の消費電力量は、２［ｍＷ］×０．４０×（１２［秒］＋３［秒］）×３［回］＝３６［ｍＷ秒］となる。
【００９１】
続けて、ＯＳ２０１の消費電力量は、ＯＳ２０１によるＣＰＵ１０１の消費電力×ＯＳ２０１のＣＰＵ１０１平均使用率×ＯＳ２０１のアクティブ時間となる。また、ＣＰＵ１０１は、ＯＳ２０１のアクティブ時間を終了すると、一定時間経過後に低電力モードに遷移する。
【００９２】
なお、ＯＳ２０１のアクティブ時間は、アプリ２１０の処理時間となる。ＯＳ２０１によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、ＯＳ２０１のＣＰＵ１０１平均使用率を０．５とする。また、ＯＳ２０１のアクティブ時間は、ブラウザアプリ２１１の処理時間とメールアプリ２１４の処理時間を重ねた時間となる。ＯＳ２０１のアクティブとなる時間間隔は、時刻ｔ１〜時刻ｔ２、時刻ｔ３〜時刻ｔ４、時刻ｔ５〜時刻ｔ６、時刻ｔ７〜時刻ｔ８、時刻ｔ９〜時刻ｔ１１となる。以上の値より、ＯＳ２０１の消費電力量は、２［ｍＷ］×０．５０×（７［秒］＋３［秒］＋１２［秒］＋３［秒］）×３［回］＝７５［ｍＷ秒］となる。
【００９３】
デバイス２０３の消費電力量は、デバイス２０３の消費電力×デバイス２０３のアクティブ時間となる。なお、デバイス２０３の消費電力以外に、デバイス２０３に接続されるＩ／Ｆの消費電力も存在するが、図７、図８での計算では、Ｉ／Ｆの消費電力をデバイス２０３の消費電力に含めて計算する。また、デバイス２０３は、デバイス２０３のアクティブ時間が終了すると、低電力モードに遷移する。
【００９４】
図７の例では、デバイス２０３の消費電力を０．５［ｍＷ］とする。また、デバイス２０３のアクティブ時間は、ブラウザアプリ２１１の処理時間とメールアプリ２１４の処理時間を重ねた時間となり、ＯＳ２０１のアクティブ時間と等しい。以上の値より、デバイス２０３の消費電力量は、０．５［ｍＷ］×（１０［秒］＋１５［秒］）×３［回］＝３７．５［ｍＷ秒］となる。以上より、携帯端末装置１００の消費電力量は、３０［ｍＷ秒］＋３６［ｍＷ秒］＋７５［ｍＷ秒］＋３７．５［ｍＷ秒］＝１７８．５［ｍＷ秒］となる。
【００９５】
図８は、ポーリング間隔Ｔを補正した場合の携帯端末装置１００の電力消費量を示す説明図である。符号８０１で示す説明図は、時間変化に伴うブラウザアプリ２１１と、メールアプリ２１４と、ＯＳ２０１と、デバイス２０３と、の消費電力を示しており、表８０２は、符号８０１で示す説明図における消費電力量を示している。また、ブラウザアプリ２１１によるイベントの予定開始時刻の補正が、イベント６０１と、イベント７０５に対して行われる。なお、符号７０１で示す説明図で使用された時刻ｔ１〜時刻ｔ１１と、符号８０１で示す説明図で使用された時刻ｔ１〜時刻ｔ１４とについては、時刻ｔ１〜時刻ｔ５までが同一時刻を示しており、時刻ｔ６以降は異なる時刻を示している。
【００９６】
また、イベント６０１の補正の算出内容については、図６で示した内容と等しいため、計算結果を省略する。補正の結果、イベント６０１の予定開始時刻は、時刻ｔ９＝１２：４４：００から時刻ｔ６＝１２：４３：４０に補正される。イベント７０５の補正の算出内容については、以下のとおりである。補正を行う現在時刻は、イベント６０１が終了する時刻ｔ８＝１２：４３：５０である。さらに、イベント７０５の予定開始時刻は、時刻ｔ６からポーリング間隔＝１９０［秒］を加算した時刻ｔ１０＝１２：４６：５０となる。現在時刻以後で最も早く実行されるイベントはイベント７０４となり、予定開始時刻ｔ１２＝１２：４６：５５となる。
【００９７】
イベント管理ＡＰＩ２２２は、関数ｆ１に各値を代入し、下記（６）式を得る。代入される値は、Ｐｏｌｌｉｎｇ＿Ａｐｌ１＝時刻ｔ１０、ＣｕｒｒｅｎｔＴｉｍｅ＝時刻ｔ８、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１＝時刻ｔ１２、定数＝１、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＝３、ＢａｔｔｅｒｙＬｉｆｅ＝０．５となる。
【００９８】
Ｔ＝（時刻ｔ１０−時刻ｔ８）＋（時刻ｔ１２−時刻ｔ１０）＊１／（３＊０．５）
＝１８０＋５／（１．５）
≒１８３［秒］  …（６）
イベント管理ＡＰＩ２２２は、（１）式に（６）式を代入し、下記（７）式を得ることで、イベント７０５の補正後の予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２を算出する。
【００９９】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２＝時刻ｔ８＋１８３
＝１２：４６：５３（時刻ｔ１１）  …（７）
【０１００】
算出した結果、イベント７０５の処理時間は、時刻ｔ１１〜時刻ｔ１３＝１２：４７：０３に補正される。ブラウザアプリ２１１の処理電力量については、図７と変わらず、３０［ｍＷ秒］となる。また、ポーリング間隔補正後のメールアプリ２１４の消費電力量について、メールアプリ２１４の処理間隔は、図８より、時刻ｔ１〜時刻ｔ２と、時刻ｔ５〜時刻ｔ７＝１２：４３：４５と、時刻ｔ１２〜時刻ｔ１４＝１２：４７：１０となる。このように、図７と図８とで、メールアプリ２１４の処理時間が等しいため、消費電力量も一致し、３６［ｍＷ秒］となる。
【０１０１】
続けて、ポーリング間隔補正後のＯＳ２０１の消費電力量について算出する。ＯＳ２０１のアクティブとなる時間間隔は、時刻ｔ１〜時刻ｔ２、時刻ｔ３〜時刻ｔ４、時刻ｔ５〜時刻ｔ８、時刻ｔ１１〜時刻ｔ１４となり、アクティブ時間の合計は、１５［秒］＋１０［秒］＋２０［秒］＋１７［秒］＝６２［秒］となる。この値は、図７で示したＯＳ２０１の実行時間＝（７［秒］＋３［秒］＋１２［秒］＋３［秒］）×３［回］＝７５［秒］より減少するが、時刻ｔ６〜時刻ｔ７、時刻ｔ１２〜時刻ｔ１３では、実行するアプリが２つ存在する分、ＯＳ２０１の仕事量が増加する。したがって、全体の仕事量は変化せず、ＯＳ２０１の消費電力量は、図７と同じ７５［ｍＷ秒］となる。
【０１０２】
続けて、ポーリング間隔補正後のデバイス２０３の消費電力量について算出する。デバイス２０３のアクティブ時間は、ＯＳ２０１のアクティブ時間と等しくなり、デバイス２０３の消費電力量は、０．５［ｍＷ］×（１５［秒］＋１０［秒］＋２０［秒］＋１７［秒］）＝３１［ｍＷ秒］となる。以上より、携帯端末装置１００の消費電力量は、３０［ｍＷ秒］＋３６［ｍＷ秒］＋７５［ｍＷ秒］＋３１［ｍＷ秒］＝１７２［ｍＷ秒］となる。携帯端末装置１００は、デバイス２０３の実行時間を１つに纏めることにより、消費電力を削減することができる。
【０１０３】
また、ブラウザアプリ２１１のポーリング間隔については、１度目の補正であるイベント６０１の補正によってはポーリング間隔＝１９０［秒］から、１７０［秒］へと、補正前のポーリング間隔から減少する結果となる。次に、１度目の補正により、同一処理の次のイベントであるイベント７０５の予定開始時刻が、現在時刻以後で最も早く実行されるイベント７０４より前の時間となる。これにより、２度目の補正であるイベント７０５の補正では、ポーリング間隔が１９０［秒］から１９３［秒］へと増加することになる。１度目と２度目の補正されたポーリング間隔の平均は、（１７０＋１９３）／２＝１８１．５［秒］となり、補正前のポーリング間隔＝１９０秒に近づくことになる。
【０１０４】
このように、携帯端末装置１００は、現在時刻以後で最も早く実行されるイベントの予定開始時刻に対して補正することで、補正対象イベントのポーリング間隔の長期的な平均を、補正前のポーリング間隔に収束させることができる。補正前のポーリング間隔に収束させることで、携帯端末装置１００は、制約情報を順守しやすくなる。特に、制約情報が特定の時間あたりの回数である場合、携帯端末装置１００は、長期的な平均が補正前のポーリング間隔に収束されることで、制約情報を順守しやすくなる。
【０１０５】
また、１度目の補正では、デバイス２０３の実行時間が２０［秒］となるが、２度目の補正では、デバイス２０３の実行時間が１７［秒］となっており、１度目の補正より、２度目の補正の方が消費電力の削減量が大きくなっている。このように、段階的に補正を行うことで、予定開始時刻の間隔が短くなるため、消費電力の削減量をより大きくすることができる。また、制約情報を順守したために１度目の補正でデバイス２０３の実行時間が短くならず、消費電力が削減されなくても、補正を行わなかった際の予定開始時刻の差分より、１度目の補正時による予定開始時刻の差分の方が小さくなる。したがって、携帯端末装置１００は、段階的に補正を行い、最終的にはデバイス２０３の実行時間が短くなり、消費電力を削減することができる。
【０１０６】
図９、図１０にて、ＯＳ２０１で行われるポーリング間隔の補正を行うポーリング間隔補正処理を示す。図９、図１０にて起動されるアプリは、アプリ２１０に含まれるアプリ１、アプリ２であることを想定する。携帯端末装置１００の運用時には、１つのアプリを起動してもよいし、３つ以上のアプリを起動してもよい。
【０１０７】
図９は、ポーリング間隔補正処理を示すフローチャート（その１）である。ＯＳ２０１は、携帯端末装置１００のブート終了後等に、ＯＳ２０１の動作を開始する（ステップＳ９０１）。動作開始後、ユーザからの指示等により、ＯＳ２０１は、アプリの起動要求を実行する（ステップＳ９０２）。起動要求を受けたアプリ１は、動作を開始する（ステップＳ９０３）。起動要求を受けたアプリ２も同様に、動作を開始する（ステップＳ９０４）。なお、動作を開始後、アプリ１と、アプリ２は、ポーリング補正を行うイベント発生処理を開始する。
【０１０８】
ＯＳ２０１は、電力制御ライブラリ２３２からＢａｔｔｅｒｙＬｉｆｅを取得する（ステップＳ９０５）。また、動作を開始したアプリ１は、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１をＯＳ２０１に通知する（ステップＳ９０６）。アプリ２も同様に、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２、Ｐｏｌｌｉｎｇ＿Ａｐｌ２をＯＳ２０１に通知する（ステップＳ９０７）。また、ＯＳ２０１は、イベント管理ＡＰＩ２２２によって、現在時刻以後で最も早く実行されるイベント＿ｅ１を取得する（ステップＳ９０８）。
【０１０９】
以下、ＯＳ２０１は、ステップＳ９０６の処理による通知とステップＳ９０７の処理による通知のうち、ステップＳ９０６の処理による通知を先に受け付けたと想定する。イベント＿ｅ１の取得後、ＯＳ２０１は、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１、ＢａｔｔｅｒｙＬｉｆｅ、ＣｕｒｒｅｎｔＴｉｍｅを関数ｆに代入し、ポーリング間隔Ｔ＿Ａｐｌ１を算出する（ステップＳ９０９）。
【０１１０】
なお、ステップＳ９０９の処理については、ステップＳ９０７によるアプリ２の通知の方が早い場合、ＯＳ２０１は、アプリ２の各値を代入してポーリング間隔Ｔ＿Ａｐｌ２を算出する。また、ステップＳ９０６による通知より遅い通知となったステップＳ９０７に関するアプリ２のポーリング間隔Ｔ＿Ａｐｌ２の算出は、再びステップＳ９０９が実行される際に行われる。また、ＣｕｒｒｅｎｔＴｉｍｅの取得については、ステップＳ９０９の実行前に、ＯＳ２０１がタイマＡＰＩ２２３を呼び出して取得する。
【０１１１】
算出後、ＯＳ２０１は、算出されたポーリング間隔Ｔをアプリへ通知する（ステップＳ９１０）。なお、通知先となるアプリに関して、ＯＳ２０１は、ステップＳ９０９で算出したポーリング間隔ＴがＴ＿Ａｐｌ１であればアプリ１へ、Ｔ＿Ａｐｌ２であればアプリ２へ通知する。
【０１１２】
図１０は、ポーリング間隔補正処理を示すフローチャート（その２）である。以下、ＯＳ２０１がステップＳ９１０にてアプリ１に通知した場合を想定する。アプリ１は、ポーリング間隔Ｔ＿Ａｐｌ１を取得する（ステップＳ１００１）。続けて、アプリ１は、アプリ１固有の動作により、イベント＿ｅＮの実行要求を発生させる（ステップＳ１００２）。なお、イベント＿ｅＮは、アプリ１が呼び出したイベント管理ＡＰＩ２２２により、イベントリスト２０２に登録される。登録後、アプリ１は、イベント＿ｅＮ実行時までスタンバイする（ステップＳ１００３）。なお、ステップＳ１００３にて、アプリ１は、イベント＿ｅＮを実行する以外に実行可能な他の処理が存在すれば、スタンバイせずに他の処理を実行してもよい。
【０１１３】
ＯＳ２０１は、イベント管理ＡＰＩ２２２によって、新たなイベント＿ｅＮが登録されたことが検出されたかを判断する（ステップＳ１００７）。検出された場合（ステップＳ１００７：Ｙｅｓ）、ＯＳ２０１は、イベント＿ｅＮを補正対象イベントとし、イベント＿ｅＮの予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮをＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１に補正する（ステップＳ１００８）。
【０１１４】
なお、ステップＳ１００１の処理にて、Ｔ＿Ａｐｌ１を取得したアプリ１は、自身が持つ制約情報に基づいて、Ｔ＿Ａｐｌ１を更新してもよい。たとえば、Ｔ＿Ａｐｌ１が１６０［秒］で通知されたが、アプリ１の制約情報として、ポーリング間隔が１７０［秒］〜１９０［秒］の範囲内と定められていることを想定する。このとき、アプリ１は、Ｔ＿Ａｐｌ１’＝１７０［秒］として、ステップＳ１００２の処理時にＴ＿Ａｐｌ１’をＯＳ２０１に通知する。続けて、ステップＳ１００８の処理にて、ＯＳ２０１は、イベント＿ｅＮの予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮをＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１’に補正する。
【０１１５】
ステップＳ１００８の終了後、または、新たなイベントが検出されていない場合（ステップＳ１００７：Ｎｏ）、ＯＳ２０１は、イベントリスト２０２に登録されたイベントのうち、タイマＡＰＩ２２３により現在時刻がイベントの予定開始時刻以後となったかを判断する（ステップＳ１００９）。予定開始時刻以後である場合（ステップＳ１００９：Ｙｅｓ）、ＯＳ２０１は、イベントが予定開始時刻以後になったことをイベントに対応するアプリに通知する（ステップＳ１０１０）。アプリに通知後、または、予定開始時刻以後となったイベントがない場合（ステップＳ１００９：Ｎｏ）、ＯＳ２０１は、ステップＳ９０５の処理に移行する。
【０１１６】
予定開始時刻以後となったことの通知を受けたアプリ１は、イベント＿ｅＮを実行する（ステップＳ１０１１）。なお、通知を受けたアプリ１は、スタンバイせずに他の処理を実行している場合も有り得る。たとえば、イベント＿ｅＮの処理より優先度が高い他の処理が存在する場合である。この場合、アプリ１は、他の処理が完了してからイベント＿ｅＮの処理を行ってもよい。
【０１１７】
イベント＿ｅＮを実行後、アプリ１は、イベントが発生するループが終了するかを判断する（ステップＳ１０１２）。イベントが発生するループが継続する場合（ステップＳ１０１２：Ｎｏ）、アプリ１は、ステップＳ９０６の処理に移行する。イベントが発生するループが終了する場合（ステップＳ１０１２：Ｙｅｓ）、アプリ１は、ポーリング補正を行うイベント発生処理を終了する。
【０１１８】
なお、ステップＳ９０６の処理にて、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１は、アプリ１固有の値であり、かつアプリ１実行中に変更されない。したがって、ステップＳ９０６の処理に移行したアプリ１は、２度目以降のステップＳ９０６の処理では、次のイベントの補正前の予定開始時刻であるＰｏｌｌｉｎｇ＿Ａｐｌ１のみをＯＳ２０１に送信してもよい。
【０１１９】
なお、ＯＳ２０１がステップＳ９１０にてアプリ２に通知した場合、アプリ１の代わりにアプリ２が処理を実行する。具体的には、アプリ２は、ポーリング間隔Ｔ＿Ａｐｌ２を取得する（ステップＳ１００４）。続けて、アプリ２は、アプリ２固有の動作により、イベント＿ｅＭの実行要求を発生させる（ステップＳ１００５）。なお、イベント＿ｅＭは、アプリ２が呼び出したイベント管理ＡＰＩ２２２により、イベントリスト２０２に登録される。登録後、アプリ２は、イベント＿ｅＭ実行時までスタンバイする（ステップＳ１００６）。なお、ステップＳ１００６にて、アプリ２はアプリ１と同様に、イベント＿ｅＭを実行する以外に行う他の処理が存在すれば、スタンバイせずに他の処理を実行してもよい。
【０１２０】
続けて、予定開始時刻以後となったことの通知を受けたアプリ２は、イベント＿ｅＭを実行し（ステップＳ１０１３）、イベントが発生するループが終了するかを判断する（ステップＳ１０１４）。イベントが発生するループが継続する場合（ステップＳ１０１４：Ｎｏ）、アプリ２は、ステップＳ９０７の処理に移行する。イベントが発生するループが終了する場合（ステップＳ１０１４：Ｙｅｓ）、アプリ２は、ポーリング補正を行うイベント発生処理を終了する。
【０１２１】
以上説明したように、情報処理装置、電力制御方法、および電力制御プログラムによれば、現在時刻以後で実行される２つのイベントのうち補正対象イベントの制約情報を順守する範囲内で、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、イベント処理に伴って実行されるデバイスの実行時間が最終的には纏められ、消費電力を削減できる。
【０１２２】
また、情報処理装置は、２つのイベントと同一処理内容で２つの先行イベントが実行され、２つの先行イベントの処理時間が重ならなかった場合に、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。たとえば、制約情報によって、補正できる値が制限された結果、先行する２つのイベントの処理時間が重ならない場合もある。または、補正されたイベントを実行するアプリは、イベント処理より優先度の高い他の処理を実行している可能性がある。したがって、アプリは、必ずしも補正されたイベントの予定開始時刻でイベントを実行するとは限らず、２つのイベントの処理時間が重ならない場合もある。
【０１２３】
しかしながら、２つの先行イベントの補正前の予定開始時刻の差分と、２つの先行イベントが実行された開始時刻の差分では、後者の差分の方がより短い。よって、先行イベントの次に行われる２つのイベントの差分は、２つの先行イベントの補正前の予定開始時刻の差分より小さくなっており、処理時間が重なりやすくなる。このように、情報処理装置は、２つのイベントの処理時間が重ならなくても、段階的に補正することで、最終的に処理時間が重なり、消費電力を削減することができる。
【０１２４】
また、情報処理装置は、先行する２つのイベントの予定開始時刻が補正された結果、先行する２つのイベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。制約情報によって、補正できる値が制限された結果、補正を行った時点で先行する２つのイベントの処理時間が重ならないことが明らかな場合もある。しかしながら、先行イベントの次に行われる２つのイベントの差分は、２つの先行イベントの補正前の予定開始時刻の差分より小さくなっており、処理時間が重なりやすくなる。このように、情報処理装置は、補正の結果２つのイベントの処理時間が重ならなくても、段階的に補正することで、最終的に処理時間が重なり、消費電力を削減することができる。
【０１２５】
また、情報処理装置は、２つのイベントのうち遅く検出された方を補正対象イベントとしてもよい。早く検出された方のイベント、具体的にはイベントリスト２０２に登録されたイベントについては、既に補正済である場合が存在する。もし、早く検出された方のイベントを補正対象イベントとし、予定開始時刻の補正を行った場合、既に補正された内容が無駄になってしまう可能性がある。したがって、情報処理装置は、遅く検出された方を補正対象イベントとすることで、既に補正された内容を無駄にせずに済む。
【０１２６】
また、情報処理装置は、現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと他のイベントとを２つのイベントとして検出し、他のイベントの方を補正対象イベントとしてもよい。これにより、情報処理装置は、補正対象イベントのポーリング間隔の長期的な平均を、補正前のポーリング間隔に収束させることができる。ポーリング間隔の長期的な平均が補正前のポーリング間隔に収束されることで、情報処理装置は、制約情報を順守しやすくなる。
【０１２７】
また、情報処理装置は、算出された差分と２つのイベントのうちいずれか一方のイベントの消費電力量とに基づいて、補正対象イベントの予定開始時刻を補正してもよい。具体的には、情報処理装置は、イベントの消費電力量が大きいほど、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、消費電力に大きく影響を与えるアプリの消費電力を削減することができる。また、イベントの消費電力量が小さい場合、補正前のポーリング間隔を優先することになり、情報処理装置は、制約情報を順守しやすくなる。
【０１２８】
また、情報処理装置は、算出された差分と自装置の有する電力の残量とに基づいて、補正対象イベントの予定開始時刻を補正してもよい。具体的には、情報処理装置は、電力の残量が少ないほど、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、電力の残量が少ない場合、電力の消費を抑えることができる。また、電力の残量が多い場合、補正前のポーリング間隔を優先することになり、情報処理装置は、制約情報を順守しやすくなる。
【０１２９】
なお、本実施の形態で説明した電力制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本電力制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本電力制御プログラムは、インターネット等のネットワークを介して配布してもよい。
【符号の説明】
【０１３０】
１０１  ＣＰＵ
１０６  メモリ
１１１  バス
２０１  ＯＳ
２０２  イベントリスト
２１０  アプリ
２１１  ブラウザアプリ
２１４  メールアプリ
５０１  検出部
５０２  算出部
５０３  補正部
【図１】
2012081079.tif 000003
【図２】
2012081079.tif 000004
【図３】
2012081079.tif 000005
【図４】
2012081079.tif 000006
【図５】
2012081079.tif 000007
【図６】
2012081079.tif 000008
【図７】
2012081079.tif 000009
【図８】
2012081079.tif 000010
【図９】
2012081079.tif 000011
【図１０】
2012081079.tif 000012
【手続補正書】
【提出日】平成25年6月20日(2013.6.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出手段と、
前記検出手段によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出手段と、
前記算出手段によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記検出手段は、
前記現在時刻以前に実行された２つのイベントに対応する２つの先行イベントが実行された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記補正手段は、
前記差分に基づいて、前記２つのイベントのうち前記検出手段によって遅く検出された方を前記補正対象イベントとして、前記補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記検出手段は、
前記現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと前記最も早く実行されるイベント以外となる他のイベントとを前記２つのイベントとして検出することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記補正手段は、
さらに、前記２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項６】
前記補正手段は、
さらに、自装置の有する電力の残量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１に記載の情報処理装置。
【請求項７】
コンピュータが、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行することを特徴とする電力制御方法。
【請求項８】
コンピュータに、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行させることを特徴とする電力制御プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電力を制御する情報処理装置、電力制御方法、および電力制御プログラムに関する。
【背景技術】
【０００２】
近年、携帯電話や、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などの携帯端末装置は、マルチタスクＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を搭載する形態が増加している。マルチタスクＯＳを搭載する携帯端末装置の中には、機能やユーザインターフェイスの表現力や操作性が向上した、リッチクライアントソフトウェアを追加可能とする装置も存在する。また、携帯端末装置は、通話以外の様々な機能を有している。携帯端末装置は、たとえば、メール、Ｗｅｂブラウザ、ニュース、ブログ等の閲覧、地図、交通情報、ゲーム等のアプリケーション（以下、「アプリ」と呼称する）を実行することで様々な機能をユーザに提供する。
【０００３】
このような様々な機能を提供する携帯端末装置は、提供する機能量につれて消費電力も増加していった。たとえば、マルチタスクＯＳを搭載する携帯端末装置の一例であるスマートフォンは、消費電力が大きい。また、提供される機能の中には、メール受信、ＲＳＳ（Ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｒａｍｅｗｏｒｋ  Ｓｉｔｅ  Ｓｕｍｍａｒｙ）更新などといった定期的に実行される処理によって、ユーザが操作していない状態でも、携帯端末装置のハードウェア、ソフトウェアを実行させる機能が存在する。このような機能により、さらに携帯端末装置の消費電力が増加していった。
【０００４】
このような増加した消費電力を削減する技術として、たとえば、無線端末装置とサーバ間で、電池残量等の情報を相互に申告し、その内容に応じて、伝送速度、伝送方式、電源制御方式の設定をすることで、電池残量の減少を最小にするという技術が開示されている（たとえば、下記特許文献１を参照。）。
【０００５】
また、消費電力を削減する他の技術として、パケットの到着時間を予測し、予測された到着時間を基に、電力を制限なしに使用するアクティブ状態から低電力状態に切り替え、または、低電力状態からアクティブ状態に切り替えるという技術が開示されている（たとえば、下記特許文献２を参照。）。
【０００６】
さらに消費電力を削減する他の技術として、無線通信システムにおいて、基地局が通知するビーコン信号の送信周期を、端末局が要求した設定要求に基づいて設定するという技術が開示されている（たとえば、下記特許文献３を参照。）。特許文献３の技術によれば、端末局は、端末局上で実行されているメールアプリのチェック間隔と基地局のビーコンの送信周期とを一致させることで、ビーコン信号を受信するタイミングまで通信回路の電力供給をＯＦＦにでき、消費電力を削減することができる。
【０００７】
また、定期的に実行される処理において情報を削減する技術として、親局からのパケットのポーリング時刻を、子局がデータベースに基づいて算出するという技術が開示されている（たとえば、下記特許文献４を参照。）。特許文献４の技術によれば、パケットに時刻情報を付加せずに済み、より多くのパケットを送受信することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平９−２０５３９６号公報
【特許文献２】特開２００２−１８５４７５号公報
【特許文献３】特開２００５−１３０４３６号公報（段落［００１５］、［００１６］）
【特許文献４】特開２００５−３３４４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した従来技術において、特許文献２にかかる技術では、携帯端末装置が送受信するデータ量を観測結果から予想しているため、大量のデータが発生した場合には、消費電力が増加するという問題があった。また、特許文献１、２、４にかかる技術では、様々な機能を提供するアプリが、携帯端末装置の想定内で動作するとは限らず、また、アプリが他のアプリとの動作とは無関係に動作し、消費電力が増加するという問題があった。
【００１０】
また、特許文献３にかかる技術にて、基地局による送信処理をアプリ１、端末局によるメールアプリのチェック処理をアプリ２と想定すると、特許文献３にかかる技術を携帯端末装置に適用でき、アプリ１をアプリ２の動作に連携して動作させることができる。しかしながら、アプリが動作する時刻が変更されることで、アプリの動作制約に違反してしまう可能性があるという問題があった。
【００１１】
本発明は、１側面では、消費電力を削減できる情報処理装置、電力制御方法、および電力制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するため、開示の情報処理装置は、現在時刻以後に実行される２つのイベントの予定開始時刻が検出された場合、２つのイベントの予定開始時刻の差分を算出し、算出された差分に基づいて、２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、２つのイベントの予定開始時刻の間隔が短くなるように補正対象イベントの予定開始時刻を補正する。
【発明の効果】
【００１３】
一態様によれば、消費電力を削減できるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】実施の形態にかかる携帯端末装置１００のハードウェアを示すブロック図である。
【図２】携帯端末装置１００のソフトウェアを示すブロック図である。
【図３】イベント管理ＡＰＩ２２２によって補正されたポーリング間隔にて、アプリ２１０を動作させる場合を示す説明図である。
【図４】イベント管理ＡＰＩ２２２とアプリ管理ＡＰＩ２２１の処理内容の一例を示す説明図である。
【図５】携帯端末装置１００の機能を示すブロック図である。
【図６】ポーリング間隔の補正例を示す説明図である。
【図７】ポーリング間隔Ｔを補正しない場合の携帯端末装置１００の消費電力量を示す説明図である。
【図８】ポーリング間隔Ｔを補正した場合の携帯端末装置１００の電力消費量を示す説明図である。
【図９】ポーリング間隔補正処理を示すフローチャート（その１）である。
【図１０】ポーリング間隔補正処理を示すフローチャート（その２）である。
【発明を実施するための形態】
【００１５】
以下に添付図面を参照して、本発明にかかる情報処理装置、電力制御方法、および電力制御プログラムの好適な実施の形態を詳細に説明する。本実施の形態では、情報処理の一例として、携帯端末装置を例として説明を行う。
【００１６】
（携帯端末装置１００のハードウェア）
図１は、実施の形態にかかる携帯端末装置１００のハードウェアを示すブロック図である。携帯端末装置１００は、マルチコアのＣＰＵ１０１、ＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０２を含む。また、携帯端末装置１００は、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）Ｉ／Ｆ１０３、タッチパネルＩ／Ｆ１０４、前面カメラＩ／Ｆ１０５、メモリ１０６、背面カメラＩ／Ｆ１０７、無線Ｉ／Ｆ１０８、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）Ｉ／Ｆ１０９、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）Ｉ／Ｆ１１０を含む。
【００１７】
なお、図１はＬＣＤＩ／Ｆ１０３、タッチパネルＩ／Ｆ１０４、前面カメラＩ／Ｆ１０５、背面カメラＩ／Ｆ１０７、無線Ｉ／Ｆ１０８、ＵＳＢＩ／Ｆ１０９、Ｗｉ−ＦｉＩ／Ｆ１１０を介して接続される各装置の図示を省略している。バス１１１で相互に接続されているＧＰＵ１０２〜Ｗｉ−ＦｉＩ／Ｆ１１０は、ＣＰＵ１０１による管理下で相互にデータの送受信を行うことができる。
【００１８】
ＣＰＵ１０１は携帯端末装置１００全体の動作制御を司る中央処理装置である。なお、ＣＰＵ１０１は、複数のコアを搭載するマルチコアプロセッサであってもよい。ＧＰＵ１０２はグラフィック処理に特有な計算処理を行う。ＬＣＤＩ／Ｆ１０３は液晶ディスプレイとのＩ／Ｆである。液晶ディスプレイは、カーソル、アイコンあるいはツールボックスを始め、文書、画像、機能情報などのデータを表示する。タッチパネルＩ／Ｆ１０４はタッチパネルとのＩ／Ｆである。たとえば、ユーザによりタッチパネルが押下されると、タッチパネルＩ／Ｆ１０４は、マウスダウンイベントが発生したとしてＣＰＵ１０１に通知する。
【００１９】
前面カメラＩ／Ｆ１０５および背面カメラＩ／Ｆ１０７はカメラとのＩ／Ｆである。メモリ１０６は主記憶装置および補助記憶装置である。具体的には、メモリ１０６は、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、フラッシュＲＯＭといった記憶装置である。ＲＯＭは、ブートプログラムなどのプログラムを記憶している。ＲＡＭは、ＣＰＵ１０１のワークエリアとして使用される。フラッシュＲＯＭは、ＯＳなどのシステムソフトウェアやアプリケーションソフトウェア、または前面カメラ、背面カメラから生成された画像、動画等を記憶している。
【００２０】
無線Ｉ／Ｆ１０８はアンテナなど無線デバイスとのＩ／Ｆである。ＵＳＢＩ／Ｆ１０９はＵＳＢ規格に対応した周辺機器とのＩ／Ｆである。周辺機器には、たとえば、ＳＤカード（登録商標）といったフラッシュメモリなどの記録媒体が存在する。Ｗｉ−ＦｉＩ／Ｆ１１０は無線ＬＡＮの標準規格である「ＩＥＥＥ    ８０２．１１  ａ／ＩＥＥＥ    ８０２．１１ｂ」に対応する無線ＬＡＮデバイスとのＩ／Ｆである。
【００２１】
図２は、携帯端末装置１００のソフトウェアを示すブロック図である。携帯端末装置１００は、アプリ２１０、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）２２０、ライブラリ２３０、カーネル２４０を有する。ＡＰＩ２２０〜カーネル２４０はＯＳ２０１が提供するソフトウェア群である。
【００２２】
アプリ２１０には、ブラウザアプリ２１１、電話アプリ２１２、ニュースアプリ２１３、メールアプリ２１４等が含まれる。ブラウザアプリ２１１は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、主にＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で得たＷｅｂページを閲覧するアプリである。電話アプリ２１２は、無線Ｉ／Ｆ１０８によって基地局に接続され、他の携帯端末装置、固定電話等と通話を行うアプリである。ニュースアプリ２１３は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、ＮＮＴＰ（Ｎｅｔｗｏｒｋ  Ｎｅｗｓ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）で得たネットニュースを閲覧するアプリである。
【００２３】
メールアプリ２１４は、Ｗｉ−ＦｉＩ／Ｆ１１０経由等で通信され、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ）等によってメールの送受信を行うアプリである。なお、本実施の形態にかかるアプリ２１０は、それぞれ１プロセスとして実行していると想定する。具体的には、ブラウザアプリ２１１が一つのプロセスであり、電話アプリ２１２がまた別のプロセスである。
【００２４】
ＡＰＩ２２０は、ＯＳ２０１の一部の機能であり、アプリ２１０がＯＳ２０１の提供するライブラリ２３０にアクセスするためのインターフェイスである。ＡＰＩ２２０には、アプリ管理ＡＰＩ２２１、イベント管理ＡＰＩ２２２、タイマＡＰＩ２２３等が含まれる。
【００２５】
アプリ管理ＡＰＩ２２１は、液晶ディスプレイに表示されているアプリ２１０について、開始処理、終了処理、切り替え処理を行う。本実施の形態の特徴であるイベント管理ＡＰＩ２２２は、現在時刻以後に実行されるイベントが登録されているイベントリスト２０２と、携帯端末装置１００の電力情報とから、アプリ２１０のポーリング間隔を補正する。なお、イベントリスト２０２の記憶内容の例は、図４にて記述する。
【００２６】
イベント管理ＡＰＩ２２２は、具体的には、ブラウザアプリ２１１内のＷｅｂページのＨＴＭＬ等で指定された再読み込み間隔、または、メールアプリ２１４のＰＯＰサーバへのメール問い合わせ間隔等を補正する。また、イベント管理ＡＰＩ２２２は、イベントリスト２０２と電力情報をライブラリ２３０から取得する。タイマＡＰＩ２２３は、アプリ２１０、イベント管理ＡＰＩ２２２等から呼び出された時に時刻情報を提供する。
【００２７】
ライブラリ２３０は、ＯＳ２０１の一部の機能であり、アプリ２１０が利用できるサービス群を示す。ライブラリ２３０には、タイミング制御ライブラリ２３１、電力制御ライブラリ２３２、Ｊａｖａ（登録商標）ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）２３３が含まれる。
【００２８】
タイミング制御ライブラリ２３１は、タイマＡＰＩ２２３からの要求に従って時刻情報、たとえば現在時刻を取得する機能を有する。また、電力制御ライブラリ２３２は、イベント管理ＡＰＩ２２２の要求に従って電力情報を取得する。ＪａｖａＶＭ２３３は、アプリ２１０のいずれかの実行オブジェクトがネイティブコードとなる携帯端末装置１００の機械語で記載されておらず、Ｊａｖａの中間コードで記述されている場合に、携帯端末装置１００で実行可能にするライブラリである。もし、アプリ２１０内の全てのアプリがネイティブコードで記載されているならば、ＪａｖａＶＭ２３３は存在しなくてもよい。
【００２９】
カーネル２４０は、ＯＳ２０１の中核となるソフトウェアである。カーネル２４０には、デバイス制御部２４１、プロセス制御部２４２等が含まれる。デバイス制御部２４１は、携帯端末装置１００に接続されているデバイス２０３の制御を行う機能を有する。なお、デバイス２０３は、具体的には、ＬＣＤＩ／Ｆ１０３に接続される液晶ディスプレイ、前面カメラＩ／Ｆ１０５、背面カメラＩ／Ｆ１０７に接続されるカメラ、無線Ｉ／Ｆ１０８、Ｗｉ−ＦｉＩ／Ｆ１１０に接続されるアンテナである。さらに、デバイス２０３は、ＵＳＢＩ／Ｆ１０９に接続されるフラッシュメモリ等の記録媒体等も含まれる。
【００３０】
たとえば、デバイス制御部２４１は、ＬＣＤＩ／Ｆ１０３にアクセスすることにより液晶ディスプレイを制御する。プロセス制御部２４２は、携帯端末装置１００で実行されているプロセスを制御する機能を有する。たとえば、プロセス制御部２４２は、アプリ２１０で実行されているプロセスを優先度、時分割等によってＣＰＵ１０１に割り当てる。
【００３１】
図３は、イベント管理ＡＰＩ２２２によって補正されたポーリング間隔にて、アプリ２１０を動作させる場合を示す説明図である。なお、図３は図２からアプリ２１０、ＡＰＩ２２０を抽出した図である。
【００３２】
ニュースアプリ２１３、メールアプリ２１４はプロセス制御部２４２によりプロセス切り替えが行われる。イベント管理ＡＰＩ２２２は、ニュースアプリ２１３、メールアプリ２１４からイベントの実行要求が通知されると、次のイベントまでのポーリング間隔を補正する。タイマＡＰＩ２２３により時刻情報が提供され、補正されたポーリング間隔以後の時刻となった場合に、イベント管理ＡＰＩ２２２は、実行要求元のアプリ２１０にイベント予定開始時刻となったことを通知し、実行要求元のアプリ２１０がイベントを実行する。
【００３３】
図４は、イベント管理ＡＰＩ２２２とアプリ管理ＡＰＩ２２１の処理内容の一例を示す説明図である。イベント管理ＡＰＩ２２２は、イベントリスト２０２を管理しており、アプリ管理ＡＰＩ２２１は、イベントとアプリ２１０の関係を示した情報を保持している。符号４０１で示す説明図では、現在時刻が２０１０年４月３日１２：４０：４０におけるイベント管理ＡＰＩ２２２によるイベントリスト２０２の保持状態を示している。また、符号４０２で示す説明図では、アプリ管理ＡＰＩ２２１によるイベントとアプリ２１０の関係を示している。
【００３４】
符号４０１で示す説明図にて、イベントリスト２０２は、イベント管理ＡＰＩ２２２によって管理されており、アプリ２１０が指定した時刻をトリガとして発生するイベントのリストである。イベントの種類には、１回だけ発生するイベントと、定期的に繰り返されるイベントと、の２種類が存在する。符号４０１で示す説明図では、イベントリスト２０２にイベント４０３〜イベント４０６が登録されている。
【００３５】
イベントは、イベントＩＤ、種類、予定開始時刻という３つのフィールドを含む。イベントＩＤフィールドは、アプリ２１０と対応づけられたＩＤが格納されている。種類フィールドは、１回だけ発生するイベントか、定期的に繰り返されるイベントかを判断できる情報が格納されている。さらに、種類フィールドは、対象のイベントが定期的に繰り返されるイベントである場合に、どれぐらいの間隔で対象のイベントが実行されるかという時間の情報についても格納される。予定開始時刻フィールドは、対象のイベントが次に実行される時刻が格納されている。
【００３６】
符号４０２で示す説明図にて、アプリ管理ＡＰＩ２２１には、アプリ２１０のポインタが格納されている。それぞれのポインタに、イベントリスト２０２に登録されたイベントＩＤが関連付けられている。たとえば、ブラウザアプリ２１１は、イベントＩＤ：１と関連付けられている。電話アプリ２１２は、どのイベントとも関連付けられていない。ニュースアプリ２１３は、イベントＩＤ：３と関連付けられている。メールアプリ２１４は、イベントＩＤ：２およびイベントＩＤ：４と関連付けられている。
【００３７】
符号４０１と符号４０２で示す説明図より、たとえば、ブラウザアプリ２１１は、イベントＩＤが１であるイベント４０３を２０１０年４月３日１２：４０：５０に実行する。イベント４０３が特定のＷｅｂページの再読み込みを行うイベントである場合、ブラウザアプリ２１１は、予定開始時刻にＷｅｂページを再読み込みする。
【００３８】
同様に、ニュースアプリ２１３は、イベントＩＤが３であるイベント４０５を２０１０年４月５日９：１１：００に実行する。イベント４０５が前回の取得以降に投稿されたネットニュースを取得するイベントである場合、ニュースアプリ２１３は、指定された予定開始時刻にネットニュースを取得する。なお、イベント４０５は繰り返し発生するイベントであるため、イベント４０５の終了後、３日後となる２０１０年４月８日９：１１：００に実行される予定の新たなイベントがイベントリスト２０２に追加される。
【００３９】
同様に、メールアプリ２１４は、イベントＩＤが２であるイベント４０４を２０１０年４月３日１２：４３：３０に実行し、イベントＩＤが４であるイベント４０６を２０１０年４月３日１３：００：００に実行する。なお、ここではメールアプリ２１４がマルチアカウントに対応したソフトウェアであることを想定している。イベント４０４、イベント４０６がそれぞれのメールアカウントの新着メールチェックを実行するイベントである場合、メールアプリ２１４は、指定された予定開始時刻に新着メールチェックを実行する。このように、１つのアプリが複数のイベントを発生する場合も有り得る。発生された複数のイベントは、処理内容が等しい場合も存在するし、異なる場合も存在する。
【００４０】
なお、イベント４０４、イベント４０６は共に繰り返し発生するイベントであるため、イベント終了後に新たなイベントがイベントリスト２０２に登録される。たとえば、イベント４０４の終了後、イベント４０４の開始時刻から２０５秒後となる２０１０年４月３日１２：４６：５５に実行される予定の新たなイベントがイベントリスト２０２に登録される。また、イベント４０６の終了後、イベント４０６の開始時刻から１時間後となる２０１０年４月３日１４：００：００に実行される予定の新たなイベントがイベントリスト２０２に登録される。
【００４１】
（携帯端末装置１００の機能）
次に、携帯端末装置１００の機能について説明する。図５は、携帯端末装置１００の機能を示すブロック図である。携帯端末装置１００は、検出部５０１と、算出部５０２と、補正部５０３と、を含む。この制御部となる機能（検出部５０１〜補正部５０３）は、記憶装置に記憶されたプログラムをＣＰＵ１０１が実行することにより、その機能を実現する。記憶装置とは、具体的には、たとえば、図１に示したメモリ１０６、ＵＳＢＩ／Ｆ１０９に接続された記録媒体等である。
【００４２】
検出部５０１は、現在時刻以後に実行される２つのイベントの予定開始時刻を検出する機能を有する。たとえば、現在時刻を２０１０年４月３日１２：４１：００とし、イベント４０３は既に実行済でイベントリスト２０２からは削除されている場合を想定する。このとき、検出部５０１は、ブラウザアプリ２１１から発生した、現在時刻以後に実行されるイベントと、イベントリスト２０２に登録されているイベント４０４との予定開始時刻を検出する。または、検出部５０１は、イベントリスト２０２に登録されているイベント群から、２つのイベントの予定開始時刻を検出してもよい。
【００４３】
また、検出部５０１は、２つのイベントと同一処理内容で実行済の２つの先行イベントが実行された結果、２つの先行イベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。たとえば、前述のブラウザアプリ２１１から発生したイベントが繰り返し実行されるイベントであることを想定する。さらに、ブラウザアプリ２１１から発生したイベントと同一処理内容で実行済である先行イベントと、イベント４０４の２０５秒前に実行された先行イベントと、の処理時間が重ならなかった場合を想定する。このとき、検出部５０１は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻を検出する。なお、処理時間が重なっている状態とは、２つのイベントが両方とも実行されている時刻が存在する状態である。
【００４４】
また、検出部５０１は、先行する２つのイベントの予定開始時刻が補正部５０３によって補正された結果、先行する２つのイベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。補正部５０３による補正では、補正対象イベントの制約情報により、処理時間が重ならない場合も有り得る。このような場合、検出部５０１は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻を検出する。なお、制約情報の説明、および具体例の説明については、補正部５０３による説明文内で行う。
【００４５】
また、検出部５０１は、現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと最も早く実行されるイベント以外となる他のイベントとを２つのイベントとして検出してもよい。たとえば、現在時刻が２０１０年４月３日１２：４０：５０であれば、検出部５０１は、最も早く実行されるイベントとしてイベント４０４と、他のイベントとして、ブラウザアプリ２１１から発生したイベントを検出してもよい。または、イベント４０４は、他のイベントとして、イベント４０５、イベント４０６を検出してもよい。なお、検出されたデータは、ＣＰＵ１０１のレジスタ、キャッシュメモリ、メモリ１０６等の記憶領域に格納される。
【００４６】
算出部５０２は、検出部５０１によって２つのイベントの予定開始時刻が検出された場合、２つのイベントの予定開始時刻の差分を算出する機能を有する。たとえば、算出部５０２は、ブラウザアプリ２１１から発生したイベントとイベント４０４との予定開始時刻の差分を算出する。ブラウザアプリ２１１から発生したイベントの予定開始時刻が２０１０年４月３日１２：４４：００であると想定すると、算出部５０２は、差分として、２０１０年４月３日１２：４３：３０−２０１０年４月３日１２：４４：００＝−３０［秒］を算出する。なお、算出された差分の値は、ＣＰＵ１０１のレジスタ、キャッシュメモリ、メモリ１０６等の記憶領域に格納される。
【００４７】
補正部５０３は、算出部５０２によって算出された差分に基づいて、２つのイベントの予定開始時刻の間隔が短くなるように２つのイベントのうち少なくともいずれか一方となる補正対象イベントの予定開始時刻を補正する機能を有する。また、補正部５０３は、補正対象イベントの制約情報を順守する範囲内で補正対象イベントの予定開始時刻を補正する。
【００４８】
制約情報は、補正対象イベントを実行するアプリ２１０の仕様等に基づく値である。具体的には、ブラウザアプリ２１１のポーリング間隔の仕様として、ポーリング間隔が短くなりサーバの負荷が増大することを回避するため、特定のＷｅｂページに対し、再読み込み間隔の最小値が設定されている場合が存在する。また、別の仕様として、特定のＷｅｂページに対し、１時間でアクセス可能な最大の回数が設定されている場合も存在する。
【００４９】
このような制約情報が存在する場合に、補正部５０３は、制約情報を順守する範囲内で補正対象イベントの予定開始時刻を補正する。たとえば、補正部５０３は、算出された差分が−３０［秒］となった場合、補正対象イベントとするブラウザアプリ２１１から発生したイベントの予定開始時刻に加算し、予定開始時刻は２０１０年４月３日１２：４３：３０となる。このとき、ブラウザアプリ２１１から発生したイベントと、イベント４０４の予定開始時刻が一致し、デバイス２０３の実行時間が纏められ、消費電力が削減できる。
【００５０】
もし、補正対象イベントの予定開始時刻となった２０１０年４月３日１２：４３：３０が制約情報を順守できない場合、補正部５０３は、制約情報を順守できる範囲内で補正対象イベントの予定開始時刻を補正する。たとえば、２０１０年４月３日１２：４３：４０以後でないと補正対象イベントを実行できないという制約情報であれば、補正部５０３は、補正対象イベントの予定開始時刻を２０１０年４月３日１２：４３：４０に補正する。なお、具体的な補正の例は、図６にて後述する。
【００５１】
また、補正部５０３は、２つのイベントのうち、検出部５０１によって遅く検出された方を補正対象イベントとして補正対象イベントの予定開始時刻を補正してもよい。たとえば、補正部５０３は、ブラウザアプリ２１１から発生したイベントとイベント４０４とが検出部５０１によって検出されていた場合、遅く検出されたブラウザアプリ２１１から発生したイベントを補正対象イベントとする。
【００５２】
また、補正部５０３は、２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、補正対象イベントの予定開始時刻を補正してもよい。また、補正部５０３は、自装置の有する電力の残量に基づいて、補正対象イベントの予定開始時刻を補正してもよい。イベントの消費電力量は、補正対象イベントの消費電力量であってもよいし、補正対象とならないイベントの消費電力量であってもよい。また、補正部５０３は、算出された差分、消費電力量、電力の残量等から、制約情報が順守されやすくなるようにポーリング時刻の補正を行い、補正されたポーリング時刻が制約情報を順守するか否かの判定は、アプリが行ってもよい。
【００５３】
図６は、ポーリング間隔の補正例を示す説明図である。携帯端末装置１００は、イベントのポーリング間隔をアプリ２１０が独自に設定するのではなく、アプリ２１０から提供された値に基づいて、ＯＳ２０１が最適なポーリング間隔に補正する。または、アプリ２１０が、算出されたポーリング間隔に基づいて、イベントの予定開始時刻を補正してもよい。図６によるポーリング間隔の補正の例を示す前に、補正の計算式の例を示す。イベント管理ＡＰＩ２２２は、下記（１）式に従ってポーリング間隔を補正する。
【００５４】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮ＝ＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１  …（１）
【００５５】
ただし、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮは、補正対象イベントの補正後の予定開始時刻を示している。なお、接尾記号である“＿ｅＮ”は、イベントリスト２０２に存在するイベントのうち、Ｎ番目に実行されるイベントであることを示している。また、Ｎは、自然数である。また、ＣｕｒｒｅｎｔＴｉｍｅは、現在時刻を示している。Ｔ＿Ａｐｌ１は、アプリ２１０に含まれるアプリ１の算出された補正後となるポーリング間隔を示している。イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ１について下記関数ｆ１によって算出する。
【００５６】
Ｔ＿Ａｐｌ１＝ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１）＊定数／（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＊ＢａｔｔｅｒｙＬｉｆｅ）
【００５７】
Ｐｏｌｌｉｎｇ＿Ａｐｌ１は、アプリ１の補正前のイベントの開始予定時刻を示している。なお、接尾記号である“＿Ａｐｌ１”は、対象の記号がアプリ１に関することを示している。また、Ｐｏｌｌｉｎｇ＿Ａｐｌ１は、現在時刻に、アプリ１が仕様等から決定したポーリング間隔を加算することで算出することができる。
【００５８】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１は、イベントリスト２０２に存在するイベントのうち、現在時刻以後で最も早く実行されるイベントの予定開始時刻であることを示している。以下、図６の説明において、現在時刻以後で最も早く実行されるイベントを実行するアプリをアプリ２と呼称する。このように、関数ｆ１は、第２項の分子部分である、アプリ１の補正前のイベントの開始予定時刻と現在時刻以後で最も早く実行されるイベントの予定開始時刻との差分に基づいて、補正後のポーリング間隔を算出する。
【００５９】
ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１は、アプリ１の消費電力量の指標を示している。消費電力量の指標は、１が最も消費電力量が大きく、値が大きくなるにつれ消費電力量が小さくなることを示している。たとえば、ＰｏｗｅｒＡｐｉＬｅｖｅｌは下記（２）式で算出できる。
【００６０】
ＰｏｗｅｒＡｐｉＬｅｖｅｌ＝（ＣＰＵ１０１の負荷が１００％である場合の消費電力／アプリの消費電力）  …（２）
【００６１】
（２）式を適用し、たとえば、ＣＰＵ１０１の負荷が１００％である場合の消費電力が３［ｍＷ］である場合に、３［ｍＷ］消費するアプリは、消費電力量の指標＝（３／３）＝１となる。また、１［ｍＷ］消費するアプリは、消費電力量の指標＝（３／１）＝３となる。
【００６２】
また、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔に制約を付与するため、制約情報として、上限値、下限値といった閾値に基づいて補正してもよい。たとえば、ブラウザアプリ２１１のポーリング間隔の仕様として、特定のＷｅｂページに対する再読み込み間隔の最小値が設定されている場合を想定する。このような制約が存在する場合、下限値を特定のＷｅｂページに対する再読み込み間隔の最小値とし、関数ｆ１による算出結果が下限値を下回った場合、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔを下限値に設定してもよい。
【００６３】
ＢａｔｔｅｒｙＬｉｆｅは携帯端末装置１００の電力の残量を示している。具体的には、ＢａｔｔｅｒｙＬｉｆｅは０〜１の数値で、０ならば電力の残量がない完全放電状態を示し、１ならば満充電状態を示す。定数は、０〜１の数値で、携帯端末装置１００全体の制約情報の一つであり、関数ｆ１の第２項を拡大、縮小するパラメータである。定数が０に近い場合、アプリ１とアプリ２の処理時間が重なるまで時間がかかるようになるが、携帯端末装置１００は、補正前のポーリング間隔を守り、制約情報を順守することを優先することになる。定数が１に近い場合、アプリ１とアプリ２の処理時間が重なるまでの時間が短くなり、携帯端末装置１００は、消費電力を削減することを優先することになる。
【００６４】
また、関数ｆ１によって、長期的な平均を取るとポーリング間隔はアプリ１が仕様等から決定したポーリング間隔に収束されるが、各ポーリング間隔は、直近の他のイベントのポーリングに近づくことになる。なお、イベントが１つしか存在しない場合、イベント管理ＡＰＩ２２２は、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１が存在しないため関数ｆ１を実行しない。したがって、該当のイベントの開始予定時刻は、Ｐｏｌｌｉｎｇ＿Ａｐｌ１に等しく、ポーリング間隔はアプリ１が仕様等から決定したポーリング間隔に等しくなる。
【００６５】
また、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ１について下記関数ｆ２によって算出してもよい。
【００６６】
Ｔ＿Ａｐｌ１＝ｆ２（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１）＊定数／ｅｘｐ（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＊ＢａｔｔｅｒｙＬｉｆｅ）
【００６７】
関数ｆ２は、関数ｆ１と比較して、ハードウェアの消費電力およびアプリ１の消費電力の影響を小さくすることができる。なお、関数ｆ１、関数ｆ２の分母が１未満になった場合、イベント管理ＡＰＩ２２２は、分母を１に置き換えて算出してもよい。理由としては、分母が１未満であるとき、関数ｆの結果が、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１−Ｐｏｌｌｉｎｇ＿Ａｐｌ１となる２つのイベントの差分より大きい値となる可能性があるためである。分母を１に置き換えない場合、たとえば、補正対象イベントの予定開始時刻が他方のイベントの予定開始時刻以後である場合、補正対象イベントの予定開始時刻が他方のイベントの予定開始時刻以前の時刻で補正されてしまう可能性がある。
【００６８】
以下、関数ｆ１を用い、図６で示す例にてポーリング間隔の補正の例を示す。図６では、ブラウザアプリ２１１にて、イベント４０３の終了後に新たなイベントが発生した場合を例にして説明している。以下、説明の簡略化のため、図６〜図８における時刻の記載にて日時の指定がない場合は、２０１０年４月３日内の時刻とする。
【００６９】
ブラウザアプリ２１１は、イベント４０３を時刻ｔ１＝１２：４０：５０に実行開始し、時刻ｔ２＝１２：４１：００にて終了する。時刻ｔ２にて、時刻ｔ７＝１２：４４：００に実行開始されるイベント６０１がブラウザアプリ２１１から発生した場合、タイミング制御ライブラリ２３１は、イベント６０１をポーリング間隔の補正対象イベントとして処理を開始する。なお、時刻ｔ２の時点にて、イベントリスト２０２には、イベント４０４〜イベント４０６が存在すると想定する。現在時刻以後で最も早く実行されるイベントは、時刻ｔ３＝１２：４３：３０に実行開始されるイベント４０４となる。
【００７０】
ここで、関数ｆ１にてアプリ１を示していた“＿Ａｐｌ１”を、ブラウザアプリ２１１を示す“＿Ａｐｌ２１１”に置き換える。また、現在時刻以後で最も早く実行するイベントを示していた“＿ｅ１”を、イベント４０４を示す“＿Ｅ４０４”に置き換えて関数ｆ１を表現すると、下記（３）式を得る。
【００７１】
ｆ１（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１、Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１）
＝（Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１−ＣｕｒｒｅｎｔＴｉｍｅ）＋（ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿Ｅ４０４−Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１）＊定数／（ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１＊ＢａｔｔｅｒｙＬｉｆｅ）  …（３）
【００７２】
イベント管理ＡＰＩ２２２は、式（３）に、ブラウザアプリ２１１の情報として、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２１１＝３、Ｐｏｌｌｉｎｇ＿Ａｐｌ２１１＝時刻ｔ７、定数＝１を代入する。また、イベント管理ＡＰＩ２２２は、式（３）に他の変数であるＣｕｒｒｅｎｔＴｉｍｅ＝時刻ｔ２、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿Ｅ４０４＝時刻ｔ３、ＢａｔｔｅｒｙＬｉｆｅ＝０．５を代入する。結果、イベント管理ＡＰＩ２２２は、補正後のポーリング間隔Ｔ＿Ａｐｌ２１１を算出し、下記（４）式を得る。
【００７３】
Ｔ＿Ａｐｌ２１１＝（時刻ｔ７−時刻ｔ２）＋（時刻ｔ３−時刻ｔ７）＊１／（３＊０．５）
＝１８０＋（−３０）／（１．５）
＝１６０［秒］  …（４）
【００７４】
イベント管理ＡＰＩ２２２は、（１）式に（４）式を代入し、下記（５）式を得ることで、イベント６０１の補正後の予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２を算出する。
【００７５】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２＝時刻ｔ２＋１６０
＝１２：４３：４０（時刻ｔ４）  …（５）
【００７６】
算出した結果、イベント６０１の処理時間は、時刻ｔ７〜時刻ｔ８＝１２：４４：１０から、時刻ｔ４〜時刻ｔ６＝１２：４３：５０に補正される。補正により、イベント６０１の処理時間と、イベント４０４の処理時間である時刻ｔ３〜時刻ｔ５＝１２：４３：４５とから、携帯端末装置１００は、処理時間が重なった時刻ｔ４〜時刻ｔ５についてデバイス２０３の実行時間を纏めることができる。これにより、携帯端末装置１００は、デバイス２０３の実行時間を減少させ、消費電力を削減することができる。
【００７７】
また、関数ｆ１および関数ｆ２にて、現在時刻以後で最も早く実行されるイベントの予定開始時刻を用いて算出していたが、補正前のイベントの予定開始時刻から最も近いイベントの予定開始時刻を用いて算出してもよい。たとえば、現在時刻が時刻ｔ２にて、電話アプリ２１２が、予定開始時刻が時刻ｔ９＝１３：０１：００となるイベント６０２を発生した場合を想定する。
【００７８】
このとき、イベント管理ＡＰＩ２２２は、イベントリスト２０２に登録されているイベントのうち、予定開始時刻が補正前のイベントであるイベント６０２の予定開始時刻から最も近いイベントであるイベント４０６の予定開始時刻を用いて算出してもよい。最も近いイベントを選択する場合、携帯端末装置１００は、発生されたイベントの予定開始時刻とイベントリスト２０２に登録済のイベント群との予定開始時刻との差分を算出し、最も小さい差分を、最も近いイベントとして選択する。最も近いイベントを選択することにより、補正前のイベントの開始予定時刻と未実行のイベントの予定開始時刻との差分が小さくなるため、制約情報を順守しても２つのイベントの処理時間が重なりやすくなり、消費電力を削減できる。
【００７９】
また、図６の例では新たに検出されたイベント６０１を補正対象イベントとしているが、携帯端末装置１００は、イベント６０１より早く検出されたイベント４０４を補正対象イベントとし、予定開始時刻を補正してもよい。また、携帯端末装置１００は、イベント６０１とイベント４０４の両イベントを補正対象イベントとしてもよい。
【００８０】
この場合、携帯端末装置１００は、たとえば、イベント６０１とイベント４０４の予定開始時刻の平均値＝（時刻ｔ３＋時刻ｔ７）／２＝１２：４３：４５を仮想的なイベントの予定開始時刻と設定する。続けて、携帯端末装置１００は、両イベントの予定開始時刻を、仮想的なイベントの予定開始時刻に基づいて補正してもよい。これにより、イベント６０１と仮想的なイベントとの予定開始時刻の間隔、イベント４０４と仮想的なイベントとの予定開始時刻の間隔は、いずれか一方が補正対象イベントであったときより短くなる。したがって、携帯端末装置１００は、制約情報を順守しやすくなり、さらに２つのイベントの処理時間が重なった場合、消費電力を削減することができる。
【００８１】
また、関数ｆ１および関数ｆ２では、ＰｏｗｅｒＡｐｉＬｅｖｅｌは、補正対象イベントを実行するアプリ１の消費電力量の指標ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１を代入していた。ここで、ＰｏｗｅｒＡｐｉＬｅｖｅｌは、アプリ２の消費電力量の指標を用いてもよい。
【００８２】
また、アプリ１の消費電力量の指標とアプリ２の消費電力量の指標のうち、消費電力量の指標の値が大きい方を選択して用いてもよい。消費電力量の指標の値が大きい場合、すなわち消費電力量が小さい方を選択する理由は次のとおりである。アプリの消費電力量が小さい場合、それに伴うデバイス２０３の消費電力量も小さくなる。大きい消費電力量となる実行時間と小さい消費電力量となる実行時間とが重なる場合、小さい消費電力量の分が、消費電力の最大の削減量となる。このように、消費電力の最大の削減量は小さい消費電力量の方に左右されるため、携帯端末装置１００は、消費電力量の指標の値が大きい方を選択することで、消費電力量の最大の削減量に基づいてポーリング間隔を補正することができる。
【００８３】
以下、イベント管理ＡＰＩ２２２によってポーリング間隔Ｔを補正しない場合と補正した場合の消費電力量の違いに関して、図７と図８にて説明を行う。図７、図８では、携帯端末装置１００の消費電力の詳細として、ブラウザアプリ２１１の消費電力量、メールアプリ２１４の消費電力量、ＯＳ２０１の消費電力量、デバイス２０３の消費電力量を算出する例を示す。続けて、算出された各消費電力量を合計して、携帯端末装置１００の消費電力量を計算する例を示す。
【００８４】
なお、図７、図８では以下の前提条件が存在する。初めに、消費電力量の計算にあたって、ＣＰＵ１０１、デバイス２０３の低電力モードの消費電力を０［ｍＷ］と想定する。また、図７、図８で示すデバイス２０３は、ブラウザアプリ２１１とメールアプリ２１４が共にアクセスするデバイスである。たとえば、デバイス２０３は、Ｗｉ−ＦｉＩ／Ｆ１１０に接続されるアンテナ等である。さらに、ブラウザアプリ２１１の補正前のポーリング間隔を１９０秒と想定し、メールアプリ２１４の補正前のポーリング間隔を２０５秒と想定する。
【００８５】
図７は、ポーリング間隔Ｔを補正しない場合の携帯端末装置１００の消費電力量を示す説明図である。符号７０１で示す説明図が、時間変化に伴うブラウザアプリ２１１と、メールアプリ２１４と、ＯＳ２０１と、デバイス２０３と、の消費電力を示しており、表７０２が、符号７０１で示す説明図における消費電力量を示している。
【００８６】
また、図７、図８では、ブラウザアプリ２１１のイベントとして、イベント４０３、イベント６０１、予定開始時刻が時刻ｔ１０＝１２：４７：１０であるイベント７０５が実行されることを想定する。同様に、メールアプリ２１４のイベントとして、予定開始時刻が時刻ｔ１＝１２：４０：０５であるイベント７０３、イベント４０４、予定開始時刻が時刻ｔ９＝１２：４６：５５であるイベント７０４が実行されることを想定する。
【００８７】
アプリ２１０の消費電力量は、アプリ２１０によるＣＰＵ１０１の消費電力×アプリ２１０のＣＰＵ１０１平均使用率×（ＣＰＵ１０１のアクティブ時間＋一定時間）となる。なお、ＣＰＵ１０１のアクティブ時間＋一定時間をアプリ２１０の処理時間と設定する。また、ＣＰＵ１０１の消費電力以外に、メモリ１０６、バス１１１の消費電力も存在するが、図７、図８での計算では、メモリ１０６、バス１１１の消費電力をＣＰＵ１０１の消費電力に含めて計算する。
【００８８】
たとえば、図７の例では、ブラウザアプリ２１１によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、ブラウザアプリ２１１のＣＰＵ１０１平均使用率を０．５０と設定する。また、ブラウザアプリ２１１の処理時間を、ＣＰＵ１０１のアクティブ時間７［秒］＋一定時間３［秒］＝１０［秒］とする。また、ＣＰＵ１０１は、アクティブ時間を終了すると、一定時間経過後に低電力モードに遷移する。
【００８９】
ブラウザアプリ２１１の処理間隔は、図７より、時刻ｔ３＝１２：４０：５０〜時刻ｔ４＝１２：４１：００と、時刻ｔ７＝１２：４４：００〜時刻ｔ８＝１２：４４：１０と、時刻ｔ１０〜時刻ｔ１１＝１２：４７：２０となる。以上の値より、ブラウザアプリ２１１の消費電力量は、２［ｍＷ］×０．５０×（７［秒］＋３［秒］）×３［回］＝３０［ｍＷ秒］となる。
【００９０】
同様に、メールアプリ２１４によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、メールアプリ２１４のＣＰＵ１０１平均使用率を０．４０とする。また、メールアプリ２１４の処理時間を、ＣＰＵ１０１のアクティブ時間１２［秒］＋一定時間３［秒］＝１５［秒］とする。メールアプリ２１４の処理間隔は、図７より、時刻ｔ１〜時刻ｔ２＝１２：４０：２０と、時刻ｔ５＝１２：４３：３０〜時刻ｔ６＝１２：４３：４５と、時刻ｔ９＝１２：４６：５５〜時刻ｔ１０となる。以上の値より、メールアプリ２１４の消費電力量は、２［ｍＷ］×０．４０×（１２［秒］＋３［秒］）×３［回］＝３６［ｍＷ秒］となる。
【００９１】
続けて、ＯＳ２０１の消費電力量は、ＯＳ２０１によるＣＰＵ１０１の消費電力×ＯＳ２０１のＣＰＵ１０１平均使用率×ＯＳ２０１のアクティブ時間となる。また、ＣＰＵ１０１は、ＯＳ２０１のアクティブ時間を終了すると、一定時間経過後に低電力モードに遷移する。
【００９２】
なお、ＯＳ２０１のアクティブ時間は、アプリ２１０の処理時間となる。ＯＳ２０１によるＣＰＵ１０１の消費電力を２［ｍＷ］とし、ＯＳ２０１のＣＰＵ１０１平均使用率を０．５とする。また、ＯＳ２０１のアクティブ時間は、ブラウザアプリ２１１の処理時間とメールアプリ２１４の処理時間を重ねた時間となる。ＯＳ２０１のアクティブとなる時間間隔は、時刻ｔ１〜時刻ｔ２、時刻ｔ３〜時刻ｔ４、時刻ｔ５〜時刻ｔ６、時刻ｔ７〜時刻ｔ８、時刻ｔ９〜時刻ｔ１１となる。以上の値より、ＯＳ２０１の消費電力量は、２［ｍＷ］×０．５０×（７［秒］＋３［秒］＋１２［秒］＋３［秒］）×３［回］＝７５［ｍＷ秒］となる。
【００９３】
デバイス２０３の消費電力量は、デバイス２０３の消費電力×デバイス２０３のアクティブ時間となる。なお、デバイス２０３の消費電力以外に、デバイス２０３に接続されるＩ／Ｆの消費電力も存在するが、図７、図８での計算では、Ｉ／Ｆの消費電力をデバイス２０３の消費電力に含めて計算する。また、デバイス２０３は、デバイス２０３のアクティブ時間が終了すると、低電力モードに遷移する。
【００９４】
図７の例では、デバイス２０３の消費電力を０．５［ｍＷ］とする。また、デバイス２０３のアクティブ時間は、ブラウザアプリ２１１の処理時間とメールアプリ２１４の処理時間を重ねた時間となり、ＯＳ２０１のアクティブ時間と等しい。以上の値より、デバイス２０３の消費電力量は、０．５［ｍＷ］×（１０［秒］＋１５［秒］）×３［回］＝３７．５［ｍＷ秒］となる。以上より、携帯端末装置１００の消費電力量は、３０［ｍＷ秒］＋３６［ｍＷ秒］＋７５［ｍＷ秒］＋３７．５［ｍＷ秒］＝１７８．５［ｍＷ秒］となる。
【００９５】
図８は、ポーリング間隔Ｔを補正した場合の携帯端末装置１００の電力消費量を示す説明図である。符号８０１で示す説明図は、時間変化に伴うブラウザアプリ２１１と、メールアプリ２１４と、ＯＳ２０１と、デバイス２０３と、の消費電力を示しており、表８０２は、符号８０１で示す説明図における消費電力量を示している。また、ブラウザアプリ２１１によるイベントの予定開始時刻の補正が、イベント６０１と、イベント７０５に対して行われる。なお、符号７０１で示す説明図で使用された時刻ｔ１〜時刻ｔ１１と、符号８０１で示す説明図で使用された時刻ｔ１〜時刻ｔ１４とについては、時刻ｔ１〜時刻ｔ５までが同一時刻を示しており、時刻ｔ６以降は異なる時刻を示している。
【００９６】
また、イベント６０１の補正の算出内容については、図６で示した内容と等しいため、計算結果を省略する。補正の結果、イベント６０１の予定開始時刻は、時刻ｔ９＝１２：４４：００から時刻ｔ６＝１２：４３：４０に補正される。イベント７０５の補正の算出内容については、以下のとおりである。補正を行う現在時刻は、イベント６０１が終了する時刻ｔ８＝１２：４３：５０である。さらに、イベント７０５の予定開始時刻は、時刻ｔ６からポーリング間隔＝１９０［秒］を加算した時刻ｔ１０＝１２：４６：５０となる。現在時刻以後で最も早く実行されるイベントはイベント７０４となり、予定開始時刻ｔ１２＝１２：４６：５５となる。
【００９７】
イベント管理ＡＰＩ２２２は、関数ｆ１に各値を代入し、下記（６）式を得る。代入される値は、Ｐｏｌｌｉｎｇ＿Ａｐｌ１＝時刻ｔ１０、ＣｕｒｒｅｎｔＴｉｍｅ＝時刻ｔ８、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１＝時刻ｔ１２、定数＝１、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１＝３、ＢａｔｔｅｒｙＬｉｆｅ＝０．５となる。
【００９８】
Ｔ＝（時刻ｔ１０−時刻ｔ８）＋（時刻ｔ１２−時刻ｔ１０）＊１／（３＊０．５）
＝１８０＋５／（１．５）
≒１８３［秒］  …（６）
イベント管理ＡＰＩ２２２は、（１）式に（６）式を代入し、下記（７）式を得ることで、イベント７０５の補正後の予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２を算出する。
【００９９】
ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ２＝時刻ｔ８＋１８３
＝１２：４６：５３（時刻ｔ１１）  …（７）
【０１００】
算出した結果、イベント７０５の処理時間は、時刻ｔ１１〜時刻ｔ１３＝１２：４７：０３に補正される。ブラウザアプリ２１１の処理電力量については、図７と変わらず、３０［ｍＷ秒］となる。また、ポーリング間隔補正後のメールアプリ２１４の消費電力量について、メールアプリ２１４の処理間隔は、図８より、時刻ｔ１〜時刻ｔ２と、時刻ｔ５〜時刻ｔ７＝１２：４３：４５と、時刻ｔ１２〜時刻ｔ１４＝１２：４７：１０となる。このように、図７と図８とで、メールアプリ２１４の処理時間が等しいため、消費電力量も一致し、３６［ｍＷ秒］となる。
【０１０１】
続けて、ポーリング間隔補正後のＯＳ２０１の消費電力量について算出する。ＯＳ２０１のアクティブとなる時間間隔は、時刻ｔ１〜時刻ｔ２、時刻ｔ３〜時刻ｔ４、時刻ｔ５〜時刻ｔ８、時刻ｔ１１〜時刻ｔ１４となり、アクティブ時間の合計は、１５［秒］＋１０［秒］＋２０［秒］＋１７［秒］＝６２［秒］となる。この値は、図７で示したＯＳ２０１の実行時間＝（７［秒］＋３［秒］＋１２［秒］＋３［秒］）×３［回］＝７５［秒］より減少するが、時刻ｔ６〜時刻ｔ７、時刻ｔ１２〜時刻ｔ１３では、実行するアプリが２つ存在する分、ＯＳ２０１の仕事量が増加する。したがって、全体の仕事量は変化せず、ＯＳ２０１の消費電力量は、図７と同じ７５［ｍＷ秒］となる。
【０１０２】
続けて、ポーリング間隔補正後のデバイス２０３の消費電力量について算出する。デバイス２０３のアクティブ時間は、ＯＳ２０１のアクティブ時間と等しくなり、デバイス２０３の消費電力量は、０．５［ｍＷ］×（１５［秒］＋１０［秒］＋２０［秒］＋１７［秒］）＝３１［ｍＷ秒］となる。以上より、携帯端末装置１００の消費電力量は、３０［ｍＷ秒］＋３６［ｍＷ秒］＋７５［ｍＷ秒］＋３１［ｍＷ秒］＝１７２［ｍＷ秒］となる。携帯端末装置１００は、デバイス２０３の実行時間を１つに纏めることにより、消費電力を削減することができる。
【０１０３】
また、ブラウザアプリ２１１のポーリング間隔については、１度目の補正であるイベント６０１の補正によってはポーリング間隔＝１９０［秒］から、１７０［秒］へと、補正前のポーリング間隔から減少する結果となる。次に、１度目の補正により、同一処理の次のイベントであるイベント７０５の予定開始時刻が、現在時刻以後で最も早く実行されるイベント７０４より前の時間となる。これにより、２度目の補正であるイベント７０５の補正では、ポーリング間隔が１９０［秒］から１９３［秒］へと増加することになる。１度目と２度目の補正されたポーリング間隔の平均は、（１７０＋１９３）／２＝１８１．５［秒］となり、補正前のポーリング間隔＝１９０秒に近づくことになる。
【０１０４】
このように、携帯端末装置１００は、現在時刻以後で最も早く実行されるイベントの予定開始時刻に対して補正することで、補正対象イベントのポーリング間隔の長期的な平均を、補正前のポーリング間隔に収束させることができる。補正前のポーリング間隔に収束させることで、携帯端末装置１００は、制約情報を順守しやすくなる。特に、制約情報が特定の時間あたりの回数である場合、携帯端末装置１００は、長期的な平均が補正前のポーリング間隔に収束されることで、制約情報を順守しやすくなる。
【０１０５】
また、１度目の補正では、デバイス２０３の実行時間が２０［秒］となるが、２度目の補正では、デバイス２０３の実行時間が１７［秒］となっており、１度目の補正より、２度目の補正の方が消費電力の削減量が大きくなっている。このように、段階的に補正を行うことで、予定開始時刻の間隔が短くなるため、消費電力の削減量をより大きくすることができる。また、制約情報を順守したために１度目の補正でデバイス２０３の実行時間が短くならず、消費電力が削減されなくても、補正を行わなかった際の予定開始時刻の差分より、１度目の補正時による予定開始時刻の差分の方が小さくなる。したがって、携帯端末装置１００は、段階的に補正を行い、最終的にはデバイス２０３の実行時間が短くなり、消費電力を削減することができる。
【０１０６】
図９、図１０にて、ＯＳ２０１で行われるポーリング間隔の補正を行うポーリング間隔補正処理を示す。図９、図１０にて起動されるアプリは、アプリ２１０に含まれるアプリ１、アプリ２であることを想定する。携帯端末装置１００の運用時には、１つのアプリを起動してもよいし、３つ以上のアプリを起動してもよい。
【０１０７】
図９は、ポーリング間隔補正処理を示すフローチャート（その１）である。ＯＳ２０１は、携帯端末装置１００のブート終了後等に、ＯＳ２０１の動作を開始する（ステップＳ９０１）。動作開始後、ユーザからの指示等により、ＯＳ２０１は、アプリの起動要求を実行する（ステップＳ９０２）。起動要求を受けたアプリ１は、動作を開始する（ステップＳ９０３）。起動要求を受けたアプリ２も同様に、動作を開始する（ステップＳ９０４）。なお、動作を開始後、アプリ１と、アプリ２は、ポーリング補正を行うイベント発生処理を開始する。
【０１０８】
ＯＳ２０１は、電力制御ライブラリ２３２からＢａｔｔｅｒｙＬｉｆｅを取得する（ステップＳ９０５）。また、動作を開始したアプリ１は、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１をＯＳ２０１に通知する（ステップＳ９０６）。アプリ２も同様に、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ２、Ｐｏｌｌｉｎｇ＿Ａｐｌ２をＯＳ２０１に通知する（ステップＳ９０７）。また、ＯＳ２０１は、イベント管理ＡＰＩ２２２によって、現在時刻以後で最も早く実行されるイベント＿ｅ１を取得する（ステップＳ９０８）。
【０１０９】
以下、ＯＳ２０１は、ステップＳ９０６の処理による通知とステップＳ９０７の処理による通知のうち、ステップＳ９０６の処理による通知を先に受け付けたと想定する。イベント＿ｅ１の取得後、ＯＳ２０１は、ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅ１、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１、Ｐｏｌｌｉｎｇ＿Ａｐｌ１、ＢａｔｔｅｒｙＬｉｆｅ、ＣｕｒｒｅｎｔＴｉｍｅを関数ｆに代入し、ポーリング間隔Ｔ＿Ａｐｌ１を算出する（ステップＳ９０９）。
【０１１０】
なお、ステップＳ９０９の処理については、ステップＳ９０７によるアプリ２の通知の方が早い場合、ＯＳ２０１は、アプリ２の各値を代入してポーリング間隔Ｔ＿Ａｐｌ２を算出する。また、ステップＳ９０６による通知より遅い通知となったステップＳ９０７に関するアプリ２のポーリング間隔Ｔ＿Ａｐｌ２の算出は、再びステップＳ９０９が実行される際に行われる。また、ＣｕｒｒｅｎｔＴｉｍｅの取得については、ステップＳ９０９の実行前に、ＯＳ２０１がタイマＡＰＩ２２３を呼び出して取得する。
【０１１１】
算出後、ＯＳ２０１は、算出されたポーリング間隔Ｔをアプリへ通知する（ステップＳ９１０）。なお、通知先となるアプリに関して、ＯＳ２０１は、ステップＳ９０９で算出したポーリング間隔ＴがＴ＿Ａｐｌ１であればアプリ１へ、Ｔ＿Ａｐｌ２であればアプリ２へ通知する。
【０１１２】
図１０は、ポーリング間隔補正処理を示すフローチャート（その２）である。以下、ＯＳ２０１がステップＳ９１０にてアプリ１に通知した場合を想定する。アプリ１は、ポーリング間隔Ｔ＿Ａｐｌ１を取得する（ステップＳ１００１）。続けて、アプリ１は、アプリ１固有の動作により、イベント＿ｅＮの実行要求を発生させる（ステップＳ１００２）。なお、イベント＿ｅＮは、アプリ１が呼び出したイベント管理ＡＰＩ２２２により、イベントリスト２０２に登録される。登録後、アプリ１は、イベント＿ｅＮ実行時までスタンバイする（ステップＳ１００３）。なお、ステップＳ１００３にて、アプリ１は、イベント＿ｅＮを実行する以外に実行可能な他の処理が存在すれば、スタンバイせずに他の処理を実行してもよい。
【０１１３】
ＯＳ２０１は、イベント管理ＡＰＩ２２２によって、新たなイベント＿ｅＮが登録されたことが検出されたかを判断する（ステップＳ１００７）。検出された場合（ステップＳ１００７：Ｙｅｓ）、ＯＳ２０１は、イベント＿ｅＮを補正対象イベントとし、イベント＿ｅＮの予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮをＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１に補正する（ステップＳ１００８）。
【０１１４】
なお、ステップＳ１００１の処理にて、Ｔ＿Ａｐｌ１を取得したアプリ１は、自身が持つ制約情報に基づいて、Ｔ＿Ａｐｌ１を更新してもよい。たとえば、Ｔ＿Ａｐｌ１が１６０［秒］で通知されたが、アプリ１の制約情報として、ポーリング間隔が１７０［秒］〜１９０［秒］の範囲内と定められていることを想定する。このとき、アプリ１は、Ｔ＿Ａｐｌ１’＝１７０［秒］として、ステップＳ１００２の処理時にＴ＿Ａｐｌ１’をＯＳ２０１に通知する。続けて、ステップＳ１００８の処理にて、ＯＳ２０１は、イベント＿ｅＮの予定開始時刻ＮｅｘｔＰｏｌｌｉｎｇＴｉｍｅ＿ｅＮをＣｕｒｒｅｎｔＴｉｍｅ＋Ｔ＿Ａｐｌ１’に補正する。
【０１１５】
ステップＳ１００８の終了後、または、新たなイベントが検出されていない場合（ステップＳ１００７：Ｎｏ）、ＯＳ２０１は、イベントリスト２０２に登録されたイベントのうち、タイマＡＰＩ２２３により現在時刻がイベントの予定開始時刻以後となったかを判断する（ステップＳ１００９）。予定開始時刻以後である場合（ステップＳ１００９：Ｙｅｓ）、ＯＳ２０１は、イベントが予定開始時刻以後になったことをイベントに対応するアプリに通知する（ステップＳ１０１０）。アプリに通知後、または、予定開始時刻以後となったイベントがない場合（ステップＳ１００９：Ｎｏ）、ＯＳ２０１は、ステップＳ９０５の処理に移行する。
【０１１６】
予定開始時刻以後となったことの通知を受けたアプリ１は、イベント＿ｅＮを実行する（ステップＳ１０１１）。なお、通知を受けたアプリ１は、スタンバイせずに他の処理を実行している場合も有り得る。たとえば、イベント＿ｅＮの処理より優先度が高い他の処理が存在する場合である。この場合、アプリ１は、他の処理が完了してからイベント＿ｅＮの処理を行ってもよい。
【０１１７】
イベント＿ｅＮを実行後、アプリ１は、イベントが発生するループが終了するかを判断する（ステップＳ１０１２）。イベントが発生するループが継続する場合（ステップＳ１０１２：Ｎｏ）、アプリ１は、ステップＳ９０６の処理に移行する。イベントが発生するループが終了する場合（ステップＳ１０１２：Ｙｅｓ）、アプリ１は、ポーリング補正を行うイベント発生処理を終了する。
【０１１８】
なお、ステップＳ９０６の処理にて、ＰｏｗｅｒＡｐｉＬｅｖｅｌ＿Ａｐｌ１は、アプリ１固有の値であり、かつアプリ１実行中に変更されない。したがって、ステップＳ９０６の処理に移行したアプリ１は、２度目以降のステップＳ９０６の処理では、次のイベントの補正前の予定開始時刻であるＰｏｌｌｉｎｇ＿Ａｐｌ１のみをＯＳ２０１に送信してもよい。
【０１１９】
なお、ＯＳ２０１がステップＳ９１０にてアプリ２に通知した場合、アプリ１の代わりにアプリ２が処理を実行する。具体的には、アプリ２は、ポーリング間隔Ｔ＿Ａｐｌ２を取得する（ステップＳ１００４）。続けて、アプリ２は、アプリ２固有の動作により、イベント＿ｅＭの実行要求を発生させる（ステップＳ１００５）。なお、イベント＿ｅＭは、アプリ２が呼び出したイベント管理ＡＰＩ２２２により、イベントリスト２０２に登録される。登録後、アプリ２は、イベント＿ｅＭ実行時までスタンバイする（ステップＳ１００６）。なお、ステップＳ１００６にて、アプリ２はアプリ１と同様に、イベント＿ｅＭを実行する以外に行う他の処理が存在すれば、スタンバイせずに他の処理を実行してもよい。
【０１２０】
続けて、予定開始時刻以後となったことの通知を受けたアプリ２は、イベント＿ｅＭを実行し（ステップＳ１０１３）、イベントが発生するループが終了するかを判断する（ステップＳ１０１４）。イベントが発生するループが継続する場合（ステップＳ１０１４：Ｎｏ）、アプリ２は、ステップＳ９０７の処理に移行する。イベントが発生するループが終了する場合（ステップＳ１０１４：Ｙｅｓ）、アプリ２は、ポーリング補正を行うイベント発生処理を終了する。
【０１２１】
以上説明したように、情報処理装置、電力制御方法、および電力制御プログラムによれば、現在時刻以後で実行される２つのイベントのうち補正対象イベントの制約情報を順守する範囲内で、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、イベント処理に伴って実行されるデバイスの実行時間が最終的には纏められ、消費電力を削減できる。
【０１２２】
また、情報処理装置は、２つのイベントと同一処理内容で２つの先行イベントが実行され、２つの先行イベントの処理時間が重ならなかった場合に、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。たとえば、制約情報によって、補正できる値が制限された結果、先行する２つのイベントの処理時間が重ならない場合もある。または、補正されたイベントを実行するアプリは、イベント処理より優先度の高い他の処理を実行している可能性がある。したがって、アプリは、必ずしも補正されたイベントの予定開始時刻でイベントを実行するとは限らず、２つのイベントの処理時間が重ならない場合もある。
【０１２３】
しかしながら、２つの先行イベントの補正前の予定開始時刻の差分と、２つの先行イベントが実行された開始時刻の差分では、後者の差分の方がより短い。よって、先行イベントの次に行われる２つのイベントの差分は、２つの先行イベントの補正前の予定開始時刻の差分より小さくなっており、処理時間が重なりやすくなる。このように、情報処理装置は、２つのイベントの処理時間が重ならなくても、段階的に補正することで、最終的に処理時間が重なり、消費電力を削減することができる。
【０１２４】
また、情報処理装置は、先行する２つのイベントの予定開始時刻が補正された結果、先行する２つのイベントの処理時間が重ならなかった場合、現在時刻以後に実行される２つのイベントの予定開始時刻を検出してもよい。制約情報によって、補正できる値が制限された結果、補正を行った時点で先行する２つのイベントの処理時間が重ならないことが明らかな場合もある。しかしながら、先行イベントの次に行われる２つのイベントの差分は、２つの先行イベントの補正前の予定開始時刻の差分より小さくなっており、処理時間が重なりやすくなる。このように、情報処理装置は、補正の結果２つのイベントの処理時間が重ならなくても、段階的に補正することで、最終的に処理時間が重なり、消費電力を削減することができる。
【０１２５】
また、情報処理装置は、２つのイベントのうち遅く検出された方を補正対象イベントとしてもよい。早く検出された方のイベント、具体的にはイベントリスト２０２に登録されたイベントについては、既に補正済である場合が存在する。もし、早く検出された方のイベントを補正対象イベントとし、予定開始時刻の補正を行った場合、既に補正された内容が無駄になってしまう可能性がある。したがって、情報処理装置は、遅く検出された方を補正対象イベントとすることで、既に補正された内容を無駄にせずに済む。
【０１２６】
また、情報処理装置は、現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと他のイベントとを２つのイベントとして検出し、他のイベントの方を補正対象イベントとしてもよい。これにより、情報処理装置は、補正対象イベントのポーリング間隔の長期的な平均を、補正前のポーリング間隔に収束させることができる。ポーリング間隔の長期的な平均が補正前のポーリング間隔に収束されることで、情報処理装置は、制約情報を順守しやすくなる。
【０１２７】
また、情報処理装置は、算出された差分と２つのイベントのうちいずれか一方のイベントの消費電力量とに基づいて、補正対象イベントの予定開始時刻を補正してもよい。具体的には、情報処理装置は、イベントの消費電力量が大きいほど、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、消費電力に大きく影響を与えるアプリの消費電力を削減することができる。また、イベントの消費電力量が小さい場合、補正前のポーリング間隔を優先することになり、情報処理装置は、制約情報を順守しやすくなる。
【０１２８】
また、情報処理装置は、算出された差分と自装置の有する電力の残量とに基づいて、補正対象イベントの予定開始時刻を補正してもよい。具体的には、情報処理装置は、電力の残量が少ないほど、２つのイベントの予定開始時刻の間隔が短くなるように補正する。これにより、情報処理装置は、電力の残量が少ない場合、電力の消費を抑えることができる。また、電力の残量が多い場合、補正前のポーリング間隔を優先することになり、情報処理装置は、制約情報を順守しやすくなる。
【０１２９】
なお、本実施の形態で説明した電力制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本電力制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本電力制御プログラムは、インターネット等のネットワークを介して配布してもよい。
【０１３０】
上述した実施の形態に関し、さらに以下の付記を開示する。
【０１３１】
（付記１）現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出手段と、
前記検出手段によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出手段と、
前記算出手段によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正手段と、
を備えることを特徴とする情報処理装置。
【０１３２】
（付記２）前記検出手段は、
前記現在時刻以前に実行された２つのイベントに対応する２つの先行イベントが実行された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする付記１に記載の情報処理装置。
【０１３３】
（付記３）前記検出手段は、
前記２つの先行イベントの予定開始時刻が前記補正手段によって補正された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする付記１に記載の情報処理装置。
【０１３４】
（付記４）前記補正手段は、
前記差分に基づいて、前記２つのイベントのうち前記検出手段によって遅く検出された方を前記補正対象イベントとして、前記補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正することを特徴とする付記１に記載の情報処理装置。
【０１３５】
（付記５）前記検出手段は、
前記現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと前記最も早く実行されるイベント以外となる他のイベントとを前記２つのイベントとして検出することを特徴とする付記４に記載の情報処理装置。
【０１３６】
（付記６）前記補正手段は、
さらに、前記２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする付記１に記載の情報処理装置。
【０１３７】
（付記７）前記補正手段は、
さらに、自装置の有する電力の残量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする付記１に記載の情報処理装置。
【０１３８】
（付記８）コンピュータが、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行することを特徴とする電力制御方法。
【０１３９】
（付記９）コンピュータに、
現在時刻以後に実行される２つのイベントの予定開始時刻を検出する検出工程と、
前記検出工程によって前記２つのイベントの予定開始時刻が検出された場合、前記２つのイベントの予定開始時刻の差分を算出する算出工程と、
前記算出工程によって算出された前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する補正工程と、
を実行させることを特徴とする電力制御プログラム。
【符号の説明】
【０１４０】
１０１  ＣＰＵ
１０６  メモリ
１１１  バス
２０１  ＯＳ
２０２  イベントリスト
２１０  アプリ
２１１  ブラウザアプリ
２１４  メールアプリ
５０１  検出部
５０２  算出部
５０３  補正部
【手続補正書】
【提出日】平成26年1月6日(2014.1.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
デバイスを有する情報処理装置であって、
同一である前記デバイスを使用し現在時刻以後に実行される２つのイベントの予定開始時刻を検出し、
前記２つのイベントの予定開始時刻を検出した場合、前記２つのイベントの予定開始時刻の差分を算出し、
算出した前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する、
制御部を有することを特徴とする情報処理装置。
【請求項２】
前記制御部は、
前記２つのイベントに対応する前記現在時刻以前に実行された２つの先行イベントが実行された結果、前記２つの先行イベントの処理時間が重ならなかった場合、前記現在時刻以後に実行される２つのイベントの予定開始時刻を検出することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記制御部は、
前記差分に基づいて、前記２つのイベントのうち遅く検出した方を前記補正対象イベントとして、前記補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記制御部は、
前記現在時刻以後に実行されるイベント群のうち、最も早く実行されるイベントと前記最も早く実行されるイベント以外となる他のイベントとを前記２つのイベントとして検出することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記制御部は、
さらに、前記２つのイベントのうちいずれか一方のイベントの消費電力量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
前記制御部は、
さらに、自装置の有する電力の残量に基づいて、前記補正対象イベントの予定開始時刻を補正することを特徴とする請求項１〜５のいずれか一つに記載の情報処理装置。
【請求項７】
デバイスを有するコンピュータが、
同一である前記デバイスを使用し現在時刻以後に実行される２つのイベントの予定開始時刻を検出し、
前記２つのイベントの予定開始時刻を検出した場合、前記２つのイベントの予定開始時刻の差分を算出し、
算出した前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する、
処理を実行することを特徴とする電力制御方法。
【請求項８】
デバイスを有するコンピュータに、
同一である前記デバイスを使用し現在時刻以後に実行される２つのイベントの予定開始時刻を検出し、
前記２つのイベントの予定開始時刻を検出した場合、前記２つのイベントの予定開始時刻の差分を算出し、
算出した前記差分に基づいて、前記２つのイベントのうち少なくともいずれか一方となる補正対象イベントの制約情報を順守する範囲内で、前記２つのイベントの予定開始時刻の間隔が短くなるように前記補正対象イベントの予定開始時刻を補正する、
処理を実行させることを特徴とする電力制御プログラム。
【国際調査報告】
2012081079.tif 000013
2012081079.tif 000014
2012081079.tif 000015
2012081079.tif 000016