JP2011114408A - 画像処理装置及び画像処理方法 - Google Patents

Abstract

【課題】本発明では、装置内の状態通知を行う機能の開発・追加に関し効率良く行うことができる画像処理装置を提供することを目的とする。
【解決手段】開示の画像処理装置の一形態は、装置内で発生したイベントを検知する検知手段と、装置内で発生するイベントと該装置内において取られるべき措置とを対応付けて保持される情報の中から、前記検知手段により検知された前記イベントに対応する措置を選択する措置選択手段と、前記措置選択手段により選択された前記措置を実行する措置実行手段と、を有し、前記装置内において取られるべき措置は、前記イベントが発生した旨を該装置の外部に通知することであることを特徴とする。
【選択図】図４

Description

本発明は、画像処理装置における装置状態の通知処理の技術に関する。

画像処理装置の内部において、エラー発生やメンテナンス要求などのイベントが発生した場合、ネットワーク上のサーバやユーザ端末に対し、電子メールなどの通知手段を用いて情報通知を行うことが行われる。そして、上記の情報通知を行うために、装置内部で発生したイベントをトリガとして通知手段が起動される。

従来、画像処理装置の情報通知システムにおいて、情報通知の方法は予め当該情報通知システムが備える通知手段に限られる。従って、新規プロトコルへの対応により通知手段を追加する場合、当該情報通知システムを修正し、装置内のソフトウェア全体を更新する必要があるという問題点があった。

また、同一の条件での情報通知であっても、通知手段毎に管理する必要があり、実装に重複が多くなるという問題点があった。つまり、どのようなイベントを検知し、検知されたイベント毎にどのような処理を行うかについて通知手段毎に実装する必要があり、開発効率が悪いという問題点があった。

そこで、本発明では、装置内の状態通知を行う機能の開発・追加に関し効率良く行うことができる画像処理装置を提供することを目的とする。

開示の画像処理装置は、装置内の情報通知システムをフレームワーク化し、イベントトリガー管理手段の一括管理と、イベント通知の手段や送信方法をプラグインで動的に追加及び削除とを容易にすることで、装置内の状態通知を行う機能の開発・追加に関し効率良く行うことができる。

開示の画像処理装置では、装置内の状態通知を行う機能の開発・追加に関し効率良く行うことができる。

本実施の形態に係る画像処理装置を含むシステムの概要図である。 本実施の形態に係る画像処理装置のハードウェア構成の一例を示す図である。 本実施の形態に係る画像処理装置のソフトウェア構成の一例を示す図である。 本実施の形態に係る機器管理モジュールの機能ブロック図である。 本実施の形態に係るイベントトリガー管理部で保持するイベントトリガーのテーブル情報の一例である。 本実施の形態に係る画像処理装置にクライアントモジュールをプラグインする際のシーケンス図である。 本実施の形態に係る送信用プラグイン管理部で保持する情報の一例を示す図である。 本実施の形態に係る画像処理装置におけるイベント通知発生時のシーケンス図である。 本実施の形態に係る画像処理装置におけるイベント通知発生時のシーケンス図である（イベント発生条件のＡＮＤ条件によるイベント通知発生時）。

図面を参照しながら、本発明を実施するための最良の形態について説明する。
（画像処理装置を含むシステムの概要）
図１を用いて、本実施の形態に係る画像処理装置１００を含むシステムの概要について説明する。画像処理装置１００は、ネットワークＮＷに接続されている。ネットワークＮＷは、オフィス内に限定したローカルネットワーク（ＬＡＮ：Local Area Network）のみで構成されていても良いし、インターネットのような公衆回線及びそれに接続されるＬＡＮという構成でも良い。

ネットワークＮＷにはネットワークサーバ９００ａ〜９００ｎが接続されている。ネットワークサーバ９００ａ〜９００ｎは、画像処理装置１００からの情報通知を受け取る受信手段をそれぞれ備えている。ここで受信手段は、電子メールを受け取るメールサーバ機能、ＭＩＢ（Management Information Base）情報を受け取るＳＮＭＰ（Simple Network Management Protocol）マネージャ機能、ＳＯＡＰ（Simple Object Access Protocol）やＲＥＳＴ（Representational State Transfer）に準拠したＸＭＬ（Extensible Markup Language）メッセージを受け取るＷｅｂサーバ機能などがある。

ネットワークサーバ９００ａ〜９００ｎそれぞれは、１つ以上の受信手段を備えている。また、画像処理装置１００は、ネットワークサーバ９００ａ〜９００ｎの備える受信手段に対応した情報通知手段を備えている。画像処理装置１００が情報通知手段により情報を送信すると、情報はネットワークＮＷを通過し、ネットワークサーバ９００ａ〜９００ｎによって受信される。ネットワークサーバ９００ａ〜９００ｎは、受信した情報に応じてそれぞれ処理を行う。

（画像処理装置のハードウェア構成）
図２を用いて、画像処理装置１００のハードウェア構成について説明する。図２は、画像処理装置１００のハードウェア構成の一例を示す図である。画像処理装置１００は、オペレーションパネル２１０、ファクス制御２２０、エンジン部２５０とコントローラ１１０のＡＳＩＣ（Application Specific Integrated Circuit）１８０とをＰＣＩ（Peripheral Component Interconnect）バス等で接続した構成である。

コントローラ１１０は、ＡＳＩＣ１８０にＲＡＭ（Random Access Memory）１７０、ＨＤＤ（Hard Disk Drive）２００等を接続すると共に、このＡＳＩＣ１８０とＣＰＵ１２０とをＣＰＵ（Central Processing Unit）チップセットのＮＢ（North Bridge）１４０を介して接続している。このように、ＮＢ１４０を介して接続する理由は、ＣＰＵ１２０自体のインタフェースが公開されていないためである。

ここで、ＡＳＩＣ１８０及びＮＢ１４０は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ（Accelerated Graphics Port）１６０を介して接続されている。このようにＡＧＰ１６０を介して接続することとした理由は、画像処理装置１００が後述するプラットフォーム４５０やアプリケーション４３０を形成する複数のプロセスを実行制御する関係上、これらの低速のＰＣＩを接続したのでは、パフォーマンスが低下するためである。

ＣＰＵ１２０は、画像処理装置１００の全体制御を行うものであり、具体的には、後述するＯＳ３８０上でアプリケーション４３０、サービス４４０を起動して実行させる。ＮＢ１４０は、ＣＰＵ１２０とＲＡＭ１７０、シリアルバス１５０、ＡＳＩＣ１８０及びＬＡＮポート１９０とを接続するためのブリッジであり、ＲＡＭ１７０は、画像処理装置１００の描画用メモリなどとして使用するシステムメモリである。

シリアルバス１５０は、ＮＢ１４０とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＲＡＭ１７０は、コピー用画像バッファ、符号バッファとして使用するローカルメモリであり、ＡＳＩＣ１８０は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＬＡＮポート１９０は、ネットワークを介して他の画像処理装置と通信するためのＬＡＮケーブルを接続するためのＩ／Ｆ（Interface）である。

ＨＤＤ２００は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積及びフォームの蓄積を行うためのストレージであり、オペレーションパネル２１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示を行う操作部である。

従って、ＡＳＩＣ１８０には、ＲＡＭ１７０を接続するためのＲＡＭインタフェースと、ＨＤＤ２００を接続するためのハードディスクインタフェースが設けられ、これらの記憶部に対して画像データの入出力を行う場合には、入出力先がＲＡＭインタフェースまたはハードディスクインタフェースに切替えられる。

ＡＧＰ１６０は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレータカード用のバスインタフェースであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスアクセラレータカードを高速にする。

（画像処理装置のソフトウェア構成）
図３を用いて、画像処理装置１００のソフトウェア構成について説明する。図３は、画像処理装置１００のソフトウェア構成の一例を示す図である。画像処理装置１００は、プロッタ４００と、スキャナ４１０と、ファクシミリ２２０等のハードウェアリソース４２０等を有すると共に、プラットフォーム４５０とアプリケーション４３０とから構成されるソフトウェア群２７０と、起動部２６０とを備えている。

起動部２６０は、画像処理装置１００の電源投入時に先ず始めに実行され、プラットフォーム４５０やアプリケーション４３０を起動する。プラットフォーム４５０は、ＯＳ（Operating System）３８０とアプリケーション４３０が装置１００内のハードウェア資源を意識しないで処理を実行し、アプリケーション４３０が共通で使用する機能の提供を行うためのサービス４４０を有する。

