JP6975009B2 - 画像処理装置及びその制御方法、並びにプログラム - Google Patents

Description

本発明は、画像処理装置及びその制御方法、並びにプログラムに関するものである。

情報処理を実行するソフトウェアを開発する際、開発効率を重視したプログラミング言語（例えば、Ｊａｖａ（登録商標）言語）と処理速度を重視したプログラミング言語（例えば、Ｃ言語又はＣ＋＋言語）とを併用することがある。例えば、頻繁に更新するプログラム（例えば、アプリケーションプログラム）の開発に、開発効率を重視したプログラミング言語を利用する。一方で、複雑な演算を行うプログラム（例えば、画像処理プログラム）の開発に、処理速度を重視したプログラミング言語を利用する。これにより、頻繁に更新するプログラムの開発効率を向上させながら、複雑な演算を行うプログラムを高速に動作させる構成を実現できる。また、開発効率を重視したプログラミング言語として、Ｊａｖａ言語のように、メモリ管理の自動化機能（プログラム内で使用するメモリ領域の管理を自動的に行う機能）を有するものを利用すると、実装時の手間の軽減と開発効率の更なる向上が可能である。

上述のように異なるプログラミング言語を併用する技術として、特許文献１には、組み込みシステムのソフトウェア開発環境において、図的プログラミング言語とＣ言語等のテキスト形式のプログラミング言語とを併用する技術が開示されている。特許文献１では、一方のプログラミング言語で開発された実行プログラムと、他方のプログラミング言語で開発された実行プログラムとを同一の実行環境で動作させ、実行プログラム間での呼び出しを可能にしている。

特開２０１３−１７８６０６号公報

しかしながら、異なるプログラミング言語間でのプログラムの呼び出しを可能にする、一般的な呼び出し機構においては、呼び出し側のプログラムと呼び出された側のプログラムとで、論理メモリ空間を共有してしまう。このような論理メモリ空間の共有が生じると、呼び出された側のプログラムによるメモリ操作の不具合が、呼び出し側のプログラムの動作に影響する可能性がある。

上述のようなメモリ操作の不具合は、メモリ管理の自動化機能が無いプログラミング言語で開発されたプログラムにおいて発生しうる。例えば、メモリ管理の自動化機能が無いプログラミング言語で開発された画像処理プログラムが、アプリケーションプログラム（アプリケーション）から呼び出され、当該画像処理プログラムによるメモリ操作に不具合が発生する場合がある。このメモリ操作の不具合によって、アプリケーションが使用しているメモリ領域が影響を受けると、当該アプリケーションの動作に異常が発生する。例えば、アプリケーションが管理している顧客データの消失やアプリケーションが制御している印刷処理の予期せぬ終了等の異常が生じ、当該アプリケーションが実装されている装置自体の動作に問題が生じる結果となる。

本発明は、上述の問題に鑑みてなされたものである。本発明は、異なるプログラミング言語で開発されたプログラム間で、一方のプログラムにおけるメモリ操作の不具合が他方のプログラムの動作に影響することを防止する技術を提供することを目的とする。

本発明の一態様に係る画像処理装置は、第１プログラミング言語による第１実行環境で実行される第１プログラムに対応するプラグインアプリケーションと、前記プラグインアプリケーションからの要求に従って、第２プログラミング言語による第２実行環境で実行される第２プログラムを用いた画像処理の実行を要求する処理要求を送信する、前記第１実行環境で動作するクライアントと、前記クライアントから送信された前記処理要求を受信し、受信した前記処理要求に従って前記第２プログラムを実行することにより前記画像処理を実行する、前記第２実行環境で動作するサーバと、を備え、前記サーバは、前記第１実行環境で使用されるメモリ空間とは独立したメモリ空間を使用するプロセス上で動作し、前記処理要求は、前記画像処理の対象となるデータ及び前記画像処理に関するパラメータと、前記第２プログラムのライブラリ及び関数の指定と、を含むことを特徴とする。

本発明によれば、異なるプログラミング言語で開発されたプログラム間で、一方のプログラムにおけるメモリ操作の不具合が他方のプログラムの動作に影響することを防止できる。

