JP2010186483A - 省電力支援装置 - Google Patents

Abstract

【課題】サーバなどの長時間連続稼働ネットワーク機器に対する省電力支援装置を提供する。
【解決手段】省電力支援装置２０１は，ネットワーク１０９に接続するネットワークインタフェースを含む少なくとも２つのネットワークインタフェースと，情報処理装置１０７が省電力状態か稼働状態かを判断する情報処理装置電源確認部と，ネットワークインタフェースにて受信した情報処理装置への通信に対し，情報処理装置に代わって，受信した通信の応答をする代理応答部と，２つのネットワークインタフェース間の通信に関し，通信に何も手を加えず，そのまま相互に通信を通過させるブリッジ動作部とを備える。
【選択図】図２

Description

本発明はネットワーク接続されるパーソナルコンピュータ及びサーバ機器の省電力運用を支援する装置に関する。

ＩＴ（情報技術）の普及およびインフラ整備により，各企業には多くのパーソナルコンピュータ（以下ＰＣと称す）やサーバ機器が常時起動状態にある。ただ，これらサーバは，実際には，業務時間帯や，ある特定の繁忙期しか利用されないものが少なくない。しかし，サーバはセキュリティ上の理由により業務室から隔離して設置されることが多く，さらにサーバに対するクライアントからの使用要求が不定期に発生することから，サーバの電源ＯＦＦ／ＯＮタイミングをスケジュール定義することは容易でない。また，電源ＯＦＦ／ＯＮを人手で行う煩わしさから，多くのサーバは２４時間連続稼動状態にあり，日々電力を浪費している。
このようなサーバの非効率な運用に対し，ＷＯＬ（Wake ON LAN）と言う技術が提案されている（特許文献１）。

特開平１１−１７５２０１号公報

ＷＯＬはサーバ等のネットワークに接続される機器の省電力に関する技術の１つであり，具体的には，サーバのネットワークインタフェースを通じて，サーバの電源を任意のタイミングでＯＮにしようとするものである。より詳細には，ＷＯＬ対応サーバは，マジックパケット(登録商標)と呼ばれるデータをネットワーク経由で受信することによって，省電力状態(例えば，殆ど電力を消費しないスタンバイ状態，または電源をＯＦＦしたサスペンド状態など)から，通常の起動状態に移行することができる。この様子を図１に示す。

図１は従来技術であるＷＯＬサーバの存在するネットワーク環境図である。この図を参照して，ＰＣ１０１〜１０５およびサーバ１０７はネットワーク１０９に接続されている。サーバ１０７は，スタンバイモードなど消費電力の少ないモードで動作していることとする。この時，ＨＴＴＰなどのサーバ１０７が備えるサービスは提供できない状態にある。ネットワーク１０９に接続されているＰＣ等のネットワーク機器が，このサーバ１０７のサービスを利用するには，サービスの利用に先立ち，何らかの手段でネットワーク経由にてマジックパケットをサーバ１０７に送信し，サーバ１０７を起動させる必要がある。図１は，ＰＣ１０３がサーバ１０７にマジックパケットを送信している様子を示している。これを受信したサーバ１０７は，このマジックパケットを認識し，自身の備える起動機構（図示せず）によってサービス提供可能状態に移行する。なお，マジックパケットを送信する主体はＰＣ１０３だけでなく，ネットワークに接続されている他のＰＣ若しくは，他のネットワーク機器（図示せず）であっても良い。

このようにして，停止状態にあるサーバと通信するクライアントは，サーバの利用に先立ち，サーバに対してマジックパケットを送信し，サーバを起動することでサーバと通信が可能となる。
即ち，ＷＯＬ機能を利用することにより，サーバの稼働時間を削減し，結果として消費電力の削減効果が得られる。

しかし，ＷＯＬによる省電力の効果を得るためには，前述したように，サーバだけでなくクライアントもＷＯＬに対応している必要がある。例えば，クライアントは，マジックパケットを送信するための専用ソフトウェアを予め自身に組み込んでおく必要がある。通常，ネットワーク内には数多くのクライアントが存在し，ＷＯＬを利用する全てのクライアントに対し，ＷＯＬ専用ソフトウェアのインストールを行うのは，ネットワーク運用上，非常に面倒な作業となる。

また，ＷＯＬはサーバ及びクライアントのコンピュータ環境への依存度が比較的大きい技術である。例えば，マジックパケットを送信する専用ソフトウェアは，クライアントで使用される全てのＯＳで利用可能とは限らない。このような事由によって，ＷＯＬ機能を利用できない場合もあった。

また，サーバ及びクライアントがＷＯＬに対応している場合であっても，クライアントのユーザは，サーバの利用に先立ち，サーバの電源がＯＦＦになっているかどうかを何らかの手段で確認する必要があり，このような作業はユーザにとっては煩わしいものとなっていた。

また，ＷＯＬはサーバの電源をＯＮにする技術であり，ＯＦＦにすることはできない。また，Telnet等のリモートコンソール技術を使用することで，サーバの電源をＯＦＦにすることも可能であるが，このような操作は，サーバシステムにおける管理者権限を有するユーザしか行うことができず，必要に応じて随時電源をＯＦＦにすることは非常に煩わしい作業となる。即ち，リモートコンソールによるサーバの電源制御は，システムの運用上，現実的な手段ではなかった。

さらに，ＷＯＬは，サーバの電源がＯＦＦの間，自身が行う必要最小限の処理さえ実行できない。例えば，サーバが他のＤＨＣＰサーバからＩＰアドレスを付与されている場合に，電源がＯＦＦになると，リース時間の延長をすることができない。また，他のサーバ上にあるＷＩＮＳ(Windows(登録商標) Internet Name Service)などの名前データベースに自身の名前が登録されている場合も，更新処理ができず，当該データベースから名前が抹消されることがある。この結果，例え，ＷＯＬに対応したクライアントがサーバにアクセスしようとしても，名前解決などが適切に行えず，サーバにアクセスすることすらできなくなってしまう。つまり，ＷＯＬは，対応サーバおよび対応クライアントを使用する場合においてさえ，サーバを復帰させることができないことがあった。

上述した課題に鑑み，本発明の目的は，クライアントおよびそのユーザがサーバのＷＯＬ対応状況を意識することなくサーバを利用でき，同時にサーバの消費電力を削減することのできる，より汎用性の高い装置，モジュールおよび方法を提供することである。

本発明の第２の形態に係る省電力支援装置は，少なくとも１台の情報処理装置とＤＨＣＰサーバが接続されたネットワークとの間に挿入される省電力支援装置であって，省電力支援装置は，ネットワークに接続されるネットワークインタフェースを含む少なくとも２つのネットワークインタフェースと，ＤＨＣＰサーバ部と，ＤＨＣＰクライアント部とを備え，ＤＨＣＰクライアント部は，ネットワーク上にあるＤＨＣＰサーバに第１のアドレス割当要求を行い，ＤＨＣＰサーバにより割り当てられたＩＰアドレスおよびそのリース時間ＴＡを記憶し，少なくとも１台の情報処理装置より第２のアドレス割当要求を受信すると，ＤＨＣＰサーバ部は，第２のアドレス割当要求に対し，記憶したＩＰアドレスおよび記憶したリース時間ＴＡから第２の割当要求を受信した時間までの経過時間を差し引いた時間をリース時間ＴＢとして応答することを特徴とする。

より好ましくは，ＤＨＣＰクライアント部はさらに，記憶したリース時間ＴＡが満了するまでに，ＤＨＣＰサーバに対し，記憶したリース時間ＴＡの延長要求を送信し，ＤＨＣＰサーバより得られる延長リース時間ＴＣを記憶し，ＤＨＣＰサーバ部はさらに，少なくとも１台の情報処理装置からリース時間延長要求を受信すると，リース時間延長要求をＤＨＣＰサーバにそのまま送信し，ＤＨＣＰサーバからの応答であるリース時間ＴＤをリース時間延長要求の送信元にそのまま応答すると共に，リース時間ＴＤを記憶することを特徴とする。

