JP4833560B2 - 常時動作可能なコンピューティングデバイス - Google Patents

Description

本発明は、概して電源管理の分野に関する。より詳細には、本発明は、アプリケーションを実行するオン状態にとどまりながらオフ状態を擬似(simulate)するように、アコースティックエミッションを削減するようにコンピューティングデバイス内の個々のコンポーネントによって電源の使用を制御するシステムおよび方法に関する。

ＰＣの機能が、家庭用電化（ＣＥ）機器の機能、例えば家庭用ビデオ録画（例えば、デジタルビデオレコーダ（ＤＶＲ）、ｅＨｏｍｅ ＰＣなど）に集中し始めると、ＰＣは、書斎やホームオフィスなどの場所からリビングルームに移ることになるので、家庭用娯楽設備（例えば、ＴＶ、ステレオ受信機、セットトップボックスなど）に接続される場合がある。この移動は、ユーザがＣＥ機器と同等の非常に高い信頼性および使いやすさを期待するという点で、ＰＣにとって挑戦課題となる。ＰＣは使いにくく、ハードウェアおよびソフトウェア両方に関して安定性が問題になりがちだったので、ＰＣに対する期待はこれまでＣＥ機器よりはるかに低いものだった。したがって、ＣＥの領域で成功するためには、ＰＣは、従来のＰＣのようにではなく、より電気製品らしく動作しなければならない。

ＰＣは、電源のオンおよびオフに関しても、ＣＥ機器とは大幅に異なる。従来、オフ状態からすぐに使用可能になるためには、ＰＣは低電力のスタンバイ状態（ＡＣＰＩ Ｓ３）におかれる。一般に、この低電力状態は、ＰＣが２秒足らずで電源をオンにすることを可能にする。ただし、ＰＣが低電力状態である間、ＰＣが実施し得る唯一のアクションは、ＰＣが他の機能を実施し得るようにシステムを完全な「オン」状態（ＡＣＰＩ Ｓ０）に起動することである。さらに、Ｓ３と「オン」の間の待ち時間は、多くの要因、すなわちハードウェアおよびソフトウェア両方に依存する。あるときは電源を入れるのに２秒未満しかかからないが、次のときには５秒か７秒かかる場合もあり得る。このため、ＰＣの低電力スタンバイ状態は、ユーザがＣＥ機器に対して期待する瞬時のオン動作を提供することができない。

"System Management Bus (SMBus）Specification," Version 2.0, August 3, 2000, published by the SBS Implementers Forum section 4.3 of the ATX Specification, version 2.2 section 8.3.3 of the Advanced Configuration and Power Interface Specification section 8.1.1 of the ACPI specification

したがって、ＰＣを省電力状態から完全な「オン」状態に復元し、ＰＣが省電力状態において特定の機能を実施し得る改良型システムが必要である。本発明は、このようなソリューションを提供する。

本発明は、コンピューティングデバイスにおいて擬似オフ状態(a simulated off condition)をもたらすシステムおよび方法を対象とする。第１の態様によると、１組のソフトウェア拡張により、コンピューティングデバイスにおいて擬似オフ状態を作り出す方法が提供される。この方法は、管理される各コンポーネント用にデバイスドライバを提供すること、コンピューティングデバイスの電源状態を判定するために、デバイスドライバからの情報を調整するためのポリシードライバを提供すること、コンピューティングデバイスの電源状態を変えるための信号を受信すること、およびその信号に従ってそれぞれの電源状態を変えるようシステムコンポーネントに命令することを含む。信号が、低電力状態に入らせる要求を表す場合、システムコンポーネントの電力消費は削減され、そうすることによって、コンピューティングデバイスは擬似オフ状態に入る。ただし、コンピューティングデバイスが擬似オフ状態にあるとき、コンピューティングシステムは完全にオンのままであり、システムコンポーネントはアプリケーションの実行を可能にしたままである。信号が完全にオンの電源状態に入らせる要求を表す場合、システムは完全にオンの電源状態に戻される。

本発明の特徴によると、ヒューマンインターフェースデバイスは、入力を破棄することによってロックされ、上述した信号を表す予め定義された入力シーケンスが検出され得る。さらに、ポリシーは状態情報を求めて各デバイスドライバを定期的にポーリングすることができる。また、システム内のプロセッサに最低状態までクロックを下げるよう命令し、ディスプレイ信号を切ってモニタをオフにし、電源出力を削減し、冷却ファンをオフにし、コンピューティングデバイスが擬似オフ状態にあることを示すシステムサービスが提供される。

本発明の別の態様によると、擬似オフ状態を有するコンピューティングデバイスが提供される。この装置は、電源を通る気流の向きと合致する第１のフィン配向、および乱気流を誘導するための第１のクロスカットを有する電源ヒートシンクを有する電源と、２種類の金属からなる外側部およびベースを有するＣＰＵヒートシンクを有する中央処理装置と、画像処理装置上方の気流の向きと合致する第２のフィン配向を有するＧＰＵヒートシンク、および乱気流を誘導するための第２のクロスカットを有する画像処理装置と、ハードディスクドライブと、ランダムアクセスメモリとを含む。コンピューティングデバイスが電源をパワーダウンされると、コンピューティングデバイスがオフに見えるようにシステムコンポーネントを低電力状態におくことによって、コンピューティングデバイスは擬似オフ状態におかれる。本発明のこの態様によると、コンピューティングデバイスは、擬似オフ状態にある場合、引き続きアプリケーションを実行することが可能であり続ける。

本発明の別の態様によると、コンピューティングデバイスがＡＣＰＩ Ｓ０状態にあるとき、コンピューティングデバイスにおいて擬似オフ状態を作り出す方法が提供される。この方法は、管理される各コンポーネント用にデバイスドライバを提供すること、コンピューティングデバイスの電源状態を判定するためにデバイスドライバからの情報を調整するためのポリシードライバを提供すること、コンピューティングデバイスの電源状態を変えるための信号を受信すること、および信号に従ってそれぞれの電源状態を変えるようシステムコンポーネントに命令することを含む。信号が、低電力状態に入らせる要求を表す場合、システムコンポーネントの電力消費はＡＣＰＩメソッドを用いて削減され、そうすることによって、コンピューティングデバイスは擬似オフ状態に入る。コンピューティングデバイスが擬似オフ状態にあるとき、コンピューティングシステムは完全にオンのままであり、システムコンポーネントは引き続きアプリケーションを実行することが可能であり続ける。ただし、信号が完全にオンの電源状態に入らせる要求を表す場合、システムコンポーネントはＡＣＰＩメソッドを用いて完全にオンの電源状態に戻される。

本発明のそれ以外の特徴および利点が、添付の図面を参照して進行する、例示的な実施形態の以下の詳細な説明から明らかにされるであろう。

上述の要約、ならびに以下の好ましい実施形態の詳細な説明は、添付の図面と併せ読まれるとよりよく理解されよう。本発明を説明するために、本発明の例示的な構成が図面に示される。ただし、本発明は、開示される特定の方法および手段に限定されない。

（例示的な計算機環境）
図１は、本発明が実施され得る、適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切な計算機環境の一例に過ぎず、本発明の使用または機能の範囲に対するどのような限定を示唆することも意図されない。計算機環境１００は、例示的な動作環境１００に示されるどのコンポーネントまたはその組合せに関するどのような依存も要件も有していると解釈されるべきでない。

本発明は、他の数多くの汎用または専用の通信環境または構成と動作可能である。本発明とともに使用するのに適切であり得る他の公知の計算システム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれをも含む分散型計算機環境などを含むが、それに限定されない。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明することができる。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、通信ネットワークまたは他のデータ伝送媒体を介してリンクされるリモート処理デバイスによってタスクが実施される分散型計算機環境でも実施される場合がある。分散型計算機環境では、プログラムモジュールおよび他のデータは、メモリ記憶装置を含むローカルおよびリモートコンピュータ記憶媒体両方に置かれる場合がある。

図１を参照すると、本発明を実施する例示的なシステムは、汎用コンピューティングデバイスを、コンピュータ１１０の形で含む。コンピュータ１１０のコンポーネントは、処理ユニット１２０と、システムメモリ１３０と、システムメモリなど様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含むことができるが、それに限定されない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスなどいくつかの種類のバス構造のいずれでもよい。限定ではなく例として、このようなアーキテクチャは、ＩＳＡ（業界標準アーキテクチャ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（拡張ＩＳＡ）バス、ＶＥＳＡ（米国ビデオ電子装置規格化協会）ローカルバス、ＰＣＩ（周辺装置相互接続）バス（メザニンバスとしても知られる）、ＰＣＩ−Ｅｘｐｒｅｓｓ（高速周辺装置相互接続）、およびシステム管理バス（ＳＭＢｕｓ）を含む。

コンピュータ１１０は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスされ得るとともに揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体両方を含む、市販されているどの媒体でもよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するためのどの方法でも技術でも実施される揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタル多用途ディスク）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは、所望の情報を格納するのに使われ得るとともにコンピュータ１１０によってアクセスされ得る他のどの媒体も含むが、それに限定されない。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、変調データ信号、例えば搬送波や他の移送機構として具体化し、どの情報配信媒体も含む。「変調データ信号」という用語は、信号中の情報を符号化するようなやり方で設定されまたは変更される信号特性の１つまたは複数を有する信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。上記のどの組合せも、やはりコンピュータ可読媒体の範囲に含まれるべきである。

