JP7197733B2 - リアル・タイムでファイル・システムの互換性を動的に生み出すこと - Google Patents

Description

本発明は、ファイル・システムの互換性の動的な確立と、データに対するファイル・システムに依存しないアクセスとを、リアル・タイムで行うための方法に関する。本発明によれば、エンド・ユーザは、受動データ・メモリの基盤となるファイル・システムを考慮に入れる必要なしに、任意の端末デバイスを用いて、受動メモリに対してアクセスすることが可能である。これは、例えば、直接記憶媒体上にファイル・システムの変換を提供する、複雑な処理工程を回避する。したがって、提案される方法は、より効率的であり、かつ、より誤り耐性が高い。本発明は、対応して構成される装置およびシステム構成にも向けられる。また、方法工程を実装する制御コマンドを備えたコンピュータ・プログラム製品が提案される。

特許文献１は、所定のファイル・システムを備えた能動データ・メモリに対して読み取りおよび書き込みをするためのデバイスを示している。
特許文献２は、構造化された情報が記録された記憶媒体を生み出すための方法を提案しており、この目的のために、データを変換することを提案しており、ユニバーサル・データ・モデルを使用する。

特許文献３は、記憶媒体に対して書き込むための方法を示している。
特許文献４は、ファイル・システムを変換するための方法を示している。
先行技術は、端末がデータ・メモリに対してアクセスすることを欲する場合に互換性問題が生じ得るという問題を取り扱う。例えば、エンド・デバイスは、メモリ上でファイル・システムをサポートしない。先行技術は、互換性がない場合、すなわち、異なるファイル・システムでは、データ・メモリのファイル・システムが典型的には変換されることを提言する。したがって、データ・メモリのファイル・システムは、端末によってサポートされるファイル・システムへ変換される。これは複雑な処理であり、記憶媒体上でデータも失われる。

あるファイル・システムから別のファイル・システムへの転送または変換は、データ・メモリ全体をフォーマット化することによって実行されることが多い。フォーマット化は、再構造化期間中にデータ・ストア全体が消去され、その結果、書き込み動作を始めるときには空であるという事実に基づく。これは、さらなる問題、例えば、データをバック・アップする必要、またはデータ損失の可能性の問題につながる。

さらに、ターゲット・システムの機能性が模倣されるエミュレーションが、先行技術において知られている。エミュレーションも複雑な処理であり、ターゲット・システムの基盤となるハードウェアおよびソフトウェアの抽象化レベルを提供する際に相当な努力を必要とする。エミュレーションすること自体が、時間を要することが多い。また、通信参加者が受動データ・メモリである場合には、不必要な機能性が提供される。これは、典型的には、広範囲な機能性を提示しないが、データ・メモリの主要なタスクは、単純に受動的に行為することであり、静的データを記憶することのみである。したがって、エミュレーションも時間を要し、該当する場合には、誤りを起こしやすい。

したがって、先行技術は、基盤となるファイル・システムが常に互換性があるような手法で、エンド・ユーザが、受動データ・キャリアを端末に対して接続することを可能にする方法が提供されていないという不利益を有する。対応する方法は複雑であり、ファイル・システム全体の複雑な変換は、典型的には、準備処理工程において実行される。しかしながら、ユーザは典型的にはリアル・タイムでデータ・キャリアに書き込みをすることを欲し、したがってフォーマット化を受け入れることを欲しないので、これはユーザにとって不利益だと感じられる。ひいては、ユーザがデータを損失する脅威にさらされれば、そのような手続きは受け入れられない。

米国特許第５，４６３，７７２号明細書 国際公開第２００５／０８６０３９号 国際公開第２０１８／０３１７９４号 米国特許第５，７４２，８１８号明細書

したがって、ファイル・システムの互換性に関する問題を引き起こさずに、ユーザが受動データ記憶デバイスを端末に対して接続することを可能にする方法を提供することが、提案される発明の目的である。したがって、データの損失を必然的に伴わず、リアル・タイムで実行されることも可能である、ファイル・システムに依存しないデータ・アクセスが可能となる。対応して構成されるデバイスおよび対応して構成されるシステム構成を提案することも、本発明の目的である。また、方法を実装し、またはデバイスもしくはシステム構成を動作させる制御コマンドを備えたコンピュータ・プログラムが提案されることになっている。

目的は、請求項１に記載の特徴を有する方法によって達成される。さらなる有利な構成は、従属項において特定される。
したがって、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うための方法であって、能動端末およびモデル化デバイスに対して、受動データ・メモリ・デバイスのファイル・システムに対するアクセスを許可する工程であって、モデル化デバイスは、受動データ・メモリ・デバイスと能動端末との間に通信可能に接続される、許可する工程と、モデル化デバイスによって、能動端末からのアクセス要求を受信する工程であって、アクセス要求は、アクセス・データと、受動データ・メモリに対するアクセス動作と、を指定する、受信する工程と、モデル化デバイスによる、受動データ・メモリのファイル・システムの認識工程と、受動データ・メモリの認識されたファイル・システムに従って、アクセス要求を実行するのに適した、記憶されたアクセス規則を選択する工程と、モデル化デバイスによって、アクセス要求によって指定されるアクセス・データに対して、選択されたアクセス規則を適用する工程と、アクセス要求に従って、アクセス動作を実行する工程と、を備える、方法が提案される。

本発明によれば、データ・キャリアのハードウェアはエミュレーションされず、むしろ端末からのデータが受動データ・メモリに対して書き込まれることが可能であるような手法で、データ・レベルまたはファイル・レベル上で適応が行われるような手法で、ファイル・システムの互換性の動的な確立が行われる。ハードウェアはシミュレーションされず、むしろ作業はファイル・レベル上で達成され、このためのエミュレーションは必要ではない。また、受動データ・メモリは、ソフトウェアを有しておらず、その結果、ここでは機能性がマッピングされる必要もない。データ・メモリは、典型的には、受動的な読み取り動作または書き込み動作を提示するのみである。これは、提案される方法がリアル・タイムで作動することを可能にする。

本発明によれば、リアル・タイムとは、著しいレイテンシがないこと、すなわち、ユーザが自身の観点から見て遅延に気づかないことを意味する。個々の処理工程は、１秒の何分の１かで処理されることが可能であり、その結果、エンド・ユーザは、処理がリアル・タイムで実行されていると感じる。しかしながら、技術的な観点から見ると、人間のユーザによって主観的に知覚されることができない処理時間が勿論ある。

本発明によれば、方法は、準備方法工程においてファイル・システムをエミュレーションまたは転送する必要を回避する。したがって、エンド・ユーザは、モデル化デバイスにより、記憶媒体または受動データ・メモリを端末に対して結合し、データ・メモリに対して読み取り動作および書き込み動作を直ちに始めることができる。これは、データ・メモリ内のデータが、ファイル・システムに依存せずにアクセスされることが可能であることを意味する。データに対するアクセスとは、データ・キャリアに対する読み取り動作と書き込み動作との両方がサポートされることを意味する。

これを行うためには、ファイル・システムに対するアクセスを許可する必要がある。アクセスを許可することは、ＭＯＵＮＴ動作とも称される。ここで、受動データ・メモリのファイル・システムを読み出し、そのデータ・メモリ上にどのデータがあるのかを既に認識することが可能である。これは時間の著しい消費を必要とせず、その結果、ユーザの観点から見て、この処理工程も、リアル・タイムで、すなわち、待機時間なしで、実行されることが可能である。ファイル・システムに対するアクセスを許可することによって、データ・メモリは、モデル化デバイスが介在させられて、能動端末に通信可能に結合される。アクセスを許可することは、例えば、データ・メモリ、モデル化デバイスおよび能動端末の間にプラグ接続を確立することを含む。

プラグ接続は、受動データ・メモリがモデル化デバイス内へ直接差し込まれ、次いで、モデル化デバイスが能動端末内へ差し込まれるような手法で、行われ得る。しかしながら、データ・メモリ、モデル化デバイスおよび端末の間に有線接続を提供することも可能である。本発明の一態様によれば、アクセスは、データ記憶デバイス、モデル化デバイスおよび端末の間の物理的接続により許可される。当業者は、このための共通のフォーマット、および、そのようなプラグ接続がどのように設計されるかを知っている。ＵＳＢが一例として使用されることが可能であり、その結果、共通インターフェースが、この目的のために使用され得る。したがって、受動データ記憶デバイスは、外部ハードドライブまたはＵＳＢスティックまたはＳＤカード・スロットとすることができる。

モデル化デバイスは、独自のハードウェア・デバイスとして設計されることが可能であり、例えば、アクセス規則を含有するデータ・メモリを有することができる。モデル化デバイスは、制御ロジックを提供または実行する組み込みシステムとして実装されることも可能である。一般に、モデル化デバイスは、２つ以上のインターフェースと、インターフェースを介してモデル化デバイスと通信する受動データ・メモリと、さらなるインターフェースと通信する能動端末とを備える。しかしながら、一般に、いくつかのデータ・メモリが接続され得るように、さらなるインターフェースを提供することも可能である。いくつかの能動エンド・デバイスが、データ・メモリに対して書き込み、またはデータ・メモリから読み取るように、いくつかの能動エンド・デバイスを接続することも可能である。

受動データ・メモリは、機能性を提供せず、データを記憶するための役割を果たすにすぎず、結果として、受動と称され得る。対応する書き込み動作および読み取り動作は、能動端末によって開始および送信される。したがって、能動端末は、本発明による方法を開始し、受動データ・メモリに対してアクセスしたいであろう。能動端末は、基盤となるファイル・システムに従って記憶されているデータを準備しておき、または受動データ・メモリ上に記憶されているデータを要求する。本発明によれば、対応するデータは、能動デバイスのサポートされているファイル・システムに応じて適合される。

一般に、能動端末は、第１のファイル・システムをサポートし、受動データ記憶デバイスは、第２のファイル・システムを有する。ここで、データが受動データ・メモリに対して書き込まれる場合、第１のファイル・システム・フォーマットにおけるデータは、それらが第２のファイル・システム・フォーマットにおいて記憶されることになるような手法で適合される。データがデータ・メモリから要求される場合、対応するデータは、それらが第１のファイル・システム・フォーマットに対応するような手法で、第２のファイル・システム・フォーマットから適合される。典型的には、この目的のためにユーザ・データを適合させることは必要ではなく、追加のデータのみが適合されなければならない。例えば、メタデータは、それらがデータ・メモリに対して書き込まれ、または能動端末上に記憶され得るような手法で、モデル化され得る。追加のデータは、ユーザ・データを記述し、またはファイル・システムに関連する情報を提供するデータであり得る。対応するデータ・ブロックが記憶媒体上に物理的に記憶される場所を指定するオフセットを追加のデータが記述していることが起こり得る。

