JP2006252406A - 拡張機能制御装置 - Google Patents

Abstract

【課題】 画像処理装置に容易に機能拡張およびカスタマイズさせることが可能で、かつ画像処理装置自身の処理能力や記憶容量を圧迫しない拡張機能制御装置を提供することである。
【解決手段】 第一の通信経路より送受信する前記第一の制御プロトコルを、第二の通信経路に送受信する第二の制御プロトコルに、および第二の制御プロトコルを第一の制御プロトコルに変換することの可能なプロトコル変換手段と、外部装置と通信し、画像処理装置を制御し機能拡張するための動作を記述する、拡張機能定義を受信して、所定の記憶領域に記憶する記憶手段と、拡張機能定義を読み出して解釈し、前記第一の制御コマンドプロトコルを生成して、前記プロトコル変換手段に送信して画像処理装置を制御する。
【選択図】 図１

Description

本発明は、画像処理装置に接続される拡張機能制御装置に関し、特に、画像処理装置と所定の通信プロトコルに従い通信し、画像データおよびプリント、スキャン等のジョブの送受信、および画像処理装置の操作部の操作を行なうことの可能である、機能拡張装置上で動作する通信ソフトウェアモジュールを用いて、画像処理装置の持つ複数の機能を組み合わせた機能の実装やカスタマイズを容易に行なうことのできる拡張機能制御装置に関する。

従来より、複写機などの画像処理装置に接続される、外部コントローラ装置が提供されている。この外部コントローラ装置は、例えば、ホストコンピュータのプリント・ドライバで生成されたＰＤＬプリントジョブをネットワーク経由で受信し、ＰＤＬ言語を解釈してプリントジョブをページ画像に展開し、ジョブコントロールコマンドと共に画像処理装置に送って、用紙媒体上に画像を形成するという目的で使用されている。

また近年、複写機はＭＦＰ化してきており、実行することのできるジョブも、リモートコピーやＢｏｘ画像の送信など、多種多様になってきている。これに伴い、外部装置との通信Ｉ／Ｆプロトコルも複雑化してきており、特定目的の外部装置を作成する場合、複雑なプロトコルの中から目的とする動作をさせるコマンドを選択するだけでも、プロトコルに精通している必要があって、困難となってきている。

そのため、特定目的に特化したより簡単なプロトコルを、上記のネイティブ・プロトコルに精通していない開発者、例えば外部コントローラ装置ベンダーに提供する必要が生じ、外部コントローラＯＳ上で動作するプロトコル変換モジュールが開発された。これにより、外部コントローラ装置ベンダーは、ＭＦＰの複雑なネイティブ・プロトコルを理解すること無しに、目的とする機能を提供する外部コントローラ装置を速やかに開発できるようになり、また複写機メーカーとしては、対自社製機器・ソフトの通信のみで使用する、特定目的以外の外部ベンダーに触らせたくないコマンドを使えないようにするなど機密保持することを可能とするとともに、このプロトコル変換機能を外部装置側で実行させることにより、複写機ＣＰＵに余分な負荷を与えず処理を最適化することが可能となった。

また、あまり市場規模の見込めない、ニッチなユーザのニーズに個別に対応したいという要求もあって、これに対応するため、画像処理装置の既存の機能を組み合わせ、操作部をカスタマイズして、個々のユーザに会った機能を追加するという技術がいくつか存在する。

例えば、特許文献１においては、外部の拡張装置から、拡張メニューファイルを印刷装置にダウンロードするという機能を提案している。また、特許文献２においては、ＩＤに応じたアプリケーションソフトをＭＦＰにダウンロードするという機能を提案している。
特開平０９−１６７０６１号公報 特開２００２−２９８５６１号公報

しかしながら、多様なニーズに対応するため、外部コントローラ装置の種類自体も増えてきており、これに伴いベンダーも増加しつつある。ベンダー毎に、開発する装置のハードウェアやＯＳは異なるため、上記のプロトコル変換モジュールを開発する上では、各種プラットフォームに対応する必要があり、開発負荷を上げる一因となってきた。

さらに、ニッチなユーザのニーズへの個別対応に関しては、上記の特許文献１や特許文献２に見られるとおり、画像処理装置自体がメニューファイルを解釈したりアプリケーションソフトを格納し実行するなどする必要があり、一部のユーザのためだけに、画像処理装置の記憶容量や処理能力が圧迫され、またこのための専用の仕組みを内蔵する必要があって、画像処理装置単体の開発・製造コストアップに繋がっている恐れがあった。

本発明は、以上の点に着目して成されたもので、開発負荷を下げることが可能で、必要なユーザにのみに最低限のコストで提供することが可能な拡張機能制御装置を提供することを目的とする。

本発明は、上記の問題点を解消するための、
第一の通信経路により受信した第一の制御プロトコルに従って、第二の通信経路に接続する画像処理装置の制御を行なう画像処理装置の拡張機能制御装置であって、
前記第一の通信経路より送受信する前記第一の制御プロトコルを、前記第二の通信経路に送受信する第二の制御プロトコルに、および前記第二の制御プロトコルを前記第一の制御プロトコルに変換することの可能な、プロトコル変換手段と、
外部装置と通信し、前記画像処理装置を制御し機能拡張するための動作を記述する、拡張機能定義を受信して、所定の記憶領域に記憶する拡張機能定義記憶手段と、
前記拡張機能定義記憶手段より拡張機能定義を読み取って解釈し、前記第一の制御コマンドプロトコルを生成して、前記プロトコル変換手段と送受信する制御を行なう拡張機能定義実行手段と
を有することを特徴とする。

また、これに加えて、前記第一の通信経路には外部装置が接続され、外部装置から送受信される前記第一の制御プロトコルを前記第二の制御プロトコルに変換し、前記画像処理装置に対する制御を行なうことを特徴とする。

また、これに加えて、前記第一の制御プロトコルとは、前記画像処理装置への画像印刷動作を指示するプロトコルであることを特徴とする。

また、これに加えて、前記第一の制御プロトコルとは、前記画像処理装置への原稿読取動作を指示するプロトコルであることを特徴とする。

また、これに加えて、前記第一の制御プロトコルとは、前記画像処理装置の操作部への表示および入力の受信を行なうための制御プロトコルであることを特徴とする。

また、これに加えて、前記拡張機能定義には、前記拡張機能制御装置上で実行することのできる外部プログラムの実行の指示を含めることが可能なことを特徴とする。

また、これに加えて、前記拡張機能定義は、前記拡張機能制御装置内部の記憶領域に存在する外部データを参照できることを特徴とする。

また、これに加えて、前記第一の通信経路および前記第二の通信経路を、異なったハードウェアＩ／Ｆ装置に接続することを特徴とする。

あるいは、前記第一の通信経路および前記第二の通信経路を、同一のハードウェアＩ／Ｆ装置に接続することを特徴とする。

本発明によれば、多様なユーザ・ニーズに対応するための、外部コントローラ装置ベンダーの増加に対応し、プラットフォーム依存性を少なくしたプロトコル変換装置を提供して、開発負荷を下げることが可能となる。