サービス４４０は、複数のサービスモジュールにより形成され、具体的には機器管理モジュール３３０、コンポーネント管理３４０、履歴情報サービス３５０、機内設定アクティビティ３６０及び機内監視コンポーネント３７０がある。なお、このプラットフォーム４５０は、あらかじめ定義された関数により前記アプリケーションからの処理要求を受信可能とするアプリケーションプログラムインタフェースを有する。

ＯＳ３８０は、ＵＮＩＸ（登録商標）等のオペレーティング・システムであり、プラットフォーム４５０及びアプリケーション４３０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易になる。さらに、ＯＳ、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）のロイヤリティが不要であり、アウトソーシングも容易となる。

コンポーネント管理３４０は、画像処理装置１００にインストールされたコンポーネントを管理する。各コンポーネントの起動・停止や、コンポーネントの情報収集を行う。

履歴情報コンポーネント３５０は、ログやカウンタを管理する。ログには、画像処理装置１００にログインやネットワークによるアクセスがあったことを示すアクセスログ、画像処理装置１００で発生したジョブの履歴を示すジョブログなどがある。カウンタには、課金対象となるカウンタを示す課金カウンタ、消耗品の使用頻度をカウントするモードカウンタなどがある。

機内設定アクティビティ３６０は、画像処理装置１００の各種設定値を参照、設定するためのモジュールである。機内監視コンポーネント３７０は、画像処理装置１００の状態や構成を管理するモジュールである。

機器管理モジュール３３０は、サービス４４０の各モジュールのＩ／Ｆを隠蔽することで、アプリケーション４３０の各モジュールが画像処理装置１００の保持する情報を利用し易くするためのモジュールである。アプリケーション４３０の各モジュールが自身で利用したい情報を定義し、機器管理モジュール３３０に登録することで、サービス４４０の各モジュールが管理する様々な情報を意味のある単位で取得することが可能となる。機器管理モジュール３３０については、後ほど詳しく説明する。

アプリケーション４３０は、ページ記述言語（ＰＤＬ：Page Description Language）、ＰＣＬ（Printer Command Language）及びポストスクリプト（Postscript）を有するプリンタ用のアプリケーションであるプリンタアプリ２８０、コピー用アプリケーションであるコピーアプリ２９０、ファクシミリ用アプリケーションであるファクスアプリ３００、スキャナ用アプリケーションであるスキャナアプリ３１０、情報通知を行う通知クライアント３２０などを有する。なお、画像処理装置１００に接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーション毎に追加または削除することができる。

通知クライアント３２０は、機器管理モジュールから情報通知の依頼を受けて、ネットワーク上のサーバ（ネットワークサーバ９００ａ〜９００ｎ）に情報通知を行うモジュールである。通知モジュールは通知手段毎に別のモジュールとして作成され、登録される。通知クライアント３２０については後ほど詳しく説明する。

（機器管理モジュールの機能）
図４で、通知クライアント３２０の例として、ＭＩＢモジュール４６０、ＳＯＡＰ Ｗｅｂサービスクライアント４７０、ＲＥＳＴ Ｗｅｂサービスクライアント４８０、Ｅｍａｉｌ送信４９０を示す。また、図４には、機器管理モジュール３３０とシステムに関連するモジュールとして、コンポーネント管理３４０、履歴情報コンポーネント３５０、機内設定アクティビティ３６０、機内監視コンポーネント３７０を抜粋し記載している。また、ＳＰやカウンタのデータを永続化し保管するためのモジュールとして、永続情報保管部５５０を示している。

機器管理モジュール３３０は、プラグイン用Ｉ／Ｆ５００、イベント送信用Ｉ／Ｆ５１０、送信用プラグイン管理部５２０、イベントトリガー管理部５３０、情報収集部５４０で構成される。

プラグイン用Ｉ／Ｆ５００は、画像処理装置１００にプラグインされるクライアントモジュールとのＩ／Ｆとなる。プラグイン用Ｉ／Ｆ５００を通じて、機器管理モジュール３３０が実行するイベント通知の各種クライアントを追加できる。ＭＩＢモジュール４６０、ＳＯＡＰ Ｗｅｂサービスクライアント４７０、ＲＥＳＴ Ｗｅｂサービスクライアント４８０、Ｅｍａｉｌ送信４９０は画像処理装置１００にプラグインされるクライアントモジュールであり、プラグイン用Ｉ／Ｆ５００を通じて機器管理モジュール３３０にこれらを登録することで、ＭＩＢ、電子メール、Ｗｅｂサービスといった汎用的なネットワークＩ／Ｆを利用したイベント通知が可能となる。

