JP2008107980A

JP2008107980A - クライアントコンピュータ及び印刷システム及び情報処理方法

Info

Publication number: JP2008107980A
Application number: JP2006288811A
Authority: JP
Inventors: Kazuhisa Ebuchi; 和久江渕
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-10-24
Filing date: 2006-10-24
Publication date: 2008-05-08
Anticipated expiration: 2026-10-24
Also published as: EP1936490A3; CN101169708A; US8136110B2; EP1936490A2; JP4298738B2; US20080098396A1

Abstract

【課題】クライアントで例えばレンダリングなどの印刷処理制御を行うオペレーティングシステムを用いる印刷システムにおいても、従来、印刷の完了および印刷処理の進行を柔軟に監視することが困難であった。
【解決手段】本発明は、印刷キュー２０２に存在するジョブの情報を取得し、取得した情報に基づき、印刷キュー２０２からクライアントコンピュータ２０１での印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キュー２０２からサーバーコンピュータ２０３での印刷処理に対応するサーバージョブ２１５が消滅した場合に、印刷キュー２０２の監視を終了することを特徴とする。
【選択図】図３

Description

クライアントからの印刷指示に基づく印刷処理の完了および印刷ジョブの有無など、印刷ジョブの状態を正しく監視する方法および装置に関する。

プリンタの印刷処理過程において、排紙、給紙や印字といった通常ステータス、あるいは紙詰まりやインク切れといったエラーステータスなどの、プリンタの様々な動作状態をもとに印刷処理の進行状況を監視する方法がある。これらの状態監視に加えて、プリンタに対応するスプーラに投入された印刷ジョブのスプール、デスプール、あるいは存否などの状態を元に、印刷処理の進行を監視する方法もある。

このような監視手段を持つ印刷状況監視システムにおいて、印刷処理完了を検出するための最も簡単な方法として、プリンタが印字状態から排紙動作を経てアイドル状態に変化する遷移を見張る手法がある。

但し、ホストコンピュータ内でジョブが未だスプール状態でプリンタに転送されていない場合、印刷ジョブの待ち行列である印刷キューの一時停止などが設定されている場合では、プリンタの動作状態のみを監視する方法では、処理完了の正確な判断が出来ない。

また、ホストコンピュータ内の印刷キューに存在するジョブの存否のみを監視する方法では、プリンタへのデータ転送が完了した時点で印刷完了と見なしてしまう。そのため、その後プリンタ側で印字が続く場合でも、エラーが発生して停止している場合でも、印刷完了と見なしてしまう。

そこで、例えば特許文献１では、プリンタの動作状態および印刷キュー内のジョブの存否を元に判断することで、より精度の高い印刷処理完了の検出を行っている。具体的には、監視対象となる印刷ジョブが印刷キュー内に存在しないと確認され、かつプリンタの動作状態が印刷可能な状態、即ち印刷が行われていないことが確認された場合に印刷完了と判断する手法である。

この他、マイクロソフト社のウィンドウズ（登録商標）２０００やウィンドウズ（登録商標）ＸＰなどのオペレーティングシステムでは、スプールサブシステムにおいて、ランゲージモニタと呼ばれるプロセスが実行されるが、これと連携する手法もある。スプールサブシステムとは、プリントデータを一度スプールしてから出力するシステムのことである。

ランゲージモニタは、ＩＥＥＥ１２８４やＵＳＢ１．１、ＵＳＢ２．０などに準拠した双方向通信によってコンピュータに接続されたプリンタとの間で通信を行いつつ、印刷データをプリンタに転送することが可能である。

ここでランゲージモニタが印字データの全てをプリンタに転送した後、プリンタが最終ページを排紙した事を確認してからスプーラに制御を返すことにより、プリンタから最終ページが確実に出力されてから印刷キュー内のジョブが消滅することになる。また、ユーザにより、印刷ジョブが処理の途中でキャンセルされた場合も印刷キューのジョブが書滅することになる。

これにより、例えばステータスモニタなどは、印刷処理の進行を印刷キューと通信を行うことで監視し、印刷キューからのジョブの消滅をもって、印刷処理が終了したと見なすことが可能である。例えば、マイクロソフト社のウィンドウズ（登録商標）ＸＰなどのオペレーティングシステムから成るプリンタネットワーク環境において説明する。それらプリンタネットワーク環境においては、プリントサーバーコンピュータ（以下、サーバー）とクライアントコンピュータ（以下、クライアント）の印刷システムにおける印刷ジョブの状態などを１つの印刷キューで監視する。そして、ある印刷処理に関する印刷ジョブの状態は、サーバーまたはクライアントでの処理に関わり無く、共有されている印刷キューを監視することでその情報が得られた。つまり、印刷ジョブの状態が常に反映される状態で印刷キューに印刷ジョブ状態が存在することになる。本実施形態においては、印刷キューはサーバーが保持しており、ステータスモニタはその印刷キューを監視している。この際、サーバーの印刷キューにはクライアントで処理中のジョブの情報も反映されているので、クライアントとサーバーで１つの印刷キューを共有していることになる。尚、印刷キューの実態となる記憶領域などに関しては、クライアント、サーバーのどちらにあってもよく、その際には両者内で処理しているジョブの情報は、印刷キューの状態を監視することで得ることができる。

このシステムにおける、サーバーとクライアントの印刷処理とサーバーとクライアントで共有される印刷キュー内のジョブ、およびクライアントにおけるステータスモニタの処理の関係を、図６に示す。尚、図６は図の上部から下部に時間的に遷移していく様子を示している。

クライアント６０１にて、任意のアプリケーションなどから６０４にて印刷ジョブが発行されると、プリンタドライバ内のソフトウェアモジュール、本実施形態においては後述する、ＵＩドライバ１０３からステータスモニタが６０７にて起動される。

ステータスモニタは６０７の起動処理が終了すると、６０８のステータス監視フェーズに遷移し、６１０、６１１、６１２といった、サーバーとクライアントで共有されている印刷キュー６０２との通信を開始する。この通信により、印刷キュー６０２内の印刷ジョブの存否を取得する。

６０４にて発行された印刷ジョブは、６０６にてサーバーへ送信される。

