JP6324134B2 - 画像形成装置、画像形成装置の制御方法、及びプログラム - Google Patents

Description

本発明は、状態監視を行うホストからの要求に応じて状態を示す値を返却する画像形成装置、画像形成装置の制御方法、及びプログラムに関する。

従来より、ネットワークに接続された画像形成装置の状態監視方法として、ホストとなる情報処理装置で動作する監視アプリケーションによる定期的なポーリング監視によって、画像形成装置から状態情報の取得を行い、監視を行う技術が提案されている。その中でも手軽な監視方法として、ＳＮＭＰ(Simple Network Management Protocol)とＭＩＢ(Management Information Base)情報を用いて画像形成装置の監視を行う方法がある。例えば、監視アプリケーションが、画像形成装置に備わった特定のＭＩＢオブジェクトにアクセスし、ＭＩＢ値を取得することで状態監視を行う。

監視アプリケーションが取得するＭＩＢオブジェクトの例としてはＲＦＣ(Request for Comments)のHost Resources MIBで規格化された以下を用いることが多い。
・hrDeviceStatus
・hrPrinterStatus
・hrPrinterDetectedErrorState

上記ＭＩＢオブジェクトで取得できる値の意味に関してはＲＦＣによって規格化されている。監視アプリケーションは、画像形成装置から取得した上記ＭＩＢオブジェクトの値をＭＩＢオブジェクト単独、もしくは組み合わせによって解析して画像形成装置の状態監視を行う。

特許第２８８６１５０号公報

しかし、ＲＦＣ仕様は、技術の進歩等によって更新されている。例えば前述のhrPrinterDetectedErrorStateの値はＲＦＣ１５１４で規定され、その後ＲＦＣ２７９０で仕様が拡張されている。このため、ＲＦＣ２７９０で拡張された仕様に追随していない監視アプリケーションでは、画像形成装置から取得した値の解析が正しく行えず、その結果、画像形成装置の状態を正しく判断できないといった問題が存在する。

例えば、監視機構がホストＯＳの一部として組み込まれ、改変出来ないような場合には、前述のようなＲＦＣ仕様の変更に対応できず、画像形成装置の状態を正しく把握できないという課題があった。

例えば、Ｗｉｎｄｏｗｓ（登録商標）ＯＳの場合、ＳＮＭＰ／ＭＩＢを使用してＲＦＣのHost Resources MIBに含まれるhrPrinterDetectedErrorStateの値をポーリングして、デバイスの状態判断を行うことができる。hrPrinterDetectedErrorStateは、ＲＦＣ１５１４で規定され、その後ＲＦＣ２７９０で仕様が拡張されている。ＷｉｎｄｏｗｓＸＰ／ＶＩＳＴＡでは、拡張された仕様に追随していないため、拡張仕様により返却された値を正しく解釈できず、デバイス状態を正しく取得できないケースが存在する。例えば、Ｗｉｎｄｏｗｓ８では「用紙切れ」を判断できるが、同じ値を、Ｖｉｓｔａは「オフライン」、ＸＰは「準備完了」と誤判定してしまう等の課題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、情報処理装置からの要求に応じて画像形成装置が返却する状態を示す値を、情報処理装置における状態を示す値の定義に係る仕様に応じて追随させることを可能とし、情報処理装置において画像形成装置の状態が誤判定されてしまう状況の発生を回避する仕組みを提供することである。

本発明は、外部の情報処理装置からの所定の時間間隔に基づく要求に応じて、状態を示す値を返却する画像形成装置であって、前記状態を示す値の定義に係る仕様を、複数の仕様のいずれにするかを決定するための指定を行う指定手段と、前記所定の時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第１の返却手段と、前記返却する値が異常を示すと前記情報処理装置により判定された場合の、前記所定の時間間隔より短い時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第２の返却手段とを有することを特徴とする。

本発明によれば、情報処理装置からの要求に応じて画像形成装置が返却する状態を示す値を、情報処理装置における状態を示す値の定義に係る仕様に応じて追随させることを可能とし、情報処理装置において画像形成装置の状態が誤判定されてしまう状況の発生を回避することができる。よって、情報処理装置と画像形成装置との間で応答仕様の整合が取れ、情報処理装置から画像形成装置の状態を正しく把握することが可能となり、正しい状態監視を行うことができる。

本発明の一実施例を示す画像形成装置を含むシステムを例示する図。 ＲＦＣ１５１４とＲＦＣ２７９０との仕様差分を示した図である。 ホストによる画像形成装置の状態監視を説明する図。 ホストによる画像形成装置の状態監視を説明する図。 ホストによる画像形成装置の状態監視を説明する図。 実施例１におけるＵＩ設定画面を例示する図。 実施例１における仕様切り替え処理の流れを例示するフローチャート。 実施例２におけるＵＩ設定画面を例示する図。 実施例２における仕様切り替え処理の流れを例示するフローチャート。 実施例３におけるＵＩ設定画面を例示する図。 実施例３における仕様切り替え処理の流れを例示するフローチャート。 実施例３における仕様切り替え処理の流れを例示するフローチャート。 実施例４におけるサンプリング処理の流れを例示するフローチャート。 実施例４におけるサンプリング・テーブルを例示する図。 実施例４における仕様切り替え処理の流れを例示するフローチャート。

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

＜画像形成装置の構成＞
本実施例では、画像形成装置の一例として、コピー機能やプリンタ機能等の複数の機能を有するＭＦＰ(Multi Function Peripheral)機ついて説明する。しかし、本発明の画像形成装置は、コピー機能のみ又はプリンタ機能のみを有するＳＦＰ(Single Function Peripheral)であってもよく、これに限定されるものではない。まず、図１を参照して、画像形成装置１００の構成例について説明する。

図１は、本発明の一実施例を示す画像形成装置を含むシステムを例示する図である。
コントローラ部（制御部）１１０は、リーダ部１２０及びプリンタ部１３０と電気的に接続されている。制御部１１０は、リーダ部１２０及びプリンタ部１３０からデータを受信する。また、制御部１１０は、リーダ部１２０及びプリンタ部１３０に対して各種のコマンドを送信する。さらに、制御部１１０は、ネットワーク１６０を介してホスト（１６１、１６２）と接続されており、それらから画像データや制御コマンドを受信する。

ネットワーク１６０は、例えば、イーサネット（登録商標）で構築される。ホスト（ＰＣ１６１、１６２）は、ネットワーク１６０を介して、画像形成装置１００に対して、機器の構成情報や現在のステータス情報の監視等も行っている外部の情報処理装置である。なお、ネットワーク１６０は、イントラネットであっても、インターネットであってもよい。

リーダ部１２０は、原稿の画像を光学的に読み取り、画像データに変換する。リーダ部１２０は、原稿を読み取る機能を有するスキャナユニット１２１と、原稿をスキャナユニット１２１によって読み取り可能な位置まで搬送する原稿給紙ユニット１２２とを備える。スキャナユニット１２１が備えるスキャナコントローラ１２３は、制御部１１０からの指示に基づいて、スキャナユニット１２１と原稿給紙ユニット１２２とを制御する。

プリンタ部１３０は、画像形成（印刷）用の用紙（用紙又は記録材）を収納する給紙ユニット１３１と、画像データを用紙に転写及び定着させるマーキングユニット１３２と、印刷された用紙を排紙する排紙ユニット１３４とを備える。プリンタ部１３０は、制御部１１０からの指示に基づいて、給紙ユニット１３１から用紙をマーキングユニット１３２へ給紙し、マーキングユニット１３２で当該用紙に対して画像データを印刷した後、当該用紙を排紙ユニット１３４へ排紙する。排紙ユニット１３４は、マーキングユニット１３２で印刷された用紙に対し、ソートやステイプル等の処理を施すことができる。給紙ユニット１３１は、複数の給紙部を備えており、各給紙部には用紙が収納され、載置（設定）される。各給紙部は、例えば、普通紙や光沢紙等、複数種類の用紙を収納できる。また、各給紙部は、画像形成装置１００のプリンタ部１３０で印刷された用紙を、再び収納することもできる。給紙部の例として、給紙カセットや、給紙デッキ、手差用紙トレイ等がある。給紙部の形態はこれに限られず、その他、収納された用紙をマーキングユニット１３２に搬送できればよい。

操作部１４０は、例えば、ハードキーや、液晶表示部及びその表面上に貼り付けられたタッチパネル部を備え、それらを介してユーザから指示を受け付ける。また、操作部１４０は、液晶表示部にソフトキーや、画像形成装置１００の機能や状態を表示することができる。操作部１４０は、ユーザからの指示に対応するコマンドを、制御部１１０に送信する。ＨＤＤ(Hard Disk Drive)１５０は、画像形成装置１００の各種設定及び画像データを記憶する。なお、ＨＤＤ１５０の代わりに、ＳＳＤ（Solid State Drive）等の他の記憶装置を備えていてもよい。

上記の構成に基づき、画像形成装置１００は、例えば、コピー機能、画像データ送信機能、プリンタ機能等の種々の機能を実現する。コピー機能を実現する場合には、制御部１１０は、リーダ部１２０で原稿の画像データを読込み、プリンタ部１３０で当該画像データを用いて用紙に印刷する制御を行う。画像データ送信機能を実現する場合に、制御部１１０は、リーダ部１２０で読み込んだ原稿の画像データをコードデータに変換し、当該コードデータを、ネットワーク１６０を介してホスト（１６１、１６２）に送信する。さらに、プリンタ機能を実現する場合には、制御部１１０は、ホスト（１６１、１６２）からネットワーク１６０を介して受信したコードデータ（印刷データ）を画像データに変換し、プリンタ部１３０へ送信する。プリンタ部１３０は、受信した画像データを用いて用紙に印刷する。

制御部１１０は、図示しない、ＣＰＵ、ＲＯＭ、ＲＡＭ、ネットワークＩ／Ｆ等を有し、ＣＰＵがＲＯＭやＨＤＤ１５０等に格納されるプログラムを実行することにより、上述した各種制御を実現する。

＜標準技術の説明＞
次に、ＩＥＴＦ(Internet Engineering Task Force)がインターネットで利用される技術の標準化を目的として発行しているＲＦＣ(Request for Comments)に基づく、ネットワーク機器からの情報取得の技術について説明する。

ネットワーク上のデバイスの情報監視プロトコルとしてＳＮＭＰ(Simple Network Management Protocol)が一般的に広く用いられている。ＳＮＭＰで管理されるネットワーク機器は、ＭＩＢ(Management Information Base)情報を搭載し、管理端末からのＳＮＭＰリクエストに対してレスポンスを行うことで管理される。ＭＩＢ情報の構造についても、ＩＥＦＴで標準化がなされている。

