JP2012118635A

JP2012118635A - データ処理装置、データ処理装置の制御方法及びプログラム

Info

Publication number: JP2012118635A
Application number: JP2010265745A
Authority: JP
Inventors: Hidenori Yokokura; 秀則横倉
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-11-29
Filing date: 2010-11-29
Publication date: 2012-06-21
Anticipated expiration: 2030-11-29
Also published as: JP5704904B2; US8732497B2; CN102594584B; CN102594584A; US20120137150A1

Abstract

【課題】装置の消費電力を低減することと、ネットワーク上の他の装置からのデータやコマンドに対して適切に応答できることの両立を図る。
【解決手段】データ処理装置は、少なくとも第一の状態と、当該第一の状態よりも消費電力が少ない第二の状態で動作し、前記第二の状態で動作中にネットワークから受信するデータであって、当該第二の状態から前記第一の状態に移行することなく応答を行うべき特定のデータを示す情報を保持する。前記第一の状態で動作中にネットワークから受信したデータが、前記保持手段によって保持された情報が示す特定のデータであるか否かを判断し、特定のデータであると判断された場合は特定のデータでないと判断された場合よりも早く、前記受信したデータに応答した後に前記第一の状態から前記第二の状態に移行する。
【選択図】図６

Description

本発明は、第一の状態とそれよりも消費電力が少ない第二の状態の少なくとも何れかの状態で動作するデータ処理装置、データ処理装置の制御方法及びプログラムに関する発明である。

印刷装置や複写装置などのデータ処理装置において、装置の消費電力を低減する要求が高まっている。その要求に対する対策として、データ処理装置が待機状態の時に、データ処理装置を制御する主制御部への電力供給を通常より低減（あるいは遮断）してスリープ状態に移行することによって、消費電力を更に低減する技術が知られている。

また、ネットワークに接続可能なデータ処理装置が一般的になっている。このようなデータ処理装置は、ＰＣ等の情報処理装置からネットワークを介してデータやコマンドを受信して処理することで、様々な処理を実行することができる。

しかしながら、このようなデータ処理装置に上述した消費電力を更に低減する技術を採用した場合、データ処理装置がスリープ状態の時にネットワークを介して受信したデータやコマンドの処理を早急に行えないという問題が発生してしまう。なぜなら、スリープ状態においてデータやコマンドをネットワークを介して受信しても主制御部が動作していないため、主制御部への電力供給が再開して待機状態となるまでは、データやコマンドの処理が停滞してしまうからである。以下、ネットワークを介してデータやコマンドを受信した際に、主制御部への電力供給を再開して待機状態となることを、ＷＯＬ（ＷａｋｅｏｎＬＡＮ）と呼ぶ。

このような問題により、ＳＮＭＰ等のデバイス管理を行うためのプロトコルで用いられるネットワークパケットに対して、応答が遅延したり正しく応答できない場合があった。その結果、ＳＮＭＰ等のプロトコルを用いてデバイスを管理するＰＣ側のユーティリティソフトでは、正しいデバイスの管理ができないことがあった。特に、一旦ＷＯＬして待機状態になり、データやコマンドを処理した後にすぐにまたスリープ状態に移行してしまうと、その後連続して送られたデータやコマンドに対して応答できない場合がある。そこで、一旦ＷＯＬした後は、一定時間の間、スリープ状態に移行しないように制御する方法が考えられている。

また、特許文献１のように、主制御部への電力供給を遮断した後も電力が供給される副制御部を備え、スリープ状態中に受信したデータやコマンドに対して副制御部が代理で応答する代理応答の技術も考えられている。特許文献１の方法では、スリープ状態に移行した後も電力が供給されている処理部が備えるメモリに、代理応答パターン記憶領域や代理応答データ記憶領域を備え、これらのデータを用いて代理応答を行っている。

特開２００９−１５１５３７

一旦ＷＯＬした後は一定時間の間スリープ状態に移行しないように制御することを、全てのデータやコマンドに対して行った場合には、次の問題がある。即ち、データ処理装置に対してデータやコマンドを送信する装置がネットワーク上に多数存在した場合、データ処理装置が一向にスリープ状態に移行できなくなる。

