JP5539151B2 - 周辺装置制御システム、周辺装置、情報処理装置、周辺装置制御方法及びプログラム - Google Patents

Description

本発明は、周辺装置制御システム、周辺装置、情報処理装置、周辺装置制御方法及びプログラムに関する。

近年、ＵＳＢ、Ｅｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ等の様々なインタフェースを利用して、情報処理装置に周辺装置を接続し、自宅やオフィスで様々な形態でこのような周辺装置制御システムが有効に活用されている。周辺装置の例としては、例えば、プリンタ、複写機、ファクシミリ、スキャナ、デジタルカメラ、及びこれらの複合機能等が挙げられる。

＜従来の技術＞
今、周辺装置の例としてプリンタを挙げる。複数の情報処理装置によってプリンタを共有するネットワーク印刷システムにおいては、一般に次の２種類のプリンタが用いられている。１つはプリンタに大容量の記憶媒体を備えることで印刷ジョブを記憶し、プリンタから印刷ジョブを実行する構成である。もう１つは、プリンタが、情報処理装置からの印刷ジョブの送信順序を管理し、必要な時に情報処理装置に印刷ジョブの送信を行わせるというものである。尚、ここではプリンタの例を挙げたが、プリントサーバ等を使って実現される例もある。

後者のネットワーク印刷システムにおいては、プリンタに、複数の印刷ジョブを蓄積するための大容量の記憶媒体を備えておくことを不要にすることができる。このようなネットワーク印刷システムに関しては、種々の方式が提案されている。例えば特許文献１によれば、プリンタは情報処理装置から印刷予約を受け付け、印刷予約の受付順を管理し、その順序に応じて情報処理装置に印刷要求を発行させる構成が記載されている。具体的には、情報処理装置からの印刷要求を、現在実行中の印刷処理の完了を待つことなく予約として受付ける。そして、各印刷要求に対しては、受付は順に予約順番号を付し、一つの印刷処理が完了するごとに予約順を更新する。それとともに、次順の情報処理装置に対して印刷データを要求し、該印刷データを受信して印刷処理を行う。

特許文献１に記載されている印刷システムにおいては、情報処理装置に対して印刷データの要求を行う機能をプリンタに装備する必要がある為、コストアップするという問題点があった。これに対して、特許文献２には、プリンタに、情報処理装置に対して印刷データの要求を行う機能を装備する必要がない印刷システムが記載されている。具体的には、情報処理装置より印刷ジョブの処理を要求する印刷要求を発行する。プリンタにおいて、受信した印刷要求の識別子を待ちリストに登録し、該待ちリストを用いて印刷要求に応じた印刷ジョブの実行を管理する。そして、前記印刷要求の受信時における前記待ちリスト中の該印刷要求の順位に基づいて、該印刷要求の発行間隔を決定し、前記決定工程で決定された発行間隔で前記印刷要求を発行するように、前記発行工程を制御する。

また、近年、複数の情報処理装置によってプリンタを共有するネットワーク印刷システムにおける標準化も進んでいる。例えば、発明を実施するための形態で後述するＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用したネットワーク印刷システムが実用化されている。
このＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用したネットワーク印刷システムでは、印刷ジョブの処理を要求する印刷要求として、ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔというオペレーションを、ＯＳがプリンタに発行することで、印刷ジョブの要求が行われる。

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

ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用したネットワーク印刷システムに対して、特許文献２の方法を適用しようとした場合、印刷ジョブの処理を要求する印刷要求であるＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔオペレーションを利用することになる。その際、特許文献２の特徴の内の１つである識別子をＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔの中に付加しておく必要がある。

しかしながら、ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔオペレーションはＯＳが発行する為、プリンタドライバが、またはプリンタドライバからの指示によりＯＳが前記識別子をこのオペレーションの中に付加することができない。ゆえに、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用したネットワーク印刷システムに、特許文献２に記載されているネットワーク印刷システムを適用することができない、という問題がある。

本発明では上記従来例のこのような問題点に着目し、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用したネットワーク印刷システムにおいても、大容量の記憶媒体、及び情報処理装置に対して印刷データの要求を行う機能を備えていない低コストな共有プリンタを利用した、操作性に優れた周辺装置制御システムを提案する。

上記の課題を解決するため、本発明の周辺装置制御システムは、ネットワークを介して接続された情報処理装置と周辺装置からなる周辺装置制御システムであって、前記情報処理装置は、ジョブ要求と予約要求を前記周辺装置に対して発行し、前記周辺装置は、前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して前記ジョブ要求の予約を受け付けることを特徴とする。

本発明によれば、次のような効果が得られる。

（１） 大容量の記憶媒体、及び情報処理装置に対して印刷データの要求を行う機能を備えていない低コストな共有プリンタを利用した、操作性に優れた周辺装置制御システムを実現することができる。
（２） 複数の印刷ジョブを受け付けることができず、１つの印刷ジョブだけを受け付けることができるようなプリンタにおいても、１台または複数のＰＣから発行された複数の印刷ジョブを発行された順序通り正確に印刷することができる。
（３） 複数のプロトコルの印刷ジョブが混在している環境においても、各ＰＣから発行された印刷ジョブが発行された順序に従って正しく印刷される、優れた周辺装置制御システムを実現することができる。

本発明に係る情報処理装置及び周辺装置からなる周辺装置制御システムの一実施形態におけるシステムの構成部分を表すブロック図 ＰＣとプリンタのハードウェア構成の一例を表すブロック図 ＰＣのソフトウェア構成を表す図 ＰＣにおけるプリンタドライバの構成を表す図 印刷時のコーリングシーケンスを表す図 印刷時のコーリングシーケンスを表す図 印刷時のコーリングシーケンスを表す図 ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図 ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図 ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図 ＣｒｅａｔｅＰｒｉｎｔＪｏｂの内容を表す図 プリンタ３におけるＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を表すフローチャート プリンタ３におけるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を表すフローチャート プリンタ３が受け付けて予約した印刷ジョブ要求を管理する印刷キューデータベースを表す図 ＰＣのポートとＤｅｖｉｃｅ ＩＤのＩＮＦＯ情報の関係を示す表 印刷時のコーリングシーケンスを表す図 プリンタ３における印刷予約ＩＤの発行の処理を表すフローチャート ＳｔａｒｔＪｏｂの内容を表す図 プリンタ３における印刷キューデータベースの更新割り込みの処理を表すフローチャート ランゲージモニタ３６におけるＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を表すフローチャート ポートモニタ３７におけるＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を表すフローチャート プリンタ３が受け付けて予約した印刷ジョブ要求を管理する印刷キューデータベースを表す図 プリンタ３におけるＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を表すフローチャート プリンタ３におけるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を表すフローチャート

以下、本発明の実施の形態を、図面を参照して説明する。
以下で引用される Ｖｉｓｔａ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの情報の内、特に詳しい説明を付加していないものに関しては、２００９年７月２２日現在、Ｍｉｃｒｏｓｏｆｔ Ｄｅｖｅｌｏｐｅｒ Ｎｅｔｗｏｒｋ （ＭＳＤＮ）のサイト（ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃＷｉｎｄｏｗｓ（登録商標）ｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐｘ）でインターネット上で公開されている情報であるので、必要以上の説明を省略する。

以下において、ＵＳＢとは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓを表し、２００９年７月２２日現在、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓのサイト（ｈｔｔｐ：／／ｗｗｗ．ｕｓｂ．ｏｒｇ／ｈｏｍｅ）上で公開されている情報であるので、必要以上の説明を省略する。

以下において、ＷＳＤとは、Ｗｅｂ Ｓｅｒｖｉｃｅ ｏｎ Ｄｅｖｉｃｅｓを表し、２００９年７月２２日現在、Ｗｉｎｄｏｗｓ（登録商標） Ｈａｒｄｗａｒｅ Ｄｅｖｅｌｏｐｅｒ Ｃｅｎｔｒａｌのサイト（ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｗｈｄｃ／ｃｏｎｎｅｃｔ／ｒａｌｌｙ／ｒａｌｌｙｗｓｄ．ｍｓｐｘ）上で公開されている情報であるので、必要以上の説明を省略する。

以下において、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｖｅｒｓｉｏｎ １．０は、２００９年７月２２日現在、Ｗｉｎｄｏｗｓ（登録商標） Ｈａｒｄｗａｒｅ Ｄｅｖｅｌｏｐｅｒ Ｃｅｎｔｒａｌのサイト（ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｗｈｄｃ／ｃｏｎｎｅｃｔ／ｒａｌｌｙ／ｗｓｄｓｐｅｃｓ．ｍｓｐｘ）上で公開されている米国マイクロソフト社が定義したＰｒｉｎｔ Ｓｅｒｖｉｃｅであるので、必要以上の説明を省略する。

＜実施形態１＞
図１は本発明に係る情報処理装置及び周辺装置からなる周辺装置制御システムの一実施形態におけるシステムの構成部分を表すブロック図である。同図において、１、２は情報処理装置であり、一般的なパーソナルコンピュータ（以降、ＰＣと略す場合がある）で構成される。ＰＣ１、ＰＣ２、ＰＣ５は図２（ａ）で後述するようなハードウェアで構成される。ＰＣ１とＰＣ２には、ＯＳ（オペレーティングシステム）として米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａ（登録商標）と同等のＯＳがインストールされている。ＰＣ５には、ＯＳとして米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標） ＸＰ（登録商標）と同等のＯＳがインストールされている。ＰＣ１、ＰＣ２、ＰＣ５はそれぞれＥｔｈｅｒｎｅｔ（登録商標）で構成されるネットワーク４に接続されている。７はＵＳＢインタフェースである。３はプリンタであり、カラーインクジェットプリンタで構成され、本発明における周辺装置の一例としている。プリンタ３はＡＢＣ社製のＫｍｍｎというモデル名のプリンタである。尚、本発明における周辺装置としては、プリンタ、複写機、ファクシミリ、スキャナ、デジタルカメラ、及びこれらの複合機能を備える装置等であってもよい。

プリンタ３は図２（ｂ）で後述するようなハードウェアで構成され、ＰＣ１とＵＳＢインタフェース７及びネットワーク４を介して接続されており、互いに双方向通信が可能である。３０は図４で後述する印刷可能なアプリケーションであり、Ｗｉｎｄｏｗｓ（登録商標）用の実行可能形式のファイル（＊．ＥＸＥ）で構成される。３６は図４に示すようなランゲージモニタである。

図２はＰＣとプリンタのハードウェア構成の一例を表すブロック図である。ＰＣ１、ＰＣ２、ＰＣ５は同図の（ａ）に示すようなハードウェアで構成されている。同図の（ａ）ではＰＣ１の例で説明する。ＰＣ１はランダムアクセスメモリ部（ＲＡＭ２０１）、記憶部であるハードディスクドライブ部（ＨＤＤ２０２）、入力部の一例であるキーボード部（ＫＢＤ２０３）、制御部のＣＰＵ２０４、表示部の一例である表示用ディスプレイ（ＬＣＤ２０５）、通信制御部の一例であるネットワークボード（ＮＢ２０７）等を有する。
以上のＰＣ１の構成要素はバス２０６により互いに接続されている。尚、記憶部は、可搬性ＣＤ−ＲＯＭまたは内部据付のＲＯＭなどであってもよい。図３、図４に示す各モジュール（ソフトウェア）は、ＨＤＤ２０２に記憶され、必要に応じてＲＡＭ２０１に読み出されてＣＰＵ２０４により実行される。これにより、ＣＰＵ２０４が、図３、図４に示す各モジュール（ソフトウェア）の機能を実現する。

プリンタ３は図２（ｂ）に示すようなハードウェア構成を持つ。図２（ｂ）において、１５はマイクロプロセッサ等から構成されるＣＰＵであり、プリンタ３の中央処理装置として、ＲＯＭ１６に記憶されているプログラムに従って、ＲＡＭ１７、通信部１８、記録部１９、操作部２０、表示部２１を制御する。ＲＯＭ１６にはプリンタドライバ５０（図４で後述する）の制御に従ってプリンタ３が記録（印刷）処理や、印刷動作の状態をＰＣ１へ通知する処理を行うプログラムが記憶されている。ＲＡＭ１７は主にＰＣ１から送られて、それをもとに記録部１９によって印刷される印字データが一時的に記憶される。通信部１８にはＵＳＢインタフェース７やネットワーク４用の接続ポート等が含まれており、ＵＳＢやＥｔｈｅｒｎｅｔ（登録商標）通信を制御する。記録部１９は、インクジェット方式の記録ヘッド、各カラーインク、キャリッジ、記録紙搬送機構等から構成される記録ユニットと、前記印字データをもとに前記記録ヘッドにて印字用パルスを発生させる為のＡＳＩＣ等から構成される電気回路とから構成される。印刷可能なアプリケーション上での印刷操作によって、アプリケーションで開かれているファイルの表示内容（画像データ）が、ＥＭＦ形式のスプールファイルとしてＰＣ１のＨＤＤ２０２に一時的に格納される。そして、プリンタドライバ５０を介してプリンタ３制御用コマンドを含む印字データに変換された後、ＵＳＢインタフェース７またはネットワーク４を介してプリンタ３に送られる。プリンタ３にて受信された印字データは、記録部１９で印字用パルスに変換されて、記録紙上に印刷される。２０は操作部であり、電源ボタン、リセットボタン等の各種ボタンから構成され、プリンタ３を操作することができる。２１は表示部であり、タッチパネルの液晶ディスプレイで構成され、プリンタ３の状態の表示や、各種設定の表示、入力等を行うことができる。

図３はＰＣのソフトウェア構成を表す図である。同図において、９２はＥｔｈｅｒｎｅｔ（登録商標）を制御するＥｔｈｅｒｎｅｔ（登録商標）制御スタックである。９１はＩＰ Ｎｅｔｗｏｒｋを制御するＩＰ Ｎｅｔｗｏｒｋ制御スタックである。９０はＷＳＤを制御するＷＳＤ制御スタックである。８９はＩＨＶの独自プロトコルを制御するＩＨＶネイティブプロトコル制御スタックである。８８はネットワークのプラグ アンド プレイ（以降、Ｎ−ＰｎＰと略す場合がある）を制御するＮ−ＰｎＰ制御スタックである。尚、ネットワーク接続デバイスに対するサポートを提供する、プラグ アンド プレイの一連の拡張機能としてＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａ ＯＳに標準搭載されている機能として、Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｅｘｔｅｎｓｉｏｎｓ（ＰｎＰ−Ｘ）が存在するが、本実施例ではこれと同等の機能として前記Ｎ−ＰｎＰを利用する例で説明する。後述するＷＳＤを制御するＷＳＤＡＰＩｓは、ＷＳＤ制御スタック９０に含まれる。後述するＩＨＶの独自プロトコルを制御するＡＰＩｓは、ＩＨＶネイティブプロトコル制御スタック８９に含まれる。８５はデバイスドライバ群であり、ＯＳに標準で同梱されている標準ドライバ群８７とＩＨＶから提供されるＩＨＶ製ドライバ群８６から構成される。８４はアプリケーション／ＤＤＩインタフェースであり、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）、Ｄｅｖｉｃｅ Ｄｒｉｖｅｒ Ｉｎｔｅｒｆａｃｅ（ＤＤＩ）から構成される。３０は図４で後述する印刷可能なアプリケーションである。８２はアプリケーション群であり、アプリケーション３０等から構成される。この図ではＰＣ１の例で説明したが、例えば、ＰＣ５のようにＰＣにインストールされているＯＳが米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標） ＸＰの場合、ＷＳＤ制御スタック９０が存在せず、ＩＨＶネイティブプロトコル制御スタック８９だけが存在する。この場合、このＰＣではＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを利用した印刷を行うことができない為、ＩＨＶの独自プロトコルを利用して印刷を行う。

図４はＰＣにおけるプリンタドライバの構成を表す図である。同図において、５０はＰＣ１にインストールされているプリンタ３用のプリンタドライバであり、３３〜３６、３９の複数のモジュールから構成される。３０は印刷可能なアプリケーションであり、例えば、ＯＳに標準で同梱されているテキストエディタであるＮｏｔｅｐａｄ（Ｎｏｔｅｐａｄ．ｅｘｅ）等に相当する。３１はＧｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ（ＧＤＩ）であり、ＯＳの一部である。３２はプリンタキューであり、スプーラ４０の一部として構成され、印刷ジョブがキューイングされる。キューイングされた印刷ジョブはプリンタキューフォルダ（図は省略）に表示される。３３はプリントプロセッサであり、印刷レイアウトの変更や印刷画像に対する特殊処理が行われる。３４はグラフィックスドライバであり、プリンタドライバの画像処理のコアとして、ＧＤＩ３１から送られて来る描画命令をもとに印刷用の画像処理を行い、印刷制御コマンドを作成する。３５はＵＩモジュールであり、プリンタドライバのユーザインタフェースの提供及び制御を行う。３６はランゲージモニタであり、データの通信Ｉ／Ｆとしてデータの送受信を制御する。３９はステータスモニタであり、プリンタ３のインクの残量や、警告、エラー等の状態を表示する。３７はポートモニタであり、ランゲージモニタ３６から送られて来るデータを適切なポートに対して送信したり、プリンタ３から送られて来るデータをクラスドライバ３８を介して受信したりする処理を行う。特に、ＵＳＢを制御するポートモニタのことをＵＳＢＭｏｎ、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅを制御するポートモニタのことをＷＳＤＭｏｎと呼ぶ。３８はクラスドライバであり、最もポートに近いローレベルのモジュールである。本発明ではＷＳＤやＩＨＶの独自プロトコルのプリンタクラスのドライバに相当し、ポート（本発明ではＵＳＢまたはネットワークポート）を制御する。プリンタドライバ５０はプリンタ３の製造元であるＡＢＣ社製のものである。

図５は印刷時のコーリングシーケンスを表す図である。同図は従来例を表す図である。