ＭＩＢ情報は分野別の階層構造となっており、枝にはそれぞれ番号が割り当てられており、この番号をつなげたものをＯＩＤ(Object IDentifier)と呼ぶ。ＭＩＢでは、この階層構造と、ＯＩＤを持つオブジェクトがどの様な情報を持ち、どのようなデータ型で定義されているのか等が規定される。ＭＩＢには、各種のＲＦＣによって規定されるものや、企業により独自に拡張されたプライベート情報等がある。データ型の定義についても管理情報構造（ＳＭＩ(Structure of Management Information)）としてＲＦＣに規定があり、ＡＳＮ.１(Abstract Syntax Notation One)というＩＳＯとＩＴＵ−Ｔで規定された記述言語で表現される。

なお、ＲＦＣの技術仕様は不変ではなく、技術の進歩によって更新が行われる。ＲＦＣには「ＲＦＣｘｘｘｘ」という番号があり、一度公開された仕様の更新にあたっては、旧来の番号をＯｂｓｏｌｅｔｅ扱いとし、新規の番号が割り当てられる。

ＳＮＭＰとＭＩＢを用い、ネットワーク機器の状態監視をネットワーク上の遠隔のホストから行うために、Host Resources MIBが用いられている例がある。なお、Host Resources MIBには、ＲＦＣ１５１４と、更新されたＲＦＣ２７９０とが存在しており、基本的には上位互換の仕様拡張となっている。

しかしながら、ＲＦＣ１５１４と、更新されたＲＦＣ２７９０との間には、一部の互換性が損なわれている仕様が存在している。以下、図２〜図５を用いて、その仕様や、仕様非互換がネットワークに接続された画像形成装置の状態監視にどのような影響を与えているかを説明する。

＜仕様非互換の説明＞
まず、ＲＦＣ１５１４とＲＦＣ２７９０において問題となる仕様非互換のＭＩＢ情報について説明する。
各仕様における"hrPrinterDetectedErrorState OBJECT-TYPE"に係る記載では、データ型がオクテット型のバイナリ列であり、バイナリのビットアサインを上位互換となるようにＲＦＣ２７９０の定義が更新されているように見える。しかしながら、前述のＡＳＮ.１によるバイナリ変換規則を用い、データを、ネットワーク上のバイトオーダーで数値としてみた場合には、図２に示すように差が生まれる。

図２は、Host Resources MIBのhrPrinterDetectedErrorStateの仕様差を説明するための図である。
図２（ａ）において、２００は、２０００年０３月に発行されたＲＦＣ２７９０に則したビットアサインを示している。２０４は、ビットが立った時のプリンタの状態＝Ｃｏｎｄｉｔｉｏｎを示している。２０５は、１９９３年０９月に発行されたＲＦＣ１５１４則したビットアサインを示している。２０１は、ＲＦＣ１５１４とＲＦＣ２７９０とでビットアサインとしては互換となっている割り当てを示している。一方、２０２は、ＲＦＣ２７９０で仕様追加が行われ、新たなＣｏｎｄｉｔｉｏｎとビットアサインとが追加されている。なお、２０３は、Ｃｏｎｄｉｔｉｏｎの割り当てがされていないビットを示している。

前述の通り、このビットアサインを見る限りにおいては、ＲＦＣ２７９０でのhrPrinterDetectedErrorStateは、ＲＦＣ１５１４と互換性があるように見える。hrPrinterDetectedErrorStateを、ＡＳＮ.１によるバイナリ変換規則を用い、ネットワーク上のバイトオーダーで数値としての対応付けすると、図２（ｂ）に示すようになる。

図２（ｂ）では、２０６がＣｏｎｄｉｔｉｏｎ、２０７がＲＦＣ２７９０での１６進数での数値、２０８がＲＦＣ１５１４での１６進数での数値を示している。
hrPrinterDetectedErrorStateは、ＲＦＣ１５１４では１バイト（８ビット）のデータであるが、ＲＦＣ２７９０では２バイト（１６ビット）のデータとなり、ＲＦＣ２７９０で仕様追加された２１０で示す状態は、旧仕様であるＲＦＣ１５１４では示すことが出来ない。hrPrinterDetectedErrorStateを数値としてみた場合、２０９で示すｉｄｅｌ状態のみが、旧仕様のＲＦＣ１５１４と新仕様のＲＦＣ２７９０とで一致し、それ以外の状態は不一致となることが分かる。

＜ホストによる画像形成装置の状態監視＞
ホストによる画像形成装置の状態監視の例を図３〜図５に示す。
図３〜図５は、ホストによる画像形成装置の状態監視を説明する図である。

まず、図３を用いて、旧ＲＦＣに対応する状態監視の例を示す。
図３において、ホストＡ（１６１）はＲＦＣ１５１４（以下、旧ＲＦＣ）に対応したホストを示しており、画像形成装置Ａ（１００）も旧ＲＦＣに対応した画像形成装置を示している。即ち、図３は、旧ＲＦＣに則って状態監視を行うホストＡ（１６１）と、旧ＲＦＣに則って状態通知を行う画像形成装置Ａ（１００）との組み合わせでの状態監視の例に対応する。

ホストＡ（１６１）は画像形成装置Ａ（１００）の状態取得を行うため、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔオペレーションを用いhrPrinterDetectedErrorStateの取得リクエストを画像形成装置Ａ（１００）に送信する（３００）。ＧｅｔＲｅｑｕｅｓｔに含めるＯＩＤ値は、ＮＵＬＬ指定というＳＮＭＰ仕様のため、ホストＡ（１６１）が送信するＧｅｔＲｅｑｕｅｓｔのパケット（３００）からは、新旧何れのＲＦＣに対応したホストであるか、受信側の画像形成装置Ａ（１００）では判別できない。

画像形成装置Ａ（１００）は、現在の機器状態を旧ＲＦＣの状態マッピングに基づいた値でレスポンスを行う（３０１）。レスポンス３０１の返信値が「０ｘ００」の場合、図２に基づくと「ｉｄｅｌ」の状態を示しているため、ホストＡ（１６１）は、画像形成装置Ａ（１００）の状態が正常であると認識する（３０２）。

画像形成装置Ａ（１００）を正常状態として認識したホストＡ（１６１）は、正常状態と認識した機器に対しての余分なネットワークトラフィックを回避するため、次回の画像形成装置Ａ（１００）に対する状態の更新を所定の時間間隔の経過後（ここでは１０分後とする）に行う（３０３）。このリクエストに対して、画像形成装置Ａ（１００）は、給紙ユニット１３１が用紙無しの状態であると制御部１１０が判断した場合、現在の機器の状態として「０ｘ４０」の値で返信を行う（３０４）。

３０４の返信値が「０ｘ４０」の場合、図２の旧ＲＦＣの状態マッピングでは「ｎｏＰａｐｅｒ」を示しているため、ホストＡ（１６１）は、画像形成装置Ａ（１００）の状態を用紙無し（ｎｏＰａｐｅｒ）と認識する（３０５）。画像形成装置Ａ（１００）の状態が用紙無し（ｎｏＰａｐｅｒ）と認識したホストＡ（１６１）は、エラー状態からの復帰確認を行うため、エラー復帰まで上記所定の時間間隔よりも短い時間間隔（ここでは３０秒間隔とする）で、画像形成装置Ａ（１００）の状態取得を繰り返す（３０６）。３０秒後の状態に変化が無い場合、画像形成装置Ａ（１００）は用紙無し状態が継続していることを示すため、「０ｘ４０」の返信値で応答を返す（３０７）。ホストＡ（１６１）は用紙無しの状態が継続していると判断し（３０８）、再度３０秒後に画像形成装置Ａ（１００）の状態取得を行う（３０９）。

この時点で画像形成装置Ａ（１００）の給紙ユニット１３１に対して用紙補給が完了している場合には、制御部１１０は用紙無しが解消したと判断し、画像形成装置Ａ（１００）は、３０９の状態取得のリクエストに対する返信値として、「０ｘ００」（ｉｄｅｌ）で返信を行う（３１０）。３１０の返信を受けたホストＡ（１６１）は、画像形成装置Ａ（１００）の状態が正常に戻ったと判断し（３１１）、次回の画像形成装置Ａ（１００）に対する状態取得の間隔を１０分後とした状態取得を行う（３１２）。上述のように、ホストは、監視内容によっては定期的なポーリング間隔の調整を行い、これにより、画像形成装置の例えば用紙詰まり等の異常検出状態からの復帰や、ウォームアップ中からの復帰時等の印刷可能状態への状態変化時の応答性を高めることができる。

次に、図４を用いて、新ＲＦＣに対応する状態監視の例を示す。
図４において、ホストＢ（１６２）はＲＦＣ２７９０（以下、新ＲＦＣ）に対応したホストを示しており、画像形成装置Ｂ（１００）は図３の画像形成装置Ａ（１００）に対して新ＲＦＣ対応に設定変更した画像形成装置Ｂ（１００）を示している。即ち、図４は、新ＲＦＣに則って状態監視を行うホストＢ（１６２）と、新ＲＦＣに則って状態通知を行う画像形成装置Ｂ（１００）との組み合わせでの状態監視の例に対応する。

ホストＢ（１６２）は画像形成装置Ｂ（１００）の状態取得を行うため、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔオペレーションを用いhrPrinterDetectedErrorStateの取得リクエストを画像形成装置Ａ（１００）に送信する（４００）。画像形成装置Ｂ（１００）は現在の機器状態を新ＲＦＣの状態マッピングに基づいた値でレスポンスを行う（４０１）。レスポンス４０１の返信値が「０ｘ００００」の場合、図２に基づくと「ｉｄｅｌ」の状態を示しているため、ホストＢ（１６２）は、画像形成装置Ｂ（１００）の状態が正常であると認識する（４０２）。

画像形成装置Ｂ（１００）を正常状態として認識したホストＢ（１６２）は、正常状態と認識した機器に対しての余分なネットワークトラフィックを回避するため、次回の画像形成装置Ｂ（１００）に対する状態の更新を１０分後に行う（４０３）。このリクエストに対して、画像形成装置Ｂ（１００）は、給紙ユニット１３１が用紙無しの状態であると制御部１１０が判断した場合、現在の機器の状態を「０ｘ４０００」の値で返信を行う（４０４）。

４０４の返信値が「０ｘ４０００」の場合、図２の新ＲＦＣの状態マッピングでは「ｎｏＰａｐｅｒ」を示しているため、ホストＢ（１６２）は、画像形成装置Ｂ（１００）の状態を用紙無し（ｎｏＰａｐｅｒ）と認識する（４０５）。画像形成装置Ｂ（１００）の状態が用紙無し（ｎｏＰａｐｅｒ）と認識したホストＢ（１６２）は、エラー状態からの復帰確認を行うため、エラー復帰まで３０秒間隔で、画像形成装置Ｂ（１００）の状態取得を繰り返す（４０６）。３０秒後の状態に変化が無い場合、画像形成装置Ｂ（１００）は用紙無し状態が継続していることを示すため、「０ｘ４０００」の返信値で応答を返す（４０７）。ホストＢ（１６２）は用紙無しの状態が継続していると判断し（４０８）、再度３０秒後に画像形成装置Ｂ（１００）の状態取得を行う（４０９）。

