JP2012048501A - 周辺装置制御システム、周辺装置、情報処理装置及び制御方法 - Google Patents

Abstract

【課題】 周辺装置が印刷を終了したときにイベントを通知できない場合に、情報処理装置内における印刷ジョブのキューを削除する。
【解決手段】 ネットワークを介して周辺装置と接続された情報処理装置は、周辺装置が印刷を終了したときに情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを周辺装置に発行する。そして、リクエストに対して周辺装置から返信されたレスポンスに含まれる情報がイベントを通知できないことを表す情報の場合、情報処理装置は印刷ジョブをスタックするプリンタキューから、周辺装置にデータを送信し終えた印刷ジョブを削除する。
【選択図】 図１３

Description

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

近年、Ethernet（登録商標）、無線ＬＡＮ等の様々なインタフェースを利用して、情報処理装置に周辺装置を接続し、自宅やオフィスにおいて様々な形態でこのような周辺装置制御システムが有効に活用されている。周辺装置の例としては、例えばプリンタ、複写機、ファクシミリ、スキャナ、デジタルカメラ、デジタルビデオカメラ、及びこれらの複合機能等が挙げられる。
＜従来の技術＞
周辺装置の例としてプリンタを挙げる。近年、複数の情報処理装置によってプリンタを共有するネットワーク印刷システムにおける標準化が進んでいる。例えば、ＷＳＤ（Web Service on Devices）のプリントサービスを利用したネットワーク印刷システムが実用化されている。このようなネットワーク印刷システムでは、イベントベースのプロトコルが利用されており、このプリントサービスでもプリンタから情報処理装置に対して通知されるイベントを利用して、情報処理装置がこのイベントにより様々な制御を行っている。

例えば、上述のプリントサービスを利用したネットワーク印刷システムにおいて、同一のネットワーク上でプリンタを共有している情報処理装置からそのプリンタで印刷を行うことができる。このとき、情報処理装置が発行した印刷ジョブの要求に関して、プリンタは印刷が終了したことを表すイベント（JobEndStateEvent）を情報処理装置に通知する。

このイベントが通知される情報処理装置は、印刷ジョブを発行した情報処理装置、及び同一のネットワーク上でそのプリンタを共有している他の情報処理装置である。そして、印刷ジョブを発行した情報処理装置は、プリンタからそのイベントを受け取ると、印刷が終了した印刷ジョブを、その情報処理装置内のプリンタキューから削除する。

一般的に、プリンタ等の周辺処理装置が情報処理装置に通知するイベントの制御に関しては、その周辺装置のハードウェアリソースによる制限の影響を大きく受ける。具体的な例を挙げると、例えばプリンタが、同一ネットワーク上に存在する全ての情報処理装置に対して印刷ジョブの処理状況等をイベントによって通知することは困難である。

そのため、一般的にプリンタは自分で制御可能な特定の台数の情報処理装置に限定し、イベントの通知を行うように設計されている。例えば、カラーインクジェットプリンタのような廉価版のプリンタの場合は、そのプリンタがイベントを通知することができる情報処理装置の台数が１０〜２０台に限定されているケースが多い。

即ち、プリンタがイベントを通知することができる情報処理装置の台数が、例えば１０台に限定されているケースでは、このプリンタを共有している１１台目以降の各情報処理装置に対してイベントを通知することができない。

オペレーティングシステム（ＯＳ）には、上述したような、プリンタがイベントを通知できないケースを想定した時の対策が盛り込まれている。例えば、ＯＳは印刷終了を表すイベント（JobEndStateEvent）が通知されないケースを想定し、GetActiveJobsオペレーションを使いプリンタ内で処理中の印刷ジョブに関する情報を１０分に１回の間隔で定期的に取得する。

そして、GetActiveJobsオペレーションで取得したプリンタ内で処理中の印刷ジョブに関する情報の中に、このＯＳが発行した印刷ジョブに関する情報が含まれている間はプリンタキュー内に該当する印刷ジョブを残しておく。その後、含まれなくなると、プリンタキュー内から該当する印刷ジョブを削除する。

この対策処理において、ＯＳがプリンタに対してGetActiveJobsオペレーションを定期的に発行する時間間隔が１０分である。しかし、これはネットワークの規模や情報処理装置のハードウェア構成（スペック）等の、様々な使用環境におけるネットワーク上のトラフィックや情報処理装置の処理速度等を考慮して導き出された値であると考えられる。

この時間間隔を、例えば５秒に設定した場合、１００台以上の情報処理装置で構成される大規模ネットワークで複数台のプリンタが共有されているような使用環境の場合、ネットワーク上のトラフィックが著しく増加する。これは、稼動している全ての情報処理装置が５秒に１回の間隔でプリンタに対して定期的にGetActiveJobsオペレーションを発行するためである。その結果、Ｅメールの送受信やインターネットへのアクセス等、他のサービスの処理速度に悪影響を及ぼしてしまう。

また、情報処理装置内のＯＳの処理に着目した場合、ＯＳが５秒に１回の間隔でプリンタに対して定期的にGetActiveJobsオペレーションを発行する処理を常に実行し続けることになる。即ち、処理能力の低い廉価版の情報処理装置の場合、このような５秒に１回のGetActiveJobsオペレーションの発行処理の継続が、他のサービスや処理に悪影響を与え、処理速度が低下し、ユーザの操作性を悪化させる。このように、ＯＳ（情報処理装置）がプリンタに対してGetActiveJobsオペレーションを定期的に発行する際の時間間隔を安易に短くすることはできない。

特開２００９−００３７７８号公報

ＷＳＤのプリントサービスを利用したネットワーク印刷システムにおいて、プリンタがイベントを通知することができる情報処理装置の台数が１０台（情報処理装置Ａ〜Ｊ）に限定されているケースを考える。このようなケースにおいて、同一ネットワーク上でそのプリンタを共有している情報処理装置が１１台存在する場合、情報処理装置Ａ〜Ｊ、情報処理装置Ｋの、１１台全ての情報処理装置からそのプリンタで印刷を行うことができる。

このとき、プリンタは、情報処理装置Ａ〜Ｊが発行した印刷ジョブ要求に関して、印刷が終了したことを表すイベント（JobEndStateEvent）を各情報処理装置に対して通知する。情報処理装置Ａ〜Ｊは、このイベントを受け取ると、該当する印刷が終了した印刷ジョブを、その情報処理装置内のプリンタキューから削除する。

しかしながら、情報処理装置Ｋが発行した印刷ジョブ要求に関して、プリンタは上述の印刷終了を表すイベント（JobEndStateEvent）を情報処理装置Ｋに対して通知できない。その結果、情報処理装置Ｋは、印刷が終了した印刷ジョブをプリンタキューから削除することができず、情報処理装置Ｋ内のプリンタキューにその印刷ジョブが残ってしまう、という問題がある。

この印刷終了を表すイベントが通知されないケースにおいて、ＯＳは、GetActiveJobsオペレーションを使って、プリンタ内で処理中の印刷ジョブに関する情報を１０分に１回の間隔で定期的に取得し、印刷が終了した印刷ジョブを判別する。そして、判別の結果、印刷が終了していれば、その印刷ジョブをプリンタキューから削除している。しかしながら、印刷が終了した後、そのジョブがプリンタキューから削除されるまでに最長１０分かかり、リアルタイムでプリンタキューから印刷ジョブが削除されない、という問題もある。

情報処理装置がプリンタに対し、例えば連続して１００個の印刷ジョブを発行し、５分程度で全ての印刷ジョブの印刷が終了したような場合でも、印刷が終了した印刷ジョブがその情報処理装置のプリンタキュー内に最長１０分間残ってしまう。その結果、操作性が極めて悪い。また、ユーザの誤操作を誘発してしまう危険性も高まる。

本発明は、周辺装置が印刷を終了したときにイベントを通知できない場合に、情報処理装置内における印刷ジョブのキューを削除できるシステム及び方法を提供することを目的とする。

本発明は、ネットワークを介して接続された、印刷ジョブをスタックするプリンタキューを利用する情報処理装置と周辺装置とで構成される周辺装置制御システムであって、
前記情報処理装置は、
前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行する発行手段と、
前記周辺装置から前記レスポンスを取得して保存する取得手段とを有し、
前記周辺装置は、
前記情報処理装置から発行された前記リクエストに対して、前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを返信する返信手段を有し、
前記情報処理装置は、前記情報処理装置が前記印刷ジョブのデータを前記周辺装置に送信後、前記周辺装置から返信された前記レスポンスに含まれる前記情報が前記イベントを通知できないことを表す情報の場合、前記プリンタキューから前記印刷ジョブを削除することを特徴とする。

本発明によれば、以下のような効果が得られる。
（１）情報処理装置が印刷ジョブ要求を周辺装置に発行し、周辺装置が、その印刷ジョブ要求に関して、印刷終了を表すイベントを通知できないケースにおいて、情報処理装置内のプリンタキューからその印刷ジョブを削除することができる。これにより、印刷ジョブの処理状況がプリンタキューにリアルタイムに反映されるので、ユーザの操作性に優れる。
（２）情報処理装置内のプリンタキューから印刷が終了した印刷ジョブが自動的に削除されるので、オペレーティングシステムの誤動作や、ユーザの誤操作を防止することができる。
（３）プリンタがイベントを通知できないケースを想定した場合に、ＯＳがプリンタに対してGetActiveJobsオペレーションを定期的に発行する時間間隔を短くする必要がなく、ユーザの操作性に優れる。
（４）プリンタキューにおいて、「印刷後にドキュメントを残す」機能がセットされている場合は、印刷が終了した印刷ジョブをプリンタキューから削除しないので、この機能も誤動作することなく正しく動作する。
（５）周辺装置が複数の印刷ジョブ要求を同時に受け付けて処理できる場合にも、他の印刷ジョブ要求の印刷処理状況の影響を受けることなく、情報処理装置がプリンタキューにスタックされた複数の印刷ジョブを、周辺装置に順次発行することができる。これにより、ユーザの操作性に優れる。
（６）周辺装置が複数の印刷ジョブ要求を同時に受け付けて処理できる場合にも、印刷が終了した印刷ジョブを情報処理装置内のプリンタキューから自動的に削除することができるので、ユーザの操作性に優れる。

周辺装置制御システムの構成を表すブロック図。 ＰＣとプリンタのハードウェア構成の一例を表すブロック図。 ＰＣのソフトウェア構成を表す図。 ＰＣにおけるプリンタドライバの構成を表す図。 従来の印刷時におけるコーリングシーケンスを表す図。 実施形態の印刷時におけるコーリングシーケンスを表す図。 実施形態の印刷時におけるコーリングシーケンスを表す図。 GetPrinterElementsの内容を表し、（ａ）はGetPrinterElementsRequest、（ｂ）はGetPrinterElementsResponseをそれぞれ表す図。 プリンタ３におけるGetPrinterElementsの処理を表すフローチャート。 （ａ）はイベント管理データベースを表す図、（ｂ）は１つの印刷ジョブだけを受け付けて処理できる印刷キューデータベースを表す図、（ｃ）は複数の印刷ジョブを同時に受け付けて処理できる印刷キューデータベースを表す図。 印刷時のコーリングシーケンスを表す図。 ランゲージモニタ３６におけるLM_WritePort()関数の処理を表すフローチャート。 ランゲージモニタ３６におけるLM_EndDocPort()関数の処理を表すフローチャート。 GetActiveJobsの内容を表し、（ａ）はGetActiveJobsRequest、（ｂ）はGetActiveJobsResponseをそれぞれ表す図。 ランゲージモニタにおけるLM_EndDocPort()関数の処理を表すフローチャート。 ランゲージモニタにおける印刷ジョブの監視と削除の処理を表すフローチャート。 GetPrinterElementsの内容を表し、（ａ）はGetPrinterElementsRequest、（ｂ）はGetPrinterElementsResponseをそれぞれ表す図。 プリンタキューを表す図。 CreatePrintJobの内容を表す図であり、（ａ）はCreatePrintJobRequest、（ｂ）はCreatePrintJobResponseをそれぞれ表す図。 プリンタ３におけるCreatePrintJobの処理を表すフローチャート。 プリンタ３におけるGetActiveJobsの処理を表すフローチャート。 JobEndStateEventの内容を表す図。

以下、図面を参照しながら発明を実施するための形態について詳細に説明する。

以下で引用されるオペレーティングシステム（ＯＳ）の情報の内、特に詳しく説明していないものに関しては、インターネット上で公開されている情報であるので、必要以上の説明を省略する。2010年4月12日現在、Microsoft Developer Network (MSDN)のサイトで公開されている。http://msdn.microsoft.com/en-us/library/default.aspx

以下において、ＷＳＤとは、Web Service on Devicesを表し、インターネット上で公開されている情報であるので、必要以上の説明を省略する。2010年4月12日現在、Windows Hardware Developer Centralのサイトで公開されている。http://www.microsoft.com/whdc/connect/rally/rallywsd.mspx

以下において、ＷＳＤのPrint Service Definition Version 1.0は、インターネット上で公開されているので、必要以上の説明を省略する。2010年4月12日現在、Windows Hardware Developer Centralのサイトで公開されている米国マイクロソフト社が定義したPrint Serviceである。http://www.microsoft.com/whdc/connect/rally/wsdspecs.mspx

＜実施形態１＞
図１は情報処理装置及び周辺装置からなる周辺装置制御システムの一実施形態におけるシステムの構成を表すブロック図である。図１に示す情報処理装置１、２、５、８８８は、一般的なパーソナルコンピュータ（ＰＣ）で構成される。ＰＣ１、２、５、８８８は、図２（ａ）で後述するようなハードウェアで構成される。ＰＣ１、２、５、８８８には、ＯＳとして米国マイクロソフト社のWindows 7（登録商標）と同等のＯＳがインストールされている。また、ＰＣ１、２、５、８８８はそれぞれEthernet（登録商標）で構成されるネットワーク４に接続されている。

プリンタ３は、カラーインクジェットプリンタで構成され、本発明における周辺装置の一例として構成されている。プリンタ３は、ABC社製のKmmnというモデル名のプリンタである。尚、周辺装置は、プリンタに限らず、複写機、ファクシミリ、スキャナ、デジタルカメラ、デジタルビデオカメラ、及びこれらの複合機能を備える装置等であっても良い。プリンタ３は、図２（ｂ）で後述するようなハードウェアで構成され、ＰＣ１、２、５、８８８とネットワーク４を介して接続され、互いに双方向通信が可能である。

プリントアプリケーション３０は、Windows（登録商標）用の実行可能形式のファイル（*.EXE）で構成される。尚、プリントアプリケーション３０及びランゲージモニタ３６は、図４を用いて更に詳細に説明する。

