JP4611210B2 - 非メインｃｐｕ／ｏｓベースの動作環境 - Google Patents

Description

発明の分野は一般にはコンピューティングに、より詳細には非メインＣＰＵ／ＯＳベースの動作環境に関する。

Ａ．コンピューティングシステム
図１はコンピューティングシステム１００の実施例を示している。このコンピューティングシステムは中央処理装置（ＣＰＵ）１０１、キャッシュ１０２、メモリ・Ｉ／Ｏコントロール１０３、システムメモリ１０４を含んでいる。このコンピューティングシステムによって実行されるソフトウェア命令（およびその対応データ）はシステムメモリ１０４およびキャッシュ１０２に保存される（ここで、頻繁に使われる命令およびデータがキャッシュ１０２に保存される）。前記ソフトウェア命令（対応データと合わせて）はＣＰＵ１０１によって実行される。メモリ・Ｉ／Ｏコントロール１０３のメモリコントローラ部分は、システムメモリ１０４（グラフィクスコントローラ１０５およびさまざまなＩ／Ｏユニットのような、ＣＰＵ１０１以外の機能要素によって使用されることもある）へのアクセスを管理することを受け持っている。

グラフィクスコントローラ１０５およびディスプレイ１０６は当該コンピューティングシステム１００のユーザーが見るコンピュータ生成画像を提供する。メモリ・Ｉ／Ｏコントロール機能１０３のＩ／Ｏコントローラは、システムメモリ１０４（もしくはＣＰＵ１０１またはその両方）へのアクセスを、さまざまなＩ／Ｏユニット１０８_１から１０８_Ｎ、そして１０９、１１１、１１３、１１５のために管理することを受け持っている。Ｉ／Ｏユニットは典型的には、コンピューティングシステムとの間で情報を送受信する機能ユニット（たとえば、ネットワークアダプタ、モデム、無線インターフェース、キーボード、マウスなど）もしくはコンピューティングシステムの情報を該コンピューティングシステム１００内に保存しておくのに用いられる機能ユニット（たとえばハードディスクドライブユニット）またはその両方であると見なされている。

コンピューティングシステム内には、しばしばさまざまなＩ／Ｏユニットが見られる。さらに、コンピューティングシステム内には、しばしばＩ／ＯユニットとＩ／Ｏコントロール機能との間の通信のためのさまざまな種類のインターフェースが見られる。しばしば、これらのインターフェースは業界標準によって定義される。図１に示した代表例としてのコンピューティングシステム構成は、異なるＩ／Ｏユニット１０８_１から１０８_Ｎをつなぐことのできるシステムバスインターフェース１０７と、異なるインターフェース１１０、１１２、１１４、１１６とを示している。前記異なるインターフェース１１０、１１２、１１４、１１６のそれぞれは、図１では、対応する独自のＩ／Ｏユニット１０９、１１１、１１３、１１５を有するものとして描かれている。

コンピュータシステムによってインターフェースの数が異なりうること、コンピュータシステムによってインターフェースの種類（たとえばインターフェースあたりのＩ／Ｏユニットの最大数やインターフェース技術などの面での種類）が異なりうることを注意しておく。可能な実装のほんの一例として、図１のコンピューティングシステムをテンプレートに使うと：（１）システムバス１０７はＰＣＩバス、（２）インターフェース１１０はシリアルポート、（３）インターフェース１１２はＵＳＢインターフェース、（４）インターフェース１１４はシリアルインターフェース、（５）インターフェース１１６はＩＤＥインターフェース（または他の記憶装置インターフェース）となる。

Ｂ．コンピューティングシステムの状態図
図２はコンピューティングシステムについての従来技術の状態図を示している。図２に見られる動作状態の実施例は、ＡＣＰＩ（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ［先進構成・電力インターフェース］）規格２００２年３月３１日付修正版２．０ａ（コンパック・コンピュータ社、インテル社、マイクロソフト社、フェニックス・テクノロジーズ社、東芝社によって公表されている）に見出すことができる。ＡＣＰＩ規格は既存のコンピューティングシステムの多くを記述するものとして認識されているが、ＡＣＰＩ規格に適合しない多くのコンピューティングシステムでも図２に見られる動作状態構成に適合することはできる。その意味で、図１の記載は、ＡＣＰＩ規格が適合しているより一般的な仕様に対応するものである。

図２の描写によると、「通常のオン」状態２０１と称される第一の状態２０１は、当該コンピュータの通常の動作状態（すなわち、当該コンピュータの電源が投入されて活動し、ユーザーによって使われている（あるいはいつでも使えるようになっている）状態）である。ＡＣＰＩ規格内では、「通常のオン」状態２０１は「Ｇ０」状態と称されている。第二の状態２０２は、当該コンピューティングシステムが「オフ」であると認識される一つ以上の状態の任意のいずれかを指す。ＡＣＰＩ規格はそのような状態として二つを認識する：ハードウェア的なオフ状態（たとえば、システム全体から電力が除去されている）およびソフトウェア的なオフ状態（システムには電力が供給されているが、ＢＩＯＳとＯＳ（オペレーティング・システム）を、保存されている先の動作環境のコンテキストには関わりなくゼロから読み込む必要がある）である。ＡＣＰＩ規格はハードウェア的オフ状態を「Ｇ３」状態、ソフトウェア的オフ状態を「Ｇ２」状態と称している。

第三の状態２０３は、当該コンピューティングシステムが「スリープ」と認識される一つ以上の状態の任意のいずれかを指す。スリープ状態については、「通常のオン」状態２０１におけるシステムの動作環境（たとえば、さまざまなソフトウェアルーチンの状態やデータ）が、コンピュータのＣＰＵが低電力消費状態にはいるのに先立って保存されている。スリープ状態２０３は、コンピューティングシステムの連続的な使用中、中休みの間ＣＰＵによって消費される電力を節約することをねらいとしたものである。すなわち、たとえば、ユーザーがコンピューティングシステムを通常のオン状態２０１で使っていて（たとえば文書を打っているなど）、あるとき別のことをして一時的にそのような使用をやめたとしたら（たとえば電話に出るなどして）―当該コンピューティングシステムは自動的に通常のオン状態２０１からスリープ状態２０２に遷移し、システム電力消費を低減させる。

ここで、コンピューティングシステムのソフトウェア動作環境（たとえば、書きかけの文書も含む）―「コンテキスト」とも称する―は前もって保存されている。その結果、ユーザーが別の用事が終わったのちコンピューティングシステムの使用に戻ってきたとき、コンピューティングシステムは自動的に、前記の別の用事が生じたときに存在していた環境を（保存されているコンテキストを呼び出すことによって）ユーザーに提示する。これはスリープ状態２０３から通常状態２０１に戻る遷移過程の一部として行われる。ＡＣＰＩ規格はさまざまなスリープ状態（特に「Ｓ１」「Ｓ２」「Ｓ３」「Ｓ４」状態）の集合を認識し、そのそれぞれが電力節約と「通常のオン」状態２０１に戻るときの遅れとの間の独自の兼ね合いに対応している（ここで、Ｓ１、Ｓ２、Ｓ３状態は「待機」のさまざまな種類として認識され、Ｓ４状態は「ハイバーネーション」状態である）。

しかしながら、従来技術のスリープ状態の問題は、ＣＰＵがいかなる有用な仕事も実行できないということである。そのままでは、電力消費は認識されているが、コンピューティングシステムがスリープ状態の期間中に実行すれば有益であるはずのいかなるタスクも実行することができないのである。

本発明は下記の記述および本発明の実施例を図解するのに使われている付属の図面を参照することで最もよく理解できる。

動作可能な低電力状態を有する状態図およびコンピューティングシステム
コンピューティングシステムが低電力消費状態において有用なタスクを実行するためには、システムに特別な状態を作り込まなければならない。特に、これらの特別な状態は、一つ以上の有用なタスクが実行できるよう十分な機能上の実力をもち、それと同時に「通常のオン」状態に対応するよりも電力消費の割合が低くなるよう構成されるべきである。ここで、図３および図４Ａから図４Ｃはそのような特別な状態を二つもつコンピューティングシステムの実施例を示している。

図３は状態図を提示している。図４Ａから図４Ｃは、代表的なコンピューティングシステムのさまざまな構成要素で、低電力状態に強制移行させられていないもの、あるいは有用なタスクを実行しうる各状態の低電力状態に強制移行させられているものを示す代表例としての描写である（ここで、影を付けた領域は構成要素が非アクティブな低電力状態内にとどまることを強制されていることを示し、影を付けていない領域は構成要素が非アクティブな低電力状態にとどまることを強制されていないことを示している）。下記でより詳細に説明するように、図４Ａから図４Ｃに見られるコンピューティングシステムそのものも、非アクティブ低電力状態を強制された構成要素と非アクティブ低電力状態を強制されていない構成要素の特定の組み合わせも、いずれも単なる代表例であり、実施形態によって異なりうるものであることに注意しておくことが重要である。

図３に見られる方式の状態図では、コンピューティングシステムには有用なタスクを実行できる主要な状態が三つある：（１）高電力の「通常のオン」状態３０１、（２）「メインＣＰＵ／ＯＳベースの低電力」状態３０４、（３）「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５である。図４Ａから図４Ｃは単一のコンピューティングシステムについての上記の三つの状態のそれぞれの代表的な実施形態を示している。これらの状態のそれぞれについて、すぐ次に簡単に概観し、そのあとに「メインＣＰＵ／ＯＳベースの低電力」状態３０４および「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５のより本格的な議論にはいる。

図４Ａは「通常のオン」状態３０１にあるコンピューティングシステムの実施形態を示している。影を付けた構成要素がない、すなわちこのコンピューティングシステムのさまざまな構成要素のどれ一つとして非アクティブな低電力状態に強制的に移行させられたものはないことに注意しておく。さまざまな実施形態において、コンピューティングシステムの構成要素の少なくとも一部は自らの電力消費を検知された使用状態に応じて制御する（たとえば、最低電力消費状態から最高電力消費状態へ）権限を与えられている。ここでは、構成要素は非アクティブな低電力状態への移行を強制されないので、自らの電力消費を制御する能力を有する構成要素は、「通常のオン」状態３０１内では自由にそうすることができる。

これに対し、図４Ｂは同じコンピューティングシステムが「メインＣＰＵ／ＯＳベースの低電力」状態３０４に移行されたあとの実施形態を示している。ここで、ある構成要素（影を付けて示している）は非アクティブな低電力状態への移行を強制されている。今の設定と一貫するよう、自らの電力消費を制御する権限を有しており、非アクティブな低電力状態への移行を強制されることになっている構成要素は、電力制御権限を剥奪された上で最低電力消費状態への移行を強制される。ここで、「非アクティブ」の用語は、電力保存のため当該構成要素がその主たる機能を停止していることを意味することに注意しておく。メインＣＰＵは非アクティブとはなっておらず、したがってソフトウェアプログラムの実行を続けることができることに注意しておく。

図４Ｃは同じコンピューティングシステムが「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５に移行されたあとの実施形態を示している。ここで、図４Ｂに比べて影を付けたものが増えていることにも示されるように、さらなる構成要素（特にＣＰＵ）が非アクティブ低電力状態に置かれていることに注意しておく。

