JP6245056B2 - 情報処理装置、電源制御プログラム及びｕｓｂ機器 - Google Patents

Description

本発明は、情報処理装置、電源制御プログラム及びＵＳＢ機器に関する。

機器が消費するエネルギーを低減させる、いわゆる省エネのための電源制御方法が提案されている（例えば、特許文献１及び特許文献２参照）。マウスやキーボード等のＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）機器には省エネ状態から復旧するためのリモートウェイクアップと呼ぶ機能がある。リモートウェイクアップとは、例えばサスペンド状態にあるＵＳＢ機器が操作者から操作を受けたときに、ＵＳＢ機器に接続されたＵＳＢホスト機器に対して操作のあったことを通知する（具体的にはリジューム信号を発行する）機能である。またリモートウェイクアップがイネーブルされているときのＵＳＢ機器のサスペンド状態では、ＵＳＢ機器（以下、「デバイス」ともいう。）は電源がオフのときに近い消費電力状態（省エネ状態）となる。言い換えると、リモートウェイクアップの機能は、デバイスが省エネ状態から復帰したことを通知するための機能となっている。

サスペンド状態にあるデバイスがサスペンド状態から復帰する方法としては、以下の二つの方法がある。一つは、リモートウェイクアップのイネーブルの指示が事前にＵＳＢホスト機器側からなされ、デバイスの操作者の操作をＵＳＢ機器自らが検出して、それをＵＳＢホスト機器に通知して復帰する方法である。もう一つは、リモートウェイクアップのイネーブルの指示が事前にＵＳＢホスト機器側から無く、ＵＳＢホスト機器側からの指示によって復帰する方法である。

リモートウェイクアップの使用には二つの方法がある。一つは、ＵＳＢホスト機器は稼動状態（運用状態）Ｓ０にあるが、デバイスに一定期間操作が無い場合に省エネのためにデバイスをサスペンド状態(以下、「セレクティブサスペンド」ともいう)としたときのサスペンド状態から復帰する場合である。もう一つは、サスペンド状態(以下、「システムサスペンド」ともいう)のＳ３からＵＳＢホスト機器を復帰させる場合である。Ｓ０では、ＵＳＢホスト機器のＣＰＵには電力が供給されているが、Ｓ３では、ＵＳＢホスト機器のＣＰＵには電力が供給されていない。

しかしながら、デバイスにとってはこれら二つのリモートウェイクアップに区別は無く、どちらもリモートウェイクアップのイネーブルされた状態になる。デバイスにとって上記二つのリモートウェイクアップの動作に区別が無いことでＵＳＢホスト機器側に不具合が生じる場合がある。例えば、ＵＳＢホスト機器がデバイスに対してリモートウェイクアップのイネーブルを指示し、ＵＳＢバスをアイドルとした後、即刻リジューム信号が発行される場合に生じることがある。

デバイスがいつリジューム信号を発行するかは操作者の操作によって決まる。よって、デバイスに対してリモートウェイクアップがイネーブルされ、ＵＳＢバスがアイドルとなった後、リジューム信号がいつ発行されるかを特定することは困難である。

一方、リジューム信号を受けるＵＳＢホスト機器側としては、セレクティブサスペンド状態でリジュームが通知された場合には、ＵＳＢホスト機器は稼働状態Ｓ０にあるため、ＵＳＢホスト機器側で動作するソフトウェアを使用して対応することができる。例えば、ＵＳＢホスト機器はソフトウェアを使用してリジューム信号の通知による割り込み入力をマスクする（所定期間無効化する）などのリジューム信号に対する制御が可能で、リジューム信号の入力タイミングによる不具合は生じない。

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

しかしながら、ＵＳＢホスト機器がスタンバイ状態であるＳ３のためにリモートウェイクアップがイネーブルされ、Ｓ３への移行中にリジューム信号が通知されると、ドライバスタックの動作が部分的に停止された状態にあるため、ＵＳＢホスト機器が正常にリジューム信号を制御できない可能性がある。その結果、リジューム信号の通知が中途半端にＵＳＢホスト機器に受け取られた状態となって不具合が生じることがある。

そこで、一側面では、リジューム信号の発行を遅らせることが可能な、情報処理装置、電源制御プログラム及びＵＳＢ機器を提供することを目的とする。

一つの案では、
スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器と通信可能な情報処理装置であって、
前記スリープモードへの移行時に、前記リジューム信号の発行を遅らせるための時間であって前記情報処理装置の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加し、所定のタイミングに発行するリクエスト発行部と、
前記遅れ時間の情報が付加されたリクエストを前記ＵＳＢ機器に送信する送信部と、
を有する情報処理装置が提供される。

一態様によれば、リジューム信号の発行を遅らせることで、リジューム信号の発行タイミングによる不具合を回避できる。

一実施形態にかかるＵＳＢ機器側コントローラのハードウェア構成の一例を示す図。 一実施形態にかかるＰＣのハードウェア構成の一例を示す図。 一実施形態にかかるＵＳＢ機器のハードウェア構成の一例を示す図。 リジューム信号の発行タイミングの一例を説明するための図。 一実施形態にかかるＵＳＢ機器及びＰＣの機能構成の一例を示す図。 Ｓ３移行時のサスペンド及びリジュームのバス状態とホスト状態を示す図。 セレクティブサスペンドのバス状態とホスト状態を示す図。 一実施形態にかかるリクエストの拡張によりアサートタイミングを指定する例。 一実施形態にかかるリクエストの拡張によりアサートタイミングを指定する例。 一実施形態にかかるリクエスト発行タイミングによりアサートタイミングを指定する例。 一実施形態にかかるリクエスト発行回数でアサートタイミングを指定する例。 一実施形態にかかる初期化処理を実行するためのフローチャートの一例。 一実施形態にかかる割り込みハンドラ（ＭＣＵ）のフローチャートの一例。 サスペンド移行のタイムチャートの一例。 一実施形態にかかるサスペンド移行のタイムチャートの一例。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

（はじめに）
機器が消費するエネルギーを低減させる、いわゆる省エネのための電源制御方法が提案されている。ＣＰＵへの給電がオフとなるＳ２、Ｓ３、Ｓ４は、ＣＰＵへの給電がオンである稼働状態Ｓ０と比較すると電力を節約できる上に、起動中のプログラムなどを終了させることなく素早い復帰が可能となるといった利点がある。

ＣＰＵへの給電がオフとなるＳ２、Ｓ３、Ｓ４のうち、Ｓ２はＣＰＵの電力供給がオフとなるモード、Ｓ３はメモリ以外の電力供給がオフとなるモード（いわゆる、システムサスペンド）である。Ｓ４はメモリ内のデータをＨＤＤ(Hard Disk Drive)に保存し、すべての電力供給を停止するモード（いわゆる、ハイバーネーション）である。Ｓ２、Ｓ３、Ｓ４は、Ｗｉｎｄｏｗｓ（登録商標）のＯＳ搭載ＰＣの規格であるＡＣＰＩ(Advanced Power&Configuration Interface)によるシステムの省エネ状態の定義の一つである。以下では、ＣＰＵの電力供給がオフとなるＳ２、Ｓ３、Ｓ４を総称して「スリープモード」という。なお、Ｓ０は、すべての電力供給がオンされている運用状態（稼働状態）である。Ｓ１は、低消費電力状態であるが、ＣＰＵには電力が供給されている状態である。Ｓ５は、ＯＳをシャットダウンしてすべての電力供給を停止するモードである。