図２は、ＰＣとプリンタのハードウェア構成の一例を表すブロック図である。ＰＣ１、２、５、８８８は、図２の（ａ）に示すようなハードウェアで構成されている。ここでは、ＰＣ５を例に挙げて説明する。図２の（ａ）に示すように、ＰＣ５にはＲＡＭ２０１、記憶部であるＨＤＤ２０２、入力部の一例であるＫＢＤ２０３、制御部のＣＰＵ２０４、表示部の一例であるＬＣＤ２０５、通信制御部の一例であるＮＢ２０７が含まれ、バス２０６に接続されている。尚、記憶部は、可搬性ＣＤ−ＲＯＭ又は内部据付のＲＯＭなどであっても良い。

図３、図４に示す各モジュール（ソフトウェア）は、ＨＤＤ２０２に記憶され、必要に応じてＲＡＭ２０１に読み出されてＣＰＵ２０４により実行される。これにより、ＣＰＵ２０４が、図３、図４に示す各モジュール（ソフトウェア）の機能を実現する。

一方、プリンタ３は、図２（ｂ）に示すようなハードウェア構成を持つ。図２（ｂ）に示すＣＰＵ１５はマイクロプロセッサ等から構成され、プリンタ３の中央処理装置としてＲＯＭ１６に記憶されているプログラムに従ってＲＡＭ１７、通信部１８、記録部１９、操作部２０、表示部２１を制御する。

ＲＯＭ１６にはプリンタドライバ（図４で後述する）の制御に従ってプリンタ３が記録（印刷）処理や、印刷動作の状態をＰＣ５へ通知する処理を行うプログラムが記憶されている。ＲＡＭ１７は主にＰＣ５から送られ、それをもとに記録部１９によって印刷される印字データが一時的に記憶される。通信部１８にはネットワーク４用の接続ポート等が含まれ、Ethernet（登録商標）通信を制御する。記録部１９は、インクジェット方式の記録ヘッド、各カラーインク、キャリッジ、記録紙搬送機構等から構成される記録ユニットと、印字データをもとに記録ヘッドにて印字用パルスを発生させる為のＡＳＩＣ等から構成される電気回路とから構成される。

印刷可能なアプリケーション上での印刷操作によってアプリケーションで開かれているファイルの表示内容（画像データ）がＥＭＦ形式のスプールファイルとしてＰＣ５のＨＤＤ２０２に一時的に格納される。格納されたスプールファイルは、プリンタドライバ５０を介してプリンタ３制御用コマンドを含む印字データに変換された後、ネットワーク４を介してプリンタ３に送られる。プリンタ３で受信された印字データは、記録部１９で印字用パルスに変換されて記録紙上に印刷される。

操作部２０は、電源ボタン、リセットボタン等の各種ボタンから構成され、プリンタ３を操作することができる。表示部２１は、タッチパネルの液晶ディスプレイで構成され、プリンタ３の状態の表示や、各種設定の表示、入力等を行うことができる。

図３は、ＰＣのソフトウェア構成を表す図である。図３に示す、イーサネット（登録商標）制御スタック９２はイーサネット（登録商標）を制御する。ＩＰネットワーク制御スタック９１はＩＰネットワークを制御する。ＷＳＤ制御スタック９０はＷＳＤを制御する。ＩＨＶネイティブプロトコル制御スタック８９はＩＨＶの独自プロトコルを制御する。Ｎ−ＰｎＰ制御スタック８８はネットワークのプラグアンドプレイ（Ｎ−ＰｎＰ）を制御する。

尚、ネットワーク接続デバイスに対するサポートを提供するプラグアンドプレイの一連の拡張機能としてＯＳに標準搭載されている機能には、ＰｎＰ−Ｘ（Plug and Play for Extensions）が存在する。しかし、ここでは、これと同等の機能としてＮ−ＰｎＰを利用する例で説明する。

また、後述するＷＳＤを制御するＷＳＤＡＰＩｓは、ＷＳＤ制御スタック９０に含まれる。そして、後述するＩＨＶの独自プロトコルを制御するＡＰＩｓは、ＩＨＶネイティブプロトコル制御スタック８９に含まれる。

デバイスドライバ群８５は、ＯＳに標準で同梱されている標準ドライバ群８７とＩＨＶから提供されるＩＨＶ製ドライバ群８６から構成される。アプリケーション／ＤＤＩインタフェース８４は、アプリケーションプログラミングインタフェース（ＡＰＩ）、デバイスドライバインタフェース（ＤＤＩ）から構成される。アプリケーション群８２は、図４で後述する印刷可能なアプリケーション３０等から構成される。

図４は、ＰＣにおけるプリンタドライバの構成を表す図である。図４に示す、プリンタドライバ５０はＰＣ５にインストールされているプリンタ３用のプリンタドライバであり、複数のモジュール３３〜３６、３９から構成される。また、プリントアプリケーション３０は、例えばＯＳに標準で同梱されている印刷可能なテキストエディタのノートパッド（Notepad.exe）等に相当する。そして、ＧＤＩ（グラフィックスデバイスインタフェース）３１及びスプーラ４０はＯＳの一部であり、プリンタキュー３２はこのスプーラ４０の一部として構成され、印刷ジョブがキューイングされる。キューイングされた印刷ジョブはプリンタキューフォルダ（不図示）に表示される。

プリンタドライバ５０において、プリントプロセッサ３３は、印刷レイアウトの変更や印刷画像に対する特殊処理を行う。グラフィックスドライバ３４は、プリンタドライバの画像処理のコアとしてＧＤＩ３１から送られてくる描画命令をもとに印刷用の画像処理を行い、印刷制御コマンドを作成する。ＵＩモジュール３５は、プリンタドライバのユーザインタフェースの提供及び制御を行う。

また、ランゲージモニタ３６は、データの通信Ｉ／Ｆとしてデータの送受信を制御する。ステータスモニタ３９は、プリンタ３のインク残量や警告、エラー等の状態を表示する。ポートモニタ３７は、ランゲージモニタ３６から送られてくるデータを適切なポートに送信し、プリンタ３から送られてくるデータをクラスドライバ３８を介して受信する処理を行う。特に、ＷＳＤのプリントサービスを制御するポートモニタのことをＷＳＤＭｏｎと呼ぶ。

クラスドライバ３８は、最もポートに近いローレベルのモジュールである。ここでは、ＷＳＤやＩＨＶの独自プロトコルのプリンタクラスのドライバに相当し、ポート（ネットワークポート）を制御する。プリンタドライバ５０は、プリンタ３の製造元であるABC社製のものである。

図１０は、プリンタ３がＰＣに通知するＷＳＤのイベントを管理するイベント管理データベースと、プリンタ３が受信した印刷ジョブ要求を管理する印刷キューデータベースを表す図である。図１０は本発明の特徴を最も良く表す図の内の１つである。

図１０の（ａ）は、プリンタ３がＰＣに通知するＷＳＤのイベントを管理するイベント管理データベースを表す図である。一般的に、プリンタがＰＣに通知するイベントの制御に関しては、そのプリンタのハードウェアリソースにおける制限の影響を大きく受ける。具体的な例を挙げると、例えばプリンタが、同一ネットワーク上に存在する全てのＰＣに対して印刷ジョブの処理状況等をイベントによって通知することは困難である。そのため、一般的に、プリンタは自分で制御可能な特定の台数のＰＣに限定し、イベントの通知を行うように設計されている。

図１０の（ａ）に示すイベント管理データベース１２３の場合、プリンタ３はComputer Name欄にセットされている最多で２台のＰＣに対してイベントを通知することが可能である。また、Subscribed Event欄には、ＰＣからのＷＳＤの各イベントの登録要求に対して、プリンタ３が登録を許可したイベントがセットされている。更に、ans:EventControl欄には、図８に示すＷＳＤのGetPrinterElementsResponse内の＜ans:EventControl＞要素８０２にセットされる値が保存されている。この例では、プリンタ３がＰＣ１、ＰＣ２に対して、以下に示すＷＳＤの各イベントを通知することが可能な状態であることを示している。
PrinterElementsChangeEvent
PrinterStatusSummaryEvent
PrinterStatusConditionEvent
PrinterStatusConditionClearedEvent
JobStatusEvent
JobEndStateEvent

例えば、ＰＣ１又はＰＣ２からプリンタ３に対して印刷ジョブが発行された場合、プリンタ３におけるその印刷ジョブの処理状況に応じて、プリンタ３はＰＣ１又はＰＣ２に対して、各イベントによる通知を行う。これにより、ＰＣ１又はＰＣ２は、自分が発行した印刷ジョブの処理状況を把握することができる。

これに対して、ＰＣ５からプリンタ３に対して印刷ジョブが発行された場合、プリンタ３はこの印刷ジョブを受け付けて印刷を行うことができるものの、ＰＣ５に対して、その印刷ジョブの処理状況に応じた各イベントの通知を行うことができない。その結果、ＰＣ５は、自分が発行した印刷ジョブの処理状況を、イベントを利用して把握することはできない。これは、ＰＣ１、ＰＣ２、ＰＣ５からほぼ同時に印刷ジョブが発行された時に限定されることはなく、例えばネットワーク４上にＰＣ１、ＰＣ２、ＰＣ５が存在する場合において、ＰＣ５だけから印刷ジョブが発行された場合にも同様である。プリンタ３はＰＣ５に対してその印刷ジョブの処理状況に応じた各イベントの通知を行うことができない。この例では、特に重要なイベントとして、印刷ジョブの処理状況を表すJobStatusEventと、印刷が終了したことを表すJobEndStateEventの２つのイベントに着目する。このJobEndStateEventの詳細に関しては、図２２を用いて更に説明する。

図１０の（ｂ）は、複数の印刷ジョブを同時に受け付けて処理することができず、１つの印刷ジョブだけを受け付けて処理することができるプリンタ３における、受信した印刷ジョブ要求を管理する印刷キューデータベースを表す図である。

印刷キューデータベース１２４において、管理番号（Ｎｏ．）欄は、印刷キューデータベース１２４における印刷ジョブ要求の管理番号である。この例では、プリンタ３が印刷処理中又は印刷処理待ちの印刷ジョブ要求を同時に５つまで保存することができる。次のComputer Name欄には、印刷ジョブ要求が発行されたＰＣの名前が保存されている。wprt:JobName欄には、ＷＳＤのプリントサービスのCreatePrintJobRequest内の＜wprt:JobName＞要素にセットされている値が保存されている。wprt:JobOriginatingUserName欄には、ＷＳＤのプリントサービスのCreatePrintJobRequest内の＜wprt:JobOriginatingUserName＞要素にセットされている値が保存されている。wprt:JobId欄には、前記印刷ジョブ要求に対する応答としてＰＣに返されるＷＳＤのCreatePrintJobResponse内の＜wprt:JobId＞要素にセットされる値が保存されている。

管理番号が１の印刷ジョブ要求のwprt:JobIdの値１００１は、プリンタ３がＰＣ５から発行された要求を受け付けた時に、その応答であるCreatePrintJobResponseによりプリンタ３からＰＣ５へ既に返されている。この印刷ジョブは図１８の（ｃ）に示す印刷ジョブ１４５である。管理番号が２、３のwprt:JobIdの値１００２、１００３は、プリンタ３がＰＣ１、ＰＣ２から発行された要求を受け付けていないので、ＰＣ１、ＰＣ２へは未だ返されていない。これらの値は、プリンタ３が、管理番号が１の印刷ジョブ要求の印刷処理を終了した後、ＰＣ１、ＰＣ２から発行された要求を受け付ける時に備えて予約されている。

ans:EventControl欄には、図８に示すＷＳＤのGetPrinterElementsResponse内の＜ans:EventControl＞要素８０２にセットされる値が保存されている。Status欄には、印刷ジョブ要求のプリンタ３における処理状況が保存されている。ここでは、プリンタ３がＰＣ５から発行された印刷ジョブ要求を受信し、管理番号１として受け付けて処理している状態（Processing）を示す。また、プリンタ３が、ＰＣ１、ＰＣ２から発行された印刷ジョブ要求を受信し、管理番号が２、３としてそれぞれ印刷キューデータベース１２４に登録したものの、受け付けずに処理していない状態（Not Accepted）も示している。

図１０の（ｃ）は、複数の印刷ジョブを同時に受け付けて処理することができず、１つの印刷ジョブだけを受け付けて処理することができるようなプリンタ３で、受信した印刷ジョブ要求を管理する印刷キューデータベースを表す図である。印刷キューデータベースである。尚、図１０の（ｂ）で説明した内容に関しては、その説明を省略する。

図１０の（ｂ）でプリンタ３が処理していた管理番号が１の印刷ジョブ要求の印刷が終了すると、図１０の（ｃ）に示すような印刷キューデータベース１２４の状態に移行する。そして、プリンタ３が、ＰＣ１、ＰＣ２から発行された印刷ジョブ要求を受信し、それぞれ管理番号が１、２の印刷ジョブ要求として印刷キューデータベース１２４に再登録した状態を示す。また、プリンタ３が、これらの印刷ジョブ要求の内、管理番号が１の印刷ジョブ要求を受け付けて処理している状態（Processing）と、管理番号が２の印刷ジョブ要求を受け付けずに処理していない状態（Not Accepted）も示している。管理番号が１の印刷ジョブは、図１８の（ａ）に示す印刷ジョブ１４４である。

図５は従来の印刷時におけるコーリングシーケンスを表す図である。今、プリンタ３は複数の印刷ジョブを受け付けることができず、１つの印刷ジョブだけを受け付けることができる、と仮定する。図５において、ユーザがアプリケーション３０から印刷を開始すると（Ｓ５０１）、ＯＳはスプーラ４０のStartPrintJob()関数をコールする（Ｓ５０２）。この関数内において、スプーラ４０はランゲージモニタ３６のLM_StartDocPort()関数をコールする（Ｓ５０４）。この関数内において、ランゲージモニタ３６はポートモニタ３７のPM_StartDocPort()関数をコールする（Ｓ５０６）。この関数内において、ポートモニタ３７は必要に応じて適当な処理を行い（Ｓ５０７）、戻り値pmRetに処理の結果を代入して、この関数を終了し、呼び出し元に戻る（Ｓ５０８）。

通常、正常に処理された場合は戻り値pmRetにTRUEが代入され、それ以外の場合は戻り値pmRetにFALSEが代入される。ランゲージモニタ３６は、PM_StartDocPort()関数の戻り値をlmRetに代入し（Ｓ５０５）、LM_StartDocPort()関数を終了し、呼び出し元に戻る（Ｓ５０９）。