今、プリンタ３は複数の印刷ジョブを受け付けることができず、１つの印刷ジョブだけを受け付けることができる、と仮定する。同図において、ユーザがアプリケーション３０から印刷を開始すると（Ｓ５０１）、ＯＳはスプーラ４０のＳｔａｒｔＰｒｉｎｔＪｏｂ（ ）関数をコールする。この関数内において（Ｓ５０２）、まず、スプーラ４０はランゲージモニタ３６のＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ５０３）。この関数内において（Ｓ５０４）、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ５０５）。この関数内において（Ｓ５０６）、ポートモニタ３７は必要に応じて適当な処理を行い（Ｓ５０７）、戻り値ｐｍＲｅｔにその処理の結果を代入してこの関数を終了し、呼び出し元に戻る（Ｓ５０８）。通常、正常に処理された場合はｐｍＲｅｔにＴＲＵＥが代入され、それ以外の場合はｐｍＲｅｔにＦＡＬＳＥが代入される。ランゲージモニタ３６は、ＰＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入して（Ｓ５０５）、ＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ５０９）。スプーラ４０は、このＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入する（Ｓ５０３）。ｓｐＲｅｔがＴＲＵＥではない（ＦＡＬＳＥである）場合（Ｓ５１０）、Ｓ５０３に戻り、スプーラ４０はランゲージモニタ３６のＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールする。Ｓ５１０においてｓｐＲｅｔがＴＲＵＥの場合、次に、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする（Ｓ５１１）。この関数内において（Ｓ５１２）、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする（Ｓ５１３）。この関数内において（Ｓ５１４）、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数をコールする（Ｓ５１５）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔをプリンタ３に発行する。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔの中に、この印刷ジョブに関する詳細情報が含まれている。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅまたは拒絶応答であるＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す（Ｓ５１６）。例えば、プリンタ３が印刷ジョブを受け付けることができ、その印刷ジョブを受け付けた場合、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅをＰＣ１に返す。プリンタ３が印刷ジョブを受け付けることができない場合、プリンタ３はＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す。ＰＣ１がＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅを受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ５１５）。ＰＣ１がＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）を受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ５１５）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値を代入して（Ｓ５１５）、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ５１７）。ランゲージモニタ３６は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入して（Ｓ５１３）、ＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ５１８）。スプーラ４０は、このＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入する（Ｓ５１１）。ｓｐＲｅｔがＴＲＵＥではない（ＦＡＬＳＥである）場合（Ｓ５１９）、Ｓ５１１に戻り、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする。Ｓ５１９においてｓｐＲｅｔがＴＲＵＥの場合、スプーラ４０は引き続き図７に示す印刷データの送信処理を行う。最後に、スプーラ４０はランゲージモニタ３６のＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ５２０）。この関数内において（Ｓ５２１）、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ５２２）。この関数内において（Ｓ５２３）、ポートモニタ３７は必要に応じて適当な処理を行い（Ｓ５２４）、戻り値ｐｍＲｅｔにその処理の結果を代入してこの関数を終了し、呼び出し元に戻る（Ｓ５２５）。通常、正常に処理された場合はｐｍＲｅｔにＴＲＵＥが代入され、それ以外の場合はｐｍＲｅｔにＦＡＬＳＥが代入される。ランゲージモニタ３６は、ＰＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入して（Ｓ５２２）、ＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ５２６）。スプーラ４０は、このＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入し（Ｓ５２０）、ＳｔａｒｔＰｒｉｎｔＪｏｂ（ ）関数を終了し、呼び出し元に戻る（Ｓ５２７）。このように、従来例では、複数のＰＣから発行された印刷ジョブ全てを、プリンタ３が、印刷ジョブが発行された順に受け付けることができないので、後から発行された印刷ジョブが先に印刷されてしまう、というようなケースが発生し、問題となっている。

図６、図１６は印刷時のコーリングシーケンスを表す図である。これらの図は本発明の特徴を最もよく表す図の内の１つである。今、プリンタ３は、１つの印刷ジョブだけを処理して印刷を実行することができる、というような廉価版のプリンタであるものの、複数の印刷ジョブを受け付けることができ、その内の１つの印刷ジョブを処理して印刷を実行することができる、と仮定する。

図６において、ユーザがアプリケーション３０から印刷を開始すると（Ｓ６０１）、ＯＳはスプーラ４０のＳｔａｒｔＰｒｉｎｔＪｏｂ（ ）関数をコールする。この関数内において（Ｓ６０２）、まず、スプーラ４０はランゲージモニタ３６のＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ６０３）。この関数内において（Ｓ６０４）、ランゲージモニタ３６はｌｍＭｕｌｔｉｐｌｅＪｏｂｓにＦＡＬＳＥを代入して初期化する（Ｓ６０５）。このｌｍＭｕｌｔｉｐｌｅＪｏｂｓはランゲージモニタ３６内で使用されるフラグであり、プリンタ３が複数の印刷ジョブを受け付けて順次処理する機能を備えている場合にＴＲＵＥがセットされ、それ以外の場合にＦＡＬＳＥがセットされる。ランゲージモニタ３６はｌｍＲｅｔｒｙに０を代入して初期化する（Ｓ６０６）。このｌｍＲｅｔｒｙはランゲージモニタ３６内で使用される変数であり、ＰＣ１がプリンタ３に発行する印刷ジョブ要求のリトライ回数を表す。ランゲージモニタ３６はｌｍＲｅｃｅｉｖｅｄＩｄに“Ｎｏｎｅ”を代入して初期化する（Ｓ６０７）。このｌｍＲｅｃｅｉｖｅｄＩｄには、図１６で後述するＳ１６０７、Ｓ１６２３において、プリンタ３が印刷ジョブ要求の予約を受け付けた時に発行する印刷予約ＩＤが代入される。その後、ランゲージモニタ３６は図５のＳ５０５〜Ｓ５０９と同じ処理を行う。スプーラ４０は、Ｓ５０９と同じ処理で返されたＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入する（Ｓ６０３）。ｓｐＲｅｔがＴＲＵＥではない（ＦＡＬＳＥである）場合（Ｓ６０８）、Ｓ６０３に戻り、スプーラ４０はランゲージモニタ３６のＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールする。次に、Ｓ６０８においてｓｐＲｅｔがＴＲＵＥの場合、図１６のＳ１６０１へ進む。図１６において、印刷ジョブ要求の発行、予約処理に関して後述する。最後に、スプーラ４０はランゲージモニタ３６のＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数をコールする（Ｓ６０９）。この関数内において（Ｓ６１０）、ランゲージモニタ３６はｌｍＭｕｌｔｉｐｌｅＪｏｂｓにＦＡＬＳＥを代入して初期化する（Ｓ６１１）。ランゲージモニタ３６はｌｍＲｅｔｒｙに０を代入して初期化する（Ｓ６１２）。ランゲージモニタ３６はｌｍＲｅｃｅｉｖｅｄＩｄに“Ｎｏｎｅ”を代入して初期化する（Ｓ６１３）。その後、ランゲージモニタ３６は図５のＳ５２２〜Ｓ５２５と同じ処理を行う。ランゲージモニタ３６はＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ６１４）。この時、ランゲージモニタ３６は、Ｓ５２２と同じ処理により、ＰＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数の戻り値をｌｍＲｅｔに代入し、このｌｍＲｅｔの値をＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数の戻り値として返す（Ｓ６１４）。スプーラ４０は、このＬＭ＿ＥｎｄＤｏｃＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入し（Ｓ６０９）、ＳｔａｒｔＰｒｉｎｔＪｏｂ（ ）関数を終了し、呼び出し元に戻る（Ｓ６１５）。

図１６において、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする（Ｓ１６０２）。この関数内において（Ｓ１６０３）、ランゲージモニタ３６はｌｍＲｅｔｒｙとｌｍＭｕｌｔｉｐｌｅＪｏｂｓの値を確認（Ｓ１６０４）する。ｌｍＲｅｔｒｙが０より大きく、かつ、ｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥの場合、Ｓ１６０５へ進む。ｌｍＲｅｔｒｙが０またはｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥではない（ＦＡＬＳＥである）場合、Ｓ１６０９へ進む。Ｓ１６０５において、ランゲージモニタ３６は、引数にａｎｓ：ＡＢＣＣｏｍｍａｎｄをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（Ｓ１６０６）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ１６０５）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ１６０５）。Ｓ１６０５において、ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。Ｓ１６０５でＰＣ１が発行するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔと、それに対してプリンタ３が返すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの詳細に関しては図９、図１０で説明する。ランゲージモニタ３６は、Ｓ１６０５のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２または１０１１にセットされている値を、ｌｍＲｅｃｅｉｖｅｄＩｄに代入する（Ｓ１６０７）。ランゲージモニタ３６は、ｌｍＲｅｃｅｉｖｅｄＩｄの値を確認し、「Ｎｏｎｅ」の場合（Ｓ１６２７）、ｌｍＲｅｔｒｙに０を代入して印刷ジョブ要求のリトライ回数を初期化する（Ｓ１６２８）。ｌｍＲｅｃｅｉｖｅｄＩｄの値が「Ｎｏｎｅ」ではない場合（Ｓ１６２９）、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに１を足した値をｌｍＲｅｔｒｙに代入して、印刷ジョブ要求のリトライ回数を更新する（Ｓ１６０８）。Ｓ１６０９において、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする。この関数内において（Ｓ１６１０）、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数をコールする（Ｓ１６１１）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔをプリンタ３に発行する。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔの中に、この印刷ジョブに関する詳細情報が含まれている。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅまたは拒絶応答であるＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す（Ｓ１６１２）。例えば、プリンタ３が印刷ジョブを受け付けて、この印刷ジョブを実行することができる状態の時に、その印刷ジョブを受け付けた場合、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅをＰＣ１に返す。プリンタ３が印刷ジョブを受け付けることはできるが、この印刷ジョブを実行することができない状態の時に、その印刷ジョブを受け付けた場合、プリンタ３はＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す。また、プリンタ３が印刷ジョブを受け付けることができない場合も、プリンタ３はＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す。ＰＣ１がＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅを受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ１６１３）。ＰＣ１がＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）を受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ１６１１）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値を代入して（Ｓ１６１１）、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ１６１３）。ランゲージモニタ３６は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入する（Ｓ１６０９）。ランゲージモニタ３６は、ｌｍＲｅｔの値を確認し（Ｓ１６１４）、ＴＲＵＥの場合、Ｓ１６２５へ進み、ＴＲＵＥではない（ＦＡＬＳＥである）場合、ｌｍＲｅｔｒｙの値を確認する（Ｓ１６１５）。Ｓ１６１５において、ｌｍＲｅｔｒｙが０の場合、ランゲージモニタ３６は、引数にｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする（Ｓ１６１６）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの中に、プリンタ３が複数の印刷ジョブを受け付けることができるか否かを表す＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２（図８（ｂ）で後述）を取得する為に必要な＜ｗｐｒｔ：Ｎａｍｅ＞ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ＜／ｗｐｒｔ：Ｎａｍｅ＞要素８０１（図８（ａ）で後述）が含まれている。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（Ｓ１６１７）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ１６１６）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ１６１６）。Ｓ１６１６において、ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。

ランゲージモニタ３６は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２にセットされている値を確認する（Ｓ１６１８）。Ｓ１６１８において、＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２に「ｔｒｕｅ」がセットされている場合、ｌｍＭｕｌｔｉｐｌｅＪｏｂｓにＴＲＵＥを代入する（Ｓ１６１９）。Ｓ１６１５において、ｌｍＲｅｔｒｙが０以外（Ｓ１６０８、Ｓ１６２４でｌｍＲｅｔｒｙに代入される値は０以上の整数なので、実際には０より大きい整数）の場合、Ｓ１６２０へ進む。Ｓ１６２０において、ｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥの場合、ランゲージモニタ３６は、引数にａｎｓ：ＡＢＣＣｏｍｍａｎｄをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする（Ｓ１６２１）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（Ｓ１６２２）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ１６２１）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ１６２１）。Ｓ１６２１において、ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。Ｓ１６２１でＰＣ１が発行するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔと、それに対してプリンタ３が返すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの詳細に関しては図９、図１０で説明する。ランゲージモニタ３６は、Ｓ６２１のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２または１０１１にセットされている値、すなわち印刷予約ＩＤを、ｌｍＲｅｃｅｉｖｅｄＩｄに代入する（Ｓ１６２３）。ランゲージモニタ３６は、ｌｍＲｅｃｅｉｖｅｄＩｄの値を確認し、「Ｎｏｎｅ」の場合（Ｓ１６３０）、ｌｍＲｅｔｒｙに０を代入して印刷ジョブ要求のリトライ回数を初期化する（Ｓ１６３１）。ｌｍＲｅｃｅｉｖｅｄＩｄの値が「Ｎｏｎｅ」ではない場合（Ｓ１６３２）、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに１を足した値をｌｍＲｅｔｒｙに代入して、印刷ジョブ要求のリトライ回数を更新する（Ｓ１６２４）。Ｓ１６２０において、ｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥではない（ＦＡＬＳＥである）場合、Ｓ１６２５へ進む。

Ｓ１６２５において、ランゲージモニタ３６はＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る。この時、このＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値として、ｌｍＲｅｔの値が返される。スプーラ４０は、このＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入する（Ｓ１６０２）。ｓｐＲｅｔがＴＲＵＥではない（ＦＡＬＳＥである）場合（Ｓ１６２６）、Ｓ１６０２に戻り、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする。Ｓ１６２６においてｓｐＲｅｔがＴＲＵＥの場合、スプーラ４０は引き続き図７に示す印刷データの送信処理を行う。このように、本発明によれば、たとえプリンタが１つの印刷ジョブだけを処理して印刷を実行するような廉価版のプリンタであっても、複数のＰＣから発行された印刷ジョブをこのプリンタが順次受け付け、受け付けた順序で印刷を実行することができるので、後から発行された印刷ジョブが先に印刷されてしまう、というようなケース（問題）が発生することが無い。これにより、印刷ジョブが発行された順序に従って正しく印刷される、優れた周辺装置制御システムを実現することができる。

図７は印刷時のコーリングシーケンスを表す図である。図５のＳ５１９または図１６のＳ１６２６において、ｓｐＲｅｔがＴＲＵＥの場合、図７において、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする（Ｓ７０１）。この関数内において（Ｓ７０２）、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする（Ｓ７０３）。この関数内において（Ｓ７０４）、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数をコールする（Ｓ７０５）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔをプリンタ３に発行し、ＭＴＯＭ（Ｍｅｓｓａｇｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｍｅｃｈａｎｉｓｍ）メッセージエンコーディングを使って、印刷制御コマンドで構成された印刷データを、ＳＯＡＰメッセージを使用して未処理のバイトとしてプリンタ３に送信する。プリンタ３は、ＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔに対してＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅをＰＣ１に返す（Ｓ７０６）。ＰＣ１がＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅを受け取り、全ての印刷データをプリンタ３に送信し終わると、ＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元に戻る（Ｓ７０５）。ＰＣ１がＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔを発行した時、あるいはＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅを受け取った時に、何らかのエラーが発生した場合、ＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ７０５）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値を代入して（Ｓ７０５）、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ７０７）。ランゲージモニタ３６は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入して（Ｓ７０３）、ＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数を終了し、呼び出し元に戻る（Ｓ７０８）。スプーラ４０は、このＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値をｓｐＲｅｔに代入する（Ｓ７０１）。ｓｐＲｅｔがＴＲＵＥではない（ＦＡＬＳＥである）場合（Ｓ７０９）、Ｓ７０１に戻り、スプーラ４０はランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする。Ｓ７０９においてｓｐＲｅｔがＴＲＵＥの場合、図５のＳ５２０または図６のＳ６０９へ進む。

図２０はランゲージモニタ３６におけるＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を表すフローチャートである。同図は本発明の特徴を最もよく表す図の内の１つである。図２０のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。図１６において、スプーラ４０がランゲージモニタ３６のＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールすると、図２０において、ランゲージモニタ３６がＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を開始する（Ｓ２００１）。ランゲージモニタ３６はｌｍＲｅｔｒｙとｌｍＭｕｌｔｉｐｌｅＪｏｂｓの値を確認し（Ｓ２００２）、ｌｍＲｅｔｒｙが０より大きく、かつ、ｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥの場合ステップＳ２００４へ進み、ｌｍＲｅｔｒｙが０またはｌｍＭｕｌｔｉｐｌｅＪｏｂｓがＴＲＵＥではない（ＦＡＬＳＥである）場合ステップＳ２００９へ進む（Ｓ２００３）。ステップＳ２００４において、ランゲージモニタ３６は、引数にａｎｓ：ＡＢＣＣｏｍｍａｎｄをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する（Ｓ２００４）。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（図１６のＳ１６０６、図１３のステップＳ１３１９）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２００４）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２００４）。ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する（Ｓ２００４）。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。Ｓ２００４でＰＣ１が発行するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔと、それに対してプリンタ３が返すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの詳細に関しては図９、図１０で説明する。ランゲージモニタ３６は、Ｓ２００４のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２または１０１１にセットされている値を、ｌｍＲｅｃｅｉｖｅｄＩｄに代入する（Ｓ２００５）。ランゲージモニタ３６は、ｌｍＲｅｃｅｉｖｅｄＩｄの値を確認し（Ｓ２００６）、「Ｎｏｎｅ」の場合ステップＳ２００７へ進み、「Ｎｏｎｅ」ではない場合ステップＳ２００８へ進む。ステップＳ２００７において、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに０を代入して印刷ジョブ要求のリトライ回数を初期化する。ステップＳ２００８において、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに１を足した値をｌｍＲｅｔｒｙに代入して、印刷ジョブ要求のリトライ回数を更新する。Ｓ２００９において、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールする。この関数内におけるポートモニタ３７の処理は、図２１の（ａ）で後述する。ランゲージモニタ３６は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値を戻り値ｌｍＲｅｔに代入する（Ｓ２００９）。ランゲージモニタ３６は、ｌｍＲｅｔの値を確認し（Ｓ２０１０）、ＴＲＵＥの場合ステップＳ２０２１へ進み、ＴＲＵＥではない（ＦＡＬＳＥである）場合ステップＳ２０１１へ進む。

