(57)【要約】【課題】  記憶媒体に記憶されたファイルのファイル管理を簡易に、かつ柔軟に行うことを可能とする。【解決手段】  管理情報作成部１５は、フラッシュＲＯＭ１１のデータ領域１１ｂに保存されるファイルの属性を示したファイル管理情報とファイルを構成するデータが記憶されるセクタの属性を示したデータ領域管理情報とからなりＸＭＬで記述した管理情報をＸＭＬパーサ１６を使用して管理領域１１ａに書き込む。また、ＸＭＬパーサ１６は、管理領域に記憶された管理情報をＸＭＬ以外の、ダウンロード処理部１４やアプリケーション処理部１７に適した形式に変換する。【選択図】      図１
2005135011.tif 000002
【特許請求の範囲】
【請求項１】
セクタ構造を有するとともにファイル管理情報を記憶する管理領域およびデータを記憶するデータ領域を備える記憶媒体にアクセス可能な電子装置であって、
前記記憶媒体に保存されるファイルの属性と前記ファイルを構成するデータが記憶されるセクタの属性とを対応付けてＸＭＬ（eXtensible Markup Language）で記述した管理情報を前記管理領域に書き込む手段と、
前記管理領域に記憶された前記管理情報をＸＭＬ以外の形式に変換する手段とを具備したことを特徴とする電子装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フラッシュＲＯＭ（Read Only Memory）等の記憶媒体に保存されるファイルの管理を行う電子装置に関する。
【背景技術】
【０００２】
プログラムファイルやデータファイルなどのファイルをダウンロード可能な組込型のマイコンシステムでは、ダウンロードしたファイルを不揮発性記憶装置であるフラッシュＲＯＭに保存するケースが多々ある。この場合のフラッシュＲＯＭに保存されたファイルは、フラッシュＲＯＭにファイルを保存するためのデータ領域とは別に管理領域を設け、この管理領域にファイルの管理情報およびデータ領域の管理情報を記憶しておくことでシステム的に管理している。ファイルの管理情報は図１２に示すように、ファイル名、所有者、ファイルサイズ、作成日付、更新日付、ファイルアクセス権、あるいはデータ領域でのファイルの格納位置などを含む。データ領域の管理情報は図１２に示すように、空き容量、使用容量、あるいは空き領域等の情報を含む。
【０００３】
図１３は管理情報の具体例を示す図である。  
ここでは、128Kbyteセクタを６３個、16Kbyteのセクタを８個有した容量8MbyteのフラッシュＲＯＭに、ファイル名が「CSWELanSvr」、版が「1.00」、ファイルサイズが「1127000」、作成日付が「03.5.11 11:36」、更新日付が「03.5.12.15:11」、アクセス権限が「rwxr-xr-x」、所有者が「Y.Watanabe」であるファイルを、図１４に示すようにNo.1からNo.9の９つの128Kbyteセクタに保存した場合を例示する。なお図１４では、上記のファイルが保存されるセクタをハッチングして示している。
【０００４】
以上のようなファイル管理は、一般的に言うファイル管理システムに近い形になっている。ただしファイル管理システムは、上述のような管理情報に、ディレクト管理、ネットワーク管理システムと結びついたネットワーク上のファイル管理、さらにはシステム管理と結びついた実行ファイル管理等が付加される。
【０００５】
高性能ＣＰＵおよび大容量のメモリを用いた比較的大きい組込型システム（例えば、トロン系、ＵＮＩＸ系、Ｗｉｎｄｏｗｓ系、その他）においては、図１５に示すようにファイル管理システム１０１を実装したオペレーティングシステム（ＯＳ）１０２が搭載され、フラッシュＲＯＭ１０３はファイル管理システム１０１から直接管理されるケースもある。このようなファイル管理システム１０１によれば、ユーザプログラム１０４からフラッシュＲＯＭ１０３へのアクセスはファイル管理システム１０１を通して行われる。従って、ユーザプログラム１０４は記憶媒体が何であるか意識することなく、共通アプリケーションインタフェースでフラッシュＲＯＭ１０３上にファイルの作成・書き込み・読み込み・削除ができる。ファイル管理は、全てファイル管理システム１０１が行う。
【０００６】
一方、ＣＰＵの性能が低く、メモリもそれほど持たない組込型システムにおいては、管理領域を設けずに、図１６に示すようにフラッシュＲＯＭ１１１をプログラムから直接、固定的に管理している。すなわち、第１アプリケーションの格納エリアはアドレス「04000000」から256Kbyte、第２アプリケーションの格納エリアはアドレス「04030000」から256Kbyte、第３アプリケーションの格納エリアはアドレス「04060000」から256Kbyteと固定的に決め、ダウンロードプログラム１１２の中にこのアドレステーブル１１３を設け、ダウンロードプログラム１１２から直接、該当エリアにアクセスする。この場合、ファイルという概念は持たない。
【０００７】
さて昨今においては、組込型システムに要求される機能はますます増え、機能は分割され、多数の開発者により開発されたプログラムがダウンロードプログラムとして複数個存在する。初期あるいは不具合発生時には、上記のような複数のダウンロードプログラムがプログラム単位でダウンロードされ、フラッシュＲＯＭに保存される。このような環境下においては、ファイルという概念が必要になってくる。しかしオペレーティングシステムのファイル管理システムを実装する程の規模ではない機器においては、限られた資源（ＣＰＵ、メモリ）を有効に使ってファイル管理機能を実現することが要求される。
【０００８】
ファイル管理システムを使用しないでフラッシュＲＯＭ上でファイルを管理する前述の方法によると、管理領域に置かれる各種管理情報は開発毎にまちまちであり、そのフォーマットは統一されていない。データ領域の管理方式が違えば、当然データ領域の管理情報も異なる。例えば図１２に示した管理情報は、イレーズ処理はファイルの削除要求が出されるたびに行い、かつセクタの残りは使用しない、という前提の下に作成されている。これを例えば資源の無駄を省くという考えの下でデータ領域の管理を行うとしたら、図１７に示すようにセクタ内のデータの始まりの位置および終わりの位置を示す情報１２１を追加する必要がある。また、イレーズはファイルの削除毎に行うのではなく、新たに使用する領域が確保できなくなったときにイレーズを行うようにし、セクタの隙間をレイアウトし直す（ガベージコレクタ）のならば、図１７に示すように削除容量や削除領域（イレーズ処理を必要とする容量や領域）の情報１２２も管理情報に追加する必要がある。
【０００９】
ファイルの管理情報も、例えば携帯電話機のダウンロードプログラムで管理しなければならない管理情報と、自動車のエンジンの制御プログラムで管理しなければならない管理情報とは異なったものになる。例えば、携帯電話機でゲーム等のアプリケーションをダウンロードする時には図１８に示すように、携帯電話機１３１へは配信サーバ１３２より、アプリケーションのダウンロードの前にアプリケーション記述子が送られる。このアプリケーション記述子は、アプリケーション名、ファイル名、ＪＡＶＡコアライブラリバージョン、ＪＡＶＡユーザインタフェースのバージョンなどを記述したテキストファイルである。携帯電話機１３１では、このアプリケーション記述子に基づいて、ダウンロードするアプリケーションが携帯電話機１３１側のＪＡＶＡ環境で適切かどうかをチェックするとともに、ファイルの管理情報には図１９に示すようにＪＡＶＡコアライブラリバージョン、ＪＡＶＡユーザインタフェースのバージョンなどの情報１４１を追加する。また、自動車のエンジン制御プログラムのダウンロードでは、人命にかかわるプログラムであるため、セキュリティ管理を厳重にすることが必要となり、パスワードの付加、暗号キーの付加などが必要になる。
【００１０】
ところで、これらの管理情報は従来、バイトデータである。図２０は図１２に示した管理情報をバイトデータで展開した様子を示す図である。この図２０において、「ＮＬ」はnew lineを示し、１６進で「０Ａ」を意味する。バイトデータは「０」または「１」で始まり、各フィールドは「，」で区切られ、「ＮＬ」で終わる。バイトデータは、ファイルの管理情報とデータ領域の管理情報との２種類が有り、ファイルの管理情報は「０」で始まり、データ領域の管理情報は「１」で始まる。各フィールドの意味は以下の通りである。
【００１１】
(1) ファイルの管理情報  
「０，ファイル名，版，ファイルサイズ，所有者，作成日付，更新日付，アクセス権，データ領域の格納セクタ位置とセクタ内データ数ＮＬ」
なお、データ領域の格納セクタ位置とセクタ内データ数は複数ある場合はスペースで区切って記述する。セクタ位置は「xxx-yy」の形式で表わし、「xxx」はセクタの種類で「128」は128Kbyteセクタを、「16」は16Kbyteセクタをそれぞれ表わす。「yy」はセクタ番号。セクタ内データ数は「データ数」で表わす。
【００１２】
(2) データ領域の管理情報
「１，128Kbyteセクタ使用容量，128Kbyteセクタ空き容量，128Kbyteセクタ空き領域，16Kbyteセクタ使用容量，16Kbyteセクタ空き容量，16Kbyteセクタ空き領域ＮＬ」
なお、128Kbyteセクタ空き領域，16Kbyteセクタ空き領域の表現形式は「xxx-yy」である。
【００１３】
このように、実際の管理情報はバイトデータの羅列である。各バイトデータが何を示しているかは、そのバイトデータの位置により決まる。すなわち図２０に示す管理情報は、図２１（ａ）に示すような固定のフォーマットをなしている。そして、例えば第５フィールドのバイトデータを参照することにより、所有者を認識できることになる。
【００１４】
このような管理情報では、項目の追加および削除と、記述形式の変更は次のようにして行われる。  
(1) 項目の追加
図１９に示した例のように、「ＪＡＶＡコアライブラリのバージョン」および「ＪＡＶＡユーザインタフェースのバージョン」の各項目を図２１（ａ）に示したフォーマットに対して図２１（ｂ）に示すように追加すると、管理情報は図２１（ｃ）に示すようなフォーマットに変更される。この場合、「格納セクタ位置とセクタ内データ数」の項目が第９フィールドから第１１フィールドに移る。「格納セクタ位置とセクタ内データ数」の項目の情報は追加前では第９フィールドを参照することで認識できたが、第１１フィールドを参照するように変更される。このため、管理情報読み込みプログラムの変更が必要となる。
【００１５】
(2) 項目の削除
追加の場合と同様に、削除の場合も管理情報読み込みプログラムの変更が必要となる。例えば、図２１（ａ）に示すフォーマットにおける「所有者」の項目を削除すると、以降の各項目のフィールドが１つずつずれる。  
管理情報読み込みプログラムの変更を避けるために、図２２に示すようにバイトデータを記述しない方法も考えられる。しかしこの方法だと、項目自体は残ってしまう。
【００１６】
(3) 記述形式の変更
例えば、セクタ内のデータの管理をデータ数による管理から開始位置および終了位置による管理に変更する場合、変更前は例えば「128-9(15000)」と記述していたものが、「128-9(0 14999)」または「128-9(0-12999)」といった記述に変更となる。  
このような変更にともない、管理情報読み込みプログラムを次のように変更することが必要となる。  
・「データ領域の格納セクタ位置とセクタ内の開始位置および終了位置」の項目に相当するフィールドを読み込む。  
・カッコ内のデータを取得。  
・取得したデータをサーチし、スペース（または「−」）より前のデータを開始位置、スペース（または「−」）より後ろのデータを終了位置とする。
【００１７】
なお、コンフィギュレーション情報やメタデータをＸＭＬで記述することは知られている（例えば特許文献１および特許文献２を参照）。
【特許文献１】特開2001-134721
【特許文献２】特開2002-202905
【発明の開示】
【発明が解決しようとする課題】
【００１８】
以上のように、ファイル管理システムを用いずにファイルの管理を行う場合には、複数の項目に関するバイトデータを固定フォーマットで羅列した管理情報が利用されていた。  
このため、管理情報の変更に対する柔軟性がなく、管理情報の変更に当っては管理情報を読み込むプログラムの変更を伴うなどの不具合があった。
【００１９】
本発明はこのような事情を考慮してなされたものであり、その目的とするところは、記憶媒体に記憶されたファイルのファイル管理を簡易に、かつ柔軟に行うことが可能な電子機器を提供することにある。
【課題を解決するための手段】
【００２０】
以上の目的を達成するために本発明は、セクタ構造を有するとともにファイル管理情報を記憶する管理領域およびデータを記憶するデータ領域を備える記憶媒体にアクセス可能な電子装置に、前記記憶媒体に保存されるファイルの属性と前記ファイルを構成するデータが記憶されるセクタの属性とを対応付けてＸＭＬ（eXtensible Markup Language）で記述した管理情報を前記管理領域に書き込む手段と、前記管理領域に記憶された前記管理情報をＸＭＬ以外の形式に変換する手段とを備えた。
【発明の効果】
【００２１】
本発明によれば、記憶媒体に記憶されたファイルのファイル管理を簡易に、かつ柔軟に行うことが可能な電子機器を提供できる。
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して本発明の一実施形態につき説明する。  
図１は本実施形態に係る電子機器１の要部構成を示すブロック図である。  
電子機器１は、配信サーバ２にインターネット３を介してアクセス可能であり、配信サーバ２からファイルをダウンロードする機能を備えるものである。
【００２３】
電子機器１は図１に示すように、フラッシュＲＯＭ１１、ドライバ１２、通信部１３、ダウンロード処理部１４、管理情報作成部１５、ＸＭＬパーサ１６およびアプリケーション処理部１７を含む。
【００２４】
フラッシュＲＯＭ１１は、ダウンロードしたファイルを保存するための記憶媒体である。フラッシュＲＯＭ１１は、例えば128Kbyteセクタを６３個、16Kbyteのセクタを８個有したセクタ構造を持つ。これらのセクタの一部が管理領域１１ａに割り当てられ、残りのセクタがデータ領域１１ｂに割り当てられる。管理領域１１ａは、ファイルを管理するための管理情報を保存する。データ領域は、ファイルを保存する。
【００２５】
ドライバ１２は、フラッシュＲＯＭ１１への書き込みと、フラッシュＲＯＭ１１からの読み出しとを行う。
【００２６】
通信部１３は、インターネット３を介しての通信を行う。
【００２７】
ダウンロード処理部１４は、配信サーバ２からファイルをダウンロードし、データ領域１１ｂへ保存するためのダウンロード処理を実行する。このときダウンロード処理部１４は、管理領域１１ａに記憶された管理情報をＸＭＬパーサ１６を使用して取得する。
【００２８】
管理情報作成部１５は、配信サーバ２からダウンロードされてデータ領域１１ｂに保存されるファイルの属性とこのファイルを構成するデータが記憶されるセクタの属性とを対応付け、ＸＭＬパーサ１６を使ってＸＭＬの記述に置き換え、管理情報として管理領域１１ａに保存するための管理情報作成処理を実行する。
【００２９】
ＸＭＬパーサ１６は、管理領域１１ａに記憶された管理情報を解釈して、ダウンロード処理部１４やアプリケーション処理部１７で使用するのに適した形態に変換し、ダウンロード処理部１４やアプリケーション処理部１７に与える。またＸＭＬパーサ１６は、管理情報作成部１５やアプリケーション処理部１７からの要求に応じて、管理領域１１ａに保存された管理情報を編集する。
【００３０】
アプリケーション処理部１７は、任意のアプリケーションからのプログラムファイルやデータファイルの取得要求またはデータファイルの書き込み要求に対し、管理領域１１ａに記憶された管理情報をＸＭＬパーサ１６を使用して取得し、その情報からデータ領域１１ｂにアクセスし、アプリケーションからの要求を実行する。また必要に応じて管理領域１１ａに保存された管理情報をＸＭＬパーサ１６を使用して更新する。
【００３１】
なお、ドライバ１２、ダウンロード処理部１４、管理情報作成部１５、ＸＭＬパーサ１６およびアプリケーション処理部１７は、例えばマイクロプロセッサを基本ハードウェアとして用い、上記の各部を機能させるためのプログラムを上記のマイクロプロセッサに実行させることにより実現することができる。
【００３２】
さて、この電子機器１の設計に当って設計者は、フラッシュＲＯＭ１１の内容（容量、セクタ数、セクタサイズ、イレーズ方式、イレーズ時間等）に基づいてデータ領域の管理方式を決定する。設計者は、この決定した管理方式でファイルの管理を行うために必要となる属性をピックアップする。ここでピックアップされる属性は、ファイル自体に関する属性（以下、ファイル属性と称する）およびデータ領域１１ｂに関する属性（以下、データ領域属性と称する）であり、ファイル属性の集合がファイルの管理情報（以下、ファイル管理情報と称する）となり、データ領域属性の集合がデータ領域１１ｂの管理情報（以下、データ領域管理情報と称する）となる。設計者は、ファイル属性およびデータ領域属性に対し、これらの属性の内容を識別可能な名前をつける。さらに設計者は、ファイル属性およびデータ領域属性の名前に対応付けて、ＸＭＬの要素名および記述形式とを定めて、これらの対応付けをダウンロード処理部１４、管理情報作成部１５およびアプリケーション処理部１７に登録する。
【００３３】
図２はファイル属性またはデータ領域属性の名前と、ＸＭＬの要素名および記述形式との対応付けの一例を示す図である。  
この図２の例では、ファイル属性として９つの属性がピックアップされており、これらにはファイル名、版、ファイルサイズ、所有者、作成日付、更新日付、アクセス権、データ領域の格納セクタ位置、セクタのデータ数、といった名前が付けられている。またデータ領域属性として６つの属性がピックアップされており、これらには128Kbyteセクタ使用容量、128Kbyteセクタ空き容量、128Kbyteセクタ空き領域、16Kbyteセクタ使用容量、16Kbyteセクタ空き容量、16Kbyteセクタ空き領域、といった名前が付けられている。
【００３４】
そして図２の例では、「ファイル名」なる名前のファイル属性には、要素名fileを使用し、その内容はname属性により記述することが定められている。「版」なる名前のファイル属性には、要素名versionを使用し、その内容はPCDATA（パースドキャラクタデータ）により記述することが定められている。なお、図２の例では、ファイルの管理情報に対しては要素名filecontrolが、またデータ領域の管理情報に対しては要素名datacontrolがそれぞれ割り付けられている。
【００３５】
また設計者は、データ領域管理情報を作成しておく。このデータ領域管理情報を電子機器１の製造時などに管理領域１１ａに書き込む。  
図３は電子機器１の製造時などに管理情報１１ａに書き込まれるデータ領域管理情報の一例を示す図である。  
この図３の例は、フラッシュＲＯＭ１１が、128Kbyteセクタを６３個、16Kbyteのセクタを８個有した容量8Mbyteのものであり、no.0の128Kbyteセクタを管理領域１１ａに割り当て、残りの全てのセクタをデータ領域１１ｂに割り当てる場合である。
【００３６】
datacontrol要素がデータ領域管理情報に相当する。usesize要素は、128Kbyteセクタおよび16Kbyteセクタのそれぞれの全使用容量を示す。初期には、データ領域１１ｂに割り当てられた128Kbyteセクタおよび16Kbyteセクタのいずれも使用されていないので、その内容は「０」とされる。availablesize要素は、128Kbyteセクタおよび16Kbyteセクタのそれぞれの全空き容量を示す。初期には、データ領域１１ｂに割り当てられた６２個の128Kbyteセクタおよび８個の16Kbyteセクタのいずれも空きであるので、それぞれの内容は「7936000」および「128000」とされる。sector要素は、空き領域であるセクタを示す。初期には、no.1〜no.62の128Kbyteセクタとno.0〜no.8の16Kbyteセクタが空き領域であるので、これらのセクタの情報がそれぞれsector要素で示される。
【００３７】
次に以上のように構成された電子機器１の動作について説明する。  
ここでは、配信サーバ２は、電子機器１から要求に応じてファイルのダウンロードを行うが、ファイルの本体のダウンロードに先立って、このファイルに関する属性を示したアプリケーション記述子をダウンロードすることとする。
【００３８】
図４はダウンロード処理部１４が実行するダウンロード処理および管理情報作成部１５が実行する管理情報作成処理のフローチャートである。  
ファイルをダウンロードするときに電子機器１では、ダウンロード処理部１４および管理情報作成部１５が図４に示すダウンロード処理および管理情報作成処理をそれぞれ実行する。
【００３９】
ステップＳａ１においてダウンロード処理部１４は、アプリケーション記述子をダウンロードする。ステップＳａ２においてダウンロード処理部１４は、これからダウンロードするファイルがデータ領域１１ｂに保存可能かどうかを確認する。ダウンロード処理部１４は、上記のアプリケーション記述子に示されるファイルサイズと、管理領域１１ａに記憶されたデータ領域１１ｂの空き容量（availablesize要素で示される空き容量）とを比較することで、上記の確認を行う。もし、保存が不可能であることを確認したならば、ダウンロード処理部１４はダウンロード処理を終了する。
【００４０】
これに対して保存が可能であることを確認したならば、ダウンロード処理部１４はステップＳａ２からステップＳａ３へ進む。ステップＳａ３においてダウンロード処理部１４は、上記のアプリケーション識別子を管理情報作成部１５へ渡す。
【００４１】
ステップＳｂ１において管理情報作成部１５は、上記のようにダウンロード処理部１４から渡されるアプリケーション識別子を取得する。ステップＳｂ２において管理情報作成部１５は、アプリケーション識別子に示される各種の属性値のうちから前述したように予め名前が登録された属性に関する属性値を取り出して、これらをＸＭＬパーサ１６に与えてＸＭＬの記述に置き換えさせ、ドライバ１２を介してファイル管理情報として管理領域１１ａへ書き込む。
【００４２】
図５はファイル管理情報が書き込まれたのちに管理領域１１ａに保存される情報の一例を示す図である。  
図５に示すfilecontrol要素がファイル管理情報に相当する。このfilecontrol要素には、file要素、version要素、size要素、owner要素、createdate要素、updatedate要素およびaccesspermission要素を含み、これらの要素にファイルの属性がそれぞれ示される。例えば、「ファイル名」なる名前の属性に関して「CSWLanSvr」なる属性値がアプリケーション識別子に示されていたことに応じて、<file  name="CSWLanSvr">という要素が示される。また、「版」なる名前の属性に関して「1.00」なる属性値がアプリケーション記述子に示されていたことに応じて、<version>1.00</version>なる要素が示される。以降、ファイルのダウンロードは、図６に示す方式で行われることを前提に説明する。すなわち、ダインロード処理部１４は、配信サーバ２と通信部１３を通して１伝文のダウンロードデータを受信する度に、フラッシュＲＯＭ１１へダウンロードデータを書き込む。
【００４３】
さて、ステップＳａ４においてダウンロード処理部１４は、ＸＭＬパーサ１６を使って管理領域１１ａに記憶されたセクタ飽き領域を取得し、空き領域に含まれるセクタの１つを使用セクタとして選択する。すなわちダウンロード処理部１４は、datacontrol要素に含まれたsector要素に対応するセクタのうちの１つを使用セクタとして選択する。そしてステップＳａ５においてダウンロード処理部１４は、上記の使用セクタを管理情報作成部１５へ通知する。
【００４４】
管理情報作成部１５は、ステップＳｂ２を終えたならば、ステップＳｂ３において、使用セクタが通知されるのを待ち受けている。そこで、上述のようにダウンロード処理部１４から使用セクタが通知されたならば、管理情報作成部１５はステップＳｂ３からステップＳｂ４へ進む。ステップＳｂ４において管理情報作成部１５は、使用セクタを空き領域から削除する。具体的には管理情報作成部１５は、ＸＭＬパーサ１６に今回使用するセクタを示し、datacontrol要素から削除するよう指示する。例えばno.1の128Kbyteセクタが使用セクタとして選択されたのであれば、管理情報作成部１５は、sector type=123 no=1削除指示をＸＭＬパーサ１６に出す。ＸＭＬパーサ１６は、<sector type="128" no="1"/>なる要素をdatacontrol要素から削除する。
【００４５】
ダウンロード処理部１４は上述のように使用セクタを通知したのちには、ステップＳａ６において、ダウンロードデータを使用セクタへ書き込む。具体的にはドライバ１２は、データ領域１１ｂのうちの使用セクタとされているセクタへ、上記のダウンロードデータを書き込む。
【００４６】
このようにダウンロードデータの書き込みが行われる状態にてダウンロード処理部１４は、ステップＳａ７およびステップＳａ８にてファイルのダウンロードが完了するか、あるいは使用セクタが満杯となるのを待ち受ける。もし、使用セクタが満杯となったならば、ダウンロード処理部１４はステップＳａ８からステップＳａ９へ進む。ステップＳａ９においてダウンロード処理部１４は、管理情報作成部１５へ満杯通知を行う。この上でダウンロード処理部１４は、ステップＳａ３以降の処理を繰り返すことにより、使用セクタを変更しつつデータのダウンロードと、このデータのフラッシュＲＯＭ１１への書き込みとを繰り返す。
【００４７】
さて、管理情報作成部１５は、上述のようにダウンロード処理部１４から満杯通知がなされるとき、ステップＳｂ５およびステップＳｂ６の待ち受け状態にある。このため管理情報作成部１５は、上記の満杯通知がなされたことに応じて、ステップＳｂ６からステップＳｂ７へ進む。ステップＳｂ７において管理情報作成部１５は、使用セクタの情報とデータ量とを示した要素を、管理領域１１ａに保存されているファイル管理情報にＸＭＬパーサ１６およびドライバ１２を使用して追加する。この上で管理情報作成部１５は、ステップＳｂ３の待ち受け状態に戻る。
【００４８】
図７は図５に示す情報に使用セクタの情報とデータ量とを示した要素を追加したのちの情報の一例を示す図である。  
図７中のfilecontrol要素に含まれたsector要素が使用セクタの情報とデータ量とを示した要素に相当する。図７の例では、no.1の128Kbyteセクタに128Kbyteのデータを書き込んだことを示す。
【００４９】
管理情報作成部１５は、ダウンロード処理部１４の制御の下に、使用セクタを変更しつつファイルのダウンロードと、このファイルのフラッシュＲＯＭ１１への書き込みとが継続される間、ステップＳｂ３乃至ステップＳｂ７を繰り返す。これにより、filecontrol要素にはsector要素が順次追加されて行く。また、datacontrol要素からは、sector要素が順次削除されて行く。
【００５０】
さて、使用セクタが満杯になる前にファイルのダウンロードが完了した場合には、ダウンロード処理部１４はステップＳａ７からステップＳａ１０へ進む。ステップＳａ１０においてダウンロード処理部１４は、管理情報作成部１５へ終了通知を行う。そしてこれをもってダウンロード処理部１４は、ダウンロード処理を終了する。
【００５１】
上記の終了通知がなされたことに応じて、ステップＳｂ５からステップＳｂ８へ進む。ステップＳｂ８において管理情報作成部１５は、使用セクタの情報とデータ量とを示した要素を、管理領域１１ａに保存されているファイル管理情報に追加する。具体例としては、ステップＳｂ７と同様にfilecontrol要素にsector要素を追加する。次にステップＳｂ９において管理情報作成部１５は、データ領域の全使用容量および全空き容量を計算し、この計算結果を反映するようにデータ領域管理情報を更新する。更新は、ＸＭＬパーサ１６およびドライバ１２を使用して行う。具体例としては、128Kbyteセクタおよび16Kbyteセクタの全使用容量を計算してdatacontrol要素内のusesize要素の内容を更新し、128Kbyteセクタおよび16Kbyteセクタの全空き容量をそれぞれ計算してdatacontrol要素内のavailablesize要素の内容を更新する。この結果、ステップＳｂ９が行われた後には、管理領域１１ａに記憶される情報は例えば図８に示すようなものとなる。  
そしてこれをもって管理情報作成部１５は、管理情報作成処理を終了する。
【００５２】
ダウンロードファイルの削除要求がなされた場合には、該当ファイルのファイル管理情報のセクタの情報（sector要素）で示された各セクタをセクタ単位でイレーズして行き、イレーズが完了したセクタの情報（sector要素）をデータ領域管理情報に追加して行く。このあと、データ領域管理情報の全使用容量および全空き容量の情報を更新し、最後に該当ファイルのファイル管理情報（filecontrol要素）を全て削除する。
【００５３】
ダウンロード処理部１４やアプリケーション処理部１７が管理領域１１ａに保存された管理情報を参照する場合、その要求はＸＭＬパーサ１６に与えられる。ＸＭＬパーサ１６は、ダウンロード処理部１４やアプリケーション処理部１７が必要とする情報を記述した要素をドライバ１２を介して管理領域１１ａから取り出し、ダウンロード処理部１４やアプリケーション処理部１７で使用するのに適した形態のデータに変換してダウンロード処理部１４やアプリケーション処理部１７へ与える。このときにＸＭＬパーサ１６は、要素名を利用して管理領域１１ａから必要な要素を取り出す。
【００５４】
以上のように本実施形態によれば、管理情報をＸＭＬにより記述しているため、この管理情報内で示すべき個々の属性をそれぞれ示す要素の順番には意味がない。例えば、図９（ａ）に示す記述および図９（ｂ）に示す記述は、全く同じ内容を示す。従って、要素の追加や省略は自由に行え、管理情報内で示すべき個々の属性の増加や減少に柔軟に対応できる。
【００５５】
また、１つの属性に関する記述形式を変更する場合にも容易に対応できる。例えばセクタに記憶するデータの管理を、データ量から開始位置および終了位置に変更する場合、startposition要素およびendposition要素を追加して、図１０（ａ）に示す記述から図１０（ｂ）に示す記述に変更すれば良い。
【００５６】
また、要素名により記述された属性値がどのような属性に関するものかを容易に判断可能であるため、管理情報の内容を人間も容易に確認することができる。さらには、既存のＸＭＬビューワなども使用することで、例えば図１１に示すように管理情報の内容を見やすく表示させることが可能である。そしてこのようなＸＭＬビューワを使用することで、管理情報の内容を人間がより容易に確認することができる。
【００５７】
なお、本発明は上記実施形態に限定されるものではない。例えばフラッシュＲＯＭ１１は、電子機器１に内蔵せず、着脱可能としても良い。  
記憶媒体としては、フラッシュＲＯＭ１１とは異なるタイプの半導体メモリや、あるいはハードディスクなどのような半導体メモリ以外の媒体も適用可能である。  
ダウンロード処理および管理情報作成処理は、１つの処理として統合的に行うようにしても良い。  
ダウンロードしたファイルに限らず、どのようなファイルの管理にも本発明を利用できる。  
このほか、本発明の要旨を逸脱しない範囲で種々の変形実施が可能である。
【図面の簡単な説明】
【００５８】
【図１】本発明の一実施形態に係る電子機器１の要部構成を示すブロック図。
【図２】ファイル属性またはデータ領域属性の名前と、ＸＭＬの要素名および記述形式との対応付けの一例を示す図。
【図３】図１中の電子機器１の製造時などに管理情報１１ａに書き込まれるデータ領域管理情報の一例を示す図。
【図４】図１中のダウンロード処理部１４が実行するダウンロード処理および管理情報作成部１５が実行する管理情報作成処理のフローチャート。
【図５】ファイル管理情報が書き込まれたのちに図１中の管理領域１１ａに保存される情報の一例を示す図。
【図６】ファイルのダウンロードの方式を示す図。
【図７】図５に示す情報に使用セクタの情報とデータ量とを示した要素を追加したのちに図１中の管理領域１１ａに保存される情報の一例を示す図。
【図８】データ領域の全使用容量および全空き容量を更新したのちに図１中の管理領域１１ａに保存される情報の一例を示す図。
【図９】図１中の管理領域１１ａに保存される管理情報における要素に順序の自由度を示す図。
【図１０】図１中の管理領域１１ａに保存される管理情報における１つの属性に関する記述形式を変更する例を示す図。
【図１１】図８に示した管理情報をＸＭＬビューワを使用して表示した例を示す図。
【図１２】従来のファイルの管理情報の一例を示す図。
【図１３】従来の管理情報の具体例を示す図。
【図１４】従来のデータ領域におけるファイル保存の様子の一例を示す図。
【図１５】従来のファイル管理システムを実装したオペレーティングシステムの構成例。
【図１６】従来のプログラムがファイルを管理する例を示す図。
【図１７】従来の管理情報の変更の様子を示す図。
【図１８】従来の携帯電話機でゲーム等のアプリケーションをダウンロードする手順を示す図。
【図１９】従来の管理情報の変更の様子を示す図。
【図２０】従来の管理情報のバイトデータでの記述例を示す図。
【図２１】従来の管理情報での項目の追加および削除や記述形式の変更の様子を示す図。
【図２２】従来の管理情報での項目の削除の別の例を示す図。
【符号の説明】
【００５９】
１…電子機器、１１…フラッシュＲＯＭ、１１ａ…管理情報、１１ｂ…データ領域、１２…ドライバ、１３…通信部、１４…ダウンロード処理部、１５…管理情報作成部、１６…ＸＭＬパーサ、１７…アプリケーション処理部。
【図１】
2005135011.tif 000003
【図２】
2005135011.tif 000004
【図３】
2005135011.tif 000005
【図４】
2005135011.tif 000006
【図５】
2005135011.tif 000007
【図６】
2005135011.tif 000008
【図７】
2005135011.tif 000009
【図８】
2005135011.tif 000010
【図９】
2005135011.tif 000011
【図１０】
2005135011.tif 000012
【図１１】
2005135011.tif 000013
【図１２】
2005135011.tif 000014
【図１３】
2005135011.tif 000015
【図１４】
2005135011.tif 000016
【図１５】
2005135011.tif 000017
【図１６】
2005135011.tif 000018
【図１７】
2005135011.tif 000019
【図１８】
2005135011.tif 000020
【図１９】
2005135011.tif 000021
【図２０】
2005135011.tif 000022
【図２１】
2005135011.tif 000023
【図２２】
2005135011.tif 000024