JP2017194758A - 印刷制御装置および印刷制御プログラム - Google Patents

Abstract

【課題】送信コマンドと応答データとの不対応が生じることを抑制する。【解決手段】プリンターと通信する通信部と、プリンターを送信対象とする送信コマンドの送信要求を行う通信制御部と、記憶部と、送信要求に応じて送信コマンドを通信部を介してプリンターに送信する送信制御部と、送信コマンドに対応した応答データを通信部を介してプリンターから取得し、取得した応答データに識別情報を付加し、識別情報を付加した応答データを記憶部に格納する受信制御部と、を有し、通信制御部は、第１の送信コマンドの送信要求を行う前に記憶部から取得した応答データに付加されている識別情報と、第１の送信コマンドの送信要求を行った後に記憶部から取得した応答データに付加されている識別情報との比較に基づいて、第１の送信コマンドの送信要求を行った後に記憶部から取得した応答データが第１の送信コマンドに対応するか否かを判定する印刷制御装置。【選択図】図４

Description

本発明は、プリンターを制御する印刷制御装置および印刷制御プログラムに関する。

Ｗｉｎｄｏｗｓ（登録商標）環境下で動作する端末では、プリンター等のデバイスとの間で双方向通信を実行するための双方向通信機能（ＢｉＤｉ）を備えている。双方向通信機能を用いることで、端末は、アプリケーションからの要求のプリンターへの送信と、この要求に応じたプリンターからの応答データの取得とを、通信部を介して実現することができる。

Ｗｉｎｄｏｗｓ８以降の環境下で動作するＶｅｒｓｉｏｎ４プリンタードライバー（以下、Ｖ４プリンタードライバーとも記載する。）では、双方向通信機能はデバイス制御のための拡張機能として定義されている。この拡張機能では、アプリケーションからプリンターへコマンドを送信する処理と、プリンターからの応答データを取得する処理とは、Ｊａｖａｓｃｒｉｐｔ（登録商標）で作成された別々のインターフェイス（ＩＦ）により実現されている。例えば、アプリケーションで発行したコマンドをプリンターに送信するためには、拡張機能のsetメソッドを用いて一連の処理が行われる。一方、プリンターからの応答データの取得は、拡張機能のgetメソッドを用いて一連の処理が行われる。

また、ＸＰＳ（XML Paper Specification）仕様で記述されたＸＰＳファイルを処理するＸＰＳプリンタードライバーが開示されている（特許文献１参照）。

特開２０１３‐２５７８２０号公報

Ｖ４プリンタードライバーにおける双方向通信機能では、setメソッドによる処理とgetメソッドによる処理との間で同期が取られていない（それぞれの処理が独立して行われる）ため、setメソッドで送信したコマンドと、getメソッドで取得したデータとが対応していない場合があった。

本発明は、上述の課題に鑑みたもので、送信コマンドと応答データとの不対応が生じることを抑制できる印刷制御装置および印刷制御プログラムを提供する。

本発明の態様の１つは、印刷制御装置は、プリンターと通信する通信部と、前記プリンターを送信対象とする送信コマンドの送信要求を行う通信制御部と、記憶部と、前記送信要求に応じて、前記送信コマンドを前記通信部を介して前記プリンターに送信する送信制御部と、前記送信コマンドに対応した応答データを前記通信部を介して前記プリンターから取得し、取得した前記応答データに識別情報を付加し、当該識別情報を付加した前記応答データを前記記憶部に格納する受信制御部と、を有し、前記通信制御部は、第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報との比較に基づいて、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応するか否かを判定する。
当該構成によれば、印刷制御装置は、前記比較に基づいて送信コマンド（第１の送信コマンド）に対応する応答データを確実に取得することができる。

本発明の態様の１つは、前記受信制御部は、前記プリンターから取得した前記応答データを、当該応答データが対応する送信コマンドの種別に応じた前記記憶部の領域に格納し、前記通信制御部は、前記第１の送信コマンドの種別に対応する前記記憶部の領域から前記応答データを取得するとしてもよい。
当該構成によれば、通信制御部は、第１の送信コマンドと種別が異なる送信コマンドに対応した応答データを、第１の送信コマンドに対応する可能性のある応答データとして記憶部から取得することを、回避できる。

本発明の態様の１つは、前記通信制御部は、前記第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報とが相違する場合に、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応する応答データであると判定する。一方、前記比較の対象とした２つの識別情報が同じである場合には、前記通信制御部は、前記受信制御部に前記プリンターからの応答データの取得を再度要求する。
このような構成によれば、第１の送信コマンドに対応する応答データを最終的には取得することができる。また、前記通信制御部は、前記第１の送信コマンドの送信要求を行う前に前記記憶部から空データを取得した場合には、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応する応答データであると判定すればよい。

前記通信部は、ＵＳＢ（Universal Serial Bus）規格に対応するインターフェイスである。また、印刷制御装置は、前記通信制御部からの要求に応じて拡張機能を呼び出すスプーラーを有し、前記送信制御部と前記受信制御部とは前記スプーラーにより読み出されて実行されるとしてもよい。

