(57)【要約】【課題】ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスから転送されてくるデータを適切に受信可能なＵＳＢホスト装置の提供。【解決手段】ＵＳＢホスト装置は、ＳＣＳＩリードコマンドが発行された場合（Ｓ１０１：はい）、１コマンドに対応してＵＳＢホストコントローラ自身が受け取り可能な最大セクタ数を取得し（Ｓ１０３）、リードコマンドで指定されたリードセクタ数が最大セクタ数を超えていれば（Ｓ１０５：超えている）、リードコマンドの分割を実行する（Ｓ１０７）。その結果、基となったＳＣＳＩリードコマンドに対応する複数のＳＣＳＩリードコマンドがＵＳＢストレージデバイスに伝達され、ＵＳＢストレージデバイスからは、分割されたコマンドに対応するデータが順次転送されることになる。【選択図】図３
2012048309.tif 000002
【特許請求の範囲】
【請求項１】
ＵＳＢ（Universal Serial Bus）デバイスと通信可能で、ＵＳＢストレージデバイスから読取対象データを読み取る際には、ＳＣＳＩ（Small Computer System Interface）ドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置であって、
前記ＵＳＢストレージドライバは、
前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、
前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読み取り対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、
前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、
前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、
前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段と
を備えることを特徴とするＵＳＢホスト装置。
【請求項２】
前記データバッファに格納可能なデータのサイズに関する情報を、複数の異なる前記ＵＳＢホストコントローラそれぞれに対応づけて記憶するＵＳＢホストコントローラ情報記憶手段
を備え、
前記ＳＣＳＩコマンド生成手段は、前記ＵＳＢホストコントローラ情報記憶手段に記憶された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定する
ことを特徴とする請求項１に記載のＵＳＢホスト装置。
【請求項３】
前記ＵＳＢホストコントローラのデバイスドライバから、前記データバッファの現在の空き領域サイズに関する情報を取得する空き領域サイズ情報取得手段
を備え、
前記ＳＣＳＩコマンド生成手段は、前記空き領域サイズ情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定する
ことを特徴とする請求項１又は請求項２に記載のＵＳＢホスト装置。
【請求項４】
前記ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に関する情報を取得するデバイス数情報取得手段
を備え、
前記ＳＣＳＩコマンド生成手段は、前記デバイス数情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定する
ことを特徴とする請求項１〜請求項３いずれか一項に記載のＵＳＢホスト装置。
【請求項５】
ＵＳＢ（Universal Serial Bus）デバイスと通信可能で、ＵＳＢストレージデバイスから読取対象データを読み取る際には、ＳＣＳＩ（Small Computer System Interface）ドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置において、前記ＵＳＢホスト装置が備えるコンピュータを前記ＵＳＢストレージドライバとして機能させるためのプログラムであって、
前記コンピュータを、
前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、
前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読み取り対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、
前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、
前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、
前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＳＢ（Universal Serial Bus）規格に準拠した方式で、ＵＳＢストレージデバイスとの通信を行うＵＳＢホスト装置と、ＵＳＢホスト装置が備えるコンピュータをＵＳＢストレージドライバとして機能させるためのプログラムに関する。
【背景技術】
【０００２】
ＵＳＢホスト装置は、ＵＳＢストレージデバイスをＳＣＳＩ（Small Computer System Interface）デバイスとして認識する。そして、ＵＳＢストレージデバイスへのアクセスを行う際には、ＵＳＢホスト装置内においてＳＣＳＩコマンドが発行され、そのＳＣＳＩコマンドがＵＳＢストレージドライバ（ＵＳＢマスストレージクラスドライバ）に渡される（例えば、特許文献１：段落［００２７］参照。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１７１５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ＵＳＢストレージデバイスに対し大量のデータリードを要求するＳＣＳＩリードコマンドが、ＵＳＢホスト装置内において発行された場合、そのようなＳＣＳＩリードコマンドもＵＳＢストレージドライバに渡される。
【０００５】
そして、ＵＳＢストレージドライバは、ＳＣＳＩコマンドに対しＵＳＢ用のヘッダを付加してから、そのリードコマンドをＵＳＢプロトコルスタックに渡し、リードコマンドはＵＳＢプロトコルスタック経由でＵＳＢストレージデバイスへと伝送される。その結果、このようなリードコマンドを受けたＵＳＢストレージデバイスからは、ＵＳＢホスト装置に対し、リード要求に対応する大量のデータが転送されることになる。
【０００６】
しかし、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合、ＵＳＢストレージデバイスから過剰に大量のデータが転送されてくると、そのデータ量がＵＳＢホストコントローラないしＵＳＢプロトコルスタックの受信能力を上回ってしまうことがある。そのため、そのような状況になった場合には、転送されたデータの一部がＵＳＢホスト装置側で失われてしまう、という問題があった。
【０００７】
本発明は、上記問題を解決するためになされたものであり、その目的は、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスから転送されてくるデータを適切に受信することが可能なＵＳＢホスト装置と、そのようなＵＳＢホスト装置が備えるコンピュータをＵＳＢストレージドライバとして機能させるためのプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
以下、本発明において採用した構成について説明する。
請求項１に記載のＵＳＢホスト装置は、ＵＳＢ（Universal Serial Bus）デバイスと通信可能で、ＵＳＢストレージデバイスから読取対象データを読み取る際には、ＳＣＳＩ（Small Computer System Interface）ドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置であって、前記ＵＳＢストレージドライバは、前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読み取り対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段とを備えることを特徴とする。
【０００９】
このように構成されたＵＳＢホスト装置によれば、ＵＳＢストレージドライバは、ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合であっても、読取対象データをいくつかに分割して、分割後の各データそれぞれを読み取るためのＳＣＳＩコマンドを生成する。
【００１０】
そして、それらのＳＣＳＩコマンドそれぞれを、ＵＳＢストレージデバイスに対して順次発行し、各ＳＣＳＩコマンドを発行するごとにデータバッファに格納されるデータを、データバッファから順次取得する。この取得の結果、分割後の各データをすべて取得したら、それら分割後の各データを一括して、ＳＣＳＩコマンドに対する応答としてＳＣＳＩドライバへと転送する。
【００１１】
このような処理を行えば、ひとつのＳＣＳＩコマンドを発行してもデータバッファの容量を上回るデータがＵＳＢストレージデバイスから転送されてくることはない。しかも、各ＳＣＳＩコマンドを発行するタイミングについては、ＵＳＢホスト装置側の処理能力に応じた都合のよいタイミングとすることができる。
【００１２】
したがって、ＵＳＢストレージデバイスに対し大量のデータリードを要求するＳＣＳＩリードコマンドがＵＳＢホスト装置内において発行された際、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスから転送されてくるデータを適切に受信することができる。
【００１３】
請求項２に記載のＵＳＢホスト装置は、請求項１に記載のＵＳＢホスト装置において、前記データバッファに格納可能なデータのサイズに関する情報を、複数の異なる前記ＵＳＢホストコントローラそれぞれに対応づけて記憶するＵＳＢホストコントローラ情報記憶手段を備え、前記ＳＣＳＩコマンド生成手段は、前記ＵＳＢホストコントローラ情報記憶手段に記憶された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定することを特徴とする。
【００１４】
このように構成されたＵＳＢホスト装置によれば、複数の異なるＵＳＢホストコントローラそれぞれで、データバッファに格納可能なデータのサイズが異なっていても、それに応じて読取対象データがより適切な分割数に分割されることになる。
【００１５】
したがって、比較的大きなデータバッファを備えるＵＳＢホストコントローラであるにもかかわらず、データの分割数が過剰に多くなるようなことはない。また、比較的小さなデータバッファを備えるＵＳＢホストコントローラであるにもかかわらず、データの分割数が過剰に少なくなるようなこともない。
【００１６】
請求項３に記載のＵＳＢホスト装置は、請求項１又は請求項２に記載のＵＳＢホスト装置において、前記ＵＳＢホストコントローラのデバイスドライバから、前記データバッファの現在の空き領域サイズに関する情報を取得する空き領域サイズ情報取得手段を備え、前記ＳＣＳＩコマンド生成手段は、前記空き領域サイズ情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定することを特徴とする。
【００１７】
このように構成されたＵＳＢホスト装置によれば、データバッファの現在の空き領域サイズに基づいて、データバッファに格納可能なデータのサイズが決定される。したがって、同じＵＳＢホストコントローラの制御下で、様々なＵＳＢデバイスがそれぞれデータバッファを利用している場合でも、データバッファの現在の空き領域サイズを動的に把握し、その空き領域サイズに応じて読取対象データをより適切な分割数に分割することができる。
【００１８】
請求項４に記載のＵＳＢホスト装置は、請求項１〜請求項３いずれか一項に記載のＵＳＢホスト装置において、前記ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に関する情報を取得するデバイス数情報取得手段を備え、前記ＳＣＳＩコマンド生成手段は、前記デバイス数情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定することを特徴とする。
【００１９】
このように構成されたＵＳＢホスト装置によれば、ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に基づいて、データバッファに格納可能なデータのサイズが決定される。したがって、同じＵＳＢホストコントローラの制御下で、様々なＵＳＢデバイスがそれぞれデータバッファを利用している場合でも、そのようなＵＳＢデバイスの数を動的に把握し、そのＵＳＢデバイス数に応じて読取対象データをより適切な分割数に分割することができる。
【００２０】
請求項５に記載のプログラムは、ＵＳＢ（Universal Serial Bus）デバイスと通信可能で、ＵＳＢストレージデバイスから読取対象データを読み取る際には、ＳＣＳＩ（Small Computer System Interface）ドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置において、前記ＵＳＢホスト装置が備えるコンピュータを前記ＵＳＢストレージドライバとして機能させるためのプログラムであって、前記コンピュータを、前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読み取り対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段として機能させることを特徴とする。
【００２１】
このように構成されたプログラムによれば、ＵＳＢホスト装置が備えるコンピュータを上述した通りのＵＳＢストレージドライバとして機能させ、これにより、このＵＳＢホスト装置では、請求項１に記載した通りの各手段が機能することになる。
【００２２】
したがって、このようなＵＳＢホスト装置であれば、ＵＳＢストレージデバイスに対し大量のデータリードを要求するＳＣＳＩリードコマンドがＵＳＢホスト装置内において発行された際、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスから転送されてくるデータを適切に受信することができる。
【００２３】
なお、請求項５に記載のプログラムは、ＵＳＢホスト装置が備えるコンピュータを、さらに請求項２〜請求項４のいずれか一項に記載の各手段として機能させるプログラムとして構成されていてもよいことはもちろんである。
【図面の簡単な説明】
【００２４】
【図１】ＵＳＢホスト装置を中心に構成されたシステムを示すブロック図。
【図２】ＵＳＢホスト装置内のデータ伝送経路を示すブロック図。
【図３】第一実施形態として例示するＳＣＳＩコマンド処理のフローチャート。
【図４】（ａ）は第一実施形態として例示する最大セクタ数取得処理のフローチャート、（ｂ）は第一実施形態として例示するリードコマンド分割処理のフローチャート。
【図５】第二実施形態として例示するリードコマンド分割処理のフローチャート。
【図６】第三実施形態として例示する最大セクタ数取得処理のフローチャート。
【図７】第四実施形態として例示する最大セクタ数取得処理のフローチャート。
【図８】（ａ）は第四実施形態として例示するＵＳＢデバイス接続検出処理のフローチャート、（ｂ）は第四実施形態として例示するＵＳＢデバイス切断検出処理のフローチャート。
【図９】第五実施形態として例示する最大セクタ数取得処理のフローチャート。
【発明を実施するための形態】
【００２５】
次に、本発明の実施形態について、いくつかの具体的な例を挙げて説明する。
〔１〕第一実施形態
［装置の構成］
図１に示すＵＳＢホスト装置１は、制御部２、補助記憶部３、ＵＳＢインターフェース４、その他の入出力インターフェース５などを備えている。ＵＳＢインターフェース４には、ＵＳＢハブ６を介して、ＵＳＢストレージデバイス７やＵＳＢハンドセット８が接続されている。その他の入出力インターフェース５は、具体的には、ＬＡＮインターフェース、ディスプレイインターフェース、キーボードインターフェース等である。これら各インターフェースには、各インターフェースに対応したその他のデバイス類９（ＬＡＮ、ディスプレイ、キーボードなど）が接続されている。
【００２６】
制御部２は、周知のＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３などを備えてなるマイクロコンピュータによって構成されている。また、補助記憶部３は、ハードディスク装置や不揮発性メモリなどのストレージデバイスによって構成されている。
【００２７】
補助記憶部３には、ディスクデバイスドライバ１５、ＵＳＢホストコントローラドライバ１６、ＵＳＢマスストレージクラスドライバ１７、及びＵＳＢハンドセットドライバ１８に対応するプログラムが格納されている。
【００２８】
これらのプログラムは、ＵＳＢホスト装置１の起動時に、補助記憶部３から制御部２が備えるＲＡＭ１３にロードされ、以降、ＣＰＵ１１がＲＡＭ１３上のプログラムに基づく処理を実行する。これにより、ＵＳＢホスト装置１では、ディスクデバイスドライバ１５、ＵＳＢホストコントローラドライバ１６、ＵＳＢマスストレージクラスドライバ１７、及びＵＳＢハンドセットドライバ１８が機能する状態になる。
【００２９】
ＵＳＢインターフェース４は、ＵＳＢホストコントローラ１９を中心に構成されている。このＵＳＢホストコントローラ１９は、ＰＣＩバスインターフェース、アービター、ＯＨＣＩ（Open Host Controller Interface）ホストコントローラ、ＥＨＣＩ（Enhanced Host Controller Interface）ホストコントローラ、ルートハブ、ＵＳＢ物理層などが１チップ上に集積されたハードウェアである。
【００３０】
さらに、ＵＳＢホスト装置１では、図２に示すように、ＵＳＢプロトコルスタック２１などのソフトウェアが機能している。そして、このＵＳＢプロトコルスタック２１経由で、ＵＳＢマスストレージクラスドライバ１７やＵＳＢハンドセットドライバ１８などのＵＳＢ系ドライバが、ＵＳＢデバイスへのアクセスを行う仕組みになっている。
【００３１】
これらＵＳＢマスストレージクラスドライバ１７、ＵＳＢハンドセットドライバ１８、ＵＳＢホストコントローラ１９、及びＵＳＢプロトコルスタック２１は、それぞれがデータ格納用のバッファ１７Ａ，１８Ａ，１９Ａ，２１Ａを備えている。
【００３２】
ここで、ＵＳＢホスト装置１内でアプリケーションソフトウェアが機能し、その処理の中でＵＳＢストレージデバイス７からのデータリードが行われる場合、ＵＳＢマスストレージクラスドライバ１７には、リード要求が伝達される。
【００３３】
このリード要求は、ＵＳＢホスト装置１のＯＳ（Operating System）が備えるファイルシステム経由で、アプリケーションソフトウェアから伝達されるものである。ファイルシステムは、アプリケーションソフトウェアの発行するファイルリード要求を、セクタ単位でＵＳＢストレージデバイス７にアクセスするためのＳＣＳＩリードコマンドに変換して、そのＳＣＳＩリードコマンドをＵＳＢマスストレージクラスドライバ１７に伝達する。
【００３４】
そして、このＳＣＳＩリードコマンドを受けたＵＳＢマスストレージクラスドライバ１７は、ＳＣＳＩリードコマンドをＵＳＢプロトコルに準拠した方式で送信するため、必要な情報をＳＣＳＩリードコマンドに付加した上で、そのＳＣＳＩリードコマンドをＵＳＢプロトコルスタック２１に渡す。なお、本実施形態においては、ＳＣＳＩリードコマンドを解析して、必要があればＳＣＳＩリードコマンドの分割を行うが、その詳細については後述する。
【００３５】
ＵＳＢプロトコルスタック２１に渡されたＳＣＳＩリードコマンドは、ＵＳＢホストコントローラ１９経由でＵＳＢストレージデバイス７へと伝送される。その結果、このＵＳＢリードコマンドを受けたＵＳＢストレージデバイス７からは、ＵＳＢホスト装置１に対し、リード要求に対応するデータが転送されることになる。
【００３６】
ここで転送されるデータは、まず、ＵＳＢホストコントローラ１９のバッファ１９Ａに格納される。また、このバッファ１９Ａに格納されたデータは、ＵＳＢプロトコルスタック２１やＵＳＢマスストレージクラスドライバ１７などのソフトウェアが機能することにより、順次、バッファ２１Ａ、バッファ１７Ａへと転送され、最終的にはリード要求の発行元となったアプリケーションソフトウェアなどへと転送される。
【００３７】
［ＵＳＢストレージデバイスからのリード処理］
次に、ファイルシステム側のＳＣＳＩドライバから発行されるＳＣＳＩコマンドがＵＳＢマスストレージクラスドライバ１７に伝達されたときに、ＵＳＢマスストレージクラスドライバ１７が実行する処理について、図３，図４（ａ），図４（ｂ）のフローチャートに基づいて説明する。
【００３８】
この処理を開始すると、ＵＳＢマスストレージクラスドライバ１７としての処理を実行するＣＰＵ１１（以下、単にＣＰＵ１１と称する。）は、まず、リードコマンドか否かを判断する（Ｓ１０１）。ここで、リードコマンドであった場合（Ｓ１０１：はい）、１コマンド当たりの最大セクタ数を取得する処理を実行する（Ｓ１０３）。
【００３９】
このＳ１０３の具体的な処理内容は、様々なものを考え得る。ただし、第一実施形態では、特定のＵＳＢホストコントローラ１９を採用したシステムを想定しており、ＵＳＢホストコントローラ１９のバッファ１９Ａのサイズ（パケットバッファ数）が固定値（例えば、６４）としてわかっている。そこで、第一実施形態では、図４（ａ）に示すように、そのような固定値に対して余裕を持ったセクタ数（例えば、パケットバッファ数の１／２）を固定値（例えば、３２）で返す（Ｓ２０１）。
【００４０】
このような最大セクタ数が返されたら、ＣＰＵ１１は、リードセクタ数が最大セクタ数を超えているか否かを判断する（Ｓ１０５）。ここで、リードセクタ数が最大セクタ数を超えていれば（Ｓ１０５：超えている）、そのままリードコマンドを発行すると、最大セクタ数を超えるデータがＵＳＢストレージデバイス７から転送されてくるおそれがある。そこで、ＣＰＵ１１は、リードコマンドの分割を実行する（Ｓ１０７）。
【００４１】
このＳ１０７は、詳しくは図４（ｂ）に示すような処理となる。すなわち、この処理を開始すると、ＣＰＵ１１は、まず、リード開始位置となる先頭セクタ番号を変数Ｔに代入し、リードセクタ数を変数ｎに代入し、最大セクタ数を変数ｍに代入する（Ｓ３０１）。
【００４２】
そして、ＣＰＵ１１は、変数ｎ，ｍについて、ｎ≦ｍか否かを判断する（Ｓ３０３）。ここで、Ｓ１０５ではｎ＞ｍが成立したからこそ図４（ｂ）に示す処理に移行しているので、少なくとも初回はｎ≦ｍではないと判断されることになり（Ｓ３０３：いいえ）、この場合、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｍセクタリードのＳＣＳＩリードコマンドを発行する（Ｓ３０７）。
【００４３】
すなわち、Ｓ３０７では、基となったＳＣＳＩコマンドで要求されたセクタ数ｎではなく、Ｓ１０３で取得した最大セクタ数ｍのＳＣＳＩリードコマンドを発行する。なお、Ｓ３０７で発行するＳＣＳＩリードコマンドは、ＵＳＢプロトコルスタック２１経由でＵＳＢストレージデバイス７にＳＣＳＩコマンドを伝達するためのコマンドである。より具体的には、最大セクタ数ｍのＳＣＳＩリードコマンドに対し、ＵＳＢ規格に準拠したヘッダを付加したものである。
【００４４】
このようなＳＣＳＩコマンドにより、ＵＳＢストレージデバイス７にＳＣＳＩコマンドが伝達されると、ＵＳＢストレージデバイス７からは最大セクタ数ｍのデータが転送され、このデータがＵＳＢホストコントローラ１９のバッファ１９Ａに格納される。このとき、ＵＳＢストレージデバイス７から返されるデータ量は、最大セクタ数ｍに抑えられることになるので、バッファ１９Ａの容量不足に起因してデータの損失が起こることはない。
【００４５】
バッファ１９Ａに格納されたデータは、ＣＰＵ１１がＵＳＢプロトコルスタック２１やＵＳＢマスストレージクラスドライバ１７としての処理を実行することで、順次、バッファ２１Ａ、バッファ１７Ａへと転送され、その結果、Ｓ３０７を完了する。
【００４６】
Ｓ３０７を終えたら、ＣＰＵ１１は、変数Ｔ，ｍの値に基づき、Ｔ＋ｍの演算結果を新たに変数Ｔに代入し、変数ｎ，ｍの値に基づき、ｎ−ｍの演算結果を新たに変数ｎに代入し（Ｓ３０９）、Ｓ３０３へと戻る。以降、Ｓ３０３においてｎ≦ｍではないと判断される間は、Ｓ３０３〜Ｓ３０９を繰り返し、ＵＳＢストレージデバイス７からは最大セクタ数ｍのデータ転送が繰り返されることになる。
【００４７】
そして、Ｓ３０３において、ｎ≦ｍであると判断された場合（Ｓ３０３：はい）、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｎセクタリードのＳＣＳＩリードコマンドを発行する（Ｓ３１１）。これにより、ＵＳＢストレージデバイス７からはセクタ数ｎのデータが転送され、その結果、所期のセクタ数分のデータ転送が完了することになる。
【００４８】
このデータは、最終的にバッファ１７Ａへと転送され、その結果、バッファ１７Ａには所期のセクタ数分のデータが格納されることになるので、これにて、図４（ｂ）に示す処理を終了する。そして、図４（ｂ）に示す処理を終了すると、Ｓ１０７を終えることになるので、図３に示す処理を終了する。この時点で、バッファ１７Ａには所期のセクタ数分のデータが格納されているので、このデータがＳＣＳＩコマンドの要求元に返されることになる。
【００４９】
なお、図３に示す処理のうち、Ｓ１０１において、ＳＣＳＩリードコマンドではないと判断された場合（Ｓ１０１：いいえ）、上記のようなリードコマンドの分割処理は不要となる。また、Ｓ１０５において、リードセクタ数が最大セクタ数を超えていないと判断されたら（Ｓ１０５：超えていない）、上記のようなリードコマンドの分割処理は不要となる。
【００５０】
したがって、これらの場合、ＣＰＵ１１は、従来通りのＳＣＳＩコマンド処理を実行し（Ｓ１０９）、図３に示す処理を終了する。ちなみに、従来通りのＳＣＳＩコマンド処理とは、ＳＣＳＩコマンドに対し、ＵＳＢ規格に準拠したヘッダを付加して、そのＳＣＳＩコマンドを発行する処理のことである。このような処理により、ＵＳＢプロトコルスタック２１経由でＵＳＢストレージデバイス７にＳＣＳＩコマンドが伝達されることになる。
【００５１】
［効果］
以上説明したように、上記ＵＳＢホスト装置１によれば、Ｓ３０７，Ｓ３１１の各ステップが到来するたびにＳＣＳＩコマンドを発行するものの、そのＳＣＳＩコマンドに対し、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７から転送されてくることはない。
【００５２】
しかも、それらのＳＣＳＩコマンドを発行するタイミングについては、ＵＳＢホスト装置１側の処理能力に応じて、バッファ１９Ａ内のデータをバッファ１７Ａへ転送した後のタイミングとすることができる。
【００５３】
したがって、ＵＳＢストレージデバイス７に対し、バッファ１９Ａ内で使用可能な容量を上回る大量のデータリードを要求するＳＣＳＩリードコマンドがＵＳＢホスト装置１内において発行された際、ＵＳＢホスト装置１側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイス７から転送されてくるデータを適切に受信することができる。
【００５４】
すなわち、ＵＳＢホストコントローラ１９の性能に合わせて（より詳しくは、ＵＳＢホストコントローラ１９が自力で受け取り可能なパケット数に応じて）、リードコマンドを分割すれば、ＵＳＢストレージデバイス７から一気に大量のパケットが転送されるのを制限できるのである。
【００５５】
したがって、例えば、ＣＰＵ１１の性能が低い場合や、ＣＰＵ１１が他の処理で高負荷になっている場合に、転送速度の早いＵＳＢストレージデバイス７を使ったとしても、ＵＳＢパケットの損失が起きるのを防止できるのである。
【００５６】
ちなみに、仮にＵＳＢホスト装置１側のデータ処理能力に十分な余力があるとすれば、バッファ１９Ａ内で使用可能な容量を上回る大量のデータがＵＳＢストレージデバイス７から転送されても、その転送速度を上回る速度で、バッファ１９Ａ内のデータをバッファ１７Ａへ転送することで、データの損失を回避することは可能である。
【００５７】
しかし、その場合は、ＣＰＵ１１に高度な処理能力が要求されることになり、その分だけＵＳＢホスト装置１を高性能化する必要があり、ＵＳＢホスト装置１にかかるコストが増大することになる。
【００５８】
この点、上記実施形態のような構成を採用すれば、ＣＰＵ１１に高度な処理能力は要求されないので、ＵＳＢホスト装置１を過度に高性能にしなくても済み、ＵＳＢホスト装置１にかかるコストを低減することができる。
【００５９】
しかも、このような機能を実現するに当たって、バッファ１９Ａ内で使用可能な容量を上回る大量のデータリードを要求するＳＣＳＩリードコマンドがＵＳＢホスト装置１内において発行されること自体は許容しているので、アプリケーションソフトウェアの改修は不要である。
【００６０】
また、ＵＳＢプロトコルスタック２１についても、何ら変更を加える必要はないので、すでに信頼性が高く、高度な処理を行っているＵＳＢプロトコルスタック２１について、不用意な改修を加えなくても済み、ＵＳＢホスト装置１の信頼性をいたずらに低下させてしまうことがない。
【００６１】
加えて、ＵＳＢプロトコルスタック２１でデータ転送を制限すると、ＵＳＢ音声デバイスなどのデータ転送で問題が生じる可能性があるが、上記実施形態であれば、そのような問題もない。
【００６２】
より詳しくは、ＵＳＢプロトコルスタック２１は、上記のようなＵＳＢストレージデバイス７の他、ＵＳＢハンドセット８のような音声デバイスにも利用されるソフトウェアである。
【００６３】
この種のＵＳＢ音声デバイスの場合、データ処理が間に合わなければ、一部の音声データを破棄して、後から到来する新しいデータの受け取りを優先することで、多少の音飛びが発生してもリアルタイム性が損なわれないようにしている。
【００６４】
そのため、ＣＰＵ１１の処理性能が低い状態にある場合に、ＵＳＢプロトコルスタック２１でデータ転送を制限すると、データ損失を防止できるとしても、新しいデータの受け取りで遅れが生じ、リアルタイム性が損なわれてしまうという問題が起こる。
【００６５】
この点、上記実施形態では、ＵＳＢプロトコルスタック２１の構成を変えることなく対処しているので、ＵＳＢハンドセット８のような音声デバイスに対し、悪影響を及ぼしてしまうおそれがない。
【００６６】
〔２〕第二実施形態
次に、第二実施形態について説明する。ただし、第二実施形態以降の各実施形態は、いずれも一部が第一実施形態と異なるだけで、大部分は第一実施形態と同様なので、第二実施形態以降の各実施形態については、第一実施形態との相違点を中心に説明し、第一実施形態との共通点に関しては、その説明を省略する。
【００６７】
［リードコマンド分割処理］
第二実施形態は、第一実施形態において図４（ｂ）に示したリードコマンド分割処理を、図５に示す処理に変更したものである。
【００６８】
図５に示す処理を開始すると、ＣＰＵ１１は、まず、リード開始位置となる先頭セクタ番号を変数Ｔに代入し、リードセクタ数を変数ｎに代入し、最大セクタ数を変数ｍに代入する（Ｓ４０１）。
【００６９】
そして、ＣＰＵ１１は、変数ｎ，ｍについて、ｎ≦ｍか否かを判断する（Ｓ４０３）。ここで、ｎ≦ｍではないと判断された場合（Ｓ４０３：いいえ）、ＣＰＵ１１は、変数ｎ，ｍの値に基づき、ｎ÷ｍの演算結果（ただし、端数切り上げ）を変数ａに代入し、さらにｎ÷ａの演算結果（ただし、端数切り上げ）を変数ｂに代入する（Ｓ４０７）。
【００７０】
ここで、変数ａの値は、最大セクタ数ｍでのリードを繰り返した場合に、何回のリードを行うことになるのか、その回数を示す値に相当する。また、変数ｂの値は、変数ａの示す回数のリードを行う場合に、少なくとも変数ｂの示すセクタ数のリードを繰り返せば、変数ｂの示すセクタ数を超えるリードを１度も発行しなくても済むセクタ数を示す値に相当する。
【００７１】
これらの値を算出したら、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｂセクタリードのＳＣＳＩリードコマンドを発行する（Ｓ４０９）。すなわち、Ｓ４０９では、基となったＳＣＳＩコマンドで要求されたセクタ数ｎではなく、Ｓ４０７で算出した値ｂをリード対象セクタ数とするＳＣＳＩリードコマンドを発行する。
【００７２】
このようなＳＣＳＩコマンドにより、ＵＳＢストレージデバイス７にＳＣＳＩコマンドが伝達されると、ＵＳＢストレージデバイス７からはセクタ数ｂのデータが転送され、このデータがＵＳＢホストコントローラ１９のバッファ１９Ａに格納される。したがって、ＵＳＢストレージデバイス７から返されるデータ量は、セクタ数ｂに抑えられることになるので、バッファ１９Ａの容量不足に起因してデータの損失が発生することはない。
【００７３】
Ｓ４０９を終えたら、ＣＰＵ１１は、変数Ｔ，ｂの値に基づき、Ｔ＋ｂの演算結果を新たに変数Ｔに代入し、変数ｎ，ｂの値に基づき、ｎ−ｂの演算結果を新たに変数ｎに代入し（Ｓ４１１）、Ｓ４０３へと戻る。以降、Ｓ４０３においてｎ≦ｍではないと判断される間は、Ｓ４０３〜Ｓ４１１を繰り返し、ＵＳＢストレージデバイス７からはセクタ数ｂのデータ転送が繰り返されることになる。
【００７４】
そして、Ｓ４０３において、ｎ≦ｍであると判断された場合（Ｓ４０３：はい）、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｎセクタリードのＳＣＳＩリードコマンドを発行する（Ｓ４１３）。これにより、ＵＳＢストレージデバイス７からはセクタ数ｎのデータが転送され、その結果、所期のセクタ数分のデータ転送が完了することになる。
【００７５】
［効果］
以上説明したようなリードコマンド分割処理を行っても、第一実施形態の場合同様、Ｓ４０９，Ｓ４１３の各ステップが到来するたびにＳＣＳＩコマンドを発行するものの、そのＳＣＳＩコマンドに対し、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７から転送されてくることはない。
【００７６】
しかも、第一実施形態においては、最大セクタ数ｍに基づき、その最大セクタ数ｍのリードを繰り返した後、最後に端数分となるセクタのリードを行っていたが、第二実施形態においては、上記のような変数ａ，ｂの値を算出し、セクタ数ｂのリードを繰り返す。
【００７７】
そのため、最後の端数分のセクタ数がきわめて小さくなるような状況であれば、繰り返し回数はそのままに、各回に可能な限り均等にセクタ数を配分し、その分、繰り返しリードを行うときのセクタ数をいくらか小さくすることができる。
【００７８】
理解を促すため、簡単な数値を例示して上記効果を説明すれば、例えば、リードセクタ数３４、最大セクタ数１０の場合、先に説明した第一実施形態であれば、セクタ数を１０，１０，１０，４と分けて４回のリードを行っていたのに対し、第二実施形態では、セクタ数を９，９，８，８と分けて４回のリードを行うことになる。
【００７９】
つまり、リード回数は、第一実施形態と同様であるにもかかわらず、各回に可能な限り均等にセクタ数を配分することができる。したがって、繰り返し処理の回数を増大させることなく、１回のリードで必要となるバッファ１９Ａの容量を低減することができるので、ＵＳＢホスト装置１にかかる負荷を第一実施形態以上に軽減でき、バッファ１９Ａ内でのデータ損失を防止する効果を、より一層高めることができる。
【００８０】
〔３〕第三実施形態
次に、第三実施形態について説明する。
［最大セクタ数取得処理］
第三実施形態は、第一実施形態において図４（ａ）に示した最大セクタ数取得処理を、図６に示す処理に変更したものである。
【００８１】
図６に示す処理を開始すると、ＣＰＵ１１は、まず、「ＵＳＢストレージデバイス７が接続されているＵＳＢホストコントローラ１９」のドライバ１６からプラグアンドプレイＩＤを取得する（Ｓ５０１）。Ｓ５０１で取得するプラグアンドプレイＩＤは、ＵＳＢホストコントローラ１９の製造者及び形式を一意に特定可能な識別子である。
【００８２】
続いて、ＣＰＵ１１は、取得したプラグアンドプレイＩＤをテーブルから検索する（Ｓ５０３）。ＵＳＢホスト装置１には、Ｓ５０１で取得する可能性のあるプラグアンドプレイＩＤと、そのプラグアンドプレイＩＤに対応するＵＳＢホストコントローラ経由でリードを発行しても安全なセクタ数との対応関係が、あらかじめテーブル化されて記憶されている（下記表１参照。）。Ｓ５０３では、Ｓ５０１で取得したプラグアンドプレイＩＤを、表１に示すようなテーブル内からサーチする。
【００８３】
【表１】
2012048309.tif 000003
【００８４】
そして、ＣＰＵ１１は、テーブル上にＵＳＢホストコントローラ１９の情報が見つかった否かを判断し（Ｓ５０５）、見つかった場合には（Ｓ５０５：はい）、テーブルから取得した値（ｍ）を返す（Ｓ５０７）。
【００８５】
例えば、Ｓ５０１で取得したプラグアンドプレイＩＤが、“Ｖｅｎ＝０ｘ１０ｄｅ  Ｄｅｖ＝０ｘ０２２１”の場合、表１に示すテーブル上から情報が見つかる。そこで、その場合は、その見つかった情報に対応するセクタ数ｍ＝１２をテーブルから取得して、その値をリターン値として上位手段（図６に示す処理を呼び出した処理手段）へと返し、図６に示す処理を終了する。
【００８６】
一方、Ｓ５０５において、テーブル上からＵＳＢホストコントローラ１９の情報が見つからなかった場合（Ｓ５０５：いいえ）、ＣＰＵ１１は、デフォルト値をリターン値として上位手段へと返し、図６に示す処理を終了する。なお、このデフォルト値は、利用される可能性のあるＵＳＢホストコントローラのうち、性能が比較的低いものを想定してあらかじめ取り決められている値であり、例えば、ｍ＝８などの固定値が返されることになる。
【００８７】
［効果］
以上説明したような処理を行っても、第一、第二実施形態の場合同様、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７から転送されてくることはない。
【００８８】
しかも、第一実施形態においては、ある特定のＵＳＢホストコントローラ１９だけをターゲットにして最大セクタ数が取り決められていたが、第三実施形態の構成を採用すれば、複数種類の異なるＵＳＢホストコントローラ１９をターゲットにして、それぞれの性能に応じて最大セクタ数を最適化することができる。
【００８９】
したがって、複数種類の異なるＵＳＢホストコントローラ１９が使用され得るＵＳＢホスト装置１を対象とする場合には、第三実施形態の構成を採用することで、より性能を引き出すことができる。
【００９０】
〔４〕第四実施形態
次に、第四実施形態について説明する。
［最大セクタ数取得処理］
第四実施形態は、第一、第三実施形態において図４（ａ）、図６に示した最大セクタ数取得処理を、図７に示す処理に変更したものである。
【００９１】
図７に示す処理を開始すると、ＣＰＵ１１は、まず、「ＵＳＢストレージデバイス７が接続されているＵＳＢホストコントローラ１９」のドライバ１６からプラグアンドプレイＩＤを取得し（Ｓ６０１）、取得したプラグアンドプレイＩＤをテーブルから検索する（Ｓ６０３）。これらの処理は、第三実施形態とほぼ同様である。
【００９２】
ただし、第四実施形態では、テーブルの記憶内容が第三実施形態とは異なっている。具体的には、ＵＳＢホスト装置１には、Ｓ６０１で取得する可能性のあるプラグアンドプレイＩＤと、そのプラグアンドプレイＩＤに対応するＵＳＢホストコントローラのパケットバッファ数との対応関係が、あらかじめテーブル化されて記憶されている（下記表２参照。）。
【００９３】
【表２】
2012048309.tif 000004
【００９４】
ＣＰＵ１１は、テーブル上にＵＳＢホストコントローラ１９の情報が見つかった否かを判断し（Ｓ６０５）、見つかった場合には（Ｓ６０５：はい）、テーブルから取得した値（Ｑ）を以降の演算で使用する（Ｓ６０７）。
【００９５】
一方、Ｓ６０５において、テーブル上からＵＳＢホストコントローラ１９の情報が見つからなかった場合（Ｓ６０５：いいえ）、ＣＰＵ１１は、デフォルト値を以降の演算で使用する。このデフォルト値は、利用される可能性のあるＵＳＢホストコントローラのうち、性能が比較的低いものを想定してあらかじめ取り決められている値であり、例えば、Ｑ＝３２などの固定値が使用される。
【００９６】
続いて、ＣＰＵ１１は、「ＵＳＢストレージデバイスが接続されているＵＳＢホストコントローラ」に接続されているＵＳＢデバイス数を、変数Ｐに代入する（Ｓ６１１）。そして、変数Ｐ，Ｑの値に基づいて、Ｑ÷（Ｐ＋１）の演算結果を変数ｍに代入する（Ｓ６１３）。なお、Ｓ６１３において、変数ｍが０となるときは、変数ｍの値を１に補正する。そして、この変数ｍの値をリターン値として上位手段（図７に示す処理を呼び出した処理手段）へと返し、図７に示す処理を終了する。
【００９７】
このようにして最大セクタ数ｍを決定すれば、例えば、ＵＳＢデバイス数が１のときは、全パケットバッファの１／２がひとつのＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が２のときは、全パケットバッファの１／３がひとつのＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が３のときは、全パケットバッファの１／４がひとつのＵＳＢストレージデバイスに利用され、…ということになる。
【００９８】
したがって、この場合、仮に全ＵＳＢデバイスがＵＳＢストレージデバイスであっても、ＵＳＢデバイス数が１のときは、全パケットバッファの１／２が全ＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が２のときは、全パケットバッファの２／３が全ＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が３のときは、全パケットバッファの３／４が全ＵＳＢストレージデバイスに利用され、…となり、いくらか余裕が残る状態でバッファが利用されることになる。
【００９９】
ちなみに、Ｓ６１１で変数Ｐに代入されるＵＳＢデバイス数は、ＵＳＢデバイスの接続・切断に応じて、図８（ａ）及び同図（ｂ）に示すような処理により、動的に変更される値である。
【０１００】
すなわち、プラグアンドプレイ機能により、ＵＳＢデバイスの接続が検出された場合には、図８（ａ）に示す処理が実行され、この場合、ＣＰＵ１１は、接続を検出したＵＳＢデバイスが接続しているＵＳＢホストアダプタのＵＳＢデバイス数をカウントアップし（Ｓ７０１）、以下、通常のＵＳＢデバイス接続処理を実行する（Ｓ７０３）。なお、Ｓ７０３で行われる処理の詳細は、ＵＳＢデバイスにおける一般的な処理に過ぎないので、ここでの説明は省略する。
【０１０１】
また、プラグアンドプレイ機能により、ＵＳＢデバイスの切断が検出された場合には、図８（ｂ）に示す処理が実行され、この場合、ＣＰＵ１１は、切断を検出したＵＳＢデバイスが接続していたＵＳＢホストアダプタのＵＳＢデバイス数をカウントダウンし（Ｓ８０１）、以下、通常のＵＳＢデバイス切断処理を実行する（Ｓ８０３）。なお、Ｓ８０３で行われる処理の詳細も、ＵＳＢデバイスにおける一般的な処理に過ぎないので、ここでの説明は省略する。
【０１０２】
［効果］
以上説明したような処理を行っても、第一〜第三実施形態の場合同様、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７から転送されてくることはない。
【０１０３】
また、第四実施形態の構成でも、第三実施形態同様、複数種類の異なるＵＳＢホストコントローラ１９をターゲットにして、それぞれの性能に応じて最大セクタ数を最適化することができる。しかも、第四実施形態の構成であれば、ＵＳＢデバイス数に応じて最大セクタ数を最適化することもできる。
【０１０４】
したがって、複数種類の異なるＵＳＢホストコントローラ１９が使用され得るＵＳＢホスト装置１を対象とする場合には、第四実施形態の構成を採用することで、より性能を引き出すことができ、さらにＵＳＢデバイス数も考慮した最適化を行うことができる。
【０１０５】
〔５〕第五実施形態
次に、第五実施形態について説明する。
［最大セクタ数取得処理］
第五実施形態は、第一、第三、第四実施形態において図４（ａ）、図６、図７に示した最大セクタ数取得処理を、図９に示す処理に変更したものである。
【０１０６】
図９に示す処理を開始すると、ＣＰＵ１１は、まず、「ＵＳＢストレージデバイス７が接続されているＵＳＢホストコントローラ１９」のドライバ１６からプラグアンドプレイＩＤを取得する（Ｓ９０１）。
【０１０７】
そして、取得したプラグアンドプレイＩＤに対応するＵＳＢホストコントローラ１９について、パケットバッファを解析できる否かを判断する（Ｓ９０３）。パケットバッファを解析できる否かは、複数種類あるＵＳＢホストコントローラ１９のそれぞれで決まっており、その情報はＵＳＢホスト装置１があらかじめ記憶している。
【０１０８】
ここで、パケットバッファを解析できる場合（Ｓ９０３：はい）、ＣＰＵ１１は、パケットバッファの残り数を調べて、その値を変数Ｒに代入する（Ｓ９０５）。そして、その変数Ｒに基づいて、Ｒ÷２の演算結果を変数ｍに代入する（Ｓ９０７）。なお、Ｓ９０７では、変数ｍが０になるときは、変数ｍの値を１に補正する。そして、この変数ｍの値をリターン値として上位手段（図９に示す処理を呼び出した処理手段）へと返し、図９に示す処理を終了する。
【０１０９】
一方、Ｓ９０３において、パケットバッファを解析できない場合（Ｓ９０３：いいえ）、ＣＰＵ１１は、デフォルト値をリターン値として上位手段へと返し、図９に示す処理を終了する。なお、このデフォルト値は、利用される可能性のあるＵＳＢホストコントローラのうち、性能が比較的低いものを想定してあらかじめ取り決められている値であり、例えば、ｍ＝８などの固定値が返されることになる。
【０１１０】
［効果］
以上説明したような処理を行っても、第一〜第四実施形態の場合同様、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７から転送されてくることはない。
【０１１１】
また、第五実施形態の構成であれば、ＵＳＢホストコントローラ１９のバッファ１９Ａの空き容量を実際に解析し、最大セクタ数を最適化することができる。したがって、第五実施形態の構成を採用することで、動的に変化するバッファ１９Ａの空き容量も考慮して、より性能を引き出すことができる。
【０１１２】
〔６〕変形例等
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１１３】
例えば、上記第五実施形態などでは、取得したプラグアンドプレイＩＤに対応するＵＳＢホストコントローラ１９について、パケットバッファを解析できる否かを判断していたが、特定のＵＳＢホストコントローラ１９と組み合わせて出荷されるソフトウェアであれば、パケットバッファを解析できることを前提とした処理を行ってもよい。
【０１１４】
すなわち、この場合、パケットバッファを解析できる否かを判断は省略してもよく、そのような構成であっても、ＵＳＢホストコントローラ１９のバッファ１９Ａの空き容量を実際に解析し、最大セクタ数を最適化することができる、という効果を奏するものとなる。
【符号の説明】
【０１１５】
１・・・ＵＳＢホスト装置、２・・・制御部、３・・・補助記憶部、４・・・ＵＳＢインターフェース、５・・・その他の入出力インターフェース、６・・・ＵＳＢハブ、７・・・ＵＳＢストレージデバイス、８・・・ＵＳＢハンドセット、９・・・その他のデバイス類、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１５・・・ディスクデバイスドライバ、１６・・・ＵＳＢホストコントローラドライバ、１７・・・ＵＳＢマスストレージクラスドライバ、１８・・・ＵＳＢハンドセットドライバ、１９・・・ＵＳＢホストコントローラ、２１・・・ＵＳＢプロトコルスタック、１７Ａ，１８Ａ，１９Ａ，２１Ａ・・・バッファ。
【図１】
2012048309.tif 000005
【図２】
2012048309.tif 000006
【図３】
2012048309.tif 000007
【図４】
2012048309.tif 000008
【図５】
2012048309.tif 000009
【図６】
2012048309.tif 000010
【図７】
2012048309.tif 000011
【図８】
2012048309.tif 000012
【図９】
2012048309.tif 000013