JP2006139439A - 情報処理装置、情報処理方法、及びプログラム - Google Patents
情報処理装置、情報処理方法、及びプログラム Download PDFInfo
- Publication number
- JP2006139439A JP2006139439A JP2004327256A JP2004327256A JP2006139439A JP 2006139439 A JP2006139439 A JP 2006139439A JP 2004327256 A JP2004327256 A JP 2004327256A JP 2004327256 A JP2004327256 A JP 2004327256A JP 2006139439 A JP2006139439 A JP 2006139439A
- Authority
- JP
- Japan
- Prior art keywords
- file
- data
- information
- cluster
- header
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【課題】新規ファイルの記録媒体への記録を効率的なものとする。
【解決手段】ヘッダ部A1−データ部A2-リソース部A3とから成るオリジナルファイルから、ヘッダ部A1又はリソース部A3を変更したヘッダ／リソース編集ファイルを新規生成／保存するのにあたっては、ヘッダ部A1又はリソース部A3については、実際にメディアへのデータの書き込みを実行するが、データ部A2については、オリジナルファイルのデータ部A2を共有する構造となるようにしてFAT領域の内容を変更する処理を実行する。
【選択図】図１０
【解決手段】ヘッダ部A1−データ部A2-リソース部A3とから成るオリジナルファイルから、ヘッダ部A1又はリソース部A3を変更したヘッダ／リソース編集ファイルを新規生成／保存するのにあたっては、ヘッダ部A1又はリソース部A3については、実際にメディアへのデータの書き込みを実行するが、データ部A2については、オリジナルファイルのデータ部A2を共有する構造となるようにしてFAT領域の内容を変更する処理を実行する。
【選択図】図１０
Description
本発明は、記憶媒体に対してデータを記憶して管理するための情報処理装置とその方法に関する。また、このような情報処理装置が実行するプログラムに関する。
例えば、パーソナルコンピュータなどに代表される各種の情報処理装置においては、
記憶媒体に記憶すべきファイルとしてのデータに対する操作の１つとして、ユーザインターフェイスに対する入力などに応じて新規に作成したファイルを、記憶媒体に対して書き込んで記憶（保存）させることが行われる。
このような新規ファイルの記憶媒体への記録については、例えば処理時間や記憶媒体容量などに関してできるだけ効率的に行われるようにすることが求められており、このための構成の１つが特許文献１に示されている。
記憶媒体に記憶すべきファイルとしてのデータに対する操作の１つとして、ユーザインターフェイスに対する入力などに応じて新規に作成したファイルを、記憶媒体に対して書き込んで記憶（保存）させることが行われる。
このような新規ファイルの記憶媒体への記録については、例えば処理時間や記憶媒体容量などに関してできるだけ効率的に行われるようにすることが求められており、このための構成の１つが特許文献１に示されている。
特許文献１では、例えば記憶媒体である磁気テープにファイルＡが記憶済みとされている状態のもとで、ファイルＢを追加的に書き込むようにしているが、ここで、ファイルＢは、その冒頭部分についてはファイルＡの後ろ側の一部と重複するようにして形成されてる形態が示されている。この場合において、ファイルＡについては通常のＦＡＴなどのファイルシステムにより管理されるのに対して、ファイルＢについては、開始／終了タイムコード、開始／終了巻径などによりファイルの記録位置を管理することで、上記のようなファイルＢの追加記録を可能としている。
本発明としても、記憶媒体への新規ファイルの記録に関してこれまでよりも効率的なものとなることをその課題とする。
例えばファイルの実際としては、複数の情報体の集合から成る場合が通常である。あくまでも具体例であるが、或る動画ファイルなどは、先頭のヘッダ領域と、これに続くデータ領域、また、このデータ領域を形成する単位データをプレゼンテーションする情報などを格納するリソース領域との、３つの情報体を所定順に配列して形成される。本発明では、このような情報体の集合構造から成るファイルを対象として、効率的な新規ファイルの生成／保存、管理が行われるようにする。
例えばファイルの実際としては、複数の情報体の集合から成る場合が通常である。あくまでも具体例であるが、或る動画ファイルなどは、先頭のヘッダ領域と、これに続くデータ領域、また、このデータ領域を形成する単位データをプレゼンテーションする情報などを格納するリソース領域との、３つの情報体を所定順に配列して形成される。本発明では、このような情報体の集合構造から成るファイルを対象として、効率的な新規ファイルの生成／保存、管理が行われるようにする。
そこで本発明としては、情報処理装置として次のように構成する。
本発明の情報処理装置は、所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規のファイルである新規ファイルとしての内容を生成する新規ファイル生成手段と、この新規ファイル生成手段により生成された新規ファイルの内容を記憶媒体に書き込んで記憶させる書き込み手段と、記憶媒体に記憶されるファイルについて管理する管理手段とを備える。
そして、上記書き込み手段は、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むようにされる。また、上記管理手段は、書き込み手段により書き込まれた書込対象情報部と、原ファイルにおいて未変更情報部と同一とされる内容を有する情報部である引用情報部とにより、新規ファイルが形成されるものとして管理するようにされる。
本発明の情報処理装置は、所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規のファイルである新規ファイルとしての内容を生成する新規ファイル生成手段と、この新規ファイル生成手段により生成された新規ファイルの内容を記憶媒体に書き込んで記憶させる書き込み手段と、記憶媒体に記憶されるファイルについて管理する管理手段とを備える。
そして、上記書き込み手段は、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むようにされる。また、上記管理手段は、書き込み手段により書き込まれた書込対象情報部と、原ファイルにおいて未変更情報部と同一とされる内容を有する情報部である引用情報部とにより、新規ファイルが形成されるものとして管理するようにされる。
また、情報処理方法としては、所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規のファイルである新規ファイルとしての内容を生成する新規ファイル生成手順と、この新規ファイル生成手順により生成された新規ファイルの内容を上記記憶媒体に書き込んで記憶させる書き込み手順と、記憶媒体に記憶されるファイルについて管理する管理手順とを実行するようにされる。
そして、書き込み手順は、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むように構成する。また、管理手順は、書き込み手順により書き込まれた書込対象情報部と、原ファイルにおいて未変更情報部と同一とされる内容を有する情報部である引用情報部とにより新規ファイルが形成されるものとして管理するようにされる。
そして、書き込み手順は、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むように構成する。また、管理手順は、書き込み手順により書き込まれた書込対象情報部と、原ファイルにおいて未変更情報部と同一とされる内容を有する情報部である引用情報部とにより新規ファイルが形成されるものとして管理するようにされる。
また、プログラムとして、上記情報処理方法としての手順を情報処理装置に実行させるように構成することとした。
上記各構成によると、本発明が対応するファイルとしては複数の情報部により形成される形式を有するものを前提としている。
そのうえで、記憶媒体に記憶済みであった原ファイルにおける所要の或る情報部の内容を変更して作成した新規ファイルを記憶媒体に記憶して管理するのにあたっては、先ず、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、この未変更情報部以外の情報部を、書込対象情報部として、実際に記憶媒体に書き込んで記憶させることとしている。つまり、この未変更情報部以外の情報部（書込対象情報部）については、実際のデータ書き込みが実行される。
また、これとともに、新規ファイルについては、上記のようにして実際に書き込みが行われた未変更情報部以外の情報部と、原ファイルにおいて未変更情報部と同一の内容を有する情報部（引用情報部）とにより、新規ファイルが形成されるものとして管理するようにされる。
このような処理が実行される結果、新規ファイルは、実際に書き込みが行われた未変更情報部以外の情報部（書込対象情報部）と、本来は原ファイルを形成するデータ部分である、未変更情報部と同一内容の情報部とにより形成されることになる。つまり、新規ファイルは、未変更部領域については、原ファイルにおける該当の情報部を引用、共有することでファイルとしての全体構造を形成する。
そのうえで、記憶媒体に記憶済みであった原ファイルにおける所要の或る情報部の内容を変更して作成した新規ファイルを記憶媒体に記憶して管理するのにあたっては、先ず、新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、この未変更情報部以外の情報部を、書込対象情報部として、実際に記憶媒体に書き込んで記憶させることとしている。つまり、この未変更情報部以外の情報部（書込対象情報部）については、実際のデータ書き込みが実行される。
また、これとともに、新規ファイルについては、上記のようにして実際に書き込みが行われた未変更情報部以外の情報部と、原ファイルにおいて未変更情報部と同一の内容を有する情報部（引用情報部）とにより、新規ファイルが形成されるものとして管理するようにされる。
このような処理が実行される結果、新規ファイルは、実際に書き込みが行われた未変更情報部以外の情報部（書込対象情報部）と、本来は原ファイルを形成するデータ部分である、未変更情報部と同一内容の情報部とにより形成されることになる。つまり、新規ファイルは、未変更部領域については、原ファイルにおける該当の情報部を引用、共有することでファイルとしての全体構造を形成する。
このことから、本発明としては、新規ファイルを記憶媒体に書き込んで記憶（保存）させるのにあたり、上記未変更情報部の内容については、実際に記憶媒体に書き込む必要は無いこととなる。これにより、未変更情報部の内容を含む新規ファイルを成す全ての内容を書き込む場合と比較して、新規ファイル保存のための書き込み処理に要する時間は短縮される。また、原ファイルと新規ファイルとで１つの情報部を共有することにもなるので、その分の記憶媒体の記憶可能容量を節約できることになる。このようにして、本発明は新規ファイルの記憶媒体への記録を効率的なものとしている。
以下、本発明を実施するための最良の形態（以下、実施の形態という）について説明する。本実施の形態としては、本発明としての情報処理装置の構成をデジタルビデオカメラに適用した場合を例に挙げることとする。
図１は、本実施の形態としてのデジタルビデオカメラ１の構成例を示すブロック図である。
この図に示すデジタルビデオカメラ１において、光学系部２は、撮像レンズ、絞りなどを備えて成り、入射された光を撮像光として、光電変換部３に結像させる。また、光学系部２においては、フォーカス（焦点）調整のためのフォーカス調整機構や、絞り値に応じて絞りを可変する絞り可変機構などを備えているものとされ、このような機構部の駆動は、カメラ機能部６から出力される駆動信号によって行われる。カメラ機能部６は、ＣＰＵ１０の制御に応じて、しかるべきフォーカス状態や絞りの状態等が得られるように所要の駆動信号を出力するようにされている。
また、例えば光学ズーム機能を与えることとした場合には、光学系部２においてズームレンズを移動させるズーム機構を設けると共に、上記と同様にして、ＣＰＵ１０の制御に応じて上記ズーム機構を移動させる駆動部を設けるようにすればよい。さらに、カメラ機能部６として、ストロボを設けたうえで、ストロボ発光機能を与えるように構成することもできる。
この図に示すデジタルビデオカメラ１において、光学系部２は、撮像レンズ、絞りなどを備えて成り、入射された光を撮像光として、光電変換部３に結像させる。また、光学系部２においては、フォーカス（焦点）調整のためのフォーカス調整機構や、絞り値に応じて絞りを可変する絞り可変機構などを備えているものとされ、このような機構部の駆動は、カメラ機能部６から出力される駆動信号によって行われる。カメラ機能部６は、ＣＰＵ１０の制御に応じて、しかるべきフォーカス状態や絞りの状態等が得られるように所要の駆動信号を出力するようにされている。
また、例えば光学ズーム機能を与えることとした場合には、光学系部２においてズームレンズを移動させるズーム機構を設けると共に、上記と同様にして、ＣＰＵ１０の制御に応じて上記ズーム機構を移動させる駆動部を設けるようにすればよい。さらに、カメラ機能部６として、ストロボを設けたうえで、ストロボ発光機能を与えるように構成することもできる。
光電変換部３は、例えば光電変換素子であるＣＣＤ(Charge Coupled Device)を備えて構成され、光学系部２から入射されて受光面にて結像された撮像光を光電変換することで撮像信号を生成してビデオ信号処理部４に出力する。撮影時においては、例えば露出設定結果に応じて決定されるシャッター速度の指示が、ＣＰＵ１０からビデオ信号処理部４に通知される。ビデオ信号処理部４では、通知されたシャッター速度に対応する走査タイミング信号を光電変換部３に出力する。光電変換部３は、この走査タイミング信号に応じて走査を行うようにして、光電変換処理を実行して映像信号を出力するようにされる。
ビデオ信号処理部４は、光電変換部３から入力されたアナログのビデオ信号（撮像画像信号）について、例えばゲイン調整、サンプルホールド処理を施すことによって波形整形を行ったうえで、Ａ／Ｄ変換を行うことで、デジタルとしてのビデオ信号データに変換する。そして、この変換処理によって得られたデジタルビデオ信号について、例えば、表示用輝度データの生成処理などをはじめ、表示部７にて表示が行われるようにするためのビデオ信号処理を実行する。これに伴い、ビデオ信号処理部４では、ＣＰＵ１０の制御に応じてキャラクタ画像なども撮像画像に重畳して表示可能なように、いわゆるオンスクリーンディスプレイのための信号処理も実行可能とされている。
表示部７として採用される実際のディスプレイデバイスについては特に限定されるべきものではないが、現状においては、広く液晶ディスプレイパネルが採用されている。
表示部７として採用される実際のディスプレイデバイスについては特に限定されるべきものではないが、現状においては、広く液晶ディスプレイパネルが採用されている。
また、ビデオ信号処理部４は、光電変換部３から入力されたアナログビデオ信号を変換して得たデジタルビデオ信号について、例えば所定方式による圧縮符号化処理を施して、圧縮ビデオデータを生成することが可能とされている。
また、本実施の形態のデジタルビデオカメラは、スチルカメラ機能も備える。つまり、撮像画像信号について、写真としての所定形式による静止画データファイルを生成することが可能とされているが、このような画像処理も、ビデオ信号処理部４によって行われる。
また、本実施の形態のデジタルビデオカメラは、スチルカメラ機能も備える。つまり、撮像画像信号について、写真としての所定形式による静止画データファイルを生成することが可能とされているが、このような画像処理も、ビデオ信号処理部４によって行われる。
また、ビデオ信号処理部４では、光電変換部３から入力された画像（映像）信号や、後述するメディアから読み出されたＡＶ(Audio Video)データのファイル（ＡＶファイル）などを、所定方式のアナログビデオ信号又はデジタルビデオ信号に変換して、画像入出力部５を介して外部機器などに出力可能とされている。
画像入出力部５は、外部から所定方式のビデオ信号を入力可能ともされており、この入力したビデオ信号をビデオ信号処理部４の処理を経て表示部７に表示させることが可能とされる。また、ビデオ信号処理部４は、画像入出力部５が入力したビデオ信号について、光電変換部３から入力されたアナログビデオ信号と同様にして、記録用データに変換してメディアコントローラ１３に転送することもできる。
これに対応して、画像入出力部５は、例えば所定方式に従った映像（画像）信号出力端子／映像信号入力端子を備える。
画像入出力部５は、外部から所定方式のビデオ信号を入力可能ともされており、この入力したビデオ信号をビデオ信号処理部４の処理を経て表示部７に表示させることが可能とされる。また、ビデオ信号処理部４は、画像入出力部５が入力したビデオ信号について、光電変換部３から入力されたアナログビデオ信号と同様にして、記録用データに変換してメディアコントローラ１３に転送することもできる。
これに対応して、画像入出力部５は、例えば所定方式に従った映像（画像）信号出力端子／映像信号入力端子を備える。
また、本実施の形態のデジタルビデオカメラ１は、音声処理部８及び音声入出力部９を備えることで、音声信号の入出力も可能とされている。
先ず、音声入力については、音声入出力部９としてマイクロフォンなどを備え、外部音声の収音を行って音声信号に変換して音声を入力するようにされる。そして、このようにして入力した音声信号を音声処理部８に出力する。音声処理部８は、例えば、撮像画像の圧縮符号化に対応する音声圧縮符号化方式により符号化された圧縮オーディオデータに変換するなどの音声信号処理を施す。
先ず、音声入力については、音声入出力部９としてマイクロフォンなどを備え、外部音声の収音を行って音声信号に変換して音声を入力するようにされる。そして、このようにして入力した音声信号を音声処理部８に出力する。音声処理部８は、例えば、撮像画像の圧縮符号化に対応する音声圧縮符号化方式により符号化された圧縮オーディオデータに変換するなどの音声信号処理を施す。
ＣＰＵ１０は、画像信号処理部４により得られた撮像画像についての圧縮ビデオデータと、音声処理部８により得られた収音音声についての圧縮オーディオデータとにより、所定形式のＡＶファイルを形成するための制御処理を実行するようにされる。このＡＶファイルは、圧縮ビデオデータを再生して出力される動画像に対して、圧縮オーディオデータを再生して出力される音声の再生時間軸が同期したものとなっている。なお、実際にＡＶファイルを形成するための構成としては、ＣＰＵ１０がプログラムを実行して得られるデジタル信号処理となるソフトウェア構成とされてもよいし、あるいは、ＡＶファイルを形成するためのハードウェアを備えるとともに、ＣＰＵ１０がこのハードウェアについての動作を制御する構成としてもよい。
上記ＡＶファイルとしてのデータは、記録用データとして、例えばＣＰＵ１０の制御によってメディアコントローラ１３に転送される。また、ＣＰＵ１０は、ビデオ信号処理部４によって生成された写真画像としての所定形式の静止画データファイルについても、記録用データとしてメディアコントローラ１３に転送することができる。
上記ＡＶファイルとしてのデータは、記録用データとして、例えばＣＰＵ１０の制御によってメディアコントローラ１３に転送される。また、ＣＰＵ１０は、ビデオ信号処理部４によって生成された写真画像としての所定形式の静止画データファイルについても、記録用データとしてメディアコントローラ１３に転送することができる。
音声入出力部９としては、音声信号入力端子などを備えて外部のオーディオ機器などからオーディオ信号を入力するようにも構成することができる。上記音声信号入力端子から入力されたオーディオ信号については、音声処理部８は、所定形式によるデジタルオーディオデータファイルに変換するようにされる。ＣＰＵ１０は、このようなデジタルオーディオデータファイルのデータについても、記録用データとしてメディアコントローラ１３に転送することができる。
メディアコントローラ１３は、ＣＰＵ１０との連携により、所定の異なる種別の外部のメディア（記憶媒体）、外部記憶デバイス（記憶装置）に対応して、これらのメディアに対するデータ処理に関する制御処理を実行可能に構成される。ここでいうメディアに対するデータ処理とは、メディアのフォーマット処理や、メディアの記憶領域に対するファイル及びファイル管理のための情報（ファイル管理情報）などの書き込み／読み出し処理など、メディアに記憶されるべきデータに関連する何らかの処理をいう。
本実施の形態では、メディアコントローラ１３に対しては、先ず、ハードディスクドライブ（ＨＤＤ）が接続されている。ＨＤＤは、周知のようにしてハードディスクといわれる、記憶媒体として磁気ディスクを備える記憶デバイスであり、現状においては、比較的低コストでギガバイトクラスの大容量が得られる。また、周知のようにして、記憶媒体である磁気ディスクに対する物理的なデータの読み出し／書き込みは、磁気ヘッドにより、磁気ディスク上に形成されるトラックをトレースしながら磁界印加、磁界検出を行うことによって実現される。
また、この場合のＨＤＤとしては、例えばデジタルビデオカメラ１に固定的に内蔵されるものとしてもよいし、デジタルビデオカメラ１（ホスト）に対して装脱可能な、所定の規格に従ったリムーバブル形態とされてもよい。
また、この場合のＨＤＤとしては、例えばデジタルビデオカメラ１に固定的に内蔵されるものとしてもよいし、デジタルビデオカメラ１（ホスト）に対して装脱可能な、所定の規格に従ったリムーバブル形態とされてもよい。
また、この図では、メディアコントローラ１３は、所定方式の光ディスク、光磁気ディスク、及び半導体メモリ素子を備える記憶デバイスである半導体記憶装置などにも対応してデータ処理が可能であることとされている。
光ディスク及び光磁気ディスクなどに対応する場合の実際としては、これらの記録（記憶）媒体に対応してデータの書き込み／読み出しが可能に構成されたドライブとしてのデバイスを備え、これらのデバイスとメディアコントローラ１３とを接続することになる。
また、半導体記憶装置に対応する場合は、半導体記憶装置の実際の規格に従って、この半導体記憶装置が装脱されるスロットを、デジタルビデオカメラ１の本体に備える。このスロットに対して半導体記憶装置が適正に装填されると、半導体記憶装置のピン端子がスロットのコネクタ部位の電極と接続され、これにより、半導体記憶装置は、メディアコントローラ１３との間で通信が可能に接続されることになる。
光ディスク及び光磁気ディスクなどに対応する場合の実際としては、これらの記録（記憶）媒体に対応してデータの書き込み／読み出しが可能に構成されたドライブとしてのデバイスを備え、これらのデバイスとメディアコントローラ１３とを接続することになる。
また、半導体記憶装置に対応する場合は、半導体記憶装置の実際の規格に従って、この半導体記憶装置が装脱されるスロットを、デジタルビデオカメラ１の本体に備える。このスロットに対して半導体記憶装置が適正に装填されると、半導体記憶装置のピン端子がスロットのコネクタ部位の電極と接続され、これにより、半導体記憶装置は、メディアコントローラ１３との間で通信が可能に接続されることになる。
メディアコントローラ１３は、先に説明したようにして、記録用データが転送されてくるのに応じて、この記録用データを、メディアコントローラ１３と接続されているメディア（記憶媒体、記憶装置）のうちから対象として選択されているメディアに対してさらに転送する。データが転送されたメディアでは、メディアコントローラ１３側からの指示に応じて記憶領域に対してデータを書き込んで記憶させる。このようにしてメディアに記憶されるデータがファイルとして記憶管理されることになる。なお、メディアに記憶されるファイルの管理は所定方式のファイルシステムによって行われる。
また、例えばメディアに記憶されているファイルについての再生として、ＡＶファイルを再生するときには、ＣＰＵ１０及びメディアコントローラ１３は、指定されたＡＶファイルにアクセスして読み出しを行う。このようにして読み出されるＡＶファイルは、例えばＣＰＵ１０の処理により、圧縮ビデオデータと圧縮オーディオデータとに分離され、圧縮ビデオデータについてはビデオ信号処理部４に受け渡し、圧縮オーディオ信号については、音声処理部８に受け渡すようにされる。
この場合のビデオ信号処理部４及び音声処理部８は、それぞれ、上記のようにして転送されてきた圧縮ビデオデータ、圧縮オーディオデータについて、復調処理を含む所要の再生信号処理を実行する。これにより、圧縮ビデオデータを再生した画像を表示部７にて表示するとともに、この画像の再生時間に同期して、圧縮オーディオデータを再生して得られる音声信号を、音声入出力部９が有するとされるスピーカにより音声として出力させたり、ヘッドフォン端子から出力させることができる。
この場合のビデオ信号処理部４及び音声処理部８は、それぞれ、上記のようにして転送されてきた圧縮ビデオデータ、圧縮オーディオデータについて、復調処理を含む所要の再生信号処理を実行する。これにより、圧縮ビデオデータを再生した画像を表示部７にて表示するとともに、この画像の再生時間に同期して、圧縮オーディオデータを再生して得られる音声信号を、音声入出力部９が有するとされるスピーカにより音声として出力させたり、ヘッドフォン端子から出力させることができる。
また、例えばメディアから再生されたオーディオデータファイルは、音声処理部８の音声信号処理を経た後に、音声入出力部９を介して、外部に対して所定形式のオーディオ信号、オーディオデータとして出力することも可能とされている。この場合、音声入出力部９としては、音声処理部８から出力される所定のオーディオ信号、オーディオデータの形式に対応するオーディオ出力端子を備えることになる。
ＣＰＵ(Central Processing Unit)１０は、プログラムを実行することでデジタルビデオカメラ１についての各種制御処理を実行する。ＲＯＭ１１は、ＣＰＵ１０が実行する各種プログラムのほか、ＣＰＵ１０が処理を実行するのに使用する各種設定情報などが記憶されている。ＲＡＭ１２は、ＣＰＵ１０がプログラムに従った処理を実行するときの作業領域として使用されるもので、各種の演算処理結果などのデータが保持される。
この場合の操作入力部１５は、デジタルビデオカメラ１に備えられる各種操作子を一括して示しているものとされる。例えば、この操作入力部１５における操作子としては、写真撮影時に操作されるシャッターボタン、撮影モードなどを選択する操作子、パラメータのアップ／ダウンを行うための操作子などが含まれる。
通信部１６は、ＣＰＵ１０の制御に応じて、所定のデータ通信方式により外部デバイスと通信を行うためのハードウェア、ソフトウェアを実装して構成される部位である。この通信部１６が対応するデータ通信方式としては、有線、無線を問わず特に限定されるべきものではなく、また、対応するデータ通信方式の数も限定されるべきものでない。現状であれば、データ通信方式としては、有線ではEthernet（商標）などのネットワーク、ＵＳＢ(Universal Serial Bus)、IEEE1394などのデータバス規格などを挙げることができる。また、無線であれば、Bluetooth（商標）などのデバイス間近距離無線通信、IEEE802.11a/b/gなどの無線ＬＡＮ(Local Area Network)規格を挙げることができる。
電源部１７は、デジタルビデオカメラ１における各種のハードウェアデバイスに対して動作電源を供給するもので、例えばバッテリや電源アダプタからの電力供給を受けて動作する電源回路などを備えて構成される。
上記のようにして、本実施の形態のデジタルビデオカメラ１では、主としては、撮像／収音により得られるＡＶファイルを、ＨＤＤ、各種光学ディスク状記録媒体（光磁気ディスクを含む）、半導体記憶装置などのメディア（記憶媒体）に対して記憶させることができるようになっている。
上記のようにしてメディアに記憶されるファイルは、通常は、所定フォーマットによるファイルシステムにより管理されることになるのであるが、本実施の形態としては、ＦＡＴ(File Allocation Table)ファイルシステムにより管理されるものとしている。ＦＡＴファイルシステムは、周知のようにして、ツリー型のディレクトリ構造によりファイルを管理するようにされており、また、データの書き込み／読み出しについては、クラスタといわれる論理的な最小データ管理単位により行うものとされている。クラスタは、メディアにおける物理的なデータ書き込み／読み出しの最小単位であるセクタを所定数にまとめたものが１単位となる。
上記のようにしてメディアに記憶されるファイルは、通常は、所定フォーマットによるファイルシステムにより管理されることになるのであるが、本実施の形態としては、ＦＡＴ(File Allocation Table)ファイルシステムにより管理されるものとしている。ＦＡＴファイルシステムは、周知のようにして、ツリー型のディレクトリ構造によりファイルを管理するようにされており、また、データの書き込み／読み出しについては、クラスタといわれる論理的な最小データ管理単位により行うものとされている。クラスタは、メディアにおける物理的なデータ書き込み／読み出しの最小単位であるセクタを所定数にまとめたものが１単位となる。
図２は、ＦＡＴファイルシステムの一般的なシステム構成を階層モデルにより示している。
先ず、この階層モデルとしては、ソフトウェア層と、その下層となるハードウェア層に大別される。
ソフトウェア層は、この場合には、メディアに対してホスト（実施の形態ではデジタルビデオカメラ１）となるデバイスにおいて、ＣＰＵが実行するプログラム、及び各種ファームウェア、ミドルウェアなどにより実現されるソフトウェア処理が対応するものとされる。この場合のソフトウェア層は、図示するように、上層から下層にかけて、アプリケーション１００、ファイルシステム１０１、デバイスドライバ１０２の各層が位置する。
ハードウェア層には、メディアそのものの物理的な記憶領域が位置するものとして考えることができる。
先ず、この階層モデルとしては、ソフトウェア層と、その下層となるハードウェア層に大別される。
ソフトウェア層は、この場合には、メディアに対してホスト（実施の形態ではデジタルビデオカメラ１）となるデバイスにおいて、ＣＰＵが実行するプログラム、及び各種ファームウェア、ミドルウェアなどにより実現されるソフトウェア処理が対応するものとされる。この場合のソフトウェア層は、図示するように、上層から下層にかけて、アプリケーション１００、ファイルシステム１０１、デバイスドライバ１０２の各層が位置する。
ハードウェア層には、メディアそのものの物理的な記憶領域が位置するものとして考えることができる。
アプリケーション１００は、例えばファイルの記録／再生機能などを有して、メディアを使用するアプリケーションソフトウェアが対応し、ファイルレベルでのアクセス要求をファイルシステム１０１に対して行う。
ファイルシステム１０１は、ファイルシステムとしての機能を実現するソフトウェアが対応する。本実施の形態では、ＦＡＴファイルシステムを採用することとしているので、ファイルシステム１０１の機能を提供するソフトウェアとしても、ＦＡＴファイルシステムに対応して構成されるものとなる。
このファイルシステム１０１では、アプリケーション１００からのファイルレベルによるアクセス要求を、ＦＡＴファイルシステムのフォーマットにおけるデータの管理単位となるクラスタのレベルに変換して、デバイスドライバ１０２に対してアクセス要求を行う。
このファイルシステム１０１では、アプリケーション１００からのファイルレベルによるアクセス要求を、ＦＡＴファイルシステムのフォーマットにおけるデータの管理単位となるクラスタのレベルに変換して、デバイスドライバ１０２に対してアクセス要求を行う。
デバイスドライバ１０２は、コントロール対象のデバイスとなるメディアをコントロールするためのソフトウェアが対応し、上記ファイルシステム１０１からのＦＡＴファイルシステムフォーマットに従ったクラスタレベルによるアクセス要求を、メディア１０３上におけるデータの記録再生単位であるセクタのレベルに変換して、メディア１０３へのアクセス要求を行う。
この場合のメディア１０３は、論理的にはＦＡＴファイルシステムに従ってフォーマット（初期化）されたものとなる。図１では、ＨＤＤ、光学ディスク状記録媒体、半導体記憶装置など、メディアコントローラ１３と接続されている記憶媒体、記憶装置がここでのメディア１０３に相当する。そして、メディア１０３は、デバイスドライバ１０２からのセクタレベルのアクセス要求に応答して、指定されたセクタアドレスからデータを読み出して、デバイスドライバ１０２に返す。つまり、セクタレベルでのアクセス応答を実行する。
デバイスドライバ１０２は、メディア１０３からのセクタレベルでのアクセス応答、つまりセクタ単位でのデータの受け取りを行い、この受け取ったデータについて、クラスタ単位によるデータとして扱ってファイルシステム１０１に受け渡す（クラスタレベルでのアクセス応答）。
ファイルシステム１０１は、デバイスドライバ１０２から受け取ったデータを、ファイルレベルのデータとしてアプリケーション１００に受け渡すようにされる。アプリケーション１００は、ファイルとして受け取ったデータについて、例えばユーザによる操作入力などに応じたアプリケーションレベルでの所要の処理を実行する。
デバイスドライバ１０２は、メディア１０３からのセクタレベルでのアクセス応答、つまりセクタ単位でのデータの受け取りを行い、この受け取ったデータについて、クラスタ単位によるデータとして扱ってファイルシステム１０１に受け渡す（クラスタレベルでのアクセス応答）。
ファイルシステム１０１は、デバイスドライバ１０２から受け取ったデータを、ファイルレベルのデータとしてアプリケーション１００に受け渡すようにされる。アプリケーション１００は、ファイルとして受け取ったデータについて、例えばユーザによる操作入力などに応じたアプリケーションレベルでの所要の処理を実行する。
また、ＦＡＴファイルシステムは、記憶ファイルをツリー型のディレクトリ構造により管理し、また、ファイルをクラスタ単位の集合として管理するようにされている。このようなファイル管理、データ管理は、周知のようにしてディレクトリエントリ、及びＦＡＴといわれるテーブル情報を備えることにより実現されるものとなる。ディレクトリエントリは、メディア上におけるファイル、ディレクトリ（サブディレクトリ）の所在をクラスタレベルで示す情報であり、ＦＡＴは、ディレクトリ、ファイルを成すクラスタレベルでのチェイン（リンク、連結）を示す情報である。
図３は、ＦＡＴの規格に従ったメディアのフォーマット構造を示している。
ＦＡＴの形式としては複数が規定されているのであるが、ここでは、ＦＡＴ１６及びＦＡＴ３２の各形式に対応するフォーマット構造を示すこととする。
先ず、図３の左側に示されるＦＡＴ１６に対応するフォーマット構造から説明する。
この図に示す構造は、ＬＢＡ(Logical Block Addressing)に従った論理的なものとなっている。つまり、最も上を先頭セクタ（LBA=0）として、以降、下に向かってブロック（セクタ）の番号が進んでいくものとなる。
また、ＦＡＴのファイルシステムでは、１つの物理的記憶領域を複数のパーティションに分割可能とされているが、ここでは説明の便宜上、１パーティションとした場合のフォーマット構造を示している。
ＦＡＴの形式としては複数が規定されているのであるが、ここでは、ＦＡＴ１６及びＦＡＴ３２の各形式に対応するフォーマット構造を示すこととする。
先ず、図３の左側に示されるＦＡＴ１６に対応するフォーマット構造から説明する。
この図に示す構造は、ＬＢＡ(Logical Block Addressing)に従った論理的なものとなっている。つまり、最も上を先頭セクタ（LBA=0）として、以降、下に向かってブロック（セクタ）の番号が進んでいくものとなる。
また、ＦＡＴのファイルシステムでは、１つの物理的記憶領域を複数のパーティションに分割可能とされているが、ここでは説明の便宜上、１パーティションとした場合のフォーマット構造を示している。
先ず、LBA=0として表される先頭セクタは、ＭＢＲ(Master Boot Recorder) といわれる、ブート領域となっている。
ＭＢＲの構造を図４（ａ）に示す。
１セクタは５１２バイトのサイズであり、従って、ＭＢＲとしても５１２バイトとなる。図４（ａ）では、このＭＢＲの領域における５１２バイトについて、先頭から最終のバイト位置を、0000h〜01FFhまでの１６進法による番号を振って表現したうえで、１６バイト単位を１列として配列して示している。なお、１６進法の表記を行うのにあたっては、上記0000h、或いは01FFhのようにして、数値の最後尾に１６進法表記であることを示すhを付すこととする。
先ず、バイト位置0000h〜01BDhまでの４４６バイトの領域は、ＯＳ(Operating System)起動用のメディアとして使用される場合において、その起動（ブート：boot）のためのコード（起動コード）が格納される領域である。
１セクタは５１２バイトのサイズであり、従って、ＭＢＲとしても５１２バイトとなる。図４（ａ）では、このＭＢＲの領域における５１２バイトについて、先頭から最終のバイト位置を、0000h〜01FFhまでの１６進法による番号を振って表現したうえで、１６バイト単位を１列として配列して示している。なお、１６進法の表記を行うのにあたっては、上記0000h、或いは01FFhのようにして、数値の最後尾に１６進法表記であることを示すhを付すこととする。
先ず、バイト位置0000h〜01BDhまでの４４６バイトの領域は、ＯＳ(Operating System)起動用のメディアとして使用される場合において、その起動（ブート：boot）のためのコード（起動コード）が格納される領域である。
ＭＢＲにおけるバイト位置01BEh〜01FDhまでの６４バイトの領域は、パーティションテーブルとされており、起動時において必要とされるパーティションごとに関する所定の情報が格納される。このパーティションテーブルの領域は、さらに１６バイト単位で４つの領域に分割されることになっており、これらの４分割された領域は、先頭から順に、パーティション１、パーティション２、パーティション３、パーティション４に対応する領域となっている。これらのこれらのパーティションごとに対応する各領域は、パーティションごとのエントリの領域となる。
また、ＭＢＲにおける最終の２バイトの領域には、現セクタがＭＢＲであることの識別子として55AAhが格納される。
上記パーティションのエントリは、図４（ｂ）に示す構造を有するものとされる。先ず、最上位のバイト位置00hは、該当パーティションについての、起動ドライブとしての指定の有無を示すフラグを格納する領域とされる。
また、続くバイト位置01h〜03hによる３バイトの領域は、該当パーティションの開始セクタをＣＨＳ（Cylinder/Head/Sector）により表現した値が格納される。バイト位置05h〜07hから成る３バイトの領域により、該当パーティションの終了セクタをＣＨＳにより表現した値が格納される。
また、バイト位置08h〜0Bhによる４バイトの領域により、該当パーティションの開始セクタをＬＢＡにより示す値を格納することとしている。
また、続くバイト位置01h〜03hによる３バイトの領域は、該当パーティションの開始セクタをＣＨＳ（Cylinder/Head/Sector）により表現した値が格納される。バイト位置05h〜07hから成る３バイトの領域により、該当パーティションの終了セクタをＣＨＳにより表現した値が格納される。
また、バイト位置08h〜0Bhによる４バイトの領域により、該当パーティションの開始セクタをＬＢＡにより示す値を格納することとしている。
バイト位置0Ch〜0Fhから成る４バイトの領域は、該当パーティションのデータサイズ（パーティションサイズ）を示す値を格納する。
バイト位置04hが示す１バイトの領域は、システム識別子ともいわれる、該当パーティションが対応するプラットフォーム、ファイルシステムなどのタイプを示す値を格納する。
説明を図３に戻す。
ＭＢＲとしての先頭セクタに続けては所定セクタ数による空き領域を設けることとしている。そして、この空き領域より後となるセクタ領域により、パーティション単位の領域を形成する。
ＭＢＲとしての先頭セクタに続けては所定セクタ数による空き領域を設けることとしている。そして、この空き領域より後となるセクタ領域により、パーティション単位の領域を形成する。
１パーティション内における先頭セクタから所定のバイト数までによる領域は、システム関連の情報を格納するシステム領域となる。
このシステム領域において先頭セクタから開始される所定バイト数の領域は、ＢＰＢ(BIOS Parameter Block/Boot Parameter Block)とされ、ここでは現パーティションに関して、例えばホスト側のＢＩＯＳ(Basic Input/Output System)などのように、ブロックデバイスコントロールのためのプログラムが利用すべき所要のデータが格納される。ＢＰＢに格納する情報においては、次に説明するＦＡＴ領域の数、メインのＦＡＴ領域の開始セクタ、ＦＡＴ領域のセクタ数などの情報を含む。
このシステム領域において先頭セクタから開始される所定バイト数の領域は、ＢＰＢ(BIOS Parameter Block/Boot Parameter Block)とされ、ここでは現パーティションに関して、例えばホスト側のＢＩＯＳ(Basic Input/Output System)などのように、ブロックデバイスコントロールのためのプログラムが利用すべき所要のデータが格納される。ＢＰＢに格納する情報においては、次に説明するＦＡＴ領域の数、メインのＦＡＴ領域の開始セクタ、ＦＡＴ領域のセクタ数などの情報を含む。
ＢＰＢに続けてはＦＡＴ１、ＦＡＴ２のＦＡＴ領域が順に配置される。通常は、ＦＡＴ１，２のいずれか一方の領域がメインのＦＡＴ領域として使用され、他方のＦＡＴ領域は、メインＦＡＴ領域の内容をコピーしたミラー領域として使用するなど、例えばメインのＦＡＴ領域の予備領域、バックアップ用領域として使用される。
これらのＦＡＴ領域は、ＦＡＴエントリが、データ領域内のクラスタ番号順に配列されて形成される領域とされる。ＦＡＴエントリと、データ領域内のクラスタとは１対１で対応しており、ＦＡＴエントリには、ディレクトリ、ファイルの記憶結果に応じて、該当クラスタについての情報として、例えば、未使用、該当ファイルにおいて現クラスタの次にチェインされるクラスタ番号、不良クラスタ、EOF(End Of File：ファイルにおける最終クラスタ)などのうちから、何れかを示す情報が格納される。
ＦＡＴ１６フォーマットでは、クラスタ番号を２バイト（１６ビット）により表すこととしており、これに応じて、ＦＡＴエントリの個々のサイズも２バイトとされている。
ＦＡＴ１６フォーマットでは、クラスタ番号を２バイト（１６ビット）により表すこととしており、これに応じて、ＦＡＴエントリの個々のサイズも２バイトとされている。
ＦＡＴ１，ＦＡＴ２の領域に続けては、所定サイズのルートディレクトリエントリが配置される。このルートディレクトリエントリには、ルートディレクトリにおけるディレクトリ、ファイルなどについてのディレクトリエントリが格納される。
ルートディレクトリより下位のセクタ領域が、データ領域となる。このデータ領域に対するデータの書き込み／読み出しは、ＦＡＴファイルシステムにより管理される。従って、図示するようにして、ファイルシステムのフォーマット構造としては、１以上の所定数のセクタの連続から成るクラスタ単位によりデータ領域を管理することになる。上記もしたように、ＦＡＴ領域は、原則として、このデータ領域を形成する全クラスタに対応するＦＡＴエントリを有して形成されるものとなる。
続いては図３の右側に示されるＦＡＴ３２に対応するフォーマット構造について説明する。
ＦＡＴ３２対応のフォーマット構造としても、LBA=0で表される先頭セクタにＭＢＲを配置している。そして、このＭＢＲに続けて配置する所定セクタ数の空き領域に続けて、パーティション単位の領域を配置していくようにされる。
ＦＡＴ３２対応のフォーマット構造としても、LBA=0で表される先頭セクタにＭＢＲを配置している。そして、このＭＢＲに続けて配置する所定セクタ数の空き領域に続けて、パーティション単位の領域を配置していくようにされる。
ＦＡＴ３２対応のフォーマット構造のパーティション領域にけるシステム領域としては、ＢＰＢに続けてＦＳｉｎｆｏの領域を設けることとしている。
ＦＳｉｎｆｏは、該当パーティションにおける空き容量を計算するのに利用する所定の情報を格納する領域である。ＦＡＴ１，ＦＡＴ２のＦＡＴ領域は、ＦＳｉｎｆｏに続けて順次配置される。
ＦＳｉｎｆｏは、該当パーティションにおける空き容量を計算するのに利用する所定の情報を格納する領域である。ＦＡＴ１，ＦＡＴ２のＦＡＴ領域は、ＦＳｉｎｆｏに続けて順次配置される。
ＦＡＴ３２のフォーマットの場合のＦＡＴ領域も、クラスタと１対１で対応するＦＡＴエントリがクラスタ番号順に配列されて形成され、ＦＡＴエントリには、ディレクトリ、ファイルの記憶結果に応じて、該当クラスタについての所定の情報が格納される。ただし、ＦＡＴ３２のフォーマットでは、クラスタ番号を４バイト（３２ビット）で表現することから、ＦＡＴエントリの個々のサイズも４バイトで区切られることになる。
また、ＦＡＴ３２のフォーマット構造においては、ＦＡＴ１６のフォーマット構造においてシステム領域内に設けられていたルートディレクトリエントリの領域が省略されている。
ＦＡＴ３２のフォーマット構造では、ルートディレクトリはデータ領域内におかれることなっている。データ領域におけるルートディレクトリの開始クラスタ番号は、ＢＰＢにおける所定領域（RootClus）に格納される値により示されており、ルートディレクトリにアクセスするときには、上記RootClusを参照して認識したクラスタ番号にアクセスするようにされる。RootClusが示すルートディレクトリの開始クラスタ番号は、通常、２である。
ＦＡＴ３２のフォーマット構造では、ルートディレクトリはデータ領域内におかれることなっている。データ領域におけるルートディレクトリの開始クラスタ番号は、ＢＰＢにおける所定領域（RootClus）に格納される値により示されており、ルートディレクトリにアクセスするときには、上記RootClusを参照して認識したクラスタ番号にアクセスするようにされる。RootClusが示すルートディレクトリの開始クラスタ番号は、通常、２である。
データ領域は、この場合においても、ＦＡＴ３２のファイルシステムによりクラスタ単位でデータの書き込み／読み出しが管理される領域となる。
図５に、ＦＡＴのファイルシステムにおいて規定されるディレクトリエントリの構造を示す。なお、ここでは、ＦＡＴ３２に対応するディレクトリエントリの構造を示している。
この場合、ディレクトリエントリは３２バイトとされている。この図においては、上位バイトから下位バイトまでの各バイト位置を、0h〜1Fhまでの値により示している。
ディレクトリエントリを形成する３２バイトにおいて、最上位のバイト位置0hからバイト位置7hまでの８バイトの領域は、現ディレクトリエントリが示す現ファイル又は現ディレクトリの名称を格納する。
続く下位のバイト位置8hからバイト位置Ahまでの３バイトの領域は、現ファイルのファイル形式に応じた拡張子が格納される。
この場合、ディレクトリエントリは３２バイトとされている。この図においては、上位バイトから下位バイトまでの各バイト位置を、0h〜1Fhまでの値により示している。
ディレクトリエントリを形成する３２バイトにおいて、最上位のバイト位置0hからバイト位置7hまでの８バイトの領域は、現ディレクトリエントリが示す現ファイル又は現ディレクトリの名称を格納する。
続く下位のバイト位置8hからバイト位置Ahまでの３バイトの領域は、現ファイルのファイル形式に応じた拡張子が格納される。
続く下位のバイト位置Bhには、現ファイル／現ディレクトリについての属性を示す値が格納される。
バイト位置Chは、ここでは予約領域とされている。
バイト位置Dh〜Fhまでの３バイトの領域は、現ファイル／現ディレクトリの作成時刻を示す値を格納する。
バイト位置10h−11hによる２バイトの領域は、現ファイル／現ディレクトリの作成日付を示す値を格納する。
バイト位置12h−13hによる２バイトの領域は、現ファイル／現ディレクトリに対するアクセスが最後に行われた日（最終アクセス日付）を示す値を格納する。
バイト位置Chは、ここでは予約領域とされている。
バイト位置Dh〜Fhまでの３バイトの領域は、現ファイル／現ディレクトリの作成時刻を示す値を格納する。
バイト位置10h−11hによる２バイトの領域は、現ファイル／現ディレクトリの作成日付を示す値を格納する。
バイト位置12h−13hによる２バイトの領域は、現ファイル／現ディレクトリに対するアクセスが最後に行われた日（最終アクセス日付）を示す値を格納する。
また、バイト位置14h−15hによる２バイト領域とバイト位置1Ah−1Bhによる２バイト領域との計４バイトの領域によっては、現ファイル／現ディレクトリが記憶されるメディア上の先頭位置をクラスタ番号により示すようにされる。つまり、この計４バイトの領域には現ファイル／現ディレクトリについての先頭クラスタ番号の値が格納される。バイト位置14h−15hによる２バイト領域に対しては、先頭クラスタ番号についての上位４バイトの値を格納する。バイト位置1Ah−1Bhによる２バイト領域に対しては、先頭クラスタ番号についての下位４バイトの値を格納する。
バイト位置16h−17hによる２バイト領域は、現ファイル／現ディレクトリについての記録（最後の更新）が実行された時刻（記録時刻）を示す値を格納する。
バイト位置18h−19hによる２バイト領域は、現ファイル／現ディレクトリについての記録（最後の更新）が実行された日付（記録日付）を示す値を格納する。
バイト位置1Ch〜1Fhまでの４バイトの領域は、現ファイル／現ディレクトリについてのサイズ（容量）を示す値を格納する。
バイト位置18h−19hによる２バイト領域は、現ファイル／現ディレクトリについての記録（最後の更新）が実行された日付（記録日付）を示す値を格納する。
バイト位置1Ch〜1Fhまでの４バイトの領域は、現ファイル／現ディレクトリについてのサイズ（容量）を示す値を格納する。
図６は、ＦＡＴファイルシステムによるファイル管理例を示している。なお、この図においては、ＦＡＴ３２に従ってフォーマットされた場合を示している。
ここでは、データ領域において、少なくともファイルＡ、ファイルＢ、ファイルＣ、ファイルＤが記憶されているものとしたうえで、ファイルＡ，Ｂ，Ｃ，Ｄのディレクトリエントリを、それぞれ図６（ａ）（ｂ）（ｃ）（ｄ）に示す。なお、この図における説明としては、ディレクトリエントリにおける先頭クラスタ番号(バイト位置14h-15h/1Ah-1Bh)
の情報が主要であることから、他の領域の情報については省略している箇所がある。
ここでは、データ領域において、少なくともファイルＡ、ファイルＢ、ファイルＣ、ファイルＤが記憶されているものとしたうえで、ファイルＡ，Ｂ，Ｃ，Ｄのディレクトリエントリを、それぞれ図６（ａ）（ｂ）（ｃ）（ｄ）に示す。なお、この図における説明としては、ディレクトリエントリにおける先頭クラスタ番号(バイト位置14h-15h/1Ah-1Bh)
の情報が主要であることから、他の領域の情報については省略している箇所がある。
また、図６（ｅ）は、ＦＡＴ領域の一部を示すもので、ファイルＡ，Ｂ，Ｃ，Ｄの記憶結果に対応するＦＡＴエントリの内容を有している。なお、この図６（ｅ）においては、図示が簡略でわかりやすくなることを考慮して、ほぼファイルＡ，Ｂ，Ｃ，Ｄのみに対応したＦＡＴエントリ内容のみを抜き出したものとなっている。なお、前述もしたように、ＦＡＴ３２では、個々のＦＡＴエントリは３２ビットのサイズを有する。
また、この図６（ｅ）に示すＦＡＴ領域におけるＦＡＴエントリは、00000000h、00000010h、00000020h、00000030h・・・として示されるように、ＦＡＴエントリに対応するクラスタ番号の値が１桁ごとにインクリメントされる行と、各行が示すクラスタ番号の値に対して足し合わせる最下位桁の値である、＋00h〜＋0Fhが示される列とのマトリクスにより配列されている。例えば、00000000hの行と＋07hの列が交差する位置のＦＡＴエントリは、クラスタ番号00000007hに対応する。
また、この図６（ｅ）に示すＦＡＴ領域におけるＦＡＴエントリは、00000000h、00000010h、00000020h、00000030h・・・として示されるように、ＦＡＴエントリに対応するクラスタ番号の値が１桁ごとにインクリメントされる行と、各行が示すクラスタ番号の値に対して足し合わせる最下位桁の値である、＋00h〜＋0Fhが示される列とのマトリクスにより配列されている。例えば、00000000hの行と＋07hの列が交差する位置のＦＡＴエントリは、クラスタ番号00000007hに対応する。
ＦＡＴファイルシステムにおいては、クラスタ番号00000000h、00000001hで表される先頭クラスタとこれに続く２番目のクラスタの２クラスタは予約領域（RSV）となる。これに応じて、クラスタ番号00000000h、00000001hに対応する各ＦＡＴエントリも予約領域として規定されている。
そして、上記ＦＡＴエントリに格納する値として、現クラスタの次にチェインするクラスタ番号は、00000002h〜0FFFFFF6hで表すこととしている。また、EOF（該当クラスタを含むファイルにおける最終クラスタ（ファイルの終端クラスタ））については、EOF＝0FFFFFFFhにより表すこととしている。また、図６（ｅ）においては、未使用クラスタであることを「−」で示しているが、例えば実際には00000000hの値により表すこととしている。
そして、上記ＦＡＴエントリに格納する値として、現クラスタの次にチェインするクラスタ番号は、00000002h〜0FFFFFF6hで表すこととしている。また、EOF（該当クラスタを含むファイルにおける最終クラスタ（ファイルの終端クラスタ））については、EOF＝0FFFFFFFhにより表すこととしている。また、図６（ｅ）においては、未使用クラスタであることを「−」で示しているが、例えば実際には00000000hの値により表すこととしている。
ファイルＡにアクセスするためには、先ず、図６（ａ）に示すファイルＡのディレクトリエントリにアクセスすることになるが、このファイルＡのディレクトリエントリそのものに対するアクセスは例えば次のようにして行われる。
ファイルアクセスのコマンドが絶対パスによるものである場合を例に挙げると、ファイルＡのディレクトリエントリに対するアクセスのためには、先ず、ルートディレクトリにアクセスし、ここからパスに従ってディレクトリエントリをたどっていくようにされる。また、ディレクトリエントリを辿っていく過程において、或るカレントディレクトリのサブディレクトリを辿ることになる場合があるが、周知のようにして、親ディレクトリと子ディレクトリの親子関係についても、ディレクトリエントリにより表現される。このためには、例えば親ディレクトリ側のディレクトリエントリには、名称として子ディレクトリを示すものを設けておき、この親ディレクトリ側のディレクトリエントリにより示される子ディレクトリのディレクトリエントリには、親ディレクトリが存在することを示す情報を名称の領域に格納したディレクトリエントリを設けるようにされる。これにより、親から子、及び子から親の両方向に対してディレクトリを辿っていくことができる。
そして、上記のようにしてパスに従ってディレクトリエントリをたどる結果、アクセス先として、最終的にはファイルＡのディレクトリエントリに到達することになる。
ファイルアクセスのコマンドが絶対パスによるものである場合を例に挙げると、ファイルＡのディレクトリエントリに対するアクセスのためには、先ず、ルートディレクトリにアクセスし、ここからパスに従ってディレクトリエントリをたどっていくようにされる。また、ディレクトリエントリを辿っていく過程において、或るカレントディレクトリのサブディレクトリを辿ることになる場合があるが、周知のようにして、親ディレクトリと子ディレクトリの親子関係についても、ディレクトリエントリにより表現される。このためには、例えば親ディレクトリ側のディレクトリエントリには、名称として子ディレクトリを示すものを設けておき、この親ディレクトリ側のディレクトリエントリにより示される子ディレクトリのディレクトリエントリには、親ディレクトリが存在することを示す情報を名称の領域に格納したディレクトリエントリを設けるようにされる。これにより、親から子、及び子から親の両方向に対してディレクトリを辿っていくことができる。
そして、上記のようにしてパスに従ってディレクトリエントリをたどる結果、アクセス先として、最終的にはファイルＡのディレクトリエントリに到達することになる。
ファイルＡのディレクトリエントリへのアクセスが行われると、続いては、このファイルＡのディレクトリエントリを起点として、ファイルＡそのものへのアクセスが行われることになる。
ファイルＡそのものへのアクセスとしては、概念的には次のようなものとなる。
ファイルＡにアクセスするためには、ファイルＡのディレクトリエントリにおける先頭（開始）クラスタ番号を取得する。この先頭クラスタ番号は、データ領域においてファイルＡのデータが記憶される開始クラスタ番号を示しており、この場合には、図６（ａ）に示すようにして00000007hとなっている。つまり、この段階で、ファイルＡの開始クラスタ番号が00000007hであることが認識される。
そこで、ファイルシステムは、図６（ｅ）に示すＦＡＴ領域において、クラスタ番号00000007hに対応するＦＡＴエントリにアクセスして、このＦＡＴエントリに格納される値を参照する。この場合、クラスタ番号00000007hに対応するＦＡＴエントリには、00000008hを格納している。これにより、ファイルシステムは、ファイルＡのデータは、クラスタ番号00000007hのクラスタのデータに続けて、クラスタ番号00000008hのクラスタのデータが連結されていることを認識する。そこで、次にクラスタ番号00000008hに対応するＦＡＴエントリにアクセスして参照すると、ここには、00000009hが格納されているので、ファイルＡのデータは、さらにクラスタ番号00000008hのクラスタのデータに続けて、クラスタ番号00000009hのクラスタのデータを連結することが認識される。そこでまた、クラスタ番号00000009hのＦＡＴエントリを参照すると、ここにはEOFを示す値が格納されているので、ファイルＡは、クラスタ番号00000009hのクラスタが終端であることが認識される。
このことから、ファイルＡは、図６（ｆ）のクラスタチェインに示すようにして、クラスタ番号00000007h-00000008h-00000009hの順によるクラスタのデータの連結により形成されることが認識されることになる。ファイルシステムは、クラスタ番号00000007h-00000008h-00000009hのクラスタにアクセスしていくようにされ、これにより、ファイルＡに対するアクセスが行われることになる。
ファイルＡそのものへのアクセスとしては、概念的には次のようなものとなる。
ファイルＡにアクセスするためには、ファイルＡのディレクトリエントリにおける先頭（開始）クラスタ番号を取得する。この先頭クラスタ番号は、データ領域においてファイルＡのデータが記憶される開始クラスタ番号を示しており、この場合には、図６（ａ）に示すようにして00000007hとなっている。つまり、この段階で、ファイルＡの開始クラスタ番号が00000007hであることが認識される。
そこで、ファイルシステムは、図６（ｅ）に示すＦＡＴ領域において、クラスタ番号00000007hに対応するＦＡＴエントリにアクセスして、このＦＡＴエントリに格納される値を参照する。この場合、クラスタ番号00000007hに対応するＦＡＴエントリには、00000008hを格納している。これにより、ファイルシステムは、ファイルＡのデータは、クラスタ番号00000007hのクラスタのデータに続けて、クラスタ番号00000008hのクラスタのデータが連結されていることを認識する。そこで、次にクラスタ番号00000008hに対応するＦＡＴエントリにアクセスして参照すると、ここには、00000009hが格納されているので、ファイルＡのデータは、さらにクラスタ番号00000008hのクラスタのデータに続けて、クラスタ番号00000009hのクラスタのデータを連結することが認識される。そこでまた、クラスタ番号00000009hのＦＡＴエントリを参照すると、ここにはEOFを示す値が格納されているので、ファイルＡは、クラスタ番号00000009hのクラスタが終端であることが認識される。
このことから、ファイルＡは、図６（ｆ）のクラスタチェインに示すようにして、クラスタ番号00000007h-00000008h-00000009hの順によるクラスタのデータの連結により形成されることが認識されることになる。ファイルシステムは、クラスタ番号00000007h-00000008h-00000009hのクラスタにアクセスしていくようにされ、これにより、ファイルＡに対するアクセスが行われることになる。
上記説明から分かるように、データ領域に記憶されるファイルのデータの位置は、ディレクトリエントリに格納される先頭クラスタ番号と、この先頭クラスタ番号を起点として参照するＦＡＴ領域のＦＡＴエントリの内容によって示されており、これらの情報を参照することで、ファイルへのアクセスが可能となっている。
また、データ領域に記憶されるファイルについての、ツリー型ディレクトリ構造による管理は、ディレクトリエントリにより表現されているものであることも分かる。
また、データ領域に記憶されるファイルについての、ツリー型ディレクトリ構造による管理は、ディレクトリエントリにより表現されているものであることも分かる。
そして、残るファイルＢ，Ｃ，Ｄの記憶位置については、上記ディレクトリエントリ及びＦＡＴ領域から成るファイル管理情報により、次のようにして管理されている。
先ず、ファイルＢについては、図６（ｂ）のディレクトリエントリに示すようにして、ファイルの先頭（開始）クラスタのクラスタ番号が0000000Ahであることが示されている。そこで、図６（ｅ）に示すＦＡＴ領域のクラスタ番号0000000Ahに対応するＦＡＴエントリを参照すると、次のクラスタを示すチェイン情報としてクラスタ番号0000001Fhが示されている。そこで、さらにＦＡＴエントリを辿って、クラスタ番号0000001Fhに対応するＦＡＴエントリを参照すると、チェイン情報としてクラスタ番号00000025hが格納されている。クラスタ番号00000025hに対応するＦＡＴエントリには、クラスタ番号00000031hが格納されている。クラスタ番号00000031hに対応するＦＡＴエントリにはクラスタ番号00000030hが格納されている。クラスタ番号00000030hに対応するＦＡＴエントリにはEOFであることを示す値が格納されている。
このようにして、ファイルＢは、ディレクトリエントリ及びＦＡＴ領域により、図６（ｇ）に示すようにして、クラスタ番号0000000Ah-0000001Fh-00000025h-00000031h-00000030hの順に従ったクラスタに記憶されるデータの連結により形成されることが表現される。
先ず、ファイルＢについては、図６（ｂ）のディレクトリエントリに示すようにして、ファイルの先頭（開始）クラスタのクラスタ番号が0000000Ahであることが示されている。そこで、図６（ｅ）に示すＦＡＴ領域のクラスタ番号0000000Ahに対応するＦＡＴエントリを参照すると、次のクラスタを示すチェイン情報としてクラスタ番号0000001Fhが示されている。そこで、さらにＦＡＴエントリを辿って、クラスタ番号0000001Fhに対応するＦＡＴエントリを参照すると、チェイン情報としてクラスタ番号00000025hが格納されている。クラスタ番号00000025hに対応するＦＡＴエントリには、クラスタ番号00000031hが格納されている。クラスタ番号00000031hに対応するＦＡＴエントリにはクラスタ番号00000030hが格納されている。クラスタ番号00000030hに対応するＦＡＴエントリにはEOFであることを示す値が格納されている。
このようにして、ファイルＢは、ディレクトリエントリ及びＦＡＴ領域により、図６（ｇ）に示すようにして、クラスタ番号0000000Ah-0000001Fh-00000025h-00000031h-00000030hの順に従ったクラスタに記憶されるデータの連結により形成されることが表現される。
また、ファイルＣについては、図６（ｃ）に示すようにして、先ず、ファイルＣのディレクトリエントリにおいて、ファイルの先頭（開始）クラスタとしてクラスタ番号0000001Bhが示されている。このことに基づき、図６（ｅ）に示すＦＡＴ領域におけるクラスタ番号0000001BのＦＡＴエントリを起点として参照した内容によっては、ファイルＣは、図６（ｈ）に示すように、クラスタ番号0000001Bh-00000011h-00000012h-00000013h-00000014h-00000003hの順に従ったクラスタに記憶されるデータの連結により形成される。
ファイルＤについては、図６（ｄ）に示すファイルＤのディレクトリエントリにおいて、ファイルの先頭（開始）クラスタとしてクラスタ番号0000002Chが示されている。これに基づいて、図６（ｅ）に示すＦＡＴ領域におけるクラスタ番号0000002CのＦＡＴエントリを起点として参照した内容としては、ファイルＤは、図６（ｉ）に示すように、クラスタ番号0000002Ch-0000002Dh-0000002Eh-0000002Fh-00000038h-00000039h-0000003Ah-0000003Bhの順に従ったクラスタに記憶されるデータの連結により形成される。
これまでに説明したＦＡＴファイルシステムのフォーマット内容をふまえて、先ず、本発明に至った事情について説明しておく。
本実施の形態のデジタルビデオカメラ１によりメディアに記憶させることのできるＡＶ(Audio Video)データファイルのファイルフォーマットの例として、ここでは、ISO Base Media File Format、あるいはMP4 File Formatなどに準拠したものであることとする。これらのフォーマットに従った本実施の形態のＡＶファイルの基本構造としては次のようになる。
本実施の形態のデジタルビデオカメラ１によりメディアに記憶させることのできるＡＶ(Audio Video)データファイルのファイルフォーマットの例として、ここでは、ISO Base Media File Format、あるいはMP4 File Formatなどに準拠したものであることとする。これらのフォーマットに従った本実施の形態のＡＶファイルの基本構造としては次のようになる。
図７には、上記ファイルフォーマットに従ったＡＶファイルとして、ファイルＡ、ファイルＢの２つのファイルが示されている。ここでは、ＡＶファイルの構造についてファイルＡを参照して説明する。
図示するようにして、１つのＡＶファイルは、ヘッダ部Ａ１、データ部Ａ２、及びリソース部Ａ３の３つの領域（情報部）に分けることができる。
ヘッダ部Ａ１は、ファイルの先頭に配置される領域で、ファイル名、ファイルサイズ、再生互換性情報などの他、ヘッダ情報として格納すべき所定の情報が格納される。
データ部Ａ２には、ＡＶファイルを形成するビデオデータ（画像データ）、オーディオデータなどが所定のデータ要素単位により所定規則に従って格納される領域である。例として、ビデオデータとして動画再生に使用されるデータ要素単位であれば、ＪＰＥＧ(Joint Photographic Expert Group)形式などに代表される、所定の画像圧縮方式により圧縮された１つの静止画像データの単位などとなる。
リソース部Ａ３は、上記データ部Ａ２におけるデータ分割単位の位置情報などをはじめ、データ部Ａ２に格納されるデータを再生出力（Presentation）するのに必要とされる所定の情報から成る領域である。ファイル再生にあたっては、このデータ部Ａ２に格納される情報を読み込んで解釈し、解釈結果に従って、データ部Ａ２から指定されるデータ要素単位を読み出してデコード処理を実行していく。これにより、例えば編集意図に従った内容による再生出力が実現される。
図示するようにして、１つのＡＶファイルは、ヘッダ部Ａ１、データ部Ａ２、及びリソース部Ａ３の３つの領域（情報部）に分けることができる。
ヘッダ部Ａ１は、ファイルの先頭に配置される領域で、ファイル名、ファイルサイズ、再生互換性情報などの他、ヘッダ情報として格納すべき所定の情報が格納される。
データ部Ａ２には、ＡＶファイルを形成するビデオデータ（画像データ）、オーディオデータなどが所定のデータ要素単位により所定規則に従って格納される領域である。例として、ビデオデータとして動画再生に使用されるデータ要素単位であれば、ＪＰＥＧ(Joint Photographic Expert Group)形式などに代表される、所定の画像圧縮方式により圧縮された１つの静止画像データの単位などとなる。
リソース部Ａ３は、上記データ部Ａ２におけるデータ分割単位の位置情報などをはじめ、データ部Ａ２に格納されるデータを再生出力（Presentation）するのに必要とされる所定の情報から成る領域である。ファイル再生にあたっては、このデータ部Ａ２に格納される情報を読み込んで解釈し、解釈結果に従って、データ部Ａ２から指定されるデータ要素単位を読み出してデコード処理を実行していく。これにより、例えば編集意図に従った内容による再生出力が実現される。
なお、本実施の形態が対応するＡＶファイルのフォーマットでは、ヘッダ部Ａ１に続けて、図のようにしてデータ部Ａ２−リソース部Ａ３の順で配置する構造の他に、リソース部Ａ３−データ部Ａ２の順で配置する構造を採ることも許可されている。
しかしながら、下記の理由で、実際のアプリケーションとしては、図７に示す構造によりメディアへの書き込みが行われることが通常であり、本実施の形態としても、これに従っている。
しかしながら、下記の理由で、実際のアプリケーションとしては、図７に示す構造によりメディアへの書き込みが行われることが通常であり、本実施の形態としても、これに従っている。
実際におけるメディアに対するＡＶファイルの書き込み処理によっては、上記図７に示す構造に応じたデータのシーケンスにより、メディア上の空き領域を埋めていくようにしてデータの書き込みが行われる。
そのうえで、リソース部Ａ３に格納される情報には、メディア上でのデータ分割単位の記録位置などの情報も含まれる。従って、リソース部Ａ３は、先にデータ部Ａ２の全てのデータがメディアに書き込まれた後、あるいは、データ部Ａ２の全てのデータについてのメディアへの記録位置が確定した後でなければ生成することができない、ということになる。
このような事情があるにもかかわらず、ヘッダ部Ａ１に続いて先ずリソース部Ａ３が配置され、その後にデータ部Ａ２が配置される構造によりメディアへの書き込みを実行するとすれば、そのための処理は相当に複雑なものとなる。つまり、例えばデータ部Ａ２としてのデータをメディアに書き込まずにメモリ領域などに保持しておいたうえで、データ部Ａ２をメディアに書き込んだ結果を推定するなどしてリソース部Ａ３に格納すべき情報を生成し、この後に改めて、リソース部Ａ３−データ部Ａ２の順で、メディアに対する書き込みを実行しなければならない。また、このような書き込み手順では、相当のデータ量を有するデータ部Ａ２のデータをバッファリングできるだけのメモリ容量も確保する必要が生じる。
これに対して、図７に示す構造であれば、ヘッダ部Ａ１に続けて、データ部Ａ２のデータのメディアへの物理的な書き込みを実行していきながら、その書き込み結果に応じてリソース部Ａ３の情報も逐次生成していくことができる。そして、データ部Ａ２のデータの書き込みが終了した時点では、リソース部Ａ３の情報も完成していることになり、即座にリソース部Ａ３のデータもメディアに書き込むことができる。
このようにして、本実施の形態のＡＶファイルは、図７に示す構造とすることがデータ書き込み処理に際して非常に効率的、合理的であり、この観点から、本実施の形態の場合も含め、図７のファイル構造を採用することが通常となっているものである。
ただし、確認のために述べておくと、本発明は、ファイル先頭からヘッダ部Ａ１−リソース部Ａ３−データ部Ａ２の順で配置するＡＶファイルの構造であっても適用されるものであり、同様の効果が得られる。
そのうえで、リソース部Ａ３に格納される情報には、メディア上でのデータ分割単位の記録位置などの情報も含まれる。従って、リソース部Ａ３は、先にデータ部Ａ２の全てのデータがメディアに書き込まれた後、あるいは、データ部Ａ２の全てのデータについてのメディアへの記録位置が確定した後でなければ生成することができない、ということになる。
このような事情があるにもかかわらず、ヘッダ部Ａ１に続いて先ずリソース部Ａ３が配置され、その後にデータ部Ａ２が配置される構造によりメディアへの書き込みを実行するとすれば、そのための処理は相当に複雑なものとなる。つまり、例えばデータ部Ａ２としてのデータをメディアに書き込まずにメモリ領域などに保持しておいたうえで、データ部Ａ２をメディアに書き込んだ結果を推定するなどしてリソース部Ａ３に格納すべき情報を生成し、この後に改めて、リソース部Ａ３−データ部Ａ２の順で、メディアに対する書き込みを実行しなければならない。また、このような書き込み手順では、相当のデータ量を有するデータ部Ａ２のデータをバッファリングできるだけのメモリ容量も確保する必要が生じる。
これに対して、図７に示す構造であれば、ヘッダ部Ａ１に続けて、データ部Ａ２のデータのメディアへの物理的な書き込みを実行していきながら、その書き込み結果に応じてリソース部Ａ３の情報も逐次生成していくことができる。そして、データ部Ａ２のデータの書き込みが終了した時点では、リソース部Ａ３の情報も完成していることになり、即座にリソース部Ａ３のデータもメディアに書き込むことができる。
このようにして、本実施の形態のＡＶファイルは、図７に示す構造とすることがデータ書き込み処理に際して非常に効率的、合理的であり、この観点から、本実施の形態の場合も含め、図７のファイル構造を採用することが通常となっているものである。
ただし、確認のために述べておくと、本発明は、ファイル先頭からヘッダ部Ａ１−リソース部Ａ３−データ部Ａ２の順で配置するＡＶファイルの構造であっても適用されるものであり、同様の効果が得られる。
また、ISO Base Media File Format（又はMP4 File Format）では、ファイル構造はBoxといわれるデータ単位の集合として形成されることが規定されており、これらのBoxのタイプ(Box type)としては、ftyp、moov、mdat、free、skipなどが定義されている。
ftypは、現ファイルのファイルタイプ、現ファイルを形成するBox typeごとのサイズ（データ長）、brand，versionなどといわれるファイルの再生互換性などの情報を格納するBoxとされる
moovは、ファイル出力（再生）などに必要とされるメタデータ(meta data)を格納するBoxとされる
mdatは、ファイル再生に使用される、例えばビデオ、オーディオなどをはじめとした実データ（media data）を格納するBoxとされる。
free、skipは、free spaceとして規定されるもので、ファイル再生には無関係であり無視されるべき領域として扱われるBoxとなる。
ftypは、現ファイルのファイルタイプ、現ファイルを形成するBox typeごとのサイズ（データ長）、brand，versionなどといわれるファイルの再生互換性などの情報を格納するBoxとされる
moovは、ファイル出力（再生）などに必要とされるメタデータ(meta data)を格納するBoxとされる
mdatは、ファイル再生に使用される、例えばビデオ、オーディオなどをはじめとした実データ（media data）を格納するBoxとされる。
free、skipは、free spaceとして規定されるもので、ファイル再生には無関係であり無視されるべき領域として扱われるBoxとなる。
そして、図７に示すように、ISO Base Media File Formatでは、ヘッダ部Ａ１において、ftype Boxを配置することとしている。つまり、ftype Boxに格納される上記各情報が実質的なヘッダ情報として機能している。
また、この場合においては、ＡＶファイルのヘッダ部Ａ１におけるftype Boxのサイズにより、ftype Boxの終端位置がクラスタの終端と一致しておらずに、クラスタの中途位置にある場合には、ヘッダ部Ａ１におけるftype Boxの終端位置から、この終端位置を含むクラスタの終端までの領域をfree Box（又はskip Box）により埋めることができる。このfree Boxにより、ヘッダ部Ａ１とデータ部Ａ２との境界をクラスタ境界とするように調整することができ、これにより、データ部Ａ２の開始位置をクラスタの先頭と一致させることで、データ部Ａ２に対するアクセスを効率的なものとすることができる。
また、この場合においては、ＡＶファイルのヘッダ部Ａ１におけるftype Boxのサイズにより、ftype Boxの終端位置がクラスタの終端と一致しておらずに、クラスタの中途位置にある場合には、ヘッダ部Ａ１におけるftype Boxの終端位置から、この終端位置を含むクラスタの終端までの領域をfree Box（又はskip Box）により埋めることができる。このfree Boxにより、ヘッダ部Ａ１とデータ部Ａ２との境界をクラスタ境界とするように調整することができ、これにより、データ部Ａ２の開始位置をクラスタの先頭と一致させることで、データ部Ａ２に対するアクセスを効率的なものとすることができる。
また、データ部Ａ２に格納されるビデオデータ、オーディオデータなどがmedia dataとなるので、このmedia dataを格納している領域がmdat Boxとなる。
また、データ部Ａ２においても、mdat Boxの終端位置から、この終端位置を含むクラスタの終端までの領域をfree Box（又はskip Box）により埋めることで、リソース部Ａ３の開始位置をクラスタの先頭と一致させるように調整して、リソース部Ａ３に対するアクセスの効率が高くなるようにしている。
また、データ部Ａ２においても、mdat Boxの終端位置から、この終端位置を含むクラスタの終端までの領域をfree Box（又はskip Box）により埋めることで、リソース部Ａ３の開始位置をクラスタの先頭と一致させるように調整して、リソース部Ａ３に対するアクセスの効率が高くなるようにしている。
リソース部Ａ３は、先に説明したように、データ部Ａ２に格納されるビデオ／オーディオなどのデータ（media data）を再生出力（Presentation）するための参照データを格納する領域である。つまりmeta dataを格納する領域のmoov Boxとなる。
上記したＡＶファイルの構造を前提として、例えば、図７におけるファイルＡを基として、このファイルＡに対する操作により何らかのデータ内容を変更して、新規ファイルを作成する場合を考えてみる。この場合、図７に示されるファイル構造では、データとして意味のある何らかの内容を有する領域は、ftyp Box、mdat Box、moov Boxであり、free Box(又はskip Box)は、データとしての意味を持つ内容を有していないので、実施区的なデータ内容を変更できる領域もftyp Box、mdat Box、moov Boxであることになる。
そのうえで、図７のファイルＡの内容に変更を加えて新規ファイルを作成してメディアに書き込んで記憶させる（保存する）場合の具体例として、同じ図７に示すように、ファイルＡのヘッダ部Ａ１内のftyp Boxとリソース部Ａ３のmoov Box（あるいはftyp Boxとmoov Boxの何れか一方でもよい）における所要の内容を変更して、新規にファイルＢを作成して保存した場合を想定してみる。
なお、ビデオ／オーディオなどの実データ（mdat）以外の、ヘッダ情報（ftyp）やリソース情報（moov）のみを変更するような編集としては、次のような事例を挙げることができる。
１．ヘッダ情報（ftyp）におけるbrand，versionなどの再生互換情報のみを変更する場合。例えば、ファイルＡでは、brandの情報単位として、或る１つのbrandのみが登録されていたとする。そこで、brandの情報について、さらに他のbrandを追加登録する変更を行い、ファイルＢを新規作成して保存する。
この場合において、リソース情報（moov）は変更しないものとすると、ファイルＡとファイルＢとでは、再生出力(presentation)される内容は変わらないが、再生可能なbrandについてはファイルＢのほうが追加登録分により拡張されている。
２．例えばファイルＡを基としたpresentationの変更のための編集処理などに応じて、ファイルＡのリソース情報（moov）の内容を基にして、presentationの内容を変更する場合。この場合においては、データ部Ａ２において格納するmdatの内容はファイルＡ，Ｂで同じであるが、再生出力される態様、つまり、presentationの結果が異なるものとなる。
なお、ビデオ／オーディオなどの実データ（mdat）以外の、ヘッダ情報（ftyp）やリソース情報（moov）のみを変更するような編集としては、次のような事例を挙げることができる。
１．ヘッダ情報（ftyp）におけるbrand，versionなどの再生互換情報のみを変更する場合。例えば、ファイルＡでは、brandの情報単位として、或る１つのbrandのみが登録されていたとする。そこで、brandの情報について、さらに他のbrandを追加登録する変更を行い、ファイルＢを新規作成して保存する。
この場合において、リソース情報（moov）は変更しないものとすると、ファイルＡとファイルＢとでは、再生出力(presentation)される内容は変わらないが、再生可能なbrandについてはファイルＢのほうが追加登録分により拡張されている。
２．例えばファイルＡを基としたpresentationの変更のための編集処理などに応じて、ファイルＡのリソース情報（moov）の内容を基にして、presentationの内容を変更する場合。この場合においては、データ部Ａ２において格納するmdatの内容はファイルＡ，Ｂで同じであるが、再生出力される態様、つまり、presentationの結果が異なるものとなる。
また、上記図７に示す場合を含み、ファイルＡを基にして内容に何らかの変更を与えて新規ファイルＢを作成してメディアに保存するための処理手順を、図８に示す。この図は、先に図２に示したＦＡＴファイルシステムのシステム階層の下での処理手順として示している。
この場合において、編集元（変更元）となるファイルＡは既にメディアに記憶済みとされている。そこで、アプリケーション１００は、手順１によりファイルＡの読み出しを要求する。この要求は、ファイルシステム１０１によりクラスタレベルのアクセス要求に変換されてデバイスドライバ１０２に伝達される。デバイスドライバ１０２は、この要求に応じて、ファイルＡの読み出しのために、メディア１０３に対するセクタレベルによるアクセスを実行する。
次の手順２としては、上記したデバイスドライバ１０２のアクセスにより、メディア１０３からファイルＡを成すデータの内容の一部が読み出されることになる。このときにどのようなデータのまとまりにより読み出しを実行するのかについては、読み出したデータをクラスタレベルで保持するワークＲＡＭ領域のサイズや、データ単位構造などに応じたものとなる。
そして、デバイスドライバ１０２は、読み出したファイルＡの内容のデータをファイルシステム１０１経由でアプリケーション１００に渡していくようにされる。この過程で、メディア１０３から読み出されるデータは、セクタレベルからクラスタレベルに、さらにアプリケーションデータのレベルに変換されていく。
次の手順２としては、上記したデバイスドライバ１０２のアクセスにより、メディア１０３からファイルＡを成すデータの内容の一部が読み出されることになる。このときにどのようなデータのまとまりにより読み出しを実行するのかについては、読み出したデータをクラスタレベルで保持するワークＲＡＭ領域のサイズや、データ単位構造などに応じたものとなる。
そして、デバイスドライバ１０２は、読み出したファイルＡの内容のデータをファイルシステム１０１経由でアプリケーション１００に渡していくようにされる。この過程で、メディア１０３から読み出されるデータは、セクタレベルからクラスタレベルに、さらにアプリケーションデータのレベルに変換されていく。
アプリケーション１００では、手順３として示すように、上記手順２によりメディアから読み出して取得したファイルＡの内容のデータ部分を変更対象として扱う。ここで、アプリケーション１００は、ファイルＢとしての内容を得るために変更が必要なのであれば、所要のデータ部分についての変更を行う。そして、この変更対象のデータをファイルＢの内容として書き込むための要求を行う。これにより、この変更対象のデータは、ファイルシステム１０１からデバイスドライバ１０２に受け渡され、ファイルＢとして管理されるようにして、メディア１０３に対して書き込みが行われる。
なお、手順３において、上記変更対象のデータ部分について変更の必要が無い場合には、そのままファイルＡとして読み出したそのままの内容により、ファイルＢとしてメディア１０３に書き込むための処理が実行される。
なお、手順３において、上記変更対象のデータ部分について変更の必要が無い場合には、そのままファイルＡとして読み出したそのままの内容により、ファイルＢとしてメディア１０３に書き込むための処理が実行される。
そして、上記手順３によるファイルＢの内容のデータ部分についてのメディア１０３への書き込みが完了したとされると、手順４として示すようにして、デバイスドライバ１０２は、今回のファイルＢのデータ部分の書き込みを完了したことの通知を行う。この通知は、ファイルシステム１０１経由で、アプリケーション１００に対して通知されることになる。
そして、この手順１〜手順４までの処理を、ファイルＢを形成する全ての内容のデータについてのメディア１０３への書き込み処理が終了するまで繰り返し実行することになる。つまり、変更元のファイル（ファイルＡ）の内容を変更して新規ファイル（ファイルＢ）を作成してメディアに記憶させるためには、変更元のファイルの一部データ内容をメディアから一旦読み出して、必要に応じて変更を行い、このデータを、新規ファイルのデータ部分としてメディアに再度書き込むという処理を、新規ファイルを形成する全データの書き込みが完了するまで繰り返し実行する。
そして、この手順１〜手順４までの処理を、ファイルＢを形成する全ての内容のデータについてのメディア１０３への書き込み処理が終了するまで繰り返し実行することになる。つまり、変更元のファイル（ファイルＡ）の内容を変更して新規ファイル（ファイルＢ）を作成してメディアに記憶させるためには、変更元のファイルの一部データ内容をメディアから一旦読み出して、必要に応じて変更を行い、このデータを、新規ファイルのデータ部分としてメディアに再度書き込むという処理を、新規ファイルを形成する全データの書き込みが完了するまで繰り返し実行する。
上記図８に示した処理手順は、従来においては、変更元ファイルを基としてその内容を変更して生成した新規ファイルを保存する場合には、例外なく実行される処理となる。換言すれば、図７に示した構造のＡＶファイルであれば、ftype Box、mdat Box、moov Boxのうち、少なくも何れか１つの領域において、少なくとも１項目でも内容の変更があれば実行されるものとなる。
このために、例えば図７にて例示しているように、ファイルＡについてftype Boxとmoov Boxの内容のみを変更して新規にファイルＢを作成して保存することとした場合、ファイルＡとファイルＢとで同一とされるmdat Boxのデータ内容を含むデータ部Ａ２についても、図８に示す手順１から手順４による処理を実行することになる。この場合において、変更が与えられたftype Boxを含むヘッダ部Ａ１と、moov Boxであるリソース部Ａ３については、図８に示す手順の処理を実行する必要はあるといえる。しかし、ファイルＡからの変更がないデータ部Ａ２についても図８に示す手順による読み出し／書き込みの処理を実行するということは、ファイルＡのデータ部Ａ２と同一の内容を、ファイルＢのデータ部Ａ２を形成するために、同じメディアにコピー（複製）しているのみであり、その分、ファイルＢの新規保存にあたって余分な処理時間をかけている、ということがいえる。
現実的な問題として、mdat Boxは、例えば画像、音声などの実データなどであるから、そのデータサイズは、ftype Box及びmoov Boxに対して相当に大きく、ファイルの大部分を占める。従って、図７の場合において、mdat Boxの読み出し／書き込みを実行することは、ファイルＢを作成／保存するための処理時間全体においても相当に冗長な時間を含んでいるということになる。また、このことは、換言すれば、図７に示されるケースにおいては、mdat Boxの読み出し／書き込みが省略されるようにすれば、ファイルＢを作成／保存するための処理時間は相当に短縮されるというメリットが得られることにつながる。ただし、単純にmdat Boxの読み出し／書き込みの処理を省略しても、ファイルＢとしてはmdat Boxを有さない不完全な構造のファイルとなるので、何ら意味は成さない。
本実施の形態としては、上記したことを背景として、新規のファイルＢとしても、mdat Boxを有する構造によりメディアに記録されるようにしながらも、図８に示されるようなmdat Boxの読み出し／書き込みの処理が省略されるようにする。このための構成を、以降説明していく。
現実的な問題として、mdat Boxは、例えば画像、音声などの実データなどであるから、そのデータサイズは、ftype Box及びmoov Boxに対して相当に大きく、ファイルの大部分を占める。従って、図７の場合において、mdat Boxの読み出し／書き込みを実行することは、ファイルＢを作成／保存するための処理時間全体においても相当に冗長な時間を含んでいるということになる。また、このことは、換言すれば、図７に示されるケースにおいては、mdat Boxの読み出し／書き込みが省略されるようにすれば、ファイルＢを作成／保存するための処理時間は相当に短縮されるというメリットが得られることにつながる。ただし、単純にmdat Boxの読み出し／書き込みの処理を省略しても、ファイルＢとしてはmdat Boxを有さない不完全な構造のファイルとなるので、何ら意味は成さない。
本実施の形態としては、上記したことを背景として、新規のファイルＢとしても、mdat Boxを有する構造によりメディアに記録されるようにしながらも、図８に示されるようなmdat Boxの読み出し／書き込みの処理が省略されるようにする。このための構成を、以降説明していく。
ここで、以降の説明にあたって、図７におけるファイルＡのようにして、新規にファイルを作成するのにあたって、その作成元となるファイルについては、「オリジナルファイル（原ファイル）」ともいうこととする。また、図７のファイルＢのように、オリジナルファイルを基として、その一部内容を変更、追加するなどして新規に作成されるファイル（新規ファイル）として、ヘッダ部Ａ１(ftyp Box)、及びリソース部Ａ３（moov Box)の少なくとも何れか一方について変更されているが、データ部Ａ２(mdat)については変更のないファイルについては、「ヘッダ／リソース編集ファイル」ともいうことにする。なお、現実的には、ヘッダ部Ａ１は、例えばファイル名、ファイルＩＤなどファイルごとに対応して固有の情報を有するから、オリジナルファイルを基として必ず変更がされる。従って、ヘッダ／リソース編集ファイルとしては、ヘッダ部Ａ１のみが変更されてリソース部Ａ３については変更がないファイルと、ヘッダ部Ａ１及びリソース部Ａ３の両者について変更されるファイルとの２つがあることになる。
図９は、オリジナルファイルであるファイルＡと、ファイルＡを基とするヘッダ／リソース編集ファイルであるファイルＢについてのメディアにおける記録状態例を、ＦＡＴファイルシステムに従ったファイル管理結果として示している。この図により、本実施の形態におけるヘッダ／リソース編集ファイルについての構造概念を説明する。
先ず、オリジナルファイルのファイルＡとしては次のようにして管理されている。
つまり、ファイルＡがメディアに記録されていることにより、同じメディアに、ファイルＡのディレクトリエントリ(D1)が記録されている。このディレクトリエントリD1が格納するファイルの先頭クラスタ番号（バイト位置14h-15h/1Ah-1Bh）が指示するクラスタには、矢印ａ−１として示すように、ファイルＡのファイル先頭である、ヘッダ部Ａ１(D2)のデータ(ftyp Box)の先頭部分が記録される。
そして、このヘッダ部Ａ１の先頭データ部分を格納するクラスタを起点として、ＦＡＴ領域を参照してファイルＡについてのクラスタチェインを辿っていくことで、ヘッダ部Ａ１(D2)に続けて、矢印ａ−２に示すように、ファイルＡのデータ部Ａ２(D3)が連結され、さらにファイルＡのデータ部Ａ２(D3)に続けて、矢印ａ−３に示すように、ファイルＡのリソース部Ａ３(D4)が連結されることになる。
先ず、オリジナルファイルのファイルＡとしては次のようにして管理されている。
つまり、ファイルＡがメディアに記録されていることにより、同じメディアに、ファイルＡのディレクトリエントリ(D1)が記録されている。このディレクトリエントリD1が格納するファイルの先頭クラスタ番号（バイト位置14h-15h/1Ah-1Bh）が指示するクラスタには、矢印ａ−１として示すように、ファイルＡのファイル先頭である、ヘッダ部Ａ１(D2)のデータ(ftyp Box)の先頭部分が記録される。
そして、このヘッダ部Ａ１の先頭データ部分を格納するクラスタを起点として、ＦＡＴ領域を参照してファイルＡについてのクラスタチェインを辿っていくことで、ヘッダ部Ａ１(D2)に続けて、矢印ａ−２に示すように、ファイルＡのデータ部Ａ２(D3)が連結され、さらにファイルＡのデータ部Ａ２(D3)に続けて、矢印ａ−３に示すように、ファイルＡのリソース部Ａ３(D4)が連結されることになる。
また、ファイルＢは次のようにして管理されている。
ヘッダ／リソース編集ファイルであるファイルＢについても、メディアに記録されたファイルであるから、ファイルＢのディレクトリエントリ(D5)が作成されてメディアに記録されている。
このファイルＢのディレクトリエントリ(D5)が格納する先頭クラスタ番号が指示するクラスタには、矢印ｂ−１として示すように、ファイルＢのファイル先頭であるヘッダ部Ａ１(D6)のデータ(ftyp Box)の先頭部分が記録される。
そして、以降、ファイルＢのＦＡＴ領域を参照してクラスタチェインを辿っていくようにすると、この場合には、ヘッダ部Ａ１(D6)の終端クラスタに続けて、矢印ｂ−２に示すように、本来はファイルＡの形成要素であるデータ部Ａ２(D3)が連結される。そして、データ部Ａ２(D3)の終端に続けては、ファイルＡのリソース部Ａ３(D4)ではなく、ファイルＢのリソース部Ａ３(D7)が連結されるようにして管理される。
ヘッダ／リソース編集ファイルであるファイルＢについても、メディアに記録されたファイルであるから、ファイルＢのディレクトリエントリ(D5)が作成されてメディアに記録されている。
このファイルＢのディレクトリエントリ(D5)が格納する先頭クラスタ番号が指示するクラスタには、矢印ｂ−１として示すように、ファイルＢのファイル先頭であるヘッダ部Ａ１(D6)のデータ(ftyp Box)の先頭部分が記録される。
そして、以降、ファイルＢのＦＡＴ領域を参照してクラスタチェインを辿っていくようにすると、この場合には、ヘッダ部Ａ１(D6)の終端クラスタに続けて、矢印ｂ−２に示すように、本来はファイルＡの形成要素であるデータ部Ａ２(D3)が連結される。そして、データ部Ａ２(D3)の終端に続けては、ファイルＡのリソース部Ａ３(D4)ではなく、ファイルＢのリソース部Ａ３(D7)が連結されるようにして管理される。
上記説明によると、ヘッダ／リソース編集ファイルであるファイルＢのヘッダ部Ａ１−データ部Ａ２−リソース部Ａ３の構造において、データ部Ａ２は、オリジナルファイルであるファイルＡのデータ部Ａ２(D3)とされている。つまり、ヘッダ／リソース編集ファイルは、自身のデータ部Ａ２について、オリジナルファイルのデータ部Ａ２を共有、引用することで、ファイルとして完成した構造を得るようにされる。
確認のために述べておくと、ヘッダ／リソース編集ファイルのデータ部Ａ２におけるmdat Boxに格納されるべき内容は、オリジナルファイルのデータ部Ａ２と同一であるべきものなので、このようにしてデータ部Ａ２が共有されたとしても、ファイルＢを再生することによっては、意図通りのpresentation結果が得られる。
確認のために述べておくと、ヘッダ／リソース編集ファイルのデータ部Ａ２におけるmdat Boxに格納されるべき内容は、オリジナルファイルのデータ部Ａ２と同一であるべきものなので、このようにしてデータ部Ａ２が共有されたとしても、ファイルＢを再生することによっては、意図通りのpresentation結果が得られる。
ヘッダ／リソース編集ファイルとして上記した構造を採るようにすれば、ヘッダリソースファイルを新規作成（生成）してメディアに保存するための、メディアへのデータ書き込み処理としては、ヘッダ部Ａ１のデータとリソース部Ａ３のみ（図９ではD6，D7の領域が相当する）でよく、データ部Ａ２については必要がない。このようにして、データ部Ａ２についてのデータ書き込み処理が省略されることで、ヘッダ／リソース編集ファイルの生成／保存は、ヘッダ部Ａ１とリソース部Ａ３のメディアへの書き込み処理と、データ部２が共有できるようにＦＡＴ領域の所要の内容を書き換える処理のみを実行すればよいことになる。
換言すれば、ヘッダ／リソース編集ファイルの生成／保存に要する処理時間は、上記している、ヘッダ部Ａ１とリソース部Ａ３のメディアへの書き込み処理時間と、ＦＡＴ領域の所要の内容を書き換える処理時間との合計となるものであり、ヘッダ／リソース編集ファイルの作成／保存にあたってのデータ書き込み処理に要する時間は省かれる。
データ書き込み処理に要する時間は、書き込むべきデータ量の増加に応じて長くなるが、本実施の形態では、ファイル全体において最もサイズ占有率が高く、また、データサイズそのものが大容量の傾向にあるデータ部Ａ２のデータ書き込み処理を省略することとしている。従って、本実施の形態におけるヘッダ／リソース編集ファイルの生成／保存のためのデータ書き込み処理の時間は、大幅に短縮されることになる。特に、ＨＤＤ、光学ディスク状記録媒体などのようにして、メディアへのアクセスのためにヘッドなどの物理的移動（シーク動作）が伴うような場合には、その分、シーク動作が実行される機会も減少することになるので、データ書き込み時間の短縮効果はより顕著に得られる。
換言すれば、ヘッダ／リソース編集ファイルの生成／保存に要する処理時間は、上記している、ヘッダ部Ａ１とリソース部Ａ３のメディアへの書き込み処理時間と、ＦＡＴ領域の所要の内容を書き換える処理時間との合計となるものであり、ヘッダ／リソース編集ファイルの作成／保存にあたってのデータ書き込み処理に要する時間は省かれる。
データ書き込み処理に要する時間は、書き込むべきデータ量の増加に応じて長くなるが、本実施の形態では、ファイル全体において最もサイズ占有率が高く、また、データサイズそのものが大容量の傾向にあるデータ部Ａ２のデータ書き込み処理を省略することとしている。従って、本実施の形態におけるヘッダ／リソース編集ファイルの生成／保存のためのデータ書き込み処理の時間は、大幅に短縮されることになる。特に、ＨＤＤ、光学ディスク状記録媒体などのようにして、メディアへのアクセスのためにヘッドなどの物理的移動（シーク動作）が伴うような場合には、その分、シーク動作が実行される機会も減少することになるので、データ書き込み時間の短縮効果はより顕著に得られる。
また、ヘッダ／リソース編集ファイルがオリジナルファイルのデータ部Ａ２を共有していることで、ヘッダ／リソース編集ファイルのデータ書き込みに際しては、データ部書き込みのために新たにクラスタを消費することが無い。これにより、メディアの残容量が節約され、その使用効率についても向上される。
本発明においては、１つのオリジナルファイルを基として、複数のヘッダ／リソース編集ファイルを生成することが可能であり、これら複数のヘッダ／リソース編集ファイルは、何れもオリジナルファイルのデータ部Ａ２を共有、引用する。従って、１つのオリジナルファイルを基とするヘッダ／リソース編集ファイルの数が多くなるほど、このメディア容量の使用効率は高くなっていく。
本発明においては、１つのオリジナルファイルを基として、複数のヘッダ／リソース編集ファイルを生成することが可能であり、これら複数のヘッダ／リソース編集ファイルは、何れもオリジナルファイルのデータ部Ａ２を共有、引用する。従って、１つのオリジナルファイルを基とするヘッダ／リソース編集ファイルの数が多くなるほど、このメディア容量の使用効率は高くなっていく。
ところで、先に挙げた特許文献１においても、記録済みのファイルＡと、この後において生成／保存されたファイルＢとで、ファイルＡのデータの一部をファイルＢも共有する構造としている形態が示されている。しかしながら、この特許文献１では、データ部分がファイルＡ，Ｂとにより共有されるようにして管理するのにあたっては、ファイルＢについては、磁気テープに固有の情報となる開始／終了タイムコード、開始／終了巻径などによりファイルの記録位置を管理することとしている。つまり、ファイルＡについては本来採用されているファイルシステムにより管理することとしているが、ファイルＢについては、このファイルシステム以外の管理形態により管理することとしている。つまり、管理手段としては、ファイルシステムに従って管理するものと、ファイルシステムの枠組みからは外れた形式により管理するものとの、２つが存在しているということがいえる。このようなファイル管理形態は、メディアが磁気テープであることを前提した場合には非常に有効となるが、逆に他のメディア全般において採用することは難しい。
これに対して本実施の形態としては、以降の説明から理解されるように、ファイル管理のために本来的に採用されるファイルシステムの枠内で本実施の形態に特有の仕組みを与えることで、複数のファイル間におけるデータ部Ａ２の共有を実現している。また、このようにして、本実施の形態としては、あくまでもファイルシステムの枠組みのなかでデータ部分の共有を実現していることで、メディアについて、上記磁気テープも含め、ＨＤＤ、光学ディスク状記録媒体、半導体メディア装置、その他が対象となるもので、広い汎用性が与えられている、ということもいえる。
これに対して本実施の形態としては、以降の説明から理解されるように、ファイル管理のために本来的に採用されるファイルシステムの枠内で本実施の形態に特有の仕組みを与えることで、複数のファイル間におけるデータ部Ａ２の共有を実現している。また、このようにして、本実施の形態としては、あくまでもファイルシステムの枠組みのなかでデータ部分の共有を実現していることで、メディアについて、上記磁気テープも含め、ＨＤＤ、光学ディスク状記録媒体、半導体メディア装置、その他が対象となるもので、広い汎用性が与えられている、ということもいえる。
続いては、図９に例示したようにして、ＦＡＴファイルシステムの下で、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を共有（引用）したファイル構造により管理されるようにするためのファイルシステム構成について、図１０〜図１３を参照して説明する。なお、ここでの説明にあたっては、ＦＡＴファイルシステムフォーマットとして、ＦＡＴ３２を採用していることとする。
図１０は、オリジナルファイルであるファイルＡと、このファイルＡを共通に基とするヘッダ／リソース編集ファイルである３つのファイルＢ，Ｃ，Ｄとの４つのファイルについて、クラスタ番号によるクラスタチェイン構造として示している。
先ず、オリジナルファイルのファイルＡは、ヘッダ部Ａ１についてはクラスタ番号［00000010h→00000011h→00000012h］の３クラスタの連結により形成され、ヘッダ部Ａ１の終端クラスタ（00000012h）に続くデータ部Ａ２については、クラスタ番号［00000013h〜0000001Ch］までの１０クラスタの連結により形成され、データ部Ａ２の終端クラスタ（0000001Ch）に続くリソース部Ａ３については、クラスタ番号［0000001Dh→0000001Eh→0000001Fh］の３クラスタの連結により形成されていることが示される。
先ず、オリジナルファイルのファイルＡは、ヘッダ部Ａ１についてはクラスタ番号［00000010h→00000011h→00000012h］の３クラスタの連結により形成され、ヘッダ部Ａ１の終端クラスタ（00000012h）に続くデータ部Ａ２については、クラスタ番号［00000013h〜0000001Ch］までの１０クラスタの連結により形成され、データ部Ａ２の終端クラスタ（0000001Ch）に続くリソース部Ａ３については、クラスタ番号［0000001Dh→0000001Eh→0000001Fh］の３クラスタの連結により形成されていることが示される。
次に、ヘッダ／リソース編集ファイルであるファイルＢ，Ｃ，Ｄのうち、ファイルＢについては、ヘッダ部Ａ１はクラスタ番号[00000020h]の１クラスタから成ることとしている。そして、このクラスタに続くデータ部Ａ２は、ファイルＡのデータ部Ａ２を引用していることで、ファイルＡと同じクラスタ番号［00000013h〜0000001Ch]までの１０クラスタの連結により形成されるものとなる。このデータ部Ａ２に続くリソース部Ａ３は、クラスタ番号［00000021h→00000022h］による２クラスタの連結から成るものとしている。
ファイルＣは、先ず、ヘッダ部Ａ１はクラスタ番号[00000030h→00000031h]の２クラスタから成ることとしている。また、この場合にもデータ部Ａ２は、ファイルＡのデータ部Ａ２を引用して、ファイルＡと同じクラスタ番号［00000013h〜0000001Ch]の１０クラスタの連結となる。リソース部Ａ３は、クラスタ番号［00000032h→00000033h→00000034h］による３クラスタの連結から成っている。
ファイルＤは、ヘッダ部Ａ１についてクラスタ番号［00000038h→00000039h→0000003Ah]の３クラスタで形成しており、データ部Ａ２は、ファイルＣ，Ｄと同様に、ファイルＡのデータ部Ａ２を引用してクラスタ番号［00000013h〜0000001Ch]の１０クラスタの連結となっている。リソース部Ａ３は、クラスタ番号［0000003Bh→0000003Ch→0000003Dh］による３クラスタの連結から成る。
次に、上記図１０に示したクラスタチェイン構造によりファイルＡ，Ｂ，Ｃ，Ｄを管理可能とするためのＦＡＴファイルシステムのフォーマット（仕様）について説明する。
先に図３により説明したように、ＦＡＴファイルシステムによるフォーマット構造では、ＦＡＴ１，ＦＡＴ２として示すように、複数のＦＡＴ領域を備えてよいことになっている。ＦＡＴ１，ＦＡＴ２の２つのＦＡＴ領域を形成した場合、通常はＦＡＴ１が実際のファイル管理に使用されるＦＡＴ領域で、ＦＡＴ２は、予備領域、バックアップ領域として、ＦＡＴ１の内容がコピーなどされるようにして使用される。
本実施の形態では、ＦＡＴ１のＦＡＴエントリ構造について、次に説明するようにして定義すると共に、ＦＡＴ２については、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を引用できるようにするためのクラスタチェインを記述するための領域として使用するようにされる。これにより、例えば図１０に示したように、オリジナルファイルのデータ部Ａ２を、他のヘッダ／リソース編集ファイルが共有するファイル構造管理を可能とする。
先に図３により説明したように、ＦＡＴファイルシステムによるフォーマット構造では、ＦＡＴ１，ＦＡＴ２として示すように、複数のＦＡＴ領域を備えてよいことになっている。ＦＡＴ１，ＦＡＴ２の２つのＦＡＴ領域を形成した場合、通常はＦＡＴ１が実際のファイル管理に使用されるＦＡＴ領域で、ＦＡＴ２は、予備領域、バックアップ領域として、ＦＡＴ１の内容がコピーなどされるようにして使用される。
本実施の形態では、ＦＡＴ１のＦＡＴエントリ構造について、次に説明するようにして定義すると共に、ＦＡＴ２については、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を引用できるようにするためのクラスタチェインを記述するための領域として使用するようにされる。これにより、例えば図１０に示したように、オリジナルファイルのデータ部Ａ２を、他のヘッダ／リソース編集ファイルが共有するファイル構造管理を可能とする。
図１１は、ＦＡＴ１の領域において配列されるＦＡＴエントリの構造を示している。
この場合のＦＡＴエントリは、ＦＡＴファイルシステムフォーマットがＦＡＴ３２であることに対応して、３２ビット（第０ビット〜第２７ビット）とされている。そして、実際には、この３２ビットにおける第４ビットから第２７ビットまでの下位２８ビットにより、チェイン先となる次のクラスタ番号を格納することとされている。そして、従来としては、残る上位第０ビット〜第３ビットまでの４ビットは未使用とされて、ビット値としては0,0,0,0(0h)を格納することとしていた。
本実施の形態では、これまで未使用であった上位４ビットについて、図のようにして定義する。つまり、この上位４ビットにおける最上位の第０ビットについては、引用元指示フラグの領域とする。
引用元指示フラグのビット値が０の場合には、現ＦＡＴエントリの下位２８ビットの領域は、通常に、次のチェイン先となるクラスタ番号を格納していることを示す。つまり、通常機能のＦＡＴエントリであることを示す。
これに対して、引用元指示フラグのビット値が１の場合には、現ＦＡＴエントリの下位２８ビットは、ヘッダ／リソース編集ファイルが引用すべきオリジナルファイルのデータ部Ａ２の先頭のクラスタ番号、つまり、引用元となるデータ部分を格納する最初のクラスタ番号を格納していることを示す。
この場合のＦＡＴエントリは、ＦＡＴファイルシステムフォーマットがＦＡＴ３２であることに対応して、３２ビット（第０ビット〜第２７ビット）とされている。そして、実際には、この３２ビットにおける第４ビットから第２７ビットまでの下位２８ビットにより、チェイン先となる次のクラスタ番号を格納することとされている。そして、従来としては、残る上位第０ビット〜第３ビットまでの４ビットは未使用とされて、ビット値としては0,0,0,0(0h)を格納することとしていた。
本実施の形態では、これまで未使用であった上位４ビットについて、図のようにして定義する。つまり、この上位４ビットにおける最上位の第０ビットについては、引用元指示フラグの領域とする。
引用元指示フラグのビット値が０の場合には、現ＦＡＴエントリの下位２８ビットの領域は、通常に、次のチェイン先となるクラスタ番号を格納していることを示す。つまり、通常機能のＦＡＴエントリであることを示す。
これに対して、引用元指示フラグのビット値が１の場合には、現ＦＡＴエントリの下位２８ビットは、ヘッダ／リソース編集ファイルが引用すべきオリジナルファイルのデータ部Ａ２の先頭のクラスタ番号、つまり、引用元となるデータ部分を格納する最初のクラスタ番号を格納していることを示す。
また、ＦＡＴエントリにおける第１ビット〜第３ビットまでの３ビットは引用ファイル数を格納する領域とされる。そのＦＡＴエントリが、オリジナルファイルのデータ部Ａ２の開始位置を含むクラスタに対応している場合において、この第１ビット〜第３ビットの３ビットの領域において、オリジナルファイルのデータ部Ａ２を引用しているヘッダ／リソース編集ファイルの数が示される。
上記したＦＡＴ１のＦＡＴエントリ構造をふまえ、図１０に示したファイルＡ，Ｂ，Ｃ，Ｄについての、ＦＡＴファイルシステムによる管理形態について説明することとする。周知のようにしてＦＡＴファイルシステムでは、ファイルとしてのデータの実体は、ディレクトリエントリとＦＡＴ領域とにより管理されることとなっており、このことについては、本実施の形態の場合も同様である。
そこで先ず、図１０に示したファイルＡ，Ｂ，Ｃ，Ｄに対応するディレクトリエントリを、それぞれ、図１２（ａ）（ｂ）（ｃ）（ｄ）に示す。なお、ここでは、ファイルＡ，Ｂ，Ｃ，Ｄのそれぞれについての先頭クラスタ番号の管理状態を示すことを主眼としているので、ＦＡＴエントリにおける先頭クラスタ番号（バイト位置14h-15h/1Ah-1Bh)以外の領域については省略している箇所がある。
これらファイルＡ，Ｂ，Ｃ，Ｄとして示している形式のＡＶファイルは、先に図７によっても示したように、ヘッダ部Ａ１の先頭がファイルの先頭となる。
図９によれば、ファイルＡは、ヘッダ部Ａ１の先頭クラスタ番号が00000010hとされているので、ファイルの先頭クラスタの番号としても00000010hとなる。これに応じて、図１２（ａ）に示すように、ファイルＡのディレクトリエントリの先頭クラスタ番号の領域には、00000010hが格納される。
ファイルＢのヘッダ部Ａ１は、00000020hのクラスタのみであるから、ファイルの先頭クラスタ番号としても、この00000020hとなる。これに応じて、図１２（ｂ）に示すように、ファイルＢのディレクトリエントリの先頭クラスタ番号の領域には、00000020hが格納される。
ファイルＣのヘッダ部Ａ１の先頭クラスタ（ファイル先頭クラスタ）は00000030hであり、これに応じて、ファイルＣのディレクトリエントリの先頭クラスタ番号の領域にも、図１２（ｃ）に示すように、00000030hが格納される。
ファイルＤのヘッダ部Ａ１の先頭クラスタ（ファイル先頭クラスタ）は00000038hであり、これに応じて、ファイルＣのディレクトリエントリの先頭クラスタ番号の領域にも、図１２（ｃ）に示すように、00000038hが格納される。
図９によれば、ファイルＡは、ヘッダ部Ａ１の先頭クラスタ番号が00000010hとされているので、ファイルの先頭クラスタの番号としても00000010hとなる。これに応じて、図１２（ａ）に示すように、ファイルＡのディレクトリエントリの先頭クラスタ番号の領域には、00000010hが格納される。
ファイルＢのヘッダ部Ａ１は、00000020hのクラスタのみであるから、ファイルの先頭クラスタ番号としても、この00000020hとなる。これに応じて、図１２（ｂ）に示すように、ファイルＢのディレクトリエントリの先頭クラスタ番号の領域には、00000020hが格納される。
ファイルＣのヘッダ部Ａ１の先頭クラスタ（ファイル先頭クラスタ）は00000030hであり、これに応じて、ファイルＣのディレクトリエントリの先頭クラスタ番号の領域にも、図１２（ｃ）に示すように、00000030hが格納される。
ファイルＤのヘッダ部Ａ１の先頭クラスタ（ファイル先頭クラスタ）は00000038hであり、これに応じて、ファイルＣのディレクトリエントリの先頭クラスタ番号の領域にも、図１２（ｃ）に示すように、00000038hが格納される。
図１３は、ファイルＡ，Ｂ，Ｃ，Ｄのメディアへの記録結果に応じたＦＡＴ領域の内容を示しているもので、図の上側にＦＡＴ１の領域の内容を示し、図の下側にＦＡＴ２の領域の内容を示す。
先ず、このＦＡＴ領域上で、オリジナルファイルであるファイルＡがどのようにして管理されているのかについて述べる。なお、以降の説明にあたり、ＦＡＴ１内のＦＡＴエントリについては、ＦＡＴエントリ／ＦＡＴ１と記載し、ＦＡＴ２内のＦＡＴエントリについては、ＦＡＴエントリ／ＦＡＴ２と記載する場合がある。
先ず、このＦＡＴ領域上で、オリジナルファイルであるファイルＡがどのようにして管理されているのかについて述べる。なお、以降の説明にあたり、ＦＡＴ１内のＦＡＴエントリについては、ＦＡＴエントリ／ＦＡＴ１と記載し、ＦＡＴ２内のＦＡＴエントリについては、ＦＡＴエントリ／ＦＡＴ２と記載する場合がある。
ファイルＡの先頭クラスタ番号は、図１２（ａ）によれば00000010hとされている。そこで、図１３のＦＡＴ１におけるクラスタ番号00000010hのＦＡＴエントリが格納する値を参照すると、00000011hとなっている。この値では、先ず、第０〜第３ビットまでの４ビットについて0,0,0,0,となっていることから、通常に次のチェイン先クラスタ番号を示す機能を有するＦＡＴエントリであることが分かる。そこで、チェイン先となるクラスタ番号00000011hのＦＡＴエントリ／ＦＡＴ１を参照すると、00000012hが格納されており、さらに次のチェイン先クラスタ番号が00000012hであることを示している。以降、ＦＡＴ１においてクラスタチェインを辿っていくことにより、最終的に、EOFを示すクラスタ番号0000001Fhのクラスタに到達する。これにより、ファイルＡは、クラスタ番号00000010h〜0000001Fhの順による１６クラスタの連結により形成されるものとして管理されていることとなり、図１０に示したファイルＡのクラスタチェイン構造と一致している。
なお、図１０によるとファイルＡのデータ部Ａ２の領域は、クラスタ番号［00000013h〜0000001Ch］である。図１３では、図示を見やすいものとするために、このデータ部Ａ２の領域となるクラスタ番号のＦＡＴエントリ／ＦＡＴ１の纏まりを、太枠で囲って示している。
なお、図１０によるとファイルＡのデータ部Ａ２の領域は、クラスタ番号［00000013h〜0000001Ch］である。図１３では、図示を見やすいものとするために、このデータ部Ａ２の領域となるクラスタ番号のＦＡＴエントリ／ＦＡＴ１の纏まりを、太枠で囲って示している。
そして、ファイルＡにおけるデータ部Ａ２の先頭クラスタのクラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ１を参照してみると、30000014hが格納されている。つまり、上位４ビットのビット値としては、0,0,1,1となっており、引用ファイル数として３が示されていることが分かる。つまり、ファイルＡのデータ部Ａ２を引用元とするヘッダ／リソース編集ファイルとして、ファイルＢ，Ｃ，Ｄの３つとしていることに対応した値が格納されている。
続いて、同じ図１３を参照して、ファイルＡを基とするヘッダ／リソース編集ファイルの１つであるファイルＢについてのＦＡＴ領域上での管理内容について説明する。なお、この説明にあたっては、図において○印内に示す番号に従った手順で説明していく。
図１２（ｂ）に示した、ファイルＢに対応するディレクトリエントリの先頭クラスタ番号を参照すると00000020hが示されている。そこで、図１３の手順１として示すようにして、先ずは、クラスタ番号00000020hのＦＡＴエントリ／ＦＡＴ１を参照することになる。図１０にて説明したようにファイルＢのヘッダ部Ａ１は、クラスタ00000020hの１クラスタのみとされている。従って、このファイルＢのヘッダ部Ａ１としてのクラスタ00000020hは、ヘッダ部Ａ１における開始クラスタでもあるが、終端クラスタでもあることになる。
そして、このヘッダ部Ａ１における終端クラスタとしてのクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１には、図示するようにして、80000013hが格納されている。この場合、ＦＡＴエントリ／ＦＡＴ１の第０ビット〜第４ビットについて、8hの値となっているということは、ビット値としては、1,0,0,0とされていることになる。つまり、図１１に示した引用元指示フラグについてビット値１が格納されていることになる。これにより、このクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１の下位２８ビットは、チェイン先のクラスタ番号ではなく、引用元のデータの開始クラスタ番号を示していることになる。
従って、この場合のＦＡＴエントリ／ＦＡＴ１の下位２８ビットは、ファイルＡのデータ部Ａ２の開始クラスタ番号を示すこととなる。ファイルＡのデータ部Ａ２の開始クラスタ番号としては00000013hであり、手順１として参照するクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１には、上記のようにして、80000013hが格納される。つまり、引用元となるファイルＡのデータ部Ａ２の開始クラスタ番号を下位２８ビットにより示している。
図１２（ｂ）に示した、ファイルＢに対応するディレクトリエントリの先頭クラスタ番号を参照すると00000020hが示されている。そこで、図１３の手順１として示すようにして、先ずは、クラスタ番号00000020hのＦＡＴエントリ／ＦＡＴ１を参照することになる。図１０にて説明したようにファイルＢのヘッダ部Ａ１は、クラスタ00000020hの１クラスタのみとされている。従って、このファイルＢのヘッダ部Ａ１としてのクラスタ00000020hは、ヘッダ部Ａ１における開始クラスタでもあるが、終端クラスタでもあることになる。
そして、このヘッダ部Ａ１における終端クラスタとしてのクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１には、図示するようにして、80000013hが格納されている。この場合、ＦＡＴエントリ／ＦＡＴ１の第０ビット〜第４ビットについて、8hの値となっているということは、ビット値としては、1,0,0,0とされていることになる。つまり、図１１に示した引用元指示フラグについてビット値１が格納されていることになる。これにより、このクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１の下位２８ビットは、チェイン先のクラスタ番号ではなく、引用元のデータの開始クラスタ番号を示していることになる。
従って、この場合のＦＡＴエントリ／ＦＡＴ１の下位２８ビットは、ファイルＡのデータ部Ａ２の開始クラスタ番号を示すこととなる。ファイルＡのデータ部Ａ２の開始クラスタ番号としては00000013hであり、手順１として参照するクラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１には、上記のようにして、80000013hが格納される。つまり、引用元となるファイルＡのデータ部Ａ２の開始クラスタ番号を下位２８ビットにより示している。
そこで、手順２としては、上記クラスタ番号00000020hに対応するＦＡＴエントリ／ＦＡＴ１が指示するクラスタ番号00000013hのＦＡＴエントリ／ＦＡＴ１を参照することになる。クラスタ番号00000013hは、これまでの説明から理解されるように、ファイルＡのデータ部Ａ２の開始クラスタである、また、このクラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ１の上位４ビットについて、3hとされていることで、このデータ部Ａ２を引用するファイル数を示すようにされている。
また、この場合のクラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ１は、現ヘッダ／リソース編集ファイル（ここではファイルＢ）により引用されるデータ部Ａ２の先頭クラスタに対応するが、本実施の形態では、手順３として、これと同じクラスタ番号のＦＡＴエントリ／ＦＡＴ２も参照しておくようにされる。つまり、ここでは、クラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ２を参照する。
この位置のＦＡＴエントリ／ＦＡＴ２は、現ヘッダ／リソース編集ファイルが引用するデータ部Ａ２の終端クラスタ番号を格納するものとして規定されている。ファイルＢにとっての引用元であるファイルＡのデータ部Ａ２の終端クラスタは、図１０及び図１３のＦＡＴ１にも示されるように0000001Chであり、クラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ２にも、この値が格納されている。
また、この場合のクラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ１は、現ヘッダ／リソース編集ファイル（ここではファイルＢ）により引用されるデータ部Ａ２の先頭クラスタに対応するが、本実施の形態では、手順３として、これと同じクラスタ番号のＦＡＴエントリ／ＦＡＴ２も参照しておくようにされる。つまり、ここでは、クラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ２を参照する。
この位置のＦＡＴエントリ／ＦＡＴ２は、現ヘッダ／リソース編集ファイルが引用するデータ部Ａ２の終端クラスタ番号を格納するものとして規定されている。ファイルＢにとっての引用元であるファイルＡのデータ部Ａ２の終端クラスタは、図１０及び図１３のＦＡＴ１にも示されるように0000001Chであり、クラスタ番号00000013hに対応するＦＡＴエントリ／ＦＡＴ２にも、この値が格納されている。
ここで、先の手順２により、引用元であるファイルＡのデータ部Ａ２の先頭クラスタに対応するクラスタ番号00000013hのＦＡＴエントリ／ＦＡＴ１を参照して、以降、クラスタチェインを辿っていくと、先ず、図１３のＦＡＴ１において太枠で囲っているＦＡＴエントリが順次参照されていくことになる。
ここで仮に、通常にクラスタチェインを辿っていくと最終的には、クラスタ番号0000001FhのＦＡＴエントリ／ＦＡＴ１が示すEOFに到達して終了してしまうことになる。つまり、リソース部Ａ３としては、ファイルＢのものではなく、ファイルＡのものが連結されるという不都合が生じる。
しかし、先に手順３により、引用元となるデータを格納する終端クラスタ番号の情報を得ていることで、上記した不都合は生じない。つまり、ヘッダ／リソース編集ファイルについては、上記手順２以降においてＦＡＴエントリを参照して継続されるクラスタチェインは、上記手順３により得た終端クラスタ番号までで一旦止めることとしている。具体的には、引用元であるファイルＡのデータ部Ａ２についての、開始クラスタ番号00000013hからのクラスタチェインは、終端クラスタ番号0000001Chのクラスタにて止められる。これにより、上記したようにファイルＡのリソース部のクラスタがチェインされることにはならない。
ここで仮に、通常にクラスタチェインを辿っていくと最終的には、クラスタ番号0000001FhのＦＡＴエントリ／ＦＡＴ１が示すEOFに到達して終了してしまうことになる。つまり、リソース部Ａ３としては、ファイルＢのものではなく、ファイルＡのものが連結されるという不都合が生じる。
しかし、先に手順３により、引用元となるデータを格納する終端クラスタ番号の情報を得ていることで、上記した不都合は生じない。つまり、ヘッダ／リソース編集ファイルについては、上記手順２以降においてＦＡＴエントリを参照して継続されるクラスタチェインは、上記手順３により得た終端クラスタ番号までで一旦止めることとしている。具体的には、引用元であるファイルＡのデータ部Ａ２についての、開始クラスタ番号00000013hからのクラスタチェインは、終端クラスタ番号0000001Chのクラスタにて止められる。これにより、上記したようにファイルＡのリソース部のクラスタがチェインされることにはならない。
すると、この次には、ファイルＡのデータ部Ａ２の終端クラスタ番号0000001Chに続けて、ファイルＢのリソース部Ａ３の開始クラスタがチェインされるべきこととなる。このために、引用元データ（ファイルＡのデータ部Ａ２）から、本来のヘッダ／リソース編集ファイルのデータに復帰するようにしてチェインをつくる仕組みとして、ＦＡＴ２においては、復帰先クラスタ番号を示すＦＡＴエントリを設けることとしている。
この復帰先クラスタ番号は、引用元データの開始クラスタ番号を格納するＦＡＴエントリ／ＦＡＴ１と同じクラスタ番号に対応するＦＡＴエントリ／ＦＡＴ２に格納することとしている。具体的には、ファイルＢの場合であれば、引用元データの開始クラスタ番号を格納するＦＡＴエントリ／ＦＡＴ１は、先に手順１により参照したクラスタ番号00000010hに対応するものであるから、復帰先クラスタ番号は、同じクラスタ番号00000010hに対応するＦＡＴエントリ／ＦＡＴ２に格納されることになる。
手順４としては、このＦＡＴエントリ／ＦＡＴ２における復帰先クラスタ番号を参照するようにされる。これにより、引用元データの終端クラスタにチェインさせるクラスタが認識される。図１３のファイルＢの場合には、この復帰先クラスタ番号として、00000021hが格納されている。
そして、次の手順５として、この場合の引用元データであるファイルＡのデータ部Ａ２の終端クラスタ番号0000001Chから、上記復帰先クラスタ番号00000021hにクラスタチェインさせることになる。つまり、クラスタ番号0000001ChのＦＡＴエントリ／ＦＡＴ１には、0000001Dhが格納されているのにかかわらず、この場合には、クラスタ番号00000021hのＦＡＴエントリ／ＦＡＴ１を参照すべきことになる。クラスタ番号00000021hのクラスタは、ファイルＢのリソース部Ａ３の開始クラスタである。これにより、ファイルＡのデータ部Ａ２の終端クラスタから、ファイルＢのリソース部Ａ３の開始クラスタに対してチェインが行われたことになる。以降、クラスタ番号00000021hのＦＡＴエントリ／ＦＡＴ１を起点としてクラスタチェインを辿ることで、クラスタ番号00000021h−00000022h−00000023hの順によるクラスタチェインでリソース部Ａ３を形成してEOFに至ることになる。
このようにして、ＦＡＴ１，ＦＡＴ２のＦＡＴ領域を使用することで、ファイルＢについては、図１０により示したとおりの構造で管理されることになる。
また、ここでの詳しい説明は省略するが、上記と同じ要領でクラスタチェインを辿っていくことで、他のヘッダ／リソース編集ファイルであるファイルＣ，Ｄについても、同じく図１０に示したファイル構造により管理されるものとなる。
この復帰先クラスタ番号は、引用元データの開始クラスタ番号を格納するＦＡＴエントリ／ＦＡＴ１と同じクラスタ番号に対応するＦＡＴエントリ／ＦＡＴ２に格納することとしている。具体的には、ファイルＢの場合であれば、引用元データの開始クラスタ番号を格納するＦＡＴエントリ／ＦＡＴ１は、先に手順１により参照したクラスタ番号00000010hに対応するものであるから、復帰先クラスタ番号は、同じクラスタ番号00000010hに対応するＦＡＴエントリ／ＦＡＴ２に格納されることになる。
手順４としては、このＦＡＴエントリ／ＦＡＴ２における復帰先クラスタ番号を参照するようにされる。これにより、引用元データの終端クラスタにチェインさせるクラスタが認識される。図１３のファイルＢの場合には、この復帰先クラスタ番号として、00000021hが格納されている。
そして、次の手順５として、この場合の引用元データであるファイルＡのデータ部Ａ２の終端クラスタ番号0000001Chから、上記復帰先クラスタ番号00000021hにクラスタチェインさせることになる。つまり、クラスタ番号0000001ChのＦＡＴエントリ／ＦＡＴ１には、0000001Dhが格納されているのにかかわらず、この場合には、クラスタ番号00000021hのＦＡＴエントリ／ＦＡＴ１を参照すべきことになる。クラスタ番号00000021hのクラスタは、ファイルＢのリソース部Ａ３の開始クラスタである。これにより、ファイルＡのデータ部Ａ２の終端クラスタから、ファイルＢのリソース部Ａ３の開始クラスタに対してチェインが行われたことになる。以降、クラスタ番号00000021hのＦＡＴエントリ／ＦＡＴ１を起点としてクラスタチェインを辿ることで、クラスタ番号00000021h−00000022h−00000023hの順によるクラスタチェインでリソース部Ａ３を形成してEOFに至ることになる。
このようにして、ＦＡＴ１，ＦＡＴ２のＦＡＴ領域を使用することで、ファイルＢについては、図１０により示したとおりの構造で管理されることになる。
また、ここでの詳しい説明は省略するが、上記と同じ要領でクラスタチェインを辿っていくことで、他のヘッダ／リソース編集ファイルであるファイルＣ，Ｄについても、同じく図１０に示したファイル構造により管理されるものとなる。
上記図１０〜図１３による例説のようにしてＦＡＴ領域を使用するように規定することで、本実施の形態では、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を引用（共有）する構造を有するようにしてＦＡＴファイルシステム上で管理されることになる。
ここで、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を引用（共有）する構造として管理されるためには、２つのことが管理される必要がある。１つは、ヘッダ／リソース編集ファイルのヘッダ部Ａ１の終端に続けて、オリジナルファイルのデータ部Ａ２の先頭がチェイン（連結）されるように管理されることである。また、もう１つは、オリジナルファイルのデータ部Ａ２の終端に続けて、ヘッダ／リソース編集ファイルのリソース部Ａ３の先頭がチェイン（連結）されるように管理されることである。
ここで、ヘッダ／リソース編集ファイルが、オリジナルファイルのデータ部Ａ２を引用（共有）する構造として管理されるためには、２つのことが管理される必要がある。１つは、ヘッダ／リソース編集ファイルのヘッダ部Ａ１の終端に続けて、オリジナルファイルのデータ部Ａ２の先頭がチェイン（連結）されるように管理されることである。また、もう１つは、オリジナルファイルのデータ部Ａ２の終端に続けて、ヘッダ／リソース編集ファイルのリソース部Ａ３の先頭がチェイン（連結）されるように管理されることである。
図１３の説明から理解されるように、本実施の形態では、前者の管理のために、ＦＡＴ１におけるヘッダ／リソース編集ファイルのヘッダ部Ａ１の最終クラスタ(ファイルＢでは00000020h)のＦＡＴエントリに対して、引用元フラグ＝１をセットするとともに、オリジナルファイル（ファイルＡ）のデータ部Ａ２の開始クラスタの番号を格納するようにされる(この結果、80000013hを格納している）。
また、後者の管理のためには、ＦＡＴ２に対して、復帰先クラスタ番号、及び引用データの終端クラスタ番号を格納することとしている。
また、後者の管理のためには、ＦＡＴ２に対して、復帰先クラスタ番号、及び引用データの終端クラスタ番号を格納することとしている。
なお、復帰先クラスタ番号及び引用データの終端クラスタ番号を格納すべきＦＡＴ２内のＦＡＴエントリの位置としては、他にも考えることができる。しかしながら、本実施の形態のようにして、「復帰先クラスタ番号については、ヘッダ／リソース編集ファイルのヘッダ部Ａ１の終端クラスタのＦＡＴエントリ／ＦＡＴ１と同じ位置のＦＡＴエントリ／ＦＡＴ２とする」、また、「引用データの終端クラスタ番号については、オリジナルファイルのデータ部Ａ２の開始クラスタのＦＡＴエントリ／ＦＡＴ１と同じ位置のＦＡＴエントリ／ＦＡＴ２とする」ことで、これら復帰先クラスタ番号及び引用データの終端クラスタ番号を参照するのにあたって、参照位置を求めるための複雑な演算処理などは実行する必要が無い。これにより、例えばヘッダ／リソース編集ファイルの新規生成／保存のためのｄＦＡＴ領域の編集（書き換え）処理や、ヘッダ／リソース編集ファイルを再生するときのＦＡＴ領域の参照処理などについて軽いものとすることができる。
そして、上記のようなヘッダ／リソース編集ファイルを管理するためのＦＡＴ領域の内容は、このヘッダ／リソース編集ファイルを新規に生成してメディアに記録（保存）するときに応じて、ファイルシステム情報（ディレクトリエントリ及びＦＡＴ領域）を更新することで得られるものとなる。
そこで、続いては、本実施の形態においてヘッダ／リソース編集ファイルを新規に生成／保存するための処理について説明する。
そこで、続いては、本実施の形態においてヘッダ／リソース編集ファイルを新規に生成／保存するための処理について説明する。
先ず、本実施の形態におけるヘッダ／リソース編集ファイルの新規生成／保存を、先に図２に示したＦＡＴファイルシステムからみた場合の処理として考えた場合には、次のようになる。
ヘッダ／リソース編集ファイルは、これまでの説明から理解されるように、ヘッダ部Ａ１及びリソース部Ａ３については、そのヘッダ／リソース編集ファイルのみに対応するデータであり、少なくとも何れか一方の内容は、オリジナルファイルに対して変更が与えられている。これに対して、データ部Ａ２については、オリジナルファイルから引用しているものであり、本来はオリジナルファイルの構成要素となる。
このために、ヘッダ部Ａ１とリソース部Ａ３については、先に図８により説明した手順１〜手順４を、それぞれヘッダ部Ａ１の内容のデータについて繰り返し実行し、ソース部Ａ３の内容のデータについて繰り返し実行するようにされる。これにより、オリジナルファイルのヘッダ部Ａ１及びリソース部Ａ３について変更した内容がメディアに実際に記録されることになる。
これに対して、オリジナルファイルからの内容変更が無いデータ部Ａ２については、図８の手順１〜手順４による処理は実行せずに、これに代えて、図１４に示す手順を実行する。
このために、ヘッダ部Ａ１とリソース部Ａ３については、先に図８により説明した手順１〜手順４を、それぞれヘッダ部Ａ１の内容のデータについて繰り返し実行し、ソース部Ａ３の内容のデータについて繰り返し実行するようにされる。これにより、オリジナルファイルのヘッダ部Ａ１及びリソース部Ａ３について変更した内容がメディアに実際に記録されることになる。
これに対して、オリジナルファイルからの内容変更が無いデータ部Ａ２については、図８の手順１〜手順４による処理は実行せずに、これに代えて、図１４に示す手順を実行する。
つまり、先ず、図１４の手順１として示すように、アプリケーション１００としては、ヘッダ／リソース編集ファイルにおけるデータ部Ａ２のデータについての書き込み要求をファイルシステム１０１に対して発行する。
ファイルシステム１０１では、データの書き込み要求が、上記手順１のようにしてヘッダ／リソース編集ファイルにおけるデータ部Ａ２についてのものである場合には、手順２として示すように、リソース編集ファイルのデータ部Ａ２について、オリジナルファイルのデータ部Ａ２が引用されるようにする（つまり、ヘッダ／リソース編集ファイルのデータ部Ａ１の終端に続けてオリジナルファイルのデータ部Ａ２の先頭がチェインされ、このデータ部Ａ２の終端に続けてヘッダ／リソース編集ファイルのリソース部Ａ３がチェインされるようにする）ためのＦＡＴ領域の編集処理を実行する。
この処理に応じて、デバイスドライバ１０２は、メディアのＦＡＴ１，ＦＡＴ２の領域において必要とされるＦＡＴエントリの内容を書き換えるようにして、メディアに対するアクセスを実行する。このデバイスドライバ１０２によるアクセスにより、実際のメディアに記録されるＦＡＴ１，ＦＡＴ２としては、リソース編集ファイルについてオリジナルファイルのデータ部Ａ２を引用する構造として管理する内容を有することになる。
ファイルシステム１０１では、データの書き込み要求が、上記手順１のようにしてヘッダ／リソース編集ファイルにおけるデータ部Ａ２についてのものである場合には、手順２として示すように、リソース編集ファイルのデータ部Ａ２について、オリジナルファイルのデータ部Ａ２が引用されるようにする（つまり、ヘッダ／リソース編集ファイルのデータ部Ａ１の終端に続けてオリジナルファイルのデータ部Ａ２の先頭がチェインされ、このデータ部Ａ２の終端に続けてヘッダ／リソース編集ファイルのリソース部Ａ３がチェインされるようにする）ためのＦＡＴ領域の編集処理を実行する。
この処理に応じて、デバイスドライバ１０２は、メディアのＦＡＴ１，ＦＡＴ２の領域において必要とされるＦＡＴエントリの内容を書き換えるようにして、メディアに対するアクセスを実行する。このデバイスドライバ１０２によるアクセスにより、実際のメディアに記録されるＦＡＴ１，ＦＡＴ２としては、リソース編集ファイルについてオリジナルファイルのデータ部Ａ２を引用する構造として管理する内容を有することになる。
そして、上記のようにして、デバイスドライバ１０２によるＦＡＴ領域のデータの書き換え、つまりＦＡＴ領域の編集が完了したとされると、手順３として、このことをデバイスドライバ１０２からファイルシステム１０１に通知する。そして、ファイルシステム１０１は、このＦＡＴ領域の編集の完了の通知を受けると、手順４として示すように、ヘッダ／リソース編集ファイルのデータ部Ａ２についてのデータの書き換えが完了したものとしてアプリケーション１００に通知するようにされる。この通知を受けることで、アプリケーション１００は、ヘッダ／リソース編集ファイルのデータ部Ａ２についてのデータの書き込みが完了したと認識する。
また、ヘッダ／リソース編集ファイルの新規生成／保存のためにＣＰＵ１０が実行するとされる処理を図１５のフローチャートに示す。この図に示す処理は、ＣＰＵ１０が、例えばＲＯＭ１１（あるいはメディアコントローラ１３と接続されるメディアなどとされてもよい）に記憶されているプログラムを実行することで、アプリケーション１００、ファイルシステム１０１、デバイスドライバ１０２としてのソフトウェア処理が連携して実現される。
例えば、アプリケーション１００のレベルでの処理によって、オリジナルファイルを基として、ヘッダ部Ａ１又はリソース部Ａ２についての変更を伴う編集を行ったうえで、例えば、オリジナルファイルに対する内容の変更を、オリジナルファイルとは別のファイルとして新規に保存させるための要求が発行されたとする。この場合、新規保存させるべきファイルは、オリジナルファイルとの内容比較としては、ヘッダ部Ａ１又はリソース部Ａ２についてのみ変更があり、データ部Ａ２については変更が無い。このような条件を満たしている場合には、この新規保存させるべきファイルは、これまでに説明してきたヘッダ／リソース編集ファイルということになる。この場合に、ファイルの新規生成／保存のための処理として、図１５に示す、ヘッダ／リソース編集ファイルの新規生成／保存処理を実行する。
ヘッダ／リソース編集ファイルの新規生成／保存を実行するにあたっては、先ず、ステップＳ１０１によりオリジナルファイルをreadモードでオープンするためのファイルオープンの処理を実行する。例えば、この処理に応じて、ヘッダ／リソース編集ファイルについてのディレクトリエントリが用意され、また、書き込みのためのクラスタ領域を確保するなどの処理が行われる。また、これに続くとされるステップＳ１０２により、今回の新規作成対象となっているヘッダ／リソース編集ファイルについてのwriteモードでのファイルオープンの処理を実行する。
次のステップＳ１０３においては、オリジナルファイルにおけるヘッダ部Ａ１のデータについての読み込みを実行する。そして、次のステップＳ１０４において、上記ステップＳ１０３にて読み込んだオリジナルファイルのヘッダ部Ａ１の内容を基として、必要に応じてデータ内容を変更しながら、ヘッダ／リソース編集ファイルのヘッダ部Ａ１としてのデータ内容を作成し、このデータについてのメディアへの書き込みを実行する。
このステップＳ１０３及びステップＳ１０４の処理は、ヘッダ部Ａ１のデータについて、先に図８に示した手順１〜手順４を繰り返すことに対応する。
このステップＳ１０３及びステップＳ１０４の処理は、ヘッダ部Ａ１のデータについて、先に図８に示した手順１〜手順４を繰り返すことに対応する。
上記ステップＳ１０３、Ｓ１０４の処理が完了することで、先ず、ヘッダ／リソース編集ファイルとしてのヘッダ部Ａ１のデータの書き込みが完了したことになる。ここでは、ＡＶファイル構造としては、ヘッダ部Ａ１に続けてデータ部Ａ２を配置することとしているので、続くステップＳ１０５からステップＳ１０９までは、ヘッダ／リソース編集ファイルのデータ部Ａ２についての処理を実行するようにされる。つまり、ヘッダ／リソース編集ファイルのデータ部Ａ２としては、オリジナルファイルのデータ部Ａ２が引用されるようにして管理されるようにするためのＦＡＴ領域についての編集処理を実行する。この処理は、ファイルシステム階層モデルの観点では、図１４により説明した手順１〜手順４が対応する。
先ず、ステップＳ１０５では、オリジナルファイルのデータ部Ａ２としてのデータを格納するクラスタのうちで先頭となるクラスタ、つまり、データ部Ａ２の開始位置を含むクラスタのクラスタ番号numdtを認識する。このためには、例えば先ず、オリジナルファイルのヘッダ部Ａ１にアクセスしてデータの読み込みを行ってその内容を解析し、オリジナルファイルのデータ部Ａ２のデータ位置を認識し、この認識したデータ位置をクラスタ換算することで得るようにされる。
次のステップＳ１０６では、ヘッダ／リソース編集ファイルのヘッダ部Ａ１に続けて、オリジナルファイルのデータ部Ａ２がチェインされるようにするための処理を実行する。つまり、この段階では、先のステップＳ１０４の処理を経ていることで、ヘッダ／リソース編集ファイルのヘッダ部Ａ１としてのデータの書き込みは完了している。そして、この書き込み済みのヘッダ部Ａ１としてのデータを格納するクラスタのうちで終端となるクラスタに続けて、オリジナルファイルのデータ部Ａ２のデータ開始位置を格納するクラスタがチェインするものとして管理されるようにＦＡＴ領域の内容を変更するものである。
このために、ステップＳ１０６としては、先ず、ヘッダ／リソース編集ファイルのヘッダ部Ａ１のデータを格納するクラスタのうちで終端となるクラスタのクラスタ番号numheを認識する。そして、ＦＡＴ１の領域において、このクラスタ番号numheに対応するＦＡＴエントリの下位２８ビットに対して、上記ステップＳ１０５にて認識したクラスタ番号numdtを格納する。また、同じＦＡＴエントリの先頭ビット（第０ビット）のビット位置に対して、引用元指示フラグとして１の値をセットする。これにより、図１３の場合であれば、ファイルＢのヘッダ部Ａ１の終端クラスタに対応するＦＡＴ１のクラスタ番号00000020hに格納すべき値（80000013h）が確定されることになる。
また、ステップＳ１０６では、ヘッダ／リソース編集ファイルの復帰先クラスタ番号numrtを決定する。この復帰先クラスタ番号numrtは、図１３による説明から分かるように、ヘッダ／リソース編集ファイルのリソース部Ａ３の記録を開始するクラスタ番号と同一となる。そこで、復帰先クラスタ番号numrtを決定するのにあたっては、例えばＦＡＴ１を参照するなどして現段階での空きクラスタを認識し、この空きクラスタのうちから所定規則に従ってリソース部Ａ３の記録を開始するクラスタを決定する。この決定されたクラスタの番号が復帰先クラスタ番号numrtとなる。
そして、ここでは、上記のようにして決定した復帰先クラスタ番号numrtを、ヘッダ／リソース編集ファイルのヘッダ部Ａ１の終端クラスタのクラスタ番号のＦＡＴエントリ／ＦＡＴ２に対して格納するようにされる。図１３におけるファイルＢとの対応では、ＦＡＴ２における00000020hのＦＡＴエントリに対して00000021hを格納している状態が、この処理結果に相当する。
そして、ここでは、上記のようにして決定した復帰先クラスタ番号numrtを、ヘッダ／リソース編集ファイルのヘッダ部Ａ１の終端クラスタのクラスタ番号のＦＡＴエントリ／ＦＡＴ２に対して格納するようにされる。図１３におけるファイルＢとの対応では、ＦＡＴ２における00000020hのＦＡＴエントリに対して00000021hを格納している状態が、この処理結果に相当する。
次のステップＳ１０７においては、オリジナルファイルのデータ部Ａ２のデータを格納するクラスタのうちで終端となるクラスタ、つまり、データ部Ａ２のデータの終端位置を格納するクラスタの番号numdeを認識する。
そして、続くステップＳ１０８においては、先のステップＳ１０５において認識したクラスタ番号numdtに対応するＦＡＴ２のＦＡＴエントリに対して、上記ステップＳ１０７により認識したクラスタ番号numdeを格納する。これは、図１３との対応では、ＦＡＴ２のクラスタ番号00000013hのＦＡＴエントリに対して、0000001Chを格納する処理となる。つまり、ステップＳ１０８において認識したオリジナルファイルのデータ部Ａ２の終端クラスタ番号は、ヘッダ／リソース編集ファイルにとって引用元となるデータを格納するクラスタのうちで終端となるクラスタの番号としての意義を持つ。
そして、続くステップＳ１０８においては、先のステップＳ１０５において認識したクラスタ番号numdtに対応するＦＡＴ２のＦＡＴエントリに対して、上記ステップＳ１０７により認識したクラスタ番号numdeを格納する。これは、図１３との対応では、ＦＡＴ２のクラスタ番号00000013hのＦＡＴエントリに対して、0000001Chを格納する処理となる。つまり、ステップＳ１０８において認識したオリジナルファイルのデータ部Ａ２の終端クラスタ番号は、ヘッダ／リソース編集ファイルにとって引用元となるデータを格納するクラスタのうちで終端となるクラスタの番号としての意義を持つ。
ステップＳ１０９では、ＦＡＴ１におけるクラスタ番号numdtに対応するＦＡＴエントリにアクセスして、このＦＡＴエントリにおける上位２番目から４番目（第１〜第３ビット）までの３ビットの領域が示す値、つまり引用ファイル数について、１インクリメントした値をセットする。これにより、ＦＡＴ１のオリジナルファイルのデータ部Ａ２の先頭クラスタに格納する引用ファイル数の情報として、今回新規に保存するヘッダ／リソース編集ファイルの数が含められることになる。
このようにしてステップＳ１０５〜ステップＳ１０９の処理が実行されることで、例えばＦＡＴ２に対する復帰先クラスタ番号及び引用データの終端クラスタ番号の書き込み、また、ＦＡＴ１の引用ファイル数の情報についての書き換えが行われることになる。つまり、オリジナルファイルのデータ部Ａ２を、今回新規に生成／保存するヘッダ／リソース編集ファイルが引用できるようにするためのＦＡＴ領域の内容の書き換えが完了したことになる。
なお、図１３から理解されるように、ＦＡＴ１におけるオリジナルファイルのデータ部Ａ２の開始クラスタ番号に対応するＦＡＴエントリ／ＦＡＴ２に格納される引用データの終端クラスタ番号は、１つのオリジナルファイルに対して複数のヘッダ／リソース編集ファイルが存在する場合には、これらのヘッダ／リソース編集ファイル間で共通に参照するものとなる。従って、ステップＳ１０８としての引用データの終端クラスタ番号を格納する処理は、或るオリジナルファイルに対して最初となるヘッダ／リソース編集ファイルを新規生成／保存するときにのみ実行して、同じオリジナルファイルに対して２番目以降のヘッダ／リソース編集ファイルを新規生成／保存するときには、省略するようにしてよい。ただし、ステップＳ１０８の処理をヘッダ／リソース編集ファイルを新規生成／保存するごとに実行したとしても、結果的に同じ値で書き換えられるのみであり実質的な内容変更は生じないので、何ら問題はない。
このようにしてステップＳ１０５〜ステップＳ１０９の処理が実行されることで、例えばＦＡＴ２に対する復帰先クラスタ番号及び引用データの終端クラスタ番号の書き込み、また、ＦＡＴ１の引用ファイル数の情報についての書き換えが行われることになる。つまり、オリジナルファイルのデータ部Ａ２を、今回新規に生成／保存するヘッダ／リソース編集ファイルが引用できるようにするためのＦＡＴ領域の内容の書き換えが完了したことになる。
なお、図１３から理解されるように、ＦＡＴ１におけるオリジナルファイルのデータ部Ａ２の開始クラスタ番号に対応するＦＡＴエントリ／ＦＡＴ２に格納される引用データの終端クラスタ番号は、１つのオリジナルファイルに対して複数のヘッダ／リソース編集ファイルが存在する場合には、これらのヘッダ／リソース編集ファイル間で共通に参照するものとなる。従って、ステップＳ１０８としての引用データの終端クラスタ番号を格納する処理は、或るオリジナルファイルに対して最初となるヘッダ／リソース編集ファイルを新規生成／保存するときにのみ実行して、同じオリジナルファイルに対して２番目以降のヘッダ／リソース編集ファイルを新規生成／保存するときには、省略するようにしてよい。ただし、ステップＳ１０８の処理をヘッダ／リソース編集ファイルを新規生成／保存するごとに実行したとしても、結果的に同じ値で書き換えられるのみであり実質的な内容変更は生じないので、何ら問題はない。
上記ステップＳ１０９の処理が完了した後は、データ部Ａ２に続けて配置されるべきリソース部Ａ３についての処理を実行することになる。先ず、ステップＳ１１０では、オリジナルファイルのリソース部Ａ３にアクセスして読み込みを実行する。続いて、ステップＳ１１１において、ステップＳ１１０により読み込んだオリジナルファイルのリソース部Ａ３の内容を基として、必要に応じてデータ内容を変更しながら、ヘッダ／リソース編集ファイルのリソース部Ａ３としてのデータ内容を作成する。そして、このデータについてのメディアへの書き込みを実行する。
このステップＳ１１１の処理により、ヘッダ／リソース編集ファイルについてのリソース部Ａ３のメディアへの記録が完了することを以て、ヘッダ／リソース編集ファイルについてのヘッダ部Ａ１とリソース部Ａ３の書き込みと、オリジナルファイルのデータ部Ａ２を引用するためのＦＡＴ内容の変更が完了したことになる。つまり、ヘッダ／リソース編集ファイルのメディアへの記録が完了したとされる状態が得られたことになる。
なお、ステップＳ１１１としての書き込み処理としては、復帰先クラスタ番号numrtが示すクラスタを起点として記録を開始することになる。また、上記ステップＳ１１０、Ｓ１１１の処理としても、ファイルシステムの階層モデルとしてみた場合には、先のステップＳ１０３、Ｓ１０４と同様に、図８に示した手順が相当する。
このステップＳ１１１の処理により、ヘッダ／リソース編集ファイルについてのリソース部Ａ３のメディアへの記録が完了することを以て、ヘッダ／リソース編集ファイルについてのヘッダ部Ａ１とリソース部Ａ３の書き込みと、オリジナルファイルのデータ部Ａ２を引用するためのＦＡＴ内容の変更が完了したことになる。つまり、ヘッダ／リソース編集ファイルのメディアへの記録が完了したとされる状態が得られたことになる。
なお、ステップＳ１１１としての書き込み処理としては、復帰先クラスタ番号numrtが示すクラスタを起点として記録を開始することになる。また、上記ステップＳ１１０、Ｓ１１１の処理としても、ファイルシステムの階層モデルとしてみた場合には、先のステップＳ１０３、Ｓ１０４と同様に、図８に示した手順が相当する。
そして、ステップＳ１１２により、オリジナルファイルと、今回の新規生成／保存対象であったヘッダ／リソース編集ファイルとについてファイルクローズの処理を実行することで、ヘッダ／リソース編集ファイルの新規生成／保存のための一連の処理が終了されることになる。
参考として、図２に示したファイルシステム階層モデルにおいて、ファイルシステム１０１の内部機能についてより詳細に示した構成例を、図１６に示しておくこととする。なお、この図においては、図２と同様に、アプリケーション１００、ファイルシステム１０１、デバイスドライバ１０２、及びメディア１０３によるシステム階層モデル全体を示している。
この図に示すようにして、ファイルシステム１０１としてソフトウェアが実行する処理を機能ブロックとしてみた場合には、記録制御部２００及びメディア制御部２１０を備えて構成されるものとみることができる。
記録制御部２００は、メディアに対するデータの記録（書き込み）及び読み出しに関する各種制御処理を実行するもので、ディレクトリエントリ制御部２０１、ＦＡＴ制御部２０２、及びクラスタ制御部２０３を備える。また、メディア制御部２１０は、ファイルシステムがメディアに対するコントロールを行うために、デバイスドライバ１０２側とデータの授受を行うことが可能な機能部位として位置算出部２１１を備える。
記録制御部２００内のディレクトリエントリ制御部２０１は、例えばメディアに対するファイルの書き込み、消去などのデータ処理結果に応じてディレクトリエントリを作成、削除、更新するなど、ディレクトリエントリについての各種所要の制御処理を実行する。ＦＡＴ制御部２０２は、メディアに対するファイルデータ処理結果に応じてＦＡＴ領域における所定のＦＡＴエントリについての書き換えを実行するなど、ＦＡＴ領域についての各種所要の制御処理を実行する。クラスタ制御部２０３は、ファイルシステム内での処理がクラスタレベルで実行されるようにするための各種制御処理を実行する。
例えばメディアに書き込むためのデータが、ファイル単位の処理としてアプリケーション１００から渡されてきたとすると、クラスタ制御部２０３は、このファイルレベルのデータをクラスタレベルによるデータに変換する。そして、このクラスタレベルによるデータについてのメディアへの書き込みを、メディア制御部２１０の位置算出部２１１に指示する。
位置算出部２１１では、ＦＡＴ制御部２０２により管理しているＦＡＴ領域の内容を参照して認識されるメディアの未使用領域のうちから、ファイルのデータを書き込むべきクラスタの位置（クラスタ番号）を算出する。そして、デバイスドライバ１０２に対して、書き込むべきクラスタ単位のデータを受け渡すと共に、このデータを書き込むべきクラスタ番号を指示する。デバイスドライバ１０２は、指示されたクラスタ番号について最終的には、メディア上の記憶領域の物理セクタのアドレスに変換して、セクタレベルによりメディアへのデータの書き込みを実行するようにされる。
例えばメディアに書き込むためのデータが、ファイル単位の処理としてアプリケーション１００から渡されてきたとすると、クラスタ制御部２０３は、このファイルレベルのデータをクラスタレベルによるデータに変換する。そして、このクラスタレベルによるデータについてのメディアへの書き込みを、メディア制御部２１０の位置算出部２１１に指示する。
位置算出部２１１では、ＦＡＴ制御部２０２により管理しているＦＡＴ領域の内容を参照して認識されるメディアの未使用領域のうちから、ファイルのデータを書き込むべきクラスタの位置（クラスタ番号）を算出する。そして、デバイスドライバ１０２に対して、書き込むべきクラスタ単位のデータを受け渡すと共に、このデータを書き込むべきクラスタ番号を指示する。デバイスドライバ１０２は、指示されたクラスタ番号について最終的には、メディア上の記憶領域の物理セクタのアドレスに変換して、セクタレベルによりメディアへのデータの書き込みを実行するようにされる。
また、これとともに、ファイルシステムでは、上記のようにしてメディアに書き込まれて記憶されるファイルがＦＡＴファイルシステム上で適正に管理されるように、ディレクトリエントリ及びＦＡＴ領域についての書き換え（更新）を行う。
例えば先ず、ディレクトリエントリ制御部２０１により今回記録するファイルについてのディレクトリエントリを作成する。このときには、ＦＡＴ制御部２０２と連携して、ＦＡＴ領域における空き領域から、ファイルを記録すべきクラスタを決定する。これに伴い、ディレクトリエントリにおける開始クラスタに格納する値も決まることになる。また、ファイルを記録すべきクラスタが決定されるのに応じて、ＦＡＴ制御部２０２は、ＦＡＴ領域において、このファイルについてのクラスタチェインなどの内容が示されるように、所要のクラスタ番号のＦＡＴエントリの値を書き換える。
そして、このようにして作成したディレクトリエントリ、及びＦＡＴ領域の書き換え内容を、先の説明と同様にして、クラスタ制御部２０３及びメディア制御部２１０（位置算出部２１１）の処理によって、メディアの所定領域に書き込んで記憶させる。
例えば先ず、ディレクトリエントリ制御部２０１により今回記録するファイルについてのディレクトリエントリを作成する。このときには、ＦＡＴ制御部２０２と連携して、ＦＡＴ領域における空き領域から、ファイルを記録すべきクラスタを決定する。これに伴い、ディレクトリエントリにおける開始クラスタに格納する値も決まることになる。また、ファイルを記録すべきクラスタが決定されるのに応じて、ＦＡＴ制御部２０２は、ＦＡＴ領域において、このファイルについてのクラスタチェインなどの内容が示されるように、所要のクラスタ番号のＦＡＴエントリの値を書き換える。
そして、このようにして作成したディレクトリエントリ、及びＦＡＴ領域の書き換え内容を、先の説明と同様にして、クラスタ制御部２０３及びメディア制御部２１０（位置算出部２１１）の処理によって、メディアの所定領域に書き込んで記憶させる。
本実施の形態において特有となる、図１３におけるステップＳ１０５〜Ｓ１０９の処理、つまり、オリジナルファイルのデータ部Ａ２が、ヘッダ／リソース編集ファイルのデータ部Ａ２としても共用されるようにしてファイル管理されるようにするための処理としては、主として、ＦＡＴ制御部２０２が実行すべきものとしてプログラムを構成することになる。
ところで、実際において、ヘッダ／リソース編集ファイルのヘッダ部Ａ１は、そのファイルに特有のファイル名、ファイルＩＤなどを格納するので、必ずオリジナルファイルに対して内容が変更されるが、リソース部Ａ３については変更されない場合がある。しかし、本実施の形態としての記載では、ヘッダ／リソース編集ファイルの新規生成／保存にあたり、ヘッダ部Ａ１及びリソース部Ａ３については、固定的に書込対象情報部として扱うこととして、常に図８に示した手順による書き換えの処理を実行させることとしている。
これは、ヘッダ部Ａ１とリソース部Ａ３は、データ部Ａ２と比較してそのサイズは非常に小さいので、例えばヘッダ部Ａ１のみがオリジナルファイルの内容から変更されて、リソース部Ａ３については変更する必要がないとしても、書き換えの処理時間は非常に短いために、実質上特に問題がないことが理由である。
しかしながら、本発明としては、例えばヘッダ／リソース編集ファイルとして、リソース部Ａ３について変更の無い場合には、リソース部Ａ３についても、データ部Ａ２と同様にして引用情報部として扱って、オリジナルファイルを引用できるようにファイル管理が行われるように構成してかまわない。
これは、ヘッダ部Ａ１とリソース部Ａ３は、データ部Ａ２と比較してそのサイズは非常に小さいので、例えばヘッダ部Ａ１のみがオリジナルファイルの内容から変更されて、リソース部Ａ３については変更する必要がないとしても、書き換えの処理時間は非常に短いために、実質上特に問題がないことが理由である。
しかしながら、本発明としては、例えばヘッダ／リソース編集ファイルとして、リソース部Ａ３について変更の無い場合には、リソース部Ａ３についても、データ部Ａ２と同様にして引用情報部として扱って、オリジナルファイルを引用できるようにファイル管理が行われるように構成してかまわない。
また、前述もしたように、ＦＡＴファイルシステムに従ってフォーマットされたメディアにおいては、ＦＡＴ１、ＦＡＴ２の２つのＦＡＴ領域が形成され、本実施の形態では、ＦＡＴ１をメインのＦＡＴ領域としたうえで、ＦＡＴ２の領域を復帰先クラスタ番号や引用データの終端クラスタ番号を格納すべき領域として使用している。
しかし、前述もしたように、ＦＡＴ２は、ＦＡＴ１の予備領域、バックアップ領域として、ＦＡＴ１と同様の内容がコピーされるようにして使用される場合がある。このために、仕様として、本実施の形態のようにして、１つのＦＡＴ領域を復帰先クラスタ番号や引用データの終端クラスタ番号を格納すべき領域として使用するとしても、さらに、ＦＡＴメインのＦＡＴ領域のためのバックアップ領域としてのＦＡＴ領域が必要となる場合があることが考えられる。
このような場合には、例えばＦＡＴ領域について３以上の領域を形成するフォーマットを採用すればよい。ＢＰＢ内には、BPB_NumFATsといわれる、ＦＡＴ領域数を示す情報が格納されている。そこで、このBPB_NumFATsについて３以上の値を設定してメディアフォーマットを実行すれば、３以上のＦＡＴ領域が形成される構造を得ることができる。
しかし、前述もしたように、ＦＡＴ２は、ＦＡＴ１の予備領域、バックアップ領域として、ＦＡＴ１と同様の内容がコピーされるようにして使用される場合がある。このために、仕様として、本実施の形態のようにして、１つのＦＡＴ領域を復帰先クラスタ番号や引用データの終端クラスタ番号を格納すべき領域として使用するとしても、さらに、ＦＡＴメインのＦＡＴ領域のためのバックアップ領域としてのＦＡＴ領域が必要となる場合があることが考えられる。
このような場合には、例えばＦＡＴ領域について３以上の領域を形成するフォーマットを採用すればよい。ＢＰＢ内には、BPB_NumFATsといわれる、ＦＡＴ領域数を示す情報が格納されている。そこで、このBPB_NumFATsについて３以上の値を設定してメディアフォーマットを実行すれば、３以上のＦＡＴ領域が形成される構造を得ることができる。
また、本発明のファイルは、複数の情報部から成ることが最低限の要件となる。従って、実施の形態において図７などに示したISO Base Media File Formatなどに従ったファイルの形式は、あくまでも一例であり、上記した本発明が対応するファイルの要件を満たす限り、そのファイル構造、ファイル形式は限定されるべきものではない。また、これに応じて、ファイル種別としても動画と音声について再生時間軸を同期させて再生するようなＡＶファイル系以外の各種ファイルとされてよい。
また、実施の形態におけるファイルの記録管理についてはＦＡＴファイルシステムを採用することとしているが、例えばＨＳＦ(Hierarchical File System)などをはじめとする他のファイルシステムとされてもよいものであり、ファイルシステムの規格に関しては特に限定されるべきものではない。
また、上記実施の形態では、本発明の情報処理装置としても、実施の形態に挙げたデジタルビデオカメラに限定されるべきものではなく、例えば、デジタルスチルカメラ、テレビジョン放送番組の予約録画機器、さらにはパーソナルコンピュータをはじめ、これに準じた各種情報処理機器など、ＨＤＤなどの記憶媒体に対応してデータ書き込み／読み出しなどのデータ処理が可能な機器であれば、本発明が適用できる。
また、ファイルが記録される記憶媒体としても、実施の形態では、図１においてメディアコントローラ１３と接続されているものを例示しているが、これら以外の各種記録媒体とされてよい。
また、ファイルが記録される記憶媒体としても、実施の形態では、図１においてメディアコントローラ１３と接続されているものを例示しているが、これら以外の各種記録媒体とされてよい。
１ デジタルビデオカメラ、２ 光学系部、３ 光電変換部、４ ビデオ信号処理部、５ 画像入出力部、６ カメラ機能部、７ 表示部、８ 音声処理部、９ 音声入出力部、１０ ＣＰＵ、１１ ＲＯＭ、１２ ＲＡＭ、１３ メディアコントローラ、１４ ＨＤＤ、１５ 操作入力部、１６ 通信部、１００ アプリケーション、１０１ ファイルシステム、１０２ デバイスドライバ、２００ 記録制御部、２０１ ディレクトリエントリ、２０２ ＦＡＴ制御部、２０３ クラスタ制御部、２１０ メディア制御部、２１１ 位置算出部
Claims (4)
- 所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規の上記ファイルである新規ファイルとしての内容を生成する新規ファイル生成手段と、
上記新規ファイル生成手段により生成された新規ファイルの内容を上記記憶媒体に書き込んで記憶させる書き込み手段と、
上記記憶媒体に記憶されるファイルについて管理する管理手段とを備え、
上記書き込み手段は、上記新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、上記新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むようにされ、
上記管理手段は、上記書き込み手段により書き込まれた上記書込対象情報部と、上記原ファイルにおいて上記未変更情報部と同一とされる内容を有する情報部である引用情報部とにより、上記新規ファイルが形成されるものとして管理する、
ことを特徴とする情報処理装置。 - 上記管理手段は、
ファイルを形成するとされるデータを、所定のデータサイズを有する最小管理単位の連結による構造として管理するようにされたうえで、
上記新規ファイルを管理するために、
新規ファイルの構造として、上記引用情報部の前方に所定の書込対象情報部が配置される場合には、この所定の書込対象情報部のデータを格納する最小管理単位のうちで終端となる最小管理単位に続けて、上記引用情報部のデータを格納する最小管理単位のうちで先頭となる最小管理単位が連結されるようにして管理し、
新規ファイルの構造として、上記引用情報部の後方に所定の書込対象情報部が配置される場合には、上記引用情報部のデータを格納する最小管理単位のうちで終端となる最小管理単位に続けて、この所定の書込対象情報部のデータを格納する最小管理単位のうちで先頭となる最小管理単位が連結されるようにして管理する、
ことを特徴とする請求項１に記載の情報処理装置。 - 所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規の上記ファイルである新規ファイルとしての内容を生成する新規ファイル生成手順と、
上記新規ファイル生成手順により生成された新規ファイルの内容を上記記憶媒体に書き込んで記憶させる書き込み手順と、
上記記憶媒体に記憶されるファイルについて管理する管理手順とを実行するものとされ、
上記書き込み手順は、上記新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、上記新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むようにされ、
上記管理手順は、上記書き込み手順により書き込まれた上記書込対象情報部と、上記原ファイルにおいて上記未変更情報部と同一とされる内容を有する情報部である引用情報部とにより、上記新規ファイルが形成されるものとして管理する、
ことを特徴とする情報処理方法。 - 所定の複数の情報部により形成される形式を有し、記憶媒体に記憶済みとされていたファイルである原ファイルを基として、この原ファイルにおける所要の情報部の内容について変更することにより、新規の上記ファイルである新規ファイルとしての内容を生成する新規ファイル生成手順と、
上記新規ファイル生成手順により生成された新規ファイルの内容を上記記憶媒体に書き込んで記憶させる書き込み手順と、
上記記憶媒体に記憶されるファイルについて管理する管理手順とを情報処理装置に実行させるものとされ、
上記書き込み手順は、上記新規ファイルを形成する所定の情報部のうちで、原ファイルの内容からの変更が無かったとされる未変更情報部がある場合には、上記新規ファイルを形成する情報部のうちで、この未変更情報部以外の情報部である書込対象情報部を記憶媒体に書き込むようにされ、
上記管理手順は、上記書き込み手順により書き込まれた上記書込対象情報部と、上記原ファイルにおいて上記未変更情報部と同一とされる内容を有する情報部である引用情報部とにより、上記新規ファイルが形成されるものとして管理する、
ことを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004327256A JP4561323B2 (ja) | 2004-11-11 | 2004-11-11 | 情報処理装置、情報処理方法、及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004327256A JP4561323B2 (ja) | 2004-11-11 | 2004-11-11 | 情報処理装置、情報処理方法、及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006139439A true JP2006139439A (ja) | 2006-06-01 |
| JP4561323B2 JP4561323B2 (ja) | 2010-10-13 |
Family
ID=36620238
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004327256A Expired - Fee Related JP4561323B2 (ja) | 2004-11-11 | 2004-11-11 | 情報処理装置、情報処理方法、及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4561323B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012512460A (ja) * | 2008-12-16 | 2012-05-31 | サンディスク アイエル リミテッド | 廃棄可能ファイル |
| JP2012512462A (ja) * | 2008-12-16 | 2012-05-31 | サンディスク アイエル リミテッド | 廃棄可能ファイル |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08320817A (ja) * | 1995-05-25 | 1996-12-03 | Toshiba Corp | ファイルシステム管理方法 |
| JPH11162089A (ja) * | 1997-11-28 | 1999-06-18 | Toshiba Corp | データ再生制御装置、同装置に用いられる記録媒体、データ再生制御方法 |
| JP2000259459A (ja) * | 1999-03-08 | 2000-09-22 | Matsushita Electric Ind Co Ltd | ファイル記憶媒体、ファイル管理装置、ファイル管理プログラム記憶媒体 |
| JP2001051878A (ja) * | 1999-08-11 | 2001-02-23 | Sony Corp | ファイル管理装置及びファイル管理方法 |
| JP2002373099A (ja) * | 2001-06-14 | 2002-12-26 | Sharp Corp | ディスク管理方法 |
-
2004
- 2004-11-11 JP JP2004327256A patent/JP4561323B2/ja not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08320817A (ja) * | 1995-05-25 | 1996-12-03 | Toshiba Corp | ファイルシステム管理方法 |
| JPH11162089A (ja) * | 1997-11-28 | 1999-06-18 | Toshiba Corp | データ再生制御装置、同装置に用いられる記録媒体、データ再生制御方法 |
| JP2000259459A (ja) * | 1999-03-08 | 2000-09-22 | Matsushita Electric Ind Co Ltd | ファイル記憶媒体、ファイル管理装置、ファイル管理プログラム記憶媒体 |
| JP2001051878A (ja) * | 1999-08-11 | 2001-02-23 | Sony Corp | ファイル管理装置及びファイル管理方法 |
| JP2002373099A (ja) * | 2001-06-14 | 2002-12-26 | Sharp Corp | ディスク管理方法 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012512460A (ja) * | 2008-12-16 | 2012-05-31 | サンディスク アイエル リミテッド | 廃棄可能ファイル |
| JP2012512462A (ja) * | 2008-12-16 | 2012-05-31 | サンディスク アイエル リミテッド | 廃棄可能ファイル |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4561323B2 (ja) | 2010-10-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0971358B1 (en) | Data processing apparatus and file management method therefor | |
| JP5129156B2 (ja) | アクセス装置、および、ライトワンス記録システム | |
| US8977802B2 (en) | Access device, information recording device, controller, real time information recording system, access method, and program | |
| US20120102076A1 (en) | Information processing apparatus, information processing method, and program | |
| GB2383859A (en) | Memory controller managing a file allocation table for a memory card | |
| JP4487954B2 (ja) | データ記録装置、データ記録方法、及びプログラム | |
| JP2007233638A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| US9015444B2 (en) | Access apparatus and available storage space calculation method | |
| US7051054B1 (en) | Method and apparatus for emulating read/write file system on a write-once storage disk | |
| WO2004042724A1 (en) | Record carrier having a main file system area and a virtual file system area | |
| JP4561323B2 (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| JP2003052006A (ja) | 情報編集制御装置、情報編集方法、及びディスク装置 | |
| JP2007108853A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP2006178633A (ja) | 情報処理装置、情報処理方法、プログラム | |
| US20070055819A1 (en) | Information recording medium and its control method | |
| JP2006164017A (ja) | 情報処理装置、情報処理方法、プログラム | |
| WO2018186455A1 (ja) | 不揮発性メモリにおける空き容量管理方法、及び不揮発性メモリを含む情報記録装置にデータを記録するアクセス装置、情報記録装置および情報記録システム | |
| JP2006178632A (ja) | 情報処理装置、情報処理方法、プログラム | |
| JP2010020845A (ja) | 記録媒体初期化方法及び記録媒体初期化装置 | |
| JP4734898B2 (ja) | 情報処理装置、情報処理方法、プログラム | |
| JP2007059004A (ja) | 情報処理装置および方法、プログラム並びに記録媒体 | |
| JP2006139845A (ja) | 情報処理装置、情報処理方法、プログラム | |
| US7424573B2 (en) | Information processing apparatus, method, and program for formatting multiple recording media integrated as one | |
| JP2006133855A (ja) | 情報処理装置、情報処理方法、プログラム | |
| JP2006146812A (ja) | 情報処理装置、情報処理方法、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070822 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100405 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100420 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100527 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100706 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100719 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130806 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130806 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |