JP4164467B2

JP4164467B2 - 画像処理装置、画像処理制御方法、及びプログラム

Info

Publication number: JP4164467B2
Application number: JP2004093215A
Authority: JP
Inventors: 雅仁山本
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-03-26
Filing date: 2004-03-26
Publication date: 2008-10-15
Anticipated expiration: 2024-03-26
Also published as: EP1735687A1; US8373874B2; KR100852795B1; KR20070011399A; CN100533365C; WO2005093560A1; CN1934531A; KR20080011469A; JP2005284384A; KR100815728B1; EP1735687A4; US20090180133A1

Description

本発明は、画像処理装置、画像処理制御方法、及びプログラムに関し、特に、プリンタ等の機能を有する画像処理装置、該画像処理装置に適用される画像処理制御方法、及び該画像処理制御方法をコンピュータに実行させるためのプログラムに関する。

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

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

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

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

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

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

ところで、ページ記述言語（ＰＤＬ）プリンタにおいて、カスタマイズや微細な修正などの個別対応が求められる事例がある。すなわち、顧客のプリンティング環境およびそれぞれの環境における要求は多種多様である。たとえば基幹系の業務システムでは、顧客環境のそれぞれにおいて独自に開発された業務アプリケーションが直接にプリントデータを生成するように作られている場合がある。また、業務アプリケーションがプリンタドライバを介してプリントデータを生成する場合であっても、ひとたび正常に稼働しはじめたシステム全体の安定性を維持したいという要望が非常に強く、プリンタドライバを簡単に変更することは許されないことがある。また、プリンタには他社の開発したＰＤＬを解釈してプリントする機能を備えるものがあるが、顧客のシステムによっては、そのプリンタ専用に開発されたプリンタドライバではなく、またＰＤＬ開発元が開発したものでもない第三者の開発したプリンタドライバを経由してプリントを行うようにシステムが構築されており、そしてそのドライバの変更が許されない場合もある。すなわち、現実の顧客環境は多種多様であり、個別対応が求められる。

このような現実のプリンティング環境の制約の中で、プリンタのベンダは、顧客環境の側に対応を求めるのではなく、プリンタ側の対応によって各種の顧客要望に応えるべき使命がある。たとえば、プリンタの新製品が提供する新しい機能として両面印刷や製本などのフィニッシング機能があった場合、同時に開発された専用のプリンタドライバ経由でプリントジョブを投入したり、顧客の業務アプリケーションが新規追加されたコマンド列を含むＰＤＬデータを生成するように更新されたりすれば、これらの新機能を使いこなせることは当然である。しかしながら、顧客システムに影響をおよぼさず、プリンタ側の対応によって装置の新機能を利用可能とすることが求められる。

あるいは、あるＰＤＬ仕様に対応したプリンタを複数のベンダが供給している場合、個々のベンダの解釈の差異などに基づく互換性の問題は常に存在しうる。この種の問題は問題が顕在化し現実に業務の支障となる顧客環境に対しては、仮に個別対応であってもプリンタ側が対応して回避しなければならない。

また、ごく稀にプリンタファームウェアの実装上の問題によって、特定のパターンのＰＤＬデータに対して顕在化するバグを含んだまま製品が出荷されてしまう場合もある。十分な品質評価を経て製品化される以上、このような特定のパターンは多くの顧客環境の通常の利用においては現れることがなく、まったく問題とならないが、それでも例えば上記業務システムなどにおいて顕在化する場合があり得、そしてそのようなケースに対しては特にその顧客環境においては可能な限りすみやかに対策されなければならない。

さらにまた、特定のアプリケーションが生成するＰＤＬデータには、プリンタの実装の特性上、最適化できる余地のあるデータパターンが含まれる場合がありえる。たとえば冗長な記述が行われたＰＤＬデータと最適な記述が行われたＰＤＬデータとを比較した場合、そのプリントパフォーマンスの改善は著しいため、このような特定のアプリケーションを利用する顧客環境において、もしアプリケーションやプリンタドライバを更新できないのであれば、プリンタ側の対応によってＰＤＬデータの最適化を行えることが望ましい。

これらの要望に、顧客システム側に影響を与えずプリンタ側で対応するためには、プリンタを構成するファームウェアを改造して個別対応リリースする方法があり、実際にこの方法がとられている場合もある。しかし、ファームウェアの改造による個別対応は、装置全体の品質の再評価を含め開発期間や開発費などが多くかかり、また顧客環境に納品した装置に組み込まれたファームウェアの更新には、フィールドエンジニアなどによる高度なメンテナンスの手間を要するため、顧客要望に速やかに応えるためにも、また費用対効果の面でも課題を残している。実際には、これらの要望のうちの一部に対しては、プリンタのファームウェア全体を変更するまでもなく、受信したＰＤＬデータストリームを解釈する前の前処理を追加して、そこでＰＤＬデータストリームそのものに変換を施すことによって対応できる。したがって、受信したＰＤＬデータストリームを解釈する前の前処理を実現するソフトウェアだけを、他のファームウェアとは独立に柔軟かつ拡張可能に追加できる、より動的な機構が求められる。

しかしながら、従来の技術によって上記要請に応えようとしても、下記のような問題があった。

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

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

本発明はこのような問題点に鑑みてなされたものであって、ＰＤＬプリンタのカスタマイズの生産性を向上することを図った画像処理装置、画像処理制御方法、及びプログラムを提供することを目的とする。

上記目的を達成するために、請求項１記載の発明によれば、クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリーム中の特定のデータを置換するフィルタ処理を行い、前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段と、前記受信手段が受信した印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、前記フィルタ手段によってフィルタ処理された印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段と、を備え、前記フィルタ手段はフィルタ処理を実行するためのフィルタプログラムをユーザによる操作に基づいて外部からインストールしたりアンインストールすることで、フィルタ処理の内容を変更することが可能であることを特徴とする画像処理装置が提供される。

また、請求項８記載の発明によれば、クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリームをフィルタ処理して前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段と、前記受信手段によって受信された印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、１つ以上のフィルタ手段を印刷要求データストリームのデータパス中に配置可能に制御し、配置された１つ以上のフィルタ手段に逐次的に印刷要求データストリームを処理させるフィルタ管理手段と、前記フィルタ管理手段によって配置された１つ以上のフィルタ手段によってフィルタ処理された印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段と、を有することを特徴とする画像処理装置が提供される。

