JP2022080404A - Ｕｓｂデバイス、ｕｓｂデバイスの制御方法、及びプログラム - Google Patents

Abstract

【課題】Ｅｎｄｐｏｉｎｔ０で通信が行われるＵＳＢのコントロール転送において、５００ｍｓ以内に応答が要求されるコマンドをタイムアウトさせることなくホストＰＣの要求データを返答できるようにすること。【解決手段】画像処理装置１は、ＵＳＢ処理を司るドライバ層２０１を複数スレッド化し、ＳＥＴコマンド受信時にドライバ層２０１の別スレッド（ドライバ層別スレッド３０１）により予め先行してＧＥＴコマンドで応答するデータを取得しておき（Ｓ３０２～Ｓ３０４）、ＧＥＴコマンド受信時に先行して取得しておいたデータをホストＰＣに応答する（Ｓ３０５、Ｓ３０６、Ｓ２１０）。【選択図】図３

Description

本発明は、画像処理装置等のＵＳＢデバイスとＵＳＢケーブルで接続されたホストＰＣとのＵＳＢ通信に関する技術である。

画像処理装置には、ホストＰＣ（HOST PC）とUniversal Serial Bus（以下「ＵＳＢ」）のケーブルで接続可能なＵＳＢデバイスＩ／Ｆを装備するものがある。ホストＰＣと画像処理装置間では、例えばＵＳＢ２．０の仕様（Universal Serial Bus Specification）に準拠したプロトコルのもとに通信を行っている。

ＵＳＢ通信は、ＥｎｄＰｏｉｎｔと言われるＰｏｒｔごとに通信チャンネルを持っている。ＥｎｄＰｏｉｎｔ０という基本通信Ｐｏｒｔでは、コントロール転送のプロトコルを使った通信が行われる。また、ＥｎｄＰｏｉｎｔ１～ｎのデータ通信Ｐｏｒｔでは、コントロール転送以外のバルク転送、インタラプト転送、アイソクロナス転送などプロトコルで通信が行われる。

コントロール転送の場合、ＵＳＢ２．０の仕様では、ホストＰＣからのデータ要求（以下「ＩＮ要求」）に対して５００ｍｓ以内にデバイス側から返答がない場合、ホストＰＣはＩＮ要求を停止することが可能となる。このため、デバイス側である画像処理装置は、５００ｍｓ以内にコントロール転送のＩＮ要求に対して返答データを用意する必要がある。

特許文献１では、ホストＰＣと画像処理装置の通信において、画像処理装置側がデータ受信するバルク転送用のバッファーの状態を、バルク転送と並行してインタラプト転送を行ってホストＰＣに通知する技術が提案されている。インタラプト転送は定期的にホストＰＣとデバイス間で通信する規定の通信のため、定期的に画像処理装置のバルク転送用のバッファーの状態をホストＰＣに通知することができる。これにより、バルク転送の転送間隔を調整してタイムアウトを抑えることが可能となる。

特開２００２－３１８７７８号公報

特許文献１の技術では、ＥｎｄＰｏｉｎｔ１～ｎを使ったＰｏｒｔの通信の場合、バルク転送とインタラプト転送を併用することで、画像処理装置側の状況をホストＰＣに伝え、バルク転送の転送間隔を調整する制御が可能である。
しかし、ＥｎｄＰｏｉｎｔ０のコントロール転送のみ使用するプロトコルの場合、前述のインタラプト転送と併用して画像処理装置の状況をホストＰＣに伝えることができない。

上述したように、コントロール転送の返答は５００ｍｓ以内に応答する必要があるという制約がある。リアルタイムオペレーティングシステム（以下「ＲＴＯＳ」）を採用する画像処理装置の場合は、データを生成するタスクの処理優先度を上げることにより、５００ｍｓ以内の応答データ生成するできない事象を軽減することは可能となる。しかし、汎用ＯＳ（例えばＬｉｎｕｘ（登録商標））を採用する画像処理装置の場合は、各タスクのＣＰＵ専有時間が均等割りされているため、ＣＰＵ処理が忙しい場合には、５００ｍｓ以内での応答データ生成が保証されないという課題があった。なお、これは画像処理装置以外のＵＳＢデバイスでも共通する課題である。

本発明は、上記の課題を解決するためになされたものである。本発明は、Ｅｎｄｐｏｉｎｔ０で通信が行われるＵＳＢのコントロール転送において、５００ｍｓ以内に応答が要求されるコマンドをタイムアウトさせることなくホストＰＣの要求データを返答可能にする仕組みを提供することを目的とするものである。

本発明は、ＵＳＢホストとＵＳＢケーブルを介して通信可能なＵＳＢデバイスであって、前記ＵＳＢホストから送信されるコマンドを解釈して応答を行う手段であり、ＵＳＢのコントロール転送の第１コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第１シーケンスの後に、前記コントロール転送の第２コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第２シーケンスにおいて前記ＵＳＢホストにデータを応答する制御手段と、前記制御手段が前記第１コマンドを受信したことに応じて、前記第２シーケンスにて前記ＵＳＢホストに応答するデータを先行して取得する第１取得手段と、を有し、前記制御手段は、前記第２コマンドを受信した場合に、前記第１取得手段が先行して取得したデータを前記ＵＳＢホストに応答することを特徴とする。

