JP2005080018A - 画像処理装置 - Google Patents

Abstract

【課題】 機能を容易に拡張でき、その場合に現存のアプリケーションの変更をほとんど必要としない構成の画像処理装置を提供すること。
【解決手段】 デジタル複写機（ＭＦＰ）は、外部ＰＣ５０からの、画像処理に関する処理要求を含むＸＭＬデータを受け付けて、それを制御層２０のＡＰＩ（アプリケーション・プログラム・インターフェース）に対応するコマンドに変換して制御層２０に渡す機能を有する外部ＡＰＩ部３０を、制御層２０とアプリケーション層４０の間の位置に備える。
【選択図】 図１

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）５１等を備えている。このＳＤＫ５１は、上記ソフトウエアを作成するためのものとして外部ユーザに利用されるものである。
なお、ホストＰＣ側とＭＦＰ側の境界位置に破線で示した「外部ＡＰＩ（ＸＭＬ）」は、ＰＣ５０により利用される外部ＡＰＩがＸＭＬで記述されたデータで扱われていることを示したものである。

上記のような外部ＡＰＩ部３０を備える構成により、ＭＦＰ１の各アプリでは行えなかった機能であっても、外部から実行させることが可能になる。
例えば、スキャナ１２自体は、複数の読み取り解像度、例えば１２００、６００、４００ｄｐｉ（dot per inch）のいずれの解像度でも原稿画像を読み取る能力を有しているが、スキャンアプリ４３には、ユーザからの解像度選択入力を受け付ける機能が備えられていない（例えば、最低の４００ｄｐｉ固定になっている）構成の場合に、外部ＡＰＩ３２として読み取り解像度を指定したスキャンジョブの実行に必要な内容を公開しておけば、外部ユーザは、当該スキャンジョブを実行させるために必要なコマンド等を含むＸＭＬデータをＭＦＰ１に送る処理を行うソフトウエアを外部で作成でき、外部から当該スキャンジョブを実行させることが可能になる。

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

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

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

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

このブロック３のデータの「do_scan」「scan_destination」は、制御層２０で実際にスキャン動作を実行するための関数を示しており、その後の括弧内のパラメータは、その関数の引数になっている。
制御層２０では、上記関数が呼び出されるとそれらを実行する。具体的には、設定された読み取り条件（原稿Ａ４サイズ、読み取り解像度６００ｄｐｉ等）に基づいてスキャナ１１に原稿画像の読み取り動作を実行させ、読み取られた画像データを、設定された送信宛先としてのＰＣ５０（ａｂｃ＠ｍｉｎｏｌｔａ．ｃｏ．ｊｐ）に送信させる。

図３は、上記スキャンジョブを実行する場合におけるＰＣ５０とＭＦＰ１間のデータフローを示す模式図である。ここで同図の矢印の内、細線は、ＩＯ／ＩＪＣ ＡＰＩ２４がコールされることにより実行される動作を示し、太線は、外部ＡＰＩ３２がコールされることにより実行される動作を示したものであり、二重線は画像データを示している。このことは、図４、５についても同様である。

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

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

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

以下、図４を用いて当該スキャンジョブを実行させる場合の例を説明する。
図４は、スキャンアプリ４３を起動させてスキャンジョブを実行させる場合のデータフローを示した模式図である。
外部ＡＰＩ部３０は、ＩＯ２３を介し、ＰＣ５０からスキャン開始のための外部ＡＰＩコールを受けると（スキャンアプリ４３を起動させてスキャン動作を実行させるための所定のコマンドを受け付けると）（Ｓ２１）、ＰＣ５０とＸＭＬデータ（原稿サイズ等の読み取り条件、送信宛先を示すデータ）を送受信し（Ｓ２２）、スキャンアプリ４３へ接続確認を依頼する（Ｓ２３）。スキャンアプリ４３とＩＯ２３との間で接続確認がなされ（Ｓ２４）、接続確認結果が通知されると（Ｓ２５）、外部ＡＰＩ部３０は、制御層２０からその通知を取得する（Ｓ２６）。

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