本発明の技術的思想は、印刷制御装置以外によっても実現される。例えば、印刷制御装置が搭載するコンピューターに本発明にかかる処理を実行させるプログラム（印刷制御プログラム）や、印刷制御装置が実行する工程を含んだ方法（印刷制御方法）や、当該プログラムを記憶したコンピューター読取可能な記憶媒体等を、それぞれ発明として捉えることができる。また、印刷制御装置（印刷制御プログラム、印刷制御方法）は、プリンターとの通信を制御すると言えるため、これを通信制御装置（通信制御プログラム、通信制御方法）等と称してもよい。

印刷制御装置の構成を例示するブロック図。 ＣＰＵにより実現されるソフトウェアの機能を例示する図。 ＣＰＵにより実現される機能のうち双方向通信に係る機能を模式的に示す図。 通信処理を説明するためのシーケンス図。 受信制御部がステップＳ５，Ｓ１３で実行する処理を示すフローチャート。 応答データ格納領域を説明するための図。 格納領域規定テーブルを例示する図。 上位通信モジュールがステップＳ１６で実行する処理を示すフローチャート。

下記の順序に従って本発明の実施形態を説明する。
１．印刷制御装置の構成：
２.ソフトウェアの機能構成：
３.通信処理：
４．まとめ：

１．印刷制御装置の構成：
図１は、印刷制御装置の構成を例示するブロック図である。以下では、印刷制御装置の一例として、端末１０を例に説明を行う。端末１０は、プリンタードライバーを搭載してプリンターを制御できるものであればよく、パーソナルコンピューター（ＰＣ）や、タブレット型端末や、スマートフォンや、これらと同等の性能を有する各種装置である。また、端末１０が有する構成の一部を印刷制御装置や通信制御装置と称してもよい。端末１０は、ディスプレイ１１、操作キー１２、ビデオカード１３、Ｉ・ＯＩＦ１４、バス１５、ＣＰＵ１６、外部記憶装置１７、ＲＡＭ１８、ＲＯＭ１９、ＵＳＢＩＦ２０、を備えている。

ディスプレイ１１は、画像を表示する表示部１１１や、利用者からの操作を受け付けるタッチパネルモジュール１１２を備えている。表示部１１１は、例えば、ＬＣＤ（Liquid Crystal Display）や、ＬＣＤを駆動するためのドライバー回路を備え、ビデオカード１３に接続されている。ビデオカード１３は、バス１５とディスプレイ１１とを接続している。また、タッチパネルモジュール１１２は、静電容量方式や抵抗膜方式のセンサーを備え、利用者の操作位置に応じた電圧値を、Ｉ・ＯＩＦ１４に出力する。

操作キー１２は、押し込み式のボタンにより構成され、利用者の操作を受け付けるユーザーインターフェイスである。
Ｉ・ＯＩＦ１４は、利用者によるタッチパネルモジュール１１２または操作キー１２の操作に応じて生成される信号をバス１５に出力する。
バス１５には、ＣＰＵ１６、外部記憶装置１７、Ｉ・ＯＩＦ１４、ＲＡＭ１８、ＲＯＭ１９、ビデオカード１３、ＵＳＢＩＦ２０が接続されている。バス１５は、不図示のチップセットを備え、ＣＰＵ１６と他のデバイスとの通信を制御する。

ＣＰＵ１６は、外部記憶装置１７またはＲＯＭ１９に記憶されたプログラムをＲＡＭ１８に展開して実行することで、端末１０を統合的に制御する。ＲＯＭ１９には、ＣＰＵ１６が起動する際に実行されるＢＩＯＳプログラムが記憶されている。ＲＡＭ１８は、ＣＰＵ１６により処理されるプログラムやデータを展開するワークエリアとして機能する。

外部記憶装置１７には、ＯＳ（Operating System）としての機能をＣＰＵ１６に付与するＯＳプログラム１７ａ、アプリケーションの機能をＣＰＵ１６に付与するアプリケーションプログラム１７ｂ、ＯＳと協働してプリンター２００を制御するプリンタードライバープログラム（ＰＤＲＶプログラム）１７ｃが記憶されている。ＯＳプログラム１７ａは、例えば、Ｗｉｎｄｏｗｓ１０（Ｗｉｎｄｏｗｓは登録商標）である。アプリケーションプログラム１７ｂは、描画ソフト、ＰＤＦファイルビューア、ブラウザー、Ｗｅｂアプリケーションといったアプリケーションの機能をＣＰＵ１６に実現させる。ＰＤＲＶプログラム１７ｃは、Ｖ４プリンタードライバーであり、拡張機能を備えている。

