JP4785580B2 - 画像形成装置及びその制御方法、プログラム - Google Patents

Description

本発明は、印刷データを受信して、印刷を行う画像形成装置及びその制御方法、プログラムに関するものである。

ホストコンピュータ上のアプリケーションから画像やテキストを印刷装置にて印刷する際には、図１に示すような構成が一般的である。

即ち、ホストコンピュータ３０００上のアプリケーション１０１は、グラフィクスエンジン１０３に対して描画データを渡し、その描画データはグラフィクスエンジン１０３にて加工されてからプリンタドライバ１０４に渡される。次に、プリンタドライバ１０４にて、プリンタ１５００に対する印刷データ（例えば、ＰＤＬ：Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）を生成し、その印刷データはスプーラ１０５に格納された後、プリンタ１５００に送られるという構成である。

特に、グラフィクスエンジン１０３は、アプリケーション１０１で作成された描画データの解像度を変換したり、プリンタドライバ１０４の処理能力に合わせてシミュレート処理等の描画データの加工を行う。これによって、アプリケーション１０１とプリンタドライバ１０４が互いに非依存な関係で動作することができる。このグラフィクスエンジン１０３は、通常、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１０２の一部として提供される。

一方、このグラフィクスエンジンは必ずしも一つであるとは限らず、二つ以上のグラフィクスエンジンが共存する構成が存在する。

例えば、２００５年米国シアトルにてＷｉｎＨＥＣ ２００５というハードウェアエンジニアリングカンファレンスがＭｉｃｒｏｓｏｆｔ社によって開催された。この場にて、Ｍｉｃｒｏｓｏｆｔ社の新しいＯＳ（Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａ）が図２に示すような２つのグラフィクスエンジン（ＧＤＩ２０２、ＷＰＦ２１２）が共存する構成になることが紹介されている（非特許文献１）。尚、ＷＰＦとは、Ｗｉｎｄｏｗｓ（登録商標） Ｐｒｅｓｅｎｔａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎの略称である。

従来のＭｉｃｒｏｓｏｆｔ社の印刷処理システムは、Ｗｉｎ３２ ＡＰＩというＡＰＩを使用するアプリケーションからＧＤＩと呼ばれるグラフィクスエンジンを活用して、ＧＤＩから呼び出されるプリンタドライバにて描画データから印刷データを作成する。この印刷処理フローを、ＧＤＩプリントパスと称している。

ここで、ＡＰＩは、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅの略称である。また、ＧＤＩは、Ｇｒａｐｈｉｃ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅの略称である。また、以下では、Ｗｉｎ３２ ＡＰＩを使用するアプリケーションを、Ｗｉｎ３２アプリケーション２０１と略称する。また、ＧＤＩから呼び出されるプリンタドライバを、ＧＤＩプリンタドライバ２０３と略称する。

一方、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでは、従来のＧＤＩプリントパスに加え、ＸＰＳプリントパスという新しい印刷処理フローが追加される。ＸＰＳプリントパスとは、ＷｉｎＦｘ ＡＰＩを使用するアプリケーションからＷＰＦと呼ばれるグラフィクスエンジンを活用して、ＸＰＳ形式の描画データをプリンタドライバにて印刷データに変換する印刷処理フローである。

ここで、ＸＰＳは、ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎの略称である。また、以下では、ＷｉｎＦｘ ＡＰＩを使用するアプリケーションを、ＷｉｎＦｘアプリケーション２１１と略称する。また、ＸＰＳ形式の描画データをプリンタドライバを、ＸＰＳプリンタドライバ２１３と略称する。

このように、Ｗｉｎｄｏｗｓ（登録商標） ＶＩＳＴＡにおいて、アプリケーションは、Ｗｉｎ３２アプリケーション２０１とＷｉｎＦｘアプリケーション２１１の２種類に区別される。また、グラフィクスエンジンはＧＤＩ２０２とＷＰＦ２１２の２つがＯＳ１０２上に存在する。

ここで、Ｗｉｎ３２アプリケーション２０１はＧＤＩ２０２に対して描画データを渡し、ＷｉｎＦＸアプリケーション２１１はＷＰＦ２１２に対して描画データを渡す。また、プリンタドライバは、ＧＤＩプリンタドライバ２０３とＸＰＳプリンタドライバ２１３の２種類に区別される。ＧＤＩプリンタドライバ２０３は、ＧＤＩ２０２から描画データを受け取りプリンタ１５００に対する印刷データに変更する。また、ＸＰＳプリンタドライバ２１３は、ＷＰＦ２１２から描画データを受け取りプリンタ１５００に対する印刷データに変更する。そして、プリンタドライバで作成された印刷データはスプーラ１０５を経てプリンタ１５００に送信される。

更に、このＧＤＩ２０２とＷＰＦ２１２といったグラフィクスエンジンは、互いに連携することができる。そして、この連携により、Ｗｉｎ３２アプリケーション２０１からＸＰＳプリンタドライバ２１３に描画データを渡すことができる。一方で、ＷｉｎＦｘアプリケーション２１１からＧＤＩプリンタドライバ２０３に描画データを渡すことができる。

図３にて、Ｗｉｎｄｏｗｓ（登録商標） ＶＩＳＴＡにおける２つのグラフィクスエンジンの連携の仕組みを説明する。

印刷処理フロー（１）は、従来のＧＤＩプリントパスを示している。Ｗｉｎ３２アプリケーション２０１から渡される描画データは、ＧＤＩ２０２にてＥＭＦ（Ｅｎｈａｎｃｅｄ Ｍｅｔａｆｉｌｅ）形式でＥＭＦスプールファイル３０１として格納される。その後、ＧＤＩプリンタドライバ２０３にて印刷データへの変換が行われる。

印刷処理フロー（４）は、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａで追加されるＸＰＳプリントパスを示している。ＷｉｎＦｘアプリケーション２１１から渡される描画データは、ＷＰＦ２１２にてＸＰＳスプールファイル３１１として格納される。その後、ＸＰＳプリンタドライバ２１３にて印刷データへの変換が行われる。

印刷処理フロー（３）は、ＷｉｎＦｘアプリケーション２１１からＧＤＩプリンタドライバ２０３で印刷する場合の印刷処理フローを示している。ＷｉｎＦｘアプリケーション２１１から渡される描画データは、ＷＰＦ２１２を経由してＸＰＳ→ＧＤＩ変換モジュール３１２にて、ＥＭＦ形式の描画データに変換され、ＥＭＦスプールファイル３０１として格納される。その後、ＧＤＩプリンタドライバ２０３にて印刷データへの変換が行われる。

印刷処理フロー（２）は、Ｗｉｎ３２アプリケーション２０１からＸＰＳプリンタドライバ２１３で印刷する場合の処理フローを示している。Ｗｉｎ３２アプリケーション２０１から渡される描画データは、ＧＤＩ２０２を経由してＧＤＩ→ＸＰＳ変換モジュール３０２にてＸＰＳ形式の描画データに変換され、ＸＰＳスプールファイル３１１として格納される。その後、ＸＰＳプリンタドライバ２１３にて印刷データへの変換が行われる。

このように、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａにおいては、４つの印刷処理フローが用意されている。また、プリンタに対するプリンタドライバは、ＧＤＩプリンタドライバ２０３あるいはＸＰＳプリンタドライバ２１３の一方を用意することで、Ｗｉｎ３２アプリケーション２０１及びＷｉｎＦｘアプリケーション２１１の両方からの印刷処理に対応できる。

一方、ＸＰＳ形式そのものに注目すると、その特徴の一つとして、セキュリティ機能を持たせられる点があげられる。一例として、ＸＰＳ形式の文書データに電子署名を付加し、文書データの改ざんを検知することが可能である。この電子署名付加機能を利用すると、プリンタと連携したセキュリティソリューションが考えられる。

例えば、プリンタに電子署名検証機能を持たせ、プリンタが受信したＸＰＳ文書に付加された電子署名を検証し、文書が改ざんされていないと判定された場合のみ印刷を実行するような印刷システムを構築することが可能となる。

