JP2001325134A

JP2001325134A - ディレクトリ設定方法、記録装置

Info

Publication number: JP2001325134A
Application number: JP2000147479A
Authority: JP
Inventors: Yoko Matsuura; 陽子松浦; Tomotaka Yamazaki; 友敬山崎
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2000-05-15
Filing date: 2000-05-15
Publication date: 2001-11-22

Abstract

(57)【要約】【課題】ディレクトリの名称として固有かつシステム
からみて適切な名称を設定でき、かつユーザーにわかり
やすい名称を提示できるようにする。【解決手段】或るアプリケーションソフトウエアから
発生される１又は複数のファイルを、１つのディレクト
リの下のファイルとして記録媒体に記録すると共に、ア
プリケーションソフトウエアに固有に付されているアプ
リケーションＩＤをディレクトリ名称として用い、さら
に、ディレクトリ名称とユーザ提示用名称の対応づけを
行うようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置で用
いるアプリケーションプログラムに関わる情報の記録の
際のディレクトリ設定方法、及び記録装置に関するもの
である。

【０００２】

【従来の技術】パーソナルコンピュータやＰＤＡ（Pers
onal Digital Assistants：携帯情報機器）などの情報
処理装置においては、ＨＤＤ（Hard Disc Drive）、光
ディスク、光磁気ディスク、磁気ディスク、メモリカー
ドなどの各種の記録媒体に対するファイル等の記録につ
いて、ディレクトリによるツリー構造をとることができ
る。

【０００３】

【発明が解決しようとする課題】ところで、ディレクト
リの名称は、他のディレクトリと重複しない固有の名称
が要求され、その一方で、例えばユーザーがディレクト
リの内容を識別しやすい名称とされることが求められ
る。さらにシステムからみても内容を判別しやすい名称
であることも求められる。例えば情報処理システムにお
いて、新たなディレクトリの生成に対して、固有の名称
を付すことは、その時点で存在する他のディレクトリの
名称と比較確認していくことで容易に実現できる。しか
しながら、そのように生成された名称は、必ずしもユー
ザーにとってわかりやすいものではない。一方、ディレ
クトリ名称をユーザーが設定するようにすれば、ユーザ
ーにとってはわかりやすいものとなる。しかしながら、
名称が重複する可能性はあり、重複した場合は名称変更
を余儀なくされる。また、ユーザーに名称入力操作とい
う操作負担を強いることになる。

【０００４】

【課題を解決するための手段】本発明はこのような問題
点に鑑みて、ディレクトリの名称を、固有かつシステム
からみてわかりやすい名称を設定できるようにするとと
もに、ユーザーにわかりやすい名称を提示できるように
することを目的とする。

【０００５】このために、本発明のディレクトリ設定方
法は、ユニーク（固有）なアプリケーションを有する或
るアプリケーションソフトウエアを構成する当該ユニー
クなアプリケーションＩＤを有する１又は複数のファイ
ルを、１つのディレクトリの下のファイルとして記録媒
体に記録すると共に、上記アプリケーションソフトウエ
ア及びそれを構成するファイル群に固有に付されている
アプリケーションＩＤを上記ディレクトリ名称として用
い、さらに、上記ディレクトリ名称とユーザ提示用名称
の対応づけを行うようにする。対応づけの手法として
は、ディレクトリ名称とユーザ提示用名称を対応させる
対応テーブルファイルを記録することや、ユーザ提示用
名称を示した名称ファイルをディレクトリにリンクさせ
ること、或いはユーザ提示用名称を示したタグファイル
をディレクトリ下に記録すること、さらにはディレクト
リ下の特定のファイルに、ユーザ提示用名称を記録する
こと、などで実現する。

【０００６】本発明の記録装置は、或るアプリケーショ
ンソフトウエアを構成する１又は複数のファイルを格納
するディレクトリを、上記アプリケーションソフトウエ
ア及び構成ファイルに固有に付されているアプリケーシ
ョンＩＤをディレクトリ名称として用いて発生させるデ
ィレクトリ発生手段と、上記ディレクトリ名称とユーザ
提示用名称の対応づけを行う情報を生成する対応情報生
成手段と、記録媒体に対して、上記１又は複数のファイ
ルを上記ディレクトリの下に記録すると共に上記対応情
報を記録する記録手段と、を備えるようにする。

【０００７】

【発明の実施の形態】以下、本発明の実施の形態を次の
順序で説明する。なお、実施の形態としては、本発明の
ディレクトリ設定方法を実行し、また本発明の記録装置
に相当する、情報処理装置とする。記録媒体としてはメ
モリカードの例を挙げる。１．情報処理装置の外観例２．情報処理装置の構成３．ＯＳ構造及びデータベース構造４．メモリカード４−１外観４−２メモリカードの端子及び内部構造４−３ファイルシステム処理階層４−４物理的データ構造４−５物理アドレス及び論理アドレスの概念４−６論理−物理アドレス変換テーブル４−７ディレクトリ構造５．ＦＡＴ構造６．メモリカードと情報処理装置のインターフェース７．メモリカードへのファイル記録時の処理８．形成されるディレクトリ構造例１９．形成されるディレクトリ構造例２１０．形成されるディレクトリ構造例３１１．形成されるディレクトリ構造例４

【０００８】１．情報処理装置の外観例本例の情報処理装置の外観例を図１に示す。この情報処
理装置１は、いわゆるＰＤＡ機器として携帯に適した小
型軽量の装置とされる。また記録媒体として、後述する
メモリカード７０を装着し、記録再生を行うことができ
るものとする。なお本発明としては、携帯型の情報処理
装置に限られず、パーソナルコンピュータをはじめとす
るあらゆるタイプの情報処理装置に適用できるものであ
り、また装置が記録を行う記録媒体はメモリカードに限
られず、ＨＤＤ、光ディスク、光磁気ディスク、或いは
装置内に固定的に配置されるＲＡＭ、フラッシュメモリ
など、他の種の記録媒体であってもよいものである。

【０００９】図１（ａ）（ｂ）（ｃ）（ｄ）は情報処理
装置１の外観例としての平面図、右側面図、左側面図、
上面図を示している。図１（ｄ）に示すように装置上面
側には後述するメモリカード７０を装着可能なメモリス
ロット７が形成されており、この情報処理装置１は、メ
モリスロット７に装着されたメモリカード７０に対する
各種データ（コンピュータ用データ、音楽データ、音声
データ、動画像データ、静止画像データ、制御データな
ど）の記録再生が可能とされる。なお、この図１の例で
はメモリスロット７が２つ形成されていることから、２
つのメモリカード７０を同時に装着できるようになされ
ている。もちろん、形成するメモリスロット７の数は１
つでもよいし、３つ以上でもよい。

【００１０】この情報処理装置１には、平面上に例えば
液晶パネルによる表示部２が形成され、アプリケーショ
ンソフトウエアの起動及び各種処理に伴う画像、データ
としての画像や文字、再生される音声、音楽に付随する
情報、さらには操作のガイドメッセージ、再生や編集操
作等のためのメニュー画面などが表示される。

【００１１】情報処理装置１上には、ユーザーの操作の
ための各種の操作子が設けられる。例えば操作キー３
ａ、ジョグダイヤル３ｂ、プッシュダイヤル３ｃなどが
それぞれ所要部位に形成される。これらの操作子により
ユーザーは、例えば電源操作、メニュー操作、選択操
作、文字等の入力操作、その他必要とされる各種の操作
を行うことができる。これらの操作子はもちろん一例に
すぎない。即ち配備する操作子の数、種類、位置は多様
に考えられる。

【００１２】また、情報処理装置１上には、スピーカ
４，マイクロホン５，撮像部６も形成され、音声の出
力、入力、撮像による画像の取込なども実行できるよう
にされている。

【００１３】また各種機器との接続のために、各種端子
が形成される。例えば図１（ｂ）のように、ヘッドホン
端子１０、ライン出力端子１２、ライン入力端子１１な
どが形成され、また図１（ｃ）のようにＩＥＥＥ１３９
４端子８、ＵＳＢ(universalserial bus)端子９などが
形成される。なお、これらの端子の種類、数、配置位置
も、他の例が多様に考えられる。例えば光ケーブル対応
のデジタル入出力端子を備えるようにしたり、或いはＳ
ＣＳＩコネクタ、シリアルポート、ＲＳ２３２Ｃコネク
タなどが形成されるようにしても良い。

【００１４】２．情報処理装置の構成図２に情報処理装置１の内部構成を示す。図示するよう
に情報処理装置１内には、まず中核となる部位として、
システムコントローラ２１、ＣＰＵ２２、フラッシュＲ
ＯＭ２３、Ｄ−ＲＡＭ２４が設けられる。また基本的な
ユーザーインターフェースのための部位として操作部３
５，表示制御部２７，表示部２が形成される。

【００１５】システムコントローラ２１は操作部３５か
らの操作情報を入力し、それに応じてＣＰＵ２２に割り
込みをかける。操作部３５とは、図１に示した各種操作
子３ａ、３ｂ、３ｃに相当する。また図１では説明しな
かったが、表示部２に操作キーやアイコンの表示を行う
とともに表示部２上でのタッチ検出機構を設けること
で、タッチパネル操作子を形成してもよく、その場合の
タッチパネル操作子も図２でいう操作部３５に含まれる
ものとなる。