スプーラ４０は、このLM_StartDocPort()関数の戻り値をspRetに代入する（Ｓ５０３）。ここで、spRetがTRUEではない（FALSEである）場合（Ｓ５１０）、スプーラ４０は再びランゲージモニタ３６のLM_StartDocPort()関数をコールする（Ｓ５０４）。一方、spRetがTRUEの場合、スプーラ４０はランゲージモニタ３６のLM_WritePort()関数をコールする（Ｓ５１２）。この関数内において、ランゲージモニタ３６はポートモニタ３７のPM_WritePort()関数をコールする（Ｓ５１４）。この関数内において、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのCreatePrintJob()関数をコールする。この関数内において、ポートモニタ３７はＷＳＤのプリントサービスのリクエスト（CreatePrintJobRequest）をプリンタ３に発行する。

このリクエストの中に、この印刷ジョブに関する詳細情報が含まれている。このリクエストに対してプリンタ３がレスポンス（CreatePrintJobResponse）又はFault（ServerErrorNotAcceptingJobs）をポートモニタ３７に返す（Ｓ５１６）。プリンタ３が印刷ジョブを受け付けることができ、その印刷ジョブを受け付けた場合、プリンタ３はレスポンスをポートモニタ３７に返す。しかし、プリンタ３が印刷ジョブを受け付けることができない場合、プリンタ３はFaultをポートモニタ３７に返す。

ポートモニタ３７がプリンタ３からCreatePrintJob()関数の戻り値を受け取るとpmRetに代入し（Ｓ５１５）、PM_WritePort()関数を終了して呼び出し元に戻る（Ｓ５１７）。そして、ランゲージモニタ３６がpmRetを受け取ると、PM_WritePort()関数の戻り値をlmRetに代入し（Ｓ５１３）、LM_WritePort()関数を終了して呼び出し元に戻る（Ｓ５１８）。

スプーラ４０は、このLM_WritePort()関数の戻り値をspRetに代入する（Ｓ５１１）。ここで、spRetがTRUEではない（FALSEである）場合（Ｓ５１９）、スプーラ４０は再びランゲージモニタ３６のLM_WritePort()関数をコールする（Ｓ５１２）。一方、spRetがTRUEの場合、スプーラ４０は引き続き印刷データの送信処理を行う。この送信処理は、図７を用いて更に後述する。

最後に、スプーラ４０はランゲージモニタ３６のLM_EndDocPort()関数をコールする（Ｓ５２１）。この関数内において、ランゲージモニタ３６はポートモニタ３７のPM_EndDocPort()関数をコールする（Ｓ５２３）。この関数内において、ポートモニタ３７は印刷が終了したことを表すイベント（JobEndStateEvent）通知待ちプロセスを起動する（Ｓ５２４）。

ポートモニタ３７は、必要に応じて適当な処理を行い（Ｓ５２５）、その戻り値pmRetに処理の結果を代入し、この関数を終了し、呼び出し元に戻る（Ｓ５２６）。通常、正常に処理された場合は戻り値にTRUEが代入され、それ以外の場合は戻り値にFALSEが代入される。ランゲージモニタ３６は、PM_EndDocPort()関数の戻り値をlmRetに代入し（Ｓ５２２）、LM_EndDocPort()関数を終了して呼び出し元に戻る（Ｓ５２７）。

スプーラ４０は、このLM_EndDocPort()関数の戻り値をspRetに代入し（Ｓ５２０）、StartPrintJob()関数を終了し、呼び出し元に戻る（Ｓ５２８）。ポートモニタ３７が上述のイベント通知待ちプロセスにおいて、プリンタ３からそのイベントの通知を受信すると、通知された印刷が終了した印刷ジョブをプリンタキュー３２から削除する。

図１０の（ａ）及び（ｃ）のケースにおいて、プリンタ３がＰＣ１から発行された印刷ジョブ要求に対して印刷処理を実行すると、プリンタキューには、図１８の（ａ）に示すような印刷ジョブ１４４が「Printing」のステータスで表示される。その後、プリンタ３は、印刷が終了した時にＰＣ１に対して印刷終了イベントを通知する。ＰＣ１内のポートモニタ３７は、このイベントの通知待ちプロセスにおいて、このイベントを受信すると、印刷ジョブ１４４をＰＣ１内のプリンタキューから削除する。その結果、図１８の（ｂ）に示すように、ＰＣ１内のプリンタキューから印刷ジョブ１４４が削除されて、表示されなくなる。

また、図１０の（ａ）及び（ｂ）のケースにおいても、プリンタ３はＰＣ５から発行された印刷ジョブ要求に対して印刷処理を受け付けて処理することができる。そして、その印刷ジョブを実行すると、ＰＣ５内のプリンタキュー３２には、図１８の（ｃ）に示すような印刷ジョブ１４５が「Printing」のステータスで表示される。

しかしながら、プリンタ３は、印刷が終了した時にＰＣ５に対して印刷終了のイベントを通知することができない。その結果、ＰＣ５内のポートモニタ３７は、このイベントの通知待ちプロセスにおいて、ＰＣ５から発行された印刷ジョブ１４５の印刷が終了したことを表すイベントを一切受信することができない。その結果、図１８の（ｄ）に示すように、ＰＣ５内のプリンタキュー３２に印刷ジョブ１４５が「Sent to printer」のステータスで残ってしまう。

即ち、プリンタ３がこのイベントを通知することができないＰＣ５のようなＰＣからの印刷ジョブが、印刷が終了しているにもかかわらず「Sent to printer」のステータスでプリンタキューに残ってしまう。

図６、図１１は印刷時のコーリングシーケンスを表す図である。これらの図は本発明の特徴を最もよく表す図の内の１つである。今、プリンタ３は、１つの印刷ジョブ要求だけを受け付けて、その印刷ジョブを処理して印刷を実行することができ、図１０の（ａ）に示すようにＰＣ１とＰＣ２の２台のＰＣにだけイベントを通知できる、というような廉価版のプリンタである、と仮定する。

図６において、ユーザがアプリケーション３０から印刷を開始すると（Ｓ６０１）、ＯＳはスプーラ４０のStartPrintJob()関数をコールする（Ｓ６０２）。この関数内において、スプーラ４０はランゲージモニタ３６のLM_StartDocPort()関数をコールする（Ｓ６０４）。この関数内において、ランゲージモニタ３６はフラグlmDeleteJobにFALSEを代入して初期化する（Ｓ６０５）。このフラグは、ランゲージモニタ３６内で使用されるものであり、プリンタ３がその印刷ジョブを発行したＰＣに対してその印刷ジョブが終了したことを表すイベントを通知することができない場合に、TRUEがセットされる。それ以外の場合にFALSEがセットされる。ランゲージモニタ３６はlmJobIdに０を代入して初期化する（Ｓ６０６）。その後、ランゲージモニタ３６は図５のＳ５０５〜Ｓ５０９と同じ処理を行う。

スプーラ４０は、Ｓ５０９と同じ処理で返されたLM_StartDocPort()関数の戻り値をspRetに代入する（Ｓ６０３）。スプーラ４０は、spRetがTRUEではない（FALSEである）場合（Ｓ６０７）、ランゲージモニタ３６のLM_StartDocPort()関数をコールする。一方、このspRetがTRUEの場合、図１１のＳ１１０１へ進む。図１１に示す印刷ジョブ要求の発行と印刷ジョブ情報の取得等に関して後述する。

最後に、スプーラ４０はランゲージモニタ３６のLM_EndDocPort()関数をコールする（Ｓ６０９）。この関数内において、ランゲージモニタ３６は、引数にwprt:PrinterDescriptionをセットし、ＷＳＤを制御するＷＳＤＡＰＩｓのGetPrinterElements（）関数をコールする。この関数内において、ポートモニタ３７はＷＳＤのプリントサービスのリクエスト（GetPrinterElementsRequest）をプリンタ３に発行する。このリクエストに対してプリンタ３がレスポンス（GetPrinterElementsResponse）をポートモニタ３７に返す（Ｓ６１１）。ここでポートモニタ３７がレスポンスを受け取ると、GetPrinterElements（）関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ６１０）。

また、ポートモニタ３７がプリンタ３に対してリクエストを発行してからある一定時間の間にレスポンスを受け取らなかった場合、GetPrinterElements（）関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ６１０）。

ランゲージモニタ３６はGetPrinterElements（）関数の戻り値をlmRetに代入する。尚、ここでは、GetPrinterElements（）関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。ポートモニタ３７が発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図８で説明する。

ランゲージモニタ３６は、Ｓ６１０のGetPrinterElements（）関数の引数として渡されたレスポンス内の＜wprt:DeviceId＞要素８０４にセットされている値を取得し、プリンタ３の状態を判定を行う。その中に含まれるＩＮＦＯ：にセットされている値が、オンラインでスタンバイ状態を表す「０００」、即ち＜wprt:DeviceId＞要素８０４にセットされている値の中に「ＩＮＦＯ：０００」が含まれているか否かを判定する（Ｓ６１２）。ここで、プリンタ３がオンラインでスタンバイ状態であるということは、印刷が終了したしたことを意味する。Ｓ６１２において、ランゲージモニタ３６が、＜wprt:DeviceId＞要素８０４にセットされている値の中に「ＩＮＦＯ：０００」が含まれていると判定した場合、図５のＳ５２２〜Ｓ５２６と同じ処理を行う。しかし、含まれていないと判定した場合にはＳ６１０に戻る。

このとき、ランゲージモニタ３６はＳ５２２と同じ処理により、PM_EndDocPort()関数の戻り値をlmRetに代入する。ランゲージモニタ３６は、lmDeleteJobにセットされている値を確認し、TRUEがセットされている場合（Ｓ６１３）、図１３のステップＳ１３０４、Ｓ１３０６に示す印刷ジョブの削除処理を行う（Ｓ６１４）。例えば、図１３のＳ１３０６で、ランゲージモニタ３６がこの印刷ジョブを削除した場合、「Sent to printer」のステータスの印刷ジョブ（図１８の（ｃ）の印刷ジョブ１４５）がプリンタキュー３２から削除される（図１８の（ｅ））。ランゲージモニタ３６はlmDeleteJobにFALSEを代入して初期化する（Ｓ６１５）。ランゲージモニタ３６はlmJobIdに０を代入して初期化する（Ｓ６１６）。

ランゲージモニタ３６は、ｌｍＲｅｔの値をLM_EndDocPort()関数の戻り値として返し、LM_EndDocPort()関数を終了し、呼び出し元に戻る（Ｓ６１７）。Ｓ６０９〜Ｓ６１７に示すLM_EndDocPort()関数の処理の詳細に関しては、図１３で説明する。スプーラ４０は、このLM_EndDocPort()関数の戻り値をspRetに代入し（Ｓ６０８）、StartPrintJob()関数を終了し、呼び出し元に戻る（Ｓ６１８）。

図１１において、スプーラ４０はランゲージモニタ３６のLM_WritePort()関数をコールする（Ｓ１１０２）。この関数内において（Ｓ１１０３）、ランゲージモニタ３６はポートモニタ３７のＰＭ＿ＷｒｉｔｅＰｏｒｔ（）関数をコールする（Ｓ１１０４）。この関数内において（Ｓ１１０５）、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのCreatePrintJob（）関数をコールする（Ｓ１１０６）。この関数内において、ＰＣ（ＰＣ５）は、印刷ジョブ要求、即ちＷＳＤのプリントサービスのリクエスト（CreatePrintJobRequest）をプリンタ３に発行する。このリクエストの中に、この印刷ジョブに関する詳細情報が含まれている。このリクエストに対してプリンタ３はレスポンス（CreatePrintJobResponse）又はFault（ServerErrorNotAcceptingJobs）をポートモニタ３７に返す（Ｓ１１０７）。

プリンタ３が印刷ジョブ要求を受け付け、実行することができる状態の時に、その印刷ジョブ要求を受け付けた場合、プリンタ３はその印刷ジョブ要求を発行したポートモニタ３７に対してレスポンスを返す。また、プリンタ３が印刷ジョブ要求を受け付けることができない状態の時に、印刷ジョブ要求を受け付けない場合、プリンタ３はその印刷ジョブ要求を発行したポートモニタ３７に対してFaultを返す。

ポートモニタ３７がレスポンスを受け取ると、CreatePrintJob（）関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ１１０６）。このとき、プリンタ３はレスポンス内の＜wprt:JobId＞要素に、図１０の（ｂ）、（ｃ）のwprt:JobId欄に保存されている値をセットしておく。一方、ポートモニタ３７がFaultを受け取ると、CreatePrintJob（）関数の戻り値にFALSEを代し、呼び出し元に戻る（Ｓ１１０６）。ポートモニタ３７は、戻り値pmRetにCreatePrintJob（）関数の戻り値を代入し（Ｓ１１０６）、PM_WritePort()関数を終了し、呼び出し元に戻る（Ｓ１１０８）。

ランゲージモニタ３６は、PM_WritePort()関数の戻り値をlmRetに代入する（Ｓ１１０４）。ランゲージモニタ３６は、lmRetの値を確認し（Ｓ１１０９）、TRUEの場合Ｓ１１１０へ進み、TRUEではない（FALSE）場合Ｓ１１１７へ進む。このＳ１１１０では、ランゲージモニタ３６は、引数にwprt:PrinterDescriptionをセットして、ＷＳＤを制御するＷＳＤＡＰＩｓのGetPrinterElements（）関数をコールする。この関数内において、ＷＳＤのプリントサービスのリクエスト（GetPrinterElementsRequest）をプリンタ３に発行する。このリクエストに対してプリンタ３はレスポンス（GetPrinterElementsResponse）をポートモニタ３７に返す（Ｓ１１１１）。

ポートモニタ３７がレスポンスを受け取ると、GetPrinterElements（）関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ１１１０）。また、ポートモニタ３７がプリンタ３に対してリクエストを発行した後、一定時間の間にレスポンスを受け取らなかった場合、GetPrinterElements（）関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ１１１０）。Ｓ１１１０において、ランゲージモニタ３６はGetPrinterElements（）関数の戻り値をlmRetに代入する。尚、ここでは、GetPrinterElements（）関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。また、Ｓ１１１０でポートモニタ３７が発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図８で説明する。

ランゲージモニタ３６は、Ｓ１１１０のGetPrinterElements（）関数の引数として渡されたレスポンス内の＜ans:EventControl＞要素８０２の値を取得し「false」と比較する（Ｓ１１１２）。Ｓ１１１２において、ランゲージモニタ３６が「false」であると判定した場合、lmDeleteJobにTRUEを代入する（Ｓ１１１３）。このとき、＜wprt:DeviceId＞要素８０４にセットされている値は次の値であり、プリンタ３が印刷処理中（Processing）であることを表す「ＩＮＦＯ：００１」の状態であることがわかる。「MFG:ABC;CMD:ABCCommand;MDL:Kmmn;CLS:PRINTER;DES:ABC Kmmn;VER:1.00;INFO:001;」