イベント送信用Ｉ／Ｆ５１０は、プラグイン用Ｉ／Ｆ５００で登録したクライアントモジュールに対し、イベント通知の送信依頼を行うためのインタフェースである。汎用的なインタフェースであり、どのクライアントモジュールに対しても共通のパラメータを使って送信依頼を行うことが可能である。

送信用プラグイン管理部５２０は、プラグイン用Ｉ／Ｆ５００で登録されたクライアントモジュールの管理を行う。機器管理モジュール３３０に登録されているクライアントモジュール及びそのクライアントモジュールに対して送信依頼を行うイベント通知の管理を行い、図７で示すような構造の情報を保持している。イベントトリガー管理部５３０から、イベントトリガー発生の通知を受け、そのイベントによるイベント送信を必要とするクライアントモジュールを判断し、そのクライアントモジュールに対してイベント送信Ｉ／Ｆ５１０を通じて送信依頼を行う。

イベントトリガー管理部５３０は、機器管理モジュール３３０が送信可能な全イベント通知の管理を行う。管理対象となるイベント通知毎に、イベントの識別子や発生条件等を図５で示すようなテーブル形式で保持している。イベントトリガー管理部５３０は、情報収集部５４０から画像処理装置１００で発生した事象等を受取り、イベント通知の発生条件を満たした段階で送信用プラグイン管理部５２０にその旨を通知する。情報収集部５４０は、機内監視コンポーネント３７０などの画像処理装置１００の各モジュールから装置１００内で発生した事象を収集する。

（イベントトリガー管理部で保持するテーブル）
図５を用いて、イベントトリガー管理部１０４で保持するテーブルについて説明する。イベント種別は、電源ＯＮや電力モードなど画像処理装置１００のシステム全般に関わるイベント、ＳＣ（サービスマンコール）などのエラーのイベント、トナーなどの消耗品の情報など画像処理装置１００のメンテナンスに関するイベントなどの種別を表す。イベントＩＤは、各イベントを一意に識別するための識別子となる。トリガ名は、各イベントの意味を表すイベント通知の名称である。発生条件は、そのイベントのトリガとなる条件を表す。画像処理装置１００内のどのモジュールからの情報であるかを表すモジュール名とそのモジュールからの通知及びそのパラメータを対で保持している。例えば、「電源ＯＮ」の場合、コンポーネント管理モジュール３４０から全コンポーネントの起動が通知された段階で、「電源ＯＮ」のイベント通知を発生させる。

また、「ＳＣ発生（ＳＣ１００）」のように、サービスマンコール１００番台が発生した際に送信するイベント通知の場合など、１００番台全ての通知を発生条件に記載してＯＲ条件で出すこともできる。同様に、「カートリッジ消耗」のようにＡＮＤ条件で出すことも可能である。

（通知クライアントモジュールの追加）
図６を用いて、通知クライアントモジュール３２０の追加について説明する。図６は、画像処理装置１００にクライアントモジュールをプラグインした場合のシーケンス図である。ここでは、ＭＩＢモジュール４６０がプラグインで追加された場合を例にして説明する。

Ｓ１０でＭＩＢモジュール４６０が機器管理モジュール３３０のプラグイン用Ｉ／Ｆ５００に対しプラグイン追加を要求する。その際、プラグインの識別子となるプラグインＩＤ、プラグイン名及び送信したいイベント通知のトリガのリストをパラメータとする。イベント通知のトリガのリストに含める情報は、図５で示したテーブルのイベントＩＤである。

次に、Ｓ２０でプラグイン用Ｉ／Ｆ５００が、送信用プラグイン管理部５２０に対し、プラグイン情報の追加を要求する。送信用プラグイン管理部１０３は、機器管理モジュール３３０に登録された新たなプラグイン情報を図７に示すような形式で保持し、保持に成功した段階でプラグイン用Ｉ／Ｆ５００に登録の成否を含んだ応答を返す。プラグイン用Ｉ／Ｆ５００は応答を受けて、ＭＩＢモジュール４６０にプラグイン登録の成否を含んだ応答を返す。