システムメモリ１３０は、コンピュータ記憶媒体を、ＲＯＭ１３１およびＲＡＭ１３２など、揮発性および／または不揮発性メモリの形で含む。ＢＩＯＳ（基本入出力システム）１３３は、例えば起動中にコンピュータ１１０内部の要素間での情報の転送を助ける基本ルーチンを含み、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は一般に、処理ユニット１２０に対してただちにアクセス可能な、かつ／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０は、他の着脱式／固定式、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。単なる例として、図１は、固定式不揮発性磁気媒体からの読出しまたはそこへの書込みを行うハードディスクドライブ１４１、着脱式な不揮発性磁気ディスク１５２からの読出しまたはそこへの書込みを行う磁気ディスクドライブ１５１、および、ＣＤ−ＲＯＭや他の光学媒体など着脱式な不揮発性光ディスク１５６からの読出しまたはそこへの書込みを行う光ディスクドライブ１５５を示す。例示的な動作環境で使われ得る、他の着脱式／固定式、揮発性／不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体状態ＲＡＭ、固体状態ＲＯＭなどを含むが、それに限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０などの固定式メモリインターフェースによって、システムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの着脱式メモリインターフェースによって、システムバス１２１に接続される。

上述した、図１に示されているディスクドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０のための他のデータの格納を可能にする。図１では、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示される。こうしたコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じでも異なってもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくとも異なるものであることを示すために、ここでは異なる番号が与えられている。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）は、マイクロホン、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ＵＳＢ（ユニバーサルシリアルバス）など、他のインターフェースおよびバス構造によって接続されることもできる。モニタ１９１または他の種類の表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加え、コンピュータは、出力周辺インターフェース１９５を介して接続され得るスピーカ１９７およびプリンタ１９６など、他の周辺出力デバイスも含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク接続された環境において動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードでよく、通常、コンピュータ１１０に関連して上述された要素の多くまたはすべてを含むが、図１にはメモリ記憶装置１８１のみが示されている。図１に示される論理接続は、ＬＡＮ（ローカルエリアネットワーク）１７１およびＷＡＮ（ワイドエリアネットワーク）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。

ＬＡＮネットワーク環境において使われる場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境において使われる場合、コンピュータ１１０は通常、モデム１７２、または、例えばインターネットなどのＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内部にあっても外部にあってもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続され得る。ネットワーク接続された環境では、コンピュータ１１０に関連して図示されるプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納され得る。限定ではなく例として、図１は、リモートアプリケーションプログラム１８５を、メモリ装置１８１に存在するものとして示す。図示したネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使われ得ることが理解されよう。

（常時動作可能なコンピューティングデバイスの例示的な実施形態）
最新のＰＣオペレーティングシステム、例えばワシントン州レドモンドのマイクロソフトコーポレーションから販売されているＷＩＮＤＯＷＳ（登録商標）ＸＰは、システムの特定のコンポーネントがＡｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ（ＡＣＰＩ）メソッドを介して引き出す電力量を制御する機能をもっている。このようなコンポーネントは、ＣＰＵ、グラフィックスプロセッサ（ＧＰＵ）、モニタ、ハードディスクドライブ、電源機構、冷却ファンなどを含むが、それに限定されない。この機能は、電力使用を削減してシステムのエネルギー効率を高めるとともに冷却ファンからのアコースティックエミッションも削減するという利益を有する。具体的には、今日、ＰＣにおける最大のノイズ要因は、ＣＰＵファン、ＧＰＵファン、電源ファン、システムケースのファンを含む冷却ファンである。装置がより低い電力を引き出し、より低い熱を放出するにつれて、ファンにより熱を活発に放散する必要性が減少し、その結果、アコースティックエミッションが低下した。ＰＣがリビングルームで受け入れられるためには、こうしたノイズ発生源を大幅に削減する必要がある。

本発明は、「スマートオフ」状態（擬似オフ状態）を有するＰＣシステムであって、ＰＣが「オン」状態（ＡＣＰＩ Ｓ０）にとどまっているが、ユーザには「オフ」に見えるＰＣシステムを対象とする。本発明によると、ＰＣの電源ボタン（「スマートオフ電源ボタン」）が、（システムケース上で、リモコンあるいはキーボードまたはマウスアクションを介して）押下されると、システムは「オフ」イベントを登録し、現在実行中の状態（Ｓ０）以外のＡＣＰＩ状態（例えば、Ｓ１、Ｓ３、Ｓ４、またはＳ５）に入るようにオペレーティングシステムに信号通知するのではなく、カスタムソフトウェアおよびＡＣＰＩメソッドによりＣＰＵ、ＧＰＵ、モニタ、ファンなどのシステムコンポーネントをパワーダウンするように一連の電源管理トリガが設定される。したがってＰＣは、「常時オン」であり、タスクを実施することができる状態にある。あるいは、本発明は、最初に「スマートオフ」状態に入り、次いで所定の期間の後、Ｓ３に遷移することもできる。この場合、何らかのイベント（例えば、ＰＣがＰＶＲとしてのタスクを課される、など）が起こると、システムはＳ３から「スマートオフ」（すなわち、モニタがオフであり、オーディオがミュートされている、など）を起動し、タスクを実施し、次いで一定の非アクティブ期間の後、Ｓ３に戻る。

この技術は、控えめな上に「オフ」に見える一方、低強度のタスクを処理できるシステムのために色々役立つ。システムは、より高強度のタスクを遂行する必要がある場合には、自らを「オン」に戻すことができる。例えば、ユーザがＰＣをオフにしているが、所定の時間にＴＶ番組が録画される予定を立てており、同時に別のユーザがそのＰＣからメディアを流している場合、ＰＣは、それ自体を「オン」に戻して、こうしたタスクを遂行するのに必要な処理能力および冷却を提供することができる。システムは次いで、タスクが完了した後、それ自体を「オフ」に戻すようにプログラミングされ得る。

本発明によると、Ｓ０における５つの「擬似オフ」状態が、次のように考慮される。

（１）ユーザ対話(interaction)を伴うオン。この状態は、ユーザが、ＴＶを見、音楽を再生し、ＤＶＤを見ることなどによってシステムと対話しているときである。この対話は、ワードプロセッシングやインターネットの閲覧など、他のどの一般的なＰＣ使用も含むことができよう。

（２）スマートオフ。上述したように、ユーザが娯楽目的またはコンピュータの使用を終了し、ＰＣの「オフ」ボタンを押下するとこの状態に入る。ＰＣは、Ｓ０状態にとどまるが、すべてのデバイスがクロックを下げられ、すべての冷却ファンが停止され、マウスおよびキーボードなどの入力デバイスがロックされるなどして、ユーザにデバイスがオフであることを示す。クロックの低下により、システムは、状態（１）より低電力の状態にあり、受動冷却(passive cooling)により冷却され得る。

（３）ユーザ対話を伴うスマートオフ。この状態において、ユーザは、スマートオフから状態（１）に完全に「起動させる」ことなく、特定のタスクをＰＣ上で実施することができる。例えば、「スマートオフ」は音楽再生を実行するのに十分な処理能力を提供する。ユーザが、ファンもモニタもオンにすることなくＰＣでオーディオを再生できることが望ましい場合がある。この例において、ＰＣは、どのトラックが再生中であるか、残り時間などを示すための、ＤＶＤ／ＣＤプレーヤで使われるものと同様のフロントパネルディスプレイを含み得る。

（４）ユーザ対話を伴わないオン。例えば、ＰＣが状態（２）であったが、画面がオンに戻ることなく状態（１）に戻るよう要求された後で、この状態に入る。例えばこの状態には、システムが、全ＣＰＵまたはＧＰＵ処理（例えば、家庭用ビデオレコーダ（ＰＶＲ））を必要とするＴＶ番組を録画するタスクを課されると、入る可能性がある。この状態では、状態（２）よりは高いが、状態（１）より低い、ファンからのアコースティックエミッションが生じる。

（５）アクティブスマートオフ。この状態は、状態（１）に似ているが、ＰＣが状態（２）にとどまりながら扱うことができる程度に処理の作業負荷が小さい。この状態において、ＰＣは、ファンをオンにすることなくタスクを処理し、命令を処理していてもオフに見え続ける。状態（４）の説明において言及したＰＶＲのシナリオが、この状態において遂行され得ることも可能である。番組が録画されていることを示す光をＶＣＲが点灯させるのと同様に、「オフ」状態のＰＣでタスクが遂行されつつあることをユーザが視覚的に確認し得るように、ＬＥＤを点灯させることが望ましい場合もある。

上述したＳ０状態のいずれからでも、ユーザは、同じようにシステムをＳ５／Ｇ３状態に完全にシャットダウンし得るであろう。このことは、（例えばシャーシの裏にある）第２の電源ボタンまたは「オフスイッチ」を用いて実装され得る。さらに、システムをＳ５／Ｇ３にするための、スマートオフ電源ボタンの長押し（例えば４秒）を実装することが望ましい場合もある。最後に、ユーザは、オペレーティングシステムのユーザインターフェース制御を用いてシステムをシャットダウンすることもできる。

本発明によると、以下の非限定リストに挙げるコンポーネントが、比較的低いアコースティックエミッションを実現するために以下のやり方でパワーダウンされ得る。

（ＣＰＵ）
現在のＣＰＵ技術は、システム要求に基づいて電力消費を変えるのに使用される間、ＣＰＵの周波数および電圧の調整を可能にする。例えば、映像が描画されるとき、３．０６ＧＨｚのプロセッサが、その最大周波数および電圧までクロックを上げて、ほぼ９０ワットに等しい可能な最高処理能力を提供することができる。ただし、システムがアイドル状態にあるとき、ＣＰＵは、はるかに低い電圧および周波数（例えば、８００ＭＨｚ未満）までクロックを下げ、約１０〜３５ワットしか引き出さない場合がある。

ＣＰＵ用の従来の冷却ソリューションは、常に、可能な最高電力に対して冷却を行うように設計されるので、より低電力の操作の間は、不必要に高いアコースティックエミッションが生じる。しかし、本発明によると、３５ワットを受動冷却し、またはＣＰＵがサポートするクロックダウン周波数から生じるどのワット数も受動冷却し得るＣＰＵ用のヒートシンクが用いられ、したがって、ＣＰＵファンは、スマートオフ電源ボタンが押下されると完全にオフになり得る。

