JP7080061B2 - 画像処理装置 - Google Patents

Description

本発明は、画像処理装置に関するものである。

画像形成装置、及び情報処理装置においては、装置内のソフトウェアフレームワークに、プラグインアプリケーション（以下では、アプリケーションをアプリと略記する。）をアドオンすることによって、後から機能を追加することができる。そのような方法を採用することによって、装置内の既存のソースコードを極力修正することなく、装置への機能追加が可能になる。追加した機能を利用する際は、機能の要求元モジュールが、ソフトウェアフレームワークに対して、その機能に対応したプラグインアプリを指定した上で、実行要求を通知する。ソフトウェアフレームワークは、その要求に従い、指定されたプラグインアプリを実行する。

特許文献１は、プラグインアプリがアドオンされた画像処理装置のＵＩ上にＷｅｂページを表示し、ユーザによってＷｅｂページの該当箇所が選択されると、当該箇所に紐づいたスクリプトを実行し、対応するプラグインアプリを呼び出す技術を提案している。

特開２０１２－１６２０４４号公報

しかしながら、上記従来技術には以下に記載する課題がある。追加した機能を利用する際に、機能の要求元モジュールは、適切なプラグインアプリを選択する必要がある。上記従来技術では、例えば、他の情報処理装置に、どのプラグインアプリを利用すべきか問い合わせた上で、その回答に従って選択している。この時、問い合わせる情報処理装置が存在しない場合は、機能の要求元モジュール自身が、どのプラグインアプリを利用すべきか判断し、選択を行う必要がある。ここで、誤ったプラグインを選択した場合、意図しない処理を実行してしまう虞がある。また、ＵＩ上のＷｅｂページに表示される画面等の選択（操作）可能箇所にプラグインアプリ等を紐づけて登録することは、製品の設計開発を行う中で、画面構成や仕様に何らかの制約が加わり、設計の自由度を著しく低下する可能性がある。

本発明は、上述の問題に鑑みて成されたものであり、装置に後から追加された機能を利用する際に、当該機能の要求元モジュールが適切なプラグインアプリを好適に選択する仕組みを提供することを目的とする。

本発明は、１以上の機能を提供し、さらに、プラグインアプリケーションをインストールすることにより、提供する機能を追加可能な画像処理装置であって、
所定の処理を実行する要求を受け付ける受付手段と、前記受付手段によって受け付けた前記要求から前記所定の処理の識別情報と、該所定の処理を実行する際に用いるパラメータと、を取得する取得手段と、前記所定の処理を実行できるかどうかを、前記画像処理装置にインストールされた１以上のプラグインアプリケーションのそれぞれに前記識別情報を通知することで、問い合わせる問合せ手段と、問い合わせの結果で特定された前記所定の処理を実行できるプラグインアプリケーションに、前記パラメータを用いた前記所定の処理を指示する指示手段と、を備えることを特徴とする。

本発明によれば、装置に後から追加された機能を利用する際に、当該機能の要求元モジュールが適切なプラグインアプリを好適に選択することができる。

一実施形態に係る画像形成システムの構成例を表す図。 一実施形態に係る画像形成装置の構成例を表す図。 一実施形態に係る画像形成装置におけるソフトウェア構成の一例を示す階層図。 一実施形態に係るサーバの構成例を表す図。 一実施形態に係るサーバにおけるソフトウェア構成の一例を示す階層図。 一実施形態に係る画像処理プラグインアプリ３０３の呼び出し処理を示すフローチャート。 一実施形態に係る画像処理プラグインアプリ３０３の呼び出し処理を示すフローチャート。 一実施形態に係る画像形成装置に実装される画像処理システムの概要を示す図。 一実施形態に係る画像処理プラグインアプリ３０３の呼び出し処理を示すフローチャート。 一実施形態に係る実行可否判定処理を示すフローチャート。

以下に本発明の一実施形態を示す。以下で説明される個別の実施形態は、本発明の上位概念、中位概念及び下位概念など種々の概念を理解するために役立つであろう。また、本発明の技術的範囲は、特許請求の範囲によって確立されるのであって、以下の個別の実施形態によって限定されるわけではない。

＜第１の実施形態＞
＜画像形成システムの構成＞
以下では、本発明の第１の実施形態について説明する。まず、図１を参照して、本実施形態に係る画像形成システムの構成例について説明する。図１は、画像形成システムの構成の一例を示す図である。画像形成システムは、画像処理装置の一例となる画像形成装置１０１、１０２、情報処理端末１０３、１０４、及びサーバ１０５を有する。画像形成装置１０１、１０２、情報処理端末１０３、１０４、及びサーバ１０５は、ネットワーク１０６により相互に接続されて、通信可能である。ネットワーク１０６は、ＬＡＮ（ローカルエリアネットワーク）やインターネット等の、画像形成システム内の装置が相互に通信可能なネットワークである。

図１では、２つの画像形成装置１０１、１０２が設けられた例を示しているが、画像形成システムには任意の数（１つ以上）の画像形成装置を設けることが可能である。本実施形態では、画像形成装置１０１、１０２は複合機（ＭＦＰ：Multifunction Peripheral）であるが、例えば、ＭＦＰ、印刷装置、複写機、及びファクシミリ装置の何れであってもよい。以下では、画像形成装置１０１、１０２が同じ構成を有する場合を想定し、画像形成装置１０２についての詳細な説明を省略する。

画像形成装置１０１は、プリンタ及びスキャナを備え、例えば、情報処理端末１０３、１０４から印刷要求（印刷データ）を受信して、プリンタにより印刷を行うこと、及びスキャナにより原稿の画像を読み取って画像データを生成することが可能である。また、画像形成装置１０１は、スキャナにより生成された画像データに基づいて、プリンタにより印刷を行うこと、及び情報処理端末１０３、１０４から受信した印刷データを保存することも可能である。画像形成装置１０１は、更に、スキャナにより生成された画像データの情報処理端末１０３、１０４への送信、サーバ１０５を用いた画像処理、及びサーバ１０５に格納されている文書の印刷を行うことが可能である。また、画像形成装置１０１は、プリンタやスキャナ等を用いて各種サービスを提供するが、新たなサービス（機能）を追加可能に構成される。具体的には、画像形成装置１０１に追加のプラグインアプリをインストールことにより新たなサービスの追加を実現することができる。

＜画像形成装置のハードウェア構成＞
次に、図２を参照して、画像形成装置１０１のハードウェア構成の一例について説明する。画像形成装置１０１は、コントローラ２０１、プリンタ２０２、スキャナ２０３、及び操作部２０４を有する。コントローラ２０１は、ＣＰＵ２１１、ＲＡＭ２１２、ＨＤＤ２１３、ネットワークインタフェース（Ｉ／Ｆ）２１４、プリンタＩ／Ｆ２１５、スキャナＩ／Ｆ２１６、操作部Ｉ／Ｆ２１７、及び拡張Ｉ／Ｆ２１８を有する。ＣＰＵ２１１は、ＲＡＭ２１２、ＨＤＤ２１３、ネットワークＩ／Ｆ２１４、プリンタＩ／Ｆ２１５、スキャナＩ／Ｆ２１６、操作部Ｉ／Ｆ２１７、及び拡張Ｉ／Ｆ２１８とデータを授受することが可能である。また、ＣＰＵ２１１は、ＨＤＤ２１３から読み出したプログラム（命令）をＲＡＭ２１２に展開し、ＲＡＭ２１２に展開したプログラムを実行する。

