JP2005508041A - バスデバイスの選択的サスペンド - Google Patents

Abstract

バス（８４）を介して接続された１つまたは複数のハードウェアデバイス（８６、９０、９２、９４、および９６）に電力制御を施行する方法およびシステム。本発明は、第２のデバイスに接続された第１のデバイスをサスペンドすることをシグナリングし、待機する方法およびシステムを含む。本発明は、ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを有するデバイスのツリーをサスペンドする方法およびシステムも含む。ツリーのルートにあるコントローラ（８６）は、子デバイスの１つまたは複数からアイドル要求を受け取り、各子デバイスからアイドル要求を受け取った後にツリー中のすべてのデバイスをサスペンドする。本発明は、アイドル要求を通信するための入出力制御（ＩＯＣＴＬ）のデータ構造も含む。

Description

【技術分野】
【０００１】
本発明は、一般にはデバイスの電力制御の分野に関する。詳細には、本発明は、バスを介して接続された１つまたは複数のハードウェアデバイスに電力制御を施行して選択的にデバイスをサスペンドさせるシステムおよび方法に関する。
【背景技術】
【０００２】
パーソナルコンピュータには、各種のバスアーキテクチャを介して周辺ハードウェアデバイスが接続する。例えば、ユニバーサルシリアルバス（ＵＳＢ）は、ハブ、ヒューマンインターフェースデバイス（ＨＩＤ）、スピーカ、およびユーザ入力装置などのデバイスを接続する。従来技術によるシステムの一部では、ホストオペレーティングシステムは、そのデバイスがその時に使用されていなくともシステムの稼動中は接続されたデバイスをフルパワー状態に維持する。さらに、ハブまたはコントローラは、それらに接続された非ハブデバイスがない時でも不必要にフルパワーの状態を保つ。これらの制約は、デスクトップコンピュータの場合には電力の消費と熱の発生を意味し、また特にラップトップコンピュータの場合はバッテリ電力の節減が必要となることを意味する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
また、従来技術のシステムの一部では、バスのバスコントローラは、そのバスコントローラがサスペンド状態にない時には絶えずホストシステム上のメインメモリにアクセスする。その結果、ホストシステムは、メインメモリとプロセッサとのためのシステムプロセッサキャッシュまたはメインキャッシュをアイドル状態（例えばＣ３）にすることができない。さらに、一部の従来技術システムでは、バスのルートハブポートに何も差し込まれていない場合にのみバスのバスコントローラをアイドル状態にする。
【０００４】
下記で述べる本発明は、これらおよびその他の不都合点の１つまたは複数に対処する。
【課題を解決するための手段】
【０００５】
本発明は、一般には、バスを介して接続された１つまたは複数のハードウェアデバイスに対して電力制御を施行することに関する。詳細には、本発明は、第２のデバイスに接続された第１のデバイスをサスペンドすることをシグナリングし、待機することを含む。第１のデバイスは、当該第１のデバイスがサスペンドできる状態になると第２のデバイスにアイドル要求を送信する。第１のデバイスは次いで、第１のデバイスに関連付けられたコールバック関数への第２のデバイスからの呼び出しを受け取るのを待って第１のデバイスをサスペンド状態にする。
【０００６】
本発明の態様を実施する方法は、１つまたは複数のデバイスがツリー中の親デバイスおよび子デバイスとして階層的に編成されたデバイスのツリーをサスペンドする。ツリーのルートにあるコントローラは、子デバイスの１つまたは複数からアイドル要求を受け取り、各子デバイスからアイドル要求を受け取った後にツリー中のすべてのデバイスをサスペンドする。
【０００７】
本発明は、ラップトップコンピュータなどのコンピューティングシステムに関連付けられたバス、ホストコントローラ、およびバス上のデバイスが、当該コンピューティングシステムがｆｕｌｌ動作電力を維持している間でも低電力モードに入ることも可能にする。低電力モードは、特にシステムにＵＳＢデバイスが接続されていない時にラップトップコンピュータでバッテリ電力の節減を可能にし、電力節減のイニシアチブに関して他のコンピュータシステムに利益をもたらす。本発明は、クラスドライバまたは他のデバイスドライバが本発明を利用する限り、ルートハブポートに追加的なデバイスが接続されていてもホストコントローラをアイドル状態にする。さらに、本発明は、当該複合デバイスが唯一のデバイスであっても、あるいはデバイスツリー中のデバイスの１つであっても、複合デバイスがバスに接続されている時にバスをサスペンドすることができる。
【０００８】
別の実施形態で、本発明は、バス上のすべてのデバイスは自身がアイドル状態であり、サスペンドできる状態にあることを通告（ｒｅｇｉｓｔｅｒ）することができるので、バス全体を同時にサスペンドすることができる。本発明は、独立した電力制御を持たないピアデバイスをサスペンドする。本発明は、クラスドライバから様々なコントローラ間の相違をなくす。さらに、本発明では、元々の機器製造者は自社のコンピューティングシステムに内蔵デバイスを追加することができ、その一方で、ホストコントローラをアイドル状態にさせ、内蔵デバイスに関連付けられたプロセッサおよびキャッシュをサスペンド状態に入れることができる。
【０００９】
あるいは、本発明は、各種の他の方法および装置を備えてもよい。
【００１０】
この他の特徴は、部分的には明らかになり、部分的には以下で指摘する。
【発明を実施するための最良の形態】
【００１１】
すべての図面を通じて、対応する参照符号は対応する部分を指す。
【００１２】
次いで図面を参照すると、本発明は、ユニバーサルシリアルバス（ＵＳＢ）などのバスを介して接続された１つまたは複数のハードウェアデバイスに電力制御を施行する。
【００１３】
図１に、ＵＳＢを介して接続されたデバイスのハードウェアモデルをブロック図の形態で示す。図１の実施形態では、コンピュータ８２は、内部ＰＣＩバス８４を含む。これに限定しないが図２との関連で説明する周辺コンポーネントを含む周辺コンポーネントは、この内部ＰＣＩバス８４に接続する。周辺コンポーネントは、例えば、複合デバイス（複数インターフェースを備えるデバイスなど）、ＵＳＢルートハブ８８などのルートハブ、あるいはＵＳＢホストコントローラ８６などのコントローラである。図１で、コンピュータ８２中のＵＳＢホストコントローラ８６は、ＰＣＩバス８４に接続する。ＵＳＢホストコントローラ８６は、概略的に８９で示すＵＳＢを介して周辺装置を接続することができるＵＳＢルートハブ８８を含む。他の実施形態では、ＵＳＢルートハブ８８は、ＵＳＢコントローラ８６の外部にある。図１で、プリンタ９０およびジョイスティック９２がＵＳＢルートハブ８８に接続される。この実施形態では、プリンタ９０は、プリンタ９０に接続されたマウス９４およびスピーカ９６を有するのでハブを含む。
【００１４】
図１の例に示す周辺装置は、マウス９４とスピーカ９６がプリンタ９０の子ノードあるいは子デバイスである点でツリー構造のノードとして階層的に編成されている。プリンタ９０が複合デバイスである場合、印刷コンポーネントは、同じプリンタ９０デバイスの他のコンポーネントに対して兄弟になる。別の実施形態では、包括的な親デバイスを、それ自体少なからぬ機能を持つ複合デバイスの親として使用する。同様に、プリンタ９０とジョイスティック９２とは、コンピュータ８２の子ノードになる。この場合、コントローラ８６、ルートハブ８８、またはコンピュータ８２を、プリンタ９０およびジョイスティック９２の親ノードと呼ぶ。一般に、ハブ、コントローラ、または包括的な親は、１つまたは複数の子ノードの親ノードになることができる。簡潔にするために、参照符号９８で、プリンタ９０、ジョイスティック９２、マウス９４、スピーカ９６などの１つまたは複数などのデバイスをまとめて指す。
【００１５】
当業者は、図１のノードの構成は例示的なものに過ぎず、本発明は、第２のノードに接続されたツリー構造中の複数ノードのうち任意の１ノードに動作可能であることに気付かれよう。さらに、図１のバスはＵＳＢであるが、当業者には、本発明は、デバイス間またはデバイスとコントローラ間の通信を可能にする任意タイプのバスアーキテクチャまたはネットワークアーキテクチャと共に動作可能であることに気付かれよう。
【００１６】
一部の従来技術システムでは、複合デバイスの子は、それらが同じ物理デバイスのコンポーネントであり、そのため同じ共通の電源を互いと共有するので、独立して電力制御することができない。本発明は、接続された子デバイス（例えばマウス９４やスピーカ９６）に対する独立した電力制御を持たないデバイス９８の独立した電力制御を提供する。本発明の実施は、ＵＳＢデバイスドライバ（例えばクラスドライバ）などのドライバソフトウェアとＵＳＢコアスタックとの協同的な成果である。本明細書に記載する本発明はクラスドライバへの例示的な参照を含むが、当業者は、本発明は広く任意のタイプのデバイスドライバソフトウェア（すなわちクラスドライバに制限されない）に動作可能であることに気付かれよう。本発明によれば、ＵＳＢクラスドライバは、デバイス９８がアイドル状態であり、もはや使用されていないことをＵＳＢコアスタックに通知する。特定のデバイス９８がアイドル状態になると、ドライバは、各自の個々のデバイス９８を低電力モードにすることを求める。低電力モードは、適用することが可能であればエネルギーとバッテリ電力とを節減する。また、本発明は、デバイス９８を安全に低電力モードに入れられる可能性があることをＵＳＢコアスタックがクラスドライバに通知するための機構を含む。ドライバとコアスタックとの対話により、ＵＳＢクラスドライバは、自身のデバイス９８がアイドル状態である、すなわち使用中でないことを検出するとそのデバイス９８の電力を下げることができる。
【００１７】
本発明により動作すると、独立した入出力の制御および機能を備えるが独立した電力制御を持たない２つの独立したデバイスが、それぞれ独立してアイドル状態になり、サスペンド可能な状態になることができる。２つの独立したデバイスは、両デバイスが接続されている第３のデバイスにメッセージを送信し、同時にサスペンド状態になる。さらに、ホストコントローラ８６は、ルートハブ８８の１つまたは複数のポートに１つまたは複数のデバイスが接続されている時でもアイドル状態になることができる。同様に、本発明は、バスに接続された１つまたは複数のルートハブポートを別々にサスペンドする方法を含む。本発明は、バスに複合デバイスだけが接続されている時にバスをサスペンドすることも可能にする。同様に、本発明は、バスに接続されたデバイスがない時にコンピュータがバスコントローラをサスペンドすることを可能にするように動作する。
【００１８】
新しい入出力制御（ＩＯＣＴＬ）要求により、ＵＳＢクラスドライバは、そのＵＳＢクラスドライバに関連付けられたデバイスがサスペンド可能な状態であることをＵＳＢコアスタックに通知することができる。ＵＳＢクラスドライバは、それがロードされた対象であるＵＳＢデバイス９８がアイドル状態で、もはや使用されていないと判定すると、ＵＳＢコアスタックにＩＯＣＴＬ要求を送信する。一実施形態では、ＩＯＣＴＬは、入出力要求パケット（ＩＲＰ）機構を介してＵＳＢコアスタックに送信される。ＩＯＣＴＬ要求でＵＳＢコアスタックに渡されるパラメータの１つは、その要求を提出するＵＳＢクラスドライバ中のコールバック機能へのポインタである。このコールバック関数は、それを行うために呼び出されるとＵＳＢデバイス９８を低電力モードに入れる要求を提出するＵＳＢクラスドライバ中の実際の関数である。
【００１９】
本発明の一実施形態では、デバイス９８はＵＳＢで接続される。ＵＳＢ複合デバイス（プリンタ９０、スピーカ９６など）とは、２つ以上のＵＳＢクラスドライバ（または同じＵＢＳクラスドライバの２つ以上のインスタンス）がそれについてロードされる２つ以上のインターフェースを含むタイプのＵＳＢデバイス９８である。例えば、スピーカ９６などの多くのＵＳＢスピーカデバイスは、実際にＵＳＢ複合デバイスであり、１つのインターフェースが実際のＵＳＢオーディオコンポーネントであり、もう１つのインターフェースが、通例はスピーカ９６から発せられる音声の音量を上げ下げするために使用されるヒューマンインターフェースデバイス（ＨＩＤ）コントロールのセットになっている。通例、ＵＳＢデバイス９８のドライバは、それが単純なＵＳＢデバイスについてロードされるのか、またはＵＳＢ複合デバイスのインターフェースについてロードされるのかを認識しない。一般に、ＵＳＢ複合デバイスは、複数のインターフェースを公開する。ＵＳＢデバイス９８の場合、ＨＩＤまたは他のＵＳＢデバイスを制御するソフトウェアをＵＳＢクラスドライバとも称する。同様に、ＵＳＢの場合、コントローラを制御するソフトウェアをＵＳＢコアスタックとも称する。ＵＳＢコアスタックには、包括的な親ドライバ、ハブドライバ、およびコントローラドライバが含まれる。例えば、ＵＳＢコアスタックは、ＵＳＢ複合デバイスのクラスドライバであるＵＳＢＣＣＧＰ．ＳＹＳと、ＵＳＢハブデバイスのクラスドライバおよびＵＳＢ全般のバスドライバであるＵＳＢＨＵＢ．ＳＹＳを含むことができる。ＵＳＢＨＵＢ．ＳＹＳは、システムに接続された単純なデバイスと複合デバイスとの両方の全ＵＳＢデバイスについての物理デバイスオブジェクト（ＰＤＯ）を生成する。複合デバイスの場合は、ＵＳＢＣＣＧＰ．ＳＹＳが、ＵＳＢＨＵＢ．ＳＹＳによって作成されたＰＤＯに対するクラスドライバとしてロードされる。
【００２０】
従来のＵＳＢ実装には様々な制約がある。具体的には、ＵＳＢ複合デバイスの場合、単一のインターフェースが低電力モードに入るには、必ず同じＵＳＢ複合デバイスのすべての他のインターフェースも低電力モードに入れることが必要となる。さらに、インターフェースは、そのインターフェースに関連付けられたＵＳＢクラスドライバの知識または許可がなければ低電力モードに入れることができない。
【００２１】
また、一部のタイプのＵＳＢクラスドライバ、特にＵＳＢ入力（またはＨＩＤ）デバイスのクラスドライバは、いつＵＳＢデバイスをフルパワーモードに戻すかを知るためにユーザ入力またはデバイスアクティビティの通知を必要とする。特定の既存のＵＳＢホストコントローラについては、コントローラにハードウェアバグがあり、そのため、１つのみのＵＳＢポートが低電力モードにあり、コントローラハードウェア全体自体は低電力モードにない場合には通知機能が機能しない。例えば、ＵＳＢマウス（例えばマウス９４）がバグのある可能性のあるＵＳＢホストコントローラ（例えばＵＳＢホストコントローラ８６）の１つのあるポートに接続され、同じコントローラの第２のポートに別のＵＳＢデバイスが接続されている場合に、ＵＳＢマウスのクラスドライバがその別のデバイスを低電力モードに入れた場合、ＵＳＢクラスドライバは、その後のデバイスアクティビティ（すなわちエンドユーザがマウスを動かす、あるいはマウスボタンをクリックするなど）を認識しない。そのため、ＵＳＢマウスのＵＳＢクラスドライバは、そのデバイスをフルパワーモードに設定しないことになる。エンドユーザに対するこのハードウェアバグの影響は、ＵＳＢマウスが動作しなくなるという形で現れる。このバグのあるＵＳＢホストコントローラによるＵＳＢを扱う際の別の制約は、ＵＳＢデバイスのためにロードされたＵＳＢクラスドライバに、そのドライバがロードされた対象のＵＳＢデバイスをＵＳＢクラスドライバからの一方的な要求に基づいて低電力モードに入れさせることができないことである。
【００２２】
本発明によるドライバソフトウェアの動作を図４および図５に示し、同図との関連で説明する。図４では、ドライバソフトウェアは、階層的に編成されたデバイスのツリー中で子デバイスとして機能するＵＳＢデバイス（例えばＨＩＤ）をサポートする。図５では、ドライバソフトウェアは、階層的に編成されたデバイスのツリー中のＵＳＢ複合親デバイスまたはＵＳＢハブデバイスをサポートする。本発明のドライバソフトウェアは、図４および５に示すソフトウェアの両方の態様を含む。
【００２３】
次いで図２を参照すると、本発明を実施することが可能な適切なコンピューティングシステム環境１００の一例をブロック図で示す。コンピューティングシステム環境１００は適切なコンピューティングまたは動作環境の一例に過ぎず、本発明の使用または機能性の範囲について何らの制限を示唆するものではない。またコンピューティングシステム環境１００は、例示的コンピューティングシステム環境１００に示す構成要素の任意の１つまたは組み合わせに関連する依存性または必要性を有するものとも解釈すべきでない。
【００２４】
図２は、コンピュータ１３０の形態の汎用コンピューティングデバイスの一例を示す。本発明の一実施形態では、コンピュータ１３０などのコンピュータが、本明細書で説明する他の図で使用するのに適している。例えば、コンピュータ１３０などのコンピュータは、コンピュータ８２として使用するのに適している。
【００２５】
コンピュータ１３０は、１つまたは複数のプロセッサあるいは処理装置１３２とシステムメモリ１３４とを含む。図の実施形態で、システムバス１３６は、システムメモリ１３４を含む各種のシステム構成要素をプロセッサ１３２に結合する。システムバス１３６は、各種のバスアーキテクチャの任意のものを使用したメモリバスまたはメモリコントローラ、ペリフェラルバス、アクセラレーテッドグラフィックポート、およびプロセッサバスあるいはローカルバスを含む数タイプのバス構造のいずれか１つまたは複数を表す。これらに限定しないが、例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称されるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。
【００２６】
コンピュータ１３０は、通例少なくとも何らかの形態のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性および不揮発性の媒体、取り外し可能および取り外し不能の媒体を含み、コンピュータ１３０からアクセスできる任意の利用可能な媒体であってよい。これに限定しないが、コンピュータ可読媒体の例には、コンピュータ記憶媒体と通信媒体とが含まれる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術に実装された揮発性および不揮発性の媒体、取り外し可能および取り外し不能の媒体を含む。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは、所望の情報の記憶に用いることができ、コンピュータ１３０によるアクセスが可能な任意の他の媒体が含まれる。通信媒体は、通例、搬送波または他の搬送機構などの変調データ信号に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施し、任意の情報伝達媒体を含む。当業者は、信号中に情報を符号化する方式でその特性の１つまたは複数を設定または変化させた変調データ信号には精通している。配線ネットワークまたは直接配線接続などの配線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体は、通信媒体の例である。上記の媒体のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれる。
【００２７】
システムメモリ１３４は、取り外し可能および／または取り外し不能メモリ、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。図の実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８とランダムアクセスメモリ（ＲＡＭ）１４０とを含む。起動時などにコンピュータ１３０内の要素間の情報転送を助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１４２は、通例ＲＯＭ１３８に記憶される。ＲＡＭ１４０は通例、処理装置１３２から即座にアクセス可能な、かつ／または現在処理装置１３２によって操作中のデータおよび／またはプログラムモジュールを含む。これに限定しないが、例として図２にはオペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、およびプログラムデータ１５０を示す。
【００２８】
コンピュータ１３０は、この他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。例えば、図２には、取り外し不能、不揮発性の磁気媒体の読み書きを行うハードディスクドライブ１５４を示している。図２には、取り外し可能、不揮発性の磁気ディスク１５８の読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭや他の光学媒体などの取り外し可能、不揮発性の光ディスク１６２の読み書きを行う光ディスクドライブ１６０も示す。例示的動作環境で使用できるこの他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体には、これらに限定しないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１５４、磁気ディスクドライブ１５６、および光ディスクドライブ１６０は、通例、インターフェース１６６などの不揮発性メモリインターフェースによってシステムバス１３６に接続される。
【００２９】
上記で説明し、図２に示すドライブまたは他の大容量記憶装置とそれに関連付けられたコンピュータ記憶媒体は、コンピュータ１３０のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を提供する。図２では、例えば、ハードディスクドライブ１５４にオペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、およびプログラムデータ１７６を格納している。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、およびプログラムデータ１５０と同じものでも、異なるものでもよいことに留意されたい。ここではオペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、およびプログラムデータ１７６には、それらが少なくとも異なるコピーであることを表すために異なる参照符号をつけている。
【００３０】
ユーザは、キーボード１８０、およびポインティングデバイス１８２（マウス、トラックボール、ペン、タッチパッドなど）などの入力装置を通じてコンピュータ１３０にコマンドと情報とを入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらおよび他の入力装置は、システムバス１３６に結合されたユーザ入力インターフェース１８４を通じて処理装置１３２に接続することが多いが、パラレルポート、ゲームポート、あるいはユニバーサルシリアルバス（ＵＳＢ）など他のインターフェースおよびバス構造によって接続することも可能である。モニタ１８８または他タイプの表示装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１３６に接続される。コンピュータは、モニタ１８８に加えて、プリンタやスピーカなど他の周辺出力装置（図示せず）もしばしば含み、それらは出力周辺インターフェース（図示せず）を通じて接続することができる。
【００３１】
コンピュータ１３０は、リモートコンピュータ１９４など１つまたは複数のリモートコンピュータとの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいはその他の一般的なネットワークノードでよく、通例はコンピュータ１３０との関連で上記で挙げた要素の多くまたはすべてを含む。図２に示す論理接続には、ローカルネットワーク（ＬＡＮ）１９６とワイドネットワーク（ＷＡＮ）１９８とが含まれるが、他のネットワークを含むことも可能である。このようなネットワーキング環境は、オフィス、企業内のコンピュータネットワーク、イントラネット、および世界規模のコンピュータネットワーク（インターネットなど）に一般的に見られる。
【００３２】
ローカルエリアネットワーキング環境で使用する場合、コンピュータ１３０はネットワークインターフェースまたはアダプタ１８６を通じてＬＡＮ１９６に接続される。ワイドエリアネットワーキング環境で使用する場合、コンピュータ１３０は通例、インターネットなどのＷＡＮ１９８を通じて通信を確立するためのモデム１７８またはその他の手段を含む。モデム１７８は内蔵型でも外付け型でもよく、ユーザ入力インターフェース１９４または他の適切な機構を介してシステムバス１３６に接続される。ネットワーク環境では、コンピュータ１３０との関連で図示したプログラムモジュール、またはその一部は遠隔のメモリ記憶装置（図示せず）に格納することができる。これに限定しないが、例として、図２ではリモートアプリケーションプログラム１９２がメモリ装置に常駐している。図のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用してよいことは理解されよう。
【００３３】
一般に、コンピュータ１３０のデータプロセッサは、様々な時にコンピュータの各種のコンピュータ可読記憶媒体に記憶された命令によってプログラムされる。プログラムおよびオペレーティングシステムは、通例、例えばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭなどで配布される。そこから、コンピュータの２次メモリにインストールまたはロードされる。実行時に、プログラムおよびオペレーティングシステムは、少なくとも一部がコンピュータの主要な電子メモリにロードされる。本明細書に記載する本発明は、そのような媒体が、マイクロプロセッサまたは他のデータプロセッサと協働して下記のステップを実施する命令またはプログラムを含む場合はそれらおよび他の各種のコンピュータ可読記憶媒体を含む。本発明は、下記の方法および技術に従ってプログラムされた場合にはコンピュータ自体も含む。
【００３４】
説明のために、プログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントはこの図では別々のブロックとして示している。ただし、そのようなプログラムおよびコンポーネントは、様々な時にコンピュータの様々な記憶コンポーネントに存在し、コンピュータのデータプロセッサによって実行されることは認識されよう。
【００３５】
次いで図３を参照すると、ブロック図により、図１との関係で図示し、説明したようなＵＳＢを介して接続されたデバイスのソフトウェアモデルを示す。図３のソフトウェアモデルは、例示的なデバイス構成に関連付けられたソフトウェアコンポーネントを示す。図３のデバイス構成は、図１のデバイス構成とは異なる。図３では、点線で示したハードウェアデバイスは、そのデバイスの隣に図示するソフトウェアコンポーネントに関連付けられる。
【００３６】
この実施形態では、ＵＳＢコントローラ３０２は、コンピュータ（コンピュータ１３０など）に関連付けられたＰＣＩバス３０４に接続する。ＵＳＢコントローラ３０２は、ルートハブ３０６を含む。ルートハブ３０６は、ポート＃１〜＃Ｎとして示す１つまたは複数のポート３０８を含む。ハブ３１０は、ポート３０８の１つに接続する。ハブ３１０のためのソフトウェアにはバスドライバ３１２およびクライアントドライバ３１４が含まれる。包括的な親（あるいは他の複合デバイス）３１６およびＨＩＤ３１８は、ハブ３１０の子デバイスすなわち子ノードとしてハブ３１０に接続する。ＨＩＤ３１８のためのソフトウェアにはクライアントドライバが含まれる。図３の例示的実施形態では、ＨＩＤ３１８はマウスに関連付けられている。包括的な親３１６は、２つの子デバイス、すなわちオーディオコンポーネント３２０およびＨＩＤ３２２を有する。ソフトウェアクライアントドライバが、オーディオコンポーネント３２０とＨＤ３２２とに別々に関連付けられる。この例では、オーディオコンポーネント３２０はスピーカに関連付けられている。さらに、ＨＩＤ３２２は、１つまたは複数のスピーカボタンに関連付けられている。
【００３７】
次いで図４を参照すると、流れ図により、ＨＩＤ３２２などの子ＵＳＢデバイスを制御するドライバソフトウェアの例示的動作を説明している。ドライバソフトウェアは、図１および３との関連で説明したようなＵＳＢデバイス（例えば包括的な親やハブデバイス）をサスペンドすることをシグナリングし、待機する方法を含む。ＵＳＢデバイスに関連付けられたドライバソフトウェアは、ステップ４０２でＵＳＢデバイスがアイドル状態であるかどうかを継続的に判定する。ドライバソフトウェアは、ＵＳＢデバイスがアイドル状態であるか、ないしはサスペンドできる状態にあると判定すると、ステップ４０４でＵＳＢデバイスの親デバイス（例えば親３１６）にアイドル要求を提出するか、ないしはシグナリングする。例えば、ドライバソフトウェアは、ソフトウェア中の自身の物理デバイスオブジェクトに要求を送信する。一実施形態では、アイドル要求の提出または送信は、ＵＳＢデバイスからそのＵＳＢデバイスの親デバイスにＩＯＣＴＬ要求を送信することを含む。一実施形態では、ＩＯＣＴＬ要求の送信は、ＩＯＣＴＬ要求を含む入出要求パケット（ＩＲＰ）をＵＳＢデバイスからそのＵＳＢデバイスの親デバイスに送信することを含む。例えば、ＵＳＢデバイスはＵＳＢホストコントローラであり、ＵＳＢデバイスの親デバイスはコンピュータであることが考えられる。この例では、ＵＳＢホストコントローラは、ＵＳＢホストコントローラがサスペンドできる状態であることをコンピュータにシグナリングする。コンピュータはその後、ＵＳＢホストコントローラに他のデバイスが接続されていなくともＵＳＢホストコントローラをサスペンドさせることができる。すなわち、アイドル状態になることを求めるルートハブのクライアントドライバは、そのルートハブの物理デバイスオブジェクト（ＰＤＯ）にアイドル要求を送信する。ＰＤＯは次いで、クライアントドライバにルートハブをサスペンドするように指示する。
【００３８】
一実施形態では、ＵＳＢデバイスは、アクティブ状態とアイドル状態とを有する。この例では、ＵＳＢデバイスは、アイドル状態にある時にはサスペンド可能な状態にある。本発明は、ＵＳＢデバイスが完全にアイドル状態でなくともサスペンドを要求することが可能な他の実施形態を企図する。例えば、ＵＳＢデバイスは、フルパワーを必要としない動作を行っている可能性がある。そのため、ＵＳＢデバイスは、低電力モードまたは他のサスペンド状態に入る間もその動作を継続して実行することができる。ＵＳＢデバイスが１つまたは複数の子ノード（下記の図５参照）を有する実施形態では、ＵＳＢデバイスは、そのＵＳＢデバイスがアイドル状態であり、ＵＳＢデバイスの各子ノードがサスペンド可能な状態にある時に、サスペンドできる状態にある。この例では、ＵＳＢデバイスの各子ノードは、ＵＳＢデバイスにアイドル要求を送信して自身がサスペンドできる状態にあることを知らせているはずである。
【００３９】
アイドル要求を提出すると、ドライバソフトウェアはステップ４０６で親デバイスから自身の電力低下のコールバック関数が呼び出されるのを待つ。親デバイスから電力低下のコールバック関数が呼び出されると、ＵＳＢデバイスのドライバソフトウェアは、ステップ４０８で電力低下のコールバック関数を実行してＵＳＢデバイスをサスペンドさせる。非アイドルのアクティビティ（ａｃｔｉｖｉｔｙ）後、ステップ４１０でドライバソフトウェアがＵＳＢデバイスをウェイクする。ＵＳＢデバイス、ＵＳＢデバイスの複数の子ノードのいずれか１つまたは複数、ＵＳＢデバイスの親ノード、またはコントローラに関連付けられたソフトウェア（例えばアプリケーションプログラム）は、ＵＳＢデバイスにウェイクするようにシグナリングする非アイドルアクティビティを行うことができる。例えば、ＵＳＢデバイスがマウスなどのポインティングデバイスである場合は、非アイドルアクティビティはマウスの移動とすることができる。同様に、親ノードがコントローラであり、デバイスの１つまたは複数がスピーカである場合は、そのコントローラに関連付けられたコンピュータで実行されるソフトウェアは、スピーカで音楽を再生することにより非アイドルアクティビティを生成することができる。デバイスをウェイクすることは、デバイスが自由に新規のアイドル要求を提出できるようにアイドル要求を再設定することを含む。
【００４０】
デバイスをＵＳＢで接続する実施形態では、ＵＳＢデバイス（およびそのＵＳＢツリー全体）がサスペンド状態にされると、そのデバイス（およびその後ＵＳＢデバイスツリー全体）を「目覚め（ａｗａｋｅｎ）」させ、フルパワーモードに戻す方法が少なくとも２つある。第１の方法は、任意のＵＳＢクラスドライバが、そのデバイスについての適切な電力設定要求を提出することにより、その子デバイスをフルパワーモードにするものである。第２の方法は、リモートウェイクをサポートし、低電力モードに置かれる前にあらかじめリモートウェイクを使用可能にしてある任意のＵＳＢデバイスでの「リモートウェイク」アクティビティを利用するものである。これらの各場合で、行われる動作はデバイスツリー全体をフルパワーモードにする効力を持ち、子デバイスに対応するＵＳＢクラスドライバは、各自の子デバイスまたはインターフェースがアイドル状態にあり、もはや使用中でないと判断すると、それ以降再び自由に新規のアイドル要求を提出することができ、全サイクルが再度開始する。
【００４１】
すなわち、一旦サスペンド状態に置かれると、デバイスは、２つの方式の少なくとも１つでウェイクさせることができる。第１に、ウェイクは、リモートウェイク対応デバイスについてのシグナリングの再開を介して行うことができる（すなわち待機／ウェイクのＩＲＰが正常に完了する）。通例、デバイスは、機能ドライバの待機／ウェイクＩＲＰの完了ルーチンによって、完全に動作可能な電力状態（例えば電力状態Ｄ０）に設定される。待機／ウェイクＩＲＰを使用して、リモートウェイクが行えるようにデバイスを備える（ａｒｍ）。第２に、ウェイクは、クライアントソフトウェアによって開始される新しいオープン要求を介して行うことができる。ウェイクプロセス中、アイドル要求メッセージはリセットされるか、ないしはキャンセルされる。
【００４２】
本発明の一実施形態では、ドライバは、子デバイスがもはやサスペンドできる状態にない時には、自身のコールバック関数を実行する前に子デバイスの親デバイスにキャンセル要求を送信することにより、その子デバイスまたはインターフェースについてのアイドル要求をキャンセルすることができる。一般に、キャンセル要求は、アイドル要求の送信後に子デバイスによって送信される。コントローラ（例えばＵＳＢコアスタック）は、キャンセル要求に応答して、現在進行中のサスペンド状態への遷移をキャンセルし、デバイスツリー中の他のデバイスについての保留中の他のアイドル要求をキャンセルする。
【００４３】
サスペンド後にキャンセル要求が送信された場合、コントローラは、そのキャンセル要求を、デバイスツリー全体をウェイクすることを必要とする非アイドルアクティビティと見なす。
【００４４】
ＵＳＢデバイスと親デバイスとは、通信媒体を介して接続される。この通信媒体には、これに限定しないが、図２との関連で説明したネットワークまたはバスアーキテクチャが含まれる。そのようなバスアーキテクチャには、階層的なパラレルバス、ツリー状の接続性を有する無線バス、およびＵＳＢが含まれる。例えば、図４との関連で説明したノードは、ＵＳＢを介して接続されたデバイスであってよい。この例では、他のデバイスがサスペンドするとＵＳＢハブおよび／またはＵＳＢコントローラもサスペンドする。さらに、コンピュータは、他のデバイス（そのコンピュータの内部または外部の）がバスに接続されていない時でもＵＳＢコントローラをサスペンドさせることができる。
【００４５】
本発明は、図４に示す方法を行うコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を含む。
【００４６】
一実施形態では、デバイス間の通信は、オペレーティングシステムの内部にあるデバイスのソフトウェア表現を介して行われる。例えば、コントローラがアイドル要求を受け取る時には、そのコントローラのソフトウェアデバイスオブジェクトがアイドル要求を受け取る。当業者は、通信は物理ハードウェアデバイス間の電気的なシグナリングを利用して行ってもよいことに気付かれよう。さらに、当業者は、親デバイスと子デバイスとは論理的には異なってよいが、制御および機能のために物理的には異ならないことに気付かれよう。例えば、デバイスは、内蔵ハブと２つの内蔵デバイス、または２つの独立して制御される機能を有する複合デバイスを含むことができる。
【００４７】
次いで図５を参照すると、流れ図により、親ＵＳＢデバイス（例えば親３１６）を制御するドライバソフトウェアの動作を説明している。親ＵＳＢデバイス（例えば包括的な親またはハブデバイス）は、その親ＵＳＢデバイスに接続された１つまたは複数の子デバイス（例えばオーディオ３２０やＨＩＤ３２２）を有する。親ＵＳＢデバイスのドライバソフトウェアは、ステップ５０２で繰り返しループして、各子デバイスからアイドル要求を受け取っているかどうかを判定する。各子デバイスからアイドル要求を受け取っている場合、ドライバソフトウェアはステップ５０４で、親ＵＳＢデバイス自体がアイドル状態であるかどうかを判定する。親ＵＳＢデバイスがアイドル状態でない場合、ドライバソフトウェアはステップ５０２の判定に戻る。親ＵＳＢデバイスがアイドル状態である場合、ドライバソフトウェアはステップ５０６で親デバイスがルートハブであるかどうかを判定する。親ＵＳＢデバイスがルートハブでない場合、親ＵＳＢデバイスは、ステップ５０８で、アイドル要求を親ＵＳＢデバイスの親デバイス（例えばハブ３１０）に提出することにより、受け取ったアイドル要求を伝播する。一実施形態では、提出されるアイドル要求は、子デバイスから受け取ったすべてのアイドル要求を含む。子デバイスが、ツリー中で親ＵＳＢデバイスの下位にある子デバイスを有する場合、提出されるアイドル要求は、下位の子デバイスそれぞれから提出されたすべてのアイドル要求を含む。このようにして、ツリー中の各デバイスからツリーのルートにあるルートハブまたは他のコントローラにアイドル要求が伝播される。
【００４８】
親ＵＳＢデバイスがルートハブである場合、親ＵＳＢデバイスは、ステップ５１０でそのデバイスのツリーをサスペンド状態にする（図５参照）。デバイスがＵＳＢで接続される実施形態では、ルートハブがツリー中のデバイスの電力を管理する。
【００４９】
当業者は、アイドル状態の判定を行う順序は図５に示す順序に限らないことに気付かれよう。各子ノードからアイドル要求を受け取っているかどうかの判定、および親ＵＳＢデバイスがアイドル状態かどうかの判定は、ツリーがサスペンドされる前、または親ＵＳＢデバイスがアイドル要求をその親ＵＳＢデバイスの親デバイスに伝播する前に両方の判定が満たされるのであれば、任意の順序で行うことができる。すなわち、アイドル要求の伝播は、一般には、第１のデバイスがサスペンドできる状態にあり、第１のデバイスが自身の各子デバイスからアイドル要求を受け取った場合に、受け取ったアイドル要求を第１のデバイスから第２のデバイス（第１のデバイスの親など）に送信することを含む。アイドル要求の伝播は、第１のデバイスからコントローラまでツリー構造を帰納的に横断することを含む。詳細には、アイドル要求の伝播は、第１のデバイスが当該第１のデバイスの各子ノードからアイドル要求を受け取っているかどうかを判定することを含む。ドライバソフトウェアは、各子ノードからアイドル要求を受け取っていない場合は、各子ノードからアイドル要求を受け取るのを待つ。ドライバソフトウェアは、第１のデバイスが各子ノードからアイドル要求を受け取っている場合は第２のデバイスにアイドル要求を提出する。
【００５０】
本発明は、図５に示す方法を行うコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を含む。
【００５１】
次いで図６を参照すると、流れ図により、デバイスのツリーをサスペンド状態にするコントローラソフトウェアの動作を説明している。ＵＳＢでデバイスを接続する実施形態では、図６は、ツリー中のデバイスの電力を管理するルートハブ（例えばルートハブ３０６）に対応するソフトウェアの動作を説明することになる。他の実施形態では、ルートハブ以外のツリーのルートにあるコンポーネントにコントローラソフトウェアを関連付けることができる。
【００５２】
図６に関して、ツリーは、ツリー中の子デバイスおよび親デバイスとして階層的に編成された１つまたは複数のデバイスを含む。詳細には、ルートハブは、ルートハブに接続され、ツリー構造に編成された１つまたは複数の子デバイスを有する。コントローラソフトウェア（例えばＵＳＢコアスタック）は、子デバイスからアイドル要求を受け取る。ルートハブのコントローラソフトウェアは、ステップ６０２で繰り返しループして各子デバイスからアイドル要求を受け取っているかどうかを判定する。各子デバイスからアイドル要求を受け取っている場合、コントローラソフトウェアはステップ６０４でデバイスのツリーをサスペンドさせる。
【００５３】
一実施形態では、子デバイスから受け取るアイドル要求は、ツリー構造中でさらに下位にある子デバイスから伝播されたアイドル要求を含む。ツリー中の各親が各自の子デバイスそれぞれの電力低下のコールバック関数を呼び出すことによってサスペンドが行われる。このサスペンドは、子デバイスから受け取るアイドル要求と伝播されるアイドル要求とがたどる経路を通じてツリー全体で行われる。このサスペンドは、ツリー中の各子デバイスのドライバソフトウェアが子デバイスの親デバイスから自身のコールバック関数への呼び出しを受け取り、次いでコールバック関数を実行して子デバイスをサスペンドさせるのでツリー全体に伝播される。各子デバイスのサスペンドは、子デバイスを低電力モードまたは他のサスペンド状態に入れるコールバック関数を実行することを含む。
【００５４】
代替実施形態では、ルートハブまたは他のコントローラは、ルートハブに接続された各子デバイスから１つのアイドル要求を受け取り、受け取るアイドル要求は、さらに下位の子デバイスからのアイドル要求は含まない。子デバイスからのすべてのアイドル要求を受け取るのに応答して、ルートハブは、電力低下のコールバック関数を逆方向に伝播することによりツリー中のすべてのデバイスをサスペンドさせる。すなわち、ルートハブのコントローラソフトウェアがルートハブの各子デバイスの電力低下のコールバック関数を呼び出し、次いで各子デバイスのドライバソフトウェアが自身の各子デバイスの電力低下のコールバック関数を呼び出す。このようにしてツリー中の各デバイスをサスペンドさせる。この実施形態では、各親デバイスのドライバソフトウェアが、当該親デバイスの各子デバイスのドライバソフトウェアに固有の電力低下コールバック関数を認識することが確実になる。
【００５５】
本発明は、図６に示す方法を行うコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を含む。
【００５６】
次いで図７を参照すると、ブロック図により、ツリー構造中で子デバイスであるＨＩＤを制御するドライバソフトウェアに関連付けられたシグナリングコンポーネント７０４およびドライバコンポーネント７０６を示している。図７の子デバイスはＨＩＤとして説明するが、当業者は、子デバイスは任意のバスデバイス（例えばＵＳＢデバイス）であってよいことに気付かれよう。このツリーは、親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含む。一実施形態では、親デバイスおよび子デバイスはＵＳＢで接続される。ＨＩＤに関連付けられた１つまたは複数のコンピュータ可読媒体７０２は、ＨＩＤのサスペンドをシグナリングし、待機するためのコンピュータ実行可能コンポーネントを有する。このコンポーネントには、シグナリングコンポーネント７０４とドライバコンポーネント７０６とが含まれる。シグナリングコンポーネント７０４は、ＨＩＤがサスペンド可能な状態になると、ＨＩＤからＨＩＤの親デバイスにアイドル要求を送信する。このアイドル要求は、親デバイスからコントローラすなわちルートハブデバイスまでツリー中を伝播する。さらに、ＨＩＤが少なくとも１つの子デバイスを有する場合、シグナリングコンポーネント７０４は、その子デバイスからアイドル要求を受け取り、受け取ったアイドル要求を親デバイスに送信する。
【００５７】
一実施形態では、アイドル要求は、ＨＩＤのサスペンドの前に送信された場合は、ＨＩＤによってキャンセルすることができる。この実施形態では、シグナリングコンポーネント７０４は、ＨＩＤによる非アイドルアクティビティに応答してＨＩＤから親デバイスにキャンセル要求を送信する。キャンセル要求は、コントローラあるいはルートハブまで伝播し、シグナリングコンポーネント７０４から送信されたアイドル要求がその後キャンセルされる。ＨＩＤをサスペンドさせた後に送信された場合、キャンセル要求は、コントローラあるいは親デバイスにより、ツリー中の全デバイスのウェイクを必要とする非アイドルアクティビティと見なされる。
【００５８】
ドライバコンポーネント７０６は、自身の親デバイスからそのコールバック関数が呼び出されるのを待ってＨＩＤをサスペンドする。シグナリングコンポーネント７０４は、伝播されたアイドル要求に応答してコントローラから自身のコールバック関数の呼び出しを受け取る。ドライバコンポーネント７０６は、シグナリングコンポーネント７０４によって呼び出されたコールバック関数の実行に応答してＨＩＤをサスペンドする。一実施形態では、コールバック関数は電力低下関数を実行してＨＩＤの電力を下げる。さらに、電力低下関数は、ＨＩＤを低電力モードにするための低電力関数を含むことができる。ドライバコンポーネント７０６は、ＨＩＤによるアクティビティ、親デバイスからの信号、またはコントローラに関連付けられたソフトウェアからの信号に応答してＨＩＤをウェイクする。
【００５９】
次いで図８を参照すると、ブロック図により、コントローラに関連付けられたインターフェースコンポーネント８０４とコントローラコンポーネント８０６とを示している。当業者は、本明細書で概説し、特に図７および８との関連で説明するコントローラの機能の一部またはすべては、コントローラの子として機能するルートハブデバイスが行ってもよいことに気付かれよう。１つまたは複数のコンピュータ可読媒体８０２は、ツリーのルートにあるコントローラによってデバイスのツリーに電力制御を施行するためのコンピュータ実行可能コンポーネントを有する。１つまたは複数のコンピュータ可読媒体８０２は、そのコントローラに関連付けられる。ツリーは、ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含む。一実施形態では、親デバイスと子デバイスとはＵＳＢで接続される。コンポーネントには、インターフェースコンポーネント８０４とコントローラコンポーネント８０６とが含まれる。インターフェースコンポーネント８０４は、１つまたは複数の子デバイスからアイドル要求を受け取る。コントローラコンポーネント８０６は、各子デバイスからアイドル要求を受け取るとツリー中のすべてのデバイスをサスペンドする。コントローラはその後、コントローラ、デバイスのいずれか、またはその両方によるアクティビティに応答してツリー中のデバイスをウェイクする。
【００６０】
次いで図９を参照すると、ブロック図によりＩＯＣＴＬアイドル要求のデータ構造を示している。コンピュータ可読媒体９０２は、ＩＯＣＴＬ要求として実施されたアイドル要求を表すデータ構造９０４を格納する。データ構造９０４は、第１のフィールドと第２のフィールドとを含む。第１のフィールドは、コールバック関数を表すルーチン属性９０６を格納する。ルーチン属性９０６は、例えば、親が子デバイスのデバイスの電力を安全に低下できることを子に通知する際に親によって呼び出される子ドライバ中の関数へのポインタである。第２のフィールドは、コールバックコンテクストを表すコンテクスト属性９０８を格納する。コールバックコンテクストは、呼び出されるとコールバック関数に渡され、そのコールバック関数を実行するための環境を提供する。本明細書で説明するように、第１のデバイスは、第１のデバイスがサスペンドできる状態になるとデータ構造９０４を介して第２のデバイスにアイドル要求を送信する。図４および５との関連で説明したように、アイドル要求の送信に応答してコールバック関数が実行されて第１のデバイスをサスペンドさせる。
【００６１】
第１のデバイスは、ツリー構造に編成された１つまたは複数の子ノードを有する。さらに、第１のデバイスは、アクティブ状態とアイドル状態とを有する。第１のデバイスは、第１のデバイスの１つまたは複数の子ノードそれぞれがサスペンドできる状態になると、サスペンド可能な状態になる。一実施形態では、第１のデバイスと第２のデバイスは、ユニバーサルシリアルバスで接続される。
【００６２】
図９のデータ構造９０４の一例を下に示す。