本発明の第３の形態に係る省電力支援装置は，情報処理装置，当該情報処理装置をクライアントとするサーバおよび省電力支援装置が接続されるネットワークにおいて，省電力支援装置は，ネットワークに接続される少なくとも１つのネットワークインタフェースと，情報処理装置が省電力状態か稼働状態かを判断する情報処理装置電源確認部と，情報処理装置から前記サーバに対して行われるべき通信を，情報処理装置に代わり行い，通信によって得られる結果を保持する代理通信部と，あたかも情報処理装置自身が通信をしたかのように保持された結果に対して所定の処理を施し，情報処理装置に対して処理結果を送信するデータ調整部とを備え，省電力支援装置は，情報処理装置電源確認部によって情報処理装置が省電力状態にあることを判断している間に，代理通信部を起動させ，その後，情報処理装置が省電力状態から復帰したこと判断すると，データ調整部を起動させることを特徴とする。ここで代理通信部，およびデータ調整部とは，それぞれ実施例における，ＤＨＣＰクライアント部，およびＤＨＣＰサーバ部の備える機能を一般化したものである。

本発明の第８の形態に係る方法は，省電力支援モジュールによる情報処理装置の省電力化を支援する方法であって，情報処理装置が省電力状態にあり，本来なら情報処理装置が稼働状態時に，これによって行われるべき処理を，省電力支援モジュールが，第１のトリガに基づいて代理実行するステップを含むことを特徴とする。

より好ましくは，行われるべき処理は，所定のメールサーバにある受信メール一覧の取得であり，第１のトリガは，当該受信メール一覧の取得を実行する時刻の到来であることを特徴とする。

より好ましくは，行われるべき処理は，所定のＤＨＣＰサーバにより付与されているＩＰアドレスのリース時間延長要求であり，第１のトリガは，当該リース時間終了の接近であることを特徴とする。

より好ましくは，さらに，情報処理装置が省電力状態にあり，本来なら前記情報処理装置が稼働状態時に，これによって行われるべき処理を，前記省電力支援モジュールが，前記情報処理装置に実行させるべく，第２のトリガに基づいて前記情報処理装置を起動させるステップを含むことを特徴とする。

より好ましくは，第２のトリガは，所定のＤＨＣＰサーバにより付与されているＩＰアドレスのリース時間終了の接近，または所定のメールサーバに受信すべきメールが存在することの検知であることを特徴とする。

本発明の第９の形態に係る方法は，省電力支援モジュールによる情報処理装置の省電力化を支援する方法であって，情報処理装置が省電力状態にあり，本来なら情報処理装置が稼働状態時に，これによって行われるべき処理を，省電力支援モジュールが，情報処理装置に実行させるべく，所定のトリガに基づいて情報処理装置を起動させるステップを含むことを特徴とする。

より好ましくは，所定のトリガは，所定のＤＨＣＰサーバにより付与されているＩＰアドレスのリース時間終了の接近，または所定のメールサーバに受信すべきメールが存在することの検知であることを特徴とする。

以上の通り，本発明によれば，多くのネットワーク環境において，省電力支援装置は情報処理装置の省電力に貢献できる。結果，本発明の省電力支援装置によって，既存のネットワーク環境を大きく変えることなく，情報処理装置の省電力化が可能となる。

また，換言すると，本発明は，情報処理装置の存在をネットワークに周知せしめ，その状態を維持継続させることにより，ネットワークアベイラビリティの向上を可能にする。即ち，情報処理装置が省電力状態にある間，省電力支援装置が，このネットワークアベイラビリティの維持継続に必要となる，能動的自律動作，及び受動的自律動作を実行する。結果，情報処理装置にとって必要な処理が途切れることなく，ネットワークアベイラビリティを維持継続させることができる。また，本発明の省電力支援装置は，上記した能動的自律動作，及び受動的自律動作では対応できない場合に，発生が予測される処理を行うため，情報処理装置を省電力状態から復帰させる機構も有する。この結果，情報処理装置の省電力状態を最大限維持し，ひいては情報処理装置の維持消費電力を最小化することができる。

以下では図を参照し，本発明に係る装置の実施例を説明する。なお，各図面において共通する要素には同じ番号を付し，説明は繰り返さない。
＜実施例１＞

図２は，本発明に係る装置が使用されるネットワーク環境図である。従来技術におけるネットワーク環境図である図１と比較し，本発明の装置である代理サーバ２０１がネットワーク１０９とサーバ１０７の間に追加・接続されている。図からも明らかなように，サーバ１０７は，ネットワーク１０９に直接接続されておらず，代理サーバ２０１を介して接続されている。即ち，このような接続形態を採用することによって，ネットワーク１０９とサーバ１０７間における通信は，全て代理サーバ２０１を介することになる。
[ハードウェア構成]

図３は，代理サーバ２０１のハードウェア構成図である。図３を参照して，ＣＰＵ３０１は，ＲＯＭ３０３に記憶されているプログラムをＲＡＭ３０５に展開し，このプログラムを実行することによって，代理サーバ２０１の各種動作を実現する。ＲＡＭ３０５には，代理サーバ２０１の動作過程で生じたデータを一時的に保存することもある。第１のネットワークＩ／Ｆ３０７および第２のネットワークＩ／Ｆ３０９は，ハードウェア構成上は等価であり，何れも同じコネクタおよびＬＡＮコントローラ(図示せず)など，ネットワーク接続に必要なハードウェアコンポーネントを備える。なお，本実施例において，第１のネットワークＩ／Ｆ３０７にＰＣ等が接続されているネットワーク１０９が接続され，第２のネットワークＩ／Ｆ３０９にサーバ１０７が接続されているものとして，以下では解説する。なお，第１および第２のネットワークＩ／Ｆと，これらに接続されるネットワークとの対応は，この例に限定されるわけではなく，後述する処理プロトコルの対応など，必要に応じて対応関係が選択可能である。さらに，本実施例において，ネットワークインタフェースは有線タイプを例示しているが，両方，若しくは一方を無線タイプなど，他のハードウェアコンポーネントとすることも可能である。
[ソフトウェア機能ブロック]

図４は本実施例における代理サーバ２０１のソフトウェア機能ブロック図である。図４を参照して，第１のネットワーク送受信部４０１および第２のネットワーク送受信部４１３は，それぞれ第１のネットワークＩ／Ｆ３０７および第２のネットワークＩ／Ｆ３０９を介して接続されるネットワークとの送受信処理を担う。具体的には，ＴＣＰ／ＩＰなどのプロトコル処理を行う。但し，第１のネットワーク送受信部４０１および第２のネットワーク送受信部４１３は，それぞれ独立した機能部であるため，必ずしも同じ機能を有する必要はない。例えば，一方がＩＰｖ４(Internet Protocol Version 4)で他方がＩＰｖ６(Internet
Protocol Version 6)を処理するなど，それぞれ異なったプロトコルを処理することも可能である。なお，この際，既存技術であるプロトコル変換が必要となるが，本発明の趣旨ではないため，具体的実現手段の説明は省略する。

サーバ電源確認部４０３は，第２のネットワーク送受信部４１３を経由して接続されているサーバ１０７の電源状態を確認する。具体的には，サーバ１０７に対して，ＩＣＭＰ(Internet Control Message Protocol) Echo Request通信を定期的に行い，その応答の有無を以て，サーバ１０７の電源のＯＦＦ／ＯＮを把握し，この結果をＲＡＭ３０５に保存する。なお，ＩＣＭＰ通信の時間間隔は任意でよいが，本実施例では５秒間隔とする。また，この値は，設定により可変とすることが可能である。