尚、プリンタが実際に印刷を行うかどうかを受信した印刷データを解析して判定する技術は、例えば、特許文献１で提案されている。この特許文献１においては、その判定方法として、印刷データにより指定されたジョブ属性が処理可能かどうかという基準を採用している。
http://www.microsoft.com/whdc/device/print/default.mspx (Advances in Windows （登録商標）Printing : TWPR05001_WinHEC05.ppt) 特開２００３−２２６０６１号公報

しかしながら、ＸＰＳ形式とＥＭＦ形式は異なるため、図３の印刷処理フロー（２）及び印刷処理フロー（３）のように、描画データの変換が発生してしまう恐れのある印刷処理フローに対して印刷品質や機能面、印刷速度への課題が存在する。

印刷品質面では、例えば、印刷処理フロー（２）において、ＥＭＦ形式でサポートされているＲＯＰ演算（ラスターオペレーション処理演算）のような論理演算を含む描画データは、ＸＰＳ形式ではサポートされていない。そのため、米国マイクロソフト社が決定する仕様によっては、そのような論理演算を含む描画データに対しては、ＧＤＩ→ＸＰＳ変換モジュール３０２で変換する際に論理演算情報が欠落してしまう恐れがある。ＸＰＳプリンタドライバ２１３には論理演算情報が削除された描画データが渡される場合、Ｗｉｎ３２アプリケーション２０１において意図された出力結果をＸＰＳプリンタドライバ２１３で作成することができなくなる可能性がある。

また、逆に、印刷処理フロー（３）において、ＸＰＳ形式においてサポートされている高度なグラフィクス描画データは、ＥＭＦ形式においてサポートされていない。そのため、そのような描画データに対してはＸＰＳ→ＧＤＩ変換モジュール３１２で変換する際に、Ｆｌａｔｔｅｒｉｎｇと呼ばれる局所的なＢｉｔｍａｐ化が行われる。その場合、グラフィクスデータがＢｉｔｍａｐデータに変換されてしまうことにより、ＧＤＩプリンタドライバ２０３では元のオブジェクト属性が判断できなくなってしまい、最適な出力結果を作成することはできなくなる恐れがある。

そのため、印刷処理フロー（２）や（３）が使用された場合、プリンタから出力された印刷結果はユーザの意図したものから品質的に劣ってしまう恐れがある。

セキュリティ面においては、例えば、印刷処理フロー（３）において、ＸＰＳ形式においてサポートされる電子署名情報は、ＥＭＦ形式においてはサポートされていない。そのため、ＸＰＳ形式の文書を印刷処理フロー（３）を経由することにより、文書に付加されていた電子署名情報は失われ、プリンタは従来の系で印刷せざるを得ない。この場合、悪意あるユーザが意図的にセキュリティ制限を回避して印刷を行うことを阻止できなくなる恐れがある。

本発明は上記の課題を解決するためになされたものであり、不正な印刷または印刷品質の低下を防止することができる画像形成装置及びその制御方法、プログラムを提供することを第１の目的とする。

また、本発明は、劣化した印刷品質での出力を極力減らすことができる画像形成装置及びその制御方法、プログラムを提供することを第２の目的とする。

上記の目的を達成するための本発明による画像形成装置は以下の構成を備える。即ち、
第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置であって、
前記情報処理装置より印刷データを受信する受信手段と、
前記受信手段で受信した印刷データが、前記第１アプリケーションと第１プリンタドライバの組み合わせによる処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第２プリンタドライバの組み合わせによる処理経路を介して生成された印刷データでないと解析された場合、前記受信手段によって受信された印刷データの印刷を禁止するように制御する制御手段と
を備える。

上記の目的を達成するための本発明による画像形成装置は以下の構成を備える。即ち、
第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置であって、
前記情報処理装置より印刷データを受信する受信手段と、
前記受信手段で受信した印刷データが、前記第１アプリケーションと第２プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第１プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データであると解析された場合、前記描画変換を伴わない種類のプリンタドライバを特定する特定手段と、
前記特定手段によって特定された種類のプリンタドライバを含むデバイス情報を前記情報処理装置に対して通知する通知手段
を備える。

本発明によれば、不正な印刷または印刷品質の低下を防止することができる画像形成装置及びその制御方法、プログラムを提供できる。

また、本発明によれば、劣化した印刷品質での出力を極力減らすことができる画像形成装置及びその制御方法、プログラムを提供できる。

以下、本発明の実施の形態について図面を用いて詳細に説明する。
図３は、Ｗｉｎｄｏｗｓ（登録商標） ＶＩＳＴＡにおける２つのグラフィクスエンジンの連携の仕組みを説明する。

印刷処理フロー（１）は、従来のＧＤＩプリントパスを示している。Ｗｉｎ３２アプリケーション２０１から渡される描画データは、ＧＤＩ２０２にてＥＭＦ形式でＥＭＦスプールファイル３０１として格納される。その後、ＧＤＩプリンタドライバ２０３にて印刷データへの変換が行われる。

印刷処理フロー（４）は、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａで追加されるＸＰＳプリントパスを示している。ＷｉｎＦｘアプリケーション２１１から渡される描画データは、ＷＰＦ２１２にてＸＰＳスプールファイル３１１として格納される。その後、ＸＰＳプリンタドライバ２１３にて印刷データへの変換が行われる。

印刷処理フロー（３）は、ＷｉｎＦｘアプリケーション２１１からＧＤＩプリンタドライバ２０３で印刷する場合の印刷処理フローを示している。ＷｉｎＦｘアプリケーション２１１から渡される描画データは、ＷＰＦ２１２を経由してＸＰＳ→ＧＤＩ変換モジュール３１２にて、ＥＭＦ形式の描画データに変換され、ＥＭＦスプールファイル３０１として格納される。その後、ＧＤＩプリンタドライバ２０３にて印刷データへの変換が行われる。

印刷処理フロー（２）は、Ｗｉｎ３２アプリケーション２０１からＸＰＳプリンタドライバ２１３で印刷する場合の処理フローを示している。Ｗｉｎ３２アプリケーション２０１から渡される描画データは、ＧＤＩ２０２を経由してＧＤＩ→ＸＰＳ変換モジュール３０２にてＸＰＳ形式の描画データに変換され、ＸＰＳスプールファイル３１１として格納される。その後、ＸＰＳプリンタドライバ２１３にて印刷データへの変換が行われる。

このように、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａにおいては、４つの印刷処理フローが用意されている。また、プリンタに対するプリンタドライバは、ＧＤＩプリンタドライバ２０３あるいはＸＰＳプリンタドライバ２１３の一方を用意することで、Ｗｉｎ３２アプリケーション２０１及びＷｉｎＦｘアプリケーション２１１の両方からの印刷処理に対応できる。

図２、図３では、情報処理装置は、第１アプリケーションであるＷｉｎ３２アプリケーション２０１と第１プリンタドライバであるＧＤＩプリンタドライバ２０３を備える。また、情報処理装置は、第２アプリケーションであるＷｉｎＦＸアプリケーション２１１と第２プリンタドライバであるＸＰＳプリンタドライバ２１３を備える。

また、グラフィクスエンジンは、第１描画変換部であるＧＤＩ２０２と第２描画変換部であるＷＰＦ２１２の２つがＯＳ１０２上に存在する。Ｗｉｎ３２アプリケーションは、ＧＤＩ２０２に対して第１描画データであるＧＤＩ関数を渡し、ＷｉｎＦｘアプリケーション２１１はＷＰＦ２１２に対して第２描画データであるＷＰＦ ＡＰＩ形式データを渡す。

ＧＤＩプリンタドライバ２０３はＧＤＩ２０２から描画データを受け取り印刷装置１５００に対する印刷データに変換する。ＸＰＳプリンタドライバ２１３はＷＰＦ２１２から描画データを受け取り印刷装置１５００に対する印刷データに変換する。プリンタドライバで作成された印刷データは、スプーラ１０５を経て印刷装置１５００に送信される。

尚、本実施形態では、変換モジュールを用いた描画変換を伴う印刷処理経路（２）及び（３）をクロスパスと総称する。一方、変換モジュールを用いた描画変換を伴わない印刷処理経路（１）及び（４）をストレートパスと総称する。