また、請求項１２記載の発明によれば、クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリーム中の特定のデータを置換するフィルタ処理を行い、前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備え、前記フィルタ手段はフィルタ処理を実行するためのフィルタプログラムをユーザによる操作に基づいて外部からインストールしたりアンインストールすることで、フィルタ処理の内容を変更することが可能である画像処理装置に適用される画像処理制御方法において、前記受信手段が受信した印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップとを有することを特徴とする画像処理制御方法が提供される。

また、請求項１４記載の発明によれば、クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリームをフィルタ処理して前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備えた画像処理装置に適用される画像処理制御方法において、前記受信手段によって受信された印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップと、１つ以上のフィルタ手段を印刷要求データストリームのデータパス中に配置可能に制御し、配置されたフィルタ手段に逐次的に印刷要求データストリームを処理させるフィルタ管理ステップとを有することを特徴とする画像処理制御方法が提供される。

さらに、上記画像処理制御方法をコンピュータに実行させるためのプログラムが提供される。

本発明によれば、プリンタが受信したＰＤＬデータストリームに対する解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離することによって、ＰＤＬプリンタのカスタマイズの生産性を向上できる。

以下、本発明を実施するための最良の形態について、図面を参照して説明する。

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

図中、プリンタ１０００は、内部に、異なる制御系のプリンタコントローラ１６００を含む。

プリンタコントローラ１６００におけるネットワークプリントサーバ用ＣＰＵ１は、書き換え可能なＦｌａｓｈＲＯＭ３に記憶された制御プログラムに基づいて、複数の外部装置から送られる印刷データやプリンタ制御命令等の各種データ送受信要求を統括的に制御する。複数の外部装置は、ローカルエリアネットワーク（ＬＡＮ）２０００に接続されたホストコンピュータ等（不図示）であり、ＬＡＮ２０００は、システムバス４に接続されるネットワークコントローラ（ＬＡＮＣ）５によって通信制御される。上記の各種データ送受信要求は、外部装置から所定のネットワーク通信プロトコルを用いて送信される。

またＣＰＵ１は、ＲＯＭ９に記憶された制御プログラム等、またはディスクコントローラ（ＤＫＣ）１５を介して接続された外部メモリ１０に記憶された制御プログラムやリソースデータ（資源情報）等に基づいて、システムバス４に接続される各種デバイスとのアクセスを統括的に制御し、また受信された印刷データに基づき、ラスタコントローラ１２によって出力画像情報を生成し、マーキングエンジン１６に対して画像信号を出力する。

ＲＡＭ２は、ＣＰＵ１の主メモリ、ワークエリア等の一時記憶領域として用いられる。

ＬＥＤ６は、プリンタコントローラ１６００の動作状態を示す表示部として機能し、例えばネットワークコントローラ（ＬＡＮＣ）５とローカルエリアネットワーク（ＬＡＮ）２０００との電気的な接続状態（ＬＩＮＫ）や、ネットワーク通信モード（１０Ｂａｓｅか１００Ｂａｓｅ、全二重か半二重）等の各種動作状態を、点滅パターンや点灯色によって示す。

操作パネル（操作部）１８は、プリンタ１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンや液晶パネルに重ねあわされたタッチパネルから構成されるとともに、プリンタ１０００の動作状態を示す液晶パネルやＬＥＤ等の表示部から構成される。

なお、マーキングエンジン１６は既知の印刷技術を利用して印刷を実行するためのものであり、例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華（熱転写）方式等により、転写紙への画像形成を行う。

図２は、図１に示す画像処理装置を動作させるためのソフトウェア（モジュール）の構成を示す階層図である。

図２において上位の階層に位置するモジュールは、下位の階層に位置するモジュールに依存していることを示す。また特に線によって接続したモジュール間には、強い依存関係が存在することを示す。

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

２０２はプリントアプリケーションである。プリントアプリケーション２０２は、画像処理装置にプリンタとしての中心機能を提供するための組み込みアプリケーションであり、クライアントからの要求に呼応してプリントサービスを提供する。プリントアプリケーション２０２は制御ＡＰＩ２０４によって、クライアントから要求されたプリントジョブの実行を行う。

２０３は印刷要求受信モジュールであり、クライアントから投入されるプリントジョブを受信する。印刷要求受信モジュール２０３は、ＲＴＯＳ２０９を介してプロトコルスタック２１０に依存している。クライアントからの印刷要求は、物理的にはＥｔｈｅｒｎｅｔ（登録商標）などのネットワークやＵＳＢ、ＩＥＥＥ１３９４などの各種インタフェースを介してクライアントからプリンタに送信されるが、それぞれの接続形態に応じてプリント要求を行うためのアプリケーションプロトコルが規定されている。印刷要求受信モジュール２０３は、このプリントのためのアプリケーションプロトコルのサーバ機能を実装している。プリントサービスのためのアプリケーションプロトコルには、たとえばネットワークプロトコルだけでもＬＰＲやＳＭＢ、ＰＡＰ、ＮｅｔＷａｒｅなど各種の仕様が存在し、その実現のためには膨大な開発コストと品質評価コストを要する。印刷要求受信モジュール２０３は、これら複数のインタフェースごとにそれぞれ各種存在するプリントサービスプロトコルからなるマルチプロトコルをサポートしている。

印刷要求受信モジュール２０３は、画像処理装置の記憶装置にプリントジョブの待ち行列を構成し、いわゆるスプール機能を実装するように構成してもよい。この場合、印刷要求受信モジュール２０３は、他のジョブを実行している最中のようにジョブをただちに実行できないときにも、クライアントからのプリントジョブ要求を受け付けて待ち行列に格納しクライアントを解放する。待ち行列に格納されたプリントジョブは、プリントジョブが実行可能となった時にスケジューリングアルゴリズムに応じて逐次処理される。

２０４は制御ＡＰＩであり、画像処理装置が提供する装置サービスにアクセスするためのアプリケーションプログラミングインタフェースである。制御ＡＰＩ２０４を構成する主要なインタフェースのひとつは、プリントジョブを実行したり制御したりするためのインタフェースである。

２０５はジョブ制御モジュールである。ジョブ制御モジュール２０５は、画像処理装置が提供する各種の画像処理ジョブを制御する。主要な画像処理ジョブはプリントジョブである。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介して実行を要求されたプリントジョブのデータストリームを解釈して、プリントジョブの記述と、プリントされるべき印刷データの記述とを分離する。プリントジョブ記述は、印刷データの解釈展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、印刷データはＰＤＬによって記述されており、主にページごとの描画が記述されている。ジョブ制御モジュール２０５は、プリントジョブ記述に応じてトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８を制御する。またジョブ制御モジュール２０５は、印刷データストリームがトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の順に流れ処理されるようにスケジュールする。

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

