JP4946762B2 - 画像処理装置及びプログラム - Google Patents

Description

本発明は、画像処理装置及びプログラムに関する。

対象ごとに内容を差し替えて印刷する可変印刷技術が知られている。可変データ印刷は、可変印刷又はバリアブル印刷等とも呼ばれる。近年の可変データ印刷では、宛名などのような単なる文字列の差し替えにとどまらず、データベースのレコードに応じてグラフやその他複雑な画像の差し替えも可能となっている。可変データ印刷では、共通のレイアウトデータに対して個々のレコードを適用することにより、それら各レコードに対応した画像を描画する。可変データ印刷のためには、データベースのレコード群、各レコードに対して適用されるレイアウトデータ、各レコードの描画の際に利用される画像等のリソースデータが必要である。

同じ可変データ印刷を繰り返す場合、リソースデータがプリンタに保存されていればそれをそのまま用いることができる。プリンタに保存されていないリソースデータは再度プリンタに送信することとなる。

特許文献１には、可変データ印刷のためのレコード群、レイアウトデータ及びリソースデータなどを圧縮して１つのセットにまとめてクライアントコンピュータからプリンタに送信することが示されている。このプリンタは、受け取ったデータセットを展開して印刷処理を実行すると共に、その展開結果のデータを再度の印刷に備えて保存する機能を備える。また、その保存機能のオン・オフをユーザが指定することもできる。

特許文献２に開示されるプリンタは、フォーム情報をビットマップに展開して圧縮し、その圧縮されたフォーム情報をワークメモリに記憶しておく。そのフォーム情報とのオーバレイが指示されると、記憶されているフォーム情報を読出して伸長し、画像データのビットイメージと重畳してビットマップ展開し、画像イメージを作成するように動作する。

特開２００２−３５８１７３号公報 特開平０６−１０６８１０号公報

本発明は、外部装置から可変データ印刷のための印刷ジョブデータを受け取って描画処理を行う画像処理装置において、個別性の高いリソースデータを除外してリソースデータを保存できるようにすることを目的とする。

請求項１に係る発明は、１以上の主体の各々について１以上のレコードを含む可変データと、前記レコード群に適用する描画プログラムと、前記レコード群についての描画の際に用いられる１以上のリソースデータと、を含む印刷ジョブデータを外部装置から受信する受信手段と、前記描画プログラムを前記可変データ中の各レコードについて実行する際に、前記各レコードの中で指定されているリソースデータを用いることで前記各レコードに対応する出力画像を生成する画像生成手段と、前記画像生成手段による前記各レコードに対応する出力画像の生成において、前記リソースデータごとに当該リソースデータを描画の際に用いる前記主体の数を計数し、その計数の結果に基づき個別性の高いリソースデータを特定する特定手段と、前記印刷ジョブデータを保存する制御を行う保存制御手段であって、前記印刷ジョブデータのうち、前記特定手段が特定した個別性の高いリソースデータを除外して保存する制御を行う保存制御手段と、を備える画像処理装置である。

請求項２に係る発明は、請求項１に係る発明において、前記外部装置に対して、前記保存制御手段により除外されたリソースデータを特定する情報を通知する通知手段と、前記外部装置から、前記印刷ジョブデータに対応する再印刷データを受信した場合、前記再印刷データを前記記憶装置に格納されたリソースデータと組み合わせて前記印刷ジョブデータを再構成する再構成手段と、を備える。

請求項３に係る発明は、請求項１に係る発明において、前記保存制御手段は、前記可変データのレコードの記述のうち、前記特定手段により特定された個別性の高いリソースデータを指定する記述を、ダミーデータを指定する記述に置き換える置き換え手段、を備えることを特徴とする。

請求項４に係る発明は、請求項３に係る発明において、前記各リソースデータの前記出力画像内での画像サイズを求めるサイズ判定手段、を更に備え、前記置き換え手段は、前記可変データのレコードの記述において、前記個別性の高いリソースデータを指定する記述を、ダミーデータを指定する記述に置き換えた場合に、前記ダミーデータを前記削除したリソースデータと同サイズで描画させる指定を前記レコードに追加する、ことを特徴とする。

請求項５に係る発明は、コンピュータを、１以上の主体の各々について１以上のレコードを含む可変データと、前記レコード群に適用する描画プログラムと、前記レコード群についての描画の際に用いられる１以上のリソースデータと、を含む印刷ジョブデータを外部装置から受信する受信手段、前記描画プログラムを前記可変データ中の各レコードについて実行する際に、前記各レコードの中で指定されているリソースデータを用いることで前記各レコードに対応する出力画像を生成する画像生成手段、前記画像生成手段による前記各レコードに対応する出力画像の生成において、前記リソースデータごとに当該リソースデータを描画の際に用いる前記主体の数を計数し、その計数の結果に基づき個別性の高いリソースデータを特定する特定手段、前記印刷ジョブデータを保存する制御を行う保存制御手段であって、前記印刷ジョブデータのうち、前記特定手段が特定した個別性の高いリソースデータを除外して保存する制御を行う保存制御手段、として機能させるためのプログラムである。

請求項１又は５に係る発明によれば、個別性の高いリソースデータを除外してリソースデータを画像処理装置に保存することができる。