本発明によれば、Ｅｎｄｐｏｉｎｔ０で通信が行われるＵＳＢのコントロール転送において、５００ｍｓ以内に応答が要求されるコマンドをタイムアウトさせることなくホストＰＣの要求データを返答できるようになる。

本実施形態のＵＳＢデバイスとしての画像処理装置のハードウェア構成図。 コントロール転送を用いた通信例の概略を説明するシーケンス図。 第１実施形態においてコントロール転送を用いた通信処理のシーケンス図。 第１実施形態におけるドライバ層の動作を示すフローチャート。 第１実施形態におけるドライバ層別スレッドの動作を示すフローチャート。 第１実施形態におけるＣＲＧ情報処理層の動作を示すフローチャート。 第２実施形態においてコントロール転送を用いた通信処理のシーケンス図。 第２実施形態におけるドライバ層の動作を示すフローチャート。 第２実施形態におけるドライバ層別スレッドの動作を示すフローチャート。 第２実施形態におけるＣＲＧ情報処理層の動作を示すフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

〔第１実施形態〕
図１は、本発明の一実施形態を示すＵＳＢデバイスとしての画像処理装置のハードウェア構成の一例を示す図である。
画像処理装置１は本実施形態のＵＳＢデバイスであり、ＨＯＳＴ ＰＣ（以下「ホストＰＣ」）２とＵＳＢケーブル３を介して通信可能である。

画像処理装置１において、ＣＰＵ１０１は、画像処理装置１を稼働させるためのソフトウェアを動作させる中央処理演算装置である。
システムバス１０２は、ＣＰＵ１０１が他のユニットにアクセスする、及び、他のユニット同士をアクセスする通路となる。

ＨＤＤ１０３は、画像処理装置１のソフトウェア及び、画像処理装置１が動作するために必要なデータ、また一次保存ファイルが格納されるハードディスクユニットである。なお、ＨＤＤの代わりに又は併用してＳＳＤ（Solid State Drive）等の他の記憶装置（大容量不揮発メモリ）を備えていてもよい。
ＲＡＭ１０４は、画像処理装置１のプログラムが展開されたり、プログラム動作時の変数や各ユニットからDynamic Memory Access（ＤＭＡ）で転送されるデータの格納領域となるRandom Access Memoryである。

ネットワーク・コントローラ１０５とネットワーク・コントローラ・インターフェース（Ｉ／Ｆ）１０６は、画像処理装置１と図示しないネットワーク上の他の機器とが通信を行うためのものである。
ＵＳＢデバイスコントローラ１０７とＵＳＢデバイスＩ／Ｆ１０８は、画像処理装置１とホストＰＣ２とがＵＳＢケーブル３を経由しての通信を行うためのものである。

ＣＰＬＤ１０９は、ＣＰＵ１０１を介して、基盤回路上の信号線のＬｏｗ／Ｈｉｇｈ状況を読み取る、又は、ＣＰＵ１０１がＬｏｗ／Ｈｉｇｈ状況の設定を変更可能にするユニットである。ＣＰＬＤ１０９はプログラマブルなロジックデバイスであり、画像処理装置１上で電力関係のＯＦＦ／ＯＮを制御可能にしているユニットである。なお、ＣＰＬＤは「Complex Programmable Logic Device」の略である。ＣＰＬＤ１０９の内部には、General Purpose Input Output（以下「ＧＰＩＯ」）が存在する。ＣＰＵ１０１は、そのＧＰＩＯレジスタの設定値を変更することで、電力関係のＯＦＦ／ＯＮを可能としている。

ディスプレイ１１１は、画像処理装置１の動作状況をユーザ等が確認できるように表示する。ディスプレイコントローラ１１０は、ディスプレイ１１１への表示制御を行う。
入力部１１３は、画像処理装置１へのユーザからの指示を受け付ける。入力部コントローラ１１２は、入力部１１３を制御する。入力部１１３は、具体的にはキーボードやマウスや、テンキー、カーソルキー、タッチパネルや、操作部キーボードといった入力システムである。入力部１１３がタッチパネルである場合は、物理的にはディスプレイ１１１の表面に装着された形態になる。

ＲＴＣ１１４は、画像処理装置１の時計機能、アラーム機能、タイマー機能等を持つリアルタイムクロックである。
不揮発メモリ１１５は、ＨＤＤ１０３以外に大容量ではないが書き換え可能な不揮発な記録メディアである。不揮発メモリは、Static Random Access Memory（以下「ＳＲＡＭ」）や、Electrically Erasable Programmable Read Only Memory（以下「ＥＥＰＲＯＭ」）等であってもよい。