ＨＤＤ２１３には、ＣＰＵ２１１が実行可能なプログラム、画像形成装置１０１で使用する設定値、及びユーザから要求された処理に関連するデータ等が格納されうる。ＲＡＭ２１２は、ＣＰＵ２１１がＨＤＤ２１３から読み出したプログラムを一時的に格納するために用いられる。また、ＲＡＭ２１２は、プログラムの実行に必要な各種のデータを格納するために用いられる。ネットワークＩ／Ｆ２１４は、ネットワーク１０６を介して画像形成システム内の他の装置との通信を行うためのインタフェースである。ネットワークＩ／Ｆ２１４は、データの受信をＣＰＵ２１１に通知すること、及びＲＡＭ２１２上のデータをネットワーク１０６に送信することが可能である。

プリンタＩ／Ｆ２１５は、ＣＰＵ２１１から受信した印刷データをプリンタ２０２に送信すること、及びプリンタ２０２から通知された当該プリンタの状態をＣＰＵ２１１に通知することが可能である。スキャナＩ／Ｆ２１６は、ＣＰＵ２１１から受信した画像読取指示をスキャナ２０３に送信すること、及びスキャナ２０３から受信した画像データをＣＰＵ２１１に送信することが可能である。また、スキャナＩ／Ｆ２１６は、スキャナ２０３から通知された当該スキャナの状態をＣＰＵ２１１に通知することが可能である。

操作部Ｉ／Ｆ２１７は、操作部２０４においてユーザによって入力された指示をＣＰＵ２１１に通知すること、及びユーザの操作を受け付ける操作画面の画面情報を操作部２０４へ送信することが可能である。拡張Ｉ／Ｆ２１８は、画像形成装置１０１に外部機器を接続することを可能とするインタフェースである。拡張Ｉ／Ｆ２１８は、例えば、ＵＳＢ（Universal Serial Bus）形式のインタフェースである。画像形成装置１０１は、ＵＳＢメモリ等の外部記憶装置が拡張Ｉ／Ｆ２１８に接続された場合、当該外部記憶装置に格納されているデータの読み取り及び当該外部記憶装置に対するデータの書き込みを行うことが可能である。

プリンタ２０２は、プリンタＩ／Ｆ２１５から受信した画像データに対応する画像をシートに印刷すること、及び当該プリンタの状態をプリンタＩ／Ｆ２１５に通知することが可能である。スキャナ２０３は、スキャナＩ／Ｆ２１６から受信した画像読取指示に従って、原稿の画像を読み取って画像データを生成し、生成した画像データをスキャナＩ／Ｆ２１６へ送信することが可能である。また、スキャナ２０３は、当該スキャナの状態をスキャナＩ／Ｆ２１６へ通知することが可能である。操作部２０４は、画像形成装置１０１に対して各種の指示を行うための操作をユーザに行わせるためのインタフェースである。例えば、操作部２０４は、タッチパネル機能を有する表示部を備え、操作画面をユーザに提供し、当該操作画面を介してユーザからの操作を受け付ける。

＜画像形成装置の画像処理システム＞
次に、図８を参照して、本実施形態に係る画像形成装置１０１に実装される画像処理（情報処理）システムの概要について説明する。本実施形態では、画像処理システムは、プラットフォーム部８００、Ｎａｔｉｖｅアプリ８０１、拡張アプリ８０２、Ｎａｔｉｖｅモジュール８０３、画像処理実行クライアント８０４、画像処理実行サーバ８０５、及び拡張処理プラグイン１～３で構成される。

Ｎａｔｉｖｅアプリ８０１又は拡張アプリ８０２（Ｊａｖａアプリ）は、ユーザからの指示に従って、所望の画像処理（情報処理）の実行をプラットフォーム部８００に要求しうる。Ｎａｔｉｖｅアプリ８０１は、例えばＣ言語等のプログラム言語によって記述され、画像形成装置１０１に元々備わっている（プリインストールされている）アプリである。Ｎａｔｉｖｅアプリ８０１は、例えば、プリントアプリ、コピーアプリ、スキャンアプリ、及び送信アプリ等である。Ｎａｔｉｖｅアプリ８０１を更新するためには、画像形成装置１０１のファームウェアを更新する必要がある。拡張アプリ８０２は、例えばＪａｖａ言語等のプログラム言語によって記述されたアプリである。拡張アプリ８０２は、画像形成装置１０１の機能を拡張するために画像形成装置１０１に後からインストールされる。拡張アプリ８０２は、例えば、画像形成装置１０１へのユーザのログインを管理するログインアプリ等である。

画像形成装置１０１では、プラットフォーム部８００上で、１つ以上の拡張処理プラグインを動作させることが可能である。本実施形態では、３つの拡張処理プラグイン１～３がプラットフォーム部８００上で動作している。拡張処理プラグイン１～３は、拡張アプリ７０２と同様、画像形成装置１０１の機能を拡張するために画像形成装置１０１に後からインストールされる。拡張処理プラグインの機能を更新する場合には、当該プラグインのみを更新すればよく、画像形成装置１０１のファームウェアの更新は必要とならない。

本実施形態では、拡張処理プラグイン１は、画像形成装置１０１内のＪａｖａ言語で記述されたライブラリに接続して処理を実行する拡張処理プラグインである。拡張処理プラグイン２は、クラウド等の外部サーバに接続して処理を実行する拡張処理プラグインである。拡張処理プラグイン３は、Ｃ言語で記述されたＮａｔｉｖｅモジュール７０３に接続して処理を実行する拡張処理プラグインである。

拡張処理プラグイン３は、画像処理実行クライアント８０４及び画像処理実行サーバ８０５を介して、Ｎａｔｉｖｅモジュール８０３に接続する。Ｎａｔｉｖｅモジュール８０３は、Ｎａｔｉｖｅアプリ８０１と同様、画像形成装置１０１にプリインストールされている。また、Ｎａｔｉｖｅモジュール８０３を更新するためには、Ｎａｔｉｖｅアプリ８０１と同様、画像形成装置１０１のファームウェアの更新が必要になる。本実施形態では、Ｎａｔｉｖｅモジュール８０３は、ＯＣＲ処理を提供するモジュールである。なお、拡張処理プラグイン１～３は一例にすぎず、拡張処理プラグインの接続先及び処理内容は、上述の接続先及び処理内容に限定されない。

プラットフォーム部８００は、Ｎａｔｉｖｅアプリ７０１又は拡張アプリ８０２から画像処理の実行要求を受け付けることができる。例えば、プラットフォーム部８００は、スキャンアプリから、スキャンした画像から文字画像を抽出するＯＣＲ処理の実行要求を受け付ける。プラットフォーム部８００は、画像処理の実行要求を受け付けると、拡張処理プラグイン１～３のうちで、実行要求に従って画像処理を実行させる拡張処理プラグインを選択し、選択した拡張処理プラグインに画像処理の実行を指示する。例えばプラットフォーム部８００は、実行を要求された画像処理の種別及び内容（即時性が求められるか、処理負荷の度合い等）に基づいて、利用する拡張処理プラグインを決定する。プラットフォーム部８００は、要求された画像処理の実行結果を、利用した拡張処理プラグインから取得する。プラットフォーム部８００は、取得した実行結果を、実行要求に対する応答として、当該実行要求の送信元のアプリへ出力する。

なお、図８に示される各要素は、以下で説明する図３に示される各要素と以下のような対応関係を有する。プラットフォーム部８００は、接続ライブラリ３３２に対応する。Ｎａｔｉｖｅアプリ８０１は、デバイス制御ライブラリ３０９に対応する。拡張アプリ８０２は、単独機能プラグインアプリ３０２に対応する。拡張処理プラグイン１～３は、画像処理プラグインアプリ３０３に対応する。Ｎａｔｉｖｅモジュール８０３は、Ｎａｔｉｖｅモジュール３１６に対応する。画像処理実行クライアント８０４は、Ｎａｔｉｖｅクライアント３３１に対応する。画像処理実行サーバ８０５は、Ｎａｔｉｖｅサーバ３１５に対応する。

＜画像形成装置のソフトウェア構成＞
次に、図３を参照して、画像形成装置１０１のソフトウェア構成の一例について説明する。画像形成装置１０１のソフトウェア構成は、例えば、ＨＤＤ２１３に格納されたプログラムを用いて実現される。図３に示すソフトウェア構成は、オペレーティングシステム３１７を含む最下位層と、Ｊａｖａ（登録商標）言語実行環境３３０に対応する最上位層と、それらの間の中間層とから成る階層構造を有する。この階層構造は、一部の例外を除いて、下位の階層が提供するサービスを上位の階層が利用する関係を有している。なお、この例外とは、後述するように、デバイス制御ライブラリ３０９が、画像処理制御部３４０を介して、最上位層に含まれる画像処理プラグインアプリ３０３を利用できることである。

最下位層は、オペレーティングシステム３１７を含み、プログラムの実行の管理やメモリ管理等を行う階層である。オペレーティングシステム３１７には、プリンタ制御ドライバ３１８、スキャナ制御ドライバ３１９、及びネットワークＩ／Ｆ制御ドライバ３２０が組み込まれている。プリンタ制御ドライバ３１８、スキャナ制御ドライバ３１９、及びネットワークＩ／Ｆ制御ドライバ３２０は、相互に連携して機能することが可能である。プリンタ制御ドライバ３１８は、プリンタＩ／Ｆ２１５を介してプリンタ２０２を制御するためのソフトウェアである。スキャナ制御ドライバ３１９は、スキャナＩ／Ｆ２１６を介してスキャナ２０３を制御するためのソフトウェアである。ネットワークＩ／Ｆ制御ドライバ３２０は、ネットワークＩ／Ｆ２１４を制御するためのソフトウェアである。

最下位層より上位の中間層は、デバイス制御ライブラリ３０９及び画像処理制御部３４０を含む。本実施形態では、デバイス制御ライブラリ３０９及び画像処理制御部３４０のプログラムは、Ｃ言語又はＣ＋＋言語等のコンパイル言語で記述され、ＣＰＵ２１１が直接実行できるオブジェクトファイルの形式で、ＨＤＤ２１３に格納されうる。

最上位層は、Ｊａｖａ言語実行環境３３０で動作するアプリを含む、アプリ層である。最上位層は、プラグインアプリ３０１及びデバイス制御アプリ３０４を含み、Ｎａｔｉｖｅクライアント３３１、接続ライブラリ３３２、及び外部クライアント３３３を更に含む。最上位層の各アプリは、デバイス制御ライブラリ３０９又は接続ライブラリ３３２によって提供されるＡＰＩを利用しながら動作することによって、様々な機能を提供する。なお、画像形成装置１０１のファームウェアの更新により、デバイス制御アプリ３０４の機能を拡張することが可能である。

本実施形態では、プラグインアプリ３０１及びデバイス制御アプリ３０４のプログラムは、Ｊａｖａ言語で記述され、Ｊａｖａ仮想マシンが解釈できるＪａｖａバイトコード形式で、ＨＤＤ２１３に格納されうる。そのため、ＣＰＵ２１１は、Ｊａｖａ仮想マシンのプログラムを実行し、Ｊａｖａバイトコード形式のプログラムをＨＤＤ２１３から読み出してＪａｖａ仮想マシンに実行させることによって、最上位層の各アプリによる処理を実現する。

このように、Ｊａｖａ言語等のプログラミング言語を利用する理由の１つは、プログラムの記述の簡易さである。Ｊａｖａではメモリ領域の管理は自動的に行われるため、開発者がメモリ領域の管理を行う必要はない。このため、開発者がプログラムを記述する際の手間が低減され、開発効率が向上することが期待される。

（デバイス制御ライブラリ３０９）
次に、デバイス制御ライブラリ３０９について、より具体的に説明する。デバイス制御ライブラリ３０９は、後述する単独機能プラグインアプリ３０２又はデバイス制御アプリ３０４と、静的又は動的にリンクされる。デバイス制御ライブラリ３０９は、最上位層の各アプリによる指示に基づいて、最下位層のオペレーティングシステム３１７を利用する。また、デバイス制御ライブラリ３０９は、Ｎａｔｉｖｅ接続ライブラリ３１４に対して画像処理の実行を要求することも可能である。デバイス制御ライブラリ３０９は、一例として、プリントライブラリ３１０、コピーライブラリ３１１、スキャン保存ライブラリ３１２、及びスキャン送信ライブラリ３１３で構成される。

プリントライブラリ３１０は、プリンタ制御ドライバ３１８の機能を利用してプリントジョブの制御を行うためのＡＰＩ（Application Programming Interface）を提供する。プリントジョブは、ＨＤＤ２１３に保存されている印刷データ、又は外部装置（情報処理端末１０３、１０４等）からネットワークＩ／Ｆ２１４を通して受信した印刷データに基づいてプリンタ２０２で印刷を行う、一連の処理を指す。コピーライブラリ３１１は、スキャナ制御ドライバ３１９及びプリンタ制御ドライバ３１８の機能を利用してコピージョブの制御を行うためのＡＰＩを提供する。コピージョブは、スキャナ２０３で原稿画像のスキャンを行い、得られた画像データに基づいてプリンタ２０２で印刷を行う、一連の処理である。

スキャン保存ライブラリ３１２は、スキャナ制御ドライバ３１９の機能を利用してスキャン保存ジョブの制御を行うためのＡＰＩを提供する。スキャン保存ジョブは、スキャナ２０３で原稿画像のスキャンを行い、得られた画像データを印刷データ又は汎用フォーマットのデータに変換し、ＨＤＤ２１３、又は拡張Ｉ／Ｆ２１８に接続されたＵＳＢ等の外部記憶装置に保存する、一連の処理を指す。なお、汎用フォーマットは、例えば、ＰＤＦ（Portable Document Format）又はＪＰＥＧ（Joint Photographic Experts Group）等のデータフォーマットである。

スキャン送信ライブラリ３１３は、スキャナ制御ドライバ３１９及びネットワークＩ／Ｆ制御ドライバ３２０の機能を利用してスキャン送信ジョブの制御を行うためのＡＰＩを提供する。スキャン送信ジョブは、スキャナ２０３で原稿画像のスキャンを行い、得られた画像データを汎用フォーマットのデータに変換し、ネットワークＩ／Ｆ２１４を通して外部へ送信する、一連の処理を指す。スキャン送信ジョブでは、ネットワークＩ／Ｆ２１４を通して、例えば、サーバ１０５等のファイルサーバへデータが送信されるか、又は情報処理端末１０３、１０４等の外部装置へ電子メールによりデータが送信される。

（画像処理制御部３４０）
次に、画像処理制御部３４０について、より具体的に説明する。画像処理制御部３４０は、Ｎａｔｉｖｅ接続ライブラリ３１４、Ｎａｔｉｖｅサーバ３１５、及びＮａｔｉｖｅモジュール３１６を含む。Ｎａｔｉｖｅ接続ライブラリ３１４は、デバイス制御ライブラリ３０９から画像処理の実行要求を受けると、要求内容を接続ライブラリ３３２へ転送する。Ｎａｔｉｖｅサーバ３１５は、後述するＪａｖａ言語実行環境３３０で動作するアプリから要求を受けて、Ｎａｔｉｖｅモジュール３１６を実行する機能を提供する。Ｎａｔｉｖｅモジュール３１６は、様々な種類の画像処理を実行可能なソフトウェアである。

Ｎａｔｉｖｅサーバ３１５及びＮａｔｉｖｅモジュール３１６は、図３に示すように、Ｎａｔｉｖｅ制御プロセス３５０上で実行される。Ｎａｔｉｖｅ制御プロセス３５０は、Ｎａｔｉｖｅサーバ３１５及びＮａｔｉｖｅモジュール３１６以外の他のソフトウェアが有する論理メモリ空間とは分離された論理メモリ空間を有するプログラム実行単位である。なお、このようなメモリ空間の分離は、一般的なＯＳ（オペレーティングシステム）が備えるプロセス機構を用いる方法等の、他の方法により実現することも可能である。

本実施形態では、上述のように、Ｎａｔｉｖｅ制御プロセス３５０が有する論理メモリ空間が、他のソフトウェアが有する論理メモリ空間と独立している。このため、Ｎａｔｉｖｅ制御プロセス３５０上でメモリ操作に不具合が生じても、そのような不具合が、Ｎａｔｉｖｅサーバ３１５に画像処理の実行を要求する側のアプリが有する論理メモリ空間に影響を及ぼすことを防止できる。即ち、Ｎａｔｉｖｅサーバ３１５に画像処理の実行を要求する側のアプリの動作に不具合が生じることを防止できる。

（デバイス制御アプリ３０４）
次に、デバイス制御アプリ３０４について、より具体的に説明する。デバイス制御アプリ３０４は、一例として、プリントアプリ３０５、コピーアプリ３０６、スキャン保存アプリ３０７、及びスキャン送信アプリ３０８を含む。これらのデバイス制御アプリ３０４は、画像形成装置１０１における常駐型のアプリである。

プリントアプリ３０５、コピーアプリ３０６、スキャン保存アプリ３０７、及びスキャン送信アプリ３０８は、それぞれ画面情報３２１、３２２、３２３、３２４を有する。ＣＰＵ２１１は、画面情報３２１、３２２、３２３、３２４のそれぞれに基づいて、対応する操作画面を、操作部Ｉ／Ｆ２１７を通して操作部２０４に表示しうる。また、ＣＰＵ２１１は、表示した操作画面を介してユーザからの指示を受け付けうる。

ＣＰＵ２１１は、ユーザが操作部２０４を操作してデバイス制御アプリ３０４の設定の変更を行ったことを検知すると、その変更の内容をＨＤＤ２１３に書き込む。ＣＰＵ２１１（デバイス制御アプリ３０４）は、ユーザが操作部２０４を操作してジョブの実行要求を行ったことを検知すると、デバイス制御ライブラリ３０９のＡＰＩをコールすることによって、ジョブの実行を開始する。また、ＣＰＵ２１１（デバイス制御アプリ３０４）は、接続ライブラリ３３２に対して、画像処理の実行を要求することも可能である。

例えば、プリントアプリ３０５は、プリントライブラリ３１０のＡＰＩをコールすることによって、プリントジョブを実行する。コピーアプリ３０６は、コピーライブラリ３１１のＡＰＩをコールすることによって、コピージョブを実行する。スキャン保存アプリ３０７は、スキャン保存ライブラリ３１２のＡＰＩをコールすることによって、スキャン保存ジョブを実行する。スキャン送信アプリ３０８は、スキャン送信ライブラリ３１３のＡＰＩをコールすることによって、スキャン送信ジョブを実行する。

（プラグインアプリ３０１）
次に、プラグインアプリ３０１について、より具体的に説明する。プラグインアプリ３０１は、常駐型のアプリであるデバイス制御アプリ３０４とは別に、画像形成装置１０１に対してプラグインとしてインストール及びアンインストールが可能なアプリである。プラグインアプリ３０１は、リモートＵＩ（ユーザインタフェース）等を用いることにより、画像形成装置１０１にインストールされる。なお、リモートＵＩは、情報処理端末１０３、１０４等の外部装置においてＷｅｂブラウザから画像形成装置１０１にアクセスし、画像形成装置１０１の状況の確認、印刷ジョブの操作、及び各種設定等を可能にする仕組みである。

プラグインアプリ３０１は、単独機能プラグインアプリ３０２及び画像処理プラグインアプリ３０３を含む。各プラグインアプリ３０１（単独機能プラグインアプリ３０２及び画像処理プラグインアプリ３０３）には、それぞれ動作に必要なプログラムがパッケージングされている。また、各プラグインアプリ３０１は、それぞれ個別に起動及び停止を行うことが可能である。

プラグインアプリ３０１のインストールから起動、停止、アンインストールまでの一連の流れは、例えば以下のとおりである。まず、ＣＰＵ２１１は、リモートＵＩ等を用いたプラグインアプリ３０１のインストールを検知すると、当該プラグインアプリの情報をＨＤＤ２１３に保存する。次に、ＣＰＵ２１１は、プラグインアプリ３０１に対する起動指示を検知すると、当該プラグインアプリに対する起動指示を行う。プラグインアプリ３０１は、起動している間、当該プラグインアプリの機能を提供することが可能である。

その後、ＣＰＵ２１１は、プラグインアプリ３０１に対する停止指示を検知すると、当該プラグインアプリ３０１に対して停止指示を行う。更に、ＣＰＵ２１１は、プラグインアプリ３０１に対するアンインストール指示を検知すると、当該プラグインアプリ３０１の情報をＨＤＤ２１３から削除することにより、当該プラグインアプリをアンインストールする。なお、ＣＰＵ２１１によって検知される上述の各指示は、例えば、リモートＵＩ又は操作部２０４から行われうるが、これ以外の方法で指示が行われてもよい。

（単独機能プラグインアプリ３０２）
次に、単独機能プラグインアプリ３０２について、より具体的に説明する。単独機能プラグインアプリ３０２は、画面情報３２５を有する。ＣＰＵ２１１は、画面情報３２５に基づいて、対応する操作画面を、操作部Ｉ／Ｆ２１７を通して操作部２０４に表示しうる。また、ＣＰＵ２１１は、表示した操作画面を介してユーザからの指示を受け付けうる。

単独機能プラグインアプリ３０２は、デバイス制御ライブラリ３０９が提供するＡＰＩをコールすることによって、デバイス制御アプリ３０４とは別の機能又は画面をユーザに提供することが可能である。単独機能プラグインアプリ３０２は、デバイス制御ライブラリ３０９による複数の機能を組み合わせて提供することが可能である。例えば、単独機能プラグインアプリ３０２は、或る画像のコピーを行うとともに、スキャンにより得られた画像データを、当該プラグインアプリ自体が保持する宛先データベース内の特定の宛先へ送信する機能を提供することが可能である。

なお、単独機能プラグインアプリ３０２は、画像処理機能を有していなくてもよく、その場合、画像処理の設定を行わない。デバイス制御ライブラリ３０９は、単独機能プラグインアプリ３０２から印刷データ、又は汎用フォーマットに変換後の画像データを受信すると、オペレーティングシステム３１７に対して必要な処理の制御を指示することで、ジョブを実行させる。