ステップＳ２０１１において、ランゲージモニタ３６は、ｌｍＲｅｔｒｙの値を確認し、０の場合ステップＳ２０１２へ進み、０以外（Ｓ２００８、Ｓ２０２０でｌｍＲｅｔｒｙに代入される値は０以上の整数なので、実際には０より大きい整数）の場合ステップＳ２０１５へ進む。ステップＳ２１１２において、ランゲージモニタ３６は、引数にｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する（Ｓ２０１２）。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの中に、プリンタ３が複数の印刷ジョブを受け付けることができるか否かを表す＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２（図８（ｂ）で後述）を取得する為に必要な＜ｗｐｒｔ：Ｎａｍｅ＞ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ＜／ｗｐｒｔ：Ｎａｍｅ＞要素８０１（図８（ａ）で後述）が含まれている。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（図１６のＳ１６１７、図１３のステップＳ１３１９）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２０１２）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２０１２）。ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する（２０１２）。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。ランゲージモニタ３６は、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２にセットされている値を確認する（Ｓ２０１３）。Ｓ２０１３において、＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２に「ｔｒｕｅ」がセットされている場合ステップＳ２０１４へ進み、それ以外の場合ステップＳ２０１５へ進む。ステップＳ２０１４において、ランゲージモニタ３６はｌｍＭｕｌｔｉｐｌｅＪｏｂｓにＴＲＵＥを代入する。ステップＳ２０１５において、ランゲージモニタ３４はｌｍＭｕｌｔｉｐｌｅＪｏｂｓの値を確認し、ＴＲＵＥの場合ステップＳ２０１６へ進み、ＴＲＵＥではない（ＦＡＬＳＥである）場合ステップＳ２０２１へ進む。ステップＳ２０１６において、ランゲージモニタ３６は、引数にａｎｓ：ＡＢＣＣｏｍｍａｎｄをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数をコールする。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔをプリンタ３に発行する。このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対して、プリンタ３はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ１に返す（図１６のＳ１６２２、図１３のステップＳ１３１９）。ＰＣ１がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ると、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２０１６）。ＰＣ１がプリンタ３に対してＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからある一定時間の間に、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取らなかった場合、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２０１６）。ランゲージモニタ３６はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値をｌｍＲｅｔに代入する（Ｓ２０１６）。尚、ここでは、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の戻り値としてＦＡＬＳＥが返されるようなエラーケースの説明は省略する。ステップＳ２０１６でＰＣ１が発行するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔと、それに対してプリンタ３が返すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの詳細に関しては図９、図１０で説明する。ランゲージモニタ３６は、ステップＳ２０１６のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数の引数として渡されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ内の＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２または１０１１にセットされている値、すなわち印刷予約ＩＤを、ｌｍＲｅｃｅｉｖｅｄＩｄに代入する（Ｓ２０１７）。ランゲージモニタ３６は、ｌｍＲｅｃｅｉｖｅｄＩｄの値を確認し（Ｓ２０１８）、「Ｎｏｎｅ」の場合ステップＳ２０１９へ進み、「Ｎｏｎｅ」ではない場合ステップＳ２０２０へ進む。ステップＳ２０１９において、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに０を代入して印刷ジョブ要求のリトライ回数を初期化する。ステップＳ２０２０において、ランゲージモニタ３６は、ｌｍＲｅｔｒｙに１を足した値をｌｍＲｅｔｒｙに代入して、印刷ジョブ要求のリトライ回数を更新する。ステップＳ２０２１において、ランゲージモニタ３６は、ＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値として、ｌｍＲｅｔをスプーラ４０にリターンして返し、ＬＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を終了して、呼び出し元であるスプーラ４０に戻る（Ｓ２０２２）。

図２１はポートモニタ３７におけるＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を表すフローチャートである。図２１のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。図２０のステップＳ２００９において、ランゲージモニタ３６がポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールすると、図２１の（ａ）において、ポートモニタ３７がＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を開始する（Ｓ２１０１）。ポートモニタ３７がＣｒｅａｔｅＰｒｉｎｔＪｏｂの状況を確認し（Ｓ２１０２）、ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを発行して、それに対する応答としてＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅを既に受信済みの場合（Ｓ２１０３）、ステップＳ２１０５へ進み、それ以外の場合、ステップＳ２１０４へ進む。ステップＳ２１０５において、ポートモニタ３７は戻り値ｐｍＲｅｔにＴＲＵＥを代入する。ステップＳ２１０４において、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数をコールする。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔをプリンタ３に発行する（Ｓ２１０４）。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔの中に、この印刷ジョブに関する詳細情報が含まれている。このＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅまたは拒絶応答であるＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す（図１６のＳ１６１２）。例えば、プリンタ３が印刷ジョブを受け付けて、この印刷ジョブを実行することができる状態の時に、その印刷ジョブを受け付けた場合、プリンタ３はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅをＰＣ１に返す（図１６のＳ１６１２）。プリンタ３が印刷ジョブを受け付けることはできるが、この印刷ジョブを実行することができない状態の時に、その印刷ジョブを受け付けた場合、プリンタ３はＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す（図１６のＳ１６１２）。

また、プリンタ３が印刷ジョブを受け付けることができない場合も、プリンタ３はＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ１に返す（図１６のＳ１６１２）。ＰＣ１がＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅを受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元であるポートモニタ３７に戻る（Ｓ２１０４）。ＰＣ１がＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）を受け取ると、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元であるポートモニタ３７に戻る（Ｓ２１０４）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）関数の戻り値を代入する（Ｓ２１０４）。ポートモニタ３７は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値として、ｐｍＲｅｔをランゲージモニタ３６にリターンして返し（Ｓ２１０６）、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を終了して、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２１０７）。

図７のＳ７０３において、ランゲージモニタ３６がポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数をコールすると、図２１の（ｂ）において、ポートモニタ３７がＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を開始する（Ｓ２１０８）。ポートモニタ３７がＳｅｎｄＤｏｃｕｍｅｎｔの状況を確認し（Ｓ２１０９）、ＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔを発行して、それに対する応答としてＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅを既に受信済みの場合（Ｓ２１１０）、ステップＳ２１１２へ進み、それ以外の場合、ステップＳ２１１１へ進む。ステップＳ２１１２において、ポートモニタ３７は戻り値ｐｍＲｅｔにＴＲＵＥを代入する。ステップＳ２１１１において、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数をコールする（図７のＳ７０５）。この関数内において、ＰＣ１はＷＳＤのＰｒｉｎｔ ＳｅｒｖｉｃｅのＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔをプリンタ３に発行し、ＭＴＯＭ（Ｍｅｓｓａｇｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｍｅｃｈａｎｉｓｍ）メッセージエンコーディングを使って、印刷制御コマンドで構成された印刷データを、ＳＯＡＰメッセージを使用して未処理のバイトとしてプリンタ３に送信する（Ｓ２１１１）。プリンタ３は、ＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔに対してＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅをＰＣ１に返す（図７のＳ７０６）。ＰＣ１がＳｅｎｄＤｏｃｕｍｅｎｔＲｅｑｕｅｓｔを発行した時、あるいはＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅを受け取った時に、何らかのエラーが発生した場合、ＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値にＦＡＬＳＥが代入されて、呼び出し元に戻る（Ｓ２１１１）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値を代入する（Ｓ２１１１）。ＰＣ１がＳｅｎｄＤｏｃｕｍｅｎｔＲｅｓｐｏｎｓｅを受け取り、全ての印刷データをプリンタ３に送信し終わると、ＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値にＴＲＵＥが代入されて、呼び出し元であるポートモニタ３７に戻る（Ｓ２１１３）。ポートモニタ３７は、戻り値ｐｍＲｅｔにＳｅｎｄＤｏｃｕｍｅｎｔ（ ）関数の戻り値を代入する（Ｓ２１１３）。ポートモニタ３７は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の戻り値として、ｐｍＲｅｔをランゲージモニタ３６にリターンして返し（Ｓ２１１４）、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の処理を終了して、呼び出し元であるランゲージモニタ３６に戻る（Ｓ２１１５）。

図８〜図１０はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図、図１１はＣｒｅａｔｅＰｒｉｎｔＪｏｂの内容を表す図である。ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓオペレーションは、通常、プリンタに関する情報を取得する為に利用される。ＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーションは、印刷ジョブの開始要求である。以降において、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ、ＣｒｅａｔｅＰｒｉｎｔＪｏｂの一般的な内容に関しては、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｖｅｒｓｉｏｎ １．０で定義されているので、ここではその説明を省略する。

図１１はＣｒｅａｔｅＰｒｉｎｔＪｏｂの内容を表す図であり、（ａ）はジョブ要求であるＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔ、（ｂ）はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅをそれぞれ表す。

図１１（ａ）はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを表す図である。同図に示すＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔは、ＰＣ１からプリンタ３に発行されるものの一例である。同図において、１１０５は、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅの名前空間を名前空間名ｗｐｒｔと定義している記述である。名前空間名ｗｐｒｔの有効範囲内は、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｖｅｒｓｉｏｎ １．０で定義されているパブリック情報である。以降の図においても、名前空間名ｗｐｒｔは同様な取り扱いとなり、名前空間名ｗｐｒｔの有効範囲内は、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｖｅｒｓｉｏｎ １．０で定義されているパブリック情報を表す。１１０１は＜ｗｐｒｔ：ＪｏｂＤｅｓｃｒｉｐｔｉｏｎ＞要素であり、前記パブリック情報であり、この中に印刷ジョブに関する情報が含まれている。１１０２は＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素であり、前記パブリック情報であり、印刷ジョブ名がセットされる。この例では、「Ｐｈｏｔｏ２」という印刷ジョブ名がセットされている状態を表す。１１０３は＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素であり、前記パブリック情報であり、この印刷ジョブを発行したユーザ名がセットされる。この例では、「Ｎａｔｓｕ」というユーザ名がセットされている状態を表す。

図１１（ｂ）はＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅを表す図である。同図に示すＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅは、プリンタ３からＰＣ１に返されるものの一例である。同図において、１１０４は＜ｗｐｒｔ：ＪｏｂＩｄ＞要素であり、前記パブリック情報であり、ＰＣ１から発行されたＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで要求された印刷ジョブに対して、プリンタ３がこの印刷ジョブを受け付けた時に、この印刷ジョブを識別する為にプリンタ３が発行したジョブＩＤがセットされる。
この例では、「１２３４」というジョブＩＤがセットされている状態を表す。

図８はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図であり、（ａ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ、（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをそれぞれ表す。

図８（ａ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを表す図である。
同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔは、ＰＣ１からプリンタ３に発行されるものの一例である。同図において、８０１は＜ｗｐｒｔ：Ｎａｍｅ＞要素であり、前記パブリック情報であり、その値としてｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎがセットされている。

図８（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを表す図である。同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅは、プリンタ３からＰＣ１に返されるものの一例である。プリンタ３は、ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎがセットされた＜ｗｐｒｔ：Ｎａｍｅ＞要素８０１を含むＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受け取った時、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅでｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎをＰＣ１に返す。同図において、８０６は、ＡＢＣ社のＷＳＤを利用したＰｒｉｎｔ Ｓｅｒｖｉｃｅの名前空間を名前空間名ａｎｓと定義している記述である。名前空間名ａｎｓの有効範囲内は、ＡＢＣ社のＷＳＤを利用したＰｒｉｎｔ Ｓｅｒｖｉｃｅで定義されているプライベート情報である。以降の図においても、名前空間名ａｎｓは同様な取り扱いとなり、名前空間名ａｎｓの有効範囲内は、ＡＢＣ社のＷＳＤを利用したＰｒｉｎｔ Ｓｅｒｖｉｃｅで定義されているプライベート情報を表す。８０３は＜ｗｐｒｔ：ＥｌｅｍｅｎｔＤａｔａ＞要素であり、前記パブリック情報であり、Ｎａｍｅ属性として前記パブリック情報のｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎがセットされている。これは、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅが、＜ｗｐｒｔ：Ｎａｍｅ＞要素８０１で指定されたｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎを含んでいることを表す。８０５は＜ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ＞要素であり、前記パブリック情報であり、プリンタ３に搭載されている機能等に関する情報が、この中に含まれている。８０４は＜ｗｐｒｔ：ＤｅｖｉｃｅＩｄ＞要素であり、前記パブリック情報であり、ＩＥＥＥ １２８４−２０００のＤｅｖｉｃｅ ＩＤで定義されたデータ（文字列）がセットされている。これは、プリンタ３のＤｅｖｉｃｅ ＩＤを表す。

この例では、「ＭＦＧ：ＡＢＣ；ＣＭＤ：ＡＢＣＣｏｍｍａｎｄ；ＭＤＬ：Ｋｍｍｎ；ＣＬＳ：ＰＲＩＮＴＥＲ；ＤＥＳ：ＡＢＣ Ｋｍｍｎ；ＶＥＲ：１．００；ＩＮＦＯ：０００；」というＤｅｖｉｃｅ ＩＤがセットされている状態を表す。８０２は＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素であり、前記プライベート情報であり、プリンタ３が複数印刷ジョブ制御機能を備えるプリンタであるか否かを表す。この複数印刷ジョブ制御機能とは、そのプリンタが複数の印刷ジョブを受け付けることができ、その内の１つの印刷ジョブを処理して印刷を実行することができる、という機能である。プリンタがこの機能を備える場合は「ｔｒｕｅ」が、この機能を備えない場合は「ｆａｌｓｅ」が、この要素にセットされる。この例では、「ｔｒｕｅ」がセットされている状態を表す。

図９はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図であり、（ａ）は予約要求であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ、（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをそれぞれ表す。
図９（ａ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを表す図である。

同図は本発明の特徴を最もよく表す図の内の１つである。同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔは、ＰＣ１からプリンタ３に発行されるものの一例である。同図において、９０３は＜ｗｐｒｔ：Ｎａｍｅ＞要素であり、前記パブリック情報であり、その値としてａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされている。このａｎｓ：ＡＢＣＣｏｍｍａｎｄは、前記プライベート情報である。９０４は＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素であり、前記プライベート情報であり、この中に、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９０５、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９０６、＜ａｎｓ：Ｒｅｔｒｙ＞要素９０１、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９０７、＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８が含まれている。要素９０５、９０６、９０１、９０７、９０８は全て前記プライベート情報であり、ランゲージモニタ３６がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ内のこれらの要素に、それぞれ適切な値をセットする。ランゲージモニタ３６は、図５のＳ５０３や図６のＳ６０３でスプーラ４０がＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールした時に渡される第３引数ＪｏｂＩｄにセットされている値（ジョブＩＤ）を、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９０５にセットする。スプーラ４０からランゲージモニタ３６に渡されたこのジョブＩＤは、ＰＣ１内のＯＳから発行されたものであるので、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９０５にセットされる値は、プリンタ３から発行されて＜ｗｐｒｔ：ＪｏｂＩｄ＞要素１１０４にセットされるジョブＩＤとは全く異なるものである。この例では、「５」という値がセットされている状態を表す。ＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数の仕様は次に示す通りである。
ＢＯＯＬ ＷＩＮＡＰＩ ＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（
ＨＡＮＤＬＥ ｈＰｏｒｔ，
ＬＰＷＳＴＲ ｐＰｒｉｎｔｅｒＮａｍｅ，
ＤＷＯＲＤ ＪｏｂＩｄ，
ＤＷＯＲＤ Ｌｅｖｅｌ，
ＬＰＢＹＴＥ ｐＤｏｃＩｎｆｏ
）；

− Ｐａｒａｍｅｔｅｒｓ −
ｈＰｏｒｔ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｒｔ ｈａｎｄｌｅ．
ｐＰｒｉｎｔｅｒＮａｍｅ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｉｎｔｅｒ ｔｏ ａ ｓｔｒｉｎｇ ｃｏｎｔａｉｎｉｎｇ ｔｈｅ ｐｒｉｎｔｅｒ ｎａｍｅ．
ＪｏｂＩｄ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ，ｓｐｏｏｌｅｒ−ａｓｓｉｇｎｅｄ ｊｏｂ ｉｄｅｎｔｉｆｉｅｒ．Ｌｅｖｅｌ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｖａｌｕｅ ｉｎｄｉｃａｔｉｎｇ ｔｈｅ ｔｙｐｅ ｏｆ ｓｔｒｕｃｔｕｒｅ ｐｏｉｎｔｅｄ ｔｏ ｂｙ ｐＤｏｃＩｎｆｏ．Ｐｏｓｓｉｂｌｅ ｖａｌｕｅｓ ａｒｅ ａｓ ｆｏｌｌｏｗｓ：
Ｌｅｖｅｌ ｐＤｏｃＩｎｆｏ
１ ＤＯＣ＿ＩＮＦＯ＿１
２ ＤＯＣ＿ＩＮＦＯ＿２
ｐＤｏｃＩｎｆｏ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｉｎｔｅｒ ｔｏ ａ ＤＯＣ＿ＩＮＦＯ＿１ ｏｒ ＤＯＣ＿ＩＮＦＯ＿２ ｓｔｒｕｃｔｕｒｅ．Ｔｈｅｓｅ ｓｔｒｕｃｔｕｒｅｓ ａｒｅ ｄｅｓｃｒｉｂｅｄ ｉｎ ｔｈｅ Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＳＤＫ ｄｏｃｕｍｅｎｔａｔｉｏｎ．

− Ｒｅｔｕｒｎ Ｖａｌｕｅ −
Ｉｆ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｓｕｃｃｅｅｄｓ，ｔｈｅ ｆｕｎｃｔｉｏｎ ｓｈｏｕｌｄ ｒｅｔｕｒｎ ＴＲＵＥ．Ｏｔｈｅｒｗｉｓｅ ｉｔ ｓｈｏｕｌｄ ｒｅｔｕｒｎ ＦＡＬＳＥ．