画像処理装置１は、スキャナＩ／Ｆ１１６を介してスキャナ１１７に接続する。
また、画像処理装置１は、プリンタＩ／Ｆ１１８を介してプリンタ１１９に接続する。なお、プリンタ１１９は、記録剤を用いてシート等に画像形成を行う。プリンタ１１９内部には、記録剤を収容するカートリッジ（以後「ＣＲＧ」）１２４がセットされている。記録剤としては、例えばトナーやインク等がある。本実施形態では、記録剤をトナーとして説明するがインク等でもよい。

図２は、ホストＰＣ２と画像処理装置１を使ったコントロール転送を用いた通信例の概略を説明するシーケンス図である。
ホストＰＣ２は、ＵＳＢホストとして動作可能な機器（情報処理装置）であり、例えばパーソナルコンピュータである。なお、ホストＰＣは、パーソナルコンピュータに限定されるものではなく、タブレット型コンピュータやスマートフォン等であってもよく、ＵＳＢホストとして動作可能な機器であればよい。ホストＰＣ２は、画像処理装置１とＵＳＢケーブル３で接続され、通信を行う。図２に示す通信例は、ホストＰＣ２が、画像処理装置１内部存在するプリンタ１１９内に格納されているＣＲＧ１２４のトナー残量等を問い合わせるものである。

画像処理装置１の内部には、ＵＳＢのパケットを処理するソフトウェア的なモジュール（以下「ソフトウェアモジュール」）であるドライバ層２０１と、ＣＲＧ情報を管理するソフトウェアモジュールであるＣＲＧ情報処理層２０２が存在する。すなわち、ドライバ層２０１とＣＲＧ情報処理層２０２は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現され機能する。

以下、ＵＳＢホストとして動作するホストＰＣ２が画像処理装置１にＣＲＧ１２４に収容されているトナーに関する情報（トナー残量）等を問い合わせる通信について詳細に説明する。

まず、ホストＰＣ２は、画像処理装置１に対して、コントロール転送のベンダークラス（Vendor class）コマンドであるCRG Set Commandを送信する（Ｓ２０３）。
続いて、ホストＰＣ２は、ＣＲＧ１２４にセットするデータを、画像処理装置１に送信する（Ｓ２０４）。

画像処理装置１では、上記ホストＰＣ２から送信されたコマンドデータを、ドライバ層２０１で受け取る。ドライバ層２０１は、該受け取ったデータをＣＲＧ情報処理層２０２に転送する（Ｓ２０５）。ＣＲＧ情報処理層２０２は、コマンドデータの内容を解釈して処理を実施する。
上記Ｓ２０５の処理が完了すると、ドライバ層２０１は、受信した主旨であるＡＣＫ応答をホストＰＣ２に対して実施する（Ｓ２０６）。

次に、ホストＰＣ２は、画像処理装置１のＣＲＧ情報（例えば、ＣＲＧ１２４内のトナー残量）を取得するために、コントロール転送のVendor classコマンドであるCRG Get Commandをドライバ層２０１に送信する（Ｓ２０７）。
上記Ｓ２０７でCRG Get Commandを受信したドライバ層２０１は、該受信したコマンドをＣＲＧ情報処理層２０２に転送する（Ｓ２０８）。
ＣＲＧ情報処理層２０２は、上記Ｓ２０８で受け取ったコマンドの情報を解釈し、該コマンドに対応するデータを収拾し、ＣＲＧ情報Ｄａｔａとしてドライバ層２０１に返答する（Ｓ２０９）。上記Ｓ２０９でＣＲＧ情報Ｄａｔａを受け取ったドライバ層２０１は、CRG Get dataをホストＰＣ２に返送する（Ｓ２１０）。
ホストＰＣ２は、CRG Get dataをドライバ層２０１から受信すると、受領を意味するＡＣＫを画像処理装置１へ送信する（Ｓ２１１）。

上記Ｓ２０３、Ｓ２０４及びＳ２０６のシーケンスに対応するトランザクション（以下「セットアップトランザクション」）は、CRG Set Commandの送信（Ｓ２０３）により開始する。また、上記Ｓ２０７、Ｓ２１０及びＳ２１１のシーケンスに対応するトランザクション（以下「データトランザクション」）は、CRG Get Commandの送信（Ｓ２０７）により開始する。本実施形態のシステムでは、データトランザクションの前に、セットアップトランザクションが行われる。なお、１回のデータトランザクションで転送可能なでデータサイズよりも、転送すべきデータのサイズが大きい場合、データトランザクションを複数回繰り返して、全データを転送するようにしてもよい。

ホストＰＣ２は、ＵＳＢ２．０仕様通りに動作する。ホストＰＣ２は、上記Ｓ２０７でCRG Get Commandを発行した後、上記Ｓ２１０でCRG Get dataの受領までの間が５００ｍｓ以上経過すると、CRG Get Commandのデータ取得をタイムアウトとして諦める。例えばＣＲＧ情報処理層２０２がＣＲＧ情報を取得中に、別ジョブ起因で（例えばネットワークからのＰＤＬ印刷データ処理が発生し）、ＣＰＵ資源が十分に回らなくなった場合、ＣＲＧ情報Ｄａｔａの取得（Ｓ２０９）が遅くなる場合がある。この場合、上記Ｓ２０７から５００ｍｓ以上経過してしまい、ドライバ層２０１からホストＰＣ２へのCRG Get dataの返答（Ｓ２１０）ができなくなってしまう可能性がある。

