JP4738773B2 - 画像処理装置及びその制御方法 - Google Patents

Description

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

従来、例えば複写機やＭＦＰ（マルチファンクションプリンタ）などの画像処理装置で画像処理を実行するソフトウェアは、オペレーティングシステム（ＯＳ）の上に静的かつ固定的な、いわゆるファームウェアとして構築されることが主流であった。このようなファームウェアは、内部的に複数のモジュールから構成されている場合でも、全体が単一のロードモジュールに静的にリンクされた状態で装置の不揮発性メモリに記憶され、システムの起動時にハードディスクなどの不揮発性メモリからＲＡＭにロードされて実行されるか、又はそのファームウェアを記憶しているＲＯＭなどの不揮発性メモリ上で直接実行される。特に低価格の画像処理装置のように、組み込みシステムを構成するファームウェアは一般に、その経済性や安全性等のために、部分的なモジュールの動的なロードやリンクを行わないように構成されている。即ち、ダイナミックリンクを実現するために必要なシンボルテーブルを記憶するためのメモリ容量や、シンボルのアドレスへアクセスするための処理に関するオーバヘッドなどが、装置のコストパフォーマンスを悪化させる。また、サブモジュールの追加ロード及びリンクによって、そのサブモジュールをリンクする以前には十分に評価され達成されていたシステム全体の品質やセキュリティが脅かされる危険があるためである。

従来より、組み込みシステムのファームウェアのリアルタイムＯＳ上に更にもう一層のソフトウェア動作環境を設け、この設けたソフトウェア動作環境において、ダイナミックローディングやダイナミックリンキングや動的なメモリ操作などのソフトウェアの動的な特性をサポートする画像処理装置が開発されている。追加によるソフトウェア動作環境は、インタプリタと一揃いのアプリケーションプログラミングインターフェース（ＡＰＩ）群やフレームワーク群から構成され、その上で動作するソフトウェアのために一種のＯＳ或はコンピューティングプラットフォームを提供する。インタプリタは、所定の命令セットに含まれる命令からなる一連の命令列を逐次的に読み出し解釈し実行する。この命令セットをＣＰＵのための命令セットと同等の位置付けで捉える場合、インタプリタは特に仮想マシン（virtual machine）と呼ばれることもある。一揃いのＡＰＩ群及びフレームワーク群は、このソフトウェア動作環境の下層にある実際のリアルタイムＯＳが提供する資源やハードウェア資源を抽象化した各種の資源群に対するアクセスを、ソフトウェア動作環境上で動作するソフトウェアのために提供する。これら資源には、プロセッサによる命令実行コンテクストやメモリ、ファイルシステム、ネットワークインターフェースを含む各種入出力（Ｉ／Ｏ）などがある。特に命令実行コンテクストは、ＣＰＵとリアルタイムＯＳが提供するマルチタスク機構とは独立に、ソフトウェア動作環境が独自にインタプリタ上の命令実行コンテクストを管理できる。また、メモリの管理も同様にソフトウェア動作環境が独自のメモリ管理を提供できる。

このようなソフトウェア実行環境上で動作するソフトウェアは、インタプリタによって逐次的に読み込まれて解釈されて実行されるため、これらの処理の過程で命令列を監視しシステムに悪影響を与える動作を除外できる可能性がある。また、ソフトウェア実行環境上デ動作するソフトウェアからの各種資源に対するアクセスは、そのソフトウェア実行環境が提供するＡＰＩ群やフレームワーク群を経由して間接的に行われるため、このアクセスの過程で、システムに悪影響を与える動作を除外できる可能性がある。従って、ファームウェア内部にインタプリタ及びＡＰＩ群とフレームワーク群からなるソフトウェア実行環境の階層を設けるアプローチは、静的かつ固定的に構成されるべき低コスト組み込みシステムのファームウェアにおいて、ソフトウェアの動的な特性を部分的に導入するために非常に有効である（特許文献１、特許文献２）。

上記アプローチにおいて、ソフトウェア実行環境の階層を実現するためにインタプリタとしてＪａｖａ（登録商標）仮想マシンを採用し、Ｊａｖａ（登録商標）に関連するＡＰＩ群やフレームワーク群を採用することができ、本出願人は２００３年に、画像処理装置のファームウェア内部にＪａｖａ（登録商標）プラットフォームを内蔵した複合機を製品化している。

従来、ネットワークコンピュータを備えたアプリケーションダウンロード型プリンタを用い、コンピュータネットワークから、印刷すべきデータファイルと、そのデータファイルに対応したアプリケーションとをプリンタにダウンロードすることが行われている。そして、そのダウンロードしたアプリケーションを立ち上げて実行することにより、データファイルを開いてラスタイメージに変換し、それを印刷するネットワークコンピュータ内蔵型プリンタが知られている。またこの場合のアプリケーションとして、「Ｊａｖａ（登録商標）アプレット」を用いることも開示されている。このアプリケーションは印刷データファイルとともにクライアントからプッシュされる場合も、プリンタがアプリケーションサーバなどからプルすることも開示されている（特許文献３）。

また特許文献４には、複数の周辺機器及び周辺機器を動作させるソフトウェアを搭載した複数の端末装置、及び少なくとも周辺装置を動作させるソフトウェアに関するデータベースを備えたサーバ装置を伝送路に接続させ、所定の通信プロトコルに基づいてネットワーク通信を行うネットワーク通信システムにおいて、周辺機器は、サーバ装置から周辺機器を動作させるソフトウェアの全部／一部、或はソフトウェアが使用するモジュールに対応する最新モジュール情報を要求・獲得するクライアント制御部と、獲得した最新モジュールを端末装置に配付するソフトウェア配信エージェントと、を備えたネットワーク通信システムが開示されている。この場合の周辺機器を操作するソフトウェアが使用するクライアント側モジュールとして、「Ｊａｖａ（登録商標）アプレット」や「Ｊａｖａ（登録商標）アプリケーション」が供給可能であることも開示されている。

一方、基幹系の業務システムでは、一度、正常に稼働し始めたシステム全体の安定性を維持したいという要望はとても強く、プリンタドライバやアプリケーションの変更やバージョンアップなどの変更が簡単に許されない場合がある。このような現実のプリンティング環境の制約の中で、プリンタのベンダは顧客側に対応を求めるのではなく、プリンタ側の対応によって各種の顧客要望に応えるべき使命がある。このためには、プリンタ／プリンタコントローラを構成するファームウェアを改造して各顧客に対応してリリースする方法がある。しかし、ファームウェアの改造による各顧客への対応は、装置の開発期間や開発費などが多くかかり、またファームウェアの更新にはフィールドエンジニアなどによる高度なメンテナンスの手間を要するため、各顧客の要望に速やかに応えるには、費用対効果の面でも課題を残している。

組み込みシステムのファームウェアに、例えばＪａｖａ（登録商標）プラットフォームのようなソフトウェア動作環境を内蔵する複合機では、ソフトウェア動作環境上に、ファームウェアと独立した新たな装置組み込みアプリケーションを開発可能であり、ＡＰＩによってＪａｖａ（登録商標）アプリケーションから装置のプリント機能にアクセスできた。しかしながら、Ｊａｖａ（登録商標）プラットフォームがファームウェア内の組み込みアプリケーション階層に位置付けられているため、同じ階層で、ネイティブの組み込みアプリケーションとして実現されているプリントデータの受信機能やプリントサーバ機能をＪａｖａ（登録商標）アプリケーションのために流用できなかった。即ち、例えばネットワーク経由でプリントデータを受信するための各種プリントサービスプロトコルを実装したプリントサーバ機能をＪａｖａ（登録商標）側にも再実装する必要があり、開発負荷や評価負荷並びに実行時のメモリ容量の点でも非効率であった。

一方、その他の組み込みシステムのファームウェア内にソフトウェア動作環境の階層を持たない場合には、組み込みシステム全体がダイナミックリンクやプラグイン可能な構成で、システム全体が動的な構成になってしまっていた。動的な特性が求められる部分が、受信したＰＤＬデータストリームを解釈する前の前処理を柔軟かつ拡張可能に追加する機構だけであることを前提とした場合には、このような従来のアプローチは、システム全体を動的なソフトウェアとして構成するためのオーバヘッドに伴うコストアップや品質保証の難しさから低価格の小規模システムには向かなかった。

そこでプリンタが受信したＰＤＬデータストリームの解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離することによって、ＰＤＬプリンタのカスタマイズの生産性を向上する技術も提案されている（特許文献５参照）。
特開平１１−２８２６８４号公報 特開２００３−２５６２１６号公報 特開平１１−５３１３２号公報 特開平１１−３０６１０７号公報 特願２００４−０９３２１５号公報

特許文献５では、フィルタ処理を常に印刷要求データストリーム全体に対して行う必要があり、効率的な処理が実現できていない。即ち、画像処理装置が受信する印刷要求データストリームは、ＪＬ（Job Language）などの印刷装置の給排紙段の指定などのように、主に装置の制御に関する指示命令で構成される装置制御データストリーム部と、ＰＤＬなど描画に関する指示命令で構成される描画データストリーム部とで構成されている。そして、このフィルタ処理は常に、これら両方を含んだデータストリームに対して実行されてしまうため、処理全体が重くなり、スループットが落ちるなど、効率的な処理が行えない。また画像処理装置へのデータの一時保管処理のような、ＰＤＬ以外の様々な処理要求データストリームへの対応や、画像処理装置で読み取った画像データを電子メールで送信するといった、様々なデータストリームへの対応も考慮されていなかった。

本発明は上記問題点に鑑みてなされたもので、本発明の特徴は、入力したデータストリームに対して、動的ロードやリンク可能なフィルタを適用することにより、データストリームに対する各種処理を容易に実装できるようにした画像処理装置及びその制御方法を提供することにある。

本発明の一態様に係る画像処理装置は以下のような構成を備える。即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置であって、
前記ネイティブ環境で、前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信手段と、
前記ネイティブ環境で、前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成するデータ処理手段と、
前記インタプリタ環境で、前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記ネイティブ環境で、前記フィルタ手段との間で前記中間データストリームの前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース手段と、
前記ネイティブ環境で、前記インターフェース手段を介して取り出した前記中間データストリームの前記装置制御指示データストリームと描画データストリームとをそれぞれ、対応する前記インタプリタ環境のフィルタ手段へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、を有することを特徴とする。