ランゲージモニタ３６は、ＷＳＤを制御するＷＳＤＡＰＩｓのGetActiveJobs関数をコールする（Ｓ１１１４）。この関数内において、ポートモニタ３７はＷＳＤのプリントサービスのリクエスト（GetActiveJobsRequest）をプリンタ３に発行する。このリクエストに対してプリンタ３はレスポンス（GetActiveJobsResponse）をポートモニタ３７に返す（Ｓ１１１５）。ポートモニタ３７がレスポンスを受け取ると、GetActiveJobs関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ１１１４）。また、ポートモニタ３７がプリンタ３に対してリクエストを発行してからある一定時間の間に、レスポンスを受け取らなかった場合、GetActiveJobs関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ１１１４）。Ｓ１１１４において、ランゲージモニタ３６はGetActiveJobs関数の戻り値をlmRetに代入する。

尚、ここでは、GetActiveJobs関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。Ｓ１１１４でポートモニタ３７が発行するリクエストと、それに対してプリンタ３が返すレスポンスの詳細に関しては図１４で説明する。

ランゲージモニタ３６は、Ｓ１１１４のGetActiveJobs関数の引数として渡されたレスポンス内の＜wprt:JobId＞要素１４０２の値を取得し、lmJobIdに代入する（Ｓ１１１６）。ランゲージモニタ３６はLM_WritePort()関数を終了し、呼び出し元に戻る（Ｓ１１１７）。このとき、このLM_WritePort()関数の戻り値として、lmRetの値が返される（Ｓ１１１７）。

スプーラ４０は、このLM_WritePort()関数の戻り値をspRetに代入する（Ｓ１１０２）。spRetがTRUEではない（FALSE）場合（Ｓ１１１８）、Ｓ１１０２に戻り、スプーラ４０はランゲージモニタ３６のLM_WritePort()関数をコールする。Ｓ１１１８においてspRetがTRUEの場合、スプーラ４０は引き続き図７に示す印刷データの送信処理を行う。その後、ランゲージモニタ３６が図６のＳ６０９〜Ｓ６１７の処理を行い、スプーラ４０が図６のＳ６１８の処理を行うことで、印刷が終了する。

このように、図１０の（ａ）及び（ｂ）のケースにおいて、図１８の（ｅ）に示すように、印刷が終了した印刷ジョブ１４５をＰＣ５内のプリンタキュー３２から自動的に削除することができ、ユーザの操作性に優れる。

図７は印刷時のコーリングシーケンスを表す図である。図５のＳ５１９又は図１１のＳ１１１８において、spRetがTRUEの場合、スプーラ４０はランゲージモニタ３６のLM_WritePort()関数をコールする（Ｓ７０２）。この関数内において、ランゲージモニタ３６はポートモニタ３７のPM_WritePort()関数をコールする（Ｓ７０４）。この関数内において、ポートモニタ３７はＷＳＤを制御するＷＳＤＡＰＩｓのSendDocument()関数をコールする。この関数内において、ＰＣはＷＳＤのプリントサービスのリクエスト（SendDocumentRequest）をプリンタ３に発行する。その際に、ＭＴＯＭ（Message Transmission Optimization Mechanism）メッセージエンコーディングを使う。そして印刷制御コマンドで構成された印刷データを、ＳＯＡＰメッセージを使用して未処理のバイトとしてプリンタ３に送信する。

プリンタ３は、このリクエストに対してレスポンス（SendDocumentResponse）をポートモニタ３７に返す（Ｓ７０６）。ポートモニタ３７がこのレスポンスを受け取り、全ての印刷データをプリンタ３に送信し終わると、SendDocument()関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ７０５）。ポートモニタ３７がリクエストを発行した時、或いはレスポンス受け取った時に、何らかのエラーが発生した場合、SendDocument()関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ７０５）。ポートモニタ３７は、戻り値pmRetにSendDocument()関数の戻り値を代入し（Ｓ７０５）、PM_WritePort()関数を終了し、呼び出し元に戻る（Ｓ７０７）。

ランゲージモニタ３６は、PM_WritePort()関数の戻り値をlmRetに代入し（Ｓ７０３）、LM_WritePort()関数を終了し、呼び出し元に戻る（Ｓ７０８）。スプーラ４０は、このLM_WritePort()関数の戻り値をspRetに代入する（Ｓ７０１）。ここで、spRetがTRUEではない（FALSE）場合（Ｓ７０９）、Ｓ７０１に戻り、スプーラ４０はランゲージモニタ３６のLM_WritePort()関数をコールする。一方、spRetがTRUEの場合、図５のＳ５２０又は図６のＳ６０８へ進む。

図１９は、CreatePrintJobの内容を表す図、図８、図１７はGetPrinterElementsの内容を表す図である。図１４はGetActiveJobsの内容を表す図、図２２はJobEndStateEventの内容を表す図である。CreatePrintJobオペレーションは、印刷ジョブの開始要求である。GetPrinterElementsオペレーションは、通常プリンタに関する情報を取得するために利用される。GetActiveJobsオペレーションは、通常プリンタ内で処理中の印刷ジョブに関する情報を取得するために利用される。JobEndStateEventは、印刷ジョブの終了を表す印刷終了イベントである。CreatePrintJob、GetPrinterElements、GetActiveJobsの一般的な内容に関しては、ＷＳＤのプリントサービスDefinition Version 1.0で定義されているので、説明は省略する。

図１９はCreatePrintJobの内容を表す図であり、（ａ）はCreatePrintJobRequest、（ｂ）はCreatePrintJobResponseをそれぞれ表す。

図１９の（ａ）のリクエストは、ＰＣ５がプリンタ３に発行するものの一例である。図示するように、リクエストには、ＷＳＤのプリントサービスの名前空間を名前空間名ｗｐｒｔと定義する記述１９０５が含まれる。名前空間名ｗｐｒｔの有効範囲内は、ＷＳＤのプリントサービスDefinition Version 1.0で定義されているパブリック情報である。これ以降の図においても、名前空間名ｗｐｒｔは同様な取り扱いとなり、名前空間名ｗｐｒｔの有効範囲内はＷＳＤのプリントサービスDefinition Version 1.0で定義されているパブリック情報を表す。

＜wprt:JobDescription＞要素１９０１はパブリック情報であり、この中に印刷ジョブに関する情報が含まれている。＜wprt:JobName＞要素１９０２はパブリック情報であり、印刷ジョブ名がセットされる。この例では、図１８の（ｃ）に示す印刷ジョブ１４５のDocument Nameと同じ「Photo2」という印刷ジョブ名がセットされている状態を表す。

＜wprt:JobOriginatingUserName＞要素１９０３はパブリック情報であり、この印刷ジョブを発行したユーザ名がセットされる。この例では、図１８の（ｃ）に示す印刷ジョブ１４５のOwnerと同じ「Natsu」というユーザ名がセットされている状態を表す。

図１９（ｂ）のレスポンスは、プリンタ３がＰＣ５に返すものの一例である。ここで、＜wprt:JobId＞要素１９０４はパブリック情報であり、ＰＣ５からリクエストされた印刷ジョブを識別するためにプリンタ３が割り当てたジョブＩＤがセットされる。この例では、「1001」（図１０の（ｂ）の管理番号が１の印刷ジョブ要求のwprt:JobId欄）というジョブＩＤがセットされている状態を表す。

図８はGetPrinterElementsの内容を表す図である。図８の（ａ）はGetPrinterElementsRequest、（ｂ）はGetPrinterElementsResponseをそれぞれ表す。図８は本発明の特徴を最もよく表す図の内の１つである。

図８の（ａ）に示すリクエストは、ＰＣ５がプリンタ３に発行するものの一例である。このリクエストの＜wprt:Name＞要素８０１はパブリック情報であり、その値としてwprt:PrinterDescriptionがセットされている。

図８の（ｂ）に示すレスポンスは、プリンタ３がＰＣ５に返すものの一例である。プリンタ３は、wprt:PrinterDescriptionがセットされた＜wprt:Name＞要素８０１を含むリクエストを受け取ると、このレスポンスでwprt:PrinterDescriptionをＰＣ５に返す。

このレスポンスには、ＡＢＣ社のＷＳＤを利用したプリントサービスの名前空間を名前空間名ａｎｓと定義している記述８０６が含まれる。名前空間名ａｎｓの有効範囲内は、ＡＢＣ社のＷＳＤを利用したプリントサービスで定義されているプライベート情報である。これ以降の図においても、名前空間名ａｎｓは同様な取り扱いとなり、名前空間名ａｎｓの有効範囲内は、ＡＢＣ社のＷＳＤを利用したプリントサービスで定義されているプライベート情報を表す。

＜wprt:ElementData＞要素８０３はパブリック情報であり、Name属性としてパブリック情報のwprt:PrinterDescriptionがセットされている。これは、このレスポンスが＜wprt:Name＞要素８０１で指定されたwprt:PrinterDescriptionを含むことを表す。＜wprt:PrinterDescription＞要素８０５はパブリック情報であり、プリンタ３に搭載されている機能等に関する情報がこの中に含まれている。

＜wprt:DeviceId＞要素８０４はパブリック情報であり、IEEE 1284-2000ノDevice IDで定義されたデータ（文字列）がセットされている。これはプリンタ３のDevice IDを表す。この例では、「MFG:ABC;CMD:ABCCommand;MDL:Kmmn;CLS:PRINTER;DES:ABC Kmmn;VER:1.00;INFO:001;」というDevice IDがセットされている状態を表す。このDevice IDの中にプリンタ３の状態を表す情報INFO:xxx（ｘｘｘは以下に記す何れかの値）が含まれており、以下に示す状態を表す。
ＩＮＦＯ：
０００ オンラインでスタンバイ状態
００１ 印刷処理中（Processing）

＜ans:EventControl＞要素８０２はプライベート情報であり、プリンタ３がＰＣに対してＷＳＤのイベントを通知することができるか否かを表す。プリンタ３がそのＰＣに対してＷＳＤのイベントを通知することができる場合は「true」が、通知することができない場合は「false」が、要素８０２にセットされる。この例では、「false」がセットされており、プリンタ３がそのＰＣに対してＷＳＤのイベントを通知することができない状態を表す。

＜ans:MultipleJobsControl＞要素８０７はプライベート情報であり、プリンタ３が１つの印刷ジョブだけを受け付けて処理可能か、複数の印刷ジョブ要求を同時に受け付けて処理可能かを表す。プリンタ３が１つの印刷ジョブだけを受け付けて処理可能なプリンタである場合は「false」が、複数の印刷ジョブ要求を同時に受け付けて処理可能なプリンタである場合は「true」が要素８０７にセットされる。この例では、「false」がセットされており、プリンタ３が１つの印刷ジョブだけを受け付けて処理可能なプリンタであることを表す。

図１４はGetActiveJobsの内容を表す図であり、（ａ）はGetActiveJobsRequest、（ｂ）はGetActiveJobsResponseをそれぞれ表す。ここで、図１４の（ａ）に示すリクエストは、ＰＣ５がプリンタ３に発行するものの一例である。図１４の（ｂ）に示すレスポンスは、プリンタ３がＰＣ５に返すものの一例である。

＜wprt:ActiveJobs＞要素１４０３はパブリック情報であり、プリンタ３が処理中の全ての印刷ジョブに関する情報を表す。＜wprt:JobSummary＞要素１４０１はパブリック情報であり、プリンタ３が処理中の各印刷ジョブに関する情報を印刷ジョブ単位で表す。

＜wprt:ActiveJobs＞要素１４０３の中に＜wprt:JobSummary＞要素が０〜複数含まれる。図１８の（ｃ）に示す印刷ジョブ１４５（図１０の（ｂ）の管理番号１の印刷ジョブ）を表す＜wprt:JobSummary＞要素１４０１が＜wprt:ActiveJobs＞要素１４０３の中に１つだけ含まれているケースを表している。印刷が終了した印刷ジョブは＜wprt:ActiveJobs＞要素１４０３の中には含まれない。

従って、次の場合には、ＰＣからのリクエストに対するプリンタ３からのレスポンスの中の＜wprt:ActiveJobs＞要素１４０３の中には印刷ジョブ１４５の＜wprt:JobSummary＞要素１４０１は含まれない。つまり、図１０の（ｂ）に示す状態から印刷ジョブ１４５の印刷が終了した状態に変わった後、その後、次の印刷ジョブ（図１８の（ａ）に示す印刷ジョブ１４４）が開始されて図１０の（ｃ）に示す状態に変わった後。これにより、ＰＣ５は、GetActiveJobsオペレーションを使って印刷ジョブ１４５の印刷が終了したことを把握することができる。

＜wprt:JobId＞要素１４０２はパブリック情報であり、印刷ジョブのジョブＩＤがセットされている。このジョブＩＤは、この印刷ジョブを受け付けた時にプリンタ３からＰＣ５へ返された、図１９の（ｂ）に示すCreatePrintJobResponseの＜wprt:JobId＞要素１９０４にセットされているジョブＩＤと同一である。ここでは、ＰＣ５から発行された、図１８の（ｃ）に示す印刷ジョブ１４５に対してプリンタ３が割り当てた「１００１」というジョブＩＤがセットされている状態を表す。

＜wprt:JobState＞要素１４０４は、印刷ジョブの状態（処理状況）を表す値がセットされている。ここでは、印刷ジョブ１４５の図１０の（ｂ）のStatus欄に示す値がセットされている状態を表す。＜wprt:JobName＞要素１４０５はパブリック情報であり、この印刷ジョブの印刷ジョブ名がセットされる。この印刷ジョブ名は、図１９の（ａ）に示すCreatePrintJobRequestの＜wprt:JobName＞要素１９０２にセットされている印刷ジョブ名と同一である。

＜wprt:JobOriginatingUserName＞要素１４０６はパブリック情報であり、印刷ジョブを発行したユーザ名がセットされる。このユーザ名は、図１９の（ａ）に示すCreatePrintJobRequestの＜wprt:JobOriginatingUserName＞要素１９０３にセットされているユーザ名と同一である。

図２２はJobEndStateEventの内容を表す図である。図２２に示すイベントは、プリンタ３がＰＣ１に通知するものの一例であり、図１８の（ａ）に示す印刷ジョブ１４４のプリンタ３における印刷が終了し、図１８の（ｂ）に示す状態に移行した時の例を示す。

＜wprt:JobEndStateEvent＞要素２２０１はパブリック情報であり、印刷ジョブの終了を表す印刷終了イベント（JobEndStateEvent）を表す。＜wprt:JobEndState＞要素２２０２はパブリック情報であり、この印刷終了イベントの詳細情報を表す。

