"インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する画像形成装置。前記出力手段は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項1記載の画像形成装置。前記監視手段は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項1又は2記載の画像形成装置。インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、前記イベント情報を出力する出力手順とを画像形成装置が実行する管理方法。前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項4記載の管理方法。前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項4又は5記載の管理方法。インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、前記イベント情報を出力する出力手順とを画像形成装置に実行させる管理プログラム。前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項7記載の管理プログラム。前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項7又は8記載の管理プログラム。請求項7乃至9いずれか一項記載の管理プログラムを記録したコンピュータ読み取り可能な記録媒体。上記のような拡張アプリの状態の変化に関しても、画像形成装置の既存の機能に関するイベントと同様に通知対象とすることができれば、ユーザにとって便利である。この際、拡張アプリごとに、イベント通知機構が実装されたのでは、限られた機器のリソースを非効率に消費することになる。また、拡張アプリごとに、イベント通知機構が実装されたのでは、イベント通知機構の拡張性及び保守性等が損なわれてしまう。イベント通知機構の拡張のための改変が、拡張アプリごとに必要とされるからである。更に、自らの状態の変化に関して、拡張アプリ自身では通知できないイベントもある。例えば、拡張アプリが異常終了した場合、当該拡張アプリ自身は、そのイベントを通知することができない可能性がある。本発明は、上記の点に鑑みてなされたものであって、アプリケーションプログラムに関する状態の変化を適切に管理することのできる画像形成装置、管理方法、管理プログラム、及び記録媒体の提供を目的とする。そこで上記課題を解決するため、画像形成装置は、インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する。このような画像形成装置では、アプリケーションプログラムに関する状態の変化を適切に管理することができる。本発明によれば、アプリケーションプログラムに関する状態の変化を適切に管理することができる。以下、図面に基づいて本発明の実施の形態を説明する。図1は、第一の実施の形態の機器管理システムの構成例を示す図である。同図の機器管理システム1において、一以上の画像形成装置10、イベント管理サーバ20、及び管理者端末30は、LANLocalAreaNetwork等のネットワーク50有線又は無線の別は問わない。を介して通信可能に接続されている。画像形成装置10は、印刷、スキャン、コピー、及びFAX送受信等のうちの二以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を単体で有する機器が画像形成装置10として用いられてもよい。画像形成装置10には、機能拡張等を目的としてプログラムのインストール又はアンインストール等が可能である。イベント管理サーバ20は、画像形成装置10において発生する各種のイベントを示す情報以下、イベント情報という。の管理機能を有するコンピュータである。すなわち、本実施の形態において、イベント管理サーバ20は、画像形成装置10のイベント情報に関して既定の出力先又は通知先である。なお、イベントとは、例えば、画像形成装置10の状態の変化をいう。画像形成装置10の状態には、画像形成装置10のハードウェア資源の状態の変化のみならず、ソフトウェアの状態の変化も含まれる。管理者端末30は、画像形成装置10の管理者が利用するPC等の情報処理装置である。本実施の形態において、管理者端末30は、緊急性の高いイベント情報の出力先とされる。図2は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置10は、コントローラ11、スキャナ12、プリンタ13、モデム14、操作パネル15、ネットワークインタフェース16、及びSDカードスロット17等のハードウェアを有する。コントローラ11は、CPU111、RAM112、ROM113、HDD114、及びNVRAM115等を有する。ROM113には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。RAM112は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。CPU111は、RAM112にロードされたプログラムを処理することにより、各種の機能を実現する。HDD114には、プログラムやプログラムが利用する各種のデータ等が記録される。NVRAM115には、各種の設定情報等が記録される。スキャナ12は、原稿より画像データを読み取るためのハードウェア画像読取手段である。プリンタ13は、印刷データを印刷用紙に印刷するためのハードウェア印刷手段である。モデム14は、電話回線に接続するためのハードウェアであり、FAX通信による画像データの送受信を実行するために用いられる。操作パネル15は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。液晶パネルは、タッチパネル機能を有していてもよい。この場合、当該液晶パネルは、入力手段の機能をも兼ねる。ネットワークインタフェース16は、LAN等のネットワーク有線又は無線の別は問わない。に接続するためのハードウェアである。SDカードスロット17は、SDカード80に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置10では、ROM113に記録されたプログラムだけでなく、SDカード80に記録されたプログラムもRAM112にロードされ、実行されうる。なお、他の記録媒体例えば、CD-ROM又はUSBUniversalSerialBusメモリ等によってSDカード80が代替されてもよい。すなわち、SDカード80の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、SDカードスロット17は、記録媒体の種類に応じたハードウェアによって代替されればよい。図3は、第一の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置10は、一以上の拡張アプリ121、監視部122、及びイベント通知部123等を有する。拡張アプリ121は、画像形成装置10にインストールされるアプリケーションプログラムである。例えば、拡張アプリ121は、画像形成装置10が有する所定のAPIApplicationProgramInterfaceを利用して作成される。監視部122は、画像形成装置10の状態を監視する。例えば、監視部122は、各拡張アプリ121の状態を監視する。監視部122は、拡張アプリ121の状態の変化を示すイベント情報を生成し、該イベント情報をイベント通知部123に入力する。なお、各拡張アプリ121自身が通知可能なイベント情報に関しては、各拡張アプリ121よりイベント通知部123に入力される。イベント通知部123は、入力されたイベント情報を、イベント出力先又は通知先に出力又は通知する。第一の実施の形態において、イベント出力先は、イベント管理サーバ20又は管理者端末30である。なお、監視部122及びイベント通知部123は、画像形成装置10にインストールされたプログラムがCPU111に実行させる処理によって実現される。図4は、第一の実施の形態における画像形成装置の機能構成例を示す図である。同図において、監視部122は、拡張アプリ監視部131、イベント生成判定部132、及び生成ルール記憶部133等を含む。拡張アプリ監視部131は、各拡張アプリ121の状態を監視する。監視対象とされる拡張アプリ121は、インストール情報記憶部124が記憶する情報に基づいて特定可能である。すなわち、拡張アプリ121がインストールされると、当該拡張アプリ121の属性情報がインストール情報記憶部124に記録される。また、拡張アプリ121がアンインストールされると、当該拡張アプリ121の属性情報がインストール情報記憶部124より削除される。したがって、インストール情報記憶部124は、画像形成装置10にインストールされている拡張アプリ121の属性情報の一覧を記憶する。なお、インストール情報記憶部124は、例えば、HDD114又はNVRAM115等を用いて実現可能である。イベント生成判定部132は、拡張アプリ121の状態に変化が発生した場合に、当該変化に関するイベント情報の生成の要否等を、生成ルール記憶部133を用いて判定する。生成ルール記憶部133には、イベント情報の生成ルールを記憶する。イベント情報の生成ルールとは、どのような状態の変化が発生した場合に、どのようなイベント情報を生成すべきかを示す情報である。なお、生成ルール記憶部133は、例えば、HDD114又はNVRAM115等を用いて実現可能である。イベント通知部123は、イベント生成部141、イベント解析部142、出力方法判定部143、及びイベント出力部144等を有する。イベント生成部141は、拡張アプリ121や拡張アプリ監視部131から指定された通りにイベント情報を生成する。イベント解析部142は、イベント生成部141によって生成されるイベント情報を解析する。出力方法判定部143は、イベント情報の出力方法又は出力形態を、出力ルール記憶部145を用いて判定する。出力ルール記憶部145は、出力ルールを記憶する。出力ルールとは、イベント情報の内容に応じて、イベント情報の出力方法又は出力形態を示す情報である。出力ルール記憶部145は、例えば、HDD114又はNVRAM115等を用いて実現可能である。イベント出力部144は、出力方法判定部143によって判定された出力方法又は出力形態によって、イベント情報を出力する。以下、第一の実施の形態の画像形成装置10が実行する処理手順について説明する。図5は、第一の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。拡張アプリ監視部131は、インストール情報記憶部124にその属性情報が記録されている各拡張アプリ121の状態を定期的に監視するS101。拡張アプリ監視部131は、例えば、或る拡張アプリ121が停止したことを検知するとS102、イベント情報の生成の要否の判定をイベント生成判定部132に要求するS103。この際、拡張アプリ監視部131は、拡張アプリ121に関してどのような状態の変化が発生したのかをイベント生成判定部132に通知する。ここでは、拡張アプリ121が停止したことが通知される。イベント生成判定部132は、生成ルール記憶部133を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部131に出力するS104。図6は、第一の実施の形態の生成ルール記憶部の構成例を示す図である。同図は、生成ルール1及び生成ルール2の二つの生成ルールが記録された例を示す。各生成ルールは、生成条件及び生成内容等を含む。生成条件とは、拡張アプリ121の状態に変化に対して、イベント情報を生成する条件である。生成条件は、イベント情報の通知条件であるともいえる。イベント情報を生成するか否かの判定は、イベント情報を通知するか否かの判定と等価であるといえるからである。生成内容は、生成条件に合致した状態の変化に応じて生成すべきイベント情報の内容である。なお、本実施の形態において、イベント情報は、id、緊急度レベル、及びメッセージ等の情報を含む。idは、イベント情報の識別子である。緊急度レベルは、イベント情報が示す状態の変化の緊急度である。メッセージは、イベント情報が示す状態の変化を示す任意の文字列である。なお、同図では、生成ルール1に関して、括弧書きで拡張アプリ監視部と記載され、生成ルール2に関して、括弧書きで拡張アプリと記載されている。これは、生成ルール1は、拡張アプリ監視部131によって検知される状態の変化に関する生成ルールであり、生成ルール2は、各拡張アプリ121自身によって検知される状態の変換に関する生成ルールであることを示す。ここでは、拡張アプリ監視部131によって拡張アプリ121の停止が検知された例を説明している。したがって、当該拡張アプリ121の状態の変化すなわち、停止は、生成ルール1の生成条件に合致する。そこで、イベント生成判定部132は、生成ルール1の生成内容を拡張アプリ監視部131に出力する。続いて、拡張アプリ監視部131は、当該生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS105。イベント生成部141は、当該要求に応じ、idに各イベント情報に固有の番号が設定され、緊急度レベルに高が設定され、メッセージに停止理由が設定されたイベント情報を生成する。イベント生成部141は、生成されたイベント情報以下、対象イベント情報という。をイベント解析部142に出力するS106。なお、停止理由は、例えば、ステップS105の要求と共に、拡張アプリ監視部131よりイベント生成部141に対して通知されてもよい。続いて、イベント解析部142は、対象イベント情報を解析し、対象イベント情報より、id、緊急度レベル、及びメッセージのそれぞれの値を取得する。続いて、イベント解析部142は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部143に要求するS107。続いて、出力方法判定部143は、指定されたid、緊急度レベル、又はメッセージの値と、出力ルール記憶部145が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。図7は、第一の実施の形態の出力ルール記憶部の構成例を示す図である。同図は、出力ルール1及び出力ルール2の二つの出力ルールが記録された例を示す。各出力ルールは、適用条件及び出力方法等を含む。適用条件は、当該出力ルールが適用される条件である。出力方法は、当該出力ルールが適用される場合の出力方法である。対象イベント情報の緊急度レベルは、高である。したがって、ここでは、出力ルール1及び2の双方が適用される。そこで、出力方法判定部143は、管理者にメール送信と、イベント管理サーバに転送との二つの出力方法をイベント解析部142に出力するS108。なお、図7の出力ルール2の緊急度レベル=高/中/低は、緊急度レベルが、高、中、又は低であることを示す。また、出力方法の値は、便宜上、人間が理解可能な言葉によって記されているが、各出力方法を示す識別子であってもよい。続いて、イベント解析部142は、対象イベント情報と、出力方法判定部143による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部144に要求するS109。続いて、イベント出力部144は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部144は、対象イベント情報を、イベント管理サーバ20に転送するS110。また、イベント出力部144は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信するS111。なお、管理者のメールアドレスは、出力ルール1の出力方法のパラメータとして含まれていても良いし、イベント出力部144の設定情報として、例えば、HDD114等に記録されていてもよい。このように、本実施の形態によれば、停止特に、異常系の停止のような、拡張アプリ121自身では補足することができない状態の変化が生じた場合であっても、拡張アプリ監視部131によって、当該変化が検知される。したがって、拡張アプリ121では通知することのできないイベント情報を通知することができる。また、生成ルールによって、通知対象とする状態の変化を限定することができる。したがって、全ての変化についてイベント情報が通知されることによる煩雑さを回避することができる。また、出力ルールによって、イベント情報の出力先がイベント情報の内容に応じて振り分けられる。その結果、例えば、緊急性の高い状態の変化については、管理者に迅速に伝え、緊急性の低い状態の変化については、イベント管理サーバ20に蓄積しておく等といった、柔軟なイベント情報の管理形態を実現することができる。なお、イベント管理サーバ20に蓄積されたイベント情報の一覧は、例えば、Webページ等によって、任意のタイミングで閲覧可能としてもよい。続くステップS121以降は、拡張アプリ121内において重大なすなわち、緊急性の高い内部エラーが発生した場合に実行される処理手順である。内部エラーが発生した場合、拡張アプリ121自身が、生成ルール記憶部133を参照してイベント情報の生成の要否を判定する。拡張アプリ監視部131からは、内部エラーを検知することはできないからである。内部エラーの発生は、図6の生成ルール2の生成条件に該当する。そこで、拡張アプリ121は、生成ルール2の生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS121。この際、緊急度レベルは高に設定される。上記したように、ステップS121以降は、重大な内部エラーの発生に応じた処理だからである。ステップS122~S127は、上記したステップS106~S111と同様の処理手順が実行される。すなわち、S122~S127において処理対象とされるイベント情報の緊急度レベルは、S106~S111において処理対象とされたイベント情報の緊急度レベルと同じ高である。また、図7より明らかなように、本実施の形態の各出力ルールには、緊急度レベルに関して適用条件が設定されている。したがって、拡張アプリ121の重大な内部エラーを通知するイベント情報は、イベント管理サーバ20に転送されS126、また、管理者のメールアドレス宛に電子メールによって送信されるS127。続くステップS131以降は、拡張アプリ121内において軽微なすなわち、緊急性の低い内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ121は、生成ルール記憶部133を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図6の生成ルール2の生成条件に該当する。そこで、拡張アプリ121は、生成ルール2の生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS131。この際、緊急度レベルは中又は低に設定される。上記したように、ステップS131以降は、軽微な内部エラーの発生に応じた処理だからである。ステップS132~S136は、基本的に、上記したステップS106~S111と同様の処理手順が実行される。但し、軽微な内部エラーに応じたイベント情報の緊急度レベルは中又は低である。したがって、当該イベント情報には、出力ルール2のみが適用される。その結果、当該イベント情報は、イベント管理サーバ20に転送されるがS136、管理者のメールアドレス宛には送信されない。このように、拡張アプリ121によって内部的に検知される状態の変化に関しても、拡張アプリ監視部131によって検知される状態の変化と同様の仕組みによってイベント情報の生成及び出力が行われる。したがって、拡張アプリ121ごとに当該仕組みを実装する必要はない。次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。図8は、第二の実施の形態の機器管理システムの構成例を示す図である。図8中、図1と同一部分には同一符号を付し、その説明は省略する。図8に示される機器管理システム2では、イベント管理サーバ20a及び20bがネットワーク50に接続されている。イベント管理サーバ20aは、拡張アプリ121のエラー又は異常等に関するイベント情報を管理するコンピュータである。エラーには、拡張アプリ121の停止や拡張アプリ121の不正な動作等が含まれる。一方、イベント管理サーバ20bは、エラー以外の状態の変化に関するイベント情報を管理するコンピュータである。図9は、第二の実施の形態における画像形成装置の機能構成例を示す図である。図9中、図4と同一部分には同一符号を付し、その説明は省略する。図9において、拡張アプリ監視部131は、拡張アプリ設定監視部151及び機器設定監視部152等を含む。拡張アプリ設定監視部151は、各拡張アプリ121の設定情報を監視する。機器設定監視部152は、画像形成装置10の設定情報を監視する。なお、拡張アプリ121の設定情報及び画像形成装置10の設定情報は、例えば、HDD114又はNVRAM115等に記録されている。また、画像形成装置10の設定情報とは、複数の拡張アプリ121や拡張アプリ121以外の機能に対して影響する設定情報をいう。すなわち、画像形成装置10の設定情報は、複数の機能によって共用される設定情報、又は複数の機能によって共用される機能に関する設定情報をいう。以下、第二の実施の形態の画像形成装置10が実行する処理手順について説明する。図10は、第二の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。拡張アプリ設定監視部151は、インストール情報記憶部124にその属性情報が記録されている各拡張アプリ121の設定情報以下アプリ設定情報という。を取得するS201、S202。続いて、機器設定監視部152は、画像形成装置10の設定情報以下、機器設定情報という。を取得するS203、S204。なお、ステップS201~S204は、定期的に、又はいずれかの拡張アプリ121の設定情報若しくは画像形成装置10の設定情報の更新に応じて実行される。拡張アプリ監視部131は、取得された各アプリ設定情報と、機器設定情報とを比較又は照合し、両者の組み合わせに関して不整合の有無を判定する。どのような状態が不整合であるかは、外部ファイル等に設定されていてもよいし、拡張アプリ監視部131のロジック内に定義されていてもよい。不整合が検出された場合、拡張アプリ監視部131は、イベント情報の生成の要否の判定をイベント生成判定部132に要求するS205。この際、拡張アプリ監視部131は、アプリ設定情報と機器設定情報との間に不整合が発生したことをイベント生成判定部132に通知する。イベント生成判定部132は、生成ルール記憶部133を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部131に出力するS206。図11は、第二の実施の形態の生成ルール記憶部の構成例を示す図である。同図において、生成ルール2は、アプリ設定情報と機器設定情報との組み合わせが不正であることが生成条件とされている。したがって、イベント生成判定部132は、生成ルール2の生成内容を拡張アプリ監視部131に出力する。続いて、拡張アプリ監視部131は、当該生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS207。イベント生成部141は、当該要求に応じ、idに各イベント情報に固有の番号が設定され、種別にエラーが設定され、メッセージに不正な理由が設定されたイベント情報を生成する。また、イベント生成部141は、当該イベント情報に関して、出力方法にメール送信を設定し、出力先に管理者のメールアドレスを設定する。イベント生成部141は、生成されたイベント情報以下、対象イベント情報という。をイベント解析部142に出力するS208。なお、不正な理由は、例えば、ステップS207の要求と共に、拡張アプリ監視部131よりイベント生成部141に対して通知されてもよい。続いて、イベント解析部142は、対象イベント情報を解析し、イベント情報より、id、種別、メッセージ、出力方法、及び出力先のそれぞれの値を取得する。続いて、イベント解析部142は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部143に要求するS209。続いて、出力方法判定部143は、指定されたid、種別、メッセージ、出力方法、又は出力先の値と、出力ルール記憶部145が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。図12は、第二の実施の形態の出力ルール記憶部の構成例を示す図である。同図において、出力ルール1の適用条件は、対象イベント情報の種別が、エラーであることである。したがって、対象イベント情報には出力ルール1が適用される。また、対象イベント情報の送信方法はメール送信である。したがって、対象イベント情報には出力ルール3も適用される。そこで、出力方法判定部143は、エラーサーバに転送と、指定アドレスメール送信との二つの出力方法をイベント解析部142に出力するS210。なお、エラーサーバは、イベント管理サーバ20aを示す。続いて、イベント解析部142は、対象イベント情報と、出力方法判定部143による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部144に要求するS211。続いて、イベント出力部144は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部144は、対象イベント情報を、イベント管理サーバ20aに転送するS212。また、イベント出力部144は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信するS213。続くステップS221以降は、拡張アプリ121内において内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ121は、生成ルール記憶部133を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図11の生成ルール3の生成条件に該当する。そこで、拡張アプリ121は、生成ルール3の生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS221。したがって、イベント生成部141は、idに各イベント情報に固有の番号が設定され、種別にエラーが設定され、メッセージにエラーの理由が設定されたイベント情報を生成するS222。ステップS223~S226は、基本的に、上記したステップS210~S212と同様の処理手順が実行される。但し、当該イベント情報は、図12の出力ルール1の適用条件のみに該当する。したがって、当該イベント情報は、イベント管理サーバ20aには転送されるがS226、管理者のメールアドレス宛には送信されない。続くステップS231以降は、拡張アプリ121の処理の実行に応じて実行される処理手順である。この場合、拡張アプリ121は、生成ルール記憶部133を参照して、イベント情報の生成の要否を判定する。処理の実行は、図11の生成ルール4の生成条件に該当する。そこで、拡張アプリ121は、生成ルール3の生成内容を指定して、イベント情報の生成をイベント生成部141に要求するS231。したがって、イベント生成部141は、idに各イベント情報に固有の番号が設定され、種別にログが設定され、メッセージに処理内容が設定されたイベント情報を生成するS232。以降ステップS233~S236は、基本的に、上記したステップS223~S226と同様の処理手順が実行される。但し、当該イベント情報は、図12の出力ルール2の適用条件に該当する。したがって、当該イベント情報は、イベント管理サーバ20bに転送されるS236。このように、生成ルール及び出力ルールの設定内容に応じて、エラーを示すイベント情報と、単なるログであるイベント情報との転送先を区別することができる。次に、第三の実施の形態について説明する。第三の実施の形態では、第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一又は第二の実施の形態と同様でよい。図13は、第三の実施の形態の機器管理システムの構成例を示す図である。図13中、図1と同一部分には同一符号を付し、その説明は省略する。図13に示される機器管理システム3は、イベント管理サーバ20を含まない。但し、このことは、イベント管理サーバ20が含まれる形態と、第三の実施の形態とが排他的な関係にあることを示すものではない。イベント管理サーバ20が、ネットワーク50に接続されていてもよい。図14は、第三の実施の形態における画像形成装置の機能構成例を示す図である。図14中、図4と同一部分には同一符号を付し、その説明は省略する。図14において、画像形成装置10は、イベント保持部125を有する。イベント保持部125は、例えば、HDD114等を用いてイベント情報を一時的に保持する。すなわち、第三の実施の形態では、イベント生成部141によって生成されたイベント情報は、必ずしも直ちに出力先に出力されず、一時的にイベント保持部125に保持されうる。以下、第三の実施の形態の画像形成装置10が実行する処理手順について説明する。図15は、第三の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。同図では、イベント生成部141によって生成されたイベント情報がイベント解析部142に入力され、当該イベント情報に対する出力方法が判定された以降の処理手順が示されている。したがって、同図に示されている処理手順以前の処理手順は、第一又は第二の実施の形態において説明した処理手順例えば、図5のステップS101~S108等同様でよい。イベント解析部142は、イベント生成部141によって生成されたイベント情報及びその出力方法を指定して、当該イベント情報の出力をイベント出力部144に要求するS301。イベント出力部144は、指定された出力方法に拘わらず、当該イベント情報及び当該出力方法の保持をイベント保持部125に要求するS302。イベント保持部125は、当該イベント情報を、例えばHDD114に記録しておく。但し、イベント出力部144は、緊急度レベルが高であるイベント情報、又は種別がエラーであるイベント情報等、緊急性が高いイベント情報に関しては、出力方法にしたがって、即時的に出力先への出力処理を実行してもよい。なお、ステップS301及びS302は、イベント情報が生成されるたびに実行される。一方、ステップS303以降は、定期的に実行される。したがって、定期的な周期において生成されたイベント情報が、イベント保持部125によって保持される。ステップS303において、イベント解析部142は、保持されている未だ出力されていないイベント情報の件数の取得を出力方法判定部143に要求する。出力方法判定部143は、当該件数をイベント保持部125に問い合わせるS304。イベント保持部125は、当該問い合わせに応じ、現在保持されているイベント情報の件数を応答するS305。出力方法判定部143は、当該件数をイベント解析部142に応答するS306。当該件数が所定数例えば、10件等に到達した場合、イベント解析部142は、イベント保持部125によって保持されている各イベント情報及びその出力方法を取得するS307、S308。続いて、イベント解析部142は、当該各イベント情報及びその出力方法を指定して、当該各イベント情報の出力をイベント出力部144に要求するS309。なお、ここで、ステップS302以降が繰り返されないように、ステップS309の要求とステップS301の要求とは、イベント出力部144によって識別可能となるようにするとよい。例えば、ステップS309とS301とにおいて、イベント出力部144に対して呼び出されるメソッドが異なっていてもよいし、メソッドに対する引数が異なっていてもよい。続いて、イベント出力部144は、当該各イベント情報を、指定された出力方法によって出力するS310。例えば、イベント出力部144は、当該イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する。続いて、イベント解析部142は、ステップS308において取得された各イベント情報の削除をイベント保持部125に要求するS311。その結果、当該各イベント情報は、重複して出力されないように保持対象から除外される。上述したように、第三の実施の形態によれば、イベント情報は一時的に画像形成装置10内において保持され、定期的に出力される。したがって、例えば、機器管理システム3のように、イベント情報の出力先が管理者端末30に限定されている場合、管理者端末30に頻繁にイベント情報が通知されることによる煩雑さを低減させることができる。次に、第四の実施の形態について説明する。第四の実施の形態では、イベント出力部144の拡張性に関して説明する。なお、第四の実施の形態は、上記各実施の形態と組み合わせて実施される。上記各実施の形態では、出力ルールの定義に応じて、各種のイベント情報の出力先を変化させることができる。但し、出力ルールに定義可能な出力方法は、イベント出力部144の実装の範囲内に限定される。このことは、翻せば、イベント出力部144が対応可能な出力方法を容易に拡張可能とすることができれば、出力ルールに定義可能な出力方法の種類も容易に増加させることができることを意味する。そこで、第四の実施の形態において、イベント出力部144は、図16に示されるような構成を有する。図16は、第四の実施の形態におけるイベント出力部の機能構成例を示す図である。同図において、イベント出力部144は、インタフェース部161、一以上の出力方法実装部162、及び対応情報記憶部163等を含む。各出力方法実装部162は、それぞれ一つ出力方法に対応した実装である。例えば、或る出力方法実装部162は、管理者のメールアドレス宛の電子メールによるイベント情報の送信を行う。別の出力方法実装部162は、イベント管理サーバ20へのイベント情報の転送を行う。インタフェース部161は、イベント解析部142等とのインタフェースを担う部分である。すなわち、インタフェース部161は、イベント解析部142より、イベント情報及びその出力方法が指定されたイベント情報の出力要求を受け付ける。インタフェース部161は、指定された出力方法に対応する出力方法実装部162に、当該イベント情報の出力を実行させる。対応情報記憶部163は、出力方法と出力方法実装部162との対応情報を記憶する。すなわち、インタフェース部161は、対応情報記憶部163を参照して、出力方法に応じた出力方法実装部162を特定する。なお、対応情報記憶部163は、例えば、HDD114又はNVRAM115等を用いて実現可能である。図16に示されるような構成において、出力方法実装部162を動的にリンク可能なプログラムモジュールとすれば、新たな出力方法の追加を容易とすることができる。すなわち、新たな出力方法に応じた出力方法実装部162を実装し、当該出力方法実装部162に関する対応情報を対応情報記憶部163に登録すれば、基本的に、既存部分の改変を行うことなく新たな出力方法を有効とすることができる。対応情報記憶部163に対する設定は、例えば、インタフェース部161が操作パネル15又は監理者端末30等に表示させる対応情報設定画面を介して行われればよい。図17は、対応情報設定画面の表示例を示す図である。同図において、対応情報設定画面510は、対応情報一覧511、編集ボタン512,削除ボタン513、出力方法入力領域514、説明入力領域515、実装名入力領域516、及び追加ボタン517等を有する。対応情報一覧511は、対応情報記憶部163に記憶されている対応情報の一覧を表示する。各対応情報は、出力方法、説明、及び実装名等の項目を有する。出力方法は、出力方法を識別するための文字列である。すなわち、当該文字列が、出力ルール記憶部145の出力方法に設定される。同図の内容は、図12の出力ルール記憶部145に対応している。説明は、出力方法の内容を説明する文字列である。実装名は、当該出力方法に対応する出力方法実装部162のプログラムモジュール名である。対応情報一覧511において、いずれかの対応情報のチェックボタン511bがチェックされ、削除ボタン513が押下されると、当該対応情報が対応情報記憶部163より削除される。また、編集ボタン512が押下されると、当該対応情報の出力方法、説明、及び実装名が、出力方法入力領域514、説明入力領域515、又は実装名入力領域516に表示され、編集可能な状態となる。編集後、追加ボタン517が押下されると、編集後の対応情報が対応情報記憶部163に追加される。例えば、出力方法実装部162をバージョンアップした場合、バージョンアップ後のモジュール名によって実装名を更新することで、バージョンアップ後の出力方法実装部162を有効とすることができる。また、出力方法入力領域514、説明入力領域515、及び実装名入力領域516が空の状態において、各領域に値が入力され、追加ボタン517が押下されると、新たな対応情報が対応情報記憶部163に記録される。各出力方法実装部162に固有の設定情報の設定については、各出力方法実装部162が、操作パネル15又は監理者端末30等に表示させる設定画面を介して行われればよい。図18は、出力方法実装部の設定画面の一例を示す図である。同図の設定画面520は、出力方法表示領域521、説明表示領域522、及び実装名表示領域523、更新ボタン524、管理者アドレス入力領域525、及びOKボタン526等を有する。出力方法表示領域521、説明表示領域522、及び実装名表示領域523には、現在設定対象とされている出力方法実装部162の出力方法、説明、又は実装名が表示される。管理者アドレス入力領域524は、管理者のメールアドレスを入力させるための領域である。すなわち、図18の設定画面520は、管理者に対してメール送信を行う出力方法実装部162に関する設定画面の例である。したがって、他の出力方法に関する出力方法実装部162については、当該他の出力方法実装部162に固有の設定情報に関する入力領域が表示される。OKボタン526が押下されると、管理者アドレス入力領域524に入力されたメールアドレスが、当該出力方法実装部162に設定される。以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。"