PCに搭載されるOSで一般的に普及している ものとしてWindows(登録商標)がある。本実施形 態では、Windows(登録商標)XPを搭載しているPC� �、USBインタフェースの外付HDDを接続する場� �について、図を用いて説明する。なお、本� �明においてOSの種別や接続デバイスの種別、 インタフェースを限定するものではない。

 図4は、本実施形態におけるPCと外付HDDの� ��ロック図である。PC1と外付HDD2はUSBインタフ ェース(I/F)で接続される。PC1は、全体を管理� ��るOS11上に、種々の処理を行うアプリケーシ ョン101、および周辺機器を動作させるための 各種ドライバが含まれるドライバ102を搭載し ている。アプリケーション101は、ドライバ102 、USBコントローラ12、およびUSBI/F13を介して� �付HDD2に記憶されているデータを読み出し(リ ード)、外付HDD2にデータを書き込む(ライト)� �

 外付HDD2は、コントローラ22がUSBI/F21を介� �てリードまたはライトの要求を受信し、こ� �に応じてHDD23に記憶されているデータをリー ド、またはHDD23にデータをライトする。また� ��本実施形態の外付HDD2は、コントローラ22が� ��PC1側から転送されたコマンドを分割し、HDD2 3に所定のサイズ(例えば1MB)以下の小さいデー タでリード、ライトするものである(本発明� �コマンド分割部に相当する)。

 図5は、OS11上に搭載されている各種ドラ� �バおよび外付HDD2の機能ブロック図である。� ��図において、アプリケーション101、汎用デ� ��スクドライバ502、USBマスストレージドライ� ��503、USBホストコントローラドライバ504、上� ��側ドライバ151、および下位側ドライバ152は� ��OS11上に搭載されている機能部である。実際 には、これらの機能部は、OS11にインストー� �されるソフトウェアとして実現する。

 アプリケーション101は、ドライバ102に含� ��れる各種ドライバを介して外付HDD2にリード またはライトの要求を行う。同図においては 、アプリケーション101がライトの要求を行い 、データ転送する例を示す。

 アプリケーション101は、上位側ドライバ1 51に、ライト要求を行い、外付HDD2のHDD23に書� ��込むべきデータを転送する。上位側ドライ� ��151は、このライト要求およびデータを下位� ��である汎用ディスクドライバ502に転送する� ��ともに、アプリケーション101からライト要� ��があった旨、およびそのデータ量を示す情� ��をアクセス情報として下位側ドライバ152に� ��信する。上位側ドライバ151が下位側ドライ� ��152に転送するアクセス情報については後に� ��しく述べる。

 汎用ディスクドライバ502は、上位側ドラ� ��バ151から受信したデータをUSBマスストレー� ��ドライバ503に転送する。このとき、USBマス� ��トレージドライバ503のデータ転送サイズの� ��限が64kBであるため、汎用ディスクドライバ 502は、64kB毎に分割してUSBマスストレージド� �イバ503にデータを転送する。

 USBマスストレージドライバ503は、バルク� ��ンリープロトコル(図2参照)によりデータ転� ��を行うため、この64kBに分割されたデータに コマンド、ステータスを付与し、順次、下位 側ドライバ152に転送する。

 下位側ドライバ152は、USBマスストレージ� ��ライバ503から転送されたデータをキャッシ� ��し、所定のタイミングでUSBホストコントロ� ��ラドライバ504に転送する。USBホストコント� ��ーラドライバ504は、図4で示したUSBホストコ ントローラ12、USBI/F13を介して、このデータ� �外付HDD2に転送する。なお、図5においてはUSB ホストコントローラ12、USBI/F13、およびUSBI/F21 を省略している。下位側ドライバ152が、USBマ スストレージドライバ503から転送されたデー タをキャッシュし、ある程度の容量(64kB以上) のデータとして、まとめてUSBホストコントロ ーラドライバ504に転送するため、コマンド、 ステータスの発行が1度で(あるいは64kB毎に付 与するよりも少なくて)済む。したがって、� �マンド、ステータスの処理時間による遅延� �最小限で済む。なお、汎用ディスクドライ� �502から下位側ドライバ152まで転送されるデ� �タは、64kB毎にコマンド、ステータスが付与� ��れているが、この転送は、OS上のメモリ(RAM) 転送であるため、外付HDD2へのデータ転送速� �に比較して非常に高速である(RAM転送速度に� ��存する)。

 また、この実施形態において、アプリケ� ��ション101が直接USBマスストレージドライバ5 03にデータ転送する場合があるが、上記と同� ��、USBマスストレージドライバ503のデータ転� ��サイズの上限が64kBであるため、アプリケー ション101が64kB毎に分割してデータを転送し� �USBマスストレージドライバ503がコマンド、� �テータスを付与したデータを転送する。こ� �場合においても、下位側ドライバ152がデー� �をキャッシュしてから下位側にデータ転送� �るため、コマンド、ステータスの処理時間� �よる遅延が最小限で済む。

 外付HDD2のコントローラ22は、USBI/F21を介� �て、上記転送されたコマンドを受信する。� �こで、コントローラ22は、このコマンドを所 定のサイズ(例えば1MB以下)に分割し、上位側� ��ら転送されるデータを順次、HDD23にライト� �る処理を行う。すなわち、コントローラ22は 、ライトのコマンドを受信したとき、1MBより も大きいデータをライトするものであるか否 かを判断し、1MB以下であればそのままライト コマンドを実行し、1MBよりも大きい場合、当 該コマンドを1MB以下のデータをライトするも のとなるように複数のコマンドに分割する。 例えば転送されたコマンドが3MBのデータをラ イトするものであった場合、これを1MBのデー タをライトするコマンドに3分割する。これ� �より、外付HDD2が1MB以下のデータをライトす� ��ように最適化されている場合において、コ� ��トローラ22が1MB以下のデータに分割してラ� �トするため、デバイス側(外付HDD2側)のライ� �速度を向上させることができる。

 なお、分割するサイズは1MBに限らず、上� ��のように64kB毎に分割してもよい。この場合 、PC側が複数コマンドに分割することを想定� ��て、64kBB以下のデータをライトするように� �適化されている周辺機器においても、ライ� �速度を向上させることができる。例えば、� �場出荷時等において、デバイス毎に最適な� �イト速度となるように、コントローラ22が分 割するサイズを規定する(ファームウェアを� �定しておく)。

 また、上記コントローラ22や下位側ドラ� �バ152において、分割するサイズを変更する� �うにしてもよい。例えば、下位側ドライバ15 2が、そのデバイスのメーカ名や型番等の情� �を取得し、最適な分割サイズを設定する。� �の場合、メーカ名や型番等と最適なサイズ� �を予め対応づけてデータベース化しておく� �下位側ドライバ152は、メーカ名や型番等の� �報を取得して当該データベースを参照する� �とにより、最適な分割サイズを読み出し、� �れをコントローラ22に設定する。

 また、デバイス側に設けられているキャ� ��シュの容量に応じて分割サイズを設定して� ��よい。いずれにしても、デバイスの仕様に� ��じて、最適な分割サイズの設定方法をとれ� ��よい。

 次に、上位側ドライバ151および下位側ド� ��イバ152の詳細な動作について説明する。図6 は、上位側ドライバ151および下位側ドライバ 152の詳細な構成を示す機能ブロック図である 。なお、図5と共通する構成については同一� �符号を付し、その説明を省略する。上位側� �ライバ151は、リード、ライト要求受信部155� �備えている。また、下位側ドライバ152は、� �ントローラ(制御プログラム)156、データベー ス157、キャッシュメモリ158A~158C、タイマ159、 およびコマンドキュー160を備えている。なお 、データベース157やキャッシュメモリ158A~158C 、コマンドキュー160は、PC1に搭載されている RAMにより実現される。また、リード、ライト 要求受信部155やコントローラ156は、ソフトウ ェアにより実現される。

 リード、ライト要求受信部155は、アプリ� ��ーション101からリードまたはライトの要求� ��受信する。リード、ライト要求受信部155は� ��この要求を下位側の汎用ディスクドライバ5 02に転送するとともに、要求の内容をアクセ� ��情報として下位側ドライバ152に送信する。� ��ードまたはライトの要求は、汎用ディスク� ��ライバ502、およびUSBマスストレージドライ� ��503を介して下位側ドライバ152に転送される� ��

 アクセス情報には、LBA(Logical Block Addressi ng:HDDのセクタ指定番号)、転送ブロック数、� �送方向などが記載されている。転送ブロッ� �数は転送データの容量を示す。転送方向は� �下位側から上側への転送(リード)であるか、 上位側から下位側への転送(ライト)であるか� ��示す情報である。

 このアクセス情報は、下位側ドライバ152� ��データベース157に予想データベースとして� ��憶される。下位側ドライバ152のコントロー� ��156は、USBマスストレージドライバ503からリ� ��ドまたはライトの要求を受信したとき、デ� ��タベース157を参照する。予想データベース� ��参照することで、転送データ容量を予測す� ��ことができる。

 また、コントローラ156は、USBマスストレ� ��ジドライバ503から受信したリードまたはラ� ��トの要求を履歴データベースとしてデータ� ��ース157に記憶する。履歴データベースは、� ��ントローラ156が予想データベースを作成、� ��正する場合に用いられる。すなわち、USBマ� ��ストレージドライバ503からリードまたはラ� ��トの要求を受信したとき、過去の履歴デー� ��ベースを参照し、LBA、転送ブロック数、転� ��方向が同一または一部一致する(類似する)� �のを予想データベースとして転記する。ま� �、一致する履歴が存在した場合、これと関� �する履歴(例えばLBAと転送ブロック数に基づ� ��て、連続して要求があったと判断できるも� ��)をまとめ、1つのコマンドとして予想デー� �ベースに記憶することもできる。なお、履� �データベースは、同図においてはデータベ� �ス157内に記憶され、PC1のRAM上に一時的に記� �されているが、これをPC1のOS11(PC1のHDD)上、� �たは外付HDD2のHDD23に記憶しておいてもよい� �これにより、外付HDD2を再接続したときやPC1� ��再起動したときにおいても過去の履歴を参� ��することができる。

 コントローラ156は、USBマスストレージド� ��イバ503から転送された要求がライトの要求� ��あれば、予想データベースの転送ブロック� ��を参照することで、転送データ容量を予測� ��ることができる。このとき、上位側ドライ� ��151が下位側ドライバ152に、アクセス情報を� ��信して予想データベースに記憶されている� ��合は、転送データ容量(ライトすべき全デー タ)を予測することができる。コントローラ15 6は、64kB以上のデータ転送が行われると予測� ��た場合、上位側から転送されたデータをキ� ��ッシュメモリ158A~158Cのいずれかに格納する� ��

 キャッシュメモリ158A~158Cは、RAM上に仮想� ��に形成されたエリアであり、その数および� ��量はコントローラ156が設定する。キャッシ� ��メモリの数および容量は、適宜設定し得る� ��、同図の例では、3つのキャッシュメモリを 用意し、それぞれ4MBの容量を設定しているも のとする。なお、動作中にキャッシュメモリ の数および容量を変化させることも可能であ る。キャッシュメモリの数および容量はユー ザが手動で設定するようにしてもよいし、後 述のように動作状態に応じて適宜変化させる ようにしてもよい。

 上記のように、コントローラ156は、キャ� ��シュメモリ158A~158Cのうち、いずれか1つに上 位側から転送されたデータを順次、格納する 。このライト用のデータを格納したキャッシ ュメモリがライト用キャッシュメモリとなる 。ただし、USBマスストレージドライバ503から 64kB毎にコマンド、ステータスが付与されて� �ータ転送されるため、コントローラ156は、64 kBのデータを受信する度に、USBマスストレー� ��ドライバ503に対してコマンド終了を擬似的� ��返信する。これにより、USBマスストレージ� ��ライバ503から順次コマンドを受信すること� ��でき、複数のコマンドを統合することがで� ��る。

 コントローラ156は、所定のタイミングで� ��位側のUSBホストコントローラドライバ504に� ��し、ライト要求を行い、ライト用キャッシ� ��メモリのデータを転送する。この所定のタ� ��ミングは、ライト用キャッシュメモリの容� ��が一杯になったタイミング、上位側から64kB 未満のデータが転送されたタイミング、FLUSH� �CACHEコマンドのようなデータ書き込みを指示 するコマンドを受信したタイミング、等であ る。

 また、タイマ159を使用し、タイマ159の割� ��込み処理により決定されるタイミングで書� ��込みを行ってもよい。この場合、コントロ� ��ラ156は、USBマスストレージドライバ503から� ��イト要求を受信したときにタイマ159を作動� ��せる。タイマを使用すれば、一定時間コマ� ��ド発行が無い状態を検出して、ライト用キ� ��ッシュメモリの内容を書き込みすることが� ��きる。そのため、異常時(USBケーブルが切断 されたり、PC1がハングアップした場合)のフ� �イル破壊等を防止することができる。

 なお、USBホストコントローラドライバ504� ��下の下位側において他の処理を行っている� ��合、コントローラ156は、一旦ライト要求を� ��マンドキュー160に登録しておき、後に下位� ��の処理が空いているときにライト要求を行� ��。

 以上のようにして、アプリケーション101� ��らデータのライトが行われる。次に、図7に おいて、アプリケーション101がリードの要求 を行い、データ転送する例を示す。

 図7は、OS11上に搭載されている各種ドラ� �バの機能ブロック図である。なお、図5と共� ��する構成については同一の符号を付し、そ� ��説明を省略する。

 まず、アプリケーション101は、上位側ド� ��イバ151に、リード要求を行う。上位側ドラ� ��バ151は、この要求を下位側である汎用ディ� ��クドライバ502に転送するとともに、アプリ� ��ーション101からリード要求があった旨(アク セス情報)を下位側ドライバ152に送信する。

 汎用ディスクドライバ502は、上位側ドラ� ��バ151から受信したリード要求をUSBマススト� ��ージドライバ503に転送する。このとき、USB� ��スストレージドライバ503のデータ転送サイ� ��の上限が64kBであるため、汎用ディスクドラ イバ502は、64kB毎にリード要求を分割する。US Bマスストレージドライバ503は、下位側ドラ� �バ152に64kB毎に分割されたリード要求を転送� ��る。

 下位側ドライバ152は、USBマスストレージ� ��ライバ503から64kB毎に分割されたリード要求 を受信した場合、この後連続してリード要求 がされると予測し、ある程度の容量(例えば3M B)のデータを転送するように、USBホストコン� ��ローラドライバ504に予測リード要求を行う� ��USBホストコントローラドライバ504は、この� ��測リード要求に基づいて、上記3MBの容量の� ��ータをHDD2のHDD23から読み出すように、USBホ� ��トコントローラ12、USBI/F13を介して外付HDD2� �リードのコマンドを転送する。

 外付HDD2のコントローラ22は、USBI/F21を介� �て、USBホストコントローラドライバ504から� �送されたリードのコマンドを受信する。こ� �で、コントローラ22は、3MB分のリードのコマ ンドを所定のサイズ(例えば1MB以下)に分割し� ��から、HDD23からリードする処理を行う。す� �わち、コントローラ22は、リードのコマンド およびデータを受信したとき、1MBよりも大き いデータをリードするものであるか否かを判 断し、1MB以下であればそのままリードコマン ドを実行し、1MBよりも大きい場合、当該コマ ンドを1MB以下のデータをリードするものとな るように複数のコマンドに分割する。例えば 3MBのデータをリードするものであった場合、 これを1MBのデータをリードするコマンドに3� �割する。そして、分割した各コマンドを実� �し、上記USBホストコントローラドライバ504� �、リードしたデータを順次転送する。

 これにより、外付HDD2が1MB以下のデータを リードするように最適化されている場合にお いて、コントローラ22が1MB以下のコマンドに� ��割して順次リードを行うため、デバイス側� ��リード速度を向上させることができる。

 なお、分割するサイズは1MBに限らず、上� ��のように64kB毎に分割してもよい。ライトと 同様、PC側が複数コマンドに分割することを� ��定して、64kB以下のデータをリードするよう に最適化されている周辺機器においても、リ ード速度を向上させることができる。また、 ライトと同様、例えば工場出荷時等において 、デバイス毎に最適なリード速度となるよう に、コントローラ22が分割するサイズを規定� ��る(ファームウェアを設定しておく)。

 また、前述のように、デバイスのメーカ� ��や型番等の情報を取得して、分割するサイ� ��を変更するようにしてもよいし、デバイス� ��に設けられているキャッシュの容量に応じ� ��分割サイズを設定してもよい。

 このようにしてリードされたデータが下� ��側ドライバ152に順次転送され、キャッシュ� ��れる。下位側ドライバ152は、USBマスストレ� ��ジドライバ503から受信したリード要求にし� ��がって、キャッシュしたデータを順次、上� ��側に転送する。ここで、ある程度の容量と� ��、上記の例では3MBとしたが、転送容量が大� ��すぎる場合は、転送速度が遅くなる。すな� ��ち、その転送の終了を待ち、その転送の正� ��終了のステータスを確認するまで、上位側� ��キャッシュしたデータの転送を開始できな� ��ため、転送速度が遅くなる原因となる。ま� ��、リード用キャッシュメモリの容量を大き� ��する必要がある。

 そのため、コントローラ156は、最初に64kB (あるいはそれ以下、32kB等であってもよい。) のリード要求を受信したとき、その所定倍(� �えば32kBの4倍である128kB)の容量のデータを読 み出してキャッシュすることが望ましい。こ のキャッシュしたデータが、結果的に全て上 位側に転送される場合、さらに所定倍(例え� �128kBの4倍である512kB)の容量のデータを読み� �す。このように、順次、キャッシュするデ� �タの容量を大きくすることで、転送時間を� �えながら、好適なリード用キャッシュメモ� �の容量に設定することができる。

 このように、下位側ドライバ152が、外付H DD2からある程度の容量を一度に読み出し、キ ャッシュしておくことで、外付HDD2に対する� �マンド、ステータスの発行が1度で(あるいは 64kB毎に付与するよりも少なくて)済む。した� ��って、コマンド、ステータスの処理時間に� ��る遅延が最小限で済む。なお、下位側ドラ� ��バ152から汎用ディスクドライバ502まで転送� ��れるデータは、64kBに分割されるが、この転 送は、OS上のメモリ(RAM)転送であるため、外� �HDD2からのデータ転送速度に比較して非常に� ��速である(RAM転送速度に依存する)。

 図6を参照して、上記リード要求発生時の 上位側ドライバ151および下位側ドライバ152の 詳細な動作について説明する。リード、ライ ト要求受信部155は、アプリケーション101から リードの要求を受信する。リード、ライト要 求受信部155は、この要求を下位側の汎用ディ スクドライバ502に転送するとともに、要求の 内容をアクセス情報として下位側ドライバ152 に送信する。リード要求は、汎用ディスクド ライバ502、およびUSBマスストレージドライバ 503を介して下位側ドライバ152に転送される。 なお、汎用ディスクドライバ502、およびUSBマ スストレージドライバ503から転送されるリー ド要求は64kB毎のリード要求に分割されてい� �。

 上位側ドライバ151が送信したアクセス情� ��は、下位側ドライバ152のデータベース157に� ��想データベースとして記憶される。下位側� ��ライバ152のコントローラ156は、USBマススト� ��ージドライバ503からリード要求を受信した� ��き、データベース157を参照する。予想デー� ��ベースを参照することで、転送データ容量( リードすべき全データ)を予測することがで� �る。

 また、USBマスストレージドライバ503から� ��信したリード要求を履歴データベースとし� ��データベース157に記憶する。履歴データベ� ��スは、コントローラ156が予想データベース� ��作成、修正する場合に用いられる。すなわ� ��、USBマスストレージドライバ503からリード� ��求を受信したとき、過去の履歴データベー� ��を参照し、LBA、転送ブロック数、転送方向� ��同一または類似するものを予想データベー� ��として転記する。一致する履歴が存在する� ��合、これと関連する履歴(例えばLBAと転送ブ ロック数に基づいて、連続して要求があった と判断できるもの)をまとめ、1つのコマンド� ��して予想データベースに記憶することもで� ��る。

 コントローラ156は、USBマスストレージド� ��イバ503からリード要求を受信したとき、予� ��データベースの転送ブロック数を参照する� ��とで、転送データ容量(リードすべき全デー タ)を予測することができる。コントローラ15 6は、64kB以上のデータ転送が行われると予測� ��た場合、USBホストコントローラドライバ504� ��予想データベースに記載された64kB以上のデ ータを転送するようにリード要求を行い、転 送されたデータをキャッシュメモリ158A~158Cの いずれかに格納する。

 このデータを格納したキャッシュメモリ� ��リード用キャッシュメモリとなる。 コン� �ローラ156は、USBマスストレージドライバ503� �ら転送されるリード要求に応じて、順次リ� �ド用キャッシュメモリのデータを転送する� �なお、上位側ドライバ151が、リードすべき� �データのアクセス情報を送信した場合は、� �ード用キャッシュメモリに正確に全データ� �キャッシュすることができるが、アプリケ� �ション101が直接USBマスストレージドライバ50 3にリード要求を行う場合や上位側ドライバ15 1がリードすべき全データのアクセス情報を� �信しない場合は、コントローラ156が上位側� �らリード要求を受信したときに予想データ� �ースを作成する必要がある。この場合、上� �のように履歴データベースを参照すればよ� �。例えば、最初に64kB(あるいはそれ以下)の� �ード要求を受信したとき、そのリード要求� �連続した開始LBAから、所定倍の容量のデー� �がリードされるように予測する。この予測� �た開始LBAに対するリード要求を上位側のド� �イバから受信した場合、その予測容量分の� �ードを行い、予測したデータが全て上位側� �ドライバからリードされた場合、さらにそ� �予測リードに連続する開始LBAから、さらに� �定倍の容量のデータがリードされるように� �測する。

 以上のようにして、アプリケーション101� ��らデータのリードが行われる。

 次に、上位側ドライバ151、下位側ドライ� ��152、および外付HDD2のコントローラ22の動作� ��フローチャートを用いて説明する。図8(A)は 、上位側ドライバ151の動作を示すフローチャ ートである。上位側ドライバ151は、アプリケ ーションからリード、ライト要求を受信した とき、この要求の内容をアクセス情報として 下位側ドライバ152に送信する(s1)。また、上� �側ドライバ151は、下位側(汎用ディスクドラ� ��バ502)にリード、ライト要求を転送する(s2)� �アクセス情報は、下位側ドライバ152のデー� �ベース157に予想データベースとして記憶さ� �る。

 なお、上位側ドライバ151は、図8(B)および 図14に示すような動作を行うこともできる。� ��8(B)は、上位側ドライバ151の別の動作を示す 図であり、図14は、この動作を行う場合の上� ��側ドライバ151および下位側ドライバ152の詳� ��な構成を示す機能ブロック図である。なお� ��図6と共通する構成については、同一の符号 を付し、その説明を省略する。

 図8(B)において、上位側ドライバ151は、ア プリケーションからリード、ライト要求を受 信したとき、転送されるデータ容量が所定量 以上(例えば64kB以上)であるか否かを判断する (s5)。所定量以上でなければ要求の内容をア� �セス情報として下位側ドライバ152に転送し(s 6)、汎用ディスクドライバ502にリード、ライ� ��要求を転送する(s7)。所定量以上であれば、 図14に示すように、リード、ライト要求を直� ��下位側ドライバ152のコントローラ156に転送� ��る(s8)。この場合、汎用ディスクドライバ502 にはリード、ライト要求を転送しない。リー ド、ライト要求を直接コントローラ156に転送 することで、64kBにデータが分割されること� �く転送することができる。また、汎用ディ� �クドライバ502、およびUSBマスストレージド� �イバ503を介さないため、処理時間を短縮す� �ことができ、より高速化を期待できる。転� �されるデータ容量が所定量以上でなければ� �USBマスストレージドライバ503が一度にデー� �を処理することができるため、下位側(汎用� ��ィスクドライバ502)に転送するようにしてい る。

 なお、s5の処理に換えて、リード要求で� �るか否かの判断としてもよい。リード要求� �あれば直接下位側ドライバ152のコントロー� �156に転送する。コントローラ156では、上位� �(USBマスストレージドライバ)からリード、ラ イト要求を受信したときに予測処理を行うた め、特に、リード時には予測結果に基づいて ある程度のデータ容量をデバイス側から読み 出し、キャッシュしてから上位側に返信する ため、その分の遅延が生じる可能性がある。 そのため、リード要求時には上位側ドライバ 151からコントローラ156に直接この要求を転送 し、予測処理やキャッシュ処理を行わず、転 送時間(転送開始までの時間)を短縮すること� ��できる。

 なお、リード要求であるか否かの判断とs 5の判断とをいずれか1つ行うようにしてもよ� ��し、両方行ってもよい。なお、その他の判� ��手法を用いてもよい。例えば、デバイス側� ��ら予めデータを読み出しておき、キャッシ� ��しておくことを重視する場合(アプリケーシ ョンが同じデータ内容にアクセスすることを 繰り返すような場合)、リード要求時におい� �も直接コントローラ156に要求を転送せずに� �下位側に転送する。上位側ドライバ151が下� �側ドライバ152のコントローラ156に直接リー� �、ライト要求を転送する場合、キャッシュ� �モリにデータが蓄積されない。そのため、� �プリケーションが同じファイルにアクセス� �るような場合であればキャッシュメモリに� �ータが蓄積されるように下位側に転送すれ� �よい。ただし、下位側ドライバ152がデータ� �転送するとともに、このデータをキャッシ� �メモリにコピーすることで、直接リード、� �イト要求を受信した場合であっても、デー� �を蓄積することが可能である。この場合、RA M上のコピーであるため、コピー速度は高速� �あり、処理速度が著しく低下することはな� �。

 図9は、下位側ドライバ152の動作を示すフ ローチャートである。上位側ドライバ(USBマ� �ストレージドライバ503またはアプリケーシ� �ン101)からリード要求、ライト要求、または� ��の他の要求を受信するとこの動作を開始す� ��。

 まず、下位側ドライバ152は、アクセス予� ��を行う(s11)。アクセス予測は、上位側ドラ� �バ151から送信されたアクセス情報や履歴デ� �タベースを参照することで行う。また、以� �のようにして、精密にアクセス予測を行っ� �もよい。

 (1)ファイルシステムに基づく予測
 この予測手法は、外付HDD2のファイルシステ ムを解析することでアクセス予測を行う手法 である。HDDのファイルシステムが、例えばFAT ファイルシステムフォーマットである場合、 ファイル管理領域を参照することで、個々の ファイルの記録位置(セクタ)やサイズを判断� ��ることができる。よって、上位側のアプリ� ��ーションやドライバからリード要求が有っ� ��とき、その要求が示す記録位置に対応する� ��ァイルのデータにアクセスが有ると予測す� ��。またファイルサイズ以上のリードを行わ� ��いように予測することで、必要以上のリー� ��をせずに、無駄な処理時間を削減する。

 なお、このファイル管理領域は、頻繁に� ��クセスを行う領域であるため、リード用キ� ��ッシュメモリにリードし、保持しておいて� ��よい。都度、外付HDD2にアクセスしなくとも 、リード用キャッシュメモリに保持している ファイル管理領域にアクセスすることで、ア クセス予測の処理時間を削減することができ る。

 (2)デバイス種別、コンテンツ種別に基づく� ��測
 この予測手法は、接続される対象デバイス� ��タイプ(上記実施形態ではHDD)や転送すべき� �ータのファイル構成(コンテンツ種別)に基づ いてアクセス予測を行う手法である。例えば 、接続されるデバイスがDVD-ROMであり、この� �バイスにDVD-Videoメディアが挿入されている� �合、順次リードがされ、ライト要求がされ� �ことがない。そのため、リード用キャッシ� �メモリの容量一杯までデータがキャッシュ� �れるように予測データベースを作成する。� �お、リード用キャッシュメモリにキャッシ� �したデータが全てリードされた場合、即時� �のキャッシュを破棄し、新たなデータをキ� �ッシュすれば、効率的にリード用キャッシ� �メモリを用いることができる。

 また、キャッシュメモリの数および容量� ��変化させる場合、デバイス種別に基づいて� ��化させることができる。例えば、上記のよ� ��にDVD-Videoメディアが挿入されている場合、� ��イト要求されることがないため、リード用� ��ャッシュメモリの数を増やし、その容量も� ��きく設定する。逆に未書き込みのDVD-Rメデ� �アが挿入されている場合、主にライト要求� �されるため、ライト用キャッシュメモリの� �を増やし、その容量を大きく設定する。

 (3)転送速度の解析に基づく予測
 この予測手法は、上記デバイス種別、コン� ��ンツ種別に基づく予測の応用例であり、デ� ��イス種別に応じてデータ転送速度の傾向を� ��断し、これに基づいてアクセス予測を行う� ��法である。例えば、多層型DVDメディアが接� ��される場合、各層の境界線を越えるランダ� ��アクセスは、転送速度が非常に遅くなる。� ��のため、各層の境界線をまたぐアクセスの� ��度が低くなるようにキャッシュするように� ��て、予測データベースを作成する。

 また、キャッシュメモリの数および容量� ��変化させる場合には、このデバイス種別や� ��ータ転送速度の傾向に基づいて変化させる� ��ともできる。例えば、対象デバイスとのデ� ��タ転送速度が遅い場合(例えばUSB MO(光磁気� ��ィスク)のように4MB/s程度である場合)、キャ ッシュメモリの容量を大きくして大量にデー タをキャッシュしても、そもそもデータ転送 速度が遅いために転送速度の向上が望めない 。そのため、対象デバイスとのデータ転送速 度が遅い場合、キャッシュメモリの容量を小 さく設定し、RAMの消費を抑える。

 (4)リード要求時に1度に転送するデータを徐 々に増加させる手法
 この予測手法は、リード要求時に、上記(1)~ (3)の手法で予測したリード要求に基づいて、 対象デバイスから一度にデータ転送しないよ うに、予測データベースを修正する(分割す� �)手法である。例えばリード要求の所定倍(例 えば4倍)の容量のデータをまずキャッシュす� ��ように予測データベースを修正する。この� ��ャッシュしたデータが、結果的に全て上位� ��に転送される場合、さらに所定倍の容量の� ��ータをキャッシュするように予想データベ� ��スを修正する。順次、キャッシュするデー� ��の容量を大きくすることで、転送時間を抑� ��ることができる。また、実際の要求が予想� ��ータベースと異なり、その後リードが無か� ��た場合に無駄となるデータ量を削減するこ� ��ができる。また、都度キャッシュメモリの� ��量を変化させることで、RAMの消費を抑える� ��ともできる。なお、予想データベースの修� ��処理は、実際にリードを行うとき(後述のs29 の処理時)に行ってもよい。

 以上のようにして、アクセス予測を行う� ��なお、キャッシュメモリの数および容量は� ��ーザが手動で設定することができる。また� ��ライト用キャッシュメモリ、リード用キャ� ��シュメモリの確保数もユーザが設定するこ� ��ができる。ユーザがリードを優先したい場� ��はリード用キャッシュメモリの数を増やし� ��ライトを優先したい場合はライト用キャッ� ��ュメモリの数を増やす。

 次に、図9において、下位側ドライバ152は 、上側から送信された要求の内容を判断する (s12)。リード、ライトの要求でなければ、対� ��デバイスが他のリード、ライト等の処理を� ��っているか否かを判断し(s13)、処理が空い� �いればこの要求を下位側に転送する(s14)。他 の処理を行っていればこの要求をコマンドキ ューに登録する(s15)。コマンドキューに登録� ��ておけば、後に処理が空いたときに実行す� ��ことができる。また、FLUSH CACHEコマンドの� ��うな、ライト用キャッシュメモリのデータ� ��書き込み指示するようなコマンドを受領し� ��場合、このときにライト用キャッシュメモ� ��にキャッシュされているデータを下位側へ� ��送する。

 s12において、下位側ドライバ152は、リー� ��、ライトの要求であると判断した場合、キ� ��ッシュメモリを参照する(s16)。ここで、上� �側からの要求がリード要求であり、リード� �キャッシュメモリまたはライト用キャッシ� �メモリに該当するデータがキャッシュされ� �いれば、これを上側に転送し、コマンド終� �を返信する(s17)。

 s12において、下位側ドライバ152は、上位� ��からの要求が連続したライト要求であると� ��断した場合、ライト用キャッシュメモリに� ��続してデータを書き込み、コマンド終了を� ��信する(s18)。その後、ライト用キャッシュ� �モリの容量が一杯であるかを判断し(s19)、容 量が一杯でなければタイマを起動させ(s20)、� ��作を終える。

 s19において、ライト用キャッシュメモリ� ��容量が一杯であれば、対象デバイスが他の� ��ード、ライト等の処理を行っているか否か� ��判断し(s21)、処理が空いていればライト要� �を下位側に送信し、キャッシュしたデータ� �転送する(s22)。他の処理を行っていればこの ライト要求をコマンドキューに登録する(s23)� ��コマンドキューに登録しておけば、後に処� ��が空いたときに実行することができる。

 s16において、下位側ドライバ152は、上位� ��からの要求に該当するキャッシュデータが� ��いと判断した場合、予想データベースを参� ��し、上位側からの要求と予想データベース� ��内容を比較する(s24)。上位側からの要求と� �想データベースの内容が不一致(LBAや転送ブ� ��ック数が不一致)であれば、この要求をその まま下位側に転送する(s25)。なお、このとき� ��下位側が他の処理を行っていればコマンド� ��ューに登録し、後に実行するようにしても� ��い。

 上位側からの要求がライト要求であり、� ��想データベースの内容と一致(LBAや転送ブロ ック数が一致)すれば、ライト用キャッシュ� �モリを確保する(s26)。ここで、空きキャッシ ュメモリが有れば、そのキャッシュメモリを ライト用キャッシュメモリとして確保し、キ ャッシュメモリが全てライト用またはリード 用に用いられていた場合、最も過去に更新し たキャッシュメモリの内容を消去してライト 用キャッシュメモリを確保する。なお、ライ ト用キャッシュメモリのデータは、リード用 キャッシュメモリのデータとしても使用可能 である。

 その後、確保したライト用キャッシュメ� ��リに上位側から転送されるデータを保存し� ��コマンド終了を返信する(s27)。

 s24において、下位側ドライバ152は、上位� ��からの要求がリード要求であり、予想デー� ��ベースの内容と一致(LBAや転送ブロック数が 一致)すると判断した場合、リード用キャッ� �ュメモリを確保する(s28)。上記と同様、空き キャッシュメモリが有ればこれをリード用キ ャッシュメモリとし、空きが無ければ最も過 去に更新したキャッシュメモリの内容を消去 してリード用キャッシュメモリを確保する。

 その後、予想データベースに基づいて、� ��想分のリード要求を下位側に送信し、リー� ��用キャッシュメモリにデータをキャッシュ� ��る(s29)。このとき、一度に大量のデータを� �ャッシュするのではなく、複数回に分けて� �ータキャッシュしてもよい。この場合、残� �のリード要求はコマンドキューに登録する� �リード要求を複数に分割することで、キャ� �シュ済みデータを上位側のドライバへ転送� �ながら、それと並行して、次に連続するリ� �ドデータをキャッシュすることができ、USB� �スの使用率向上が期待できる。

 次に、図10は、下位側からのコマンド終� �割り込みがあった場合の動作を示すフロー� �ャートである。

 まず、下位側ドライバ152は、下位側から� ��信したコマンド終了が、ライト用キャッシ� ��メモリにキャッシュしておいたデータを書� ��終えた旨を示すコマンドであるか否かを判� ��する(s31)。ライト用キャッシュメモリのデ� �タが書き終わった場合は、このライト用キ� �ッシュメモリをリード用キャッシュメモリ� �変更する(s32)。なお、ライト用キャッシュメ モリをリード用キャッシュメモリに変更する タイミングは、このタイミングに限るもので はない。また、上述のように、ライト用キャ ッシュメモリのデータをリード用キャッシュ メモリのデータとして用いることも無論可能 である。

 その後、下位側ドライバ152は、上位側に� ��して終了報告(転送)が必要なコマンドであ� �か否かを判断する(s33)。必要であれば上位側 にコマンド終了を返送する(s34)。

 さらに、下位側ドライバ152は、コマンド� ��ュー160を参照し、キューイングされたコマ� ��ドが存在するか否かを判断する(s35)。キュ� �イングされたコマンドが存在すれば、これ� �下位側に転送する(s36)。

 次に、図11は、タイマ割り込み、ドライ� �初期化時、ドライバ終了時の動作を示すフ� �ーチャートである。

 まず、同図(A)は、タイマ割り込み動作を� ��すフローチャートである。下位側ドライバ1 52は、タイマがタイムアップするとこの動作� ��開始する。下位側ドライバ152は、ライト用� ��ャッシュメモリにデータがキャッシュされ� ��いるか否かを確認する(s41)。キャッシュさ� �ていれば、下位側にライト要求を送信し、� �イト用キャッシュメモリにキャッシュされ� �いるデータを下位側に転送し(s42)、動作を終 える。ライト用キャッシュメモリにデータが キャッシュされていなければ動作を終える。

 同図(B)は、ドライバ終了時の動作を示す� ��ローチャートである。PCのシャットダウン� �、外付HDD2の接続を解除する時にこの動作を� ��始する。下位側ドライバ152は、履歴データ� ��ースを外付HDD2またはOS11に転記して保存す� �(s51)。

 同図(C)は、ドライバ初期化時の動作を示� ��フローチャートである。PC1を再起動したり� ��外付HDD2を再接続した場合にこの動作を開始 する。下位側ドライバ152は、履歴データベー スを外付HDD2またはOS11から読み出し、RAMに展� ��してデータベース157を構築する(s61)。

 次に、図12は、外付HDD2のコントローラ22� �動作を示すフローチャートである。コント� �ーラ22は、PC1側からコマンドを受信したとき にこの動作を開始する。まず、コントローラ 22は、受信したコマンドが、所定のサイズ(1MB )よりも大きいデータをリード、ライトする� �のであるかを判断する(s71)。所定のサイズ(1M B)以下であればそのままHDD23に書き込み、ま� �は読み出しを行う(s73)。

 一方、所定のサイズ(1MB)よりも大きいデ� �タをリード、ライトするものであった場合� �このコマンドを所定のサイズ(1MB以下)に分割 し(s72)、順次、HDD23に書き込み、または読み� �しを行う(s73)。

 なお、上記実施形態では、上位側ドライ� ��151、下位側ドライバ152を実現し、汎用ディ� ��クドライバ502、またはUSBマスストレージド� ��イバ503に接続される例を示したが、USBマス� ��トレージドライバを専用ドライバに置き換� ��る形でも、本発明のデバイスコントローラ� ��実現することができる。図13は、USBマスス� �レージドライバを専用ドライバに置き換え� �場合の例を示す機能ブロック図である。な� �、図5と共通する構成については同一の符号� ��付し、その説明を省略する。

 この例では、USBホストコントローラドラ� ��バ504、汎用ディスクドライバ502、およびア� ��リケーション101に接続される専用USBマスス� ��レージクラスドライバ171を備えている。専� ��USBマスストレージクラスドライバ171は、従� ��の標準のUSBマスストレージドライバを置き� ��えるものである(図1を参照)。

 この専用USBマスストレージクラスドライ� ��171は、上記実施形態と同様に、キャッシュ� ��モリを内蔵しており、上位側から受信した� ��ード、ライト要求に応じてデータをキャッ� ��ュする。専用マスストレージクラスドライ� ��171の動作は図9から図11に示した下位側ドラ� ��バの動作と同様である。

 この例においても、アプリケーション101� ��64kB毎にデータを分割して、リード/ライト� �要求を発行する場合は、専用USBマスストレ� �ジクラスドライバ171がキャッシュメモリに� �ータをキャッシュし、データ転送する。

 なお、この専用USBマスストレージクラス� ��ライバ171は、64kBのデータ転送サイズの上限 を持たず、64kBより大きいサイズのリード/ラ� ��トの要求を処理可能なものである。したが� ��て、アプリケーション101、または汎用ディ� ��クドライバ501は、リード/ライトの要求を64k B単位に分割することなく発行することが可� �であるため、コマンド、ステータスの処理� �遅延が少なくて済み、データ転送を高速に� �ることができる。