画像形成システムの構成例を示す図 画像形成装置のハードウェア構成例を示すブロック図 画像形成装置のソフトウェア構成例を示すブロック図 画像処理プラグインアプリによる処理の手順を示すフローチャート Ｎａｔｉｖｅサーバによる処理の手順を示すフローチャート Ｎａｔｉｖｅサーバによる処理の手順を示すフローチャート 画像形成装置における画像処理システムの構成例を示す図

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

以下の第１乃至第４実施形態では、画像形成装置に本発明を適用した例について説明する。なお、本発明は、情報処理装置であれば適用可能であり、例えば、印刷装置、複写機、複合機及びファクシミリ装置等の画像形成装置だけでなく、ＰＣ、携帯電話及びスマートフォン等の情報処理端末にも適用可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態では、特に、拡張処理プラグイン３とＮａｔｉｖｅモジュール７０３とでプロセス及びメモリの使用領域を分けることによって、一方で発生したエラー（メモリ操作の不具合）が他方に影響を及ぼさないようにする構成について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（画像処理プラグインアプリ３０３）
次に、画像処理プラグインアプリ３０３について、より具体的に説明する。画像処理プラグインアプリ３０３は、特定の画像処理を提供するアプリである。なお、画像処理プラグインアプリ３０３は、それぞれ異なる画像処理を実行する複数のアプリで構成されてもよい。例えば、入力画像に対して画像形式変換、斜行補正、帳票認識、及びＯＣＲ処理等をそれぞれ実行可能な複数のアプリが、画像処理プラグインアプリ３０３として画像形成装置１０１にインストールされてもよい。本実施形態では、図７の拡張処理プラグイン１〜３に対応する３つのアプリが、画像処理プラグインアプリ３０３としてインストールされている。

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

画像処理プラグインアプリ３０３は、受け付けた画像処理要求に従って、画像処理を実行する。画像処理要求には、処理対象の画像データ及び処理パラメータが含まれうる。また、画像処理プラグインアプリ３０３は、画像処理要求に基づいて、必要に応じて、Ｎａｔｉｖｅクライアント３３１の画像処理機能を利用することが可能である。なお、画像処理プラグインアプリ３０３は、それ自体が画像処理機能を有していなくてもよい。画像処理プラグインアプリ３０３は、画像処理機能を有していなくても、Ｎａｔｉｖｅクライアント３３１を利用することによって、Ｎａｔｉｖｅモジュール３１６の画像処理機能を利用することが可能である。本実施形態では、拡張処理プラグイン３（図７）に対応する画像処理プラグインアプリ３０３は、Ｎａｔｉｖｅクライアント３３１を介して、Ｎａｔｉｖｅモジュール３１６（Ｎａｔｉｖｅモジュール７０３）の画像処理機能を利用する。

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

このように、本実施形態の画像形成装置１０１は、Ｊａｖａ実行環境３３０で実行されるプログラムから、Ｃ／Ｃ＋＋実行環境で実行されるプログラムを呼び出す仕組みとして、Ｎａｔｉｖｅクライアント３３１及びＮａｔｉｖｅサーバ３１５を有する。このＮａｔｉｖｅクライアント３３１は、Ｊａｖａ実行環境３３０で動作し、Ｎａｔｉｖｅサーバ３１５は、Ｃ／Ｃ＋＋実行環境で動作する。なお、Ｊａｖａ実行環境３３０は、第１プログラミング言語（Ｊａｖａ言語）に対応する第１実行環境の一例であり、Ｃ／Ｃ＋＋実行環境は、第２プログラミング言語（Ｃ／Ｃ＋＋言語）に対応する第２実行環境の一例である。

Ｎａｔｉｖｅクライアント３３１は、Ｊａｖａ実行環境３３０で実行される画像処理プラグインアプリ３０３からの要求に従って、Ｃ／Ｃ＋＋実行環境で実行されるＮａｔｉｖｅモジュール３１６を用いた画像処理の実行を要求する処理要求を送信する。Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１から送信された処理要求を受信し、受信した処理要求に従ってＮａｔｉｖｅモジュール３１６を実行することにより画像処理を実行する。このＮａｔｉｖｅサーバ３１５は、Ｊａｖａ実行環境３３０で使用されるメモリ空間とは独立したメモリ空間を使用するＮａｔｉｖｅ制御プロセス３５０上で動作する。

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

