画像形成装置、管理方法、管理プログラム、及び記録媒体
【課題】アプリケーションプログラムに関する状態の変化を適切に管理すること。
【解決手段】画像形成装置は、インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する。
【解決手段】画像形成装置は、インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置、管理方法、管理プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
近年、公開されたＡＰＩ（Application Program Interface）を利用して、その出荷後に新たなアプリケーションプログラムの開発及びインストールが可能とされている画像形成装置が一般化している。 斯かるＡＰＩを利用して開発されたアプリケーションプログラム（以下、「拡張アプリ」という。）によれば複雑なワークフローの実現等が可能となり、ユーザの業務効率の向上等を図ることができる（例えば、特許文献１）。
【０００３】
他方において、画像形成装置は、一般的に、要求されたジョブの開始若しくは終了、又は画像形成装置における異常の発生や消耗品の残量の低下等をユーザに通知するためのイベント通知機構を有する（例えば、特許文献２）。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような拡張アプリの状態の変化に関しても、画像形成装置の既存の機能に関するイベントと同様に通知対象とすることができれば、ユーザにとって便利である。この際、拡張アプリごとに、イベント通知機構が実装されたのでは、限られた機器のリソースを非効率に消費することになる。
【０００５】
また、拡張アプリごとに、イベント通知機構が実装されたのでは、イベント通知機構の拡張性及び保守性等が損なわれてしまう。イベント通知機構の拡張のための改変が、拡張アプリごとに必要とされるからである。
【０００６】
更に、自らの状態の変化に関して、拡張アプリ自身では通知できないイベントもある。例えば、拡張アプリが異常終了した場合、当該拡張アプリ自身は、そのイベントを通知することができない可能性がある。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、アプリケーションプログラムに関する状態の変化を適切に管理することのできる画像形成装置、管理方法、管理プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、画像形成装置は、インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する。
【０００９】
このような画像形成装置では、アプリケーションプログラムに関する状態の変化を適切に管理することができる。
【発明の効果】
【００１０】
本発明によれば、アプリケーションプログラムに関する状態の変化を適切に管理することができる。
【図面の簡単な説明】
【００１１】
【図１】第一の実施の形態の機器管理システムの構成例を示す図である。
【図２】本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。
【図３】第一の実施の形態における画像形成装置のソフトウェア構成例を示す図である。
【図４】第一の実施の形態における画像形成装置の機能構成例を示す図である。
【図５】第一の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図６】第一の実施の形態の生成ルール記憶部の構成例を示す図である。
【図７】第一の実施の形態の出力ルール記憶部の構成例を示す図である。
【図８】第二の実施の形態の機器管理システムの構成例を示す図である。
【図９】第二の実施の形態における画像形成装置の機能構成例を示す図である。
【図１０】第二の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図１１】第二の実施の形態の生成ルール記憶部の構成例を示す図である。
【図１２】第二の実施の形態の出力ルール記憶部の構成例を示す図である。
【図１３】第三の実施の形態の機器管理システムの構成例を示す図である。
【図１４】第三の実施の形態における画像形成装置の機能構成例を示す図である。
【図１５】第三の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図１６】第四の実施の形態におけるイベント出力部の機能構成例を示す図である。
【図１７】対応情報設定画面の表示例を示す図である。
【図１８】出力方法実装部の設定画面の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態の機器管理システムの構成例を示す図である。同図の機器管理システム１において、一以上の画像形成装置１０、イベント管理サーバ２０、及び管理者端末３０は、ＬＡＮ（Local Area Network）等のネットワーク５０（有線又は無線の別は問わない。）を介して通信可能に接続されている。
【００１３】
画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等のうちの二以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を単体で有する機器が画像形成装置１０として用いられてもよい。画像形成装置１０には、機能拡張等を目的としてプログラムのインストール又はアンインストール等が可能である。
【００１４】
イベント管理サーバ２０は、画像形成装置１０において発生する各種のイベントを示す情報（以下、「イベント情報」という。）の管理機能を有するコンピュータである。すなわち、本実施の形態において、イベント管理サーバ２０は、画像形成装置１０のイベント情報に関して既定の出力先（又は通知先）である。なお、イベントとは、例えば、画像形成装置１０の状態の変化をいう。画像形成装置１０の状態には、画像形成装置１０のハードウェア資源の状態の変化のみならず、ソフトウェアの状態の変化も含まれる。
【００１５】
管理者端末３０は、画像形成装置１０の管理者が利用するＰＣ等の情報処理装置である。本実施の形態において、管理者端末３０は、緊急性の高いイベント情報の出力先とされる。
【００１６】
図２は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。
【００１７】
コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。
【００１８】
スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。液晶パネルは、タッチパネル機能を有していてもよい。この場合、当該液晶パネルは、入力手段の機能をも兼ねる。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。
【００１９】
図３は、第一の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、一以上の拡張アプリ１２１、監視部１２２、及びイベント通知部１２３等を有する。
【００２０】
拡張アプリ１２１は、画像形成装置１０にインストールされるアプリケーションプログラムである。例えば、拡張アプリ１２１は、画像形成装置１０が有する所定のＡＰＩ（Application Program Interface）を利用して作成される。
【００２１】
監視部１２２は、画像形成装置１０の状態を監視する。例えば、監視部１２２は、各拡張アプリ１２１の状態を監視する。監視部１２２は、拡張アプリ１２１の状態の変化を示すイベント情報を生成し、該イベント情報をイベント通知部１２３に入力する。なお、各拡張アプリ１２１自身が通知可能なイベント情報に関しては、各拡張アプリ１２１よりイベント通知部１２３に入力される。
【００２２】
イベント通知部１２３は、入力されたイベント情報を、イベント出力先（又は通知先）に出力（又は通知）する。第一の実施の形態において、イベント出力先は、イベント管理サーバ２０又は管理者端末３０である。
【００２３】
なお、監視部１２２及びイベント通知部１２３は、画像形成装置１０にインストールされたプログラムがＣＰＵ１１１に実行させる処理によって実現される。
【００２４】
図４は、第一の実施の形態における画像形成装置の機能構成例を示す図である。同図において、監視部１２２は、拡張アプリ監視部１３１、イベント生成判定部１３２、及び生成ルール記憶部１３３等を含む。
【００２５】
拡張アプリ監視部１３１は、各拡張アプリ１２１の状態を監視する。監視対象とされる拡張アプリ１２１は、インストール情報記憶部１２４が記憶する情報に基づいて特定可能である。すなわち、拡張アプリ１２１がインストールされると、当該拡張アプリ１２１の属性情報がインストール情報記憶部１２４に記録される。また、拡張アプリ１２１がアンインストールされると、当該拡張アプリ１２１の属性情報がインストール情報記憶部１２４より削除される。したがって、インストール情報記憶部１２４は、画像形成装置１０にインストールされている拡張アプリ１２１の属性情報の一覧を記憶する。なお、インストール情報記憶部１２４は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００２６】
イベント生成判定部１３２は、拡張アプリ１２１の状態に変化が発生した場合に、当該変化に関するイベント情報の生成の要否等を、生成ルール記憶部１３３を用いて判定する。生成ルール記憶部１３３には、イベント情報の生成ルールを記憶する。イベント情報の生成ルールとは、どのような状態の変化が発生した場合に、どのようなイベント情報を生成すべきかを示す情報である。なお、生成ルール記憶部１３３は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００２７】
イベント通知部１２３は、イベント生成部１４１、イベント解析部１４２、出力方法判定部１４３、及びイベント出力部１４４等を有する。
【００２８】
イベント生成部１４１は、拡張アプリ１２１や拡張アプリ監視部１３１から指定された通りにイベント情報を生成する。イベント解析部１４２は、イベント生成部１４１によって生成されるイベント情報を解析する。出力方法判定部１４３は、イベント情報の出力方法（又は出力形態）を、出力ルール記憶部１４５を用いて判定する。出力ルール記憶部１４５は、出力ルールを記憶する。出力ルールとは、イベント情報の内容に応じて、イベント情報の出力方法（又は出力形態）を示す情報である。出力ルール記憶部１４５は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。イベント出力部１４４は、出力方法判定部１４３によって判定された出力方法（又は出力形態）によって、イベント情報を出力する。
【００２９】
以下、第一の実施の形態の画像形成装置１０が実行する処理手順について説明する。図５は、第一の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００３０】
拡張アプリ監視部１３１は、インストール情報記憶部１２４にその属性情報が記録されている各拡張アプリ１２１の状態を定期的に監視する（Ｓ１０１）。拡張アプリ監視部１３１は、例えば、或る拡張アプリ１２１が停止したことを検知すると（Ｓ１０２）、イベント情報の生成の要否の判定をイベント生成判定部１３２に要求する（Ｓ１０３）。この際、拡張アプリ監視部１３１は、拡張アプリ１２１に関してどのような状態の変化が発生したのかをイベント生成判定部１３２に通知する。ここでは、拡張アプリ１２１が停止したことが通知される。
【００３１】
イベント生成判定部１３２は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部１３１に出力する（Ｓ１０４）。
【００３２】
図６は、第一の実施の形態の生成ルール記憶部の構成例を示す図である。同図は、生成ルール１及び生成ルール２の二つの生成ルールが記録された例を示す。
【００３３】
各生成ルールは、生成条件及び生成内容等を含む。生成条件とは、拡張アプリ１２１の状態に変化に対して、イベント情報を生成する条件である。生成条件は、イベント情報の通知条件であるともいえる。イベント情報を生成するか否かの判定は、イベント情報を通知するか否かの判定と等価であるといえるからである。生成内容は、生成条件に合致した状態の変化に応じて生成すべきイベント情報の内容である。なお、本実施の形態において、イベント情報は、ｉｄ、緊急度レベル、及びメッセージ等の情報を含む。ｉｄは、イベント情報の識別子である。緊急度レベルは、イベント情報が示す状態の変化の緊急度である。メッセージは、イベント情報が示す状態の変化を示す任意の文字列である。
【００３４】
なお、同図では、生成ルール１に関して、括弧書きで（拡張アプリ監視部）と記載され、生成ルール２に関して、括弧書きで（拡張アプリ）と記載されている。これは、生成ルール１は、拡張アプリ監視部１３１によって検知される状態の変化に関する生成ルールであり、生成ルール２は、各拡張アプリ１２１自身によって検知される状態の変換に関する生成ルールであることを示す。
【００３５】
ここでは、拡張アプリ監視部１３１によって拡張アプリ１２１の停止が検知された例を説明している。したがって、当該拡張アプリ１２１の状態の変化（すなわち、停止）は、生成ルール１の生成条件に合致する。そこで、イベント生成判定部１３２は、生成ルール１の生成内容を拡張アプリ監視部１３１に出力する。
【００３６】
続いて、拡張アプリ監視部１３１は、当該生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１０５）。イベント生成部１４１は、当該要求に応じ、ｉｄに各イベント情報に固有の番号が設定され、緊急度レベルに「高」が設定され、メッセージに停止理由が設定されたイベント情報を生成する。イベント生成部１４１は、生成されたイベント情報（以下、「対象イベント情報」という。）をイベント解析部１４２に出力する（Ｓ１０６）。なお、停止理由は、例えば、ステップＳ１０５の要求と共に、拡張アプリ監視部１３１よりイベント生成部１４１に対して通知されてもよい。
【００３７】
続いて、イベント解析部１４２は、対象イベント情報を解析し、対象イベント情報より、ｉｄ、緊急度レベル、及びメッセージのそれぞれの値を取得する。続いて、イベント解析部１４２は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部１４３に要求する（Ｓ１０７）。
【００３８】
続いて、出力方法判定部１４３は、指定されたｉｄ、緊急度レベル、又はメッセージの値と、出力ルール記憶部１４５が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。
【００３９】
図７は、第一の実施の形態の出力ルール記憶部の構成例を示す図である。同図は、出力ルール１及び出力ルール２の二つの出力ルールが記録された例を示す。
【００４０】
各出力ルールは、適用条件及び出力方法等を含む。適用条件は、当該出力ルールが適用される条件である。出力方法は、当該出力ルールが適用される場合の出力方法である。
【００４１】
対象イベント情報の緊急度レベルは、「高」である。したがって、ここでは、出力ルール１及び２の双方が適用される。そこで、出力方法判定部１４３は、「管理者にメール送信」と、「イベント管理サーバに転送」との二つの出力方法をイベント解析部１４２に出力する（Ｓ１０８）。なお、図７の出力ルール２の「緊急度レベル＝高／中／低」は、緊急度レベルが、「高」、「中」、又は「低」であることを示す。また、出力方法の値は、便宜上、人間が理解可能な言葉によって記されているが、各出力方法を示す識別子であってもよい。
【００４２】
続いて、イベント解析部１４２は、対象イベント情報と、出力方法判定部１４３による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部１４４に要求する（Ｓ１０９）。続いて、イベント出力部１４４は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部１４４は、対象イベント情報を、イベント管理サーバ２０に転送する（Ｓ１１０）。また、イベント出力部１４４は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する（Ｓ１１１）。なお、管理者のメールアドレスは、出力ルール１の出力方法のパラメータとして含まれていても良いし、イベント出力部１４４の設定情報として、例えば、ＨＤＤ１１４等に記録されていてもよい。
【００４３】
このように、本実施の形態によれば、停止（特に、異常系の停止）のような、拡張アプリ１２１自身では補足することができない状態の変化が生じた場合であっても、拡張アプリ監視部１３１によって、当該変化が検知される。したがって、拡張アプリ１２１では通知することのできないイベント情報を通知することができる。また、生成ルールによって、通知対象とする状態の変化を限定することができる。したがって、全ての変化についてイベント情報が通知されることによる煩雑さを回避することができる。また、出力ルールによって、イベント情報の出力先がイベント情報の内容に応じて振り分けられる。その結果、例えば、緊急性の高い状態の変化については、管理者に迅速に伝え、緊急性の低い状態の変化については、イベント管理サーバ２０に蓄積しておく等といった、柔軟なイベント情報の管理形態を実現することができる。なお、イベント管理サーバ２０に蓄積されたイベント情報の一覧は、例えば、Ｗｅｂページ等によって、任意のタイミングで閲覧可能としてもよい。
【００４４】
続くステップＳ１２１以降は、拡張アプリ１２１内において重大な（すなわち、緊急性の高い）内部エラーが発生した場合に実行される処理手順である。内部エラーが発生した場合、拡張アプリ１２１自身が、生成ルール記憶部１３３を参照してイベント情報の生成の要否を判定する。拡張アプリ監視部１３１からは、内部エラーを検知することはできないからである。内部エラーの発生は、図６の生成ルール２の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール２の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１２１）。この際、緊急度レベルは「高」に設定される。上記したように、ステップＳ１２１以降は、「重大な」内部エラーの発生に応じた処理だからである。
【００４５】
ステップＳ１２２〜Ｓ１２７は、上記したステップＳ１０６〜Ｓ１１１と同様の処理手順が実行される。すなわち、Ｓ１２２〜Ｓ１２７において処理対象とされるイベント情報の緊急度レベルは、Ｓ１０６〜Ｓ１１１において処理対象とされたイベント情報の緊急度レベルと同じ「高」である。また、図７より明らかなように、本実施の形態の各出力ルールには、緊急度レベルに関して適用条件が設定されている。したがって、拡張アプリ１２１の重大な内部エラーを通知するイベント情報は、イベント管理サーバ２０に転送され（Ｓ１２６）、また、管理者のメールアドレス宛に電子メールによって送信される（Ｓ１２７）。
【００４６】
続くステップＳ１３１以降は、拡張アプリ１２１内において軽微な（すなわち、緊急性の低い）内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図６の生成ルール２の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール２の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１３１）。この際、緊急度レベルは「中」又は「低」に設定される。上記したように、ステップＳ１３１以降は、「軽微な」内部エラーの発生に応じた処理だからである。
【００４７】
ステップＳ１３２〜Ｓ１３６は、基本的に、上記したステップＳ１０６〜Ｓ１１１と同様の処理手順が実行される。但し、軽微な内部エラーに応じたイベント情報の緊急度レベルは「中」又は「低」である。したがって、当該イベント情報には、出力ルール２のみが適用される。その結果、当該イベント情報は、イベント管理サーバ２０に転送されるが（Ｓ１３６）、管理者のメールアドレス宛には送信されない。
【００４８】
このように、拡張アプリ１２１によって内部的に検知される状態の変化に関しても、拡張アプリ監視部１３１によって検知される状態の変化と同様の仕組みによってイベント情報の生成及び出力が行われる。したがって、拡張アプリ１２１ごとに当該仕組みを実装する必要はない。
【００４９】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【００５０】
図８は、第二の実施の形態の機器管理システムの構成例を示す図である。図８中、図１と同一部分には同一符号を付し、その説明は省略する。
【００５１】
図８に示される機器管理システム２では、イベント管理サーバ２０ａ及び２０ｂがネットワーク５０に接続されている。イベント管理サーバ２０ａは、拡張アプリ１２１のエラー又は異常等に関するイベント情報を管理するコンピュータである。エラーには、拡張アプリ１２１の停止や拡張アプリ１２１の不正な動作等が含まれる。一方、イベント管理サーバ２０ｂは、エラー以外の状態の変化に関するイベント情報を管理するコンピュータである。
【００５２】
図９は、第二の実施の形態における画像形成装置の機能構成例を示す図である。図９中、図４と同一部分には同一符号を付し、その説明は省略する。
【００５３】
図９において、拡張アプリ監視部１３１は、拡張アプリ設定監視部１５１及び機器設定監視部１５２等を含む。拡張アプリ設定監視部１５１は、各拡張アプリ１２１の設定情報を監視する。機器設定監視部１５２は、画像形成装置１０の設定情報を監視する。なお、拡張アプリ１２１の設定情報及び画像形成装置１０の設定情報は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等に記録されている。また、画像形成装置１０の設定情報とは、複数の拡張アプリ１２１や拡張アプリ１２１以外の機能に対して影響する設定情報をいう。すなわち、画像形成装置１０の設定情報は、複数の機能によって共用される設定情報、又は複数の機能によって共用される機能に関する設定情報をいう。
【００５４】
以下、第二の実施の形態の画像形成装置１０が実行する処理手順について説明する。図１０は、第二の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００５５】
拡張アプリ設定監視部１５１は、インストール情報記憶部１２４にその属性情報が記録されている各拡張アプリ１２１の設定情報（以下「アプリ設定情報」という。）を取得する（Ｓ２０１、Ｓ２０２）。続いて、機器設定監視部１５２は、画像形成装置１０の設定情報（以下、「機器設定情報」という。）を取得する（Ｓ２０３、Ｓ２０４）。なお、ステップＳ２０１〜Ｓ２０４は、定期的に、又はいずれかの拡張アプリ１２１の設定情報若しくは画像形成装置１０の設定情報の更新に応じて実行される。
【００５６】
拡張アプリ監視部１３１は、取得された各アプリ設定情報と、機器設定情報とを比較又は照合し、両者の組み合わせに関して不整合の有無を判定する。どのような状態が不整合であるかは、外部ファイル等に設定されていてもよいし、拡張アプリ監視部１３１のロジック内に定義されていてもよい。
【００５７】
不整合が検出された場合、拡張アプリ監視部１３１は、イベント情報の生成の要否の判定をイベント生成判定部１３２に要求する（Ｓ２０５）。この際、拡張アプリ監視部１３１は、アプリ設定情報と機器設定情報との間に不整合が発生したことをイベント生成判定部１３２に通知する。イベント生成判定部１３２は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部１３１に出力する（Ｓ２０６）。
【００５８】
図１１は、第二の実施の形態の生成ルール記憶部の構成例を示す図である。同図において、生成ルール２は、アプリ設定情報と機器設定情報との組み合わせが不正であることが生成条件とされている。したがって、イベント生成判定部１３２は、生成ルール２の生成内容を拡張アプリ監視部１３１に出力する。
【００５９】
続いて、拡張アプリ監視部１３１は、当該生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２０７）。イベント生成部１４１は、当該要求に応じ、ｉｄに各イベント情報に固有の番号が設定され、種別に「エラー」が設定され、メッセージに不正な理由が設定されたイベント情報を生成する。また、イベント生成部１４１は、当該イベント情報に関して、出力方法に「メール送信」を設定し、出力先に管理者のメールアドレスを設定する。イベント生成部１４１は、生成されたイベント情報（以下、「対象イベント情報」という。）をイベント解析部１４２に出力する（Ｓ２０８）。なお、不正な理由は、例えば、ステップＳ２０７の要求と共に、拡張アプリ監視部１３１よりイベント生成部１４１に対して通知されてもよい。
【００６０】
続いて、イベント解析部１４２は、対象イベント情報を解析し、イベント情報より、ｉｄ、種別、メッセージ、出力方法、及び出力先のそれぞれの値を取得する。続いて、イベント解析部１４２は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部１４３に要求する（Ｓ２０９）。
【００６１】
続いて、出力方法判定部１４３は、指定されたｉｄ、種別、メッセージ、出力方法、又は出力先の値と、出力ルール記憶部１４５が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。
【００６２】
図１２は、第二の実施の形態の出力ルール記憶部の構成例を示す図である。同図において、出力ルール１の適用条件は、対象イベント情報の種別が、「エラー」であることである。したがって、対象イベント情報には出力ルール１が適用される。また、対象イベント情報の送信方法は「メール送信」である。したがって、対象イベント情報には出力ルール３も適用される。そこで、出力方法判定部１４３は、「エラーサーバに転送」と、「指定アドレスメール送信」との二つの出力方法をイベント解析部１４２に出力する（Ｓ２１０）。なお、「エラーサーバ」は、イベント管理サーバ２０ａを示す。
【００６３】
続いて、イベント解析部１４２は、対象イベント情報と、出力方法判定部１４３による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部１４４に要求する（Ｓ２１１）。続いて、イベント出力部１４４は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部１４４は、対象イベント情報を、イベント管理サーバ２０ａに転送する（Ｓ２１２）。また、イベント出力部１４４は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する（Ｓ２１３）。
【００６４】
続くステップＳ２２１以降は、拡張アプリ１２１内において内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図１１の生成ルール３の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール３の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２２１）。したがって、イベント生成部１４１は、ｉｄに各イベント情報に固有の番号が設定され、種別に「エラー」が設定され、メッセージにエラーの理由が設定されたイベント情報を生成する（Ｓ２２２）。
【００６５】
ステップＳ２２３〜Ｓ２２６は、基本的に、上記したステップＳ２１０〜Ｓ２１２と同様の処理手順が実行される。但し、当該イベント情報は、図１２の出力ルール１の適用条件のみに該当する。したがって、当該イベント情報は、イベント管理サーバ２０ａには転送されるが（Ｓ２２６）、管理者のメールアドレス宛には送信されない。
【００６６】
続くステップＳ２３１以降は、拡張アプリ１２１の処理の実行に応じて実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。処理の実行は、図１１の生成ルール４の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール３の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２３１）。したがって、イベント生成部１４１は、ｉｄに各イベント情報に固有の番号が設定され、種別に「ログ」が設定され、メッセージに処理内容が設定されたイベント情報を生成する（Ｓ２３２）。
【００６７】
以降ステップＳ２３３〜Ｓ２３６は、基本的に、上記したステップＳ２２３〜Ｓ２２６と同様の処理手順が実行される。但し、当該イベント情報は、図１２の出力ルール２の適用条件に該当する。したがって、当該イベント情報は、イベント管理サーバ２０ｂに転送される（Ｓ２３６）。
【００６８】
このように、生成ルール及び出力ルールの設定内容に応じて、エラーを示すイベント情報と、単なるログであるイベント情報との転送先を区別することができる。
【００６９】
次に、第三の実施の形態について説明する。第三の実施の形態では、第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一又は第二の実施の形態と同様でよい。
【００７０】
図１３は、第三の実施の形態の機器管理システムの構成例を示す図である。図１３中、図１と同一部分には同一符号を付し、その説明は省略する。
【００７１】
図１３に示される機器管理システム３は、イベント管理サーバ２０を含まない。但し、このことは、イベント管理サーバ２０が含まれる形態と、第三の実施の形態とが排他的な関係にあることを示すものではない。イベント管理サーバ２０が、ネットワーク５０に接続されていてもよい。
【００７２】
図１４は、第三の実施の形態における画像形成装置の機能構成例を示す図である。図１４中、図４と同一部分には同一符号を付し、その説明は省略する。
【００７３】
図１４において、画像形成装置１０は、イベント保持部１２５を有する。イベント保持部１２５は、例えば、ＨＤＤ１１４等を用いてイベント情報を一時的に保持する。すなわち、第三の実施の形態では、イベント生成部１４１によって生成されたイベント情報は、必ずしも直ちに出力先に出力されず、一時的にイベント保持部１２５に保持されうる。
【００７４】
以下、第三の実施の形態の画像形成装置１０が実行する処理手順について説明する。図１５は、第三の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００７５】
同図では、イベント生成部１４１によって生成されたイベント情報がイベント解析部１４２に入力され、当該イベント情報に対する出力方法が判定された以降の処理手順が示されている。したがって、同図に示されている処理手順以前の処理手順は、第一又は第二の実施の形態において説明した処理手順（例えば、図５のステップＳ１０１〜Ｓ１０８等）同様でよい。
【００７６】
イベント解析部１４２は、イベント生成部１４１によって生成されたイベント情報及びその出力方法を指定して、当該イベント情報の出力をイベント出力部１４４に要求する（Ｓ３０１）。イベント出力部１４４は、指定された出力方法に拘わらず、当該イベント情報及び当該出力方法の保持をイベント保持部１２５に要求する（Ｓ３０２）。イベント保持部１２５は、当該イベント情報を、例えばＨＤＤ１１４に記録しておく。但し、イベント出力部１４４は、緊急度レベルが「高」であるイベント情報、又は種別が「エラー」であるイベント情報等、緊急性が高いイベント情報に関しては、出力方法にしたがって、即時的に出力先への出力処理を実行してもよい。
【００７７】
なお、ステップＳ３０１及びＳ３０２は、イベント情報が生成されるたびに実行される。一方、ステップＳ３０３以降は、定期的に実行される。したがって、定期的な周期において生成されたイベント情報が、イベント保持部１２５によって保持される。
【００７８】
ステップＳ３０３において、イベント解析部１４２は、保持されている（未だ出力されていない）イベント情報の件数の取得を出力方法判定部１４３に要求する。出力方法判定部１４３は、当該件数をイベント保持部１２５に問い合わせる（Ｓ３０４）。イベント保持部１２５は、当該問い合わせに応じ、現在保持されているイベント情報の件数を応答する（Ｓ３０５）。出力方法判定部１４３は、当該件数をイベント解析部１４２に応答する（Ｓ３０６）。
【００７９】
当該件数が所定数（例えば、１０件等）に到達した場合、イベント解析部１４２は、イベント保持部１２５によって保持されている各イベント情報及びその出力方法を取得する（Ｓ３０７、Ｓ３０８）。続いて、イベント解析部１４２は、当該各イベント情報及びその出力方法を指定して、当該各イベント情報の出力をイベント出力部１４４に要求する（Ｓ３０９）。なお、ここで、ステップＳ３０２以降が繰り返されないように、ステップＳ３０９の要求とステップＳ３０１の要求とは、イベント出力部１４４によって識別可能となるようにするとよい。例えば、ステップＳ３０９とＳ３０１とにおいて、イベント出力部１４４に対して呼び出されるメソッドが異なっていてもよいし、メソッドに対する引数が異なっていてもよい。
【００８０】
続いて、イベント出力部１４４は、当該各イベント情報を、指定された出力方法によって出力する（Ｓ３１０）。例えば、イベント出力部１４４は、当該イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する。
【００８１】
続いて、イベント解析部１４２は、ステップＳ３０８において取得された各イベント情報の削除をイベント保持部１２５に要求する（Ｓ３１１）。その結果、当該各イベント情報は、重複して出力されないように保持対象から除外される。
【００８２】
上述したように、第三の実施の形態によれば、イベント情報は一時的に画像形成装置１０内において保持され、定期的に出力される。したがって、例えば、機器管理システム３のように、イベント情報の出力先が管理者端末３０に限定されている場合、管理者端末３０に頻繁にイベント情報が通知されることによる煩雑さを低減させることができる。
【００８３】
次に、第四の実施の形態について説明する。第四の実施の形態では、イベント出力部１４４の拡張性に関して説明する。なお、第四の実施の形態は、上記各実施の形態と組み合わせて実施される。
【００８４】
上記各実施の形態では、出力ルールの定義に応じて、各種のイベント情報の出力先を変化させることができる。但し、出力ルールに定義可能な出力方法は、イベント出力部１４４の実装の範囲内に限定される。このことは、翻せば、イベント出力部１４４が対応可能な出力方法を容易に拡張可能とすることができれば、出力ルールに定義可能な出力方法の種類も容易に増加させることができることを意味する。
【００８５】
そこで、第四の実施の形態において、イベント出力部１４４は、図１６に示されるような構成を有する。
【００８６】
図１６は、第四の実施の形態におけるイベント出力部の機能構成例を示す図である。同図において、イベント出力部１４４は、インタフェース部１６１、一以上の出力方法実装部１６２、及び対応情報記憶部１６３等を含む。
【００８７】
各出力方法実装部１６２は、それぞれ一つ出力方法に対応した実装である。例えば、或る出力方法実装部１６２は、管理者のメールアドレス宛の電子メールによるイベント情報の送信を行う。別の出力方法実装部１６２は、イベント管理サーバ２０へのイベント情報の転送を行う。
【００８８】
インタフェース部１６１は、イベント解析部１４２等とのインタフェースを担う部分である。すなわち、インタフェース部１６１は、イベント解析部１４２より、イベント情報及びその出力方法が指定されたイベント情報の出力要求を受け付ける。インタフェース部１６１は、指定された出力方法に対応する出力方法実装部１６２に、当該イベント情報の出力を実行させる。
【００８９】
対応情報記憶部１６３は、出力方法と出力方法実装部１６２との対応情報を記憶する。すなわち、インタフェース部１６１は、対応情報記憶部１６３を参照して、出力方法に応じた出力方法実装部１６２を特定する。なお、対応情報記憶部１６３は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００９０】
図１６に示されるような構成において、出力方法実装部１６２を動的にリンク可能なプログラムモジュールとすれば、新たな出力方法の追加を容易とすることができる。すなわち、新たな出力方法に応じた出力方法実装部１６２を実装し、当該出力方法実装部１６２に関する対応情報を対応情報記憶部１６３に登録すれば、基本的に、既存部分の改変を行うことなく新たな出力方法を有効とすることができる。
【００９１】
対応情報記憶部１６３に対する設定は、例えば、インタフェース部１６１が操作パネル１５又は監理者端末３０等に表示させる対応情報設定画面を介して行われればよい。
【００９２】
図１７は、対応情報設定画面の表示例を示す図である。同図において、対応情報設定画面５１０は、対応情報一覧５１１、編集ボタン５１２，削除ボタン５１３、出力方法入力領域５１４、説明入力領域５１５、実装名入力領域５１６、及び追加ボタン５１７等を有する。
【００９３】
対応情報一覧５１１は、対応情報記憶部１６３に記憶されている対応情報の一覧を表示する。各対応情報は、出力方法、説明、及び実装名等の項目を有する。出力方法は、出力方法を識別するための文字列である。すなわち、当該文字列が、出力ルール記憶部１４５の出力方法に設定される。同図の内容は、図１２の出力ルール記憶部１４５に対応している。説明は、出力方法の内容を説明する文字列である。実装名は、当該出力方法に対応する出力方法実装部１６２のプログラムモジュール名である。
【００９４】
対応情報一覧５１１において、いずれかの対応情報のチェックボタン５１１ｂがチェックされ、削除ボタン５１３が押下されると、当該対応情報が対応情報記憶部１６３より削除される。また、編集ボタン５１２が押下されると、当該対応情報の出力方法、説明、及び実装名が、出力方法入力領域５１４、説明入力領域５１５、又は実装名入力領域５１６に表示され、編集可能な状態となる。編集後、追加ボタン５１７が押下されると、編集後の対応情報が対応情報記憶部１６３に追加される。例えば、出力方法実装部１６２をバージョンアップした場合、バージョンアップ後のモジュール名によって実装名を更新することで、バージョンアップ後の出力方法実装部１６２を有効とすることができる。
【００９５】
また、出力方法入力領域５１４、説明入力領域５１５、及び実装名入力領域５１６が空の状態において、各領域に値が入力され、追加ボタン５１７が押下されると、新たな対応情報が対応情報記憶部１６３に記録される。
【００９６】
各出力方法実装部１６２に固有の設定情報の設定については、各出力方法実装部１６２が、操作パネル１５又は監理者端末３０等に表示させる設定画面を介して行われればよい。
【００９７】
図１８は、出力方法実装部の設定画面の一例を示す図である。同図の設定画面５２０は、出力方法表示領域５２１、説明表示領域５２２、及び実装名表示領域５２３、更新ボタン５２４、管理者アドレス入力領域５２５、及びＯＫボタン５２６等を有する。
【００９８】
出力方法表示領域５２１、説明表示領域５２２、及び実装名表示領域５２３には、現在設定対象とされている出力方法実装部１６２の出力方法、説明、又は実装名が表示される。
【００９９】
管理者アドレス入力領域５２４は、管理者のメールアドレスを入力させるための領域である。すなわち、図１８の設定画面５２０は、管理者に対してメール送信を行う出力方法実装部１６２に関する設定画面の例である。したがって、他の出力方法に関する出力方法実装部１６２については、当該他の出力方法実装部１６２に固有の設定情報に関する入力領域が表示される。ＯＫボタン５２６が押下されると、管理者アドレス入力領域５２４に入力されたメールアドレスが、当該出力方法実装部１６２に設定される。
【０１００】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１０１】
１、２、３ 機器管理システム
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０、２０ａ、２０ｂ イベント管理サーバ
３０ 管理者端末
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２１ 拡張アプリ
１２２ 監視部
１２３ イベント通知部
１２４ インストール情報記憶部
１２５ イベント保持部
１３１ 拡張アプリ監視部
１３２ イベント生成判定部
１３３ 生成ルール記憶部
１４１ イベント生成部
１４２ イベント解析部
１４３ 出力方法判定部
１４４ イベント出力部
１５１ 拡張アプリ設定監視部
１５２ 機器設定監視部
１６１ インタフェース部
１６２ 出力方法実装部
１６３ 対応情報記憶部
【先行技術文献】
【特許文献】
【０１０２】
【特許文献１】特開２００５‐２６９６１９号広報
【特許文献２】特開２００４‐１８７００８号広報
【技術分野】
【０００１】
本発明は、画像形成装置、管理方法、管理プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
近年、公開されたＡＰＩ（Application Program Interface）を利用して、その出荷後に新たなアプリケーションプログラムの開発及びインストールが可能とされている画像形成装置が一般化している。 斯かるＡＰＩを利用して開発されたアプリケーションプログラム（以下、「拡張アプリ」という。）によれば複雑なワークフローの実現等が可能となり、ユーザの業務効率の向上等を図ることができる（例えば、特許文献１）。
【０００３】
他方において、画像形成装置は、一般的に、要求されたジョブの開始若しくは終了、又は画像形成装置における異常の発生や消耗品の残量の低下等をユーザに通知するためのイベント通知機構を有する（例えば、特許文献２）。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような拡張アプリの状態の変化に関しても、画像形成装置の既存の機能に関するイベントと同様に通知対象とすることができれば、ユーザにとって便利である。この際、拡張アプリごとに、イベント通知機構が実装されたのでは、限られた機器のリソースを非効率に消費することになる。
【０００５】
また、拡張アプリごとに、イベント通知機構が実装されたのでは、イベント通知機構の拡張性及び保守性等が損なわれてしまう。イベント通知機構の拡張のための改変が、拡張アプリごとに必要とされるからである。
【０００６】
更に、自らの状態の変化に関して、拡張アプリ自身では通知できないイベントもある。例えば、拡張アプリが異常終了した場合、当該拡張アプリ自身は、そのイベントを通知することができない可能性がある。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、アプリケーションプログラムに関する状態の変化を適切に管理することのできる画像形成装置、管理方法、管理プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、画像形成装置は、インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、前記イベント情報を出力する出力手段とを有する。
【０００９】
このような画像形成装置では、アプリケーションプログラムに関する状態の変化を適切に管理することができる。
【発明の効果】
【００１０】
本発明によれば、アプリケーションプログラムに関する状態の変化を適切に管理することができる。
【図面の簡単な説明】
【００１１】
【図１】第一の実施の形態の機器管理システムの構成例を示す図である。
【図２】本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。
【図３】第一の実施の形態における画像形成装置のソフトウェア構成例を示す図である。
【図４】第一の実施の形態における画像形成装置の機能構成例を示す図である。
【図５】第一の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図６】第一の実施の形態の生成ルール記憶部の構成例を示す図である。
【図７】第一の実施の形態の出力ルール記憶部の構成例を示す図である。
【図８】第二の実施の形態の機器管理システムの構成例を示す図である。
【図９】第二の実施の形態における画像形成装置の機能構成例を示す図である。
【図１０】第二の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図１１】第二の実施の形態の生成ルール記憶部の構成例を示す図である。
【図１２】第二の実施の形態の出力ルール記憶部の構成例を示す図である。
【図１３】第三の実施の形態の機器管理システムの構成例を示す図である。
【図１４】第三の実施の形態における画像形成装置の機能構成例を示す図である。
【図１５】第三の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【図１６】第四の実施の形態におけるイベント出力部の機能構成例を示す図である。
【図１７】対応情報設定画面の表示例を示す図である。
【図１８】出力方法実装部の設定画面の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態の機器管理システムの構成例を示す図である。同図の機器管理システム１において、一以上の画像形成装置１０、イベント管理サーバ２０、及び管理者端末３０は、ＬＡＮ（Local Area Network）等のネットワーク５０（有線又は無線の別は問わない。）を介して通信可能に接続されている。
【００１３】
画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等のうちの二以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を単体で有する機器が画像形成装置１０として用いられてもよい。画像形成装置１０には、機能拡張等を目的としてプログラムのインストール又はアンインストール等が可能である。
【００１４】
イベント管理サーバ２０は、画像形成装置１０において発生する各種のイベントを示す情報（以下、「イベント情報」という。）の管理機能を有するコンピュータである。すなわち、本実施の形態において、イベント管理サーバ２０は、画像形成装置１０のイベント情報に関して既定の出力先（又は通知先）である。なお、イベントとは、例えば、画像形成装置１０の状態の変化をいう。画像形成装置１０の状態には、画像形成装置１０のハードウェア資源の状態の変化のみならず、ソフトウェアの状態の変化も含まれる。
【００１５】
管理者端末３０は、画像形成装置１０の管理者が利用するＰＣ等の情報処理装置である。本実施の形態において、管理者端末３０は、緊急性の高いイベント情報の出力先とされる。
【００１６】
図２は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。
【００１７】
コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。
【００１８】
スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。液晶パネルは、タッチパネル機能を有していてもよい。この場合、当該液晶パネルは、入力手段の機能をも兼ねる。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。
【００１９】
図３は、第一の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、一以上の拡張アプリ１２１、監視部１２２、及びイベント通知部１２３等を有する。
【００２０】
拡張アプリ１２１は、画像形成装置１０にインストールされるアプリケーションプログラムである。例えば、拡張アプリ１２１は、画像形成装置１０が有する所定のＡＰＩ（Application Program Interface）を利用して作成される。
【００２１】
監視部１２２は、画像形成装置１０の状態を監視する。例えば、監視部１２２は、各拡張アプリ１２１の状態を監視する。監視部１２２は、拡張アプリ１２１の状態の変化を示すイベント情報を生成し、該イベント情報をイベント通知部１２３に入力する。なお、各拡張アプリ１２１自身が通知可能なイベント情報に関しては、各拡張アプリ１２１よりイベント通知部１２３に入力される。
【００２２】
イベント通知部１２３は、入力されたイベント情報を、イベント出力先（又は通知先）に出力（又は通知）する。第一の実施の形態において、イベント出力先は、イベント管理サーバ２０又は管理者端末３０である。
【００２３】
なお、監視部１２２及びイベント通知部１２３は、画像形成装置１０にインストールされたプログラムがＣＰＵ１１１に実行させる処理によって実現される。
【００２４】
図４は、第一の実施の形態における画像形成装置の機能構成例を示す図である。同図において、監視部１２２は、拡張アプリ監視部１３１、イベント生成判定部１３２、及び生成ルール記憶部１３３等を含む。
【００２５】
拡張アプリ監視部１３１は、各拡張アプリ１２１の状態を監視する。監視対象とされる拡張アプリ１２１は、インストール情報記憶部１２４が記憶する情報に基づいて特定可能である。すなわち、拡張アプリ１２１がインストールされると、当該拡張アプリ１２１の属性情報がインストール情報記憶部１２４に記録される。また、拡張アプリ１２１がアンインストールされると、当該拡張アプリ１２１の属性情報がインストール情報記憶部１２４より削除される。したがって、インストール情報記憶部１２４は、画像形成装置１０にインストールされている拡張アプリ１２１の属性情報の一覧を記憶する。なお、インストール情報記憶部１２４は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００２６】
イベント生成判定部１３２は、拡張アプリ１２１の状態に変化が発生した場合に、当該変化に関するイベント情報の生成の要否等を、生成ルール記憶部１３３を用いて判定する。生成ルール記憶部１３３には、イベント情報の生成ルールを記憶する。イベント情報の生成ルールとは、どのような状態の変化が発生した場合に、どのようなイベント情報を生成すべきかを示す情報である。なお、生成ルール記憶部１３３は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００２７】
イベント通知部１２３は、イベント生成部１４１、イベント解析部１４２、出力方法判定部１４３、及びイベント出力部１４４等を有する。
【００２８】
イベント生成部１４１は、拡張アプリ１２１や拡張アプリ監視部１３１から指定された通りにイベント情報を生成する。イベント解析部１４２は、イベント生成部１４１によって生成されるイベント情報を解析する。出力方法判定部１４３は、イベント情報の出力方法（又は出力形態）を、出力ルール記憶部１４５を用いて判定する。出力ルール記憶部１４５は、出力ルールを記憶する。出力ルールとは、イベント情報の内容に応じて、イベント情報の出力方法（又は出力形態）を示す情報である。出力ルール記憶部１４５は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。イベント出力部１４４は、出力方法判定部１４３によって判定された出力方法（又は出力形態）によって、イベント情報を出力する。
【００２９】
以下、第一の実施の形態の画像形成装置１０が実行する処理手順について説明する。図５は、第一の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００３０】
拡張アプリ監視部１３１は、インストール情報記憶部１２４にその属性情報が記録されている各拡張アプリ１２１の状態を定期的に監視する（Ｓ１０１）。拡張アプリ監視部１３１は、例えば、或る拡張アプリ１２１が停止したことを検知すると（Ｓ１０２）、イベント情報の生成の要否の判定をイベント生成判定部１３２に要求する（Ｓ１０３）。この際、拡張アプリ監視部１３１は、拡張アプリ１２１に関してどのような状態の変化が発生したのかをイベント生成判定部１３２に通知する。ここでは、拡張アプリ１２１が停止したことが通知される。
【００３１】
イベント生成判定部１３２は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部１３１に出力する（Ｓ１０４）。
【００３２】
図６は、第一の実施の形態の生成ルール記憶部の構成例を示す図である。同図は、生成ルール１及び生成ルール２の二つの生成ルールが記録された例を示す。
【００３３】
各生成ルールは、生成条件及び生成内容等を含む。生成条件とは、拡張アプリ１２１の状態に変化に対して、イベント情報を生成する条件である。生成条件は、イベント情報の通知条件であるともいえる。イベント情報を生成するか否かの判定は、イベント情報を通知するか否かの判定と等価であるといえるからである。生成内容は、生成条件に合致した状態の変化に応じて生成すべきイベント情報の内容である。なお、本実施の形態において、イベント情報は、ｉｄ、緊急度レベル、及びメッセージ等の情報を含む。ｉｄは、イベント情報の識別子である。緊急度レベルは、イベント情報が示す状態の変化の緊急度である。メッセージは、イベント情報が示す状態の変化を示す任意の文字列である。
【００３４】
なお、同図では、生成ルール１に関して、括弧書きで（拡張アプリ監視部）と記載され、生成ルール２に関して、括弧書きで（拡張アプリ）と記載されている。これは、生成ルール１は、拡張アプリ監視部１３１によって検知される状態の変化に関する生成ルールであり、生成ルール２は、各拡張アプリ１２１自身によって検知される状態の変換に関する生成ルールであることを示す。
【００３５】
ここでは、拡張アプリ監視部１３１によって拡張アプリ１２１の停止が検知された例を説明している。したがって、当該拡張アプリ１２１の状態の変化（すなわち、停止）は、生成ルール１の生成条件に合致する。そこで、イベント生成判定部１３２は、生成ルール１の生成内容を拡張アプリ監視部１３１に出力する。
【００３６】
続いて、拡張アプリ監視部１３１は、当該生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１０５）。イベント生成部１４１は、当該要求に応じ、ｉｄに各イベント情報に固有の番号が設定され、緊急度レベルに「高」が設定され、メッセージに停止理由が設定されたイベント情報を生成する。イベント生成部１４１は、生成されたイベント情報（以下、「対象イベント情報」という。）をイベント解析部１４２に出力する（Ｓ１０６）。なお、停止理由は、例えば、ステップＳ１０５の要求と共に、拡張アプリ監視部１３１よりイベント生成部１４１に対して通知されてもよい。
【００３７】
続いて、イベント解析部１４２は、対象イベント情報を解析し、対象イベント情報より、ｉｄ、緊急度レベル、及びメッセージのそれぞれの値を取得する。続いて、イベント解析部１４２は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部１４３に要求する（Ｓ１０７）。
【００３８】
続いて、出力方法判定部１４３は、指定されたｉｄ、緊急度レベル、又はメッセージの値と、出力ルール記憶部１４５が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。
【００３９】
図７は、第一の実施の形態の出力ルール記憶部の構成例を示す図である。同図は、出力ルール１及び出力ルール２の二つの出力ルールが記録された例を示す。
【００４０】
各出力ルールは、適用条件及び出力方法等を含む。適用条件は、当該出力ルールが適用される条件である。出力方法は、当該出力ルールが適用される場合の出力方法である。
【００４１】
対象イベント情報の緊急度レベルは、「高」である。したがって、ここでは、出力ルール１及び２の双方が適用される。そこで、出力方法判定部１４３は、「管理者にメール送信」と、「イベント管理サーバに転送」との二つの出力方法をイベント解析部１４２に出力する（Ｓ１０８）。なお、図７の出力ルール２の「緊急度レベル＝高／中／低」は、緊急度レベルが、「高」、「中」、又は「低」であることを示す。また、出力方法の値は、便宜上、人間が理解可能な言葉によって記されているが、各出力方法を示す識別子であってもよい。
【００４２】
続いて、イベント解析部１４２は、対象イベント情報と、出力方法判定部１４３による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部１４４に要求する（Ｓ１０９）。続いて、イベント出力部１４４は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部１４４は、対象イベント情報を、イベント管理サーバ２０に転送する（Ｓ１１０）。また、イベント出力部１４４は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する（Ｓ１１１）。なお、管理者のメールアドレスは、出力ルール１の出力方法のパラメータとして含まれていても良いし、イベント出力部１４４の設定情報として、例えば、ＨＤＤ１１４等に記録されていてもよい。
【００４３】
このように、本実施の形態によれば、停止（特に、異常系の停止）のような、拡張アプリ１２１自身では補足することができない状態の変化が生じた場合であっても、拡張アプリ監視部１３１によって、当該変化が検知される。したがって、拡張アプリ１２１では通知することのできないイベント情報を通知することができる。また、生成ルールによって、通知対象とする状態の変化を限定することができる。したがって、全ての変化についてイベント情報が通知されることによる煩雑さを回避することができる。また、出力ルールによって、イベント情報の出力先がイベント情報の内容に応じて振り分けられる。その結果、例えば、緊急性の高い状態の変化については、管理者に迅速に伝え、緊急性の低い状態の変化については、イベント管理サーバ２０に蓄積しておく等といった、柔軟なイベント情報の管理形態を実現することができる。なお、イベント管理サーバ２０に蓄積されたイベント情報の一覧は、例えば、Ｗｅｂページ等によって、任意のタイミングで閲覧可能としてもよい。
【００４４】
続くステップＳ１２１以降は、拡張アプリ１２１内において重大な（すなわち、緊急性の高い）内部エラーが発生した場合に実行される処理手順である。内部エラーが発生した場合、拡張アプリ１２１自身が、生成ルール記憶部１３３を参照してイベント情報の生成の要否を判定する。拡張アプリ監視部１３１からは、内部エラーを検知することはできないからである。内部エラーの発生は、図６の生成ルール２の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール２の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１２１）。この際、緊急度レベルは「高」に設定される。上記したように、ステップＳ１２１以降は、「重大な」内部エラーの発生に応じた処理だからである。
【００４５】
ステップＳ１２２〜Ｓ１２７は、上記したステップＳ１０６〜Ｓ１１１と同様の処理手順が実行される。すなわち、Ｓ１２２〜Ｓ１２７において処理対象とされるイベント情報の緊急度レベルは、Ｓ１０６〜Ｓ１１１において処理対象とされたイベント情報の緊急度レベルと同じ「高」である。また、図７より明らかなように、本実施の形態の各出力ルールには、緊急度レベルに関して適用条件が設定されている。したがって、拡張アプリ１２１の重大な内部エラーを通知するイベント情報は、イベント管理サーバ２０に転送され（Ｓ１２６）、また、管理者のメールアドレス宛に電子メールによって送信される（Ｓ１２７）。
【００４６】
続くステップＳ１３１以降は、拡張アプリ１２１内において軽微な（すなわち、緊急性の低い）内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図６の生成ルール２の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール２の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ１３１）。この際、緊急度レベルは「中」又は「低」に設定される。上記したように、ステップＳ１３１以降は、「軽微な」内部エラーの発生に応じた処理だからである。
【００４７】
ステップＳ１３２〜Ｓ１３６は、基本的に、上記したステップＳ１０６〜Ｓ１１１と同様の処理手順が実行される。但し、軽微な内部エラーに応じたイベント情報の緊急度レベルは「中」又は「低」である。したがって、当該イベント情報には、出力ルール２のみが適用される。その結果、当該イベント情報は、イベント管理サーバ２０に転送されるが（Ｓ１３６）、管理者のメールアドレス宛には送信されない。
【００４８】
このように、拡張アプリ１２１によって内部的に検知される状態の変化に関しても、拡張アプリ監視部１３１によって検知される状態の変化と同様の仕組みによってイベント情報の生成及び出力が行われる。したがって、拡張アプリ１２１ごとに当該仕組みを実装する必要はない。
【００４９】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【００５０】
図８は、第二の実施の形態の機器管理システムの構成例を示す図である。図８中、図１と同一部分には同一符号を付し、その説明は省略する。
【００５１】
図８に示される機器管理システム２では、イベント管理サーバ２０ａ及び２０ｂがネットワーク５０に接続されている。イベント管理サーバ２０ａは、拡張アプリ１２１のエラー又は異常等に関するイベント情報を管理するコンピュータである。エラーには、拡張アプリ１２１の停止や拡張アプリ１２１の不正な動作等が含まれる。一方、イベント管理サーバ２０ｂは、エラー以外の状態の変化に関するイベント情報を管理するコンピュータである。
【００５２】
図９は、第二の実施の形態における画像形成装置の機能構成例を示す図である。図９中、図４と同一部分には同一符号を付し、その説明は省略する。
【００５３】
図９において、拡張アプリ監視部１３１は、拡張アプリ設定監視部１５１及び機器設定監視部１５２等を含む。拡張アプリ設定監視部１５１は、各拡張アプリ１２１の設定情報を監視する。機器設定監視部１５２は、画像形成装置１０の設定情報を監視する。なお、拡張アプリ１２１の設定情報及び画像形成装置１０の設定情報は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等に記録されている。また、画像形成装置１０の設定情報とは、複数の拡張アプリ１２１や拡張アプリ１２１以外の機能に対して影響する設定情報をいう。すなわち、画像形成装置１０の設定情報は、複数の機能によって共用される設定情報、又は複数の機能によって共用される機能に関する設定情報をいう。
【００５４】
以下、第二の実施の形態の画像形成装置１０が実行する処理手順について説明する。図１０は、第二の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００５５】
拡張アプリ設定監視部１５１は、インストール情報記憶部１２４にその属性情報が記録されている各拡張アプリ１２１の設定情報（以下「アプリ設定情報」という。）を取得する（Ｓ２０１、Ｓ２０２）。続いて、機器設定監視部１５２は、画像形成装置１０の設定情報（以下、「機器設定情報」という。）を取得する（Ｓ２０３、Ｓ２０４）。なお、ステップＳ２０１〜Ｓ２０４は、定期的に、又はいずれかの拡張アプリ１２１の設定情報若しくは画像形成装置１０の設定情報の更新に応じて実行される。
【００５６】
拡張アプリ監視部１３１は、取得された各アプリ設定情報と、機器設定情報とを比較又は照合し、両者の組み合わせに関して不整合の有無を判定する。どのような状態が不整合であるかは、外部ファイル等に設定されていてもよいし、拡張アプリ監視部１３１のロジック内に定義されていてもよい。
【００５７】
不整合が検出された場合、拡張アプリ監視部１３１は、イベント情報の生成の要否の判定をイベント生成判定部１３２に要求する（Ｓ２０５）。この際、拡張アプリ監視部１３１は、アプリ設定情報と機器設定情報との間に不整合が発生したことをイベント生成判定部１３２に通知する。イベント生成判定部１３２は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否、及びどのような内容のイベント情報を生成すべきかを判定し、その判定結果を拡張アプリ監視部１３１に出力する（Ｓ２０６）。
【００５８】
図１１は、第二の実施の形態の生成ルール記憶部の構成例を示す図である。同図において、生成ルール２は、アプリ設定情報と機器設定情報との組み合わせが不正であることが生成条件とされている。したがって、イベント生成判定部１３２は、生成ルール２の生成内容を拡張アプリ監視部１３１に出力する。
【００５９】
続いて、拡張アプリ監視部１３１は、当該生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２０７）。イベント生成部１４１は、当該要求に応じ、ｉｄに各イベント情報に固有の番号が設定され、種別に「エラー」が設定され、メッセージに不正な理由が設定されたイベント情報を生成する。また、イベント生成部１４１は、当該イベント情報に関して、出力方法に「メール送信」を設定し、出力先に管理者のメールアドレスを設定する。イベント生成部１４１は、生成されたイベント情報（以下、「対象イベント情報」という。）をイベント解析部１４２に出力する（Ｓ２０８）。なお、不正な理由は、例えば、ステップＳ２０７の要求と共に、拡張アプリ監視部１３１よりイベント生成部１４１に対して通知されてもよい。
【００６０】
続いて、イベント解析部１４２は、対象イベント情報を解析し、イベント情報より、ｉｄ、種別、メッセージ、出力方法、及び出力先のそれぞれの値を取得する。続いて、イベント解析部１４２は、取得された各値を指定して、対象イベント情報の出力方法の判定を出力方法判定部１４３に要求する（Ｓ２０９）。
【００６１】
続いて、出力方法判定部１４３は、指定されたｉｄ、種別、メッセージ、出力方法、又は出力先の値と、出力ルール記憶部１４５が記憶する出力ルールとに基づいて、対象イベント情報の出力方法を判定する。
【００６２】
図１２は、第二の実施の形態の出力ルール記憶部の構成例を示す図である。同図において、出力ルール１の適用条件は、対象イベント情報の種別が、「エラー」であることである。したがって、対象イベント情報には出力ルール１が適用される。また、対象イベント情報の送信方法は「メール送信」である。したがって、対象イベント情報には出力ルール３も適用される。そこで、出力方法判定部１４３は、「エラーサーバに転送」と、「指定アドレスメール送信」との二つの出力方法をイベント解析部１４２に出力する（Ｓ２１０）。なお、「エラーサーバ」は、イベント管理サーバ２０ａを示す。
【００６３】
続いて、イベント解析部１４２は、対象イベント情報と、出力方法判定部１４３による判定結果である二つの出力方法とを指定して、対象イベント情報の出力をイベント出力部１４４に要求する（Ｓ２１１）。続いて、イベント出力部１４４は、対象イベント情報を、指定された出力方法によって出力する。すなわち、イベント出力部１４４は、対象イベント情報を、イベント管理サーバ２０ａに転送する（Ｓ２１２）。また、イベント出力部１４４は、対象イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する（Ｓ２１３）。
【００６４】
続くステップＳ２２１以降は、拡張アプリ１２１内において内部エラーが発生した場合に実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。内部エラーの発生は、図１１の生成ルール３の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール３の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２２１）。したがって、イベント生成部１４１は、ｉｄに各イベント情報に固有の番号が設定され、種別に「エラー」が設定され、メッセージにエラーの理由が設定されたイベント情報を生成する（Ｓ２２２）。
【００６５】
ステップＳ２２３〜Ｓ２２６は、基本的に、上記したステップＳ２１０〜Ｓ２１２と同様の処理手順が実行される。但し、当該イベント情報は、図１２の出力ルール１の適用条件のみに該当する。したがって、当該イベント情報は、イベント管理サーバ２０ａには転送されるが（Ｓ２２６）、管理者のメールアドレス宛には送信されない。
【００６６】
続くステップＳ２３１以降は、拡張アプリ１２１の処理の実行に応じて実行される処理手順である。この場合、拡張アプリ１２１は、生成ルール記憶部１３３を参照して、イベント情報の生成の要否を判定する。処理の実行は、図１１の生成ルール４の生成条件に該当する。そこで、拡張アプリ１２１は、生成ルール３の生成内容を指定して、イベント情報の生成をイベント生成部１４１に要求する（Ｓ２３１）。したがって、イベント生成部１４１は、ｉｄに各イベント情報に固有の番号が設定され、種別に「ログ」が設定され、メッセージに処理内容が設定されたイベント情報を生成する（Ｓ２３２）。
【００６７】
以降ステップＳ２３３〜Ｓ２３６は、基本的に、上記したステップＳ２２３〜Ｓ２２６と同様の処理手順が実行される。但し、当該イベント情報は、図１２の出力ルール２の適用条件に該当する。したがって、当該イベント情報は、イベント管理サーバ２０ｂに転送される（Ｓ２３６）。
【００６８】
このように、生成ルール及び出力ルールの設定内容に応じて、エラーを示すイベント情報と、単なるログであるイベント情報との転送先を区別することができる。
【００６９】
次に、第三の実施の形態について説明する。第三の実施の形態では、第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一又は第二の実施の形態と同様でよい。
【００７０】
図１３は、第三の実施の形態の機器管理システムの構成例を示す図である。図１３中、図１と同一部分には同一符号を付し、その説明は省略する。
【００７１】
図１３に示される機器管理システム３は、イベント管理サーバ２０を含まない。但し、このことは、イベント管理サーバ２０が含まれる形態と、第三の実施の形態とが排他的な関係にあることを示すものではない。イベント管理サーバ２０が、ネットワーク５０に接続されていてもよい。
【００７２】
図１４は、第三の実施の形態における画像形成装置の機能構成例を示す図である。図１４中、図４と同一部分には同一符号を付し、その説明は省略する。
【００７３】
図１４において、画像形成装置１０は、イベント保持部１２５を有する。イベント保持部１２５は、例えば、ＨＤＤ１１４等を用いてイベント情報を一時的に保持する。すなわち、第三の実施の形態では、イベント生成部１４１によって生成されたイベント情報は、必ずしも直ちに出力先に出力されず、一時的にイベント保持部１２５に保持されうる。
【００７４】
以下、第三の実施の形態の画像形成装置１０が実行する処理手順について説明する。図１５は、第三の実施の形態の画像形成装置が実行する処理手順の一例を説明するためのシーケンス図である。
【００７５】
同図では、イベント生成部１４１によって生成されたイベント情報がイベント解析部１４２に入力され、当該イベント情報に対する出力方法が判定された以降の処理手順が示されている。したがって、同図に示されている処理手順以前の処理手順は、第一又は第二の実施の形態において説明した処理手順（例えば、図５のステップＳ１０１〜Ｓ１０８等）同様でよい。
【００７６】
イベント解析部１４２は、イベント生成部１４１によって生成されたイベント情報及びその出力方法を指定して、当該イベント情報の出力をイベント出力部１４４に要求する（Ｓ３０１）。イベント出力部１４４は、指定された出力方法に拘わらず、当該イベント情報及び当該出力方法の保持をイベント保持部１２５に要求する（Ｓ３０２）。イベント保持部１２５は、当該イベント情報を、例えばＨＤＤ１１４に記録しておく。但し、イベント出力部１４４は、緊急度レベルが「高」であるイベント情報、又は種別が「エラー」であるイベント情報等、緊急性が高いイベント情報に関しては、出力方法にしたがって、即時的に出力先への出力処理を実行してもよい。
【００７７】
なお、ステップＳ３０１及びＳ３０２は、イベント情報が生成されるたびに実行される。一方、ステップＳ３０３以降は、定期的に実行される。したがって、定期的な周期において生成されたイベント情報が、イベント保持部１２５によって保持される。
【００７８】
ステップＳ３０３において、イベント解析部１４２は、保持されている（未だ出力されていない）イベント情報の件数の取得を出力方法判定部１４３に要求する。出力方法判定部１４３は、当該件数をイベント保持部１２５に問い合わせる（Ｓ３０４）。イベント保持部１２５は、当該問い合わせに応じ、現在保持されているイベント情報の件数を応答する（Ｓ３０５）。出力方法判定部１４３は、当該件数をイベント解析部１４２に応答する（Ｓ３０６）。
【００７９】
当該件数が所定数（例えば、１０件等）に到達した場合、イベント解析部１４２は、イベント保持部１２５によって保持されている各イベント情報及びその出力方法を取得する（Ｓ３０７、Ｓ３０８）。続いて、イベント解析部１４２は、当該各イベント情報及びその出力方法を指定して、当該各イベント情報の出力をイベント出力部１４４に要求する（Ｓ３０９）。なお、ここで、ステップＳ３０２以降が繰り返されないように、ステップＳ３０９の要求とステップＳ３０１の要求とは、イベント出力部１４４によって識別可能となるようにするとよい。例えば、ステップＳ３０９とＳ３０１とにおいて、イベント出力部１４４に対して呼び出されるメソッドが異なっていてもよいし、メソッドに対する引数が異なっていてもよい。
【００８０】
続いて、イベント出力部１４４は、当該各イベント情報を、指定された出力方法によって出力する（Ｓ３１０）。例えば、イベント出力部１４４は、当該イベント情報を含む電子メールを、管理者のメールアドレス宛に送信する。
【００８１】
続いて、イベント解析部１４２は、ステップＳ３０８において取得された各イベント情報の削除をイベント保持部１２５に要求する（Ｓ３１１）。その結果、当該各イベント情報は、重複して出力されないように保持対象から除外される。
【００８２】
上述したように、第三の実施の形態によれば、イベント情報は一時的に画像形成装置１０内において保持され、定期的に出力される。したがって、例えば、機器管理システム３のように、イベント情報の出力先が管理者端末３０に限定されている場合、管理者端末３０に頻繁にイベント情報が通知されることによる煩雑さを低減させることができる。
【００８３】
次に、第四の実施の形態について説明する。第四の実施の形態では、イベント出力部１４４の拡張性に関して説明する。なお、第四の実施の形態は、上記各実施の形態と組み合わせて実施される。
【００８４】
上記各実施の形態では、出力ルールの定義に応じて、各種のイベント情報の出力先を変化させることができる。但し、出力ルールに定義可能な出力方法は、イベント出力部１４４の実装の範囲内に限定される。このことは、翻せば、イベント出力部１４４が対応可能な出力方法を容易に拡張可能とすることができれば、出力ルールに定義可能な出力方法の種類も容易に増加させることができることを意味する。
【００８５】
そこで、第四の実施の形態において、イベント出力部１４４は、図１６に示されるような構成を有する。
【００８６】
図１６は、第四の実施の形態におけるイベント出力部の機能構成例を示す図である。同図において、イベント出力部１４４は、インタフェース部１６１、一以上の出力方法実装部１６２、及び対応情報記憶部１６３等を含む。
【００８７】
各出力方法実装部１６２は、それぞれ一つ出力方法に対応した実装である。例えば、或る出力方法実装部１６２は、管理者のメールアドレス宛の電子メールによるイベント情報の送信を行う。別の出力方法実装部１６２は、イベント管理サーバ２０へのイベント情報の転送を行う。
【００８８】
インタフェース部１６１は、イベント解析部１４２等とのインタフェースを担う部分である。すなわち、インタフェース部１６１は、イベント解析部１４２より、イベント情報及びその出力方法が指定されたイベント情報の出力要求を受け付ける。インタフェース部１６１は、指定された出力方法に対応する出力方法実装部１６２に、当該イベント情報の出力を実行させる。
【００８９】
対応情報記憶部１６３は、出力方法と出力方法実装部１６２との対応情報を記憶する。すなわち、インタフェース部１６１は、対応情報記憶部１６３を参照して、出力方法に応じた出力方法実装部１６２を特定する。なお、対応情報記憶部１６３は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を用いて実現可能である。
【００９０】
図１６に示されるような構成において、出力方法実装部１６２を動的にリンク可能なプログラムモジュールとすれば、新たな出力方法の追加を容易とすることができる。すなわち、新たな出力方法に応じた出力方法実装部１６２を実装し、当該出力方法実装部１６２に関する対応情報を対応情報記憶部１６３に登録すれば、基本的に、既存部分の改変を行うことなく新たな出力方法を有効とすることができる。
【００９１】
対応情報記憶部１６３に対する設定は、例えば、インタフェース部１６１が操作パネル１５又は監理者端末３０等に表示させる対応情報設定画面を介して行われればよい。
【００９２】
図１７は、対応情報設定画面の表示例を示す図である。同図において、対応情報設定画面５１０は、対応情報一覧５１１、編集ボタン５１２，削除ボタン５１３、出力方法入力領域５１４、説明入力領域５１５、実装名入力領域５１６、及び追加ボタン５１７等を有する。
【００９３】
対応情報一覧５１１は、対応情報記憶部１６３に記憶されている対応情報の一覧を表示する。各対応情報は、出力方法、説明、及び実装名等の項目を有する。出力方法は、出力方法を識別するための文字列である。すなわち、当該文字列が、出力ルール記憶部１４５の出力方法に設定される。同図の内容は、図１２の出力ルール記憶部１４５に対応している。説明は、出力方法の内容を説明する文字列である。実装名は、当該出力方法に対応する出力方法実装部１６２のプログラムモジュール名である。
【００９４】
対応情報一覧５１１において、いずれかの対応情報のチェックボタン５１１ｂがチェックされ、削除ボタン５１３が押下されると、当該対応情報が対応情報記憶部１６３より削除される。また、編集ボタン５１２が押下されると、当該対応情報の出力方法、説明、及び実装名が、出力方法入力領域５１４、説明入力領域５１５、又は実装名入力領域５１６に表示され、編集可能な状態となる。編集後、追加ボタン５１７が押下されると、編集後の対応情報が対応情報記憶部１６３に追加される。例えば、出力方法実装部１６２をバージョンアップした場合、バージョンアップ後のモジュール名によって実装名を更新することで、バージョンアップ後の出力方法実装部１６２を有効とすることができる。
【００９５】
また、出力方法入力領域５１４、説明入力領域５１５、及び実装名入力領域５１６が空の状態において、各領域に値が入力され、追加ボタン５１７が押下されると、新たな対応情報が対応情報記憶部１６３に記録される。
【００９６】
各出力方法実装部１６２に固有の設定情報の設定については、各出力方法実装部１６２が、操作パネル１５又は監理者端末３０等に表示させる設定画面を介して行われればよい。
【００９７】
図１８は、出力方法実装部の設定画面の一例を示す図である。同図の設定画面５２０は、出力方法表示領域５２１、説明表示領域５２２、及び実装名表示領域５２３、更新ボタン５２４、管理者アドレス入力領域５２５、及びＯＫボタン５２６等を有する。
【００９８】
出力方法表示領域５２１、説明表示領域５２２、及び実装名表示領域５２３には、現在設定対象とされている出力方法実装部１６２の出力方法、説明、又は実装名が表示される。
【００９９】
管理者アドレス入力領域５２４は、管理者のメールアドレスを入力させるための領域である。すなわち、図１８の設定画面５２０は、管理者に対してメール送信を行う出力方法実装部１６２に関する設定画面の例である。したがって、他の出力方法に関する出力方法実装部１６２については、当該他の出力方法実装部１６２に固有の設定情報に関する入力領域が表示される。ＯＫボタン５２６が押下されると、管理者アドレス入力領域５２４に入力されたメールアドレスが、当該出力方法実装部１６２に設定される。
【０１００】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１０１】
１、２、３ 機器管理システム
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０、２０ａ、２０ｂ イベント管理サーバ
３０ 管理者端末
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２１ 拡張アプリ
１２２ 監視部
１２３ イベント通知部
１２４ インストール情報記憶部
１２５ イベント保持部
１３１ 拡張アプリ監視部
１３２ イベント生成判定部
１３３ 生成ルール記憶部
１４１ イベント生成部
１４２ イベント解析部
１４３ 出力方法判定部
１４４ イベント出力部
１５１ 拡張アプリ設定監視部
１５２ 機器設定監視部
１６１ インタフェース部
１６２ 出力方法実装部
１６３ 対応情報記憶部
【先行技術文献】
【特許文献】
【０１０２】
【特許文献１】特開２００５‐２６９６１９号広報
【特許文献２】特開２００４‐１８７００８号広報
【特許請求の範囲】
【請求項１】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、
前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、
前記イベント情報を出力する出力手段とを有する画像形成装置。
【請求項２】
前記出力手段は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項１記載の画像形成装置。
【請求項３】
前記監視手段は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項１又は２記載の画像形成装置。
【請求項４】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、
前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、
前記イベント情報を出力する出力手順とを画像形成装置が実行する管理方法。
【請求項５】
前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項４記載の管理方法。
【請求項６】
前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項４又は５記載の管理方法。
【請求項７】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、
前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、
前記イベント情報を出力する出力手順とを画像形成装置に実行させる管理プログラム。
【請求項８】
前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項７記載の管理プログラム。
【請求項９】
前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項７又は８記載の管理プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載の管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手段と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手段と、
前記生成判定手段によって、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手段と、
前記イベント情報を出力する出力手段とを有する画像形成装置。
【請求項２】
前記出力手段は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項１記載の画像形成装置。
【請求項３】
前記監視手段は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項１又は２記載の画像形成装置。
【請求項４】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、
前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、
前記イベント情報を出力する出力手順とを画像形成装置が実行する管理方法。
【請求項５】
前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項４記載の管理方法。
【請求項６】
前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項４又は５記載の管理方法。
【請求項７】
インストールされているアプリケーションプログラムの一覧情報に基づいて前記アプリケーションプログラムの状態を監視し、該状態の変化を検知する監視手順と、
検知された前記状態の変化が、第一の記憶手段の記憶するイベント情報の生成条件に合致するか否かを判定する生成判定手順と、
前記生成判定手順において、前記状態の変化が前記生成条件に合致すると判定された場合に、該状態の変化を示すイベント情報を生成する生成手順と、
前記イベント情報を出力する出力手順とを画像形成装置に実行させる管理プログラム。
【請求項８】
前記出力手順は、前記イベント情報の内容に応じて前記イベント情報の出力先を示す情報を記憶する第二の記憶手段を参照して、前記イベント情報の出力先を選択する請求項７記載の管理プログラム。
【請求項９】
前記監視手順は、前記アプリケーションプログラムに関する第一の設定情報と前記画像形成装置に関する第二の設定情報とを比較し、前記第一の設定情報と前記第二の設定情報との組み合わせの不整合を検知する請求項７又は８記載の管理プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載の管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−１８２６６９（Ｐ２０１２−１８２６６９Ａ）
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願番号】特願２０１１−４４３２６（Ｐ２０１１−４４３２６）
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]