２０７はレンダラである。レンダラ２０７はディスプレイリストをラスタ画像に展開する。レンダラ２０７はＲＴＯＳ２０９を介してレンダラドライバ２１２に依存している。

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

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

２１０はプロトコルスタックである。プロトコルスタック２１０は、ＲＴＯＳ２０９のフレームワークに組み込まれ、より下層の外部インタフェースドライバ２１１が制御する外部インタフェース上にトランスポート層以下のプロトコルを実装する。たとえばネットワークインタフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現し、組み込みアプリケーション層に対してはＲＴＯＳ２０９を介してバークレイソケットなどのアプリケーションプログラミングのためのインタフェースを提供する。またたとえば外部インタフェースがＵＳＢの場合にはＩＥＥＥ規格１２８４．４などのプロトコルを実現する。

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

２１２はレンダラドライバであり、レンダラ２０７を駆動する。レンダラ２０７はディスプレイリストをラスタ画像に展開するためのハードウェアである。レンダラ２０７はソフトウェアによって実現してもよい。

２１３はマーキングエンジン（ＭＥ）ドライバであり、転写紙への画像形成を行うマーキングエンジン１６を駆動する。

２１４は操作パネルドライバである。画像処理装置が備える操作パネル１８の表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。

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

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

２１７は標準のＡＰＩライブラリとフレームワーク群であり、ＲＴＯＳ２０９が提供する抽象化された各種コンピューティング資源を、さらにインタプリタ環境２１５固有のモデルによって抽象化して、この上で動作するプログラムのための実行環境を提供する。ここではＪａｖａ（登録商標）プラットフォームを構成する標準的なクラスライブラリ群と、ＯＳＧｉのフレームワークとによって実現している。

このＪａｖａ（登録商標）プラットフォームは、ＲＴＯＳ２０９相当の抽象化された機能を提供し、たとえば仮想マシンによる命令実行コンテクストを抽象化したスレッド管理、複数の実行コンテクストを仮想的に同時動作させ並行処理を実現するマルチスレッド機構、スレッド間でメッセージのやり取りをしたり同期をとったりするためのスレッド間通信、高度に抽象化された各種のメモリ管理（コレクションなど）、タイマーやクロック、例外管理、ファイルシステムやネットワークのアクセス、外部入出力装置とのインタフェースなどがある。

またＯＳＧｉフレームワークは、単一のＪａｖａ（登録商標）仮想マシン上に複数のＪａｖａ（登録商標）アプリケーション（サービス）を動作させる。またアプリケーションのライフサイクルの管理やアプリケーション間通信機能などを提供する。ＯＳＧｉフレームワーク上には、複数のシステムサービスがプリインストールされている。システムサービスには、インタプリタ環境に新たなアプリケーションを追加したり更新したり削除したりするためのサービス管理サービスや、Ａｐｐｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）クラスを画像処理装置の操作パネル１８に表示して操作パネル１８から操作可能に動作させるためのＡｐｐｌｅｔビューアサービスや、Ｓｅｒｖｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）クラスをクライアントのブラウザから操作可能なＷｅｂアプリケーションとして動作させるためのＨＴＴＰサービスなどが用意されている。特にＡｐｐｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）アプリケーションは、ＡＷＴのＡＰＩなどを経由して間接的に操作パネルドライバ２１４とインタフェースすることができる。

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

２１９はフィルタフレームワークである。フィルタフレームワーク２１９は、プリントアプリケーション２０２と通信して、プリントジョブ要求の実行に際してインタプリタ環境２１５上に実装したフィルタプログラムからのプリントデータストリームに対する介在を可能とする。

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

２２１はフィルタである。フィルタ２２１は、インタプリタ環境２１５上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているため、プリントアプリケーション２０２が処理するプリントデータストリームに対する処理を実行することができる。

図３は、図２に示す画像処理装置におけるソフトウェアモジュール間のデータの流れを示す図である。

印刷要求受信モジュール２０３がクライアントから受信したプリントジョブデータストリームに対してフィルタ処理を施さない場合には、印刷要求受信モジュール２０３からプリントジョブデータストリーム３０１がジョブ制御モジュール２０５に流れる。プリントジョブデータストリーム３０１は、たとえばＲＴＯＳ２０９が提供するメッセージキューなどのタスク間通信機能によって引き渡される。

ジョブ制御モジュール２０５はプリントジョブデータストリーム３０１を逐次的に解釈し、プリントジョブデータストリーム３０１中のジョブ記述の解釈を行い、それに応じて制御パス３０２を介してトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の制御を行う。

一方、プリントジョブデータストリーム３０１中の印刷データは、一般にＰＤＬによって記述されたページ記述のコマンドシーケンス３０３であり、これはトランスレータ２０６に流れる。トランスレータ２０６は印刷データの解釈を行い、ディスプレイリスト３０４の生成を行う。生成されたディスプレイリスト３０４はレンダラ２０７に流れる。レンダラ２０７はディスプレイリスト３０４の展開を行い、ラスタ画像データ３０５の生成を行う。ラスタ画像データ３０５はページ単位に生成される場合もあれば、ページを副走査方向に複数の領域に区切ったバンド単位に生成される場合もある。生成されたラスタ画像データ３０５はＭＥ制御モジュール２０８に流れる。ＭＥ制御モジュール２０８はラスタ画像データ３０５をマーキングエンジン１６に転送し、マーキングエンジン１６において転写紙への画像形成が行われる。

以上の処理は、すべてネイティブコード部分２０１に実装されているソフトウェアによって実現される。

一方、プリントジョブデータストリームに対してフィルタ処理を施す場合には、印刷要求受信モジュール２０３がクライアントから受信したプリントジョブデータストリーム３０６はフィルタフレームワーク２１９に流れる。プリントジョブデータストリーム３０６は、たとえばＲＴＯＳ２０９が提供するメッセージキューなどのタスク間通信機能によって引き渡される。

フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境２１５上に実装されたフィルタプログラム群を管理している。フィルタフレームワーク２１５は、受け取ったプリントジョブデータストリーム３０６をプリントジョブデータストリーム３０７としてフィルタ２２１に流す。プリントジョブデータストリーム３０７は、たとえばインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。なお複数のフィルタが配置されている場合には、それぞれのフィルタ間にもプリントジョブデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。

フィルタ２２１は、受け取ったプリントジョブデータストリーム３０７に対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリーム３０８はフィルタフレームワーク２１９に流れる。データストリーム３０８は、たとえばインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。