＜画像処理プラグインアプリによる処理手順＞
図４は、本実施形態に係る、画像処理プラグインアプリ３０３による処理の手順を示すフローチャートである。図４の各ステップの処理は、ＨＤＤ２１３に格納されているプログラムをＣＰＵ２１１がＲＡＭ２１２に展開して実行することによって実現される。本フローチャートは、画像処理プラグインアプリ３０３が、要求元から画像処理要求を受け付けた場合に、Ｎａｔｉｖｅモジュール３１６の画像処理機能を利用するための処理の手順を示している。画像処理要求の要求元（送信元）は、上述のように、Ｊａｖａ実行環境３３０で動作する単独機能プラグインアプリ３０２及びデバイス制御アプリ３０４、並びにＣ／Ｃ＋＋実行環境で動作するデバイス制御ライブラリ３０９のいずれかである。

なお、ＣＰＵ２１１は、画像形成装置１０１の起動時に、Ｊａｖａ実行環境３３０においてＮａｔｉｖｅクライアント３３１を起動し、Ｃ／Ｃ＋＋実行環境においてＮａｔｉｖｅ制御プロセス３５０を起動する。更に、ＣＰＵ２１１は、Ｎａｔｉｖｅ制御プロセス３５０上で、Ｎａｔｉｖｅサーバ３１５を起動する。このため、画像処理プラグインアプリ３０３が画像処理要求を受け付ける際には、Ｎａｔｉｖｅクライアント３３１及びＮａｔｉｖｅサーバ３１５は、既に動作しており、画像処理プラグインアプリ３０３からの利用が可能な状態にある。

画像処理プラグインアプリ３０３は、画像処理要求を要求元から受信すると、図４に示す手順による処理を開始する。まずＳ４０１で、画像処理プラグインアプリ３０３は、受信した画像処理要求に含まれる、画像処理（情報処理）の対象となる画像データを検証する。本ステップでは、例えば、画像データについての画像形式及び画像サイズが確認される。ただし、必要に応じて他の項目について検証が行われてもよい。次にＳ４０２で、画像処理プラグインアプリ３０３は、受信した画像処理要求に含まれる、画像処理（情報処理）に関する処理パラメータを検証する。本ステップでは、例えば、処理パラメータが示す、ＯＣＲのための言語（日本語／英語等）の指定が確認される。

次にＳ４０３で、画像処理プラグインアプリ３０３は、画像処理要求によって要求された画像処理の内容に従って、使用するＮａｔｉｖｅモジュール３１６のライブラリ名及び関数名を特定する。ライブラリ名は、オブジェクトファイルのファイル名を表し、例えば、Ｌｉｎｕｘ（登録商標）又はＷｉｎｄｏｗｓで用いられる動的共有ライブラリのファイル名（拡張子「．ｓｏ」又は「．ｄｌｌ」を有するファイル名）である。また、関数名は、ライブラリ名によって特定されたオブジェクトファイルに含まれる関数の名称を表す。このように、画像処理プラグインアプリ３０３は、画像処理要求の要求元から受け付けた画像データ及び処理パラメータに基づいて、Ｎａｔｉｖｅサーバ３１５が使用すべきライブラリ及び関数を特定する。

ライブラリ名及び関数名の特定後、Ｓ４０４で、画像処理プラグインアプリ３０３は、使用するＮａｔｉｖｅモジュール３１６に入力する画像データを準備し、Ｓ４０５で、使用するＮａｔｉｖｅモジュール３１６に入力する処理パラメータを準備する。

その後、Ｓ４０６で、画像処理プラグインアプリ３０３は、Ｓ４０４及びＳ４０５でそれぞれ準備した画像データ及び処理パラメータを含む画像処理要求を、Ｎａｔｉｖｅクライアント３３１へ送信する。この画像処理要求には、画像処理に使用するライブラリ及び関数の指定として、Ｓ４０３で特定されたライブラリ名及び関数名も含められる。これにより、画像処理プラグインアプリ３０３は、Ｎａｔｉｖｅクライアント３３１に画像処理の実行を要求する。当該要求を受けたＮａｔｉｖｅクライアント３３１は、Ｎａｔｉｖｅサーバ３１５に対して、所定の方法で画像処理要求を行う。なお、Ｎａｔｉｖｅサーバ３１５は、後述する図５に示す手順で、画像処理要求に従った画像処理を実行する。