（画像処理プラグインアプリ３０３）
次に、画像処理プラグインアプリ３０３について、より具体的に説明する。画像処理プラグインアプリ３０３は、特定の画像処理を提供するアプリである。なお、画像処理プラグインアプリ３０３は、それぞれ異なる画像処理を実行する複数のアプリで構成されてもよい。例えば、入力画像に対して画像形式変換、斜行補正、帳票認識、及びＯＣＲ処理等をそれぞれ実行可能な複数のアプリが、画像処理プラグインアプリ３０３として画像形成装置１０１にインストールされてもよい。なお、画像処理プラグインアプリ３０３は、追加でインストールされる際に、当該アプリにおいて実行可能な画像処理を示す画像処理情報として、当該画像処理の名称（画像処理名）を保持しておくことが望ましい。これにより、後述する図６のＳ６０３で問い合わせされる画像処理名に対応する画像処理の実行可否を好適に判定することができる。

画像処理プラグインアプリ３０３は、単独機能プラグインアプリ３０２又はデバイス制御アプリ３０４から、接続ライブラリ３３２を介して画像処理要求（画像処理の実行要求）を受け付けることが可能である。また、画像処理プラグインアプリ３０３は、デバイス制御ライブラリ３０９からも、Ｎａｔｉｖｅ接続ライブラリ３１４及び接続ライブラリ３３２を介して、画像処理要求を受け付けることが可能である。

画像処理プラグインアプリ３０３は、受け付けた画像処理要求に従って、画像処理を実行する。画像処理要求には、処理対象の画像データ及び処理パラメータが含まれうる。当該処理パラメータは、例えば、後述する画像処理名及び画像処理に関わるパラメータを含む。また、画像処理プラグインアプリ３０３は、画像処理要求に基づいて、必要に応じて、Ｎａｔｉｖｅクライアント３３１の画像処理機能を利用することが可能である。なお、画像処理プラグインアプリ３０３は、それ自体が画像処理機能を有していなくてもよい。画像処理プラグインアプリ３０３は、画像処理機能を有していなくても、Ｎａｔｉｖｅクライアント３３１を利用することによって、Ｎａｔｉｖｅモジュール３１６の画像処理機能を利用することが可能である。

このように画像処理プラグインアプリ３０３がＮａｔｉｖｅモジュール３１６を利用する理由の１つは、画像処理を行う際の処理速度の高速化である。具体的には、画像処理を行う際には、大量かつ複雑な数値演算の実行が必要になる場合や処理の過程で大量のメモリが必要になる場合がある。そのような場合、Ｊａｖａのように仮想マシンを介して処理を行うプログラミング言語による処理系ではなく、ＣＰＵが直接実行できるオブジェクトファイルを生成するコンパイル言語による処理系を利用することにより、処理速度の高速化が期待できる。

さらに、画像処理プラグインアプリ３０３は、外部クライアント３３３を利用し、サーバ（外部装置）１０５のような外部デバイスに対して、入力画像、及び画像処理要求を送信し、外部の画像処理クライアントによる画像処理の実行を要求することも可能である。そうすることで、画像形成装置１０１が実行できない画像処理を実行したり、大量のメモリを利用した高速な処理を実行したりすることが可能になる。

＜サーバのハードウェア構成＞
次に、図４を参照して、本実施形態に係るサーバの構成例について説明する。サーバ１０５は、ＣＰＵ４０１、ＲＡＭ４０２、ＨＤＤ４０３、及びネットワークＩ／Ｆ４０４を有する。ＣＰＵ２１１は、ＲＡＭ４０２、ＨＤＤ４０３、及びネットワークＩ／Ｆ４０４とデータを授受することが可能である。また、ＣＰＵ４０１は、ＨＤＤ４０３から読み出したプログラム（命令）をＲＡＭ４０２に展開し、ＲＡＭ４０２に展開したプログラムを実行する。

ＨＤＤ４０３には、ＣＰＵ４０１で実行可能なプログラム、サーバ１０５で使用する設定値、及びユーザから要求された処理に関するデータ等が格納されうる。ＲＡＭ４０２は、ＣＰＵ４０１がＨＤＤ４０３から読み出したプログラムを一時的に格納するために用いられる。ＲＡＭ４０２は、プログラムの実行に必要な各種のデータを記憶しておくことが可能である。ネットワークＩ／Ｆ４０４は、ネットワーク上に存在する他の装置とネットワーク通信を行うためのインタフェースである。ネットワークＩ／Ｆ４０４は、データの受信をＣＰＵ４０１に通知すること、及びＲＡＭ４０２上のデータをネットワーク１０６に送信することが可能である。

＜サーバのソフトウェア構成＞
次に、図５を参照して、ＣＰＵ４０１が処理するソフトウェアの構造の一例について説明する。図５に示す構造を有するソフトウェアは、例えば、サーバ１０５のＨＤＤ４０３に格納されたプログラムを用いて実現される。サーバ１０５は、ソフトウェア構成として、モジュール５０１、及び通信ライブラリ５０２を含む。なお、本発明におけるサーバのソフトウェア構成を上記２つのコンポーネントのみに限定する意図はなく、他のモジュール等が含まれてもよい。

モジュール５０１は、通信ライブラリ５０２から送られた、入力画像、及び画像処理要求を受け取り、当該要求に従って、入力画像に対して画像処理を実行する。そして、処理後の画像データを、通信ライブラリ５０２を介して通知する。通信ライブラリ５０２は、画像形成装置１０１のような、ネットワーク１０６上に存在する他のデバイスとの通信処理を実行するためのＡＰＩを提供するライブラリである。通信ライブラリ５０２は、画像形成装置１０１から送られた入力画像、及び画像処理要求を受信し、それらを、モジュール５０１に転送する。さらに、通信ライブラリ５０２は、モジュール５０１が生成した処理後の画像データを、画像形成装置１０１へ送信する。

＜処理手順＞
次に、図６を参照して、接続ライブラリ３３２が、画像処理プラグインアプリ３０３を呼び出す際の処理手順について説明する。以下で説明する処理は、例えば、ＣＰＵ２１１がＨＤＤ２１３に格納されたプログラムをＲＡＭ２１２に展開して、実行することによって実現される。

まず、Ｓ６０１で、接続ライブラリ３３２は、受付手段として機能し、単独機能プラグインアプリ３０２やデバイス制御アプリ３０４から、画像処理の実行要求を受け付ける。ここで、接続ライブラリ３３２は、実行が要求された画像処理に対応する画像処理情報として、画像処理名と、パラメータの指定とを受信する。例えば、画像処理名（ＩｍａｇｉｎｇＮａｍｅ）は、「ＯＣＲ」のような文字列であってもよい。また、パラメータは、「言語：日本語」のような当該画像処理に関わるパラメータが指定される。

次に、Ｓ６０２で、接続ライブラリ３３２は、受け付けた要求からＳ６０１で指定された画像処理名を取得する。続いて、Ｓ６０３で、接続ライブラリ３３２は、インストールされている全ての画像処理プラグインアプリ３０３に対して、画像処理名を指定し、それに対応する画像処理が実行可能か否かを問い合わせる。ここで、各画像処理プラグインアプリ３０３は、指定された画像処理名に該当する画像処理を自身が実行可能であるか否か判断し、その結果を接続ライブラリ３３２に応答する。このように、本実施形態によれば、画像処理名を検索キーとして用い、インストールされているプラグインアプリの中から要求された画像処理に適切なプラグインアプリを好適に選択することができる。つまり、接続ライブラリ３３２は、種々の画像処理に対応するプラグインをそれぞれ把握しておく必要がなく、当該要求から画像処理名を抽出して、各プラグインアプリに問い合わせることにより、適切なプラグインアプリを選択することができる。これにより、例えば、メニュー画面における各画像処理ボタンにインストールしたプラグインアプリを紐づけるなどの登録処理を必要とせず、製品における開発設計の自由度を向上させるとともに、余分な処理を削減することもできる。