動作モード切替部４０５は，ＲＡＭ３０５に保存されたサーバの電源状態に基づき，代理サーバ２０１を，代理応答モード(後述)，もしくはブリッジモード(後述)の何れで動作させるかを判定し，必要に応じて，後述する代理応答部４０７，もしくはブリッジ動作部４１３へ代理サーバ２０１の動作を移行させる。さらに，動作モード切替部４０５は，サーバ１０７の起動が必要と判断した場合，マジックパケットをサーバ１０７に対して送信する。
代理応答部４０７は，第１のネットワーク送受信部４０１を通じて，ＰＣ等のネットワーク機器に対して，サーバ１０７の代わりに通信を行う。

ブリッジ動作部４１１は，代理サーバ２０１をブリッジモードとして動作させる。ブリッジモードとは，第１のネットワーク送受信部４０１および第２のネットワーク送受信部４１３の通信に関し，代理サーバ２０１は何の処理も加えず，ただ，それぞれの送受信部の通信を透過的に通過させるだけの処理を意味する。
[システム全体フロー]

次いで，代理サーバ２０１の，動作全体のフローを説明する。図５を参照して，代理サーバ２０１は，２つのタスクを有する。タスクとは，代理サーバ２０１起動時に同時に動作を開始し，電源がＯＮの間，独立して動作するプログラムである。本実施例において，タスクはメインタスク(ａ)と電源確認タスク(ｂ)があり，メインタスクは，動作モード切替部４０５，代理応答部４０７，およびブリッジ動作部４１１を含み，一方，電源確認タスクはサーバ電源確認部４０３を含む。

図５のフローは，代理サーバ２０１の電源がＯＮにされる動作を含めた，装置全体の動作を示すフローチャートである。以下で，各タスクおよび機能部による動作を順に説明する。なお，前提として，ユーザが代理サーバ２０１に対して，サーバ１０７のＩＰアドレスおよびＭＡＣアドレスを設定として予め登録しているものとする。これらのアドレスはＲＡＭ３０５に保存される。
まず，電源確認タスクを説明する。

ステップ５５１において，サーバ電源確認部４０３は，サーバにＩＣＭＰ通信を行い，この応答の有無をサーバの電源状態，即ちサーバ電源フラグとしてＲＡＭ３０５に保存する。応答があれば，サーバ１０７の電源がＯＮであると判定し，なければＯＦＦであると判定する。

ステップ５５３において，サーバ電源確認部４０３は，前回のＩＭＣＰ通信から５秒経過したかを判定する。この結果，Ｎｏであれば再び処理がステップ５５３に戻り，Ｙｅｓであればステップ５５１に処理が戻る。即ち，電源確認タスクにより，代理サーバ２０１の稼働中は，５秒毎にＩＣＭＰ通信が行われ，サーバ電源状態が更新される。
次いでメインタスクを説明する。

ステップ５０１において，メインタスクは，予めＲＡＭ３０５に保存されているＩＰアドレスおよびＭＡＣアドレスを読み出し，自身に設定する。この時点では，これらのアドレス体系で代理サーバ２０１は動作しない。図示していないが，代理サーバ２０１の電源ＯＮ時は，後述するブリッジモードとして動作しているからである。

ステップ５０３において，動作モード切替部４０５は，第１のネットワーク送受信部４０１を通じて，第１のネットワークＩ／Ｆ３０７に接続されているネットワーク１０９上のネットワーク機器(ＰＣなど)からサーバ１０７宛のデータを受信したかを判定する。本実施形態において，代理サーバ２０１は，ネットワーク１０９とサーバ１０７の間に位置することから，代理サーバ２０１の受信するデータは，ブロードキャスト通信を含め，全てサーバ１０７への到達を意図して送信されたデータである。この判定の結果，Ｙｅｓであれば処理がステップ５０５に進み，Ｎｏであれば再度ステップ５０３に戻る。即ち，Ｎｏの場合は，データを受信するまで待ち続けることとなる。

ステップ５０５において，動作モード切替部４０５は，サーバ電源フラグを読み出し，サーバ１０７の電源状態がＯＮかＯＦＦかを判定する。この結果，ＯＮであれば，処理がステップ５１７に進み，ＯＦＦであればステップ５０９に進む。

ステップ５０９において，動作モード切替部４０５は，サーバ１０７の起動条件を満たしたかどうかを判定する。この結果，Ｙｅｓであれば処理がステップ５１１に進み，Ｎｏであれば処理がステップ５１５に進む。ここで，サーバ１０７の起動条件とは，サーバ１０７を起動させるかどうかを決定する条件であり，任意の条件が設定可能である。例えば，「ＨＴＴＰ ＧＥＴ」メソッドを受信した場合は起動させるが，「ＴＣＰ ＳＹＮ」だけなら起動させないなどである。

ステップ５１１において，動作モード切替部はサーバ１０７に対してマジックパケットを送信する。
ステップ５１５において，代理応答部４０７がサーバ２０１への通信に対して代理応答をするが，この処理の詳細は別途説明する。このステップが終了すると，再び処理がステップ５０３に戻る。
ステップ５１７において，ブリッジ動作部４１１が代理サーバ２０１をブリッジとして動作させるが，この処理の詳細は別途説明する。このステップが終了すると，再び処理がステップ５０３に戻る。
[代理応答シーケンス]

図６は，代理サーバ２０１がＰＣに対して，サーバ１０７の代理としてＨＴＴＰ通信を行う際のシーケンス図である。なお，本実施例において，サーバ１０７はＨＴＴＰサーバとして動作しているものとし，ＰＣはサーバ１０７のＩＰアドレスを予め認識しているものとする。また，本シーケンス図における代理サーバ２０１の動作は，代理応答部４０７の動作(図５のステップ５１５)となる。

ステップ６０１において，代理サーバ２０１は，図５のステップ５０１で設定されたＩＰアドレスおよびＭＡＣアドレスにて自身が動作するよう設定する。
通信６０３において，ＰＣはサーバ１０７のＩＰアドレスに対応するＭＡＣアドレスを得るため，ＡＲＰ要求をブロードキャストする。

通信６０５において，代理サーバ２０１は，このＡＲＰ要求を受けてＰＣにＭＡＣアドレスを応答する。通信６０３にて送信されたＡＲＰ要求は，サーバ１０７のＩＰアドレスに対するものであり，代理サーバ２０１はこのＩＰアドレスにて動作しているため，対応するＭＡＣアドレスであるサーバ１０７のＭＡＣアドレスが応答される。

通信６０７において，ＰＣは代理サーバ２０１に対してＴＣＰ接続を開始すべく，ＨＴＴＰのサービスポートＴＣＰ８０番に向けてＳＹＮを送る。なお，ステップ６０１にて説明した通り，代理サーバ２０１は，サーバ１０７のＩＰアドレスおよびＭＡＣアドレスにて動作している。即ち，ＰＣはサーバ１０７に対してＳＹＮ送ったと認識しているが，実際にこれを受け取るのは代理サーバ２０１となる。

通信６０９において，代理サーバ２０１は，ＰＣからのＳＹＮを受け，サーバ１０７を起動するため，サーバ１０７にＷＯＬのマジックパケットを送信する。なお，通信６０３のＡＲＰ要求を受信した時点でマジックパケットを送信しない理由は，ＡＲＰ要求だけでは後に続く通信，即ちサーバ１０７を必要とする通信が開始されるかどうかが不明なためである。即ち，本実施例では，マジックパケットの送信条件として，ＴＣＰ８０番ポートに対するＳＹＮの受信が設定されている。このマジックパケットを受けたサーバ１０７は，ＷＯＬにより自身の電源をＯＮにし，ＯＳの起動など一連の起動処理(ステップ６１１)を開始する。

通信６１３において，代理サーバ２０１は，ＰＣからのＳＹＮに対する応答であるＳＹＮ＋ＡＣＫをＰＣに送信する。この通信は，本来であれば，サーバ１０７が返すべきものであるが，これを代理サーバ２０１がサーバ１０７の代理として送信している。