ＵＳＢＩＦ２０は、ＵＳＢコントローラーや、ＵＳＢケーブルを備え、バス１５とプリンター２００とを接続している。この実施形態では、通信部は、ＵＳＢＩＦ２０により実現されている。
プリンター２００は、インクジェットプリンターやレーザープリンターである。プリンター２００は、プリンター以外の機能、例えば、スキャナーやファクシミリ等の機能も併せ持つ複合機であってもよい。プリンター２００は、外部記憶装置１７に記憶されたＰＤＲＶプログラム１７ｃに対応しており、端末１０からＵＳＢＩＦ２０を通じて送信される印刷用データや送信コマンドによりその駆動が制御される。なお、プリンター２００の内部構成は周知でありその説明は省略する。

２.ソフトウェアの機能構成：
図２は、ＣＰＵ１６により実現されるソフトウェアの機能を例示する図である。図２では、外部記憶装置１７に記憶された各プログラムによりＣＰＵ１６に実現される機能をアプリケーション１６０、ＯＳ１７０、プリンタードライバー１８０として示している。

アプリケーション１６０は、画像や文章を含む印刷用データを生成する。印刷用データはＸＰＳ（XML Paper Specification）のフォーマットに対応するものを想定しているが、これ以外のフォーマットに対応するものであってもよい。また、アプリケーション１６０は、プリンター２００に対して、インク残量等の状態を示すステータス情報を要求するコマンドや、クリーニング等のメンテナンス処理を実行させるコマンドを発行する機能を備えている。以下では、アプリケーション１６０が発行するコマンドを送信コマンドＳＣと記載する。

ＯＳ１７０は、スプーラー１７１、ＵＳＢポートモニター１７２を備え、プリンタードライバー１８０と協働してプリンター２００を制御する。スプーラー１７１は、印刷処理時のデータ（スプールデータ）の出力処理や、双方向通信時のデータの送受信を制御する。ＵＳＢポートモニター１７２は、アプリケーション１６０やプリンタードライバー１８０が通信を行う際に使用するポート番号の管理や、印刷処理時や双方向通信時におけるこのポート番号を用いた実質的な通信を行う。

プリンタードライバー１８０は、上位通信モジュール１８１、グラフィックスモジュール１８２、拡張機能部１８３を備えている。プリンタードライバー１８０は、印刷制御プログラムの一例である。上位通信モジュール１８１（通信制御部）は、アプリケーション１６０からの印刷用データの受信や、アプリケーション１６０との間で行われる制御用データ（送信コマンドＳＣ、応答データＲＤ）の受け渡しを実行する。グラフィックスモジュール１８２は、印刷処理時に、アプリケーション１６０が生成した印刷用データをプリンター２００が対応するフォーマットに変換する。拡張機能部１８３は、印刷処理時や双方向通信時に行われる機能を拡張するためのモジュールにより構成されている。

拡張機能部１８３は、その機能ごとに複数の機能モジュールを備えている。各機能モジュールは、Ｊａｖａｓｃｒｉｐｔにより構成されたスクリプトファイルや、ＸＭＬ（eXtensible Markup Language）ファイルにより構成されている。ＸＭＬファイルは、各機能を定義するスキーマとして機能し、スクリプトファイルは、このＸＭＬファイルに基づいて動作することで、プリンタードライバー１８０に拡張された機能を提供する。各機能モジュールは、スプーラー１７１から呼び出されることで、実施される。

図３は、ＣＰＵ１６により実現される各機能のうち、ＵＳＢＩＦ２０を用いた双方向通信に係る機能を模式的に示した図である。双方向通信は、スプーラー１７１が、拡張機能部１８３が備える機能モジュールのうち、USB Bidi Extender１８４を呼び出すことで実行される。USB Bidi Extender１８４のうち、スクリプトファイル内に実装されているメソッド（関数）であるsetSchema()は、上位通信モジュール１８１がアプリケーション１６０から取得した送信コマンドＳＣを、ＵＳＢポートモニター１７２からＵＳＢＩＦ２０によりプリンター２００に送信する機能を実現する。スクリプトファイル内に実装されているメソッド（関数）であるgetSchemas()は、プリンター２００が送信コマンドＳＣに対応して生成する応答データＲＤをＵＳＢＩＦ２０を通じて取得する機能を実現する。getSchemas()で取得される応答データＲＤは、ＸＭＬファイル内の要素で定義されたＲＡＭ１８の該当領域（後述する応答データ格納領域）に記憶される。該当領域に記憶された応答データＲＤは、上位通信モジュール１８１により取得され、アプリケーション１６０に返信される。
以下では、端末１０（ＣＰＵ１６）がsetSchema()を用いることで実現される機能部を送信制御部１８５と、getSchemas()を用いることで実現される機能部を受信制御部１８６とも記載する。

３.通信処理：
次に、双方向通信機能を用いた端末１０とプリンター２００との通信処理を説明する。
図４は、当該通信処理を説明するためのシーケンス図である。図４は、アプリケーション１６０、上位通信モジュール１８１、スプーラー１７１、送信制御部１８５、受信制御部１８６、プリンター２００による処理をそれぞれ示している。