次にＳ４０７で、画像処理プラグインアプリ３０３は、Ｎａｔｉｖｅクライアント３３１から、画像処理の実行結果を受信したか否かを判定する。画像処理プラグインアプリ３０３は、画像処理要求に従った画像処理の実行結果を、Ｎａｔｉｖｅサーバ３１５からＮａｔｉｖｅクライアント３３１を介して受信すると、処理をＳ４０８へ進める。なお、後述するように、Ｎａｔｉｖｅ制御プロセス３５０上で動作しているＮａｔｉｖｅサーバ３１５による画像処理が完了すると、Ｎａｔｉｖｅサーバ３１５からＮａｔｉｖｅクライアント３３１へ、画像処理の実行結果が送信される。

Ｓ４０８で、画像処理プラグインアプリ３０３は、画像処理の要求元に対して返却する、画像処理の実行結果を示すデータを準備して当該要求元へ送信し、処理を終了する。なお、返却するデータは、要求された画像処理の内容に応じて変化する。例えば、画像形式変換が要求された場合には、返却するデータには変換後の画像データが含まれる。また、帳票認識が要求された場合には、返却するデータには帳票種別等のメタデータが含まれる。

＜Ｎａｔｉｖｅサーバによる処理手順＞
図５は、本実施形態に係る、Ｎａｔｉｖｅサーバ３１５による処理の手順を示すフローチャートである。図５の各ステップの処理は、ＨＤＤ２１３に格納されているプログラムをＣＰＵ２１１がＲＡＭ２１２に展開して実行することによって実現される。

Ｎａｔｉｖｅサーバ３１５の起動が行われると、Ｎａｔｉｖｅサーバ３１５は、図５に示す手順による処理を開始する。まずＳ５０１で、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１から処理要求を待ち受けるための準備処理を行う。本実施形態では、Ｎａｔｉｖｅサーバ３１５は、ＴＣＰ／ＩＰ通信によりＮａｔｉｖｅクライアント３３１から処理要求を受信する。このため、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１とのＴＣＰ／ＩＰ通信のためのサーバソケットを生成し、生成したソケットによって通信の待ち受けを行う。なお、ＴＣＰ／ＩＰ通信ではなく、例えば、ＩＰＣ（Interprocess Communication）メッセージキュー等を用いた待ち受けが行われてもよい。

Ｓ５０１の準備処理が完了すると、次にＳ５０２で、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１からの処理要求を待ち受ける。Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１から処理要求を受信したか否かを判定する。Ｎａｔｉｖｅサーバ３１５は、処理要求の受信を検知すると、Ｓ５０２からＳ５０３へ処理を進める。

Ｓ５０３で、Ｎａｔｉｖｅサーバ３１５は、受信した処理要求の内容が、画像処理要求であるかシャットダウン要求であるかを判定する。処理要求の内容がシャットダウン要求である場合、Ｎａｔｉｖｅサーバ３１５は、Ｓ５０３からＳ５１０へ処理を進め、処理要求の待ち受けを終了するための終了処理を行い、処理を終了する。一方、受信した処理要求の内容が画像処理要求である場合、Ｎａｔｉｖｅサーバ３１５は、Ｓ５０３からＳ５０４へ処理を進める。

Ｓ５０４で、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅモジュール３１６に、受信した画像処理要求に含まれるライブラリ名に対応するライブラリ（画像処理要求において指定されたライブラリ）が存在するか否かを判定する。Ｎａｔｉｖｅサーバ３１５は、指定されたライブラリが存在しない場合には、Ｓ５０９へ処理を進め、画像処理エラーの発生をＮａｔｉｖｅクライアント３３１へ通知し、処理をＳ５０２へ戻す。その後、Ｎａｔｉｖｅサーバ３１５は、再び、Ｎａｔｉｖｅクライアント３３１からの処理要求を待ち受ける。一方、Ｎａｔｉｖｅサーバ３１５は、指定されたライブラリが存在する場合には、Ｓ５０５へ処理を進める。

