JP2015114878A - 通信装置、通信制御方法、プログラム及び記憶媒体 - Google Patents

Abstract

【課題】通信サービスやオペレーティングシステムが通信処理中にスリープ状態に遷移すると返信パケットが破棄され通信エラーが発生する場合がある。通信処理がアイドル状態においても適切にスリープ状態に遷移可能な通信装置を提供する。
【解決手段】電力モードを通常稼働モードから省電力モードへ遷移する前にサービスアプリケーション部へ電力モードの遷移予告を通知する省電力制御部と、保持するユーザリクエストの状態を検出するサービスアプリケーション部と、ユーザリクエストの状態を処理中と判定した場合、省電力制御部に省電力モードへ遷移遅延要求を送信するサービスアプリケーション部と、省電力制御部の指示により情報処理装置を省電力モードへ遷移を制御する電力制御部を備える。
【選択図】 図４

Description

本発明は、ネットワーク処理を行うための通信装置およびその制御方法に関する。

ネットワーク（イントラネット、インターネットなどのＬＡＮ）に接続されて用いられるＰＣ（パーソナルコンピュータ）やサーバ、プリンタやＭＦＰなど、様々な通信装置が知られている。

近年、これらの通信装置では機器が動作していない時に消費電力を削減する省電力の要求が強まっている。

しかし、特に通信サービスを提供する通信サーバにおいて省電力を実現するためには、必要最低限のCPUやメモリ、外部記憶装置の利用を行うため、通信遅延や通信エラーが発生する場合がある。

このため、省電力を実現しながら通信遅延や通信エラーの発生しにくい通信装置が求められている。

通信処理プログラムにおいて、TCP/IPのプロトコルスタックに対し、通信パラータを調整するように指示する事で省電力中の通信装置とエラーの発生しにくい通信処理が行える提案がなされている（特許文献１参照）。

省電力状態に移行した通信装置に対して、省電力状態に移行してない別の通信装置が代理応答、代行処理を行うことにより省電力を保持しつつエラーの発生しにくい通信処理が行える提案がなされている（特許文献２参照）。

機器の電源制御と構成要素に関してACPI(Advanced Configuration & Power Interface)が規格化されている（非特許文献１参照）。

特表２００８−５００２８５号公報 特開２００２−２９７３５２号公報

