JP5728246B2 - 印刷システム、印刷装置およびその制御方法、並びにプログラム - Google Patents

Description

本発明はネットワークに接続された印刷装置のタイムアウト処理を制御する印刷システムに関する。

近年、米国のマイクロソフト社のＷｉｎｄｏｗｓ ７（登録商標）では、ネットワークに接続された印刷装置にて印刷を行う方式として、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ ｏｎ Ｄｅｖｉｃｅ）が採用されている。ＷＳＤについては、非特許文献１上で詳細な情報が公開されている。従来、ネットワークへ接続された印刷装置にて印刷を行う場合、印刷装置の占有を避けるために、印刷ジョブを送信した情報処理装置から一定期間にわたって印刷装置へアクセスがなければタイムアウト処理を行い、印刷装置の占有を解除する技術がある。

また、印刷装置は、印刷開始要求を解析しエラーがなければポートを作成し、一定期間、ポートにアクセスなければポートをクローズすると言う処理が開示されている（特許文献１参照）。

また、手指し印刷のようにプリンタドライバが手指し印刷のガイドダイアログを表示するためなどに意図的に印刷装置への印刷データの送信を止めている場合も考えられる。このような場合においても、定期的に印刷装置にステータス情報を問い合わせることで、タイムアウトエラーが発生しないようにする技術も存在する。

特開２００４−３４１７３４号公報

Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ、"Ｗｉｎｄｏｗｓ Ｈａｒｄｗａｒｅ Ｄｅｖｅｌｏｐｅｒ Ｃｅｎｔｒａｌ"、［ｏｎｌｉｎｅ］、［平成２２年１０月１１日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｗｈｄｃ／ｃｏｎｎｅｃｔ／ｒａｌｌｙ／ｒａｌｌｙｗｓｄ．ｍｓｐｘ）

一般的なＯＳの印刷サポート機能として、情報処理装置と接続されているネットワークケーブルが抜き差しされた場合、現在印刷中の印刷ジョブを一度削除し、新たに同じ内容のジョブを再印刷する方法がある。例えば、ジョブ１を印刷中にネットワークケーブルの抜き差しが発生すると、印刷サポート機能は、プリントキューに保持されているジョブ１を削除し、新たに同じ内容のジョブをジョブ２として生成し、印刷する。

ここで、印刷装置は、情報処理装置と接続されているネットワークケーブルの抜き差しを検知できないためジョブ１を処理中のままとなる。情報処理装置のポートモニタは印刷装置に対してジョブ２の印刷開始要求を行うが、印刷装置はジョブ１を処理中の為、エラー応答をする。一方、情報処理装置のランゲージモニタは印刷装置に対してステータス取得要求を行う。印刷装置は情報処理装置からのアクセスがある為、タイムアウト処理のカウンタをリセットする。これにより、タイムアウトが発生せず、印刷装置はジョブ１を処理中のままとなり、ジョブ２の処理を一定期間、開始できないという課題があった。

上述のような課題を解決するため、本発明は以下の構成を有する。すなわち、ネットワークを介して接続された、情報処理装置と印刷装置とを有する印刷システムであって、前記情報処理装置は、前記印刷装置にジョブに対する印刷開始要求を送信する印刷要求送信手段と、前記印刷装置が処理を開始したジョブに割り当てた識別子を取得し、記憶する記憶手段と、識別子を含むステータス取得要求を前記印刷装置へ送信するステータス取得要求送信手段とを有し、前記印刷装置は、前記情報処理装置から前記印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当手段と、計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理手段と、前記情報処理装置から前記ステータス取得要求を受信し、当該ステータス取得要求に含まれる識別子を取得する第一の取得手段と、処理中のジョブに割り当てた識別子を取得する第二の取得手段と、前記第一の取得手段にて取得した識別子と前記第二の取得手段にて取得した識別子とを比較する比較手段とを有し、前記タイムアウト処理手段は、前記比較手段の比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とする。

また、本発明に係る別の構成として、ネットワークを介して接続された、情報処理装置と印刷装置とを有する印刷システムにおける印刷装置であって、前記情報処理装置から印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当手段と、計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理手段と、前記情報処理装置からステータス取得要求を受信し、当該ステータス取得要求に含まれる識別子を取得する第一の取得手段と、処理中のジョブに割り当てた識別子を取得する第二の取得手段と、前記第一の取得手段にて取得した識別子と前記第二の取得手段にて取得した識別子とを比較する比較手段とを有し、前記タイムアウト処理手段は、前記比較手段の比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とする。

印刷装置は情報処理装置からのステータス要求をジョブ単位で区別でき、自身が処理中でないジョブに対するステータス要求により不正にタイムアウト処理のカウンタをリセットしてしまうことを回避できる。