次に、Ｓ６０４で、接続ライブラリ３３２は、各応答に基づいて、画像処理情報である画像処理名に対応する画像処理が実行可能な画像処理プラグインアプリ３０３が存在するか否かを判断する。存在する場合はＳ６０５へ進み、存在しない場合はＳ６０６へ進む。例えば、上記の例では、画像処理名、「ＯＣＲ」に対応する画像処理プラグインアプリ３０３が存在する場合は、Ｓ６０５へ進む。Ｓ６０５で、接続ライブラリ３３２は、画像処理プラグインアプリ３０３に対して、Ｓ６０１で指定されたパラメータを通知した上で、画像処理の実行指示を通知する。一方、Ｓ６０６で、接続ライブラリ３３２は、デバイス制御アプリ３０４又はデバイス制御ライブラリ３０９に対して、実行可能な画像処理プラグインアプリ３０３が見つからなかったことを画像処理の要求元に通知し、処理を終了する。具体的には、接続ライブラリ３３２は、所定の画像処理を実行可能なプラグインアプリケーションが存在しないことを要求元に通知する。

以上説明したように、本実施形態に係る画像処理装置（画像形成装置）は、所定の画像処理を実行する要求を受け付け、当該所定の画像処理の名称を示す画像処理名を当該要求から取得する。また、画像処理装置は、取得した画像処理名を用いて、受け付けた所定の画像処理を実行可能なプラグインアプリケーションを選択し、その実行を指示する。これにより、本実施形態によれば、追加した画像処理機能を利用する要求元モジュールが、直接プラグインを選択する必要がなくなり、画像処理名の指定をするだけで適切なプラグインを利用することができ、プラグインの誤選択の危険性を低減できる。

本発明は、上記実施形態に限らず様々な変形が可能である。例えば、上記Ｓ６０３では、接続ライブラリ３３２が画像処理名を用いて各画像処理プラグインアプリ３０３に対して、当該画像処理名に対応する画像処理の実行可否を問い合わせている。この構成の代わりに、各画像処理プラグインアプリ３０３がインストールされる際に、接続ライブラリ３３２に対して自身が実行可能な画像処理の画像処理名を当該プラグインアプリに紐づけて登録するようにしてもよい。これにより、接続ライブラリ３３２は、画像処理名を用いて、各画像処理プラグインアプリに対して問い合わせることなく、自身が保持している情報に基づいて、適切なプラグインを選択することができる。

＜第２の実施形態＞
以下では、本発明の第２の実施形態を説明する。上記第１の実施形態では、接続ライブラリ３３２は、画像処理プラグインアプリ３０３に対して、画像処理名を指定し、それに対応する画像処理が実行可能か否か問い合わせることで、プラグインの選択を行った。

しかしながら、画像処理名からだけでは、画像処理プラグインアプリ３０３の選択が正しく行えない場合もあり得る。ここでは、画像処理名として、「ＯＣＲ」が指定されたケースを考える。ＯＣＲ処理を行うプラグインとしては、デバイス内のＮａｔｉｖｅモジュール３１６に処理を要求するプラグインと、ネットワーク１０６を介してサーバ１０５に処理を要求するプラグインが存在する。前者は、英語等、デバイス内にＯＣＲ用の辞書が存在する言語についての処理を行うためのプラグインであり、後者は、デバイス内に辞書が存在しない言語についての処理を行うためのプラグインである。このようなケースでは、「ＯＣＲ」という画像処理名に対応するプラグインが複数個存在するため、画像処理名の情報のみからでは、正しく画像処理プラグインアプリ３０３の選択を行うことができない。

そこで、本実施形態では、画像処理プラグインアプリ３０３の選択を行う際、画像処理名に加えて、画像処理に関わるパラメータ情報を利用する。当該パラメータは、キーとバリューのペアから成り、一つの画像処理に対して、複数指定されてもよい。上記の例において、パラメータを、「キー：バリュー」の形で表現すると、「言語：英語」という文言が指定される。画像処理名、「ＯＣＲ」と、パラメータ、「言語：英語」の情報に基づいて、接続ライブラリ３３２は、Ｎａｔｉｖｅモジュール３１６を利用してＯＣＲ処理を実行する画像処理プラグインアプリ３０３を選択することが可能になる。

また、別の例としては、パラメータとして指定される、「入力画像解像度」によって、利用するプラグインを切り替えることも考えられる。まず、パラメータとして、「入力画像解像度：３００ＤＰＩ」が指定された場合には、デバイス内のＮａｔｉｖｅモジュール３１６に処理を要求するプラグインを利用する。一方、パラメータとして、「入力画像解像度：６００ＤＰＩ」が指定された場合には、サーバ１０５に処理を要求するプラグインを利用する。これは、入力解像度が高くなるにつれ、処理に必要なＲＡＭ２１２の容量が増えるため、画像形成装置１０１内で処理できる入力画像解像度には一定の制限があり、所定の入力解像度を超えた場合は、サーバ１０５に処理を要求する必要があるためである。

＜処理手順＞
図７を参照して、本実施形態における、接続ライブラリ３３２が、画像処理プラグインアプリ３０３を呼び出す際の処理手順について説明する。以下で説明する処理は、例えば、ＣＰＵ２１１がＨＤＤ２１３に格納されたプログラムをＲＡＭ２１２に展開して、実行することによって実現される。なお、本実施形態のシステム構成、及び処理手順は、上記第１の実施形態で説明したものと同一であるため、その説明を省略し、異なる箇所のみを説明する。具体的には、Ｓ７０１、Ｓ７０４、Ｓ７０５、Ｓ７０６は、Ｓ６０１、Ｓ６０４、Ｓ６０５、Ｓ６０６と同一であるため説明を省略する。

Ｓ７０２で、接続ライブラリ３３２は、Ｓ７０１で指定を受けた、画像処理名とパラメータを参照する。さらに、Ｓ７０３で、接続ライブラリ３３２は、インストールされている全ての画像処理プラグインアプリ３０３に対して、画像処理名とパラメータを指定し、それに対応する画像処理が実行可能か否かを問い合わせる。

以上説明したように、本実施形態によれば、画像処理名とパラメータの２つの情報に基づいて、より細かい条件で、画像処理プラグインアプリ３０３を選択することが可能になる。また、上述したように、上記Ｓ７０３では、接続ライブラリ３３２が画像処理名及びパラメータを用いて各画像処理プラグインアプリ３０３に対して、当該画像処理名及びパラメータに対応する画像処理の実行可否を問い合わせている。この構成の代わりに、各画像処理プラグインアプリ３０３がインストールされる際に、接続ライブラリ３３２に対して自身が実行可能な画像処理に対応する画像処理名及びパラメータを当該プラグインアプリに紐づけて登録するようにしてもよい。これにより、接続ライブラリ３３２は、画像処理名及びパラメータを用いて、各画像処理プラグインアプリに対して問い合わせることなく、自身が保持している情報に基づいて、適切なプラグインを選択することができる。

＜第３の実施形態＞
以下では、本発明の第３の実施形態を説明する。上記第２の実施形態においては、接続ライブラリ３３２は、画像処理プラグインアプリ３０３に対して、画像処理名とパラメータを指定し、それに対応する画像処理が実行可能か否か問い合わせることで、プラグインの選択を行った。

