JP5026579B2 - オペレーティングシステムに依存しないネットワークイベント処理 - Google Patents

Description

本開示は、一般にシステム管理に関し、より詳細には計算装置が低電力消費状態を維持しながら、計算装置のオペレーティングシステムから独立した計算装置のファームウェア環境によるウェイクイベントの処理に関する。

計算装置の電力消費を低減するための各種メカニズムが存在する。電力管理のための標準的な技術は、ＡＣＰＩ（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ）バージョン４．０に規定され、それはｗｗｗ．ａｃｐｉ．ｉｎｆｏのＵＲＬでパブリックインターネット上で見つけることができる。ＡＣＰＩは、電力管理のために大部分のコンピュータシステムが現在使用している規格であり、計算システムがオペレーティングシステム（ＯＳ）にどのように依存するかについて記載している。電力管理機能は、コンポーネントレベルとシステムレベルの双方において計算装置がそれの動作状態を高電力消費状態と低電力消費状態との間で遷移することを可能にする。これらの動作モードは、しばしばウェイク及びスリープ状態又はモードと呼ばれる。ＡＣＰＩ規格は、計算装置が典型的にとりうる７つの状態を規定する。例えば、状態Ｓ３（“Ｓ３”）は、典型的にはスタンバイ、スリープ（ここではまた“スリープモード”とも呼ばれる）又はＲＡＭへのサスペンドと呼ばれるかもしれない。状態Ｓ５（“Ｓ５”）は、シャットダウン又はオフと呼ばれるかもしれない。

いくつかのイベントは、計算装置にスリープモードとウェイクモードとの間を遷移させ、すなわち、ウェイクアップ又はゴートゥースリープさせる。例えば、計算装置がスリープに移行するのをトリガーするスリープイベントは、ユーザの非活動やユーザの選択を含むかもしれない。計算装置がスリープに移行するとき、計算装置コンポーネントの多くもまた（中央処理ユニット（ＣＰＵ）などのメインプロセッサ、揮発性メモリ、大容量ストレージのためのディスクドライブなど）スリープに移行する。スリープ状態になると、計算装置はウェイクイベントの発生によりウェイクする。ウェイクイベントは、例えば、マウスやキーボードからの入力の計算装置による受信、電子メールメッセージ又はリモートシステムアドミニストレータからのクエリなどを含む。

本発明の課題は、計算装置が低電力消費状態を維持しながら、計算装置のオペレーティングシステムから独立した計算装置のファームウェア環境によるウェイクイベントの処理を実現することである。

上記課題を解決するため、本発明の一特徴は、計算装置によるネットワークイベントに応答するための方法であって、前記計算装置を第１高電力消費状態から第２低電力消費状態に移行させるとき、プレブート時に利用可能な１以上のファームウェアファンクションを含むファームウェア環境を再インスタンス化するステップと、前記計算装置が前記第２低電力消費状態にある間、前記ファームウェア環境がネットワークイベントを受信するステップと、前記第２低電力消費状態に留まっている間、前記計算装置のオペレーティングシステムから独立して前記ファームウェア環境が、前記計算装置全体を前記第１高電力消費状態に戻すことなく前記ネットワークイベントが処理可能であるか判断するステップと、前記ファームウェア環境が前記ネットワークイベントが処理可能であると判断した場合、前記ファームウェア環境は、前記ＯＳから独立して前記計算装置全体を前記第１高電力消費状態に戻すことなく前記ネットワークイベントを処理するステップとを有する方法に関する。

本発明によると、計算装置が低電力消費状態を維持しながら、計算装置のオペレーティングシステムから独立した計算装置のファームウェア環境によるウェイクイベントの処理を実現することができる。

図１は、各種実施例によるウェイクモードからスリープモードへの計算装置の移行を示すタイムラインである。 図２は、各種実施例によるオペレーティングシステム（ＯＳ）から独立してウェイクイベントをファームウェアが処理するための一例となる方法を示すフロー図である。 図３は、各種実施例による計算装置におけるブート及びウェイクサイクルを示すブロック図である。 図４は、各種実施例による一例となる計算装置を示すブロック図である。

以下、図面に基づいて本発明の実施の形態を説明する。

本発明の例示的な実施例は、以下に限定するものでないが、計算装置が低電力消費スリープモードに留まるとき、計算装置のオペレーティングシステムから独立して計算装置のファームウェア環境又はファームウェアによるウェイクイベントを処理するための方法及び装置を含む。