すぐ次に「メインＣＰＵ／ＯＳベースの低電力」状態３０４および「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５についてのより本格的な議論が与えられる。

図３および図４Ｂを参照すると、「メインＣＰＵ／ＯＳベースの低電力」状態３０４は、メインＣＰＵ４０１が電源投入されていてソフトウェアを実行できる状態に対応している。しかし、全体としての電力消費は「通常のオン」状態３０１に比べて低減している。メインＣＰＵはメインＯＳ（オペレーティング・システム）に基づいてソフトウェアを実行できるので、状態３０４は「メインＣＰＵ／ＯＳベースの」と称される。電力は、すぐ次に記載する技術のうちの一つまたは複数によって節減しうる。

（１）ＣＰＵ以外のコンピューティングシステム構成要素で自らの電力消費を動的に制御する判断機能／能力のあるものが、自らの電力消費を動的に制御する権限を剥奪され、代わりに最低電力状態に強制移行させられる。たとえば、ＡＣＰＩ準拠システムの場合、コンピューティングシステム内のさまざまな構成要素（ディスプレイ、グラフィクスコントローラ、さまざまなＩ／Ｏデバイス（ハードディスクドライブのような）など）が自らの電力消費を制御する権限を与えられている（たとえば、デバイスドライバを通じて観測される使用状態に基づいて）。その仕方はＤ０からＤ３までの複数の状態に応じたものであり、Ｄ０状態が最高電力の動作状態、Ｄ３状態が最低電力の非動作状態である（Ｄ１およびＤ２も非動作状態であり、この順に電力消費が少なくなる）。ある実施形態では、「メインＣＰＵ／ＯＳベースの低電力」状態３０４は、意図的にある一部の構成要素が、当該システムが「メインＣＰＵ／ＯＳベースの低電力」状態３０４にある限り恒久的にＤ３状態にとどまるように設定する。ＡＣＰＩ以外のシステムでも同じような設定はできる。図４Ｂでは、最低電力状態に強制移行させられている構成要素は影を付してある。これによると、図４Ｂの例では、グラフィクスコントローラ４０５、ディスプレイ４０６、Ｉ／Ｏユニット４０８_２から４０８_Ｎが最低電力状態に強制移行させられている。別の実施形態では、当該システムが「メインＣＰＵ／ＯＳベースの低電力」状態３０４にある間、電源の電圧を下げたり除去したりするよう、ある一部の構成要素を設計することが可能となりうる。

（２）ＣＰＵが複数の異なる電力消費状態の間で電力消費を動的に調整する（たとえば、内部電圧レベルもしくはクロック周波数またはその両方を動的に変えることによって）機能をもっていれば、そのＣＰＵは最低電力状態で（または複数ある最低電力状態の一つで）動作するよう強制される。たとえば、インテルのスピードステップ（ＳｐｅｅｄＳｔｅｐ、商標）技術に基づくＣＰＵは異なる「Ｐ_ｎ」状態Ｐ_０からＰ_４をもつことができる。ここで、Ｐ_０が最高電力状態で、Ｐ_４が最低電力状態である。スピードステップ（商標）技術に基づくＣＰＵは、電圧と周波数の両方を下げることによって電力を節減し、パフォーマンスをそれほど下げることなく消費電力を劇的に低下させることができる。スピードステップ（商標）技術に基づくＣＰＵを用いる実施形態においては、コンピューティングシステムが「メインＣＰＵ／ＯＳベースの低電力」状態３０４にある間、ＣＰＵはＰ_４状態で動作するよう強制される（アプリケーションの方針によっては、次に低い電力状態Ｐ_３に上がれる特別な例外を認めることも可能であるが）。電圧と周波数の一方または両方を下げることによって電力を節減するが、それでもスピードステップ（商標）技術に基づくＣＰＵではない他のＣＰＵも存在するかもしれないことを注意しておく。その意味で、現在記載しているこの技術は、スピードステップ（商標）技術に基づくＣＰＵおよびスピードステップ（商標）技術に基づくものでないＣＰＵの両方について実装しうるものである。より詳細な実施形態においては、最低電力状態にありながら内部クロック周波数が調整できる限り、該クロック周波数は、当該プロセッサが適正に動作できる最低のクロック周波数にセットされる。

（３）「メインＣＰＵ／ＯＳベースの低電力」状態３０４では使わないアプリケーションソフトウェアプログラムを定義しておき、この状態にある間はその使用を一時停止する。「メインＣＰＵ／ＯＳベースの低電力」状態３０４および「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５の実装に有用でも必要でもないと見なされるソフトウェアタスクまたはアプリケーションはすべて、非常に少ないシステム消費電力を実現するために一時停止することができる。例としては、スクリーンセーバー、ワープロアプリケーション、プレゼンテーション／グラフィックアプリケーション、そして表計算アプリケーションの全部または一部が含まれうる。さらに、バッチ計算ジョブはすべて、状態３０４および３０５での動作の間、一時停止することができる。

（４）複数のメインＣＰＵを有するコンピューティングシステムおいては（すなわち、図１のＣＰＵ１０１が実際には複数のＣＰＵを含む）、アクティブ状態ではたらくＣＰＵの数が減らされ（たとえば、「通常のオン」状態３０１の間はＮ個のメインＣＰＵを有するシステムにおいて）、「メインＣＰＵ／ＯＳベースの低電力」状態３０４の間はそのようなメインＣＰＵのうち一つだけがアクティブとなる。

図３および図４Ｃを参照すると、「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５は、メインＣＰＵ４０１が電源を落とされ、当該コンピューティングシステムのメインＯＳをベースとしてはソフトウェアを実行できない状態に対応する。図４Ｃの例においては、キャッシュ４０２、システムメモリ４０４、そしてメモリ・Ｉ／Ｏコントロールユニット４０３の少なくともメモリコントローラ部分もまた、非アクティブな低電力状態に強制移行させられている（これらは主としてメインＣＰＵ４０１がソフトウェアを実行するはたらきを助けるものなので）。メインＣＰＵ４０１が活動していないので、状態３０５は「非メインＣＰＵ／ＯＳベース」である。さらに、少なくともＣＰＵ４０１が非アクティブにされているので、状態３０５は状態３０１や３０４と比べて「より低電力」である。よって、状態３０５は「非メインＣＰＵ／ＯＳベースのより低電力」状態と称することができる。ただし、状態３０５にある間強制的に非アクティブにされる構成要素の正確な組み合わせは実施形態によって変わりうることに注意しておくことが重要である（たとえば、一例として、システムメモリ４０４は「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５にある間もアクティブに保ち、その状態３０５においてもシステムメモリ４０４を使えるようにシステムを設計することも可能である）。

実施例：フルセットのコードレス電話システム
状態３０１、３０４、３０５を（たとえば、図４Ａから図４Ｃに見られるコンピューティングシステム電力管理プロファイルに従って）取り入れることによって、コンピューティングシステムがさまざまな電力消費節減段階にあるときにある種のタスクを生み出すよう特別仕立てにすることができ、結果として効率改善が期待できる。この手法の可能性を示すには例を示すのが役に立つ。図５は例として、図３および図４Ａから図４Ｃで概観したコンピューティングシステムで実装できる、「フルセットの」、それでいてエネルギー効率のよい、コードレス電話システムを示している。ここで、フルセットのコードレス電話システムというのは、（１）基本的なコードレス電話機能（すなわち、従来型の素朴な電話サービス［ＰＯＴＳ：Ｐｌａｉｎ Ｏｌｄ Ｔｅｌｅｐｈｏｎｅ Ｓｅｒｖｉｃｅ］のインターフェースおよびコードレス電話とＰＯＴＳインターフェースとの間の無線接続）、（２）該コードレス電話が発信者の呼び出しに応答されずにいた場合に発信者のメッセージを録音する留守番電話機構、（３）ネットミーティングの相手として適切な発信者に関連付けられている発信者ＩＤに反応してインターネット上での対話をお膳立てするネットミーティング（Ｎｅｔ Ｍｅｅｔｉｎｇ）エンジン、を提供するシステムのことである。

前述のフルセットのコードレス電話システムの基本的な実装とは、図５に見られるように、（１）「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５からの基本的なコードレス電話機能、（２）「メインＣＰＵ／ＯＳベースの低電力」状態５０４からの留守番電話機能、（３）「通常のオン」状態５０１からのネットミーティングエンジン、を実装するものである。基本的なコードレス電話機能を「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５から実装することによって、当該コンピューティングシステムは、その使用状態の要求するままに、「単なる」基本的コードレス電話機能と完全な機能を備えたコンピューティングシステムとの間で容易に自らを転換させて行ったり来たりできる。背後にあるコンピューティングシステムとしての図４Ａから図４Ｃを参照すると、（１）ネットミーティングエンジンは図４Ａの完全なコンピューティングシステムを用いて実装され、（２）留守番電話は図４Ｂのより低電力のメインＣＰＵ／ＯＳベースの範囲内のシステムを用いて実装され、（３）基本的コードレス電話機能はＩ／Ｏユニット４０８_１を用いて実装されていることに注意されたい。

今述べた機能の実装が、それに対応する機能／処理能力と電力消費の要求とも一貫していることを注意しておく。すなわち、基本的なコードレス電話機能は少数の単純な構成要素から容易に構築でき、したがって、（１）単一のＩ／Ｏユニット（Ｉ／Ｏユニット４０８_１のような）に容易に統合でき、（２）電力消費が少ない（全コンピューティングシステムに比べて）。この意味で、基本的コードレス電話機能は、コンピューティングシステムの「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５レベルの機能の一つとしてＩ／Ｏユニット４０８_１に組み込む設計とするのに理想的な機能である。

それに対し、留守番電話機能はより複雑な機能で、（１）応答されなかった呼び出しの発信者に聞かせる録音メッセージ、（２）該発信者が録音するメッセージ（もしあれば）の両方のための記録リソースを必要とする。その意味で、留守番電話機能をＩ／Ｏユニットに統合することも可能であるが、録音メッセージの保存のためにはコンピューティングシステムのメインメモリ４０４の記録リソースを使うほうがより経済的であろう。さらに、メインＣＰＵ４０１およびメインＯＳは録音メッセージを再生する処理を管理するアプリケーションソフトウェアを実行するのに利用することができる（再生というのは、呼び出しに応答されなかった発信者と発信者のメッセージを聞きたいコンピューティングシステムユーザーの両方に対する再生を含む）。

また、留守番電話はしばしば、ユーザーが電話に出られないときにメッセージを録音することに注意しておく。その意味で、たいていの場合、ディスプレイ４０６とグラフィクスコントローラ４０５の電源がはいっていなくても不都合はない（たとえば、ユーザーが自宅にいなくて電話に出られない場合、ユーザーはディスプレイ４０６をインターフェースとしてコンピューティングシステムと対話することもできないわけである）。さらに、メインＣＰＵ４０１およびメインＯＳは今述べた留守番電話の動作を補佐するのに使うことができるというとき、留守番電話タスクは典型的なコンピューティングシステムＣＰＵ４０１にとって決して「高機能」タスクではないことに注意しておく。結果として、これらのタスクは、メインＣＰＵ４０１がパフォーマンス／電力消費を下げた状態となるよう（たとえば、使っている内部電圧もしくはクロック周波数またはその両方を下げるよう強制することによって）設定されていたとしても容易に実装できる。