（送信用プラグイン管理部で保持する情報）
図７を用いて、送信用プラグイン管理部５２０で保持する情報について説明する。図７は、送信用プラグイン管理部５２０で保持する情報を示した図である。送信用プラグイン管理部５２０で、機器管理モジュール３３０に登録されているクライアントモジュールの情報及びそのクライアントモジュールの送信対象となるイベント通知の種類を管理している。

プラグインＩＤは、プラグインを一意に識別する識別子である。プラグインＩＤとプラグイン名は、図６中のＳ１０で示すように、プラグイン時にパラメータとして渡される。イベントは、そのプラグインが送信対象とするイベント通知の種類を表す。種類は、図５で示すイベントトリガー管理部５３０で保持するイベントで示すイベントＩＤであり、それをリストとして保持する。プラグインの情報とセットでこのリストを保持する。上記のようにすることで、使用するプラグインを常に決まった方法で決定することができ、システムをシンプルにすることができる。

（イベント通知発生時の処理）
図８を用いて、機器１００内部で発生した事象に基づいたイベント通知送信実行について説明する。図８は、イベント通知発生時のシーケンス図である。図８では、例として「電源ＯＮ」のイベント通知の送信時のシーケンスを示す。はじめに、Ｓ３０でコンポーネント管理３４０が、画像処理装置１００内の全コンポーネントの起動完了を検知し、機器管理モジュール１２１６の情報収集部５４０に全コンポーネントの起動を通知する。

次に、Ｓ４０で情報収集部５４０がコンポーネント管理３４０から全コンポーネントの起動の通知があった旨を、イベントトリガー管理部５３０に通知する。Ｓ５０でイベントトリガー管理部５３０が、コンポーネント管理５５０からの全コンポーネントの起動について、図５で示すテーブルに基づきイベント通知「電源ＯＮ」のトリガであることを判断し、送信用プラグイン管理部５２０に「電源ＯＮ」のイベント発生を通知する。

Ｓ６０・Ｓ８０で送信用プラグイン管理部５２０が、「電源ＯＮ」のイベント通知について、図７で示す情報に基づき「ＭＩＢ」及び「ＲＥＳＴ Ｗｅｂサービス」のクライアントで送信が必要なことを判断し、イベント送信用Ｉ／Ｆ５１０に送信依頼を出す。Ｓ７０・Ｓ９０でイベント送信用Ｉ／Ｆ５１０が、送信依頼に含まれるプラグイン情報に基づき、該当クライアントモジュールに「電源ＯＮ」のイベント通知を実行するよう通知する。上記処理のように、画像処理装置１００は、発生させるイベントの選択を常に決まった方法で行うことができ、システムをシンプルにすることができる。

（ＡＮＤ条件によるイベント通知発生時の処理）
図９を用いて、装置１００内部で発生した事象に基づいたイベント通知送信実行について説明する。図９は、イベント発生条件のＡＮＤ条件によるイベント通知発生時のシーケンス図である。図９では、例として「カートリッジ消耗」のイベント通知の送信時のシーケンスを示す。はじめに、Ｓ１００で機内監視コンポーネント５８０が、廃トナー残量が「０」となったことを検知し、機器管理モジュール３３０の情報収集部５４０にその旨を通知する。

次に、Ｓ１１０で情報収集部５４０が機内監視コンポーネント５８０から廃トナー残量が「０」であることを知らせる通知があった旨を、イベントトリガー管理部５３０に通知する。イベントトリガー管理部５３０は、機内監視コンポーネント５８０からの廃トナー残量が「０」であることの通知は、図５で示すテーブルに基づきイベント通知「カートリッジ消耗」のトリガの一部であることを判断する。ＡＮＤ条件のため、このタイミングではまだイベント通知は行わない。

その後、Ｓ１２０で機内設定アクティビティ５７０が、あるＳＰ番号の値が５０に変更されたことを検知し、機器管理モジュール３３０の情報収集部５４０にその旨を通知する。次に、Ｓ１３０で情報収集部５４０が機内設定アクティビティ５７０から通知があった旨を、イベントトリガー管理部５３０に通知する。イベントトリガー管理部１０４は、機内設定アクティビティ１２１９からあるＳＰ番号の値が５０に変更された旨の通知について、図５で示すテーブルに基づきイベント通知「カートリッジ消耗」のトリガの一部であることを判断する。