本発明の一態様に係る画像処理装置の制御方法は以下のような工程を備える。即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置の制御方法であって、
前記ネイティブ環境で、前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信工程と、
前記ネイティブ環境で、前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成するデータ処理工程と、
前記インタプリタ環境で、前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記ネイティブ環境で、前記フィルタ工程との間で前記中間データストリームの前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース工程と、
前記ネイティブ環境で、前記インターフェース工程を介して取り出した前記中間データストリームの前記装置制御指示データストリームと描画データストリームとをそれぞれ、対応する前記インタプリタ環境のフィルタ工程へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース工程を介して書き戻すフィルタ管理工程と、を有することを特徴とする。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。

図１は、本実施の形態に係る画像処理装置１０００のハードウェア構成を説明するブロック図である。

この画像処理装置１０００は、画像処理装置コントローラ（以下、コントローラ）１６００を有し、異なる制御系を司る機器で構成されている。本実施の形態における画像処理装置１０００は、具体的には印刷装置を想定している。

ＣＰＵ１は、書き換え可能なフラッシュ（Flash）メモリ３に記憶された制御プログラムに基づいて制御動作を実行する。このＣＰＵ１はまた、所定のネットワーク通信プロトコルを用いて、システムバス４に接続されるネットワークコントローラ（ＬＡＮＣ）５を介してローカルエリアネットワーク（ＬＡＮ２０００）に接続されたホストコンピュータ等の複数の外部装置（不図示）から送られる印刷データやプリンタ制御命令等の各種データの送受信要求を統括的に制御する。またＲＯＭ９に記憶された制御プログラム等、或はディスクコントローラ（ＤＫＣ）１５を介して接続された外部メモリ１０に記憶された制御プログラムやリソースデータ（資源情報）等に基づいて、システムバス４に接続される各種デバイスとのアクセスを統括的に制御している。これにより、受信した印刷データを基にラスタコントローラ１２によって画像情報を生成して、その画像情報をマーキングエンジン（プリンタエンジン）１６に出力する。

ＲＡＭ２は、ＣＰＵ１の主メモリ、ワークエリア等の一時記憶領域として用いられる。フラッシュメモリ３は書き換え可能な不揮発メモリで、ＲＯＭ９とともに制御プログラムを記憶している。システムバス４は、このコントローラ１６００を構成する機器間のデータのやりとりに使用される。

ネットワークコントローラ（ＬＡＮＣ）５は、コントローラ１６００をＬＡＮ２０００に接続する。ＬＥＤ６は、このコントローラ１６００の動作状態を示す表示部として用いられており、例えばネットワークコントローラ（ＬＡＮＣ）５とローカルエリアネットワーク（ＬＡＮ）２０００との電気的な接続状態（ＬＩＮＫ）やネットワーク通信モード（10Baseや100Base、全二重、半二重）等の各種動作状態をＬＥＤ６の点滅パターンや色で示すことができる。外部メモリ１０は、制御プログラムや各種データを保持し、ＤＫＣ１５を介してコントローラ１６００に接続されている。一般的にはハードディスクドライブやＵＳＢメモリなどが使用されている。ラスタコントローラ１２は、受信した印刷データを基に、出力すべき画像情報を生成する。マーキングエンジン１６は、ラスタコントローラ１２から画像情報を受け取って印刷を行う。

操作パネル（操作部）１８は、画像処理装置１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンや、液晶パネルに重ね合わせて表示されたタッチパネル、及び画像処理装置１０００の動作状態を示す液晶パネルやＬＥＤ等の表示部を配している。画像読み取り部１９は、操作パネル１８、或はローカルエリアネットワーク２０００を介して画像情報の読み取りを指示することにより、その読み取った（スキャン）画像情報を画像処理装置１０００に入力する。

なお、この図１に示したマーキングエンジン１６は、既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザビーム方式）やインクジェット方式、昇華（熱転写）方式等が挙げられる。

図２は、本実施の形態に係るコントローラ１６００のソフトウェア構造を示す階層図である。図において、上方に位置している上位モジュールは、下方に位置している下位モジュールに依存していることを示す。また特に線によって接続したモジュール間には依存関係が存在することを示す。

ネイティブコード部２０１は、画像処理装置１０００のファームウェアを構成する標準部分で、ＣＰＵ１によって直接実行される。このネイティブコード部２０１は、ファームウェアとして、装置の開発時に単一のロードモジュールに静的にリンクされ、この画像処理装置１０００の不揮発性メモリ３に格納されている。このファームウェアは画像処理装置１０００の起動時に不揮発性メモリ３からＲＡＭ２にロードされ、画像処理装置１０００の稼働中はＣＰＵ１がＲＡＭ２からコードを逐次的に読み出して、そのコードを解釈して処理を実行するが、その処理の実行時にダイナミックリンクは行わない。尚、このファームウェアは、ＲＯＭ９のようにＣＰＵ１が直接読み出しアクセス可能な不揮発性メモリに格納され、ＲＡＭ２に展開せずに直接ＣＰＵ１がＲＯＭ９からコードを逐次的に読み出し、それを解釈して実行するようにしてもよい。

データ送受信モジュール２０２は、クライアントからの処理要求データストリーム３５０（図３）を受信し、コントローラ１６００で生成された送信用データストリーム３５８（図３）をクライアントに送信する。このデータ送受信モジュール２０２は、ＲＴＯＳ（リアルタイムＯＳ）２１４を介してプロトコルスタック２２３に依存している。クライアントとの間でのデータの送受信は、物理的にはイーサネット（Ethernet）（登録商標）などのネットワークやＵＳＢ，ＩＥＥＥ１３９４などの各種インターフェースを介して行われるが、それぞれの接続形態に応じて処理要求を行うためのアプリケーションプロトコルが規定されている。また、このデータ送受信モジュール２０２は、アプリケーションプロトコルのサーバ機能を実装している。サービスのためのアプリケーションプロトコルには、例えばネットワークプロトコルだけでもＬＰＲやＳＭＢ，ＰＡＰ，ＮｅｔＷａｒｅなど各種の仕様が存在し、その実現のためには膨大な開発コストと品質評価コストを要する。データ送受信モジュール２０２は、これら複数のインターフェース毎に、それぞれ各種存在するサービスプロトコルからなるマルチプロトコルをサポートしている。データ送受信モジュール２０２は、データの送受信のために、画像処理装置１０００のＲＡＭ２にジョブの待ち行列を構成し、いわゆるスプール機能を実装するように構成してもよい。この場合、データ送受信モジュール２０２は、他のジョブを実行している最中のようにジョブを直ちに実行できる場合にも、クライアントからのジョブ要求を受け付けて待ち行列に格納しクライアントを解放する。こうして待ち行列に格納されたジョブは、そのジョブが実行可能となった時にスケジューリングアルゴリズムに応じて逐次処理される。

組み込みアプリケーション２０３は、この画像処理装置１０００の中心機能を提供するための組み込みアプリケーションであり、クライアントからの要求に呼応してサービスを提供している。クライアントがＬＡＮ２０００を介したホスト上のアプリケーション及びドライバソフトの場合は、クライアントは処理要求データストリーム３５０（図３）を生成し、データ送受信モジュール２０２を介して組み込みアプリケーション２０３へ引き渡す。組み込みアプリケーション２０３は、この処理要求データストリーム３５０を装置制御指示データストリーム３５１（図３）と描画データストリーム３５２（図３）とに分割し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５にそれぞれを引き渡す。或は、装置制御指示データストリーム３５１を解釈し、制御ＡＰＩ２０４によってジョブ制御モジュール２０５に対して、クライアントから要求された処理を指示し、描画データストリーム３５２（図３）を引き渡す。

いまクライアントが画像処理装置１０００の操作パネル１８を介した指示であった場合は、組み込みアプリケーション２０３で、装置制御指示データストリーム３５１（図３）を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡す。また或は、ジョブ制御モジュール２０５に対して制御ＡＰＩ２０４によってクライアントから要求された指示を行う。この装置の制御に関する記述部は、一般的にはＪＬ（Job Language）と呼称され、描画データの解釈や展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、描画データストリームはＰＤＬで記述されており、主にページごとの描画が記述されている。

制御ＡＰＩ２０４は、この画像処理装置１０００が提供するサービスにアクセスするためのアプリケーションプログラミング・インターフェースである。この制御ＡＰＩ２０４を構成する主要なインターフェースの一つは、プリントジョブを実行したり制御するためのインターフェースと、装置制御指示データストリーム３５１（図３）と描画データストリーム３５２（図３）のジョブ制御モジュール２０５への引き渡しのためのインターフェースである。

ジョブ制御モジュール２０５は、画像処理装置１０００が提供する各種の画像処理ジョブを制御する。この画像処理ジョブの一例であるプリントジョブの処理を以下に示す。

ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した指示に従って装置の制御を行う。或は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５へ入力された装置制御指示データストリーム３５１（図３）を解釈することで動作を行う。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した装置の制御に関する指示、或は装置制御指示データストリーム３５１の記載内容に応じて、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９、データ管理モジュール２１０を制御する。プリントジョブの場合は、ジョブ制御モジュール２０５により、描画データストリーム３５２（図３）がトランスレータ２０６によりディスプレイリスト３５５（図３）に変換される。このディスプレイリスト３５５（図３）は、更にレンダラ２０７により中間画像データストリーム３５６（図３）に変換される。そして、この中間画像データストリーム３５６は、画像処理モジュール２０９により最終画像データストリーム３５７（図３）に変換され、この最終画像データストリーム３５７がＭＥ制御モジュール２０８に送られて印刷されるようにスケジュールされる。

更なる一例として、組み込みアプリケーション２０３により提供される、画像データの読み取りと送信の動作について説明する。操作パネル１８から画像データを読み取って送信するように指示された場合、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと送信指示を行う。この送信指示は、組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して直接ジョブ制御モジュール２０５に指示するか、もしくは組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことにより実行される。ジョブ制御モジュール２０５は、画像読み取り部１９から画像データを入力してＲＡＭ２に保持して画像処理モジュール２０９に引き渡す。これにより生成されたスキャン画像データストリーム３６０（図３）を、組み込みアプリケーション２０３に引き渡すようにスケジューリングする。この組み込みアプリケーション２０３は、この引き渡されたスキャン画像データストリーム３６０を、操作パネル１８から指示された形式に変換して送信用データストリーム３５９（図３）を生成し、データ送受信モジュール２０２を介して送信する。或は、操作パネル１８から指示された送信先が、内蔵されている外部メモリ１０である場合は、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと保存の指示を行う。この指示は、組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して直接ジョブ制御モジュール２０５に指示するか、或は組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、画像読み取り部１９から画像データを入力してＲＡＭ２に保持して画像処理モジュール２０９に引き渡す。そして、この画像処理モジュール２０９で生成されたスキャン画像データストリーム３６０（図３）をデータ管理モジュール２１０を介して外部メモリ１０へ格納するようにスケジューリングする。