ステップＳ１では、アプリケーション１６０は、プリンター２００に応答データＲＤ（例えば、ステータス情報を記述した応答データ）を要求するための送信コマンドＳＣを発行する。ステータス情報は、例えば、アプリケーション１６０がプリンター２００の状態を示すユーザーインターフェイス（ＵＩ）画面を表示させる情報である。

ステップＳ２では、上位通信モジュール１８１は、アプリケーション１６０から取得した、ステップＳ１で発行された送信コマンドＳＣの種別を記憶する。送信コマンドＳＣの種別は、例えば、ステータス情報の要求や、メンテナンス処理の実行命令といったように、アプリケーション１６０が要求する処理の内容に応じて定められている。ステップＳ１で発行された送信コマンドＳＣは、第１の送信コマンドに該当する。本発明において、第１の送信コマンドとは、その内容や種別が限定される訳ではない。便宜上“第１の〜”と表現することで、端末１０が現在実行中の通信処理（図４）の発端としてアプリケーション１６０が発行した送信コマンドＳＣ（第１の送信コマンド）を、端末１０が過去に実行した通信処理（図４）の発端としてアプリケーション１６０が発行した送信コマンドＳＣと区別しているに過ぎない。

ステップＳ３では、上位通信モジュール１８１は、スプーラー１７１に対してgetSchemas()を呼び出すための関数をコールする。つまり、上位通信モジュール１８１は、スプーラー１７１に対する、USB Bidi Extender１８４のgetSchemas()の呼び出し要求を行う。また、このような要求を、応答データＲＤの取得要求とも言う。

ステップＳ４では、スプーラー１７１は、上位通信モジュール１８１がコールする関数に応じて、USB Bidi Extender１８４のgetSchemas()を呼び出す。getSchemas()の呼び出しにより、ＣＰＵ１６は受信制御部１８６として機能することとなる。

ステップＳ５では、受信制御部１８６は、応答データＲＤをプリンター２００から取得するための処理を行う。
図５は、受信制御部１８６がステップＳ５で実行する処理を示すフローチャートである。なお、受信制御部１８６は、後述するステップＳ１３でも当該図５に示すフローチャートを実行する。ステップＳ５１では、受信制御部１８６は、プリンター２００が送信する（ステップＳ６）応答データＲＤを、ＵＳＢＩＦ２０を介して取得する。

ステップＳ５２では、受信制御部１８６は、ステップＳ５１においてプリンター２００からの応答データＲＤの取得に成功したか否かを判定する。応答データＲＤを取得、つまりプリンター２００から応答データＲＤを受信できた場合（ステップＳ５２：Ｙｅｓ）はステップＳ５３へ進む。ステップＳ５３では、受信制御部１８６は、受信した応答データＲＤを識別情報ＩＤとともに、記憶部（例えばＲＡＭ１８）の対応する記憶領域（応答データ格納領域）に格納する。受信制御部１８６により応答データＲＤが格納される応答データ格納領域のアドレスは、拡張機能部１８３のＸＭＬファイルに定義されている。

一方、プリンター２００からの応答データＲＤの取得に成功しなかった場合（ステップＳ５２：Ｎｏ）、受信制御部１８６は、ステップＳ５３を実行することなく、図５に示すフローチャートを終了する。プリンター２００は、端末１０から送信された送信コマンドＳＣへの応答として、応答データＲＤを生成して返す。ステップＳ１で送信コマンドＳＣが発行されて以降、ステップＳ５の段階では、この送信コマンドＳＣは未だプリンター２００に送信されていない。従って、ステップＳ５の段階では、実際にはプリンター２００から応答データＲＤは送信されず（ステップＳ６は発生せず）、ステップＳ５２において“Ｎｏ”の判定をすることになる。

ここで、ステップＳ５３の詳細を説明しておく。
図６は、応答データ格納領域の位置を説明するための図である。拡張機能部１８３のＸＭＬファイルにより、応答データＲＤが対応する送信コマンドＳＣの種別に応じて応答データ格納領域が指定されている。図６の例では、送信コマンドＳＣの種別、例えば、第１種別の送信コマンドＳＣ１、第２種別の送信コマンドＳＣ２、第３種別の送信コマンドＳＣ３…毎に、ＲＡＭ１８の記憶領域内に応答データ格納領域１８ａ，１８ｂ，１８ｃ…といった各領域が確保されている。ステップＳ５３では、受信制御部１８６は、拡張機能部１８３のＸＭＬファイルを参照することにより、前記ステップＳ５１で受信した応答データＲＤを、その応答データＲＤが対応する送信コマンドＳＣの種別に応じた応答データ格納領域に格納する。なお、受信制御部１８６等は、応答データＲＤが対応する送信コマンドＳＣの種別については、例えば、応答データＲＤの内容と送信コマンドＳＣの種別との対応付けを予めしている拡張機能部１８３のＸＭＬファイルを参照することにより、判別することができる。