例示的な実施例の各種態様が、他の当業者に成果の本質を伝えるために当業者により通常用いられる用語を用いて説明される。しかしながら、他の実施例は説明される態様の一部のみにより実現可能であることは、当業者に明らかであろう。説明のため、具体的な数字、物及び構成が例示的な実施例の完全な理解を提供するため与えられる。しかしながら、他の実施例はこのような具体的な詳細になしに実現可能であることは当業者に明らかであろう。他方、周知の特徴は、例示的な実施例を不明りょうにしないように省略又は簡略化される。

さらに、各種処理が、例示的な実施例を理解するのに最も役立つように複数の個別の処理として説明される。しかしながら、説明の順序は、これらの処理が必ずしも順序に依存することを意味すると解釈されるべきでない。特に、これらの処理は、提供される順序により実行される必要はない。“一実施例では”という用語が繰り返し使用される。この用語は、一般に同一の実施例を参照するものでない。しかしながら、そうである場合もある。“構成する”、“有する”及び“含む”という用語は、特段の指摘がない限り同義語である。

図１は、各種実施例によるウェイクモードからスリープモードへの計算装置の移行を示すタイムラインである。後述されるように、各種実施例では、計算装置のファームウェアは、計算装置がスリープモード中に作業を実現することが可能とされてもよい。ファームウェアは、この作業をオペレーディングシステムから独立して実現可能であり、これにより、計算装置の機能性を向上させると共に、電力消費全体を低減させることが可能となる。実施例では、計算装置又はシステムは、デスクトップコンピュータ、ラップトップコンピュータ、モバイル計算装置、ネットワークサーバ、シンクライアント、又はファームウェアを利用するよう構成された他の計算装置であってもよい。実施例では、ファームウェアは、レガシーＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）、ＵＥＦＩ（Ｕｎｉｆｉｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ）互換性（ＵＥＦＩ仕様書バージョン２．０（２００６年）など）、ＥＦＩ（Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ）互換性（ＥＦＩ仕様書バージョン１．１０（２００４年）など）又は他のファームウェアであってもよい。ＥＦＩは、計算装置のファームウェアとオペレーティングシステム又は他のアプリケーション環境との間の抽象的なプログラムインタフェースを記述する公開された工業規格であることに留意されたい。例えば、ＥＦＩは、ファームウェアモジュールの形式によるファームウェアが、フラッシュメモリデバイス、オプションのＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、各種永続的記憶デバイス（ハードディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）など）を含む各種リソースから、又はコンピュータネットワークを介した１以上のコンピュータシステムからロード可能である。ＵＥＦＩアーキテクチャに関するさらなる情報は、ｗｗｗ．ｕｅｆｉ．ｏｒｇにおいてパブリックインターネット上で利用可能である。後述されるように、各種実施例では、スリープモードに移行すると、計算装置はブート前に利用可能な１以上のファームウェアファンクションを含むＵＥＦＩ又は他のファームウェア環境を再インスタンス化する。実施例では、再インスタンス化されたファームウェア環境は、ファームウェア環境が計算装置のＯＳにより通常実行される電力管理機能を実行することを可能にする。

図１を参照するに、図示された実施例では、計算装置は、ファームウェア環境又はファームウェア１１１によりプレブート期間に初期化される。各種実施例では、以下で詳細に説明されるように、このプレブート期間において、ファームウェアは、ファームウェアが１１２において以降にデータを収集するメモリ又はメールボックスの一部を確保する。プレブートの初期化が終了すると、１１３において、ブート処理を継続するため、計算装置のオペレーティングシステム（ＯＳ）に制御が移行する。ＯＳ又はシステムブート後、１１５において、ＯＳは、機能モード又はウェイクモードにより計算装置を実行又は動作させ、これは、典型的には、通常処理に関する高電力消費状態を含む。計算装置は、スリープイベントが計算装置を低電力消費状態を含むスリープモードＳ３に移行させる１１７まで、ウェイクモードにより動作し続ける。上述されるように、スリープイベントは、ユーザ選択又はユーザ非活動などの各種イベントを含むものであってもよい。