留守番電話についての前述の特徴をすべて合わせて考えると、留守番電話機能は「メインＣＰＵ／ＯＳベースの低電力」状態５０４に好適であることに注意しておく。すなわち、図４Ｂを参照すると、ディスプレイ４０６およびグラフィクスコントローラ４０５は非アクティブであり（電力を節約するため）、メインＣＰＵおよびＯＳはパフォーマンス／電力消費容量を下げた状態で、メッセージの再生と録音機能に使うことができる。結果として、図５では、フルセットの電話システムの留守番電話部分が「メインＣＰＵ／ＯＳベースの低電力」状態５０４を用いて実装されるよう示してある。こうして、ここまでの図５の議論を振り返ってみると、この電話システムのコンピューティングシステムの実装は巧妙にコンピューティングシステムの動作状態と対応している。すなわち、より低電力／より低パフォーマンスの基本的コードレス電話機能は「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５に組み込まれるよう設計され、より高度な留守番電話機能は「メインＣＰＵ／ＯＳベースの低電力」状態５０４に組み込まれるよう設計されているのである。

最後に、図５のフルセットのコードレス電話システムのネットミーティング機能は、当該コンピューティングシステムが「通常のオン」状態５０１にあるときに使われるよう設計されている。ここで、インターネットを通じたやりとりを扱うことを担うソフトウェアはより高級な処理タスクを含みうる（たとえば、レイヤー４フロー制御、ＩＰレイヤーヘッダ処理など）。さらに、インターネット接続は、コードレス電話に付随するＰＯＴＳインターフェースのほかに別のネットワークインターフェース（たとえば無線インターフェース）を通じて確立されることもありうる。その意味で、インターネットでのやりとりは、基本的コードレス電話機能が統合されているＩ／Ｏユニット以外のＩ／Ｏユニット（たとえばＩ／Ｏユニット４０８_２が無線インターフェースを提供するならＩ／Ｏユニット４０８_２）の使用に関わってくることもありうる。こうして、フルセットのコードレス電話システムのネットミーティング機能は、「通常のオン」状態にあるときのコンピューティングシステムに好適である（通常のコンピューティングシステムのインターネット通信機能がだいたいコードレス電話システムのネットミーティング通信機能に転用できるので）。

当該コンピューティングシステムは図５の状態図中のさまざまな状態の間を遷移できるので、上述したフルセットのコードレス電話システムは、「高電力」のコンピューティングシステムと「より低電力」の基本的コードレス電話の間を使用状態に応じて行ったり来たりできるコンピューティングシステムに対応している。たとえば、ほんの一例として、ユーザーが当該コンピューティングシステムを伝統的なコンピューティングシステムの用途（たとえば、文書を書くなど）に使っていたとすると、当該コンピューティングシステムは「通常のオン」状態５０１にある。次にユーザーがこの活動を一時停止して（たとえば、コンピュータに関係のない「何か別のこと」をすることによって）一時的に当該コンピューティングシステムを離れたとすると、当該コンピューティングシステムは自動的に最低電力のアクティブ状態５０５（「非メインＣＰＵ／ＯＳベースのより低電力状態」）まで下がり、機能の面でも消費電力の面でも基本的コードレス電話システムとして振る舞う。ユーザーがコンピューティングシステムを一度に何時間も離れることが多くの場合にありうることを考えると、コンピューティングシステムを自動的により低電力の状態に落とすことにより、コンピューティングシステムは自らの電力消費を使用状態の関数として制御するようになるのである。

このコンピューティングシステムはまたしたがって、伝統的な「高電力」コンピューティングシステムとローエンド機器との間の混成物と見なすことができる。ユーザーがシステムを伝統的なコンピュータ利用の目的に使うとき（たとえば、文書作成、インターネットサーフィンなど）、そのシステムは伝統的なコンピューティングシステムとして振舞う。ユーザーがシステムを伝統的なコンピューティングシステムとして使っていないときは、システムは、そのシステムは低級化して（機能性と電力消費の面で）基本機器となる（今の場合、基本的コードレス電話）。図５に見られる状態図が示すように、当該コンピューティングシステムはさまざまな使用可能状態５０１、５０４、５０５の間を行ったり来たり移行できるが、同様に、該コンピューティングシステムは伝統的なコンピューティングシステムと基本機器の間を行ったり来たり移行することができる。

さらに、すぐ上で述べた例を続けると、ユーザーが一時的にコンピュータを離れたのち、電話を受けてその電話に出ることができなかった場合、コンピューティングシステムは最低電力の動作可能状態５０５から中間電力の動作可能状態５０４への状態遷移を引き起こし、自らを基本的コードレス電話（状態５０５で表している）から留守番電話機能のある基本的コードレス電話（状態５０４で表している）へと転換させる。この場合、システムは自らの機能上の能力および対応する消費電力を、該システムに提示される全体的な使用状況に応じて調整しているのである。

同じ例を続けると、発信者のメッセージを（たとえばシステムメモリ４０４に保存することによって）録音したのち、「メインＣＰＵ／ＯＳベースの低電力」状態５０４ではたらくソフトウェアは（ユーザーが伝統的なコンピューティングシステム用途のために戻ってこなければ）システムをもとのより低電力状態５０５に戻すよう書かれていることもありうる。そうして当該コンピューティングシステムを基本的コードレス電話に戻すのである。このように、これらの状態遷移の観点からは、当該コンピューティングシステムはその機能上の能力および対応する電力消費を伝統的なコンピューティングシステム（状態５０１）と基本機器（状態５０５の基本的コードレス電話）との間で調整することができるのみならず、機能上の能力および対応する電力消費を「中間」機器（状態５０４の留守番電話）に対応するように調整することもできるのである。さらに、さまざまな機能上の能力の間の上述した転換は、時間の流れの中でいかなる使用がされて当該コンピューティングシステムに提示されようともそれに応じて自動的に引き起こされる。

ネットミーティングの確立を引き起こすに足るイベントの系列を示すフルセットのコードレス電話システムの例については、図１１との関連でのちにより詳細に扱う。

状態遷移の方法論と支援ハードウェア
上記の例がさまざまな使用可能状態５０１、５０４、５０５（それぞれ独自の機能上の能力、電力消費の度合いが設定されている）の間で遷移することのできる稼動システムを記述しているが、これらの状態遷移の実装の仕方にもなにがしかの重要性がある。図６Ａ、６Ｂから図８Ａ、８Ｂまではこれらの状態遷移のあらましのためのものである。特に、図６Ａ、図６Ｂは、図３の高電力の「通常のオン」状態３０１と「メインＣＰＵ／ＯＳベースの低電力」状態３０４との間の状態遷移の方法論を示すものである。図８Ａ、図８Ｂは「メインＣＰＵ／ＯＳベースの低電力」状態３０４と「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５との間の状態遷移の方法論を示すものである。図７はその状態遷移過程を補助するのに使える回路設計の実施例である。

図６Ａは、コンピューティングシステムが高電力の「通常のオン」状態３０１から「メインＣＰＵ／ＯＳベースの低電力」状態３０４に遷移するために実行しうる方法論の実施形態を示している。図６Ａの方法論によれば、システムは当初「通常のオン」の高電力状態６０１で「実行中」である。この状態では、システムは伝統的なコンピュータ利用の目的のために使うことができる。ある時点で、「通常のオン」状態から「メインＣＰＵ／ＯＳベースの低電力」状態への遷移のトリガーとなるイベントが検出される（６０２）。このイベントは実施形態によって、またアプリケーションによって異なりうる。

たとえば、単なる例としていくつか挙げると、当該コンピューティングシステムはある一定期間の間ユーザーから何の刺激も与えられなかった（たとえば、ユーザーがマウスを使ったりキーボードで入力したりといった動作をある一定期間の間しなかった）ことを認識するのでもよい。あるいは、当該コンピューティングシステムはユーザーが該コンピューティングシステムのふたを閉めた（当該コンピューティングシステムがラップトップパソコン・ノートパソコンのような携帯機器の場合）、あるいは画面・ディスプレイの電源を切った（当該コンピューティングシステムが典型的な「デスクトップ」パソコンの場合）といったことを認識するのでもよい。このイベントによってシステムが「メインＣＰＵ／ＯＳベースの低電力」状態にはいるか従来技術のスリープ状態３０３状態にはいるかを決める条件にはさまざまなものがあり、実施形態によって、またアプリケーションによって異なることに注意しておく。ほんの一例を挙げれば、もしより低電力のある動作状態がソフトウェア内のフラグを立てることによって「有効」であると認識されているならば（たとえば、基本的コードレス電話システムが有効であると認識されるならば）、システムは自動的に、従来技術のスリープ状態３０３ではなく、より低電力の動作状態３０４、３０５に移行する。

前記検出されたイベント（６０２）に反応して、ＯＳは自らを「メインＣＰＵ／ＯＳベースの低電力」状態にあるとマークする（６０３）。ここで、この低電力だが動作する状態の「メインＣＰＵ／ＯＳ」という部分は、メインＣＰＵもメインＯＳもいまだ動作しており、メインＣＰＵおよびメインＯＳ上で一つ以上のアプリケーションソフトウェアプログラムが実行できるという意味であることを想起されたい。その意味で、ＯＳは、より低電力の状態で動作しているということを正式に認めることができるよう、自らをマークする（６０３）のである。適切なソフトウェアドライバも同様に自らをマークする。これで「メインＣＰＵ／ＯＳベースの低電力」状態３０４が構築または確立される（６０４）。この場合、状態３０４の実装が：（１）さまざまな構成要素（たとえばグラフィクスコントローラおよびディスプレイ）が自らの電力消費を制御する権限を剥奪すること、（２）ＣＰＵをより低パフォーマンス／より低電力消費のモードに強制移行させること、（３）一部のアプリケーションソフトウェアプログラムやタスクをパークさせること、（４）複数のメインＣＰＵがあるシステムではアクティブなメインＣＰＵの数を減らすこと、（５）さまざまな構成要素への電力を切ったり下げたりすること、のうちの一部または全部によって行いうることを想起されたい。「メインＣＰＵ／ＯＳベースの低電力」状態のために非アクティブ化されたソフトウェアはみな、「通常のオン」状態に戻ったときにその動作環境を回復できるよう、そのコンテキストが保存されるようにしておくことができる。ひとたび「メインＣＰＵ／ＯＳベースの低電力」状態が構築されれば、システムはその状態で実行される（６０５）。