請求項２に係る発明によれば、印刷ジョブデータを送ってきた外部装置は、画像処理装置に保存されなかったリソースデータを知り、再印刷の際にそのようなリソースデータのみを選んで画像処理装置に再送することができる。

請求項３に係る発明によれば、個別性の高いリソースデータの代わりにダミーデータを用いて出力画像を生成することができ、可変データ印刷を繰り返す際に個別性の高いリソースデータの印刷を抑制できる。

請求項４に係る発明によれば、ダミーデータを用いて出力画像を生成する際に、ダミーデータを元のリソースデータと同じ画像サイズにすることができるので、出力画像のレイアウトを維持したまま個別性の高いリソースデータの印刷を抑制できる。

本発明の実施形態では、プリンタ又はプリントサーバ等の画像処理装置が、可変データ印刷のための情報リソース（以下単に「リソース」と呼ぶ）一式をクライアントコンピュータから受信し、それらリソース一式を用いて可変データ印刷を実行する。また、画像処理装置は、受信したリソース一式を保存し、再印刷指示の際に保存したリソース一式を利用する。ここで、画像処理装置は、リソース一式のすべてを保存するのではなく、それらリソース一式のうち個人情報のように個別性が高いと判定されるリソースは保存しない。個別性とは、対象（この例ではリソース）が個々の主体に固有のものである可能性のことである。個々の主体に固有の情報は、個別性が高いといえる。個別性が高いものは、守秘の対象となる可能性が高い。個々のリソースが個別性の高いものであるか否かは、可変データ印刷におけるそのリソースの使われ方を監視することで判定する。リソースが個別性の高いものであるか否かの判定結果は、そのリソースについての様々な取り扱いを決定するのに用いることができる。以下では、そのような様々な取り扱いのうち、リソースについての守秘のための保存制御にその判定結果を用いる場合を例にとって説明する。

可変データ印刷では、可変データに含まれる複数のレコードの各々に対して出力画像を生成し、それを用紙等の物理媒体に印刷する。レコードは、人や物などの主体（エンティティ、実体とも呼ばれる）に関する１以上のデータ項目を含んでいる。典型的には１つの主体の情報は１つのレコードに表現されるが、１つの主体の情報が複数のレコードにより表現される場合もある。レコードの中のデータ項目はリソースの一種であり、またそのデータ項目が外部の情報（例えば画像や表のファイル）を指し示す情報である場合、そのような外部情報もリソースの一種である。リソースが守秘対象か否かは、主体固有の情報であるか否かにより判定することができる。すなわち、１つの主体にしか用いられていないリソースは、その主体に固有の情報なので秘密の度合いが高く、逆に複数の主体に用いられているリソースは秘密の度合いが低いと考えられる。そこで、この実施形態では、リソースがいくつの主体についての出力画像に用いられているか（すなわち個別性）を監視し、その監視結果に基づきそのリソースを守秘対象とするか否かを判定するのである。

単純には、可変データ中の全レコードについての出力画像の生成が終わった段階で、１回しか使われていないリソースは、当然ながら１つの主体にしか用いられていないので、個別性が高いといえ、守秘対象と判定してよい。例えば同じ画像や表が１つの主体についての印刷物に繰り返し現れることは通常はあまりないので、このような簡易な判断手法でも実用的には大きな意義がある。

また、あるリソースが１レコードの出力画像中には複数回現れるが、他のレコードの出力画像には現れない場合、そのリソースは１つの主体にしか用いられていないといえるので、個別性が高く、守秘対象と判定できる。

画像処理装置は、守秘対象と判定したリソース以外のリソースを、再印刷に備えて保存するとともに、どのリソースを保存したか（逆に言えばどのリソースは保存しなかったか）を表す情報を、クライアントコンピュータに通知する。クライアントコンピュータは、この通知に基づき、再印刷の際には、画像処理装置に保存されていないリソースを画像処理装置に再送する。

以上、実施形態の概念を説明した。次に、図１を参照して、この概念に従った画像形成システムの構成の一例を説明する。このシステムは、プリントサーバ１００と印刷装置２００とクライアントコンピュータ３００とを備える。印刷装置２００は、画像を用紙に印刷する。プリントサーバ１００は、クライアントコンピュータ３００から入力される印刷データ（例えばページ記述言語で記述される）を、印刷装置２００が取り扱い可能な画像データに変換し、印刷装置２００に提供する。この他、プリントサーバ１００は、クライアントコンピュータ３００から入力される印刷データ（「ジョブ」とも呼ばれる）の実行順序の制御などを行う機能を有していてもよい。プリントサーバ１００と印刷装置２００とは、ネットワーク又はケーブル等の通信路で相互接続された別々の装置であってもよいし、一体の装置として構成されてもよい。プリントサーバ１００は、ネットワーク又はケーブル等の通信路を介してクライアントコンピュータ３００と通信可能となっている。

ここで、プリントサーバ１００は、可変データ印刷機能を備える。可変データ印刷のために用いられるリソースには、例えば、複数のレコードを含んだ可変データ、それら各レコードに適用されるレイアウトプログラム、それらレコードに適用される背景や罫線などのフォーム（書式）データ、それらレコードの印刷画像に組み込まれる画像や表などのデータ、等がある。また、印刷の管理等のために、それら各リソースの属性を記述したファイル（「属性ファイル」と呼ぶ）もある。

