JP2006259853A - 情報処理装置 - Google Patents

Abstract

【課題】 メンバプリンタの台数、印刷処理装置の能力によってはメンバプリンタドライバの機能を反映した仮想プリンタドライバ印刷設定画面の表示に時間を要するという問題があった。
【解決手段】 複数のメンバプリンタにより構成される仮想プリンタのジョブ制御を行う情報処理装置において、メンバプリンタとのコンフリクト処理方法をメンバプリンタの構成台数、印刷処理装置の処理パフォーマンス及び、コンフリクト処理時間により切り替え、設定画面の表示を一定の時間内に行えるようコンフリクト処理方法を制御する。
【選択図】 図１０

Description

本発明は、仮想プリンタドライバ（以降、仮想ドライバ）の仕組みに関する。

従来、アプリケーションデータから作成されたＥＭＦ（Ｅｎｈａｎｃｅｄ Ｍｅｔａ−Ｆｉｌｅ）と、仮想ドライバを介しての設定に基づき作成されたジョブ記述ファイルとを用意し、ジョブ記述ファイルに含まれるジョブの配布先のプリンタに対しＥＭＦを変換したコマンドを送信し、同報、分散印刷を行う仕組みが知られている。

例えば特許文献１には、上に述べたような仮想ドライバを利用する印刷において、仮想ドライバのダイアログ画面を介して設定された、メーカやプリンタ機種に依存しない共通な情報（用紙サイズ、用紙種等）をＤＥＶＭＯＤＥ情報として印刷設定する仕組みが開示されている。

この仮想ドライバのダイアログ画面の設定可能項目は固定的なものとなっており、同報印刷に利用される複数のプリンタを代表するものであり、同報印刷などの配布印刷では、ユーザは複数のプリンタにまとめて所定の設定を行えるというメリットを受けることができた。
特開平１１−１４３６６１号公報

しかしながら、従来から知られている特許文献１によれば仮想ドライバのダイアログ画面を介して設定可能な項目が固定的なものとなっており、複数のプリンタの各々の機能を画一的なものとして扱うことになり、実際には異なる各々のプリンタの機能を十分に反映させたものであるとは云えず、各々のプリンタの機能を十分に生かしきれないという問題が挙げられる。

このような問題点を解決するために各々のプリンタの機能を取得し、取得した情報を元に各々のプリンタに矛盾の無いような印刷設定項目を特定し、該特定された印刷設定項目を仮想ドライバのダイアログ画面に反映させるようにすることが望まれる。しかしながら、従来から知られている特許文献１によれば、各々のプリンタの機能を十分に生かすべく各々のプリンタの機能の取得処理などを想定しておらず、単に仮想ドライバのダイアログ画面を表示させるという仕組みであったため、仮想ドライバのダイアログ画面の生成に数秒から数十秒要する場合に、ユーザに不安を与えてしまうという問題があった。場合によっては、ユーザは印刷処理装置（パーソナルコンピュータ等）がフリーズしたと勘違いし、印刷処理装置を再起動させてしまうような問題もある。

本発明は上記問題点を鑑みてなされたものであり、仮想ドライバの設定画面表示を一定の時間内に行いユーザに不安を与えることなく提示可能な仕組みを提供することを目的とする。

本発明は上記目的を達成する為に、複数のメンバプリンタにより構成される仮想プリンタのジョブ制御に関わる仕組みにおいて、複数のメンバプリンタのそれぞれの機能に基づくコンフリクト処理を行うコンフリクト手段と、コンフリクト手段によるコンフリクト結果を、前記仮想ドライバの設定画面に反映させる表示制御手段と、メンバプリンタの構成を調べる調査手段と、本システムが導入されている印刷処理装置（パーソナルコンピュータ等）のスペックを読み出す手段を有し、さらにコンフリクト手段は、前記システムより読み出した構成メンバ台数、印刷処理装置スペック及び、コンフリクト方法切り替え判定情報及びコンフリクト処理時間に基づき、コンフリクト処理の切り替え制御を行うことを特徴とする仕組みを提供する。

仮想ドライバの設定画面上で設定を行い印刷する際に、メンバプリンタの台数が増加しても、メンバプリンタとのコンフリクト処理をメンバプリンタの構成台数、印刷処理装置の処理パフォーマンス及び処理時間によりダイナミックに切り替えることで設定画面表示を一定の時間内に行う事により、ユーザに不安を与えることなく提示可能な仕組みを提供することを可能にしたので、従来発生していたメンバ台数が多い場合にはＵＩ表示に時間がかかりすぎ、ユーザが印刷処理装置（パーソナルコンピュータ等）がフリーズしたと勘違いし印刷処理装置を再起動させてしまうようなケースを防ぐことが可能となった。

以下、本発明を適用するのに好適である実施形態について説明を行う。

〔第１の実施の形態〕
図１は、本発明を適用可能な情報処理システムの構成を説明するブロック図である。なお、本システムにおけるクライアントコンピュータは、１台、または複数台接続されていることを仮定している。

図において、１０２、１０３、１０４はクライアントコンピュータ（クライアント）としての情報処理装置であり、イーサネット（登録商標）などのネットワークケーブルによって、ネットワーク１０６に接続され、アプリケーションプログラム等の各種のプログラムを実行可能であり、印刷データをプリンタに対応する或は解釈可能なプリンタ言語に変換する機能を有するプリンタドライバを搭載している。なお、後述にて詳しく説明するが、本発明におけるプリンタドライバは複数のプリンタドライバをサポートするものとする。

１０１は本実施形態のサーバ（以下、プリントサーバと呼ぶ）としての情報処理装置であり、ネットワークケーブルによって、ネットワーク１０６に接続され、ネットワークで使用されるファイルを蓄積したり、ネットワーク１０６の使用状態を監視したりする。プリントサーバ１０１は、ネットワーク１０６に接続されている複数のプリンタを管理する機能を有する。