これで条件が満たされたため、Ｓ１４０でイベントトリガー管理部５３０が送信用プラグイン管理部１０３に「カートリッジ消耗」のイベント発生を通知する。Ｓ１５０で送信用プラグイン管理部５２０が、「カートリッジ消耗」のイベント通知は、図７で示す情報に基づきＲＥＳＴ Ｗｅｂサービスクライアント４８０で送信が必要なことを判断し、イベント送信用Ｉ／Ｆ５１０に送信依頼を出す。Ｓ１６０でイベント送信用Ｉ／Ｆ５１０が、送信依頼に含まれるプラグイン情報に基づき、該当クライアントモジュールに「カートリッジ消耗」のイベント通知を実行するよう通知する。上記処理のように、柔軟な条件記述が可能になり、情報通知の利便性が向上する。

以上、本発明の実施の形態について詳述したが、本発明は係る特定の実施の形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲において、種々の変形・変更が可能である。

１００ 画像処理装置、１１０ コントローラ、１２０ ＣＰＵ、１３０ ＲＡＭ、１４０ ＮＢ、１５０ シリアルバス、１６０ ＡＧＰ、１７０ ＲＡＭ、１８０ ＡＳＩＣ、１９０ ＬＡＮポート、２００ ＨＤＤ、２１０ 操作部（オペレーションパネル）、２２０ ファクス制御、２３０ プロッタ、２４０ スキャナ、２５０ エンジン部、２６０ 起動部、２７０ ソフトウェア群、２８０ プリンタアプリ、２９０ コピーアプリ、３００ ファクスアプリ、３１０ スキャナアプリ、３２０ 通知クライアント、３３０ 機器管理モジュール、３４０ コンポーネント管理、３５０ 履歴情報コンポーネント、３６０ 機内設定アクティビティ、３７０ 機内監視コンポーネント、３８０ ＯＳ、３９０ エンジンＩ／Ｆ、４００ プロッタ、４１０ スキャナ、４２０ その他ハードウェアリソース、４３０ アプリケーション、４４０ サービス、４５０ プラットフォーム、４６０ ＭＩＢモジュール、４７０ ＳＯＡＰ Ｗｅｂサービスクライアント、４８０ ＲＥＳＴ Ｗｅｂサービスクライアント、４９０ Ｅｍａｉｌ送信、５００ プラグインＩ／Ｆ、５１０ イベント送信Ｉ／Ｆ、５２０ 送信用プラグイン管理部、５３０ イベントトリガー管理部、５４０ 情報収集部、５５０ 永続情報保管部、９００ａ〜９００ｎ ネットワークサーバ、ＮＷ ネットワーク

特開２００５−３０１９９９号公報

Claims (5)

1. 装置内で発生したイベントを検知する検知手段と、
   装置内で発生するイベントと該装置が取るべき措置とを対応付けて保持される情報の中から、前記検知手段により検知された前記イベントに対応する措置を選択する措置選択手段と、
   前記措置選択手段により選択された前記措置を実行する措置実行手段と、を有し、
   前記装置が取るべき措置は、前記イベントが発生した旨を該装置の外部に通知することであることを特徴とする画像処理装置。
2. 前記検知手段は、複数の前記イベントを検知し、
   前記措置選択手段は、前記複数のイベントに対応する措置を選択することを特徴とする請求項１に記載の画像処理装置。
3. 前記措置実行手段は、当該装置に登録されたプラグインによる制御によって前記措置を実行することを特徴とする請求項１又は２に記載の画像処理装置。
4. 前記措置選択手段は、前記検知手段により検知されたイベントに対応する措置として、複数の措置を選択することを特徴とする請求項１乃至３の何れか一に記載の画像処理装置。
5. 検知手段が、装置内で発生したイベントを検知するステップと、
   措置選択手段が、装置内で発生するイベントと該装置が取るべき措置とを対応付けて保持される情報の中から、前記検知手段により検知された前記イベントに対応する措置を選択するステップと、
   措置実行手段が、前記措置選択手段により選択された前記措置を実行するステップと、を含み、
   前記装置が取るべき措置は、前記イベントが発生した旨を該装置の外部に通知することであることを特徴とする画像処理方法。

Images