【００６３】
当業者は、本明細書で説明するデバイスは、これに限定しないが、コンピュータ外部のデバイスとコンピュータに内蔵されたデバイスとを含むことに気付かれよう。デバイスは、例えば、ラップトップコンピュータに内蔵されたＵＳＢ準拠デバイスである。本発明を使用して、ラップトップコンピュータは、内蔵ＵＳＢデバイス、ラップトップ、あるいは別の内蔵デバイス（例えばコントローラ）に関連付けられたキャッシュおよびプロセッサがサスペンド状態（例えばＣ３）に入ることを許可する。
【００６４】
次のＵＳＢ固有の例によって、本発明を例示する。ＵＳＢクラスドライバは、それがロードされた対象のＵＳＢデバイスがアイドル状態であり、もはや使用中でないと判断すると、ＩＯＣＴＬアイドル要求を含むＩＲＰをＵＳＢコアスタックに送信して、そのデバイスのＵＳＢクラスドライバがそのデバイスを低電力モードにしようとしていることをＵＳＢコアスタックに通知する。このＩＯＣＴＬアイドル要求を、ＩＯＣＴＬ＿ＩＮＴＥＲＮＡＬ＿ＵＳＢ＿ＳＵＢＭＩＴ＿ＩＤＬＥ＿ＮＯＴＩＦＩＣＡＴＩＯＮと参照する。ＩＯＣＴＬアイドル要求は、ＰＡＳＳＩＶＥ＿ＬＥＶＥＬの割り込み要求レベル（ＩＲＱＬ）で送られる。ＵＳＢコアスタックがこの要求を受け取ると、ＵＳＢコアスタックドライバは、子デバイスがアイドル状態であることに気付く。ＵＳＢコアスタック、バス、またはポートドライバは、Ｉｒｐ−＞ＩｏＳｔａｔｕｓ．Ｓｔａｔｕｓなどの変数にＳＴＡＴＵＳ＿ＳＵＣＣＥＳＳなどの該当するエラーステータスを設定する。次いでＵＳＢコアドライバは、すべての子デバイスのリストを検索して、すべての他の子デバイスのすべてのＵＳＢクラスドライバが各自の子デバイスを低電力モードに入れることをすでに要求しているかどうかを判定する。ＵＳＢコアドライバが、実際にすべてのＵＢＳ子デバイスを低電力モードに入れることが各デバイスのためにロードされたＵＳＢクラスドライバにより要求されていると判定すると、ＵＳＢコアスタックは、それらＵＳＢ子デバイスの親デバイスにアイドル要求を提出する。親デバイスは、子デバイスがＵＳＢ複合デバイスである場合は包括的なＵＳＢ親デバイスであってよい。同様に、親デバイスは、子デバイスが単純なＵＳＢデバイスである場合はＵＳＢハブであってよい。包括的な親ＵＳＢデバイスまたはハブデバイスは、そのすべての子デバイスがアイドル状態であればアイドル状態になる。
【００６５】
ＵＳＢデバイスのツリー全体にアイドル要求が伝播され、ＵＳＢルートハブデバイスについてアイドル要求が提出されると、ＵＳＢルートハブデバイスは、ロードされた自身のクラスドライバ（ＵＳＢＨＵＢ．ＳＹＳ）のコールバックを呼び出す。各ＵＳＢ親デバイス、ＵＳＢ複合デバイス、またはハブデバイスは、その後、各ＵＳＢ子デバイスまたはインターフェースのためにロードされた各ＵＳＢクラスドライバのコールバックを呼び出す。そのようなドライバはすべて、各自のＵＳＢデバイスまたはインターフェースを低電力モードに入れることを要求し、したがってＵＳＢデバイスとＵＳＢルートハブとからなるツリー全体が低電力モードに入れられる。ＵＳＢルートハブを低電力モードにすると、次いでＵＳＢホストコントローラも低電力モードにする。ＵＳＢデバイスまたはインターフェースがリモートウェイクアップをサポートし、保留中のＩＲＰ＿ＭＮ＿ＷＡＩＴ＿ＷＡＫＥ要求がない場合は、それらのデバイスまたはインターフェースのコールバックルーチンは、それらデバイスまたはインターフェースの電力を切る前にＩＲＰ＿ＭＮ＿ＷＡＩＴ＿ＷＡＫＥ要求をＵＳＢコアスタックに提出しなければならない。あるいは、そのＩＲＰが必要とされることが明らかになると、ファンクションドライバは、この要求の提出をコールバックルーチンで行うのを待つのではなく、Ｗａｉｔ／ＷａｋｅＩＲＰをＵＳＢドライバスタックに提出する。
【００６６】
また、ハブドライバは、デバイスを完全に動作可能な電力状態（すなわちＤ０）に設定できる場合は、成功を示すステータスコードでアイドル要求を完了する。これは、そのデバイスがもはやアイドル状態ではないことをより高いレベルのドライバに知らせる。ただし、そのデバイスが除去あるいは停止されている場合は、ハブドライバは、該当するエラーコードでアイドル要求ＩＲＰを完了する。
【００６７】
機能ドライバがアイドル要求ＩＲＰをキャンセルする場合、ハブドライバは、エラーコードでＩＲＰを完了する。機能ドライバの完了ルーチンが、ハブドライバがＳＴＡＴＵＳ＿ＰＯＷＥＲ＿ＳＴＡＴＥ＿ＩＮＶＡＬＩＤ以外のエラーコードでアイドル要求ＩＲＰを完了していることを検出すると、機能ドライバはそのデバイスの電源を入れることを試みる。一実施形態では、ハブドライバは、アイドル要求ＩＲＰをエラーで完了する時にはデバイスが電源供給状態にあることを保証しない。
【００６８】
本発明の一態様によれば、ある方法が、第１のデバイスのサスペンドをシグナリングし、待機することを提供する。第１のデバイスは、通信媒体を介して第２のデバイスに接続される。この方法は、第１のデバイスがサスペンドできる状態になると第１のデバイスから第２のデバイスにアイドル要求を送信することを含む。この方法はさらに、第１のデバイスに関連付けられたコールバック関数の呼び出しを第２のデバイスから受け取るのを第１のデバイスが待機して第１のデバイスをサスペンドすることを含む。
【００６９】
本発明の別の態様によれば、ある方法が、デバイスツリーのサスペンドを提供する。このツリーは、ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含む。ツリーはさらに、ツリーのルートにあるコントローラを含む。この方法は、子デバイスの１つまたは複数からのアイドル要求をコントローラが受け取ることを含む。この方法はさらに、ツリー中の各デバイスからアイドル要求を受け取った後にツリー中のすべてのデバイスをコントローラがサスペンドすることを含む。
【００７０】
本発明のさらに別の態様によれば、１つまたは複数のコンピュータ可読媒体が、デバイスツリー中のデバイスをサスペンドすることをシグナリングし、待機するコンピュータ実行可能コンポーネントを有する。このツリーは、親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含む。ツリーは、ツリーのルートにコントローラを有する。上記のコンポーネントには、少なくとも１つの子デバイスがサスペンド可能な状態になった時にその子デバイスから親デバイスにアイドル要求を送信するシグナリングコンポーネントが含まれる。アイドル要求は、親デバイスからコントローラまでツリー中を伝播する。コンポーネントには、子デバイスに関連付けられたコールバック関数へのコントローラからの呼び出しを当該子デバイスが受け取るのを待って子デバイスをサスペンドするためのドライバコンポーネントも含まれる。
【００７１】
本発明の態様を実施する１つまたは複数のコンピュータ可読媒体は、ツリーのルートにあたるコントローラによりデバイスのツリーに電力制御を施行するためのコンピュータ実行可能コンポーネントを有する。ツリーは、ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含む。コンポーネントには、１つまたは複数の子デバイスからのアイドル要求をコントローラによって受け取るためのインターフェースコンポーネントが含まれる。コンポーネントには、各子デバイスからアイドル要求を受け取った後にツリー中のすべてのデバイスをコントローラによってサスペンドするためのコントローラコンポーネントも含まれる。
【００７２】
本発明のさらに別の実施形態では、コンピュータ可読媒体が、アイドル要求を表すデータ構造を格納する。このデータ構造は、第１のフィールドと第２のフィールドとを含む。第１のフィールドは、コールバック関数を表すルーチン属性を格納する。第２のフィールドは、コールバックコンテクストを表すコンテクスト属性を格納する。第１のデバイスは、サスペンドできる状態になるとこのデータ構造を介して第２のデバイスにアイドル要求を送信する。
【００７３】
本発明についてコンピュータ１３０を含む例示的コンピューティングシステム環境との関連で説明したが、本発明は、他の多数の汎用または特殊目的のコンピューティングシステム環境または構成で動作することができる。このコンピューティングシステム環境は、本発明の使用または機能性の範囲について何らの限定を示唆するものではない。さらに、このコンピューティングシステム環境は、例示的動作環境に示す構成要素の１つまたは組み合わせに関連する依存性または必要性を持つものと解釈すべきでない。本発明と共に使用するのに適する可能性があるよく知られるコンピューティングシステム、環境、および／または構成の例には、これらに限定しないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド機器またはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な消費者家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは機器を含む分散コンピューティング環境などが挙げられる。
【００７４】
本発明は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令に概ね即して説明することができる。一般に、プログラムモジュールには、これらに限定しないが、特定のタスクを行うか、特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造が含まれる。本発明は、通信ネットワークを通じてリンクされた遠隔の処理機器によってタスクを行う分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート両方の記憶媒体に置くことができる。
【００７５】
本発明またはその実施形態の要素を紹介する際、冠詞「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」は、その要素が１つまたは複数あることを意味する。用語「〜を備える（ｃｏｍｐｒｉｓｉｎｇ）」、「〜を含む（ｉｎｃｌｕｄｉｎｇ）」、および「〜を有する（ｈａｖｉｎｇ）」は、包含的な意味とし、列記した要素以外に追加的な要素があってよいことを意味する。
【００７６】
上述から、本発明のいくつかの目的が達成され、他の有利な結果が得られることが理解されよう。
【００７７】
本発明の範囲から逸脱することなく上記の製品および方法には各種の変更を行えるので、上記の説明に含まれ、添付図面に示すすべての事項は説明を目的とするものであり、限定的な意味に解釈すべきではない。
【図面の簡単な説明】
【００７８】
【図１】ユニバーサルシリアルバスで接続されたデバイスのハードウェアモデルを示す本発明の一実施形態のブロック図である。
【図２】本発明を実施することが可能な例示的コンピューティングシステム環境を示す本発明の一実施形態のブロック図である。
【図３】ユニバーサルシリアルバスで接続されたデバイスのソフトウェアモデルを示す本発明の一実施形態のブロック図である。
【図４】子ＵＳＢデバイスを制御するドライバソフトウェアの動作を説明する本発明の一実施形態の流れ図である。
【図５】親ＵＳＢデバイスを制御するドライバソフトウェアの動作を説明する本発明の一実施形態の流れ図である。
【図６】デバイスのツリーをサスペンドするコントローラソフトウェアの動作を説明する本発明の一実施形態の流れ図である。
【図７】ツリー構造中の子ＵＳＢデバイスを制御するドライバソフトウェアに関連付けられたシグナリングコンポーネントおよびドライバコンポーネントを示す本発明の一実施形態のブロック図である。
【図８】ハードウェアデバイスに電力制御を施行するインターフェースコンポーネントおよびコントローラコンポーネントを示す本発明の一実施形態のブロック図である。
【図９】ＩＯＣＴＬアイドル要求を示す本発明の一実施形態のブロック図である。