構成としては、クライアント１０２〜１０４とプリントサーバ１０１は、一般的な情報処理装置であり、クライアントとプリントサーバには、それぞれ異なる制御を行う印刷制御プログラムが実行可能に格納されている。

また、プリントサーバ１０１は、一般的な情報処理装置であり、クライアント１０２〜１０４の機能を同時に持つこともできる。

本実施形態におけるプリントサーバ１０１は、さらにクライアントコンピュータ１０２、１０３、１０４から印刷要求が出された印字データを含む印刷ジョブを格納して印刷させたり、または、クライアントコンピュータ１０２、１０３、１０４から印字データを含まないジョブ情報のみ受け取り、クライアントコンピュータ１０２、１０３、１０４のプリンタへの印刷データを送出する印刷順序を管理し、印刷順序になったクライアントに対して印字データを含む印刷ジョブの送信許可を通知したり、ネットワークプリンタ１０５のステータスや印刷ジョブの各種情報を取得し、クライアントコンピュータ１０２、１０３、１０４に通知したりする機能を揃えている。

１０５は印刷制御装置であるネットワークプリンタであり、図示省略したネットワークインターフェイスを介してネットワーク１０６と接続されており、クライアントコンピュータやプリントサーバ１０１から送信される印字データを含む印刷ジョブを解析してドットイメージに変換して、１ページ毎に印刷する。１０６はネットワークであり、クライントコンピュータ１０２、１０３、１０４、サーバ１０１、ネットワークプリンタ１０５等を通信可能に接続している。

図２は、本発明の情報処理装置の構成を説明するブロック図であり、情報処理装置であるクライントコンピュータ１０２、１０３、１０４も同じ構成であり、さらにサーバ１０１も同様あるいは同等のハードウエア構成とする。よって、クライアントとサーバの構成を説明するブロック図として説明する。

図２において、２００は情報処理装置の制御手段であるＣＰＵであり、ハードディスク（ＨＤ）２０５に格納されているアプリケーションプログラム、プリンタドライバプログラム、ＯＳや本発明のネットワークプリンタ制御プログラム等を実行し、ＲＡＭ２０２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。

２０１は記憶手段であるＲＯＭであり、内部には、基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。２０２は一時記憶手段であるＲＡＭであり、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。

２０３は記憶媒体読み込み手段としてのフロッピー（登録商標）ディスク（ＦＤ）ドライブであり、後述する図５に示すようにＦＤドライブ２０３を通じて記憶媒体としてのＦＤ２０４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。なお、記憶媒体は、ＦＤに限らず、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意である。

２０４は記憶媒体であるフロッピー（登録商標）ディスク（ＦＤ）であり、コンピュータが読み取り可能なプログラムが格納された記憶媒体である。

２０５は外部記憶手段の一つであり、大容量メモリとして機能するハードディスク（ＨＤ）であり、アプリケーションプログラム、プリンタドライバプログラム、ＯＳ、ネットワークプリンタ制御プログラム、関連プログラム等を格納している。さらにスプール手段であるスプーラはここに確保される。スプール手段は、クライアントではクライアントスプーラのことであり、プリントサーバではサーバスプーラのことである。また、プリントサーバでは、クライアントから受けたジョブ情報を格納し、順序制御を行うためのテーブルもこの外部記憶手段に生成されて格納される。

２０６は指示入力手段であるキーボードであり、ユーザがクライアントコンピュータに対して、また、オペレータや管理者がプリントサーバに対して、デバイスの制御コマンドの命令等を入力指示するものである。

２０７は表示手段であるディスプレイであり、キーボード２０６から入力したコマンドや、プリンタの状態等を表示したりするものである。

２０８はシステムバスであり、クライアントやプリントサーバであるコンピュータ内のデータの流れを司るものである。

２０９は入出力手段であるインターフェイスであり、該インターフェイス２０９を介して情報処理装置は外部装置とのデータのやり取りを行う。

図３は、図２に示したＲＡＭ２０２のメモリマップの一例を示す図であり、ＦＤ２０４からロードされる上記ネットワークプリンタ制御プログラムが、ＲＡＭ２０２にロードされ実行可能となった状態のメモリマップである。

本実施形態では、ＦＤ２０４からネットワークプリンタ制御プログラムおよび関連データを直接ＲＡＭ２０２にロードして実行させる例を示すが、これ以外にも、ＦＤ２０４からネットワークプリンタ制御プログラムを動作させる度に、既にネットワークプリンタ制御プログラムがインストールされているＨＤ２０５からＲＡＭ２０２にロードするようにしてもよい。

また、本ネットワークプリンタ制御プログラムを記憶する媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＰＣカード、ＤＶＤ、ＩＣメモリカード等、情報が記憶できる媒体であれば適用可能である。さらに、本ネットワークプリンタ制御プログラムをＲＯＭ２０１に記憶しておき、これをメモリマップの一部となすように構成し、直接ＣＰＵ２００で実行することも可能である。

また、以上の各装置と同等の機能を実現するソフトウェアをもって、ハードウエア装置の代替として構成することもできる。

また、本ネットワークプリンタ制御プログラムのことを、簡単に印刷制御プログラムと呼ぶこともある。印刷制御プログラムは、クライアントにおいて印刷ジョブの印刷先の変更を指示したり、印刷順序を変更する指示をするための制御を行うプログラムを含み、また、プリントサーバにおいて、印刷ジョブの順序制御を行ったり、印刷ジョブの印刷終了や印刷先変更要求などを通知するためのプログラムを含んでいる。また、このような制御を行う本発明の印刷制御プログラムは、クライアントにインストールされるモジュールと、プリントサーバにインストールされるモジュールを別々に分けてもよいし、ひとつの印刷制御プログラムが、実行される環境によりクライアント用として機能したり、またはプリントサーバ用として機能するようにしてもよい。あるいは一台のコンピュータに、クライアント用の機能を持つモジュールと、プリントサーバ用として機能するモジュールをともにインストールし、同時に、あるいは時分割で擬似的に平行動作させる構成も可能である。

