JP3778190B2 - 画像処理装置 - Google Patents

Description

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

従来、会社のオフィス等では、セットされた原稿の画像を読み取るスキャンジョブ、原稿の画像を読み取って得られた画像データに基づいて用紙に印刷するコピージョブ、外部端末からの印刷指示に基づいて用紙に印刷するプリントジョブ、外部のファクシミリ装置との通信により画像を送受信するＦＡＸジョブなどの複数の機能を有する、いわゆるデジタル複合機（MFP：Multiple Function Peripheral。以下、「ＭＦＰ」という。）が普及している。

このようなＭＦＰを用いれば、ユーザにとっては、コピー機、プリンタ等の装置を個別に配置する必要がなく、１台で複数の機能を実行できるため、低コストであり使い勝手も良くなる。
一方で、ＭＦＰの開発者にとっては、スキャン機能等の各種機能に対応する複数のソフトウエア（アプリケーション。以下、「アプリ」という。）を開発する必要があるが、これらを個別に設ける構成としたのでは開発に多大な時間がかかってしまう。そのため、例えば特許文献１には、各アプリの共通部分を括り出したものと汎用ＯＳ（オペレーティング・システム）とでプラットフォームを形成し、アプリ開発時には当該プラットフォーム以外の部分を作成するだけの構成とすることで、効率良く開発を行えるようにした技術が開示されている。
特開２００２−８４３８３号公報

上記公報記載の構成とすれば、開発段階においては効率が良くなるものの、ユーザへの納品後に、ユーザから、現存のアプリには備えられていない機能を実行したい旨の要求（いわゆるカスタマイズの要求）を受けた場合には容易に対応できない。例えば、スキャン機能について、現在のスキャンアプリにより提供されている機能以外の読取モードで読取動作を行いたいような場合には、現存のアプリをそのユーザのためだけに全面的に変更する必要があり、大変な作業を強いられ、実際には困難である。すなわち、機能拡張性に極めて乏しい構成になっている。

本発明は、上述のような問題点に鑑みてなされたものであって、機能を容易に拡張でき、その場合に現存のアプリの変更をほとんど必要としない構成の画像処理装置を提供することを目的とする。

上記目的を達成するため、本発明に係る画像処理装置は、画像形成部、読み取り部、表示部の少なくとも一つを有するハードウェア資源と、前記ハードウェア資源の上位に位置するアプリケーションと、前記ハードウェア資源と前記アプリケーションの間に位置する第１の制御プログラムと、前記アプリケーションの上位に位置する第２の制御プログラムと、からなるアーキテクチャを有し、前記第１の制御プログラムは、予め定義された関数により前記アプリケーションおよび前記第２の制御プログラムからの画像処理に関する処理要求を受け付ける第１のＡＰＩ（アプリケーション・プログラム・インターフェース）を有し、受け付けた処理要求に基づく処理を前記ハードウェア資源に実行させ、前記第２の制御プログラムは、予め外部に公開された関数により前記外部から画像処理に関する処理要求を受け付ける第２のＡＰＩを有し、受け付けた処理要求を前記第１のＡＰＩに対応するコマンドに変換し、当該処理要求の内容に応じて前記アプリケーションまたは前記第１の制御プログラムのいずれかに渡すことを特徴とする。

また、前記外部からの画像処理に関する処理要求は、ＸＭＬで表されたものであり、前記第２の制御プログラムは、前記外部からの画像処理に関する処理要求をＸＭＬ形式のデータで受け付けることを特徴とする。
さらに、前記第２の制御プログラムは、受け付けたＸＭＬ形式のデータから前記処理要求を示す情報を抽出する第１の変換部と、抽出された情報を前記第１のＡＰＩに対応するコマンドに変換する第２の変換部と、を備えることを特徴とする。

本発明に係る画像処理装置は、第２の制御プログラムを有しているので、例えば当該装置がユーザに納品された後であっても、現存のアプリケーションに変更を加えることなく、当該アプリケーションでは実行できなかった新たな機能を第２の制御プログラムを利用して外部から実行させることが可能になり、機能拡張性が向上し、ユーザにとって使い勝手が大変良くなる。