さらに、ニッチなユーザのニーズへの個別対応に関しては、画像処理装置の記憶容量や処理能力を圧迫することなく、必要なユーザにのみに最低限のコストで、機能拡張装置を提供することが可能となる。

以下に図面を参照して本発明の好適な実施例を示す。

図１は、本発明の第１の実施例を示す画像処理システムのハードウェア構成を説明する概略ブロック図である。

この画像処理システムは、ネットワーク（１０１）を介して１台以上のホストコンピュータ（１０２）と、機能拡張装置としてＰＤＬプリントジョブなどのジョブを解釈し画像展開するなどの画像処理を行なう外部コントローラ装置（１０３）と、外部コントローラ装置が接続する画像処理装置（１０４）、および外部コントローラ装置（１０３）と画像処理装置（１０４）を接続し、外部コントローラ装置（１０３）との通信プロトコル（Ａ）を画像処理装置（１０４）が直接解釈することのできるネイティブ通信プロトコル（Ｂ）に変換することのできるプロトコル変換装置（１０５）から構成されている。

外部コントローラ装置（１０３）は、ＨＤＤ（１１４）またはＲＯＭメモリ（１１５）等に格納されたプログラムを、ＣＰＵ（１１３）が実行することにより動作しており、プログラムに応じて、受け取ったＰＤＬジョブをビットマップ画像データに画像展開（ＲＩＰ）したり、画像処理装置にジョブを表すコマンドスクリプトや画像データを送受信したり、あるいは内部バスに接続されている各機器部の制御を行なうことができる。内部バスにはネットワークＩ／Ｆ１（１１２）およびネットワークＩ／Ｆ２（１１７）も接続されている。外部コントローラ装置（１０３）は、ネットワークＩ／Ｆ１（１１２）を介して外部ネットワーク（１０１）に接続され、ネットワークＩ／Ｆ２（１１７）を介して画像処理装置と接続されている。また、ユーザ・インタフェースあるいは他のインタフェース、その他の装置（１１６）を備えていることもできる。

本実施例における画像処理装置（１０４）は、ＭＦＰタイプの複写機であって、外部と通信を行なうための不図示のネットワークＩ／Ｆ部を備え、さらに用紙媒体上に画像形成を行なう画像形成部、原稿画像を読み取り画像データとする画像読取部、ＬＣＤタッチパネルおよびハードキーにより構成されるＵＩ部等を備えている。そしてネットワークＩ／Ｆ部を介して、外部からのジョブコマンドスクリプトを受信したり、画像データを送受信して、用紙媒体上に画像形成するプリントジョブや、原稿画像を読み取るスキャンジョブ、あるいは、ＵＩのＬＣＤ画面への表示指令を実行することが可能である。これらの指令を表すコマンド群は、画像処理装置（１０４）が直接解釈することのできるプロトコルとなっており、これを本実施例ではネイティブ・プロトコルあるいはプロトコル（Ｂ）と呼ぶ。

プロトコル変換装置（１０５）は、外部コントローラ装置（１０３）と同様に、ＣＰＵ（１２３）、ＨＤＤ装置（１２４）、プログラムデータなどを格納するＲＯＭとプログラムの作業領域等に使用するＲＡＭ（１２５）、ネットワークＩ／Ｆ１（１２２）およびネットワークＩ／Ｆ２（１２７）を備えている。ただし、メインとなる処理は後述するプロトコル変換処理であるので、それほど負荷は大きくなく、通常は外部コントローラ装置（１０３）よりも低コストのハードウェアを用いて構成しても問題はない。

ネットワークＩ／Ｆ１（１２２）には、外部コントローラ装置（１０３）のネットワークＩ／Ｆ２（１１７）が接続されており、外部コントローラ装置（１０３）からのプリントジョブ、スキャンジョブやＵＩ表示などのコマンドを受信する。これらの指令のコマンドは、上記プロトコル（Ｂ）と比べ、外部コントローラ装置（１０３）で必要と思われるもの、および他社ベンダーに公開しても良い範囲に絞った、より簡単なプロトコル（Ａ）で表される。プロトコル（Ａ）は、そのままでは画像処理装置（１０４）には解釈できないため、プロトコル変換装置にてプロトコル（Ａ）からプロトコル（Ｂ）への変換処理を行なう。これについては、後述する。

なお、本実施例の場合、外部コントローラ装置（１０３）の外部接続用Ｉ／Ｆと画像処理装置（１０４）の外部装置接続用Ｉ／Ｆ、およびプロトコル変換装置（１０５）の両Ｉ／Ｆを、すべてネットワークＩ／Ｆ（イーサネット（登録商標））で構成しているが、外部ネットワークあるいは画像処理装置（１０４）のＩ／Ｆ構成に合わせて、一部あるいは全部を他のＩ／Ｆハードウェアにしてももちろん良い。例えば、画像処理装置（１０４）の外部装置接続用Ｉ／Ｆが専用ハードウェアＩ／Ｆとなっていた場合、プロトコル変換装置（１０５）のネットワークＩ／Ｆ２（１２７）を専用ハードウェアＩ／Ｆと置き換えたり、さらに外部コントローラ（１０５）間とのＩ／Ｆである１２２と１１７を、ＵＳＢ２．０やＩＥＥＥ１３９４などの他の汎用的なＩ／Ｆハードウェアに置き換えて構成することももちろん可能である。また、高解像度カラー多値画像などの大容量データを転送する必要がある場合には、複数の専用ハードウェアＩ／Ｆと汎用Ｉ／Ｆを組み合わせて実装することももちろん可能である。

また、プロトコル変換装置（１０５）を、画像処理装置（１０４）に内蔵する構成とすることももちろん可能である。プロトコル変換装置（１０５）はオプション装置であるので、メカ的には内蔵した場合、ネットワークＩ／Ｆ２（１２７）に相当する内部Ｉ／Ｆを実装すればよい。

次に、外部コントローラ装置（１０３）で処理するジョブの一例として、ＰＤＬプリントジョブを記述するＰＤＬデータについて説明する。

アドビ（ＡＤＯＢＥ）社のＰｏｓｔＳｃｒｉｐｔ（登録商標）言語に代表されるＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）は、１ページの画像を、（ｉ）文字コードによる画像記述、（ｉｉ）図形コードによる図形記述、（ｉｉｉ）ラスタ画像データによる画像記述などの要素を組み合わせて記述するための言語であり、それで記述されたデータがＰＤＬデータである。

該ＰＤＬデータは、このように文字コードや図形コード、言い換えると図形描画コマンドを中心として構成されているので、ラスタ画像データのみの場合に比べて、一般にプリントジョブのデータ量が少なくて済む。このため、多数の機器が接続されるネットワークを介してジョブを送る場合、トラフィックを減らして高速にジョブを転送することが可能である。