一方で、上記特許文献１の技術を用いて、全てのデータやコマンドに対して代理応答を行うようにすることは、装置の消費電力を低減するという観点から現実的ではない。なぜなら、その場合には代理応答パターン記憶領域や代理応答データ記憶領域のメモリ容量が膨大になり、結果的にスリープ状態中でも大きな電力を消費してしまうことになるからである。

本発明はこれらの問題に対してなされたものであり、装置の消費電力を低減することと、ネットワーク上の他の装置からのデータやコマンドに対して適切に応答できることの両立を図ることを目的とする。

上記目的を達成するために本発明のデータ処理装置は、少なくとも第一の状態と、当該第一の状態よりも消費電力が少ない第二の状態で動作するデータ処理装置であって、前記第二の状態で動作中にネットワークから受信するデータであって、当該第二の状態から前記第一の状態に移行することなく応答を行うべき特定のデータを示す情報を保持する保持手段と、前記第一の状態で動作中にネットワークからデータを受信する受信手段と、前記受信手段によって受信されたデータが、前記保持手段によって保持された情報が示す特定のデータであるか否かを判断する判断手段と、前記判断手段によって特定のデータであると判断された場合は特定のデータでないと判断された場合よりも早く、前記受信したデータに応答した後に前記第一の状態から前記第二の状態に移行するよう制御する制御手段とを有することを特徴とする。

本発明によれば、装置の消費電力を低減することと、ネットワーク上の他の装置からのデータやコマンドに対して適切に応答できることの両立を図ることができる。

本発明の実施形態におけるデバイス装置を使用したネットワークシステムの構成を示す図。本発明の実施形態におけるデバイス装置内のハードウェア構成を示すブロック図。本発明の実施形態におけるデバイス装置内のソフトウェア構成を示すブロック図。本発明の実施形態における復帰／代理応答情報管理部によって管理されるテーブルを示す図。本発明の実施形態におけるホストコンピュータとデータ処理装置間の通信シーケンスを示す図。本発明の実施形態におけるデータ処理装置の通常状態における動作を示したフローチャート。本発明の実施形態におけるＳＯＡＰメソッドとそれに対するレスポンスの一例を示す図。本発明の実施形態におけるデータ処理装置の通常状態における動作を示したフローチャート。

（実施形態１）
以下、本発明を実施するための最良の形態について図面を用いて説明する。

図１は、本発明の実施形態１におけるデータ処理装置を使用したネットワークシステムの構成を示す図である。データ処理装置１−１とホストコンピュータ１−２、１−３、１−４、１−５がネットワーク１−６を介して接続され、相互に通信可能となっている。データ処理装置１−１は、プリンタやスキャナ、複写機やＦＡＸ、複合機等の装置である。本実施形態におけるデータ処理装置は、第一の状態と、第一の状態よりも消費電力が少ない第二の状態といった、少なくとも二つの電力状態で動作する（これ以外の電力状態で動作してもよい）ことができるようになっている。それぞれの電力状態において電力が供給される箇所については後述する。以降の説明では、第二の状態をスリープ状態と呼び、第一の状態を通常状態と呼ぶ。

ホストコンピュータは情報処理装置の一例で、携帯端末等のその他の装置であっても構わない。このホストコンピュータは、一般的なユーザが使用するパーソナルコンピュータであったり、ネットワーク上の端末を管理する管理装置としてのサーバであったりする。またネットワーク１−６はＬＡＮやインターネット、無線ネットワークであっても構わない。

図２は、本実施形態におけるデータ処理装置内のハードウェア構成を示すブロック図である。

データ処理装置１−１はＭａｉｎＣＰＵ２−１が制御する主制御部２−７と、ＳｕｂＣＰＵ２−８が制御する副制御部２−１１を持ち、主制御部２−７と副制御部２−１１はＰＣＩバスにより接続されている。主制御部２−７は読取制御部２−４や印刷制御部２−５を制御し、データ処理装置としてコピー、印刷といった機能を実現する。これらの機能を制御するプログラムはＲＯＭ２−２やＨＤＤ２−６に格納されており、データ処理装置が起動した時にＲＡＭ２−３に読み込まれ、ＭａｉｎＣＰＵ２−１により実行される。