情報処理装置と印刷装置とを有する印刷システムの構成を示すブロック図。 第一実施形態に係る印刷システムの構成を示すブロック図。 印刷処理の流れを示す図。 ＪｏｂＩＤとＪｏｂＳｔａｔｅを示す図。 印刷装置の処理を示すフローチャート。 ランゲージモニタの処理を示すフローチャート。 ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅの構成例を示す図。 ランゲージモニタの処理を示すフローチャート。 印刷装置の処理を示すフローチャート。 印刷装置のタイムアウト処理を示すフローチャート。 ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔ及びＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅの構成例を示す図。 ＬＡＮケーブルの接続状態に応じた印刷装置とプリントキューの状態を表す図。 第二実施形態に係る印刷システムの構成を示すブロック図。 ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの構成例を示す図。

以下、添付図面を参照して本発明に係る実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜第一実施形態＞
［システム構成］
図１乃至図１２を参照し、本発明に係る第一実施形態を説明する。図１において、情報処理装置１００は、一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）の構成を有する。情報処理装置１００は、ＲＡＭ１０１、外部記憶装置１０２、キーボード１０３、ＣＰＵ１０４、ネットワークボード１０５、表示用ディスプレイ１０６、およびインターフェース（Ｉ／Ｆ）部１０８を有する。

ＲＡＭ１０１は、外部記憶装置１０２に保存される各種プログラムがワークメモリとして使用する。外部記憶装置１０２にはアプリケーションプログラム群とＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、プリンタドライバやその他各種のデータが格納されている。キーボード１０３は、ユーザによるデータ入力あるいは動作指示に使用される。表示用ディスプレイ１０６は、データ表示や状態の通知に使用される。ネットワークボード１０５はネットワーク１０９を介し接続された他の機器との通信を行う。インターフェース部１０８は、印刷装置１１０との接続を制御する。

印刷装置１１０は、インターフェース（Ｉ／Ｆ）部１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＣＰＵ１１４、エンジン１１５を有する。インターフェース部１１１はネットワーク１０９に接続され、同様にネットワークに接続された他の機器との通信を行う。ＲＯＭ１１３には、制御プログラムなどが格納されている。ＣＰＵ１１４は、ＲＯＭ１１３に格納された制御プログラムに従って印刷装置１１０を制御する。ＲＡＭ１１２は、ＣＰＵ１１４のワークメモリとして使用され、受信したデータを一時的に保存する受信バッファとしても用いられる。エンジン１１５はＲＡＭ１１２に保存されたデータを印刷する。本実施形態における印刷装置１１０のエンジン１１５はインクジェット方式を例に説明を行うが、これに限定されることなく、例えば、電子写真方式、熱転写方式などのエンジンを適用することもできる。

図２は、図１に示した情報処理装置１００に適用可能な印刷システムを表すブロック図である。アプリケーション２０１はＯＳの印刷サポート機能２０２を介して、ユーザインターフェースモジュール２０３から印刷設定情報を取得し、印刷データを作成する。アプリケーション２０１が作成した印刷データはＯＳの印刷サポート機能２０２を介してスプールデータ２０７としてスプーラ２０５のプリントキュー２０６に印刷ジョブとして蓄えられる。印刷ジョブはスプーラ２０５を経由してランゲージモニタ２０８に渡される。

ランゲージモニタ２０８は、印刷ジョブをポートモニタ２０９に出力する。ポートモニタ２０９はランゲージモニタ２０８から渡された印刷ジョブを、ネットワーク１０９を経由して印刷装置１１０に送信する。本実施形態ではポートモニタ２０９としてＷＳＤ印刷用のポートモニタを想定しているが、これに限定されることなく本発明が適用可能な構成であれば、様々なポートモニタを用いることができる。

［ＷＳＤ印刷処理］
図３はＷＳＤ印刷における印刷処理の流れを示したものである。処理３０１でスプーラ２０５はランゲージモニタ２０８の関数であるＳｔａｒｔＤｏｃＰｏｒｔ（）を呼び出し、印刷処理を開始する。ランゲージモニタ２０８は、ポートモニタ２０９の関数であるＳｔａｒｔＤｏｃＰｏｒｔ（）を呼び出す。処理３０２でスプーラ２０５は、ランゲージモニタ２０８の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出し、印刷データの送信を開始する。処理３０３でランゲージモニタ２０８は、ポートモニタ２０９の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出す。処理３０４でポートモニタ２０９は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔ（印刷開始要求）を印刷装置１１０に送信する。これにより、印刷要求送信手段を実現する。

処理３０５で印刷装置１１０は、ＪｏｂＩＤ３０６と共にＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅ（印刷開始応答）をポートモニタ２０９に返却する。ここで用いられるＪｏｂＩＤ３０６は、印刷装置１１０が印刷ジョブを管理する為に、印刷ジョブに付加する一意に識別するためのＩＤ（識別子）である。処理３０７でポートモニタ２０９はＳｅｎｄＤｏｃｕｍｅｎｔ Ｒｅｑｕｅｓｔ（文書送信要求）を印刷装置１１０に送信後、ＷｒｉｔｅＰｏｒｔ（）の処理を完了する。