可変データ４００のデータ内容の一例を図２に示す。この例では、行４０２の記述"(test01.dbm) STARTDBM"により、この可変データの処理において用いるレイアウトプログラムを指定している。用いられるレイアウトプログラムの識別名は" test01.dbm"であり、" STARTDBM "がレイアウトプログラムを指定する命令である。行４０４以降が、印刷対象となるレコード群のデータである。すなわち、行４０４は、印刷対象のレコード中の各フィールド（項目）のフィールド名を表す。"C#ID"フィールドはレコードのＩＤ（識別情報）を、"C#NAME"フィールドは当該レコードの主体である顧客の名前を示す。また、"C#IMG"及び"C#IMG2"フィールドは、当該レコードの印刷画像に組み込まれる画像の識別情報（例えばファイル名）を、それぞれ示す。

レイアウトプログラムは、可変データ中のレコードから印刷用の画像を生成するための手順を記述したプログラムであり、ページ記述言語等の言語で記述される。レイアウトプログラムには、レコード中の１以上のフィールドの値に基づき画像を生成するコマンドが含まれる。この種のコマンドは、レコードごとに異なる画像を描画する。また、レイアウトプログラムには、レコードに依存しない固定的なデータを描画するコマンド、描画位置を移動させるコマンド、背景フォームを指定するコマンド、など様々なコマンドが含まれ得る。

図３にレイアウトプログラム５００の一例を示す。この例は、図２の可変データ内で指定されているレイアウトプログラム"test01.dbm "の内容である。例えば、行５０２は描画を開始する座標を指定するコマンドである。また、行５０４は、レコード中のフィールド"C#ID"内の文字列の描画を指示するコマンドである。その後に、フィールド"C#NAME"内の文字列の描画を指示するコマンド、フィールド"C#IMG"内の識別情報が示す画像の描画を指示するコマンドが続く。そして、更にその後の行５０６にはフィールド"C#IMG2"内の識別情報が示す画像の描画を指示するコマンドが記述されている。

図４に属性ファイル６００のデータ内容の一例を示す。この例では、属性ファイル６００はＸＭＬ(eXtensible Markup Language)で記述されている。タグ<RESOURCES>が表す要素内に、個々のリソースの属性を示すリソース要素<RESOURCE>が列挙される。個々のリソース要素のタグ<RESOURCE>内に、当該リソースの属性項目が列挙される。例えば、リソース要素６０２は、図２の可変データ（ファイル名"submission.dbf"）の属性項目群を表している。属性項目'Type'は当該リソースの種別を示すものであり、その値"sub"は「可変データ」という種別を表す。また例えばリソース要素６０４は、"trail1V.jpg"というファイル名を持つリソースの種別が「画像」であることを示している。

このシステムでは、クライアントコンピュータ３００が、上述のような可変印刷に必要なリソース一式をひとまとめにしたファイル（「ジョブファイル」と呼ぶ）を生成し、プリントサーバ１００に送信する。

すなわち、図１の説明に戻ると、クライアントコンピュータ３００のリソース管理部３１０には、可変データ、レイアウトプログラム、フォームデータ、画像データ、表やグラフのデータ、属性ファイルなどのリソースが保存されている。リソース管理部３１０は、リソース群を記憶するハードディスク等の記憶媒体と、リソース群の保存・読み出し等を管理する管理プログラムとを含んでいる。ユーザは、クライアントコンピュータ３００上で動作するプリンタドライバ３２０又はアプリケーションプログラムを用いて可変印刷の実行を指示し、その可変印刷で用いるリソース一式を指定する。すると、圧縮部３２２がそれらリソース一式を圧縮して１つのジョブファイルを生成する。生成されたジョブファイルは、ＯＳ（オペレーティングシステム）が備える通信プロトコルスタックとネットワークインタフェースカード等のハードウエアを含んだ通信部３３０により、ＬＡＮ（ローカルエリアネットワーク）等のネットワークを介してプリントサーバ１００に送信される。送信されるジョブファイルの中には、当該ジョブファイル自身の識別情報が含まれる。

このジョブファイルは、プリントサーバ１００の通信部１１０により受信され、解凍部１２０により圧縮状態から展開される。これにより元のリソース一式が得られ、これらリソース一式はＰＤＬ処理部１３０に渡される。ＰＤＬ処理部１３０は、それらリソース一式を用いて可変印刷のための描画処理を実行する。すなわち、リソース一式の中に含まれる可変データ中のレコードごとに、レイアウトプログラムを実行することで、各レコードに対応する印刷画像を生成する。この実行の際、レコードの中で指定された他のリソース（画像や表など）がリソース管理部１５０から読み出され、印刷画像に組み込まれる。

ＰＤＬ処理部１３０の機能は、レイアウトプログラムを解釈する解釈部１３２と、その解釈部１３２の解釈結果（例えばディスプレイリスト等の中間データ）を処理してラスター画像を描画する描画部１３６とに分けることができる。解釈部１３２及び描画部１３６は、リソース管理部１５０に保存されたリソースを利用する。