「メインＣＰＵ／ＯＳベースの低電力」状態から「通常のオン」状態へのシステムの遷移は、図６Ｂにその実施形態が見られるが、だいたい、前記の「通常のオン」状態から「メインＣＰＵ／ＯＳベースの低電力」状態への遷移の逆として実装できる。すなわち、図６Ｂを参照すると、「メインＣＰＵ／ＯＳベースの低電力」状態で実行中（６０６）に「通常のオン」状態への状態遷移を引き起こすトリガーとなるイベントが検出される（６０７）。ここでもまた、トリガーイベント６０７の性質についての詳細は実施形態によって、またアプリケーションによって変わりうる。図５の関連で先に述べた留守番電話の場合、トリガーイベント６０７は、今受けた電話についてネットミーティングを確立する必要があるとの認識でよい。

トリガーイベント６０７に反応して、ＯＳおよび関連するデバイスドライバは自らを「通常のオン」状態にあるとマークする（６０８）。これで「通常のオン」状態が確立または構築される（６０９）（たとえば、さまざまな構成要素に自らの電力消費を制御することを認めたり、メインＣＰＵにより高いパフォーマンス／より高い電力消費モードで動作することを許可したり、「パークされた」アプリケーションソフトウェアプログラムを再びアクティブにしてそのコンテキストを回復したり、さまざまな構成要素にその本来の電源を再び供給したりすることによって行う）。ひとたび「通常のオン」状態が確立されれば、システムは「通常のオン」状態で実行される（６１０）。

「メインＣＰＵ／ＯＳベースの低電力」状態の間、メインＣＰＵ／ＯＳは電源がはいって、起きたままにされているので、メインＣＰＵおよびメインＯＳは、「通常のオン」状態と「メインＣＰＵ／ＯＳベースの低電力」状態の間の状態遷移過程の間、スリープさせられることはない。これに対し、「非メインＣＰＵ／ＯＳベースのより低電力」状態の「非メインＣＰＵ／ＯＳ」という部分は、メインＣＰＵ／ＯＳが非アクティブ状態にされていることを表している。つまり、「非メインＣＰＵ／ＯＳベースのより低電力」への遷移はメインＣＰＵ／ＯＳをスリープ状態にすることを含んでいるのである。一般に、スリープさせられたメインＣＰＵ／ＯＳが「起きる」とき、「目覚め」過程の初期段階は、全コンピューティングシステムが全体として最初に電源投入されるとき、あるいはコンピューティングシステムがリセット状態から抜け出すときに実行される過程と同様である。すなわち、基本ＢＩＯＳソフトウェアが読み込まれ、ＯＳそのものと一緒に実行される必要があるのである。

最初の電源投入やリセット動作とスリープ状態からの復帰との間の根本的な違いは、スリープ状態から復帰するときには、システムがスリープ状態から復帰するところだということを初期のソフトウェア読み込み過程が認識しているという点である。この認識が今度は先に保存されたコンテキストの再読み込みを引き起こす。これに対し、最初の電源投入やリセットからの立ち上げの際には、そのような認識もコンテキストも存在しない。ここで、システムが最初の電源投入やリセットから立ち上げているところなのかスリープ状態から立ち上げているところなのかを（そして場合によってはシステムがどのようなスリープ状態から起きようとしているのかを）当該システムが判断できるように、目覚め過程の間、特定の調査対象位置に保存されている一つ以上の特定のビットが使われる。一つ以上のビットによってシステムがスリープ状態から復帰しているところだということが示されれば、システムがもとの環境に復帰できるよう、保存されていたコンテキストが回復される。

これらの調査対象ビットが存在するということは、メインＣＰＵ／ＯＳがスリープ中の期間も、ＣＰＵ、メモリコントローラ、Ｉ／Ｏコントローラ機能のうちの一部または全部に関連するハードウェアの限られた一部は電源投入状態のまま残ることを意味している。この限られたハードウェアの実施例が図７に見られる。図７の特定の回路設計は、「非メインＣＰＵ／ＯＳベースのより低電力」状態にはいることで開始されたスリープ状態からの復帰に対応するばかりでなく、従来技術のＡＣＰＩ準拠のスリープ状態からの復帰とも両立できる。その意味で、図３と図７を参照すると、ＡＣＰＩ互換システムで図７の回路設計を使えば、（１）伝統的なスリープ状態３０３からの遷移、（２）「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５からの遷移、の両方を扱うことができる。

さまざまな実施形態において、スリープ状態からの復帰に使われる回路（図７の回路のような）はメモリコントローラもしくはＩ／Ｏコントローラまたはその両方の機能と統合される。さらなる実施形態では、メモリコントローラ機能は第一の半導体チップを用いて実装され、Ｉ／Ｏコントローラ機能は第二の半導体チップを用いて実装される。この場合、スリープ状態からの復帰に使われる回路（図７の回路のような）はメモリコントローラの半導体チップかＩ／Ｏコントローラの半導体チップかのいずれかに統合してもよい。

さて、図７を参照すると、目覚めようとしているシステムに該システムがスリープ状態から目覚めるのか最初の電源投入やリセット状態から立ち上げるのかを示す「調査対象」ビットは、ビット７０２に対応している（ＷＡＫ＿ＳＴＳ）。このＷＡＫ＿ＳＴＳビット７０２の状態を決定する処理については、のちにより詳細に説明する。ＳＬＰ＿ＥＮビット７１２とＳＬＰ＿ＴＹＰビット７１３はシステムが全体として伝統的な「非動作」スリープ状態（たとえば、図３の状態３０３）にはいるときに書き込まれる。ここで、ＳＬＰ＿ＥＮビット７１２はシステムが伝統的な非動作スリープモードにはいろうとしていることを示し、ＳＬＰ＿ＴＹＰビット７１３ははいろうとしている伝統的な非動作スリープ状態の特定の種類（たとえば、ＡＣＰＩベースのシステムのＳ０からＳ４）を示す。図７の特定のＳＬＰ＿ＴＹＰの実施例では３つのビットを使っている。

システムが伝統的な非動作スリープ状態にはいろうとしているとき、ＳＬＰ＿ＥＮビット７１２およびＳＬＰ＿ＴＹＰビット７１３がともに、目覚め／スリープロジック７０１によって、コンピューティングシステム内での適切な電源電圧体系を確立するために使われる。すなわち、伝統的なスリープ状態モードはそれぞれの種類ごとに独自の電源電圧体系（ある構成要素は電源を切り、ある構成要素は電源電圧を下げるなど）をもつことができる。出力７０９が、指示された伝統的なスリープモードのための適切な電源体系を実装するのに使われる。もしある特定のスリープモード体系が一つ以上の構成要素について電源電圧を調整するのではなく論理的に無効にするような場合（たとえば、入力クロックを止めたり、無効ビットをオンにしたりすることなどによって）、目覚め／スリープロジック７０１および出力７０９は無効化の目的にも使うことができる。

ＮＭＣ／Ｏ＿ＥＮビット７１０はシステムが「メインＣＰＵ／ＯＳベースの低電力」状態３０４から「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５に遷移する際に書き込まれる。ここで、「非メインＣＰＵ／ＯＳベースのより低電力」状態は独自の電源電圧体系（たとえば、特定の構成要素ごとにどれは電源を切り、どれは電圧を下げるなどといったことに関するもの）をもっていることができる。ある実施例では、目覚め／スリープロジック７０１は、「非メインＣＰＵ／ＯＳベースのより低電力」状態に固有の電源体系が実施されようとしていることを示すために、特別のＮＭＣ／Ｏ＿ＥＮ入力ビット７１０をもっている。

それに代わるある実施例では、「非メインＣＰＵ／ＯＳベースのより低電力」状態にあっても「スリープ」の概念がＳＬＰ＿ＥＮビット７１２およびＳＬＰ＿ＴＹＰビット７１３によってマークされる（たとえば、「非メインＣＰＵ／ＯＳベース」状態を表すためにＳＬＰ＿ＴＹＰビットの独自の、これまで使われていなかった組み合わせを用いることによって）。ここで、ＮＭＣ／Ｏ＿ＥＮビットは、これが１であれば、目覚め／スリープロジック７０１に遷移しようとしている先が「非メインＣＰＵ／ＯＳベースのより低電力」状態であるということを通知する追加情報として使われることができる。いずれにせよ、出力７０９が適切な電源体系を確立するのに使われる。ここでもまた、「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５が一つ以上の構成要素の電源電圧を調整するのではなく論理的に無効にするような場合（たとえば、入力クロックを止めたり、無効ビットをオンにしたりすることなどによって）、目覚め／スリープロジック７０１および出力７０９は無効化の目的にも使うことができる。

多入力ＯＲゲート７０３の入力ビット７０４、７１４は目覚めイベントのビットである。すなわち、メインＣＰＵ／ＯＳを伝統的なスリープ状態または「非メインＣＰＵ／ＯＳベースのより低電力」状態から目覚めさせるのに足るイベントが到来すると、これらの入力ビット７０４、７１４の少なくとも一つがオンになる。これによって正味の７０８もオンになり、それが今度はＷＡＫ＿ＳＴＳビット７０２がオンになるようにする。ＷＡＫ＿ＳＴＳビット７０２がオンになるのに反応して、メインＣＰＵ／ＯＳはスリープ状態から目覚めようとしていることを認識し、次いで、何がシステムが起こされる原因となったのかをさらに認識するためにビット７０４、７１４を調べることができる。さらに、実装によっては、メインＣＰＵ／ＯＳは「非メインＣＰＵ／ＯＳベースのより低電力」状態から目覚めようとしていることを、ＮＭＣ／Ｏ＿ＥＮビット７１０の状態またはＮＭＣ／Ｏ＿ＳＴＳビット７１４の状態を読むことによって認識することができる。

ＮＭＣ／Ｏ＿ＥＮビット７１０はシステムが「非メインＣＰＵ／ＯＳベースのより低電力」状態にはいるときにオンにセットされているので、ある実施例では、目覚めの際にビット７１０を読み込むことによってシステムが「非メインＣＰＵ／ＯＳベースのより低電力」状態から目覚めようとしていることを認識することができる。この場合、ビット７１０は、書き込みも（「非メインＣＰＵ／ＯＳベースのより低電力」状態への移行について）読み出しも（「非メインＣＰＵ／ＯＳベースのより低電力」状態からの遷移について）できるという意味で、読み出し／書き込みビットであることを注意しておく。この特定の場合には、ＮＭＣ／Ｏ＿ＳＴＳビット７１４は単に図７の回路にシステムが「非メインＣＰＵ／ＯＳベースのより低電力」状態から引き出されようとしている（すなわち、目覚めイベントが生起した）ことを通知するためだけに使われる。

システムが「非メインＣＰＵ／ＯＳベースのより低電力」状態にはいろうとしていることを示すのにＳＬＰ＿ＴＹＰビット７１３が使われる（たとえば、ＳＬＰ＿ＴＹＰビット設定の独自の、これまで使われていなかった組み合わせによって）別の実施形態では、これらの同じＳＬＰ＿ＴＹＰビットが、システムが「非メインＣＰＵ／ＯＳベースのより低電力」状態から起きようとしていることを認識するために読み込まれる。別の実施形態では、システムは、該システムが「非メインＣＰＵ／ＯＳベースのより低電力」状態から目覚めようとしているのかどうかを認識するためにＮＭＣ／Ｏ＿ＳＴＳビット７１４を調べるよう構成される（すなわち、目覚めのときにビット７１４がオンであれば、システムは「非メインＣＰＵ／ＯＳベースのより低電力」状態から目覚めるところである）。ビット７０４は伝統的な目覚めイベントに対応する「従来技術」のＡＣＰＩビットである（たとえば、ラップトップパソコン・ノートパソコンの先に閉じたふたが開くイベントに対するＬＩＤ＿ＳＴＳビット）。