図４は本発明の実施形態のコンピュータを含むプリンタ制御システムの構成を説明するブロック図である。

尚、特に断らない限り、本発明の機能が実行されるのであれば、単体の機能であっても、複数の機器からなるシステムであっても本発明を適用できることは言うまでもない。更には、ＬＡＮ、ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても、本発明を適用できることは言うまでもない。

図４において、３０００はホストコンピュータであり、ＣＰＵ１を備える。ＣＰＵ１は、ＲＯＭ３のプログラム用ＲＯＭ３ｂあるいは外部メモリ１１に記憶された文書処理プログラム（アプリケーションプログラム）等のプログラムに基づいて、図形、イメージ、文字、表（表計算等を含む）等の構成要素が混在した文書処理を実行する。更に、ＣＰＵ１は、ホストコンピュータ本体２０００内のシステムバス４に接続される各デバイスを総括的に制御する。

また、このＲＯＭ３のプログラム用ＲＯＭ３ｂあるいは外部メモリ１１には、ＣＰＵ１の制御プログラムであるオペレーティングシステムプログラム（以下、ＯＳ）等のプログラムも記憶している。また、ＲＯＭ３のフォント用ＲＯＭ３ａあるいは外部メモリ１１には、上記文書処理の際に使用するフォントデータ等のデータを記憶している。また、ＲＯＭ３のデータ用ＲＯＭ３ｃあるいは外部メモリ１１には、上記文書処理等の各種処理を行う際に使用する各種データを記憶する。

２はＲＡＭであり、ＣＰＵ１の主メモリ、ワークエリア等として機能する。５はキーボードコントローラ（ＫＢＣ）であり、キーボード（ＫＢ）９やポインティングデバイス（不図示）からのキー入力を制御する。６はＣＲＴコントローラ（ＣＲＴＣ）であり、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。尚、ＣＲＴコントローラ６及びＣＲＴディスプレイ１０の代りに、ＬＣＤコントローラ及びＬＣＤを用いても良い。

７はディスクコントローラ（ＤＫＣ）であり、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル等の外部メモリ１１とのアクセスを制御する。さらに、ＤＫＣ７は、印刷制御コマンド生成プログラム（以下、プリンタドライバ）等の各種データを記憶する、ハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）等の外部メモリ１１とのアクセスも制御する。

８はプリンタコントローラ（ＰＲＴＣ）であり、所定の双方向性インタフェース２１を介してプリンタ１５００に接続されて、プリンタ１５００との通信制御処理を実行する。双方向性インタフェースの例には、ＵＳＢインタフェース、ＩＥＥＥ１３９４インタフェース、無線ＬＡＮインタフェース等がある。

尚、ＣＰＵ１は、例えば、ＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行してＧＵＩを提供することで、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１は、ＣＲＴ１０上のマウスカーソル（不図示）等で指示されたコマンドに基づいて、登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザは、印刷を実行する際、印刷の設定に関するウインドウを開き、プリンタの設定や、印刷モードの選択を含むプリンタドライバに対する印刷方法の設定を行える。

プリンタ１５００において、１２はプリンタＣＰＵであり、プリンタＣＰＵ１２は、プリンタ制御部１０００内のシステムバス１５に接続される各デバイスを総括的に制御する。また、プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭ１３ｂあるいは外部メモリ１４に記憶された制御プログラム等のプログラムに基づいて、システムバス１５に接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。

また、このＲＯＭ１３のプログラム用ＲＯＭ１３ｂには、プリンタＣＰＵ１２の制御プログラム等のプログラムを記憶している。また、ＲＯＭ１３のフォント用ＲＯＭ１３ａには、上記出力情報を生成する際に使用するフォントデータ等のデータを記憶している。また、ハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４がないプリンタの場合には、ＲＯＭ１３のデータ用ＲＯＭ１３ｃには、ホストコンピュータ３０００上で利用される情報等を記憶している。

プリンタＣＰＵ１２は、入力部１８を介してホストコンピュータ３０００との通信処理が可能となっており、プリンタ１５００内のステータス情報等の各種情報をホストコンピュータ３０００に通知可能に構成されている。１９はＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭである。このＲＡＭ１９は、増設ポート（不図示）に接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。

尚、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスが制御される。外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等のデータを記憶する。また、１５０１は操作部であり、プリンタ１５００に対する各種操作を実現するための操作パネルやスイッチ、ＬＥＤ表示器等が構成されている。

また、外部メモリ１４は１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、ＮＶＲＡＭ（不図示）を有し、操作部１５０１からのプリンタモード設定情報を記憶するようにしてもよい。

また、プリンタ１５００には、１個以上のＰＤＬ装置（ＰＤＬボード）を接続し、ＣＰＵ１２からＰＤＬ装置を制御可能とする。ＰＤＬ装置は、ホストコンピュータ３０００から受信した印刷データ（ＰＤＬ）を解釈し、印刷部１７が印刷可能なビットマップデータに変換する機能を有する画像形成部である。このＰＤＬ装置は、標準として１個以上接続されているが、後から追加することも可能である。また、プラグアンドプレイで使用されるＩＥＥＥ１２８４規定のデバイス情報は、このＰＤＬ装置が保持している。

尚、本実施形態の情報処理装置は、プリンタドライバを介して、プリンタが解釈可能な印刷データ（印刷ジョブ）を生成できる。

また、通常、プリンタ１５００は、標準ＰＤＬ装置としてＰＤＬ１を備えており、オプションＰＤＬ装置としてＰＤＬ２等の他の種類のＰＤＬを追加拡張可能であるものとする。

この拡張は、専用のＰＤＬ装置を搭載する拡張ボードを物理的にプリンタ１５００に追加する構成であっても良い。あるいは、ＰＤＬ装置がプログラムによって実現される場合には、プログラム用ＲＯＭ１３ｂに対応するプログラムを追加する構成であっても良い。更には、予め複数種類のＰＤＬ装置それぞれに対応するプログラムをプログラム用ＲＯＭ１３ｂに記憶しておき、それらから必要なＰＤＬ装置を、ユーザ操作によって入力されたライセンスキーによって有効にすることで追加する構成であっても良い。

また、ＰＤＬの一例としては、ＬＩＰＳ、ＰｏｓｔＳｃｒｉｐｔ、ＰＣＬ等がある。

また、本実施形態に適用するプリンタ１５００には、レーザビームプリンタ及びインクジェットプリンタ等の他の各種印刷方式の印刷装置（画像形成装置）を使用することが可能である。また、複数種類の機能を有するＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ：マルチファンクション周辺機器）であっても良い。

ここで、ＭＦＰは、自装置内部に複数のジョブを記憶可能なハードディスク等の記憶装置を具備している。また、例えば、スキャナ部から出力されたジョブに対し、その記憶装置を介してプリンタ部でプリント可能にするコピー機能を具備している。また、ＰＣ（パーソナルコンピュータ）等の外部装置から出力されたジョブに対し記憶装置を介してプリンタ部でプリント可能にするプリント機能を具備している。このように、ＭＦＰは、これらの機能を含む複数の機能を具備している。

ＭＦＰには、フルカラー機器とモノクロ機器があり、色処理機能や内部データ等を除いて、基本的な部分においては、フルカラー機器がモノクロ機器の構成を包含することが多い。そのため、ここでは、フルカラー機器に絞って説明し、必要に応じて随時モノクロ機器の説明を加えることとする。

また、本実施形態で説明するシステムは、複数の機能を具備した複合機能型の画像形成装置（印刷装置）でも、プリント機能のみを具備した単一機能型の画像形成装置（印刷装置）であるＳＦＰを具備する構成でも良い。いずれにしても、本実施形態の制御が実現可能な構成であればよい。

尚、ＳＦＰとは、Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ：単一機能周辺機器の略称である。

次に、プリンタ１５００のＣＰＵ１２によって実行される機能構成について、図５を用いて説明する。

図５は本発明の実施形態のプリンタの機能構成を示すブロック図である。

ジョブ受信部５０１は、ホストコンピュータ３０００から印刷ジョブを受信し、受信した印刷ジョブをジョブ解析部５０２に送信する。ジョブ解析部５０２は、印刷ジョブを解析し、後述の識別方法により印刷ジョブが生成された印刷処理フロー（印刷ジョブ生成経路）を識別する。尚、印刷ジョブと印刷データは同義である。