Ｓ５０５で、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅモジュール３１６のライブラリのうち、指定されたライブラリを、ＨＤＤ２１３からＲＡＭ２１２にロードする。その後、Ｓ５０６で、Ｎａｔｉｖｅサーバ３１５は、ＲＡＭ２１２にロードされたライブラリ内に、受信した画像処理要求に含まれる関数名に対応する関数（画像処理要求において指定された関数）が存在するか否かを判定する。Ｎａｔｉｖｅサーバ３１５は、指定された関数が存在しない場合には、Ｓ５０９へ処理を進め、画像処理エラーの発生をＮａｔｉｖｅクライアント３３１へ通知し、処理をＳ５０２へ戻す。その後、Ｎａｔｉｖｅサーバ３１５は、再び、Ｎａｔｉｖｅクライアント３３１からの処理要求を待ち受ける。一方、Ｎａｔｉｖｅサーバ３１５は、指定された関数が存在する場合には、Ｓ５０７へ処理を進める。

Ｓ５０７で、Ｎａｔｉｖｅサーバ３１５は、指定された関数の引数に、処理対象の画像データ及び処理パラメータを指定し、当該関数を実行することにより、画像処理要求に従った画像処理を実行する。更に、当該関数の実行が完了すると、Ｓ５０８で、Ｎａｔｉｖｅサーバ３１５は、画像処理の実行結果を、要求元（Ｎａｔｉｖｅクライアント３３１）へ送信し、処理をＳ５０２へ戻す。その後、Ｎａｔｉｖｅサーバ３１５は、再び、Ｎａｔｉｖｅクライアント３３１からの処理要求を待ち受ける。

以上説明したように、本実施形態では、Ｎａｔｉｖｅサーバ３１５は、Ｃ／Ｃ＋＋実行環境で動作し、Ｎａｔｉｖｅクライアント３３１からの処理要求に従って、Ｎａｔｉｖｅモジュール３１６（第２プログラム）を実行することにより、画像処理を実行する。Ｎａｔｉｖｅサーバ３１５は、Ｊａｖａ実行環境３３０で使用されるメモリ空間とは独立したメモリ空間を使用するＮａｔｉｖｅ制御プロセス３５０上で動作する。

本実施形態によれば、Ｎａｔｉｖｅ制御プロセス３５０上でのＮａｔｉｖｅサーバ３１５によるメモリサーバの不具合が、Ｎａｔｉｖｅサーバ３１５に画像処理の実行を要求する側のアプリの動作に影響することを防止できる。例えば、デバイス制御アプリ３０４からの要求に従ってＮａｔｉｖｅモジュール３１６が動作する際に、メモリ操作に関する不具合が発生した場合でも、その影響は、Ｎａｔｉｖｅ制御プロセス３５０内に限定される。そのため、このような不具合が発生した場合でも、デバイス制御アプリ３０４がＲＡＭ２１２に保持している送信先データベースや、デバイス制御ライブラリ３０９による印刷制御等に影響を及ぼすことを防止できる。このように、異なるプログラミング言語で開発されたプログラム間で、一方のプログラムにおけるメモリ操作の不具合が他方のプログラムの動作に影響することを防止できる。

［第２実施形態］
次に、第２実施形態について説明する。なお、第１実施形態と共通する部分の説明を省略し、第１実施形態との相違点について説明する。

第１実施形態では、Ｎａｔｉｖｅクライアント３３１からＮａｔｉｖｅサーバ３１５への画像処理要求の送信に、ＴＣＰ／ＩＰ通信が用いられ、この画像処理要求には、処理対象の画像データ及び処理パラメータが含められる。このため、処理対象の画像データのサイズが大きくなるほど、画像処理要求のための通信時間（画像データの転送に要する時間）が長くなりうる。