しばらくした後、各種実施例では、計算装置はウェイクイベントを受信する。一部の実施例では、ウェイクイベントは電子メール、コンフィギュレーション指示又は他のネットワーク送信などのネットワークイベントを含むものであってもよい。他の実施例では、ウェイクイベントは、入力装置における入力の検知、計算装置のキーボードのタッチ、特定タイプのネットワークパケットの受信などであってもよい。ウェイクイベントの処理は、ＳＭＩ（Ｓｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｒｕｐｔ）、制御ライン変更、レジスタフラグ、又は他の構成により開始されてもよい。他のケースでは、ウェイクイベントの処理は、計算装置のチップセットにより開始されてもよい。さらに、いくつかのウェイクイベントは、ＯＳによる処理のため計算装置のパワーアップをトリガーするものであってもよい。他のウェイクイベントは、本開示の実施例に関して後述されるように、計算装置がスリープモードに留まりながらファームウェアにより処理される。

各種実施例では、計算装置のＯＳに依存せずに動作するファームウェアは、ウェイクイベントが計算装置全体を第１高電力消費状態に戻すことなく処理可能であるか判断する。ウェイクイベントがファームウェアにより処理可能でなく、ＯＳがウェイクイベントを処理する場合、１２１において、ディスクが回転され、モニタがオンされ、計算装置はフルウェイクモードに戻される。その後、処理フローは１１５に戻り、ＯＳは計算装置をウェイクモードで実行又は動作させる。しかしながら、ファームウェアがウェイクイベントがＯＳに関係なく、計算装置全体を第１高電力消費状態に戻すことなく処理可能であると判断した場合、ファームウェアはウェイクイベントを処理可能である。計算装置は、１１９においてスリープし続けてもよい。一部の実施例では、ウェイクイベントに依存して、計算装置全体をウェイクさせることなく、ファームウェアはウェイクイベントに関するタスクをサービス提供するか、又は完了するため１以上のハードウェアコンポーネント又はデバイスをウェイクする。さらに、イベントの処理の完了後、ファームウェアはハードウェアコンポーネントを第２低電力消費状態を含むスリープモードに戻してもよい。

ここで実施例では、１２３において、フィルタドライバなどのファームウェアコンポーネントは、ＯＳが１以上のハードウェアコンポーネントをスリープモードに移行する方法に関するデータをモニタ及び収集し始める。各種実施例では、フィルタドライバは、１１２におけるプレブート期間におけるファームウェアにより確保されたメモリの一部又はメールボックスに収集されたデータを保存してもよい。ファームウェアは、以降において独立して収集されたデータを利用して、ウェイクイベントを提供するのに必要な１以上のハードウェアコンポーネントをスリープ状態に及び／又はスリープ状態から遷移する。

次に、図２は、本開示の各種実施例によるＯＳから独立してウェイクイベントを処理する一例となる方法を示すフロー図である。実線のブロックは、実施例ではファームウェアにより実行され、破線のブロックはＯＳにより実行される。“ファームウェアにより実行”という用語は、より複雑な計算装置のやりとりのための略記であることは当業者に明らかであろう。シングルプロセッサシステムでは、例えば、命令の実行はメインプロセッサ又はＣＰＵにより実行される。“ファームウェアにより実行”は、非オペレーティングシステムの命令がプロセッサに接続される不揮発性メモリストア（ファームウェア）からフェッチされ、その後にプロセッサにより実行されることを意味するものであってもよい。プロセッサは、ＯＳをロードする前にファームウェアにアクセスする。このため、ブート命令は、典型的にはファームウェアブートブロックに格納される。さらに、一部の実施例では、フルブートブロックがリモートに配置され、ローカルブートブロックは、フルブートブロックのリモート位置へのポインタを含むようにしてもよい。

図２の実施例では、ブロック２０１において、計算装置又はシステムが電源オンされる。ブロック２０３において、プラットフォームが、ブートブロックファームウェアによって事前に初期化される。ブートブロックの外部にあるファームウェアの他の部分は、事前の初期化において役割を担うようにしてもよい。ブートブロックは、典型的には早期のメモリ初期化や中央プロセッサの初期化などの早期の初期化機能について使用されることに留意されたい。事前の初期化はまた、メモリの特定及びリセット、計算装置に接続されるデバイス及びコンポーネントの特定などを含むものであってもよい。