したがって、モデル化デバイスは、能動端末からのアクセス要求を受け入れ、アクセス要求は、アクセス・データと、受動データ・メモリに対するアクセス動作とを指定する。アクセス動作は、読み取り動作または書き込み動作のどちらかであってよく、一方で、アクセス・データは、まさに問い合わせされる、または送信されるものを記述する。アクセス・データは、例えば、「書き込み」アクセス動作に従ってデータ・メモリに対して書き込まれるファイル名を指定することができる。アクセス要求は、能動端末によって開始され、ファイル・システム内に入らずに、所望のデータを指定する。

次いで、受動のデータ・キャリアのファイル・システムが、モデル化デバイスによって認識される。モデル化デバイスは、能動端末と受動データ・メモリとの間を仲介する。したがって、あらゆるメッセージまたはコマンドが、モデル化デバイスを通過させられる。したがって、接続された通信参加者、換言すれば、能動端末および受動データ・メモリは、モデル化デバイスを介してのみ通信する。

さらに、受動データ・メモリの認識されたファイル・システムに従ってアクセス要求を実行するのに適した、記憶されたアクセス規則の選択がある。記憶されたアクセス規則は、例えば、経験的に決定されてもよく、または準備処理工程において作成されてもよい。アクセス規則は、第１のファイル・システムから開始して、データが第２のファイル・システム内で解釈され得るように、どのようにデータがモデル化されるかを記述している。追加のデータ、例えばメタデータは、典型的には、第１のオペレーティング・システムに従って符号化されているファイルまたはデータが、第２のオペレーティング・システムに従って符号化されるような手法で、ここでは適合される。例えば、書き込み動作が行われる場合、能動端末は、第１のファイル・システムまたは能動端末上で利用可能なファイル・システム・フォーマットに従って、ファイルを送信する。次いで、ファイルは、それらが第２のファイル・システムまたはファイル・システム・フォーマット上に記憶され得る手法で、アクセス規則に従ってモデル化される。他方で、読み取り動作が行われる場合、第２のファイル・システムのデータは、それらが能動端末によっても解釈され得るような手法で、モデル化される。したがって、データは、それらが能動端末のファイル・システム上に保存され得るような手法で変換される。

第１の列内に能動端末のファイル・システムを記述し、第２の列内に受動データ・メモリのファイル・システムを記述し、第３の列において、どのアクセス規則が提供されるかを指定する表が維持されるような手法で、アクセス規則が選択され得る。第３の列は、対応するアクセス規則を指すポインタを保持することができる。ＦＡＴ、ＦＡＴ３２、ＥｘＦＡＴ、ＮＴＦＳまたは他のものが、ファイル・システムとして使用され得る。

アクセス規則を備えたデータ・メモリは、典型的には、モデル化デバイス内に組み立てられ、または、データ・メモリが、読み出される外部データ・メモリとして存在することも可能である。このようにして、データ・メモリも能動端末によって保持されることが可能である。

したがって、アクセス規則は、データが各ケースにおいて互換性があるように、書き込まれるまたは読み取られるデータをどのように適合するかに関する規則を記述する。つまり、ペイロード・データは他のデータから分離され、他のデータはファイル・システムに従って適合されるような手法で、アクセス・データが分析されることが提供され得る。追加のデータまたはメタデータのみが典型的なケースにおいて適合される状態で、ユーザ・データも適合されることが任意選択で提供される。したがって、修正処理を非常に効率的に実行することが可能であり、ひいては、方法をリアル・タイムで実行することが可能である。したがって、適合されるものはファイル・システムではなく、データであり、データについては、典型的にはメタデータのみであるので、追加のデータの変換は、迅速に実行されることが可能である。これは、大きな技術的な努力なしに適合され得る、ごく少量のデータにすぎない。

アクセス規則が選択された場合、それらはアクセス・データに対して適用され、これは、書き込まれるまたは読み取られるデータが、それらが受動データ・メモリのファイル・システムに対して書き込まれることが可能であるような手法で適合され、または、データが読み取られる場合、それらが能動端末デバイスのファイル・システムに対応するように適合されることを意味する。既述されたように、ペイロード・データではなく、追加のデータを単純に符号化またはモデル化することで十分であることが多い。

ここでは、データが互換性のある手法で変換されているので、アクセス動作を実行する実際の工程を開始することが可能である。アクセス動作は、読み取り動作または書き込み動作のどちらかであってよい。ここでは、データが適切に利用可能であるので、それらは、受動データ・メモリに対して書き込まれ、または受動データ・メモリから読み取られる。

方法工程は、選択されたアクセス規則が適用され、定義されたデータ・ストリームに対してアクセス動作が実行されるような手法で、反復して実行され得る。例えば、ファイルのセットが、能動端末によって要求されることがあり、アクセス・データの一度だけの調整が十分であるかどうか、または、例えば、アクセス規則がファイルの各書き込み動作後に再適用されなければならないかどうかは、アクセス動作に従って決定され得る。これは、メタデータがファイルごとに適合され得ること、または、メタデータが一度だけ適合され、全てのユーザ・データが上書きされることを意味する。ここでどのように進行するかは、モデル化デバイスのデータ・メモリ内に記憶され得る。

本発明の一態様によれば、アクセスを許可することは、マウント処理、受動データ・キャリアをモデル化デバイス内に組み込む工程、受動データ・キャリアを能動端末内に組み込む工程、通信可能な結合工程、１つ以上のプラグ接続を確立する工程、アクセスを起動する工程、アクセス権および／またはデータ通信をセット・アップする工程を備える。これは、アクセスが許可された場合にデータ・メモリが読み出され得るという利点を有し、したがって、読み取り動作期間中に利用可能なデータを推定することが可能である。したがって、例えば、ファイル・サイズは知られており、読み取られるデータ・ストリームがどのように構築されているかが決定され得る。この情報に依存して、選択されたアクセス規則の適用およびアクセス動作の実装が、最適化され得る。例えば、多くのより小さなファイルがある場合、ファイルの個々のグループは、データ・ストリームとして読み取られることが可能であり、したがって、選択されたアクセス規則の適用は、いくつかのファイルに関連する。ファイルが大きい場合、アクセス規則は、各ファイルに対して適用され得る。通信可能な結合は、能動端末がモデル化デバイスを介して受動データ・メモリと通信することを確実にする。追加のセキュリティ機構を実装することも可能であり、例えば、アクセス権が割り当てられ得る。

本発明のさらなる態様によれば、能動端末は、アクセス要求を生成するオペレーティング・システムを有する。これは、データ・ストリームが予め指定されることが可能であり、したがって、どのファイルが要求されているかが知られるという利点を有する。このようにして、オペレーティング・システムは、多数のファイルが読み取られ、または書き込まれ、したがって、選択されたアクセス規則も、１つまたは複数のファイルに対して適用可能であることを示すことができる。結果として、アクセス・データは、セグメント化され、一体的に適合されることが可能であり、または、個々のセグメント、すなわち、個々のデータ・ストリームが、適合されることが可能である。このようにして、少量のデータが要約されることが可能であり、アクセス規則が一度適用される。これは、これらのファイルが書き込まれることが可能であり、追加のデータは毎回調整される必要がないことを意味する。

本発明のさらなる態様によれば、適用および実装は、データ・ストリームごとに反復して実行され、オペレーティング・システムは、データ・ストリームを定義する。これは、アクセス規則の適用および書き込み動作の実行が、望まれる回数だけ実行されることが可能であり、その結果、最後の反復の後に、全てのアクセス・データが読み取られ、または書き込まれるという利点を有する。したがって、データ・ストリームは、要求されたファイルまたは指定されたファイルに依存して、選択され得る。

本発明のさらなる態様によれば、アクセス要求は、１つ以上の読み取り要求および／または書き込み要求を有する。これは、受動データ・メモリが、読み取りと書き込みとの両方のためにアクセスされ得るという利点を有する。ここでは、受動データ・メモリの機能性をエミュレーションすることは必要ではなく、むしろ、書き込まれるまたは読み取られる（メタ）データの適合が、本発明に従って行われ、受動データ・メモリに対するファイル・システムの直接的な適合はない。

本発明のさらなる態様によれば、アクセス要求は、ペイロード・データおよび／または追加のデータを指定する。これは、どのデータがユーザ・データであり、どれが追加のデータであるかを、アクセス要求が既に指定するという利点を有する。追加のデータは、例えば、有用なデータを記述するメタデータとして、存在し得る。そのような追加のデータは、ファイルのサイズまたはファイル名である。ファイル・システムが、一定の追加のデータをサポートしない場合、例えば、異なる文字セットが使用される場合、ファイル名がファイル・システムの文字セットと一致するようにファイル名が変更されるような手法で、アクセス規則の適用が行われる。例えば、能動端末は、受動データ・メモリに対してファイルを書き込み、ウムラウトを有するファイル名を用いてユーザ・データを指定することを欲する。ウムラウトが、データ・メモリのファイル・システム上でサポートされていない場合、アクセス規則は、例えば、ウムラウトが別の母音に、または母音および「ｅ」に置換されることを提供する。

本発明のさらなる態様によれば、アクセス・データは、ファイル名、絶対メモリアドレス、相対メモリアドレス、ファイル・タイプおよび／またはファイル・プロパティを記述する。これは、どの情報が適合されることを潜在的に必要とするかをアクセス・データが記述するという利点を有する。受動データ・メモリのメモリ・システムが、一定のメモリアドレスのみをサポートし、または一定のサイズのみを有する場合、アクセス・データがデータ・メモリに対して書き込まれ得るように、送信されるメモリアドレスが適合される。ファイルが読み取られる場合、これらのアクセス・データは、それらが能動端末のファイル・システム上に保存され得るような手法で適合され得る。

本発明のさらなる態様によれば、アクセス動作は、読み取り動作および／または書き込み動作を記述する。これは、個々の動作がどのように実行されるかをアクセス動作が記述するという利点を有する。どのように読み取りまたは書き込むかは、ファイル・システムごとに記述され得る。