ジョブ解析部５０２の処理結果、及びモード設定部５０３により設定されたモードに従い印刷ジョブの処理方法が決定され、印刷ジョブを印刷する場合は、印刷ジョブは印刷部５０４に送信され、印刷が行われる。ジョブ削除部５０５は、ジョブ解析部５０２の処理結果に従い、印刷ジョブをキャンセルする処理を行う。通知部５０６は、ジョブ解析部５０２の処理結果に従い、ホストコンピュータ３０００に通知を行う。

次に、本実施形態のホストコンピュータ３０００上とプリンタ間のデータ処理例について、図６を用いて説明する。

図６は本発明の実施形態のホストコンピュータ上とプリンタ間のデータ処理例を示す図である。

ＷｉｎＦＸアプリケーション２１１からプリンタ１５００へデータが渡る際にＧＤＩプリンタドライバ２０３またはＸＰＳプリンタドライバ２１３を経由する２種類のプリントパスが存在することは前述のとおりである。

ここで、ＷｉｎＦＸアプリケーション２１１において、電子署名情報が付加された印刷ジョブを発行する状況を想定する。

ＸＰＳプリンタドライバ２１３を経由するプリントパスでは電子署名情報付きの描画データ３２３は、ＸＰＳプリンタドライバ２１３によって処理される。そして、ＸＰＳプリンタドライバ２１３により変換されたＰＤＬデータと共に電子署名情報３２５がプリンタ１５００へ送信される。ここでのフォーマットについては後述する。

一方、ＧＤＩプリンタドライバ２０３経由のプリントパスでは、ＸＰＳ→ＧＤＩ変換モジュール３１２によってＧＤＩに変換される際に電子署名情報を失い、電子署名情報なしの描画データ３２２が生成される。そして、この電子署名情報なしの描画データ３２２は、ＧＤＩプリンタドライバ２０３によって処理される。その結果、電子署名情報のないＰＤＬデータ３２４となってプリンタ１５００へ送信される。

このように、本実施形態では、この電子署名情報が失われる可能性がある印刷環境において、その印刷処理の禁止／実行を適応的に制御するためのセキュリティ機能を実現する。

このセキュリティ機能を実現するにあたり、本実施形態では、ホストコンピュータ上で生成された印刷ジョブが生成された経路に基づいて、印刷処理の禁止／実行を設定するためのモード設定部５０３を構成している。そこで、このモード設定部５０３が生成するモード設定画面について、図７を用いて説明する。

図７は本発明の実施形態における画像形成装置のモード設定画面の一例を示す図である。

このモード設定画面７００は、操作部１５０１上に表示され、プリンタの管理者が設定を行う。

各設定項目には、それぞれＯＮ／ＯＦＦを切り替えるボタンが存在し、どちらかのボタンを選択すると、ボタンは選択状態を示す黒色表示となる。

７０１は、セキュリティ設定の有効／無効を切り替えるためのボタンである。ボタン７０１がＯＦＦの場合、ボタン７０２〜７０６は、グレーアウトされ各設定項目への設定は禁止となり、設定はすべて無効となる。

７０２は、ＧＤＩ経由での印刷を禁止するか否かを設定するためのボタンである。ボタン７０２が、ＯＮの場合は印刷処理フロー（１）及び（３）で処理された印刷ジョブはキャンセルされ、印刷を禁止する。但し、ボタン７０２がＯＮであっても、ボタン７０３がＯＮの場合は、印刷処理フロー（１）で処理された印刷ジョブは印刷する。つまり、ボタン７０３がＯＮの場合は、Ｗｉｎ３２アプリケーションからの印刷ジョブについては、その印刷を許可することになる。

よって、図３の印刷処理フロー（１）のプリントパスを介して生成された印刷データは印刷されるが、図３の印刷処理フロー（３）のプリントパスを介して生成された印刷データは印刷されなくなる。また、図７の設定画面にて「クロスパス経由の印刷禁止」ボタンを設けることにより、図３の印刷処理フロー（２）及び（３）のプリントパスを介して生成された印刷データの印刷を禁止することもできる。

このように、本実施形態のプリンタは、印刷処理経路毎に印刷データの処理に係る設定を行える。例えば、図７の画面が、Ｗｉｎ３２アプリケーションとＸＰＳドライバの組み合わせによる処理経路（２）、またはＷｉｎＦＸアプリケーションとＧＤＩドライバの組み合わせによる処理経路（３）を介して生成された印刷データの印刷を禁止するか否かの設定項目を備えることができる。

７０４は、ＧＤＩ経由での印刷ジョブを受信した場合に管理者にメールで通知を行うか否かを設定するためのボタンである。尚、通知先となる管理者のメールアドレスは、管理者情報を設定する別の画面において設定済であるものとする。

７０５は、ＧＤＩ経由での印刷ジョブを受信した場合にユーザに通知するか否かを設定するためのボタンである。後述するように、この通知は、印刷ジョブを送信してきたホストコンピュータのＩＰアドレスに対してユニキャストで行われる。

また、ボタン７０４及び７０５による通知の通知方法は一例であり、メッセージダイアログによって指定されたホストコンピュータに通知したり、通知内容を指定のプリンタに出力する構成としても良い。

そして、この状態でＯＫボタン７０６を操作すると、図７中の設定状態（モード設定情報）として、例えば、ＲＡＭ１９上に記憶されるとともに、モード設定画面７００の表示が消去される。一方、キャンセル（Ｃａｎｃｅｌ）ボタン７０７を操作すると、図７中の設定状態がキャンセルされて、このモード設定画面７００の表示が消去される。

尚、図７に示すモード設定画面７００の設定項目は一例であり、用途や目的に応じて様々な設定項目を構成することが可能である。本実施形態の主眼とするところは、印刷データを生成するための複数種類の印刷処理フローが存在していて、その使用される印刷処理フローによっては、印刷不具合や不正な印刷が発生し得る状況を事前に回避したり、禁止することにある。そのため、この目的を達成するための設定項目であれば、様々な設定項目を構成できることは言うまでもない。

次に、プリンタ１５００が実行する処理について、図８を用いて説明する。

図８は本発明の実施形態のプリンタが実行する処理を示すフローチャートである。尚、図８の各ステップの処理は、プリンタのＣＰＵ１２によって実行される。

図８は、特に、プリンタ１５００がホストコンピュータ３０００から印刷ジョブを受信した際の処理を示すフローチャートである。

ステップＳ８０１で、ジョブ受信部５０１は、印刷ジョブを受信する。ステップＳ８０２で、ジョブ解析部５０２は、印刷ジョブを解析し、印刷ジョブが生成された経路（印刷処理フロー（印刷ジョブ生成経路））を識別する。尚、ジョブ生成経路の識別方法については図１８にて後述する。次に、ステップＳ８０３で、モード設定部５０３は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定として、ボタン７０１の設定値がＯＮであるか否かを判定する。

セキュリティ設定がＯＦＦである場合（ステップＳ８０３でＮＯ）、ステップＳ８０９に進み、印刷ジョブを印刷して処理を終了する。一方、セキュリティ設定がＯＮである場合（ステップＳ８０３でＹＥＳ）、ステップＳ８０４に進み、ジョブ解析部５０２は、印刷ジョブ生成経路が印刷処理フロー（３）であるか否かを判定する。

印刷処理フロー（３）である場合（ステップＳ８０４でＹＥＳ）、プリンタ１５００は、後述するサブルーチンＳＲを実行する。その後、ステップＳ８０５で、モード設定部５０３は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定（ＧＤＩ経由の印刷禁止）として、ボタン７０２の設定値がＯＮであるか否かを判定する。

ＧＤＩ経由の印刷禁止がＯＮである場合（ステップＳ８０５でＹＥＳ）、ステップＳ８０６に進み、印刷部５０４は、印刷ジョブをキャンセルした後、処理を終了する。一方、ＧＤＩ経由の印刷禁止がＯＦＦである場合（ステップＳ８０５でＮＯ）、ステップＳ８０９に進み、印刷部５０４は、印刷ジョブを印刷して処理を終了する。