（ＧＰＵ）
ＣＰＵとほぼ同じやり方で、ほとんどのグラフィックスアダプタ用の冷却ソリューションが、アダプタが別個のものであっても統合されていても、最高電力を使用するシナリオ用に設計される。ＣＰＵに対して上で説明したものと同じ技術を実装することによって、ＧＰＵファンは、スマートオフ電源ボタンが押下されるとオフにされ得る。ＧＰＵファンをオフにすることに加え、映像信号も直ちに除去されて、デバイスがオフである様子をディスプレイに提供することができる。

（システムケースのファン）
システムケースのファンはシステムシャーシの周囲温度を下げるのに利用され、この温度低下は、コンポーネントファンの効果を最大にし、かつシステム内の受動冷却されたデバイスに気流をもたらすのを助ける。システム負荷に応じて、こうしたファンは、オフにされることも、人間の可聴閾値未満のアコースティックエミッションをもたらす非常に遅い速度で駆動されることもできる。

（ハードディスクドライブ）
ハードディスクドライブ技術は、ＰＣシャーシの外側のアコースティックエミッションが知覚不可能になるところまで向上しているが、インアクティビティに基づいてドライブの回転速度を下げることも可能である。ハードドライブは、ＰＣがスマートオフ状態にある間回転し続け、そうすることによって、ＰＣは、システムコードのアップデートや、ケーブル供給またはインターネットからのメディアコンテンツのダウンロードなどのバックグラウンド機能を実施し得ることが望ましい。

（電源）
上に記載したソリューションを利用することによって、システム内のコンポーネントがより低電力の状態におかれると、電源に対する負荷が大幅に減少する。電源に対する負荷を減少することによって、より低電力の状態の間、電源ファンがオフにされ得るように、電源を冷却するのに適したサイズの受動ヒートシンクが使われ得る。

本発明によると、好ましい実装形態は、既存のＡＣＰＩメソッドを用いてＣＰＵの周波数および電圧を制御するソフトウェアドライバを使用する。同様に、ＧＰＵは、ＰＣのオペレーティングシステムによる要求に応じてＧＰＵを減速するように定義されているＡＰＩを介して制御される。ソフトウェアドライバは、他のコンポーネント、例えばファンおよび電源などを制御するのに使われ得る。

好ましい実装形態において使われる通信プロトコルは、電源に既存のマイクロコントローラを使用するＳＭＢｕｓ（システム管理バスインターフェース）である。図２に示すように、ＳＭＢｕｓインターフェース２００を介して、ＳＭＢｕｓシステムホスト２０２、電源２０４、および他のデバイス２０６を含む様々なコンポーネントが、システムホストファン、ボタン、およびＬＥＤを制御するために通信を行うことができる。ＳＭＢｕｓインターフェースは、例えば、非特許文献１に記載されている。

電源２０４は、ＡＣからＤＣへの変換を行う電源ユニット、バッテリ、不可欠な充電装置からなることができる。電源２０４は、特定の電源ユニットのサイズ、またはバッテリのサイズおよび化学的性質にかかわらず、電源管理および充電制御に適した情報を提供するための特定の環境パラメータを監視する。ホスト１１０から電源２０４への通信は、ユーザまたはホスト１１０の電源管理システムのいずれかに提示されるデータを得るのに用いられる。ユーザは、電源から２種類のデータ、すなわち実測および予測データを取得することができる。温度やバッテリの充電／放電状態などの実測データは、測定されたものでも、バッテリの化学的性質などのバッテリ特性でもよい。予測データは、ＰＳＵおよびバッテリの現在の状態に基づいて計算される。

本発明によると、電源管理システムは、アクションがシステムの整合性に害を及ぼすかどうか判定するために、デバイスドライバに問い合わせることができる。例えば、電源２０４が最大負荷状態のときにディスクドライブを回転させることは、電源の出力電圧を許容限度より低下させシステム障害を引き起こす場合がある。これを防止するために、デバイスドライバは、望ましい結果をもたらす、電源からの情報を必要とする。ドライバは、電源２０４に問合せを行い、十分な電力が利用可能でないことを発見した場合、電源管理システムが、非限界電力(non-critical power)の使用を停止し、またはシステムコンポーネントの電力／性能の動作点を変えるよう要求することができる。

電源２０４は、ホスト１１０に、限界となり得る条件を知らせることができる。こうした通知は、電源が落ちそうであること、またはバッテリの充電が低いことをホスト１１０に知らせるための、電源２０４側の活動を表す。電源２０４は、ユーザまたはホスト１１０が適切な訂正アクションをとることを期待する。このような限界通知(critical notification)は、電源２０４の状態が変化したことをホスト１１０に信号通知するためのＳＭＢＡｌｅｒｔを用いて、電源２０４から発生し得る。

あるいは、ＣＰＵ周波数および電圧は、マイクロコントローラ内のマイクロコード（システムＢＩＯＳなど）を伴うハードウェア機構を介しても制御され得る。この制御は、ＡＣ電源の損失および／またはＤＣ電源の存在（バッテリ電源）というイベントに基づいて周波数および電圧を変えるよう、ＣＰＵに通知するための制御プロトコル（例えば、ＳＭＢｕｓや他の制御プロトコル）を用いて、電源によってトリガされ得る。この実装形態は、ＡＣＰＩに依拠せず、完全にＨＷ／ファームウェアベースである。

ここで図３および４を参照すると、上述したＡＣＰＩ Ｓ０における様々な擬似オフ状態の間の遷移のフローチャートが示されている。ステップ３００で、ＰＣは、状態（１）として上述した、完全な「オン」状態にある。ステップ３０２で、ユーザは、ＰＣとの対話を終え、ＰＣのスマートオフ電源ボタンを押下する。ステップ３０４で、システムは、いずれかのアクティブなアプリケーションが、全処理能力を必要とするかどうか判定し、システムがオフにされるとアクションがキャンセルされることをユーザに通知する（ステップ３０６）。ステップ３０８で、ユーザは、ステップ３０６で言及したアクションをキャンセルすることができ、この場合処理は、ステップ３０４に戻り、またはユーザはアクションをキャンセルしないことを選ぶことができ、この場合、ＰＣは、ステップ３００に戻り、完全なオン状態にとどまる。

ステップ３０４で、アクティブなアプリケーションが全処理能力を必要としない場合、ステップ３１０で、システムコンポーネントは低電力要求を通知される。次に、ステップ３１２で、ＣＰＵは、最低状態になるようにクロックを下げ、ＣＰＵファンが停止される。ステップ３１４でＧＰＵがオフになり、ファンが停止され、映像信号がカットされる。ステップ３１６で、ＨＤＤは、キャッシュをフラッシュし回転速度を落として電力消費をさらに削減することができる。ステップ３１８で、システムケースのファンが停止し、次いでステップ３２０で、電力出力が低下され、ファンが停止する。ステップ３２２で、電源ボタン（またはケースのＬＥＤ）は、オフ状態（すなわち、スマートオフ）を示し、そうすることによって、ＰＣがオフに見える（ステップ３２４）。

図４は、システムがスマートオフ状態にある（ステップ３２６）ときに、完全なオン状態に戻る処理を示す。ステップ３２８でさらに電力を必要とするアプリケーションがあるかどうか判定される。このようなアプリケーションは、スケジュールされることも、ユーザ対話によってトリガされることもできる。どのアプリケーションもそれ以上の電力を必要としない場合、処理はステップ３２６に戻る。追加電力を必要とするアプリケーションがある場合、ステップ３３０で電源ファンがオンになり、その後ステップ３３２でシステムケースのファンがオンになる。ステップ３３４でハードドライブが回転速度を上げ、次いでステップ３３６でＧＰＵおよびそのファンがオンになる。ステップ３３８でＣＰＵがクロックを上げ、ＣＰＵのファンがオンになる。次いでステップ３４０で電源ボタンが、ＰＣがオンであることを示し、そうすることによって、ＰＣはこの時点で完全なオン状態になる（ステップ３４２）。

図５は、ＡＣＰＩ／スマートオフ状態に対する電力使用量の例示的なグラフを示す。ＰＣがＡＣＰＩ Ｓ０状態のとき、ＰＣ内の様々なコンポーネントは、最高出力で実行されることが許可される。したがって、ＰＣの電力消費は比較的高く、約５０ワットから２００ワット超の範囲である。ただし、ユーザがスマートオフを開始すると、電力消費は、例えば６０ワット（または受動冷却され得る他の量）の閾値に消費量を制限するように、強制的に管理される。スマートオフ状態にあるとき、ＰＣはＳ０にとどまり、コンポーネントは全消費量が閾値未満のままとなるように管理される。ＰＣは、この状態においてタスク処理を実施することができる。スマートオフ状態にあるとき、ＰＣは、アプリケーションの処理要求を満たしながら、電力を閾値未満に削減することを試みる。ＰＣが、スマートオフ状態の電力制限下で可能であるよりも多くの処理を必要とするアプリケーションを実行するようにタスクを課されると、ＰＣコンポーネントは出力電力が上げられ、アクティブ冷却コンポーネントが再度活動化される。ＰＣはしたがって、完全なオン（Ｓ０）状態に戻される。しかし、ユーザが、ＰＣが他のＡＰＣＩ状態（Ｓ３、Ｓ４／Ｓ５）に入ることを要求すると、電力消費はさらに削減され、ＰＣは、どのタスク処理も実施することができなくなる。

本発明による常時動作可能なコンピューティングデバイス(Always Ready Computing Device)の例示的なハードウェア実装形態が次に説明される。コンピューティングシステムは、望ましくは、マイクロソフトのＷＩＮＤＯＷＳ（登録商標）ＸＰ、またはより上位のものを実行する。常時動作可能であるという特徴を実装するシステムは、コンピューティングデバイス１００の前面にあるヒューマンインターフェースデバイス（ＨＩＤ）準拠のスリープボタン、リモコン、および任意選択のキーボード１６２を含む。本文書の目的のために、ＨＩＤ準拠スリープボタンは、「スマートオフボタン」と呼ばれる。スマートオフボタンは主として、システム１００をＳ０からスマートオフに、かつスマートオフからＳ０に遷移させることを担う。さらに、装置１００の前面、任意選択でリモコンにあるスマートオフボタンは、システムをＳ５またはＳ４状態からＳ０にすることができる。