【００１６】ＣＰＵ２２は基本ソフト（ＯＳ：Operatin
g System）やアプリケーションプログラムが動作される
部位となる。ＣＰＵ２２はシステムコントローラ２１を
介して供給される操作情報に応じて所要の処理を実行す
る。フラッシュＲＯＭ２３は、基本動作プログラム、各
種処理定数、設定情報などを記憶する領域とされる。Ｄ
−ＲＡＭ２４は、各種処理に必要な情報の記憶、データ
のバッファリング、ＣＰＵ２２のワークエリアの拡張、
その他、ＣＰＵ２２の処理に応じて多様に使用される。
またＤ−ＲＡＭ２４にはストレージエリア（不揮発性領
域）が設けられており、そのストレージエリアにはＯＳ
やアプリケーションソフトウエアがインストールされ
る。そしてＤ−ＲＡＭ２４にインストールされたアプリ
ケーションソフトウエアは、ユーザからの操作に応じて
起動され、ＣＰＵ２２により実行される。またアプリケ
ーションソフトウエアはユーザーインターフェース画面
を持ち、ユーザーの指示による状態遷移に基づいて、Ｄ
−ＲＡＭ２４に確保されたフレームバッファに描画を行
う。描画された画像データは、表示制御部２７に送ら
れ、表示部２に表示される。

【００１７】また上述したようにメモリカード７０に対
するメモリスロット７が形成され、メモリカード７０を
装着できるが、ＣＰＵ２２は、メモリカードインターフ
ェース２８を介して装着されたメモリカード７０に対し
て書込又は読み出しアクセスすることができる。メモリ
カードインターフェース２８とメモリカード７０との間
のインターフェース動作については後述する。ＣＰＵ２
２は、装着されたメモリカード７０を、拡張的なメモリ
領域として利用することができる。また、もちろんメモ
リカード７０にアプリケーションプログラムが記録され
ていれば、それをＤ−ＲＡＭ２４にインストールした
り、或いはアプリケーションやデータを直接Ｄ−ＲＡＭ
２４に展開して所要処理を実行させることができる。ま
た、或るアプリケーションに基づいてＣＰＵ２２が、作
成した文書データ、画像データ、オーディオデータ、表
計算データなどを、メモリカード７０に記録することも
できる。なお、メモリスロット７にメモリカード７０が
装着されたことを検出することで、メモリカード７０に
対する動作が記録再生動作可能になったり、或いはメモ
リカード７０に記録されているアプリケーションやデー
タが自動的にＤ−ＲＡＭ２４に展開されるなどの、いわ
ゆるホットプラグイン動作も可能である。またメモリカ
ードインターフェース２８は、メモリカード７０に記録
するデータについての暗号化処理や、読み出したデータ
の暗号解読処理なども可能とされる。

【００１８】撮像部６は例えばＣＣＤ撮像素子及び撮像
回路系によりに形成される。撮像部６により取り込まれ
た撮像画像データは、撮像データインターフェース３４
を介してＤ−ＲＡＭ２４に取り込むことができ、またＣ
ＰＵ２２は所定のアプリケーションプログラムに基づく
動作により、撮像画像データの編集やメモリカード７０
への記録等を実行できる。

【００１９】オーディオインターフェース２９は、上述
したスピーカ４、マイクロホン５、ヘッドホン端子１
０、ライン出力端子１２，ライン入力端子１１から入出
力されるオーディオデータのインターフェース部位とな
る。例えばマイクロホン５或いはライン入力端子１１か
ら入力されたアナログオーディオ信号は、入力オーディ
オ処理部３２でそれぞれ所定の増幅処理やフィルタリン
グが行われ、Ａ／Ｄ変換器３３でデジタルオーディオデ
ータとされてオーディオインターフェース２９に供給さ
れる。オーディオインターフェース２９は、入力された
デジタルオーディオデータについて、ＣＰＵ２２の制御
に基づいて処理や出力を実行する。例えば所要の圧縮エ
ンコード処理を行った後、メモリカードインターフェー
ス２８に供給し、メモリカード７０に記録させることが
できる。またオーディオインターフェース２９は、例え
ばメモリカード７０から読み出されるなどして供給され
たデジタルオーディオデータについて所定のデコード処
理を行い、Ｄ／Ａ変換器３０に供給する。Ｄ／Ａ変換器
３０はデジタルオーディオデータをアナログオーディオ
信号に変換する。出力オーディオ処理部３１は供給され
たアナログオーディオ信号について、出力先に応じた所
定の増幅処理、インピーダンス調整などを行い、スピー
カ４，ヘッドホン端子１０、ライン出力端子１２に出力
する。

【００２０】ＵＳＢインターフェース２５は、ＵＳＢコ
ネクタ９に接続された外部機器との間の通信インターフ
ェースである。ＣＰＵ２２はＵＳＢインターフェース２
５を介して外部のパーソナルコンピュータ或いは周辺機
器などとの間でデータ通信を行うことができる。例えば
この情報処理装置１で扱われる制御データ、コンピュー
タデータ、画像データ、オーディオデータなどの送受信
が実行される。同様にＩＥＥＥ１３９４インターフェー
ス２６は、ＩＥＥＥ１３９４端子８に接続された外部機
器との間の通信インターフェースである。ＣＰＵ２２は
ＩＥＥＥ１３９４インターフェース２６を介して外部の
情報機器との間で各種データ通信を行うことができる。

【００２１】なお、この図２に示す情報処理装置１の構
成はあくまでも一例であり、これに限定されるものでは
ない。即ち、一般にパーソナルコンピュータやＰＤＡ機
器で採用されている各種構成部位を追加したり、或いは
実際の製品として不要の部位を削除することは、設計上
の都合により決められるものである。

【００２２】３．ＯＳ構造及びデータベース構造続いて図３で、本例の情報処理装置１に搭載されるＯＳ
構造について説明する。図３に示すように、ＯＳは、基
本ソフトの中心部分としてのカーネルを含むマネージャ
層と、標準ライブラリ、及び制御ＩＣなどのハードウエ
アのレイヤとなるＨＡＬ（Hardware Abstraction Laye
r）から構成される。アプリケーションソフトウエア
は、このようなＯＳ構造による基本動作上で動作され
る。またＨＡＬに対しては、１又は複数のデバイスドラ
イバとして階層が付加され実際のハードウエア（ＨＷ）
が駆動される。

【００２３】ここで、特に本例の情報処理装置１の場合
は、メモリカード７０をドライブ可能とし、かつ後述す
るがメモリカード７０のデータはＦＡＴにより管理され
ることから、ＯＳにＦＡＴライブラリが付加され、さら
に、メモリカードをハンドリングするためのライブラリ
（ＭＳライブラリ）が付加される。そしてこのＦＡＴラ
イブラリ及びＭＳライブラリに基づいて、メモリドライ
ブがメモリカード７０がドライブされる構造とされてい
る。

【００２４】このようなＯＳ構造を持つ本例の情報処理
装置１では、さらに通常でいうところの「ファイル」に
相当する概念として、「データベース」という概念が導
入されている。ここでいう「データベース」とは、通常
いうところのデータベースのように単にデータを蓄積し
ていったものではなく、データベース自体がデータを管
理できる構造としてフォーマット化されている。この意
味で、「データベース」は「ファイル」に相当する。

【００２５】図４にデータベース構造を示す。即ちデー
タベースには、ヘッダ（ＤＴＢヘッダ）としてデータベ
ースネーム（ＤＴＢＮａｍｅ）及びその他情報を含む
領域が形成され、さらにポインタテーブルが配される。
そしてデータ領域に記録される実際のデータは、ポイン
タテーブルに記録されたポイント情報により、位置的な
管理が行われる状態となっている。

【００２６】このような構造のデータベースとしては、
２種類のものが存在する。例えば一般に１つのアプリケ
ーションソフトウエアは複数のファイルで構成され、そ
の中には実行ファイル（＊＊＊．ｅｘｅ）と、データフ
ァイル（＊＊＊．ｄａｔａ）があるが、その実行ファイ
ル（＊＊＊．ｅｘｅ）に相当するものとして「リソース
データベース（＊＊＊．ｐｒｃ）」があり、またデータ
ファイル（＊＊＊．ｄａｔａ）に相当するものとして
「データベースデータベース（＊＊＊．ｄｔｂ）」があ
る。

【００２７】本例の情報処理装置１では、このような
「データベース」という概念によりデータを扱う。従っ
て、メモリカード７０において記録再生されるファイル
（ＦＡＴで扱われるファイル）も、上記データベースの
形態となる。なお本明細書では、「ファイル」という言
葉を用いるが、これは一般的な概念にあわせて用いてい
るものであり、本実施の形態に関していえば、「ファイ
ル」とは上記構造のデータベースの意味となる。

【００２８】４．メモリカード４−１外観次にメモリカード７０について説明していく。まず図５
にメモリカード７０の外形形状を示す。メモリカード７
０は、例えば図５に示すような板状の筐体内部に例えば
所定容量ののメモリ素子を備える。本例としては、この
メモリ素子としてフラッシュメモリ（Flash Memory）が
用いられるものである。図５に平面図、正面図、側面
図、底面図として示す筐体は例えばプラスチックモール
ドにより形成され、サイズの具体例としては、図に示す
幅Ｗ１１、Ｗ１２、Ｗ１３のそれぞれが、Ｗ１１＝６０
ｍｍ、Ｗ１２＝２０ｍｍ、Ｗ１３＝２．８ｍｍとなる。