そして、外部からの画像処理に関する処理要求がアプリケーションに対するものである場合には、当該処理要求が第２の制御プログラムから当該アプリケーションに直接渡されるので、例えば全てのデータが第１の制御プログラムを介して渡される構成に比べて、第１の制御プログラムの構成を簡素化できると共に処理負担を減らすことが可能になる。
また、外部からの画像処理に関する処理要求がＸＭＬ形式のデータで受け付けられる構成になっている。

これにより、外部ユーザは、画像処理装置に実行させたいジョブの画像処理に関する処理要求をＸＭＬを用いて記述することができ大変扱い易い。
さらに、画像処理装置が第１の変換部を備える構成になっている。
これにより、外部と画像処理装置との間の通信プロトコルとして、例えば周知のＳＯＡＰ等を用いることができ、外部ユーザによって簡易かつ扱い易い。

以下、本発明に係る画像処理装置としてのＭＦＰの実施の形態について図面を参照しながら説明する。
（１）ＭＦＰの構成
図１は、ＭＦＰ１のシステム構成を示す図である。
同図に示すように、ＭＦＰ１は、最下位層に位置するデバイス（ハードウエア資源）１０と、デバイス１０を直接制御する制御層２０と、制御層２０の上位に位置するアプリケーション層３０と、アプリケーション層３０の上に位置（実質的には、制御層２０とアプリケーション層３０の間に位置）する外部ＡＰＩ部４０が階層構造的に体系化されたアーキテクチュアからなり、上記スキャンジョブ、コピージョブ、プリントジョブ、ＦＡＸジョブなどの画像処理ジョブを実行する複数の機能を有するデジタル複合機である。また、外部機器、ここではＰＣ（パーソナルコンピュータ）５０とＬＡＮ等のネットワーク（不図示）を介して接続されており、例えばTCP/IP(Transmission Control Protocol/Internet Protocol)を用いて互いに各種データのやりとりが可能になっている。

デバイス１０には、画像形成部としてのプリンタ１１と、読み取り部としてのスキャナ１２と、操作パネル１３およびＩ／Ｏ１４が含まれている。
ここで、プリンタ１１は、周知の電子写真方式により画像データに基づいて画像を用紙に印刷（プリント）するものである。スキャナ１２は、セットされた原稿の画像をＣＣＤ（Charge Coupled Device）等の光電変換素子により読み取って画像データを得る公知の装置である。操作パネル１３は、入力キーや表示部としてのディスプレイ等を備え、操作者からのキー入力を受け付けると共に各種メッセージ等をディスプレイに表示させるものである。また、Ｉ／Ｏ１４は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、外部機器とのインターフェース装置（例えば、ＮＩＣ：Network Interface Card）等を含むものである。

制御層２０は、カーネル２１と、各デバイスの動作を制御するためのモジュール（ＩＪＣ：Image Job Controller）２２と、外部機器との通信制御を実行するためのインターフェースモジュール（ＩＯ：Input-Output ）２３と、ＩＯ ＡＰＩ、ＩＪＣ ＡＰＩ（以下、これらをまとめて「ＩＯ／ＩＪＣ ＡＰＩ」という。）２４とを備えており、ＯＳ（Operating System）として機能する。

ここで、ＩＯ／ＩＪＣ ＡＰＩ２４は、アプリケーション層３０の各アプリケーション３１〜３５にＩＪＣ２２とＩＯ２３の機能（すなわち、制御層２０の機能）を提供するためのＡＰＩ（アプリケーション・プログラム・インターフェース）であり、各アプリがこの機能を利用する際に呼び出すための関数の集まりである。すなわち、予め定義されたこれら関数により各アプリからの画像処理に関する処理要求を受け付ける機能を有するものである。

また、ＩＯ／ＩＪＣ ＡＰＩ２４は、ＰＣ５０に外部ＡＰＩ部４０を介して制御層２０の機能を提供するためのＡＰＩとしても機能する。この場合は、ＰＣ５０からの画像処理に関する処理要求を受け付けた外部ＡＰＩ部４０が、制御層２０の機能を利用する際に呼び出す（コールする）ための関数として用いられる。
外部ＡＰＩ部４０は、ＡＰＩ変換部４１、外部ＡＰＩ４２およびＸＭＬ変換部４３を備え、ＰＣ５０からの画像処理に関する処理要求を、制御層２０で実行できる所定の形式に変換して必要に応じて制御層２０または各アプリに渡すためのプログラムである。