図示される実施例では、事前又はすぐ後の初期化の一部として、ファームウェアは、計算装置の状態を決定するため、いくつかのポリシーの質問を開始する。実施例では、ブロック２０６において、ファームウェアは、計算装置がウェイクイベント（本実施例では、ネットワークウェイクイベントなど）のためにウェイクアップしているか、又はスリープモードから移行しているか照会する。各種実施例では、計算装置がネットワークウェイクイベントによりウェイクアップしておらず、単に電力アップを完了させた場合、プレブート処理はブロック２０８に続く。ブロック２０８において、ファームウェアは、以降に必要とされる画像をキャッシュする。例えば、それは、スリープモード（Ｓ３など）のために必要なデータをキャッシュしてもよい。次に、ブロック２１０において、ファームウェアは、計算装置の有形なコンピュータ可読記憶媒体のメモリの一部をこのプレブート期間中に確保する。実施例では、メモリの一部は、ファームウェアのメールボックスとして使用されてもよい。典型的には、計算装置のリソースは、ファームウェアが自らのためにこのようなリソースを積極的に確保しない場合、ＯＳの制御下にあることに留意されたい。さらに、各種実施例では、後述されるように、ＯＳが１以上のハードウェアコンポーネントをスリープ状態に移行させる方法に関する入出力（Ｉ／Ｏ）データが、ファームウェアにより以降にアクセスされるメールボックスに保存されてもよい（ＯＳのモニタリングコンポーネントなどによって）。実施例では、ファームウェアが以前にキャッシュされた画像を再初期化することを可能にする十分なメモリが確保されてもよい。

図示される実施例では、次のブロック２１２において、ファームウェアは通常のブート処理を続け、ＯＳに制御が与えられ、開始される。ブロック２１４において、ＯＳは、フィルタドライバなどのコンポーネントをインストールする。後述されるように、フィルタドライバは、ハードウェアコンポーネントのスリープモードへの移行に関するＩ／Ｏデータを収集するためのモニタリングコンポーネントとして機能する。通常のＯＳ処理が、ブロック２１６において継続される。判定ブロック２１８において、ある期間入力を受信しない場合、又は他の計算装置のポリシーが指示する場合、ＯＳは計算装置をスリープモードに移行させる。例えば、計算装置がスリープモードに移行することをポリシーが指示しない場合、ブロック２１６において、ＯＳ処理が継続される。他方、判定ブロック２１８に戻って、計算装置がスリープモードに入ろうとする場合、ＯＳは判定ブロック２１８からブロック２２０に移行する。実施例では、このときＯＳは、ハードウェアコンポーネントがスリープモードに移行すべきであることをすべての又は実質的にすべてのハードウェアコンポーネント又はハードウェアデバイスドライバに通知するメッセージを送信する。ブロック２２２において、フィルタドライバは、この通知を受信又は検出し、１以上のハードウェアデバイス又はコンポーネントがスリープモードに移行される方法に関する入出力（Ｉ／Ｏ）データ、例えば、ハードウェアデバイスインタフェースとハードウェアデバイスドライバとの間のＩ／Ｏ信号などのモニタリングを開始する。ブロック２２４において、フィルタドライバは、その後にＩ／Ｏデータを収集し、それを事前ブート時にファームウェア環境により確保されたメールボックス（ブロック２１０において説明された）に保存する。最後に、ブロック２２６において、ＯＳは計算装置をスリープモードに移行する処理を完了する。

上述されたように、ブロック２２４においてメールボックスに保存されるＩ／Ｏデータは、ファームウェアがウェイクイベントの処理中及び／又は処理後にＩ／Ｏデータを利用することを可能にするため、以降において利用されてもよいことに留意されたい。例えば、判定ブロック２０６に戻って、計算装置がネットワークウェイクイベントなどのウェイクイベントによりウェイクアップしている場合、ＹＥＳの矢印に続く。ブロック２２８において、ファームウェアは、ＯＳがスリープモードに留まっている間、ネットワークイベントがＯＳから独立して計算装置全体をウェイクアップすることなく、又は高電力消費状態に戻すことなくファームウェアにより処理可能であるか決定する。判定結果がＮＯである場合、計算装置は、ブロック２３０において通常のＳ３コードパスを介して復帰し、最後に２１２において通常のブート処理を継続する。判定結果がＹＥＳである場合、ファームウェアは、ネットワークイベントをＯＳから独立して処理する。一部の実施例では、ブロック２３２において、ファームウェアは、１以上のハードウェアコンポーネントのみ（すべてでなく）をウェイクするか、又は高電力消費状態に移行させ、及び／又はネットワークイベントの処理に用いられるソフトウェアを起動させる。ブロック２３４において、ファームウェアは、フィルタドライバによりメールボックスに保存されているＩ／Ｏデータ及び／又は他の情報を抽出する。最後に、ブロック２３６において、ネットワークイベントの処理が完了すると、ファームウェアは、抽出されたＩ／Ｏデータを用いてハードウェアデバイスをスリープに戻す／移行する。