３０１は基本Ｉ／Ｏプログラムであり、本制御装置の電源がＯＮされたときに、ＨＤ２０５からＯＳがＲＡＭ２０２に読み込まれ、ＯＳの動作を開始させるＩＰＬ（イニシャルプログラムローデイング）機能などを有しているプログラムが入っている領域である。

３０２はオペレーティングシステム（ＯＳ）であり、３０３はネットワークプリンタ制御プログラムで、ＲＡＭ２０２上に確保される領域に記憶される。３０４は関連データで、ＲＡＭ２０２上に確保される領域に記憶される。３０５はワークエリアで、ＣＰＵ２００が本プリンタ制御プログラムを実行する領域が確保されている。

図４は、図２に示したＦＤ２０４のメモリマップの一例を示す図である。

図４において、４００は前記ＦＤ２０４のデータ内容であり、４０１はデータの情報を示すボリューム情報であり、４０２はディレクトリ情報、４０３は本実施形態で説明する印刷制御プログラムであるネットワークプリンタ制御プログラム、４０４はその関連データである。４０３のネットワークプリンタ制御プログラムは、実施形態で説明するフローチャートに基づいてプログラム化したものであり、本実施例では、クライアント、サーバ共、同様の構成をとっている。

図５は、図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図であり、図２と同一のものには同一の符号を付してある。

図５において、ＦＤ２０４には、本実施形態で説明するネットワークプリンタ制御プログラムおよび関連データを格納している。

次に本実施の形態における、プリンタを複数台使用して、前述の分散、同報、代行といった印刷処理を行う、印刷ジョブ制御システムについて説明する。

なお、本実施の形態では、複数のプリンタを１台のプリンタとして仮想的に束ねるプリンタをグループプリンタ、束ねられるプリンタをメンバプリンタと呼ぶ。また、それに対応するプリンタドライバをそれぞれグループプリンタドライバ、メンバプリンタドライバと呼ぶ。

図６は本システムのクライアントサーバモデルにおいてＭｉｃｒｏｓｏｆｔＷｏｒｄ（登録商標）などの一般的なアプリケーションから発行された印刷ジョブが、印刷ジョブ制御システムにおいてどのように処理されるかを示した図である。図６において、６００はクライアントマシンで、印刷ジョブ制御システムのクライアントモジュールが動作するマシンを指す。

通常、印刷の指示がされるとアプリケーションプログラムは一連の描画命令を生成し、プリンタドライバを経てＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒに渡される。Ｗｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒは、ユーザが選択したポートモニタにプリントジョブデータを渡してプリンタデバイスに送信させる手順をとる。

本実施の形態では、ユーザはあらかじめ印刷ジョブ制御システム用のポートモニタ６２１（以降、本実施例ではジョブ制御ポートモニタと略記）を指定して印刷を指示する。アプリケーションプログラム６０１は一連の描画命令を生成する。描画命令を受け取ったグループプリンタドライバ６０３では、汎用印刷ファイルを生成し、プリンタデバイスへプリントジョブデータを送信するポートモニタではなく、ジョブ制御ポートモニタ６２１にプリントジョブデータとして送信する。ジョブ制御ポートモニタ６２１はプリントジョブデータをプリンタデバイス６５０に送信するのではなく、印刷ジョブ制御システム用プリントサービス６２２（以降、本実施例ではジョブ制御プリントサービスと略記）に送信する。ジョブ制御プリントサービス６２２は、プリントジョブデータに対して、後述するような印刷ジョブ制御処理を行う。

印刷ジョブ制御システム用プリントマネージャ６２３（以降、本実施例ではジョブ制御プリントマネージャと略記）は、ユーザがジョブ制御プリントサービス６２２内部でプリントジョブがどのような状態にあるかを調べたり、プリントジョブを操作したりするためのユーザインターフェイス（ＵＩ）を提供するプログラムである。

ジョブ制御プリントマネージャ６２３はジョブ制御プリントサービス６２２のソフトウェアのインターフェイス（ＡＰＩ）を介して、ジョブ制御プリントサービス６２２と情報・指示をやり取りしている。

印刷ジョブ制御システム用サーバ６３０（以降、本実施例ではジョブ制御サーバと略記）は、個々のクライアント６００上のジョブ制御プリントサービス６２２がプリンタデバイス６５０にプリントジョブデータを送信するタイミングを集中制御（スケジューリング）している。

印刷ジョブ制御システム用マネージメントコンソール６３３（以降、本実施例ではジョブ制御マネージメントコンソールと略記）は、ジョブ制御サーバ６３０が持つソフトウェアがアクセスするためのＡＰＩを介してジョブ制御サーバ６３０と情報・指示をやり取りすることで、印刷ジョブ制御システム全体を監視することができる。

また、ジョブ制御サーバ６３０はデバイス情報コントロールモジュール６３１を用いて各プリンタデバイス６５０と通信を行い、各プリンタ内の印刷ジョブや動作状態に関する情報を入手したり、操作を行ったりする。入手した情報はクライアント６００側のジョブ制御プリントサービス６２２に渡すことができる。

次に本実施の形態におけるグループプリンタドライバ６０３からの印刷について説明する。

グループプリンタドライバ６０３はアプリケーションプログラムが生成した一連の描画コマンドを、プリンタデバイスやＯＳ等の種類に依存しない中間フォーマットのファイルである汎用印刷ファイルに変換する。この汎用印刷ファイルの構成については後述する。

