(57)【要約】【課題】  ポーリングを使用せずにパケットデータの受信を制御装置に認識させることができるデータ受信装置を提供する。【解決手段】  データ通信路を介してホスト装置１０から送信されたパケットデータを格納する複数のバッファ３２１、３２２、３２３を備えるターゲットデバイス３０であって、ホスト装置１０から送信されるパケットデータを受信するＵＳＢターゲットコントローラ３３と、ホスト装置１０から転送されるパケットデータの最大転送サイズを、パケットデータを格納可能な有効メモリサイズとし、ホスト装置１０からのパケットデータの送信が開始されると、複数のバッファにおいて最初にパケットデータを格納するバッファ３２１と、バッファ３２１にパケットデータが格納され、バッファ３２１の有効メモリサイズを満たした場合に、ターゲットデバイス３０を制御するＣＰＵ３１に、パケットデータの受信を通知する制御部３６とを備える。【選択図】        図２
2011198314.tif 000002
【特許請求の範囲】
【請求項１】
データ通信路を介して外部装置から送信されたパケットデータを格納する複数のメモリを備えるデータ受信装置であって、
前記データ通信路を介して前記外部装置から送信されるパケットデータを受信する受信手段と、
前記外部装置から転送されるパケットデータの最大転送サイズを、パケットデータを格納可能な有効メモリサイズとし、前記外部装置からのパケットデータの送信が開始されると、前記複数のメモリにおいて最初にパケットデータを格納する第１メモリと、
前記第１メモリにパケットデータが格納され、前記第１メモリの有効メモリサイズを満たした場合に、前記データ受信装置を制御する制御装置に、パケットデータの受信を通知する通知手段と、
を有することを特徴とするデータ受信装置。
【請求項２】
前記複数のメモリは、前記第１メモリと、前記外部装置から順次送信される、前記第１メモリに格納されたパケットデータに後続するパケットデータを順次格納する、前記最大転送サイズの整数倍をパケットデータを格納可能な有効メモリサイズとする複数の後続メモリとを備え、
前記複数の後続メモリのいずれかにパケットデータの格納が開始されてから、該メモリの有効メモリサイズを満たすパケットデータが格納されるまでの待ち時間を設定する待ち時間設定手段を有し、
前記通知手段は、前記複数の後続メモリのうちのいずれかのメモリにパケットデータの格納が開始されてから、前記待ち時間を経過しても前記メモリの有効メモリサイズを満たすパケットデータが前記メモリに格納されない場合に、前記制御装置に、前記外部装置からのパケットデータの受信完了を通知することを特徴とする請求項１記載のデータ受信装置。
【請求項３】
前記後続メモリは、第２メモリと第３メモリとを備え、
前記第２メモリのパケットデータを格納可能な有効メモリサイズは、前記第３メモリの有効メモリサイズから前記第１メモリの有効メモリサイズを差し引いたメモリサイズを備えることを特徴とする請求項２記載のデータ受信装置。
【請求項４】
前記第１メモリと前記第２メモリとの有効メモリサイズを変更する有効メモリサイズ変更手段を備え、
前記有効メモリサイズ変更手段は、前記第１メモリと前記第２メモリとのそれぞれに、各メモリの有効メモリサイズを満たすパケットデータが格納され、前記制御装置によって、格納されたパケットデータが後段側の処理部へ転送された後に、前記第１メモリと前記第２メモリとの有効メモリサイズを、前記第３メモリの有効メモリサイズに変更して、前記第３メモリに、該第３メモリの有効メモリサイズを満たすパケットデータが格納された後に、後続するパケットデータを前記第１メモリと前記第２メモリとに順次格納させることを特徴とする請求項３記載のデータ受信装置。
【請求項５】
データ通信路を介して外部装置から送信されたパケットデータを格納する複数のメモリを備えるデータ受信装置のデータ受信プログラムであって、
コンピュータに、
前記データ通信路を介して前記外部装置から送信されるパケットデータを受信手段で受信するステップと、
前記外部装置からのパケットデータの送信が開始されると、前記外部装置から転送されるパケットデータの最大転送サイズを、パケットデータを格納可能な有効メモリサイズとする第１メモリに、前記複数のメモリにおいて最初にパケットデータを格納させるステップと、
前記第１メモリにパケットデータが格納され、前記第１メモリの有効メモリサイズを満たした場合に、前記データ受信装置を制御する制御装置に、パケットデータの受信を通知するステップとを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ受信装置及びプログラムに関する。
【背景技術】
【０００２】
装置間における通信は、一般に、何らかの規格に基づいて行われる。例えば、シリアル通信においては、ＩＥＥＥ(Institute of Electrical and Electronic Engineers)１３９４やＵＳＢ（ Universal Serial Bus）が広く用いられている。ＩＥＥＥ１３９４は、１００Ｍｂｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓの転送速度が定められた規格である。また、ＵＳＢは、ＵＳＢ１．１で採用された最大１２Ｍｂｐｓの転送速度を持つＦＳ（フルスピードモード）や、ＵＳＢ２．０で追加された最大４８０Ｍｂｐｓの転送速度を持つＨＳ（ハイスピード）モードなどが定められた規格である。
【０００３】
特許文献１は、画像形成装置のデータ転送方法であって、メモリにパケットが格納されているかを第１の監視時間ごとに監視する第１の監視段階と、監視の結果、メモリにパケットが格納されていれば第１の監視時間よりも短い第２の監視時間ごとにメモリへのパケットの格納を監視する第２監視段階とを備えている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許公報第３８５７５９８号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、ポーリングを使用せずにパケットデータの受信を制御装置に認識させることができるデータ受信装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
かかる目的を達成するために請求項１記載の発明は、データ通信路を介して外部装置から送信されたパケットデータを格納する複数のメモリを備えるデータ受信装置であって、前記データ通信路を介して前記外部装置から送信されるパケットデータを受信する受信手段と、前記外部装置から転送されるパケットデータの最大転送サイズを、パケットデータを格納可能な有効メモリサイズとし、前記外部装置からのパケットデータの送信が開始されると、前記複数のメモリにおいて最初にパケットデータを格納する第１メモリと、前記第１メモリにパケットデータが格納され、前記第１メモリの有効メモリサイズを満たした場合に、前記データ受信装置を制御する制御装置に、パケットデータの受信を通知する通知手段とを備える。
【０００７】
請求項２記載の発明は、請求項１記載の発明において、前記複数のメモリは、前記第１メモリと、前記外部装置から順次送信される、前記第１メモリに格納されたパケットデータに後続するパケットデータを順次格納する、前記最大転送サイズの整数倍をパケットデータを格納可能な有効メモリサイズとする複数の後続メモリとを備え、前記複数の後続メモリのいずれかにパケットデータの格納が開始されてから、該メモリの有効メモリサイズを満たすパケットデータが格納されるまでの待ち時間を設定する待ち時間設定手段を有し、前記通知手段は、前記複数の後続メモリのうちのいずれかのメモリにパケットデータの格納が開始されてから、前記待ち時間を経過しても前記メモリの有効メモリサイズを満たすパケットデータが前記メモリに格納されない場合に、前記制御装置に、前記外部装置からのパケットデータの受信完了を通知するとよい。
【０００８】
請求項３記載の発明は、請求項１記載の発明において、前記後続メモリは、第２メモリと第３メモリとを備え、前記第２メモリのパケットデータを格納可能な有効メモリサイズは、前記第３メモリの有効メモリサイズから前記第１メモリの有効メモリサイズを差し引いたメモリサイズを備えるとよい。
【０００９】
請求項４記載の発明は、請求項３記載の発明において、前記第１メモリと前記第２メモリとの有効メモリサイズを変更する有効メモリサイズ変更手段を備え、前記有効メモリサイズ変更手段は、前記第１メモリと前記第２メモリとのそれぞれに、各メモリの有効メモリサイズを満たすパケットデータが格納され、前記制御装置によって、格納されたパケットデータが後段側の処理部へ転送された後に、前記第１メモリと前記第２メモリとの有効メモリサイズを、前記第３メモリの有効メモリサイズに変更して、前記第３メモリに、該第３メモリの有効メモリサイズを満たすパケットデータが格納された後に、後続するパケットデータを前記第１メモリと前記第２メモリとに順次格納させるとよい。
【００１０】
請求項５記載の発明は、データ通信路を介して外部装置から送信されたパケットデータを格納する複数のメモリを備えるデータ受信装置のデータ受信プログラムであって、コンピュータに、前記データ通信路を介して前記外部装置から送信されるパケットデータを受信手段で受信するステップと、前記外部装置からのパケットデータの送信が開始されると、前記外部装置から転送されるパケットデータの最大転送サイズを、パケットデータを格納可能な有効メモリサイズとする第１メモリに、前記複数のメモリにおいて最初にパケットデータを格納させるステップと、前記第１メモリにパケットデータが格納され、前記第１メモリの有効メモリサイズを満たした場合に、前記データ受信装置を制御する制御装置に、パケットデータの受信を通知するステップとを実行させることを特徴としている。
【発明の効果】
【００１１】
請求項１記載の発明によれば、ポーリングを使用せずにパケットデータの受信を制御装置に認識させることができる。
【００１２】
請求項２記載の発明によれば、パケットデータの受信完了を判定し、制御装置にパケットデータの受信完了を通知することができる。
【００１３】
請求項３記載の発明によれば、後段側の処理部に送るパケットデータのデータサイズを第３メモリの有効メモリサイズに合わせることができる。
【００１４】
請求項４記載の発明によれば、第１メモリと第２メモリとに一度パケットデータが格納された後は、第１メモリと第２メモリの有効メモリサイズを第３メモリの有効メモリサイズに合わせることができる。
【００１５】
請求項５記載の発明によれば、ポーリングを使用せずにパケットデータの受信を制御装置に認識させることができる。
【図面の簡単な説明】
【００１６】
【図１】ＵＳＢ通信システムのハードウェア構成例を示す図である。
【図２】ＵＳＢ通信システムのソフトウェアとハードウェアの階層を示す図である。
【図３】バルクアウト転送において送受信されるパケットを説明するための図である。
【図４】バルクアウト転送において送受信されるパケットを説明するための図である。
【図５】ターゲットデバイス内部におけるデータ転送について説明するための図である。
【図６】カーネル領域のバッファに関する処理の流れを示す図である。
【図７】ＩＯリクエスト構造体の構造を示す図である。
【図８】ＩＯリクエストとＩＯリクエスト待ちキューについて説明するための図である。
【図９】ＩＯリクエストとＩＯリクエスト完了キューについて説明するための図である。
【図１０】カーネル領域のバッファ設定処理を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、添付図面を参照しながら本発明の好適な実施例を説明する。
【実施例】
【００１８】
まず、図１を参照しながら本発明をＵＳＢ通信システムに適用した実施例の構成を説明する。ＵＳＢ通信システムは、ＵＳＢのホスト装置（例えば、パーソナルコンピュータ）１０と、ターゲットデバイス（例えば、画像形成装置）３０とがＵＳＢケーブル２０で接続された構成を備える。
【００１９】
ホスト装置１０は、汎用的なコンピュータであり、例えば、所有者によって携帯されるノート型ＰＣを一例として挙げることができる。ホスト装置１０には、内部通信路としてのバスを介して、ＣＰＵ（中央処理装置）１１、メモリ１２、ＵＳＢホストコントローラ１３が接続されている。
【００２０】
ＣＰＵ１１は、メモリ１２に格納されたプログラム（ソフトウエア）に従って演算や制御を実行する装置であり、バスを通じて、各装置の動作を制御したり、各装置間あるいは外部との通信を制御したりする。メモリ１２は、記憶装置であり、ＯＳ（オペレーションシステム）、デバイスドライバ、アプリケーションプログラム、各種のデータなどが格納される。なお、、メモリ１２には、ＯＳやデバイスドライバが使用するカーネル領域１２Ａや、アプリケーションプログラムが使用するユーザ領域１２Ｂが構築される。
【００２１】
ＵＳＢホストコントローラ１３は、ＵＳＢ通信を制御し、ＵＳＢケーブル２０を通じてターゲットデバイス３０とのデータの送信及び受信を可能にする通信制御装置である。ＵＳＢホストコントローラ１３は、バッファメモリ１４、ＵＳＢインタフェース（以下、ＵＳＢＩ／Ｆと略記する）１５及び制御部１６を備えている。
【００２２】
バッファメモリ１４は、半導体メモリを用いて構成された先入れ先出し方式の記憶装置であり、入力または出力するデータを一時的に格納する。また、ＵＳＢＩ／Ｆ１５は、ＵＳＢケーブル２０を接続するインタフェースである。制御部１６は、演算処理機能を備え、ＵＳＢホストコントローラ１３を制御する装置である。制御部１６は、ＣＰＵ１４の指示の下、バッファメモリ１４やＵＳＢＩ／Ｆ１５を制御する。この制御部１６には、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）１７が設けられている。ＤＭＡ１７は、バッファメモリ１４とメモリ１２との間のデータ通信を制御する装置であり、ＣＰＵ１１を介在せずに直接的にバッファメモリ１４とメモリ１２との通信制御を行うことができる。
【００２３】
ターゲットデバイス３０は、内部バスに、ＣＰＵ３１、メモリ３２、ＵＳＢターゲットコントローラ３３等が接続された構成を備える。ＣＰＵ３１、メモリ３２は、ＰＣ２０とほぼ同様に構成されており、メモリ３２にカーネル領域３２Ａとユーザ領域３２Ｂとを設けている点も同様である。
【００２４】
また、ＵＳＢターゲットコントローラ３３は、ＵＳＢホストコントローラ１３とほぼ同様にして構成されているが、ＵＳＢ通信におけるターゲットデバイスとして用いられる点で異なる。つまり、ＵＳＢターゲットコントローラ３３では、ＵＳＢＩ／Ｆ３５や制御部３６などが、受信手段として構築されている。
【００２５】
次に、図２を参照しながら、ＵＳＢによる通信について説明する。図２は、ＵＳＢ通信において通信に携わるホスト装置１０とターゲットデバイス３０との機能部を、ソフトウェアとハードウェアとに階層分けして示した図である。図２では、ホスト装置１０及びターゲットデバイス３０の構成を、アプリケーションレベル、デバイスドライバレベル及びハードウエアレベルの三つの階層に分けている。
【００２６】
ホスト装置１０においては、アプリケーションレベルは、アプリケーション１０１のプログラムによって構成される。また、デバイスドライバレベルは、汎用的な上位ドライバとしてのクラスドライバ１０２と、ＡＰＩ（Application Program Interface）１０３と、ホストコントロール／バスドライバ１０４によって構成される。ＡＰＩ１０３は、クラスドライバ１０２と、ホストコントロール／バスドライバ１０４とをつなぐソフトウェアである。また、ホストコントロールドライバは、ＵＳＢホストコントローラ１３を抽象化したドライバであり、バスドライバは、ＵＳＢ固有のプロトコルを実装するドライバである。また、ハードウェアレベルは、図１で説明したＵＳＢホストコントローラ１３によって構成される。
【００２７】
ターゲットデバイス３０は、アプリケーションレベルは、アプリケーション１０８のプログラムによって構成される。また、デバイスドライバレベルは、Ｈ／Ｗ（ハードウエア）非依存部１０７と、ＡＰＩ１０６と、Ｈ／Ｗ依存部１０５とによって構成される。また、ハードウェアレベルは、図１で説明したＵＳＢターゲットコントローラ３３によって構成される。
なお、デバイスドライバレベルにおいて、Ｈ／Ｗ非依存部１０７とＨ／Ｗ依存部１０５に分離しているのは、ＵＳＢターゲットコントローラ３３を別のものに取り替えた場合の影響を少なくすることを考慮したためであるが、もちろん、両者を一体化することも可能である。また、ＡＰＩ１０６は、Ｈ／Ｗ非依存部１０７と、Ｈ／Ｗ依存部１０５とをつなぐソフトウェアである。
【００２８】
ＵＳＢでは、デフォルトタイプのコントロール転送の他に、大容量データを転送するためのバルク転送、小容量データを周期的に転送するためのインタラプト転送、一定時間内の転送データ量が補償されたアイソクロナス転送が定められている。以下では、バルク転送をホストからターゲットに行うバルクアウト転送をＨＳモードで行う例について説明する。
【００２９】
ホスト装置１０のアプリケーション１０１が、通信対象となるデータをターゲットデバイス３０のアプリケーション１０８にバルクアウト送信する場合には、まず、アプリケーション１０１からクラスドライバ（プリンタクラスなど）１０２にデータが転送される。続いて、クラスドライバ１０２が、ＡＰＩ１０３を介してホストコントロール／バスドライバ１０４にデータを転送する。そして、ホストコントロール／バスドライバ１０４は、ＵＳＢ２．０の規格にもとづいて５１２ｂｙｔｅのパケット（これは、データ転送の単位となるデータ要素である）にデータを分割し、ＵＳＢホストコントローラ１３を用いてＯＵＴトランザクションとして送信を行う。
【００３０】
送信される各パケットデータは、ＵＳＢケーブル２０を経由して、ターゲットデバイス３０のＵＳＢターゲットコントローラ３３に到達する。ＵＳＢターゲットコントローラ３３は、パケットデータを受信して、バッファメモリ３４に一時的に格納する。具体的には、バッファメモリ３４は、パケットデータ１個（ＵＳＢ２．０では最大５１２ｂｙｔｅ）を格納できるＦＩＦＯ（先入れ先出し方式の格納部）によって構成されており、ここにパケットデータが格納される。１つのターゲットデバイス３０とホスト装置１０の間には、複数の論理的な通信路(パイプ)を設定することが可能である。各パイプのターゲットデバイス側の端は、エンドポイントと呼ばれ、通常は、物理的にはパケットデータ１個を格納できるＦＩＦＯが設けられる。ＦＩＦＯの個数は固定であってもよいし、変更可能であってもよい。一般的には、ＦＩＦＯの個数が多い方がデータ転送を高速化できる余地が高まる。
【００３１】
ここで、図３を用いて、バルクアウト転送トランザクションにおいて、ＵＳＢホストコントローラ１３とＵＳＢターゲットコントローラ３３との間でやりとりされているパケットのフォーマットを示す。ＵＳＢホストコントローラ１３は、バルクアウト転送の開始を通知するために、まず、ＯＵＴトークンパケット１２０を送信する。これにより、ＵＳＢターゲットコントローラ３３は、これから行われる転送がバルクアウト転送であることを認識し、バルクアウト用のエンドポイントにパケットデータを格納するＦＩＦＯを用意する。続いて、ＵＳＢホストコントローラ１３は、ＤＡＴＡ０というパケットデータ１２１を送信する。そして、ＵＳＢターゲットコントローラ３３は、ＤＡＴＡ０のパケットデータを受信して、このパイプのエンドポイントに設けられたＦＩＦＯに格納する。この時点では、２つのＦＩＦＯのうち、他方のＦＩＦＯは使用可能である。そこで、ＵＳＢターゲットコントローラ３３は、次のパケットデータ１２１を受信できる旨を示すＡＣＫハンドシェーク１２４をＵＳＢホストコントローラ１３に送信する。 ＵＳＢホストコントローラ１３は、ＡＣＫハンドシェーク１２４を受信すると、引き続きＯＵＴトークンパケット１２０と、ＤＡＴＡ１というパケットデータ１２１を送信する。そして、ＵＳＢターゲットコントローラ３３は、このパケットデータ１２１を受信して、他方のＦＩＦＯに格納する。
【００３２】
この段階で、先にＤＡＴＡ０のパケットデータ１２１を格納したＦＩＦＯが空である場合、つまり後段の装置に既にデータ転送が行われており、新たなるケットデータパが格納可能な状況にある場合には、ＵＳＢターゲットコントローラ３３は、次のパケットデータ１２１を受信可能である旨を示すＡＣＫハンドシェーク１２４を送信する。他方、先にＤＡＴＡ０のパケットデータ１２１を格納したＦＩＦＯが使用中である場合、つまり後段の装置にデータ転送が行われていない場合には、ＵＳＢターゲットコントローラ３３は、次のパケットデータを受信できない旨を表すＮＹＥＴハンドシェーク１２３をＵＳＢホストコントローラ１３に送信する。
【００３３】
図４は、ＵＳＢホストコントローラ１３が、ＮＹＥＴハンドシェーク１２３を受信した場合のパケットのやりとりを示す図である。この場合、ＵＳＢホストコントローラ１３は、ＯＵＴトークンパケット１２０の代わりにＰＩＮＧトークンパケット１２７を発行する。そして、ＵＳＢターゲットコントローラ３３は、ＤＡＴＡ０のパケットデータ１２１を保持するＦＩＦＯが使用不可能な場合にはＮＡＫハンドシェーク１２５を、使用可能な場合にはＡＣＫハンドシェーク１２４をＵＳＢホストコントローラ１３に送信する。ＵＳＢホストコントローラ１３は、ＡＣＫハンドシェーク１２４を受信した場合には、ＯＵＴトランザクションを再開するために、図３に示したＯＵＴトークンパケット１２０を発行する。他方、ＵＳＢホストコントローラ１３は、ＮＡＫハンドシェーク１２５を受信した場合には、再びＰＩＮＧトークンパケット１２７を発行する。このＰＩＮＧトークンパケット１２７の発行は、ＵＳＢターゲットコントローラ３３からＡＣＫハンドシェーク１２４を受信するまで継続される。なお、ＵＳＢターゲットコントローラ３３は、動作不能な状態のときにはＳＴＡＬＬハンドシェーク１２６を返信する。ここで説明した各ハンドシェークは、ターゲットデバイスとホストとの間で、コネション型の通信を行う（対話的に通信を行う）ためのパケットである。
【００３４】
次に、図５を参照しながら、パケットデータを受信した後のターゲットデバイス３０内でのパケットデータの流れについて説明する。図５は、ホスト装置１０からターゲットデバイス３０に、ＨＳモードのバルクアウト転送（パケットデータは５１２ｂｙｔｅ）でデータ転送が行われる場合に、ターゲットデバイス３０内でのパケットデータの処理の流れを示した図である。
【００３５】
ＵＳＢターゲットコントローラ３３のＵＳＢＩ／Ｆ３５で受信されたパケットデータは、パケットデータ毎に、エンドポイントに設定されたＦＩＦＯ３４１、３４２のいずれかに一時的に格納される。ＦＩＦＯ３４１、３４２は、ＵＳＢターゲットコントローラ３３内のバッファメモリ３４に確保された領域である。
【００３６】
ＦＩＦＯ３４１、３４２に格納されたパケットデータは、ＵＳＢターゲットコントローラ３３内のＤＭＡ３７によって、メモリ３２内のカーネル領域３２Ａに転送される。カーネル領域３２Ａには、ＦＩＦＯ３４１、３４２から転送されるパケットデータを一時的に格納するため、３つのバッファ３２１、３２２、３２３が確保されている。
【００３７】
バッファ３２１、３２２、３２３は、アプリケーション１０８からのリクエストによって、カーネル領域３２Ａ内に用意される。このうち、バッファ３２１、３２２は、パケットを格納できる使用可能な有効領域のサイズ（以下、有効メモリサイズと呼ぶ）を変更することができる。例えば、カーネル領域３２Ａ内に用意されたバッファ３２１のサイズ（以下、オリジナルサイズと呼ぶ）をそれぞれ４Ｋｂｙｔｅとすると、バッファ３２１は、そのうちの５１２ｂｙｔｅを有効メモリサイズとしている。このバッファ３２１の有効メモリサイズである５１２ｂｙｔｅは、本実施例では、ＵＳＢ２．０を想定しているため、データ転送されるパケットデータ１個の最大サイズと等しい値である。バッファ３２１の有効メモリサイズは、データ転送されるパケットデータ１個の最大サイズに応じて変更される。
【００３８】
また、バッファ３２２の有効メモリサイズは、パケットデータ１個の最大サイズの整数倍（すなわち、５１２ｂｙｔｅ×整数）としている。本実施例では、バッファ３２２の有効領域のサイズは、オリジナルサイズの４Ｋｂｙｔｅから、バッファ３２１の有効メモリサイズ（又は、パケットデータ１個の最大サイズ）である５１２ｂｙｔｅを差し引いた約３．５Ｋｂｙｔｅとしている。
また、バッファ３２３の有効メモリサイズは、カーネル領域３２Ａ内に用意されたオリジナルサイズの４Ｋｂｙｔｅとしている。
【００３９】
カーネル領域３２Ａに格納されたパケットデータは、ユーザ領域３２Ｂに確保されたバッファ３２５に転送される。バッファ３２５は、ホスト装置１０から送信されるデータ全体を格納できるサイズを持っており、ここで各パケットデータの統合が行われる。こうして復元されたデータは、アプリケーション１０８によって管理・利用されることになる。カーネル領域３２Ａからユーザ領域３２Ｂへのパケットデータの転送は、ＣＰＵ３１によって行われる。
【００４０】
図５においては、カーネル領域３２Ａ内に３つのバッファ３２１、３２２、３２３を設ける例を示した。しかし、カーネル領域３２Ａ内に設けるバッファの数及びサイズ（オリジナルサイズ及び有効メモリサイズ）は、動的に変更可能である。
【００４１】
図６は、ターゲットデバイス３０内における内部処理の流れを、図２に示したソフトウエア及びハードウエアの構造と関連づけて説明する図である。
Ｈ／Ｗ非依存部１０７は、ｉｏｃｔｌ（）及びｒｅａｄ（）などの一般的なシステムコールのルーチンを管理しており、これらのルーチンがアプリケーション１０８から呼び出された場合には、ＡＰＩ１０６を通じて、Ｈ／Ｗ依存部１０５に、対応する処理を命じる。ここで、ｉｏｃｔｌ（）は、カーネル領域３２Ａに設けるバッファの個数及びサイズを設定するためのファンクションをサポートするルーチンであり、ｒｅａｄ（）は、データの読み込みを行うためのルーチンである。
【００４２】
アプリケーション１０８は、まず、ｉｏｃｔｌ（）の引数にファンクション値とファンクション値の属性値を設定し、タイムアウト時間と、バッファの個数及びサイズ（オリジナルサイズ及び有効メモリサイズ）を設定する。そして、ｉｏｃｔｌ（）は、設定されたバッファの個数と同数のＩＯリクエスト構造体（以下、簡単に、ＩＯリクエストと呼ぶ場合もある）を生成する（図６に示すＩＯリクエストａ、ｂ、ｃ）。なお、図６に示すＩＯリクエストａによって、図５に示すカーネル領域３２Ａに、有効メモリサイズが５１２ｂｙｔｅのバッファ３２１が設定されるものとする。同様にして、ＩＯリクエストｂによって、図５に示すカーネル領域３２Ａに、有効メモリサイズが約３．５Ｋｂｙｔｅのバッファ３２２が設定されるものとし、ＩＯリクエストｃによって、図５に示すカーネル領域３２Ａに、有効メモリサイズが４Ｋｂｙｔｅのバッファ３２３が設定されるものとする。なお、タイムアウト時間については、後述する。
【００４３】
図７は、ＩＯリクエスト構造体２１０について説明する図である。ＩＯリクエスト構造体２１０は、カーネル領域３２Ａに確保されるバッファ毎に設定される構造体であり、バッファへのポインタ２１２、バッファのオリジナルサイズ２１４、バッファの有効サイズ２１６、コールバックルーチンへのポインタ２１８、データサイズ２２０、及びリストポインタ２２２の各フィールドをもつ。バッファへのポインタ２１２は、このＩＯリクエスト構造体２１０によってカーネル領域３２Ａに確保されるバッファ３２１（３２２、３２３）のアドレスを表す。バッファのオリジナルサイズ２１４は、このＩＯリクエスト構造体２１０によってカーネル領域３２Ａに確保されるバッファ３２１（３２２、３２３）のオリジナルのサイズを表す。バッファ３２１、３２２、３２３のオリジナルサイズは、すべて４Ｋｂｙｔｅに設定されている。また、バッファの有効サイズ２１６は、カーネル領域３２Ａに用意されたバッファ３２１（３２２、３２３）のオリジナルサイズのうち、実際に使用（パケットデータを格納）する有効メモリサイズを表す。また、コールバックルーチンへのポインタ２１８は、Ｈ／Ｗ依存部１０５からＩＯリクエストが完了した旨の通知をもらうために設定されるアドレスである。そして、データサイズ２２０は、実際にバッファに格納されるデータのサイズを表し、リストポインタ２２２は、複数のＩＯリクエスト構造体２１０の並びを制御するために設定される。
【００４４】
Ｈ／Ｗ非依存部１０７において、ｉｏｃｔｌ（）は、ＩＯリクエスト構造体２１０の各フィールドに値を設定する。このとき、リストポインタ２２２はＮＵＬＬで初期化され、データサイズ２２０は０で初期化される。また、ｉｏｃｔｌ（）からの指示に基づいて、Ｈ／Ｗ依存部１０５が管理するリクエスト待ちキューがＮＵＬＬで初期化される。
【００４５】
ホスト装置１０からのデータを受信する場合、図６で示すようにアプリケーション１０８は、Ｈ／Ｗ非依存部１０７が提供するｒｅａｄ（）をコールする。すると、Ｈ／Ｗ非依存部１０７は、バッファの個数分のＩＯリクエストをＡＰＩ１０６を通じて、Ｈ／Ｗ依存部１０５に対し順次発行する。Ｈ／Ｗ依存部１０５は、発行されたＩＯリクエストを順次処理するためにＩＯリクエスト待ちキューを管理しており、発行されたＩＯリクエストに対応するＩＯリクエスト構造体２１０を順次ＩＯリクエスト待ちキューにつなぐ処理を行う。図８は、この様子を説明する図であり、発行された３個のＩＯリクエスト２４０，２４２，２４４（ＩＯリクエスト２４０が図６に示すＩＯリクエストａに該当し、ＩＯリクエスト２４２が図６に示すＩＯリクエストｂに該当し、ＩＯリクエスト２４４が図６に示すＩＯリクエストｃに該当する）がＩＯリクエスト待ちキュー２４６につながれている。
【００４６】
ＤＭＡ３７は、バッファメモリ３４に設けられたＦＩＦＯ３４１あるいはＦＩＦＯ３４２に格納されたパケットデータを、ＩＯリクエスト待ちキュー２４６の先頭のＩＯリクエストによってカーネル領域３２Ａに用意されたバッファ３２１に転送する。そして、バッファ３２１への転送が完了すると、ＵＳＢターゲットコントローラ３３の制御部３６からＣＰＵ３１へインタラプトが通知され、ＣＰＵ３１はそのインタラプトの内容からＨ／Ｗ依存部１０５のインターラプトハンドラ（Ｈ／Ｗ依存部１０５に含まれるルーチン）に、パケットデータが格納されたことを通知する。Ｈ／Ｗ依存部１０５は、インターラプトハンドラで、制御部３６からの通知を受け付けると、ＩＯリクエスト待ちキュー２４６の先頭のＩＯリクエストを、ＩＯリクエスト完了キュー２５０の最後尾につなげる。Ｈ／Ｗ依存部１０５は、ＩＯリクエスト完了キュー２５０につながれたＩＯリクエストを、ＩＯリクエスト完了キュー２５０につながれた順番に処理する。Ｈ／Ｗ依存部１０５は、ＩＯリクエスト完了キュー２５０につながれたＩＯリクエスト構造体に設定されたコールバックルーチンへのポインタ２１８に従って、Ｈ／Ｗ非依存部１０７のコールバックルーチンをコールする。
【００４７】
続いて、コールされたＨ／Ｗ非依存部１０７のコールバックルーチンは、図９に示すＩＯリクエスト完了キュー２５０をチェックする。そして、ＩＯリクエスト完了キュー２５０の先頭のＩＯリクエストをキューから外し、先頭のＩＯリクエストのバッファへのポインタ２１２に設定されたバッファ（例えば、ＩＯリクエストａであればバッファ３２１、ＩＯリクエストｂであればバッファ３２２、ＩＯリクエストｃであればバッファ３２３）から、ユーザ領域３２Ｂのバッファ３２５へ、ＩＯリクエストのデータサイズ２２０に設定されたサイズのパケットデータをコピーする。また、Ｈ／Ｗ非依存部１０７のコールバックルーチンは、コピーしたパケットデータのサイズがバッファ３２１（３２２、３２３）の有効メモリサイズと等しいかどうかをチェックする。まず、コピー元であるバッファ３２１（３２２、３２３）の有効メモリサイズと、ユーザ領域３２Ｂのバッファ３２５へコピーしたパケットデータのサイズとが一致しなかった場合（すなわち、コピーしたパケットデータのサイズである５１２ｂｙｔｅの整数倍ではなかった場合（以下、この場合をショートパケットと呼ぶ）、Ｈ／Ｗ非依存部１０７のコールバックルーチンは、ホスト装置１０から送信されたパケットデータはもう存在しないと判定し、ＩＯリクエストの取消処理を行い、ＩＯリクエスト待ちキュー２４６に繋がれている不要なＩＯリクエストを外す。また、ホスト装置１０から受信したパケットデータがヌルパケットであった場合にも、コールバックルーチンは、ホスト装置１０から送信されたパケットデータはもう存在しないと判定し、ＩＯリクエストの取消処理を行い、ＩＯリクエスト待ちキュー２４６につながれている不要なＩＯリクエストを外す。
【００４８】
他方、コピーしたパケットデータのサイズが、バッファ３２１（３２２、３２３）の有効メモリサイズに等しい場合、コールバックルーチンは、ホスト装置１０からのパケットデータがまだ存在すると判定し、使用済みとなったＩＯリクエストを使用してＩＯリクエストを再度発行し、再度待ち状態に入る前にＩＯリクエスト完了キュー２５０をチェックする。以降、同様な処理を繰り返す。
【００４９】
ここで、タイムアウト時間について図６を参照しながら説明する。
タイムアウト時間は、Ｈ／Ｗ非依存部１０７がＩＯリクエストを発行してから、Ｈ／Ｗ非依存部１０７のコールバックルーチンがコールされるまでの時間である。但し、タイムアウト時間の計時開始タイミングに、ＩＯリクエストａ，ｂ，ｃの発行タイミングは含まれていない。すなわち、ＩＯリクエストａ，ｂ，ｃに後続するＩＯリクエストｄ，ｅ，ｆ・・の発行タイミングが、タイムアウト時間の計時開始タイミングとなる。ＩＯリクエストａが対象となっていないのは、最初に発行されるＩＯリクエストａのタイムアウト時間を無限時間に設定しているからである。ＩＯリクエストａのタイムアウト時間を無限時間に設定しているのは、ホスト装置１０側が、いつパケットデータの送信を開始するのかはターゲットデバイス３０側では分からないためである。また、ＩＯリクエストｂ，ｃは、ＩＯリクエストａと一緒に発行され、ＩＯリクエスト待ちキュー２４６にＩＯリクエストａと共に接続されているからである。なお、タイムアウト時間の計時終了に、ＩＯリクエストａが含まれないのも、ＩＯリクエストａは、タイムアウト時間を無限時間に設定しているからである。
図６に示すＩＯリクエストを参照して、タイムアウト時間についてより詳細に説明する。バッファ３２１に、バッファ３２１の有効メモリサイズ分のパケットデータが格納されると、ＩＯリクエストａがＩＯリクエスト完了キュー２５０につながれ、次のＩＯリクエスト構造体であるＩＯリクエストｂがＩＯリクエスト待ちキュー２４６の先頭に接続される。そして、Ｈ／Ｗ依存部１０５によって、Ｈ／Ｗ非依存部１０７のコールバックルーチンがコールされると、Ｈ／Ｗ非依存部１０７は、使用済みとなったＩＯリクエスト構造体を使用してＩＯリクエストを再度発行する。このＩＯリクエストをＩＯリクエストａと区別するため、便宜上、ＩＯリクエストｄと呼ぶ。Ｈ／Ｗ非依存部１０７は、ＩＯリクエストｄを発行した段階で、タイムアウト時間の計時を開始する。そして、バッファ３２２に、バッファ３２２の有効メモリサイズ分のパケットデータが格納され、ＩＯリクエストｂがＩＯリクエスト完了キュー２５０につながれ、Ｈ／Ｗ依存部１０５によって、Ｈ／Ｗ非依存部１０７のコールバックルーチンがコールされるまでの時間（図６参照）がタイムアウト時間である。このタイムアウト時間をオーバーした場合、タイムアウト時間を経過しても、Ｈ／Ｗ依存部１０５がコールバックルーチンをコールすることがないので、Ｈ／Ｗ非依存部１０７は、ホスト装置１０から送信されたパケットデータはもう存在しないと判定し、ＩＯリクエストの取消処理を行い、ＩＯリクエスト待ちキュー２４６に繋がれている不要なＩＯリクエストを外す。
なお、タイムアウト時間は、バッファ３２２、３２３、３２１に、各バッファの有効メモリサイズのパケットデータが格納されるまでにかかる時間ということができる。例えば、バッファ３２３へのパケットデータの格納が完了して、コールバックルーチンがコールされているのに、次のバッファであるバッファ３２１へのパケットデータの格納が完了せず、コールバックルーチンがコールされない場合に、Ｈ／Ｗ非依存部１０７は、ホスト装置１０から送信されたパケットデータはもう存在しないと判定する。
【００５０】
次に、バッファ３２１、３２２の有効メモリサイズについて説明する。
ホスト装置１０から送信されるパケットデータを最初に格納するカーネル領域３２Ａのバッファ３２１の有効メモリサイズは、初期状態では、５１２ｂｙｔｅに設定している。例えば、最初にパケットデータを格納するバッファの有効メモリサイズを４Ｋｂｙｔｅとした場合、この４Ｋｂｙｔｅよりも小さく、かつ最大転送サイズである５１２ｂｙｔｅの整数倍のパケットを受信してバッファ３２１に格納すると、後続してパケットデータを受信したり、ヌルパケットを受信しない限り、ターゲットデバイス３０側は、無限にパケットデータの受信を待つことになってしまう。しかし、バッファ３２１の有効メモリサイズをＵＳＢ２．０の最大転送サイズである５１２ｂｙｔｅに設定しておくことで、ターゲットデバイス３０側では、パケットデータを受信して、受信したパケットデータがバッファ３２１に格納されると、ＣＰＵ３１経由でＨ／Ｗ依存部１０５に通知が行き、パケットデータの受信が認識可能となる。また、ＣＰＵ３１が所定時間ごとにポーリングでパケットデータの受信状態を監視しなくても、５１２ｂｙｔｅのパケットデータがバッファ３２１に格納されるとＵＳＢターゲットコントローラ３３の制御部３６から通知があるので、ＣＰＵ３１はホスト装置１０からのパケットデータの受信を認識可能となる。
【００５１】
また、バッファ３２１の次にパケットデータを格納するバッファ３２２の有効メモリサイズは、バッファ３２１（３２２、３２３）のオリジナルサイズである４Ｋｂｙｔｅから５１２ｂｙｔｅを差し引いた約３．５Ｋｂｙｔｅとしている。このため、バッファ３２１とバッファ３２２に格納されるパケットデータのデータサイズは、合わせて４Ｋｂｙｔｅになる。また、バッファ３２２の次にパケットデータを格納するバッファ３２３の有効メモリサイズも、オリジナルサイズの４Ｋｂｙｔｅとし、さらに、バッファ３２１とバッファ３２２は、一度、有効メモリサイズのパケットデータを格納し、パケットデータがユーザ領域３２Ｂに読み出された後は、バッファ３２１とバッファ３２２の有効メモリサイズは、それぞれオリジナルサイズの４Ｋｂｙｔｅに設定される。
ユーザ領域３２Ｂのバッファ３２５のサイズは、バッファ３２１、３２２、３２３のオリジナルサイズの整数倍に設定されている。そして、パケットデータの受信開始時にだけ、バッファ３２１とバッファ３２２とに格納されるパケットデータの和が４Ｋｂｙｔｅとし、それ以降は、バッファ３２１、３２２、３２３からバッファ３２５に送られるパケットデータのサイズを４Ｋｂｙｔｅで揃えておく。このように処理することで、パケットデータを、バッファ３２１、３２２、３２３のいずれかからバッファ３２５に転送しているときに、この転送しているバッファ３２１（３２２、３２３）にパケットデータを残した状態で、バッファ３２５が満杯になってしまうことがない。
【００５２】
図１０に示すフローチャートに沿って、カーネル領域３２Ａのバッファ設定処理の手順を、図６を参照しながら説明する。
まず、アプリケーション１０８は、デバイスドライバのＨ／Ｗ非依存部１０７が提供するｉｏｃｔｌ（）をコールし、このｉｏｃｔｌ（）にタイムアウト時間を設定する（ステップＳ１）。なお、タイムアウト時間は、パケットデータを格納する順番が２番目以降のバッファ（すなわち、バッファ３２２、バッファ３２３、バッファ３２１、バッファ３２２、・・・）に、有効メモリサイズ分のパケットデータが格納されるまでにかかる時間である。より詳細には、タイムアウト時間は、Ｈ／Ｗ非依存部１０７で、各ＩＯリクエストｄ，ｅ，ｆ・・・が発行されてから、ＩＯリクエストｂ，ｃ，ｄ・・・がＩＯリクエスト完了キュー２５０に接続され、Ｈ／Ｗ非依存部１０７のコールバックルーチンがコールされるまでの時間（図６参照）である。なお、一番最初にパケットデータを格納するバッファ３２１は、タイムアウト時間なしに無限にホスト装置１０からのパケットデータの受信を待つ。
【００５３】
次に、アプリケーション１０８は、デバイスドライバのＨ／Ｗ非依存部１０７が提供するＲｅａｄ（）をコールする。アプリケーション１０８によってＲｅａｄ（）がコールされると、Ｈ／Ｗ非依存部１０７は、図６に示すＩＯリクエストａ，ｂ，ｃをデバイスドライバのＨ／Ｗ依存部１０５に対して発行する（ステップＳ２）。ＩＯリクエストａ，ｂ，ｃがＨ／Ｗ依存部１０５に発行されることで、Ｈ／Ｗ依存部１０５は、カーネル領域３２Ａにバッファ３２１、３２２、３２３を用意する。すなわち、ＩＯリクエストａによって、カーネル領域３２Ａにバッファ３２１が用意され、ＩＯリクエストｂによって、カーネル領域３２Ａにバッファ３２２が用意され、ＩＯリクエストｃによって、カーネル領域３２Ａにバッファ３２３が用意される。ＩＯリクエストａ，ｂ，ｃは、それぞれＩＯリクエスト待ちキュー２４６に登録される。ホスト装置１０から送られるパケットデータを格納する順番は、バッファ３２１、バッファ３２２、バッファ３２３の順番であるので、ＩＯリクエスト待ちキュー２４６にも、ＩＯリクエストａ，ＩＯリクエストｂ，ＩＯリクエストｃの順番で登録される。最初にパケットデータを格納するバッファ３２１は、タイムアウト時間なしに無限にホスト装置１０からのパケットデータの受信を待つ（ステップＳ３）。
【００５４】
ホスト装置１０がバルクアウト転送を開始し、バッファ３２１に最初のパケットデータが格納されると、ＵＳＢターゲットコントローラ３３の制御部３６からＣＰＵ３１経由でＨ／Ｗ依存部１０５のインターラプトハンドラにパケットデータが格納されたことが通知される。Ｈ／Ｗ依存部１０５は、インターラプトハンドラで制御部３６からの通知を受け付けると、ＩＯリクエストａをＩＯリクエスト待ちキュー２４６からＩＯリクエスト完了キュー２５０に移動させる。また、Ｈ／Ｗ依存部１０５は、図７に示すＩＯリクエスト構造体の“コールバックルーチンへのポインタ”２１８で設定されている、Ｈ／Ｗ非依存部１０７のコールバックルーチンをコールする。Ｈ／Ｗ依存部１０５がコールバックルーチンをコールすることで、ＣＰＵ３１は、バッファ３２１に格納されたパケットデータを読み出して、ユーザ領域３２Ｂのバッファ３２５に格納する（ステップＳ４）。
【００５５】
次に、Ｈ／Ｗ非依存部１０７は、ユーザ領域３２Ｂのバッファ３２５に格納したパケットデータがショートパケットであるか否かを判定する（ステップＳ５）。Ｈ／Ｗ非依存部１０７は、パケットデータのデータサイズが、最大パケット転送サイズである５１２ｂｙｔｅの整数倍ではないショートパケットであった場合には（ステップＳ５／ＹＥＳ）、未使用のＩＯリクエストｂ，ｃの取り消しや、Ｒｅａｄ（）の完了処理を行い（ステップＳ６）、バルクアウト転送を終了させる。また、Ｈ／Ｗ非依存部１０７は、パケットデータがヌルパケットであった場合にも、未使用のＩＯリクエストｂ，ｃの取り消しや、Ｒｅａｄ（）の完了処理を行い（ステップＳ６）、バルクアウト転送を終了させる。
【００５６】
また、ユーザ領域３２Ｂのバッファ３２５に新たに格納されたパケットデータのデータサイズが、最大パケット転送サイズである５１２ｂｙｔｅの整数倍のデータサイズであった場合（ステップＳ５／ＮＯ）、Ｈ／Ｗ非依存部１０７は、バッファ３２１の有効メモリサイズがオリジナルサイズ（４Ｋｂｙｔｅ）であるか否かを判定する（ステップＳ７）。最初、バッファ３２１の有効メモリサイズは、５１２ｂｙｔｅに設定されているので（ステップＳ７／ＮＯ）、Ｈ／Ｗ非依存部１０７は、バッファ３２１の有効メモリサイズを５１２ｂｙｔｅからオリジナルサイズの４Ｋｂｙｔｅに変更（ステップＳ８）したＩＯリクエストｄ（図６参照）をデバイスドライバのＨ／Ｗ依存部１０５に発行する（ステップＳ９）。ＩＯリクエストｄがＨ／Ｗ依存部１０５に発行されることで、Ｈ／Ｗ依存部１０５は、カーネル領域３２Ａに、バッファ３２１を４Ｋｂｙｔｅで用意させる。すなわち、パケットデータの格納が終わったバッファ３２１は、格納したパケットデータのユーザ領域３２Ｂへの転送が終了すると、有効メモリサイズ等を新たに設定されて、メモリ３２のカーネル領域３２Ａに再度、用意される。
【００５７】
その後、後続するパケットデータがバッファ３２２に格納され、バッファ３２２の有効メモリサイズを満たすと、バッファ３２１の場合と同様に、ＵＳＢターゲットコントローラ３３の制御部３６からＣＰＵ３１経由でＨ／Ｗ依存部１０５のインターラプトハンドラにパケットデータが格納されたことが通知される。Ｈ／Ｗ依存部１０５は、インターラプトハンドラで制御部３６からの通知をＣＰＵ３１経由で受け、ＩＯリクエストｂをＩＯリクエスト待ちキューらＩＯリクエスト完了キューに移動させる。また、Ｈ／Ｗ依存部１０５は、図７に示すＩＯリクエスト構造体の“コールバックルーチンへのポインタフィールド”で設定されている、Ｈ／Ｗ非依存部１０７のコールバックルーチンをコールする（ステップＳ１０）。Ｈ／Ｗ依存部１０５がコールバックルーチンをコールすることで、ＣＰＵ３１は、バッファ３２１に格納されたパケットデータを読み出して、ユーザ領域３２Ｂのバッファ３２５に格納する（ステップＳ４）。この後、同様にして、Ｈ／Ｗ非依存部１０７は、ユーザ領域３２Ｂのバッファ３２５に新たに格納されたパケットデータがショートパケットであるか否かを判定する（ステップＳ５）。ユーザ領域３２Ｂのバッファ３２５に新たに格納されたパケットデータのデータサイズが、最大パケット転送サイズである５１２ｂｙｔｅの整数倍のデータサイズであった場合（ステップＳ５／ＮＯ）、Ｈ／Ｗ非依存部１０７は、バッファ３２２のサイズが最大サイズであるか否かを判定する（ステップＳ７）。最初、バッファ３２２のサイズは、最大サイズである４Ｋｂｙｔｅではなく、最大サイズである４Ｋｂｙｔｅから５１２ｂｙｔｅを差し引いた、約３．５Ｋｂｙｔｅに設定されている（ステップＳ７／ＮＯ）。そこで、Ｈ／Ｗ非依存部１０７は、バッファ３２１の有効メモリサイズをオリジナルサイズの４Ｋｂｙｔｅに変更（ステップＳ８）したＩＯリクエストｅ（図６参照）をデバイスドライバのＨ／Ｗ依存部１０５に発行する（ステップＳ９）。ＩＯリクエストｅがＨ／Ｗ依存部１０５に発行されることで、Ｈ／Ｗ依存部１０５は、カーネル領域３２Ａにバッファ３２２を４Ｋｂｙｔｅで用意させる。
これ以後、バッファ３２１、３２２、３２３の有効メモリサイズは、４Ｋｂｙｔｅとなり、バッファ３２１、３２２、３２３に、４Ｋｂｙｔｅのパケットデータが格納されるごとに、Ｈ／Ｗ依存部１０５、Ｈ／Ｗ非依存部１０７を介してアプリケーション１０８のユーザ領域３２Ｂに４Ｋｂｙｔｅのパケットデータが転送される。
【００５８】
また、ステップＳ１０において、ＩＯリクエスト（例えば、図６に示すＩＯリクエストｇ）が発行されてから、タイムアウト時間を経過してもＨ／Ｗ非依存部１０７のコールバックルーチンがコールされない場合（ステップＳ１１／ＹＥＳ）、未使用のＩＯリクエストの取り消しや、Ｒｅａｄ（）の完了処理を行い（ステップＳ６）、バルクアウト転送を終了させる。
【００５９】
上述した実施例は、本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施が可能である。
【符号の説明】
【００６０】
１０  ホスト装置
１１  ＣＰＵ
１２  メモリ
１３  ＵＳＢホストコントローラ
３０  ターゲットデバイス
３１  ＣＰＵ（制御装置）
３２  メモリ
３３  ＵＳＢターゲットコントローラ
３６  制御部（通知手段）
１０１、１０８  アプリケーション
１０２  クラスドライバ
１０３、１０６  ＡＰＩ
１０４  ホストコントロール／バスドライバ
１０５  Ｈ／Ｗ依存部
１０７  Ｈ／Ｗ非依存部
３２１  バッファ（第１メモリ）
３２２  バッファ（第２メモリ）
３２３  バッファ（第３メモリ）
３２５  バッファ
【図１】
2011198314.tif 000003
【図２】
2011198314.tif 000004
【図３】
2011198314.tif 000005
【図４】
2011198314.tif 000006
【図５】
2011198314.tif 000007
【図６】
2011198314.tif 000008
【図７】
2011198314.tif 000009
【図８】
2011198314.tif 000010
【図９】
2011198314.tif 000011
【図１０】
2011198314.tif 000012