外部ＡＰＩ４２は、外部に制御層２０の機能を提供するためのＡＰＩであり、ＰＣ５０が制御層２０の機能を利用する際に呼び出すための、予め定義された関数の集まりである。
この外部ＡＰＩ４２は、予め一般の外部ユーザ（例えば、ソフトウエア開発者等）に公開されるようになっており、外部ユーザは、この公開されたＡＰＩに基づいて制御層２０の機能を利用するためのソフトウエアを開発することができる。

具体的には、外部ユーザは、公開されたＡＰＩから、ＭＦＰ１のデバイス制御のために、どのようなコマンドやパラメータ類（例えば、実行させるべきジョブの指定、ジョブ開始の指示等を示すコマンド、スキャンジョブの場合の読み取りサイズ、送信宛先等、コピージョブの場合のコピー枚数等のジョブ実行条件を示すパラメータ等）が用意されており、そのコマンド等をどのような構文で記述すれば良いのかを知ることができる。

外部ユーザは、当該コマンド等を当該構文に基づいて記述したデータ（ここでは、ＸＭＬ（Extensible Markup Language）形式のデータ。図２参照）を画像処理に関する処理要求を含むデータとしてＭＦＰ１に送信させるためのソフトウエアを開発し、当該ソフトウエアを用いて上記ＸＭＬデータをＭＦＰ１に送信させるようにすることで、所望のデバイスに所望の動作をさせることができるものである。

外部ＡＰＩ４２は、ＩＯ／ＩＪＣ ＡＰＩ２４で定義されている関数群の中の、所定の複数のものを一つにまとめた形態、例えばデバイスのある動作が、ＩＯ／ＩＪＣ ＡＰＩ２４で関数Ａ、Ｂ、Ｃにより定義されている場合、関数Ａ、Ｂ、Ｃをまとめた関数Ｄ（すなわち、関数Ｄは、関数Ａ、Ｂ、Ｃを実行させるための関数ということになる。）で構成されている。

このようにまとまったある動作を一の関数で表すことにより、外部ユーザは、例えばデバイスに当該ある動作を実行させたい場合、ＰＣ５０から関数Ｄを呼び出すようにすれば、実質的に関数Ａ、Ｂ、Ｃを呼び出したことになり、複数のコマンドを用いる必要がなくなって扱い易く、上記ソフトウエアも開発し易くなる。なお、一の動作を一の関数で表したものについては、その関数が用いられる。

ＸＭＬ変換部４３は、後述のように、ＰＣ５０から送られて来るＸＭＬデータから処理要求を示す情報としてのコマンド等を抽出する。
ＡＰＩ変換部４１は、ＸＭＬ変換部４３で抽出されたコマンド等（ＰＣ５０からの画像処理に関する処理要求）を、制御層２０で実行できる所定のデータ形式に変換して、制御層２０または当該アプリに渡す。なお、ＰＣ５０と外部ＡＰＩ部４０間でのＸＭＬデータの通信プロトコルとして、ここでは周知のＳＯＡＰ（Simple Object Access Protocol）が用いられる。

アプリケーション層３０には、ＩＯ／ＩＪＣ ＡＰＩ２４にアクセスして（予め定義された関数の内の任意のものを必要に応じて呼び出して（コールして））、実際にデバイスを動作させるための複数のアプリケーションが含まれている。
例えば、パネルアプリ３１は、操作パネル１３のディスプレイ表示を制御するためのアプリケーションである。具体的には、操作パネル１３からのキー入力情報を制御層２０を介して受け付けると、その入力情報に基づくメッセージ等を操作パネル１３のディスプレイに表示させる。例えば、コピースタートキーが押されたことを示す情報を受け付けると、「コピー中です」というメッセージを表示させる。

プリントアプリ３２は、プリントジョブ実行時に起動されると、ここでは外部機器からのＰＤＬ（Page Description Language）形式のプリントデータをビットマップ形式の画像データに変換し、その画像データに基づくプリント処理をプリンタ１１に実行させる。
スキャンアプリ３３は、スキャンジョブ実行時に起動されると、スキャナ１２に原稿画像を読み取らせ（スキャン動作を実行させて）、画像データを得る。