監視部１３４は、解釈部１３２による各レコードに対するレイアウトプログラムの実行状況を監視することで、各リソースの使用状況を求める。そして、その使用状況から、ジョブファイル中の各リソースが守秘対象であるか否か、すなわち個別性の高いものであるか否か、を判定する。具体的な判定のための処理手順は、後で説明する。

描画部１３６が生成した各レコードに対応する出力画像は、出力部１４０により、ネットワーク又は通信ケーブルを介して印刷装置２００に送られ、印刷される。

リソース管理部１５０は、クライアントコンピュータ３００から受け取ったジョブファイル中のリソース群の保存のための管理を行う。リソース管理部１５０は、格納制御部１５２，通知部１５４，及び再構成部１５６を備える。格納制御部１５２は、ジョブファイル中のリソース群のうち、守秘対象と判定されたものを保存対象から削除する制御を行う。通知部１５４は、保存対象から削除したリソースを示す情報（又は保存したリソースを示す情報）をクライアントコンピュータ３００に通知する。この例では、属性ファイル６００の中にそのような情報を組み込んでクライアントコンピュータ３００に送る。再構成部１５６は、保存したジョブファイル（ただし守秘対象のリソースは削除されている）に対応する再印刷のジョブファイル（守秘対象のリソース群が含まれる）がクライアントコンピュータ３００から到来した場合に、前者と後者のジョブファイルのリソース群から元のジョブファイルを再構成する。再印刷は、再構成されたジョブファイルに基づき実行される。

次に、新たなジョブファイルの処理を指示されたときの解釈部１３２の処理手順の一例を、図５を参照して説明する。まず、この処理では、解釈部１３２は、処理対象のレコードの番号を示す制御変数ｉを１に初期化する（Ｓ１）。次に解釈部１３２は、そのジョブファイル中の可変データからｉ番目のレコードを取得し（Ｓ２）、そのレコードに対してジョブファイル中のレイアウトプログラムを実行する（Ｓ３）。例えば、図２の可変データ例の行４０６に示されるレコードに対して、図３に例示したレイアウトプログラムを適用した場合、当該レコードのＩＤ、「鈴木太郎」と言う文字列、"trail1V.jpg"の画像、"secure1.jpg"の画像、が順に並んだ出力画像が生成される。このステップＳ３の処理の中で、監視部１３４が例えば図６に例示するような処理を行い、リソースの使用状況を監視する（図６の手順については後で詳述）。ステップＳ３が終了すると、現在のレコードが可変データ中の最後のレコードであるか否かを判定し（Ｓ４）、最後のものでなければ変数ｉを１だけ増加させ（Ｓ５）、ステップＳ２〜Ｓ４の処理を繰り返す。可変データの最後のレコードまで処理が完了すると、解釈部１３２は、リソース管理部１５０に対し、保存リソースの機密化処理の実行を依頼する（Ｓ６）。この機密化処理については、後で説明する。

次に、図６を参照して、監視部１３４によるリソース使用状況の記録処理の手順の一例を説明する。この手順では、図７に例示する管理情報リストを用いる。このリストには、リソースごとに、その識別情報（リソースＩＤ）と、機密フラグの値とが含まれる。リソースＩＤとしては、レコード中に記述されたリソースの文字列（例えば顧客の氏名の文字列やリソースのファイル名）を用いればよい。機密フラグは、当該リソースが守秘対象であるか否かを示すフラグである。この例では機密フラグの値「１」は守秘対象であることを示し、「０」は守秘対象でないことを示す。

監視部１３４は、ステップＳ３でのレイアウトプログラムの実行において、対象のレコードについての画像生成の際にリソースが用いられるごとに、図６の手順を実行する。この手順では、監視部１３４は、管理情報リストの中に読み出された現在のリソースと同じリソースがあるか否かを調べる（Ｓ１１）。同じリソースがなければ、監視部１３４は、現在のリソースについてのエントリをそのリストに登録する（Ｓ１２）。このとき、当該リソースについての機密フラグの値は初期値「１」に設定される。一方、現在のリソースと同じリソースが管理情報リスト上に存在する場合は、そのリスト上の当該リソースの機密フラグの値を「０」に変更する（Ｓ１３）。機密フラグの値が既に「０」である場合は、その値のままとする。ステップＳ１２又はＳ１３により、現在のリソースについての処理は終了する。

１レコードについての画像生成において複数のリソースが用いられる場合は、個々のリソースについて図６の手順が実行される。例えば、図２の可変データの例で、画像ファイルのリソースのみを監視対象とする場合、１レコード中には"C#IMG"及び"C#IMG2"の２つの画像リソースが存在するので、それら２つのリソースについて図６の手順が実行される。

図７の上段のリスト（ａ）は、図２の例における最初のレコード（行４０６）の処理が終了した時点での管理情報リストである。そのレコード中の"trail1V.jpg"及び"secure1.jpg"は、当該ジョブにおいて初出なので、機密フラグは共に「１」に設定される。下段のリスト（ｂ）は、２つ目のレコードの処理が終了した時点のものである。２つ目のレコードの処理では、リソース"trail1V.jpg"が用いられるが、これは既に管理情報リストに登録されているので、監視部１３４はリスト上の"trail1V.jpg"の機密フラグを「０」に変更する。一方、リソース"secure2.jpg"は初出なので、機密フラグを「１」として新たにリストに登録される。