この課題を解決する処理を図３のシーケンス図に示す。以下、図２のシーケンス図との差分を説明する。
図３は、第１実施形態におけるホストＰＣ２と画像処理装置１を使ったコントロール転送を用いた通信処理の一例を説明するシーケンス図であり、図２と同一のものには同一の符号を付してある。

図２と同様に、Ｓ２０４の処理でホストＰＣ２からCRG Set dataを取得したドライバ層２０１は、ＣＲＧ情報処理層２０２にＣＲＧ情報Ｄａｔａを送信する（Ｓ２０５）。Ｓ２０５の処理が終わると同時にドライバ層２０１は、ＣＲＧ情報取得コマンド生成用の別スレッドであるドライバ層別スレッド３０１を生成する（Ｓ３０２）。ドライバ層別スレッド３０１は、文字通りドライバ層２０１とは、別スレッドで動作を行う。上記Ｓ３０２の処理の後、ドライバ層２０１は、ホストＰＣ２へのＡＣＫ応答を返答し（Ｓ２０６）、CRG Get Commandの受信を待つ。

ドライバ層別スレッド３０１は、ＣＲＧ情報処理層２０２にＣＲＧ情報取得コマンドを送信する（Ｓ３０３）。ＣＲＧ情報処理層２０２は、上記Ｓ３０３でコマンド受信を受けると、ＣＲＧ情報Ｄａｔａを生成して、ドライバ層別スレッド３０１にデータを返答する（Ｓ３０４）。ドライバ層別スレッド３０１は、この後、後述するＣＲＧ情報取得の処理（Ｓ３０５）を待つことになる。

ドライバ層２０１は、Ｓ２０７でホストＰＣ２からのCRG Get Commandを受けると、ドライバ層別スレッド３０１に対して、ＣＲＧ情報取得コマンドを送る（Ｓ３０５）。ドライバ層別スレッド３０１は、上記Ｓ３０５の処理を受け、上記Ｓ３０４の処理で事前に取得しておいたＣＲＧ情報をドライバ層２０１に速やかに返答する（Ｓ３０６）。
ドライバ層２０１は、上記Ｓ３０６で受信したデータをホストＰＣ２に対してCRG Get dataとして送信する（Ｓ２１０）。上記Ｓ２１０の処理でCRG Get dataを受信したホストＰＣ２は、受領した主旨を意味するＡＣＫコマンドをドライバ層２０１に送る（Ｓ２１１）。

すなわち、ＵＳＢ処理を司るドライバ層２０１を複数スレッド化し、ＳＥＴコマンド受信時にドライバ層２０１の別スレッド（ドライバ層別スレッド３０１）により予め先行してＧＥＴコマンドで応答するデータを取得しておく。そして、ＧＥＴコマンド受信時に上記先行して取得しておいたデータをホストＰＣに応答する。

上述した図３では本実施形態のシーケンスを示した。次に、画像処理装置１のそれぞれのソフトウェアモジュール（ドライバ層２０１、ドライバ層別スレッド３０１、ＣＲＧ情報処理層２０２）の動作について、図４、図５及び図６のフローチャートを用いて説明する。

図４は、第１実施形態におけるドライバ層２０１の動作の一例を示すフローチャートである。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

ＣＰＵ１０１（ドライバ層２０１）は、ＵＳＢデバイスＩ／Ｆ１０８を介して、ホストＰＣ２から送信されてくるＵＳＢコントロール転送のVendor ClassコマンドのCRG Set Commandの受信を待つ（Ｓ４０１）。このCRG Set Commandは、ホストＰＣ２から、CRG Get Commandの送信より前に必ず送信される。

ＣＰＵ１０１（ドライバ層２０１）は、CRG Set Commandを受信すると（Ｓ４０１でＹｅｓの場合）、プリンタ１１９内部に存在するＣＲＧ１２４情報を管理するＣＲＧ情報処理層２０２に、受信したコマンドを送信する（Ｓ４０２）。

また、ＣＰＵ１０１（ドライバ層２０１）は、ドライバ層別スレッド３０１を生成する（Ｓ４０３）。ドライバ層別スレッド３０１の処理については後述する図５に示す。

上記Ｓ４０３の処理を終えると、ＣＰＵ１０１（ドライバ層２０１）は、ホストＰＣ２に対してCRG Set dataを受信したことを示すＡＣＫ応答を返答する（Ｓ４０４）。
次にＣＰＵ１０１（ドライバ層２０１）は、ホストＰＣ２から送信されてくるＵＳＢコントロール転送のVendor ClassコマンドのCRG Get Commandの受信を待つ（Ｓ４０５）。
ＣＰＵ１０１（ドライバ層２０１）は、CRG Get Commandを受信すると（Ｓ４０５でＹｅｓの場合）、ドライバ層別スレッド３０１にＣＲＧ情報取得を要求する（Ｓ４０６）。