以下は、スマートオフボタンが、どのようにして常時動作可能なシステムで実装され得るか、および、従来のＨＩＤスリープボタンとどのように異なり得るかを説明する。ＵＳＢポートをスマートオフボタンに接続する専用のＵＳＢヘッダが、マザーボード上に露出される。このソリューションを実装するために、低コストのＵＳＢマイクロコントローラがＨＩＤデバイスとなるようにプログラミングされることができ、スマートオフ機能をサポートする。スマートオフボタンを実行するのに必要なＵＳＢマイクロコントローラは、ＨＩＤデバイスとしてプログラミングされ、ＨＩＤ使用コードを送るために、電源管理に使用される。常時動作可能であることは、システム制御に従来のＨＩＤ使用コードを使うので、常時動作可能なソフトウェアが後で取り外される場合、スマートオフボタンは電源管理を用いて構成され得る。

スマートオフボタンは、スーパーＩ／Ｏチップの電源管理コントローラに直接配線接続されないので、通常、オペレーティングシステムがロードするまで、どの操作も実施することができない。スマートオフボタンがＳ４またはＳ５からのブート動作を実施することを可能にするために、マザーボードはＵＳＢを介した「リモート電源オン」をサポートする。この機能を実施するために、マザーボードのチップセットがＵＳＢポート用の「ウェイクオンＵＳＢ」用に構成され、ＵＳＢポート上でＰＣのシャーシにあるスマートオフボタンが接続される。リモコン受信機が、外部の接続経由ではなく内部的にＵＳＢポートに配線接続される場合、このポートもシステムを起動することが可能にされるであろう。ただし、システムがＳ４またはＳ５にあるときに節電を行うために、すべてのポートではなく、スマートオフボタンが接続されているポートのみがウェイクオンＵＳＢ用に構成されることが好ましい。

マザーボードのチップセットがＡＣ電源損失後のウェイクオンＵＳＢをサポートしない場合、マザーボードのチップセットおよびシステムは両方ともＡＣ復帰におけるパワーアップをサポートし、そうしたパワーアップ用に設定されるべきである。そうしないと、スマートオフボタンは、ＡＣ電源がシステムから取り外され、後で復元された場合に作用することができない。

ＢＩＯＳ実装形態は、後でより詳細に説明される常時動作可能なドライバ拡張により、常時動作可能技術と相互作用する。スマートオフボタンは、ＨＩＤ準拠のスリープボタンとして実装されるので、電源管理機能は、システム制御用のＨＩＤ使用コードを認識し、制御パネルの電力オプションで指定されたシステム状態に入るようシステムに命令する。常時動作可能なシステムが、このボタン押下に対して異なるアクションを実施するためには、常時動作可能なドライバは、ボタン押下イベントを遮り、次いでこのイベントを常時動作可能なポリシードライバにリダイレクトする。

常時動作可能なポリシードライバは、常時動作可能なＡＣＰＩドライバを介してシステムＢＩＯＳ１３３と通信する。当業者は理解するであろうが、本明細書において使われるドライバ拡張、サービス、およびメソッドの名称は例示のためであり、本発明の範囲を限定する意図はない。常時動作可能なＡＣＰＩドライバは、スマートオフへの、およびそこからの遷移をＢＩＯＳに通知するＡＣＰＩ制御メソッド（ＡＲＤＹ）を実行する。常時動作可能なＡＣＰＩドライバが、オンとスマートオフの間を遷移するためのスマートオフ要求をＢＩＯＳに伝達するために、このドライバは、例えばＡＣＰＩ．ＳＹＳを介してＡＲＤＹ制御メソッドを呼び出す。この呼出しは、常時動作可能なＡＣＰＩドライバがそのためにロードされ得るＢＩＯＳのＡＣＰＩ名前空間内でデバイスが作成されると行われる。常時動作可能なＡＣＰＩドライバは、新しいデバイス用にロードされるとＡＲＤＹ制御メソッドを実行するためのＩＯＣＴＬをＡＣＰＩ．ＳＹＳに送る。

ＡＣＰＩ名前空間において作成されるデバイスの名称およびハードウェアＩＤ、ならびに例示的なＡＲＤＹ制御メソッドは、次の通りである。

システムのアクティブ電源状態を伝える発光ダイオード（ＬＥＤ）は、サポートされるＡＣＰＩ電源状態すべてに加えてスマートオフ状態も表し得るべきである。スマートオフ準拠システムへのＬＥＤの接続は、ＡＣＰＩ固定電源ボタンをサポートする電源ＬＥＤと同じやり方で物理的に接続される。しかし、スマートオフボタンならびにＡＣＰＩ固定電源ボタン両方がシステム上に存在する場合、システムに２つのＬＥＤが必要となり得る。こうしたＬＥＤそれぞれのシステム状態は、システム状態にかかわらず常に一致するべきである。

スマートオフボタンＬＥＤは、ＡＣＰＩ名前空間内で定義されたシステム状況オブジェクト（＿ＳＳＴ）を使用してシステムがスマートオフ状態にあるかどうかを正しく示す。ＡＲＤＹ制御メソッドが実行される（そうすることによって、システムがスマートオフに遷移していることを示す）と、ＢＩＯＳは、＿ＳＳＴオブジェクトを、「１」という動作状態から「３」というスリープ状態に変える必要がある。この制御メソッドが、システムをスマートオフ状態から起動するために再度実行されると、＿ＳＳＴオブジェクトの値は、「１」という動作状態に戻される必要がある。

常時動作可能なコンピューティングデバイスで使われる電源は、上述したアコースティック要件を満たす限り、実装において変動し得る。すなわち、装置がスマートオフ状態にあるときファンが停止され得る。電力消費、コンポーネントの配置、シャーシ設計、ならびにＣＰＵおよびグラフィックスカードなどのシステムコンポーネントの選択など、多くのシステム要因が電源に対して考慮されるべきである。こうした要因は、システムによって変わるが、常時動作可能なコンピューティングデバイス用の電源を選び、または設計する際、ファン制御、ヒートシンク設計、および動作効率の領域が考慮される。

スマートオフを用いてファンをオフにすることが望まれるが、上記のリストに列挙したシステム要因によっては、そうすることが妥当でない場合がある。代替案として、電源の高度なファン制御を行い、スマートオフ状態にあるときにファンが静音速度で実行されることを可能にすることがより妥当であると考えられる。電源ファンが、オフになるか、より遅い速度で回転するかにかかわらず、スマートオフになると、ファン自体の制御が何らかのやり方で遂行されなければならない。ファン制御は、ＢＩＯＳを介してコンピューティングデバイス上の常時動作可能なソフトウェアを実行することによって遂行されることもでき、電源自体によって管理されることもできる。

電源のファン動作は通常、ＰＣがオンであるときに所定の速度（電圧）でファンを絶えず動かすことによっても、システムがスリープまたはオフであるときにファンをオフにすることによっても、電源自体により制御される。常時動作可能なシステムは、実質的に１００％の時間、Ｓ０にあるので、一般的な電源は、システムがいつスマートオフに、かつそこから遷移するかを判定する機構をもたない。次に説明されるように、常時動作可能という技術とともに最適に動作するように設計される電源に対して、特殊な修正が加えられる必要がある。

ファンの速度制御は、例えば、非特許文献２で定義されるＦａｎＣ信号によりシステムに公開され得る。電源からＦａｎＣ信号ラインが接続されているマザーボード上で汎用Ｉ／Ｏ（ＧＰＩＯ）ヘッダが公開される。さらに、デバイスドライバが、スマートオフに、かつそこから遷移するとき、ファンを制御するための常時動作可能なポリシードライバとともに使用される場合がある。このデバイスドライバは、ＦａｎＣ信号が接続されているＧＰＩＯと直接通信するように実装される。あるいは、電源ファンを制御するためのＧＰＩＯは、デバイスドライバではなくＢＩＯＳを介して制御されることもできる。あるいは、システム設計者はＦａｎＣ／ＦａｎＭのファン制御を提供する、ＭＩＣＲＯＳＯＦＴ ＰＯＷＥＲ ＳＥＮＳＥ技術による電源を使うことを選ぶこともできる。

電源ファンの速度制御は、マザーボードのスーパーＩ／Ｏチップの環境コントローラ機能を介しても遂行される場合がある。通常、こうしたコントローラは、電源のファンを制御するのに使われ得る複数のファン出力を有する。

電源ファンの制御のための異なる方法が実装され得ることに留意されたい。例えば、電源内部で温熱条件(thermal condition)が起こった場合、電源はファン制御をオーバーライドするようにも設計されなければならない。このような設計は、電源が熱についての情報をシステムに伝達しないので必要である。

スマートオフの間、電源が静かに冷却されるためには、この目標を念頭において電源ヒートシンクが設計されることが必要である。熱の分析は、電源のメインＰＣＡ上で提供されるストックヒートシンクが強制または自然対流条件いずれの下でも適切でないことを示した。さらに、こうしたストックヒートシンクは、はるかにしっかりと囲まれた領域に適合するように設計された。

ここで図６を参照すると、常時動作可能なコンピューティングデバイス内で電力負荷の発熱を受動放散するように設計された電源ヒートシンク４０２が示されている。このヒートシンクの物理的な大きさは、システム筐体内の利用可能空間に適合するように最大にされるが、ボードに搭載される構成部品、配線、および周辺構造のための隙間を残している。フィン配向４０４は電源を通る卓越気流(prevailing airflow)の向きに一致し、クロスカット４０６は乱気流の誘導を助ける。このヒートシンクは、陽極酸化されて黒色になり、放射熱の転送能力を最大にするのを助ける。