この時点で画像形成装置Ｂ（１００）の給紙ユニット１３１に対して用紙補給が完了している場合には、制御部１１０は用紙無しが解消したと判断し、画像形成装置Ｂ（１００）は、４０９の状態取得のリクエストに対する返信値として、「０ｘ００００」（ｉｄｅｌ）で返信を行う（４１０）。４１０の返信を受けたホストＢ（１６２）は、画像形成装置Ｂ（１００）の状態が正常に戻ったと判断し（４１１）、次回の画像形成装置Ｂ（１００）に対する状態取得の間隔を１０分後とした状態取得を行う（４１２）。

最後に、図５を用いて、新旧ＲＦＣに対応する装置が混在する場合の状態監視の例を示す。
図５において、ホストＡ（１６１）は旧ＲＦＣに対応したホストを示しており、画像形成装置Ｂ（１００）は図３の画像形成装置Ａ（１００）に対して新ＲＦＣ対応に設定変更した画像形成装置Ｂ（１００）を示している。即ち、図５は、旧ＲＦＣに則って状態監視を行うホストＡ（１６１）と、新ＲＦＣに則って状態通知を行う画像形成装置Ｂ（１００）との組み合わせでの状態監視の例に対応する。

ホストＡ（１６１）は画像形成装置Ａ（１００）の状態取得を行うため、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔオペレーションを用いhrPrinterDetectedErrorStateの取得リクエストを画像形成装置Ｂ（１００）に送信する（５００）。ＧｅｔＲｅｑｕｅｓｔに含めるＯＩＤ値は、ＮＵＬＬ指定というＳＮＭＰ仕様のため、ホストＡ（１６１）が送信するＧｅｔＲｅｑｕｅｓｔのパケット（５００）からは、新旧何れのＲＦＣに対応したホストであるか、受信側の画像形成装置Ｂ（１００）では判別できない。

画像形成装置Ｂ（１００）は現在の機器状態を新ＲＦＣの状態マッピングに基づいた値でレスポンスを行う（５０１）。レスポンス５０１の返信値が「０ｘ００００」の場合、図２に基づくと「ｉｄｅｌ」の状態を示している。

一方、４０１の返信を受けたホストＡ（１６１）が旧ＲＦＣの解釈のみしかサポートしていない場合、ホストＡ（１６１）は、hrPrinterDetectedErrorStateの１オクテット分の解釈しかできない。即ち、ネットワークのバイトオーダーに従ってホストＡ（１６１）が受信を行い、解釈できない返信値のデータ部を切り捨てると、１６進数の下位１バイト分の解釈しかできないことと等価である。つまり、５０１の画像形成装置Ｂ（１００）からの返信値「０ｘ００００」は、ホストＡ（１６１）で受信し解釈されるのは、下位１バイト分の「０ｘ００」となる。なお、この値は、図２の旧ＲＦＣに対しての状態マッピングでは「ｉｄｅｌ」の状態を示しているため、ホストＡ（１６１）は、画像形成装置Ｂ（１００）の状態が正常であると認識する（５０２）。

画像形成装置Ｂ（１００）を正常状態として認識したホストＡ（１６１）は、正常状態と認識した機器に対しての余分なネットワークトラフィックを回避するため、次回の画像形成装置Ｂ（１００）に対する状態の更新を１０分後に行う（５０３）。このリクエストに対して、画像形成装置Ｂ（１００）は、給紙ユニット１３１が用紙無しの状態であると制御部１１０が判断した場合、現在の機器の状態を、新ＲＦＣに則った「０ｘ４０００」の値で返信を行う（５０４）。５０４の返信値が「０ｘ４０００」の場合、図２の新ＲＦＣの状態マッピングではｎｏＰａｐｅｒを示している。

一方、旧ＲＦＣの解釈しかできないホストＡ（１６１）は、前述の通り画像形成装置Ｂ（１００）からの返信値の下位１バイト分、つまり「０ｘ００」しか認識することができない。ホストＡ（１６１）が認識する「０ｘ００」の状態マッピングは図２の旧ＲＦＣに当てはめると「ｉｄｅｌ」となる。このため、ホストＡ（１６１）は、新ＲＦＣに則った画像形成装置Ｂ（１００）からの「用紙無し」の異常状態を、正常な「ｉｄｅｌ状態」として、誤認識してしまう（５０５）。

５０５で画像形成装置Ｂ（１００）の状態を「正常」と誤認識したホストＡ（１６１）は、正常状態と認識した機器に対しての余分なネットワークトラフィックを回避するロジックが働くため、次回の画像形成装置Ｂ（１００）に対する状態の更新を１０分後に行う（５０６）。この時点において、画像形成装置Ｂ（１００）の用紙なし状態が解消されていない場合、画像形成装置Ｂ（１００）からの返信値は前述したのと同様に、新ＲＦＣに則った「０ｘ０４００」で返信されることになる（５０７）。ホストＡ（１６１）は旧ＲＦＣに則った解釈しかできないため、ホストＡ（１６１）では、同様に画像形成装置Ｂ（１００）が「正常状態」であるという誤認識の状態が継続される（５０８）。

ホストＡ（１６１）は、画像形成装置Ｂ（１００）に不都合が生じた場合、機器管理者にｅ−Ｍａｉｌ通知を行ったり、画像形成装置Ｂ（１００）へ印刷Ｊｏｂの投入を抑制したり、正常な別な機器へ代行処理を行わせるなどといった役割も担っている。このため、画像形成装置Ｂ（１００）の状態を、上述の５０５や５０８のように誤認識してしまうと、システム全体の運用に支障が出る可能性がある。

ホストＡ（１６１）は、画像形成装置Ｂ（１００）の状態を正常状態（５０８）と誤認識しているため、１０分後に画像形成装置Ｂ（１００）の状態取得を行う（５０９）。この時点で画像形成装置Ｂ（１００）の給紙ユニット１３１に対して用紙補給が完了している場合には、制御部１１０は用紙無しが解消したと判断し、画像形成装置Ｂ（１００）は、５０９の状態取得のリクエストに対する返信値として、「０ｘ００００」（ｉｄｅｌ）で返信を行う（５１０）。

ホストＡ（１６１）は、前述した通り旧ＲＦＣに則って、返信値を「０ｘ００」として認識し、図２の旧ＲＦＣの状態マッピングでは旧ＲＦＣでも「ｉｄｅｌ」となるため、画像形成装置Ｂ（１００）の状態を正常（５１１）と認識する。そのため、ホストＡ（１６１）は、次回の画像形成装置Ｂ（１００）に対する状態取得の間隔を１０分後とした状態取得を行う（５１２）。

以上のように、旧ＲＦＣに則って状態監視を行う監視アプリケーションと、新ＲＦＣに則って状態通知を行う画像形成装置との組み合わせで状態監視を行った場合、監視アプリケーション側で、画像形成装置の状態を正しく把握できない。このため、監視アプリケーションが画像形成装置の状態監視のためのポーリング間隔を画像形成装置の状態に応じて変更する（例えば異常時では正常時より短縮する）といった監視機構も正しく働かなくなってしまう。上述のように、正常時には１０分間隔でポーリング監視し、異常時３０秒間隔でポーリング監視する監視機構を監視アプリケーションが備えているとする。しかし、ＲＦＣ仕様変更に対応していない監視アプリケーションでは、画像形成装置の異常を認識できず、図５に示したように、常に１０分間隔でポーリング監視することになってしまう。

本発明では、画像形成装置側で新旧仕様の利用有無に加え、新旧仕様に対応した複数の状態の生成、及び、新旧仕様の適用範囲を設定し、その設定に沿った運用を行う。以下、その設定画面を図６で示し、画像形成装置の動作を図７のフローチャートで示す。

図６は、実施例１におけるＵＩ設定画面の一例を示す図であり、画像形成装置１００の制御部１１０の制御により操作部１４０の表示画面に表示される。図６に示す設定画面は、画像形成装置の状態を示す値の定義に係るＲＦＣ仕様を複数のＲＦＣ仕様のいずれにするかを決定するための指定を行うためのものである。ここでは、画像形成装置１００の操作部１４０を用いて以下の説明を行うが、操作部１４０に代わり、ＰＣ１６１上のウェブブラウザ（不図示）等を用い、画像形成装置１００のリモートＵＩ機能に接続し、同様の設定を行う構成であってもよい。

図６において、６００は、新旧ＲＦＣ仕様を切り替えるための設定を行う画面の表示例を示す。６０１は、図２のＲＦＣ２７９０で拡張されたhrPrinterDetectedErrorState定義のｂｉｔ８〜ｂｉｔ１５の拡張定義の使用の有無を設定する設定項目である。本実施例では、６０１の設定に関し「使う」「使わない」の二択で説明を行っているが、応答仕様がさらに拡張された場合には、設定可能な選択肢をさらに追加し、ユーザが２以上の選択肢の中から設定を行えるような操作部１４０の表示、及び処理としてもよい。６０２の「使う」を設定した場合にはＲＦＣ２７９０仕様に基づいた状態返信を行い、６０３の「使わない」を設定した場合にはＲＦＣ１５１４仕様に基づいた状態返信を行う設定となる。

また、６０４は、ＲＦＣ２７９０拡張の返信値ではなく、ＲＦＣ１５１４の旧仕様の返信値を、特定のＩＰアドレスに対して行うための例外設定を使うか否かの設定を行う設定項目である。６０５の「使う」がユーザによって選択された場合、選択内容が操作部１４０から制御部１１０へ送信され、６０７〜６１３で示す例外アドレス設定のための設定項目の入力が可能となる。６０６の「使わない」がユーザによって選択された場合には６０７〜６１３で示す例外アドレス設定のための入力項目はマスクされ、操作部１４０は該入力項目への入力を受け付けない。

６０７は、ＩＰアドレスによる例外設定を行う設定項目であり、本実施例では最大５つまでの設定を可能としている。６０８の登録する例外ＩＰアドレスに関して、６０９の入力欄に、個別のＩＰアドレス、もしくはＩＰアドレスの範囲（レンジ）、プレフィックス長指定の入力をユーザが行い、６１０のＯＫボタンを押下することで設定が行われる。６０９で設定された内容は、６１１の登録済み設定としてリスト表示され、設定内容が６１２に各々リスト表示される。登録済みの設定変更を行う場合には、６１３の削除ボタンを押下することで設定の削除を行った後に、再度例外アドレス設定を行う。

６００に示す設定画面に表示された内容で問題が無い場合には、６１４の「ＯＫ」ボタンをユーザが押下することによって、設定操作が終了し、操作部１４０から制御部１１０に最終の設定内容の送信が行われる。６００の画面例は、ＲＦＣ２７９０を使用することが前提であり、例外設定としてＲＦＣ１５１４の旧仕様での返信が必要なホストのＩＰアドレスを設定する場合の入力画面例である。６００の表示画面で、６０３の「使わない」を押下すると、６３０に示す初期値の入れ替えが行われ、設定画面が６１５の表示に切り替えられる。

以下、６０３の設定でＲＦＣ２７９０を「使わない」と設定した場合の画面設定例を６１５の表示例を用いて簡単に説明する。６１５の画面例では、ＲＦＣ１５１４の旧仕様を用いることが前提となっており、例外設定としてＲＦＣ２７９０の新仕様に対応したホストのＩＰアドレスを設定する流れとなる。