サーバー６０３では、６１６において、クライアント６０１から送信された印刷ジョブの受信を開始する。これと共に印刷キュー６０２には、印刷ジョブ６１５が出現する。

サーバー６０３では、６１７にて、６１６で受信した印刷ジョブを実行する。ここで行われる印刷ジョブの実行とは、印刷ジョブの印刷出力処理に関する一連の処理を示し、主にサーバー上での印刷ジョブのレンダリング処理やプリンタへのデータ転送処理などを示す。レンダリングとは、数値データとして与えられた物体や図形に関する情報を計算によって画像化することである。

本図では、プリンタからの応答を元に、プリンタでの印刷処理が完了するまで印刷ジョブ実行状態６１７が継続する形態を示している。その後、印刷ジョブ実行状態６１７の終了と共に印刷キュー６０２から印刷ジョブ６１５が消滅する。

６０８にて印刷キュー６０２との通信を続けているステータスモニタは、通信６１３にて、印刷キュー６０２からジョブが完全に消滅したことを検知すると、６０９にて終了処理を行い、ステータスモニタとしての動作を終了する。

クライアントから印刷を行った場合、図６からわかるように、その印刷データの実体がクライアント側にあってもサーバー側にあっても、印刷キューにおいて終始一つのジョブとして存在する。従ってステータスモニタは、クライアントにおいてもサーバーにおいても、印刷キューを一つ監視すればよい。
特開２００４−２１６９２号公報

しかしながら、スプールサブシステムを含む印刷システムの構成方法によっては、ネットワーク環境において、従来手法では正常に印刷完了および印刷可能状態を検出できない場合がある。

印刷システムによっては、サーバーに接続されたプリンタに対してクライアントから印刷を実行する際、クライアントで印刷ジョブのレンダリングを行う、クライアントサイドレンダリングという手法がある。

この手法により、大規模ネットワークにおいてもサーバーへの処理負荷集中を回避することができ、またプリンタドライバがレンダリング過程で提供する印刷結果のプレビュー機能などをクライアントで利用することが可能となる。また、クライアントでレンダリングを行うことによりクライアント内で印刷ジョブが完成するため、クライアント内に独立した印刷キューを形成する事が可能となる。しかし１度の印刷処理として、ジョブ管理やジョブ操作を簡潔にするため、サーバーとクライアントとで行われる印刷処理に基づく印刷ジョブの状態を、１つの印刷キューにより監視することが望ましい。

クライアントサイドレンダリングでは、クライアントから印刷処理を開始した場合、印刷キューにその印刷処理に対応するジョブが出現する。しかしながら、サーバーに接続されたプリンタから印刷出力される前に、間もなく印刷キューから印刷ジョブが消滅する。そして僅かな時間を置いた後、再びその印刷処理に対応する印刷ジョブが出現し、サーバーに接続されたプリンタから印刷出力される。この印刷キューからジョブが一時的に消滅してしまうのは、クライアントでレンダリング処理を行うために、クライアントからサーバーへ印刷データの転送などを行うといった、クライアントでもサーバーでも処理を行っていないタイミングが生じるからである。

また、クライアントサイドレンダリングにおける処理動作の詳細については、図７を用いて後述する。

また、最初に出現した印刷ジョブを識別するための識別子であるジョブＩＤと、２回目に出現する印刷ジョブのジョブＩＤは異なる。ここでジョブＩＤは、ドキュメント名、所有者名などのジョブ情報と共に印刷システム乃至オペレーティングシステムから対象ジョブに対して割当てられる。ジョブＩＤは、ジョブ情報などと共に取得することが可能で、これをもとに、印刷キュー内の複数のジョブから対象のジョブを一意に特定することが可能である。また、本発明におけるジョブ情報とは、印刷ジョブの発行元情報、印刷ジョブに対応する処理を行っている装置の情報、印刷設定やエラーステータスに関する情報などを含むものである。

つまり、クライアントサイドレンダリングでは、印刷キューにおいて印刷ジョブが一度消滅し、印刷ジョブを監視できない期間が存在する場合がある。また、クライアントにおいて１つの印刷ジョブに対する、印刷開始時に割当てられた印刷ジョブＩＤと、サーバー転送時に印刷キューから一時消滅し、その後サーバーで割当てられた印刷ジョブＩＤとが異なる。これらにより、印刷キュー内の印刷ジョブの存否とプリンタの動作状態から印刷処理の進行や終了を判断する従来の手法では、破綻をきたすことになる。

例えば、印刷完了と共に印刷キューのステータスモニタによる監視を自動終了する印刷監視システムが、不適切なタイミングで監視を終了することがある。また、印刷完了を見届けてから課金を行う課金システムにおいて、不正なカウントアップが発生することもある。複数のプリンタを用いた分散処理システムにおいて、まだ印刷が進行しているプリンタに対する不適切なジョブの分配が行われる、といった不具合も発生してしまう。

この印刷ジョブが一度消滅する現象を避けるためには、クライアント内の印刷データに対応する印刷ジョブは、印刷キューに反映しない手法がある。しかし、その場合は、印刷開始からサーバーへの印刷データ到達する期間、印刷キュー内のジョブが管理できない。よって、その期間の監視を行えず、印刷処理の開始が検出できない、もしくはユーザが印刷を中止したくともできない、といったデメリットがある。

本発明では、上記の事情を鑑み、クライアントで例えばレンダリングなどの印刷処理制御を行うオペレーティングシステムを用いる印刷システムにおいても、印刷の完了および印刷処理の進行を柔軟に監視する方法を提案することを目的としている。

上記課題を解決するために、本発明は、クライアントコンピュータからの印刷要求に基づくジョブを監視する情報処理装置における情報処理方法であって、印刷キューに存在するジョブの情報を取得し、取得した情報に基づき、前記印刷キューからクライアントコンピュータでの印刷処理に対応するクライアントジョブ消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合に、印刷キューの監視を終了することを特徴とする。

本発明により、クライアントで例えばレンダリングなどの印刷処理制御を行うオペレーティングシステムを用いる印刷システムにおいても、印刷の完了および印刷処理の進行を柔軟に監視することが可能である。

以下、本発明を実施するための最良の形態を、具体例を用いて説明する。また、前記任意の印刷指示に対し最初に出現したあと、プリンタからの印刷を伴う事無く終了するジョブをクライアントジョブ、再び出現し、プリンタからの印刷を伴うジョブをサーバージョブと記して説明する。