【００２９】筐体の正面下部から底面側にかけて例えば
１０個の電極を持つ端子部７２が形成されており、この
端子部７２から、内部のメモリ素子に対する読出又は書
込動作が行われる。筐体の平面方向の左上部は切欠部７
３とされる。この切欠部７３は、このメモリカード７０
を、例えばドライブ装置本体側の着脱機構へ装填する際
などに挿入方向を誤ることを防止するためのものとな
る。また筐体上面から底面側にかけて、ラベル貼付面７
４が形成され、ユーザーが記憶内容を書いたラベルを貼
付できるようにされている。さらに底面側には、記録内
容の誤消去を防止する目的のスライドスイッチ７５が形
成されている。

【００３０】このようなメモリカード７０においては、
フラッシュメモリ容量としては、４ＭＢ（メガバイ
ト），８ＭＢ，１６ＭＢ，３２ＭＢ，６４ＭＢ，１２８
ＭＢの何れかであるものとして規定されている。またデ
ータ記録／再生のためのファイルシステムとして、いわ
ゆるＦＡＴ（File Allocation Table）システムが用い
られている。

【００３１】書込速度は１５００ＫＢｙｔｅ／ｓｅｃ〜
３３０ＫＢｙｔｅ／ｓｅｃ、読出速度は２．４５ＭＢｙ
ｔｅ／ｓｅｃとされ、書込単位は５１２バイト、消去ブ
ロックサイズは８ＫＢ又は１６ＫＢとされる。また電源
電圧Ｖｃｃは２．７〜３．６Ｖ、シリアルクロックＳＣ
ＬＫは最高２０ＭＨｚとされる。

【００３２】４−２メモリカードの端子及び内部構造図６に端子部７２の電極構造を示す。図５に示したよう
に端子部７２は１０個の平面電極が１列に並んだ構造と
されるが、図６に示すように各電極（端子Ｔ１〜Ｔ１
０）は次の通りとなる。

【００３３】端子Ｔ１及びＴ１０は検出電圧Ｖｓｓ端子
とされる。端子Ｔ２は、シリアルプロトコルバスステー
ト信号ＢＳの入力端子とされる。端子Ｔ３及びＴ９は電
源電圧Ｖｃｃ端子とされる。端子Ｔ４はデータ端子、つ
まりシリアルプロトコルデータ信号の入出力端子とされ
る。端子Ｔ５及びＴ７はリザーブ（予備）とされる。端
子Ｔ６は検出端子とされ、ドライブ装置側（情報処理装
置１のメモリカードインターフェース）がメモリカード
の装着検出に用いる。端子Ｔ８は、シリアルクロックＳ
ＣＬＫの入力端子とされる。

【００３４】また図６にはメモリカード７０の内部構成
も示している。メモリカード７０の内部は、コントロー
ルＩＣ８０とフラッシュメモリ８１が設けられている。
コントロールＩＣ８０はフラッシュメモリ８１に対する
書込／読出動作を実行する部位となる。図からわかるよ
うに、コントロールＩＣ８０に対しては、端子Ｔ２から
のシリアルプロトコルバスステート信号ＢＳ、端子Ｔ８
からのシリアルクロックＳＣＬＫが供給される。書込動
作時には、コントロールＩＣ８０は、これらのシリアル
プロトコルバスステート信号ＢＳ、シリアルクロックＳ
ＣＬＫに従って、端子Ｔ４から供給されるデータのフラ
ッシュメモリ８１への書込を行う。また読出時には、シ
リアルプロトコルバスステート信号ＢＳ、シリアルクロ
ックＳＣＬＫに従って、フラッシュメモリ８１からデー
タを読み出し、端子Ｔ４からドライブ装置側に出力す
る。

【００３５】また検出電圧Ｖｓｓは、検出端子Ｔ６に供
給されており、ドライブ装置側では、図示するように抵
抗Ｒによって検出端子Ｔ６の端子電圧を検出すること
で、このメモリカード７０が装着部（メモリスロット
７）に接続されているか否かを検出できるようにされ
る。

【００３６】４−３ファイルシステム処理階層続いて、メモリカード７０を記録媒体とするシステムに
おけるフォーマットについて説明していく。図７は、メ
モリカード７０を記録媒体とするシステムのファイルシ
ステム処理階層を示すものである。この図に示すよう
に、ファイルシステム処理階層としては、アプリケーシ
ョン処理層の下に、順次、ファイル管理処理層、論理ア
ドレス層、物理アドレス層、フラッシュメモリアクセス
がおかれる。この階層では、ファイル管理処理層がいわ
ゆるＦＡＴ（File Allocation Table）となる。また、
この図から分かるように、本例のファイルシステムでは
論理アドレス及び物理アドレスという概念が導入されて
いるが、これについては後述する。

【００３７】４−４物理的データ構造図８には、メモリカード７０内の記憶素子である、フラ
ッシュメモリ８１の物理的データ構造が示されている。
フラッシュメモリ８１としての記憶領域は、セグメント
という固定長のデータ単位が大元となる。このセグメン
トは、１セグメントあたり４ＭＢ（メガバイト）或いは
８ＭＢとして規定されるサイズであり、１つのフラッシ
ュメモリ８１内におけるセグメント数は、そのフラッシ
ュメモリ８１の容量に依存して異なってくる。

【００３８】そして、この１セグメントを図８（ａ）に
示すように、ブロックという固定長のデータ単位として
８ＫＢ（キロバイト）又は１６ＫＢにより区切るように
される。原則として、１セグメントは５１２ブロックに
区切られることから、図８（ａ）に示すブロックｎにつ
いては、ｎ＝５１１とされることになる。但し、フラッ
シュメモリ８１では、書き込み不可な損傷エリアである
ディフェクトエリアとしてのブロック数が所定数の範囲
で許可されているため、データ書き込みが有効とされる
実質的なブロック数を対象とすれば、上記ｎは５１１よ
りも少なくなる。

【００３９】図８（ａ）に示すようにして形成されるブ
ロック０〜ｎのうち、先頭の２つのブロック０，１はブ
ートブロックといわれる。但し、実際には有効なブロッ
クの先頭から２つのブロックがブートブロックとして規
定されることになっており、必ずしもブートブロックが
ブロック０，１である保証はない。そして、残りのブロ
ックが、ユーザデータが格納されるユーザブロックとな
る。

【００４０】１ブロックは、図８（ｄ）に示すようにし
て、ページ０〜ｍにより分割される。１ページの容量
は、図８（ｅ）に示すように、５１２バイトのデータエ
リアと１６バイトの冗長部よりなる、５２８（＝５１２
＋１６）バイトの固定長とされる。なお、冗長部の構造
については図８（ｆ）により後述する。また、１ブロッ
ク内のページ数としては、１ブロックの容量が８ＫＢの
場合には１６ページ、１６ＫＢの場合には３２ページと
なる。

【００４１】このような、図８（ｄ）（ｅ）に示される
ブロック内のページ構造は、上記ブートブロックとユー
ザブロックとで共通である。また、フラッシュメモリ８
１では、データの読み出し、及び書き込みはページ単位
で行われ、データの消去はブロック単位で行われるもの
とされる。そして、データの書き込みは、消去済みのペ
ージに対してしか行われないものとされている。従っ
て、実際のデータの書き換えや書き込みは、ブロック単
位を対象として行われることになる。

【００４２】先頭のブートブロックは、図８（ｂ）に示
すように、ページ０に対してヘッダーが格納され、ペー
ジ１には初期不良データの位置（アドレス）を示す情報
が格納される。また、ページ２にはＣＩＳ／ＩＤＩとい
われる情報が格納される。２つめのブートブロックは図
８（ｃ）に示すように、ブートブロックとしてのバック
アップのための領域とされている。

【００４３】図８（ｅ）に示された冗長部（１６バイ
ト）は、図８（ｆ）に示す構造を有する。この冗長部
は、図のように先頭の第０バイト〜第２バイトの３バイ
トが、データエリアのデータ内容の更新に応じて書き換
えが可能なオーバーライトエリアとされる。このオーバ
ーライトエリアのうち、第０バイトにはブロックステー
タスが格納され、第１バイトにはデータステータスが格
納される(Block Flag Data)。また、第２バイトの上位
の所定ビットを利用して変換テーブルフラグ(Page Data
Status1)が格納される。

【００４４】原則として第３バイト〜第１５バイトは、
その内容が現ページのデータ内容に応じて固定とされ、
書き換えが不可とされる情報が格納される領域となる。
第３バイトにはアクセス許可やコピー禁止指定等を示す
管理フラグ(Block Info)が格納される。第４，第５バイ
トから成る２バイトの領域には、後述する論理アドレス
(LogicAddress)が格納される。第６〜第１０バイトの５
バイトの領域は、フォーマットリザーブの領域とされ、
続く第１１，第１２バイトの２バイトが、上記フォーマ
ットリザーブに対して誤り訂正を施すための分散情報Ｅ
ＣＣを格納する領域とされる。残る第１３〜第１５バイ
トには、図８（ｅ）に示すデータエリアのデータに対し
て誤り訂正を行うためのデータＥＣＣが格納される。