副制御部２−１１はネットワーク制御部２−１２とネットワーク２−１５を介してネットワークパケットの送受信を行ったり、データ処理装置がスリープ状態に移行した後に通常状態への復帰制御を行うための機能を実現したりする。これらの機能を制御するプログラムはＲＯＭ２−９に格納されており、データ処理装置が起動した時にＲＡＭ２−１０に読み込まれ、ＳｕｂＣＰＵ２−８により実行される。後述するようにデータ処理装置が省電力状態から復帰するための条件となる情報は主制御部２−７から副制御部２−１１に送信され、ＲＡＭ２−１０に格納される。電源制御部２−１３は、データ処理装置１−１の各ブロックへの電力供給を制御する。特に、主制御部２−７への電力供給を停止することによって、データ処理装置を通常状態から省電力状態に移行させ、装置全体としての消費電力を抑えることが可能である。

図３は、本実施形態におけるデータ処理装置のソフトウェア構成を示すブロック図である。

図３（ａ）は本実施形態のデータ処理装置内の主制御部２−７のソフトウェア構成を示すブロック図である。各ブロックはすべてＭａｉｎＣＰＵ２−１により並行して実行される。ＳＮＭＰやＳＯＡＰ等のパケットを制御する通常制御部３（ａ）−１は、通常状態時のデータ処理装置としての各種動作を制御する。復帰／代理応答情報管理部３（ａ）−３はスリープ状態から通常状態へ復帰する条件についての情報をＲＯＭやＨＤＤ等の記憶部に保持する。スリープ制御部３（ａ）−２は、復帰／代理応答情報管理部３（ａ）−３によって保持された復帰／代理応答条件情報を取得しＭａｉｎ−ＳｕｂＣＰＵ通信部３（ａ）−４に送信した後、電源制御部２−１３にスリープ状態への移行を指示する。Ｍａｉｎ−ＳｕｂＣＰＵ通信部３（ａ）−４は、Ｓｕｂ−Ｍａｉｎ通信部３（ｂ）−１と通信を行い、副制御部２−１１との情報の送受信を行う。

図３（ｂ）は本実施形態のデータ処理装置内の副制御部２−１１のソフトウェア構成を示すブロック図である。各ブロックはすべてＳｕｂＣＰＵ２−８により並行して実行される。Ｓｕｂ−ＭａｉｎＣＰＵ通信部３（ｂ）−１はＭａｉｎ−Ｓｕｂ通信部３（ａ）−４と通信を行い、主制御部２−７との情報の送受信を行う。復帰／代理応答情報保持部３（ｂ）−２は復帰／代理応答情報管理部３（ａ）−３からＳｕｂ−ＭａｉｎＣＰＵ通信部３（ｂ）−１を介して復帰／代理応答条件情報を受信してＲＡＭ等の記憶部に保持する。復帰／代理応答判定部３（ｂ）−３はネットワーク送受信部３（ｂ）−５から受信したパケットを解析し、復帰／代理応答情報保持部３（ｂ）−２によって保持されている情報に基づき通常状態へ復帰させるか、代理応答させるかどうかを判定する。また復帰／代理応答判定部３（ｂ）−３は、特定のパケットパターンであれば、代理応答を行い、それ以外の自機宛のパケットであれば、復帰判定を行う。

通常状態においては、ネットワーク送受信部３（ｂ）−５が受信したパケットはそのままＳｕｂ−ＭａｉｎＣＰＵ通信部３（ｂ）−１を介して主制御部２−７に渡される。一方スリープ状態においてはネットワーク送受信部３（ｂ）−５が受信したパケットは、復帰／代理応答判定部３（ｂ）−３に渡される。３（ｂ）−４は、代理応答をする判定となった時に、代理応答のパケットパターンを生成し、ネットワーク送受信部３（ｂ）−５にて、ホストコンピュータに送信される。代理応答をする判定となった場合、即ち代理応答する場合には、スリープ状態から通常状態に移行することなく、受信したパケットに対する応答が行われる。