通信６１５において，ＰＣは代理サーバ２０１からのＳＹＮ＋ＡＣＫを受け，これに対する応答であるＡＣＫを代理サーバ２０１に送信する。上記した通信６０７，６１３および６１５を以て，ＰＣと代理サーバ２０１のＴＣＰ接続が確立される。なお，この接続はＰＣと代理サーバ２０１の間で確立されたものであるが，ＰＣはサーバ１０７と接続を確立していると認識している。

通信６１７において，ＰＣは代理サーバ２０１に対して，ＨＴＴＰコンテンツを取得すべく，「ＨＴＴＰ ＧＥＴ」メソッドを送信する。
通信６１９において，代理サーバ２０１はＰＣからの「ＨＴＴＰ ＧＥＴ」に対して，正常に処理できた旨を示す，「２００ ＯＫ」をＰＣに応答する。

通信６２１において，代理サーバ２０１はＰＣに代替ＨＴＴＰコンテンツを送信する。なお，ここで送信されるコンテンツは，代理サーバ２０１が備えるコンテンツであって，サーバ１０７が備えるコンテンツではない。即ち，ＰＣが受信を期待するコンテンツではない。具体的には，図７のようなコンテンツが送信され，ＰＣ側では図８のようなイメージが表示される。
ステップ６２３において，サーバ１０７の起動処理が完了する。

通信６２７〜６３３は，ＰＣと代理サーバ２０１との間のＴＣＰ接続を，代理サーバ２０１から切断するシーケンスである。このシーケンスは，通常のＴＣＰ切断のシーケンスと同じであるため説明を省略する。

なお，図７からも明らかな通り，代理サーバ２０１からＰＣに送信される代替ＨＴＴＰコンテンツには，定期的にＷｅｂページを再読込する指示が含まれている。図７の場合，１００００ミリ秒毎にＷｅｂページを再読込することとなる。即ち，ＰＣはステップ６０７〜６３３までの処理を繰り返すこととなる(ステップ６２２)。
［ブリッジ動作シーケンス］

図９は，代理サーバ２０１のブリッジ動作(図５のステップ５１７)，およびＰＣのＷｅｂページ再読込６２２の処理の流れを示すシーケンス図である。

通信９０１において，ＰＣはサーバ１０７との間にＴＣＰ接続を確立すべくＳＹＮを送信する。このＳＹＮは一旦代理サーバ２０１にて受信されるが，代理サーバ２０１はブリッジモードであるため，これに対し何ら手を加えずサーバ１０７に対してそのまま通過させる。以下，代理サーバ２０１を経由する通信は全て同じように通過させるため，説明は繰り返さない。

通信９０３において，サーバ１０７はこのＳＹＮに対して，ＳＹＮ＋ＡＣＫを応答する。
通信９０５にてＰＣがサーバ１０７に対してＡＣＫを応答する。上記した９０１〜９０５により，ＰＣとサーバ１０７との間にＴＣＰ接続が確立される。代理サーバ２０１が代理モードの時は，ＰＣと代理サーバ２０１との間でＴＣＰ接続が確立されたが，ブリッジモードの時はＰＣとサーバ１０７の間でＴＣＰ接続が確立される。何れの場合においても，ＰＣはサーバ１０７とＴＣＰ接続を確立したものと認識している。
通信９０７において，ＰＣは確立したＴＣＰ接続を使用して「ＨＴＴＰ ＧＥＴ」メソッドをサーバ１０７に送信する。
通信９０９において，サーバ１０７はＰＣに正常に処理が完了した旨である「２００ ＯＫ」の応答をする。

通信９１１において，サーバ１０７は，ＰＣにＨＴＴＰコンテンツを送信する。ここで送信されるコンテンツは，ＰＣが本来要求していたコンテンツであって，代理サーバ２０１が代理応答時に送信した代替コンテンツではない。

通信９１３において，ＰＣはＴＣＰ接続を切断するため，ＦＩＮをサーバ１０７に送信する。
通信９１５において，サーバ１０７はＦＩＮに対するＡＣＫをＰＣに送信する。
通信９１７において，サーバ１０７はＦＩＮをＰＣに送信する。
通信９１９において，ＰＣはサーバ１０７からのＦＩＮに対してＡＣＫをサーバ１０７に送信する。

以上の通信を以て，ＰＣとサーバ１０７の間の通信は完了する。その後一定条件が満たされた場合，サーバは自ら電源をＯＦＦにしたり，スタンバイモードに突入するなど待機状態に入る。ここで一定条件とは，例えば，無通信時間が所定の時間を超えた場合などである。このような動作を行うには，サーバ１０７に予め専用ソフトウェアをインストールしておくなどの準備が必要となる。なお，サーバ１０７の電源がＯＦＦになった場合であっても，代理サーバ２０１のサーバ電源確認部の常に動作しているため，電源ＯＦＦを検知し，直ちに自らの動作モードをブリッジモードから代理応答モードに移行することができる。

本実施例によれば，ＰＣはＷＯＬに対応していなくとも，サーバ１０７の電源を必要に応じて起動し，サービスを受けることができる。また，代理サーバは，ネットワークおよびサーバに接続される２つのネットワークＩ／Ｆを備えることによって，ＰＣからサーバへの通信に関し，必ず代理サーバ自身を経由させることができる。なお，ＰＣおよびそのユーザは，前もってサーバ１０７の電源状態を確認するなど，サーバ１０７の電源状態を意識することなく，サーバ１０７を利用することができる。
＜実施例２＞

実施例１は，サーバ１０７のＩＰアドレスが固定的に割り当てられている場合の動作であった。しかし，実際のネットワーク運用においては，ＤＨＣＰ(Dynamic Host Configuration Protocol)サーバを設置し，クライアントの要求に応じて，ＤＨＣＰサーバが動的にＩＰアドレスを付与することもある。本実施例では，ネットワーク上にＤＨＣＰサーバが存在し，サーバ１０７がこのＤＨＣＰサーバよりＩＰアドレスを取得する場合を説明する。

図１０は，ＤＨＣＰサーバが設置されたネットワーク環境図である。図１０を参照して，代理サーバ２０１やＰＣ(１０１〜１０５)が接続されているネットワーク１０９にＤＨＣＰサーバ１００１が接続されている。ただ，ＤＨＣＰサーバは必ずしもＩＰアドレスが付与されるクライアントと同じネットワークに接続されなければならないわけではなく，クライアントとＤＨＣＰサーバが別のネットワーク上に存在しても運用可能である。

図１１は，本実施例における代理サーバ２０１のソフトウェア機能ブロック図である。図１１を参照して，実施例１と比較し，ＤＨＣＰサーバ部１１０１およびＤＨＣＰクライアント部１１０３が追加されている。

ＤＨＣＰクライアント部１１０３は，ＤＨＣＰサーバよりＩＰアドレスを割り当ててもらうため，ＤＨＣＰサーバに対してＩＰアドレス割り当て要求を送信する。さらに，割り当てられたＩＰアドレスのリース時間が切れる前に，そのリース時間の延長をＤＨＣＰサーバに要求する。

ＤＨＣＰサーバ部１１０１は，ＤＨＣＰサーバとしての機能を担う機能部ではあるが，代理サーバ２０１においては，ＤＨＣＰクライアント部１１０３でのアドレス取得結果を元に動作する点が，一般に設置されるＤＨＣＰサーバとは異なる。具体的には，クライアントからのＩＰアドレス割り当て要求を受信した場合，前述のＤＨＣＰクライアント部にて取得したＩＰアドレスを，該当ＩＰアドレス取得時刻から起算し適切に調整されたリース時間とともに応答する。クライアントからのリース時間の延長要求に関しては，代理サーバ２０１搭載のＤＨＣＰサーバ部１１０１は主体的には関与せず，本来のＤＨＣＰサーバ１００１との通信を橋渡しするように動作する。但し，本来のＤＨＣＰサーバ１００１と，クライアントの間で合意された，ＩＰアドレス及びそのリース時間についての情報は，代理サーバで保持している同情報にも，適時反映更新される必要がある。