図８Ａおよび図８Ｂはそれぞれ、コンピューティングシステムの「メインＣＰＵ／ＯＳベースの低電力」状態３０４から「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５への遷移（図８Ａ）、そして「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５から「メインＣＰＵ／ＯＳベースの低電力」状態３０４への遷移（図８Ｂ）を示している。図８Ａを参照すると、システムは当初は「メインＣＰＵ／ＯＳベースの低電力」状態８０１で実行されている。ある時点で、システムの「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５への移行を引き起こすに足るイベントが検出される（８０２）（たとえば、図５の留守番電話機能５０４が応答のなかった発信者からの電話の録音を完了して、ユーザーもコンピューティングシステムに戻ってこなかったなど）。

結果として、メインＣＰＵおよびメインＯＳはスリープさせられる（８０５）。このことには、（１）ＯＳおよびドライバにその処理に備えさえ、コンテキストを保存し（８０３）、（２）メインＣＰＵ／ＯＳが「非メインＣＰＵ／ＯＳベースのより低電力」状態にはいるためスリープさせられようとしていることを記録し（たとえば、図７のＮＭＣ／Ｏ＿ＥＮビット７１０、もしくはＳＬＰ＿ＥＮビット７１２およびＳＬＰ＿ＴＹＰビット７１３、またはその両方を１にすることによって）、「非メインＣＰＵ／ＯＳベースのより低電力」の電力消費状態を構築する（８０４）（たとえば、ＣＰＵ，メモリコントローラ、システムメモリなどのパワープレーンを、たとえば目覚め／スリープロジック７０１によって提供される形で電力を下げることによって）ことが関わってくる。これがなされたのちは、システムは「非メインＣＰＵ／ＯＳベースのより低電力」状態から実行される（８０６）。

図８Ｂは、コンピューティングシステムが伝統的なスリープ状態３０３または「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５のどちらかから目覚める際にたどりうるより一般的な目覚め処理の流れを示している。図８Ｂの処理によれば、目覚めイベント８０７がメインＣＰＵがスリープ状態を抜け出すトリガーを与え、ＢＩＯＳソフトウェアが読み込まれる（８０８）。伝統的なスリープ状態からの遷移の場合、目覚めイベント８０７としては、ユーザーがシステムのところに戻ってきたといった指示（たとえば、図７のＬＩＤ＿ＳＴＳ入力に対応する、閉じたノートパソコン・ラップトップパソコンのふたを開けることなどによる）がありうる。「非メインＣＰＵ／ＯＳベースのより低電力」状態からの遷移の場合、目覚めイベント８０７は前記「より低電力」状態内では動作できない機能（たとえば、電話に出なかったことに応ずる留守番電話）を使う必要によって引き起こされうる。

ＢＩＯＳが読み込まれて適切なハードウェアが初期化されるのに反応して、システムの制御はメインＯＳに渡され、該メインＯＳが目覚めイベント８０７が伝統的なスリープ状態３０３からの遷移に対応するものか「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５からの遷移に対応するものかを判断する（８０９）。ここで、実施形態によっては、メインＯＳは図７のビット７１２、７１０、７１４のうちの一部または全部を参照してこの判断８０９を行う。システムが伝統的なスリープ状態３０３から遷移しようとしているのであれば、従来技術の目覚めシーケンスが実行される（８１０）。もしＯＳが、システムが「非メインＣＰＵ／ＯＳベースのより低電力」状態から遷移しようとしていると判定した場合には、メインＯＳは非メインＣＰＵ／ＯＳベースのサブシステムがそのトリガーイベントを生成した原因を理解しようと試みる（８１１）。

ここで、非メインＣＰＵ／ＯＳのより低電力のサブシステムがソフトウェアを実行するプロセッサを含んでいる場合には（のちに図９との関連でより詳細に説明するように）、メインＣＰＵ／ＯＳは非メインＣＰＵ／ＯＳのより低電力のサブシステムにメッセージを送って、トリガーイベント８０７が生成された原因を判定させる。非メインＣＰＵ／ＯＳサブシステムがソフトウェアを実行しない場合には、メインＯＳは、たとえば、非メインＣＰＵ／ＯＳによってセットされた追加的なハードウェアビットを調査し、トリガーイベント８０７の素性についてメインＯＳに通知することができる。

遷移が伝統的なスリープ状態３０３からのものである場合、図７の目覚め／スリープロジック７０１が適正にハードウェアを「通常のオン」状態（たとえば図４Ａに見られるような）にまで立ち上げるようにさせるために、図７のビット７１０をオフにすることができる。同様に、実施形態によっては、遷移が「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５からのものである場合は、目覚め／スリープロジック７０１が適正にハードウェアを「メインＣＰＵ／ＯＳベースの低電力」状態（たとえば図４Ｂに見られるような）にまで立ち上げるようにさせるために、ビット７１０もしくはビット７１２またはその両方をオフにすることができる。

非メインＣＰＵ／ＯＳベースのより低電力状態のハードウェアおよびソフトウェア設計
これから図９Ａおよび図９Ｂを補助に使って、「非メインＣＰＵ／ＯＳベースのより低電力」状態に対して可能なハードウェアおよびソフトウェア設計について、より詳細に議論していく。ここで、今の議論はもともと図４Ｃに関連して提示された議論を敷衍させたものと見ることができる。暫時先の図４Ｃを参照して、「非メインＣＰＵ／ＯＳベースのより低電力」状態を実装するために使われるハードウェアの簡略版が提示されていたことを想起されたい。そこでは、より具体的に言うと、単一のＩ／Ｏユニット４０８_１がアクティブとなって非メインＣＰＵ／ＯＳ状態３０５を実装していたのであった。

これに対し、今見ている敷衍した非メインＣＰＵ／ＯＳ状態３０５のハードウェアの実装は、より低電力／より低パフォーマンスのコンピューティングシステムで識別可能なソフトウェアおよびＩ／Ｏを有するものと見なすことができる。図９Ａがその例を示している。図９Ａの描写では、メインＣＰＵ／ＯＳベースのシステムを有するコンピューティングシステムが示されている（これにはメインＣＰＵ９０１、キャッシュ９０２、システムメモリ９０４、グラフィクスコントローラ９０５、メインディスプレイ９０６などが含まれる）。メインＣＰＵ／ＯＳベースのシステムの主要構成要素の多くは、「非メインＣＰＵ／ＯＳベースのより低電力」状態では非アクティブにされている。図４Ａから図４Ｃの構成と同様、「非メインＣＰＵ／ＯＳベースのより低電力」状態で非アクティブにされている構成要素は図９Ａでも影付きの領域として描かれている。

ここで、図９Ａの実施形態によれば、「非メインＣＰＵ／ＯＳベースのより低電力」状態を実装するのに使われるコンピューティングシステムに含まれるものとしては、自らの独自の：（１）コントローラ９１７（これは、メインＣＰＵに比してより低パフォーマンス／低電力のプロセッサ、マイクロコントローラ、論理状態機械などによって実装されうる）、（２）主メモリ９１８（これは、メインシステムメモリ９０４に比してより低速のＲＡＭ［ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ランダムアクセスメモリ］もしくはより低密度のＲＡＭまたはその両方を用いて実装されうる）、（３）ユーザーインターフェース９２５（これにはディスプレイ９１９、キーボードやボタン９２０、ＬＥＤ９２４が含まれうる）、（４）システムバス９２３、（５）Ｉ／Ｏユニット９２２（これは、単なる一例として挙げると、フラッシュベースのメモリまたはポリマーベースのメモリのような記憶リソースを用いて実装されうる）、（６）フラッシュメモリ９２１、がある。

上に特記した顕著な構成要素とは別に、「非メインＣＰＵ／ＯＳベースのより低電力」状態を実装するために使われるコンピューティングシステムはまた、さまざまなＩ／ＯユニットをメインＣＰＵ／ＯＳコンピューティングシステムと共有しうることを注意しておく。図９Ａの実施形態においては、共有されるＩ／Ｏユニットに含まれるものとして：（１）モデムユニット９０９、（２）無線ローカルエリアネットワーク（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）ユニット９１１、（３）無線広域ネットワーク（ＷＷＡＮ：Ｗｉｒｅｌｅｓｓ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）ユニット９１３、がある。ここで、これらの「共有された」Ｉ／Ｏユニット９０９、９１１、９１３は「非メインＣＰＵ／ＯＳベースのより低電力」状態の間もアクティブである。これ以外の共有Ｉ／Ｏインターフェースユニットも可能である（たとえばブルートゥース）。さまざまな実施形態において、「共有された」Ｉ／Ｏユニットは、前記一対のコンピューティングシステム（メインＣＰＵ／ＯＳおよび非メインＣＰＵ／ＯＳ）において、「非メインＣＰＵ／ＯＳベースのより低電力」状態にないときにはメインＣＰＵ／ＯＳシステムからコマンドを受け、「非メインＣＰＵ／ＯＳベースのより低電力」状態にあるときは非メインＣＰＵ／ＯＳシステムからコマンドを受けることによって動作する。また、共有されたＩ／Ｏユニットがメインシステムバス９０７につなげられうることも可能である（たとえば、Ｉ／Ｏユニット９０８_Ｎが通信インターフェース９２６によって表されているような形で）。

ある実施形態では、インターフェース９１０、９１２、９１４、９１６（これらは「非メインＣＰＵ／ＯＳベースのより低電力」状態の間、非アクティブである）に対応するのはそれぞれ：（１）インターフェース９１０には、シリアルポートインターフェース（この場合、モデム９０９はより詳細にはＶ．９０モデム９０９に対応しうる）、（２）インターフェース９１２には、ＩＥＥＥ８０２．１１ベースのネットワークインターフェースカードとしてＵＳＢインターフェース、（３）インターフェース９１４には、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅｓ［汎用パケット無線サービス］）無線モデムとしてシリアルインターフェース、（４）インターフェース９１６には、ＩＤＥハードディスクドライブ（ＨＤＤ）のためのＡＴＡ−１００インターフェース、である。より詳細な実施例では、メモリ・Ｉ／Ｏコントロール機能９０３のＩ／Ｏコントローラ部分から発するＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ［ユニバーサルシリアルバス］）インターフェース（図９Ａでは簡単のため示さず）が「非メインＣＰＵ／ＯＳベースのより低電力」状態で非アクティブにされ、これにはブルートゥースＩ／Ｏユニットが含まれる。ただし、ブルートゥースインターフェースユニットはまた、共有にして、「非メインＣＰＵ／ＯＳベースのより低電力」状態の間もアクティブでいられるようにすることも可能である。