このようなＰＤＬデータよりなるＰＤＬプリントジョブを、１ページずつラスタ画像データの形式に展開することをＲＩＰ処理という。すなわちＰＤＬプリントジョブを印刷するためには、ＲＩＰ処理を行なってラスタ画像データ（ビットマップ）に変換する必要がある。

画像処理装置（１０４）が特定ＰＤＬに対するＲＩＰ機能を持っていない場合は、本実施例のように、外部コントローラ装置（１０３） とプロトコル変換装置（１０５）を接続し、外部コントローラ装置（１０３）に特定ＰＤＬのＲＩＰ機能を持たせることによって、画像処理装置（１０４）を機能拡張して特定ＰＤＬプリントシステムとして提供できるようになる。

外部コントローラ装置（１０３）は、図１においてＨＤＤ（１１４）上に格納されたプログラムにより、ＣＰＵ（１１３）が動作することにより、ＲＩＰ機能を実現している。展開されたラスタ画像は、ＲＡＭ（１１５）上に圧縮された状態で一時保持され、プロトコル変換装置（１０５）を介してプリントジョブコマンドスクリプトと共に、画像処理装置（１０４）へと送られてプリント処理される。

以上はＰＤＬプリント処理機能を持たせた外部コントローラ装置（１０３）についての説明であるが、同様の仕組みで、これ以外にも例えば、画像処理装置（１０４）に原稿画像をスキャンさせ、読み取った画像に対してＯＣＲ等の何らかの処理を行なう機能や、あるいは画像処理装置（１０４）の不図示のＵＩ等を制御して所望のユーザに対するメッセージ等を表示する機能を実現する外部コントローラ装置（１０３）を提供することももちろん可能である。

次に図２を用いて、プロトコル変換装置（１０５）の内部で動作するソフトウェア構成について説明する。

図２におけるハードウェア２０１とは、図１で説明したネットワークＩ／Ｆ１および２（１２２，１２７）を含む、プロトコル変換装置（１０５）のハードウェア全般を模式的に示している。これの上に、ハードウェア制御のためのデバイスドライバを含むＯＳ（２０２）プログラムが動作する。尚、本実施例におけるプロトコル変換装置（１０５）は、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘなどの汎用ＯＳを用いている。

ＯＳ上で動作するプログラムモジュールとしては、本発明に特に関わる機能拡張エージェント（２０３）、アップローダ（２０６）、プロトコル変換を行なうプロトコル変換モジュール（２０４）、および転送モジュール（２０５）が動作する。この他、ドライバソフトを通じて装置全般の必要なハードウェア制御を行なう制御モジュールなども存在する。

プロトコル変換モジュール（２０４）は、プロトコル変換装置（１０５）のメインの機能となるプロトコル変換処理を提供するものであって、前述の通り、画像処理装置を制御する複雑なプロトコル（Ｂ）を、より簡単な特定機能に特化したプロトコル（Ａ）に変換するソフトウェアモジュールである。プロトコル（Ａ）による外部コントローラ装置（１０３）からジョブ送信指令等のコマンドを受けると、プロトコル変換モジュール（２０４）は、画像処理装置が直接解釈することのできるプロトコル（Ｂ）に変換し、送信する。

同様に、画像処理装置からプロトコル（Ｂ）で来た外部コントローラ装置（１０３）に対する返信等のコマンドを、プロトコル（Ａ）に変換して伝える。実際には両プロトコルのコマンドやパラメータは１対１とは限らず、複数のコマンドやパラメータを一つのコマンドにまとめたり、その逆を行なったり、あるいはプロトコル変換モジュール（２０４）としての内部状態を持ち、内部状態に応じた特定コマンドシーケンスやパラメータに変換したり、複数の種類の異なったプロトコル（Ｂ）を組み合わせて送受信するなど、複雑な変換アルゴリズムを実現している。

この、プロトコル変換処理の一例を図３に示す。図３において、３１、３２および３３のそれぞれの（１）はプロトコル（Ａ）でのコマンドのパケット構造を表し、（２）はコマンドに対するリプライのパケット構造を表している。プロトコル変換モジュール（２０４）が、それぞれのコマンドパケット（１）を受信したときに行なわれる処理が、（３）に示してあり、このうち斜体文字部分が情報処理装置（１０４）に対する指令すなわちプロトコル（Ｂ）を模式的に示すものである。もちろん実際のプロトコル（Ｂ）のパケット構造は規定に従いコードやパラメータを集めたデータとなっている。

３１は、ＰｒｉｎｔＪｏｂＳｔａｒｔコマンドであって、プリントジョブを送信する際に外部コントローラ（１０３）が最初に送信するコマンドである。

図に示す通りコマンドコード０ｘ１００２と、通常のプリントであるかあるいはＢｏｘ投入ジョブであるのか等のジョブの種類を示すＪｏｂ ｍｏｄｅ、Ｂｏｘ投入ジョブである場合に宛先Ｂｏｘを示すＢｏｘ ｎｕｍｂｅｒ、ジョブの名称を示す文字列Ｊｏｂ ｎａｍｅ、ユーザ名を示すＵｓｅｒ ｎａｍｅ、ジョブに対するパスワードを設定するＰａｓｓｗｏｒｄ、部数Ｃｏｐｉｅｓ、複数部のジョブを１部ずつ順に出力するかあるいはページごとにまとめて出力するかや、まとまりの区切りでシフトするかあるいは用紙を９０度回転させて出力するかなどを示すＳｏｒｔ ｍｏｄｅ、ステイプルするか否かおよびその位置を示すＳｔａｐｌｉｎｇ、ページ画像データのフォーマットを示すＤａｔａ ｆｏｒｍａｔ、画像形成する用紙媒体のサイズやタイプあるいは給紙段を示すＰｒｉｎｔ ｍｅｄｉｕｍ、片面か両面かおよび両面時の閉じ位置を示すＰｌｅｘ、省トナーモードで印刷するかどうかを示すＰｒｉｎｔ ｔｏｎｅｒ ｓａｖｉｎｇ、ライン等のエッジを滑らかにする画像処理を行なうかどうかを示すＥｄｇｅ ｓｍｏｏｔｈｉｎｇ、段階的に色味の変化するグラデーション部において色の変化を滑らかにする画像処理を行なうＧｒａｄａｔｉｏｎ ｓｍｏｏｔｈｉｎｇ、カラー印刷するか白黒印刷するかを示すＣｏｌｏｒ ｍｏｄｅ、といったパラメータにより構成されている。

３１−（１）のＰｒｉｎｔＪｏｂＳｔａｒｔコマンドを受信すると、プロトコル変換モジュール（２０４）は３１−（３）に示す動作を行なう。すなわち、まず、画像処理装置（１０４）の予め定められたポート（Ｗｅｌｌ ｋｎｏｗｎ ｐｏｒｔ）に接続し、Ｐｒｉｎｔ ｊｏｂ ｓｅｒｖｉｃｅを使用することを通知するＲｅｓｅｒｖｅコマンドを発行する。すると画像処理装置（１０４）からのリプライとして、現在Ｐｒｉｎｔ ｊｏｂを送ることのできるプリント用ポート番号を通知してくる。