６１６は、ＲＦＣ２７９０拡張を使うか否かの設定項目である。本実施例では、６１６の設定に関し「使う」「使わない」の二択で説明を行っているが、応答仕様がさらに拡張された場合には、設定可能な選択肢をさらに追加し、ユーザが２以上の選択肢の中から設定を行えるような操作部１４０の表示、及び処理としてもよい。６１７の「使う」を設定した場合にはＲＦＣ２７９０仕様に基づいた状態返信を行い、６１８の「使わない」を設定した場合にはＲＦＣ１５１４仕様に基づいた状態返信を行う設定となる。ここでユーザが６１７の「使う」を押下すると、６３０に示す初期値の入れ替えが行われ、設定画面が６００の表示に切り替えられる。

６１９は、前述の６０４とは逆に、新仕様であるＲＦＣ２７９０を適用するホストのアドレス設定を使用するか否かの設定を行う設定項目である。６２０の「使う」がユーザによって選択された場合、選択内容が操作部１４０から制御部１１０へ送信され、６２２〜６２８で示す適用アドレス設定のための設定項目の入力が可能となる。６２１の「使わない」がユーザによって選択された場合には６２２〜６２８で示す適用アドレス設定のための入力項目はマスクされ、操作部１４０は該入力項目へのユーザによる入力を受け付けない。

６２２は、ＩＰアドレスによる適用設定を行う設定項目であり、本実施例では最大５つまでの設定を可能としている。６２３の登録する適用ＩＰアドレスに関して、６２４の入力欄に、個別のＩＰアドレス、もしくはＩＰアドレスの範囲、プレフィックス長指定の入力をユーザが行い、６２５のＯＫボタンを押下することで設定が行われる。６２５で設定された内容は、６２６の登録済み設定としてリスト表示され、設定内容が６２７に各々リスト表示される。登録済みの設定変更を行う場合には、６２８の削除ボタンを押下することで設定の削除を行った後に、再度適用アドレス設定を行う。

６１５に示す設定画面に表示された内容で問題が無い場合には、６２９の「ＯＫ」ボタンをユーザが押下することによって、設定操作が終了し、操作部１４０から制御部１１０に最終の設定内容の送信が行われる。制御部１１０は、操作部１４０から受信した設定内容をＨＤＤ１５０等に保存し、以後、該設定内容を用い、図７に示すフローチャートに則った処理を行うことで、本実施例の機能を実現させる。以上の設定画面により、上記状態取得を要求するパケットの送信元の情報処理装置のアドレスもしくはアドレスの範囲ごとに、上記要求に対して返却する状態の値を作成する際に用いるＲＦＣ仕様を指定する。なお、設定方法は、同様の指定が可能なものであれば、どのようなものであってもよい。

次に、図７を用いて、図６で設定された内容に基づく画像形成装置１００の状態値の返信値切り替え処理について説明する。
図７は、実施例１における画像形成装置１００の状態値の返信値切り替え処理を例示するフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０のＣＰＵがＲＯＭ又はＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現されるものである。

Ｓ９００において、画像形成装置１００の処理が開始される。Ｓ９０１において、制御部１１０は、ＰＣ１６１やＰＣ１６２からのHost Resources MIBのhrPrinterDetectedErrorStateの問合わせのパケットを受信すると、Ｓ９０２に処理を進める。

Ｓ９０２では、制御部１１０は、図６の６０１あるいは６１６で設定された、新仕様を使用するか否かの判断を行う。そして、新仕様を使用すると判断した場合（Ｓ９０２でＹｅｓの場合）、制御部１１０は、Ｓ９０３に処理を遷移させる。

Ｓ９０３では、制御部１１０は、図６の６０４の設定を参照し、上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６１２の例外ＩＰアドレスに含まれているか否かを判断する。そして、図６の６０４の設定が、６０５の例外アドレスを「使う」かつ、上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６１２の例外ＩＰアドレスに含まれていると判断した場合（Ｓ９０３でＹｅｓの場合）、制御部１１０は、Ｓ９０５に処理を遷移させる。Ｓ９０５では、制御部１１０は、旧仕様で画像形成装置１００の状態を返信するための返信値（旧仕様に準拠した返信値）とパケットを生成し、Ｓ９０７に処理を遷移させる。

また、上記Ｓ９０３において、図６の６０４の設定が、６０６の例外アドレスを「使わない」もしくは上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６１２の例外ＩＰアドレスに含まれていないと判断した場合（Ｓ９０３でＮｏの場合）、制御部１１０は、Ｓ９０６に処理を遷移させる。Ｓ９０６では、制御部１１０は、新仕様で画像形成装置１００の状態を返信するための返信値（新仕様に準拠した返信値）とパケットを生成し、Ｓ９０７に処理を遷移させる。

Ｓ９０７では、制御部１１０は、上記Ｓ９０５又はＳ９０６で生成した返信値のパケットを、上記Ｓ９０１で受信したパケットの送り元ＰＣに対して返信処理し、Ｓ９０８で、一連の処理を完了させる。

また、上記Ｓ９０２において、新仕様を使用しないと判断した場合（Ｓ９０２でＮｏの場合）、制御部１１０は、Ｓ９０４に処理を遷移させる。Ｓ９０４では、制御部１１０は、図６の６１９の設定を参照し、上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６２７の適用ＩＰアドレスに含まれているか否かを判断する。そして、図６の６１９の設定が、６２１の適用ＩＰアドレスを「使わない」もしくは上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６２７の適用ＩＰアドレスに含まれていないと判断した場合（Ｓ９０４でＮｏの場合）、制御部１１０は、Ｓ９０５に処理を遷移させる。一方、図６の６１９の設定が、６２０の適用ＩＰアドレスを「使う」かつ、上記Ｓ９０１で受信したパケットの送り元ＰＣのＩＰアドレスが６２７の適用ＩＰアドレスに含まれていると判断した場合（Ｓ９０４でＹｅｓの場合）、制御部１１０は、Ｓ９０６に処理を遷移させる。なお、Ｓ９０５以降、Ｓ９０６以降の処理に関しては上述のものと同一であるので説明を省略する。

以上示したように、実施例１によれば、監視アプリケーション側（ホスト側）のhrPrinterDetectedErrorStateの新旧ＲＦＣの対応状況に応じて、画像形成装置が応答する状態通知の値を追随させることが可能となる。その結果、旧ＲＦＣ仕様しか解釈できない監視アプリケーションに対して、新ＲＦＣ仕様で画像形成装置が返信を行ってしまい誤判定されてしまう状況を回避可能となる。また逆に、新ＲＦＣに対応した監視アプリケーションに対して画像形成装置が旧ＲＦＣで定義された少ない範囲の状態通知しか行えないといった状況も回避可能となる。よって、監視アプリケーションは、常に適切な状態監視を継続的に行うことができる。

上記実施例１では、返信値を生成する新旧仕様を、状態取得を要求するパケットの送信元のＩＰアドレスに応じて切り替える構成を説明した。実施例２では、返信値を生成する新旧仕様を、新旧仕様の切り替え期日と曜日ごとの時間帯設定に応じて切り替えるように構成する。以下、その設定画面を図８で示し、画像形成装置の動作を図９のフローチャートで示す。

図８は、実施例２におけるＵＩ設定画面の一例を示す図であり、画像形成装置１００の制御部１１０の制御により操作部１４０の表示画面に表示される。図８に示す設定画面は、画像形成装置の状態を示す値の定義に係るＲＦＣ仕様を複数のＲＦＣ仕様のいずれにするかを決定するための指定を行うためのものである。ここでは、画像形成装置１００の操作部１４０を用いて以下の説明を行うが、操作部１４０に代わり、ＰＣ１６１上のウェブブラウザ（不図示）等を用い、画像形成装置１００のリモートＵＩ機能に接続し、同様の設定を行う構成であってもよい。

図８において、７００は、新旧ＲＦＣ仕様を切り替えるための設定を行う画面の表示例を示す。７０１は、図２のＲＦＣ２７９０で拡張されたhrPrinterDetectedErrorState定義のｂｉｔ８〜ｂｉｔ１５の拡張定義の使用の有無を設定する設定項目である。本実施例では、７０１の設定に関し「使う」「使わない」の二択で説明を行っているが、応答仕様がさらに拡張された場合には、設定可能な選択肢をさらに追加し、ユーザが２以上の選択肢の中から設定を行えるような操作部１４０の表示、及び処理としてもよい。７０２の「使う」を設定した場合にはＲＦＣ２７９０仕様に基づいた状態返信を行い、７０３の「使わない」を設定した場合にはＲＦＣ１５１４仕様に基づいた状態返信を行う設定となる。

また、７０４は、ＲＦＣ２７９０拡張の返信値ではなく、ＲＦＣ１５１４の旧仕様の返信値を、特定の期日まで例外として使用するか否かの設定を行う設定項目である。７０５の「使う」がユーザによって選択された場合、選択内容が操作部１４０から制御部１１０へ送信され、７０７で示す例外期日設定のための設定項目の入力が可能となり、設定後に、７０８の「ＯＫ」ボタンをユーザが押下することによって設定が完了となる。７０６の「使わない」がユーザによって選択された場合には、７０７で示す例外期日設定のための設定項目の入力項目はマスクされ、操作部１４０はユーザによる該入力項目への入力を受け付けない。

７０９は、曜日と、曜日ごとの設定された時間帯において、ＲＦＣ２７９０拡張の返信値ではなく、ＲＦＣ１５１４の旧仕様の返信値を用いる例外設定を使用するか否かを設定するための設定項目である。７１０の「使う」がユーザによって選択された場合、選択内容が操作部１４０から制御部１１０へ送信され、７１２〜７１５で示す例外設定のための設定項目の入力が可能となる。７１１の「使わない」がユーザによって選択された場合には、７１２〜７１５で示す例外設定のための設定項目の入力項目はマスクされ、操作部１４０は該入力項目へのユーザによる入力を受け付けない。

７１２は曜日を示しており、ユーザは、曜日ごとに例外適用の開始時刻の入力を７１３に、終了時刻の入力を７１４に行う。これらを解除する場合には、曜日ごとに設けられた７１５の解除ボタンを押下することによって行う。

７００の設定画面に表示された内容で問題が無い場合には、７１６の「ＯＫ」ボタンをユーザが押下することによって、設定操作が終了し、操作部１４０から制御部１１０に最終の設定内容の送信が行われる。７００の画面例は、ＲＦＣ２７９０を使用することが前提であり、例外設定としてＲＦＣ１５１４の旧仕様での返信が必要な期日と曜日ごとの例外適用の設定を行う場合の入力画面例である。７００の表示画面で、７０３の「使わない」を押下すると、７３４に示す初期値の入れ替えが行われ、設定画面が７１７の表示に切り替えられる。