コピーアプリ３４は、コピージョブ実行時に起動されると、スキャナ１２に原稿画像を読み取らせ、得られた画像データに基づくプリント処理をプリンタ１１に実行させる。
ＦＡＸアプリ３５は、ＦＡＸジョブ実行時に起動されると、ＦＡＸ送信時には、例えばスキャナ１２に原稿画像を読み取らせ、得られた画像データをファクシミリ用のデータに変換して、指定された宛先に送信し、ＦＡＸ受信時には、例えば外部から受信した画像データに基づくプリント処理をプリンタ１１に実行させる。

また、各アプリは、外部ＡＰＩ部４０とアクセスして、外部ＡＰＩ部４０からの画像処理に関する処理要求を受け付けると、その処理要求に基づく画像処理をデバイスに実行させる機能を有している。
一方、ＰＣ５０は、図示していないが、ＰＣ本体、ディスプレイ、キーボード、ネットワークインターフェースおよびＳＤＫ（Software Development Kit）５１等を備えている。このＳＤＫ５１は、上記ソフトウエアを作成するためのものとして外部ユーザに利用されるものである。

なお、ホストＰＣ側とＭＦＰ側の境界位置に破線で示した「外部ＡＰＩ（ＸＭＬ）」は、ＰＣ５０により利用される外部ＡＰＩがＸＭＬで記述されたデータで扱われていることを示したものである。
上記のような外部ＡＰＩ部４０を備える構成により、ＭＦＰ１の各アプリでは行えなかった機能であっても、外部から実行させることが可能になる。

例えば、制御層２０に、外部と電子メールの送受信を実行できる機能が備えられているが、スキャンアプリ３３には、読み取った画像データを電子メールに添付して指定の宛先に送信するという、いわゆるScan to E-mail機能が備えられていない構成の場合に、外部ＡＰＩ４２してScan to E-mailによるスキャンジョブの実行に必要な内容を公開しておけば、外部ユーザは、当該スキャンジョブを実行させるために必要なコマンド等を含むＸＭＬデータをＭＦＰ１に送る処理を行うソフトウエアを外部で作成でき、外部から当該スキャンジョブを実行させることが可能になる。

以下、図２、３を用いて当該スキャンジョブを実行する場合の具体例を説明する。
図２は、公開されたＡＰＩに基づいて外部ユーザにより作成された、上記スキャンジョブを実行させるためのコマンド等を含むＸＭＬデータが、ＰＣ５０からＭＦＰ１の外部ＡＰＩ部４０を介してスキャンアプリ３３および制御層２０に渡されるまでに変換されて行く様子を例示した模式図である。

ここでは、画像読み取り条件として原稿枚数「１枚」、原稿サイズ「Ａ４」、原稿のセット方向「ポートレート（たて長）」、「カラー原稿」、読み取り解像度「６００（ｄｐｉ）」、「Ｊｐｅｇ高圧縮」、ファイル名「ｔｅｓｔｆｉｌｅ」、読み取った画像データの電子メールによる送信宛先として「ａｂｃ＠ｍｉｎｏｌｔａ．ｃｏ．ｊｐ」のジョブを実行させる場合の例を示している。なお、同図はＸＭＬデータの構成を解り易いように説明に必要な部分だけを簡素化して示した例であって、実際には一のジョブを実行させるために必要となるコマンド等の数、種類はこれよりも多くなり、また通信データとしてはヘッダ等の各種情報が付加されることになる。

同図のブロック１に示すように、ＰＣ５０からは、上記スキャンジョブの原稿サイズ等の各項目の内容が所定のタグで挟まれた状態で記述されたＸＭＬデータが出力される。ここでは、「message ID」タグに挟まれた「scan」がコマンドに相当し、「parameter」タグに挟まれた「destination」等が当該コマンドに対応するパラメータとなる。
このＸＭＬデータは、ＭＦＰ１のＩＯ２３を介して外部ＡＰＩ部４０のＸＭＬ変換部４３に送られ、ブロック２に示すデータに変換される。

具体的には、ＸＭＬ変換部４３において、入力されたＸＭＬデータからコマンド等に相当する部分と、それに対応するパラメータとが処理要求を示す情報として抽出される。この意味で、ブロック２に示すデータが、外部ＡＰＩ４２として公開された関数「scan」がＰＣ５０により呼び出された場合のデータ構成例となる。
ブロック２のデータは、ＡＰＩ変換部４１に送られ、制御層２０で直接実行できる形態（すなわちＩＯ／ＩＪＣ ＡＰＩ２４に対応するコマンド）に変換される（ブロック３）。