一方、ステップＳ８０４において、印刷処理フロー（３）でない場合（ステップＳ８０４でＮＯ）、ステップＳ８０７に進み、ジョブ解析部５０２は、印刷ジョブ生成経路が印刷処理フロー（１）であるか否かを判定する。

印刷処理フロー（１）である場合（ステップＳ８０７でＹＥＳ）、後述するサブルーチサブルーチンＳＲを実行する。その後、ステップＳ８０８で、モード設定部５０３は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定（Ｗｉｎ３２アプリケーションからの印刷許可）として、ボタン７０３の設定値がＯＮであるか否かを判定する。

Ｗｉｎ３２アプリケーションからの印刷許可がＯＦＦである場合（ステップＳ８０８でＮＯ）、ステップＳ８０６に進み、プリンタ１５００は、印刷ジョブをキャンセルした後、処理を終了する。一方、Ｗｉｎ３２アプリケーションからの印刷許可がＯＮである場合（ステップＳ８０８でＹＥＳ）、印刷部５０４は、印刷ジョブを印刷して処理を終了する。このように、プリンタ１５００は、ステップＳ８０２の解析結果と図７の設定内容に基づいて、受信した印刷データの処理を制御する。

図８の処理より、プリンタ１５００のＣＰＵ１２は、ステップＳ８０２の解析の結果、アプリケーションとプリンタドライバの組み合わせが特定の組み合わせであり、かつ特定の組み合わせの場合に印刷を禁止することが設定される場合、印刷データの印刷を禁止するように制御する。その結果、プリンタ１５００は、機密性の低下または印刷品質の劣化等を防止することが可能となる。

次に、図８のサブルーチンＳＲの詳細について、図９を用いて説明する。

図９は本発明の実施形態のサブルーチンＳＲの処理の詳細を示すフローチャートである。

ステップＳ９０１で、モード設定部５０３は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定（管理者通知）として、ボタン７０４の設定値がＯＮであるか否かを判定する。

管理者通知がＯＦＦである場合（ステップＳ９０１でＮＯ）、ステップＳ９０４に進む。一方、管理者通知がＯＮである場合（ステップＳ９０１でＹＥＳ）、ステップＳ９０２に進み、通知部５０６は、予め設定された管理者のメールアドレスを取得する。次に、ステップＳ９０３で、通知部５０６は、管理者宛にメールを送信する。その後、ステップＳ９０４に進む。ここで、メールの一例を図１０に示す。

例えば、ユーザがＷｉｎＦＸアプリケーションにて、電子署名情報付きのデータを生成した場合を想定する。ここで、ユーザがＷｉｎＦＸアプリケーションを介してＧＤＩプリンタドライバを選択した場合、ＷｉｎＦＸアプリケーションにて生成された電子署名付きのデータの電子署名は削除されてしまい、セキュリティを保つことができなくなる恐れがある。

プリンタは、受信した印刷データから印刷処理フロー（３）であることを解析した場合、上述したように電子署名情報が欠落した恐れがあると判定する。そして、プリンタは、適切ではないプリンタドライバを使用して印刷データが生成されたことを通知するため、図１０のようなメールを生成して管理者へ送信する。

ステップＳ９０４で、モード設定部５０３は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定（ユーザ通知）として、ボタン７０５の設定値がＯＮであるか否かを判定する。

ユーザ通知がＯＦＦである場合（ステップＳ９０４でＮＯ）、処理を終了する。一方、ユーザ通知がＯＮである場合（ステップＳ９０４でＹＥＳ）、ステップＳ９０５に進み、通知部５０６は、印刷ジョブを送信してきたホストコンピュータ３０００にユニキャストで通知メッセージを送信し、処理を終了する。

ここで、通知メッセージの一例を図１１に示す。図１１において、１１０１はプリンタの構成情報が変化したり、印刷ジョブのキャンセルが発生するたびに１ずつ増加していく整数である。ホストコンピュータ３０００は、この値を取得することにより、プリンタ１５００で上記事象が発生したことを検知することができる。

このようにセキュリティ設定として、ボタン７０１、７０２及び７０５の設定値がＯＮに設定されている状態でホストコンピュータ３０００からＧＤＩ経由での印刷ジョブを受信すると、プリンタ１５００は図１１の通知メッセージを送信する。これにより、例えば、ホストコンピュータ３０００上のＧＤＩプリンタドライバがアンインストールされ、それ以降ＧＤＩ経由での印刷を行わせないようにする（禁止）することが可能となる。

このＧＤＩプリンタドライバのアンインストールの処理について、図１２を用いて説明する。

図１２は本発明の実施形態のＧＤＩプリンタドライバのアンインストールのシーケンスを示す図である。

１２０１で、プリンタ１５００はホストコンピュータ３０００に通知メッセージを送信する。

次に、ホストコンピュータ３０００は、１２０２で、プリンタ１５００に対してデバイス情報要求を送信する。デバイス情報要求を受信したプリンタ１５００は、１２０３で、後述する方法でデバイス情報を生成し、生成したデバイス情報を、１２０４で、ホストコンピュータ３０００に送信する。

このデバイス情報の一例を図１３に示す。図１３に示すように、デバイス情報には、デバイスが有するサービス（機能（画像形成部（ＰＤＬ装置）の種類等））のリストを含んでいる。また、図１３中の＜ＳｅｒｖｉｃｅＩｄ＞要素の値は、各サービスを識別するための固有のＩＤ、つまり、識別子であり、後でサービスを特定する際に使用される。

次に、ホストコンピュータ３０００は、１２０５で、受信したデバイス情報から、必要なサービスＩＤを指定してサービス情報要求を送信する。サービス情報要求を受信したプリンタ１５００は、１２０６で、指定されたサービスＩＤに対応するＩＥＥＥ１２８４規定のデバイス情報の値を含むサービス情報をホストコンピュータ３０００に送信する。このサービス情報の一例を図１４に示す。

尚、１２０４で、プリンタ１５００が複数のサービスリストを含むデバイス情報をホストコンピュータ３０００に送信した場合、１２０５〜１２０６のシーケンスが繰り返されることになる。

ホストコンピュータ３０００は、１２０７で、プリンタ１５００から受信したサービス情報を参照し、プリンタが返さなかったＤｅｖｉｃｅＩＤに対応するプリンタドライバをアンインストールする。

次に、図１２の１２０３において、デバイス情報要求を受信したプリンタ１５００がデバイス情報を生成する際の処理について、図１５を用いて説明する。

図１５は本発明の実施形態のデバイス情報要求を受信したプリンタがデバイス情報を生成する際の処理を示すフローチャートである。

ステップＳ１５０１で、プリンタ１５００は、デバイス情報要求を受信する。ステップＳ１５０２で、プリンタがサポートしているＰＤＬ装置のＰＤＬリストから、プリンタ１５００で印刷可能なＰＤＬを１個取得する。次に、ステップＳ１５０３で、取得したＰＤＬ装置に対応するＸＰＳ対応ドライバ用のＤｅｖｉｃｅＩＤを有するサービスに対応するサービスエントリをデバイス情報に追加する。つまり、ステップＳ１５０３において、プリンタ１５００は、取得したＰＤＬに対応するＸＰＳプリンタドライバは有効なプリンタドライバであるとの情報を追加する。

次に、ステップＳ１５０４で、プリンタ１５００は、ＲＡＭ１９上のモード設定情報を参照して、セキュリティ設定として、ボタン７０１及び７０２の設定値を取得し、ＧＤＩ印刷が受付可能であるか否かを判定する。受付可能でない場合（ステップＳ１５０４でＮＯ）、ステップＳ１５０６に進む。

一方、受付可能である場合（ステップＳ１５０４でＹＥＳ）、ステップＳ１５０５に進み、取得したＰＤＬに対応するＧＤＩ対応ドライバ用のＤｅｖｉｃｅＩＤを有するサービスに対応するサービスエントリをデバイス情報に追加する。つまり、ステップＳ１５０５において、プリンタ１５００は、取得したＰＤＬに対応するＧＤＩプリンタドライバは有効であるとの情報をデバイス情報に追加する。