以下、７０３の設定でＲＦＣ２７９０を「使わない」と設定した場合の画面設定例を７１７の表示例を用いて簡単に説明する。７１７の画面例では、ＲＦＣ１５１４の旧仕様を用いることが前提である。７１８は、ＲＦＣ２７９０拡張を使うか否かの設定項目である。本実施例では、７１８の設定に関し「使う」「使わない」の二択で説明を行っているが、応答仕様がさらに拡張された場合には、設定可能な選択肢をさらに追加し、ユーザが２以上の選択肢の中から設定を行えるような操作部１４０の表示、及び処理としても良い。７１９の「使う」を設定した場合にはＲＦＣ２７９０仕様に基づいた状態返信を行い、７２０の「使わない」を設定した場合にはＲＦＣ１５１４仕様に基づいた状態返信を行う設定となる。ここでユーザが７１９の「使う」を押下すると、７３４に示す初期値の入れ替えが行われ、７００の設定画面の表示に切り替えられる。

７２１〜７２５は、上述の７０４〜７２５の設定項目と同じであるため説明を割愛する。７２６は、曜日と、曜日ごとの設定された時間帯において、ＲＦＣ１５１４の返信値ではなく、ＲＦＣ２７９０の新仕様の返信値を用いる例外設定を使用するか否かを設定するための設定項目である。７２７の「使う」がユーザによって選択された場合、選択内容が操作部１４０から制御部１１０へ送信され、７２９〜７３２で示す例外設定のための設定項目の入力が可能となる。７２８の「使わない」がユーザによって選択された場合には、７２９〜７３２で示す例外設定のための設定項目の入力項目はマスクされ、操作部１４０は該入力項目へのユーザによる入力を受け付けない。

７２９は曜日を示しており、ユーザは、曜日ごとに例外適用の開始時刻の入力を７３０に、終了時刻の入浴を７３１に行う。これらを解除する場合には、曜日ごとに設けられた７３２の解除ボタンを押下することによって行う。

７１７の設定画面に表示された内容で問題が無い場合には、７３３の「ＯＫ」ボタンをユーザが押下することによって、設定操作が終了し、操作部１４０から制御部１１０に最終の設定内容の送信が行われる。制御部１１０は、操作部１４０から受信した設定内容をＨＤＤ１５０等に保存し、以後、該設定内容を用い、図９に示すフローチャートに則った処理を行うことで、本実施例の機能を実現させる。

なお、図８では、曜日と時間帯の組み合わせごとに旧仕様又は新仕様を例外として用いることを設定した。しかし、単に曜日ごとに旧仕様又は新仕様を例外として用いる設定であっても、単に時間帯ごとに旧仕様又は新仕様を例外として用いる設定であってもよい。以上の設定画面により、上記状態取得の要求を受ける時間帯ごと、曜日ごと、もしくは時間帯と曜日の組み合わせごとに、上記要求に対して返却する状態の値を作成する際に用いるＲＦＣ仕様を指定する。また、該ＲＦＣ仕様を切り替える期日を指定する。なお、設定方法は、同様の指定可能なものであれば、どのようなものであってもよい。

次に、図９を用いて、図８で設定された内容に基づく画像形成装置１００の状態値の返信値切り替え処理について説明する。
図９は、実施例２における画像形成装置１００の状態値の返信値切り替え処理を例示するフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０のＣＰＵがＲＯＭ又はＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現されるものである。

Ｓ１０００において、画像形成装置１００の処理が開始される。Ｓ１００１において、画像形成装置１００の制御部１１０は、ＰＣ１６１やＰＣ１６２からのHost Resources MIBのhrPrinterDetectedErrorStateの問合わせのパケットを受信すると、Ｓ１００２に処理を進める。

Ｓ１００２では、制御部１１０は、図８の７０１あるいは７１８で設定された、新仕様を使用するか否かの判断を行う。そして、新仕様を使用すると判断した場合（Ｓ１００２でＹｅｓの場合）、制御部１１０は、Ｓ１００３に処理を遷移させる。

Ｓ１００３では、制御部１１０は、図８の７０４の設定を参照し、例外期日の設定を「使う」と設定されているか否かを判断する。そして、例外期日の設定を「使う」と設定されていると判断した場合（Ｓ１００３でＹｅｓの場合）、制御部１１０は、Ｓ１００４に処理を遷移させる。

Ｓ１００４では、制御部１１０は、図８の７０７で設定された例外期日設定の日時と現在の日時とを比較し、現在の日時が例外期日設定の日時の前であるか否かを判断する。そして、現在の日時が例外期日設定の日時の前であると判断した場合（Ｓ１００４でＹｅｓの場合）、制御部１１０は、Ｓ１００５に処理を遷移させる。

Ｓ１００５では、制御部１１０は、図８の７０９の設定を参照し、例外（旧仕様）ウィークリータイマを「使う」か否かを判断する。そして、例外（旧仕様）ウィークリータイマを「使う」と判断した場合（Ｓ１００５でＹｅｓの場合）、制御部１１０は、Ｓ１００６に処理を遷移させる。一方、例外（旧仕様）ウィークリータイマを「使わない」と判断した場合（Ｓ１００５でＮｏの場合）、制御部１１０は、そのままＳ１００７に処理を遷移させる。

Ｓ１００６では、制御部１１０は、図８の７１２〜７１４の曜日ごとの例外（旧仕様）時刻の設定と、現在の曜日と日時とを比較して、現在の曜日と日時が例外の範囲内であるか否かを判断する。そして、現在の曜日と日時が例外の範囲内であると判断した場合（Ｓ１００６でＹｅｓの場合）、制御部１１０は、Ｓ１００７に処理を遷移させる。Ｓ１００７では、制御部１１０は、旧仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１０１１に処理を進める。

また、上記Ｓ１００３において、例外期日の設定を「使わない」と設定されていると判断した場合（Ｓ１００３でＮｏの場合）、制御部１１０は、Ｓ１０００８に処理を遷移させる。また、上記Ｓ１００４において、現在の日時が例外期日設定の日時の前でないと判断した場合（Ｓ１００４でＮｏの場合）にも、制御部１１０は、Ｓ１００８に処理を遷移させる。また、上記Ｓ１００６において、現在の曜日と日時が例外の範囲内でないと判断した場合（Ｓ１００６でＮｏの場合）にも、制御部１１０は、Ｓ１００８に処理を遷移させる。Ｓ１００８では、制御部１１０は、新仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１０１１に処理を進める。

Ｓ１０１１では、上記Ｓ１００１で受信したパケットの送り元ＰＣに対して、上記Ｓ１００７又はＳ１００８で生成したパケットを返信する返信処理を行い、Ｓ１０１２において、一連の処理を完了させる。

また、上記Ｓ１００２において、新仕様を使用しないと判断した場合（Ｓ１００２でＮｏの場合）、制御部１１０は、Ｓ１００９に処理を遷移させる。Ｓ１００９では、制御部１１０は、図８の７２６の設定を参照し、例外（新仕様）ウィークリータイマを「使う」か否かを判断する。そして、例外（新仕様）ウィークリータイマを「使わない」と判断した場合（Ｓ１００９でＮｏの場合）、制御部１１０は、Ｓ１００７に処理を遷移させる。一方、例外（新仕様）ウィークリータイマを「使う」と判断した場合（Ｓ１００９でＹｅｓの場合）、制御部１１０は、Ｓ１０１０に処理を遷移させる。

Ｓ１０１０では、制御部１１０は、図８の７２９〜７３１の曜日ごとの例外（新仕様）時刻の設定と、現在の曜日と日時とを比較して、現在の曜日と日時が例外の範囲内であるか否かを判断する。そして、現在の曜日と日時が例外の範囲内でないと判断した場合（Ｓ１０１０でＮｏの場合）、制御部１１０は、Ｓ１００７に処理を遷移させる。一方、現在の曜日と日時が例外の範囲内であると判断した場合（Ｓ１０１０でＹｅｓの場合）、制御部１１０は、Ｓ１００８に処理を遷移させる。なお、Ｓ１００７以降、Ｓ１００８以降の処理に関しては上述のものと同一であるので説明を省略する。

以上示したように、実施例２によれば、新旧仕様の切り替え期日と曜日ごとの時間帯設定に応じて、画像形成装置が応答する状態通知の値の新旧仕様を切り替えることが可能となる。よって、監視アプリケーション側（ホスト側）の新旧仕様の切り替え日や、監視スケジュール等に合わせて設定を行っておくことにより、旧ＲＦＣ仕様しか解釈できない監視アプリケーションに対して、新ＲＦＣ仕様で画像形成装置が返信を行ってしまい誤判定されてしまう状況を回避可能となる。また逆に、新ＲＦＣに対応した監視アプリケーションに対して画像形成装置が旧ＲＦＣで定義された少ない範囲の状態通知しか行えないといった状況も回避可能となる。よって、監視アプリケーションは、常に適切な状態監視を継続的に行うことができる。

実施例３では、返信値を生成する新旧仕様を、ＳＮＭＰのプロトコルバージョンと、ＳＮＭＰの仕様として複数存在する情報取得系のオペレーションによって切り替えるように構成する。以下、その設定画面を図１０で示し、画像形成装置の動作を図１１及び図１２のフローチャートで示す。

図１０は、実施例３におけるＵＩ設定画面の一例を示す図であり、画像形成装置１００の制御部１１０の制御により操作部１４０の表示画面に表示される。図６に示す設定画面は、画像形成装置の状態を示す値の定義に係るＲＦＣ仕様を複数のＲＦＣ仕様のいずれにするかを決定するための指定を行うためのものである。ここでは、画像形成装置１００の操作部１４０を用いて以下の説明を行うが、操作部１４０に代わり、ＰＣ１６１上のウェブブラウザ（不図示）等を用い、画像形成装置１００のリモートＵＩ機能に接続し、同様の設定を行う構成であってもよい。

図１０において、８００は、新旧ＲＦＣ仕様を切り替えるための設定を行う画面の表示例を示す。８０１で図２のＲＦＣ２７９０で拡張されたhrPrinterDetectedErrorState定義のｂｉｔ８〜ｂｉｔ１５の拡張定義の使用の設定全体を示す。この例では、ＳＮＭＰのプロトコルバーションが「ｖ１」の情報取得系オペレーションと、「ｖ１」の情報取得系オペレーションについて設定可能である。

８０２は、ＳＮＭＰのプロトコルバーションが「ｖ１」の情報取得系オペレーションに関して、ＲＦＣ２７９０拡張の返信値を使うか否かの設定を行う設定項目である。ＳＮＭＰｖ１の仕様では、ホストがターゲット機器からＭＩＢ情報の取得を行うオペレーションとしてＧｅｔＲｅｑｕｅｓｔ（８０３）とＧｅｔＮｅｘｔＲｅｑｕｅｓｔ（８０４）が存在している。

８０２の設定項目では、８０５の「使う」を選択した場合には、ＳＮＭＰｖ１の取得系の全オペレーションに対して新仕様が適用され、８０８で示すオペレーション毎の設定項目はマスクされ、操作部１４０は設定項目８０８へのユーザによる入力を受け付けない。８０６の「使わない」を選択した場合には、ＳＮＭＰｖ１の取得系の全オペレーションに対して旧仕様が適用され、８０８で示すオペレーション毎の設定項目はマスクされ、操作部１４０は設定項目８０８へのユーザによる入力を受け付けない。