ブロック３のデータの「do_scan」「scan_destination」は、制御層２０で実際にスキャン動作を実行するための関数を示しており、その後の括弧内のパラメータは、その関数の引数になっている。ここで、変換されたコマンドは、制御層２０に対応するものなので、各アプリ３１〜３５でも実行できるものである。
外部ＡＰＩ部４０は、ブロック３のデータをどのアプリまたは制御層２０のモジュールに渡すのかをその内容に応じて決める（渡すべき先を選ぶ。）。具体的には、アプリで実行できるコマンドについては、直接（制御層２０を介さないで）アプリに渡す。

ここでは、当該データを、スキャン動作のための部分（ブロック４ａ）とE-mail送信のための部分（ブロック４ｂ）に分け、ブロック４ａのデータをスキャンアプリ３３に、ブロック４ｂのデータをScan to E-mail送信を受け持つ制御層２０に渡す。なお、どのコマンドをどのアプリに渡すかについては、予め決められている。
スキャンアプリ３３は、ブロック４ａのデータに基づく関数を呼び出してスキャン動作を実行させ、具体的には設定された読み取り条件（原稿Ａ４サイズ等）に基づいてスキャナ１１に原稿画像の読み取り動作を実行させる。

一方、制御層２０は、ブロック４ｂのデータに基づく関数を呼び出してScan to E-mail送信を実行させ、具体的には読み取られた画像データを、設定された送信宛先（ａｂｃ＠ｍｉｎｏｌｔａ．ｃｏ．ｊｐ）に送信させる。
図３は、上記スキャンジョブを実行する場合におけるＰＣ５０とＭＦＰ１間のデータフローを示す模式図である。ここで同図の矢印の内、細線は、ＩＯ／ＩＪＣ ＡＰＩ２４がコールされることにより実行される動作を示し、太線は、外部ＡＰＩ４２がコールされることにより実行される動作を示したものであり、二重線は画像データを示している。このことは、図４、５についても同様である。

外部ＡＰＩ部４０は、ＩＯ２３を介し、ＰＣ５０からスキャン開始のための外部ＡＰＩコールを受けると（Ｓ１）、ＰＣ５０とＸＭＬデータ（原稿サイズ等の読み取り条件、送信宛先等を示すデータ）を送受信し（Ｓ２）、スキャンアプリ３３へ接続確認を依頼する（Ｓ３）。スキャンアプリ３３とＩＯ２３との間で接続確認がなされ（Ｓ４）、接続確認結果が通知されると（Ｓ５）、外部ＡＰＩ部４０は、制御層２０からその通知を取得する（Ｓ６）。

外部ＡＰＩ部４０は、スキャン動作指示およびScan to E-mail送信の宛先を制御層２０に通知し（Ｓ７）、その指示に対する結果、例えばスキャン開始の承諾等を受け付けると（Ｓ８）、その旨をＰＣ５０に通知する（Ｓ９）。そして、ジョブ開始可能状態であることを受け付けると（Ｓ１０）、その旨をＰＣ５０に通知し（Ｓ１１）、スキャンアプリ３３に原稿サイズ等の読み取り条件を通知する（Ｓ１２）。

スキャンアプリ３３は、原稿サイズ等の読み取り条件に基づいてスキャン動作を開始させると共に、制御層２０に対し、読み取られた画像データ取得のための要求を行い（Ｓ１３）、制御層２０（ＩＪＣ２２）から画像データを取得すると（Ｓ１４）、所定の圧縮等の処理を施して、当該画像データを上記送信宛先にＩＯ２３を介してScan to E-mail送信させる（Ｓ１５）。

外部ＡＰＩ部４０は、ジョブの実行状態、例えば送信のためのファイル変換中、送信中等の情報を受け付け（Ｓ１６）、その後ジョブ終了を受け付けると（Ｓ１７）、その旨をＰＣ５０に通知し（Ｓ１８）、処理を終了する。
このように、公開されたＡＰＩに基づいてScan to E-mailによるスキャンジョブに必要なコマンド、パラメータをＰＣ５０から送信することで、スキャンアプリ３３では実行できない機能を外部から実行させることが可能になる。また、スキャンアプリ３３を起動させる構成にしているので、外部からアプリ起動のためのコマンドを送信すれば、スキャンアプリ３３がスキャナ１２を制御してスキャン動作を実行してくれる。したがって、外部ユーザにとってみれば、原稿画像の読み取り開始から、読み取られた画像データを設定された送信あて先に送信させるまでの一連の動作を所定のコマンド等を用いて指示する必要がなく、その意味でスキャンジョブを簡易に外部から実行させることが可能になる。