この汎用印刷ファイルは前述したようにＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４からジョブ制御ポートモニタ６２１を経て（ａ）、ジョブ制御プリントサービス６２２に導かれる（ｂ）。ジョブ制御プリントサービス６２２はこのプリントジョブに対して行うジョブ制御の種類に応じて、汎用印刷ファイルをもとに描画コマンドを生成し（ｃ）、続いてＰＤＬドライバ６０２がその描画コマンドをプリンタデバイス６５０が解釈可能なＰＤＬファイルにする。図６では、ジョブ制御プリントサービス６２２で、このプリントジョブに対してプリントジョブをふたつに分けるジョブ制御が行われる例で、２つのメンバジョブが生成された例を２つの矢印（ｃ）で示している。ＰＤＬドライバ６０２で生成されたＰＤＬファイルはＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４、ジョブ制御ポートモニタ６２１を経て（ｄ）、再びジョブ制御プリントサービス６２２に渡される（ｅ）。ジョブ制御プリントサービス６２２は、ジョブ制御サーバ６３０の指示に従ってＰＤＬのプリントジョブデータをプリンタデバイス６５０に送信する（ｆ）。

ジョブ制御プリントサービス６２２は、汎用印刷ファイル中の印刷指示書の指示にしたがって、一つの汎用印刷ファイルを複数のプリントジョブに論理的に分割してそれぞれ別のプリンタデバイスに送信したり、一度送信したプリントジョブデータを別のプリンタデバイスに送信し直したりする。尚、図６のＡ中の（ｃ）（ｄ）（ｅ）（ｆ）はそのような場合のプリントジョブデータの経路を示している。

一方、汎用印刷ファイルをアプリケーションソフトウェアが作成し、そのアプリケーションソフトウェアが直接汎用印刷ファイルを印刷ジョブとして投入する場合、一般のアプリケーションとはグループプリンタドライバ６０３への情報の渡し方や、グループプリンタドライバ６０３での処理内容が異なる。前述のように、一般のアプリケーションの場合、アプリケーションはグループプリンタドライバ６０３に描画情報を渡す際、通常のプリンタドライバと同じようにＷｉｎｄｏｗｓ（登録商標）のＧＤＩ関数を呼び出し、グループプリンタドライバ６０３がそれに応じて汎用印刷ファイルを生成する。これに対して汎用印刷ファイルを直接作成するアプリケーションの場合は、アプリケーションが汎用印刷ファイルをすでに持ち、それをグループプリンタドライバ６０３に供給する。グループプリンタドライバ６０３は必要に応じてあらかじめ設定された印刷方法にもとづいて汎用印刷ファイル内部の印刷指示書を書き換えてＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４に送る。

図８は、汎用印刷ファイルの構成の一例を示した図である。

本実施の形態で使用される汎用印刷ファイルは、印刷指示部８−ａと、ドキュメントデータ部８−ｂからなる。印刷指示部は、ドキュメントの情報と印刷指示を記述した部分である。また、ドキュメントデータは、アプリケーションのドキュメントのデータをＰＤＦ（Ａｄｏｂｅｓｙｓｔｅｍｓ登録商標）などの汎用的な形式のデータに変換したものであり、プリンタ言語に依存しないデータフォーマットとなっている。

印刷指示部はヘッダ部、ページ情報部、印刷体裁指示部、出力方法指定部、グループプリンタドライバ設定情報部、メンバプリンタ数、メンバプリンタドライバ名、メンバプリンタドライバ設定情報部などから構成されている。

ヘッダ部は本ファイルのバージョン識別やファイル情報などの情報を格納する部分である。

ページ情報部は、ドキュメントデータ部８−ｂのドキュメントデータのページ数、各ページのサイズなどの情報を格納する部分である。

印刷体裁指示部は、印刷ページ範囲、印刷部数、ドキュメントデータの面付け情報（Ｎ−ＵＰや製本印刷など）、ステイプル指示やパンチ指示など、出力体裁に関する情報を格納する部分である。

出力方法指定部は、出力方法として、分散印刷、カラーモノクロ分散印刷、代行印刷、同報印刷などの情報を格納する部分である。

グループプリンタドライバ設定情報部は、後述するグループプリンタドライバのＵＩの設定情報を格納する部分である。

メンバプリンタ数はグループプリンタドライバが関連付けているメンバプリンタの数を格納する部分である。

メンバプリンタドライバ名は、メンバプリンタのプリンタドライバ名を格納する部分である。

メンバプリンタドライバ設定情報部はメンバプリンタのドライバＵＩの設定情報として例えばＤＥＶＭＯＤＥ情報を格納する部分である。

このメンバプリンタドライバ名とメンバプリンタドライバ設定情報部は、前述のメンバプリンタ数に格納された数だけの格納エリアを持っている。

前述の図６で説明したグループプリンタドライバ６０３では、汎用印刷ファイルを生成する際、グループプリンタドライバＧＵＩ上の設定を印刷指示部８−ｂヨ記録する。さらに、グループプリンタドライバ６０３はＧＤＩで受け取ったデータを汎用的なデータに変換しドキュメントデータとして、本汎用印刷ファイルのドキュメントデータ部に記録することとなる。

なお、本ファイルは、印刷指示部８−ａとドキュメントデータ部８−ｂが異なるファイルであってもかまわない。その場合、印刷指示部は印刷指示書ファイルとして、ドキュメントデータ部はドキュメントデータファイルとしてそれぞれ存在し、これらを一つのアーカイブ形式でまとめて同様に一つのファイルのように扱うこともが可能である。