各種実施例では、計算装置のファームウェア環境は、計算装置がスリープモードに移行すると再インスタンス化される。実施例では、ファームウェア環境は、計算装置のＯＳにより通常実行される電力管理機能を実行することが可能とされる。一部の実施例では、計算装置は、特定のハードウェアコンポーネントをスリープ状態に移行させる機能、例えば、スリープモード中に計算装置により受信されるネットワーク送信に関するものなどを有するだけでなく、ファームウェア環境は、計算装置の複数のさらなるハードウェア又は他のコンポーネントをウェイクするための移行を開始することが可能である。各種実施例では、ファームウェア環境は、複数のハードウェアデバイスがスリープモードに移行される方法に関するＩ／Ｏデータを抽出することが可能とされる。このようなＩ／Ｏデータは、事前ブート期間中にファームウェアにより確保されたメールボックスから抽出されてもよい。各種実施例では、ファームウェア環境は、ハードウェアコンポーネントをスリープモードに移行することが可能とされ、電力管理機能は、典型的にはＯＳによってのみ実行される。

図３を参照するに、実施例は、例えば、ｗｗｗ．ｉｎｔｅｌ．ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｆｒａｍｅｗｏｒｋにおいて利用可能であるｔｈｅ Ｐｌａｔｆｏｒｍ Ｉｎｎｏｖａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｆｏｒ ｔｈｅ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ（ＥＦＩ） Ｄｒａｆｔ ｆｏｒ Ｒｅｖｉｅｗ，Ｖｅｒｓｉｏｎ ０．９，Ｓｅｐｔｅｍｂｅｒ １６，２００３などのモジュールＳ３レジュームアーキテクチャを結合してもよい。典型的には、例えば、２００９年５月８日に公表されたＵＥＦＩ Ｐｌａｔｆｏｒｍ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ （ＰＩ） Ｓｐｅｃｉｆｉｃａｔｉｏｎ，ｖｅｒｓｉｏｎ ２．３によると、ＰＩ ｐｒｅ−ＥＦＩ（ＰＥＩ）モジュールとＰＩ Ｄｒｉｖｅｒ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ（ＤＸＥ）ドライバのコンポーネント全体が、Ｓ５モード（“オフ”）からブート中に呼び出される。この結果、ＵＥＦＩシェル、サードパーティのＵＥＦＩドライバ／オプションＲＯＭ、ＵＥＦＩ ＯＳローダなどのプレＯＳアプリケーションにより使用されるＵＥＦＩ環境が生成される。しかしながら、Ｓ３期間中、Ｓ３の復帰時間の制約のため、計算装置は、典型的にはＤＸＥなしにＰＥＩの一部のみを含む標準的なＰＩ再開フローを実行する。また、Ｓ３再開モード中、豊富なＵＥＦＩドライバ機能は利用可能でないかもしれない。しかしながら、本開示の各種実施例は、計算装置がＳ３期間中にＤＸＥ３３０を実現してもよいことを提供する。図３の太字部分により示されるように、Ｓ３は、ＯＳのスリープモード中にＵＥＦＩブートサービスアプリケーションを実行するためのプレＯＳによりリクエストされた（又はＯＳドライバによりピンされた）ページにおいてＵＥＦＩ環境を再生成するためのＤＸＥを有してもよい。

図３を参照するに、実施例に示されるように、ブロック図３００は、ＵＥＦＩアーキテクチャにより実現されるブートウェイクサイクルを示す。実施例では、電源オン又はリセット後の通常のブート３０１中に、セキュリティ（ＳＥＣ）フェーズ３０２（ＳＥＣ ３０２）が開始される。ＳＥＣ３０２は、計算装置上で実行される初期的なオペレーディングコードのセキュリティチェックをサポートする。次に、実施例では、ＳＥＣ ３０２は、ｐｒｅ−ＥＦＩ（ＰＥＩ）フェーズ３０４（ＰＥＩ ３０４）に移行する。ＰＥＩ ３０４は、例えば、プロセッサ、チップセット、マザーボードのための特定の初期的な（ＩＮＩＴ）コンフィグレーションルーチンをロード及び呼び出す方法などを提供する。ＰＥＩ ３０４は、メモリを検出し、ドライバ実行環境（ＤＸＥ）フェーズ３０６（ＤＸＥ ３０６）にハンドオフされるリソースマップを準備する。ＤＸＥ ３０６は、プロセッサ、チップセット及びプラットフォームコンポーネントを初期化するためのＤＸＥ ３０６の呼び出しと共に、コンソール及びブートデバイスのソフトウェア抽象化の提供を含む。３１０において示されるように、ＤＸＥ ３０６は、不揮発性ストア（ＮＶＳ）などの確保されたメモリのブートスクリプトテーブルの一部としてＩ／Ｏコントローラ設定を保存する。ブートスクリプトは、スリープモードに移行する前に計算装置を以前の状態に戻すためにＳ３を再スタートすると再生されるアクション群を含む。典型的なブートスクリプトは、Ｉ／ＯデバイスとＣＰＵ状態情報とを復元する。