機器を省エネ状態にしたときの省エネ効果は、復帰時間と背反の関係にある。Ｓ４は、Ｓ３よりも電力を節約する効果は高いが、復帰時に保存したデータをＨＤＤから読み込むのに時間が掛かるため、Ｓ３よりも復帰までに時間がかかる。Ｓ３は、メインメモリの内容をそのままバックアップしておき、そのための電源だけをオン、それ以外の電源をオフして実現される状態であり、Ｓ４やＳ５に較べ、高速復帰と省エネ効果のバランスのとれた省エネ状態となっている。

ところで、ＵＳＢホスト機器（例えば、ＰＣ等）とＵＳＢ機器（例えば、マウス等）とがＵＳＢインタフェースを介して接続されている場合の電源制御の一例を挙げて説明する。Ｓ０（稼働状態）からＳ３（システムサスペンド）へ移行中にＵＳＢ機器からＵＳＢホスト機器にリジューム信号が通知されると、ドライバスタックの動作が部分的に停止された状態にあるため、ＵＳＢホスト機器はリジューム信号を正常に制御できないことがある。その結果、リジューム信号の通知が中途半端にＵＳＢホスト機器に受け取られた状態となって不具合が生じることがある。

この不具合は、再操作で救済されるものや、システムがハングし、ＵＳＢホスト機器の電源を再投入しなければならないもの等様々である。特にＵＳＢホスト機器の電源の再投入が必要になる不具合が生じると、Ｓ３状態で処理途中のデータが失われてしまう恐れがある。

これらの不具合に対する対処法として、Ｓ０からＳ３への移行が開始されてから一定期間の操作を控えるというような操作制限事項をマニュアルに記載することも考えられる。しかしながら、この種の操作制限事項を操作者に徹底させるには困難がある。

上記不具合を解消するために、Ｓ３への移行時には、ＵＳＢホスト機器がＳ３への移行を完了するまでＵＳＢ機器側でリジューム信号の発行を一律に遅らせることが考えられる。しかしながら、リモートウェイクアップのリジューム信号の反応を一律に遅らせてしまうことは、システム全体のスループットを低下させてしまうことになるため望ましくない。従って、リモートウェイクアップのリジューム信号の発行を、一律ではなく、ＵＳＢホスト機器の状態に応じて遅らせることが望ましい。

しかしながら、現状のＵＳＢの仕様では、リジューム信号の発行タイミングを遅らせる仕組みは備えていない。そこで、以下の本発明にかかる実施形態では、ＵＳＢ機器側でリジューム信号のタイミングを、ＵＳＢホスト機器毎に機器の状態に応じて区別する方法を提供する。

［ＵＳＢ機器側コントローラのハードウェア構成例］
まず、本発明の一実施形態に係るＵＳＢ機器側のコントローラ１について、図１を参照しながら説明する。図１は、一実施形態にかかるＵＳＢ機器側のコントローラ１のハードウェア構成の一例を示す。

ＵＳＢ機器側のコントローラ１は、ＭＣＵ（Micro Controller Unit）９、ＲＯＭ（Read Only Memory）１０、ＲＡＭ（Random Access Memory）１１及ＳＲＡＭ（Static Random Access Memory）１２を有し、それぞれがバスで相互に接続されている。

コントローラ１はまた、Ｐ３．０〜Ｐ３．４の５ビットのＧＰＩＯ（Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）、ＲＴＳ／ＣＴＳ／ＤＴＲ／ＤＳＲ他の信号の、シリアルの入出力インタフェース信号線を備えている。それらのインタフェースはプリンタやモデムなど、様々なメカや電気回路（省略）と内部的に接続され、ＵＳＢ機器２（図３を参照）を構成する。

ＭＣＵ９は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と同様の機能を有し、ＵＳＢ機器２における主な処理回路である。ＵＳＢ機器２は、ＭＣＵ９を中心として、ＵＳＢのデバイス側インタフェースを備えた構成となっている。ＭＣＵ９には、割り込みコントローラ、ＩＲＣが接続され、チップ内で発生する様々な割り込みをＭＣＵ９に通知する。ＭＣＵ９は、ＩＲＣからの入力の他、外部割り込み、タイマ割り込みを受ける。

ＲＯＭ１０は、不揮発性メモリであり、ＭＣＵ９によって実行されるプログラムを格納する。ＲＯＭ１０が格納するプログラムには、「ブートコード」と呼ばれる、ＰＣのＢＩＯＳに相当する機能を受け持つプログラムが含まれる。

ＲＡＭ１１は、揮発性メモリであり、ＲＡＭ１１にはＲＯＭ１０のブートコードによってチップ外付ＥＥＰＲＯＭに格納したファームウェアがロードされ、運用時には高速なＲＯＭとして働くプログラムメモリである。ＲＡＭ１１はＲＯＭ１０の代替としてＥＥＰＲＯＭのファームウェアのロードの後はリードオンリーになる。

ＳＲＡＭ１２は、ファームウェアが必要に応じて随時使用する読み書き可能なメモリで、汎用メモリの役割を担う。

さらに、コントローラ１は、タイマー１５、Ｐｏｒｔ３のレジスタ１６、Ｉ^２Ｃコントローラ１７、ＤＭＡ（ＤＭＡ−１、ＤＭＡ−３）１８、ＵＡＲＴ（ＵＡＲＴ−１）１９等のＵＳＢ機器２の外部回路と接続されている。

タイマー１５は、所定の時間を計時する。Ｉ^２Ｃコントローラ１７は、チップ外付ＥＥＰＲＯＭと接続され、ＭＣＵ９及びＥＥＰＲＯＭ間のインタフェースとして機能する。ＭＣＵ９は、Ｉ^２Ｃコントローラ１７を通じて、ＥＥＰＲＯＭに格納されたファームウェアをＲＡＭ１１にロードし、またファームウェアの更新の際には、ＵＳＢホスト機器（後述されるＰＣ）からのデータをＥＥＰＲＯＭに書き込む。チップ外付ＥＥＰＲＯＭはフラッシュＲＯＭであり、ＭＣＵ９の直接動作を想定したものでは無く、ＰＣのファイルに相当する書き込み可能不揮発性メモリである。

Ｐｏｒｔ３のレジスタ１６、ＵＡＲＴ（ＵＡＲＴ−１）１９は、メカ部分とのインタフェースを担う。Ｐｏｒｔ３のレジスタ１６、ＵＡＲＴ（ＵＡＲＴ−１）１９は、ＭＣＵ９からの指示を受け、ＧＰＩＯの信号線、ＵＡＲＴ（ＵＡＲＴ−１）１９のシリアルインタフェースの信号線を通じてＵＳＢ機器２に内蔵するメカや電気回路とのインタフェースを取り持つ。