次にＣＰＵ１０１（ドライバ層２０１）は、ドライバ層別スレッド３０１からのＣＲＧ情報Ｄａｔａの応答を待つ（Ｓ４０７）。ＣＲＧ情報Ｄａｔａを取得できたら（Ｓ４０７でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層２０１）は、該取得したＣＲＧ情報ＤａｔａをホストＰＣ２に対して、ＵＳＢデバイスＩ／Ｆ１０８を介して送信する（Ｓ４０８）。Ｓ４０８の処理の後、ＣＰＵ１０１（ドライバ層２０１）は、Ｓ４０１に処理を戻し、次のCRG Set Commandの受信を待機する。

図５は、第１実施形態におけるドライバ層別スレッド３０１の動作の一例を示すフローチャートである。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

ＣＰＵ１０１（ドライバ層別スレッド３０１）は、生成されると直ちに、ＣＲＧ情報処理層２０２に対して、ＣＲＧ情報取得コマンドを送信する（Ｓ５０１）。
上記Ｓ５０１の処理後、ＣＰＵ１０１（ドライバ層別スレッド３０１）は、ＣＲＧ情報処理層からＣＲＧ情報Ｄａｔａを取得できるまで待つ（Ｓ５０２）。
上記Ｓ５０２の処理でＤａｔａを取得出来たら（Ｓ５０２でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層別スレッド３０１）は、該取得したデータをＲＡＭ１０４上に保持しておく（Ｓ５０３）。すなわち、ドライバ層別スレッド３０１は、先行してＣＲＧ情報Ｄａｔａを取得しておく。

次にＣＰＵ１０１（ドライバ層別スレッド３０１）は、ドライバ層２０１からのＣＲＧ情報取得依頼を待つ（Ｓ５０４）。
上記５０４の処理で依頼を受けたら（Ｓ５０４でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層別スレッド３０１）は、ＲＡＭ１０４上に保持していたＣＲＧ情報Ｄａｔａをドライバ層２０１に対して送信し（Ｓ５０５）、処理を終了する。

図６は、第１実施形態におけるＣＲＧ情報処理層２０２の動作の一例を示すフローチャートである。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ドライバ層２０１からのＣＲＧ情報Ｄａｔａの受信を待つ（Ｓ６０１）。
ＣＲＧ情報Ｄａｔａを受信すると（Ｓ６０１でＹｅｓの場合）、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、該受信した情報を基にＣＲＧ１２４と通信を行い、指定されたコマンドを処理する（Ｓ６０２）。

次にＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ情報取得コマンドの受信を待つ（Ｓ６０３）。ここではＣＲＧ情報取得コマンドはドライバ層別スレッド３０１から送信される。ＣＲＧ情報取得コマンドを受信すると（Ｓ６０３でＹｅｓの場合）、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ１２４と通信を行い、ＣＲＧ情報取得を行い、返答データを作成する（Ｓ６０４）。

ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、上記Ｓ６０４で作成したデータをＣＲＧ情報取得コマンドの送信元（上述の例ではドライバ層別スレッド３０１）に返送する（Ｓ６０５）。Ｓ６０５の処理の後、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、Ｓ６０１に処理を戻し、次のＣＲＧ情報Ｄａｔａの受信を待機する。

以上、図３に示したシーケンス、及び図４、図５，図６に示した各ソフトウェアモジュールの処理により、画像処理装置１のＣＰＵ１０１の負荷状況に関わらず、コントロール転送の５００ｍｓ以内の返答をホストＰＣに行うことが可能になる。

〔第２実施形態〕
ホストＰＣ２が発行するCRG Set CommandとCRG Get Commandのコマンドの時間間隔（Ｓ２０３の処理とＳ２０７の処理の間隔）が大きくなってしまう場合がある。この場合、第１実施形態の構成では、CRG Get Commandの結果取得されるCRG Gat dataの情報が最新のデータになっていない（又は最新のデータとの相違が大きくなっている）可能性がある。

例えば、極端な例で説明すると、ホストＰＣ２がＳ２０３でCRG Set Commandを発行後、画像処理装置１にネットワーク・コントローラＩ／Ｆ１０６経由で別ＰＤＬ印刷ジョブが大量処理された場合、ＣＲＧのトナー情報に変動が発生する。Ｓ２０３の処理から１０分経過した後に、Ｓ２０７でCRG Get Commandが発行された場合、その結果取得されるCRG Get dataの情報は、１０分前の情報となる。この場合、取得されるCRG Get dataの情報が、最新の情報になっていない（又は最新の情報との差が大きくなっている）ケースも想定される。以下、この課題を解決する第２実施形態について説明する。

この課題を解決する処理を図７のシーケンス図に示す。以下、図３のシーケンス図との差分を説明する。
図７は、第２実施形態におけるホストＰＣ２と画像処理装置１を使ったコントロール転送を用いた通信処理の一例を説明するシーケンス図であり、図３と同一のものには同一の符号を付してある。