本発明のさらなる態様によれば、アクセス規則は、アクセス・データがファイル・システムに従って読み取られるように、および／または書き込まれるように、アクセス・データの追加のデータがどのようにモデル化されるかを指定する修正動作を記述する。これは、一定のアクセス・データが第１のファイル・システムに関してエンコードされている場合、一定のアクセス・データが第２のファイル・システムと互換性があるような手法で一定のアクセス・データが記録されるような手法で、一定のアクセス・データを変換する変換規則または修正規則をアクセス規則が示すという利点を有する。

本発明のさらなる態様によれば、アクセス規則は、第１のファイル・システムに従ったデータが、第２のファイル・システムへどのように書き込まれるか、および／または第２のファイル・システムからどのように読み取られるかを記述する。これは、能動端末上に存在し得るファイル・システム、および受動データ・メモリ上に存在するファイル・システムから、変換が行われ得るという利点を有する。したがって、アクセス規則は、符号化データを記述し、または追加のデータがどのように適合されるかの処理を記述する。典型的には、追加のデータのみが適合される必要があり、必ずしもペイロード・データが適合される必要はない。

本発明のさらなる態様によれば、受動データ記憶媒体は、記憶媒体、ＵＳＢスティック、ハードドライブ、メモリーカード、サーバ、ネットワーク構成要素、ＤＡＳ、ＮＡＳおよび／またはローカル・データ記憶デバイスを備える。これは、従来の仕様が再び使用されることが可能であり、多数の記憶媒体も使用されることが可能であるという利点を有する。ここでは、いくつかの受動のデータ・メモリがアドレス指定されることも可能である。ＮＡＳは、ネットワーク接続型ストレージ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）を表す。ＤＡＳは、直接接続型ストレージ（Ｄｉｒｅｃｔ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）を表す。

本発明のさらなる態様によれば、能動端末は、テレビジョン・デバイス、プリンタ、ルータ、ＤＡＳ、ＮＡＳ、ポータブル端末、据置型端末、コンピュータ、電話またはネットワーク構成要素である。これは、能動端末が多種多様な手法で実装されることが可能であり、完全に異なるファイル・システムを互換性があるようにする一般的な方法が作成されるという利点を有する。

本発明の別の態様は、アクセス要求を区別し、ユーザ・コンテンツに対してアクセスを要求するか、またはメタデータに対してアクセスを要求するかを決める、本発明の能力である。アクセス要求のタイプに依存して、次いで、要求は、データ変形なしに受動メモリへ転送され、またはメタデータは、翻訳規則を使用して適当なフォーマットにされる。

本発明の別の態様は、端末へフィードバックを送るために、受動メモリからメタデータの一部のみを取り出す、本発明の能力である。このようにして、要求されたファイル上の最も必要な情報のみが、リアル・タイムで、かつ、短い応答時間で提供される。

本発明の別の態様は、受動メモリの特定の部分（通常は、特定のサブディレクトリとそのコンテンツ）のみを別個のメモリとして利用可能にし、その結果、別個のメモリは、端末によって提供され得るという本発明の能力である。

本発明の別の態様は、予選択を行い、したがって、どのファイル・システムが端末にとって利用可能にされるかに関する決定を行う、本発明の能力である。これは、スイッチを介して、または外部媒体上で予め設定されたファイル、例えばｍａｋｅａｓ．ｅｘＦＡＴなどを使用することによって行われ、ｍａｋｅａｓ．ｅｘＦＡＴは、モデル化ユニットに、ｅｘＦＡＴファイル・システムを用いて外部メモリを作成するように指示する。このようにして、モデル化ユニットは、ｅｘＦＡＴファイル・システムをエンド・デバイスにとって利用可能にすることができ、理由は、このファイル・システムが、その仕様が公に利用可能になって以来、広く使用されてきており（ｅｘＦＡＴのオープン・ソース実装は、マイクロソフト・コーポレーション（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）の開発者らによってサポートされている）、組み込みデバイス、携帯電話、および他のマルチメディア・デバイスの全般において使用されているからである。

本発明の別の態様は、ＦＡＴ３２の重大な不利益を、このファイル・システムが端末上で使用される場合に補償する、本発明の能力である。大きな不利益は、ファイル・サイズの限定であり、これはＦＡＴ３２では４ＧＢである。ＦＡＴ３２は、同じサブディレクトリ内でアドレス指定可能なファイルの数についてさらなる限定を特定しており、これは６５５３４個である。ＦＡＴ３２により提供された外部媒体は、より古いモデルのエンド・デバイスによってサポートされている可能性が最も高く、それらの限定も、ユーザに対して考慮されることができ／ユーザは、それを用いて作業することを継続することができる。本発明が、最大許容サイズが４ＧＢのいくつかのファイルを端末にとって利用可能にするような手法で、本発明は、大きなファイルによって表される問題を取り扱う。

ＦＡＴ３２の第２の限定、すなわち、同じサブディレクトリ内のアドレス指定可能なファイルの最大数６５５３４は、全てのファイルが同じディレクトリまたはサブディレクトリ内にある場合、使用法に影響を与える。情報が、６５５３４個を超えるファイルを用いてサブディレクトリから取り出されることになる可能性は極めて低いが、そのような場合において、本発明は、ユーザに対して、限界に到達し、これらの６５５３４個のファイルが同時にアクセスされることは不可能であることを通知することになる。このようにして、ユーザは、全てのファイルがデバイス上に表示され得るとは限らないが、依然として利用可能であることを知る。

本発明の一態様によれば、端末はＦＡＴ３２を排他的にサポートすると仮定される。エンド・デバイスにおけるＦＡＴ３２についてのサポートは、そのモジュールまたは構成要素（例えば、インストールされているファイル・システム・ドライバ）が、ファイルおよびディレクトリを作成し、回復し、更新し、または削除するために、ＦＡＴ３２フォーマットを用いてローカル・メモリ、外部メモリまたは仮想メモリにアドレス指定することができる場合に、適用される。

メモリは、本発明の一態様に従って、ブロック・デバイスとして定義され、これは、基本的な動作がブロック、すなわち、読み取りブロックおよび書き込みブロックによって提供されることを意味し、ブロックは、オフセットによって、またはメモリ内の位置を介してアドレス指定される。エンド・デバイスは、外部記憶媒体への接続のためにＵＳＢインターフェースを有すると仮定される。

端末におけるＦＡＴ３２サポートの仮定は、一般に、デモンストレーション目的に役立つにすぎず、提案される発明の考え得る使用をＦＡＴ３２システムに限定することを目的としない。端末が外部記憶媒体への接続のためにＵＳＢインターフェースを有するという仮定も、例示の目的に役立ち、提案される発明の考え得る使用をＵＳＢインターフェース接続に限定することを目的としない。適当な標準、例えばＦＡＴまたはＦＡＴ３２などが、ここで言及される場合、これは一般にファイル・システムを表す。

目的は、モデル化デバイスによっても達成され、モデル化デバイスは、受動データ・メモリと能動端末との間に通信可能に相互接続されることが可能であり、能動端末に対して受動データ・メモリのファイル・システムに対するアクセスを許可するようにセット・アップされ、モデル化デバイスは、能動端末から、アクセス・データと、受動データ記憶デバイスに対するアクセス動作とを指定するアクセス要求を受信するようにも構成され、受動データ・メモリのファイル・システムを認識するようにさらにセット・アップされ、データベース・ユニットは、受動データ・メモリの認識されたファイル・システムに従ってアクセス要求を達成するのに適した、記憶されたアクセス規則を選択するように構成されており、モデル化デバイスは、アクセス要求によって指定されるアクセス・データに対して、選択されたアクセス規則を適用するようにさらにセット・アップされ、アクセス動作をアクセス要求に従って実行させるようにさらに構成される。

モデル化デバイスは、提案される方法における使用に適している。さらに、モデル化デバイスは、提案されるシステム構成において使用され得る。
目的は、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うためのシステム構成であって、能動端末に対して受動データ・メモリのファイル・システムに対するアクセスを許可するようにセット・アップされた１つ以上のインターフェース・ユニットと、受動データ・メモリをサポートするモデル化デバイスとを有し、能動端末は、中間に通信可能に接続され、モデル化デバイスは、能動端末からアクセス要求を受信するようにセット・アップされ、アクセス要求は、アクセス・データと、受動データ・メモリに対するアクセス動作とを指定し、モデル化デバイスは、受動データ・メモリのファイル・システムを認識するようにセット・アップされ、データベース・ユニットは、受動データ・メモリの認識されたファイル・システムに従ってアクセス要求を実行するのに適した、記憶されたアクセス規則を選択するようにセット・アップされ、モデル化デバイスは、アクセス要求によって指定されるアクセス・データに対して、選択されたアクセス規則を適用するようにセット・アップされ、受動データ・メモリは、アクセス要求に従ってアクセス動作を実行するように構成される、システム構成によっても達成される。

目的は、制御コマンドを備えたコンピュータ・プログラム製品であって、制御コマンドは、方法を実行し、制御コマンドがコンピュータ上で実行される場合、提案される構成を動作させる、コンピュータ・プログラム製品によっても達成される。

本発明によれば、方法が、提案されるデバイスおよびユニットまたはシステム構成を動作させるために使用され得ることは、特に有利である。提案されるデバイスおよびデバイスは、本発明による方法を実行するのにも適している。したがって、各ケースにおけるデバイスまたはシステム構成は、対応する方法を実行するのに適した構造的な特徴を実装する。ただし、構造的な特徴は、方法工程として設計されることも可能である。提案される方法は、構造的な特徴の機能を実装するための工程も提供する。

本発明のさらなる利点、特徴および詳細は、以下の説明から現われ、以下の説明において、本発明の態様は、図面を参照しつつ詳細に説明される。特許請求の範囲および説明において言及される特徴は、個々にまたは任意の組み合わせで、本発明にとって必須であり得る。上述された特徴およびここで詳述される特徴も、個々にまたは任意の組み合わせでまとめて使用され得る。例示的な実施形態の説明において使用される「左側」、「右側」、「上部」および「底部」という用語は、図中の文字が普通に読めたり参照符号が普通に読めたりする向きにある図面に関連する。図示および説明される実施形態は、決定的なものとして理解されるべきではなく、本発明を解説するための例示である。詳細な説明は、当業者の情報のために提供されており、したがって、説明において、知られている回路、構造および方法は、本説明を理解することをより困難にしないように、詳細には図示または解説されない。図において、以下が示される。