これを受けてプロトコル変換モジュールは、次に、指定された番号のプリントポートに接続し、プリントジョブのＳｔａｒｔコマンドパケットを生成し、送る。その返信として、ジョブのＩＤが返される。

そして次に、このジョブＩＤに対して、各パラメータを一つずつセットするためのＳｅｔコマンドパケットを生成し、順に送ってリプライを受け取る。このＳｅｔパケット送信においては、特定条件のときのみ送るパラメータがあったり、外部コントローラ装置（１０３）から指定されていなくとも、必ずなんらかの値をセットしなければならないものなどがあるため、個別に条件判断を行なっている。

例えば、ジョブ名称が指定されていない場合は、”Ｕｎｋｎｏｗｎ”という文字列を指定したり、予め調べてある画像処理装置（１０４）の機種に応じて、対応していないデータフォーマットが指定された場合には、途中でキャンセルを行なったりしている。尚、本実施例では、カラー画像の圧縮データフォーマットとしてＪｐｅｇ、白黒２値画像の圧縮データフォーマットとしてＪＢＩＧをサポートしている。

また、例えばプロトコル（Ａ）において省トナーモードオンである場合、これはプロトコル（Ｂ）では濃度を調整することになっているので、濃度をプロトコル変換装置で定めた５０％とするなどの処理を行なう。

また、本実施例の画像処理装置（１０４）においては、プロトコル（Ｂ）は、ジョブをＤｏｃｕｍｅｎｔ単位に分割し、複数Ｄｏｃｕｍｅｎｔのジョブを扱うことができるようになっている。これによりジョブ中での一部パラメータの設定変更を容易にしているのであるが、この機能は外部コントローラ装置（１０３）に公開したくないものとしている。従って、プロトコル（Ａ）により受け取るジョブは、必ず１ｄｏｃｕｍｅｎｔとなるようにしている。

パラメータには、ジョブ全体に付随するパラメータと、Ｄｏｃｕｍｅｎｔ単位で付随するパラメータがあって、Ｄｏｃｕｍｅｎｔ単位のパラメータをＳｅｔする場合には、ＤｏｃｕｍｅｎｔのＳｔａｒｔコマンドを送る必要がある。プロトコル（Ａ）で送られたパラメータのうち、ジョブ全体に対するパラメータ設定が終わったら、ＤｏｃｕｍｅｎｔをＳｔａｒｔし、然る後にＤｏｃｕｍｅｎｔ単位のパラメータをセットするという処理を行なう。

全てのプロトコル（Ｂ）のコマンド送信手順が正しく行なわれリプライが正常値で戻ってきた場合、プロトコル（Ａ）に対するリプライパケット３１−（２）を生成し、外部コントローラ装置（１０３）に返す。もし一連のプロトコル（Ｂ）の手順で異常が発生した場合には、対応するエラーコードをもってエラーのリプライパケットを返し、プロトコル（Ｂ）の処理は途中で中止する。

尚、ＪｏｂおよびＤｏｃｕｍｅｎｔには、それぞれ２バイトのＩＤが付けられＳｔａｒｔのリプライとして返されてくるが、これをプロトコル（Ａ）に変換する際には、上位２バイトをジョブＩＤとし、下位２バイトをＤｏｃｕｍｅｎｔＩＤとして、全体をプロトコル（Ａ）におけるＪｏｂ ｈａｎｄｌｅとして３１−（２）で返信するようになっている。また、１つのコマンド送った後は、一旦ポートをクローズするようになっている。

次に３２のページ画像およびページ単位のパラメータを送信するためのＰｒｉｎｔＰａｇｅコマンドについて説明する。外部コントローラ装置（１０３）は、ＰｒｉｎｔＪｏｂＳｔａｒｔ後にそのジョブに含まれる各ページデータを順に、複数のＰｒｉｎｔＰａｇｅコマンドを用いて送ってくる。

ＰｒｉｎｔＰａｇｅコマンドのコードは０ｘ１００３となっている。パラメータには、どのジョブに対するページであるかを示すためのＪｏｂ ｈａｎｄｌｅ、ページ画像データ全体のサイズを示すＤａｔａ ｓｉｚｅ、データの主操作方向の画素数を示すＤａｔａ ｐｉｘｅｌｓ ｏｎ ｌｉｎｅと副走査方向のライン数を示すＤａｔａ ｌｉｎｅｓ ｏｎ ｐａｇｅ、用紙に対する画像の書き出し位置を示すＩｍａｇｅ ｌｅｆｔ ｏｆｆｓｅｔおよびＩｍａｇｅ ｔｏｐ ｏｆｆｓｅｔ、そして、ページ毎に切替可能なパラメータとして、用紙サイズおよびタイプを示すＰｒｉｎｔ ｍｅｄｉａ、カラーか白黒かどちらで印刷するかを示すＣｏｌｏｒ ｍｏｄｅがある。これらのパラメータは同様のものがＪｏｂに対してもあるが、Ｊｏｂの方のパラメータはＪｏｂ全体に対するデフォルト値となり、ページごとの指定が無い場合にはＪｏｂのパラメータが使用されるようになっている。

そして、ＰｒｉｎｔＰａｇｅのパラメータの一つとして、画像データであるＰａｇｅ ｄａｔａがある。先に説明したとおり、本実施例の画像処理装置（１０４）は、ＪｐｅｇまたはＪＢＩＧデータを受信可能であるので、ここに入るデータはいずれかのフォーマットのファイルをパケット化したものであり、Ｄａｔａ ｓｉｚｅはファイルサイズとなる。

プロトコル変換モジュール（１０５）は、３１での処理と同様に（３）に示す処理を行なう。すなわち、まずプリントポートに接続し、ＰａｇｅのＳｔａｒｔコマンドを送る。そしてページのＩＤを得る。つぎに各パラメータを必要に応じて条件判断し、Ｓｅｔコマンドを送る。

次にデータの転送となるが、画像処理装置（１０４）は画像データ受信用のポートはプリントポートとは別に開いているので、３１でプリントポート番号を得たのと同様に、データ転送先のポート番号を問い合わせる。

画像データは、縦横のＰｉｘｅｌ数および全体のファイルサイズを、ヘッダとして画像データファイルとまとめたものを送る必要があるため、そのパケットを（１）として受信したパケットから生成して、データ転送ポートに接続し、送信する。

送信完了となったらデータおよびプリントポートをクローズし、外部コントローラ装置（１０３）に対して３１と同様に結果とＰａｇｅ ｈａｎｄｌｅを返信する。

ジョブに含まれるすべてのページをＰｒｉｎｔＰａｇｅで送った後、外部コントローラ装置（１０３）は３３−（１）に示すＰｒｉｎｔＪｏｂＥｎｄコマンドを送信する。すなわちＰｒｉｎｔＪｏｂＳｔａｒｔ−＞複数のＰｒｉｎｔ ｐａｇｅ−＞ＰｒｉｎｔＪｏｂＥｎｄが、プロトコル（Ａ）における１つのプリントジョブを表すコマンドシーケンスである。