図１２は，サーバ１０７がＤＨＣＰサーバ１００１よりＩＰアドレスの割当を受ける場合の，代理サーバ２０１を含む一連の動作を示すシーケンス図である。前提として，最初はサーバ１０７および代理サーバ２０１の電源はＯＦＦとする。また，ＩＰアドレスの割当要求は，実際にはＤＨＣＰプロトコルのDISCOVER,OFFER,REQUEST,ACK通信を含み，ＩＰアドレスのリース時間延長要求は，REQUEST,ACK通信を含むが，本実施例では簡易的にそれぞれを「ＩＰアドレス割当要求」，「リース時間延長要求」などと記す。

ステップ１２０１において，代理サーバ２０１の電源がＯＮになる。
通信１２０３において，起動された代理サーバ２０１は，第１のネットワークＩ／Ｆ３０７を通じて，ＤＨＣＰクライアント部１１０３の機能により，ＩＰアドレス割当要求を送信する。なお，このＩＰアドレス割当要求は，ブロードキャスト通信の為，特定の相手先を指定しなくてもＤＨＣＰサーバ１００１に通信が到達する。

通信１２０５において，ＤＨＣＰサーバ１００１は，任意のＩＰアドレスおよびそのリース時間を設定し代理サーバ２０１に応答する。なお，割り当てられたＩＰアドレスおよびそのリース時間は，代理サーバ２０１のＲＡＭ３０５に保存される。

通信１２０７において，代理サーバ２０１は，リース時間の時間が切れる前に，ＤＨＣＰサーバ１００１に対し，割当済みのＩＰアドレスのリース時間の延長を要求する。

通信１２０９において，ＤＨＣＰサーバ１００１は，リース時間を延長し，この時間を代理サーバ２０１に応答する。延長されたリース時間は，ＲＡＭ３０５に保存されているリース時間に上書き保存される。これにより，割り当てられているＩＰアドレスのリース時間が更新される。

ステップ１２１１において，サーバ１０７の電源が入れられる。
通信１２１３において，サーバ１０７はＩＰアドレス割当要求を送信する。なお，ＩＰアドレス割当要求は，通信１２０３と同じくブロードキャスト通信である。

通信１２１５において，代理サーバ２０１のＤＨＣＰサーバ部１１０１は，通信１２１３のＩＰアドレス割当要求の受信に対し，ＩＰアドレスおよびリース時間を応答する。ここで応答するＩＰアドレスは，予め通信１２０５で割り当てられ，ＲＡＭ３０５に保存されているＩＰアドレスであり，リース時間(Ｃ)は，通信１２０９で延長されたリース時間(リース時間(Ｂ))から，通信１２０９でＤＨＣＰサーバ１００１がリースした時間を起点としサーバ１０７が通信１２１３を開始するまでの時間(経過時間(Ａ))を差し引いた時間となる。式を以下に示す。
リース時間(Ｃ)＝リース時間(Ｂ)−経過時間(Ａ)

通信１２１７において，サーバ１０７は，通信１２１５で割当られたリース時間を延長すべく，リース時間延長要求をＤＨＣＰサーバ１００１に送信する。この時，代理サーバ２０１この通信をそのままＤＨＣＰサーバ１００１に送信する。

通信１２１９において，ＤＨＣＰサーバ１００１は，このリース時間延長要求に対し，リース時間を延長してサーバ１０７に送信する。この時，代理サーバ２０１は，延長されたリース時間をＲＡＭ３０５に保存し，リース時間を保持する。

言い換えると，本実施例における代理サーバ２０１は，クライアントであるサーバ１０７からＤＨＣＰサーバ１００１に対して行われるべき通信をサーバ１０７に代わって行い，その通信によってＤＨＣＰサーバから得られる結果を保持するという機能(代理通信機能)とともに，あたかもサーバ１０７自身が通信をしたかのように保持された結果に対して所定の処理を施し，サーバ１０７に対して処理結果を送信する機能(データ調整機能)の２つを有する。実施例１の場合は，代理サーバはネットワーク上の他の端末からサーバを宛先とする送信があったときにのみ，そのサーバに代わって応答したが，本実施例では，代理サーバ２０１が能動的にネットワーク上の他の端末（この場合ＤＨＣＰサーバ）と送信・受信を行う点が異なる。

本実施例によれば，サーバがＤＨＣＰサーバよりＩＰアドレスを割り当ててもらう運用形態において，サーバが省電力状態に入り，ＩＰアドレスのリース時間延長を要求できない状態になっても，割り当てられたＩＰアドレスがリース時間満了によって解放されることなく，省電力状態復帰後においても，サーバはそのＩＰアドレスを使用し続けることができる。
＜実施例３＞

これまでの実施例では，代理サーバ２０１がＰＣからの要求を受信し，これをトリガとしてサーバ１０７にマジックパケットを送信することでサーバ１０７を起動していた。しかし，この方法では，サーバ１０７がＷＯＬに対応している必要がある。そこで本実施例では，マジックパケットを使用しない，より汎用的にサーバを起動することのできる代理サーバを説明する。

図１３は，本実施例に係る代理サーバ２０１のハードウェア構成図である。他の実施例と比較して，スイッチ回路１３０１が追加されている。スイッチ回路１３０１は２つの端子を電気的に導通させる装置である。

図１４は，本実施例に係る代理サーバ２０１の使用されるネットワーク環境図である。他の実施例と比較して，リード線１４０１が追加されている。図示していないが，このリード線１４０１は，２本の導線を有している。それぞれの導線は，一端が代理サーバ２０１のスイッチ回路１３０１が備える端子に接続され，もう一端がサーバ１０７のマザーボード上にある，ＰＷＲ端子およびそのＧｒｏｕｎｄ端子に接続されている。なお，マザーボード上には通常，システムパネルコネクタとして，ＰＷＲ端子以外に，ＰＣをリセットするためのＲＥＳＥＴ端子やＩＤＥ
ＡＣＣＥＳＳのＬＥＤ端子などが配されている。

システムパネルコネクタの一例を図１５に示す。なお，システムパネルコネクタの端子レイアウトは，マザーボードの機種毎に固有となっており，この図のレイアウトは一例である。

図１５を参照して，ＰＷＲ端子１５０１は電源を投入するための端子であり，この端子とＧｒｏｕｎｄ端子を導通させることで，マザーボード上のＡＴＸ電源コネクタ(図示せず)を通じてＡＴＸマザーボードに電力の供給が始まる。

図１６は，本実施例に係る代理サーバ２０１のソフトウェア機能ブロック図である。他の実施例と比較して，動作モード切替部１６０１が変更されている。本実施例の動作モード切替部１６０１は，他の実施例で記載したマジックパケット送信機能に代え，スイッチ回路導通機能が追加されている。スイッチ回路導通機能は，代理サーバ２０１の代理応答時に，スイッチ回路１３０１の２つの端子を導通させる。即ち，図６のステップ６０９においてマジックパケットの送信に代え，スイッチ回路１３０１導通させることで，サーバ１０７のマザーボードの電源をＯＮにしサーバ１０７を起動する。

ところで，ＰＷＲ端子１５０１は，通常，電源をＯＮにするだけでなく，電源をＯＦＦにする場合にも用いられる。即ち，サーバ１０７の稼働中に，再度ＰＷＲ端子１５０１とＧｒｏｕｎｄ端子を導通させることでサーバ１０７の電源をＯＦＦにすることができる。具体的には，代理サーバ２０１は，サーバ１０７への通信に関し，一定時間無通信の時間を検知するなど，所定の条件を満たした場合に，ＰＷＲ端子１５０１とＧｒｏｕｎｄ端子を導通させる。