ステップＳ１５０６で、プリンタ１５００は、ＰＤＬリスト中のすべてのＰＤＬ装置に対して処理が終了したか否かを判定する。終了していない場合（ステップＳ１５０６でＮＯ）、ステップＳ１５０２に戻り、未処理のＰＤＬ装置を取得して、上述の処理を実行する。一方、終了している場合（ステップＳ１５０６でＹＥＳ）、ステップＳ１５０７に進み、生成したデバイス情報をホストコンピュータ３０００に送信して、処理を終了する。

以上の処理により、プリンタ１５００は、自ら処理可能な印刷データを生成するプリンタドライバを指定することが可能となる。例えば、ステップＳ１５０４においてＧＤＩ印刷が不可能と判定した場合（ステップＳ１５０４でＮＯ）、ＧＤＩプリンタドライバは有効なプリンタドライバとしてデバイス情報に追加されない。

このデバイス情報を取得したホストコンピュータは、デバイス情報にＧＤＩプリンタドライバが含まれていないため、ＧＤＩプリンタドライバを介して印刷データを生成してはいけないと判定することができる。その結果、例えば。ＷｉｎＦＸアプリケーションを用いて作成した電子署名付きのデータにおける、電子署名情報が削除された印刷データがプリンタに送信されるという恐れが解消できる。

つまり、ホストコンピュータは、デバイスから通知されるデバイス情報に従ってプリンタドライバを制御することができる。例えば、ホストコンピュータは、自ら保持しているプリンタドライバの内、通知されたデバイス情報に含まれていないプリンタドライバを特定して、そのプリンタドライバをアンインストールすることも可能である。このように、プリンタは、印刷可能な印刷データを生成できるプリンタドライバを示す識別情報を、ホストコンピュータへ通知することができる。

また、図１２の処理を用いることにより、クロスパスを介して生成された印刷データを受信した際に、プリンタが適切なプリンタドライバを推奨する処理について、図１９を用いて説明する。尚、この場合、図１２に記述されているアンインストール処理は、実行されなくて良い。

プリンタ１５００は、印刷データを受信したか否かを判定し（ステップＳ１９０１）、受信した場合、印刷データがクロスパスを介して生成された印刷データか否かを判定する（ステップＳ１９０２）。尚、クロスパスを介して生成されたか否かの解析方法は、図１８にて後述する。

ステップＳ１９０２により、ジョブ解析部５０２が、クロスパスを介して生成された印刷データであると解析した場合に、描画モジュールの変換を伴わずに印刷データを生成できるプリンタドライバの種類を特定する（ステップＳ１９０３）。詳細には、ジョブ解析手段は、図１８の処理を用いることにより、印刷要求元のアプリケーションの種類を判定できる。

具体的には、要求元のアプリケーションが、ＷｉｎＦＸアプリであるかＷｉｎ３２アプリであるかを判定する。その結果に基づいて、プリンタは、描画変換を伴わないプリンタドライバの種類を特定する。具体的には、印刷要求元がＷｉｎＦＸアプリケーションである場合、プリンタは、ＸＰＳプリンタドライバを特定する。一方、印刷要求元がＷｉｎ３２アプリケーションである場合、プリンタは、ＧＤＩプリンタドライバを特定する。

ステップＳ１９０３によって、プリンタは、特定されたプリンタドライバを含んだデバイス情報を作成する（ステップＳ１９０４）。そして、そのデバイス情報をホストコンピュータへ送信する（ステップＳ１９０５）。

ステップＳ１９０３の処理を具体例を用いて説明する。例えば、プリンタＡが、ＧＤＩプリンタドライバＡによって印刷データがクロスパスを介して生成されていると判定した場合、適切なプリンタドライバとしてＸＰＳプリンタドライバＡを特定する。そして、特定されたＸＰＳプリンタドライバＡを含むデバイス情報をホストコンピュータへ送信するため、ユーザはプリンタから推奨された適切なドライバに切り替えることができる。その結果、印刷品質の劣化、または、不正な印刷を極力防止することが可能となる。

尚、プリンタは、デバイス探索メッセージ（図１２の１２０２）に含まれるメッセージ送信元情報に対してＳ１９０４にて作成したデバイス情報を通知する。

次に、プリンタ１５００が印刷ジョブ受信時に、ジョブが生成された経路を識別する識別方法について説明する。

この識別方法を説明するにあたり、まず、ＸＰＳプリンタドライバ２１３の構成について、図１６Ａを用いて説明する。

図１６Ａは本発明の実施形態のＸＰＳプリンタドライバの構成を示す図である。

図２に示す環境において、ＧＤＩプリントパスではＤＥＶＭＯＤＥ構造体と呼ばれるデータ構造で印刷設定データを持っている。一方、ＸＰＳプリントパスではＰｒｉｎｔＴｉｃｋｅｔと呼ばれるＸＭＬ形式のデータ構造になる。ここで、ＧＤＩからＸＰＳもしくはＸＰＳからＧＤＩに変換する際にＤＥＶＭＯＤＥからＰｒｉｎｔＴｉｃｋｅｔへ、ＰｒｉｎｔＴｉｃｋｅｔからＤＥＶＭＯＤＥに変換する処理が必要となる。

そして、描画データ同様に、ＤＥＶＭＯＤＥで表現できる範囲とＰｒｉｎｔＴｉｃｋｅｔで表現できる範囲も異なる。そこで、この処理は、オペレーティングシステムが自動で行うのではなく、プリンタドライバ自身が拡張されたアーキテクチャを用いて行うようになっている。

ＸＰＳプリンタドライバ２１３は、プリントチケットプロバイダ２１３ａ、ＵＩドライバモジュール（ＸＰＳ）２１３ｂを保持している。ＵＩドライバモジュール（ＸＰＳ）２１３ｂは、ＤＥＶＭＯＤＥベースであり、アプリケーションから呼び出されることによって印刷設定情報を設定するためのＵＩを表示する。また、プリントチケットプロバイダ２１３ａは、ＰｒｉｎｔＴｉｃｋｅｔ（プリントチケット）からＤＥＶＭＯＤＥ、または、ＤＥＶＭＯＤＥからプリントチケットへの変換処理を行う。

図１６Ａでは、Ｗｉｎ３２アプリケーション２０１が、印刷設定を行うためにＤＥＶＭＯＤＥを要求する場合、ＸＰＳプリンタドライバ２１３は、ＤＥＶＭＯＤＥベースのため変換処理の必要が生じない。よって、Ｗｉｎ３２アプリケーション２０１が、ＸＰＳプリンタドライバ２１３を用いて印刷処理を行う場合、プリントチケットプロバイダ２１３ａは、変換処理を行う必要がない。

一方、ＷｉｎＦｘアプリケーション２１１は、印刷設定を行うためプリントチケットを要求する。ＸＰＳプリンタドライバ２１３は、プリントチケットを保持していないため、プリントチケットプロバイダ２１３ａは、プリントチケットからＤＥＶＭＯＤＥへの変換処理を実行する。

ここで、ＸＰＳプリンタドライバ２１３は、プリントチケットプロバイダ２１３ａの変換処理を認識することができる。そのため、印刷対象のデータを受け付けた時に、プリントチケットプロバイダ２１３ａによる、プリントチケットからＤＥＶＭＯＤＥへの変換処理が行われた場合には、印刷設定の要求元がＷｉｎＦＸアプリケーション２１１であると判定することができる。一方、印刷対象のデータを受け付けた時に、プリントチケットプロバイダ２１３ａによる変換処理が行われていない場合には、印刷設定の要求元をＷｉｎ３２アプリケーション２０１と判定することができる。

尚、ＧＤＩプリンタドライバ２０３の構造は、ＸＰＳプリンタドライバ２１３と同様であるが、ＵＩドライバモジュール（ＸＰＳ）２１３ｂに相当するものとして、ＵＩドライバモジュール（ＧＤＩ）が構成されることになる。

そして、ＧＤＩプリンタドライバ２０３と、ＸＰＳプリンタドライバ２１３と同様に、プリントチケットプロバイダ２１３ａの変換処理を認識することができる。そのため、印刷対象のデータの処理経路及び、印刷設定の要求元のアプリケーションを判定することができる。