例えば、処理対象の画像データのサイズが８０ＭＢ、通信の転送スループットが１００Ｍｂｐｓ、画像処理後の画像データのサイズが処理対象の画像データのサイズと同じであるとする。この場合、画像形成装置１０１内における、Ｎａｔｉｖｅクライアント３３１とＮａｔｉｖｅサーバ３１５との間の画像データの転送に約０．２秒を要することになる。仮に画像処理が約０．５秒で完了すると、画像処理に要する時間に対して４０％程度の時間が画像データの転送に要することになり、画像処理要求に対応する処理の全体に占めるオーバヘッドが無視できない割合となりうる。

そこで、本実施形態では、Ｎａｔｉｖｅクライアント３３１は、画像データそのものを画像処理要求に含めてＮａｔｉｖｅサーバ３１５へ送信せず、画像データを特定できる情報（識別情報）を画像処理要求に含めて送信する。画像データを特定できる情報として、例えば「/var/docs/01/doc00001.tif」のような、ＨＤＤ２１３のファイルパス、又はスキャン保存ライブラリ３１２が管理する画像データのＩＤ等が使用されうる。一般的には、このような情報のサイズは画像データのサイズよりも大幅に小さい。したがって、上述の処理により、Ｎａｔｉｖｅクライアント３３１とＮａｔｉｖｅサーバ３１５との間の通信時間を短くすることが可能である。

以上説明したように、Ｎａｔｉｖｅクライアント３３１は、画像処理の対象となる画像データを画像処理要求に含めずに、当該画像データをＮａｔｉｖｅサーバ３１５が特定するための情報を、処理パラメータとともに画像処理要求に含めて送信する。これにより、画像処理プラグインアプリ３０３がＮａｔｉｖｅモジュール３１６の画像処理機能を利用する際の処理時間を短くすることが可能である。その結果、Ｎａｔｉｖｅモジュール３１６を利用した画像処理を、より高速化することが可能である。

［第３実施形態］
次に、第３実施形態について説明する。なお、第１実施形態と共通する部分の説明を省略し、第１実施形態との相違点について説明する。

第１実施形態では、Ｎａｔｉｖｅサーバ３１５は、Ｎａｔｉｖｅクライアント３３１から画像処理要求を受け付けると、要求された画像処理に対応する関数を呼び出し、関数の実行結果を、画像処理の実行結果として返却する。その後、Ｎａｔｉｖｅサーバ３１５は、再び処理要求を受け付ける状態となる。このように、Ｎａｔｉｖｅサーバ３１５は、画像処理要求を受け付けた順に、要求された画像処理を行う。この場合、Ｎａｔｉｖｅサーバ３１５は、複数の画像処理要求が生じると、先に受信した画像処理要求に対応する画像処理が完了するまで、次の画像処理要求に対応する画像処理を開始することができない。

例えば、Ｎａｔｉｖｅサーバ３１５が、スキャン送信アプリ３０８からの要求により、サーバ１０５へ転送する画像データを生成するための画像処理を行っている間に、ユーザが操作部２０４を用いてコピーアプリ３０６の操作を行う場合がありうる。この場合、Ｎａｔｉｖｅサーバ３１５は、スキャン送信アプリ３０８から要求された画像処理が完了するまで、次の画像処理（コピーアプリ３０６から要求される画像処理）を開始することがない。このため、コピーアプリ３０６を使用するユーザを待たせることになり、ユーザにとっての利便性が低下する可能性がある。

そこで、本実施形態では、Ｎａｔｉｖｅサーバ３１５は、複数の画像処理要求に対応する複数の画像処理を並列に実行するために、画像処理要求を受け付ける（受信する）ごとに、画像処理を行うためのスレッドを新規に生成する。このスレッドは、Ｎａｔｉｖｅ制御プロセス３５０が有するメモリ空間を使用する新たなスレッドである。これにより、Ｎａｔｉｖｅサーバ３１５は、画像処理要求を待ち受ける処理と、受け付けた画像処理要求に対応する画像処理とを並列に実行する。

図６は、本実施形態に係る、Ｎａｔｉｖｅサーバ３１５による処理の手順を示すフローチャートである。図６の各ステップの処理は、ＨＤＤ２１３に格納されているプログラムをＣＰＵ２１１がＲＡＭ２１２に展開して実行することによって実現される。