Claims (50)

1. 第１のデバイスをサスペンドすることをシグナリングし、待機する方法であって、前記第１のデバイスは通信媒体を介して第２のデバイスに接続され、前記方法は、
   前記第１のデバイスがサスペンド可能な状態になると前記第１のデバイスから前記第２のデバイスにアイドル要求を送信すること、および
   前記第１のデバイスに関連付けられたコールバック関数への前記第２のデバイスからの呼び出しを受け取るのを前記第１のデバイスによって待機して、前記第１のデバイスをサスペンドすること
   を含むことを特徴とする方法。
2. 前記第２のデバイスはコンピュータであり、前記第１のデバイスは前記コンピュータに関連付けられた周辺コンポーネントであることを特徴とする請求項１に記載の方法。
3. 前記周辺コンポーネントは、複合デバイス、ルートハブ、およびコントローラからなる群から選択されることを特徴とする請求項２に記載の方法。
4. 前記送信ステップおよび待機ステップは、前記第１のデバイスを制御するドライバを介して行われることを特徴とする請求項１に記載の方法。
5. 前記第１のデバイスはアクティブ状態とアイドル状態とを有し、前記第１のデバイスは前記アイドル状態にある時にサスペンド可能であることを特徴とする請求項１に記載の方法。
6. 前記第１のデバイスは、ツリー構造に編成された複数のノードの１つからなり、前記第１のデバイスは、前記第２のデバイスの子ノードであることを特徴とする請求項１に記載の方法。
7. 請求項６に記載の方法を行うコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
8. 前記ツリー中のノードはユニバーサルシリアルバスで接続されることを特徴とする請求項６に記載の方法。
9. 前記第１のデバイスは、前記ツリー構造中に１つまたは複数の子ノードを有し、前記第１のデバイスは、前記第１のデバイスの前記１つまたは複数の子ノードそれぞれがサスペンド可能な状態になるとサスペンド可能になることを特徴とする請求項６に記載の方法。
10. 前記第１のデバイスの前記子ノードの少なくとも１つからのアイドル要求を前記第１のデバイスによって受け取ることをさらに含むことを特徴とする請求項９に記載の方法。
11. 前記アイドル要求を前記第１のデバイスから前記ツリー構造のルートにあるコントローラに伝搬することをさらに含むことを特徴とする請求項１０に記載の方法。
12. 前記アイドル要求を伝搬することは、前記ツリー構造を前記第１のデバイスから前記コントローラまで帰納的に横断することにより前記アイドル要求を伝搬することを含むことを特徴とする請求項１１に記載の方法。
13. 前記アイドル要求を伝搬することは、前記第１のデバイスがサスペンド可能な状態であり、前記第１のデバイスが前記第１のデバイスの各子ノードからアイドル要求を受け取っている場合に、前記受け取ったアイドル要求を前記第１のデバイスから前記第２のデバイスに送信することを含むことを特徴とする請求項１１に記載の方法。
14. 前記アイドル要求を伝搬することは、
    前記第１のデバイスが前記第１のデバイスの各子ノードからアイドル要求を受け取っているかどうかを判定すること、
    各子ノードからアイドル要求を受け取っていない場合は、前記子ノードそれぞれからアイドル要求を受け取るのを待つこと、および
    前記第１のデバイスが前記子ノードそれぞれからアイドル要求を受け取っている場合は前記第２のデバイスにアイドル要求を提出すること
    を含むことを特徴とする請求項１１に記載の方法。