＜wprt:JobId＞要素２２０３はパブリック情報であり、印刷ジョブのジョブＩＤがセットされている。このジョブＩＤは、この印刷ジョブを受け付けた時にプリンタ３からＰＣ１へ返されたレスポンス内の＜wprt:JobId＞要素（不図示）にセットされているジョブＩＤと同一である。この例では、ＰＣ１から発行された、図１８の（ａ）に示す印刷ジョブ１４５に対してプリンタ３が割り当てた「１００２」というジョブＩＤ（図１０の（ｃ）の管理番号１の印刷ジョブ要求のwprt:JobId欄）がセットされている状態を表す。

＜wprt:JobCompletedState＞要素２２０４はパブリック情報であり、印刷ジョブが完了した時の状態を表す。この例では印刷ジョブが正常に完了したことを表す「Completed」がセットされている状態を表す。＜wprt:JobCompletedStateReasons＞要素２２０５はパブリック情報であり、印刷ジョブが完了した時の状態の理由が、この要素の中に１つ又は複数個含まれる。

＜wprt:JobCompletedStateReason＞要素２２０６はパブリック情報であり、印刷ジョブが完了した時の状態の理由を表す。この例では、印刷ジョブが正常に完了したことを表す「JobCompletedSuccessfully」がセットされている状態を表す。＜wprt:JobName＞要素２２０７はパブリック情報であり、印刷ジョブの印刷ジョブ名がセットされる。この印刷ジョブ名は、ＰＣ１から発行されたリクエスト内の＜wprt:JobName＞要素（不図示）にセットされている印刷ジョブ名と同一である。

＜wprt:JobOriginatingUserName＞要素２２０８はパブリック情報であり、印刷ジョブを発行したユーザ名がセットされる。このユーザ名は、ＰＣ１から発行されたリクエスト内の＜wprt:JobOriginatingUserName＞要素（不図示）にセットされているユーザ名と同一である。

図１８はプリンタキューを表す図である。図１８において、（ａ）と（ｂ）はＰＣ１内のプリンタキュー、（ｃ）〜（ｅ）はＰＣ５内のプリンタキューを表す図である。これらのプリンタキューは、ユーザ操作により左上部の「Printer」メニューから「Properties」を選択し、このプリンタキューのプロパティを開くことができる。そして、このプロパティ内の「Advanced」シートの中に「印刷後にドキュメントを残す」機能を選択する手段を備えており（不図示）、ユーザの操作によりこの機能のオン／オフを切り換えることができる。尚、この機能のデフォルトの設定値はオフである。

図１８の（ａ）において、印刷ジョブ１４４はＰＣ１がプリンタ３に対して発行したものである。印刷ジョブ１４４のステータス（Status）が「Printing」と表示されているので、印刷ジョブ１４４がプリンタ３で印刷中であることがわかる。

図１８の（ｂ）は、図１８の（ａ）で印刷中であった印刷ジョブ１４４の印刷が、プリンタ３において終了した後の状態を表す。この図から、印刷が終了した印刷ジョブ１４４が、ＰＣ１内のプリンタキューから削除され、表示されていないことがわかる。尚、ＰＣ１内のプリンタキューの状態が図１８の（ａ）から（ｂ）へ変化する過程において、次のように処理される。ＰＣ１が印刷ジョブ１４４の全ての印字データをプリンタ３に転送し終えた時点で、ＰＣ１内のプリンタキューは印刷ジョブ１４４のステータス（Status）が「Sent to printer」に変わる。その後、プリンタ３において、印刷が終了した時点で、印刷ジョブ１４４がＰＣ１内のプリンタキューから削除される。

図１８の（ｃ）において、印刷ジョブ１４５はＰＣ５がプリンタ３に対して発行したものである。印刷ジョブ１４５のステータス（Status）が「Printing」と表示されているので、印刷ジョブ１４５がプリンタ３で印刷中であることがわかる。

図１８の（ｄ）は、図１８の（ｃ）で印刷中であった印刷ジョブ１４５の印刷が、プリンタ３において終了した後の状態を表す。この図では、ＰＣ５が印刷ジョブ１４５の全ての印字データをプリンタ３に転送し終えており、かつ、プリンタ３で印刷ジョブ１４５の印刷が終了している状態である。しかしながら、印刷ジョブ１４５が「Sent to printer」のステータス（Status）の状態でＰＣ５内のプリンタキュー３２に残ってしまっている。これが、本発明で解決しようとしている従来例の問題点である。

図１８の（ｅ）は、（ｄ）の状態ではＰＣ５内のプリンタキュー３２に残ってしまっていた印刷ジョブ１４５がプリンタキュー３２から削除され、表示されていない状態を表す。図１８の（ｅ）では、本発明が従来例の問題点を解決し、ユーザの操作性に優れる例を表している。

図１２はランゲージモニタ３６におけるLM_WritePort()関数の処理を表すフローチャートである。図１２は本発明の特徴を最もよく表す図の内の１つである。図１２のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。

図１１のＳ１１０２において、スプーラ４０がランゲージモニタ３６のLM_WritePort()関数をコールすると、図１２において、ランゲージモニタ３６がLM_WritePort()関数の処理を開始する（Ｓ１２０１）。ランゲージモニタ３６は、ポートモニタ３７のPM_WritePort()関数をコールし、その関数の戻り値をlmRetに代入する（Ｓ１２０２）。ランゲージモニタ３６は、Ｓ１２０３でlmRetの値を確認し、TRUEの場合はＳ１２０４へ進み、TRUEではない（FALSEである）場合はＳ１２１１へ進む。

Ｓ１２０４において、ランゲージモニタ３６は、引数にwprt:PrinterDescriptionをセットし、ＷＳＤを制御するＷＳＤＡＰＩｓのGetPrinterElements（）関数をコールする。この関数内において、ＰＣ５はＷＳＤのプリントサービスのリクエスト（GetPrinterElementsRequest）をプリンタ３に発行する（Ｓ１２０４、図１１のＳ１１１０）。このリクエストに対してプリンタ３はレスポンス（GetPrinterElementsResponse）をＰＣ５に返す（Ｓ１２０４、図１１のＳ１１１１）。ＰＣ５がこのレスポンスを受け取ると、GetPrinterElements（）関数の戻り値にTRUEが代入され、呼び出し元であるランゲージモニタ３６に戻る（Ｓ１２０４、図１１のＳ１１１０）。

また、ＰＣ５がプリンタ３に対してリクエストを発行後、一定の時間内にレスポンスを受け取らなかった場合、GetPrinterElements（）関数の戻り値にFALSEを代入する。そして、呼び出し元であるランゲージモニタ３６に戻る（Ｓ１２０４、図１１のＳ１１１０）。ランゲージモニタ３６はGetPrinterElements（）関数の戻り値をlmRetに代入する（Ｓ１２０４、図１１のＳ１１１０）。

尚、ここでは、GetPrinterElements（）関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。また、Ｓ１２０４でＰＣ５が発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図８に示す。

ランゲージモニタ３６は、GetPrinterElements（）関数の引数として渡されたレスポンス内の＜ans:EventControl＞要素８０２にセットされている値を取得する（Ｓ１２０５）。ランゲージモニタ３６は、Ｓ１２０６で、この値が「false」であるか否かを確認し、「false」である場合はＳ１２０７へ進み、「false」ではない（「true」である）場合はＳ１２０８へ進む。

Ｓ１２０７において、ランゲージモニタ３６は、lmDeleteJobにTRUEを代入し、Ｓ１２０８へ進む。Ｓ１２０８において、ランゲージモニタ３６は、ＷＳＤを制御するＷＳＤＡＰＩｓのGetActiveJobs関数をコールする（図１１のＳ１１１４）。この関数内において、ＰＣ５はＷＳＤのプリントサービスのリクエスト（GetActiveJobsRequest）をプリンタ３に発行する（Ｓ１２０８、図１１のＳ１１１４）。

このリクエストに対してプリンタ３がレスポンス（GetActiveJobsResponse）をＰＣ５に返す（Ｓ１２０８、図１１のＳ１１１５）。ＰＣ５がこのレスポンスを受け取ると、GetActiveJobs関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ１２０８、図１１のＳ１１１４）。

また、ＰＣ５がプリンタ３に対してリクエストを発行後、一定の時間内にレスポンスを受け取らなかった場合、GetActiveJobs関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ１２０８、図１１のＳ１１１４）。ランゲージモニタ３６はGetActiveJobs関数の戻り値をlmRetに代入する（Ｓ１２０８、図１１のＳ１１１４）。

尚、ここでは、GetActiveJobs関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。Ｓ１１１４でＰＣ５が発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図１４に示す。

ランゲージモニタ３６は、GetActiveJobs関数の引数として渡されたGetActiveJobsResponse内の＜wprt:JobId＞要素１４０２にセットされている値を取得する（Ｓ１２０９、図１１のＳ１１１６）。そして、lmJobIdに代入し（Ｓ１２１０、図１１のＳ１１１６）、Ｓ１２１１へ進む。Ｓ１２１１において、ランゲージモニタ３６は、LM_WritePort()関数の戻り値として、lmRetをスプーラ４０に返し、LM_WritePort()関数の処理を終了し、呼び出し元であるスプーラ４０に戻る。

図１３はランゲージモニタ３６におけるLM_EndDocPort()関数の処理を表すフローチャートである。図１３は本発明の特徴を最もよく表す図の内の１つである。図１３のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。

ＰＣがプリンタ３に対して印刷ジョブを発行して印刷を行うケースにおいて、ＰＣがその印刷ジョブの全ての印刷データをプリンタ３に送信し終わった時、スプーラ４０がLM_EndDocPort()関数をコールする。そして、ランゲージモニタ３６がこのLM_EndDocPort()関数の処理を開始する。

図６のＳ６０８で、スプーラ４０がLM_EndDocPort()関数をコールすると、ランゲージモニタ３６がLM_EndDocPort()関数の処理を開始する（Ｓ１３０１）。ランゲージモニタ３６は、引数にwprt:PrinterDescriptionをセットし、ＷＳＤを制御するＷＳＤＡＰＩｓのGetPrinterElements（）関数をコールする（Ｓ１３０２）。この関数内において、ＰＣ５はＷＳＤのプリントサービスのリクエスト（GetPrinterElementsRequest）をプリンタ３に発行する（Ｓ１３０２、図６のＳ６１０）。

このリクエストに対して、プリンタ３はレスポンス（GetPrinterElementsResponse）をＰＣ５に返す（Ｓ１３０２、図６のＳ６１１）。ＰＣ５がこのレスポンスを受け取ると、GetPrinterElements（）関数の戻り値にTRUEを代入し、呼び出し元であるランゲージモニタ３６に戻る（Ｓ１３０２、図６のＳ６１０）。

ＰＣ５がプリンタ３に対してリクエストを発行後、一定の時間内に、レスポンスを受け取らなかった場合、GetPrinterElements（）関数の戻り値にFALSEを代入する。そして、呼び出し元であるランゲージモニタ３６に戻る（Ｓ１３０２、図６のＳ６１０）。ランゲージモニタ３６はGetPrinterElements（）関数の戻り値をlmRetに代入する（Ｓ１３０２、図６のＳ６１０）。

尚、ここでは、GetPrinterElements（）関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。また、Ｓ１３０２でＰＣ５が発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図８に示す。

ランゲージモニタ３６は、Ｓ１３０２のGetPrinterElements（）関数の引数として渡されたレスポンス内の＜wprt:DeviceId＞要素８０４にセットされている値を取得する。そして、その中に含まれるプリンタ３の状態を表す情報ＩＮＦＯ：ｘｘｘ（ｘｘｘは「０００」、「００１」の何れかの値）を取得する（Ｓ１３１１）。ランゲージモニタ３６は、ＩＮＦＯ：ｘｘｘを確認し、プリンタ３がオンラインでスタンバイ状態を表す「ＩＮＦＯ：０００」であると判定した場合はＳ１３０７へ進む。また、「ＩＮＦＯ：０００」ではない（「ＩＮＦＯ：００１」である）と判定した場合はＳ１３０２に戻る。ここで、プリンタ３がオンラインでスタンバイ状態であるということは、印刷が終了したしたことを意味する。

つまり、ランゲージモニタ３６は、Ｓ１３０２、Ｓ１３１１、Ｓ１３０３の一連の処理を繰り返すことで、プリンタ３における印刷が終了したか否かを見とどけ、印刷が終了した後に、Ｓ１３０７へ進む。

Ｓ１３０７において、ランゲージモニタ３６は、ポートモニタ３７のPM_EndDocPort()関数をコールし、その関数の戻り値をlmRetに代入する。ランゲージモニタ３６は、lmDeleteJobの値を確認し、TRUEの場合はＳ１３０４へ進み、TRUEではない（FALSEである）場合はステップＳ１３０９へ進む。Ｓ１３０４において、ランゲージモニタ３６は、プリンタキュー３２の「印刷後にドキュメントを残す」機能の設定値を確認し、オンの場合はＳ１３０９へ進み、オフの場合はＳ１３０６へ進む。

Ｓ１３０６において、ランゲージモニタ３６は、その印刷ジョブをプリンタキュー３２から削除する。このとき、例えば、ＯＳが提供しているSetJob()関数を利用し、その第５引数のCommandにJOB_CONTROL_RELEASEという値をセットし、この関数をコールすることで、プリンタキュー３２から印刷ジョブを削除することができる。

これは、ポートモニタ３７が印刷開始時にSetJob()関数を利用し、その第５引数のCommandにJOB_CONTROL_RETAINという値をセットしてこの関数をコールしているからである。
BOOL SetJob(
_in HANDLE hPrinter,
_in DWORD JobId,
_in DWORD Level,
_in LPBYTE pJob,
_in DWORD Command
);
Command [in]: The print job operation to perform. This parameter can be one of the following values.
JOB_CONTROL_RETAIN: Keep the job in the queue after it prints.
JOB_CONTROL_RELEASE: Release the print job.
JOB_CONTROL_RESTART: Restart the print job. A job can only be restarted if it was printing.
尚、SetJob()関数を利用する際に、第１〜第４引数にセットする値に関しては、一般的な情報である。そして、Microsoft Developer Network (MSDN)のサイトに記載されている情報であるので、ここでは説明を省略する。

Ｓ１３０９において、ランゲージモニタ３６は、lmDeleteJobにFALSEを代入して初期化し、lmJobIdに０を代入して初期化する（Ｓ１３１０）。ランゲージモニタ３６は、LM_EndDocPort()関数の戻り値として、lmRetをスプーラ４０に返し、LM_EndDocPort()関数の処理を終了し、呼び出し元であるスプーラ４０に戻る（Ｓ１３０５）。

Ｓ１３０４において、プリンタキュー３２の「印刷後にドキュメントを残す」機能がオンの場合、ランゲージモニタ３６が印刷ジョブをプリンタキュー３２から削除しないようにする。これにより、この機能が正しく動作し、印刷が終了した後もプリンタキュー３２にこの印刷ジョブが残る。