電源設計の本質は、電源が全負荷で動いているときに最適効率が達成されるようにすることである。表１は、全容量で動いているときに２００ワットのＤＣ負荷に対して見積もられる電源効率を示す。

表１に示されるように、１９０．８５ワットの連続ＤＣ出力をＰＣに渡すために、電源は、ＡＣからＤＣへの変換によるワット損に起因する７９．１５ワットの損失を調節するための２７０ワットのＡＣ入力が可能である。これは、１００％の負荷での７１％の電源の評価効率と同じである。対照的に、電源負荷が大幅に下げられると電力損失が増える。表２は、２０％の負荷で動いているときに２００ワットのＤＣ負荷に対して見積もられる電源効率を示す

表２に示されるように、３６．７５ワットの連続ＤＣ出力をＰＣに渡すために、電源は、ＡＣからＤＣへの変換によるワット損に起因する３１．２５ワットの損失を調節するための６８ワットのＡＣ入力を提供しなければならない。これは、２０％の負荷での５４％の効率と同じである。電源の動作効率を７１％（表１に示される）から上げることによって、より低い動作レベルでの損失が大幅に低下する。この結果、エンドユーザにはより高い省電力をもたらし、かつスマートオフのときに受動冷却をより容易に調節することができる熱の面での設計を電源にもたらす。

ＡＲＤＹ制御メソッドが実行されて、システムがオンとスマートオフの間を遷移していることをＢＩＯＳに通知すると、ＢＩＯＳはＡＲＤＹ制御メソッドの値に応じて電源ファンを制御するための適切なアクションをとることができる。このアクションは通常、ＣＰＵおよびシステムの温度情報を監視し複数のファン制御ポイントを有する、システム内のスーパーＩ／Ｏチップ（ＳＩＯ）を介して遂行される。スマートファン制御を有するＳＩＯチップは、ファンおよび温度制御レジスタ内で構成される値に基づいてファン速度を変えることができる。

常時動作可能のための設計の一側面は、ＣＰＵが、より低い周波数および電圧で実行され、システムがスマートオフになるときにより低電力の状態をもたらす能力である。この能力は、スマートオフのときの電力消費を大幅に下げ、ファンを回転する必要なく受動放散され得るＣＰＵに対してはるかに小さい熱のエンベロープ(envelope)をもたらす。

最適な常時動作可能ＰＣを設計するためのＣＰＵ関連ハードウェアは、ＡＣＰＩプロセッサの性能制御をサポートするＣＰＵ、およびカスタムヒートシンク設計である。例えば、非特許文献３で定義されている、プロセッサの性能状態をサポートするプロセッサは、ＣＰＵが、電力消費がより低い状態に入ることを可能にする。このことは通常、プロセッサの周波数（ＣＬＫ）および電圧（ＶＤＤ）の変更により達成される。あるいは、プロセッサは、例えば、非特許文献４で定義されているクロックスロットル停止(stop clock throttling)を実装して、プロセッサのクロックオフタイムのデューティ値を上げることができる。このことは、電圧は低下されないが周波数を下げることと同じ効果を有し、省電力は、プロセッサの性能制御の実装ほど重要でないことを意味する。

例示のために、ＡＭＤ ＡＴＨＬＯＮ６４プロセッサにおいて、表３は、スマートオフのときの異なるシナリオに対するＣＰＵ温度、システム電力消費、およびＣＰＵ使用を示す。

適切なマザーボードに適合する従来のヒートシンクは、統合冷却ファンを用いる強制対流の下で作用するように設計されるので、こうしたヒートシンクは、強制対流条件下で最良の熱伝導のために質量および表面領域を最大にする構造（ピン、狭間隔フィン、折返し板金フィンなど）を有する。しかし、気流は、隙間の狭いフィンを通らず、滞流する傾向にあるので、自然対流条件下では従来のヒートシンクはうまく働かないことを示した。さらに、一体化して取り付けられたファンは、ファンが強制気流をもたらしていないときヒートシンクを断熱する傾向にある。

ファンのないいくつかのヒートシンクが市販されているが、こうしたヒートシンクは大きすぎて、一般的なコンピューティングデバイス内の限られた利用可能空間に適合しない。したがって、自然および強制対流条件下両方で優れた熱性能をもつ設計が必要とされる。このような設計が、図７に示される。

ＣＰＵヒートシンク４０８の設計は、高い熱伝導性をもつので、プロセッサチップから熱を分散するのに銅ベース４１０が使用される。しかし、銅は重く、高価であり、製造工程において押出し成型するのが容易でない。こうした欠点を最小限にするために、このヒートシンク設計の外側部分４１２は、大気中に熱を放散するのに必要とされる表面領域および熱量を提供する、銅ベースに接着されたアルミニウムフィンからなる。こうしたヒートシンクフィン４１４は、自然対流状況下での優れた伝導を可能にするように比較的間隔があけられる。さらに、このヒートシンクのアルミニウム部分は、銅ベースより外側に伸びて熱量および表面領域を最大にする。筐体の入口／出口およびファンの偏向板構造も、強制対流下で最良冷却シナリオをもたらすように調整される。

このヒートシンクの理想的な物理サイズは、システム筐体内の利用可能空間に適合するように構造全体のサイズを最大にすることによって決定され、マザーボードを搭載したコンポーネントおよび配線のための隙間を残している。銅ベースサイズは、ＡＭＤ ＡＴＨＬＯＮ６４によって指定されたプロファイルおよびホール取付け配置に適合するように選ばれた。このベースの厚さは、ヒートシンクのアルミニウム部分（銅部分の外部表面に搭載されている）がマザーボードの上に広がるとともに、付近のコンポーネントをよけるように選択される。このことは、容易かつ平面的な幾何学的遷移領域をもたらし、容易かつ低コストの製造を可能にする。

銅製ヒートシンクベース上のフィン付きアルミニウム構造は、マザーボード上の利用可能空間を最大にするように設計され、コンピューティングデバイスの筐体の構成全体が与えられると、可能なほとんどの表面領域および熱量を提供する。フィンの間隔は、特殊な設備も工程（ＥＤＭ機械加工など）も必要とすることなく、ヒートシンクフィンをカットするための標準的な工作機械仕上げを可能にするように選択される。この設計は、上述したように強制および自然対流条件両方の下で優れた熱伝達をもたらすように比較的間隔をあけた高アスペクト比のフィン構造を提供する。さらに、薄いクロスカット４１６が、気流を「妨害」するためにフィン配向に対して垂直にされたので、乱気流の誘導を助け、したがってヒートシンクの熱の伝達性能を上げる。

ヒートシンクのアルミニウム部分は、陽極酸化されて黒色になり、ヒートシンクの放射熱の伝達性能を最大にするのを助ける。黒色陽極酸化は、むき出しのアルミニウムの数倍大きい放熱性を有する。この熱伝達効率の向上は、対流冷却モードを用いるときは特に重要である。

常時動作可能に準拠するシステムＢＩＯＳは、例えば、非特許文献３で定義されるプロセッサ性能制御を実装する。この実装は、スマートオフになるとき、常時動作可能なユーザモードサービスがＮＴＰｏｗｅｒＩｎｆｏｒｍａｔｉｏｎＡＰＩを実行して、ＣＰＵを最低サポートのＰ状態にすることを可能にする。

ＣＰＵファン制御は、システムがＡＲＤＹ制御メソッドによってスマートオフに入ったという、システムＢＩＯＳへの通知により遂行される。ＢＩＯＳは次いでファンをオフにするのに適したアクションをとる。ただし、スマートオフのときでも、ＣＰＵの温度が、メーカ推奨限度を超えるレベルを超えないことを保証するために、熱のオーバーライドが考慮されなければならない。この機能は通常、ＣＰＵおよびシステムの温度情報を監視し、複数のファン制御ポイントを有する、システム内のスーパーＩ／Ｏチップを介して遂行される。スマートファン制御を有するＳＩＯチップは、ファンおよび温度制御レジスタ内で構成される値に基づいてファン速度を変えることができる。

多くのシステムにおいて、グラフィックスカードは、使用されると、ＣＰＵと同程度の電力を消費し得る。この電力消費は、システムがスマートオフに入るとき、解決が困難な熱に関する挑戦課題を課す。しかし、ユーザは、システムがスマートオフのときに積極的にディスプレイを使っているわけではないので、高度なグラフィックス性能は必要ない。このことは、グラフィックスベンダがスマートオフに入るときに、必要に応じてカードのＧＰＵを積極的に管理できるようにする。さらに、ヒートシンク設計は、スマートオフのときに受動冷却され得るソリューションを開発するために考慮され得る。

スマートオフの間にＧＰＵ温度がメーカ公開仕様より高くならないことを保証するために、図８に示すようなヒートシンク４１８の設計が用いられ得る。この設計は、ＧＰＵのスロットルおよびファン制御が実装されない場合に用いられる。さらに、ほとんどのグラフィックスカードが備えられたストックヒートシンクは適切な熱伝達特性をもたらさない。具体的には、ビデオカードは、システム内での気流のほとんどの直接経路中になかった領域において下向きのヒートシンクを搭載される。さらに、ストックヒートシンクのフィン４２０の配向は、筐体のその領域において卓越気流に対して垂直であった。

ＣＰＵヒートシンクの場合と同様、このヒートシンクの物理的な大きさは、システム筐体内の利用可能空間に適合するように最大にされるが、ボードに搭載される構成部品、配線、および周辺構造のための隙間を残している。フィン配向は、筐体のその領域における卓越気流の向きにより一致し、クロスカット４２２は、乱気流の誘導を助ける。このヒートシンクも陽極酸化されて黒色になり、放射熱の転送能力を最大にするのを助ける。

