特許第5798459号(P5798459)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧

<>
  • 特許5798459-ファイル要求アクセスを制御する方法 図000002
  • 特許5798459-ファイル要求アクセスを制御する方法 図000003
  • 特許5798459-ファイル要求アクセスを制御する方法 図000004
  • 特許5798459-ファイル要求アクセスを制御する方法 図000005
  • 特許5798459-ファイル要求アクセスを制御する方法 図000006
  • 特許5798459-ファイル要求アクセスを制御する方法 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5798459
(24)【登録日】2015年8月28日
(45)【発行日】2015年10月21日
(54)【発明の名称】ファイル要求アクセスを制御する方法
(51)【国際特許分類】
   G06F 13/10 20060101AFI20151001BHJP
   G06F 12/00 20060101ALI20151001BHJP
【FI】
   G06F13/10 330B
   G06F12/00 514K
【請求項の数】12
【全頁数】13
(21)【出願番号】特願2011-259178(P2011-259178)
(22)【出願日】2011年11月28日
(65)【公開番号】特開2013-114397(P2013-114397A)
(43)【公開日】2013年6月10日
【審査請求日】2014年6月17日
(73)【特許権者】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MACHINES CORPORATION
(74)【代理人】
【識別番号】100108501
【弁理士】
【氏名又は名称】上野 剛史
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(74)【代理人】
【識別番号】100091568
【弁理士】
【氏名又は名称】市位 嘉宏
(72)【発明者】
【氏名】▲高▼野 光司
(72)【発明者】
【氏名】大庭 信之
(72)【発明者】
【氏名】片山 泰尚
【審査官】 寺谷 大亮
(56)【参考文献】
【文献】 国際公開第2011/109727(WO,A1)
【文献】 米国特許出願公開第2007/0073937(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 13/10
G06F 12/00
(57)【特許請求の範囲】
【請求項1】
ユーザーアプリケーションが、ホストOSに対して、ファイル要求アクセスをする方法であって、
ユーザーアプリケーションが、ホストOSに対して、要求するファイルに対応するミラーファイル番号を送信するステップと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされているかどうかを判断するステップと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するステップと、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するステップと、
ホストOSが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するステップと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストOS内にキャッシュされているデータを、ユーザーアプリケーションに提供するステップとを有する、
ファイル要求アクセスをする方法。
【請求項2】
請求項1に記載の方法において提供されるファイルについて、ユーザーアプリケーションが、ファイルの整合性をチェックする方法であって、
前回のファイル要求アクセスにおけるシーケンス番号と、今回のファイル要求アクセスにおけるシーケンス番号とを比較するステップと、
比較の結果、これらシーケンス番号が同一である場合には、ホストOS内にキャッシュされているデータが提供されていると判断するステップと、
比較の結果、これらシーケンス番号が異なる場合には、ブロックデバイスから読み出されたデータが提供されていると判断するステップとを有する、
請求項1に記載の方法。
【請求項3】
請求項2に記載の方法において、ホストOS内にキャシュされているデータが提供されていると判断される場合には、ユーザーアプリケーションが、ホストOSに対して、要求するファイルに対応するミラーファイル番号の次のミラーファイル番号を送信するステップとを有する、
請求項2に記載の方法。
【請求項4】
シーケンス番号の変更が、シーケンス番号の増加である、
請求項1に記載の方法。
【請求項5】
ユーザーアプリケーションが、ホストOSに対して、ファイル要求アクセスをするシステムであって、
ユーザーアプリケーションが、ホストOSに対して、要求するファイルに対応するミラーファイル番号を送信し、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされているかどうかを判断し、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求し、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出し、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供し、
ホストOSが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供し、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストOS内にキャッシュされているデータを、ユーザーアプリケーションに提供する、
ファイル要求アクセスをするシステム。
【請求項6】
(ユーザーアプリケーションから)ホストOSを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する方法であって、
ブロックデバイスが、要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するステップとを有する、
読み出し要求に応答する方法。
【請求項7】
(ユーザーアプリケーションから)ホストOSを経由して送信されてくるミラーファイル番号に基づいて、データの読み出し要求に応答する、ブロックデバイス内に設けられた、ファイルシステムであって、
要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、
取得したメモリのアドレスのデータを読み出し、
読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供する、
ファイルシステム。
【請求項8】
(ユーザーアプリケーションから)ホストOSを経由して送信されてくるミラーファイル番号に基づいて、データの読み出し要求に応答するために、ブロックデバイス内に設けられる、ミラーファイルエントリーテーブル(MFET)であって、
要求のあったミラーファイル番号のセクタ番号から、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得することができるように、
セクタ番号、そのセクタ番号に対応する実際のコンテンツが格納された(ブロックデバイス内に設けられる)メモリのアドレス、および、データの読み出しの要求がある度に(ファイルシステムエミュレータによって)変更されるシーケンス番号が対応付けられている、
MFET。
【請求項9】
外部から送信されてくる、要求するファイルに対応するミラーファイル番号に対して、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされているかどうかを判断するステップと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するステップと、
ブロックデバイスが、要求のあったミラーファイル番号から、対応するコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するステップと、
ホストOSが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するステップと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストOS内にキャッシュされているデータを、(外部に)提供するステップとを有する、
ファイル要求アクセスをする方法。
【請求項10】
ホストOSおよびブロックデバイスによって実行されるプログラムであって、
外部から送信されてくる、要求するファイルに対応するミラーファイル番号に対して、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされているかどうかを判断するプログラムコードと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求するプログラムコードと、
ブロックデバイスが、要求のあったミラーファイル番号から、対応するコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するプログラムコードと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すプログラムコードと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するプログラムコードと、
ホストOSが、ユーザーアプリケーションに対して、ブロックデバイスから提供されてきたデータを提供するプログラムコードと、
ホストOSが、送信されてきたミラーファイル番号のデータが、ホストOS内にキャッシュされていると判断される場合には、ユーザーアプリケーションに対して、ホストOS内にキャッシュされているデータを、(外部に)提供するプログラムコードとを有する、
プログラム。
【請求項11】
(外部から)ホストOSを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する方法であって、
ブロックデバイスが、要求のあったミラーファイル番号から、対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するステップと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すステップと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するステップとを有する、
読み出し要求に応答する方法。
【請求項12】
(外部から)ホストOSを経由して送信されてくるミラーファイル番号に基づくデータの読み出し要求に応答する、ブロックデバイスによって実行されるプログラムであって、
ブロックデバイスが、要求のあったミラーファイル番号から、対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更するプログラムコードと、
ブロックデバイスが、取得したメモリのアドレスのデータを読み出すプログラムコードと、
ブロックデバイスが、読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供するプログラムコードとを有する、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、処理性能の異なる機器間にわたっているファイル要求アクセスを、効果的に制御する方法に関する。
【背景技術】
【0002】
ミリ波による高速ダウンロードが実現され、slatedevice や携帯端末での利用シーンが検討されている。ミリ波のスピードは端末の外部インターフェイスに比べ圧倒的に速いため、現状の slate device や携帯端末の外部インターフェイスに直接ミリ波を接続してもミリ波の高速ダウンロードの恩恵が得られない。
【0003】
ミリ波は普及前段階にあるが、今後slatedevice や携帯端末の内蔵デバイスとして採用されるためには、特殊なデバイスドライバや新たな高速外部インターフェイスといった端末への大きな変更が無いほうが望ましい。
【0004】
もし現在標準的に使用されているインターフェイス経由の外付けのデバイスとしてミリ波デバイスがあり、おなじくすでに端末が持っているデバイスドライバ等で操作が可能であれば、ミリ波のような新しいテクノロジーの端末への導入が容易になる。
【0005】
そこで、これらを鑑みた上で最適な構成として、ミリ波受信機と記憶領域が一体化した外部記憶装置が考えられる。
【0006】
無線受信機(Rx)は外部記憶装置側に存在し、端末からは無線受信機(Rx)の制御を行い、ダウンロードコンテンツは直接装置内部の記憶領域に書き込まれる。ユーザ端末からは、必要なときに記憶領域に書き込まれたダウンロードコンテンツを読み出す。
【0007】
外部記憶装置へのアクセスは、OSの標準ファイルインターフェイスで行い、ダウンロードコンテンツの読み出しと、無線受信機(Rx)の制御も同様に標準ファイルインターフェイスで行う。
【0008】
しかし、このような外部記憶装置の制御、および、受信したコンテンツの管理には、次の技術的困難がある。
【0009】
OSによるキャッシュの問題 : OSのキャッシュによって、外部記憶装置のデータがキャッシュされてしまう。このファイルシステムのキャッシュにより、外部記憶装置側に新しいデータが到達してもOS側が新しいデータを認知しない。
【0010】
受信機のハードウエアが持つレジスタ操作のリード・ライトがキャッシュされ、正常なレジスタ操作ができない
【0011】
キャッシュが有効な場合、先読み等により高速動作が可能であるが、動的に変化するコンテンツの場合、先読みが自立的に行われてしまうため誤動作の可能性がある。
【0012】
一方キャッシュがない場合は、毎回ハードウエアの実アクセスを行うため、アクセス速度が低下する。
【0013】
特許文献1は、SD card に Wifi の送受信機を一体化して、SD card のデータを、他の Wifi enableな機器やクラウド上のストレージにレプリケートすることによって、容量が無限大のSDカードのように見えるようにする技術を開示している。
【0014】
しかし、特許文献1で扱っているものは、SDcard から外部方向へのデータ転送であり、本願発明で取り扱おうとしているものとは真逆のデータの流れである。
【0015】
データの流れが真逆であるが故の問題(OSでキャッシュされてしまうと SD側でのコンテンツに変更があっても OS に通知する手段が標準入出力には用意されていない)を本願発明では解決しようとしている。
【先行技術文献】
【特許文献】
【0016】
【特許文献1】米国特許第7702821B2号公報
【発明の概要】
【発明が解決しようとする課題】
【0017】
受信機を内蔵し、受信機が受信したデータを直接記憶領域に書き込む外部記憶装置において、OSによるキャッシュの問題を回避可能にして、受信機の制御とダウンロードを可能とする方法が望まれる。
【課題を解決するための手段】
【0018】
ホストOSに対して、要求するファイルに対応するミラーファイル番号を送信する。
【0019】
ホストOS内にキャッシュされているかどうかを判断し、送信されてきたミラーファイル番号のデータが、キャッシュされていないと判断される場合には、ブロックデバイスに対して、ミラーファイル番号のデータの読み出しを要求する。
【0020】
ブロックデバイスが、そのセクタ番号に対応する実際のコンテンツが格納されたメモリのアドレスを取得し、そのコンテンツに対応するシーケンス番号を取得して、取得したシーケンス番号を変更し、取得したメモリのアドレスのデータを読み出す。読み出されたデータを、変更されたシーケンス番号を付加したデータにして、ホストOSに提供する。
【0021】
ホストOS内にキャッシュされていると判断される場合には、ホストOS内にキャッシュされているデータを提供する。
【発明の効果】
【0022】
OSによるキャッシュの問題(OSのキャッシュによって、外部記憶装置のデータがキャッシュされてしまう。このファイルシステムのキャッシュにより、外部記憶装置側に新しいデータが到達してもOS側が新しいデータを認知しない。)を解決することができる。
【図面の簡単な説明】
【0023】
図1図1は、本発明であるファイル要求アクセスを制御するシステムの全体構成を示す。
図2図2は、本発明におけるデータの流れを示す。
図3図3は、シーケンス番号(SN:Sequencenumber)の動作をより詳細に示す。
図4図4は、ユーザーアプリケーション10、ホストOS20、ブロックデバイス30内部のファイルシステムエミュレータ、メモリの動作の流れを示す。
図5図5は、キャッシュの有無をチェックするためのファイル整合性チェック部分のフローを示す。
図6図6は、コンテンツテーブル および Mirror File Entry Table(MFET)の構造を示す。
【発明を実施するための形態】
【0024】
図1は、本発明であるファイル要求アクセスを制御するシステムの全体構成を示す。
【0025】
ユーザーアプリケーション(Userapplication)10、ホストOS(ホストシステム)20、ブロックデバイス(Block device)30、が接続される関係として示されている。
【0026】
ブロックデバイス30内部には無線受信機(mmWave transceiver)31が存在し、受信したコンテンツは直接メモリ(Memory(Flash, DRAM等))32へと格納される。
【0027】
ミリ波などの広帯域無線通信で受信されるデータは非常に高速であるため、たとえばホストOS側が、携帯端末やタブレット端末のような外部インターフェイスに低速の I/F しか持たない端末の場合、その低速の I/F に受信速度が制限されてしまい、無線側の広帯域を生かせない。
【0028】
無線受信機31によって受信したコンテンツは、直接、ブロックデバイス30内部のメモリ32へ格納される。 無線受信機31のハードウエアを制御するためのレジスタ(Register file for transceiver)33もブロックデバイス30内部に存在する。
【0029】
メモリ32やレジスタ33へのアクセスは、調停回路(Arbiter)34によって制御され、ホストOS20からのデータ操作と無線受信機からのデータ操作の両方を制御する。
【0030】
ホストOS20からのアクセスは、通常、ホストOS上で動作するユーザーアプリケーション10によって起動される。
【0031】
ユーザーアプリケーション10が、ブロックデバイス30内部のメモリ32や、ブロックデバイス30内部の無線受信機31の制御をレジスタ33経由で行いたい場合、本発明の構成においては、ホストOS20に標準的に備わっている標準ファイルIO(Standard file IO) 22を用いて操作する。
【0032】
具体的には、ホストOS20の管理する通常のファイルと同様の操作であり、ファイルを open し、ファイルに対するread/write が、OSの標準API経由でデバイスドライバ(Standard device driver) 24を通り、物理インターフェイス(Interface)26を経て、ブロックデバイス30へのアクセスとなる。
【0033】
インターフェイス26経由で要求のあったread/writeのアクセスは、ブロックデバイスのインターフェイス(Interface)35を通過してブロックデバイス内部へと伝わる。
【0034】
本発明の特徴的な構成では、この要求のあったアクセスはファイルシステムエミュレータ(File System Emulator)36によって解釈され、ブロックデバイス30内部のどのファイルに対するアクセスが発生したのかをアクセスされたファイルのセクタの値(番号)から検出し、それが後述のミラーファイルであるか否かを判定するとともに、ミラーファイルであればそのシーケンス番号(Sequence number)を変化(変更)させる。
【0035】
ホストOS20からのアクセスが read (ブロックデバイスからホストへデータを送る)場合であれば、シーケンス番号(Sequence number)を返答データの末尾に付加する。
【0036】
この シーケンス番号(Sequence number)の付加されたデータは、ホストOS20を経由して ユーザーアプリケーション10へと返信して提供され、ユーザーアプリケーション10は受け取ったシーケンス番号(Sequence number)を参照して、受けとったデータが実際にブロックデバイスから返信されたデータであるか否かを判定する。詳細は後述する。
【0037】
図2は、本発明におけるデータの流れを示す。
【0038】
ユーザーアプリケーション10が標準ファイルI/O22経由でファイルアクセスを行うと、アクセス対象のファイルの格納されているセクタが(ホスト)OS20によって調べられ、そのセクタに対するアクセス要求がブロックデバイス30へ送られる。
【0039】
通常のブロックデバイスであれば、セクタから直接ブロックデバイス30内部のメモリ32のアドレスを計算して、そのアドレスのメモリにアクセスする。
【0040】
本発明の構成においては、ブロックデバイス30内部でいったんセクタの値をファイルシステムエミュレータ(File System Emulator)36が解釈し、通常のブロックデバイス同様に直接メモリ32へアクセス可能なセクタなのか、それともミラーファイルなのかを区別する。
【0041】
ここで、「ミラーファイル」とは、OS20内のファイルシステム上ではそれぞれ異なったファイルとして参照されるが、ブロックデバイス30内部の実際のメモリが同一の場所であるファイルである。
【0042】
図2においては、OS20から参照するファイルシステム上の Mirror file #1 から Mirror file#n がすべてミラーファイルであり、OS20からは物理的に異なるファイルとして参照されるが、ブロックデバイス30内のメモリ内部のデータとしては同一のアドレス先のデータを参照する。
【0043】
本発明の構成では、ミラーファイルの参照する先として、ブロックデバイス内部のメモリでも、無線受信機制御のためのレジスタ群(Register file for transceiver)33であってもよい。
【0044】
さらに本発明では、このミラーファイルのデータの末尾には、シーケンス番号(SN:Sequence number)という、そのファイルにブロックデバイス30内部でアクセスが発生するたびに変更される(典型的には、増加する)値を付加する。
【0045】
図3は、シーケンス番号(SN:Sequencenumber)の動作をより詳細に示す。
【0046】
シーケンス番号(Sequence number)は、ブロックデバイス30に実際のファイルアクセスが発生するたびに値が変更(増加)する。これを用いることで、ユーザーアプリケーション10の側で、OS20によるファイルのキャッシュの有無の判定が可能となる。
【0047】
図3の例では、ユーザーアプリケーション10から2回のファイルアクセスを行った場合に関して、OS20のファイルキャッシュの有無で、シーケンス番号(Sequence number)の動作がどのように異なるかを例として示す。
【0048】
図3の左の図は、OS20によりファイルがキャッシュされる場合の動作を示したものである。ユーザーアプリケーションからファイルへの最初のアクセスが発生すると、OSにそのリクエストが到達し、OSはその時点でのキャッシュの有無をチェックする。
【0049】
図3の左の図のように、最初のアクセスではOS20にはキャッシュがないため、ブロックデバイス30への実アクセスが発生する。ブロックデバイス30はファイルアクセスを検出し、Sequence Number(SN)の値を増加させ、ブロックデバイス30内部のメモリに格納されている最新の対象ファイルのデータにアクセスしOS20へデータを返答する。その際にSN をデータに(末尾などに)付加する。OS20は、受け取ったデータをユーザーアプリケーションへ返答して最初のファイルアクセスは完了する。
【0050】
引き続き2回目のファイルアクセスを同一ファイルに行った場合、今度は OS20がキャッシュを持っているためOS20はそのキャッシュの内容をユーザーアプリケーション10へと返答する。そのためブロックデバイス30への実アクセスは発生せず、2回目のファイルアクセスは終了となる。
【0051】
ここで、ユーザーアプリケーション10側は、最初と2回目のアクセスで得られたデータ(の末尾)に付加されているSN の値を比較する。SNの値が同一であることから、ユーザーアプリケーションはこの2回目のデータはキャッシュであり、2回目のデータはブロックデバイス30への実アクセスをしていない古いデータ(キャッシュ)であることが判定可能となる。
【0052】
図3の右の図は、OS20によるキャッシュがない場合について示したものである。最初のファイルアクセスではOS20はキャッシュがないためブロックデバイス30へと実アクセスが発生し、ブロックデバイス30内部ではSN の値を増加させその値をファイルのデータ(の末尾など)に付加して返答する。2回目のファイルアクセスが発生しても、OS20はキャッシュをしないためブロックデバイス30への実アクセスが再度発生し、ブロックデバイス30内部ではSNが同様に増加し、その値をファイルのデータ(の末尾など)に付加して返答する。
【0053】
ユーザーアプリケーション10では、1回目、2回目のアクセスで得られたデータの末尾を比較すると値が異なるため、OS20によるキャッシュが無く、2回目も1回目同様にブロックデバイス30への実アクセスをした最新のデータであることが判定可能となる。
【0054】
図4は、ユーザーアプリケーション10、ホストOS20、ブロックデバイス30内部のファイルシステムエミュレータ、メモリの動作の流れを示す。
【0055】
図5は、キャッシュの有無をチェックするためのファイル整合性チェック部分のフローを示す。
【0056】
図6は、コンテンツテーブル および Mirror File Entry Table(MFET)の構造を示す。
【0057】
ユーザーアプリケーション10が、OS20の標準ファイルI/O 22経由で、ファイルをアクセスした際に、ブロックデバイス30側のファイルシステムエミュレータ36が、ミラーファイルについての判定のために参照するものが、 Mirror File Entry Table(MFET)37である(図1参照)。
【0058】
ブロックデバイス30内部の無線受信機31によってダウンロードされたコンテンツは、図6(a)のコンテンツテーブルを用いて、各コンテンツがどのアドレス範囲内部に格納されているかを記憶する。
【0059】
図6(b)はミラーファイルの情報を管理するMirror File Entry Table(MFET)であり、ミラーファイルとコンテンツの格納されたメモリのアドレスの関連付けと Sequence Number(SN)の管理を行う。
【0060】
コンテンツがダウンロードされると、ミラーファイルが複数個(この図の例では64個)がファイルシステム上に作成され、各ミラーファイルのOS20から参照される際のセクタがミラーファイルごとに決定する。
【0061】
そのセクタ番号が MFET の第1列のセクタ部分に記録される。
【0062】
第2列はファイルシステム上、対応するミラーファイルのファイル名を参考までに示しているが、このファイル名の情報はMFET自身が記憶する必要はかならずしも無い。(ファイル名とセクタの対応付けは、OS20が参照するファイルシステム本体部分に通常通り記されているためである)。
【0063】
第3列には、各ミラーファイルに対応する実体のコンテンツがメモリ上のどのアドレスに記録されているかを格納する。
【0064】
第4列は参考として対応する実体のコンテンツのファイル名を示しているがMFET自身が記憶する必要は必ずしも無い。(この対応付けは図6(a)のコンテンツテーブルを参照することで判定可能なためである)。
【0065】
そして、第5列に SequenceNumber(SN)を記録する。
【0066】
OS20経由でアクセスのあったファイルがミラーファイルかどうかの判定は、アクセスのあったファイルのセクタ番号がMFETの第1列のセクタに合致するか否かをチェックし、該当セクタがあった場合はミラーファイルであると判定できる。
【0067】
ミラーファイルであると判定された後は、ファイルのアクセスを、MFETの第3列で示されるブロックデバイス30内部のメモリのアドレスに対して行うことで、複数のミラーファイルからのアクセスを、実体がひとつだけのブロックデバイス30内部のメモリに格納された最新のコンテンツに対して行うことが可能となる。
【符号の説明】
【0068】
10 ユーザーアプリケーション(Userapplication)
20 ホストOS
30 ブロックデバイス(Block device)
36 ファイルシステムエミュレータ(FileSystem Emulator)
37 ミラーファイルエントリーテーブル(MirrorFile Entry Table)(MFET)
図1
図2
図3
図4
図5
図6