JP5839119B2 - 情報処理装置、電池残量通知方法および電池残量通知プログラム - Google Patents

Description

本発明は、電池で駆動される（battery-powered）情報処理装置に関する。

何らかの条件に応じて、情報処理装置の構成または動作を変更するための様々な技術が開発されている。

例えば、情報処理装置の稼働中に、ＣＰＵ（Central Processing Unit）やメモリなどのデバイスを、情報処理装置に動的に追加したり、情報処理装置から動的に削除したりする技術が知られている。当該技術は、「ホットプラグ（hot plug）」と呼ばれる。ホットプラグ機能によるデバイスの動的な追加または削除は、情報処理装置の負荷に応じて行われる場合もあるし、ユーザからのコマンド入力にしたがって行われる場合もある。

ホットプラグ機能によるデバイスの動的な追加と削除は、それぞれ「ホットアド（hot-add）」および「ホットリムーブ（hot-remove）」とも呼ばれる。場合によっては、ホットアドが「ホットプラグ」と呼ばれ、ホットリムーブが「ホットアンプラグ（hot-unplug）」と呼ばれることもあるが、本明細書ではホットアドとホットリムーブを含む技術を「ホットプラグ」という。

また、電池で駆動される装置においては、電池残量（remaining battery capacity）に応じた制御が行われることもある。例えば、予め決められたポリシと電池残量に応じて、デバイスへの電力供給やデバイスの動作周波数をオペレーティング・システムが制御することもある。

電池で駆動される装置に関しては、消費される電力量（electrical energy）を抑制することがユーザの利便性向上につながる。よって、消費電力量を抑制するための様々な技術が提案されている。

さらに、電池で駆動される情報処理装置の多くは、電池残量を表示する機能を有する。電池残量の表示を更新するタイミングや、より正確に電池残量を表示するための方法についても、様々な提案がなされている。

例えば、複数のプログラムを実行する情報処理装置について、次のような技術が提案されている。

当該情報処理装置は、記憶手段と検知手段と取得手段と実行手段を有する。記憶手段は、第１のプログラムが設定する状態情報、および第２のプログラムが設定するコールバック情報を、それぞれ対応づけて記憶する。また、検知手段は、第１のプログラムが設定する状態情報が変化したことを検知する。取得手段は、検知手段が第１のプログラムの状態が変化したことを検知した際に、第２のプログラムが設定するコールバック情報を取得する。実行手段は、コールバック情報に基づいてコールバックを呼び出す。

例えば、記憶手段は、状態情報として、電池レベルの情報を記憶してもよく、コールバック情報として、電池レベルを通知するプログラムを記憶してもよい。この場合、実行手段は、コールバック情報に基づいて電池レベルを通知してもよい。

また、消費電力量を抑制するための様々な技術が提案されている。例えば、仮想マシン機能により実行されるアプリケーションソフトウェアの終了処理が忘れられてしまうことにより、バッテリが消耗することがある。そのようなバッテリの消耗を抑制することを目的として、次のような携帯端末が提案されている。

当該携帯端末には、タッチセンサ部が設けられている。タッチセンサ部は、当該携帯端末にユーザが触れていることを、検知することができる。

そして、制御部にタッチセンサ部から接触信号が出力されているときは、「携帯端末がユーザにより使用中である」と判定される。逆に、非接触信号が出力されているときには、「携帯端末は現在使用されていない」と判定される。

当該携帯端末上でアプリケーションソフトウェアが実行されているときに、タッチセンサ部から非接触信号が出力されたとき、制御部は、実行中のアプリケーションソフトウェアの実行を一時中断する。この一時中断により、携帯端末の消費電力量は抑えられる。

さらに、仮想マシンシステムの消費電力量を仮想マシンごとに抑制できるようにするため、以下のような仮想マシンシステムも提案されている。
当該仮想マシンシステムにおいて、仮想バッテリ管理部は、仮想マシンへ仮想バッテリを提供する。また、仮想バッテリ管理部は、仮想マシンシステムの消費電力量を示す消費電力量ポリシ、仮想マシンへの充電量を示す充電量ポリシ、仮想マシンへの電力の配分率を示す電力配分テーブルを設定する。

そして、スケジュール管理部が、仮想マシンへリソースを割り当てる。当該仮想マシンシステムにおいては、仮想マシンへのリソース割り当て量が、リソース割り当て量管理部から得られる。

仮想マシンが駆動中であれば、消費電力量ポリシと電力配分テーブルを参照してＣＰＵ使用時間を放電量に換算して仮想バッテリの残量を減少させる処理が行われる。逆に、仮想マシンが停止中であれば、充電量ポリシと電力配分テーブルを参照して停止時間を充電量に換算して仮想バッテリの残量を増加させる処理が行われる。

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

Mwaikambo, Z., Raj, A., Russell, R., Schopp, J., and Vaddagiri, S., "Linux Kernel Hotplug CPU Support", Proceedings of the Linux Symposium, 2004, Vol. 2, pp. 467-480.（なおLinuxは登録商標）

何らかのポリシにしたがって、電池の残量に応じて、適切に電力を使用するための電源管理機能は、様々なオペレーティング・システムに実装されている。

一方で、１台の情報処理装置上で複数のオペレーティング・システムが動作することもある。具体的には、情報処理装置上でハイパーバイザが動作し、ハイパーバイザ上で複数のオペレーティング・システムが動作することもある。このようにハイパーバイザ上で複数のオペレーティング・システムが動作する環境においては、個々のオペレーティング・システムが互いに独立に電源管理を行うと、情報処理装置全体としては、適切に電力が使用されないおそれがある。

本発明は、１つの側面では、ハイパーバイザ上で複数のオペレーティング・システムが動作する場合にも、情報処理装置全体として適切に電力が使用されるようにすることを目的とする。

一態様による情報処理装置は、電池で駆動され、評価部と通知部を有する。また、前記情報処理装置上で動作するハイパーバイザ上では、複数のオペレーティング・システムが動作する。

前記評価部は、前記複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価する。そして、前記通知部は、前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記評価部が評価した値である仮想残量値を通知する。

上記の情報処理装置によれば、ハイパーバイザ上で複数のオペレーティング・システムが動作する場合にも、情報処理装置全体として適切に電力が使用される。

第１実施形態の情報処理装置のブロック構成図である。 情報処理装置のハードウェア構成の例を示す図である。 第２実施形態の情報処理装置のブロック構成図である。 第２実施形態で使われるプロファイルの例を示す図である。 第２実施形態で使われるルールセットの例を示す図である。 第２実施形態の情報処理装置が行う処理のフローチャート（その１）である。 第２実施形態の情報処理装置が行う処理のフローチャート（その２）である。 第２実施形態において履歴を使わずに仮想残量値を計算する例を示す図である。 第２実施形態において履歴を使って仮想残量値を計算する例を示す図である。 第３〜第５実施形態で使われる割り当てルールの例を示す図である。 第３実施形態でハイパーバイザが行う処理のフローチャートである。 第４〜第５実施形態でハイパーバイザが行う処理のフローチャートである。 仮想ハードウェアの動的な構成変更の効果を説明する図である。

以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図１を参照して第１実施形態について説明する。次に、図２を参照して、第１〜第５実施形態のいずれも適用可能な情報処理装置のハードウェア構成の例を説明する。その後、図３〜９を参照して第２実施形態について説明する。さらに、図１０〜１１を参照して第３実施形態について説明し、図１０と１２を参照して第４実施形態について説明し、第５実施形態についても図１０と１２を参照して説明する。また、第３〜第５実施形態の効果について図１３を参照して説明する。最後に、その他の変形例についても説明する。

図１は、第１実施形態の情報処理装置のブロック構成図である。図１の情報処理装置１００は、電池１０１で駆動される。電池１０１は、１次電池でもよいし、充電可能な２次電池でもよい。

電池１０１で駆動される情報処理装置１００は、具体的には、例えば、以下の（１ａ）〜（１ｇ）のいずれの種類であってもよい。

（１ａ）ノート型ＰＣ（Personal Computer）
（１ｂ）タブレット端末
（１ｃ）ＰＤＡ（Personal Digital Assistant）
（１ｄ）スマートフォン
（１ｅ）携帯電話
（１ｆ）携帯型メディアプレーヤ
（１ｇ）その他の各種携帯端末

また、情報処理装置１００は、ハイパーバイザを用いて仮想化されており、ハイパーバイザ上で複数のオペレーティング・システム（以下「ＯＳ」と略す）が動作する（run）。より詳しくは、情報処理装置１００上でハイパーバイザが動作し、ハイパーバイザ上で複数の仮想マシンが動作し、各仮想マシン上で各ＯＳが動作する。

例えば、図１には、２つのＯＳ１０２ａと１０２ｂが例示されているが、ＯＳの数（すなわち仮想マシンの数）は、実施形態に応じて任意である。なお、図１では仮想マシンは省略されている。

また、情報処理装置１００は、評価部１０３と通知部１０４を有する。
評価部１０３は、複数のＯＳ（例えばＯＳ１０２ａと１０２ｂ）それぞれに対応する、電池１０１の仮想的な残量を評価する。以下では、評価部１０３が評価した値を「仮想残量値」という。評価部１０３は、具体的には、複数のＯＳ（例えばＯＳ１０２ａと１０２ｂ）それぞれの特性を示す特性情報と、電池１０１の物理的な残量を示す値（以下、「物理残量値」という）を用いて、各仮想残量値を評価する。ある観点から見れば、特性情報は、各仮想マシンの特性を示す情報でもある。

通知部１０４は、ＯＳ１０２ａに対応して評価部１０３が評価した仮想残量値を、ＯＳ１０２ａに通知する。また、通知部１０４は、ＯＳ１０２ｂに対応して評価部１０３が評価した仮想残量値を、ＯＳ１０２ｂに通知する。

情報処理装置１００は、評価部１０３が評価に用いる特性情報と物理残量値をそれぞれ取得するための、第１の取得部１０５と第２の取得部１０６をさらに有していてもよい。

第１の取得部１０５は、各ＯＳの特性を示す特性情報を取得する。特性情報は、静的に予め決められた情報でもよいし、動的に変化する情報でもよいし、両者の組み合わせでもよい。

換言すれば、第１の取得部１０５は、情報処理装置１００の不図示の記憶装置に記憶された静的な特性情報を、記憶装置から読み取ってもよい。それにより、第１の取得部１０５は、静的な特性情報を記憶装置から取得してもよい。

あるいは、第１の取得部１０５は、ＯＳ１０２ａおよび１０２ｂ（ならびに、ＯＳ１０２ａおよび１０２ｂ上で動作するアプリケーション）の実際の動作（activity）に基づいて、動的な特性情報を生成してもよい。換言すれば、第１の取得部１０５は、各仮想マシンの実際の動作に基づいて、動的な特性情報を生成してもよい。それにより、第１の取得部１０５は、動的な特性情報を取得してもよい。

例えば、ＯＳ１０２ａの特性情報は、以下の（２ａ）と（２ｂ）に示す２種類の情報のうち少なくとも一方を含んでもよい。

（２ａ）ＯＳ１０２ａ、およびＯＳ１０２ａ上で動作するアプリケーションにより使用された、資源の量を示す使用状況情報。
（２ｂ）ＯＳ１０２ａの優先度を示す優先度情報。

同様に、ＯＳ１０２ｂの特性情報は、以下の（３ａ）と（３ｂ）に示す２種類の情報のうち少なくとも一方を含んでもよい。

（３ａ）ＯＳ１０２ｂ、およびＯＳ１０２ｂ上で動作するアプリケーションにより使用された、資源の量を示す使用状況情報。
（３ｂ）ＯＳ１０２ｂの優先度を示す優先度情報。

使用状況情報は動的な特性情報の例であり、優先度情報は静的な特性情報の例である。
なお、使用状況情報によって使用量が示される資源は、具体的には電力資源であってもよい。例えば、ある期間で消費される電力量または当該期間での推定平均電力を示す値が、使用状況情報として使われてもよい。

あるいは、使用状況情報によって使用量が示される資源は、情報処理装置１００が有するハードウェア資源であってもよいし、情報処理装置１００から使用可能なネットワーク資源であってもよい。

例えば、消費電力量に関するＯＳ１０２ａの特性を表す特性情報は、具体的には、「ＯＳ１０２ａ（およびＯＳ１０２ａ上のアプリケーション）によって、ハードウェア資源やネットワーク資源がどれほど使用されたか」を示す使用状況情報を含んでもよい。ＯＳ１０２ａ（およびＯＳ１０２ａ上のアプリケーション）に起因する消費電力量は、ＯＳ１０２ａ（およびＯＳ１０２ａ上のアプリケーション）によって使用された資源の量に依存する。よって、上記のような使用状況情報は、間接的に、消費電力量に関するＯＳ１０２ａの特性（換言すれば、ＯＳ１０２ａの動作する仮想マシンの特性）を表す。

使用状況情報は、ある特定の１つの期間（例えば、長さが１分間の直近の期間）において各ＯＳ（およびＯＳ上のアプリケーション）がどれほど資源を使用したかを示してもよい。

あるいは、情報処理装置１００は、使用状況情報の履歴を図１には不図示の記憶部に記憶していてもよい。そして、評価部１０３は、仮想残量値の評価に際して、使用状況情報の履歴を用いてもよい。換言すれば、特性情報は、複数の期間のそれぞれと対応づけられた使用状況情報を含んでもよい。

さて、第２の取得部１０６は、電池１０１の物理的な残量を示す物理残量値を取得する。

評価部１０３は、複数のＯＳそれぞれの特性情報と、物理残量値とを用いて、複数のＯＳそれぞれに対応する仮想残量値を評価する。また、通知部１０４は、上記のとおり、各ＯＳに仮想残量値を通知する。

なお、評価部１０３は、予め決められた数式にしたがって、特性情報と物理残量値から仮想残量値を計算してもよい。つまり、評価部１０３は、計算によって仮想残量値を評価してもよい。

あるいは、特性情報は、複数の物理残量値にそれぞれ仮想残量値を対応づける換算表のような情報であってもよい。この場合、評価部１０３は、第２の取得部１０６により取得された物理残量値と対応づけられている仮想残量値を換算表から読み取ることにより、仮想残量値を評価してもよい。もちろん、評価部１０３は、換算表と補間計算によって仮想残量値を評価してもよい。

さて、ＯＳ１０２ａに仮想残量値が通知されると、ＯＳ１０２ａは、予め設定された電源管理のためのポリシにしたがって、通知された仮想残量値に応じて、適宜に電源を管理する。例えば、ＯＳ１０２ａは、ディスプレイの明るさを調整するための命令を発行してもよいし、ＣＰＵのクロック周波数を調整するための命令を発行してもよい。これらの命令は、具体的には、ハイパーバイザコールであってもよい。

ＯＳ１０２ａに設定される電源管理のためのポリシは、例えば、以下の（４ａ）〜（４ｃ）のポリシのうちのいずれか１つであってもよい。