図４は、本実施形態のデータ処理装置がスリープ状態時に代理応答すべきデータの内容を示すテーブルである。図４のテーブルは、復帰／代理応答情報管理部３（ａ）−３によってＲＯＭ２−２又はＨＤＤ２−６に格納されている。また、復帰／代理応答情報保持部３（ｂ）−２によってＲＡＭ２−１０に格納されている。図４の例では、ＳＮＭＰにおけるＭＩＢのオブジェクト名４−１とＯＩＤ（ＯｂｊｅｃｔＩＤ）４−２が記述されている。このテーブルの場合、データ処理装置は、スリープ状態中にこのテーブルに記述されたＯＩＤが指定されたＳＮＭＰのコマンドを受信した場合、ＷＯＬすることなく副制御部２−１１が前述の代理応答を行う。

なお、本発明は図４のオブジェクト名、ＯＩＤのみに限定されるものではなく、また、テーブルに登録されるＯＩＤのセットは図４に例示した１セットだけではなく、複数のセットがあってもかまわない。また、一つのセットに含まれる個々のＯＩＤは固定的ではなく、動的に追加されてもよい。また、４−１のオブジェクト名がなく、４−２のＯＩＤだけがデータとして格納されてもかまわないし、その逆であってもよい。図４の例に示したＯＩＤは、一般的なＰＣのＯＳが、定期的にネットワーク上に送信することが多いＯＩＤのセットである。従って、これらのＯＩＤを指定したコマンドを代理応答の対象とするように構成すれば、もしネットワーク上にたくさんのＰＣが存在した場合であっても、データ処理装置はスリープ状態を維持することができる。

図５は、本実施形態におけるホストコンピュータとデータ処理装置間のＳＮＭＰによる通信を示すシーケンス図である。

５−１は、５−２は、ホストコンピュータ（以降、それぞれＰＣ１、ＰＣ２と呼ぶ）であり、データ処理装置（５−３）は、ＰＣ１やＰＣ２とＳＮＭＰによるネットワーク通信を行うことが可能である。

ＰＣ１（５−１）は、不定期にデータ処理装置（５−３）の情報を取得しているコンピュータであり、例えば、ネットワーク上の装置を管理する管理サーバである。ＳＮＭＰのｉｆＩｎｄｅｘ（５−５）やｉｆＰｈｙｓＡｄｄｒｅｓｓ（５−９）は、ＭＩＢオブジェクトであり、デバイス情報の一部となる。ＰＣ２（５−２）は、１０分間隔でデータ処理装置に対して、図４のＳＮＭＰのＯＩＤを問い合わせるコマンドを発行し（５−１２、５−１６）、データ処理装置のステータスの監視を行う。ＰＣ２は例えば、一般的なユーザが用いるパーソナルコンピュータである。５−４は、データ処理装置が現在のどの状態で動作中かを示しており、現在、スリープ状態中であることを示している。

５−５において自機宛てのＳＮＭＰパケットを受信したのに応じて、データ処理装置は５−６で、スリープ状態から通常状態への復帰を行う。通常状態へ復帰した後、次のＳＮＭＰパケットの待ちうけを行うため、データ処理装置は５−７でスリープ移行時間の延長を行う。図５の例では、スリープ移行時間が１５秒延長される。その後データ処理装置は、５−５で受信したＳＮＭＰパケットに対する応答をＰＣ１に送信する。５−８は、５−７で行われたスリープ移行時間の延長時間１５秒を示している。

その後さらに、データ処理装置は５−９で自機宛てのＳＮＭＰパケットを受信する。５−９のタイミングは５−８に示す１５秒以内であるため、データ処理装置はスリープ状態には移行しておらず通常状態である。データ処理装置は５−１０で再びスリープ移行時間の延長を行う。即ち、５−８において延長した１５秒を無視し、改めてこのタイミングから１５秒後にスリープ状態へ移行するように、スリープ移行時間を延長する（５−１１）。その後データ処理装置は、５−９で受信したＳＮＭＰパケットに対する応答をＰＣ１に送信する。このように本実施形態のデータ処理装置は、スリープ状態から通常状態への復帰要因となったＳＮＭＰパケットに対する応答を行った後に、すぐにスリープ状態に移行するのではなく、予め決められた時間、スリープ状態に移行せずに通常状態を維持する。これにより、もし連続してＳＮＭＰパケットがＰＣから送られてきたとしても、その都度スリープ状態からの復帰処理をする必要がなくなり、応答が遅延したり、応答できなくなるという問題を軽減することができる。

