(57)【要約】      （修正有）【課題】ネイティブ環境上に構築されたインタプリタ環境上で動作するフィルタ型アプリケーションによる不正な処理を防止する。【解決手段】フィルタ２２１に入力する入力データストリーム３０７と出力されるデータストリーム３０８の差分を取り、予め定義したクリティカルな処理命令が差分データストリームに含まれているか否かをパターンマッチングにより検出する。クリティカルな処理命令が含まれる場合には、フィルタからの出力データストリーム３０８をキャンセルし、元の入力データストリームに戻すとともに、不正なフィルタ処理が行われたことを通知する。【選択図】図３
2006215720.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記ネイティブ環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記インタプリタ環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記ネイティブ環境または前記インタプリタ環境で、前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出し、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする画像処理装置。
【請求項２】
前記差分データ抽出手段は、前記第１のインタフェース手段により取り出した前記入力データストリームを一時的記憶する一時記憶手段と、
前記入力データストリームを前記フィルタ手段に引き渡し、または前記フィルタ手段が出力する前記フィルタ処理済のデータストリームを受け取る第２のインタフェース手段とを備え、
前記クリティカルな処理が検出されなかった場合には前記第２のインタフェース手段により受信した前記フィルタ処理済のデータストリームをそのまま前記第１のインタフェース手段を介して前記データ処理手段に引き渡し、前記クリティカルな処理が検出された場合は、前記所定の対策処理として、前記フィルタ処理済のデータストリームを破棄し、前記一時記憶手段に保存しておいた前記入力データストリームを前記第１のインタフェース前記手段を介して前記データ処理手段に引き渡すことを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記差分データ抽出手段により抽出する変更点は、前記入力データストリームに追加または変更された部分であって、前記入力データストリームから削除された部分は含まないことを特徴とする請求項１に記載の画像処理装置。
【請求項４】
前記クリティカル処理定義手段は、前記画像処理装置の備える不揮発性メモリに固定的に記録された処理情報であることを特徴とする請求項１に記載の画像処理装置。
【請求項５】
前記クリティカル処理定義手段により定義される前記クリティカルな処理とは、前記画像処理装置から外部の情報処理装置へのデータ送信処理であることを特徴とする請求項１または４に記載の画像処理装置。
【請求項６】
前記クリティカル処理定義手段により定義される前記クリティカルな処理とは、前記画像処理装置内部の記憶領域に保存されるデータを削除あるいは変更する処理要求であることを特徴とする請求項１、４または５に記載の画像処理装置。
【請求項７】
前記フィルタ手段は、新たな部分データストリームを生成し、前記入力データストリームに追加する処理を含むことを特徴とする請求項１に記載の画像処理装置。
【請求項８】
前記フィルタ手段は、前記中間データストリーム中に現れる特定データパターンを発見するパターンマッチングと、パターンにマッチした部分のデータストリームに対応する新たな部分データストリームを生成し置換する処理を含むことを特徴とする請求項１または７に記載の画像処理装置。
【請求項９】
前記インタプリタ環境は、その環境上で動作するプログラムのために命令の読み出し解釈実行をそれぞれ並行して処理するスレッド機構を提供し、
前記フィルタ手段は前記インタプリタ環境が提供する前記スレッド機構による独立した実行コンテクストの下で自律的にそのデータ処理を実行することを特徴とする請求項１に記載の画像処理装置。
【請求項１０】
前記インタプリタ環境はＪａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１または９に記載の画像処理装置。
【請求項１１】
前記中間データストリームは、前記画像処理装置へ装置制御指示を行う装置制御指示データストリーム、前記画像処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、または前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする請求項１または８に記載の画像処理装置。
【請求項１２】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置の制御方法であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記ネイティブ環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記インタプリタ環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記ネイティブ環境または前記インタプリタ環境で、前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出し、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする画像処理装置の制御方法。
【請求項１３】
前記差分データ抽出工程は、前記第１のインタフェース手段により取り出した前記入力データストリームを一時的記憶する一時記憶手段と、
前記入力データストリームを前記フィルタ工程に引き渡し、または前記フィルタ工程が出力する前記フィルタ処理済のデータストリームを受け取る第２のインタフェース手段とを備え、
前記クリティカルな処理が検出されなかった場合には前記第２のインタフェース手段により受信した前記フィルタ処理済のデータストリームをそのまま前記第１のインタフェース手段を介して前記データ処理工程に引き渡し、前記クリティカルな処理が検出された場合は、前記所定の対策処理として、前記フィルタ処理済のデータストリームを破棄し、前記一時記憶工程に保存しておいた前記入力データストリームを前記第１のインタフェース手段を介して前記データ処理工程に引き渡すことを特徴とする請求項１２に記載の画像処理装置の制御方法。
【請求項１４】
前記差分データ抽出工程により抽出する変更点は、前記入力データストリームに追加または変更された部分であって、前記入力データストリームから削除された部分は含まないことを特徴とする請求項１２に記載の画像処理装置の制御方法。
【請求項１５】
前記クリティカル処理定義工程は、前記画像処理装置の備える不揮発性メモリに固定的に記録された処理情報であることを特徴とする請求項１２に記載の画像処理装置の制御方法。
【請求項１６】
前記クリティカル処理定義工程により定義される前記クリティカルな処理とは、前記画像処理装置から外部の情報処理装置へのデータ送信処理であることを特徴とする請求項１２または１５に記載の画像処理装置の制御方法。
【請求項１７】
前記クリティカル処理定義工程により定義される前記クリティカルな処理とは、前記画像処理装置内部の記憶領域に保存されるデータを削除あるいは変更する処理要求であることを特徴とする請求項１２、１５または１６に記載の画像処理装置の制御方法。
【請求項１８】
前記フィルタ工程は、新たな部分データストリームを生成し、前記入力データストリームに追加する処理を含むことを特徴とする請求項１２に記載の画像処理装置の制御方法。
【請求項１９】
前記フィルタ工程は、前記中間データストリーム中に現れる特定データパターンを発見するパターンマッチングと、パターンにマッチした部分のデータストリームに対応する新たな部分データストリームを生成し置換する処理を含むことを特徴とする請求項１２または１８に記載の画像処理装置の制御方法。
【請求項２０】
前記インタプリタ環境は、その環境上で動作するプログラムのために命令の読み出し解釈実行をそれぞれ並行して処理するスレッド機構を提供し、
前記フィルタ工程は前記インタプリタ環境が提供する前記スレッド機構による独立した実行コンテクストの下で自律的にそのデータ処理を実行することを特徴とする請求項１２に記載の画像処理装置の制御方法。
【請求項２１】
前記インタプリタ環境はＪａｖａ（登録商標）プラットフォームに基づくことを特徴とする請求項１２または２０に記載の画像処理装置の制御方法。
【請求項２２】
前記中間データストリームは、前記画像処理装置へ装置制御指示を行う装置制御指示データストリーム、前記画像処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、または前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする請求項１２または１９に記載の画像処理装置の制御方法。
【請求項２３】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築された第１プログラム実行環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行する第２プログラム実行環境を備えるデータ処理装置であって、
前記第１プログラム実行環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記第１プログラム実行環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記第２プログラム実行環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記第１プログラム実行環境または前記第２プログラム実行環境で、前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出し、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とするデータ処理装置。
【請求項２４】
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築された第１プログラム実行環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行する第２プログラム実行環境を備えるデータ処理装置の制御方法であって、
前記第１プログラム実行環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記第１プログラム実行環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記第２プログラム実行環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記第１プログラム実行環境または前記第２プログラム実行環境で、前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出し、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とするデータ処理装置の制御方法。
【請求項２５】
クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出し、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする画像処理装置。
【請求項２６】
クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出し、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする画像処理装置の制御方法。
【請求項２７】
請求項１２乃至２２または２６のいずれかに記載の画像処理装置の制御方法をコンピュータで実行させるためのプログラム。
【請求項２８】
請求項２４に記載のデータ処理装置の制御方法をコンピュータで実行させるためのプログラム。
【請求項２９】
請求項２７または２８に記載のプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プリンタ等の機能を有する画像処理装置、及び画像処理装置の制御方法に関するものである。
【背景技術】
【０００２】
従来、画像処理装置のソフトウェアはリアルタイムオペレーティングシステム（ＲＴＯＳ）の上に静的かつ固定的ないわゆるファームウェアとして構築されることが主流であった。このようなファームウェアは内部的に複数のモジュールから構成されている場合でも全体が単一のロードモジュールに静的にリンクされた状態で装置の不揮発性メモリに記憶され、ファームウェアはシステムの起動時にハードディスクなどの不揮発性メモリからＲＡＭにロードされ実行されるか、または、ＲＯＭなどの不揮発性メモリ上で直接実行される。特に低価格な画像処理装置のような組み込みシステムを構成するファームウェアは一般に、その経済性や安全性などのために部分的なモジュールの動的なロードやリンクを行わないように構成されている。すなわち、ダイナミックリンクを実現するために必要なシンボルテーブルの記憶容量やシンボルのアドレスへの解決を行うための処理に関するオーバヘッドなどが、装置のコストパフォーマンスを悪化させ、また、追加してロードおよびリンクされるサブモジュールによってそのサブモジュールをリンクする以前には十分に評価され達成されていたシステム全体の品質やセキュリティが脅かされる危険があるためである。
【０００３】
しかしながら近年、組み込みシステムのファームウェアのリアルタイムＯＳ上にさらにもう一層のソフトウェア動作環境を設け、追加で設けたソフトウェア動作環境においてダイナミックローディングやダイナミックリンキングや動的なメモリ操作などのソフトウェアの動的な特性をサポートする画像処理装置が開発されている。追加で設けられたソフトウェア動作環境は、インタプリタとひとそろいのアプリケーションプログラミングインタフェース（ＡＰＩ）群やフレームワーク群から構成され、その上で動作するソフトウェアのために一種のＯＳあるいはコンピューティングプラットフォームというべきものを提供する。インタプリタは、所定の命令セットに含まれる命令からなる一連の命令列を逐次的に読み出し解釈し実行する。この命令セットをハードウェアのＣＰＵのための命令セットと同等の位置づけに捉える場合、インタプリタは特に仮想マシン（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ）と呼ばれることもある。ひとそろいのＡＰＩ群およびフレームワーク群は、このソフトウェア動作環境の下層に内在する実際のリアルタイムＯＳが提供する資源やハードウェア資源を抽象化した各種の資源群に対するアクセスを、ソフトウェア動作環境上で動作するソフトウェアのために提供する。資源にはプロセッサによる命令実行コンテクストやメモリ、ファイルシステム、ネットワークインタフェースを含む各種入出力（Ｉ／Ｏ）などがある。特に、命令実行コンテクストは実際のＣＰＵとリアルタイムＯＳが提供するマルチタスク機構とは独立に、ソフトウェア動作環境が独自にインタプリタ上の命令実行コンテクストを管理できる。また、メモリも同様にソフトウェア動作環境が独自のメモリ管理を提供できる。
【０００４】
このようなソフトウェア実行環境上で動作するソフトウェアはインタプリタによって逐次的に読み込み解釈実行されるため、これらの処理の過程で命令列を監視しシステムに悪影響を与える動作を除外できる可能性がある。また、ソフトウェア実行環境上のソフトウェアから各種資源に対するアクセスは、ソフトウェア実行環境が提供するＡＰＩ群やフレームワーク群を経由して間接的に資源を操作するため、この過程でシステムに悪影響を与える動作を除外できる可能性がある。したがって、ファームウェア内部にインタプリタおよびＡＰＩ群とフレームワーク群からなるソフトウェア実行環境の階層を設けるアプローチは、基本的には静的かつ固定的に構成されるべき低コスト組み込みシステムのファームウェアにおいて、ソフトウェアの動的な特性を部分的に導入するために非常に有効である。（例えば、特許文献１、特許文献２を参照。）
【０００５】
上記アプローチにおいて、ソフトウェア実行環境の階層を実現するためにインタプリタとしてＪａｖａ（登録商標）仮想マシンを採用し、Ｊａｖａ（登録商標）に関連するＡＰＩ群やフレームワーク群を採用することができ、本出願人は２００３年に、画像処理装置のファームウェア内部にＪａｖａ（登録商標）プラットフォームを内蔵した複合機であるＭＥＡＰ（登録商標）を製品化している。
【０００６】
従来、内部にネットワークコンピュータを備えたアプリケーションダウンロード型プリンタを用い、コンピュータネットワークから、印刷すべきデータファイルと該データファイルに対応したアプリケーションとを上記プリンタ内にダウンロードし、上記ネットワークコンピュータ上で上記アプリケーションを立ち上げることにより該データファイルを開いてラスタイメージに変換し、印刷するネットワークコンピュータ内蔵プリンタおよびこれを備えたコンピュータネットワークシステムが開示されている。アプリケーションが「Ｊａｖａ（登録商標）アプレット」である場合も開示されている。アプリケーションは印刷データファイルとともにクライアントからプッシュされる場合も、プリンタがアプリケーションサーバなどからプルする場合も開示されている。（例えば、特許文献３を参照。）
【０００７】
従来、複数の周辺機器および周辺機器を動作させるソフトウェアを搭載した複数の端末装置および少なくとも周辺装置を動作させるソフトウェアに関するデータベースを備えたサーバ装置を伝送路に接続させ、所定の通信プロトコルに基づいてネットワーク通信を行うネットワーク通信システムであって、周辺機器は、サーバ装置から周辺機器を動作させるソフトウェアの全部／一部、あるいはソフトウェアが使用するモジュールに対応する最新モジュール情報を要求・獲得するクライアント制御部と、獲得した最新モジュールを端末装置に配付するソフトウェア配信エージェントと、を備えたネットワーク通信システムが開示されている。周辺機器を操作するソフトウェアが使用するクライアント側モジュールとして、「ｊａｖａ（登録商標）アプレット」や「ｊａｖａ（登録商標）アプリケーション」が供給可能であることも開示されている。（例えば、特許文献４を参照。）
【０００８】
一方、上記従来例を基にすることで、本出願人は以下の技術を開示している。
【０００９】
多種多様の顧客のプリンティング環境および様々な環境における要求が存在している。特に基幹系の業務システムでは、ひとたび正常に稼働しはじめたシステム全体の安定性を維持したいという要望はとても強く、プリンタドライバやアプリケーション簡単に変更することは許されないことがある。このような現実のプリンティング環境の制約の中で、プリンタのベンダは顧客環境の側に対応を求めるのではなくプリンタ側の対応によって各種の顧客要望に応えるべき使命がある。たとえば、プリンタの新製品が提供する新しい機能として両面印刷や製本などのフィニッシング機能があった場合、同時に開発された専用のプリンタドライバ経由で新規機能を使用するコマンド列が含まれるプリントジョブを生成する、もしくは顧客の業務アプリケーションが新規追加されたコマンド列を含むプリントジョブを生成するように更新を行うことで、これらの新機能を使いこなせることは当然である。しかしながら、前述のように顧客システムに影響をおよぼさずプリンタ側の対応によって装置の新機能を利用可能とすることが求められている。
【００１０】
顧客システム側に影響を与えずプリンタ側でこれらの要望に対応するためには、プリンタを構成するファームウェアを改造して個別対応リリースする方法があり実際にこの方法がとられている場合もある。しかし、ファームウェアの改造による個別対応は装置全体の品質の再評価を含め開発期間や開発費などが多くかかり、また顧客環境に納品した装置に組み込まれたファームウェアの更新にはフィールドエンジニアなどによる高度なメンテナンスの手間を要するため、顧客要望に速やかに応えるためにもまた費用対効果の面でも課題を残している。実際には、これらの要望のうちの一部はプリンタのファームウェア全体を変更するまでもなく、受信したプリントデータストリームを解釈する前の前処理を追加してそこでプリントデータストリームそのものに変換を施すことによって対応できる。したがって、受信したプリントデータストリームを解釈する前の前処理を実現するソフトウェアだけを他のファームウェアとは独立に柔軟かつ拡張可能に追加できるより動的な機構が求められる。
【００１１】
組み込みシステムのファームウェア内にＪａｖａ（登録商標）プラットフォームのようなソフトウェア動作環境階層を内蔵するＭＥＡＰ（登録商標）のような従来例では、ソフトウェア動作環境上にファームウェアと独立した新たな装置組み込みアプリケーションを開発可能であり、ＡＰＩによってＪａｖａ（登録商標）アプリケーションから装置のプリント機能にアクセスすることはできた。しかしながら、Ｊａｖａ（登録商標）プラットフォームがファームウェア内の組み込みアプリケーション階層に位置づけられているため、同階層においてネイティブの組み込みアプリケーションとして実現されているプリントデータ受信機能やプリントサーバ機能をＪａｖａ（登録商標）アプリケーションのために流用できなかった。すなわち、たとえばネットワーク経由でプリントデータを受信するための各種プリントサービスプロトコルを実装したプリントサーバ機能をＪａｖａ（登録商標）側にも再実装する必要があり、開発負荷や評価負荷ならびに実行時のメモリ面などでも非効率であった。
【００１２】
一方、その他の組み込みシステムのファームウェア内にソフトウェア動作環境階層を持たない従来例においては、組み込みシステム全体がダイナミックリンクやプラグイン可能な構成になっておりシステム全体が動的な構成になってしまっていた。動的な特性が求められる部分が、受信したＰＤＬデータストリームを解釈する前の前処理を柔軟かつ拡張可能に追加する機構だけであることを前提とした場合には、これらの従来例のアプローチはシステム全体を動的なソフトウェアとして構成するためのオーバヘッドに伴うコストアップや品質保証の難しさから低価格の小規模システムには向かなかった。
【００１３】
そこでプリンタが受信したＰＤＬデータストリームに対する解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離する構成をとることによって、ＰＤＬプリンタのカスタマイズの生産性が向上される。（特許文献５を参照）
【特許文献１】特開平１１−２８２６８４号公報
【特許文献２】特開２００３−２５６２１６号公報
【特許文献３】特開平１１−５３１３２号公報
【特許文献４】特開平１１−３０６１０７号公報
【特許文献５】特願２００４−０９３２１５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
特許文献５では、画像処理装置が受信した印刷要求データストリームに対する解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして画像処理装置内のインタプリンタ環境上へ実装する方法が示された。
【００１５】
この手法は、特許記載の印刷要求データストリームに限定するものではなく、例えば画像処理装置がＭＦＰなどの複合機である場合には、「画像読取要求」や「ＦＡＸ送信要求」などのあらゆるジョブ処理要求データストリームに対して、同様にフィルタ部による操作を適用することが可能であることは明らかである。画像処理装置が受信するジョブ処理要求データスリームは、主としてＪＬ（Ｊｏｂ  Ｌａｎｇｕａｇｅ）など印刷装置の給排紙段の指定といった主に装置の制御に関する指示命令で構成される装置制御データストリーム部と、ＰＤＬなど描画に関する指示命令で構成される描画データストリーム部で構成されている。ジョブ処理要求の種類や内容によって、この両方を含む場合と、片方しか含まない場合がある。
【００１６】
装置制御データストリーム部に対して、フィルタリング処理を行うと、例えば印刷要求をＦＡＸ送信要求に変更するなど、元の要求に対して全く異なった種類のジョブ処理を要求するように、データストリームを変更したり、あるいは全く異なったジョブを追加したりすることが可能となる。このことは、フィルタ部によって柔軟な拡張処理が可能であることを示す反面、ユーザの意図しないデータ流出やデータ消失等を引き起こすなどの不正な処理が、フィルタ部によってジョブ処理要求データストリームに組み込まれてしまう可能性を示している。
【００１７】
一般的に、ジョブ処理要求データストリームは、外部ホストコンピュータ等の上で動作するドライバ・ソフトウェア等によって生成される。通常、このドライバ・ソフトウェア等は、画像処理装置の提供者自身が開発、あるいは十分にテストしている。従って、画像処理装置の受信したジョブ要求データストリームに、外部へのデータ送信要求や、装置内部のデータ削除要求が含まれていたとしても、これはユーザの意図するところの処理要求であると考えてよい。
【００１８】
また、上記インタプリタ環境へ実装する通常のアプリケーションソフトについては、画像処理装置の提供者でないサードパーティ・ベンダが開発する場合もあり得るが、背景技術で述べたとおり、提供するＡＰＩ郡やフレームワーク郡において、システムに悪影響を与える動作を除外できる可能性があり、ユーザに不利益を与える可能性のある動作の抑制処理もこれに含めることができる。
【００１９】
しかしながら、フィルタ部では、ジョブ要求データストリームの書き換えによって、ジョブ処理要求データストリームにより実行することのできる全ての動作要求を追加または変更することが可能となる。データストリームそのものを書き換える操作は、フィルタの機能として内部で行われるものであるから、書き換え実行時にその内容をチェックすることはできない。すなわち、有意義な処理を行うものとして提供された筈のフィルタが、ある特定の条件に合致したとき、ユーザに対して不利益を与える処理を行う、ということも有り得る。
【００２０】
もちろん画像処理装置の提供者自身が開発するフィルタであれば、このような不正な処理が混入する余地は極めて少ないが、開発効率や対応時間を短くするためといった観点から、他のアプリケーションと同じくフィルタ部もサードバーティによって開発可能であることが望ましい。従って、画像処理装置の提供者は、サードパーティによって作られたフィルタ部を含むアプリケーションをインストールして良いかどうかを判別する認証テストする体制を十分に整えており、この認証テストに合格したアプリケーションのみを認証テスト合格品として配布している。
【００２１】
しかしながら、例えば悪意あるベンダが存在した場合には、完璧なテストを行うことが極めて困難なケースも有り得る。また、必ずしも悪意は無くとも、フィルタ作成者のミスにより特定条件で不正な処理を行ってしまう、という場合もあり得る。
【００２２】
例えば、あるフィルタが、通常は新規機能追加の処理を行っており、画像処理装置の提供者による認証テストもこの動作をするフィルタとしてパスしてしまったが、日付やある特定のジョブのオーナー名等の特定条件で不正処理が発動し、ジョブ要求データストリームに含まれる画像データや、器機内部に保存されている機密性の高いデータを外部へ送信してしまう、というような、「トロイの木馬」型フィルタが作成可能となってしまう場合も稀に有り得るという問題点があった。
【００２３】
本発明は上記に鑑みてなされたものであって、プリンタが受信したジョブ要求データストリームに対する前処理をフィルタ型アプリケーションソフトとして柔軟かつ拡張可能なソフトウェアとして実装できる構成を保ちつつ、フィルタ型アプリによるクリティカルな動作指令を検出・制御し、不正な処理を防止してユーザが不利益を被ることのない安全性の高いシステムを構築することを目的とするものである。
【課題を解決するための手段】
【００２４】
上記の目的を達成するために本発明による画像処理装置は以下の構成を備える。
【００２５】
即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記ネイティブ環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記インタプリタ環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記ネイティブ環境または前記インタプリタ環境で、前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出す、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする。
【００２６】
さらに好ましくは、前記差分データ抽出手段は、前記第１のインタフェース手段により取り出した前記入力データストリームを一時的記憶する一時記憶手段と、
前記入力データストリームを前記フィルタ手段に引き渡す、または前記フィルタ手段が出力する前記フィルタ処理済のデータストリームを受け取る第２のインタフェース手段とを備え、
前記クリティカルな処理が検出されなかった場合には前記第２のインタフェース手段により受信した前記フィルタ処理済のデータストリームをそのまま前記第１のインタフェース手段を介して前記データ処理手段に引き渡し、前記クリティカルな処理が検出された場合は、前記所定の対策処理として、前記フィルタ処理済のデータストリームを破棄し、前記一時記憶手段に保存しておいた前記入力データストリームを前記第１のインタフェース前記手段を介して前記データ処理手段に引き渡すことを特徴とする。
【００２７】
さらに好ましくは、前記差分データ抽出手段により抽出する変更点は、前記入力データストリームに追加または変更された部分であって、前記入力データストリームから削除された部分は含まないことを特徴とする。
【００２８】
さらに好ましくは、前記クリティカル処理定義手段は、前記画像処理装置の備える不揮発性メモリに固定的に記録された処理情報であることを特徴とする。
【００２９】
さらに好ましくは、前記クリティカル処理定義手段により定義される前記クリティカルな処理とは、前記画像処理装置から外部の情報処理装置へのデータ送信処理であることを特徴とする。
【００３０】
さらに好ましくは、前記クリティカル処理定義手段により定義される前記クリティカルな処理とは、前記画像処理装置内部の記憶領域に保存されるデータを削除あるいは変更する処理要求であることを特徴とする。
【００３１】
さらに好ましくは、前記フィルタ手段は、新たな部分データストリームを生成し、前記入力データストリームに追加する処理を含むことを特徴とする。
【００３２】
さらに好ましくは、前記フィルタ手段は、前記中間データストリーム中に現れる特定データパターンを発見するパターンマッチングと、パターンにマッチした部分のデータストリームに対応する新たな部分データストリームを生成し置換する処理を含むことを特徴とする。
【００３３】
さらに好ましくは、前記インタプリタ環境は、その環境上で動作するプログラムのために命令の読み出し解釈実行をそれぞれ並行して処理するスレッド機構を提供し、
前記フィルタ手段は前記インタプリタ環境が提供する前記スレッド機構による独立した実行コンテクストの下で自律的にそのデータ処理を実行することを特徴とする。
【００３４】
さらに好ましくは、前記インタプリタ環境はＪａｖａ（登録商標）プラットフォームに基づくことを特徴とする。
【００３５】
さらに好ましくは、前記中間データストリームは、前記画像処理装置へ装置制御指示を行う装置制御指示データストリーム、前記画像処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、または前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする。
【００３６】
上記の目的を達成するために本発明による画像処理装置の制御方法は以下の構成を備える。
【００３７】
即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築されたネイティブ環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行するインタプリタ環境を備える画像処理装置の制御方法であって、
前記ネイティブ環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記ネイティブ環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記インタプリタ環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記ネイティブ環境または前記インタプリタ環境で、前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出す、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする。
【００３８】
さらに好ましくは、前記差分データ抽出工程は、前記第１のインタフェース手段により取り出した前記入力データストリームを一時的記憶する一時記憶手段と、
前記入力データストリームを前記フィルタ工程に引き渡す、または前記フィルタ工程が出力する前記フィルタ処理済のデータストリームを受け取る第２のインタフェース手段とを備え、
前記クリティカルな処理が検出されなかった場合には前記第２のインタフェース手段により受信した前記フィルタ処理済のデータストリームをそのまま前記第１のインタフェース手段を介して前記データ処理工程に引き渡し、前記クリティカルな処理が検出された場合は、前記所定の対策処理として、前記フィルタ処理済のデータストリームを破棄し、前記一時記憶工程に保存しておいた前記入力データストリームを前記第１のインタフェース手段を介して前記データ処理工程に引き渡すことを特徴とする。
【００３９】
さらに好ましくは、前記差分データ抽出工程により抽出する変更点は、前記入力データストリームに追加または変更された部分であって、前記入力データストリームから削除された部分は含まないことを特徴とする。
【００４０】
さらに好ましくは、前記クリティカル処理定義工程は、前記画像処理装置の備える不揮発性メモリに固定的に記録された処理情報であることを特徴とする。
【００４１】
さらに好ましくは、前記クリティカル処理定義工程により定義される前記クリティカルな処理とは、前記画像処理装置から外部の情報処理装置へのデータ送信処理であることを特徴とする。
【００４２】
さらに好ましくは、前記クリティカル処理定義工程により定義される前記クリティカルな処理とは、前記画像処理装置内部の記憶領域に保存されるデータを削除あるいは変更する処理要求であることを特徴とする。
【００４３】
さらに好ましくは、前記フィルタ工程は、新たな部分データストリームを生成し、前記入力データストリームに追加する処理を含むことを特徴とする。
【００４４】
さらに好ましくは、前記フィルタ工程は、前記中間データストリーム中に現れる特定データパターンを発見するパターンマッチングと、パターンにマッチした部分のデータストリームに対応する新たな部分データストリームを生成し置換する処理を含むことを特徴とする。
【００４５】
さらに好ましくは、前記インタプリタ環境は、その環境上で動作するプログラムのために命令の読み出し解釈実行をそれぞれ並行して処理するスレッド機構を提供し、
前記フィルタ工程は前記インタプリタ環境が提供する前記スレッド機構による独立した実行コンテクストの下で自律的にそのデータ処理を実行することを特徴とする。
【００４６】
さらに好ましくは、前記インタプリタ環境はＪａｖａ（登録商標）プラットフォームに基づくことを特徴とする。
【００４７】
さらに好ましくは、前記中間データストリームは、前記画像処理装置へ装置制御指示を行う装置制御指示データストリーム、前記画像処理装置へ描画指示を行う描画データストリーム、前記装置制御指示データストリームと前記描画データストリームを処理することで生成される中間画像データストリーム、または前記中間画像データストリームを処理することで生成される最終画像データストリームを含むことを特徴とする。
【００４８】
上記の目的を達成するために本発明によるデータ処理装置は以下の構成を備える。
【００４９】
即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築された第１プログラム実行環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行する第２プログラム実行環境を備えるデータ処理装置であって、
前記第１プログラム実行環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記第１プログラム実行環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記第２プログラム実行環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記第１プログラム実行環境または前記第２プログラム実行環境で、前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出し、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする。
【００５０】
上記の目的を達成するために本発明によるデータ処理装置の制御方法は以下の構成を備える。
【００５１】
即ち、
ハードウェアを構成するプロセッサによって処理される第１命令群に基づいて構築された第１プログラム実行環境で、前記第１命令群とは独立に定義された第２命令群に基づいて構築されたプログラムを動的に実行する第２プログラム実行環境を備えるデータ処理装置の制御方法であって、
前記第１プログラム実行環境で、クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記第１プログラム実行環境で、前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記第２プログラム実行環境で、前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記第１プログラム実行環境または前記第２プログラム実行環境で、前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出し、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする。
【００５２】
上記の目的を達成するために本発明による画像処理装置は以下の構成を備える。
【００５３】
即ち、
クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信手段と、
前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理手段と、
前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ手段と、
前記フィルタ手段との間で前記データストリーム受信手段が受信した前記入力データストリームを取り出し、または前記フィルタ手段が処理した前記フィルタ処理済のデータストリームを前記データ処理手段に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義手段と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ手段が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出手段と、
前記差分データ抽出手段により抽出された差分データストリームに前記クリティカル処理定義手段により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出手段とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする。
【００５４】
上記の目的を達成するために本発明による画像処理装置の制御方法は以下の構成を備える。
【００５５】
即ち、
クライアントからの処理要求を含む入力データストリームを受信するデータストリーム受信工程と、
前記入力データストリームを解釈し、解釈した内容に従って中間データストリームを生成するデータ処理工程と、
前記入力データストリームをフィルタ処理してフィルタ処理済のデータストリームを生成するフィルタ工程と、
前記フィルタ工程との間で前記データストリーム受信工程が受信した前記入力データストリームを取り出し、または前記フィルタ工程が処理した前記フィルタ処理済のデータストリームを前記データ処理工程に引き渡す第１のインタフェース手段と、
特定のクリティカルな処理を定義するクリティカル処理定義工程と、
前記第１のインタフェース手段により取り出された前記入力データストリームと前記フィルタ工程が出力する前記フィルタ処理済のデータストリームとを比較し変更点を抽出する差分データ抽出工程と、
前記差分データ抽出工程により抽出された差分データストリームに前記クリティカル処理定義工程により定義された前記特定のクリティカルな処理が含まれているかどうかを判断するクリティカル処理検出工程とを備え、
前記クリティカルな処理が検出された際に、所定の対策処理を実行することを特徴とする画像処理装置の制御方法。
【００５６】
さらに好ましくは、画像処理装置の制御方法をコンピュータで実行させるためのプログラム。
【００５７】
さらに好ましくは、データ処理装置の制御方法をコンピュータで実行させるためのプログラム。
【００５８】
さらに好ましくは、プログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の効果】
【００５９】
本発明によれば、Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタにおいて、新機能を活かすために必要なデータを追加することで、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能としつつ、たとえそのフィルタが悪意あるベンダによって作成されたとしても、不正な書き換え処理は防止して、ユーザに被害を与えないようにすることが可能となった。
【００６０】
また、例えば悪意あるベンダによる不正な処理だけでなく、誤って混入した同様の変換処理に対しても効力を発揮することは明らかで、本発明を用いることにより、より安全なフィルタ適用処理環境を提供できることになる。
【発明を実施するための最良の形態】
【００６１】
以下、本発明の発明を実施するための最良の形態について図面を用いて説明する。
【実施例１】
【００６２】
図１は画像処理装置のハードウェア構成を説明するブロック図である。
【００６３】
１０００は画像処理装置で、内部で画像処理装置コントローラ１６００からなる、異なる制御系を司る機器で構成されている。本実施例における画像処理装置は具体的には印刷機能、画像読取機能、ＦＡＸやＬＡＮによる画像データの送受信機能などを備えたＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ）装置を想定している。
【００６４】
１は画像処理装置用ＣＰＵで、書き換え可能なＦｌａｓｈＲＯＭ３に記憶された制御プログラムに基づいてシステムバス４に接続されるネットワークコントローラ（ＬＡＮＣ）５を介してローカルエリアネットワーク（ＬＡＮ）２０００に接続されたホストコンピュータ等の複数の外部装置（不図示）と所定のネットワーク通信プロトコルを用いて、前記外部装置から送られる印刷データやプリンタ制御命令等の各種データ送受信要求を統括的に制御する。またＲＯＭ９に記憶された制御プログラム等あるいはディスクコントローラ（ＤＫＣ）１５を介して接続された外部メモリ１０に記憶された制御プログラムやリソースデータ（資源情報）等に基づいてシステムバス４に接続される各種デバイスとのアクセスを統括的に制御し、受信される印刷データを基にラスタコントローラ１２によって出力画像情報を生成し、マーキングエンジン１６に対して画像信号を出力する。
【００６５】
２はＲＡＭであり、ＣＰＵ１の主メモリ、ワークエリア等の一時記憶領域をして用いられる。
【００６６】
３はＦｌａｓｈＲＯＭは書き換え可能であり、９はＲＯＭである。ともに制御プログラムが記憶されている。
【００６７】
４はシステムバスであり、画像処理装置コントローラ１６００を構成する機器間のデータやりとりに使用される。
【００６８】
５はネットワークコントローラ（ＬＡＮＣ）であり画像処理装置コントローラ１６００をＬＡＮ２０００に接続する。
【００６９】
６はＬＥＤでありコントローラの動作状態を示す表示部として用いられており、例えばネットワークコントローラ（ＬＡＮＣ）５とローカルエリアネットワーク（ＬＡＮ）２０００の電気的な接続状態（ＬＩＮＫ）やネットワーク通信モード（１０Ｂａｓｅや１００Ｂａｓｅ、全二重、半二重）等の各種動作状態をＬＥＤの点滅パターンや色で示すこと可能となっている。
【００７０】
１０は外部メモリであり、制御プログラムや保存データなどを保持し、ＤＫＣ１５を介して画像処理装置コントローラ１６００に接続されている。一般的にはハードディスクドライブやＵＳＢメモリなどが使用されている。
【００７１】
１２はラスタコントローラであり、受信される印刷データを基に出力画像情報を生成する。
【００７２】
１６はマーキングエンジン１６であり、ラスタコントローラ１２から出力画像情報を受け取り、処理を行う。
【００７３】
１８は操作パネル（操作部）で画像処理装置１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンや液晶パネルに重ねあわされたタッチパネル、および画像処理装置１０００の動作状態を示す液晶パネルやＬＥＤ等の表示部が配されている。
【００７４】
１９は画像取り込み部で操作パネル１８もしくは、ローカルエリアネットワーク（ＬＡＮ）２０００を介して画像取り込み指示を行うことで画像処理装置内に画像の取り込みを行う。
【００７５】
２０はＦＡＸコントローラであって、電話回線２００１と接続されている。画像処理コントローラ１６００は、操作部またはＬＡＮ２０００から、ＦＡＸ送信ジョブを受け付けると、ＣＰＵ１で動作する制御プログラムによって、ＦＡＸコントローラ２０に指定の画像データを送信する。ここで指定の画像データとは、１９の画像取り込み部で取り込んだ紙原稿の画像であってもよいし、ＬＡＮ２０００からＦＡＸ送信ジョブと共に送られてきた画像データであってもよいし、あるいは外部メモリ１０に保存されている画像データであってもよい。どの画像データを用いるかは、操作パネル１８での指定もしくはＦＡＸ送信ジョブのパラメータとして表されている。ＦＡＸコントローラ２０では、電話回線２００１を通じて指定の送信先と接続し、画像データを送信する。
【００７６】
ＦＡＸコントローラ２０が電話回線２００１を通じてＦＡＸ受信した場合には、システムバス４を通じてＣＰＵ１に受信したことを知らせるイベントが伝えられる。ＦＡＸ受信イベントを受け取ったＣＰＵ１は、動作する制御プログラムによって、ＦＡＸコントローラ２０を介して画像データを受信し、動作モードに応じて、ラスタコントローラ１２を介してマーキングエンジン１６に出力して印刷したり、ＤＫＣ１５を介して外部メモリ１０に保存したりする。
【００７７】
なお、本図で示したマーキングエンジン１６は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華方（熱転写）方式等が挙げられる。
【００７８】
図２は画像処理装置コントローラのソフトウェア構造を示す階層図である。
【００７９】
図において上位のモジュールは下位のモジュールに依存していることを示す。また特に線によって接続したモジュール間には依存関係が存在することを示す。
【００８０】
２０１はネイティブコード部である。この部分は画像処理装置のファームウェアを構成する標準部分であり、ハードウェアであるＣＰＵによって直接実行されるネイティブコードである。この部分はファームウェアとして、装置の開発時に単一のロードモジュールにスタティックリンクされ、生産時に装置の持つ不揮発性メモリに格納されている。ファームウェアは装置の起動時に不揮発性メモリからＲＡＭに展開され、装置の稼働中はＣＰＵがＲＡＭからコードを逐次的に読み出して解釈実行を行うが、実行時のダイナミックリンクは行わない。あるいは、ＲＯＭのようなＣＰＵが直接読み出しアクセス可能な不揮発性メモリにファームウェアを格納して、ＲＡＭへの展開は行わずにＣＰＵがＲＯＭからコードを逐次的に読み出して解釈実行するように構成してもよい。
【００８１】
２０２は組み込みアプリケーションである。画像処理装置の中心機能を提供するための組み込みアプリケーションであり、クライアントからの要求に呼応してサービスを提供する。クライアントがＬＡＮ２０００を介したホスト上のアプリケーション及びドライバソフトの場合は、クライアントはジョブ要求データストリームを生成し、データ送受信モジュール２０３を介して、組み込みアプリケーション２０２へデータストリームを引き渡す。組み込みアプリケーション２０２は制御ＡＰＩ２０４によって、クライアントから送られてきたジョブ要求データストリームの実行を行う。尚、ジョブ要求データストリームは、通常、装置制御指示データストリームと描画データストリームにより構成される。装置の制御に関する記述部は、一般的にはＪＬ（Ｊｏｂ  Ｌａｎｇｕａｇｅ）と呼称される。これは例えばプリントジョブの場合には、描画データの解釈展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、描画データストリームは通常ＰＤＬによって記述されており、主にページごとの描画が記述されている。画像読み取りジョブの場合には、ジョブ要求データストリームは装置制御指示データストリームのみで構成され、読み取り動作を実行した結果として画像データが生成される。
【００８２】
２０３はデータ送受信モジュールであり、クライアントから投入される各種ジョブ要求データストリームを受信したり、ジョブ要求の実行の結果生成される各種データをクライアントや他の装置に送信したりする。データ送受信モジュール２０３は、ＲＴＯＳ２０９を介してプロトコルスタック２１０に依存している。クライアントからのジョブ処理要求は、物理的にはＥｔｈｅｒｎｅｔ（登録商標）などのネットワークやＵＳＢ、ＩＥＥＥ１３９４あるいはＦＡＸ回線などの各種インタフェースを介してクライアントから画像処理装置２０１に送信されるが、それぞれの接続形態に応じてジョブ処理要求を行うためのアプリケーションプロトコルが規定されている。データ送受信モジュールはこのジョブ処理要求のためのアプリケーションプロトコルのサーバ機能を実装している。ジョブ処理サービスのためのアプリケーションプロトコルには、たとえばネットワークプロトコルだけでもＬＰＲやＳＭＢ、ＰＡＰ、ＮｅｔＷａｒｅ（登録商標）など各種の仕様が存在し、その実現のためには膨大な開発コストと品質評価コストを要する。データ送受信モジュール２０３はこれら複数のインタフェースごとにそれぞれ各種存在するサービスプロトコルからなるマルチプロトコルをサポートしている。データ送受信モジュール２０３は装置の記憶装置にジョブ処理要求の待ち行列を構成して、いわゆるスプール機能を実装するように構成してもよい。この場合、データ送受信モジュール２０３は他のジョブを実行している最中のようにジョブをただちに実行できないときにもクライアントからのジョブ処理要求を受け付けて待ち行列に格納しクライアントを解放する。待ち行列に格納されたジョブ処理要求はジョブが実行可能となった時にスケジューリングアルゴリズムに応じて逐次処理される。また、データ送受信モジュール２０３は、組み込みアプリケーションからの指令を受けて、ジョブ実行の結果生成された画像などのデータを、所定のプロトコルに基づいてクライアントや特定の宛先に送信する処理も実行する。例えば、ＦＡＸ送信処理や画像読み取り処理ではこの機能を利用している。
【００８３】
２０４は制御ＡＰＩであり、画像処理装置が提供する装置サービスにアクセスするためのアプリケーションプログラミングインタフェースである。制御ＡＰＩを構成する主要なインタフェースのひとつはプリントジョブを実行したり制御したりするためのインタフェースであり、他にも画像読み取りジョブやＦＡＸ送信ジョブ等の実行したり制御したりするためのインタフェース等が含まれる。
【００８４】
２０５はジョブ制御モジュールである。ジョブ制御モジュールは画像処理装置が提供する各種の画像処理ジョブを制御する。
【００８５】
画像処理ジョブの一例としてプリントジョブの処理を以下に示す。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介して実行を要求されたプリントジョブのジョブ要求データストリームを解釈して、プリントジョブの記述すなわち装置制御指示データストリームと、プリントされるべき印刷データすなわち描画データストリームの記述とを分離する。装置制御指示データストリームは、通常のプリントジョブであることを示すジョブ種別と、印刷データの解釈展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、描画データストリームすなわち印刷データはＰＤＬによって記述されており、主にページごとの描画が記述されている。ジョブ制御モジュール２０５はプリントジョブ記述に応じてトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８、データ管理モジュール２２４を制御する。またジョブ制御モジュール２０５は、印刷データストリームがトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の順に流れ処理されるようにスケジュールする。
【００８６】
さらなる一例として、画像読み取りジョブの動作を示す。操作パネル１８から画像データの取り込み送信指示が行われた場合、組み込みアプリケーション２０２は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの取り込み送信指示を行う。この指示は組み込みアプリケーション２０２が画像読取ジョブ要求の装置制御指示データストリームを生成し、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に引き渡すことで実行される。ジョブ制御モジュール２０５は、画像読み取り部１９から画像をとりこみ、スキャン画像データとしてデータ管理モジュール２２４に引渡し、ＲＡＭ２上に保持して管理する。そして、生成されたスキャン画像データストリームを組み込みアプリケーション２０２へ引き渡すようにスケジューリングする。組み込みアプリケーション２０２は、データ管理モジュール２２４から引き渡されたスキャン画像データストリームを、操作パネル１８から指示された形式に変換し、データ送受信モジュール２０３を介して、操作パネル１８で指示された送信先に送信する。もしくは操作パネル１８から指示された送信先が、内蔵されている外部メモリ１０である場合は、制御ＡＰＩ２０４を介してジョブ制御モジュール２０５に対して、画像データの取り込みと保存指示を行う。つまりジョブ制御モジュール２０５は、画像読み取り部１９から画像をとりこみ、生成されたスキャン画像データストリーム３６０をデータ管理モジュール２２４を介して外部メモリ１０へ格納するようにスケジューリングする。
【００８７】
２０６はトランスレータである。トランスレータはＰＤＬなどの描画データストリームを解釈して、レンダリング処理に適した印刷用中間言語の記述に変換する。レンダリング処理に適した印刷用中間言語によるプリントデータの記述をディスプレイリストと呼ぶ。トランスレータ２０６は各種のＰＤＬ仕様ごとにそれぞれ異なる固有の実装を持ち、どのトランスレータもそれぞれのＰＤＬをレンダラに固有のディスプレイリストへと変換する。
【００８８】
２０７はレンダラである。レンダラはディスプレイリストをラスタ画像に展開する。レンダラ２０７はＲＴＯＳ２０９を介してレンダラドライバ２１２に依存している。
【００８９】
２０８はマーキングエンジン（ＭＥ）制御モジュールである。ＭＥ制御モジュールは画像処理装置において転写紙への画像形成を行うマーキングエンジンを制御する。ＭＥ制御モジュールはＲＴＯＳ２０９を介してＭＥドライバ２１３に依存している。なお、マーキングエンジンは既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華（熱転写）方式などが挙げられる。
【００９０】
２０９はリアルタイムＯＳである。リアルタイムＯＳは、画像処理装置のネイティブコードファームウェアの実行環境を提供するプラットフォームである。リアルタイムＯＳは、その上で動作するソフトウェアのために、ソフトウェア構築のために利用する基本的なサービスや装置が持つハードウェア資源を抽象化したサービスを提供し、また、装置のハードウェアをソフトウェアから利用しやすいインタフェースに抽象化するためのデバイスドライバ構築のフレームワークも提供する。ＲＴＯＳ２０９が提供する機能には、ＣＰＵによる命令実行コンテクストを抽象化したタスク管理、複数の実行コンテクストを仮想的に同時動作させ並行処理（ｃｏｎｃｕｒｒｅｎｔ  ｐｒｏｃｅｓｓｉｎｇ）を実現するマルチタスク機構、タスク間でメッセージのやり取りをしたり同期をとったりするためのタスク間通信（メッセージキューやセマフォなど）、各種のメモリ管理、タイマーやクロック、割り込み管理やＤＭＡの制御などがある。
【００９１】
２１０はプロトコルスタックである。プロトコルスタックはＲＴＯＳ２０９のフレームワークに組み込まれ、より下層の外部インタフェースドライバ２１１が制御する外部インタフェース上にトランスポート層以下のプロトコルを実装する。たとえばネットワークインタフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現し、組み込みアプリケーション層に対してはＲＴＯＳ２０９を介してバークレイソケットなどのアプリケーションプログラミングのためのインタフェースを提供する。またたとえば外部インタフェースがＵＳＢの場合には１２８４．４などのプロトコルを実現する。ＦＡＸ送受信プロトコルもここに含まれている。
【００９２】
２１１は外部インタフェースドライバである。ネットワークインタフェースや、ＩＥＥＥ１３９４、ＵＳＢ、ＲＳ２３２Ｃ、セントロニクス、ＦＡＸ回線などの各種インタフェースへの接続を提供するハードウェアを駆動する。たとえばネットワークの場合、Ｅｔｈｅｒｎｅｔ（登録商標）などのネットワークに接続するためのネットワークインタフェースハードウェアを駆動して物理層のプロトコルを実現する。
【００９３】
２１２はレンダラドライバであり、レンダラを駆動する。レンダラはディスプレイリストをラスタ画像に展開するためのハードウェアである。レンダラはソフトウェアによって実現してもよい。
【００９４】
２１３はマーキングエンジンドライバであり、転写紙への画像形成を行うマーキングエンジンを駆動する。
【００９５】
２１４は操作パネルドライバである。画像処理装置が備える操作パネルの表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。
【００９６】
２１５はインタプリタ環境である。各種のインタプリタ環境、ここではＪａｖａ（登録商標）プラットフォームのランタイム環境に基づき、それに画像処理装置固有のＡＰＩ群とフレームワーク群を追加して構成されているソフトウェアプラットフォームである。このソフトウェアプラットフォームは、その上で動作するインタプリタ言語で記述されたプログラムに対して動的なソフトウェア動作環境を提供する。インタプリタ環境は、ネイティブコードによって実装された部分（２０１に含まれる）と、そのインタプリタ言語で記述されたプログラムとして実装された部分（２２０に含まれる）とを含む。
【００９７】
２１６はインタプリタであり、所定の命令セットによって記述された命令列から逐次的に命令を読み出し解釈し実行する。ここではインタプリタはＪａｖａ（登録商標）仮想マシンによって構成され、命令セットはＪａｖａ（登録商標）のバイトコードである。
【００９８】
２１７は標準のＡＰＩライブラリとフレームワーク群である。ＲＴＯＳ２０９が提供する抽象化された各種コンピューティング資源をさらにインタプリタ環境固有のモデルによって抽象化して、この上で動作するプログラムのための実行環境を提供する。ここではＪａｖａ（登録商標）プラットフォームを構成する標準的なクラスライブラリ群と、ＯＳＧｉのフレームワークによって実現している。Ｊａｖａ（登録商標）プラットフォームはＲＴＯＳ２０９相当の抽象化された機能を提供し、たとえば仮想マシンによる命令実行コンテクストを抽象化したスレッド管理、複数の実行コンテクストを仮想的に同時動作させ並行処理を実現するマルチスレッド機構、スレッド間でメッセージのやり取りをしたり同期をとったりするためのスレッド間通信、高度に抽象化された各種のメモリ管理（コレクションなど）、タイマーやクロック、例外管理、ファイルシステムやネットワークのアクセス、外部入出力装置とのインタフェースなどがある。ＯＳＧｉフレームワークは単一のＪａｖａ（登録商標）仮想マシン上に複数のＪａｖａ（登録商標）アプリケーション（サービス）を動作させる。またアプリケーションのライフサイクルの管理やアプリケーション間通信機能などを提供する。ＯＳＧｉフレームワーク上には、複数のシステムサービスがプリインストールされている。システムサービスには、インタプリタ環境に新たな  アプリケーションを追加したり更新したり削除したりするためのサービス管理サービスや、Ａｐｐｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）クラスを画像処理装置の操作パネルに表示して操作パネルから操作可能に動作させるためのＡｐｐｌｅｔビューアサービスや、Ｓｅｒｖｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）クラスをクライアントのブラウザから操作可能なＷｅｂアプリケーションとして動作させるためのＨＴＴＰサービスなどが用意されている。特にＡｐｐｌｅｔインタフェースに従って実装されたＪａｖａ（登録商標）アプリケーションは、ＡＷＴのＡＰＩなどを経由して間接的に操作パネルドライバ２１４とインタフェースすることができる。
【００９９】
ここで、ＯＳＧｉとはＯｐｅｎ  Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ  Ｉｎｉｔｉａｔｉｖｅの略で、ここではＯＳＧｉの仕様に基いている事を意味する。Ａｐｐｌｅｔ（アプレット）とはＷｅｂブラウザ上で動作するＪａｖａ（登録商標）のクラスを意味する。ＡＷＴ（Ａｂｓｔｒａｃｔ  Ｗｉｎｄｏｗｉｎｇ  Ｔｏｏｌｋｉｔ）とはＪａｖａ（登録商標）に標準で付属するグラフィック関連のクラスライブラリ（再利用可能なプログラム部品）を意味する。ＳｅｒｖｌｅｔとはＷｅｂサーバ上で実行されるＪａｖａ（登録商標）のプログラムモジュールのことである。
【０１００】
尚、本発明の実施例記載のプログラミング用語（クラス、オブジェクト、継承、コンストラクタなど）はＪａｖａ（登録商標）やオブジェクト指向言語（例えばＣ＋＋言語）で周知・慣用のものである。
【０１０１】
２１８はジョブ制御ライブラリである。ジョブ制御ライブラリは制御ＡＰＩ２０４に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインタフェースを提供する。ジョブ制御ライブラリ２１８に制限機構として、アプリケーション２２２が制御ＡＰＩ２０４の中のクリティカルな処理を実行した際に、実行したアプリケーション２２２のＩＤをログ履歴に残したり、実行時にアプリケーションまたはユーザのＩＤをチェックし、特定の条件を満たしていない場合には実行自体を中止するなどの実装を行うことも可能である。
【０１０２】
２１９はフィルタフレームワークである。フィルタフレームワーク２１９は、クリティカル変更検出モジュール２２３を介して、プリントアプリケーション２０２と通信し、ジョブ要求の実行に際してインタプリタ環境上に実装したフィルタプログラム２２１からのジョブ要求データストリームに対する介在を可能とする。
【０１０３】
２２０はインタプリタコード部である。この部分はインタプリタが解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するＡＰＩライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部２０１とインタプリタコード部２２０にまたがって位置づけられるソフトウェアはそれぞれの空間の間をインタフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではＪａｖａ（登録商標）  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）に従って境界部分のプログラミングを行っている。
【０１０４】
２２１はフィルタである。インタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているため組み込みアプリケーション２０２が処理するジョブ要求データストリームに対する処理を行うことができる。
【０１０５】
２２３はクリティカル部検出モジュールである。フィルタフレームワーク２１９を介してフィルタ２２１に渡す入力データストリームと、フィルタ２２１から出力されてくる出力データストリームをフィルタフレームワーク２１９より受け取り、両者の差分を取って、変更点もしくは追加部に別途定義してあるクリティカルな処理指令が含まれているかどうかを検出する。クリティカルな処理定義データは、外部メモリ１０に保持されており、クリティカル部検出モジュール２２３は、データ管理モジュール２２４を介してこの定義を取り出す。そして、もしクリティカルな変更・または追加がされていると判断した場合には、所定の処理を行う。この所定の処理の一例としては、出力データストリームを破棄して、フィルタ処理される前の入力データストリームをそのまま組み込みアプリケーションに引き渡すことである。また、別の一例としては、クリティカルな変更が行われたことを、その変更を行ったフィルタのＩＤなどと共にログデータに出力して記録することである。もちろんこれらを組み合わせても、操作パネル２１４でユーザに知らせる、プリントジョブの場合にはユーザのＰＣのプリントユーティリティやドライバ画面に通知する、管理者にメールで通知するなど、その他の処理を行っても良い。尚、クリティカル部変更モジュール２２３はフィルタ２２１における不正な変更処理を検出することを目的とするモジュールである。よって、データ送受信モジュール２０３が受け取った時点のジョブ処理要求データストリームに、クリティカル定義と一致する処理が含まれていたとしても、それは外部の十分にテストされたドライバなどによって生成された正当な処理であるとみなし、検出はしないようにしている。
【０１０６】
２２４はデータ管理モジュールである。画像処理装置内の画像データストリームなどのデータストリームを外部メモリ１０へ保存管理する。画像データストリーム以外のデータストリームを保存管理可能な構成でもよい。
【０１０７】
図３は画像処理装置コントローラ１６００のソフトウェアモジュール間の基本的なデータの流れを示す図である。前述のモジュールには同一の符号をつけて説明を省略する。
【０１０８】
データ送受信モジュール２０３がクライアントから受信したジョブ処理要求データストリームは、フィルタを介さない場合、３０１によってジョブ制御モジュール２０５に流れる。データストリーム３０１は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。ジョブ制御モジュールはジョブ処理要求データストリームを逐次的に解釈し、データストリーム中の装置制御指示データストリームの解釈を行いそれに応じて制御パス３０２によってトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の制御を行う。一方プリントジョブに含まれるデータストリーム中の描画データストリームは一般にＰＤＬによって記述されたページ記述のコマンドシーケンスであり、これは３０３によってトランスレータ２０６に流れる。トランスレータ２０６は印刷データの解釈を行いディスプレイリストの生成を行う。生成されたディスプレイリストは３０４によってレンダラ２０７に流れる。レンダラ２０７はディスプレイリストの展開を行いラスタ画像データの生成を行う。ラスタ画像データはページ単位に生成される場合もあれば、ページを副走査方向に複数の領域に区切ったバンド単位に生成される場合もある。生成されたラスタ画像データは３０５によってＭＥ制御モジュール２０８に流れる。ＭＥ制御モジュールはラスタ画像データをマーキングエンジンに転送し、マーキングエンジンにおいて転写紙への画像形成が行われる。以上の処理はすべてネイティブコード部分２０１で実装されている。
【０１０９】
一方、ジョブ処理要求データのストリームに対するフィルタ処理を施す場合には、データ送受信モジュール２０３がクライアントから受信したジョブ処理要求データストリームは３０６によってクリティカル部検出モジュール２２３に流れる。クリティカル部検出モジュール２２３が受け取ったデータストリームは、内部で管理するバッファに保存されると共に、そのまま３１１によってフィルタフレームワーク２１９に流れる。データストリーム３０６および３１１は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。フィルタフレームワークのランタイムモジュール２１９はインタプリタ環境上に実装されたフィルタプログラム群を管理している。フィルタフレームワークはジョブ処理要求データストリームを３０７によってフィルタ２２１に流す。データストリーム３０７は、たとえばインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。複数のフィルタが配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。フィルタの実装２２１は入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは３０８によってフィルタフレームワーク２１９に流れる。データストリーム３０８は、たとえばインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。
【０１１０】
フィルタフレームワーク２１９はフィルタ２１１から受け取ったデータストリームを３１２によってクリティカル部検出モジュール２２３に引き渡す。クリティカル部検出モジュールは、受け取った出力データストリーム３１２を、バッファに保存しておいた入力データストリームすなわち３１１と比較し、差分データストリームを抽出する。そして、抽出した差分データストリームを、別途定義してあるクリティカル処理とのマッチングをとって、差分データストリームにクリティカル処理が含まれていない場合には、出力データストリーム３１２をそのまま３０９としてジョブ制御モジュール２０５に流す。データストリーム３１２および３０９は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。以下はフィルタを介さない場合と同様にデータが流れる。
【０１１１】
尚、差分データにクリティカル処理が含まれていた場合には、フィルタ２１１が不正な処理を行ったことになる。このときクリティカル部検出モジュール２２３は、出力データストリーム３１２を破棄し、変わりにバッファに保存しておいた入力データストリーム３０６を３０９に流す。そして、フィルタフレームワークに、この処理を行ったフィルタＩＤおよびベンダＩＤを問い合わせて、その情報をログとして外部メモ１０に出力保存しておく。これによって、ジョブ制御モジュール以下に、ユーザに不利益を与えるような不正な処理が流れないようにしている。
【０１１２】
３１３はフィルタフレームワーク２１９の状態に応じてデータ送受信モジュール２０３からジョブ制御モジュール２０５にいたるデータストリームを制御するための制御パスである。この制御パスは、クリティカル部検出モジュール２２３に一旦入力され、３１０としてデータ送受信モジュール２０３に入力される。これにより、データ送受信モジュール２０３のみならずクリティカル部検出モジュール２２３も同時にストリーム制御が行われることを知ることができ、前述の処理準備等を行うことが可能となる。そして、フィルタフレームワーク２１９が管理するフィルタが有効な状態で配置されている場合はデータストリーム３０６および３１１が有効となりフィルタによる前処理が施される。フィルタフレームワーク２１９が有効なフィルタを配置していない場合には、データストリーム３０１が有効となり、クライアントから受信したデータストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク介在のオーバヘッドを避けられるため、フィルタによるカスタマイズをまったく行わない標準状態のプリンタのデータ処理性能を発揮できる。
【０１１３】
尚、本実施例ではより特徴を明確化するためにクリティカル部検出モジュール２２３をフィルタフレームワーク２１９と分けて構成したが、これら２つを１つのモジュールとして構成することももちろん可能である。こうすることにより、タスク間通信などのオーバーヘッドを減らし、処理を高層化できる可能性もある。
【０１１４】
図４はインタプリタ環境上に構築されるフィルタフレームワークのクラス図である。
【０１１５】
ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１はフィルタフレームワークのランタイム環境を実現するオブジェクトのクラスである。ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１はひとつのＣｏｎｎｅｃｔｏｒクラス４０５のオブジェクトをコンポジション（ｃｏｍｐｏｓｉｔｉｏｎ）として持つ。また、複数（ｎ個）のＦｉｌｔｅｒクラス４０２のオブジェクトへの参照と、複数（ｎ−１個）のＰｉｐｅクラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワークランタイムにインストールされた複数のＦｉｌｔｅｒクラスの具体クラスを管理するためのｉｎｓｔａｌｌｅｄＦｉｌｔｅｒ属性を備える。
【０１１６】
Ｆｉｌｔｅｒ抽象クラス４０２は各種のフィルタクラスを抽象化する抽象クラスである。Ｆｉｌｔｅｒ抽象クラス４０２はフィルタ名称を示すｎａｍｅ属性などを備える。また、ｉｎｐｕｔ属性としてＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したクラスのオブジェクトへの参照を持ち、ｏｕｔｐｕｔ属性としてＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したクラスのオブジェクトへの参照を持つ。Ｆｉｌｔｅｒ抽象クラスの具体クラスたちはＲｕｎｎａｂｌｅインタフェースを実装しｒｕｎメソッドを持つ。ＦｉｌｔｅｒＭａｎａｇｅｒオブジェクトが、管理している各種のフィルタクラスのインスタンスを生成してデータストリームのフィルタ処理のために配置するとき、配置されるそれぞれのフィルタオブジェクトに対応してスレッドを生成し並行動作するスレッドの実行コンテクストでフィルタオブジェクトのｒｕｎメソッドを実行する（すなわち、コンストラクタのパラメータにフィルタオブジェクトを渡してｊａｖａ（登録商標）．ｌａｎｇ．Ｔｈｒｅａｄオブジェクトを生成し、ｓｔａｒｔする）。このようにして個々のフィルタオブジェクトは自律的に動作する。
【０１１７】
ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３はデータストリームの入力元の抽象クラスである。ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３は、呼び出しのたびに逐次的にデータを読み出すことのできるｒｅａｄメソッドを備える。
【０１１８】
ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４はデータストリームの出力先の抽象クラスである。ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４は、呼び出しのたびに逐次的にデータを書き込むことのできるｗｒｉｔｅメソッドを備える。
【０１１９】
Ｃｏｎｎｅｃｔｏｒクラス４０５はインタプリタ環境のオブジェクトとネイティブコードとの間でデータストリームの交換を行うための接点を表現したオブジェクトのクラスである。Ｃｏｎｎｅｃｔｏｒクラス４０５はＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承した具体クラスであるＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍクラスのオブジェクトをコンポジションとして持ち、そのｒｅａｄメソッドによってネイティブコードの印刷要求受信モジュール２０３から流れたデータストリーム３０６を逐次的に読み出すことができる。また、Ｃｏｎｎｅｃｔｏｒクラス４０５はＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍクラスのオブジェクトもコンポジションとして持ち、そのｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームはネイティブコードのジョブ制御モジュール２０５へデータストリーム３０９として流れる。
【０１２０】
Ｐｉｐｅクラス４０５はデータストリームに対して複数のフィルタリング処理を施す際にＦｉｌｔｅｒクラス４０２の一連のオブジェクト間を連結するために用いるオブジェクトのクラスである。Ｐｉｐｅクラス４０５はＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍクラスとＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍクラスのそれぞれのオブジェクトをコンポジションとして持つ。ＰｉｐｅオブジェクトのＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトは接続されており、スレッド間通信を実現する。すなわちあるＰｉｐｅオブジェクトに関して、あるＦｉｌｔｅｒオブジェクトがそのＰｉｐｅオブジェクトが持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームは、別のＦｉｌｔｅｒオブジェクトがそのＰｉｐｅオブジェクトが持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄメソッドによって逐次的に読み出すことができる。
【０１２１】
図５はインタプリタ環境上に構築されるフィルタフレームワークが管理するオブジェクトのインスタンス図である。
【０１２２】
図５（ａ）は１つのフィルタが有効な状態のときフィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。
【０１２３】
Ｃｏｎｎｅｃｔｏｒオブジェクト５０１はＣｏｎｎｅｃｔｏｒクラス４０５のオブジェクトである。
【０１２４】
フィルタオブジェクト５０２はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタオブジェクト５０２のｉｎｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｅａｍオブジェクトの参照が保持されており、ｏｕｔｐｕｔ属性にもＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの属性が保持されている。Ｆｉｌｔｅｒオブジェクトはｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄしたデータストリームに対してフィルタ処理を施す。フィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへとｗｒｉｔｅする。
【０１２５】
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。
【０１２６】
図５（ｂ）は２つのフィルタが有効な状態のときフィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。
【０１２７】
フィルタ１オブジェクト５０３はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ１オブジェクト５０３のｉｎｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。フィルタ１オブジェクト５０３はｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄしたデータストリームに対してフィルタ処理を施す。フィルタ１オブジェクト５０３のｏｕｔｐｕｔ属性にはＰｉｐｅオブジェクト５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。フィルタ１オブジェクト５０３はフィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＰｉｐｅｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへとｗｒｉｔｅする。
【０１２８】
Ｐｉｐｅオブジェクト５０４はＰｉｐｅクラス４０５のオブジェクトである。Ｐｉｐｅオブジェクト５０４は、ＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトを接続された状態で持つ。Ｐｉｐｅオブジェク５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドの呼び出しによって引き渡されたデータストリームは、Ｐｉｐｅオブジェクト５０４が持つＰｉｐｅＩｎｐｕｔＳｔｒｅａｍオブジェクトのｒｅａｄメソッドの呼び出しによってデータストリームとして読み出すことができる。
【０１２９】
フィルタ２オブジェクト５０５はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。フィルタ２オブジェクト５０５のｉｎｐｕｔ属性にはＰｉｐｅオブジェクト５０４が持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍの参照が保持されている。フィルタ２オブジェクト５０５はｉｎｐｕｔの指すＰｉｐｅオブジェクト５０４からｒｅａｄしたデータストリームに対してフィルタ処理を施す。フィルタ２オブジェクト５０５のｏｕｔｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍの参照が保持されている。フィルタ２オブジェクト５０５はフィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍへとｗｒｉｔｅする。
【０１３０】
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。また、同様にして間にＰｉｐｅオブジェクトを挟みこみながらより多くのフィルタオブジェクトをデータストリーム処理のために配置することもできる。
【０１３１】
尚、本実施例では、ＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍからｒｅａｄされるデータストリームがクリティカル部検出モジュール２２３から引き渡されたデータストリームで、ＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍへｗｒｉｔｅされるデータストリームが同検出モジュール２２３に引き渡されるようになっている。すなわち図５（ｂ）の場合に不正な書き換え処理が行われたとすると、フィルタ１、２のいずれがこれを行ったのか検出することはできないが、先に述べたように、フィルタフレームワーク３１１と検出モジュール２２３を一体化する構成をとって、ＰｉｐｅｄＯｕｔｓｔｒｅａｍやＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍとやりとりするデータストリームと差分比較するようにすれば、どちらのフィルタで不正な処理が行われたかを判別することができるようになるのは自明であろう。
【０１３２】
図６はフィルタフレームワークを操作するためのユーザインタフェース例を示す図である。
【０１３３】
フィルタフレームワーク操作のためのユーザインタフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによってＷｅｂアプリケーション（Ｓｅｒｖｌｅｔ）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。あるいは、Ａｐｐｌｅｔ型サービスとして実装して、画像処理装置の持つ操作パネルから操作するように構成してもよい。
【０１３４】
図６（ａ）は画像処理装置のフィルタフレームワークに新しいフィルタを追加インストールするためのユーザインタフェースを示している。
【０１３５】
６０１はフィルタインストール画面の例である。
【０１３６】
６０２はファイル名入力フィールドである。ユーザはこの欄にクライアントコンピュータのファイルシステムにあらかじめ格納されているインストールしたいフィルタクラスのクラスファイルのファイルパスを入力する。
【０１３７】
６０３は参照ボタンである。ユーザがこのボタンをクリックすると、クライアントコンピュータのＷｅｂブラウザが提供するファイル選択ダイアログが開き、クライアントコンピュータのファイルシステム内をブラウズしてインストールしたいフィルタクラスのクラスファイルを選択することができる。ファイル選択ダイアログによってユーザが選択したファイルのファイルパスは自動的にファイル名入力フィールド６０２に入力される。
【０１３８】
６０４はインストールボタンである。ユーザがこのボタンをクリックすると、クライアントコンピュータのＷｅｂブラウザによって、６０２に入力されたファイルパスのクラスファイルが画像処理装置上で待機している新規フィルタインストールのためのＷｅｂアプリケーションに送信される。クラスファイルを受信したＷｅｂアプリケーションは画像処理装置の不揮発性メモリに受信したクラスファイルを格納する。また、クラスファイルをインタプリタ環境に動的にロードしてオブジェクトインスタンスを生成し、生成したフィルタオブジェクトをフィルタフレームワークランタイムが管理する有効フィルタ列のリストの最下流に配置する（もし既に有効なＦｉｌｔｅｒオブジェクトがフィルタ列に存在すれば、新規Ｆｉｌｔｅｒオブジェクトを連結するために新たなＰｉｐｅオブジェクトの生成も行う）。
【０１３９】
本ユーザインタフェースをＷｅｂアプリケーションとして実装している場合、フィルタの実装クラスを装置にアップロードする機構はＲＦＣ（代表的なものはＲＦＣ１８６７「Ｆｏｒｍ−ｂａｓｅｄ  Ｆｉｌｅ  Ｕｐｌｏａｄ  ｉｎ  ＨＴＭＬ」１９９５年１１月発行を参照のこと）によって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用して実装している。したがって、この場合６０２と６０３はクライアントコンピュータのＷｅｂブラウザによって表示されており、６０４はフォームのｓｕｂｍｉｔに対応している。
【０１４０】
また、本ユーザインタフェースをＡｐｐｌｅｔ型のサービスとして実装する場合には、６０１は画像処理装置の操作パネルの表示部に表示される。６０２に指定されるファイルは、画像処理装置がリムーバブル記憶装置を備える場合はリムーバブル記憶メディア中のファイルパスを指定してもよいし、あるいは、ネットワーク経由で画像処理装置からＨＴＴＰやＦＴＰなどのファイル転送プロトコルによって読み出しアクセス可能な共有ファイルをＵＲＬなどによって指定するように構成してもよい。
【０１４１】
図６（ｂ）は画像処理装置のフィルタフレームワークにインストールされているフィルタを配置するためのユーザインタフェースを示している。
【０１４２】
６０５はフィルタ配置画面の例である。
【０１４３】
６０６はフィルタフレームワークのランタイムにインストールされているフィルタ群を一覧するための表である。表の各行はインストールされているフィルタのそれぞれに対応している。表の「選択」列にはチェックボックスが並び、チェックされた行のフィルタが後述する操作の対象として選択される。表の「順序」列にはフィルタが無効状態にある場合には「無効」の表示と、有効状態にある場合にはそのデータストリーム処理の上流から下流にむけて昇順につけられた番号が表示される。表の「名称」列にはフィルタオブジェクトのｎａｍｅ属性に記述されたフィルタ名称が表示される。
【０１４４】
６０７から６１１は選択フィルタに対する操作を指示するためのボタンであり、表６０６の選択列がチェックされた行のフィルタを対象とする操作を指示する。
【０１４５】
６０７は詳細表示ボタンである。ユーザがこのボタンをクリックすると、選択されたフィルタに関する詳細情報が表示される。詳細情報としては、フィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名（ファイルパスやＵＲＬ）、インストールされた日時などがある。
【０１４６】
６０８は上へボタンである。ユーザがこのボタンをクリックすると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の上流方向に一段階変更する。
【０１４７】
６０９は下へボタンである。ユーザがこのボタンをクリックすると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の下流方向に一段階変更する。
【０１４８】
６１０は有効／無効のトグルボタンである。ユーザがこのボタンをクリックすると、選択されたフィルタが有効状態にある場合は無効状態に変更し、無効状態にある場合には有効状態に変更する。無効状態にされたフィルタオブジェクトは削除されるがフィルタクラスはインストールされた状態で残りフィルタフレームワークランタイムの管理下に留まる。
【０１４９】
６１１はアンインストールボタンである。ユーザがこのボタンをクリックすると、選択されたフィルタのクラスファイルを画像処理装置のインタプリタ環境から削除する。
【０１５０】
図９は、データ管理モジュール２２４により管理され、クリティカル部検出モジュール２２３により利用されるクリティカル処理の定義方法を示している。
【０１５１】
図９の（ａ）はクリティカル処理定義一覧表データであって、外部メモリ１０の上に製品出荷時より予め保存されている情報を表している。この場合、フィルタによって書き換えられるとユーザに不利益を引き起こす可能性のある装置制御指示データストリームに含むことのできる命令がすべて、クリティカル処理として固定的に定義されている。この表では、ジョブの種別のみに注目したＤＢとなっているため、どのようなジョブであってもフィルタによって結果的に一覧のジョブ種へ変更されたり、あるいは一覧のジョブ種のジョブが余分に追加された場合は、全てクリティカルな変更が入ったと判断されるようになる。
【０１５２】
図９の（ｂ）はユーザの管理者が操作パネル１８からクリティカルな処理を定義する場合のユーザインタフェースを示している。この例では、前述の固定的なＤＢを用いた場合よりも詳細な定義が可能となっている。
【０１５３】
９０１は設定画面の例である。９０２は設定されているクリティカル処理の一覧を表示する表である。行の各行がそれぞれ１つのクリティカル処理定義を示している。例えば、１行目においては、ジョブ種がＦａｘ  Ｓｅｎｄジョブであって、かつそのジョブの宛先番号属性が０で始まる場合（すなわち外線発信である場合）には、クリティカルな処理であると判断されることを示している。このとき制限指定としては、フィルタ処理を禁止する、すなわち図３における３１３データストリームは破棄し３０６データストリームをそのまま３０９として流す処理を行うことを示している。この例では宛先番号が０で始まらない（すなわち内線宛先）の場合には、クリティカル処理とみなさないことになる。
【０１５４】
各行の先頭にある選択ボタンを押すと、その行が選択される。９１１および９１２はスクロールボタンであって、設定項目数が多く表示仕切れない場合に、表をスクロールさせてすべてを順に表示することができる。表の一番下の行は新規追加行となっており、この行を選択すると、新たな設定行を追加することができる。いずれかの行を選択した直後の状態では、その行の先頭項目「指定ジョブ種」が反転表示され、選択されている項目であることを示している。このとき９０４の入力／変更ボタンを押すと、９０３のサブウィンドウがポップアップし、９１３、９１４の上下ボタンによって反転表示される所望のジョブ種を選択できる。ＯＫボタン９１５によりジョブ種が決定される。続く項目の「指定属性」「制限指定」も同様に入力／変更ボタン９０４を押すとポップアップが出て選択可能となる。反転表示されている選択項目の移動は、９０５および９０６の左右矢印ボタンにより可能である。「指定値」の項目は、細かく設定したい場合があるため同様のポップアップでは選択できない。この項目が反転されているときに入力／変更ボタン９０４を押すと、図９（ｃ）に示すキーボードウィンドウが表示される。このウィンドウにより、所望の文字列の入力が可能となる。前述のＦａｘ  Ｓｅｎｄの例から分かるとおり、指定値の指定には、所謂ワイルドカード”＊”や否定の意味の！の指定を加えることも可能である。例えば、９０２の表の２行目Ｅｍａｉｌ  Ｓｅｎｄの指定においては、特定ドメイン以外に所属する宛先へのＥｍａｉｌ送信をクリティカル処理として定義している。
【０１５５】
行が選択されているとき、その行を９０７・９０８の上下移動ボタンによって上下に移動させることができる。クリティカル処理判断は、票の上部より順に行われるので、これによって処理の順序を調整することも可能である。同種のジョブ種や指定属性に対する処理をいくつか行いたい場合には、９０９の前の行をコピーするボタンを用いて一旦全項目コピーし、変更したい部分のみを９０５、９０６ボタンで選択して変更するということも可能である。不要となった行は９１０の削除ボタンで定義を削除できる。
【０１５６】
図１０はクリティカル検出除外設定を行うためのユーザインタフェースを表す図である。
【０１５７】
１００１は設定例の１画面である。１００２は、インストールされている全フィルタとその除外設定有無を示す表である。図６のユーザインタフェースによりインストールされた全てのフィルタは、１００２の表に反映されて表示される。表の各項目のうち、「除外」欄については、「しない」がデフォルト値となっており、フィルタがインストールされた直後は自動的に「しない」となっておりクリティカル部検出モジュール２２３でのクリティカル検出処理が除外されずに適用されることを示している。また、フィルタにはそのフィルタを製作したベンダＩＤと、フィルタ自身を示すフィルタＩＤが割り当てられている。これらも１００２の表には表示される。「選択」項目のボタンを押すと、その行のフィルタが選択された状態になる。この状態で、１００３の除外する／しないボタンを押すことにより、「する」「しない」を切り替えることができる。「する」に設定したフィルタは、十分に信用されていることを示し、このフィルタをしようとする際にクリティカル検出処理を行わないことを示す。すなわちこの場合には図３におけるクリティカル部検出モジュール２２３の処理が簡略化され、処理のオーバーヘッドが大幅に削減され高速化される。また、特定の行を選択した状態で、１００４の［このベンダのフィルタを全て除外する／しない］ボタンを押すと、１００２の表の１行目または最終行に示したようにフィルタＩＤがワイルドカード”＊”に変更され、このベンダＩＤのフィルタは全て除外される状態となる。このとき、他の行に同じベンダＩＤの別のフィルタが表示されていれば、この行は削除される。また、これ以降にインストールされる同じベンダＩＤの別のフィルタに対してもこの設定は有効となる。逆に、フィルタＩＤがすでにワイルドカードになっている行でこのボタンを押すと、そのベンダのインストールされている各フィルタＩＤの行が復活し、個別に設定可能となる。なお、本実施例では、ベンダＩＤ＝００００を、画像処理装置の提供者と同一としており、そのフィルタは当然ながら十分に信用できるものとして、予め１００２の表にワイルドカードで設定されている。
【０１５８】
図７（ａ）はフィルタ処理の主要な手順を示すフローチャートである。
【０１５９】
この手順は具体的なフィルタクラスのｒｕｎメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成しその入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのｒｕｎメソッドを実行するためにスレッド（Ｔｈｒｅａｄオブジェクト）を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて本手順がそれぞれ自律的に並行処理で動作することになる。
【０１６０】
ステップ７０１では、必要な前処理を行う。前処理には、フィルタが内部的に利用する属性の初期化や、パターンマッチングに使用するパターン記述に対する前処理、入力ストリームや出力ストリームをより使いやすくする機能を付け加える（たとえば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりする）ための修飾クラス（ｊａｖａ（登録商標）．ｉｏ．ＦｉｌｔｅｒＩｎｐｕｔＳｔｒｅａｍやｊａｖａ（登録商標）．ｉｏ．ＦｉｌｔｅｒＯｕｔｐｕｔＳｔｒｅａｍの具体クラス）によってストリームをラップする処理などが含まれる。
【０１６１】
ステップ７０２では、ｉｎｐｕｔ属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。
【０１６２】
ステップ７０３では、入力のデータストリーム中からこのフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。フィルタが操作するべきデータパターンは固定のデータ列そのものでもよいし、正規表現（ｒｅｇｕｌａｒ  ｅｘｐｒｅｓｓｉｏｎ）などの形式言語による記述でもよい。パターン記述に合致するデータの出現をデータストリーム中から発見する各種の実装が広く知られている（ｇｒｅｐ、ｓｅｄ、ＡＷＫ、Ｐｅｒｌなどが有名である）。パターンマッチングを効率よく行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較してハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Ｋｎｕｔｈ−Ｍｏｒｒｉｓ−Ｐｒａｔｔの方法や、Ｂｏｙｅｒ−Ｍｏｏｒｅの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のＪａｖａ（登録商標）プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる（ｊａｖａ（登録商標）．ｕｔｉｌ．ｒｅｇｅｘ）。たとえばデータストリームの上流のパターンに応じて状態が変化し変化した状態に従って下流のパターンの解釈を変えなければならない場合など、正規表現などではかえって記述が困難なほど複雑なパターンマッチングが必要とされる場合には、そのパターンの特徴そのものを評価するアルゴリズムをＪａｖａ（登録商標）プログラムとして書き下してもよい。どれほど複雑なパターンマッチングであっても素直に実装することができる。
【０１６３】
ステップ７０４では、パターンマッチングの結果を判定しパターン記述に合致するデータをデータストリーム中に発見した場合はステップ７０５に進む。そうでなければステップ７０６に進む。
【０１６４】
ステップ７０５では、パターン記述に合致したデータストリーム中の部分データ列に対してこのフィルタの目的に応じた操作を施しその結果で置き換える。
【０１６５】
ステップ７０６では、処理済の部分データ列（すなわち、監視しているパターンが現れなかったデータ列、あるいは、監視しているパターンを含むデータ列に対してステップ７０５の処理を施したデータ列）を出力ストリームに書き込む。
【０１６６】
ステップ７０７では、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了する。そうでなければステップ７０２に戻り、上記の手順を繰り返す。
【０１６７】
尚、７０３のパターンマッチング処理は、７０５で置換しようとしている部分のみに限定する必要は無い。例えば、特定ユーザであることをパターンマッチング処理により検出して、置換する部分は他の部分とすることにより、特定ユーザに限定して効果を発揮するフィルタというものも実装可能である。
【０１６８】
本処理においてポイントとなる部分は、７０２の入力ストリームからデータを読み出す処理と、７０６の処理済みのデータを出力ストリームに書き込む処理であって、これらはフィルタフレームワークのＡＰＩ関数を呼び出すことにより、フィルタアプリに組み込まれる。逆にこれらのＡＰＩ関数を利用すれば、あらゆるタイプの変換処理を実現することができる。つまり、フィルタアプリとは、これらのＡＰＩを利用するアプリケーションのことであるということもできる。
【０１６９】
次に、図７（ｂ）を用いて、クリティカル部検出モジュール２２３の処理を説明する。これは、フィルタ２１１の出力データを監視する処理である。
【０１７０】
７０８の処理において、アプリ側入力ストリームすなわち図３における３０６より入力データを読み出す。
【０１７１】
この読み出したデータは、７０９において、一時バッファに保存する。尚、バッファはＲＡＭ２上に持つが、容量上の都合などにより外部メモリ１０に持つ構成としても無論かまわない。
【０１７２】
そして、それと共に、同じ入力データをフィルタ側出力ストリームすなわち図３における３１１に書き出す。この書き出されたデータが、図７（ａ）における７０２で、フィルタが入力ストリームから読み出すデータとなる。
【０１７３】
次に、フィルタでの処理をまって、フィルタ側入力ストリームすなわち図３における３１２から、フィルタの出力データを読み出す。これは７０６でフィルタが処理して書き込んでくる出力データそのものである。
【０１７４】
そして、７１２において、一時バッファに保存しておいた入力データを読み出した出力データの差分を取る。この差分抽出には、良く知られる文書比較アルゴリズムを用いることができる。効率的な文書比較アルゴリズムとしては、Ｅ．Ｗ．ＭｙｅｒｓによるＯ（ＮＤ）アルゴリズムや、Ｓ．Ｗ．ｍａｎｅｒらによるＯ（ＮＰ）アルゴリズムと言ったものが知られている。取り扱う入出力データストリームがテキストベースであるならば、多くのＯＳで利用可能なｄｉｆｆコマンドを外部コマンドとして実行して、結果を得るように実装してももちろん構わない。もしテキストベースで無い場合には、コマンドの区切りの規定など若干の工夫が必要となるが、本質的には変わらないアルゴリズムで差分抽出が可能である。
【０１７５】
７１３において、抽出した差分データに図９で定義したクリティカル処理が含まれているかどうかのパターンマッチング処理を行う。この処理は例えば、ジョブ種に注目する場合には、ジョブ種属性指定コマンドをマッチさせて、そこで指定のジョブがセットされているかどうかを確認する処理となる。詳細なクリティカル処理を設定している場合にも、同様にそれぞれの属性をより細かく見ていけばよい。
【０１７６】
また、本実施例において、７１３におけるパターンマッチング処理を行う部分は、差分データの中でも出力データで変更または書き加えられた部分のみでよい。入力データにあって出力データから無くなった部分は、フィルタの結果実行されなくなる処理であるから、ここにクリティカル処理が含まれていたとしても通常は問題ない。従って差分データからこの削除された部分を省くことで、パターンマッチング処理を行う部分を少なくでき、処理を高速化できる可能性がある。
【０１７７】
ただし、これは処理系実装依存であって、もし万が一削除されることによって不具合を引き起こす可能性のある処理を持つ処理系があるならば、その際には入力データから削除されたデータ部分に対して、削除されてはまずいパターンについてのマッチングも行う必要がある。この場合には、追加された部分に対するマッチング処理と削除された部分にマッチング処理は別々に行い、それぞれのクリティカル処理の定義も別にしておいた方が処理しやすいことは自明であろう。
【０１７８】
さて、７１４において、クリティカル処理に合致した場合には、７１５の処理を実行する。すなわち、フィルタから出力されたデータストリームはここで破棄され、一時バッファに保存されていた入力データと差し替えられる。つまり、保存しておいた入力データがそのまま処理済データという扱いになる。そして、７１６において今回実行したフィルタＩＤおよびそのベンダＩＤをフィルタフレームワーク２１９に問い合わせて、マッチしたクリティカル処理の種類の情報とともにログに書き出して保存する。尚、７１５および７１６の処理は図９（ｂ）の指定における制限指定に応じて、どちらか一方のみ行う場合もあり得る。また、これら以外に、例えば操作パネル１８に警告を表示したり、管理者にメールで警告送信するなどの処理を加えることもできることは明らかである。
【０１７９】
７１４によりクリティカル処理に合致しないと判断された場合には、フィルタ２２１より受け取った出力データストリーム３１２がそのまま処理済みデータの扱いとなる。
【０１８０】
そして７１７において、処理済データをアプリ側出力ストリームすなわち図３の３０９として出力し、クリティカル検出処理は終了となる。
【０１８１】
尚、これらクリティカル変更検出処理の一連の処理を、入力データストリームおよび出力データストリームの固まりで行うのではなく、パイプラインにより入出力しながら処理を行って高速かしてももちろん構わない。また、図７（ａ）の７０２および７０６から呼ばれるＡＰＩ関数に組み込んで、フィルタフレームワークと一体かすることにより効率化やより詳細な検出を可能にできることは、すでに述べたとおりである。
【０１８２】
図８は本実施例の一例である互換化フィルタが行う処理を説明する図である。
【０１８３】
８０１は互換化フィルタクラスのオブジェクトであり、入力ストリームを読み出してデータストリーム中に現れる互換性の問題を解決する処理を施して出力ストリームに書き込む。互換性の問題として、ここでは代表的なＰＤＬのひとつであるＡｄｏｂｅのＰｏｓｔＳｃｒｉｐｔ（登録商標）仕様を各社ベンダが実装したプリンタ間におけるベンダごとの解釈の差異にもとづく問題とその解決の例を説明する。あるベンダのプリンタは、ＰｏｓｔＳｃｒｉｐｔ（登録商標）のｓｅｔｐａｇｅｄｅｖｉｃｅでは／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎが真のときカスタム用紙扱いとし用紙要求をパネルに表示し、偽のときに指定されたサイズから±５の範囲で定型用紙を検索し定型にない場合はＰｏｓｔＳｃｒｉｐｔ（登録商標）のＰｏｌｉｃｙに従うものと解釈して実装されていた。別のベンダのプリンタでは、／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎが真のとき指定されたサイズそのもののサイズ（範囲なし）で定型用紙を検索し定型にない場合はカスタム用紙扱いとし、偽のとき±５の範囲で定型用紙を検索し定型にない場合はＰｏｓｔＳｃｒｉｐｔ（登録商標）のＰｏｌｉｃｙに従うように実装されていた。ここで、さらに別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、これらのうち後者の解釈に基づく挙動を前提として構築されたとすると、そのシステムにおける印刷要求に対して前者のプリンタでは期待に反するシチュエーションでカスタム用紙扱いとなってしまい「用紙なし」が操作パネルに表示されて印刷されないという顧客の不利益が生ずる。前者のプリンタのベンダはこの互換性の問題に対してできるだけ低コストでできるだけ速やかに解決を顧客に提供することが求められる。この要求は、印刷要求データストリーム中に現れるｓｅｔｐａｇｅｄｅｖｉｃｅの／ＤｅｆｅｒｒｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎパラメータをｔｒｕｅからｆａｌｓｅに変換することで、少なくとも暫定的に、応えることができる。互換化フィルタ８０１はこの問題解決のために働くフィルタオブジェクトであり、入力データストリーム中から／ＤｅｆｅｒｅｅｄＭｅｄｉａＳｅｌｅｃｔｉｏｎがｔｒｕｅで指定されたｓｅｔｐａｇｅｄｅｖｉｃｅに対するパターンマッチングを行いマッチした場合はｆａｌｓｅに置き換えた力データストリームを出力する。
【０１８４】
８０２はフィルタへの入力データストリームの例であり、ＰｏｓｔＳｃｒｉｐｔのプリントデータである。２行目にパターンに合致する部分データが出現する。
【０１８５】
８０３はフィルタからの出力データストリームの例であり、フィルタ処理されたＰｏｓｔＳｃｒｉｐｔ（登録商標）のプリントデータである。２行目のデータの中でｔｒｕｅという文字列がｆａｌｓｅへと置換されている。
【０１８６】
この図８の互換化フィルタの例では、クリティカルな処理は含まれていない。このような描画データであるＰＤＬレベルの記述を変更するフィルタにおいては、クリティカルな処理が混入する余地は、器機制御データストリームより遥かに少ない。
【０１８７】
描画データに含まれ得る不正処理として、考えられる一例は、色の濃さの指定がある。多くの電子写真式プリンタにおいては、トナーの乗り量の最大値が定義されている。例えばＣＭＹＫ４色のプリンタにおいて２７０％が最大のり量であるとした場合、これを超えるトナーの載り量を指定すると、プリンタを破損する恐れがある。しかしながら、ＰＤＬ上はこのような指定も可能である。もし保障されたドライバによって生成される２７０％までしか指定しないＰＤＬを処理することを前提としたプリンタが合ったとすると、フィルタによりこれが２７０％を超える値に書き換えられる、ということはあり得るため、これをクリティカルな属性値として指定し検出する。
【０１８８】
図１１は本実施例の別のフィルタが行う処理を説明する図である。
【０１８９】
図１１の（ａ）において、１１０１は機能拡張フィルタクラスのオブジェクトであり、入力ストリームを読み出して、そのデータに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力ストリームに書き込む。機能拡張の例として、顧客システムが専用のＰＤＬドライバを抱えていてそのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応のときに、そのドライバを変更することなく画像処理装置側のフィルタ対応によって装置の新機能を活かす例をとりあげている。
【０１９０】
機能拡張フィルタ１１０１は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための印刷ジョブ設定をその属性として持つ。フィルタオブジェクトの属性値は装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。ジョブ種類属性は「印刷」「セキュアプリント」などの値をとり、画像処理装置が備える各種ジョブのタイプを表す。部数属性は印刷物のコピーを何セット生成するかを表す。ページレイアウト属性は「１ページ／枚」「２ページ／枚」「４ページ／枚」など１枚の用紙に複数ページを面付けするための指定や「ポスター（２ｘ２）」「ポスター（３ｘ３）」など１ページを拡大して複数枚の用紙に分割印刷するための指定といった、ページレイアウト指定を表す。配置順属性は、「左上から右向き」「左上から下向き」「右上から左向き」「右上から下向き」などの値をとり、ページレイアウト時の各面の配置指定を表す。印刷方法属性は「片面印刷」「両面印刷」「製本印刷」などの値をとり、印刷方法を表す。とじ方向属性は「長辺とじ（左）」「長辺とじ（右）」「短辺とじ（上）」「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。排紙方法属性は「指定しない」「ソート」「ステイプル」「パンチ穴」などの値をとり、フィニッシングの方法を表す。給紙属性は「自動」「手差しトレイ」「カセット」「デッキ」あるいは「普通紙」「厚紙」「色紙」「ＯＨＰ」などの値をとり、画像形成対象とする用紙（転写紙）の給紙指定を表す。
【０１９１】
１１０２は機能拡張フィルタへの入力データストリーム例であり、その内容は旧来のアプリケーションや画像処理装置ドライバが生成する単にページごとの画像形成記述を中心とするＰＤＬやテキストからなる印刷データストリームである。
【０１９２】
１１０３は機能拡張フィルタが逐次処理を行って出力する出力データストリーム例である。入力データに存在した単純な印刷データストリームに加えて、画像処理装置の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において機能拡張フィルタ１１０１属性のような各種属性の指定が可能である。１行目はジョブの開始を表すデータである。２行目はジョブ単位の設定の開始を表すデータである。３行目はこの位置に各種のジョブ単位の設定データが存在することを示す。４行目は複数文書をひとまとめにする単位の開始を表すデータである。５行目は複数文書をまとめた単位に対する設定の開始を表すデータである。６行目はこの位置に複数文書をまとめた単位に対する設定データが存在することを示す。７行目は文書の開始を表すデータである。８行目は文書単位の設定の開始を表すデータである。９行目はこの位置に文書を単位とする設定データが存在することを示す。１０行目は文書記述データの開始を表すデータである。１１行目は文書そのものを表現する文書記述データがこの位置に存在し、ここでは入力データストリーム１１０２に存在した印刷データストリームがこの位置に存在する。１２行目は文書の終了を表すデータである。１３行目は複数文書をまとめる単位の終了を表すデータである。１４行目はジョブの終了を表すデータである。
【０１９３】
図１１（ｂ）は、フィルタ１１０１によって処理されたデータストリームのより具体的な例である。ジョブの種類は通常のプリントであることを示す”Ｎｏｒｍａｌ  Ｐｒｉｎｔ  Ｊｏｂ”が指定されており、レイアウトや配置順など、１１０２の印刷データストリームでは指定されていなかった設定が追加されている。１１０５は、印刷データストリーム１１０２そのものであって、その前後に１１０４および１１０６が追加されている。この追加部分は、図７（ｂ）で説明したクリティカル変更検出処理の差分抽出処理７１２により抽出される。この例においては、特にクリティカルな処理が差分データに含まれていないため、（ｂ）のデータはそのままジョブ制御モジュール２０５に渡され、詳細な処理パラメータ付きで処理されてゆくことになる。
【０１９４】
図１２は機能拡張フィルタを操作するためのユーザインタフェース例を示す図である。
【０１９５】
フィルタ操作のためのユーザインタフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによってＷｅｂアプリケーション（Ｓｅｒｖｌｅｔ）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。あるいは、Ａｐｐｌｅｔ型サービスとして実装して、画像処理装置の持つ操作パネルから操作するように構成してもよい。
【０１９６】
１２０１は機能拡張フィルタ１１０３の基本操作画面であり、フィルタオブジェクト属性の確認や変更など操作できる。
１２０２はジョブ種類属性の操作を行う。
１２０２は部数属性の操作を行う。
１２０３はページレイアウト属性の操作を行う。
１２０４は配置順属性の操作を行う。
１２０５は印刷方法属性の操作を行う。
１２０６はとじ方向属性の操作を行う。
１２０７は排紙方法属性の操作を行う。
１２０８は給紙属性の操作を行う。
１２０９はヘルプボタンであり、このボタンを押すとこのフィルタの使い方、機能、属性の意味などの説明が表示される。
１２１０は「標準に戻す」ボタンであり、このボタンを押すと各種属性がデフォルトの値に設定される。
１２１１は適用ボタンであり、このボタンを押すと属性値の変更操作が適用され新しい値が実際にフィルタオブジェクトの属性に設定される。
１２１２はプレビューアイコンであり、各種属性の確認を助けるためにいくつかの重要な属性についてその値の状態に応じた模式図が表示される。
【０１９７】
ところで、図１１のフィルタがサードパーティ・ベンダによって開発されたものである場合、画像処理装置の提供者は、このフィルタのテストを十分に行い、図１１（ｂ）に示した処理のみしか行われないことを確認した上で認証し、市場にリリースする。
【０１９８】
しかし、例えば、このフィルタが実は悪意ある「トロイの木馬」であった場合、特定の日付を超えると全く異なった不正な処理を実行するということも有り得る。図１１（ｃ）は不正な処理の想定例である。
【０１９９】
ここで、本来意図していた変更処理（ｂ）では、ジョブ種＝Ｎｏｒｍａｌ  Ｐｒｉｎｔとなるべきであった部分が、１１０７において、ジョブ種＝ＦＡＸ  Ｓｅｎｄ  ｊｏｂに変わってしまい、さらに社外の電話番号を宛先に指定するようになってしまっている。電話番号には匿名性の高いものも存在するため、このジョブが実行されてしまったとき電話番号から相手を特定することができるとは限らない。また、そもそも機密データの流出はなんとしても避けたいものである。
【０２００】
そこで、本実施系の実装によれば、図７（ｂ）で説明した処理によって、まず１１０７の部分が抽出されて、この部分に、ジョブ種ＦＡＸ  Ｓｅｎｄ  ｊｏｂおよび社外宛先が含まれることにより、この図１１（ｃ）のフィルタ処理はキャンセルされて、元の印刷データストリーム１１０２がそのままジョブ制御モジュールに送られる。フィルタで追加したかった機能はキャンセルされ実行されないことになるが、データ流出は防止でき、安全性が確保された。
【０２０１】
また、ログにより管理者にこのフィルタが不正であることが通知されるので、管理者は後日このフィルタをアンインストールしたり、画像処理装置の提供者に報告したりすることもできる。
【０２０２】
本実施例によれば、Ｊａｖａ（登録商標）環境に柔軟に拡張可能なフィルタにおいて、新機能を活かすために必要なデータを追加することで、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能としつつ、たとえそのフィルタが悪意あるベンダによって作成されたとしても、不正な書き換え処理は防止して、ユーザに被害を与えないようにすることが可能となった。
【実施例２】
【０２０３】
図１３は第２の実施例のフィルタが行う処理を説明する図である。
【０２０４】
図１３の（ａ）において、１１０１は機能変更フィルタクラスのオブジェクトである。このフィルタは、入力ストリームを読み出して、そのデータに含まれる特定属性の設定命令を抽出し、一定の条件に合致するとき、特定の属性を書き換えたり追加したりし、出力ストリームに書き込む。図１３（ｂ）がその処理の一例であって、ジョブ所有者がある特定の人物であるかどうかをパターンマッチングにより抽出し、一致した場合に、１３０４のページレイアウト４ｉｎ１の指定と配置順：左から右の指定を追加している。尚、元のジョブ１３０２にこれらの属性の指定が無かった場合は、属性の追加処理となるが、あった場合には属性の書き換え処理を行う。
【０２０５】
これによって、特定ユーザの場合には、常に４ｉｎ１の出力をして紙を節約することができるように設定可能となる。設定画面は図１２と同様のものを考えればよく、詳細は省略する。
【０２０６】
さて、図１３の（ｃ）は、実施例１と同様、本来図１３（ｂ）として処理されることを期待してインストールされたフィルタが、不正な書き換え処理を行ってしまった想定例を示す。これは、Ｅｍａｉｌ転送によって外部にデータを流出させてしまう書き換えを行った場合である。このとき、ジョブ種別はＥｍａｉｌ  ｓｅｎｄ、メール宛先はやはり社外ドメインｚｚｚ．ｚｚｚ．ｊｐの宛先となっている。近年、匿名性の高いメールアドレスの取得方法が存在するため、電話番号のときと同様、メールアドレスから相手を特定することは困難であり、そもそも情報流出してから特定したところで、被害は抑えられていないことになる。
【０２０７】
本発明によれば、この様な想定の場合においても、データ流出を未然に防ぐことが可能となる。図７（ｂ）のアルゴリズムがそのまま適用できる。すなわち、差分として抽出された１３０５、１３０６、１３０７の中に、ジョブ種＝Ｅｍａｉｌ  ｓｅｎｄとする指定があることによって、図９（ａ）で定義されているクリティカルな変更処理として一致し、検出される。
【０２０８】
実施例１と同様に、この変更は破棄されて、入力データ１３０２がそのまま処理されると共に、管理者にログ等の情報で知らせられる。
【０２０９】
また、図９（ｂ）に示した詳細クリティカル処理設定を用いると、表２行目のクリティカル定義により、社内ドメイン（図９（ｂ）では”ｘｘｘ．ｘｘｘ．ｊｐ”）宛先の場合には、この書き換え処理を禁止しないようにすることも可能である。このような特定宛先へのデータ転送処理は、特定のユーザ等の印刷しようとするデータを管理したい場合などに応用できるため、全て禁止すればよいというものでもない。本実施例によれば、社内ドメインの場合はデータ管理に利用し、社外ドメインの場合は不正処理として検出することにより実行禁止するというように、場合によって処理を分けて利用することができる。
【実施例３】
【０２１０】
図１４の処理は、より悪質な不正処理の想定例を示す。
【０２１１】
図１４は図１３と同様の特定ユーザのときに強制的に４ｉｎ１出力をすることを期待するフィルタによる処理である。図１１や図１３のときの書き換え処理と異なり、本来フィルタで行いたかった１４０１の書き換え・追加処理は正しく行われている。しかし、さらに余分な別のジョブ１４０２として、Ｅｍａｉｌ  ｓｅｎｄジョブに関する処理が追加されている。この不正処理が検出されずに実行された場合は、実施例１、２のときと異なり、ユーザは所望の処理１４０１は正しく行われているため、不正な処理１４０２が追加されているということに気が付きにくい。
【０２１２】
本発明における図７（ｂ）の処理を用いると、このような場合であっても不正な処理として検出が可能である。すなわち、１４０２の部分が差分データとして抽出され、クリティカルな処理を含むものとしてマッチングされ、検出されるため、実施例１や２と同様、データの流出を防ぐことが可能となるのは明らかであろう。
【０２１３】
また、例えば悪意あるベンダによる不正な処理だけでなく、誤って混入した同様の変換処理に対しても効力を発揮することは明らかで、本発明を用いることにより、より安全なフィルタ適用処理環境を提供できることになる。
【０２１４】
［その他の実施形態］
以上が本発明の実施形態の説明であるが、本発明は、これら実施形態に限られるものではなく、特許請求の範囲で示した機能、または実施形態の構成が持つ機能を達成できる構成であれば、どのようなものであっても適用可能である。
【０２１５】
前述の実施例１から３においては、主としてデータの流出処理に注目して説明したが、本発明によれば、図９（ａ）に記述したようなＦｉｌｅ  ｄｅｌｅｔｅによる特定データの削除処理、あるいはＦｉｌｅ  ｐｕｔによる特定データの上書き処理も検出可能であって、画像処理装置内部に存在するデータの破壊を防ぐことができることはいうまでもない。
【０２１６】
上記実施例では、ファームウェア内部のインタプリタ環境としてＪａｖａ（登録商標）の仮想マシンと環境を用いたが、これに限定されるものではない。他のスクリプト言語などのインタプリタ環境をファームウェアに組み込んで構成した場合であっても、動的なフィルタ追加とファームウェア部分の分離など同様の効果が得られる。また、オブジェクト指向など高効率の開発を可能とするインタプリタ環境は他にも多く、これらを用いてもフィルタ生産性など同様の効果が得られる。特にパターンマッチングに基づくデータストリームの処理に関しては、ｓｅｄ、ＡＷＫ、Ｐｅｒｌなどの選択肢も適している。
【０２１７】
以上の説明から分かるように、第１のプログラム実行環境下、例えば画像形成装置のファームウェア実行環境下や情報処理装置のアプリケーション実環境下で、受信した処理データ（画像形成装置／情報処理装置装置自体の制御コマンド、印刷データ／処理用データ等）のコマンド列・データ列に対してＪａｖａ（登録商標）等の第２のプログラム実行環境を組み込み、上記の処理データに対して所望のプログラマブルなフィルタを掛け、コマンド列・データ列自体の変更／置換を行った場合に、本来のフィルタを掛けない環境下では起こりえないセキュリティ上クリティカルな問題（例えば本来はスキャン→プリントの処理が、フィルタを掛けた結果、スキャン→プリントと同時にＢＯＸ格納されるように処理される。これはユーザが望んだ処理である。しかし、フィルタに誤ったコードが混入していた場合、スキャン→プリントと同時にＢＯＸ格納という処理をしつつＢＯＸ格納されるデータをメールで送信してしまうというケースも想定では有り得る）を検知し排除することが本発明の概念であり目的とするところである。
【０２１８】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体及びプログラムは本発明を構成することになる。
【０２１９】
また、プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２２０】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２２１】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０２２２】
【図１】画像処理装置のハードウェア構成を説明するブロック図である。
【図２】画像処理装置コントローラのソフトウェア構造を示す階層図である。
【図３】画像処理装置コントローラのソフトウェアモジュール間のデータストリームの流れを示す図である。
【図４】インタプリタ環境上に構築されるフィルタフレームワークのクラス図である。
【図５】インタプリタ環境上に構築されるフィルタフレームワークが管理するオブジェクトのインスタンス図である。
【図６】フィルタフレームワークを操作するためのユーザインタフェース例を示す図である。
【図７】フィルタ処理およびクリティカル変更検出処理の主要な手順を示すフローチャートである。
【図８】互換化フィルタが行う処理を説明する図である。
【図９】クリティカルな処理の定義例と、詳細なクリティカル処理を定義するためのユーザインタフェースを示す図である。
【図１０】個別のフィルタに対するクリティカル検出除外設定を行うためのユーザインタフェースを示す図である。
【図１１】機能追加フィルタが行う処理を説明する図と、その正当な処理の一例および不正な処理の一例を示す図である。
【図１２】機能拡張フィルタを操作するためのユーザインタフェース例を示す図である。
【図１３】実施例２の機能変更フィルタが行う処理を説明する図と、その正当な処理の一例および不正な処理の一例を示す図である。
【図１４】実施例３の機能変更フィルタが行う別の不正な処理の一例を示す図である。
【図１】
2006215720.tif 000003
【図２】
2006215720.tif 000004
【図３】
2006215720.tif 000005
【図４】
2006215720.tif 000006
【図５】
2006215720.tif 000007
【図６】
2006215720.tif 000008
【図７】
2006215720.tif 000009
【図８】
2006215720.tif 000010
【図９】
2006215720.tif 000011
【図１０】
2006215720.tif 000012
【図１１】
2006215720.tif 000013
【図１２】
2006215720.tif 000014
【図１３】
2006215720.tif 000015
【図１４】
2006215720.tif 000016