ただし，上記した両端子の導通によりサーバ１０７の電源をＯＦＦにするには，サーバ１０７のＯＳやマザーボードのＢＩＯＳなどに対し，事前の設定が必要になることがある。

本実施例によれば，ＰＣだけでなくサーバもＷＯＬに対応することなく，サーバの電源を必要に応じてＯＮにすることができる。また，ユーザは，サーバＯＳの管理者権限が無くとも，サーバの電源をＯＦＦにすることができるため，より高い省電力効果が得られる。
＜実施例４＞

これまでの実施例では，電源を制御したいサーバが１台しかない場合を説明した。これに対して，本実施例では複数台のサーバの電源を制御することのできる代理サーバについて説明する。

図１７は，本実施例に係るネットワーク環境図である。図１７を参照して，代理サーバ２０１は，ネットワーク１０９およびスイッチングハブ１７０１に接続されている。スイッチングハブ１７０１には，サーバ１０７，１１１および１１３が接続されている。これらのサーバは，同じサービスを提供するサーバでも良いし，異なった機能を提供するサーバでも良い。このような接続形態を採ることにより，ネットワーク１０９と各サーバ間の通信は，全て代理サーバ２０１を介することとなる。

図１８は，代理サーバ２０１がＲＡＭ３０５にて管理するサーバ情報管理テーブルである。各レコードは，サーバのＩＰアドレス，ＭＡＣアドレスおよび動作モードのフィールドにより構成されている。このうち，ＩＰアドレスおよびＭＡＣアドレスは，実施例１でも説明した通り，ユーザにより予め入力されている。動作モードは，各サーバの最新の動作モードを示しており，実施例１で説明した，電源確認タスクのサーバ電源確認部４０３により随時更新される。

図１９は，本実施例における代理サーバ２０１の動作を概念的に示した図である。図１９を参照して，代理サーバ２０１内に動作スイッチ回路１９０１，１９０３および１９０５がある。各動作スイッチ回路は，これまでの実施例で説明した動作を概念的に示したものであり，何れも動作としては等価である。上記したように，本実施例では，代理サーバ２０１には３つの動作スイッチ回路が存在する。これらは，代理サーバ２０１が管理するサーバの数だけ論理的に代理サーバ内に生成され，それぞれ独立したサーバに対応づけられ動作する。即ち，動作スイッチ回路１９０１は，図１８のＩＰアドレス192.168.0.1のサーバのためのスイッチ回路であり，スイッチ回路１９０３は，図１８のＩＰアドレス192.168.0.2のサーバのためのスイッチ回路であり，スイッチ回路１９０５は，図１８のＩＰアドレス192.168.0.10のサーバのためのスイッチ回路である。各スイッチ回路は，それぞれ独立している為，対応づけられたサーバの電源状態に応じて独立して動作する。例えば，動作スイッチ回路１９０１に対応づけられているサーバの電源がＯＦＦの場合は，代理サーバ２０１が代理応答をする必要がある為，スイッチが代理応答部に繋がっている。一方，動作スイッチ回路１９０３に対応づけられているサーバは電源がＯＮであるため，スイッチがブリッジ動作部に繋がっている。つまり，代理サーバ２０１は，管理するサーバの数に応じて，動作スイッチ回路を論理的に生成することで，複数のサーバの電源状態を同時に管理することができる。

図２０は，本実施例に係る代理サーバ２０１の動作フローを示している。図２０を参照して，メインタスクは上述した動作スイッチ回路の動作を詳細に示したものであり，各動作スイッチ回路毎に存在し，電源確認タスクは，サーバの数に依らず，代理サーバ２０１内に１つだけ存在する。本実施例の場合，管理するサーバが３台なので，メインタスクは３つ存在し，電源確認タスクは１つ存在する。以下では，図５との差異についてのみ説明する。

ステップ２００１において，代理サーバ２０１は，ＲＡＭ３０５に保存されているサーバ情報管理テーブル１８０１のＩＰアドレスおよびＭＡＣアドレスを自身に設定する。本実施例では，３つのサーバ情報がテーブルで管理されているので，各サーバに対応するメインタスクは，それぞれのＩＰアドレスおよびＭＡＣアドレスを自身に設定する。結果として，代理サーバ２０１は３つのＩＰアドレスおよびＭＡＣアドレスを自身に設定することとなる。

ステップ２０５１において，代理サーバ２０１は，管理する各サーバに対しＩＣＭＰ通信を行い，それぞれの電源状態を把握し，この結果をサーバ情報管理テーブル１８０１の各サーバ毎に保存する。

本実施例によれば，代理サーバは複数のサーバの電源状態を管理することできるので，ネットワークシステムにおける総合的な消費電力の削減に効果がある。
＜実施例５＞

これまでの実施例では，代理サーバ２０１はネットワークインタフェースを２つ備えていた。これにより，サーバとネットワーク間の通信が，必ず代理サーバ２０１を経由していたため，代理サーバ２０１はサーバになりすました代理応答が可能であった。本実施例では，ネットワークインタフェースを１つしか備えない場合の代理サーバ２０１について説明する。

図２１は，本実施例に係る代理サーバ２０１の使用されるネットワーク環境図である。図２１を参照して，他の実施例との違いは，代理サーバ２０１がネットワーク１０９とサーバ１０７の間に位置していないことである。即ち，ＰＣからサーバ１０７への通信は，後述する特定の場合を除き，代理サーバ２０１を経由しない。

図２２は，本実施例に係る代理サーバ２０１のハードウェア構成図である。他の実施例と比較して，ネットワークインタフェースが１つになっている。即ち，ネットワークＩ／Ｆ２２０１の１つしか存在しない。このネットワークＩ／Ｆ２２０１は，他の実施例のネットワークインタフェースと等価であり，無線・有線などその接続形態は任意のものが選択可能である。

ハードウェア構成およびソフトウェア構成は，他の実施例とそれほど大差ないが，本実施例の代理サーバ２０１は，通常はブリッジではなくＨＴＴＰプロキシサーバとして動作する点が大きく異なる。即ち，ＰＣからのＨＴＴＰ通信は，ＨＴＴＰプロキシサーバである代理サーバ２０１を必ず経由することになる。代理サーバ２０１は，ＨＴＴＰプロキシサーバとして動作することによって，ネットワークインタフェースが１つしか備えておらず，さらに，ネットワーク１０９とサーバ１０７の間に必ずしも位置しなくとも，ＰＣからサーバ１０７へのＨＴＴＰ通信に関して自らを経由させることができる。

図２３は，本実施例に係る代理サーバ２０１のソフトウェア機能ブロック図である。他の実施例と比較してネットワーク送受信部２３０１が１つしか存在しない。このネットワーク送受信部２３０１は，他の実施例の送受信部と等価であり，プロトコル処理など，ネットワークデータの送受信に関して，任意のソフトウェア処理が可能である。本実施例で新たに追加されたＨＴＴＰプロキシ動作部２３０３は，他の実施例におけるブリッジ動作部４１１に代わるものである。ＨＴＴＰプロキシ動作部２３０３は，既存のＨＴＴＰプロキシサーバと同じ処理を行うため説明は省略する。

図２４は，本実施例に係る代理サーバ２０１の動作フローである。他の実施例と比較して，２４０３が変更・追加されている。
ステップ２４０３は，ＨＴＴＰプロキシ動作部によるＨＴＴＰプロキシサーバとしての動作であるが，上述した通り，これは既存技術であるため説明は省略する。

以上説明したように，本実施例において，代理サーバ２０１は，通常はＨＴＴＰプロキシサーバとして動作し，代理応答が必要な場合には，他の実施例と同様，代理応答を行う。なお，本実施例はプロキシサーバを例示したが，ＰＣからの通信が必ず経由するものであれば，これに限らない。