トランスレータ２０６は、ＰＤＬ等の描画データストリーム３５２を解釈して、レンダリング処理に適した印刷用の中間言語に変換する。このレンダリング処理に適した印刷用中間言語によるプリントデータの記述をディスプレイリスト３５５（図３）と呼ぶ。トランスレータ２０６は、各種のＰＤＬの仕様毎に、それぞれ異なる固有の実装を持ち、どのトランスレータもそれぞれのＰＤＬをレンダラ２０７に固有のディスプレイリスト３５５へ変換する。

レンダラ２０７は、ディスプレイリスト３５５を中間画像データストリーム３５６（図３）に展開する。このレンダラ２０７はＲＴＯＳ２１４を介してレンダラドライバ２２５に依存している。

マーキングエンジン（ME）制御モジュール２０８は、画像処理装置１０００において転写紙への画像形成を行うマーキングエンジン１６を制御する。このＭＥ制御モジュール２０８は、ＲＴＯＳ２１４を介してＭＥドライバ２２６に依存している。

画像処理モジュール２０９は、この画像処理装置１０００の中間画像データストリーム３５６などの画像データに対して、ハーフトーニング、トラッピング、濃淡補正、カラーモノクロ変換など様々な画像処理を行う。

データ管理モジュール２１０は、この画像処理装置１０００の中間画像データストリーム３５６（図３）や、最終画像データストリーム３５７（図３）などのデータストリームを外部メモリ１０へ保存管理する。尚、画像データストリーム以外のデータストリームを保存及び管理可能にしても良い。レイヤＩ／Ｆ２１１は、この画像処理装置１０００内のデータストリームを、インタプリタ環境２１５との間でやりとりする。このレイヤＩ／Ｆ２１１は、データストリームに対するフィルタリング処理のレベル付けのために、大きく内部レイヤＩ／Ｆ２１３と外部レイヤＩ／Ｆ２１２とに分かれる。

外部レイヤＩ／Ｆ２１２は、データ送受信モジュール２０２及び組み込みアプリケーション２０３から、処理要求データストリーム３５０、装置制御指示データストリーム３５１、描画データストリーム３５２、送信用データストリーム３５８，３５９のインタプリタ環境２１５への引き渡しと、フィルタ２２１で処理された各データストリームをデータ送受信モジュール２０２、組み込みアプリケーション２０３、ジョブ制御モジュール２０５へ引き渡す。

内部レイヤＩ／Ｆ２１３は、ジョブ制御モジュール２０５が、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９、データ管理モジュール２１０、画像読み取り部１９とやりとりすることで生成する、ディスプレイリスト３５５、中間画像データストリーム３５６、最終画像データストリーム３５７、スキャン画像データストリーム３６０のインタプリタ環境２１５への引き渡しと、フィルタ２２１で処理されたジョブをジョブ制御モジュール２０５への引き渡す。ここでジョブ制御モジュール２０５だけでなく、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９、データ管理モジュール２１０、画像読み取り部１９とインタプリタ環境２１５の間でも前述のデータストリームのやりとりを行っても良いことはいうまでもない。

リアルタイムＯＳ２１４は、画像処理装置１０００のネイティブコードファームウェアの実行環境を提供するプラットフォームである。このリアルタイムＯＳ２１４は、その上で動作するソフトウェアのために、ソフトウェア構築のために利用する基本的なサービスや、装置１０００が持つハードウェア資源を抽象化したサービスを提供する。また、装置１０００のハードウェアをソフトウェアから利用しやすいインターフェースに抽象化するためのデバイスドライバ構築のフレームワークも提供する。このＲＴＯＳ（Real-Time OS）２１４が提供する機能には、ＣＰＵ１による命令実行コンテクストを抽象化したタスク管理、複数の実行コンテクストを仮想的に同時に動作させる並行処理（concurrent processing）を実現するマルチタスク機構、タスク間でメッセージのやり取りをしたり、同期をとったりするためのタスク間通信（メッセージキューやセマフォなど）、各種のメモリ管理、タイマーやクロック、割り込み管理やＤＭＡの制御などがある。尚、セマフォとは並行して動作しているプロセス間で同期を取ったり割り込み処理の制御を行なう機構を意味する。

インタプリタ環境２１５は、各種のインタプリタ環境、ここではＪａｖａ（登録商標）プラットフォームのランタイム環境に基づき、それに画像処理装置１０００に固有のＡＰＩ群とフレームワーク群を追加して構成されているソフトウェアプラットフォームである。このソフトウェアプラットフォームは、その上で動作するインタプリタ言語で記述されたプログラムに対して動的なソフトウェア動作環境を提供する。このインタプリタ環境は、ネイティブコードによって実装された部分（ネイティブコード部２０１に含まれる）と、そのインタプリタ言語で記述されたプログラムとして実装された部分（図２のインタプリタコード部２２０に含まれる）とを含む。

インタプリタ２１６は、所定の命令セットによって記述された命令列から逐次的に命令を読み出し、それを解釈して実行する。ここでインタプリタ２１６は、Ｊａｖａ（登録商標）仮想マシンによって構成され、命令セットはＪａｖａ（登録商標）のバイトコードである。

標準のＡＰＩライブラリとフレームワーク群２１７は、ＲＴＯＳ２１４が提供する抽象化された各種コンピューティング資源を更にインタプリタ環境固有のモデルによって抽象化して、このＲＴＯＳ２１４上で動作するプログラムのための実行環境を提供する。ここではＪａｖａ（登録商標）プラットフォームを構成する標準的なクラスライブラリ群と、OSGiのフレームワークによって実現している。Ｊａｖａ（登録商標）プラットフォームは、ＲＴＯＳ２１４相当の抽象化された機能を提供し、例えば仮想マシンによる命令実行コンテクストを抽象化したスレッド管理、複数の実行コンテクストを仮想的に同時に動作させて並行処理を実現するマルチスレッド機構、スレッド間でメッセージのやり取りをしたり、同期を取るためのスレッド間通信、高度に抽象化された各種のメモリ管理（コレクションなど）、タイマやクロック、例外管理、ファイルシステムやネットワークのアクセス、外部入出力装置とのインターフェースなどを提供している。OSGiフレームワークは、単一のＪａｖａ（登録商標）仮想マシン上に複数のＪａｖａ（登録商標）アプリケーション（サービス）を動作させる。またアプリケーションのライフサイクルの管理や、アプリケーション間の通信機能などを提供する。このOSGiフレームワーク上には、複数のシステムサービスがプリインストールされている。システムサービスには、インタプリタ環境に新たなアプリケーションを追加、更新、削除するためのサービス管理サービスや、アプレット（Applet）インターフェースに従って実装されたＪａｖａ（登録商標）クラスを画像処理装置の操作パネルに表示して操作パネル１８から操作可能に動作させるためのAppletビューアサービスや、Servletインターフェースに従って実装されたＪａｖａ（登録商標）クラスをクライアントのブラウザから操作可能なＷｅｂアプリケーションとして動作させるためのＨＴＴＰサービスなどが用意されている。特にAppletインターフェースに従って実装されたＪａｖａ（登録商標）アプリケーションは、ＡＷＴのＡＰＩなどを経由して、間接的に操作パネルドライバ２２７とインターフェースすることができる。
尚、OSGiとはOpen Service Gateway Initiativeの略で、ここではOSGiの仕様に基いている事を意味する。

ジョブ制御ライブラリ２１８は、制御ＡＰＩ２０４に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインターフェースを提供する。

フィルタフレームワーク２１９は、組み込みアプリケーション２０３と通信して、ジョブの実行に際して、インタプリタ環境上に実装したフィルタプログラムからの画像処理装置１０００の複数のデータストリームに対する介在を可能とする。

インタプリタコード部２２０は、インタプリタが解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するＡＰＩライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部２０１とインタプリタコード部２２０に跨って位置付けられるソフトウェアは、それぞれの空間の間をインターフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではＪａｖａ（登録商標） Native Interface（JNI）に従って境界部分のプログラミングを行っている。

フィルタ２２１は、インタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているため、組み込みアプリケーション２０３が処理する処理要求データストリームに対する処理を行うことができる。プロトコルスタック２２３は、ＲＴＯＳ２１４のフレームワークに組み込まれ、より下層の外部インターフェースドライバ２２４が制御する外部インターフェース上にトランスポート層以下のプロトコルを実装する。例えば、ネットワークインターフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現し、組み込みアプリケーション２０３に対しては、ＲＴＯＳ２１４を介してバークレイソケットなどのアプリケーションプログラミングのためのインターフェースを提供する。また例えば、外部インターフェースがＵＳＢの場合には１２８４.４などのプロトコルを実現する。

外部インターフェースドライバ２２４は、ネットワークインターフェースやＩＥＥＥ１３９４、ＵＳＢ，ＲＳ２３２Ｃ、セントロニクスなどの各種インターフェースへの接続を提供するハードウェアを駆動する。例えばネットワークの場合、イーサネット（登録商標）などのネットワークに接続するためのネットワークインターフェースハードウェアを駆動して物理層のプロトコルを実現する。

レンダラドライバ２２５はレンダラ２０７を駆動する。レンダラ２０７は、図３のディスプレイリスト３５５を中間画像データストリーム３５６に展開するためのハードウェアである。レンダラ２０７はソフトウェアによって実現してもよいし、展開されるデータストリームは最終画像データストリーム３５７（図３）でもよい。マーキングエンジン（ＭＥ）ドライバ２２６は、転写紙への画像形成を行うマーキングエンジンを駆動する。操作パネルドライバ２２７は、この画像処理装置１０００が備える操作パネル１８の表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。

図３は、本実施の形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れとそれぞれのモジュールにおいて存在するデータストリームを示す図である。図２に示すモジュールと共通するモジュールには同一の符号をつけて説明を省略する。

データ送受信モジュール２０２は、クライアントから受信した、装置制御指示データストリーム３５１と描画データストリーム３５２からなる処理要求データストリーム３５０を、フィルタ２２１を介さない場合に、経路３０１を介して組み込みアプリケーション２０３に流す。この経路３０１は、例えばＲＴＯＳ２１４が提供するメッセージキュー等のタスク間通信機能によって実現される。その他のデータの受け渡しも同様である。

