(57)【要約】【課題】アラートを通知するか否かを動的に変更できる画像形成装置、状態通知方法及びプログラムを提供すること。【解決手段】通報状態を検出する通報状態検出手段６２と、通報状態に対応づけて通知先２００、３００への通知有り又は通知なしを登録した通知有無情報を記憶する通知有無情報記憶手段５１と、通報状態に対応づけて、通知先へ該通報状態を通知することが妥当か又は通知しないことが妥当かを登録した通知有無情報変更情報を記憶する通知有無情報変更情報記憶手段５４と、通知有無情報変更情報に、該通報状態を通知することが妥当と登録されている場合、通知有無情報の通報状態に対応づけられた通知なしを通知ありに変更する、通知有無情報変更手段６５と、を有することを特徴とする画像形成装置１００を提供する。【選択図】図１
2011250175.tif 000002
【特許請求の範囲】
【請求項１】
機器が通報状態となったことを通知先に通知する画像形成装置であって、
前記通報状態を検出する通報状態検出手段と、
前記通報状態に対応づけて前記通知先への通知あり又は通知なしを登録した通知有無情報を記憶する通知有無情報記憶手段と、
前記通報状態に対応づけて、前記通知先へ該通報状態を通知することが妥当か又は通知しないことが妥当かを登録した通知有無情報変更情報を記憶する通知有無情報変更情報記憶手段と、
前記通知有無情報変更情報に、前記通報状態検出手段が検出した前記通報状態に対応づけて通知することが妥当であると登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、
該通報状態を通知することが妥当でないと登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更する、通知有無情報変更手段と、
を有することを特徴とする画像形成装置。
【請求項２】
前記通知有無情報変更情報には、前記通報状態及び前記通知先に対応づけて、前記通知先へ通知する通知あり情報、又は、前記通知先へ通知しない通知なし情報が登録されており、
前記通報状態の前記通知先を判定する通知先判定手段、を有し、
前記通知有無情報変更手段は、前記通知有無情報変更情報の前記通報状態及び前記通知先に前記通知あり情報が登録されている場合は、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、
前記通報状態及び前記通知先に前記通知なし情報が登録されている場合は、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更する、
ことを特徴とする請求項１記載の画像形成装置。
【請求項３】
前記通知有無情報変更情報には、前記通報状態に対応づけて、該通報状態を通知すべき当該画像形成装置の状況又は通知すべきでない当該画像形成装置の状況、及び、前記通知先へ通知する通知あり情報又は前記通知先へ通知しない通知なし情報が登録されており、
前記通報状態に対応づけられた前記状況が成立するか否かを判定する状況判定手段を有し、
前記通知有無情報変更手段は、前記通知有無情報変更情報の前記状況が成立し、かつ、前記通報状態に前記通知あり情報が登録されている場合は、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、
前記状況が成立せず、かつ、前記通報状態に前記通知あり情報が登録されている場合は、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更する、
ことを特徴とする請求項１記載の画像形成装置。
【請求項４】
前記通報状態検出手段が前記通報状態を検出した場合、前記通報状態の検出履歴を履歴テーブルに記憶する検出履歴記憶手段を有し、
前記検出履歴記憶手段は、前記通報状態検出手段が前記通報状態の解消を検出した場合、前記履歴テーブルの該通報状態の検出履歴を消去する、
ことを特徴とする請求項１〜３いずれか１項記載の画像形成装置。
【請求項５】
前記通知先から前記通報状態の問い合わせを受信した場合、前記履歴テーブルに登録された前記検出履歴を前記通知先に送信する、
ことを特徴とする請求項４記載の画像形成装置。
【請求項６】
前記通報状態はＭＩＢに格納されており、前記通知先とＳＮＭＰに基づき通信する、
ことを特徴とする請求項１〜５いずれか１項記載の画像形成装置。
【請求項７】
機器の通報状態に対応づけて通知先への通知あり又は通知なしを登録した通知有無情報を記憶する通知有無情報記憶手段と、
前記通報状態に対応づけて、前記通知先へ該通報状態を通知することが妥当か又は通知しないことが妥当かを登録した通知有無情報変更情報を記憶する通知有無情報変更情報記憶手段と、を有し、機器が前記通報状態となったことを前記通知先に通知する画像形成装置の状態通知方法であって、
通報状態検出手段が、前記通報状態を検出するステップと、
通知有無情報変更手段が、前記通知有無情報変更情報の前記通報状態に基づき、該通報状態を通知することが妥当か否かを判定するステップと、
前記通知有無情報変更情報に、該通報状態を通知することが妥当と登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、該通報状態を通知することが妥当でない登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更するステップと、
を有することを特徴とする状態通知方法。
【請求項８】
機器の通報状態に対応づけて通知先への通知あり又は通知なしを登録した通知有無情報を記憶する通知有無情報記憶手段と、
前記通報状態に対応づけて、前記通知先へ該通報状態を通知することが妥当か又は通知しないことが妥当かを登録した通知有無情報変更情報を記憶する通知有無情報変更情報記憶手段と、を有し、機器が前記通報状態となったことを前記通知先に通知する画像形成装置のＣＰＵに、
前記通報状態を検出するステップと、
前記通知有無情報変更情報の前記通報状態に基づき、該通報状態を通知することが妥当か否かを判定するステップと、
前記通知有無情報変更情報に、該通報状態を通知することが妥当と登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、該通報状態を通知することが妥当でない登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部にアラートを通知可能な画像形成装置、状態通知方法及びプログラムに関する。
【背景技術】
【０００２】
プリンタ等のＭＦＰ（Multifunction Peripheral）をネットワークを介してサーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等の通知先と接続した場合に、通知先からＭＦＰの状態を検出したい場合がある。このような状態の検出方法としてＭＩＢ（Management Information Base）とＳＮＭＰ（Simple Network Management Protocol）とを使用した通信方法が知られている。
【０００３】
ＳＮＭＰでは、ＭＦＰが通知先に対し能動的に状態を通知するＴｒａｐコマンドと、通知先からのＧｅｔＲｅｑｕｅｓｔコマンドに対し受動的に状態を通知するＧｅｔＲｅｓｐｏｎｓｅコマンドがある。ＭＦＰは、例えば自機の状態の変化を検出すると、ＭＩＢに格納された状態を示す状態情報（以下、アラートという）をＴｒａｐコマンドで通知先に通知する。通知先はアラートを解析して必要であればＧｅｔＲｅｑｕｅｓｔコマンドをＭＦＰに送信し、さらにＭＦＰの詳細な情報を取得することができる。
【０００４】
ＳＮＭＰでは下位プロトコルにＵＤＰ／ＩＰを利用するため、通知先はＧｅｔＲｅｑｕｅｓｔコマンドがＭＦＰに到達したか否かを把握できない。そこで、ＧｅｔＲｅｑｕｅｓｔコマンドを送信した通知先が、所定期間内にＭＦＰからＧｅｔＲｅｓｐｏｎｓｅコマンドを受信しない場合に、再度、ＧｅｔＲｅｑｕｅｓｔコマンドを送信する技術が考えられている（例えば、特許文献１参照。）。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に開示された技術では、ＭＦＰに状態の変化が生じると、Ｔｒａｐコマンドが常に通知先に送信されてしまうという問題がある。ネットワークに複数の通知先が接続されている場合、種々のＴｒａｐコマンドの通知先が考えられるが、通知先によっては状態を通知する必要がない場合がある。また、Ｔｒａｐコマンドでアラートを通知する際の機器の状況によっては、通知先にアラートを通知する必要がない場合もあり、必要であれば通知先がＧｅｔＲｅｑｕｅｓｔコマンドで取得すればよい場合もある。
【０００６】
一方、ＳＮＭＰではＭＩＢで管理する情報しかＭＦＰが送信することができず、ＭＩＢの情報のうち通知すべきアラートに対し、固定的にＴｒａｐコマンドによる通知の有無が登録されている。管理者としてはＴｒａｐコマンドによる通知の有無をＭＦＰやユーザの使用環境に応じて設定することができるが、いったん、登録した後は、アラートの通知先や状況に応じて、アラートの通知有無を変えることができず、柔軟な運用が困難になっていた。
【０００７】
本発明は、上記課題に鑑み、アラートを通知するか否かを動的に変更できる画像形成装置、状態通知方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、機器が通報状態となったことを通知先に通知する画像形成装置であって、前記通報状態を検出する通報状態検出手段と、前記通報状態に対応づけて前記通知先への通知あり又は通知なしを登録した通知有無情報を記憶する通知有無情報記憶手段と、前記通報状態に対応づけて、前記通知先へ該通報状態を通知することが妥当か又は通知しないことが妥当かを登録した通知有無情報変更情報を記憶する通知有無情報変更情報記憶手段と、前記通知有無情報変更情報に、前記通報状態検出手段が検出した前記通報状態に対応づけて通知することが妥当であると登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知なしを通知ありに変更し、該通報状態を通知することが妥当でないと登録されている場合、前記通知有無情報の前記通報状態に対応づけられた通知ありを通知なしに変更する、通知有無情報変更手段と、を有することを特徴とする。
【発明の効果】
【０００９】
アラートを通知するか否かを動的に変更できる画像形成装置、状態通知方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】ＭＦＰの概略を模式的に説明する図の一例である。
【図２】ＭＦＰ管理システムのシステム構成図の一例である。
【図３】ＭＦＰのハードウェア構成図の一例である。
【図４】ユーザＰＣのハードウェア構成図の一例を示す図である。
【図５】ＭＦＰの全体構成図の一例である。
【図６】ＳＮＭＰにおけるＴｒａｐコマンドの通信フォーマットの一例を示す図である。
【図７】アラート情報設定ファイルを模式的に説明する図の一例である。
【図８】変更判定テーブルの一例を示す図である。
【図９】Ｔｒａｐコマンドによるアラートの通知の手順の一例を示す図である。
【図１０】ＧｅｔＲｅｑｕｅｓｔコマンドによるアラートの通知の手順の一例を示す図である。
【図１１】ＭＦＰの機能ブロック図の一例である。
【図１２】ＭＦＰが通知先に応じてアラート情報設定ファイルを変更する動作手順を示すフローチャート図の一例である。
【図１３】図１２のステップＳ８の処理手順を示すフローチャート図の一例である。
【図１４】アラート情報設定ファイルの変更後の手順を模式的に説明する図の一例である。
【図１５】ＭＦＰの概略を模式的に説明する図の一例である（実施例２）。
【図１６】ＭＦＰの機能ブロック図の一例である（実施例２）。
【図１７】変更判定テーブルの一例を示す図である（実施例２）。
【図１８】ＭＦＰが状況に応じてアラート情報設定ファイルを変更する動作手順を示すフローチャート図の一例である。
【図１９】図１８のステップＳ１４〜Ｓ１５の処理手順を示すフローチャート図の一例である。
【図２０】アラートの通知有無を変更する手順を示すフローチャート図の一例である。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【実施例１】
【００１２】
図１は、本実施例のＭＦＰの概略を模式的に説明する図の一例である。アラート設定情報には、アラート毎にＴｒａｐコマンドによるそのアラートの通知の有無が登録されている。ＭＦＰ（Multifunction Peripheral）のユーザ又は管理者（以下、区別せずにユーザという）は、アラート毎に、全ての又は一部のアラート設定情報を設定することができる。なお、アラートとは警告の意味であるが、本実施例ではMＦＰの状態を知らせる情報とその状態が発生することをいい、警告という意味を含んでいなくてもよい。
【００１３】
図１（ａ）に示すように、「ＡＤＦ（Auto Document Feeder）リフトアップ」というアラートに対し、アラート設定情報では「Ｔｒａｐ通知なし」と登録されている。
【００１４】
この状態で「ＡＤＦリフトアップ」というアラートが発生した場合、ＭＦＰは、Ｔｒａｐコマンドによるアラートの通知先を確認する。ＳＮＭＰ（Simple Network Management Protocol）ではコミュニティという単位で監視される側のエージェントと監視する側のマネージャとのグループ化を可能にしている。ＭＦＰにはこのコミュニティが登録されており、ＭＦＰは登録されている全てのコミュニティ（通知先）にＴｒａｐコマンドによりアラートを通知することができる。
【００１５】
本実施例ではアラートの通知の前に、ＭＦＰがコミュニティとして登録されているマネージャを識別し、マネージャにそのアラートを通知すべきかを判定する。例えば、マネージャがサーバ系かクライアント系かを判定する。
【００１６】
ＭＦＰでは、「ＡＤＦリフトアップ」のアラートを検出した場合に、Ｔｒａｐコマンドを通知するか否かをアラート設定情報に登録することはできるが、ユーザがＭＦＰの前でＭＦＰを操作しているような場合に、「ＡＤＦリフトアップ」をユーザＰＣに通知する必要性は少ない。一方、サーバ系の通知先では、アラートを記録しておきたい場合が多い。
【００１７】
そこで、本実施例では変更判定テーブル５４に基づき、通知先に応じて通知の妥当性を判定し、通知の有無を変更する。こうすることで、サーバ系の通知先にはアラートを通知することができ、サーバ系のマネージャはＭＦＰの状態を管理することができる。
【００１８】
変更判定テーブル５４には、アラート毎に通知先がサーバ系の場合の通知有無、通知先がクライアント系の場合の通知有無、が登録されている。図１（ａ）では、通知先がサーバ系であると判明したとする。
【００１９】
ＭＦＰは変更判定テーブル５４を参照して、「ＡＤＦリフトアップ」というアラートに対し、「Ｔｒａｐ通知なし」から「Ｔｒａｐ通知あり」へアラート設定情報を変更する。こうすることで、サーバではアラートの記録を取ることができる。
【００２０】
また、図１（ｂ）に示すように、「ＡＤＦリフトアップ」というアラートに対し、アラート設定情報では「Ｔｒａｐ通知あり」と登録されていることもある。アラート設定情報は、ユーザが設定したものでも、本実施例の処理によりＭＦＰが変更したものでもよい。
【００２１】
この状態で「ＡＤＦリフトアップ」というアラートが発生した場合、ＭＦＰは、Ｔｒａｐコマンドによるアラートの通知先を確認する。図１（ｂ）では、通知先がクライアント系であると判明したとする。ＭＦＰは変更判定テーブル５４を参照して、「ＡＤＦリフトアップ」というアラートに対し、「Ｔｒａｐ通知あり」から「Ｔｒａｐ通知なし」へアラート設定情報を変更する。こうすることで、ユーザＰＣへの不要なアラートの通知を低減することができる。
【００２２】
１つのコミュニティには１台以上のマネージャが配置されるが、マネージャがサーバ系からクライアント系（またはこの逆）に変わることはなく、一度、設定されたアラート設定情報をアラートの通知先に応じて変更する必要性は少ない可能性がある。しかし、一台のＭＦＰは複数のコミュニティに属することができるので、１台のＭＦＰが異なるマネージャにアラートを通知することは少なくない。このような場合に、アラート設定情報が複数のマネージャに共通であっても、本実施例のＭＦＰは通知先に応じて、同じアラートの通知の有無を切り替えることができる。よって、ＳＮＭＰによるアラートの通知を柔軟に運用することができる。また、ユーザにアラートを煩わしく感じさせることを防止でき、また、サーバではアラートの発生を確実に記録することができる。
【００２３】
図２は、ＭＦＰ管理システム５００のシステム構成図の一例を示す。ＭＦＰ１００、ユーザＰＣ２００及びＭＦＰ管理サーバ３００がＬＡＮに接続されている。なお、ＬＡＮはネットワークの一例であって、ＶＬＡＮ（Virtual LAN）、ＷＡＮ、又は、インターネットなどでもよい。また、有線でも無線でもよい。
【００２４】
ユーザはユーザＰＣ２００にてアプリケーションソフトウェアを実行して、アプリケーションソフトウェアが生成した電子文書の印刷を、画像形成装置１００に要求する。印刷の際、ユーザＰＣ２００は、ＭＦＰ１００に印刷が可能か否かを問い合わせる。このようにユーザがユーザＰＣ２００を使用する場合、ユーザＰＣ２００が上記のクライアント系の通知先となる。例えば、印刷が困難な状態（紙詰まりなどが発生した状態）の場合、ＭＦＰ１００はユーザＰＣ２００にアラートを通知することができる。
【００２５】
このようなアラートの形態は、ユーザＰＣ２００がＧｅｔＲｅｑｕｅｓｔコマンドをＭＦＰ１００に送信し、ＭＦＰ１００がＧｅｔＲｅｓｐｏｎｓｅコマンドをユーザＰＣ２００に送信する形態であり、ＭＦＰ１００から見て受動的なアラートの通知となる。
【００２６】
これに対し、ＭＦＰ管理サーバ３００は、サーバ系の通知先である。ＭＦＰ管理サーバ３００は、主に、ＭＦＰ１００に発生したアラートを監視したり、Ｔｒａｐコマンドに対しＧｅｔＲｅｑｕｅｓｔコマンドをＭＦＰ１００に送信して、詳細な情報を得るため等に使用される。このようなアラートの形態は、ＭＦＰ１００がＴｒａｐコマンドをＭＦＰ管理サーバ３００に通知する形態であり、ＭＦＰ１００から見て能動的なアラートの通知となる。
【００２７】
このようにＭＦＰ１００は、受動的にだけでなく、能動的にアラートをＭＦＰ管理サーバ３００に通知することができる。しかしながら、ユーザＰＣ２００とＭＦＰ管理サーバ３００との物理的な相違は少なく、ＭＦＰ１００はＭＦＰ管理サーバ３００だけでなくユーザＰＣ２００をマネージャとして能動的にアラートを通知することができる。
【００２８】
ＭＦＰ１００がＴｒａｐコマンドをユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知する形態には次のような場合がある。なお、ＭＦＰ１００がエージェント、ユーザＰＣ２００及びＭＦＰ管理サーバ３００がマネージャである。
・ＭＦＰ１００とユーザＰＣ２００がＳＮＭＰの１つのコミュニティに属している。
・ＭＦＰ１００とＭＦＰ管理サーバ３００がＳＮＭＰの１つのコミュニティに属している。
・ＭＦＰ１００とユーザＰＣ２００がＳＮＭＰの１つのコミュニティに、同時に、ＭＦＰ１００とＭＦＰ管理サーバ３００がＳＮＭＰの１つのコミュニティに属している（ＭＦＰ１００が２つのコミュニティに属している）。
・ＭＦＰ１００、ユーザＰＣ２００及びＭＦＰ管理サーバ３００がＳＮＭＰの１つのコミュニティに属している（１つのコミュニティにマネージャが複数ある）。
【００２９】
このように、ＭＦＰ１００がＴｒａｐコマンドをユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知する種々の形態があるが、ＭＦＰ１００にはどのような形態でコミュニティが構成されているかが不明である。ＭＦＰ毎にユーザＰＣ２００とＭＦＰ管理サーバ３００がどのようにコミュニティを構成しているかを登録することも不可能ではないが、ＭＦＰ毎に設定が必要になり、また、新しいユーザＰＣ２００がＬＡＮに接続された場合の対応が困難になってしまう。
【００３０】
そこで、本実施例では、ＭＦＰ１００が通知先にサーバ系かクライアント系かを問い合わせて、通知すべき通知先にのみアラートを通知することにする。なお、ＭＦＰ１００は、ユーザＰＣ２００とＭＦＰ管理サーバ３００とを、例えば、ＯＳの種類、ユーザ名（ＭＦＰ管理サーバ３００には特定のユーザ名が登録される）等を問い合わせることで識別する。
【００３１】
図３は、ＭＦＰ１００のハードウェア構成図の一例を示す。ＭＦＰ１００は、コントローラ３０と、オペレーションパネル２５と、ファクシミリコントロールユニット（ＦＣＵ）２６と、撮像部２７及び印刷部２８が有する。
【００３２】
コントローラ３０は、ＣＰＵ１４と、ＡＳＩＣ１６と、ＮＢ（ノースブリッジ）１５と、ＳＢ（サウスブリッジ）１７と、ＭＥＭ−Ｐ（システムメモリ）１１と、ＭＥＭ−Ｃ（ローカルメモリ）１２と、ＨＤＤ（ハードディスクドライブ）１３と、メモリカードスロット２３と、ＮＩＣ（ネットワークインタフェースコントローラ）１８と、ＵＳＢデバイス１９と、ＩＥＥＥ１３９４デバイス２１と、セントロニクスデバイス２２とを有する。
【００３３】
ＣＰＵ１４は、種々の情報処理を実行するためのＩＣであり、アプリケーションプログラム（後述するアプリケーション４１）やプラットフォーム、オプションパッケージをＵＮＩＸ（登録商標）等のＯＳによりプロセス単位で並列的に実行する。ＡＳＩＣ１６は、画像処理用のＩＣである。ＮＢ１５は、ＣＰＵ１４とＡＳＩＣ１６を接続するためのブリッジである。ＳＢ１７は、ＮＢ１５と周辺機器等を接続するためのブリッジである。ＡＳＩＣ１６とＮＢ１５は、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介して接続されている。
【００３４】
ＭＥＭ−Ｐ１１は、ＮＢ１５に接続されたメモリである。ＭＥＭ−Ｃ１２は、ＡＳＩＣ１６に接続されたメモリである。ＨＤＤ１３は、ＡＳＩＣ１６に接続されたストレージであり、画像データ蓄積・文書データ蓄積・プログラム蓄積・フォントデータ蓄積・フォームデータ蓄積等を行うために使用される。プログラムには、アプリケーションプログラム（図示略）、後述する各種のコンポーネントのコンポーネントプログラム（図示略）、及び、アラート通知プログラム３１等がある。
【００３５】
メモリカードスロット２３は、ＳＢ１７に接続され、メモリカード２４をセット（挿入）するために使用される。メモリカード２４は、ＵＳＢメモリ等のフラッシュメモリであり、アラート通知プログラム３１を配布するために使用される。また、アラート通知プログラム３１は所定のサーバからＭＦＰ１００にダウンロードして配布することもできる。
【００３６】
ＮＩＣ１８は、ネットワーク等を介してＭＡＣアドレス等を使用したデータ通信を行うためのコントローラである。ＵＳＢデバイス１９は、ＵＳＢ規格に準拠したシリアルポートを提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２１は、ＩＥＥＥ１３９４規格に準拠したシリアルポートを提供するためのデバイスである。セントロニクスデバイス２２は、セントロニクス仕様に準拠したパラレルポートを提供するためのデバイスである。ＮＩＣ１８と、ＵＳＢデバイス１９と、ＩＥＥＥ１３９４デバイス２１と、セントロニクスデバイス２２と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＮＢ１５とＳＢ１７に接続されている。
【００３７】
オペレーションパネル２５は、ユーザがＭＦＰ１００に入力を行うためのハードウェア（操作部）であると共に、ＭＦＰ１００がオペレータに可視情報を提供するためのハードウェア（表示部）である。オペレーションパネル２５は、ＡＳＩＣ１６に接続されている。ＦＣＵ２６と、撮像部２７と、印刷部２８は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＡＳＩＣ１６に接続されている。
【００３８】
図４は、ユーザＰＣ２００のハードウェア構成図の一例を示す図である。なお、ＭＦＰ管理サーバ３００のハードウェア構成図はユーザＰＣ２００とほぼ同じなので説明を省略する。
【００３９】
ユーザＰＣ２００は、それぞれバスで相互に接続されているＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、記憶媒体装着部１０４、通信装置１０５、入力装置１０６、表示制御部１０７及び記憶装置１０８を有する。ＣＰＵ１０１は、ＯＳ、アプリケーションソフトウェアを記憶装置１０８から読み出して、ＲＡＭ１０２を作業メモリにして実行する。
【００４０】
ＲＡＭ１０２は必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ１０３にはＢＩＯＳや初期設定されたデータ、プログラムが記憶されている。
【００４１】
記憶媒体装着部１０４はＵＳＢケーブル等のケーブルや、可搬型の記憶媒体１１１を装着するインタフェースである。
【００４２】
通信装置１０５は、ＬＡＮカードやイーサネット（登録商標）カードと呼ばれ、ＭＦＰ１００からＴｒａｐコマンドを受信する。また、ＣＰＵ１０１からの指示によりＭＦＰ１００にＧｅｔＲｅｑｕｅｓｔコマンドを送信し、ＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する。
【００４３】
入力装置１０６は、キーボード、マウスなど、ユーザの様々な操作指示を受け付けるユーザインターフェイスである。タッチパネルや音声入力装置を入力装置とすることもできる。表示制御部１０７は、通報処理プログラム１１０が指示する画面情報に基づき所定の解像度や色数等でディスプレイ１０９の描画を制御する。ディスプレイ１０９は、液晶や有機ＥＬなどのＦＰＤ（Ｆｌａｔ  Ｐａｎｅｌ  Ｄｉｓｐｌａｙ）である。
【００４４】
記憶装置１０８は、ＨＤＤやフラッシュメモリなどの不揮発メモリを実体とし、ＯＳ、アプリケーションソフトウェア等を記憶している。記憶媒体１１１は、例えば、ＳＤカードやＵＳＢメモリなど不揮発性のメモリである。アプリケーションソフトウェアは、記憶媒体１１１に記録された状態又は不図示のサーバからダウンロードされる態様で配布される。
【００４５】
図５は、ＭＦＰ１００の全体構成図の一例を示す。ＭＦＰ１００は、上層から、オペレーションパネル２５、アプリケーション４１、プラットフォーム４３及びエンジン４２を有する。エンジン４２としては、画像形成するプロッタエンジン（図３の印刷部２８に相当）、原稿を読み取るスキャナエンジン（図３の撮像部２７に相当）、及び、ＦＡＸエンジン（図３のＦＣＵ２６に相当）等がある。
【００４６】
アプリケーション４１について詳細は省略したが、コピー用のアプリケーション４１であるコピーアプリと、プリンタ用のアプリケーション４１であるプリンタアプリと、スキャナ用のアプリケーション４１であるスキャナアプリと、ファクシミリ用のアプリケーション４１であるファクシミリアプリと、ネットワークファイル用のアプリケーション４１であるネットワークファイルアプリ等がある。アプリケーション４１は、このように、ＭＦＰ１００の各機能に固有な情報処理を実行するためのソフトウェアである。
【００４７】
プラットフォーム４３は、各アプリケーション４１と各アプリケーション４１から共通に利用されるソフトウェアを有する。なお、プラットフォーム４３とエンジン４２の間にはＯＳやデバイスドライバがある。
【００４８】
本実施形態のＭＦＰ１００は、「パイプ＆フィルタアーキテクチャ」を採用しており、ジョブの処理手段である「フィルタ」と、フィルタ間を接続する「パイプ」とを組み合わせ、ジョブを実行する。フィルタには、「入力フィルタ」、「加工フィルタ」、及び、「出力フィルタ」があり、これらは数あるソフトウェア部品の１つである。
【００４９】
このようなソフトウェア部品を本実施例では「コンポーネント」と称する。コンポーネントには、この他、アクティビティコンポーネント、及び、ＭＩＢコンポーネント５３等がある。
【００５０】
アクティビティコンポーネントは、上記各フィルタコンポーネントとパイプとの連携を制御するコンポーネントである。アクティビティコンポーネントは、いわばジョブや内部的な処理に必要なコンポーネントを組み合わせて、ＭＦＰ１００の機能を提供する。このアクティビティコンポーネントの１つに機器管理アクティビティコンポーネント（以下、機器管理アクティビティ５２という。）があり、機器管理アクティビティ５２は各コンポーネントを利用して、ＭＦＰ１００からユーザＰＣ２００又はＭＦＰ管理サーバ３００にアラートを通知する。
【００５１】
本実施例では、機器管理アクティビティ５２が、Ｔｒａｐコマンドによるアラートの通知の妥当性を判定する。アラートを通知することに妥当性があると判定した場合、機器管理アクティビティ５２はＭＩＢコンポーネント５３に、アラートの内容を通知すると共にアラートの通知を要求する。
【００５２】
ＭＩＢコンポーネント５３は、ＭＩＢ（Management Information Base）とＳＮＭＰに基づき、ユーザＰＣ２００又はＭＦＰ管理サーバ３００と通信する。ＭＩＢには、ＭＦＰ１００の状態がツリー構造で管理されている。ＭＦＰ１００の状態とは、ＡＤＦの状態、ドアの状態、トナー切れ、用紙切れ、エネルギー消費モード（省エネモード）等、である。ＳＮＭＰでは、ＭＩＢに登録されている状態であれば互いに送受信することができる。換言すると、ＭＩＢに登録されていない状態は、互いに送受信することができない。
【００５３】
ツリー構造のどのノードにどの状態が登録されるかは固定であり、ＭＦＰ１００だけでなく、ユーザＰＣ２００及びＭＦＰ管理サーバ３００にとって既知になっている。より具体的には、ＭＩＢにおいてＭＦＰ１００の状態が格納される１単位を「オブジェクト（Object）」といい、オブジェクトにはそれぞれ一意の「オブジェクトID（OID）」が割り当てられている。ＭＦＰ１００がＴｒａｐコマンドによりアラートを通知する場合、及び、ユーザＰＣ２００又はＭＦＰ管理サーバ３００がＧｅｔＲｅｑｕｅｓｔコマンドでＭＦＰ１００の状態を問い合わせる場合は、このＯＩＤを指定する。
【００５４】
機器管理アクティビティ５２はアラートを検出した場合、アラートの内容を後述するアラート発生履歴テーブル５５に登録する。また、機器管理アクティビティ５２は、ユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知すべきアラートか否かを判定し、通知すべきアラートの場合、アラートに応じて定まるＯＩＤのオブジェクトに状態を登録する。
【００５５】
ＭＩＢコンポーネント５３は、予め定められたオブジェクトを監視しており、状態が変化したオブジェクトの変化後の状態をＴｒａｐコマンドによりユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知する。これにより、ＭＩＢコンポーネント５３がアラートをユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知することができる。
【００５６】
なお、アラート発生履歴テーブル５５はＭＩＢのオブジェクトの１つであり（ＭＩＢコンポーネント５３による監視外の）、ユーザＰＣ２００又はＭＦＰ管理サーバ３００は、ＧｅｔＲｅｑｕｅｓｔコマンドでアラート発生履歴テーブル５５のアラートを取得することができる。
【００５７】
図６は、ＳＮＭＰにおけるＴｒａｐコマンドの通信フォーマットの一例を示す。この通信フォーマットは、ＩＰヘッダ、ＵＤＰヘッダ及びＳＮＭＰメッセージを有する。ＩＰヘッダは、送信元（ＭＦＰ１００）のＩＰアドレス、宛先（ユーザＰＣ２００又はＭＦＰ管理サーバ３００）のＩＰアドレス等を有する。ＵＤＰヘッダは、送信元（ＭＦＰ１００）の通信ポート、宛先（ユーザＰＣ２００又はＭＦＰ管理サーバ３００）の通信ポート等を有する。ＳＮＭＰメッセージは、ＳＮＭＰバージョン、コミュニティ名、及び、ＰＤＵ（Protocol Data Units）を有する。ＳＮＭＰバージョンはＳＮＭＰメッセージの従うＳＮＭＰのバージョンである。コミュニティ名は、エージェントとマネージャのグループを特定する。エージェントとマネージャには予めコミュニティ名が与えられており、マネージャとエージェントが同じコミュニティ名を有する場合のみ、両者が通信することができる。ＰＤＵには、Ｔｒａｐコマンド、ＯＩＤ及びその値等が含まれる。
【００５８】
ＭＩＢコンポーネント５３には、ユーザＰＣ２００及びＭＦＰ管理サーバ３００のＩＰアドレスが登録されている。よって、ＭＩＢコンポーネント５３は、図６のフォーマットのフィールドを満たして、ＴｒａｐコマンドをユーザＰＣ２００及びＭＦＰ管理サーバ３００に通知することができる。
【００５９】
図５に戻り、機器管理アクティビティ５２が、ユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知すべきアラートか否かを判定するための情報が設定されているのが、アラート情報設定ファイル５１である。アラート情報設定ファイル５１は、例えば、ＨＤＤ１３に記憶されている。
【００６０】
図７は、アラート情報設定ファイル５１を模式的に説明する図の一例である。アラート情報設定ファイル５１には、１つ以上のアラート設定情報が登録されている。アラート設定情報は、アラートの識別情報（α、β、γ…）に対応づけられた、「Ｔｒａｐ通知有無」である。図６では、アラートα、β、γ…が、例えば、トナーエンド、用紙切れ、ＡＤＦリフトアップ等を意味する。
【００６１】
「Ｔｒａｐ通知あり」が対応づけられたアラートは、ユーザＰＣ２００及びＭＦＰ管理サーバ３００の少なくともいずれかに通知され、「Ｔｒａｐ通知なし」が対応づけられたアラートは、ユーザＰＣ２００又はＭＦＰ管理サーバ３００のいずれにも通知されない。本実施例では、この「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に変更することができる。
【００６２】
アラートα、β、γ…は、ＯＩＤにより指定されるオブジェクトが特定の値を取ったことと同義である。例えば、アラート「トナーエンド」は、トナー状態が格納されるＯＩＤのオブジェクトの値がトナー切れを表す値になったことと同じである。アラートα、β、γ…は、少なくともアラート発生履歴テーブル５５に登録され、Ｔｒａｐコマンドにより通知されるか否かに関係なく、ＧｅｔＲｅｑｕｅｓｔコマンドによりユーザＰＣ２００又はＭＦＰ管理サーバ３００が取得することができる。
【００６３】
図５に戻り、アラート情報設定ファイル５１のＴｒａｐ通知有無を変更すべきか否か判定する情報が設定されているのが、変更判定テーブル５４である。変更判定テーブル５４は、例えば、ＨＤＤ１３に記憶されている。
【００６４】
図８は、変更判定テーブル５４の一例を示す図である。変更判定テーブル５４は、アラート識別情報と通知先に対応づけて、通知の有無が登録されている。例えば、アラートが「ＡＤＦリフトアップ」である場合、ユーザはＭＦＰ前にいると考えられる。また、ユーザが操作するのは、クライアント系のユーザＰＣ２００である。よって、通知先がクライアント系のユーザＰＣ２００の場合、「ＡＤＦリフトアップ」のアラートを通知しても、ユーザが確認することができない。一方、ＭＦＰ管理サーバ３００は、「ＡＤＦリフトアップ」のアラートを記録しておくべきであると考えられる。このため、例えば「ＡＤＦリフトアップ」のアラートには、クライアント系の通知先には「Ｔｒａｐ通知なし」、サーバ系の通知先には「Ｔｒａｐ通知あり」と、変更判定テーブル５４に登録される。
【００６５】
同様に、アラートが「非純正トナー検知」である場合、ユーザはトナーが純正か否かを問題にしないと考えられる。一方、ＭＦＰ管理サーバ３００は、「非純正トナー検知」のアラートを記録しておくべきである。このため、例えば「非純正トナー検知」のアラートには、クライアント系の通知先には「Ｔｒａｐ通知なし」、サーバ系の通知先には「Ｔｒａｐ通知あり」と、変更判定テーブル５４に登録される。
【００６６】
〔アラート情報設定ファイル５１に基づく通信（従来例）〕
まず、アラート情報設定ファイル５１に基づく通信の手順を説明する。
図９は、Ｔｒａｐコマンドによるアラートの通知の手順の一例を示す図である。アラート情報設定ファイル５１には、「トナーエンド」のアラートに対し、「Ｔｒａｐ通知あり」と、「給紙トレイ故障」のアラートに対し、「Ｔｒａｐ通知あり」と、それぞれ登録されている。
【００６７】
（１）ＭＩＢコンポーネント５３は、ＭＦＰ１００の起動直後やアラート情報設定ファイル５１に変更があると、アラート情報設定ファイル５１を読み込み、機器管理アクティビティ５２に登録する。こうすることで、ＭＩＢコンポーネント５３と機器管理アクティビティ５２とがアラート情報設定ファイル５１を共有する。
【００６８】
（２）アラート「トナーエンド」、アラート「給紙トレイ故障」が発生したとする。機器管理アクティビティ５２はこれらを検出する。
【００６９】
（３）機器管理アクティビティ５２は、アラート情報設定ファイル５１を参照して、「トナーエンド」が「Ｔｒａｐ通知あり」のアラートであると、「給紙トレイ故障」が「Ｔｒａｐ通知あり」のアラートであると、それぞれ判定する。
【００７０】
機器管理アクティビティ５２は、「トナーエンド」に対応したＯＩＤのオブジェクトをトナーエンドに対応した値に変更する。これにより、ＭＩＢコンポーネント５３にアラートの通知を要求したことになる。同様に、機器管理アクティビティ５２は、「給紙トレイ故障」に対応したＯＩＤのオブジェクトを給紙トレイ故障に対応した値に変更する。これにより、ＭＩＢコンポーネント５３にアラートの通知を要求したことになる。
【００７１】
また、機器管理アクティビティ５２は、「トナーエンド」と「給紙トレイ故障」のアラートを、アラート発生履歴テーブル５５に登録する。なお、機器管理アクティビティ５２は、アラートが解消すると（トナーエンドが補充された場合、給紙トレイが修理された場合）、アラート発生履歴テーブル５５からアラートを消去する。
【００７２】
（４）ＭＩＢコンポーネント５３は、ＭＩＢの変更を検出して、「トナーエンド」と「給紙トレイ故障」のアラートを、ＳＮＭＰメッセージのＯＩＤにて指定すると共にオブジェクトの値を格納することで、ユーザＰＣ２００又はＭＦＰ管理サーバ３００に通知する。「トナーエンド」と「給紙トレイ故障」を同時に通知してもよいし、別々のＳＮＭＰメッセージにより通知してもよい。これにより、通知先のユーザＰＣ２００又はＭＦＰ管理サーバ３００は、アラートを受信することができる。
【００７３】
（５）また、上記のとおり、ＭＦＰ１００がＴｒａｐコマンドで通知するアラートは、通知先がＧｅｔＲｅｑｕｅｓｔコマンドで取得することができるので、通知先はＧｅｔＲｅｑｕｅｓｔコマンドでアラート発生履歴テーブル５５又はＯＩＤにて特定されるオブジェクトの値を取得することができる。
【００７４】
図１０は、ＧｅｔＲｅｑｕｅｓｔコマンドによるアラートの通知の手順の一例を示す図である。アラート情報設定ファイル５１には、「ＡＤＦリフトアップ」のアラートに対し、「Ｔｒａｐ通知なし」と、「省エネモード中」のアラートに対し、「Ｔｒａｐ通知なし」と、それぞれ登録されている。
【００７５】
（１）ＭＩＢコンポーネント５３は、ＭＦＰ１００の起動直後やアラート情報設定ファイル５１に変更があると、アラート情報設定ファイル５１を読み込み、機器管理アクティビティ５２に登録する。こうすることで、ＭＩＢコンポーネント５３と機器管理アクティビティ５２とがアラート情報設定ファイル５１を共有する。
【００７６】
（２）アラート「ＡＤＦリフトアップ」、アラート「省エネモード中」が発生したとする。機器管理アクティビティ５２はこれらを検出する。
【００７７】
（３）機器管理アクティビティ５２は、アラート情報設定ファイル５１を参照して、「ＡＤＦリフトアップ」が「Ｔｒａｐ通知なし」のアラートであると、「省エネモード中」が「Ｔｒａｐ通知なし」のアラートであると、それぞれ判定する。この場合、機器管理アクティビティ５２は、「ＡＤＦリフトアップ」「省エネモード中」に対応したＯＩＤのオブジェクトの値に変更しない。したがって、ＭＩＢコンポーネント５３はＴｒａｐコマンドによるアラートを通知しない。
【００７８】
機器管理アクティビティ５２は、「ＡＤＦリフトアップ」と「省エネモード中」のアラートを、アラート発生履歴テーブル５５に登録する。なお、機器管理アクティビティ５２は、アラートが解消すると（ＡＤＦリフトアップが解消された場合、省エネモードから印字モードに移行した場合）、アラート発生履歴テーブル５５からアラートを消去する。
【００７９】
（４）通知先は、ＧｅｔＲｅｑｕｅｓｔコマンドでアラート発生履歴テーブル５５に登録されたアラートを取得することができる。通知先はＧｅｔＲｅｑｕｅｓｔコマンドでアラート発生履歴テーブル５５のアラートを取得することができる。なお、通知先には、Ｔｒａｐコマンドによるアラートが通知されていないので、取得のトリガーは、例えば、監視用の定期的な通信、ユーザのＭＦＰ管理サーバ３００の操作である。
【００８０】
以上のように、ＭＦＰ１００は、アラート情報設定ファイル５１に基づき、Ｔｒａｐコマンドによるアラートの通知の有無を制御することができる。また、Ｔｒａｐコマンドによりアラートを通知しない場合も、通知先はＧｅｔＲｅｑｕｅｓｔコマンドによりアラートを取得することができる。
【００８１】
〔ＭＦＰ１００の機能〕
図１１は、本実施例のＭＦＰ１００の機能ブロック図の一例を示す。機器管理アクティビティ５２は、全体制御部６１、アラート検出部６２、履歴管理部６３、通知先判定部６４及び設定ファイル変更部６５を有する。
これらの各機能ブロックは、ＣＰＵ１４がアラート通知プログラム３１を実行することで実現される。なお、図１１では、機器管理アクティビティ５２がこれらの機能ブロックを有するとしたが、これらの機能ブロックの一以上をＭＩＢコンポーネント５３が有していてもよい。
【００８２】
全体制御部６１は、アラートの通知の全体を制御する。アラート検出部６２は、ＭＦＰ１００の各部位に備えられたセンサが検出する信号を監視して、ＭＦＰ１００に生じるアラートを検出する。アラートには、例えば、用紙切れ、トナー切れ、用紙ジャム、ＡＤＦリフトアップ、非純正トナー検知、ドアのオープン等、種々のアラートがある。
【００８３】
履歴管理部６３は、検出されたアラートをアラート発生履歴テーブル５５に登録し、また、アラートが解消されるとアラート発生履歴テーブル５５から解消されたアラートを消去する。
【００８４】
通知先判定部６４は、アラートの通知先がクライアント系かサーバ系かを判定する。判定するタイミングは、アラートが検出された直後、又は、ＭＦＰ１００の起動直後などであり、全体制御部６１により制御される。通知先判定部６４は、予め登録されているユーザＰＣ２００及びＭＦＰ管理サーバ３００のＩＰアドレスを指定してユーザＰＣ２００及びＭＦＰ管理サーバ３００と通信し、例えばＯＳの種類を問い合わせることで、通知先がクライアント系かサーバ系かを識別する。なお、通知先の種類は２種類に限らず３以上にすることもできる。
【００８５】
設定ファイル変更部６５は、アラート及び通知先に基づき変更判定テーブル５４を参照し、アラート情報設定ファイル５１の「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、それぞれ変更する。例えば、アラートαが検出され、通知先がクライアント系の場合、「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に変更する。当然ながら、アラート情報設定ファイル５１のアラートαのクライアント系に「Ｔｒａｐ通知なし」が対応づけられている場合、設定ファイル変更部６５はアラート情報設定ファイル５１を変更しない。
【００８６】
ＭＩＢコンポーネント５３は、ファイル設定部６６を有する。ファイル設定部６６は、ＣＰＵ１４がアラート通知プログラム３１を実行することで実現される。ファイル設定部６６を機器管理アクティビティ５２が有していてもよい。
【００８７】
ファイル設定部６６は、アラート情報設定ファイル５１の変更を検出し、変更後のアラート情報設定ファイル５１を機器管理アクティビティ５２に設定する。これにより、ＭＩＢコンポーネント５３と機器管理アクティビティ５２が変更後のアラート情報設定ファイル５１を共有できる。機器管理アクティビティ５２内の点線のアラート情報設定ファイル５１が、ＭＩＢコンポーネント５３が設定したアラート情報設定ファイル５１である。
【００８８】
＜動作手順＞
図１２は、ＭＦＰ１００が通知先に応じてアラート情報設定ファイル５１を変更する動作手順を示すフローチャート図の一例である。
【００８９】
まず、ＭＩＢコンポーネント５３のファイル設定部６６は、変更前のアラート情報設定ファイル５１を機器管理アクティビティ５２に設定する（Ｓ１）。
【００９０】
次に、ＡＤＦリフトアップが発生し、機器管理アクティビティ５２のアラート検出部６２が「ＡＤＦリフトアップ」のアラートを検出したとする（Ｓ２）。
【００９１】
履歴管理部６３は、アラート「ＡＤＦリフトアップ」をアラート発生履歴テーブル５５に登録する（Ｓ３）。
【００９２】
全体制御部６１は、ＭＩＢコンポーネント５３に、コミュニティとして登録されている通知先がクライアント系かサーバ系かを確認するよう要求する（Ｓ４）。
【００９３】
ＭＩＢコンポーネント５３は、コミュニティとして登録されている通知先のＩＰアドレスを指定して、クライアント系かサーバ系かを問い合わせる（Ｓ５）。これにより、ＭＩＢコンポーネント５３はクライアント系かサーバ系かを示す通知先情報を取得する（Ｓ６）。
【００９４】
ＭＩＢコンポーネント５３は、通知先情報を機器管理アクティビティ５２に通知する（Ｓ７）。
ＭＩＢコンポーネント５３の通知先判定部６４は、通知先情報がクライアント系の場合、アラート「ＡＤＦリフトアップ」に対応づけられていた「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に変更し（Ｓ８ａ）、通知先情報がサーバ系の場合、アラート「ＡＤＦリフトアップ」に対応づけられていた「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に変更する（Ｓ８ｂ）。
【００９５】
図１３は、ステップＳ８の処理手順を示すフローチャート図の一例である。全体制御部６１は、通知先情報を取得する（Ｓ８１）。
【００９６】
設定ファイル変更部６５は、アラートの識別情報と通知先情報により特定される変更判定テーブル５４のフィールドが「Ｔｒａｐ通知あり」又は「Ｔｒａｐ通知なし」のいずれかを特定する（Ｓ８３）。
【００９７】
設定ファイル変更部６５は、「Ｔｒａｐ通知あり」の場合は、アラート情報設定ファイル５１を「Ｔｒａｐ通知あり」に変更し、「Ｔｒａｐ通知なし」の場合は、アラート情報設定ファイル５１を「Ｔｒａｐ通知なし」に変更する。
【００９８】
そして、アラート情報設定ファイル５１が変更されることで、ファイル設定部６６がアラート情報設定ファイル５１の再度の設定を開始する。
【００９９】
図１４は、アラート情報設定ファイル５１の変更後の手順を模式的に説明する図の一例である。図１４は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」へ変更する手順なので、ステップＳ８ｂに対応した手順である。
【０１００】
これまで説明したように、ＭＩＢコンポーネント５３のファイル設定部６６は、変更前のアラート情報設定ファイル５１を機器管理アクティビティ５２と共有している。
【０１０１】
アラート情報設定ファイル５１には、「トナーエンド」のアラートに対し、「Ｔｒａｐ通知あり」と、「ＡＤＦリフトアップ」のアラートに対し、「Ｔｒａｐ通知なし」と、それぞれ登録されている。
【０１０２】
（１）ＭＩＢコンポーネント５３のファイル設定部６６は、ＭＦＰ１００の起動直後、アラート情報設定ファイル５１を読み込む。
【０１０３】
（２）ファイル設定部６６は、機器管理アクティビティ５２にアラート情報設定ファイル５１を設定する。こうすることで、ＭＩＢコンポーネント５３と機器管理アクティビティ５２とがアラート情報設定ファイル５１を共有する。
【０１０４】
（３）図１３の処理により、機器管理アクティビティ５２は、アラート情報設定ファイル５１を参照して、「ＡＤＦリフトアップ」に対応づけられた「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に変更する。
【０１０５】
（４）ファイル設定部６６は、アラート情報設定ファイル５１の変更を検出して、変更後のアラート情報設定ファイル５１を読み込む。
【０１０６】
（５）ファイル設定部６６は、機器管理アクティビティ５２にアラート情報設定ファイル５１を設定する。こうすることで、ＭＩＢコンポーネント５３と機器管理アクティビティ５２とが変更後のアラート情報設定ファイル５１を共有する。
【０１０７】
アラート情報設定ファイル５１に「Ｔｒａｐ通知あり」が設定されている場合、機器管理アクティビティ５２は図９の（３）以下の手順を実行する。
【０１０８】
図１２に戻り、機器管理アクティビティ５２は、ＭＩＢコンポーネント５３にアラートの通知を要求でき（図１２のＳ９）、ＭＩＢコンポーネント５３はＴｒａｐコマンドによりアラートを通知先に通知することができる（図１２のＳ１０）。
【０１０９】
なお、図１２のステップＳ８ａが実行された場合、機器管理アクティビティ５２は図１０の（３）以下の手順を実行する。すなわち、機器管理アクティビティ５２は、アラートを通知しないので、クライアント系のユーザＰＣ２００にアラートを通知することを防止できる。
【０１１０】
以上説明したように、本実施例のＭＦＰ１００は通知先に応じて、同じアラートの通知の有無を切り替えることができるので、ＳＮＭＰによるアラートの通知を柔軟に運用することができる。これにより、ユーザにアラートを煩わしく感じさせることを防止でき、また、サーバではアラートの発生を確実に管理できる。
【実施例２】
【０１１１】
実施例１では通知先に応じて、同じアラートの通知の有無を切り替えるＭＦＰ１００について説明したが、本実施例では、ＭＦＰ１００の状況に応じて同じアラートの通知の有無を切り替えるＭＦＰ１００について説明する。
【０１１２】
図１５は、本実施例のＭＦＰ１００の概略を模式的に説明する図の一例である。図１５（ａ）に示すように、「ドアオープン」というアラートに対し、アラート設定情報では「Ｔｒａｐ通知あり」と登録されている。この状態で「ドアオープン」というアラートが発生した。
【０１１３】
ＭＦＰ１００はアラートが発生すると、変更判定テーブル５４を参照して現在の状況がアラートを通知する状況か否かを判定する。変更判定テーブル５４には、アラート毎に状況とＴｒａｐコマンドによるアラートの通知有無が登録されている。図１５（ａ）の変更判定テーブル５４には「ドアオープン→ジャム発生→通知あり」と登録されている。
【０１１４】
状況の判定方法の１つが、アラート発生履歴テーブルを参照することであり、図１５（ａ）では「ジャム発生中」と登録されている。
【０１１５】
例えば、ジャムが発生中の場合、ユーザがＭＦＰ１００のドアをオープンすることは必要な作業であるため、通知先に通知する必要性は低い。また、例えば、「ステープルなし」のアラートが検出された場合、ステープル印刷中でなければ、通知する必要性は低い。
【０１１６】
このため、ＭＦＰ１００は、特定の状況では、Ｔｒａｐコマンドによる通知の有無を変更する。すなわち、ＭＦＰ１００は変更判定テーブル５４を参照して通知すべき又は通知すべきでない状況を特定し、現在の状況がアラートを通知する状況でなければ「Ｔｒａｐ通知あり」から「Ｔｒａｐ通知なし」に、現在の状況がアラートを通知する状況であれば「Ｔｒａｐ通知なし」から「Ｔｒａｐ通知あり」に、変更する。
【０１１７】
例えば、「ドアオープン」というアラートに対し、ジャムが発生中の場合、ＭＦＰは「Ｔｒａｐ通知あり」から「Ｔｒａｐ通知なし」へアラート設定情報を変更する。こうすることで、ユーザＰＣ２００又はＭＦＰ管理サーバ３００への不要なアラートの通知を低減することができる。
【０１１８】
また、図１５（ｂ）に示すように、「ドアオープン」というアラートに対し、アラート設定情報では「Ｔｒａｐ通知なし」と登録されていることもある。この状態で「ドアオープン」というアラートが発生した場合、ＭＦＰ１００は、変更判定テーブル５４を参照して現在の状況がアラートを通知する状況か否かを判定する。
【０１１９】
図１５（ｂ）のアラート発生履歴テーブル５４によれば、ドアオープンの前に記録紙のジャムが発生していない。ジャムが発生していない場合、ユーザがＭＦＰ１００のドアをオープンすることは不測性が強いため、通知する必要性が高い。
【０１２０】
このため、ＭＦＰ１００は、アラートに対応づけられた状況が発生していない場合、変更判定テーブルと逆に通知の有無を変更する。すなわち、ＭＦＰ１００は変更判定テーブル５４を参照して、「ドアオープン」というアラートに対し、「Ｔｒａｐ通知なし」から「Ｔｒａｐ通知あり」へアラート設定情報を変更する。こうすることで、通知すべきアラートは通知先に確実に通知することができる。
【０１２１】
図１６は、ＭＦＰ１００の機能ブロック図の一例を示す。図１６において図１１と同一部には同一の符号を付しその説明は省略する。図１６の機器管理アクティビティ５２は妥当性判定部６７を有する。
【０１２２】
妥当性判定部６７は、ＭＦＰ１００の状況を考慮すると、アラートが発生することが妥当か否かを判定する。アラートを通知することが妥当な状況は、発生したアラートに対応づけて変更判定テーブル５４に登録されている。
【０１２３】
図１７は、本実施例の変更判定テーブル５４の一例を示す。発生したアラートα、β、γ…に、「状況」及び「通知有無」が対応づけられている。変更判定テーブル５４の１行目によれば、例えば、発生したアラートが「アラートα」の場合、状況として「アラート１」が発生していた場合、Ｔｒａｐコマンドによるアラートが「Ｔｒａｐ通知なし」と設定されている。
【０１２４】
妥当性判定部６７は、アラート検出部６２が検出したアラートに対応づけられた状況を変更判定テーブル５４から読み出し、その状況がアラート発生履歴テーブル５５に登録されているか否かを判定する。
【０１２５】
登録されている場合、設定ファイル変更部６５は、変更判定テーブル５４の「通知有無」の設定に従い、アラート情報設定ファイル５１を変更する。すなわち、設定ファイル変更部６５は、現在の状況が変更判定テーブル５４に登録されている状況の場合、「通知有無」に登録されている「通知有無」に従い、アラート情報設定ファイル５１の「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、変更する。
【０１２６】
逆に、現在の状況が変更判定テーブル５４に登録されている状況でない場合、「通知有無」に登録されている「通知有無」と逆に、設定ファイル変更部６５は、アラート情報設定ファイル５１の「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、変更する。
【０１２７】
同様に、変更判定テーブル５４の２行目によれば、例えば、発生したアラートが「アラートβ」の場合、状況として「ジョブ１の実行中」である場合、Ｔｒａｐコマンドによるアラートが「Ｔｒａｐ通知あり」と設定されている。このように、「状況」はアラートである必要はない。なお、ジョブの内容は、機器管理アクティビティ５２がアプリケーション４１に問い合わせることで検出される。
【０１２８】
＜動作手順＞
図１８は、ＭＦＰ１００が状況に応じてアラート情報設定ファイル５１を変更する動作手順を示すフローチャート図の一例である。
【０１２９】
まず、ＭＩＢコンポーネント５３のファイル設定部６６は、変更前のアラート情報設定ファイル５１を機器管理アクティビティ５２に設定する（Ｓ１１）。
【０１３０】
次に、ドアオープンが発生し、機器管理アクティビティ５２のアラート検出部６２が「ドアオープン」のアラートを検出したとする（Ｓ１２）。
【０１３１】
履歴管理部６３は、アラート「ドアオープン」をアラート発生履歴テーブル５５に登録する（Ｓ１３）。
【０１３２】
次に、妥当性判定部６７は、変更判定テーブル５４を参照し、アラート「ドアオープン」に対応づけられた状況が現在の状況と一致するか否かを判定する（Ｓ１４）。ここでは、ジャムが発生中か否かを確認する。
【０１３３】
ジャム発生中の場合、ＭＩＢコンポーネント５３の設定ファイル変更部６５は、アラート「ドアオープン」に対応づけられていた「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に変更し（Ｓ１５ａ）、ジャム発生中でない場合、アラート「ドアオープン」に対応づけられていた「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に変更する（Ｓ１５ｂ）。
【０１３４】
図１９は、ステップＳ１４〜Ｓ１５の処理手順を示すフローチャート図の一例である。
【０１３５】
妥当性判定部６７は、アラート「ドアオープン」を通知先に通知することが妥当な状況鏡か否かを判定する（Ｓ９１）。すなわち、妥当性判定部６７は、発生したアラートに対応づけられた変更判定テーブル５４の「状況」が成立するか否かを判定する。
【０１３６】
妥当性判定部６７は、変更判定テーブル５４において、発生したアラート「ドアオープン」に対応づけられた「状況」か否かを、アラート発生履歴テーブル５５を参照したりアプリケーションに問い合わせることで判定する。
【０１３７】
「状況」が成立する場合（Ｓ９１のＹｅｓ）、設定ファイル変更部６５は、変更判定テーブル５４の「通知有無」に従い、「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、変更する（Ｓ９３）。
【０１３８】
「状況」が成立しない場合（Ｓ９１のＮｏ）、設定ファイル変更部６５は、変更判定テーブル５４の「通知有無」と逆に、「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、変更する（Ｓ９５）。
【０１３９】
アラート情報設定ファイル５１の変更後、ファイル設定部６６がアラート情報設定ファイル５１の再度の設定を開始する。よって、図１４の手順が実行され、ＭＩＢコンポーネント５３と機器管理アクティビティ５２が、変更後のアラート情報設定ファイル５１を共有できるようになる。
【０１４０】
アラート情報設定ファイル５１に「Ｔｒａｐ通知あり」が設定された場合、機器管理アクティビティ５２は図９の（３）以下の手順を実行する。
【０１４１】
なお、アラート情報設定ファイル５１に「Ｔｒａｐ通知なし」が設定された場合、機器管理アクティビティ５２は、図１０の（３）以下の手順を実行する。こうすることで、機器管理アクティビティ５２は、アラートを通知することを防止できる。
【０１４２】
図１８に戻り、機器管理アクティビティ５２は、ＭＩＢコンポーネント５３にアラートの通知を要求でき（図１８のＳ９）、ＭＩＢコンポーネント５３はＴｒａｐコマンドによりアラートを通知先に通知することができる（図１８のＳ１０）。
【０１４３】
以上説明したように、本実施例のＭＦＰ１００は状況に応じて、同じアラートの通知の有無を切り替えることができるので、ＳＮＭＰによるアラートの通知を柔軟に運用することができる。
【実施例３】
【０１４４】
実施例１と実施例２とを別々に説明したが、実施例１と実施例２のアラート情報設定ファイル５１の変更は、１つの画像形成装置にて実現できる。この場合、ＭＦＰ１００が状況に応じて変更したアラート設定情報が「Ｔｒａｐ通知あり」になった場合に通知先を確認し、通知有無を変更すればよい。こうすることで、状況に基づけば「Ｔｒａｐ通知あり」のアラートが発生したが、通知先によってはそのアラートの通知が不要であれば、不要なアラートの通知を防止できる。
【０１４５】
図２０は、アラートの通知有無を変更する手順を示すフローチャート図の一例である。図２０の手順は、図１９と図１３を組み合わせたものになっている。
【０１４６】
変更判定テーブルに登録された「状況」が成立する場合（Ｓ９１のＹｅｓ）、設定ファイル変更部６５は、変更判定テーブル５４の「通知有無」に従い、「状況」が成立しない場合（Ｓ９１のＮｏ）、設定ファイル変更部６５は、変更判定テーブル５４の「通知有無」と逆に、「Ｔｒａｐ通知あり」を「Ｔｒａｐ通知なし」に、又は、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に、変更する（Ｓ９３，Ｓ９５）。
【０１４７】
Ｓ９３とＳ９５のいずれの場合も、「Ｔｒａｐ通知なし」を「Ｔｒａｐ通知あり」に変更する場合がある。このため、通知先判定部６４は、アラート情報設定ファイル５１において発生したアラートに対応づけられた「通知有無」が「Ｔｒａｐ通知あり」になっているか否かを判定する（Ｓ１０１）。通知する必要がないアラートは、通知先に関係なく通知が不要なため、この判定により処理を振り分ける。
【０１４８】
「Ｔｒａｐ通知あり」になっている場合（Ｓ１０１のＹｅｓ）、全体制御部６１は、通知先情報を取得する（Ｓ８１）。
【０１４９】
設定ファイル変更部６５は、発生したアラート「ドアオープン」の識別情報と通知先情報により特定される変更判定テーブル５４のフィールドが「Ｔｒａｐ通知あり」又は「Ｔｒａｐ通知なし」のいずれかを特定する（Ｓ８３）。
【０１５０】
設定ファイル変更部６５は、「Ｔｒａｐ通知あり」の場合はＭＩＢコンポーネント５３にアラートの通知を要求する（Ｓ１０３）。これにより、ＭＦＰ１００は、状況に応じてアラートの通知の有無を切り変え、通知ありの場合は通知先に応じた通知の有無を判定できる。
【０１５１】
本実施例のＭＦＰ１００は、状況と通知先に応じて、同じアラートの通知の有無を切り替えることができるので、ＳＮＭＰによるアラートの通知をより柔軟に運用することができる。
【符号の説明】
【０１５２】
１３        ＨＤＤ
１４        ＣＰＵ
３１        アラート通知プログラム
５１        アラート情報設定ファイル
５２        機器管理アクティビティ
５３        ＭＩＢコンポーネント
５４        変更判定テーブル
６１        全体制御部
６２        アラート検出部
６３        履歴管理部
６４        通知先判定部
６５        設定ファイル変更部
６６        ファイル設定部
６７        妥当性判定部
１００      ＭＦＰ
２００      ユーザＰＣ
３００      ＭＦＰ管理サーバ
５００      ＭＦＰ管理システム
【先行技術文献】
【特許文献】
【０１５３】
【特許文献１】特開平１１‐１５４９５０号公報
【図１】
2011250175.tif 000003
【図２】
2011250175.tif 000004
【図３】
2011250175.tif 000005
【図４】
2011250175.tif 000006
【図５】
2011250175.tif 000007
【図６】
2011250175.tif 000008
【図７】
2011250175.tif 000009
【図８】
2011250175.tif 000010
【図９】
2011250175.tif 000011
【図１０】
2011250175.tif 000012
【図１１】
2011250175.tif 000013
【図１２】
2011250175.tif 000014
【図１３】
2011250175.tif 000015
【図１４】
2011250175.tif 000016
【図１５】
2011250175.tif 000017
【図１６】
2011250175.tif 000018
【図１７】
2011250175.tif 000019
【図１８】
2011250175.tif 000020
【図１９】
2011250175.tif 000021
【図２０】
2011250175.tif 000022