15. アイドル要求を送信することは、前記第１のデバイスから前記第２のデバイスに入出力制御（ＩＯＣＴＬ）要求を送信することを含むことを特徴とする請求項１に記載の方法。
16. 前記ＩＯＣＴＬを送信することは、前記第１のデバイスから前記第２のデバイスに入出力要求パケットを送信することを含むことを特徴とする請求項１５に記載の方法。
17. 前記第１のデバイスに関連付けられた前記コールバック関数への前記第２のデバイスからの呼び出しを前記第１のデバイスによって受け取り、前記受け取ったコールバック関数が実行されるのに応答して前記第１のデバイスをサスペンドすることをさらに含むことを特徴とする請求項１に記載の方法。
18. 前記第１のデバイスをウェイクさせることをさらに含むことを特徴とする請求項１７に記載の方法。
19. 前記ウェイクは、前記第１のデバイスが前記第２のデバイスに前記第１のデバイスがウェイクできる状態にあることをシグナリングするのに応答して行われることを特徴とする請求項１８に記載の方法。
20. 前記ウェイクは、前記第２のデバイスが前記第１のデバイスにウェイクするようにシグナリングするのに応答して行われることを特徴とする請求項１８に記載の方法。
21. 前記第１のデバイスは、ツリー構造に編成された複数のノードの１つであり、前記第１のデバイスは１つまたは複数の子ノードを有し、前記ウェイクは、前記子ノードの少なくとも１つが前記第１のデバイスにウェイクするようにシグナリングするのに応答して行われることを特徴とする請求項１８に記載の方法。
22. 前記ウェイクは、前記送信されたアイドル要求をリセットすることを含むことを特徴とする請求項１８に記載の方法。
23. 前記第１のデバイスがもはやサスペンド可能な状態でなくなると前記第１のデバイスから前記第２のデバイスにキャンセル要求を送信することをさらに含み、前記キャンセル要求の送信は、前記アイドル要求の送信後に行われることを特徴とする請求項１に記載の方法。
24. 第３のデバイスがサスペンド可能な状態になると前記第３のデバイスが前記第２のデバイスにアイドル要求を送信し、前記第１のデバイスと同時にサスペンドすることをさらに含み、前記第３のデバイスは、前記第１のデバイスとは独立した入出力の制御および機能を有することを特徴とする請求項１に記載の方法。
25. デバイスのツリーをサスペンドする方法であって、前記ツリーは、前記ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含み、前記ツリーはさらに、前記ツリーのルートにコントローラを含み、前記方法は、
    前記子デバイスの１つまたは複数からのアイドル要求を前記コントローラによって受け取ること、および
    前記ツリー中の各前記デバイスからアイドル要求を受け取った後に前記ツリー中のすべてのデバイスを前記コントローラによってサスペンドすること
    を含むことを特徴とする方法。