ここでクライアントが、ＬＡＮ２０００を介したホスト上のアプリケーション及びドライバソフトの場合は、クライアントは処理要求データストリーム３５０を生成し、その処理要求データストリーム３５０を、データ送受信モジュール２０２を介して組み込みアプリケーション２０３へ引き渡す。組み込みアプリケーション２０３は、処理要求データストリーム３５０を装置制御指示データストリーム３５１と描画データストリーム３５２とに分割し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５にそれぞれを引き渡す。或は、装置制御指示データストリーム３５１を解釈し、制御ＡＰＩ２０４によってジョブ制御モジュール２０５に対して、クライアントから要求された処理を指示し、描画データストリーム３５２を引き渡す。

一方、クライアントが画像処理装置の操作パネル１８を介した指示の場合は、組み込みアプリケーション２０３で装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡す。或はジョブ制御モジュール２０５に対して制御ＡＰＩ２０４によってクライアントから要求された指示を行う。装置の制御に関する記述部は、一般的にはＪＬ（Job Language）と呼ばれ、ここには描画データの解釈及び展開に関する動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などが含まれる。一方、描画データストリームはＰＤＬによって記述されており、主にページごとの描画が記述されている。

ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した指示に従って装置１０００の制御を行う。或は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５へ入力された装置制御指示データストリーム３５１を解釈して動作を行う。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した装置１０００の制御に関する指示、或は装置制御指示データストリーム３５１の記載内容に応じて、３９０を介して、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９及びデータ管理モジュール２１０を制御する。プリントジョブの場合は、ジョブ制御モジュール２０５は、描画データストリーム３５２をトランスレータ２０６によりディスプレイリスト３５５に変換させ、ディスプレイリスト３５５をレンダラ２０７により中間画像データストリーム３５６に変換させ、中間画像データストリーム３５６を画像処理モジュール２０９により最終画像データストリーム３５７に変換し、最終画像データストリーム３５７がＭＥ制御モジュール２０８に流れて印刷するようにスケジュールする。

更なる一例として、組み込みアプリケーション２０３により提供される画像データの読み取りと送信の際の動作を示す。操作パネル１８から画像データの読み取り及び送信指示が行われた場合、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと送信の指示を行う。この指示は組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して、直接ジョブ制御モジュール２０５に指示するか、或は組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、画像読み取り部１９で読み取られた画像データを入力してＲＡＭ２上に保持して画像処理モジュール２０９に引き渡す。こうして画像処理モジュール２０９で生成されたスキャン画像データストリーム３６０を組み込みアプリケーション２０３へ引き渡すようにスケジューリングする。組み込みアプリケーション２０３は、その引き渡されたスキャン画像データストリーム３６０を操作パネル１８から指示された形式に変換して送信用データストリーム３５９を生成する。そして、この送信用データストリーム３５９を、データ送受信モジュール２０２を介して送信用データストリーム３５９として送信する。或は、操作パネル１８から指示された送信先が、内蔵されている外部メモリ１０の場合は、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと保存指示を行う。この指示は、組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して直接ジョブ制御モジュール２０５に指示するか、或は組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、３９０を介して、画像読み取り部１９から画像データを入力してＲＡＭ２上に保持し、画像処理モジュール２０９に引き渡す。こうして生成されたスキャン画像データストリーム３６０をデータ管理モジュール２１０を介して外部メモリ１０へ格納するようにスケジューリングする。

以上の処理は全てネイティブコード部分２０１に実装されている。

図４は、本実施の形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。各モジュールにおけるデータストリームは図３と同様であり、前述の図面と共通する部分は同じ記号で示している。

データ送受信モジュール２０２は、データストリームに対してフィルタ処理を施す場合には、処理されたデータストリームを、経路３０６を介して外部レイヤ２１２に流す。この経路３０６は、例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間の通信機能によって引き渡されるが、その他のデータの受け渡しでも良い。外部レイヤＩ／Ｆ２１２は、レイヤＩ／Ｆ２１１の中でも特に、基本的には画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、この処理要求データストリーム３５０を画像処理装置１０００内で分割した装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換、生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８をインタプリタ環境２１５へ引き渡す。尚、これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。

外部レイヤＩ／Ｆ２１２は、その受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境上２１５に実装されたフィルタプログラム群２２１を管理している。フィルタフレームワーク２１９は、そのデータストリームを、経路３０８を介してフィルタ２２１に流す。この経路３０８では、例えばインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。インタプリタ環境２１５内のデータのやりとりに関しても以下同様である。ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。
尚、ランタイムモジュールとはプログラムを実行する際に必要となるソフトウェアモジュールを意味する。

フィルタ２２１は、入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９を介してフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤＩ／Ｆ２１２に引き渡す。これにより外部レイヤＩ／Ｆ２１２は、そのデータストリームを経路３１１を介して組み込みアプリケーション２０３に流す。また或は、外部レイヤＩ／Ｆ２１２が、経路３７０を介してデータ送受信モジュール２０２にデータストリームを流し、そのデータストリームを、前述のように経路３０１を介して組み込みアプリケーション２０３に流す構成をとってもよい。

制御パス３１２，３７２は、フィルタフレームワーク２１９の状態に応じて、データ送受信モジュール２０２から組み込みアプリケーション２０３に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、前述の経路３０６，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３０１が有効となり、データストリームは直接、データ送受信ストリーム２０２から組み込みアプリケーション２０３に流れる。この場合、フィルタフレームワーク２１９が介在することによるオーバヘッドが避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００のデータ処理性能を発揮できる。

組み込みアプリケーション２０３がデータストリームに対してフィルタ処理を施す場合には、データストリームは経路３１４を介して外部レイヤ２１２に流れる。この経路３１４は例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間通信機能によって引き渡されるが、その他のデータの受け渡しも同様である。外部レイヤ２１２は、前述したように、レイヤＩ／Ｆ２１１の中でも特に、基本的には画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、処理要求データストリーム３５０が画像処理装置１０００内で分割された装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換、生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８をインタプリタ環境２１５へ引き渡す。これらのデータストリームはデータ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。外部レイヤ２１２は、受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境２１５に実装されたフィルタ２２１を管理している。フィルタフレームワーク２１９は、受け取ったデータストリームを経路３０８を介してフィルタ２２１に流す。この経路３０８は、例えばインタプリタ環境２１５が提供するスレッド間通信機能によって実現される。インタプリタ環境２１５のデータのやりとりに関しても以下同様である。尚、ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。

フィルタ２２１は、受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９よってフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９はフィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤ２１２に引き渡し、外部レイヤ２１２は、経路３１５を介して、そのデータストリームをジョブ制御モジュール２０５に流す。尚、ここで外部レイヤ２１２が、経路３７１を介して、そのデータストリームを組み込みアプリケーション２０３に流し、前述のように経路３１３を介してジョブ制御モジュール２０５に流す構成をとってもよい。

制御パス３１６，３７２は、フィルタフレームワーク２１９の状態に応じて組み込みアプリケーション２０３からジョブ制御モジュール２０４に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１４，３０７が有効となりフィルタ２２１による前処理が施されるが、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３１３が有効となり、データストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク２１９が介在することによりオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００でのデータ処理性能を発揮できる。

次に、ジョブ制御モジュール２０５が、データストリームに対してフィルタ処理を施す場合を説明する。この場合、データストリームは、経路３１８を介して、内部レイヤＩ／Ｆ２１３に流れる。経路３１８は、例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間の通信機能によって引き渡される。その他のデータの受け渡しも同様である。内部レイヤＩ／Ｆ２１３は、レイヤＩ／Ｆ２１１の中でも特に、トランスレータ２０６が描画データストリーム３５２を処理することで生成するディスプレイリスト３５５、レンダラ２０７がディスプレイリスト３５５を処理することで生成する中間画像データストリーム、画像処理モジュール２０９が中間画像データストリーム３５６を処理することで生成する最終画像データストリーム３５７、画像読み取り部１９から読み込まれたスキャン画像データストリーム３６０など、画像処理装置１６００で生成されるデータストリームをインタプリタ環境２１５へ引き渡す。これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。内部レイヤＩ／Ｆ２１３は、経路３１８を介して受け取ったデータストリームを、フィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールはインタプリタ環境２１５に実装されたフィルタ２２１を管理している。このインタプリタコード部２２０におけるフィルタ処理は前述の処理と同じであるため、その説明を省略する。

フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して内部レイヤＩ／Ｆ２１３に引き渡す。内部レイヤＩ／Ｆ２１３は、そのデータストリームを経路３１９を介してジョブ制御モジュール２０５に流す。尚、内部レイヤＩ／Ｆ２１３が直接、トランスレータ２０６、レンダラ２０７、画像処理モジュール２０９、ME制御モジュール２０８、データ管理モジュール２１０へ引き渡す構成をとってもよい。

制御パス３２０，３７２は、フィルタフレームワーク２１９の状態に応じてデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１８，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には経路３１７が有効となり、データストリームは直接ジョブ制御モジュール２０５がスケジューリングした次のモジュールに流れる。この場合、フィルタフレームワーク２１９が介在することによりオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置のデータ処理性能を発揮できる。

図５は、本実施の形態のインタプリタ環境２２０に構築されるフィルタフレームワーク２１９のクラスを説明する図である。

フィルタ管理（FilterManager）クラス４０１は、フィルタフレームワーク２１９のランタイム環境を実現するオブジェクトのクラスである。このフィルタ管理クラス４０１は一つのコネクタ（Connector）クラス４０５のオブジェクトをコンポジション（composition）として持つ。また複数（ｎ個）のフィルタ（Filter）抽象クラス４０２のオブジェクトへの参照と、複数｛（ｎ−１）個｝のパイプ（Pipe）クラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワーク２１９のランタイムに、インストールされた複数のフィルタクラス４０２の具体クラスを管理するためのinstalledFilter属性４１０を備えている。

フィルタ抽象クラス４０２は、各種のフィルタクラスを抽象化する抽象クラスである。このフィルタ抽象クラス４０２は、フィルタ名称を示す「name」属性などを備える。また、入力（input）属性として、入力ストリーム（InputStream）抽象クラス４０３を継承したクラスのオブジェクトへの参照を有している。また出力（output）属性として、出力ストリーム（OutputStream）抽象クラス４０４を継承したクラスのオブジェクトへの参照を有している。フィルタ抽象クラス４０２の具体クラスは、Runnableインターフェース４１１を実装し「run」メソッドを有している。フィルタ管理クラス４０１のオブジェクトが、管理している各種のフィルタ抽象クラス４０２のインスタンスを生成してデータストリームのフィルタ処理のために配置する時、配置される各フィルタオブジェクトに対応してスレッドを生成し、並行して動作するスレッドの実行コンテクストでフィルタオブジェクトのrunメソッドを実行する（即ち、コンストラクタのパラメータにフィルタオブジェクトを渡してＪａｖａ（登録商標）.lang.Threadオブジェクトを生成し、startする）。このようにして個々のフィルタオブジェクトは自律的に動作する。