別の実施形態では、システムバス９２３はシステムバス９０７と同一とすることができる。この場合、「通常のオン」状態３０１では、コントローラ９１７に加えてメインＣＰＵ９０１はデバイス９０８_１から９０８_Ｎにアクセスできる。しかし、システムが「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５にあるときは、コントローラ９１７はデバイス９０８_１から９０８_Ｎにシステムバス９２３／９２７（今の実施形態では同じバスだが、そのことは簡単のため図９Ａには示していない）を通じてアクセスできる。今の実施形態では、デバイス９０８_１から９０８_Ｎは「非メインＣＰＵ／ＯＳベースのより低電力」状態３０５にあってもコントローラ９１７がアクセスできるようにアクティブなまま（影なし）となるはずであることに注意しておく。

非メインＣＰＵ／ＯＳシステムは自らの独自のインターフェース９２５を含みうることに注意しておく。図９Ａの実施形態では、この独自のユーザーインターフェースにはＬＥＤ９２４（その状態はコントローラ９１７によって制御される）、ディスプレイ９１９、キーボード／ボタン９２０が含まれているように示されている。ユーザーインターフェース９２５はその機械的な位置や配置によって「非メインＣＰＵ／ＯＳベースのより低電力」状態に関する独自性を高めることができる。特に、モバイルコンピューティングの応用分野（たとえば、ラップトップパソコンやノートパソコン）では、ユーザーインターフェース９２５は、メインディスプレイ９０６のふたが閉じられてメインキーボードを覆っているときでも、ユーザーがディスプレイ９１９およびＬＥＤ９２４を見たり、あるいはキーボード／ボタン９２０を使ったり、あるいはその両方をしたりすることができるように位置・配置することができる。図９Ｂは、一対のラップトップまたはノート型コンピューティングシステムのそれぞれが該コンピューティングシステムの「ふた」を閉じているときでもアクセスできるユーザーインターフェースをもっている様子を示している。

このふたを閉じた状態でのユーザーインターフェース上でアクセスしうるデータの例としてはカレンダー、連絡先、行動予定表、すなわちいわゆる個人情報管理（ＰＩＭ：Ｐｅｒｓｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）データがある。しかし、この種のデータに限られるものではなく、「ふたを閉じた」状態でノートパソコンを使うエンドユーザーにとって大切でありうるいかなる情報をも含むことができる（たとえば、外回りの営業員にとっての現在の売り上げデータなど）。追加的に、全体としてのコンピューティングシステムは、ふたを閉じた状態でのユーザーインターフェースを通じてノートパソコン内の機能を制御できるようにしてあってもよい。その例としてたとえば、コンピュータに保存してあるＭＰ３音楽ファイルの無線ヘッドホンを通じての再生を挙げることができる。この場合、ユーザーは音楽（選択した楽曲、アルバム、その他の種類）の再生をふたをした状態でのユーザーインターフェースを通じて制御できるのである。

図９Ａに戻って、非メインＣＰＵ／ＯＳコンピューティングシステムはコントローラ９１７を用いて実装でき、このコントローラ９１７は今度はマイクロプロセッサまたはマイクロコントローラとして実装できる。その結果、非メインＣＰＵ／ＯＳコンピューティングシステムが自分のソフトウェアルーチンを実行するような実施形態が想定される。図１０は非メインＣＰＵ／ＯＳコンピューティングシステムのソフトウェア（図１０の右側）がどのようにメインＣＰＵおよびメインＯＳによって実行されるソフトウェアと協働しうるかを実地に説明する図である。すなわち、非メインＣＰＵ／ＯＳコンピューティングシステムが「通常のオン」状態および「メインＣＰＵ／ＯＳベースの低電力」状態の両方の間、電源がオンでアクティブのままでいることを想起すると、両方のシステム（メインＣＰＵ／ＯＳおよび非メインＣＰＵ／ＯＳ）からのソフトウェアが、「通常のオン」状態または「メインＣＰＵ／ＯＳベースの低電力」状態のいずれの間でも、協働しあう全体として一緒に動作するような「デュアルシステム」を実装することが可能である。図１０はこの関係を実地に説明しようと試みるものである。

図１０は、ラップトップまたはノートパソコンのふたを閉じた状態で関心のあるエンドユーザーのデータにアクセスしたり、有用なエンドユーザー機能を制御したりするために、ふたを閉じた状態でのユーザーインターフェースを用いたシステム（図９Ｂに示したようなもの）の実施形態と見なすことができる（これのみに限られるものと理解してはならないが）。図１０は動作の機能が図３で説明した異なるシステム状態、すなわち「通常のオン」状態３０１、「メインＣＰＵ／ＯＳベース」の状態３０４、「非メインＣＰＵ／ＯＳベース」の状態３０５の間でどのように配分されるかを示している。

図１０の右側は非メインＣＰＵ／ＯＳコンピューティングシステムのソフトウェア構成要素を示している。これらは以下の非メインオペレーティングシステム（すなわち、非メインＯＳ）構成要素を含んでいる：（１）アプリケーションプログラマーズインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｅｒ’ｓ ｉｎｔｅｒｆａｃｅ）１００１、（２）管理機能１００２（イベント管理ルーチンと機能管理ルーチンの両方を含むことができる）、（３）データ記憶管理機能１００３（非メインＣＰＵ／ＯＳコンピューティングシステムがその独自のデータ記憶リソース（図９Ａのフラッシュメモリやポリマーメモリのような）を使用するのを制御するためのもの）、（４）ユーザーインターフェース管理機能１００４（非メインＣＰＵ／ＯＳコンピューティングシステムがその独自のユーザーインターフェース（図９Ａのユーザーインターフェース９２５のような）を使用するのを制御するためのもの）。

アプリケーションソフトウェア１００５、１００６もこの非メインＣＰＵ／ＯＳコンピューティングシステムに存在しうる。アプリケーションソフトウェアは典型的には次の二つの種類に分けられる：（１）データ記憶１００５（保存されたデータの使用・管理に向けられる）、（２）機能１００６（根底にあるコントローラ９１７によって実行される有用な機能に向けられる）。

典型的なソフトウェア環境の場合と同様に、非メインＣＰＵ／ＯＳコンピューティングシステムのアプリケーション１００５、１００６も非メインＣＰＵ／ＯＳコンピューティングシステムのＯＳとはＡＰＩ１００１を通じて接する。

「非メインＣＰＵ／ＯＳベースのより低電力」状態にあるとき、非メインＣＰＵ／ＯＳコンピューティングシステム（ソフトウェア構成要素１００１から１００６も含めて）は独立して動作する。また、メインＣＰＵ／ＯＳが「非メインＣＰＵ／ＯＳベースのより低電力」状態の間は非アクティブであるため、メインＣＰＵ／ＯＳ上で走るソフトウェア構成要素１００７から１０１２も同様に非アクティブである。しかし、全体としてのシステムが「通常のオン」状態または「メインＣＰＵ／ＯＳベースの低電力」状態にあるときには、メインＣＰＵ／ＯＳ上で走るさまざまなソフトウェア構成要素がアクティブとなる。それに加えて、非メインＣＰＵ／ＯＳコンピューティングシステムはこのどちらの状態でもアクティブのままなので、両システムからのソフトウェアは協働しあう全体として一緒に働きうるのである。

たとえば、非メインＣＰＵ／ＯＳコンピューティングシステムの制御下のあるリソースを認識していることによって、メインＣＰＵ／ＯＳ側のソフトウェアがこれらのリソースを「使う」よう構成することも可能となる。たとえば、メインＣＰＵ／ＯＳコンピューティングシステム上のソフトウェアルーチンを、非メインＣＰＵ／ＯＳコンピューティングシステム独自のデータ記憶リソースやメモリリソース（図９Ａのユニット９１８、９２１、９２２のような）を使用するよう構成することも可能となるのである。もう一つの例として、メインＣＰＵ／ＯＳコンピューティングシステム上のソフトウェアルーチンを、非メインＣＰＵ／ＯＳコンピューティングシステム独自のユーザーインターフェースに付随するさまざまなリソースの状態に影響を与えるよう構成することも可能となる。たとえば、のちにより詳細に説明するように、「メインＣＰＵ／ＯＳベースの低電力」状態の範囲内で実装されたコードレス電話の留守番電話機能（図５に関連して説明したような）において、非メインＣＰＵ／ＯＳベースのユーザーインターフェースに付随しているＬＥＤ（図９ＡのＬＥＤ９２４のような）を反復的につけたり消したりと明滅させたくなることもありうる（たとえば、ユーザーが聞くべきメッセージが録音されていることをユーザーに通知するためなど）。そのような実施例についてはのちに図１１との関連でより詳細に述べる。

メインＣＰＵ／ＯＳソフトウェア１００７から１０１２は、非メインＣＰＵ／ＯＳソフトウェア１００１から１００６と「協働」するため、非メインＣＰＵ／ＯＳコントローラ９１７にある動作を要求するメッセージを送ることもありうるし、記憶装置１００３のためのデータオブジェクトを渡すこともできる。ここでもアプリケーションソフトウェアはデータアプリケーション１００９、１０１０および機能アプリケーション１０１３、１０１１に分けられる。ところが、これらのアプリケーションのうちの一部１００９、１０１３は非メインＣＰＵ／ＯＳコンピューティングシステム上のリソースが利用可能であるという理解のもとにあらかじめ書かれていることがありうる。その一方、他の（たとえば、古い「レガシー」の）ソフトウェアアプリケーション１０１０、１０１１はそのようなリソースが存在するという認識も情報もなく書かれていることがありうる。後者の種類のソフトウェアアプリケーションについては、「接着剤レイヤー」として振舞う「プロキシ」ソフトウェア１００７、１００８を使って、レガシーアプリケーションを強制するなり他の方法を使うなりして非メインＣＰＵ／ＯＳコンピューティングシステムのリソースと協働的に動作できるようにすることができる。機能ブロック１００２、１００３、１００４によって、ユーザーはユーザーインターフェース９２５との対話によりＰＩＭその他の情報を表示したり、ＭＰ３ファイル再生のような何らかの機能を制御したりすることができる。マネージャ１００２はデータオブジェクトを受け取り、受け取ったデータオブジェクトは次いで記憶ブロック１００３に保存される。これらのデータオブジェクトはユーザーインターフェースに表示すべきデータ（ＰＩＭその他のデータ）を表しており、データアプリケーション１００５、１０１０、１００９に発するものである。アプリケーション１０１０および１００７は「通常のオン」状態３０１において動作し、これによって提供されるデータオブジェクトがマネージャ１００２のもとＡＰＩ１００１を通じて記憶１００３に保存される。レガシーデータアプリケーション１０１０の例としてはアウトルック（商標）やロータスノーツ（商標）の現在のバージョンがある。これらはＰＩＭデータを含んでいるが、ユーザーインターフェース１００４が理解できるデータオブジェクトを生成する方法についても、それらのオブジェクトを記憶１００３に移動させる方法についても、全く知らないのである。プロキシアプリケーション１００７がこの機能を担っており、本質的なところでは、レガシーアプリケーションから適切なデータを引き出し、正しいデータオブジェクトに整形し、それからそのデータオブジェクトを、記憶１００３に保存されるよう、マネージャ１００２にＡＰＩ１００１を通じて渡す。将来、これらの種類のアプリケーションはこうしたエクスポート機能を内蔵するようになるだろう。そうしたものがデータアプリケーション１００９によって表されている。