フィルタフレームワーク２１９は、フィルタ２１１から受け取ったデータストリーム３０８をデータストリーム３０９としてジョブ制御モジュール２０５に流す。データストリーム３０９は、たとえばＲＴＯＳ２０９が提供するメッセージキューなどのタスク間通信機能によって引き渡される。以下はフィルタ２２１を介さない場合と同様にデータが流れる。

３１０はフィルタフレームワーク２１９から印刷要求受信モジュール２０３への制御パスであり、印刷要求受信モジュール２０３からジョブ制御モジュール２０５へのプリントジョブデータストリーム３０１の引き渡しを、フィルタフレームワーク２１９から制御するための制御パスである。すなわち、フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合には、プリントジョブデータストリーム３０６が有効となり、プリントジョブデータストリーム３０６に対してフィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されていない場合には、プリントジョブデータストリーム３０１が有効となり、クライアントから受信したプリントジョブデータストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク２１９介在のオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズをまったく行わない標準状態のプリンタのデータ処理性能を発揮できる。

図４は、インタプリタ環境２１５上に構築されるフィルタフレームワーク２１９のクラスを示す図である。

ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１は、フィルタフレームワーク２１９のランタイム環境を実現するオブジェクトのクラスである。ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１は、ひとつのＣｏｎｎｅｃｔｏｒクラス４０５のオブジェクトをコンポジション（composition）として持つ。また、複数（ｎ個）のＦｉｌｔｅｒ抽象クラス４０２のオブジェクトへの参照と、複数（ｎ−１個）のＰｉｐｅクラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワーク２１９のランタイムにインストールされた複数のＦｉｌｔｅｒ抽象クラス４０２の具体クラスを管理するためのｉｎｓｔａｌｌｅｄＦｉｌｔｅｒ属性を備える。

Ｆｉｌｔｅｒ抽象クラス４０２は、各種のフィルタクラスを抽象化する抽象クラスである。Ｆｉｌｔｅｒ抽象クラス４０２は、フィルタ名称を示すｎａｍｅ属性などを備える。また、ｉｎｐｕｔ属性としてＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したクラスのオブジェクトへの参照を持ち、ｏｕｔｐｕｔ属性としてＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したクラスのオブジェクトへの参照を持つ。Ｆｉｌｔｅｒ抽象クラス４０２の具体クラスは、Ｒｕｎｎａｂｌｅインタフェースを実装し、ｒｕｎメソッドを持つ。ＦｉｌｔｅｒＭａｎａｇｅｒオブジェクトが、管理している各種のフィルタクラスのインスタンスを生成してデータストリームのフィルタ処理のために配置されるとき、配置されるそれぞれのフィルタオブジェクトに対応してスレッドを生成し、並行動作するスレッドの実行コンテクストでフィルタオブジェクトのｒｕｎメソッドを実行する。すなわち、コンストラクタのパラメータにフィルタオブジェクトを渡してｊａｖａ．ｌａｎｇ．Ｔｈｒｅａｄオブジェクトを生成し、スタートする。このようにして個々のフィルタオブジェクトは自律的に動作する。

ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３は、データストリームの入力元の抽象クラスである。ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３は、呼び出しのたびに逐次的にデータを読み出すことのできるｒｅａｄメソッドを備える。

ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４は、データストリームの出力先の抽象クラスである。ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４は、呼び出しのたびに逐次的にデータを書き込むことのできるｗｒｉｔｅメソッドを備える。

Ｃｏｎｎｅｃｔｏｒクラス４０５は、インタプリタ環境２１５のオブジェクトとネイティブコードとの間でデータストリームの交換を行うための接点を表現したオブジェクトのクラスである。Ｃｏｎｎｅｃｔｏｒクラス４０５は、ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承した具体クラスであるＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍクラスのオブジェクトをコンポジションとして持ち、そのｒｅａｄメソッドによってネイティブコードの印刷要求受信モジュール２０３から流れたデータストリーム３０６を逐次的に読み出すことができる。また、Ｃｏｎｎｅｃｔｏｒクラス４０５は、ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍクラスのオブジェクトもコンポジションとして持ち、そのｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームは、ネイティブコードのジョブ制御モジュール２０５へデータストリーム３０９として流れる。

Ｐｉｐｅクラス４０６は、データストリームに対して複数のフィルタリング処理を施す際にＦｉｌｔｅｒ抽象クラス４０２の一連のオブジェクト間を連結するために用いるオブジェクトのクラスである。Ｐｉｐｅクラス４０６は、ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍクラスとＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍクラスのそれぞれのオブジェクトをコンポジションとして持つ。ＰｉｐｅオブジェクトのＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトとは接続されており、スレッド間通信を実現する。すなわちあるＰｉｐｅオブジェクトに関して、あるＦｉｌｔｅｒオブジェクトが、そのＰｉｐｅオブジェクトが持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームは、別のＦｉｌｔｅｒオブジェクトが、そのＰｉｐｅオブジェクトが持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄメソッドによって逐次的に読み出すことができる。

図５は、インタプリタ環境２１５上に構築されるフィルタフレームワーク２１９が管理するオブジェクトのインスタンスを示す図である。

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

Ｃｏｎｎｅｃｔｏｒオブジェクト５０１は、Ｃｏｎｎｅｃｔｏｒクラス４０５のオブジェクトである。

フィルタオブジェクト５０２は、Ｆｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタオブジェクト５０２のｉｎｐｕｔ属性には、Ｃｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｅａｍオブジェクトの参照が保持されており、ｏｕｔｐｕｔ属性にも、Ｃｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの属性が保持されている。Ｆｉｌｔｅｒオブジェクト５０２は、信号ｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトから読み取ったデータストリームに対してフィルタ処理を施す。また、フィルタ処理を施したデータストリームを、信号ｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへと書き込む。

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

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

フィルタ１オブジェクト５０３は、Ｆｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ１オブジェクト５０３のｉｎｐｕｔ属性には、Ｃｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。フィルタ１オブジェクト５０３は、信号ｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトから読み取ったデータストリームに対してフィルタ処理を施す。また、フィルタ１オブジェクト５０３のｏｕｔｐｕｔ属性には、Ｐｉｐｅオブジェクト５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。フィルタ１オブジェクト５０３は、フィルタ処理を施したデータストリームを信号ｏｕｔｐｕｔの指すＰｉｐｅｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへと書き込む。

Ｐｉｐｅオブジェクト５０４は、Ｐｉｐｅクラス４０６のオブジェクトである。Ｐｉｐｅオブジェクト５０４は、ＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトとを接続された状態で持つ。Ｐｉｐｅオブジェク５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドの呼び出しによって引き渡されたデータストリームは、Ｐｉｐｅオブジェクト５０４が持つＰｉｐｅＩｎｐｕｔＳｔｒｅａｍオブジェクトのｒｅａｄメソッドの呼び出しによってデータストリームとして読み出すことができる。