処理３０８にてランゲージモニタ２０８は、ポートモニタ２０９のＷｒｉｔｅＰｏｒｔ（）による処理完了後、一定期間内にＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔを印刷装置１１０に送信する。処理３０９で印刷装置１１０は、ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅをランゲージモニタ２０８に返却する。ＧｅｔＡｃｔｉｖｅＪｏｂｓ ＲｅｓｐｏｎｓｅはＪｏｂＩＤとＪｏｂＳｔａｔｅを有する情報（テーブル３１０）を含んでいる。これにより、ジョブ情報取得手段を実現する。なお、本実施形態では、一定期間（Ｘ秒）の例として、４秒以内とする。なお、この時間はこの値に限定されるものではなく、他の設定値を用いてもよい。また、管理者が必要に応じて値を変更可能なように構成してもよい。

処理３１１でスプーラ２０５は、印刷データを印刷装置１１０に送信する為にランゲージモニタ２０８の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出す。続いて、ランゲージモニタ２０８はポートモニタ２０９の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出す。そして、ポートモニタ２０９は印刷データを印刷装置１１０に送信する。

印刷データの送信を行いつつ、処理３１２でランゲージモニタ２０８はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔ（ステータス取得要求）を印刷装置１１０に送信する。ここでのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ ＲｅｑｕｅｓｔはＪｏｂＩＤ３０６を含んでいる。これにより、ステータス取得要求送信手段を実現する。処理３１３で印刷装置１１０は、ランゲージモニタ２０８に対して、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅ（ステータス取得応答）を返却する。本実施形態におけるシステムは、上述した処理を、印刷データを全て送信するまで繰り返す（処理３１４、３１５、３１６）。

［ＪｏｂＩＤおよびＪｏｂＳｔａｔｅ］
図４を用いて、上述した処理の中で用いられるジョブ情報としてのＪｏｂＩＤとＪｏｂＳｔａｔｅについて説明する。印刷装置１１０は、図４（ａ）、（ｂ）、（ｃ）に示したようなテーブルを用いて現在処理しているジョブの状態を管理する。「ＪｏｂＩＤ」は、現在処理しているジョブを一意に識別するためのＩＤ（識別子）であり、「ＪｏｂＳｔａｔｅ」はジョブの状態を表す。各ジョブは、ＪｏｂＩＤおよびＪｏｂＳｔａｔｅを有する。印刷装置１１０が情報処理装置１００からジョブを受信した直後は図４（ａ）に示すようにジョブの状態は“Ｓｔａｒｔｅｄ”となっている。印刷装置１１０がジョブを処理し、印刷している時は図４（ｂ）に示すようにジョブの状態は“Ｐｒｉｎｔｉｎｇ”となっている。印刷装置１１０がジョブの印刷を完了すると図４（ｃ）に示すようにジョブの状態は“Ｃｏｍｐｌｅｔｅｄ”となる。なお、本実施形態において上記三種類のジョブの状態を示したが、これ以外の状態を定義しても構わない。

［Ｒｅｑｕｅｓｔ受信時の動作］
図５を用いて、印刷装置１１０がＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信した際（図３の処理３０４）及び、ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔを受信した際（図３の処理３０８）の動作を詳細に説明する。

印刷装置１１０はポートモニタ２０９からＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信すると（Ｓ５０１）、自身がジョブ処理中かどうかを判定する（Ｓ５０２）。ジョブ処理中でない場合（Ｓ５０２にてＮＯ）、印刷装置１１０は受信した要求に対応する新たなＪｏｂＩＤを割り当てる（Ｓ５０３）。これにより、割当手段を実現する。そして、ＪｏｂＳｔａｔｅに“Ｓｔａｒｔｅｄ”を設定し、その状態を一定時間（Ｘ秒）、保持する（Ｓ５０３）。ここでの一定時間は、予め定義されているものとする。また、本実施形態では、“Ｓｔａｒｔｅｄ”の状態を特定の状態として、一定時間、維持させている。このとき、ＪｏｂＩＤとＪｏｂＳｔａｔｅはテーブル３１０のような状態になる。印刷装置１１０は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅに“成功”を示す情報をセットする（Ｓ５０５）。そして、印刷装置１１０は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅをポートモニタ２０９に送信する（Ｓ５０７）。そして、本処理を終了する。

印刷装置１１０がジョブ処理中の場合（Ｓ５０２にてＹＥＳ）、印刷装置１１０は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅに“エラー”を示す情報をセットする（Ｓ５０６）。そして、印刷装置１１０は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅをポートモニタ２０９に送信する（Ｓ５０７）。そして、本処理を終了する。

印刷装置１１０は、ランゲージモニタ２０８からＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔを受信する（Ｓ５１１）。その後、図５に示すテーブル３１０のＪｏｂＩＤとＪｏｂＳｔａｔｅをＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅに含めてランゲージモニタ２０８に送信する（Ｓ５１２）。そして、本処理を終了する。