このように、図１０の（ａ）と（ｂ）で示されるケースにおいて、プリンタ３が、印刷が終了したことを表すイベントをＰＣ５に返すことができない場合にも、印刷が終了した印刷ジョブをプリンタキューから自動的に削除できる。従って、ユーザの操作性に優れる。

仮に、全ての印刷ジョブにおいて、ランゲージモニタがその印刷ジョブをプリンタキューから削除する処理を実装した場合に、プリンタが、印刷が終了したことを表すイベントをＰＣに返すことができるケースを考える。このようなケースでは、ポートモニタがJobEndStateEvent通知待ちプロセスの中で印刷が終了したその印刷ジョブをプリンタキューから削除し、またランゲージモニタもその印刷ジョブをプリンタキューから削除する。そのため、ポートモニタ又はランゲージモニタのどちらか一方で既に削除済みの印刷ジョブに対して、再度その印刷ジョブを削除しようとすることになる。その結果、プリンタキューから既に削除されている印刷ジョブを二重に削除しようとする処理が発生し、この処理によってＯＳ内で予期せぬ誤動作をまねく恐れがある、という問題が発生する。

そこで、本実施形態では、まず図１２のＳ１２０４、Ｓ１２０５で、ランゲージモニタ３６がGetPrinterElementsオペレーションを利用して＜ans:EventControl＞要素８０２を取得する。そして、ランゲージモニタ３６が、その値に応じて「false」の場合のみlmDeleteJobにTRUEを代入し、このlmDeleteにセットされた値がTRUEの時のみ、図１３のＳ１３０６においてプリンタキュー３２から印刷ジョブを削除する。

このように、ランゲージモニタ３６が＜ans:EventControl＞要素８０２を利用して制御を行うことで、上述の問題が発生することを防止でき、ＯＳ内で誤動作することのない、安全な周辺装置制御システムを実現することができる。

この例では、図１２のＳ１２０２でポートモニタ３７がCreatePrintJobオペレーションを実行した後、即ち印刷ジョブ要求発行後に、Ｓ１２０４でランゲージモニタ３６がGetPrinterElementsオペレーションを実行する。そして、＜wprt:EventControl＞要素８０２を取得する例を挙げた。ここではその理由を説明する。

ランゲージモニタ３６はＳ１２０４のGetPrinterElementsオペレーションにより、図８に示すようなDevice IDも取得している。これは、CreatePrintJobオペレーションで発行された印刷ジョブに含まれる最初の印刷制御コマンドがＰＣ５から送信された後、ランゲージモニタ３６は、プリンタ３と双方向通信を行うことができるか否かを確認する。そのために、ランゲージモニタ３６は、Device IDの取得を試みることで、プリンタ３から送られてくるデータを受信することができるか否かを判別する。

Ｓ１２０４において、ランゲージモニタ３６がDevice IDを取得するためにGetPrinterElementsオペレーションを発行することは従来例から実施されていた。本実施形態では、このＳ１２０４のGetPrinterElementsオペレーションを利用し、Device IDと＜wprt:EventControl＞要素８０２を同時に取得している。これにより、＜wprt:EventControl＞要素８０２を取得するだけの目的でランゲージモニタ３６がGetPrinterElementsオペレーションを発行する機会を増やすことがなくなる。更に、ネットワーク４におけるトラフィックを必要最小限に抑えることができ、ネットワーク４上のＰＣやデバイスに悪影響を与えることがない。

尚、ランゲージモニタ３６が、前述したような双方向通信ができるか否かを確認する必要がない場合等では、この例に限られることはない。そのような場合、例えば、ポートモニタ３７がCreatePrintJobオペレーションを実行する前、即ち印刷ジョブ要求発行前に、ランゲージモニタ３６がGetPrinterElementsオペレーションを実行する。そして、＜wprt:EventControl＞要素８０２を事前に取得しても実現することができ、同様な効果を得ることができる。

その際に、ランゲージモニタ３６が行っているプリンタキュー３２の「印刷後にドキュメントを残す」機能の設定値の確認処理を、上述のGetPrinterElementsオペレーションを実行する前に行っても良い。この確認処理は、図１３のＳ１３０４や図１５で後述するＳ１５０４に相当する。この場合、「印刷後にドキュメントを残す」機能の設定値がオフの時だけ、ランゲージモニタ３６が＜wprt:EventControl＞要素８０２を取得するためにGetPrinterElementsオペレーションを実行すれば良い。

これにより、不要なGetPrinterElementsオペレーションを実行することがなくなる。その結果、不要なリクエスト（GetPrinterElementsRequest）やレスポンス（GetPrinterElementsResponse）の通信も行われないので、ネットワーク４のトラフィックの上昇を防ぐことができる。

図２０はプリンタ３におけるCreatePrintJobの処理を表すフローチャートである。図２０のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。

図１１のＳ１１０６において、ＰＣ（ＰＣ５）からプリンタ３にCreatePrintJobRequest（例えば、図１９の（ａ）のリクエスト）が発行されると、Ｓ２００１が開始される。プリンタ３は、このリクエストを受信する（Ｓ２００２）。次に、＜wprt:JobName＞要素１９０２にセットされている印刷ジョブ名と＜wprt:JobOriginatingUserName＞要素１９０３にセットされているユーザ名を取得する（Ｓ２００３）。次に、ＰＣ５のコンピュータ名（Computer Name）を取得する（Ｓ２００４）。本実施形態では、ＷＳＤのプリントサービス宛てのHTTP POSTでのＴＣＰ受信ソケットからＩＰアドレスを取得し、このＩＰアドレスに基づいてコンピュータ名を取得する。

尚、ここでは説明を分かり易くするために、このようにＩＰアドレスからコンピュータ名を取得し、このコンピュータ名を用いてＰＣ（ＰＣ５）を特定して各処理を行っているが、ＩＰアドレスを用いてＰＣ５を特定して各処理を行っても良い。

プリンタ３は、取得した印刷ジョブ名とユーザ名とコンピュータ名を一時的に保存する（Ｓ２００５）。そして、図１０の（ｂ）や（ｃ）に示す印刷キューデータベース１２４を参照し、印刷処理中の印刷ジョブ要求の有無を確認する（Ｓ２００６）。ここで、印刷処理中の印刷ジョブ要求が有ると判断した場合はＳ２００８へ進み、無いと判断した場合はＳ２０１０へ進む（Ｓ２００７）。Ｓ２００８では、プリンタ３はＰＣ（ＰＣ５）から要求された印刷ジョブ要求にジョブＩＤを割り当て、この印刷ジョブ要求をStatus「Not Accepted」として印刷キューデータベース１２４に登録する。そして、印刷ジョブ要求を受け付けることができなかったことを表すFault（ServerErrorNotAcceptingJobs）をＰＣ５に返し（Ｓ２００９）、この処理を終了する（Ｓ２０１３）。

Ｓ２０１０では、プリンタ３は、ＰＣ５から要求された印刷ジョブ要求にジョブＩＤを割り当て、この印刷ジョブ要求をStatus「Processing」として印刷キューデータベース１２４に登録する。そして、ジョブＩＤを＜wprt:JobId＞要素１９０４にセットする（Ｓ２０１１）。次に、この印刷ジョブを受け付けて処理することを表す応答であるレスポンス（CreatePrintJobResponse）、例えば図１９の（ｂ）を用意する。そして、その中にＳ２０１１でセットした＜wprt:JobId＞要素１９０４及びその他の各情報をセットし、ＰＣ５に返信し（Ｓ２０１２）、この処理を終了する（Ｓ２０１３）。

図９は、プリンタ３におけるGetPrinterElementsの処理を表すフローチャートである。図９は本発明の特徴を最もよく表す図の内の１つである。図９のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。

ＰＣがプリンタ３へGetPrinterElementsRequestを発行したとき、プリンタ３はこれを受けて図９に示す処理を実行する。本発明においてこのリクエストを発行するタイミングとして最も望ましいのは、ＰＣがその印刷ジョブの全ての印刷データをプリンタ３に送信し終わった時である。尚、例えば、その印刷ジョブの印刷開始時や印刷中等、他のタイミングでこの処理を実行しても良い。

図１２のＳ１２０４において、ＰＣ５からプリンタ３にリクエスト（GetPrinterElementsRequest）、例えば図８（ａ）が発行されると、Ｓ９０１が開始される。プリンタ３がリクエストを受信する（Ｓ９０２）。そして、このリクエストから＜wprt:Name＞要素（例えば８０１）にセットされている値を確認し、一時的に保存しておく（Ｓ９０３）。ここで、リクエストの中に複数の＜wprt:Name＞要素が存在する場合、全ての要素にセットされている値を一時的に保存しておく。

次に、プリンタ３は、＜wprt:Name＞要素にセットされている値として、wprt:PrinterDescriptionを発見した場合はＳ９０５へ進み、発見しなかった場合はＳ９１１へ進む（Ｓ９０４）。Ｓ９０５では、プリンタ３は図１０の（ａ）のイベント管理データベース１２３を参照し、リクエストの発行元のＰＣに対してＷＳＤのイベントを返すことができるか否かを確認する。その結果、ＰＣ５に対してＷＳＤのイベントを返すことができる場合はＳ９０７へ進み、返すことができない場合Ｓ９０８へ進む（Ｓ９０６）。

Ｓ９０７では、プリンタ３は、＜ans:EventControl＞要素８０２に「true」をセットし、Ｓ９０９へ進む。Ｓ９０８では、プリンタ３は、＜ans:EventControl＞要素８０２に「false」をセットし、Ｓ９０９へ進む。Ｓ９０９では、プリンタ３はDevice IDを生成する。このとき、プリンタ３の状態を確認し、その時の状態に応じた値を、Device IDに含まれるプリンタ３の状態を表す情報INFOにセットする。ここでは、オンラインでスタンバイ状態を表す「０００」か、印刷処理中（Processing）を表す「００１」の何れかがセットされる。

次に、プリンタ３は、＜wprt:DeviceId＞要素８０４に、Ｓ９０９で生成されたDevice IDをセットし、Ｓ９１１へ進む（Ｓ９１０）。Ｓ９１１では、プリンタ３は、Ｓ９０７、Ｓ９０８、Ｓ９１０で各情報等がセットされたレスポンス（GetPrinterElementsResponse）をＳ９０２で受信したリクエストに対する応答としてＰＣ５に返信する。そして、この処理を終了する（Ｓ９１２）。

図２１はプリンタ３におけるGetActiveJobsの処理を表すフローチャートである。図２１のフローに係るプログラムは、ＲＯＭ１６に記憶されており、ＲＡＭ１７に読み出され、ＣＰＵ１５により実行される。

図１２のＳ１２０８又は図１６のＳ１６０２において、ＰＣ５からプリンタ３にリクエスト（GetActiveJobsRequest）、例えば図１４の（ａ）が発行され、Ｓ２１０１が開始される。プリンタ３は、このリクエストを受信した後（Ｓ２１０２）、図１０の（ｂ）や（ｃ）に示す印刷キューデータベース１２４を参照し、印刷処理中の印刷ジョブ要求の有無を確認する（Ｓ２１０３）。ここで、印刷処理中の印刷ジョブ要求が有ると判断した場合はＳ２１０５へ進み、無いと判断した場合はＳ２１０７へ進む（２１０４）。Ｓ２１０５では、プリンタ３は＜wprt:JobSummary＞要素１４０１に、印刷処理中の印刷ジョブ要求に関する以下に示すような各情報をセットする。
＜wprt:JobId＞要素１４０２
＜wprt:JobState＞要素１４０４
＜wprt:JobName＞要素１４０５
＜wprt:JobOriginatingUserName＞要素１４０６

例えば、プリンタ３が複数の印刷ジョブ要求を同時に受け付けて処理できるような印刷キューを備え、同時に印刷処理中の場合、全ての印刷ジョブ要求に対してそれぞれ＜wprt:JobSummary＞要素を用意する。そして、その中にそれぞれの印刷ジョブ要求に関する各情報をセットする。

プリンタ３は、＜wprt:ActiveJobs＞要素１４０３に、Ｓ２１０５で用意した＜wprt:JobSummary＞要素１４０１をセットする（Ｓ２１０６）。Ｓ２１０７では、プリンタ３は、Ｓ２１０６でセットした＜wprt:ActiveJobs＞要素１４０３及びその他の各情報がセットされたレスポンス（GetActiveJobsResponse）をリクエストに対する応答としてＰＣ５に返信する。そして、この処理を終了する（Ｓ２１０８）。

実施形態１で説明した周辺装置制御システムは、印刷中の記録紙のジャムをリカバリーして、ジャムが発生して印刷に失敗したページから再印刷する紙ジャムエラーリカバリー処理に対応している。

この紙ジャムエラーリカバリー処理の詳細は、次に示す通りである。ランゲージモニタ３６は、ある印刷ジョブを印刷中にプリンタ３から印刷中のページ番号とエラーの有無の情報を、例えば５秒に１回の時間間隔で定期的に取得する。そして、取得した情報を印刷制御に関する情報を保存するための印刷制御用構造体（不図示、物理的にはＲＡＭ２０１に該当）に保存する。記録紙のジャムが発生した場合、ランゲージモニタ３６はプリンタ３から紙ジャムエラー情報を取得し、その紙ジャムエラー情報を印刷制御用構造体に保存する。

この状態において、印刷制御用構造体には、紙ジャムエラー情報と、紙ジャムエラーが発生したページ番号が保存されている。LM_WritePort()関数内において、ランゲージモニタ３６は、SetJob()関数を利用してその第５引数のCommandにJOB_CONTROL_RESTARTという値をセットする。そして、印刷ジョブを再印刷するために、この関数をコールした後、LM_WritePort()関数の処理を終了して呼び出し元であるスプーラ４０に処理を戻す。

スプーラ４０は、印刷ジョブを再印刷するための新しい印刷ジョブを生成し、プリンタキュー３２にその新しい印刷ジョブをスタックし、ランゲージモニタ３６のLM_EndDocPort()関数をコールする。ランゲージモニタ３６は図１３に示すLM_EndDocPort()関数の処理を実行し、Ｓ１３０１とＳ１３０２の間でプリンタ３にリセットコマンドを送信し、その後、Ｓ１３０２及びそれ以降の処理を実行し、呼び出し元であるスプーラ４０に処理を戻す。

プリンタ３は、リセットコマンドを受信すると、ＲＡＭ１７に一時的に格納されている紙ジャムエラーを発生した印刷ジョブの残りの印字データを破棄し、エラー状態を解除する。このとき、プリンタ３は、Device IDの中に含まれるプリンタ３の状態を表す情報INFO:に、オンラインでスタンバイ状態を表す「000」をセットする。スプーラ４０は、紙ジャムエラーを発生した印刷ジョブを修了し、再印刷用の新しい印刷ジョブを開始する。

