(57)【特許請求の範囲】
【請求項１】
ユーザーアプリケーションが、ホストＯＳに対して、ファイル要求アクセスをする方法であって、
ユーザーアプリケーションが、ホストＯＳに対して、要求するファイルに対応するミラーファイル番号を送信するステップと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされているかどうかを判断するステップと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するステップと、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するステップと、
ホストＯＳが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するステップと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストＯＳ内にキャッシュされているデータを、ユーザーアプリケーションに提供するステップとを有する、
ファイル要求アクセスをする方法。
【請求項２】
請求項１に記載の方法において提供されるファイルについて、ユーザーアプリケーションが、ファイルの整合性をチェックする方法であって、
前回のファイル要求アクセスにおけるシーケンス番号と、今回のファイル要求アクセスにおけるシーケンス番号とを比較するステップと、
比較の結果、これらシーケンス番号が同一である場合には、ホストＯＳ内にキャッシュされているデータが提供されていると判断するステップと、
比較の結果、これらシーケンス番号が異なる場合には、ブロックデバイスから読み出されたデータが提供されていると判断するステップとを有する、
請求項１に記載の方法。
【請求項３】
請求項２に記載の方法において、ホストＯＳ内にキャッシュされているデータが提供されていると判断される場合には、ユーザーアプリケーションが、ホストＯＳに対して、要求するファイルに対応するミラーファイル番号の次のミラーファイル番号を送信するステップとを有する、
請求項２に記載の方法。
【請求項４】
シーケンス番号の変更が、シーケンス番号の増加である、
請求項１に記載の方法。
【請求項５】
ユーザーアプリケーションが、ホストＯＳに対して、ファイル要求アクセスをするシステムであって、
ユーザーアプリケーションが、ホストＯＳに対して、要求するファイルに対応するミラーファイル番号を送信し、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされているかどうかを判断し、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求し、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出し、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供し、
ホストＯＳが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供し、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストＯＳ内にキャッシュされているデータを、ユーザーアプリケーションに提供する、
ファイル要求アクセスをするシステム。
【請求項６】
（ユーザーアプリケーションから）ホストＯＳを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する方法であって、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するステップとを有する、
読み出し要求に応答する方法。
【請求項７】
（ユーザーアプリケーションから）ホストＯＳを経由して送信されてくるミラーファイル番号に基づいて、データの読み出し要求に応答する、ブロックデバイス内に設けられた、ファイルシステムであって、
要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、
取得したメモリのアドレスのデータを読み出し、
読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供する、
ファイルシステム。
【請求項８】
（ユーザーアプリケーションから）ホストＯＳを経由して送信されてくるミラーファイル番号に基づいて、データの読み出し要求に応答するために、ブロックデバイス内に設けられる、ミラーファイルエントリーテーブル（ＭＦＥＴ）であって、
要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得することができるように、
セクタ番号、そのセクタ番号に対応する実際のコンテンツが格納された（ブロックデバイス内に設けられる）メモリのアドレス、および、データの読み出しの要求がある度に（ファイルシステムエミュレータによって）変更されるシーケンス番号が対応付けられている、
ＭＦＥＴ。
【請求項９】
外部から送信されてくる、要求するファイルに対応するミラーファイル番号に対して、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされているかどうかを判断するステップと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するステップと、
ブロックデバイスが、要求のあったミラーファイル番号から、対応するコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するステップと、
ホストＯＳが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するステップと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストＯＳ内にキャッシュされているデータを、（外部に）提供するステップとを有する、
ファイル要求アクセスをする方法。
【請求項１０】
ホストＯＳおよびブロックデバイスによって実行されるプログラムであって、
外部から送信されてくる、要求するファイルに対応するミラーファイル番号に対して、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされているかどうかを判断するプログラムコードと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するプログラムコードと、
ブロックデバイスが、要求のあったミラーファイル番号から、対応するコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するプログラムコードと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すプログラムコードと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するプログラムコードと、
ホストＯＳが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するプログラムコードと、
ホストＯＳが、送信されてきたミラーファイル番号のデータが、ホストＯＳ内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストＯＳ内にキャッシュされているデータを、（外部に）提供するプログラムコードとを有する、
プログラム。
【請求項１１】
（外部から）ホストＯＳを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する方法であって、
ブロックデバイスが、要求のあったミラーファイル番号から、対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するステップとを有する、
読み出し要求に応答する方法。
【請求項１２】
（外部から）ホストＯＳを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する、ブロックデバイスによって実行されるプログラムであって、
ブロックデバイスが、要求のあったミラーファイル番号から、対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するプログラムコードと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すプログラムコードと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供するプログラムコードとを有する、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理性能の異なる機器間にわたっているファイル要求アクセスを、効果的に制御する方法に関する。
【背景技術】
【０００２】
ミリ波による高速ダウンロードが実現され、slatedevice や携帯端末での利用シーンが検討されている。ミリ波のスピードは端末の外部インターフェイスに比べ圧倒的に速いため、現状の slate device や携帯端末の外部インターフェイスに直接ミリ波を接続してもミリ波の高速ダウンロードの恩恵が得られない。
【０００３】
ミリ波は普及前段階にあるが、今後slatedevice や携帯端末の内蔵デバイスとして採用されるためには、特殊なデバイスドライバや新たな高速外部インターフェイスといった端末への大きな変更が無いほうが望ましい。  
【０００４】
もし現在標準的に使用されているインターフェイス経由の外付けのデバイスとしてミリ波デバイスがあり、おなじくすでに端末が持っているデバイスドライバ等で操作が可能であれば、ミリ波のような新しいテクノロジーの端末への導入が容易になる。
【０００５】
そこで、これらを鑑みた上で最適な構成として、ミリ波受信機と記憶領域が一体化した外部記憶装置が考えられる。
【０００６】
無線受信機(Rx)は外部記憶装置側に存在し、端末からは無線受信機(Rx)の制御を行い、ダウンロードコンテンツは直接装置内部の記憶領域に書き込まれる。ユーザ端末からは、必要なときに記憶領域に書き込まれたダウンロードコンテンツを読み出す。
【０００７】
外部記憶装置へのアクセスは、OSの標準ファイルインターフェイスで行い、ダウンロードコンテンツの読み出しと、無線受信機(Rx)の制御も同様に標準ファイルインターフェイスで行う。
【０００８】
しかし、このような外部記憶装置の制御、および、受信したコンテンツの管理には、次の技術的困難がある。
【０００９】
OSによるキャッシュの問題  ：  OSのキャッシュによって、外部記憶装置のデータがキャッシュされてしまう。このファイルシステムのキャッシュにより、外部記憶装置側に新しいデータが到達してもOS側が新しいデータを認知しない。
【００１０】
受信機のハードウエアが持つレジスタ操作のリード・ライトがキャッシュされ、正常なレジスタ操作ができない
【００１１】
キャッシュが有効な場合、先読み等により高速動作が可能であるが、動的に変化するコンテンツの場合、先読みが自立的に行われてしまうため誤動作の可能性がある。
【００１２】
一方キャッシュがない場合は、毎回ハードウエアの実アクセスを行うため、アクセス速度が低下する。
【００１３】
特許文献１は、SD card に Wifi の送受信機を一体化して、SD card のデータを、他の Wifi enableな機器やクラウド上のストレージにレプリケートすることによって、容量が無限大のＳＤカードのように見えるようにする技術を開示している。
【００１４】
しかし、特許文献１で扱っているものは、SDcard から外部方向へのデータ転送であり、本願発明で取り扱おうとしているものとは真逆のデータの流れである。
【００１５】
データの流れが真逆であるが故の問題（OSでキャッシュされてしまうと SD側でのコンテンツに変更があっても OS に通知する手段が標準入出力には用意されていない）を本願発明では解決しようとしている。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】米国特許第７７０２８２１Ｂ２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
受信機を内蔵し、受信機が受信したデータを直接記憶領域に書き込む外部記憶装置において、ＯＳによるキャッシュの問題を回避可能にして、受信機の制御とダウンロードを可能とする方法が望まれる。
【課題を解決するための手段】
【００１８】
ホストＯＳに対して、要求するファイルに対応するミラーファイル番号を送信する。
【００１９】
ホストＯＳ内にキャッシュされているかどうかを判断し、送信されてきたミラーファイル番号のデータが、キャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求する。
【００２０】
ブロックデバイスが、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、取得したメモリのアドレスのデータを読み出す。読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストＯＳに提供する。
【００２１】
ホストＯＳ内にキャッシュされていると判断される場合には、ホストＯＳ内にキャッシュされているデータを提供する。
【発明の効果】
【００２２】
OSによるキャッシュの問題（OSのキャッシュによって、外部記憶装置のデータがキャッシュされてしまう。このファイルシステムのキャッシュにより、外部記憶装置側に新しいデータが到達してもOS側が新しいデータを認知しない。）を解決することができる。
【図面の簡単な説明】
【００２３】
【図１】図１は、本発明であるファイル要求アクセスを制御するシステムの全体構成を示す。
【図２】図２は、本発明におけるデータの流れを示す。
【図３】図３は、シーケンス番号（ＳＮ：Sequencenumber）の動作をより詳細に示す。
【図４】図４は、ユーザーアプリケーション１０、ホストＯＳ２０、ブロックデバイス３０内部のファイルシステムエミュレータ、メモリの動作の流れを示す。
【図５】図５は、キャッシュの有無をチェックするためのファイル整合性チェック部分のフローを示す。
【図６】図６は、コンテンツテーブル および Mirror File Entry Table（ＭＦＥＴ）の構造を示す。
【発明を実施するための形態】
【００２４】
図１は、本発明であるファイル要求アクセスを制御するシステムの全体構成を示す。
【００２５】
ユーザーアプリケーション（Userapplication）１０、ホストＯＳ（ホストシステム）２０、ブロックデバイス（Block device）３０、が接続される関係として示されている。
【００２６】
ブロックデバイス３０内部には無線受信機（mmWave transceiver）３１が存在し、受信したコンテンツは直接メモリ（Memory(Flash, DRAM等)）３２へと格納される。
【００２７】
ミリ波などの広帯域無線通信で受信されるデータは非常に高速であるため、たとえばホストＯＳ側が、携帯端末やタブレット端末のような外部インターフェイスに低速の I/F しか持たない端末の場合、その低速の I/F に受信速度が制限されてしまい、無線側の広帯域を生かせない。
【００２８】
無線受信機３１によって受信したコンテンツは、直接、ブロックデバイス３０内部のメモリ３２へ格納される。  無線受信機３１のハードウエアを制御するためのレジスタ（Register file for transceiver）３３もブロックデバイス３０内部に存在する。
【００２９】
メモリ３２やレジスタ３３へのアクセスは、調停回路(Arbiter)３４によって制御され、ホストＯＳ２０からのデータ操作と無線受信機からのデータ操作の両方を制御する。
【００３０】
ホストＯＳ２０からのアクセスは、通常、ホストＯＳ上で動作するユーザーアプリケーション１０によって起動される。
【００３１】
ユーザーアプリケーション１０が、ブロックデバイス３０内部のメモリ３２や、ブロックデバイス３０内部の無線受信機３１の制御をレジスタ３３経由で行いたい場合、本発明の構成においては、ホストＯＳ２０に標準的に備わっている標準ファイルIO(Standard file IO) ２２を用いて操作する。
【００３２】
具体的には、ホストＯＳ２０の管理する通常のファイルと同様の操作であり、ファイルを open し、ファイルに対するread/write が、OSの標準API経由でデバイスドライバ(Standard device driver) ２４を通り、物理インターフェイス（Interface）２６を経て、ブロックデバイス３０へのアクセスとなる。
【００３３】
インターフェイス２６経由で要求のあったread/writeのアクセスは、ブロックデバイスのインターフェイス（Interface）３５を通過してブロックデバイス内部へと伝わる。
【００３４】
本発明の特徴的な構成では、この要求のあったアクセスはファイルシステムエミュレータ（File System Emulator）３６によって解釈され、ブロックデバイス３０内部のどのファイルに対するアクセスが発生したのかをアクセスされたファイルのセクタの値（番号）から検出し、それが後述のミラーファイルであるか否かを判定するとともに、ミラーファイルであればそのシーケンス番号（Sequence number）を変化（変更）させる。
【００３５】
ホストＯＳ２０からのアクセスが read (ブロックデバイスからホストへデータを送る)場合であれば、シーケンス番号（Sequence number）を返答データの末尾に付加する。
【００３６】
この シーケンス番号（Sequence number）の付加されたデータは、ホストＯＳ２０を経由して ユーザーアプリケーション１０へと返信して提供され、ユーザーアプリケーション１０は受け取ったシーケンス番号（Sequence number）を参照して、受けとったデータが実際にブロックデバイスから返信されたデータであるか否かを判定する。詳細は後述する。
【００３７】
図２は、本発明におけるデータの流れを示す。
【００３８】
ユーザーアプリケーション１０が標準ファイルI/O２２経由でファイルアクセスを行うと、アクセス対象のファイルの格納されているセクタが（ホスト）ＯＳ２０によって調べられ、そのセクタに対するアクセス要求がブロックデバイス３０へ送られる。
【００３９】
通常のブロックデバイスであれば、セクタから直接ブロックデバイス３０内部のメモリ３２のアドレスを計算して、そのアドレスのメモリにアクセスする。
【００４０】
本発明の構成においては、ブロックデバイス３０内部でいったんセクタの値をファイルシステムエミュレータ（File System Emulator）３６が解釈し、通常のブロックデバイス同様に直接メモリ３２へアクセス可能なセクタなのか、それともミラーファイルなのかを区別する。
【００４１】
ここで、「ミラーファイル」とは、ＯＳ２０内のファイルシステム上ではそれぞれ異なったファイルとして参照されるが、ブロックデバイス３０内部の実際のメモリが同一の場所であるファイルである。
【００４２】
図２においては、ＯＳ２０から参照するファイルシステム上の Mirror file #1 から Mirror file#n がすべてミラーファイルであり、ＯＳ２０からは物理的に異なるファイルとして参照されるが、ブロックデバイス３０内のメモリ内部のデータとしては同一のアドレス先のデータを参照する。
【００４３】
本発明の構成では、ミラーファイルの参照する先として、ブロックデバイス内部のメモリでも、無線受信機制御のためのレジスタ群(Register file for transceiver)３３であってもよい。
【００４４】
さらに本発明では、このミラーファイルのデータの末尾には、シーケンス番号（ＳＮ：Sequence number）という、そのファイルにブロックデバイス３０内部でアクセスが発生するたびに変更される（典型的には、増加する）値を付加する。
【００４５】
図３は、シーケンス番号（ＳＮ：Sequencenumber）の動作をより詳細に示す。
【００４６】
シーケンス番号（Sequence number）は、ブロックデバイス３０に実際のファイルアクセスが発生するたびに値が変更（増加）する。これを用いることで、ユーザーアプリケーション１０の側で、ＯＳ２０によるファイルのキャッシュの有無の判定が可能となる。
【００４７】
図３の例では、ユーザーアプリケーション１０から２回のファイルアクセスを行った場合に関して、ＯＳ２０のファイルキャッシュの有無で、シーケンス番号（Sequence number）の動作がどのように異なるかを例として示す。
【００４８】
図３の左の図は、ＯＳ２０によりファイルがキャッシュされる場合の動作を示したものである。ユーザーアプリケーションからファイルへの最初のアクセスが発生すると、ＯＳにそのリクエストが到達し、ＯＳはその時点でのキャッシュの有無をチェックする。
【００４９】
図３の左の図のように、最初のアクセスではＯＳ２０にはキャッシュがないため、ブロックデバイス３０への実アクセスが発生する。ブロックデバイス３０はファイルアクセスを検出し、Sequence Number(ＳＮ)の値を増加させ、ブロックデバイス３０内部のメモリに格納されている最新の対象ファイルのデータにアクセスしＯＳ２０へデータを返答する。その際にＳＮ をデータに（末尾などに）付加する。ＯＳ２０は、受け取ったデータをユーザーアプリケーションへ返答して最初のファイルアクセスは完了する。
【００５０】
引き続き２回目のファイルアクセスを同一ファイルに行った場合、今度は ＯＳ２０がキャッシュを持っているためＯＳ２０はそのキャッシュの内容をユーザーアプリケーション１０へと返答する。そのためブロックデバイス３０への実アクセスは発生せず、２回目のファイルアクセスは終了となる。
【００５１】
ここで、ユーザーアプリケーション１０側は、最初と２回目のアクセスで得られたデータ（の末尾）に付加されているＳＮ の値を比較する。ＳＮの値が同一であることから、ユーザーアプリケーションはこの２回目のデータはキャッシュであり、２回目のデータはブロックデバイス３０への実アクセスをしていない古いデータ（キャッシュ）であることが判定可能となる。
【００５２】
図３の右の図は、ＯＳ２０によるキャッシュがない場合について示したものである。最初のファイルアクセスではＯＳ２０はキャッシュがないためブロックデバイス３０へと実アクセスが発生し、ブロックデバイス３０内部ではＳＮ の値を増加させその値をファイルのデータ（の末尾など）に付加して返答する。２回目のファイルアクセスが発生しても、ＯＳ２０はキャッシュをしないためブロックデバイス３０への実アクセスが再度発生し、ブロックデバイス３０内部ではＳＮが同様に増加し、その値をファイルのデータ（の末尾など）に付加して返答する。
【００５３】
ユーザーアプリケーション１０では、１回目、２回目のアクセスで得られたデータの末尾を比較すると値が異なるため、ＯＳ２０によるキャッシュが無く、２回目も１回目同様にブロックデバイス３０への実アクセスをした最新のデータであることが判定可能となる。
【００５４】
図４は、ユーザーアプリケーション１０、ホストＯＳ２０、ブロックデバイス３０内部のファイルシステムエミュレータ、メモリの動作の流れを示す。
【００５５】
図５は、キャッシュの有無をチェックするためのファイル整合性チェック部分のフローを示す。
【００５６】
図６は、コンテンツテーブル および Mirror File Entry Table（ＭＦＥＴ）の構造を示す。
【００５７】
ユーザーアプリケーション１０が、ＯＳ２０の標準ファイルI/O ２２経由で、ファイルをアクセスした際に、ブロックデバイス３０側のファイルシステムエミュレータ３６が、ミラーファイルについての判定のために参照するものが、 Mirror File Entry Table（ＭＦＥＴ）３７である（図１参照）。
【００５８】
ブロックデバイス３０内部の無線受信機３１によってダウンロードされたコンテンツは、図６（ａ）のコンテンツテーブルを用いて、各コンテンツがどのアドレス範囲内部に格納されているかを記憶する。
【００５９】
図６（ｂ）はミラーファイルの情報を管理するMirror File Entry Table（ＭＦＥＴ）であり、ミラーファイルとコンテンツの格納されたメモリのアドレスの関連付けと Sequence Number（ＳＮ）の管理を行う。
【００６０】
コンテンツがダウンロードされると、ミラーファイルが複数個（この図の例では６４個）がファイルシステム上に作成され、各ミラーファイルのＯＳ２０から参照される際のセクタがミラーファイルごとに決定する。
【００６１】
そのセクタ番号が  ＭＦＥＴ の第１列のセクタ部分に記録される。
【００６２】
第２列はファイルシステム上、対応するミラーファイルのファイル名を参考までに示しているが、このファイル名の情報はＭＦＥＴ自身が記憶する必要はかならずしも無い。（ファイル名とセクタの対応付けは、ＯＳ２０が参照するファイルシステム本体部分に通常通り記されているためである）。
【００６３】
第３列には、各ミラーファイルに対応する実体のコンテンツがメモリ上のどのアドレスに記録されているかを格納する。
【００６４】
第４列は参考として対応する実体のコンテンツのファイル名を示しているがＭＦＥＴ自身が記憶する必要は必ずしも無い。（この対応付けは図６（ａ）のコンテンツテーブルを参照することで判定可能なためである）。
【００６５】
そして、第５列に  SequenceNumber（ＳＮ）を記録する。
【００６６】
ＯＳ２０経由でアクセスのあったファイルがミラーファイルかどうかの判定は、アクセスのあったファイルのセクタ番号がＭＦＥＴの第１列のセクタに合致するか否かをチェックし、該当セクタがあった場合はミラーファイルであると判定できる。
【００６７】
ミラーファイルであると判定された後は、ファイルのアクセスを、ＭＦＥＴの第３列で示されるブロックデバイス３０内部のメモリのアドレスに対して行うことで、複数のミラーファイルからのアクセスを、実体がひとつだけのブロックデバイス３０内部のメモリに格納された最新のコンテンツに対して行うことが可能となる。
【符号の説明】
【００６８】
１０  ユーザーアプリケーション（Userapplication）
２０  ホストＯＳ
３０  ブロックデバイス（Block device）
３６  ファイルシステムエミュレータ（FileSystem Emulator）
３７  ミラーファイルエントリーテーブル（MirrorFile Entry Table）（ＭＦＥＴ）
【図１】
0005798459.tif 000002
【図２】
0005798459.tif 000003
【図３】
0005798459.tif 000004
【図４】
0005798459.tif 000005
【図５】
0005798459.tif 000006
【図６】
0005798459.tif 000007