本実施例によれば，代理サーバは，必ずしもサーバとＰＣの接続されるネットワークとの間に位置する必要がないため，より多くのネットワークシステムに対して柔軟に適用可能である。換言すると，代理サーバは，１つのネットワークＩ／Ｆを持たない場合であっても，自身がプロキシサーバとして動作することで，ＰＣからサーバへの通信に関し，必ず自身を経由させる事ができる。
＜実施例６＞

これまでの実施例では，代理サーバ２０１は，ネットワークに接続される独立した装置として説明してきた。しかし，代理サーバ２０１の機能は，必ずしも独立した機器である必要はなく，電源を制御したいサーバに直接組み込むことも可能である。そこで本実施例では，サーバのネットワークインタフェースカードに代理サーバ機能を組み込む場合を説明する。

図２５は，代理サーバ機能の組み込まれたネットワークインタフェースカード(以下インテリジェントＮＩＣと称す)を備えるサーバ１０７が接続されるネットワーク環境図である。図２５を参照して，サーバ１０７はインテリジェントＮＩＣ２５０１を備え，これを通してネットワーク１０９に接続されている。従って，ネットワーク１０９とサーバ１０７の通信は，全てインテリジェントＮＩＣ２５０１を介すこととなる。

図２６は，本実施例に係る，インテリジェントＮＩＣ２５０１のハードウェア構成図である。インテリジェントＮＩＣ２５０１は，ＲＯＭ２６０３に保存されているプログラムをＲＡＭ２６０５に展開し，このプログラムを実行するＣＰＵ２６０１を備える。さらに，インテリジェントＮＩＣ２５０１は，ネットワーク１０９と接続するためのネットワークＩ／Ｆ２６０７，このネットワークＩ／Ｆを制御するＬＡＮコントローラ２６０９，２つの端子を電気的に導通させるスイッチ回路２６１１およびサーバ１０７とのインタフェースであるPCI express I/F２６１３を備える。

他の実施例と同様，ネットワークＩ／Ｆ２６０７は，本実施例では有線を想定しているが，無線であっても構わない。スイッチ回路２６１１は，図１３で説明したものと同じであり，ＰＣのマザーボード上にあるＰＷＲ端子とそのＧｒｏｕｎｄ端子に接続されている。

図２７は，本実施例に係る，インテリジェントＮＩＣ２５０１のソフトウェアブロック図である。ネットワーク送受信部２７０１は，ＴＣＰ／ＩＰなどのプロトコル処理を実行する。なお，このプロトコル処理はインテリジェントＮＩＣ２５０１が代理応答モードの時にのみ動作する。動作モード切替部２７０３は，図５で説明した動作とほぼ同じであるが，本実施例では，マジックパケット送信５１１に代え，PCI express I/F２６１３への割り込み，またはスイッチ回路２６１１への導通指示を行う。これらのトリガにより，サーバ１０７を電源ＯＮにする。PCI express I/F送受信部２７０７は，インテリジェントＮＩＣ２５０１とサーバ１０７のPCI express I/Fとの間の送受信を実行する。ブリッジ動作部２７０５の動作は，他の実施例のそれとは少し異なる。即ち，本実施例において，ブリッジ動作部２７０５は，ネットワーク送受信部２７０１とPCI express送受信部２７０７との間の通信に関して，ブリッジとして動作する。つまり，その間を流れるデータに対して何も手を加えず，ただ，通過をさせるのみである。従って，プロトコル処理などはＰＣ側のアプリケーションによって実行される。

以上説明したように，本実施例では，代理サーバ機能はインテリジェントＮＩＣ２５０１に組み込まれている。ＮＩＣに代理サーバ機能を組み込んだ事による，独立した装置である代理サーバ２０１との動作の違いは，サーバ１０７の電源をＯＮにする手段(端子の導通，もしくはPCI express I/Fへの割り込み)と，ブリッジ動作時のデータの流れる経路(ネットワーク送受信部２７０１とPCI express 送受信部２７０７の間)である。

なお，本実施例では，インテリジェントＮＩＣ２５０１にスイッチ回路２６１１を設け，サーバ１０７のＰＷＲＳＷ回路からサーバ１０７の電源をＯＮにしたが，サーバ１０７がＷＯＬ端子を備える場合は，インテリジェントＮＩＣ２５０１側にＷＯＬ端子(図示せず)およびＷＯＬ端子制御部(図示せず)を設け，ＷＯＬ端子経由でサーバ１０７の電源をＯＮにしても良い。

本実施例によれば，代理サーバ機能は内蔵カードとして情報処理装置に直接組み込むことが可能なため，より多くのネットワークシステムにおいて適用可能である。
＜実施例７＞

これまでの実施例では，代理サーバ２０１とサーバ１０７のインタフェースはネットワークであるＥｔｈｅｒｎｅｔ(登録商標)を前提として説明してきたが，本発明はこれに限定されることなくＵＳＢインタフェースなど他の物理インタフェースを利用することも可能である(図２８)。この場合，代理サーバ２０１は，ＥｔｈｅｒｎｅｔとＵＳＢインタフェースとの間のプロトコル変換機能を搭載していればよい。

本実施例によれば，代理サーバとサーバとの間の接続に，Ｅｔｈｅｒｎｅｔ以外のインタフェースを用いるため，必ずしもサーバはネットワーク機能を必要としない。このため，代理サーバは，ネットワーク機能を備えるサーバだけでなく，他の様々な情報処理装置に対しても適用可能である。
＜実施例８＞

本実施例では，実施例６で示したインテリジェントＮＩＣ２５０１において，図２９に示すようなソフトウェアを動作させる。

図２９を参照して，ＰＯＰクライアント部２９０１および情報処理装置電源確認部２９０３が新たに追加されている。なお，代理応答部４０７は記載されていないが，本実施例において不要と言うだけであって，実際には，代理応答部４０７を同時に動作させても良い。
ＰＯＰクライアント部２９０１は，任意のメールサーバにおける所定のアカウントに対する受信メールのリストを取得する。

情報処理装置電源確認部２９０３は，インテリジェントＮＩＣ２５０１が組み込まれる母体である情報処理装置の電源状態を，PCI express送受信部２７０７を介して定期的に監視し，この結果を電源フラグとして保持する。なお，情報処理装置電源確認部２９０３は，後に説明する電源確認タスクに含まれる。

動作モード切替部２９０５は，保存された電源フラグを読み出し，必要に応じて情報処理装置の動作モードを切り替える。

図３０を参照して，本実施例の動作フローを説明する。
まずは，電源確認タスク(ｂ)を説明する。
ステップ３００１において，情報処理装置電源確認部２９０３は，情報処理装置の電源状態を確認し，結果を電源フラグとしてＲＡＭ３０５に保存する。フラグは，情報処理装置の電源がＯＮの場合とＯＦＦの場合の２種類がある。

ステップ３００３において，前回の電源確認の実施から所定時間が経過したかを判定する。経過していれば，処理がステップ３００１に戻り，そうでなければ，再度，処理がステップ３００３に戻る。

次いで，メインタスク(ａ)を説明する。
ステップ３００５において，メインタスクは，予めＲＡＭ３０５に保存されているＩＰアドレスおよびＭＡＣアドレスを読み出し，自身に設定する。

ステップ３００７において，動作モード切替部２９０５は，保存されている電源フラグを読み出し，情報処理装置の電源状態がＯＮであれば，ブリッジ動作部２７０５を起動(ステップ３０１９)させ，そうでなければ処理がステップ３００９に進む。
ステップ３００９において，ＰＯＰクライアント部２９０１は，受信メールリスト取得用のタイマーをセットする。

ステップ３０１１において，ＰＯＰクライアント部２９０１は，所定のメールサーバにある受信メールのリストをチェックする時刻になったかどうかを判定し，時刻が到来していれば処理がステップ３０１３に進み，そうでなければ処理がステップ３００７に戻る。
ステップ３０１３において，ＰＯＰクライアント部２９０１は，メールサーバにアクセスし，受信メールのリストを取得する。