既知のシステム構成の概略ブロック図。 本発明の一態様による、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うためのシステム構成の概略ブロック図。 本発明のさらなる態様による、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないリアル・タイムでデータに対するアクセスと、をリアル・タイムで行うためのシステム構成の概略ブロック図。 本発明のさらなる態様による、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うための方法の概略フロー図。 モデル化デバイスによって実行され得る方法工程の概略フロー図。 アクセス要求に対してサービス提供するための、本発明による方法工程の概略フロー図。 受動メモリからファイル・システム・パラメータを読み取るためのモデル化デバイスの本発明による方法工程の概略フロー図。 本発明の一態様による、記憶されたアクセス規則を適用するための方法工程を例示する表。 本発明の一態様による、記憶されたアクセス規則を適用するための方法工程を例示する表。 本発明のさらなる態様による、記憶されたアクセス規則を適用するための方法工程を例示するさらなる表。 本発明のさらなる態様による、記憶されたアクセス規則を適用するための方法工程を例示するさらなる表。 本発明の一態様による、記憶されたアクセス規則を使用するための方法工程を例示する表。

図１は、先行技術によるシステム構成を示す。記憶媒体は左側に位置し、端末デバイスは右側に位置し、プラグ接続のみが右側に示されている。モデル化デバイスは、右手側と左手側との両方でハードウェアがエミュレーションされるような手法で、設計されている。これは先行技術において当てはまり、理由は、中央のデバイスは、周辺デバイスに対して制御コマンドを転送するのに適しているからである。したがって、先行技術は、典型的には、受動記憶媒体を提供せず、むしろ入力デバイスなどの周辺デバイスが、ここに接続され得る。したがって、先行技術は機能性のエミュレーションも必要とし、これは本発明によれば必要ではない。

本図１から分かるように、左手側のエミュレータ１および右手側のエミュレータ２によってエミュレーションが必要であることは、先行技術において特に不利益である。したがって、先行技術は、接続された端末全てがエミュレーションされなければならないことを提供し、これは相当な技術的な努力を表し、おそらくは誤りを起こしやすくさえある。

本発明によれば、この不利益は、先行技術において克服され、驚くことに、調整はファイル・レベルまたはデータ・レベルにおいてのみ必要であることが認識された。また、先行技術は、互換性の確立がリアル・タイムで行われることを可能にしない。例えば、左側に記憶媒体が実際にある場合、先行技術は、ファイル・システムがここで適合されることを提供する。本発明によれば、適合されるものは、ファイル・システムではなく、読み取られるまたは書き込まれるデータのみである。

図２は、本発明によるシステム構成を示す。受動記憶媒体は、左手側に配置され、ここでは図示されない能動端末デバイスは、右手側にある。中央には、モデル化デバイスＭがあり、モデル化デバイスＭは、記憶媒体と端末との間に通信可能に接続される。この目的のために、プラグ接続が、左側と右側との両方に提供されることが可能であり、または、ケーブルが各ケースにおいて提供される。

図２は、底部において、アクセス規則を記憶し、それらをモデル化デバイスＭに対して保持するデータ・メモリも示す。データ・メモリは、外部に配置されてもよく、データ・メモリは、好適な実施形態においてモデル化デバイス内に組み込まれる。提案される発明によれば、エミュレーション構成要素１、２が提供される必要はなく、むしろ修正ユニットを提供すれば十分であることは、先行技術と比較して特に有利である。これは、モデル化デバイスＭにおいて中心に配置される。

図３は、提案されるシステム構成をさらなる図において示しており、プラグ接続は、左側の受動データ・メモリに対して提供され、ケーブル接続は、右側に提供されている。これは異なる形で解決されることも可能であり、左側にもケーブル接続があってもよい。使用されるインターフェースは、従来の仕様に従って設計され得る。好適な実施形態において、インターフェースは、ＵＳＢインターフェースとして実装される。

図４は、概略フロー図において、ファイル・システムの互換性の動的な確立と、ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うための方法であって、能動端末およびモデル化デバイスＭに対して受動データ・メモリのファイル・システムへのアクセスを許可する工程１００であって、モデル化デバイスＭは、受動データ・メモリに対応し、能動端末は、間に通信可能に接続される、許可する工程１００と、モデル化デバイスによる能動端末からのアクセス要求の受け入れ１０１であって、アクセス要求は、アクセス・データと、受動データ・メモリに対するアクセス動作とを指定する、受け入れ１０１と、モデル化デバイスによる受動体積のファイル・システムの認識１０２と、受動データ・メモリの認識された１０２ファイル・システムに従ってアクセス要求を実行するのに適した、記憶されたアクセス規則を選択する工程１０３と、アクセス要求によって指定されるアクセス・データに対して、選択されたアクセス規則を適用する工程１０４と、アクセス要求に従ってアクセス動作を実行する工程１０５とを含む。

当業者は、工程がさらなるサブ工程を有し得ること、および、特に、方法工程は各々、反復しておよび／または異なる順序で実行され得ることを認識する。
以下の工程の全ては、エンド・デバイスの観点から見て説明されており、エンド・デバイスは、主な行為者としてのユーザによって制御される。

図５は、端末デバイス２０１が読み取りアクセス要求を生成する場合に、本発明に従ってモデル化デバイス２０２が何のアクションを実行することができるかを示す。本ケースにおいて、端末は、ファイル・システムとしてＦＡＴ３２をサポートし、これは以下でファイル・システム１と称されることになる。

本発明の一態様によれば、アクセス要求は、端末とモデル化デバイスとの間の通信インターフェースによって行われ、これはＵＳＢインターフェース２０４である。
本発明の一態様によれば、２つの方法が、モデル化デバイスにおいて実装される。追加のデータ２０６を保持するための方法、およびデータ２０７をモデル化するための方法である。データが受動メモリ２０３から読み取られる場合、この工程は、通信インターフェース２０５によって実行される。しかしながら、受動メモリも、モデル化デバイスが接続されるＵＳＢインターフェースを介して接続されることは必須ではなく、２０５もデータバスによって置換されてもよく、その結果、受動メモリは、モデル化デバイスの構成要素として直接実装される。

本発明の一態様によれば、イベントのシーケンスは、どのアクセス要求を端末が開始したかに依存し、これに従って、受動メモリが既に接続されているモデル化デバイスが、端末に接続される。エンド・デバイスのバージョンに依存して、この順序は、以下の例示と異なってもよい。

本発明の一態様によれば、端末は、２つの手法でモデル化デバイスと通信する。一方では、ＵＳＢデバイスに対して責任を負う端末のオペレーティング・システムの構成要素は、ＵＳＢを介して接続されたモデル化デバイスを、「メモリ」タイプの外部ＵＳＢデバイスとして認識する。他方では、オペレーティング・システムのその他の構成要素は、接続された記憶デバイスが論理レベル上でどのようにアドレス指定されるか、具体的には、どのファイル・システムがメモリ上で認識され得るかを決定する。

ＵＳＢプロトコルを使用する第１の通信の場合、本発明の一態様によれば、モデル化デバイスが必須のパラメータを有すること、例えば、ＵＳＢプロトコル・サポートの範囲内の必要なアクションとして、アドレス指定可能なブロックの数またはブロック・サイズを報告することが少なくとも必要である。この目的のために、いわゆる識別要求３０１が開始されてもよく、しかしながら、これは、オペレーティング・システムの実装に依存して、強制的ではない。ＵＳＢプロトコルは、問題なく当業者によって実質的に実行され得るので、このプロトコルに従った指定のアクションは、ここでは取り扱われない。この第１の識別要求は、モデル化デバイスがそれ自体を適宜アラインすることができること、および、そのような識別要求（アドレス指定可能なブロックの数）を処理するために必要なデータが利用可能に維持されることに既につながることのみに留意されたい。

本発明の一態様によれば、これについてのモデル化デバイスの側での第１の必要なアクションは、受動メモリ３１４からファイル・システム・パラメータを読み取ることであり、これは、図７に詳細に示される。以下、ファイル・システム２と称される、受動メモリ上のファイル・システムは、３１４の実行期間中にモデル化デバイスによって認識され、読み出されるデータは、第１の識別要求を満たすことに限定されないが、代わりに、それらがファイル・システム１のブート・セクタ・データとして使用され、モデル化デバイス２０６内にも維持されるような手法で、本発明に従って、まず変換される。したがって、識別要求についての必須のパラメータも十分に決定され（アドレス指定可能なブロックの数、ブロック・サイズ）、モデル化デバイスはＵＳＢプロトコルに従って識別要求を実現する３１０。

次の工程において、端末のオペレーティング・システムは、接続された記憶デバイスが論理レベル上でどのようにアドレス指定されるか、具体的には、どのファイル・システムが記憶デバイス上で認識され得るかを決定する。

この目的のために、端末は、メモリから少なくともブロック０を読み取ることを目的とする、１つ以上のアクセス要求を生成することができ、理由は、これが、ファイル・システムを決定するための情報を含有しているからである。

このアクセス要求に対してサービス提供するために、以下のアクションが、本発明に従って実行されることが可能であり、これは例として図５に示される。
端末の第１のアクセス要求３１１は、位置０から開始して、セクタを読み取れ、である。

第１の工程３１２において、本発明の一態様によれば、要求されるデータがモデル化デバイス内に既に保持されているかどうかがチェックされる。端末３０１の識別要求が、まだ行われていないが、アクセス要求３１１によって置換されることは、除外されることが不可能である。３１１を実行する場合、受動メモリのパラメータは、エンド・デバイスにまだ知られていないであろうが、これは、エンド・デバイスがアクセス要求３１１を生成するのを防止せず、理由は、メモリ・デバイスがアドレス指定可能である場合、位置０は常に読み取られ得るからである。例示の目的のために、３０１に従った識別要求は、前もって行われていないと仮定される。したがって、位置０における第１のセクタについてのデータは、２０６に従ってまだ保持されていない。

第２の工程３１３において、本発明の一態様によれば、セクタが位置０から読み取られる場合、ファイル・システム１の意味におけるどのデータが関与するかがチェックされる。したがって、行為３１３は、読み取り処理期間中に、それが追加のデータであるのか、またはユーザ・データであるのかがチェックされることになる手法で一般に記述される、それがユーザ・データである場合、ファイル・システム１の意味におけるファイルは、それから由来する。