図５の５−１２では、データ処理装置は、自機宛てのＳＮＭＰパケットであって、尚且つ図４のテーブルに記述されたＯＩＤのＳＮＭＰパケットをＰＣ２から受信する。５−１２のタイミングは５−１１に示す１５秒以内であるため、データ処理装置はスリープ状態には移行しておらず通常状態である。しかし５−１３では、これまでの５−７や５−１０とは異なり、スリープ移行時間の延長を行わない。つまり、図４のテーブルに記述されたＯＩＤのＳＮＭＰパケットを受信した場合には、スリープ移行時間の延長は行わない。データ処理装置は、５−１２で受信したＳＮＭＰパケットに対する応答をＰＣ２へ送信する。その後、５−１１に示すスリープ移行時間の１５秒が経過したことに応じて、通常状態からスリープ状態へと移行する（５−１４）。５−１５は、データ処理装置の現在の状態を示しており、現在、スリープ状態中であることを示している。

データ処理装置は、５−１６において自機宛てのＳＮＭＰパケットであって、尚且つ図４のテーブルに記述されたＯＩＤのＳＮＭＰパケットを再びＰＣ２から受信する。図４のテーブルに記述されたＯＩＤとは、即ち代理応答の対象となるデータである。従ってデータ処理装置は、スリープ状態を維持したまま、受信したＳＮＭＰパケットに対する応答を行う（５−１７）。

尚、図５の例では、データ処理装置にＳＮＭＰパケットを送る装置としてＰＣ１とＰＣ２の２台のＰＣのみが登場したが、この台数に限定されるものではなく。また、スリープ移行時間の延長時間を１５秒としたが、これに限定されるものでもなく、また、ユーザが適宜延長時間を設定できるようにしてもよい。

図６は、本実施形態のデータ処理装置の通常状態における動作を示したフローチャートである。本実施形態のデータ処理装置は、自身が備える操作部からの指示やネットワークを介して受信したデータに従って様々なデータ処理を実行するが、図６では特にＳＮＭＰパケットを受信する際の処理について説明する。図６の各ステップは、データ処理装置のＲＯＭ２−２やＨＤＤ２−６に格納されたプログラムがＲＡＭ２−３に読み込まれ、ＭａｉｎＣＰＵ２−１により実行される。

まずＳ６０１においてＭａｉｎＣＰＵ（２−１）は、ネットワークを介してホストコンピュータから送信されたＳＮＭＰパケットを受信したかどうかを判断する。ＳＮＭＰパケットを受信していない場合にはＳ６０７へと進む。本実施形態のデータ処理装置は、通常状態において一定時間の間何も操作がされず、データの受信もない場合、スリープ状態へと移行する。Ｓ６０７においてＭａｉｎＣＰＵ（２−１）は、この一定時間が経過したかどうかを判断する。このスリープ移行時間は、例えば１分や１０分といったように予めユーザによって設定され、データ処理装置のＲＡＭ２−３やＨＤＤ２−６に保持されている。そして不図示のタイマーによって経過時間がカウントされている。スリープ状態へ移行するための時間が経過するまではＳ６０１へと戻り、ＳＮＭＰパケットを受信したかどうかの判断を繰り返すことになる。Ｓ６０７においてＭａｉｎＣＰＵ（２−１）がスリープ状態に移行するための時間が経過したと判断した場合、Ｓ６０８へ進み、電源制御部２−１３は副制御部２−１１への給電を止める。これによりデータ処理装置はスリープ状態へと移行し、本フローチャートの処理を終了する。