しかしながら、すべての画像処理プラグインアプリ３０３について、画像処理名とパラメータを指定した上で、画像処理が実行可能か否かを判断しようとすると、処理に時間が掛かってしまう場合がある。例えば、画像処理プラグインアプリ３０３の数が多かったり、実行可能か否かの判定ロジックが複雑なものが多数存在する場合である。

上記第２の実施形態の方法では、画像処理が実行可能か否かの問い合わせを、画像処理プラグインアプリ３０３の数と同じ回数実行する必要がある。このような方法では、指定された画像処理を行う機能を有さない画像処理プラグインアプリについても、プラグインの能力についての問い合わせ処理を行うこととなる。例えば、指定された画像処理を実行する機能を有さない画像処理プラグインアプリについても、当該画像処理プラグインアプリの能力を示す関数を呼び出し、指定されたパラメータで画像処理を実行可能かどうか確認する確認処理が発生してしまう。この確認処理を実行するための判定ロジックが複雑な場合、本来実行する必要がない処理を実行することとなる。また、アプリケーションによっては、指定された画像処理を行う機能を有していなくても、指定されたパラメータで画像処理を行うことが可能かを判定するための判定処理を実行してしまう可能性もある。これらの本来実行する必要がない処理を実行することにより、検索時間が長くなったり、ＣＰＵ２１１の処理負荷が増大したりするという問題がある。

そこで、本実施形態においては、二段階のフィルタを動作させて、画像処理プラグインアプリ３０３の選択を行うことで、処理速度、及び柔軟性を両立させることとする。初めに、一段階目のフィルタを適用し、指定された画像処理名のみから、画像処理プラグインアプリ３０３の候補を絞り込む。これは単に、指定された画像処理名と一致する画像処理名を保持する画像処理プラグインアプリ３０３を探し出すだけの処理である。そして、その後、二段階目のフィルタを適用し、一段階目のフィルタで絞り込んだ候補に対してパラメータを指定し、処理が可能か否かを問い合わせることで、適切な画像処理プラグインアプリ３０３を選択する。

一段階目のフィルタ処理は、取得した画像処理名を用いて、指定された画像処理を実行可能なプラグインアプリケーションを選択する第１の選択処理である。また、二段階目のフィルタ処理は、第１の選択処理によって選択されたプラグインアプリケーションのうちから、パラメータに応じた画像処理を実行可能なプラグインアプリケーションを選択する第２の選択処理である。このようにすれば、処理が実行可能か否かを判断するためのロジックが複雑な場合であっても、予め絞り込んだ候補にだけ処理を適応させればよいため、二段階フィルタを動作させない場合と比べて、処理時間の増加を抑制することができる。

＜処理手順＞
ここで、図８に示すフローチャートを参照して、本実施形態における、接続ライブラリ３３２が、画像処理プラグインアプリ３０３を呼び出す処理の詳細について説明する。以下で説明する処理は、例えば、ＣＰＵ２１１がＨＤＤ２１３に格納されたプログラムをＲＡＭ２１２に展開して、実行することによって実現される。なお、本実施形態のシステム構成、及び処理手順は、上記第１の実施形態で説明したものと同一であるため、その説明を省略し、異なる箇所のみを説明する。具体的には、Ｓ９０１、Ｓ９０２、Ｓ９０８、Ｓ９０９は、Ｓ６０１、Ｓ６０２、Ｓ６０５、Ｓ６０６と同一である。

Ｓ９０３で、接続ライブラリ３３２は、インストールされている全ての画像処理プラグインアプリ３０３に対して、画像処理名を指定し、その画像処理名に対応するプラグインか否かを問い合わせる。これは、前述した一段階目のフィルタに対応する処理である。Ｓ９０４で、接続ライブラリ３３２は、指定された画像処理名に対応する画像処理プラグインアプリ３０３が存在するか否か判断する。存在する場合は、Ｓ９０５へ、存在しない場合は、Ｓ９０９へ進む。例えば、Ｓ９０１で、画像処理名、「ＯＣＲ」が指定された場合、それと同じ画像処理名を保持する画像処理プラグインアプリ３０３が存在する場合は、Ｓ９０５へ進む。Ｓ９０５で、接続ライブラリ３３２は、Ｓ９０１で指定を受けた、パラメータを参照する。Ｓ９０６で、接続ライブラリ３３２は、Ｓ９０４で検出した画像処理プラグインアプリ３０３に対して、パラメータを指定し、それに対応する画像処理が実行可能か否か問い合わせる。上記の例においては、画像処理名、「ＯＣＲ」の画像処理プラグインアプリ３０３に対して、パラメータ、「言語：英語」を指定して、画像処理が実行可能か否か問い合わせる。この時、上記第２の実施形態と同様、画像処理プラグインアプリ３０３内部では、所定のディレクトリ以下に、英語に対応したＯＣＲ用の辞書が存在するか否かで、実行可能か否かを判断する。

また、同一の画像処理名に対応する画像処理プラグインアプリ３０３として、画像形成装置１０１内部で処理を行うプラグインと、サーバ１０５に処理を依頼するプラグインの両方が存在する場合もある。

指定された画像形成装置１０１内部で画像処理を行う場合は、サーバ１０５に処理を依頼する場合と比較して、サーバ１０５との通信時間が不要であるため、短い時間で処理を実行できる。一方、画像形成装置１０１内の他の機能とメモリを共有するため、場合によってはメモリが不足し、他の機能の動作に影響を与えることがある。サーバ１０５に画像処理を依頼する場合は、画像形成装置１０１のメモリを使用しないため、画像形成装置１０１の他の機能の動作に影響を与えないで済む。

即ち、画像形成装置１０１においてメモリ不足が発生しない場合には、画像形成装置１０１の内部で画像処理を行う画像処理プラグインアプリ３０３によって処理を実行した方が、サーバ１０５に処理を依頼するよりも処理時間を短縮できる可能性が高い。一方、画像形成装置１０１においてメモリ不足が発生する可能性がある場合には、サーバ１０５に画像処理を依頼する画像処理プラグインアプリ３０３によって処理を実行する方が好ましい。

そこで、画像処理プラグインアプリは、指定されたパラメータを満たす画像処理を行う際のメモリ使用量に応じて、指定された画像処理を画像処理プラグインアプリが実行可能かを判定することとしてもよい。

例えば、画像形成装置１０１内部で画像処理を行う画像処理プラグインアプリ３０３は、「入力画像解像度：６００ＤＰＩ」のような、入力解像度についてのパラメータを元に、実行可能か否か判断する。「入力画像解像度：６００ＤＰＩ」に対応する画像処理を実行するためには、実行時のＲＡＭ２１２使用量が多く、他の機能の実行に影響を及ぼす可能性がある。従って、画像形成装置１０１の内部で処理を行う画像処理プラグインアプリ３０３は、当該画像処理が実行不可能であると判断する。

また、サーバ１０５に処理を依頼する画像処理プラグインアプリ３０３は、サーバ１０５において十分にメモリ容量を確保することができるので、当該画像処理を実行することが可能であると判断する。

一方、パラメータが「入力画像解像度：３００ＤＰＩ」であれば、実行時のＲＡＭ２１２使用量は、６００ＤＰＩの場合に比べて少なく、他の機能の実行に影響を及ぼす可能性が低い。そこで、画像形成装置１０１の内部で処理を行う画像処理プラグインアプリ３０３は、当該画像処理を実行可能であると判断する。