（４ａ）パフォーマンスを低下させて消費電力量を抑えることで、電池１０１を長持ちさせるための、「省電力」ポリシ。
（４ｂ）消費電力量の増加には構わず、パフォーマンスを向上させるための、「ハイパフォーマンス」ポリシ。
（４ｃ）両者のバランスをとった、「バランス」(balanced）ポリシ。

同様に、ＯＳ１０２ｂに仮想残量値が通知されると、ＯＳ１０２ｂは、予め設定された電源管理のためのポリシ（例えば（４ａ）〜（４ｃ）のいずれかのポリシでもよい）にしたがって、通知された仮想残量値に応じて、適宜の省電力制御を実行する。

なお、仮想残量値は特性情報に依存するので、ＯＳ１０２ａに通知される仮想残量値とＯＳ１０２ｂに通知される仮想残量値は、必ずしも同じではない。

また、ＯＳ１０２ａに設定されたポリシとＯＳ１０２ｂに設定されたポリシも、必ずしも同じではない。例えば、以下の（５ａ）や（５ｂ）のような場合があり得る。

（５ａ）ＯＳ１０２ａは「省電力」ポリシにしたがって電源を管理する一方で、ＯＳ１０２ｂは「ハイパフォーマンス」ポリシにしたがって電源を管理する場合。
（５ｂ）ＯＳ１０２ａと１０２ｂの両者とも「省電力」ポリシにしたがって電源を管理するものの、ＯＳ１０２ａの「省電力」ポリシを規定するパラメタの値と、ＯＳ１０２ｂの「省電力」ポリシを規定するパラメタの値が異なる場合。

いずれにしろ、ＯＳ１０２ａと１０２ｂは独立に、それぞれのポリシにしたがって、それぞれに通知された仮想残量値に応じて適宜の制御を行う。

ところで、評価部１０３による評価の詳細は、情報処理装置１００全体についての電源管理のためのポリシに応じて、様々であってよい。情報処理装置１００全体についての電源管理のためのポリシは、ＯＳ１０２ａと１０２ｂそれぞれのポリシとは別に定義される。情報処理装置１００全体についての電源管理のためのポリシは、例えば、以下の（６ａ）〜（６ｃ）のポリシのうちのいずれか１つであってもよい。

（６ａ）「ＯＳ１０２ａと１０２ｂの双方を含む情報処理装置１００全体として、ハイパフォーマンスが達成されることが好ましい」というポリシ。
（６ｂ）「電池１０１をなるべく長持ちさせることが好ましい」というポリシ。
（６ｃ）両者のバランスをとったポリシ。

評価部１０３は、情報処理装置１００全体についての電源管理のためのポリシに応じて決められた適宜の式にしたがって、各ＯＳの仮想残量値を計算してもよい。

特性情報が使用状況情報を含む場合、仮想残量値は、使用状況情報が示す資源使用量に対して単調増加するよう定義されていてもよい。特性情報が優先度情報を含む場合、仮想残量値は、優先度情報が示す優先度に対して単調増加するよう定義されていてもよい。

また、評価部１０３は、特定の条件下では、当該特定の条件が成立しない場合とは異なる方法で、仮想残量値を評価（あるいは再評価）してもよい。特定の条件の例は、例えば以下の（７ａ）〜（７ｃ）の条件である。

（７ａ）「電池１０１が充電中である」という条件。
（７ｂ）「物理残量値が閾値未満である」という条件。
（７ｃ）「評価部１０３により得られた仮想残量値が、閾値未満である」という条件。

例えば、電池１０１が充電中のとき、評価部１０３は、複数のＯＳのうち少なくとも１つ以上のそれぞれに関して、「仮想残量値は、物理残量値の定義域の最大値に等しい」と見なしてもよい。つまり、この場合、通知部１０４は、複数のＯＳのうち少なくとも１つ以上のそれぞれに対して、物理残量値の定義域の最大値を、仮想残量値として通知する。

例えば、物理残量値がＷｈ（ワット時）単位で表されてもよい。この場合、物理残量値の定義域の最大値は、電池１０１の仕様で定められている値（具体的には、フル充電された状態から電池１０１が供給することのできる電力量を示す値）であってもよい。

あるいは、物理残量値がパーセンテージで表されてもよい。この場合、物理残量値の定義域の最大値は１００である。

以上のように、電池１０１が充電中のとき、実際の物理残量値によらず、物理残量値の定義域の最大値が、仮想残量値として通知されてもよい。

ところで、複数のＯＳのうち少なくとも１つ以上のそれぞれに関して、当該ＯＳに対応する仮想残量値の定義域の最大値が定義されていてもよい。例えば、特性情報が優先度情報を含む場合、優先度情報と、物理残量値の定義域の最大値とに応じて、仮想残量値の定義域の最大値が定義されていてもよい。そして、電池１０１が充電中のとき、もし、或るＯＳに関して仮想残量値の定義域の最大値が定義されているならば、評価部１０３は、当該ＯＳに対応する仮想残量値を、仮想残量値の定義域の最大値と見なしてもよい。

あるいは、電池１０１が充電中のとき、評価部１０３は、実際の物理残量値とは関係なく、「物理残量値は、物理残量値の定義域の最大値である」と見なしてもよい。そして、評価部１０３は、このようにして最大値と見なした物理残量値を用いて、複数のＯＳそれぞれに対応する仮想残量値の評価を行ってもよい。

または、電池１０１が充電中のとき、評価部１０３は、複数のＯＳのうち少なくとも１つ以上のそれぞれに対応する仮想残量値を、物理残量値と同じであると見なしてもよい。

また、物理残量値が第１の閾値未満のとき、評価部１０３は、複数のＯＳのうち少なくとも１つ以上のそれぞれに関して、「仮想残量値がゼロである」と見なしてもよい。つまり、この場合、通知部１０４は、複数のＯＳのうち少なくとも１つ以上のそれぞれに対して、「仮想残量値がゼロである」と通知する。

複数のＯＳのうちの或るＯＳに対応する仮想残量値が第２の閾値未満のとき、評価部１０３は、「当該或るＯＳに対応する仮想残量値はゼロである」と再評価してもよい。つまり、この場合、通知部１０４は、当該或るＯＳに対して、「仮想残量値がゼロである」と通知する。

なお、情報処理装置１００は、不図示の表示部をさらに有していてもよい。表示部は、複数のＯＳのうちの少なくとも１つに通知された仮想残量値に応じて、文字、画像、またはその組み合わせを表示する。表示部は、例えば、「７０％」のように文字列により仮想残量値を表示してもよい。または、表示部は、例えば、仮想残量値を３個のレベルで示すアイコンを表示してもよい。

以上説明した情報処理装置１００の動作は、情報処理装置１００内のプロセッサが所定のプログラムを実行することによって実現されてもよい。当該所定のプログラムは、例えば、電池１０１のデバイスドライバのプログラムに含まれていてもよいし、ハイパーバイザのプログラムの中に含まれていてもよい。電池１０１のデバイスドライバは、具体的には、ハイパーバイザで動作する。

以上説明した図１の情報処理装置１００によれば、ハイパーバイザ上で複数のＯＳが動作する場合にも、情報処理装置１００全体として適切に電力が使用される。以下に、２つの比較例（便宜上、「第１比較例」と「第２比較例」という）と図１の情報処理装置１００との比較を通じて、情報処理装置１００の利点について説明する。

第１および第２比較例では、第１実施形態のように通知部１０４がＯＳごとに仮想残量値を通知するのではなく、ハイパーバイザがどのＯＳにも同じ物理残量値を通知するものとする。つまり、第１および第２比較例には、評価部１０３も通知部１０４も第１の取得部１０５も第２の取得部１０６も存在しない。

ところで、各ＯＳは、当該ＯＳに物理残量値が通知されたのか、それとも当該ＯＳに仮想残量値が通知されたのかを認識しない。よって、図１の第１実施形態においても、第１および第２比較例においても、各ＯＳは、単に「電池の残量を示す値が通知された」と認識する。

また、各ＯＳは、「他のＯＳがどのようなポリシにしたがって電源を管理するか」ということに関与しない。換言すれば、複数のＯＳは独立に電源を管理する。
そして、或るＯＳのポリシと別のＯＳのポリシは異なる場合があり得る。また、たとえ複数のＯＳにおいて互いに似たポリシが使われているとしても、或るＯＳのポリシを規定するパラメタの値が、別のＯＳのポリシを規定するパラメタの値とは異なる場合もあり得る。

第１比較例と第１実施形態では、このようにＯＳごとにポリシまたはパラメタが異なることがあり得る。第２比較例では逆に、全ＯＳがまったく同じポリシにしたがって電源を管理するものとする。

第１比較例では、同じ物理残量値が全ＯＳに通知されるため、情報処理装置１００全体としては適切に電力が使われないことがあり得る。説明の便宜上、例えば以下の（８ａ）〜（８ｅ）のように仮定する。

（８ａ）第１比較例においても、２つのＯＳ１０２ａと１０２ｂがハイパーバイザ上で動作する。
（８ｂ）ＯＳ１０２ａには、「電池１０１の残量が３０％以上なら通常モードで動作し、電池１０１の残量が３０％未満なら省電力モードで動作する」というポリシが設定されている。
（８ｃ）ＯＳ１０２ｂには、「電池１０１の残量が１０％以上なら通常モードで動作し、電池１０１の残量が１０％未満なら省電力モードで動作する」というポリシが設定されている。
（８ｄ）通常モードは、パフォーマンスの向上を消費電力量の抑制よりも優先するモードである。
（８ｅ）省電力モードは、消費電力量の抑制をパフォーマンスの向上よりも優先するモードである。

以上の（８ａ）〜（８ｅ）の仮定のもとで、仮に物理残量値が２０％であったとする。すると、第１比較例においては、ＯＳ１０２ａが省電力モードで動作する一方、ＯＳ１０２ｂは通常モードで動作する。通常モードで動作するＯＳが存在すると、消費電力量は比較的大きい。その結果、第１比較例では、「ＯＳ１０２ａは電池１０１を長持ちさせるために省電力モードで動作しているにも関わらず、意図通りには電池１０１は長持ちしない」という事態が生じ得る。

あるいは、（８ａ）〜（８ｅ）の仮定のもとで、仮に物理残量値が５０％であったとする。すると、第１比較例においては、ＯＳ１０２ａと１０２ｂの双方が通常モードで動作するので、電池残量がすぐに減ってしまう。

一方、ＯＳ１０２ａと１０２ｂは、電源管理のために電池１０１の残量が０％になるまでにかかる時間を予測してもよいが、第１比較例ではこの予測の精度が悪いことがある。例えば、以上のようにしてＯＳ１０２ａと１０２ｂの双方が通常モードで動作するせいで、「予測された時間よりも遥かに短い時間のうちに、物理残量値がゼロになってしまう」という事態が生じることがあるからである。

このように、第１比較例では、情報処理装置１００全体として適切に電力が使われないおそれがある。そこで、第１比較例における問題（つまり、意図しない事態や予測精度の低さといった問題）を避けるために、第２比較例を採用することも可能である。しかし、第２比較例は、あまり好ましくない。

なぜなら、第２比較例では、全ＯＳがまったく同じポリシにしたがって電源を管理するので、ＯＳごとの柔軟な電源管理が制約を受けてしまうからである。つまり、ハイパーバイザによる仮想化のメリットの１つは各ＯＳの独立性であるのに、第２比較例ではＯＳに応じた柔軟な管理が阻害されてしまう。

また、全ＯＳに共通のポリシに、どのＯＳの特性も必ず適しているとは限らない。共通のポリシに適さない特性を持ったＯＳが存在する場合もあり得る。そのため、第２比較例では、情報処理装置１００全体として、必ずしも電力が適切には使用されないことがあり得る。

以上のような第１および第２比較例と比べると、第１実施形態には、次の（９ａ）と（９ｂ）のような利点がある。

（９ａ）評価部１０３が適宜のポリシ（例えば（６ａ）〜（６ｃ）のうちのいずれか）にしたがって仮想残量値を評価すれば、情報処理装置１００全体としては適切に電力が使われる。
（９ｂ）ＯＳごとの独立性を犠牲にしなくてよい。換言すれば、ＯＳごとの柔軟な電源管理は制約を受けない。

ところで、上記に例示した（４ａ）〜（４ｃ）のポリシのように、各ＯＳに設定される具体的なポリシは様々である。しかし、多くのポリシは、「電池の残量が多い場合には、電池の残量が少ない場合と比べると、パフォーマンスの向上がより重視される」という点において共通である。換言すれば、多くのポリシは、「電池の残量が少ない場合には、電池の残量が多い場合と比べると、消費電力量の抑制がより重視される」という点において共通である。

したがって、第１実施形態において、ＯＳの優先度が高いほど評価部１０３が仮想残量値を高く評価すれば、以下の（１０ａ）と（１０ｂ）のことが期待される。

（１０ａ）優先度の高いＯＳは、パフォーマンスの向上を重視して動作する。
（１０ｂ）優先度の低いＯＳは、消費電力量の抑制を重視して動作する。

よって、情報処理装置１００全体として、適切にＯＳ間で電力が配分される。また、各ＯＳは、第２比較例のように一律なポリシにしたがって動作するのではなく、当該ＯＳ独自のポリシにしたがって動作するので、柔軟性も保たれる。

また、第１実施形態において、より多くの電力量を消費する高負荷の仮想マシンのＯＳほど、評価部１０３が仮想残量値を高く評価すれば、以下の（１１ａ）と（１１ｂ）のことが期待される。

（１１ａ）負荷の高い（したがって消費電力量が大きい）仮想マシンのＯＳは、パフォーマンスの向上を重視して動作する。
（１１ｂ）負荷の低い（したがって消費電力量が小さい）仮想マシンのＯＳは、消費電力量の抑制を重視して動作する。

よって、仮想マシンの負荷が高いほど、当該仮想マシン上のＯＳに対応する仮想残量値を評価部１０３が高く評価することが好ましい。そのような評価の結果として、高負荷の仮想マシンのＯＳが「電池の残量が十分にあるので、パフォーマンスの向上を重視して構わない」と認識する期間を、例えば第１比較例と比べて長引かせることも可能である。換言すれば、仮想残量値が負荷に対して単調増加する場合、高負荷の仮想マシンのＯＳ上で実行中のプロセスは、消費電力量を抑制するための制約を受けずに（あるいは、そのような制約をあまり受けずに）順調に実行され、ハイパフォーマンスが達成される。

なお、評価部１０３は、上記のように負荷の高さに応じて仮想残量値を評価する場合、負荷の高さを複数のＯＳ間で（換言すれば複数の仮想マシン間で）相対的に評価することが好ましい。

続いて、図２を参照して、第１〜第５実施形態のいずれも適用可能な情報処理装置のハードウェア構成の例を説明する。図１の上記の情報処理装置１００は、具体的には図２の情報処理装置２００により実現されてもよい。同様に、後述の図３の情報処理装置３００も、具体的には図２の情報処理装置２００により実現されてもよい。もちろん、図２の情報処理装置２００とは異なるハードウェア構成の情報処理装置が利用されてもよい。

図２の情報処理装置２００は、電池２０１で駆動される携帯型の装置である。電池２０１は、１次電池でもよいし、充電可能な２次電池でもよい。情報処理装置２００の具体例としては、例えば、ノート型ＰＣ、タブレット端末、ＰＤＡ、スマートフォン、携帯電話、携帯型メディアプレーヤ、その他の各種携帯端末などが挙げられる。

情報処理装置２００は、直接的にバス・インタコネクト（bus interconnect）２０２に接続されたいくつかのハードウェア要素を含む。情報処理装置２００は、適宜のインタフェイス回路（以下「Ｉ／Ｆ」と略す）を介して間接的にバス・インタコネクト２０２に接続されたいくつかのハードウェア要素も含む。

具体的には、電池２０１は電池Ｉ／Ｆ２０３を介してバス・インタコネクト２０２に接続されている。電池Ｉ／Ｆ２０３は、電池２０１の物理残量値を取得するための要求を受け付けて物理残量値を返す。また、電池Ｉ／Ｆ２０３は、電池２０１から他のコンポーネントへの電力供給のオン／オフ制御に関するコマンドを受け付け、コマンドにしたがって電力供給を制御する。なお、図２では、電池２０１から他のコンポーネントへの電力供給路は省略されている。

情報処理装置２００はさらに、バス・インタコネクト２０２に接続されたＣＰＵ２０４とＧＰＵ（Graphics Processing Unit）２０５を有する。図２には１個のＣＰＵ２０４のみが示されているが、情報処理装置２００は２個以上のＣＰＵ２０４を含んでもよい。また、ＣＰＵ２０４はシングルコアＣＰＵでもマルチコアＣＰＵでもよい。

同様に、情報処理装置２００は２個以上のＧＰＵ２０５を含んでいてもよい。また、ＧＰＵ２０５はシングルコアＧＰＵでもマルチコアＧＰＵでもよい。実施形態によっては、独立したＧＰＵ２０５はなくてもよく、代わりに、ＧＰＵ２０５がＣＰＵ２０４内に統合されていてもよい。

また、情報処理装置２００はさらにタッチパネル２０６を有している。タッチパネル２０６は、出力装置（つまりディスプレイ）でもあり、入力装置（つまりポインティングデバイス）でもある。

図２の例では、タッチパネル２０６は、ＬＣＤ（Liquid Crystal Display）Ｉ／Ｆ２０７とタッチパネルＩ／Ｆ２０８を介して、バス・インタコネクト２０２に接続されている。ＬＣＤ Ｉ／Ｆ２０７は、ＣＰＵ２０４またはＧＰＵ２０５からの制御信号にしたがってタッチパネル２０６への出力を制御するためのインタフェイス回路である。タッチパネルＩ／Ｆ２０８は、タッチパネル２０６からの入力をＣＰＵ２０４に通知するためのインタフェイス回路である。

情報処理装置２００はさらにカメラ２０９を有し、カメラ２０９はカメラＩ／Ｆ２１０を介してバス・インタコネクト２０２に接続されている。

情報処理装置２００はさらに、バス・インタコネクト２０２に接続されたメモリ２１１と不揮発性記憶装置２１２を有する。メモリ２１１は、例えばＤＲＡＭ（Dynamic Random Access Memory）でもよい。不揮発性記憶装置２１２は、例えば、フラッシュＳＳＤ（Solid-State Drive）でもよいし、ＨＤＤ（Hard Disk Drive）でもよい。メモリ２１１は、メモリコントローラを介してバス・インタコネクト２０２に接続されていてもよい。また、不揮発性記憶装置２１２は、ディスクコントローラ等の制御回路を内蔵している。

情報処理装置２００はさらにＲＦ（Radio Frequency）回路２１３を有し、ＲＦ回路２１３は無線（radio）Ｉ／Ｆ２１４を介してバス・インタコネクト２０２に接続されている。ＲＦ回路２１３は、例えば、３ＧＰＰ（Third Generation Partnership Project）、ＬＴＥ（Long Term Evolution）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの通信規格にしたがった通信回路であってもよい（ＷｉＭＡＸは登録商標）。ＲＦ回路２１３は、アンテナ、変調器、復調器などの回路を含む。

例えば、ＣＰＵ２０４が生成したデータまたはメモリ２１１に格納されているデータは、無線Ｉ／Ｆ２１４を介してＲＦ回路２１３に出力され、ＲＦ回路２１３から送信されてもよい。ＲＦ回路２１３が電波信号を受信すると、電波信号により表されるディジタルデータが、無線Ｉ／Ｆ２１４とバス・インタコネクト２０２を介して、他のコンポーネント（例えばＣＰＵ２０４またはメモリ２１１）に出力される。

また、バス・インタコネクト２０２には、ＵＳＢ（Universal Serial Bus）コントローラ２１５が接続されている。情報処理装置２００は、不図示のＵＳＢポートを有しており、ＵＳＢポートとＵＳＢコントローラ２１５はＵＳＢ規格のバスで接続されている。したがって、ＵＳＢポートに他のＵＳＢ対応デバイス（例えばメモリカード）が接続されると、ＵＳＢコントローラ２１５を介して情報処理装置２００とＵＳＢ対応デバイスとの間でデータ転送が可能となる。

情報処理装置２００はさらに、バス・インタコネクト２０２に接続されたＷｉＦｉモジュール２１６を有する（「ＷｉＦｉ」は登録商標）。なお、図２にはＷｉＦｉモジュール２１６の１つのブロックのみが図示されているが、ＷｉＦｉモジュール２１６は、ＲＦ回路２１３と無線Ｉ／Ｆ２１４のように、２つのコンポーネントを含んでいてもよい。

例えば、ＣＰＵ２０４が生成したデータまたはメモリ２１１に格納されているデータは、適宜のフレーム形式にて、ＷｉＦｉモジュール２１６から送信されてもよい。そして、ＷｉＦｉモジュール２１６がフレームを受信すると、フレームのデータは、例えばＣＰＵ２０４またはメモリ２１１に出力される。

情報処理装置２００はさらにＮＦＣ（Near Field Communication）用のＲＦ回路２１７を有する。ＲＦ回路２１７は、ＮＦＣ Ｉ／Ｆ２１８を介してバス・インタコネクト２０２に接続されている。ＲＦ回路２１７は、アンテナ、変調器、復調器などの回路を含む。

例えば、ＣＰＵ２０４が生成したデータまたはメモリ２１１に格納されているデータは、ＮＦＣ Ｉ／Ｆ２１８を介してＲＦ回路２１７に出力され、ＲＦ回路２１７から送信されてもよい。また、ＲＦ回路２１７が電波信号を受信すると、電波信号により表されるディジタルデータが、ＮＦＣ Ｉ／Ｆ２１８とバス・インタコネクト２０２を介して、他のコンポーネント（例えばＣＰＵ２０４またはメモリ２１１）に出力される。

実施形態に応じて、図２の情報処理装置２００とは異なるハードウェア構成の情報処理装置が利用されてもよい。例えば、入力装置として、タッチパネル２０６の代わりに（あるいはタッチパネル２０６に加えて）、マウス、キーボード、マイク、またはその組み合わせが使われてもよい。また、出力装置として、タッチパネル２０６の代わりに、タッチセンサ機能のない通常のディスプレイが使われてもよい。出力装置として、さらにスピーカが使われてもよい。

また、カメラ２０９は省略されてもよい。ＵＳＢコントローラ２１５やＵＳＢバスも、省略されてもよい。

情報処理装置２００の種類によっては、ＲＦ回路２１３と無線Ｉ／Ｆ２１４が省略されてもよい。あるいは、ＷｉＦｉモジュール２１６が省略されてもよい。あるいは、ＲＦ回路２１７とＮＦＣ Ｉ／Ｆ２１８が省略されてもよい。逆に、情報処理装置２００が、バス・インタコネクト２０２に接続された有線ＬＡＮ（Local Area Network）モジュールをさらに備えていてもよい。

なお、図１の情報処理装置１００は、具体的には図２の情報処理装置２００であってもよい。その場合、以下の（１２ａ）〜（１２ｆ）のような種々のプログラムは、不揮発性記憶装置２１２に予め格納されており、メモリ２１１にロードされ、ＣＰＵ２０４により実行される。ＣＰＵ２０４は、メモリ２１１をワーキングエリアとしても利用する。

（１２ａ）アプリケーションプログラム。
（１２ｂ）ＯＳ１０２ａのプログラム。
（１２ｃ）ＯＳ１０２ｂのプログラム。
（１２ｄ）デバイスドライバのプログラム。
（１２ｅ）ハイパーバイザのプログラム（例えばファームウェアプログラムであってもよい）。
（１２ｆ）図１の評価部１０３、通知部１０４、第１の取得部１０５、および第２の取得部１０６としてＣＰＵ２０４を機能（serve）させるための所定のプログラム。

なお、（１２ｆ）の「所定のプログラム」は、例えば、（１２ｄ）のデバイスドライバのプログラムの一部であってもよいし、（１２ｅ）のハイパーバイザのプログラムの一部であってもよい。

ＣＰＵ２０４は、（１２ｆ）の所定のプログラムをメモリ２１１にロードして（１２ｆ）の所定のプログラムを実行する。ＣＰＵ２０４は、（１２ｆ）の所定のプログラムを実行することにより、評価部１０３、通知部１０４、第１の取得部１０５、および第２の取得部１０６として機能する。

なお、（１２ｆ）の所定のプログラムは、情報処理装置２００にプレインストールされていてもよく、ネットワークからダウンロードされてもよく、記憶媒体からコピーされてもよい。ダウンロードは、具体的には、ＲＦ回路２１３と無線Ｉ／Ｆ２１４を介して行われてもよいし、あるいは、ＷｉＦｉモジュール２１６を介して行われてもよい。記憶媒体は、例えばＵＳＢメモリスティックであってもよい。

実施形態によっては、情報処理装置２００が光ディスクドライブを有していてもよい。その場合、上記所定のプログラムを記憶する記憶媒体は、光ディスクであってもよい。光ディスクの例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などである。

もちろん、磁気ディスクや光磁気ディスクなどの、その他の種類の記憶媒体が使われてもよい。記憶媒体の種類に応じて、情報処理装置２００が適宜のドライブ装置を備えていてもよいし、情報処理装置２００がＵＳＢポートを介して適宜のドライブ装置と接続されてもよい。

なお、以上の図２の説明において、メモリ２１１、不揮発性記憶装置２１２、各種記憶媒体について述べたが、これらはすべて、コンピュータ読み取り可能な有形の（tangible）媒体である。これらの有形の媒体は、信号搬送波のような一時的な（transitory）媒体ではない。

ところで、第１の取得部１０５が取得する特性情報が、優先度情報などの静的な情報を含む場合、静的な特性情報は、図２の不揮発性記憶装置２１２に予め格納されていてもよい。そして、第１の取得部１０５として機能するＣＰＵ２０４が、不揮発性記憶装置２１２から静的な特性情報を取得してもよい。あるいは、第１の取得部１０５として機能するＣＰＵ２０４は、ＯＳ１０２ａと１０２ｂの動作を監視することにより、動的な特性情報を生成し、生成によって特性情報を取得してもよい。

第２の取得部１０６として機能するＣＰＵ２０４は、具体的には、電池２０１の物理残量値を取得するための要求を、バス・インタコネクト２０２を介して電池Ｉ／Ｆ２０３に送ってもよい。すると、ＣＰＵ２０４は、電池Ｉ／Ｆ２０３を介して物理残量値を取得する。

続いて、図３〜９を参照して、第２実施形態について説明する。
図３は、第２実施形態の情報処理装置のブロック構成図である。以下に述べるとおり、図３の情報処理装置３００は仮想化されている。

情報処理装置３００は、様々な種類のハードウェア３１０を有する。ハードウェア３１０の１つは電池３１１である。また、情報処理装置３００は図２の情報処理装置２００により実現されてもよい。つまり、ハードウェア３１０が、ＣＰＵ２０４、ＧＰＵ２０５、タッチパネル２０６、カメラ２０９、メモリ２１１、不揮発性記憶装置２１２、ＲＦ回路２１３、ＵＳＢコントローラ２１５、ＷｉＦｉモジュール２１６、およびＲＦ回路２１７などを含んでいてもよい。

ハードウェア３１０上ではハイパーバイザ３２０が動作する。ハイパーバイザ３２０は「仮想マシンモニタ」とも呼ばれる。

ハイパーバイザ３２０上では、複数の種類のハードウェア３１０にそれぞれ対応する仮想ドライバ（virtual drivers）３３０が動作する。仮想ドライバ３３０のうちの１つは、電池３１１に対応する仮想電池ドライバ３４０である。

また、情報処理装置３００には複数の仮想マシンが構築されている。ハイパーバイザ３２０上で動作する仮想マシンは、「ドメイン」、「論理ドメイン」、「パーティション」などとも呼ばれる。図３の例では、２つの仮想マシン３５０ａと３５０ｂがハイパーバイザ３２０上で動作する。

仮想マシン３５０ａ内ではＯＳ３５１ａが動作し、ＯＳ３５１ａ上で１つ以上のアプリケーション３５２ａが動作する。同様に、仮想マシン３５０ｂ内では、ＯＳ３５１ｂが動作し、ＯＳ３５１ｂ上で１つ以上のアプリケーション３５２ｂが動作する。

情報処理装置３００が情報処理装置２００により実現される場合、以下の（１３ａ）〜（１３ｄ）の各種のプログラムが図２のＣＰＵ２０４により実行される。

（１３ａ）ハイパーバイザ３２０のプログラム（上記（１２ｅ）のプログラムに対応する）。
（１３ｂ）仮想電池ドライバ３４０を含む仮想ドライバ３３０それぞれのプログラム（上記（１２ｆ）のプログラムを含む（１２ｄ）のプログラム、およびその他の（１２ｄ）のプログラムに対応する）。
（１３ｃ）ＯＳ３５１ａと３５１ｂのプログラム（上記（１２ｂ）と（１２ｃ）のプログラムに対応する）。
（１３ｄ）アプリケーション３５２ａと３５２ｂのプログラム（上記（１２ａ）のプログラムに対応する）。

上記（１３ａ）〜（１３ｄ）のプログラムは、不揮発性記憶装置２１２に予め格納されていてもよい。あるいは、上記（１３ａ）〜（１３ｄ）のプログラムは、ＲＦ回路２１３と無線Ｉ／Ｆ２１４を介してネットワークからダウンロードされてもよいし、ＷｉＦｉモジュール２１６を介してネットワークからダウンロードされてもよい。上記（１３ａ）〜（１３ｄ）のプログラムは、コンピュータ読み取り可能な記憶媒体から読み取られて、不揮発性記憶装置２１２にコピーされてもよい。いずれにしろ、上記（１３ａ）〜（１３ｄ）のプログラムは、メモリ２１１にロードされて、ＣＰＵ２０４により実行される。

仮想電池ドライバ３４０は、プロファイラ３４１ａと３４１ｂを含む。プロファイラ３４１ａは、ＯＳ３５１ａに対応する（換言すれば、仮想マシン３５０ａに対応する）。プロファイラ３４１ｂは、ＯＳ３５１ｂに対応する（換言すれば、仮想マシン３５０ｂに対応する）。仮想電池ドライバ３４０はさらに、取得部３４２と計算部３４３も含む。

プロファイラ３４１ａと３４１ｂは、図１の第１の取得部１０５と類似しており、特性情報の一部（より具体的には使用状況情報）を取得する。また、プロファイラ３４１ａと３４１ｂは、図１の通知部１０４とも類似している。つまり、プロファイラ３４１ａと３４１ｂは、ＯＳ３５１ａと３５１ｂにそれぞれ仮想残量値を通知する。

取得部３４２は、図１の第２の取得部１０６と類似しており、電池３１１の物理残量値を取得する。計算部３４３は、評価部１０３と類似している。具体的には、計算部３４３は、特性情報と物理残量値から仮想残量値を計算し、計算した仮想残量値をプロファイラ３４１ａと３４１ｂに出力する。

仮想電池ドライバ３４０内の上記のコンポーネントのさらなる詳細は、図６〜７のフローチャートとともに後述する。

図３には、計算部３４３が仮想残量値の計算に用いる様々な情報も図示されている。具体的には、使用状況情報３４４、優先度情報３４５、モード情報３４６、およびフラグ３４７が、図３に示されている。これら各種の情報の詳細は、図４、６、および７とともに後述する。

続いて、図４を参照して、図３の使用状況情報３４４、優先度情報３４５、およびモード情報３４６の具体例について説明する。図４は、第２実施形態で使われるプロファイルの例を示す図である。

図４のプロファイル４０１ａは、ＯＳ３５１ａに対応する使用状況情報３４４、優先度情報３４５、およびモード情報３４６を含む。同様に、プロファイル４０１ｂは、ＯＳ３５１ｂに対応する使用状況情報３４４、優先度情報３４５、およびモード情報３４６を含む。プロファイル４０１ａと４０１ｂは、物理的なメモリ２１１上の、仮想電池ドライバ３４０が使用する領域内に、格納されている。

プロファイル４０１ａ中の優先度情報３４５によれば、ＯＳ３５１ａの優先度は「５」である。プロファイル４０１ａ中のモード情報３４６によれば、ＯＳ３５１ａのモードは「第３モード」である。

他方、プロファイル４０１ｂ中の優先度情報３４５によれば、ＯＳ３５１ｂの優先度は「２」である。プロファイル４０１ｂ中のモード情報３４６によれば、ＯＳ３５１ｂのモードは「第１モード」である。

モードの詳細は図６〜７とともに後述するが、モード情報３４６により表されるモードは、電池３１１が充電中の場合に計算部３４３が仮想残量値を評価する方法を示す。第２実施形態では、「第１モード」から「第３モード」までの３種類のモードが定義されているものとする。

優先度情報３４５とモード情報３４６は、予め決められた静的な情報である。例えば、優先度情報３４５とモード情報３４６は、ユーザからの入力に応じて設定されてもよい。例えば、優先度情報３４５とモード情報３４６は、不揮発性記憶装置２１２に予め格納されていてもよく、仮想電池ドライバ３４０により不揮発性記憶装置２１２から読み出されてメモリ２１１上にロードされてもよい。

プロファイル４０１ａ中の使用状況情報３４４は、具体的には、Ｔ個の期間（Ｔ≧１）のそれぞれにおいて、ＯＳ３５１ａおよびアプリケーション３５２ａの動作に起因して使用された物理資源の量を、物理資源ごとに示す。同様に、プロファイル４０１ｂ中の使用状況情報３４４は、Ｔ個の期間のそれぞれにおいて、ＯＳ３５１ｂおよびアプリケーション３５２ｂの動作に起因して使用された物理資源の量を、物理資源ごとに示す。図示の便宜上、図４において使用状況情報３４４はテーブル形式で示されている。

使用状況情報３４４のテーブルの各行は、１つの期間に対応する。期間の長さは予め決められた定数である。

使用状況情報３４４のテーブルの各列は、１つの物理資源（具体的には物理デバイス）についての１つの観測項目に対応する。図４は、「ＣＰＵ２０４（またはＣＰＵ２０４内のコア）については、使用率と周波数という２つの項目が観測されるが、ＧＰＵ２０５やＷｉＦｉモジュール２１６については１つの項目しか観測されない」という場合の使用状況情報３４４の例を示す。

紙幅の都合上、図４では一部の物理デバイスに対応する使用状況情報３４４のみが例示されており、他の物理デバイスに対応する使用状況情報３４４は省略されている。プロファイル４０１ｂ中の使用状況情報３４４も、プロファイル４０１ａ中の使用状況情報３４４と同様に、テーブル形式で図示されている。

なお、物理デバイスと仮想デバイスの間の対応関係は、実施形態に応じて様々である。対応関係に応じて、使用状況情報３４４のテーブルの列の数は異なり得る。

例えば、図２に関して説明したように、物理ＣＰＵは１台でも複数台でもよく、各物理ＣＰＵは、シングルコアＣＰＵでもマルチコアＣＰＵでもよい。また、各仮想マシンの仮想ＣＰＵの数も任意である。ハイパーバイザ３２０は、各仮想マシンに対して、シングルコアの仮想ＣＰＵを提供してもよいし、マルチコアの仮想ＣＰＵを提供してもよい。

よって、物理ＣＰＵと仮想ＣＰＵの間の対応関係は、実施形態に応じて様々である。具体例をいくつか挙げると、例えば以下の（１４ａ）〜（１４ｆ）のような場合があり得る。もちろん、さらに別の場合もあり得る。なお、下記（１４ｅ）の場合は、（１４ａ）の場合のより具体的な例である、とも見なせる。

（１４ａ）シングルコアまたはマルチコアの物理ＣＰＵが１台ある。当該物理ＣＰＵは、仮想マシン３５０ａの仮想ＣＰＵに割り当てられるとともに、仮想マシン３５０ｂの仮想ＣＰＵにも割り当てられる。つまり、仮想マシン３５０ａと３５０ｂは同じ物理ＣＰＵを共有する。
（１４ｂ）シングルコアまたはマルチコアの物理ＣＰＵが２台ある。第１物理ＣＰＵは、仮想マシン３５０ａの仮想ＣＰＵに割り当てられる。第２物理ＣＰＵは、仮想マシン３５０ｂの仮想ＣＰＵに割り当てられる。
（１４ｃ）シングルコアまたはマルチコアの物理ＣＰＵが３台ある。第１物理ＣＰＵと第２物理ＣＰＵは、仮想マシン３５０ａの仮想ＣＰＵに割り当てられる。ハイパーバイザ３２０は、シングルコアのＣＰＵが１台だけが存在するかのように仮想マシン３５０ａに認識させてもよいし、デュアルコアの（dual-core）ＣＰＵが１台だけ存在するかのように仮想マシン３５０ａに認識させてもよい。後者の場合、例えば第１物理ＣＰＵが仮想ＣＰＵの第１コアに割り当てられ、第２物理ＣＰＵが仮想ＣＰＵの第２コアに割り当てられてもよい。また、第３物理ＣＰＵは、仮想マシン３５０ｂの仮想ＣＰＵに割り当てられる。
（１４ｄ）デュアルコアの物理ＣＰＵが１台ある。当該物理ＣＰＵの第１コアは、仮想マシン３５０ａの仮想ＣＰＵに割り当てられ、仮想マシン３５０ａからは１台のＣＰＵとして認識される。当該物理ＣＰＵの第２コアは、仮想マシン３５０ｂの仮想ＣＰＵに割り当てられ、仮想マシン３５０ｂからは１台のＣＰＵとして認識される。
（１４ｅ）デュアルコアの物理ＣＰＵが１台ある。当該物理ＣＰＵの第１コアは、仮想マシン３５０ａの仮想ＣＰＵの第１コアに割り当てられるとともに、仮想マシン３５０ｂの仮想ＣＰＵの第１コアにも割り当てられる。また、当該物理ＣＰＵの第２コアは、仮想マシン３５０ａの仮想ＣＰＵの第２コアに割り当てられるとともに、仮想マシン３５０ｂの仮想ＣＰＵの第２コアにも割り当てられる。
（１４ｆ）クアッドコアの（quad-core）物理ＣＰＵが１台ある。当該物理ＣＰＵの第１コアと第２コアは、仮想マシン３５０ａの仮想ＣＰＵの第１コアと第２コアにそれぞれ割り当てられる。つまり、仮想マシン３５０ａからは、デュアルコアの１台のＣＰＵが存在するかのよう認識される。また、当該物理ＣＰＵの第３コアと第４コアは、仮想マシン３５０ｂの仮想ＣＰＵの第１コアと第２コアにそれぞれ割り当てられる。つまり、仮想マシン３５０ｂからは、デュアルコアの１台のＣＰＵが存在するかのよう認識される。

以上のように、物理デバイスと仮想デバイスの間の対応関係は、実施形態に応じて様々であり、対応関係に応じて、使用状況情報３４４のテーブルの列の数は異なり得る。例えば、上記（１４ａ）〜（１４ｆ）の場合、使用状況情報３４４のテーブルにおける、ＣＰＵ（またはＣＰＵコア）に関する列の数は、以下のとおりである。

上記（１４ａ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、１台の物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。同様に、プロファイル４０１ｂの使用状況情報３４４のテーブルにも、１台の物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。

上記（１４ｂ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、第１物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。他方、プロファイル４０１ｂの使用状況情報３４４のテーブルには、第２物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。

上記（１４ｃ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、第１物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列と、第２物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。他方、プロファイル４０１ｂの使用状況情報３４４のテーブルには、第３物理ＣＰＵの使用率と周波数にそれぞれ対応する２つの列がある。

上記（１４ｄ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、物理ＣＰＵの第１コアの使用率と周波数にそれぞれ対応する２つの列がある。他方、プロファイル４０１ｂの使用状況情報３４４のテーブルには、物理ＣＰＵの第２コアの使用率と周波数にそれぞれ対応する２つの列がある。

上記（１４ｅ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、物理ＣＰＵの第１コアの使用率と周波数にそれぞれ対応する２つの列と、物理ＣＰＵの第２コアの使用率と周波数にそれぞれ対応する２つの列がある。同様に、プロファイル４０１ｂの３４４のテーブルにも、物理ＣＰＵの第１コアの使用率と周波数にそれぞれ対応する２つの列と、物理ＣＰＵの第２コアの使用率と周波数にそれぞれ対応する２つの列がある。

上記（１４ｆ）の場合、プロファイル４０１ａの使用状況情報３４４のテーブルには、物理ＣＰＵの第１コアの使用率と周波数にそれぞれ対応する２つの列と、物理ＣＰＵの第２コアの使用率と周波数にそれぞれ対応する２つの列がある。他方、プロファイル４０１ｂの使用状況情報３４４のテーブルには、物理ＣＰＵの第３コアの使用率と周波数にそれぞれ対応する２つの列と、物理ＣＰＵの第４コアの使用率と周波数にそれぞれ対応する２つの列がある。

したがって、例えば（１４ａ）、（１４ｂ）または（１４ｄ）の場合には、図４に示すように、プロファイル４０１ａと４０１ｂのどちらの使用状況情報３４４のテーブルにも、ＣＰＵ（またはＣＰＵコア）に関して、使用率と周波数の列が１つずつある。

例えば、プロファイル４０１ａ中の使用状況情報３４４は、以下の（１５ａ）〜（１５ｄ）のことを示す。

（１５ａ）ＯＳ３５１ａおよびアプリケーション３５２ａによるＣＰＵ使用率は、直近の期間においては５０％であり、直近から２番目の期間においては２０％であり、直近からＴ番目の期間においては６０％である。なお、ここでの「ＣＰＵ使用率」は、仮想マシン３５０ａの仮想ＣＰＵに割り当てられている物理ＣＰＵ（または物理ＣＰＵコア）の使用率である。
（１５ｂ）仮想マシン３５０ａの仮想ＣＰＵに割り当てられている物理ＣＰＵ（または物理ＣＰＵコア）のクロック周波数は、直近の期間においては５００ＭＨｚであり、直近から２番目の期間と直近からＴ番目の期間においては１ＧＨｚである。
（１５ｃ）ＯＳ３５１ａとアプリケーション３５２ａの少なくとも一方が、仮想マシン３５０ａの仮想ＧＰＵを、直近の期間と直近からＴ番目の期間において使用した。つまり、仮想マシン３５０ａの仮想ＧＰＵに割り当てられている物理ＧＰＵ（具体的にはＧＰＵ２０５）は、ＯＳ３５１ａまたはアプリケーション３５２ａの動作に起因して、直近の期間と、直近からＴ番目の期間において使用された。しかし、直近から２番目の期間においては、ＯＳ３５１ａまたはアプリケーション３５２ａの動作に起因して上記物理ＧＰＵが使用されることはなかった。
（１５ｄ）ＯＳ３５１ａとアプリケーション３５２ａが直近の期間において、仮想ＷｉＦｉデバイスを介して受信したデータの量と仮想ＷｉＦｉデバイスを介して送信したデータの量の総和は１０ｋＢである。つまり、仮想マシン３５０ａの仮想ＷｉＦｉデバイスに割り当てられた物理ＷｉＦｉデバイス（具体的にはＷｉＦｉモジュール２１６）を介して、ＯＳ３５１ａまたはアプリケーション３５２ａに関して行われた通信のデータ量は、直近の期間では１０ｋＢである。また、当該データ量は、直近から２番目の期間においては２５ｋＢであり、直近からＴ番目の期間においては３５ｋＢである。

なお、ＯＳ３５１ａは、仮想マシン３５０ａの仮想ＣＰＵに割り当てられている物理ＣＰＵ（または物理ＣＰＵコア）のクロック周波数を変更するためのハイパーバイザコールを発行してもよい。ただし、実際に物理ＣＰＵ（または物理ＣＰＵコア）のクロック周波数を変更するか否かは、ハイパーバイザ３２０が決定する。例えば、１つの物理ＣＰＵ（または１つの物理ＣＰＵコア）が複数の仮想マシンにより共有されている場合、ハイパーバイザ３２０は、クロック周波数を変更しないことに決定してもよい。

ハイパーバイザ３２０は、クロック周波数を変更することに決定した場合、決定にしたがって、物理ＣＰＵ（または物理ＣＰＵコア）に対して、クロック周波数を変更するための命令を発行する。本実施形態では、以上のようにクロック周波数が可変であるため、上記（１５ｂ）のようにクロック周波数が使用状況情報３４４として記録される。

また、図４では、物理ＧＰＵが期間中に使用されたことを「ＯＮ」と表し、物理ＧＰＵが期間中に使用されなかったことを「ＯＦＦ」と表している。

なお、プロファイル４０１ｂ中の使用状況情報３４４は、プロファイル４０１ａ中の使用状況情報３４４と同様の形式なので、詳しい説明を省略する。

さて、以上説明したようなプロファイル４０１ａ中の使用状況情報３４４は、プロファイラ３４１ａにより生成され、記録される。例えば、プロファイラ３４１ａは、ＯＳ３５１ａの動作を監視することにより、プロファイル４０１ａ中の使用状況情報３４４を生成してもよい。そして、プロファイラ３４１ａは、生成した使用状況情報３４４を例えばメモリ２１１に格納してもよい。以上のように、プロファイラ３４１ａは監視と生成により、使用状況情報３４４を取得してもよい。

同様に、プロファイラ３４１ｂはＯＳ３５１ｂの動作を監視することにより、プロファイル４０１ｂ中の使用状況情報３４４を生成してもよい。そして、プロファイラ３４１ｂは、生成した使用状況情報３４４を例えばメモリ２１１に格納してもよい。

より具体的には、プロファイラ３４１ａは、例えば、ハイパーバイザ３２０への問い合わせを介して、仮想マシン３５０ａの動作に起因する物理ＣＰＵ使用率を取得してもよい。つまり、プロファイラ３４１ａは、物理ＣＰＵ時間のうち、ＯＳ３５１ａとアプリケーション３５２ａにより消費された時間の割合を、ハイパーバイザ３２０への問い合わせを介して、物理ＣＰＵごとに（あるいは物理ＣＰＵコアごとに）取得してもよい。

ところで、アプリケーション３５２ａがデバイスを利用する場合、アプリケーション３５２ａはシステムコールを呼び出してもよい。そして、システムコールに応じて、ＯＳ３５１ａが、アプリケーション３５２ａの利用しようとするデバイスに対応する仮想ドライバ３３０に対して、命令を発行してもよい。仮想ドライバ３３０は、ＯＳ３５１ａからの命令に応じて、ハイパーバイザコールを呼び出すことで、物理デバイスにアクセスしてもよい。

つまり、アプリケーション３５２ａがＯＳ３５１ａを介してデバイスを利用する場合に、ＯＳ３５１ａからの命令に応じて仮想ドライバ３３０がハイパーバイザコールを呼び出すことがある。もちろん、ＯＳ３５１ａがアプリケーション３５２ａとは無関係にデバイスを利用する場合に、ＯＳ３５１ａからの命令に応じて仮想ドライバ３３０がハイパーバイザコールを呼び出すこともあり得る。したがって、プロファイラ３４１ａは、ＯＳ３５１ａからの命令に応じて仮想ドライバ３３０から呼び出されたハイパーバイザコールを集計する（aggregate）ことで、上記のような物理デバイスごとの使用状況情報３４４を生成してもよい。

実施形態に応じてハイパーバイザコールの具体的な形式は異なり得るが、プロファイラ３４１ａは、ハイパーバイザコールの形式に応じて、適宜、プロファイル４０１ａ中の使用状況情報３４４を生成する。例えば、プロファイラ３４１ａは、ハイパーバイザコールの種類ごと、ハイパーバイザコールの引数の値ごと、あるいは、種類と引数の値の組み合わせごとに、ハイパーバイザコールの回数をカウントしてもよい。

また、或る種のハイパーバイザコールが数値的な引数をとる場合、プロファイラ３４１ａは、当該或る種のハイパーバイザコールに関して、引数の和を計算してもよい。プロファイラ３４１ａは、このような計算によって、数値的な使用状況情報３４４を取得してもよい。例えば、上記（１５ｄ）のデータ量は、数値的な使用状況情報３４４の例である。

あるいは、ハイパーバイザ３２０のアーキテクチャによっては、特定の仮想マシンのデバイスドライバが、ハードウェア３１０へのアクセスを提供してもよい。図３では便宜上、仮想ドライバ３３０が仮想マシン３５０ａと３５０ｂの外側に描かれているが、例えば仮想マシン３５０ａが上記「特定の仮想マシン」である場合、仮想マシン３５０ａのデバイスドライバが、ハードウェア３１０へのアクセスを提供してもよい。

この場合、仮想マシン３５０ａ内には、他の仮想マシン３５０ｂ内のデバイスドライバ（すなわちフロントエンドドライバ）との間のインタフェイスとして機能するバックエンドドライバと、実際にハードウェア３１０にアクセスする実ドライバがあってもよい。仮想マシン３５０ｂ内のフロントエンドドライバは、ハイパーバイザ３２０を介して仮想マシン３５０ａ内のバックエンドドライバに対してアクセス要求を発行するためのインタフェイスである。

例えば、或る種の物理デバイスに関して、プロファイラ３４１ｂは、仮想マシン３５０ｂ内のフロントエンドドライバから仮想マシン３５０ａ内のバックエンドドライバへの要求を監視してもよい。そして、プロファイラ３４１ｂは、要求の回数をカウントすることにより（または、要求の種類もしくは引数に応じて適宜の集計処理を行うことにより）、仮想マシン３５０ｂに対応する使用状況情報３４４を取得してもよい。

プロファイラ３４１ａは、仮想マシン３５０ａ内のＯＳ３５１ａまたはアプリケーション３５２ａの動作に起因するハードウェア３１０へのアクセスを監視してもよい。具体的には、プロファイラ３４１ａは、仮想マシン３５０ｂ内のフロントエンドドライバからの要求とは関係なく実ドライバが行うハードウェア３１０へのアクセスを監視してもよい。そして、プロファイラ３４１ａは、アクセスの回数をカウントすることにより（または、アクセスの種類もしくは引数に応じて適宜の集計処理を行うことにより）、仮想マシン３５０ａに対応する使用状況情報３４４を取得してもよい。

なお、仮想電池ドライバ３４０は、電池３１１に関するバックエンドドライバと実ドライバの組み合わせにより実現されていてもよい。例えば、物理残量値を取得する取得部３４２は、実ドライバ内にあってもよい。プロファイラ３４１ａと３４１ｂは、バックエンドドライバ内にあってもよい。図３ではプロファイラ３４１ｂとＯＳ３５１ｂが線でつながれているが、電池３１１に対応するバックエンドドライバ内にプロファイラ３４１ｂがある場合、プロファイラ３４１ｂは、仮想マシン３５０ｂ内で電池３１１に対応するフロントエンドドライバを介して、ＯＳ３５１ｂに仮想残量値を通知してもよい。

実施形態によっては、ハイパーバイザ３２０が、問い合わせに応じて、物理デバイスとＯＳの組み合わせごとに（または物理デバイスと仮想マシンの組み合わせごとに）、使用状況情報３４４を応答する機能を提供していてもよい。その場合、プロファイラ３４１ａは、ハイパーバイザ３２０への問い合わせを介して、プロファイル４０１ａ内の使用状況情報３４４を取得してもよい。同様に、プロファイラ３４１ｂも、ハイパーバイザ３２０への問い合わせを介して、プロファイル４０１ｂ内の使用状況情報３４４を取得してもよい。

なお、図４の例から理解されるとおり、使用状況情報３４４がどのような形式で表されるかは、物理デバイスごとに異なり得る。

例えば、ＣＰＵ２０４（またはＣＰＵ２０４のコア）の使用状況情報３４４は、パーセンテージと周波数で表される。実施形態によっては、ＧＰＵ２０５（またはＧＰＵ２０５のコア）の使用状況情報３４４も、パーセンテージと周波数で表されてもよい。しかし、図４の例では、ＧＰＵ２０５の使用状況情報３４４は、２値的に「ＯＮ」と「ＯＦＦ」で表される。また、ＷｉＦｉモジュール２１６の使用状況情報３４４は、データ量（図４の例ではキロバイト単位の量）により数値的に表される。

タッチパネル２０６からの入力に関する使用状況情報３４４も、２値的に表されてもよい。例えば、ＯＳ３５１ａまたはアプリケーション３５２ａに対応する表示領域内に、期間中にユーザが１回でも触った場合は、プロファイル４０１ａにおいて、タッチパネル２０６からの入力に関する使用状況情報３４４の値は、「ＯＮ」である。逆に、期間中にユーザが上記表示エリア内に触らなかった場合、使用状況情報３４４の値は、「ＯＦＦ」である。

実施形態によっては、タッチパネル２０６からの入力に関する使用状況情報３４４が、数値的に表されてもよい。例えば、タッチパネル２０６からタッチパネルＩ／Ｆ２０８を介してバス・インタコネクト２０２に出力されたデータの量が、数値的な使用状況情報３４４として利用可能である。プロファイラ３４１ａは、当該データ量を、タッチパネル２０６からの入力に対応する仮想ドライバ３３０がＯＳ３５１ａに対して発行する割り込みの回数、または、そのような割り込みの引数に基づいて、計算してもよい。

また、タッチパネル２０６への出力に関する使用状況情報３４４も、数値的に表されてもよい。具体的には、期間中にＶＲＡＭ（Video Random Access Memory）へ出力されたデータ量により、タッチパネル２０６への出力に関する使用状況情報３４４が表されてもよい。例えば、プロファイラ３４１ａは、当該データ量を、タッチパネル２０６への出力に対応する仮想ドライバ３３０がＯＳ３５１ａからの命令に応じて発行するハイパーバイザコールの引数に基づいて、計算してもよい。

ＵＳＢコントローラ２１５に関する使用状況情報３４４も同様に、２値的に表されてもよいし、数値的に表されてもよい。つまり、使用状況情報３４４は、ＵＳＢコントローラ２１５を介してＵＳＢデバイスが使用されたか否かを示してもよいし、ＵＳＢコントローラ２１５を介して転送されたデータの量を示してもよい。

カメラ２０９に関する使用状況情報３４４は、例えば、カメラ２０９により撮像された画像のデータ量により、数値的に表されてもよい。情報処理装置２００がスピーカを有する場合、スピーカに関する使用状況情報３４４は、スピーカに出力されたオーディオデータの量により、数値的に表されてもよい。実施形態によっては、カメラ２０９やスピーカに関する使用状況情報３４４が２値的に表されてもよい。

ＲＦ回路２１３の使用状況情報３４４も、ＷｉＦｉモジュール２１６の使用状況情報３４４と同様に、ＲＦ回路２１３によって通信されたデータの量により、数値的に表されてもよい。同様に、ＲＦ回路２１７の使用状況情報３４４も、数値的に表されてもよい。

なお、デバイスの種類によっては、使用状況情報３４４が、数値的でも２値的でもなく、ｎ値的（n-ary）に表されてもよい（ｎ＞２）。

以上のとおり、使用状況情報３４４の形式は様々である。しかし、使用状況情報３４４の形式によらず、プロファイラ３４１ａは、物理デバイスの種類に応じた適宜の監視または問い合わせにより、プロファイル４０１ａの使用状況情報３４４を取得することができる。同様に、プロファイラ３４１ｂも、使用状況情報３４４の形式によらず、プロファイル４０１ｂの使用状況情報３４４を取得することができる。

例えば、上記のように物理ＣＰＵ（または物理ＣＰＵコア）のクロック周波数が実際に変更されるか否かは、ハイパーバイザ３２０が決定する。よって、クロック周波数の変更を要求するハイパーバイザコールをＯＳ３５１ａが発行したら、プロファイラ３４１ａは、ハイパーバイザ３２０に実際のクロック周波数を問い合わせてもよい。

ところで、ＯＳ３５１ａと３５１ｂは、互いに独立に、電源管理に関する各々のポリシにしたがって動作する。第２実施形態では、電源管理に関するポリシは、具体的には、複数のルールを含むルールセットにより表される。図５は、第２実施形態で使われるルールセットの例を示す図である。

図５の例では、ＯＳ３５１ａには２つのルールセット５００と５２０が予め定義されており、ＯＳ３５１ｂには１つのルールセット５４０が予め定義されている。複数のルールセットが定義されているＯＳでは、それら複数のルールセットのうち１つが選択可能である。例えば、ユーザからの入力に応じて、ＯＳ３５１ａではルールセット５００が選択されていてもよい。

各ルールセットは複数のルールを含む。各ルールは、ＯＳが認識する電池３１１の残量値（すなわち仮想残量値）に関する条件と対応づけられている。条件とルールの間の対応づけは、「当該条件が成立する場合に、ＯＳが当該ルールを適用する」ということを表す。

例えば、ルールセット５００では３つの条件５０１〜５０３が定義されており、ルールセット５００は７つのルール５０４〜５１０を含む。ルール５０４〜５１０の各々は、条件５０１〜５０３のいずれかに対応づけられている。以下では説明の便宜上、電池の残量は、Ｗｈ単位で表される（すなわち、使用可能な残りの電力量により表される）ものとする。

条件５０１は、「電池３１１の残量としてＯＳ３５１ａが認識する値（すなわちＯＳ３５１ａに通知された仮想残量値）が、２０Ｗｈ以上である」という条件である。条件５０２は、「電池３１１の残量としてＯＳ３５１ａが認識する値が、５Ｗｈ以上２０Ｗｈ未満である」という条件である。条件５０３は、「電池３１１の残量としてＯＳ３５１ａが認識する値が、５Ｗｈ未満である」という条件である。

ところで、以下では説明の便宜上、ハイパーバイザ３２０による仮想化の結果としてＯＳ３５１ａが認識するＣＰＵ（つまり仮想ＣＰＵ）のコアの数が２であるものとする。同様に、ＯＳ３５１ｂが認識するＣＰＵのコアの数も２であるものとする。例えば、上記（１４ｅ）と（１４ｆ）の場合は、いずれも、ＯＳ３５１ａが認識する仮想ＣＰＵのコアの数が２であり、かつ、ＯＳ３５１ｂが認識する仮想ＣＰＵのコアの数も２である。

さて、ルールセット５００において、ルール５０４は、条件５０１に対応づけられている。ルール５０４は、「ＯＳ３５１ａが認識する２つの仮想ＣＰＵコアのうち、第１コアを１ＧＨｚで動作させる」というルールである。

ルール５０５も条件５０１に対応づけられている。ルール５０５は、「ＯＳ３５１ａが認識する２つの仮想ＣＰＵコアのうち、第２コアを５００ＭＨｚで動作させる」というルールである。

ＯＳ３５１ａに２０Ｗｈ以上の仮想残量値が通知された場合、ＯＳ３５１ａは、ルール５０４と５０５を適用する。具体的には、ＯＳ３５１ａは、仮想ＣＰＵの第１コアを１ＧＨｚで動作させるための命令を発行し、仮想ＣＰＵの第２コアを５００ＭＨｚで動作させるための命令を発行する。これらの命令は、具体的にはハイパーバイザコールであってもよい。

ハイパーバイザ３２０は、ＯＳ３５１ａからのハイパーバイザコールにしたがって、物理ＣＰＵコアのクロック周波数を変更してもよいし、変更しなくてもよい。例えば、ハイパーバイザ３２０は、ＯＳ３５１ａからのハイパーバイザコールにしたがって、物理ＣＰＵ時間のＯＳ３５１ａへの割り当てを調整してもよく、物理ＣＰＵコアのクロック周波数自体は変更しなくてもよい。

さて、ルール５０６〜５０９は、いずれも条件５０２に対応づけられている。よって、ＯＳ３５１ａに５Ｗｈ以上２０Ｗｈ未満の仮想残量値が通知された場合、ＯＳ３５１ａは、ルール５０６〜５０９を適用する。

ルール５０６は、「第１コアを５００ＭＨｚで動作させる」というルールである。ルール５０７は、「第２コアを１００ＭＨｚで動作させる」というルールである。ルール５０８は、「ＷｉＦｉモジュールを介した通信のデータレートを１ｋＢ／ｈまでに制限する」というルールである。ルール５０９は、「画面に警告を表示する」というルールである。

また、条件５０３にはルール５１０が対応づけられている。ルール５１０は、「強制的にスリープする」というルールである。よって、５Ｗｈ未満の仮想残量値がＯＳ３５１ａに通知されると、ＯＳ３５１ａはアプリケーション３５２ａをスリープさせ、ＯＳ３５１ａ自体もスリープする。

さて、ルールセット５２０では３つの条件５２１〜５２３が定義されている。条件５２１は、「電池３１１の残量としてＯＳ３５１ａが認識する値（すなわちＯＳ３５１ａに通知された仮想残量値）が、２５Ｗｈ以上である」という条件である。条件５２２は、「電池３１１の残量としてＯＳ３５１ａが認識する値が２．５Ｗｈ以上２５Ｗｈ未満である」という条件である。条件５２３は、「電池３１１の残量としてＯＳ３５１ａが認識する値が、２．５Ｗｈ未満である」という条件である。

条件５２１にはルール５２４と５２５が対応づけられており、条件５２２にはルール５２６〜５２９が対応づけられており、条件５２３にはルール５３０が対応づけられている。ルール５２４〜５３０は、それぞれ、ルール５０４〜５１０と同じである。つまり、ルールセット５００と５２０には、同じルールが含まれるが、各ルールが適用される条件が、ルールセット５００と５２０では異なる。

例えば、２２Ｗｈという仮想残量値がＯＳ３５１ａに通知された場合、もしルールセット５００が選択されていれば、ＯＳ３５１ａはルール５０４と５０５を適用する。しかし、もしルールセット５２０が選択されていれば、ＯＳ３５１ａはルール５２６〜５２９を適用する。

ところで、ＯＳ３５１ｂには１つのルールセット５４０が定義されており、ＯＳ３５１ｂはルールセット５４０にしたがって動作する。ルールセット５４０では３つの条件５４１〜５４３が定義されており、ルールセット５４０は５つのルール５４４〜５４８を含む。

条件５４１は、「ドントケア（don't care）」を示す条件である。つまり、電池３１１の残量としてＯＳ３５１ｂが認識する値（すなわちＯＳ３５１ｂに通知された仮想残量値）によらず、条件５４１は常に「成立する」と見なされる。条件５４２は、「電池３１１の残量としてＯＳ３５１ｂが認識する値が、３０Ｗｈ未満である」という条件である。条件５４３は、「電池３１１の残量としてＯＳ３５１ｂが認識する値が、７．５Ｗｈ未満である」という条件である。

ルール５４４は条件５４１に対応づけられている。ルール５４４は、「ＯＳ３５１ｂが認識する２つの仮想ＣＰＵコアのうち、第１コアを１ＧＨｚで動作させる」というルールである。

ルール５４５も条件５４１に対応づけられている。ルール５４５は、「ＯＳ３５１ｂが認識する２つの仮想ＣＰＵコアのうち、第２コアを停止する」というルールである。
ルール５４４を適用する場合、ＯＳ３５１ｂは、具体的には、第１コアを１ＧＨｚで動作させるためのハイパーバイザコールを呼び出してもよい。同様に、ルール５４５を適用する場合、ＯＳ３５１ｂは、具体的には、第２コアを停止するためのハイパーバイザコールを呼び出してもよい。

ハイパーバイザコールに応じてハイパーバイザ３２０が実際に物理ＣＰＵコアのクロック周波数を変更するか否かは、場合による。同様に、ハイパーバイザコールに応じてハイパーバイザ３２０が実際に物理ＣＰＵコアを停止させるか否かも、場合による。

ルール５４６は、条件５４２に対応づけられている。ルール５４６は、「ディスプレイのバックライトを減光する」というルールである。

なお、ＯＳ３５１ｂは、物理デバイスであるタッチパネル２０６自体を認識しているのではなく、タッチパネル２０６に対応する仮想ディスプレイを認識している。よって、ルール５４６を適用する場合、ＯＳ３５１ｂは、ディスプレイのバックライトを減光するための命令を、仮想ドライバ３３０のうちの仮想ディスプレイドライバに対して発行してもよい。ＯＳ３５１ｂから発行された命令に応じて、実際にタッチパネル２０６のバックライトが減光されるか否かは、場合による。

ルール５４７も、条件５４２に対応づけられている。ルール５４７は、「ネットワーク通信を行うプロセスをサスペンド状態にする」というルールである。例えば、ＯＳ３５１ｂは、どのプロセスがネットワーク通信を行うのかを判断するために、ネットワーク通信のためにユーザプロセスから呼び出されるシステムコールを監視してもよい。

ルール５４８は、条件５４３に対応づけられている。ルール５４８は、「ＧＰＵを省電力モードに変更する」というルールである。ルール５４８を適用する場合、ＯＳ３５１ｂは、物理デバイスであるＧＰＵ２０５に対応する仮想ＧＰＵを省電力モードに変更するための命令を発行する。当該命令は、具体的にはハイパーバイザコールであってもよい。

例えば、１０Ｗｈという仮想残量値がＯＳ３５１ｂに通知された場合、条件５４１と５４２の双方が成立する。よって、この場合、ＯＳ３５１ｂは、ルール５４４〜５４７を適用する。

続いて、図３の情報処理装置３００が行う処理について説明する。情報処理装置３００の電源がオンになっている間、以下の（１６ａ）〜（１６ｃ）の処理が並行に実行される。

（１６ａ）プロファイル４０１ａ中の使用状況情報３４４を取得するために、プロファイラ３４１ａが実行する処理。例えば、図４に関して説明したように、ＯＳ３５１ａから仮想ドライバ３３０を介して呼び出される（またはＯＳ３５１ａから直接呼び出される）ハイパーバイザコールを監視する処理など。
（１６ｂ）プロファイル４０１ｂ中の使用状況情報３４４を取得するために、プロファイラ３４１ｂが実行する処理。
（１６ｃ）仮想電池ドライバ３４０により実行される図６〜７の処理。

以下、図６〜７の処理について詳しく説明する。情報処理装置３００に電源が入れられると、図６〜７の処理が開始される。図６〜７の処理フローは、仮想電池ドライバ３４０により制御される。

まず、ステップＳ１０１で仮想電池ドライバ３４０は、適宜の初期化を行う。初期化の詳細は、実施形態に応じて様々であってよい。

例えば、プロファイラ３４１ａは、ＯＳ３５１ａに対応づけられて予め不揮発性記憶装置２１２に記憶されている優先度情報３４５とモード情報３４６を読み出してもよい。そして、プロファイラ３４１ａは、読み出した優先度情報３４５とモード情報３４６を、プロファイル４０１ａ用に割り当てられたメモリ２１１上の領域にコピーしてもよい。また、プロファイラ３４１ａは、プロファイル４０１ａ中の使用状況情報３４４を格納するための、メモリ２１１上の領域をクリアしてもよい。プロファイラ３４１ｂも、プロファイラ３４１ａと同様の初期化を適宜行う。

また、計算部３４３が、ＯＳ３５１ａに対応する仮想残量値の初期値と、ＯＳ３５１ｂに対応する仮想残量値の初期値を、ステップＳ１０１で計算してもよい。そして、計算された初期値をプロファイラ３４１ａと３４１ｂがそれぞれＯＳ３５１ａと３５１ｂに通知してもよい。

実施形態によっては、ステップＳ１０１での初期値の計算と通知は省略されてもよい。また、計算部３４３が初期値を計算する方法も、実施形態に応じて様々であってよい。例えば、取得部３４２が物理残量値を取得してもよい。そして、計算部３４３が優先度情報３４５と物理残量値に基づいてＯＳ３５１ａと３５１ｂそれぞれに対応する仮想残量値の初期値を計算してもよい。

あるいは、ＯＳ３５１ａと３５１ｂそれぞれに対応する仮想残量値の初期値が、予め決められていてもよい。この場合、計算部３４３は初期値を計算しない。プロファイラ３４１ａは、ＯＳ３５１ａ用に予め決められた初期値をＯＳ３５１ａに通知し、プロファイラ３４１ｂは、ＯＳ３５１ｂ用に予め決められた初期値をＯＳ３５１ｂに通知する。

ステップＳ１０１では、例えば以上説明したような適宜の初期化が行われる。次に、ステップＳ１０２で仮想電池ドライバ３４０は、所定の単位時間が経過するまで待つ。

例えば、仮想電池ドライバ３４０は、タイマ割り込みを使って所定の単位時間が経過するまで待ってもよい。なお、単位時間の長さは実施形態に応じて任意である。所定の単位時間が経過すると、図６〜７の処理はステップＳ１０３へと移行する。

ステップＳ１０３で仮想電池ドライバ３４０は、インデックス変数ｋに１を代入することで、インデックス変数ｋを初期化する。

次に、ステップＳ１０４で仮想電池ドライバ３４０は、ｋ番目のプロファイラに使用状況情報３４４の生成と記録を命令する。すると、ｋ番目のプロファイラが、今回の期間の間のｋ番目のＯＳの動作状況から、ｋ番目のＯＳについての使用状況情報３４４を生成し、生成した使用状況情報３４４を記録する。

ここで、「今回の期間」とは、具体的には、ステップＳ１０２で経過した単位時間である。例えば単位時間が３分間である場合、「今回の期間」は、直近の３分間である。

上記の（１６ａ）〜（１６ｂ）のとおり、図６〜７の処理と並行して、プロファイラ３４１ａはＯＳ３５１ａからデバイスへのアクセス要求を監視し、プロファイラ３４１ｂはＯＳ３５１ｂからデバイスへのアクセス要求を監視する。つまり、ステップＳ１０２で単位時間の経過が待たれている間にも、プロファイラ３４１ａと３４１ｂによる監視は並行して実行される。

例えば、プロファイラ３４１ａは、ＯＳ３５１ａの動作状況を一時的に記憶するために、カウンタ変数やフラグ変数を用いてもよい。具体的には、プロファイラ３４１ａは、ＯＳ３５１ａからデバイスへのアクセス要求のたびに、例えば、アクセス要求の回数を示すためのカウンタ変数（または、アクセス要求の有無を示すためのフラグ変数）を更新してもよい。プロファイラ３４１ｂも同様に、適宜の変数を利用しながら、ＯＳ３５１ｂからデバイスへのアクセス要求を監視してもよい。

図３の例では、１番目のプロファイラはプロファイラ３４１ａであり、１番目のＯＳはＯＳ３５１ａである。また、２番目のプロファイラはプロファイラ３４１ｂであり、２番目のＯＳはＯＳ３５１ｂである。

よって、ｋ＝１の場合、ステップＳ１０４でプロファイラ３４１ａは、今回の期間における監視から判明したＯＳ３５１ａの動作状況から、ＯＳ３５１ａについての使用状況情報３４４を生成する。例えば、プロファイラ３４１ａは、上記のようなカウンタ変数やフラグ変数の値に基づいて、使用状況情報３４４を生成してもよい。もちろん、図４に関して説明したとおり、デバイスの種類によっては、プロファイラ３４１ａは、ハイパーバイザ３２０への問い合わせを介して使用状況情報３４４を生成してもよい。

そして、プロファイラ３４１ａは、生成した使用状況情報３４４を、プロファイル４０１ａの一部として記録する。より具体的には、プロファイラ３４１ａは、図４に示すように、生成した使用状況情報３４４を「直近の期間」に対応づけて記録する。

なお、今まで「直近からＴ番目の期間」に対応づけられていた使用状況情報３４４は破棄される。また、１≦ｊ＜Ｔなる各ｊについて、今まで「直近からｊ番目の期間」に対応づけられていた使用状況情報３４４は、ステップＳ１０４で、「直近から（ｊ＋１）番目の期間」に対応づけられる。

例えば、プロファイル４０１ａ内の使用状況情報３４４を格納するためのメモリ領域は、バッファサイズがＴのリングバッファであってもよい。この場合、プロファイラ３４１ａは、リングバッファのポインタの値をステップＳ１０４で更新してもよい。

続いて、ステップＳ１０５で仮想電池ドライバ３４０は、インデックス変数ｋの値と、情報処理装置３００内の仮想マシンの数Ｎを比較する。仮想マシンの数Ｎは、換言すればＯＳの数である。また、第２実施形態では、仮想電池ドライバ３４０内のプロファイルの数もＮである。図３と４には、Ｎ＝２の例が示されている。

もし、ｋ＜Ｎであれば、対応する使用状況情報３４４がまだ記録されていないＯＳが残っている。そこで、図６〜７の処理は、ステップＳ１０５からステップＳ１０６へと移行する。

逆に、ｋ≧Ｎであれば（具体的にはｋ＝Ｎであれば）、今回の期間に関して、すべてのＯＳについて、それぞれ対応する使用状況情報３４４が記録され終わっている。そこで、図６〜７の処理は、ステップＳ１０５からステップＳ１０７へと移行する。

ステップＳ１０６で仮想電池ドライバ３４０は、インデックス変数ｋを１だけインクリメントする。そして、図６〜７の処理はステップＳ１０４へと戻る。

さて、ステップＳ１０７では、取得部３４２が電池３１１の物理残量値を取得する。以下では、物理残量値を「Ｒ」とする。

取得部３４２は、例えば、電池Ｉ／Ｆ２０３にアクセスし、電池Ｉ／Ｆ２０３から物理残量値Ｒを取得してもよい。取得部３４２は、取得した物理残量値Ｒを計算部３４３に通知する。

次に、ステップＳ１０８で計算部３４３は、各プロファイラに通知するために仮想残量値を計算するか否かを決定する。以下では、ｋ番目のＯＳに通知するための仮想残量値を「ｒ_ｋ」とする。

第２実施形態では、物理残量値Ｒが所定の閾値Ｄｐ未満の場合、計算部３４３は個々の仮想残量値ｒ_ｋを計算しない。その代わり、物理残量値Ｒが閾値Ｄｐ未満の場合、計算部３４３は、「どのＯＳに対応する仮想残量値ｒ_ｋもゼロである（すなわち、１≦ｋ≦Ｎなるすべてのｋについてｒ_ｋ＝０）」と見なす。閾値Ｄｐは正の比較的小さな値である。

具体的には、Ｒ＜Ｄｐならば、図６〜７の処理はステップＳ１０９に移行する。逆に、Ｒ≧Ｄｐならば、図６〜７の処理はステップＳ１１３に移行する。
ステップＳ１０９で計算部３４３は、インデックス変数ｋを１に初期化する。

そして、次のステップＳ１１０で計算部３４３は、ｋ番目のプロファイラに、ゼロという仮想残量値ｒ_ｋを通知する。すると、ｋ番目のプロファイラは、ゼロという仮想残量値ｒ_ｋをｋ番目のＯＳに通知する。

次に、ステップＳ１１１で計算部３４３は、インデックス変数ｋの値とＯＳの数Ｎを比較する。

もし、ｋ＜Ｎであれば、まだゼロという仮想残量値ｒ_ｋの通知が済んでいないＯＳが残っている。そこで、図６〜７の処理は、ステップＳ１１１からステップＳ１１２へと移行する。

逆に、ｋ≧Ｎであれば（具体的にはｋ＝Ｎであれば）、すべてのＯＳに対してそれぞれゼロという仮想残量値ｒ_ｋが既に通知されている。よって、図６〜７の処理は、ステップＳ１１１からステップＳ１０２へと戻る。

ステップＳ１１２で計算部３４３は、インデックス変数ｋを１だけインクリメントする。そして、図６〜７の処理はステップＳ１１０へと戻る。

さて、ステップＳ１０８において物理残量値Ｒが閾値Ｄｐ以上と判断された場合、ステップＳ１１３で計算部３４３は、以下の（１７ａ）と（１７ｂ）の条件がともに成立するか否かを判断する。

（１７ａ）電池３１１（つまり電池２０１）は現在充電中である。
（１７ｂ）フラグ３４７が「電池３１１の充電中は、物理残量値を最大値と見なす」ということを示している。

例えば、計算部３４３は、電池３１１が現在充電中か否かについての問い合わせを、電池Ｉ／Ｆ２０３に対して発行してもよい。換言すれば、計算部３４３は、電池Ｉ／Ｆ２０３へのアクセスを通じて、「電池３１１が現在充電中か否か」を判断してもよい。

上記の（１７ａ）と（１７ｂ）の条件がともに成立する場合、図６〜７の処理はステップＳ１１４へと移行する。逆に、（１７ａ）と（１７ｂ）の条件のうち少なくとも一方が成立しない場合、図６〜７の処理は、図７のステップＳ１１５へと移行する。

ステップＳ１１４で計算部３４３は、物理残量値Ｒが最大値ｍａｘＲであると見なす。より具体的には、最大値ｍａｘＲは、電池３１１の仕様において定められている、物理残量値Ｒの定義域の最大値である。

なお、計算部３４３は、予め取得部３４２を介して電池Ｉ／Ｆ２０３から最大値ｍａｘＲを取得してもよい。あるいは、最大値ｍａｘＲは、定数として不揮発性記憶装置２１２に予め記憶されていてもよい。

取得部３４２が取得した物理残量値Ｒを、以上のようにして計算部３４３が上書きした後、図６〜７の処理は、図７のステップＳ１１５へと移行する。
ステップＳ１１５で計算部３４３は、インデックス変数ｋを１に初期化する。

そして、次のステップＳ１１６で計算部３４３は、以下の（１８ａ）と（１８ｂ）の情報を用いて、ｋ番目のＯＳに対応する仮想残量値ｒ_ｋを計算する。

（１８ａ）ｋ番目のＯＳに対応する使用状況情報３４４と、ｋ番目のＯＳに対応する優先度情報３４５の、少なくとも一方。
（１８ｂ）物理残量値Ｒ（具体的には、ステップＳ１０７で取得部３４２により取得された値そのものか、または、当該値を上書きするのにステップＳ１１４で使われた最大値ｍａｘＲ）。

ステップＳ１１５における具体的な計算方法は、実施形態に応じて様々であってよい。例えば、計算部３４３は、式（１）にしたがって、仮想残量値ｒ_ｋを計算してもよい。

式（１）において、「Ｎ」は仮想マシンの数（換言すればＯＳの数）を表す。また、「Ｒ」は物理残量値を表す。

式（１）の「Ｑ」は、０＜Ｑ≦１を満たす係数である。係数Ｑの値は、固定されていてもよいし、ユーザ定義可能であってもよい。そして、「ｅ_ｋ」は、ｋ番目のＯＳの特性を示す評価値である。

式（１）によれば、仮想残量値ｒ_ｋは、物理残量値Ｒに対して単調増加するように定義されている。また、式（１）によれば、仮想残量値ｒ_ｋは、全ＯＳの評価値の平均値に対する、ｋ番目のＯＳの評価値ｅ_ｋの割合に対して、単調増加するように定義されている。

また、式（１）によれば、係数Ｑの値が大きいほど、ｋ番目のＯＳに通知される仮想残量値ｒ_ｋが大きい。そして、図５の例示のとおり、多くのＯＳは、電池の残量が多いほど、より多くの資源を使う傾向がある。したがって、係数Ｑの値が大きいほど、消費電力量は増え、電池２０１が早く切れてしまう傾向がある。

よって、電池３１１をより長持ちさせるためには、係数Ｑが小さな値であることが好ましい。逆に、パフォーマンスを優先するためには、係数Ｑが１に近い大きめの値であることが好ましい。

式（１）の評価値ｅ_ｋは、具体的には、ｋ番目のＯＳについての使用状況情報３４４と優先度情報３４５のうち、少なくとも一方に基づく値である。また、計算部３４３は、使用状況情報３４４の履歴（つまり、図４における「直近から２番目の期間」から「直近からＴ番目の期間」までの使用状況情報３４４）を利用して評価値ｅ_ｋを計算してもよい。あるいは、計算部３４３は、使用状況情報３４４の履歴を使わずに評価値ｅ_ｋを計算してもよい（つまり、図４においてＴ＝１であってもよい）。

以下に、評価値ｅ_ｋの様々な定義に応じた、仮想残量値ｒ_ｋの様々な計算方法について、さらに具体的に説明する。以下の式（２）〜（５）および（７）は、いずれも、式（１）の具体例である。なお、以下では説明の便宜上、次の（１９ａ）〜（１９ｃ）のような表記法を用いる。

（１９ａ）ｋ番目のＯＳの優先度を「ｐ_ｋ」とする。優先度ｐ_ｋは、ｋ番目のＯＳについて優先度情報３４５により定義された値である。図４の例によれば、ｐ_１＝５でありｐ_２＝２である。
（１９ｂ）ｋ番目の仮想マシンに起因して消費される電力量に関して、直近からｊ番目の期間について推定される平均電力を「ｃ_ｋ，ｊ」とする。平均電力ｃ_ｋ，ｊは、直近からｊ番目の期間に対応してｋ番目のプロファイラが生成した使用状況情報３４４から、計算部３４３により計算される。平均電力ｃ_ｋ，ｊを計算するための具体的な式の例は、図８〜９とともに後述する。
（１９ｃ）計算部３４３が使用状況情報３４４の履歴を使わない場合については、簡単化のため、平均電力ｃ_ｋ，１を単に「ｃ_ｋ」とも表記する。

以下では説明の便宜上、上記の（１９ａ）〜（１９ｃ）の表記法を用いて、計算部３４３による仮想残量値ｒ_ｋの計算方法の具体例について説明する。

まず、計算部３４３は、ｋ番目のＯＳについての使用状況情報３４４を参照して、平均電力ｃ_ｋ，ｊを計算する。

使用状況情報３４４の履歴を使わない場合、計算部３４３は、平均電力ｃ_ｋ（＝ｃ_ｋ，１）と優先度ｐ_ｋを用いて、例えば式（２）にしたがって仮想残量値ｒ_ｋを計算してもよい。式（２）は、ｅ_ｋ＝ｐ_ｋｃ_ｋの場合を示す。

また、計算部３４３は、式（３）と（４）に示すように、使用状況情報３４４と優先度情報３４５の一方のみを用いて仮想残量値ｒ_ｋを計算してもよい。式（３）はｅ_ｋ＝ｃ_ｋの場合を示し、式（４）はｅ_ｋ＝ｐ_ｋの場合を示す。

もちろん、計算部３４３は、使用状況情報３４４の履歴を用いてもよい。例えば、計算部３４３は、使用状況情報３４４の履歴と優先度情報３４５の双方を用いて、式（５）にしたがって仮想残量値ｒ_ｋを計算してもよい。式（５）は、評価値ｅ_ｋが式（６）のように表される場合を示す。

計算部３４３は、優先度情報３４５を使わずに、使用状況情報３４４の履歴を用いて、式（７）にしたがって仮想残量値ｒ_ｋを計算してもよい。式（７）は、評価値ｅ_ｋが式（８）のように表される場合を示す。

もちろん、計算部３４３は、上記に例示した以外の式にしたがって、図７のステップＳ１１６において仮想残量値ｒ_ｋを計算してもよい。

例えば、仮想残量値ｒ_ｋの定義域の最大値が決められていてもよい。以下では当該最大値を「ｍａｘｒ_ｋ」とする。

例えば、任意のｋについて「ｍａｘｒ_ｋ＝ｍａｘＲ」と定義されていてもよい。この「ｍａｘｒ_ｋ＝ｍａｘＲ」という定義は、特に後述の第２モードに好適である。あるいは、優先度情報３４５が使われる場合は、物理残量値Ｒの最大値ｍａｘＲと優先度ｐ_ｋに応じて、仮想残量値ｒ_ｋの最大値ｍａｘｒ_ｋが静的に定義されていてもよい。

計算部３４３は、例えば、式（１）の代わりに式（９）を用いて、仮想残量値ｒ_ｋを計算してもよい。なお、上記のとおり、式（２）〜（５）および（７）は、いずれも、式（１）の具体例である。よって、式（９）の評価値ｅ_ｋを適宜定義することによって、式（１）を式（９）で置き換えるのと同様にして、式（２）〜（５）および（７）の各々も別の式に置き換えることが可能である。

仮想残量値ｒ_ｋの計算後、次のステップＳ１１７で計算部３４３は、仮想残量値ｒ_ｋと閾値Ｄｖを比較する。閾値Ｄｖは正の比較的小さな値である。

もし、ｒ_ｋ＜Ｄｖならば、図６〜７の処理はステップＳ１１８に移行する。逆に、ｒ_ｋ≧Ｄｖならば、図６〜７の処理はステップＳ１１９に移行する。

ステップＳ１１８で計算部３４３は、実際にステップＳ１１６で計算した値に関わらず、ｋ番目のプロファイラに、ゼロという仮想残量値ｒ_ｋを通知する。つまり、計算部３４３は、仮想残量値ｒ_ｋをゼロと再評価する。すると、ｋ番目のプロファイラは、ゼロという仮想残量値ｒ_ｋをｋ番目のＯＳに通知する。そして、図６〜７の処理はステップＳ１２５へと移行する。

他方、ｒ_ｋ≧Ｄｖの場合、ステップＳ１１９で計算部３４３は、ステップＳ１１３と同様の方法により、現在電池３１１が充電中であるか否かを判断する。もし、電池３１１が現在充電中でなければ、図６〜７の処理はステップＳ１２０へと移行する。逆に、電池２０１が現在充電中であれば、図６〜７の処理はステップＳ１２１へと移行する。

ステップＳ１２０で計算部３４３は、ｋ番目のプロファイラに、ステップＳ１１６で計算した仮想残量値ｒ_ｋを通知する。すると、ｋ番目のプロファイラは、通知された仮想残量値ｒ_ｋをｋ番目のＯＳに通知する。そして、図６〜７の処理はステップＳ１２５へと移行する。

ステップＳ１２１で計算部３４３は、ｋ番目のＯＳについてのモード情報３４６を参照する。以下、第１〜第３モードについて説明する。

第１モードは、物理的な電池３１１（つまり電池２０１）が充電されている間は特定の値をＯＳに通知するモードである。具体的には、第１モードにおける上記「特定の値」は、仮想残量値ｒ_ｋの定義域の最大値である。仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋは、仮想残量値ｒ_ｋの計算に使われる式によって異なり得る。

例えば、式（９）が使われる場合、仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋは、最大値ｍａｘｒ_ｋとして予め任意に決められた正の値である。また、式（４）が使われる場合、仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋは、物理残量値Ｒの定義域の最大値ｍａｘＲと、各ＯＳの優先度ｐ_ｉに応じて決まる。

式（２）が使われる場合、仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋは、各仮想マシンに対応する電力ｃ_ｉの最小値による。例えば、各仮想マシンに対応する電力ｃ_ｉの最小値がゼロであるとする。この場合、式（２）においてｉ≠ｋなる各ｉについてｃ_ｉ＝０とし、かつＲ＝ｍａｘＲとすると、ｒ_ｋ＝Ｑ・ｍａｘＲ・Ｎである。したがって、ｍａｘｒ_ｋ＝Ｑ・ｍａｘＲ・Ｎである。

式（３）、（５）、または（７）が使われる場合の最大値ｍａｘｒ_ｋも、式（２）が使われる場合と同様である。

電池３１１の充電中は、消費電力量を低く抑えるための制御をＯＳが特に行わなくても、電池切れの心配はない。そこで、電池３１１の充電中は消費電力量の抑制よりもパフォーマンス向上を優先するために、第１モードが使われてもよい。

第２モードは、物理的な電池３１１が充電されている間は物理残量値Ｒを仮想残量値ｒ_ｋとしてＯＳに通知するモードである。ＯＳの中には、「充電完了まであとＸ分」もしくは「Ｙ％充電完了」のようなメッセージ（または、そのようなメッセージに相当するアイコン）を表示するための計算を行うものがある。当該計算が正確に行われるようにするために、当該計算を行うＯＳは、第２モードに設定されていてもよい。

なお、仮想電池ドライバ３４０は、当該計算を行うＯＳに対して、当該計算に用いるための値として、物理残量値Ｒの定義域の最大値ｍａｘＲを予め通知しておいてもよい。すると、第２モードのＯＳは、予め通知された最大値ｍａｘＲと、充電中の電池３１１の現在の物理残量値Ｒとから、充電完了までにかかる時間、または現在の充電率を計算することができる。

第３モードは、物理的な電池３１１が充電中の場合と、物理的な電池３１１が充電中ではない場合を区別しないモードである。第１モードには電池３１１の充電中のパフォーマンスの向上という効果があり、第２モードには上記計算の正確性の向上という効果がある。しかし、もちろん、第３モードも利用可能である。

さて、ステップＳ１２１におけるモード情報３４６の参照の結果、ｋ番目のＯＳのモードが第１モードと判明した場合、図６〜７の処理はステップＳ１２２へと移行する。また、ｋ番目のＯＳのモードが第２モードの場合、図６〜７の処理はステップＳ１２３へと移行する。そして、ｋ番目のＯＳのモードが第３モードの場合、図６〜７の処理はステップＳ１２４へと移行する。

ｋ番目のＯＳのモードが第１モードの場合、ステップＳ１２２で計算部３４３は、実際にステップＳ１１６で計算した値に関わらず、ｋ番目のプロファイラに、ｋ番目の仮想マシンに対応する仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋを通知する。つまり、計算部３４３は、仮想残量値ｒ_ｋを最大値ｍａｘｒ_ｋと見なす。すると、ｋ番目のプロファイラは、通知された最大値ｍａｘｒ_ｋをｋ番目のＯＳに通知する。そして、図６〜７の処理はステップＳ１２５へと移行する。

なお、上記のとおり、仮想残量値ｒ_ｋの定義域の最大値ｍａｘｒ_ｋは、予め決められた定数でもよいし、仮想残量値ｒ_ｋの式に応じて決まる値であってもよい。最大値ｍａｘｒ_ｋは、例えば不揮発性記憶装置２１２に予め記憶されていてもよい。そして、最大値ｍａｘｒ_ｋは、不揮発性記憶装置２１２から、仮想電池ドライバ３４０に割り当てられたメモリ空間内の記憶領域へと予め読み出されていてもよい。

さて、ｋ番目のＯＳのモードが第２モードの場合、ステップＳ１２３で計算部３４３は、ｋ番目のプロファイラに、仮想残量値ｒ_ｋとして物理残量値Ｒを通知する。なお、ステップＳ１２３で仮想残量値ｒ_ｋとして通知される物理残量値Ｒは、ステップＳ１０７で取得部３４２が取得した値そのものの場合もあるし、ステップＳ１１４で最大値ｍａｘＲに書き換えられた物理残量値Ｒの場合もある。

つまり、電池３１１が充電中のとき、計算部３４３は、仮想残量値ｒ_ｋを、電池３１１の現在の実際の物理残量値Ｒと同じと見なす場合もある。また、電池３１１が充電中のとき、計算部３４３は、仮想残量値ｒ_ｋを、物理残量値Ｒの定義域の最大値ｍａｘＲと同じと見なす場合もある。

いずれにせよ、計算部３４３がｋ番目のプロファイラに仮想残量値ｒ_ｋとして物理残量値Ｒを通知すると、ｋ番目のプロファイラは、仮想残量値ｒ_ｋとして物理残量値Ｒをｋ番目のＯＳに通知する。そして、図６〜７の処理はステップＳ１２５へと移行する。

さて、ｋ番目のＯＳのモードが第３モードの場合、ステップＳ１２４で計算部３４３は、ｋ番目のプロファイラに、ステップＳ１１６で計算した仮想残量値ｒ_ｋを通知する。すると、ｋ番目のプロファイラは、通知された仮想残量値ｒ_ｋをｋ番目のＯＳに通知する。そして、図６〜７の処理はステップＳ１２５へと移行する。

さて、ステップＳ１２５は、ｋ番目のプロファイラがステップＳ１１８、Ｓ１２０、Ｓ１２２、Ｓ１２３、またはＳ１２４においてｋ番目のＯＳに仮想残量値ｒ_ｋを通知した後に、実行される。具体的には、ステップＳ１２５で計算部３４３は、インデックス変数ｋの値とＯＳの数Ｎを比較する。

もし、ｋ＜Ｎであれば、まだ仮想残量値ｒ_ｋの通知が済んでいないＯＳが残っている。そこで、図６〜７の処理は、ステップＳ１２５からステップＳ１２６へと移行する。

逆に、ｋ≧Ｎであれば（具体的にはｋ＝Ｎであれば）、すべてのＯＳに対してそれぞれ仮想残量値ｒ_ｋが既に通知されている。よって、図６〜７の処理は、ステップＳ１２５から図６のステップＳ１０２へと戻る。

ステップＳ１２６で計算部３４３は、インデックス変数ｋを１だけインクリメントする。そして、図６〜７の処理はステップＳ１１６へと戻る。

以上説明した図６〜７の処理により、定期的に各ＯＳに仮想残量値が通知される。そして、各ＯＳは、通知された仮想残量値と図５のようなルールセットにしたがって、電力に関する適宜の制御を実行する。

続いて、図８〜９を参照して、具体的な計算例について説明する。図８は、第２実施形態において履歴を使わずに仮想残量値ｒ_ｋを計算する例を示す図である。また、図９は、第２実施形態において履歴を使って仮想残量値ｒ_ｋを計算する例を示す図である。

具体的には、図８〜９には、５つの計算例６０１〜６０５が例示されている。計算例６０１は、仮想残量値が利用されない第３比較例に関する例である。

計算例６０２は、第２実施形態において式（２）が利用され、式（２）においてＱ＝０．１である場合の例である。計算例６０３は、第２実施形態において式（２）が利用され、式（２）においてＱ＝１である場合の例である。つまり、計算例６０２と６０３を比べると、計算例６０２は電池３１１を長持ちさせることを重視する例であり、計算例６０３はパフォーマンスを重視する例である。

計算例６０４は、第２実施形態において式（５）が利用され、式（５）においてＴ＝２かつＱ＝０．１である場合の例である。計算例６０５は、第２実施形態において式（５）が利用され、式（５）においてＴ＝２かつＱ＝１である場合の例である。つまり、計算例６０４と６０５を比べると、計算例６０４は電池３１１を長持ちさせることを重視する例であり、計算例６０５はパフォーマンスを重視する例である。

具体的に計算例６０１〜６０５について参照する前に、いくつかの仮定について説明する。図８〜９の例では、以下の（２０ａ）〜（２０ｍ）のように仮定する。

（２０ａ）図４の例とは異なり、ＯＳ３５１ａに対応する（つまり仮想マシン３５０ａに対応する）優先度ｐ_１は、１であるものとする。また、図４の例とは異なり、ＯＳ３５１ｂに対応する（つまり仮想マシン３５０ｂに対応する）優先度ｐ_２は、３であるものとする。
（２０ｂ）上記（１４ｆ）のように、クアッドコアの物理ＣＰＵのうち２つのコアが仮想マシン３５０ａの２つの仮想ＣＰＵコアに割り当てられ、残りの２つのコアが仮想マシン３５０ｂの２つの仮想ＣＰＵコアに割り当てられるものとする。この場合、仮想マシン３５０ａと仮想マシン３５０ｂは物理ＣＰＵコアを共有しない。よって、ハイパーバイザ３２０は、ＣＰＵコアのクロック周波数を変更するための命令をＯＳ３５１ａまたは３５１ｂから受け取ると、命令にしたがって実際にクロック周波数を変更するものとする。
（２０ｃ）１つの物理ＣＰＵコアを１ＧＨｚで動作させ、かつ１００％の使用率で命令を実行させるための電力は、１Ｗであるものとする。また、１つの物理ＣＰＵコアを５００ＭＨｚで動作させ、かつ１００％の使用率で命令を実行させるための電力は、０．５Ｗであるものとする。そして、１つの物理ＣＰＵコアを１００ＭＨｚで動作させ、かつ１００％の使用率で命令を実行させるための電力は、０．１Ｗであるものとする。
（２０ｄ）或る期間に物理ＣＰＵコアによって消費される電力量は、当該期間における物理ＣＰＵコアの使用率に比例するものとする。ここでは説明の簡単化のため、仮想マシン３５０ａの２つの仮想ＣＰＵコアに割り当てられた２つの物理ＣＰＵコアの使用率は、どちらも常に１００％であるものとする。同様に、仮想マシン３５０ｂの２つの仮想ＣＰＵコアに割り当てられた２つの物理ＣＰＵコアの使用率は、どちらも常に１００％であるものとする。
（２０ｅ）仮想マシン３５０ａの動作に起因する消費電力量と、仮想マシン３５０ｂの動作に起因する消費電力量の和が、情報処理装置３００全体の消費電力量に等しいとする。また、簡単化のため、ＣＰＵ２０４とＧＰＵ２０５とタッチパネル２０６とＷｉＦｉモジュール２１６以外のデバイスの動作にかかる電力は、無視することができるものとする。
（２０ｆ）ＯＳ３５１ａは図５のルールセット５００を使い、ＯＳ３５１ｂは図５のルールセット５４０を使うものとする。なお、図８〜９のテーブル中では、ＯＳが適用するルールが切り換わる箇所の横罫線が、太く強調されている。
（２０ｇ）ＷｉＦｉモジュール２１６による通信により消費される電力量は、０．０１Ｗｈ／ｋＢであるものとする。
（２０ｈ）アプリケーション３５２ａからの要求に応じて、ＯＳ３５１ａは、仮想マシン３５０ａの仮想ＷｉＦｉモジュールを介してフレームを送信または受信する。このような仮想マシン３５０ａ用の仮想ＷｉＦｉモジュールを介した通信のデータレートは、通常は、１０００ｋＢ／ｈであるものとする。同様に、仮想マシン３５０ｂ用の仮想ＷｉＦｉモジュールを介した通信のデータレートも、通常は、１０００ｋＢ／ｈであるものとする。なお、データレートは、ルール５０８または５４７の適用により、制限される場合がある。
（２０ｉ）デュアルコアの物理ＧＰＵが１台あるものとする。そして、第１コアが仮想マシン３５０ａ用の仮想ＧＰＵに割り当てられており、第２コアが仮想マシン３５０ｂ用の仮想ＧＰＵに割り当てられているものとする。
（２０ｊ）ＧＰＵのモードには、「通常モード」と「省電力モード」の２種類があるものとする。例えば、２種類のモード間でＧＰＵのクロック周波数が異なっていてもよい。また、物理ＧＰＵコアを通常モードと省電力モードで動作させるための電力は、それぞれ、２Ｗと１Ｗであるものとする。使用状況情報３４４では、物理ＧＰＵコアに関して、図４のように「ＯＮ」または「ＯＦＦ」が記録されるのではなく、モードが記録されるものとする。
（２０ｋ）ＯＳ３５１ａと３５１ｂは、仮想ＧＰＵのモードを変更するための命令（例えばハイパーバイザコール）を発行してもよい。仮想マシン３５０ａと３５０ｂは物理ＧＰＵコアを共有しないので、ハイパーバイザ３２０は、命令にしたがって、仮想ＧＰＵに対応する物理ＧＰＵコアのモードを実際に変更するものとする。
（２０ｌ）或る仮想マシンにおける全プロセスがサスペンド状態のとき、当該仮想マシンの実行にかかる電力は、全デバイスを合わせて０．０１Ｗであるものとする。また、ＯＳが強制的にスリープしたときは、仮想マシンの実行にかかる電力は０Ｗであるものとする。
（２０ｍ）ＯＳ３５１ａと３５１ｂの少なくとも一方が、仮想ディスプレイのバックライトを減光するための命令を発行すると、ハイパーバイザ３２０が、物理デバイスであるタッチパネル２０６のバックライトを実際に減光するものとする。タッチパネル２０６のバックライトを通常の強さで発光させるための電力は４Ｗであり、減光されたレベルの発光をさせるための電力は１Ｗであるものとする。また、すべてのＯＳが強制的にスリープしたときは、タッチパネル２０６への電力供給が遮断されるものとする。

さて、計算例６０１に示す第３比較例では、同じ物理残量値ＲがＯＳ３５１ａと３５１ｂに通知される。他方、第２実施形態では、ＯＳ３５１ａと３５１ｂには、仮想残量値ｒ_１とｒ_２がそれぞれ通知される。しかし、ＯＳ３５１ａと３５１ｂは、通知された値が物理残量値なのか仮想残量値なのかを認識せず、単に、通知された値にしたがって適宜のルールを適用する。

２０Ｗｈ以上の電池残量がＯＳ３５１ａに通知された場合、図５によれば、ＯＳ３５１ａはルール５０４〜５０５を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５０４〜５０５の適用後の仮想マシン３５０ａの実行にかかる電力は、下記（２１ａ）〜（２１ｄ）の値の和であり、具体的には、１３．５（＝１＋０．５＋２＋１０）Ｗである。

（２１ａ）物理ＣＰＵの第１コア用の１Ｗ（物理ＣＰＵの第１コアは、仮想マシン３５０ａ用の仮想ＣＰＵの第１コアに割り当てられており、１ＧＨｚで動作し、使用率は１００％である）。
（２１ｂ）物理ＣＰＵの第２コア用の０．５Ｗ（物理ＣＰＵの第２コアは、仮想マシン３５０ａ用の仮想ＣＰＵの第２コアに割り当てられており、５００ＭＨｚで動作し、使用率は１００％である）。
（２１ｃ）物理ＧＰＵの第１コア用の２Ｗ（物理ＧＰＵの第１コアは、仮想マシン３５０ａ用の仮想ＧＰＵに割り当てられており、通常モードで動作する）。
（２１ｄ）ＷｉＦｉモジュール２１６用の１０Ｗ（＝１０００［ｋＢ／ｈ］×０．０１［Ｗｈ／ｋＢ］）。

また、５Ｗｈ以上２０Ｗｈ未満の電池残量がＯＳ３５１ａに通知された場合、図５によれば、ＯＳ３５１ａはルール５０６〜５０９を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５０６〜５０９の適用後の仮想マシン３５０ａの実行にかかる電力は、下記（２２ａ）〜（２２ｄ）の値の和であり、具体的には、２．６１（＝０．５＋０．１＋２＋０．０１）Ｗである。

（２２ａ）物理ＣＰＵの第１コア用の０．５Ｗ（物理ＣＰＵの第１コアは、仮想マシン３５０ａ用の仮想ＣＰＵの第１コアに割り当てられており、５００ＭＨｚで動作し、使用率は１００％である）。
（２２ｂ）物理ＣＰＵの第２コア用の０．１Ｗ（物理ＣＰＵの第２コアは、仮想マシン３５０ａ用の仮想ＣＰＵの第２コアに割り当てられており、１００ＭＨｚで動作し、使用率は１００％である）。
（２２ｃ）物理ＧＰＵの第１コア用の２Ｗ（物理ＧＰＵの第１コアは、仮想マシン３５０ａ用の仮想ＧＰＵに割り当てられており、通常モードで動作する）。
（２２ｄ）ＷｉＦｉモジュール２１６用の０．０１Ｗ（＝１［ｋＢ／ｈ］×０．０１［Ｗｈ／ｋＢ］）。

また、５Ｗｈ未満の電池残量がＯＳ３５１ａに通知された場合、図５によれば、ＯＳ３５１ａはルール５１０を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５１０の適用後の仮想マシン３５０ａの実行にかかる電力は、０Ｗである。

さて、３０Ｗｈ以上の電池残量がＯＳ３５１ｂに通知された場合、図５によれば、ＯＳ３５１ｂはルール５４４〜５４５を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５４４〜５４５の適用後の仮想マシン３５０ｂの実行にかかる電力は、下記（２３ａ）〜（２３ｄ）の値の和であり、具体的には、１３（＝１＋０＋２＋１０）Ｗである。

（２３ａ）物理ＣＰＵの第３コア用の１Ｗ（物理ＣＰＵの第３コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第１コアに割り当てられており、１ＧＨｚで動作し、使用率は１００％である）。
（２３ｂ）物理ＣＰＵの第４コア用の０Ｗ（物理ＣＰＵの第４コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第２コアに割り当てられているが、ルール５４５の適用により停止されている）。
（２３ｃ）物理ＧＰＵの第２コア用の２Ｗ（物理ＧＰＵの第２コアは、仮想マシン３５０ｂ用の仮想ＧＰＵに割り当てられており、通常モードで動作する）。
（２３ｄ）ＷｉＦｉモジュール２１６用の１０Ｗ（＝１０００［ｋＢ／ｈ］×０．０１［Ｗｈ／ｋＢ］）。

また、７．５Ｗｈ以上３０Ｗｈ未満の電池残量がＯＳ３５１ｂに通知された場合、図５によれば、ＯＳ３５１ｂはルール５４４〜５４７を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５４４〜５４７の適用後の仮想マシン３５０ｂの実行にかかる電力は、下記（２４ａ）〜（２４ｄ）の値の和であり、具体的には、３（＝１＋０＋２＋０）Ｗである。

（２４ａ）物理ＣＰＵの第３コア用の１Ｗ（物理ＣＰＵの第３コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第１コアに割り当てられており、１ＧＨｚで動作し、使用率は１００％である）。
（２４ｂ）物理ＣＰＵの第４コア用の０Ｗ（物理ＣＰＵの第４コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第２コアに割り当てられているが、ルール５４５の適用により停止されている）。
（２４ｃ）物理ＧＰＵの第２コア用の２Ｗ（物理ＧＰＵの第２コアは、仮想マシン３５０ｂ用の仮想ＧＰＵに割り当てられており、通常モードで動作する）。
（２４ｄ）ＷｉＦｉモジュール２１６用の０Ｗ（ルール５４７の適用により、ＷｉＦｉモジュール２１６を使った通信は行われない）。

また、７．５Ｗｈ未満の電池残量がＯＳ３５１ｂに通知された場合、図５によれば、ＯＳ３５１ｂはルール５４４〜５４８を適用する。よって、上記の仮定（２０ａ）〜（２０ｍ）によれば、ルール５４４〜５４８の適用後の仮想マシン３５０ｂの実行にかかる電力は、下記（２５ａ）〜（２５ｄ）の値の和であり、具体的には、２（＝１＋０＋１＋０）Ｗである。

（２５ａ）物理ＣＰＵの第３コア用の１Ｗ（物理ＣＰＵの第３コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第１コアに割り当てられており、１ＧＨｚで動作し、使用率は１００％である）。
（２５ｂ）物理ＣＰＵの第４コア用の０Ｗ（物理ＣＰＵの第４コアは、仮想マシン３５０ｂ用の仮想ＣＰＵの第２コアに割り当てられているが、ルール５４５の適用により停止されている）。
（２５ｃ）物理ＧＰＵの第２コア用の１Ｗ（物理ＧＰＵの第２コアは、仮想マシン３５０ｂ用の仮想ＧＰＵに割り当てられており、省電力モードで動作する）。
（２５ｄ）ＷｉＦｉモジュール２１６用の０Ｗ（ルール５４７の適用により、ＷｉＦｉモジュール２１６を使った通信は行われない）。

なお、図５のルールセット５４０は強制スリープに関するルールを含まない。そのため、ＯＳ３５１ａと３５１ｂが双方とも強制スリープすることはない。したがって、上記の仮定（２０ｆ）と（２０ｍ）より、タッチパネル２０６への電力供給は遮断されない。

また、図５のルールセット５００は、バックライトの減光に関するルールを含まない。そのため、タッチパネル２０６用の電力は、ＯＳ３５１ａに通知される電池残量に依存して変化することはない。

したがって、ＯＳ３５１ｂがルール５４６を適用しなければ（つまりＯＳ３５１ｂに３０Ｗｈ以上の電池残量が通知されれば）、タッチパネル２０６を動作させるための電力は４Ｗである。逆に、ＯＳ３５１ｂがルール５４６を適用すれば（つまりＯＳ３５１ｂに３０Ｗｈ未満の電池残量が通知されれば）、タッチパネル２０６を動作させるための電力は１Ｗである。

さて、以上の説明に基づいて、続いて図８〜９の計算例６０１〜６０５について説明する。
図８〜９において、「ｔ」は、電池３１１がフル充電された状態で情報処理装置３００に電源が入れられたときを基準とする時刻である。換言すれば、「ｔ」は、電池３１１がフル充電された状態で情報処理装置３００に電源が入れられてから経過した時間の長さを示す。なお、説明の便宜上、図８〜９の計算例６０１〜６０５は、いずれも、図６のステップＳ１０２の単位時間が１時間である場合の例である。しかし、もちろん単位時間はより短い時間であってもよい。

図８〜９において、「Ｒ」は、時刻ｔにおける電池３１１の物理残量値を示す。なお、図８〜９の例では、ｔ＝０のときＲ＝１００なので、時刻ｔの上記定義より、ｍａｘＲ＝１００である。

また、時刻ｔから時刻（ｔ＋１）までの期間において、仮想マシン３５０ａの実行にかかる電力は一定と見なせる。図８〜９ではその一定の電力が「ｃ_１」と表されている。つまり、時刻ｔにＯＳ３５１ａに通知された電池残量と、ルールセット５００に基づいて、時刻ｔにＯＳ３５１ａが行う制御によれば、時刻ｔから時刻（ｔ＋１）の期間では、仮想マシン３５０ａの実行にかかる電力は一定値ｃ_１である。

同様に、時刻ｔから時刻（ｔ＋１）までの期間において、仮想マシン３５０ｂの実行にかかる電力は一定と見なせる。図８〜９ではその一定の電力が「ｃ_２」と表されている。

また、時刻ｔから時刻（ｔ＋１）までの期間において、タッチパネル２０６を動作させるための電力も一定と見なせる。図８〜９ではその一定の電力が「ｃ_Ｌ」と表されている。

そして、上記（２０ｅ）の仮定より、時刻ｔから時刻（ｔ＋１）までの期間における情報処理装置３００全体の消費電力量は、時刻ｔの行の電力ｃ_１とｃ_２とｃ_Ｌを用いて、
（ｃ_１＋ｃ_２＋ｃ_Ｌ）［Ｗ］×１［ｈ］
と表せる。時刻（ｔ＋１）の物理残量値Ｒは、時刻ｔの物理残量値Ｒよりも、この消費電力量の分だけ少なくなっている。

例えば、図８の計算例６０１は、仮想残量値が使われない第３比較例を示す。
計算例６０１に示すように、第３比較例では、ＯＳ３５１ａに通知された物理残量値Ｒが２０Ｗｈ以上の間は（つまりｔ＝０の行からｔ＝２の行までは）、ｃ_１＝１３．５Ｗ（すなわち上記（２１ａ）〜（２１ｄ）の和）である。また、ＯＳ３５１ａに通知された物理残量値Ｒが５Ｗｈ以上２０Ｗｈ未満の間は（つまりｔ＝３の行では）、ｃ_１＝２．６１Ｗ（すなわち上記（２２ａ）〜（２２ｄ）の和）である。そして、ＯＳ３５１ａに通知された物理残量値Ｒが５Ｗｈ未満のときは（つまりｔ＝４の行では）、ｃ_１＝０Ｗである（ルール５１０が適用されるため）。

また、第３比較例では、ＯＳ３５１ｂに通知された物理残量値Ｒが３０Ｗｈ以上の間は（つまりｔ＝０の行からｔ＝２の行までは）、ｃ_２＝１３Ｗ（すなわち上記（２３ａ）〜（２３ｄ）の和）であり、ｃ_Ｌ＝４Ｗである。また、ＯＳ３５１ｂに通知された物理残量値Ｒが７．５Ｗｈ以上３０Ｗｈ未満の間は（つまりｔ＝３の行では）、ｃ_２＝３Ｗ（すなわち上記（２４ａ）〜（２４ｄ）の和）であり、ｃ_Ｌ＝１Ｗである。そして、ＯＳ３５１ｂに通知された物理残量値Ｒが７．５Ｗｈ未満のときは（つまりｔ＝４の行では）、ｃ_２＝２Ｗ（すなわち上記（２５ａ）〜（２５ｄ）の和）であり、ｃ_Ｌ＝１Ｗである。

計算例６０１に示すように、第３比較例では、時刻ｔ＝５のときには電池切れである。それに対して、第２実施形態についての計算例６０２〜６０５では、電池切れは時刻ｔ＝６以降に起きる。

具体的には、計算例６０２〜６０５では、上記（２０ａ）のような優先度に応じた仮想残量値ｒ_１とｒ_２がそれぞれＯＳ３５１ａと３５１ｂに通知される。よって、相対的に優先度の高い仮想マシン３５０ｂの稼働可能な時間が、第３比較例の計算例６０１よりも長い。

つまり、計算例６０２〜６０５では、相対的に優先度の低いＯＳ３５１ａには、小さな仮想残量値ｒ_１が通知される。そのため、仮想マシン３５０ａからのデバイスの利用をＯＳ３５１ａが抑制する傾向は、計算例６０１よりも計算例６０２〜６０５において、より強い。その結果、計算例６０２〜６０５では、相対的に優先度の低い仮想マシン３５０ａに分配される電力は少なくなり、相対的に優先度の高い仮想マシン３５０ｂの稼働可能な時間が長くなる。

なお、計算例６０２〜６０５のいずれにおいても、次の（２６ａ）〜（２６ｇ）のことは共通である。

（２６ａ）ＯＳ３５１ａに通知された仮想残量値ｒ_１が２０Ｗｈ以上の間は（例えば計算例６０３のｔ＝０の行からｔ＝２の行までは）、ｃ_１＝１３．５Ｗ（すなわち上記（２１ａ）〜（２１ｄ）の和）である。
（２６ｂ）ＯＳ３５１ａに通知された仮想残量値ｒ_１が５Ｗｈ以上２０Ｗｈ未満の間は（例えば計算例６０２のｔ＝０の行や計算例６０４のｔ＝０の行では）、ｃ_１＝２．６１Ｗ（すなわち上記（２２ａ）〜（２２ｄ）の和）である。
（２６ｃ）ＯＳ３５１ａに通知された仮想残量値ｒ_１が５Ｗｈ未満のときは（例えば計算例６０２のｔ＝１以降の行では）、ｃ_１＝０Ｗである（ルール５１０が適用されるため）。
（２６ｄ）ＯＳ３５１ｂに通知された仮想残量値ｒ_２が３０Ｗｈ以上の間は（例えば計算例６０５のｔ＝０の行からｔ＝２の行までは）、ｃ_２＝１３Ｗ（すなわち上記（２３ａ）〜（２３ｄ）の和）であり、ｃ_Ｌ＝４Ｗである。
（２６ｅ）ＯＳ３５１ｂに通知された仮想残量値ｒ_２が７．５Ｗｈ以上３０Ｗｈ未満の間は（例えば計算例６０２のｔ＝０の行からｔ＝１４の行までは）、ｃ_２＝３Ｗ（すなわち上記（２４ａ）〜（２４ｄ）の和）であり、ｃ_Ｌ＝１Ｗである。
（２６ｆ）ＯＳ３５１ｂに通知された仮想残量値ｒ_２が７．５Ｗｈ未満のときは（例えば計算例６０３のｔ＝５の行では）、ｃ_２＝２Ｗ（すなわち上記（２５ａ）〜（２５ｄ）の和）であり、ｃ_Ｌ＝１Ｗである。
（２６ｇ）ｔ＝０の行における仮想残量値ｒ_１とｒ_２は、図６のステップＳ１０１の初期化の際に計算部３４３により計算され、プロファイラ３４１ａと３４１ｂによりそれぞれＯＳ３５１ａと３５１ｂに通知された値である。ステップＳ１０１の初期化の際にはまだ使用状況情報３４４が蓄積されていないので、計算部３４３は、優先度情報３４５と物理残量値Ｒを使って、式（４）にしたがって仮想残量値ｒ_１とｒ_２を計算してもよい。計算例６０２〜６０５には、以上のようにして式（４）にしたがってｔ＝０のときに計算された仮想残量値ｒ_１とｒ_２が示されている。

ここで、計算例６０２〜６０５で上記（２６ａ）のように表される電力ｃ_１と、図５のルールセットと、図６〜７の処理との間の関係について補足説明する。他の（２６ｂ）〜（２６ｆ）の各々と図５〜７との間の関係も、（２６ａ）と図５〜７との間の関係と同様である。

図６〜７の処理によりプロファイラ３４１ａが時刻ｔにＯＳ３５１ａに通知した仮想残量値ｒ_１が２０Ｗｈ以上である場合、ＯＳ３５１ａは、通知に応じて、図５のルール５０４〜５０５を適用する。ルール５０４〜５０５の適用は、ほぼ時刻ｔに行われたものと見なせる。

また、上記のとおり、図８〜９の計算例６０１〜６０５においては、図６のステップＳ１０２の単位時間が１時間である。この単位時間の間は、新たな仮想残量値ｒ_１がＯＳ３５１ａに通知されない。そのため、この単位時間の間は、ＯＳ３５１ａも適用するルールを変えない。よって、時刻ｔから時刻（ｔ＋１）までの単位時間の間、仮想マシン３５０ａの実行にかかる電力も、一定と見なせる。つまり、２０Ｗｈ以上の仮想残量値ｒ_１をプロファイラ３４１ａがＯＳ３５１ａに通知した後の、図６のステップＳ１０２の単位時間が経過する間は、仮想マシン３５０ａの実行にかかる電力ｃ_１は、（２６ａ）に述べたとおり、１３．５Ｗという一定値と見なせる。

ところで、１３．５Ｗという電力は、上記のとおり（２１ａ）〜（２１ｄ）に示した電力の和である。そして、（２１ａ）〜（２１ｄ）に示した電力は、具体的には、計算部３４３が、ほぼ時刻（ｔ＋１）と見なせるタイミングでステップＳ１１６において計算する値である。

具体的には、上記のステップＳ１０２での単位時間の経過後、ほぼ時刻（ｔ＋１）と見なせるタイミングにおいてステップＳ１０４が実行される。ステップＳ１０４で生成されるプロファイル４０１ａの使用状況情報３４４は、以下の（２７ａ）〜（２７ｆ）に示す「１ＧＨｚ」、「１００％」、「５００ＭＨｚ」、「１００％」、「通常モード」、および「１０００ｋＢ」という値を含む。

（２７ａ）仮想マシン３５０ａ用の仮想ＣＰＵの第１コアに割り当てられている物理ＣＰＵの第１コアが、今回の単位時間の間（つまり時刻ｔから時刻（ｔ＋１）までの期間）は１ＧＨｚで動作していた。
（２７ｂ）物理ＣＰＵの第１コアの、仮想マシン３５０ａに起因する使用率（つまりＯＳ３５１ａとアプリケーション３５２ａに起因する使用率）は、今回の単位時間において１００％であった。
（２７ｃ）仮想マシン３５０ａ用の仮想ＣＰＵの第２コアに割り当てられている物理ＣＰＵの第２コアが、今回の単位時間の間は５００ＭＨｚで動作していた。
（２７ｄ）物理ＣＰＵの第２コアの、仮想マシン３５０ａに起因する使用率は、今回の単位時間において１００％であった。
（２７ｅ）仮想マシン３５０ａ用の仮想ＧＰＵに割り当てられている物理ＧＰＵの第１コアは、今回の単位時間の間は通常モードで動作していた。
（２７ｆ）ＷｉＦｉモジュール２１６を介して今回の単位時間の間に行われた通信のうち、仮想マシン３５０ａが送信元または送信先である通信のデータ量は、１０００ｋＢ（＝１０００［ｋＢ／ｈ］×１［ｈ］）であった。

そして、ステップＳ１０４の実行のタイミングとステップＳ１１６の実行のタイミングの差はごくわずかであるから、ステップＳ１１６もほぼ時刻（ｔ＋１）に実行されると見なせる。つまり、ほぼ時刻（ｔ＋１）にステップＳ１１６で、計算部３４３は、（２７ａ）〜（２７ｆ）に示した値を含む使用状況情報３４４を用いて、電力ｃ_１を１３．５Ｗと計算する。

計算部３４３が電力ｃ_１を計算する具体的な方法は、（２１ａ）〜（２１ｄ）を参照して説明したように、加算を含む。つまり、計算部３４３は、各物理デバイスに対応する電力から電力ｃ_１を計算する。計算部３４３は、例えば上記の仮定（２０ｃ)、(２０ｄ）、（２０ｇ）、（２０ｈ）、（２０ｊ）などに例示したような特定の電力計算モデルにしたがって、各物理デバイスに対応する電力を計算する。

もちろん、計算部３４３は、実施形態に合った電力計算モデルを表す適宜の式にしたがって、各物理デバイスに対応する電力および合計の電力ｃ_１を計算することが好ましい。例えば、計算部３４３は、上記（２０ｄ）の方法（つまり、クロック周波数に応じた電力に、単に使用率を掛ける方法）とは異なる方法にしたがって、物理ＣＰＵコア用の電力を計算してもよい。

電力ｃ_１と同様に、計算部３４３は、ほぼ時刻（ｔ＋１）にステップＳ１１６で、電力ｃ_２も計算する。そして、計算部３４３は、電力ｃ_１とｃ_２を使って、新たな仮想残量値ｒ_１を計算する。

また、図７に示すように、ステップＳ１１６は各ＯＳに対応して実行される。つまり、計算部３４３は、新たな仮想残量値ｒ_２も同様に計算する。ここで、図７のステップＳ１１５〜Ｓ１２６の繰り返しループの実行にかかる時間はごくわずかである。よって、「ほぼ時刻（ｔ＋１）には、新たな仮想残量値ｒ_１とｒ_２が、計算され、必要に応じて再評価され、ＯＳ３５１ａと３５１ｂにそれぞれ通知される」と見なせる。

ここで、図８〜９の各計算例のテーブルでは、時刻ｔから時刻（ｔ＋１）の期間における電力は、時刻ｔの行に書かれている。よって、以上のようにしてほぼ時刻（ｔ＋１）にステップＳ１１６で計算された電力ｃ_１を示す「１３．５Ｗ」という値が、図８〜９の各計算例のテーブルでは、時刻ｔの行に書かれている。

よって、上記（２６ａ）に要約したとおり、時刻ｔの行の仮想残量値ｒ_１が２０Ｗｈ以上の場合、同じ行の電力ｃ_１は１３．５Ｗである。上記（２６ｂ）〜（２６ｆ）の各々についても同様に、「計算例６０２〜６０５における電力ｃ_１とｃ_２は、計算部３４３による計算結果を示している」とも言える。

ところで、上記のとおり、計算例６０４と６０５は、式（５）を利用する例である。より具体的には、計算例６０４と６０５は、式（５）においてＴ＝２の場合の例である。

ところが、ｔ＝１のときには、直近の期間（つまりｔ＝０からｔ＝１までの単位時間）の使用状況情報３４４しか蓄積されておらず、直近からＴ番目（つまり直近から２番目）の期間の使用状況情報３４４は未蓄積である。そのため、計算例６０４と６０５のｔ＝１の行における仮想残量値ｒ_１とｒ_２は、Ｔ＝１と見なして式（５）にしたがって計算された値（換言すれば、式（２）にしたがって計算された値）である。

つまり、計算部３４３は、式（５）を利用する場合であっても、所定の個数（Ｔ個）の期間にそれぞれ対応する使用状況情報３４４が蓄積されるまでは、Ｔ個未満の期間の使用状況情報３４４のみを利用して仮想残量値を計算してもよい。

続いて、第３〜第５実施形態について図１０〜１３を参照して説明する。なお、以下の説明においては、第２実施形態との共通点に関しては、図３〜７での参照符号を用いて説明を行うことがある。

第３実施形態は、図３のハイパーバイザ３２０が図１１の処理を実行する点において第２実施形態と異なる。しかし、他の点では、第３実施形態は第２実施形態と同様である。

また、第４実施形態は、ハイパーバイザ３２０が図１１の処理の代わりに図１２の処理を行う点で第３実施形態と異なる。しかし、他の点では、第４実施形態は第３実施形態と同じである。

第５実施形態は、第４実施形態と類似だが、第５実施形態の仮想電池ドライバ３４０では、計算部３４３とプロファイラ３４１ａ〜３４１ｂが省略される。よって、第５実施形態では、計算部３４３が使う各種情報（つまり、使用状況情報３４４、優先度情報３４５、モード情報３４６、およびフラグ３４７）も省略される。その代わり、第５実施形態では、取得部３４２が、取得した物理残量値ＲをＯＳ３５１ａと３５１ｂのそれぞれに通知する。通知は、所定の間隔で行われてもよい。

以下では、まず第３〜第５実施形態の共通点について説明する。
第３〜第５実施形態では、複数の仮想マシン３５０ａ〜３５０ｂの各々にハイパーバイザ３２０が提供する仮想ハードウェアの構成が、電池３１１の物理残量値または仮想残量値に応じて、動的に変更される。換言すれば、第３〜第５実施形態では、ハイパーバイザ３２０が、物理残量値または仮想残量値に応じて、仮想ハードウェア要素のホットアドまたはホットリムーブを実行する。

ホットリムーブされた仮想ハードウェア要素は、仮想マシンからアクセスされない。したがって、ハイパーバイザ３２０は、ホットリムーブした仮想ハードウェア要素（例えば仮想ＣＰＵ）に今まで割り当てていた物理ハードウェア要素（例えば物理ＣＰＵ内のコア）への電力供給を、遮断してもよい。物理ハードウェア要素への電力供給を断つことにより、情報処理装置３００全体での消費電力量は低減する。

もちろん、複数の仮想マシンそれぞれの仮想ハードウェア要素に、同じ１つの物理ハードウェア要素が割り当てられている場合もあり得る。この場合、ハイパーバイザ３２０は、ある１つの仮想マシンから仮想ハードウェア要素をホットリムーブしたら、ホットリムーブした仮想ハードウェア要素に割り当てている物理ハードウェア要素の動作周波数を、下げてもよい。動作周波数の低減により、消費電力量も低減する。

このように、第３〜第５実施形態では、仮想ハードウェア構成の動的な変更により、情報処理装置３００全体での消費電力量の削減が図られる。消費電力量の削減により、電池３１１は長持ちする（つまり、情報処理装置３００の可用時間が長くなる）。以下、図１０〜１３を参照して、第３〜第５実施形態についてさらに詳しく説明する。

図１０は、第３〜第５実施形態で使われる割り当てルールの例を示す図である。全仮想マシンに共通の割り当てルールが使われてもよいし、仮想マシンごとに異なる割り当てルールが使われてもよい。第３〜第５実施形態では、仮想マシンごとに異なる割り当てルールが使われる。

割り当てルールは、各仮想ハードウェア要素を仮想マシンに対して提供するか否かを電池残量ごとに規定するルールである。実施形態によって、割り当てルールの定義に使われる電池残量は、仮想残量でもよいし、物理残量でもよい。具体的には、第３実施形態では仮想残量が使われ、第４実施形態と第５実施形態では物理残量が使われる。

図１０では、仮想ハードウェア要素として、ＣＰＵの第１〜第２コア、ＧＰＵの第１〜第４コア、ＵＳＢコントローラ、およびＷｉＦｉモジュールが例示されている。もちろん、ディスプレイやスピーカなどの他の仮想ハードウェア要素がさらにあってもよいが、説明の便宜上図１０では、他のハードウェア要素はまとめて「その他」と表されている。

なお、図１０の例では、割り当てルール７０１と７０２のいずれにおいても、メモリの割り当てについて明示はされていない。しかし、図１０の例では、「メモリは電池残量によらず常にどの仮想マシンに対しても提供される」と暗黙的に予め決められているものとする。実施形態によっては、各仮想マシンに割り当てるメモリの容量を電池残量に応じて変更するために、割り当てルールで定義される仮想ハードウェア要素の１つが仮想メモリモジュールであってもよい。

また、紙幅の都合上、図１０ではＵＳＢコントローラが「ＵＳＢ」と略記され、ＷｉＦｉモジュールが「ＷｉＦｉ」と略記されている。なお、誤解のおそれはないので、図１０とその説明においては、例えば仮想ＣＰＵコアを単に「ＣＰＵの第１コア」などと表記している。

また、図１０では、ハイパーバイザ３２０が仮想ハードウェア要素を仮想マシンに対して提供することが「○」印により表されている。逆に、ハイパーバイザ３２０が仮想ハードウェア要素を仮想マシンに対して提供しないことは、「×」印により表されている。

例えば、割り当てルール７０１は仮想マシン３５０ａ用のルールであり、割り当てルール７０２は仮想マシン３５０ｂ用のルールである。

割り当てルール７０１によれば、電池残量が３０Ｗｈ以上のとき、ハイパーバイザ３２０は、仮想マシン３５０ａに以下の（２８ａ）〜（２８ｆ）の仮想ハードウェア要素をすべて提供する。

（２８ａ）ＣＰＵの第１〜第２コア
（２８ｂ）ＧＰＵの第１〜第４コア
（２８ｃ）ＵＳＢコントローラ
（２８ｄ）ＷｉＦｉモジュール
（２８ｅ）「その他」に分類される仮想ハードウェア要素
（２８ｆ）メモリ

また、割り当てルール７０１によれば、電池残量が１０Ｗｈ以上３０Ｗｈ未満のとき、ハイパーバイザ３２０は、仮想マシン３５０ａに以下の（２９ａ）〜（２９ｅ）の仮想ハードウェア要素を提供するが、ＵＳＢコントローラは提供しない。

（２９ａ）ＣＰＵの第１〜第２コア
（２９ｂ）ＧＰＵの第１〜第４コア
（２９ｃ）ＷｉＦｉモジュール
（２９ｄ）「その他」に分類される仮想ハードウェア要素
（２９ｅ）メモリ

そして、割り当てルール７０１によれば、電池残量が１Ｗｈ以上１０Ｗｈ未満のとき、ハイパーバイザ３２０は、仮想マシン３５０ａに以下の（３０ａ）〜（３０ｄ）の仮想ハードウェア要素を提供する。

（３０ａ）ＣＰＵの第１コア
（３０ｂ）ＧＰＵの第１〜第２コア
（３０ｃ）「その他」に分類される仮想ハードウェア要素
（３０ｄ）メモリ

しかし、電池残量が１Ｗｈ以上１０Ｗｈ未満のとき、ハイパーバイザ３２０は、仮想マシン３５０ａに以下の（３１ａ）〜（３１ｄ）の仮想ハードウェア要素を提供しない。

（３１ａ）ＣＰＵの第２コア
（３１ｂ）ＧＰＵの第３〜第４コア
（３１ｃ）ＵＳＢコントローラ
（３１ｄ）ＷｉＦｉモジュール

また、電池残量が１Ｗｈ未満のとき、割り当てルール７０１によれば、ハイパーバイザ３２０は、仮想マシン３５０ａにＣＰＵの第１コアとメモリを提供するが、残りのいかなる仮想ハードウェア要素も提供しない。

ところで、割り当てルール７０２によれば、電池残量が３０Ｗｈ以上のとき、ハイパーバイザ３２０は、仮想マシン３５０ｂに以下の（３２ａ）〜（３２ｆ）の仮想ハードウェア要素をすべて提供する。

（３２ａ）ＣＰＵの第１〜第２コア
（３２ｂ）ＧＰＵの第１〜第４コア
（３２ｃ）ＵＳＢコントローラ
（３２ｄ）ＷｉＦｉモジュール
（３２ｅ）「その他」に分類される仮想ハードウェア要素
（３２ｆ）メモリ

また、割り当てルール７０２によれば、電池残量が１０Ｗｈ以上３０Ｗｈ未満のとき、ハイパーバイザ３２０は、仮想マシン３５０ｂに以下の（３３ａ）〜（３３ｆ）の仮想ハードウェア要素を提供するが、ＣＰＵの第２コアとＧＰＵの第３〜第４コアは提供しない。

（３３ａ）ＣＰＵの第１コア
（３３ｂ）ＧＰＵの第１〜第２コア
（３３ｃ）ＵＳＢコントローラ
（３３ｄ）ＷｉＦｉモジュール
（３３ｅ）「その他」に分類される仮想ハードウェア要素
（３３ｆ）メモリ

そして、割り当てルール７０２によれば、電池残量が１Ｗｈ以上１０Ｗｈ未満のとき、ハイパーバイザ３２０は、仮想マシン３５０ｂに以下の（３４ａ）〜（３４ｆ）の仮想ハードウェア要素を提供するが、ＣＰＵの第２コアとＧＰＵの第２〜第４コアは提供しない。

（３４ａ）ＣＰＵの第１コア
（３４ｂ）ＧＰＵの第１コア
（３４ｃ）ＵＳＢコントローラ
（３４ｄ）ＷｉＦｉモジュール
（３４ｅ）「その他」に分類される仮想ハードウェア要素
（３４ｆ）メモリ

また、電池残量が１Ｗｈ未満のとき、割り当てルール７０２によれば、ハイパーバイザ３２０は、仮想マシン３５０ｂにＣＰＵの第１コアとメモリを提供するが、残りのいかなる仮想ハードウェア要素も提供しない。

割り当てルール７０１と７０２を比較すると、以下の２つのことが分かる。
第１に、ＯＳ３５１ａと３５１ｂに通知される電池残量値（第３実施形態では仮想残量値、第４〜第５実施形態では物理残量値）が同じ場合、ＣＰＵコアやＧＰＵコアなどの仮想プロセッサ資源は、仮想マシン３５０ａの方により多く割り当てられる傾向がある。つまり、仮想マシン３５０ａは仮想マシン３５０ｂよりも、仮想プロセッサ資源に関して優先されている。

第２に、ＯＳ３５１ａと３５１ｂに通知される電池残量値が同じ場合、仮想プロセッサ資源以外の仮想ハードウェア資源（具体的にはＵＳＢコントローラとＷｉＦｉモジュール）は、逆に、仮想マシン３５０ｂの方により多く割り当てられる傾向がある。つまり、仮想マシン３５０ｂは仮想マシン３５０ａよりも、ＵＳＢコントローラとＷｉＦｉモジュールといった仮想ハードウェア資源に関して優先されている。

以上のように、仮想ハードウェア要素の種類に応じて、優先される仮想マシンが異なっていてもよい。もちろん、「電池残量値が同じ場合で比較すれば、仮想ハードウェア要素の種類によらず、ある仮想マシンが他の仮想マシンよりも優先される」となるように、割り当てルールが決められていてもよい。

また、図１０の例では、割り当てルール７０１と７０２で、電池残量に関して同じ「３０Ｗｈ以上」・「１０Ｗｈ以上３０Ｗｈ未満」・「１Ｗｈ以上１０Ｗｈ未満」・「１Ｗｈ未満」という条件が使われている。しかし、割り当てルール７０１と７０２で電池残量に関する異なる条件が使われてもよい。

さて次に、第３実施形態でハイパーバイザ３２０が行う処理ついて、図１１のフローチャートを参照して説明する。ハイパーバイザ３２０は、例えば仮想マシン３５０ａと３５０ｂを動作させるための初期化などの処理を終えた後、図１１の処理を開始してもよい。ハイパーバイザ３２０は、他の処理（例えばハイパーバイザコールへの応答など）と並行して、図１１の処理を実行する。

ステップＳ２０１でハイパーバイザ３２０は、インデックス変数ｋに１を代入することで、インデックス変数ｋを初期化する。

次に、ステップＳ２０２でハイパーバイザ３２０は、仮想電池ドライバ３４０の計算部３４３から、ｋ番目のＯＳに関して計算部３４３が計算した最新の仮想残量値ｒ_ｋを取得する。なお、第３実施形態の計算部３４３は、ハイパーバイザ３２０からの要求に備えて、計算した仮想残量値ｒ_ｋを例えばメモリ２１１に記憶しておく。

次に、ステップＳ２０３でハイパーバイザ３２０は、ハイパーバイザ３２０がｋ番目の仮想マシンに提供する仮想ハードウェアの構成を、仮想残量値ｒ_ｋと割り当てルールにしたがって決定する。そして、ハイパーバイザ３２０は、決定にしたがって、必要に応じてｋ番目の仮想マシンの仮想ハードウェアの構成を変更する。

例えば、ｋ番目の仮想マシンが仮想マシン３５０ａであり、仮想残量値ｒ_ｋが１５Ｗｈである場合、ハイパーバイザ３２０は、仮想マシン３５０ａ用の割り当てルール７０１を参照する。１０≦１５＜３０なので、ハイパーバイザ３２０は、仮想マシン３５０ａに以下の（３５ａ）〜（３５ｅ）の仮想ハードウェア要素を提供することに決定するとともに、仮想マシン３５０ａにＵＳＢコントローラを提供しないことに決定する。

（３５ａ）ＣＰＵの第１〜第２コア
（３５ｂ）ＧＰＵの第１〜第４コア
（３５ｃ）ＷｉＦｉモジュール
（３５ｄ）「その他」に分類される仮想ハードウェア要素
（３５ｅ）メモリ

そして、ハイパーバイザ３２０は、上記決定にしたがって、仮想マシン３５０ａに提供する仮想ハードウェアの構成を必要に応じて変更する。

例えば、現在ハイパーバイザ３２０が仮想マシン３５０ａに提供している仮想ハードウェアの構成が、上記で決定した構成と同じ場合があり得る。この場合、ハイパーバイザ３２０は仮想ハードウェアの構成を変えない。

また、上記のようにしてハイパーバイザ３２０が仮想マシン３５０ａに提供することに決定した仮想ハードウェア要素の中に、現在ハイパーバイザ３２０が仮想マシン３５０ａに提供していないものがある場合もあり得る。

この場合、ハイパーバイザ３２０は、当該仮想ハードウェア要素のホットアドを行う。すなわち、ハイパーバイザ３２０は、当該仮想ハードウェア要素を仮想マシン３５０ａに提供し始める。例えば、電池３１１の充電が進行中のときなどに、以上のようなホットアドが行われる可能性がある。

例えば、以下の（３６ａ）と（３６ｂ）の２つの条件がともに成り立つ場合、ハイパーバイザ３２０は、ＧＰＵの第３コアのホットアドを行う。

（３６ａ）ハイパーバイザ３２０は、現在はＧＰＵの第３コアを仮想マシン３５０ａに提供していない。
（３６ｂ）ハイパーバイザ３２０は、上記のように割り当てルール７０１にしたがって、ＧＰＵの第３コアを仮想マシン３５０ａに提供することに決定した。

逆に、上記のようにしてハイパーバイザ３２０が仮想マシン３５０ａに提供しないことに決定した仮想ハードウェア要素の中に、現在ハイパーバイザ３２０が仮想マシン３５０ａに提供しているものがある場合もあり得る。

この場合、ハイパーバイザ３２０は、当該仮想ハードウェア要素のホットリムーブを行う。すなわち、ハイパーバイザ３２０は、当該仮想ハードウェア要素の仮想マシン３５０ａへの提供を停止する。例えば、ユーザが、電池３１１の充電を行わずにある程度長い時間にわたって情報処理装置３００を利用し続けると、以上のようなホットリムーブが行われる可能性がある。

例えば、以下の（３７ａ）と（３７ｂ）の２つの条件がともに成り立つ場合、ハイパーバイザ３２０は、ＵＳＢコントローラのホットリムーブを行う。

（３７ａ）ハイパーバイザ３２０は、現在はＵＳＢコントローラを仮想マシン３５０ａに提供している。
（３７ｂ）ハイパーバイザ３２０は、上記のように割り当てルール７０１にしたがって、ＵＳＢコントローラを仮想マシン３５０ａに提供しないことに決定した。

なお、仮想ハードウェア要素の種類に応じて、ハイパーバイザ３２０はホットリムーブにともなう適宜の処理をさらに行うこともある。例えば、ハイパーバイザ３２０は、仮想ＣＰＵコアをホットリムーブする前に、当該仮想ＣＰＵコアに割り当てられた物理ＣＰＵコア内のレジスタに記憶されているデータを退避してもよい。

以上のとおり、ステップＳ２０３では、ｋ番目の仮想マシンの現在の仮想ハードウェア構成と、ｋ番目の仮想マシン用の割り当てルールと、仮想残量値ｒ_ｋに基づいて、ｋ番目の仮想マシンの仮想ハードウェア構成が、必要に応じて変更される。

そして、次のステップＳ２０４でハイパーバイザ３２０は、インデックス変数ｋの値と、情報処理装置３００内の仮想マシンの数Ｎを比較する。

もし、ｋ＜Ｎであれば、仮想ハードウェア構成を変更するか否かをまだ決めていない仮想マシンが残っている。そこで、図１１の処理はステップＳ２０４からステップＳ２０５へと移行する。

逆に、ｋ≧Ｎであれば（具体的にはｋ＝Ｎであれば）、すべての仮想マシンの仮想ハードウェア構成が決定済みである。そこで、図１１の処理はステップＳ２０４からステップＳ２０６へと移行する。

ステップＳ２０５でハイパーバイザ３２０は、インデックス変数ｋを１だけインクリメントする。そして、図１１の処理はステップＳ２０２へと戻る。

他方、ステップＳ２０６でハイパーバイザ３２０は、所定の時間が経過するまで待つ。そして、所定の時間が経過すると、図１１の処理はステップＳ２０１へと戻る。なお、所定の時間の長さは任意だが、所定の時間は、図６〜７のステップＳ１０２における単位時間以上であることが好ましい。

以上、図１１を参照して説明したとおり、第３実施形態では、ハイパーバイザ３２０が各仮想マシンに関して仮想残量値を定期的に監視し、当該仮想マシンにハイパーバイザ３２０が提供する仮想ハードウェアの構成を、仮想残量値に応じて動的に変更する。したがって、仮に各仮想マシン上の各ＯＳが省電力制御を行わないとしても、第３実施形態によれば、ホットリムーブの結果として、消費電力量が低減される。その結果、情報処理装置３００全体としては、電池３１１が一層長持ちする。

また、仮想マシンの用途に応じた割り当てルールの利用により、情報処理装置３００全体としてはバランスのよい電力使用が実現される。例えば、プロセッサ資源を多く使う用途に使われる仮想マシンと、通信資源を多く使う用途に使われる仮想マシンに異なる割り当てルールが適用されてもよい。仮想マシンの用途に応じた割り当てルールの適用により、各仮想マシンからは、当該仮想マシンにとって優先度の低い仮想ハードウェア要素ほど先に削除されることになる。つまり、利便性の維持と節電効果のバランスをとるために、仮想マシンの用途に応じた割り当てルールを用いられてもよい。

続いて、第４〜第５実施形態でハイパーバイザ３２０が行う処理について、図１２のフローチャートを参照して説明する。

ステップＳ３０１でハイパーバイザ３２０は、電池Ｉ／Ｆ２０３から物理残量値Ｒを取得する。

次にステップＳ３０２でハイパーバイザ３２０は、インデックス変数ｋに１を代入することで、インデックス変数ｋを初期化する。

次に、ステップＳ３０３でハイパーバイザ３２０は、ハイパーバイザ３２０がｋ番目の仮想マシンに提供する仮想ハードウェアの構成を、物理残量値Ｒと割り当てルールにしたがって決定する。そして、ハイパーバイザ３２０は、決定にしたがって、必要に応じてｋ番目の仮想マシンの仮想ハードウェアの構成を変更する。なお、ステップＳ３０３は、決定に際して仮想残量値ｒ_ｋではなく物理残量値Ｒが使われる点以外は、図１１のステップＳ２０３と同様である。よって、詳しい説明は省略する。

次のステップＳ３０４でハイパーバイザ３２０は、インデックス変数ｋの値と、情報処理装置３００内の仮想マシンの数Ｎを比較する。

もし、ｋ＜Ｎであれば、仮想ハードウェア構成を変更するか否かをまだ決めていない仮想マシンが残っている。そこで、図１２の処理はステップＳ３０４からステップＳ３０５へと移行する。

逆に、ｋ≧Ｎであれば（具体的にはｋ＝Ｎであれば）、すべての仮想マシンの仮想ハードウェア構成が決定済みである。そこで、図１２の処理はステップＳ３０４からステップＳ３０６へと移行する。

ステップＳ３０５でハイパーバイザ３２０は、インデックス変数ｋを１だけインクリメントする。そして、図１２の処理はステップＳ３０３へと戻る。

他方、ステップＳ３０６でハイパーバイザ３２０は、所定の時間が経過するまで待つ。そして、所定の時間が経過すると、図１２の処理はステップＳ３０１へと戻る。なお、所定の時間の長さは任意だが、所定の時間は、図６〜７のステップＳ１０２における単位時間以上であることが好ましい。

以上、図１２を参照して説明したとおり、第４〜第５実施形態では、ハイパーバイザ３２０が電池３１１の物理的な残量を定期的に監視し、各仮想マシンにハイパーバイザ３２０が提供する仮想ハードウェアの構成を、電池３１１の物理的な残量に応じて動的に変更する。したがって、仮に各仮想マシン上の各ＯＳが省電力制御を行わないとしても、第４〜第５実施形態によれば、ホットリムーブの結果として、消費電力量が低減される。その結果、情報処理装置３００全体としては、電池３１１が一層長持ちする。

また、第５実施形態では仮想残量値が使われないが、第５実施形態においても、「ハイパーバイザ上で複数のＯＳが動作する場合にも、情報処理装置全体として適切に電力が使用される」という効果が得られる。具体的には、仮想マシンの用途に応じた割り当てルールの利用により、当該効果が得られる。なぜなら、第３実施形態に関して説明した「仮想マシンの用途に応じた割り当てルールの利用により、利便性の維持と節電効果のバランスがとれる」という効果は、第４実施形態および第５実施形態でも同様だからである。

さて、図１３は、仮想ハードウェアの動的な構成変更の効果を説明する図である。具体的には、図１３には、ハイパーバイザ３２０が仮想ハードウェアの構成を動的に変更することのない第４比較例についての計算例８０１と、第５実施形態についての計算例８０２が例示されている。

以下では説明の簡単化のため、図２のＣＰＵ２０４とＧＰＵ２０５とＷｉＦｉモジュール２１６による消費電力量の和により、情報処理装置２００全体の消費電力量が近似されるものとする。

また、説明の簡単化のため、ＯＳ３５１ａと３５１ｂが何も省電力制御を行わないと仮定する。換言すれば、ＯＳ３５１ａと３５１ｂは、いずれも、次の(３８ａ）〜（３８ｃ）のようなルールセットにしたがうものとする。

（３８ａ）電池の残量によらず、すべてのＣＰＵコアを、ＣＰＵコアに設定可能な最大周波数（説明の便宜上１ＧＨｚとする）で動作させる。
（３８ｂ）電池の残量によらず、すべてのＧＰＵコアを稼働させておく。
（３８ｃ）電池の残量によらず、ＷｉＦｉモジュールを介した通信の量は無制限である。

また、説明の簡単化のため、情報処理装置３００にはデュアルコアの物理ＣＰＵとクアッドコアの物理ＧＰＵがあるとする。

そして、仮想マシン３５０ａ用の仮想ＣＰＵの第１コアと仮想マシン３５０ｂ用の仮想ＣＰＵの第１コアには、物理ＣＰＵの第１コアが割り当て可能だとする。同様に、仮想マシン３５０ａ用の仮想ＣＰＵの第２コアと仮想マシン３５０ｂ用の仮想ＣＰＵの第２コアには、物理ＣＰＵの第２コアが割り当て可能だとする。

ＧＰＵについても同様に、仮想マシン３５０ａ用の仮想ＧＰＵの第ｍコアと仮想マシン３５０ｂ用の仮想ＧＰＵの第ｍコアには、物理ＣＰＵの第ｍコアが割り当て可能だとする（ｍ＝１〜４）。

さらに、各物理ＣＰＵコアが１ＧＨｚで動作するための電力は、１Ｗであるものとする。また、各物理ＧＰＵコアが動作するための電力は、２Ｗであるものとする。そして、或る期間に物理ＣＰＵコアによって消費される電力量は、当該期間における物理ＣＰＵコアの使用率に比例するものとする。

さて、図１３における記号「ｔ」と「Ｒ」と「ｃ_１」と「ｃ_２」は、図８〜９と同様である。また、図１３では、仮想ハードウェア要素がホットリムーブされるタイミングを、太い横罫線により示している。

図１３の計算例８０１と８０２それぞれのテーブルにおいて、時刻ｔの行の「ｕ_１」は、時刻ｔから時刻（ｔ＋１）までの単位時間の間における、仮想マシン３５０ａの動作に起因する物理ＣＰＵコアの使用率を示す。説明の簡単化のため、仮想マシン３５０ａ用の仮想ＣＰＵコアに割り当てられているどの物理ＣＰＵコアの使用率も、同じ率ｕ_１であるものとする。

同様に、時刻ｔの行の「ｕ_２」は、時刻ｔから時刻（ｔ＋１）までの単位時間の間における、仮想マシン３５０ｂの動作に起因する物理ＣＰＵコアの使用率を示す。説明の簡単化のため、仮想マシン３５０ｂ用の仮想ＣＰＵコアに割り当てられているどの物理ＣＰＵコアの使用率も、同じ率ｕ_２であるものとする。

ところで、時刻ｔの行の「ｗ_１」は、仮想マシン３５０ａの仮想ＷｉＦｉモジュールを介して行われる通信の、時刻ｔから時刻（ｔ＋１）までの期間における平均データレートを示す。同様に、時刻ｔの行の「ｗ_２」は、仮想マシン３５０ｂの仮想ＷｉＦｉモジュールを介して行われる通信の、時刻ｔから時刻（ｔ＋１）までの期間における平均データレートを示す。データレートｗ_１とｗ_２の単位はいずれも［ｋＢ／ｈ］である。

仮想マシン３５０ａから仮想ＷｉＦｉモジュールがホットリムーブされた場合は、当然ｗ_１＝０である。同様に、仮想マシン３５０ｂから仮想ＷｉＦｉモジュールがホットリムーブされた場合は、ｗ_２＝０である。

さて、説明の便宜上、時刻ｔにおいてハイパーバイザ３２０が仮想マシン３５０ａに提供している仮想ＣＰＵコアの数を「ｎ_１」とする。また、時刻ｔにおいてハイパーバイザ３２０が仮想マシン３５０ａに提供している仮想ＧＰＵコアの数を「ｍ_１」とする。

同様に、時刻ｔにおいてハイパーバイザ３２０が仮想マシン３５０ｂに提供している仮想ＣＰＵコアの数を「ｎ_２」とする。また、時刻ｔにおいてハイパーバイザ３２０が仮想マシン３５０ｂに提供している仮想ＧＰＵコアの数を「ｍ_２」とする。

すると、以上説明した仮定より、電力ｃ_１とｃ_２は、式（１０）と（１１）のように表すことができる。

また、時刻ｔから時刻（ｔ＋１）までの単位時間における消費電力量は、「（ｃ_１＋ｃ_２）×１」と表すことができる。計算例８０１および８０２それぞれにおいて、時刻（ｔ＋１）における物理残量値Ｒは、時刻ｔにおける物理残量値Ｒから、この「（ｃ_１＋ｃ_２）×１」という消費電力量を引いた値である。

式（１０）によれば、例えば計算例８０１の各行に示すように、ｕ_１＝５０かつｗ_１＝６５かつｎ_１＝２かつｍ_１＝４の場合は、ｃ_１＝９．６５である。また、式（１１）によれば、計算例８０１の各行に示すように、ｕ_２＝２５かつｗ_２＝１００かつｎ_２＝２かつｍ_２＝４の場合は、ｃ_２＝９．５である。

計算例８０１は、上記のとおり、ハイパーバイザ３２０がホットリムーブを行わない第４比較例についての例である。よって、計算例８０１では、物理残量値Ｒが減少しても、物理残量値Ｒが大きかったときと同様に大きな電力が使われてしまう。そのため、計算例８０１では、時刻ｔ＝６のときには既に電池切れになっている。

他方、第５実施形態による計算例８０２では、時刻ｔ＝６ではまだ電池切れになっておらず、電池３１１がより長持ちしている。具体的には、第５実施形態では、物理残量値Ｒの減少に応じて、仮想マシン３５０ａから仮想ハードウェア要素が動的に削除され、仮想マシン３５０ｂからも仮想ハードウェア要素が動的に削除される。そのため、動的に削除される仮想ハードウェア要素に割り当てられていた物理ハードウェア要素の消費電力量の分、第５実施形態では情報処理装置３００の消費電力量が第４比較例よりも少ない。その結果として、図１３に示すように、電池３１１が長持ちする。

例えば、物理残量値Ｒが１０Ｗｈ以上の場合（具体的には、計算例８０２のｔ＝０からｔ＝４の行においては）、割り当てルール７０１よりｎ_１＝２かつｍ_１＝４である。よって、この場合、計算例８０２に示した使用率ｕ_１とデータレートｗ_１によれば、ｃ_１＝９．６５である。

しかし、物理残量値Ｒが１Ｗｈ以上１０Ｗｈ未満の場合（具体的には、計算例８０２のｔ＝５の行においては）、割り当てルール７０１よりｎ_１＝１かつｍ_１＝２かつｗ_１＝０である。よって、この場合、計算例８０２に示した使用率ｕ_１によれば、ｃ_１＝４．５である。

また、物理残量値Ｒが１Ｗｈ未満の場合（具体的には、計算例８０２のｔ＝６の行においては）、割り当てルール７０１よりｎ_１＝１かつｍ_１＝０かつｗ_１＝０である。よって、この場合、計算例８０２に示した使用率ｕ_１によれば、ｃ_１＝０．５である。

以上のように、物理残量値Ｒの減少に応じて、仮想マシン３５０ａから仮想ハードウェア要素が動的に削除され、仮想マシン３５０ａの実行にかかる電力が抑えられる。仮想マシン３５０ｂに関しても同様である。

例えば、物理残量値Ｒが３０Ｗｈ以上の場合（具体的には、計算例８０２のｔ＝０からｔ＝３の行においては）、割り当てルール７０２よりｎ_２＝２かつｍ_２＝４である。よって、この場合、計算例８０２に示した使用率ｕ_２とデータレートｗ_２によれば、ｃ_２＝９．５である。

また、物理残量値Ｒが１０Ｗｈ以上３０Ｗｈ未満の場合（具体的には、計算例８０２のｔ＝４の行においては）、割り当てルール７０２よりｎ_２＝１かつｍ_２＝２である。よって、この場合、計算例８０２に示した使用率ｕ_２とデータレートｗ_２によれば、ｃ_２＝５．２５である。

そして、物理残量値Ｒが１Ｗｈ以上１０Ｗｈ未満の場合（具体的には、計算例８０２のｔ＝５の行においては）、割り当てルール７０２よりｎ_２＝１かつｍ_２＝１である。よって、この場合、計算例８０２に示した使用率ｕ_２とデータレートｗ_２によれば、ｃ_２＝３．２５である。

また、物理残量値Ｒが１Ｗｈ未満の場合（具体的には、計算例８０２のｔ＝６の行においては）、割り当てルール７０２よりｎ_２＝１かつｍ_２＝０かつｗ_２＝０である。よって、この場合、計算例８０２に示した使用率ｕ_２によれば、ｃ_２＝０．２５である。

以上、図１３を参照して説明したように、たとえＯＳが省電力制御を行わなくても、第５実施形態では、電池３１１が長持ちし、情報処理装置３００の可用時間が第４比較例よりも長い。また、第４実施形態では、第５実施形態と同様のホットリムーブによる節電効果に加えて、さらに、ＯＳが行う省電力制御による節電効果も得られる。そして、第３実施形態では、第４実施形態と同様の節電効果に加えて、例えば次の（３９ａ）〜（３９ｂ）のような効果も得られる。

（３９ａ）物理残量値の代わりに仮想残量値を用いてＯＳが省電力制御を行うことによる、情報処理装置３００全体としての適切な電力配分。
（３９ｂ）適切な電力配分の結果としての更なる節電効果。

なお、本発明は上記の第１〜第５実施形態に限られるものではなく、上記実施形態は様々に変形可能である。以下に、上記実施形態を変形するいくつかの観点を例示する。例えば、上記実施形態は、下記のいくつかの観点から様々に変形することもでき、これらの変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。

図６のステップＳ１０８では、物理残量値Ｒが閾値Ｄｐ未満か否かが判断される。しかし、実施形態によっては、物理残量値Ｒが閾値Ｄｐ以下か否かが判断されてもよい。また、図７のステップＳ１１７では仮想残量値ｒ_ｋが閾値Ｄｖ未満か否かが判断される。しかし、実施形態によっては、仮想残量値ｒ_ｋが閾値Ｄｖ以下か否かが判断されてもよい。

また、各閾値の具体的な値は、実施形態に応じて適宜任意に決められてよい。図４、５、８〜１０、１３に例示した様々な数値も、説明の便宜上の例示的な値に過ぎない。

図４と５には、便宜上、テーブル形式で様々なデータを例示した。しかし、データ形式は実施形態に応じて任意である。例えば、使用状況情報３４４は、リングバッファに記憶されてもよい。また、線形リスト、連想配列、ＣＳＶ（Comma Separated Values）などのデータ形式も利用可能である。実施形態によっては、ルールセット５００、５２０、および５４０は、所定のマークアップ言語にしたがって記述されていてもよい。

また、図１０の割り当てルール７０１と７０２も、実施形態に応じて適宜のデータ形式で表現されていてよい。

第２実施形態では、ＯＳごとにモード情報３４６が定義されているが、全ＯＳのモードが同じでもよい。全ＯＳのモードが同じ場合、モード情報３４６は省略されてもよい。

もちろん、全ＯＳのモードが同じ場合でも、モード情報３４６があってもよい。例えば、３つのモードが選択可能な場合、ユーザからの入力にしたがって、３つのモードのうちの１つを示す値が、モード情報３４６として不揮発性記憶装置２１２に記憶されてもよい。この場合、モード情報３４６は、全ＯＳに共通のモードを示す。つまり、モード情報３４６は、ＯＳごとの特性を表す特性情報ではなく、計算部３４３による計算の方法を指定するための情報として使われてもよい。

なお、選択可能なモードの数は、第２実施形態のように３でもよいし、２でもよいし、４以上であってもよい。例えば、第２実施形態に関して説明した第１〜第３モードのうち２つだけが選択可能な実施形態も可能である。

逆に、第４モードが定義されている実施形態も可能である。例えば、第４モードは、「電池３１１が充電中の場合、ステップＳ１０７で取得された物理残量値ＲとステップＳ１１６で計算された仮想残量値ｒ_ｋに基づいて、計算部３４３が、仮想残量値ｒ_ｋを計算しなおす」というモードであってもよい。例えば、計算部３４３は、物理残量値Ｒと仮に計算された仮想残量値ｒ_ｋとの最大値、最小値、平均値、または重み付け和を、最終的な仮想残量値ｒ_ｋとして計算してもよい。

第２実施形態では、計算部３４３による計算の方法は、モード情報３４６とフラグ３４７に応じて可変である。しかし、上記のとおり実施形態によってはモード情報３４６が省略可能なのと同様に、フラグ３４７も実施形態によっては省略可能である。例えば、フラグ３４７が省略される場合、図６のステップＳ１１３〜Ｓ１１４が省略されてもよい。あるいは、フラグ３４７が省略される場合、図６のステップＳ１１３では電池３１１が充電中か否かだけが判断されてもよく、電池３１１が充電中のときにステップＳ１１４が実行されてもよい。

また、図６のステップＳ１０８〜Ｓ１１２に示すように、物理残量値Ｒが閾値Ｄｐ未満のときに各ＯＳにゼロという仮想残量値が通知されるならば、図７のステップＳ１１７〜Ｓ１１８は省略されてもよい。ステップＳ１１７〜Ｓ１１８が省略される場合、ステップＳ１１６の計算の実行後、処理はステップＳ１１９に移行する。

実施形態によっては逆に、図６のステップＳ１０８〜Ｓ１１２が省略されてもよい。具体的には、図７のステップＳ１１７〜Ｓ１１８のように仮想残量値ｒ_ｋが閾値Ｄｖ未満のときにゼロという仮想残量値が通知されるならば、ステップＳ１０８〜Ｓ１１２が省略されてもよい。ステップＳ１０８〜Ｓ１１２が省略される場合、ステップＳ１０７での物理残量値Ｒの取得の後、処理はステップＳ１１３に移行する。

なお、図６〜７のフローチャートに示したステップの実行順序は、矛盾が生じない限り適宜入れ替えられてもよい。

第２実施形態では、プロファイラ３４１ａおよび３４１ｂ、取得部３４２、ならびに計算部３４３が仮想電池ドライバ３４０内に実装されている。しかし、実施形態によっては、プロファイラ３４１ａおよび３４１ｂ、取得部３４２、ならびに計算部３４３の一部または全部が、ハイパーバイザ３２０内に実装されていてもよい。

また、第２実施形態では、ＯＳ３５１ａに対応してプロファイラ３４１ａが設けられており、ＯＳ３５１ｂに対応してプロファイラ３４１ｂが設けられている。しかし、実施形態によっては、１つのプロファイラのみが設けられていてもよく、１つのプロファイラが各ＯＳについての使用状況情報３４４を生成するとともに、各ＯＳへ仮想残量値を通知してもよい。

第２実施形態では１つの計算部３４３が各ＯＳの仮想残量値を計算するが、実施形態によっては、ＯＳごとに別の計算部が設けられていてもよい。その場合、複数の計算部の各々は、当該計算部に対応するＯＳの仮想残量値のみを計算してもよい。

第２実施形態のプロファイラ３４１ａは、図１の第１の取得部１０５と類似の動作をするだけでなく、通知部１０４と類似の動作をする。しかし、実施形態によっては、プロファイラ３４１ａが、第１の取得部１０５と類似の動作をするコンポーネントと、通知部１０４と類似の動作をするコンポーネントに、分割されてもよい。プロファイラ３４１ｂも同様に、分割されてもよい。

計算部３４３が使用状況情報３４４を使わずに仮想残量値を計算する場合、使用状況情報３４４は省略可能である。この場合、プロファイラ３４１ａと３４１ｂが使用状況情報３４４を生成する必要もない。また、この場合、図６のステップＳ１０３〜Ｓ１０６も省略可能である。

ところで、第３〜第５実施形態の共通点は、「どの仮想マシンについても仮想残量値に基づく制御が行われるか、または、どの仮想マシンについても物理残量値に基づく制御が行われる」という点である。しかし、仮想マシンごとに、「当該仮想マシンの仮想ハードウェアの構成をハイパーバイザが仮想残量値と物理残量値のいずれに応じて変更するのか」ということが決められていてもよい。例えば、ハイパーバイザ３２０は、仮想マシン３５０ａの仮想ハードウェア構成を、仮想マシン３５０ａに対応する仮想残量値ｒ_１に基づいて変更する一方で、仮想マシン３５０ｂの仮想ハードウェア構成を、物理残量値Ｒに基づいて変更してもよい。また、動的に仮想ハードウェア構成を変更しないことに決められている仮想マシンがあってもよい。

１００、２００、３００ 情報処理装置
１０１、２０１、３１１ 電池
１０２ａ、１０２ｂ、３５１ａ、３５１ｂ ＯＳ
１０３ 評価部
１０４ 通知部
１０５ 第１の取得部
１０６ 第２の取得部
２０２ バス・インタコネクト
２０３ 電池Ｉ／Ｆ
２０４ ＣＰＵ
２０５ ＧＰＵ
２０６ タッチパネル
２０７ ＬＣＤ Ｉ／Ｆ
２０８ タッチパネルＩ／Ｆ
２０９ カメラ
２１０ カメラＩ／Ｆ
２１１ メモリ
２１２ 不揮発性記憶装置
２１３、２１７ ＲＦ回路
２１４ 無線Ｉ／Ｆ
２１５ ＵＳＢコントローラ
２１６ ＷｉＦｉモジュール
２１８ ＮＦＣ Ｉ／Ｆ
３１０ ハードウェア
３２０ ハイパーバイザ
３３０ 仮想ドライバ
３４０ 仮想電池ドライバ
３４１ａ、３４１ｂ プロファイラ
３４２ 取得部
３４３ 計算部
３４４ 使用状況情報
３４５ 優先度情報
３４６ モード情報
３４７ フラグ
３５０ａ、３５０ｂ 仮想マシン
３５２ａ、３５２ｂ アプリケーション
４０１ａ、４０１ｂ プロファイル
５００、５２０、５４０ ルールセット
５０１〜５０３、５２１〜５２３、５４１〜５４３ 条件
５０４〜５１０、５２４〜５３０、５４４〜５４８ ルール
６０１〜６０５、８０１、８０２ 計算例
７０１、７０２ 割り当てルール

Claims (10)

1. 電池で駆動される情報処理装置であって、
   前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価する評価部と、
   前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記評価部が評価した値である仮想残量値を通知する通知部と
   を備えることを特徴とする情報処理装置。
2. 前記複数のオペレーティング・システムそれぞれの前記特性情報が、
   当該オペレーティング・システムおよび当該オペレーティング・システム上で動作するアプリケーションにより使用された資源の量を示す使用状況情報と、
   当該オペレーティング・システムの優先度を示す優先度情報
   のうち少なくとも一方を含むことを特徴とする請求項１に記載の情報処理装置。
3. 前記特性情報が、複数の期間のそれぞれと対応づけられた前記使用状況情報を含む
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも１つ以上のそれぞれに対して、前記仮想残量値を、
   当該オペレーティング・システムに対応する前記仮想残量値の定義域の最大値、または
   前記物理残量値の定義域の最大値
   と見なすことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記電池が充電中のとき、前記評価部は、
   前記物理残量値が、前記物理残量値の定義域の最大値であると見なし、
   前記最大値と見なした前記物理残量値を用いて、前記複数のオペレーティング・システムそれぞれに対応する前記仮想残量値を評価する
   ことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
6. 前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも１つ以上のそれぞれに対応する前記仮想残量値を、前記物理残量値と同じと見なす
   ことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
7. 前記複数のオペレーティング・システムのそれぞれが動作する、前記ハイパーバイザ上の各仮想マシンに、前記ハイパーバイザが提供する仮想ハードウェアの構成を、前記ハイパーバイザが、
   前記物理残量値、または
   当該仮想マシン上の当該オペレーティング・システムに対応する前記仮想残量値
   に応じて変更する
   ことを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 電池で駆動される情報処理装置が実行する電池残量通知方法であって、
   前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
   前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
   ことを特徴とする電池残量通知方法。
9. 電池で駆動される情報処理装置に、
   前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
   前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
   ことを含む処理を実行させる電池残量通知プログラム。
10. 前記ハイパーバイザ上で動作する、前記電池のデバイスドライバのプログラムに含まれることを特徴とする請求項９に記載の電池残量通知プログラム。

Images