以上に説明した図６の手順では、可変データ中の全レコードについての出力画像の生成が終わった段階で、１回しか使われていないリソースの機密フラグは「１」となり、２回以上使われているリソースの機密フラグは「０」となる。したがって、全レコードの処理の中で１回しか使われなかったリソースのみが守秘対象と判定されることになる。

なお、図６に例示した手順はあくまで一例であり、同様の処理が実現される手順であればどのような手順を用いてもよい。

なお、図６の手順は、レコードの処理の際に用いられるすべてのリソースについて行ってもよいが、この手順の実行対象となるリソースをユーザ側が絞り込めるようにしてもよい。実際の可変データは図２に例示したものよりもフィールド数が遙かに多いことが一般的であり、すべてのフィールドに示されたリソースについて上述のような処理を行っていたのでは、画像処理装置の処理負荷が大きくなりすぎる可能性がある。一方、守秘対象となる可能性があるフィールドは、ユーザ側にはある程度目星がついていることが多いので、監視対象をそのようなフィールドのみに絞るのである。図３に例示したレイアウトプログラムでは、行５０６の中のコマンド"SEC1"が、そのような監視対象を指定するものとなっている。すなわち、このコマンドにより監視部１３４が呼び出され、直前に読み込まれたリソースを対象として監視部１３４が図６のような処理を実行する。

次に、図８を参照して、ステップＳ６で呼び出されたリソース管理部１５０の処理手順の一例を説明する。この手順では、まずリソース管理部１５０内の格納制御部１５２が、監視部１３４の作成した管理情報リストの中から機密フラグが「１」となっているリソースを特定する。そして、それまで処理していたジョブファイルのリソース群の中から、それら特定したリソースを削除し、残ったリソース群を当該ジョブファイルの保存データとして保存する。例えば、図２に例示した可変データを含むジョブの場合、リソース管理部１５０に保存されるデータの中には、"secure1.jpg"や"secure2.jpg"等の画像ファイルは含まれない。保存データ内に残るのは、"trail1V.jpg"等の複数レコードで共用される画像ファイル、当該可変データのファイル、レイアウトプログラム、属性ファイル等である。

ここで、格納制御部１５２は、クライアントコンピュータ３００から受信したジョブファイル中の属性ファイルの書き換えを行う（Ｓ２２）。例えば受信した属性ファイルが図４に例示したようなものであったとすると、ステップＳ２２では、図９に示すように、各リソースの属性を示す<RESOUCE>要素の中に、"Secure"属性を追加する。すなわち、守秘対象のリソース（プリントサーバ１００内に保存されないリソース）の<RESOUCE>要素には"Secure"属性「１」を追加し、守秘対象でないリソース（プリントサーバ１００内に保存されるリソース）の<RESOUCE>要素には"Secure"属性「０」を追加する。例えば、図９の属性ファイル６１０では、要素６１２の"Secure"属性値は「０」であり、これは可変データ"submission01.dbf"がプリントサーバ１００内に保存されていることを示す。一方、要素６１４の"Secure"属性値は「１」であり、これは画像ファイル"secure1.jpg"がプリントサーバ１００内に保存されていないことを示す。通知部１５４は、上述のように更新された属性ファイルを、通信部１１０を介してクライアントコンピュータ３００に返す（Ｓ２３）。

なお、クライアントコンピュータ３００に送られる属性ファイルには、元のジョブファイルを特定する識別情報が対応付けられている。このため、クライアントコンピュータ３００はプリントサーバ１００から受け取った属性ファイルがどのジョブファイルに対応するものかを判定できる。

更新後の属性ファイルを受け取ったクライアントコンピュータ３００のリソース管理部３１０は、その属性ファイルを再印刷ジョブの候補として記憶し、それら候補のリストを画面表示してユーザから再印刷の指示を受け付ける。ユーザが再印刷するジョブを選択すると、リソース管理部３１０は、そのジョブの属性ファイルの中で"Secure"属性値が「１」であるリソースを特定する。プリンタドライバ３２０は、特定されたリソース群を１つにまとめて再印刷のジョブファイルを生成し、プリントサーバ１００に送信する。この再印刷のジョブファイルには、元のジョブファイルの識別情報が対応づけられている。

プリントサーバ１００は、受信した再印刷のジョブファイルを解凍部１２０で解凍すると共に、そのジョブファイルに対応づけられた識別情報から、リソース管理部１５０内にある当該ジョブの保存データを特定する。リソース管理部１５０の再構成部１５６は、解凍結果のリソース群と、保存データとを組み合わせることで、元のジョブファイルに含まれていたリソース群を再生する。ＰＤＬ処理部１３０は、これらリソース群を処理することで、可変データ印刷を実行する。

以上の例では、ジョブの中で１回しか使われないリソースを、個別性の高いものと判定したが、これは一例に過ぎない。変形例として、１レコード中でしか使われないリソースを個別性の高いものと判定してもよい。この変形例のためには、監視部１３４は、図１０に例示するような管理情報リストを用いればよい。このリストは、図７に例示した上述の例のリストに対し、各リソースが検出されたレコードの識別情報（レコードＩＤ）のフィールドを追加したものである。この変形例における監視部１３４の処理手順を図１１に示す。図１１において、図６に示したステップと同内容の処理を行うステップには同一符号を付して説明を省略する。