Ｓ９０７において、接続ライブラリ３３２は、指定されたパラメータをもとに処理を実行することができる画像処理プラグインアプリ３０３が存在するか否か判断する。存在する場合は、Ｓ９０８へ、存在しない場合は、Ｓ９０９へ進む。

本実施形態で示した方法によると、二段階のフィルタを動作させて、画像処理プラグインアプリ３０３の選択を行うことで、処理速度、及び柔軟性を両立させることが可能になる。

＜変形例＞
本発明は上記実施形態に限らず様々な変形が可能である。例えば、画像形成装置１０１内部で画像処理を行う画像処理プラグインアプリ３０３は、画像処理の実行可否を、指定されたパラメータだけでなく、画像形成装置１０１のＲＡＭ２１２の使用状況に応じて、動的に判断を行うこととしてもよい。

例えば、画像形成装置１０１内部で処理を行う画像処理プラグインアプリ３０３は、パラメータとして「入力画像解像度：６００ＤＰＩ」が入力された場合でも、ＲＡＭ２１２の空き容量が所定の容量以上である場合は、当該画像処理を実行可能と判断する。一方、画像形成装置１０１内部で処理を行う画像処理プラグインアプリ３０３は、ＲＡＭ２１２の空き容量が所定の容量未満の場合は、パラメータとして「入力画像解像度：６００ＤＰＩ」が入力されると、当該画像処理を実行することはできないと判断する。

上記の処理を、図１０のフローチャートを用いて説明する。本フローチャートによる処理は、ＣＰＵ２１１が画像処理プラグインアプリ３０３を実行することによって実現される。以下で説明する処理は、例えば、ＣＰＵ２１１がＨＤＤ２１３に格納されたプログラムをＲＡＭ２１２に展開して、実行することによって実現される。

Ｓ１００１で、画像処理プラグインアプリ３０３は、指定されたパラメータに応じた画像処理を実行するために必要な、メモリ空き容量の閾値を取得する。例えば、画像処理プラグインアプリ３０３は、画像処理のパラメータと、メモリの容量に関する閾値とを対応付けた情報を管理しており、当該情報を参照して、指定されたパラメータに対応する閾値を取得する。当該対応付け情報は、例えば、画像処理プラグインアプリ３０３のインストール時に、画像形成装置１０１のＨＤＤ２１３等の記憶部に記憶される。

次に、Ｓ１００２で、画像処理プラグインアプリ３０３は、ＲＡＭ２１２の空き容量を取得する。Ｓ１００２は、画像形成装置１０１のメモリの使用状況を取得する容量取得処理である。続いて、Ｓ１００３で、画像処理プラグインアプリ３０３は、Ｓ１００２で取得した空き容量が、Ｓ１００１で取得した閾値以上であるか否かを判定する。

画像処理プラグインアプリ３０３は、Ｓ１００２で取得した空き容量が、Ｓ１００１で取得した閾値以上である場合には、Ｓ１００４に進み、指定された画像処理を実行可能であると接続ライブラリ３３２に応答して処理を終了する。一方、画像処理プラグインアプリ３０３は、Ｓ１００２で取得した空き容量が、Ｓ１００１で取得した閾値未満である場合には、Ｓ１００５に進み、指定された画像処理の実行が不可能であると接続ライブラリ３３２に応答して処理を終了する。

以上のようにして、画像処理プラグインアプリ３０３は、メモリの使用状況と、メモリの使用状況に関する閾値とに基づいて、特定のプラグインアプリケーションが、パラメータに応じた画像処理を実行可能か否か判定する。このようにして、画像形成装置１０１のメモリ使用状況に応じて動的に、指定された画像処理の実行の可否を応答することができる。また接続ライブラリ３３２は、応答された内容（判定結果）に基づいて、指定されたパラメータに応じた画像処理を実行可能なプラグインアプリケーションを選択することができる。

本変形例では、画像処理プラグインアプリ３０３が、指定された画像処理の実行可否を判定する例について説明したが、これに限らず、接続ライブラリ３３２が当該判定を行うこととしてもよい。例えば、接続ライブラリ３３２が、画像処理プラグインアプリ３０３の識別情報と、画像処理のパラメータと、メモリの容量に関する閾値と関連付けて管理する。そして、判定対象の画像処理プラグインアプリ３０３の識別情報に関連付けられたパラメータと閾値に基づいて、図１０に示した処理と同様の処理を実行することとしてもよい。この場合、図１０に示した処理は、ＨＤＤ２１３に記憶されたプログラムコードをＲＡＭ２１２に展開し、ＣＰＵ２１１が実行することにより実現される。

Ｓ１００４では、接続ライブラリ３３２は、判定対象の画像処理プラグインアプリ３０３が指定された処理を実行可能であると判定する。またＳ１００５では、接続ライブラリ３３２は、判定対象の画像処理プラグインアプリ３０３が指定された処理を実行することができないと判定する。

以上のようにしても、画像形成装置１０１のメモリ使用状況に応じて動的に、指定された画像処理の実行の可否を判定することができる。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１、１０２：画像形成装置、１０３、１０４：情報処理端末、１０５：サーバ、２０１：コントローラ、２０２：プリンタ、２０３：スキャナ、２０４：操作部、２１１：ＣＰＵ、２１２：ＲＡＭ、２１３：ＨＤＤ、２１４：ネットワークＩ／Ｆ、２１５：プリンタＩ／Ｆ、２１６：スキャナＩ／Ｆ、２１７：操作部Ｉ／Ｆ、２１８：拡張Ｉ／Ｆ

Claims (5)

1. １以上の機能を提供し、さらに、プラグインアプリケーションをインストールすることにより、提供する機能を追加可能な画像処理装置であって、
   所定の処理を実行する要求を受け付ける受付手段と、
   前記受付手段によって受け付けた前記要求から前記所定の処理の識別情報と、該所定の処理を実行する際に用いるパラメータと、を取得する取得手段と、
   前記所定の処理を実行できるかどうかを、前記画像処理装置にインストールされた１以上のプラグインアプリケーションのそれぞれに前記識別情報を通知することで、問い合わせる問合せ手段と、
   問い合わせの結果で特定された前記所定の処理を実行できるプラグインアプリケーションに、前記パラメータを用いた前記所定の処理を指示する指示手段と、
   を備えることを特徴とする画像処理装置。
2. 前記問合せ手段は、前記識別情報を用いた前記問い合わせの結果で特定された前記プラグインアプリケーションに対して、前記パラメータを用いた前記所定の処理が実行できるかどうかのさらなる問い合わせを行い、
   前記指示手段は、前記さらなる問い合わせの結果で前記パラメータを用いた前記所定の処理を実行できることが特定されたプラグインアプリケーションに対して、前記パラメータを用いた前記所定の処理を指示することを特徴とする請求項１に記載の画像処理装置。
3. 前記所定の処理がＯＣＲ処理である場合において、
   前記識別情報は、ＯＣＲの文字列を含み、
   前記パラメータは、ＯＣＲの言語を示すことを特徴とする請求項１または２に記載の画像処理装置。
4. 前記パラメータは、前記所定の処理が施される入力画像の解像度を示すことを特徴とする請求項１または２に記載の画像処理装置。
5. 前記問合せ手段による問い合わせの結果で、外部装置が提供する画像処理クライアントを前記所定の処理を実行可能なプラグインアプリケーションとして特定された場合、前記指示手段は、前記画像処理クライアントに対して前記パラメータを用いた前記所定の処理を指示することを特徴とする請求項１乃至４の何れか１項に記載の画像処理装置。

Images