［ＷｒｉｔｅＰｏｒｔ（）における処理］
図６は図３の処理３０２で、スプーラ２０５からランゲージモニタ２０８の関数であるＷｒｉｔｅＰｏｒｔ（）が呼ばれた際のランゲージモニタ２０８の処理を示すフローチャートである。

スプーラ２０５がランゲージモニタ２０８のＷｒｉｔｅＰｏｒｔ（）を呼び出すと、ランゲージモニタ２０８はポートモニタ２０９の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出す（Ｓ６０１）。ポートモニタ２０９のＷｒｉｔｅＰｏｒｔ（）による処理が成功すると（Ｓ６０２にてＹＥＳ）、ランゲージモニタ２０８は一定時間（Ｘ秒）以内にＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔを印刷装置１１０に送信する（Ｓ６０３）。ここでの一定時間は、予め定義されているものとする。

そして、ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔの送信に成功し、印刷装置１１０からＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅが返ってきたら（Ｓ６０５にてＹＥＳ）、ランゲージモニタ２０８は、ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅに含まれるＪｏｂＳｔａｔｅの値が“Ｓｔａｒｔｅｄ”になっているかどうか判定を行う（Ｓ６０６）。これにより、ジョブの状態判定を行う。ＪｏｂＳｔａｔｅの値が“Ｓｔａｒｔｅｄ”になっている場合は（Ｓ６０６にてＹＥＳ）、ランゲージモニタ２０８はそのＪｏｂＩＤを記憶部であるＲＡＭ１０１等に記憶する（Ｓ６０７）。そして、ランゲージモニタ２０８は、スプーラ２０５に成功を通知する（Ｓ６０８）。そして、本処理を終了する。

なお、図６には図示していないが、Ｓ６０７にて記憶したＪｏｂＩＤは、印刷処理終了時にランゲージモニタ２０８が削除する。

ポートモニタ２０９のＷｒｉｔｅＰｏｒｔ（）が失敗した場合は（Ｓ６０２にてＮＯ）、ランゲージモニタ２０８は、スプーラ２０５に失敗を通知する（Ｓ６０４）。そして、本処理を終了する。ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔに失敗した場合（Ｓ６０５にてＮＯ）やＪｏｂＳｔａｔｅの値が“Ｓｔａｒｔｅｄ”でない場合（Ｓ６０６にてＮＯ）は、ポートモニタ２０９のＷｒｔｅＰｏｒｔ（）は成功している。よって、その場合には、ランゲージモニタ２０８は、その旨をスプーラ２０５に成功を通知する（Ｓ６０８）。そして、本処理を終了する。

［ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅの構成］
次に図７を用いて、図３の３０９にて印刷装置１１０が返却するＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅについて説明する。ＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｓｐｏｎｓｅは、情報処理装置１００から送信されるＧｅｔＡｃｔｉｖｅＪｏｂｓ Ｒｅｑｕｅｓｔに対する印刷装置１１０の応答であり、印刷装置１１０が処理しているジョブの状態を表している。ＧｅｔＡｃｔｉｖｅＪｏｂｓ ＲｅｓｐｏｎｓｅはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）フォーマットで記述されている。図７にて示したＸＭＬデータに含まれる記述７００では、印刷装置１１０が処理中のジョブのＩＤ（ＪｏｂＩＤタグ）は“１”であり、状態（ＪｏｂＳｔａｔｅタグ）は“Ｓｔａｒｔｅｄ”であることが分かる。また、Ｊｏｂの名称（ＪｏｂＮａｍｅ）は“Ｊｏｂ １”と定義されている。

図５のＳ５０４で説明したように印刷装置１１０はＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信後、Ｘ秒間はジョブの状態（ＪｏｂＳｔａｔｅ）を“Ｓｔａｒｔｅｄ”にする。このとき、ＪｏｂＩＤが“１”のジョブはまだ処理が開始されたばかりであることがわかる。

［ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの送受信］
図８は、図３に示す処理３１２および処理３１５でランゲージモニタ２０８が印刷装置１１０に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを送信する時のランゲージモニタ２０８の処理を示すフローチャートである。

ランゲージモニタ２０８は処理を開始すると、保存しているＪｏｂＩＤがあるか否かを確認する（Ｓ８０１）。保存しているＪｏｂＩＤがある場合は（Ｓ８０１にてＹＥＳ）、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ ＲｅｑｕｅｓｔのＸＭＬデータに、保存しているＪｏｂＩＤをセットする（Ｓ８０２）。そして、ランゲージモニタ２０８は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを印刷装置１１０へ送信する（Ｓ８０４）。そして、本処理を終了する。

保存しているＪｏｂＩＤが無い場合（Ｓ８０１にてＮＯ）、ランゲージモニタ２０８は、ＪｏｂＩＤとしてデフォルト値を、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ ＲｅｑｕｅｓｔのＸＭＬにセットする（Ｓ８０３）。そして、ランゲージモニタ２０８は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを送信する（Ｓ８０４）。そして、本処理を終了する。