入力ストリーム抽象クラス４０３は、データストリームの入力元の抽象クラスで、呼び出しの度に、逐次的にデータを読み出すことができるreadメソッドを備える。

出力ストリーム抽象クラス４０４は、データストリームの出力先の抽象クラスで、呼び出しの度に、逐次的にデータを書き込むことのできるwriteメソッドを備える。

コネクタクラス４０５は、インタプリタ環境のオブジェクトとネイティブコードとの間でデータストリームを交換するための接点を表現したオブジェクトのクラスである。コネクタクラス４０５は、入力ストリーム抽象クラス４０３を継承した具体クラスであるConnectorInputStreamクラス４１２のオブジェクトをコンポジションとして持ち、そのreadメソッドによって、ネイティブコード２０１のデータ送受信モジュール２０２から流れたデータストリーム３０６を逐次的に読み出すことができる。また、コネクタクラス４０５は、出力ストリーム（OutputStream）抽象クラス４０４を継承したConnectorOutputStreamクラス４１３のオブジェクトもコンポジションとして持ち、そのwriteメソッドによって逐次的に書き込んだデータストリームは、ネイティブコード２０１のジョブ制御モジュール２０５へデータストリームとして流れる。

パイプ（Pipe）クラス４０５は、データストリームに対して複数のフィルタリング処理を施す際にフィルタクラス４０２の一連のオブジェクト間を連結するために用いるオブジェクトのクラスである。このパイプクラス４０５は、出力ストリーム抽象クラス４０４を継承したPipedOutputStreamクラス４１４と、入力ストリーム抽象クラス４０３を継承したPipedInputStreamクラス４１５のそれぞれのオブジェクトをコンポジションとして持つ。パイプオブジェクトのPipedOutputStreamオブジェクト４１４とPipedInputStreamオブジェクト４１５とは接続されていて、スレッド間通信を実現している。即ち、あるフィルタオブジェクトが、あるパイプオブジェクトが持つPipedOutputStreamオブジェクトへwriteメソッドによって逐次的に書き込んだデータストリームを、別のフィルタオブジェクトが、そのパイプオブジェクトが持つPipedInputStreamオブジェクトからreadメソッドによって逐次的に読み出すことができる。

図６は、インタプリタ環境２１５に構築されるフィルタフレームワーク２１９が管理するオブジェクトのインスタンス図で、図６（Ａ）は、１つのフィルタが有効な状態のとき、フィルタフレームワーク２１９のランタイムが管理しているオブジェクト間の関係を示している。

コネクタ（Connector）オブジェクト５０１は、コネクタクラス４０５のオブジェクトである。フィルタオブジェクト５０２は、フィルタ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタオブジェクト５０２の入力属性には、コネクタオブジェクト５０１が持つConnectorInputSteamオブジェクトの参照が保持されている。また出力属性にも、コネクタオブジェクト５０１が有するConnectorOutputStreamオブジェクトの属性が保持されている。フィルタオブジェクト５０２は、「input」の指すConnectorInputStreamオブジェクトからreadしたデータストリームに対してフィルタ処理を施す。こうしてフィルタ処理を施したデータストリームを、「output」の指すConnectorOutputStreamオブジェクトへwriteする。

以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。

図６（Ｂ）は、２つのフィルタが有効な状態のとき、フィルタフレームワーク２１９のランタイムが管理しているオブジェクト間の関係を示している。

フィルタ１オブジェクト５０３は、フィルタ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ１オブジェクト５０３の入力属性には、コネクタオブジェクト５０１が持つConnectorInputStreamオブジェクトの参照が保持されている。フィルタ１オブジェクト５０３は、inputの指すConnectorInputStreamオブジェクトからreadしたデータストリームに対してフィルタ処理を施す。フィルタ１オブジェクト５０３の出力属性には、パイプオブジェクト５０４が持つPipedOutputStreamオブジェクトの参照が保持されており、フィルタ１オブジェクト５０３はフィルタ処理を施したデータストリームをoutputの指すPipeedOutputStreamオブジェクトへwriteする。

パイプオブジェクト５０４は、パイプクラス４０５のオブジェクトである。このパイプオブジェクト５０４は、PipedOutputStreamオブジェクトとPipedInputStreamオブジェクトとを接続された状態で持つ。パイプオブジェク５０４が持つPipedOutputStreamオブジェクトのwriteメソッドの呼び出しによって引き渡されたデータストリームは、パイプオブジェクト５０４が持つPipeInputStreamオブジェクトのreadメソッドの呼び出しによってデータストリームとして読み出すことができる。

フィルタ２オブジェクト５０５は、フィルタ抽象クラス４０２を具体化した具体クラスのオブジェクトで、この入力属性にはパイプオブジェクト５０４が持つPipedInputStreamの参照が保持されており、inputの指すパイプオブジェクト５０４からreadしたデータストリームに対してフィルタ処理を施す。また、このフィルタ２オブジェクト５０５の出力属性にはコネクタオブジェクト５０１が持つConnectorOutputStreamの参照が保持されており、フィルタ処理を施したデータストリームをoutputの指すConnectorオブジェクト５０１が持つConnectorOutputStreamへwriteする。

以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。また、同様にして間にパイプオブジェクト５０４を挟みこみながら、より多くのフィルタオブジェクトをデータストリーム処理のために配置することもできる。

図７（Ａ）〜（Ｃ）は、本実施の形態に係るフィルタフレームワーク２１９を操作するためのユーザインターフェース例を説明する図である。このフィルタフレームワークを操作するためのユーザインターフェースは、標準ライブラリとフレームワーク２１７（図１）に含まれるＨＴＴＰサービスによってウエブ（Ｗｅｂ）アプリケーション（Servlet）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の操作パネル１９から操作するように構成してもよい。

図７（Ａ）は、この実施の形態の画像処理装置１０００のフィルタフレームワーク２１９に新しいフィルタ２２１をインストールして追加するためのユーザインターフェースを示している。このフィルタインストール画面６０１は、ファイル名入力フィールド６０２、参照ボタン６０３及びインストールボタン６０４を備えている。

ユーザは、クライアントコンピュータのファイルシステムに予め格納されているインストールしたいフィルタクラス４０２のクラスファイルのファイルパスを、ファイル名入力フィールド６０２に入力する。

ユーザが、参照ボタン６０３をクリックすると、クライアントコンピュータのＷｅｂブラウザが提供するファイル選択ダイアログがオープンされて、クライアントコンピュータのファイルシステム内をブラウズして、インストールしたいフィルタクラス４０２のクラスファイルを選択できる。このファイル選択ダイアログによってユーザが選択したファイルのファイルパスは、自動的にファイル名入力フィールド６０２に入力される。

次にユーザが、インストールボタン６０４をクリックすると、クライアントコンピュータのＷｅｂブラウザによって、ファイル名入力フィールド６０２に入力されたファイルパスのクラスファイルが、この画像処理装置１０００で待機している新規フィルタインストールのためのＷｅｂアプリケーションに送信される。こうしてクラスファイルを受信したＷｅｂアプリケーションは、この画像処理装置１０００の不揮発性メモリ３に、その受信したクラスファイルを格納する。また、そのクラスファイルをインタプリタ環境２１５に動的にロードしてオブジェクトインスタンスを生成する。そして、その生成したフィルタオブジェクトを、フィルタフレームワークランタイムが管理する有効フィルタ列のリストの最下流に配置する（このとき、既に有効なフィルタオブジェクトがフィルタ列に存在すれば、新規のフィルタオブジェクトを連結するために新たなパイプオブジェクトを生成する）。

このようなユーザインターフェースをＷｅｂアプリケーションとして実装している場合には、フィルタの実装クラスの装置１０００へのアップロードは、ＲＦＣによって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用している。従って、この場合、ファイル名入力フィールド６０２と参照ボタン６０３はクライアントコンピュータのＷｅｂブラウザによって表示されており、インストールボタン６０４はフォームのsubmitに対応している。

また、このユーザインターフェースをApplet型のサービスとして実装する場合には、この画面６０１は、画像処理装置１０００の操作パネル１８の表示部に表示される。ファイル名入力フィールド６０２で指定されるファイルは、画像処理装置１０００がリムーバブル記憶メディアを備える場合は、そのリムーバブル記憶メディア中のファイルパスを指定しても良い。また或は、ネットワーク経由で画像処理装置からＨＴＴＰやＦＴＰ等のファイル転送プロトコルによって読み出しアクセス可能な共有ファイルを、ＵＲＬなどによって指定してもよい。

図７（Ｂ）は、本実施の形態に係る画像処理装置１０００のフィルタフレームワーク２１９にインストールされているフィルタを配置するためのユーザインターフェースを説明する図である。

このフィルタ配置画面６０５において、表６０６は、フィルタフレームワーク２１９のランタイムにインストールされているフィルタ群を一覧表示している。この表６０６の各行は、インストールされているフィルタのそれぞれに対応している。また、この表６０６の「選択」列にはチェックボックスが並んでおり、ここでチェックされた行のフィルタが後述する操作の対象として選択される。表６０６の「順序」列には、そのフィルタが無効状態にある場合には「無効」が表示される。また有効状態にある場合には、そのデータストリーム処理の上流から下流に向かって昇順に付された番号が表示される。そして表６０６の「名称」列には、そのフィルタオブジェクトのname属性に記述されたフィルタ名称が表示される。

６０７〜６１１は、選択されたフィルタに対する操作を指示するためのボタンであり、表６０６の選択列でチェックされた行のフィルタを対象とする操作を指示する。ユーザが、詳細表示ボタン６０７をクリックすると、表６０６で選択されたフィルタに関する詳細情報が表示される。この詳細情報としては、フィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名（ファイルパスやＵＲＬ）、インストールされた日時などがある。

上へボタン６０８がクリックされると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の上流方向に一段階だけアップする。一方、下へボタン６０９がクリックされると、選択されたフィルタのフィルタ列内における順序が、データストリーム処理の下流方向に一段階だけダウンさせる。有効／無効のトグルボタン６１０がクリックされると、選択されたフィルタが有効状態にある場合は無効状態に変更され、無効状態にある場合には有効状態に変更される。無効状態にされたフィルタオブジェクトは削除されるが、フィルタクラス４０２はインストールされた状態で残って、フィルタフレームワークランタイムの管理下に留まる。アンインストールボタン６１１がクリックされると、選択されたフィルタのクラスファイルを画像処理装置１０００のインタプリタ環境から削除する。