次に図７でＷｉｎｄｏｗｓ（登録商標）が提供するＰｒｉｎｔＳｙｓｔｅｍと印刷ジョブ制御システムにおける印刷ジョブの関係と処理概要をさらに詳しく述べる。

図７中で印刷ジョブ制御システム７００は、サーバとクライアントの制御プログラムが動作する物理的なマシンをまたいだ、印刷ジョブ制御システムの範囲を示している。また、サーバが管理している出力ポート（ＯｕｔｐｕｔＰｏｒｔ）７１１は、クライアントのジョブ制御プリントサービス６２２のプロキシ出力ポート（ＰｒｏｘｙＯｕｔｐｕｔＰｏｒｔ）７１２と関連付けられ、ひとつのポートに関連づけられた各クライアント上のプロキシ出力ポート全てを統一的に管理している。本実施例では、実際のプリントジョブデータはおのおののクライアントのプロキシ出力ポート７１２に保持される。ジョブ制御サーバ６３０は、プリントジョブデータ自体の送信処理は行わず、ジョブ制御プリントサービス６２２に対して印刷ジョブの送信指示のみを行う。その指示に応じてクライアントのジョブ制御プリントサービス６２２はプリントジョブデータをデバイス６５０に送信する。

次に、印刷ジョブ制御システム７００が、代行印刷、分散印刷、同報印刷などの付加価値的な印刷を行う場合の処理を説明する。

印刷ジョブ制御システム７００が、代行印刷、分散印刷、同報印刷などの付加価値的な印刷を行う場合には、前述のようにユーザまたはアプリケーション６０１はグループプリンタドライバ６０３が割り当てられたプリンタに印刷ジョブを発行しなければならない。ジョブ制御プリントサービス６２２は、グループプリンタドライバ６０３によって処理されたジョブデータをジョブ制御ポートモニタ６２１を介して汎用印刷ファイルとして受け取る。ジョブ制御プリントサービス６２２はこのジョブを受け取り、Ｄｅ−ｓｐｏｏｌｅｒ７０１を介してＰＤＬドライバが割り当てられた別のプリンタにジョブ（メンバジョブ）を発行して印刷を行わせる。この時、Ｄｅ−ｓｐｏｏｌｅｒ７０１は前述の図８で説明した汎用印刷ファイルの印刷指示部８−ａを解釈し、ドキュメントデータ部８−ｂのドキュメントデータを加工して、Ｗｉｎｄｏｗｓ（登録商標）のＧＤＩに変換し、各プリンタドライバに対して印刷指示を行い印刷ジョブを発行する。例えば印刷体裁指定部に、２−ＵＰの指示が記録されていた場合、用紙１枚に２ページ分のドキュメントデータを縮小レイアウトする。また分散印刷あるいは同報印刷の場合には、それらの設定に応じて印刷指示部８−ａに記述されている複数のメンバプリンタにジョブを発行する。代行印刷の場合は、代行する条件が満たされた時に、自動代行では事前の設定、手動代行ではユーザの操作に応じてメンバジョブを発行する。

また、Ｄｅ−ｓｐｏｏｌｅｒ７０１は各メンバプリンタにジョブを発行する際、メンバプリンタドライバに対応する印刷指示として、各メンバプリンタのＤＥＶＭＯＤＥを作成する必要があるが、このＤＥＶＭＯＤＥは印刷指示部８−ａに記載された内容を適宜各メンバプリンタのＤＥＶＭＯＤＥに反映させて生成する。

クライアント側のジョブ制御プリントサービス６２２は、ＰＤＬドライバ６０２によってレンダリングされた、それぞれのメンバジョブのＰＤＬデータをジョブ制御ポートモニタ６２１を介して受け取り、受け取ったジョブに関する情報をサーバ側に知らせ、ジョブデータは自身のプロキシ出力キュー（ＰｒｏｘｙＯｕｔｐｕｔＰｏｒｔ）７１２で一時保持する。その後、ジョブ制御サーバ６３０からの送信指示を受けた後にプリントデバイス６５０に送信する。

図９は、本発明のグループプリンタドライバのＵＩ制御フローを示すフローチャートである。尚、図９のフローチャートの各ステップにおける処理は上に説明した情報処理装置に設けられたＣＰＵ（中央演算処理装置）が、ＲＯＭ、ＦＤ、ハードディスク（ＨＤ）等の所定の記憶媒体に記憶された制御プログラムを読込み、該読込んだプログラムに基づく処理を実行することに応じて実現されるものとする。

以下、複数のメンバプリンタにより構成されるグループプリンタのジョブ制御を行う仕組みにおいて、複数のメンバプリンタドライバのそれぞれの機能に基づくコンフリクト処理を行うコンフリクト手段と、コンフリクト手段によるコンフリクト結果をグループプリンタドライバの設定画面に反映させる表示制御手段と、メンバプリンタの構成を調べる調査手段と、本システムが導入されている印刷処理装置（パーソナルコンピュータ等、以降ＰＣ）のスペックを読み出す手段を有し、前記コンフリクト手段において、構成メンバ台数、ＰＣスペック、及びコンフリクト方法切り替え判定情報、及びコンフリクト処理時間に基づき、コンフリクト処理の切り替え制御を行うことを特徴とする情報処理装置。

まず、アプリケーションからグループプリンタドライバへのＵＩ表示要求が来ると、処理はステップ９−１へ進む。

ステップ９−２では、グループプリンタドライバを構成するメンバプリンタの台数及び本システムが導入されているＰＣのスペックを読み出し、複数のメンバプリンタのそれぞれの機能に基づくコンフリクト処理を行うステップであり、図１０はその詳細である。