ＵＳＢシルアルインタフェースエンジン２０は、ＵＡＲＴ(Universal Asynchronous Receiver Transmitter)に相当し、ＵＳＢホスト機器とのインタフェースである。ＵＳＢ機器２は、ＵＳＢシルアルインタフェースエンジン２０をインタフェースとしてＵＳＢバスを介してＵＳＢホスト機器と接続される。

ＵＳＢバスには、信号線が２本（Ｄ＋、Ｄ−）ある。Ｄ＋、Ｄ−でやりとりされる信号は、パルス信号であり、互いに極性が背反の信号である。システムサスペンドの状態（つまり、Ｓ３）では、例えばＤ＋がＨｉｇｈ、Ｄ−がＬｏｗになる。

ＤＭＡ（ＤＭＡ−１、ＤＭＡ−３）１８はＤＭＡコントローラである。ＤＭＡ−１はＵＳＢシルアルインタフェースエンジン２０及びＳＲＡＭ１２間のＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）を行うのに使われる。ＤＭＡ−３はＳＲＡＭ１２及びＵＡＲＴ１９間のＤＭＡを行うのに使われる。ＤＭＡは、メモリとメモリ、又はメモリとＩ／Ｏデバイス間の直接のデータ転送に使われる。ＵＡＲＴ１９は、調歩同期方式によるシリアル信号からパラレル信号への変換、その逆方向の変換を行う。

［ＰＣのハードウェア構成例］
次に、本発明の一実施形態にかかる図３のＰＣ３のハードウェア構成について、図２を参照しながら説明する。図２は、一実施形態にかかるＰＣ３のハードウェア構成の一例を示す。

ＰＣ３は、ＵＳＢインタフェースを介してＵＳＢ機器２と通信可能な情報処理装置の一例である。つまり、本実施形態にかかる情報処理装置は、ＵＳＢインタフェースを介してＵＳＢ機器と通信可能な機器であれば、ＰＣ３の形態に限らず、例えば、タブレット型の機器等であってもよい。

本実施形態にかかるＰＣ３は、ＣＰＵ（Central Processing Unit）１０１、ＭａｉｎＭｅｍｏｒｙ１０２、ＨＤＤ（Hard Disk Drive）１０３及びＳｌｉｍ−ＯＤＤ（Optical Disk Drive）１０４を有している。また、ＰＣ３は、ＢＩＯＳ（Basic Input/Output System）１０９、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）１１０及びＤＶＩ（Digital Visual Interface）１１１のインタフェースコネクタを有している。さらに、ＰＣ３は、ＵＳＢインタフェースのＵＳＢＣＮ１２、ＵＳＢＣＮ１１３のコネクタ及びＰｏｗｅｒＳｕｐｐｌｙＵｎｉｔ１１４を有している。

ＣＰＵ１０１は、ＰＣ３における主な処理回路である。ＭａｉｎＭａｍｏｒｙ１０２は、ＯＳやアプリケーションプログラムを格納し実行するメインメモリである。ＨＤＤ１０３及びＳｌｉｍ−ＯＤＤ１０４は、メインメモリにロードされるＯＳやアプリケーションプログラムを格納する補助記憶装置である。ＳｕｐｅｒＩＯ１０８は入出力インターフェイス回路、ＢＩＯＳ１０９はシステム立ち上げ時点の初期化処理、ＯＳのロードを行うファームウェアの格納された不揮発性メモリである。

ＨＤＭＩ１１０は、デジタル映像や音声を伝送させるためのインタフェースである。ＤＶＩ１１１は、例えば、モニタと接続されてもよく、ＰＣ３で保存された画像データ等をモニタに出力するインタフェースである。ＵＳＢＣＮ１１２、１１３は、ＰＣ３が有するＵＳＢコネクタに接続されたＵＳＢ機器２の制御回路である。ＵＳＢＣＮ１１２、１１３は、ＵＳＢ機器２をＰＣ３に接続するためのＵＳＢインタフェースである。ＰｏｗｅｒＳｕｐｐｌｙＵｎｉｔ１１４は、ＣＰＵ１０１等の各部に電力を供給する電源である。

［ＵＳＢ機器の構成例］
ＵＳＢ機器２の構成例を図３に示す。図３では、ＵＳＢ機器２の一例としてＵＳＢ電気スタンドを示している。しかしながら、ＵＳＢ機器２は、これに限らず、マウスやキーボード、その他の機器であってもよい。

ＵＳＢ機器２は、図１に示したコントローラ１、スイッチＳＷ３３及びランプＬＰ３４を有する。ＵＳＢ機器２には、コントローラ１のチップが内蔵され、コントローラ１による制御に基づき、ＬＰ３４のオン及びオフの制御が行われる。またＵＳＢ機器２のＳＷ３３は、消灯されたＬＰ３４を点灯する際、ユーザーがオンするために使われる。

ＬＰ３４には、コントローラ１のチップのＧＰＩＯ、Ｐ３．０の端子（図１を参照）に接続され、またＳＷ３３は、コントローラ１のチップのＷＡＫＥＵＰ＃（ウェイクアップ）の端子に接続されている。

ＵＳＢ機器２は、ホスト機器（ＰＣ３）からのサスペンドのＵＳＢバスの状態（３ｍｓ以上のＵＳＢバスにパケットの何も出力されないバスアイドル状態）と連動してサスペンド状態に移行する。またＵＳＢ機器２は、ＵＳＢバスからのリジューム信号によるリジュームの指示と連動してサスペンド状態から復帰する。

コントローラ１には、リモートウェイクアップの機能がある。リモートウェイクアップの指示はコントローラ１に対して、図１に示すＷＡＫＥＵＰ＃の信号線に与えられるリジューム信号によって実現される。リモートウェイクアップの指示を受けたコントローラ１は、リジューム信号をＵＳＢインタフェースに出力し、ＰＣ３に通知する。

［リジューム信号の発行タイミング］
次に、図４を参照しながら、図３に示したＵＳＢ機器２から発行されるリジューム信号（図１に示すＷＡＫＥＵＰ＃の信号線に与えられるリジューム信号）の発行タイミングについて説明する。

ＵＳＢホスト機器側であるＰＣ３側のアプリケーションプログラムが起動されることでＵＳＢ機器２に対してＵＳＢインタフェース（ＵＳＢバス）を通じてＬＰ３４を点灯するリクエストが発せられる。これに応じて、ＵＳＢ機器２は自動的にＬＰ３４を点灯する(図４の（１）参照)。

その後一定期間を経て、ＵＳＢ機器２は、ＰＣ３からのサスペンドの指示（つまり、ＵＳＢバスの３ｍｓ以上のアイドル状態を検出）を受け、ＬＰ３４を消灯する（図４の（３）参照）。ＬＰ３４の消灯（３）は、ＵＳＢバスのサスペンド状態（Ｊ状態）で指示されているため、コントローラ１はサスペンド状態になる。

また、ＰＣ３は、ＬＰ３４の消灯（３）の指示に先立ってＵＳＢ機器２からのリジューム信号を受けるために、リジューム信号の発行を許可する、リモートウェイクアップの指示を行う（図４の（２）参照）。

