画像処理装置
【課題】本発明では、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することを目的とする。
【解決手段】本発明に係る画像処理装置は、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする。
【解決手段】本発明に係る画像処理装置は、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理に関するアプリケーションの機能を拡張するためのプラグインを追加する際に、当該プラグインが備えるインタフェースの仕様について適切か否かの判定を行う技術に関する。
【背景技術】
【０００２】
近年、パーソナルコンピュータおよびワークステーションなどの装置だけでなく、様々な装置に高性能なＡＰＩ（Application Program Interface）を有するＯＳ（Operating System）が採用されている。例えば、コピー、プリンタ、スキャナ、ＦＡＸ、またはドキュメントサーバなどの機能を集約した複合機（ＭＦＰ）などの装置にも、このようなＯＳが採用されている。
ＡＰＩの性能が低かった頃は、これらの装置の機能拡張を行い、または応用的な処理を行うためのプログラムを作成することは難しく、手間が掛かった。装置の構造を理解し、機械語などの言語を用いてプログラムをコーディングしなければならなかったからである。
【０００３】
しかし、高性能なＡＰＩが採用されるようになってからは、予め用意されているＡＰＩ関数をコールするだけで種々の機能を呼び出して処理を行うことができるようになった。これにより、従来よりも容易にプログラミングが行われるようになった。
したがって、今後、これらの装置の機能拡張を行いまたは応用的な処理を行うためのプログラム、およびこれらのプログラムを作成し提供するサービス提供者が増えると予測される。このことは、ユーザにとって、装置をより便利に使用することができるようになるという利点があるが、その一方で、不正な処理を実行しユーザに損害をもたらす欠陥のあるプログラムや悪意のあるプログラムが流通しやすくなるという問題点もある。
【０００４】
そこで、上記装置でプログラムを実行する際に、何らかのチェックを行う必要があるものと考えられるが、特許文献１では、ＭＦＰにプログラムを追加する際に、そのプログラムの作成者の情報に基づいて当該プログラムの実行制御を行う技術が公開されている。この技術においては、プログラム実行時に、該プログラムの作成者にアクセス許可されていないＡＰＩ呼び出しを行うと、そのＡＰＩ呼び出しが禁止される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、上記技術においては、プログラムの作成者情報を登録する必要があり、未登録の作成者により作成されたプログラムには適用できないという問題点がある。
また、上記技術においては、プログラムの作成者が正当か否かに基づいてプログラムの実行制御はできるものの、装置に追加するプログラム自体に問題が無いか否かをチェックすることができないという問題点がある。
【０００６】
そこで、本発明では、上記問題点に鑑み、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
開示の画像処理装置の一形態では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、対応するアプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする。
【発明の効果】
【０００８】
本発明では、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施の形態に係る複合機のソフトウェア構成例を説明するための図である。
【図２】本実施の形態に係るパイプ＆フィルタの概念を説明するための図である。
【図３】本実施の形態に係るフィルタの構成要素を説明するための図である。
【図４】本実施の形態に係る複合機における各機能を実現するためのフィルタの組み合わせの例を示す図である。
【図５】本実施の形態に係る複合機の動作原理を説明するための図である。
【図６】本実施の形態に係る機能拡張プラグインを追加する前の処理例を説明するためのシーケンス図である。
【図７】本実施の形態に係る機能拡張プラグインを追加した後の処理例を説明するためのシーケンス図である。
【図８】本実施の形態に係る機能拡張プラグインを追加する際に行うテスト項目例を説明するための図である。
【図９】本実施の形態に係る複合機のハードウェア構成の一例を示す図である。
【図１０】本実施の形態に係る複合機に機能拡張プラグインを追加する際の処理例を示すフローチャートである。
【図１１】本実施の形態に係る複合機に機能拡張プラグインを追加する際の処理例を示すフローチャートである。
【図１２】本実施の形態に係る機能拡張プラグインに対するテスト内容を変更する処理例を示すフローチャートである。
【図１３】画像処理装置がＣＰＵとメモリを２組ずつ有する構成を示す図である。
【図１４】画像処理装置が有する１組のＣＰＵとメモリをテスト専用にする構成を示す図である。
【図１５】画像処理装置が有するＣＰＵを１つにした構成を示す図である。
【図１６】画像処理装置が有するメモリを１つにした構成を示す図である。
【図１７】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（片方が終わるまで待つ場合）を示す図である。
【図１８】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（一方を止めて委譲する場合）を示す図である。
【図１９】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（片方が終わるまで待つ場合）のフローチャートである。
【図２０】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（一方を止めて委譲する場合）のフローチャートである。
【図２１】ジョブが投入された場合、テストを中断／再開する場合のフローチャートである。
【図２２】ジョブが投入された場合、テストを中断／再開する場合の構成を示す図である。
【図２３】テストサーバと画像処理装置との接続例を示す図である。
【図２４】テストサーバと画像処理装置との接続例を示す図である。
【図２５】テスト実施部をプリントサーバと別構成にした場合の構成を示す図である。
【図２６】テスト実施をプラグインのインストール後に行う場合のフローチャートを示す図である。
【図２７】テストサーバに格納されている情報の一例を示す図である。
【図２８】テスト実施をプラグインのインストール前に行う場合のフローチャートを示す図である。
【図２９】テスト実施部をプリントサーバ内でソフトエミュレーションした場合の構成を示す図である。
【図３０】プラグイン可能なインストール一覧を更新する場合のフローチャートを示す図である。
【図３１】テスト項目を特定する場合のフローチャートを示す図である。
【発明を実施するための形態】
【００１０】
図面を参照しながら、本発明を実施するための最良の形態について説明する。
（本発明に係る画像処理装置のソフトウェア構成）
図１は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。ここで、複合機とは、プリンタ、コピー、スキャナ、又はＦＡＸ等の複数の機能を一台の筐体において実現する画像処理装置をいう。
【００１１】
図１で示すように、複合機１におけるソフトウェアは、ユーザインタフェース層１０、コントロール層２０、アプリケーションロジック層３０、デバイスサービス層４０及びデバイス制御層５０より構成される。なお、図中における各層の上下関係は、層間の呼び出し関係に基づいている。すなわち、基本的に図中において上にある層が下の層を呼び出す。
【００１２】
ユーザインタフェース層１０は、機能（例えば、コピー、印刷、スキャン、ＦＡＸ送信）の実行要求を受け付けるための機能が実装されている部分であり、例えば、通信サーバ部１１及びローカルＵＩ（User Interface）部１２が含まれる。通信サーバ部１１は、例えば、非図示のクライアントＰＣ（Personal Computer）からネットワーク経由で要求を受け付ける。ローカルＵＩ部１２は、例えば、非図示のオペレーションパネルを介して入力される要求を受け付ける。ユーザインタフェース層１０において受け付けられた要求は、コントロール層２０に伝えられる。
【００１３】
コントロール層２０は、要求された機能を実現するための処理を制御するための機能が実装されている部分である。具体的には、要求された機能に応じて、アプリケーションロジック層３０における各フィルタを接続し、接続されたフィルタに基づいて機能の実行を制御する。
コントロール層２０は、例えば、リクエスト管理部２１、プラグイン管理部２２を有する。リクエスト管理部２１は、要求されたジョブに応じて、アプリケーションロジック層３０が有する各フィルタを接続し、接続されたフィルタに基づいてジョブの実行を制御する。プラグイン管理部２２は、複合機１に実装されるジョブを実行するための手段等の物理的なアドレスと、手段の動作とを管理する。なお、本実施の形態においては、プラグイン管理部２２が管理する「プラグイン」とは、複合機１が有する基本機能に対して新たに追加される機能に対応するプログラム又はデバイス、及び、複合機１が有する基本機能に対応するプログラム又はデバイスを含む。すなわち、プラグイン管理部２２は、複合機１が有する基本機能及び追加機能に対応するプログラム又はデバイス等の物理的なアドレス、及び、それらの動作を管理する手段である。
なお、本実施の形態において「複合機１の機能」とは、複合機１がユーザに対して提供する一つのまとまった単位（要求が入力されて最終的な出力が得られるまで）のサービスと同義であり、ソフトウェア的には一つのまとまった単位のサービスを提供するアプリケーションと同義である。
【００１４】
アプリケーションロジック層３０は、それぞれが複合機１において提供される機能の一部を実現する部品群が実装されている部分である。すなわち、アプリケーションロジック層３０における部品を組み合わせることにより一つの機能が実現される。本実施の形態では、各部品を「フィルタ」と呼ぶ。これは、複合機１のソフトウェアアーキテクチャが「パイプ＆フィルタ」と呼ばれる考え方に基づくことによる。
【００１５】
図２は、パイプ＆フィルタの概念を示すための図である。図２においては、「Ｆ」はフィルタを示し、「Ｐ」はパイプを示す。図中に示されるように、各フィルタはパイプによって接続される。フィルタは、入力されたデータに対して変換を施し、その結果を出力する。パイプは、フィルタから出力されたデータを次のフィルタに伝達する。
【００１６】
すなわち、本実施の形態における複合機１では、各機能をドキュメント（データ）に対する「変換」の連続として捉える。複合機の各機能は、ドキュメントの入力、加工、及び出力によって構成されるものとして一般化することができる。そこで、「入力」、「加工」、及び「出力」を「変換」として捉え、一つの「変換」を実現するソフトウェア部品がフィルタとして構成される。入力を実現するフィルタを特に「入力フィルタ」という。また、加工を実現するフィルタを特に「加工フィルタ」という。更に、出力を実現するフィルタを特に「出力フィルタ」という。なお。各フィルタは独立しており、フィルタ間における依存関係（呼び出し関係）は基本的には存在しない。したがって、フィルタ単位で追加（インストール）又は削除（アンインストール）が可能とされている。
【００１７】
図１において、アプリケーションロジック層３０には、入力フィルタとして、読取フィルタ３０１、メール受信フィルタ３０２、ＦＡＸ受信フィルタ３０３、ＰＣ文書受信フィルタ３０４が含まれている。
読取フィルタ３０１は、スキャナによる画像データの読み取りを制御し、読み取られた画像データを出力する。メール受信フィルタ３０２は、電子メールを受信し、当該電子メールに含まれているデータを出力する。ＦＡＸ受信フィルタ３０３は、ＦＡＸ受信を制御し、受信されたデータを出力する。ＰＣ文書受信フィルタ３０４は、非図示のクライアントＰＣから印刷データを受信し、受信された印刷データを出力する。
【００１８】
図１において、アプリケーションロジック層３０には、加工フィルタとして、文書加工フィルタ３１１、文書変換フィルタ３１２が含まれている。
文書加工フィルタ３１１は、入力されたデータに所定の画像変換処理（集約、拡大、又は縮小等）を施し、出力する。文書変換フィルタ３１２は、レンダリング処理を実行する。すなわち、入力されたＰｏｓｔＳｃｒｉｐｔデータをビットマップデータに変換して出力する。
【００１９】
図１において、アプリケーションロジック層３０には、出力フィルタとして、印刷フィルタ３２１、メール送信フィルタ３２２、ＦＡＸ送信フィルタ３２３、ＰＣ文書送信フィルタ３２４が含まれている。
印刷フィルタ３２１は、入力されたデータをプロッタに出力（印刷）させる。メール送信フィルタ３２２は、入力されたデータを電子メールに添付して送信する。ＦＡＸ送信フィルタ３２３は、入力されたデータをＦＡＸ送信する。ＰＣ文書送信フィルタ３２４は、入力されたデータをクライアントＰＣに送信する。
【００２０】
また、アプリケーションロジック層３０は、ビルトインテスト３４を含む。ビルトインテスト３４は、上記で説明したフィルタ又はアクティビティの機能を拡張するプラグイン（プログラム）を複合機１に追加する際に、該プラグインの備えるインタフェース（Ｉ／Ｆ）が適切か否かをチェックする。また、ビルトインテスト３４は、後述するテスト内容抽出手段１２０及びプラグインテスト手段１３０に該当し、プラグインテストテーブル２００を含むものである。
【００２１】
デバイスサービス層４０は、アプリケーションロジック層３０における各フィルタから共通に利用される下位機能が実装されている部分であり、例えば、画像パイプ４１及びデータ管理部４２が含まれる。画像パイプ４１は、上述したパイプの機能を実現する。すなわち、或るフィルタからの出力データを次のフィルタに伝達する。データ管理部４２は、各種のデータベースを表現する。例えば、ユーザ情報が登録されたデータベースや、文書又は画像データ等が蓄積されるデータベース等が相当する。
【００２２】
デバイス制御層５０は、デバイス（ハードウェア）を制御するドライバと呼ばれるプログラムモジュール群が実装されている部分であり、例えば、スキャナ制御部５１、プロッタ制御部５２、メモリ制御部５３、電話回線制御部５４、及びネットワーク制御部５５が含まれる。各制御部は、当該制御部の名前に付けられているデバイスを制御する。
【００２３】
フィルタについて更に詳しく説明する。図３は、フィルタの構成要素を説明するための図である。図３に示されるように、各フィルタは、フィルタ設定用ＵＩ、フィルタロジック、フィルタ固有下位サービス及び永続記憶領域情報により構成される。
フィルタ設定用ＵＩは、フィルタの実行条件を設定させるための画面をオペレーションパネルに表示させるプログラムである。例えば、入力フィルタの一つである読取フィルタであれば、解像度、濃度、画像種別を設定する画面が相当する。なお、オペレーションパネルの表示がＨＴＭＬ（HyperText Markup Language）データや、スクリプトに基づいて行われ得ることに鑑みれば、フィルタ設定用ＵＩはＨＴＭＬデータやスクリプトであっても良い。
【００２４】
フィルタロジックは、フィルタの機能を実現するためのロジックが実装されたプログラムである。例えば、読取フィルタであれば、スキャナによる原稿読み取り制御のためのロジックが相当する。
フィルタ固有下位サービスは、フィルタロジックを実現するために必要な下位機能（ライブラリ）である。例えば、読取フィルタであれば、スキャナを制御するための機能が相当する。
永続記憶領域情報は、フィルタに対する設定情報（例えば、実行条件のデフォルト値）等、不揮発性メモリに保存する必要があるデータのスキーマ定義が相当する。当該スキーマ定義は、フィルタのインストール時にデータ管理部４２に登録される。
【００２５】
図４は、本実施の形態の複合機における各機能（アプリケーション）を実現するためのフィルタの組み合わせの例を示す図である。
例えば、コピー機能は、読取フィルタ３０１と印刷フィルタ３２１とを接続することにより実現される。読取フィルタ３０１によって、原稿から読み取られた画像データを印刷フィルタ３２１によって印刷すれば良いからである。なお、コピー機能に付随する、集約、拡大、縮小等の加工が要求された場合には、これらの加工を実現する文書加工フィルタ３１１が読取フィルタ３０１と印刷フィルタ３２１の間に挿入される。
【００２６】
プリンタ機能（クライアントPCからの印刷機能）は、ＰＣ文書受信フィルタ３０４と文書変換フィルタ３１２と印刷フィルタ３２１とを接続することにより実現される。スキャンｔｏ ｅｍａｉｌ機能（スキャンした画像データを電子メールで転送する機能）は、読取フィルタ３０１とメール送信フィルタ３２２とを接続することにより実現される。ＦＡＸ送信機能は、読取フィルタ３０１とＦＡＸ送信フィルタ３２３とを接続することにより実現される。ＦＡＸ受信機能は、ＦＡＸ受信フィルタ３０３と印刷フィルタ３２１とを接続することにより実現される。
【００２７】
また、アプリケーションロジック層３０は、コピーアクティビティ３１、プリンタアクティビティ３２、マルチ文書アクティビティ３３を含む。ここで、アクティビティとは、予め固定的に定義されたフィルタの組み合わせによって、一つの機能（複合機１がユーザに対して提供する一つのまとまった単位のサービス又はアプリケーション）を実現するソフトウェアである。コピーのように頻繁に利用する機能については、毎回フィルタの選択によってユーザが実行指示を行うのは煩雑であるため、予めフィルタの組み合わせを定義することで、この煩雑さを解消するために用意されるものである。
コピーアクティビティ３１は、読取フィルタ３０１と文書加工フィルタ３１１と印刷フィルタ３２１との組み合わせにより、コピー機能（コピーアプリケーション）を実現するアクティビティである。
プリンタアクティビティ３２は、ＰＣ文書受信フィルタ３０４と文書変換フィルタ３１２と印刷フィルタ３２１との組み合わせにより、印刷機能（プリンタアプリケーション）を実現するアクティビティである。
マルチ文書アクティビティ３３は、入力フィルタ、加工フィルタ、出力フィルタのそれぞれについて、自由な組み合わせが可能なアクティビティである。
なお、各アクティビティは独立しており、各アクティビティ間における依存関係（呼び出し関係）は基本的には存在せず、したがって、アクティビティ毎に追加（インストール）、削除（アンインストール）が可能である。
【００２８】
（本実施の形態に係る複合機１の動作原理）
図５を用いて、本発明の画像処理装置である複合機１の動作原理について説明する。図５は複合機１の動作原理を示した図である。
図５で示すように、複合機１は、プラグイン登録手段１１０、テスト内容抽出手段１２０、プラグインテスト手段１３０、プラグイン削除手段１４０、テスト実行選択手段１５０、テスト内容変更手段１６０、画像処理テスト手段１７０、画像処理手段１８０、記憶装置８３を有する。また、複合機１とダウンロードサーバ３００とは、通信ネットワークで接続されているものとし、該通信ネットワークは、有線通信ネットワークであっても無線通信ネットワークであっても良い。
【００２９】
画像処理手段１８０は、複合機１が行う一般的な画像処理を実行し、例えば、コピー処理、プリンタ処理、ＦＡＸ処理等を実行する。
【００３０】
記憶装置８３は、画像処理に係るアプリケーションの機能を拡張するためのプラグイン１９０、プラグイン１９０を追加する際のテスト内容を規定するプラグインテストテーブル２００、複合機１の基本性能を規定する基本機能確認基準２１０を保持している。
画像処理に係るアプリケーションは、上記説明におけるアプリケーションロジック層３０を構成する入力フィルタ（読取フィルタ３０１等）、加工フィルタ（文書加工フィルタ３１１等）、出力フィルタ（印刷フィルタ３２１等）、各アクティビティ３１、３２、３３、ビルトインテスト３４とする形態であっても良い。
【００３１】
図６、７を用いて、上記画像処理に係るアプリケーションを機能拡張するためのプラグイン１９０について説明することとし、ここでは、複合機１が有するスキャナ８９を用いて、３枚の原稿を読み取る処理を例にして説明を行う。この場合、追加するプラグイン１９０によって機能拡張されるアプリケーションは、読取フィルタ３０１となる。
図６で示すように、機能拡張プラグイン１９０を複合機１に追加する前の環境では、ローカルＵＩ部１２から受け付けられた要求「スキャン実行」は読取フィルタ３０１に伝達され、読取フィルタ３０１は当該要求に従いスキャナ８９に原稿を読み取らせる。そして、スキャナ８９は原稿を１枚読み取る毎に、スキャンを実行した旨の信号「スキャン実行イベント（進捗）」を読取フィルタ３０１に通知し、読取フィルタ３０１は当該信号をローカルＵＩ部１２へ通知する処理を行う。
【００３２】
一方、図７で示すように、機能拡張プラグインを複合機に追加した後の環境でも、ローカルＵＩ部１２から受け付けられた要求「スキャン実行」は読取フィルタ３０１に伝達され、読取フィルタ３０１は当該要求に従いスキャナ８９に原稿を読み取らせる。ただし、スキャナ８９が原稿を１枚読み取る毎に読取フィルタ３０１に通知する信号「スキャン実行イベント（進捗）」は、一旦機能拡張プラグイン１９０に通知され、当該通知をトリガーとして機能拡張プラグイン１９０による所定の処理が行われた後、読取フィルタ３０１は当該信号をローカルＵＩ部１２へ通知する。
ここで、機能拡張プラグイン１９０による所定の処理は、スキャナ８９が原稿を読み取った時刻や処理実行（ここでは、スキャン実行）を要求したユーザのＩＤなどの履歴情報を記録する処理（ログを残す処理）であっても良いし、機能拡張プラグイン１９０において予め定める特定のイベントが発生したと通知された場合に、スキャナ８９による原稿の読取処理を停止、再開、キャンセルさせる処理であっても良い。つまり、読取フィルタ３０１における処理に関連する処理であれば良い。
【００３３】
また、図８を用いて、プラグインテストテーブル２００について説明する。図８は、機能拡張のためのプラグインを複合機１に追加する際に、当該プラグインに対し確認すべき項目の一例であり、機能拡張の対象となるアプリケーション（図８では、フィルタ）毎に、必要なインタフェース（以後、Ｉ／Ｆ：ＩｎｔｅｒＦａｃｅ）、当該Ｉ／Ｆに関する引数の個数、及び当該Ｉ／Ｆに関する引数の型が定められている。例えば、図７で説明した例のように、読取フィルタ３０１の機能を拡張するプラグイン１９０を複合機１に追加する際に、追加するプラグイン１９０が備えるべきＩ／Ｆは「スキャンイベント受取」であり、当該Ｉ／Ｆ「スキャンイベント受取」に関する引数の個数は１つで、該Ｉ／Ｆ「スキャンイベント受取」に関する引数の型は「Ｏｂｊｅｃｔ型」であることを要求される。
【００３４】
ここで、プラグインテストテーブル２００において、必要なＩ／Ｆは１つであっても複数であっても良く、また、各Ｉ／Ｆに関する引数の個数は１つであっても複数であっても良い。さらに、各Ｉ／Ｆに関する引数の型は、Ｏｂｊｅｃｔ型であっても他の型であっても良い。
また、図８において、機能拡張される対象のアプリケーションをフィルタとしているが、該アプリケーションはアクティビティであっても良く、他のアプリケーションであっても良い。
【００３５】
また、基本機能確認基準２１０は、複合機１において画像処理を行った場合に、当該画像処理が最低限満足すべき基準であり、例えば、スキャナ８９で読み取られた画像品質やプロッタ９０で印刷された画像品質等に関する機能性基準、コピーやＦＡＸ等の画像処理に要する時間や当該画像処理に関するリソース消費量（メモリリーク、ＧＣ、ＵＩの応答時間等）に関する非機能性基準を含むものであっても良い。
【００３６】
プラグイン登録手段１１０は、ダウンロードサーバ３００から、画像処理に係るアプリケーションの機能を拡張するためのプラグイン１９０をダウンロード（取得）し、当該プラグイン１９０を記憶装置８３に記録する。
また、プラグイン登録手段１１０は、後述するプラグインテスト手段１３０の判定に基づいて、画像処理手段１８０による処理においてプラグイン１９０を利用できる状態にする。ここで、プラグイン１９０を利用できる状態とは、プラグイン管理部２２にプラグイン１９０が登録された状態である。一方で、プラグイン登録手段１１０は、テスト実行選択手段１５０の決定により、プラグインテスト手段１３０による処理が行われない場合についても、画像処理手段１８０による処理においてプラグイン１９０を利用できる状態にする。
【００３７】
テスト内容抽出手段１２０は、プラグイン登録手段１１０により取得されたプラグイン１９０がどのアプリケーション（フィルタ、アクティビティ等）に対する機能拡張プラグインなのかを判断し、この判断結果と図８で示すようなプラグインテーブル２００とを照合し、当該プラグイン１９０に関して確認すべき項目を抽出する。例えば、プラグイン登録手段１１０により取得されたプラグイン１９０が読取フィルタ３０１に対するプラグインであると判断した場合、テスト内容抽出手段１９０は、図８で示すプラグインテストテーブル２００において読取フィルタ３０１を検索し、読取フィルタ３０１に必要なＩ／Ｆは「スキャンイベント受取」であり、「スキャンイベント受取」に必要な引数の個数は「１つ」であり、「スキャンイベント受取」に必要な引数の型は「Ｏｂｊｅｃｔ型」であるという確認すべき項目を抽出する。
【００３８】
プラグインテスト手段１３０は、テスト内容抽出手段１２０により抽出される確認項目に基づいて、プラグイン１９０の備えるＩ／Ｆの仕様を確認する。具体的には、プラグイン１９０の備えるＩ／Ｆに関して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを備えているか否か、テスト内容抽出手段１２０により抽出される引数の個数と一致するか否か、テスト内抽出手段１２０により抽出される引数の型と一致するか否かについて、それぞれ判定を行う。例えば、プラグインテスト手段１３０は、プラグイン１９０（実行オブジェクト）に対して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを指定し、リフレクション機能を使用して取得を行い、プラグイン１９０が必要なＩ／Ｆを有するか否かを判定する。そして、プラグインテスト手段１３０は、上記で取得したＩ／Ｆに対して、引数の数を取得し、テスト内容抽出手段１２０により抽出される引数の数と一致するか否かを判定する。さらに、プラグインテスト手段１３０は、上記で取得したＩ／Ｆに対して、引数の型を取得し、テスト内容抽出手段１２０により抽出される引数の型と一致するか否かを判定する。このようにして、適切なＩ／Ｆの未実装を防止し、プログラムをバーションアップする場面で起こりがちなＩ／Ｆの不整合等による複合機１の動作不良を防止することができる。
【００３９】
また、プラグインテスト手段１３０は、プラグイン１９０の備えるＩ／Ｆに関して、応答時間を計測し、該応答時間が所定の時間内であるか否かを判定する。具体的には、プラグインテスト手段１３０は、プラグイン１９０（実行オブジェクト）に対して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを指定し、リフレクション機能を使用して取得を行った後、該取得したＩ／Ｆの応答時間を計測し、この計測した応答時間が所定の時間内であるか否かを判定する。ここで、Ｉ／Ｆの応答時間は、該Ｉ／Ｆに何らかの問合せを行った時刻と、該問合せに対して何らかの応答があった時刻との時刻差である。障害として発見することが難しいタイムアウトによるスレッドの不正処理等を防止することができる。
【００４０】
プラグイン削除手段１４０は、プラグインテスト手段１３０により、プラグイン１９０の備えるＩ／Ｆの仕様と、テスト内容抽出手段１２０により抽出される仕様とが一致しないと判定された場合、又は、該Ｉ／Ｆの応答時間が所定の時間内でないと判定された場合に、プラグイン１９０を記憶装置８３から削除する。未知なコンポーネントが正しい拡張ルールに従っているかを、プラグイン追加時にリアルタイムで確認することで、より信頼性の高いものしか追加させない堅牢なシステムを構築することができる。
【００４１】
テスト実行選択手段１５０は、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するか否かに関するユーザの選択を受け付け、該選択に基づいて、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するか否かを決定する。すなわち、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するとユーザが選択すればこれらの手段による処理が実行され、反対に、実行しないとユーザが選択すればこれらの手段による処理は実行されない。テスト実行の有無に関する選択をユーザに委ね、不要なテストを行わないことで、テスト実行時間の削減することができ、または、記憶装置の資源を有効活用することができる。
【００４２】
テスト内容変更手段１６０は、ダウンロードサーバ３００から、図８で示すようなプラグインテストテーブル２００をダウンロード（取得）し、該プラグインテストテーブル２００を記憶装置８３に記録する。このとき、従来のプラグインテーブル２００は、上書き、削除される形態としても良い。テスト内容変更手段１６０による処理は、アプリケーションロジック層３０のビルトインテスト３４を再インストールする処理に該当する。
こうすることで、製品が市場に出た後であっても、テスト内容を適宜変更することで、機能拡張プラグインに関するテストを適切に行うことができる。
【００４３】
画像処理テスト手段１７０は、プラグイン１９０により機能拡張されたアプリケーションを含む画像処理が、基本機能確認基準２１０を満たすか否かを判定する。機能拡張をした後でも、複合機１の基本性能が落ちていないこと（複合機１の基本性能が確保できていること）を確認することができる。
【００４４】
以下では、上記で説明した複合機１の動作原理に基づき、複合機１による処理の流れを説明する。ここでは、図７で示すように、読取フィルタ３０１の機能を拡張するためのプラグイン１９０を追加する場合の処理について説明する。
はじめに、プラグイン登録手段１１０が、ダウンロードサーバ３００から、プラグイン１９０をダウンロードし、記憶装置８３に記憶する。そして、テスト実行選択手段１５０が、プラグイン１９０に関するテストを実行する旨のユーザの選択を受け付けると、テスト内容抽出手段１２０が、プラグイン１９０が読取フィルタ３０１の機能拡張を行うものであることを検出し、プラグインテストテーブル２００から読取フィルタ３０１に対応する確認項目を抽出する。
【００４５】
そして、プラグインテスト手段１３０が、プラグイン１９０の備えるＩ／Ｆの仕様と、テスト内容抽出手段１２０により抽出された仕様とが一致するか否かを確認、判定し、両者の全ての仕様が一致すると判定した場合に、プラグイン登録手段１１０が、プラグイン１９０を利用できる状態にする。一方、プラグインテスト手段１３０が、両者の仕様に関し１項目でも一致しないと判定した場合には、プラグイン削除手段１４０が、プラグイン１９０を記憶装置８３から削除する。
【００４６】
また、プラグイン登録手段１１０が、プラグイン１９０を利用できる状態にした後、画像処理手段１８０が、プラグイン１９０を利用した画像処理（例えば、原稿をスキャナ８９で読み取り、プロッタ９０から紙出力するコピー処理）を実行し、画像処理テスト手段１７０が、該コピー処理と、該コピー処理に関する基本機能確認基準２１０とを比較して、該コピー処理が基本機能確認基準２１０をクリアしているか否かを判定する。そして、画像処理テスト手段１７０により基本機能確認基準２１０をクリアしていないと判定された場合に、プラグイン削除手段１４０が、プラグイン１９０を記憶装置８３から削除する。
【００４７】
そして、テスト内容変更手段１６０が、ダウンロードサーバ３００から、プラグインテストテーブル２００を適宜ダウンロードし、該プラグインテストテーブル２００を更新する。
上記のような処理を行うことで、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
【００４８】
（本実施の形態に係る複合機のハードウェア構成）
図９を用いて、本発明の画像処理装置である複合機１のハードウェアの構成例を説明する。図９は、本発明の実施の形態における複合機１のハードウェア構成の一例を示す図である。
複合機１のハードウェアとしては、コントローラ８０と、オペレーションパネル８７、ファクシミリコントロールユニット（ＦＣＵ：Facsimile Control Unit）８８と、撮像部８９と、印刷部９０が存在する。
【００４９】
コントローラ８０は、ＣＰＵ（Central Processing Unit）８４、ＡＳＩＣ（Application Specific Integrated Circuit）８６、ＮＢ（North Bridge）８５、ＳＢ（South Bridge）９１、ＭＥＭ−Ｐ８１、ＭＥＭ−Ｃ８２、ＨＤＤ（ハードディスクドライブ）８３、メモリカードスロット９６、ネットワークインタフェースコントローラ（ＮＩＣ：Network Interface Controller）９２、ＵＳＢ（Universal Serial Bus）デバイス９３、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.）１３９４デバイス９４、セントロニクスデバイス９５により構成される。
【００５０】
ＣＰＵ８４は、種々の情報処理用のＩＣ（Integrated Circuit）である。ＡＳＩＣ８６は、種々の画像処理用のＩＣである。ＮＢ８５は、コントローラのノースブリッジである。ＳＢ９１は、コントローラのサウスブリッジである。ＭＥＭ−Ｐ８１は、複合機１のシステムメモリである。ＭＥＭ−Ｃ８２は、複合機１のローカルメモリである。ＨＤＤ８３は、複合機１のストレージである。メモリカードスロット９６は、メモリカード９７をセットするためのスロットである。ＮＩＣ９２は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス９３は、ＵＳＢ規格の接続端子を提供するためのデバイスである。セントロニクスデバイス９５は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル８７は、オペレータが複合機１に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１から出力を得るためのハードウェア（表示部）である。
【００５１】
なお、本発明に係る複合機１のソフトウェアは、例えば、ＭＥＭ−Ｃ８２に格納され、ＣＰＵ８４によって処理されることにより、その機能を複合機１に実行させる。
【００５２】
（本発明の複合機１による処理例）
＜第１の実施例＞
従来、自動テストを行うことにより、複合機１本体に負荷が掛かってしまうため、複合機１の性能に影響が発生するが、第１の実施例においては、自動でテストを行いながらも複合機１の性能を低下させないようにする。
【００５３】
（１）複合機１によるプラグイン追加処理について
図１０を用いて、プラグインを追加する際の、複合機１による処理例について説明する。図１０は、プラグインを追加する際の、複合機１による処理の一例を示すフローチャートである。
ここでは、図７で示すような読取フィルタ３０１に関するプラグイン１９０を追加する際の処理について説明することとし、図８で示すプラグインテストテーブル２００に従って、プラグイン１９０の備えるＩ／Ｆに関するテストを行う。
【００５４】
Ｓ１０で複合機１がプラグイン追加時の処理を開始する。当該処理の開始は、ユーザによるプラグイン追加操作をローカルＵＩ部１２が受け付けたことで開始する形態としても良い。
Ｓ２０でプラグイン登録手段１１０が、ダウンロードサーバ３００から、読取フィルタ３０１の機能を拡張するプラグイン１９０を取得（ダウンロード）し、当該プラグイン１９０をＨＤＤ８３に保存する。ここで、プラグイン登録手段１１０は、プラグイン１９０をＭＥＭ−Ｐ８１に保存する形態としても良い。
【００５５】
Ｓ３０でテスト実行選択手段１５０が、複合機１に追加するプラグイン１９０に関するテストを実行するか否かに関するユーザの選択に基づいて、テスト内容抽出手段１２０及びプラグインテスト手段１３０によるテストを実施するか否かについて決定する。
追加されるプラグインの適性を確認するテストを実施するか否かの選択をユーザに委ね、不要なテストを行わないことで、テスト実行時間を削減することができ、一方では、記憶装置のリソースを有効活用することができる。
【００５６】
Ｓ３０でテスト実行選択手段１５０が、プラグイン１９０に関するテストを実施すると決定した場合（Ｓ３０でＹｅｓの場合）、Ｓ４０でテスト内容抽出手段１２０が、プラグイン１９０がどのアプリケーションに関するプラグインであるかを判別し、該判別結果に基づいて、図８で示すプラグインテストテーブル２００から、プラグイン１９０の備えるＩ／Ｆが満たすべき仕様に関する情報を抽出する。Ｉ／Ｆが満たすべき仕様に関する情報は、必要なＩ／Ｆ、該Ｉ／Ｆの引数の数、該Ｉ／Ｆの引数の型に関する情報である。本処理例のように、複合機１に追加しようとするプラグイン１９０が読取フィルタ３０１に関するプラグインの場合、該プラグイン１９０のＩ／Ｆが満たすべき仕様は、「スキャンイベント受取」というＩ／Ｆを有し、該「スキャンイベント受取」の引数の数は１つであり、該「スキャンイベント受取」の引数の型は「Ｏｂｊｅｃｔ型」であることである。
【００５７】
Ｓ３０でテスト実行選択手段１５０が、プラグイン１９０に関するテストを実施しないと決定した場合（Ｓ３０でＮｏの場合）、Ｓ７０でプラグイン登録手段１１０が、プラグイン１９０を追加する処理を完了させる、つまり、プラグイン１９０をプラグイン管理部２２に登録し、画像処理手段１８０による処理において使用できるようにする。
【００５８】
Ｓ５０でプラグインテスト手段１３０が、テスト内容抽出手段１２０により抽出した仕様と、プラグイン１９０の備えるＩ／Ｆに関する仕様とを比較して、両者の仕様が一致するか否かを判定する。すなわち、プラグインテスト手段１３０は、プラグイン１９０の備えるＩ／Ｆが「スキャンイベント受取」であるか否か（プラグイン１９０は「スキャンイベント受取」という名称のＩ／Ｆを有するか否か）、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの引数の数は１つであるか否か、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの引数の型は「Ｏｂｊｅｃｔ型」であるか否かについて、確認し、判定を行う。
また、プラグインテスト手段１３０は、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの応答時間が所定の時間内であるか否かについても、確認し、判定を行う。該応答時間の測定には、タイマーを使用する。
この様なチェックを行うことで、適切なＩ／Ｆの未実装を防止し、プログラムをバーションアップする場面で起こりがちなＩ／Ｆの不整合等による複合機１の動作不良を防止することができる。また、障害として発見することが難しいタイムアウトによるスレッドの不正処理等についても防止することができる。
【００５９】
Ｓ６０でプラグインテスト手段１３０が、上記項目の全てについて一致する（要件を満たす）と判定した場合（Ｓ６０でＹｅｓの場合）、Ｓ７０でプラグイン登録手段１１０が、プラグイン１９０を追加する処理を完了させる、つまり、プラグイン１９０をプラグイン管理部２２に登録し、画像処理手段１８０による処理において使用できるようにする。
Ｓ６０でプラグインテスト手段１３０が、上記項目のうち１項目でも一致しない（要件を満たさない）と判定した場合（Ｓ６０でＮｏの場合）、Ｓ８０でプラグイン削除手段１４０が、プラグイン１９０を記憶装置８３又はＭＥＭ−Ｐ８１から削除する。
【００６０】
Ｓ９０で複合機１がプラグイン追加時の処理を終了する。以後、プラグイン１９０が追加され、プラグイン管理部２２に登録された場合には、画像処理手段１８０が、プラグイン１９０の追加された環境で、コピー処理、プリンタ処理、ＦＡＸ処理等を行い、他方、プラグイン１９０が削除された場合には、画像処理手段１８０が、プラグイン１９０の追加される前の環境で、コピー処理、プリンタ処理、ＦＡＸ処理等を行う。
このような処理を行うことで、未知なコンポーネントが正しい拡張ルールに従っているかを、プラグイン追加時にリアルタイムで確認することで、より信頼性の高いものしか追加させない堅牢なシステムとすることができる。
【００６１】
（２）複合機１の基本動作を確認する処理について
図１１を用いて、プラグイン１９０を追加する際の、複合機１の基本動作を確認する処理について説明する。図１１は、複合機１の基本動作を確認する処理の一例を示すフローチャートである。
ここでは、図７で示すような読取フィルタ３０１に関するプラグイン１９０を追加する際の処理について説明する。
【００６２】
Ｓ１１０で複合機１が基本動作の確認を行う処理を開始する。当該処理の開始は、ユーザによる当該処理開始操作をローカルＵＩ部１２が受け付けることで開始する形態としても良いし、ユーザの操作によらず、プラグイン１９０のダウンロード後又はプラグイン管理部２２への登録後、自動的に処理を開始する形態としても良い。
Ｓ１２０で画像処理手段１８０が、読取フィルタ３０１に関するプラグイン１９０を追加した環境で、コピー処理、ＦＡＸ処理等、機能拡張された読取フィルタ３０１を使用する処理を実行する。プラグイン１９０を追加したことに伴う、複合機１の基本性能への影響の有無を確認するためである。
【００６３】
Ｓ１３０で画像処理テスト手段１７０が、画像処理手段１８０により実行された画像処理に対応する基本機能確認基準２１０を取得する。ここで、基本機能確認基準２１０は、複合機１において画像処理を行った場合に、当該画像処理が最低限満足すべき基準であり、例えば、スキャナ８９で読み取られた画像品質やプロッタ９０で印刷された画像品質等に関する機能性基準と、コピーやＦＡＸ等の画像処理に要する時間や当該画像処理に関するリソース消費量（メモリリーク、ＧＣ、ＵＩの応答時間等）に関する非機能性基準とで構成される。
【００６４】
Ｓ１４０で画像処理テスト手段１７０が、画像処理手段１８０により実行された画像処理の結果と、当該画像処理に対応する基本機能確認基準２１０とを比較して、画像処理手段１８０により実行された画像処理の結果が基本機能確認基準２１０を満たしているか否かを判定する。
Ｓ１５０で画像処理テスト手段１７０により基本機能確認基準２１０を満たしていると判定された場合（Ｓ１５０でＹｅｓの場合）、Ｓ１７０で複合機１が基本動作の確認を行う処理を終了する。ここで、プラグイン１９０がプラグイン管理部２２に未登録の状態であれば、Ｓ１５０で画像処理テスト手段１７０による上記判定がされた後、プラグイン登録手段１１０が、追加すべきプラグイン１９０をプラグイン管理部２２へ登録し、Ｓ１７０の処理へ移行する形態としても良い。
【００６５】
Ｓ１５０で画像処理テスト手段１７０により基本機能確認基準２１０を満たしていないと判定された場合（Ｓ１５０でＮｏの場合）、Ｓ１６０でプラグイン削除手段１４０が、プラグイン１９０を記憶装置８３又はＭＥＭ−Ｐ８１から削除し、必要であれば、プラグイン管理部２２からも登録を削除し、Ｓ１７０で複合機１が基本動作の確認を行う処理を終了する。
上記のような処理を行うことで、機能拡張をした後でも、複合機１の基本性能が落ちていないこと（確保できていること）を確認することができる。
【００６６】
（３）複合機１によるプラグインテストテーブル２００を更新する処理について
図１２を用いて、複合機１によるプラグインテストテーブル２００を更新する処理について説明する。図１２は、複合機１によるプラグインテストテーブル２００を更新する処理の一例を示すフローチャートである。
Ｓ２１０で複合機１が、プラグインテストテーブル２００を更新する処理を開始する。当該処理の開始は、ユーザによる処理開始操作をローカルＵＩ部１２が受け付けることで開始する形態としても良く、一定の時間間隔で自動的に処理が開始される形態としても良い。
【００６７】
Ｓ２２０でテスト内容変更手段１６０が、ダウンロードサーバ３００から、プラグインテストテーブル２００を取得（ダウンロード）し、Ｓ２３０で当該プラグインテストテーブル２００を記憶装置８３に記憶（登録）する。このとき、従来の（古い）プラグインテストテーブル２００は削除される（新しいプラグインテストテーブル２００を上書き保存する）形態としても良い。Ｓ２２０におけるテスト内容変更手段１６０による処理は、アプリケーションロジック層３０のビルトインテスト３４を再インストールする処理に該当する。
Ｓ２４０で複合機１が、プラグインテストテーブル２００を更新する処理を終了する。
上記のように、製品が市場に出た後であっても、テスト内容を適宜変更することで、機能拡張プラグインに関するテストを適切に行うことができる。
【００６８】
＜第２の実施例＞
図１３、図１４で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリを複数保持し、プラグインテストを実施する専用のＣＰＵ・メモリを有することを特徴とする。これにより、プラグインテストをすぐに実施することができる。
【００６９】
また、図１５−２０で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリを複数保持し、使用されていないＣＰＵ・メモリを検索し、プラグインテストを実施することを特徴とする。こうすることにより、リソースを最大限利用できる。
【００７０】
さらに、図１５−２０で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリのどちらか一方のみ複数保持し、プラグインテストを実施することを特徴とする。こうすることにより、コスト削減を図ることができる。
【００７１】
図２１で示すように、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、一組のＣＰＵ・メモリで行う予定となっている処理を別のＣＰＵ・メモリに委譲させ、プラグインテストを実施するためのＣＰＵ・メモリを確保することを特徴とする。こうすることにより、リソースを最大限利用でき、また、テストもすぐに実施することができる。
【００７２】
ここで、図１９−２１のフローチャートの動作主体は、図１３中のスケジューラである。また、図２１において、ジョブが終わったことの検知方法については、例えば、作像装置９０やＦＣＵ８８から終了通知がＣＰＵに通知され、使ったデバイス全てから終了通知が来た場合にジョブ終了を検知する形態としても良い。
【００７３】
図２２で示すように、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、新規画像処理のジョブが実行される時に、実行中のプラグインテストを中断させ、画像処理のジョブを実施し、ジョブ終了後プラグインテストを再開させることを特徴とする。こうすることにより、ジョブを優先させることができる。つまり、ユーザの要求により詳細に応えることができる。
【００７４】
また、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、プラグイン追加時に画像処理装置１が行っている画像処理のジョブを中断させ、プラグインテストを実施し、プラグインテスト終了後ジョブを再開させることを特徴とする。こうすることにより、テストを優先させることができる。つまり、ユーザの要求により詳細に応えることができる。
【００７５】
従来、自動でテストを行うことにより、本体１に負荷がかかってしまうため、画像処理装置１の性能に影響が発生していたが、上記のように第２の実施例においては、画像処理装置１の性能を低下させずに自動でテストを行うことができる。
【００７６】
＜第３の実施例＞
図２３、２４で示すように、第３の実施例においては、サーバ３００と画像処理装置１とを直接接続する形態としても良く、サーバ３００をユーザが構築したＬＡＮ内に設置する形態としても良く、また、サーバ３００を画像処理装置１の提供元のＬＡＮ内に設置する形態としても良い。こうすることにより、セキュリティの向上を図ることができたり、テスト項目を常に最新にすることができる。また、問題が発生したときの対処を素早く取ることができる。
【００７７】
そして、図２５、２６、２７で示すように、第３の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、サーバ３００に本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、追加されたプラグイン情報、本体の使用状況、テスト項目を送る手段と、サーバ３００でテストされた結果を受け取る手段と、テスト結果を判断する手段を有することを特徴とする。こうすることにより、本体１に負担を全く掛けずにテストを実施することができる。
【００７８】
また、図２５、２７、２８で示すように、第３の実施例における画像処理装置１では、ユーザがプラグイン追加を希望した際に、プラグインを本体１にサーバから取得する前に、サーバ３００に本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、追加希望されたプラグイン情報、本体１の使用状況を送り、サーバ３００でテストを実施し、その結果によってダウンロードを開始することを特徴とする。こうすることにより、テスト失敗時のダウンロードの時間を削減することができる。
【００７９】
さらに、図２９で示すように、第３の実施例における画像処理装置１では、サーバ３００で実施するテストを、ソフトエミュレーション環境によって実施することを特徴とする。こうすることにより、コスト削減を図ることができる。
【００８０】
図３０、３１で示すように、第３の実施例における画像処理装置１では、定期的にサーバに本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、本体１の使用状況を送信しておき、毎日定期的にサーバ３００でプラグインに対してテストを行い、ダウンロード可能なプラグインを選定しておくことを特徴とする。こうすることにより、ユーザの手間が減り、ユーザが選択した後のテスト失敗がなくなる。
【００８１】
従来、自動でテストを行うことにより、本体１に負荷がかかってしまうため、画像処理装置１の性能に影響が発生していたが、上記のように第３の実施例においては、画像処理装置１の性能を低下させずに自動でテストを行うことができる。
【００８２】
（総括）
本発明では、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
以上、本発明の実施の形態について詳述したが、本発明は係る特定の実施の形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲において、種々の変形・変更が可能である。
【符号の説明】
【００８３】
１ 複合機（画像処理装置）
１２ ローカルＵＩ部
２２ プラグイン管理部
３０ アプリケーションロジック層
３１ コピーアクティビティ
３２ プリンタアクティビティ
８１ 記憶装置（ＭＥＭ−Ｐ）
８３ 記憶装置（ＨＤＤ）
３０１ 読取フィルタ
３１１ 文書加工フィルタ
３２１ 印刷フィルタ
１１０ プラグイン登録手段
１２０ テスト内容抽出手段
１３０ プラグインテスト手段
１４０ プラグイン削除手段
１５０ テスト実行選択手段
１６０ テスト内容変更手段
１７０ 画像処理テスト手段
１８０ 画像処理手段
１９０ プラグイン
２００ プラグインテストテーブル
２１０ 基本機能確認基準
３００ ダウンロードサーバ
【先行技術文献】
【特許文献】
【００８４】
【特許文献１】特開２００５−０９２２７５号公報
【技術分野】
【０００１】
本発明は、画像処理に関するアプリケーションの機能を拡張するためのプラグインを追加する際に、当該プラグインが備えるインタフェースの仕様について適切か否かの判定を行う技術に関する。
【背景技術】
【０００２】
近年、パーソナルコンピュータおよびワークステーションなどの装置だけでなく、様々な装置に高性能なＡＰＩ（Application Program Interface）を有するＯＳ（Operating System）が採用されている。例えば、コピー、プリンタ、スキャナ、ＦＡＸ、またはドキュメントサーバなどの機能を集約した複合機（ＭＦＰ）などの装置にも、このようなＯＳが採用されている。
ＡＰＩの性能が低かった頃は、これらの装置の機能拡張を行い、または応用的な処理を行うためのプログラムを作成することは難しく、手間が掛かった。装置の構造を理解し、機械語などの言語を用いてプログラムをコーディングしなければならなかったからである。
【０００３】
しかし、高性能なＡＰＩが採用されるようになってからは、予め用意されているＡＰＩ関数をコールするだけで種々の機能を呼び出して処理を行うことができるようになった。これにより、従来よりも容易にプログラミングが行われるようになった。
したがって、今後、これらの装置の機能拡張を行いまたは応用的な処理を行うためのプログラム、およびこれらのプログラムを作成し提供するサービス提供者が増えると予測される。このことは、ユーザにとって、装置をより便利に使用することができるようになるという利点があるが、その一方で、不正な処理を実行しユーザに損害をもたらす欠陥のあるプログラムや悪意のあるプログラムが流通しやすくなるという問題点もある。
【０００４】
そこで、上記装置でプログラムを実行する際に、何らかのチェックを行う必要があるものと考えられるが、特許文献１では、ＭＦＰにプログラムを追加する際に、そのプログラムの作成者の情報に基づいて当該プログラムの実行制御を行う技術が公開されている。この技術においては、プログラム実行時に、該プログラムの作成者にアクセス許可されていないＡＰＩ呼び出しを行うと、そのＡＰＩ呼び出しが禁止される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、上記技術においては、プログラムの作成者情報を登録する必要があり、未登録の作成者により作成されたプログラムには適用できないという問題点がある。
また、上記技術においては、プログラムの作成者が正当か否かに基づいてプログラムの実行制御はできるものの、装置に追加するプログラム自体に問題が無いか否かをチェックすることができないという問題点がある。
【０００６】
そこで、本発明では、上記問題点に鑑み、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
開示の画像処理装置の一形態では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、対応するアプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする。
【発明の効果】
【０００８】
本発明では、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施の形態に係る複合機のソフトウェア構成例を説明するための図である。
【図２】本実施の形態に係るパイプ＆フィルタの概念を説明するための図である。
【図３】本実施の形態に係るフィルタの構成要素を説明するための図である。
【図４】本実施の形態に係る複合機における各機能を実現するためのフィルタの組み合わせの例を示す図である。
【図５】本実施の形態に係る複合機の動作原理を説明するための図である。
【図６】本実施の形態に係る機能拡張プラグインを追加する前の処理例を説明するためのシーケンス図である。
【図７】本実施の形態に係る機能拡張プラグインを追加した後の処理例を説明するためのシーケンス図である。
【図８】本実施の形態に係る機能拡張プラグインを追加する際に行うテスト項目例を説明するための図である。
【図９】本実施の形態に係る複合機のハードウェア構成の一例を示す図である。
【図１０】本実施の形態に係る複合機に機能拡張プラグインを追加する際の処理例を示すフローチャートである。
【図１１】本実施の形態に係る複合機に機能拡張プラグインを追加する際の処理例を示すフローチャートである。
【図１２】本実施の形態に係る機能拡張プラグインに対するテスト内容を変更する処理例を示すフローチャートである。
【図１３】画像処理装置がＣＰＵとメモリを２組ずつ有する構成を示す図である。
【図１４】画像処理装置が有する１組のＣＰＵとメモリをテスト専用にする構成を示す図である。
【図１５】画像処理装置が有するＣＰＵを１つにした構成を示す図である。
【図１６】画像処理装置が有するメモリを１つにした構成を示す図である。
【図１７】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（片方が終わるまで待つ場合）を示す図である。
【図１８】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（一方を止めて委譲する場合）を示す図である。
【図１９】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（片方が終わるまで待つ場合）のフローチャートである。
【図２０】画像処理装置が有するＣＰＵの両方を通常でも使用する構成（一方を止めて委譲する場合）のフローチャートである。
【図２１】ジョブが投入された場合、テストを中断／再開する場合のフローチャートである。
【図２２】ジョブが投入された場合、テストを中断／再開する場合の構成を示す図である。
【図２３】テストサーバと画像処理装置との接続例を示す図である。
【図２４】テストサーバと画像処理装置との接続例を示す図である。
【図２５】テスト実施部をプリントサーバと別構成にした場合の構成を示す図である。
【図２６】テスト実施をプラグインのインストール後に行う場合のフローチャートを示す図である。
【図２７】テストサーバに格納されている情報の一例を示す図である。
【図２８】テスト実施をプラグインのインストール前に行う場合のフローチャートを示す図である。
【図２９】テスト実施部をプリントサーバ内でソフトエミュレーションした場合の構成を示す図である。
【図３０】プラグイン可能なインストール一覧を更新する場合のフローチャートを示す図である。
【図３１】テスト項目を特定する場合のフローチャートを示す図である。
【発明を実施するための形態】
【００１０】
図面を参照しながら、本発明を実施するための最良の形態について説明する。
（本発明に係る画像処理装置のソフトウェア構成）
図１は、本発明の実施の形態における複合機のソフトウェア構成例を示す図である。ここで、複合機とは、プリンタ、コピー、スキャナ、又はＦＡＸ等の複数の機能を一台の筐体において実現する画像処理装置をいう。
【００１１】
図１で示すように、複合機１におけるソフトウェアは、ユーザインタフェース層１０、コントロール層２０、アプリケーションロジック層３０、デバイスサービス層４０及びデバイス制御層５０より構成される。なお、図中における各層の上下関係は、層間の呼び出し関係に基づいている。すなわち、基本的に図中において上にある層が下の層を呼び出す。
【００１２】
ユーザインタフェース層１０は、機能（例えば、コピー、印刷、スキャン、ＦＡＸ送信）の実行要求を受け付けるための機能が実装されている部分であり、例えば、通信サーバ部１１及びローカルＵＩ（User Interface）部１２が含まれる。通信サーバ部１１は、例えば、非図示のクライアントＰＣ（Personal Computer）からネットワーク経由で要求を受け付ける。ローカルＵＩ部１２は、例えば、非図示のオペレーションパネルを介して入力される要求を受け付ける。ユーザインタフェース層１０において受け付けられた要求は、コントロール層２０に伝えられる。
【００１３】
コントロール層２０は、要求された機能を実現するための処理を制御するための機能が実装されている部分である。具体的には、要求された機能に応じて、アプリケーションロジック層３０における各フィルタを接続し、接続されたフィルタに基づいて機能の実行を制御する。
コントロール層２０は、例えば、リクエスト管理部２１、プラグイン管理部２２を有する。リクエスト管理部２１は、要求されたジョブに応じて、アプリケーションロジック層３０が有する各フィルタを接続し、接続されたフィルタに基づいてジョブの実行を制御する。プラグイン管理部２２は、複合機１に実装されるジョブを実行するための手段等の物理的なアドレスと、手段の動作とを管理する。なお、本実施の形態においては、プラグイン管理部２２が管理する「プラグイン」とは、複合機１が有する基本機能に対して新たに追加される機能に対応するプログラム又はデバイス、及び、複合機１が有する基本機能に対応するプログラム又はデバイスを含む。すなわち、プラグイン管理部２２は、複合機１が有する基本機能及び追加機能に対応するプログラム又はデバイス等の物理的なアドレス、及び、それらの動作を管理する手段である。
なお、本実施の形態において「複合機１の機能」とは、複合機１がユーザに対して提供する一つのまとまった単位（要求が入力されて最終的な出力が得られるまで）のサービスと同義であり、ソフトウェア的には一つのまとまった単位のサービスを提供するアプリケーションと同義である。
【００１４】
アプリケーションロジック層３０は、それぞれが複合機１において提供される機能の一部を実現する部品群が実装されている部分である。すなわち、アプリケーションロジック層３０における部品を組み合わせることにより一つの機能が実現される。本実施の形態では、各部品を「フィルタ」と呼ぶ。これは、複合機１のソフトウェアアーキテクチャが「パイプ＆フィルタ」と呼ばれる考え方に基づくことによる。
【００１５】
図２は、パイプ＆フィルタの概念を示すための図である。図２においては、「Ｆ」はフィルタを示し、「Ｐ」はパイプを示す。図中に示されるように、各フィルタはパイプによって接続される。フィルタは、入力されたデータに対して変換を施し、その結果を出力する。パイプは、フィルタから出力されたデータを次のフィルタに伝達する。
【００１６】
すなわち、本実施の形態における複合機１では、各機能をドキュメント（データ）に対する「変換」の連続として捉える。複合機の各機能は、ドキュメントの入力、加工、及び出力によって構成されるものとして一般化することができる。そこで、「入力」、「加工」、及び「出力」を「変換」として捉え、一つの「変換」を実現するソフトウェア部品がフィルタとして構成される。入力を実現するフィルタを特に「入力フィルタ」という。また、加工を実現するフィルタを特に「加工フィルタ」という。更に、出力を実現するフィルタを特に「出力フィルタ」という。なお。各フィルタは独立しており、フィルタ間における依存関係（呼び出し関係）は基本的には存在しない。したがって、フィルタ単位で追加（インストール）又は削除（アンインストール）が可能とされている。
【００１７】
図１において、アプリケーションロジック層３０には、入力フィルタとして、読取フィルタ３０１、メール受信フィルタ３０２、ＦＡＸ受信フィルタ３０３、ＰＣ文書受信フィルタ３０４が含まれている。
読取フィルタ３０１は、スキャナによる画像データの読み取りを制御し、読み取られた画像データを出力する。メール受信フィルタ３０２は、電子メールを受信し、当該電子メールに含まれているデータを出力する。ＦＡＸ受信フィルタ３０３は、ＦＡＸ受信を制御し、受信されたデータを出力する。ＰＣ文書受信フィルタ３０４は、非図示のクライアントＰＣから印刷データを受信し、受信された印刷データを出力する。
【００１８】
図１において、アプリケーションロジック層３０には、加工フィルタとして、文書加工フィルタ３１１、文書変換フィルタ３１２が含まれている。
文書加工フィルタ３１１は、入力されたデータに所定の画像変換処理（集約、拡大、又は縮小等）を施し、出力する。文書変換フィルタ３１２は、レンダリング処理を実行する。すなわち、入力されたＰｏｓｔＳｃｒｉｐｔデータをビットマップデータに変換して出力する。
【００１９】
図１において、アプリケーションロジック層３０には、出力フィルタとして、印刷フィルタ３２１、メール送信フィルタ３２２、ＦＡＸ送信フィルタ３２３、ＰＣ文書送信フィルタ３２４が含まれている。
印刷フィルタ３２１は、入力されたデータをプロッタに出力（印刷）させる。メール送信フィルタ３２２は、入力されたデータを電子メールに添付して送信する。ＦＡＸ送信フィルタ３２３は、入力されたデータをＦＡＸ送信する。ＰＣ文書送信フィルタ３２４は、入力されたデータをクライアントＰＣに送信する。
【００２０】
また、アプリケーションロジック層３０は、ビルトインテスト３４を含む。ビルトインテスト３４は、上記で説明したフィルタ又はアクティビティの機能を拡張するプラグイン（プログラム）を複合機１に追加する際に、該プラグインの備えるインタフェース（Ｉ／Ｆ）が適切か否かをチェックする。また、ビルトインテスト３４は、後述するテスト内容抽出手段１２０及びプラグインテスト手段１３０に該当し、プラグインテストテーブル２００を含むものである。
【００２１】
デバイスサービス層４０は、アプリケーションロジック層３０における各フィルタから共通に利用される下位機能が実装されている部分であり、例えば、画像パイプ４１及びデータ管理部４２が含まれる。画像パイプ４１は、上述したパイプの機能を実現する。すなわち、或るフィルタからの出力データを次のフィルタに伝達する。データ管理部４２は、各種のデータベースを表現する。例えば、ユーザ情報が登録されたデータベースや、文書又は画像データ等が蓄積されるデータベース等が相当する。
【００２２】
デバイス制御層５０は、デバイス（ハードウェア）を制御するドライバと呼ばれるプログラムモジュール群が実装されている部分であり、例えば、スキャナ制御部５１、プロッタ制御部５２、メモリ制御部５３、電話回線制御部５４、及びネットワーク制御部５５が含まれる。各制御部は、当該制御部の名前に付けられているデバイスを制御する。
【００２３】
フィルタについて更に詳しく説明する。図３は、フィルタの構成要素を説明するための図である。図３に示されるように、各フィルタは、フィルタ設定用ＵＩ、フィルタロジック、フィルタ固有下位サービス及び永続記憶領域情報により構成される。
フィルタ設定用ＵＩは、フィルタの実行条件を設定させるための画面をオペレーションパネルに表示させるプログラムである。例えば、入力フィルタの一つである読取フィルタであれば、解像度、濃度、画像種別を設定する画面が相当する。なお、オペレーションパネルの表示がＨＴＭＬ（HyperText Markup Language）データや、スクリプトに基づいて行われ得ることに鑑みれば、フィルタ設定用ＵＩはＨＴＭＬデータやスクリプトであっても良い。
【００２４】
フィルタロジックは、フィルタの機能を実現するためのロジックが実装されたプログラムである。例えば、読取フィルタであれば、スキャナによる原稿読み取り制御のためのロジックが相当する。
フィルタ固有下位サービスは、フィルタロジックを実現するために必要な下位機能（ライブラリ）である。例えば、読取フィルタであれば、スキャナを制御するための機能が相当する。
永続記憶領域情報は、フィルタに対する設定情報（例えば、実行条件のデフォルト値）等、不揮発性メモリに保存する必要があるデータのスキーマ定義が相当する。当該スキーマ定義は、フィルタのインストール時にデータ管理部４２に登録される。
【００２５】
図４は、本実施の形態の複合機における各機能（アプリケーション）を実現するためのフィルタの組み合わせの例を示す図である。
例えば、コピー機能は、読取フィルタ３０１と印刷フィルタ３２１とを接続することにより実現される。読取フィルタ３０１によって、原稿から読み取られた画像データを印刷フィルタ３２１によって印刷すれば良いからである。なお、コピー機能に付随する、集約、拡大、縮小等の加工が要求された場合には、これらの加工を実現する文書加工フィルタ３１１が読取フィルタ３０１と印刷フィルタ３２１の間に挿入される。
【００２６】
プリンタ機能（クライアントPCからの印刷機能）は、ＰＣ文書受信フィルタ３０４と文書変換フィルタ３１２と印刷フィルタ３２１とを接続することにより実現される。スキャンｔｏ ｅｍａｉｌ機能（スキャンした画像データを電子メールで転送する機能）は、読取フィルタ３０１とメール送信フィルタ３２２とを接続することにより実現される。ＦＡＸ送信機能は、読取フィルタ３０１とＦＡＸ送信フィルタ３２３とを接続することにより実現される。ＦＡＸ受信機能は、ＦＡＸ受信フィルタ３０３と印刷フィルタ３２１とを接続することにより実現される。
【００２７】
また、アプリケーションロジック層３０は、コピーアクティビティ３１、プリンタアクティビティ３２、マルチ文書アクティビティ３３を含む。ここで、アクティビティとは、予め固定的に定義されたフィルタの組み合わせによって、一つの機能（複合機１がユーザに対して提供する一つのまとまった単位のサービス又はアプリケーション）を実現するソフトウェアである。コピーのように頻繁に利用する機能については、毎回フィルタの選択によってユーザが実行指示を行うのは煩雑であるため、予めフィルタの組み合わせを定義することで、この煩雑さを解消するために用意されるものである。
コピーアクティビティ３１は、読取フィルタ３０１と文書加工フィルタ３１１と印刷フィルタ３２１との組み合わせにより、コピー機能（コピーアプリケーション）を実現するアクティビティである。
プリンタアクティビティ３２は、ＰＣ文書受信フィルタ３０４と文書変換フィルタ３１２と印刷フィルタ３２１との組み合わせにより、印刷機能（プリンタアプリケーション）を実現するアクティビティである。
マルチ文書アクティビティ３３は、入力フィルタ、加工フィルタ、出力フィルタのそれぞれについて、自由な組み合わせが可能なアクティビティである。
なお、各アクティビティは独立しており、各アクティビティ間における依存関係（呼び出し関係）は基本的には存在せず、したがって、アクティビティ毎に追加（インストール）、削除（アンインストール）が可能である。
【００２８】
（本実施の形態に係る複合機１の動作原理）
図５を用いて、本発明の画像処理装置である複合機１の動作原理について説明する。図５は複合機１の動作原理を示した図である。
図５で示すように、複合機１は、プラグイン登録手段１１０、テスト内容抽出手段１２０、プラグインテスト手段１３０、プラグイン削除手段１４０、テスト実行選択手段１５０、テスト内容変更手段１６０、画像処理テスト手段１７０、画像処理手段１８０、記憶装置８３を有する。また、複合機１とダウンロードサーバ３００とは、通信ネットワークで接続されているものとし、該通信ネットワークは、有線通信ネットワークであっても無線通信ネットワークであっても良い。
【００２９】
画像処理手段１８０は、複合機１が行う一般的な画像処理を実行し、例えば、コピー処理、プリンタ処理、ＦＡＸ処理等を実行する。
【００３０】
記憶装置８３は、画像処理に係るアプリケーションの機能を拡張するためのプラグイン１９０、プラグイン１９０を追加する際のテスト内容を規定するプラグインテストテーブル２００、複合機１の基本性能を規定する基本機能確認基準２１０を保持している。
画像処理に係るアプリケーションは、上記説明におけるアプリケーションロジック層３０を構成する入力フィルタ（読取フィルタ３０１等）、加工フィルタ（文書加工フィルタ３１１等）、出力フィルタ（印刷フィルタ３２１等）、各アクティビティ３１、３２、３３、ビルトインテスト３４とする形態であっても良い。
【００３１】
図６、７を用いて、上記画像処理に係るアプリケーションを機能拡張するためのプラグイン１９０について説明することとし、ここでは、複合機１が有するスキャナ８９を用いて、３枚の原稿を読み取る処理を例にして説明を行う。この場合、追加するプラグイン１９０によって機能拡張されるアプリケーションは、読取フィルタ３０１となる。
図６で示すように、機能拡張プラグイン１９０を複合機１に追加する前の環境では、ローカルＵＩ部１２から受け付けられた要求「スキャン実行」は読取フィルタ３０１に伝達され、読取フィルタ３０１は当該要求に従いスキャナ８９に原稿を読み取らせる。そして、スキャナ８９は原稿を１枚読み取る毎に、スキャンを実行した旨の信号「スキャン実行イベント（進捗）」を読取フィルタ３０１に通知し、読取フィルタ３０１は当該信号をローカルＵＩ部１２へ通知する処理を行う。
【００３２】
一方、図７で示すように、機能拡張プラグインを複合機に追加した後の環境でも、ローカルＵＩ部１２から受け付けられた要求「スキャン実行」は読取フィルタ３０１に伝達され、読取フィルタ３０１は当該要求に従いスキャナ８９に原稿を読み取らせる。ただし、スキャナ８９が原稿を１枚読み取る毎に読取フィルタ３０１に通知する信号「スキャン実行イベント（進捗）」は、一旦機能拡張プラグイン１９０に通知され、当該通知をトリガーとして機能拡張プラグイン１９０による所定の処理が行われた後、読取フィルタ３０１は当該信号をローカルＵＩ部１２へ通知する。
ここで、機能拡張プラグイン１９０による所定の処理は、スキャナ８９が原稿を読み取った時刻や処理実行（ここでは、スキャン実行）を要求したユーザのＩＤなどの履歴情報を記録する処理（ログを残す処理）であっても良いし、機能拡張プラグイン１９０において予め定める特定のイベントが発生したと通知された場合に、スキャナ８９による原稿の読取処理を停止、再開、キャンセルさせる処理であっても良い。つまり、読取フィルタ３０１における処理に関連する処理であれば良い。
【００３３】
また、図８を用いて、プラグインテストテーブル２００について説明する。図８は、機能拡張のためのプラグインを複合機１に追加する際に、当該プラグインに対し確認すべき項目の一例であり、機能拡張の対象となるアプリケーション（図８では、フィルタ）毎に、必要なインタフェース（以後、Ｉ／Ｆ：ＩｎｔｅｒＦａｃｅ）、当該Ｉ／Ｆに関する引数の個数、及び当該Ｉ／Ｆに関する引数の型が定められている。例えば、図７で説明した例のように、読取フィルタ３０１の機能を拡張するプラグイン１９０を複合機１に追加する際に、追加するプラグイン１９０が備えるべきＩ／Ｆは「スキャンイベント受取」であり、当該Ｉ／Ｆ「スキャンイベント受取」に関する引数の個数は１つで、該Ｉ／Ｆ「スキャンイベント受取」に関する引数の型は「Ｏｂｊｅｃｔ型」であることを要求される。
【００３４】
ここで、プラグインテストテーブル２００において、必要なＩ／Ｆは１つであっても複数であっても良く、また、各Ｉ／Ｆに関する引数の個数は１つであっても複数であっても良い。さらに、各Ｉ／Ｆに関する引数の型は、Ｏｂｊｅｃｔ型であっても他の型であっても良い。
また、図８において、機能拡張される対象のアプリケーションをフィルタとしているが、該アプリケーションはアクティビティであっても良く、他のアプリケーションであっても良い。
【００３５】
また、基本機能確認基準２１０は、複合機１において画像処理を行った場合に、当該画像処理が最低限満足すべき基準であり、例えば、スキャナ８９で読み取られた画像品質やプロッタ９０で印刷された画像品質等に関する機能性基準、コピーやＦＡＸ等の画像処理に要する時間や当該画像処理に関するリソース消費量（メモリリーク、ＧＣ、ＵＩの応答時間等）に関する非機能性基準を含むものであっても良い。
【００３６】
プラグイン登録手段１１０は、ダウンロードサーバ３００から、画像処理に係るアプリケーションの機能を拡張するためのプラグイン１９０をダウンロード（取得）し、当該プラグイン１９０を記憶装置８３に記録する。
また、プラグイン登録手段１１０は、後述するプラグインテスト手段１３０の判定に基づいて、画像処理手段１８０による処理においてプラグイン１９０を利用できる状態にする。ここで、プラグイン１９０を利用できる状態とは、プラグイン管理部２２にプラグイン１９０が登録された状態である。一方で、プラグイン登録手段１１０は、テスト実行選択手段１５０の決定により、プラグインテスト手段１３０による処理が行われない場合についても、画像処理手段１８０による処理においてプラグイン１９０を利用できる状態にする。
【００３７】
テスト内容抽出手段１２０は、プラグイン登録手段１１０により取得されたプラグイン１９０がどのアプリケーション（フィルタ、アクティビティ等）に対する機能拡張プラグインなのかを判断し、この判断結果と図８で示すようなプラグインテーブル２００とを照合し、当該プラグイン１９０に関して確認すべき項目を抽出する。例えば、プラグイン登録手段１１０により取得されたプラグイン１９０が読取フィルタ３０１に対するプラグインであると判断した場合、テスト内容抽出手段１９０は、図８で示すプラグインテストテーブル２００において読取フィルタ３０１を検索し、読取フィルタ３０１に必要なＩ／Ｆは「スキャンイベント受取」であり、「スキャンイベント受取」に必要な引数の個数は「１つ」であり、「スキャンイベント受取」に必要な引数の型は「Ｏｂｊｅｃｔ型」であるという確認すべき項目を抽出する。
【００３８】
プラグインテスト手段１３０は、テスト内容抽出手段１２０により抽出される確認項目に基づいて、プラグイン１９０の備えるＩ／Ｆの仕様を確認する。具体的には、プラグイン１９０の備えるＩ／Ｆに関して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを備えているか否か、テスト内容抽出手段１２０により抽出される引数の個数と一致するか否か、テスト内抽出手段１２０により抽出される引数の型と一致するか否かについて、それぞれ判定を行う。例えば、プラグインテスト手段１３０は、プラグイン１９０（実行オブジェクト）に対して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを指定し、リフレクション機能を使用して取得を行い、プラグイン１９０が必要なＩ／Ｆを有するか否かを判定する。そして、プラグインテスト手段１３０は、上記で取得したＩ／Ｆに対して、引数の数を取得し、テスト内容抽出手段１２０により抽出される引数の数と一致するか否かを判定する。さらに、プラグインテスト手段１３０は、上記で取得したＩ／Ｆに対して、引数の型を取得し、テスト内容抽出手段１２０により抽出される引数の型と一致するか否かを判定する。このようにして、適切なＩ／Ｆの未実装を防止し、プログラムをバーションアップする場面で起こりがちなＩ／Ｆの不整合等による複合機１の動作不良を防止することができる。
【００３９】
また、プラグインテスト手段１３０は、プラグイン１９０の備えるＩ／Ｆに関して、応答時間を計測し、該応答時間が所定の時間内であるか否かを判定する。具体的には、プラグインテスト手段１３０は、プラグイン１９０（実行オブジェクト）に対して、テスト内容抽出手段１２０により抽出される必要なＩ／Ｆを指定し、リフレクション機能を使用して取得を行った後、該取得したＩ／Ｆの応答時間を計測し、この計測した応答時間が所定の時間内であるか否かを判定する。ここで、Ｉ／Ｆの応答時間は、該Ｉ／Ｆに何らかの問合せを行った時刻と、該問合せに対して何らかの応答があった時刻との時刻差である。障害として発見することが難しいタイムアウトによるスレッドの不正処理等を防止することができる。
【００４０】
プラグイン削除手段１４０は、プラグインテスト手段１３０により、プラグイン１９０の備えるＩ／Ｆの仕様と、テスト内容抽出手段１２０により抽出される仕様とが一致しないと判定された場合、又は、該Ｉ／Ｆの応答時間が所定の時間内でないと判定された場合に、プラグイン１９０を記憶装置８３から削除する。未知なコンポーネントが正しい拡張ルールに従っているかを、プラグイン追加時にリアルタイムで確認することで、より信頼性の高いものしか追加させない堅牢なシステムを構築することができる。
【００４１】
テスト実行選択手段１５０は、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するか否かに関するユーザの選択を受け付け、該選択に基づいて、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するか否かを決定する。すなわち、テスト内容抽出手段１２０及びプラグインテスト手段１３０による処理を実行するとユーザが選択すればこれらの手段による処理が実行され、反対に、実行しないとユーザが選択すればこれらの手段による処理は実行されない。テスト実行の有無に関する選択をユーザに委ね、不要なテストを行わないことで、テスト実行時間の削減することができ、または、記憶装置の資源を有効活用することができる。
【００４２】
テスト内容変更手段１６０は、ダウンロードサーバ３００から、図８で示すようなプラグインテストテーブル２００をダウンロード（取得）し、該プラグインテストテーブル２００を記憶装置８３に記録する。このとき、従来のプラグインテーブル２００は、上書き、削除される形態としても良い。テスト内容変更手段１６０による処理は、アプリケーションロジック層３０のビルトインテスト３４を再インストールする処理に該当する。
こうすることで、製品が市場に出た後であっても、テスト内容を適宜変更することで、機能拡張プラグインに関するテストを適切に行うことができる。
【００４３】
画像処理テスト手段１７０は、プラグイン１９０により機能拡張されたアプリケーションを含む画像処理が、基本機能確認基準２１０を満たすか否かを判定する。機能拡張をした後でも、複合機１の基本性能が落ちていないこと（複合機１の基本性能が確保できていること）を確認することができる。
【００４４】
以下では、上記で説明した複合機１の動作原理に基づき、複合機１による処理の流れを説明する。ここでは、図７で示すように、読取フィルタ３０１の機能を拡張するためのプラグイン１９０を追加する場合の処理について説明する。
はじめに、プラグイン登録手段１１０が、ダウンロードサーバ３００から、プラグイン１９０をダウンロードし、記憶装置８３に記憶する。そして、テスト実行選択手段１５０が、プラグイン１９０に関するテストを実行する旨のユーザの選択を受け付けると、テスト内容抽出手段１２０が、プラグイン１９０が読取フィルタ３０１の機能拡張を行うものであることを検出し、プラグインテストテーブル２００から読取フィルタ３０１に対応する確認項目を抽出する。
【００４５】
そして、プラグインテスト手段１３０が、プラグイン１９０の備えるＩ／Ｆの仕様と、テスト内容抽出手段１２０により抽出された仕様とが一致するか否かを確認、判定し、両者の全ての仕様が一致すると判定した場合に、プラグイン登録手段１１０が、プラグイン１９０を利用できる状態にする。一方、プラグインテスト手段１３０が、両者の仕様に関し１項目でも一致しないと判定した場合には、プラグイン削除手段１４０が、プラグイン１９０を記憶装置８３から削除する。
【００４６】
また、プラグイン登録手段１１０が、プラグイン１９０を利用できる状態にした後、画像処理手段１８０が、プラグイン１９０を利用した画像処理（例えば、原稿をスキャナ８９で読み取り、プロッタ９０から紙出力するコピー処理）を実行し、画像処理テスト手段１７０が、該コピー処理と、該コピー処理に関する基本機能確認基準２１０とを比較して、該コピー処理が基本機能確認基準２１０をクリアしているか否かを判定する。そして、画像処理テスト手段１７０により基本機能確認基準２１０をクリアしていないと判定された場合に、プラグイン削除手段１４０が、プラグイン１９０を記憶装置８３から削除する。
【００４７】
そして、テスト内容変更手段１６０が、ダウンロードサーバ３００から、プラグインテストテーブル２００を適宜ダウンロードし、該プラグインテストテーブル２００を更新する。
上記のような処理を行うことで、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
【００４８】
（本実施の形態に係る複合機のハードウェア構成）
図９を用いて、本発明の画像処理装置である複合機１のハードウェアの構成例を説明する。図９は、本発明の実施の形態における複合機１のハードウェア構成の一例を示す図である。
複合機１のハードウェアとしては、コントローラ８０と、オペレーションパネル８７、ファクシミリコントロールユニット（ＦＣＵ：Facsimile Control Unit）８８と、撮像部８９と、印刷部９０が存在する。
【００４９】
コントローラ８０は、ＣＰＵ（Central Processing Unit）８４、ＡＳＩＣ（Application Specific Integrated Circuit）８６、ＮＢ（North Bridge）８５、ＳＢ（South Bridge）９１、ＭＥＭ−Ｐ８１、ＭＥＭ−Ｃ８２、ＨＤＤ（ハードディスクドライブ）８３、メモリカードスロット９６、ネットワークインタフェースコントローラ（ＮＩＣ：Network Interface Controller）９２、ＵＳＢ（Universal Serial Bus）デバイス９３、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc.）１３９４デバイス９４、セントロニクスデバイス９５により構成される。
【００５０】
ＣＰＵ８４は、種々の情報処理用のＩＣ（Integrated Circuit）である。ＡＳＩＣ８６は、種々の画像処理用のＩＣである。ＮＢ８５は、コントローラのノースブリッジである。ＳＢ９１は、コントローラのサウスブリッジである。ＭＥＭ−Ｐ８１は、複合機１のシステムメモリである。ＭＥＭ−Ｃ８２は、複合機１のローカルメモリである。ＨＤＤ８３は、複合機１のストレージである。メモリカードスロット９６は、メモリカード９７をセットするためのスロットである。ＮＩＣ９２は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス９３は、ＵＳＢ規格の接続端子を提供するためのデバイスである。セントロニクスデバイス９５は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル８７は、オペレータが複合機１に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１から出力を得るためのハードウェア（表示部）である。
【００５１】
なお、本発明に係る複合機１のソフトウェアは、例えば、ＭＥＭ−Ｃ８２に格納され、ＣＰＵ８４によって処理されることにより、その機能を複合機１に実行させる。
【００５２】
（本発明の複合機１による処理例）
＜第１の実施例＞
従来、自動テストを行うことにより、複合機１本体に負荷が掛かってしまうため、複合機１の性能に影響が発生するが、第１の実施例においては、自動でテストを行いながらも複合機１の性能を低下させないようにする。
【００５３】
（１）複合機１によるプラグイン追加処理について
図１０を用いて、プラグインを追加する際の、複合機１による処理例について説明する。図１０は、プラグインを追加する際の、複合機１による処理の一例を示すフローチャートである。
ここでは、図７で示すような読取フィルタ３０１に関するプラグイン１９０を追加する際の処理について説明することとし、図８で示すプラグインテストテーブル２００に従って、プラグイン１９０の備えるＩ／Ｆに関するテストを行う。
【００５４】
Ｓ１０で複合機１がプラグイン追加時の処理を開始する。当該処理の開始は、ユーザによるプラグイン追加操作をローカルＵＩ部１２が受け付けたことで開始する形態としても良い。
Ｓ２０でプラグイン登録手段１１０が、ダウンロードサーバ３００から、読取フィルタ３０１の機能を拡張するプラグイン１９０を取得（ダウンロード）し、当該プラグイン１９０をＨＤＤ８３に保存する。ここで、プラグイン登録手段１１０は、プラグイン１９０をＭＥＭ−Ｐ８１に保存する形態としても良い。
【００５５】
Ｓ３０でテスト実行選択手段１５０が、複合機１に追加するプラグイン１９０に関するテストを実行するか否かに関するユーザの選択に基づいて、テスト内容抽出手段１２０及びプラグインテスト手段１３０によるテストを実施するか否かについて決定する。
追加されるプラグインの適性を確認するテストを実施するか否かの選択をユーザに委ね、不要なテストを行わないことで、テスト実行時間を削減することができ、一方では、記憶装置のリソースを有効活用することができる。
【００５６】
Ｓ３０でテスト実行選択手段１５０が、プラグイン１９０に関するテストを実施すると決定した場合（Ｓ３０でＹｅｓの場合）、Ｓ４０でテスト内容抽出手段１２０が、プラグイン１９０がどのアプリケーションに関するプラグインであるかを判別し、該判別結果に基づいて、図８で示すプラグインテストテーブル２００から、プラグイン１９０の備えるＩ／Ｆが満たすべき仕様に関する情報を抽出する。Ｉ／Ｆが満たすべき仕様に関する情報は、必要なＩ／Ｆ、該Ｉ／Ｆの引数の数、該Ｉ／Ｆの引数の型に関する情報である。本処理例のように、複合機１に追加しようとするプラグイン１９０が読取フィルタ３０１に関するプラグインの場合、該プラグイン１９０のＩ／Ｆが満たすべき仕様は、「スキャンイベント受取」というＩ／Ｆを有し、該「スキャンイベント受取」の引数の数は１つであり、該「スキャンイベント受取」の引数の型は「Ｏｂｊｅｃｔ型」であることである。
【００５７】
Ｓ３０でテスト実行選択手段１５０が、プラグイン１９０に関するテストを実施しないと決定した場合（Ｓ３０でＮｏの場合）、Ｓ７０でプラグイン登録手段１１０が、プラグイン１９０を追加する処理を完了させる、つまり、プラグイン１９０をプラグイン管理部２２に登録し、画像処理手段１８０による処理において使用できるようにする。
【００５８】
Ｓ５０でプラグインテスト手段１３０が、テスト内容抽出手段１２０により抽出した仕様と、プラグイン１９０の備えるＩ／Ｆに関する仕様とを比較して、両者の仕様が一致するか否かを判定する。すなわち、プラグインテスト手段１３０は、プラグイン１９０の備えるＩ／Ｆが「スキャンイベント受取」であるか否か（プラグイン１９０は「スキャンイベント受取」という名称のＩ／Ｆを有するか否か）、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの引数の数は１つであるか否か、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの引数の型は「Ｏｂｊｅｃｔ型」であるか否かについて、確認し、判定を行う。
また、プラグインテスト手段１３０は、プラグイン１９０の有する「スキャンイベント受取」というＩ／Ｆの応答時間が所定の時間内であるか否かについても、確認し、判定を行う。該応答時間の測定には、タイマーを使用する。
この様なチェックを行うことで、適切なＩ／Ｆの未実装を防止し、プログラムをバーションアップする場面で起こりがちなＩ／Ｆの不整合等による複合機１の動作不良を防止することができる。また、障害として発見することが難しいタイムアウトによるスレッドの不正処理等についても防止することができる。
【００５９】
Ｓ６０でプラグインテスト手段１３０が、上記項目の全てについて一致する（要件を満たす）と判定した場合（Ｓ６０でＹｅｓの場合）、Ｓ７０でプラグイン登録手段１１０が、プラグイン１９０を追加する処理を完了させる、つまり、プラグイン１９０をプラグイン管理部２２に登録し、画像処理手段１８０による処理において使用できるようにする。
Ｓ６０でプラグインテスト手段１３０が、上記項目のうち１項目でも一致しない（要件を満たさない）と判定した場合（Ｓ６０でＮｏの場合）、Ｓ８０でプラグイン削除手段１４０が、プラグイン１９０を記憶装置８３又はＭＥＭ−Ｐ８１から削除する。
【００６０】
Ｓ９０で複合機１がプラグイン追加時の処理を終了する。以後、プラグイン１９０が追加され、プラグイン管理部２２に登録された場合には、画像処理手段１８０が、プラグイン１９０の追加された環境で、コピー処理、プリンタ処理、ＦＡＸ処理等を行い、他方、プラグイン１９０が削除された場合には、画像処理手段１８０が、プラグイン１９０の追加される前の環境で、コピー処理、プリンタ処理、ＦＡＸ処理等を行う。
このような処理を行うことで、未知なコンポーネントが正しい拡張ルールに従っているかを、プラグイン追加時にリアルタイムで確認することで、より信頼性の高いものしか追加させない堅牢なシステムとすることができる。
【００６１】
（２）複合機１の基本動作を確認する処理について
図１１を用いて、プラグイン１９０を追加する際の、複合機１の基本動作を確認する処理について説明する。図１１は、複合機１の基本動作を確認する処理の一例を示すフローチャートである。
ここでは、図７で示すような読取フィルタ３０１に関するプラグイン１９０を追加する際の処理について説明する。
【００６２】
Ｓ１１０で複合機１が基本動作の確認を行う処理を開始する。当該処理の開始は、ユーザによる当該処理開始操作をローカルＵＩ部１２が受け付けることで開始する形態としても良いし、ユーザの操作によらず、プラグイン１９０のダウンロード後又はプラグイン管理部２２への登録後、自動的に処理を開始する形態としても良い。
Ｓ１２０で画像処理手段１８０が、読取フィルタ３０１に関するプラグイン１９０を追加した環境で、コピー処理、ＦＡＸ処理等、機能拡張された読取フィルタ３０１を使用する処理を実行する。プラグイン１９０を追加したことに伴う、複合機１の基本性能への影響の有無を確認するためである。
【００６３】
Ｓ１３０で画像処理テスト手段１７０が、画像処理手段１８０により実行された画像処理に対応する基本機能確認基準２１０を取得する。ここで、基本機能確認基準２１０は、複合機１において画像処理を行った場合に、当該画像処理が最低限満足すべき基準であり、例えば、スキャナ８９で読み取られた画像品質やプロッタ９０で印刷された画像品質等に関する機能性基準と、コピーやＦＡＸ等の画像処理に要する時間や当該画像処理に関するリソース消費量（メモリリーク、ＧＣ、ＵＩの応答時間等）に関する非機能性基準とで構成される。
【００６４】
Ｓ１４０で画像処理テスト手段１７０が、画像処理手段１８０により実行された画像処理の結果と、当該画像処理に対応する基本機能確認基準２１０とを比較して、画像処理手段１８０により実行された画像処理の結果が基本機能確認基準２１０を満たしているか否かを判定する。
Ｓ１５０で画像処理テスト手段１７０により基本機能確認基準２１０を満たしていると判定された場合（Ｓ１５０でＹｅｓの場合）、Ｓ１７０で複合機１が基本動作の確認を行う処理を終了する。ここで、プラグイン１９０がプラグイン管理部２２に未登録の状態であれば、Ｓ１５０で画像処理テスト手段１７０による上記判定がされた後、プラグイン登録手段１１０が、追加すべきプラグイン１９０をプラグイン管理部２２へ登録し、Ｓ１７０の処理へ移行する形態としても良い。
【００６５】
Ｓ１５０で画像処理テスト手段１７０により基本機能確認基準２１０を満たしていないと判定された場合（Ｓ１５０でＮｏの場合）、Ｓ１６０でプラグイン削除手段１４０が、プラグイン１９０を記憶装置８３又はＭＥＭ−Ｐ８１から削除し、必要であれば、プラグイン管理部２２からも登録を削除し、Ｓ１７０で複合機１が基本動作の確認を行う処理を終了する。
上記のような処理を行うことで、機能拡張をした後でも、複合機１の基本性能が落ちていないこと（確保できていること）を確認することができる。
【００６６】
（３）複合機１によるプラグインテストテーブル２００を更新する処理について
図１２を用いて、複合機１によるプラグインテストテーブル２００を更新する処理について説明する。図１２は、複合機１によるプラグインテストテーブル２００を更新する処理の一例を示すフローチャートである。
Ｓ２１０で複合機１が、プラグインテストテーブル２００を更新する処理を開始する。当該処理の開始は、ユーザによる処理開始操作をローカルＵＩ部１２が受け付けることで開始する形態としても良く、一定の時間間隔で自動的に処理が開始される形態としても良い。
【００６７】
Ｓ２２０でテスト内容変更手段１６０が、ダウンロードサーバ３００から、プラグインテストテーブル２００を取得（ダウンロード）し、Ｓ２３０で当該プラグインテストテーブル２００を記憶装置８３に記憶（登録）する。このとき、従来の（古い）プラグインテストテーブル２００は削除される（新しいプラグインテストテーブル２００を上書き保存する）形態としても良い。Ｓ２２０におけるテスト内容変更手段１６０による処理は、アプリケーションロジック層３０のビルトインテスト３４を再インストールする処理に該当する。
Ｓ２４０で複合機１が、プラグインテストテーブル２００を更新する処理を終了する。
上記のように、製品が市場に出た後であっても、テスト内容を適宜変更することで、機能拡張プラグインに関するテストを適切に行うことができる。
【００６８】
＜第２の実施例＞
図１３、図１４で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリを複数保持し、プラグインテストを実施する専用のＣＰＵ・メモリを有することを特徴とする。これにより、プラグインテストをすぐに実施することができる。
【００６９】
また、図１５−２０で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリを複数保持し、使用されていないＣＰＵ・メモリを検索し、プラグインテストを実施することを特徴とする。こうすることにより、リソースを最大限利用できる。
【００７０】
さらに、図１５−２０で示すように、第２の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、ＣＰＵ（演算装置）・メモリのどちらか一方のみ複数保持し、プラグインテストを実施することを特徴とする。こうすることにより、コスト削減を図ることができる。
【００７１】
図２１で示すように、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、一組のＣＰＵ・メモリで行う予定となっている処理を別のＣＰＵ・メモリに委譲させ、プラグインテストを実施するためのＣＰＵ・メモリを確保することを特徴とする。こうすることにより、リソースを最大限利用でき、また、テストもすぐに実施することができる。
【００７２】
ここで、図１９−２１のフローチャートの動作主体は、図１３中のスケジューラである。また、図２１において、ジョブが終わったことの検知方法については、例えば、作像装置９０やＦＣＵ８８から終了通知がＣＰＵに通知され、使ったデバイス全てから終了通知が来た場合にジョブ終了を検知する形態としても良い。
【００７３】
図２２で示すように、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、新規画像処理のジョブが実行される時に、実行中のプラグインテストを中断させ、画像処理のジョブを実施し、ジョブ終了後プラグインテストを再開させることを特徴とする。こうすることにより、ジョブを優先させることができる。つまり、ユーザの要求により詳細に応えることができる。
【００７４】
また、第２の実施例における画像処理装置１では、ＣＰＵ（演算装置）・メモリを複数保持し、プラグイン追加時に画像処理装置１が行っている画像処理のジョブを中断させ、プラグインテストを実施し、プラグインテスト終了後ジョブを再開させることを特徴とする。こうすることにより、テストを優先させることができる。つまり、ユーザの要求により詳細に応えることができる。
【００７５】
従来、自動でテストを行うことにより、本体１に負荷がかかってしまうため、画像処理装置１の性能に影響が発生していたが、上記のように第２の実施例においては、画像処理装置１の性能を低下させずに自動でテストを行うことができる。
【００７６】
＜第３の実施例＞
図２３、２４で示すように、第３の実施例においては、サーバ３００と画像処理装置１とを直接接続する形態としても良く、サーバ３００をユーザが構築したＬＡＮ内に設置する形態としても良く、また、サーバ３００を画像処理装置１の提供元のＬＡＮ内に設置する形態としても良い。こうすることにより、セキュリティの向上を図ることができたり、テスト項目を常に最新にすることができる。また、問題が発生したときの対処を素早く取ることができる。
【００７７】
そして、図２５、２６、２７で示すように、第３の実施例における画像処理装置１では、画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能となっており、前記プラグインが追加された後に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段１３０を有する画像処理装置１であって、サーバ３００に本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、追加されたプラグイン情報、本体の使用状況、テスト項目を送る手段と、サーバ３００でテストされた結果を受け取る手段と、テスト結果を判断する手段を有することを特徴とする。こうすることにより、本体１に負担を全く掛けずにテストを実施することができる。
【００７８】
また、図２５、２７、２８で示すように、第３の実施例における画像処理装置１では、ユーザがプラグイン追加を希望した際に、プラグインを本体１にサーバから取得する前に、サーバ３００に本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、追加希望されたプラグイン情報、本体１の使用状況を送り、サーバ３００でテストを実施し、その結果によってダウンロードを開始することを特徴とする。こうすることにより、テスト失敗時のダウンロードの時間を削減することができる。
【００７９】
さらに、図２９で示すように、第３の実施例における画像処理装置１では、サーバ３００で実施するテストを、ソフトエミュレーション環境によって実施することを特徴とする。こうすることにより、コスト削減を図ることができる。
【００８０】
図３０、３１で示すように、第３の実施例における画像処理装置１では、定期的にサーバに本体１の構成（プリントサーバ、ＡＳＩＣ、ＣＰＵ、メモリ）、本体１の使用状況を送信しておき、毎日定期的にサーバ３００でプラグインに対してテストを行い、ダウンロード可能なプラグインを選定しておくことを特徴とする。こうすることにより、ユーザの手間が減り、ユーザが選択した後のテスト失敗がなくなる。
【００８１】
従来、自動でテストを行うことにより、本体１に負荷がかかってしまうため、画像処理装置１の性能に影響が発生していたが、上記のように第３の実施例においては、画像処理装置１の性能を低下させずに自動でテストを行うことができる。
【００８２】
（総括）
本発明では、画像処理に係るアプリケーションの機能を拡張するプログラムを追加する際に、該プログラム自体に問題がないか否かの確認を行い、信頼性の高いプログラムのみを追加することにより、堅牢なシステムを有する画像処理装置を提供することができる。
以上、本発明の実施の形態について詳述したが、本発明は係る特定の実施の形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲において、種々の変形・変更が可能である。
【符号の説明】
【００８３】
１ 複合機（画像処理装置）
１２ ローカルＵＩ部
２２ プラグイン管理部
３０ アプリケーションロジック層
３１ コピーアクティビティ
３２ プリンタアクティビティ
８１ 記憶装置（ＭＥＭ−Ｐ）
８３ 記憶装置（ＨＤＤ）
３０１ 読取フィルタ
３１１ 文書加工フィルタ
３２１ 印刷フィルタ
１１０ プラグイン登録手段
１２０ テスト内容抽出手段
１３０ プラグインテスト手段
１４０ プラグイン削除手段
１５０ テスト実行選択手段
１６０ テスト内容変更手段
１７０ 画像処理テスト手段
１８０ 画像処理手段
１９０ プラグイン
２００ プラグインテストテーブル
２１０ 基本機能確認基準
３００ ダウンロードサーバ
【先行技術文献】
【特許文献】
【００８４】
【特許文献１】特開２００５−０９２２７５号公報
【特許請求の範囲】
【請求項１】
画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、
前記プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする画像処理装置。
【請求項２】
前記アプリケーションは、前記画像処理に係るジョブを構成する処理毎に設けられたフィルタであることを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースが、前記アプリケーションの要求する該インタフェースと一致するか否かの判定を行うことを特徴とする請求項１又は２に記載の画像処理装置。
【請求項４】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースに関する引数の数が、前記アプリケーションの要求する該インタフェースに関する引数の数と一致するか否かの判定を行うことを特徴とする請求項１乃至３の何れか一に記載の画像処理装置。
【請求項５】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースに関する引数の型が、前記アプリケーションの要求する該インタフェースに関する引数の型と一致するか否かの判定を行うことを特徴とする請求項１乃至４の何れか一に記載の画像処理装置。
【請求項６】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースの応答時間が、前記アプリケーションの要求する所定の時間内であるか否かの判定を行うことを特徴とする請求項１乃至５の何れか一に記載の画像処理装置。
【請求項７】
アプリケーションの要求する前記仕様を変更するテスト内容変更手段を有することを特徴とする請求項１乃至６の何れか一に記載の画像処理装置。
【請求項８】
前記プラグインを追加する際に、該プラグインを記憶する記憶装置と、
前記プラグインテスト手段により、前記プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致しないと判定された場合に、前記プラグインを前記記憶装置から削除するプラグイン削除手段と、を有することを特徴とする請求項１乃至７の何れか一に記載の画像処理装置。
【請求項９】
ユーザによる、前記プラグインテスト手段による処理を実行させるか否かの選択に基づいて、前記プラグインテスト手段による処理を実行するか否かを決定するテスト実行選択手段を有することを特徴とする請求項１乃至８の何れか一に記載の画像処理装置。
【請求項１０】
前記プラグインにより機能が拡張される前記アプリケーションを含む前記画像処理が、当該画像処理装置により定められる所定の基準を満たすか否かの判定を行う画像処理テスト手段を有することを特徴とする請求項１乃至９の何れか一に記載の画像処理装置。
【請求項１１】
前記プラグインテスト手段による処理専用のＣＰＵ（Central Processing Unit）及び記憶装置を有することを特徴とする請求項１乃至１０の何れか一に記載の画像処理装置。
【請求項１２】
複数のＣＰＵ及び記憶装置を有し、
前記複数のＣＰＵ及び記憶装置のうち、不使用の該ＣＰＵ及び記憶装置を検索し、検索した該ＣＰＵ及び記憶装置を用いて、前記プラグインテスト手段による処理を実施することを特徴とする請求項１乃至１１の何れか一に記載の画像処理装置。
【請求項１３】
前記画像処理に係るジョブを優先実行させるために、前記プラグインテスト手段による処理を中断させ、該画像処理に係るジョブの実行が終了した後、前記プラグインテスト手段による処理を再開することを特徴とする請求項２乃至１２の何れか一に記載の画像処理装置。
【請求項１４】
前記画像処理に係るジョブを実行中に前記プラグインが追加された場合、該画像処理に係るジョブを中断すると共に、前記プラグインテスト手段による処理を優先実行し、該プラグインテスト手段による処理が終了した後、該画像処理に係るジョブを再開することを特徴とする請求項２乃至１２の何れか一に記載の画像処理装置。
【請求項１５】
当該画像処理装置と接続されるサーバに対し、当該画像処理装置の構成、当該画像処理装置に追加された前記プラグイン情報、当該画像処理装置の使用状況及びテスト項目を通知する手段と、該サーバによるテスト結果を取得する手段とを有し、
前記プラグインテスト手段は、前記テスト結果を判定することを特徴とする請求項１乃至１４の何れか一に記載の画像処理装置。
【請求項１６】
前記サーバから当該画像処理装置に前記プラグインをダウンロードする場合、
前記サーバに対し、当該画像処理装置の構成、当該画像処理装置に追加される前記プラグイン情報、当該画像処理装置の使用状況及びテスト項目を通知する手段と、該サーバによるテスト結果を取得する手段とを有し、
前記プラグインテスト手段は前記テスト結果の判定を行い、該判定の結果に応じて前記プラグインのダウンロードを開始することを特徴とする請求項１乃至１５の何れか一に記載の画像処理装置。
【請求項１７】
前記サーバにおけるテストは、ソフトエミュレーション環境において実施されることを特徴とする請求項１５又は１６に記載の画像処理装置。
【請求項１】
画像処理に係るアプリケーションの機能を拡張するためのプラグインを追加可能な画像処理装置であって、
前記プラグインが追加される際に、該プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致するか否かの判定を行うプラグインテスト手段を有することを特徴とする画像処理装置。
【請求項２】
前記アプリケーションは、前記画像処理に係るジョブを構成する処理毎に設けられたフィルタであることを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースが、前記アプリケーションの要求する該インタフェースと一致するか否かの判定を行うことを特徴とする請求項１又は２に記載の画像処理装置。
【請求項４】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースに関する引数の数が、前記アプリケーションの要求する該インタフェースに関する引数の数と一致するか否かの判定を行うことを特徴とする請求項１乃至３の何れか一に記載の画像処理装置。
【請求項５】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースに関する引数の型が、前記アプリケーションの要求する該インタフェースに関する引数の型と一致するか否かの判定を行うことを特徴とする請求項１乃至４の何れか一に記載の画像処理装置。
【請求項６】
前記プラグインテスト手段は、前記プラグインの備えるインタフェースの応答時間が、前記アプリケーションの要求する所定の時間内であるか否かの判定を行うことを特徴とする請求項１乃至５の何れか一に記載の画像処理装置。
【請求項７】
アプリケーションの要求する前記仕様を変更するテスト内容変更手段を有することを特徴とする請求項１乃至６の何れか一に記載の画像処理装置。
【請求項８】
前記プラグインを追加する際に、該プラグインを記憶する記憶装置と、
前記プラグインテスト手段により、前記プラグインの備えるインタフェースに関する仕様が、前記アプリケーションの要求する該インタフェースに関する仕様と一致しないと判定された場合に、前記プラグインを前記記憶装置から削除するプラグイン削除手段と、を有することを特徴とする請求項１乃至７の何れか一に記載の画像処理装置。
【請求項９】
ユーザによる、前記プラグインテスト手段による処理を実行させるか否かの選択に基づいて、前記プラグインテスト手段による処理を実行するか否かを決定するテスト実行選択手段を有することを特徴とする請求項１乃至８の何れか一に記載の画像処理装置。
【請求項１０】
前記プラグインにより機能が拡張される前記アプリケーションを含む前記画像処理が、当該画像処理装置により定められる所定の基準を満たすか否かの判定を行う画像処理テスト手段を有することを特徴とする請求項１乃至９の何れか一に記載の画像処理装置。
【請求項１１】
前記プラグインテスト手段による処理専用のＣＰＵ（Central Processing Unit）及び記憶装置を有することを特徴とする請求項１乃至１０の何れか一に記載の画像処理装置。
【請求項１２】
複数のＣＰＵ及び記憶装置を有し、
前記複数のＣＰＵ及び記憶装置のうち、不使用の該ＣＰＵ及び記憶装置を検索し、検索した該ＣＰＵ及び記憶装置を用いて、前記プラグインテスト手段による処理を実施することを特徴とする請求項１乃至１１の何れか一に記載の画像処理装置。
【請求項１３】
前記画像処理に係るジョブを優先実行させるために、前記プラグインテスト手段による処理を中断させ、該画像処理に係るジョブの実行が終了した後、前記プラグインテスト手段による処理を再開することを特徴とする請求項２乃至１２の何れか一に記載の画像処理装置。
【請求項１４】
前記画像処理に係るジョブを実行中に前記プラグインが追加された場合、該画像処理に係るジョブを中断すると共に、前記プラグインテスト手段による処理を優先実行し、該プラグインテスト手段による処理が終了した後、該画像処理に係るジョブを再開することを特徴とする請求項２乃至１２の何れか一に記載の画像処理装置。
【請求項１５】
当該画像処理装置と接続されるサーバに対し、当該画像処理装置の構成、当該画像処理装置に追加された前記プラグイン情報、当該画像処理装置の使用状況及びテスト項目を通知する手段と、該サーバによるテスト結果を取得する手段とを有し、
前記プラグインテスト手段は、前記テスト結果を判定することを特徴とする請求項１乃至１４の何れか一に記載の画像処理装置。
【請求項１６】
前記サーバから当該画像処理装置に前記プラグインをダウンロードする場合、
前記サーバに対し、当該画像処理装置の構成、当該画像処理装置に追加される前記プラグイン情報、当該画像処理装置の使用状況及びテスト項目を通知する手段と、該サーバによるテスト結果を取得する手段とを有し、
前記プラグインテスト手段は前記テスト結果の判定を行い、該判定の結果に応じて前記プラグインのダウンロードを開始することを特徴とする請求項１乃至１５の何れか一に記載の画像処理装置。
【請求項１７】
前記サーバにおけるテストは、ソフトエミュレーション環境において実施されることを特徴とする請求項１５又は１６に記載の画像処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１０−１６７９７（Ｐ２０１０−１６７９７Ａ）
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００９−５５６９９（Ｐ２００９−５５６９９）
【出願日】平成２１年３月９日（２００９．３．９）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願日】平成２１年３月９日（２００９．３．９）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]