Ｓ６０１においてＭａｉｎＣＰＵ（２−１）がＳＮＭＰパケットを受信したと判断した場合、Ｓ６０２へと進む。Ｓ６０２において、ＭａｉｎＣＰＵ（２−１）は受信したＳＮＭＰパケットにおいて指定されているＯＩＤを解析する。Ｓ６０３において、ＭａｉｎＣＰＵ（２−１）はＳ６０２で解析されたＯＩＤが、図４のテーブル即ち復帰／代理応答情報管理部３（ａ）−３によってＲＯＭ２−２又はＨＤＤ２−６に保持されているテーブルに記述されたＯＩＤに一致するか否かを判断する。Ｓ６０３における判断の結果、テーブルに記述されたＯＩＤに一致した場合にはＳ６０４へ進み、一致しなかった場合にはＳ６０５へと進む。Ｓ６０５において、ＭａｉｎＣＰＵ（２−１）はスリープ状態へ移行するための時間であるスリープ移行時間を予め決められた時間（例えば１５秒）延長する処理を行う。上述したように本実施形態のデータ処理装置は、何も操作がされずデータの受信もないまま一定時間が経過した場合にスリープ状態へ移行する条件となるスリープ移行時間（例えば１分）を保持している。これを第一のスリープ移行時間と呼ぶ。Ｓ６０５において延長されるスリープ移行時間は、この第一のスリープ移行時間とは別のスリープ移行時間であり、通常状態からスリープ状態へ移行する条件となる時間である。これを第二のスリープ移行時間と呼ぶ。Ｓ６０７において、ＭａｉｎＣＰＵ（２−１）は第一のスリープ移行時間と第二のスリープ移行時間の何れか遅い方のスリープ移行時間が経過したことを条件としてＳ６０８へと進みスリープ状態へと移行する。言い換えると、第一のスリープ移行時間と第二のスリープ移行時間の両方が経過したことを条件にスリープ状態へと移行する。第二のスリープ移行時間も第一のスリープ移行時間と同様にデータ処理装置のＲＡＭ２−３やＨＤＤ２−６に保持されており、不図示のタイマーによって経過時間がカウントされる。また、第二のスリープ移行時間は、Ｓ６０５において延長されていない状態では、デフォルトで０秒がセットされている。Ｓ６０５の処理の結果、図４のテーブルに記述されていないＯＩＤが指定されたＳＮＭＰパケットを受信した場合には、データ処理装置は、必ず少なくとも延長された第二のスリープ移行時間の間は通常状態を保つことになる。Ｓ６０５において第二のスリープ移行時間を延長したのち、Ｓ６０６へと進む。Ｓ６０６において、ＭａｉｎＣＰＵ（２−１）は受信したＳＮＭＰパケットに対する応答を送信元のホストコンピュータへと送信する。その後、処理はＳ６０７へと進む。

一方、Ｓ６０３における判断の結果、テーブルに記述されたＯＩＤに一致した場合にはＳ６０４へ進む。Ｓ６０４において、ＭａｉｎＣＰＵ（２−１）は受信したＳＮＭＰパケットに対する応答を送信元のホストコンピュータへと送信する。つまりこの場合は、第二のスリープ移行時間を延長しない。その後、処理はＳ６０７へと進む。Ｓ６０７以降の処理は上述したとおりである。

このようにデータ処理装置は、図４のテーブルに記述された特定のＯＩＤが指定されたＳＮＭＰパケットを受信した場合にはスリープ移行時間を延長せず、他のＯＩＤが指定されたＳＮＭＰパケットを受信した場合にはスリープ移行時間を延長する。即ち、代理応答すべきパケットを受信した場合にはスリープ移行時間を延長しないが、それ以外のパケットを受信した場合にはスリープ移行時間を延長する。これにより、代理応答できないパケットが連続して送られてくる場合に備えてスリープ移行時間を延長して通常状態を保つことで、ホストコンピュータからのデータやコマンドに適切に応答できるようになる。また、通常状態を保つ必要がない場合にはスリープ移行時間を延長せず速やかにスリープ状態へ移行できるようにして、装置の消費電力を低減することができる。

（実施形態２）
実施形態１では、図４のテーブルにＳＮＭＰにおけるＭＩＢのＯＩＤが登録されている例をあげて説明したが、代理応答すべきデータの内容を示す図４のテーブルには、これ以外のプロトコルに基づく情報が記述されていてもよい。本実施形態では、その他の例として特定のＳＯＡＰメソッドに対して代理応答する例を説明する。尚、本実施形態におけるネットワークシステム構成やデータ処理装置のハードウェア、ソフトウェア構成に関しては、実施形態１と同様のため、説明は省略する。