ＬＰ３４の消灯後、操作者は、再度ＬＰ３４を点灯したいときにはＳＷ３３を押下（オン）して再点灯を要求する。ＳＷ３３のオンは、リジューム信号としてコントローラ１のＷＡＫＥＵＰ＃の信号線に与えられる。コントローラ１は、この信号を受けてサスペンド状態から復帰し、ＵＳＢインタフェース（ＵＳＢバス）にリジューム信号を発行し（図４の（４）参照）、再点灯を要求する。これにより、ＵＳＢバスはアイドル状態から復帰し（Ｋ状態）、要求を受けたＰＣ３は、ＬＰ３４を点灯するリクエストを発行し、ＬＰ３４の点灯を指示する。ＵＳＢ機器２は、このリクエストを受け、ＬＰ３４を再点灯する（図４の（５）参照）。

この一連のシーケンスで不具合が生じるおそれがあるのは、図４の（４）にて示されるＵＳＢ機器２が出力するリジューム信号の発行タイミングである。ＵＳＢ機器２はＰＣ３からリモートウェイクアップの指示（２）を受けた後、ＰＣ３側がリジューム信号を正しく受け取られる好適なタイミングが判らない。このため、ＵＳＢ機器２はＰＣ３からリモートウェイクアップを指示するリクエスト（２）を受けた直後にＳＷ３３がオンされた場合には、コントローラ１は、図４の点線の矢印で示したタイミングで、すぐさまリジューム信号（４）'を発行してしまう。これにより、ＰＣ３側がそのジューム信号（４）'を受け取れないという不具合が生じる場合がある。

これに対して、後述されるように、本実施形態では、サスペンドの後、ＵＳＢホスト機器であるＰＣ３にとって適正なリジューム信号の待ち時間（以下では、「遅れ時間」ともいう）をＰＣ３側から指示し、この指示を受けたＵＳＢ機器２は、指定された遅れ時間経過後リジューム信号を発行する。これにより、ＰＣ３側は正しくリジューム信号を受け取ることができ、ＰＣ３側のリジューム動作を不具合なく行うことが出来る。

［ＵＳＢ機器及びＰＣの機能構成］
次に、本実施形態に係るＵＳＢ機器２及びＰＣ３の機能構成について、図５を参照しながら説明する。図５は、一実施形態に係るＵＳＢ機器２及びＰＣ３の機能構成の一例を示す。なお、図５は、ＵＳＢ機器制御部分に着目した機能構成を示し、その物理構成については、図２（ＰＣ３）及び図３（ＵＳＢ機器２）に示されている。

ＵＳＢ機器２は、受信部２０１、送信部２０２、スイッチ（ＳＷ）３３及びランプ（ＬＰ）３４を有する。受信部２０１は、リモートウェイクアップを指示するリクエストをＰＣ３から受信する。そのリクエストには、遅れ時間の情報が付加されている。遅れ時間は、リジューム信号の発行を遅らせるための時間であってＵＳＢ機器２と通信するＰＣ３の状態に応じた時間である。

送信部２０２は、ＰＣ３からのリクエストに応じて遅れ時間分遅らせてリジューム信号をＰＣ３に送信する。

スイッチ（ＳＷ）３３は、操作者によりオン及びオフに設定される。スイッチ３３がオンに設定されるとＬＰ３４は点灯し、オフに設定されるとＬＰ３４は消灯する。

ＰＣ３は、電力供給部３０１、記憶部３０２、受信部３０３、リクエスト発行部３０４及び送信部３０６を有する。電力供給部３０１は、スリープモードへ移行した場合、給電を省エネモードに制御する。例えば、Ｓ２へ移行した場合、電力供給部３０１は、図２のＣＰＵ１０１の電力供給をオフに制御する。例えば、Ｓ３へ移行した場合、電力供給部３０１は、メモリ以外の電力供給をオフに制御する。例えば、Ｓ４へ移行した場合、メモリ内のデータを図２のＨＤＤ１０３に保存した後、電力供給部３０１はすべての電力供給を停止する
記憶部３０２は、メモリ内のデータを保存するＨＤＤ１０３等の記憶領域である。受信部３０３は、ＵＳＢ機器２により発行されたリジューム信号やその他の情報を受信する。

リクエスト発行部３０４は、スリープモードへの移行時に、リジューム信号の発行を遅らせるための時間であってＰＣ３の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加し、所定のタイミングに発行する。例えば、ＰＣ３が稼働モードＳ０からスリープモードＳ２、Ｓ３、Ｓ４のいずれかへ移行する場合、リクエスト発行部３０４は、ＰＣ３の状態に応じて遅れ時間を特定する。例えば、記憶部３０２には、ＰＣ３の状態がＳ０からＳ２への移行のときの遅れ時間Ｔ２、Ｓ３への移行のときの遅れ時間Ｔ３、Ｓ４への移行のときの遅れ時間Ｔ４が記憶されているとする。この場合、リクエスト発行部３０４は、記憶部３０２に記憶された遅れ時間Ｔ２，Ｔ３，Ｔ４からＰＣ３の状態に応じた遅れ時間を選択する。遅れ時間Ｔ２には、Ｓ０からＳ２への移行時間よりもαだけ長い時間が設定される。遅れ時間Ｔ３には、Ｓ０からＳ３への移行時間よりもαだけ長い時間が設定される。遅れ時間Ｔ４には、Ｓ０からＳ４への移行時間よりもαだけ長い時間が設定される。αは、リモートウェイクアップを指示するリクエストの発行タイミングに応じて設定される。

遅れ時間は、省エネ効果と背反の関係にある、遅れ時間は、モード移行の所要時間に応分な時間を指定する。遅れ時間Ｔ２は、モード移行は短時間であるが省エネ効果は低いスリープモードＳ２の装置状態のときに設定される時間である。遅れ時間Ｔ４は、モード移行にデータセーブが必要であり時間が掛かるが省エネ効果は高いスリープモードＳ４の装置状態のときに設定される時間である。遅れ時間Ｔ３は、スリープモードＳ２、Ｓ４の中間のモード移行時間と省エネ効果を有するＳ３の装置状態のときに設定される時間である。よって、モード移行時間Ｓ２＜Ｓ３＜Ｓ４に比例してＴ２＜Ｔ３＜Ｔ４となる段階的な遅れ時間が設定されてもよい。

但し、リクエスト発行部３０４は、ＰＣ３の状態の全てに対して細かな遅れ時間を設定する制御に限らず、例えばＳ２及びＳ３の遅延時間は同じ値に設定し、Ｓ４の遅延時間はＳ２及びＳ３の遅延時間と異なる値に設定してもよい。リクエスト発行部３０４は、ＵＳＢインタフェースの仕様等を考慮して遅延時間を設定することもできる。

この結果、リジューム信号は、リモートウェイクアップを指示するリクエストに対して、そのリクエストに付加された遅れ時間だけ遅らせて発行される。なお、リジューム信号の発行を遅らせる必要がない場合には、遅延時間を「０」に設定してもよい。つまり、遅れ時間にはＰＣ３の状態に応じて０以上の値が設定され得る。また、遅れ時間は、リジューム信号の発行を遅らせるための時間であるが、遅れ時間が「０」に設定された場合、実質的にはリジューム信号の発行を遅らせる制御は行われない。