図９は、図３に示す処理３１２及び処理３１５で印刷装置１１０がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信した時の印刷装置１１０の処理を示すフローチャートである。

印刷装置１１０は処理を開始すると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信する（Ｓ９０１）。そして、印刷装置１１０は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔに含まれるＪｏｂＩＤを取得する（Ｓ９０２）。これにより、第一の取得手段を実現する。次に印刷装置１１０は、現在処理中のジョブのＪｏｂＩＤを取得する（Ｓ９０３）。これにより、第二の取得手段を実現する。

印刷装置１１０は、Ｓ９０２およびＳ９０３にて取得した２つのＪｏｂＩＤを比較する（Ｓ９０４）。そして、それらのＪｏｂＩＤが一致した場合は（Ｓ９０４にてＹＥＳ）、印刷装置１１０は、タイムアウト処理用カウンタ（以下、カウンタ）の値をリセットする（Ｓ９０５）。そして、印刷装置１１０は、ランゲージモニタ２０８へＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅを送信する（Ｓ９０６）。そして、本処理を終了する。

ＪｏｂＩＤが一致しない場合は（Ｓ９０４にてＮＯ）、印刷装置１１０は、カウンタの値をリセットせずにランゲージモニタ２０８へＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅを送信する（Ｓ９０６）。そして、本処理を終了する。

［タイムアウト処理］
ここでの「タイムアウト処理」とは、印刷装置１１０の占有を避けるために、印刷ジョブを送信した情報処理装置１００から一定期間にわたって印刷装置１１０へアクセスがなければ、印刷ジョブの処理を中止し、印刷装置１１０の占有を解除することを意味する。図１０を用いてタイムアウト処理について説明する。

印刷装置１１０は、情報処理装置１００からアクセスがあったか否かを確認する（Ｓ１００１）。ここでいうアクセスの有無は、情報処理装置１００から印刷装置１１０に印刷データが送られてきた場合や、図９のＳ９０４でＪｏｂＩＤが一致した場合などが該当する。しかし、他の条件を用いて、アクセスの有無を判定しても構わない。アクセスがあった場合は（Ｓ１００１にてＹＥＳ）、印刷装置１１０はカウンタの値をリセット（初期化）する（Ｓ１００２）。そして、本処理を終了する。

アクセスが無かった場合は（Ｓ１００１にてＮＯ）、印刷装置１１０は、カウンタの値を１つ増やすことでカウントする（Ｓ１００３）。続いて、印刷装置１１０は、カウンタの値が閾値を超えているかどうか確認する（Ｓ１００４）。ここで用いられる閾値は予め定義されているものとし、管理者などによって適宜変更できるように構成されても構わない。カウンタの値が閾値を超えている場合は（Ｓ１００４にてＹＥＳ）、印刷装置１１０は印刷ジョブの処理を中止する（Ｓ１００５）。そして、本処理を終了する。

カウンタの値が閾値を超えていない場合は（Ｓ１００４にてＮＯ）、そのまま本処理を終了する。印刷装置１１０は、上記処理を印刷ジョブが終了するまで定期的に行う。

なお、上記タイムアウト処理において、アクセスが無かった場合の経過を計測する計時部としてカウンタを用いたが、他の手段（例えばタイマー等）を用いて、タイムアウトを管理しても構わない。

［ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｔｎｓの構成例］
図１１を用いて、ランゲージモニタ２０８が送信するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔ（図３の処理３１２、３１５）及び、印刷装置１１０が送信するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅ（図３の処理３１３、３１６）について説明する。

ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔはランゲージモニタ２０８が印刷装置１１０に対して、印刷装置１１０の状態の取得及び、意図的に印刷装置１１０への印刷データの送信を一時的に停止している際に印刷装置１１０のタイムアウト処理を防止する為に送信する。ランゲージモニタ２０８が意図的に印刷装置１１０への印刷データの送信を一時的に停止する例としては、手指し印刷において手指し印刷のガイドダイアログを表示する場合などが挙げられる。

印刷装置１１０は受信したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔ対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅで応答する。図１１（ａ）、（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの構成例を示している。ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ ＲｅｑｕｅｓｔはＸＭＬフォーマットで記述されている。

図１１（ａ）は図８のＳ８０２にて、ランゲージモニタ２０８が保存しているＪｏｂＩＤをセットした場合のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの記述例を示している。ＪｏｂＩＤ（ＪｏｂＩＤタグ）に“１”がセットされている（記述１１００）。

図１１（ｂ）は図８のＳ８０３にて、ランゲージモニタ２０８がＪｏｂＩＤとしてデフォルト値をセットした場合のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの記述例を示している。ここでは、ＪｏｂＩＤにデフォルト値として“Ｉｎｖａｌｉｄ”がセットされている（記述１１０１）。

図１１（ｃ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅの構成例を示している。ＧｅｔＰｒｉｎｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅには、印刷装置１１０のＲＡＭ容量や、インクの情報など、印刷装置１１０の状態に関する情報が記述されている。