ランゲージモニタ３６とポートモニタ３７のインタフェースであるＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の仕様は次に示す通りである。

ＢＯＯＬ ＷＩＮＡＰＩ ＰＭ＿ＷｒｉｔｅＰｏｒｔ（
ＨＡＮＤＬＥ ｈＰｏｒｔ，
ＬＰＢＹＴＥ ｐＢｕｆｆｅｒ，
ＤＷＯＲＤ ｃｂＢｕｆ，
ＬＰＤＷＯＲＤ ｐｃｂＷｒｉｔｔｅｎ
）；

− Ｐａｒａｍｅｔｅｒｓ −
ｈＰｏｒｔ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｒｔ ｈａｎｄｌｅ．
ｐＢｕｆｆｅｒ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｉｎｔｅｒ ｔｏ ａ ｂｕｆｆｅｒ ｃｏｎｔａｉｎｉｎｇ ｄａｔａ ｔｏ ｂｅ ｗｒｉｔｔｅｎ ｔｏ ｔｈｅ ｐｏｒｔ．
ｃｂＢｕｆ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｓｉｚｅ，ｉｎ ｂｙｔｅｓ， ｏｆ
ｐＢｕｆｆｅｒ．
ｐｃｂＷｒｉｔｔｅｎ：Ｃａｌｌｅｒ−ｓｕｐｐｌｉｅｄ ｐｏｉｎｔｅｒ ｔｏ ａ ｌｏｃａｔｉｏｎ ｔｏ ｒｅｃｅｉｖｅ ｔｈｅ ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｓｕｃｃｅｓｓｆｕｌｌｙ ｗｒｉｔｔｅｎ ｔｏ ｔｈｅ ｐｏｒｔ．

− Ｒｅｔｕｒｎ Ｖａｌｕｅ −
Ｉｆ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｓｕｃｃｅｅｄｓ，ｔｈｅ ｆｕｎｃｔｉｏｎ ｓｈｏｕｌｄ ｒｅｔｕｒｎ ＴＲＵＥ． Ｏｔｈｅｒｗｉｓｅ ｉｔ ｓｈｏｕｌｄ ｒｅｔｕｒｎ ＦＡＬＳＥ．

ポートモニタ３７は、図５のＳ５１５や図１６のＳ１６１１（図２１の（ａ）のステップＳ２１０２）において、ＷＳＤを制御するＷＳＤＡＰＩｓのＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）をコールするが、この関数の引数として参照できる図１１に示す＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素１１０２、＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素１１０３、＜ｗｐｒｔ：ＪｏｂＩｄ＞要素１１０４にセットされている値は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の引数として渡されない為、ランゲージモニタ３６がこれらの要素１１０２、１１０３、１１０４にセットされている値を参照したり、ランゲージモニタ３６がこれらの値を変更したりすることはできない。同じ理由により、ランゲージモニタ３６が、ポートモニタ３７から発行されるＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーションを使って、ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに前記プライベート情報である要素９０５、９０６、９０１、９０７、９０８を追加することもできない。

＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９０６には、プリンタ３が印刷ジョブ要求の予約を受け付けた時に発行する印刷予約ＩＤがセットされる。この例では、プリンタ３から印刷予約ＩＤがまだ発行されていないので、「Ｎｏｎｅ」という値がセットされている状態を表す。ランゲージモニタ３６は、ＰＣ１がプリンタ３に印刷ジョブ要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データをプリンタ３に初めて送信しようとする時の初期値として、「Ｎｏｎｅ」を＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９０６にセットする。それ以外の場合は、プリンタ３からＰＣ１に最後に送られてきたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２にセットされている値を、ランゲージモニタ３６がｌｍＲｅｃｅｉｖｅｄに保存しておき、ランゲージモニタ３６がこの値を＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９０６にセットする。＜ａｎｓ：Ｒｅｔｒｙ＞要素９０１には、ＰＣ１がプリンタ３に発行する印刷ジョブ要求のリトライ回数がセットされる。この例では、ＰＣ１がプリンタ３に印刷ジョブ要求を初めて送信するケースを表す「０」という値がセットされている状態を表す。ランゲージモニタ３６は、ＰＣ１がプリンタ３に印刷ジョブ要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データの送信を試みる度に、このリトライ回数を１ずつ更新して、その値を＜ａｎｓ：Ｒｅｔｒｙ＞要素９０１にセットする。＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９０７には、ＰＣ１のＯＳのバージョンがセットされる。ランゲージモニタ３６は、ＯＳのＡＰＩであるＧｅｔＶｅｒｓｉｏｎＥｘ（ ）関数をコールして、その引数で返されるＯＳのバージョン情報を、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９０７にセットする。この例では、ＯＳがＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａであることを表す「６．０」という値がセットされている状態を表す。プリンタ３は、この＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９０７にセットされている値を確認し、ＰＣのＯＳがＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａの場合と、それ以外のＯＳの場合とで、制御を切り換えることが可能である。例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａから将来のＷｉｎｄｏｗｓ（登録商標） ＯＳにかけて、ＷＳＤのプロトコル等のタイミングや制御に変更が入った場合、プリンタ３がそれに合わせてＷＳＤのプロトコル等のタイミングや制御を切り換えることにより、ＰＣにインストールされているＯＳ毎に最適化された安定した制御を行うことができ、誤動作等を防止することができる。＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８には、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行する時の日時がセットされる。ランゲージモニタ３６は、ＯＳのＡＰＩをコールして、日付と時刻を取得し、この日付と時刻を用いて＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８に日時をセットする。この例では、「２００９−０１−０１Ｔ００：０８：００」という値がセットされている状態を表す。ネットワーク４内に接続されているＰＣ、プリンタ、様々なデバイスの状況に応じて、複数のＰＣ（ＰＣ１、ＰＣ２及びその他のＰＣ（不図示））からプリンタ３に対して順に発行されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを、プリンタ３が発行された順に受信するとは限らない。その為、プリンタ３は＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８をもとに、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを処理する順序を決定し、その順序に従って、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する応答として、その発行元のＰＣに対して図９（ｂ）で後述するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを返す。

図９（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを表す図である。同図は本発明の特徴を最もよく表す図の内の１つである。同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅは、ＰＣ１からプリンタ３に発行されるものの一例である。プリンタ３は、ａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされた＜ｗｐｒｔ：Ｎａｍｅ＞要素９０３を含むＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受け取った時、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅでａｎｓ：ＡＢＣＣｏｍｍａｎｄをＰＣ１に返す。同図において、９０９は＜ｗｐｒｔ：ＥｌｅｍｅｎｔＤａｔａ＞要素であり、前記パブリック情報であり、Ｎａｍｅ属性として前記プライベート情報のａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされている。これは、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅが、＜ｗｐｒｔ：Ｎａｍｅ＞要素９０３で指定されたａｎｓ：ＡＢＣＣｏｍｍａｎｄを含んでいることを表す。９１０は＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素であり、前記プライベート情報であり、この中に、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９１１、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２、＜ａｎｓ：Ｒｅｔｒｙ＞要素９０２、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９１３、＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９１４が含まれている。要素９１１、９１２、９０２、９１３、９１４は全て前記プライベート情報である。プリンタ３は、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９０５にセットされている値をそのまま＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素９１１にセットする。この例では、「５」という値がセットされている状態を表す。プリンタ３は、図１３で後述するように＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素９１２に適切な値をセットする。この例では、「０００００２０２」という値がセットされている状態を表す。プリンタ３は、＜ａｎｓ：Ｒｅｔｒｙ＞要素９０１にセットされている値を確認し、「０」がセットされている場合は、新規に発行された印刷ジョブに対するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔであると判断する。「０」以外の値がセットされている場合は、プリンタ３が予約を受け付けた印刷ジョブの再開始要求に対するＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔであると判断する。プリンタ３は、＜ａｎｓ：Ｒｅｔｒｙ＞要素９０１にセットされていた値をそのまま＜ａｎｓ：Ｒｅｔｒｙ＞要素９０２にセットする。この例では、ランゲージモニタ３６が、ＰＣ１がプリンタ３に印刷ジョブ要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データをプリンタ３に初めて送信しようとしたケースを表す「０」という値がセットされている状態を表す。＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９１３は、ＰＣ（ＰＣ１）のＯＳのバージョン情報を表す。プリンタ３は、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９０７にセットされていた値をそのまま＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素９１３にセットする。この例では、ＯＳがＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａであることを表す「６．０」という値がセットされている状態を表す。＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９１４には、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを発行する時の日時がセットされる。プリンタ３は、内部に装備されているリアルタイムクロックから日付と時刻を取得し、この日付と時刻を用いて＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９１４に日時をセットする。この例では、「２００９−０１−０１Ｔ００：０８：０１」という値がセットされている状態を表す。ＰＣ１は、＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８と＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９１４との時間差から、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行してからＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受信する迄の時間を取得することができる。ＰＣ１は、これを利用してネットワーク４の通信速度やトラフィックを計算して予想することができ、この時間をもとにＷＳＤのプロトコルの通信やタイミングの制御を最適化することができる。また、ＰＣ１はＡＰＩを使ってＯＳ内部のタイマーをコールし、このタイマーから計算されたＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの発行からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅの返信を受け取る迄の時間と、前記＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９０８と＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素９１４との時間差から計算された時間を比較することもできる。この比較結果をもとに、ＰＣ１はプリンタ３のリアルタイムクロックの日付や時刻を補正したり、ＰＣ１内の日付や時刻を補正したりすることができる。図９（ａ）の説明の中で前述した通り、ポートモニタ３７は、図５のＳ５１５や図６のＳ１６１１（図２１の（ａ）のステップＳ２１０２）において、ＷＳＤを制御するＷＳＤＡＰＩｓのＣｒｅａｔｅＰｒｉｎｔＪｏｂ（ ）をコールするが、この関数の引数として参照できる図１１に示す＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素１１０２、＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素１１０３、＜ｗｐｒｔ：ＪｏｂＩｄ＞要素１１０４にセットされている値は、ＰＭ＿ＷｒｉｔｅＰｏｒｔ（ ）関数の引数として渡されない為、ランゲージモニタ３６がこれらの要素１１０２、１１０３、１１０４にセットされている値を参照したり、ランゲージモニタ３６がこれらの値を変更したりすることはできない。同じ理由により、ランゲージモニタ３６が、ポートモニタ３７から発行されるＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーションを使って、ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅから前記プライベート情報である要素９１１、９１２、９０２、９１３、９１４を参照することもできない。

図１０はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの内容を表す図であり、（ａ）は予約要求であるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ、（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをそれぞれ表す。

図１０（ａ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを表す図である。同図は本発明の特徴を最もよく表す図の内の１つである。同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔは、ＰＣ１からプリンタ３に発行されるものの一例である。同図において、図９（ａ）と同様な内容に関しては、その詳細説明を省略する。
１００１は＜ｗｐｒｔ：Ｎａｍｅ＞要素であり、前記パブリック情報であり、その値としてａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされている。このａｎｓ：ＡＢＣＣｏｍｍａｎｄは、前記プライベート情報である。１００２は＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素であり、前記プライベート情報であり、この中に、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素１００３、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素１００４、＜ａｎｓ：Ｒｅｔｒｙ＞要素１００５、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素１００６、＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素１００７が含まれている。要素１００３、１００４、１００５、１００６、１００７は全て前記プライベート情報であり、ランゲージモニタ３６がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ内のこれらの要素に、それぞれ適切な値をセットする。ランゲージモニタ３６は、図５のＳ５０３や図６のＳ６０３でスプーラ４０がＬＭ＿ＳｔａｒｔＤｏｃＰｏｒｔ（ ）関数をコールした時に渡される第３引数ＪｏｂＩｄにセットされている値を、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素１００３にセットする。この例では、「５」という値がセットされている状態を表す。＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素１００４には、プリンタ３が印刷ジョブ要求の予約を受け付けた時に発行する印刷予約ＩＤがセットされる。この例では、プリンタ３がこの印刷ジョブ要求の予約を既に受け付けていて、受け付けた時に発行された「０００００２０２」という値がセットされている状態を表す。＜ａｎｓ：Ｒｅｔｒｙ＞要素１００５には、ＰＣ１がプリンタ３に発行する印刷ジョブ要求のリトライ回数がセットされる。この例では、ＰＣ１がプリンタ３に印刷ジョブ要求を１回目のリトライとして送信するケースを表す「１」という値がセットされている状態を表す。ランゲージモニタ３６は、ＰＣ１がプリンタ３に印刷ジョブ要求を発行する為のトリガとなる、最初の印刷制御コマンドで構成された印刷データの送信を試みる度に、このリトライ回数を１ずつ更新して、その値を＜ａｎｓ：Ｒｅｔｒｙ＞要素１００５にセットする。＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素１００６には、ＰＣ１のＯＳのバージョンがセットされる。この例では、ＯＳがＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａであることを表す「６．０」という値がセットされている状態を表す。＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素１００７には、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行する時の日時がセットされる。この例では、「２００９−０１−０１Ｔ００：０８：０４」という値がセットされている状態を表す。

図１０（ｂ）はＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを表す図である。同図は本発明の特徴を最もよく表す図の内の１つである。同図に示すＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅは、ＰＣ１からプリンタ３に発行されるものの一例である。プリンタ３は、ａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされた＜ｗｐｒｔ：Ｎａｍｅ＞要素１００１を含むＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受け取った時、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅでａｎｓ：ＡＢＣＣｏｍｍａｎｄをＰＣ１に返す。同図において、図９（ｂ）と同様な内容に関しては、その詳細説明を省略する。１００８は＜ｗｐｒｔ：ＥｌｅｍｅｎｔＤａｔａ＞要素であり、前記パブリック情報であり、Ｎａｍｅ属性として前記プライベート情報のａｎｓ：ＡＢＣＣｏｍｍａｎｄがセットされている。これは、このＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅが、＜ｗｐｒｔ：Ｎａｍｅ＞要素１００１で指定されたａｎｓ：ＡＢＣＣｏｍｍａｎｄを含んでいることを表す。１００９は＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素であり、前記プライベート情報であり、この中に、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素１０１０、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素１０１１、＜ａｎｓ：Ｒｅｔｒｙ＞要素１０１２、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素１０１３、＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素１０１４が含まれている。要素１０１０、１０１１、１０１２、１０１３、１０１４は全て前記プライベート情報である。プリンタ３は、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素１００３にセットされている値をそのまま＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素１０１０にセットする。この例では、「５」という値がセットされている状態を表す。プリンタ３は、図１３で後述するように＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素１０１１に適切な値をセットする。この例では、「０００００２０２」という値がセットされている状態を表す。プリンタ３は、＜ａｎｓ：Ｒｅｔｒｙ＞要素１００５にセットされていた値をそのまま＜ａｎｓ：Ｒｅｔｒｙ＞要素１０１２にセットする。この例では、「１」という値がセットされている状態を表す。プリンタ３は、＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素１００６にセットされていた値をそのまま＜ａｎｓ：ＯＳＶｅｒｓｉｏｎ＞要素１０１３にセットする。この例では、「６．０」という値がセットされている状態を表す。プリンタ３は、内部に装備されているリアルタイムクロックから日付と時刻を取得し、この日付と時刻を用いて＜ａｎｓ：ＤａｔｅＴｉｍｅ＞要素１０１４に日時をセットする。この例では、「２００９−０１−０１Ｔ００：０８：０５」という値がセットされている状態を表す。

図１８はＳｔａｒｔＪｏｂの内容を表す図であり、（ａ）はジョブ予約であるＳｔａｒｔＪｏｂＲｅｑｕｅｓｔ、（ｂ）はＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅをそれぞれ表す。

図１８（ａ）はＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを表す図である。これは印刷ジョブの開始要求である。同図に示すＳｔａｒｔＪｏｂＲｅｑｕｅｓｔは、ＰＣ５からプリンタ３に発行されるものの一例である。同図において、１８０１は、ＡＢＣ社のＩＨＶの独自プロトコルを利用したＡＢＣ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの名前空間を名前空間名ｌａｎｓと定義している記述である。この名前空間を、図８の８０６に記載されているＡＢＣ社のＷＳＤを利用したＰｒｉｎｔ Ｓｅｒｖｉｃｅの名前空間と比較した場合、バージョンを表す情報が、それぞれｖ００２とｖ１００となっており、ＡＢＣ社のＩＨＶの独自プロトコルを利用したＡＢＣ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの名前空間の方がバージョンが古いものであることがわかる。名前空間名ｌａｎｓの有効範囲内は、ＡＢＣ社のＡＢＣ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅで定義されているプライベート情報である。以降の図においても、名前空間名ｌａｎｓは同様な取り扱いとなり、名前空間名ｌａｎｓの有効範囲内は、ＡＢＣ社のＡＢＣ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅで定義されているプライベート情報を表す。１８０２は＜ｗｓａ：Ａｃｔｉｏｎ＞要素であり、この情報がＳｔａｒｔＪｏｂオペレーションであることを表す。１８０３は＜ｌａｎｓ：ＳｔａｒｔＪｏｂＲｅｑｕｅｓｔ＞要素であり、この中に、＜ｌａｎｓ：ＣｏｍｐｕｔｅｒＮａｍｅ＞要素１８０４、＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８０５、＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８０６、＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７が含まれている。要素１８０３、１８０４、１８０５、１８０６、１８０７は全て前記プライベート情報であり、ランゲージモニタがそれぞれ適切な値をセットする。１８０４は＜ｌａｎｓ：ＣｏｍｐｕｔｅｒＮａｍｅ＞要素であり、この情報の発行元のコンピュータ名として、その値にＰＣ５がセットされている。＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８０５には、プリンタ３が印刷ジョブ要求の予約を受け付けた時に発行するタイムスタンプがセットされる。この例では、プリンタ３からタイムスタンプがまだ発行されていないので、「Ｎｏｎｅ」という値がセットされている状態を表す。ランゲージモニタは、ＰＣ５がプリンタ３に印刷ジョブの開始要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データをプリンタ３に初めて送信しようとする時の初期値として、「Ｎｏｎｅ」を＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８０５にセットする。それ以外の場合は、プリンタ３からＰＣ５に最後に送られてきたＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅの＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８１０にセットされている値を、ランゲージモニタが保存しておき、ランゲージモニタがこの値を＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８０５にセットする。

＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８０６には、ＰＣ５がプリンタ３に発行する印刷ジョブの開始要求のリトライ回数がセットされる。この例では、ＰＣ５がプリンタ３に印刷ジョブの開始要求を初めて送信するケースを表す「０」という値がセットされている状態を表す。ランゲージモニタは、ＰＣ５がプリンタ３に印刷ジョブの開始要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データの送信を試みる度に、このリトライ回数を１ずつ更新して、その値を＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８０６にセットする。＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７には、このＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを発行する時の日時がセットされる。ランゲージモニタは、ＯＳのＡＰＩをコールして、日付と時刻を取得し、この日付と時刻を用いて＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７に日時をセットする。この例では、「２００９−０１−０１Ｔ２２：０１：３０」という値がセットされている状態を表す。ネットワーク４内に接続されているＰＣ、プリンタ、様々なデバイスの状況に応じて、複数のＰＣ（ＰＣ５及びその他のＰＣ（不図示））からプリンタ３に対して順に発行されたＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを、プリンタ３が発行された順に受信するとは限らない。その為、プリンタ３は＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７をもとに、ＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを処理する順序を決定し、その順序に従って、ＳｔａｒｔＪｏｂＲｅｑｕｅｓｔに対する応答として、その発行元のＰＣに対して図１８（ｂ）で後述するＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅを返す。

図１８（ｂ）はＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅを表す図である。同図に示すＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅは、ＰＣ５からプリンタ３に発行されるものの一例である。

プリンタ３は、図１８（ａ）に示すＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを受け取った時、ＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅをＰＣ５に返す。同図において、１８０８は＜ｌａｎｓ：ＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅ＞要素であり、この中に、＜ｌａｎｓ：ＣｏｍｐｕｔｅｒＮａｍｅ＞要素１８０９、＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８１０、＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８１１、＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８１２が含まれている。要素１８０８、要素１８０９、１８１０、１８１１、１８１２は全て前記プライベート情報である。プリンタ３は、＜ｌａｎｓ：ＣｏｍｐｕｔｅｒＮａｍｅ＞要素１８０４にセットされている値をそのまま＜ｌａｎｓ：ＣｏｍｐｕｔｅｒＮａｍｅ＞要素１８０９にセットする。この例では、「ＰＣ５」という値がセットされている状態を表す。

プリンタ３は、図１４に示す印刷キューデータベースにセットされている情報に基づいて、＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素１８１０に適切な値をセットする。この例では、「０００００３０１」という値がセットされている状態を表す。プリンタ３は、＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８０６にセットされている値を確認し、「０」がセットされている場合は、新規に発行された印刷ジョブに対するＳｔａｒｔＪｏｂＲｅｑｕｅｓｔであると判断する。「０」以外の値がセットされている場合は、プリンタ３が予約を受け付けた印刷ジョブの再開始要求に対するＳｔａｒｔＪｏｂＲｅｑｕｅｓｔであると判断する。

プリンタ３は、＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８０６にセットされていた値をそのまま＜ｌａｎｓ：Ｒｅｔｒｙ＞要素１８１１にセットする。この例では、ランゲージモニタが、ＰＣ５がプリンタ３に印刷ジョブの開始要求を発行する為のトリガとなる、印刷制御コマンドで構成された印刷データの先頭データをプリンタ３に初めて送信しようとしたケースを表す「０」という値がセットされている状態を表す。＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８１２には、このＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅを発行する時の日時がセットされる。プリンタ３は、内部に装備されているリアルタイムクロックから日付と時刻を取得し、この日付と時刻を用いて＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８１２に日時をセットする。この例では、「２００９−０１−０１Ｔ２２：０１：３１」という値がセットされている状態を表す。ＰＣ５は、＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７と＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８１２との時間差から、ＳｔａｒｔＪｏｂＲｅｑｕｅｓｔを発行してからＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅを受信する迄の時間を取得することができる。ＰＣ５は、これを利用してネットワーク４の通信速度やトラフィックを計算して予想することができ、この時間をもとにＩＨＶの独自プロトコルの通信やタイミングの制御を最適化することができる。また、ＰＣ５はＡＰＩを使ってＯＳ内部のタイマーをコールし、このタイマーから計算されたＳｔａｒｔＪｏｂＲｅｑｕｅｓｔの発行からＳｔａｒｔＪｏｂＲｅｓｐｏｎｓｅの返信を受け取る迄の時間と、前記＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８０７と＜ｌａｎｓ：ＤａｔｅＴｉｍｅ＞要素１８１２との時間差から計算された時間を比較することもできる。この比較結果をもとに、ＰＣ５はプリンタ３のリアルタイムクロックの日付や時刻を補正したり、ＰＣ５内の日付や時刻を補正したりすることができる。

図１４はプリンタ３が受け付けて予約した印刷ジョブ要求を管理する印刷キューデータベースを表す図である。同図は本発明の特徴を最もよく表す図の内の１つである。図１４（ａ）は、複数の印刷ジョブを受け付けることができず、１つの印刷ジョブだけを受け付けることができるようなプリンタにおいて、このプリンタ内に装備された、ＷＳＤだけを利用したネットワーク印刷を制御する為の印刷キューデータベースを表す図である。図１４（ｂ）は、４つの印刷ジョブを受け付けることができるようなプリンタにおいて、このプリンタ内に装備された、ＷＳＤとＩＨＶの独自プロトコルの両プロトコルが混在したネットワーク印刷を制御する為の印刷キューデータベースを表す図である。図１４（ｃ）は、図１４（ｂ）の印刷キューデータベースを、さらに拡張して、ＵＳＢインタフェース７を介した印刷ジョブや印刷ジョブ要求も同時に管理することができる、ネットワーク印刷とローカル（ＵＳＢ）印刷を統合して制御する為の印刷キューデータベースを表す図である。図１４（ａ）、図１４（ｂ）、図１４（ｃ）において、「Ｎｕｌｌ」はデータが存在しない空領域であることを表し、「−」はデータが不定（利用不可）であることを表す。

図１４（ａ）において、「Ｎｏ．」欄は、実行中の印刷ジョブ、または予約されている印刷ジョブ要求の順番を表す。１は現在印刷を実行中の印刷ジョブ、２〜８は印刷ジョブ要求の予約を表す。２〜８において、２は次に印刷を実行する予定の最優先の印刷ジョブ要求の予約、８は最後に印刷を実行する予定の最も優先順位の低い印刷ジョブ要求の予約を表す。本実施例では、プリンタ３が実行できる印刷ジョブの数が１つ、予約できる印刷ジョブ要求の数が７つの、合計８つの印刷キューの例を表している。図１４（ｂ）、図１４（ｃ）において、「Ｎｏ．」欄は、実行中の印刷ジョブ、または予約されている印刷ジョブ要求の順番を表す。１は現在印刷を実行中の印刷ジョブ、２〜４は受け付けが完了してジョブＩＤ（「ｗｐｒｔ：ＪｏｂＩｄ」欄参照）が発行済みで印刷待機中の印刷ジョブ、５〜８は印刷ジョブ要求の予約を表す。２〜４において、２は次に印刷を実行する予定の最優先の印刷ジョブ、３は２の次に優先順位の高い印刷ジョブ、４は３の次に優先順位の高い印刷ジョブを表す。５〜８において、５は４の次に優先順位の高い印刷ジョブ要求の予約、８は最後に印刷を実行する予定の最も優先順位の低い印刷ジョブ要求の予約を表す。本実施例では、プリンタ３が実行できる印刷ジョブの数が１つ、受け付けることができる印刷ジョブの数が前記実行できる印刷ジョブも含めて合計４つ、予約できる印刷ジョブ要求の数が４つの、合計８つの印刷キューの例を表している。図１４（ａ）、図１４（ｂ）、図１４（ｃ）において、「Ｃｏｍｐｕｔｅｒ Ｎａｍｅ」欄は、印刷ジョブ要求を発行したＰＣのコンピュータ名を表す。「ｗｐｒｔ：ＪｏｂＮａｍｅ」欄は、＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素（例えば１１０２）にセットされている印刷ジョブ名を表す。「ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ」欄は、＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素（例えば１１０３）にセットされているユーザ名を表す。「ｗｐｒｔ：ＪｏｂＩｄ」欄は、＜ｗｐｒｔ：ＪｏｂＩｄ＞要素（例えば１１０４）にセットされている、プリンタ３から発行されたジョブＩＤを表す。例えば、図１４（ａ）のＮｏ．１の行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には、「８８８」というジョブＩＤがセットされている。これは、プリンタ３がこの印刷ジョブの印刷を実行していて、ジョブＩＤを発行済みの状態であることを表している。図１４（ａ）のＮｏ．２〜８の行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には、「Ｎｕｌｌ」がセットされている。これは、プリンタ３がこの印刷ジョブ要求の予約を受け付けただけで、印刷が実行されていないので、ジョブＩＤを発行していない状態であることを表している。例えば、図１４（ｂ）のＮｏ．１の行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には、「８８８」というジョブＩＤがセットされている。これは、プリンタ３がこの印刷ジョブの印刷を実行していて、ジョブＩＤを発行済みの状態であることを表している。図１４（ｂ）のＮｏ．２〜４の行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には、「８８８」、「−」、「８９０」、「１００１」という値がそれぞれセットされている。これは、プリンタ３がこれらの印刷ジョブを受け付けていて、ジョブＩＤを発行済みの状態であることを表している。図１４（ｂ）のＮｏ．５〜８の行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には、「−」、「Ｎｕｌｌ」、「Ｎｕｌｌ」、「−」という値がそれぞれセットされている。これは、プリンタ３がこれらの印刷ジョブ要求の予約を受け付けただけで、印刷が実行されていないので、ジョブＩＤを発行していない状態であることを表している。尚、図１４（ｂ）のＮｏ．２、５、８行の「ｗｐｒｔ：ＪｏｂＩｄ」欄には「−」がセットされているが、これは、ＩＨＶの独自プロトコルにおいては、＜ｗｐｒｔ：ＪｏｂＩｄ＞要素が存在しないので、不定（利用不可）であることを表している。

図１４（ａ）、図１４（ｂ）、図１４（ｃ）の「ａｎｓ：ＳｐｌＪｏｂＩｄ」欄は、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素（例えば９０５、１００３）にセットされている、スプーラ４０から発行されたジョブＩＤを表す。例えば、１台のＰＣからあるユーザが同じドキュメントを何度も繰り返して連続印刷するようなケースにおいて、スプーラ４０がこれらの印刷ジョブを複数のスレッド等により並列処理できる場合、これら複数の印刷ジョブ要求、すなわち複数のＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔ内の＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素（例えば１１０２）にセットされている印刷ジョブ名と＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素（例えば１１０３）にセットされているユーザ名が、各印刷ジョブ要求間で同一の印刷ジョブ名とユーザ名になってしまう為、これらの印刷ジョブ要求を区別することができない、という問題がある。このような問題に対して、スプーラ４０から発行されたジョブＩＤを印刷キューデータベース内に保持する情報に含めることで、これらの印刷ジョブを識別することができ、前記問題を解決することができる。図１４（ａ）、図１４（ｂ）、図１４（ｃ）の「Ｔｉｍｅ」欄は、ＰＣから発行された印刷ジョブ要求または印刷ジョブ要求の予約確認要求を、プリンタ３が受け付けた時刻を表すタイムカウント値を表す。図１４（ａ）において、「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ」欄は、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にセットされている印刷予約ＩＤを表す。図１４（ｂ）において、「Ｐｒｏｔｏｃｏｌ」欄は、ＰＣとプリンタ３との間のネットワーク通信に使用される通信プロトコルを表す。本実施例では、ＷＳＤあるいはＩＨＶの独自プロトコル（ＩＨＶ Ｎａｔｉｖｅ）の何れかがセットされる。図１４（ｃ）において、「Ｐｒｏｔｏｃｏｌ」欄は、ＰＣとプリンタ３との間のネットワーク通信またはＰＣ１とプリンタ３との間のローカル（ＵＳＢ）通信に使用される通信プロトコルを表す。本実施例では、ＷＳＤ、ネットワーク用のＩＨＶの独自プロトコル（ＩＨＶ Ｎａｔｉｖｅ）、あるいはローカル（ＵＳＢ）用のＩＨＶの独自プロトコル（ＩＨＶ Ｎａｔｉｖｅ ２）の何れかがセットされる。図１４（ｂ）、図１４（ｃ）の「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ／ｌａｎｓ：ＴｉｍｅＳｔａｍｐ」欄は、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にセットされている印刷予約ＩＤ、またはプリンタ３がＩＨＶの独自プロトコルを使ってＰＣに発行する＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素（例えば１８１０）にセットされているタイムスタンプを表す。このタイムスタンプは、ＩＨＶの独自プロトコルにおいて、前記印刷予約ＩＤに相当するものであり、それぞれの印刷ジョブ要求に対して一意の値として割り振られるものである。言い換えれば、プリンタ３は、このタイムスタンプを、ＷＳＤの＜ｗｐｒｔ：ＪｏｂＩｄ＞要素のジョブＩＤに相当するようなジョブＩＤとして利用することもできる。この実施例のように印刷予約ＩＤとタイムスタンプを同じ形式で定義することで、印刷ジョブ要求の予約を一元管理して、容易に管理及び制御することができる。ランゲージモニタ（ランゲージモニタ３６）は、ＩＨＶの独自プロトコルを制御する為のＡＰＩｓを利用することにより、ＩＨＶの独自プロトコルを利用してプリンタ３に任意の情報を送信したり、プリンタ３から任意の情報を受信したりすることができる。従って、ＩＨＶの独自プロトコルを利用した場合、ＷＳＤのように、図１６のＳ１６１１（図２１の（ａ）のステップＳ２１０２）のＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーションと図１６のＳ１６２１（図２０のステップＳ２０１６）のＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓオペレーションを組み合わせた２つ（複数）のオペレーションによって１つの印刷ジョブ要求を発行して、印刷ジョブ要求の予約を行うような仕組みは必要ない。その為、ＩＨＶの独自プロトコルを利用した場合、ＷＳＤで例えると図５のＳ５１５のＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーションに相当するような、印刷ジョブの開始要求だけによって１つの印刷ジョブ要求を発行することができる。すなわち、図１８に示すＳｔａｒｔＪｏｂオペレーションだけによって、１つの印刷ジョブ要求を発行することができる。

例えば、ＰＣ１にはＷｉｎｄｏｗｓ（登録商標） ＶｉｓｔａのＯＳがインストールされていて、ネットワーク４上の他のＰＣにはＷｉｎｄｏｗｓ（登録商標） ＸＰのＯＳがインストールされている場合、それぞれのＰＣから発行される印刷ジョブとして、ＷＳＤのプロトコルを利用したものとＩＨＶの独自プロトコルを利用したものとが混在することになる。このような、複数のプロトコルの印刷ジョブが混在している環境においても、図１４（ｂ）のような印刷キューデータベースを利用することで、各ＰＣから発行された印刷ジョブが発行された順序に従って正しく印刷される、優れた周辺装置制御システムを実現することができる。

さらに、ＵＳＢインタフェース７を使った印刷においても、ＵＳＢ用のＩＨＶの独自プロトコルを実装し、図１４（ｃ）のような印刷キューデータベースを利用することで、各ＰＣからネットワーク４を介して発行された印刷ジョブ、及びＰＣ１からＵＳＢインタフェース７を介して発行されて印刷ジョブが、発行された順序に従って正しく印刷される、優れた周辺装置制御システムを実現することもできる。

図１５はＰＣのポートとＤｅｖｉｃｅ ＩＤのＩＮＦＯ情報の関係を示す表である。図１５（ａ）では、プリンタ３がＵＳＢインタフェース７とネットワーク４を完全に排他的に制御する例を示す。図１５（ａ）において、「印刷中のＰＣ１のポート」欄は、ＰＣ１が印刷中の時に、その印刷に使用しているポートの情報を表す。「印刷待ちのＰＣ２のポート」欄は、ＰＣ２が印刷待ちの時に、その待機している印刷に使用するポートの情報を表す。「印刷中のＰＣ１のポート」欄、「印刷待ちのＰＣ２のポート」欄において、ＵＳＢは、ＵＳＢインタフェース７を介して印刷するＵＳＢポートを、ＷＳＤは、ネットワーク４を介してＷＳＤで印刷するネットワークポートを、ＩＨＶ Ｎａｔｉｖｅは、ネットワーク４を介してＩＨＶの独自プロトコルで印刷するネットワークポートを、それぞれ表す。「Ｄｅｖｉｃｅ ＩＤのＩＮＦＯ」欄は、Ｄｅｖｉｃｅ ＩＤのＩＮＦＯ情報にセットされている値を表し、ＰＣ１以外のＰＣ（この例ではＰＣ２）から見た場合のプリンタ３の状態を表す情報を含んでいる。プリンタ３が電源オンでスタンバイ（オンライン）状態の時は、ＩＮＦＯ：０００というように「０００」がＤｅｖｉｃｅ ＩＤのＩＮＦＯ情報にセットされる。以下において、Ｄｅｖｉｃｅ ＩＤのＩＮＦＯ情報にセットされる値とその意味は次に示す通りである。
ＩＮＦＯ：意味
０００ プリンタ３が電源オンでスタンバイ（オンライン）状態
１０１ 他のインタフェースで使用中の状態
１０２ 他のコンピュータで使用中の状態
ＰＣ２はこれらの情報をもとに、プリンタ３の状態をモニタして表示するステータスモニタのようなアプリケーション上に、次のようなメッセージを表示してユーザの操作性を向上することができる。
ＩＮＦＯ：メッセージ
０００ オンライン
１０１ 他のインタフェースで使用中
１０２ 他のコンピュータで使用中
ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＵＳＢで「印刷待ちのＰＣ２のポート」がＩＨＶ Ｎａｔｉｖｅの場合、ＰＣ２がプリンタ３からＩＨＶの独自プロトコルを用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０１」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＵＳＢで「印刷待ちのＰＣ２のポート」がＷＳＤの場合、ＰＣ２がプリンタ３からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）を用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０１」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＩＨＶ Ｎａｔｉｖｅで「印刷待ちのＰＣ２のポート」がＩＨＶ Ｎａｔｉｖｅの場合、ＰＣ２がプリンタ３からＩＨＶの独自プロトコルを用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。

ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＩＨＶ Ｎａｔｉｖｅで「印刷待ちのＰＣ２のポート」がＷＳＤの場合、ＰＣ２がプリンタ３からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）を用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＷＳＤで「印刷待ちのＰＣ２のポート」がＩＨＶ Ｎａｔｉｖｅの場合、ＰＣ２がプリンタ３からＩＨＶの独自プロトコルを用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＷＳＤで「印刷待ちのＰＣ２のポート」がＷＳＤの場合、ＰＣ２がプリンタ３からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）を用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。

