(57)【特許請求の範囲】
【請求項１】
データ処理装置であって、
ネットワークを介して受信されるパケットを監視し、前記ネットワークを介して受信した前記パケットがオペレーティングシステムによって応答されるべきパケットかどうかを判断する監視手段と、
前記オペレーティングシステムが前記ネットワークを介して受信した前記パケットへ応答することができなくなる省電力状態への移行を制御する省電力制御手段と、を有し、
前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させる前に受信したパケットが、前記監視手段によって、前記オペレーティングシステムによって応答されるべきパケットであると判断された場合、前記監視手段は、所定時間の間、前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させるのを制限し、前記所定時間が経過した後に、前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させるのを許可することを特徴とするデータ処理装置。
【請求項２】
前記監視手段は、ＩＣＭＰパケットの受信を監視することを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
前記監視手段は、パケットソケットを使用して、前記オペレーティングシステムによって応答されるべきパケットの受信を監視することを特徴とする請求項１に記載のデータ処理装置。
【請求項４】
前記監視手段は、
前記ネットワークを介してパケットを受信したと判断すると、前記省電力制御手段に前記省電力状態への移行不可を示す情報を送信し、
前記パケットが、前記オペレーティングシステムによって応答されるべきパケットでないと判断すると、前記省電力制御手段に前記省電力状態への移行不可を解除する情報を送信し、
前記パケットが、前記オペレーティングシステムによって応答されるべきパケットであると判断すると、前記所定時間の経過後に、前記省電力制御手段に前記省電力状態への移行不可を解除する情報を送信する、ことを特徴とする請求項１に記載のデータ処理装置。
【請求項５】
前記監視手段は、前記ネットワークを介して受信されるパケットを解析して、前記パケットが前記オペレーティングシステムによって応答されるべきパケットかどうかを判断する、ことを特徴とする請求項１乃至４の何れか１項に記載のデータ処理装置。
【請求項６】
前記監視手段は、前記ネットワークを介して受信されるパケットに含まれるプロトコル種別を示す情報に基づいて、前記パケットが前記オペレーティングシステムによって応答されるべきパケットかどうかを判断する、ことを特徴とする請求項５に記載のデータ処理装置。
【請求項７】
前記監視手段は、前記ネットワークを介して受信されるパケットに含まれるポート番号を示す情報に基づいて、前記パケットが前記オペレーティングシステムによって応答されるべきパケットかどうかを判断する、ことを特徴とする請求項５に記載のデータ処理装置。
【請求項８】
前記監視手段は、前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させる条件を満たした後であって前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させる前に受信したパケットを監視する、ことを特徴とする請求項１乃至７の何れか１項に記載のデータ処理装置。
【請求項９】
データ処理装置の省電力制御方法であって、
前記データ処理装置の監視手段が、ネットワークを介して受信されるパケットを監視し、前記ネットワークを介して受信した前記パケットがオペレーティングシステムによって応答されるべきパケットかどうかを判断する監視工程と、
前記データ処理装置の省電力制御手段が、前記オペレーティングシステムが前記ネットワークを介して受信した前記パケットへ応答することができなくなる省電力状態への移行を制御する省電力制御工程と、を有し、
前記省電力制御工程が前記データ処理装置を前記省電力状態に移行させる前に受信したパケットが、前記監視工程で、前記オペレーティングシステムによって応答されるべきパケットであると判断された場合、前記監視工程は、所定時間の間、前記省電力制御工程が前記データ処理装置を前記省電力状態に移行させるのを制限し、前記所定時間が経過した後に、前記省電力制御工程が前記データ処理装置を前記省電力状態に移行させるのを許可することを特徴とするデータ処理装置の省電力制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理装置及びその省電力制御手法に関し、詳細には省電力状態に移行する際の処理に関するものである。
【背景技術】
【０００２】
従来、装置の省電力を図る技術として、例えば所定時間データが入力されない等の所定条件を満足すると、装置を省電力状態に移行する技術が知られている。例えば、特許文献１の発明では、予め設定された設定時間の間に、外部からの要求が入力されないと、装置の制御部が省電力状態に移行するように制御している。この省電力状態では、制御部のＣＰＵへの電力供給が制限され、ＣＰＵは通信処理を行わなくなる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２５２１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
コンピュータ機器などで、上述の省電力制御をオペレーティングシステムとは異なるソフトウェアが行っている場合に、以下のような状況が起こりうる。即ち、コンピュータ機器が外部装置からデータを受信し、そのデータがオペレーティングシステムによって応答すべきデータである場合、オペレーティングシステムはデータに対する応答をしようとする。しかし、このとき、上記のソフトウェアがそのことを知らずに、省電力状態に移行する条件が満足されると、コンピュータ機器を省電力状態に移行してしまう。これにより、オペレーティングシステムが、そのデータに対する応答をできないまま、コンピュータ機器が省電力状態に移行してしまうことが考えられる。
【０００５】
本願発明の目的は、上記従来技術の問題点を解決することにある。
【０００６】
本願発明の特徴は、オペレーションシステムの通信を監視して省電力を制御することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明の一態様に係るデータ処理装置は以下のような構成を備える。即ち、
データ処理装置であって、
ネットワークを介して受信されるパケットを監視し、前記ネットワークを介して受信した前記パケットがオペレーティングシステムによって応答されるべきパケットかどうかを判断する監視手段と、
前記オペレーティングシステムが前記ネットワークを介して受信した前記パケットへ応答することができなくなる省電力状態への移行を制御する省電力制御手段と、を有し、
前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させる前に受信したパケットが、前記監視手段によって、前記オペレーティングシステムによって応答されるべきパケットであると判断された場合、前記監視手段は、所定時間の間、前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させるのを制限し、前記所定時間が経過した後に、前記省電力制御手段が前記データ処理装置を前記省電力状態に移行させるのを許可することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、オペレーティングシステムがデータへの応答をできないまま省電力状態に移行するのを防止できるという効果がある。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に係る通信システムの全体図。
【図２】本実施形態に係る画像形成システムの構成を説明するブロック図。
【図３】ＭＦＰのソフトウェアの構成を説明するブロック図。
【図４】実施形態に係る監視アプリケーションとＯＳとの関係を説明するブロック図。
【図５】実施形態に係るＭＦＰによる処理を説明するフローチャート。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。尚、以下の実施形態では、データ処理装置としてＭＦＰ（多機能処理装置）を例に説明するが、本発明はこれに限らず、通信装置、ＰＣなどの情報処理装置或いは、表示装置や印刷装置などにも適用可能である。
【００１１】
図１は、本発明の実施形態に係る通信システムの全体図である。
【００１２】
ＭＦＰ（複合機）１００は、ＮＩＣ１０１（ネットワークインターフェースカード）を介してＬＡＮ１０３に接続されている。ＬＡＮ１０３は一般的なＬＡＮであるものとし、例えばイーサネット（登録商標）であるものとする。その他、無線ＬＡＮなどであってもよい。また本実施形態には直接関係しないため図示していないが、ＬＡＮ１０３にはＰＣ１０２の他にも複数のＰＣ（パーソナルコンピュータ）が接続されているものとする。ＭＦＰ１００とＮＩＣ１０１とはＰＣＩバス等のコンピュータ用拡張バスアーキテクチャによって接続されており、その外観は一台の機器として見える。そのためＭＦＰ１００とＮＩＣ１０２をここでは画像形成システム１０４と呼ぶ。
【００１３】
図２は、本実施形態１に係る画像形成システム１０４の構成を説明するブロック図である。
【００１４】
ＮＩＣ１０１は、インテリジェント型ネットワークカードモジュールにより実現された、ＭＦＰ１００に着脱可能なネットワークインターフェース装置である。そして、ＮＩＣ１０１は、ＮＩＣ１０１用のＣＰＵ２０１，ＲＡＭ２０２，ＲＯＭ２０３，ネットワークＩ／Ｆ２０４，ＬＥＤ２０５，拡張Ｉ／Ｆ２０６と、これらを互いに接続するシステムバス２０７とを備えている。ＣＰＵ２０１は、ＲＯＭ２０３に記憶された制御プログラムに従って各種制御処理を実行する。例えば、ＣＰＵ２０１は、システムバス２０７に接続されたネットワークＩ／Ｆ２０４を介してＬＡＮ１０３に接続し、更にＬＡＮ１０３を介してＬＡＮ１０３上のＰＣ１０２と所定の通信プロトコルに従って通信する。これにより、例えばＰＣ１０２から送信された印刷データや印刷制御命令等の各種データを受信し、拡張Ｉ／Ｆ２０６を介してＭＦＰ１００に転送し、ＭＦＰ１００において印刷処理を行うことができる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＬＥＤ２０５は、ＮＩＣ１０１の動作状態を示す表示部として用いられている。ＬＥＤ２０５は、例えば、ネットワークＩ／Ｆ２０４とＬＡＮ１０３との電気的な接続状態や通信モード等の各種動作状態をＬＥＤの色や点滅パターンで示すことができる。拡張Ｉ／Ｆ２０６は、ＮＩＣ１０１とＭＦＰ１００とを接続するためのＩ／Ｆであり、前述したようにＰＣＩ(Peripheral Component Interconnect)バスに接続されている。
【００１５】
次にＭＦＰ１００の構成を説明する。
【００１６】
ＭＦＰ１００は、制御部２２０、操作部２３０、スキャナ部２４０及びプリンタ部２５０を備えている。制御部２２０には、ＭＦＰ１００用のＣＰＵ２２１，ＲＡＭ２２２，ＲＯＭ２２３，拡張Ｉ／Ｆ２２４，操作部Ｉ／Ｆ２２５，デバイスＩ／Ｆ２２６と、これらを互いに接続するシステムバス２２７とが備えられている。ＣＰＵ２２１は、ＲＯＭ２２３に記憶された制御プログラムを読み出して各種制御処理を実行する。例えば、ＣＰＵ２２１は、拡張Ｉ／Ｆ２２４を介してＮＩＣ１０１から転送される印刷データに基づいて印刷用画像データを生成し、デバイスＩ／Ｆ２２６を介してプリンタ部２５０に出力して印刷する。ＲＡＭ２２２は、ＣＰＵ２２１の主メモリ、ワークエリア等を提供している。またＲＡＭ２２２は、図示しない増設ポートに接続されるオプションＲＡＭにより、そのメモリ容量を拡張することができる。操作部２３０には、ＭＦＰ１００の動作モード等の設定や印刷データの取り消し等の操作を行うためのボタンと、ＭＦＰ１００の動作状態を示す液晶パネルやＬＥＤ等の表示部等が配されている。また、後述する通信モードの設定も操作部２３０を介して行うことができる。プリンタ部２５０は、公知の印刷技術を利用したプリンタであり、例えば電子写真方式やインクジェット方式、昇華方（熱転写）方式等で画像データの印刷を実行する。またスキャナ部２４０は原稿の画像を読み取って画像データを生成し、ＭＦＰ１００に入力する。尚、ＭＦＰ１００は、スタンバイ時よりも消費電力が小さい省電力状態を備えている。以下では、省電力状態の一例としてディープスリープを説明する。ディープスリープ中は、特定のユニット（操作部２３０や拡張Ｉ／Ｆ２２４など）を除く各ユニットに対する電力供給を停止することにより、消費電力を減少させている。
【００１７】
電源ＯＮ／ＯＦＦ部２７０は、電源装置２６０から供給される電力を、ライン２８１及びライン２８２を介して各ユニットに供給する。ディープスリープ状態では、電源ＯＮ／ＯＦＦ部２７０は、電力をライン２８２を介して供給するものの、ライン２８１による電力供給を停止する。またディープスリープ状態ではないときは、電源ＯＮ／ＯＦＦ部２７０は、ライン２８１及び２８２の両方を介して電力を供給する。尚、電源ＯＮ／ＯＦＦ部２７０は、印刷時にはプリンタ部２５０に電力を供給し、スキャン時にはスキャナ部２４０に電力を供給するが、図２ではその図示を省略する。
【００１８】
またＣＰＵ２２１は、ライン２９１を介して電源ＯＮ／ＯＦＦ部２７０に制御信号を送信することにより、電源ＯＮ／ＯＦＦ部２７０を制御する。また、ＮＩＣ１０１のＣＰＵ２０１は、ライン２９２を介して制御信号を電源ＯＮ／ＯＦＦ部２７０に送信することにより、電源ＯＮ／ＯＦＦ部２７０を制御する。
【００１９】
図３は、ＭＦＰ１００のソフトウェアの構成を説明するブロック図である。
【００２０】
ＮＩＣドライバ３００は、ＮＩＣ１０１を制御するデバイスドライバである。ＭＦＰ１００上で動作する各種のソフトウェアがＮＩＣ１００を制御する場合には、このＮＩＣドライバ３００を介して行われる。プロトコルスタック３０１は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰやＩＣＭＰ等の一般的なＬＡＮで使用されるプロトコルをサポートしている。ソケットＡＰＩ３０２は、ＯＳ（オペレーティングシステム）が提供する一般的なソケットＡＰＩである。
【００２１】
Ｗｅｂサーバアプリケーション３０３は、Ｗｅｂサーバとしての動作を行う。ジョブ受信アプリケーション３０４は、ＮＩＣ１０１が受信した印刷ジョブを受け取る。例えばＰＣ１０２が画像形成システム１０４に対して送信した印刷ジョブは、ＬＡＮ１０３を経由してジョブ受信アプリケーション３０４が受信する。監視アプリケーション３０５は、プロトコルスタック３０１自身が通信を行う際に、その通信データを監視する。スリープ制御アプリケーション３０６は、ディープスリープへの移行処理を制御しており、前述したアプリケーション群３０３〜３０５に対して、定期的にディープスリープへの移行の可否を問い合わせる。この問い合わせを受けた各アプリケーションは、予め定められたディープスリープ移行条件を満たしていれば移行可能を示す情報を返信し、その移行条件を満たしていなければ移行不可を示す情報を返信する。スリープ制御アプリケーション３０６は、問い合わせ先の全てのアプリケーションからスリープ移行可能を示す情報を受信すると、画像形成システム１０４をディープスリープへ移行させる。ディープスリープへの移行処理では、スリープ制御アプリケーション３０６は電源ＯＮ／ＯＦＦ部２７０へ制御信号を送信する。
【００２２】
本実施形態では、一般的なそれと同じく、プロトコルスタック３０１及びソケットＡＰＩ３０２をＯＳと定義する。そしてＯＳとＮＩＣドライバ３００がカーネルスペースで動作しているものとする。それ以外のアプリケーション群（３０３〜３０６）は、アプリケーションスペースで動作しているものとする。尚、本実施形態では特に説明しないが、これら以外にも、画像形成システムとして動作するための多数のアプリケーションが、このＭＦＰ１００のユーザスペースで動作しているものとする。
【００２３】
次に図４のソフトウェアブロック図を参照して、監視アプリケーション３０５が、ＯＳ自身が実行するネットワーク通信を監視する際の処理について説明する。ここで監視アプリケーション３０５が監視の対象とするネットワーク通信とは、一般的にＯＳ自身が機能として備えているプロトコルであり、例えば、ＩＣＭＰなどが対象となる。
【００２４】
図４は、監視アプリケーション３０５とＯＳとの関係を説明するブロック図である。
【００２５】
課題は、画像形成システム１０４がＬＡＮ１０３上のＰＣ１０２からＩＣＭＰプロトコルのパケット（例えば、ＰＩＮＧ）を受信した際にディープスリープに移行した場合に発生する。詳しくは、プロトコルスタック３０１がＩＣＭＰパケットを解析中、或いはＩＣＭＰパケットへの応答処理中に画像形成システム１０４がディープスリープに移行してしまうと、解析または応答処理が中断されるため、応答パケットがＬＡＮ１０３に送出されない。
【００２６】
そのため本実施形態では、監視アプリケーション３０５がＩＣＭＰパケットの送受信の状況を監視して、プロトコルスタック３０１がＩＣＭＰパケットの処理中であった場合にはディープスリープに移行させないようにしている。監視アプリケーション３０５は、ＰＦ＿ＰＡＣＫＥＴと呼ばれるタイプのソケットを使用して動作している。これは別名でパケットソケットと呼ばれ、デバイスドライバレベルでのパケットを送受信することを可能にするソケットである。デバイスドライバレベルでのパケットは、ＯＳＩ参照モデルのレイヤ２でのパケットの送受信が可能であり、これはイーサネットフレームのデータを全て送受信できることを意味する。つまりＰＦ＿ＰＡＣＫＥＴを使用したソケットを用いることにより、ＮＩＣドライバ３００を経由する全てのネットワークフレームをネットワークインタフェースレベルで監視することが可能になる。
【００２７】
次に図５のフローチャートを参照して、監視アプリケーション３０５が実際にパケット監視を行って省電力制御を行う際の処理の流れについて説明する。
【００２８】
図５は、実施形態に係るＭＦＰ１００による処理を説明するフローチャートである。この処理を実行するプログラムはＲＯＭ２２３に記憶されており、ＣＰＵ２２１の制御の下に実行される。
【００２９】
ここで、スリープ制御アプリケーション３０６は、例えば所定時間の間、所定のデータ（パケット）が入力されない等の、スリープモードに移行するための所定の条件が満足されるかどうかをチェックしている。そして、この所定の条件が満足されると、このＭＦＰ１００をスリープモードに移行させる。このとき、監視アプリケーション３０５からスリープ移行不可を示す情報を受信すると、例え、上記所定の条件が満足されていても、スリープ移行不可が解除されるまではスリープモードへの移行を行わないように動作することを前提としている。
【００３０】
まずＳ５０１で、監視アプリケーション３０５が前述したようにパケットソケットを用いてポートの監視を開始する。次にＳ５０２に進み、監視アプリケーション３０５が、パケットの受信があったかどうかを判定する。ここでパケットの受信があったと判定するとＳ５０３に進み、監視アプリケーション３０５は、スリープ制御アプリケーション３０６に対してスリープ移行不可を示す情報を送信する。これにより、スリープ制御アプリケーション３０６は、スリープに移行しないように振舞う。またＳ５０３で、受信されたパケットを解析する。そしてＳ５０４で、その受信されたパケットが、ＯＳが処理すべきものか、或いはアプリケーションが処理するべきものかを判別する。この判別は、パケットデータに含まれるプロトコル種別を示す情報や、ポート番号を示す情報を参照することで行う。Ｓ５０４で、ＯＳが処理すべきパケットでないと判定するとＳ５０６に進むが、ＯＳが処理すべきパケットであると判定するとＳ５０５に進む。Ｓ５０５では、監視アプリケーション３０５は、予め定められた時間（ここでは３００ｍｓ）だけ待つ（ウェイトする）。即ち、スリープモードに入るまでの時間を延長する。このウェイト後にＳ５０６に進み、スリープ制御アプリケーション３０６に対してスリープ移行不可を解除する情報を送信する。これにより、スリープ制御アプリケーション３０６は、画像形成システム４をディープスリープ状態に移行させるのを延期する。なお、スリープ移行不可を解除する情報は、スリープ移行不可からスリープ移行可能への変更を示す情報であっても、単に、スリープ移行可能を示す情報であってもよい。
【００３１】
以上説明したように、ＯＳが処理すべきパケットの受信を検知したときは、一定時間待機した後、スリープへの移行が可能であることを通知することにより、スリープ状態に入る前に、ＯＳがそのパケットの処理を確実に行うことができる。
【００３２】
以上説明したように本実施形態によれば、アプリケーションスペースで動作するソフトウェアモジュールが、カーネルスペースで動作するＯＳが行う通信を監視し、ＯＳの通信状況を考慮してスリープ移行の可否の判断を行うことができる。これにより、ＯＳ自体に手を加えることなく、ＯＳが通信している最中にディープスリープモードに入ってしまうという課題を解決することが可能になる。
【００３３】
またカーネルがオープンソースソフトウェアを用いてソフトウェアを作成する場合でも、アプリケーションスペースで動作するため、開示の必要がないという利点がある。
【００３４】
（その他の実施例）
図５のＳ５０５では、監視アプリケーション３０５は、予め定められた時間だけ待つ。予め定められた時間だけ待つことに代えて、パケットの処理が完了するのを待ってもよい。
【００３５】
図５のＳ５０４では、監視アプリケーション３０５は、受信されたパケットがＯＳによって処理されるべきものかを判別した。しかしながら、Ｓ５０４の判別を省略してもよい。つまり、パケットの受信があった場合には、ＯＳが処理すべきパケットを受信した可能性があると判断して、ＯＳが処理すべきパケットの受信を検知したとみなす。
【００３６】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
0005763934.tif 000002
【図２】
0005763934.tif 000003
【図３】
0005763934.tif 000004
【図４】
0005763934.tif 000005
【図５】
0005763934.tif 000006