８０７の「個別設定」が選択されたことが操作部１４０から画像形成装置１００の制御部１１０に通知されると、制御部１１０は、８０８で示すオペレーション毎の設定項目のマスクを解除するように操作部１４０に通知する。これにより、操作部１４０では、８０８へのユーザによる入力を受け付ける。よって、ＧｅｔＲｅｑｕｅｓｔ（８０３）とＧｅｔＮｅｘｔＲｅｑｕｅｓｔ（８０４）のオペレーション毎に新旧の仕様の切り替えを設定することが可能となる。

８０２は、ＳＮＭＰのプロトコルバーションが「ｖ３」の情報取得系オペレーションに関して、ＲＦＣ２７９０拡張の返信値を使うか否かの設定を行う設定項目である。ＳＮＭＰｖ３の仕様では、ホストがターゲット機器からＭＩＢ情報の取得を行うオペレーションとしてＧｅｔＲｅｑｕｅｓｔ（８１０）と、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ（８１１）と、ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ（８１２）が存在している。

８０９の設定項目では、８１３の「使う」を選択した場合には、ＳＮＭＰｖ３の取得系の全オペレーションに対して新仕様が適用され、８１６で示すオペレーション毎の設定項目はマスクされ、操作部１４０は設定項目８１６へのユーザによる入力を受け付けない。８１４の「使わない」を選択した場合には、ＳＮＭＰｖ３の取得系の全オペレーションに対して旧仕様が適用され、８１６で示すオペレーション毎の設定項目はマスクされ、操作部１４０は設定項目８１６へのユーザによる入力を受け付けない。

８１５の「個別設定」が選択されたことが操作部１４０から画像形成装置１００の制御部１１０に通知されると、制御部１１０は、８０８で示すオペレーション毎の設定項目のマスクを解除するように操作部１４０に通知する。これにより、操作部１４０では、８１６へのユーザによる入力を受け付ける。よって、ＧｅｔＲｅｑｕｅｓｔ（８１０）と、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ（８１１）と、ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ（８１２）のオペレーション毎に新旧の仕様の切り替えを設定することが可能となる。

８００の設定画面に表示された内容で問題が無い場合には、８１７の「ＯＫ」ボタンをユーザが押下することによって、設定操作が終了し、操作部１４０から制御部１１０に最終の設定内容の送信が行われる。なお、８００の設定画面では、８０８、８１６の設定に関し有無の二択で説明を行っているが、応答仕様がさらに拡張された場合には、設定可能な選択肢をさらに追加し、ユーザが２以上の選択肢の中から設定を行えるような操作部１４０の表示、及び処理としてもよい。以上の設定画面により、上記状態取得の要求に対応するＳＮＭＰのバージョンごとに、上記要求に対して返却する状態の値を作成する際に用いるＲＦＣ仕様を指定する。また、ＳＮＭＰのオペレーションごとに、該ＲＦＣ仕様を指定する。なお、設定方法は、同様の指定可能なものであれば、どのようなものであってもよい。

次に、図１１、図１２を用いて、図１０で設定された内容に基づく画像形成装置１００の状態値の返信値切り替え処理について説明する。
図１１、図１２は、実施例３における画像形成装置１００の状態値の返信値切り替え処理を例示するフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０のＣＰＵがＲＯＭ又はＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現されるものである。

Ｓ１１００において、画像形成装置１００の処理が開始される。Ｓ１１０１において、画像形成装置１００の制御部１１０は、ＰＣ１６１やＰＣ１６２からのHost Resources MIBのhrPrinterDetectedErrorStateの問合わせのパケットを受信すると、Ｓ１１０２に処理を進める。本実施例では、画像形成装置１００がサポートしているＳＮＭＰのプロトコルバージョンを「１」と「３」として説明する。

Ｓ１１０２において、制御部１１０は、上記Ｓ１１０１で受信したパケットの解析を行い、ＳＮＭＰのプロトコルバージョンが「１」であるか否かを判断する。そして、ＳＮＭＰのプロトコルバージョンが「１」であると判断した場合（Ｓ１１０２でＹｅｓの場合）、制御部１１０は、Ｓ１１０６に処理を進める。

Ｓ１１０６では、制御部１１０は図１０の８０２の設定が新仕様を「使う」か否かの判断を行う。そして、８０２の設定が新仕様を「使う」であると判断した場合（Ｓ１１０６でＹｅｓの場合）、制御部１１０は、Ｓ１１０７に処理を遷移させる。Ｓ１１０７では、制御部１１０は、新仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１１０８に処理を遷移させる。

一方、上記Ｓ１１０６において、８０２の設定が新仕様を「使う」でないと判断した場合（Ｓ１１０６でＮｏの場合）、制御部１１０は、Ｓ１１１０に処理を遷移させる。Ｓ１１１０では、制御部１１０は、８０２の設定が「個別設定」であるか否かの判断を行う。そして、８０２の設定が「個別設定」でないと判断した場合（Ｓ１１１０でＮｏの場合）、即ち、８０２の設定が「使わない」の場合、制御部１１０は、Ｓ１１１３に処理を遷移させる。Ｓ１１１３では、制御部１１０は、旧仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１１０８に処理を遷移させる。

Ｓ１１０８では、上記Ｓ１００１で受信したパケットの送り元ＰＣに対して、上記Ｓ１１０７又はＳ１１１３で生成したパケットを返信する返信処理を行い、Ｓ１１０９において、一連の処理を完了させる。

また、上記Ｓ１１１０において、８０２の設定が「個別設定」であると判断した場合（Ｓ１１１０でＹｅｓの場合）、制御部１１０は、Ｓ１１１１に処理を遷移させる。Ｓ１１１１では、制御部１１０は、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」であるか否かを判断する。そして、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」であると判断した場合（Ｓ１１１１でＹｅｓの場合）、制御部１１０は、Ｓ１１１２に処理を遷移させる。Ｓ１１１２では、制御部１１０は、図１０の８０８の設定された「ＧｅｔＲｅｑｕｅｓｔ」の設定値を参照し、新仕様を「使う」設定であるか否かを判断する。そして、「ＧｅｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使う」設定であると判断した場合（Ｓ１１１２でＹｅｓの場合）、制御部１１０は、Ｓ１１０７に処理を遷移させ、一方、「ＧｅｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使わない」設定であると判断した場合（Ｓ１１１２でＮｏの場合）、制御部１１０は、Ｓ１１１３に処理を遷移させる。なお、Ｓ１１０７以降、Ｓ１１１３以降の処理に関しては上述のものと同一であるので説明を省略する。

また、上記Ｓ１１１１において、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」でないと判断した場合（Ｓ１１１１でＮｏの場合）、制御部１１０は、Ｓ１１１４に処理を遷移させる。Ｓ１１１４では、制御部１１０は、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」であるか否かを判断する。そして、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」であると判断した場合（Ｓ１１１４でＹｅｓの場合）、制御部１１０は、Ｓ１１１５に処理を遷移させる。Ｓ１１１５では、制御部１１０は、図１０の８０８の設定された「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値を参照し、新仕様を「使う」設定であるか否かを判断する。そして、「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使う」設定であると判断した場合（Ｓ１１１５でＹｅｓの場合）、制御部１１０は、Ｓ１１０７に処理を遷移させ、一方、「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使わない」設定であると判断した場合（Ｓ１１１５でＮｏの場合）、制御部１１０は、Ｓ１１１３に処理を遷移させる。なお、Ｓ１１０７以降、Ｓ１１１３以降の処理に関しては上述のものと同一であるので説明を省略する。

また、上記Ｓ１１１４において、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」でないと判断した場合（Ｓ１１１４でＮｏの場合）、制御部１１０は、Ｓ１１１６に処理を遷移させる。Ｓ１１１６では、制御部１１０は、ＳＮＭＰｖ１の既定外オペレーションと判断し、エラーで返信するためのパケットを生成し、上記Ｓ１１０１で受信したパケットの送り元ＰＣに対してエラーの返信処理を行い、Ｓ１１０９で一連の処理を完了させる。

また、上記Ｓ１１０２において、ＳＮＭＰのプロトコルバージョンが「１」でないと判断した場合（Ｓ１１０２でＮｏの場合）、制御部１１０は、Ｓ１１０３に処理を進める。Ｓ１１０３では、制御部１１０は、ＳＮＭＰのプロトコルバージョンが「３」であるか否かを判断する。そして、ＳＮＭＰのプロトコルバージョンが「３」でないと判断した場合（Ｓ１１０３でＮｏの場合）、制御部１１０は、Ｓ１１０５に処理を進める。Ｓ１１０５では、サポート外のプロトコルバージョンであるため、制御部１１０は、上記Ｓ１１０１で受信したパケットを破棄し、処理をＳ１１０９に遷移させ、処理終了となる。

一方、ＳＮＭＰのプロトコルバージョンが「３」であると判断した場合（Ｓ１１０３でＹｅｓの場合）、制御部１１０は、Ｓ１１０４に遷移させる。Ｓ１１０４以降の処理に関しては、図１２のＳ１２００以降で説明を行う。

図１２のＳ１２００において、ＳＮＭＰのプロトコルバージョンが「３」である時の判別処理が開始される。Ｓ１２０１において、制御部１１０は、図１０の８０９の設定が新仕様を「使う」か否かの判断を行う。そして、８０９の設定が新仕様を「使う」であると判断した場合（Ｓ１２０１でＹｅｓの場合）、制御部１１０は、Ｓ１２０２に処理を遷移させる。Ｓ１２０２では、制御部１１０は、新仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１２０３に処理を遷移させる。

一方、上記Ｓ１２０１において、８０９の設定が新仕様を「使う」でないと判断した場合（Ｓ１２０１でＮｏの場合）、制御部１１０は、Ｓ１２０５に処理を遷移させる。Ｓ１２０５は、制御部１１０は、８０９の設定が「個別設定」であるか否かの判断を行う。そして、８０９の設定が「個別設定」でないと判断した場合（Ｓ１２０５でＮｏの場合）、即ち、８０９の設定が「使わない」の場合、制御部１１０は、Ｓ１２０８に処理を遷移させる。Ｓ１２０８では、制御部１１０は、旧仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１２０３に処理を遷移させる。

Ｓ１２０３では、上記図１１のＳ１１０１で受信したパケットの送り元ＰＣに対して、上記Ｓ１２０２又はＳ１２０８で生成したパケットを返信する返信処理を行い、Ｓ１２０４において、一連の処理を完了させる。

