図1は、本発明の実施例1であるネットワーク対応プリンタPR1を示す図である。
ネットワーク対応プリンタPR1は、印刷装置の例であり、CPU1と、ROM2と、RAM3と、タイマ4と、操作パネル5と、印刷出力デバイス6と、Ethernetコントローラ7と、Ethernetケーブル8と、システムバス9とを有する。なお、上記Ethernetは、登録商標である。
CPU1は、基本制御等のプログラムが書き込まれているROM2に従って、装置全体を制御する。RAM3は、ROM2から読み出されたプログラムを実行する場合におけるワークエリア、データ送受信時のバッファに用いられる。ただし、ハードディスク等の大容量のストレージは持たず、印刷用にRAM3をライン・バッファとして用いることができても、印刷ジョブの全てをスプールすることはできない。
IEEE802.3によって規定されたEthernet(通称)によって、Ethernetコントローラ7に接続されている有線LANネットワークを介して、クライアントPCから印刷を実行するために、コマンドを送受信する。また、印刷データが送信される。
Ethernetコントローラ7は、有線LAN通信に対応するためのEthernetケーブル8用のコネクタと、インタフェース制御を司るコントローラとによって構成されている。Ethernetケーブル8を、コネクタに接続して通信する。
無線LAN対応PCカードと無線コントローラとを追加することによって、IEEE802.11a/b/gで規定されている無線LANネットワークを使用するようにしてもよい。無線LANに対応する場合、無線LAN通信に対応するためのPCカードを接続するためのPCカード・インタフェースで構成されている。
実施例1は、2種類の異なる通信プロトコル・印刷サービスであるWSDと、非標準系通信プロトコル・印刷サービスとに対応する印刷システムを提供する。WSDで使用される通信プロトコル方式、並びに印刷に関する要求形態と応答形態とは、標準規格として定められている。実施例1における非標準系通信プロトコル・印刷サービスは、ベンダ固有の通信方式、並びに印刷に関する要求形態と応答形態とを用い、標準規格では定められていない。
ROM2には、これらのWSD又は非標準系の通信プロトコル・印刷サービスに従って、印刷出力デバイス6に、印刷を実行させるプログラムが書き込まれている。印刷出力デバイスは、インクジェットプリンタ・デバイスであるとする。なお、レーザプリンタを、印刷出力デバイスとして使用するようにしてもよい。指定された用紙に、印字・印画するためのカートリッジ式のインクタンクと、インクを吐出するためのインクジェット用吐出ヘッドと専用駆動モータとが設けられている。そして、セットされた用紙を、印字させるヘッド位置まで移動させる給紙コントロール部と、専用駆動モータと、定期的にインクジェット用吐出ヘッドの汚れを除去するクリーニング・ユニットとによって構成されている。
図2は、実施例1であるネットワーク対応プリンタPR1に設けられているROM2に記憶されているプログラムP1のモジュールの構成を示す図である。
ROM2に記憶されているプログラムP1は、アプリケーション層10、ミドルウェア層11、装置のオペレーション・システム12の各層に分類されている。
最初に、オペレーション・システム12が起動されると同時に、ミドルウェア層11のOS起動処理が呼ばれる。OS起動処理は、装置の起動状態に応じて、必要なモジュールを順番に起動する。
ミドルウェア層11は、オペレーション・システム12と、アプリケーション層10のモジュール群との間に介在し、通信制御を行う。ミドルウェア層11のLANドライバ、TCP/IPモジュール、UDPモジュールは、Ethernetコントローラ7を制御し、TCP/IP、UDP経由で通信する。
ミドルウェア層11は、TCP/IPモジュール20と、UDPモジュール21と、OS起動処理22と、LANドライバ23とを有する。
アプリケーション層10は、要求順管理部13、実行状態管理部14、印刷用モジュール15、HTTPモジュール16、XML解析モジュール17、WSDプロトコルモジュール18、非標準系プロトコルモジュール19を有する。
一般的に、プリンタのIPアドレス等を含むネットワークの設定は、操作パネル5からだけではなく、ネットワーク経由で、クライアントPCのWebブラウザを起動し、プリンタへアクセスすることによって、実行することができる。
HTTPモジュール16は、設定用のWebサーバとしての管理と、WSDで規定されたHTTP通信との両方の目的で使用する。
XML解析モジュール17は、WSDの通信で使用され、SOAP−Over−UDP通信の受信データの解析に使用する。
要求順管理部13、実行状態管理部14は、複数の通信プロトコル・印刷サービスに依存せずに、一貫して、ネットワーク経由の印刷ジョブの順番や、キューイング状態を管理するためのWSD、非標準系通信プロトコル・印刷サービスで共通のモジュールである。
ネットワーク対応プリンタPR1は、印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する装置である。
CPU1は、印刷装置で印刷データをスプールするか否かに応じて、上記印刷ジョブ情報を、上記要求順番リストに登録するタイミングを、第1の要求コマンド又は第2の要求コマンドに切り替える制御手段の例である。
印刷出力デバイス6は、上記要求順番リストを管理する要求順管理手段が要求した順番で印刷する印刷手段の例である。
また、CPU1は、複数の通信プロトコル経由での印刷機能を持ち、印刷中に受信した他のクライアントデバイスからの第1の要求コマンドに、特定のジョブ情報が含まれているか否かを識別する識別手段の例である。この識別手段は、第1の要求コマンドに、再送回数、最初にプリンタから返却されたタイムスタンプが含まれているかどうかを識別する手段である。
さらに、CPU1は、上記識別手段による識別結果に応じて、ジョブ情報を、上記要求順番リストに登録するタイミングを、第1の要求コマンド又は第2の要求コマンドに切り替える制御手段の例である。この制御手段は、上記第1の要求コマンドに、特定のジョブ情報を含まないプロトコルである場合、印刷中であっても、クライアント機器から送信された上記第1の要求コマンドに対して、エラー応答せずに受諾する。そして、上記第2の要求コマンドにのみ、ビジー応答し、印刷中は、印刷データの受信を保留する。
また、CPU1は、プロトコル間で要求順番リストを統合する要求順管理手段の例である。
印刷出力デバイス6は、上記要求順管理手段が要求した順番で、印刷する印刷手段の例である。
次に、非標準系、WSDのそれぞれの通信プロトコル・印刷サービスでのコマンドレスポンス形式での印刷方法について説明する。
また、非標準系通信プロトコル・印刷サービスでは、要求順に着目したキューイング手法について説明し、WSDでは、標準方式に沿った印刷方式について説明する。
その後に、非標準系、WSDで通信プロトコル・印刷サービスでの一貫したキューイング管理手法と、これに対応する各コマンドレスポンス手法とについて説明する。
<非標準系通信プロトコル・印刷サービス>
最初に、従来の非標準系通信プロトコル・印刷サービスの要求順に着目したキューイング手法について説明する。
図3は、非標準系通信プロトコル・印刷サービスで使用されるSessionStart要求・応答コマンドを示す図である。
ビットフィールド30は、数値列であり、コマンド識別に使用する。各コマンドに対応して予め定められたコマンド数値列が入る。
このコマンドは、印刷データを転送するために、セッションの確立をリクエストする。プリンタが、まだセッションを成立していない状態である等、セッションを成立できる場合には、成功の値を、ビットフィールド31のResultに代入して返却する。逆に、既にセッションが成立している等の理由によって、新たなセッションが確立できない場合、失敗の値を、ビットフィールド31のResultに代入し、返却する。
ビットフィールド32には、印刷ジョブのセッションIDが格納されている。ビットフィールド33は、ビットフィールド34〜37のビット長を示す。ビットフィールド34は、コマンド再送回数であり、同印刷ジョブに対して、SessionStartを再送した回数を示す。なお、最初は、コマンド再送回数を、「0」とし、2回目は、再送回数が「1」になる。それ以降は、再送ごとに、1ずつ加算する。
ビットフィールド35のタイムスタンプに、最初は「0」を入れて送信する。プリンタは、失敗応答時に、タイムスタンプを付加して返却する。他のジョブが実行中に、セッション開始要求SessionStartを送信してきたジョブについて、プリンタのタイマ4で受信した時刻を取得する。「xx:xx:xx」のように、時:分:秒形式とし、要求順管理部13の要求順リストに書き込む。プリンタでの印刷要求順の管理において、他のジョブ実行が完了した後は、このタイムスタンプの数値を比較し、先にセッション開始要求を受信したものから順番に、ジョブを実行することによって、データ到着順に印刷する。クライアントPCは、プリンタからの応答コマンドが、印刷データ転送が失敗であれば、タイムスタンプの値を記憶し、SessionStartコマンドの再送時に、最初に取得したタイムスタンプ値を、代入する。
ビットフィールド36には、印刷ジョブの発行元PC名を格納し、ビットフィールド37には、印刷ジョブのドキュメント名を格納する。なお、プリンタからの要求コマンドには、発行元PC名、ドキュメント名を含めるが、応答コマンドの場合、このビットフィールドは、不要である。
図4は、非標準系通信プロトコル・印刷サービスで使用されるDataWrite要求・応答コマンドを示す図である。
ビットフィールド40は、数値列を格納し、コマンド識別を格納するために使用する。各コマンドに対応して、予め定められたコマンド数値列が入る。このコマンドは、印刷データを転送するコマンドである。
ビットフィールド41は、印刷データ転送が成功したか失敗したかの結果を、Resultに代入し、返却する。ビットフィールド42には、印刷ジョブのセッションIDが格納される。ビットフィールド43は、ビットフィールド44のビット長を格納する。
ビットフィールド44に、印刷ジョブの送信データを格納する。1回のDataWriteコマンドで送りきれないデータ量である場合、複数回のDataWriteコマンドに分けて、データ転送を繰り返し実行する。
図5は、非標準系通信プロトコル・印刷サービスで、実際にSessionStart要求コマンドとDataWrite要求コマンドとを、クライアントPCから発行し、プリンタから印刷を行ったときの動作を示すシーケンス図である。
通信51において、クライアントPCは、プリンタにSessionStart要求コマンドを発行する。非標準系プロトコルモジュール19で、SessionStart要求コマンドを受信すると、印刷出力デバイス6が使用可能かどうかを、実行状態管理部14に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。
通信51の際に、プリンタPR1は、アイドル状態であり、印刷待ちのジョブも存在しないので、SessionStart応答コマンドのビットフィールド31のResultに成功を代入して応答する。通信52において、クライアントPCは、SessionStart応答コマンドの成功を受信すると、データ転送が完了する通信53まで、DataWrite要求コマンドを繰り返し、発行する。通信54において、クライアントPCは、SessionEnd要求コマンドを発行して終了する。
図6は、非標準系通信プロトコル・印刷サービスで、実際にSessionStart要求コマンドとDataWrite要求コマンドとを、複数台のクライアントPCから発行し、プリンタPR1から印刷を行った場合における動作を示すシーケンス図である。
このシーケンス図を用いて、クライアントPC1が印刷中に、クライアントPC2とクライアントPC3から、順次、印刷を発行した場合の動作について説明する。
通信61において、PC1は、プリンタPR1にSessionStart要求コマンドを発行する。非標準系プロトコルモジュール19が、SessionStart要求コマンドを受信すると、印刷出力デバイス6が使用可能かどうかを、実行状態管理部14に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを要求順管理部13に問い合わせる。通信61の際に、プリンタPR1は、アイドル状態であり、印刷待ちのジョブも存在しないので、SessionStart応答コマンドのビットフィールド31のResultに成功を、代入し、応答する。
通信62において、PC1は、プリンタPR1からのSessionStart応答コマンドの成功を受信すると、データ転送が完了する通信66まで、DataWrite要求コマンドを繰り返し、発行する。
通信63において、PC2は、SessionStart要求コマンドを、プリンタPR1に発行する。しかし、非標準系プロトコルモジュールがプリンタに問い合わせすると、印刷出力デバイス6が、PC1の実行中の印刷ジョブによって占有されているので、実行状態管理部14がBUSYを応答する。非標準系プロトコルモジュールは、SessionStart応答コマンドのビットフィールド31のResultに、失敗の値を代入し、タイマ4から取得したコマンド受信時刻に応じたタイムスタンプT1を代入し、PC2に応答する。
このときに、実際の印刷データは、スプールされないが、SessionStart要求コマンドを受信した順番のみに着目し、要求順リストに、PC2のジョブ情報のみをキューイングする。この要求順リストに登録されたジョブ情報には、実行状態管理部14が管理している印刷ジョブの実行状態と、初回SessionStart受信時のタイムスタンプと、セッションID、発行元PC名、ドキュメント名とが含まれている。この要求順リストは、タイムスタンプの時間の早い順からキューイングされ、コマンド受信や印刷処理等の状態変化に伴って、要求順管理部13によって追加・更新・削除される。
PC2は、通信63において、SessionStartに失敗したので、周期的に同コマンドを再送する。通信64において、PC2は、SessionStart要求コマンドの最初の再送を行っている。ビットフィールド34のコマンド再送回数として、「1」を代入し、ビットフィールド35のタイムスタンプには、初回のSessionStart時の失敗応答によって返却されたタイムスタンプT1を代入する。しかし、PC1の印刷がまだ印字処理中であるので、プリンタPR1は、SessionStart応答コマンドを失敗で再度応答する。このときに、タイムスタンプT2を代入して応答する。
次に、PC3が、印刷を開始し、通信65において、SessionStart要求コマンドを発行する。非標準系プロトコルモジュールが、実行状態管理部14に、プリンタPR1の使用状態を問い合わせる。このときに、印刷出力デバイス6は、処理が完了しているが、要求順リストに印刷ジョブ情報(PC2、タイムスタンプT1のジョブ)がキューイングされているので、BUSYで応答する。
非標準系プロトコルモジュールは、失敗の値をResult代入し、タイムスタンプT3を代入し、PC3に応答する。要求順リストに、PC3のジョブ情報をキューイングする。
通信66、通信67において、PC1の印刷処理が終了する。
通信68において、PC3は、SessionStart要求コマンドのm回目の再送を行っている。ビットフィールド34のコマンド再送回数として、「m」を代入し、ビットフィールド35のタイムスタンプには、初回のSessionStart時の失敗応答によって返却されたタイムスタンプT3を代入する。しかし、PC1の印刷がまだ印字処理中であるので、プリンタPR1は、SessionStart応答コマンドを失敗で再度応答する。このときに、タイムスタンプTmを代入して応答する。
通信69において、PC2が、SessionStart要求コマンドにタイムスタンプT1を付加し、発行すると、非標準系プロトコルモジュール経由で、実行状態管理部14に使用状態を問い合わせる。キューイングされているPC2のジョブ情報があるので、受信パケットのタイムスタンプと比較すると、タイムスタンプT2が一致するので、該当ジョブに対して印刷を許可する。通信70で、DataWriteが発行され、PC2の印刷が開始する。
図7は、非標準系通信プロトコル・印刷サービスの印刷ジョブの実行状態を示す状態遷移図である。
実行状態71は、アイドル状態であり、この状態で、SessionStart要求コマンドを受信すると、成功応答を返し、印刷状態(実行状態72)に遷移する。
実行状態72は、印刷状態であり、この状態で、SessionStart要求コマンドを受信すると、失敗応答を返し、ジョブ情報のキューイングを行う。印刷終了後は、ジョブ情報のキューイングがあれば、キューイング状態(実行状態73)に遷移し、無ければ、アイドル状態(実行状態71)に遷移する。
実行状態73は、キューイング状態(ジョブ情報のみをキューに保存)であり、この状態でSessionStart要求コマンドを受信すると、最優先キューであれば、成功応答を返し、印刷状態(実行状態72)に遷移する。設定されたキューイングの有効期限が切れたら、アイドル状態(実行状態71)に遷移する。
<WSD>
次に非標準系、WSDのそれぞれの通信プロトコル・印刷サービスでの一貫したキューイング管理手法と、これに対応する各コマンドレスポンス手法について説明する。
まず、WSDにおける標準方式に沿った従来の印刷方式について説明する。
図8は、標準プロトコルであるWSD通信プロトコル・印刷サービスで使用されるCreatePrintJob要求コマンドを示す図である。
なお、図に記載されているmicrosoft、windows、canonは、登録商標である。
CreatePrintJob要求コマンドは、クライアントPCから要求されたコマンドに記載されているPrintTicketのJobDescriptionに従って、印刷ジョブの生成を、プリンタPR1に要求する。
SOAPエンベロープには、ヘッダ領域とボディ領域とが含まれている。たとえば、CreatePrintJob要求コマンドでは、JobNameエレメントと、JobOriginatingUserNameとを使用する。それぞれの応答値は、印刷サービスの定義として定められた値を用いる。
図9は、標準プロトコルであるWSD通信プロトコル・印刷サービスで使用されるCreatePrintJob応答コマンドの成功パケットを示す図である。
プリンタPR1は、要求されたジョブの生成を承諾すると、JobIdを生成し、コマンド応答する。
図10は、標準プロトコルであるWSD通信プロトコル・印刷サービスで使用されているCreatePrintJob応答コマンドの失敗パケットを示す図である。
プリンタPR1は、要求されたジョブの生成に失敗すると、エラーコードのみを生成し、コマンド応答する。
図11は、標準プロトコルであるWSD通信プロトコル・印刷サービスで使用されているSendDocument要求コマンドを示す図である。
SendDocument要求コマンドは、プリンタPR1がジョブを生成することを承諾したCreatePrintJob応答コマンドに記載されたJobIdと、DocumentDescriptionとの情報に従って、印刷データを転送する。
たとえば、上記DocumentDescriptionには、DocumentId、Compression、Format、DocumentNameを記載する。それぞれの応答値は、印刷サービスの定義としてWSDで定められた値を用いる。
図12は、標準プロトコルであるWSD通信プロトコル・印刷サービスで使用されているSendDocument応答コマンドを示す図である。
SendDocument要求コマンドに続いて、全ての印刷データの転送が完了したと判断すると、プリンタは、クライアントPCにSendDocument応答コマンドを発行する。
図13は、標準プロトコルであるWSD通信プロトコル・印刷サービスで、実際にCreatePrintJob要求コマンドとSendDocument要求コマンドとをクライアントPCから発行し、プリンタから印刷を行った場合のシーケンス図である。
通信81において、クライアントPCは、プリンタPR1に、CreatePrintJob要求コマンドを発行する。WSDプロトコルモジュール18が、CreatePrintJob要求コマンドを受信すると、印刷出力デバイス6が使用可能であるかどうかを、実行状態管理部14に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。通信81の際に、プリンタPR1は、アイドル状態であり、印刷待ちのジョブも存在しないので、CreatePrintJob応答コマンドを成功にし、JobIdを生成して応答する。
通信82において、クライアントPCは、CreatePrintJob応答コマンドの成功を受信すると、SendDocument要求コマンドを発行し、データ転送を開始する。同要求コマンドのJobIdには、CreatePrintJob応答コマンドに含まれていたJobIdを付加する。
印刷データの転送が完了すると、プリンタPR1は、通信83で、SendDocument応答コマンドを発行する。また、通信84において、印刷終了時にJobEndStateイベントを発行する。
次に、実施例1において、WSDで複数のクライアントPCから印刷を行った時のシーケンスについて説明する。
つまり、クライアントPC1が印刷中に、クライアントPC2とクライアントPC3とが、順次、印刷を発行した場合の動作について説明する。
図14は、標準プロトコルであるWSD通信プロトコル・印刷サービスで、実際にCreatePrintJob要求コマンドとSendDocument要求コマンドとを、複数台のクライアントPCが発行し、プリンタから印刷した時のシーケンス図である。
通信91において、PC1は、プリンタにCreatePrintJob要求コマンドを発行する。WSDプロトコルモジュール18が、CreatePrintJob要求コマンドを受信すると、印刷出力デバイス6が使用可能であるかどうかを、実行状態管理部14に問い合わせる。また、同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。通信91の際に、プリンタPR1は、アイドル状態であり、印刷待ちのジョブも存在しないので、CreatePrintJob応答コマンドのJobId=1を生成し、応答する。
通信92において、PC1は、プリンタPR1からのCreatePrintJob応答コマンドの成功と、配布されたJobId=1とを、SendDocument要求コマンドに記載し、データ転送を開始する。SendDocument応答は、印刷を終了した後に、後の通信97で発行される。
通信93において、PC2は、プリンタにCreatePrintJob要求コマンドを発行する。しかし、WSDプロトコルモジュールが、プリンタPR1に問い合わせすると、印刷出力デバイス6が、PC1の実行中の印刷ジョブによって占有されているので、実行状態管理部14が、BUSY応答を返す。従来の方法では、WSDプロトコルモジュールは、PC2にCreatePrintJob応答コマンドを送り、失敗応答する。
非標準系通信プロトコル・印刷サービスと比較した場合、最初のSessionStartコマンドをプリンタPR1が受信したタイミングで、受信したタイムスタンプで、ソートされるジョブの順番に着目してジョブ制御する。
しかし、WSDの標準プロトコルに沿って、通信を行った場合、そのままでは、SessionStartの失敗時に、プリンタPR1が返却していたタイムスタンプ情報を、コマンド応答に含めることができない。すなわち、非標準系通信プロトコル・印刷サービスで行っていたプリンタPR1側でのスプールをしないキューイング制御の機構を適用することができない。
そこで、実施例1では、WSD通信プロトコル・通信サービスにおいて、プリンタPR1側でスプールしないキューイング制御の仕組みを適用するために、WSDの場合には、キューイング機構を切り替える。
通信93において、PC1からの印刷ジョブが実行中であるので、実行状態管理部14は、PC2からのCreatePrintJobに対して、内部的にBUSYを返す。しかし、WSDプロトコルモジュール18は、そこで非標準系のようにキューイングを行わずに、成功応答を応答する。すなわち、WSDにおいては、印刷中のCreatePrintJobコマンドに対して、成功応答を返すことによって、クライアントPCからのコマンド再送処理を期待しない処理とする。
通信93で、CreatePrintJob応答コマンドには、JobId=2を生成し、応答する。キューイングされたジョブ情報に、生成されたJobIdとコマンド受信時の(前に説明した非標準系相当の)タイムスタンプとを関連付け、保持することによって、要求順リストに存在するジョブのソートを実現する。
通信94において、PC2から、JobId=2のジョブについてSendDocument要求コマンドを発行する。WSDプロトコルモジュールは、SendDocument要求コマンドを受信すると、印刷出力デバイス6が使用可能であるかどうかを、実行状態管理部14に問い合わせる。また同時に、キューイングされているジョブ情報が要求順リストに無いかどうかを問い合わせる。通信94では、キューイングされているジョブ情報が存在しないが、印刷出力デバイス6が、PC1のJobId=1のジョブによって実行中になっているので、プリンタPR1側でセッションを張ったまま、印刷データの受信を停止する。このようにすることによって、順番が回ってくるまで、PC2の印刷処理を待たせる。
印刷データの受信を停止した場合、要求順管理部13が、新たなジョブ情報を要求順リストの最後尾に追加する。この場合、PC2のJobId=2のジョブ情報を、要求順リストに追加する。
要求順リストに登録されたジョブ情報には、実行状態管理部14が管理している印刷ジョブの実行状態と、初回CreatePrintJob受信時のタイムスタンプと、JobID、発行元PC(又はユーザ)名、ドキュメント名とが含まれる。この要求順リストは、タイムスタンプの時間の早い順から、キューイングされ、コマンド受信や印刷処理等の状態変化に伴って、追加・更新・削除される。
通信95において、PC3からのCreatePrintJob要求コマンドが発行される。通信93と同様に、印刷出力デバイスの実行状態は、BUSYであるが、JobID=3を付加し、CreatePrintJob応答コマンドを返す。
通信96において、PC3からのSendDocument要求コマンドが発行されるが、通信94と同様に、JobId=3の印刷データの受信を停止する。
PC1のJobID=1の印刷が完了すると、通信97において、SendDocument応答コマンドを発行し、通信98において、JobEndStateイベントを発行する。
その後に、印刷出力デバイスを監視していた実行状態管理部14が、印刷可能になったことを検知する。ここで、要求順管理部13が、要求順リスト111に蓄えられている印刷ジョブ情報を参照し、一番古いタイムスタンプを記録している印刷ジョブ情報はPC2であるので、PC3の印刷ジョブは印刷待ち状態であると判断する。したがって、通信99では、通信96以降の通信状態と同様に、プリンタPR1側でセッションを張ったまま、印刷データの受信を停止した状態を保持する。このようにすることによって、順番が回ってくるまで、PC3の印刷処理を待たせる。
その後に、印刷出力デバイスを監視していた実行状態管理部14が、印刷可能な状態になったことを検知し、通信100において、PC2へのデータ受信を再開し、印刷を実行する。
<非標準系,標準WSDにおける通信プロトコル・印刷サービス同時管理>
図15は、実施例1において、非標準系通信プロトコル・印刷サービスとWSD標準プロトコル・印刷サービスとの印刷ジョブが混在するプリンタでの実行状態を表す状態遷移図である。
非標準系通信プロトコル・印刷サービスでは、SessionStart要求コマンドに失敗応答するときに、キューイングし、WSDでは、SendDocumentでデータ受信を停止するときに、キューイングする。
非標準系通信プロトコル・印刷サービスの状態遷移については、図4で説明したとおりである。次に、WSDについての差分を説明する。
実行状態101は、アイドル状態であり、この状態で、SendDocument要求コマンドを受信すると、成功応答を返し、データ受信を開始し、印刷状態(実行状態102)に遷移する。
実行状態102は、印刷状態であり、この状態であっても、SendDocument要求コマンドを受信した場合、成功応答を返し、ジョブ情報のキューイングを行い、キューイング状態(実行状態103)に遷移する。
実行状態103は、キューイング状態(ジョブ情報のみをキューに保存)であり、この状態で、SendDocument要求コマンドを受信すると、最優先キューである場合、成功応答を返し、データ受信を開始し、印刷状態(実行状態102)に遷移する。設定されたキューイングの有効期限が切れたら、データ受信を切断し、アイドル状態(実行状態101)に遷移する。
たとえば、非標準系通信プロトコル・印刷サービスでキューイング状態であるときに、WSDのSendDocument要求コマンドを受信すると、通信94のように、WSDのデータ受信を停止する処理を行うという実行状態管理を可能とする。
また、WSDでキューイング状態(実行状態103)であるときに、非標準系のSessionStart要求コマンドを受信すると、SessionStart応答コマンドで失敗を応答し、キューイング状態(実行状態103)を維持する。
図16は、実施例1において使用する要求順リストを示す図である。
PC1が印刷中であるときに、PC2のJob2(非標準系)、PC3のJob3(WSD)が順次印刷されたことによって、ジョブ情報が、順番にキューイングされたケースについて説明する。したがって、要求順リスト111には、2種類の通信プロトコル・印刷サービス経由でのジョブ情報が登録されている。つまり、非標準系通信プロトコル・印刷サービスのジョブ情報112と、WSDのジョブ情報113とが登録されている。
非標準系通信プロトコル・印刷サービスのジョブ情報112は、プロトコル識別情報、印刷状態フラグ、セッションID、タイムスタンプ、発行元PC名、ドキュメント名によって構成されている。WSDのジョブ情報113は、プロトコル識別情報、印刷状態フラグ、JobId、タイムスタンプ、発行元PC名、ドキュメント名によって構成されている。
プロトコル識別情報には、WSD、非標準系通信プロトコル・印刷サービスのプロトコル番号が割り振られる。
印刷状態フラグは、図15に示す各実行状態を反映したフラグ値である。
生成されたJobIdと、コマンド受信時にタイマ4から取得した「xx:xx:xx」のような時:分:秒形式のタイムスタンプとを関連付けて、WSDのジョブ情報113に保持することによって、要求順リストに存在するジョブのソートを実現する。
非標準系通信プロトコル・印刷サービス、WSDでの優先順位管理には、タイムスタンプの時刻情報を用いて一貫したジョブ情報のソートを行うことができる。
図17は、実施例1における印刷開始要求コマンド受信処理を示すフローチャートである。
非標準系、WSD以外の第3の通信プロトコル・印刷サービスであっても、印刷開始要求コマンドとデータ受信開始要求コマンドとに分類できれば、同様のフローチャートに対応できるので、複数プロトコル間で統合したフローチャートを示す。
また、要求順管理部13、実行状態管理部14は、複数プロトコルであっても、それぞれ1つの管理部で管理している。図17に示す一貫したフローチャートチャートで、全体像を示すことによって、各プロトコルでの処理タイミングを明らかにする。
印刷するにあたり、クライアントPCから最初に発行される「印刷開始要求コマンド」は、非標準系通信プロトコル・印刷サービスでは、SessionStart要求コマンドであり、WSDでは、CreatePrintJob要求コマンドに相当する。
クライアントPCからプリンタPR1に印刷データを転送する場合、印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、非標準系では、DataWrite要求コマンドに相当する。また、上記「データ受信開始要求コマンド」は、WSDでは、SendDocument要求コマンドに相当する。
プリンタPR1側でのスプールをしないキューイング機能を、それぞれの通信プロトコル・印刷サービスにおいて適用し、かつ、複数の通信プロトコル・印刷サービスであっても、要求順リストを一貫して管理する。このために、図15に示す実行状態遷移図に従って運用する。すなわち、非標準系通信プロトコル・印刷サービスでは、「印刷開始要求コマンド」受信時にのみ、キューイング状態(実行状態103)への遷移が可能であり、「データ受信開始要求コマンド」受信時では、キューイング状態への遷移は許可しない。逆に、WSDでは、「印刷開始要求コマンド」受信時に、キューイング状態(実行状態103)への遷移を許可しないが、「データ受信開始要求コマンド」受信時にのみ、キューイング状態への遷移が可能である。
S1では、受信した印刷開始要求コマンドの通信プロトコル・印刷サービスを識別する。非標準系である場合、同コマンド受信時に、キューイング状態(実行状態103)への遷移が可能であると判断し、S2へ移行する。WSDである場合、同コマンド受信時にキューイング状態への遷移を許可しないので、S12へ移行する。
S2〜S11は、非標準系通信プロトコル・印刷サービスで使用する処理である。S2で、非標準系通信プロトコル・印刷サービスの処理を示し、プリンタPR1のキューイング状態への遷移を、実行状態管理部14に許可するように命令する。したがって、WSDから印刷開始要求コマンドを受信した場合、このタイミングでは、プリンタPR1のキューイング状態への遷移は許可されない。
S1〜S12へ移行した場合、WSDプロトコルモジュール18が、要求順管理部13、実行状態管理部14に問い合わせしなくてもよい。ジョブがキューイング状態(実行状態103)であり、また、印刷状態(実行状態102)であっても、このタイミングでは、S12で、成功応答をし、同コマンド処理を終了する。
S3で、コマンド受信時に非標準系通信プロトコル・印刷サービスのジョブ情報112のセッションIDと合わせて、タイマ4から取得した時刻を、ジョブ情報のタイムスタンプに記録する。
S4〜S11は、ジョブ情報のキューイング追加処理を示すフローチャートである。ジョブ情報をキューイングする際に、要求順リスト111の順番を受信したコマンドのタイムスタンプに基づいてソートする。タイムスタンプは、S3で取得したものである。S4では、実行状態管理部14でプリンタの実行状態を確認する。この結果、アイドル状態(実行状態101)であれば、S9に移行する。印刷状態(実行状態102)であれば、S5に移行する。S9に移行した後、キューイング状態(実行状態103)であれば、S10に移行する。
S4で、プリンタが印刷状態であれば、S5で、要求順管理部13に問い合わせ、要求順リスト111を参照する。
要求順リストにジョブ情報が1つでも、登録済みであれば、S6で、ジョブ情報を要求順リストの最後尾に追加し、S8で、印刷開始要求コマンド応答を失敗応答する。
要求順リストにジョブ情報が、未登録であれば、S7で、ジョブ情報を新規作成し、要求順リストに追加し、S8で、印刷開始要求コマンド応答を失敗応答する。
なお、図17では、S6、S7でジョブ情報を要求順リストに追加した後に、S8で印刷開始要求コマンド応答を失敗応答している。この順序は、S5の判定処理の後に印刷開始要求コマンドの失敗応答をした後のタイミングでジョブ情報を追加する、または、ジョブ情報を新規追加する順序でもよい。
S8で、SessionStart応答コマンドに失敗の値を代入し、クライアントPCに応答し、コマンド処理を終了する。S9で、要求順リストにジョブ情報が1つでも、登録済みであれば、S10に移行し、ジョブ情報を、要求順リスト111の最後尾に追加し、S11で、印刷開始要求コマンド応答を失敗応答する。S11で、SessionStart応答コマンドに、失敗の値を代入し、クライアントPCに応答し、コマンド処理を終了する。
なお、図17では、S10でジョブ情報を要求順リストに追加した後に、S11で印刷開始要求コマンド応答を失敗応答している。この順序は、S9の判定処理の後に印刷開始要求コマンドの失敗応答をした後のタイミングでジョブ情報を追加する、または、ジョブ情報を新規追加する順序でもよい。
S4〜S10で、ジョブ情報のキューイング追加処理が終わると、S12で、印刷開始要求コマンドへの応答を行う。非標準系通信プロトコル・印刷サービスであれば、SessionStart応答を成功で返し、WSDであれば、CreatePrintJobを成功で返す。S13で、TCP/IPモジュール20に、印刷データ受信待ちイベントを発行し、印刷データの受信に備える。TCP/IPモジュール20は、セッション接続待ちの状態に入る。
図18は、実施例1においてデータ受信開始要求コマンド受信処理を示すフローチャートである。
印刷データをプリンタPR1に転送するにあたり、印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、非標準系通信プロトコル・印刷サービスでは、DataWrite要求コマンドに相当する。印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、WSDでは、SendDocument要求コマンドに相当する。
非標準系通信プロトコル・印刷サービスでは、DataWrite要求コマンドに転送データを付加し、繰り返し送信することによって、印刷する。WSDでは、SendDocument要求コマンドに続いて、印刷データを送信するので、繰り返し送信する必要が無い。
S21において、印刷データの受信バッファへの書き込み処理が1回目か否かを判定する。初回の書き込みである場合、S22で、初回WriteフラグをONにセットし、S23で、Write(バッファ書き込み)モジュールにイベントを発行する。
Writeモジュールは、このイベント発行を受け、データの受信待ち状態に入り、転送データを受信すると、RAM3に確保した受信バッファに、データを書き込む。同時に、印刷用モジュール15が、Readモジュールによって順次データを読み出しつつ、実際の印字出力を実行する。
S24で、受信したデータ受信開始要求コマンドの通信プロトコル・印刷サービスを識別する。非標準系である場合、同コマンド受信時にキューイング状態(実行状態103)への遷移を許可しないので、S34へ移行する。WSDの場合、同コマンド受信時に、キューイング状態への遷移が可能であると判断し、S25へ移行する。
S25〜S37は、WSDで使用するフローチャートである。S25で、S3と同様に、タイムスタンプのための時刻情報を取得する。S24〜S33は、ジョブ情報のキューイング追加処理を示すフローチャートである。S4〜S11と同様のキューイング処理である。ただし、S30とS33とは、キューイング処理の最後に、TCP/IPモジュール20でのデータ受信を停止する処理を行う。
S36とS37とでは、TCPモジュールでデータが停止された後に、実行状態管理部14にてアイドル状態(実行状態101)になるまで待機し、アイドル状態になった後にTCPモジュールでのデータ受信を再開する。なお、このデータ受信待ちの待機処理にタイムアウト時間を設けることによって、ネットワークが切断された場合、プリンタにトラブルが発生してデータが送信されなくなった場合に、中断させる。S36とS37とでデータ受信が再開された場合、S34へ移行する。ただし、タイムアウトによってデータ受信が中断された場合、データ受信開始要求コマンド処理をエラー終了し、該当するジョブ情報を破棄する。
S26〜S33で、ジョブ情報のキューイング追加処理が終わると、S34で、受信データを受信バッファへ書き込み、S35で、印刷開始要求コマンドへ応答する。非標準系通信プロトコル・印刷サービスであれば、DataWrite応答コマンドを成功で返し、WSDであれば、SendDocument応答コマンドを成功で返す。
なお、上記実施例では、ネットワークに接続されているクライアントPCとネットワーク対応プリンタPR1とによって構成されているが、クライアントPCは、印刷命令を発行できる他の画像入力デバイスであってもよい。
また、実施例1の機能を実現するプログラムコードを記録した記録媒体を、システム又は装置に供給し、そのシステム又は装置のコンピュータが、記憶媒体に格納されたプログラムコードを読み出し、実行することによって、上記実施例の目的が達成される。この場合、記憶媒体から読み出されたプログラムコード自体が、実施例1の機能を実現し、そのプログラムコード自体及びプログラムコードを記憶した記憶媒体は、本発明を構成する。