なお、ここで示した各要求／応答のＸＭＬフォーマットにおける構成は、一例であり、これに限定されるものではない。

［ＬＡＮケーブル抜き差し時の動作］
次に図１２（Ａ）乃至（Ｃ）を用いて、印刷装置１１０がジョブの印刷中に情報処理装置１００側のＬＡＮケーブルが抜き差しされた際のＯＳの印刷サポート機能２０２、ランゲージモニタ２０８、および印刷装置１１０の動作について説明する。

図１２（Ａ）は、ＬＡＮケーブルが情報処理装置１００から抜かれる前の情報処理装置１００と印刷装置１１０の構成を示している。また、情報処理装置１００におけるプリントキュー２０６にて示されるジョブの状態を示している。情報処理装置１００と印刷装置１１０はネットワーク１０９で接続されており、印刷装置１１０はジョブ１を印刷中である。情報処理装置１００上のプリントキュー２０６には状態１２００として印刷中のジョブ１が存在する。

図１２（Ｂ）は、情報処理装置１００側のＬＡＮケーブルが抜かれた際の情報処理装置１００と印刷装置１１０の構成を示している。また、情報処理装置１００におけるプリントキュー２０６にて示されるジョブの状態を示している。情報処理装置１００はＬＡＮケーブルが抜かれたことを検知し、ＯＳの印刷サポート機能２０２はジョブ１を再印刷するため一度削除する（状態１３００）。このとき、印刷装置１１０は情報処理装置１００側のＬＡＮケーブルが抜かれたことを検知できないため、ジョブ１を印刷中のままである（状態１２００）。

図１２（Ｃ）は、情報処理装置１００側のＬＡＮケーブルが再び接続されたときの情報処理装置１００と印刷装置１１０の構成を示している。また、情報処理装置１００におけるプリントキュー２０６にて示されるジョブの状態を示している。情報処理装置１００はＬＡＮケーブルが再接続されたことを検知し、ＯＳの印刷サポート機能２０２はジョブ１を再び印刷する（状態１４００）。ここでは説明を分かりやすくするため、再印刷されたジョブを再印刷される前のジョブ１と区別して、「ジョブ１’」と表記する。一方、印刷装置１１０は情報処理装置１００側のＬＡＮケーブルが抜き差しされたことは検知できないので、ジョブ１を印刷中のままである。すなわち、印刷装置１１０はジョブ１を印刷中の状態であるにもかかわらず、情報処理装置１００はジョブ１’を印刷しようとする。

スプーラ２０５、ランゲージモニタ２０８、ポートモニタ２０９、及び印刷装置１１０は再印刷されたジョブ１’の処理を開始する。スプーラ２０５は、ランゲージモニタ２０８の関数であるＳｔａｒｔＤｏｃＰｏｒｔ（）、ＷｒｉｔｅＰｏｒｔ（）を順次呼び出す（図３に示す処理３０１、３０２）。ランゲージモニタ２０８は、ポートモニタ２０９の関数であるＷｒｉｔｅＰｏｒｔ（）を呼び出し、ポートモニタ２０９はＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを印刷装置１１０に送信する（図３の処理３０３、３０４）。印刷装置１１０はポートモニタ２０９からＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信し処理を開始するが、ジョブ１を印刷中のままであるため図５の以下の処理を行う。

印刷装置１１０は、ポートモニタ２０９からＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信するが（Ｓ５０１）、ジョブ１を印刷中のままであるため、新たにジョブの処理を開始することができない。したがって、印刷装置１１０はＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｓｐｏｎｓｅにエラーをセットし（Ｓ５０２にてＮＯ、Ｓ５０６）、ポートモニタ２０９に送信する（Ｓ５０７）。そして、本処理を終了する。

ランゲージモニタ２０８は、ポートモニタ２０９のＷｒｉｔｅＰｏｒｔ（）の呼び出し（図３の処理３０３）に失敗するため、スプーラ２０５に失敗を通知する（図６のＳ６０２にてＮＯ、Ｓ６０４）。その後、スプーラ２０５はランゲージモニタ２０８のＷｒｉｔｅＰｏｒｔ（）の呼び出しが成功するまで繰り返しランゲージモニタ２０８のＷｒｉｔｅＰｏｒｔ（）を呼び出す（図３の処理３０２）。

一方、ランゲージモニタ２０８は、別スレッドで図３に示す処理３１２に相当するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを印刷装置１１０に送信する。この時のランゲージモニタ２０８の動作を、図８を用いて説明する。ランゲージモニタ２０８は保存したＪｏｂＩＤの有無を確認する（Ｓ８０１）。ここでは、保存したＪｏｂＩＤが無い為（Ｓ８０１にてＮＯ）、ＪｏｂＩＤとしてデフォルト値（Ｉｎｖａｌｉｄ）をＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ ＲｅｑｕｅｓｔのＸＭＬデータにセットする（Ｓ８０３）。そして、ランゲージモニタ２０８は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを印刷装置１１０に送信する（Ｓ８０４）。その後、本処理を終了する。この時に記述されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔは、図１１（ｂ）に示した内容となる。