図３と同様に、Ｓ２０７の処理でホストＰＣ２からCRG Get Commandを取得したドライバ層２０１は、新しくＣＲＧ情報取得コマンド生成用の第２の別スレッドであるドライバ層第２別スレッド７０１を生成する（Ｓ７０２）。ドライバ層第２別スレッド７０１は、文字通りドライバ層２０１とは、別スレッドで動作を行う。
さらにドライバ層２０１は、ドライバ層第２別スレッド７０１に対して、ＣＲＧ情報取得コマンドを送る（Ｓ７０３）。

ドライバ層第２別スレッド７０１は、上記Ｓ７０３のコマンド受信を受け、ＣＲＧ情報処理層２０２にＣＲＧ情報取得コマンドを送信する（Ｓ７０４）。
ＣＲＧ情報処理層２０２は、上記Ｓ７０４のコマンド受信を受け、ＣＲＧ情報Ｄａｔａを生成して、ドライバ層第２別スレッド７０１にデータを返答する（Ｓ７０５）。
ドライバ層第２別スレッド７０１は、上記Ｓ７０５で取得したデータをドライバ層２０１に対して返答する（Ｓ７０６）。

ドライバ層２０１は、上記Ｓ２０７でホストＰＣ２からのCRG Get Commandを受けてから５００ｍｓ－α時間（αは正の値で１０ｍｓ～５０ｍｓ程度の小さい値）ドライバ層第２別スレッド７０１からの返答（Ｓ７０６）を待ち続ける。しかし、５００ｍｓ－α時間待っても上記Ｓ７０６の返答がされない場合は、ドライバ層２０１は、予めＳ３０６で取得しているデータをもって、ホストＰＣ２に対してCRG Get dataを返答する（Ｓ２１０）。
一方、ドライバ層２０１は、５００ｍｓ－α時間以内に上記Ｓ７０６でＣＲＧ情報Ｄａｔａを取得出来た場合、該Ｓ７０６で取得したデータをGET Get dataとしてホストＰＣ２へ送信する（Ｓ２１０）。この場合、ホストＰＣ２がCRG Get Commandの結果取得するCRG Gat dataの情報を最新のデータにすることができる。

上述した図７では本実施形態のシーケンスを示した。次に、画像処理装置１のそれぞれのソフトウェアモジュール（ドライバ層２０１、ドライバ層第２別スレッド７０１、ＣＲＧ情報処理層２０２）の動作について、図８、図９及び図１０のフローチャートを用いて説明する。なお、ドライバ層別スレッド３０１のフローチャートに関しては、第１実施形態と変更ないため、説明を省略する。

図８は、第２実施形態におけるドライバ層２０１の動作の一例を示すフローチャートであり、図４と同一のステップには同一のステップ番号を付してある。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

第２実施形態のＣＰＵ１０１（ドライバ層２０１）は、CRG Get Commandを受信すると（Ｓ４０５でＹｅｓの場合）、ドライバ層第２別スレッド７０１を生成する（Ｓ８０１）。ドライバ層第２別スレッド７０１の処理については後述する図９に示す。

上記Ｓ８０１の処理を終えると、ＣＰＵ１０１（ドライバ層２０１）は、ドライバ層第２別スレッド７０１にＣＲＧ情報取得を要求する（Ｓ８０２）。
その後ＣＰＵ１０１（ドライバ層２０１）は、ドライバ層別スレッド３０１にＣＲＧ情報取得を要求する（Ｓ４０６）。

次にＣＰＵ１０１（ドライバ層２０１）は、ドライバ層別スレッド３０１からのＣＲＧ情報Ｄａｔａを取得できたら（Ｓ４０７でＹｅｓの場合）、Ｓ８０３に処理を進める。
Ｓ８０３では、ＣＰＵ１０１（ドライバ層２０１）は、ドライバ層第２別スレッド７０１からのＣＲＧ情報Ｄａｔａの応答を待つ。そしてＣＰＵ１０１（ドライバ層２０１）は、応答待ち時間がCRG Get Command取得時間から５００ｍｓ－α時間経過したか判定する
（Ｓ８０４）。５００ｍｓ－α時間経過していなければ（Ｓ８０４のＮｏの場合）、ＣＰＵ１０１（ドライバ層２０１）は、ひきつづき上記Ｓ８０３でＣＲＧ情報Ｄａｔａの応答を待つ。

５００ｍｓ－α時間経過していなければ（Ｓ８０４のＮｏの場合）、ＣＰＵ１０１（ドライバ層２０１）は、ひきつづき上記Ｓ８０３でＣＲＧ情報Ｄａｔａの応答を待つ。
５００ｍｓ－α時間経過する前に、ドライバ層第２別スレッド７０１からのＣＲＧ情報Ｄａｔａを取得できた場合（Ｓ８０３でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層２０１）は、Ｓ８０５に処理を進める。
Ｓ８０５では、ＣＰＵ１０１（ドライバ層２０１）は、上記Ｓ８０３で取得したデータをホストＰＣ２に対して、ＵＳＢデバイスＩ／Ｆ１０８を介して送信する。