Ｓ５０１〜Ｓ５０３は、第１実施形態と同様である。ただし、Ｓ５０３において、処理要求の内容が画像処理要求であると判定した場合、Ｎａｔｉｖｅサーバ３１５は、Ｓ６０１へ処理を進める。Ｓ６０１で、Ｎａｔｉｖｅサーバ３１５は、受信した画像処理要求に対応する画像処理を行うためのスレッドを新規に生成（起動）する。

Ｓ６０１における新規スレッドの生成後、Ｎａｔｉｖｅサーバ３１５は、新規スレッドを用いた処理をＳ５０４へ進め、それと並行して、元のスレッドを用いた処理を、Ｓ５０２に戻す。これにより、Ｎａｔｉｖｅサーバ３１５は、新規スレッドを用いて、第１実施形態と同様、Ｓ５０４以降の処理を実行する。一方、Ｎａｔｉｖｅサーバ３１５は、新規スレッドを用いた処理と並行して、元のスレッドを用いて、第１実施形態と同様、Ｓ５０２においてＮａｔｉｖｅクライアント３３１からの新たな処理要求を待ち受ける（受信する）。このように、本実施形態において、新規スレッドは、Ｓ５０４以降の処理を行うためのスレッドであり、元のスレッドは、新たな処理要求を待ち受けるためのスレッドである。

本実施形態によれば、Ｎａｔｉｖｅサーバ３１５が、複数の画像処理要求が受信した場合でも、それぞれの要求に対応する画像処理を並行して実行することが可能になり、処理時間を短縮することが可能になる。このため、ユーザにとっての利便性を向上させることが可能である。

［第４実施形態］
次に、第４実施形態について説明する。なお、第３実施形態と共通する部分の説明を省略し、第３実施形態との相違点について説明する。

第３実施形態では、Ｎａｔｉｖｅサーバ３１５が、画像処理要求を受け付けるごとに、画像処理を行うためのスレッドを新規に生成することによって、複数の画像処理要求を同時に受け付けることを可能にしている。これに対し、本実施形態では、Ｎａｔｉｖｅサーバ３１５は、画像処理要求を受け付けるごとに、Ｓ６０１において、新規スレッドを生成する代わりに、Ｎａｔｉｖｅ制御プロセス３５０とは別の新たなプロセスを生成する。このプロセスは、Ｊａｖａ実行環境３３０で使用されるメモリ空間及びＮａｔｉｖｅ制御プロセス３５０が使用するメモリ空間とは独立したメモリ空間を使用する。更に、Ｎａｔｉｖｅサーバ３１５は、生成したプロセス上で、Ｓ５０４以降の処理を行う。

このように本実施形態では、Ｎａｔｉｖｅサーバ３１５は、Ｓ６０１の処理において、新規スレッドを起動するのではなく、新規プロセスを起動し、当該新規プロセスで、画像処理要求に対応する画像処理を行う。一方、Ｎａｔｉｖｅサーバ３１５は、元のプロセスで、Ｓ５０２においてＮａｔｉｖｅクライアント３３１からの新たな処理要求を待ち受ける。

本実施形態によれば、同時に実行する画像処理間においても、使用する論理メモリ空間を分離することが可能になる。それにより、或る画像処理におけるメモリ操作の不具合が、他の画像処理に影響することを防止でき、画像形成装置１０１の動作の安定性を更に向上させることが可能になる。

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

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

Claims (12)

1. 第１プログラミング言語による第１実行環境で実行される第１プログラムに対応するプラグインアプリケーションと、
   前記プラグインアプリケーションからの要求に従って、第２プログラミング言語による第２実行環境で実行される第２プログラムを用いた画像処理の実行を要求する処理要求を送信する、前記第１実行環境で動作するクライアントと、
   前記クライアントから送信された前記処理要求を受信し、受信した前記処理要求に従って前記第２プログラムを実行することにより前記画像処理を実行する、前記第２実行環境で動作するサーバと、を備え、
   前記サーバは、前記第１実行環境で使用されるメモリ空間とは独立したメモリ空間を使用するプロセス上で動作し、
   前記処理要求は、前記画像処理の対象となるデータ及び前記画像処理に関するパラメータと、前記第２プログラムのライブラリ及び関数の指定と、を含む
   ことを特徴とする画像処理装置。