さらに、アプリで実行できるコマンド等（図２のブロック４ａ）については外部ＡＰＩ部４０から直接スキャンアプリ３３に渡される構成になっているので、例えば全てのデータを制御層２０を介してやりとりする構成の場合に比べて、その分制御層２０の処理の負担を減らすことが可能になる。
上記では、スキャンアプリ３３を起動させた場合の例を説明したが、スキャンアプリ３３を起動させないでスキャン動作を行うスキャンジョブに必要な内容を外部ＡＰＩ４２として公開しておけば、外部から当該スキャンジョブを実行させることも可能である。以下、図４を用いて当該スキャンジョブを実行させる場合の例を説明する。

図４は、スキャンアプリ３３を起動させないでスキャンジョブを実行させる場合のデータフローを示した模式図である。
外部ＡＰＩ部４０は、ＰＣ５０からスキャン開始のための外部ＡＰＩコールを受けると（スキャンアプリ３３を起動させないでスキャン動作を実行させるための所定のコマンドを受け付けると）（Ｓ２１）、ＰＣ５０とＸＭＬデータ（図２のブロック１に示す原稿サイズ、送信宛先等を含むデータ）を送受信する（Ｓ２２）。なお、ここでは送信宛先をＰＣ５０としている。

外部ＡＰＩ部４０は、制御層２０に対しスキャン動作指示を行い（Ｓ２３）、その指示に対する結果、例えばスキャン開始の承諾等を受け付けると（Ｓ２４）、その旨をＰＣ５０に通知する（Ｓ２５）。そして、制御層２０からジョブ開始可能な状態になっていることを受け付けると（Ｓ２６）、その旨をＰＣ５０に通知し（Ｓ２７）、制御層２０に原稿サイズ等の読み取り条件、送信宛先等を通知する（Ｓ２８）。

制御層２０は、原稿サイズ等の読み取り条件に基づいてスキャン動作を開始させ、ＩＪＣ２２を介して画像データを外部ＡＰＩ部４０に送る（Ｓ２９）。
外部ＡＰＩ部４０は、制御層２０（ＩＪＣ２２）から画像データを取得すると、当該画像データをＩＯ２３を介して送信宛先としてのＰＣ５０に送信させる（Ｓ３０）。
外部ＡＰＩ部４０は、送信が終わると、その旨をＰＣ５０に通知して（Ｓ３１）、処理を終了する。

このように、スキャンジョブに必要なコマンド、パラメータをＰＣ５０から送信することで、スキャンアプリ３３を起動させなくてもスキャンアプリ３３では実行できない機能を外部から実行させることが可能になる。
次に図５を用いて、プリントアプリ３２を起動させないで、外部からプリントジョブを実行させる場合の例を説明する。この場合も上記同様に、プリントアプリ３２を起動させないでプリントジョブを実行させる場合における当該プリントジョブの実行に必要な内容が予め外部ＡＰＩ４２として公開されることになる。

図５に示すように、外部ＡＰＩ部４０は、ＰＣ５０からプリント開始のための外部ＡＰＩコールを受けると（プリントアプリ３２を起動させずにプリント動作を実行させるための所定のコマンドを受け付けると）（Ｓ４１）、ＰＣ５０から画像データを取得する（Ｓ４２）。そして、ＰＣ５０とＸＭＬデータ（例えば、プリント条件として用紙サイズ、プリント枚数等を示すデータ）を送受信する（Ｓ４３）。

外部ＡＰＩ部４０は、制御層２０のＩＪＣ２２に、プリント指示、必要な設定情報として用紙サイズ等のプリント条件を通知し（Ｓ４４）、画像データを送信する（Ｓ４５）。
制御層２０は、プリンタ１１を制御して、受信したプリント条件、画像データに基づくプリントを開始させる。また、ジョブの実行状態、例えばプリント中、終了等の情報を外部ＡＰＩ部４０に送る（Ｓ４６）。