フィルタ２オブジェクト５０５は、Ｆｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ２オブジェクト５０５のｉｎｐｕｔ属性には、Ｐｉｐｅオブジェクト５０４が持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍの参照が保持されている。フィルタ２オブジェクト５０５は、信号ｉｎｐｕｔの指すＰｉｐｅオブジェクト５０４から読み出したデータストリームに対してフィルタ処理を施す。フィルタ２オブジェクト５０５のｏｕｔｐｕｔ属性には、Ｃｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍの参照が保持されている。フィルタ２オブジェクト５０５は、フィルタ処理を施したデータストリームを信号ｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍへと書き込む。

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

図６は、フィルタフレームワーク２１９を操作するためのユーザインタフェースの一例を示す図である。

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

図６（Ａ）は、画像処理装置のフィルタフレームワーク２１９に新しいフィルタを追加インストールするためのユーザインタフェースを示す図である。

６０１はフィルタインストール画面の例である。

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

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

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

本ユーザインタフェースをＷｅｂアプリケーションとして実装している場合、フィルタの実装クラスを画像処理装置にアップロードする機構は、ＲＦＣ（Requests for Comments）によって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用して実装している。したがって、この場合、ファイル名入力フィールド６０２と参照ボタン６０３とは、クライアントコンピュータのＷｅｂブラウザによって表示されており、インストールボタン６０４は、フォームのｓｕｂｍｉｔに対応している。

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

図６（Ｂ）は、画像処理装置のフィルタフレームワーク２１９にインストールされているフィルタを配置するためのユーザインタフェースを示す図である。

６０５はフィルタ配置画面の例である。

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

６０７から６１１は、選択されたフィルタに対する操作を指示するためのボタンであり、表６０６の選択列のチェックボックスがチェックされた行のフィルタを対象とする操作を指示する。

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

６０８は上へボタンである。ユーザがこの上へボタン６０８をクリックすると、選択されたフィルタのフィルタ列内における順序を、データストリーム処理の上流方向に一段階変更する。

６０９は下へボタンである。ユーザがこの下へボタン６０９をクリックすると、選択されたフィルタのフィルタ列内における順序を、データストリーム処理の下流方向に一段階変更する。

６１０は有効／無効のトグルボタンである。ユーザがこのトグルボタン６１０をクリックすると、選択されたフィルタが有効状態にある場合は無効状態に変更し、無効状態にある場合には有効状態に変更する。無効状態にされたフィルタオブジェクトは削除されるが、フィルタクラスはインストールされた状態で残り、フィルタフレームワーク２１９のランタイムの管理下に留まる。

６１１はアンインストールボタンである。ユーザがこのアンインストールボタン６１１をクリックすると、選択されたフィルタのクラスファイルを画像処理装置のインタプリタ環境２１５から削除する。

図７は、フィルタ処理の主要な手順を示すフローチャートである。

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

ステップＳ７０１では、必要な前処理を行う。前処理には、フィルタが内部的に利用する属性の初期化や、パターンマッチングに使用するパターン記述に対する前処理、入力ストリームや出力ストリームをより使いやすくする機能を付け加える（たとえば入力ストリームを先読み可能にしたり、システムリソースを有効に利用するバッファリングを拡張したりする）ための修飾クラス（ｊａｖａ．ｉｏ．ＦｉｌｔｅｒＩｎｐｕｔＳｔｒｅａｍやｊａｖａ．ｉｏ．ＦｉｌｔｅｒＯｕｔｐｕｔＳｔｒｅａｍの具体クラス）によってストリームをラップする処理などが含まれる。

ステップＳ７０２では、ｉｎｐｕｔ属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。

ステップＳ７０３では、入力のデータストリーム中からこのフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。フィルタが操作するべきデータパターンは固定のデータ列そのものでもよいし、正規表現（ｒｅｇｕｌａｒｅｘｐｒｅｓｓｉｏｎ）などの形式言語による記述でもよい。パターン記述に合致するデータの出現をデータストリーム中から発見する各種の実装が広く知られている（ｇｒｅｐ、ｓｅｄ、ＡＷＫ、Ｐｅｒｌなどが有名である）。

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

ステップＳ７０４では、パターンマッチングの結果を判定し、パターン記述に合致するデータをデータストリーム中に発見した場合はステップＳ７０５に進む。そうでなければステップＳ７０６に進む。

ステップＳ７０５では、パターン記述に合致したデータストリーム中の部分データ列に対して、このフィルタの目的に応じた操作を施し、その結果で置き換える。

ステップＳ７０６では、処理済の部分データ列（すなわち、監視しているパターンが現れなかったデータ列、あるいは、監視しているパターンを含むデータ列に対してステップＳ７０５の処理を施したデータ列）を出力ストリームに書き込む。

ステップＳ７０７では、入力ストリームが終了したか否かを判定し、終端を迎えた場合は終了する。そうでなければステップＳ７０２に戻り、上記の手順を繰り返す。

図８は、本実施の形態における互換化フィルタが行う処理を説明する図である。

８０１は互換化フィルタクラスのオブジェクトであり、入力ストリームを読み出して、データストリーム中に現れる互換性の問題を解決する処理を施して出力ストリームに書き込む。互換性の問題として、ここでは代表的なＰＤＬのひとつであるＡｄｏｂｅのＰｏｓｔＳｃｒｉｐｔ仕様を実装した各ベンダのプリンタ間におけるベンダごとの解釈の差異に基づく問題を取上げ、その解決の例を説明する。

あるベンダのプリンタによれば、ＰｏｓｔＳｃｒｉｐｔのｓｅｔｐａｇｅｄｅｖｉｃｅでは、／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎが真のとき、カスタム用紙扱いとして、用紙要求をパネルに表示し、一方、偽のときには、指定されたサイズから±５の範囲で定型用紙を検索して、定型にない場合はＰｏｓｔＳｃｒｉｐｔのＰｏｌｉｃｙに従うものと解釈して実装されていた。また別のベンダのプリンタによれば、／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎが真のとき、指定されたサイズそのもののサイズ（範囲なし）で定型用紙を検索して、定型にない場合はカスタム用紙扱いとし、一方、偽のときには、±５の範囲で定型用紙を検索して、定型にない場合はＰｏｓｔＳｃｒｉｐｔのＰｏｌｉｃｙに従うように実装されていた。