このようにして、リクエスト発行部３０４は、スリープモードへの移行時に、ＰＣ３の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加し、所定のタイミングに発行する。

リクエスト発行部３０４がリモートウェイクアップを指示するリクエストを発行するタイミングとしては、例えば、ＰＣ３がＵＳＢバスをアイドル状態とする直前が挙げられる。

送信部３０６は、発行されたリクエストをＵＳＢ機器２に送信する。

（Ｓ３移行時のＵＳＢバス状態）
次に、Ｓ３移行時のＵＳＢバス状態について説明する。図６は、Ｓ３移行時のサスペンド及びリジュームのバス状態とホスト状態を示すＰＣ３がＳ０からＳ３に移行するときの動作を示す。ＰＣ３（図６のホスト）は、ＵＳＢ機器２に対して「ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ」のリクエストを発行する。「ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ」のリクエストは、リモートウェイクアップのイネーブルを指示するリクエストである。リクエストを発行後、ＰＣ３は、ＵＳＢバスをアイドル（バスにパケットが何も出力されていない状態）とし、Ｓ３に移行する。

ＵＳＢ機器２は、バスの一定期間以上のアイドルによってサスペンドの指示を検出し、サスペンド状態になる。そしてサスペンド状態では、ＵＳＢ機器２は、ＵＳＢ機器２の操作（例えば、マウスボタンのクリックやＳＷのオンなど）を検出するとリジューム信号を発行し、ＰＣ３に通知する。

ここで、リジューム信号がアサート（発行）されるポイントが、図６の右側（１）に示す様に、ＰＣ３の状態が完全にＳ３に移行した後であれば、ＰＣ３はリジューム信号を受け、ＰＣ３自身もリジューム信号を、今度はＵＳＢ機器２に向けて折り返し発行する。そして、ＰＣ３は、Ｓ０の運用状態に戻り、「ＣｌｅａｒＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ」のリクエストを発行する。「ＣｌｅａｒＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ」のリクエストは、リモートウェイクアップをディセーブルを指示するリクエストである。

しかしながら、図６の左側（２）に示す様にＰＣ３がまだＳ３への移行過程にある状態でリジューム信号がアサート（発行）されると、不具合が生じることがある。

そこで、本実施形態では、リジューム信号の発行タイミングを、上記不具合の起こらない図６（Ａ）や（Ｂ）に示した「ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａ」、「ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂ」のリクエストに対応した位置へ意図的に遅らせる。これにより、上記移行期間中にＵＳＢ機器２がリジューム信号をアサートしないようにすることができる。なお、Ｓ０→Ｓ３、Ｓ３→Ｓ０の移行時の斜線は論理的、物理的な移行過程を概念的に示したもので、電源状態だけを示したものではない。

（セレクティブサスペンド移行時のＵＳＢバス状態）
次に、セレクティブサスペンド移行時のＵＳＢバス状態について説明する。図７は、リモートウェイクアップがセレクティブサスペンドのためにイネーブルされた状態を示す。このタイムチャートは、ＰＣ３の状態（ホスト状態）がＳ０を保持している以外は図６の図と外面的に変わることは無い。つまり、ＰＣ３は、ＵＳＢ機器２に対してはＳ３のときと同様にリモートウェイクアップのイネーブルを指示するＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐのリクエストを発行する。また、ＰＣ３は、リモートウェイクアップのディセーブルを指示するＣｌｅａｒＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐのリクエストを発行する。

セレクティブサスペンドとは、ＳＯ状態でＵＳＢホスト機器に接続されたＵＳＢ機器毎に個別にサスペンドとして省エネを図るホスト側の仕組みを指す。

現実にＵＳＢ機器２が省エネ状態となるのは、ＵＳＢバスの３ｍｓ以上のアイドルを検出してからであるが、図６、図７では、このタイミングの詳細を省略している。またＵＳＢバスのアイドル状態とは、ＵＳＢバスにパケットが全く出力されていない状態を指すが、現実のＵＳＢバス状態はＵＳＢ機器のスピードによって異なり、図７を含め、本実施形態のＵＳＢバス状態はＵＳＢの、フルスピードのバス状態で示している。

図８〜図１１は、本実施形態の一例であり、ＰＣ３がリクエストによってリジューム信号のアサートタイミングを通知し、ＵＳＢ機器２がそれに応じてリジューム信号を遅れ時間だけ遅らせて発行する様子を示す。なお、図８〜図１１に示される「遅れ時間」は、ＵＳＢ機器２がリジューム信号を発行するまでに確保される「時間」の一例である。

(第一の例)
図８の例では、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａ、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂのリクエストの違いによるリジューム信号のアサート（発行）タイミングの違いを示す。

一例としては、リクエスト発行部３０４は、Ｓ２への移行を想定して、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａのリクエストを発行し、Ｓ３への移行を想定して、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂのリクエストを発行する場合が挙げられる。

その際、リクエスト発行部３０４は、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａのリクエストに遅れ時間Ｔ２を付加し、例えば、ＵＳＢバスがアイドル状態となる直前にそのリクエストを発行する。送信部３０６は、発行されたＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿ＡのリクエストをＵＳＢ機器２に送信する。

ＵＳＢ機器２は、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａのリクエストに応じて、リジューム信号の発行タイミングをリクエストに付加された遅れ時間Ｔ２だけ遅らせてリジューム信号を発行する。これにより、Ｓ２への移行期間後にリジューム信号を発行することができる。また、次に説明するＳ３への移行時のリジューム信号の発行タイミングよりも遅れの少ないタイミングでリジューム信号を発行することができる。

また、リクエスト発行部３０４は、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂのリクエストに、Ｓ３への移行を想定した遅れ時間Ｔ３を付加する。ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂのリクエストの発行タイミングは、例えば、ＵＳＢバスがアイドル状態となる直前である。送信部３０６は、発行されたＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿ＢのリクエストをＵＳＢ機器２に送信する。

ＵＳＢ機器２は、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂのリクエストに応じて、リジューム信号の発行タイミングをリクエストに付加された遅れ時間Ｔ３だけ遅らせたリジューム信号を発行する。Ｔ２＜Ｔ３であるから、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａのリクエストよりも移行時間の長いＳ３への移行を想定したタイミングでリジューム信号がアサートされる。これにより、Ｓ３への移行期間後にリジューム信号をアサートすることができる。

以上に説明したように、リクエスト発行部３０４は、ＰＣ３の状態に応じて_ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａ、Ｂのリクエストを選択して使用する。これにより、ＰＣ３がＵＳＢ機器２に対してリモートウェイクアップのイネーブルを指示（リクエスト）し、ＵＳＢバスをアイドルとした後、即刻リジューム信号が発行される場合に生じるＳ０→Ｓ２やＳ０→Ｓ３の移行期間の不具合を回避出来る。