2. 前記サーバは、前記クライアントから受信した前記処理要求で指定されたライブラリに含まれる、前記処理要求で指定された関数の引数に、前記データ及び前記パラメータを指定して、前記関数を実行することによって、前記画像処理を実行する
   ことを特徴とする請求項１に記載の画像処理装置。
3. 前記プラグインアプリケーションは、前記画像処理の対象となるデータ及び前記画像処理に関するパラメータに基づいて、前記サーバが使用すべきライブラリ及び関数を特定し、特定したライブラリ及び関数を用いた画像処理の実行を前記クライアントに要求する
   ことを特徴とする請求項１又は２に記載の画像処理装置。
4. 前記プラグインアプリケーションは、前記第１実行環境で動作する他のアプリケーション、又は前記第２実行環境で動作する他のアプリケーションから、前記画像処理の対象となるデータ及び前記画像処理に関するパラメータを含む要求を受け付ける
   ことを特徴とする請求項１から３のいずれか１項に記載の画像処理装置。
5. 前記プラグインアプリケーションは、前記処理要求に従った前記画像処理の実行結果を前記サーバから前記クライアントを介して受信すると、当該実行結果を示すデータを前記他のアプリケーションへ送信する
   ことを特徴とする請求項４に記載の画像処理装置。
6. 前記画像処理装置の起動時に、前記第１実行環境において前記クライアントを起動し、前記第２実行環境において前記プロセスを起動し、かつ、前記プロセス上で前記サーバを起動する起動手段を更に備える
   ことを特徴とする請求項１から５のいずれか１項に記載の画像処理装置。
7. 前記クライアントは、前記画像処理の対象となるデータを前記処理要求に含めずに、当該データを前記サーバが特定するための情報を、前記画像処理装置に関するパラメータとともに前記処理要求に含めて、当該処理要求を前記サーバへ送信する
   ことを特徴とする請求項１から６のいずれか１項に記載の画像処理装置。
8. 前記サーバは、前記クライアントから前記処理要求を受信したことに基づき、前記プロセスが有するメモリ空間を使用する新たなスレッドを生成し、当該新たなスレッドを用いて、前記処理要求に従って前記画像処理を実行する
   ことを特徴とする請求項１から７のいずれか１項に記載の画像処理装置。
9. 前記サーバは、前記プロセスが有するメモリ空間を使用する１つのスレッドを用いて、前記クライアントからの前記処理要求の受信を行い、前記クライアントから前記処理要求を受信したことに基づき、前記プロセスが有するメモリ空間を使用する新たなスレッドを、前記画像処理の実行のために生成する
   ことを特徴とする請求項８に記載の画像処理装置。
10. 前記サーバは、前記クライアントから前記処理要求を受信したことに基づき、前記第１実行環境で使用されるメモリ空間及び前記プロセスが使用するメモリ空間とは独立したメモリ空間を使用する新たなプロセスを生成し、当該新たなプロセス上で前記処理要求に従って前記画像処理を実行する
    ことを特徴とする請求項１から７のいずれか１項に記載の画像処理装置。
11. 画像処理装置の制御方法であって、
    第１プログラミング言語による第１実行環境で実行される第１プログラムに対応するプラグインアプリケーションからの要求に従って、第２プログラミング言語による第２実行環境で実行される第２プログラムを用いた画像処理の実行を要求する処理要求を送信するよう、前記第１実行環境でクライアントを動作させる工程と、
    前記クライアントから送信された前記処理要求を受信し、受信した前記処理要求に従って前記第２プログラムを実行することにより前記画像処理を実行するよう、前記第２実行環境でサーバを動作させる工程と、を含み、
    前記サーバは、前記第１実行環境で使用されるメモリ空間とは独立したメモリ空間を使用するプロセス上で動作し、
    前記処理要求は、前記画像処理の対象となるデータ及び前記画像処理に関するパラメータと、前記第２プログラムのライブラリ及び関数の指定と、を含む
    ことを特徴とする画像処理装置の制御方法。
12. 請求項１１に記載の画像処理装置の制御方法の各工程を前記画像処理装置に実行させるためのプログラム。

Images