JP2009269259A - 印刷装置及び印刷装置の制御方法 - Google Patents

Abstract

【課題】標準の通信プロトコル・印刷サービスに沿った方法で、プリンタ側のスプールを必要とせずにキューイングすることができ、また、複数の通信プロトコル・サービス経由での印刷命令を、先着順に印刷出力することができるようにすることを目的とする。
【解決手段】印刷中は、他のクライアント機器から送信された印刷データを、プリンタ側のスプール機能として受信せずに、要求順番リストで管理し、印刷可能となった時点で、クライアント機器からの印刷データの受信を許可するネットワーク対応の印刷装置である。
【選択図】図１７

Description

本発明は、ネットワークに繋がるプリンタを共有して使用する際に、ネットワークに繋がれているクライアントＰＣからの印刷要求のジョブを管理するジョブ管理に関する。

従来、小規模ネットワーク環境では、有線ＬＡＮや無線ＬＡＮで接続されているネットワーク対応プリンタ、又はプリンタに、ネットワーク対応のプリントサーバを装着する。これによって、複数のクライアントＰＣから、１台のプリンタを共有して印刷することができる。

このような環境で使用されるプリンタとして、たとえば、レーザビームプリンタや、多機能の複合機のように、高速なネットワークプリンタが代表的である。

プリンタのオプション装備、又はネットワーク内蔵機能として、プリントサーバ・ユニットを追加することによって、大容量のストレージデバイス（ＨＤＤ等）を使って、プリントスプールすることができる。複数のクライアントＰＣから、同時に印刷要求があった場合でも、印刷ジョブの先着順で印刷することを目的としたジョブ・キューイング処理に対応している。

また、小規模オフィスの場合、低価格で場所を取らないという理由で、インクジェットプリンタを導入するケースが多い。さらに、近年は、一般家庭でも、インターネットの使用を目的とした常時接続のローカルエリアネットワークのインフラストラクチャ導入が進んでいる。

近年のノートＰＣには、購入した直後から使用できるように、ＬＡＮ機能が標準装備されている。このような理由から、低価格のインクジェットプリンタであっても、ネットワーク対応の共有サーバ機能を可能としている。

ネットワーク対応プリンタでは、同じネットワーク上に繋がっている複数のクライアントＰＣから、ランダムに送られた印刷データを、一時ストレージデバイスに格納し、受付順に、印刷データを、プリンタへ送信する方法がある。

ところで、プリンタの記憶領域が少なく、プリントスプールができないプリンタであっても、プリンタ共有の際に、ネットワーク経由で、複数のクライアントＰＣから印刷が要求された順番で、ジョブ・キューイング制御することが求められている。

そこで、大容量のストレージデバイスを使用しなくても、ジョブ・キューイングすることができる方法が提案されている。たとえば、印刷予約のみを受け付け、予約した順番に印刷許可を与え、プリンタへ印刷データを送信する方法等が知られている（たとえば、特許文献１参照）。この方法では、受け付け順で、予約順を付与し、また、印刷中の処理が完了する毎に、予約順を更新することによって、順番印刷を実現している。

この方式では、印刷中の割り込みに対して、プリンタでプリントスプールはせずに、要求順番のみに着目し、要求順リストに印刷ジョブの予約番号を付与する。つまり、印刷割り込み時に、クライアントＰＣからの実際の印刷ジョブの送信を拒否し、クライアントＰＣを待たせ、印刷完了後に、予約番号の順番になった印刷ジョブの送信を、クライアントＰＣに許可する。

また、プリンタや家電製品を含めたネットワーク対応機器が増加することに伴い、ネットワーク上のデバイス同士の通信プロトコルや、デバイスのディスカバリの仕組み、デバイスのインストールの仕組み、印刷サービスの仕様が、標準規格化されている。

たとえば、クライアントＰＣから、より汎用的に、ネットワーク機器を利用するための標準通信プロトコルや、より簡単にデバイスを使用するためのサービスが、規格化されている。たとえば、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ ｆｏｒ Ｄｅｖｉｃｅｓ）や、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ＆Ｐｌａｙ）（登録商標）が知られている。

ＷＳＤは、デバイスを用いた様々なサービスの要求に答えるために定義された標準仕様であり（たとえば、非特許文献１参照）、基本的に、Ｗｅｂサービスのアーキテクチャを使用し、標準化された通信プロトコル群と、印刷サービスとを提供している。

ＷＳＤは、Ｗｅｂサービスをベースとしたデバイス同士の相互接続を可能とするためのネットワーク上の標準通信プロトコル群を用いる。デバイス用のＷｅｂサービスとして、たとえば、デバイス発見（Ｄｉｓｃｏｖｅｒｙ）、デバイス情報提示（Ｄｅｓｃｒｉｐｔｉｏｎ）、デバイス制御（Ｃｏｎｔｒｏｌ）、デバイスのイベント通知（Ｅｖｅｎｔｉｎｇ）等の仕様が定められている。

また、ネットワーク経由で接続するデバイスに対して、Ｍｉｃｒｏｓｏｆｔ（登録商標）社が提唱するＰｎＰ−Ｘを使用して、ＰｎＰ−Ｘ対応のクライアントＰＣへ、デバイスドライバを簡単にインストールすることができる。なお、ＰｎＰ−Ｘは、Ｐｌｕｇ ａｎｄ Ｐｌａｙ ｅＸｔｅｎｓｉｏｎｓである。従来のＰｎＰ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ）では、各デバイスとホストＰＣとを、様々なローカルのＩ／Ｏポートに、ケーブルやコネクタで直接接続した際に働く機能である。

プラグアンドプレイでは、デバイスが、機種名（デバイスＩＤ）や、製造者名（ベンダＩＤ）、シリアル番号等を、ホストＰＣに送信する。ホストＰＣは、これら受信した情報を参照し、デバイスを使用するためのデバイスドライバを、クライアントに、自動でインストールすることができる。