この手順では、ステップＳ１１で管理情報リストに現在のリソースがないと判定された場合、現在のリソースのリソースＩＤ、そのリソースを用いている現在のレコード（すなわちこの処理が呼ばれた時点で解釈されているレコードのＩＤ）のレコードＩＤをそのリストに記録する（Ｓ１２）。ここで、機密ラベルは初期値「１」に設定する。そして、ステップＳ１１で管理情報リストに現在のリソースの情報がある場合、その情報の中のレコードＩＤと、現在解釈中のレコードのレコードＩＤとが同じか否かを判定する（Ｓ１４）。ステップＳ１４の判定結果が否定（Ｎｏ）である場合、現在のリソースは、同じリソースを最初に使ったレコードとは異なるレコードで使われているということである。この場合、管理情報リスト上の当該リソースの機密フラグの値を「０」にする（Ｓ１３）。「同じ」と判定された場合は、現在のリソースは、同じリソースを最初に使ったレコードの中で使われているということなので、ステップＳ１３をスキップして処理を終了する。

なお、監視部１３４が生成した管理情報リストを用いる格納制御部１５２の処理手順は、上述の例（図８参照）と同様でよい。

以上では、１レコード中でしか使われないリソースを個別性の高いものと判定する変形例を示したが、１つの主体についてしか使われないリソースを個別性の高いものと判定してもよい。この場合は、管理情報リストの中に、レコードＩＤの代わりに、主体のＩＤを記録する。主体ＩＤは、レコードの主体の識別情報である。主体ＩＤの一例としては、例えば、顧客名や顧客番号などがある。同一の主体について複数のレコードがある場合も、それらレコード中の主体ＩＤは同じである。監視部１３４の処理は、主体ＩＤを用いる点以外は、上述の変形例と同様でよい。

次に、第２の変形例を説明する。上述の例では、守秘対象と判定されたリソースを単にプリントサーバ１００上の保存データから削除したのに対し、この第２変形例ではそのようなリソースをダミーデータに置き換える。

例えば印刷レイアウトの確認や調整のために、プリントサーバ１００側で保存データを用いてサンプル印刷をしたい場合がある。ところが、守秘対象のリソースを保存データから単に削除した場合、サンプル印刷の際に、必要なリソースが見つからないためエラーとなって印刷ができなくなる場合がある。また、リソースがなくても印刷が実行できる場合は、印刷結果では削除されたリソースの部分が空白となる。この場合、その部分が元から空白なのか、それとも守秘対象のリソースに対応しているから空白なのかがわからない。このようなことから、この第２の変形例では、守秘対象のリソースをダミーデータに置き換えるのである。

この第２の変形例における格納制御部１５２及び通知部１５４の処理手順を、図１２に示す。図１２において、図８に示したステップと同様の処理を行うステップには同一符号を付して説明を省略する。この手順では、可変データ中の守秘対象のリソースを指し示す記述を、所定のダミーデータを指し示す記述に書き換える（Ｓ２４）。ステップＳ２１（守秘対象リソースの削除）とステップＳ２４との実行順序は図示例に限らない。

例えば、図１３に例示するように、レイアウトプログラム５１０の中の行５１２及び５１４で、フィールド"C#NAME"（顧客名）と"C#IMG2"（画像）とがコマンド"SEC2"により監視対象に指定されたとする。この場合、フィールド"CC#NAME"と"CC#IMG2"のなかで、１主体でしか使われないリソースが守秘対象に判定され、ダミーデータに置き換えられる。

書き換えられた可変データ４１０の例を図１４に示す。この例では、各レコード中のフィールド"C#NAME"の値のうち守秘対象と判定されたものは、文字列「ダミー」に置き換えられる。また、フィールド"C#IMG2"の値のうち守秘対象と判定されたものは、文字列"dummy.jpg"に置き換えられている。この例では、他のリソースを指し示しているのではない単なる文字列（顧客名など）は「ダミー」という文字列に置き換えられ、画像ファイルを指し示しているファイル目の文字列はダミー画像のファイルの識別情報"dummy.jpg"に置き換えられる。なお、ダミー画像としてはどのような画像を用いてもよく、そのダミー画像のファイルはあらかじめリソース管理部１５０に登録しておけばよい。ここでは画像ファイルをダミー画像に置換する場合を例示したが、表やグラフなどの他の種類のリソースファイルについても同様にダミーファイルに置き換えることもできる。

再び図１２の説明に戻ると、格納制御部１５２は、当該ジョブの属性ファイルを更新する（Ｓ２２ａ）。この更新は、図８の手順のステップＳ２２と同様であるが、"Secure"属性値として「２」、「３」という図８の手順では用いていなかった値が増える。"Secure"属性値「２」はリソースの内容に変更が加えられたことを示す値であり、「３」はプリントサーバ１００が新たに追加したリソースであることを示す値である。ステップＳ２２ａにて更新された後の属性ファイル６２０の内容の例を図１５に示す。この例では、可変データがステップＳ２４で書き換えられているので、可変データの属性群を表す要素６２２には"Secure"属性値「２」を表す記述が追加されている。また、ダミー画像"dummy.jpg" を新たに用いることとなったので、そのダミー画像を示す要素６２４が新たに属性ファイル６２０に追加されている。ダミー画像はプリントサーバ１００側で追加されたリソースなので、"Secure"属性値は「３」となっている。このようにして作成されたファイルは、通知部１５４によりクライアントコンピュータ３００に送られる（Ｓ２３）。