３１９に示されるように、Ｓ３復帰ブートでは、ＳＥＣ ３２０が実現されてもよい。次に、３２５において、Ｓ３ ＰＥＩモジュールは、チップセット、ハードウェア及びビデオ設定の基本的な復元など、３１０のＮＶＳからＰＥＩフェーズコンフィギュレーションを復元する。実施例では、ＤＸＥ ３３０は、ＤＸＥ初期プログラムロード（ＩＰＬ）３３５、ＤＸＥコア３４０、ＤＸＥファームウェアボリューム（ＦＶ）３４５、ブートデバイス選択（ＢＤＳ）３５０、ネットワークプロキシアクション３５５及びＤＸＥターミネータ３６０を含む複数のコンポーネント又はフェーズにより実現されてもよい。上述されるように、実質的に完全に形成されたＵＥＦＩインタフェースのインスタンス化は、Ｓ３にＤＸＥ ３３０を含めた結果として実現される。典型的には、少数のＵＥＦＩドライバのみが、プレブートフェーズ中に追加されない。しかしながら、本開示の実施例では、ＯＳドライバは、ＵＥＦＩ環境に追加的なＵＥＦＩドライバを追加する。各種実施例では、ＵＥＦＩドライバは、他のソースから収集されてもよい。一部の実施例では、これらの追加的なドライバは、ＤＸＥ ３３０の期間中に利用可能なＵＥＦＩドライバの個数を増やすため、ＵＥＦＩシステムパーティション又は他の方法を介して提供されてもよい。

最後に、図４は、本開示の実施例の一例となる計算装置４００を示す。各種実施例では、計算装置４００は、バス４２０を介し接続される各種要素を有する。図示されるように、これらの要素は、プロセッサ４０１、メモリ４１０、チップセット４０３、ハードウェアデバイス４６０、フラッシュメモリなどの不揮発性ストレージ４３０及び通信インタフェース４１５を有する。チップセット４０３は、上述されたファームウェアに与えられてもよい。メモリ４１０は、ＯＳ４２２、上述されたメールボックス４３５及びデバイスドライバ４８０を有する。プロセッサ４０１は、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラなど、ソフトウェアを実行可能な何れかのタイプのプロセッサであってもよい。図４は１つのプロセッサ４０１しか示していないが、計算装置４００には１以上のプロセッサがあってもよく、これらのプロセッサの１以上は、複数のスレッド、複数のコアなどを含むものであってもよい。各種実施例では、コンポーネント４２２は、１以上のハードウェアデバイス４６０のハードウェアインタフェースとデバイスドライバ４８０との間で通信されるバス４２０上のＩ／Ｏ信号をモニタリングすることによって、第１高電力消費状態と第２低電力消費状態とに関する情報を決定又は収集する。スリープモード中、ファームウェアは、上述されるような１以上のネットワーク又はウェイクイベントを処理する。

通信インタフェース４１５は、ネットワークインタフェースカード（ＮＩＣ）などのネットワーキングインタフェースを有する。ＮＩＣは、シリアルオーバＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェースなどを介しリモートサーバ４８０を含むインターネット／ネットワーク４７５に通信接続される。通信インタフェースは、ＴＣＰ／ＩＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）又は他の通信プロトコルをサポートするものであってもよい。ＮＩＣは、ＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ）リダイレクション（図示せず）や他の手段など、ネットワークを介し通信するための他の手段を利用するものであってもよい。実施例では、ウェイクイベントの処理は、限定されることなく、特定のパケットタイプへの応答、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）リースの続行、ウィルスのためのメモリのスキャンなどの低電力バックグラウンド動作、リモートファイルバックアップ／リストアなどを含むものであってもよいことに留意されたい。図示される実施例では、チップセット４０３はまた、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）４０９のソフトウェアインタフェースを有してもよい。