ACPI Advanced Configuration & Power Interface (URL: http://www.acpi.info/)

上記従来例では、通信要求元となる通信クライアントの通信処理プログラムにおいて、TCP/IPのプロトコルスタックの通信パラータを調整するため、省電力となる通信サーバとは別に、通信クライアントでの処理が必要となる。

また、刻々と変わる通信サーバの状態に応じて通信クライアントが通信パラメータを決定するため、パラメータの適切な値を決定する事が困難であり、通信パラメータの値によっては通信サーバの消費電力を削減できない場合がある。

また、省電力状態に移行した通信装置に対して、省電力状態に遷移してない別の通信装置が代理応答を行うことにより通信サーバの消費電力を削減しつつエラーの発生しにくい通信処理を行う通信装置をでは、代理応答、代行処理を行う通信装置が必要となる。

本発明の目的は、サーバが通信処理中に省電力状態へ遷移する場合においても、ユーザリクエストに関連する通信処理が終了するまで適切なスリープ遅延を行うことである。
また、サーバの消費電力を削減しつつ、従来技術の問題点である通信エラーの発生し難い通信装置を提供することにある。

本願発明の特徴は、サーバＰＣの通信サービスが、従来技術の問題点である外部の通信装置の処理に頼ることなく、適切なスリープ遅延を行うことで、サーバの消費電力を削減しつつ、通信エラーの発生し難い通信装置を提供することにある。

本願発明は通信サービスが通信処理中に、オペレーティングシステム、または、サーバサービスが省電力状態へ遷移する場合に適用される。

電力消費を制御する電力消費制御手段（４０８）を有する情報処理装置（１０２）と、
電力消費制御手段を制御する省電力制御手段（４０５）を有するオペレーティングシステム（４０４）と、
前記オペレーティングシステム（４０４）においてサービスを提供可能なサービス制御手段（４０６）と、
前記サービス制御手段（４０６）においてネットワークを介してサービスを提供可能なサービス手段（４００）を有するシステムにおける省電力制御方法であって、
前記省電力制御手段（４０５）が前記電力消費制御手段（４０８）を用いて電力モードを通常稼働モードから省電力モードへ遷移する前に、サービス手段（４００）へ電力モードの遷移予告を通知する第１のステップと、
前記サービス手段（４００）が、保持するユーザリクエスト（４０３）の状態を検出する第２のステップと、
前記サービス手段（４００）がユーザリクエストの状態を処理中と判定した場合、前記サービス手段（４００）は前記省電力制御手段に省電力モードへ遷移遅延要求を送信する第３のステップと、
前記サービス手段（４００）がユーザリクエストの状態を完了と判定した場合に、前記サービス手段（４００）は前記省電力制御手段（４０５）に省電力モードへ遷移通知を送信する第４のステップと、
前記省電力制御手段（４０５）の指示により電力消費制御手段（４０８）が、前記情報処理装置を省電力モードへ遷移を制御する第５のステップを有することを特徴とする。

本発明によって、 サーバが通信処理中に省電力状態へ遷移する場合においても、ユーザリクエストに関連する通信処理が終了するまで適切なスリープ遅延を行うことで、省電力状態への遷移時の通信エラーが発生し難い通信システムを提供することが可能となる。
また、サーバの消費電力を削減可能な通信装置を提供する事ができる。

さらに、サーバＰＣの通信サービスが、従来技術の問題点である外部の通信装置の処理に頼ることなく、適切なスリープ遅延を行うことで、サーバの消費電力を削減しつつ、通信エラーの発生し難い通信装置を提供することが可能となる。

さらに、サーバＰＣの通信サービスが、ＵＤＰの返信パケット待ちなど、通信処理がアイドル状態の場合においても、オペレーティングシステムがスリープ状態へ遷移することによる通信エラーが発生し難い通信システムを提供できる。

本発明の構成例を示す図である。 本発明の実施例に係るクライアントＰＣ、サーバＰＣであるホストコンピュータの構成例を示す。 本発明の実施例に係るプリンタであるＭＦＰの構成例を示す。 本発明の実施例に係る通信装置であるサーバＰＣの構成例を示す。 本発明の実施例１に係るサーバＰＣの処理フローチャートである。 本発明の実施例１に係るサーバＰＣの処理フローチャートである。 本発明の実施例１に係るクライアントＰＣ、サーバＰＣ、プリンタのシーケンス例を示す。 本発明の実施例１に係るサーバＰＣのユーザリクエスト管理部が保持するユーザリクエスト例を示す。 本発明の実施例１に係るサーバＰＣのユーザリクエスト管理部が保持するトランザクション例を示す。

以下、本発明を実施するための最良の形態について図面を用いて説明する。
尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

本発明の実施例に係る通信装置について説明する。

［実施例］
図１は、本発明の実施の形態に係る通信装置の利用環境を説明するシステム構成例を示す図である。

尚、本発明の機能が実現されるのであれば、クライアントＰＣ１０１および、サーバＰＣ１０２でのプログラムの動作を、プリンタやＭＦＰ（マルチファンクションペリフェラル）上のＣＰＵ、ＲＡＭ，ＲＯＭで実行しても良いことは言うまでもない。

このシステムは、本発明の通信装置であるサーバＰＣ（１０２）がネットワーク（１００）に接続されている。さらに、通信回線、ネットワーク（１００）を介して、クライアントＰＣ（１０１）、プリンタ（１０３）が接続されている。

クライアントＰＣ（１０１）、サーバＰＣ（１０２）、プリンタ（１０３）は、ネットワーク（１００）において他の通信装置と通信を行うためにＩＰアドレスを保持している。サーバＰＣ（１０２）は、クライアントＰＣ（１０１）からのリクエストに応答するサービスを提供している。サーバPCが提供するサービスとしては、例えば、プリントサーバやWeb、 DNS、メール、SNMPエージェント、WS-Eventing（非特許文献２を参照）のサーバ機能などがある。

また、サーバＰＣ（１０２）は、クライアントＰＣ（１０１）からのリクエストに応じて、さらに別のサーバに通信を行う事もある。サーバＰＣ（１０２）がプリントサーバの場合、クライアントＰＣ（１０１）からの印刷リクエストやプリンタ情報取得リクエストをプリンタ（１０３）に送信する。

プリンタ（１０３）では、プリントサーバ機能（LPD：RFC 1179）やサーバＰＣ（１０２）と同様に各種リクエストに応答するサービスを提供している。サービスとしては、例えば、Web、 ファイル、SNMP、WS-Eventingなどのサーバ機能などがある。

なお、本発明においては、サーバPCが提供するサービスについて、アドレスを利用する通信であれば、IPv4やIPv6などのプロトコルも含め、プロトコルを限定するものではない。また、実施例以外のネットワークデバイス、情報処理装置、通信装置が接続されていても良いことはもちろんである。

また、クライアントＰＣ１００および、サーバＰＣ１０５間の接続方式が、ＬＡＮ，ＷＡＮ以外のネットワークや、ＩＥＥＥ８０２．１１などの無線ＬＡＮなどの接続方式も、本発明を適用できることは言うまでもない。

図２は、クライアントＰＣ１０１および、サーバＰＣ１０２であるホストコンピュータの構成例を示す図である。

ホストコンピュータ２００において、ＣＰＵ１はシステムバス４に接続された各デバイスを統括的に制御する中央処理装置である。このＣＰＵ１は、ＲＯＭ３のプログラム用ＲＯＭ或いは外部メモリ（ＨＤ）１１に記憶されたアプリケーション（文書処理プログラム等）に基づいて、図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理等の各種処理を実行する。

またＣＰＵ１は、例えばＲＡＭ２上に設定された表示ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴＣ（表示制御部）６を介して表示部１０に表示する。

更に、ＣＰＵ１は、この表示部１０上のマウスカーソル（図示略）等で指示されたコマンドに基づいて、登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザはクライアントアプリケーション１０１やサーバアプリケーション１０８を使用する際、その設定などの操作に関するウインドウを開き、設定を行うことができるようになっている。尚、表示部１０はＣＲＴに限らず、液晶やプラズマ等でも良い。

ＲＡＭ２はＣＰＵ１の主メモリ、ワークエリア等として機能する。ＲＯＭ３はフォント用ＲＯＭ（不図示）、プログラム用ＲＯＭ（不図示）と、データ用ＲＯＭ（不図示）などを備えている。

フォント用ＲＯＭ或いは外部メモリ１１は、上記文書処理等の際に使用するフォントデータ等を記憶する。

プログラム用ＲＯＭ或いは外部メモリ１１は、ＣＰＵ１の制御プログラムであるオペレーティングシステム（以下、ＯＳ）等を記憶する。

データ用ＲＯＭ或いは外部メモリ１１は、上述の文書処理等を行う際に使用する各種データを記憶する。又外部メモリ１１に記憶されているプログラムは、実行時にＲＡＭ２に展開されて実行される。

キーボードコントローラ（ＫＢＣ）５は、キーボード９やポインティングデバイス（不図示）からの入力情報を制御する。ＣＲＴＣ６は、表示部１０への表示を制御する。ディスクコントローラ（ＤＫＣ）７は、外部メモリ１１とのアクセスを制御する。ネットワークコントローラ（ＮＷＣ）８は、双方向性インターフェース２１を介してネットワーク１０６に接続されている。

キーボード９は、各種キーを備えている。表示部１０は、図形、イメージ文字、表等を表示する。外部メモリ１１はハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）等から構成されている。この外部メモリ１１は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル等を記憶する。

図３は、図１のプリンタ１０３の構成例を示す図である。なお本例のプリンタ１０３には、印刷機能を提供するプリンタの他、印刷、スキャナ、FAXなどの複合機能を提供する複合機（MFP）とした場合も同様に適用可能とする。
本例では一般的なMFPの構成例を示す。

フィーダ３００（原稿自動送り部）は、スキャナ部３０１でスキャンニングを行う際に自動で紙を送る機構である。原稿のスキャナ部３０１は、紙の情報をスキャニングして電子化を行う。

ＵＩ部３０２は、MFPの操作入力操作を受け付ける、情報を表示する機構である。給紙部３０３は印刷の際に印刷用紙を定着部３０４に送る機構である。定着部３０４は給紙部３０３から送られてきた用紙にトナーを定着させて印刷を行う機構である。排紙部３０５は定着部３０４にて印刷された用紙を排紙する機構である。

フィニッシング装置３０６は排紙部３０５から排紙された紙を発注情報に従ってステープルやパンチといった処理を行う機構である。そして排紙トレイ３０７は最終的に印刷・フィニッシングされた印刷物を保持するトレイとなる。

図４は、本実施例に係るサーバＰＣ１０２の構成を説明するブロック図である。サーバＰＣ１０２において、サービスアプリケーション部（４００）は、クライアントＰＣ１０１で動作するアプリケーションが送信した送信データを処理し、処理結果をクライアントアＰＣ１０１で動作するアプリケーションに返信する。

サービスアプリケーション部（４００）が提供するサービスとしては、例えば、Ｗｅｂサーバ、メールサーバ、ＤＮＳサーバ、プリントサーバなどが提供される。

サービスアプリケーション部（４００）は、サーバＰＣ（１０２）のオペレーティングシステム部（４０４）上で動作する。

サービスアプリケーション部（４００）は、オペレーティングシステム部（４０４）が提供するサービス制御部（４０６）によって管理される。サービス制御部（４０６）は、サービスアプリケーション部（４００）の登録、削除を行う。また、サービス制御部（４０６）はサービスアプリケーション部（４００）の停止、開始、スリープ指示などの状態変更を行う。

サービス制御部（４０６）は、複数のサービスアプリケーション部（４００）を管理することが可能である。

一般にサービスアプリケーション部（４００）は、クライアントＰＣ１０１上のアプリケーションが送信した送信データを処理し、処理結果をクライアントアＰＣ１０１で動作するアプリケーションに返信する。

クライアントＰＣ１０１上のアプリケーションは、サービスを提供するサーバＰＣ（１０２）のＩＰアドレスおよび、サービスアプリケーション部（４００）が作成した通信ソケットのポート番号を指定することで特定のサービスアプリケーションと通信を行う。

また、サービスアプリケーション部（４００）は、提供するサービスに応じて他のサーバと通信を行い、その処理結果をクライアントＰＣ１０１上のアプリケーションに対して返信する場合がある。

たとえば、Ｗｅｂサーバの場合は、クライアントからの処理依頼であるユーザリクエストに対して、データベースサーバに問い合わせを行い、その処理結果をクライアントに返信する。また、プリントサーバの場合は、クライアントからの印刷指示に従い、印刷データをプリンタに送信する。また、クライアントからのプリンタ情報取得指示や状態変化イベントなどのユーザリクエストに対し、その結果をクライアントに返信する。

本実施例においては、サービスアプリケーション部（４００）はクライアントからのプリンタ情報取得指示や状態変化イベントなどを返信するプリンタ双方向通信サービスの一例を示す。

サービスアプリケーション管理部（４０１）は、サービスアプリケーション部（４００）の主処理部である。サービス制御部（４０６）からのサービス停止や開始などの制御処理、及び、提供するサービスの管理を行う。

提供するサービスの管理としては、クライアントからのプリンタ情報取得指示や状態変化イベントなどユーザリクエスト管理、ユーザリクエストを処理するプリンタとの双方向通信によるプリンタ情報取得やプリンタの状態遷移イベント処理などを行う。

サービスアプリケーション管理部（４０１）は外部との通信処理はオペレーティングシステムの提供する通信制御部４０７を介して行う。ユーザリクエスト管理部（４０２）は、クライアントからのユーザリクエストの管理を行う。ユーザリクエストのデータ例としては、リクエストのＩＤである管理番号、リクエスト処理内容である処理識別ＩＤ、ユーザリクエストの処理状態を示す通信処理状態、ユーザリクエストの送信元アドレス（クライアント識別）である通信要求元アドレス、ユーザリクエストの処理対象アドレス（プリンタ識別）である通信要求先、が含まれる。

ユーザリクエスト管理部（４０２）は、サービスアプリケーション管理部（４０１）が通信制御部４０７を介して受信したユーザリクエストの管理を行う。

ユーザリクエスト管理部（４０２）は、処理中のユーザリクエストをユーザリクエストデータ部４０３で記憶する。

ユーザリクエストのリストの一例を図８に示す。ユーザリクエストデータ（４０３）は、ユーザリクエスト管理部（４０２）の処理中のユーザリクエストを記憶する。

オペレーティングシステム部（４０４）は、サーバＰＣ（１０２）のオペレーションシステムである。近年、情報処理装置であるサーバＰＣ１０２上で複数のオペレーティングシステを稼動するオペレーティングシステの仮想化が一般化しており、サーバＰＣ１０２上で複数のオペレーティングシステを稼動する場合も本実施例に含まれる。

省電力制御部（４０５）は、オペレーティングシステム部（４０４）の機能の一部でありオペレーティングシステム部（４０４）およびサービスアプリケーション部（４００）の電力制御を行う。

省電力制御部（４０５）は、オペレーティングシステム部（４０４）やサービスアプリケーション部（４００）の実行中のプロセスを監視し、それらのアイドル状態の判定を行いスリープなどの省電力状態への通知や省電力状態への稼動状態遷移を行う。

サービス制御部（４０６）は、複数のサービスアプリケーションを管理する。サービス制御部（４０６）は、サービスアプリケーション部（４００）の登録、削除を行う。また、サービスアプリケーション部（４００）の停止、開始、スリープ指示などの状態変更を行う。また、サービスアプリケーション部（４００）へそれらの状態変更通知を行う。

通信制御部（４０７）は、オペレーティングシステム部（４０４）の機能の一部であり、各種のサービスアプリケーションの通信制御を行う。

電力制御部（４０８）は、電源ユニットの通常稼働モードや省電力モードの電源処理を行う。電源ユニットやオペレーティングシステム部（４０４）との制御インターフェースとしてＡＣＰＩなどの統一規格がある（非特許文献１）。

通信部（４０９）は、ネットワークインターフェースであり、オペレーティングシステム部（４０４）のデバイスドライバを介してサービスアプリケーション部（４００）が通信を行う。

サーバＰＣ（１０２）は、通信部（４０９）を介してクライアントPC１０１やプリンタ１０３と通信を行う。

図５は、サーバＰＣ（１０２ ）のサービスアプリケーション部（４００）における処理フローである。サーバのサービスが通信処理中に省電力状態へ遷移する場合に、ユーザリクエストに関連する通信処理が終了するまで適切なスリープ遅延を行うことで消費電力を削減しつつ、省電力状態への遷移時に通信エラーが発生し難い通信処理方法を以下に説明する。

サービスアプリケーション部（４００）のサービスアプリケーション管理部（４０１）はステップＳ５０１で、オペレーティングシステム（４０４）の省電力制御部（４０５）からスリープ移行通知を取得する。

サービスアプリケーション管理部（４０１）がスリープ移行通知を取得する方法として、省電力制御部（４０５）に対して、状態遷移イベントを取得できるようにイベント登録を行う方法がある。

また、他の方法としてブロードキャストメッセージとして受信する方法、ポーリングで情報を取得するなど考えられる。また、省電力制御部（４０５）からではなくサービスアプリケーション部（４００）を管理しているサービス制御部（４０６）から情報を取得する方法もある。

スリープ移行通知の内容としては、オペレーティングシステム（４０４）や情報処理装置の仕様に応じて、状態遷移する予定のスリープの詳細な情報が取得できる場合がある。
例えば、ACPIのSystem sleeping states S1, S2, S3, S4, S5に対応した状態が取得できる。

ステップＳ５０２で、サービスアプリケーション部（４００）のサービスアプリケーション管理部（４０１）はユーザリクエスト管理部（４０２）の保持するユーザリクエストデータ（４０３）を取得する。

ユーザリクエストデータ（４０３）は、クライアントＰＣ（１０１）からサーバＰＣ（１０２ ）のサービスアプリケーション部（４００）への処理中の要求であるユーザリクエストのリストを記憶している。

ステップＳ５０３で、サービスアプリケーション管理部（４０１）は処理中のリクエストがあるか判定を行う。処理中のユーザリクエストの判定方法については、後述する図６で説明する。

サーバＰＣ（１０２）のサービスアプリケーション部（４００）が、ＵＤＰプロトコルによる通信の返信パケット待ちなど、アイドル状態の場合においても、通信状態を判定することでオペレーティングシステムのスリープ状態遷移を遅延させる事が可能となる。

よって、スリープ状態へ遷移による通信エラーが発生し難い通信システムを提供できる。特に、ＵＤＰ通信の場合は、ＴＣＰ通信のセッション確立が無いため、ＵＤＰ通信の処理内容および対応する返信パケットを判定することにより現在の通信状態が判定することが可能である。

また、ＴＣＰ通信においても、セッションが切断されているが一連の通信を行っている場合を判定することによって、通信状態が判定可能となる。

ステップＳ５０３において、処理中のユーザリクエストがあると判定された場合は、ステップＳ５０４の処理を行う。無いと判定された場合は、ステップＳ５０７の処理を行う。

ステップＳ５０３において、処理中のユーザリクエストがあると判定された場合は、ステップＳ５０４において、サービスアプリケーション管理部（４０１）は省電力制御部にスリープ移行遅延を通知する。

続いてステップＳ５０５において、サービスアプリケーション管理部（４０１）は処理中のユーザリクエストの完了を待つ。そのため、サービスアプリケーション管理部（４０１）は既定時間経過後にユーザリクエストキューのリスト再取得をおこなう。

ステップＳ５０６で、サービスアプリケーション管理部（４０１）はユーザリクエスト処理のタイムアウト判定を行う。ステップＳ５０５において、サービスアプリケーション管理部（４０１）が取得したユーザリクエストの状態が通信処理中のままで、既定時間経過後でも応答がない場合は通信エラーなどの理由によりタイムアウトと判定しステップS５０７に進む。

ステップＳ５０６で、サービスアプリケーション管理部（４０１）はユーザリクエスト処理のタイムアウト判定を行いユーザリクエストの状態が通信処理中のままで、既定時間経過後でも応答がない場合は通信エラーなどの理由によりタイムアウトと判定する。

ステップＳ５０６でサービスアプリケーション管理部（４０１）がユーザリクエスト処理をタイムアウトと判定した場合、または、ステップS５０３で処理中のリクエストが無いと判断した場合、ステップＳ５０７でサービスアプリケーション管理部（４０１）は省電力制御部（４０５）にスリープ移行を通知する。

続いて、ステップＳ５０８で、省電力制御部（４０５）が電力制御部（４０８）にスリープ移行を通知する。電力制御部（４０８）は省電力制御部（４０５）が指定したACPIのSystem sleeping states S1, S2, S3, S4, S5に対応した状態に遷移させる。このため、情報処理装置は省電力モードに移行する。

図６は、ステップＳ５０３における、サーバＰＣ（１０２ ）のサービスアプリケーション管理部（４０１）の詳細な判定処理フローである。ステップＳ６０１で、サービスアプリケーション管理部（４０１）は、ユーザリクエスト管理部（４０２）の記憶するユーザリクエストデータ（４０３）の通信方式などを取得する。

ユーザリクエストとして、リクエストのＩＤである管理番号（８０１）、リクエスト処理内容である処理識別ＩＤ（８０２）、ユーザリクエストの処理状態を示す通信処理状態（８０３）、ユーザリクエストの送信元アドレス（クライアント識別）である通信要求元アドレス（８０４）、ユーザリクエストの処理対象アドレス（プリンタ識別）である通信要求先（８０５）、を取得する。

ステップＳ６０２では、サービスアプリケーション管理部（４０１）がステップＳ６０１で取得した通信方式の判定を行う。通信方式として、先ずTCPか判定を行う。通信方式としてTCPの通信の場合はステップＳ６０３に進む。また、通信方式としてTCP以外の通信の場合はステップＳ６０５に進む。

全ステップ（ステップＳ６０２）でTCP通信と判定された場合、ステップＳ６０３で、サービスアプリケーション管理部（４０１）はTCPセッションがまだ確立されているか判定を行う。

さらに、ステップＳ６０３で、TCPセッションが確立されていると判定された場合は、通信処理中と判定し、ステップＳ６０４で、サービスアプリケーション管理部（４０１）は通信処理中のリクエストと判定する。

ステップＳ６０２で、通信方式としてTCP以外の通信と判定した場合は、ステップＳ６０５で、サービスアプリケーション管理部（４０１）はプリンタ（１０３）への送受信パケットから通信処理状態を判定する。

ステップＳ６０５では、サービスアプリケーション管理部（４０１）がプリンタ（１０３）への送信したパケットに対して、受信パケットの有無から通信処理状態を判定する。

一般にUDPプロトコルやTCPプロトコルの送受信時にコネクションが切断される通信では、送信プロトコルと受信プロトコルに同一の一意のID（リクエストID）を付加することで送信パケットに対応する返信パケットを識別できる。

次のステップＳ６０６およびステップＳ６０７では、OSI参照モデル レイヤ5のセッション層のコネクションの確立開始から切断完了までを一連の処理として通信中として判定する例を示す。

ステップＳ６０６で、サービスアプリケーション管理部（４０１）はユーザリクエストがイベント登録中か判定を行い、登録中の場合は通信処理中と判断する。

例えば、通信データとして、WS-Eventing （Web Services Eventing、URL: http://www.w3.org/Submission/WS-Eventing/）のSubscribe をサーバＰＣ（１０２）からプリンタ（１０３）に送信した場合、一連のユーザリクエスト処理として、TCPプロトコル上のWS-EventingのSubscribeを送信し、プリンタ（１０３）の状態遷移イベントを取得開始してから、TCPプロトコル上のWS-EventingのUnsubscribeを送信し、プリンタ（１０３）の状態遷移イベント取得を終了するまでをあらわす。

この例では、WS-EventingのSubscribeからUnsubscribeまでがOSI参照モデル(OSI Reference Model) レイヤ5のセッション層のコネクションの確立開始から切断完了までを意味する。

イベント登録中のユーザリクエストの一例を図9に示す。ステップＳ６０７で、サービスアプリケーション管理部（４０１）はユーザリクエストが一連のトランザクションを処理中かを判定する。

例えば、通信データとして、SNMPにおけるGetNextRequestコマンドを実行する場合、情報取得対象のOID（Object Identifier）と関連するテーブルエントリーのOIDも連続取得する事が可能である。

この場合、GetNextRequestで連続するOIDが取得できている間は関連するテーブルエントリーと判定できるため、一連の処理として通信中として判定する。

イベント登録中のユーザリクエストの一例を図9に示す。ステップＳ６０８で、サービスアプリケーション管理部（４０１）は通信処理中のリクエストが無いと判定する。ステップＳ６０９で、サービスアプリケーション管理部（４０１）がプリンタ（１０３）へ送信したパケットに対して、リクエストIDが同一の返信パケットが既定時間内に取得できない場合、送信パケットがタイムアウトしたと判定する。

ステップＳ６１０で、サービスアプリケーション管理部（４０１）は、一定時間後に再度リクエストIDが同一の返信パケットをオペレーティングシステムの通信制御部４０７から取得する。

このステップＳ６０１からステップＳ６１０の処理は、ユーザリクエストデータ（４０３）が複数存在する場合は、全てのユーザリクエストデータの通信処理が終わる事を待つ。

図７は、本発明の実施例に係るクライアントＰＣ（１０１）、サーバＰＣ（１０２）、プリンタ（１０３）のシーケンス例を示す。ステップＰ７０１で、クライアントＰＣ（１０１）上のアプリケーションは、サービスを提供するサーバＰＣ（１０２）のＩＰアドレスおよび、サービスアプリケーション部（４００）のポート番号を指定してサービスアプリケーションと通信を開始する。

ステップＰ７０２で、サーバＰＣ（１０２）のサービスアプリケーション部（４００）はプリンタ（１０３）に送信する。送信するデータはクライアントＰＣ（１０１）上のアプリケーションからのユーザリクエストを、サービスアプリケーション部（４００）が処理して作られたデータを送信する。

例えば、ステップＰ７０１で、クライアントＰＣ（１０１）上のアプリケーションがプリンタの状態取得のユーザリクエストに対して、サービスアプリケーション部（４００）は、プリンタ（１０３）に対して状態取得を行う。

ステップＰ７０３で、プリンタ（１０３）はステップＰ７０２の返信処理を行う。プリンタ（１０３）は処理結果の返信パケットをサーバＰＣ（１０２）に対してステップＰ７０７で送信する。

この間（ステップＰ７０３からステップＰ７０７の間）、サーバＰＣ（１０２）において、ステップＰ７０４で、サーバＰＣ（１０２）の省電力制御部（４０５）がオペレーティングシステムやサービスアプリケーションのアイドル状態を検出し、省電力モードへの移行を判定する。

このため、省電力制御部（４０５）がサービス制御部（４０６）を経由してサービスアプリケーション部（４００）に対して、スリープ（スリープ予告）を通知する。

ステップＰ７０５で、サービスアプリケーション管理部（４０１）は処理中のユーザリクエストがあると判定する。

ステップＰ７０６で、サービスアプリケーション管理部（４０１）は処理中のユーザリクエストがあると判定（ステップＰ７０５）したために、省電力制御部にスリープ移行遅延を通知する。

ステップＰ７０７で、プリンタ（１０３）はサーバＰＣ（１０２）に対してステップＰ７０３の処理結果を返信する。

ステップＰ７０８で、サーバＰＣ（１０２）のサービスアプリケーション部（４００）はステップＰ７０７の返信データ、または、返信データから加工したデータをクライアントＰＣ（１０１）上のアプリケーションに返信する。

ステップＰ７０９で、クライアントＰＣ（１０１）はステップＰ７０１の返信データを受信する。このデータは、ステップＰ７０８のサービスアプリケーション部（４００）が送信したデータである。

ステップＰ７１０で、サービスアプリケーション管理部（４０１）はユーザリクエストの処理状態を確認して処理完了後、または、処理のタイムアウト後に省電力制御部（４０５）に「スリープ許可」を通知する。

ステップＰ７１１で、省電力制御部（４０５）が電力制御部（４０８）にスリープ移行を通知する。このため、電力制御部（４０８）は省電力制御部（４０５）が指定したACPIのSystem sleeping states S1, S2, S3, S4, S5に対応した状態に遷移し、情報処理装置は省電力モードに移行する。

図８は、ユーザリクエスト管理部（４０２）の記憶するユーザリクエストデータ（４０３）の一例を示す。ユーザリクエスト管理部（４０２）は、処理中のユーザリクエストをユーザリクエストデータ部４０３で記憶する。

ユーザリクエストのデータ例として、リクエストのＩＤである管理番号（８０１）、
リクエスト処理内容である処理識別ＩＤ（８０２）、ユーザリクエストの処理状態を示す通信処理状態（８０３）、ユーザリクエストの送信元アドレス（クライアント識別）である通信要求元アドレス（８０４）、ユーザリクエストの処理対象アドレス（プリンタ識別）である通信要求先（８０５）、が含まれる。

ユーザリクエスト管理部（４０２）は、サービスアプリケーション管理部（４０１）が通信制御部４０７を介して受信したユーザリクエストの管理を行う。

図９は、ユーザリクエスト管理部（４０２）の記憶する一連のユーザリクエスト処理の一例を示す。

ここで一連のユーザリクエスト処理とは、OSI参照モデル レイヤ5のセッション層のコネクションの確立開始から切断完了までを意味する。ユーザリクエスト管理部（４０２）は、これらの通信内容（９０１）の処理は関連したユーザリクエストとして処理を行う。

一連のユーザリクエスト処理例として、通信内容（９０１）、送信データ属性１（９０２）、送信データ属性１（９０３）、が含まれる。

例えば、通信データとして、WS-EventingのSubscribe をサーバＰＣ（１０２）からプリンタ（１０３）に送信した場合の一連のユーザリクエスト処理としては、WS-EventingのSubscribeを送信して、プリンタ（１０３）の状態遷移イベントを取得開始してから、WS-EventingのUnsubscribeを送信し、プリンタ（１０３）の状態遷移イベント取得を終了するまでをあらわす。

この例では、WS-EventingのSubscribeからUnsubscribeまでがOSI参照モデル(OSI Reference Model) レイヤ5のセッション層のコネクションの確立開始から切断完了までを意味する。

また、OSI参照モデル レイヤ5のセッション層のコネクションの確立開始から切断完了までを一連の処理として通信中として判定する別の例を以下に示す。

通信データとして、SNMPにおけるGetNextRequestコマンドを実行する場合、情報取得対象のOID（Object Identifier）と関連するテーブルエントリーのOIDも連続取得する事が可能である。

この場合、GetNextRequestで連続するOIDが取得できている間は関連するテーブルエントリーと判定できるため、一連の処理として通信中として判定する。

図9に示される一連の処理の管理テーブルはステップＳ６０６、ステップＳ６０７の判定で利用される。

図9に示される一連の処理の管理テーブルは、実施の一例であり、一般的にOSI参照モデル レイヤ5のセッション層以上の論理通信経路の確立開始から切断完了までを通信処理中と判定する。

このため、OSI参照モデル レイヤ４のトランスポート層のコネクションの確立開始から切断完了までの期間に限定するものではない。

以上説明した本実施例によれば、サーバが通信処理中に省電力状態へ遷移する場合においても、ユーザリクエストに関連する通信処理が終了するまで適切なスリープ遅延を行うことで、従来技術の問題点である省電力状態への遷移時の通信エラーが発生し難い通信システムを提供可能となる。

さらに、スリープ時の通信が可能でありながら消費電力を削減可能な通信装置を提供する事ができる。

さらに、サーバＰＣの通信サービスが、従来技術の問題点である外部の通信装置の処理に頼ることなく、適切なスリープ遅延を行うことで、サーバの消費電力を削減しつつ、通信エラーの発生し難い通信装置を提供することが可能となる。

さらに、サーバＰＣの通信サービスが、ＵＤＰの返信パケット待ちなど、通信処理がアイドル状態の場合においても、オペレーティングシステムがスリープ状態へ遷移することによる通信エラーが発生し難い通信システムを提供できる。

［他の実施形態］
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良い。

また仮想化ＯＳなどで構成される場合も含めて一つの機器からなる装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウエアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。

さらには、画像形成装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ、DVD-RAM）などである。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。

つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してDVD−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

１００ ネットワーク
１０１ クライアントＰＣ
１０２ サーバＰＣ
１０３ プリンタ
４００ サービスアプリケーション部
４０１ サービスアプリケーション管理部
４０２ ユーザリクエスト管理部
４０３ ユーザリクエストデータ
４０４ オペレーティングシステム部
４０５ 省電力制御部
４０６ サービス制御部
４０７ 通信制御部
４０８ 電力制御部
４０９ 通信部

Claims (10)

1. 電力消費を制御する電力消費制御手段（４０８）を有する情報処理装置（１０２）と、
   電力消費制御手段を制御する省電力制御手段（４０５）を有するオペレーティングシステム（４０４）と、
   前記オペレーティングシステム（４０４）においてサービスを提供可能なサービス制御手段（４０６）と、
   前記サービス制御手段（４０６）においてネットワークを介してサービスを提供可能なサービス手段（４００）を有するシステムにおける省電力制御方法であって、
   前記省電力制御手段（４０５）が前記電力消費制御手段（４０８）を用いて電力モードを通常稼働モードから省電力モードへ遷移する前に、サービス手段（４００）へ電力モードの遷移予告を通知する第１のステップと、
   前記サービス手段（４００）が、保持するユーザリクエスト（４０３）の状態を検出する第２のステップと、
   前記サービス手段（４００）がユーザリクエストの状態を処理中と判定した場合、前記サービス手段（４００）は前記省電力制御手段に省電力モードへ遷移遅延要求を送信する第３のステップと、
   前記サービス手段（４００）がユーザリクエストの状態を完了と判定した場合に、前記サービス手段（４００）は前記省電力制御手段（４０５）に省電力モードへ遷移通知を送信する第４のステップと、
   前記省電力制御手段（４０５）の指示により電力消費制御手段（４０８）が、前記情報処理装置を省電力モードへ遷移を制御する第５のステップを有することを特徴とする省電力制御方法。
2. 前記サービス手段（４００）は、通信処理中のユーザリクエスト（４０３）が存在する場合に、ユーザリクエストの状態を処理中と判定することを特徴とする請求項１に記載の省電力制御方法。
3. 前記サービス手段（４００）は、前記通信処理中の判定として、ユーザリクエスト（４０３）の通信処理状態が
   ・ TCPのセッションの確立開始から切断完了まで
   ・ UDPのパケット送信から対応する返信パケットの受信完了、または受信タイムアウトまで
   ・ TCPまたはUDPパケットでイベント登録からイベント削除まで
   ・ OSI参照モデル レイヤ5のセッション層以上のコネクションの確立開始から切断完了まで
   ・ TCPまたはUDPパケットで一連のトランザクション処理中のいずれかの場合は処理中と判定することを特徴とする請求項１又は請求項２に記載の省電力制御方法。
4. 前記ユーザリクエスト（４０３）には、通信要求元、通信要求先、通信内容、通信処理状態が含まれることを特徴とする請求項１乃至請求項３の何れか１項に記載の省電力制御方法。
5. 前記情報機器（１０２）の電力消費制御手段（４０８）は、前記オペレーティングシステム（４０４）または前記サービス手段（４００）をスリープまたはスタンバイまたは休止またはシャットダウンの省電力モードに遷移可能であることを特徴とする請求項１乃至請求項４の何れか１項に記載の省電力制御方法。
6. 前記情報機器（１０２）の電力消費制御手段（４０８）は、ACPI(Advanced Configuration & Power Interface)を制御することを特徴とする請求項１乃至請求項５の何れか１項に記載の省電力制御方法。
7. 前記情報機器（１０２）の省電力モードは、ACPIのSystem sleeping states S1, S2, S3, S4, S5のいずれかであることを特徴とする請求項１乃至請求項６の何れか１項に記載の省電力制御方法。
8. 前記情報機器（１０２）がプリントサーバであることを特徴とする請求項１乃至請求項７の何れか１項に記載の省電力制御方法。
9. 前記サービス手段（４００）がプリンタドライバの双方向通信サービスであることを特徴とする請求項１乃至請求項８の何れか１項に記載の省電力制御方法。
10. 請求項９に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。