ステップＳ５３では、受信制御部１８６は、応答データＲＤに上述したように識別情報ＩＤを付加し、識別情報ＩＤを付加した応答データＲＤを応答データ格納領域に格納する。識別情報ＩＤを応答データＲＤに付加するとは、識別情報ＩＤと応答データＲＤとを一対一で対応付けるという意味である。受信制御部１８６は、ステップＳ５３を実行する度に異なる識別情報ＩＤを生成し、そのとき応答データ格納領域へ格納する応答データＲＤに付加する。受信制御部１８６は、例えば、ステップＳ５３の度に乱数を発生させることによりユニークな識別情報ＩＤを生成することができる。あるいは、受信制御部１８６は、予め定められた規則に従ってユニークな識別情報ＩＤを生成してもよい。ステップＳ５３では、受信制御部１８６は、識別情報ＩＤを付加した応答データＲＤを、対応する応答データ格納領域に格納する際、それまで当該応答データ格納領域に記憶されていた情報（応答データＲＤおよび識別情報ＩＤ）に上書きする。

ステップＳ７（図４）では、上位通信モジュール１８１は、応答データＲＤおよび応答データＲＤに付加されている識別情報ＩＤを取得する。つまり、上位通信モジュール１８１は、応答データＲＤおよび識別情報ＩＤが格納されている参照先の応答データ格納領域を、ステップＳ２で記憶した送信コマンドＳＣの種別に従って特定し、当該特定した応答データ格納領域から応答データＲＤおよび識別情報ＩＤを取得する。このような参照先の応答データ格納領域の特定は、例えば、拡張機能部１８３に記憶されている格納領域規定テーブルＲＴを用いて行われる。

図７は、ステップＳ７（および後述のステップＳ１５）で用いる格納領域規定テーブルＲＴを例示している。格納領域規定テーブルＲＴには、送信コマンドＳＣの種別（例えば、第１種別の送信コマンドＳＣ１、第２種別の送信コマンドＳＣ２、第３種別の送信コマンドＳＣ３…）毎に、参照先の応答データ格納領域を特定可能な格納領域特定情報が記憶されている。格納領域特定情報としては、例えば、参照先の応答データ格納領域をＸＭＬファイルで定義したスキーマ名称（スキーマ名称１，２，３…）や、この応答データ格納領域をＸＭＬファイルで間接的に示す定義名称を用いることができる。これ以外にも、応答データ格納領域の先頭アドレス等を用いるものであってもよい。上位通信モジュール１８１はステップＳ２で記憶した送信コマンドＳＣの種別をもとに、格納領域規定テーブルＲＴから応答データ格納領域の格納領域特定情報を取得し、格納領域特定情報に対応する応答データ格納領域から応答データＲＤおよび識別情報ＩＤを取得する。むろん、ステップＳ５３（図５）において、受信制御部１８６は、応答データＲＤおよび識別情報ＩＤを応答データ格納領域へ格納する際に、格納領域規定テーブルＲＴを参照して格納先の応答データ格納領域を特定することができる。

このようにステップＳ７で上位通信モジュール１８１が取得した識別情報ＩＤは、第１の送信コマンドの送信要求を行う前に記憶部（ＲＡＭ１８）から取得した応答データに付加されている識別情報、に該当する。また、ステップＳ７で上位通信モジュール１８１が取得した識別情報ＩＤは、端末１０が現在実行中の通信処理（図４）よりも過去に、受信制御部１８６がプリンター２００から取得した応答データＲＤに付加して記憶部（ＲＡＭ１８）内の応答データ格納領域に応答データＲＤとともに格納した識別情報である。

次に、ステップＳ８では、上位通信モジュール１８１は、スプーラー１７１に対してsetSchema()を呼び出すための関数をコールするとともに、アプリケーション１６０から取得した（ステップＳ１で発行された）送信コマンドＳＣを送信する。つまり、上位通信モジュール１８１は、スプーラー１７１に対する、USB Bidi Extender１８４のsetSchema()の呼び出し要求を行う。このような要求は、送信コマンドＳＣの送信要求に該当する。

ステップＳ９では、スプーラー１７１は、上位通信モジュール１８１がコールする関数により、USB Bidi Extender１８４のsetSchema()を呼び出し、送信コマンドＳＣをsetSchema()の引数として設定する。setSchema()の呼び出しにより、ＣＰＵ１６は送信制御部１８５として機能することになる。

ステップＳ１０では、送信制御部１８５は、ＵＳＢポートモニター１７２を制御し、送信コマンドＳＣをプリンター２００に送信する。ＵＳＢポートモニター１７２の機能により送信コマンドＳＣはＵＳＢＩＦ２０を介してプリンター２００に送信される。プリンター２００はＵＳＢＩＦ２０を介して送信コマンドＳＣを受信すると、送信コマンドＳＣを解釈し、送信コマンドＳＣに対応する応答データＲＤを生成する。