（ソフトウェア実装形態）
常時動作可能のための１組の拡張が、１組のドライバおよびユーザモードサービスにより管理される。図９のブロック図は、こうしたソフトウェアコンポーネントおよび互いとの論理関係を示す。矩形ボックスは、ドライバおよびＡＲＰｏｌｉｃｙであり、ＡＲＨｉｄＦｌｔおよびＡＲＡＣＰＩは、特定のどのハードウェア実装形態にも特有でない。ＡＲＥｎｖドライバは、部分的にハードウェア依存である。ＡＲＳｅｒｖｉｃｅは、ユーザモード常時動作可能サービスである。このサービスはハードウェア依存でない。

ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムにおいて、すべてのドライバは、標準カーネルモードＷＤＭドライバである。図のドライバはすべて、ＰＣＩバスドライバが所与のＶＩＤ／ＤＩＤにドライバを関連づけた結果として、フィルタドライバとして、またはルート列挙デバイスとして、標準ＰｎＰ手段を介してインスタンス化される。ユーザモードサービスは、通常のシステムサービス開始時に、システムのブート中に開始される。

図９の要素それぞれが次に説明される。ＡＲＰｏｌｉｃｙドライバ４２４（または他の適切な名前のドライバ）は、他の常時動作可能なドライバおよび協働エンティティからの情報収集を担う。ＡＲＰｏｌｉｃｙ４２４は、この情報を使って、システムの常時動作可能な状態を判定する。この状態情報は次いで、ＡＲＰｏｌｉｃｙによってシステムに渡るすべての協働エンティティに分配される。ＡＲＥｎｖドライバ４２６は、システムの常時動作可能な状態における変化について知らせを受ける必要があるいずれかの専用ハードウェアをサポートする方法についての例として与えられる。ＡＲＨｉｄＦｌｔドライバ４２８は、ＨＩＤフィルタドライバである。システムがスマートオフであるとき、このドライバは、（すべてのユーザキーストロークを破棄することによって）ＵＳＢキーボードと、（マウス動作通知を破棄することによって）ＵＳＢマウスとを「ロック」する。このドライバは、スマートオフおよびオンに、かつそこからトグルするのに使われる、予め定義されたキーシーケンス（スマートオフボタンの代替手段）も検出する。ＡＲＡＣＰＩドライバ４３０は、システムのＡＣＰＩ名前空間内で定義される常時動作可能に特有のデバイス（存在する場合）も要求する。ＡＲＡＣＰＩドライバ４３０は、システムがスマートオフ状態に入り、または出るときはいつでも、このデバイスのＡＣＰＩ名前空間（デバイスの直下）で定義される特定のメソッドを呼び出す。ＡＲＳｅｒｖｉｃｅ４３２は、ユーザモードでより容易に実装される常時動作可能な動作を実施するユーザモードサービスである。こうした操作は、メイン映像ディスプレイの電力低下、オーディオのミュート、進行中のオーディオ再生の一時停止、ＣＰＵ速度の限界までの低下を含む。こうした操作は、従来の機能を用いて遂行され得る。ＡＲＳｅｒｖｉｃｅ４３２が、Ｓ０−Ｌｏｏｋｓ−Ｏｆｆ状態に入るときに実施する特定の機能は、後で定義されるように、レジストリキーによって制御される。

ＡＲＰｏｌｉｃｙと、一体化されたカーネルモードコンポーネントとの間の通信が次に説明される。ＡＲＸｘｘｘドライバ（すなわち、ＡＲＰｏｌｉｃｙの指揮下にある制御コンポーネントへのドライバ）は概して、ハードウェア状況変化、または内部で検出したイベントの結果に合わせてその状態を変えるための自律アクションをとらない。そうではなく、ＡＲＸｘｘｘドライバによって識別されるハードウェアの状況変化は、ドライバが、ＡＲＰｏｌｉｃｙドライバへの１つまたは複数のイベント通知を生成するという結果を生じる。ＡＲＰｏｌｉｃｙドライバは、システム全体に渡る様々なコンポーネントから集められた情報をまとめ、この情報を使ってシステムの現在の常時動作可能な状態を定める。ＡＲＰｏｌｉｃｙは、システムの常時動作可能な状態におけるどの変化も、コマンド通知を用いて他のＡＲＸｘｘｘドライバに伝達する。ＡＲＸｘｘｘドライバは、ＡＲＰｏｌｉｃｙから受け取った、現在既に使用可能なシステム状態についての情報を用いて、ドライバの制御ポイントを管理する。

ＡＲＰｏｌｉｃｙと他のＡＲＸｘｘｘドライバの間の通信は、１対の名前付き実行コールバックを用いて遂行される。第１のコールバックは、「イベント」コールバックである。このコールバック（ＡＲＰＣ＿ＥＶＥＮＴ＿ＣＡＬＬＢＡＣＫ＿ＮＡＭＥという名称）は、ＡＲＸｘｘｘドライバによって通知されて、システム状況を報告する情報をＡＲＰｏｌｉｃｙに送る。各ＡＲＸｘｘｘドライバ（ＡＲＰｏｌｉｃｙ以外）は、このコールバックをオープンしイベント通知に用いる。ＡＲＰｏｌｉｃｙは、このコールバックをオープンし、各通知の結果として呼び出されるコールバックルーチンを登録する。

第２のコールバックは、「コマンド」コールバックである。このコールバック（ＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＣＡＬＬＢＡＣＫ＿ＮＡＭＥ）は、ＡＲＸｘｘｘドライバの１つまたは複数に送るべきコマンドがあるとき、ＡＲＰｏｌｉｃｙによって通知される。各ＡＲＸｘｘｘドライバ（ＡＲＰｏｌｉｃｙ以外）は、このコールバックをオープンし、コールバックを通知するＡＲＰｏｌｉｃｙの結果として呼ばれるコールバックルーチンを登録する。

カーネルコールバックは、比較的軽いものでありながら１対多（ブロードキャストタイプ）の通信機構を提供することができるので、主たる通信方法として好ましい。さらに、通知は、コールバックルーチンに２つの引数を渡すことにより大幅な柔軟性をもたらす。コールバック通知は同時に処理されるので、常時動作可能な組のすべてのドライバは、そのコールバックを阻止することなく直ちに処理する。このシステム内の通信は、ＡＲＰｏｌｉｃｙと他のＡＲＸｘｘｘドライバの１つとの間であることも好ましい。ＡＲＸｘｘｘドライバは、互いと直接通信することはない。

コールバックが通知されると、ＡＲＰｏｌｉｃｙによるものか、他のＡＲＸｘｘドライバのいずれかによるものかにかかわらず、２つの３２ビットの引数が渡される。すなわち、ＡＲ＿ＣＯＭＭＡＮＤ構造、および本明細書においてＶａｌｕｅ２と呼ばれる追加の３２ビット値である。Ｖａｌｕｅ２の使用は、ＡＲ＿ＣＯＭＭＡＮＤの内容に依存する。ＡＲ＿ＣＯＭＭＡＮＤの構造は、ＡＲＰｏｌｉｃｙと他のＡＲｘｘｘドライバの間の通信に用いられる。

例示的な構造の形式が、図１０に示されており、ここでＡＲ＿ＣＯＭＭＡＮＤのフィールド定義は、次のようになる。

Ｃ／Ｅ：セットされると、ＡＲ＿ＣＯＭＭＡＮＤ構造がコマンドを記述し、このＡＲ＿ＣＯＭＭＡＮＤが、ＡＲＰｏｌｉｃｙから生じ、主としてＤｒｉｖｅｒフィールドで識別されるドライバに向けられることを示す。クリアされると、ＡＲ＿ＣＯＭＭＡＮＤ構造が、主としてＡＲＰｏｌｉｃｙドライバをターゲットとしたイベントを記述し、このＡＲ＿ＣＯＭＭＡＮＤが、Ｄｒｉｖｅｒフィールドによって識別されたＡＲＸｘｘドライバから生じたことを示す。

ＩＤ：ある特定のコマンドまたはイベントを一意に識別する７ビット値を含む。

Ｄｒｉｖｅｒ：Ｃ／Ｅが１に等しい（コマンドを指す）場合、Ｄｒｉｖｅｒは、このコマンドの主ターゲットであるドライバのＡＲ＿ＤＲＩＶＥＲ数を含む。Ｃ／Ｅが１に等しく、Ｄｒｉｖｅｒが０ｘＦ（ＡＲ＿ＤＲＩＶＥＲ＿ＡＬＬ）のとき、ターゲットは、すべてのＡＲＸｘｘｘオブジェクトである。Ｃ／Ｅが０（イベントを指す）の場合、Ｄｒｉｖｅｒは、イベントを生じたドライバのＡＲ＿ＤＲＩＶＥＲ数を含む。

Ｓｅｑ：Ｃ／Ｅが１に等しい（コマンドを指す）場合は、コマンドシーケンス番号である。Ｃ／Ｅが０に等しい（イベントを指す）場合は、（１）予め受信されているコマンドのＳｅｑフィールドのシーケンス番号であって、このイベントがある特定のコマンドへの応答であることを示すか、または（２）０であって、このイベントが、予め受信されているコマンドに応答して生成されたものではないことを示す。

Ｆ／Ｓ：Ｃ／Ｅが０に等しい場合、Ｆ／Ｓは、セットされて、ＡＲ＿ＣＯＭＭＡＮＤ構造が、少なくとも部分的に誤っているイベントを記述していることを示す。Ｖａｌｕｅ１中のデータ（以下を参照）は、不完全または正しくないものである可能性がある。このビットは通常、ＡＲＸｘｘｘドライバが、ＡＲＰｏｌｉｃｙからのコマンドの処理を試みたが、失敗した場合にセットされる。この場合、コマンドＩＤは、ＡＲＰｏｌｉｃｙからのコマンドを含む。

Ｖａｌｕｅ１：特定のコマンドまたはＩＤに示されるイベントに関連づけられた、またはそれによって定義されるデータ（コマンド引数やイベント値など）を含む。