図１５（ａ）では、ＰＣ１からプリンタ３にＵＳＢインタフェース７を介して印刷中に、ＰＣ２上のステータスモニタに「他のインタフェースで使用中」というようなメッセージを表示することができたが、このケースにおいて、ＰＣ２上のステータスモニタに表示されるメッセージとして最も適切なメッセージは「他のコンピュータで使用中」である。

図１５（ｂ）では、プリンタ３がＵＳＢインタフェース７とネットワーク４を包括的に制御する例を示す。図１５（ｂ）において、図１５（ａ）と同様な内容に関する説明は省略する。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＵＳＢで「印刷待ちのＰＣ２のポート」がＩＨＶ Ｎａｔｉｖｅの場合、ＰＣ２がプリンタ３からＩＨＶの独自プロトコルを用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ＰＣ１からプリンタ３で印刷している時、「印刷中のＰＣ１のポート」がＵＳＢで「印刷待ちのＰＣ２のポート」がＷＳＤの場合、ＰＣ２がプリンタ３からＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）を用いてＤｅｖｉｃｅ ＩＤを取得すると、ＩＮＦＯ情報に「１０２」がセットされたＤｅｖｉｃｅ ＩＤがプリンタ３から返される。ここでは一例として、ＵＳＢインタフェース７を介してプリンタ３を制御する印刷制御コマンド及びＤｅｖｉｃｅ ＩＤと、ネットワーク４を介してプリンタ３を制御する印刷制御コマンド及びＤｅｖｉｃｅ ＩＤを同一コマンドとし、そのコマンドが含まれるプロトコルだけを変えることで、このような制御を実現している。

図１２はプリンタ３におけるＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を表すフローチャートである。同図は本発明の特徴を最もよく表す図の内の１つである。図１２のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。プリンタ３は、起動時にｎｅｗ＿ｊｏｂフラグを「０」で初期化しているものとする。ＰＣ（ＰＣ１）からプリンタ３にＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔ（例えば図１１（ａ））が発行されて、プリンタ３がこれを受け付けると、同図のステップＳ１２０１が開始される。プリンタ３は、前記ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを受信した時（Ｓ１２０２）、プリンタ３に内蔵されているタイマーから時刻や経過時間を計算可能なカウント値を取得してＴｉｍｅ１に保存する（Ｓ１２０３）。

このカウント値の単位は「秒」である。プリンタ３は、前記ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔから＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素１１０２にセットされている印刷ジョブ名と、＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素１１０３にセットされているユーザ名を取得する（Ｓ１２０４）。プリンタ３はＰＣ１のコンピュータ名（Ｃｏｍｐｕｔｅｒ Ｎａｍｅ）を取得する（Ｓ１２０５）。本実施例では、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得し、このＩＰアドレスをもとにコンピュータ名を取得する。尚、本実施例では説明をわかりやすくする為に、このようにＩＰアドレスからコンピュータ名を取得して、このコンピュータ名を用いてＰＣを特定して各処理を行っているが、ＩＰアドレスを用いてＰＣを特定して各処理を行ってもよい。プリンタ３は、前記印刷ジョブ名と前記ユーザ名と前記コンピュータ名を一時的に保存する（Ｓ１２０９）。プリンタ３は、前記印刷ジョブ名、前記ユーザ名、前記コンピュータ名をもとに、図１４に示す印刷キューデータベース内に既にステップＳ１２０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブの印刷ジョブ要求の予約が存在する可能性が有るかを確認する（Ｓ１２０６）。図１４に示す印刷キューデータベース内に前記印刷ジョブ要求の予約が既に存在する可能性が有る場合ステップＳ１２１１へ進み、存在する可能性が無い場合ステップＳ１２０８へ進む（Ｓ１２０７）。ステップＳ１２０８において、図１４に示す印刷キューデータベース内にステップＳ１２０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブより優先順位の高い他の印刷ジョブ要求の予約が有る場合ステップＳ１２１７へ進み、無い場合ステップＳ１２１０へ進む。ステップＳ１２１０において、プリンタ３は、図１４に示す印刷キューデータベースにステップＳ１２０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブの印刷ジョブ要求を登録する。プリンタ３は、ステップＳ１２０２で受信した印刷ジョブ要求ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、この印刷ジョブを受け付けて実行することを表す応答としてＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅ（例えば図１１（ｂ））をＰＣ（ＰＣ１）に返し（Ｓ１２１８）、ＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を終了する（Ｓ１２２１）。ステップＳ１２１１において、プリンタ３はｎｅｗ＿ｊｏｂフラグの値を確認し、「１」がセットされている場合ステップＳ１２１９へ進み、それ以外（「０」がセットされている）場合ステップＳ１２１２へ進む。ステップＳ１２１２において、プリンタ３は、ステップＳ１２０３で保存されたＴｉｍｅ１から図１３のステップＳ１３０３で保存されたＴｉｍｅ２を減算して、プリンタ３が図１３のステップＳ１３０２でＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受信してからステップＳ１２０２でＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを受信するまでの経過時間（受信時間差）を計測する。この経過時間が５秒を超えている場合ステップＳ１２１９へ進み、５秒以内の場合ステップＳ１２２０へ進む。ステップＳ１２２０において、プリンタ３は、ステップＳ１２０９で保存した前記印刷ジョブ名と前記ユーザ名と前記コンピュータ名をもとに、図１４に示す印刷キューデータベース内でこれらの情報と同じ情報を持つ印刷ジョブ要求の予約を検索する。そして、この印刷キューデータベース内から「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ」欄にセットされている印刷予約ＩＤと「ａｎｓ：ＳｐｌＪｏｂＩｄ」欄にセットされているスプーラ４０から発行されたジョブＩＤを取得して、一時的に保存する。プリンタ３は、図１３のステップＳ１３０９で保存されている＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素（例えば９０４、１００２）に含まれている情報の中から＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素にセットされている印刷予約ＩＤ（例えば１００４）と、＜ａｎｓ：ＳｐｌＪｏｂＩｄ＞要素にセットされているスプーラ４０から発行されたジョブＩＤ（例えば１００３）を取得する（Ｓ１２１３）。

プリンタ３は、ステップＳ１２１３で取得した印刷予約ＩＤとスプーラ４０から発行されたジョブＩＤを、ステップＳ１２２０で一時的に保存した印刷予約ＩＤ及びスプーラ４０から発行されたジョブＩＤとそれぞれ比較する（Ｓ１２１４）。さらに、プリンタ３は、ステップＳ１２２０で一時的に保存した印刷予約ＩＤをもとに印刷キューデータベースから取得した印刷ジョブ名とユーザ名とコンピュータ名を、ステップＳ１２０９で一時的に保存した印刷ジョブ名、ユーザ名及びコンピュータ名とそれぞれ比較する（Ｓ１２１４）。プリンタ３は、前記比較対象の全ての情報を比較した結果、全ての比較対象情報がそれぞれ一致した場合ステップＳ１２１６へ進み、少なくとも１つ以上の一致しない情報が存在した場合ステップＳ１２１７へ進む（Ｓ１２１５）。ステップＳ１２１６において、プリンタ３は図１４に示す印刷キューデータベースを確認し、ステップＳ１２０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブより優先順位の高い他の印刷ジョブ要求の予約がこの印刷キューデータベース内に有る場合ステップＳ１２１９へ進み、無い場合ステップＳ１２１０へ進む。ステップＳ１２１７において、プリンタ３はｎｅｗ＿ｊｏｂフラグに「１」をセットする。ステップＳ１２１９において、プリンタ３は、ステップＳ１２０２で受信した印刷ジョブ要求ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、この印刷ジョブを受け付けることができなかったことを表すＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ（ＰＣ１）に返し、ＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を終了する（Ｓ１２２１）。

図１３はプリンタ３におけるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を表すフローチャートである。同図は本発明の特徴を最もよく表す図の内の１つである。図１３のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。ＰＣ（ＰＣ１）からプリンタ３にＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ（例えば図８（ａ）、図９（ａ）、図１０（ａ））が発行されて、プリンタ３がこれを受け付けると、同図のステップＳ１３０１が開始される。プリンタ３は、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受信した後（Ｓ１３０２）、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔから＜ｗｐｒｔ：Ｎａｍｅ＞要素（例えば８０１、９０３、１００１）にセットされている値を確認する（Ｓ１３０４）。ステップＳ１３０４において、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの中に複数の＜ｗｐｒｔ：Ｎａｍｅ＞要素が存在する場合があるので、プリンタ３は取得した全ての＜ｗｐｒｔ：Ｎａｍｅ＞要素にセットされている値を一時的に保存しておく。＜ｗｐｒｔ：Ｎａｍｅ＞要素にセットされている値として、ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎが見つかった場合ステップＳ１３０６へ進み、見つからなかった場合ステップＳ１３０８へ進む（Ｓ１３０５）。ステップＳ１３０６において、プリンタ３は＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２に「ｔｒｕｅ」をセットし、ステップＳ１３０８へ進む。ステップＳ１３０８において、プリンタ３は、ステップＳ１３０４で一時的に保存された＜ｗｐｒｔ：Ｎａｍｅ＞要素にセットされている全ての値を確認し、ａｎｓ：ＡＢＣＣｏｍｍａｎｄが見つかった場合ステップＳ１３０３へ進み、見つからなかった場合ステップＳ１３１９へ進む。ステップＳ１３０３において、プリンタ３は内蔵されているタイマーから時刻や経過時間を計算可能なカウント値を取得してＴｉｍｅ２に保存する。このカウント値の単位は「秒」である。ステップＳ１３０９において、プリンタ３は前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ内の＜ａｎｓ：ＡＢＣＣｏｍｍａｎｄ＞要素（例えば９０４、１００２）に含まれている全ての情報を取得して保存する。プリンタ３はｎｅｗ＿ｊｏｂフラグの値を確認し、「１」がセットされている場合ステップＳ１３０７へ進み、それ以外（「０」がセットされている）場合ステップＳ１３１１へ進む（Ｓ１３２０）。ステップＳ１３０７において、Ｔｉｍｅ２から図１２のステップＳ１２０３で保存されたＴｉｍｅ１を減算して、図１２のステップＳ１２０２でプリンタ３がＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを受信してからステップＳ１３０２でプリンタ３がＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受信するまでの経過時間（受信時間差）を計測する。この経過時間が５秒を超えている場合ステップＳ１３２１へ進み、５秒以内の場合ステップＳ１３１０へ進む。ステップＳ１３１０において、プリンタ３は、＜ａｎｓ：Ｒｅｔｒｙ＞要素（例えば９０１、１００５）にセットされている値を確認し、この値が「０」の場合ステップＳ１３１７へ進み、「０」以外（実際には０より大きい整数）の場合ステップＳ１３１１へ進む。ステップＳ１３１７において、プリンタ３は図１７に示す印刷予約ＩＤの発行処理を実行する。プリンタ３は、図１７で＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にセットされた値を確認し、「Ｎｏｎｅ」の場合ステップＳ１３２１へ進み、「Ｎｏｎｅ」ではない場合ステップＳ１３１８へ進む。ステップＳ１３１８において、ステップＳ１３１７を経由して来た場合、プリンタ３は、図１７のステップＳ１７０４で新規に発行した印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）をもとに、図１４に示す印刷キューデータベースに新規の印刷ジョブ要求の予約として各情報を登録して、印刷キューデータベースを更新する。ステップＳ１３１５（ＮＯ）を経由して来た場合、プリンタ３は、既存の印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）をもとに、図１４に示す印刷キューデータベースに既存の印刷ジョブ要求の予約として各情報を登録して、印刷キューデータベースを更新する。また、ステップＳ１３１８において、プリンタ３は、「Ｔｉｍｅ」欄にセットされているタイムカウント値をＴｉｍｅ２に保存されている値で更新する。ステップＳ１３２１において、プリンタ３はｎｅｗ＿ｊｏｂフラグを「０」で初期化する。プリンタ３は、ステップＳ１３０６でセットされた情報、図１７のステップＳ１７０５でセットされた情報、図１４に示す印刷キューデータベース内にセットされている情報等を用いて、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅに各情報をセットして、ステップＳ１３０２で受信したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する応答として、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ（ＰＣ１）に返す（Ｓ１３１９）。そして、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を終了する（Ｓ１３２２）。ステップＳ１３１１において、プリンタ３は＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素にセットされている印刷予約ＩＤ（例えば１００４）を取得する。プリンタ３は、図１４に示す印刷キューデータベース内の「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ」欄または「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ／ｌａｎｓ：ＴｉｍｅＳｔａｍｐ」欄に、この印刷予約ＩＤが存在するか否かを確認する（Ｓ１３１２）。プリンタ３が、この印刷ジョブ要求の予約を表す印刷予約ＩＤを図１４に示す印刷キューデータベース内で発見した場合ステップＳ１３１４へ進み、発見しなかった場合ステップＳ１３１７へ進む（Ｓ１３１３）。ステップＳ１３１４において、プリンタ３は、図１４に示す印刷キューデータベースから前記印刷予約ＩＤで予約されている印刷ジョブ予約の「Ｔｉｍｅ」欄にセットされているタイムカウント値を取得し、ステップＳ１３０３で保存されたＴｉｍｅ２からこのタイムカウント値を減算して、最後にこの印刷ジョブ予約が更新された時からの経過時間を計測する。プリンタ３は、この経過時間が既定時間（ここでは２０秒に設定）を超える場合ステップＳ１３１６へ進み、既定時間以内の場合ステップＳ１３１８へ進む（Ｓ１３１５）。ステップＳ１３１６において、プリンタ３は、図１４に示す印刷キューデータベース内において、この印刷ジョブ要求の印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）を一旦削除し、この印刷ジョブ要求をその印刷キューデータベース内の最後尾に移動して、最も優先順位の低い印刷ジョブ要求の予約となるように変更し、ステップＳ１３１７へ進む。

図１２のステップＳ１２１２、図１３のステップＳ１３０７において、一定時間の経過を判断する値として５秒の固定のタイムアウト値を設定したが、これらの例に限られることなく、プリンタ３の使用環境やユーザが使用するネットワークの環境に応じて、例えば、３秒、８秒、１０秒というような固定のタイムアウト値を設定したり、プリンタ３の表示部２１のタッチパネルや操作部２０のボタン操作により、使用環境に応じた任意の適切な値を設定したりするように構成してもよい。また、プリンタ３がネットワーク４上のＰＣをモニタし、その数に応じてネットワークの混雑状況を把握し、その混雑状況から最適なタイムアウト値を設定するように構成してもよい。さらに、図１２のステップＳ１２１２におけるタイムアウト値と、図１３のステップＳ１３０７におけるタイムアウト値を、同一の値ではなく、それぞれ異なる値としてもよい。この場合、例えば、図１２のステップＳ１２１２におけるタイムアウト値を５秒とし、図１３のステップＳ１３０７におけるタイムアウト値を３秒とする、というような実施例となる。

図１７はプリンタ３における印刷予約ＩＤの発行の処理を表すフローチャートである。

同図は本発明の特徴を最もよく表す図の内の１つである。図１７のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。プリンタ３が図１３のステップＳ１３１７の印刷予約ＩＤの発行処理を実行すると、同図のステップＳ１７０１が開始される。プリンタ３は、図１４に示す印刷キューデータベースの空領域の状況を確認し（Ｓ１７０２）、空領域が有る場合ステップＳ１７０４へ進み、空領域が無い場合ステップＳ１７０５へ進む（Ｓ１７０３）。ステップＳ１７０４において、プリンタ３は印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）を新規に発行し、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にこの印刷予約ＩＤをセットし、印刷予約ＩＤの発行処理を終了して（Ｓ１７０６）、図１３のＳ１３２３へ進む。ステップＳ１７０４で発行される印刷予約ＩＤは、プリンタ３内で管理されるものであり、プリンタ３内で一意に決定される値である。ステップＳ１７０５において、プリンタ３は＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）に「Ｎｏｎｅ」をセットし、印刷予約ＩＤの発行処理を終了して（Ｓ１７０６）、図１３のＳ１３２３へ進む。このように、例えば、図１４に示す印刷キューデータベースに新規の印刷ジョブ要求の予約を受け付けることが可能な空領域が存在しない場合、プリンタ３は、ＰＣ（ＰＣ１）からの印刷ジョブ要求の予約を受け付けることができない。この場合、図６に示すコーリングシーケンスに従って、ＰＣ（ＰＣ１）が印刷ジョブ要求を再度発行してくるので、プリンタ３は、図１４に示す印刷キューデータベースに新規の印刷ジョブ要求を受け付けることが可能な空領域が存在した時に、この印刷ジョブ要求の予約を受け付ける。