（第１の実施形態）
図８は、コンピュータ１１００と画像形成装置１３００とがネットワークなどを介して通信可能に接続されている様子を示す。

まず、コンピュータ１００の構成について説明する。尚、図９に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のコンピュータ１００には一般的な情報処理装置のハードウェア構成を適用できる。後述する、図１におけるクライアント１５１やサーバー１５２は、コンピュータ１１００と同様なハードウェア構成とする。また、後述するプリンタ１０９は、画像形成装置１３００と同様なハードウェア構成とする。

図９において、ＣＰＵ１２０１は、ＲＯＭ１２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク１２１１からＲＡＭ１２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ１２０２は、ＣＰＵ１２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）１２０５は、キーボード１２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）１２０６は、ＣＲＴディスプレイ１２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）１２０７は各種データを記憶するハードディスク（ＨＤ）１２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＰＲＴＣ１２０８は、接続された画像形成装置１３００との間の信号の交換を制御する。ＮＣ１２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

次に、画像形成装置１３００の構成について説明する。図示するように、画像形成装置３００において、３０１は画像形成装置１３００のＣＰＵであり、ＲＯＭ１３０２や、外部メモリ１３０３に記憶された制御プログラムに基づいてシステムバス１３０４に接続される各ブロックを制御する。ＣＰＵ１３０１の処理により生成された画像信号が、印刷部Ｉ／Ｆ１３０５を介して、印刷部（画像形成装置エンジン）３０６に出力情報として出力される。また、ＣＰＵ１３０１は、入力部１３０７を介してホストコンピュータ１１００との通信処理が可能となっており、画像形成装置１３００内の情報等をホストコンピュータ１１００に通知できる。

ＲＯＭ１３０２内のプログラムＲＯＭには、ＣＰＵ１３０１の制御プログラム等を記憶している。ＲＯＭ１３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等を記憶している。ＲＯＭ１３０２内のデータ用ＲＯＭには、ハードディスク等の外部メモリ１３０３がない画像形成装置の場合、ホストコンピュータ１１００上で利用される情報等を記憶している。

ＲＡＭ１３０８は、ＣＰＵ１３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ１３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。

外部メモリ１３０３は、メモリコントローラ（ＭＣ）１３０９によりアクセスを制御される。外部メモリ１３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。

スキャナＩ／Ｆ１３１２は、スキャナ部１３１３から受取った画像データに対して、補正、加工、及び編集を行う。スキャナ部１３１３は、原稿上の画像を露光走査して得られた反射光をＣＣＤに入力することで画像の情報を電気信号に変換する。さらに電気信号をＲ，Ｇ，Ｂ各色からなる輝度信号に変換し、当該輝度信号を画像データとして読み込む。ユーザが操作部１３１１から読み取り開始を指示すると、スキャナ部１３１３に原稿読み取り指示が与えられる。スキャナ部１３１２は、この指示を受けると原稿の読み取り動作を行う。尚、原稿の読み取り方法は原稿フィーダ（不図示）にセットされる自動送り方式の形態であってもよい。また、原稿を不図示のガラス面上に載せ、露光部を移動させることで原稿の走査を行う方法であってもよい。

ここで図９における画像形成装置１３００は、スキャナ部やスキャナインターフェースを備えている。しかしながら、スキャナ部を保持しないコンシューマ向けのインクジェットプリンタなど、クライアントからの印刷データに基づき印刷を行うことが可能な画像形成装置で有るならば、後述する実施形態は適用可能である。

図１は本発明を適用可能な印刷システムのソフトウェアの構成を示すブロック図である。

図１はネットワーク環境下の構成を示す。図１において、１５１はクライアント、１５２はプリンタが接続されたサーバーである。図１におけるクライアント１５１内のモジュールは主にプリンタドライバの構成を示している。具体的には、本実施形態において、プリンタドライバには、ＵＩドライバ１０３、グラフィックスドライバ１０６及びステータスモニタ１１４などが含まれる。尚、プリンタドライバの構成として、更にプリントプロセッサ１０５やなどを含むものであっても、本実施形態には適用可能である。

クライアント１５１において、アプリケーション１０１は文書を作成し、その文書を印刷するためにＵＩドライバ１０３にプリンタシステムの機能を問い合わせる。その後、オペレーティングシステムのグラフィカルデバイスインターフェース（以下ＧＤＩと記す）１０２を含む印刷システムに印刷開始を通知する。ここでＧＤＩ１０２は、アプリケーション１０１から印刷開始の通知を受けると、ＵＩドライバ１０３にアプリケーション１０１による印刷開始の印刷イベントを通知する。

続いてアプリケーション１０１は印刷対象の文書の印刷データをＧＤＩ１０２に供給し印刷処理を続行する。

ＧＤＩ１０２を経由した印刷データは、スプーラ１１２を介してスプールファイル１０４に格納される。

プリントプロセッサ１０５は、スプールファイル１０４から印刷データを読み出し、その印刷データはグラフィクスドライバ１０６を介した後、サーバー１５２へ転送される。

転送された印刷データは、サーバー１５２において、スプーラ１１３を介してスプールファイル１０７として一旦蓄積されたあと、ランゲージモニタ１０８に送られる。ランゲージモニタ１０８は、プリンタ１０９と双方向通信を行いながら、印刷データをプリンタ１０９へと送信する。

またランゲージモニタ１０８は、プリンタから受信した情報や送信する印刷データを元に、現在のプリンタや印刷の状況をステータスモニタ１１０に伝え、ステータスモニタ１１０がその表示を行う。

ステータスモニタ１１０はさらに、クライアントとサーバーが共有している印刷キュー１１１を監視し、印刷ジョブの有無やステータスを取得する。

尚、インクジェットプリンタのようなコンシューマ向けのプリンタにおけるステータスモニタ１１０は、操作性の面からオペレーティングシステム内に常駐する。そして、印刷処理の有無に関わらず複数のプリンタを継続監視するのではなく、特定のプリンタおよびその印刷キューを、印刷処理が発生している間だけ監視する手法が有効である。