イベントＩＤのいくつかの例は、次の通りである。

ＡＲＰＣ＿ＥＶＥＮＴ＿ＥＮＴＥＲ＿ＳＭＡＲＴＯＦＦ：Ｖａｌｕｅ１およびＶａｌｕｅ２は、このイベントに対して両方ともゼロである。

ＡＲＰＣ＿ＥＶＥＮＴ＿ＥＸＩＴ＿ＳＭＡＲＴＯＦＦ：Ｖａｌｕｅ１およびＶａｌｕｅ２は、このイベントに対して両方ともゼロである。

例示的なコマンドは、次のものであり得る。

ＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥ：Ｖａｌｕｅ１はゼロであり、Ｖａｌｕｅ２は、ＡＲＰＯＬＩＣＹ＿ＳＴＡＴＥ構造を含む。

ＡＲＰｏｌｉｃｙは、イベント通知を受け取ると常に、そのイベントがシステムの常時動作可能な状態に対して与える効果を評価する。イベントが、システムの常時動作可能な状態に変化を生じさせると、ＡＲＰｏｌｉｃｙは、ＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥというコマンドＩＤをもつＡＲ＿ＣＯＭＭＡＮＤを構築し、ＡＲＰＯＬＩＣＹ＿ＳＴＡＴＥ構造によって記述される、システムの新たな常時動作可能状態を、コマンド通知が実施されるときにＶａｌｕｅ２に入れて渡す。

例示的なＡＲＰＯＬＩＣＹ＿ＳＴＡＴＥ構造の形式が、図１１に示される。図１１に示されるように、ＡＲＰＯＬＩＣＹ＿ＳＴＡＴＥフィールドの定義は、次の通りである。

ＰｏｗｅｒＳｔａｔｅ：システムの現在のＳ状態（Ｓ０〜Ｓ５）、またはＳ０−Ｌｏｏｋｓ−Ｏｆｆ。

ＣｐｕＵｓａｇｅ：十分位での現在のＣＰＵ使用率（すなわち、１から１０の値は、１０％から１００％を意味する）。

アプリケーション：ビットマスクであり、０〜１４の範囲の各ビットは、活動しているある特定の「常時動作可能認識」アプリケーションを表す。ビット番号は、レジストリ中の常時動作可能認識アプリケーションの名称からなる配列への索引である。ビット１５は、セットされると、１つまたは複数の追加「常時動作可能認識」アプリケーションが現在活動していることを示す。

Ｒｅｓｅｒｖｅｄ：こうしたフィールドは、将来の利用のために予約されているので、無視される。

ＡＲＸｘｘｘドライバ以外の協働カーネルモードエンティティも、ＡＲＰｏｌｉｃｙに状態変化情報を伝達することができる。こうしたエンティティは、イベントコールバック（ＡＲＰＣ＿ＥＶＥＮＴ＿ＣＡＬＬＢＡＣＫ＿ＮＡＭＥ）をオープンし、ＡｒＸｘｘｘドライバに関して前述したようにこのコールバックを通知することによって伝達を行い、ＡＲ＿ＣＯＭＭＡＮＤ構造および追加ＤＷＯＲＤ引数（Ｖａｌｕｅ２）を渡す。協働エンティティは、常時動作可能な一連のソフトウェアの一体型部分ではないので、ＡＲ＿ＣＯＭＭＡＮＤ構造のドライバフィールドをＤＲＩＶＥＲ＿ＯＴＨＥＲにセットし、ＳｅｑおよびＳ／Ｆフィールドをゼロにセットする。

例えば、協働ＨＩＤデバイス用のドライバは、システムをＳ０−Ｌｏｏｋｓ−Ｏｆｆ状態に入らせるＨＩＤ出現イベントをＡｒＰｏｌｉｃｙに通知しようとし得る。ＨＩＤドライバは、次のようなコードを用いて通知を遂行し得る。

上記の例において、ＤｅｖｉｃｅＥｘｔｅｎｓｉｏｎ−＞ＳｍａｒｔＯｆｆＣａｌｌｂａｃｋは、予めオープンされている、（ＡＲＰＣ＿ＥＶＥＮＴ＿ＣＡＬＬＢＡＣＫ＿ＮＡＭＥという名称の）コールバックオブジェクトへのポインタを含む。協働エンティティは、常時動作可能な１組のソフトウェアの一体設計されたメンバではないので、コマンドコールバックオブジェクト（ＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＣＡＬＬＢＡＣＫ＿ＮＡＭＥ）をオープンしないことが好まれる。ただし、このようなエンティティは、ＡＲＰｏｌｉｃｙからのターゲットデバイス変更通知を登録することによって、システムの常時動作可能な状態における変化を通知され得る。このことは、本文書の他の箇所で説明される。

ＡＲＰｏｌｉｃｙは、カスタムターゲットデバイス変更通知ＰｎＰイベントを送ることによって、ユーザモードコンポーネントと、一体型および非一体型協働カーネルモードコンポーネント両方とに、システムの常時動作可能な状態における変化を伝達する。ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムは、ＧＵＩＤを用いて、ターゲットデバイス変更通知イベントを識別する。常時動作可能であることは、ユーザモードおよび他の協働エンティティとの通信用に定義される、２つの具体的なターゲットデバイス変更通知イベントを定義する。

ＡＲＰＯＬＩＣＹ＿ＣＯＭＭＡＮＤ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤ：このＧＵＩＤに関連づけられたイベントがトリガされると、送られるカスタムデータは、前述した、同じ３２ビットＡＲ＿ＣＯＭＭＡＮＤおよび３２ビットのＶａｌｕｅ２の値となる。

ＡＲＰＯＬＩＣＹ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤ：このＧＵＩＤに関連づけられたイベントがトリガされると、１バイトのカスタムデータが送られる。０の値は、システムがＳ０であることを示すのに用いられ、１の値は、システムがＳ０−Ｌｏｏｋｓ−Ｏｆｆ状態であることを示す。

（動作フェーズ）
前述したように、このプロジェクトの一部として開発されたドライバは、ＷＤＭ ＰｎＰおよび電源管理ガイドラインに完全に準拠する。こうしたドライバは、次のようにインスタンス化される。

ＡＲＰｏｌｉｃｙ：ルートが、Ｒｏｏｔ＼ＡＲＰｏｌｉｃｙとして列挙される。

ＡＲＥｎｖ：ルートが、Ｒｏｏｔ＼ＡＲＥｎｖとして列挙される。

ＡＲＨｉｄＦｌｔ：ＨＩＤクラスドライバの上部フィルタとしてロードする。

ＡＲＡＣＰＩ：ＡＣＰＩ定義デバイスにおいて、ＡＣＰＩ＼ＰＮＰｘｘｙｙをロードする。

システムの起動中、ＡＲＰｏｌｉｃｙ以外のすべてのＡＲＸｘｘｘドライバは、ＡＲＰｏｌｉｃｙがそのインターフェース（ＡＲＰＯＬＩＣＹ＿ＤＲＩＶＥＲ＿ＩＮＴＥＲＦＡＣＥ）を可能にするのを待つ。ＡＲＰｏｌｉｃｙのインターフェースが動作可能にされると、システムの常時動作可能な状態に影響を与えるイベントを発生させるドライバが、システムの開始状態を示すイベントを発生させる。こうした初期状態は、ＡＲＰｏｌｉｃｙによって、システム用に第１のＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドを構築するのに用いられる。上記のイベントがＡＲＰｏｌｉｃｙによって受け取られるとすぐに、第１のＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドが、コマンドコールバック通知およびＡＲＰＯＬＩＣＹ＿ＣＯＭＭＡＮＤ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤというＧＵＩＤのターゲットデバイス変更通知両方を介して発行される。このコマンドの受け取りに先立ち、個々のＡＲＸｘｘｘドライバは、そのデバイスを適切なデフォルト状態に設定することができる。システムの起動中、ＡＲＰｏｌｉｃｙは、ＡＲＰＯＬＩＣＹ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤに対するカスタムターゲットデバイス変更通知を発行してもしなくてもよい。したがって、起動中、この通知を使用する要素は、システム状態がＳ０であると仮定するものとする。

通常のシステム動作の間、ＡＲＸｘｘｘドライバおよび協働エンティティは、適切なように、そのハードウェアと対話する。各ＡＲＸｘｘｘドライバは定期的に、ただし５秒以上の間隔をおかず、そのコンポーネントの状態を判定し、システムの常時動作可能な状態に物理的に影響を与えるどの変化も、イベントを起こすことによってＡＲＰｏｌｉｃｙに送信する。

ＡＲＰｏｌｉｃｙは通常、システムの常時動作可能な状態における変化の結果としてのみ、（コールバック通知、ならびにＡＲＰＯＬＩＣＹ＿ＣＯＭＭＡＮＤ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤおよびターゲットデバイス変化イベントをトリガすることにより）ＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドを発行する。しかし、コンポーネントは、連続する同一のＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドの受信を受諾できることが好ましい。

良質のユーザ経験、および「リアルタイム」と同程度に近接したフィードバックをもたらすために、ＡＲＰｏｌｉｃｙは、Ｅｎｔｅｒ Ｓｍａｒｔ ＯｆｆまたはＥｘｉｔ Ｓｍａｒｔ Ｏｆｆイベントを受け取ると、Ｓ０−Ｌｏｏｋｓ−Ｏｆｆ状態における変化を指すＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドを用いて、カスタムターゲットデバイス変化イベントを、ＡＲＰＯＬＩＣＹ＿ＣＯＭＭＡＮＤ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤにトリガする。このトリガは、ＡＲＳｅｒｖｉｃｅおよび他のこのようなエンティティが、要求があった時間とできるだけ近い時間にヒューマンインターフェース対話を実施することを可能にする。