図１９はプリンタ３における印刷キューデータベースの更新割り込みの処理を表すフローチャートである。図１９のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。プリンタ３に内蔵されているタイマーにより、１８０秒毎にこの割り込みが発生し、同図に示す処理が実行される。プリンタ３に内蔵されているタイマーにより、この割り込み処理が発生すると、同図のステップＳ１９０１が開始される。プリンタ３は内蔵されているタイマーから時刻や経過時間を計算可能なカウント値を取得してＴｉｍｅ３に保存する。このカウント値の単位は「秒」である（Ｓ１９０２）。プリンタ３は、図１４に示す印刷キューデータベース内の印刷ジョブ要求の予約の中から、最も優先順位の高いものの内容をピックアップして確認する（Ｓ１９０３）。プリンタ３は、ステップＳ１９０３でピックアップした印刷ジョブ要求の予約から「Ｔｉｍｅ」欄にセットされているタイムカウント値を取得する（Ｓ１９０４）。プリンタ３は、Ｔｉｍｅ３からステップＳ１９０４で取得したタイムカウント値を減算する（Ｓ１９０５）。プリンタ３は、ステップＳ１９０５の減算結果が既定時間（６０秒）を超える場合ステップＳ１９０７へ進み、既定時間（６０秒）以内の場合ステップＳ１９０８へ進む（Ｓ１９０６）。ステップＳ１９０７において、プリンタ３は、ステップＳ１９０３でピックアップした印刷ジョブ要求の予約を図１４に示す印刷キューデータベース内から削除し、ステップＳ１９１０へ進む。この時、プリンタ３は、この印刷ジョブ要求の印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）も削除する。ステップＳ１９０８において、プリンタ３は、ステップＳ１９０５の減算結果が既定時間（２０秒）を超える場合ステップＳ１９０９へ進み、既定時間（２０秒）以内の場合ステップＳ１９１０へ進む。ここで、この既定時間（２０秒）は、図１３のステップＳ１３１５で設定している２０秒と同一の値としている。ステップＳ１９０９において、プリンタ３は、図１４に示す印刷キューデータベース内において、ステップＳ１９０３でピックアップした印刷ジョブ要求の予約の印刷予約ＩＤ（ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ）を一旦削除する。そして、この印刷ジョブ要求をその印刷キューデータベース内の最後尾に移動して、最も優先順位の低い印刷ジョブ要求の予約となるように変更し、ステップＳ１９１０へ進む。ステップＳ１９１０において、プリンタ３が、全ての印刷ジョブ要求の予約の確認を完了した場合印刷キューデータベースの更新割り込みの処理を終了し（Ｓ１９１２）、完了していない場合ステップＳ１９１１へ進む。ステップＳ１９１１において、プリンタ３は、図１４に示す印刷キューデータベース内において、ステップＳ１９０３でピックアップした印刷ジョブ要求の予約の、ピックアップした時点で次の優先順位の印刷ジョブ要求の予約に進み、ステップＳ１９０３へ戻る。尚、本実施例において、タイマー割り込みのインターバルを１８０秒としたが、この例に限られることなく、任意のインターバルを設定可能である。

また、プリンタ３の表示部２１のタッチパネルや操作部２０のボタン操作により、使用環境に応じた任意の適切な値を設定したりするように構成してもよい。

図１３のステップＳ１３１５及び図１９のステップＳ１９０８において、既定時間を２０秒の固定のタイムアウト値を設定したが、この例に限られることなく、プリンタ３の使用環境やユーザが使用するネットワークの環境に応じて、例えば、１０秒、２０秒、３０秒、６０秒というような固定のタイムアウト値を設定したり、プリンタ３の表示部２１のタッチパネルや操作部２０のボタン操作により、使用環境に応じた任意の適切な値を設定したりするように構成してもよい。また、プリンタ３がネットワーク４上のＰＣをモニタし、その数に応じてネットワークの混雑状況を把握し、その混雑状況から最適なタイムアウト値を設定するように構成してもよい。

図１９のステップＳ１９０６において、既定時間を６０秒の固定のタイムアウト値を設定したが、この例に限られることなく、プリンタ３の使用環境やユーザが使用するネットワークの環境に応じて、例えば、３０秒、６０秒、９０秒、１２０秒というような固定のタイムアウト値を設定したり、プリンタ３の表示部２１のタッチパネルや操作部２０のボタン操作により、使用環境に応じた任意の適切な値を設定したりするように構成してもよい。また、プリンタ３がネットワーク４上のＰＣをモニタし、その数に応じてネットワークの混雑状況を把握し、その混雑状況から最適なタイムアウト値を設定するように構成してもよい。

図１２、図１３、図１９において、経過時間を計算する方法としてプリンタ３に内蔵されているタイマーから取得したカウント値を利用する方法を挙げたが、この例に限られることなく、例えば、プリンタ３に内蔵されているリアルタイムクロックから取得した時刻を利用すること等によっても、実現することができる。

本実施例では周辺装置の例としてプリンタ３のようなプリンタを挙げたが、プリンタ、ＦＡＸ、スキャナ、ストレージ等を搭載したマルチファンクションプリンタ（以降、ＭＦＰと略す場合がある）にも、本発明は有効である。ＷＳＤを搭載したＭＦＰの場合、プリンタ、ＦＡＸ、スキャナのそれぞれの機能に対して、次に示すようなＷＳＤの各Ｓｅｒｖｉｃｅを割り当てることが可能である。
機能 ＷＳＤのＳｅｒｖｉｃｅ 備考
プリンタ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ プリンタ機能用
ＦＡＸ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ ＦＡＸ機能用
スキャナ Ｓｃａｎ Ｓｅｒｖｉｃｅ
ここで、各機能のＳｅｒｖｉｃｅに割り当てられているＳｅｒｖｉｃｅＩｄは、次の通
りである。
プリンタ： ＜ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ａｂｃ．ｘｘｘ／Ｐｒｉｎｔｅｒ＜／ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞
ＦＡＸ： ＜ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ａｂｃ．ｘｘｘ／Ｆａｘ＜／ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞
スキャナ： ＜ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ａｂｃ．ｘｘｘ／Ｓｃａｎｎｅｒ＜／ｗｓｄｐ：ＳｅｒｖｉｃｅＩｄ＞
プリンタ機能とＦＡＸ機能には、どちらもＰｒｉｎｔ Ｓｅｒｖｉｃｅが割り当てられていて、ＳｅｒｖｉｃｅＩＤがプリンタ機能用とＦＡＸ機能用とで異なっている。その為、プリンタ機能とＦＡＸ機能のＳｅｒｖｉｃｅＴｙｐｅは、どちらもＰｒｉｎｔｅｒＳｅｒｖｉｃｅＴｙｐｅとなる。

前述した通り、ランゲージモニタ３６は、ＷＳＤＡＰＩｓのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数を使って、ＰＣ１からプリンタ３にＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを発行して、プリンタ３からＰＣ１に返されるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅを受け取ることができる。この時、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ（ ）関数に次に示すようにＳｅｒｖｉｃｅＴｙｐｅを指定してこの関数をコールすることで、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓを利用することができる。
＜ｐｏｒｔＴｙｐｅ ｎａｍｅ＝“ＰｒｉｎｔｅｒＳｅｒｖｉｃｅＴｙｐｅ” ｗｓｅ：ＥｖｅｎｔＳｏｕｒｃｅ＝“ｔｒｕｅ”＞
＜ｏｐｅｒａｔｉｏｎ ｎａｍｅ＝“ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ”＞
＜ｉｎｐｕｔ ｍｅｓｓａｇｅ＝“ｗｐｒｔ：ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔＭｓｇ”
ｗｓａ：Ａｃｔｉｏｎ＝“ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｙｙｙｙ．ｘｘｘ／ＹＹＹＹ／ＭＭ／ｗｄｐ／ｐｒｉｎｔ／ ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓ”／＞
＜ｏｕｔｐｕｔ ｍｅｓｓａｇｅ＝“ｗｐｒｔ：ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅＭｓｇ”
ｗｓａ：Ａｃｔｉｏｎ＝“ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｙｙｙｙ．ｘｘｘ／ＹＹＹＹ／ＭＭ／ｗｄｐ／ｐｒｉｎｔ／ ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅ”／＞
＜／ｏｐｅｒａｔｉｏｎ＞
＜／ｐｏｒｔＴｙｐｅ＞
しかしながら、前記ＭＦＰの場合、プリンタ機能とＦＡＸ機能のＳｅｒｖｉｃｅＴｙｐｅはどちらもＰｒｉｎｔｅｒＳｅｒｖｉｃｅＴｙｐｅという同一のタイプである為、ＳｅｒｖｉｃｅＴｙｐｅを指定して前記関数をコールしても、プリンタ機能とＦＡＸ機能を区別してその機能に関する情報を取得することができない、という問題に直面する。このような問題に対して、例えば前記ＭＦＰの場合には、ランゲージモニタ３６がＳｅｒｖｉｃｅＩＤを指定して前記関数をコールすることで、プリンタ機能またはＦＡＸ機能を指定して、その指定した機能に関する情報をＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓを利用して取得することができる。これにより、プリンタ機能とＦＡＸ機能を備えるＭＦＰに対しても、誤動作を防止して、正確な制御が可能な周辺装置制御システムを実現することができる。

ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔはＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅにおける印刷ジョブの開始要求であり、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔはＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅにおけるプリンタ情報取得要求である。

このように、本発明では、ある一定時間（同図では５秒）以内にステップＳ１２０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔとステップＳ１３０２で受信したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ（ａｎｓ：ＡＢＣＣｏｍｍａｎｄ）のそれぞれに含まれる情報を関連付けて、１つの印刷ジョブ要求の予約として扱い、印刷キューデータベースに登録し、プリンタ３内で一意に決定される印刷予約ＩＤで印刷ジョブ要求の予約を管理することを特徴とする。つまり、印刷ジョブの開始要求とプリンタ情報取得要求というような異なる２つの要求が一定時間以内に受信された場合において、これらの要求に含まれる情報を関連付けて、１つの印刷ジョブ要求の予約として扱い、印刷キューデータベースに登録し、プリンタ３内で一意に決定される印刷予約ＩＤで印刷ジョブ要求の予約を管理することを特徴とする。これにより、複数の印刷ジョブを受け付けることができず、１つの印刷ジョブだけを受け付けることができるようなプリンタにおいても、１台または複数のＰＣから発行された複数の印刷ジョブを発行された順序通り正確に印刷することができる。

＜実施形態２＞
実施形態１では、例えば、１台のＰＣからあるユーザが同じドキュメントを何度も繰り返して連続印刷するようなケースにおいて、スプーラ４０がこれらの印刷ジョブを複数のスレッド等により並列処理できるケースを想定した。このようなケースにおいて、これら複数の印刷ジョブ要求、すなわち複数のＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔ内の＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素（例えば１１０２）にセットされている印刷ジョブ名と＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素（例えば１１０３）にセットされているユーザ名が、各印刷ジョブ要求間で同一の印刷ジョブ名とユーザ名になってしまう為、これらの印刷ジョブ要求を区別することができない、という問題があった。このような問題に対して、実施形態１では、スプーラ４０から発行されたジョブＩＤを印刷キューデータベース内に保持する情報に含めることで、これらの印刷ジョブを識別し、前記問題を解決した。そして、プリンタ３が印刷ジョブ要求の予約を一元管理する方法の中から、最も容易な方法として、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にセットされている印刷予約ＩＤ、または＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素（例えば１８１０）にセットされている、前記印刷予約ＩＤに相当するタイムスタンプを利用する例を挙げた。

他の例として、前述したような、１台のＰＣからあるユーザが同じドキュメントを何度も繰り返して連続印刷するようなケースにおいて、スプーラ４０がこれらの印刷ジョブを複数のスレッド等により並列処理することができず、優先順位の最も高い印刷ジョブを１つのスレッドでシーケンシャルに処理するケースを考える。このようなケースでは、１台のＰＣからあるユーザが同じドキュメントを何度も繰り返して連続印刷しても、スプーラ４０は、プリンタキュー３２にスタックされている印刷ジョブの中で優先順位の最も高い印刷ジョブだけを処理する。従って、例えば、ＷＳＤプロトコルだけを利用するケースを考えた場合、印刷予約ＩＤやタイムスタンプを使わなくても、図１４に示す印刷キューデータベースの中に記された次の３つの情報、
「Ｃｏｍｐｕｔｅｒ Ｎａｍｅ」欄のコンピュータ名、
「ｗｐｒｔ：ＪｏｂＮａｍｅ」欄の印刷ジョブ名、
「ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ」欄のユーザ名を使って、印刷ジョブ要求の予約を一元管理することが可能である。また、ＷＳＤプロトコルに加えて、ＩＨＶの独自プロトコルが混在するケースを考えた場合も、印刷ジョブ名とユーザ名の情報を図１８に示すＳｔａｒｔＪｏｂに加えることで、印刷予約ＩＤやタイムスタンプを使わなくても、印刷ジョブ要求の予約を一元管理することが可能である。

但し、この実施形態２で挙げた例は、スプーラ４０が複数の印刷ジョブを複数のスレッド等により並列処理することができず、優先順位の最も高い印刷ジョブを１つのスレッドでシーケンシャルに処理するケースに対してのみ有効なものである。

ＩＨＶの独自プロトコルの例としては、ネットワーク用のＩＨＶの独自プロトコル（ＩＨＶ Ｎａｔｉｖｅ）、あるいはローカル（ＵＳＢ）用のＩＨＶの独自プロトコル（ＩＨＶ Ｎａｔｉｖｅ ２）等が挙げられる。

以下、図２２〜図２４を用いて、詳細を説明する。
図２２はプリンタ３が受け付けて予約した印刷ジョブ要求を管理する印刷キューデータベースを表す図である。同図は本発明の特徴を最もよく表す図の内の１つである。同図に示す印刷キューデータベースは図１４（ｃ）をベースにしたものであるので、実施形態１において、図１４（ｃ）で既に説明した内容に関してはその説明を省略する。図２２と図１４（ｃ）を比較した場合の差異は、図１４（ｃ）には「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ／ｌａｎｓ：ＴｉｍｅＳｔａｍｐ」欄が用意されている点である。この欄には、＜ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ＞要素（例えば９１２、１０１１）にセットされている印刷予約ＩＤ、またはプリンタ３がＩＨＶの独自プロトコルを使ってＰＣに発行する＜ｌａｎｓ：ＴｉｍｅＳｔａｍｐ＞要素（例えば１８１０）にセットされているタイムスタンプを表す情報が格納される。図２２には「ａｎｓ：ＲｅｃｅｉｖｅｄＩｄ／ｌａｎｓ：ＴｉｍｅＳｔａｍｐ」欄が用意されておらず、前記印刷予約ＩＤや前記タイムスタンプを格納する必要が無い。

図２３はプリンタ３におけるＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を表すフローチャートである。同図は本発明の特徴を最もよく表す図の内の１つである。図２３のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。ＰＣ（ＰＣ１）からプリンタ３にＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔ（例えば図１１（ａ））が発行されて、プリンタ３がこれを受け付けると、同図のステップＳ２３０１が開始される。プリンタ３は、前記ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔを受信した時（Ｓ２３０２）、プリンタ３に内蔵されているタイマーから時刻や経過時間を計算可能なカウント値を取得してＴｉｍｅ１に保存する（Ｓ２３０３）。このカウント値の単位は「秒」である。プリンタ３は、前記ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔから＜ｗｐｒｔ：ＪｏｂＮａｍｅ＞要素１１０２にセットされている印刷ジョブ名と、＜ｗｐｒｔ：ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅ＞要素１１０３にセットされているユーザ名を取得する（Ｓ２３０４）。プリンタ３はＰＣ１のコンピュータ名（Ｃｏｍｐｕｔｅｒ Ｎａｍｅ）を取得する（Ｓ２３０５）。本実施例では、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得し、このＩＰアドレスをもとにコンピュータ名を取得する。尚、本実施例では説明をわかりやすくする為に、このようにＩＰアドレスからコンピュータ名を取得して、このコンピュータ名を用いてＰＣを特定して各処理を行っているが、ＩＰアドレスを用いてＰＣを特定して各処理を行ってもよい。プリンタ３は、前記印刷ジョブ名と前記ユーザ名と前記コンピュータ名を一時的に保存する（Ｓ２３０６）。プリンタ３は、前記コンピュータ名をもとに、図２２に示す印刷キューデータベース内に既にステップＳ２３０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブの印刷ジョブ要求の予約が存在するかを確認する（Ｓ２３０７）。図２２に示す印刷キューデータベース内に前記印刷ジョブ要求の予約が既に存在する場合ステップＳ２３０９へ進み、存在しない場合ステップＳ２３１３へ進む（Ｓ２３０８）。ステップＳ２３０９において、プリンタ３は、図２２に示す印刷キューデータベースから前記コンピュータ名で予約されている印刷ジョブ予約の「Ｔｉｍｅ」欄にセットされているタイムカウント値を取得し、ステップＳ２３０３で保存されたＴｉｍｅ１からこのタイムカウント値を減算して、最後にこの印刷ジョブ予約が更新された時からの経過時間を計測する。プリンタ３は、この経過時間が既定時間（ここでは２０秒に設定）を超える場合ステップＳ２３１１へ進み、既定時間以内の場合ステップＳ２３１２へ進む（Ｓ２３１０）。ステップＳ２３１１において、プリンタ３は、図２２に示す印刷キューデータベース内において、この印刷ジョブ要求をその印刷キューデータベース内の最後尾に移動して、最も優先順位の低い印刷ジョブ要求の予約となるように変更し、ステップＳ２３１２へ進む。この時、もし図２２に示す印刷キューデータベース内に空領域が無い場合、プリンタ３は、この印刷ジョブ要求の予約を破棄して、印刷キューデータベース内に印刷ジョブ要求の予約として格納しない。ステップＳ２３１２において、プリンタ３は、前記コンピュータ名をもとに、図２２に示す印刷キューデータベースに印刷ジョブ要求の予約として各情報を登録して、印刷キューデータベースを更新する。この時、プリンタ３は、「Ｔｉｍｅ」欄にセットされているタイムカウント値をＴｉｍｅ１に保存されている値で更新する。ステップＳ２３１３において、プリンタ３は、図２２に示す印刷キューデータベースにステップＳ２３０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブの印刷ジョブ要求を登録する。図２２に示す印刷キューデータベース内にステップＳ２３０２で受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブより優先順位の高い他の印刷ジョブ要求の予約が有る場合ステップＳ２３１５へ進み、無い場合ステップＳ２３１６へ進む（Ｓ２３１４）。ステップＳ２３１６において、プリンタ３は、ステップＳ２３０２で受信した印刷ジョブ要求ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、この印刷ジョブを受け付けて実行することを表す応答としてＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｓｐｏｎｓｅ（例えば図１１（ｂ））をＰＣ（ＰＣ１）に返し、ＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を終了する（Ｓ２３１７）。ステップＳ２３１５において、プリンタ３は、ステップＳ２３０２で受信した印刷ジョブ要求ＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔに対して、この印刷ジョブを受け付けることができなかったことを表すＦａｕｌｔ（ＳｅｒｖｅｒＥｒｒｏｒＮｏｔＡｃｃｅｐｔｉｎｇＪｏｂｓ）をＰＣ（ＰＣ１）に返し、ＣｒｅａｔｅＰｒｉｎｔＪｏｂの処理を終了する（Ｓ２３１７）。