このようなステータスモニタは、そのプリンタに対する印刷が開始された時に起動し、前記印刷キューにスタックされる印刷ジョブだけを監視し、前記プリントキューに印刷ジョブが無くなった時点で、ステータスモニタ機能を終了する、というような仕様である。

図７は、従来の印刷キューに対する監視方法における、クライアントサイドレンダリングを行う際のクライアントにおけるステータスモニタの処理について説明した図である。また、図７はサーバーとクライアントの印刷処理とサーバーとクライアントで共有される印刷キュー内のジョブの関係も示している。尚、図７は図の上部から下部に時間的に遷移していく様子を示している。

また、以下記載する実施形態においては、印刷キューに存在するジョブに対してクライアントジョブ、サーバージョブと表現する。クライアントジョブとは、クライアントで発行された印刷ジョブに対して、クライアント内でレンダリングなどの処理を行われている間に印刷キューに出現している印刷ジョブのことを示す。また、サーバージョブとは、クライアントから受信した印刷ジョブに対して、サーバー内で処理を行っている間に印刷キューに出現している印刷ジョブのことを示す。また、印刷キューに存在する印刷ジョブには、ジョブ情報としてクライアントジョブかサーバージョブかを、ステータスモニタが判断するための情報が含まれている。

図７を用いて、従来の印刷キューに対する監視方法での課題を具体的に説明する。

まず、クライアントとサーバーで行われる印刷処理とそれに基づく印刷キュー２５２における印刷ジョブの状態について説明する。

クライアント２５１にて、任意のアプリケーションなどから２５４にて印刷ジョブが発行される。

２５４にて発行された印刷ジョブは、２５５にてプリンタドライバ（本実施形態においては、グラフィックスドライバ１０６）によって主にレンダリングなどの処理が施される。レンダリング処理により、印刷ジョブから印刷データが生成される。クライアントでのレンダリング処理などが行われる間、印刷キュー２０２には、クライアントジョブ２１４が出現する。

生成された印刷データは、２５６にて、サーバーへの送信が行われる。キューに出現していたクライアントジョブ２６４は、この印刷ジョブの送信２５６の開始と同時に消滅する。

一方、サーバー２５３では、２６６において、クライアント２５１から送信された印刷ジョブの受信を開始する。これと共に印刷キュー２５２には、サーバージョブ２６５が出現する。

サーバー２５３では、２６７にて、２６６で受信した印刷ジョブに対する印刷、すなわちプリンタへのデータ転送を行う。

プリンタでの印刷処理が完了するまで印刷ジョブ実行２６７の状態が継続し、この場合、印刷ジョブ実行２６７の状態の終了と共に印刷キュー２５２からサーバージョブ２６５が消滅する。

次に、上記のクライアントサイドレンダリングを用いたシステムにおける、ステータスモニタ１１０における印刷キュー２５２の監視について説明する。

２５４にて印刷ジョブが発行された際に、ＵＩドライバ１０３からステータスモニタが２５７にて起動される。尚、ステータスモニタ１１０を起動する指示を行うのはプリンタドライバの何れかのモジュールであればよく、後述する実施形態においても同様である。

ステータスモニタは２５７の起動処理が終了すると、２５８のステータス監視フェーズに遷移し、サーバーとクライアントで共有されている印刷キュー２５２との通信を開始する。この通信により、印刷キュー２５２内の印刷ジョブの存否を取得する。

ステータス監視２５７の状態であり、印刷キュー２５２との通信を続けているステータスモニタは、印刷キュー監視のための通信２６０、２６１、２６２を行う。

ステータスモニタは、通信２６１によって印刷キュー２５２に印刷ジョブ（クライアントジョブ）が存在するという情報を取得する。そして、通信２６２により印刷ジョブが消滅したという情報を取得し、ステータスモニタは監視を終了する。

しかしながら、図７で示されるように印刷キュー２５２にはその後、サーバージョブが出現している。つまり従来の監視方法では、サーバージョブに対する監視を行えず、ステータスモニタが終了してしまうという課題がある。

上記した、クライアントサイドレンダリングにおける挙動が行われる理由について説明する。

クライアントにおいて印刷が開始されると、クライアント内でレンダリングが行われ、印刷ジョブが生成される。また、サーバーに印刷データが到達すると、サーバーにおいても受信したデータに基づく印刷ジョブが生成されることになる。

しかし前述の通り、印刷システムによってはクライアントとサーバーとで一つの印刷キューを共有するように監視している。よって、クライアントにおける一つの印刷指示に対して、クライアントでレンダリング中の印刷データと、サーバーに到達した印刷データとで別々の印刷ジョブとして出現することになってしまう。

そこでクライアントは、グラフィックスドライバ１０６によってレンダリングされたデータがサーバーに転送され始めると、クライアント内の印刷データに対応する印刷ジョブは、印刷キューに反映しないようにすることが考えられる。尚、レンダリングを行うのはプリンタドライバの何れかのモジュールであればよく、後述する実施形態においても同様である。また、クライアントサイドレンダリングを指示するのは、オペレーションシステムやアプリケーションから指示されてもよく、またプリンタドライバがクライアント乃至はオペレーションシステムの情報に基づき自分で行ってもよい。

これが前述のジョブの一時消滅であり、これにより、一つの印刷指示に対応する印刷ジョブが同一印刷キュー内に２つ存在してしまう事を回避している。

しかしこの制御では、クライアントにおいてサーバーに向けた印刷データの転送が開始されてから、サーバーにおいて印刷データを受信し、印刷ジョブを生成するまでの期間、印刷キュー内に印刷ジョブが存在しないことになる。

本発明の印刷システムにおける、サーバーとクライアントの印刷処理とサーバーとクライアントで共有される印刷キュー内のジョブ、およびクライアントにおけるステータスモニタの処理の関係を、図２（ａ）、（ｂ）、（ｃ）に示す。尚、各図は図の上部から下部に時間的に遷移していく様子を示している。

まず図２（ａ）、（ｂ）、（ｃ）に共通して行われる処理について、説明する。

クライアント２０１にて、任意のアプリケーションなどから２０４にて印刷ジョブが発行されると、ＵＩドライバ１０３からステータスモニタが２０７にて起動される。

