(57)【要約】【課題】再通知のための情報の過剰な蓄積を抑制する。【解決手段】ユーザは、通知方法６０８により、ＳＮＭＰｖ３での通知方法として、ｉｎｆｏｒｍ（第１の通知方法）またはｔｒａｐ（第２の通知方法）の何れかを設定する。制御部１１０は、画像形成装置１００の状態変化を検知し、検知された変化先の状態が正常系またはワーニング系の場合、変化した状態に対して通知方法の変更が可能と設定されていれば、設定された通知方法がｉｎｆｏｒｍであっても、使用する通知方法をｔｒａｐと決定する。【選択図】図８
2017220045.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されるネットワークデバイスであって、
前記ネットワークデバイスにおける状態変化を検知する検知手段と、
通知先を設定すると共に、前記通知先に対する通知方法として、前記検知手段により検知された前記状態変化を通知すると共に通知の到達確認を行う第１の通知方法と、検知された前記状態変化を通知すると共に通知の到達確認を行わない第２の通知方法のいずれかを設定する設定手段と、
検知された前記状態変化を、前記設定手段により設定された前記通知先へ通知する通知手段と、
前記第１の通知方法で通知が実施され且つ、通知の到達を確認できなかった場合に、再通知を実施するための情報を格納する格納手段と、
検知された前記状態変化の態様が所定の態様に該当するか否かを判定する判定手段と、
前記設定手段により設定された通知方法と前記判定手段による判定の結果とに基づいて、使用する通知方法を決定する決定手段と、
前記決定手段により決定された通知方法で前記状態変化を前記通知先へ通知するよう前記通知手段を制御する制御手段と、を有することを特徴とするネットワークデバイス。
【請求項２】
前記決定手段は、前記判定手段により前記状態変化の態様が前記所定の態様に該当すると判定された場合は、前記設定手段により設定された通知方法が前記第１の通知方法であっても前記第２の通知方法を前記使用する通知方法として決定することを特徴とする請求項１に記載のネットワークデバイス。
【請求項３】
前記設定手段は、通知方法の変更の可否を設定することが可能であり、
前記決定手段は、前記判定手段により前記状態変化の態様が前記所定の態様に該当すると判定され且つ、前記設定された通知方法が前記第１の通知方法である場合は、前記通知方法の変更が可能と設定されていることを条件に、前記第２の通知方法を前記使用する通知方法として決定することを特徴とする請求項２に記載のネットワークデバイス。
【請求項４】
前記設定手段は、状態変化の態様ごとに通知方法の変更の可否を設定することが可能であり、
前記決定手段は、状態変化の態様ごとに、前記判定手段により前記状態変化の態様が前記所定の態様に該当すると判定され且つ、当該状態変化の態様に対して設定された通知方法が前記第１の通知方法である場合は、当該状態変化の態様に対して前記通知方法の変更が可能と設定されていることを条件に、前記第２の通知方法を前記使用する通知方法として決定することを特徴とする請求項２または３に記載のネットワークデバイス。
【請求項５】
前記設定手段は、複数の通知先の各々に通知方法を設定することが可能であり、
前記決定手段は、通知先ごとに前記使用する通知方法を決定することを特徴とする請求項１〜４のいずれか１項に記載のネットワークデバイス。
【請求項６】
前記設定手段は、通知方法の変更の可否を設定することが可能であり、
前記決定手段は、通知先ごとに、前記判定手段により前記状態変化の態様が前記所定の態様に該当すると判定され且つ、前記設定された通知方法が前記第１の通知方法である場合は、前記通知方法の変更が可能と設定されていることを条件に、前記第２の通知方法を前記使用する通知方法として決定することを特徴とする請求項５に記載のネットワークデバイス。
【請求項７】
前記決定手段は、前記判定手段により前記状態変化の態様が前記所定の態様に該当しないと判定された場合は、前記設定手段により設定された通知方法を、前記使用する通知方法として決定することを特徴とする請求項１〜６のいずれか１項に記載のネットワークデバイス。
【請求項８】
前記設定された通知方法が前記第１の通知方法であって且つ前記状態変化を前記第２の通知方法で前記通知先に通知するよう前記制御手段が前記通知手段を制御した場合であっても、前記通知先に対する通知方法の設定は維持されることを特徴とする請求項１〜７のいずれか１項に記載のネットワークデバイス。
【請求項９】
前記制御手段は、前記設定された通知方法が前記第１の通知方法であって且つ前記状態変化を前記第２の通知方法で通知するよう前記通知手段を制御した場合は、その旨を示す情報を履歴に保存することを特徴とする請求項１〜８のいずれか１項に記載のネットワークデバイス。
【請求項１０】
前記制御手段は、前記格納手段に格納された情報に基づいて、通知の到達を確認できなかった通知先へ前記状態変化を再通知するよう前記通知手段を制御することを特徴とする請求項１〜９のいずれか１項に記載のネットワークデバイス。
【請求項１１】
前記制御手段は、再通知を実施するための前記情報が前記格納手段に格納されている状態で、前記格納されている情報に対応する通知先が削除されるかまたは、前記対応する通知先に対する通知方法の設定が前記設定手段により前記第２の通知方法へ変更された場合は、前記格納手段から前記通知先に対応する情報を消去することを特徴とする請求項１０に記載のネットワークデバイス。
【請求項１２】
前記判定手段は、検知された前記状態変化による変化先の状態が、前記ネットワークデバイスが通常動作可能な状態である場合に、前記状態変化の態様が前記所定の態様に該当すると判定することを特徴とする請求項１〜１１のいずれか１項に記載のネットワークデバイス。
【請求項１３】
前記第１の通知方法は、ＳＮＭＰ（Simple Network Management Protocol）におけるＩｎｆｏｒｍＲｅｑｕｅｓｔを利用した方法であることを特徴とする請求項１〜１２のいずれか１項に記載のネットワークデバイス。
【請求項１４】
前記第２の通知方法は、ＳＮＭＰにおけるｔｒａｐを利用した方法であることを特徴とする請求項１〜１３のいずれか１項に記載のネットワークデバイス。
【請求項１５】
請求項１〜１４のいずれか１項に記載のネットワークデバイスと、
前記ネットワークデバイスにネットワークを通じて接続され、前記ネットワークを通じて前記ネットワークデバイスから前記状態変化の通知を受ける監視装置とから構成されることを特徴とする監視システム。
【請求項１６】
ネットワークに接続されるネットワークデバイスの制御方法であって、
前記ネットワークデバイスにおける状態変化を検知する検知ステップと、
通知先を設定すると共に、前記通知先に対する通知方法として、前記検知ステップにより検知された前記状態変化を通知すると共に通知の到達確認を行う第１の通知方法と、検知された前記状態変化を通知すると共に通知の到達確認を行わない第２の通知方法のいずれかを設定する設定ステップと、
検知された前記状態変化を、前記設定ステップにより設定された前記通知先へ通知する通知ステップと、
前記第１の通知方法で通知が実施され且つ、通知の到達を確認できなかった場合に、再通知を実施するための情報を格納部に格納する格納ステップと、
検知された前記状態変化の態様が所定の態様に該当するか否かを判定する判定ステップと、
前記設定ステップにより設定された通知方法と前記判定ステップによる判定の結果とに基づいて、使用する通知方法を決定する決定ステップと、
前記決定ステップにより決定された通知方法で前記状態変化を前記通知先へ通知するよう前記通知ステップにおける通知を制御する制御ステップと、を有することを特徴とするネットワークデバイスの制御方法。
【請求項１７】
請求項１６に記載のネットワークデバイスの制御方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたネットワークデバイスの状態変化を通知する技術に関する。
【背景技術】
【０００２】
従来、画像形成装置等のネットワークデバイスと監視装置とがネットワークを通じて接続されて構成される監視システムが知られている。このシステムでは、例えば、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）とＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）情報を用いてネットワークデバイスの監視が行われる。
【０００３】
特許文献１の技術では、ＳＮＭＰを用いる場合、ネットワークデバイスは、ＳＮＭＰエージェントを備え、ＩｎｆｏｒｍＲｅｑｕｅｓｔメッセージを生成し、ＳＮＭＰプロトコルによって自身の状態情報を監視装置へ通知する。監視装置は、状態情報を受信して自装置の画面に表示するＳＮＭＰマネージャを備える。監視装置のステータスモニタは、通知の受信に応答してＩｎｆｏｒｍＲｅｑｕｅｓｔのメッセージの内容を画面上に表示することで、ネットワークデバイスの状態の監視をリアルタイムに行っている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１１８８５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ネットワークデバイスの側から監視装置へＳＮＭＰ／ＭＩＢを用いて能動的に状態通知を行う方法として、次の方法がＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）で規格化されている。すなわち、ＳＮＭＰｖ１−Ｔｒａｐ（ＲＦＣ１１５７）、ＳＮＭＰｖ２−Ｔｒａｐ（ＲＦＣ３４１１）、ＩｎｆｏｒｍＲｅｑｕｅｓｔ（ＲＦＣ３４１１）等が規格化されている。
【０００６】
また、ＳＮＭＰはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）であってコネクションレス型プロトコルであるため、上位のアプリケーションによってパケット消失時の再送や到達順の変化等を保証する必要がある。後に図２でも説明するが、ＩｎｆｏｒｍＲｅｑｕｅｓｔを用いた通知では到達確認を行うため、監視装置側からＲｅｓｐｏｎｓｅが無い場合、予め定められた間隔／回数でＩｎｆｏｒｍＲｅｑｕｅｓｔの再送が行われる。到達確認ができなかった場合、再通知を実施するための情報が再送テーブルに蓄積され、再通知の結果、到達確認が行えると、該当する情報が再送テーブルから削除される。なお、ＩｎｆｏｒｍＲｅｑｕｅｓｔでデバイスの状態を通知する場合、事前にユニキャストの通知先アドレス、ＳＮＭＰｖ３ユーザ情報、通知を行うイベントタイプを複数登録しておくことが必要である。このイベントタイプには例えば、Ｊｏｂ実行後の計数カウント値、紙なし、トナーなし、ドアオープンの状態等がある。
【０００７】
ところが、通知先が複数存在し、ＩｎｆｏｒｍＲｅｑｕｅｓｔの到達確認待ち中に新たな状態変化が生じ、しかもそれが短時間で発生すると、再送テーブルがあふれるおそれがある。すなわち、記録されるデータ量が再送テーブルを格納するメモリの容量をオーバーしてしまうおそれがある。再送テーブルを保持できる情報量は通常、有限だからである。再送テーブルがあふれた結果、ネットワーク上の監視装置側でネットワークデバイスの状態変化を把握することが困難になる。すると、機器のメンテナンスやジョブの実行に支障をきたすことに繋がる。
【０００８】
本発明の目的は、再通知のための情報の過剰な蓄積を抑制することである。
【課題を解決するための手段】
【０００９】
上記目的を達成するために本発明は、ネットワークに接続されるネットワークデバイスであって、前記ネットワークデバイスにおける状態変化を検知する検知手段と、通知先を設定すると共に、前記通知先に対する通知方法として、前記検知手段により検知された前記状態変化を通知すると共に通知の到達確認を行う第１の通知方法と、検知された前記状態変化を通知すると共に通知の到達確認を行わない第２の通知方法のいずれかを設定する設定手段と、検知された前記状態変化を、前記設定手段により設定された前記通知先へ通知する通知手段と、前記第１の通知方法で通知が実施され且つ、通知の到達を確認できなかった場合に、再通知を実施するための情報を格納する格納手段と、検知された前記状態変化の態様が所定の態様に該当するか否かを判定する判定手段と、前記設定手段により設定された通知方法と前記判定手段による判定の結果とに基づいて、使用する通知方法を決定する決定手段と、前記決定手段により決定された通知方法で前記状態変化を前記通知先へ通知するよう前記通知手段を制御する制御手段と、を有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、再通知のための情報の過剰な蓄積を抑制することができる。
【図面の簡単な説明】
【００１１】
【図１】ネットワークデバイスを含む監視システムの全体構成を示す図である。
【図２】ｔｒａｐ、ｉｎｆｏｒｍによる通信の概念図である。
【図３】ブロードキャスト（図（ａ））、ユニキャスト（図（ｂ））、マルチキャスト（図（ｃ））における通知の概念図である。
【図４】管理テーブルの一例を示す概念図である。
【図５】ＳＮＭＰｖ３のユーザ設定画面の一例を示す図である。
【図６】通知先設定画面の一例を示す図である。
【図７】通知方法変更可否設定画面の一例を示す図である。
【図８】状態通知処理のフローチャートである。
【図９】再送処理のフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施の形態を説明する。
【００１３】
図１は、本発明の一実施の形態に係るネットワークデバイスを含む監視システムの全体構成を示す図である。この監視システムは、ネットワークデバイスとしての画像形成装置１００と監視装置としての監視端末１６１、１６２とがネットワーク１６０を介して接続されて構成される。なお、監視端末の数は少なくとも１つであり、３以上であってもよい。また、ネットワークデバイスは、画像形成装置１００に限定されない。
【００１４】
本実施の形態では、画像形成装置１００の一例として、コピー機能やプリンタ機能等の複数の機能を有するＭＦＰ（Multi Function Peripheral)を挙げる。なお、画像形成装置１００は、コピー機能のみ又はプリンタ機能のみを有するＳＦＰ(Single Function Peripheral)であってもよい。まず、図１を参照して、画像形成装置１００の構成例について説明する。
【００１５】
制御部（コントローラ部）１１０は、リーダ部１２０及びプリンタ部１３０と電気的に接続されている。制御部１１０は、リーダ部１２０及びプリンタ部１３０からデータを受信する。制御部１１０は、リーダ部１２０及びプリンタ部１３０に対して各種のコマンドを送信する。さらに制御部１１０は、ネットワーク１６０を介して接続された監視端末１６１、１６２から画像データや制御コマンドを受信する。ネットワーク１６０は、例えば、イーサネット（登録商標）で構築される。監視端末１６１、１６２は画像形成装置１００に対して、機器の構成情報や現在のステータス情報の監視等も行っている外部の監視装置である。
【００１６】
リーダ部１２０は、原稿の画像を光学的に読み取り、画像データに変換する。リーダ部１２０は、原稿を読み取る機能を有するスキャナユニット１２１と、原稿をスキャナユニット１２１によって読み取り可能な位置まで搬送する原稿給紙ユニット１２２とを備える。スキャナユニット１２１が備えるスキャナコントローラ１２３は、制御部１１０からの指示に基づいて、スキャナユニット１２１と原稿給紙ユニット１２２とを制御する。
【００１７】
プリンタ部１３０は画像形成機能を有する。すなわち、プリンタ部１３０は、画像形成（印刷）用の用紙（用紙又は記録材）を収納する給紙ユニット１３１と、画像データを用紙に転写及び定着させるマーキングユニット１３２と、印刷された用紙を排紙する排紙ユニット１３４とを備える。マーキングユニット１３２が備えるプリンタコントローラ１３５は、制御部１１０からの指示に基づいて、マーキングユニット１３２と給紙ユニット１３１と排紙ユニット１３４とを制御する。プリンタ部１３０は、制御部１１０からの指示に基づいて、給紙ユニット１３１から用紙をマーキングユニット１３２へ給紙し、マーキングユニット１３２で当該用紙に対して画像データを印刷した後、当該用紙を排紙ユニット１３４へ排紙する。排紙ユニット１３４は、マーキングユニット１３２で印刷された用紙に対し、ソートやステイプル等の処理を施すことができる。給紙ユニット１３１は、複数の給紙部を備えており、各給紙部には用紙が収納される。各給紙部は、例えば、普通紙や光沢紙等、複数種類の用紙を収納できる。
【００１８】
操作部１４０は、例えば、ハードキーや、液晶表示部及びその表面上に貼り付けられたタッチパネル部を備え、それらを介してユーザから指示を受け付ける。また、操作部１４０は、液晶等の表示部に、ソフトキーのほか、画像形成装置１００の機能や状態を表示することができる。操作部１４０は、ユーザからの指示に対応するコマンドを、制御部１１０に送信する。ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１５０は、画像形成装置１００の各種設定及び画像データを記憶する。
【００１９】
上記の構成に基づき、画像形成装置１００は、例えば、コピー機能、画像データ送信機能、プリンタ機能等の種々の機能を実現する。コピー機能を実現する場合には、制御部１１０は、リーダ部１２０で原稿の画像データを読み込み、プリンタ部１３０で当該画像データを用いて用紙に印刷する制御を行う。画像データ送信機能を実現する場合に、制御部１１０は、リーダ部１２０で読み込んだ原稿の画像データをコードデータに変換し、当該コードデータを、ネットワーク１６０を介して監視端末１６１、１６２に送信する。さらに、プリンタ機能を実現する場合には、制御部１１０は、監視端末１６１、１６２からネットワーク１６０を介して受信したコードデータ（印刷データ）を画像データに変換し、プリンタ部１３０へ送信する。プリンタ部１３０は、受信した画像データを用いて用紙に印刷する。
【００２０】
次に、標準技術について説明する。ＲＦＣ(Request for Comments)は、インターネットで利用される技術の標準化を目的としてＩＥＴＦ(Internet Engineering Task Force)が発行している。このＲＦＣに基づく、ネットワーク機器からの情報取得の技術について説明する。
【００２１】
ネットワーク上のデバイスの情報監視プロトコルとしてＳＮＭＰ(Simple Network Management Protocol)が一般的に広く用いられている。ＳＮＭＰで管理されるネットワーク機器は、ＭＩＢ(Management Information Base)情報を搭載し、監視端末からのＳＮＭＰリクエストに対してレスポンスを行うことで管理される。監視端末からのＳＮＭＰのリクエストは情報取得系と情報設定系とに大別される。ＭＩＢ情報の構造については、ＩＥＦＴで標準化された仕様や、ＰＷＧ（printer Working Group）で業界標準化された仕様、さらには、ベンダなどが独自に拡張したプライベートＭＩＢ仕様などが存在する。
【００２２】
ＭＩＢ情報は分野別の階層構造となっており、枝にはそれぞれ番号が割り当てられており、この番号をつなげたものはＯＩＤ（Object Identifier）と呼ばれる。ＭＩＢでは、この階層構造と、ＯＩＤを持つオブジェクトがどの様な情報を持ち、どのようなデータ型で定義されているのか等が規定される。ＭＩＢには、各種のＲＦＣによって規定されるものや、企業により独自に拡張されたプライベート情報等がある。データ型の定義についても管理情報構造（ＳＭＩ(Structure of Management Information)）としてＲＦＣに規定がある。データ型の定義は、ＡＳＮ.１(Abstract Syntax Notation One)というＩＳＯとＩＴＵ−Ｔで規定された記述言語で表現される。なお、ＲＦＣの技術仕様は不変ではなく、技術の進歩によって更新が行われる。ＲＦＣには「ＲＦＣｘｘｘｘ」という番号があり、一度公開された仕様の更新にあたっては、旧来の番号をＯｂｓｏｌｅｔｅ扱いとし、新規の番号が割り当てられる。
【００２３】
ネットワーク機器の電力状態の監視をネットワーク上の遠隔の監視端末からＳＮＭＰとＭＩＢとを用いて行うために、ＰＷＧから業界標準規格が提案されている。すなわち、業界標準規格としてＰＷＧ  Ｉｍａｇｉｎｇ  Ｓｙｓｔｅｍ  Ｐｏｗｅｒ  ＭＩＢ  ｖ１．０（以下、ＰｏｗｅｒＭＩＢ）が提案されている。このＰｏｗｅｒＭＩＢ仕様には、監視端末側から管理対象のネットワーク機器に対し、定期的なポーリングによる電力状態の管理を行うための仕様が含まれている。これに加えて、管理対象のネットワーク機器が自身の電力状態の遷移に応じて監視端末側に状態変化の通知を行うための仕様も含まれている。ネットワーク機器側から監視端末側へＳＮＭＰを用いて通知を行う方法としては主に２つの方法（ｔｒａｐとｉｎｆｏｒｍａｔｉｏｎ）がある。次に、これら２つの通知方法の違いを、図２を用いて簡単に説明する。
【００２４】
図２（ａ）、（ｂ）はそれぞれ、ｔｒａｐ、ｉｎｆｏｒｍによる通信の概念図である。まず、ｔｒａｐとｉｎｆｏｒｍとの共通事項を説明する。ＳＮＭＰによる管理機能は、ＳＮＭＰエンティティと呼ばれる構成要素によって実現される。ここで、便宜上、ＳＮＭＰによって情報を管理される側をエージェント、情報を管理する側をマネージャと呼ぶ。画像形成装置１００は情報を管理される側のエージェントであり、管理される対象の情報の例としてＭＩＢ情報２００を有している。画像形成装置１００には、情報の通知先として、マネージャ側の装置である例えば監視端末１６１が予め登録されており、ＭＩＢ情報２００に変化があった場合に通知を行うという設定がなされている。ＭＩＢ情報２００では多様な情報が管理されており、そのうちのどの情報の変化によって通知を実施するのかについても予め設定されている。ＰｏｗｅｒＭＩＢの例では、電力遷移が発生してＭＩＢ情報２００が変化した場合に、エージェント側からマネージャ側に対して通知を行う仕様が定められている。
【００２５】
図２（ａ）に示すように、ｔｒａｐで通知を行う場合、画像形成装置１００はＭＩＢ情報２００に変化があった時点で通知種別をｔｒａｐ２０１とし、通知するＭＩＢ情報とともにＳＮＭＰモジュール２０２を呼び出す。ＳＮＭＰモジュール２０２は通信モジュールＵＤＰ／ＩＰ２０３を呼び出し、マネージャ側の監視端末１６１の通信モジュールＵＤＰ／ＩＰ２０４に対し、ＭＩＢ情報を含む通知を送る。監視端末１６１側では、通信モジュールＵＤＰ／ＩＰ２０４は、受信したＭＩＢ情報と共にエージェント側である画像形成装置１００から、通知種別がｔｒａｐである通知を受信した旨をＳＮＭＰモジュール２０５に対して通知する。ＳＮＭＰモジュール２０５は監視端末１６１で動作している機器監視アプリケーションに対して、通知を受けたＭＩＢ情報と共に画像形成装置１００から情報が到達した旨をｔｒａｐ２０６にて通知する。
【００２６】
図２（ｂ）に示すように、ｉｎｆｏｒｍで通知を行う場合、画像形成装置１００はＭＩＢ情報２００に変化があった時点で通知種別をＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７とし、通知するＭＩＢ情報とともにＳＮＭＰモジュール２０２を呼び出す。ＳＮＭＰモジュール２０２は通信モジュールＵＤＰ／ＩＰ２０３を呼び出し、監視端末１６１の通信モジュールＵＤＰ／ＩＰ２０４に対し、ＭＩＢ情報を含む通知を送る。監視端末１６１側では、通信モジュールＵＤＰ／ＩＰ２０４は、受信したＭＩＢ情報と共に画像形成装置１００から、通知種別がＩｎｆｏｒｍＲｅｑｕｅｓｔの通知を受信した旨をＳＮＭＰモジュール２０５に対して通知する。ＳＮＭＰモジュール２０５は監視端末１６１で動作している機器監視アプリケーションに対して、通知を受けたＭＩＢ情報と共に画像形成装置１００から情報が到達した旨をＩｎｆｏｒｍＲｅｑｕｅｓｔ２０８にて通知する。ＳＮＭＰモジュール２０２及び通信モジュールＵＤＰ／ＩＰ２０３は、本発明における通知手段に該当する。
【００２７】
監視端末１６１で動作している機器監視アプリケーションは、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０８にて画像形成装置１００からの情報通知を受ける。すると機器監視アプリケーションは、確かに受信を行った確認応答として、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０８に対するＲｅｓｐｏｎｓｅ２０９をＳＮＭＰモジュール２０５にセットする。ＳＮＭＰモジュール２０５は画像形成装置１００に確認応答を行うために通信モジュールＵＤＰ／ＩＰ２０４をさらに呼び出して、画像形成装置１００側の通信モジュールＵＤＰ／ＩＰ２０３に対して確認応答を送信する。ＳＮＭＰモジュール２０２は、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７に対応する確認応答としてＲｅｓｐｏｎｓｅ２１０を制御部１１０に通知する。ここで制御部１１０は、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の通知開始からＲｅｓｐｏｎｓｅ２１０を受け取るまでの間に一定時間が経過した場合には、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７が監視端末１６１に到達しなかった（不達）と判断する。不達と判断された場合、画像形成装置１００は予め決められた間隔と回数によってＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の再送を実施する。
【００２８】
図３（ａ）、（ｂ）、（ｃ）はそれぞれ、ブロードキャスト、ユニキャスト、マルチキャストにおける通知の概念図である。ブロードキャストは、ネットワーク上の全宛先を指定して1対不特定多数で行われるデータ通信のことである。ユニキャストは、単一の送信相手を指定して1対1で行われるデータ通信のことである。マルチキャストは、特定のアドレスを指定して1対複数で行われるデータ通信のことである。
【００２９】
ｔｒａｐとｉｎｆｏｒｍの仕様を簡単に比較すると以下の仕様差がある。まず、ｔｒａｐは状態変化を一方的に通知するだけである。ｔｒａｐは一行的に通知するだけなので、通知先に設定できるアドレスは、ユニキャスト、マルチキャスト、ブロードキャストの何れであってもよい。一方、ｉｎｆｏｒｍでは到達確認を行うため、ＳＮＭＰエージェントはＳＮＭＰマネージャからのＲｅｓｐｏｎｓｅが無い場合に、予め定められた間隔／回数でＩｎｆｏｒｍＲｅｑｕｅｓｔの再送を行う。ｉｎｆｏｒｍでは、到達確認を行う機構上、通知先が不特定多数となるマルチキャストやブロードキャストのアドレスを通知先に設定することはなく、必ずユニキャストで通知先を指定する。
【００３０】
図４は、管理テーブルの一例を示す概念図である。管理テーブルＴＢＬは、ｉｎｆｏｒｍで通知が実施されたが通知の到達を確認できなかった場合に、再通知を実施するための情報としてエントリーを格納したテーブルである。再通知（ＩｎｆｏｒｍＲｅｑｕｅｓｔの再送）を実施した結果、到達確認を行えた場合は、該当するエントリーは消去される。管理テーブルＴＢＬは、不揮発性の格納手段（格納部）、例えばＨＤＤ１５０に、記憶容量の上限を規定されて格納される。
【００３１】
次に、設定画面による各種設定について説明する。図５は、ＳＮＭＰｖ３のユーザ設定画面の一例を示す図である。このユーザ設定画面５００は画像形成装置１００における操作部１４０に表示される。
【００３２】
ＳＮＭＰｖ３は、ＩＥＴＦにおけるＳＴＤ６２によって規格化されており、ユーザベースの認証機構と暗号化を使用して通信が行われる。ＳＮＭＰｖ３ユーザは複数存在することが可能であるため、ユーザ設定画面５００には、現在設定を行っているユーザの前後のユーザに関する設定画面に切り替えるためにボタン５０１、５０２が表示される。ユーザＩＤ５０４は、制御部１１０においてＳＮＭＰｖ３のユーザを一意に特定するためのＩＤであり、制御部１１０が管理するＩＤであるため表示のみがなされ、ユーザは操作することができない。設定項目５０５は、ユーザＩＤ５０４に対応するＳＮＭＰｖ３設定を有効化／無効化するための項目であり、ユーザがプルダウン設定５１１において有効／無効を選択することにより変更が可能となっている。設定項目５０６は、ユーザＩＤ５０４に対するユーザ名を設定するための設定項目であり、ユーザが設定項目５０６を押下することにより、不図示のソフトウェアキーボード等の表示へと画面が遷移し、ユーザ名の入力や変更が可能となっている。設定項目５０７は、設定項目５０６で設定されたユーザ名に対して、ＳＮＭＰｖ３通信で認証を行うための認証アルゴリズムを設定するための設定項目であり、ユーザがプルダウン設定５１２において「なし／ＭＤ５／ＳＨＡ１」の中から選択可能である。認証パスワード５０８は、設定項目５０７で選択された認証アルゴリズムによる認証パスワードの入力を行うための設定項目である。ユーザが認証パスワード５０８を押下することにより、不図示のソフトウェアキーボード等の表示へと画面が遷移し、認証パスワードの入力や変更が可能となっている。
【００３３】
設定項目５０９は、ユーザＩＤ５０４がＳＮＭＰｖ３で通信を行う際の暗号化アルゴリズムを設定するための設定項目であり、ユーザがプルダウン設定５１３において「なし／ＤＥＳ／ＡＥＳ」の中から選択可能である。設定項目５１０は、設定項目５０９で選択された暗号化アルゴリズムによる暗号化パスワードの入力を行うための設定項目である。ユーザが５１０を押下することにより、不図示のソフトウェアキーボード等の表示へと画面が遷移し、暗号化パスワードの入力や変更が可能となっている。設定項目５０６、認証パスワード５０８及び設定項目５１０の設定においては、最少文字列長や最大文字列長を設けてもよい。ＳＮＭＰｖ３のユーザ設定が完了し、ＯＫボタン５０３が押下されると、操作部１４０から制御部１１０に対してＳＮＭＰｖ３のユーザ設定値が送信され、制御部１１０は受信した設定値に基づいてＳＮＭＰｖ３の通信を行う。
【００３４】
次に、図６を用いて、ＳＮＭＰｖ１とＳＮＭＰｖ３の各々での通信先の設定について説明する。図６は、通知先設定画面の一例を示す図である。この通知先設定画面６００は画像形成装置１００における操作部１４０に表示される。操作部１４０は、本発明における設定手段に該当する。
【００３５】
通知先設定６０１は、ＳＮＭＰｖ１での通知先を設定することを示す題目である。アドレス設定項目６０４は、通知先のアドレスを示し、画面例では通知先としてＩＰｖ４アドレス、ＩＰｖ６アドレス、ＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）での設定が可能となっている。コミュニティ名６０５はコミュニティ名の設定を示している。ＳＮＭＰｖ１の通信では、コミュニティ名を用いて管理対象をグルーピングし、同じコミュニティに属するノード間で通信を行う。コミュニティ名ごとに管理スコープを変更したり、ｒｅａｄ−ｏｎｌｙ／ｒｅａｄ−ｗｒｉｔｅのアクセスモードの切り替えを行ったりすることも可能である。有効／無効６０６は、通知先の有効／無効を切り替えるための設定項目である。
【００３６】
通知先設定６０２は、ＳＮＭＰｖ３トラップの送信先設定、すなわちＳＮＭＰｖ３での通知先を設定することを示す題目である。アドレス設定項目６０７はアドレス設定項目６０４と同様に通知先のアドレスを示し、画面例では通知先としてＩＰｖ４アドレス、ＩＰｖ６アドレス、ＦＱＤＮでの設定が可能となっている。通知方法６０８は、ＳＮＭＰｖ３での通知タイプ（通知方法）を設定・選択するための項目であり、ＳＮＭＰｖ３では、通知方法としてｉｎｆｏｒｍ（第１の通知方法）とｔｒａｐ（第２の通知方法）の何れかが選択可能である。ユーザＩＤ６０９は、通知を行う際に使用するＳＮＭＰｖ３のユーザＩＤを設定する項目で、ユーザＩＤの詳細な設定は、ユーザＩＤ５０４（図５）と紐付けされている。有効／無効６１０は、通知先の有効／無効を切り替えるための設定項目である。ＳＮＭＰｖ１とＳＮＭＰｖ３の通知先の設定が完了し、ユーザがＯＫボタン６０３を押下することにより、操作部１４０から制御部１１０に対してＳＮＭＰの各設定値が送信され、制御部１１０は受信した設定値に基づいてＳＮＭＰの通知を行う。
【００３７】
次に、図７を用いて、通知方法の変更可否の設定と履歴確認のための設定について説明する。図７は、通知方法変更可否設定画面の一例を示す図である。この通知方法変更可否設定画面７００は画像形成装置１００における操作部１４０に表示される。
【００３８】
通知方法切り替え設定７０１は、状態変化の通知方法の切り替えを設定することを示す題目である。通知方法切り替え設定７０１では、所定の条件が成立した場合に、通知先設定画面６００（図６）の通知方法６０８で設定された通知方法とは異なる通知方法を、使用する通知方法として採用することを禁止または許可できる。変更しない設定７０２は、状態変化の通知に使用する通知方法を、通知方法６０８で設定されたままとし、変更することを許可しないための設定項目である。変更可能設定７０３は、状態変化の通知に使用する通知方法を、通知方法６０８で設定された方法から変更することを許可するための設定項目である。
【００３９】
変更しない設定７０２と変更可能設定７０３とは排他的に選択され、変更可能設定７０３が選択された場合にだけ、状態７０４と切り替え有効／無効７０５の設定が可能となる。通知方法の変更の可否は、切り替え有効／無効７０５の設定によって、画像形成装置１００の変化後の状態ごとに設定可能である。変化後の状態としては例えば、状態７０４で、正常系、ワーニング、オペレータコール、サービスリクエストの４種類が挙げられている。なお、本実施の形態では、画像形成装置１００の変化後の状態で状態７０４が区分されているが、変化前と変化後との関係によって規定される状態変化の態様で区分してもよい。切り替え有効／無効７０５の有効／無効の設定によって、状態７０４ごとに、通知方法の変更の可否が設定される。図７の設定例では、正常系またはワーニングの状態へ遷移した場合に、通知方法６０８で設定されている通知方法が変更され得る。具体的には、図７に示す設定状態で、正常系またはワーニングの状態へ遷移した場合に、通知方法６０８で設定されている通知方法がｉｎｆｏｒｍであったときには、一時的にｉｎｆｏｒｍからｔｒａｐに切り替えて通知が実施される。オペレータコール、サービスリクエストに関しては、無効固定の設定であるため、変化後の状態にかかわらず、通知方法６０８で設定された通知方法で通知が実施される。
【００４０】
履歴確認７０６は、履歴を確認するためのボタンであり、履歴確認７０６が押下されると、表示画面が切り替わり、ログに記録された履歴内容等が表示される。通知方法／履歴の設定が完了し、ユーザがＯＫボタン７０７を押下することにより、操作部１４０から制御部１１０に対して各設定値が送信され、制御部１１０は受信した設定値に基づいてＳＮＭＰｖ３の状態変化通知を行う。なお、管理テーブルＴＢＬ（図４）に格納される、再通知を実施するためのエントリーの情報には、図５、図６で設定された内容が含まれる。
【００４１】
図８は、状態通知処理のフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０内のＣＰＵ（不図示）がＲＯＭまたはＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現される。この処理は、画像形成装置１００の電源がオンにされると開始される。
【００４２】
まずステップＳ１０１では、制御部１１０は、画像形成装置１００の状態が変化したか否かを検知し、状態変化を検知するまでその処理を継続する。制御部１１０は、本発明における検知手段に該当する。なお、状態変化を検知している間に画像形成装置１００の電源がオフにされた場合は、図８の処理は終了する。制御部１１０は、状態変化を検知すると、処理をステップＳ１０２に進める。ステップＳ１０２では、制御部１１０は、検知した状態変化が正常系であるか否かを判別し、状態変化が正常系である場合は、処理をステップＳ１０４に進める。一方、状態変化が正常系でない場合は、ステップＳ１０３で、制御部１１０は、検知した状態変化がワーニング系であるか否かを判別する。そして制御部１１０は、状態変化がワーニング系である場合は処理をステップＳ１０４に進める一方、状態変化がワーニング系でない場合は、処理をステップＳ１１０に進める。ステップＳ１１０では、制御部１１０は、検知した状態変化は重要状態であると判定する。制御部１１０は、ステップＳ１０２、Ｓ１０３において、本発明における判定手段としての役割を果たす。
【００４３】
ここで、正常系の状態とは、例えば、画像形成装置１００への電源投入直後のほか、スリープ復帰時のウォーミングアップ動作時、あるいはその後にスタンバイへ遷移した状態である。ワーニング系の状態とは、例えば、画像形成装置１００で消費される消耗品（用紙やトナー等）の残量が減少しているが、現時点では通常動作が可能な状態である。重要状態は、オペレータコール系、もしくはそれ以上の差し迫った問題（例えば、サービスリクエスト）の問題が生じた状態である。本実施の形態では、正常系とワーニング系とを、画像形成装置１００が通常動作可能な状態（所定の態様）に含めている。一方、通常動作可能でない状態を重要状態としている。このように、ステップＳ１０４以降を実行するかステップＳ１１１以降を実行するかは、状態変化の態様によって判断されるが、動作に与える影響の重要度に応じて判断してもよい。例えば、変化前と変化後の消費電力の差が所定以上である場合や、遷移先の状態が長時間続くことが予想される場合（シャットダウン等）は、重要状態と判断するようにしてもよい。また、正常系から正常系への状態変化の通知は重要ではないが、ワーニングから正常系への復帰は確実に通知したいといったことも考えられる。そこで、ワーニングから正常系へ遷移した場合は、重要状態と判断されるようステップＳ１１０へ移行するようにしてもよい。なお、所定の態様を任意に設定可能に構成してもよい。すなわちステップＳ１０４以降を実行するかステップＳ１１１以降を実行するかの基準を、ユーザが予め決定できるように構成してもよい。
【００４４】
ステップＳ１１０の後、ステップＳ１１１へ処理が進む。通知先の数が複数である場合、ステップＳ１１１以降の処理は１つずつの通知先に関して順番に実行される。ステップＳ１１１では、制御部１１０は、今回の通知先に対して通知方法６０８（図６）で設定された通知方法を、使用する通知方法として決定し、その通知方法による通知処理を開始する。制御部１１０は、ＳＮＭＰモジュール２０２及び通信モジュールＵＤＰ／ＩＰ２０３を制御して、通知処理を実現する。次に、ステップＳ１１２では、制御部１１０は、今回の通知先に対して通知方法６０８で設定された通知方法がｉｎｆｏｒｍであるか否かを判別する。そして、設定された通知方法がｉｎｆｏｒｍである場合は、制御部１１０は、ステップＳ１１３でＩｎｆｏｒｍ通知を行う。すなわち制御部１１０は、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の仕組みを使用して、ステップＳ１０１で検知した状態変化を、アドレス設定項目６０７（図６）で設定された通知先へ通知する（図２（ｂ））。
【００４５】
次に、ステップＳ１１４では、制御部１１０は、通知先（監視端末１６１等）からの応答をＲｅｓｐｏｎｓｅ２１０として受け取ったかどうかによって、ｉｎｆｏｒｍで通知した状態変化の到達確認ができたか否かを判別する。ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の到達確認の判断は、送信先アドレスからのＲｅｓｐｏｎｓｅ２１０の受信が所定時間内に確認できたか否かで行われる。そして、到達確認ができた場合は、ステップＳ１１５で、制御部１１０は、通知した内容と到達確認の結果を履歴としてログに記録する。ログは例えば、ＨＤＤ１５０に保存される。一方、到達確認ができなかった場合は、制御部１１０は、ステップＳ１１６で、所定回数まで再送信を行うための管理テーブルＴＢＬ（図４）に、状態変化や通知先に関する情報をエントリーとして追加してから、処理をステップＳ１１５に進める。なお、到達確認ができた場合には通知先へ状態変化の通知を確実に行えたため、ステップＳ１１５では、あえて画像形成装置１００内での履歴管理を行わず、履歴記録をしないという処理を採用することも可能である。
【００４６】
次に、ステップＳ１１９では、制御部１１０は、全ての通知先への状態通知を完了したか否かを判別する。制御部１１０は、通知未実施の通知先がある場合は、処理をステップＳ１１２へ戻して、未通知の通知先に対して同様の処理を繰り返す一方、全ての通知先への状態通知を完了した場合は、処理をステップＳ１０１へ戻す。
【００４７】
ステップＳ１１２の判別の結果、通知方法６０８で設定された通知方法がｉｎｆｏｒｍでない場合は、設定された通知方法がｔｒａｐであるので、制御部１１０は処理をステップＳ１１７へ進める。ステップＳ１１７では、制御部１１０は、ｔｒａｐ２０１の仕組みを使用して、ステップＳ１０１で検知した状態変化を、アドレス設定項目６０７（図６）で設定された通知先へ通知する（図２（ａ））。ｔｒａｐ２０１の仕組みはＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の仕組みとは異なり到達確認ができない。そのため、通知した内容が監視端末側で受信できたか否かによらず、通知先への通知を実施したことで通知処理は完了となる。従って、ステップＳ１１８では、制御部１１０は、通知内容の履歴をログに記録し、処理をステップＳ１１９に進める。
【００４８】
通知先の数が複数である場合、ステップＳ１０４以降の処理は１つずつの通知先に関して順番に実行される。ステップＳ１０４では、制御部１１０は、今回の通知先に対して通知方法６０８で設定された通知方法がｉｎｆｏｒｍであるか否かを判別する。設定された通知方法がｉｎｆｏｒｍでない場合は、設定された通知方法はｔｒａｐであり、通知方法を変更する必要がないので、処理をステップＳ１０７に進める。一方、設定された通知方法がｉｎｆｏｒｍである場合は、制御部１１０は、通知方法切り替え設定７０１の変更可能設定７０３（図７）で、通知方法の変更が可能と設定されているか否かを判別する。ここでは、今回、変化した状態に対応する切り替え有効／無効７０５の設定値から判定され、例えば、図７に示す設定例では、正常系、ワーニング系のいずれの場合も、通知方法の変更が可能と設定されていると判定される。
【００４９】
ステップＳ１０５の判別の結果、今回、変化した状態に対して通知方法の変更が可能と設定されていない場合は、制御部１１０は、通知方法を変更できないので、処理をステップＳ１０７に進める。一方、今回、変化した状態に対して通知方法の変更が可能と設定されている場合は、処理をステップＳ１０６に進める。すなわち、今回、変化した状態が、通常動作可能な状態であり且つ、通知方法の変更が可能であるので、到達確認の必要性が低いと判断できる。そこで、ステップＳ１０６では、制御部１１０は、設定された通知方法をｉｎｆｏｒｍからｔｒａｐへ一時的に切り替えることで、不達の場合における管理テーブルＴＢＬの記憶残容量の減少を回避する。この場合、制御部１１０は、今回の通知先に対して通知方法６０８で設定された通知方法（ｉｎｆｏｒｍ）は変更することなく設定を維持する。これにより、通知方法は一時的に変更されるだけであるので、その後の状態変化時に影響を与えることがなく、次回の状態変化時にはｉｎｆｏｒｍでの通知が実施され得る。なお、制御部１１０は、通知方法をｉｎｆｏｒｍからｔｒａｐへ一時的に切り替える旨をユーザに予告するための報知を実施してもよい。その報知の方法は、画面表示や音声表示でもよい。
【００５０】
ステップＳ１０４またはステップＳ１０５からステップＳ１０７へ移行した場合は、通知方法６０８で設定された通知方法が、使用する通知方法として決定される。一方、ステップＳ１０６からステップＳ１０７へ移行した場合は、ｔｒａｐが、使用する通知方法として決定される。ステップＳ１０７では、制御部１１０は、ステップＳ１０１で検知した状態変化を、決定した通知方法にて、アドレス設定項目６０７（図６）で設定された通知先へ通知する。ステップＳ１０８では、制御部１１０は、通知内容の履歴をログに記録する。なお、ステップＳ１０６を経由した場合は、制御部１１０は、一時的に通知方法を変更した旨とそれに対応する通知先の情報も履歴としてログに記録する。これにより、通知方法の変更実績の記録を残すことができる。その後、ステップＳ１０９では、制御部１１０は、全ての通知先への状態通知を完了したか否かを判別する。制御部１１０は、通知未実施の通知先がある場合は、処理をステップＳ１０４へ戻して、未通知の通知先に対して同様の処理を繰り返す一方、全ての通知先への状態通知を完了した場合は、処理をステップＳ１０１へ戻す。ところで、制御部１１０は、ステップＳ１０４〜Ｓ１０７、Ｓ１１２、Ｓ１１３、Ｓ１１７において、本発明における決定手段及び制御手段としての役割を果たす。
【００５１】
図９は、再送処理のフローチャートである。このフローチャートの処理は、画像形成装置１００の制御部１１０内のＣＰＵ（不図示）がＲＯＭまたはＨＤＤ１５０等に格納されたプログラムを読み出して実行することにより実現される。この処理は、画像形成装置１００の電源がオンにされた後、所定の時間間隔で繰り返し実行される。
【００５２】
まず、ステップＳ２０１では、制御部１１０は、管理テーブルＴＢＬにエントリーが存在するか否かを判別し、管理テーブルＴＢＬにエントリーが存在しない場合は、図９の処理を終了させる。管理テーブルＴＢＬにエントリーが存在する場合は、制御部１１０は、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７に対するＲｅｓｐｏｎｓｅ２１０の受信がなされていないので、制御部１１０は、処理をステップＳ２０２に進める。ステップＳ２０２では、今回の処理対象のエントリーのリトライ時間が到来したか否かを判別する。ここで、リトライ時間は、予め定められた時間であり、エントリーが格納された時点からの経過時間と比較される。経過時間は、制御部１１０が備えるタイマにより計時される。経過時間がリトライ時間を超えた場合にリトライ時間が到来したと判別される。なお、制御部１１０は、管理テーブルＴＢＬにエントリーが複数ある場合、格納された順に処理対象とし、最後のエントリーを処理対象とした後に未削除のエントリーがある場合は最初のエントリーへ処理順を戻す。
【００５３】
ステップＳ２０２の判別の結果、今回の処理対象のエントリーのリトライ時間が到来していない場合は、制御部１１０は、ステップＳ２１５で、管理テーブルＴＢＬ内に次のエントリーが存在するか否かを判別する。そして、管理テーブルＴＢＬ内に次のエントリーが存在する場合は、ステップＳ２１６で、制御部１１０は、当該次のエントリーを処理対象のエントリーとするよう処理対象を進めて、処理をステップＳ２０２に戻す。一方、管理テーブルＴＢＬ内に次のエントリーが存在しない場合は、制御部１１０は、ステップＳ２１７で、所定の待ち時間を待つ待ち処理を実行してから、処理をステップＳ２０２に戻す。
【００５４】
ステップＳ２０２の判別の結果、今回の処理対象のエントリーのリトライ時間が到来した場合は、制御部１１０は、当該エントリーの情報に従ってＩｎｆｏｒｍでの再通知を実施する。すなわち、制御部１１０は、図８のステップＳ１１３と同様に、ＩｎｆｏｒｍＲｅｑｕｅｓｔ２０７の仕組みを使用して状態変化を通知する。次に、ステップＳ２０４では、制御部１１０は、図８のステップＳ１１４と同様に、ｉｎｆｏｒｍで通知した状態変化の到達確認ができたか否かを判別する。そして、制御部１１０は、到達確認ができた場合は、ステップＳ２１１で、到達確認ができたエントリーを管理テーブルＴＢＬから削除し、ステップＳ２１２で、通知した内容と到達確認の結果を履歴としてログに記録する。次に、制御部１１０は、ステップＳ２１３で、管理テーブルＴＢＬ内に次のエントリーが存在するか否かを判別する。そして、管理テーブルＴＢＬ内に次のエントリーが存在する場合は、ステップＳ２１４で、制御部１１０は、当該次のエントリーを処理対象のエントリーとするよう処理対象を進めて、処理をステップＳ２０２に戻す。一方、管理テーブルＴＢＬ内に次のエントリーが存在しない場合は、制御部１１０は、図９の処理を終了させる。
【００５５】
ステップＳ２０４の判別の結果、到達確認ができなかった場合は、制御部１１０は、ステップＳ２０５で、ｉｎｆｏｒｍによる再通知の回数が予め定められた回数上限を超過したか否かを判別する。そして、制御部１１０は、再通知の回数（再送回数）が回数上限を超過した場合は、処理をステップＳ２１１に進める。一方、再通知の回数が回数上限を超過していない場合は、制御部１１０は、ステップＳ２０６で、再通知の回数を係数するカウンタをインクリメントし、ステップＳ２０７で、通知した内容と到達確認の結果を履歴としてログに記録する。そして、制御部１１０は、ステップＳ２０８で、管理テーブルＴＢＬ内に次のエントリーが存在するか否かを判別する。そして、管理テーブルＴＢＬ内に次のエントリーが存在する場合は、ステップＳ２０９で、制御部１１０は、当該次のエントリーを処理対象のエントリーとするよう処理対象を進めて、処理をステップＳ２０２に戻す。一方、管理テーブルＴＢＬ内に次のエントリーが存在しない場合は、制御部１１０は、ステップＳ２１０で、所定の待ち時間を待つ待ち処理を実行してから、処理をステップＳ２０２に戻す。
【００５６】
ところで、図９で実行される管理テーブルＴＢＬに関する各処理は、通知先設定画面（図６）のアドレス設定項目６０７で設定された通知先と通知方法６０８で設定された通知方法（ｉｎｆｏｒｍ）とに紐付けして実現されるものである。従って、ｉｎｆｏｒｍ再通知後の到達確認が完了しない段階で、ユーザによってアドレス設定項目６０７や通知方法６０８での設定変更がなされた場合は、管理テーブルＴＢＬからエントリーを削除する等して無駄な再送処理を回避するようにしてもよい。すなわち、管理テーブルＴＢＬにエントリーが格納されている状態で、当該エントリーに対応する通知先が削除されるかまたは通知方法の設定がｔｒａｐへ変更された場合は、当該エントリーを管理テーブルＴＢＬから消去するようにしてもよい。
【００５７】
本実施の形態によれば、検知された変化先の状態の判定結果と設定された通知方法とに基づいて、使用する通知方法が決定される。特に、検知された変化先の状態が正常系またはワーニング系の場合は、設定された通知方法がｉｎｆｏｒｍ（第１の通知方法）であっても、使用する通知方法をｔｒａｐ（第２の通知方法）に切り替えるので、通知に対する到達確認を行う必要がない。そのため、不達による管理テーブルＴＢＬへのエントリーの格納が回避される。これにより、再通知のための情報の過剰な蓄積を抑制することができる。従って、記録されるデータ量が管理テーブルＴＢＬ用のメモリ容量をオーバーしてしまうことが回避される。
【００５８】
また、制御部１１０は、ｉｎｆｏｒｍからｔｒａｐへの変更を、通知方法の変更が可能と設定されていることを条件に実行し、しかも、変化後の状態ごとに通知方法の変更の可否を設定可能であるので、使い勝手が向上する。さらに、通知先ごとに、複数の通知先の各々に通知方法を設定可能であり、通知方法の切り替えも通知先ごとに判断されるので、使い勝手が高い。なお、通知方法の変更の可否を設定できるように構成することは必須でない。
【００５９】
また、検知された変化先の状態が重要状態である（所定の態様に該当しない）場合は、制御部１１０は、設定された通知方法を、使用する通知方法として決定する。これにより、設定されている通知方法がｉｎｆｏｒｍであれば、重要度の高い状態変化を確実にｉｎｆｏｒｍで通知できる。また、制御部１１０は、管理テーブルＴＢＬに格納された情報に基づいて、通知の到達を確認できなかった通知先へ状態変化を再通知するので、ｉｎｆｏｒｍによる通知処理を確実に行える。
【００６０】
なお、図８のステップＳ１０１で画像形成装置１００の状態変化が検知された場合に、ポーリングの頻度に応じて状態通知の可否または通知方法を決定するようにしてもよい。例えば、ポーリングの頻度が所定頻度より高い通知先に関してはポーリングの頻度が低い通知先よりも優先して通知を実施してもよい。また、ポーリングの頻度が所定頻度より低い通知先に関しては、設定された通知方法がｉｎｆｏｒｍであってもｔｒａｐへ変更して通知を実施してもよい。
【００６１】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６２】
以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【符号の説明】
【００６３】
１１０  制御部
１４０  操作部
１５０  ＨＤＤ
２０２  ＳＮＭＰモジュール
２０３  通信モジュールＵＤＰ／ＩＰ
【図１】
2017220045.tif 000003
【図２】
2017220045.tif 000004
【図３】
2017220045.tif 000005
【図４】
2017220045.tif 000006
【図５】
2017220045.tif 000007
【図６】
2017220045.tif 000008
【図７】
2017220045.tif 000009
【図８】
2017220045.tif 000010
【図９】
2017220045.tif 000011