印刷装置１１０は、ランゲージモニタ２０８からのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信する（図３の処理３１２、３１５）。この時の印刷装置１１０の動作を、図９を用いて説明する。印刷装置１１０はランゲージモニタ２０８からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信する（Ｓ９０１）。そして、印刷装置１１０は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔに含まれているＪｏｂＩＤを取得する（Ｓ９０２）。このＪｏｂＩＤは、“Ｉｎｖａｌｉｄ”となっている。印刷装置１１０は、現在処理中のジョブのＪｏｂＩＤを取得する（Ｓ９０３）。この時のＪｏｂＩＤは、“１”となっている。印刷装置１１０は、取得した２つのＪｏｂＩＤの比較を行い、両者は一致しないので（Ｓ９０４にてＮＯ）、ランゲージモニタ２０８へＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｓｐｏｎｓｅを送信する（Ｓ９０６）。そして、本処理を終了する。

印刷装置１１０は、上記処理に従って、タイムアウト処理用カウンタのクリアは行わない。このためタイムアウト時間が経過すると、印刷装置１１０はタイムアウト処理を行うこととなる。タイムアウト処理を行うことで、印刷装置１１０は印刷中のジョブ１に対する処理を中止し、ジョブ１による印刷装置１１０の占有は解除される。

その後、スプーラ２０５によるランゲージモニタ２０８のＷｒｉｔｅＰｏｒｔ（）の呼び出しは成功する（図３の処理３０２）。そして、印刷装置１１０はポートモニタ２０９からＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔを受信する。（Ｓ５０１）このとき、ジョブ１の印刷が終了しているので、印刷装置１１０は、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ ＲｅｓｐｏｎｓｅのＸＭＬデータに成功を示す値をセットし（Ｓ５０５）、ポートモニタ２０９に送信する（Ｓ５０７）。そして、印刷装置１１０はジョブ１’の処理を開始する。

以上により、印刷装置は自身が処理中でないジョブに対するステータス要求により不正にタイムアウト処理のカウンタをリセットしてしまうことを回避できる。

なお、図１２ではＬＡＮケーブルの抜き差しを例にとって、ネットワークの切断／再接続を説明したが、もちろん物理的なネットワークに限定されるものではなく、例えば無線ＬＡＮなどのネットワークにおいても本発明は適用可能であることはいうまでもない。

＜第二実施形態＞
図１３、１４を参照し、本発明に係る第二実施形態を説明する。図１３は、図２の印刷システムのブロック図に新たにアプリケーション１５００を追加したものである。アプリケーション１５００はアプリケーション２０１と異なり、ＯＳの印刷サポート機能２０２を経由せず、印刷装置１１０に直接印刷ジョブを送信することが可能である。

ここで、アプリケーション２０１、アプリケーション１５００の順で印刷装置１１０に印刷ジョブを送った場合を考える。アプリケーション２０１は、ＯＳの印刷サポート機能２０２を経由して、図３で説明した処理に従って、印刷装置１１０に印刷ジョブを送る。この場合において、印刷ジョブの状態の取得及び印刷装置１１０のタイムアウト処理を防止するために、定期的にＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを送信する。

印刷装置１１０は、アプリケーション２０１からのＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔに対して、ＪｏｂＩＤとして“２００”を割り当て、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｐｏｎｓｅを返却する。このため、アプリケーション２０１が印刷したジョブの状態を取得する為のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの内容は図１４（Ａ）のようになる。ここでは、ＪｏｂＩＤ（ＪｏｂＩＤタグの値）に“２００”が記述されている。

アプリケーション１５００は、ＯＳの印刷サポート機能２０２を経由せずに直接印刷装置１１０に、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔ及びＳｅｎｄＤｏｃｕｍｅｎｔ Ｒｅｑｕｅｓｔを送信し、印刷装置１１０に所望のジョブを印刷させる。この場合において、印刷ジョブの状態の取得及び印刷装置１１０のタイムアウト処理を防止するために、アプリケーション１５００は、定期的にＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを送信する。

印刷装置１１０は、アプリケーション２０１からの印刷ジョブを印刷中なので、アプリケーション１５００からのＣｒｅａｔｅＰｒｉｎｔＪｏｂ Ｒｅｑｕｅｓｔに対して、エラーを返す。この場合、アプリケーション１５００はＪｏｂＩＤを取得できない。よって、アプリケーション１５００が印刷ジョブの状態を取得する為のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔの内容は図１４（Ｂ）のようになる。ここではＪｏｂＩＤ（ＪｏｂＩＤタグの値）に“Ｉｎｖａｌｉｄ”が記述されている。