図７は、本実施形態におけるホストコンピュータからの問い合わせのＳＯＡＰメソッドとそれに対するレスポンスの一例を示す図である。図７（ａ）は、ステータス取得を要求するＳＯＡＰメソッドで、図７（ｂ）は、図７（ａ）のメソッドのレスポンスでステータス情報を返信するＳＯＡＰメソッドである。図７（ａ）のメソッドは、ｇｅｔＤｅｖＳｔａｔｕｓというメソッド名であり、自装置の情報（ＩＤ、ＩＰアドレス）、相手先装置の情報（ＩＤ、ＩＰアドレス）が含まれている。図７（ｂ）は、ｇｅｔＤｅｖＳｔａｔｕｓＲｅｓｐｏｎｓｅというメソッドであり、自装置の情報と相手先装置の情報とデータ処理装置のステータスを示す＜ｓｔａｔｕｓ＞が含まれている。そして実施形態２では、図４のテーブルに特定のＳＯＡＰメソッドが記述されている。例えばｇｅｔＤｅｖＳｔａｔｕｓやｇｅｔＪｏｂＳｔａｔｕｓといってＳＯＡＰメソッドが記述されている。

図８は、本実施形態のデータ処理装置の通常状態における動作を示したフローチャートである。本実施形態のデータ処理装置は、自身が備える操作部からの指示やネットワークを介して受信したデータに従って様々なデータ処理を実行するが、図８では特にＳＯＡＰパケットを受信する際の処理について説明する。図８の各ステップは、データ処理装置のＲＯＭ２−２やＨＤＤ２−６に格納されたプログラムがＲＡＭ２−３に読み込まれ、ＭａｉｎＣＰＵ２−１により実行される。

まずＳ８０１においてＭａｉｎＣＰＵ（２−１）は、ネットワークを介してホストコンピュータから送信されたＳＯＡＰパケットを受信したかどうかを判断する。ＳＯＡＰパケットを受信していない場合にはＳ８０７へと進む。Ｓ８０７においてＭａｉｎＣＰＵ（２−１）は、スリープ移行時間が経過したかどうかを判断する。スリープ移行時間が経過するまではＳ８０１へと戻り、ＳＯＡＰパケットを受信したかどうかの判断を繰り返すことになる。Ｓ８０７においてＭａｉｎＣＰＵ（２−１）がスリープ移行時間が経過したと判断した場合、Ｓ８０８へ進み、電源制御部２−１３は副制御部２−１１への給電を止める。これによりデータ処理装置はスリープ状態へと移行し、本フローチャートの処理を終了する。

Ｓ８０１においてＭａｉｎＣＰＵ（２−１）がＳＯＡＰパケットを受信したと判断した場合、Ｓ８０２へと進む。Ｓ８０２において、ＭａｉｎＣＰＵ（２−１）は受信したＳＯＡＰパケットにおいて指定されているＳＯＡＰメソッドを解析する。Ｓ８０３において、ＭａｉｎＣＰＵ（２−１）はＳ８０２で解析されたＳＯＡＰメソッドが、図４のテーブル即ち復帰／代理応答情報管理部３（ａ）−３によって保持されたテーブルに記述されたＳＯＡＰメソッドに一致するか否かを判断する。Ｓ８０３における判断の結果、テーブルに記述されたＳＯＡＰメソッドに一致した場合にはＳ８０４へ進み、一致しなかった場合にはＳ８０５へと進む。Ｓ８０５において、ＭａｉｎＣＰＵ（２−１）はスリープ状態へ移行するための時間であるスリープ移行時間を予め決められた時間（例えば１５秒）延長する処理を行う。ここで延長されるスリープ移行時間は、上述の図６のＳ６０５と同様に、第二のスリープ移行時間である。Ｓ８０７において、ＭａｉｎＣＰＵ（２−１）は第一のスリープ移行時間と第二のスリープ移行時間の何れか遅い方のスリープ移行時間が経過したことを条件としてＳ８０８へと進みスリープ状態へと移行する。Ｓ８０５において第二のスリープ移行時間を延長したのち、Ｓ８０６へと進む。Ｓ８０６において、ＭａｉｎＣＰＵ（２−１）は受信したＳＯＡＰパケットに対する応答を送信元のホストコンピュータへと送信する。その後、処理はＳ８０７へと進む。