ステップ９−３は、前記ステップで行ったコンフリクト処理に基づき仮想プリンタドライバの印刷設定画面に反映させる表示制御手段である。メンバプリンタの構成は所定の仮想プリンタ毎に特有のものであり、ユーザ操作などによりメンバプリンタを削除／変更／追加できたりする。図９のフローチャートはそのようなダイナミックに変更しうるメンバプリンタ構成に適応したＵＩ表示制御を行うものとなっている。

図１０は、ステップ９−２の詳細な処理を示した図でありコンフリクト処理の切り替え制御を行うステップである。ステップ１０−１は、印刷ジョブ制御システムＡＰＩを使って、グループプリンタを構成するメンバプリンタの数を取得する。一般的にクライアントＰＣには複数種類のグループプリンタ（仮想プリンタ）が備えられており、各々のグループプリンタ毎にメンバプリンタの構成が異なる可能性がある。ステップ１０−１では、現在選択されているグループプリンタに対応するメンバプリンタの数が調べられる。またステップ１０−１の処理には、グループプリンタを構成するメンバプリンタドライバの識別ＩＤを問い合わせる処理も含まれており、この取得された各メンバプリンタドライバの識別ＩＤを用いて、ＩＤの数から構成台数を算出するようにしても良い。ステップ１０−３は、クライアントＰＣのＣＰＵスペックを読み出すステップであり、ＯＳが提供しているＡＰＩよりマシンのＣＰＵの能力をたとえば、ＭＨｚの単位で読み出す。ステップ１０−３は、ステップ１０−１，１０−２で読み出し情報を元にコンフリクトレベルを判定するステップであり、その詳細が図１１−１である。また図１１−２はコンフリクト方法切り替え判定情報テーブルの一例である。前記、切り替え判定情報テーブルは、メンバ台数及びＰＣのスペックをパラメータにもつ２次元のテーブルである。図１１−１のテーブルについて例を上げて説明する。なお、表中の各セルにある、Ｆ，Ｈ，Ｚは、それぞれの意味は、Ｆ（フルコンフリクト）、Ｈ（ハーフコンフリクト）、Ｚ（ゼロコンフリクト）をそれぞれ示しており、詳細については、ステップ１０−６で説明を行う。縦軸のパラメータは、メンバ台数を示しており、たとえば１５と記載されている部分は、メンバ台数が１１台から１５台までを示しており、同様に横軸のパラメータは、システム導入環境のＣＰＵパフォーマンスを示している。たとえば５００と記載されている部分は、４０１から５００ＭＨｚまでのＣＰＵパフォーマンスを搭載したマシン環境を示している。したがって、メンバ台数が、１３台でＰＣスペックが４３３ＭＨｚの場合には図１１−２の表よりコンフリクトレベルはハーフコンフリクトと読み出せる。ステップ１１−１は、前述の処理フローをステップ化したものであり、ステップ１０−１で読み出しグループプリンタを構成するメンバプリンタの台数が、コンフリクト方法切り替え判定情報テーブルのメンバ台数のどのレンジに相当するかを判定するステップである。本ステップでメンバプリンタ台数のレンジを確定した後、ステップ１１−２へ進む。ステップ１１−２は、ステップ１０−２で読み出したマシンスペックが前記テーブルのどのレンジに相当するかを判定するステップである。ステップ１１−３は、前記１１−１，１１−２で判定した各パラメータのレンジより、コンフリクトレベルを読み出すステップである。ここでコンフリクトレベルの読みだしを行いステップ１０−４へ進む。なお、コンフリクト方法切り替え判定情報テーブルは、プログラムで自動生成させてもよく、また、システム導入環境における導入アプリケーション（特に常駐アプリケーション）やネットワーク設定によって切り替え可能なようにファイル形式で保存しておく形式をとっても有効なのは言うまでもない。ステップ１０−４は、ステップ１１−３で読み出したコンフリクトレベルを元に処理を切り替えるステップであり、フルコンフリクトと、もしくはハーフコンフリクトと判定された場合には、ステップ１０−５へ進み、それ以外であればステップ１０−６へ進む。

図１２は、ステップ１０−５の詳細である。

ステップ１２−１は、前記ステップ１０−１で求めたメンバプリンタの構成台数をカウンタ（以降ＣＯＵＮＴＥＲ）変数にセットするステップであり、台数をカウンタにセットした後、ステップ１２−２へ進む。ステップ１２−２は、処理開始時間を設定するステップであり、本コンフリクト処理時間を計測するために計測タイマ変数（ＴＩＭＥＲ）に対しゼロを設定するステップである。ステップ１２−３は、前記ＣＯＵＮＴＥＲ変数がゼロになったかどうか判定するステップであり、カウンタ変数が０となった場合、ドライバのコンフリクト情報の獲得を完了したものとしてステップ９−３へ進み、ゼロになっていない場合には、ステップ１２−４へ進む。ステップ１２−４は、メンバプリンタの能力を取得するステップであり、ステップ１０−１で得た、各メンバプリンタの識別ＩＤを使って当該メンバプリンタの能力を読み出すステップである。ステップ１２−５は、フル及びハーフコンフリクト処理を行うステップである。

ここで行うフルコンフリクト処理および、ハーフコンフリクト処理について記載する。

一般的なプリンタドライバの設定項目には、ＯＳの機能を使って設定項目の能力の取得が可能な基本設定項目と呼ばれる部分と、プリンタドライバの開発ベンダで独自に実装し、また、その能力の取得方法が一般には非公開となっている拡張設定項目と呼ばれる部分がある。

図１５は、共通設定項目・拡張設定項目と各設定項目との対応を示す。なお、本特許では共通設定項目は、前記、共通設定領域に存在する項目、拡張設定項目は、前記、拡張設定領域に存在する項目として分類し規定しているが、印刷ジョブ制御システムを運用するＯＳの違いによっては、設定項目の分類が異なる場合や設定可能項目に変更がある場合があるが、本特許のＵＩ制御フローが有効なのはいうまでもない。