一方、ドライバ層第２別スレッド７０１からのＣＲＧ情報Ｄａｔａを取得する前に、５００ｍｓ－α時間をオーバーした場合（Ｓ８０４でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層２０１）は、Ｓ８０６に処理を進める。
Ｓ８０６では、ＣＰＵ１０１（ドライバ層２０１）は、上記Ｓ４０７で取得したデータをホストＰＣ２に対して、ＵＳＢデバイスＩ／Ｆ１０８を介して送信する。

すなわち、所定の時間（上述の例では５００ｍｓ－α時間）以内にドライバ層第２別スレッド７０１を介してＣＲＧ情報Ｄａｔａを取得できた場合には、そのＣＲＧ情報ＤａｔａをホストＰＣに送信する（Ｓ８０５）。一方、所定の時間以内にドライバ層第２別スレッド７０１を介してＣＲＧ情報Ｄａｔａを取得できなかった場合には、ドライバ層別スレッド３０１が先行して取得したＣＲＧ情報ＤａｔａをホストＰＣに送信する（Ｓ８０６）。
上記Ｓ８０５又はＳ８０６の処理の後、ＣＰＵ１０１（ドライバ層２０１）は、Ｓ４０１に処理を戻し、次のCRG Set Commandの受信を待機する。

図９は、第２実施形態におけるドライバ層第２スレッド７０１の動作の一例を示すフローチャートである。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

ＣＰＵ１０１（ドライバ層第２スレッド７０１）は、生成されると直ちに、ドライバ層２０１からくるＣＲＧ情報取得依頼を待ち続ける（Ｓ９０１）。上記９０１の処理で依頼を受けると（Ｓ９０１でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層第２スレッド７０１）は、ＣＲＧ情報処理層２０２に対して、ＣＲＧ情報取得コマンドを送信する（Ｓ９０２）。

上記Ｓ９０２の処理後、ＣＰＵ１０１（ドライバ層第２スレッド７０１）は、ＣＲＧ情報処理層からＣＲＧ情報Ｄａｔａを取得できるまで待つ（Ｓ９０３）。
上記Ｓ９０３の処理でＤａｔａを取得出来たら（Ｓ９０３でＹｅｓの場合）、ＣＰＵ１０１（ドライバ層第２スレッド７０１）は、Ｓ９０４に処理を進める。Ｓ９０４では、ＣＰＵ１０１（ドライバ層第２スレッド７０１）は、上記Ｓ９０３で取得したデータをＲＡＭ１０４上に保持して、そのデータをＣＲＧ情報Ｄａｔａとしてドライバ層２０１に対して送信し、処理を終了する。

図１０は、第２実施形態におけるＣＲＧ情報処理層２０２の動作の一例を示すフローチャートである。このフローチャートの処理は、画像処理装置１のＣＰＵ１０１がＨＤＤ１０３等に格納されたプログラムをＲＡＭ１０４にロードして実行することにより実現される。

ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ドライバ層２０１からのＣＲＧ情報Ｄａｔａの受信を待つ（Ｓ１００１）。
ＣＲＧ情報Ｄａｔａを受信すると（Ｓ１００１でＹｅｓの場合）、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、該受信した情報を基にＣＲＧ１２４と通信を行い、指定されたコマンドを処理する（Ｓ１００２）。

次にＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ情報取得コマンドの受信を待つ（Ｓ１００３）。ここではＣＲＧ情報取得コマンドはドライバ層別スレッド３０１から送信される。ＣＲＧ情報取得コマンドを受信すると（Ｓ１００３でＹｅｓの場合）、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ１２４と通信を行い、ＣＲＧ情報取得を行い、返答データを作成する（Ｓ１００５）。

ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、上記Ｓ１００４で作成したデータをＣＲＧ情報取得コマンドの送信元（上述の例ではドライバ層別スレッド３０１）に返送する（Ｓ１００５）。

次にＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ情報取得コマンドの受信を待つ（Ｓ１００６）。ここではＣＲＧ情報取得コマンドはドライバ層第２別スレッド７０１から送信される。ＣＲＧ情報取得コマンドを受信すると（Ｓ１００６でＹｅｓの場合）、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、ＣＲＧ１２４と通信を行い、ＣＲＧ情報取得を行い、返答データを作成する（Ｓ１００７）。

ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、上記Ｓ１００７で作成したデータをＣＲＧ情報取得コマンドの送信元（上述の例ではドライバ層第２別スレッド７０１）に返送する（Ｓ１００８）。Ｓ１００８の処理の後、ＣＰＵ１０１（ＣＲＧ情報処理層２０２）は、Ｓ１００１に処理を戻し、次のＣＲＧ情報Ｄａｔａの受信を待機する。

以上、図７に示したシーケンス、及び図８、図９，図１０に示した各ソフトウェアモジュールの処理により、画像処理装置１のＣＰＵ１０１の負荷状況に関わらず、コントロール転送の５００ｍｓ以内の返答をホストＰＣに行うことが可能になる。さらに、最新のＣＲＧ情報を返答することが可能となる。
以上、各実施形態によれば、Ｅｎｄｐｏｉｎｔ０で通信が行われるＵＳＢのコントロール通信において、５００ｍｓ以内に応答が要求されるＧＥＴコマンドをタイムアウトさせることなくホストＰＣの要求データを返答できるようになる。