ランゲージモニタ３６は、LM_WritePort()関数内でこの再印刷された新しい印刷ジョブの印字データを受け取った後、印刷制御用構造体を参照する。ここで紙ジャムエラー情報がセットされている場合は、紙ジャムエラーが発生したページ番号を参照し、その前のページまでの印字データをプリンタ３へ送信せずに読み捨てる。そして、紙ジャムエラーが発生したページ及びそれ以降のページの印字データをプリンタ３へ送信する。

プリンタ３は、印字データに従って印刷処理を実行し、紙ジャムエラーが発生したページから再印刷を行う。紙ジャムエラーリカバリー処理中に、ランゲージモニタ３６がLM_EndDocPort()関数の処理を実行し、印刷終了を表すイベントを通知できない場合、Ｓ１３０６でプリンタキュー３２から紙ジャムエラーを発生した印刷ジョブを削除する。

このように、紙ジャムエラーリカバリー処理中において、紙ジャムエラーで印刷に失敗した印刷ジョブをランゲージモニタ３６がステップＳ１３０６でプリンタキュー３２から削除する。これにより、紙ジャムエラーで印刷に失敗した印刷ジョブが、「Sent to printer」のステータス（Status）の状態でプリンタキュー３２に残ることがなく、操作性に優れた周辺装置制御システムを実現することができる。

実施形態では周辺装置の例としてプリンタ３を挙げたが、プリンタ、ＦＡＸ、スキャナ、ストレージ等を搭載したマルチファンクションプリンタ（ＭＦＰ）にも、本発明は有効である。ＷＳＤを搭載したＭＦＰの場合、プリンタ、ＦＡＸ、スキャナのそれぞれの機能に対して次に示すようなＷＳＤの各Ｓｅｒｖｉｃｅを割り当てることが可能である。
機能 ＷＳＤのサービス 備考
プリンタ プリントサービス プリンタ機能用
ＦＡＸ プリントサービス ＦＡＸ機能用
スキャナ スキャンサービス

ここで、各機能のサービスに割り当てられているServiceIdは、次の通りである。
プリンタ： ＜wsdp:ServiceId＞http://schemas.abc.xxx/Printer＜/wsdp:ServiceId＞
ＦＡＸ： ＜wsdp:ServiceId＞http://schemas.abc.xxx/Fax＜/wsdp:ServiceId＞
スキャナ： ＜wsdp:ServiceId＞http://schemas.abc.xxx/Scanner＜/wsdp:ServiceId＞
プリンタ機能及びＦＡＸ機能には、どちらもプリントサービスが割り当てられており、ServiceIDがプリンタ機能用とＦＡＸ機能用とで異なっている。そのため、プリンタ機能及びＦＡＸ機能のServiceTypeは、どちらもPrinterServiceTypeとなる。

上述した通り、ランゲージモニタ３６は、ＷＳＤＡＰＩｓのGetPrinterElements（）関数を使ってＰＣ５からプリンタ３にGetPrinterElementsRequestを発行する。そしてプリンタ３からＰＣ５に返されるGetPrinterElementsResponseを受け取ることができる。このとき、GetPrinterElements（）関数に次に示すようにServiceTypeを指定してこの関数をコールすることで、GetPrinterElementsを利用することができる。
＜portType name="PrinterServiceType" wse:EventSource="true"＞
＜operation name="GetPrinterElements"＞
＜input message="wprt:GetPrinterElementsRequestMsg"
wsa:Action="http://schemas.yyyy.xxx/YYYY/MM/wdp/print/
GetPrinterElements" /＞
＜output message="wprt:GetPrinterElementsResponseMsg"
wsa:Action="http://schemas.yyyy.xxx/YYYY/MM/wdp/print/
GetPrinterElementsResponse" /＞
＜/operation＞
＜/portType＞

しかしながら、ＭＦＰの場合、プリンタ機能及びＦＡＸ機能のServiceTypeはどちらもPrinterServiceTypeという同一のタイプである。そのため、ServiceTypeを指定して上述の関数をコールしても、プリンタ機能とＦＡＸ機能を区別してその機能に関する情報を取得することができない、という問題に直面する。そこで、ＭＦＰの場合、ランゲージモニタ３６がServiceIDを指定して関数をコールすることでプリンタ機能又はＦＡＸ機能を指定し、指定した機能に関する情報をGetPrinterElementsを利用して取得することができる。これにより、プリンタ機能とＦＡＸ機能とを備えるＭＦＰに対しても、誤動作を防止して正確な制御が可能な周辺装置制御システムを実現することができる。

＜実施形態２＞
実施形態１では、プリンタ３が複数の印刷ジョブを同時に受け付けて処理することができず、１つの印刷ジョブだけを受け付けて処理することができる例を挙げた。実施形態２では、ランゲージモニタ３６が、自身が発行（送信）した印刷ジョブのプリンタ３における印刷が終了したか否かを見とどけ、必要に応じてプリンタキュー３２からその印刷ジョブを削除する方法を説明する。

しかしながら、例えばプリンタ３が複数の印刷ジョブ要求を同時に受け付けて処理することができるような印刷キューを備える場合、ランゲージモニタ３６が発行（送信）した印刷ジョブが、必ずしもプリンタ３において直ちに印刷されるわけではない。プリンタ３内の印刷キューに入るだけで、印刷が開始されないケースも存在する。

ここで、プリンタ３が１０個の印刷ジョブを同時に受け付けて処理できる場合、ＰＣ１において印刷ジョブ１４４の印刷が行われ、プリンタ３がＰＣ１から発行された印刷ジョブ要求を印刷中にＰＣ５において同時に複数の印刷が行われる。そして複数の印刷ジョブがＰＣ５内のプリンタキュー３２にスタックされるような例を考える。

まず、ＰＣ５において、スプーラ４０がプリンタキュー３２にスタックされている１つ目の印刷ジョブ１４５の印刷を開始すると、ＰＣ５はプリンタ３にこの印刷ジョブ１４５の印刷ジョブ要求を発行する。プリンタ３は、ＰＣ１から発行された印刷ジョブ要求を受け付けて印刷中であるため、プリンタ３内の印刷キューにＰＣ５から送られてくる印字データを格納するものの、ＰＣ５から発行された印刷ジョブ要求の印刷処理を開始することはできない。

ＰＣ５（ランゲージモニタ３６）が印刷ジョブ１４５の全ての印字データをプリンタ３に送信し終わると、ランゲージモニタ３６は、図１３のＳ１３０２、Ｓ１３１１、Ｓ１３０３を繰り返す。そして、その印刷ジョブ１４５のプリンタ３における印刷が終了することを確認する（見とどける）。しかしながら、ランゲージモニタ３６は、プリンタ３において未だ印刷が開始されていない印刷ジョブ１４５の印刷状況を監視して、その印刷が終了するまで見とどけることになる。そのため、スプーラ４０に制御を戻すことができず、ＰＣ５（スプーラ４０）は次の印刷ジョブ（不図示）を発行することができない。このような問題に対する解決策を図１５及び図１６を用いて説明する。

図１５はランゲージモニタ３６におけるLM_EndDocPort()関数の処理を表すフローチャートである。図１５は本発明の特徴を最もよく表す図の内の１つである。図１５のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。

ＰＣがプリンタ３に対して印刷ジョブを発行して印刷を行うケースにおいて、ＰＣがその印刷ジョブの全ての印刷データをプリンタ３に送信後、スプーラ４０がLM_EndDocPort()関数をコールする。そして、ランゲージモニタ３６がこのLM_EndDocPort()関数の処理を開始する。

図６のＳ６０８において、スプーラ４０がランゲージモニタ３６のLM_EndDocPort()関数をコールすると、図１５において、ランゲージモニタ３６がこの関数の処理を開始する（Ｓ１５０１）。ランゲージモニタ３６は、ポートモニタ３７のPM_EndDocPort()関数をコールし、その関数の戻り値をlmRetに代入する（Ｓ１５０２）。ランゲージモニタ３６は、lmDeleteJobの値を確認し、TRUEの場合はＳ１５０４へ進み、TRUEではない（FALSEである）場合はＳ１５０７へ進む（Ｓ１５０３）。

Ｓ１５０４では、ランゲージモニタ３６はプリンタキュー３２の「印刷後にドキュメントを残す」機能の設定値を確認し、オンの場合はＳ１５０７へ進み、オフの場合はＳ１５０６へ進む。Ｓ１５０６では、ランゲージモニタ３６は、別プロセスを起動し、そのプロセスの中で図１６に示す印刷ジョブの監視と削除の処理を実行する。

また、Ｓ１５０７では、ランゲージモニタ３６は、lmDeleteJobにFALSEを代入して初期化し、lmJobIdに０を代入して初期化する（Ｓ１５０８）。ランゲージモニタ３６は、LM_EndDocPort()関数の戻り値として、lmRetをスプーラ４０に返し、LM_EndDocPort()関数の処理を終了し、呼び出し元であるスプーラ４０に戻る（Ｓ１５０５）。

図１６はランゲージモニタ３６における印刷ジョブの監視と削除の処理を表すフローチャートである。図１６は本発明の特徴を最もよく表す図の内の１つである。図１６のフローに係るプログラムは、ＨＤＤ２０２に記憶されており、ＲＡＭ２０１に読み出され、ＣＰＵ２０４により実行される。

図１５のＳ１５０６において、ランゲージモニタ３６が別プロセスを起動して印刷ジョブの監視と削除の処理を実行すると、図１６において、ランゲージモニタ３６が印刷ジョブの監視と削除の処理を開始する（Ｓ１６０１）。ランゲージモニタ３６は、ＷＳＤを制御するＷＳＤＡＰＩｓのGetActiveJobs関数をコールする（Ｓ１６０２）。この関数内において、ＰＣ５はＷＳＤのプリントサービスのリクエスト（GetActiveJobsRequest）をプリンタ３に発行する。このリクエストに対して、プリンタ３はレスポンス（GetActiveJobsResponse）をＰＣ５に返信する（Ｓ１６０２）。ＰＣ５がレスポンスを受け取ると、GetActiveJobs関数の戻り値にTRUEを代入し、呼び出し元に戻る（Ｓ１６０２）。

ＰＣ５がプリンタ３に対してリクエストを発行後、一定時間内にレスポンスを受け取らなかった場合、GetActiveJobs関数の戻り値にFALSEを代入し、呼び出し元に戻る（Ｓ１６０２）。Ｓ１６０２において、ランゲージモニタ３６はGetActiveJobs関数の戻り値をlmRetに代入する。尚、ここでは、GetActiveJobs関数の戻り値としてFALSEが返されるようなエラーケースの説明は省略する。

Ｓ１６０２でＰＣが発行するリクエストと、リクエストに対してプリンタ３が返信するレスポンスの詳細に関しては図１４で説明する。ランゲージモニタ３６は、Ｓ１６０２のGetActiveJobs関数の引数として渡されたレスポンス内の＜wprt:ActiveJobs＞要素１４０３内の各＜wprt:JobSummary＞要素にセットされている情報を取得する（Ｓ１６０３）。そして、ランゲージモニタ３６は、それぞれの＜wprt:JobSummary＞要素内の＜wprt:JobId＞要素にセットされている値を取得して、lmJobIdと同じ番号の印刷処置中の印刷ジョブの有無を確認する（Ｓ１６０３）。ランゲージモニタ３６が、＜wprt:ActiveJobs＞要素１４０３内の各＜wprt:JobSummary＞要素に含まれる＜wprt:JobId＞要素の中に、lmJobIdと同じ値が有ると判断した場合はＳ１６０２に戻る。

また、無いと判断した場合はＳ１６０５へ進み、ランゲージモニタ３６は、lmJobIdにセットされているジョブＩＤの印刷ジョブをプリンタキュー３２から削除する。そして、ランゲージモニタ３６は印刷ジョブの監視と削除の処理を終了し、これに伴い、このプロセスも終了する（Ｓ１６０６）。

図１５のＳ１５０６において、ランゲージモニタ３６が別プロセスを起動して印刷ジョブの監視と削除の処理を実行する。これにより、図１６に示す印刷ジョブの監視と削除処理の終了を待つことなく、図１５のＳ１５０７、Ｓ１５０８、Ｓ１５０５の処理が行われ、呼び出し元であるスプーラ４０に制御を戻すことができる。

よって、プリンタ３が複数の印刷ジョブ要求を同時に受け付けて処理できるような印刷キューを備える場合にも、プリンタ３における他の印刷ジョブ要求の印刷処理状況の影響を受けることなく、処理できる。即ち、ＰＣ５（スプーラ４０）がプリンタキュー３２にスタックされた複数の印刷ジョブを、プリンタ３に順次発行することができる。

更に、図１０の（ａ）で示されるケースにおいて、プリンタ３が、印刷が終了したことを表すJobEndStateEventのイベントをＰＣ５に返信することができない場合にも、印刷が終了した印刷ジョブ（印刷ジョブ１４５）を削除できる。即ち、図１８の（ｅ）に示すようにＰＣ５内のプリンタキュー３２から自動的に削除することができるので、ユーザの操作性に優れる。

尚、図１５のステップＳ１５０６において、ランゲージモニタ３６が別プロセスを起動して印刷ジョブの監視と削除の処理を実行する例を挙げたが、この例に限られるものではない。例えば、既に別プロセスで起動中のステータスモニタ３９で、図１６に示すような印刷ジョブの監視と削除の処理を実行することでも、実現可能であり、同様な効果を得ることができる。

また、例えばネットワーク４上の複数のプリンタの状態や印刷ジョブの状況を表示し、プリンタや印刷ジョブを操作することができるようなプリンタ管理アプリケーション（不図示）等で図１６に示すような印刷ジョブの監視と削除の処理を実行する。これによっても、実現可能であり、同様な効果を得ることができる。

実施形態２では、プリンタ３において実際に印刷ジョブが処理されて、印刷が完了した時点で、プリンタキュー３２からその印刷ジョブを削除する例（第１の例）を挙げたが、この例以外にも本発明を適用することができる。

ＰＣ５からプリンタ３へある印刷ジョブの印字データを全て送信し、プリンタ３がその印字データを全て受信した時点でプリンタキュー３２からその印刷ジョブを削除するようにしても良い（第２の例）。即ち、その印刷ジョブのステータス（Status）が「Sent to printer」に変わった時点で、プリンタキュー３２からその印刷ジョブを削除する。この例の場合、ＰＣ１からプリンタ３へ印刷ジョブが発行されたケースでは、プリンタ３は、その印刷ジョブの印字データを全て受信した時点で、ＰＣ１に印刷終了を表すイベントを通知する。