「メインＣＰＵ／ＯＳベース」の状態３０４で動作し、このユーザーインターフェース９２５／１００４によって制御される機能としては、アプリケーション１０１１、１００８、１０１３が含まれる。ここでも非メインＣＰＵ／ＯＳ機能のことを知らず、したがってこれらの機能とのインターフェースになってくれるメインＣＰＵ／ＯＳプロキシドライバを必要とするものを表すレガシー機能というものがある。そのようなアプリケーションの一つの例が音楽ファイルを再生できるレガシーメディアプレーヤーである。この場合、メインＣＰＵ／ＯＳベースの状態３０４にある間、ユーザーインターフェース１００４にこのアプリケーションを制御するのを許すようなプロキシアプリケーション１００８を書くことができる。このアプリケーションが、メインＣＰＵ／ＯＳベースの状態３０４で利用可能なサブシステムで保存されている楽曲メディアの再生をユーザーが制御できるようにし、何らかのオーディオインターフェースを通じて出力する。将来、これらの種類のアプリケーションはこうしたプロキシ機能を内蔵するようになるだろう。そうしたものが機能アプリケーション１０１３によって表されている。

非メインＣＰＵ／ＯＳベースの状態３０５で動作する機能が図の右側にある。ユーザーインターフェース１００４は、ユーザーのボタン操作（キーボード／ボタン９２０）に反応して、次いでデータオブジェクトをディスプレイ９１９上に表示するのを受け持っている。データオブジェクト内部にはナビゲーションコマンドが埋め込まれており、それがどのボタンが押されたかに基づいて次にどのオブジェクトを表示するかをユーザーインターフェースに伝える。追加的に、マネージャが、ＭＰ３「非メインＣＰＵ／ＯＳベースのより低電力状態」機能アプリケーション１００６を通じて、ＭＰ３再生をユーザーが制御できるようにする。この１００６がＭＰ３ファイルを記憶１００３から取得し、そのファイルをデコードし、出力をブルートゥースインターフェースを通じて無線ヘッドホンに送るのを受け持っている。

データ記憶アプリケーション１００５の例としては、企業サーバーに接続し返し、新しいＰＩＭデータオブジェクトを引き出すアプリケーションがある。そうして引き出したデータオブジェクトは次いで記憶１００３に入れられ、ユーザーがユーザーインターフェース１００４を通じてアクセスできるようになる。この場合、アプリケーション１００５はこれらの新しいデータオブジェクトに、非メインＣＰＵ／ＯＳベースの状態３０５で動作する無線通信デバイス（ＷＬＡＮ９１１またはＷＷＡＮ９１３のような）を通じてアクセスすることになる。

図１１は、図５に関連して説明したフルセットのコードレス電話システムの動作の過程で生じうる、状態遷移のもう一つの実施形態を示している。ただし、図１１の例は図５の議論よりも若干手が込んでいて、ＬＥＤが明滅する（ユーザーに対し、応答しなかった電話からのメッセージが録音されていてユーザーを待っているということを示すために）とともに、ネットミーティングも確立される。図１１の手法では、期間Ｔ１の間、システムはもともとの「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５、１１０１にあり、ここでは基本的コードレス電話以外のコンピュータの活動・使用は発生しない。

時点Ｔ２において、このコードレス電話に呼び出しがなされ、誰も応答しなかったとする。その結果、「メインＣＰＵ／ＯＳベースの低電力」状態５０４、１１０２への遷移が引き起こされ、留守番電話機能が実現される。期間Ｔ３の間、留守番電話機能が電話に応答し、発信者にメッセージを再生して聞かせ、発信者のメッセージを録音し、非メインＣＰＵ／ＯＳコンピューティングシステム独自のユーザーインターフェース上でＬＥＤ（たとえば、図９ＡのＬＥＤ９２４）を反復的に明滅させる。このＬＥＤの明滅を引き起こす機能は、メインＣＰＵ／ＯＳ上にある留守番電話ソフトウェアと非メインＣＰＵ／ＯＳコンピューティングシステム独自であるＬＥＤソフトウェア／ハードウェアとの間の協働的な作業フローになっていることに注意しておく。

Ｔ４の時点で上記の機能が完了すると、全体としてのコンピューティングシステムは「非メインＣＰＵ／ＯＳベースのより低電力」状態５０５、１１０３に遷移によって戻る。Ｔ５の時点で、まだＬＥＤは明滅を続けており（ユーザーが録音されたメッセージを聞くまで明滅は止まらないのである）、再び電話が鳴る。しかし、今回はユーザーが電話に応答し、この通話が、確立する必要のあるネットミーティングに関するものであると認識する。ユーザーは非メインＣＰＵ／ＯＳコンピューティングシステムユーザーインターフェース上にある「ネットミーティング」ボタン（たとえば、図９Ａのキーボード／ボタン９２０に付随している）を押す。

「ネットミーティング」を押したことで、「メインＣＰＵ／ＯＳベースの低電力」状態５０５、１１０４への第一の遷移および「通常のオン」状態５０１、１１０５への第二の遷移が引き起こされる。「通常のオン」状態では、かかってきた電話の発信者ＩＤおよびメインＣＰＵ／ＯＳのリソースが、ネットミーティングを確立し、そのもとで作業を実行する（たとえば、インターネットを通じてつながっている別の個人と一緒に共通の文書を修正するなど）のに使われる。ＬＥＤは非メインＣＰＵ／ＯＳコンピューティングシステムの制御の下で明滅を続ける。ユーザーは録音されたメッセージをまだ聞いていないからである。

また、本発想の実施形態は一つ以上のソフトウェアプログラムによって実装しうるため、本発想の実施形態は機械可読媒体上もしくは機械可読媒体内で実施または実現しうることも理解しておく必要がある。機械可読媒体とは、機械（たとえばコンピュータ）によって読むことのできる形の、保存したり送信したりするためのいかなる機構をも含む。たとえば、機械可読媒体には読み出し専用メモリ（ＲＯＭ：ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ素子、電気的・光学的・音響学的またその他の伝搬信号（たとえば、搬送波、赤外線信号、デジタル信号など）などが含まれる。

上述の明細では、本発明は特定の代表例としての実施形態を参照しつつ説明されてきた。しかしながら、付属の請求項で述べられている、本発明のより広い思想と範囲から逸脱することなく、さまざまな修正や変更をなしうることは明らかであろう。よって、明細と図面は限定的な意味ではなく、解説のためのものと見なすべきものである。

コンピューティングシステムの一つの実施形態を示す図である。 コンピューティングシステムについての従来技術の状態図を示す。 使用可能な低電力状態を有するコンピューティングシステムについての改良された状態図を示す。 「通常のオン」状態について、アクティブおよび非アクティブなコンピューティングシステムのハードウェア構成要素の間の関係の実施例を示す図である。 「メインＣＰＵ／ＯＳベースの低電力」状態について、アクティブおよび非アクティブなコンピューティングシステムのハードウェア構成要素の間の関係の実施例を示す図である。 「非メインＣＰＵ／ＯＳベースのより低電力」状態について、アクティブおよび非アクティブなコンピューティングシステムのハードウェア構成要素の間の関係の実施例を示す図である。 それぞれ「通常のオン」状態、「メインＣＰＵ／ＯＳベースの低電力」状態、「非メインＣＰＵ／ＯＳベースのより低電力」状態にわたるフルセットの電話システムについてのさまざまな機能役割の配分の実施例を示す図である。 図６Ａは「通常のオン」状態から「メインＣＰＵ／ＯＳベースの低電力」状態への遷移の代表例としての方法を示す図である。また、図６Ｂは「メインＣＰＵ／ＯＳベースの低電力」状態から「通常のオン」状態への遷移の代表例としての方法を示す図である。 コンピューティングシステムの、（１）「通常のオン」状態と一つ以上のスリープ状態との間、（２）「メインＣＰＵ／ＯＳベースの低電力」状態と「非メインＣＰＵ／ＯＳベースのより低電力」状態との間の遷移を補佐または制御するのに用いうる状態遷移ロジックの実施例を示す図である。 「メインＣＰＵ／ＯＳベースの低電力」状態から「非メインＣＰＵ／ＯＳベースのより低電力」状態への遷移の代表例としての方法を示す図である。 「非メインＣＰＵ／ＯＳベースのより低電力」状態から「メインＣＰＵ／ＯＳベースの低電力」状態への遷移の代表例としての方法を示す図である。 低電力であるが動作可能な非メインＣＰＵ／ＯＳベースのサブシステムを有するコンピューティングシステムのより詳細な実施例を示す図である。 「ふたを閉じた状態での」ユーザーインターフェースを備えているモバイルコンピューティングシステムどうしの対の実施例を示す図である。 「メインＣＰＵ／ＯＳベースの低電力」状態のためのソフトウェアアーキテクチャーの実施例、「非メインＣＰＵ／ＯＳベースのより低電力」状態のためのソフトウェアアーキテクチャー、そしてこの状態の対の間に存在しうる関係を示す図である。 時間を追ってコンピューティングシステムの利用に反応するいくつかの状態遷移の例を示す図である。

符号の説明