ここで、Ｓ２及びＳ３への移行時にＵＳＢ機器２側でリジューム信号の発行を一律に遅らせることが考えられる。しかしながら、リモートウェイクアップの指示のリクエストに対するリジューム信号の発行を一律に遅らせてしまうことは、システム全体のスループットを低下させてしまうことになるため望ましくない。

これに対して、本実施形態では、リモートウェイクアップのリジューム信号の発行を、一律ではなく、ＰＣ３の状態に応じた時間だけ遅らせることができる。これにより、システム全体のスループットの低下を防止できる。

なお、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａ，Ｂのリクエストは、例えば、ＰＣ３の状態がＳ０→Ｓ２、Ｓ０→Ｓ３だけでなくＳ０→Ｓ４へ移行する場合等、移行時間に長短がある場合に用いることが好適である。

(第二の例)
図９の例は、リクエストのパラメータによりアサートタイミングを指定する本実施形態の他の例を示す。この例ではＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ（Ｘ）のリクエストのパラメータとして、Ｘ＝Ａ〜（Ａ〜：前述のタイミングを示す値）のいずれかを設定することで、遅れ時間を指定可能である。これにより、同じリクエストによってリジューム信号のアサートのタイミングを可変に指定できる。

第一の例と第二の例の違いは、リモートウェイクアップのイネーブルを指示するＡ、Ｂのリクエストをセレクタで指定して遅延時間を設定するか（第一の例の場合）、セレクタ以外のパラメータの値で指定して遅延時間を設定するか（第二の例の場合）の点である。

(第三の例)
次に、リクエストの発行タイミングで、リジューム信号のアサートのタイミングを指定する方法について、図１０を参照しながら説明する。図１０は、リクエストの発行タイミングで、リジューム信号のアサートのタイミングを指定する方法の一例を示す。

この方法は、ＵＳＢ機器２に対するリジューム信号のアサートのタイミングの指定をＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐなどのリクエストの発行タイミングによって行う。図１０の例では、ＵＳＢバスのアイドル状態に対して早めのリクエストの発行では、大きな遅れ時間を確保したＳ３のリモートウェイクアップの指定になる。ＵＳＢバスのアイドル状態に対して遅めのリクエストの発行では、セレクティブサスペンドのための、遅れ時間の少ない、リモートウェイクアップの指定となる。

この方法によれば、ＰＣ３側は特別なリクエストを新たに定義しなくとも実施が可能で、リジューム信号の遅れを設定出来ないＵＳＢ機器２に対しても互換が維持出来る。この方法を実施するに当たって本実施形態に限定はなく、例えば、リクエストを拡張ないしは増設するかどうか、またリクエストの発行位置と遅れの時間関係について特定の条件に限定されることはない。

(第四の例)
第四の例の方法では、第三の例の方法と同様に、リクエストを新たに定義しなくとも実施出来る。この方法では、一回のリクエストの発行に対してリジューム信号のアサートの遅れの時間的粒度を与え、例えば一回のリクエストの発行当たり２５０ｍｓの遅れ時間を確保するものと定義する。図１１の例では３回、リクエストを発行しているため、２５０ｍｓ＋２５０ｍｓ＋２５０ｍｓの、７５０ｍｓの遅れ時間を確保する例を示している。

リクエストが一つである場合と、リクエストが二つ以上である場合とではリクエストの意味付け（定義）を変えてもよい。また、リクエストの個数と指定時間は図の様に均等とする以外に指数的な意味付とする（リクエストの個数がＸ^ｎのｎを指定する）など、リクエストの個数と遅れ時間の関係は１：１で無くとも良い。本実施形態はそれら実装の条件に特定されない。

(本実施形態に好適なＵＳＢ機器の動作)
次に、本実施形態のＵＳＢ機器２の動作について、図１２を参照しながら説明する。図１２は、ＵＳＢ機器２が行う初期化シーケンスのフローチャートを示す。図１２のフローチャートは、ＵＳＢ機器２がＰＣ３にアタッチされ、ＵＳＢ機器２の電源がオン状態になったときにコントローラ１により実行される。

コントローラ１のＲＯＭ１０には、ブートコード（ＰＣ３のＢＩＯＳに相当する機能を受け持つプログラム）が内蔵されている。ブートコードは、コントローラ１内のレジスタの初期化の後、ＰＣ３からの初期化関連（ＳＥＴＵＰトークンパケットで始まるコントロール転送のパケット）のパケットを待ち、それに応答する処理を行う（ステップＳ１０１）。

ブートコードがＰＣ３からの初期化関連のリクエストに応答するためには、ＵＳＢ機器２のベンダＩＤ、プロダクトＩＤの他のディスクリプタ情報が必要である。それらディスクリプタ情報は事前にＩ^２Ｃコントローラ１７に接続された外部ＥＥＰＲＯＭから取得される（ステップＳ１００）。

ブートコードは、ＰＣ３からゲットディスクリプタ（ＧｅｔＤｅｓｃ）のリクエストを受けると（ステップＳ１０３）、ＥＥＰＲＯＭからＲＡＭ１１にファームウェアのダウンロードを行う（ステップＳ１０４）。ダウンロードが終了すると、ＲＡＭのファームウェアが実行待機状態となる。（ステップＳ１０５）。

ＰＣ３からのパケット入力の通知はＩＳＲを経由して入力される割り込みによってＭＣＵ９に通知される。また、ＲＯＭのブートコードは制御がＲＡＭに渡った以降もＭＣＵ９のメモリ上にマップされる。このため、ＭＣＵ９の制御がＲＡＭのファームウェアに渡された後も、ＭＣＵ９は、パケット処理の割り込みハンドラとして機能し、以降のセットアドレス（ＳｅｔＡｄｄ）、セットコンフィグレーション（ＳｅｔＣｏｎｆｉｇ）のリクエストの処理を行う。

初期化時点ではＵＳＢのコントロール転送と呼ぶ転送モードが使われ、それはＳＥＴＵＰのパケットで始まる一連のパケットになっている。コントローラ１のＲＯＭ１０には、ＵＳＢ機器２が共通に受けるセットアップ（SETUP）のリクエストの応答処理を含み、コントローラ１は前述のＵＳＢ機器２がアタッチされた時点で事前に取得したディスクリプタ情報を使ってそれらリクエストの応答処理を行う。図１２のステップＳ１０３の「ＧｅｔＤｅｓｃ」に始まるパケット判断と応答処理のリンクは、ＳＥＵＰの割り込み（ステップＳ１０２）に応じた、ＲＯＭの割り込みハンドラとして実現される。

初期化時点では、「ＧｅｔＤｅｓｃ」パケット判断（ステップＳ１０３）とその応答処理（ステップＳ１０７）が実行される。また、「ＳｅｔＡｄｄ」パケット判断（ステップＳ１０８）とその応答処理（ステップＳ１０９）が実行される。また、「ＳｅｔＣｏｎｆｉｇ」パケット判断（ステップＳ１１０）とその応答処理（ステップＳ１１１）が実行される。