26. アイドル要求を受け取ることは、前記子デバイスを制御するソフトウェアを介して前記子の１つまたは複数からのアイドル要求を前記コントローラによって受け取ることを含むことを特徴とする請求項２５に記載の方法。
27. 前記サスペンドすることは、前記子デバイスそれぞれのコールバック関数を実行して前記子デバイスを低電力モードに入れることを含むことを特徴とする請求項２５に記載の方法。
28. 前記親デバイスと前記子デバイスとはユニバーサルシリアルバス（ＵＳＢ）を介して接続され、前記ツリーはＵＳＢハブを含み、さらに前記ＵＳＢハブを前記コントローラによってサスペンドすることを含むことを特徴とする請求項２５に記載の方法。
29. 前記親デバイスと前記子デバイスとはユニバーサルシリアルバス（ＵＳＢ）を介して接続され、前記コントローラはコンピュータであり、前記ツリーはＵＳＢコントローラを含み、ＵＳＢホストコントローラを前記コンピュータによってサスペンドすることをさらに含むことを特徴とする請求項２５に記載の方法。
30. アイドル要求を受け取るステップは、前記子デバイスの１つまたは複数からの入出力制御（ＩＯＣＴＬ）要求を前記コントローラによって受け取ることを含むことを特徴とする請求項２５に記載の方法。
31. 前記ＩＯＣＴＬ要求を受け取ることは、前記１つまたは複数の子デバイスからの入出力要求パケットを前記コントローラによって受け取ることを含むことを特徴とする請求項３０に記載の方法。
32. 前記親デバイスと子デバイスとはユニバーサルシリアルバスを介して接続されることを特徴とする請求項２５に記載の方法。
33. 請求項２５に記載の方法を行うコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
34. デバイスのツリー中のデバイスをサスペンドすることをシグナリングし、待機するコンピュータ実行可能コンポーネントを有する１つまたは複数のコンピュータ可読媒体であって、前記ツリーは、親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含み、前記ツリーは前記ツリーのルートにコントローラを有し、前記コンポーネントは、
    少なくとも１つの子デバイスがサスペンド可能な状態になった時に前記子デバイスから親デバイスにアイドル要求を送信するシグナリングコンポーネントであって、前記アイドル要求は、前記親デバイスから前記コントローラまで前記ツリー中を伝搬するシグナリングコンポーネントと、
    前記子デバイスに関連付けられたコールバック関数への前記コントローラからの呼び出しを前記子デバイスが受け取るのを待って、前記子デバイスをサスペンドするドライバコンポーネントと
    を含むことを特徴とするコンピュータ可読媒体。