ＰｒｉｎｔＪｏｂＥｎｄに対するプロトコル変換モジュール（２０４）の変換処理も３１や３２に説明したのと同様で、まずプリントポートに接続し、Ｊｏｂ ｈａｎｄｌｅをＪｏｂ ＩＤとＤｏｃｕｍｅｎｔ ＩＤに変換した後、まずはＤｏｃｕｍｅｎｔに対するＥｎｄコマンドをＤｏｃｕｍｅｎｔＩＤと共に送り、その後にＪｏｂに対するＥｎｄコマンドをＪｏｂＩＤと共に送る。

またＰｒｉｎｔＪｏｂＥｎｄはジョブの途中キャンセルに用いることも可能で、この場合にはＥｎｄ ｍｏｄｅパラメータがキャンセルとして設定されている。このときには、プロトコル（Ｂ）としては、ＥｎｄコマンドではなくＣａｎｃｅｌコマンドをＪｏｂＩＤとして送る。

ちなみに、本実施例のプロトコル変換装置は、プロトコル（Ａ）のＩ／Ｆとして、用途に応じた複数のポートを開くことができる。上で説明したようなＰｒｉｎｔ系のジョブ指令コマンド等をやり取りするのはＰｒｉｎｔポートであり、他にＳｃａｎ系のジョブ指令コマンドのやりとりをするＳｊｏｂポートや、ＵＩ表示等のコマンドのやり取りを行なうためのＵＩポート、各種Ｓｔａｔｕｓの入手や通知等に用いられるＡｄｍｉｎポート等があって、これらは並行して処理することが可能である。またこれらプロトコル（Ａ）に対するポートが、画像処理装置（１０４）のプロトコル（Ｂ）に対するポートと必ずしも１対１に対応しているわけではなく、例えば上で説明したＰｒｉｎｔ時の場合ではＷｅｌｌ ｋｎｏｗｎ ｐｏｒｔ＋Ｐｒｉｎｔ ｐｏｒｔ＋Ｄａｔａ ｔｒａｎｓｆｅｒ ｐｏｒｔの３つのポートを使ったように、必要に応じてプロトコル（Ｂ）の複数のポートを組み合わせて使用する。

次に、図２の転送モジュール（２０２）について説明する。これは、ネイティブ・コマンドプロトコル（Ｂ）について、画像処理装置（１０４）がネットワーク上のホストコンピュータ等他の機器と、直接やりとりをするためのものであって、ＯＳを通じてネットワークＩ／Ｆ２（１２７）での通信とネットワークＩ／Ｆ１（１２２）での通信をアドレス変換して直接結びつけるスルー転送動作を行なう。

本実施例の構成においては、外部コントローラ装置（１０３）にもまったく同様の転送モジュールを搭載する必要があるため、プラットフォームに合わせた転送モジュールを外部ベンダーに提供している。

これによって、画像処理装置（１０４）は、外部コントローラ装置（１０３）を増設する前の対ネットワーク機能は損なうことなく、機能拡張が可能になる。例えば、ＳＮＭＰやＨＴＴＰなどの汎用プロトコルを使用するサービスを、画像処理装置が外部ネットワーク上の機器に対して公開する場合、スルーモジュールによって、この機能はそのまま外部機器から利用可能となる。さらに、外部機器からは、アドレス的に一つの装置として、外部装置を含んだ画像処理装置システムとして認識することができ、ＩＰアドレスを１つのみ割り当てれば良いようにできる。

次に図２におけるアップローダ・モジュール（２０６）について説明する。

本実施例のプロトコル変換装置（１０５）は、内蔵するＨＤＤ（１２４）に、機能拡張定義ファイル（２０７）、外部コマンド（２０８）および拡張データ（２０９）を保存することが可能である。アップローダ（２０７）は、ネットワークＩ／Ｆ１（１２２）（および外部コントローラ装置（１０３）に搭載した転送モジュール）を介して、外部ネットワーク（１０１）に接続されるホストコンピュータ端末と、所定のプロトコルをもって接続することが可能である。そして、ホストコンピュータより、これら２０７〜２０９のデータを受け取り、ＨＤＤ（１２４）に格納するという動作を行なう。尚、この所定のプロトコルとしては、ＦＴＰなどの汎用のファイル転送プロトコルを用いることも可能であり、アップローダとして汎用プロトコルに対するサーバプログラムを用いて構成することももちろん可能である。

本実施例の画像処理システムを提供する上で、ユーザに機能カスタマイズを許すならば、外部のホストコンピュータ端末上でアップローダへの接続ツールを提供し、使い方を公開すると共に、後述する拡張機能定義マクロの仕様や外部コマンドに対する要求仕様等を公開する。特定ベンダーのみに拡張機能マクロを作らせる場合には、そのベンダーのみに同様の公開をし、サービスマンが接続ツールを用いて、ユーザの要求に合ったマクロをダウンロードするという運用形態をとる。

ここで、機能拡張定義（２０７）とは、画像処理装置１０４を簡単に機能拡張させるための動作を記述したマクロ定義のテキストファイルであって、一例として図４に示すようなものとなる。

図４は、マーカー処理を定義したファイルである。マーカー処理とは、例えば図５において、Ａの白黒の原稿に対し、５０１に示すようにカラーのマーカーペンで一部領域を囲ったとすると、マスキングと呼ばれる処理においては、Ｂに示すように囲った部分を消したページ画像を生成し、トリミングと呼ばれる処理においては、Ｃに示すように囲った部分のみを表示するページ画像を生成するという処理であって、カラー読取装置をもつデジタル複写機においては古くから搭載されている機能である。しかし一部ユーザにしか使用されていない機能でもあるため、近年標準機能としない機種も増えてきている。

図４の拡張機能定義マクロを詳細に説明する。拡張機能定義マクロは、拡張データ定義部、変数定義部、メインメニュー定義部およびサブメニュー定義部より構成されており、各定義部は所定のラベルにより開始する。尚、ラベルは“：”文字で終わる行として定義される。

まず、Ｄａｔａ ｌｉｓｔ：のラベルで始まるエリアは画口調データ定義部であり、マクロ中で参照する拡張データ（２０９）を定義している。本実施系においては、拡張データ（２０９）はＨＤＤ（１２４）に格納されるファイルであるので、ファイル名“ｓａｍｐｌｅ１．ｊｐｇ”，“ｓａｍｐｌｅ２．ｊｂｇ”のファイルに対するＩｎｄｅｘとして、マクロ中でｄ１およびｄ２が使用できるように宣言する部分である。

次に、Ｖａｌ ｌｉｓｔ：のラベルで始まる領域は、変数定義部であり、マクロ中で使用する変数やバッファを宣言している。“：”の前の［］で括られた数字が、変数の大きさを表すバイト数であって、例えばｔｍｐｉｍｇやｏｕｔｉｍｇは画像データを格納するバッファとして用いるので、十分に大きな領域を確保する宣言となっている。