また、上記Ｓ１２０５において、８０９の設定が「個別設定」であると判断した場合（Ｓ１２０５でＹｅｓの場合）、制御部１１０は、Ｓ１２０６に処理を遷移させる。Ｓ１２０６では、制御部１１０は、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」であるか否かを判断する。そして、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」であると判断した場合（Ｓ１２０６でＹｅｓの場合）、制御部１１０は、Ｓ１２０７に処理を遷移させる。Ｓ１２０７では、制御部１１０は、図１０の８１６の設定された「ＧｅｔＲｅｑｕｅｓｔ」の設定値を参照し、新仕様を「使う」設定であるか否かを判断する。そして、「ＧｅｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使う」設定であると判断した場合（Ｓ１２０７でＹｅｓの場合）、制御部１１０は、Ｓ１２０２に処理を遷移させ、一方、「ＧｅｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使わない」設定であると判断した場合（Ｓ１２０７でＮｏの場合）、制御部１１０は、Ｓ１２０８に処理を遷移させる。なお、Ｓ１２０２以降、Ｓ１２０８以降の処理に関しては上述のものと同一であるので説明を省略する。

また、上記Ｓ１２０６において、ＳＮＭＰオペレーションが「ＧｅｔＲｅｑｕｅｓｔ」でないと判断した場合（Ｓ１２０６でＮｏの場合）、制御部１１０は、Ｓ１２０９に処理を遷移させる。Ｓ１２０９では、制御部１１０は、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」であるか否かを判断する。そして、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」であると判断した場合（Ｓ１２０９でＹｅｓの場合）、制御部１１０は、Ｓ１２１０に処理を遷移させる。Ｓ１２１０では、制御部１１０は、図１０の８１６の「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値を参照し、新仕様を「使う」設定であるか否かを判断する。そして、「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使う」設定であると判断した場合（Ｓ１２１０でＹｅｓの場合）、制御部１１０は、Ｓ１２０２に処理を遷移させ、一方、「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」の設定値が新仕様を「使わない」設定であると判断した場合（Ｓ１２１０でＮｏの場合）、制御部１１０は、Ｓ１２０８に処理を遷移させる。なお、Ｓ１２０２以降、Ｓ１２０８以降の処理に関しては上述のものと同一であるので説明を省略する。

また、上記Ｓ１２０９において、ＳＮＭＰオペレーションが「ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ」でないと判断した場合（Ｓ１２０９でＮｏの場合）、制御部１１０は、Ｓ１２１１に処理を遷移させる。Ｓ１２１１では、制御部１１０は、ＳＮＭＰオペレーションが「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」であるか否かを判断する。そして、ＳＮＭＰオペレーションが「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」であると判断した場合（Ｓ１２１１でＹｅｓの場合）、制御部１１０は、Ｓ１２１２に処理を遷移させる。Ｓ１２１２では、制御部１１０は、図１０の８１６の「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」の設定値を参照し、新仕様を「使う」設定であるか否かを判断する。そして、「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」の設定値が新仕様を「使う」設定であると判断した場合（Ｓ１２１２でＹｅｓの場合）、制御部１１０は、Ｓ１２０２に処理を遷移させ、一方、「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」の設定値が新仕様を「使わない」設定であると判断した場合（Ｓ１２１２でＮｏの場合）、制御部１１０は、Ｓ１２０８に処理を遷移させる。なお、Ｓ１２０２以降、Ｓ１２０８以降の処理に関しては上述のものと同一であるので説明を省略する。

また、上記Ｓ１２１１において、ＳＮＭＰオペレーションが「ＧｅｔＢｕｌｋＲｅｑｕｅｓｔ」でないと判断した場合（Ｓ１２１１でＮｏの場合）、制御部１１０は、Ｓ１２１３に処理を遷移させる。Ｓ１２１３では、制御部１１０は、ＳＮＭＰｖ３の既定外オペレーションと判断し、エラーで返信するためのパケットを生成し、上記図１１のＳ１１０１で受信したパケットの送り元ＰＣに対してエラーの返信処理を行い、Ｓ１２０４で一連の処理を完了させる。

以上示したように、実施例３によれば、ＳＮＭＰのプロトコルバージョンと、ＳＮＭＰの仕様として複数存在する情報取得系のオペレーションに応じて、画像形成装置が応答する状態通知の値の新旧仕様を切り替えることが可能となる。よって、旧ＲＦＣ仕様しか解釈できない監視アプリケーション（ホスト）に対して、新ＲＦＣ仕様で画像形成装置が返信を行ってしまい誤判定されてしまう状況を回避可能となる。また逆に、新ＲＦＣに対応した監視アプリケーションに対して画像形成装置が旧ＲＦＣで定義された少ない範囲の状態通知しか行えないといった状況も回避可能となる。よって、監視アプリケーションは、常に適切な状態監視を継続的に行うことができる。
なお、上記実施例１〜３を組み合わせて、機能を構成してもよい。

実施例４では、状態取得に来たＩＰアドレス毎に状態取得の間隔を、画像形成装置１００が正常な場合と正常でない場合とに分けてサンプリングし、該サンプリングした結果から、ＩＰアドレス毎に、返信値を生成する新旧仕様を切り替えるように構成する。以下、サンプリング処理を図１３のフローチャートで示し、サンプリング結果を図１４で示し、画像形成装置の切り替え処理を図１５のフローチャートで示す。

以下、図１３を用いて、状態取得を要求した装置のＩＰアドレス毎に状態取得の間隔を、画像形成装置１００が正常な場合と正常でない場合とに分けてサンプリングするための処理について説明する。
図１３は、実施例４における画像形成装置１００のサンプリング処理を例示するフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０のＣＰＵがＲＯＭ又はＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現されるものである。

Ｓ１３００において、サンプリングを行うための処理が、画像形成装置１００の制御部１１０で開始される。Ｓ１３０１において、制御部１１０は、受信したＳＮＭＰパケットにhrPrinterDetectedErrorStateが含まれているか否かの判断を行う。そして、hrPrinterDetectedErrorStateが含まれていないと判断した場合（Ｓ１３０１でＮｏの場合）、制御部１１０は、Ｓ１３０２に処理を遷移させる。

Ｓ１３０２では、制御部１１０は、サンプリングの終了条件に達したか否かの判断を行う。サンプリングの終了条件に関しては、例えば、予め定められた回数や、予め定められた時間等を用いるが、これらに限定されるものではない。そして、サンプリングの終了条件に達していないと判断した場合（Ｓ１３０２でＮｏの場合）、制御部１１０は、処理をＳ１３０１に遷移させ、サンプリングの処理を継続する。

また、上記Ｓ１３０１において、受信したＳＮＭＰパケットにhrPrinterDetectedErrorStateが含まれていると判断した場合（Ｓ１３０１でＹｅｓの場合）、制御部１１０は、Ｓ１３０４に処理を遷移させる。Ｓ１３０４では、制御部１１０は、サンプリング・テーブル上に、上記Ｓ１３０１で受信した状態取得を行っているＰＣ１６１やＰＣ１６２などのＩＰアドレスのエントリが存在しているか否かを判断する。なお、サンプリング・テーブルは、後述する図１４に示すようなものであり、例えば、ＨＤＤ１５０に格納されているものとする。

そして、上記Ｓ１３０４において、サンプリング・テーブル上にエントリが存在していないと判断した場合（Ｓ１３０４でＮｏの場合）、制御部１１０は、Ｓ１３０８に処理を遷移させる。Ｓ１３０８では、制御部１１０は、サンプリング・テーブル上に新規のエントリを作成し、Ｓ１３０２に処理を遷移させる。

一方、上記Ｓ１３０４において、サンプリング・テーブル上にエントリが存在していると判断した場合（Ｓ１３０４でＹｅｓの場合）、制御部１１０は、Ｓ１３０５に処理を遷移させる。Ｓ１３０５では、制御部１１０は、上記Ｓ１３０１で受信した状態取得を行っているホストに前回返信を行った時に、正常時のステータスとして返信を行った否かを判断する。なお、正常時のステータスの一例としては、図２に示した「ｉｄｅｌ」状態が挙げられる。

そして、上記Ｓ１３０５において、前回に正常時ステータスで返信を行ったと判断した場合（Ｓ１３０５でＹｅｓの場合）、制御部１１０は、Ｓ１３０６に処理を遷移させる。Ｓ１３０６では、制御部１１０は、サンプリング・テーブルに対して正常時のホストからの状態取得のポーリング間隔に関するデータとして、前回の返信日時と今回の問合わせ日時を記録し、Ｓ１３０２に処理を遷移させる。

一方、上記Ｓ１３０５において、前回に正常時ステータスで返信を行っていないと判断した場合（Ｓ１３０５でＮｏの場合）、制御部１１０は、Ｓ１３０７に処理を遷移させる。Ｓ１３０７では、制御部１１０は、サンプリング・テーブルに対してエラー時のホストからの状態取得のポーリング間隔に関するデータとして、前回の返信日時と今回の問合わせ日時を記録し、Ｓ１３０２に処理を遷移させる。

そして、上記Ｓ１３０２において、サンプリングの終了条件に達したと判断した場合（Ｓ１３０２でＹｅｓの場合）、制御部１１０は、Ｓ１３０３に処理を遷移させ、サンプリング処理を終了させる。以上のように、上記状態取得を要求するパケットの送信元の情報処理装置ごとに、正常な状態を示す値を返却してから次の要求を受け取るまでの間隔と、異常な状態を示す値を返却してから次の要求を受け取るまでの間隔とをサンプリングする。なお、サンプリング方法は、同様のサンプリングが可能なものであれば、どのようなものであってもよい。

図１４は、サンプリング・テーブルの一例を示す図である。
図１４において、１４００はエントリを示す。本実施例では画像形成装置１００の状態取得を行うＰＣ１６１やＰＣ１６２のＩＰアドレスをエントリのキーとしているが、他にＭＡＣアドレスなど他の情報と併せてエントリのキーとしてもよい。
１４０１は、サンプリング回数を示している。図１４では、サンプリング回数が３回の例が示されているが、増減を調整できるようにしてもよい。

１４０２は、ＰＣ１６１などからの情報取得に対して、制御部１１０が、前回に正常時ステータス（例えば図２のｉｄｅｌ）で返信を行った場合の日時から今回の問合わせまでの間隔を特定するための情報を記録する。図１４の例では、前回正常時ステータスを返信した日時と今回の問合わせ日時とを記録する。

１４０３は、ＰＣ１６１などからの情報取得に対して、制御部１１０が、前回に正常以外のステータス（例えば図２のｎｏＰａｐｅｒ）で返信を行った場合の日時から今回の問合わせまでの間隔を特定するための情報を記録する。図１４の例では、前回正常以外のステータスを返信した日時と今回の問合わせ日時とを記録する。

１４０４と１４０５は、エントリのキーとしているＩＰアドレスの情報であり、情報取得を行ってくるホストの数に対応して増減する。１４０６は、サンプリングが未だ行われていないことを示している。

次に図１５を用いて、図１３に示したサンプリング処理の結果に基づく返信値の切り替え処理を説明する。
図１５は、実施例４における画像形成装置１００の状態値の返信値切り替え処理を例示するフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０のＣＰＵがＲＯＭ又はＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現されるものである。