ここに記載された技術は、何れか特定のハードウェア又はソフトウェア構成に限定されるものでない。それらは、何れかの計算、家電又は処理環境における適用性を見出されるかもしれない。この技術は、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現されてもよい。上記技術は、プロセッサ、プロセッサによりアクセス可能な記憶媒体（揮発性及び不揮発性メモリ及び／又は記憶要素）、少なくとも１つの入力装置及び１以上の出力装置を含む、モバイル又は据置式コンピュータ、携帯情報端末、セットトップボックス、携帯電話及びページャ、家電装置（ＤＶＤプレーヤー、パーソナルビデオレコーダ、パーソナルビデオプレーヤー、衛星受信機、ステレオ受信機、ケーブルテレビ受信機を含む）及び他の電子装置などのプログラム可能なマシーン上で実行されるプログラムにより実現されてもよい。当業者は、本開示がマルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、独立した家電装置などを含む各種システムコンフィギュレーションにより実現可能であることを理解するであろう。本発明はまた、タスク又はその一部が通信ネットワークを介しリンクされるリモート処理装置により実行される分散計算環境において実現可能である。

プログラム命令は、命令によりプログラムされる汎用又は特定用途処理システムにここに記載された処理を実行させるのに利用されてもよい。あるいは、これらの処理は、処理を実行するための配線化されたロジックを含む特定のハードウェアコンポーネントによって、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの何れかの組み合わせによって実行されてもよい。ここに記載される方法は、当該方法を実行するよう処理システム又は他の電子装置をプログラムするのに利用される命令を格納したマシーンアクセス可能な媒体を含むコンピュータプログラムとして提供されてもよい。ここで用いられる“マシーンアクセス可能な媒体”とは、マシーンによる実行のための命令シーケンスを格納又は符号化可能であって、マシーンにここに記載された方法の何れかを実行させる何れかの媒体を含む。“マシーンアクセス可能な媒体”という用語は、以下に限定されることなく、データ信号を符号化するソリッドステートメモリ、光及び磁気ディスク及び搬送波を含む。さらに、それは、アクションを実行し、又は結果を生じさせるものとしてソフトウェア（プログラム、プロシージャ、プロセス、アプリケーション、モジュール、ロジックなど）と通常呼ばれる。このような表現は、処理システムがプロセッサにアクションを実行させ、又は結果を生成させることによってソフトウェアの実行を述べるための単なる一例である。

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

４００ 計算装置
４０１ プロセッサ
４０２ メモリ
４０３ チップセット

Claims (19)

1. 計算装置によるネットワークイベントに応答するための方法であって、
   前記計算装置を第１高電力消費状態から第２低電力消費状態に移行させるとき、プレブート時に利用可能な１以上のファームウェアファンクションを含むファームウェア環境を再インスタンス化するステップと、
   前記計算装置が前記第２低電力消費状態にある間、前記ファームウェア環境がネットワークイベントを受信するステップと、
   前記第２低電力消費状態に留まっている間、前記計算装置のオペレーティングシステムから独立して前記ファームウェア環境が、前記計算装置全体を前記第１高電力消費状態に戻すことなく前記ネットワークイベントが処理可能であるか判断するステップと、
   前記ファームウェア環境が前記ネットワークイベントが処理可能であると判断した場合、前記ファームウェア環境は、前記ＯＳから独立して前記計算装置全体を前記第１高電力消費状態に戻すことなく前記ネットワークイベントを処理するステップと、
   を有する方法。