１０１ ＣＰＵ
１０２ キャッシュ
１０３ メモリ・Ｉ／Ｏコントロール
１０４ システムメモリ
１０５ グラフィクスコントローラ
１０６ ディスプレイ
１０７ バス
２０１ 高電力の「通常のオン」状態
２０２ オフ状態
２０３ スリープ状態
３０１ 高電力の「通常のオン」状態
３０２ オフ状態
３０３ スリープ状態
３０４ 低電力の「メインＣＰＵ／ＯＳベース」の状態
３０５ 低電力の「非メインＣＰＵ／ＯＳベース」の状態
４０１ ＣＰＵ
４０２ キャッシュ
４０３ メモリ・Ｉ／Ｏコントロール
４０４ システムメモリ
４０５ グラフィクスコントローラ
４０６ ディスプレイ
４０７ バス
５０１ ネットミーティング機能
５０２ 留守番電話機能
５０３ 基本コードレス電話機能
・無線接続
・通常電話インターフェース
・ＬＥＤ
６０１ 実行中
６０２ 「メインＣＰＵ／ＯＳベースの低電力」状態への移行のトリガーとなるイベント
６０３ ＯＳ、ドライバがシステムを「メインＣＰＵ／ＯＳベースの低電力」状態にあるとマーク
６０４ 「メインＣＰＵ／ＯＳベースの低電力」システムを構築
（適当なハードウェアおよびソフトウェアの作動停止）
６０５ 実行中
６０６ 実行中
６０７ 高電力の「通常のオン」状態への以降のトリガーとなるイベント
６０８ ＯＳ、ドライバがシステムを高電力の「通常のオン」状態にあるとマーク
６０９ 高電力の「通常のオン」システムを構築
（適当なハードウェアおよびソフトウェアを作動させる）
６１０ 実行中
７０１ 目覚め／スリープロジック
７０７ スリープ
７０９ 電力制御
８０１ 実行中
８０２ 「非メインＣＰＵ／ＯＳベースのより低電力」状態への移行のトリガーとなるイベント
８０３ ＯＳおよびドライバが処理に備え、ソフトウェア状態コンテキストが保存される
８０４ ・「非メインＣＰＵ／ＯＳベースのより低電力」システムの構築（ハードウェアの無効化）
・「非メインＣＰＵ／ＯＳベースのより低電力」状態にはいるためＣＰＵ／ＯＳがスリープ状態とされたことを記録
８０５ メインＣＰＵ／ＯＳをスリープ状態に
８０６ 実行中
８０７ 目覚めイベント
８０８ ・ＢＩＯＳ読み込みおよび初期化
・通常システムに向けて電力投入（たとえば、ＳＬＰ＿ＥＮもしくはＮＭＣ／Ｏ＿ＥＮまたはその両方のビットに基づいて）
８０９ 目覚めが伝統的なスリープからか低電力状態からかを判定
８１０ 従来技術の目覚めの手続き
８１１ ・「メインＣＰＵ／ＯＳ低電力」状態でのコンテキストを回復
・目覚めイベントがトリガーされた原因を判定
９０１ ＣＰＵ
９０２ キャッシュ
９０３ メモリ・Ｉ／Ｏコントロール
９０４ システムメモリ
９０５ グラフィクスコントローラ
９０６ ディスプレイ
９０９ （モデム）
９１１ （ＷＬＡＮ）
９１３ （ＷＷＡＮ）
９１５ ハードディスクドライブ
９２２ 第二のメモリ／記憶装置
９２１ 非メインＣＰＵ／ＯＳのより低電力状態 フラッシュメモリ
９１７ 非メインＣＰＵ／ＯＳのより低電力状態 コントローラ
９１８ 非メインＣＰＵ／ＯＳのより低電力状態 主メモリ
９１９ 非メインＣＰＵ／ＯＳのより低電力状態 ディスプレイ
９２０ 非メインＣＰＵ／ＯＳのより低電力状態 キーボード／ボタン
９２４ ＬＥＤ
９２５ ユーザーインターフェース
１００１ 非メインＣＰＵ／ＯＳのより低電力状態 ＡＰＩ
１００２ 非メインＣＰＵ／ＯＳのより低電力状態 マネージャ
１００３ 非メインＣＰＵ／ＯＳのより低電力状態 記憶
１００４ 非メインＣＰＵ／ＯＳのより低電力状態 ユーザーインターフェース
１００５ 非メインＣＰＵ／ＯＳのより低電力状態 データアプリケーション
１００６ 非メインＣＰＵ／ＯＳのより低電力状態 機能アプリケーション
１００７ メインＣＰＵ／ＯＳプロキシ
１００８ メインＣＰＵ／ＯＳプロキシ
１００９ メインＣＰＵ／ＯＳデータアプリケーション
１０１０ メインＣＰＵ／ＯＳレガシーデータアプリケーション
１０１１ メインＣＰＵ／ＯＳレガシー機能アプリケーション
１０１２ メインＣＰＵ／ＯＳイベントマネージャ
１０１３ メインＣＰＵ／ＯＳ機能アプリケーション
１１０１ 非メインＣＰＵ／ＯＳベースの状態５０５
１１０２ メインＣＰＵ／ＯＳベースの低電力状態５０４
１１０３ 非メインＣＰＵ／ＯＳベースの低電力状態５０５
１１０４ メインＣＰＵ／ＯＳベースの低電力状態５０４
１１０５ 高電力の「通常のオン」状態５０１
Ｔ１ 活動なし／基本的コードレス電話としての使用のみ
Ｔ２ 電話が鳴る
誰も出ない
状態５０４への遷移を引き起こす
Ｔ３ 留守番電話機能
・電話に出る
・留守番応答メッセージの再生
・メッセージを録音
・ＬＥＤを明滅させる
Ｔ４ 応答のなかった電話への留守番電話機能完了が状態５０５への遷移を引き起こす
Ｔ５ ＬＥＤが明滅
電話が鳴る
ユーザーが電話に出て「ネットミーティング」ボタンを押す
Ｔ５とＴ６の間 「ネットミーティング」ボタンが押されたことで状態５０４への遷移が引き起こされる
Ｔ６ 「ネットミーティング」が要求されていると認識
非メインＣＰＵ／ＯＳサブシステムがＬＥＤ明滅を続ける
Ｔ７ 「ネットミーティング」が要求されているとの認識が状態５０１への遷移を引き起こした
Ｔ８ ・「ネットミーティング」ボタンが要求されているとの認識
・発信者ＩＤ取得
・ネットミーティング開始
・非メインＣＰＵ／ＯＳサブシステムがＬＥＤ明滅を続ける

Claims (20)

1. コンピューティングシステムであって、
   ａ）該コンピューティングシステムが非メインＣＰＵ／ＯＳベースの動作状態で動作しているときに非アクティブにされるＩ／Ｏユニットインターフェースと、
   ｂ）該コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるときに機能上のタスクを動作させるコントローラと、
   ｃ）前記Ｉ／Ｏユニットインターフェースおよび前記コントローラの両方に結合した無線Ｉ／Ｏユニットと、
   ｄ）前記コントローラに結合された不揮発性記憶ユニットとを有しており、前記コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるとき、前記非メインＣＰＵ／ＯＳベースの動作状態の間に前記無線Ｉ／Ｏユニットによって受信された情報を、前記コントローラが前記不揮発性記憶ユニットに書き込ませ、
   当該コンピューティングシステムは前記コントローラ上で実行されるＯＳ（オペレーティングシステム）をさらに有し、該ＯＳが次の構成要素、すなわち：
   ａ）アプリケーションプログラマーズインターフェース（ＡＰＩ）と、
   ｂ）当該コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるときに動作するユーザーインターフェースを制御するユーザーインターフェース管理機能と、
   ｃ）前記不揮発性記憶ユニットを管理するデータ記憶管理機能とを有し、
   当該コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるときに前記ＯＳ上で前記ＡＰＩを通じて走るアプリケーションソフトウェアをさらに有し、
   前記ＡＰＩが、メインＣＰＵ／ＯＳ側のソフトウェアが前記コントローラの制御下にあるリソースを使うことを許容する、ことを特徴とするコンピューティングシステム。
2. 前記アプリケーションソフトウェアがさらにデータ記憶アプリケーションソフトウェアプログラムを有することを特徴とする、請求項１記載のコンピューティングシステム。
3. 前記データ記憶アプリケーションソフトウェアプログラムが：
   ａ）前記無線Ｉ／Ｏユニットからデータオブジェクトを保存しているサーバーへの無線通信を開始し、
   ｂ）前記データオブジェクトが前記サーバーによって当該コンピューティングシステムに送られ、前記無線Ｉ／Ｏユニットによって受信されたのち、前記データオブジェクトを前記不揮発性記憶ユニット中に保存する、よう構成されていることを特徴とする、請求項２記載のコンピューティングシステム。
4. 前記無線通信がＷＷＡＮ通信であることを特徴とする、請求項３記載のコンピューティングシステム。
5. 前記無線通信がＷＬＡＮ通信であることを特徴とする、請求項３記載のコンピューティングシステム。
6. 前記データオブジェクトがさらに前記ユーザーインターフェースとともに用いるカレンダー情報を有することを特徴とする、請求項３記載のコンピューティングシステム。
7. 前記データオブジェクトがさらに前記ユーザーインターフェースとともに用いる連絡先情報を有することを特徴とする、請求項３記載のコンピューティングシステム。
8. 前記データオブジェクトがさらに前記ユーザーインターフェースとともに用いる行動予定情報を有することを特徴とする、請求項３記載のコンピューティングシステム。
9. 前記ユーザーインターフェース管理機能が、ボタンの押下に反応して、データオブジェクトをユーザーに対してディスプレイ上に提示できることを特徴とする、請求項１記載のコンピューティングシステム。
10. 前記データオブジェクトが、該データオブジェクトが前記ディスプレイ上のどこに表示されるべきかを記述する、埋め込まれたナビゲーションコマンドを含んでいることを特徴とする、請求項９記載のコンピューティングシステム。
11. 前記コンピューティングシステムがラップトップパソコンまたはノートパソコンであり、前記ディスプレイが前記ラップトップパソコンまたはノートパソコンのふたが閉じられているときでもユーザーに見えることを特徴とする、請求項１０記載のコンピューティングシステム。
12. 前記不揮発性記憶ユニットがフラッシュメモリであることを特徴とする、請求項１記載のコンピューティングシステム。
13. 前記不揮発性記憶ユニットがポリマーメモリであることを特徴とする、請求項１記載のコンピューティングシステム。
14. コンピューティングシステムが非メインＣＰＵ／ＯＳベースの動作状態で動作しているときに：
    非アクティブにされたインターフェースを有する無線Ｉ／Ｏユニットにより情報を無線式に受信する段階であって、前記非アクティブにされたインターフェースがメインＣＰＵ／ＯＳベースの動作状態の間に前記無線Ｉ／Ｏユニットから／へ送られる第二の情報を送信／受信する、段階と、
    コントローラの制御により前記情報を不揮発性記憶ユニットに保存する段階であって、前記コントローラ上ではＯＳ（オペレーティングシステム）が実行され、該ＯＳが次の構成要素、すなわち：ａ）アプリケーションプログラマーズインターフェース（ＡＰＩ）と、ｂ）当該コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるときに動作するユーザーインターフェースを制御するユーザーインターフェース管理機能と、ｃ）前記不揮発性記憶ユニットを管理するデータ記憶管理機能とを有し、前記コンピューティングシステムが前記非メインＣＰＵ／ＯＳベースの動作状態にあるときに前記ＯＳ上では前記ＡＰＩを通じてアプリケーションソフトウェアが走る、段階とを有する、
    方法であって、
    前記ＡＰＩが、メインＣＰＵ／ＯＳ側のソフトウェアが前記コントローラの制御下にあるリソースを使うことを許容する、方法。
15. 前記不揮発性記憶ユニットがフラッシュメモリを含むことを特徴とする、請求項１４記載の方法。
16. 前記不揮発性記憶ユニットがポリマーメモリを含むことを特徴とする、請求項１４記載の方法。
17. 前記非メインＣＰＵ／ＯＳベースの動作状態の間、コントローラ上で実行されるソフトウェアプログラムコードにより前記保存を引き起こすことを特徴とする、請求項１４記載の方法。
18. 前記ソフトウェアプログラムコードの実行が、ユーザーインターフェースを制御するためのユーザーインターフェース管理機能を実装させることを特徴とする、請求項１７記載の方法。
19. 前記ソフトウェアプログラムの実行がアプリケーションプログラマーズインターフェースを実装させることを特徴とする、請求項１７記載の方法。
20. 前記情報が：カレンダー情報；連絡先情報；行動予定情報のうちの少なくとも一つである、請求項１７記載の方法。

Images