ステータスモニタは２０７の起動処理が終了すると、２０８のステータス監視フェーズに遷移し、サーバーとクライアントで共有されている印刷キュー２０２との通信を開始する。この通信により、印刷キュー２０２内の印刷ジョブの存否を取得する。

２０４にて発行された印刷ジョブに基づき、２０５にてグラフィックスドライバ１０６によってレンダリングされ、印刷データが生成される。このレンダリング処理に対応して印刷キュー２０２には、クライアントジョブ２１４が出現する。

印刷ジョブは、２０６にて、サーバーへの送信が行われる。キューに出現していたクライアントジョブ２１４は、この印刷ジョブの送信２０６の開始と同時に消滅する。

一方、サーバー２０３では、２１６において、クライアント２０１から送信された印刷ジョブの受信を開始する。これと共に印刷キュー２０２には、サーバージョブ２１５が出現する。

サーバー２０３では、２１７にて、２１６で受信した印刷ジョブに対する印刷、すなわちプリンタへのデータ転送を行う。

プリンタでの印刷処理が完了するまで印刷ジョブ実行２１７の状態が継続し、この場合、印刷ジョブ実行２１７の状態の終了と共に印刷キュー２０２からサーバージョブ２１５が消滅する。

ステータス監視２１７の状態であり、印刷キュー２０２との通信を続けているステータスモニタは、印刷キュー監視のための通信２１３を行う。この際、印刷キュー２０２からジョブが完全に消滅したことを検知すると、２０９にてステータスモニタの終了処理を行い、ステータスモニタとしての動作を終了する。

以降、図２（ａ）、（ｂ）、（ｃ）のそれぞれの差異について説明を行う。各図において、ステータスモニタ起動後、ステータス監視状態１０８にステータスモニタ１１０が遷移した際に、最初の印刷キュー監視のための通信を行った時の印刷キューの状態に違いがある。この差異の要因は、主にステータスモニタ１１０の起動において、コンピュータの処理状態などにより起動時間が異なることが挙げられる。また、クライアントからの印刷ジョブの処理量やデータ量の大きさにより、印刷ジョブ生成やクライアント・サーバー間のデータ転送時間が異なることも挙げられる。

具体的には、図２（ａ）では、ステータス監視状態１０８にステータスモニタ１１０が遷移した際の、最初の印刷キュー監視の通信２１０において、印刷キュー２０２にはクライアントジョブ２１４が存在する状態を検出している。

図２（ｂ）では、ステータス監視状態１０８にステータスモニタ１１０が遷移した際の、最初の印刷キュー監視の通信２１１において、印刷キュー２０２にはクライアントジョブ２１４もサーバージョブ２１５も存在しない状態を検出している。

図２（ｃ）では、ステータス監視状態１０８にステータスモニタ１１０が遷移した際の、最初の印刷キュー監視の通信２１２において、印刷キュー２０２にはサーバージョブ２１４が存在する状態を検出している。

図２（ｂ）、（ｃ）において、ステータスモニタ１１０はサーバーに対してサーバー転送後のジョブＩＤなどの取得を行う。クライアントサイドレンダリングでは、前述したようにクライアントで発行されたジョブのジョブＩＤとサーバーで発行されたジョブＩＤが異なる。しかしながら、サーバーに予め監視対象のサーバージョブのジョブＩＤを問い合わせることで、ジョブＩＤを用いて監視対象の印刷ジョブを識別する場合でも、的確に印刷ジョブの監視が行える。

各図の印刷キューの状態が異なるといった場合でも、正確にジョブを監視するために行う処理は、後述する図３で示すフローチャートを用いて詳細に説明する。

図３はステータスモニタ１１０が印刷キュー２０２のステータスを監視する際の、クライアント内で行われる処理の制御プログラムに基づく、フローチャートの一例を示す図である。制御プログラムは、ＣＰＵ１２０１で読み込み実行され、主にＲＯＭ１２０３やＨＤ１２１１などに格納されている。

ステップ３０１において、印刷キューのジョブ情報を取得する。

ステップ３０２において、ステップ３０１で取得した情報をもとに、印刷キューにおけるジョブの存否を確認する。ジョブが存在しなかった場合はステップ３０３に遷移し、ジョブが存在した場合はステップ３０４へと遷移する。また、ジョブが存在している場合は、ステータスモニタによる、ジョブ情報およびプリンタステータスの取得、分析、表示を行い、これを対象ジョブが存在する間継続する。ここで、ジョブが存在しない状態というのは、前述した図２（ｂ）などの通信２１１などのタイミングでステータスモニタが監視を始めた場合を示す。

ステップ３０３において、ジョブとしては存在していないがサーバー転送予定のジョブ情報およびジョブＩＤが存在するか否かを確認する。サーバー転送予定のジョブ情報およびジョブＩＤが、存在する場合はステップ３０５に遷移する。また、サーバー転送予定のジョブ情報およびジョブＩＤが、存在しなかった場合は、ステータスモニタの動作を終了し、印刷キューのモニタリングを終了する。

ステップ３０４において、印刷キューに存在するジョブがクライアントジョブであるかどうかを確認する。ステップ３０１で取得したジョブ情報に、クライアントジョブであることを示す情報が含まれていれば、ステップ３０５に遷移する。これは図２（ａ）で示される状態である。また、クライアントジョブであることを示す情報が含まれていなければ、ステップ３０８に遷移する。これは、図２（ｃ）で示される状態である。

ステップ３０５において、ジョブがサーバーに転送された後に割当てられる予定のジョブＩＤを、スプーラ１１３から取得する。

続いてステップ３０６およびステップ３０７にて、印刷キューをポーリング、あるいはシステムからのイベント通知を受けることにより、該予定ジョブＩＤを持つ印刷ジョブが印刷キュー内に出現するのを待つ。該予定ジョブＩＤを持つジョブが出現したことを検出するとステップ３０８に遷移する。

ステップ３０８において、従来のステータスモニタの処理である、ジョブ情報およびプリンタステータスの取得、分析、表示を行い、これを対象ジョブが存在する間継続する。対象ジョブが存在しなくなった場合は、ステップ３０２へと戻り、その他のジョブに対して同様の処理を繰り返す。