このような処理の後、クライアントコンピュータ３００から当該ジョブに対する再印刷の指示が来るまでの間、プリントサーバ１００は、保存データを用いてサンプル印刷を行うことができる。守秘対象の文字列や画像等のリソースは、可変データ（図１４参照）中でダミーのリソースに置き換えられているので、サンプル印刷ではそれらダミーのリソースが印刷されることになる。ダミーのリソースは、文字列や画像等の内容は元の守秘対象のリソースとは異なるが、元のリソースが配置されるべき位置に配置されるので、ユーザはサンプル印刷の結果からレイアウトを把握することができる。

さて、プリントサーバ１００から更新された属性ファイル６２０を受け取ったクライアントコンピュータ３００は、当該属性ファイル６２０に対応するジョブの再実行がユーザから指示された場合、属性ファイル６２０中の"Secure"属性値が「１」又は「２」のリソース群を１つのファイルへと圧縮することで再印刷のジョブファイルを生成する。可変データの"Secure"属性値は「２」なので、再印刷のジョブファイルには可変データも含まれる。このときジョブファイルに組み込まれる可変データは、プリントサーバ１００内に保存されているダミー置換が行われた可変データではなく、そのような置換が行われる前の元の可変データである。プリントサーバ１００は、再印刷のジョブファイルを受け取って、これを対応する保存データと組み合わせることで、元のジョブファイルを復元することができる。この復元の際、ダミー置換が行われた可変データは破棄され、再印刷ジョブ中の可変データが採用される。

なお、第２変形例において用いるダミー画像の画像サイズは、一般に、元の守秘対象リソースの画像サイズと同じではない。したがって、サンプル印刷でダミー画像を印刷した場合、そのダミー画像の起点位置は元の守秘対象リソースの画像と同じ位置であるが、サイズは異なっていることとなる。印刷されるダミー画像を起点位置のみならずサイズまで元の画像に合わせれば、レイアウトがより把握しやすくなる。

このためには、例えば、監視部１３４が、各画像リソースが利用される際にその画像サイズを求め、管理情報リストに記録しておけばよい。画像リソースの画像サイズは、解釈部１３２がその画像リソースを用いる際に求めることができる。そして、図１２の手順のステップＳ２４で可変データを保存用に書き換える際に、例えば格納制御部１５２が、守秘対象の画像リソースと所定のダミー画像とのサイズ比較により、ダミー画像を守秘対象画像と同じサイズにするための縮尺を求め、これを可変データに追加すればよい。

縮尺情報が追加された可変データの例を図１６に示す。この例の可変データ４２２は、"C#IMG2"フィールドのリソースについての縮尺を示すために"C#SCL"フィールド４２２が追加されている。図示例は、ダミー画像"dummy.jpg"を１．２倍に拡大すれば、元の守秘画像と同じサイズになることを示している。以上は縦横の縮尺が同一の例であったが、縦横の縮尺（倍率）を別々に求めて記録できるようにしてもよい。

縮尺情報を利用したダミー画像の拡大・縮小は、例えば、レイアウトプログラムの書き換えにより実現してもよい。図１７に、書き換えられたレイアウトプログラム５２０の一例を示す。この例は、図１６の可変データに対応したものであり、"C#IMG2"に示された画像リソース（即ちダミー画像）を取得して描画する際に、"C#SCL"フィールド中の値を読み出す（記述５２２参照）。コマンド"ICALL"は、その値を縮尺値と解釈し、そのダミー画像を拡大また縮小して描画する。

以上に説明した実施形態又は変形例のシステムによれば、ジョブの実行終了後に守秘対象のリソースがプリントサーバ１００に残らないので、機密保持の観点から好ましい。また、守秘対象以外のリソースはプリントサーバ１００内に保存されているので、再印刷の際にすべてのリソースを再度取得する必要が無く、処理速度又はネットワーク負荷などの点でも好ましい。また、プリントサーバ１００は、保存したリソース又は削除したリソースを明示した属性ファイルをクライアントコンピュータ３００側に送る。これにより、クライアントコンピュータ３００は、再印刷を指示する際、その属性ファイルを参照してプリントサーバ１００にないリソースのみを選んで送るので、再印刷時のネットワークやプリントサーバ１００の通信負荷を低減することができる。

上述の例では、ジョブで用いられるリソース群が、印刷要求元のクライアントコンピュータ３００からプリントサーバ１００に送られる例を示したが、これは一例に過ぎない。この代わりに、例えばネットワーク上にリソースのデータベースを設け、プリントサーバ１００がそのデータベースから各リソースの実体データをダウンロードして利用してもよい。この場合も、守秘対象のリソースをプリントサーバ１００に残さないことで、情報セキュリティの向上が図れる。なお、この場合、再印刷に際しては、プリントサーバ１００が、削除した守秘対象のレコードをデータベースからダウンロードすればよい。