図７（Ｃ）は、フィルタがデータストリームを対象としたものかを選択するユーザインターフェース例を示す図である。

フィルタインストール画面６０１やフィルタ配置画面６０５を表示する前段階で、この対象データストリームの選択画面６１２を表示してユーザに選択させることにより、ユーザがフィルタ処理に関するインストールや設定を望むデータストリームを決定できる。

リスト６１３は、画像処理装置１０００内に存在するデータストリームをリスト形式で選択するためのユーザインターフェースである。フィールド６１４は、リスト６１３から選択されたデータストリームを表示する。決定ボタン６１５は、フィールド６１４で指定されているデータストリームに対するフィルタのインストールと、管理を行うように決定するためのボタンである。このボタン６１５が押下されると、該当するデータストリームのフィルタインストール画面６０１やフィルタ配置画面６０５が表示される。

フィルタの処理対象となるデータストリームを選択する他の方法としては、フィルタ抽象クラス４０２にフィルタ属性を設け、フィルタのインストールやフィルタの管理時にフィルタ属性を参照することにより、フィルタ対象データストリームを特定するようにしても良い。

図８は、本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。

この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワーク２１９が管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で実行される。

まずステップＳ１で、必要な前処理を行う。この前処理には、フィルタ２２１が内部的に利用する属性の初期化や、パターンマッチングに使用するパターン記述に対する前処理、入力ストリームや出力ストリームをより使いやすくする機能を付加する（例えば入力ストリームを先読み可能にしたり、システムリソースを有効に利用するためにバッファリングを拡張したりする）ための修飾クラス（Ｊａｖａ（登録商標）.io.FilterInputStreamやＪａｖａ（登録商標）.io.FilterOutputStreamの具体クラス）によってストリームをラップする処理などが含まれる。次にステップＳ２で、入力属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。そしてステップＳ３で、入力したデータストリームから、このフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。このフィルタが操作するべきデータパターンは、固定のデータ列そのものでも良く、或は正規表現（regular expression）等の形式言語による記述でもよい。尚、パターン記述に合致するデータの出現をデータストリーム中から発見するための各種の実装は広く知られており、例えばgrep、sed、AWK、Perlなどが有名である。

パターンマッチングを効率良く行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較し、ハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Knuth-Morris-Prattの方法や、Boyer-Mooreの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のＪａｖａ（登録商標）プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる（Ｊａｖａ（登録商標）.util.regex）。例えばデータストリームの上流のパターンに応じて状態が変化し、その変化した状態に従って下流のパターンの解釈を変えなければならない場合であって、正規表現などでは、却って記述が困難なほど複雑なパターンマッチングが必要とされる場合には、そのパターンの特徴そのものを評価するアルゴリズムをＪａｖａ（登録商標）プログラムとして書き下してもよい。このようにして、どれほど複雑なパターンマッチングであっても素直に実装することができる。

次にステップＳ４で、パターンマッチングの結果を判定し、パターン記述に合致するデータをデータストリーム中に発見した場合はステップＳ５に進むが、そうでなければステップＳ６に進む。ステップＳ５では、パターン記述に合致したデータストリームの部分データ列に対してこのフィルタの目的に応じた操作を施し、その結果で置き換える。次にステップＳ６で、処理済の部分データ列（即ち、監視しているパターンが現れなかったデータ列、或は、監視しているパターンを含むデータ列に対してステップＳ５の処理を施したデータ列）を出力ストリームに書き込む。そしてステップＳ７で、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了するが、そうでなければステップＳ２に戻って、上記の手順を繰り返す。

図９は、本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。

この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で動作することになる。

まずステップＳ１１で、必要な前処理を行う。この前処理には、フィルタが内部的に利用する属性の初期化や、パターンマッチングに使用するパターン記述に対する前処理、入力ストリームや出力ストリームを、より使いやすくする機能を付加する（例えば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりする）ための修飾クラス（Ｊａｖａ（登録商標）.io.FilterInputStreamやＪａｖａ（登録商標）.io.FilterOutputStreamの具体クラス）によってストリームをラップする処理などが含まれる。次にステップＳ１２で、新たな部分データストリームを生成する。次にステップＳ１３で、入力属性にセットされている入力ストリームから、予め定められた量のデータを読み出す。そしてステップＳ１４で、その読み込まれたデータストリームに対して、ステップＳ１２で生成された部分データ列を追加する。次にステップＳ１５で、処理済の部分データ列を出力ストリームに書き込む。そしてステップＳ１６で、入力ストリームに存在する残りデータを出力ストリームに書き込む。

図１０は、本実施の形態に係る処理要求データストリームを説明する図である。

８０１は処理要求データストリームを示している。クライアントからの、この画像処理装置１０００に対する処理の要求は、クライアントが処理要求データストリーム８０１を作成して画像処理装置１０００に送信することにより行われ、要求された処理の実行は画像処理装置１０００が、その処理要求データストリーム８０１を処理することで実行される。この処理要求データストリーム８０１は、大きく装置制御指示データストリーム８０２（図３の３５１に相当）と描画データストリーム８０３（図３の３５２に相当）に分けることができる。

装置制御指示データストリーム部８０２では、この画像処理装置１０００への、描画以外の処理要求に関する指示が記述されている。具体的には、以下のような指示を行うことが一般的に知られており、画像処理装置１０００が備える機能により規定されている。１行目の「ジョブ種類」の属性は、「印刷」、「セキュアプリント」、「画像取得」等の値を取り得、この画像処理装置１０００が備える各種ジョブのタイプを表している。「画像取得」等のように描画指示を行わない処理要求の場合は、描画データストリーム８０３は一般的には、このような処理要求データストリーム８０１に含まれない。２行目の「部数」の属性は、印刷物のコピーを何セット生成するかを表している。３行目の「ページレイアウト」の属性は、「１ページ／枚」「２ページ／枚」「４ページ／枚」など１枚の用紙に複数ページを面付けするための指定や、「ポスター（２×２）」、「ポスター（３×３）」などのように、１ページを拡大して複数枚の用紙に分割して印刷する指定のようなページレイアウト指定を表している。４行目の「配置順」の属性は、「左上から右向き」、「左上から下向き」、「右上から左向き」、「右上から下向き」等の値を取り、ページレイアウト時の各面の配置指定を表す。５行目の「印刷方法」の属性は、「片面印刷」、「両面印刷」、「製本印刷」等の値を取り、これにより印刷方法を表す。６行目の「とじ方向」の属性は、「長辺とじ（左）」、「長辺とじ（右）」、「短辺とじ（上）」、「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。７行目の「排紙方法」の属性は、「指定しない」、「ソート」、「ステイプル」、「パンチ穴」などの値をとり、フィニッシングの方法を表す。８行目の「給紙」属性は、「自動」、「手差しトレイ」、「カセット」、「デッキ」、或は「普通紙」、「厚紙」、「色紙」、「ＯＨＰ」などの値をとり、画像形成の対象とする用紙（転写紙）の給紙指定を表す。９行目の「使用ＰＤＬ」は、処理要求内容が描画指示である場合に使用され、描画データストリームに使用されるＰＤＬの種別を表している。

描画データストリーム部８０３は、処理要求内容が描画指示である場合に使用され、描画データストリームは一般的にはＰＤＬで構成される。

図１１は、本実施の形態に係る描画データストリーム８０３に対するフィルタが行う処理を説明する図である。

互換化フィルタ９０１は、この描画データストリーム８０３のフィルタクラスのオブジェクトを示し、入力データストリームに現れる描画データストリーム８０３における互換性の問題を解決する処理を施して出力ストリームに書き込む。この描画データストリーム８０３における互換性の問題として、ここでは代表的なＰＤＬの一つであるAdobeのPostScript仕様を、各社ベンダが実装した画像処理装置間におけるベンダごとの解釈の差異に基づく問題と、その解決の例を説明する。

あるベンダの画像処理装置は、PostScriptの「setpagedevice」で「/DeferredMediaSelection」が真のときカスタム用紙扱いとして用紙要求をパネルに表示し、偽の場合には、指定されたサイズから±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従うものと解釈して実装されていた。また別のベンダの画像処理装置では、「/DeferredMediaSelection」が真の場合は、指定されたサイズそのもののサイズ（範囲なし）で定型用紙を検索し、定型にない場合はカスタム用紙扱いとし、一方、偽の場合には、±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従うように実装されていた。ここで、更に別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、これらの内の後者の解釈に基づく挙動を前提として構築されたとすると、印刷要求に対して前者の画像処理装置では、カスタム用紙扱いとなってしまい、「用紙なし」が操作パネルに表示されて印刷されない。従って前者の画像処理装置のベンダは、この互換性の問題に対して、できるだけ低コストでかつ速やかに解決することが求められる。このような要求に対しては、印刷要求データストリームに現れるsetpagedeviceの「/DeferredMediaSelection」パラメータを真（true）から偽（false）に変換することで、少なくとも暫定的に応えることができる。互換化フィルタ９０１は、このような問題を解決するために働くフィルタオブジェクトであり、入力データストリームから「/DefereedMediaSelection」が真（true）で指定されたsetpagedeviceに対するパターンマッチングを行い、マッチした場合は、偽（false）に置き換えた力データストリームを出力する。

９０２はフィルタへの入力データストリームの一例である、PostScriptのプリントデータである。２行目にパターンに合致する部分データが出現する。９０３は、入力データストリーム９０１がフィルタによりフィルタ処理されて出力された出力データストリーム例を示し、フィルタ処理されたPostScriptのプリントデータで示されている。この出力データストリーム９０３では、２行目のデータの中で「true」という文字列が「false」へ変更されている。

図１２は、本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。

上記の例では、画像処理装置間の仕様の差異に基づく互換性の問題を解決するために、フィルタによるデータストリームのパターンマッチングと置換の技術を用いたが、同様の技術を、画像処理装置の実装の不具合（ファームウェアのバグなど）を緊急回避するために用いることもできる。例えば、ある画像処理装置のあるバージョンのリリースにおいて、ＬＩＰＳ（登録商標）言語の「イメージ領域確保命令（VDM）」に指定されるイメージの幅が８の倍数でなければ描画不正が発生するというバグがあったとする。