アクセス規則は、このために使用される。上記に示されるように、アクセス規則は、あるファイル・システムからのメタデータが、別のファイル・システムからのメタデータへ、どのように変換されるかを定義する。これらの規則は、ファイル・システム構造のために提供される、ファイル・システムのどのエリアが、他方のファイル・システム上のそれぞれのエリアに対応するかも定義し、したがって、アクセス要求が、メタデータの意味における追加のデータに関与するかどうかを決定することを可能にする。

本アクセス規則４００によれば、セクタが位置０から読み取られる場合、それは、特別な追加のデータ、具体的には、いわゆるブート・セクタに関与する。
アクセス規則によれば、ファイル・システム１についてのブート・セクタは、全てのファイル・システム・パラメータ（ファイル・システム・サイズ、ファイル・システム上の論理ブロック（いわゆるクラスタ）のサイズ、第１のディレクトリについての開始位置等）が既に十分に決定されているような手法で、加算される３１４。これは、このデータが、処理されるまさに最初のアクセス３１１について端末デバイスに対して利用可能に保持されなければならないことを前提とする。基本的に、ファイル・システム１についての全てのパラメータは、受動メモリのファイル・システム２のそれぞれのパラメータから導出または計算される。アクセス規則４０１は、この方法を含み、具体的には、アクセス規則４０１は、ファイル・システム１のパラメータが、それぞれのファイル・システム１／ファイル・システムの２の組み合わせについて、ファイル・システム２に依存して、どのように計算されるか、および、どの指定のアクセス規則が使用されるかを決定する。図は、ブート・セクタ４０１についてのこのアクセス規則がどのように適用されるかを示している。そのような適用は問題ではなく、理由は、ファイル・システム・サイズが知られており、論理ブロックのサイズは、ファイル・システム２から引き継がれ得るからである（これが可能ではない場合、追加のアクセス規則がブロック・サイズ調整に対して適用される）。

このようにして、モデル化デバイスは、セクタ０についてのデータを、端末がさらなるアクセス処理を開始するためにこれを使用することができるような手法で、シミュレーションおよび保持した。

本発明の一態様によれば、具体的には存在する問い合わせ３１１は、モデル化されたブート・セクタ・データが提供される場合に、実現される。
要求されるデータ３１５は、通信インターフェース（ここではＵＳＢ）を介して提供される。したがって、アクセス要求３１１は完了される。

ブロック１読み取りがＦＡＴ３２ブート・セクタであるという結果に第１のアクセス要求がつながるという事実は、端末のさらなるアクションを決定する。
原則として、本発明の一態様によれば、第１のブロックが、有効なコンテンツ（ファイル・システム・パラメータ）を備えた有効なブート・セクタとして認識される場合、端末デバイスのオペレーティング・システムは、ＵＳＢインターフェースによって提供されるメモリ上のファイル・システムを決定するために、アクセス要求を継続すると仮定され得る。そのような処理は「プローブ」とも称されることが可能であり、その目的は、特定の、論理的に体系化されたファイル・システムとしてメモリを認識し、それ自体の論理インターフェース（いわゆる「マウント・ポイント」）をオペレーティング・システム内に露出することである。

代替として、第１のアクセス要求が満たされ、第１のブロックのコンテンツが、妥当なブート・セクタであると判明した後、端末のオペレーティング・システムは、その構成要素またはアプリケーションに対してメッセージ（いわゆる「ブロードキャスト」）を送って、それらに対して、新しい１つの記憶デバイスの利用可能性に関して通知することもできる。結果として、責任を負う構成要素およびファイル・システム・ドライバは、別の処理を開始することができ、これは「マウンティング」と称されることが多い。

両方の代替案は、同じ結果につながり、すなわち、利用可能にされた新しいメモリは、ＦＡＴ３２として認識され、エンド・デバイスのオペレーティング・システム、または構成要素もしくはアプリケーションのうちの１つ以上は、これを論理ファイル・システムとしてアドレス指定することができる。

本発明の一態様によれば、このファイル・システムが読み取り動作のためにのみマウントされるのか、または書き込み動作のためにもマウントされるのかは、以下の要因、すなわち、端末のオペレーティング・システム、それぞれのファイル・システムについてのサポートの範囲、および外部的に接続可能な記憶媒体に対して端末が有し提供するタスクに依存する。以下の解説は、読み取り／書き込みモードを取り扱う。本発明により提案される方法は、それが読み取り／書き込みモードにおける約束された成功につながる場合、読み取りモードのためになおさら使用され得るので、ファイル・システムが読み込みモードにおいてのみメモリ上にマウントされるケースは、別々に扱われる必要はない。

したがって、エンド・デバイスからのさらなるアクセス要求は、「新しいメモリが利用可能である」イベントの場合にどのタスクが計画されるかに依存する。端末は、新しく提供されるメモリのコンテンツを読み取ろうとする特定のアプリケーションを実行していることがあるかもしれず、これは、ルート・ディレクトリのコンテンツがまずアクセスされることを意味する。アプリケーションが自動的に開始されない場合、モデル・デバイスをデバイスに対して接続するユーザは、メモリのコンテンツを呼び出すためのさらなるアクションを引き受け、次いで、さらなる工程をユーザ自身で決定するために「ルート・ディレクトリのコンテンツを呼び出す」行為を始める。ルート・ディレクトリのコンテンツを取り出すために、ユーザは、「ｄｉｒ」または「ｌｓ」などの端末コマンドも入力し得る。せいぜい、端末デバイスが次のアクセス要求によりルート・ディレクトリのコンテンツを読み取ろうと試行するであろうことが予期され得る。このアクセス要求に対してサービス提供するために、以下のアクションが、本発明に従って実行されることが可能であり、これも例として図５に示される。

本発明の一態様によれば、ルート・ディレクトリ・エリアはセクタＸにおいて開始し、１００個セクタのエリアを占有し、これは工程３１４に対して適用される規則によって決定されたものと仮定される。したがって、第２のアクセス要求３２１は、セクタＸから開始して、１００個のセクタの読み取り、と読み取れるであろう。

第１の工程３１２において、本発明の一態様によれば、要求されたデータが既に利用可能であるかどうかがチェックされる。本ケースにおいて、端末は今までにセクタ０しか読み取っていないので、データはまだ利用可能ではない。

第２の工程３１３において、位置Ｘ以降、１００個のセクタが読み取られる場合、ファイル・システム１の意味におけるどのデータが関与するのかに関してチェックが行われる。アクセス規則は、このために使用される。

アクセス規則４００によれば、これは、特に、要求される長さ（１００個のセクタ）全体にわたり、セクタＸが、モデル化されたファイル・システムについてアクセスされる場合、ルート・ディレクトリとして知られているものである。

モデル化デバイス２０２が、端末のルート・ディレクトリについてのデータを保持する２０６ことができるように、さらなるアクセス規則が、後続の工程３２４（図９を参照）において、このシステム・ファイル・システム１・ルート・ディレクトリ・データ・フォーマットのルート・ディレクトリ内のファイルについてのこのシステムのルート・ディレクトリ内のファイルについてリアル・タイムでメタデータが生成されるような手法で適用される。

したがって、このメタデータは、ファイル・システム２上のファイルを、ファイル・システム１（ここではＦＡＴ３２）をサポートする端末の各構成要素が、あたかもこれらの書き換えられるファイルがモデル化デバイスにおいて保持されているかのように、それらを解釈するような手法で、書き換えるのに適している。本発明によれば、このメタデータは、端末からの現在および将来のアクセス要求のために記憶される２０６。

アクセス規則３２４の適用のために、ルート・ディレクトリ構造のどのファイルが、要求された１００個のセクタによってアドレス指定可能であるのか、および、それらがどのサイズを有するのかに関する完全な知識を獲得するために、ならびに、方法４０４（図１０を参照）によって、上述されたファイルがファイル・システム２のどのエリアにおいて位置付けられるのかを決定するために、ファイル・システム２からさらなるメタデータを読み出すことが必要となり得る。

中間的な結果において：ファイル・システム１に対応するフォーマットでルート・ディレクトリをモデル化することによって、要求よりも多くのデータが読み取られてもよく、これは無害である。その理由は、最初に余分に読み取られるそのようなデータは、アクセス規則のさらなる適用のために利用可能に維持されるからである。

工程３２１からの、端末からの実際に存在する読み取りアクセス要求は、アクセス規則を使用してモデル化された１００個のセクタを提供することによって実現される。
要求されたデータは、通信インターフェース（ここではＵＳＢ）を介して提供される３２５。したがって、アクセス要求３２１が完了される。

ルート・ディレクトリ・コンテンツが端末に対して利用可能にされた後、そのアプリケーションは、ユーザに対して、さらなる工程、例えば、ファイルを開くこと、または特定の処理（印刷、ビデオ／オーディオ・ファイルの再生等）のためにファイル・コンテンツを選択することなどを行うように促すことができる。この時点において、ファイル・コンテンツは、外部記憶媒体からアクセスされ、エンド・デバイスのオペレーティング・システム構成要素（またはそのファイル・システム・ドライバ）は、必要とされるコンテンツをファイルから取り出すために、マウントされた論理ボリュームに対する要求を生成する。

本発明の一態様によれば、ファイルＡＢＣ．ＺＹＺのコンテンツがアクセスされていると仮定され、ファイル・サイズは１０個のブロックであると仮定される。
このアクセス要求に対してサービス提供するために、以下のアクションが、本発明に従って実行されることが可能であり、これも例として図５に示される。

アクセス要求３５１が開始され、これは、位置Ｐｏｓ１から１０個のブロックを読み取ることで構成され、これは、ファイル・システム１上のファイルＡＢＣ．ＺＹＺ ＳＣ１の第１のクラスタに対応する。

これらのデータは、まだ要求されていないので、それらはまだ利用可能２０６ではない。
まず、この要求がユーザ・データに関与するのか、または追加のデータに関与するのかどうかが決定されなければならない３１３。

このクエリがユーザ・データに関するものであるという事実は、クエリ３２１を実現するためにＦＡＴ構造４０２をモデル化する場合に、ＡＢＣ．ＸＹＺファイルのサイズが考慮に入れられ、そのコンテンツについて、ファイル割り当てテーブル内の切れ目のないモデル化されたチェーンが保持されるという事実から既にもたらされる。