ＰＣ１において、ポートモニタは、このイベントを受信すると、プリンタキューからその印刷ジョブを削除する。ＰＣ５からプリンタ３へ印刷ジョブが発行されたケースでは、プリンタ３は、その印刷ジョブの印字データを全て受信した時点で、ＰＣ５に印刷終了を表すイベントを通知できない。そのため、ここでは、ランゲージモニタが、図１６に示すようなGetActiveJobsオペレーションを利用した印刷ジョブの監視と削除の処理を行うことで、プリンタキュー３２からその印刷ジョブを削除する。

但し、図１６では、ランゲージモニタ３６が、Ｓ１６０４でその印刷ジョブの有無を確認し、印刷ジョブが無い場合にＳ１６０５においてプリンタキュー３２からその印刷ジョブを削除していたが、代わりに次に示すような処理を行う。

ランゲージモニタ３６は、印刷ジョブがある場合、その印刷ジョブのJobStateがPendingで、かつJobStateReasonがJobIncomingであるか否かを確認する。確認の結果、ＹＥＳの場合、ランゲージモニタ３６はＳ１６０５へ進み、プリンタキュー３２からその印刷ジョブを削除する。それ以外の場合はＳ１６０２へ戻る。このように、ランゲージモニタ３６が、プリンタキュー３２から印刷ジョブを削除する方法は、プリンタ３又は周辺装置制御システムの種類により複数の例が考えられる。

実施形態２で説明した第１の例が最も一般的であると考えられる。実施形態２で説明した第２の例は、プリンタ３の処理能力が高く、信頼性も高いような、印刷に失敗することや印刷に時間を要すことがほとんど無いケースにおいて、ＰＣ内のプリンタキューの表示が見やすくなる、という効果がある。

今、実施形態１で説明した１つの印刷ジョブだけを受け付けて処理できるプリンタと、実施形態２で説明した複数の印刷ジョブ要求を同時に受け付けて処理できるプリンタを、１つのプリンタドライバ５０で制御するケースを考える。

図６のＳ６０６の後に、ランゲージモニタ３６は、LM_StartDocPort()関数内においてlmMultipleJobsにFALSEを代入して初期化する。また、図６のＳ６１６の後に、ランゲージモニタ３６はLM_EndDocPort()関数内においてlmMultipleJobsにFALSEを代入して初期化する。このlmMultipleJobsはランゲージモニタ３６内で使用されるフラグであり、プリンタ３が１つの印刷ジョブだけを受け付けて処理できるプリンタである場合にFALSEがセットされる。また、複数の印刷ジョブ要求を同時に受け付けて処理できるプリンタである場合にはTRUEがセットされる。

Ｓ１２０４、Ｓ１２０５において、ランゲージモニタ３６は、引数にwprt:PrinterDescriptionをセットし、ＷＳＤを制御するＷＳＤＡＰＩｓのGetPrinterElements（）関数をコールする。そして、＜ans:EventControl＞要素８０２にセットされている値を取得する。このとき、ランゲージモニタ３６は、＜ans:MultipleJobsControl＞要素８０７にセットされている値も取得する。この値が「true」の場合、ランゲージモニタ３６はlmMultipleJobsにTRUEをセットする。

ここで、図１３のＳ１３０１と図１５のＳ１５０１は同一の関数ポインタであると仮定する。図６のＳ６０９において、ランゲージモニタ３６は、LM_EndDocPort()関数の処理を開始した直後（Ｓ６１０の前）に、lmMultipleJobsにセットされている値を確認する。ここで、FALSEの場合は図１３のＳ１３０２へ進み、TRUEの場合は図１５のＳ１５０２へ進む。

これにより、プリンタドライバ５０が、実施形態１で説明したプリンタと、実施形態２で説明したプリンタとを、自動的に判別して制御し、本発明の実施形態１と実施形態２を実現することができる。

＜実施形態３＞
実施形態１で説明したように、一般的にプリンタがＰＣへ通知するイベントの制御に関しては、そのプリンタのハードウェアリソースの制限の影響を大きく受ける。具体的な例を挙げると、例えば実施形態１の図１０の（ａ）に示す例では、プリンタ３はＰＣ１とＰＣ２に対してイベントを通知することができるが、ＰＣ５に対してイベントを通知することができない。

実施形態３では、この問題を解決し、しかも、本発明の課題も解決する例を、図１０の（ｄ）と図１７を用いて説明する。図１０の（ｄ）は、プリンタ３がＰＣに通知するＷＳＤのイベントを管理するイベント管理データベースを表す図である。この図は本発明の特徴を最もよく表す図の内の１つである。

実施形態３では、ＰＣに通知するイベントの数を制限することで、プリンタがイベントを通知できるＰＣの数を増やす方法を提案する。図１０の（ｄ）に示すイベント管理データベース１２５は以下のように構成されている。

Subscribed Event欄には、ＰＣから発行されたＷＳＤの各イベントの登録要求が保存されている。次のans:EventControl2欄には、各イベントの登録要求に対して、プリンタ３が登録を許可したか否かを表す情報が保存されている。ここで、「true」はそのイベントの登録要求に対して許可したことを表し、「false」はそのイベントの登録要求に対して拒絶したことを表す。また、プリンタ３が、ＷＳＤのプリントサービスで定義されている６つのイベントの内、以下に示すの２つのイベントだけをＰＣに通知し、それ以外の４つのイベントの通知は行わない例を示している。
JobStatusEvent（処理状況を表すイベント）
JobEndStateEvent（印刷が終了したことを表すイベント）
これら２つのイベントは、ＰＣ内のプリンタキューにおいて、スプーラが印刷ジョブを制御する際に利用される。この例では、プリンタ３は、ＰＣ１、ＰＣ２、ＰＣ５に対して２つのイベントの通知を行うことができる状態であることを示している。従って、プリンタ３は、図１０の（ｂ）に示すような、管理番号（Ｎｏ．）１のＰＣ５からの印刷ジョブ要求に対して、その処理状況を表すイベントや印刷が終了したことを表すイベントをＰＣ５に通知することができる。

図１７の（ａ）はGetPrinterElementsRequest、（ｂ）はGetPrinterElementsResponseをそれぞれ表す。図は本発明の特徴を最もよく表す図の内の１つである。図１７の（ａ）、（ｂ）において、図８で既に説明した要素８０１、８０６、８０３、８０５、８０４に関しては、その説明を省略する。

図１７の（ａ）は、ＰＣ５がプリンタ３に発行するリクエストの一例である。＜ans:EventControl2＞要素１７０１はプライベート情報である。プリンタ３がＰＣに対してＷＳＤのプリントサービスDefinition Version 1.0で定義されている各イベントを通知することができるか否かを表す情報が含まれている。

＜ans:PrinterElementsChangeEvent＞要素１７０２には、次のようにセットされる。プリンタ３がＰＣに対してPrinterElementsChangeEventを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「false」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができない状態を表す。

＜ans:PrinterStatusSummaryEvent＞要素１７０３には、次のようにセットされる。プリンタ３がＰＣに対してPrinterStatusSummaryEventイベントを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「false」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができない状態を表す。

＜ans:PrinterStatusConditionEvent＞要素１７０４には、次のようにセットされる。プリンタ３がＰＣに対してPrinterStatusConditionEventを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「false」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができない状態を表す。

＜ans:PrinterStatusConditionClearedEvent＞要素１７０５には、次のようにセットされる。プリンタ３がＰＣに対してPrinterStatusConditionClearedEventを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「false」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができない状態を表す。

＜ans:JobStatusEvent＞要素１７０６には、次のようにセットされる。プリンタ３がＰＣに対してJobStatusEventイベントを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「true」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができる状態を表す。

＜ans:JobEndStateEvent＞要素１７０７には、次のようにセットされる。プリンタ３がＰＣに対してJobEndStateEventを通知することができる場合は「true」がセットされる。また通知することができない場合は「false」がセットされる。この例では、「true」がセットされており、プリンタ３がそのＰＣに対してこのイベントを通知することができる状態を表す。

実施形態３では、実施形態１の＜ans:EventControl＞要素８０２の代わりに＜ans:JobEndStateEvent＞要素１７０７を代用することで、本発明の課題を解決する。

図９のＳ９０７、Ｓ９０８において、＜ans:EventControl＞要素８０２の代わりに＜ans:JobEndStateEvent＞要素１７０７を代用する。図１１のＳ１１１０、Ｓ１１１２において、＜ans:EventControl＞要素８０２の代わりに＜ans:JobEndStateEvent＞要素１７０７を代用する。図１２のＳ１２０５、Ｓ１２０６において、＜ans:EventControl＞要素８０２の代わりに＜ans:JobEndStateEvent＞要素１７０７を代用する。

このように、図１０の（ｄ）で示されるケースにおいて、ＰＣ８８８からの印刷ジョブ要求に対してプリンタ３が、印刷が終了したことを表すイベントを返せなくても、印刷が終了した印刷ジョブを、ＰＣ８８８内のプリンタキューから削除できる。よって、ユーザの操作性に優れる。

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

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

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

本発明の実施の形態では、ＰＣ１、ＰＣ２、ＰＣ５、ＰＣ８８８とプリンタ３との間のインタフェースとして、例えば無線ＬＡＮ、IEEE1394、Bluetooth（登録商標）等の任意のインタフェースを用いるようにしても良い。

本発明の実施の形態では、Ｗｅｂサービスのプロトコルの例としてＷＳＤを挙げたが、この例に限られることなく、例えばＩＨＶの独自プロトコル等の任意のプロトコルを用いるようにしても良い。

本発明の実施の形態では、ＷＳＤのプリントサービス宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得し、このＩＰアドレスをもとにコンピュータ名取得して、このコンピュータ名を用いてＰＣを特定している。この例に限られることなく、例えば、ＷＳＤのプリントサービス宛てのＨＴＴＰ ＰＯＳＴでのＴＣＰ受信ソケットからＩＰアドレスを取得して、このＩＰアドレスを用いてＰＣを特定する等の、他の手段を利用してＰＣを特定しても良い。

このようにＩＰアドレスを利用することで、ＷＳＤのプロトコル内で２バイトコードを取り扱うような考慮が不要となり、プログラムを簡素化でき、コーディングミスを最小限に抑えることができるので、品質を向上することができる。

本発明の実施の形態では、GetPrinterElementsオペレーションを利用して＜ans:EventControl＞要素や＜ans:JobEndStateEvent＞要素を取得する例を挙げた。この例に限らず、プリンタに関する情報を取得するオペレーションの代わりに、印刷ジョブに関する情報を取得するオペレーションを利用しても良い。そのオペレーションとしてはGetJobElementsオペレーション等のＷＳＤのプリントサービスDefinitionで定義されているオペレーションである。

本発明の実施の形態では、ＰＣが、プリンタから取得する＜wprt:DeviceId＞要素８０４にセットされているDevice IDの中に含まれるプリンタの状態を表す情報（INFO:xxx）を参照する。そして、この情報にセットされている値からプリンタにおける印刷が終了してオンラインでスタンバイ状態（「000」）か、印刷中（「001」）かを判断する例を挙げた。この例に限られることなく、例えば、プリンタの状態をＳＮＭＰ等の別のプロトコルやコマンドを利用して取得し、その結果をもとにプリンタにおける印刷ジョブ要求の処理状況を判断しても良い。

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

Claims (8)

1. ネットワークを介して接続された、印刷ジョブをスタックするプリンタキューを利用する情報処理装置と周辺装置とで構成される周辺装置制御システムであって、
   前記情報処理装置は、
   前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行する発行手段と、
   前記周辺装置から前記レスポンスを取得して保存する取得手段とを有し、
   前記周辺装置は、
   前記情報処理装置から発行された前記リクエストに対して、前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを返信する返信手段を有し、
   前記情報処理装置は、前記情報処理装置が前記印刷ジョブのデータを前記周辺装置に送信後、前記周辺装置から返信された前記レスポンスに含まれる前記情報が前記イベントを通知できないことを表す情報の場合、前記プリンタキューから前記印刷ジョブを削除することを特徴とする周辺装置制御システム。
2. 前記発行手段は、前記情報処理装置が前記印刷ジョブのデータを前記周辺装置に送信し終えた時点で、前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行することを特徴とする請求項１に記載の周辺装置制御システム。
3. ネットワークを介して情報処理装置と接続された周辺装置であって、
   前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得すべく前記情報処理装置から発行されたリクエストに対して前記レスポンスを返信する返信手段を有し、
   前記返信手段は、前記情報処理装置に前記イベントを通知できる場合は通知できること表す情報を前記レスポンスに設定し、前記情報処理装置にイベントを通知できない場合は通知できないことを表す情報を前記レスポンスに設定することを特徴とする周辺装置。
4. ネットワークを介して周辺装置と接続された、前記周辺装置に発行した印刷ジョブをスタックするプリンタキューを利用する情報処理装置であって、
   前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行する発行手段と、
   前記周辺装置から前記レスポンスを取得して保存する取得手段とを有し、
   前記印刷ジョブのデータを前記周辺装置に送信後、前記周辺装置から取得された前記レスポンスに含まれる前記情報が前記イベントを通知できないことを表す情報の場合、前記プリンタキューから前記印刷ジョブを削除することを特徴とする情報処理装置。
5. 前記発行手段は、前記印刷ジョブのデータを前記周辺装置に送信し終えた時点で、前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行することを特徴とする請求項４に記載の情報処理装置。
6. ネットワークを介して情報処理装置と接続された周辺装置において実行される制御方法であって、
   前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得すべく前記情報処理装置から発行されたリクエストに対して前記レスポンスを返信する返信工程を有し、
   前記返信工程において、前記情報処理装置に前記イベントを通知できる場合は通知できること表す情報を前記レスポンスに設定し、前記情報処理装置にイベントを通知できない場合は通知できないことを表す情報を前記レスポンスに設定することを特徴とする制御方法。
7. ネットワークを介して周辺装置と接続され、前記周辺装置に発行した印刷ジョブをスタックするプリンタキューを利用する情報処理装置において実行される制御方法であって、
   前記周辺装置が前記情報処理装置にイベントを通知できるか否かを表す情報を含むレスポンスを取得するためのリクエストを前記周辺装置に発行する発行工程と、
   前記周辺装置から前記レスポンスを取得して保存する取得工程とを有し、
   前記印刷ジョブのデータを前記周辺装置に送信後、前記情報処理装置は、前記周辺装置から取得された前記レスポンスに含まれる前記情報が前記イベントを通知できないことを表す情報の場合、前記プリンタキューから前記印刷ジョブを削除することを特徴とする制御方法。
8. コンピュータに、請求項６又は７に記載に制御方法における各工程を実行させるためのプログラム。

Images