ここで、さらに別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、これらのうち後者の解釈に基づく挙動を前提として構築されたとすると、そのシステムにおける印刷要求に対して前者のプリンタでは、期待に反するシチュエーションでカスタム用紙扱いとなってしまい、「用紙なし」が操作パネルに表示されて印刷されないという顧客の不利益が生ずる。前者のプリンタのベンダは、この互換性の問題に対してできるだけ低コストでできるだけ速やかに解決を顧客に提供することが求められる。この要求は、印刷要求データストリーム中に現れるｓｅｔｐａｇｅｄｅｖｉｃｅの／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎパラメータをｔｒｕｅからｆａｌｓｅに変換することで、少なくとも暫定的に、応えることができる。

互換化フィルタ８０１はこの問題解決のために働くフィルタオブジェクトであり、入力データストリーム中から／ＤｅｆｅｒｅｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎがｔｒｕｅで指定されたｓｅｔｐａｇｅｄｅｖｉｃｅに対するパターンマッチングを行い、マッチした場合はｆａｌｓｅに置き換えて出力データストリームを出力する。

８０２はフィルタへの入力データストリームの例であり、ＰｏｓｔＳｃｒｉｐｔのプリントデータである。２行目にパターンに合致する部分データが出現する。

８０３はフィルタからの出力データストリームの例であり、フィルタ処理されたＰｏｓｔＳｃｒｉｐｔのプリントデータである。２行目のデータの中でｔｒｕｅという文字列がｆａｌｓｅへと置換されている。

図９は、本実施の形態における修正フィルタが行う処理を説明する図である。

上記の互換化フィルタでは、プリンタ間の仕様解釈の差異に基づく互換性の問題を解決するために、フィルタによるデータストリームのパターンマッチングと置換の技術を用いたが、同様の技術をプリンタ実装の不具合（ファームウェアのバグなど）を緊急回避するために用いることもできる。たとえば、あるプリンタのあるバージョンのリリースにおいて、ＬＩＰＳ言語の「イメージ領域確保命令（ＶＤＭ）」に指定されるイメージの幅が８の倍数でなければ描画不正が発生するというバグがあったとする。仮にこのようなパターンのデータストリームが特定のアプリケーションの特定の利用においてだけ稀に出力されるものであったとしても、また、本来はトランスレータやレンダラというＬＩＰＳ言語処理系のコア部分で修正するべきバグであったとしても、現実の顧客環境において迅速に対応しなければならない。こうした問題を、修正フィルタを用いて解決する。

９０１は修正フィルタであり、たとえば９０２のようなデータを含むＬＩＰＳデータストリームから、バグを発現させるパターンを発見（ＶＤＭのイメージ幅が「２２５」であって８の倍数でない）し、そのバグを顕在化させず同等の機能を達成する９０３のようなデータ（ＶＤＭのイメージ幅を８の倍数でより大きい値である「２３２」）に置換する。

以上のように、第１の実施の形態によれば、ファームウェアとして静的に実装されたプリント要求受信サーバで受信したデータストリームを、組み込みＪａｖａ（登録商標）環境上に実装した動的ロードや動的リンク可能なフィルタソフトウェアに引き渡すインタフェースを設けたため、安定部分と動的部分とを明確に分離できる。したがって、装置ファームウェア全体を動的で冗長なソフトウェアに置き換える非効率を避けることができ、また、プリント要求受信サーバ機能をＪａｖａ（登録商標）環境側に再実装して二重に持つ非効率も避けることができ、装置コスト的にも開発負荷的にも合理的なフィルタフレームワークを実現できる。さらにまた、顧客環境に納入済みの画像処理装置に対するフィルタの動的な追加や置き換えが容易になったため、低いサポートコストでよりすばやくソリューションを顧客のために提供できるようになる。

また、組み込みシステムのファームウェア開発環境よりも洗練されたＪａｖａ（登録商標）環境でフィルタを実装するため、組み込みシステムでは通常困難な動的なメモリ管理が効果を発揮する高度なパターンマッチングアルゴリズムの実装が容易となり、また高度にモジュール化された再利用性の高いソフトウェアとして設計するために、オブジェクト指向パラダイムに基づくデザインパターンを採用することも容易となり、その結果、生産性高くフィルタ部を実装できるようになった。

またフィルタにおいて、パターンマッチングによって入力データストリーム中から他の実装との互換性問題を発現させるＰＤＬデータを発見し、そのデータを置き換えることで、互換性の問題を低コストですばやく解消することができる。特にこうしたことを、顧客環境のシステムやアプリケーションやプリンタドライバに影響を及ぼすことなく、プリンタ側に閉じた対応だけで達成できる。

また、フィルタを配置しない場合には、印刷要求受信モジュールが受信したデータストリームを直接ジョブ制御モジュールに流れるように構成したため、フィルタを必要としない場合は、フィルタフレームワーク介在のオーバヘッドを避けられ、プリンタ本来のデータ処理性能を維持できる。

〔第２の実施の形態〕
次に本発明の第２の実施の形態を説明する。

第２の実施の形態の構成は、基本的に第１の実施の形態の構成と同じであるので、第２の実施の形態の説明においては、第１の実施の形態の構成と同一部分には同一の参照符号を付してその説明を省略し、異なる部分だけを説明する。

図１０は、第２の実施の形態におけるフィルタが行う処理を説明する図である。

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

１００２は、最適化フィルタクラスのオブジェクト１００１への入力データストリームの例である。この入力データストリーム１１０２では、１００３のように、横長の長方形を塗りつぶすために３つの正方形の塗りつぶしを繰り返す記述が行われている。

１００４は、最適化フィルタクラスのオブジェクト１００１からの出力データストリームの例であり、最適化フィルタクラスのオブジェクト１００１が冗長な繰り返しパターンを検出し、それを等価な１つの横長の矩形の塗りつぶしに書き換えている。

以上のように、第２の実施の形態によれば、Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタにおいて、冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換えることによって、ＰＤＬ処理系のコアにはまったく触れずにプリントパフォーマンスを改善できる。また、プリンタ側に閉じて最適化処理を行うので、顧客環境のシステムやアプリケーションやプリンタドライバを改造する必要もない。また、フィルタの生産性が高くインストールなどのメンテナンスも容易であるため、顧客の利用形態に即して個別対応した最適化が提供できる可能性もある。

〔第３の実施の形態〕
次に本発明の第３の実施の形態を説明する。

第３の実施の形態の構成は、基本的に第１の実施の形態の構成と同じであるので、第３の実施の形態の説明においては、第１の実施の形態の構成と同一部分には同一の参照符号を付してその説明を省略し、異なる部分だけを説明する。

図１１は、第３の実施の形態におけるフィルタが行う処理を説明する図である。

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