2. 前記ネットワークイベントは、電子メールの受信、コンフィギュレーションの指示又は他のネットワーク送信からなるウェイクイベントである、請求項１記載の方法。
3. 前記ネットワークイベントを処理するステップは、前記ネットワークイベントを処理するのに使用される１以上のハードウェアコンポーネントを前記第１高電力消費状態に戻し、前記ネットワークイベントの処理が完了すると、前記ハードウェアコンポーネントを前記第２低電力消費状態に戻すことを含む、請求項１記載の方法。
4. フィルタドライバが、前記ＯＳが前記１以上のハードウェアコンポーネントを前記第２低電力消費状態に戻す方法に関する入出力（Ｉ／Ｏ）データをモニタリングするステップをさらに有する、請求項３記載の方法。
5. 前記ファームウェア環境が前記ネットワークイベントの処理中に使用するために前記Ｉ／Ｏデータにアクセスすることを可能にするため、前記Ｉ／Ｏデータをメールボックスに保存するステップをさらに有する、請求項４記載の方法。
6. 前記ファームウェア環境が、前記プリブート期間中に前記メールボックスとして用いるメモリの一部を確保するステップをさらに有する、請求項５記載の方法。
7. 前記再インスタンス化されたファームウェア環境は、前記計算装置に付属のものに加えてさらなるファンクションを実行するよう構成される、請求項１記載の方法。
8. 前記さらなるファンクションは、前記再インスタンス化されたファームウェア環境が前記ＯＳにより通常実行される電力管理ファンクションを実行することを可能にする、請求項７記載の方法。
9. ハードウェアデバイスを含む計算装置における方法であって、
   前記ハードウェアデバイスのハードウェアインタフェースと前記ハードウェアデバイスのデバイスドライバとの間で通信されるバス上の入出力（Ｉ／Ｏ）信号をモニタリングすることによって、第１高電力消費状態から第２低電力消費状態への前記ハードウェアデバイスの移行に関する情報を決定するステップと、
   前記決定された情報を格納するステップと、
   前記計算装置のファームウェアが、前記計算装置全体をウェイクすることなくウェイクイベントを処理することを可能にするため、前記決定された情報を抽出するステップと、
   を有し、
   前記ファームウェアは、前記ハードウェアデバイスが前記ウェイクイベントのためにサービス提供することを可能にするため、前記第１高電力消費状態から前記第２低電力消費状態に前記ハードウェアデバイスを移行し、前記ウェイクイベントのためのサービス提供が完了すると、前記第２低電力消費状態に前記ハードウェアデバイスを移行するよう構成される方法。
10. 前記ファームウェアが、プレブート期間中に前記決定された情報を格納するためのメモリの一部を確保するステップをさらに有する、請求項９記載の方法。
11. 前記ウェイクイベントは、ネットワークイベント又は入力装置において受信した入力データの検知からなる、請求項９記載の方法。
12. 前記Ｉ／Ｏ信号のモニタリングは、前記計算装置のオペレーティングシステム（ＯＳ）が前記第１高電力消費状態から前記第２低電力消費状態に移行しているという通知を受信すると、フィルタドライバにより実行される、請求項９記載の方法。
13. 前記ウェイクイベントの処理は、プレブート時に利用可能な１以上のファームウェア命令を含む前記計算装置のＯＳから独立して、再インスタンス化されたファームウェア環境において前記ネットワークイベントを処理することを含む、請求項９記載の方法。
14. 前記再インスタンス化されたファームウェア環境は、プレブート期間中に利用可能な前記ファームウェアのドライバファンクションにさらなるドライバファンクションを含む、請求項１３記載の方法。
15. 前記さらなるファームウェアファンクションは、前記ＯＳにより通常実行される電力管理ファンクションを含む、請求項１４記載の方法。
16. 前記ファームウェアによるウェイクイベントの処理は、特定のネットワークパケットタイプへの応答、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）リースの維持、ウィルスに対するメモリのスキャン及びリモートファイルバックアップ／復元の少なくとも１つを有する、請求項９記載の方法。
17. プロセッサと、
    前記プロセッサにより実行されるよう構成されるファームウェア環境と、
    を有する装置であって、
    前記ファームウェア環境は、当該装置を第１電力レベルを消費する動作状態にブートするのに用いられる複数のファームウェアファンクションを有し、
    前記ファームウェア環境はさらに、当該装置が前記動作状態から前記第１電力レベルより低い第２電力レベルを消費するスリープ状態に移行するとき、当該装置をブートするのに用いられる前記ファームウェアファンクションの少なくとも一部を有するように再インスタンス化され、当該装置が前記スリープ状態にある間に前記ファームウェア環境が前記ファームウェア環境により受信されるウェイクイベントを処理することを可能にするよう構成される装置。
18. 前記再インスタンス化されたファームウェア環境は、前記スリープ状態へのハードウェアコンポーネントの移行に関するデータを抽出し、前記抽出されたデータを用いて前記ハードウェアコンポーネントを前記スリープ状態に移行するよう構成されるファームウェアドライバを有する、請求項１７記載の装置。
19. 前記ファームウェア環境は、特定のネットワークパケットタイプへの応答、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）リースの維持、ウィルスに対するメモリのスキャン及びリモートファイルバックアップ／復元の少なくとも１つを処理するよう構成される、請求項１７記載の装置。

Images