Ｓ１５００において、状態取得の返信として用いる値を新旧仕様の何れで返信を行うかの処理が画像形成装置１００の制御部１１０で開始される。Ｓ１５０１において、制御部１１０は、ＰＣ１６１やＰＣ１６２からのHost Resources MIBのhrPrinterDetectedErrorStateの問合わせのパケットを受信すると、以下の判断を行う。制御部１１０は、前回の返信値が、正常時の値で返信を行った時と、正常時以外の値で返信を行った時とで、そのホストが次回に情報取得のパケットを送出してくるまでのポーリング間隔を比較し、両間隔が「ほぼ一致」しているか否かの判断を行う。なお、この判断にあたっては、制御部１１０は、両間隔が予め定めた誤差範囲で一致しているか否かをもって判断を行うものとする。両間隔が予め定めた誤差範囲で一致している場合（両間隔の差分が予め定めた誤差範囲内の場合）には「ほぼ一致」と判断する。一方、両間隔が予め定めた誤差範囲で一致していない場合（両間隔の差分が予め定めた誤差範囲を超える場合）には「ほぼ一致」でないと判断する。

そして、Ｓ１５０１において、正常時とエラー時とでポーリング間隔がほぼ一致していると判断した場合（Ｓ１５０１でＹｅｓの場合）、制御部１１０は、Ｓ１５２０に処理を遷移させる。Ｓ１５０２では、制御部１１０は、今回の状態取得を受信したホストがＲＦＣ２７９０の新仕様に対応していないと判断する。これは、前述で説明した、図５の状態と等価であるということを、画像形成装置１００の制御部１１０が判断したということになる。そしてＳ１５０３に処理を進める。

Ｓ１５０３では、制御部１１０は、新旧仕様の優先モードの設定（新旧仕様のどちらを優先するかの指定）があるか否かを判断する。なお、優先モードの設定は、例えば、新仕様を優先、旧仕様を優先、又は、設定しない、のいずれかを設定する画面を操作部１４０に表示し、操作部１４０を通じてユーザからの優先モードの設定指示を受け付けるものとする。この設定は、上記Ｓ１５０１及びＳ１５０２の処理において、ホスト側が新仕様に対応していない状態であることが類推されるため、図５に示したような状態に陥る可能性があることから、ユーザの指示によって最終的な切り替え判断を行うためである。なお、この設定は、上記Ｓ１５０３の実行時に１回だけ行い、以後、この設定を記憶して用いるものとしてもよいし、上記Ｓ１５０３の実行時に毎回行っても良いし、予め行っておきＨＤＤ１５０に記憶しておく構成でもよい。また、この設定は、ホスト毎に行うものであっても、全ホストに共通であってもよい。

そして、上記Ｓ１５０３において、新旧仕様の優先モードの設定がないと判断した場合（Ｓ１５０３でＮｏの場合）、制御部１１０は、Ｓ１５１０に処理を進める。Ｓ１５１０では、制御部１１０は、旧仕様で返信できるように、新仕様で返信を行うためのフラグ（新仕様フラグ）を落とす（ＯＦＦにする）フラグ操作を行ない、Ｓ１５０６に処理を遷移させる。なお、上記新仕様フラグは、制御部１１０内のＲＡＭに記憶されているものとする。

一方、上記Ｓ１５０３において、新旧仕様の優先モードの設定があると判断した場合（Ｓ１５０３でＹｅｓの場合）、制御部１１０は、Ｓ１５０４に処理を進める。Ｓ１５０４では、制御部１１０は、優先モードが新仕様優先であるか否かを判断する。そして、優先モードが旧仕様優先させる設定（新仕様を優先しない設定）であると判断した場合（Ｓ１５０４でＮｏの場合）、制御部１１０は、処理をＳ１５１０に遷移させる。Ｓ１５１０では、制御部１１０は、上述したように、新仕様フラグを落とし（ＯＦＦにし）、Ｓ１５０６に処理を遷移させる。

一方、上記Ｓ１５０４において、優先モードが新仕様優先させる設定であると判断した場合（Ｓ１５０４でＹｅｓの場合）、制御部１１０は、処理をＳ１５０５に遷移させる。Ｓ１５０５では、制御部１１０は、新仕様フラグを立て（ＯＮにし）、Ｓ１５０６に処理を遷移させる。

Ｓ１５０６では、制御部１１０は、前述の新仕様フラグの値に基づいて新旧仕様の返信値を決定し、処理をＳ１５０７に遷移させる。新仕様フラグがＯＮの場合、制御部１１０は、返信値の仕様を「新仕様」と決定する。一方、新仕様フラグがＯＦＦの場合、制御部１１０は、返信値の仕様を「旧仕様」と決定する。

Ｓ１５０７では、制御部１１０は、上記Ｓ１５０６で決定した仕様で画像形成装置１００の状態を返信するための返信値とパケットを生成し、Ｓ１５０８に処理を遷移させる。Ｓ１５０８では、制御部１１０は、上記Ｓ１５０１で受信したパケットの送り元ＰＣに対して、上記Ｓ１５０７で作成したパケットの返信処理を行い、Ｓ１５０９で一連の処理を完了させる。

また、上記Ｓ１５０１において、正常時とエラー時とでポーリング間隔がほぼ一致ではないと判断した場合（Ｓ１５０１でＮｏの場合）、制御部１１０は、Ｓ１５１１に処理を進める。Ｓ１５１１では、制御部１１０は、ホストがＲＦＣ２７９０の新仕様に対応していると判断する。これは、前述で説明した、図４の状態と等価であるということを、画像形成装置１００の制御部１１０が判断したということになる。そしてＳ１５１２に処理を進める。Ｓ１５１２では、制御部１１０は、新仕様フラグを立て（ＯＮにし）、Ｓ１５０６に処理を遷移させる。なお、Ｓ１５０６以降の処理に関しては上述のものと同一であるので説明を省略する。

以上示したように、実施例４によれば、状態取得に来たＩＰアドレス毎に状態取得の正常時とエラー時の間隔をそれぞれサンプリングし、該サンプリング結果に応じて、画像形成装置が応答する状態通知の値の新旧仕様を切り替えることが可能となる。これにより、旧ＲＦＣ仕様しか解釈できない監視アプリケーションに対して、新ＲＦＣ仕様で画像形成装置が返信を行ってしまい誤判定されてしまう状況を回避可能となる。また逆に、新ＲＦＣに対応した監視アプリケーションに対して画像形成装置が旧ＲＦＣで定義された少ない範囲の状態通知しか行えないといった状況も回避可能となる。よって、監視アプリケーションは、常に適切な状態監視を継続的に行うことができる。

従って、ホストからの要求に応じて画像形成装置が返却する状態を示す値を、ホストにおける状態を示す値の定義に係る仕様に応じて追随させることを可能とし、ホストにおいて画像形成装置の状態が誤判定されてしまう状況の発生を回避するホスト側での状態の誤判定を防止することができる。よって、ＳＮＭＰ／ＭＩＢを使用して、ホストから画像形成装置の状態を正しく把握できるようにすることが可能となる。上記各実施例の画像形成装置１００は、ホストからの所定の時間間隔（例えば１０分間隔）に基づく要求に応じて、上記ＵＩ設定画面等での指定に従い決定された仕様に準拠した画像形成装置１００の状態を示す値を該ホストに返却する。また、画像形成装置１００は、上記返却する値が異常を示すとホストにより判定された場合の、上記所定の時間間隔より短い時間間隔（例えば３０秒間）に基づく要求に応じて、上記ＵＩ設定画面等での指定に従い決定された仕様に準拠した画像形成装置１００の状態を示す値を該ホストに返却する。なお、ＲＦＣ等の標準規格が更新され新たな仕様が追加された場合、追加された仕様で応答できる画像形成装置とそうでないもの、一方、画像形成装置を管理するホスト側においても同じく、追加された仕様を理解できるものと出来ないものが混在する。このような混在環境においても適切に画像形成装置の状態管理を行えるようにすることができる

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (10)

1. 外部の情報処理装置からの所定の時間間隔に基づく要求に応じて、状態を示す値を返却する画像形成装置であって、
   前記状態を示す値の定義に係る仕様を、複数の仕様のいずれにするかを決定するための指定を行う指定手段と、
   前記所定の時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第１の返却手段と、
   前記返却する値が異常を示すと前記情報処理装置により判定された場合の、前記所定の時間間隔より短い時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第２の返却手段と、
   を有することを特徴とする画像形成装置。
2. 前記指定手段は、前記要求を行う情報処理装置のアドレスもしくはアドレスの範囲ごとに、前記指定が可能であり、
   前記第１の返却手段及び前記第２の返却手段は、前記要求を受けた情報処理装置のアドレスに応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
3. 前記指定手段は、前記要求を受ける時間帯ごと、曜日ごと、もしくは時間帯と曜日の組み合わせごとに、前記指定が可能であり、
   前記第１の返却手段及び前記第２の返却手段は、前記要求を受けた時間帯に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
4. 前記指定手段は、仕様を切り替える期日の指定が可能であり、
   前記第１の返却手段及び前記第２の返却手段は、前記要求を受けた日時に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
5. 前記要求は、ＳＮＭＰを用いるものであり、
   前記指定手段は、前記ＳＮＭＰのバージョンごとに、前記指定が可能であり、
   前記第１の返却手段及び前記第２の返却手段は、前記要求に対応するＳＮＭＰのバージョンに応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
6. 前記要求は、ＳＮＭＰを用いるものであり、
   前記指定手段は、前記ＳＮＭＰのオペレーションごとに、前記指定が可能であり、
   前記第１の返却手段及び前記第２の返却手段は、前記要求に対応するＳＮＭＰのオペレーションに応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
7. 前記要求を行う情報処理装置ごとに、正常な状態を示す値を返却してから次の要求を受け取るまでの間隔を示す第１の間隔と、異常な状態を示す値を返却してから次の要求を受け取るまでの間隔を示す第２の間隔とをサンプリングするもサンプリング手段を有し、
   前記第１の返却手段及び前記第２の返却手段は、前記第１の間隔と前記第２の間隔との比較の結果に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却することを特徴とする請求項１に記載の画像形成装置。
8. 前記複数の仕様には、第１の仕様と、第２の仕様が含まれ、
   前記第１の仕様は、前記状態を示す値を８ビットで表し、前記第２の仕様は、前記状態を示す値を１６ビットで表すことを特徴とする請求項１乃至７のいずれか１項に記載の画像形成装置。
9. 外部の情報処理装置からの所定の時間間隔に基づく要求に応じて、状態を示す値を返却する画像形成装置の制御方法であって、
   前記状態を示す値の定義に係る仕様を、複数の仕様のいずれにするかを決定するための指定を行う指定ステップと、
   前記所定の時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第１の返却ステップと、
   前記返却する値が異常を示すと前記情報処理装置により判定された場合の、前記所定の時間間隔より短い時間間隔に基づく要求に応じて、前記指定に従い決定された仕様に準拠した前記状態を示す値を返却する第２の返却ステップと、
   を有することを特徴とする画像形成装置の制御方法。
10. コンピュータを、請求項１乃至８のいずれか１項に記載の手段として機能させるためのプログラム。

Images