以上に例示したプリントサーバ１００又はクライアントコンピュータ３００は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図１８に示すように、ＣＰＵ１０００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）１００２およびリードオンリメモリ（ＲＯＭ）１００４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）１００６を制御するＨＤＤコントローラ１００８、各種Ｉ／Ｏ（入出力）インタフェース１０１０、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１０１２等が、たとえばバス１０１４を介して接続された回路構成を有する。また、そのバス１０１４に対し、例えばＩ／Ｏインタフェース１０１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ１０１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダ・ライタ１０１８、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ１００２に読み出されＣＰＵ１０００等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

実施形態の画像処理システムの一例の構成を示す図である。 可変データのデータ内容の一例を示す図である。 レイアウトプログラムの一例を示す図である。 属性ファイルのデータ内容の一例を示す図である。 解釈部の処理手順の一例を示すフローチャートである。 監視部の処理手順の一例を示すフローチャートである。 監視部が用いる管理情報リストの一例を示す図である。 プリントサーバのリソース管理部の処理手順の一例を示すフローチャートである。 プリントサーバからクライアントコンピュータに返される属性ファイルのデータ内容の一例を示す図である。 変形例で用いられる管理情報リストの一例を示す図である。 変形例における監視部の処理手順の一例を示すフローチャートである。 第２の変形例におけるプリントサーバのリソース管理部の処理手順の一例を示すフローチャートである。 第２の変形例におけるレイアウトプログラムの一例を示す図である。 第２の変形例における可変データのデータ内容の一例を示す図である。 第２の変形例における属性ファイルのデータ内容の一例を示す図である。 ダミー画像の縮尺情報を含んだ可変データのデータ内容の一例を示す図である。 ダミー画像を拡大・縮小して印刷するためのレイアウトプログラムの一例を示す図である。 コンピュータのハードウエア構成の一例を示す図である。

符号の説明

１００ プリントサーバ、１１０ 通信部、１２０ 解凍部、１３０ ＰＤＬ処理部、１３２ 解釈部、１３４ 監視部、１３６ 描画部、１４０ 出力部、１５０ リソース管理部、１５２ 格納制御部、１５４ 通知部、１５６ 再構成部、２００ 印刷装置、３００ クライアントコンピュータ、３１０ リソース管理部、３２０ プリンタドライバ、３２２ 圧縮部、３３０ 通信部。

Claims (5)

1. １以上の主体の各々について１以上のレコードを含む可変データと、前記レコード群に適用する描画プログラムと、前記レコード群についての描画の際に用いられる１以上のリソースデータと、を含む印刷ジョブデータを外部装置から受信する受信手段と、
   前記描画プログラムを前記可変データ中の各レコードについて実行する際に、前記各レコードの中で指定されているリソースデータを用いることで前記各レコードに対応する出力画像を生成する画像生成手段と、
   前記画像生成手段による前記各レコードに対応する出力画像の生成において、前記リソースデータごとに当該リソースデータを描画の際に用いる前記主体の数を計数し、その計数の結果に基づき個別性の高いリソースデータを特定する特定手段と、
   前記印刷ジョブデータを保存する制御を行う保存制御手段であって、前記印刷ジョブデータのうち、前記特定手段が特定した個別性の高いリソースデータを除外して保存する制御を行う保存制御手段と、
   を備える画像処理装置。
2. 前記外部装置に対して、前記保存制御手段により除外されたリソースデータを特定する情報を通知する通知手段と、
   前記外部装置から、前記印刷ジョブデータに対応する再印刷データを受信した場合、前記再印刷データを前記記憶装置に格納されたリソースデータと組み合わせて前記印刷ジョブデータを再構成する再構成手段と、
   を備える請求項１記載の画像処理装置。
3. 前記保存制御手段は、前記可変データのレコードの記述のうち、前記特定手段により特定された個別性の高いリソースデータを指定する記述を、ダミーデータを指定する記述に置き換える置き換え手段、を備えることを特徴とする請求項１記載の画像処理装置。
4. 前記各リソースデータの前記出力画像内での画像サイズを求めるサイズ判定手段、を更に備え、
   前記置き換え手段は、前記可変データのレコードの記述において、前記個別性の高いリソースデータを指定する記述を、ダミーデータを指定する記述に置き換えた場合に、前記ダミーデータを前記削除したリソースデータと同サイズで描画させる指定を前記レコードに追加する、
   ことを特徴とする請求項３記載の画像処理装置。
5. コンピュータを、
   １以上の主体の各々について１以上のレコードを含む可変データと、前記レコード群に適用する描画プログラムと、前記レコード群についての描画の際に用いられる１以上のリソースデータと、を含む印刷ジョブデータを外部装置から受信する受信手段、
   前記描画プログラムを前記可変データ中の各レコードについて実行する際に、前記各レコードの中で指定されているリソースデータを用いることで前記各レコードに対応する出力画像を生成する画像生成手段、
   前記画像生成手段による前記各レコードに対応する出力画像の生成において、前記リソースデータごとに当該リソースデータを描画の際に用いる前記主体の数を計数し、その計数の結果に基づき個別性の高いリソースデータを特定する特定手段、
   前記印刷ジョブデータを保存する制御を行う保存制御手段であって、前記印刷ジョブデータのうち、前記特定手段が特定した個別性の高いリソースデータを除外して保存する制御を行う保存制御手段、
   として機能させるためのプログラム。

Images