１００１は障害回避フィルタを示し、例えば、ＬＩＰＳ（登録商標）データストリーム１００２から障害を発現させるパターンを発見（VDMのイメージ幅が「２２５」であり８の倍数でない）し、その障害を顕在化させず同等の機能を達成するために、１００３で示すようなデータストリームに変換する。ここでは、VDMのイメージ幅を８の倍数で、「２２５」より大きい値である「２３２」）に変換している。

図１３は、本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。

最適化フィルタ１１０１は、描画データストリームに対する最適化フィルタクラスのオブジェクトを示し、入力ストリームを読み出してデータストリーム中に現れる冗長に記述されたＰＤＬデータを発見し、それをより効率の良い同機能のデータに変換して出力ストリームに書き込む。画像処理装置のドライバが生成するＰＤＬデータストリームは、クライアントのプリント要求システムやアプリケーション側の都合によって、どうしても繰り返しなどの冗長な処理がパターンを含む傾向にある。このような冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換える。

１１０２は、フィルタ１１０１に入力される入力データストリームの一例を示す。この入力ストリーム１１０２では、１１０３で示すように、横長の長方形を塗りつぶすために３つの正方形の塗りつぶしを繰り返すように記述されている。１１０４は、この最適化フィルタ１１０１からの出力データストリームの一例を示している。ここではフィルタ１１０１は、冗長な繰り返しパターンを検出し、それを等価な１つの横長の矩形の塗りつぶし１１０５に書き換えている。

図１４は、本実施の形態に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。

１２０１は、装置制御指示データストリーム３５１に対する機能拡張フィルタクラスのオブジェクト例を示している。機能拡張フィルタ１２０１は、入力データストリーム１２０２を読み出して、その入力データストリームに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力データストリームに書き込む。この機能拡張の例として、顧客システムが専用のＰＤＬドライバを抱えていて、そのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応のときに、そのドライバを変更することなく画像処理装置１０００のフィルタの対応によって、装置１０００の新機能を活かす場合で説明する。

機能拡張フィルタ１２０１は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための装置制御指示設定をその属性として持つ。フィルタオブジェクトの属性値は、装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。具体的には前述のように画像処理装置が備える機能により規定されている。

入力データストリーム１２０２は，印刷データストリームの機能拡張フィルタ１２０１に入力されるデータストリームであり、画像処理装置１０００が受信した旧来のアプリケーションや、画像処理装置のドライバが生成する処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム３５１である。

出力データストリーム１２０３は、この装置制御指示データストリームの機能拡張フィルタ１２０１が逐次処理を行って出力するデータストリームを示す。入力データに存在した単純な処理要求データストリームに加えて、画像処理装置１０００の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において、機能拡張フィルタ１２０１の属性のような各種属性の指定が可能である。

この出力データストリーム１２０３において、１行目の「SetJob」は、ジョブ単位の設定の開始を表す。２行目の「ジョブ設定データ」は、この位置に各種のジョブ単位の設定データが存在することを示す。３行目の「BinderStart」は、複数文書をひとまとめにする単位の開始を表す。４行目の「SetBinder」は、複数文書をまとめた単位に対する設定の開始を表す。５行目の「文書束設定データ」は、この位置に複数文書をまとめた単位に対する設定データが存在することを示す。６行目の「DocumentStart」は文書の開始を表すデータである。７行目の「SetDocument」は、文書単位の設定の開始を表す。８行目の「文書設定データ」は、この位置に文書を単位とする設定データが存在することを示す。

図１５は、機能拡張フィルタ１２０１を操作するためのユーザインターフェース例を示す図である。

フィルタ操作のためのユーザインターフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによって、Ｗｅｂアプリケーション（Servlet）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の持つ操作パネル１８から操作するように構成してもよい。

１３０１は、機能拡張フィルタ１２０１の基本操作画面を示し、この画面を使用して、フィルタオブジェクト属性の確認や変更など操作できる。１３０２は、ジョブ種類の属性を操作するのに使用される。１３０２は、部数属性を設定するのに使用される。１３０３は、ページレイアウト属性を設定するのに使用される。１３０４は、配置順の属性を設定するのに使用される。１３０５は、印刷方法の属性を設定するのに使用される。１３０６は、とじ方向の属性を設定するのに使用される。１３０７は、排紙方法の属性を設定するのに使用される。１３０８は、給紙属性を設定するのに使用される。ヘルプボタン１３０９は、このフィルタの使い方、機能、属性の意味などの説明を表示するのに使用される。「標準に戻す」ボタン１３１０は、各種属性をデフォルト値に戻す場合に指示される。適用ボタン１３１１は、属性値の変更操作が適用され、新しい値を実際にフィルタオブジェクトの属性として設定するために使用される。１３１３はプレビューアイコンを示し、各種属性を画面上で確認するために、いくつかの重要な属性についてその値の状態に応じた模式図が表示される。

以上説明したように本実施の形態１によれば、以下のような効果がある。
（１）プリント要求受信サーバをファームウェアとして静的に実装し、その受信サーバで受信したデータストリームを、組み込みＪａｖａ（登録商標）環境上に実装した動的ロードや動的リンク可能なフィルタソフトウェアに引き渡すインターフェースを設けた。これにより、安定部分と動的部分を明確に分離できるため、装置のファームウェア全体を動的で冗長なソフトウェアに置き換えるといった非効率な処理や、Ｊａｖａ（登録商標）環境側に実装して二重に持ってしまうといった非効率も防止できる。これにより、コスト面でも、また開発の負荷の面でも合理性のあるフィルタフレームワークが実現できた。更に、納入済みの装置に対するフィルタの動的な追加や置き換えを容易にできるため、低いサポートコストでより迅速に顧客のニーズに対処できる。
（２）より洗練されたＪａｖａ（登録商標）環境でフィルタを実装するため、通常、組み込みシステムでは困難な動的なメモリ管理が有効な高度なパターンマッチングアルゴリズムを容易に実装できる。また高度にモジュール化された再利用性の高いソフトウェアとして設計するため、オブジェクト指向パラダイムに基づくデザインパターンを容易に採用できる。その結果、生産性の高いフィルタ部の実装を実現できる。
（３）フィルタにより、パターンマッチングを用いて、入力データストリームから他の実装との互換性点で問題となるＰＤＬデータを発見し、そのＰＤＬデータを適正に変更することができる。これにより、互換性の問題や障害を低コストで解消できた。特に、顧客環境におかれたシステムや、アプリケーションや画像処理装置のドライバに影響を及ぼすことなく、画像処理装置側に閉じた対応だけで達成できる。また、フィルタを配置しない場合には、フィルタフレームワークが介在することによるオーバヘッドを回避できる構成であるため、フィルタを配置しない場合にも画像処理装置本来のデータ処理性能を維持できている。
（４）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタで、冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換えることができ、ＰＤＬの処理システムの主要部には全く影響を与えずに印刷処理のパフォーマンスを改善できる。画像処理装置側で閉じて最適化処理を行うので、顧客環境のシステムやアプリケーションや画像処理装置ドライバを改造する必要もない。またフィルタの生産性が高く、インストールなどのメンテナンスも容易であるため、各顧客の利用形態に即した最適化を行うことができる。
（５）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタに、新機能を活かすために必要なデータを追加することで、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能となる。
（６）Ｊａｖａ（登録商標）環境がファームウェアの更にもう一層のソフトウェアプラットフォームとして、そのファームウェアで動作するフィルタのために、追加機能の設定を操作するためのユーザインターフェースをフィルタに備えたことにより、顧客の利用形態に即して個別対応した機能拡張が提供できる可能性もある。
（７）フィルタ処理を、装置の制御に関する指示命令で構成される装置制御データストリーム部、ＰＤＬなど描画に関する指示命令で構成される描画データストリーム部のそれぞれに対して最適なフィルタ処理が可能となった。

［実施の形態２］
図１６は、本発明の実施の形態２に係る送信用データストリーム１４０１を説明する図で、この実施の形態２に係るハードウェア構成及びソフトウェア構成は前述の図１〜図４と同じであるため、その説明を省略する。

クライアントからの処理要求に応じて、画像処理装置１０００は、クライアントが指定した先へ画像データなどを送信する。その際、画像処理装置１０００は、この送信用データストリーム１４０１を生成し、データ送受信モジュール２０２より送信する。送信用データストリーム１４０１は、送信用データストリームのジョブ種類を記載しているデータストリーム部１４０２と、画像データストリーム１４０３に大別できる。このデータストリーム部１４０２には、画像データそのもの以外の情報が記述されている。このデータストリーム部１４０２のフォーマットは、画像処理装置１０００が備える機能により規定されている。このデータストリーム部１４０２は、データ送信処理を行う際に、ジョブ制御モジュール２０５、或は組み込みアプリケーション２０３により画像データに付加され、送信用データストリームとしてデータ送受信モジュール２０２から送信される。画像データストリーム部１４０３は、画像読み取り部１９から入力されたスキャン画像データストリーム３６０（図３）が画像処理モジュール２０９で処理されることで生成される。尚、ここで送信用データストリーム１４０１、データストリーム部１４０２、画像データストリーム１４０３は前述のように、それぞれフィルタ処理が可能である。

以上説明した実施の形態２によれば、画像処理装置内に存在するスキャン画像データストリーム３６０、画像データストリーム、送信用データストリーム３５９のそれぞれに対して最適なフィルタ処理が可能となった。

［他の実施の形態］
上記以外の画像処理装置内に存在するデータストリームとしては、ＰＤＬが処理されることで生成されるディスプレイリスト３５５、画像処理装置において最終的に生成される最終画像データストリーム３５７、最終画像データストリーム３５７を生成するために生成される中間画像データストリーム３５６などがあり、それぞれ画像処理装置が備える機能により形式が規定されている。前述と同様の構成により、それぞれのデータストリームに対して最適なフィルタ処理を行うことができる。

印刷データストリーム中の制御データでなく、印刷対象の文字データ列中から特定の文字列パターンの出現を発見し、特定の文字列パターンに合致した場合に、その文字列に相当する制御データを生成して置換または挿入するような機能拡張フィルタを構成することもできる。この場合は例えば、顧客がワードプロセッサのようなアプリケーションを使用してテキストとして特定文字列を入力し、それを画像処理装置の通常のドライバ経由でプリントする際、画像処理装置側のフィルタにおいて、例えば特定文字列を、それに対応する画像（ロゴやマークや透かしなど）を描画するためのベクタ描画命令などの命令列に変換してもよい。

上記実施の形態では、ファームウェア内部のインタプリタ環境としてＪａｖａ（登録商標）の仮想マシン環境を用いたが、本発明はこれに限定されるものではない。他のスクリプト言語などのインタプリタ環境をファームウェアに組み込んで構成した場合であっても、動的なフィルタ追加とファームウェア部分の分離など同様の効果が得られる。