印刷装置１１０は、アプリケーション２０１もしくはアプリケーション１５００からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信すると、第一実施形態において図９で説明した処理を行う。印刷装置１１０は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔに含まれているＪｏｂＩＤ（Ｓ９０２）と、印刷装置１１０が処理中のジョブのＪｏｂＩＤ（Ｓ９０３）とを比較する（Ｓ９０４）。そして、識別子が一致した場合のみ、印刷装置１１０はタイムアウト処理用のカウンタの値をクリアする（Ｓ９０５）。

以上により印刷装置１１０は、アプリケーション２０１からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信した場合は、ＪｏｂＩＤが一致するのでタイムアウト処理のカウンタの値のクリアを行う。一方、アプリケーション１５００からのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信した場合はＪｏｂＩＤが一致しないので、印刷装置１１０は、カウンタの値のクリアを行わない。このように印刷装置１１０は、情報処理装置１００の複数のアプリケーションからＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信した場合でも正しいタイムアウト処理の行うことができる。

例えば、印刷装置１１０がアプリケーション２０１のジョブを印刷中に、アプリケーション２０１やＯＳの印刷サポート機能２０２が何らかの原因でクラッシュした場合、印刷装置１１０はアプリケーション２０１のジョブを印刷中のままとなる。この時、アプリケーション１５００からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ Ｒｅｑｕｅｓｔを受信した場合、ＪｏｂＩＤが一致しないのでカウンタの値を更新しない。

これにより印刷装置１１０は不正にタイムアウト処理用のカウンタを更新することなく、本来想定した時間が経過後、タイムアウト処理を行い印刷中のジョブを中止し、アプリケーション１５００からの印刷ジョブを受け付けることが可能となる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (7)

1. ネットワークを介して接続された、情報処理装置と印刷装置とを有する印刷システムであって、
   前記情報処理装置は、
   前記印刷装置にジョブに対する印刷開始要求を送信する印刷要求送信手段と、
   前記印刷装置が処理を開始したジョブに割り当てた識別子を取得し、記憶する記憶手段と、
   識別子を含むステータス取得要求を前記印刷装置へ送信するステータス取得要求送信手段と
   を有し、
   前記印刷装置は、
   前記情報処理装置から前記印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当手段と、
   計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理手段と、
   前記情報処理装置から前記ステータス取得要求を受信し、当該ステータス取得要求に含まれる識別子を取得する第一の取得手段と、
   処理中のジョブに割り当てた識別子を取得する第二の取得手段と、
   前記第一の取得手段にて取得した識別子と前記第二の取得手段にて取得した識別子とを比較する比較手段と
   を有し、
   前記タイムアウト処理手段は、前記比較手段の比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とする印刷システム。
2. 前記印刷装置は、ジョブに対する前記割当手段による識別子の割り当て後、当該ジョブの状態を一定期間において特定の状態に設定し維持する維持手段を更に備え、
   前記情報処理装置は、
   前記印刷要求送信手段による印刷開始要求の送信後、一定期間内にジョブの状態を示すジョブ情報の取得要求を送信し、当該ジョブ情報を取得するジョブ情報取得手段と、
   前記ジョブ情報にて示されたジョブの状態が前記特定の状態か否かを判定する状態判定手段と
   を更に有し、
   前記記憶手段は、前記状態判定手段により前記ジョブ情報にて示されたジョブの状態が前記特定の状態の際に、対応する識別子を記憶することを特徴とする請求項１の印刷システム。
3. ネットワークを介して情報処理装置と通信可能な印刷装置であって、
   前記情報処理装置から印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当手段と、
   計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理手段と、
   前記情報処理装置から発行されたステータス取得要求に含まれる識別子と処理中のジョブに割り当てた識別子とを比較する比較手段と
   を有し、
   前記タイムアウト処理手段は、前記比較手段の比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とする印刷装置。
4. ネットワークを介して情報処理装置と通信可能な印刷装置の制御方法であって、
   前記情報処理装置から印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当工程と、
   計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理工程と、
   前記情報処理装置から発行されたステータス取得要求に含まれる識別子と処理中のジョブに割り当てた識別子とを比較する比較工程と
   を有し、
   前記タイムアウト処理工程において、前記比較工程による比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とする制御方法。
5. コンピュータを、
   情報処理装置から印刷開始要求を受信し、処理を開始した当該印刷開始要求に対応するジョブに識別子を割り当てる割当手段、
   計時部を用いて、当該印刷開始要求に対応するジョブの処理のタイムアウトを管理するタイムアウト処理手段、
   前記情報処理装置から発行されたステータス取得要求に含まれる識別子と処理中のジョブに割り当てた識別子とを比較する比較手段
   として機能させ、
   前記タイムアウト処理手段は、前記比較手段の比較により識別子が一致した場合、前記計時部の値をリセットすることを特徴とするプログラム。
6. 前記処理中のジョブがタイムアウトと判定された場合、前記ジョブの処理を中止する制御手段を更に備えることを特徴とする請求項３に記載の印刷装置。
7. 前記処理中のジョブがタイムアウトと判定された場合、前記ジョブの処理を中止する制御手段として前記コンピュータを更に機能させることを特徴とする請求項５に記載のプログラム。

Images