ステップ３０１５において，リスト取得の結果，メールがあるかどうかを判定する。結果，メールがあれば，処理がステップ３０１７に進み情報処理装置を起動(ステップ３０１７)し，そうでなければ，処理がステップ３００７に戻る。なお，情報処理装置を起動させる手段は実施例６と同様である。

本実施例によれば，本来，情報処理装置が能動的に行うべき処理について，当該情報処理装置が電源ＯＦＦの間にあっても行うことができ，実際にメール受信を行うなど，情報処理装置による動作が必要な場合にのみ，情報処理装置の電源をＯＮにし，動作を行わせることができる。
＜実施例９＞

本実施例は，実施例２と実施例６を組み合わせたものの変形例である。ハードウェア構成はインテリジェントＮＩＣ２５０１と同一なので説明しない。図３１に本実施例におけるソフトウェア機能について説明する。

図３１を参照して，ＤＨＣＰクライアント部３１０１が，追加されている。このＤＨＣＰクライアント部３１０１は，実施例２のＤＨＣＰクライアント部１１０３とは動作が若干異なる。実施例２では，ＤＨＣＰサーバより取得したＩＰアドレスのリース時間の終了が到来する前に，ＤＨＣＰクライアント部１１０３が自発的にＤＨＣＰサーバに対し，リース時間の延長を要求していた。これに対し本実施例では，リース時間の終了が迫ると，リース時間の延長を行わず，情報処理装置を起動させる。これにより，リース時間の延長を情報処理装置自身に行わせる。また，ＩＰアドレス及びリース時間の取得は，ＤＨＣＰサーバからだけでなく，ＤＨＣＰサーバよりＩＰアドレス及びリース時間が付与された情報処理装置からも取得することができる。本実施例では情報処理装置から取得する場合を説明する。

図３２を参照して，本実施例の動作フローを説明する。
なお，電源確認タスク(ｂ)の動作は，実施例８と同一であるため説明を省略し，メインタスク(ａ)のみを説明する。

ステップ３２０１において，ＤＨＣＰクライアント部３１０１は，情報処理装置よりＩＰアドレスおよびリース時間の取得を行う。

ステップ３００７において，情報処理装置電源確認部２９０３が，情報処理装置の電源状態を確認し，電源がＯＮであれば，ブリッジ動作部２７０５を起動(ステップ３０１９)させ，そうでなければ，処理がステップ３２０３に進む。

ステップ３２０３において，ＤＨＣＰクライアント部３１０１は，ステップ３２０１で取得したＩＰアドレスのリース終了時間が近いかどうかを判断する。なお，近いかどうかの判断は，全リース時間の５０％経過時など，任意に設定可能である。判断の結果，近いと判断されれば，情報処理装置を起動(ステップ３０１７)させ，そうでなければ，処理が３００７に戻る。

本実施例によれば，本来，情報処理装置が行うべき処理について，インテリジェントＮＩＣ２５０１がそのタイミングを監視し，必要に応じて情報処理装置を起動するため，本当に必要なタイミング以外は，情報処理装置の電源をＯＦＦにしておくことができる。
＜総括＞

以上説明した実施例の通り，本発明に係る装置およびモジュールによる省電力機構は，図３３に示す４つのパターンがある。

図３３を参照して，省電力支援機構を実施するトリガは，大別すると２つになる。一つは受動的トリガであり，もう１つは能動的トリガである。受動的トリガとは，省電力支援装置がネットワークを介して受信した何らかの通信をトリガとして，代理応答などを行うことである。一方，能動的トリガとは，本来，情報処理装置が行わなければならない処理を，省電力支援装置が自身の判断で実施を決定し，実施するものである。

対応動作としては，代理と起動があり，代理とは，本来，省電力支援装置が組み込まれる母体である情報処理装置が行わなければならない処理を，省電力支援装置がこれに成り代わって処理することである。一方，起動とは，こういった処理を情報処理装置にさせるべく，省電力支援装置が省電力状態にある情報処理装置を起動させることである。
なお，図３３には，それぞれのパターンに対応する開示実施例を記載した。

従来技術における，ネットワーク環境図である 実施例１における，ネットワーク環境図である 実施例１における，代理サーバのハードウェア構成図である 実施例１における，代理サーバのソフトウェア機能ブロック図である 実施例１における，代理サーバの動作フローである 実施例１における，代理サーバのシーケンス図である 実施例１において，代理サーバが代理応答時に送信するデータである 実施例１において，代理サーバの代理応答時にＰＣに表示される画面である 実施例１における，代理サーバのシーケンス図である 実施例２における，ネットワーク環境図である 実施例２における，代理サーバのソフトウェア機能ブロック図である 実施例２における，代理サーバのシーケンス図である 実施例３における，代理サーバのハードウェア構成図である 実施例３における，ネットワーク環境図である 実施例３における，サーバのＰＷＲＳＷ端子である 実施例３における，代理サーバのソフトウェア機能ブロック図である 実施例４における，ネットワーク環境図である 実施例４における，代理サーバの管理するテーブルである 実施例４における，代理サーバの動作概念図である 実施例４における，代理サーバの動作フローである 実施例５における，ネットワーク環境図である 実施例５における，代理サーバのハードウェア構成図である 実施例５における，代理サーバのソフトウェア機能ブロック図である 実施例５における，代理サーバの動作フローである 実施例６における，ネットワーク環境図である 実施例６における，代理サーバのハードウェア構成図である 実施例６における，代理サーバのソフトウェア機能ブロック図である 実施例７における，ネットワーク環境図である 実施例８における，装置のソフトウェア機能ブロック図である 実施例８における，装置の動作フローである 実施例９における，装置のソフトウェア機能ブロック図である 実施例９における，装置の動作フローである 本発明で開示される省電力機構の分類図

１０７ サーバ
１０９ ネットワーク
２０１ 代理サーバ
４０３ サーバ電源確認部
４０７ 代理応答部
４１１ ブリッジ動作部
１００１ ＤＨＣＰサーバ
１１０１ ＤＨＣＰサーバ部
１１０３ ＤＨＣＰクライアント部
１３０１ スイッチ回路
１８０１ サーバ情報管理テーブル
２３０３ ＨＴＴＰプロキシ動作部
２５０１ インテリジェントＮＩＣ
２６１１ スイッチ回路
２６１３ ＰＣＩ ｅｘｐｒｅｓｓＩ／Ｆ
２７０５ ブリッジ動作部

Claims (5)

1. 省電力支援モジュールによる情報処理装置の省電力化を支援する方法であって，
   前記情報処理装置が省電力状態である場合において，前記情報処理装置が稼働状態時であればこれによって行われるべき処理を前記情報処理装置自身に実行させるべく，前記省電力支援モジュールが，所定のトリガに基づいて前記情報処理装置を省電力状態から起動させるステップを含む方法。
2. 前記所定のトリガは，所定のＤＨＣＰサーバによって前記情報処理装置に付与されているＩＰアドレスにおけるリース時間の終了までの残存時間が所定の時間となったことを前記省電力支援モジュールが検知したことであり，且つ，前記行われるべき処理は，前記情報処理装置が前記所定のＤＨＣＰサーバに前記リース時間の延長を要求することである，請求項１に記載の方法。
3. 前記所定のトリガは，所定の時刻において前記省電力支援モジュールが所定のメールサーバにアクセスし，当該所定のメールサーバにおいて前記情報処理装置が受信すべきメールの存在を前記省電力支援モジュールが検知したことであり，且つ，前記行われるべき処理は，前記所定のメールサーバより前記受信すべきメールを前記情報処理装置が受信することである，請求項１に記載の方法。
4. 前記省電力支援モジュールによる前記検知は，前記省電力支援モジュール自身によって行われる時間管理に基づくものである，請求項２に記載の方法。
5. 前記所定の時刻は，前記省電力支援モジュール自身によって行われる時間管理に基づくものである，請求項３に記載の方法。