Ｍａｉｎ：ラベルで始まる領域は、メインメニュー定義部であり、画像処理装置（１０４）のＵＩにおいて、拡張機能画面に遷移するボタンを押した際に最初に表示される画面の内容を表している。ＦｏｒｍａｔＩＤ＝５とは、表示する画面のフォーマットを予め定められたＩＤ：５のものを用いることを示している。フォーマットによって、表示できるボタンの数や配置、文字数等が異なっているため、必要に応じて適正なＩＤを選択する必要がある。Ｔｉｌｅの項目は、画面上部に表示するタイトル文字列を示す。

Ｂｕｔｔｏｎ１，Ｂｕｔｔｏｎ２はそれぞれのボタンに表示する内容と機能を定義しており、｛｝で括られた中でＳｔｒｉｎｇがボタンの文字、Ａｃｔｉｏｎがボタンが押されたときになすべき処理を表している。このＡｃｔｉｏｎの定義内における命令ｍｏｖｅｔｏ（）は、（）内のラベルへと処理を移すことを示している。尚、ラベルとしては表示するサブメニューごとに付けられるラベル（例えばＭｅｎｕ１）や、“Ｍａｉｎ”自体もこのラベルとして指定可能であり、また、Ａｃｔｉｏｎの定義内において複数行に処理が渡る場合には、その途中に所望のラベルを挿入してこれを指定するようにすることも可能である。

サブメニュー定義部については、所望の文字列を使用することができる。図４の例ではＭｅｎｕ１およびＭｅｎｕ２をサブメニュー定義の文字列として使用している。

サブメニューＭｅｎｕ１は、メインメニューにおいてＢｕｔｔｏｎ１すなわち“マーカー処理コピー”が押されたときに表示するメニューの定義である。Ｍａｉｎ定義と同様の記述となっており、ＦｏｒｍａｔＩＤとしては６を使用、Ｔｉｔｌｅとしては“マーカー処理コピー”を設定している。Ａｃｔｉｏｎとしては、複数行にまたがる定義となっており、各行につき一つの命令を記載している。ここで、ｃｏｍ（）は、画像処理装置（１０４）の指定ポートに対し、図３で説明したような、プロトコル（Ａ）の指定コマンドを、続くパラメータと共に送り、そのリプライを受け取ることを指示する命令である。

尚、リプライパケットに付随するパラメータは、次のコマンドが送られるまで、バッファに保存されており、マクロ中で参照することが可能である。これらのパラメータを別のコマンドを送った後に使用する場合には、変数定義領域で宣言した変数へ代入しておくことが可能である。Ａｃｔｉｏｎ定義中で、“：＝”を挟んで左に変数、右にパラメータ名を指定している行が、代入文である。

次にｅｘｅｃｐ（）は、外部コマンド（２０８）を実行するための命令である。ここで、外部コマンドは、プロトコル変換装置上で動作するフィルタ型のプログラムを想定しており、コマンド名と引数の組み合わせで示される。例えば、トリミングに対する外部コマンドとしては、マーカー処理フィルタ“ｍａｒｋｅｒ”を使用し、第一引数にトリミングモードを示す１の値、第二引数に、ＳｃａｎＲｅｔｒｉｅｖｅコマンドで受け取った１ページの画像データを格納してあるバッファ領域ｔｍｐｉｍｇを指定する。フィルタプログラムであるので出力は、標準出力に排出されるが、これをリダイレクトしてｏｕｔｉｍｇのバッファ領域へ格納するように支持している。マスキングのときも全く同様で、マスキングモードを示す２を第一引数として指定させるところのみ異なる。

ｃｈｋ（）命令は、条件判定を行なう命令である。条件が真のときに、“：”に続く命令を実行する。

尚、図４においてＭｅｎｕ２に相当する“サンプル画像プリント”の定義については、記載は省略するが、ここではデータ定義部で宣言している拡張データファイルに対応する宣言ｄ１およびｄ２を選択し、プリント処理するものとなっている。

次に、機能拡張エージェント（２０３）は、機能拡張定義マクロ（２０７）を読み出し、マクロの定義に従って、プロトコル変換モジュール（２０４）に対し、必要なタイミングでプロトコル（Ａ）のコマンドのやり取りを行なう。すなわち、プロトコル変換モジュール（２０４）にとっては、外部コントローラ装置（１０３）と並列に存在するクライアント端末の一つに過ぎず、またプロトコル変換モジュール（２０４）は複数のクライアントからの接続を許可するようになっている。

この機能拡張エージェント（２０３）の処理を、図６および図７のフローチャートを用いて説明する。

機能拡張エージェント（２０３）は、起動されるとＳ６０１からの処理を開始する。尚、この処理は、アップローダ（２０６）により拡張機能定義（２０７）が更新された後等に、所定のトリガによっても再起動される。

Ｓ６０１が起動するとＳ６０２の処理として、まずＨＤＤ（１２４）から拡張機能定義ファイル（２０７）を読み込む。

そして、Ｓ６０３の処理として、まずデータ定義部を読み出し、拡張データファイルを使用できるように内部のデータ名に関連付ける。この処理は、画像データ等の大容量のものであることが多いため、サイズに応じてＯＳのメモリマッピング機能を使用して、ＨＤＤ上にありつつも内部でメモリのように取り扱えるようにして実現している。

次にＳ６０４として、変数定義領域を読み出し、スタック上に領域を確保する。これも大容量の場合には、ＨＤＤのスワップ領域を利用したり、あるいは上記と同様メモリマッピング機能を用いて実現する。

次に、Ｓ６０５の処理として、Ｍａｉｎメニュー定義部を読み出し、定義に従ってＩＤに対応するプロトコル（Ａ）のＵＩ表示コマンドのパケットを作成する。例えばＩＤ＝５に対応するＵＩ表示コマンドは、ＤｉｓｐｌａｙＭｅｎｕ５というコマンドであり、そのパラメータとして使用するボタンの数および各ボタンのストリングを指定できる。このＩＤ＝５の画面が表示されているときに、ハードキーまたはＬＣＤタッチパネルに表示されるボタンが、ユーザにより押下されると、画像処理装置（１０４）でイベントが発生し、イベント通知を登録してあるクライアントに通知される仕組みとなっている。また、Ｍａｉｎメニュー定義部には明記されていなくとも、Ｅｘｉｔキーを表示するためのパラメータを、自動的に付け加える。

同様に、Ｓ６０６の処理において、各サブメニューに対応するＵＩコマンドパケットを生成する。図４の例では、Ｍｅｎｕ１およびＭｅｎｕ２に対する２つのコマンドパケットが生成される。これらのパケットは、ラベルＭａｉｎおよびＭｅｎｕ１とＭｅｎｕ２でそれぞれ検索可能なように、メモリ上に格納される。