ステップＳ８の後に、上位通信モジュール１８１は、ステップＳ１１を実行する。また、ステップＳ１１を起因として、ステップＳ１２，Ｓ１３が実行される。ステップＳ１１，Ｓ１２，Ｓ１３は、上述のステップＳ３，Ｓ４，Ｓ５と同じ処理である。
上述したように、受信制御部１８６は、ステップＳ１３においても図５のフローチャートを実行する。ステップＳ１３の段階では、上位通信モジュール１８１は、ステップＳ１で発行された送信コマンドＳＣについての送信要求（ステップＳ８）を実行済みである。従って、ステップＳ１３で実行する図５のフローチャートにおいては、ステップＳ５１で、プリンター２００が送信する（ステップＳ１４）応答データＲＤを、ＵＳＢＩＦ２０を介して取得できる可能性が高い。

次に、ステップＳ１５では、上位通信モジュール１８１は、応答データＲＤおよび応答データＲＤに付加されている識別情報ＩＤを取得する。ステップＳ１５は、ステップＳ７と同じ処理である。ステップＳ１５で応答データＲＤおよび識別情報ＩＤを取得するための参照先の応答データ格納領域は、ステップＳ７で応答データＲＤおよび識別情報ＩＤを取得するために参照した応答データ格納領域と同じである。ただし、ステップＳ１５で応答データＲＤおよび識別情報ＩＤを取得するための参照先の応答データ格納領域は、前記ステップＳ１３により、格納する応答データＲＤおよび識別情報ＩＤが更新（上書き）されている可能性が高い。ステップＳ１５で上位通信モジュール１８１が取得した識別情報ＩＤは、第１の送信コマンドの送信要求を行った後に記憶部（ＲＡＭ１８）から取得した応答データに付加されている識別情報、に該当する。また、ステップＳ１５で上位通信モジュール１８１が取得した応答データＲＤは、第１の送信コマンドの送信要求を行った後に記憶部（ＲＡＭ１８）から取得した応答データ、に該当する。

ステップＳ１６では、上位通信モジュール１８１は、応答データＲＤをアプリケーション１６０へ送信するための処理を行う。
図８は、ステップＳ１６において上位通信モジュール１８１が実行する処理を示すフローチャートである。上位通信モジュール１８１は、ステップＳ７で取得した識別情報ＩＤ（以下、事前取得の識別情報ＩＤ）と、ステップＳ１５で取得した識別情報ＩＤ（以下、直近取得の識別情報ＩＤ）とを比較し、当該比較に基づいて、ステップＳ１５で取得した応答データＲＤが、ステップＳ１で発行された送信コマンドＳＣに対応する応答データＲＤであるか否かを判定する。具体的には、ステップＳ１６１において、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが相違するか否か判定し、判定結果に応じて処理を分岐する。

上位通信モジュール１８１は、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが相違する場合は（ステップＳ１６１：Ｙｅｓ）、ステップＳ１５で取得した応答データＲＤが、ステップＳ１で発行された送信コマンドＳＣに対応すると判定し、ステップＳ１６２へ進む。つまり、直近取得の識別情報ＩＤが事前取得の識別情報ＩＤから変化していれば、送信コマンドＳＣの送信（ステップＳ８〜Ｓ１０）後の応答データＲＤの取得要求（Ｓ１１）を契機としたステップＳ１３（ステップＳ１３で実行する図５のフローチャートにおけるステップＳ５３）で、当該送信コマンドＳＣの種別に対応する応答データＲＤが更新されたことになるため、ステップＳ１で発行された送信コマンドＳＣに対応する応答データＲＤをステップＳ１５で取得できたと判定することができる。

ステップＳ１６２では、上位通信モジュール１８１は、ステップＳ１５で取得した応答データＲＤを、アプリケーション１６０へ送信する。この結果、アプリケーション１６０は、ステップＳ１で発行した送信コマンドＳＣに対応してプリンター２００が生成した応答データＲＤを得たことになる。

一方、上位通信モジュール１８１は、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが同じである場合は（ステップＳ１６１：Ｎｏ）、ステップＳ１５で取得した応答データＲＤが、ステップＳ１で発行された送信コマンドＳＣに対応していない（送信コマンドＳＣの送信前から記憶されている応答データＲＤがまだ更新されていない）と判定できるため、ステップＳ１１へ戻る。ステップＳ１１へ戻ることで、上位通信モジュール１８１は、スプーラー１７１（受信制御部１８６）に対して再度、応答データＲＤの取得要求をすることになる。つまり、ステップＳ１１〜Ｓ１６が繰り返される。ステップＳ１１〜Ｓ１６を繰り返すことで、最終的には、アプリケーション１６０がステップＳ１で発行した送信コマンドＳＣに対応する応答データＲＤを、アプリケーション１６０へ返すことができる。