すなわち、モデル化方法４０２は、ファイル・システム２の既存ファイルを、これらのファイルが、いくつかの分割されたコンテンツ・フラグメントからファイル・システム２上で生じるかどうかにかかわらず、それらがフラグメント化されないような手法で、モデル化されたファイル・システム１上に位置付けるのに適している。

したがって、アクセス要求３５１データによって読み取られたものは、ユーザ・データである。
さらなる工程３５４において、本発明の一態様によれば、どのユーザ・データが実際にアクセスされているかがチェックされる。エンド・デバイスが、ＡＢＣ．ＸＹＺのためだけでなく、いくつかのファイルに対してアクセス要求を行い得ることは、除外されることができない。これは、方法４０４（図１０を参照）によって決定され、方法４０４は、ファイル・システム１の意味における一定のブロックがアクセスされる場合に、ファイル・システム２上のどのファイルが実際に関与するかを決定する。したがって、この方法４０４は、異なるファイルのアクセスされるコンテンツについての特定のコンテキストにおいて引き受けられる、さらなるアクションを決定するのに適している。そのようなコンテキストは、ユーザ・データに対応する一定のブロックがファイル・システム１から読み取られる場合、読み取られる対応するブロックがファイル・システム２上で常に決定されることを確立する。結果として、ユーザ・データは、受動メモリに対して向けられる、対応するアクセス要求３５５によって読み出される。要求されたコンテンツが、切れ目のないチェーンとしてファイル・システム２上に位置付けられていない場合、要求３５１によって要求された全てのデータが読み出されるまで、処理３５５が繰り返される。

要求されたデータは、通信インターフェース（ここではＵＳＢ）を介して提供される３５６。したがって、アクセス要求３５１が完了される。
ルート・ディレクトリ・コンテンツが、エンド・デバイスに対して提供された後、そのアプリケーションは、ユーザに対して、さらなる工程、例えば、エンド・デバイス上で生成されたデータをマウントされた論理ボリューム上に保存することを行うように促すことができる。例えば、新しい文書が走査される場合、マウントされた論理ボリュームは、ターゲット記憶ロケーションとして選択されることが可能である。

エンド・デバイスは、このユーザ・データを、１９個のブロックのボリュームを有するユーザ・データがエンド・デバイス上で生成された後に、ファイル・システム１上のルート・ディレクトリ内でＸＸＸ．ＡＢＣという名称を有するファイルとして作成しようとし、新しく作成されるファイルＸＸＸ．ＡＢＣのコンテンツは位置Ｐｏｓ２から開始すると仮定される。

本発明の一態様によれば、端末は、ユーザ・データがまだ定義されていない場合、新しいファイルについてファイル・システム１のルート・ディレクトリ内でファイル名およびファイル・サイズを記述することを目的とするアクセス要求を作成せず、この新しく作成されるデータについての全てのユーザ・データが記述される場合にのみ、そのような要求が行われる、とさらに仮定される。

この仮定の理由は、読み取りアクセス要求および書き込みアクセス要求を最適化するための方法が端末上で実装される可能性である。
端末が、それぞれのファイルについてのメタデータが別のアクセス要求によって記述される前に、ユーザ・データを書き込もうとすると仮定されている場合、書き込まれる新しいブロックがファイルに対してまだ割り当てられることができないという不確実性が、方法４０４の意味において生じる。しかしながら、この保留状態は、遅くとも、メモリ上の新しく作成されるファイルについてのメタデータを更新することを目的としたアクセス要求を端末が生成するときに、終了される。

このアクセス要求にサービス提供するために、以下のアクションが、本発明に従って実行されることが可能であり、これも例として図６に示される。
ＳＣＮ＋１に対応する、位置Ｐｏｓ２から開始して、１９個のブロックを書き込むことから成るアクセス要求３３１が開始される。

まず、書き込まれるこのデータが利用可能である２０６かどうかが、チェックされなければならない３３２。位置Ｐｏｓ２におけるデータは、読み取られても書き込まれてもいないので、まだ利用可能でもない。

次の工程において、この要求は、ユーザ・データに関係するのか、または追加のデータに関係するのかが、決定されることになる３３３。したがって、アクション３３３は、それが追加のデータに関係するのか、またはユーザ・データに関係するのか、および、それがユーザ・データに関係する場合、ファイル・システム１の意味におけるどのファイルにそれが由来するのかが、書き込み処理期間中にチェックされることになるような手法で、一般に記述されることになる。

これはまだ明らかに決定されることができず、理由は、これらのブロックが、メタデータ２０６として保持されているわけでも、それらが３５１の意味においてユーザ・データとして読み取られているわけでもないからである。次の工程３３４において、方法４０５（図９を参照）によれば、ユーザ・データが関与しており、書き込まれるブロックが適宜扱われると最初に仮定される。ブロックはファイルに対してまだ割り当てられることができないので、これは、いわゆる浮遊状態を始める。モデル化デバイスは、さらなる通知２０６まで、書き込まれるデータをユーザ・データとして保持することになるが、書き込み処理の完了は、通信インターフェース２０４を介して報告される３３５。したがって、アクセス要求３３１が完了される。

ファイル・システム１についてのルート・ディレクトリ・コンテンツが更新される場合、さらなるアクセス要求３３６が開始され、これは、位置Ｘ＋９９から始まるブロックを書き込むことに向けられると仮定される。具体的には、それはルート・ディレクトリの最後のセクタである。

まず、書き込まれるこのデータが利用可能である２０６かどうかが、チェックされなければならない３３２。これがここで当てはまるのは、位置Ｘ＋９９におけるブロックは、既にモデル化されており３２４、ファイル・システム１についてのルート・ディレクトリとして、工程３２１において予約されている２０６からである。

データ・ブロックが既に利用可能であり、それがメタデータである場合、アクセス規則の適用は、どの特定の変更が関与するのかを決定する３３９ために使用され得る。対応する方法は、図９に示されており４０６、これは、ルート・ディレクトリ構造における変更を確認し、それらを抽象的な記述として定義することで構成され、そこから、どの対応する変更がファイル・システム２上で行われるかが結論づけられることが可能である。これは、ルート・ディレクトリ内に過去に存在しなかった、ＸＸＸ．ＡＢＣファイルに対する新しいエントリである。この変更は、あたかもエンド・デバイスが、Ｐｏｓ２から開始して、１９個のセクタのサイズを有するＸＸＸ．ＡＢＣと呼ばれる新しいファイルを作成することを欲したかのように、記述されることが可能である。アクションのそのような抽象的な記述も、Ｐｏｓｉｘ標準と同様であり得る。

さらなる工程において、本発明の一態様によれば、特定の変更は、抽象的な記述を受動メモリに対する対応する要求に変換することによって、ファイル・システム２に対して適用されることになる。結果として、データＸＸＸ．ＡＢＣに対するエントリは、ファイル・システム２上で作成され、しかしながら、これは、ファイル・システム２上でのこのファイルの開始位置をまだ指定せず、ただし、開始位置はファイル・システム１上では既に指定されている。このことから、保留状態において、ファイル・システム１に対する指定のファイルのユーザ・データの割り当て可能性に関して、４０４の意味における不確実性が依然としてあることになる。しかしながら、この不確実性は、ＦＡＴを用いてエリアを更新することを目的としたアクセス要求により解決され、これは後述されることになる。

最後に、書き込み処理の実現は、通信インターフェース２０４を介して報告される３４０。したがって、アクセス要求３３６が完了される。
エンド・デバイスまたはそのアプリケーションが、全ての必要なユーザタスク、例えば、文書を走査し、このデータを外部媒体上に位置付けること、または他のユーザ生成されたコンテンツをトランスポートすることなどを完了した後、外部媒体は、エンド・デバイスから分離されることが可能である。

いくつかのエンド・デバイスは、これらの処理についてのデータ・セキュリティを保証することを可能にするために、ユーザに対して、外部デバイスをアンマウントすることを明示的に要求する。その結果、アンマウント処理の完了が待機され、完了した場合にのみ、外部媒体とエンド・デバイスとの分離が行われることになるアンマウント処理の実行を、エンド・デバイスが要求する前に、ユーザが外部媒体を除去した場合、ユーザは、起こり得るデータの損失に対して単独で責任を負うことになる。ユーザは、エンド・デバイスから外部媒体を分離することになると、性急になる傾向があるので、外部ストレージを除去するそのようなセキュアな方法は、標準として強制することが容易ではない。ユーザは、アンマウント処理を実行し、待機することを期待せず、むしろ、デバイス・アクティビティが完了し、デバイスが、エンド・デバイス上で容易に読み取られることが可能であるアイドル状態になるとすぐに、外部記憶媒体を単純に引き抜くことが可能であることを欲する。ユーザのこれらの期待を満たすために、端末デバイスのオペレーティング・システムは、通常、外部記憶媒体と共に作動することができるように、ファイル・システム・ドライバのための同期技術をサポートする。

この技術は、エンド・デバイスのメイン・メモリ内に記憶されるファイル・システム・データのコンテンツを空にすることによって、外部記憶媒体を最新に常に維持し、これは、通常、オペレーティング・システム自体によって開始される。これは以下を意味する：エンド・デバイスまたはそのアプリケーションが、外部記憶媒体が関与し得るそのタスクを実現し、アイドル状態に切り替わった後（および、ユーザからのさらなる入力またはさらなる指示を待機中）、ファイル・システム・ドライバまたは同様の構成要素は、外部媒体に対してまだ書き込まれていないブロックを空にすることができ、これは、外部記憶媒体が急に接続解除された場合に、データ・セキュリティを確実にする。そのような同期技法は、外部メモリに対するさらなるアクセス要求につながる。

ＦＡＴによる、そのような読み取りおよび書き込み試行を容易にするために、以下のアクション、例えば、ファイル・システム１からＦＡＴを読み取ることなどが、本発明に従って実行されることが可能である。

ＦＡＴを読み取ることに向けられたアクセス要求は、遅くとも、マウンティング後にファイルを読み取るための最初の試行と共に、またはマウンティング後にサブディレクトリに対してアクセスするための最初試みの後に、発生することに留意されたい。