ＳＥＴＵＰのパケットに始まるコントロール転送は全てのＵＳＢ機器共通の、初期化用のもの以外にも、実使用時に随時要求される、またＵＳＢ機器固有の制御の目的で設けられたリクエストのものがある。それらはＲＯＭのブートコードによって認識されないパケットとして、図１２のステップＳ１１２に示すＵＳＢ機器固有のリクエスト処理としてＲＯによって判断される。リクエスト処理は、Ｓ１０４においてＲＯＭからＲＡＭにダウンロードされたファームウェアに対して配信される。

本実施形態にかかるリジューム信号の発行を遅らせるための遅れ時間の設定は、コントロール転送のリクエストの拡張によって可能である。この新たなリクエストは、標準のリクエストとしてＲＯＭのブートコードによって処理することも、またＲＡＭのファームウェアによって処理することも可能である。

図１３に本実施形態にかかるリジューム信号の発行を遅らせるための遅れ時間の設定の一例を示す。図中の「ＳｅｔＦｅａ／Ｘ」は、第一の例のＵＳＢのリクエストを拡張する「ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｘ」の＿Ｘによりタイミングを区別するリクエストを示す。ここでの「＿Ｘ」は、第二の方法の（Ｘ）の意味では無く、第一の例の「＿Ａ」や「＿Ｂ」で示すＡ、Ｂと同じ意味を持つ。しかし、発行タイミングを区別するリクエストは、この二種類に限らず、装置の状態や装置の利用状況や装置の機種の違いに応じて複数のリクエストの定義を行うことが可能であり、リクエストの数は限定されない。

本実施形態のこれらリクエストは、割り込みハンドラにその判定と処理が追加され、図１３では、ＭＣＵ９によって拡張されたリクエストの種類に基づきリジューム信号の発行を遅らせるための遅れ時間が認識され、遅れ時間経過後にリジューム信号が発行される。ＳＥＵＰの割り込みハンドラ（ＭＣＵ９）によって「ＳｅｔＦｅａ／Ｘ」のリクエストが認識されると（ステップＳ２００）、ハンドラは指定された遅延時間をセットしたタイマー１５を起動した後（ステップＳ２０２）、割り込み処理を抜ける。「ＳｅｔＦｅａ／Ｘ」のリクエストが認識されない場合（ステップＳ２００）、次の判定処理が実行される（ステップＳ２０１）。

タイマー１５にセットした遅延時間が経過すると、タイマ割り込みが起こり（ステップＳ２０３）、タイマ割り込みのハンドラが起動される。タイマ割り込みのハンドラはＥｎａｂｌｅＲｅｍｏｔｅＷａｋｅ（）のルーチンをコールする（ステップＳ２０４）。

ＥｎａｂｌｅＲｅｍｏｔｅＷａｋｅ（）は、コントローラ１のＵＳＢＭＳＫレジスタのリモートウェイクアップの割り込みのマスクを解除する。その結果、ＷＡＫＥＵＰ＃の信号線によるＷＡＫＥＵＰの割り込みの受け付けが許可され（つまり、レジューム信号がアサートされる）、レジューム信号のアサートに伴ってその割り込みハンドラによってリジューム信号がＰＣ３に対して発行される。

ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐのリクエストを受けると、直ちにＥｎａｂｌｅＲｅｍｏｔｅＷａｋｅ（）のコールが行われる場合に比べて、本実施形態では、タイマーによって遅れ時間を確保することができる。これにより、本実施形態では、ＷＡＫＥＵＰ＃のリジューム信号の割り込み入力を抑え、リジューム信号の発行を遅れ時間分遅らせることができる。また、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ａ、ＳｅｔＦｅａｔｕｒｅ／ＲｅｍｏｔｅＷａｋｅＵｐ＿Ｂの二つのリクエストの種類によって、遅れ時間の長さを変えることで、リジューム信号の発行タイミングを遅らせることができる。

以下に、本実施形態の前述のリクエストを使ったリモートウェイクアップのリジュームタイミングを最適化する方法について説明する。

［システムのサスペンド］
システムのサスペンドは以下の手順で行われる。なお、サスペンド状態は、例えば、所定時間ＰＣ３が使用されないとディスプレイの画面が消える状態であり、ＵＳＢバスに接続された入力機器（マウス、キーボード）からの入力又はその他のＰＣ３のボタンを押す行為等により復帰(ウェイクアップ)する。

図１４は、サスペンド移行のシーケンスの一例を示す。

パワーマネージャは、ＰＣ３に搭載されたソフトウェア（ＯＳ）であり、システム全体のパワーの制御に関するサービスを受け持つ。ドライバ、デバイスドライバは、ＵＳＢ機器２（デバイス）に設けられたドライバであり、パワーマネージャの上位階層に対して下位階層に属する。

ＰＣ３に搭載されたＯＳ側は、タイマイベントや操作者の操作を受け、Ｓ３の指示を各デバイスの階層に発行する。各階層のドライバ（パワーポリシィオーナーのドライバ）は自身をＤ２とするためのリクエスト発行要求をパワーマネージャに発行して、Ｓ３のリクエストを下位ドライバに渡す。なお、Ｄ０〜Ｄ４は、デバイス側の省エネレベル（デバイスステート）であり、システム（ＰＣ３）をＳ３にし、かつデバイスからのウェイクアップ要求を指示するときにはデバイスをＤ２とする。

その後、ドライバは、自身の発行したＤ２のリクエストを受け、バスドライバにリモートウェイクアップ待ちを通知する。ドライバは、デバイスに対するリモートウェイクアップのイネーブルのＵＳＢパケットの発行をバスドライバに指示し、その後デバイスにサスペンド状態移行を指示する。

また、デバイスに対するサスペンドの指示は、デバイスドライバからのバスドライバに対するデバイスの接続ポートのＵＳＢバスのアイドル状態の指示によって成される。これにより、デバイスは、サスペンドの指示を認識することができる。ここで、アイドル状態とは、フレームマーカーパケットを含め、何もパケットの送信されていない状態である。

つまり、デバイスのパワー状態の変更の指示はＯＳ側が直接行ってはおらず、デバイスからの要求を受けて指示する形をとり、またそれらリクエストは、デバイスと直接の関係を持たない、階層の他ドライバを経由してドライバに到達する。このため、システム内に複数存在するデバイスに対して渡されるリクエストの処理時間は様々で、ＵＳＢ機器のデバイスドライバが機器に対してリモートウェイクアップを指示した後も、他デバイスの処理が継続されている場合がある。この間にＵＳＢ機器からのウェイク信号を受けるとシステムは不具合を発生することがある。

[ウェイクタイミングの最適化]
本実施形態によれば、以下の方法によって、ＵＳＢインタフェースを有するシステムに最適化した、冗長な待ち時間を待ち、機器の反応を鈍らせることが無く、かつシステムに不具合をもたらさない、最適なリモートウェィクアップが実現される。

本実施形態によってリモートウェイクアップの最適化を行うには、例えば、デバイスに対して最初のリモートウェィクアップのイネーブルに、リモートウェィクアップ信号の長い待ち時間を要求する。ＰＣ３側では、デバイスドライバは、Ｄ２のリクエストを受け、最初にデバイスに対してリモートウェィクアップをイネーブルしてから、パワーマネージャ（ＰＣ３）から電源オフやそれに類するシステムの省エネステートの指示が成されたとき、までの時間を保持、次回のリモートウェィクアップのイネーブル時点では、この時間に基づいて、最適化した待ち時間を設定する方法をとる。