次に、Ｓ６０７の処理において、プロトコル変換モジュール２０４に対してプロトコル（Ａ）でのイベントポートに接続し、ＵＩキー押下イベントの通知登録を行なう。これを受けたプロトコル変換モジュール（２０４）は、画像処理装置１０４に対し、プロトコル（Ｂ）でのイベント受信クライアント登録を行なう。すなわち、プロトコル変換モジュール（２０４）は、画像処理装置（１０４）にとってはクライアントの一つとなり、以後、プロトコル（Ｂ）によるキー押下イベントを受けて、プロトコル（Ａ）に変換し、機能拡張エージェント（２０３）に伝えるようになる。

また、機能拡張エージェント（２０６）は、内部変数として、現在表示中あるいは表示しようとしているメニューの位置を示す実行ラベルと、Ａｃｔｉｏｎ定義の中で実行する命令の位置を示す実行ポインタという２種類の内部変数を持っている。Ｓ６０８においては、実行ラベルを初期状態であるＭａｉｎラベルに設定している。

次にＳ６１０において、キー入力のイベント受信を待つ。そしてＳ６１１において、受信したキーが拡張機能画面に遷移させるための遷移キーであるかどうかを判定し、遷移キーでない場合にはＳ６１０の処理に戻ってイベント待ちを続ける。

遷移キーイベントが受信されたら、Ｓ６１２の先に生成したＭａｉｎメニュー表示のためのＵＩコマンドパケットをプロトコル変換モジュール（２０４）に送信する。プロトコル変換モジュール（２０４）はこれをうけて、情報処理装置（１０４）のＬＣＤ画面上にＭａｉｎメニューを表示させる。

そしてＳ６１３において、次のキー入力のイベントを待つ。

キー入力を受信すると、Ｓ６１４において、現在の実行ラベルがＭａｉｎであり、かつ押されたキーがＥｘｉｔキーであるかどうかを判定する。

Ｅｘｉｔキーである場合には、表示している拡張機能画面のクローズコマンドをプロトコル変換モジュール経由で画像処理装置（１０４）に送り、画面をクローズさせるとともにＳ６１０の処理へと戻る。

Ｅｘｉｔキーでない場合、Ｓ６１６の処理を実行する。これは図７のフローチャートに示す処理であって、まずＳ７０２にて、入力されたキーの判定を行なう。

そして、Ｓ７０３において、実行ラベルに対応する定義を読み出し、対応するＢｕｔｔｏｎ１のＡｃｔｉｏｎ定義１行目に実行ポインタをセットする。例えば、図４の拡張機能定義でＭａｉｎメニュー表示時にＢｕｔｔｏｎ１が押下されたとすると、Ｂｕｔｔｏｎ１のＡｃｔｉｏｎ定義１行目のｃｏｍ（Ｓｊｏｂ，ＳｃａｎＪｏｂＳｔａｒｔ，…）に実行ポインタが移される。

そして、Ｓ７０４において実行ポインタ位置の行を読み出し、命令を判定する。

命令がｍｏｖｅｔｏであれば、Ｓ７０５の処理において、実行ラベルを指定されたラベルへと変更する。但し、指定されたラベルがＡｃｔｉｏｎ定義内のラベルである場合には、実行ポインタをラベルの次の行に変更する。そして、変更したのが実行ラベルかどうかをＳ７１４にてしらべ、実行ラベルならば処理終了となりＳ６１６の処理をぬける。実行ラベルでない場合には、Ｓ７１２の処理を行い、実行ポインタをＡｃｔｉｏｎ定義内ラベルの次の行に進め、Ｓ７１３にてこれが、そのＡｃｔｉｏｎ定義内で最終行か否かを調べて、最終行でない場合にはＳ７０４の処理へと戻る。

命令がｃｏｍであれば、Ｓ７０６にてプロトコル変換モジュール（２０４）の指定ポートにコマンドを送信し、プロトコル変換モジュールが画像処理装置（１０４）と通信し終わってリプライを返すまで待ち、Ｓ７０７にてリプライを受信する。そして、Ｓ７１２で実行ポインタを１行進める。尚、このとき実行ポインタがＡｃｔｉｏｎ定義内ラベルとなったら、さらにもう一つ実行ポインタを進める。そしてｍｏｖｅｔｏと同様、Ｓ７１３にて最終行か否かの判断を行い、最終行ならば処理終了、最終行でなければＳ７０４の次の行の命令判定に戻る。

命令がｃｈｋであるときは、Ｓ７０９の処理にて、指定された条件文が真であるかどうかを指定する。この条件文には、変数と定数の比較文が使用可能である。もし条件文が真である場合には、“：”の後ろに定義された実行命令部を実行すべく実行ポインタを移し、Ｓ７０４の処理へと戻る。死んでない場合には、Ｓ７１２の処理へと移り、“：”以降は実行せず次の行へと実行ポインタを進める。

Ｓ７０４での判定結果が代入文であった場合には、Ｓ７１１の処理において“：＝”の左辺に記述される変数に、右辺のパラメータ値を代入する。このパラメータ値とは、直前にｃｏｍ命令により送信されたコマンドのリプライパケットに付随するパラメータであって、前述したように次のｃｏｍ命令を実行するまではＳｔａｃｋに保存されているため参照可能となっている。

以上のＳ６１６の処理により、キーに対応するＡｃｔｉｏｎ定義がすべて実行されると、Ｓ６１７の処理として、実行ラベルに対応するメニュー表示のＵＩコマンドパケットを送信する。このとき、実行ラベルが前回と変更がない場合であっても、ボタン押下によって画像処理装置のＬＣＤ上で反転表示されたボタンを戻すため、コマンドパケットは送信する。

そしてＳ６１３の処理に戻り、次のキー入力イベントを待つ。

尚、Ｍａｉｎで前述したとおり、それぞれのサブメニューの定義に記載されなくとも表示されるＥｘｉｔボタンがあり、これらのＥｘｉｔキーが押下された場合には、Ｓ６１６の不図示の処理として、一つ前の実行ラベルに戻すという処理も行なっている。これによりツリー状のメニュー階層の前後を行き来することを可能としている。

以上説明した各モジュールは、プロトコル変換装置（１０５）の電源投入時に、自動的に起動され、並列に動作する。

このようなソフト構成を持つ画像処理装置の外部装置としてのプロトコル変換装置を提供することにより、簡単な機能については、マクロで定義し、複雑な重い拡張機能については専用の外部コントローラ装置を接続することによって、機能に見合ったコストをかけて画像処理システムの機能拡張を行なっていくことを可能としている。

本発明を、図８に示す接続形態として適用することも可能である。

図８において、８０１〜８２７の各部／各装置については、それぞれ図１の１０１〜１２７と全く同等であるので、詳細な説明は省略する。

図８においては、図１におけるネットワークＩ／Ｆ２（１１７）を取り外したハードウェア構成となっている。そして、プロトコル変換装置８０５は、図１の実施形態のように、ダイレクトに外部コントローラ装置８０３と接続するのではなく、一旦外部ネットワーク８０１と接続され、ネットワーク８０１を経由して外部コントローラ装置８０３と通信する。