どの追加保留状態変化も収集するための適切な一定期間の後、ＡＲＰｏｌｉｃｙは、（少なくとも）Ｓ０−Ｌｏｏｋｓ−Ｏｆｆ状態における変化を反映する新たなシステム状態を有するＡＲＰＣ＿ＣＯＭＭＡＮＤ＿ＳＥＴ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＳＹＳＴＥＭ＿ＳＴＡＴＥコマンドを発行する。このコマンドは、コールバック通知およびＡＲＰＯＬＩＣＹ＿ＣＯＭＭＡＮＤ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤをもつカスタムターゲットデバイス変更通知を介して送られる。引き続き、カスタムターゲットデバイス変更通知も、新たなＳ０−Ｌｏｏｋｓ−Ｏｆｆ状態を示すためにＡＲＰＯＬＩＣＹ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤに送られる。

ＡＲＰｏｌｉｃｙは、ほとんどの協働システムコンポーネントにシステムのエントリを通知し、ＡＲＰＯＬＩＣＹ＿ＡＬＷＡＹＳ＿ＲＥＡＤＹ＿ＮＯＴＩＦＩＣＡＴＩＯＮ＿ＧＵＩＤというＧＵＩＤによって識別されるカスタムターゲットデバイス変化イベントを介して、Ｓ０−Ｌｏｏｋｓ−Ｏｆｆ状態から出る。ＡＲＰｏｌｉｃｙは通常、状態が変化したときにのみ、このターゲットデバイス変化イベントをトリガするが、このイベントを使用するエンティティは、この通知とともに含まれるカスタムデータバイトを調べて、システムのＳ０／Ｓ０−Ｌｏｏｋｓ−Ｏｆｆ状態に本当に変化があったかを調べ、それにしたがって行動する。

（コンポーネントのレジストリ値）
常時動作可能なシステム内の一体型コンポーネントのデフォルト動作は、プラットフォーム要件に従って調整され得る。この調整は好ましくは、レジストリのエントリを使って行われる。レジストリのエントリは、以下のようになり得る。

ＫｅｙＰｒｏｃｅｓｓｅｓ：システムがスマートオフであるときに「ＣＰＵ ｃｅｉｌｉｎｇ」を上げさせる、実行可能な画像の名称リスト。

ＰｒｏｃｅｓｓＴｉｍｅｒ：ＡＲＰｏｌｉｃｙポーリング間隔をミリ秒で表す時間。

ＢｌａｎｋＤｉｓｐｌａｙ：スマートオフに入るときに、ディスプレイがブランクになるべきかどうかを示すブール値。

ＰａｕｓｅＭｅｄｉａ：メディアプレーヤの、現在オープンしているインスタンスが、スマートオフに入るときに一時停止されるべきかどうか、およびスマートオフを出るときに再開されるべきかどうかを示すブール値。

ＭｕｔｅＡｕｄｉｏ：スマートオフに入るときに主オーディオがミュートされるべきかどうかを示すブール値。

ＴｈｒｏｔｔｌｅＰｒｏｃｅｓｓｏｒ：スマートオフに入るときに、プロセッサが、可能な最も低いＰ状態まで速度を低下させられるべきかどうかを示すブール値。

ＥｎｔｅｒＫｅｙｓ：システムをスマートオフに入らせるＨＩＤページおよびキー使用のリスト。

ＤｏｎｔＰａｓｓＥｘｉｔＫｅｙｓ：システムをスマートオフから抜けさせるＨＩＤページおよびキー使用のリスト。

ＰａｓｓＥｘｉｔＫｅｙｓ：システムをスマートオフから抜けさせるＨＩＤページおよびキー使用のリスト。

スマートオフ機能は、オペレーティングシステムのカーネルを介して遂行され得ることに留意されたい。オペレーティングシステム内部での実装形態は概して、ＯＳがユーザによってそうするように構成されている場合、電源ボタンが押下されるとシステムをより低電力の「Ｓ０」状態におくことを含むように電源管理ポリシーを修正することからなる。この実装形態は、ＣＰＵにおける電力を低下させるのに既存の機構（他の２つの実装形態で用いられるものと同じ）を用いること、およびより低電力のＳ０状態になるときにファン動作を変えるためのＡＣＰＩサーマルゾーンをＢＩＯＳ内に実装することを伴う。さらに、画面消去、オーディオミュートも、内部ＯＳ機構を介して、またはサービスを介して処理されるであろう。

本発明は、様々な図面の好ましい実施形態に関連して説明されたが、本発明から逸脱することなく本発明の同じ機能を実施するために、他の類似の実施形態が使用されることもでき、説明した実施形態に修正および追加が行われ得ることが理解されるべきである。例えば、本出願において述べた本発明は、有線または無線にかかわらず、どのコンピューティングデバイスにも環境にも当てはまり、通信ネットワークを介して接続され、ネットワーク経由で相互作用するこのような任意の数のコンピューティングデバイスに適用され得ることを当業者は理解するであろう。さらに、ハンドヘルドデバイスのオペレーティングシステムおよび他のアプリケーション特有のオペレーティングシステムを含む様々なコンピュータプラットフォームが考慮され、特に、無線ネットワーク接続される装置の数は増加し続けることが強調されるべきである。さらに、本発明は、複数の処理チップまたは装置の内部でも、それらに渡っても実装されることができ、同様に、複数の装置に渡って格納され得る。したがって、本発明は、どの１つの実施形態にも限定されるべきではなく、添付の特許請求の範囲による範囲内で解釈されるべきである。

本発明の態様が実装され得る、例示的な計算機環境を示すブロック図である。 ＳＭＢｕｓインターフェースおよび関連するコンポーネントを示すブロック図である。 本発明の処理のフローチャートを示す図である。 本発明の処理のフローチャートを示す図である。 本発明による、ＡＣＰＩ／スマートオフ状態に対する電力使用を示すグラフ表す図である。 電源とともに使用するヒートシンクを示す図である。 ＣＰＵとともに使用するヒートシンクを示す図である。 グラフィックスカードとともに使用するヒートシンクを示す図である。 本発明のソフトウェアコンポーネントの概観を示す図である。 ＡＲ＿ＣＯＭＭＡＮＤの例示的なコマンド構造を示す図である。 ＡＲＰＯＬＩＣＹ＿ＳＴＡＴＥの例示的なコマンド構造を示す図である。

符号の説明

１００ 計算機環境
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定式不揮発性メモリインターフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ 着脱式不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１６１ マウス
１６２ キーボード
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
２００ ＳＭＢｕｓインターフェース
２０２ ＳＭＢｕｓシステムホスト
２０４ 電源
２０６ 他のＳＭＢｕｓデバイス

Claims (8)

1. 擬似オフ状態をもつコンピューティングデバイスであって、電源を通る気流の向きと合致する第１のフィン配向を有する電源ヒートシンクを有する電源であって、前記電源ヒートシンクは、乱気流を誘導するための第１のクロスカットをさらに含む電源と、
   ２種類の金属からなる外側部およびベースを有するＣＰＵヒートシンクを有する中央処理装置と、
   画像処理装置上方の気流の向きと合致する第２のフィン配向を有するＧＰＵヒートシンクを有するグラフィックス処理装置であって、前記ＧＰＵヒートシンクは、乱気流を誘導するための第２のクロスカットをさらに含む画像処理装置と、
   ハードディスクドライブと、
   ランダムアクセスメモリとからなるシステムコンポーネントを備え、
   前記コンピューティングデバイスがパワーダウンするための信号を受信すると、前記コンピューティングデバイスがオフに見えるように前記システムコンポーネントを低電力、低アコースティックエミッションとし、かつ入力を破棄することによってヒューマンインターフェースデバイスをロックすることによって、前記コンピューティングデバイスは、擬似オフ状態におかれ、
   前記コンピューティングデバイスは、前記擬似オフ状態にあるとき、アプリケーションの実行を可能にされたままであることを特徴とするコンピューティングデバイス。
2. 前記ヒューマンインターフェースデバイスに予め定義された入力シーケンスの入力があると、前記コンピューティングデバイスは、擬似オフ状態から通常動作状態に変わることを特徴とする請求項１に記載のコンピューティングデバイス。
3. 前記システムコンポーネントに関連づけられたソフトウェアドライバを定期的にポーリングするポリシードライバをさらに備えることを特徴とする請求項１に記載のコンピューティングデバイス。
4. 前記システムコンポーネントの電源管理特徴を制御するソフトウェアドライバに、前記システムコンポーネントを前記低電力状態におくための要求を送ることを特徴とする請求項１に記載のコンピューティングデバイス。
5. 前記ソフトウェアドライバは、前記システム内のプロセッサに、最低電力状態までクロックを下げるよう命令し、ディスプレイ信号を中断してモニタをオフにし、システムオーディオをミュートし、メディアの再生を一時停止し、入力デバイスをロックし、電源出力を削減し、冷却ファンをオフにし、前記コンピューティングデバイスが前記擬似オフ状態にあることを示すことを特徴とする請求項４に記載のコンピューティングデバイス。
6. 前記ポリシードライバは、前記システムコンポーネントが前記低電力の状態より多くの電力を使用することを必要とするアプリケーションをモニタし、より多くの電力を必要とする前記アプリケーションを処理するために、前記コンピューティングデバイスは、前記擬似オフ状態から前記通常動作状態に戻されることを特徴とする請求項４に記載のコンピューティングデバイス。
7. 前記システムコンポーネントがより多くの電力を使用することを必要とする前記アプリケーションが終了した後、前記擬似オフ状態に戻されることを特徴とする請求項６に記載のコンピューティングデバイス。
8. 前記コンピューティングデバイスが前記擬似オフ状態にあるとき、前記コンピューティングデバイスはＡＣＰＩ Ｓ０状態にあり、
   所定の期間の後、前記コンピューティングデバイスはＡＣＰＩ Ｓ３状態に入ることを特徴とする請求項３に記載のコンピューティングデバイス。

Images