また、オブジェクト指向など高効率の開発を可能とするインタプリタ環境は他にも多く存在し、これらを用いてもフィルタ生産性など同様の効果が得られる。特にパターンマッチングに基づくデータストリームの処理に関しては、ｓｅｄ，ＡＷＫ，Ｐｅｒｌなどの選択肢も適している。

［他の実施形態］
以上、本発明の実施の形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、または一つの機器からなる装置に適用しても良い。

なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

本実施の形態に係る画像処理装置のハードウェア構成を説明するブロック図である。 本実施の形態に係るコントローラのソフトウェア構造を説明する階層図である。 本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、各モジュールにおいて存在するデータストリームを示す図である。 本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。 本実施の形態のインタプリタ環境に構築されるフィルタフレームワークのクラスを説明する図である。 本実施の形態のインタプリタ環境に構築されるフィルタフレームワーク２１９が管理するオブジェクトのインスタンス図で、図６（Ａ）は、１つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示し、図６（Ｂ）は、２つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。 本実施の形態に係るフィルタフレームワークを操作するためのユーザインターフェース例を説明する図である。 本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。 本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。 本実施の形態に係る処理要求データストリームを説明する図である。 本実施の形態に係る描画データストリームに対するフィルタが行う処理を説明する図である。 本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。 本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。 本実施の形態１に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。 機能拡張フィルタを操作するためのユーザインターフェース例を示す図である。 本発明の実施の形態２に係る送信用データストリームを説明する図である。

Claims (30)

1. ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置であって、
   前記ネイティブ環境で、前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信手段と、
   前記ネイティブ環境で、前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成するデータ処理手段と、
   前記インタプリタ環境で、前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
   前記ネイティブ環境で、前記フィルタ手段との間で前記中間データストリームの前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース手段と、
   前記ネイティブ環境で、前記インターフェース手段を介して取り出した前記中間データストリームの前記装置制御指示データストリームと描画データストリームとをそれぞれ、対応する前記インタプリタ環境のフィルタ手段へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
   を有することを特徴とする画像処理装置。
2. 前記フィルタ手段により処理された中間データストリームを情報処理装置に送信する送信手段を更に有することを特徴とする請求項１に記載の画像処理装置。
3. 前記クライアントは、ネットワークを介して接続された情報処理装置或は前記画像処理装置に内蔵されていることを特徴とする請求項１又は２に記載の画像処理装置。
4. 前記フィルタ手段が有効な状態で配置されている場合、前記インターフェース手段を介して前記中間データストリームを前記フィルタ手段へ引き渡し、前記フィルタ手段が有効な状態で配置されていない場合、前記中間データストリームを次のモジュールへ引き渡す制御手段を更に有することを特徴とする請求項１に記載の画像処理装置。
5. 前記フィルタ手段によるフィルタ処理は、前記中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項１乃至４のいずれか１項に記載の画像処理装置。
6. 前記フィルタ手段によるフィルタ処理は、前記中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項１乃至４のいずれか１項に記載の画像処理装置。
7. 前記インタプリタ環境のユーザインターフェースを用いて、前記フィルタ手段における処理パラメータを操作する手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載の画像処理装置。
8. 前記インタプリタ環境は、当該インタプリタ環境上で動作するプログラムのためのスレッド機構を提供し、前記フィルタ手段は前記スレッド機構による独立した実行コンテクストの下で自律的にフィルタ処理を実行することを特徴とする請求項１乃至７のいずれか１項に記載の画像処理装置。
9. 前記インタプリタ環境は、Ｊａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１乃至８のいずれか１項に記載の画像処理装置。
10. 画像処理装置であって、
    前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信手段と、
    前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成し前記入力データストリームにより指示された内容に従った処理を行うデータ処理手段と、
    前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
    前記フィルタ手段との間で前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース手段と、
    前記フィルタ手段によるフィルタ機能を選択する第１選択手段と、
    前記フィルタ手段によるフィルタ処理の対象となる前記装置制御指示データストリームと描画データストリームを選択する第２選択手段と、
    前記第２選択手段により選択された前記装置制御指示データストリーム或いは描画データストリームを前記インターフェース手段を介して取り出し、前記第１選択手段により選択された対応する前記フィルタ手段へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
    を有することを特徴とする画像処理装置。
11. 前記フィルタ手段により処理された中間データストリームを情報処理装置に送信する送信手段を更に有することを特徴とする請求項１０に記載の画像処理装置。
12. 前記クライアントは、ネットワークを介して接続された情報処理装置或は前記画像処理装置に含まれていることを特徴とする請求項１０又は１１に記載の画像処理装置。
13. 前記フィルタ手段によるフィルタ処理は、前記中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項１０乃至１２のいずれか１項に記載の画像処理装置。
14. 前記フィルタ手段によるフィルタ処理は、前記中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項１０乃至１２のいずれか１項に記載の画像処理装置。
15. ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置の制御方法であって、
    前記ネイティブ環境で、前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信工程と、
    前記ネイティブ環境で、前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成するデータ処理工程と、
    前記インタプリタ環境で、前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
    前記ネイティブ環境で、前記フィルタ工程との間で前記中間データストリームの前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース工程と、
    前記ネイティブ環境で、前記インターフェース工程を介して取り出した前記中間データストリームの前記装置制御指示データストリームと描画データストリームとをそれぞれ、対応する前記インタプリタ環境のフィルタ工程へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース工程を介して書き戻すフィルタ管理工程と、
    を有することを特徴とする画像処理装置の制御方法。
16. 前記フィルタ工程で処理された中間データストリームを情報処理装置に送信する送信工程を更に有することを特徴とする請求項１５に記載の制御方法。
17. 前記クライアントは、ネットワークを介して接続された情報処理装置或は前記画像処理装置に含まれていることを特徴とする請求項１５又は１６に記載の制御方法。
18. 前記フィルタ工程が有効な状態で配置されている場合、前記インターフェース工程を介して前記中間データストリームを前記フィルタ工程へ引き渡し、前記フィルタ工程が有効な状態で配置されていない場合、前記中間データストリームを次のモジュールへ引き渡す制御工程を更に有することを特徴とする請求項１５に記載の制御方法。
19. 前記フィルタ工程におけるフィルタ処理は、前記中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項１５乃至１８のいずれか１項に記載の制御方法。
20. 前記フィルタ工程におけるフィルタ処理は、前記中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項１５乃至１８のいずれか１項に記載の制御方法。
21. 前記インタプリタ環境のユーザインターフェースを用いて、前記フィルタ工程における処理パラメータを操作する工程を更に有することを特徴とする請求項１５乃至２０のいずれか１項に記載の制御方法。
22. 前記インタプリタ環境は、当該インタプリタ環境上で動作するプログラムのためのスレッド機構を提供し、前記フィルタ工程では前記スレッド機構による独立した実行コンテクストの下で自律的にフィルタ処理を実行することを特徴とする請求項１５乃至２１のいずれか１項に記載の制御方法。
23. 前記インタプリタ環境は、Ｊａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１５乃至２２のいずれか１項に記載の制御方法。
24. 画像処理装置の制御方法であって、
    前記画像処理装置に対する制御指示を行う装置制御指示データストリームと前記画像処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信工程と、
    前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成し前記入力データストリームにより指示された内容に従った処理を行うデータ処理工程と、
    前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
    前記フィルタ工程との間で前記装置制御指示データストリームと描画データストリームとをそれぞれの取り出し、及び書き戻しを行うインターフェース工程と、
    前記フィルタ工程によるフィルタ機能を選択する第１選択工程と、
    前記フィルタ工程によるフィルタ処理の対象となる前記装置制御指示データストリームと描画データストリームを選択する第２選択工程と、
    前記第２選択工程で選択された前記装置制御指示データストリーム或いは描画データストリームを前記インターフェース工程を介して取り出し、前記第１選択工程で選択された対応する前記フィルタ工程へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース工程を介して書き戻すフィルタ管理工程と、
    を有することを特徴とする画像処理装置の制御方法。
25. 前記フィルタ工程で処理された中間データストリームを情報処理装置に送信する送信工程を更に有することを特徴とする請求項２４に記載の制御方法。
26. 前記クライアントは、ネットワークを介して接続された情報処理方法或は前記画像処理装置に含まれていることを特徴とする請求項２４又は２５に記載の制御方法。
27. 前記フィルタ工程でのフィルタ処理は、前記中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項２４乃至２６のいずれか１項に記載の制御方法。
28. 前記フィルタ工程でのフィルタ処理は、前記中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項２４乃至２７のいずれか１項に記載の制御方法。
29. ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築された第１プログラム環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行する第２プログラム環境を備えるデータ処理装置であって、
    前記第１プログラム環境で、前記データ処理装置に対する制御指示を行う装置制御指示データストリームと前記データ処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信手段と、
    前記第１プログラム環境で、前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成するデータ処理手段と、
    前記第２プログラム環境で、前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
    前記第１プログラム環境で、前記フィルタ手段との間で前記中間データストリームの前記装置制御指示データストリームと描画データストリームとのそれぞれの取り出し、及び書き戻しを行うインターフェース手段と、
    前記第１プログラム環境で、前記インターフェース手段を介して取り出した前記中間データストリームの前記装置制御指示データストリームと描画データストリームとをそれぞれ、対応する前記第２プログラム環境のフィルタ手段へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
    を有することを特徴とするデータ処理装置。
30. データ処理装置であって、
    前記データ処理装置に対する制御指示を行う装置制御指示データストリームと前記データ処理装置へ描画指示を行う描画データストリームとを含む入力データストリームを受信するデータストリーム受信手段と、
    前記入力データストリームを前記装置制御指示データストリームと描画データストリームとに分割して中間データストリームを生成し前記入力データストリームにより指示された内容に従った処理を行うデータ処理手段と、
    前記中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
    前記フィルタ手段との間で前記装置制御指示データストリームと描画データストリームとをそれぞれの取り出し、及び書き戻しを行うインターフェース手段と、
    前記フィルタ手段によるフィルタ機能を選択する第１選択手段と、
    前記フィルタ手段によるフィルタ処理の対象となる前記装置制御指示データストリームと描画データストリームを選択する第２選択手段と、
    前記第２選択手段により選択された前記装置制御指示データストリーム或いは描画データストリームを前記インターフェース手段を介して取り出し、前記第１選択手段により選択された対応する前記フィルタ手段へ引き渡し、前記フィルタ処理済の各データストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
    を有することを特徴とするデータ処理装置。

Images