機能拡張フィルタ１１０１は、該フィルタが稼動しているプリンタの新しい能力を活かすための印刷ジョブ設定をその属性として持つ。フィルタオブジェクトの属性値は、画像処理装置の不揮発性メモリにも保存され、画像処理装置の電源が落とされて再起動された場合であっても、オブジェクトの状態は保存される。

ジョブ種類属性は、「印刷」「セキュアプリント」などの値をとり、プリンタが備える各種ジョブのタイプを表す。部数属性は、印刷物のコピーを何セット生成するかを表す。ページレイアウト属性は、「１ページ／枚」「２ページ／枚」「４ページ／枚」など１枚の用紙に複数ページを面付けするための指定や、「ポスター（２ｘ２）」「ポスター（３ｘ３）」など１ページを拡大して複数枚の用紙に分割印刷するための指定といった、ページレイアウト指定を表す。配置順属性は、「左上から右向き」「左上から下向き」「右上から左向き」「右上から下向き」などの値をとり、ページレイアウト時の各面の配置指定を表す。印刷方法属性は、「片面印刷」「両面印刷」「製本印刷」などの値をとり、印刷方法を表す。とじ方向属性は、「長辺とじ（左）」「長辺とじ（右）」「短辺とじ（上）」「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。排紙方法属性は、「指定しない」「ソート」「ステイプル」「パンチ穴」などの値をとり、フィニッシングの方法を表す。給紙属性は、「自動」「手差しトレイ」「カセット」「デッキ」あるいは「普通紙」「厚紙」「色紙」「ＯＨＰ」などの値をとり、画像形成対象とする用紙（転写紙）の給紙指定を表す。

１１０２は機能拡張フィルタ１１０１への入力データストリーム例であり、その内容は旧来のアプリケーションやプリンタドライバが生成する単にページごとの画像形成記述を中心とするＰＤＬやテキストからなる印刷データストリームである。

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

１行目は、ジョブの開始を表すデータである。２行目は、ジョブ単位の設定の開始を表すデータである。３行目は、この位置に各種のジョブ単位の設定データが存在することを示す。４行目は、複数文書をひとまとめにする単位の開始を表すデータである。５行目は、複数文書をまとめた単位に対する設定の開始を表すデータである。６行目は、この位置に複数文書をまとめた単位に対する設定データが存在することを示す。７行目は、文書の開始を表すデータである。８行目は、文書単位の設定の開始を表すデータである。９行目は、この位置に文書を単位とする設定データが存在することを示す。１０行目は、文書記述データの開始を表すデータである。１１行目は、文書そのものを表現する文書記述データがこの位置に存在し、ここでは入力データストリーム１１０２に存在した印刷データストリームがこの位置に存在することを示す。１２行目は、文書の終了を表すデータである。１３行目は、複数文書をまとめる単位の終了を表すデータである。１４行目は、ジョブの終了を表すデータである。

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

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

１２０１は機能拡張フィルタ１１０１の基本操作画面であり、フィルタオブジェクト属性の確認や変更などを操作できる。

位置１２０２ではジョブ種類属性の操作を行う。

位置１２０３では部数属性の操作を行う。

位置１２０４ではページレイアウト属性の操作を行う。

位置１２０５では配置順属性の操作を行う。

位置１２０６では印刷方法属性の操作を行う。

位置１２０７ではとじ方向属性の操作を行う。

位置１２０８では排紙方法属性の操作を行う。

位置１２０９では給紙属性の操作を行う。

１２１０はヘルプボタンであり、このヘルプボタン１２１０を押すと、この機能拡張フィルタ１１０１の使い方、機能、属性の意味などの説明が表示される。

１２１１は「標準に戻す」ボタンであり、この「標準に戻す」ボタン１２１１を押すと、各種属性がデフォルトの値に設定される。

１２１２は適用ボタンであり、この適用ボタン１２１２を押すと、属性値の変更操作が適用され、新しい値が実際にフィルタオブジェクトの属性に設定される。

１２１３はプレビューアイコンであり、各種属性の確認を助けるために、いくつかの重要な属性について、その値に応じた模式図が表示される。

以上のように、第３の実施の形態によれば、Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタにおいて、新機能を活かすために必要なデータを追加することで、プリンタの新機能に対応していない顧客環境のシステムやアプリケーションやプリンタドライバと組み合わせる場合であっても、新しい機能を使いこなすことが可能となる。

また、Ｊａｖａ（登録商標）環境が、ファームウェア内のさらにもう一層のソフトウェアプラットフォームとして、その上で動作するフィルタのためにユーザインタフェースを実装する手段を用意するため、追加機能の設定を操作するためのユーザインタフェースをフィルタに備えることができる。

また、フィルタの生産性が高くインストールなどのメンテナンスも容易であるため、顧客の利用形態に即して個別対応した機能拡張が提供できる可能性もある。

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

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

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

さらに、本発明の目的は、前述した各実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵ、ＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体およびプログラムは本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した各実施の形態の機能が実現される場合も含まれる。

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

本発明の第１の実施の形態に係る画像処理装置のハードウェア構成を示すブロック図である。図１に示す画像処理装置を動作させるためのソフトウェア（モジュール）の構成を示す階層図である。図２に示す画像処理装置におけるソフトウェアモジュール間のデータの流れを示す図である。インタプリタ環境上に構築されるフィルタフレームワークのクラスを示す図である。インタプリタ環境上に構築されるフィルタフレームワークが管理するオブジェクトのインスタンスを示す図である。フィルタフレームワークを操作するためのユーザインタフェースの一例を示す図である。フィルタ処理の主要な手順を示すフローチャートである。第１の実施の形態における互換化フィルタが行う処理を説明する図である。第１の実施の形態における修正フィルタが行う処理を説明する図である。第２の実施の形態におけるフィルタが行う処理を説明する図である。第３の実施の形態におけるフィルタが行う処理を説明する図である。機能拡張フィルタを操作するためのユーザインタフェースの一例を示す図である。

符号の説明

１ＣＰＵ（印刷要求データストリーム受信手段、印刷ジョブ制御手段、フィルタ手段、第１のインタフェース手段、第２のインタフェース手段）
２ＲＡＭ
３ＦｌａｓｈＲＯＭ
４システムバス
５ネットワークコントローラ（ＬＡＮＣ）
６ＬＥＤ
９ＲＯＭ
１２ラスタコントローラ
１５ディスクコントローラ（ＤＫＣ）
１６マーキングエンジン
１８操作パネル
１０００プリンタ（画像処理装置）
１６００プリンタコントローラ
２０００ローカルエリアネットワーク（ＬＡＮ）

Claims