ＦＡＴ（ＦＡＴ割り当てテーブル）は、ファイル・システム１の観点からファイルのエリア位置付けを定義する表であるので、そのような構造は、ファイル・システム２上にはいかなる形でも存在せず、ファイル・システム２の並列構造に対するアクセス規則の適用を通じてのみ生じる。結果として、ＦＡＴは、モデル化デバイス２０２上で保持される。また、そのような構造は、個々のファイルについてではなく、ファイル・システム１上に位置する全てのファイルについて、メタデータを書き換え、ユーザ・データではない追加のデータのタイプを表す。

しかしながら、ＦＡＴ３２４は、ファイル・システム２上に存在する全てのファイルに対して累積的にモデル化されるわけではなく、アクセス要求期間中に要求された３１４ファイルに対してのみ、その位置付けを記述したメタデータがこのファイルについてモデル化されない限り、ファイル・パスを直接指定することによって）、モデル化される。そのようなモデル化の結果は、方法４０４の適用可能性であり、これはファイル・ユーザ・データが割り当てられることを可能にする。

対応する方法は、図９に示されており、これは、ＦＡＴにおける変更４０５を確認し、それらを抽象的な記述として定義することで構成され、そこから、どの対応する変更がファイル・システム２上で行われるかが結論づけられることが可能である。

まず、アクセス規則４００に従って、このアクセス要求がＦＡＴのエリア内にあるかどうかが、問題なしに決定され得ることに留意されたい。
ＦＡＴの更新は、ファイルＸＸＸ．ＡＢＣに対して割り当てチェーンを少なくともマッピングすることを目的とすると仮定される。エンド・デバイスに対する書き込み動作は、最適化された手法で実行されるので、ＦＡＴの更新が特定のファイルに対する特定の割り当てチェーンにのみ着目するであろうことは、期待され得ない。むしろ、複数のファイルについてのＦＡＴに対する更新は累積的になるであろうことが期待される。どの変更が特に意図されるかは、ＦＡＴについての状況を比較することによって決定され得る４０５。

これは、割り当てチェーンがまだ存在していない、ＸＸＸ．ＡＢＣファイルに対する新しいエントリである。したがって、この変更は、あたかも（ＳＣＮ＋１）から開始する、１９個のセクタを含む、ＸＸＸ．ＡＢＣという名称の新しいファイルについての切れ目のない割り当てチェーンをエンド・デバイスが作成することを欲したかのように、記述され得る。

さらなる工程において、この抽象的な記述がファイル・システム２上の構造に適合しなければならないという点で、ターゲットとされた変更は、ファイル・システム２に対して適用される４０５ことになり、ファイル・システム２上の構造は、ファイル・システム上のユーザ・データの位置付けを管理する。これは、方法４０４の意味において、ユーザ・データの割り当て可能性に関する不確実性がもはやなく、モデル化デバイスにおいて依然として保持された、要求３３１に従って書き込まれるこれらのユーザ・データは、今や受動メモリの対応する位置へ書き込まれることも意味する。

結果として、クエリ３３６が処理されたときに行われたように、データＸＸＸ．ＡＢＣについてのエントリが、ファイル・システム２上に作成されるだけでなく、ファイルＸＸＸ．ＡＢＣの位置付けも、ファイル・システム１上と、ファイル・システム２上との両方で指定される。

最後に、書き込み処理の完了が、通信インターフェース２０４を介して報告される。したがって、ＦＡＴに対するアクセス要求が完了される。
最後に、他のところで実行される端末デバイスのアクションは、異なる順序で行われてもよく、ファイル・システム１に対するあらゆる変更は、常に、アクセス要求を直接もたらすことに留意されたい。結果として、ファイル・システム１の常に連続した更新は、除外されている方法４０４の意味における保留状態をもたらすので、モデル化デバイスの上述されたアクションは変化しない。

参照符号のリスト
１ エミュレータ１
２ エミュレータ２
Ｍ モデル化デバイス
（１００）～（１０５） 詳細な説明を参照
（２０１） 端末
（２０２） モデル化デバイス
（２０３） 受動ストレージ
（２０４） 通信インターフェース（２０１）～（２０２）
（２０５） 通信インターフェース（２０２）～（２０３）
（２０６） 追加のデータを保持するための手続き
（２０７） データをモデル化するための技法
（３０１）、（３１０）、（３１１）、（３１２）、（３１３）、（３１５）、（３２５）、（３５１）、（３５５）、（３５６） － 詳細な説明を参照。
（３１４） ブート・セクタ構造およびファイル・システム・パラメータのモデル化
（３２４） ディレクトリ・データのモデル化
（３５４） （３３１）、（３３２）、（３３３）、（３３５）、（３３６）、（３４９）を読み取る場合のユーザ・データの仕様 － 詳細な説明を参照。
（３３４） 書き込む場合のユーザ・データの仕様
（３３９） メタデータ変更の確認
（３１４） （ファイル・システム２）に基づいた、（ファイル・システム１）についてのブート・セクタ構造のモデル化
（Ｆｉｌｅｓｙｓｔｅｍ１） ファイル・システム１
（Ｆｉｌｅｓｙｓｔｅｍ２） ファイル・システム２
（ＢｙｔｅｓＰｅｒＳｅｃｔｏｒ） バイト数でのセクタ・サイズ：元の（ＩＮ）値（Ｖａｌｕｅ１＿２）を有し、アクセス規則（ＢＳ１）に従った変換を通じて、新しい（ＯＵＴ）値および新しいフォーマット（Ｖａｌｕｅ１＿１）をおそらく受信するパラメータ
ファイル・システムのさらなるパラメータまたは特性：
（ＳｅｃｔｏｒＰｅｒＣｌｕｓｔｅｒ） クラスタ当たりのセクタの数
（ＣｌｕｓｔｅｒＰｅｒＶｏｌｕｍｅ） ドライブ当たりのクラスタの数
（ＶｏｌｕｍｅＬａｂｅｌ） ドライブ・ラベル
（Ｅｔｃ） － 等
（ＦＳＰｒｏｐｅｒｔｙＮ） ファイル・システムのプロパティＮ：元の（ＩＮ）値（ＶａｌｕｅＮ＿２）、ならびに、おそらく、新しい（ＯＵＴ）値および新フォーマット（ＶａｌｕｅＮ＿１）を有する、（ファイル・システム２）上の別のパラメータ
（ＩＮ） 初期値
（ＶａｌｕｅＮ） 値Ｎ
（Ｒｕｌｅ） 規則、アクセス規則（ＢＳ２、ＢＳ３等）
（Ｏｕｔ） エンド値
（ＢＳＭｅｍｂｅｒＮ）
（ＡＶ） 利用可能：（２０６）において予約されるセクタについての利用可能性。（ＥＭＰＴＹ）は、「保持されない」ことを意味する。 － （ＡＶ）は、「保持された」ことを意味する
（Ｌａｓｔ） 最後：予約されたセクタの位置
（３２４） ディレクトリ・データのモデル化
（ＳｔａｔｅＮｏｗ） 現在のステータス：ファイル・システム１上のＦＡＴの現在のステータス
（ＳｔａｔｅＮｏｗ－１） おそらく未知であり、まだ初期化されていない状態である、ファイル・システム１上のＦＡＴの過去の状態。
（Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅｓｙｓｔｅｍ１） ファイル・システム１（モデル化済み）上のディレクトリ構造
（Ｄｉｒｅｃｔｏｒｙ，Ｆｉｌｅｓｙｓｔｅｍ２） ファイル・システム２上のディレクトリ構造
（Ｆｉｌｅ１．．．ＦｉｌｅＮ） ファイル１．．．ファイルＮ：ファイル・オブジェクトのファイル名
（Ｅｘｔ１．．．ＥｘｔＮ） 拡張子１．．．拡張子Ｎ：ファイル・オブジェクト拡張子
（Ｓｉｚｅ１．．．ＳｉｚｅＮ） サイズ１．．．サイズＮ：ファイル・オブジェクトのサイズ
（Ｓｃ１．．．ＳｃＮ） クラスタ１を開始．．．クラスタＮを開始：ＦＡＴの観点でのファイルの第１のクラスタ。この値は、（４０２）に従ってファイル・システム１についてモデル化される。
（Ｎｃ１ｏｆＮ） Ｎ個のうちの次のクラスタ１：Ｎ個上の後続クラスタ１
（Ｍ＋１） （ファイル・システム１）上のＦＡＴにおける次の自由位置
（４０２） この方法は、ファイル・システム２によって要求されたファイルについて、ファイル・システム１上でＦＡＴ構造をモデル化する。結果として、ファイル・システム１上のファイルの位置付けは、最初はフラグメント化されない。
（４０２ａ） 「（ｆｉｌｅｓｙｓｔｅｍ２）のルート・ディレクトリのコンテンツを読み取れ、という反復処理を開始する
（４０２ｂ） 開始するクラスタが、反復されるコンテンツについて定義されるかを決定する。
（４０２ｃ） 反復されるコンテンツを有するエリアにわたる（ｆｉｌｅ ｓｙｓｔｅｍ１）のモデル化
（４０２ｄ） 「（ｆｉｌｅｓｙｓｔｅｍ２）のルート・ディレクトリのコンテンツを読み取れ、という反復処理を終了する
（４０５） ＦＡＴに対する変更の確認
（ＳｔａｔｅＮｏｗ） 現在のステータス：ファイル・システム１上のＦＡＴの現在のステータス
（ＳｔａｔｅＮｏｗ－１） ファイル・システム１上のＦＡＴの過去の状態
（ＳｃＮ） クラスタＮを開始する：ＦＡＴ Ｎの観点でのファイルの第１のクラスタ
（Ｎｃ１ｏｆＮ） Ｎ個のうちの次のクラスタ１：Ｎ個上の後続のクラスタ１
（ＬｃｏｆＮ） Ｎ個のうち最後のクラスタ：Ｎ個上の最後のクラスタ
（Ｆｒｅｅ） 自由：占有されていないセクタ
（Ｍ＋１） （ｆｉｌｅ ｓｙｓｔｅｍ１）上のＦＡＴ内の次の自由位置
（Ｌａｓｔ） 最後のセクタ：予約されたセクタの位置
（ＱｕａｌｉｆｉｅｄＤｉｆｆｅｒｅｎｃｅＦＡＴ） 評価、すなわち、これらの変更の確認の結果：（ＳｔａｔｅＮｏｗ）と（ＳｔａｔｅＮｏｗ－１）との間の違いは、「Ｃｒｅａｔｅ＿ａ＿ｎｅｗ＿ｆｉｌｅ」についての新しいチェーンとして記述され得る。新しいチェーンは、クラスタ（Ｋ＋Ｍ＋１）から開始し、１９個のセクタ（Ｌ）の長さとなる。
（４０６） ディレクトリ構造に対する変更の確認
（ＳｔａｔｅＮｏｗ） 現在のステータス：ファイル・システム１上のディレクトリ構造の現在のステータス
（ＳｔａｔｅＮｏｗ－１） 実際の状態１：ファイル・システム１上のディレクトリ構造の元の状態
（Ｆｉｌｅ１）、（Ｆｉｌｅ２）、（Ｆｉｌｅ３）、（ＦｉｌｅＮ） ファイル１、ファイル２．．．ファイルＮ：１からＮまでの、ディレクトリ構造内のエントリに従った、ファイル・オブジェクトのファイル名
（Ｅｘｔ１）、（Ｅｘｔ２）、（Ｅｘｔ３）、（ＥｘｔｔＮ） 拡張子１．．．拡張子Ｎ：１からＮまでの、ディレクトリ構造内のエントリに従った、ファイル・オブジェクト拡張子
（Ｓｉｚｅ１）、（Ｓｉｚｅ２）、（Ｓｉｚｅ３）、（ＳｉｚｅＮ） サイズ１．．．サイズＮ：１からＮまでの、ディレクトリ構造内のエントリに従った、ファイル・オブジェクトのサイズ
（Ｓｃ１）、（Ｓｃ２）、（Ｓｃ３）、（ＳｃＮ）、（Ｓｃ Ｎ＋１） １からＮ＋１までの、ディレクトリ構造内のエントリに対応する、ファイル・オブジェクトのクラスタ値を開始する
（ＱｕａｌｉｆｉｅｄＤｉｆｆｅｒｅｎｃｅＤｉｒ） これらの変更の確認の結果：（ＳｔａｔｅＮｏｗ）と（ＳｔａｔｅＮｏｗ－１）との間の違いは、新しいファイル動作として記述され得る。新しいファイルは、（ＳＣ Ｎ＋１）において開始し、拡張子ＡＢＣを備えた名称ＸＸＸを有し、１９＊５１２バイトの長さを有する。
（４０４） ファイルに対するユーザ・データの所属の決定
（ＳｃＮ） クラスタＮを開始する：ＦＡＴ Ｎの観点でのファイルの第１のクラスタ
（Ｎｃ１ｏｆＮ） Ｎ個のうちの次のクラスタ１：Ｎ個上の後続のクラスタ１
（ＬｃｏｆＮ） Ｎ個のうちの最後のクラスタ：Ｎ個上の最後のクラスタ
（Ｍ＋１） （ｆｉｌｅ ｓｙｓｔｅｍ１）上のＦＡＴ内の次の自由位置
（Ｆｒｅｅ） 自由：占有されていないセクタ
（Ｌａｓｔ） 最後のセクタ：予約されたセクタの位置
（Ｒａｎｇｅ） 範囲：ファイル・システムによって占有されるセクタ
（Ｆｉｌｅｓｙｓｔｅｍ１） ファイル・システム１
（ＯＦＦＳＥＴ） オフセット：セグメント部分に加えて、メモリアドレスにおける第２の構成要素（整数値）
（Ｓｉｚｅ１） サイズ１：ファイル・オブジェクトのサイズ
（Ｆｉｌｅ１＿ｆｓ２） ファイル・システム２上のファイル１
（Ｆｉｌｅ１＿ｆｓ２） ファイル・システム２上のファイル１
（Ｅｘｔ１）、（Ｅｘｔ２）、（Ｅｘｔ３）、（ＥｘｔｔＮ） 拡張子１．．．拡張子Ｎ：ファイル・オブジェクト拡張子
（Ｓｉｚｅ１）、（Ｓｉｚｅ２）、（Ｓｉｚｅ３）、（ＳｉｚｅＮ） サイズ１．．．サイズＮ：ファイル・オブジェクトのサイズ
（Ｆｉｌｅ１）、（Ｆｉｌｅ２）、（Ｆｉｌｅ３）、（ＦｉｌｅＮ） ファイル１．．．ファイルＮ：ファイル・オブジェクトのファイル名