一方、Ｓ８０３における判断の結果、テーブルに記述されたＳＯＡＰメソッドに一致した場合にはＳ８０４へ進む。Ｓ８０４において、ＭａｉｎＣＰＵ（２−１）は受信したＳＯＡＰパケットに対する応答を送信元のホストコンピュータへと送信する。つまりこの場合は、第二のスリープ移行時間を延長しない。その後、処理はＳ８０７へと進む。Ｓ８０７以降の処理は上述したとおりである。

このように本実施形態におけるデータ処理装置は、図４のテーブルに記述された特定のＳＯＡＰメソッドが指定されたＳＯＡＰパケットを受信した場合にはスリープ移行時間を延長しない。一方、他のＳＯＡＰメソッドが指定されたＳＯＡＰパケットを受信した場合にはスリープ移行時間を延長する。

（その他の実施形態）
本発明は上記実施形態において説明した以外の方法によっても実現可能である。例えば上記実施形態で説明したようにデータ処理装置を一つの装置として構成するのではなく複数の装置によって構成するようにしてもよい。また、上記各実施形態を組み合わせることによっても本発明を実現可能である。

また本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２−１ＭａｉｎＣＰＵ
２−２ＲＯＭ
２−３ＲＡＭ
２−１８ＳｕｂＣＰＵ
２−１３電源制御部

Claims

少なくとも第一の状態と、当該第一の状態よりも消費電力が少ない第二の状態で動作するデータ処理装置であって、
前記第二の状態で動作中にネットワークから受信するデータであって、当該第二の状態から前記第一の状態に移行することなく応答を行うべき特定のデータを示す情報を保持する保持手段と、
前記第一の状態で動作中にネットワークからデータを受信する受信手段と、
前記受信手段によって受信されたデータが、前記保持手段によって保持された情報が示す特定のデータであるか否かを判断する判断手段と、
前記判断手段によって特定のデータであると判断された場合は特定のデータでないと判断された場合よりも早く、前記受信したデータに応答した後に前記第一の状態から前記第二の状態に移行するよう制御する制御手段と、
を有することを特徴とするデータ処理装置。
前記第一の状態で動作中に前記データ処理装置が操作されることなく前記移行時間が経過したことに応じて前記第二の状態に移行する移行手段を更に有することを特徴とする請求項１記載のデータ処理装置。
前記第二の状態で動作中にネットワークから受信したデータが前記特定のデータであるか否かを判定する判定手段を更に有し、
前記判定手段によって前記特定のデータであると判定された場合には、前記第二の状態から前記第一の状態に移行することなく当該特定のデータに対して応答し、前記判定手段によって前記特定のデータでないと判定された場合には、前記第二の状態から前記第一の状態に移行した上で当該データに対して応答することを特徴とする請求項１又は２に記載のデータ処理装置。
電源制御部によって電力の供給が制御される主制御部と副制御部とを有し、前記第一の状態は前記主制御部と前記副制御部とに電力が供給されている状態であり、前記第二の状態は前記主制御部には電力が供給されておらず前記副制御部に電力が供給されている状態であることを特徴とする請求項１乃至３の何れか一項に記載のデータ処理装置。
前記保持手段によって保持される情報は、ＳＮＭＰにおける特定のＭＩＢのＯＩＤであることを特徴とする請求項１乃至４の何れか一項に記載のデータ処理装置。
前記保持手段によって保持される情報は、ＳＯＡＰにおける特定のメソッドを示す情報であることを特徴とする請求項１乃至４の何れか一項に記載のデータ処理装置。
少なくとも第一の状態と、当該第一の状態よりも消費電力が少ない第二の状態で動作するデータ処理装置の制御方法であって、
前記第二の状態で動作中にネットワークから受信するデータであって、当該第二の状態から前記第一の状態に移行することなく応答を行うべき特定のデータを示す情報を記憶部に保持する保持ステップと、
前記第一の状態で動作中にネットワークからデータを受信する受信ステップと、
前記受信ステップによって受信されたデータが、前記保持ステップによって保持された情報が示す特定のデータであるか否かを判断する判断ステップと、
前記判断ステップによって特定のデータであると判断された場合は特定のデータでないと判断された場合よりも早く、前記受信したデータに応答した後に前記第一の状態から前記第二の状態に移行するよう制御する制御ステップと、
を有することを特徴とする制御方法。
請求項７記載の制御方法の各ステップをコンピュータに実行させるプログラム。