図１５について更に詳しく説明すると、共通設定項目に規定される各機能の項目は複数のメンバプリンタドライバのそれぞれの相違に係らず、印刷制御プログラムがＯＳを介して問い合わせることが可能な項目に相当する。一方、拡張設定項目に対応する各機能の項目は、共通設定項目のように印刷制御プログラムがＯＳを介して問い合わせることが必ずしも保証されているとは限らない。該拡張設定項目はそれぞれのプリンタドライバの提供元が独自に問合せの仕組みを規定しているようなものに相当する。グループプリンタドライバにしてみれば、拡張設定項目の問い合わせが利用できないようなプリンタドライバのことを“機能制御不可なドライバ”と呼ぶこともある。次に、機能のコンフリクト処理について具体的に説明すると、機能のコンフリクト処理とは、グループプリンタの対象となる各メンバプリンタドライバのそれぞれからドライバ識別情報や共通設定領域及び拡張設定領域に規定されている各機能の情報の取得や、メンバプリンタドライバから取得された各設定項目の機能の“あり”・“なし”をチェックし、対象となるメンバプリンタドライバ全てに機能がある場合にグループプリンタドライバＵＩでその機能を設定可能項目として扱い、また、１台でも、機能がないものがあればその項目は、設定不可項目として扱うようにする。

図１６の（ａ）中のプリンタドライバＡは、グループプリンタドライバを表しプリンタドライバ、Ｂ，Ｃ，Ｄはグループプリンタドライバを構成するメンバプリンタドライバを表し、表中の、“あり”・“なし”は各メンバプリンタドライバが製本印刷機能、ステイプル印刷機能、パンチ機能をサポートしているかどうかを示したものである。

ここで製本印刷機能に着目すると、ドライバＡ、Ｂは製本印刷機能があるが、ドライバＣにはその機能がないため、グループプリンタドライバＡの製本印刷機能は“なし”となる。

同様に、ステイプル機能は、Ｂ，Ｃ，Ｄ全てのメンバプリンタドライバに機能があるため、グループプリンタドライバＡのステイプルは、“あり”となり、パンチ機能は、Ｂ，Ｃ，Ｄ全てのメンバプリンタドライバに機能がないため、グループプリンタドライバＡのパンチ機能は、“なし”となる。

図１６の（ａ）は、特に共通設定項目と拡張設定項目とを区別無く説明してきたが、実際には、メンバプリンタドライバの構成に機能制御不可なものが含まれる場合には、コンフリクト処理（機能の取得及び整合性計算）の対象となる設定項目を共通設定項目のみにし、機能制御可能なドライバのみからメンバプリンタが構成されている場合にはコンフリクト処理の対象となる設定項目を共通設定項目と拡張設定項目にするような処理が行われる。そのメンバプリンタ種別構成とコンフリクト処理の対象とする項目との関係を示す図を図１６の（ｂ）に示す。また、図のメンバプリンタ種別構成とコンフリクト処理の対象とする項目との関係を図１６の（ｃ）のようにしても良い。

図１６の（ａ）においては、図１５中の拡張設定項目について論理和の計算を行っている様子を示しており、図１６の（ｂ）のメンバプリンタの構成が「機能制御可能なドライバのみ」や、図１６の（ｃ）の「１台でも機能制御可能なものを含む場合」に行われるコンフリクト処理を示すものとなっている。

以上が本特許で行うコンフリクト処理であり、本特許におけるフルコンフリクトとは、前記、機能制御可能なドライバに対して、基本設定項目及び拡張設定項目までのコンフリクトを行うものである。また、メンバプリンタ中に機能制御不可なドライバがあった場合、そのコンフリクト処理としては、前記、図１６の（ｂ）もしくは、１６の（ｃ）に提示したどちらの方法によって行われても有効である。一般に拡張設定項目は、ステイプル、製本といった複雑な機能を持ち、それに伴なう能力取得処理も複雑なため処理時間が増大する。

一方、ハーフコンフリクト処理とは、メンバプリンタの機能制御の可、不可にかかわらず基本設定項目のみのコンフリクト処理を行うものである。

図１３は、ステップ１２−５の詳細である。ステップ１３−１は、基本設定項目に対するコンフリクト処理を行うステップである。このステップは、コンフリクトモードがフルコンフリクト、ハーフコンフリクトどちらのケースに対しても処理を行う。ステップ１３−２は、コンフリクトモードを判定するステップであり、コンフリクトモードがフルコンフリクトの場合には、ステップ１３−３へ進み、またハーフコンフリクトモードの場合には、ステップ１２−６へ進む。ステップ１３−３は、メンバプリンタの能力を判定するステップであり、メンバプリンタの能力が機能制御可能なドライバであった場合には、ステップ１３−４へ進み、ステップ１３−４で拡張設定項目に対するコンフリクト処理を行う。また本ステップが終了した後、ステップ１２−６へ進む。ステップ１２−６は、ＣＯＵＮＴＥＲを一つ減算させるステップである。ステップ１２−７は、ステップ１２−２でゼロを設定したＴＩＭＥＲ変数より処理時間を読み出すステップでありコンフリクト処理のトータル処理時間が、あらかじめ指定されていた処理時間をオーバしていると判断した場合には、ステップ１２−８へ進みゼロコンフリクト処理を行い、その処理を行った後にステップ９−３へ進む。なお、ゼロコンフリクトに対しては、ステップ１０−６へ詳しく述べる。以上が、ステップ１０−４でコンフリクトレベルがフルもしくはハーフコンフリクトとして判断された場合の処理である。一方、ステップ１０−４でＮＯと判断された場合には、ステップ１０−６へ進む。