Claims (14)

1. ファイル・システムの互換性の動的な確立と、前記ファイル・システムに依存しないデータに対するアクセスと、をリアル・タイムで行うための方法であって、
   －能動端末およびモデル化デバイス（Ｍ）に対して、受動データ・メモリの前記ファイル・システムに対するアクセスを許可する工程（１００）であって、前記モデル化デバイス（Ｍ）は、前記受動データ・メモリと前記能動端末との間に通信可能に接続される、許可工程（１００）と、
   －前記モデル化デバイス（Ｍ）によって、前記能動端末からのアクセス要求を受信する工程（１０１）であって、前記アクセス要求は、アクセス・データと、前記受動データ・メモリに対するアクセス動作とを指定する、受信する工程（１０１）と、
   －前記モデル化デバイス（Ｍ）によって、前記受動データ・メモリの前記ファイル・システムを認識する認識工程（１０２）と、
   －前記受動データ・メモリの認識された（１０２）前記ファイル・システムに従って、前記アクセス要求を実行するのに適した、記憶されたアクセス規則を選択する工程（１０３）であって、前記アクセス規則は、第１の列内に前記能動端末のファイル・システムを記述し、第２の列内に前記受動データ・メモリの前記ファイル・システムを記述し、第３の列が、それぞれのアクセス規則を指すポインタを提供する表が提供されるように選択される、工程（１０３）と、
   －前記モデル化デバイス（Ｍ）によって、アクセス・データに対して、選択された前記アクセス規則を適用する工程（１０４）であって、前記アクセス・データは、前記アクセス要求によって指定される、適用工程（１０４）と、
   －前記アクセス要求に従って、前記アクセス動作を実行する実行工程（１０５）と
   を備える、方法。
2. 前記許可工程（１００）は、ブート・セクタの認識と、マウント処理と、前記モデル化デバイス（Ｍ）における前記受動データ・メモリの統合と、前記能動端末における前記受動データ・キャリアの統合と、通信可能な結合と、１つ以上のプラグ接続を確立する工程と、アクセスを起動する工程と、アクセス権と、データ通信をセット・アップする工程と、のうちの１つ以上を備えることを特徴とする、請求項１に記載の方法。
3. 前記能動端末は、前記アクセス要求を生成するオペレーティング・システムを有することを特徴とする、請求項１または２に記載の方法。
4. 前記適用工程（１０４）および前記実行工程（１０５）は、データ・ストリームごとに反復して実行され、前記オペレーティング・システムは、前記データ・ストリームを定義することを特徴とする、請求項３に記載の方法。
5. 前記アクセス要求は、１つ以上の読み取り要求と、書き込み要求と、のうちの一方または両方を備えることを特徴とする、請求項１乃至４のいずれか１項に記載の方法。
6. 前記アクセス要求は、ペイロード・データと、追加のデータと、のうちの一方または両方を指定することを特徴とする、請求項１乃至５のいずれか１項に記載の方法。
7. アクセス・データは、ファイル名と、絶対メモリアドレスと、相対メモリアドレスと、ファイル・タイプと、ファイル・プロパティと、のうちの１つ以上を記述することを特徴とする、請求項１乃至６のいずれか１項に記載の方法。
8. アクセス動作は、読み取り動作と、書き込み動作と、のうちの一方または両方を記述することを特徴とする、請求項１乃至７のいずれか１項に記載の方法。
9. 前記アクセス規則は、前記アクセス・データが前記ファイル・システムに従って読み取られるか、書き込まれるか、またはその両方が行われるように、アクセス・データの追加のデータがどのようにモデル化されるかを指定する修正動作を記述することを特徴とする、請求項１乃至８のいずれか１項に記載の方法。
10. アクセス規則は、第１のファイル・システムに従ったデータを、第２のファイル・システムにどのように書き込むか、第２のファイル・システムからどのように読み取るか、またはその両方を記述することを特徴とする、請求項１乃至９のいずれか１項に記載の方法。
11. 前記認識工程（１０２）は、ブート・セクタを認識する工程を含むことを特徴とする、請求項１乃至１０のいずれか１項に記載の方法。
12. 前記アクセス要求に従って、書き込み動作を実行する工程（１０５）は、ファイル・サイズが前記ファイル・システムによって限定される場合、対応するファイルを２つ以上の個々のファイルに分割することを特徴とする、請求項１乃至１１のいずれか１項に記載の方法。
13. ファイル・システムの互換性の動的な確立と、前記ファイル・システムに依存しないリアル・タイムでのデータに対するアクセスと、のためのシステム構成であって、
    －能動端末に対して、受動データ・メモリの前記ファイル・システムに対するアクセスを許可する（１００）ように構成された１つ以上のインターフェース・ユニットと、前記受動データ・メモリと前記能動端末との間に通信可能に接続されるモデル化デバイス（Ｍ）と、を備え、
    －前記モデル化デバイス（Ｍ）は、前記能動端末からアクセス要求を受信する（１０１）ように構成され、前記アクセス要求は、アクセス・データと、前記受動データ・メモリに対するアクセス動作とを指定し、
    －前記モデル化デバイス（Ｍ）は、前記受動データ・キャリアの前記ファイル・システムを認識する（１０２）ようにセット・アップされ、前記システム構成はさらに、
    －前記受動データ・メモリの認識された（１０２）前記ファイル・システムに従って前記アクセス要求を実行するのに適した、記憶されたアクセス規則を選択する（１０３）ように構成されたデータベース・ユニットを備え、前記アクセス規則は、第１の列内に前記能動端末のファイル・システムを記述し、第２の列内に前記受動データ・メモリの前記ファイル・システムを記述し、第３の列が、それぞれのアクセス規則を指すポインタを提供する表が提供されるように選択され、
    －前記モデル化デバイス（Ｍ）は、前記アクセス要求によって指定されるアクセス・データに対して、選択された前記アクセス規則を適用する（１０４）ように構成され、前記システム構成はさらに、
    －前記アクセス要求に従って前記アクセス動作を実行する（１０５）ように構成された前記受動データ・メモリを備える、システム構成。
14. 制御コマンドを備えたコンピュータ・プログラムであって、前記制御コマンドは、前記制御コマンドがコンピュータ上で実行される場合、請求項１乃至１２のいずれか１項に記載の方法を実行する、コンピュータ・プログラム。

Images