なお、ステップＳ７では、上位通信モジュール１８１は、ステップＳ２で記憶した送信コマンドＳＣの種別に対応する応答データ格納領域から応答データＲＤおよび識別情報ＩＤを取得しようとしたとき、この応答データ格納領域が空である場合は応答データＲＤおよび識別情報ＩＤを取得できない。この場合、上位通信モジュール１８１は、ステップＳ２で記憶した送信コマンドＳＣの種別に対応する応答データ格納領域から、応答データ格納領域が空であることを示す空データ（Null値）を得るだけである。上位通信モジュール１８１は、ステップＳ７で空データを取得した場合は、ステップＳ１６を実行するための便宜上、当該空データを事前取得の識別情報ＩＤとみなす。このようにすれば、ステップＳ１６１（図８）では、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが相違する（ステップＳ１６１：Ｙｅｓ）と判定することができる。つまり、上位通信モジュール１８１は、第１の送信コマンドの送信要求を行う前に記憶部（ＲＡＭ１８）から空データを取得した場合には、第１の送信コマンドの送信要求を行った後に記憶部（ＲＡＭ１８）から取得した応答データが第１の送信コマンドに対応する応答データであると判定する。

ステップＳ１５においても、実行のタイミング如何では、ステップＳ７と同様に、ステップＳ２で記憶した送信コマンドＳＣの種別に対応する応答データ格納領域から応答データＲＤおよび識別情報ＩＤを取得しようとしたとき、この応答データ格納領域から空データを取得することが有り得る。上位通信モジュール１８１は、ステップＳ１５で空データを取得した場合は、ステップＳ１６を実行するための便宜上、当該空データを直近取得の識別情報ＩＤとみなす。この場合、事前取得の識別情報ＩＤ、直近取得の識別情報ＩＤのいずれも空データであるため、ステップＳ１６１（図８）では、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが同じ（ステップＳ１６１：Ｎｏ）と判定することになる。ただし、ステップＳ１６１において“Ｎｏ”と判定した場合は、ステップＳ１１〜Ｓ１６が繰り返されるため、最終的には、アプリケーション１６０がステップＳ１で発行した送信コマンドＳＣに対応する応答データＲＤを、アプリケーション１６０へ返すことができる。

４．まとめ：
このように本実施形態によれば、通信制御部（上位通信モジュール１８１）は、第１の送信コマンド（ステップＳ１で発行された送信コマンドＳＣ）の送信要求を行う前に記憶部（ＲＡＭ１８）から取得した応答データＲＤに付加されている識別情報（事前取得の識別情報ＩＤ）と、第１の送信コマンドの送信要求を行った後に記憶部から取得した応答データＲＤに付加されている識別情報（直近取得の識別情報ＩＤ）との比較に基づいて、第１の送信コマンドの送信要求を行った後に記憶部から取得した応答データＲＤが第１の送信コマンドに対応するか否かを判定する。これにより、第１の送信コマンドに対応していない応答データＲＤを、誤って第１の送信コマンドに対応する応答データＲＤと判定し第１の送信コマンドに対応する応答データＲＤとして処理してしまうことを回避できる。具体的には、例えば、第１の送信コマンドよりも過去にアプリケーション１６０が発行した送信コマンドに対応してプリンター２００が生成し端末１０へ送信した応答データＲＤを、第１の送信コマンドの発行後に当該第１の送信コマンドに対応する応答データＲＤの送信を待っているアプリケーション１６０へ送信してしまう、といったことを回避できる。

また本実施形態によれば、受信制御部１８６は、プリンター２００から取得した応答データＲＤを、当該応答データＲＤが対応する送信コマンドＳＣの種別に応じた記憶部（ＲＡＭ１８）の領域（応答データ格納領域）に格納し、通信制御部（上位通信モジュール１８１）は、第１の送信コマンドの種別に対応する記憶部の領域（応答データ格納領域）から応答データＲＤを取得する。当該構成によれば、上位通信モジュール１８１は、第１の送信コマンドと種別が異なる送信コマンドに対応して記憶部に格納されている応答データＲＤを、第１の送信コマンドに対応する可能性のある応答データＲＤとして記憶部から取得することを回避できる。また、受信制御部１８６は、ある送信コマンドの種別に対応して記憶部に記憶されている応答データＲＤを、他の種別の送信コマンドの送信に応じてプリンター２００から返信された応答データＲＤにより上書きしてしまうことを回避することができる。

また本実施形態は、取得した応答データＲＤが第１の送信コマンドに対応する応答データＲＤであるか否かの判定において、上述したように事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとが相違するか否かという判定基準を用いることで、次のような優位性を有する。

送信コマンドと応答データとの対応・不対応を判定するために、例えば、送信コマンドの送信要求を行ったときの時刻（送信時刻）と、応答データをプリンターから受信したときの時刻（受信時刻）とを管理し、送信時刻よりも受信時刻の方が後であれば、当該受信時刻に受信した応答データが、当該送信時刻にかかる送信コマンドに対応すると判定する構成が考えられる。ここで、サーバーが管理するプリンターを、当該サーバーが接続するネットワーク（例えばＬＡＮ）に参加する複数のクライアント端末が共同使用する構成（印刷制御装置が、クライアント端末とサーバーを含むシステムである場合）を想定する。当該構成では、上述の送信時刻は、送信コマンドを発するクライアント端末が記憶し、上述の受信時刻は、サーバーが記憶することになる。