図１４は、ステップ１０−６の詳細である。本ステップのゼロコンフリクトは、コンフリクト処理を一切行わない処理である。ステップ１４−１は、あらかじめグループプリンタドライバの基本設定項目及び拡張設定項目のデフォルト設定値として、システムに登録されている設定情報を読み込むステップである。このデフォルト設定は、グループプリンタドライバ登録時にユーザによって設定された情報を用いても、また、外部ファイルとして提供されていても、または、プログラムコード中に埋め込まれている情報を使用しても有効なのは言うまでもない。ステップ１４−２は、前記ステップで読み込んだドライバのデフォルト設定値を、コンフリクト情報として登録するステップであり、本ステップを終了した後、ステップ９−３へ進む。

ステップ９−３は、ステップ１０−５及び１０−６で取得したコンフリクト情報を元にドライバＵＩを表示するステップある。前記コンフリクトの結果、機能のないものについては、ＵＩ上で設定が行えないよう、項目をグレーアウト表示、もしくは非表示といったＵＩ制御を行い、機能がある項目についてはＵＩ制御を行わない。

図１７の（ａ）、（ｂ）にＵＩのグレーアウト制御、非表示制御の具体例を示す。設定項目の両面印刷、製本印刷のダイアログボックスが前記ＵＩ制御を施した部分である。また、本ステップでは、ユーザの指定により、たとえば「製本印刷」が指定された時のパンチや、ステイプルの指定といった、機能上ありえない組み合わせが設定できないようＵＩ制御を行い設定項目に矛盾が発生しないようＵＩ表示する。

本発明を適用可能な情報処理システムの構成を説明するブロック図。 本発明の情報処理装置の構成を説明するブロック図。 図２に示したＲＡＭ２０２のメモリマップの一例を示す図。 図２に示したＦＤ２０４のメモリマップの一例を示す図。 図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図。 本発明の情報処理装置のプリント制御モジュール構成を説明するブロック図。 プリントサーバで管理されるジョブ情報のデータ構造の一例を示す図。 汎用印刷ファイルの構造例を示す図。 グループメンバプリンタドライバＵＩ表示基本フローチャート。 コンフリクト切り替え処理フローチャート。 コンフリクト方法切り替え判定情報テーブル参照処理フローチャート。 コンフリクト方法切り替え判定情報テーブル例を示す図。 フル／ハーフコンフリクト処理フローチャート。 コンフリクト処理フローチャート。 ゼロコンフリクト処理フローチャート。 共通設定項目・拡張設定項目と各設定項目との対応を示す図。 （ａ）、（ｂ）、（ｃ）コンフリクト処理の内容を説明するための図。 （ａ）、（ｂ）コンフリクト処理結果を反映させたグループプリンタドライバＵＩの表示例を示す図。

符号の説明

１０１ サーバ
１０２ クライアントコンピュータ
１０３ クライアントコンピュータ
１０４ クライアントコンピュータ
１０５ ネットワークプリンタ
１０６ ネットワーク
２００ ＣＰＵ

Claims (8)

1. 複数のメンバプリンタより構成される仮想プリンタのジョブ制御を行う情報処理装置において、メンバプリンタの構成を調べる調査手段と、本システムが導入されている印刷処理装置の処理能力を読み出す手段と、前記メンバプリンタのそれぞれの機能に基づくコンフリクト処理を行うコンフリクト手段と、前記システムより読み出した構成メンバ台数及び印刷処理装置スペックに基づき、複数あるコンフリクト処理手段の中から、どのコンフリクト手段を適用すべきかを判断する判定手段を持ち、この判定結果によりコンフリクト処理の切り替え手段により切り替え制御を行い、この結果を前記仮想ドライバの設定画面に反映させる表示制御手段を持つことを特徴とする情報処理装置。
2. 前記調査手段は、仮想プリンタに関連付けられたメンバプリンタに対応するメンバプリンタドライバからＡＰＩを用いてプリンタドライバの識別ＩＤを獲得する獲得手段と、前記調査手段は前記獲得手段により獲得されたプリンタドライバの識別ＩＤに基づきメンバプリンタの数を判断することを特徴とする請求項１に記載の情報処理装置。
3. 前記、システムが導入されている印刷処理装置の処理能力読み出し手段は、処理装置のＣＰＵパフォーマンスをクロック周波数として獲得することを特徴とする請求項１に記載の情報処理装置。
4. 前記、複数のメンバプリンタのそれぞれの機能に基づくコンフリクト処理手段は、機能制御可能メンバプリンタに対して、基本設定項目及び拡張設定項目の両者をコンフリクト対象として処理を行う事を特徴とした請求項１に記載の情報処理装置。
5. 前記、複数のメンバプリンタのそれぞれの機能に基づくコンフリクト処理手段は、機能制御可能メンバプリンタに対して、基本設定項目のみをコンフリクト対象として処理を行う事を特徴とした請求項１に記載の情報処理装置。
6. 前記、複数のメンバプリンタのそれぞれの機能に基づくコンフリクト処理手段は、機能のコンフリクトを一切にとらずに仮想ドライバのデフォルト設定をコンフリクト結果として扱う事を特徴とした請求項１に記載の情報処理装置。
7. 前記、コンフリクト手段の適用判定手段は、当該の仮想ドライバを構成するメンバプリンタの台数及び、印刷処理装置の能力を元に、前記、請求項４ないし６いずれかに記載のコンフリクト処理の適用を判定する事を特徴とした請求項１に記載の情報処理装置。
8. 請求項７の適用において請求項４又は５の適用を判断し適用を行った際に、そのコンフリクト処理時間を計測し、処理時間が一定の時間を超えた場合には、請求項６に記載の処理に切り替える事を特徴とした請求項１に記載の情報処理装置。

Images