スキャンアプリ４３は、原稿サイズ等の読み取り条件に基づいてスキャン動作を開始させると共に画像データ取得のための要求を行い（Ｓ３３）、制御層２０（ＩＪＣ２２）から画像データを取得すると（Ｓ３４）、当該画像データに所定の圧縮等の処理を施して、上記送信宛先にＩＯ２３を介して送信させる（Ｓ３５）。
外部ＡＰＩ部３０は、ジョブの実行状態、例えば送信のためのファイル変換中、送信中等の情報を受け付け（Ｓ３６）、その後ジョブ終了を受け付けると（Ｓ３７）、その旨をＰＣ５０に通知し（Ｓ３８）、処理を終了する。

このようにスキャンアプリ４３を起動させてスキャン動作を実行させる場合には、外部からアプリ起動のためのコマンドを送信すれば、スキャンアプリ４３がスキャナ１２を制御してスキャン動作を実行してくれるので、外部ユーザにとってみれば、原稿画像の読み取り開始から、読み取られた画像データを設定された送信あて先に送信させるまでの一連の動作をいちいち所定のコマンド等を用いて指示する必要がなく、その意味でスキャンジョブを簡易に外部から実行させることが可能になる。

次に図５を用いて、プリントアプリ４２を起動させないで、外部からプリントジョブを実行させる場合の例を説明する。この場合も上記同様に、プリントアプリ４２を起動させないでプリントジョブを実行させる場合における当該プリントジョブの実行に必要な内容が予め外部ＡＰＩ３２として公開されることになる。
図５に示すように、外部ＡＰＩ部３０は、ＰＣ５０からプリント開始のための外部ＡＰＩコールを受けると（プリントアプリ４２を起動させずにプリント動作を実行させるための所定のコマンドを受け付けると）（Ｓ４１）、ＰＣ５０から画像データを取得する（Ｓ４２）。そして、ＰＣ５０とＸＭＬデータ（例えば、プリント条件として用紙サイズ、プリント枚数等を示すデータ）を送受信する（Ｓ４３）。

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

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

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

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

また、制御層２０とアプリ等の間に外部ＡＰＩ３０が介在するアーキテクチュアになっているので、制御層２０、たとえばＩＪＣ２２等が設計変更される場合でも、外部ＡＰＩ部３０のＡＰＩ変換部３１の処理内容をそれに合わせて変更すれば（具体的には、変更後の制御層２０のＩＯ／ＩＪＣ ＡＰＩ２４を呼び出せる構成にすれば）、制御層２０の変更が外部ＡＰＩ部３０で吸収され、基本的に現存のアプリ等をそのまま使用できる（変更を加えなくても済む。）。これにより、ＭＦＰの開発者側にとっては、これらアプリのプログラム変更、確認作業等に手をとられる必要がなく、開発期間を大幅に短縮できると共に開発負担を軽減できる。この意味で、例えば制御層２０に今後設計変更が加えられることが予想される場合には、上記アーキテクチュアにしておけば、当該変更が実際に生じた場合に大変有効である。

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

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

（２）上記実施の形態では、制御層２０と外部ＡＰＩ部３０を別々のものとして扱ったが、例えば外部ＡＰＩ部３０を制御層２０の一部として扱う構成とすることもできる。
（３）上記実施の形態では、ＭＦＰ１とＰＣ５０がネットワークを介して接続されるとしたが、上記処理要求等のデータを通信できるものであれば接続方法は限定されず、例えば直接接続される構成とすることもできる。

また、本発明をデジタル複写機に適用した例を説明したが、スキャナ、プリンタ、ファクシミリ装置等の画像処理ジョブを実行する画像処理装置一般に適用することができる。

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

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

符号の説明

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

Claims (4)

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

Images