本実施形態において、ステータスモニタ１１０が起動し、印刷キューの監視を行っている間は、印刷ジョブのエラーステータスや処理状態などをクライアントのＣＲＴ１２１０などのディスプレイを介して通知するといった構成をとることができる。これにより、ユーザに自身の指示した印刷処理の状態を通知する通知機能、処理の途中での印刷キャンセル指示を行うためのＵＩ表示によるジョブキャンセル機能を提供することができる。尚、本実施形態においては、クライアントサイドレンダリングに起因する印刷キューからの印刷ジョブの一時的な消滅があっても、ユーザの指示した印刷ジョブを終始通知し、上述したジョブキャンセル機能を提供することが可能である。

［第１の実施形態における本発明の効果］
従来、印刷キュー内にジョブが存在することを確認した上でモニタリングを開始したものの、それがクライアントジョブであった場合、間もなく消滅するのに追従して不正にモニタリングを終了してしまっていた。それに対し、本形態を実施したシステムを用いることで、印刷指示に対する印刷ジョブに基づくサーバージョブがクライアントジョブの消滅後、印刷キューに出現することを検知できるため、印刷キューにおけるステータス監視を正しく継続することが可能となる。つまり、クライアントサイドレンダリングなどの制御を行うオペレーティングシステムを用いる印刷システムにおいても、印刷の完了および印刷処理の進行を柔軟に監視することができる。

また、クライアントジョブが消滅し、サーバージョブが出現するまでのジョブ不在の期間にモニタリングを開始した場合においても、サーバージョブが出現することを検知できるため、モニタリングを正しく継続することが可能となる。

更に自明であるが、クライアントジョブが存在する間はサーバージョブＩＤとの関連付けが可能となる。そのため、ユーザに対してクライアントジョブとサーバージョブとをあたかも同一ジョブであるように提示し、印刷キャンセルなどジョブに対する操作を受け付ける事が可能となる。また該関連付けにおいて、各印刷ジョブのドキュメント名やオーナーといった情報が同一であるかを確認し、より誤りの少ない関連付けとすることも可能である。

尚、本形態を実施したシステムは、ネットワークではない、ローカル環境においてもそのまま適用可能である。本実施形態で示したフローを用いた上で、クライアントジョブである事を示す情報やサーバージョブの予定ＩＤが取得されないだけであり、ローカル環境におけるモニタリングにおいても期待通りの動作が可能である。

また、クライアントより複数の印刷要求が連続で行われた場合を考える。図２をもとに具体的に説明すると、ステータスモニタ１１０がクライアントの印刷ジョブ（第１の印刷ジョブ）発行２０４とともに起動２０７する。その後、ステータスモニタが終了２０９する前に、新たにクライアントから印刷ジョブ（第２の印刷ジョブ）が発行された場合を考える。実際の印刷キュー２０２にジョブが現れる順番としては、第１の印刷ジョブに係るクライアントジョブ、第２の印刷ジョブに係るクライアントジョブ、第１の印刷ジョブに係るサーバージョブ、第２の印刷ジョブに係るサーバージョブといった順番などが考えられる。

この際には、ステータスモニタは第２の印刷ジョブの発行時には新たに起動せず、現在、起動しているステータスモニタにより、継続して監視を行う。また、ステータスモニタはクライアントで管理される第２の印刷ジョブの情報が参照可能である。

前述したタイミングにおいて、第１の印刷ジョブに係るサーバージョブが印刷キューから消滅すると、ステップ３０３の処理を行いステータスモニタは第２の印刷ジョブに係るサーバージョブを検出する。これにより、ステータスモニタ１１０はまだ監視すべき印刷ジョブがあるにも関わらず終了してしまう、または、クライアントに複数のステータスモニタが同時に起動してしまうといったことを防ぐことができる。

また、複数クライアントよりサーバーへ印刷要求された場合を考える。この際、第１のクライアントと、第２のクライアントから同じ印刷キューへ印刷ジョブの情報が反映される。ここで第１のクライアントについて考えると、第１のクライアント内のステータスモニタ１１０は、自身のクライアントから発行された印刷ジョブの監視を行う。図２をもとに具体的に説明する。印刷キュー２０２には、第１のクライアントからのクライアントジョブ（１）、第２のクライアントからのクライアントジョブ（２）が出現する。次いで第１のクライアントからのクライアントジョブに基づくサーバージョブ（３）、第２のクライアントからのクライアントジョブに基づくサーバージョブ（４）の順でジョブが出現するといった場合を考える。この際、第１のクライアント内のステータスモニタ１１０は、第１のクライアントからのクライアントジョブに基づくサーバージョブ（３）が消滅した時点で、監視を終了したい。しかし、第２のクライアントからのクライアントジョブに基づくサーバージョブ（４）が処理中か、もしくは印刷キュー２０２にジョブが存在しないので、サーバーにＳ３０３で示したようにサーバーにジョブ情報を問い合わせてジョブがあると判断して、ステータスモニタ１１０は監視を継続してしまう場合がある。よって、ステータスモニタ１１０は、自身のクライアントより発行された印刷ジョブを監視対象として、印刷キューやサーバーなどから取得したジョブ情報が監視対象でなければ、監視を終了するといった実施形態とすることも可能である。

さらに、クライアントジョブやサーバージョブが印刷キューに出現するのを待機している際に、ステータスモニタが印刷キューを監視している場合について考える。この際に、印刷処理がキャンセルされる、もしくはエラー状態に陥るなどして、印刷キューに印刷ジョブが出現しなくなる場合が考えられる。そうした場合も考慮し、一定時間たっても印刷キューに印刷ジョブが出現しない場合は、自動的にステータスモニタを終了させる。

〔第２の実施形態〕
本発明は、第１の実施形態に記載のステータスモニタのように、不特定多数の印刷ジョブを監視するシステムではなく、特定のジョブを監視するシステムに対しても適用可能である。

例えば、有償印刷データを生成するアプリケーションにおける本発明の実施形態の例を、図４を用いて説明する。

ステップ４００において、印刷完了時に課金を行う有償印刷データのジョブ発行を行い、オペレーティングシステムから、発行したジョブに対応するジョブＩＤを取得しておく。

ステップ４０１において、そのジョブＩＤを持つジョブが印刷キューに存在するかを確認し、無ければ終了、あればステップ４０２に遷移する。