図１５に本実施形態にかかるサスペンド移行のタイムチャートの一例を示す。図の上側には例えば電源オン後の最初のサスペンド移行のシーケンスを示し、下側は二回目以降のサスペンド移行のシーケンスを示す。これら二つのシーケンスは基本的には同じもので、前述の説明の如くのシーケンスをとっている。二つの違いは、最初のシーケンスには、本発明のサスペンド移行期のタイミング情報の経験値が無いことである。このためデバイスドライバは、本実施形態にかかるリモートウェィクアップイネーブルのコマンドの発行に際して、リモートウェィクアップ信号の、安全を考慮した長い待ち時間を指定する。このことによってシステムは、サスペンド直後のウェィクアップ信号によって不具合を誘発することを回避することができる。

また、最初のサスペンド移行の際には、デバイスドライバはＢＩＯＳに対して、例えばＤ２のリクエストを受け取ると、Ｐｏｆｆまでの経過時間の計測の開始を指示する。一方、ＢＩＯＳはデバイスドライバからの指示を受け、ＢＩＯＳがサスペンド移行の最終的なＰｏｆｆのコントロールを行う、ＢＩＯＳのＳ３のＡＣＰＩメソッドがコールされるまでの経過時間をカウントし、この値を保持しておく。

二回目のサスペンド移行の指示が成されると、デバイスドライバはＤ３のリクエストを受けた時点でＢＩＯＳに前記経過時間を問い合わせる。デバイスドライバは、本実施形態にかかるリモートウェィクアップイネーブルのコマンドの発行に際して、このフィードバック値を根拠とした、最適化された待ち時間を指定する。

これにより、デバイスはいままでの経験から導かれた、不具合を生じる可能性を有する待ち時間に拠ることなく、システム固有の待ち時間の設定を受け、サスペンド移行期の不具合の回避も行える。

以上に説明した本実施形態による電源制御によれば、リジューム信号の発行をＵＳＢホスト機器の状態に応じて遅らせることで、リジューム信号の入力タイミングによる不具合を回避できる。

以上、情報処理装置、電源制御プログラム及びＵＳＢ機器を上記実施形態により説明したが、本発明は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。

例えば図１のＵＳＢ機器２のコントローラ１のハードウェア構成は、ＵＳＢ機器２に組み込まれるコントローラの一例であり、コントローラの一部又は全部はハードウェアで構成されてもよいし、ソフトウェアで構成されてもよい。また、図２に示したＰＣ３も同様に、一部又は全部がハードウェアで構成されてもよいし、ソフトウェアで構成されてもよい。

また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。例えば図８〜図１１に示し、上記実施形態にて説明したリクエストによりアサートのタイミング（遅れ時間）を指定する例を組み合わせて、アサートのタイミングを指定してもよい。つまり、リクエストの種類、リクエストの発行タイミング又はリクエストの発行回数のいずれかにより所定の遅れ時間を指定してもよい。これにより、コストアップを生じること無く、Ｓ３への移行時のＰＣ３の不具合の発生を回避出来る。

以上の説明に関し、更に以下の項を開示する。
（付記１）
スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器と通信可能な情報処理装置であって、
前記スリープモードへの移行時に、前記リジューム信号の発行を遅らせるための時間であって前記情報処理装置の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加し、所定のタイミングに発行するリクエスト発行部と、
前記発行されたリクエストを前記ＵＳＢ機器に送信する送信部と、
を有する情報処理装置。
（付記２）
前記リクエスト発行部は、前記リクエストの種類、前記リクエストの発行タイミング、又は前記リクエストの発行回数のいずれか一つによって前記遅れ時間の情報を前記リクエストに付加する、
付記１に記載の情報処理装置。
（付記３）
スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器と通信可能な情報処理装置の電力供給を制御する処理をコンピュータに実行させる電源制御プログラムであって、
前記スリープモードへの移行時に、前記リジューム信号の発行を遅らせるための時間であって前記情報処理装置の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加して所定のタイミングに発行し、
前記発行されたリクエストを前記ＵＳＢ機器に送信する、
電源制御プログラム。
（付記４）
前記リクエストの種類、前記リクエストの発行タイミング、又は前記リクエストの発行回数のいずれか一つによって前記遅れ時間の情報を前記リクエストに付加する、
付記３に記載の電源制御プログラム。
（付記５）
スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器であって、
前記リジューム信号の発行を遅らせるための時間であって前記ＵＳＢ機器と通信する情報処理装置の状態に応じた遅れ時間の情報が付加された、リモートウェイクアップを指示するリクエストを前記情報処理装置から受信する受信部と、
前記リクエストに応じて前記遅れ時間遅らせて発行された前記リジューム信号を前記情報処理装置に送信する送信部と、
を有するＵＳＢ機器。
（付記６）
前記受信部は、前記リクエストの種類、前記リクエストの発行タイミング、又は前記リクエストの発行回数のいずれか一つによって前記遅れ時間の情報が付加された前記リクエストを受信する、
付記５に記載のＵＳＢ機器。

１：コントローラ
２：ＵＳＢ機器
３：ＰＣ
９：ＭＣＵ
１５：タイマー
１０１：ＣＰＵ
１０３：ＨＤＤ
２０１：受信部
２０２：送信部
３０１：電力供給部
３０２：記憶部
３０３：受信部
３０４：リクエスト発行部
３０６：送信部

Claims (4)

1. スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器と通信可能な情報処理装置であって、
   前記スリープモードへの移行時に、前記リジューム信号の発行を遅らせるための時間であって前記情報処理装置の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加し、所定のタイミングに発行するリクエスト発行部と、
   前記発行されたリクエストを前記ＵＳＢ機器に送信する送信部と、
   を有する情報処理装置。
2. 前記リクエスト発行部は、前記リクエストの種類、前記リクエストの発行タイミング、又は前記リクエストの発行回数のいずれか一つによって前記遅れ時間の情報を前記リクエストに付加する、
   請求項１に記載の情報処理装置。
3. スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器と通信可能な情報処理装置の電力供給を制御する処理をコンピュータに実行させる電源制御プログラムであって、
   前記スリープモードへの移行時に、前記リジューム信号の発行を遅らせるための時間であって前記情報処理装置の状態に応じた遅れ時間の情報をリモートウェイクアップを指示するリクエストに付加して所定のタイミングに発行し、
   前記発行されたリクエストを前記ＵＳＢ機器に送信する、
   電源制御プログラム。
4. スリープモードから稼働モードへの移行を指示するリジューム信号を発行するＵＳＢ機器であって、
   前記リジューム信号の発行を遅らせるための時間であって前記ＵＳＢ機器と通信する情報処理装置の状態に応じた遅れ時間の情報が付加された、リモートウェイクアップを指示するリクエストを前記情報処理装置から受信する受信部と、
   前記リクエストに応じて前記遅れ時間遅らせて発行された前記リジューム信号を前記情報処理装置に送信する送信部と、
   を有するＵＳＢ機器。

Images