なお、上述の例では、ホストＰＣ２が画像処理装置１とのコントロール転送を、ホストＰＣ２が画像処理装置１内部存在するプリンタ１１９内に格納されているＣＲＧ１２４のトナー残量等を問い合わせる処理を例に説明した。しかし、本実施形態のコントロール転送は、ホストＰＣが画像処理装置等のＵＳＢデバイスから要求データを取得するものであればよい。さらに、ホストＰＣがコントロール転送によりＵＳＢデバイスから取得するデータもどのようなデータであってもよい。

以上によれば、Ｅｎｄｐｏｉｎｔ０で通信が行われるＵＳＢのコントロール通信において、５００ｍｓ以内に応答が要求されるＧＥＴコマンドをタイムアウトさせることなくホストＰＣの要求データを返答できるようになる。すなわち、ＵＳＢホストとＵＳＢデバイスにおけるＵＳＢコントロール転送におけるタイムアウトを回避することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施形態を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１ 画像処理装置
２ ホストＰＣ
３ ＵＳＢケーブル
１０１ ＣＰＵ
１０７ ＵＳＢデバイスコントローラ
１０８ ＵＳＢデバイスインターフェース
１１８ プリンタＩ／Ｆ
１１９ プリンタ
１２４ ＣＲＧ

Claims (9)

1. ＵＳＢホストとＵＳＢケーブルを介して通信可能なＵＳＢデバイスであって、
   前記ＵＳＢホストから送信されるコマンドを解釈して応答を行う手段であり、ＵＳＢのコントロール転送の第１コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第１シーケンスの後に、前記コントロール転送の第２コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第２シーケンスにおいて前記ＵＳＢホストにデータを応答する制御手段と、
   前記制御手段が前記第１コマンドを受信したことに応じて、前記第２シーケンスにて前記ＵＳＢホストに応答するデータを先行して取得する第１取得手段と、を有し、
   前記制御手段は、前記第２コマンドを受信した場合に、前記第１取得手段が先行して取得したデータを前記ＵＳＢホストに応答することを特徴とするＵＳＢデバイス。
2. 前記制御手段はソフトウェアモジュールであり、
   前記制御手段は、前記第１コマンドを受信したことに応じて、前記第１取得手段を前記制御手段とは別のスレッドとして生成することを特徴とする請求項１に記載のＵＳＢデバイス。
3. 前記制御手段が前記第２コマンドを受信した場合に、前記第２シーケンスにて前記ＵＳＢホストに応答するデータを取得するための第２取得手段を有し、
   前記制御手段は、前記第２コマンドを受信した場合、前記第２コマンドを受信してから所定の時間以内に前記第２取得手段を介して前記データを取得できた場合には、前記第１取得手段が先行して取得したデータの代わりに、前記第２取得手段が取得したデータを前記ＵＳＢホストに応答することを特徴とする請求項１に記載のＵＳＢデバイス。
4. 前記制御手段はソフトウェアモジュールであり、
   前記制御手段は、前記第１コマンドを受信したことに応じて前記第１取得手段を前記制御手段とは別のスレッドとして生成し、前記第２コマンドを受信したことに応じて前記第２取得手段を前記制御手段とは別のスレッドとして生成することを特徴とする請求項３に記載のＵＳＢデバイス。
5. 前記第１コマンド及び前記第２コマンドは、前記コントロール転送のベンダークラスのコマンドであることを特徴とする請求項１～４のいずれか１項に記載のＵＳＢデバイス。
6. 前記ＵＳＢデバイスは、記録剤を用いて画像形成を行う画像処理装置であり、
   前記第２シーケンスにて前記ＵＳＢホストに応答するデータは、前記記録剤の残量に関するデータであることを特徴とする請求項１～５のいずれか１項に記載のＵＳＢデバイス。
7. 前記記録剤は、前記画像処理装置に装着されるカートリッジに収容されることを特徴とする請求項６に記載のＵＳＢデバイス。
8. ＵＳＢケーブルを介して通信可能なＵＳＢホストから送信されるコマンドを解釈して応答を行うＵＳＢデバイスであり、ＵＳＢのコントロール転送の第１コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第１シーケンスの後に、前記コントロール転送の第２コマンドが前記ＵＳＢホストから前記ＵＳＢデバイスに送信されることで開始される第２シーケンスにおいて前記ＵＳＢホストにデータを応答するＵＳＢデバイスの制御方法であって、
   前記第１コマンドを受信したことに応じて、前記第２シーケンスにて前記ＵＳＢホストに応答するデータを先行して取得する取得工程と、
   前記第２コマンドを受信した場合に、前記取得工程で先行して取得したデータを前記ＵＳＢホストに応答する応答工程と、
   を有することを特徴とするＵＳＢデバイスの制御方法。
9. コンピュータを、請求項１～７のいずれか１項に記載の手段として機能させるためのプログラム。

Images