35. 前記シグナリングコンポーネントは、前記子デバイスの少なくとも１つの子からのアイドル要求を受け取り、前記シグナリングコンポーネントは、前記受け取ったアイドル要求を前記親デバイスに送信することを特徴とする請求項３４に記載のコンピュータ可読媒体。
36. 前記シグナリングコンポーネントは、前記伝搬されたアイドル要求に応答して前記コントローラからコールバック関数の呼び出しを受け取ることを特徴とする請求項３４に記載のコンピュータ可読媒体。
37. 前記ドライバコンポーネントは、前記コールバック関数の実行に応答して前記子デバイスをサスペンドすることを特徴とする請求項３６に記載のコンピュータ可読媒体。
38. 前記ドライバコンポーネントは、前記子デバイスによるアクティビティ、または前記親デバイスからの信号、またはその両方に応答して前記子デバイスをウェイクすることを特徴とする請求項３７に記載のコンピュータ可読媒体。
39. 前記コールバック関数は、前記子デバイスの電力を低下する電力低下関数を含むことを特徴とする請求項３４に記載のコンピュータ可読媒体。
40. 前記電力低下関数は、前記子デバイスを低電力モードに入れる低電力関数を含むことを特徴とする請求項３９に記載のコンピュータ可読媒体。
41. 前記親デバイスと子デバイスとはユニバーサルシリアルバスを介して接続されることを特徴とする請求項３４に記載のコンピュータ可読媒体。
42. 前記シグナリングコンポーネントは、前記子デバイスによる非アイドルアクティビティに応答して前記子デバイスから前記親デバイスにキャンセル要求を送信することを特徴とする請求項３４に記載のコンピュータ可読媒体。
43. デバイスのツリーのルートにあるコントローラによって前記ツリーに電力制御を施行するためのコンピュータ実行可能コンポーネントを有する１つまたは複数のコンピュータ可読媒体であって、前記ツリーは、前記ツリー中の親デバイスおよび子デバイスとして階層的に編成された１つまたは複数のデバイスを含み、前記コンポーネントは、
    １つまたは複数の子デバイスからのアイドル要求を前記コントローラによって受け取るためのインターフェースコンポーネントと、
    前記子デバイスそれぞれからアイドル要求を受け取った後に前記ツリー中のすべてのデバイスを前記コントローラによってサスペンドするためのコントローラコンポーネントと
    を含むことを特徴とするコンピュータ可読媒体。