図２４はプリンタ３におけるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を表すフローチャートである。同図は本発明の特徴を最もよく表す図の内の１つである。図２４のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。ＰＣ（ＰＣ１）からプリンタ３にＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔ（例えば図８（ａ））が発行されて、プリンタ３がこれを受け付けると、同図のステップＳ２４０１が開始される。プリンタ３は、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔを受信した後（Ｓ２４０２）、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔから＜ｗｐｒｔ：Ｎａｍｅ＞要素（例えば８０１）にセットされている値を確認する（Ｓ２４０３）。ステップＳ２４０３において、前記ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔの中に複数の＜ｗｐｒｔ：Ｎａｍｅ＞要素が存在する場合があるので、プリンタ３は取得した全ての＜ｗｐｒｔ：Ｎａｍｅ＞要素にセットされている値を一時的に保存しておく。＜ｗｐｒｔ：Ｎａｍｅ＞要素にセットされている値として、ｗｐｒｔ：ＰｒｉｎｔｅｒＤｅｓｃｒｉｐｔｉｏｎが見つかった場合ステップＳ２４０５へ進み、見つからなかった場合ステップＳ２４０７へ進む（Ｓ２４０４）。ステップＳ２４０５において、プリンタ３は＜ａｎｓ：ＭｕｌｔｉｐｌｅＪｏｂｓＣｏｎｔｒｏｌ＞要素８０２に「ｔｒｕｅ」をセットし、内蔵されているタイマーから時刻や経過時間を計算可能なカウント値を取得してＴｉｍｅ２に保存する（Ｓ２４０６）。このカウント値の単位は「秒」である。ステップＳ２４０７において、プリンタ３はＰＣ１のコンピュータ名（Ｃｏｍｐｕｔｅｒ Ｎａｍｅ）を取得する。プリンタ３は、前記コンピュータ名をもとに、図２２に示す印刷キューデータベース内にこのコンピュータ名のＰＣから図２３のステップＳ２３０２で既に受信したＣｒｅａｔｅＰｒｉｎｔＪｏｂＲｅｑｕｅｓｔで開始要求された印刷ジョブの印刷ジョブ要求の予約が存在するかを確認する（Ｓ２４０８）。図２２に示す印刷キューデータベース内に前記印刷ジョブ要求の予約が既に存在する場合ステップＳ２４１０へ進み、存在しない場合ステップＳ２４１４へ進む（Ｓ２４０９）。ステップＳ２４１０において、プリンタ３は、図２２に示す印刷キューデータベースから前記コンピュータ名で予約されている印刷ジョブ予約の「Ｔｉｍｅ」欄にセットされているタイムカウント値を取得し、ステップＳ２４０６で保存されたＴｉｍｅ２からこのタイムカウント値を減算して、最後にこの印刷ジョブ予約が更新された時からの経過時間を計測する。プリンタ３は、この経過時間が既定時間（ここでは２０秒に設定）を超える場合ステップＳ２４１２へ進み、既定時間以内の場合ステップＳ２４１３へ進む（Ｓ２４１１）。ステップＳ２４１２において、プリンタ３は、図２２に示す印刷キューデータベース内において、この印刷ジョブ要求をその印刷キューデータベース内の最後尾に移動して、最も優先順位の低い印刷ジョブ要求の予約となるように変更し、ステップＳ２４１３へ進む。この時、もし図２２に示す印刷キューデータベース内に空領域が無い場合、プリンタ３は、この印刷ジョブ要求を破棄して、印刷キューデータベース内に印刷ジョブ要求の予約として格納しない。ステップＳ４１３において、プリンタ３は、前記コンピュータ名をもとに、図２２に示す印刷キューデータベースに印刷ジョブ要求の予約として各情報を登録して、印刷キューデータベースを更新する。この時、プリンタ３は、「Ｔｉｍｅ」欄にセットされているタイムカウント値をＴｉｍｅ２に保存されている値で更新する。プリンタ３は、ステップＳ２４０２で受信したＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｑｕｅｓｔに対する応答として、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓＲｅｓｐｏｎｓｅをＰＣ（ＰＣ１）に返し（Ｓ２４１４）、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓの処理を終了する（Ｓ２４１５）。

＜実施形態３＞
本実施形態における図５、図６、図７、図１６にそれぞれ示す各コーリングシーケンス、図１２、図１３、図１７、図１９、図２０、図２１、図２３、図２４にそれぞれ示す各フローチャートの実行によって実現できる各機能が、外部からインストールされるプログラムによって、情報処理装置によって実現されるようにしてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやフレキシブルディスク等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群が情報処理装置や周辺装置に供給される場合でも、本発明は適用されるものである。

このように、本発明は、以下の処理を実行することによっても達成される。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ等を用いることができる。

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

本発明の実施の形態では、プリンタの例としてカラーインクジェットプリンタを使用したが、この例に限られることなく、例えば、モノクロＬＢＰ等の任意のプリンタを使用することができる。

本発明の実施の形態では情報処理装置としてパーソナルコンピュータを想定したが、この例に限られることなく、例えばＤＶＤプレーヤー、ゲーム、セットトップボックス、インターネット家電等、同様な使用方法が可能な任意の情報処理装置（端末）に対して実現することができ、有効である。

本発明の実施の形態では、周辺装置としてプリンタを例示しているが、周辺装置として他に、複写機、ファクシミリ、スキャナ、デジタルカメラ、及びこれらの複合機能を備える装置等のいずれかが、本発明の適用対象となり得る。

本発明の実施の形態では、ＯＳに例としてＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａと同等のＯＳを使用したが、これらのＯＳに限られることなく、任意のＯＳを使用することができる。
本発明の実施の形態では、ネットワーク４の構成例としてＥｔｈｅｒｎｅｔ（登録商標）を用いたが、この例に限られることなく、他の任意のネットワーク構成であってもよい。

本発明の実施の形態では、ＰＣ１、ＰＣ２、ＰＣ５とプリンタ３との間のインタフェースとして、ＵＳＢやＥｔｈｅｒｎｅｔ（登録商標）を用いたが、このインタフェースに限られることなく、例えば、無線ＬＡＮ、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈ等の任意のインタフェースを用いるようにしてもよい。

本発明の実施の形態では、Ｗｅｂサービスのプロトコルの例としてＷＳＤを挙げたが、この例に限られることなく、例えばＩＨＶの独自プロトコル等の任意のプロトコルを用いるようにしてもよい。
本発明の実施の形態では、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得し、このＩＰアドレスをもとにコンピュータ名取得して、このコンピュータ名を用いてＰＣを特定している。この例に限られることなく、例えば、ＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得して、このＩＰアドレスを用いてＰＣを特定する等の、他の手段を利用してＰＣを特定してもよい。このようにＩＰアドレスを利用することで、ＷＳＤのプロトコル内で２バイトコードを取り扱うような考慮が不要となり、プログラムを簡素化でき、コーディングミスを最小限に抑えることができるので、品質を向上することができる。

本発明の実施の形態では、印刷ジョブの開始要求であるＣｒｅａｔｅＰｒｉｎｔＪｏｂオペレーション（図１６のＳ１６１１（図２１の（ａ）のステップＳ２１０２））と、プリンタに関する情報を取得する為に利用されるＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓオペレーション（図１６のＳ１６２１（図２０のステップＳ２０１６））を利用して、プリンタが印刷ジョブ要求の予約を受け付ける例を挙げた。この例に限られることなく、例えば、ＧｅｔＰｒｉｎｔｅｒＥｌｅｍｅｎｔｓオペレーションの代わりに、印刷ジョブに関する情報を取得する為に利用されるＧｅｔＪｏｂＥｌｅｍｅｎｔｓオペレーション等のＷＳＤのＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎで定義されている他のオペレーションを利用してもよい。

Claims (22)

1. ネットワークを介して接続された情報処理装置と周辺装置からなる周辺装置制御システムであって、
   前記情報処理装置は、ジョブ要求と予約要求を前記周辺装置に対して発行し、
   前記周辺装置は、前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して前記ジョブ要求の予約を受け付けることを特徴とする周辺装置制御システム。
2. ネットワークを介して接続された情報処理装置と周辺装置からなる周辺装置制御システムであって、
   前記情報処理装置にインストールされ前記情報処理装置を制御する前記オペレーティングシステムはジョブ要求を前記周辺装置に対して発行し、
   前記情報処理装置にインストールされ前記周辺装置を制御するドライバは予約要求を前記周辺装置に対して発行し、
   前記周辺装置は、前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して前記ジョブ要求の予約を受け付けることを特徴とする周辺装置制御システム。
3. ネットワークを介して接続された、第１のプロトコルを使ってジョブを制御する第１の情報処理装置と、第２のプロトコルを使ってジョブを制御する第２の情報処理装置と、周辺装置からなる周辺装置制御システムであって、
   前記第１の情報処理装置は前記第１のプロトコルの第１のジョブ要求と予約要求を前記周辺装置に対して発行し、
   前記第２の情報処理装置は前記第２のプロトコルの第２のジョブ要求を前記周辺装置に対して発行し、
   前記周辺装置は、前記第１のジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、前記受信時間差が第１の既定時間以内の場合、第１の予約ＩＤを発行して前記第１のジョブ要求の予約を受け付け、前記第２のジョブ要求を受信した場合、第２の予約ＩＤを発行して前記第２のジョブ要求の予約を受け付けることを特徴とする周辺装置制御システム。
4. 前記周辺装置は、前記ジョブ要求で要求されたジョブを実行できない場合、前記ジョブ要求に対して拒絶応答を前記情報処理装置に返すとともに、前記受信時間差が前記第１の既定時間以内の場合、前記予約要求に対して前記予約ＩＤを前記情報処理装置に返して前記ジョブ要求の予約を受け付けることを特徴とする請求項１または２記載の周辺装置制御システム。
5. 前記周辺装置は、前記ジョブ要求の発行元である前記情報処理装置を識別する情報と、前記ジョブ要求に含まれるジョブ名と、前記ジョブ要求に含まれるユーザ名と、前記予約ＩＤと、前記予約ＩＤが割り当てられている前記ジョブ要求の予約を最後に更新した時刻またはタイムカウント値をデータベースに保存して、前記ジョブ要求の予約を管理することを特徴とする請求項１または２記載の周辺装置制御システム。
6. 前記予約要求は、前記予約ＩＤと、前記時刻または前記タイムカウント値と、前記情報処理装置を制御するオペレーティングシステムが発行するジョブＩＤを含み、前記周辺装置は前記ジョブＩＤを前記データベースに保存して、前記ジョブ要求の予約を管理することを特徴とする請求項５記載の周辺装置制御システム。
7. 前記受信時間差が前記第１の既定時間を超えた場合、前記周辺装置は、前記データベースから前記ジョブの予約を削除することを特徴とする請求項５記載の周辺装置制御システム。
8. 前記予約ＩＤが割り当てられている前記ジョブ要求の予約を最後に更新してから第２の既定時間以内に、前記予約の更新が図られた場合、前記周辺装置は、前記データベースの時刻またはタイムカウント値を更新して、前記ジョブ要求の予約を保持することを特徴とする請求項５記載の周辺装置制御システム。
9. 前記予約ＩＤが割り当てられている前記ジョブ要求の予約を最後に更新してから第２の既定時間以内に、前記予約の更新が図られなかった場合、前記周辺装置は、前記データベースから前記ジョブの予約を削除することを特徴とする請求項５記載の周辺装置制御システム。
10. 前記ジョブ要求をジョブの開始を表すオペレーションで構成し、前記予約要求をそれ以外のオペレーションで構成することを特徴とする請求項１または２記載の周辺装置制御システム。
11. 前記予約要求を、周辺装置の情報を取得するオペレーション、またはジョブの情報を取得するオペレーションで構成することを特徴とする請求項１０記載の周辺装置制御システム。
12. 前記情報処理装置を識別する情報を、前記情報処理装置のＩＰアドレスまたは名前で構成することを特徴とする請求項５記載の周辺装置制御システム。
13. ネットワークを介して接続された、情報処理装置と、周辺装置からなる周辺装置制御システムにおける周辺装置制御方法であって、
    前記情報処理装置が、ジョブ要求と予約要求を前記周辺装置に対して発行するステップと、
    前記周辺装置が、前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測ステップと、
    前記周辺装置が、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して前記ジョブ要求の予約を受け付けるステップと
    を備えることを特徴とする周辺装置制御方法。
14. ネットワークを介して接続された情報処理装置と周辺装置からなる周辺装置制御システムにおける周辺装置制御方法であって、
    前記情報処理装置にインストールされ前記情報処理装置を制御するオペレーティングシステムが、ジョブ要求を前記周辺装置に対して発行するステップと、
    前記情報処理装置にインストールされ前記周辺装置を制御するドライバが、予約要求を前記周辺装置に対して発行するステップと、
    前記周辺装置が、前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測ステップと、
    前記周辺装置が、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して、前記ジョブ要求の予約を受け付けるステップと
    を備えることを特徴とする周辺装置制御方法。
15. ネットワークを介して接続された、第１のプロトコルを使ってジョブを制御する第１の情報処理装置と、第２のプロトコルを使ってジョブを制御する第２の情報処理装置と、周辺装置からなる周辺装置制御システムにおける周辺装置制御方法であって、
    前記第１の情報処理装置が、前記第１のプロトコルの第１のジョブ要求と予約要求を前記周辺装置に対して発行するステップと、
    前記第２の情報処理装置が、前記第２のプロトコルの第２のジョブ要求を前記周辺装置に対して発行するステップと、
    前記周辺装置が、前記第１のジョブ要求と前記予約要求の受信時間差を計測する第１の計測ステップと、
    前記周辺装置が、前記受信時間差が第１の既定時間以内の場合、第１の予約ＩＤを発行して前記第１のジョブ要求の予約を受け付け、前記第２のジョブ要求を受信した場合、第２の予約ＩＤを発行して前記第２のジョブ要求の予約を受け付けるステップと
    を備えることを特徴とする周辺装置制御方法。
16. 情報処理装置とネットワークを介して接続された周辺装置であって、
    情報処理装置が発行するジョブ要求と予約要求を受信する受信手段と、
    前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、
    前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して、前記ジョブ要求の予約を受け付けることを特徴とする周辺装置。
17. 情報処理装置とネットワークを介して接続された周辺装置であって、
    前記情報処理装置にインストールされ前記情報処理装置を制御するオペレーティングシステムが発行するジョブ要求と、前記情報処理装置にインストールされ前記周辺装置を制御するドライバが発行する予約要求を受信する受信手段と、
    前記ジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、
    前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行して前記ジョブ要求の予約を受け付けることを特徴とする周辺装置。
18. 情報処理装置とネットワークを介して接続された周辺装置であって、
    第１の情報処理装置が発行する第１のプロトコルの第１のジョブ要求と予約要求と、第２の情報処理装置が発行する第２のプロトコルの第２のジョブ要求を受信する受信手段と、
    前記第１のジョブ要求と前記予約要求の受信時間差を計測する第１の計測手段を備え、
    前記受信時間差が第１の既定時間以内の場合、第１の予約ＩＤを発行して前記第１のジョブ要求の予約を受け付け、前記第２のジョブ要求を受信した場合、第２の予約ＩＤを発行して前記第２のジョブ要求の予約を受け付けることを特徴とする周辺装置。
19. コンピュータを、請求項１６乃至１８のいずれか記載の周辺装置として機能させるため
    のプログラム。
20. 周辺装置とネットワークを介して接続された情報処理装置であって、
    ジョブ要求と予約要求を周辺装置に対して発行し、
    前記周辺装置に、前記ジョブ要求と前記予約要求の受信時間差を計測させ、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行させて前記ジョブ要求の予約を受け付けさせることを特徴とする情報処理装置。
21. 周辺装置とネットワークを介して接続された情報処理装置であって、
    前記情報処理装置にインストールされ前記情報処理装置を制御するオペレーティングシステムが、ジョブ要求を周辺装置に対して発行し、
    前記情報処理装置にインストールされ前記周辺装置を制御するドライバが、予約要求を前記周辺装置に対して発行し、
    前記周辺装置に、前記ジョブ要求と前記予約要求の受信時間差を計測させ、前記受信時間差が第１の既定時間以内の場合、予約ＩＤを発行させて前記ジョブ要求の予約を受け付けさせることを特徴とする情報処理装置。
22. コンピュータを、請求項２０または２１記載の情報処理装置として機能させるためのプログラム。

Images