図３において、ＷｉｎＦＸアプリケーション２１１からＧＤＩプリンタドライバ２０３に渡される印刷ジョブの内、描画データに関してはＯＳ１０２によってＸＰＳ→ＧＤＩ変換モジュール３１２が自動で変換を行う。そのため、ＧＤＩプリンタドライバ２０３は変換が行われたことを検知することができない。

一方、ステイプル処理等の印刷設定データに対しては、ＯＳ１０２が自動で変換を行うことができない。そのため、ＷｉｎＦＸアプリケーション２１１から渡されるＰｒｉｎｔＴｉｃｋｅｔを、ＧＤＩプリンタドライバ２０３の理解できる表現であるＤＥＶＭＯＤＥに変換する作業をＸＰＳプリンタドライバ２１３のＵＩドライバモジュール２１３ｂが行う。

まず、ＯＳ１０２は描画データを自動で変換する際に、印刷設定の変換をＧＤＩプリンタドライバ２０３に依頼するためにＰｒｉｎｔＴｉｃｋｅｔをＧＤＩプリンタドライバ２１３が有するＵＩドライバモジュール２１３ｂに対して引き渡す。ＯＳ１０２からＰｒｉｎｔＴｉｃｋｅｔを取得したＵＩドライバモジュール２１３ｂは与えられたＸＭＬ形式のＰｒｉｎｔＴｉｃｋｅｔ情報をＤＥＶＭＯＤＥに変換する。この際に、ＵＩドライバモジュール２１３ｂがＸＰＳ→ＧＤＩ変換モジュール３１２の変換が行われたということを示す変換フラグをＤＥＶＭＯＤＥの内部に設定する。

この処理結果の具体例について、図１６Ｂを用いて説明する。

図１６Ｂは本発明の実施形態のＰｒｉｎｔＴｉｃｋｅｔからＤＥＶＭＯＤＥへの変換の際に変換が行われたことを示す変換フラグを立てる様子を説明するための図である。

１６０１は、ＯＳからＸＰＳプリンタドライバ２１３のＵＩドライバモジュール２１３ｂに渡されるＰｒｉｎｔＴｉｃｋｅｔを示している。ＰｒｉｎｔＴｉｃｋｅｔ１６０１は、ＸＭＬ形式で表現され、用紙サイズや両面印刷の有無等の印刷設定に関わる情報を保持している。

一方、ＰｒｉｎｔＴｉｃｋｅｔ１６０１の変換後の情報が、ＤＥＶＭＯＤＥ１６０２である。ＤＥＶＭＯＤＥ１６０２は、ＧＤＩプリンタドライバ２０３で使用される印刷設定であり、ＰｒｉｎｔＴｉｃｋｅｔ１６０１と同様に用紙サイズや両面印刷の有無等が示されている。

ＸＰＳ→ＧＤＩ変換モジュール３１２の変換フラグが、ｄｍＣｏｎｖｅｒｔＦｌａｇ１６０３である。ＧＤＩプリンタドライバ変換時にＤＭ＿ＣＮＶ＿ＰＴＴＯＤＥＶＭＯＤＥを指定することで、プリントチケットプロバイダは、ＸＰＳ→ＧＤＩ変換が行われたものであることを記録している。尚、ＸＰＳ→ＧＤＩ変換の行われていないＤＥＶＭＯＤＥは、ＤＭ＿ＣＮＶ＿ＮＯＮＥが指定されることになる。

次に、ＧＤＩプリンタドライバが、ＤＥＶＭＯＤＥ及び描画データから生成する印刷データのフォーマットについて、図１７を用いて説明する。

図１７は本発明の実施形態のＧＤＩプリンタドライバが生成する印刷データのフォーマットを示す図である。

印刷データは、ジョブ印刷設定部１７０１及び描画データ部１７０２から構成されている。ジョブ印刷設定部１７０１には、部数や両面印刷等の印刷設定に関する情報に加え、ＸＰＳ→ＧＤＩ変換の有無（あり／なし）を示す変換フラグ、及び自身のドライバタイプ（ＧＤＩあるいはＸＰＳ）情報を含んでいる。プリンタ１５００は、この印刷データ（例えば、ＰＤＬデータ）を解析して、変換フラグ及びドライバタイプ情報を抽出することにより、この印刷ジョブが生成された印刷処理フロー（印刷ジョブ生成経路）を判別することができる。

ＧＤＩプリンタドライバは、プリントチケットからＤｅｖｍｏｄｅへの変換が起こっていると判定した場合、印刷要求元はＷｉｎＦＸアプリケーションと判定できる。よって、ＧＤＩプリンタドライバは、図１７に示すようにＸＰＳｔｏＧＤＩ変換あり、及び、自身のドライバタイプＧＤＩと記述した印刷データを生成する。一方、プリントチケットからＤｅｖｍｏｄｅへの変換がないと判定した場合、印刷要求元はＷｉｎ３２アプリケーションと判定できる。この場合、ＧＤＩプリンタドライバは、ＸＰＳｔｏＧＤＩ変換なし、及び、自身のドライバタイプＧＤＩと記述した印刷データを生成する。

一方、ＸＰＳプリンタドライバが生成する印刷データについても説明する。
上述したようにＸＰＳプリンタドライバは、ＷｉｎＦＸアプリケーションからの印刷要求を受信した場合、印刷機能の低下や描画結果を劣化させることなく正常に印刷できる。図１６Ａにて上述した通り、ＸＰＳプリンタドライバは、プリントチケットからＤｅｖｍｏｄｅへの変換が起こっていると判定した場合、印刷要求元はＷｉｎＦＸアプリケーションと判定できる。

この場合、印刷データは、ＧＤＩ→ＸＰＳ変換なし、及び、自身のドライバタイプＸＰＳと記述した印刷データを生成する。一方、ＸＰＳプリンタドライバは、プリントチケットからＤｅｖｍｏｄｅへの変換がないと判定した場合、印刷要求元はＷｉｎ３２アプリケーションと判定できる。この場合、印刷データは、ＧＤＩ→ＸＰＳ変換あり、及び、自身のドライバタイプＸＰＳと記述した印刷データを生成する。

このように、プリンタが受信する印刷データには、描画データの変換処理の有無を示す情報と、指定されているプリンタドライバのドライバタイプが含まれている。よって、ジョブ解析部５０２は、受信した印刷データに基づいて印刷データの生成に使用されたアプリケーションとプリンタドライバの組み合わせを解析する。

次に、図８のステップＳ８０２の処理の詳細について、図１８を用いて説明する。

図１８は本発明の実施形態のステップＳ８０２の処理の詳細を示すフローチャートである。

ここでは、特に、プリンタ１５００が、受信した印刷ジョブのジョブ生成経路（印刷処理フロー）を判別する処理について説明する。

ステップＳ１８０１で、ジョブ解析部５０２は、印刷データ中のジョブ印刷設定部１７０１に含まれるドライバタイプを識別する。図１７に示すとおり、プリンタが受信する印刷データにはドライバタイプが記述されている。ドライバタイプがＸＰＳである場合、ステップＳ１８０２に進む。

ステップＳ１８０２において、ジョブ解析部５０３は、変換フラグが立っているか否かを判定する。ここで、変換フラグが立っている場合（ステップＳ１８０２でＹＥＳ）、つまり、「ＧＤＩ→ＸＰＳ変換があり」と判定される場合、ステップＳ１８０７に進み、印刷処理フロー（４）であると判定する。一方、変換フラグが立っていない場合（ステップＳ１８０２でＮＯ）、ステップＳ１８０６に進み、印刷処理フロー（２）であると判定する。

一方、ドライバタイプがＧＤＩである場合、ステップＳ１８０３に進み、ジョブ解析部５０３は、変換フラグが立っているか否かを判定する。ここで、変換フラグが立っている場合（ステップＳ１８０３でＹＥＳ）、つまり、「ＸＰＳ→ＧＤＩ変換があり」と判定される場合、ステップＳ１８０５に進み、印刷処理フロー（３）であると判定する。

