管理装置と画像形成システム
【課題】 ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の機器の状態を判定できるようにする。
【解決手段】 ＣＰＵのスリープ判定部は、ステップ１２で、画像形成装置から取得した第１機器情報と第２機器情報の内容に違いがあるか否かを判断し、違いが有ると判断したら、ステップ１３で、画像形成装置はスリープ中であると判断し、ステップ１４で、ネットワーク制御部へ定期送信抑制信号を送信し、ネットワーク制御部が画像形成装置に対して定期的に要求する機器情報要求パケットの送信を抑制する。
【解決手段】 ＣＰＵのスリープ判定部は、ステップ１２で、画像形成装置から取得した第１機器情報と第２機器情報の内容に違いがあるか否かを判断し、違いが有ると判断したら、ステップ１３で、画像形成装置はスリープ中であると判断し、ステップ１４で、ネットワーク制御部へ定期送信抑制信号を送信し、ネットワーク制御部が画像形成装置に対して定期的に要求する機器情報要求パケットの送信を抑制する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワーク上の機器の状態を管理するＰＣ、サーバを含む管理装置と、ネットワーク上の複数の端末装置が共有して利用するファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置とその画像形成装置の状態を管理する管理装置とからなる画像形成システムとに関する。
【背景技術】
【０００２】
従来、ネットワーク上の機器に対して定期的に応答要求を出し、その応答要求に対する応答状態の変化を検出し、その検出結果から機器がエラー状態であると判断すると、上記機器を利用するユーザへその旨を電子メールで通知する技術があった。
しかし、上述の技術では、ネットワーク上の機器から応答がなかった場合、その機器がエラー状態であるか否かを判断することができない。
そこで、ネットワーク上の機器に対して所定のタイミングで応答要求を出し、その応答要求に対する応答状態の変化を検出し、その検出結果（例えば、機器がエラー状態であることや正常状態であること）をネットワーク上の所定の端末装置へメールで知らせる管理装置（例えば、特許文献１参照）があった。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述のような従来の管理装置では、ネットワークに接続されている機器が正常か異常かを判断するために、定期的な問い合わせの他に任意のタイミングで応答要求を出すので、ネットワーク上の機器が待機状態よりも消費電力が低い状態（スリープ状態）にする機能を有し、そのスリープ中の時に不定期な問い合わせに答えるために待機状態に戻さなければならなくなり、省電力効果が低減するという問題があった。
この発明は上記の点に鑑みてなされたものであり、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の機器の状態を判定できるようにすることを目的とする。
【課題を解決するための手段】
【０００４】
この発明は上記の目的を達成するため、ネットワーク上の機器の機器情報を取得して保持し、その保持した機器情報に基づいて上記機器の状態を管理する管理装置において、上記取得した機器情報を記憶する記憶手段と、上記機器から新たに取得した機器情報の内容と、上記記憶手段に先に記憶されている機器情報の内容を比較し、その２つの機器情報の内容が互いに異なる場合、上記記憶手段に先に記憶されている機器情報と区別して上記新たに取得した機器情報を上記記憶手段に記憶させると共に、上記機器の機器情報が更新されたと判定する更新判定手段と、上記更新判定手段によって上記機器の機器情報が更新されたと判定された場合、上記記憶手段から上記先に記憶されている機器情報と上記新たに取得した機器情報とを読み出し、その２つの機器情報の内容に基づいて上記機器がスリープ中か否かを判定するスリープ判定手段を設けた管理装置を提供する。
【０００５】
また、上記スリープ判定手段によって上記機器がスリープ中であると判定された場合、上記機器からの機器情報の定期的な取得を抑えるように制御する手段を設けるとよい。
さらに、上記スリープ判定手段を、上記２つの機器情報の内容について、一方が上記機器の応答する内容として適切な内容であるのに対し、もう一方が通常では得られないような不適切な内容である場合に上記機器がスリープ中であると判定する手段にするとよい。
また、上記機器がスリープ中と判定された場合、上記先に記憶されている機器情報の内容を表示する手段を設けるとよい。
さらに、上記不適切な内容とは、一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトのうちの通常は書き換え可能なオブジェクトを示しているのに対し、もう一方の機器情報が書き換えを拒絶するような内容、又は一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトが存在するという応答であったのに対し、もう一方の機器情報はＭＩＢオブジェクトが存在しないことを示す内容であるとするとよい。
【０００６】
また、上記機器がスリープ中と判定された場合、上記機器に対して上記機器がスリープ中では取得できない情報を要求するとき、上記機器に対してヌルデータを送信して上記機器をスリープ状態から復帰させ、上記機器から上記スリープ中では取得できない情報を取得する手段を設けるとよい。
さらに、上記のような管理装置と、その管理装置が管理する機器である画像形成装置とにより構成されている画像形成システムを提供する。
【発明の効果】
【０００７】
この発明による管理装置は、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の機器の状態を判定することができる。
また、この発明による画像形成システムは、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の画像形成装置の状態を判定することができる。
【図面の簡単な説明】
【０００８】
【図１】図２に示す各ホスト装置の主要部の構成を示すブロック図である。
【図２】この発明の実施例のホスト装置と画像形成装置からなる画像形成システムの構成を示す図である。
【図３】図１に示す第ｎホスト装置が定期的に画像形成装置の機器情報を取得するときの処理を示すフローチャート図である。
【図４】図１に示す第ｎホスト装置において画像形成装置がスリープ中か否かを判定する処理を示すフローチャート図である。
【０００９】
【図５】図１に示す第ｎホスト装置において画像形成装置がスリープ中か否かの判定結果に基づいて表示するときの処理を示すフローチャート図である。
【図６】ＲＦＣ１２１３に定義されているＭＩＢツリーのサンプルを示す図である。
【図７】プリンタＭＩＢを利用したプリンタの機器情報の一例を示す図である。
【図８】図１に示す第ｎホスト装置においてスリープ中と判定した画像形成装置に印刷を依頼するときの処理を示すフローチャート図である。
【発明を実施するための形態】
【００１０】
以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
〔実施例〕
まず、この発明の実施例における用語について説明する。
スリープ：ネットワーク上の機器の消費電力が通常動作時の消費電力よりも少ない状態のことをいう。例えば、機器がファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置の場合、印刷実行中ではなく、印刷要求を待っているような状態であり、印刷時よりも低い消費電力の状態で待機している状態のことをいう。
ホスト装置：ネットワーク上の機器の状態を管理するＰＣ、サーバを含む管理装置に相当する。また、ネットワーク上の機器に接続されたデジタルカメラを含む装置の状態を管理又は監視することが可能な装置をいう。このホスト装置は、ネットワーク上の機器を後述するＳＮＭＰを利用して機器情報を収集し、その機器情報に基づいて機器を管理・監視する場合、ＳＮＭＰマネージャと呼ばれる。
【００１１】
画像形成装置：ネットワーク上の端末装置が利用するファクシミリ装置、プリンタ、複写機、複合機を含む機器である。ホスト装置によってネットワーク経由で管理・監視されるネットワーク機器であり、上記ホスト装置に対してエージェントと呼ぶ。
シンプルネットワークマネジメントプロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ：ＳＮＭＰ）：今日、幅広く使用されているネットワークを管理するためのプロトコルである。
マネジメントインフォメーションベース（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ：ＭＩＢ）：ＳＮＭＰを用いてネットワークを管理する際に使用されるツリー構造の情報データベースである。
【００１２】
ＭＩＢオブジェクト（ＭＩＢ ＯＢＪＥＣＴ）：ＭＩＢに格納されている一つ一つの情報をオブジェクト（ＯＢＪＥＣＴ）と呼ぶ。このオブジェクトのことをＭＩＢオブジェクトと表記する。このＭＩＢオブジェクトは情報の要素によってツリー構造で管理されており、それぞれのＭＩＢオブジェクトにはオブジェクトＩＤ（ＯＢＪＥＣＴ ＩＤ：ＯＩＤ）という識別子が付与されている。ＳＮＭＰマネージャ（ホスト装置）は、エージェント（ネットワーク経由で監視されるネットワーク機器）に対して、ＯＩＤを指定して情報の取得や設定の変更を要求することができる。
ネットワーク：有線又は無線によるインターネット、ローカルエリアネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：ＬＡＮ）を含む通信網である。
【００１３】
図２は、この発明の実施例のホスト装置と画像形成装置からなる画像形成システムの構成を示す図である。
この画像形成システムは、多数のホスト装置（図中の第１ホスト装置〜第ｎホスト装置：ｎは正の整数）１と１台の画像形成装置２とがネットワーク３を介して通信可能に接続されており、各ホスト装置１が画像形成装置２の印刷，スキャナ等の各種機能を共有して使用するネットワーク環境が構築されている。
また、各ホスト装置１は定期的に画像形成装置２の状態（スリープ中か否かの状態を含む）を示す機器情報を収集して保持し、その機器情報に基づいて画像形成装置２を管理している。
【００１４】
図１は、図２に示す各ホスト装置の主要部の構成を示すブロック図であり、同図では、複数のホスト装置を代表して、第ｎホスト装置１を示している。
この第ｎホスト装置１には、ＣＰＵ１０が搭載されている。
このＣＰＵ１０は、図示を省略したＲＯＭに格納された制御プログラムを、作業領域であるＲＡＭを使用して実行することにより、ネットワーク制御部１１，更新判定部１２，スリープ判定部１３の機能を果たす。
ネットワーク制御部１１は、ネットワーク３上の画像形成装置２の間で機器情報取得パケット、印刷データを含むネットワークデータの送信及び受信の制御を行う。
このネットワーク制御部１１は、ネットワーク３上の画像形成装置２の状態を把握するために、ＳＮＭＰプロトコルに従い、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドを使用して、画像形成装置２に対して定期的に機器情報取得パケットを送り、画像形成装置２に機器情報を要求する。
【００１５】
画像形成装置２は、第ｎホスト装置１からの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドによる機器情報取得パケットを受信すると、「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」を含むコマンドによる応答パケットで自装置の状態を示す機器情報を返送する。
ネットワーク制御部１１が上記応答パケットによって取得した画像形成装置２の機器情報は更新判定部１２に送られる。
更新判定部１２は、ハードディスク装置を含む記憶部１４に記憶されている保管済み機器情報である前回に取得した画像形成装置２の機器情報（「第２機器情報」という）を読み出し、今回取得した最新の機器情報（最新情報）と比較し、今回取得した機器情報の内容が第２機器情報の内容と異なると判断すると、上記第２機器情報を第１機器情報として記憶部１４に記憶し、今回取得した機器情報を第２機器情報として記憶部１４に記憶する。
【００１６】
したがって、記憶部１４には、画像形成装置２から取得した機器情報について、ある時間に取得して状態が変わる前の各機器情報を第１機器情報１ａ，１ｂ．．．．１ｎとして記憶して保持され、応答内容が変わり、更新された後の各機器情報を第２機器情報２ａ，２ｂ，２ｃ．．．２ｎとして記憶して保持される。図中の機器情報に付したサフィックスのａ，ｂ，ｃ，．．．ｎは同じ種類の「ｒｅｑｕｅｓｔ」に対する「ｒｅｓｐｏｎｓｅ」であるという形で保管している。
更新判定部１２は、機器情報の更新を検出すると、スリープ判定部１３に情報更新通知を通知する。
スリープ判定部１３は、更新判定部１２から情報更新通知を受け取ると、その情報更新通知で通知された機器情報の該当するサフィックスの第１機器情報と第２機器情報を記憶部１４から読み出し、その第１機器情報と第２機器情報の内容から、画像形成装置２がスリープ中（通常待機状態より消費電力が少ない状態）か否（スリープ状態から通常待機状態へ移行した状態）かを判定する。
【００１７】
スリープ判定部１３は、画像形成装置２がスリープ中であると判定すると、ネットワーク制御部１１へ送信する定期送信抑制信号をアサートにする。
ネットワーク制御部１１は、スリープ判定部１３からの定期送信抑制信号がアサートされると、定期的に画像形成装置２の状態を把握するために送信していた、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」のコマンドを含む機器情報取得パケットの送信を極力行わないように制御する。
このような制御をすることにより、画像形成装置２がスリープ状態から解除される回数を削減することが可能となる。
【００１８】
また、第ｎホスト装置１において画像形成装置２の状態の情報を表示したり、画像形成装置２の消耗品を管理するときには、画像形成装置２がスリープ中（スリープ状態に移行している）と判定した場合、ＬＣＤを含むディスプレイである表示部１５に、記憶部１４に保存されている該当する第１機器情報の状態を表示、または第１機器情報を使用するので、画像形成装置２の状態を表示させたりする度に機器情報を収集し、画像形成装置２を頻繁にスリープ状態から復帰させるようなことを防ぐことができる。
さらに、画像形成装置２がスリープ中でないと判定した場合には、第２機器情報の値（最新の値）を使用しても、再度、機器情報の取得のための「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を送信しても、画像形成装置２の省エネルギー効果を低減させることがない。
【００１９】
次に、第ｎホスト装置１が定期的に画像形成装置２の機器情報を取得するときの処理について詳しく説明する。
図３は、第ｎホスト装置１が定期的に画像形成装置２の機器情報を取得するときの処理を示すフローチャート図である。
第ｎホスト装置１は、ネットワーク３上の画像形成装置２の状態を定期的に把握するために、ＳＮＭＰプロトコルの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンド使用し、画像形成装置２に対し、機器情報取得パケット（Ｓｅｔ Ｒｅｑｕｅｓｔの場合、設定）によって機器情報の要求を送信する。
画像形成装置２は、上記機器情報取得パケットを受信すると、「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」を含むコマンドを使用し、応答パケットで自装置の状態を示す情報を含む機器情報を第ｎホスト装置１へ返す。
【００２０】
図３に示すように、ステップ（図中「Ｓ」で示す）１で、画像形成装置はスリープ中か否かを判断する。
ここでは、ネットワーク制御部はスリープ判断部の定期送信抑制信号がアサートされているか否かを確認し、定期送信抑制信号がアサートされていれば画像形成装置はスリープ中であると判断し、この処理を終了して、定期送信によるネットワーク機器の機器情報取得を行わない。
一方、ステップ１の判断で、定期送信抑制信号がアサートされていない場合には画像形成装置はスリープ中ではないか、または、十分な情報が集っていないために画像形成装置がスリープ中か否かを判断できないかのいずれかであり、ここでは画像形成装置はスリープ中ではない判断し、ステップ２へ進む。
ステップ２では、この場合には定期送信により画像形成装置の機器情報取得処理を行うために、画像形成装置へＳＮＭＰ通信で機器情報取得パケットを送信する。
【００２１】
画像形成装置の機器情報の取得には、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドによる機器情報取得パケットを送り、画像形成装置２からツリー構造のＭＩＢオブジェクトの情報を取得するということを逐次行っていく。
ここで画像形成装置２から逐次得られた全ての応答パケットの情報を記憶部１４に記憶していくと、記憶部１４のメモリ容量を圧迫する原因となるので、記憶部１４に格納するＭＩＢオブジェクトは予め候補を絞っておくとよい。
【００２２】
図６は、ＲＦＣ１２１３に定義されているＭＩＢツリーのサンプルを示す図である。
最初の標準ＭＩＢとしてＲＦＣ１１５６で定義されたのはＭＩＢ−１であり、管理対象オブジェクトは１１４種類定義されているが、ＯＩＤの割り当てを単純でわかり易くするために８個のグループ（ｓｙｓｔｅｍ，ｉｎｔｅｒｆａｃｅｓ，ａｔ：ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ，ｉｐ，ｉｃｍｐ，ｔｃｐ，ｕｄｐ，ｅｇｐ）に分類している。
その後のＲＦＣ１２１３において、新たに５７種類の管理対象オブジェクトが追加され、１７１種類の管理対象オブジェクトを１１種類に分類したＭＩＢ−２が定義された。
１１個のグループはｓｙｓｔｅｍ，ｉｎｔｅｒｆａｃｅｓ，ａｔ：ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ，ｉｐ，ｉｃｍｐ，ｔｃｐ，ｕｄｐ，ｅｇｐ，ｏｉｍ，ｔｒａｎｓｍｉｓｓｉｏｎ，ｓｎｍｐとなる。
【００２３】
例えば、ｓｙｓｔｅｍグループには、機器（この実施例では「画像形成装置２」）のシステムに関する設定が管理されていて、その内訳はｓｙｓＤｅｓｃｒ：ｅｎｔｉｔｙの情報、ｓｙｓＯｂｊｅｃｔＩＤ：ベンダのＯＩＤ，ｓｙｓＵｐＴｉｍｅ：最後に初期化されてからの経過時間、ｓｙｓＣｏｎｔａｃｔ：ノードの管理者の情報、ｓｙｓＮａｍｅ：ドメイン名、ｓｙｓＬｏｃａｔｉｏｎ：ノードの物理的な位置，ｓｙｓＳｅｒｖｉｃｅｓ：Ｅｎｔｉｔｙが提供するサービスを示している。
これらの情報をＯＩＤを元に管理することが可能となっている。
また、ｉｎｔｅｒｆａｃｅｓグループには、機器の保有するハードウェアインターフェースに関係する設定が管理されている。
最初のオブジェクトであるｉｆＮｕｍｂｅｒには、この機器が保有するインターフェース数が格納されており、その数に応じて設定を格納するテーブル行が追加される。
その内訳は公知なので説明を省略する。
【００２４】
例えば、ｉｆＴｙｐｅを参照したいときには、機器を管理する側のホスト装置（この実施例では「第ｎホスト装置１」）がｓｙｓｔｅｍのＯＩＤのＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケット（ＯＩＤはｉｎｔｅｒｆａｃｅｓ）を送信すると、そのＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケットで指定されているＯＩＤ（ｉｎｔｅｒｆａｃｅｓ）に所属していて、その機器で管理することが可能なＯＩＤ情報であるｉｆＮｕｍｂｅｒのＯＩＤとｉｆＴａｂｌｅのＯＩＤをホストＰＣに返す。
この時にｉｆＮｕｍｂｅｒのＯＩＤに所属する値はＩＦの数となるが、ｉｆＴａｂｌｅのＯＩＤに所属する値は、その下の階層として持っているオブジェクトの数になる。
図６に示したツリーの場合には、ｉｆｉｎｄｅｘからｉｆＳｐｅｃｉｆｉｃまでで２２のオブジェクトとなる。
【００２５】
ここで、ホスト装置は、ネットワークに接続されている機器はｉｆＴｙｐｅというオブジェクトを管理対象として保持していることを認識できるので、ＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケットのＯＩＤにｉｆＴｙｐｅを指定して送信すると、機器からｉｆＴｙｐｅの値を取得することが可能となる。
このような制御を行うことで、ネットワーク上の機器（画像形成装置２）の管理対象オブジェクトを、ホスト装置（第ｎホスト装置１）は参照して操作することが可能となっている。
この中の全てのＭＩＢに対する応答結果のオブジェクトを記憶部１４に記憶するのではなく、予め、スリープ中の応答と通常状態の応答として判断できるようなオブジェクトだけを記憶部１４への保存対象として管理する。
【００２６】
例えば、画像形成装置２の場合、ｈｒＤｅｖｉｃｅＳｔａｔｕｓ，ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ等は定期的に第ｎホスト装置１が機器情報として取得してくるＭＩＢオブジェクトであり、また、これらのＭＩＢオブジェクトは、画像形成装置２がスリープ中であるが、そのままで使用できる状態であるということを示す状態が存在していないので、このｈｒＤｅｖｉｃｅＳｔａｔｕｓやｈｒＰｒｉｎｔｅｒＳｔａｔｕｓは記憶部１４への保存対象としても良い。
【００２７】
図３の説明に戻り、ステップ３で、画像形成装置から応答パケットを受信すると、ステップ４で、更新判定部は記憶部に先に保存されている同じＭＩＢオブジェクト（前回の取得で記憶されたＭＩＢオブジェクト）の内容を参照し、今回取得したＭＩＢオブジェクトの内容と比較し、今回取得した機器情報は最新情報か否かを判断する。
もし、記憶部１４に保存されていたＭＩＢオブジェクトと、今回取得したＭＩＢオブジェクトの内容が異なっていた場合には、最新情報と判断し、ステップ５で、更新判定部はスリープ判定部に情報更新通知（更新されたＭＩＢオブジェクトがわかるような識別情報を含むとよい）を送信し、ステップ６で、記憶部に先に保存されていたＭＩＢオブジェクト（第２機器情報）を記憶部上で第１機器情報として記憶し、今回取得したＭＩＢオブジェクトを第２機器情報として保存して、この処理を終了する。
【００２８】
このようにして、記憶部１４上には常に同じ画像形成装置２のＭＩＢオブジェクトについて、その画像形成装置２の状態が変化する前の第１機器情報と最新の情報である第２機器情報が保管されることになる。
もし、記憶部１４上に今回取得したＭＩＢオブジェクトと同じＯＩＤのＭＩＢオブジェクトが第２機器情報として保管されていない場合には、更新判定部１２は比較を行わずに記憶部１４に第２機器情報として今回取得したＭＩＢオブジェクトを保管する。
このときには、更新判定部１２はスリープ判定部１３への情報更新通知を送信しない。
一方、ステップ４の判断で、取得した機器情報が最新情報ではないと判断したら、すなわち、記憶部から取得した第２機器情報と今回取得したＭＩＢオブジェクトの内容が一致している場合には、更新判定部は記憶部上の第１機器情報も第２機器情報も更新しないし、スリープ判定部への情報更新通知も行わないで、この処理を終了する。
つまり、更新判定部１２がスリープ判定部１３に情報更新通知を送信する条件としては、第２機器情報と今回取得した機器情報（ＭＩＢオブジェクト）の内容が異なるときだけになる。
【００２９】
このようにして、第ｎホスト装置１では、画像形成装置２から定期的に取得した複数の応答パケットの内容の内、過去の機器情報（応答内容が変わる前の内容の機器情報）と新たに取得した機器情報（応答内容が過去のものと変わった内容の機器情報）の２つを記憶し、その２つの機器情報の内容を比較することにより、ネットワーク上に定期的な要求の他に追加して特別なパケットによる要求を発信せずに、画像形成装置２がスリープ中か否かを判定することが可能になる。
【００３０】
この実施例では、画像形成装置２に対して定期的なタイミングで取得する機器情報の違いをただ検出するのではなく、前回は正常応答（通常応答してくると想定されている範疇の応答）であったにも関わらず、明らかに異なる応答をした場合（応答が無い場合ではない）に、省エネルギー状態に入っているという判断を行う。また、機器情報を時系列的に記憶する際、その時系列の時間については、必ず、前後ではなく、例えば、前回の内容と変更が無ければ、前回の内容を保存したままにし、内容に変更が有れば新しい内容を記憶する。
こうすることで、２つの機器情報を記憶するだけで常に画像形成装置２の状態の変化を検出することを可能としている。
【００３１】
次に、第ｎホスト装置１において画像形成装置２がスリープ中か否かを判定する処理について詳しく説明する。
図４は、第ｎホスト装置１において画像形成装置２がスリープ中か否かを判定する処理を示すフローチャート図である。
スリープ判定部１３は、ステップ１１で情報更新通知を受信したか否かを判断し、情報更新通知を受信したら、ステップ１２で、記憶部から第１機器情報と第２機器情報を読み出してそれぞれの内容を比較し、第１機器情報と第２機器情報の内容に違いが有るか否かを判断する。
【００３２】
上記判断では、具体的には、例えば、第１機器情報の内容ではオブジェクトが存在するという内容であったのに、第２機器情報ではオブジェクトが存在しないといった内容になっている場合、第１機器情報ではエラーになっていないが、第２機器情報では本来エラーになることはありえない箇所がエラー発生を通知している場合、第１機器情報では書き換え可能であったのに第２機器情報では書き込み自体が行えないと示されている場合のように、本来ありえないような応答にある時点から内容が変化している場合は、第１機器情報と第２機器情報の内容に違いが有ると判断する。
ステップ１２で第１機器情報と第２機器情報の内容に違いが有ると判断したら、ステップ１３で、画像形成装置はスリープ中であると判断し、ステップ１４で、ネットワーク制御部へ定期送信抑制信号を送信し、ネットワーク制御部が機器情報取得パケットを送信しないように制御し、この処理を終了する。
【００３３】
一方、ステップ１２で第１機器情報と第２機器情報の内容に違いが無いと判断したら、ステップ１５で、画像形成装置はスリープ中ではないと判断し、ステップ１６で、ネットワーク制御部への定期送信抑制信号を解除し、ネットワーク制御部が定期的に機器情報取得パケットを送信するように戻し、この処理を終了する。
このようにして、画像形成装置２がスリープ中であると判定した場合には、ネットワーク制御部１１からの画像形成装置２の機器情報取得のための定期的なＳＮＭＰ通信（Ｇｅｔ Ｒｅｑｕｅｓｔ，Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ，Ｓｅｔ Ｒｅｑｕｅｓｔ）の送信を行わないように制御することが可能となり、画像形成装置２をスリープ状態のままに維持することが可能となる。
したがって、画像形成装置２を長い時間スリープ状態としておくことが可能となり、消費電力を低く抑えることが可能となる。
【００３４】
次に、スリープ状態を判定するために、画像形成装置２からスリープ中であることを示す情報を送信した場合、ネットワークパケットがネットワーク３上に流れるためにネットワークトラフィックが増加する。
また、そのネットワークパケットを受け取った第ｎホスト装置１が、その送られてきたネットワークパケットがスリープ中であることを示していることを理解できないと、第ｎホスト装置１としては、何を意味しているか不明なネットワークパケットを受け取っただけで意味がない。
この場合、画像形成装置２と第ｎホスト装置１の両方が双方の状態を確認できるような変更を同時に搭載していないと、画像形成装置２がスリープ中であることを認識することができない。
【００３５】
上記画像形成装置２がプリンタである場合にはプリンタＭＩＢを利用できる。
図７は、プリンタＭＩＢを利用したプリンタの機器情報の一例を示す図である。
第ｎホスト装置１は、プリンタの状態を把握するために、「Ｇｅｔ Ｒｅｑｕｅｓｔ」または「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」で定期的にプリンタに対し、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」を送信する。
プリンタは「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」を受信すると、それに応答する「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」を応答する。
「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」ではともに、プリンタが使用可能な状態でスリープ中を表すような状態は存在しない。
【００３６】
図７に示すように、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」はともに、「ｏｔｈｅｒ（１）」「ｒｕｎｎｉｎｇ（２）」「ｉｄｌｅ（３）」「ｐｒｉｎｔｉｎｇ（４）」「ｄｏｗｎ（５）」を使用して、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」でプリンタの状態を表すが、これらの値をあえて、図７にない値として「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」を返したり、または、そもそも「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」というＯＩＤは存在しないというように、本来プリンタであれば絶対に存在するＭＩＢオブジェクトをあたかも存在していないかのように応答したり、「Ｓｅｔ Ｒｅｑｕｅｓｔ」で書き換えできるはずの値を書き換えできないというように「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」で応答してきた場合、スリープ判定部１３はプリンタがスリープ中であると判定する。
【００３７】
なお、一例としてプリンタＭＩＢを挙げたが特にプリンタに限る必要はない。
また、決め打ちの実装をする場合には、変わる前の第１機器情報と最新の情報である第２機器情報を取得及び比較せずに第２機器情報だけ使用すればよいが、様々な種類のネットワークデバイスではサポートしているＭＩＢオブジェクト自体も種類が異なるし、第ｎホスト装置１側も様々な機器を監視するため、その時の応答と製品との結びつけを行うには実装が困難となる。
そこで、予め取得しておいた第１機器情報の内容と、新しく取得した機器情報であり、第１機器情報と異なる内容の機器情報を比較することによって、第１機器情報の内容はネットワーク機器として通常ありうる範囲の応答内容であるが、新しく取得した機器情報（第２機器情報）がネットワーク機器として通常ありえないような内容の応答を返した場合はスリープ中であるという判定をすることによって、製品毎の実装依存を排除しながらも、ネットワーク上の機器への定期的な機器情報の取得を排除することができる。
【００３８】
このようにして、ネットワーク３上の画像形成装置２からスリープ時に余分なネットワークパケットが送信されるわけではないので、ネットワークパケットを増加させずに済む。また、ネットワーク３上の画像形成装置２の応答内容が通常ではありえない値になっているだけで、第ｎホスト装置１としては内容を把握することは可能であり、スリープ中か否かの状態を把握するための新たなネットワークパケットによるネットワークトラフィックの増加を抑えることが可能になる。
【００３９】
次に、この実施例の第ｎホスト装置１では、画像形成装置２がスリープ中か否かを判定するために、ある時間とその後の時間で取得した２つの機器情報を必要としている。
ただし、今回取得した機器情報とそれより以前の時間で取得した直前の機器情報を比較対象と必ずしもしているわけではない。
その理由としては、ある時間に取得したときの機器情報と、今回新しく取得した機器情報を比較したときに互いの内容が同じ場合には、画像形成装置２は正常に動作しているのかと、スリープ中であるのかが判断できないからである。
もし、予め設定された特定値になっていればスリープ中であると判断できるのであれば、１回の機器情報の取得で容易に判定可能であるが、ネットワーク３上の画像形成装置２の種別が不明であり、その画像形成装置２がスリープ時にどんな応答を返してくるかを理解した上で第ｎホスト装置１上のプログラムの開発をしないと、ホスト装置はネットワーク３上の画像形成装置２がスリープ中か否かを判定することができない。
【００４０】
これは、第ｎホスト装置１と画像形成装置２とが共に同じメーカの製品であれば容易に対応可能と考えられるが、どちらかが他社の製品の場合には細かい仕様が不明なために、期待する効果が得られないことが考えられる。
そこで、第ｎホスト装置１では、まずは、画像形成装置２の正常な応答結果のＭＩＢオブジェクトの内容を保持しておき、その保存しておいた正常なＭＩＢオブジェクトの内容と比較して明らかに尋常でない内容の応答結果を取得したときに、画像形成装置２がスリープ中であると判定することによって、第ｎホスト装置１側のプログラム開発時に各製品の振る舞いを気にせずに実装することが可能になるので、開発の手間を削減することも可能になる。
【００４１】
次に、画像形成装置２は異常動作しているわけではなく、ただスリープ中であるだけで、印刷コマンドがくれば使用できるのに、使用できないような状態に扱われていると、遠隔地から管理しているときに壊れてしまったと思われたり、正しい機器情報をスリープ中に取得できないことにより、画像形成装置２の稼動率が低いと思われることがある。
そこで、ＣＰＵ１０は、画像形成装置２がスリープ中であると判定した場合、記憶部１４の第１機器情報の内容を表示部１５に表示することにより、画像形成装置２スリープ中であっても、第ｎホスト装置１上では通常稼動状態として扱われていることを、第ｎホスト装置１の作業者に示すことができるので、画像形成装置２が壊れていると間違われたり、稼働率が低いと思われることがなくなる。
【００４２】
図５は、第ｎホスト装置１において画像形成装置２がスリープ中か否かの判定結果に基づいて表示するときの処理を示すフローチャート図である。
ＣＰＵ１０は、ステップ２１で、スリープ判定部による判定結果に基づいて画像形成装置はスリープ中か否かを判断し、スリープ中なら、ステップ２２で、表示部に記憶部の第１機器情報を表示し、この処理を終了する。
また、ステップ２１の判断で、画像形成装置はスリープ中ではないと判断したら、ステップ２３で、表示部に記憶部の第２機器情報を表示し、この処理を終了する。
【００４３】
次に、第ｎホスト装置１は、画像形成装置２がスリープ中か否かを判定し、スリープ中と判定した場合には、画像形成装置２の機器情報を取得するための「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」を含む機器情報取得パケットの定期的な送信を抑制するように制御する。
しかしながら、画像形成装置２に印刷を依頼する場合、印刷時には画像形成装置２にセットされている原稿のサイズと方向を含む用紙情報、プリンタガンマの情報を含む印刷に必要な情報を取得しないと、第ｎホスト装置１では画像形成装置２へ送信する印刷データを生成できない。
【００４４】
第ｎホスト装置１は、この印刷に必要な情報を取得する際、ＳＮＭＰの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」のコマンドを使用して機器情報として取得するが、画像形成装置２がスリープ中の場合には、原稿サイズ、方向、プリンタガンマの情報は画像形成装置２のプリンタのエンジンを起動していないと状態が把握できないため、正しい原稿サイズ、方向、プリンタガンマの情報が含まれた機器情報が返信されない可能性がある。
【００４５】
そこで、第ｎホスト装置１は、画像形成装置２に対して印刷を依頼する必要が生じた場合、画像形成装置２の原稿サイズと方向を含む用紙情報、プリンタガンマを含む印刷前に必要な情報が取得できていないとき、画像形成装置２へヌル（全て“０（ゼロ）”のデータ）データを印刷データとして送信し、画像形成装置２をスリープ状態から復帰させ、その後に、画像形成装置２に対してＳＮＭＰの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」のコマンドを使用して原稿サイズと方向を含む用紙情報、プリンタガンマを含む印刷前に必要な情報を含む機器情報を取得する。
【００４６】
図８は、第ｎホスト装置１においてスリープ中と判定した画像形成装置２に印刷を依頼するときの処理を示すフローチャート図である。
ＣＰＵ１０は、画像形成装置がスリープ中であると判定した場合、その画像形成装置２への印刷要求が生じたとき、ステップ３１で、画像形成装置に対しての印刷に必要な情報（原稿のサイズと方向を含む用紙情報、プリンタガンマの情報）が有るか否かを判断し、有れば、ステップ３２で、その印刷に必要な情報に基づいて印刷データを作成し、画像形成装置へ印刷データを送信して印刷を開始させ、この処理を終了する。
【００４７】
また、ステップ３１の判断で、画像形成装置に対しての印刷に必要な情報がなければ、ステップ３３で、画像形成装置へヌルデータの印刷データを送信し、画像形成装置をスリープ状態から通常の印刷可能な状態に復帰させ、画像形成装置に対して印刷に必要な情報が含まれた機器情報を取得し、最初の処理に戻り、今度は、ステップ３１で印刷に必要な情報が有ると判断し、ステップ３２で、その印刷に必要な情報に基づいて印刷データを作成し、画像形成装置へ印刷データを送信して印刷を開始させ、この処理を終了する。
このようにして、画像形成装置２のスリープ状態を最大限維持しつつ、印刷自体も正しく行うことが可能となる。
【００４８】
上述の処理例では、画像形成装置２への印刷に必要な情報について説明したが、画像形成装置２から取得すべきその他の情報が正しく取得できていないと判断した場合にも、上述と同様にしてヌルデータを転送することでスリープ状態から復帰させることにより、画像形成装置２から所望の正しい情報を取得することができる。
このようにして、スリープ中と判定した画像形成装置２へヌルデータを送信することによりスリープ状態から復帰させ、正しい機器情報を取得できるので、正常に印刷を行うことが可能となるし、印刷させるためのスリープ復帰なので、スリープ時間を無駄に短縮させるようなことはない。
【産業上の利用可能性】
【００４９】
この発明による管理装置と画像形成システムは、ファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置、パーソナルコンピュータ、サーバコンピュータにおいて適用することができる。
【符号の説明】
【００５０】
１：第１ホスト装置〜第ｎホスト装置 ２：画像形成装置 ３：ネットワーク １０：ＣＰＵ １１：ネットワーク制御部 １２：更新判定部 １３：スリープ判定部 １４：記憶部 １５：表示部
【先行技術文献】
【特許文献】
【００５１】
【特許文献１】特開２００３−００６０６８号公報
【技術分野】
【０００１】
この発明は、ネットワーク上の機器の状態を管理するＰＣ、サーバを含む管理装置と、ネットワーク上の複数の端末装置が共有して利用するファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置とその画像形成装置の状態を管理する管理装置とからなる画像形成システムとに関する。
【背景技術】
【０００２】
従来、ネットワーク上の機器に対して定期的に応答要求を出し、その応答要求に対する応答状態の変化を検出し、その検出結果から機器がエラー状態であると判断すると、上記機器を利用するユーザへその旨を電子メールで通知する技術があった。
しかし、上述の技術では、ネットワーク上の機器から応答がなかった場合、その機器がエラー状態であるか否かを判断することができない。
そこで、ネットワーク上の機器に対して所定のタイミングで応答要求を出し、その応答要求に対する応答状態の変化を検出し、その検出結果（例えば、機器がエラー状態であることや正常状態であること）をネットワーク上の所定の端末装置へメールで知らせる管理装置（例えば、特許文献１参照）があった。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述のような従来の管理装置では、ネットワークに接続されている機器が正常か異常かを判断するために、定期的な問い合わせの他に任意のタイミングで応答要求を出すので、ネットワーク上の機器が待機状態よりも消費電力が低い状態（スリープ状態）にする機能を有し、そのスリープ中の時に不定期な問い合わせに答えるために待機状態に戻さなければならなくなり、省電力効果が低減するという問題があった。
この発明は上記の点に鑑みてなされたものであり、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の機器の状態を判定できるようにすることを目的とする。
【課題を解決するための手段】
【０００４】
この発明は上記の目的を達成するため、ネットワーク上の機器の機器情報を取得して保持し、その保持した機器情報に基づいて上記機器の状態を管理する管理装置において、上記取得した機器情報を記憶する記憶手段と、上記機器から新たに取得した機器情報の内容と、上記記憶手段に先に記憶されている機器情報の内容を比較し、その２つの機器情報の内容が互いに異なる場合、上記記憶手段に先に記憶されている機器情報と区別して上記新たに取得した機器情報を上記記憶手段に記憶させると共に、上記機器の機器情報が更新されたと判定する更新判定手段と、上記更新判定手段によって上記機器の機器情報が更新されたと判定された場合、上記記憶手段から上記先に記憶されている機器情報と上記新たに取得した機器情報とを読み出し、その２つの機器情報の内容に基づいて上記機器がスリープ中か否かを判定するスリープ判定手段を設けた管理装置を提供する。
【０００５】
また、上記スリープ判定手段によって上記機器がスリープ中であると判定された場合、上記機器からの機器情報の定期的な取得を抑えるように制御する手段を設けるとよい。
さらに、上記スリープ判定手段を、上記２つの機器情報の内容について、一方が上記機器の応答する内容として適切な内容であるのに対し、もう一方が通常では得られないような不適切な内容である場合に上記機器がスリープ中であると判定する手段にするとよい。
また、上記機器がスリープ中と判定された場合、上記先に記憶されている機器情報の内容を表示する手段を設けるとよい。
さらに、上記不適切な内容とは、一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトのうちの通常は書き換え可能なオブジェクトを示しているのに対し、もう一方の機器情報が書き換えを拒絶するような内容、又は一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトが存在するという応答であったのに対し、もう一方の機器情報はＭＩＢオブジェクトが存在しないことを示す内容であるとするとよい。
【０００６】
また、上記機器がスリープ中と判定された場合、上記機器に対して上記機器がスリープ中では取得できない情報を要求するとき、上記機器に対してヌルデータを送信して上記機器をスリープ状態から復帰させ、上記機器から上記スリープ中では取得できない情報を取得する手段を設けるとよい。
さらに、上記のような管理装置と、その管理装置が管理する機器である画像形成装置とにより構成されている画像形成システムを提供する。
【発明の効果】
【０００７】
この発明による管理装置は、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の機器の状態を判定することができる。
また、この発明による画像形成システムは、ネットワーク上の機器に対して不定期な応答要求を出さなくても、ネットワーク上の画像形成装置の状態を判定することができる。
【図面の簡単な説明】
【０００８】
【図１】図２に示す各ホスト装置の主要部の構成を示すブロック図である。
【図２】この発明の実施例のホスト装置と画像形成装置からなる画像形成システムの構成を示す図である。
【図３】図１に示す第ｎホスト装置が定期的に画像形成装置の機器情報を取得するときの処理を示すフローチャート図である。
【図４】図１に示す第ｎホスト装置において画像形成装置がスリープ中か否かを判定する処理を示すフローチャート図である。
【０００９】
【図５】図１に示す第ｎホスト装置において画像形成装置がスリープ中か否かの判定結果に基づいて表示するときの処理を示すフローチャート図である。
【図６】ＲＦＣ１２１３に定義されているＭＩＢツリーのサンプルを示す図である。
【図７】プリンタＭＩＢを利用したプリンタの機器情報の一例を示す図である。
【図８】図１に示す第ｎホスト装置においてスリープ中と判定した画像形成装置に印刷を依頼するときの処理を示すフローチャート図である。
【発明を実施するための形態】
【００１０】
以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
〔実施例〕
まず、この発明の実施例における用語について説明する。
スリープ：ネットワーク上の機器の消費電力が通常動作時の消費電力よりも少ない状態のことをいう。例えば、機器がファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置の場合、印刷実行中ではなく、印刷要求を待っているような状態であり、印刷時よりも低い消費電力の状態で待機している状態のことをいう。
ホスト装置：ネットワーク上の機器の状態を管理するＰＣ、サーバを含む管理装置に相当する。また、ネットワーク上の機器に接続されたデジタルカメラを含む装置の状態を管理又は監視することが可能な装置をいう。このホスト装置は、ネットワーク上の機器を後述するＳＮＭＰを利用して機器情報を収集し、その機器情報に基づいて機器を管理・監視する場合、ＳＮＭＰマネージャと呼ばれる。
【００１１】
画像形成装置：ネットワーク上の端末装置が利用するファクシミリ装置、プリンタ、複写機、複合機を含む機器である。ホスト装置によってネットワーク経由で管理・監視されるネットワーク機器であり、上記ホスト装置に対してエージェントと呼ぶ。
シンプルネットワークマネジメントプロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ：ＳＮＭＰ）：今日、幅広く使用されているネットワークを管理するためのプロトコルである。
マネジメントインフォメーションベース（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ：ＭＩＢ）：ＳＮＭＰを用いてネットワークを管理する際に使用されるツリー構造の情報データベースである。
【００１２】
ＭＩＢオブジェクト（ＭＩＢ ＯＢＪＥＣＴ）：ＭＩＢに格納されている一つ一つの情報をオブジェクト（ＯＢＪＥＣＴ）と呼ぶ。このオブジェクトのことをＭＩＢオブジェクトと表記する。このＭＩＢオブジェクトは情報の要素によってツリー構造で管理されており、それぞれのＭＩＢオブジェクトにはオブジェクトＩＤ（ＯＢＪＥＣＴ ＩＤ：ＯＩＤ）という識別子が付与されている。ＳＮＭＰマネージャ（ホスト装置）は、エージェント（ネットワーク経由で監視されるネットワーク機器）に対して、ＯＩＤを指定して情報の取得や設定の変更を要求することができる。
ネットワーク：有線又は無線によるインターネット、ローカルエリアネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：ＬＡＮ）を含む通信網である。
【００１３】
図２は、この発明の実施例のホスト装置と画像形成装置からなる画像形成システムの構成を示す図である。
この画像形成システムは、多数のホスト装置（図中の第１ホスト装置〜第ｎホスト装置：ｎは正の整数）１と１台の画像形成装置２とがネットワーク３を介して通信可能に接続されており、各ホスト装置１が画像形成装置２の印刷，スキャナ等の各種機能を共有して使用するネットワーク環境が構築されている。
また、各ホスト装置１は定期的に画像形成装置２の状態（スリープ中か否かの状態を含む）を示す機器情報を収集して保持し、その機器情報に基づいて画像形成装置２を管理している。
【００１４】
図１は、図２に示す各ホスト装置の主要部の構成を示すブロック図であり、同図では、複数のホスト装置を代表して、第ｎホスト装置１を示している。
この第ｎホスト装置１には、ＣＰＵ１０が搭載されている。
このＣＰＵ１０は、図示を省略したＲＯＭに格納された制御プログラムを、作業領域であるＲＡＭを使用して実行することにより、ネットワーク制御部１１，更新判定部１２，スリープ判定部１３の機能を果たす。
ネットワーク制御部１１は、ネットワーク３上の画像形成装置２の間で機器情報取得パケット、印刷データを含むネットワークデータの送信及び受信の制御を行う。
このネットワーク制御部１１は、ネットワーク３上の画像形成装置２の状態を把握するために、ＳＮＭＰプロトコルに従い、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドを使用して、画像形成装置２に対して定期的に機器情報取得パケットを送り、画像形成装置２に機器情報を要求する。
【００１５】
画像形成装置２は、第ｎホスト装置１からの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドによる機器情報取得パケットを受信すると、「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」を含むコマンドによる応答パケットで自装置の状態を示す機器情報を返送する。
ネットワーク制御部１１が上記応答パケットによって取得した画像形成装置２の機器情報は更新判定部１２に送られる。
更新判定部１２は、ハードディスク装置を含む記憶部１４に記憶されている保管済み機器情報である前回に取得した画像形成装置２の機器情報（「第２機器情報」という）を読み出し、今回取得した最新の機器情報（最新情報）と比較し、今回取得した機器情報の内容が第２機器情報の内容と異なると判断すると、上記第２機器情報を第１機器情報として記憶部１４に記憶し、今回取得した機器情報を第２機器情報として記憶部１４に記憶する。
【００１６】
したがって、記憶部１４には、画像形成装置２から取得した機器情報について、ある時間に取得して状態が変わる前の各機器情報を第１機器情報１ａ，１ｂ．．．．１ｎとして記憶して保持され、応答内容が変わり、更新された後の各機器情報を第２機器情報２ａ，２ｂ，２ｃ．．．２ｎとして記憶して保持される。図中の機器情報に付したサフィックスのａ，ｂ，ｃ，．．．ｎは同じ種類の「ｒｅｑｕｅｓｔ」に対する「ｒｅｓｐｏｎｓｅ」であるという形で保管している。
更新判定部１２は、機器情報の更新を検出すると、スリープ判定部１３に情報更新通知を通知する。
スリープ判定部１３は、更新判定部１２から情報更新通知を受け取ると、その情報更新通知で通知された機器情報の該当するサフィックスの第１機器情報と第２機器情報を記憶部１４から読み出し、その第１機器情報と第２機器情報の内容から、画像形成装置２がスリープ中（通常待機状態より消費電力が少ない状態）か否（スリープ状態から通常待機状態へ移行した状態）かを判定する。
【００１７】
スリープ判定部１３は、画像形成装置２がスリープ中であると判定すると、ネットワーク制御部１１へ送信する定期送信抑制信号をアサートにする。
ネットワーク制御部１１は、スリープ判定部１３からの定期送信抑制信号がアサートされると、定期的に画像形成装置２の状態を把握するために送信していた、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」のコマンドを含む機器情報取得パケットの送信を極力行わないように制御する。
このような制御をすることにより、画像形成装置２がスリープ状態から解除される回数を削減することが可能となる。
【００１８】
また、第ｎホスト装置１において画像形成装置２の状態の情報を表示したり、画像形成装置２の消耗品を管理するときには、画像形成装置２がスリープ中（スリープ状態に移行している）と判定した場合、ＬＣＤを含むディスプレイである表示部１５に、記憶部１４に保存されている該当する第１機器情報の状態を表示、または第１機器情報を使用するので、画像形成装置２の状態を表示させたりする度に機器情報を収集し、画像形成装置２を頻繁にスリープ状態から復帰させるようなことを防ぐことができる。
さらに、画像形成装置２がスリープ中でないと判定した場合には、第２機器情報の値（最新の値）を使用しても、再度、機器情報の取得のための「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を送信しても、画像形成装置２の省エネルギー効果を低減させることがない。
【００１９】
次に、第ｎホスト装置１が定期的に画像形成装置２の機器情報を取得するときの処理について詳しく説明する。
図３は、第ｎホスト装置１が定期的に画像形成装置２の機器情報を取得するときの処理を示すフローチャート図である。
第ｎホスト装置１は、ネットワーク３上の画像形成装置２の状態を定期的に把握するために、ＳＮＭＰプロトコルの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンド使用し、画像形成装置２に対し、機器情報取得パケット（Ｓｅｔ Ｒｅｑｕｅｓｔの場合、設定）によって機器情報の要求を送信する。
画像形成装置２は、上記機器情報取得パケットを受信すると、「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」を含むコマンドを使用し、応答パケットで自装置の状態を示す情報を含む機器情報を第ｎホスト装置１へ返す。
【００２０】
図３に示すように、ステップ（図中「Ｓ」で示す）１で、画像形成装置はスリープ中か否かを判断する。
ここでは、ネットワーク制御部はスリープ判断部の定期送信抑制信号がアサートされているか否かを確認し、定期送信抑制信号がアサートされていれば画像形成装置はスリープ中であると判断し、この処理を終了して、定期送信によるネットワーク機器の機器情報取得を行わない。
一方、ステップ１の判断で、定期送信抑制信号がアサートされていない場合には画像形成装置はスリープ中ではないか、または、十分な情報が集っていないために画像形成装置がスリープ中か否かを判断できないかのいずれかであり、ここでは画像形成装置はスリープ中ではない判断し、ステップ２へ進む。
ステップ２では、この場合には定期送信により画像形成装置の機器情報取得処理を行うために、画像形成装置へＳＮＭＰ通信で機器情報取得パケットを送信する。
【００２１】
画像形成装置の機器情報の取得には、「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」「Ｓｅｔ Ｒｅｑｕｅｓｔ」を含むコマンドによる機器情報取得パケットを送り、画像形成装置２からツリー構造のＭＩＢオブジェクトの情報を取得するということを逐次行っていく。
ここで画像形成装置２から逐次得られた全ての応答パケットの情報を記憶部１４に記憶していくと、記憶部１４のメモリ容量を圧迫する原因となるので、記憶部１４に格納するＭＩＢオブジェクトは予め候補を絞っておくとよい。
【００２２】
図６は、ＲＦＣ１２１３に定義されているＭＩＢツリーのサンプルを示す図である。
最初の標準ＭＩＢとしてＲＦＣ１１５６で定義されたのはＭＩＢ−１であり、管理対象オブジェクトは１１４種類定義されているが、ＯＩＤの割り当てを単純でわかり易くするために８個のグループ（ｓｙｓｔｅｍ，ｉｎｔｅｒｆａｃｅｓ，ａｔ：ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ，ｉｐ，ｉｃｍｐ，ｔｃｐ，ｕｄｐ，ｅｇｐ）に分類している。
その後のＲＦＣ１２１３において、新たに５７種類の管理対象オブジェクトが追加され、１７１種類の管理対象オブジェクトを１１種類に分類したＭＩＢ−２が定義された。
１１個のグループはｓｙｓｔｅｍ，ｉｎｔｅｒｆａｃｅｓ，ａｔ：ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ，ｉｐ，ｉｃｍｐ，ｔｃｐ，ｕｄｐ，ｅｇｐ，ｏｉｍ，ｔｒａｎｓｍｉｓｓｉｏｎ，ｓｎｍｐとなる。
【００２３】
例えば、ｓｙｓｔｅｍグループには、機器（この実施例では「画像形成装置２」）のシステムに関する設定が管理されていて、その内訳はｓｙｓＤｅｓｃｒ：ｅｎｔｉｔｙの情報、ｓｙｓＯｂｊｅｃｔＩＤ：ベンダのＯＩＤ，ｓｙｓＵｐＴｉｍｅ：最後に初期化されてからの経過時間、ｓｙｓＣｏｎｔａｃｔ：ノードの管理者の情報、ｓｙｓＮａｍｅ：ドメイン名、ｓｙｓＬｏｃａｔｉｏｎ：ノードの物理的な位置，ｓｙｓＳｅｒｖｉｃｅｓ：Ｅｎｔｉｔｙが提供するサービスを示している。
これらの情報をＯＩＤを元に管理することが可能となっている。
また、ｉｎｔｅｒｆａｃｅｓグループには、機器の保有するハードウェアインターフェースに関係する設定が管理されている。
最初のオブジェクトであるｉｆＮｕｍｂｅｒには、この機器が保有するインターフェース数が格納されており、その数に応じて設定を格納するテーブル行が追加される。
その内訳は公知なので説明を省略する。
【００２４】
例えば、ｉｆＴｙｐｅを参照したいときには、機器を管理する側のホスト装置（この実施例では「第ｎホスト装置１」）がｓｙｓｔｅｍのＯＩＤのＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケット（ＯＩＤはｉｎｔｅｒｆａｃｅｓ）を送信すると、そのＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケットで指定されているＯＩＤ（ｉｎｔｅｒｆａｃｅｓ）に所属していて、その機器で管理することが可能なＯＩＤ情報であるｉｆＮｕｍｂｅｒのＯＩＤとｉｆＴａｂｌｅのＯＩＤをホストＰＣに返す。
この時にｉｆＮｕｍｂｅｒのＯＩＤに所属する値はＩＦの数となるが、ｉｆＴａｂｌｅのＯＩＤに所属する値は、その下の階層として持っているオブジェクトの数になる。
図６に示したツリーの場合には、ｉｆｉｎｄｅｘからｉｆＳｐｅｃｉｆｉｃまでで２２のオブジェクトとなる。
【００２５】
ここで、ホスト装置は、ネットワークに接続されている機器はｉｆＴｙｐｅというオブジェクトを管理対象として保持していることを認識できるので、ＧＥＴ ＳＮＭＰｖ２−ＳＭＩパケットのＯＩＤにｉｆＴｙｐｅを指定して送信すると、機器からｉｆＴｙｐｅの値を取得することが可能となる。
このような制御を行うことで、ネットワーク上の機器（画像形成装置２）の管理対象オブジェクトを、ホスト装置（第ｎホスト装置１）は参照して操作することが可能となっている。
この中の全てのＭＩＢに対する応答結果のオブジェクトを記憶部１４に記憶するのではなく、予め、スリープ中の応答と通常状態の応答として判断できるようなオブジェクトだけを記憶部１４への保存対象として管理する。
【００２６】
例えば、画像形成装置２の場合、ｈｒＤｅｖｉｃｅＳｔａｔｕｓ，ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ等は定期的に第ｎホスト装置１が機器情報として取得してくるＭＩＢオブジェクトであり、また、これらのＭＩＢオブジェクトは、画像形成装置２がスリープ中であるが、そのままで使用できる状態であるということを示す状態が存在していないので、このｈｒＤｅｖｉｃｅＳｔａｔｕｓやｈｒＰｒｉｎｔｅｒＳｔａｔｕｓは記憶部１４への保存対象としても良い。
【００２７】
図３の説明に戻り、ステップ３で、画像形成装置から応答パケットを受信すると、ステップ４で、更新判定部は記憶部に先に保存されている同じＭＩＢオブジェクト（前回の取得で記憶されたＭＩＢオブジェクト）の内容を参照し、今回取得したＭＩＢオブジェクトの内容と比較し、今回取得した機器情報は最新情報か否かを判断する。
もし、記憶部１４に保存されていたＭＩＢオブジェクトと、今回取得したＭＩＢオブジェクトの内容が異なっていた場合には、最新情報と判断し、ステップ５で、更新判定部はスリープ判定部に情報更新通知（更新されたＭＩＢオブジェクトがわかるような識別情報を含むとよい）を送信し、ステップ６で、記憶部に先に保存されていたＭＩＢオブジェクト（第２機器情報）を記憶部上で第１機器情報として記憶し、今回取得したＭＩＢオブジェクトを第２機器情報として保存して、この処理を終了する。
【００２８】
このようにして、記憶部１４上には常に同じ画像形成装置２のＭＩＢオブジェクトについて、その画像形成装置２の状態が変化する前の第１機器情報と最新の情報である第２機器情報が保管されることになる。
もし、記憶部１４上に今回取得したＭＩＢオブジェクトと同じＯＩＤのＭＩＢオブジェクトが第２機器情報として保管されていない場合には、更新判定部１２は比較を行わずに記憶部１４に第２機器情報として今回取得したＭＩＢオブジェクトを保管する。
このときには、更新判定部１２はスリープ判定部１３への情報更新通知を送信しない。
一方、ステップ４の判断で、取得した機器情報が最新情報ではないと判断したら、すなわち、記憶部から取得した第２機器情報と今回取得したＭＩＢオブジェクトの内容が一致している場合には、更新判定部は記憶部上の第１機器情報も第２機器情報も更新しないし、スリープ判定部への情報更新通知も行わないで、この処理を終了する。
つまり、更新判定部１２がスリープ判定部１３に情報更新通知を送信する条件としては、第２機器情報と今回取得した機器情報（ＭＩＢオブジェクト）の内容が異なるときだけになる。
【００２９】
このようにして、第ｎホスト装置１では、画像形成装置２から定期的に取得した複数の応答パケットの内容の内、過去の機器情報（応答内容が変わる前の内容の機器情報）と新たに取得した機器情報（応答内容が過去のものと変わった内容の機器情報）の２つを記憶し、その２つの機器情報の内容を比較することにより、ネットワーク上に定期的な要求の他に追加して特別なパケットによる要求を発信せずに、画像形成装置２がスリープ中か否かを判定することが可能になる。
【００３０】
この実施例では、画像形成装置２に対して定期的なタイミングで取得する機器情報の違いをただ検出するのではなく、前回は正常応答（通常応答してくると想定されている範疇の応答）であったにも関わらず、明らかに異なる応答をした場合（応答が無い場合ではない）に、省エネルギー状態に入っているという判断を行う。また、機器情報を時系列的に記憶する際、その時系列の時間については、必ず、前後ではなく、例えば、前回の内容と変更が無ければ、前回の内容を保存したままにし、内容に変更が有れば新しい内容を記憶する。
こうすることで、２つの機器情報を記憶するだけで常に画像形成装置２の状態の変化を検出することを可能としている。
【００３１】
次に、第ｎホスト装置１において画像形成装置２がスリープ中か否かを判定する処理について詳しく説明する。
図４は、第ｎホスト装置１において画像形成装置２がスリープ中か否かを判定する処理を示すフローチャート図である。
スリープ判定部１３は、ステップ１１で情報更新通知を受信したか否かを判断し、情報更新通知を受信したら、ステップ１２で、記憶部から第１機器情報と第２機器情報を読み出してそれぞれの内容を比較し、第１機器情報と第２機器情報の内容に違いが有るか否かを判断する。
【００３２】
上記判断では、具体的には、例えば、第１機器情報の内容ではオブジェクトが存在するという内容であったのに、第２機器情報ではオブジェクトが存在しないといった内容になっている場合、第１機器情報ではエラーになっていないが、第２機器情報では本来エラーになることはありえない箇所がエラー発生を通知している場合、第１機器情報では書き換え可能であったのに第２機器情報では書き込み自体が行えないと示されている場合のように、本来ありえないような応答にある時点から内容が変化している場合は、第１機器情報と第２機器情報の内容に違いが有ると判断する。
ステップ１２で第１機器情報と第２機器情報の内容に違いが有ると判断したら、ステップ１３で、画像形成装置はスリープ中であると判断し、ステップ１４で、ネットワーク制御部へ定期送信抑制信号を送信し、ネットワーク制御部が機器情報取得パケットを送信しないように制御し、この処理を終了する。
【００３３】
一方、ステップ１２で第１機器情報と第２機器情報の内容に違いが無いと判断したら、ステップ１５で、画像形成装置はスリープ中ではないと判断し、ステップ１６で、ネットワーク制御部への定期送信抑制信号を解除し、ネットワーク制御部が定期的に機器情報取得パケットを送信するように戻し、この処理を終了する。
このようにして、画像形成装置２がスリープ中であると判定した場合には、ネットワーク制御部１１からの画像形成装置２の機器情報取得のための定期的なＳＮＭＰ通信（Ｇｅｔ Ｒｅｑｕｅｓｔ，Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ，Ｓｅｔ Ｒｅｑｕｅｓｔ）の送信を行わないように制御することが可能となり、画像形成装置２をスリープ状態のままに維持することが可能となる。
したがって、画像形成装置２を長い時間スリープ状態としておくことが可能となり、消費電力を低く抑えることが可能となる。
【００３４】
次に、スリープ状態を判定するために、画像形成装置２からスリープ中であることを示す情報を送信した場合、ネットワークパケットがネットワーク３上に流れるためにネットワークトラフィックが増加する。
また、そのネットワークパケットを受け取った第ｎホスト装置１が、その送られてきたネットワークパケットがスリープ中であることを示していることを理解できないと、第ｎホスト装置１としては、何を意味しているか不明なネットワークパケットを受け取っただけで意味がない。
この場合、画像形成装置２と第ｎホスト装置１の両方が双方の状態を確認できるような変更を同時に搭載していないと、画像形成装置２がスリープ中であることを認識することができない。
【００３５】
上記画像形成装置２がプリンタである場合にはプリンタＭＩＢを利用できる。
図７は、プリンタＭＩＢを利用したプリンタの機器情報の一例を示す図である。
第ｎホスト装置１は、プリンタの状態を把握するために、「Ｇｅｔ Ｒｅｑｕｅｓｔ」または「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」で定期的にプリンタに対し、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」を送信する。
プリンタは「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」を受信すると、それに応答する「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」を応答する。
「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」ではともに、プリンタが使用可能な状態でスリープ中を表すような状態は存在しない。
【００３６】
図７に示すように、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」はともに、「ｏｔｈｅｒ（１）」「ｒｕｎｎｉｎｇ（２）」「ｉｄｌｅ（３）」「ｐｒｉｎｔｉｎｇ（４）」「ｄｏｗｎ（５）」を使用して、「ｈｒＤｅｖｉｃｅＳｔａｔｕｓ」「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」でプリンタの状態を表すが、これらの値をあえて、図７にない値として「Ｇｅｔ Ｒｅｓｐｏｎｓｅ」を返したり、または、そもそも「ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ」というＯＩＤは存在しないというように、本来プリンタであれば絶対に存在するＭＩＢオブジェクトをあたかも存在していないかのように応答したり、「Ｓｅｔ Ｒｅｑｕｅｓｔ」で書き換えできるはずの値を書き換えできないというように「Ｓｅｔ Ｒｅｓｐｏｎｓｅ」で応答してきた場合、スリープ判定部１３はプリンタがスリープ中であると判定する。
【００３７】
なお、一例としてプリンタＭＩＢを挙げたが特にプリンタに限る必要はない。
また、決め打ちの実装をする場合には、変わる前の第１機器情報と最新の情報である第２機器情報を取得及び比較せずに第２機器情報だけ使用すればよいが、様々な種類のネットワークデバイスではサポートしているＭＩＢオブジェクト自体も種類が異なるし、第ｎホスト装置１側も様々な機器を監視するため、その時の応答と製品との結びつけを行うには実装が困難となる。
そこで、予め取得しておいた第１機器情報の内容と、新しく取得した機器情報であり、第１機器情報と異なる内容の機器情報を比較することによって、第１機器情報の内容はネットワーク機器として通常ありうる範囲の応答内容であるが、新しく取得した機器情報（第２機器情報）がネットワーク機器として通常ありえないような内容の応答を返した場合はスリープ中であるという判定をすることによって、製品毎の実装依存を排除しながらも、ネットワーク上の機器への定期的な機器情報の取得を排除することができる。
【００３８】
このようにして、ネットワーク３上の画像形成装置２からスリープ時に余分なネットワークパケットが送信されるわけではないので、ネットワークパケットを増加させずに済む。また、ネットワーク３上の画像形成装置２の応答内容が通常ではありえない値になっているだけで、第ｎホスト装置１としては内容を把握することは可能であり、スリープ中か否かの状態を把握するための新たなネットワークパケットによるネットワークトラフィックの増加を抑えることが可能になる。
【００３９】
次に、この実施例の第ｎホスト装置１では、画像形成装置２がスリープ中か否かを判定するために、ある時間とその後の時間で取得した２つの機器情報を必要としている。
ただし、今回取得した機器情報とそれより以前の時間で取得した直前の機器情報を比較対象と必ずしもしているわけではない。
その理由としては、ある時間に取得したときの機器情報と、今回新しく取得した機器情報を比較したときに互いの内容が同じ場合には、画像形成装置２は正常に動作しているのかと、スリープ中であるのかが判断できないからである。
もし、予め設定された特定値になっていればスリープ中であると判断できるのであれば、１回の機器情報の取得で容易に判定可能であるが、ネットワーク３上の画像形成装置２の種別が不明であり、その画像形成装置２がスリープ時にどんな応答を返してくるかを理解した上で第ｎホスト装置１上のプログラムの開発をしないと、ホスト装置はネットワーク３上の画像形成装置２がスリープ中か否かを判定することができない。
【００４０】
これは、第ｎホスト装置１と画像形成装置２とが共に同じメーカの製品であれば容易に対応可能と考えられるが、どちらかが他社の製品の場合には細かい仕様が不明なために、期待する効果が得られないことが考えられる。
そこで、第ｎホスト装置１では、まずは、画像形成装置２の正常な応答結果のＭＩＢオブジェクトの内容を保持しておき、その保存しておいた正常なＭＩＢオブジェクトの内容と比較して明らかに尋常でない内容の応答結果を取得したときに、画像形成装置２がスリープ中であると判定することによって、第ｎホスト装置１側のプログラム開発時に各製品の振る舞いを気にせずに実装することが可能になるので、開発の手間を削減することも可能になる。
【００４１】
次に、画像形成装置２は異常動作しているわけではなく、ただスリープ中であるだけで、印刷コマンドがくれば使用できるのに、使用できないような状態に扱われていると、遠隔地から管理しているときに壊れてしまったと思われたり、正しい機器情報をスリープ中に取得できないことにより、画像形成装置２の稼動率が低いと思われることがある。
そこで、ＣＰＵ１０は、画像形成装置２がスリープ中であると判定した場合、記憶部１４の第１機器情報の内容を表示部１５に表示することにより、画像形成装置２スリープ中であっても、第ｎホスト装置１上では通常稼動状態として扱われていることを、第ｎホスト装置１の作業者に示すことができるので、画像形成装置２が壊れていると間違われたり、稼働率が低いと思われることがなくなる。
【００４２】
図５は、第ｎホスト装置１において画像形成装置２がスリープ中か否かの判定結果に基づいて表示するときの処理を示すフローチャート図である。
ＣＰＵ１０は、ステップ２１で、スリープ判定部による判定結果に基づいて画像形成装置はスリープ中か否かを判断し、スリープ中なら、ステップ２２で、表示部に記憶部の第１機器情報を表示し、この処理を終了する。
また、ステップ２１の判断で、画像形成装置はスリープ中ではないと判断したら、ステップ２３で、表示部に記憶部の第２機器情報を表示し、この処理を終了する。
【００４３】
次に、第ｎホスト装置１は、画像形成装置２がスリープ中か否かを判定し、スリープ中と判定した場合には、画像形成装置２の機器情報を取得するための「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」を含む機器情報取得パケットの定期的な送信を抑制するように制御する。
しかしながら、画像形成装置２に印刷を依頼する場合、印刷時には画像形成装置２にセットされている原稿のサイズと方向を含む用紙情報、プリンタガンマの情報を含む印刷に必要な情報を取得しないと、第ｎホスト装置１では画像形成装置２へ送信する印刷データを生成できない。
【００４４】
第ｎホスト装置１は、この印刷に必要な情報を取得する際、ＳＮＭＰの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」のコマンドを使用して機器情報として取得するが、画像形成装置２がスリープ中の場合には、原稿サイズ、方向、プリンタガンマの情報は画像形成装置２のプリンタのエンジンを起動していないと状態が把握できないため、正しい原稿サイズ、方向、プリンタガンマの情報が含まれた機器情報が返信されない可能性がある。
【００４５】
そこで、第ｎホスト装置１は、画像形成装置２に対して印刷を依頼する必要が生じた場合、画像形成装置２の原稿サイズと方向を含む用紙情報、プリンタガンマを含む印刷前に必要な情報が取得できていないとき、画像形成装置２へヌル（全て“０（ゼロ）”のデータ）データを印刷データとして送信し、画像形成装置２をスリープ状態から復帰させ、その後に、画像形成装置２に対してＳＮＭＰの「Ｇｅｔ Ｒｅｑｕｅｓｔ」「Ｇｅｔ Ｎｅｘｔ Ｒｅｑｕｅｓｔ」のコマンドを使用して原稿サイズと方向を含む用紙情報、プリンタガンマを含む印刷前に必要な情報を含む機器情報を取得する。
【００４６】
図８は、第ｎホスト装置１においてスリープ中と判定した画像形成装置２に印刷を依頼するときの処理を示すフローチャート図である。
ＣＰＵ１０は、画像形成装置がスリープ中であると判定した場合、その画像形成装置２への印刷要求が生じたとき、ステップ３１で、画像形成装置に対しての印刷に必要な情報（原稿のサイズと方向を含む用紙情報、プリンタガンマの情報）が有るか否かを判断し、有れば、ステップ３２で、その印刷に必要な情報に基づいて印刷データを作成し、画像形成装置へ印刷データを送信して印刷を開始させ、この処理を終了する。
【００４７】
また、ステップ３１の判断で、画像形成装置に対しての印刷に必要な情報がなければ、ステップ３３で、画像形成装置へヌルデータの印刷データを送信し、画像形成装置をスリープ状態から通常の印刷可能な状態に復帰させ、画像形成装置に対して印刷に必要な情報が含まれた機器情報を取得し、最初の処理に戻り、今度は、ステップ３１で印刷に必要な情報が有ると判断し、ステップ３２で、その印刷に必要な情報に基づいて印刷データを作成し、画像形成装置へ印刷データを送信して印刷を開始させ、この処理を終了する。
このようにして、画像形成装置２のスリープ状態を最大限維持しつつ、印刷自体も正しく行うことが可能となる。
【００４８】
上述の処理例では、画像形成装置２への印刷に必要な情報について説明したが、画像形成装置２から取得すべきその他の情報が正しく取得できていないと判断した場合にも、上述と同様にしてヌルデータを転送することでスリープ状態から復帰させることにより、画像形成装置２から所望の正しい情報を取得することができる。
このようにして、スリープ中と判定した画像形成装置２へヌルデータを送信することによりスリープ状態から復帰させ、正しい機器情報を取得できるので、正常に印刷を行うことが可能となるし、印刷させるためのスリープ復帰なので、スリープ時間を無駄に短縮させるようなことはない。
【産業上の利用可能性】
【００４９】
この発明による管理装置と画像形成システムは、ファクシミリ装置、プリンタ、複写機、複合機を含む画像形成装置、パーソナルコンピュータ、サーバコンピュータにおいて適用することができる。
【符号の説明】
【００５０】
１：第１ホスト装置〜第ｎホスト装置 ２：画像形成装置 ３：ネットワーク １０：ＣＰＵ １１：ネットワーク制御部 １２：更新判定部 １３：スリープ判定部 １４：記憶部 １５：表示部
【先行技術文献】
【特許文献】
【００５１】
【特許文献１】特開２００３−００６０６８号公報
【特許請求の範囲】
【請求項１】
ネットワーク上の機器の機器情報を取得して保持し、その保持した機器情報に基づいて前記機器の状態を管理する管理装置において、
前記取得した機器情報を記憶する記憶手段と、
前記機器から新たに取得した機器情報の内容と、前記記憶手段に先に記憶されている機器情報の内容を比較し、その２つの機器情報の内容が互いに異なる場合、前記記憶手段に先に記憶されている機器情報と区別して前記新たに取得した機器情報を前記記憶手段に記憶させると共に、前記機器の機器情報が更新されたと判定する更新判定手段と、
前記更新判定手段によって前記機器の機器情報が更新されたと判定された場合、前記記憶手段から前記先に記憶されている機器情報と前記新たに取得した機器情報とを読み出し、その２つの機器情報の内容に基づいて前記機器がスリープ中か否かを判定するスリープ判定手段とを設けたことを特徴とする管理装置。
【請求項２】
前記スリープ判定手段によって前記機器がスリープ中であると判定された場合、前記機器からの機器情報の定期的な取得を抑えるように制御する手段を設けたことを特徴とする請求項１記載の管理装置。
【請求項３】
前記スリープ判定手段は、前記２つの機器情報の内容について、一方が前記機器の応答する内容として適切な内容であるのに対し、もう一方が通常では得られないような不適切な内容である場合に前記機器がスリープ中であると判定する手段であることを特徴とする請求項１又は２記載の管理装置。
【請求項４】
前記機器がスリープ中と判定された場合、前記先に記憶されている機器情報の内容を表示する手段を設けたことを特徴とする請求項１乃至３のいずれか一項に記載の管理装置。
【請求項５】
前記不適切な内容とは、一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトのうちの通常は書き換え可能なオブジェクトを示しているのに対し、もう一方の機器情報が書き換えを拒絶するような内容、又は一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトが存在するという応答であったのに対し、もう一方の機器情報はＭＩＢオブジェクトが存在しないことを示す内容であることを特徴とする請求項３記載の管理装置。
【請求項６】
前記機器がスリープ中と判定された場合、前記機器に対して前記機器がスリープ中では取得できない情報を要求するとき、前記機器に対してヌルデータを送信して前記機器をスリープ状態から復帰させ、前記機器から前記スリープ中では取得できない情報を取得する手段を設けたことを特徴とする請求項１乃至５のいずれか一項に記載の管理装置。
【請求項７】
請求項１乃至６のいずれか一項に記載の管理装置と、前記管理装置が管理する機器である画像形成装置とにより構成されていることを特徴とする画像形成システム。
【請求項１】
ネットワーク上の機器の機器情報を取得して保持し、その保持した機器情報に基づいて前記機器の状態を管理する管理装置において、
前記取得した機器情報を記憶する記憶手段と、
前記機器から新たに取得した機器情報の内容と、前記記憶手段に先に記憶されている機器情報の内容を比較し、その２つの機器情報の内容が互いに異なる場合、前記記憶手段に先に記憶されている機器情報と区別して前記新たに取得した機器情報を前記記憶手段に記憶させると共に、前記機器の機器情報が更新されたと判定する更新判定手段と、
前記更新判定手段によって前記機器の機器情報が更新されたと判定された場合、前記記憶手段から前記先に記憶されている機器情報と前記新たに取得した機器情報とを読み出し、その２つの機器情報の内容に基づいて前記機器がスリープ中か否かを判定するスリープ判定手段とを設けたことを特徴とする管理装置。
【請求項２】
前記スリープ判定手段によって前記機器がスリープ中であると判定された場合、前記機器からの機器情報の定期的な取得を抑えるように制御する手段を設けたことを特徴とする請求項１記載の管理装置。
【請求項３】
前記スリープ判定手段は、前記２つの機器情報の内容について、一方が前記機器の応答する内容として適切な内容であるのに対し、もう一方が通常では得られないような不適切な内容である場合に前記機器がスリープ中であると判定する手段であることを特徴とする請求項１又は２記載の管理装置。
【請求項４】
前記機器がスリープ中と判定された場合、前記先に記憶されている機器情報の内容を表示する手段を設けたことを特徴とする請求項１乃至３のいずれか一項に記載の管理装置。
【請求項５】
前記不適切な内容とは、一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトのうちの通常は書き換え可能なオブジェクトを示しているのに対し、もう一方の機器情報が書き換えを拒絶するような内容、又は一方の機器情報がＳＮＭＰ通信で取得したＭＩＢオブジェクトが存在するという応答であったのに対し、もう一方の機器情報はＭＩＢオブジェクトが存在しないことを示す内容であることを特徴とする請求項３記載の管理装置。
【請求項６】
前記機器がスリープ中と判定された場合、前記機器に対して前記機器がスリープ中では取得できない情報を要求するとき、前記機器に対してヌルデータを送信して前記機器をスリープ状態から復帰させ、前記機器から前記スリープ中では取得できない情報を取得する手段を設けたことを特徴とする請求項１乃至５のいずれか一項に記載の管理装置。
【請求項７】
請求項１乃至６のいずれか一項に記載の管理装置と、前記管理装置が管理する機器である画像形成装置とにより構成されていることを特徴とする画像形成システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−１９１５２３（Ｐ２０１０−１９１５２３Ａ）
【公開日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願番号】特願２００９−３２７１２（Ｐ２００９−３２７１２）
【出願日】平成２１年２月１６日（２００９．２．１６）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願日】平成２１年２月１６日（２００９．２．１６）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]