外部ＡＰＩ部４０は、制御層２０からプリント中を示す情報を受け付け、その後プリント終了を示す情報を受け付けると（Ｓ４７）、ジョブ終了である旨をＰＣ５０に通知して（Ｓ４８）、処理を終了する。
このように、ＰＣ５０から、プリンタ１１にプリントを実行させるためのコマンド等を送信すれば、プリントアプリ３２を起動させなくても、プリントアプリ３２では扱えないデータ、例えばビットマップ形式のデータを画像データとして直接ＰＣ５０からＭＦＰ１に送信させてプリントを実行させることが可能になり、ＰＣ５０側で扱えるデータがプリントアプリ３２により制限されず、その意味で機能拡張性が向上する。

なお、図２では、スキャンジョブの場合におけるデータ構成例を説明したが、他のプリントジョブ、コピージョブ等の場合も同様に、ジョブを実行させるためのコマンド、パラメータ等から構成されるＸＭＬ形式のデータが、画像処理に関する処理要求を含むデータとして、ＰＣ５０からＭＦＰ１に送られ、外部ＡＰＩ部４０において制御層２０に対応するコマンドに変換されて各アプリ、制御層２０に渡されることになる。

以上説明したように、本実施の形態のＭＦＰ１は、外部からの、画像処理に関する処理要求を含むＸＭＬデータを受け付けて、それを制御層２０（第１の制御プログラム）のＡＰＩに対応するコマンドに変換してアプリまたは制御層２０に渡す機能を有する外部ＡＰＩ部４０（第２の制御プログラム）を備えているので、ＭＦＰ１がユーザに納品された後であっても、現存のアプリに変更を加えることなく、これらアプリでは実行できなかった新たな機能、例えば上記のようにScan to E-mailによるスキャンジョブを実行させる機能、プリントアプリ３２では扱えないデータを画像データとして送信してプリントジョブを実行させる機能等を実行させることが可能になり、機能拡張性が向上し、ユーザにとって使い勝手が大変良くなる。

また、各アプリが制御層２０と外部ＡＰＩ部４０の両方にアクセス可能であり、外部からの画像処理の処理要求がアプリに対するものである場合には、当該処理要求を外部ＡＰＩ部４０から直接当該アプリに渡す構成（制御層２０を介さないでデータをやりとりする構成）にしている。したがって、制御層２０に渡し制御層２０から当該アプリに渡される構成に比べて、制御層２０の処理の負担を減らすことができ、処理をより高速化できる。また、外部とアプリ間のデータを仲介する機能を制御層２０に持たせる必要がないので、その分制御層２０の構成を簡素化できる。

さらに、外部ＡＰＩ部４０が制御層２０を介さずに各アプリと直接アクセス可能な構成になっていることから、外部ＡＰＩ部４０に、各アプリのジョブ管理等の管理機能を持たせれば、外部ＡＰＩ部４０が各アプリの状態を監視することも可能になり、制御層２０にジョブ管理等を実行させる構成に比べ、制御層２０の処理負担を減らすことが可能になる。

また、ＸＭＬを用いてコマンド等を記述できる構成にすることにより、外部のソフトウエア開発者にとって大変扱い易い。さらに、ＭＦＰ１の開発者側にとっては、ＸＭＬを用いることにより、外部から処理要求として受け付けるべきデータの論理構造を独自に定義でき、設計の自由度が広がるという効果がある。
なお、本発明は、ＭＦＰ等の画像処理装置に限られず、上記のような処理をコンピュータが実行するためのプログラムであるとしてもよい。また、本発明に係るプログラムは、例えば磁気テープ、フレキシブルディスク等の磁気ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＭＯ、ＰＤなどの光記録媒体、Ｓｍａｒｔ Ｍｅｄｉａ（登録商標）、ＣＯＭＰＡＣＴＦＬＡＳＨ（登録商標）などのフラッシュメモリ系記録媒体等、コンピュータ読み取り可能な各種記録媒体に記録することが可能であり、当該記録媒体の形態で生産、譲渡等がなされる場合もあるし、プログラムの形態で、インターネットを含む有線、無線の各種ネットワーク、放送、電気通信回線、衛星通信等を介して伝送、供給される場合もある。