印刷サービスは、ＰｒｉｎｔＳｅｒｖｉｃｅＤｅｆｉｎｉｔｉｏｎ Ｖ１．０ ｆｏｒ ＷＳＤで定められている（たとえば、非特許文献２参照）。これらによって、印刷サービスを利用するクライアントＰＣと、Ｗｅｂサービスによる印刷を提供するプリンタ・デバイスとの相互接続性を提供している。
特許第２７４２０７３号公報 Device Profile for Web Services, Feb 2006( http://specs.xmlsoap.org/ws/2006/02/devprof/ ) Printer Service Definition Ver.1.0, Nov 9, 2006( http://www.microsoft.com/japan/whdc/rally/wsdspecs.mspx )

近年のネットワーク対応プリンタは、複数の通信プロトコルに対応している印刷機能を持っている。標準プロトコル・サービスであるＷＳＤ、ＵＰｎＰ、又は非標準系の通信プロトコル・印刷サービスを含めて、異なる複数の通信プロトコルと印刷サービス機能とを持つことが可能である。

しかし、複数の通信プロトコル・印刷サービスにおいて、一貫したジョブ・キューイングを実行するためには、印刷ジョブ・データを、一旦プリンタのストレージに蓄える必要がある。たとえば、１台のネットワーク対応プリンタで、複数の異なる通信プロトコル機能・印刷サービス機能をサポートする場合、第１の通信プロトコル・サービス経由で印刷中に、第２の通信プロトコル・サービス経由で印刷が発行される場合が考えられる。また、この逆の場合や、ランダムな順番で、不特定多数のクライアントＰＣから、印刷が要求されることを想定することができる。

この場合、記憶領域が少ないプリンタでは、最初のジョブを印刷中に、２番目以降に発行された印刷ジョブ群を、要求順リストに予約しておくことによって、印刷要求を受信したタイミングでは、プリントスプールしない制御が必要である。

しかし、標準プロトコル・印刷サービスのデバイス制御方法を用いた場合、印刷中の割り込み時に、プリンタでスプールせずに、要求順リストに印刷ジョブの予約番号を付与し、制御するジョブ・キューイング方式を、適用することができない。

つまり、上記従来例では、印刷応答コマンドの失敗時に、印刷ジョブの予約情報を付与できないという問題がある。

本発明は、標準の通信プロトコル・印刷サービスに沿った方法で、プリンタ側のスプールを必要とせずにキューイングすることができ、また、複数の通信プロトコル・サービス経由での印刷命令を、先着順に印刷出力することができるようにすることを目的とする。

本発明は、印刷中は、他のクライアント機器から送信された印刷データを、プリンタ側のスプール機能として受信せずに、要求順番リストで管理し、印刷可能となった時点で、クライアント機器からの印刷データの受信を許可するネットワーク対応の印刷装置である。

また、本発明は、複数の通信プロトコル・印刷サービス経由での印刷機能を持ち、印刷中に受信した他のクライアントデバイスからの第１の要求コマンドに、特定のジョブ情報が含まれるか否かを識別する識別手段を持つ。

さらに、本発明は、この識別結果に応じて、受信した非標準系の印刷開始要求コマンド又は標準系のデータ受信開始要求コマンドに応じた失敗応答するタイミングで、上記印刷ジョブ情報を要求順リストに登録する制御手段を持つ。そして、通信プロトコル・印刷サービス間で、要求順番リストを統合する要求順管理手段によって要求された順番に、印刷する。

本発明によれば、印刷応答コマンドの失敗時に印刷ジョブの予約情報を付与できない通信プロトコル・印刷サービスでも、プリンタでスプールせずに、要求順リストに予約番号を付与し制御するキューイング方式を用いて印刷することができるという効果を奏する。

また、本発明によれば、複数の異なる通信プロトコル・印刷サービスであっても、一貫した要求順リストに対応付けて、プリンタでスプールせずに、要求順リストに予約番号を付与し、制御するキューイング方式を適用することができるという効果を奏する。

発明を実施するための最良の形態は、次の実施例である。

図１は、本発明の実施例１であるネットワーク対応プリンタＰＲ１を示す図である。

ネットワーク対応プリンタＰＲ１は、印刷装置の例であり、ＣＰＵ１と、ＲＯＭ２と、ＲＡＭ３と、タイマ４と、操作パネル５と、印刷出力デバイス６と、Ｅｔｈｅｒｎｅｔコントローラ７と、Ｅｔｈｅｒｎｅｔケーブル８と、システムバス９とを有する。なお、上記Ｅｔｈｅｒｎｅｔは、登録商標である。

ＣＰＵ１は、基本制御等のプログラムが書き込まれているＲＯＭ２に従って、装置全体を制御する。ＲＡＭ３は、ＲＯＭ２から読み出されたプログラムを実行する場合におけるワークエリア、データ送受信時のバッファに用いられる。ただし、ハードディスク等の大容量のストレージは持たず、印刷用にＲＡＭ３をライン・バッファとして用いることができても、印刷ジョブの全てをスプールすることはできない。

ＩＥＥＥ８０２．３によって規定されたＥｔｈｅｒｎｅｔ（通称）によって、Ｅｔｈｅｒｎｅｔコントローラ７に接続されている有線ＬＡＮネットワークを介して、クライアントＰＣから印刷を実行するために、コマンドを送受信する。また、印刷データが送信される。

Ｅｔｈｅｒｎｅｔコントローラ７は、有線ＬＡＮ通信に対応するためのＥｔｈｅｒｎｅｔケーブル８用のコネクタと、インタフェース制御を司るコントローラとによって構成されている。Ｅｔｈｅｒｎｅｔケーブル８を、コネクタに接続して通信する。

無線ＬＡＮ対応ＰＣカードと無線コントローラとを追加することによって、ＩＥＥＥ８０２．１１ａ／ｂ／ｇで規定されている無線ＬＡＮネットワークを使用するようにしてもよい。無線ＬＡＮに対応する場合、無線ＬＡＮ通信に対応するためのＰＣカードを接続するためのＰＣカード・インタフェースで構成されている。

実施例１は、２種類の異なる通信プロトコル・印刷サービスであるＷＳＤと、非標準系通信プロトコル・印刷サービスとに対応する印刷システムを提供する。ＷＳＤで使用される通信プロトコル方式、並びに印刷に関する要求形態と応答形態とは、標準規格として定められている。実施例１における非標準系通信プロトコル・印刷サービスは、ベンダ固有の通信方式、並びに印刷に関する要求形態と応答形態とを用い、標準規格では定められていない。

ＲＯＭ２には、これらのＷＳＤ又は非標準系の通信プロトコル・印刷サービスに従って、印刷出力デバイス６に、印刷を実行させるプログラムが書き込まれている。印刷出力デバイスは、インクジェットプリンタ・デバイスであるとする。なお、レーザプリンタを、印刷出力デバイスとして使用するようにしてもよい。指定された用紙に、印字・印画するためのカートリッジ式のインクタンクと、インクを吐出するためのインクジェット用吐出ヘッドと専用駆動モータとが設けられている。そして、セットされた用紙を、印字させるヘッド位置まで移動させる給紙コントロール部と、専用駆動モータと、定期的にインクジェット用吐出ヘッドの汚れを除去するクリーニング・ユニットとによって構成されている。

図２は、実施例１であるネットワーク対応プリンタＰＲ１に設けられているＲＯＭ２に記憶されているプログラムＰ１のモジュールの構成を示す図である。

ＲＯＭ２に記憶されているプログラムＰ１は、アプリケーション層１０、ミドルウェア層１１、装置のオペレーション・システム１２の各層に分類されている。

最初に、オペレーション・システム１２が起動されると同時に、ミドルウェア層１１のＯＳ起動処理が呼ばれる。ＯＳ起動処理は、装置の起動状態に応じて、必要なモジュールを順番に起動する。

ミドルウェア層１１は、オペレーション・システム１２と、アプリケーション層１０のモジュール群との間に介在し、通信制御を行う。ミドルウェア層１１のＬＡＮドライバ、ＴＣＰ／ＩＰモジュール、ＵＤＰモジュールは、Ｅｔｈｅｒｎｅｔコントローラ７を制御し、ＴＣＰ／ＩＰ、ＵＤＰ経由で通信する。

ミドルウェア層１１は、ＴＣＰ／ＩＰモジュール２０と、ＵＤＰモジュール２１と、ＯＳ起動処理２２と、ＬＡＮドライバ２３とを有する。

アプリケーション層１０は、要求順管理部１３、実行状態管理部１４、印刷用モジュール１５、ＨＴＴＰモジュール１６、ＸＭＬ解析モジュール１７、ＷＳＤプロトコルモジュール１８、非標準系プロトコルモジュール１９を有する。

一般的に、プリンタのＩＰアドレス等を含むネットワークの設定は、操作パネル５からだけではなく、ネットワーク経由で、クライアントＰＣのＷｅｂブラウザを起動し、プリンタへアクセスすることによって、実行することができる。

ＨＴＴＰモジュール１６は、設定用のＷｅｂサーバとしての管理と、ＷＳＤで規定されたＨＴＴＰ通信との両方の目的で使用する。

ＸＭＬ解析モジュール１７は、ＷＳＤの通信で使用され、ＳＯＡＰ−Ｏｖｅｒ−ＵＤＰ通信の受信データの解析に使用する。

要求順管理部１３、実行状態管理部１４は、複数の通信プロトコル・印刷サービスに依存せずに、一貫して、ネットワーク経由の印刷ジョブの順番や、キューイング状態を管理するためのＷＳＤ、非標準系通信プロトコル・印刷サービスで共通のモジュールである。

ネットワーク対応プリンタＰＲ１は、印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する装置である。

ＣＰＵ１は、印刷装置で印刷データをスプールするか否かに応じて、上記印刷ジョブ情報を、上記要求順番リストに登録するタイミングを、第１の要求コマンド又は第２の要求コマンドに切り替える制御手段の例である。

印刷出力デバイス６は、上記要求順番リストを管理する要求順管理手段が要求した順番で印刷する印刷手段の例である。

また、ＣＰＵ１は、複数の通信プロトコル経由での印刷機能を持ち、印刷中に受信した他のクライアントデバイスからの第１の要求コマンドに、特定のジョブ情報が含まれているか否かを識別する識別手段の例である。この識別手段は、第１の要求コマンドに、再送回数、最初にプリンタから返却されたタイムスタンプが含まれているかどうかを識別する手段である。

さらに、ＣＰＵ１は、上記識別手段による識別結果に応じて、ジョブ情報を、上記要求順番リストに登録するタイミングを、第１の要求コマンド又は第２の要求コマンドに切り替える制御手段の例である。この制御手段は、上記第１の要求コマンドに、特定のジョブ情報を含まないプロトコルである場合、印刷中であっても、クライアント機器から送信された上記第１の要求コマンドに対して、エラー応答せずに受諾する。そして、上記第２の要求コマンドにのみ、ビジー応答し、印刷中は、印刷データの受信を保留する。

また、ＣＰＵ１は、プロトコル間で要求順番リストを統合する要求順管理手段の例である。

印刷出力デバイス６は、上記要求順管理手段が要求した順番で、印刷する印刷手段の例である。

次に、非標準系、ＷＳＤのそれぞれの通信プロトコル・印刷サービスでのコマンドレスポンス形式での印刷方法について説明する。

また、非標準系通信プロトコル・印刷サービスでは、要求順に着目したキューイング手法について説明し、ＷＳＤでは、標準方式に沿った印刷方式について説明する。

その後に、非標準系、ＷＳＤで通信プロトコル・印刷サービスでの一貫したキューイング管理手法と、これに対応する各コマンドレスポンス手法とについて説明する。

＜非標準系通信プロトコル・印刷サービス＞
最初に、従来の非標準系通信プロトコル・印刷サービスの要求順に着目したキューイング手法について説明する。

図３は、非標準系通信プロトコル・印刷サービスで使用されるＳｅｓｓｉｏｎＳｔａｒｔ要求・応答コマンドを示す図である。

ビットフィールド３０は、数値列であり、コマンド識別に使用する。各コマンドに対応して予め定められたコマンド数値列が入る。

このコマンドは、印刷データを転送するために、セッションの確立をリクエストする。プリンタが、まだセッションを成立していない状態である等、セッションを成立できる場合には、成功の値を、ビットフィールド３１のＲｅｓｕｌｔに代入して返却する。逆に、既にセッションが成立している等の理由によって、新たなセッションが確立できない場合、失敗の値を、ビットフィールド３１のＲｅｓｕｌｔに代入し、返却する。

ビットフィールド３２には、印刷ジョブのセッションＩＤが格納されている。ビットフィールド３３は、ビットフィールド３４〜３７のビット長を示す。ビットフィールド３４は、コマンド再送回数であり、同印刷ジョブに対して、ＳｅｓｓｉｏｎＳｔａｒｔを再送した回数を示す。なお、最初は、コマンド再送回数を、「０」とし、２回目は、再送回数が「１」になる。それ以降は、再送ごとに、１ずつ加算する。

ビットフィールド３５のタイムスタンプに、最初は「０」を入れて送信する。プリンタは、失敗応答時に、タイムスタンプを付加して返却する。他のジョブが実行中に、セッション開始要求ＳｅｓｓｉｏｎＳｔａｒｔを送信してきたジョブについて、プリンタのタイマ４で受信した時刻を取得する。「ｘｘ：ｘｘ：ｘｘ」のように、時：分：秒形式とし、要求順管理部１３の要求順リストに書き込む。プリンタでの印刷要求順の管理において、他のジョブ実行が完了した後は、このタイムスタンプの数値を比較し、先にセッション開始要求を受信したものから順番に、ジョブを実行することによって、データ到着順に印刷する。クライアントＰＣは、プリンタからの応答コマンドが、印刷データ転送が失敗であれば、タイムスタンプの値を記憶し、ＳｅｓｓｉｏｎＳｔａｒｔコマンドの再送時に、最初に取得したタイムスタンプ値を、代入する。

ビットフィールド３６には、印刷ジョブの発行元ＰＣ名を格納し、ビットフィールド３７には、印刷ジョブのドキュメント名を格納する。なお、プリンタからの要求コマンドには、発行元ＰＣ名、ドキュメント名を含めるが、応答コマンドの場合、このビットフィールドは、不要である。

図４は、非標準系通信プロトコル・印刷サービスで使用されるＤａｔａＷｒｉｔｅ要求・応答コマンドを示す図である。

ビットフィールド４０は、数値列を格納し、コマンド識別を格納するために使用する。各コマンドに対応して、予め定められたコマンド数値列が入る。このコマンドは、印刷データを転送するコマンドである。

ビットフィールド４１は、印刷データ転送が成功したか失敗したかの結果を、Ｒｅｓｕｌｔに代入し、返却する。ビットフィールド４２には、印刷ジョブのセッションＩＤが格納される。ビットフィールド４３は、ビットフィールド４４のビット長を格納する。

ビットフィールド４４に、印刷ジョブの送信データを格納する。１回のＤａｔａＷｒｉｔｅコマンドで送りきれないデータ量である場合、複数回のＤａｔａＷｒｉｔｅコマンドに分けて、データ転送を繰り返し実行する。

図５は、非標準系通信プロトコル・印刷サービスで、実際にＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドとＤａｔａＷｒｉｔｅ要求コマンドとを、クライアントＰＣから発行し、プリンタから印刷を行ったときの動作を示すシーケンス図である。

通信５１において、クライアントＰＣは、プリンタにＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを発行する。非標準系プロトコルモジュール１９で、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、印刷出力デバイス６が使用可能かどうかを、実行状態管理部１４に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。

通信５１の際に、プリンタＰＲ１は、アイドル状態であり、印刷待ちのジョブも存在しないので、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドのビットフィールド３１のＲｅｓｕｌｔに成功を代入して応答する。通信５２において、クライアントＰＣは、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドの成功を受信すると、データ転送が完了する通信５３まで、ＤａｔａＷｒｉｔｅ要求コマンドを繰り返し、発行する。通信５４において、クライアントＰＣは、ＳｅｓｓｉｏｎＥｎｄ要求コマンドを発行して終了する。

図６は、非標準系通信プロトコル・印刷サービスで、実際にＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドとＤａｔａＷｒｉｔｅ要求コマンドとを、複数台のクライアントＰＣから発行し、プリンタＰＲ１から印刷を行った場合における動作を示すシーケンス図である。

このシーケンス図を用いて、クライアントＰＣ１が印刷中に、クライアントＰＣ２とクライアントＰＣ３から、順次、印刷を発行した場合の動作について説明する。

通信６１において、ＰＣ１は、プリンタＰＲ１にＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを発行する。非標準系プロトコルモジュール１９が、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、印刷出力デバイス６が使用可能かどうかを、実行状態管理部１４に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを要求順管理部１３に問い合わせる。通信６１の際に、プリンタＰＲ１は、アイドル状態であり、印刷待ちのジョブも存在しないので、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドのビットフィールド３１のＲｅｓｕｌｔに成功を、代入し、応答する。

通信６２において、ＰＣ１は、プリンタＰＲ１からのＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドの成功を受信すると、データ転送が完了する通信６６まで、ＤａｔａＷｒｉｔｅ要求コマンドを繰り返し、発行する。

通信６３において、ＰＣ２は、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを、プリンタＰＲ１に発行する。しかし、非標準系プロトコルモジュールがプリンタに問い合わせすると、印刷出力デバイス６が、ＰＣ１の実行中の印刷ジョブによって占有されているので、実行状態管理部１４がＢＵＳＹを応答する。非標準系プロトコルモジュールは、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドのビットフィールド３１のＲｅｓｕｌｔに、失敗の値を代入し、タイマ４から取得したコマンド受信時刻に応じたタイムスタンプＴ１を代入し、ＰＣ２に応答する。

このときに、実際の印刷データは、スプールされないが、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信した順番のみに着目し、要求順リストに、ＰＣ２のジョブ情報のみをキューイングする。この要求順リストに登録されたジョブ情報には、実行状態管理部１４が管理している印刷ジョブの実行状態と、初回ＳｅｓｓｉｏｎＳｔａｒｔ受信時のタイムスタンプと、セッションＩＤ、発行元ＰＣ名、ドキュメント名とが含まれている。この要求順リストは、タイムスタンプの時間の早い順からキューイングされ、コマンド受信や印刷処理等の状態変化に伴って、要求順管理部１３によって追加・更新・削除される。

ＰＣ２は、通信６３において、ＳｅｓｓｉｏｎＳｔａｒｔに失敗したので、周期的に同コマンドを再送する。通信６４において、ＰＣ２は、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドの最初の再送を行っている。ビットフィールド３４のコマンド再送回数として、「１」を代入し、ビットフィールド３５のタイムスタンプには、初回のＳｅｓｓｉｏｎＳｔａｒｔ時の失敗応答によって返却されたタイムスタンプＴ１を代入する。しかし、ＰＣ１の印刷がまだ印字処理中であるので、プリンタＰＲ１は、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドを失敗で再度応答する。このときに、タイムスタンプＴ２を代入して応答する。

次に、ＰＣ３が、印刷を開始し、通信６５において、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを発行する。非標準系プロトコルモジュールが、実行状態管理部１４に、プリンタＰＲ１の使用状態を問い合わせる。このときに、印刷出力デバイス６は、処理が完了しているが、要求順リストに印刷ジョブ情報（ＰＣ２、タイムスタンプＴ１のジョブ）がキューイングされているので、ＢＵＳＹで応答する。

非標準系プロトコルモジュールは、失敗の値をＲｅｓｕｌｔ代入し、タイムスタンプＴ３を代入し、ＰＣ３に応答する。要求順リストに、ＰＣ３のジョブ情報をキューイングする。

通信６６、通信６７において、ＰＣ１の印刷処理が終了する。

通信６８において、ＰＣ３は、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドのｍ回目の再送を行っている。ビットフィールド３４のコマンド再送回数として、「ｍ」を代入し、ビットフィールド３５のタイムスタンプには、初回のＳｅｓｓｉｏｎＳｔａｒｔ時の失敗応答によって返却されたタイムスタンプＴ３を代入する。しかし、ＰＣ１の印刷がまだ印字処理中であるので、プリンタＰＲ１は、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドを失敗で再度応答する。このときに、タイムスタンプＴｍを代入して応答する。

通信６９において、ＰＣ２が、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドにタイムスタンプＴ１を付加し、発行すると、非標準系プロトコルモジュール経由で、実行状態管理部１４に使用状態を問い合わせる。キューイングされているＰＣ２のジョブ情報があるので、受信パケットのタイムスタンプと比較すると、タイムスタンプＴ２が一致するので、該当ジョブに対して印刷を許可する。通信７０で、ＤａｔａＷｒｉｔｅが発行され、ＰＣ２の印刷が開始する。

図７は、非標準系通信プロトコル・印刷サービスの印刷ジョブの実行状態を示す状態遷移図である。

実行状態７１は、アイドル状態であり、この状態で、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、成功応答を返し、印刷状態（実行状態７２）に遷移する。

実行状態７２は、印刷状態であり、この状態で、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、失敗応答を返し、ジョブ情報のキューイングを行う。印刷終了後は、ジョブ情報のキューイングがあれば、キューイング状態（実行状態７３）に遷移し、無ければ、アイドル状態（実行状態７１）に遷移する。

実行状態７３は、キューイング状態（ジョブ情報のみをキューに保存）であり、この状態でＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、最優先キューであれば、成功応答を返し、印刷状態（実行状態７２）に遷移する。設定されたキューイングの有効期限が切れたら、アイドル状態（実行状態７１）に遷移する。

＜ＷＳＤ＞
次に非標準系、ＷＳＤのそれぞれの通信プロトコル・印刷サービスでの一貫したキューイング管理手法と、これに対応する各コマンドレスポンス手法について説明する。

まず、ＷＳＤにおける標準方式に沿った従来の印刷方式について説明する。

図８は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されるＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを示す図である。

なお、図に記載されているｍｉｃｒｏｓｏｆｔ、ｗｉｎｄｏｗｓ、ｃａｎｏｎは、登録商標である。

ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドは、クライアントＰＣから要求されたコマンドに記載されているＰｒｉｎｔＴｉｃｋｅｔのＪｏｂＤｅｓｃｒｉｐｔｉｏｎに従って、印刷ジョブの生成を、プリンタＰＲ１に要求する。

ＳＯＡＰエンベロープには、ヘッダ領域とボディ領域とが含まれている。たとえば、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドでは、ＪｏｂＮａｍｅエレメントと、ＪｏｂＯｒｉｇｉｎａｔｉｎｇＵｓｅｒＮａｍｅとを使用する。それぞれの応答値は、印刷サービスの定義として定められた値を用いる。

図９は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されるＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの成功パケットを示す図である。

プリンタＰＲ１は、要求されたジョブの生成を承諾すると、ＪｏｂＩｄを生成し、コマンド応答する。

図１０は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの失敗パケットを示す図である。

プリンタＰＲ１は、要求されたジョブの生成に失敗すると、エラーコードのみを生成し、コマンド応答する。

図１１は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを示す図である。

ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドは、プリンタＰＲ１がジョブを生成することを承諾したＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドに記載されたＪｏｂＩｄと、ＤｏｃｕｍｅｎｔＤｅｓｃｒｉｐｔｉｏｎとの情報に従って、印刷データを転送する。

たとえば、上記ＤｏｃｕｍｅｎｔＤｅｓｃｒｉｐｔｉｏｎには、ＤｏｃｕｍｅｎｔＩｄ、Ｃｏｍｐｒｅｓｓｉｏｎ、Ｆｏｒｍａｔ、ＤｏｃｕｍｅｎｔＮａｍｅを記載する。それぞれの応答値は、印刷サービスの定義としてＷＳＤで定められた値を用いる。

図１２は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを示す図である。

ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドに続いて、全ての印刷データの転送が完了したと判断すると、プリンタは、クライアントＰＣにＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを発行する。

図１３は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで、実際にＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドとＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドとをクライアントＰＣから発行し、プリンタから印刷を行った場合のシーケンス図である。

通信８１において、クライアントＰＣは、プリンタＰＲ１に、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを発行する。ＷＳＤプロトコルモジュール１８が、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを受信すると、印刷出力デバイス６が使用可能であるかどうかを、実行状態管理部１４に問い合わせる。また同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。通信８１の際に、プリンタＰＲ１は、アイドル状態であり、印刷待ちのジョブも存在しないので、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドを成功にし、ＪｏｂＩｄを生成して応答する。

通信８２において、クライアントＰＣは、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの成功を受信すると、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを発行し、データ転送を開始する。同要求コマンドのＪｏｂＩｄには、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドに含まれていたＪｏｂＩｄを付加する。

印刷データの転送が完了すると、プリンタＰＲ１は、通信８３で、ＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを発行する。また、通信８４において、印刷終了時にＪｏｂＥｎｄＳｔａｔｅイベントを発行する。

次に、実施例１において、ＷＳＤで複数のクライアントＰＣから印刷を行った時のシーケンスについて説明する。

つまり、クライアントＰＣ１が印刷中に、クライアントＰＣ２とクライアントＰＣ３とが、順次、印刷を発行した場合の動作について説明する。

図１４は、標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで、実際にＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドとＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドとを、複数台のクライアントＰＣが発行し、プリンタから印刷した時のシーケンス図である。

通信９１において、ＰＣ１は、プリンタにＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを発行する。ＷＳＤプロトコルモジュール１８が、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを受信すると、印刷出力デバイス６が使用可能であるかどうかを、実行状態管理部１４に問い合わせる。また、同時に、キューイングされているジョブ情報が、要求順リストに無いかどうかを問い合わせる。通信９１の際に、プリンタＰＲ１は、アイドル状態であり、印刷待ちのジョブも存在しないので、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドのＪｏｂＩｄ＝１を生成し、応答する。

通信９２において、ＰＣ１は、プリンタＰＲ１からのＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの成功と、配布されたＪｏｂＩｄ＝１とを、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドに記載し、データ転送を開始する。ＳｅｎｄＤｏｃｕｍｅｎｔ応答は、印刷を終了した後に、後の通信９７で発行される。

通信９３において、ＰＣ２は、プリンタにＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを発行する。しかし、ＷＳＤプロトコルモジュールが、プリンタＰＲ１に問い合わせすると、印刷出力デバイス６が、ＰＣ１の実行中の印刷ジョブによって占有されているので、実行状態管理部１４が、ＢＵＳＹ応答を返す。従来の方法では、ＷＳＤプロトコルモジュールは、ＰＣ２にＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドを送り、失敗応答する。

非標準系通信プロトコル・印刷サービスと比較した場合、最初のＳｅｓｓｉｏｎＳｔａｒｔコマンドをプリンタＰＲ１が受信したタイミングで、受信したタイムスタンプで、ソートされるジョブの順番に着目してジョブ制御する。

しかし、ＷＳＤの標準プロトコルに沿って、通信を行った場合、そのままでは、ＳｅｓｓｉｏｎＳｔａｒｔの失敗時に、プリンタＰＲ１が返却していたタイムスタンプ情報を、コマンド応答に含めることができない。すなわち、非標準系通信プロトコル・印刷サービスで行っていたプリンタＰＲ１側でのスプールをしないキューイング制御の機構を適用することができない。

そこで、実施例１では、ＷＳＤ通信プロトコル・通信サービスにおいて、プリンタＰＲ１側でスプールしないキューイング制御の仕組みを適用するために、ＷＳＤの場合には、キューイング機構を切り替える。

通信９３において、ＰＣ１からの印刷ジョブが実行中であるので、実行状態管理部１４は、ＰＣ２からのＣｒｅａｔｅＰｒｉｎｔＪｏｂに対して、内部的にＢＵＳＹを返す。しかし、ＷＳＤプロトコルモジュール１８は、そこで非標準系のようにキューイングを行わずに、成功応答を応答する。すなわち、ＷＳＤにおいては、印刷中のＣｒｅａｔｅＰｒｉｎｔＪｏｂコマンドに対して、成功応答を返すことによって、クライアントＰＣからのコマンド再送処理を期待しない処理とする。

通信９３で、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドには、ＪｏｂＩｄ＝２を生成し、応答する。キューイングされたジョブ情報に、生成されたＪｏｂＩｄとコマンド受信時の（前に説明した非標準系相当の）タイムスタンプとを関連付け、保持することによって、要求順リストに存在するジョブのソートを実現する。

通信９４において、ＰＣ２から、ＪｏｂＩｄ＝２のジョブについてＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを発行する。ＷＳＤプロトコルモジュールは、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを受信すると、印刷出力デバイス６が使用可能であるかどうかを、実行状態管理部１４に問い合わせる。また同時に、キューイングされているジョブ情報が要求順リストに無いかどうかを問い合わせる。通信９４では、キューイングされているジョブ情報が存在しないが、印刷出力デバイス６が、ＰＣ１のＪｏｂＩｄ＝１のジョブによって実行中になっているので、プリンタＰＲ１側でセッションを張ったまま、印刷データの受信を停止する。このようにすることによって、順番が回ってくるまで、ＰＣ２の印刷処理を待たせる。

印刷データの受信を停止した場合、要求順管理部１３が、新たなジョブ情報を要求順リストの最後尾に追加する。この場合、ＰＣ２のＪｏｂＩｄ＝２のジョブ情報を、要求順リストに追加する。

要求順リストに登録されたジョブ情報には、実行状態管理部１４が管理している印刷ジョブの実行状態と、初回ＣｒｅａｔｅＰｒｉｎｔＪｏｂ受信時のタイムスタンプと、ＪｏｂＩＤ、発行元ＰＣ（又はユーザ）名、ドキュメント名とが含まれる。この要求順リストは、タイムスタンプの時間の早い順から、キューイングされ、コマンド受信や印刷処理等の状態変化に伴って、追加・更新・削除される。

通信９５において、ＰＣ３からのＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドが発行される。通信９３と同様に、印刷出力デバイスの実行状態は、ＢＵＳＹであるが、ＪｏｂＩＤ＝３を付加し、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドを返す。

通信９６において、ＰＣ３からのＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドが発行されるが、通信９４と同様に、ＪｏｂＩｄ＝３の印刷データの受信を停止する。

ＰＣ１のＪｏｂＩＤ＝１の印刷が完了すると、通信９７において、ＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを発行し、通信９８において、ＪｏｂＥｎｄＳｔａｔｅイベントを発行する。

その後に、印刷出力デバイスを監視していた実行状態管理部１４が、印刷可能になったことを検知する。ここで、要求順管理部１３が、要求順リスト１１１に蓄えられている印刷ジョブ情報を参照し、一番古いタイムスタンプを記録している印刷ジョブ情報はＰＣ２であるので、ＰＣ３の印刷ジョブは印刷待ち状態であると判断する。したがって、通信９９では、通信９６以降の通信状態と同様に、プリンタＰＲ１側でセッションを張ったまま、印刷データの受信を停止した状態を保持する。このようにすることによって、順番が回ってくるまで、ＰＣ３の印刷処理を待たせる。

その後に、印刷出力デバイスを監視していた実行状態管理部１４が、印刷可能な状態になったことを検知し、通信１００において、ＰＣ２へのデータ受信を再開し、印刷を実行する。

＜非標準系，標準ＷＳＤにおける通信プロトコル・印刷サービス同時管理＞
図１５は、実施例１において、非標準系通信プロトコル・印刷サービスとＷＳＤ標準プロトコル・印刷サービスとの印刷ジョブが混在するプリンタでの実行状態を表す状態遷移図である。

非標準系通信プロトコル・印刷サービスでは、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドに失敗応答するときに、キューイングし、ＷＳＤでは、ＳｅｎｄＤｏｃｕｍｅｎｔでデータ受信を停止するときに、キューイングする。

非標準系通信プロトコル・印刷サービスの状態遷移については、図４で説明したとおりである。次に、ＷＳＤについての差分を説明する。

実行状態１０１は、アイドル状態であり、この状態で、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを受信すると、成功応答を返し、データ受信を開始し、印刷状態（実行状態１０２）に遷移する。

実行状態１０２は、印刷状態であり、この状態であっても、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを受信した場合、成功応答を返し、ジョブ情報のキューイングを行い、キューイング状態（実行状態１０３）に遷移する。

実行状態１０３は、キューイング状態（ジョブ情報のみをキューに保存）であり、この状態で、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを受信すると、最優先キューである場合、成功応答を返し、データ受信を開始し、印刷状態（実行状態１０２）に遷移する。設定されたキューイングの有効期限が切れたら、データ受信を切断し、アイドル状態（実行状態１０１）に遷移する。

たとえば、非標準系通信プロトコル・印刷サービスでキューイング状態であるときに、ＷＳＤのＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを受信すると、通信９４のように、ＷＳＤのデータ受信を停止する処理を行うという実行状態管理を可能とする。

また、ＷＳＤでキューイング状態（実行状態１０３）であるときに、非標準系のＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドを受信すると、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドで失敗を応答し、キューイング状態（実行状態１０３）を維持する。

図１６は、実施例１において使用する要求順リストを示す図である。

ＰＣ１が印刷中であるときに、ＰＣ２のＪｏｂ２（非標準系）、ＰＣ３のＪｏｂ３（ＷＳＤ）が順次印刷されたことによって、ジョブ情報が、順番にキューイングされたケースについて説明する。したがって、要求順リスト１１１には、２種類の通信プロトコル・印刷サービス経由でのジョブ情報が登録されている。つまり、非標準系通信プロトコル・印刷サービスのジョブ情報１１２と、ＷＳＤのジョブ情報１１３とが登録されている。

非標準系通信プロトコル・印刷サービスのジョブ情報１１２は、プロトコル識別情報、印刷状態フラグ、セッションＩＤ、タイムスタンプ、発行元ＰＣ名、ドキュメント名によって構成されている。ＷＳＤのジョブ情報１１３は、プロトコル識別情報、印刷状態フラグ、ＪｏｂＩｄ、タイムスタンプ、発行元ＰＣ名、ドキュメント名によって構成されている。

プロトコル識別情報には、ＷＳＤ、非標準系通信プロトコル・印刷サービスのプロトコル番号が割り振られる。

印刷状態フラグは、図１５に示す各実行状態を反映したフラグ値である。

生成されたＪｏｂＩｄと、コマンド受信時にタイマ４から取得した「ｘｘ：ｘｘ：ｘｘ」のような時：分：秒形式のタイムスタンプとを関連付けて、ＷＳＤのジョブ情報１１３に保持することによって、要求順リストに存在するジョブのソートを実現する。

非標準系通信プロトコル・印刷サービス、ＷＳＤでの優先順位管理には、タイムスタンプの時刻情報を用いて一貫したジョブ情報のソートを行うことができる。

図１７は、実施例１における印刷開始要求コマンド受信処理を示すフローチャートである。

非標準系、ＷＳＤ以外の第３の通信プロトコル・印刷サービスであっても、印刷開始要求コマンドとデータ受信開始要求コマンドとに分類できれば、同様のフローチャートに対応できるので、複数プロトコル間で統合したフローチャートを示す。

また、要求順管理部１３、実行状態管理部１４は、複数プロトコルであっても、それぞれ１つの管理部で管理している。図１７に示す一貫したフローチャートチャートで、全体像を示すことによって、各プロトコルでの処理タイミングを明らかにする。

印刷するにあたり、クライアントＰＣから最初に発行される「印刷開始要求コマンド」は、非標準系通信プロトコル・印刷サービスでは、ＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドであり、ＷＳＤでは、ＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドに相当する。

クライアントＰＣからプリンタＰＲ１に印刷データを転送する場合、印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、非標準系では、ＤａｔａＷｒｉｔｅ要求コマンドに相当する。また、上記「データ受信開始要求コマンド」は、ＷＳＤでは、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドに相当する。

プリンタＰＲ１側でのスプールをしないキューイング機能を、それぞれの通信プロトコル・印刷サービスにおいて適用し、かつ、複数の通信プロトコル・印刷サービスであっても、要求順リストを一貫して管理する。このために、図１５に示す実行状態遷移図に従って運用する。すなわち、非標準系通信プロトコル・印刷サービスでは、「印刷開始要求コマンド」受信時にのみ、キューイング状態（実行状態１０３）への遷移が可能であり、「データ受信開始要求コマンド」受信時では、キューイング状態への遷移は許可しない。逆に、ＷＳＤでは、「印刷開始要求コマンド」受信時に、キューイング状態（実行状態１０３）への遷移を許可しないが、「データ受信開始要求コマンド」受信時にのみ、キューイング状態への遷移が可能である。

Ｓ１では、受信した印刷開始要求コマンドの通信プロトコル・印刷サービスを識別する。非標準系である場合、同コマンド受信時に、キューイング状態（実行状態１０３）への遷移が可能であると判断し、Ｓ２へ移行する。ＷＳＤである場合、同コマンド受信時にキューイング状態への遷移を許可しないので、Ｓ１２へ移行する。

Ｓ２〜Ｓ１１は、非標準系通信プロトコル・印刷サービスで使用する処理である。Ｓ２で、非標準系通信プロトコル・印刷サービスの処理を示し、プリンタＰＲ１のキューイング状態への遷移を、実行状態管理部１４に許可するように命令する。したがって、ＷＳＤから印刷開始要求コマンドを受信した場合、このタイミングでは、プリンタＰＲ１のキューイング状態への遷移は許可されない。

Ｓ１〜Ｓ１２へ移行した場合、ＷＳＤプロトコルモジュール１８が、要求順管理部１３、実行状態管理部１４に問い合わせしなくてもよい。ジョブがキューイング状態（実行状態１０３）であり、また、印刷状態（実行状態１０２）であっても、このタイミングでは、Ｓ１２で、成功応答をし、同コマンド処理を終了する。

Ｓ３で、コマンド受信時に非標準系通信プロトコル・印刷サービスのジョブ情報１１２のセッションＩＤと合わせて、タイマ４から取得した時刻を、ジョブ情報のタイムスタンプに記録する。

Ｓ４〜Ｓ１１は、ジョブ情報のキューイング追加処理を示すフローチャートである。ジョブ情報をキューイングする際に、要求順リスト１１１の順番を受信したコマンドのタイムスタンプに基づいてソートする。タイムスタンプは、Ｓ３で取得したものである。Ｓ４では、実行状態管理部１４でプリンタの実行状態を確認する。この結果、アイドル状態（実行状態１０１）であれば、Ｓ９に移行する。印刷状態（実行状態１０２）であれば、Ｓ５に移行する。Ｓ９に移行した後、キューイング状態（実行状態１０３）であれば、Ｓ１０に移行する。

Ｓ４で、プリンタが印刷状態であれば、Ｓ５で、要求順管理部１３に問い合わせ、要求順リスト１１１を参照する。

要求順リストにジョブ情報が１つでも、登録済みであれば、Ｓ６で、ジョブ情報を要求順リストの最後尾に追加し、Ｓ８で、印刷開始要求コマンド応答を失敗応答する。

要求順リストにジョブ情報が、未登録であれば、Ｓ７で、ジョブ情報を新規作成し、要求順リストに追加し、Ｓ８で、印刷開始要求コマンド応答を失敗応答する。

なお、図１７では、Ｓ６、Ｓ７でジョブ情報を要求順リストに追加した後に、Ｓ８で印刷開始要求コマンド応答を失敗応答している。この順序は、Ｓ５の判定処理の後に印刷開始要求コマンドの失敗応答をした後のタイミングでジョブ情報を追加する、または、ジョブ情報を新規追加する順序でもよい。

Ｓ８で、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドに失敗の値を代入し、クライアントＰＣに応答し、コマンド処理を終了する。Ｓ９で、要求順リストにジョブ情報が１つでも、登録済みであれば、Ｓ１０に移行し、ジョブ情報を、要求順リスト１１１の最後尾に追加し、Ｓ１１で、印刷開始要求コマンド応答を失敗応答する。Ｓ１１で、ＳｅｓｓｉｏｎＳｔａｒｔ応答コマンドに、失敗の値を代入し、クライアントＰＣに応答し、コマンド処理を終了する。

なお、図１７では、Ｓ１０でジョブ情報を要求順リストに追加した後に、Ｓ１１で印刷開始要求コマンド応答を失敗応答している。この順序は、Ｓ９の判定処理の後に印刷開始要求コマンドの失敗応答をした後のタイミングでジョブ情報を追加する、または、ジョブ情報を新規追加する順序でもよい。

Ｓ４〜Ｓ１０で、ジョブ情報のキューイング追加処理が終わると、Ｓ１２で、印刷開始要求コマンドへの応答を行う。非標準系通信プロトコル・印刷サービスであれば、ＳｅｓｓｉｏｎＳｔａｒｔ応答を成功で返し、ＷＳＤであれば、ＣｒｅａｔｅＰｒｉｎｔＪｏｂを成功で返す。Ｓ１３で、ＴＣＰ／ＩＰモジュール２０に、印刷データ受信待ちイベントを発行し、印刷データの受信に備える。ＴＣＰ／ＩＰモジュール２０は、セッション接続待ちの状態に入る。

図１８は、実施例１においてデータ受信開始要求コマンド受信処理を示すフローチャートである。

印刷データをプリンタＰＲ１に転送するにあたり、印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、非標準系通信プロトコル・印刷サービスでは、ＤａｔａＷｒｉｔｅ要求コマンドに相当する。印刷開始要求コマンドの次に発行される「データ受信開始要求コマンド」は、ＷＳＤでは、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドに相当する。

非標準系通信プロトコル・印刷サービスでは、ＤａｔａＷｒｉｔｅ要求コマンドに転送データを付加し、繰り返し送信することによって、印刷する。ＷＳＤでは、ＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドに続いて、印刷データを送信するので、繰り返し送信する必要が無い。

Ｓ２１において、印刷データの受信バッファへの書き込み処理が１回目か否かを判定する。初回の書き込みである場合、Ｓ２２で、初回ＷｒｉｔｅフラグをＯＮにセットし、Ｓ２３で、Ｗｒｉｔｅ（バッファ書き込み）モジュールにイベントを発行する。

Ｗｒｉｔｅモジュールは、このイベント発行を受け、データの受信待ち状態に入り、転送データを受信すると、ＲＡＭ３に確保した受信バッファに、データを書き込む。同時に、印刷用モジュール１５が、Ｒｅａｄモジュールによって順次データを読み出しつつ、実際の印字出力を実行する。

Ｓ２４で、受信したデータ受信開始要求コマンドの通信プロトコル・印刷サービスを識別する。非標準系である場合、同コマンド受信時にキューイング状態（実行状態１０３）への遷移を許可しないので、Ｓ３４へ移行する。ＷＳＤの場合、同コマンド受信時に、キューイング状態への遷移が可能であると判断し、Ｓ２５へ移行する。

Ｓ２５〜Ｓ３７は、ＷＳＤで使用するフローチャートである。Ｓ２５で、Ｓ３と同様に、タイムスタンプのための時刻情報を取得する。Ｓ２４〜Ｓ３３は、ジョブ情報のキューイング追加処理を示すフローチャートである。Ｓ４〜Ｓ１１と同様のキューイング処理である。ただし、Ｓ３０とＳ３３とは、キューイング処理の最後に、ＴＣＰ／ＩＰモジュール２０でのデータ受信を停止する処理を行う。

Ｓ３６とＳ３７とでは、ＴＣＰモジュールでデータが停止された後に、実行状態管理部１４にてアイドル状態（実行状態１０１）になるまで待機し、アイドル状態になった後にＴＣＰモジュールでのデータ受信を再開する。なお、このデータ受信待ちの待機処理にタイムアウト時間を設けることによって、ネットワークが切断された場合、プリンタにトラブルが発生してデータが送信されなくなった場合に、中断させる。Ｓ３６とＳ３７とでデータ受信が再開された場合、Ｓ３４へ移行する。ただし、タイムアウトによってデータ受信が中断された場合、データ受信開始要求コマンド処理をエラー終了し、該当するジョブ情報を破棄する。

Ｓ２６〜Ｓ３３で、ジョブ情報のキューイング追加処理が終わると、Ｓ３４で、受信データを受信バッファへ書き込み、Ｓ３５で、印刷開始要求コマンドへ応答する。非標準系通信プロトコル・印刷サービスであれば、ＤａｔａＷｒｉｔｅ応答コマンドを成功で返し、ＷＳＤであれば、ＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを成功で返す。

なお、上記実施例では、ネットワークに接続されているクライアントＰＣとネットワーク対応プリンタＰＲ１とによって構成されているが、クライアントＰＣは、印刷命令を発行できる他の画像入力デバイスであってもよい。

また、実施例１の機能を実現するプログラムコードを記録した記録媒体を、システム又は装置に供給し、そのシステム又は装置のコンピュータが、記憶媒体に格納されたプログラムコードを読み出し、実行することによって、上記実施例の目的が達成される。この場合、記憶媒体から読み出されたプログラムコード自体が、実施例１の機能を実現し、そのプログラムコード自体及びプログラムコードを記憶した記憶媒体は、本発明を構成する。

本発明の実施例１であるネットワーク対応プリンタＰＲ１を示す図である。 実施例１であるネットワーク対応プリンタＰＲ１に設けられているＲＯＭ２に記憶されているプログラムＰ１のモジュールの構成を示す図である。 非標準系通信プロトコル・印刷サービスで使用されるＳｅｓｓｉｏｎＳｔａｒｔ要求・応答コマンドを示す図である。 非標準系通信プロトコル・印刷サービスで使用されるＤａｔａＷｒｉｔｅ要求・応答コマンドを示す図である。 非標準系通信プロトコル・印刷サービスで、実際にＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドとＤａｔａＷｒｉｔｅ要求コマンドとを、クライアントＰＣから発行し、プリンタから印刷を行ったときの動作を示すシーケンス図である。 非標準系通信プロトコル・印刷サービスで、実際にＳｅｓｓｉｏｎＳｔａｒｔ要求コマンドとＤａｔａＷｒｉｔｅ要求コマンドとを、複数台のクライアントＰＣから発行し、プリンタＰＲ１から印刷を行った場合における動作を示すシーケンス図である。 非標準系通信プロトコル・印刷サービスの印刷ジョブの実行状態を示す状態遷移図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されるＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドを示す図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されるＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの成功パケットを示す図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＣｒｅａｔｅＰｒｉｎｔＪｏｂ応答コマンドの失敗パケットを示す図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドを示す図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで使用されているＳｅｎｄＤｏｃｕｍｅｎｔ応答コマンドを示す図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで、実際にＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドとＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドとをクライアントＰＣから発行し、プリンタから印刷を行った場合のシーケンス図である。 標準プロトコルであるＷＳＤ通信プロトコル・印刷サービスで、実際にＣｒｅａｔｅＰｒｉｎｔＪｏｂ要求コマンドとＳｅｎｄＤｏｃｕｍｅｎｔ要求コマンドとを、複数台のクライアントＰＣが発行し、プリンタから印刷した時のシーケンス図である。 実施例１において、非標準系通信プロトコル・印刷サービスとＷＳＤ標準プロトコル・印刷サービスとの印刷ジョブが混在するプリンタでの実行状態を表す状態遷移図である。 実施例１において使用する要求順リストを示す図である。 実施例１における印刷開始要求コマンド受信処理を示すフローチャートである。 実施例１においてデータ受信開始要求コマンド受信処理を示すフローチャートである。

符号の説明

１…ＣＰＵ、
２…ＲＯＭ、
３…ＲＡＭ、
４…タイマ、
５…操作パネル、
６…印刷出力デバイス、
７…Ｅｔｈｅｒｎｅｔコントローラ、
８…ＬＡＮ、
９…システムバス、
Ｐ１…ＲＯＭ２に記憶されているプログラム、
１０…アプリケーション層、
１１…ミドルウェア層、
１２…オペレーション・システム、
１３…要求順管理部、
１４…実行状態管理部、
１５…印刷用モジュール、
１６…ＨＴＴＰモジュール、
１７…ＸＭＬ解析モジュール、
１８…ＷＳＤプロトコルモジュール、
１９…非標準系プロトコルモジュール、
２０…ＴＣＰ／ＩＰモジュール、
２１…ＵＤＰモジュール、
２２…ＯＳ起動処理、
２３…ＬＡＮドライバ。

Claims (6)

1. 印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する印刷装置において、
   受信した非標準系の印刷開始要求コマンド又は標準系のデータ受信開始要求コマンドに応じた失敗応答するタイミングで、上記印刷ジョブ情報を要求順リストに登録する制御手段と；
   上記要求順番リストを管理する要求順管理手段が要求した順番で印刷する印刷手段と；
   を有することを特徴とする印刷装置。
2. 印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する印刷装置において、
   複数の通信プロトコル経由での印刷機能を持ち、印刷中に受信した他のクライアントデバイスからの印刷開始要求コマンドに、特定のジョブ情報が含まれているか否かを識別する識別手段と；
   上記識別手段による識別結果に応じて、受信した非標準系の印刷開始要求コマンド又は標準系のデータ受信開始要求コマンドに応じた失敗応答するタイミングで、上記印刷ジョブ情報を要求順リストに登録する制御手段と；
   プロトコル間で要求順番リストを統合する要求順管理手段と；
   上記要求順管理手段が要求した順番で、印刷する印刷手段と；
   を有することを特徴とする印刷装置。
3. 請求項２において、
   上記識別手段は、印刷開始要求コマンドに、再送回数、最初にプリンタから返却されたタイムスタンプが含まれているかどうかを識別する手段であることを特徴とする印刷装置。
4. 請求項２において、
   上記制御手段は、上記印刷開始要求コマンドに、特定のジョブ情報を含まないプロトコルである場合、印刷中であっても、クライアント機器から送信された上記印刷開始要求コマンドに対して、エラー応答せずに受諾し、上記データ受信開始要求コマンドにのみ、ビジー応答し、印刷中は、印刷データの受信を保留する手段であることを特徴とする印刷装置。
5. 印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する印刷装置の制御方法において、
   印刷装置で印刷データをスプールするか否かに応じて、受信した非標準系の印刷開始要求コマンド又は標準系のデータ受信開始要求コマンドに応じた失敗応答するタイミングで、上記印刷ジョブ情報を要求順リストに登録する制御工程と；
   上記要求順番リストを管理する要求順管理工程で要求された順番で印刷する印刷工程と；
   を有することを特徴とする印刷装置の制御方法。
6. 印刷中は、他のクライアント機器から送信された印刷データを受信せず、要求順番リストによって印刷ジョブ情報を管理し、印刷可能となった時点で、クライアント機器から印刷データを受信することを許可する印刷装置の制御方法において、
   複数の通信プロトコル経由での印刷機能を持ち、印刷中に受信した他のクライアントデバイスからの印刷開始要求コマンドに、特定のジョブ情報が含まれているか否かを識別する識別工程と；
   上記識別工程による識別結果に応じて、受信した非標準系の印刷開始要求コマンド又は標準系のデータ受信開始要求コマンドに応じた失敗応答するタイミングで、上記印刷ジョブ情報を要求順リストに登録する制御工程と；
   プロトコル間で要求順番リストを統合する要求順管理工程と；
   上記要求順管理工程で要求された順番で、印刷する印刷工程と；
   を有することを特徴とする印刷装置の制御方法。

Images