一方、変換フラグが立っていない場合（ステップＳ１８０３でＮＯ）、ステップＳ１８０４に進み、印刷処理フロー（１）であると判定する。このように、プリンタは印刷データに含まれるドライバタイプと描画データの変換フラグに基づいて、印刷処理の要求もとのアプリケーションを特定できる。その特定の結果、プリンタが、ストレートパスを介して生成された印刷データでないと解析した場合、印刷データを禁止するように制御する。

尚、本実施形態においては、ＸＰＳ→ＧＤＩ変換により失われる情報として、電子署名情報を使用したセキュリティ設定を代表例としてあげて説明している。しかしながら、本発明は、セキュリティのための印刷制限だけでなく、印刷品質に対する課題に対しても、同様の構成で対応させることが可能である。

以上説明したように、本発明によれば、プリンタにおいて、印刷ジョブが生成された経路情報を識別して、その処理内容を適応的に変更することが可能である。そのため、例えば、図７にてＧＤＩ経由での印刷を禁止（７０２がＯＮ）であり、かつ、Ｗｉｎ３２からの印刷を許可（７０３がＯＮ）の場合、印刷処理フロー（３）であると識別された時点で印刷処理がキャンセル（禁止）される。

また、図７においてセキュリティ設定を有効（７０１がＯＮ）であり、かつ、７０３及び７０４がＯＦＦの場合、プリンタは、印刷処理フロー（２）を経由した印刷処理をキャンセルしても良い。この場合、ジョブ解析部は、受信した印刷データからドライバタイプがＸＰＳであり、かつ、ＧＤＩｔｏＸＰＳ変換ありと解析した場合に、印刷処理フロー（２）と判定できるので、印刷処理をキャンセルする。

このように、プリンタは、受信した印刷データに基づいて、Ｗｉｎ３２アプリケーションとＧＤＩプリンタドライバの組み合わせによる処理経路を介して生成された印刷データであるかを解析できる。また、プリンタは、受信した印刷データに基づいて、ＷｉｎＦＸアプリケーションとＸＰＳプリンタドライバの組み合わせによる処理経路を介して生成された印刷データであるかを解析できる。

つまり、セキュリティが確保されない恐れがある印刷ジョブや印刷品質が悪くなる可能性がある印刷ジョブについては、プリンタとして、その印刷ジョブの印刷を禁止することができる。これにより、セキュリティ制限を回避する印刷を防止したり、印刷品質が低いがためにユーザが望まない結果となってしまい用紙を無駄にしてしまうことを防止する印刷システムを構成することができる。

以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスクがある。また、更に、記録媒体としては、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、その接続先のホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

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

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

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

一般的な印刷処理フロー及び印刷処理に対するコンポーネントを示す図である。 複数のグラフィクスエンジンが共存する、Ｗｉｎｄｏｗｓ（登録商標） ＶＩＳＴＡにおける印刷処理フロー及び印刷処理に対するコンポーネントを示す図である。 Ｗｉｎｄｏｗｓ（登録商標） ＶＩＳＴＡにおける、２つのグラフィクスエンジン共存の仕組みを示す図である。 本発明の実施形態のコンピュータを含むプリンタ制御システムの構成を説明するブロック図である。 本発明の実施形態のプリンタの機能構成を示すブロック図である。 本発明の実施形態のホストコンピュータ上とプリンタ間のデータ処理例を示す図である。 本発明の実施形態のモード設定画面の一例を示す図である。 本発明の実施形態のプリンタが実行する処理を示すフローチャートである。 本発明の実施形態のサブルーチンＳＲの処理の詳細を示すフローチャートである。 本発明の実施形態のプリンタが管理者に送信する電子メールの一例を示す図である。 本発明の実施形態のプリンタがホストコンピュータに送信する通知メッセージの一例を示す図である。 本発明の実施形態のＧＤＩプリンタドライバのアンインストールのシーケンスを示す図である。 本発明の実施形態のプリンタから送信されるデバイス情報の一例を示す図である。 本発明の実施形態のプリンタから送信されるサービス情報の一例を示す図である。 本発明の実施形態のデバイス情報要求を受信したプリンタがデバイス情報を生成する際の処理を示すフローチャートである。 本発明の実施形態１のＸＰＳプリンタドライバの構成を示す図である。 本発明の実施形態のＰｒｉｎｔＴｉｃｋｅｔからＤＥＶＭＯＤＥへの変換の際に変換が行われたことを示す変換フラグを立てる様子を説明するための図である。 本発明の実施形態のＧＤＩプリンタドライバが生成する印刷データのフォーマットを示す図である。 本発明の実施形態のステップＳ８０２の処理の詳細を示すフローチャートである。 本発明の実施形態のプリンタの処理を示すフローチャートである。

符号の説明

５０１ ジョブ受信部
５０２ ジョブ解析部
５０３ モード設定部
５０４ 印刷部
５０５ ジョブ削除部
５０６ 通知部

Claims (8)

1. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置であって、
   前記情報処理装置より印刷データを受信する受信手段と、
   前記受信手段で受信した印刷データが、前記第１アプリケーションと第１プリンタドライバの組み合わせによる処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第２プリンタドライバの組み合わせによる処理経路を介して生成された印刷データでないと解析された場合、前記受信手段によって受信された印刷データの印刷を禁止するように制御する制御手段と
   を備えることを特徴とする画像形成装置。
2. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置であって、
   前記情報処理装置より印刷データを受信する受信手段と、
   前記受信手段で受信した印刷データが、前記第１アプリケーションと第２プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第１プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データであると解析された場合、前記描画変換を伴わない種類のプリンタドライバを特定する特定手段と、
   前記特定手段によって特定された種類のプリンタドライバを含むデバイス情報を前記情報処理装置に対して通知する通知手段
   を備えることを特徴とする画像形成装置。
3. 前記通知手段は、デバイス探索メッセージに含まれるメッセージ送信元情報に対して前記デバイス情報を通知する
   ことを特徴とする請求項２に記載の画像形成装置。
4. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置の制御方法であって、
   前記情報処理装置より印刷データを受信する受信工程と、
   前記受信工程で受信した印刷データが、前記第１アプリケーションと第１プリンタドライバの組み合わせによる処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第２プリンタドライバの組み合わせによる処理経路を介して生成された印刷データでないと解析された場合、前記受信工程によって受信された印刷データの印刷を禁止するように制御する制御工程と
   を備えることを特徴とする画像形成装置の制御方法。
5. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置の制御方法であって、
   前記情報処理装置より印刷データを受信する受信工程と、
   前記受信工程で受信した印刷データが、前記第１アプリケーションと第２プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第１プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データであると解析された場合、前記描画変換を伴わない種類のプリンタドライバを特定する特定工程と、
   前記特定工程によって特定された種類のプリンタドライバを含むデバイス情報を前記情報処理装置に対して通知する通知工程
   を備えることを特徴とする画像形成装置の制御方法。
6. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置の制御をコンピュータに実行させるためのプログラムであって、
   前記情報処理装置より印刷データを受信する受信工程と、
   前記受信工程で受信した印刷データが、前記第１アプリケーションと第１プリンタドライバの組み合わせによる処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第２プリンタドライバの組み合わせによる処理経路を介して生成された印刷データでないと解析された場合、前記受信工程によって受信された印刷データの印刷を禁止するように制御する制御工程と
   をコンピュータに実行させることを特徴とするプログラム。
7. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置で生成された印刷データを受信して、印刷を行う画像形成装置の制御をコンピュータに実行させるためのプログラムであって、
   前記情報処理装置より印刷データを受信する受信工程と、
   前記受信工程で受信した印刷データが、前記第１アプリケーションと第２プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データ、または、前記第２アプリケーションと第１プリンタドライバの組み合わせによる描画変換を伴う処理経路を介して生成された印刷データであると解析された場合、前記描画変換を伴わない種類のプリンタドライバを特定する特定工程と、
   前記特定工程によって特定された種類のプリンタドライバを含むデバイス情報を前記情報処理装置に対して通知する通知工程
   をコンピュータに実行させることを特徴とするプログラム。
8. 前記通知工程は、デバイス探索メッセージに含まれるメッセージ送信元情報に対して前記デバイス情報を通知する
   ことを特徴とする請求項７に記載のプログラム。

Images