44. 前記コントローラは、前記コントローラ、前記デバイスのいずれか、またはその両方によるアクティビティに応答して、前記ツリー中のデバイスをウェイクすることを特徴とする請求項４３に記載のコンピュータ可読媒体。
45. 前記子デバイスは、ヒューマンインターフェースデバイス（ＨＩＤ）であることを特徴とする請求項４３に記載のコンピュータ可読媒体。
46. 前記子デバイスはコンピュータに内蔵されたデバイスであることを特徴とする請求項４３に記載のコンピュータ可読媒体。
47. 前記親デバイスと子デバイスはユニバーサルシリアルバスを介して接続されることを特徴とする請求項４３に記載のコンピュータ可読媒体。
48. アイドル要求を表すデータ構造が格納されたコンピュータ可読媒体であって、前記データ構造は、
    コールバック関数を表すルーチン属性を格納する第１のフィールドと、
    コールバックコンテクストを表すコンテクスト属性を格納する第２のフィールドと
    を含み、
    第１のデバイスは、前記第１のデバイスがサスペンド可能な状態になると前記データ構造を介して第２のデバイスにアイドル要求を送信し、前記第１のデバイスが前記アイドル要求を送信するのに応答して前記コールバック関数が実行されて前記第１のデバイスをサスペンドし、前記コールバックコンテクストは、前記コールバック関数を実行するための環境を提供することを特徴とするコンピュータ可読媒体。
49. 前記第１のデバイスは、ツリー構造に編成された１つまたは複数の子ノードを有し、前記第１のデバイスはアクティブ状態とアイドル状態とを有し、前記第１のデバイスは、前記第１のデバイスの前記１つまたは複数の子ノードそれぞれがサスペンド可能な状態になるとサスペンド可能になることを特徴とする請求項４８に記載のコンピュータ可読媒体。
50. 前記第１のデバイスと前記第２のデバイスはユニバーサルシリアルバスを介して接続されることを特徴とする請求項４８に記載のコンピュータ可読媒体。

Images