（変形例）
以上、本発明を実施の形態に基づいて説明してきたが、本発明は、上述の実施の形態に限定されないのは勿論であり、以下のような変形例が考えられる。
（１）上記実施の形態では、画像処理に関する処理要求をＸＭＬを用いて表す構成としたが、これに限られることはなく、例えばＨＴＭＬ（Hypertext Markup Language）等を用いることもできる。この場合、ＰＣ５０からＭＦＰ１に送られる画像処理に関する処理要求を示すデータが、その言語で記述されたデータになるので、外部ＡＰＩ部４０は、そのデータを制御層２０が理解できるデータに変換可能なように構成されることになる。

（２）上記実施の形態では、ＭＦＰ１とＰＣ５０がネットワークを介して接続されるとしたが、上記処理要求等のデータを通信できるものであれば接続方法は限定されず、例えば直接接続される構成とすることもできる。
また、本発明をデジタル複写機に適用した例を説明したが、スキャナ、プリンタ、ファクシミリ装置等の画像処理ジョブを実行する画像処理装置一般に適用することができる。

本発明にかかる画像処理装置は、自身が備えるアプリでは実行できない画像処理の機能を外部からの指示により実行することが可能であり、複写機、スキャナ、プリンタ等に利用できる。

ＭＦＰ１のシステム構成を示す図である。 Scan to E-mailによるスキャンジョブを実行させるためのコマンド等を含むＸＭＬデータが、ＰＣ５０からＭＦＰ１の外部ＡＰＩ部４０を介してスキャンアプリ３３および制御層２０に渡されるまでに変換されて行く様子を例示した模式図である。 上記スキャンジョブの実行する場合におけるＰＣ５０とＭＦＰ１間のデータフローを示す模式図である。 スキャンアプリ３３を起動させないでスキャンジョブを実行させる場合のデータフローを示した模式図である。 ＭＦＰ１が、ＰＣ５０から送られてくる画像データに基づいてプリントを行うプリントジョブを実行する場合におけるデータフローを示した模式図である。

符号の説明

１ ＭＦＰ
１１ プリンタ
１２ スキャナ
１３ 操作パネル
２０ 制御層
２１ カーネル
２２ ＩＪＣ
２３ ＩＯ
２４ ＩＯ／ＩＪＣ ＡＰＩ
３０ アプリケーション層
３２ プリントアプリ
３３ スキャンアプリ
４０ 外部ＡＰＩ部
４１ ＡＰＩ変換部
４２ 外部ＡＰＩ
４３ ＸＭＬ変換部
５０ ＰＣ

Claims (3)

1. 画像形成部、読み取り部、表示部の少なくとも一つを有するハードウェア資源と、
   前記ハードウェア資源の上位に位置するアプリケーションと、
   前記ハードウェア資源と前記アプリケーションの間に位置する第１の制御プログラムと、
   前記アプリケーションの上位に位置する第２の制御プログラムと、からなるアーキテクチャを有し、
   前記第１の制御プログラムは、
   予め定義された関数により前記アプリケーションおよび前記第２の制御プログラムからの画像処理に関する処理要求を受け付ける第１のＡＰＩ（アプリケーション・プログラム・インターフェース）を有し、受け付けた処理要求に基づく処理を前記ハードウェア資源に実行させ、
   前記第２の制御プログラムは、
   予め外部に公開された関数により前記外部から画像処理に関する処理要求を受け付ける第２のＡＰＩを有し、受け付けた処理要求を前記第１のＡＰＩに対応するコマンドに変換し、当該処理要求の内容に応じて前記アプリケーションまたは前記第１の制御プログラムのいずれかに渡すことを特徴とする画像処理装置。
2. 前記外部からの画像処理に関する処理要求は、ＸＭＬで表されたものであり、
   前記第２の制御プログラムは、
   前記外部からの画像処理に関する処理要求をＸＭＬ形式のデータで受け付けることを特徴とする請求項１に記載の画像処理装置。
3. 前記第２の制御プログラムは、
   受け付けたＸＭＬ形式のデータから前記処理要求を示す情報を抽出する第１の変換部と、
   抽出された情報を前記第１のＡＰＩに対応するコマンドに変換する第２の変換部と、
   を備えることを特徴とする請求項２に記載の画像処理装置。

Images