ステップ４０２において、存在するジョブがクライアントジョブであるかを確認し、そうであればステップ４０４に遷移する。クライアントジョブではないと判断された場合はステップ４０７に遷移する。

ステップ４０４において、サーバー転送後のサーバージョブＩＤを取得し、たとえ印刷キューから前記クライアントジョブのＩＤを持つジョブが消滅しても、該サーバージョブＩＤを持つジョブが印刷キュー内に出現するのを待つ。

ステップ４０６にてサーバージョブＩＤを持つジョブが出現したことを検出した場合はステップ４０７に遷移する。

ステップ４０７において、該ジョブのモニタリングやプリンタステータスの取得を行う。

ステップ４０８で該ジョブが存在しなくなったらステップ４０９に遷移する。ステップ４０７でモニタリングしていた情報から、プリンタのエラーや途中キャンセルが無かったかを判断し、正常に印刷完了されていれば、ステップ４１０で課金のカウントを行い、終了する。正常完了していなければ、課金カウントをせずに終了する。

［第２の実施形態における本発明の効果］
本形態を実施することで、特定ジョブの完了を監視する場合、クライアントサイドレンダリングなど、前記印刷キューからジョブが一時的に消滅する制御を行うオペレーティングシステムから成るネットワーク環境下でも、適切なジョブモニタリングが可能となる。

また本形態を実施したシステムは、ネットワークではない、ローカル環境においてもそのまま適用可能である。本実施形態で示したフローを用いた上で、クライアントジョブである事を示す情報やサーバージョブの予定ＩＤが取得されないだけであり、ローカル環境におけるモニタリングにおいても期待通りの動作が可能である。

〔第３の実施形態〕
本発明は、第１の実施形態あるいは第２の実施形態に記載のステータスモニタとは異なり、単純に印刷キューにジョブが存在するかどうかのみが必要なシステムに対しても有効である。

例えば、ネットワーク上の複数のプリンタの稼働状況を監視し、稼動していないプリンタに対して優先的に印刷ジョブを振り分けるような分散印刷サービスなどがある。稼動状況を確認する為にそれぞれのプリンタの印刷キューを順に監視し、印刷ジョブが存在しないプリントキューに対して印刷ジョブを送信するような制御に対しても有効である。

この場合の制御フローの例を、図５を用いて説明する。なお図５は、ネットワーク上のプリンタの稼動状況を確認していく過程において、ある一つのプリンタの稼動状況を確認する際のフローである。まずステップ５０１において、印刷キューのジョブ情報を取得する。ここでジョブが存在した場合、ステップ５０４にて該プリンタはビジーであると判断する。勿論、これに加えてジョブのステータスを確認し、保留状態など、プリンタが稼動していないのと等価であれば、ジョブが存在していないと見なす確認ステップを加えてもよいことは言うまでも無い。一方、ステップ５０１にてジョブが存在しなかった場合、ステップ５０２において、ジョブとしては存在していないがサーバー転送予定のジョブ情報およびジョブＩＤが存在するかを確認する。存在すれば、ステップ５０４にて該プリンタはビジーであると判断する。存在しなければ、ステップ５０５にて、該プリンタは印刷可能であると判断する。以上のフローを、ネットワーク上の監視対象プリンタに対して順に実行していく。

［第３の実施形態における本発明の効果］
本形態を実施することにより、印刷キューに印刷処理の未完了なジョブが存在するか否かの情報が必要なシステムにおいても以下の効果を奏する。１つの効果として、印刷キューからジョブが一時的に消滅するような制御を行うオペレーティングシステムから成るネットワーク環境下でも、適切なジョブのモニタリングが可能となる。

また本形態を実施したシステムは、複数のプリンタが接続されたローカル環境においても、あるいは単一のプリンタしか存在しない環境においても、そのまま適用可能である。

本実施形態で示したフローを用いた上で、クライアントジョブである事を示す情報やサーバージョブの予定ＩＤが取得されないだけであり、ローカル環境におけるモニタリングにおいても期待通りの動作が可能である。

本発明は、クライアントサイドレンダリングなどにおいて、ステータスモニタが印刷中であるにも関わらず不正に終了してしまうようなケースが無くなり、精度の高いステータスモニタリングを提供することが可能となる。また印刷が終了したという誤判断がなくなるため、印刷終了と同時に有償データの印刷に対する対価を課す課金システムにおいても、必要不可欠の技術となる。さらには、印刷ジョブが存在しない瞬間を非印刷中だと誤判断するケースにも対処しているため、ネットワーク上の非稼動プリンタに対して優先的に印刷ジョブを振り分ける分散印刷サービスにおいても、効率的な手段となる。

本発明の実施形態の印刷システムについて、ネットワークの構成及びソフトウェア構成を示すブロック図である。（ａ）は本発明の実施形態のサーバーおよびクライアントの処理と印刷キューとステータスモニタの関係を示し、ステータスモニタ１１０が最初の通信によりクライアントジョブの存在を検出した場合の説明図、（ｂ）は本発明の実施形態のサーバーおよびクライアントの処理と印刷キューとステータスモニタの関係を示し、ステータスモニタ１１０がサーバージョブ出現前の印刷キューにジョブが無い状態を検出した場合の説明図、（ｃ）は本発明の実施形態のサーバーおよびクライアントの処理と印刷キューとステータスモニタの関係を示し、ステータスモニタ１１０が最初の通信によりサーバージョブの存在を検出した場合の説明図である。第１の実施形態におけるステータスモニタ１１０が印刷キュー２０２のステータスを監視する際の、クライアント内で行われる処理の制御プログラムに基づく、フローチャートの一例を示す図である。第２の実施形態におけるステータスモニタ１１０が印刷キュー２０２のステータスを監視する際の、クライアント内で行われる処理の制御プログラムに基づく、フローチャートの一例を示す図である。第３の実施形態におけるステータスモニタ１１０が印刷キュー２０２のステータスを監視する際の、クライアント内で行われる処理の制御プログラムに基づく、フローチャートの一例を示す図である。クライアントサイドレンダリングを行わない印刷システムにおける、従来のサーバーおよびクライアントの処理と印刷キューとステータスモニタの関係を示す説明図である。クライアントサイドレンダリングを行う印刷システムに従来のステータスモニタによる監視方法を適用した際の、サーバーおよびクライアントの処理と印刷キューとステータスモニタの関係を示す説明図である。本発明に適用可能なパーソナルコンピュータ及び画像形成装置のハードウェア構成を示した図である。