【００４５】上記図８（ｆ）に示した冗長部の第３バイ
トに格納される管理フラグは、図９に示すようにして、
ビット７〜ビット０の各ビットに、その内容が定義され
ている。ビット７，６、及びビット１，０はリザーブ
（未定義）領域とされている。ビット５は現ブロックに
対してのアクセス許可の「有効」（‘１’；Free）／
「無効」(‘０’；Read Protected）を示すフラグが格
納される。ビット４には現ブロックについてのコピー禁
止指定（‘１’；ＯＫ／‘０’；ＮＧ）についてのフ
ラグが格納される。

【００４６】ビット３は変換テーブルフラグとされる。
この変換テーブルフラグは、現ブロックが後述する論理
−物理アドレス変換テーブルであるのか否かを示す識別
子であり、このビット３の値が‘０’とされていれば、
現ブロックは論理−物理アドレス変換テーブルであるこ
とが識別され、‘０’であれば無効となる。つまり、現
ブロックは論理−物理アドレス変換テーブルではないこ
とが識別される。

【００４７】ビット２はシステムフラグが格納され、
‘１’であれば現ブロックがユーザブロックであること
が示され、‘０’であればブートブロックであることが
示される。

【００４８】ここで、セグメント及びブロックと、フラ
ッシュメモリ容量との関係を図１３（左３列を参照）に
より説明しておく。メモリカード７０のフラッシュメモ
リ容量としては、４ＭＢ，８ＭＢ，１６ＭＢ，３２Ｍ
Ｂ，６４ＭＢ，１２８ＭＢの何れかであるものとして規
定されている。そして、最も容量の小さい４ＭＢの場合
であると、１ブロックは８ＫＢと規定された上で、その
ブロック数としては５１２個とされる。つまり、４ＭＢ
はちょうど１セグメントの容量を有するものとされる。
そして、４ＭＢの容量であれば、同様に１ブロック＝８
ＫＢの容量が規定された上で、２セグメント＝１０２４
ブロックとなる。なお、前述したように、１ブロック＝
８ＫＢであれば、１ブロック内のページ数は１６ページ
となる。但し１６ＭＢの容量では、１ブロックあたりの
容量として８ＫＢと１６ＫＢの両者が存在することが許
可されている。このため、２０４８ブロック＝４セグメ
ント（１ブロック＝８ＫＢ）のものと、１０２４ブロッ
ク＝２セグメント（１ブロック＝１６ＫＢ）のものとの
２種類が在ることになる。１ブロック＝１６ＫＢの場合
には、１ブロック内のページ数は３２ページとなる。

【００４９】また、３２ＭＢ，６４ＭＢ，１２８ＭＢの
容量では、１ブロックあたりの容量は１６ＫＢのみであ
るとして規定される。従って、３２ＭＢでは２０４８ブ
ロック＝４セグメントとなり、６４ＭＢでは４０９６ブ
ロック＝８セグメントとなり、１２８ＭＢでは８１９２
ブロック＝１６セグメントとなる。

【００５０】４−５物理アドレス及び論理アドレスの
概念次に、上述したようなフラッシュメモリの物理的データ
構造を踏まえたうえで、図１０に示すデータ書き換え動
作に従って、本例のファイルシステムにおける物理アド
レスと論理アドレスの概念について説明する。

【００５１】図１０（ａ）には、或るセグメント内から
４つのブロックを抜き出して、これを模式的に示してい
る。各ブロックに対しては物理アドレスが付される。こ
の物理アドレスはメモリにおけるブロックの物理的な配
列順に従って決まるもので、或るブロックとこれに対応
付けされた物理アドレスとの関係は不変となる。ここで
は、図１０（ａ）に示す４ブロックに対して、上から順
に物理アドレスの値として、１０５，１０６，１０７，
１０８が付されている。なお、実際の物理アドレスは２
バイトにより表現される。

【００５２】ここで、図１０（ａ）に示すように、物理
アドレス１０５，１０６で示されるブロックがデータの
記憶されている使用ブロックで、物理アドレス１０７，
１０８で示されるブロックがデータが消去（即ち、未記
録領域）された未使用ブロックとなっている状態である
とする。

【００５３】そして、論理アドレスであるが、この論理
アドレスは、ブロックに対して書き込まれたデータに付
随するようにして割り振られるアドレスとされる。そし
て、この論理アドレスが、後述するＦＡＴファイルシス
テムが利用するアドレスとされている。図１０（ａ）で
は、４つの各ブロックに対して、上から順に論理アドレ
スの値として、１０２，１０３，１０４，１０５が付さ
れている状態が示されている。なお、論理アドレスも実
際には２バイトにより表現されるものである。

【００５４】ここで、上記図１０（ａ）に示す状態か
ら、例えば物理アドレス１０５に格納されているデータ
の更新として、内容の書き換え又は一部消去を行うとす
る。このような場合、フラッシュメモリのファイルシス
テムでは、同じブロックに対して更新したデータを再度
書き込むことはせずに、未使用のブロックに対してその
更新したデータを書き込むようにされる。つまり、例え
ば図１０（ｂ）に示すようにして、物理アドレス１０５
のデータは消去したうえで、更新されたデータはこれま
で未使用ブロックであった物理アドレス１０７で示され
るブロックに書き込むようにされる（処理）。

【００５５】そして、処理として示すように、データ
更新前（図１０（ａ））の状態では物理アドレス１０５
に対応していた論理アドレス１０２が、更新されたデー
タが書き込まれたブロックの物理アドレス１０７に対応
するように、論理アドレスについての変更を行うもので
ある。これに伴って、データ更新前は物理アドレス１０
７に対応していた論理アドレス１０４については、物理
アドレス１０５に対応するように変更されている。

【００５６】つまり、物理アドレスはブロックに対して
固有に付されるアドレスであり、論理アドレスは、一旦
ブロックに対して書き込まれたデータに付随するように
してついて回る、ブロック単位の書き込みデータに固有
となるアドレスであるとみることができる。

【００５７】このようなブロックのスワップ処理が行わ
れることで、或る同一の記憶領域（ブロック）に対して
繰り返し集中的にアクセスされることが無くなり、書き
換え回数の上限があるフラッシュメモリの寿命を延ばす
ことが可能となる。そして、この際に論理アドレスを上
記処理のようにして扱うことで、ブロックのスワップ
処理によって更新前と更新後のデータとで書き込まれる
ブロックの移動があるようにされても、ＦＡＴからは同
一のアドレスが見えることになり、以降のアクセスを適
正に実行することができるものである。なお、後述する
論理−物理アドレス変換テーブル上での更新のための管
理を簡略にすることなどを目的として、ブロックのスワ
ップ処理は、１セグメント内で完結するものとして規定
されている。逆に言えば、ブロックのスワップ処理はセ
グメント間で跨るようにしては行われない。

【００５８】４−６論理−物理アドレス変換テーブル上記図１０による説明から分かるように、ブロックのス
ワップ処理が行われることで、物理アドレスと論理アド
レスの対応は変化する。従って、フラッシュメモリに対
するデータの書き込み及び読み出しのためのアクセスを
実現するには、物理アドレスと論理アドレスとの対応が
示される論理−物理アドレス変換テーブルが必要とな
る。つまり、論理−物理アドレス変換テーブルをＦＡＴ
が参照することで、ＦＡＴが指定した論理アドレスに対
応する物理アドレスが特定され、この特定された物理ア
ドレスにより示されるブロックにアクセスすることが可
能になるものである。逆に言えば、論理−物理アドレス
変換テーブルが無ければ、ＦＡＴによるフラッシュメモ
リへのアクセスが不可能となる。

【００５９】従来では、例えばセット本体に対してメモ
リカード７０が装着されたときに、セット本体側のマイ
クロプロセッサがメモリカード７０の記憶内容をチェッ
クすることで、セット本体側で論理−物理アドレス変換
テーブルの構築を行い、更にこの構築された論理−物理
アドレス変換テーブルをセット本体側のＲＡＭに格納す
るようにしていた。つまり、メモリカード７０内には、
論理−物理アドレス変換テーブルの情報は格納されては
いなかった。これに対して本例では、以降説明するよう
にメモリカード７０に対して、論理−物理アドレス変換
テーブルを格納するように構成している。

【００６０】図１１は、本例のメモリカード７０に対し
て格納される論理−物理アドレス変換テーブルの構築形
態を概念的に示すものである。つまり、本例では、例え
ば論理アドレスの昇順に従って、これに対応する２バイ
トの物理アドレスを格納するようにしたテーブル情報を
論理−物理アドレス変換テーブルとして構築するように
される。なお、前述したように、物理アドレス、及び論
理アドレスは共に２バイトで表現される。これは、１２
８ＭＢの最大容量のフラッシュメモリの場合には８１９
２個のブロックが存在するため、最大で、この８１９２
個のブロック数をカバーできるだけのビット数が必要と
されることに基づく。このため、図１１において例示し
ている物理アドレスと論理アドレスとについても、実際
に即して２バイトで表現している。但し、ここでは、こ
の２バイトを１６進数により表記している。つまり、
「０ｘ」によりその後続く値が１６進法表記であること
が示される。なお、この「０ｘ」により１６進数である
ことを表す表記は、以降の説明において１６進数を表記
する場合にも同様に用いることとする。（但し、表記の
煩雑化を防ぐため「０ｘ」を省略している図面もあ
る。）

【００６１】図１２に、上記図１１に示した概念に基づ
く論理−物理アドレス変換テーブルの構造例を示す。論
理−物理アドレス変換テーブルは、フラッシュメモリの
最後のセグメント内の或るブロックに対して、図１２に
示すようにして格納される。先ず図１２（ａ）に示すよ
うに、ブロックを分割するページのうち、ページ０，１
からなる２ページの領域がセグメント０用の論理−物理
アドレス変換テーブルとして割り当てられる。例えば、
図１３にて説明したように、フラッシュメモリが４ＭＢ
の容量であれば１セグメントしか有さないために、この
ページ０，１のみの領域が論理−物理アドレス変換テー
ブルの領域となる。また、例えばフラッシュメモリが８
ＭＢの容量であれば２セグメントを有するため、セグメ
ント０用の論理−物理アドレス変換テーブルとして割り
当てられるページ０，１に加え、これに続くページ２，
３の２ページがセグメント１用の論理−物理アドレス変
換テーブルとして割り当てられることになる。

【００６２】以降、フラッシュメモリの容量の増加に応
じて、続く２ページごとにセグメントごとの論理−物理
アドレス変換テーブルの割り当て領域が設定されていく
ことになる。そして、最大の１２８ＭＢの容量を有する
場合であれば１６セグメントが存在するため、最大で
は、セグメント１５用までのページが論理−物理アドレ
ス変換テーブルの領域として割り当てられることにな
る。従って、最大の１２８ＭＢの容量のフラッシュメモ
リでは、３０ページが使用されることになり、図１２
（ａ）に示すページＮとしては、最大でＮ＝２９とな
る。これまでの説明から分かるように、論理−物理アド
レス変換テーブルは、セグメントごとに管理されるもの
である。

【００６３】図１２（ｂ）は、１セグメントあたりの論
理−物理アドレス変換テーブルの構造を示すものとし
て、２ページ分のデータエリアを抜き出して示してい
る。つまり、１ページのデータエリアは５１２バイト
（図８（ｅ）参照）であることから、図１２（ｂ）に
は、１０２４（＝５１２×２）バイトが展開されている
状態が示されている。

【００６４】図１２（ｂ）に示すように、この２ページ
分のデータエリアである１０２４バイトについて２バイ
トごとに区切り、この２バイトごとの領域を、先頭から
順次、論理アドレス０用、論理アドレス１用・・・・、
のようにして割付を行い、最後は先頭から９９１バイト
目と９９２バイト目の２バイトの領域を論理アドレス４
９５用の領域として割り付けるように規定を行う。これ
ら２バイトごとの領域に対して、各論理アドレスが対応
する物理アドレスを書き込むようにする。従って、本例
の論理−物理アドレス変換テーブルでは、実際のデータ
更新によるブロックのスワップ処理などにより物理アド
レスと論理アドレスの対応が変更された場合には、論理
アドレスを基準として、物理アドレスの格納状態が更新
されるようにしてテーブル情報の書き換えが行われるこ
とになる。

【００６５】また、残る９９３バイト目から最後の１０
２４バイト目までの計３２バイトの領域は、余剰ブロッ
クの物理アドレスが格納される領域として割り当てられ
る。つまり、１６個の余剰ブロックの物理アドレスを管
理することができる。ここでいう余剰ブロックとは、例
えばブロック単位でデータの更新を行う際に書き換え対
象となるデータを一時待避させる領域として設定された
いわゆるワークブロックなどを言うものである。

【００６６】ところで、１セグメントは５１２ブロック
に分割されているものであると先に説明したのにも関わ
らず、図１２に示したテーブル構造では、管理可能なブ
ロック数が論理アドレス０用〜論理アドレス４９５用の
４９６ブロックとしている。これは、実際上、上記した
余剰アドレスが設定されることと、前述したように、フ
ラッシュメモリでは、或ブロック数のディフェクト（使
用不可領域）が許可されている。そのため現実には、相
当数のディフェクトブロックが存在することに依る。従
って、実際には、書き込み／消去が有効なブロックを管
理するのに、４９６ブロックを管理できるように構成し
ておけば充分とされるものである。

【００６７】そして、このようにして論理−物理アドレ
ス変換テーブルが格納されるブロックについては、これ
を形成する各ページの冗長部における管理フラグ（図９
参照）のデータ内容として、この管理フラグのビット３
に対して‘０’がセットされることになる。これによ
り、当該ブロックが論理−物理アドレス変換テーブルが
格納されているブロックであることが示されることにな
る。

【００６８】論理−物理アドレス変換テーブルが格納さ
れるブロックも、論理−物理アドレス変換テーブルの内
容の書き換えがあった場合には、例外なく、先に図１０
にて説明したスワップ処理が行われる。従って、論理−
物理アドレス変換テーブルが記録されているブロックは
不定であり、或る特定のブロックに論理−物理アドレス
変換テーブルを格納するように規定することは出来な
い。そこで、ＦＡＴは、フラッシュメモリにアクセスし
て上記した管理フラグのビット３が‘０’とされている
ブロックを検索することで、論理−物理アドレス変換テ
ーブルが格納されているブロックを識別するようにされ
る。但し、論理−物理アドレス変換テーブルが格納され
ているブロックの検索がＦＡＴによって容易に行われる
ようにすることを考慮して、論理−物理アドレス変換テ
ーブルが格納されているブロックは、そのフラッシュメ
モリ内における最後のナンバが付されたセグメントに在
るように、本例では規定するものとされる。これによ
り、ＦＡＴは最後のナンバが付されたセグメントのブロ
ックのサーチだけで、論理−物理アドレス変換テーブル
を検索することができる。つまり、論理−物理アドレス
変換テーブルを検索するのに、フラッシュメモリの全て
のセグメントを検索する必要は無いようにされる。上記
図１２に示した論理−物理アドレス変換テーブルは、例
えばメモリカード７０の製造時において格納するように
される。

【００６９】ここで、再度図１３を参照して、フラッシ
ュメモリ容量と論理−物理アドレス変換テーブルのサイ
ズとの関係を説明しておく。上記図１１にて説明したよ
うに、１セグメントを管理するための論理−物理アドレ
ス変換テーブルのサイズは２ページ分の１０２４バイ
ト、つまり１ＫＢとなる。従って、図１３の最右列に記
されているように、フラッシュメモリが４ＭＢ（１セグ
メント）の容量では論理−物理アドレス変換テーブルは
１ＫＢのサイズとなる。また、フラッシュメモリの容量
が８ＭＢ（２セグメント）では論理−物理アドレス変換
テーブルは２ＫＢ（４ページ）となる。また、フラッシ
ュメモリの容量が１６ＭＢの場合、２０４８ブロック＝
４セグメントのものでは論理−物理アドレス変換テーブ
ルは４ＫＢ（８ページ）、１０２４ブロック＝２セグメ
ントのものでは論理−物理アドレス変換テーブルは２Ｋ
Ｂ（４ページ）となる。そして、フラッシュメモリの容
量が３２ＭＢ（４セグメント）では論理−物理アドレス
変換テーブルは４ＫＢ（８ページ）、フラッシュメモリ
の容量が６４ＭＢ（８セグメント）では論理−物理アド
レス変換テーブルは８ＫＢ（１６ページ）となり、フラ
ッシュメモリの容量が最大の１２８ＭＢ（１６セグメン
ト）では論理−物理アドレス変換テーブルは１６ＫＢ
（３２ページ）となる。

【００７０】４−７ディレクトリ構造メモリカード７０に記録されるディレクトリ構成例を図
１４に示す。メモリカード７０で扱うことのできる主デ
ータとしては、コンピュータ用データ、動画データ、静
止画データ、メッセージデータ、オーディオデータ、制
御用データなどがあるが、このためディレクトリ構造と
しては、ルートディレクトリから、「ＶＯＩＣＥ」（メ
ッセージ用ディレクトリ）、「ＤＣＩＭ」（静止画用デ
ィレクトリ）、「ＭＯｘｘｘｘｎｎ」（動画用ディレク
トリ）、「ＣＯＮＴＲＯＬ」（制御用ディレクトリ）、
「ＨＩＦＩ」（オーディオ用ディレクトリ）、「ＰＭ」
（情報処理装置用ディレクトリ）が配される。

【００７１】そして図示していないが、各ディレクトリ
の下には、サブディレクトリやファイル（上述したデー
タベース）、フォルダ等が配され、いわゆるツリー構造
の形態をとることになる。なお、もちろんこのようなデ
ィレクトリ構成は一例にすぎず、実際には情報処理装置
１等による記録状況や記録されるファイル種別などに応
じてディレクトリ構造が形成される。

【００７２】５．ＦＡＴ構造図７のファイルシステム階層で説明したように、ファイ
ル管理処理はＦＡＴにより行われることになる。即ち図
２に示した構成の情報処理装置１により、メモリカード
７０に対する記録再生（データ書込／読出）を実現する
には、アプリケーション処理での要求に伴ってＦＡＴに
よるファイル記憶位置管理が参照され、さらに上述した
論理−物理アドレス変換が行われて実際のアクセスが行
われることになる。ここで、ＦＡＴの構造について説明
しておく。

【００７３】図１５はＦＡＴによる管理構造の概要を示
している。なお、本例ではＦＡＴ及び論理−物理アドレ
ス変換テーブルはメモリカード７０内に格納されること
になるが、図１５に示すＦＡＴ構造が、メモリカード７
０内での管理構造となるものである。

【００７４】図示するようにＦＡＴ管理構造は、パーテ
ィションテーブル、空き領域、ブートセクタ、ＦＡＴ、
ＦＡＴのコピー、ルートディレクトリ、データ領域から
成る。データ領域には、クラスタ２、クラスタ３・・・
として単位データを示しているが、このクラスタとは、
管理単位となるＦＡＴで扱う１データ単位である。一般
にＦＡＴでは、クラスタサイズは標準で４Ｋバイトとさ
れるが、このクラスタサイズは５１２バイト〜３２Ｋバ
イトの間で２のべき乗の大きさをとることができる。本
例のメモリカード７０では、上述したように１つのブロ
ックが８Ｋバイト又は１６Ｋバイトとされるが、１ブロ
ック＝８Ｋバイトとされるメモリカード７０の場合は、
ＦＡＴで扱うクラスタは８Ｋバイトとされる。また１ブ
ロック＝１６Ｋバイトとされるメモリカード７０の場合
は、ＦＡＴで扱うクラスタは１６Ｋバイトとされる。即
ち、８Ｋバイト又は１６ＫバイトがＦＡＴ管理上でのデ
ータ単位であり、かつメモリカード７０でのブロックと
しての１つのデータ単位とされる。なお、従ってメモリ
カードからみれば、ＦＡＴで扱われるクラスタサイズ＝
そのメモリカードのブロックサイズとなる。このため、
本例の以降の説明については、簡略化のためにブロック
＝クラスタとして考えることとする。

【００７５】そして図１５左側にブロックナンバとして
ｘ・・・（ｘ＋ｍ−１）、（ｘ＋ｍ）（ｘ＋ｍ＋１）
（ｘ＋ｍ＋２）・・・と示したが、例えばこのように各
ブロックにおいてＦＡＴ構造を構築する各種データは記
憶されることになる。なお、実際には必ずしもこのよう
に物理的に連続する各ブロックに各情報が記憶されるも
のではない。

【００７６】ＦＡＴ構造において、まずパーティション
テーブルには、ＦＡＴパーティション（最大２Ｇバイ
ト）の先頭と終端のアドレスが記述されている。ブート
領域には、いわゆる１２ｂｉｔＦＡＴ、１６ｂｉｔＦＡ
Ｔの別や、ＦＡＴ構造（大きさ、クラスタサイズ、各領
域のサイズなど）が記述される。

【００７７】ＦＡＴは、後述するように各ファイルを構
成するクラスタのリンク構造を示すテーブルとなり、ま
たＦＡＴについては続く領域にコピーが記述される。ル
ートディレクトリには、ファイル名、先頭クラスタ番
号、各種属性が記述される。これらの記述は１つのファ
イルにつき３２バイト使用される。

【００７８】ＦＡＴにおいては、ＦＡＴのエントリとク
ラスタは１対１で対応しており、各クラスタのエントリ
にはリンク先、つまり後に続くクラスタの番号が記述さ
れる。つまり、複数のクラスタ（＝ブロック）で形成さ
れている或るファイルについてみると、まずディレクト
リによって先頭のクラスタ番号が示され、ＦＡＴにおけ
るその先頭クラスタのエントリには、次のクラスタ番号
が示される。さらに次のクラスタ番号のエントリには、
さらに次のクラスタ番号が示される。このようにクラス
タのリンクがＦＡＴに記述される。

【００７９】図１６はこのようなリンクの概念を模式的
に示している（数値は１６進値）。例えば２つのファイ
ル「ＭＡＩＮ．Ｃ」「ＦＵＮＣ．Ｃ」が存在するとする
と、ディレクトリにはこの２つのファイルの先頭クラス
タ番号が例えば「００２」「００４」と記述される。そ
してファイル「ＭＡＩＮ．Ｃ」については、クラスタ番
号「００２」のエントリに次のクラスタ番号「００３」
が記述され、またクラスタ番号「００３」のエントリに
次のクラスタ番号「００６」が記述される。さらに、ク
ラスタ番号００６がこのファイル「ＭＡＩＮ．Ｃ」の最
後のクラスタであるとすると、クラスタ番号「００６」
のエントリには、最後のクラスタであることを示す「Ｆ
ＦＦ」が記述される。これによりファイル「ＭＡＩＮ．
Ｃ」がクラスタ「００２」→「００３」→「００６」と
いう順番で記憶されている。即ち、仮にクラスタ番号と
メモリカード７０でのブロック番号が一致していると仮
定すると、ファイル「ＭＡＩＮ．Ｃ」は、メモリカード
７０内でブロック「００２」「００３」「００６」に記
憶されていることが表現されている。（但し、ＦＡＴで
扱うクラスタは、上述のように論理アドレスで扱うもの
となるため、ブロックの物理アドレスとそのまま一致す
るものではない）

【００８０】また同様にファイル「ＦＵＮＣ．Ｃ」につ
いては、ＦＡＴにより、クラスタ「００４」→「００
５」に記憶されていることが表現される。

【００８１】なお、未使用のブロックに対応するクラス
タについては、そのエントリは「０００」とされる。

【００８２】ところでルートディレクトリの領域に記憶
される各ファイルのディレクトリにおいては、図１６に
示した先頭クラスタ番号だけでなく、例えば図１７のよ
うに各種データが記述される。即ちファイル名、拡張
子、属性、変更時刻情報、変更日付情報、先頭クラスタ
番号、ファイルサイズが、それぞれ図示するバイト数で
記述される。

【００８３】また或るディレクトリの下層となるサブデ
ィレクトリについては、図１５のルートディレクトリの
領域ではなく、データ領域に記憶される。つまりサブデ
ィレクトリは、ディレクトリ構造を持つファイルとして
扱われる。そしてサブディレクトリの場合はサイズは無
制限とされ、また自分自身へのエントリと親ディレクト
リへのエントリが必要になる。

【００８４】図１８に、或るルートディレクトリ内にフ
ァイル「ＤＩＲ１」（属性＝ディレクトリ：つまりサブ
ディレクトリ）があり、さらにその中にファイル「ＤＩ
Ｒ２」（属性＝ディレクトリ：つまりサブディレクト
リ）があり、さらにその中にファイル「ＦＩＬＥ」が存
在する場合の構造例を示している。つまりルートディレ
クトリの領域には、サブディレクトリであるファイル
「ＤＩＲ１」としての先頭クラスタ番号が示され、上述
したＦＡＴにより、クラスタＸ、Ｙ、Ｚがリンクされて
いる状態となる。この図からわかるように、サブディレ
クトリ「ＤＩＲ１」「ＤＩＲ２」についてはファイルと
して扱われてＦＡＴのリンクに組み込まれる。

【００８５】６．メモリカードと情報処理装置のインタ
ーフェース図１９により、メモリカード７０と情報処理装置１のメ
モリカードインターフェース２８の間のシリアルインタ
ーフェースシステム構成を説明する。メモリカード７０
内のコントロールＩＣ８０は、図１９に示すようにフラ
ッシュメモリコントローラ８０ａ、レジスタ８０ｂ、ペ
ージバッファ８０ｃ、シリアルインターフェース８０ｄ
としての各ブロックを有するものとなっている。

【００８６】フラッシュメモリコントローラ８０ａは、
レジスタ８０ｂに設定されたパラメータに基づいて、フ
ラッシュメモリ８１とページバッファ８０ｃの間でのデ
ータ転送を行う。そしてページバッファ８０ｃにバファ
リングされたデータはシリアルインターフェース８０ｄ
を介して情報処理装置１のメモリカードインターフェー
ス２８側に転送され、また情報処理装置１のメモリカー
ドインターフェース２８から転送されてきたデータはシ
リアルインターフェース８０ｄを介してページバッファ
１０ｃにバファリングされる。

【００８７】メモリカードインターフェース２８側で
は、メモリカード７０に対するインターフェース構造と
して、ファイルマネージャ６０、転送プロトコルインタ
ーフェース６１、シリアルインターフェース６２を有す
る。ファイルマネージャ６０はメモリカード７０のファ
イル管理を行う。例えば本例のシステムではメモリカー
ド７０内にはメインデータファイルの管理のための管理
ファイルが記憶されているが、情報処理装置１は装填さ
れたメモリカード７０から管理ファイルをよみこんでＣ
ＰＵ２２がファイルマネージャ６０を形成することにな
る。メモリカード７０へのアクセスはファイルマネージ
ャ６０に従って実行される。転送プロトコルインターフ
ェース６１は、レジスタ８０ｂ、ページバッファ８０ｃ
へのアクセスを実行する。シリアルインターフェース６
２は、メモリカード７０との間の３つの信号線、即ちＳ
ＣＬＫ（シリアルクロック）、ＢＳ（バスステイト）、
ＳＤＩＯ（シリアルデータ入出力）において、任意のデ
ータ転送を行うためのプロトコルを規定する。

【００８８】以上の構成における各部の動作により、情
報処理装置１によるメモリカード７０（フラッシュメモ
リ８１）に対する読出アクセス／書込アクセスが実行さ
れる。

【００８９】７．メモリカードへのファイル記録時の処
理以下、情報処理装置１によりメモリカード７０に対して
ファイル（データベース）を記録する際の処理について
説明していく。ここでは一例として、或るアプリケーシ
ョンソフトウエアを構成する複数のファイルをメモリカ
ード７０に記録する場合の例を挙げ、まずその処理例を
説明し、以降、その処理例によって形成されるディレク
トリ構造例を各種示していく。なお、アプリケーション
ソフトウエアを構成する複数のファイルとは、例えば１
又は複数の実行ファイル（リソースデータベース）と、
１又は複数のデータファイル（データベースデータベー
ス）のことである。

【００９０】図２０はＣＰＵ２２によって実行される記
録時の処理を示している。ステップＦ１０１としてＣＰ
Ｕ２２は、ユーザーから或るアプリケーションを構成す
る複数のファイルをメモリカード７０に記録する指示が
あったことを検出すると、ステップＦ１０２として、そ
の複数のファイルを１つのディレクトリの下のファイル
として記録するために、ディレクトリを発生させる。こ
のとき、ディレクトリの名称は、アプリケーションＩＤ
をそのまま用いる。アプリケーションＩＤとは、クリエ
ーターＩＤとも呼ばれるもので、システム上で各アプリ
ケーションに対してそれぞれ固有の値として割り当てら
れている３２バイトのＩＤコードであり、ＯＳは、各ア
プリケーションをそのアプリケーションＩＤで識別して
扱うものとなっている。

【００９１】ところで、このアプリケーションＩＤは３
２バイトの数字列等であり、通常、ユーザーがそのＩＤ
コードをみて、それによって示されるアプリケーション
を判別できるものではない。そこでＣＰＵ２２は、ステ
ップＦ１０３で、アプリケーションをユーザーに提示す
る際に用いる名称（ユーザー提示用名称）を生成する。
これは例えばアプリケーションソフトウエアの商品名
称、機能名称などを利用して生成する。例えばアプリケ
ーションソフトウエアとしてメモ帳ソフト、地図ソフ
ト、予定表ソフトなどが存在する場合、これらのユーザ
ー提示用名称として、「ＭＥＭＯ」「ＭＡＰ」「ＳＣＨ
ＥＤＵＬＥ」等、ユーザーがすぐにアプリケーションを
判別できるような名称を生成するものである。

【００９２】続いてステップＦ１０４で、上記ディレク
トリ名、即ちアプリケーションＩＤと、上記ユーザー提
示用名称の対応情報を生成する。この対応情報として
は、後述の例でそれぞれ述べるが、例えば対応テーブル
ファイルとされたり、ディレクトリとリンクされるファ
イルであったり、タグファイルであったり、ファイル内
の情報であったりするなどの例が考えられる。いずれに
しても、アプリケーションＩＤを名称とするディレクト
リについて、ユーザー提示用名称を対応させるための情
報である。

【００９３】そしてステップＦ１０５では、実際にメモ
リカード７０への記録処理を実行する。即ちステップＦ
１０２で発生させたディレクトリ下に、アプリケーショ
ンを構成する各ファイルが配される状態となるようにメ
モリカード７０への記録及び管理構造の更新を実行す
る。このとき上記対応情報も何らかの形で記録されるよ
うにする。

【００９４】本例の情報処理装置１では、このように記
録が行われることで、システム及びユーザーの双方にと
って好適なものとなる。即ち、或るアプリケーションソ
フトウエアから発生される１又は複数のファイルについ
て、１つのディレクトリの下のファイルとして記録媒体
に記録されることでファイル管理上好適であると共に、
そのディレクトリの名称は、アプリケーションソフトウ
エアに固有に付されているアプリケーションＩＤを用い
ることから、当然に固有の名称としてディレクトリを設
定できるものとなり、かつそのアプリケーションソフト
ウエアについてアプリケーションＩＤを用いるＯＳから
すれば、ディレクトリ内容はその名称のみで明確に判別
できるものとなる。従ってメモリカード７０に記録した
ファイル管理上でも都合がよい。そしてさらに、ディレ
クトリ名称とユーザ提示用名称が対応づけられて記録さ
れることで、ユーザーにディレクトリを提示する際に
は、ユーザーにとってわかりやすい名称とすることがで
きる。例えばメモリカード７０に記録されているファイ
ルやディレクトリを表示部２に表示するような場合に、
ディレクトリについてはユーザー提示用名称を用いるこ
とで、ユーザーはその名称からディレクトリの内容（デ
ィレクトリ下に配されるファイルの種別）を判別でき
る。またそれによってユーザーのファイル指定、ディレ
クトリ指定等の操作性も向上する。即ちユーザーインタ
ーフェースが格段に向上する。

【００９５】８．形成されるディレクトリ構造例１上記処理例によっては、ステップＦ１０４で生成される
対応情報によってディレクトリ名とユーザー提示用名称
が対応づけられるが、その対応情報の形態例をとして４
つの例を、それぞれ形成されるディレクトリ構造例１〜
４として説明していく。

【００９６】まずディレクトリ構造例１を図２１（ａ）
に示す。これは対応情報が対応テーブルファイルとされ
る例である。なお、図１４にも示したように、ルートデ
ィレクトリからは情報処理装置用ディレクトリＰＭが形
成され、例えばアプリケーションを構成するファイル
は、このディレクトリＰＭ下に記録されていくものであ
るとする。

【００９７】図２１の例は、例えばメモ帳ソフトとして
のアプリケーションについてファイル群が記録され、ま
た地図ソフトとしてのアプリケーションについてファイ
ル群が記録された場合を示している。まずメモ帳ソフト
の構成ファイル群が記録される際には、例えば「１２３
４・・・４３２１」という３２バイトコードのアプリケ
ーションＩＤが名称とされたディレクトリが形成され、
そのディレクトリ下に、実行ファイル（ｘｘｘ．ｐｒｃ
等）やデータファイル（○○○．ｄｔｂ等）が記録され
ることになる。そしてこのとき、ディレクトリＰＭの下
に、上記ディレクトリ「１２３４・・・４３２１」と並
列に対応テーブルファイルＴＢＬが形成され、この対応
テーブルファイルＴＢＬには、図２１（ｂ）に示すよう
にディレクトリ「１２３４・・・４３２１」に対応して
「ＭＥＭＯ」というユーザー提示用名称が示されるもの
とされる。

【００９８】またその後、地図帳ソフトの構成ファイル
群が記録される際には、例えば「９８７６・・・６７８
９」という３２バイトコードのアプリケーションＩＤが
名称とされたディレクトリが形成され、そのディレクト
リ下に、実行ファイル（ａｂｃｄ．ｐｒｃ）やデータフ
ァイル（ａａａ．ｄｔｂ等）が記録されることになる。
そしてこのとき、対応テーブルファイルＴＢＬには、デ
ィレクトリ「９８７６・・・６７８９」に対応して「Ｍ
ＡＰ」というユーザー提示用名称が示される。

【００９９】従ってシステムからみれば、ディレクトリ
ＰＭ下において、アプリケーションＩＤによって各ディ
レクトリの内容を判別できると共に、対応テーブルファ
イルによりディレクトリに対応するユーザー提示用名称
を判別してユーザーに提示できる。

【０１００】９．形成されるディレクトリ構造例２図２２のディレクトリ構造例２は対応情報を、ディレク
トリとリンクするファイルにより形成した例である。こ
の場合、例えばメモ帳ソフトの構成ファイル群が記録さ
れる際には、ディレクトリＰＭの下に「１２３４・・・
４３２１」という３２バイトコードのアプリケーション
ＩＤが名称とされたディレクトリが形成され、そのディ
レクトリ下に、実行ファイル（ｘｘｘ．ｐｒｃ等）やデ
ータファイル（○○○．ｄｔｂ等）が記録される。

【０１０１】そしてこのとき、ディレクトリＰＭの下
に、上記ディレクトリ「１２３４・・・４３２１」と並
列に、ユーザ提示用名称を示した名称ファイルＭＥＭＯ
が形成される。この名称ファイルは、ファイル名が「Ｍ
ＥＭＯ」とされファイル内容としては実体データのない
ものとしてもよいし、実体データとして「ＭＥＭＯ」と
いうユーザー提示用名称を記録したものでもよい。そし
て個の名称ファイル「ＭＥＭＯ」は、いわゆるシンボリ
ックリンク、又はエイリアスと呼ばれるような方式で、
ディレクトリ「１２３４・・・４３２１」にリンクされ
た状態とする。

【０１０２】従ってシステムからみれば、ディレクトリ
ＰＭ下において、アプリケーションＩＤによって各ディ
レクトリの内容を判別できると共に、リンクされる名称
ファイルの存在によってディレクトリに対応するユーザ
ー提示用名称を判別してユーザーに提示できる。

【０１０３】１０．形成されるディレクトリ構造例３図２３（ａ）のディレクトリ構造例３は対応情報を、ユ
ーザ提示用名称を示したタグファイルとし、対応するデ
ィレクトリ下に配するようにした例である。この場合、
例えばメモ帳ソフトの構成ファイル群が記録される際に
は、ディレクトリＰＭの下に「１２３４・・・４３２
１」という３２バイトコードのアプリケーションＩＤが
名称とされたディレクトリが形成され、そのディレクト
リ下に、実行ファイル（ｘｘｘ．ｐｒｃ等）やデータフ
ァイル（○○○．ｄｔｂ等）が記録される。

【０１０４】さらにこのとき、ディレクトリ「１２３４
・・・４３２１」の下に、ユーザ提示用名称を示したタ
グファイルＴＧが形成される。このタグファイルＴＧ
は、図２３（ｂ）に示すように、ディレクトリ「１２３
４・・・４３２１」に対応して「ＭＥＭＯ」というユー
ザー提示用名称が示されるファイルである。

【０１０５】従ってシステムからみれば、ディレクトリ
ＰＭ下において、アプリケーションＩＤによって各ディ
レクトリの内容を判別できると共に、タグファイルＴＧ
の存在によってディレクトリに対応するユーザー提示用
名称を判別してユーザーに提示できる。

【０１０６】１１．形成されるディレクトリ構造例４図２４（ａ）のディレクトリ構造例４は対応情報を、デ
ィレクトリ下の特定のファイルに記録されるユーザ提示
用名称とする例である。この場合、例えばメモ帳ソフト
の構成ファイル群が記録される際には、ディレクトリＰ
Ｍの下に「１２３４・・・４３２１」という３２バイト
コードのアプリケーションＩＤが名称とされたディレク
トリが形成され、そのディレクトリ下に、実行ファイル
（ｘｘｘ．ｐｒｃ）やデータファイル（○○○．ｄｔｂ
等）が記録される。

【０１０７】さらにこのとき、実行ファイル（ｘｘｘ．
ｐｒｃ）には、図２４（ｂ）に示すように、「ＭＥＭ
Ｏ」というユーザー提示用名称と、ディレクトリ名「１
２３４・・・４３２１」が記録される。

【０１０８】従ってシステムからみれば、ディレクトリ
ＰＭ下において、アプリケーションＩＤによって各ディ
レクトリの内容を判別できると共に、そのディレクトリ
下のファイル群の特定のファイル、例えば実行ファイル
からディレクトリに対応するユーザー提示用名称を判別
してユーザーに提示できる。

【０１０９】以上、実施の形態としての情報処理装置の
構成、記録媒体の例、記録時の処理、記録処理によるデ
ィレクトリ構造等を説明してきたが、本発明はこれらの
例に限定されることなく、各種の変形例が考えられ、ま
た本発明を適用できる装置は、多岐にわたるものであ
る。

【０１１０】

【発明の効果】以上の説明から理解されるように本発明
によれば、或るアプリケーションソフトウエアから発生
される１又は複数のファイルについて、１つのディレク
トリの下のファイルとして記録媒体に記録されることで
ファイル管理上好適であると共に、そのディレクトリの
名称は、アプリケーションソフトウエアに固有に付され
ているアプリケーションＩＤを用いることから、容易に
固有の名称としてディレクトリを設定でき、かつそのア
プリケーションソフトウエアについてアプリケーション
ＩＤを用いるシステム上から、ディレクトリ内容は明確
なものとすることができる。これらのことからファイル
システム管理上で非常に都合がよい。そしてさらに、デ
ィレクトリ名称とユーザ提示用名称が対応づけられて記
録されることで、ユーザーにディレクトリを提示する際
には、ユーザーにとってわかりやすい名称とすることが
でき、かつユーザーのディレクトリ名設定操作の負担も
ない。従ってシステム上のファイル管理性の向上とユー
ザーインターフェースの向上を同時に実現できるという
効果がある。

【図面の簡単な説明】

【図１】本発明の実施の形態の情報処理装置の平面図、
右側面図、左側面図、上面図である。

【図２】実施の形態の情報処理装置のブロック図であ
る。

【図３】実施の形態の情報処理装置のＯＳ構造の説明図
である。

【図４】実施の形態の情報処理装置で扱うデータベース
構造の説明図である。

【図５】実施の形態のメモリカードの外形形状を示す平
面図、正面図、側面図、底面図である。

【図６】実施の形態のメモリカードの内部構造の説明図
である。

【図７】実施の形態のファイルシステム処理階層の説明
図である。

【図８】実施の形態のメモリカードの物理的データ構造
の説明図である。

【図９】実施の形態のメモリカードの管理フラグの説明
図である。

【図１０】実施の形態のメモリカードにおけるデータ更
新処理と物理アドレス及び論理アドレスの概念の説明図
である。

【図１１】実施の形態の論理−物理アドレス変換テーブ
ルの管理形態の説明図である。

【図１２】実施の形態の論理−物理アドレス変換テーブ
ルの構造の説明図である。

【図１３】実施の形態のメモリカードのフラッシュメモ
リ容量／ブロック数／１ブロックの容量／１ページの容
量／論理−物理アドレス変換テーブルのサイズの関係の
説明図である。

【図１４】実施の形態のメモリカードのディレクトリ構
造の説明図である。

【図１５】ＦＡＴ構造の説明図である。

【図１６】ＦＡＴによるクラスタ管理形態の説明図であ
る。

【図１７】ディレクトリの内容の説明図である。

【図１８】サブディレクトリ及びファイルの格納形態の
説明図である。

【図１９】実施の形態の情報処理装置とメモリカードの
インターフェース構成の説明図である。

【図２０】実施の形態の情報処理装置の記録時の処理の
フローチャートである。

【図２１】実施の形態の形成されるディレクトリ構造例
１の説明図である。

【図２２】実施の形態の形成されるディレクトリ構造例
２の説明図である。

【図２３】実施の形態の形成されるディレクトリ構造例
３の説明図である。

【図２４】実施の形態の形成されるディレクトリ構造例
４の説明図である。

【符号の説明】

１情報処理装置、２表示部、３ａ，３ｂ，３ｃ操
作子、４スピーカ、５マイクロホン、６撮像部、
７メモリスロット、８ＩＥＥＥ１３９４端子、９
ＵＳＢ端子、１０ヘッドホン端子、１１ライン入力
端子、１２ライン出力端子、２１システムコントロ
ーラ、２２ＣＰＵ、２３フラッシュＲＯＭ、２４
Ｄ−ＲＡＭ、２５ＵＳＢインターフェース、２６Ｉ
ＥＥＥ１３９４インターフェース、２７表示制御部、
２８メモリカードインターフェース、２９オーディ
オインターフェース、７０メモリカード

Claims

【特許請求の範囲】

【請求項１】或るアプリケーションソフトウエアから
発生される１又は複数のファイルを、１つのディレクト
リの下のファイルとして記録媒体に記録すると共に、上
記アプリケーションソフトウエアに固有に付されている
アプリケーションＩＤを上記ディレクトリ名称として用
い、さらに、上記ディレクトリ名称とユーザ提示用名称
の対応づけを行うことを特徴とするディレクトリ設定方
法。
【請求項２】上記ディレクトリ名称と上記ユーザ提示
用名称を対応させる対応テーブルファイルを上記記録媒
体に記録することで、上記対応づけを実現することを特
徴とする請求項１に記載のディレクトリ設定方法。
【請求項３】上記ユーザ提示用名称を示した名称ファ
イルを上記ディレクトリ外において、上記記録媒体に記
録するとともに、上記名称ファイルを上記ディレクトリ
にリンクさせることで、上記対応づけを実現することを
特徴とする請求項１に記載のディレクトリ設定方法。
【請求項４】少なくとも上記ユーザ提示用名称を示し
たタグファイルを、上記ディレクトリ下において、上記
記録媒体に記録することで、上記対応づけを実現するこ
とを特徴とする請求項１に記載のディレクトリ設定方
法。
【請求項５】上記ディレクトリ下の特定のファイル
に、上記ユーザ提示用名称を記録することで、上記対応
づけを実現することを特徴とする請求項１に記載のディ
レクトリ設定方法。
【請求項６】ユニークなアプリケーションＩＤを有す
る或るアプリケーションソフトウエアを構成する上記ユ
ニークなアプリケーションＩＤを有する１又は複数のフ
ァイルを格納するディレクトリを、上記アプリケーショ
ンソフトウエアの上記アプリケーションＩＤをディレク
トリ名称として用いて発生させるディレクトリ発生手段
と、上記ディレクトリ名称とユーザ提示用名称の対応づけを
行う情報を生成する対応情報生成手段と、記録媒体に対して、上記ディレクトリの下にディレクト
リ名と同一のＩＤを有する上記１又は複数のファイルを
記録すると共に上記対応情報を記録する記録手段と、を備えたことを特徴とする記録装置。
【請求項７】上記対応情報生成手段は上記対応情報と
して、上記ディレクトリ名称と上記ユーザ提示用名称を
対応させる対応テーブルファイルを生成し、上記記録手
段は、上記対応テーブルファイルを上記記録媒体に記録
することを特徴とする請求項６に記載の記録装置。
【請求項８】上記対応情報生成手段は上記対応情報と
して、上記ディレクトリにリンクされる、上記ユーザ提
示用名称を示した名称ファイルを生成し、上記記録手段は、上記名称ファイルを上記ディレクトリ
外において、上記記録媒体に記録することを特徴とする
請求項６に記載の記録装置。
【請求項９】上記対応情報生成手段は上記対応情報と
して、少なくとも上記ユーザ提示用名称を示したタグフ
ァイルを生成し、上記記録手段は、上記タグファイルを上記ディレクトリ
下において、上記記録媒体に記録することを特徴とする
請求項６に記載の記録装置。
【請求項１０】上記対応情報生成手段は上記対応情報
として、上記ディレクトリ下の特定のファイルに、上記
ユーザ提示用名称を含ませるようにすることを特徴とす
る請求項６に記載の記録装置。