(57)【要約】　　　（修正有）【課題】ホストコンピュータからプリンタに対する印刷データの送信の中止を、ＵＳＢプリンタクラスプロトコルの下で、受信側プリンタの負担を増大させることなく実現することを課題とする。【解決手段】ホストコンピュータは、プリンタに対して印刷データ送信中に送信中止要求が発生すると（Ｓ２０６−ＮＯ）、データ送信と異なるチャネルを介してプリンタにデータ送信中止を通知する（Ｓ２１７）。プリンタそれを受けて処理を中止し、受信されたデータを破棄する。処理の中止および受信データの廃棄、および次のデータストリームの受信準備の完了の後、プリンタはホストコンピュータに対して、中断手順の完了を通知する。ホストコンピュータは、プリンタから中断手順の完了通知を受信する（Ｓ２１９）までは次のデータストリームを送信しない。【選択図】図５Ａ
2004007426.tif 000002
【特許請求の範囲】
【請求項１】
受信装置に対してＵＳＢによりデータを送信する通信装置であって、
データ通信用のエンドポイントを介してデータを送信する送信手段と、
前記送信手段によりデータの送信途中に該データ送信の中止要求が発生した場合、ＵＳＢクラスが規定する制御用のエンドポイントを介して前記受信装置に対してデータ送信の中止を通知する通知手段とを有することを特徴とする通信装置。
【請求項２】
パケットの送信が失敗して所定時間経過後、ユーザに継続するか確認する確認手段を更に有し、前記データ送信の中止要求は、前記確認手段により継続中止が選択された場合に発生することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記データ送信の中止を受信装置に通知した後、中止が完了したことを受信装置から受信するまで、次のデータ送信処理を行わないことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記受信装置は、プリンタを含むことを特徴とする請求項１記載の通信装置。
【請求項５】
前記データ送信の中止要求は、ＵＳＢクラスが規定するベンダーユニークコマンドで定義されることを特徴とする請求項１記載の通信装置。
【請求項６】
通信装置とＵＳＢにより接続された受信装置であって、
前記通信装置からデータ通信用のエンドポイントを介してデータを受信する受信手段と、
前記受信手段によりデータの受信中に、ＵＳＢクラスが規定するデフォルトの制御用のエンドポイントを介して送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行う手段とを有することを特徴とする受信装置。
【請求項７】
前記送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行った後、中止処理が完了したことを通信装置に返信する手段を更に有することを特徴とする請求項６に記載の受信装置。
【請求項８】
前記受信装置は、プリンタを含むことを特徴とする請求項６記載の受信装置。
【請求項９】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスで規定されている方法で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント０以外のエンドポイントでプリンタに送信されている際に、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、前記コンピュータはエンドポイント０を介してＵＳＢプリンタクラスで規定されたＳＯＦＴＲＥＳＥＴをプリンタに送出することを特徴とする通信システム。
【請求項１０】
請求項９記載のシステムであって、プリンタのＵＳＢプリンタクラスドライバからエンドポイント０を介してＵＳＢプリンタクラスで規定されたＳＯＦＴＲＥＳＥＴの受信報告がきたとき、その報告を受信したプリンタはエンドポイント１を介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備えることを特徴とする通信システム。
【請求項１１】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスで規定されている方法で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント０以外のエンドポイントでプリンタに送信されるとき、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、ＵＳＢプリンタクラスドライバにすでに送出要求した全てのパケット送出要求が完了したことを確認してからコンピュータがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＯＵＴコマンドにアボート要求識別子を搭載して送出することにより、プリンタ側にそのデータ列の送信の中止を通達し、そしてエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を受信するまで新規のデータ列を送出しないことを特徴とするシステム。
【請求項１２】
請求項１１のシステムであって、プリンタのＵＳＢプリンタクラスドライバがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＯＵＴコマンドでアボート要求識別子を受信したとき、上位のクライアント（プリンタアプリとする）に対してアボート要求を受信したことを報告し、その報告を受信したプリンタアプリは前記エンドポイントを介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備え、次の新たなデータ列受信に対する備えが完了したとき、ＵＳＢクラスドライバを介しエンドポイント０を介してＵＳＢクラスで規定されたＵＳＢベンダ固有コマンドのＩＮコマンドを利用しａｂｏｒｔ完了識別子をコンピュータ側に送出することを特徴とするシステム。
【請求項１３】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスで規定されている規格で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント０以外のエンドポイントでプリンタに送信されるとき、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、コンピュータアプリがＵＳＢプリンタクラスドライバに既に出した全てのパケット送出要求が完了したことを確認してからコンピュータがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドにアボート要求識別子を搭載して受信要求を送出することにより、プリンタ側にそのデータ列の送信の中止を通達すると同時に前記のＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を受信するまで新規のデータ列を送出しないことを特徴とする通信システム。
【請求項１４】
請求項１３のシステムであって、プリンタのＵＳＢクラスドライバがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドでアボート要求識別子が搭載されたコマンドを受信したとき、上位のクライアントに対してアボート要求を受信したことを報告し、その報告を受信したクライアントは前記エンドポイントを介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備え、次の新たなデータ列受信に対する備えが完了したとき、を介しエンドポイント０を介して前記のＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を搭載して、コンピュータに直前のデータ列の破棄の完了と次のデータ列の受信準備が完了したことを通知することを特徴とする通信システム。
【請求項１５】
受信装置に対してＵＳＢによりデータを送信する通信方法であって、
データ通信用のエンドポイントを介してデータを送信する送信工程と、
前記送信工程によりデータの送信途中に該データ送信の中止要求が発生した場合、ＵＳＢクラスが規定する制御用のエンドポイントを介して前記受信装置に対してデータ送信の中止を通知する通知工程とを有することを特徴とする通信方法。
【請求項１６】
通信装置とＵＳＢによりデータを受信する受信方法であって、
前記通信装置からデータ通信用のエンドポイントを介してデータを受信する受信工程と、
前記受信工程によりデータの受信中に、ＵＳＢクラスが規定するデフォルトの制御用のエンドポイントを介して送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行う工程とを有することを特徴とする受信方法。
【請求項１７】
受信装置に対してＵＳＢによりデータを送信するためのプログラムであって、
データ通信用のエンドポイントを介してデータを送信する送信工程と、
前記送信工程によりデータの送信途中に該データ送信の中止要求が発生した場合、ＵＳＢクラスが規定する制御用のエンドポイントを介して前記受信装置に対してデータ送信の中止を通知する通知工程と
をコンピュータにより実行させることを特徴とするプログラム。
【請求項１８】
通信装置とＵＳＢによりデータを受信するためのプログラムであって、
前記通信装置からデータ通信用のエンドポイントを介してデータを受信する受信工程と、
前記受信工程によりデータの受信中に、ＵＳＢクラスが規定するデフォルトの制御用のエンドポイントを介して送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行う工程と
をコンピュータにより実行させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばＵＳＢ（ユニバーサルシリアルバス）フォーラムで規定されたＵＳＢプリンタクラスの規定に従って通信を行うコンピュータとプリンタとの間等における通信を行うための通信システム及びその制御方法に関するものである。
【０００２】
【従来の技術】
ＵＳＢは、コンピュータ等のホストと周辺装置等のファンクションとを接続するためのシリアルバス規格であり、機械的電気的規格のみならず、種々の転送モードの手順や機器の種類に応じたプロトコルが、ＵＳＢの標準化団体であるＵＳＢインプリメンターズフォーラムにより規定されている。規定されたプロトコル中には、ＵＳＢによりホストとプリンタとを接続するためのＵＳＢプリンタクラスのプロトコルも含まれている。ＵＳＢプリンタクラスは、例えばマイクロソフト社製のオペレーティングシステムであるウインドウズ（登録商標）やＬＩＮＵＸ（登録商標）、アップル社のＭａｃＯＳ等にＵＳＢプリンタクラスドライバとして実装済み、または実装可能である。ＵＳＢでは、データはパケットとして送受信されるため、マルチチャネル化が実現できる。プリンタクラスドライバでは、ＵＳＢにより提供される論理的なチャネル（エンドポイント（ＥＮＤＰＯＩＮＴ）と呼ばれる）のうちのたとえばエンドポイント１、エンドポイント２という２つのチャネルを用いてデータの双方向通信が実現される。またエンドポイント０でＵＳＢプリンタクラスが規定するコマンドの送受信が行われる。
【０００３】
このＵＳＢプリンタクラスの規定ではセッションの概念がないため、データ通信の途中で通信を中止したとき、受信側は受信したデータの内容を検証するかタイムアウトを検出する以外、送信側が通信を中止したことをしる方法がなかった。
【０００４】
【発明の解決する課題】
しかしながら、受信側でタイムアウトにより中止を検出したとしても、実際には送信側におけるデータ送信の遅延に過ぎず、データ送信は中止されていない場合もあり得る。具体的にはプリンタで紙なし等が発生しそのため送信側がデータを送信できずに受信側は受信のタイムアウトを検出した場合等がある。また、データの内容からだけではデータ送信の中止が生じたものと判断できない場合もある。
【０００５】
このように、送信側における動作と受信側における判断とが一致せず、受信側では本来行われるべきでないデータ送信の中止処理を行ってしまったり、本来行われるべきデータ送信の中止処理を行わないなどにより、本来あるべき処理が行われない事態が生じるおそれがあった。例えば、送信側がホストコンピュータであり、受信側がプリンタである場合を考える。この場合、データ送信の中止により、プリンタはそれまでに受信して未出力のデータを破棄し、その後受信するデータは新たな印刷ジョブを構成するものとして印刷処理すべきところ、データ送信の中止を検出できなければ、中止された印刷ジョブとそれに後続する新たな印刷ジョブとをひとつのジョブに含まれるデータとして処理し、誤った内容を印刷出力することになる。反対に、プリンタが誤ってデータ送信の中止と判断すれば、本来中止すべきでない印刷処理が中止されてしまう。
【０００６】
本発明は上記従来例に鑑みて成されたもので、送信側がデータ送信を中止したことを受信側で確実に誤りなく通知できるＵＳＢクラス、及びＵＳＢプリンタクラスの規定に従う通信システム及び制御方法を提供することを目的とする。
【０００７】
特に、送信側がホストコンピュータであり、受信側がプリンタである場合、受信側のプリンタにおいて、データの内容の解析をすることがなく効率的かつ確実にデータ送信の中止を認識して中止手順を実行できる通信システム及び制御方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明のシステムでは、２つの電子機器がＵＳＢプリンタクラスの規定に従い通信を行っているとき、データの送信側がそのデータ転送を中止したとき、送信側は、エンドポイント０を使用して、受信側にデータ転送中止を伝達する。
【０００９】
このため、受信側ではエンドポイント１を介して受信するデータの内容を検査しなくとも、エンドポイント０を介して受信するコマンドの内容を判定するだけで送信の中止を確実に知ることができる。
【００１０】
また、本発明はさらに上記目的を達成するために次のような構成を有する。
【００１１】
受信装置に対してＵＳＢによりデータを送信する通信装置であって、
データ通信用のエンドポイントを介してデータを送信する送信手段と、
前記送信手段によりデータの送信途中に該データ送信の中止要求が発生した場合、ＵＳＢクラスが規定するエンドポイント０を介して前記受信装置に対してデータ送信の中止を通知する通知手段とを有する。
【００１２】
更に好ましくは、本発明は、上記構成において、パケットの送信が失敗して所定時間経過後、ユーザに継続するか確認する確認手段を更に有し、前記データ送信の中止要求は、前記確認手段により継続中止が選択された場合に発生する。
【００１３】
更に好ましくは、本発明は、上記構成において、前記データ送信の中止を受信装置に通知した後、中止が完了したことを受信装置から受信するまで次のデータ送信処理を行わない。
【００１４】
更に好ましくは、本発明は、上記構成において、前記受信装置は、プリンタを含む。
【００１５】
更に好ましくは、本発明は、上記構成において、前記データ送信の中止要求は、ＵＳＢクラスが規定するベンダーユニークコマンドで定義される。
【００１６】
あるいは、本発明の次のような構成を有する。
【００１７】
通信装置とＵＳＢにより接続された受信装置であって、
前記通信装置からデータ通信用のエンドポイントを介してデータを受信する受信手段と、
前記受信手段によりデータの受信中に、ＵＳＢクラスが規定するエンドポイント０を介して送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行う手段とを有する。
【００１８】
更に好ましくは、本発明は、上記構成において、前記送信を中止する旨が通知された場合、送信が中止されたデータの破棄を行った後、中止処理が完了したことを通信装置に返信する手段を更に有する。
【００１９】
更に好ましくは、本発明は、上記構成において、前記受信装置は、プリンタを含む。
【００２０】
あるいは本発明の次のような構成を有する。
【００２１】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスで規定されている方法で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント１以外のエンドポイントでプリンタに送信されている際に、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、前記コンピュータはエンドポイント０を介してＵＳＢプリンタクラスで規定されたＳＯＦＴＲＥＳＥＴをプリンタに送出する。
【００２２】
更に好ましくは、本発明は、上記構成において、次のような構成を有する。
【００２３】
プリンタのＵＳＢプリンタクラスドライバからエンドポイント０を介してＵＳＢプリンタクラスで規定されたＳＯＦＴＲＥＳＥＴの受信報告がきたとき、その報告を受信したプリンタはエンドポイント１を介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備える。
【００２４】
あるいは、本発明の次のような構成を有する。
【００２５】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスドライバで規定されている方法で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント０以外のエンドポイントでプリンタに送信されるとき、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、ＵＳＢプリンタクラスドライバにすでに送出要求した全てのパケット送出要求が完了したことを確認してからコンピュータがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＯＵＴコマンドにアボート要求識別子を搭載して送出することにより、プリンタ側にそのデータ列の送信の中止を通達し、そしてエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を受信するまで新規のデータ列を送出しない。
【００２６】
更に好ましくは、本発明は、上記構成において、次のような構成を有する。
【００２７】
プリンタのＵＳＢプリンタクラスドライバがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＯＵＴコマンドでアボート要求識別子を受信したとき、上位のクライアント（プリンタアプリとする）に対してアボート要求を受信したことを報告し、その報告を受信したプリンタアプリはエンドポイント１を介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備え、次の新たなデータ列受信に対する備えが完了したとき、ＵＳＢプリンタクラスドライバを介しエンドポイント０を介してＵＳＢプリンタクラスで規定されたＵＳＢベンダ固有コマンドのＩＮコマンドを利用しａｂｏｒｔ完了識別子をコンピュータ側に送出する。
【００２８】
あるいは、本発明の次のような構成を有する。
【００２９】
ＵＳＢポートとＵＳＢポートを動作させるＵＳＢホスト側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのホスト側として動作するドライバを備えたコンピュータと、ＵＳＢポートとＵＳＢポートを動作させるＵＳＢターゲット側ドライバとＵＳＢフォーラムで標準化されたＵＳＢプリンタクラスのターゲット側として動作するドライバを備えた電子機器とがＵＳＢ回線で接続されているシステムにおいて、
コンピュータ側でＵＳＢプリンタクラスドライバのクライアントであるアプリケーションプログラムがＵＳＢプリンタクラスドライバを介して一連のデータ列をプリンタにＵＳＢプリンタクラスドライバで規定されている規格で送信しているときにすべてのデータ列の送信が完了しない時点でその送信を中止する要求が発生した場合、前記クライアントは送信の中止要求を通信ドライバに通知することが可能な通信システムであって、
送信要求したデータ列が少なくとも２つ以上のＵＳＢパケットに分割してＵＳＢプリンタクラスのプロトコルに則りエンドポイント０以外のエンドポイントでプリンタに送信されるとき、送信要求したデータ列を分割してパケット化して作成されたすべてのパケットの送信が完了する前にコンピュータ側のＵＳＢプリンタクラスドライバのクライアントがそのデータ列送信のキャンセルを要求してきたとき、コンピュータアプリがＵＳＢプリンタクラスドライバに既に出した全てのパケット送出要求が完了したことを確認してからコンピュータがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドにアボート要求識別子を搭載して受信要求を送出することにより、プリンタ側にそのデータ列の送信の中止を通達すると同時に前記のＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を受信するまで新規のデータ列を送出しない。
【００３０】
更に好ましくは、本発明は、上記構成において、次のような構成を有する。
【００３１】
プリンタのＵＳＢプリンタクラスドライバがエンドポイント０を介してＵＳＢ規格で規定されたＵＳＢベンダ固有コマンドのＩＮコマンドでアボート要求識別子が搭載されたコマンドを受信したとき、上位のクライアントに対してアボート要求を受信したことを報告し、その報告を受信したクライアントはエンドポイント１を介して受信したデータでアプリケーションレベルでのデータ受信が完結していないものがあれば、受信が完結していないデータ列をすべて破棄し、次の新たなデータ列受信に備え、次の新たなデータ列受信に対する備えが完了したとき、を介しエンドポイント０を介して前記のＵＳＢベンダ固有コマンドのＩＮコマンドにアボート完了報告識別子を搭載して、コンピュータに直前のデータ列の破棄の完了と次のデータ列の受信準備が完了したことを通知する。
【００３２】
【発明の実施の形態】
［第１実施形態］
以下、図面を参照し、本発明の実施形態を詳細に説明する。
【００３３】
図３は本発明に適用したシステム構成の一例である。図３において、コンピュータ３１とプリンタ３２とはＵＳＢにより接続されている。また、コンピュータ３１及びプリンタ３２にはＵＳＢプリンタクラスドライバがインストールされている。それらドライバはＵＳＢプリンタクラスに規定された手順に従って動作する。
【００３４】
具体的には、コンピュータ３１にプリンタ３２がＵＳＢケーブルで接続された場合、ホストはＵＳＢクラスが規定するの制御データ転送用のエンドポイント０（すべてのＵＳＢ機器は無条件のサポートしなければいない）を使って、接続された機器を特定する処理およびＣｏｎｆｉｇｕｒａｔｉｏｎ処理を行うためにプリンタ３２に問い合わせを行う。その問い合わせに対しプリンタ３２は機器を特定する情報（ベンダＩＤ、プロダクトＩＤ等）を返信するとともに、エンドポイント、例えばエンドポイント１をＵＳＢプリンタクラスが規定する方法に従って使用することを示す情報をコンピュータ３１に返信する。以後、コンピュータ３１からプリンタ３２に印刷データを送信する場合はエンドポイント１を用いて行うことになる。
【００３５】
図１は図３のホストコンピュータ３１の内部のブロック構成図である。ＣＰＵ１は本発明に係るホストコンピュータを制御する。ＲＡＭ２はＣＰＵ１のワークエリア等として利用される。ハードディスク３は、本発明に係るプログラム等を格納する（フロッピー（登録商標）ディスク、ＣＤＲＯＭ等でもよい）。ユーザコマンド入力装置４はユーザーのコマンドを入力するための入力装置（具体的にはマウス、キーボード等）である。ＵＳＢポート５はプリンタ等のデバイスと接続するためのインターフェースである。メインバス８は、これら各構成要素を接続している。
【００３６】
図２は、図３のプリンタ（印字装置）３２の内部のブロック構成図である。ＣＰＵ１１は本発明に係るＵＳＢプリンタを制御する。ＲＡＭ１２はＣＰＵ１のワークエリア等を提供する。ＲＯＭ１３は本発明に係るプリンタを制御するためのプログラムが格納されている（フロッピー（登録商標）ディスク、ＣＤＲＯＭ、ハードディスク等でもよい）。ＵＳＢポート１５は、ホストコンピュータ３１と接続するためのインターフェースである。印字装置（プリンタエンジン部）１４は印字用紙に印字を実行する。メインバス１８は、これら各構成要素を接続している。コンピュータ３１とプリンタ３２とはそれぞれＵＳＢポート５，１５に接続されたＵＳＢケーブルを介して通信を行う。
【００３７】
尚、本実施形態においては、特に断らない限り、ホストコンピュータで実行される手順は、ＣＰＵ１がメインバス８を介してＲＡＭ２から読み出したプログラムを実行し、ハードディスク３、ユーザーコマンド入力装置４、ＵＳＢポート５を制御することで実施される。また、印字装置で実行される手順は、ＣＰＵ１１がメインバス１８を介してＲＡＭ１２から読み出したプログラムを実行し、ＲＯＭ１３、ＵＳＢポート１５、印字装置１４を制御して実施する。
【００３８】
＜ホストコンピュータにおける印刷データ送信手順＞
最初に図１乃至図３のシステムにおけるコンピュータ１による印刷時の制御動作を図４，５Ａ，５Ｂを用いて詳細に説明する。
【００３９】
まず図４を用いて説明する。ユーザーがアプリケーションを起動し（Ｓ１０１）、なんらかのデータ（文書、画像等）を作成し、そのデータを印字するために印字指示を入力する（Ｓ１０２）。印字指示がされるとアプリケーションは印字処理を開始し（Ｓ１０４）、プリンタドライバをコールする。なお本実施例で使用する「印字」は必ずしも文字を記録するという意味ではなく、写真や図形等、ひろく画像一般の印刷を含んでいる。
【００４０】
コールされたプリンタドライバは、指示されたデータを、指定されたプリンタがサポートする印字データに変換し（Ｓ１０５）、変換された印字データをハードディスク３に格納する（Ｓ１０６）。そして印字プロセスを介するように印字プロセスをキックする（Ｓ１０７）。なお本実施形態において印字プロセスをキックするとは、印字プロセスに対して印字要求を発行することを意味している。また印字要求はその優先順位等によっては待機させられる場合があるが、それを印字要求のキックの待機と呼ぶ。
【００４１】
次に図５Ａ，５Ｂを用いてホストコンピュータ３１における印字プロセスの動作を説明する。印字プロセスは、ハードディスク３に格納された印字データを、ＵＳＢプリンタクラスドライバによりプリンタに対して送信させるためのプロセスである。図５では印字プロセスは起動された状態で印字要求の発行、すなわちキックを待っているが、キックにより印字プロセスが起動される場合もあり得る。
【００４２】
図５Ａ，５Ｂにおいて、印字プロセスが起動された後（Ｓ２０１）、キックされるのを待つ（Ｓ２０２）。キックされると、すなわち印字要求が発行されると、キック時にアプリケーションから指示されたファイルをオープンし、ハードディスク３から印字データを読み取る（Ｓ２０３）。そしてその印字データを複数のパケットに分割し、ＵＳＢプリンタクラスドライバに対してパケットの送信を要求する（Ｓ２０４）。そしてＵＳＢプリンタクラスドライバからのそのパケットの送信の完了通知（送信完了報告）を待つ（Ｓ２０５）。
【００４３】
ＵＳＢプリンタクラスドライバは送信の要求に応えて指定されたパケットを指定された宛先に送信し、送信が完了するとクライアント（ここでは印字プロセス）に対して送信完了報告を発行する。
【００４４】
印字プロセスでは、ＵＳＢプリンタクラスドライバから送信完了報告がきたなら、アプリケーション、ＯＳまたはユーザーから印字中止要求を受信したかどうかを、中止要求ＦＬＧ（フラグ）を参照して調べる（Ｓ２０６）。中止要求フラグは、ユーザ等から中止要求があった場合にセットされるフラグであり、初期的にはリセット（ＯＦＦ）されている。
【００４５】
もし中止要求ＦＬＧがＯＮで、印字中止要求を受信していれば、図９で表されるアボート要求識別子９０１を作成し（Ｓ２１６）、ＵＳＢプリンタクラスドライバに対して、ＵＳＢプリンタクラスにおいて定められているベンダ固有（ＶｅｎｄｏｒＵｎｉｑｕｅ）コマンドを利用して、作成したアボート要求識別子９０１を送信するように要求する（Ｓ２１７）。そして次に、ＵＳＢクラスドライバに対して、ＵＳＢクラスが定めるベンダ固有コマンドを利用した図１０で表されるアボート完了報告要求識別子１００１を発行して、アボート完了報告識別子１００２を受信するよう要求する（Ｓ２１８）。図１０で表されるアボート完了受信報告１００２が受信されると（Ｓ２１９）、ユーザーにその印刷のキャンセル処理が完了したことを通知する（Ｓ２２９）。そしてステップＳ２０２から繰り返し行う。なお、ここでユーザとは印字プロセスのクライアントであって、必ずしも操作者であるとは限らず、アプリケーションプロセスやオペレーティングシステムのプロセスなど、他のプロセスであることもある。
【００４６】
もしステップＳ２０６において印字中止要求をユーザ等から受信していなければ、受信完了報告の内容が、「送信成功」か「送信失敗」かを調べる（Ｓ２０７）。送信成功であれば、パケット化した全ての印字データの転送が終了したかどうか調べる（Ｓ２０８）。全ての印字データの転送が終了していなければステップＳ２０３から処理を続ける。終了していればステップＳ２０２に戻って新たな印字要求を待つ。
【００４７】
もし前記受信完了報告の内容が「送信失敗」であれば、カウンタＲｅｔｒｙＣｏｕｍｔを１増加させる（Ｓ２０９）。このカウンタＲｅｔｒｙＣｏｕｍｔはＲＡＭ２に確保される。そしてカウンタＲｅｔｒｙＣｏｕｍｔの値を予め定められている再試行回数の上限値ＭＡＸと比較する（Ｓ２１０）。もし比較の結果ＭＡＸよりもカウンタＲｅｔｒｙＣｏｕｍｔの方が小さければ、プリンタクラスドライバに対して送信を失敗したパケットの再送信を依頼する（Ｓ２１３）。もし比較の結果、ＭＡＸよりもカウンタＲｅｔｒｙＣｏｕｍｔの方が小さくなければ、ユーザーに対して送信試行回数が所定の上限値を超えた旨を通知して印字を継続するかどうか尋ね（Ｓ２１１）、ユザに選択させてそれを判定する（Ｓ２１１ａ）。
【００４８】
ユーザーの選択が「送信を中止する」でなければ、カウンタＲｅｔｒｙＣｏｕｍｔを０に初期化し（Ｓ２１２）、あらためてプリンタクラスドライバに対して送信を失敗したパケットの再送信を依頼する（Ｓ２１３）。もしユーザーの選択が「送信を中止する」であれば、中止要求フラグをオンにセットし（Ｓ２１４）、カウンタＲｅｔｒｙＣｏｕｍｔを０に初期化して（Ｓ２１５）、ステップＳ２０６に進んで送信中止の処理を行う。
【００４９】
以上の手順で印字データの送信およびデータ送信の中止の通報が行われる。ここで、ステップＳ２０４において要求されるデータパケットの送信はＵＳＢの第１のチャネル、例えばエンドポイント１を介して行われる。一方、ステップＳ２１７において要求されるアボート要求識別子の送信は、第２のチャネル例えばエンドポイント０を介して行われる。
【００５０】
＜プリンタにおける印刷データ受信手順＞
次にプリンタの動作の詳細を図６を用いて説明する。図６は、ホストコンピュータからＵＳＢプリンタクラスドライバを介して受信したデータを解析するデータ解析プロセスの手順である。ただし、本発明は印字データ送信のキャンセル処理の送信側と受信側の同期の実現をその焦点としているために、印字コマンドの解析等の詳細については省略した。
【００５１】
図６において、電源がオンになって（Ｓ３０１）、装置の初期化が行われる（Ｓ３０２）。そして印字データの受信が準備完了になるのを待つ（Ｓ３０３）。電源オンの状態で待機するプリンタの定常的な処理はステップＳ３０３から開始される。
【００５２】
準備が完了したなら、まずプリンタに実装されたＵＳＢクラスドライバに対して、ＵＳＢクラスが定めるベンダ固有コマンドを利用したアボート要求識別子９０１を受信しているかどうか確認する（Ｓ３０４）。
【００５３】
もしアボート要求識別子９０１を受信していれば、全てのデータの受信を終了していなくとも、既にそのデータに基づくサービスを起動していればそのサービスを中止する（Ｓ３１１）。例えば、印刷データを受信し、その印刷データに基づいてビットマップデータを展開するといったサービスがこれに該当する。そして、受信したデータを全て破棄する（Ｓ３１２）。そしてサービスのリソースを初期化する（Ｓ３１３）。そしてＵＳＢクラスが定めるベンダ固有コマンドを利用したアボート完了報告識別子１００１をホストコンピュータに送信するようにドライバに要求する（Ｓ３１４）。そしてステップＳ３０４から処理を続ける。
【００５４】
なお、アボート完了報告識別子１００１は、エンドポイント０を介してホストコンピュータに送信される。
【００５５】
もしアボート要求識別子９０１を受信していなければ、ドライバ経由でホストコンピュータからデータパケットを受信するのを待つ（Ｓ３０５）。そしてデータパケットを受信したならば、その受信したデータを解析する（Ｓ３０６）。そしてその解析結果にもとづき、対応した処理をする（Ｓ３０７）。例えば、受信したデータがプリンタのイメージデータであれば、そのイメージをプリンタ内部のメモリに展開する。そして受信データの内容から全データを受信したかどうか判断する（Ｓ３０８）。もし全データの受信が終了していなければステップＳ３０４を行う。もし全データの受信が完了していれば、全受信データが要求するサービスを受信データに基づいて実行する（Ｓ３０９）。例えばサービスが印字であれば印字サービスを完了し、印字した紙を排出する。そして受信データを破棄する（Ｓ３１０）。そしてステップＳ３０２から行う。
【００５６】
以上の手順で印字データの送信およびデータ送信の中止の通報が行われる。ここで、ステップ受信されるデータパケットはＵＳＢの第１のチャネル、例えばエンドポイント１を介して送信されている。一方、中止要求識別子は第２のチャネル例えばエンドポイント０を介して送信されている。このため、特定のチャネルを介して送信されるコマンドの内容をチェックすることで、中止要求を送信側から受信側に確実に通報することができる。
【００５７】
なお本実施の形態では、デフォルトで使用されているエンドポイント０を介して中止要求識別子を送信するので、新たにチャネルをオープンする必要がない。
【００５８】
また、ＵＳＢクラスが定めるベンダユニークコマンドを用いることで、大きな設計的変更をすることなく、既存の技術を利用して、中止要求の送信を実現することが可能となる。
【００５９】
このようにしてホストコンピュータとプリンタとの間で通信することで、ＵＳＢクラス及びＵＳＢプリンタクラスに即した手順により、受信側の負担を増大させることなく割り込み印刷処理を実現することができる。
【００６０】
この結果、コンピュータが印字データをプリンタに送信中に中止要求が発生したとき、プリンタはホストコンピュータからの中止要求を確実に、かつ、すべてのデータパケットを検査することなく知るができる。
【００６１】
［第２実施形態］
第１実施形態では、ある印刷のための印字データの転送がホストコンピュータによって中止されたことをＵＳＢクラスが定めるベンダ固有（ＶｅｂｄｏｒＵｎｉｑｕｅ）コマンドのＩＮタイプとＯＵＴタイプの組み合わせでホストコンピュータとプリンタとの同期をとって伝達したが、ＯＵＴタイプのみで同期をとって伝達する方法も考えられる。ＩＮタイプとＯＵＴタイプはコマンドのタイプであり、例えば図９のアボート要求識別子９０１はＩＮタイプであり、図１０のアボート完了報告要求識別子１００１はＯＵＴタイプである。このタイプは、コマンド中の”ｂｍＲｅｑｕｅｓｔＴｙｐｅ”フィールドの値で示され、０ｘ８１ならＩＮタイプのベンダ固有コマンド、０ｘＣ１ならＯＵＴタイプのベンダ固有コマンドとなる。ＯＵＴタイプはデータを書き出し、ＩＮタイプはデータの書き込みを待つコマンドである。
【００６２】
具体的にはホストコンピュータ側では、図５ＡのＳ２１６からＳ２１８の代わりに、図７Ａで表されるＳ５０１からＳ５０２のような手順を行う。すなわち、プリンタクラスドライバにアボート要求識別子の送信を依頼するのではなく、プリンタクラスドライバにアボート要求識別子を付加したアボート受信要求を依頼する。
【００６３】
それに対応してプリンタ側でも、図６のＳ３０４の代わりに図８のＳ６０１の手順を実行する。すなわち、アボート要求識別子の受信をテストするのではなく、アボート要求識別子が付加された送信要求の受信をテストする。この時、図７Ａのステップ５０１及びステップＳ５０２で作成されるコマンドは図１１で表されるコマンド１１０１である。この場合には、ひとつのコマンドで送信中止要求の送信とその要求に対する送信中止完了報告１１０２の受信ができる。
【００６４】
このようにすることで、ホストコンピュータ側とプリンタ側それぞれのデータ送信中止及びデータ破棄に関する同期が１つのコマンドで可能なため、回線効率が第１の実施形態と比較して良いという利点がある。
【００６５】
［第３実施形態］
第１実施形態、第２実施形態では、ＵＳＢプリンタクラスが定めるベンダ固有コマンドを使用してホストコンピュータ側によるデータ転送の中止を伝達したが、これをＵＳＢプリンタクラスが定めるソフトリセット（ＳｏｆｔＲｅｓｅｔ）を使用しておこなうことも可能である。
【００６６】
【発明の効果】
以上説明したように、ホストコンピュータ側がデータの送信を送信途中で中止したとき、プリンタはデータの内容を検討する必要がない。プリンタは、ホストコンピュータからのアボート通知により、データの破棄が指示されたデータの内容をデコードすることなく中止処理を行うことが可能になる。そのため、送信が中止された受信データと、それに引き続き送信されたデータとの区別がデータの内容だけでは判断できないケースでも、プリンタはそれらのデータを区別することが可能になる。またプリンタはデータの送信が途中で中止されたとき、データの内容の解析をすることがなく、破棄手順の実行ができるため、処理が効率的である。
【００６７】
さらに、受信側ではエンドポイント１を介して受信するデータの内容を検査しなくとも、エンドポイント０を介して受信するデータの内容を判定するだけで送信の中止を確実に知ることができる。
【００６８】
さらに、受信側では中止したデータを確実に破棄できる。
【００６９】
さらに、受信側ではエンドポイント１を介して受信するデータの内容を検査しなくとも、エンドポイント０を介して受信するデータの内容を判定するだけで送信の中止を確実に知ることができ、中止したデータを確実に破棄できる。
【００７０】
さらに、受信側ではＵＳＢプリンタクラスのソフトウエアリセットによって送信の中止を確実に知ることができる。
【図面の簡単な説明】
【図１】実施形態に適用されるホストコンピュータ側の内部ブロック構成図である。
【図２】実施形態に適用されるプリンタ側の内部ブロック構成図である。
【図３】実施形態に適用されるホストコンピュータとプリンタの接続形態の一例を示す図である。
【図４】実施形態に適用されるホストコンピュータ側の動作を示すアプリケーションのフローチャートである。
【図５Ａ】第１実施形態に適用されるホストコンピュータ側の動作のフローチャートである。
【図５Ｂ】第１実施形態に適用されるホストコンピュータ側の動作のフローチャートである。
【図６】第１実施形態に適用されるプリンタ側の動作のフローチャートである。
【図７Ａ】第２実施形態に適用されるホストコンピュータ側の動作のフローチャートである。
【図７Ｂ】第２実施形態に適用されるホストコンピュータ側の動作のフローチャートである。
【図８】第２実施形態に適用されるプリンタ側の動作のフローチャートである。
【図９】第１実施形態のベンダ固有コマンドのアボート要求識別子のフォーマットの一例を示す図である
【図１０】第１、第２実施形態のベンダ固有コマンドのアボート完了報告識別子受信要求のフォーマットの一例を示す図、及び第１、第２実施形態のベンダ固有コマンドのアボート完了報告識別子のフォーマットの一例を示す図である。
【図１１】第２実施形態のベンダ固有コマンドのアボート完了報告識別子受信要求フォーマットの一例を示す図、及び第２実施形態のベンダ固有コマンドのアボート完了報告識別子のフォーマットの一例を示す図である。
【図１】
2004007426.tif 000003
【図２】
2004007426.tif 000004
【図３】
2004007426.tif 000005
【図４】
2004007426.tif 000006
【図５Ａ】
2004007426.tif 000007
【図５Ｂ】
2004007426.tif 000008
【図６】
2004007426.tif 000009
【図７Ａ】
2004007426.tif 000010
【図７Ｂ】
2004007426.tif 000011
【図８】
2004007426.tif 000012
【図９】
2004007426.tif 000013
【図１０】
2004007426.tif 000014
【図１１】
2004007426.tif 000015