符号の説明

１０９プリンタ
１１０ステータスモニタ
１１１印刷キュー
１５１クライアントコンピュータ
１５２サーバーコンピュータ

Claims

印刷ジョブのレンダリング処理を行うレンダリング手段と、
前記レンダリング手段によりレンダリング処理された印刷ジョブを管理する印刷キューからクライアントコンピュータでのレンダリング処理を含む印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合、印刷キューの監視を終了する監視手段とを備えることを特徴とするクライアントコンピュータ。
前記サーバーコンピュータが画像形成装置に対して指示した印刷出力処理の終了に基づき、前記印刷キューから前記サーバージョブが消滅することを特徴とする請求項１に記載のクライアントコンピュータ。
前記サーバージョブに対応するサーバージョブ情報を、当該サーバーコンピュータから取得するサーバージョブ情報取得手段を備えることを特徴とする請求項１乃至請求項２の何れか１項に記載のクライアントコンピュータ。
前記監視手段は、前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得手段によりサーバージョブ情報を取得した場合、印刷キューの監視を継続することを特徴とする請求項３に記載のクライアントコンピュータ。
前記クライアントジョブに対応するクライアントジョブ情報を取得するクライアントジョブ情報取得手段を備え、
前記監視手段は、前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得手段によりサーバージョブ情報を取得した際に、当該サーバージョブ情報が、前記クライアントジョブ情報取得手段により取得したクライアントジョブ情報により、前記監視手段の監視対象ではないクライアントコンピュータのクライアントジョブであったと判断した場合、前記印刷キューの監視を終了することを特徴とする請求項３記載のクライアントコンピュータ。
前記監視手段により監視した、前記印刷キューの状態をユーザに対して通知する通知手段を備えることを特徴とする請求項１乃至請求項５の何れか１項に記載のクライアントコンピュータ。
クライアントコンピュータからの印刷要求に対して、サーバーコンピュータを介して印刷を行う印刷システムにおいて、
レンダリング処理された印刷ジョブを管理する印刷キューと、
前記印刷キューからクライアントコンピュータでの印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合、印刷キューの監視を終了する監視手段とを備えることを特徴とする印刷システム。
クライアントコンピュータからの印刷要求に基づくジョブを監視する情報処理装置における情報処理方法であって、
印刷キューに存在するジョブの情報を取得する取得ステップと、
前記取得ステップにより取得した情報に基づき、前記印刷キューからクライアントコンピュータでの印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合に、印刷キューの監視を終了する監視ステップとを備えることを特徴とする情報処理方法。
前記サーバージョブに対応するサーバージョブ情報を、当該サーバーコンピュータから取得するサーバージョブ情報取得ステップを備えることを特徴とする請求項８に記載の情報処理方法。
前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得ステップにおいてサーバージョブ情報が取得された場合、印刷キューの監視を継続することを特徴とする請求項９に記載の情報処理方法。
前記クライアントジョブに対応するクライアントジョブ情報を取得するクライアントジョブ情報取得ステップを備え、
前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得手段においてサーバージョブ情報が取得された際に、当該サーバージョブ情報が、前記クライアントジョブ情報取得ステップにおいて取得されたクライアントジョブ情報により、前記監視手段の監視対象ではないクライアントコンピュータのクライアントジョブであったと判断した場合、前記印刷キューの監視を終了することを特徴とする請求項９記載の情報処理方法。
前記印刷キューの状態をユーザに対して通知する通知ステップを備えることを特徴とする請求項８乃至請求項１１の何れか１項に記載の情報処理方法。
クライアントコンピュータからの印刷要求に基づくジョブを監視する情報処理装置における情報処理ステップをコンピュータにより実現させるためのコンピュータ読み取り可能なプログラムであって、
印刷キューに存在するジョブの情報を取得する取得ステップと、
前記取得手段により取得した情報に基づき、前記印刷キューからクライアントコンピュータでの印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合、印刷キューの監視を終了する監視ステップとをコンピュータにより実現させるためのコンピュータ読み取り可能なプログラム。
更に、前記サーバージョブに対応するサーバージョブ情報を、当該サーバーコンピュータから取得するサーバージョブ情報取得ステップをコンピュータにより実現させるための請求項１３に記載のコンピュータ読み取り可能なプログラム。
前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得ステップにおいてサーバージョブ情報が取得された場合、印刷キューの監視を継続することを特徴とする請求項１４に記載のコンピュータ読み取り可能なプログラム。
更に、前記クライアントジョブに対応するクライアントジョブ情報を取得するクライアントジョブ情報取得ステップをコンピュータにより実現させ、
前記印刷キューに印刷ジョブが存在せず、かつ前記サーバージョブ情報取得手段においてサーバージョブ情報が取得された際に、当該サーバージョブ情報が、前記クライアントジョブ情報取得ステップにおいて取得されたクライアントジョブ情報により、前記監視手段の監視対象ではないクライアントコンピュータのクライアントジョブであったと判断した場合、前記印刷キューの監視を終了することを特徴とする請求項１４記載のコンピュータ読み取り可能なプログラム。
更に前記印刷キューの状態をユーザに対して通知する通知ステップをコンピュータにより実現させるための請求項１３乃至請求項１６の何れか１項に記載のコンピュータ読み取り可能なプログラム。
クライアントコンピュータからの印刷要求に基づくジョブを監視する情報処理装置における情報処理ステップをコンピュータにより実現させるためのコンピュータ読み取り可能なプログラムを格納した記憶媒体であって、
印刷キューに存在するジョブの情報を取得する取得ステップと、
前記取得手段により取得した情報に基づき、前記印刷キューからクライアントコンピュータでの印刷処理に対応するクライアントジョブが消滅しても印刷キューの監視を継続し、前記印刷キューからサーバーコンピュータでの印刷処理に対応するサーバージョブが消滅した場合、印刷キューの監視を終了する監視ステップとをコンピュータにより実現させるためのコンピュータ読み取り可能なプログラムを格納した記憶媒体。