情報処理装置及び方法
【課題】データストリーム中の記述に基づいてフィルタリング処理を適用するか否かを制御可能とし、効率的なデータストリーム処理を実現する。
【解決手段】ネイティブ環境２０１で、ネイティブ命令群とは独立に定義された命令セットに基づいて構築されたプログラムを動的に実行するインタプリタ環境２１５を備えるデータ処理装置において、ネイティブ環境２０１では入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成し、インタプリタ環境２１５では中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成する。中間データストリームのフィルタ２２１への引き渡しはレイヤＩ／Ｆ２１１を介して行われる。データストリーム管理属性モジュール２２８は、中間データストリームから予め指定された項目の情報を抽出し、該情報の内容に基づいて、中間データストリームのフィルタへの引き渡しの実行を制御する。
【解決手段】ネイティブ環境２０１で、ネイティブ命令群とは独立に定義された命令セットに基づいて構築されたプログラムを動的に実行するインタプリタ環境２１５を備えるデータ処理装置において、ネイティブ環境２０１では入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成し、インタプリタ環境２１５では中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成する。中間データストリームのフィルタ２２１への引き渡しはレイヤＩ／Ｆ２１１を介して行われる。データストリーム管理属性モジュール２２８は、中間データストリームから予め指定された項目の情報を抽出し、該情報の内容に基づいて、中間データストリームのフィルタへの引き渡しの実行を制御する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファームウエア等が動作するネイティブ環境と、そのネイティブ環境において動作するインタプリタ環境とを用いた情報処理技術に関する。
【背景技術】
【０００２】
従来、例えば複写機やＭＦＰ（マルチファンクションプリンタ）などの画像処理装置で画像処理を実行するソフトウェアは、オペレーティングシステム（ＯＳ）の上に静的かつ固定的な、いわゆるファームウェアとして構築されることが主流であった。このようなファームウェアは、内部的に複数のモジュールから構成されている場合でも、全体が単一のロードモジュールに静的にリンクされた状態で装置の不揮発性メモリに記憶される。そして、システムの起動時にハードディスクなどの不揮発性メモリからＲＡＭにロードされて実行されるか、又はそのファームウェアを記憶しているＲＯＭなどの不揮発性メモリ上で直接実行される。特に低価格の画像処理装置のように、組み込みシステムを構成するファームウェアは一般に、その経済性や安全性等のために、部分的なモジュールの動的なロードやリンクを行わないように構成されている。即ち、ダイナミックリンクを実現するために必要なシンボルテーブルを記憶するためのメモリ容量や、シンボルのアドレスへアクセスするための処理に関するオーバヘッドなどが、装置のコストパフォーマンスを悪化させる。また、サブモジュールの追加ロード及びリンクによって、そのサブモジュールをリンクする以前には十分に評価され達成されていたシステム全体の品質やセキュリティが脅かされる危険があるためである。
【０００３】
上記の問題を解決するために、組み込みシステムのファームウェアのリアルタイムＯＳ上に更にもう一層のソフトウェア動作環境を設けた画像処理装置が開発されている。このもう一層の追加のソフトウェア動作環境において、ダイナミックローディングやダイナミックリンキングや動的なメモリ操作などのソフトウェアの動的な特性がサポートされる。追加のソフトウェア動作環境は、インタプリタと一揃いのアプリケーションプログラミングインターフェース（ＡＰＩ）群やフレームワーク群から構成され、その上で動作するソフトウェアのために一種のＯＳ或はコンピューティングプラットフォームを提供する。インタプリタは、所定の命令セットに含まれる命令からなる一連の命令列を逐次的に読み出し解釈し実行する。この命令セットをＣＰＵのための命令セットと同等の位置付けで捉える場合、インタプリタは特に仮想マシン（virtual machine）と呼ばれることもある。一揃いのＡＰＩ群及びフレームワーク群は、このソフトウェア動作環境の下層にある実際のリアルタイムＯＳが提供する資源やハードウェア資源を抽象化した各種の資源群に対するアクセスを、ソフトウェア動作環境上で動作するソフトウェアのために提供する。これら資源には、プロセッサによる命令実行コンテクストやメモリ、ファイルシステム、ネットワークインターフェースを含む各種入出力（Ｉ／Ｏ）などがある。特に命令実行コンテクストは、ＣＰＵとリアルタイムＯＳが提供するマルチタスク機構とは独立に、ソフトウェア動作環境が独自にインタプリタ上の命令実行コンテクストを管理できる。また、メモリの管理も同様にソフトウェア動作環境が独自のメモリ管理を提供できる。
【０００４】
このようなソフトウェア実行環境上で動作するソフトウェアは、インタプリタによって逐次的に読み込まれて解釈されて実行されるため、これらの処理の過程で命令列を監視しシステムに悪影響を与える動作を除外できる可能性がある。また、ソフトウェア実行環境上で動作するソフトウェアからの各種資源に対するアクセスは、そのソフトウェア実行環境が提供するＡＰＩ群やフレームワーク群を経由して間接的に行われる。このため、ファームウェア内部にインタプリタ及びＡＰＩ群とフレームワーク群からなるソフトウェア実行環境の階層を設けるアプローチは、このアクセスの過程で、システムに悪影響を与える動作を除外できる可能性がある。従って、このようなアプローチは、静的かつ固定的に構成されるべき低コスト組み込みシステムのファームウェアにおいて、ソフトウェアの動的な特性を部分的に導入するために非常に有効である（特許文献１、特許文献２）。
【０００５】
上記アプローチにおいて、ソフトウェア実行環境の階層を実現するためにインタプリタとしてＪａｖａ（登録商標）仮想マシンを採用し、Ｊａｖａ（登録商標）に関連するＡＰＩ群やフレームワーク群を採用することができる。本出願人は２００３年に、画像処理装置のファームウェア内部にＪａｖａ（登録商標）プラットフォームを内蔵した複合機を製品化している。
【０００６】
従来、ネットワークコンピュータを備えたアプリケーションダウンロード型プリンタを用い、コンピュータネットワークから、印刷すべきデータファイルと、そのデータファイルに対応したアプリケーションとをプリンタにダウンロードすることが行われている。そして、そのダウンロードしたアプリケーションを立ち上げて実行することにより、データファイルを開いてラスタイメージに変換し、それを印刷するネットワークコンピュータ内蔵型プリンタが知られている。またこの場合のアプリケーションとして、「Ｊａｖａ（登録商標）アプレット」を用いることも開示されている。このアプリケーションは印刷データファイルとともにクライアントからプッシュされる場合も、プリンタがアプリケーションサーバなどからプルすることも開示されている（特許文献３）。
【０００７】
特許文献４には複数の周辺機器及び周辺機器を動作させるソフトウェアを搭載した複数の端末装置、及び少なくとも周辺装置を動作させるソフトウェアに関するデータベースを備えたサーバ装置を伝送路に接続させたネットワーク通信システムが提案されている。このネットワーク通信システムにおいては、伝送路に接続された周辺機器、端末装置、サーバ装置の間で所定の通信プロトコルに基づいてネットワーク通信が行われる。ここで、周辺機器は、クライアント制御部と、ソフトウェア配信エージェントを備える。クライアント制御部は、サーバ装置から周辺機器を動作させるためのソフトウェアの全部／一部、或はソフトウェアが使用するモジュールに対応する最新モジュール情報を要求・獲得する。また、ソフトウェア配信エージェントは、獲得した最新モジュールを端末装置に配付する。そして、特許文献４によれば、この場合の周辺機器を操作するソフトウェアが使用するクライアント側モジュールとして、「Ｊａｖａ（登録商標）アプレット」や「Ｊａｖａ（登録商標）アプリケーション」が供給可能であることも開示されている。
【０００８】
一方、基幹系の業務システムでは、一度、正常に稼働し始めたシステム全体の安定性を維持したいという要望はとても強く、プリンタドライバやアプリケーションの変更やバージョンアップなどの変更が簡単に許されない場合がある。このような現実のプリンティング環境の制約の中で、プリンタのベンダは顧客側に対応を求めるのではなく、プリンタ側の対応によって各種の顧客要望に応えるべき使命がある。このためには、プリンタ／プリンタコントローラを構成するファームウェアを改造して各顧客に対応してリリースする方法がある。しかし、ファームウェアの改造による各顧客への対応は、装置の開発期間や開発費などが多くかかり、またファームウェアの更新にはフィールドエンジニアなどによる高度なメンテナンスの手間を要する。このため、各顧客の要望に速やかに応えるには、費用対効果の面でも課題を残している。
【０００９】
組み込みシステムのファームウェアに、例えばＪａｖａ（登録商標）プラットフォームのようなソフトウェア動作環境を内蔵する複合機では、ソフトウェア動作環境上に、ファームウェアと独立した新たな装置組み込みアプリケーションを開発可能である。そして、ＡＰＩによってＪａｖａ（登録商標）アプリケーションから装置のプリント機能にアクセスすることができた。しかしながら、Ｊａｖａ（登録商標）プラットフォームはファームウェア内の組み込みアプリケーション階層に位置付けられている。このため、Ｊａｖａ（登録商標）プラットフォームと同じ階層でネイティブの組み込みアプリケーションとして実現されているプリントデータの受信機能やプリントサーバ機能をＪａｖａ（登録商標）アプリケーションのために流用できなかった。即ち、例えばネットワーク経由でプリントデータを受信するための各種プリントサービスプロトコルを実装したプリントサーバ機能をＪａｖａ（登録商標）側にも再実装する必要があり、開発負荷や評価負荷並びに実行時のメモリ容量の点でも非効率であった。
【００１０】
一方、その他の組み込みシステムのファームウェア内にソフトウェア動作環境の階層を持たない場合には、組み込みシステム全体がダイナミックリンクやプラグイン可能な構成で、システム全体が動的な構成になってしまっていた。これは、動的な特性が求められる部分が、受信したＰＤＬデータストリームを解釈する前の前処理を柔軟かつ拡張可能に追加する機構だけであることを前提とした場合に、低価格の小規模システムには不向きである。システム全体を動的なソフトウェアとして構成するためのオーバヘッドに伴うコストアップや品質保証の難しさが伴うためである。
【００１１】
そこで、本出願人は、特願２００４−０９３２１５号において、プリンタが受信したＰＤＬデータストリームの解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、プリンタファームウェアのその他の部分と分離することを提案した。これは、フィルタ部の拡張可能なソフトウエアの実装を、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離することにより、ＰＤＬプリンタのカスタマイズの生産性を向上する技術の提案である。
【００１２】
しかしながら、上記提案では、フィルタ処理を常に印刷要求データストリーム全体に対して行う必要があり、効率的な処理が実現できていない。即ち、画像処理装置が受信する印刷要求データストリームは、装置制御データストリーム部と描画データストリーム部とで構成されているが、フィルタ処理は常に印刷要求データストリム全体に施されてしまう。そして、このフィルタ処理は常に、これら両方を含んだデータストリームに対して実行されてしまうため、処理全体が重くなり、スループットが落ちるなど、効率的な処理が行えない。また画像処理装置へのデータの一時保管処理のような、ＰＤＬ以外の様々な処理要求データストリームへの対応や、画像処理装置で読み取った画像データを電子メールで送信するといった、様々なデータストリームへの対応も考慮されていなかった。
【００１３】
そこで、より効率的な処理の実現を目指して、本出願人は特願２００４−２３１４３３号を出願した。特願２００４−２３１４３３号では、装置制御データストリーム部と描画データストリーム部といった夫々のデータストリーム部分に対して、フィルタをかけることが可能な構成を提案している。なお、装置制御データストリーム部は、「ＪＬ（Job Language）」等の印刷装置の給排紙段の指定といった、主に装置の制御に関する指示命令で構成される。また、「ＰＤＬ(Page Description 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の仕様に基いている事を意味する。
【００４８】
ジョブ制御ライブラリ２１８は、制御ＡＰＩ２０４に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインターフェースを提供する。
【００４９】
フィルタフレームワーク２１９は、組み込みアプリケーション２０３と通信して、ジョブの実行に際して、インタプリタ環境上に実装したフィルタプログラムからの画像処理装置１０００の複数のデータストリームに対する介在を可能とする。
【００５０】
インタプリタコード部２２０は、インタプリタ２１６が解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するAPIライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部２０１とインタプリタコード部２２０に跨って位置付けられるソフトウェアは、それぞれの空間の間をインターフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではＪａｖａ（登録商標） Native Interface（JNI）に従って境界部分のプログラミングを行っている。
【００５１】
フィルタ２２１は、インタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているため、組み込みアプリケーション２０３が処理する処理要求データストリームに対する処理を行うことができる。プロトコルスタック２２３は、ＲＴＯＳ２１４のフレームワークに組み込まれ、より下層の外部インターフェースドライバ２２４が制御する外部インターフェース上にトランスポート層以下のプロトコルを実装する。例えば、ネットワークインターフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現する。そして、組み込みアプリケーション２０３に対しては、ＲＴＯＳ２１４を介してバークレイソケットなどのアプリケーションプログラミングのためのインターフェースを提供する。また例えば、外部インターフェースがＵＳＢの場合にはＩＥＥＥ１２８４.４などのプロトコルを実現する。
【００５２】
外部インターフェースドライバ２２４は、ネットワークインターフェースやＩＥＥＥ１３９４、ＵＳＢ，ＲＳ２３２Ｃ、セントロニクスなどの各種インターフェースへの接続を提供するハードウェアを駆動する。例えばネットワークの場合、イーサネット（登録商標）などのネットワークに接続するためのネットワークインターフェースハードウェアを駆動して物理層のプロトコルを実現する。
【００５３】
レンダラドライバ２２５はレンダラ２０７を駆動する。レンダラ２０７は、図３のディスプレイリスト３５５を中間画像データストリーム３５６に展開するためのハードウェアである。レンダラ２０７はソフトウェアによって実現してもよいし、展開されるデータストリームは最終画像データストリーム３５７（図３）でもよい。マーキングエンジン（ＭＥ）ドライバ２２６は、転写紙への画像形成を行うマーキングエンジンを駆動する。操作パネルドライバ２２７は、この画像処理装置１０００が備える操作パネル１８の表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。
【００５４】
また、レイヤＩ／Ｆ２１１はデータストリーム属性管理モジュール２２８を有する。ユーザは操作パネル１８を介して、データストリーム属性管理モジュール２２８に対して画像処理装置１０００におけるデータストリームの処理内容を指示することができる。
【００５５】
具体的には、データストリーム属性管理モジュール２２８は、処理要求データストリーム３５０がデータ送受信モジュール２０２において受信された場合、処理要求データストリーム３５０に対応するデータストリーム属性の管理を開始する。ネイティブ環境に存在する各モジュールは、必要に応じてデータストリーム属性管理モジュール２２８に問い合わせを行い、データストリームに対する処理内容を決定する。ここでネイティブ環境のモジュールとしては、データ送受信モジュール２０２、組み込みアプリケーション２０３、ジョブ制御モジュール２０５が挙げられる。また、更には、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９、データ管理モジュール２１０が挙げられる。また、上記各モジュールは、特定の情報が抽出された場合に、データストリーム属性管理モジュール２２８に通知を行う。この通知により、データストリーム属性管理モジュール２２８は、データストリーム属性を更新する。データストリーム属性管理モジュール２２８は、処理要求データストリーム３５０に対する処理が全て終了した旨の通知をジョブ制御モジュール２０５から受けることにより、処理要求データストリーム３５０に対するデータストリーム属性の管理を終了する。
【００５６】
或いは、スキャン画像データストリーム３６０がジョブ制御モジュール２０５において生成された場合、データストリーム属性管理モジュール２２８は、スキャン画像データストリーム３６０に対するデータストリーム属性の管理を開始する。そして、前述と同様にデータストリーム属性が管理される。データストリーム属性管理モジュール２２８は、スキャン画像データストリーム３６０に対する処理が全て終了した旨の通知をジョブ制御モジュール２０５から受けると、スキャン画像データストリーム３６０に対するデータストリーム属性の管理を終える。
【００５７】
上述したように、データストリーム属性管理モジュール２２８は、データ送受信モジュール２０２が処理要求データストリーム３５０を受信すると、そのデータストリーム属性の管理を開始する。ここで、データストリーム属性管理モジュール２２８は、インタプリタ環境に存在する各モジュールに対してそのデータストリーム属性を、制御ＡＰＩを介して公開する。こうして前述と同様のデータストリーム属性に対する処理（データストリーム属性の管理開始。各モジュールからのデータストリーム管理モジュールへの問い合わせ。各モジュールからのデータストリーム管理モジュールへの通知。データストリーム管理モジュールによるデータストリーム属性の更新。データストリーム属性の管理終了処理）が可能となる。またデータストリーム属性により、インタプリタ環境のモジュールに対しては引き渡しそのものを行わないといった動作も実行可能となる。
【００５８】
図３は、本実施形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れとそれぞれのモジュールにおいて存在するデータストリームを示す図である。図２に示すモジュールと共通するモジュールには同一の符号をつけて説明を省略する。
【００５９】
データ送受信モジュール２０２は、クライアントから受信した、処理要求データストリーム３５０を、フィルタ２２１を介さない場合に、経路３０１を介して組み込みアプリケーション２０３に流す。この経路３０１は、例えばＲＴＯＳ２１４が提供するメッセージキュー等のタスク間通信機能によって実現される。その他のデータの受け渡しも同様である。尚、処理要求データストリーム３５０は、装置制御指示データストリーム３５１と描画データストリーム３５２からなる。
【００６０】
ここでクライアントが、ＬＡＮ２０００を介したホスト上のアプリケーション及びドライバソフトの場合、クライアントは処理要求データストリーム３５０を生成する。そして、その処理要求データストリーム３５０を、データ送受信モジュール２０２を介して組み込みアプリケーション２０３へ引き渡す。組み込みアプリケーション２０３は、処理要求データストリーム３５０を装置制御指示データストリーム３５１と描画データストリーム３５２とに分割し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５にそれぞれを引き渡す。或は、装置制御指示データストリーム３５１を解釈し、制御ＡＰＩ２０４によってジョブ制御モジュール２０５に対して、クライアントから要求された処理を指示し、描画データストリーム３５２を引き渡す。
【００６１】
一方、クライアントが画像処理装置の操作パネル１８を介した指示の場合は、組み込みアプリケーション２０３で装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡す。或はジョブ制御モジュール２０５に対して制御ＡＰＩ２０４によってクライアントから要求された指示を行う。装置の制御に関する記述部は、一般的にはＪＬ（Job Language）と呼ばれる。ＪＬには、描画データの解釈及び展開に関する動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などが含まれる。一方、描画データストリームはＰＤＬによって記述されており、主にページ毎の描画が記述されている。
【００６２】
ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した指示に従って装置１０００の制御を行う。或は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５へ入力された装置制御指示データストリーム３５１を解釈して動作を行う。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した装置１０００の制御に関する指示、或は装置制御指示データストリーム３５１の記載内容に応じて、制御線３９０を介して、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９及びデータ管理モジュール２１０を制御する。プリントジョブの場合は、ジョブ制御モジュール２０５は次のようにスケジュールする。即ち、描画データストリーム３５２をトランスレータ２０６によりディスプレイリスト３５５に変換させ、ディスプレイリスト３５５をレンダラ２０７により中間画像データストリーム３５６に変換させる。そして、中間画像データストリーム３５６を画像処理モジュール２０９により最終画像データストリーム３５７に変換し、最終画像データストリーム３５７がＭＥ制御モジュール２０８に流れて印刷するようにする。
【００６３】
更なる一例として、組み込みアプリケーション２０３により提供される画像データの読み取りと送信の際の動作を示す。操作パネル１８から画像データの読み取り及び送信指示が行われた場合、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと送信の指示を行う。この指示は組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して、直接ジョブ制御モジュール２０５に伝えられ、実行される。或は、この指示は、組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、画像読み取り部１９で読み取られた画像データを入力してＲＡＭ２上に保持して画像処理モジュール２０９に引き渡す。こうして画像処理モジュール２０９で生成されたスキャン画像データストリーム３６０を組み込みアプリケーション２０３へ引き渡すようにスケジューリングする。組み込みアプリケーション２０３は、その引き渡されたスキャン画像データストリーム３６０を操作パネル１８から指示された形式に変換して送信用データストリーム３５９を生成する。そして、この送信用データストリーム３５９を、データ送受信モジュール２０２を介して送信用データストリーム３５９として送信する。或は、操作パネル１８から指示された送信先が、内蔵されている外部メモリ１０の場合は、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと保存指示を行う。この指示は、組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して直接ジョブ制御モジュール２０５に渡され、実行される。或は、組み込みアプリケーション２０３がこの指示に基づく装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、３９０を介して、画像読み取り部１９から画像データを入力してＲＡＭ２上に保持し、画像処理モジュール２０９に引き渡す。こうして生成されたスキャン画像データストリーム３６０をデータ管理モジュール２１０を介して外部メモリ１０へ格納するようにスケジューリングする。
【００６４】
以上の処理は全てネイティブコード部分２０１に実装されている。
【００６５】
図４は、本実施の形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。各モジュールにおけるデータストリームは図３と同様であり、前述の図面と共通する部分は同じ記号で示している。
【００６６】
データ送受信モジュール２０２は、データストリームに対してフィルタ処理を施す場合には、処理されたデータストリームを、経路３０６を介して外部レイヤ２１２に流す。この経路３０６は、例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間の通信機能によって引き渡されるが、その他のデータの受け渡しでも良い。レイヤＩ／Ｆ２１１の中の外部レイヤＩ／Ｆ２１２は、各種データストリームをインタプリタ環境２１５へ引き渡す。データとストリームとしては、例えば、画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、この処理要求データストリーム３５０を画像処理装置１０００内で分割して得られた装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換・生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８が挙げられる。尚、これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。
【００６７】
外部レイヤＩ／Ｆ２１２は、その受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境上２１５に実装されたフィルタプログラム群２２１を管理している。フィルタフレームワーク２１９は、そのデータストリームを、経路３０８を介してフィルタ２２１に流す。この経路３０８では、例えばインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。インタプリタ環境２１５内のデータのやりとりに関しても以下同様である。ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。
尚、ランタイムモジュールとはプログラムを実行する際に必要となるソフトウェアモジュールを意味する。
【００６８】
フィルタ２２１は、入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９を介してフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤＩ／Ｆ２１２に引き渡す。これにより外部レイヤＩ／Ｆ２１２は、そのデータストリームを経路３１１を介して組み込みアプリケーション２０３に流す。また或は、外部レイヤＩ／Ｆ２１２が、経路３７０を介してデータ送受信モジュール２０２にデータストリームを流し、そのデータストリームを、前述のように経路３０１を介して組み込みアプリケーション２０３に流す構成をとってもよい。
【００６９】
制御パス３１２，３７２は、フィルタフレームワーク２１９の状態に応じて、データ送受信モジュール２０２から組み込みアプリケーション２０３に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、前述の経路３０６，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３０１が有効となり、データストリームは直接、データ送受信ストリーム２０２から組み込みアプリケーション２０３に流れる。この場合、フィルタフレームワーク２１９が介在することによるオーバヘッドが避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００のデータ処理性能を発揮できる。
【００７０】
組み込みアプリケーション２０３がデータストリームに対してフィルタ処理を施す場合には、データストリームは経路３１４を介して外部レイヤ２１２に流れる。この経路３１４は例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間通信機能によって引き渡されるが、その他のデータの受け渡しも同様である。外部レイヤ２１２は、前述したように、レイヤＩ／Ｆ２１１の中でも特に、基本的には画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、処理要求データストリーム３５０が画像処理装置１０００内で分割された装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換、生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８をインタプリタ環境２１５へ引き渡す。これらのデータストリームはデータ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。外部レイヤ２１２は、受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境２１５に実装されたフィルタ２２１を管理している。フィルタフレームワーク２１９は、受け取ったデータストリームを経路３０８を介してフィルタ２２１に流す。この経路３０８は、例えばインタプリタ環境２１５が提供するスレッド間通信機能によって実現される。インタプリタ環境２１５のデータのやりとりに関しても以下同様である。尚、ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。
【００７１】
フィルタ２２１は、受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９よってフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９はフィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤ２１２に引き渡し、外部レイヤ２１２は、経路３１５を介して、そのデータストリームをジョブ制御モジュール２０５に流す。尚、ここで外部レイヤ２１２が、経路３７１を介して、そのデータストリームを組み込みアプリケーション２０３に流し、前述のように経路３１３を介してジョブ制御モジュール２０５に流す構成をとってもよい。
【００７２】
制御パス３１６，３７２は、フィルタフレームワーク２１９の状態に応じて組み込みアプリケーション２０３からジョブ制御モジュール２０４に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１４，３０７が有効となりフィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３１３が有効となり、データストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク２１９が介在することによりオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００でのデータ処理性能を発揮できる。
【００７３】
次に、ジョブ制御モジュール２０５が、データストリームに対してフィルタ処理を施す場合を説明する。この場合、データストリームは、経路３１８を介して、内部レイヤＩ／Ｆ２１３に流れる。経路３１８は、例えばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間の通信機能によって引き渡される。その他のデータの受け渡しも同様である。内部レイヤＩ／Ｆ２１３は、レイヤＩ／Ｆ２１１の中でも特に、画像処理装置１６００で生成されるディスプレイリストやデータストリームをインタプリタ環境２１５へ引き渡す。内部レイヤＩ／Ｆ２１１によって引き渡されるデータとしては、トランスレータ２０６が描画データストリーム３５２を処理することで生成するディスプレイリスト３５５、レンダラ２０７がディスプレイリスト３５５を処理することで生成する中間画像データストリーム、画像処理モジュール２０９が中間画像データストリーム３５６を処理することで生成する最終画像データストリーム３５７、画像読み取り部１９から読み込まれたスキャン画像データストリーム３６０などが挙げられる。尚、これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。内部レイヤＩ／Ｆ２１３は、経路３１８を介して受け取ったデータストリームを、フィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールはインタプリタ環境２１５に実装されたフィルタ２２１を管理している。このインタプリタコード部２２０におけるフィルタ処理は前述の処理と同じであるため、その説明を省略する。
【００７４】
フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して内部レイヤＩ／Ｆ２１３に引き渡す。内部レイヤＩ／Ｆ２１３は、そのデータストリームを経路３１９を介してジョブ制御モジュール２０５に流す。尚、内部レイヤＩ／Ｆ２１３が直接、トランスレータ２０６、レンダラ２０７、画像処理モジュール２０９、ME制御モジュール２０８、データ管理モジュール２１０へ引き渡す構成をとってもよい。
【００７５】
制御パス３２０，３７２は、フィルタフレームワーク２１９の状態に応じてデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１８，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には経路３１７が有効となり、データストリームは直接ジョブ制御モジュール２０５がスケジューリングした次のモジュールに流れる。この場合、フィルタフレームワーク２１９が介在することによるオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置のデータ処理性能を発揮できる。
【００７６】
上記の構成において、本実施形態の画像処理装置にけるネイティブ環境にはデータストリーム属性管理モジュール２２８が存在する。データストリーム属性管理モジュール２２８は、図１７に示されるような処理を実行する。
【００７７】
まず、ステップＳ２１において、処理要求データストリーム３５０がデータ送受信モジュールから入力されると、データストリーム属性管理モジュール２２８は受信した処理要求データストリーム３５０の属性の管理を開始する。次に、ステップＳ２２において、ステップＳ２１で入力された処理要求データストリーム３５０を解析し、装置制御指示データストリーム３５１から当該処理要求データストリームのジョブ種類やＰＤＬ種別を判定する。これは、図１０で後述するように、処理要求データストリーム８０１に含まれる装置制御指示データストリーム３５１に記述された「ジョブ種類」や「使用ＰＤＬ」に基づいてなされる。
【００７８】
一方、本実施形態のフィルタ２２１には、複数のフィルタが登録されており、図７により後述するように処理要求データストリームや所望の中間データストリームに対して適用すべきフィルタ、或はフィルタの組み合わせが設定される。一方、図１８により後述するように、各フィルタ或はフィルタの組み合わせに、適用条件が設定される。図１８の例では、描画データストリームを対象としたフィルタ（或はフィルタの組み合わせ）について、フィルタを適用すべき条件としてＰＤＬ種別やジョブ種類を設定可能な様子が示されている。即ち、本実施形態では、各中間データに対して適用すべきフィルタ（或はフィルタの組み合わせ）が登録されると共に、実際にそのフィルタ処理を適用するか否かを判定するためのＰＤＬ種別やジョブ種類等が登録される。
【００７９】
従って、ステップＳ２３ではチェック対象のフィルタ（或はフィルタの組み合わせ）を選択する。そしてステップＳ２４において、入力した処理要求データストリームに記述されているＰＤＬ種別やジョブ種類と、登録されているフィルタ（或はフィルタの組み合わせ）に設定されているＰＤＬ種別やジョブ種類とを比較する。比較の結果、両者が一致した場合は、ステップＳ２５において当該フィルタが、対象となる中間データストリームへ適用されるように、組み込みアプリケーション２０３或はジョブ制御モジュール２０５を設定する。一方、ステップＳ２４における比較の結果、両者が一致しない場合は、ステップＳ２６へ進み、対象となる中間データストリームの転送を禁止するよう、組み込みアプリケーション２０３或はジョブ制御モジュール２０５を設定する。以上のステップＳ２３〜Ｓ２６の処理を登録されているフィルタについて行なう（ステップＳ２７）。
【００８０】
尚、上記処理では、データストリーム属性管理モジュール２２８は、処理要求データストリームを解析してフィルタの適用条件との対応を調べたが、これに限られるものではない。中間データストリーム（例えば、装置制御指示データストリーム３５１）を入力し、このデータストリームを解析することにより適用条件との対応をチェックするようにしてもよい。このようにすれば、例えば、装置制御指示データストリーム３５１を用いて描画データストリーム３５２にフィルタ機能を適用するか否かを判断する構成となる。
【００８１】
以上のような設定が組み込みアプリケーション２０３やジョブ制御モジュール２０５になされると、組み込みアプリケーション２０３やジョブ制御モジュール２０５は次のように動作する。即ち、生成されたた中間データストリーム（描画データストリーム３５２やディスプレイリスト３５５等）のうちフィルタ処理を適用すると設定された中間データストリームのみをレイヤＩ／Ｆ２１１に送るように動作する。このような制御により、中間データストリームの不要なフィルタ処理が禁止され、処理効率が向上する。
【００８２】
図５は、本実施の形態のインタプリタ環境２２０に構築されるフィルタフレームワーク２１９のクラスを説明する図である。
【００８３】
フィルタ管理（FilterManager）クラス４０１は、フィルタフレームワーク２１９のランタイム環境を実現するオブジェクトのクラスである。このフィルタ管理クラス４０１は一つのコネクタ（Connector）クラス４０５のオブジェクトをコンポジション（composition）として持つ。また複数（ｎ個）のフィルタ（Filter）抽象クラス４０２のオブジェクトへの参照と、複数｛（ｎ−１）個｝のパイプ（Pipe）クラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワーク２１９のランタイムに、インストールされた複数のフィルタクラス４０２の具体クラスを管理するためのinstalledFilter属性４１０を備えている。
【００８４】
フィルタ抽象クラス４０２は、各種のフィルタクラスを抽象化する抽象クラスである。このフィルタ抽象クラス４０２は、フィルタ名称を示す「name」属性などを備える。また、入力（input）属性として、入力ストリーム（InputStream）抽象クラス４０３を継承したクラスのオブジェクトへの参照を有している。また出力（output）属性として、出力ストリーム（OutputStream）抽象クラス４０４を継承したクラスのオブジェクトへの参照を有している。フィルタ抽象クラス４０２の具体クラスは、Runnableインターフェース４１１を実装し「run」メソッドを有している。フィルタ管理クラス４０１のオブジェクトは、管理している各種のフィルタ抽象クラス４０２のインスタンスを生成してデータストリームのフィルタ処理のために配置する。この時、配置される各フィルタオブジェクトに対応してスレッドを生成し、並行して動作するスレッドの実行コンテクストでフィルタオブジェクトのrunメソッドを実行する。即ち、コンストラクタのパラメータにフィルタオブジェクトを渡してJava.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の指すPipedOutputStreamオブジェクトへwriteする。
【００９４】
パイプオブジェクト５０４は、パイプクラス４０５のオブジェクトである。このパイプオブジェクト５０４は、PipedOutputStreamオブジェクトとPipedInputStreamオブジェクトとを接続された状態で持つ。パイプオブジェク５０４が持つPipedOutputStreamオブジェクトのwriteメソッドの呼び出しによってデータストリームはそのPipedOutputStreamオブジェクトへ引き渡される。そして、パイプオブジェクト５０４が持つPipeInputStreamオブジェクトのreadメソッドの呼び出しによって、PipeInputStreamオブジェクトからデータストリームとして読み出すことができる。
【００９５】
フィルタ２オブジェクト５０５は、フィルタ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ２オブジェクト５０５の入力属性にはパイプオブジェクト５０４が持つPipedInputStreamの参照が保持されており、inputの指すパイプオブジェクト５０４からreadしたデータストリームに対してフィルタ処理を施す。また、このフィルタ２オブジェクト５０５の出力属性にはコネクタオブジェクト５０１が持つConnectorOutputStreamの参照が保持されている。フィルタ処理が施されたデータストリームは、outputの指すConnectorオブジェクト５０１が持つConnectorOutputStreamへwriteされる。
【００９６】
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。また、同様にして間にパイプオブジェクト５０４を挟みこみながら、より多くのフィルタオブジェクトをデータストリーム処理のために配置することもできる。
【００９７】
図７（Ａ）〜（Ｃ）は、本実施の形態に係るフィルタフレームワーク２１９を操作するためのユーザインターフェース例を説明する図である。このフィルタフレームワークを操作するためのユーザインターフェースは、標準ライブラリとフレームワーク２１７（図１）に含まれるＨＴＴＰサービスによってウエブ（Ｗｅｂ）アプリケーション（Servlet）として実装されている。このユーザインターフェースは、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の操作パネル１９から操作するように構成してもよい。
【００９８】
図７（Ａ）は、この実施の形態の画像処理装置１０００のフィルタフレームワーク２１９に新しいフィルタ２２１をインストールして追加するためのユーザインターフェースを示している。このフィルタインストール画面６０１は、ファイル名入力フィールド６０２、参照ボタン６０３及びインストールボタン６０４を備えている。
【００９９】
ユーザは、クライアントコンピュータのファイルシステムに予め格納されているインストールしたいフィルタクラス４０２のクラスファイルのファイルパスを、ファイル名入力フィールド６０２に入力する。
【０１００】
ユーザが、参照ボタン６０３をクリックすると、クライアントコンピュータのＷｅｂブラウザが提供するファイル選択ダイアログがオープンされる。ユーザは、このファイル選択ダイアログによりクライアントコンピュータのファイルシステム内をブラウズして、インストールしたいフィルタクラス４０２のクラスファイルを選択できる。このファイル選択ダイアログによってユーザが選択したファイルのファイルパスは、自動的にファイル名入力フィールド６０２に入力される。
【０１０１】
次にユーザによるインストールボタン６０４のクリックが検出されると、指定されたフィルタが新規フィルタインストールのためのＷｅｂアプリケーションに送信される。即ち、クライアントコンピュータのＷｅｂブラウザによって、ファイル名入力フィールド６０２に入力されたファイルパスのクラスファイルが、この画像処理装置１０００で待機している新規フィルタインストールのためのＷｅｂアプリケーションに送信される。こうしてクラスファイルを受信したＷｅｂアプリケーションは、この画像処理装置１０００の不揮発性メモリ３に、その受信したクラスファイルを格納する。また、そのクラスファイルをインタプリタ環境２１５に動的にロードしてオブジェクトインスタンスを生成する。そして、その生成したフィルタオブジェクトを、フィルタフレームワークランタイムが管理する有効フィルタ列のリストの最下流に配置する。尚、このとき、既に有効なフィルタオブジェクトがフィルタ列に存在すれば、新規のフィルタオブジェクトを連結するために新たなパイプオブジェクトが生成される。
【０１０２】
このようなユーザインターフェースをＷｅｂアプリケーションとして実装している場合には、フィルタの実装クラスの装置１０００へのアップロードは、ＲＦＣによって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用している。従って、この場合、ファイル名入力フィールド６０２と参照ボタン６０３はクライアントコンピュータのＷｅｂブラウザによって表示されており、インストールボタン６０４はフォームのsubmitに対応している。
【０１０３】
また、このユーザインターフェースをApplet型のサービスとして実装する場合には、この画面６０１は、画像処理装置１０００の操作パネル１８の表示部に表示される。ファイル名入力フィールド６０２で指定されるファイルは、画像処理装置１０００がリムーバブル記憶メディアを備える場合は、そのリムーバブル記憶メディア中のファイルパスを指定しても良い。或は、ネットワーク経由で画像処理装置からＨＴＴＰやＦＴＰ等のファイル転送プロトコルによって読み出しアクセス可能な共有ファイルを、ＵＲＬなどによって指定してもよい。
【０１０４】
図７（Ｂ）は、本実施の形態に係る画像処理装置１０００のフィルタフレームワーク２１９にインストールされているフィルタを配置するためのユーザインターフェースを説明する図である。
【０１０５】
このフィルタ配置画面６０５において、表６０６は、フィルタフレームワーク２１９のランタイムにインストールされているフィルタ群を一覧表示している。この表６０６の各行は、インストールされているフィルタのそれぞれに対応している。また、この表６０６の「選択」列にはチェックボックスが並んでおり、ここでチェックされた行のフィルタが後述する操作の対象として選択される。表６０６の「順序」列には、そのフィルタが無効状態にある場合には「無効」が表示される。また有効状態にある場合には、そのデータストリーム処理の上流から下流に向かって昇順に付された番号が表示される。そして表６０６の「名称」列には、そのフィルタオブジェクトのname属性に記述されたフィルタ名称が表示される。
【０１０６】
６０７〜６１１は、選択されたフィルタに対する操作を指示するためのボタンであり、表６０６の選択列でチェックされた行のフィルタを対象とする操作を指示する。ユーザが、詳細表示ボタン６０７をクリックすると、表６０６で選択されたフィルタに関する詳細情報が表示される。この詳細情報としては、フィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名（ファイルパスやＵＲＬ）、インストールされた日時などがある。
【０１０７】
上へボタン６０８がクリックされると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の上流方向に一段階だけアップする。一方、下へボタン６０９がクリックされると、選択されたフィルタのフィルタ列内における順序が、データストリーム処理の下流方向に一段階だけダウンさせる。有効／無効のトグルボタン６１０がクリックされると、選択されたフィルタが有効状態にある場合は無効状態に変更され、無効状態にある場合には有効状態に変更される。無効状態にされたフィルタオブジェクトは削除されるが、フィルタクラス４０２はインストールされた状態で残って、フィルタフレームワークランタイムの管理下に留まる。アンインストールボタン６１１がクリックされると、選択されたフィルタのクラスファイルを画像処理装置１０００のインタプリタ環境から削除する。決定ボタン６２１がクリックされると、当該設定画面６０５によって設定されたフィルタ配置が決定される。
【０１０８】
図７（Ｃ）は、フィルタがデータストリームを対象としたものかを選択するユーザインターフェース例を示す図である。
【０１０９】
フィルタインストール画面６０１やフィルタ配置画面６０５を表示する前段階で、この対象データストリームの選択画面６１２を表示してユーザに選択させることにより、ユーザがフィルタ処理に関するインストールや設定を望むデータストリームを決定できる。
【０１１０】
リスト６１３は、画像処理装置１０００内に存在するデータストリームをリスト形式で選択するためのユーザインターフェースである。フィールド６１４は、リスト６１３から選択されたデータストリームを表示する。決定ボタン６１５は、フィールド６１４で指定されているデータストリームに対するフィルタのインストールと、管理を行うように決定するためのボタンである。このボタン６１５が押下されると、該当するデータストリームのフィルタインストール画面６０１やフィルタ配置画面６０５が表示される。
【０１１１】
尚、フィルタの処理対象となるデータストリームを選択する方法は上記に限られるものではない。例えば、フィルタ抽象クラス４０２にフィルタ属性を設け、フィルタのインストールやフィルタの管理時にフィルタ属性を参照することにより、フィルタ対象データストリームを特定するようにしても良い。以上のようなユーザインターフェースにより、入力データストリーム（処理要求データストリーム）や所望の中間データストリームに対して１つ又は複数のフィルタを配置することができる。又、このようにして配置されたフィルタ（或はフィルタの組み合わせ）は、図４に示されるようにレイヤＩ／Ｆ２１１を介して中間データストリームのデータパス中に配置されたことになる。
【０１１２】
又、図１７により上述したように、本実施形態では、中間データストリームに対して配置されたフィルタ（或はフィルタの組み合わせ）に関して、適用すべき「ＰＤＬ種別」や「ジョブ種類」を設定できる。例えば、図７の（Ｂ）に示される適用条件ボタン６２０が押下されると、図１８に示すユーザインターフェースが提示される。図１８では、対象データストリームが「描画データストリーム」となっており、図７（Ｃ）の対象データストリームの選択において「描画データストリーム」が選択され、図７（Ｂ）において適用条件ボタン６２０が押下された場合の表示例が示されている。図１８において、ＰＤＬ種別設定リストボックス１５０１やジョブ種類設定リストボックス１５０２において、当該フィルタ（或はフィルタの組み合わせ）を適用すべきＰＤＬ種別やジョブ種類を設定する。そして、決定ボタン１５０３をクリックすることにより、その設定内容が確定される。この場合、処理要求データストリームがここで設定されたジョブ種類とＰＤＬ種別を持つ場合に、当該処理要求データストリームに含まれる描画データストリームが図７の（Ｂ）によって配置されたフィルタの処理を受けることになる。
【０１１３】
尚、上記ではフィルタ処理を適用するか否かをＰＤＬ種別やジョブ種類により判断するが、これらは一例であり、これに限られるものではない。
【０１１４】
図８は、本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。
【０１１５】
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワーク２１９が管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で実行される。
【０１１６】
まずステップＳ１で、必要な前処理を行う。この前処理には、フィルタ２２１が内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力／出力ストリームをより使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。ここで、入力／出力ストリームをより使いやすくする機能としては、例えば入力ストリームを先読み可能にしたり、システムリソースを有効に利用するためにバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次に、ステップＳ２で、入力属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。そしてステップＳ３で、入力したデータストリームから、このフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。このフィルタが操作するべきデータパターンは、固定のデータ列そのものでも良く、或は正規表現（regular expression）等の形式言語による記述でもよい。尚、パターン記述に合致するデータの出現をデータストリーム中から発見するための各種の実装は広く知られており、例えばgrep、sed、AWK、Perlなどが有名である。
【０１１７】
パターンマッチングを効率良く行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較し、ハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Knuth-Morris-Prattの方法や、Boyer-Mooreの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のＪａｖａ（登録商標）プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる（Java.util.regex）。尚、例えばデータストリームの上流のパターンに応じて状態が変化し、その変化した状態に従って下流のパターンの解釈を変えなければならない場合であって、正規表現等では却って記述が困難なほど複雑なパターンマッチングが必要とされる場合がある。そのような場合には、そのパターンの特徴そのものを評価するアルゴリズムをＪａｖａ（登録商標）プログラムとして書き下してもよい。このようにして、どれほど複雑なパターンマッチングであっても素直に実装することができる。
【０１１８】
次にステップＳ４で、パターンマッチングの結果を判定し、パターン記述に合致するデータをデータストリーム中に発見した場合はステップＳ５に進むが、そうでなければステップＳ６に進む。ステップＳ５では、パターン記述に合致したデータストリームの部分データ列に対してこのフィルタの目的に応じた操作を施し、その結果で置き換える。次にステップＳ６で、処理済の部分データ列（即ち、監視しているパターンが現れなかったデータ列、或は、監視しているパターンを含むデータ列に対してステップＳ５の処理を施したデータ列）を出力ストリームに書き込む。そしてステップＳ７で、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了するが、そうでなければステップＳ２に戻って、上記の手順を繰り返す。
【０１１９】
図９は、本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。
【０１２０】
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で動作することになる。
【０１２１】
まずステップＳ１１で、必要な前処理を行う。この前処理には、フィルタが内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力／出力ストリームを、より使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。尚、入力／出力ストリームを、より使いやすくする機能としては、例えば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、例えば、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次にステップＳ１２で、新たな部分データストリームを生成する。次にステップＳ１３で、入力属性にセットされている入力ストリームから、予め定められた量のデータを読み出す。そしてステップＳ１４で、その読み込まれたデータストリームに対して、ステップＳ１２で生成された部分データ列を追加する。次にステップＳ１５で、処理済の部分データ列を出力ストリームに書き込む。そしてステップＳ１６で、入力ストリームに存在する残りデータを出力ストリームに書き込む。
【０１２２】
図１０は、本実施の形態に係る処理要求データストリームを説明する図である。
【０１２３】
８０１は処理要求データストリームを示している。クライアントからの、この画像処理装置１０００に対する処理の要求は、クライアントが処理要求データストリーム８０１を作成して画像処理装置１０００に送信することにより行われる。そして、要求された処理の実行は画像処理装置１０００が、その処理要求データストリーム８０１を処理することで実行される。この処理要求データストリーム８０１は、大きく装置制御指示データストリーム８０２（図３の３５１に相当）と描画データストリーム８０３（図３の３５２に相当）に分けることができる。
【０１２４】
装置制御指示データストリーム部８０２では、この画像処理装置１０００への、描画以外の処理要求に関する指示が記述されている。具体的には、以下のような指示を行うことが一般的に知られており、画像処理装置１０００が備える機能により規定されている。１行目の「ジョブ種類」の属性は、「印刷」、「セキュアプリント」、「画像取得」等の値を取り得るもので、この画像処理装置１０００が備える各種ジョブのタイプを表している。「画像取得」等のように描画指示を行わない処理要求の場合は、描画データストリーム８０３は一般的には、このような処理要求データストリーム８０１に含まれない。２行目の「部数」の属性は、印刷物のコピーを何セット生成するかを表している。３行目の「ページレイアウト」の属性は、ページレイアウト指定を表している。ページレイアウト指定には、「１ページ／枚」「２ページ／枚」「４ページ／枚」などのように、１枚の用紙に複数ページを面付けするための指定が含まれる。更に、ページレイアウト指定には、「ポスター（２×２）」、「ポスター（３×３）」などのように、１ページを拡大して複数枚の用紙に分割して印刷する指定も含まれる。４行目の「配置順」の属性は、「左上から右向き」、「左上から下向き」、「右上から左向き」、「右上から下向き」等の値を取り、ページレイアウト時の各面の配置指定を表す。５行目の「印刷方法」の属性は、「片面印刷」、「両面印刷」、「製本印刷」等の値を取り、これにより印刷方法を表す。６行目の「とじ方向」の属性は、「長辺とじ（左）」、「長辺とじ（右）」、「短辺とじ（上）」、「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。７行目の「排紙方法」の属性は、「指定しない」、「ソート」、「ステイプル」、「パンチ穴」などの値をとり、フィニッシングの方法を表す。８行目の「給紙」属性は、「自動」、「手差しトレイ」、「カセット」、「デッキ」、或は「普通紙」、「厚紙」、「色紙」、「ＯＨＰ」などの値をとり、画像形成の対象とする用紙（転写紙）の給紙指定を表す。９行目の「使用ＰＤＬ」は、処理要求内容が描画指示である場合に使用され、描画データストリームに使用されるＰＤＬの種別を表している。
【０１２５】
描画データストリーム部８０３は、処理要求内容が描画指示である場合に使用され、描画データストリームは一般的にはＰＤＬで構成される。
【０１２６】
図１１は、本実施の形態に係る描画データストリーム８０３に対するフィルタが行う処理を説明する図である。
【０１２７】
互換化フィルタ９０１は、この描画データストリーム８０３のフィルタクラスのオブジェクトを示し、入力データストリームに現れる描画データストリーム８０３における互換性の問題を解決する処理を施して出力ストリームに書き込む。この描画データストリーム８０３における互換性の問題として、ここでは代表的なＰＤＬの一つであるAdobeのPostScript仕様を、各社ベンダが実装した画像処理装置間におけるベンダごとの解釈の差異に基づく問題と、その解決の例を説明する。
【０１２８】
あるベンダの画像処理装置は、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「setpagedevice」で「/DeferredMediaSelection」が真のときカスタム用紙扱いとして用紙要求をパネルに表示する。一方、偽の場合には、指定されたサイズから±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。また別のベンダの画像処理装置では、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「/DeferredMediaSelection」が真の場合は、指定されたサイズそのもののサイズ（範囲なし）で定型用紙を検索し、定型にない場合はカスタム用紙扱いとする。一方、偽の場合には、±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。
【０１２９】
ここで、更に別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、上記の内の後者の解釈に基づく挙動を前提として構築されたとする。すると、印刷要求に対して前者の画像処理装置では、カスタム用紙扱いとなってしまい、「用紙なし」が操作パネルに表示されて印刷されない。従って前者の画像処理装置のベンダは、この互換性の問題に対して、できるだけ低コストでかつ速やかに解決することが求められる。このような要求に対しては、印刷要求データストリームに現れるsetpagedeviceの「/DeferredMediaSelection」パラメータを真（true）から偽（false）に変換することで、少なくとも暫定的に応えることができる。互換化フィルタ９０１は、このような問題を解決するために働くフィルタオブジェクトである。即ち、互換化フィルタ９０１は、入力データストリームから「/DefereedMediaSelection」が真（true）で指定されたsetpagedeviceに対するパターンマッチングを行い、マッチした場合は、偽（false）に置き換えた力データストリームを出力する。
【０１３０】
９０２はフィルタへの入力データストリームの一例である、PostScriptのプリントデータである。２行目にパターンに合致する部分データが出現する。９０３は、入力データストリーム９０１がフィルタによりフィルタ処理されて出力された出力データストリーム例を示し、フィルタ処理されたPostScriptのプリントデータで示されている。この出力データストリーム９０３では、２行目のデータの中で「true」という文字列が「false」へ変更されている。
【０１３１】
図１２は、本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。
【０１３２】
上記の図１１の例では、画像処理装置間の仕様の差異に基づく互換性の問題を解決するために、フィルタによるデータストリームのパターンマッチングと置換の技術を用いた。図１２の例では、同様の技術を、画像処理装置の実装の不具合（ファームウェアのバグなど）を緊急回避するために用いている。例えば、ある画像処理装置のあるバージョンのリリースにおいて、ＬＩＰＳ（登録商標）言語の「イメージ領域確保命令（VDM）」に指定されるイメージの幅が８の倍数でなければ描画不正が発生するというバグがあったとする。
【０１３３】
１００１は障害回避フィルタを示し、例えば、ＬＩＰＳ（登録商標）データストリーム１００２から障害を発現させるパターンを発見し、その障害を顕在化させず同等の機能を達成するためにデータストリームに変換する。例えば、障害回避フィルタ１００１は、データストリーム１００２から障害を発現させるパターンを発見（VDMのイメージ幅が「２２５」であり８の倍数でない）する。そして、発見されたパターンをVDMのイメージ幅を８の倍数に変換する（ここでは、「２２５」より大きい値である「２３２」）に変換する。
【０１３４】
図１３は、本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。
【０１３５】
最適化フィルタ１１０１は、描画データストリームに対する最適化フィルタクラスのオブジェクトを示す。最適化フィルタ１１０１は、入力ストリームを読み出してデータストリーム中に現れる冗長に記述されたＰＤＬデータを発見し、それをより効率の良い同機能のデータに変換して出力ストリームに書き込む。画像処理装置のドライバが生成するＰＤＬデータストリームは、クライアントのプリント要求システムやアプリケーション側の都合によって、どうしても繰り返しなどの冗長な処理がパターンを含む傾向にある。このような冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換える。
【０１３６】
１１０２は、フィルタ１１０１に入力される入力データストリームの一例を示す。この入力ストリーム１１０２では、１１０３で示すように、横長の長方形を塗りつぶすために３つの正方形の塗りつぶしを繰り返すように記述されている。１１０４は、この最適化フィルタ１１０１からの出力データストリームの一例を示している。ここではフィルタ１１０１は、冗長な繰り返しパターンを検出し、それを等価な１つの横長の矩形の塗りつぶし１１０５に書き換えている。
【０１３７】
図１４は、本実施の形態に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。
【０１３８】
１２０１は、装置制御指示データストリーム３５１に対する機能拡張フィルタクラスのオブジェクト例を示している。機能拡張フィルタ１２０１は、入力データストリーム１２０２を読み出して、その入力データストリームに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力データストリームに書き込む。ここでは、機能拡張の例として、以下の例を挙げる。即ち、顧客システムが専用のＰＤＬドライバを抱えていてそのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応であるとする。そのような場合に、そのドライバを変更することなく画像処理装置側のフィルタ対応によって装置の新機能を活かす。
【０１３９】
機能拡張フィルタ１２０１は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための装置制御指示設定をその属性として持つ。フィルタオブジェクトの属性値は、装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。具体的には、前述のように画像処理装置が備える機能により規定されている。
【０１４０】
入力データストリーム１２０２は、印刷データストリームの機能拡張フィルタ１２０１に入力されるデータストリームである。このデータストリーム１２０２は、旧来のアプリケーションが生成し、画像処理装置１０００によって受信された処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム３５１である。或は、このデータストリーム１２０２は、画像処理装置１０００のドライバが生成する処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム３５１である。
【０１４１】
出力データストリーム１２０３は、この装置制御指示データストリームの機能拡張フィルタ１２０１が逐次処理を行って出力するデータストリームを示す。入力データに存在した単純な処理要求データストリームに加えて、画像処理装置１０００の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において、機能拡張フィルタ１２０１の属性のような各種属性の指定が可能である。
【０１４２】
この出力データストリーム１２０３において、１行目の「JobStart」はジョブの開始を表す。２行目の「SetJob」は、ジョブ単位の設定の開始を表す。３行目の「ジョブ設定データ」は、この位置に各種のジョブ単位の設定データが存在することを示す。４行目の「BinderStart」は、複数文書をひとまとめにする単位の開始を表す。５行目の「SetBinder」は、複数文書をまとめた単位に対する設定の開始を表す。６行目の「文書束設定データ」は、この位置に複数文書をまとめた単位に対する設定データが存在することを示す。７行目の「DocumentStart」は文書の開始を表すデータである。８行目の「SetDocument」は、文書単位の設定の開始を表す。９行目の「文書設定データ」は、この位置に文書を単位とする設定データが存在することを示す。
【０１４３】
図１５は、機能拡張フィルタ１２０１を操作するためのユーザインターフェース例を示す図である。
【０１４４】
フィルタ操作のためのユーザインターフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによって、Ｗｅｂアプリケーション（Servlet）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の持つ操作パネル１８から操作するように構成してもよい。
【０１４５】
１３０１は、機能拡張フィルタ１２０１の基本操作画面を示し、この画面を使用して、フィルタオブジェクト属性の確認や変更など操作できる。１３０２は、ジョブ種類の属性を操作するのに使用される。１３１２は、部数属性を設定するのに使用される。１３０３は、ページレイアウト属性を設定するのに使用される。１３０４は、配置順の属性を設定するのに使用される。１３０５は、印刷方法の属性を設定するのに使用される。１３０６は、とじ方向の属性を設定するのに使用される。１３０７は、排紙方法の属性を設定するのに使用される。１３０８は、給紙属性を設定するのに使用される。ヘルプボタン１３０９は、このフィルタの使い方、機能、属性の意味などの説明を表示するのに使用される。「標準に戻す」ボタン１３１０は、各種属性をデフォルト値に戻す場合に指示される。適用ボタン１３１１は、属性値の変更操作が適用され、新しい値を実際にフィルタオブジェクトの属性として設定するために使用される。１３１３はプレビューアイコンを示し、各種属性を画面上で確認するために、いくつかの重要な属性についてその値の状態に応じた模式図が表示される。
【０１４６】
以上説明したように本実施の形態１によれば、以下のような効果がある。
（１）プリント要求受信サーバをファームウェアとして静的に実装し、その受信サーバで受信したデータストリームを、組み込みＪａｖａ（登録商標）環境上に実装した動的ロードや動的リンク可能なフィルタソフトウェアに引き渡すインターフェースを設けた。これにより、安定部分と動的部分を明確に分離できるため、装置のファームウェア全体を動的で冗長なソフトウェアに置き換えるといった非効率な処理や、Ｊａｖａ（登録商標）環境側に実装して二重に持ってしまうといった非効率も防止できる。これにより、コスト面でも、また開発の負荷の面でも合理性のあるフィルタフレームワークが実現できた。更に、納入済みの装置に対するフィルタの動的な追加や置き換えを容易にできるため、低いサポートコストでより迅速に顧客のニーズに対処できる。
（２）より洗練されたＪａｖａ（登録商標）環境でフィルタを実装するため、通常、組み込みシステムでは困難な動的なメモリ管理が有効な高度なパターンマッチングアルゴリズムを容易に実装できる。また高度にモジュール化された再利用性の高いソフトウェアとして設計するため、オブジェクト指向パラダイムに基づくデザインパターンを容易に採用できる。その結果、生産性の高いフィルタ部の実装を実現できる。
（３）フィルタにより、パターンマッチングを用いて、入力データストリームから他の実装との互換性点で問題となるＰＤＬデータを発見し、そのＰＤＬデータを適正に変更することができる。これにより、互換性の問題や障害を低コストで解消できた。特に、顧客環境におかれたシステムや、アプリケーションや画像処理装置のドライバに影響を及ぼすことなく、画像処理装置側に閉じた対応だけで達成できる。また、フィルタを配置しない場合には、フィルタフレームワークが介在することによるオーバヘッドを回避できる構成であるため、フィルタを配置しない場合にも画像処理装置本来のデータ処理性能を維持できている。
（４）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタで、冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換えることができる。このため、ＰＤＬの処理システムの主要部には全く影響を与えずに印刷処理のパフォーマンスを改善できる。又、画像処理装置側で閉じて最適化処理を行うので、顧客環境のシステムやアプリケーションや画像処理装置ドライバを改造する必要もない。またフィルタの生産性が高く、インストールなどのメンテナンスも容易であるため、各顧客の利用形態に即した最適化を行うことができる。
（５）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタに、新機能を活かすために必要なデータを追加することで画像処理装置の新機能が利用可能となる。このため、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能となる。
（６）Ｊａｖａ（登録商標）環境がファームウェアの更にもう一層のソフトウェアプラットフォームとして、そのファームウェアで動作するフィルタのために、追加機能の設定を操作するためのユーザインターフェースをフィルタに設けた。これにより、顧客の利用形態に即して個別対応した機能拡張が提供できる。
（７）フィルタ処理を、装置の制御に関する指示命令で構成される装置制御データストリーム部、ＰＤＬなど描画に関する指示命令で構成される描画データストリーム部のそれぞれに対して最適なフィルタ処理が可能となった。
（８）夫々のデータストリーム処理の際に、データストリーム属性管理モジュール２２８を介することで、データストリーム処理を行うモジュールは、他のデータストリームで抽出された情報を用いてフィルタリング処理の適用を決定することが可能となった。具体的には、JL(Job Language)と呼称される装置制御データストリームに記載されている、ジョブ種類や、ＰＤＬ種別に従って、描画データへのフィルタ処理の適用することが可能となった。
【０１４７】
［実施の形態２］
図１６は、本発明の実施の形態２に係る送信用データストリーム１４０１を説明する図で、この実施の形態２に係るハードウェア構成及びソフトウェア構成は前述の図１〜図４と同じであるため、その説明を省略する。
【０１４８】
クライアントからの処理要求に応じて、画像処理装置１０００は、クライアントが指定した先へ画像データなどを送信する。その際、画像処理装置１０００は、この送信用データストリーム１４０１を生成し、データ送受信モジュール２０２より送信する。送信用データストリーム１４０１は、送信用データストリームのジョブ種類を記載しているデータストリーム部１４０２と、画像データストリーム１４０３に大別できる。このデータストリーム部１４０２には、画像データそのもの以外の情報が記述されている。このデータストリーム部１４０２のフォーマットは、画像処理装置１０００が備える機能により規定されている。このデータストリーム部１４０２は、データ送信処理を行う際に、ジョブ制御モジュール２０５、或は組み込みアプリケーション２０３により画像データに付加され、送信用データストリームとしてデータ送受信モジュール２０２から送信される。画像データストリーム部１４０３は、画像読み取り部１９から入力されたスキャン画像データストリーム３６０（図３）が画像処理モジュール２０９で処理されることで生成される。尚、ここで送信用データストリーム１４０１、データストリーム部１４０２、画像データストリーム１４０３は前述のように、それぞれフィルタ処理が可能である。
【０１４９】
以上説明した実施の形態２によれば、画像処理装置内に存在するスキャン画像データストリーム３６０、画像データストリーム、送信用データストリーム３５９のそれぞれに対して最適なフィルタ処理が可能となった。
【０１５０】
［他の実施の形態］
上記以外の画像処理装置内に存在するデータストリームとしては、ＰＤＬが処理されることで生成されるディスプレイリスト３５５、画像処理装置において最終的に生成される最終画像データストリーム３５７、最終画像データストリーム３５７を生成するために生成される中間画像データストリーム３５６などがある。それぞれのデータストリームは、画像処理装置が備える機能により形式が規定されている。前述と同様の構成により、それぞれのデータストリームに対して最適なフィルタ処理を行うことができる。
【０１５１】
又、印刷データストリーム中の制御データでなく、印刷対象の文字データ列を扱うようにフィルタを構成してもよい。例えば、印刷対象の文字データ列中から特定の文字列パターンの出現を発見し、特定の文字列パターンに合致した場合に、その文字列に相当する制御データを生成して置換または挿入するような機能拡張フィルタを構成することもできる。例えば、顧客がワードプロセッサのようなアプリケーションを使用してテキストとして入力し、それを画像処理装置の通常のドライバ経由でプリントする際に、特定の文字列をベクタ描画命令などに変換するようにしてもよい。この場合、画像処理装置側のフィルタにおいて、例えば特定文字列を、それに対応する画像（ロゴやマークや透かしなど）を描画するためのベクタ描画命令などの命令列に変換するように構成することができる。
【０１５２】
上記実施の形態では、ファームウェア内部のインタプリタ環境としてＪａｖａ（登録商標）の仮想マシン環境を用いたが、本発明はこれに限定されるものではない。他のスクリプト言語などのインタプリタ環境をファームウェアに組み込んで構成した場合であっても、動的なフィルタ追加とファームウェア部分の分離など同様の効果が得られる。
【０１５３】
また、オブジェクト指向など高効率の開発を可能とするインタプリタ環境は他にも多く存在し、これらを用いてもフィルタ生産性など同様の効果が得られる。特にパターンマッチングに基づくデータストリームの処理に関しては、ｓｅｄ，ＡＷＫ，Ｐｅｒｌなどの選択肢も適している。
【０１５４】
［他の実施形態］
以上、本発明の実施の形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、または一つの機器からなる装置に適用しても良い。
【０１５５】
なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１５６】
プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０１５７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１５８】
またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１５９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１６０】
【図１】本実施の形態に係る画像処理装置のハードウェア構成を説明するブロック図である。
【図２】本実施の形態に係るコントローラのソフトウェア構造を説明する階層図である。
【図３】本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、各モジュールにおいて存在するデータストリームを示す図である。
【図４】本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。
【図５】本実施の形態のインタプリタ環境に構築されるフィルタフレームワークのクラスを説明する図である。
【図６】本実施の形態のインタプリタ環境に構築されるフィルタフレームワーク２１９が管理するオブジェクトのインスタンス図で、図６（Ａ）は、１つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示し、図６（Ｂ）は、２つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。
【図７】本実施の形態に係るフィルタフレームワークを操作するためのユーザインターフェース例を説明する図である。
【図８】本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。
【図９】本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。
【図１０】本実施の形態に係る処理要求データストリームを説明する図である。
【図１１】本実施の形態に係る描画データストリームに対するフィルタが行う処理を説明する図である。
【図１２】本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。
【図１３】本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。
【図１４】本実施の形態１に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。
【図１５】機能拡張フィルタを操作するためのユーザインターフェース例を示す図である。
【図１６】本発明の実施の形態２に係る送信用データストリームを説明する図である。
【図１７】本発明の実施の形態におけるデータストリーム属性管理モジュールによる、フィルタ適用の可否を決定するための処理を示すフローチャートである。
【図１８】フィルタ適用条件を設定するためのユーザインターフェース例を示す図である。
【技術分野】
【０００１】
本発明は、ファームウエア等が動作するネイティブ環境と、そのネイティブ環境において動作するインタプリタ環境とを用いた情報処理技術に関する。
【背景技術】
【０００２】
従来、例えば複写機やＭＦＰ（マルチファンクションプリンタ）などの画像処理装置で画像処理を実行するソフトウェアは、オペレーティングシステム（ＯＳ）の上に静的かつ固定的な、いわゆるファームウェアとして構築されることが主流であった。このようなファームウェアは、内部的に複数のモジュールから構成されている場合でも、全体が単一のロードモジュールに静的にリンクされた状態で装置の不揮発性メモリに記憶される。そして、システムの起動時にハードディスクなどの不揮発性メモリからＲＡＭにロードされて実行されるか、又はそのファームウェアを記憶しているＲＯＭなどの不揮発性メモリ上で直接実行される。特に低価格の画像処理装置のように、組み込みシステムを構成するファームウェアは一般に、その経済性や安全性等のために、部分的なモジュールの動的なロードやリンクを行わないように構成されている。即ち、ダイナミックリンクを実現するために必要なシンボルテーブルを記憶するためのメモリ容量や、シンボルのアドレスへアクセスするための処理に関するオーバヘッドなどが、装置のコストパフォーマンスを悪化させる。また、サブモジュールの追加ロード及びリンクによって、そのサブモジュールをリンクする以前には十分に評価され達成されていたシステム全体の品質やセキュリティが脅かされる危険があるためである。
【０００３】
上記の問題を解決するために、組み込みシステムのファームウェアのリアルタイムＯＳ上に更にもう一層のソフトウェア動作環境を設けた画像処理装置が開発されている。このもう一層の追加のソフトウェア動作環境において、ダイナミックローディングやダイナミックリンキングや動的なメモリ操作などのソフトウェアの動的な特性がサポートされる。追加のソフトウェア動作環境は、インタプリタと一揃いのアプリケーションプログラミングインターフェース（ＡＰＩ）群やフレームワーク群から構成され、その上で動作するソフトウェアのために一種のＯＳ或はコンピューティングプラットフォームを提供する。インタプリタは、所定の命令セットに含まれる命令からなる一連の命令列を逐次的に読み出し解釈し実行する。この命令セットをＣＰＵのための命令セットと同等の位置付けで捉える場合、インタプリタは特に仮想マシン（virtual machine）と呼ばれることもある。一揃いのＡＰＩ群及びフレームワーク群は、このソフトウェア動作環境の下層にある実際のリアルタイムＯＳが提供する資源やハードウェア資源を抽象化した各種の資源群に対するアクセスを、ソフトウェア動作環境上で動作するソフトウェアのために提供する。これら資源には、プロセッサによる命令実行コンテクストやメモリ、ファイルシステム、ネットワークインターフェースを含む各種入出力（Ｉ／Ｏ）などがある。特に命令実行コンテクストは、ＣＰＵとリアルタイムＯＳが提供するマルチタスク機構とは独立に、ソフトウェア動作環境が独自にインタプリタ上の命令実行コンテクストを管理できる。また、メモリの管理も同様にソフトウェア動作環境が独自のメモリ管理を提供できる。
【０００４】
このようなソフトウェア実行環境上で動作するソフトウェアは、インタプリタによって逐次的に読み込まれて解釈されて実行されるため、これらの処理の過程で命令列を監視しシステムに悪影響を与える動作を除外できる可能性がある。また、ソフトウェア実行環境上で動作するソフトウェアからの各種資源に対するアクセスは、そのソフトウェア実行環境が提供するＡＰＩ群やフレームワーク群を経由して間接的に行われる。このため、ファームウェア内部にインタプリタ及びＡＰＩ群とフレームワーク群からなるソフトウェア実行環境の階層を設けるアプローチは、このアクセスの過程で、システムに悪影響を与える動作を除外できる可能性がある。従って、このようなアプローチは、静的かつ固定的に構成されるべき低コスト組み込みシステムのファームウェアにおいて、ソフトウェアの動的な特性を部分的に導入するために非常に有効である（特許文献１、特許文献２）。
【０００５】
上記アプローチにおいて、ソフトウェア実行環境の階層を実現するためにインタプリタとしてＪａｖａ（登録商標）仮想マシンを採用し、Ｊａｖａ（登録商標）に関連するＡＰＩ群やフレームワーク群を採用することができる。本出願人は２００３年に、画像処理装置のファームウェア内部にＪａｖａ（登録商標）プラットフォームを内蔵した複合機を製品化している。
【０００６】
従来、ネットワークコンピュータを備えたアプリケーションダウンロード型プリンタを用い、コンピュータネットワークから、印刷すべきデータファイルと、そのデータファイルに対応したアプリケーションとをプリンタにダウンロードすることが行われている。そして、そのダウンロードしたアプリケーションを立ち上げて実行することにより、データファイルを開いてラスタイメージに変換し、それを印刷するネットワークコンピュータ内蔵型プリンタが知られている。またこの場合のアプリケーションとして、「Ｊａｖａ（登録商標）アプレット」を用いることも開示されている。このアプリケーションは印刷データファイルとともにクライアントからプッシュされる場合も、プリンタがアプリケーションサーバなどからプルすることも開示されている（特許文献３）。
【０００７】
特許文献４には複数の周辺機器及び周辺機器を動作させるソフトウェアを搭載した複数の端末装置、及び少なくとも周辺装置を動作させるソフトウェアに関するデータベースを備えたサーバ装置を伝送路に接続させたネットワーク通信システムが提案されている。このネットワーク通信システムにおいては、伝送路に接続された周辺機器、端末装置、サーバ装置の間で所定の通信プロトコルに基づいてネットワーク通信が行われる。ここで、周辺機器は、クライアント制御部と、ソフトウェア配信エージェントを備える。クライアント制御部は、サーバ装置から周辺機器を動作させるためのソフトウェアの全部／一部、或はソフトウェアが使用するモジュールに対応する最新モジュール情報を要求・獲得する。また、ソフトウェア配信エージェントは、獲得した最新モジュールを端末装置に配付する。そして、特許文献４によれば、この場合の周辺機器を操作するソフトウェアが使用するクライアント側モジュールとして、「Ｊａｖａ（登録商標）アプレット」や「Ｊａｖａ（登録商標）アプリケーション」が供給可能であることも開示されている。
【０００８】
一方、基幹系の業務システムでは、一度、正常に稼働し始めたシステム全体の安定性を維持したいという要望はとても強く、プリンタドライバやアプリケーションの変更やバージョンアップなどの変更が簡単に許されない場合がある。このような現実のプリンティング環境の制約の中で、プリンタのベンダは顧客側に対応を求めるのではなく、プリンタ側の対応によって各種の顧客要望に応えるべき使命がある。このためには、プリンタ／プリンタコントローラを構成するファームウェアを改造して各顧客に対応してリリースする方法がある。しかし、ファームウェアの改造による各顧客への対応は、装置の開発期間や開発費などが多くかかり、またファームウェアの更新にはフィールドエンジニアなどによる高度なメンテナンスの手間を要する。このため、各顧客の要望に速やかに応えるには、費用対効果の面でも課題を残している。
【０００９】
組み込みシステムのファームウェアに、例えばＪａｖａ（登録商標）プラットフォームのようなソフトウェア動作環境を内蔵する複合機では、ソフトウェア動作環境上に、ファームウェアと独立した新たな装置組み込みアプリケーションを開発可能である。そして、ＡＰＩによってＪａｖａ（登録商標）アプリケーションから装置のプリント機能にアクセスすることができた。しかしながら、Ｊａｖａ（登録商標）プラットフォームはファームウェア内の組み込みアプリケーション階層に位置付けられている。このため、Ｊａｖａ（登録商標）プラットフォームと同じ階層でネイティブの組み込みアプリケーションとして実現されているプリントデータの受信機能やプリントサーバ機能をＪａｖａ（登録商標）アプリケーションのために流用できなかった。即ち、例えばネットワーク経由でプリントデータを受信するための各種プリントサービスプロトコルを実装したプリントサーバ機能をＪａｖａ（登録商標）側にも再実装する必要があり、開発負荷や評価負荷並びに実行時のメモリ容量の点でも非効率であった。
【００１０】
一方、その他の組み込みシステムのファームウェア内にソフトウェア動作環境の階層を持たない場合には、組み込みシステム全体がダイナミックリンクやプラグイン可能な構成で、システム全体が動的な構成になってしまっていた。これは、動的な特性が求められる部分が、受信したＰＤＬデータストリームを解釈する前の前処理を柔軟かつ拡張可能に追加する機構だけであることを前提とした場合に、低価格の小規模システムには不向きである。システム全体を動的なソフトウェアとして構成するためのオーバヘッドに伴うコストアップや品質保証の難しさが伴うためである。
【００１１】
そこで、本出願人は、特願２００４−０９３２１５号において、プリンタが受信したＰＤＬデータストリームの解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、プリンタファームウェアのその他の部分と分離することを提案した。これは、フィルタ部の拡張可能なソフトウエアの実装を、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離することにより、ＰＤＬプリンタのカスタマイズの生産性を向上する技術の提案である。
【００１２】
しかしながら、上記提案では、フィルタ処理を常に印刷要求データストリーム全体に対して行う必要があり、効率的な処理が実現できていない。即ち、画像処理装置が受信する印刷要求データストリームは、装置制御データストリーム部と描画データストリーム部とで構成されているが、フィルタ処理は常に印刷要求データストリム全体に施されてしまう。そして、このフィルタ処理は常に、これら両方を含んだデータストリームに対して実行されてしまうため、処理全体が重くなり、スループットが落ちるなど、効率的な処理が行えない。また画像処理装置へのデータの一時保管処理のような、ＰＤＬ以外の様々な処理要求データストリームへの対応や、画像処理装置で読み取った画像データを電子メールで送信するといった、様々なデータストリームへの対応も考慮されていなかった。
【００１３】
そこで、より効率的な処理の実現を目指して、本出願人は特願２００４−２３１４３３号を出願した。特願２００４−２３１４３３号では、装置制御データストリーム部と描画データストリーム部といった夫々のデータストリーム部分に対して、フィルタをかけることが可能な構成を提案している。なお、装置制御データストリーム部は、「ＪＬ（Job Language）」等の印刷装置の給排紙段の指定といった、主に装置の制御に関する指示命令で構成される。また、「ＰＤＬ(Page Description 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の仕様に基いている事を意味する。
【００４８】
ジョブ制御ライブラリ２１８は、制御ＡＰＩ２０４に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインターフェースを提供する。
【００４９】
フィルタフレームワーク２１９は、組み込みアプリケーション２０３と通信して、ジョブの実行に際して、インタプリタ環境上に実装したフィルタプログラムからの画像処理装置１０００の複数のデータストリームに対する介在を可能とする。
【００５０】
インタプリタコード部２２０は、インタプリタ２１６が解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するAPIライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部２０１とインタプリタコード部２２０に跨って位置付けられるソフトウェアは、それぞれの空間の間をインターフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではＪａｖａ（登録商標） Native Interface（JNI）に従って境界部分のプログラミングを行っている。
【００５１】
フィルタ２２１は、インタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているため、組み込みアプリケーション２０３が処理する処理要求データストリームに対する処理を行うことができる。プロトコルスタック２２３は、ＲＴＯＳ２１４のフレームワークに組み込まれ、より下層の外部インターフェースドライバ２２４が制御する外部インターフェース上にトランスポート層以下のプロトコルを実装する。例えば、ネットワークインターフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現する。そして、組み込みアプリケーション２０３に対しては、ＲＴＯＳ２１４を介してバークレイソケットなどのアプリケーションプログラミングのためのインターフェースを提供する。また例えば、外部インターフェースがＵＳＢの場合にはＩＥＥＥ１２８４.４などのプロトコルを実現する。
【００５２】
外部インターフェースドライバ２２４は、ネットワークインターフェースやＩＥＥＥ１３９４、ＵＳＢ，ＲＳ２３２Ｃ、セントロニクスなどの各種インターフェースへの接続を提供するハードウェアを駆動する。例えばネットワークの場合、イーサネット（登録商標）などのネットワークに接続するためのネットワークインターフェースハードウェアを駆動して物理層のプロトコルを実現する。
【００５３】
レンダラドライバ２２５はレンダラ２０７を駆動する。レンダラ２０７は、図３のディスプレイリスト３５５を中間画像データストリーム３５６に展開するためのハードウェアである。レンダラ２０７はソフトウェアによって実現してもよいし、展開されるデータストリームは最終画像データストリーム３５７（図３）でもよい。マーキングエンジン（ＭＥ）ドライバ２２６は、転写紙への画像形成を行うマーキングエンジンを駆動する。操作パネルドライバ２２７は、この画像処理装置１０００が備える操作パネル１８の表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。
【００５４】
また、レイヤＩ／Ｆ２１１はデータストリーム属性管理モジュール２２８を有する。ユーザは操作パネル１８を介して、データストリーム属性管理モジュール２２８に対して画像処理装置１０００におけるデータストリームの処理内容を指示することができる。
【００５５】
具体的には、データストリーム属性管理モジュール２２８は、処理要求データストリーム３５０がデータ送受信モジュール２０２において受信された場合、処理要求データストリーム３５０に対応するデータストリーム属性の管理を開始する。ネイティブ環境に存在する各モジュールは、必要に応じてデータストリーム属性管理モジュール２２８に問い合わせを行い、データストリームに対する処理内容を決定する。ここでネイティブ環境のモジュールとしては、データ送受信モジュール２０２、組み込みアプリケーション２０３、ジョブ制御モジュール２０５が挙げられる。また、更には、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９、データ管理モジュール２１０が挙げられる。また、上記各モジュールは、特定の情報が抽出された場合に、データストリーム属性管理モジュール２２８に通知を行う。この通知により、データストリーム属性管理モジュール２２８は、データストリーム属性を更新する。データストリーム属性管理モジュール２２８は、処理要求データストリーム３５０に対する処理が全て終了した旨の通知をジョブ制御モジュール２０５から受けることにより、処理要求データストリーム３５０に対するデータストリーム属性の管理を終了する。
【００５６】
或いは、スキャン画像データストリーム３６０がジョブ制御モジュール２０５において生成された場合、データストリーム属性管理モジュール２２８は、スキャン画像データストリーム３６０に対するデータストリーム属性の管理を開始する。そして、前述と同様にデータストリーム属性が管理される。データストリーム属性管理モジュール２２８は、スキャン画像データストリーム３６０に対する処理が全て終了した旨の通知をジョブ制御モジュール２０５から受けると、スキャン画像データストリーム３６０に対するデータストリーム属性の管理を終える。
【００５７】
上述したように、データストリーム属性管理モジュール２２８は、データ送受信モジュール２０２が処理要求データストリーム３５０を受信すると、そのデータストリーム属性の管理を開始する。ここで、データストリーム属性管理モジュール２２８は、インタプリタ環境に存在する各モジュールに対してそのデータストリーム属性を、制御ＡＰＩを介して公開する。こうして前述と同様のデータストリーム属性に対する処理（データストリーム属性の管理開始。各モジュールからのデータストリーム管理モジュールへの問い合わせ。各モジュールからのデータストリーム管理モジュールへの通知。データストリーム管理モジュールによるデータストリーム属性の更新。データストリーム属性の管理終了処理）が可能となる。またデータストリーム属性により、インタプリタ環境のモジュールに対しては引き渡しそのものを行わないといった動作も実行可能となる。
【００５８】
図３は、本実施形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れとそれぞれのモジュールにおいて存在するデータストリームを示す図である。図２に示すモジュールと共通するモジュールには同一の符号をつけて説明を省略する。
【００５９】
データ送受信モジュール２０２は、クライアントから受信した、処理要求データストリーム３５０を、フィルタ２２１を介さない場合に、経路３０１を介して組み込みアプリケーション２０３に流す。この経路３０１は、例えばＲＴＯＳ２１４が提供するメッセージキュー等のタスク間通信機能によって実現される。その他のデータの受け渡しも同様である。尚、処理要求データストリーム３５０は、装置制御指示データストリーム３５１と描画データストリーム３５２からなる。
【００６０】
ここでクライアントが、ＬＡＮ２０００を介したホスト上のアプリケーション及びドライバソフトの場合、クライアントは処理要求データストリーム３５０を生成する。そして、その処理要求データストリーム３５０を、データ送受信モジュール２０２を介して組み込みアプリケーション２０３へ引き渡す。組み込みアプリケーション２０３は、処理要求データストリーム３５０を装置制御指示データストリーム３５１と描画データストリーム３５２とに分割し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５にそれぞれを引き渡す。或は、装置制御指示データストリーム３５１を解釈し、制御ＡＰＩ２０４によってジョブ制御モジュール２０５に対して、クライアントから要求された処理を指示し、描画データストリーム３５２を引き渡す。
【００６１】
一方、クライアントが画像処理装置の操作パネル１８を介した指示の場合は、組み込みアプリケーション２０３で装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡す。或はジョブ制御モジュール２０５に対して制御ＡＰＩ２０４によってクライアントから要求された指示を行う。装置の制御に関する記述部は、一般的にはＪＬ（Job Language）と呼ばれる。ＪＬには、描画データの解釈及び展開に関する動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などが含まれる。一方、描画データストリームはＰＤＬによって記述されており、主にページ毎の描画が記述されている。
【００６２】
ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した指示に従って装置１０００の制御を行う。或は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５へ入力された装置制御指示データストリーム３５１を解釈して動作を行う。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介した装置１０００の制御に関する指示、或は装置制御指示データストリーム３５１の記載内容に応じて、制御線３９０を介して、トランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、画像処理モジュール２０９及びデータ管理モジュール２１０を制御する。プリントジョブの場合は、ジョブ制御モジュール２０５は次のようにスケジュールする。即ち、描画データストリーム３５２をトランスレータ２０６によりディスプレイリスト３５５に変換させ、ディスプレイリスト３５５をレンダラ２０７により中間画像データストリーム３５６に変換させる。そして、中間画像データストリーム３５６を画像処理モジュール２０９により最終画像データストリーム３５７に変換し、最終画像データストリーム３５７がＭＥ制御モジュール２０８に流れて印刷するようにする。
【００６３】
更なる一例として、組み込みアプリケーション２０３により提供される画像データの読み取りと送信の際の動作を示す。操作パネル１８から画像データの読み取り及び送信指示が行われた場合、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと送信の指示を行う。この指示は組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して、直接ジョブ制御モジュール２０５に伝えられ、実行される。或は、この指示は、組み込みアプリケーション２０３が装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、画像読み取り部１９で読み取られた画像データを入力してＲＡＭ２上に保持して画像処理モジュール２０９に引き渡す。こうして画像処理モジュール２０９で生成されたスキャン画像データストリーム３６０を組み込みアプリケーション２０３へ引き渡すようにスケジューリングする。組み込みアプリケーション２０３は、その引き渡されたスキャン画像データストリーム３６０を操作パネル１８から指示された形式に変換して送信用データストリーム３５９を生成する。そして、この送信用データストリーム３５９を、データ送受信モジュール２０２を介して送信用データストリーム３５９として送信する。或は、操作パネル１８から指示された送信先が、内蔵されている外部メモリ１０の場合は、組み込みアプリケーション２０３は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの読み取りと保存指示を行う。この指示は、組み込みアプリケーション２０３が制御ＡＰＩ２０４を介して直接ジョブ制御モジュール２０５に渡され、実行される。或は、組み込みアプリケーション２０３がこの指示に基づく装置制御指示データストリーム３５１を生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、３９０を介して、画像読み取り部１９から画像データを入力してＲＡＭ２上に保持し、画像処理モジュール２０９に引き渡す。こうして生成されたスキャン画像データストリーム３６０をデータ管理モジュール２１０を介して外部メモリ１０へ格納するようにスケジューリングする。
【００６４】
以上の処理は全てネイティブコード部分２０１に実装されている。
【００６５】
図４は、本実施の形態に係るコントローラ１６００のソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。各モジュールにおけるデータストリームは図３と同様であり、前述の図面と共通する部分は同じ記号で示している。
【００６６】
データ送受信モジュール２０２は、データストリームに対してフィルタ処理を施す場合には、処理されたデータストリームを、経路３０６を介して外部レイヤ２１２に流す。この経路３０６は、例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間の通信機能によって引き渡されるが、その他のデータの受け渡しでも良い。レイヤＩ／Ｆ２１１の中の外部レイヤＩ／Ｆ２１２は、各種データストリームをインタプリタ環境２１５へ引き渡す。データとストリームとしては、例えば、画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、この処理要求データストリーム３５０を画像処理装置１０００内で分割して得られた装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換・生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８が挙げられる。尚、これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。
【００６７】
外部レイヤＩ／Ｆ２１２は、その受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境上２１５に実装されたフィルタプログラム群２２１を管理している。フィルタフレームワーク２１９は、そのデータストリームを、経路３０８を介してフィルタ２２１に流す。この経路３０８では、例えばインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。インタプリタ環境２１５内のデータのやりとりに関しても以下同様である。ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間の通信機能によって引き渡される。
尚、ランタイムモジュールとはプログラムを実行する際に必要となるソフトウェアモジュールを意味する。
【００６８】
フィルタ２２１は、入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９を介してフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤＩ／Ｆ２１２に引き渡す。これにより外部レイヤＩ／Ｆ２１２は、そのデータストリームを経路３１１を介して組み込みアプリケーション２０３に流す。また或は、外部レイヤＩ／Ｆ２１２が、経路３７０を介してデータ送受信モジュール２０２にデータストリームを流し、そのデータストリームを、前述のように経路３０１を介して組み込みアプリケーション２０３に流す構成をとってもよい。
【００６９】
制御パス３１２，３７２は、フィルタフレームワーク２１９の状態に応じて、データ送受信モジュール２０２から組み込みアプリケーション２０３に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、前述の経路３０６，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３０１が有効となり、データストリームは直接、データ送受信ストリーム２０２から組み込みアプリケーション２０３に流れる。この場合、フィルタフレームワーク２１９が介在することによるオーバヘッドが避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００のデータ処理性能を発揮できる。
【００７０】
組み込みアプリケーション２０３がデータストリームに対してフィルタ処理を施す場合には、データストリームは経路３１４を介して外部レイヤ２１２に流れる。この経路３１４は例えばＲＴＯＳ２１４が提供するメッセージキューなどのタスク間通信機能によって引き渡されるが、その他のデータの受け渡しも同様である。外部レイヤ２１２は、前述したように、レイヤＩ／Ｆ２１１の中でも特に、基本的には画像処理装置１０００の外部からＬＡＮ２０００等を介して受信するデータストリームである処理要求データストリーム３５０、処理要求データストリーム３５０が画像処理装置１０００内で分割された装置制御指示データストリーム３５１と描画データストリーム３５２、組み込みアプリケーションにおいて変換、生成される送信用データストリーム３５９、データ送受信モジュール２０２から最終的に送信処理が行われる送信用データストリーム３５８をインタプリタ環境２１５へ引き渡す。これらのデータストリームはデータ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。外部レイヤ２１２は、受け取ったデータストリームを経路３０７を介してフィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールは、インタプリタ環境２１５に実装されたフィルタ２２１を管理している。フィルタフレームワーク２１９は、受け取ったデータストリームを経路３０８を介してフィルタ２２１に流す。この経路３０８は、例えばインタプリタ環境２１５が提供するスレッド間通信機能によって実現される。インタプリタ環境２１５のデータのやりとりに関しても以下同様である。尚、ここでフィルタ２２１が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１５が提供するスレッド間通信機能によって引き渡される。
【００７１】
フィルタ２２１は、受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは、経路３０９よってフィルタフレームワーク２１９に流れる。フィルタフレームワーク２１９はフィルタ２２１から受け取ったデータストリームを経路３１０を介して外部レイヤ２１２に引き渡し、外部レイヤ２１２は、経路３１５を介して、そのデータストリームをジョブ制御モジュール２０５に流す。尚、ここで外部レイヤ２１２が、経路３７１を介して、そのデータストリームを組み込みアプリケーション２０３に流し、前述のように経路３１３を介してジョブ制御モジュール２０５に流す構成をとってもよい。
【００７２】
制御パス３１６，３７２は、フィルタフレームワーク２１９の状態に応じて組み込みアプリケーション２０３からジョブ制御モジュール２０４に至るデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１４，３０７が有効となりフィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には、経路３１３が有効となり、データストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク２１９が介在することによりオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置１０００でのデータ処理性能を発揮できる。
【００７３】
次に、ジョブ制御モジュール２０５が、データストリームに対してフィルタ処理を施す場合を説明する。この場合、データストリームは、経路３１８を介して、内部レイヤＩ／Ｆ２１３に流れる。経路３１８は、例えばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間の通信機能によって引き渡される。その他のデータの受け渡しも同様である。内部レイヤＩ／Ｆ２１３は、レイヤＩ／Ｆ２１１の中でも特に、画像処理装置１６００で生成されるディスプレイリストやデータストリームをインタプリタ環境２１５へ引き渡す。内部レイヤＩ／Ｆ２１１によって引き渡されるデータとしては、トランスレータ２０６が描画データストリーム３５２を処理することで生成するディスプレイリスト３５５、レンダラ２０７がディスプレイリスト３５５を処理することで生成する中間画像データストリーム、画像処理モジュール２０９が中間画像データストリーム３５６を処理することで生成する最終画像データストリーム３５７、画像読み取り部１９から読み込まれたスキャン画像データストリーム３６０などが挙げられる。尚、これらのデータストリームは、データ管理モジュール２１０により外部メモリ１０から取り出されたものでもよい。内部レイヤＩ／Ｆ２１３は、経路３１８を介して受け取ったデータストリームを、フィルタフレームワーク２１９に流す。フィルタフレームワーク２１９のランタイムモジュールはインタプリタ環境２１５に実装されたフィルタ２２１を管理している。このインタプリタコード部２２０におけるフィルタ処理は前述の処理と同じであるため、その説明を省略する。
【００７４】
フィルタフレームワーク２１９は、フィルタ２２１から受け取ったデータストリームを経路３１０を介して内部レイヤＩ／Ｆ２１３に引き渡す。内部レイヤＩ／Ｆ２１３は、そのデータストリームを経路３１９を介してジョブ制御モジュール２０５に流す。尚、内部レイヤＩ／Ｆ２１３が直接、トランスレータ２０６、レンダラ２０７、画像処理モジュール２０９、ME制御モジュール２０８、データ管理モジュール２１０へ引き渡す構成をとってもよい。
【００７５】
制御パス３２０，３７２は、フィルタフレームワーク２１９の状態に応じてデータストリームを制御するためのパスである。フィルタフレームワーク２１９が管理するフィルタ２２１が有効な状態で配置されている場合は、経路３１８，３０７が有効となり、フィルタ２２１による前処理が施される。一方、フィルタフレームワーク２１９が有効なフィルタ２２１を配置していない場合には経路３１７が有効となり、データストリームは直接ジョブ制御モジュール２０５がスケジューリングした次のモジュールに流れる。この場合、フィルタフレームワーク２１９が介在することによるオーバヘッドを避けられるため、フィルタ２２１によるカスタマイズを全く行わない標準状態の画像処理装置のデータ処理性能を発揮できる。
【００７６】
上記の構成において、本実施形態の画像処理装置にけるネイティブ環境にはデータストリーム属性管理モジュール２２８が存在する。データストリーム属性管理モジュール２２８は、図１７に示されるような処理を実行する。
【００７７】
まず、ステップＳ２１において、処理要求データストリーム３５０がデータ送受信モジュールから入力されると、データストリーム属性管理モジュール２２８は受信した処理要求データストリーム３５０の属性の管理を開始する。次に、ステップＳ２２において、ステップＳ２１で入力された処理要求データストリーム３５０を解析し、装置制御指示データストリーム３５１から当該処理要求データストリームのジョブ種類やＰＤＬ種別を判定する。これは、図１０で後述するように、処理要求データストリーム８０１に含まれる装置制御指示データストリーム３５１に記述された「ジョブ種類」や「使用ＰＤＬ」に基づいてなされる。
【００７８】
一方、本実施形態のフィルタ２２１には、複数のフィルタが登録されており、図７により後述するように処理要求データストリームや所望の中間データストリームに対して適用すべきフィルタ、或はフィルタの組み合わせが設定される。一方、図１８により後述するように、各フィルタ或はフィルタの組み合わせに、適用条件が設定される。図１８の例では、描画データストリームを対象としたフィルタ（或はフィルタの組み合わせ）について、フィルタを適用すべき条件としてＰＤＬ種別やジョブ種類を設定可能な様子が示されている。即ち、本実施形態では、各中間データに対して適用すべきフィルタ（或はフィルタの組み合わせ）が登録されると共に、実際にそのフィルタ処理を適用するか否かを判定するためのＰＤＬ種別やジョブ種類等が登録される。
【００７９】
従って、ステップＳ２３ではチェック対象のフィルタ（或はフィルタの組み合わせ）を選択する。そしてステップＳ２４において、入力した処理要求データストリームに記述されているＰＤＬ種別やジョブ種類と、登録されているフィルタ（或はフィルタの組み合わせ）に設定されているＰＤＬ種別やジョブ種類とを比較する。比較の結果、両者が一致した場合は、ステップＳ２５において当該フィルタが、対象となる中間データストリームへ適用されるように、組み込みアプリケーション２０３或はジョブ制御モジュール２０５を設定する。一方、ステップＳ２４における比較の結果、両者が一致しない場合は、ステップＳ２６へ進み、対象となる中間データストリームの転送を禁止するよう、組み込みアプリケーション２０３或はジョブ制御モジュール２０５を設定する。以上のステップＳ２３〜Ｓ２６の処理を登録されているフィルタについて行なう（ステップＳ２７）。
【００８０】
尚、上記処理では、データストリーム属性管理モジュール２２８は、処理要求データストリームを解析してフィルタの適用条件との対応を調べたが、これに限られるものではない。中間データストリーム（例えば、装置制御指示データストリーム３５１）を入力し、このデータストリームを解析することにより適用条件との対応をチェックするようにしてもよい。このようにすれば、例えば、装置制御指示データストリーム３５１を用いて描画データストリーム３５２にフィルタ機能を適用するか否かを判断する構成となる。
【００８１】
以上のような設定が組み込みアプリケーション２０３やジョブ制御モジュール２０５になされると、組み込みアプリケーション２０３やジョブ制御モジュール２０５は次のように動作する。即ち、生成されたた中間データストリーム（描画データストリーム３５２やディスプレイリスト３５５等）のうちフィルタ処理を適用すると設定された中間データストリームのみをレイヤＩ／Ｆ２１１に送るように動作する。このような制御により、中間データストリームの不要なフィルタ処理が禁止され、処理効率が向上する。
【００８２】
図５は、本実施の形態のインタプリタ環境２２０に構築されるフィルタフレームワーク２１９のクラスを説明する図である。
【００８３】
フィルタ管理（FilterManager）クラス４０１は、フィルタフレームワーク２１９のランタイム環境を実現するオブジェクトのクラスである。このフィルタ管理クラス４０１は一つのコネクタ（Connector）クラス４０５のオブジェクトをコンポジション（composition）として持つ。また複数（ｎ個）のフィルタ（Filter）抽象クラス４０２のオブジェクトへの参照と、複数｛（ｎ−１）個｝のパイプ（Pipe）クラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワーク２１９のランタイムに、インストールされた複数のフィルタクラス４０２の具体クラスを管理するためのinstalledFilter属性４１０を備えている。
【００８４】
フィルタ抽象クラス４０２は、各種のフィルタクラスを抽象化する抽象クラスである。このフィルタ抽象クラス４０２は、フィルタ名称を示す「name」属性などを備える。また、入力（input）属性として、入力ストリーム（InputStream）抽象クラス４０３を継承したクラスのオブジェクトへの参照を有している。また出力（output）属性として、出力ストリーム（OutputStream）抽象クラス４０４を継承したクラスのオブジェクトへの参照を有している。フィルタ抽象クラス４０２の具体クラスは、Runnableインターフェース４１１を実装し「run」メソッドを有している。フィルタ管理クラス４０１のオブジェクトは、管理している各種のフィルタ抽象クラス４０２のインスタンスを生成してデータストリームのフィルタ処理のために配置する。この時、配置される各フィルタオブジェクトに対応してスレッドを生成し、並行して動作するスレッドの実行コンテクストでフィルタオブジェクトのrunメソッドを実行する。即ち、コンストラクタのパラメータにフィルタオブジェクトを渡してJava.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の指すPipedOutputStreamオブジェクトへwriteする。
【００９４】
パイプオブジェクト５０４は、パイプクラス４０５のオブジェクトである。このパイプオブジェクト５０４は、PipedOutputStreamオブジェクトとPipedInputStreamオブジェクトとを接続された状態で持つ。パイプオブジェク５０４が持つPipedOutputStreamオブジェクトのwriteメソッドの呼び出しによってデータストリームはそのPipedOutputStreamオブジェクトへ引き渡される。そして、パイプオブジェクト５０４が持つPipeInputStreamオブジェクトのreadメソッドの呼び出しによって、PipeInputStreamオブジェクトからデータストリームとして読み出すことができる。
【００９５】
フィルタ２オブジェクト５０５は、フィルタ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ２オブジェクト５０５の入力属性にはパイプオブジェクト５０４が持つPipedInputStreamの参照が保持されており、inputの指すパイプオブジェクト５０４からreadしたデータストリームに対してフィルタ処理を施す。また、このフィルタ２オブジェクト５０５の出力属性にはコネクタオブジェクト５０１が持つConnectorOutputStreamの参照が保持されている。フィルタ処理が施されたデータストリームは、outputの指すConnectorオブジェクト５０１が持つConnectorOutputStreamへwriteされる。
【００９６】
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。また、同様にして間にパイプオブジェクト５０４を挟みこみながら、より多くのフィルタオブジェクトをデータストリーム処理のために配置することもできる。
【００９７】
図７（Ａ）〜（Ｃ）は、本実施の形態に係るフィルタフレームワーク２１９を操作するためのユーザインターフェース例を説明する図である。このフィルタフレームワークを操作するためのユーザインターフェースは、標準ライブラリとフレームワーク２１７（図１）に含まれるＨＴＴＰサービスによってウエブ（Ｗｅｂ）アプリケーション（Servlet）として実装されている。このユーザインターフェースは、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の操作パネル１９から操作するように構成してもよい。
【００９８】
図７（Ａ）は、この実施の形態の画像処理装置１０００のフィルタフレームワーク２１９に新しいフィルタ２２１をインストールして追加するためのユーザインターフェースを示している。このフィルタインストール画面６０１は、ファイル名入力フィールド６０２、参照ボタン６０３及びインストールボタン６０４を備えている。
【００９９】
ユーザは、クライアントコンピュータのファイルシステムに予め格納されているインストールしたいフィルタクラス４０２のクラスファイルのファイルパスを、ファイル名入力フィールド６０２に入力する。
【０１００】
ユーザが、参照ボタン６０３をクリックすると、クライアントコンピュータのＷｅｂブラウザが提供するファイル選択ダイアログがオープンされる。ユーザは、このファイル選択ダイアログによりクライアントコンピュータのファイルシステム内をブラウズして、インストールしたいフィルタクラス４０２のクラスファイルを選択できる。このファイル選択ダイアログによってユーザが選択したファイルのファイルパスは、自動的にファイル名入力フィールド６０２に入力される。
【０１０１】
次にユーザによるインストールボタン６０４のクリックが検出されると、指定されたフィルタが新規フィルタインストールのためのＷｅｂアプリケーションに送信される。即ち、クライアントコンピュータのＷｅｂブラウザによって、ファイル名入力フィールド６０２に入力されたファイルパスのクラスファイルが、この画像処理装置１０００で待機している新規フィルタインストールのためのＷｅｂアプリケーションに送信される。こうしてクラスファイルを受信したＷｅｂアプリケーションは、この画像処理装置１０００の不揮発性メモリ３に、その受信したクラスファイルを格納する。また、そのクラスファイルをインタプリタ環境２１５に動的にロードしてオブジェクトインスタンスを生成する。そして、その生成したフィルタオブジェクトを、フィルタフレームワークランタイムが管理する有効フィルタ列のリストの最下流に配置する。尚、このとき、既に有効なフィルタオブジェクトがフィルタ列に存在すれば、新規のフィルタオブジェクトを連結するために新たなパイプオブジェクトが生成される。
【０１０２】
このようなユーザインターフェースをＷｅｂアプリケーションとして実装している場合には、フィルタの実装クラスの装置１０００へのアップロードは、ＲＦＣによって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用している。従って、この場合、ファイル名入力フィールド６０２と参照ボタン６０３はクライアントコンピュータのＷｅｂブラウザによって表示されており、インストールボタン６０４はフォームのsubmitに対応している。
【０１０３】
また、このユーザインターフェースをApplet型のサービスとして実装する場合には、この画面６０１は、画像処理装置１０００の操作パネル１８の表示部に表示される。ファイル名入力フィールド６０２で指定されるファイルは、画像処理装置１０００がリムーバブル記憶メディアを備える場合は、そのリムーバブル記憶メディア中のファイルパスを指定しても良い。或は、ネットワーク経由で画像処理装置からＨＴＴＰやＦＴＰ等のファイル転送プロトコルによって読み出しアクセス可能な共有ファイルを、ＵＲＬなどによって指定してもよい。
【０１０４】
図７（Ｂ）は、本実施の形態に係る画像処理装置１０００のフィルタフレームワーク２１９にインストールされているフィルタを配置するためのユーザインターフェースを説明する図である。
【０１０５】
このフィルタ配置画面６０５において、表６０６は、フィルタフレームワーク２１９のランタイムにインストールされているフィルタ群を一覧表示している。この表６０６の各行は、インストールされているフィルタのそれぞれに対応している。また、この表６０６の「選択」列にはチェックボックスが並んでおり、ここでチェックされた行のフィルタが後述する操作の対象として選択される。表６０６の「順序」列には、そのフィルタが無効状態にある場合には「無効」が表示される。また有効状態にある場合には、そのデータストリーム処理の上流から下流に向かって昇順に付された番号が表示される。そして表６０６の「名称」列には、そのフィルタオブジェクトのname属性に記述されたフィルタ名称が表示される。
【０１０６】
６０７〜６１１は、選択されたフィルタに対する操作を指示するためのボタンであり、表６０６の選択列でチェックされた行のフィルタを対象とする操作を指示する。ユーザが、詳細表示ボタン６０７をクリックすると、表６０６で選択されたフィルタに関する詳細情報が表示される。この詳細情報としては、フィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名（ファイルパスやＵＲＬ）、インストールされた日時などがある。
【０１０７】
上へボタン６０８がクリックされると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の上流方向に一段階だけアップする。一方、下へボタン６０９がクリックされると、選択されたフィルタのフィルタ列内における順序が、データストリーム処理の下流方向に一段階だけダウンさせる。有効／無効のトグルボタン６１０がクリックされると、選択されたフィルタが有効状態にある場合は無効状態に変更され、無効状態にある場合には有効状態に変更される。無効状態にされたフィルタオブジェクトは削除されるが、フィルタクラス４０２はインストールされた状態で残って、フィルタフレームワークランタイムの管理下に留まる。アンインストールボタン６１１がクリックされると、選択されたフィルタのクラスファイルを画像処理装置１０００のインタプリタ環境から削除する。決定ボタン６２１がクリックされると、当該設定画面６０５によって設定されたフィルタ配置が決定される。
【０１０８】
図７（Ｃ）は、フィルタがデータストリームを対象としたものかを選択するユーザインターフェース例を示す図である。
【０１０９】
フィルタインストール画面６０１やフィルタ配置画面６０５を表示する前段階で、この対象データストリームの選択画面６１２を表示してユーザに選択させることにより、ユーザがフィルタ処理に関するインストールや設定を望むデータストリームを決定できる。
【０１１０】
リスト６１３は、画像処理装置１０００内に存在するデータストリームをリスト形式で選択するためのユーザインターフェースである。フィールド６１４は、リスト６１３から選択されたデータストリームを表示する。決定ボタン６１５は、フィールド６１４で指定されているデータストリームに対するフィルタのインストールと、管理を行うように決定するためのボタンである。このボタン６１５が押下されると、該当するデータストリームのフィルタインストール画面６０１やフィルタ配置画面６０５が表示される。
【０１１１】
尚、フィルタの処理対象となるデータストリームを選択する方法は上記に限られるものではない。例えば、フィルタ抽象クラス４０２にフィルタ属性を設け、フィルタのインストールやフィルタの管理時にフィルタ属性を参照することにより、フィルタ対象データストリームを特定するようにしても良い。以上のようなユーザインターフェースにより、入力データストリーム（処理要求データストリーム）や所望の中間データストリームに対して１つ又は複数のフィルタを配置することができる。又、このようにして配置されたフィルタ（或はフィルタの組み合わせ）は、図４に示されるようにレイヤＩ／Ｆ２１１を介して中間データストリームのデータパス中に配置されたことになる。
【０１１２】
又、図１７により上述したように、本実施形態では、中間データストリームに対して配置されたフィルタ（或はフィルタの組み合わせ）に関して、適用すべき「ＰＤＬ種別」や「ジョブ種類」を設定できる。例えば、図７の（Ｂ）に示される適用条件ボタン６２０が押下されると、図１８に示すユーザインターフェースが提示される。図１８では、対象データストリームが「描画データストリーム」となっており、図７（Ｃ）の対象データストリームの選択において「描画データストリーム」が選択され、図７（Ｂ）において適用条件ボタン６２０が押下された場合の表示例が示されている。図１８において、ＰＤＬ種別設定リストボックス１５０１やジョブ種類設定リストボックス１５０２において、当該フィルタ（或はフィルタの組み合わせ）を適用すべきＰＤＬ種別やジョブ種類を設定する。そして、決定ボタン１５０３をクリックすることにより、その設定内容が確定される。この場合、処理要求データストリームがここで設定されたジョブ種類とＰＤＬ種別を持つ場合に、当該処理要求データストリームに含まれる描画データストリームが図７の（Ｂ）によって配置されたフィルタの処理を受けることになる。
【０１１３】
尚、上記ではフィルタ処理を適用するか否かをＰＤＬ種別やジョブ種類により判断するが、これらは一例であり、これに限られるものではない。
【０１１４】
図８は、本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。
【０１１５】
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワーク２１９が管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で実行される。
【０１１６】
まずステップＳ１で、必要な前処理を行う。この前処理には、フィルタ２２１が内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力／出力ストリームをより使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。ここで、入力／出力ストリームをより使いやすくする機能としては、例えば入力ストリームを先読み可能にしたり、システムリソースを有効に利用するためにバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次に、ステップＳ２で、入力属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。そしてステップＳ３で、入力したデータストリームから、このフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。このフィルタが操作するべきデータパターンは、固定のデータ列そのものでも良く、或は正規表現（regular expression）等の形式言語による記述でもよい。尚、パターン記述に合致するデータの出現をデータストリーム中から発見するための各種の実装は広く知られており、例えばgrep、sed、AWK、Perlなどが有名である。
【０１１７】
パターンマッチングを効率良く行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較し、ハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Knuth-Morris-Prattの方法や、Boyer-Mooreの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のＪａｖａ（登録商標）プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる（Java.util.regex）。尚、例えばデータストリームの上流のパターンに応じて状態が変化し、その変化した状態に従って下流のパターンの解釈を変えなければならない場合であって、正規表現等では却って記述が困難なほど複雑なパターンマッチングが必要とされる場合がある。そのような場合には、そのパターンの特徴そのものを評価するアルゴリズムをＪａｖａ（登録商標）プログラムとして書き下してもよい。このようにして、どれほど複雑なパターンマッチングであっても素直に実装することができる。
【０１１８】
次にステップＳ４で、パターンマッチングの結果を判定し、パターン記述に合致するデータをデータストリーム中に発見した場合はステップＳ５に進むが、そうでなければステップＳ６に進む。ステップＳ５では、パターン記述に合致したデータストリームの部分データ列に対してこのフィルタの目的に応じた操作を施し、その結果で置き換える。次にステップＳ６で、処理済の部分データ列（即ち、監視しているパターンが現れなかったデータ列、或は、監視しているパターンを含むデータ列に対してステップＳ５の処理を施したデータ列）を出力ストリームに書き込む。そしてステップＳ７で、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了するが、そうでなければステップＳ２に戻って、上記の手順を繰り返す。
【０１１９】
図９は、本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。
【０１２０】
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド（Threadオブジェクト）を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で動作することになる。
【０１２１】
まずステップＳ１１で、必要な前処理を行う。この前処理には、フィルタが内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力／出力ストリームを、より使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。尚、入力／出力ストリームを、より使いやすくする機能としては、例えば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、例えば、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次にステップＳ１２で、新たな部分データストリームを生成する。次にステップＳ１３で、入力属性にセットされている入力ストリームから、予め定められた量のデータを読み出す。そしてステップＳ１４で、その読み込まれたデータストリームに対して、ステップＳ１２で生成された部分データ列を追加する。次にステップＳ１５で、処理済の部分データ列を出力ストリームに書き込む。そしてステップＳ１６で、入力ストリームに存在する残りデータを出力ストリームに書き込む。
【０１２２】
図１０は、本実施の形態に係る処理要求データストリームを説明する図である。
【０１２３】
８０１は処理要求データストリームを示している。クライアントからの、この画像処理装置１０００に対する処理の要求は、クライアントが処理要求データストリーム８０１を作成して画像処理装置１０００に送信することにより行われる。そして、要求された処理の実行は画像処理装置１０００が、その処理要求データストリーム８０１を処理することで実行される。この処理要求データストリーム８０１は、大きく装置制御指示データストリーム８０２（図３の３５１に相当）と描画データストリーム８０３（図３の３５２に相当）に分けることができる。
【０１２４】
装置制御指示データストリーム部８０２では、この画像処理装置１０００への、描画以外の処理要求に関する指示が記述されている。具体的には、以下のような指示を行うことが一般的に知られており、画像処理装置１０００が備える機能により規定されている。１行目の「ジョブ種類」の属性は、「印刷」、「セキュアプリント」、「画像取得」等の値を取り得るもので、この画像処理装置１０００が備える各種ジョブのタイプを表している。「画像取得」等のように描画指示を行わない処理要求の場合は、描画データストリーム８０３は一般的には、このような処理要求データストリーム８０１に含まれない。２行目の「部数」の属性は、印刷物のコピーを何セット生成するかを表している。３行目の「ページレイアウト」の属性は、ページレイアウト指定を表している。ページレイアウト指定には、「１ページ／枚」「２ページ／枚」「４ページ／枚」などのように、１枚の用紙に複数ページを面付けするための指定が含まれる。更に、ページレイアウト指定には、「ポスター（２×２）」、「ポスター（３×３）」などのように、１ページを拡大して複数枚の用紙に分割して印刷する指定も含まれる。４行目の「配置順」の属性は、「左上から右向き」、「左上から下向き」、「右上から左向き」、「右上から下向き」等の値を取り、ページレイアウト時の各面の配置指定を表す。５行目の「印刷方法」の属性は、「片面印刷」、「両面印刷」、「製本印刷」等の値を取り、これにより印刷方法を表す。６行目の「とじ方向」の属性は、「長辺とじ（左）」、「長辺とじ（右）」、「短辺とじ（上）」、「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。７行目の「排紙方法」の属性は、「指定しない」、「ソート」、「ステイプル」、「パンチ穴」などの値をとり、フィニッシングの方法を表す。８行目の「給紙」属性は、「自動」、「手差しトレイ」、「カセット」、「デッキ」、或は「普通紙」、「厚紙」、「色紙」、「ＯＨＰ」などの値をとり、画像形成の対象とする用紙（転写紙）の給紙指定を表す。９行目の「使用ＰＤＬ」は、処理要求内容が描画指示である場合に使用され、描画データストリームに使用されるＰＤＬの種別を表している。
【０１２５】
描画データストリーム部８０３は、処理要求内容が描画指示である場合に使用され、描画データストリームは一般的にはＰＤＬで構成される。
【０１２６】
図１１は、本実施の形態に係る描画データストリーム８０３に対するフィルタが行う処理を説明する図である。
【０１２７】
互換化フィルタ９０１は、この描画データストリーム８０３のフィルタクラスのオブジェクトを示し、入力データストリームに現れる描画データストリーム８０３における互換性の問題を解決する処理を施して出力ストリームに書き込む。この描画データストリーム８０３における互換性の問題として、ここでは代表的なＰＤＬの一つであるAdobeのPostScript仕様を、各社ベンダが実装した画像処理装置間におけるベンダごとの解釈の差異に基づく問題と、その解決の例を説明する。
【０１２８】
あるベンダの画像処理装置は、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「setpagedevice」で「/DeferredMediaSelection」が真のときカスタム用紙扱いとして用紙要求をパネルに表示する。一方、偽の場合には、指定されたサイズから±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。また別のベンダの画像処理装置では、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「/DeferredMediaSelection」が真の場合は、指定されたサイズそのもののサイズ（範囲なし）で定型用紙を検索し、定型にない場合はカスタム用紙扱いとする。一方、偽の場合には、±５の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。
【０１２９】
ここで、更に別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、上記の内の後者の解釈に基づく挙動を前提として構築されたとする。すると、印刷要求に対して前者の画像処理装置では、カスタム用紙扱いとなってしまい、「用紙なし」が操作パネルに表示されて印刷されない。従って前者の画像処理装置のベンダは、この互換性の問題に対して、できるだけ低コストでかつ速やかに解決することが求められる。このような要求に対しては、印刷要求データストリームに現れるsetpagedeviceの「/DeferredMediaSelection」パラメータを真（true）から偽（false）に変換することで、少なくとも暫定的に応えることができる。互換化フィルタ９０１は、このような問題を解決するために働くフィルタオブジェクトである。即ち、互換化フィルタ９０１は、入力データストリームから「/DefereedMediaSelection」が真（true）で指定されたsetpagedeviceに対するパターンマッチングを行い、マッチした場合は、偽（false）に置き換えた力データストリームを出力する。
【０１３０】
９０２はフィルタへの入力データストリームの一例である、PostScriptのプリントデータである。２行目にパターンに合致する部分データが出現する。９０３は、入力データストリーム９０１がフィルタによりフィルタ処理されて出力された出力データストリーム例を示し、フィルタ処理されたPostScriptのプリントデータで示されている。この出力データストリーム９０３では、２行目のデータの中で「true」という文字列が「false」へ変更されている。
【０１３１】
図１２は、本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。
【０１３２】
上記の図１１の例では、画像処理装置間の仕様の差異に基づく互換性の問題を解決するために、フィルタによるデータストリームのパターンマッチングと置換の技術を用いた。図１２の例では、同様の技術を、画像処理装置の実装の不具合（ファームウェアのバグなど）を緊急回避するために用いている。例えば、ある画像処理装置のあるバージョンのリリースにおいて、ＬＩＰＳ（登録商標）言語の「イメージ領域確保命令（VDM）」に指定されるイメージの幅が８の倍数でなければ描画不正が発生するというバグがあったとする。
【０１３３】
１００１は障害回避フィルタを示し、例えば、ＬＩＰＳ（登録商標）データストリーム１００２から障害を発現させるパターンを発見し、その障害を顕在化させず同等の機能を達成するためにデータストリームに変換する。例えば、障害回避フィルタ１００１は、データストリーム１００２から障害を発現させるパターンを発見（VDMのイメージ幅が「２２５」であり８の倍数でない）する。そして、発見されたパターンをVDMのイメージ幅を８の倍数に変換する（ここでは、「２２５」より大きい値である「２３２」）に変換する。
【０１３４】
図１３は、本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。
【０１３５】
最適化フィルタ１１０１は、描画データストリームに対する最適化フィルタクラスのオブジェクトを示す。最適化フィルタ１１０１は、入力ストリームを読み出してデータストリーム中に現れる冗長に記述されたＰＤＬデータを発見し、それをより効率の良い同機能のデータに変換して出力ストリームに書き込む。画像処理装置のドライバが生成するＰＤＬデータストリームは、クライアントのプリント要求システムやアプリケーション側の都合によって、どうしても繰り返しなどの冗長な処理がパターンを含む傾向にある。このような冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換える。
【０１３６】
１１０２は、フィルタ１１０１に入力される入力データストリームの一例を示す。この入力ストリーム１１０２では、１１０３で示すように、横長の長方形を塗りつぶすために３つの正方形の塗りつぶしを繰り返すように記述されている。１１０４は、この最適化フィルタ１１０１からの出力データストリームの一例を示している。ここではフィルタ１１０１は、冗長な繰り返しパターンを検出し、それを等価な１つの横長の矩形の塗りつぶし１１０５に書き換えている。
【０１３７】
図１４は、本実施の形態に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。
【０１３８】
１２０１は、装置制御指示データストリーム３５１に対する機能拡張フィルタクラスのオブジェクト例を示している。機能拡張フィルタ１２０１は、入力データストリーム１２０２を読み出して、その入力データストリームに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力データストリームに書き込む。ここでは、機能拡張の例として、以下の例を挙げる。即ち、顧客システムが専用のＰＤＬドライバを抱えていてそのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応であるとする。そのような場合に、そのドライバを変更することなく画像処理装置側のフィルタ対応によって装置の新機能を活かす。
【０１３９】
機能拡張フィルタ１２０１は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための装置制御指示設定をその属性として持つ。フィルタオブジェクトの属性値は、装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。具体的には、前述のように画像処理装置が備える機能により規定されている。
【０１４０】
入力データストリーム１２０２は、印刷データストリームの機能拡張フィルタ１２０１に入力されるデータストリームである。このデータストリーム１２０２は、旧来のアプリケーションが生成し、画像処理装置１０００によって受信された処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム３５１である。或は、このデータストリーム１２０２は、画像処理装置１０００のドライバが生成する処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム３５１である。
【０１４１】
出力データストリーム１２０３は、この装置制御指示データストリームの機能拡張フィルタ１２０１が逐次処理を行って出力するデータストリームを示す。入力データに存在した単純な処理要求データストリームに加えて、画像処理装置１０００の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において、機能拡張フィルタ１２０１の属性のような各種属性の指定が可能である。
【０１４２】
この出力データストリーム１２０３において、１行目の「JobStart」はジョブの開始を表す。２行目の「SetJob」は、ジョブ単位の設定の開始を表す。３行目の「ジョブ設定データ」は、この位置に各種のジョブ単位の設定データが存在することを示す。４行目の「BinderStart」は、複数文書をひとまとめにする単位の開始を表す。５行目の「SetBinder」は、複数文書をまとめた単位に対する設定の開始を表す。６行目の「文書束設定データ」は、この位置に複数文書をまとめた単位に対する設定データが存在することを示す。７行目の「DocumentStart」は文書の開始を表すデータである。８行目の「SetDocument」は、文書単位の設定の開始を表す。９行目の「文書設定データ」は、この位置に文書を単位とする設定データが存在することを示す。
【０１４３】
図１５は、機能拡張フィルタ１２０１を操作するためのユーザインターフェース例を示す図である。
【０１４４】
フィルタ操作のためのユーザインターフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによって、Ｗｅｂアプリケーション（Servlet）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置１０００の持つ操作パネル１８から操作するように構成してもよい。
【０１４５】
１３０１は、機能拡張フィルタ１２０１の基本操作画面を示し、この画面を使用して、フィルタオブジェクト属性の確認や変更など操作できる。１３０２は、ジョブ種類の属性を操作するのに使用される。１３１２は、部数属性を設定するのに使用される。１３０３は、ページレイアウト属性を設定するのに使用される。１３０４は、配置順の属性を設定するのに使用される。１３０５は、印刷方法の属性を設定するのに使用される。１３０６は、とじ方向の属性を設定するのに使用される。１３０７は、排紙方法の属性を設定するのに使用される。１３０８は、給紙属性を設定するのに使用される。ヘルプボタン１３０９は、このフィルタの使い方、機能、属性の意味などの説明を表示するのに使用される。「標準に戻す」ボタン１３１０は、各種属性をデフォルト値に戻す場合に指示される。適用ボタン１３１１は、属性値の変更操作が適用され、新しい値を実際にフィルタオブジェクトの属性として設定するために使用される。１３１３はプレビューアイコンを示し、各種属性を画面上で確認するために、いくつかの重要な属性についてその値の状態に応じた模式図が表示される。
【０１４６】
以上説明したように本実施の形態１によれば、以下のような効果がある。
（１）プリント要求受信サーバをファームウェアとして静的に実装し、その受信サーバで受信したデータストリームを、組み込みＪａｖａ（登録商標）環境上に実装した動的ロードや動的リンク可能なフィルタソフトウェアに引き渡すインターフェースを設けた。これにより、安定部分と動的部分を明確に分離できるため、装置のファームウェア全体を動的で冗長なソフトウェアに置き換えるといった非効率な処理や、Ｊａｖａ（登録商標）環境側に実装して二重に持ってしまうといった非効率も防止できる。これにより、コスト面でも、また開発の負荷の面でも合理性のあるフィルタフレームワークが実現できた。更に、納入済みの装置に対するフィルタの動的な追加や置き換えを容易にできるため、低いサポートコストでより迅速に顧客のニーズに対処できる。
（２）より洗練されたＪａｖａ（登録商標）環境でフィルタを実装するため、通常、組み込みシステムでは困難な動的なメモリ管理が有効な高度なパターンマッチングアルゴリズムを容易に実装できる。また高度にモジュール化された再利用性の高いソフトウェアとして設計するため、オブジェクト指向パラダイムに基づくデザインパターンを容易に採用できる。その結果、生産性の高いフィルタ部の実装を実現できる。
（３）フィルタにより、パターンマッチングを用いて、入力データストリームから他の実装との互換性点で問題となるＰＤＬデータを発見し、そのＰＤＬデータを適正に変更することができる。これにより、互換性の問題や障害を低コストで解消できた。特に、顧客環境におかれたシステムや、アプリケーションや画像処理装置のドライバに影響を及ぼすことなく、画像処理装置側に閉じた対応だけで達成できる。また、フィルタを配置しない場合には、フィルタフレームワークが介在することによるオーバヘッドを回避できる構成であるため、フィルタを配置しない場合にも画像処理装置本来のデータ処理性能を維持できている。
（４）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタで、冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換えることができる。このため、ＰＤＬの処理システムの主要部には全く影響を与えずに印刷処理のパフォーマンスを改善できる。又、画像処理装置側で閉じて最適化処理を行うので、顧客環境のシステムやアプリケーションや画像処理装置ドライバを改造する必要もない。またフィルタの生産性が高く、インストールなどのメンテナンスも容易であるため、各顧客の利用形態に即した最適化を行うことができる。
（５）Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタに、新機能を活かすために必要なデータを追加することで画像処理装置の新機能が利用可能となる。このため、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能となる。
（６）Ｊａｖａ（登録商標）環境がファームウェアの更にもう一層のソフトウェアプラットフォームとして、そのファームウェアで動作するフィルタのために、追加機能の設定を操作するためのユーザインターフェースをフィルタに設けた。これにより、顧客の利用形態に即して個別対応した機能拡張が提供できる。
（７）フィルタ処理を、装置の制御に関する指示命令で構成される装置制御データストリーム部、ＰＤＬなど描画に関する指示命令で構成される描画データストリーム部のそれぞれに対して最適なフィルタ処理が可能となった。
（８）夫々のデータストリーム処理の際に、データストリーム属性管理モジュール２２８を介することで、データストリーム処理を行うモジュールは、他のデータストリームで抽出された情報を用いてフィルタリング処理の適用を決定することが可能となった。具体的には、JL(Job Language)と呼称される装置制御データストリームに記載されている、ジョブ種類や、ＰＤＬ種別に従って、描画データへのフィルタ処理の適用することが可能となった。
【０１４７】
［実施の形態２］
図１６は、本発明の実施の形態２に係る送信用データストリーム１４０１を説明する図で、この実施の形態２に係るハードウェア構成及びソフトウェア構成は前述の図１〜図４と同じであるため、その説明を省略する。
【０１４８】
クライアントからの処理要求に応じて、画像処理装置１０００は、クライアントが指定した先へ画像データなどを送信する。その際、画像処理装置１０００は、この送信用データストリーム１４０１を生成し、データ送受信モジュール２０２より送信する。送信用データストリーム１４０１は、送信用データストリームのジョブ種類を記載しているデータストリーム部１４０２と、画像データストリーム１４０３に大別できる。このデータストリーム部１４０２には、画像データそのもの以外の情報が記述されている。このデータストリーム部１４０２のフォーマットは、画像処理装置１０００が備える機能により規定されている。このデータストリーム部１４０２は、データ送信処理を行う際に、ジョブ制御モジュール２０５、或は組み込みアプリケーション２０３により画像データに付加され、送信用データストリームとしてデータ送受信モジュール２０２から送信される。画像データストリーム部１４０３は、画像読み取り部１９から入力されたスキャン画像データストリーム３６０（図３）が画像処理モジュール２０９で処理されることで生成される。尚、ここで送信用データストリーム１４０１、データストリーム部１４０２、画像データストリーム１４０３は前述のように、それぞれフィルタ処理が可能である。
【０１４９】
以上説明した実施の形態２によれば、画像処理装置内に存在するスキャン画像データストリーム３６０、画像データストリーム、送信用データストリーム３５９のそれぞれに対して最適なフィルタ処理が可能となった。
【０１５０】
［他の実施の形態］
上記以外の画像処理装置内に存在するデータストリームとしては、ＰＤＬが処理されることで生成されるディスプレイリスト３５５、画像処理装置において最終的に生成される最終画像データストリーム３５７、最終画像データストリーム３５７を生成するために生成される中間画像データストリーム３５６などがある。それぞれのデータストリームは、画像処理装置が備える機能により形式が規定されている。前述と同様の構成により、それぞれのデータストリームに対して最適なフィルタ処理を行うことができる。
【０１５１】
又、印刷データストリーム中の制御データでなく、印刷対象の文字データ列を扱うようにフィルタを構成してもよい。例えば、印刷対象の文字データ列中から特定の文字列パターンの出現を発見し、特定の文字列パターンに合致した場合に、その文字列に相当する制御データを生成して置換または挿入するような機能拡張フィルタを構成することもできる。例えば、顧客がワードプロセッサのようなアプリケーションを使用してテキストとして入力し、それを画像処理装置の通常のドライバ経由でプリントする際に、特定の文字列をベクタ描画命令などに変換するようにしてもよい。この場合、画像処理装置側のフィルタにおいて、例えば特定文字列を、それに対応する画像（ロゴやマークや透かしなど）を描画するためのベクタ描画命令などの命令列に変換するように構成することができる。
【０１５２】
上記実施の形態では、ファームウェア内部のインタプリタ環境としてＪａｖａ（登録商標）の仮想マシン環境を用いたが、本発明はこれに限定されるものではない。他のスクリプト言語などのインタプリタ環境をファームウェアに組み込んで構成した場合であっても、動的なフィルタ追加とファームウェア部分の分離など同様の効果が得られる。
【０１５３】
また、オブジェクト指向など高効率の開発を可能とするインタプリタ環境は他にも多く存在し、これらを用いてもフィルタ生産性など同様の効果が得られる。特にパターンマッチングに基づくデータストリームの処理に関しては、ｓｅｄ，ＡＷＫ，Ｐｅｒｌなどの選択肢も適している。
【０１５４】
［他の実施形態］
以上、本発明の実施の形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、または一つの機器からなる装置に適用しても良い。
【０１５５】
なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１５６】
プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０１５７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１５８】
またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１５９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１６０】
【図１】本実施の形態に係る画像処理装置のハードウェア構成を説明するブロック図である。
【図２】本実施の形態に係るコントローラのソフトウェア構造を説明する階層図である。
【図３】本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、各モジュールにおいて存在するデータストリームを示す図である。
【図４】本実施の形態に係るコントローラのソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。
【図５】本実施の形態のインタプリタ環境に構築されるフィルタフレームワークのクラスを説明する図である。
【図６】本実施の形態のインタプリタ環境に構築されるフィルタフレームワーク２１９が管理するオブジェクトのインスタンス図で、図６（Ａ）は、１つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示し、図６（Ｂ）は、２つのフィルタが有効な状態のとき、フィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。
【図７】本実施の形態に係るフィルタフレームワークを操作するためのユーザインターフェース例を説明する図である。
【図８】本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。
【図９】本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。
【図１０】本実施の形態に係る処理要求データストリームを説明する図である。
【図１１】本実施の形態に係る描画データストリームに対するフィルタが行う処理を説明する図である。
【図１２】本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。
【図１３】本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。
【図１４】本実施の形態１に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。
【図１５】機能拡張フィルタを操作するためのユーザインターフェース例を示す図である。
【図１６】本発明の実施の形態２に係る送信用データストリームを説明する図である。
【図１７】本発明の実施の形態におけるデータストリーム属性管理モジュールによる、フィルタ適用の可否を決定するための処理を示すフローチャートである。
【図１８】フィルタ適用条件を設定するためのユーザインターフェース例を示す図である。
【特許請求の範囲】
【請求項１】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える情報処理装置であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記ネイティブ環境で、前記入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成するデータ処理手段と、
前記インタプリタ環境で、前記データ処理手段で生成された中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記ネイティブ環境で、前記フィルタ手段との間で、前記データ処理手段で生成された中間データストリームの取り出し、及び書き戻しを行うインターフェース手段と、
前記ネイティブ環境で、前記データ処理手段で生成された中間データストリームを前記フィルタ手段へ前記インターフェース手段を介して引き渡し、フィルタ処理済のデータストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
前記ネイティブ環境で、前記入力データストリームに含まれる、予め指定された項目の情報の内容に基づいて、前記フィルタ管理手段による中間データストリームの前記フィルタ手段への引き渡しの実行を制御する制御手段とを備えることを特徴とする情報処理装置。
【請求項２】
前記フィルタ手段により処理された中間データストリームを情報処理装置に送信する送信手段を更に有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
入力データストリームに含まれる項目の内、前記フィルタ手段へ中間データを引き渡すか否かを決定するための前記予め指定された項目として用いる項目と、該項目を用いて前記フィルタ手段へ引き渡すか否かを決定するための判定条件とを設定する設定手段を更に備え、
前記制御手段は、前記入力データストリームに含まれる前記予め指定された項目の情報と、前記設定手段で設定された判定条件とに基づいて、前記フィルタ管理手段による中間データストリームの前記フィルタ手段への引き渡しの実行を制御することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記データ処理手段において、前記入力データストリームが第１中間ストリームと第２中間ストリームを含む複数の中間ストリームに分離され、
前記制御手段は、前記第１中間ストリームから前記予め指定された項目の情報を抽出し、該情報の内容に基づいて、前記フィルタ管理手段による前記第２中間データストリームの前記フィルタ手段への引き渡しの実行を制御することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
【請求項５】
前記クライアントは、ネットワークを介して接続された情報処理装置或は前記情報処理装置に内蔵されていることを特徴とする請求項１乃至４のいずれかに記載の情報処理装置。
【請求項６】
前記データ処理手段によって生成される中間データストリームは、前記情報処理装置へ装置制御指示を行う装置制御指示データストリーム、前記情報処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項７】
前記フィルタ手段によるフィルタ処理は、中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項１乃至６のいずれかに記載の情報処理装置。
【請求項８】
前記フィルタ手段によるフィルタ処理は、中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項１乃至６のいずれかに記載の情報処理装置。
【請求項９】
前記インタプリタ環境のユーザインターフェースを用いて、前記フィルタ手段における処理パラメータを操作する手段を更に有することを特徴とする請求項１乃至８のいずれかに記載の情報処理装置。
【請求項１０】
前記インタプリタ環境は、当該インタプリタ環境上で動作するプログラムのためのスレッド機構を提供し、前記フィルタ手段は前記スレッド機構による独立した実行コンテクストの下で自律的にフィルタ処理を実行することを特徴とする請求項１乃至９のいずれかに記載の情報処理装置。
【請求項１１】
前記インタプリタ環境は、Ｊａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１乃至１０のいずれかに記載の情報処理装置。
【請求項１２】
前記フィルタ管理手段は、前記フィルタ手段が有する１又は複数のフィルタ機能から選択されたフィルタ機能を、前記インターフェース手段を介して形成される中間データストリーム経路に配置することを特徴とする請求項１に記載の情報処理装置。
【請求項１３】
前記フィルタ管理手段が管理している複数のフィルタ機能の中から、フィルタ機能を選択的に配置させる指示を行うためのユーザインターフェースを提供するフィルタ配置操作手段を更に備えることを特徴とする請求項１２に記載の情報処理装置。
【請求項１４】
前記中間データストリーム経路にフィルタ機能が１つも配置されていない場合には、前記フィルタ管理手段は前記中間データストリームを前記フィルタ手段へ引き渡さないことを特徴とする請求項１２に記載の情報処理装置。
【請求項１５】
更に、前記フィルタ機能を実現するプログラムファイルを外部から装置内に導入して前記フィルタ管理手段の管理下に置くフィルタ導入手段を更に備えることを特徴とする請求項１２に記載の情報処理装置。
【請求項１６】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える情報処理装置の制御方法であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記ネイティブ環境で、前記入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成するデータ処理工程と、
前記インタプリタ環境で、前記データ処理工程で生成された中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記ネイティブ環境で、前記フィルタ工程との間で、前記データ処理工程で生成された中間データストリームの取り出し、及び書き戻しを行うインターフェース工程と、
前記ネイティブ環境で、前記データ処理工程で生成された中間データストリームを前記フィルタ工程へ前記インターフェース工程を介して引き渡し、フィルタ処理済のデータストリームを前記インターフェース工程を介して書き戻すフィルタ管理工程と、
前記ネイティブ環境で、前記入力データストリームに含まれる、予め指定された項目の情報の内容に基づいて、前記フィルタ管理工程による中間データストリームの前記フィルタ工程への引き渡しの実行を制御する制御工程とを備えることを特徴とする情報処理方法。
【請求項１７】
請求項１６に記載のされた情報処理方法をコンピュータに実行させる制御プログラム。
【請求項１８】
制球項１７に記載の制御プログラムを格納した記憶媒体。
【請求項１】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える情報処理装置であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記ネイティブ環境で、前記入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成するデータ処理手段と、
前記インタプリタ環境で、前記データ処理手段で生成された中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記ネイティブ環境で、前記フィルタ手段との間で、前記データ処理手段で生成された中間データストリームの取り出し、及び書き戻しを行うインターフェース手段と、
前記ネイティブ環境で、前記データ処理手段で生成された中間データストリームを前記フィルタ手段へ前記インターフェース手段を介して引き渡し、フィルタ処理済のデータストリームを前記インターフェース手段を介して書き戻すフィルタ管理手段と、
前記ネイティブ環境で、前記入力データストリームに含まれる、予め指定された項目の情報の内容に基づいて、前記フィルタ管理手段による中間データストリームの前記フィルタ手段への引き渡しの実行を制御する制御手段とを備えることを特徴とする情報処理装置。
【請求項２】
前記フィルタ手段により処理された中間データストリームを情報処理装置に送信する送信手段を更に有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
入力データストリームに含まれる項目の内、前記フィルタ手段へ中間データを引き渡すか否かを決定するための前記予め指定された項目として用いる項目と、該項目を用いて前記フィルタ手段へ引き渡すか否かを決定するための判定条件とを設定する設定手段を更に備え、
前記制御手段は、前記入力データストリームに含まれる前記予め指定された項目の情報と、前記設定手段で設定された判定条件とに基づいて、前記フィルタ管理手段による中間データストリームの前記フィルタ手段への引き渡しの実行を制御することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記データ処理手段において、前記入力データストリームが第１中間ストリームと第２中間ストリームを含む複数の中間ストリームに分離され、
前記制御手段は、前記第１中間ストリームから前記予め指定された項目の情報を抽出し、該情報の内容に基づいて、前記フィルタ管理手段による前記第２中間データストリームの前記フィルタ手段への引き渡しの実行を制御することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
【請求項５】
前記クライアントは、ネットワークを介して接続された情報処理装置或は前記情報処理装置に内蔵されていることを特徴とする請求項１乃至４のいずれかに記載の情報処理装置。
【請求項６】
前記データ処理手段によって生成される中間データストリームは、前記情報処理装置へ装置制御指示を行う装置制御指示データストリーム、前記情報処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項７】
前記フィルタ手段によるフィルタ処理は、中間データストリームに新たなデータストリームを追加する処理を含むことを特徴とする請求項１乃至６のいずれかに記載の情報処理装置。
【請求項８】
前記フィルタ手段によるフィルタ処理は、中間データストリームの特定データストリームを、他のデータストリームで置換する処理を含むことを特徴とする請求項１乃至６のいずれかに記載の情報処理装置。
【請求項９】
前記インタプリタ環境のユーザインターフェースを用いて、前記フィルタ手段における処理パラメータを操作する手段を更に有することを特徴とする請求項１乃至８のいずれかに記載の情報処理装置。
【請求項１０】
前記インタプリタ環境は、当該インタプリタ環境上で動作するプログラムのためのスレッド機構を提供し、前記フィルタ手段は前記スレッド機構による独立した実行コンテクストの下で自律的にフィルタ処理を実行することを特徴とする請求項１乃至９のいずれかに記載の情報処理装置。
【請求項１１】
前記インタプリタ環境は、Ｊａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１乃至１０のいずれかに記載の情報処理装置。
【請求項１２】
前記フィルタ管理手段は、前記フィルタ手段が有する１又は複数のフィルタ機能から選択されたフィルタ機能を、前記インターフェース手段を介して形成される中間データストリーム経路に配置することを特徴とする請求項１に記載の情報処理装置。
【請求項１３】
前記フィルタ管理手段が管理している複数のフィルタ機能の中から、フィルタ機能を選択的に配置させる指示を行うためのユーザインターフェースを提供するフィルタ配置操作手段を更に備えることを特徴とする請求項１２に記載の情報処理装置。
【請求項１４】
前記中間データストリーム経路にフィルタ機能が１つも配置されていない場合には、前記フィルタ管理手段は前記中間データストリームを前記フィルタ手段へ引き渡さないことを特徴とする請求項１２に記載の情報処理装置。
【請求項１５】
更に、前記フィルタ機能を実現するプログラムファイルを外部から装置内に導入して前記フィルタ管理手段の管理下に置くフィルタ導入手段を更に備えることを特徴とする請求項１２に記載の情報処理装置。
【請求項１６】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える情報処理装置の制御方法であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記ネイティブ環境で、前記入力データストリームを複数の段階に分けて解釈した各段階において中間データストリームを生成するデータ処理工程と、
前記インタプリタ環境で、前記データ処理工程で生成された中間データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記ネイティブ環境で、前記フィルタ工程との間で、前記データ処理工程で生成された中間データストリームの取り出し、及び書き戻しを行うインターフェース工程と、
前記ネイティブ環境で、前記データ処理工程で生成された中間データストリームを前記フィルタ工程へ前記インターフェース工程を介して引き渡し、フィルタ処理済のデータストリームを前記インターフェース工程を介して書き戻すフィルタ管理工程と、
前記ネイティブ環境で、前記入力データストリームに含まれる、予め指定された項目の情報の内容に基づいて、前記フィルタ管理工程による中間データストリームの前記フィルタ工程への引き渡しの実行を制御する制御工程とを備えることを特徴とする情報処理方法。
【請求項１７】
請求項１６に記載のされた情報処理方法をコンピュータに実行させる制御プログラム。
【請求項１８】
制球項１７に記載の制御プログラムを格納した記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００７−１６４５２６（Ｐ２００７−１６４５２６Ａ）
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願番号】特願２００５−３６０８３６（Ｐ２００５−３６０８３６）
【出願日】平成１７年１２月１４日（２００５．１２．１４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願日】平成１７年１２月１４日（２００５．１２．１４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]