すなわち、外部コントローラ装置８０３においては、同一のＩ／Ｆハードウェアを用いて、ホストコンピュータ８０２とも、プロトコル変換装置８０５を経由した画像処理装置８０４とも通信することになる。

また、このような形態とするメリットとしては、外部コントローラ装置８０３を、特定の画像処理装置（８０４）１台のための機能拡張装置とするのではなく、複数の画像処理装置に対して機能拡張を行なう、機能拡張サーバとして構築することが可能となる。さらに、ホストコンピュータ等の外部コントローラ装置以外の外部装置と画像処理装置との通信は、外部ネットワークとプロトコル変換装置（８０５）のみを介して行なわれるため、外部コントローラ装置のプラットフォーム合わせた転送モジュールを開発する必要が無くなり、よりプラットフォーム依存性を無くすことが可能となる。

図８におけるプロトコル変換装置のソフトウェア構成図は、図２と全く同様で良く、実行する機能も同等でよいので、詳細な説明は省略する。

もちろん実現する機能としては、実施例１と同等でも良いし、複数台の画像処理装置と通信可能であることを利用した新しい機能を実現することも可能である。

さらに、本発明を、図９に示す接続形態として適用することも可能である。

図９においては、図８と同じく、９０１〜９２５の各部／各装置については、それぞれ図１の１０１〜１２５と全く同等であるので、詳細な説明は省略する。

図９には、図８と比べ、プロトコル変換装置８０５＝９０５のネットワークＩ／Ｆ２（８２７）をさらに取り外したハードウェア構成となっている。そして、プロトコル変換装置９０５は、図８の実施形態のように、直接画像処理装置８０４と接続するのではなく、一旦外部ネットワーク９０１と接続され、ネットワーク９０１を経由して画像処理装置８０４と通信する。もちろん外部コントローラ装置９０３とも図８と同様にネットワーク９０１を介して通信する。

このような形態とするメリットとしては、まず、図２における転送モジュール２０５自体が必要なくなり、より簡単にプロトコル変換装置（９０５）を提供できるようになることがある。

また、図８での外部コントローラ装置８０５と同様に、プロトコル変換装置（９０５）を、特定の画像処理装置（９０４）１台のための機能拡張装置とするのではなく、複数の画像処理装置に対してのプロトコル変換機能を提供する装置とすることも可能となり、ハードウェア投資のためのコストをより押さえることも可能となる。

もちろん複数の画像処理装置を制御可能な特性を生かした機能を提供する、拡張機能マクロや外部コントローラを構築することも可能となる。例えば、カラーＭＦＰでスキャンしたカラー画像をなんらかの画像処理を行なって、白黒画像に変換し、白黒ＭＦＰが出力するといった機能も、拡張機能定義マクロで定義することが可能となるのは自明である。もちろんこの場合には、図４や図６，７で説明したよりもさらに命令や制御文を、提供したい機能に応じて追加していけばよい。

本発明の１実施形態である外部コントローラ装置およびプロトコル変換装置を含む画像処理システムのハードウェア構成を示すブロック図である。 図１に示したプロトコル変換装置上で動作するプログラムのソフトウェア構成を示すソフトウェア構成概念図である。 本発明の１実施形態におけるプロトコル（Ａ）と、プロトコル変換モジュールによって行なわれるプロトコル（Ｂ）への変換処理の一例を示す図である。 本発明の１実施形態におけるプロトコル変換装置のＨＤＤ装置内にアップロードされる拡張機能定義マクロの一例を示す図である。 本発明の１実施形態における拡張機能定義マクロの一例で実現するマーカー処理を説明する説明図である。 本発明の１実施形態における機能拡張エージェント・ソフトモジュールにおける処理を表すフローチャートである。 図６における処理Ｓ６１６の詳細を示すフローチャートである。 本発明の第二の実施形態のハードウェア構成例を示すブロック図である。 本発明の第三の実施形態のハードウェア構成例を示すブロック図である。

符号の説明

１０１ ネットワーク
１０２ 情報処理装置
１０３ 外部コントローラ装置
１０４ 画像処理装置
１０５ プロトコル変換装置
１１１ 内部バス
１１２ ネットワークＩ／Ｆ １
１１３ ＣＰＵ
１１４ ＨＤＤ
１１５ ＲＡＭ／ＲＯＭ
１１６ ＵＩ／他のＩ／Ｆ装置等
１１７ ネットワークＩ／Ｆ ２
１２１ 内部バス
１２２ ネットワークＩ／Ｆ １
１２３ ＣＰＵ
１２４ ＨＤＤ
１２５ ＲＡＭ／ＲＯＭ
１２７ ネットワークＩ／Ｆ ２

Claims (9)

1. 第一の通信経路により受信した第一の制御プロトコルに従って、第二の通信経路に接続する画像処理装置の制御を行なう拡張機能制御装置であって、
   前記第一の通信経路より送受信する前記第一の制御プロトコルを、前記第二の通信経路に送受信する第二の制御プロトコルに、および前記第二の制御プロトコルを前記第一の制御プロトコルに変換することの可能な、プロトコル変換手段と、
   外部装置と通信し、前記画像処理装置を制御し機能拡張するための動作を記述する、拡張機能定義を受信して、所定の記憶領域に記憶する拡張機能定義記憶手段と、
   前記拡張機能定義記憶手段より拡張機能定義を読み取って解釈し、前記第一の制御コマンドプロトコルを生成して、前記プロトコル変換手段と送受信する制御を行なう拡張機能定義実行手段と、
   を有することを特徴とする拡張機能制御装置。
2. 前記第一の通信経路には外部装置が接続され、外部装置から送受信される前記第一の制御プロトコルを前記第二の制御プロトコルに変換し、前記画像処理装置に対する制御を行なうことを特徴とする請求項１に記載の拡張機能制御装置。
3. 前記第一の制御プロトコルとは、前記画像処理装置への画像印刷動作を指示するプロトコルであることを特徴とする請求項１に記載の拡張機能制御装置。
4. 前記第一の制御プロトコルとは、前記画像処理装置への原稿読取動作を指示するプロトコルであることを特徴とする請求項１に記載の拡張機能制御装置。
5. 前記第一の制御プロトコルとは、前記画像処理装置の操作部への表示および入力の受信を行なうための制御プロトコルであることを特徴とする請求項１に記載の拡張機能制御装置。
6. 前記拡張機能定義には、前記拡張機能制御装置上で実行することのできる外部プログラムの実行の指示を含めることが可能なことを特徴とする請求項１に記載の拡張機能制御装置。
7. 前記拡張機能定義は、前記拡張機能制御装置内部の記憶領域に存在する外部データを参照できることを特徴とする請求項１に記載の拡張機能制御装置。
8. 前記第一の通信経路および前記第二の通信経路を、異なったハードウェアＩ／Ｆ装置に接続することを特徴とする請求項１に記載の拡張機能制御装置。
9. 前記第一の通信経路および前記第二の通信経路を、同一のハードウェアＩ／Ｆ装置に接続することを特徴とする請求項１に記載の拡張機能制御装置。