このような場合、クライアント端末が時間を認識する基準（クライアント端末が内蔵する時計）と、サーバーが時間を認識する基準（サーバーが内蔵する時計）とにずれがあると、上述したような送信時刻と受信時刻との前後関係に基づく判定を正確に行えないことがある。例えば、現実の時系列では送信時刻よりも受信時刻の方が後であるにも関わらず、クライアント端末が認識する送信時刻が、サーバーが認識する受信時刻よりも後であるために、応答データは送信コマンドに対応しないという判定結果になることがある。本実施形態は、送信コマンドと応答データとの対応・不対応を、事前取得の識別情報ＩＤと直近取得の識別情報ＩＤとの相違の有無に基づいて行うため、上述したような各処理の時刻の前後関係に基づく判定をする場合に生じ得る誤判定を、避けることができる。

１０…端末、１１…ディスプレイ、１２…操作キー、１３…ビデオカード、１５…バス、１６…ＣＰＵ、１７…外部記憶装置、１８…ＲＡＭ、１８ａ，１８ｂ，１８ｃ…応答データ格納領域、１９…ＲＯＭ、２０…ＵＳＢＩＦ、１６０…アプリケーション、１７０…ＯＳ、１７１…スプーラー、１７２…ＵＳＢポートモニター、１８０…プリンタードライバー、１８１…上位通信モジュール、１８２…グラフィックスモジュール、１８３…拡張機能部、１８４…USB Bidi Extender、１８５…送信制御部、１８６…受信制御部、２００…プリンター、ＩＤ…識別情報、ＳＣ…送信コマンド、ＲＤ…応答データ

Claims (8)

1. プリンターと通信する通信部と、
   前記プリンターを送信対象とする送信コマンドの送信要求を行う通信制御部と、
   記憶部と、
   前記送信要求に応じて、前記送信コマンドを前記通信部を介して前記プリンターに送信する送信制御部と、
   前記送信コマンドに対応した応答データを前記通信部を介して前記プリンターから取得し、取得した前記応答データに識別情報を付加し、当該識別情報を付加した前記応答データを前記記憶部に格納する受信制御部と、を有し、
   前記通信制御部は、第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報との比較に基づいて、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応するか否かを判定する、ことを特徴とする印刷制御装置。
2. 前記受信制御部は、前記プリンターから取得した前記応答データを、当該応答データが対応する送信コマンドの種別に応じた前記記憶部の領域に格納し、
   前記通信制御部は、前記第１の送信コマンドの種別に対応する前記記憶部の領域から前記応答データを取得することを特徴とする請求項１に記載の印刷制御装置。
3. 前記通信制御部は、前記第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報とが相違する場合に、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応する応答データであると判定することを特徴とする請求項１または請求項２に記載の印刷制御装置。
4. 前記通信制御部は、前記第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報とが同じである場合に、前記受信制御部に前記プリンターからの応答データの取得を再度要求することを特徴とする請求項１〜請求項３のいずれかに記載の印刷制御装置。
5. 前記通信制御部は、前記第１の送信コマンドの送信要求を行う前に前記記憶部から空データを取得した場合には、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応する応答データであると判定することを特徴とする請求項１〜請求項４のいずれかに記載の印刷制御装置。
6. 前記通信部は、ＵＳＢ規格に対応するインターフェイスであることを特徴とする請求項１〜請求項５のいずれかに記載の印刷制御装置。
7. 前記通信制御部からの要求に応じて拡張機能を呼び出すスプーラーを有し、
   前記送信制御部と前記受信制御部とは前記スプーラーにより読み出されて実行されることを特徴とする請求項１〜請求項６のいずれかに記載の印刷制御装置。
8. コンピューターにプリンターを制御させる印刷制御プログラムであって、
   前記コンピューターに、
   前記プリンターを送信対象とする送信コマンドの送信要求を行う通信制御機能と、
   前記送信要求に応じて、前記送信コマンドを通信部を介して前記プリンターに送信する送信制御機能と、
   前記送信コマンドに対応した応答データを前記通信部を介して前記プリンターから取得し、取得した前記応答データに識別情報を付加し、当該識別情報を付加した前記応答データを記憶部に格納する受信制御機能と、実現させ、
   前記通信制御機能は、第１の送信コマンドの送信要求を行う前に前記記憶部から取得した応答データに付加されている識別情報と、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データに付加されている識別情報との比較に基づいて、前記第１の送信コマンドの送信要求を行った後に前記記憶部から取得した応答データが前記第１の送信コマンドに対応するか否かを判定する、ことを特徴とする印刷制御プログラム。

Images