クライアントからの印刷要求データストリームを受信する受信手段と、
印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、
印刷要求データストリーム中の特定のデータを置換するフィルタ処理を行い、前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段と、
前記受信手段が受信した印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、
前記フィルタ手段によってフィルタ処理された印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段と、を備え、
前記フィルタ手段はフィルタ処理を実行するためのフィルタプログラムをユーザによる操作に基づいて外部からインストールしたりアンインストールすることで、フィルタ処理の内容を変更することが可能であることを特徴とする画像処理装置。
前記画像処理装置は、プロセッサによって処理されるネイティブ命令で構成されるネイティブ環境中にあって、前記ネイティブ命令とは異なる命令セットに基づいて構築されたプログラムを実行するためのインタプリタ環境を内蔵し、
前記印刷要求データストリーム受信手段および前記印刷ジョブ制御手段は前記ネイティブ環境中にあり、前記フィルタ手段は前記インタプリタ環境中にあることを特徴とする、請求項１に記載の画像処理装置。
前記受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第３のインタフェース手段を更に有することを特徴とする請求項１または請求項２に記載の画像処理装置。
前記フィルタ手段は、
前記印刷要求データストリームにおいて所定のデータパターンに一致する部分を検出するパターンマッチング手段と、
前記パターンマッチング手段によって検出された前記印刷要求データストリーム内の前記一致部分に対応する所定の部分データストリームを生成し、該一致部分と置換する置換手段と
を含むことを特徴とする請求項１乃至請求項３のいずれか１項に記載の画像処理装置。
前記インタプリタ環境は、該インタプリタ環境上で動作するプログラムをユーザが操作するためのユーザインタフェースを構築するユーザインタフェース構築手段を有し、
前記フィルタ手段は、前記印刷要求データストリームに対するデータ処理の処理パラメータが、前記ユーザインタフェース構築手段によって構築されたユーザインタフェースを用いてユーザによって操作されることを特徴とする請求項２に記載の画像処理装置。
前記インタプリタ環境は、該インタプリタ環境上で動作するプログラムのために命令の読み出し及び解釈を並行して実行するスレッド手段を有し、
前記フィルタ手段は、前記スレッド手段による独立した実行コンテクストの下で、前記印刷要求データストリームに対するデータ処理を自律的に実行することを特徴とする請求項２に記載の画像処理装置。
前記インタプリタ環境は、Ｊａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項２に記載の画像処理装置。
クライアントからの印刷要求データストリームを受信する受信手段と、
印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、
印刷要求データストリームをフィルタ処理して前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段と、
前記受信手段によって受信された印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、
１つ以上のフィルタ手段を印刷要求データストリームのデータパス中に配置可能に制御し、配置された１つ以上のフィルタ手段に逐次的に印刷要求データストリームを処理させるフィルタ管理手段と、
前記フィルタ管理手段によって配置された１つ以上のフィルタ手段によってフィルタ処理された印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段と、
を有することを特徴とする画像処理装置。
前記フィルタ管理手段によって管理されている複数の前記フィルタ手段の中からフィルタ手段を印刷要求データストリームのデータパス中に選択的に配置させるユーザ操作を受け付けるフィルタ配置操作受付手段を更に有することを特徴とする請求項８に記載の画像処理装置。
前記フィルタ管理手段が印刷要求データストリームのデータパス中に前記フィルタ手段を１つも配置していない場合に、前記印刷要求データストリーム受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に直接引き渡す第３のインタフェース手段を更に有することを特徴とする請求項８または請求項９に記載の画像処理装置。
フィルタ手段を前記画像処理装置の外部から前記画像処理装置内に導入して前記フィルタ管理手段の管理下に置くためのフィルタ導入手段を更に有することを特徴とする請求項８乃至請求項１０のいずれか１項に記載の画像処理装置。
クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリーム中の特定のデータを置換するフィルタ処理を行い、前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備え、前記フィルタ手段はフィルタ処理を実行するためのフィルタプログラムをユーザによる操作に基づいて外部からインストールしたりアンインストールすることで、フィルタ処理の内容を変更することが可能である画像処理装置に適用される画像処理制御方法において、
前記受信手段が受信した印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、
前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップと
を有することを特徴とする画像処理制御方法。
前記受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第３のインタフェースステップを更に有することを特徴とする請求項１２に記載の画像処理制御方法。
クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリームをフィルタ処理して前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備えた画像処理装置に適用される画像処理制御方法において、
前記受信手段によって受信された印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、
前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップと、
１つ以上のフィルタ手段を印刷要求データストリームのデータパス中に配置可能に制御し、配置されたフィルタ手段に逐次的に印刷要求データストリームを処理させるフィルタ管理ステップと
を有することを特徴とする画像処理制御方法。
前記フィルタ管理手段によって管理されている複数の前記フィルタ手段の中からフィルタ手段を印刷要求データストリームのデータパス中に選択的に配置させるユーザ操作を受け付けるフィルタ配置操作受付ステップを更に有することを特徴とする請求項１４に記載の画像処理制御方法。
前記フィルタ管理ステップによって印刷要求データストリームのデータパス中に前記フィルタ手段が１つも配置されない場合に、前記印刷要求データストリーム受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に直接引き渡す第３のインタフェースステップを更に有することを特徴とする請求項１４または請求項１５に記載の画像処理制御方法。
クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリーム中の特定のデータを置換するフィルタ処理を行い、前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備え、前記フィルタ手段はフィルタ処理を実行するためのフィルタプログラムをユーザによる操作に基づいて外部からインストールしたりアンインストールすることで、フィルタ処理の内容を変更することが可能である画像処理装置に適用される画像処理制御方法を、コンピュータに実行させるためのプログラムにおいて、
前記画像処理制御方法は、
前記受信手段が受信した印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、
前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップと
を有することを特徴とするプログラム。
クライアントからの印刷要求データストリームを受信する受信手段と、印刷要求データストリームを解釈してジョブを制御する印刷ジョブ制御手段と、印刷要求データストリームをフィルタ処理して前記印刷ジョブ制御手段が解釈可能なフィルタ処理済の印刷要求データストリームを生成するフィルタ手段とを備えた画像処理装置に適用される画像処理制御方法を、コンピュータに実行させるためのプログラムにおいて、
前記画像処理制御方法は、
前記受信手段によって受信された印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェースステップと、
前記フィルタ手段によって生成された処理済の印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェースステップと、
１つ以上のフィルタ手段を印刷要求データストリームのデータパス中に配置可能に制御し、配置されたフィルタ手段に逐次的に印刷要求データストリームを処理させるフィルタ管理ステップと
を有することを特徴とするプログラム。