(57)【要約】アプリケーション間での汎用性が高く、記録領域を空費せず、更に、大量の個別ファイル及びグループ化ファイルの取り扱いを容易にするファイル管理方法及びその管理方法で用いられる情報記録媒体を提供する。必要な全ファイルと全グループを一括管理するファイルであるＣＭＦ(Contents Management File)を設けることにより、アプリケーションはファイルシステムと直接やり取りせずに、ＣＭＦを通してディスク上の大量のファイルを扱ったり、グループ化等の必要な処理を汎用的に行うことが可能である。
2004537089.tif 000002
【特許請求の範囲】
【請求項１】
情報記録媒体上に記録されたファイルの管理方法において、
前記媒体上に記録された複数のファイルを複数のグループにグループ化したグループ情報を含むコンテンツ管理ファイル（Contents Management File）を設け、該コンテンツ管理ファイルによりグループおよびファイルの管理を行うことを特徴とするファイル管理方法。
【請求項２】
前記コンテンツ管理ファイルには、グループおよびファイルの情報を格納する複数個の固定長の情報ブロック（Information Blocks）が記録されていることを特徴とする請求項１に記載のファイル管理方法。
【請求項３】
前記情報ブロックは、固定長の情報格納単位であるセルが複数個と、各セルの使用状態を管理するSpace Bitmapを含むことを特徴とする請求項２に記載のファイル管理方法。
【請求項４】
前記セルは、含まれる情報ブロックの種類により、サイズおよび含まれる個数が異なることを特徴とする請求項３に記載のファイル管理方法。
【請求項５】
前記セルに含まれる個別の情報を指定するIDは、セルの記憶位置に対応した番号で管理されていることを特徴とする請求項３に記載のファイル管理方法。
【請求項６】
前記情報ブロックは、前記記録媒体の誤り訂正単位（ECCブロック）を2の階乗（1,2,4,8,16,,,）で割ったサイズを持つことを特徴とする請求項２に記載のファイル管理方法。
【請求項７】
前記情報ブロックは、空き領域がなくなった場合には、同サイズのブロックを追加することにより領域確保を行うことを特徴とする請求項２に記載のファイル管理方法。
【請求項８】
前記コンテンツ管理ファイルには、一般情報、ファイルの種類一覧、データ作成者一覧、情報ブロックの種類一覧、各情報ブロックに含まれるデータの個数一覧、情報ブロック管理情報、を含むコンテンツ管理ファイル全体の管理情報（Management Information）が記録されていることを特徴とする請求項１に記載のファイル管理方法。
【請求項９】
前記情報ブロック管理情報は、前記各情報ブロックの前記コンテンツ管理ファイル内での配置情報を持つことを特徴とする請求項８に記載のファイル管理方法。
【請求項１０】
前記情報ブロック管理情報は、前記各情報ブロックに含まれる有効セルの数を示す情報が記録されていることを特徴とする請求項８に記載のファイル管理方法。
【請求項１１】
前記情報ブロック管理情報は、前記各情報ブロックの有効データ長を示す情報が含まれることを特徴とする請求項８に記載のファイル管理方法。
【請求項１２】
前記情報ブロックにおいて、前記有効セル数と前記有効データ長を比較することにより、有効データ長以内の空き領域の有無を判定し、前記Space Bitmapを利用しなくても前記情報ブロックに記録するデータの記録位置を決定できることを特徴とする請求項１０又は１１に記載のファイル管理方法。
【請求項１３】
前記管理情報は、前記コンテンツ管理ファイルに記録可能な最大情報ブロック数分のブロック管理情報を格納しても、初期のサイズを越えないことを特徴とする請求項８に記載のファイル管理方法。
【請求項１４】
前記グループ情報は、グループのグループ化も可能な階層構成になっており、ファイルのグループ化を管理する子グループ情報と前記子グループ情報のグループ化を管理する親グループ情報の少なくとも2階層構成になっていることを特徴とする請求項１に記載のファイル管理方法。
【請求項１５】
前記グループ情報の少なくとも一つが、前記ファイルの記録順序をもとにしたグループであることを特徴とする請求項１に記載のファイル管理方法。
【請求項１６】
前記情報ブロックには、前記グループ情報を含むことを特徴とする請求項２に記載のファイル管理方法。
【請求項１７】
前記情報ブロックには、前記グループのメンバー情報を含むことを特徴とする請求項２に記載のファイル管理方法。
【請求項１８】
前記情報ブロックには、前記ファイルを管理するファイル情報を含むことを特徴とする請求項２に記載のファイル管理方法。
【請求項１９】
前記情報ブロックには、文字列を格納するテキスト情報を含むことを特徴とする請求項２に記載のファイル管理方法。
【請求項２０】
前記テキスト情報は、前記グループ情報の内容を説明する文字列が含まれることを特徴とする請求項１９に記載のファイル管理方法。
【請求項２１】
前記グループ情報には、そのグループに関連した前記テキスト情報のID番号が含まれることを特徴とする請求項１６に記載のファイル管理方法。
【請求項２２】
前記テキスト情報には、テキストを参照しているグループのID番号を含むことを特徴とする請求項１９に記載のファイル管理方法。
【請求項２３】
前記テキスト情報は、テキストの長さ情報とファイルシステムと同じ文字コードから成る文字情報を含むことを特徴とする請求項１９に記載のファイル管理方法。
【請求項２４】
前記グループメンバー情報は一定サイズの前記セル（Group Member Descriptor）を単位として構成され、前記サイズを上回る情報量を持つグループメンバー情報は、複数のセルにまたがって記録されることを特徴とする請求項１７に記載のファイル管理方法。
【請求項２５】
１つのグループを構成するグループメンバー情報は、同一の前記情報ブロックに記録されることを特徴とする請求項２４に記載のファイル管理方法。
【請求項２６】
各ファイルは複数の子グループ情報に管理されることが可能であり、各ファイル情報には自身が属する子グループ数を示す情報（Link Count）が含まれることを特徴とする請求項１に記載のファイル管理方法。
【請求項２７】
各子グループ情報は、複数の親グループ情報に管理されることが可能であり、各子グループ情報には自身が属する親グループ数を示す情報（Link Count）が含まれることを特徴とする請求項１に記載のファイル管理方法。
【請求項２８】
前記ファイルはLink Countがゼロ以外の場合は、削除されても上書きが禁止されることを特徴とする請求項２６に記載のファイル管理方法。
【請求項２９】
前記子グループ情報はLink Countがゼロ以外の場合は、削除されても上書きが禁止されることを特徴とする請求項２７に記載のファイル管理方法。
【請求項３０】
前記子グループ情報に含まれるファイル一覧を利用するときに、あるファイルが削除されていることが判明した場合には、該子グループから該ファイルを削除し、該ファイルのLink Countを1減らすとともに、該Link Countが0の場合には該ファイル情報の領域を上書き可能に設定することを特徴とする請求項２６に記載のファイル管理方法。
【請求項３１】
前記親グループ情報に含まれる子グループ一覧を利用するときに、ある子グループが削除されていることが判明した場合には、該親グループから該子グループを削除し、該子グループのLink Countを1減らすとともに、該Link Countが0の場合には該子グループ情報の領域を上書き可能に設定することを特徴とする請求項２７に記載のファイル管理方法。
【請求項３２】
前記コンテンツ管理ファイルは、複数のファイルの再生或いは表示或いは印刷順番を記述したファイルを子グループ情報のひとつとして管理することを特徴とする請求項１に記載のファイル管理方法。
【請求項３３】
前記子グループ情報は各々代表ファイルを示す情報を含むことを特徴とする請求項１４に記載のファイル管理方法。
【請求項３４】
前記代表ファイルはその子グループ情報に属する先頭メンバーであることを特徴とする請求項３３に記載のファイル管理方法。
【請求項３５】
前記親グループ情報は各々代表子グループを示す情報を含むことを特徴とする請求項１４に記載のファイル管理方法。
【請求項３６】
前記代表子グループはその親グループに属する先頭メンバーであることを特徴とする請求項３５に記載のファイル管理方法。
【請求項３７】
前記ファイル情報内でファイルの拡張子は１バイトの識別情報で管理され、前記管理情報には各拡張子と識別情報の対応テーブル（File Type Table）が含まれることを特徴とする請求項１８に記載のファイル管理方法。
【請求項３８】
同一の拡張子であっても用途が異なる場合は、異なる識別情報が割り振られていることを特徴とする請求項３７に記載のファイル管理方法。
【請求項３９】
前記ファイル情報には、同一拡張子内でのファイルの識別を容易にするためにファイルの内容を示す補助属性情報が含まれることを特徴とする請求項１８に記載のファイル管理方法。
【請求項４０】
前記一般情報には、Disk IDとしてUUID情報が含まれることを特徴とする請求項８に記載のファイル管理方法。
【請求項４１】
複数のディスクで、各々に記録された前記UUID情報と更新日時を比較することにより、各ディスク間に含まれる情報が一致するか否かとコピーされたものか否かを判別することを特徴とする請求項８に記載のファイル管理方法。
【請求項４２】
前記一般情報には、コンテンツ管理ファイルの初期化日時と作成日時を示す情報が含まれており、それらの情報が一致するか否かにより記録されたディスクがコピーされたものか否かを判別することを特徴とする請求項８に記載のファイル管理方法。
【請求項４３】
前記コンテンツ管理ファイルには、ディスク装填時或いは電源投入時に自動的に起動するファイル或いはグループ情報を示す情報が含まれていることを特徴とする請求項８に記載のファイル管理方法。
【請求項４４】
前記コンテンツ管理ファイルには、ディスクを自動起動するか否かを示す情報が含まれていることを特徴とする請求項８に記載のファイル管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記録媒体内に含まれるファイルを管理する方法に関するものである。
【背景技術】
【０００２】
従来、光ディスク、磁気ディスク、光磁気ディスク等の記録媒体内に含まれる動画や静止画や音声等の情報を、画像表示ソフトや電子アルバムソフト等のアプリケーションで扱う場合は、図２(A)に示すようにUDFやFAT等のファイルシステムを通してディスク上の各情報にアクセスしていた。
【０００３】
また、印刷、一覧表示、スライドショー等で複数ファイルのグループ化が必要な場合は、プレイリストファイルやDPOFファイル等、それぞれのグループに応じて、属するファイルや必要な情報を記述する管理ファイルを作成し、グループ化ファイルの管理が行われていた。
【０００４】
しかしながら、図２(A)に示される従来のシステムのようにアプリケーションが直接ファイルシステムを利用して各ファイルにアクセスするような場合、ファイル数やグループ数が多くなると、それらを一括して管理することが困難になり、必要な情報を探すのに時間がかかるという問題があった。さらに、ファイルシステムを通してファイルを特定する場合は、ファイルの種類は拡張子で判断するしかなく、映像や音声ファイル等で同じ種類の拡張子が付けられている場合は見分けを付けづらく、迅速な検索の足かせとなっていた。
【０００５】
また、記録済みの複数のファイルを時系列に再生する場合は、すべてのファイルへアクセスして記録時間順に並べ替える必要があった。この場合、ディレクトリ構造やファイル名を工夫して時系列情報を保持することも可能だが、ディレクトリ構造やファイル名の自由度が減り、ファイル管理の面で不便であった。
【０００６】
また、上述した管理ファイルを用いる場合は、グループ毎に管理ファイルを作成する必要があった。そのため各管理ファイルに含まれているメンバー等の情報を知るためには各管理ファイルをいちいち開いて調べなければならず、ファイル管理の面で不便であった。さらに、あるファイルがいずれかの管理ファイルに含まれているかどうかを判断するにも、全ての管理ファイルを開いて調べる必要があり、ファイルを削除する場合等に管理ファイルに含まれているかどうかを判断することが困難であった。その他、上記管理ファイルは、その管理ファイルを利用するアプリケーション毎にフォーマットが異なるため他のアプリケーションで利用できないといった汎用性の問題もあった。
【０００７】
また、管理ファイルを用いる場合においても各ファイルへのアクセスはアプリケーションが直接ファイルシステムを利用して行っていたため、必要な情報を探すのに時間が掛かるという問題は解決されていなかった。
【発明の開示】
【０００８】
本発明は、上記問題に鑑みてなされたものであり、アプリケーション間での汎用性が高く、大量のファイル及びグループ情報の取り扱いを容易にするファイル管理方法の提供を目的とするものである。
【０００９】
以下に上記目的を達成するための一例を示す。
【００１０】
情報記録媒体上に記録されたファイルの管理方法において、前記媒体上に記録された複数のファイルを複数のグループにグループ化したグループ情報を含むコンテンツ管理ファイル（Contents Management File）を設け、該コンテンツ管理ファイルによりグループおよびファイルの管理を行う。
【００１１】
本発明では、図２(B)に示すように、必要な全ファイルと全グループを一括管理するファイルであるCMF（Contents Management File）を設けることにより、アプリケーションはファイルシステムと直接やり取りせずに、CMFを通してディスク上の大量のファイルを扱ったり、グループ化等の必要な処理を汎用的に行うことが可能となる。
【発明を実施するための最良の形態】
【００１２】
１．CMFの構造
まず、コンテンツ管理ファイルCMF(Contents Management File)の構造に関して説明する。以下に述べるディレクトリ構造やファイル名、およびCMFの具体的な数値等は一例であり、本実施例と異なる場合でも本発明は適用可能である。ディスク等にデータを記録する場合は、一般にFATやUDF等のファイルシステムによるディレクトリ構造があり、その中にファイルが記録されている。図26は今回CMFで管理するディレクトリ構造の例で、ROOTディレクトリ[80]の下に印刷等を管理するMISCディレクトリ[81]、静止画記録用のDCIMディレクトリ[82]、動画、音声、プレイリスト等を記録するVIDEOディレクトリ[83]が配置されている。DCIMディレクトリ[82]の下には3桁の数字で始まる静止画ディレクトリ[84]が存在し、VIDEOディレクトリ[83]の下には3桁の数字で始まる動画ディレクトリ[85]、音声ディレクトリ[86]、プレイリストディレクトリ[87]が存在する。それぞれのディレクトリ名の先頭に付く3桁の数字は、同じ種類のディレクトリで重なることはない。静止画、動画、音声、プレイリストディレクトリの下には、それぞれ静止画ファイル[92]、動画ファイル[93]、音声ファイル[94]、プレイリストファイル[95]が記録されており、先頭4文字の英数字に続いて4桁の数字を持つファイル名を持つ。ファイル名に付く4桁の数字は、同一ディレクトリの中で同じ種類のファイルの場合、重なることはない。これらのファイルや複数ファイルのグループ化等を管理するのがCMFであり、CMFは汎用性があるため、複数のアプリケーションから利用することが可能である（図2）。なお、CMF自身もファイルシステムで管理される一つのファイル[90]であるから、ディスク上のどこか（本実施例ではROOTディレクトリ[80]の下）に保存される。
【００１３】
図1はCMFの全体構造を示したものである。CMFは16Kバイトのサイズを持つ1つの管理情報(Management Information[1])と、8Kバイトのサイズを持つ数種類の情報を組み合わせた構造をしており、8Kバイト情報の一塊をInformation Blockと呼ぶ。通常のInformation BlockはParent Group Information[2]、Parent Group Member Information[3]、Child Group Information[4]、Child Group Member Information[5]、File Information[6]、Text Information[7]の6種類であり、グループは親グループ(Parent Group)と子グループ(Child Group)の2階層が作成可能である。後述するが、他にVendor Specific Information[8]とDummy Information [9]があり、Vendor Specific Information[8]はVendor独自の情報を記録するときに用い、Dummy Information[9]は前もって領域を確保しておく場合に使用する。各Information Blockの先頭にはBlock内の空き領域を管理するSpace Bitmapが配置されており、データの存在する領域は”1”、空き領域は”0”となる。最初は各Information Blockには空き領域が存在するが、情報を追加していくことにより、それぞれのInformation Blockが一杯になると、新たに8KBのInformation BlockをCMF末尾に追加していく。なお、Information Blockのサイズは8KB以外でもよく、各Information Blockでサイズが異なっても構わないが、記録媒体の誤り訂正単位（ECCブロック）を2の階乗（1,2,4,8,16,,）で割ったサイズを持つ。すなわち、ECCブロックが32KBの場合は、Information Blockのサイズは、32KB、16KB、8KB、4KB、、、の値を取り得る。こうすることにより、Information Blockの先頭は常にECCブロックの先頭と一致し、一つのInformation BlockがECCブロックをまたがって記録されることがない。
【００１４】
Management Information[1]はCMF全体を管理する部分で、一般的な情報を記録するGeneral Information[11]、ファイルの種類を一覧にしたFile Type Table [12]、CMFを作成／編集したVendorのIDを記録したVendor ID Table[13]、Information Blockの種類を一覧にしたBlock Type Table[14]、各Information Block内のオブジェクト数を管理するNumber Management Table[15]、各Information Blockを管理するInformation Block Table[16]から成る。Parent Group Information[2]は親グループの情報を記録するもので、空き領域管理のSpace Bitmap[21]と実際の情報を記したParent Group Descriptors [22]とから成る。Parent Group Member Information[3]には親グループに含まれる子グループの情報が記録されており、空き領域管理のSpace Bitmap[31]とメンバー一覧であるParent Group Member Descriptors[32]から成る。同様にChild Group Information[4]は子グループの情報を記録するもので、空き領域管理のSpace Bitmap[41]と実際の情報を記したChild Group Descriptors [42]とから成る。Child Group Member Information[5]には子グループに含まれるファイルの情報が記録されており、空き領域管理のSpace Bitmap[51]とメンバー一覧であるChild Group Member Descriptors[52]から成る。File Information[6]はファイルの情報が記録されており、空き領域管理のSpace Bitmap[61]とファイル情報File Descriptors[62]から成る。Text Information[7]はテキストの情報が記録されており、空き領域管理のSpace Bitmap[71]とテキスト情報Text Descriptors[72]から成る。
【００１５】
以下、各Information Blockの詳細な構造に関して述べる。図3はCMF全体を管理するManagement Information[1]の構造である。上述したように、General Information[11]、File Type Table[12]、Vendor ID Table[13]、Block Type Table [14]、Number Management Table[15]、Information Block Table[16]から成り、Information Block Table[16]は各Information Blockに対応したInformation Block Descriptor[17]から構成される。尚、Information Block Descriptor[17]の記録順序がInformation Blockの記録順序と一致しているので、Information Block Table[16]を見ると、必要とするInformation BlockのCMFファイル内での記録位置がわかる。データサイズはGeneral Information[11]が512バイト、File Type Table[12]が1024バイト、Vendor ID Table[13]が512バイト、Block Type Table[14]が512バイト、Number Management Table[15]が512バイト、Information Block Table[16]が各Information Block毎に8バイトである。Information BlockがB個の場合は合計3072＋8×Bバイトになり、16KバイトのManagement Information Block[1]にはInformation Blockが最大1664個格納可能である。
【００１６】
図4はManagement Information[1]内に含まれるGeneral Information[11]の構造である。ここには識別情報や日時といった一般的な情報や、CMF内に含まれるInformation Block数、コメント等が含まれる。CMF IdentifierはCMFの先頭にファイル識別情報として記録するもので、CMF Versionは将来CMFの構造が変更になった場合にどの構造で書かれているのかを識別するためのものである。File SizeはCMF全体のサイズでディスク初期化時は64Kバイトになる。Vendor IdentifierとProduct IdentifierはCMF作成者や作成機を識別するもので、各Vendorが自由に文字列を付与できる。Disk Identifierはディスク内容（コンテンツ）の識別情報でUUID（Universally Unique Identifier）が記録される。これはディスクを初期化すると変更されるので、各ディスクで不変ではない。また、ディスクがコピーされた場合はDisk Identifierもそのままコピーされるので、各ディスクに固有でもない。このDisk Identifierを用いて2つのディスクがコピーにより作成されたものかどうかを判断することができる。
【００１７】
Initial Time、Create Time、Modify Timeは、それぞれ初期化日時、CMF作成日時、CMF更新日時で、UDFファイルシステムの日時情報と同じ形式の12バイト情報である。通常はInitial TimeとCreate Timeは同一であるが、ディスクをコピーした場合にはInitial Timeはコピー元の情報をそのまま用いるが、Create Timeはコピーした日時を記録する。すなわち、Initial TimeとCreate Timeを比較することにより、ディスクがオリジナルかコピーかを判別することができる。また、ディスクの内容が変更された場合はCMFにも反映されてModify Timeが更新されるので、2つのディスクのDisk Identifierと Modify Timeを比較して、両者が同一の場合は2つのディスクの中身（コンテンツ）は一致していると判断できる。
【００１８】
Auto Start Type、Auto Start Attribute、Auto Start Object Identifierはディスク挿入時や電源投入時の自動起動情報で、Auto Start Typeは自動起動するデータの種類（グループかファイル）、Auto Start Attributeは自動起動するかどうかの設定、Auto Start Object Identifierは自動起動するグループやファイルの番号が入る。Number of Information BlocksはCMFに含まれるInformation Block数で、Comment Lengthにコメントの長さ、Comment欄に127バイトの文字列が記録される。なお文字列として、ファイルシステムで用いられているものと同じ文字コードが用いられる。最後にReserved領域が設けられ、General Information全体のサイズを512バイトにしている。
【００１９】
図5はManagement Information[1]内に含まれるFile Type Table[12]の構造例である。基本的にファイルの拡張子一覧であるが、同一の拡張子であっても種類の異なるファイル（動画や音声等）は区別している。たとえば、同じ拡張子”MPG”を持つファイルでも、動画と音声が含まれているもの（Movie）はType ID=3で、音声のみが含まれているもの（Audio）はType ID=4となる。一つの拡張子に付き4バイトまでの長さを格納でき、4バイトよりも短い拡張子は余った領域を0x00で埋める。全部で256個の種類の拡張子を登録でき、128から254の番号はVendor独自の拡張子を登録可能である。なお、番号0のNullは拡張子のないファイルを表し、番号255のNot SpecifiedはFile Type Table[12]に登録されていない拡張子を示す。
【００２０】
図6はManagement Information[1]内に含まれるVendor ID Table[13]の構造であり、Vendor Specific Information Blockを作成したVendorを示すのに用いられる。各Vendor IDは4バイトの領域を持つが、実際にはEthernet（富士ゼロックス株式会社の登録商標）のネットワークカード等でMACアドレス（の前半3バイト）として用いられる、IEEEで管理されるベンダー固有のID（カンパニーID）を使用し、残り1バイトは0x00で埋める。全部で128個のIDを登録できるが、ID=0は共通のInformation Typeを示すために用いるデフォルトIDであり、ID=127はIDなし（No Information）を示すので、Vendorは126個登録可能である。
【００２１】
図7はManagement Information[1]内に含まれるBlock Type Table[14]の構造であり、Information Blockの種類一覧が格納される。図8で示される2バイトのInformation Block Type Descriptorを256個格納することが可能で、Vendor ID（図6）とInformation Type（図9）をそれぞれ1バイトで組み合わせて指定する。Information Typeは図9に示されているように、256種類の分類が可能で、Type 0〜127はシステム用、Type 128〜255はユーザー（Vendor Specific）用である。システム用のうち、Type 0〜8（通常オブジェクトInformation）とType 127（Dummy Information）はすでに規定されており、Type 9〜126はReservedである。なお、理由は後述するがType 0,7,8は使用しない。Block Type Table（図7）のうち、Type 0〜8は予め定められており、Vendor IDが0（Default ID）で、Information Typeは0〜8が入る。なお、Block Type 0,7,8はInformation Type（図9）と同様に使用しない。
【００２２】
図10はManagement Information[1]内に含まれるNumber Management Table[15]の構造であり、Block Type Table[14]（図7）で示される各Information Block Typeに含まれる全オブジェクト数を表す。これは同一のInformation Block Typeを持つ全Information Blockに含まれるオブジェクト数の合計で、たとえばCMFにFile Information Block[6]が10個含まれていれば、その中に含まれるファイル数をすべて足し合わせたものとなる。Information Block Type（図7）に応じて256個のオブジェクト数を各2バイト（65536個以内）で格納できる。すなわち、Information Block Typeが1〜6の場合、それぞれ親グループ数、親グループメンバー数、子グループ数、子グループメンバー数、ファイル数、テキスト数となる。Information Block Type 0の場合は使わないが、Information Block Type 7,8に相当する部分が、それぞれ親グループと子グループのコメント数になっている。これは、Text InformationにはGroup Informationとそれ以外（Vendor Specific Information等）のコメントを格納できるため、グループとそれ以外に使われているコメント数を分離するためである。全テキスト数からグループに使われているコメント数を引くと、グループ以外に使われているText Descriptorの数がわかる。
【００２３】
図11はInformation Block Table[16]の要素であるInformation Block Descriptor [17]の構造である。これが複数集まってInformation Block Table[16]を構成する。Block TypeはInformation Blockの種類で、Block Type Table[14]で示される値が入る。Block AttributeはInformation Blockの属性情報で、Information Blockの種類により含まれる内容は異なる。File Information Blockの場合は、ファイル情報とディレクトリ情報がそれぞれ含まれるかどうかという情報が入り、Text Information Blockの場合は、親グループ、子グループ、その他のコメント情報がそれぞれ含まれているかどうかの情報が入る。なお、すべてのInformation Blockに共通して、Space Bitmapが含まれているかどうかの属性情報も持つ。
【００２４】
Block SizeはInformation Blockのサイズで、2KBの整数倍で表現し、本実施例ではInformation Blockはすべて8Kバイトなので4になる。Descriptor SizeはInformation Blockに含まれる一つのDescriptorのサイズで、これを用いてInformation Block内に含まれる最大Descriptor数(n)や先頭Descriptor位置(p)を計算することができる。（Block Size = bバイト、Descriptor Size = dバイト）
最大Descriptor数  ：n = int( (b×8)／(1+8×d) )
先頭Descriptor位置：p = b−d×n
【００２５】
Block Specified DataはInformation Blockに固有の情報であるが、System Information Block（Information Type 0〜127）の場合は、図12に示すようにData LengthとNumber of Objectsの情報が格納される。Data LengthはInformation Block内の有効データ長で、データの途中に空き領域があるかどうかに関わらず、最後のデータまでの長さである。Number of ObjectsはInformation Block内に含まれるデータ数であり、Descriptorの個数が入る。各Block内の空き領域は、それぞれのBlock内のSpace Bitmapで管理し、各Block内の空き領域数とデータ長は、上記CMF先頭の管理Blockで管理されるので、メモリ上に常駐しておくデータ量を減らすとともに、検索量を減らすことが可能となる。
【００２６】
各Information Block内に記録することのできるObject数は種類により固定なので、最大記録可能数からNumber of Objectsを引くことにより空き領域数を計算できる。さらにNumber of ObjectsにDescriptor Sizeを掛けることにより必要なデータ長が計算でき、これをData Lengthと比較することによりデータの途中に空き領域があるかどうかも判定できる。
【００２７】
図13は、親グループと子グループの一般情報を記録するParent Group Information Block[2]とChild Group Information Block[4]の構造を示したもので、両者の構造は同一である。これは8KバイトのInformation Block内に64バイト単位（セル）のグループ情報Parent/Child Group Descriptor[24,44]を一覧にしたものであり、グループ情報[24,44]の集合がParent/Child Group Descriptors [22,42]である。各64バイト単位のセルに有効なグループ情報が格納されているかどうかを示すのがParent/Child Group Descriptor Space Bitmap [21,41]である。一つのInformation Block内にグループ情報[24,44]は最大127個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap [21,41]が1ビット／セルで16バイトを用いて管理する。すなわちSpace Bitmap [21,41]の中で”1”で表されるビットのセルには有効なグループ情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[23,43]は、Space Bitmap[21,41]の64バイト単位のセルに対する余剰領域である。なお、グループ情報Parent/Child Group Descriptor[24,44]数がG個の場合は、有効データサイズは64＋64×Gバイトになる。また、本実施例において親グループと子グループのGroup DescriptorはCMF全体で、それぞれ最大16K個まで記録できる。
【００２８】
図14は、Group Descriptor[24,44]の構造を示したもので、親グループと子グループで構造は同一である。Group Typeは、親グループか子グループかという情報と、ユーザーが作成したユーザーグループかシステムが自動的に作成したシステムグループかといった情報が含まれる。システムグループの場合はグループの種類が記録され、ユーザーグループの場合はユーザーがグループの種類を設定することができる。本実施例においては、システムが自動的に作成するグループとして、記録順序をもとにした日付グループとプレイリストに含まれるファイルを一覧にしたプレイリストグループがあり、日付子グループの一覧が日付親グループで、プレイリスト子グループの一覧がプレイリスト親グループである。日付子グループのメンバーには全ての種類のファイルを含めることができるので、日付グループを用いればファイルの種類に関わらず記録順序を再現することが可能となる。
【００２９】
Group Attributeはグループの属性情報で、削除されたグループかどうか、削除禁止属性の他に、代表サムネイル画像がグループメンバーのサムネイルかどうか、Group DescriptorにExtended Dataが含まれるかどうか等の情報が含まれる。Member Descriptor IDはグループに含まれるメンバーを記録したGroup Member Descriptorを特定するもので、Group Member Information Block内の記録位置で示される。これは、CMF全体に含まれるGroup Member Descriptorの記録順序に従った2バイトの通し番号で表され、番号がわかるとそのグループが含まれるInformation Blockと、その中の位置を特定できる。一つのGroup Member Information Blockには最大127個のグループメンバー情報が記録できるので、たとえばMember Descriptor IDが300の場合は、3つ目のGroup Member Information Block内で46番目のグループメンバー情報を指すことがわかる。Comment IDはそのグループに付加されたコメントを示すもので、グループ一覧の表示やグループの検索等に利用し、実体はText Informationの中にある。Group Member Descriptorの指定方法と同様にテキストの記録順序に従った2バイトの通し番号で表され、コメントがない場合は0xFFFFが入る。
【００３０】
Link Countは、子グループの場合は親グループから参照されている数で、Link Countが0なら、その子グループはどの親グループにも属していないことになる。子グループのLink Countが1よりも大きい場合はいずれかの親グループから参照されていることになるので、もし削除されても上書きしてはいけない。すなわち、削除される子グループの属するGroup Information Block[2,4]内のSpace Bitmap[21,41]で、該当の削除子グループ位置を使用領域（”1”）のままにしておく。こうすることにより、子グループが削除された場合に、該当する子グループの属する親グループの情報を変更する必要がなくなる（本来、親グループに属する子グループが削除されたら、親グループ情報を変更すべきであるが、変更するには親グループに属する子グループIDを検索する必要があり時間がかかる）。逆に、親グループが削除された場合は、親グループが含む子グループのLink Countを1づつ減少させるが、そのときにLink Countが0になった子グループが削除済みであれば、Space Bitmap[21,41]で該当の子グループ情報位置を空き領域（”0”）に設定し、上書き可能にしておく。なお、本実施例において、親グループは他のグループから参照されないので、Link Countの値は常に0である。
【００３１】
Group Nameはそのグループの名前で、システムが自動的に作成するグループ以外はユーザーが自由に名前を付けても良い。システムグループである日付グループの場合は日付（YYYY：MM：DD）を、プレイリストグループの場合はディレクトリ番号とファイル名（nnn：PLAYxxxx）を記録する。Group NameはUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で表現され、先頭1バイトは文字コードの識別に使用し、余った領域は0x00で埋める。Create/Modify Date and Timeはグループ情報を作成／更新した日時であり、UDFの日時情報と同じ形式の12バイトで保存する。Thumbnail Member IDはグループ一覧等を表示するときに用いる代表サムネイルを持つ代表メンバーで、設定されていない場合（ID=0xFFFF）はGroup Member Descriptorの先頭メンバーを代表とする。グループが子グループの場合は、Thumbnail Member IDはFile Descriptorに記録されているファイル番号を指し、親グループの場合は子グループかファイルのどちらかを指す。どちらを指すかはGroup Attributeに情報が書かれており、もし子グループの場合はChild Group DescriptorのID、ファイルの場合はFile DescriptorのIDとなる。なお、親グループの代表メンバーが子グループの場合は、代表サムネイルは代表子グループの代表画像を用いる。Total Number of Membersは、このグループに属する全てのGroup Member Descriptorに含まれるメンバー数の合計である。
【００３２】
Extended Dataは上記以外のグループ情報を格納する場所であり、図15に示す構造を持つ。Extended Data内には複数のData Elementを格納でき、全Data Elementのサイズを合計した値（Data Length）を先頭1バイトに記録する。図16にData Elementの構造を示す。Data TypeはData Elementの種類を表し、Data Lengthは実際のデータのサイズ、Dataは実際のデータである。図17にData Typeを示すが、全部で256個登録でき、Type 0〜127がSystem Data、Type 128〜255がUser Dataである。System DataのうちType 0〜4は規定されており、以下各Data Typeの実際のデータ内容を示す。Null Data（Type 0）はExtended Dataの余った領域を埋めるためにExtended Dataの末尾に用いる。Date Information（Type 1）はグループの種類が日付グループの場合に作成日時を記録するもので、UDFのtimestampと同じ構造をもつ。Play List Information（Type 2）はグループの種類がプレイリストグループの場合にプレイリストファイルIDを格納するもので、File Information中に記録されたプレイリストファイルのFile Descriptor IDで表す。Link Information（Type 3）はこのグループが関係する他のObject Descriptorへのリンク情報を表し、複数個のObject Descriptorを格納可能である。このとき、各Object Descriptorは1バイトのInformation Block Type（図7）と2バイトのDescriptor IDで示される。Next Group Information（Type 4）は同じ日付やプレイリストのグループが複数個存在する場合に、次のGroup Descriptorを示すために用いられ、2バイトのDescriptor IDで示される。その他User Data（Type 128〜255）はユーザーが独自に情報を記録できるが、先頭1バイトにVendor ID（図6）を記録しておく。なお、Extended Dataは24＋64×nバイト（nは0以上）のサイズを持ち、一つのGroup Descriptorに収まらない場合（ｎが1以上の場合）は直後のGroup Descriptorに続けて記録する。このとき、Extended Dataのみが記録されたGroup DescriptorはGroup IDが欠番となる（図18にその例を示す）。
【００３３】
本実施例におけるGroup Descriptorのサイズは64バイトであるため、一つのInformation Block内に最大127個しか記録できないが、一部の情報をGroup Member Descriptorに移動することにより、一つのInformation Block内に格納できる最大Group数を増加させることができる。たとえば、Create/Modify Date and TimeとExtended DataをGroup Member Descriptorに移動してGroup Descritporのサイズを32KBにすると、一つのInformation Blockに255個格納できる。さらに、8バイト分の情報のみを残すと一つのInformation Blockに1008個格納できるので、メモリ上に記録できるグループ数を増やすことができる。もし、すべての情報をGroup Member Descritporに格納すると、Group DescriptorにはGroup Member Descriptor ID（2バイト）のみが残ることになり、これはグループに関する全情報を納めたGroup Member Descriptorの位置を指すポインタの役割をする。
【００３４】
図19は、親グループと子グループのメンバー情報を記録するParent Group Member Information Block[3]とChild Group Member Information Block[5]の構造を示したもので、両者の構造は同一である。これは8KバイトのInformation Block内に64バイト単位（セル）のグループメンバー情報Parent/Child Group Member Descriptor[34,54]を一覧にしたものであり、グループメンバー情報[34,54]の集合がParent/Child Group Member Descriptors[32,52]である。各64バイト単位のセルに有効なグループ情報が格納されているかどうかを示すのがParent/Child Group Member Descriptor Space Bitmap[31,51]である。一つのInformation Block内にグループメンバー情報[34,54]は最大127個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[31,51]が1ビット／セルで16バイトを用いて管理する。すなわちSpace Bitmap[31,51]の中で”1”で表されるビットのセルには有効なグループメンバー情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[33,53]は、Space Bitmap[31,51]の64バイト単位のセルに対する余剰領域である。なお、グループメンバー情報Parent/Child Group Member Descriptor[34,54]数がM個の場合は、有効データサイズは64＋64×Mバイトになる。また、本実施例において親グループメンバーと子グループメンバーのMember DescriptorはCMF全体で、それぞれ最大16K個まで記録できる。
【００３５】
Group Member Descriptor[34,54]にはグループに含まれるメンバー（子グループやファイル）の一覧が入るので、含まれるメンバーの数によりDescriptorのサイズは変化する。そこで、グループメンバー情報の編集が容易なように、記録単位を64バイトに固定して、メンバー数が多い場合は複数のGroup Member Descriptorに記録する。本実施例では一塊のグループメンバー情報は同一のGroup Member Information Blockに含まれるので、Group Member Descriptor [34,54]を連続して使用できるのは最大127個までということになる。また、本実施例においては、親グループには子グループのみが含まれ、子グループにはファイルのみが含まれるが、プレイリストや印刷を管理するDPOF等の複数ファイルを管理するファイル（グループ化ファイル）も子グループとして扱う。
【００３６】
図20は、Group Member Descriptor[34,54]の構造を示したもので、親グループと子グループで構造は同一である。Group Member TypeとGroup Member AttributeはこのGroup Member Descriptorが属するGroup Descriptorと同一の内容が入る。Next Member Descriptor IDはグループメンバーが一つのGroup Member Descriptorに入りきらなかった場合に次のGroup Member Descriptorを示すもので、Group Member Information Block内の記録位置で示される。これは、CMF全体に含まれるGroup Member Descriptorの記録順序に従った2バイトの通し番号で表される。なお、Next Member Descriptorがない場合（最後のGroup Member Descriptorの場合）は0xFFFFが入る。Number of Membersは、このGroup Member Descriptor[34,54]に含まれるメンバー数で、Member IDsにメンバー一覧が入る。一つのGroup Member Descriptor（64バイト）には最大29個のメンバーを格納でき、一塊のグループに含まれるメンバー数が多くなった場合は、Group Member Descriptor [34,54]を繋げて格納していく。同じグループに属するGroup Member Descriptorsが同一のGroup Member Information Block [3,5]内にすべて含まれなければならない場合は、一つのグループに含まれるメンバー数は最大3683個となる。Member IDの指定方法はNext Member Descriptor IDの指定方法と同様で、子グループIDはChild Group Information [4]に記録されているChild Group Descriptor [44]の順序に従った番号（2バイト）で指定され、ファイルIDは、File Information[6]に記録されているFile Descriptor[64]の順序に従った番号（2バイト）で指定される。
【００３７】
もし、Group Descriptorのサイズを小さくするために、グループ情報の一部をGroup Member Descriptorに記録する場合は、最初のGroup Member Descriptorに移動された情報は格納される。すなわち、最初のGroup Member DescriptorにはGroup Descriptorから移動された情報とGroup Member Descriptorに本来記録されるべき情報が両方含まれることになる。ただし、この場合もGroup Member Descriptorのサイズは64バイトなので、Member IDsに含まれるメンバー数(N)が小さくなる。グループメンバー一覧が最初のGroup Member Descriptorに入りきらない場合は、新たなGroup Member Descriptorに記録することになるが、2つ目以降のGroup Member Descriptorは通常の構造(図20)となる。
【００３８】
図21はファイルの情報を記録するFile Information[6]の構造を示したものである。これは8KバイトのInformation Block内に16バイト単位（セル）のファイル／ディレクトリ情報File Descriptor[64]を一覧にしたものであり、File Descriptor [64]の集合がFile Descriptors[62]で、各16バイト単位のセルに有効なファイル／ディレクトリ情報が格納されているかどうかを示すのがFile Descriptor Space Bitmap[61]である。一つのInformation Block内にFile Descriptor[64]は最大508個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[61]が1ビット／セルで64バイトを用いて管理する。すなわちSpace Bitmap[61]の中で”1”で表されるビットのセルには有効なFile Descriptorが格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。なお、File Descriptor[64]数がF個の場合は、有効データサイズは64＋16×Fバイトになる。また、ファイル／ディレクトリ情報はCMF全体で、最大64K個まで記録できる。
【００３９】
図22はファイルおよびディレクトリ情報であるFile Descriptor[64]の構造を示したものである。File Attributeはファイルやディレクトリの属性情報で、ファイルかディレクトリか、削除されたファイルかどうかや、削除禁止属性等の他に、アフレコ用音声や遷移用映像、説明用のテキストといった補助ファイル属性、File DescriptorにExtended Dataが含まれているかどうか等の情報も入る。File Typeは、動画、静止画、音声、プレイリストといったファイルの種類を示すもので、File Type Table[12]（図5）で示される一覧の番号を1バイトで表す。これによりファイルの拡張子も特定できる。なお、ディレクトリの場合はFile TypeはNull（”0”）となる。Link Countは、子グループの場合と同様に、ファイルが子グループから参照されている数で、Link Countが0なら、そのファイルはどの子グループにも属していないことになる。ファイルのLink Countが1よりも大きい場合はいずれかの子グループから参照されていることになるので、もし削除されても上書きしてはいけない。すなわち、削除されるファイルの属するFile Information Block[6]内のSpace Bitmap[61]で、該当の削除ファイル位置を使用領域（”1”）のままにしておく。こうすることにより、ファイルが削除された場合に、該当するファイルの属する子グループの情報を変更する必要がなくなる（本来、子グループに属するファイルが削除されたら、子グループ情報を変更すべきであるが、変更するには子グループに属するファイルIDを検索する必要があり時間がかかる）。逆に、子グループが削除された場合は、子グループが含むファイルのLink Countを1づつ減少させるが、そのときにLink Countが0になったファイルが削除済みであれば、Space Bitmap[61]で該当のファイル情報位置を空き領域（”0”）に設定し、上書き可能にしておく。なお、File Descriptorがディレクトリ情報の場合はLink Countは常に0である。
【００４０】
Parent Directory IDは親ディレクトリのFile IDで、File Information[6]に記録されているディレクトリ情報File Descriptor[64]の順序に従った番号（2バイト）で指定される。Name LengthとNameはそれぞれファイルあるいはディレクトリ名の長さと実際の名前で、NameはUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で表される。Name領域の先頭1バイトは文字コードの識別子で、UTF-8は0x08、UTF-16は0x10が入る。なお、Name Lengthは文字コード識別子も含んだバイト長であり、Name欄には拡張子を取った名前が最大255バイトまで格納できる。Extended Dataはグループ情報のExtended Data（図15、図16、図17）と同じ構造を持つ。なお、NameとExtended Dataは可変長のため、File Descriptor[64]のサイズが16バイトよりも大きくなるときは（N+Eが10バイト以上のときは）、直後のFile Descriptorに続けて記録し、一つのFile Descriptorが16バイトの整数倍になるようにExtended Dataのサイズを調整する。このとき、File NameやExtended Dataを記録するために用いられたFile Descriptor領域はFile Information[6]のSpace Bitmap [61]で使用領域(“1”)となり、その場所で指定されるFile IDは欠番となる（図23にその例を示す）。
【００４１】
なお、本実施例ではファイル名に実際の文字列を格納しているが、ディレクトリ名やファイル名を2バイトの数値で表現して、File Descriptorのサイズを16バイトよりも小さくすることができる。すなわち、File Descriptor（図22）において、Name LengthとNameを2バイトの値（Name ID）で置き換え、File Descriptorのサイズを8バイトにするのである。図26のディレクトリ構造で示したように、本実施例においては、動画、静止画、音声、プレイリスト等を含むディレクトリ名は、先頭3文字が3桁の数字で表現され、同じ種類のファイルが含まれるディレクトリ名は数字が重なることはない。そのため、File Typeでファイルの種類を指定し、ディレクトリ名としてディレクトリ番号を指定すれば、ディレクトリは一意に求まる。ファイル名に関してもディレクトリ名と同様で、ファイル名に付加されている4桁の数字は、一つのディレクトリの中で同じ種類のファイルで重なることはない。すなわち、File Typeから拡張子がわかるので、ファイル名でファイルの番号を指定することによりファイルは一意に求まる。こうすることにより、一つのInformation Block内に含まれるFile Descriptor数は1008個になり、メモリ上により多くのファイル情報を格納できる。
【００４２】
図24はグループのコメントやベンダー独自のコメントで用いるテキスト情報を記録するText Information [7]の構造を示したものである。これは8KバイトのInformation Block内に128バイト単位（セル）のテキスト情報Text Descriptor[74]を一覧にしたものであり、テキスト情報[74]の集合がText Descriptors[72]で、各128バイト単位のセルに有効なテキスト情報が格納されているかどうかを示すのがText Descriptor Space Bitmap[71]である。一つのInformation Block内にテキスト情報[74]は最大63個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[71]が1ビット／セルで8バイトを用いて管理する。すなわちSpace Bitmap[71]の中で”1”で表されるビットのセルには有効なテキスト情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[73]は、Space Bitmap[71]の128バイト単位のセルに対する余剰領域である。なお、テキスト情報Text Descriptor[74]数がT個の場合は、有効データサイズは128＋128×Tバイトになる。
【００４３】
Management Information[1]には、Information Blockが最大1664個まで記録でき、Parent Group Information[2]、Parent Group Member Information[3]、Child Group Information[4]、Child Group Member Information[5]、File Information [6]がそれぞれ最大130個づつ使用する。また、親グループと子グループのコメント用にText Information[7]を521個確保しておく必要があるため、ユーザーが自由に使えるText Information[7]とVendor Specific Information[8]の合計は493個である。
【００４４】
図25はテキスト情報であるText Descriptor[64]の構造を示したものである。Text Attributeはテキストの属性情報で、削除されたテキストかどうかや、削除禁止属性等が入る。Object Typeは、テキストを参照している情報（Object）の種類を指し、Block Type Table[14]（図7）のType値で示される。Object IDはテキストを参照しているObject Information（Group Information等）に記録されているObject Descriptor（Group Descriptor等）の順序に従った番号が2バイトで指定される。Object TypeとObject IDにより、テキストを参照している情報（グループ等）の逆参照が可能になる。Text Lengthには文字列の長さを記録し、Text欄に実際の文字列をUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で記録する。Text領域の先頭1バイトは文字コードの識別子で、UTF-8は0x08、UTF-16は0x10が入る。なお、Text Lengthは文字コード識別子も含んだバイト長であり、Text欄には最大123バイトまで格納できる。
【００４５】
２．CMFの操作手順
次に、CMFを用いたファイル管理の手順について図43を用いて説明する。図43では、電源投入時あるいはディスク挿入時から、電源切断時あるいはディスク取り出し時までの処理を示している。CMF全体のサイズは可変であるが、すべての情報は8Kバイト単位のInformation Blockに含まれており、それらのInformation BlockはCMFの先頭16KバイトのManagement Informationで管理されるので、Management Informationを読み込むことによりCMF全体の構造を知ることができる。そのため、電源投入時あるいはディスク挿入時には、まずManagement Informationをディスクから読み込む。その後、必要に応じてアプリケーションはManagement Information に基づいてInformation Blockをディスクから読み込むのであるが、ディスク初期化時に構成される、グループ情報、グループメンバー情報、ファイル情報、テキスト情報の48Kバイト分をManagement Informationと一緒に最初から読み込んでおいてもよい。
【００４６】
次に、グループやファイル一覧を表示する場合には、アプリケーションは読み込んだManagement Information に基づいて所望の表示を行う。表示形態はアプリケーション側の設定次第であり、詳しくは後述する。また、ディスク内容が変更された場合やグループ情報が追加・編集された場合にはCMFの内容を編集することになる。このとき、グループ化はユーザーが指定して行う場合の他に、システムが日付等で自動的に行うグループ化の2種類がある。いずれの場合においても、必要とするInformation Blockがメモリ上になければManagement Information内のInformation Block Tableを利用して、ディスクからInformation Blockを読み出す操作が必要となる。一連の処理が終了し、電源切断やディスクの取り出しを行う時、もし、CMFファイルの内容が変更されているならば、ディスクに更新されたCMFを書き戻す。なお、CMFをディスクに書き戻すタイミングは終了処理時以外でも構わない。
【００４７】
３．CMFの情報を用いた表示例
CMFを使ってグループやファイルを参照する手順の一例について説明する。図54はCMFの全体構造例である。まず、Information Block Descriptor[17]がCMFに含まれている各Information Blockを指し示し[B2〜B8]、位置や種類や内容等の情報を管理している。Parent Group Descriptor[24]は自分が含むメンバー一覧であるParent Group Member Descriptor[34]を示し[G2]、Parent Group Member Descriptor [34]はメンバーであるChild Group Descriptor[44]を示す[G3]。Child Group Descriptor[44]は自分が含むメンバー一覧であるChild Group Member Descriptor[54]を示し[G4]、Child Group Member Descriptor[54]はメンバーであるFile Descriptor[64]を示す[G5]。このとき、逆方向を示す情報はなく、親グループには子グループしか含まれず、子グループにはファイルしか含まれない。Text Descriptor[74]はParent Group Descriptor[24]、Child Group Descriptor[44]、Vendor Specific Information Block[8]から参照されるが[T2,T4,T8]、Text Descriptor[74]自身も参照元の情報を持っているので双方向にリンクされている。CMF末尾にあるDummy Information Block[9]は、CMFのサイズをECCブロック（たとえば32KB）の整数倍にそろえるために挿入する8KBのダミーBlockである。これはCMFが含まれるECCブロック内に他のデータが記録されることを防ぐもので、CMFの末尾にInformation Blockを追加する場合に置き換えられる。また、各Information Blockの先頭をECCブロックの先頭に一致させることにより、各Information Blockが複数のECCブロックにまたがって記録されることがなく、Information Blockの更新や追加が効率よく行える。
【００４８】
例えば、図55のようなグループ一覧を表示する場合には、先ず、アプリケーションは事前に読み込んであるManagement Informationに含まれるInformation Block Descriptor[17]を調べ、Block TypeがGroup Information であるInformation Block Descriptor[17]を抽出する。Information Block Descriptor [17]の記録順番は、そのまま該当ブロック[2,3,4,5,6,7,,,]の記録位置を示すものであるから、記録順番をアドレスに変換し、該当するGroup Information[2,4]にアクセスする。次に、Group Information[2,4]に含まれるGroup Descriptor [24,44]から名前やコメント等を抽出して必要な項目をディスプレイに表示するのである。ただし、コメントはText Information Block[7]に記録されており、Group Descriptor [24,44]内にはコメントを指すテキストIDしか含まれていない。そのため、Information Block Descriptor[17]を参照して、目的とするテキストIDのText Information Block[7]にアクセスし、Text Descriptor[74]を読み出す必要がある。Text Descriptor [74]には、自身を参照しているGroup Descriptor[24,44]への逆参照情報が含まれているので、この逆参照情報を利用すれば、コメントを検索して、そのコメントが含まれるグループ情報を取り出すことは容易である。
【００４９】
次に、他の表示形態について図56、図57を用いて説明する。図55では、ディスプレイ[100]上に画面のタイトル[101]と親グループのコメント[104]が並び、表示領域をスクロールバー[102]で表現している。ここで、枠[103]で囲まれている親グループを選択した場合、指定された親グループに所属する子グループの一覧が図56のように表示される。これは、選択された親グループに関連するParent Group Member Descriptor[34]から属する子グループのグループＩＤを取得し、そのグループＩＤからChild Group Descriptor[44]にアクセスし、選択した親グループに属する子グループ一覧を表示する。このとき、代表画像およびコメントの実体はChild Group Descriptor[44]内には含まれていないので、Thumbnail IDとComment IDから目的とするFile Descriptor[64]やText Descriptor [74]にアクセスして読み出す必要がある。この表示中に、削除されている子グループが見つかれば、その子グループのLink Countを1減らす。もしLink Countが 0になれば、その子グループの属するInformation Blockで、Space Bitmapの該当個所の値を”0”（上書き可能）にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。
【００５０】
図56の表示例では、ディスプレイ[100]上に画面のタイトル[101]と子グループのサムネイル画像[106]およびコメント[105]が並び、表示領域をスクロールバー[102]で表現している。子グループのサムネイルはThumbnail IDで表される代表ファイルのサムネイルであり、代表ファイルが指定されていなければ、子グループに含まれるファイル一覧の先頭ファイルが代表となる。また、選択されている子グループは枠[103]で囲まれており、この状態で決定すると指定された子グループに所属するファイルの一覧が表示されるか、ファイルが順次再生される。なお、ファイルが順次再生される場合に、補助属性を持つファイルは再生を飛ばしてもよい。もし、子グループがプレイリストの場合はプレイリストが実行される。ファイルの一覧表示や順次再生中に、削除されているファイルが見つかれば、そのファイルのLink Countを1減らす。もしLink Countが 0になれば、そのファイルの属するInformation Blockで、Space Bitmapの該当個所の値を”0”（上書き可能）にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。
【００５１】
図57には選択した子グループに属するファイル一覧の表示例が示されている。表示に必要な情報の取得は上述と同様な手順で行われ、この例ではサムネイル画像のみを表示している。ディスプレイ[100]上に画面のタイトル[101]とファイルのサムネイル画像[107]が並び、表示領域をスクロールバー[102]で表現している。また、選択されているファイルは枠[103]で囲まれており、この状態で決定すると指定されたファイルが実行される。もしファイルが静止画なら静止画が表示され、ファイルが動画なら動画の再生が開始される。なお、補助属性を持つファイルは一覧の中に表示しなくてもよい。
【００５２】
以上、3種類の表示例を示したが、親グループ、子グループ、ファイルで上記の表示例に決まっているわけではなく、たとえば親グループの表示に代表子グループのサムネイルとコメントを同時に表示してもよく、ファイル一覧の表示にコメントのみを用いてもよい。
【００５３】
４．CMFの更新手順
次にCMFの内容を更新する場合について説明する。先ず、更新によるCMFのデータ構造の変化を各状況に応じて説明する。
【００５４】
図27はディスク初期化時のディレクトリ構造で、図28はそのときのCMF構造である。初期化時は、ROOT[80]、MISC[81]、DCIM[82]、VIDEO[83]のディレクトリがあるだけで、ファイルは存在しない。CMFは16KバイトのManagement Information 1つと8KBのInformation Block 6個で構成されており、4つのディレクトリ情報と2つのグループ情報が含まれている。まず、本実施例においては、日付グループとプレイリストグループをデフォルトで持つので、これらの親グループ、すなわちParent Group Descriptor[22]と対応するParent Group Member Descriptor[32]が2つづつ作成される。このときParent Group Member Descriptor[32]は枠組みがあるだけで、メンバーは含まれていない。また、ディレクトリが4つあるので、ディレクトリ情報のFile Descriptor[62]が4つ作成される。これらのInformation Block内にあるSpace Bitmapは、データの入ったObject Descriptorの位置に該当するビットを”1”にしておく。子グループ情報[42,52]とテキスト情報[72]には何もデータが入っていない。Information Block Table[16]にはManagement Information[1]以外の6個分のBlockに関する情報が含まれる。なお、各Information Block内のReserved領域はSpace Bitmap領域に含めているので、図中には示していない。
【００５５】
図29は、初期化直後に動画ファイル（TAKE0001.MPG）[93]を一つだけ記録したときのディレクトリ構造であり、VIDEOディレクトリ[83]の下に動画ディレクトリ（100MOVIE）[85]が自動的に作成され、動画ファイルはこの下に記録される。図30はこのときのCMF構造である。図28と比較して、File Information[6]内のFile Descriptors[62]にディレクトリ情報とファイル情報が1つづつ追加される。ファイルが追加されると、自動的に日付グループに登録されるので、日付子グループのChild Group Descriptor[42]とそのメンバーであるChild Group Member Descriptor[52]が1つづつ自動生成される。新たに作成されたファイルはDate Child Group Member Descriptor[52]のメンバーとして登録され、今回作成されたDate Child Group Descriptor[42]も日付グループのDate Parent Group Member Descriptor[32]のメンバーとして登録される。このとき、Descriptorが追加されたInformation BlockはSpace Bitmapの記録位置に該当するビットを”0”から”1”に変更し、同時にInformation Block Table[16]の情報も更新する。
【００５６】
図31は、動画ディレクトリ[85]が2つと動画ファイル[93]が12個記録された状態から、新たにプレイリストファイル（PLAY0001.XML）[95]を追加したときのディレクトリ構造である。この例では、12個のファイルは2つのディレクトリに分割して記録されているので、動画ディレクトリ[85]は2つできている。プレイリストファイル[95]を新たに作成すると、VIDEOディレクトリ[83]の下にプレイリストディレクトリ（300PLIST）[87]が自動的に作成されて、プレイリストファイルはこの下に記録される。図32はこのときのCMF構造で、ディレクトリとファイルが一つづつ増えて合計20個になったので、File Descriptors[62]の数は20になっている。さらにプレイリストファイルが追加されると、自動的にプレイリストグループに登録されるので、プレイリスト子グループのChild Group Descriptor[42]とそのメンバーであるChild Group Member Descriptor[52]が1つづつ自動生成される。新たに作成されたプレイリストファイルはPlay List Child Group Member Descriptor[52]のメンバーとして登録され、今回作成されたPlay List Child Group Descriptor[42]もプレイリストグループのPlay List Parent Group Member Descriptor[32]のメンバーとして登録される。このとき、Descriptorが追加されたInformation BlockはSpace Bitmapの記録位置に該当するビットを”0”から”1”に変更し、同時にInformation Block Table[16]の情報も更新する。
【００５７】
図33は図32の状態から、30個以上のファイルを含むコメント付き子グループを1つだけ追加したときのCMF構造である。プレイリスト等のグループ化ファイル以外にグループ化を行った場合は、実際のファイルは作成されないので、ディレクトリ構造は図31のままである。まず、30個以上（58個以下）の子グループはChild Group Member Descriptor[52]を2つ必要とするので、Child Group Member Descriptors [52]の子グループ数が2つと、それを参照するChild Group Descriptor[42]が1つ増加する。一塊のグループが消費するGroup Member Descriptor[52]の数に関わらず、Group Descriptor[42]は1つのグループに対し1しか増加しない。コメントはText Information[7]に記録されるので、Text Descriptor[72]が1つ増加する。以上3箇所の変更に対して、対応するInformation BlockのSpace Bitmap[41,51,71]とInformation Block Table [16]の情報が更新される。
【００５８】
図34は図33の状態から、子グループにメンバーを追加してChild Group Member Descriptor[52]が新たに作成されたときのCMF構造である。グループにメンバーを追加する場合は、既存のGroup Member Descriptorに空きがあればそこに埋めることができるが、空きがなければ新たにGroup Member Descriptorを作成する必要がある。この例ではChild Group Member Descriptor[52]を1つ追加している。同時に、新規Child Group Member Descriptor[52]に繋がるChild Group Member Descriptor[52]のNext Member Descriptor IDも更新する必要がある。これに伴い、対応するInformation BlockのSpace Bitmap[51]とInformation Block Table [16]の情報が更新される。
【００５９】
図35は図34の状態から、コメント付き親グループを1つだけ追加したときのCMF構造である。この場合もディレクトリ構造は図31のままで変化しない。まず、新たに追加される親グループには29個以下の子グループしか含まれていないので、Parent Group Descriptor[22]とParent Group Member Descriptor[32]は1つづつ増加する。コメントはText Information[7]に記録されるので、Text Descriptor[72]が1つ増加する。以上3箇所の変更に対して、対応するInformation BlockのSpace Bitmap[21,31,71]とInformation Block Table [16]の情報が更新される。
【００６０】
図36は初期化時のCMF容量が一杯になるデータ数を示しており、親グループ数、親グループメンバー数、子グループ数、子グループメンバー数はそれぞれ127個、ファイル数は508個、テキスト数は63個である。なお、実際にはグループ数はグループメンバー数よりも多くなることはない。
【００６１】
図37は初期化時のCMFが一杯になった状態から、ファイルが一つ追加された場合のCMF構造である。まず、CMFが一杯になった状態として、親グループ数と子グループ数がそれぞれ127個、ファイル数が508個、テキスト数が63個の状態だとする。この例ではGroup Descriptor 1つにつき、Group Member Descriptorは1つしか存在しないことを意味している。ここにファイル情報を1つ追加する場合、すでに存在するFile Information Block 1 [61,62]には空き領域がないので、CMFの末尾に新たなFile Information Block 2 [65,66]を追加する必要がある。その後、新たに追加されたFile Information Block 2 [65,66]にFile Descriptor 2 [66]を記録するのである。同時に、新規ファイルは自動的に日付グループに登録されるので、対応するDate Child Group Member Descriptor [52]のメンバーとして登録される。これに伴い、対応するSpace Bitmap 2 [65]の情報が更新されるとともに、Information Block Table[16]にブロック数が1つ追加される。
【００６２】
図38は図37の状態から、子グループにファイルを追加してChild Group Member Information Blockが新たに追加されたときのCMF構造である。グループにメンバーを追加する場合は、既存のGroup Member Descriptorに空きがあればそこに埋めることができるが、空きがなければ新たにGroup Member Descriptorを作成する必要がある。さらにこの例では、既存のChild Group Member Information Block 1 [51,52]に空き領域がないために、新たにCMF末尾にChild Group Member Information Block 2 [55,56]を追加し、Child Group Member Descriptor 2 [56]を作成している。同時に、新規Child Group Member Descriptor 2 [56]に繋がるChild Group Member Descriptor 1 [52]のNext Member Descriptor IDも更新する必要がある。これに伴い、対応するSpace Bitmap 2 [55]の情報が更新されるとともに、Information Block Table[16]にブロック数が1つ追加される。
【００６３】
図39は図38に続いてコメント付き子グループを追加したもので、既に存在するInformation Blockが一杯なので、新たにChild Group Information BlockとText Information Blockが追加されている。まず新規子グループ用にChild Group Information Block 2 [45,46]がCMFに追加され、そのメンバーがChild Group Member Descriptors 2 [56]に追加される。さらに子グループから参照されるコメントを格納するために、Text Information Block 2 [75,76]がCMFに追加され、Text Descriptors 2 [76]にテキスト情報が1つ追加される。これに伴い、対応するSpace Bitmap[45,55,75]の情報が更新されるとともに、Information Block Table [16]にブロック数が2つ追加される。
【００６４】
図40も図38と同様に、既に存在する子グループにファイルを追加したものであるが、この場合は追加される子グループの入っているInformation Block 1 [51,52]が既に一杯で追加できないときに、関連するグループメンバー情報全体を別のInformation Block 2 [55,56]に移動させている。なお、ファイルを追加する前のChild Group Member Descriptorは1つのみであり、新たにChild Group Member Descriptorを1つ追加するものと考える。一塊のグループを同一のInformation Blockに含ませるために、まず元のChild Group Member Descriptor 1 [52]をChild Group Member Descriptors 1 [52]からChild Group Member Descriptors 2 [56]に移動して、そこに新たにChild Group Member Descriptor 2 [56]を追加する。結果として、移動先であるChild Group Member Descriptors 2 [56]の子グループ数は2つ増加し、移動元のChild Group Member Descriptors 1 [52]の子グループ数は1つ減少する。さらに、Child Group Member Descriptorを参照しているChild Group Descriptor 1 [42]のGroup Member Descriptor IDの値も更新する必要がある。最後に、対応するSpace Bitmap[51,55]とInformation Block Table[16]の情報も更新する。
【００６５】
次にファイルやグループを削除した場合に関して説明する。図41はFile Descriptors 1 [62]に含まれるファイルを1つ削除した場合で、削除されるFile Descriptorに削除属性を付与する。このとき、Space Bitmap 1 [61]の該当個所の値を”0”（削除済み）にするかどうかは、削除ファイルのLink Countの値に依存する。もし、Link Countが0ならば、Space Bitmap 1 [61]の値を”0”にしてもよく、Link Countが1より大きい場合は、そのファイルはいずれかの子グループから参照されているので、Space Bitmap 1 [61]の値は”1”のままにして、上書き禁止にしておく。もしSpace Bitmap 1 [61]の値を変更した場合は、Information Block Table[16]の情報も更新する。
【００６６】
図42は、メンバー情報として2つのChild Group Member Descriptorを持つコメント付き子グループ情報Child Group Descriptorを1つ削除した場合のCMF構造である。まず、Child Group Descriptors 1 [42]で、削除する Group Descriptorに削除属性を付与する。このとき、Space Bitmap 1 [41]の該当個所の値を”0”（削除済み）にするかどうかは、削除グループのLink Countの値に依存する。もし、Link Countが0なら、Space Bitmap 1 [41]の値を”0”にしてもよく、Link Countが1より大きい場合は、そのグループはいずれかの親グループから参照されているので、Space Bitmap 1 [41]の値は”1”のままにして、上書き禁止にしておく。なお、親グループのLink Countは常に0なので、親グループを削除する場合は、Space Bitmapの該当個所を”0”（削除済み）に設定しても構わない。つぎに削除した子グループのメンバー情報を示すChild Group Member Descriptor 1 [52]を2つ削除する。これは削除する位置情報に対応したSpace Bitmap 1 [51]の該当個所を”0”（削除済み）に設定すればよい。続いて、削除グループが参照していたText Descriptors 1 [72]のテキスト情報を削除する。これも削除するテキストに対応したSpace Bitmap 1 [71]の該当個所を”0”（削除済み）に設定すればよい。以上、変更した3つのInformation BlockでSpace Bitmap [41,51,71]の値を変更した場合は、Information Block Table[16]の情報も更新する。
【００６７】
図44はInformation Blockの新規追加手順を示したものである。Information BlockはObject Descriptorの情報を追加する空き領域がなくなった場合に新たに追加される。まず、CMFの末尾に8Kバイトの領域を確保し、追加すべきDescriptor等の情報があれば、Space BitmapとReserved領域に続くDescriptor記録領域の先頭から必要な情報を記録するとともに、記録位置に該当するSpace Bitmapの個所を”1”に設定する。その後、Management Information内のInformation Block TableにInformation Block Descriptorを1つ追加し必要事項を記録する。Information Block Tableを変更したら、General Information内のオブジェクト数等の該当項目を更新する。
【００６８】
図45はDescriptorサイズが固定長である、グループ、ファイル、テキスト情報（オブジェクト）の新規追加手順を示したものである。これらの情報は記録サイズが固定長なので、空き領域が1つでもあれば記録可能である。まず、既存のInformation Blockに空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsが最大記録可能数よりも小さければよい。もし、既存のInformation Blockに空きがあればそこに記録すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを記録する。既存のInformation Block内に記録する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、新規オブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、新規オブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。記録したら、同じInformation Block内のSpace Bitmapで該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを1増やすとともに、必要ならData Lengthも増加させる。Data Lengthは新規作成したオブジェクトが有効データ長の末尾に付加された場合のみ増加し、途中の削除された領域に記録された場合には増加しない。
【００６９】
図46はDescriptorサイズが可変長である、グループメンバー情報（オブジェクト）の新規追加手順を示したものである。これらの情報は記録サイズが可変長なので、空き領域が足りるかどうかを判定しなければならない。まず、既存のInformation Blockに十分な空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsを最大記録可能数から引いて比較すればよい。もし、既存のInformation Blockに十分な空きがあればそこに記録すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを記録する。既存のInformation Block内に記録する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、新規オブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、新規オブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。記録したら、同じInformation Block内のSpace Bitmapで該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを追加オブジェクト数だけ増やすとともに、必要ならData Lengthも増加させる。Data Lengthは新規作成したオブジェクトが有効データ長の末尾に付加された場合のみ増加し、途中の削除された領域に記録された場合には増加しない。なお、グループメンバー情報を追加した場合は、そのGroup Member Descriptorを参照するGroup Descriptor のGroup Member ID、または直前のGroup Member DescriptorのNext Member IDを新規Member Descriptor IDに更新する必要がある。
【００７０】
次に、オブジェクトを削除する手順に関して説明する。図47はファイル情報の削除手順を示したものである。まず、File Descriptor内のFile Attributeで削除属性を付加し、Link Countが0の場合は同じInformation Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。Link Countが0でない場合は上書きしてはいけないので、Space BitmapもInformation Block Descriptorも変更しない。このとき、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。
【００７１】
図48はテキスト情報の削除手順を示したものである。テキストの場合はそのテキストを参照しているグループから切り離す必要があるので、そのグループのComment IDの値を0xFFFFにして、コメントなしにしておく。その後、同じInformation Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。このとき、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。
【００７２】
図49は子グループ情報の削除手順を示したものである。まず削除する子グループのGroup Descriptorに削除属性を付与する。このとき、Link Countが0の場合は上書きしてもよいので、Space Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。次に、コメントがある場合は、Text Informationの中の対応するテキストを削除する。続いてGroup Member IDをたどり、子グループに含まれるGroup Member Descriptorをすべて削除する。最後に子グループに含まれるファイルのLink Countをすべて1づつ減少させる。このとき、もしファイルが削除済みで、かつLink Countが0ならば、そのファイルの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にして上書き可能にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。なお、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。
【００７３】
図50は親グループ情報の削除手順を示したものである。親グループの場合は必ずLink Countが0なのでGroup Descriptorを完全に削除してもよく、Space Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。このとき、完全に削除されてしまうので、子グループの削除と違い、削除属性を付与する必要はない。次に、コメントがある場合は、Text Informationの中の対応するテキストを削除する。続いてGroup Member IDをたどり、親グループに含まれるGroup Member Descriptorをすべて削除する。最後に親グループに含まれる子グループのLink Countをすべて1づつ減少させる。このとき、もし子グループが削除済みで、かつLink Countが0ならば、その子グループの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にして上書き可能にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。なお、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。
【００７４】
図51はグループメンバー情報（オブジェクト）の移動手順を示したものである。これらの情報は記録サイズが可変長なので、空き領域が足りるかどうかを判定しなければならない。まず、既存のInformation Blockに十分な空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsを最大記録可能数から引いて比較すればよい。もし、既存のInformation Blockに十分な空きがあればそこに移動すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを移動する。既存のInformation Block内に移動する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、移動するオブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、移動するオブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。移動したら、移動先のInformation Block内でSpace Bitmapの該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを1増やすとともに、必要ならData Lengthも増加させる。また、移動したグループメンバーの属するGroup DescriptorのMember ID、または直前のGroup Member DescriptorのNext Member IDの値を新規Member Descriptor IDに書き換える。最後に移動元Group Member Information Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。
【００７５】
続いて、親グループや子グループに含まれるメンバー（子グループやファイル等のオブジェクト）の追加／削除手順に関して説明する。図52はグループへのメンバー追加手順を示したものである。まず、追加したいグループのGroup Member Descriptorにメンバーを追加できる空き領域があれば、単に目的のGroup Member Descriptor内でオブジェクトIDを追加し、Total Number of Members情報を更新した後に、追加されたオブジェクトのLink Countを1づつ増加させればよい。もし領域が足らなければ、同じGroup Member Information Block内でGroup Member Descriptorを必要な数だけ追加する。このとき、オブジェクトを追加したいGroup Member Descriptorが含まれるGroup Member Information Block内にGroup Member Descriptorを追加する空き領域がなければ、別のGroup Member Information Blockに、1つのグループに属するすべてのGroup Member Descriptorを移動させてもよい。なお、既存のGroup Member Information Blockで空き領域が見つからなければ、新たにGroup Member Information Blockを作成する。
【００７６】
図53は親グループや子グループに含まれるメンバー（子グループやファイル等のオブジェクト）をグループのメンバーから削除する手順を示したものである。まず、削除したいメンバーをGroup Member Descriptorからとり除き、Total Number of Members情報を更新した後に、削除したオブジェクトのLink Countを1づつ減少させる。このとき、もしオブジェクトが削除済みで、かつLink Countが0ならば、そのオブジェクトの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。さらに、グループからメンバーを削除することにより、何もメンバーを含まないGroup Member Descriptorが発生した場合は、そのグループ全体に渡ってNext Member Descriptor IDを付け直し、不要になったGroup Member Descriptorを削除する。
【産業上の利用可能性】
【００７７】
以上述べてきたように、必要な全ファイルと全グループを一括管理するファイルであるCMF（Contents Management File）を設けることにより、アプリケーションはファイルシステムを使わずに、CMFを通して大量のファイルを扱ったり、グループ化等の必要な処理を汎用的に行うことが可能になる。たとえば、複数のファイルを時系列に表示するには、日付順のグループ化を行うか、ファイル情報を時系列にCMFに記録し順番に再生するだけでよい。また、グループ情報を親グループと子グループに階層化することで、グループの管理も容易になる。
【００７８】
また、CMF内で各グループが含んでいるメンバー（子グループやファイル等のオブジェクト）の一覧を持ち、オブジェクトが自身の含まれるグループの数であるリンクカウンタを持つことで、あるグループに含まれるメンバー一覧をすぐに取り出すことができるとともに、あるオブジェクトがいずれかのグループに含まれているかどうかを簡単に判断できるようになる。これにより、いずれかのグループに含まれているオブジェクトを削除する場合に、警告等を出すことが容易になる。
【００７９】
CMFで拡張子をテーブルを用いて1バイトで表すことにより、ファイル名の情報量を減らすことができる。さらに、拡張子テーブルは、同じ拡張子でも種類により別の物として扱うことで、ファイルの種類を拡張子には関係なく分類できる。また、ファイル自身にも補助ファイル属性を設けることにより、一般の映像や音声等と区別することができる。
【００８０】
グループメンバー情報は、含まれるメンバー数によりサイズが変化するが、固定長サイズ（64バイト）の領域（セル）を連結して使うことにより、追加や削除等の処理を効率よく行うことが可能になる。また、グループ情報やメンバー情報は固定長（8Kバイト）の領域（Block）に分割記録され、同じグループに属する一連のメンバー情報は同一Blockに記録されるので、読み出し効率が高くなる。さらに、グループのコメントは別Blockに記録されるので、コメントのないグループ等を記録する場合に、格納効率が上がる。
【００８１】
各Block内の空き領域は、それぞれのBlock内のSpace Bitmapで管理し、各Block内の空き領域数やデータ長は、CMF先頭の管理Blockで管理することにより、メモリ上に常駐しておくデータ量を減らすとともに、検索量を減らすことが可能となる。さらに、ファイルやグループを指定するときに、記録されている位置の順番で指定することにより、ファイル情報やグループ情報の中に自身のID番号をもたなくてもよく、サイズの節減になるとともに、ファイル情報やグループ情報の指定において検索処理が不要となる。
【図面の簡単な説明】
【００８２】
【図１】Contents Management Fileの全体構造を示す図である。
【図２】Contents Management Fileの役割を示す図である。
【図３】Management Informationの構造を示す図である。
【図４】General Informationの構造を示す図である。
【図５】File Type Tableの構造を示す図である。
【図６】Vendor ID Tableの構造を示す図である。
【図７】Block Type Tableの構造を示す図である。
【図８】Information Block Type Descriptorの構造を示す図である。
【図９】Information Type一覧を示す図である。
【図１０】Number Management Tableの構造を示す図である。
【図１１】Information Block Descriptorの構造を示す図である。
【図１２】Block Specified Dataの構造を示す図である。
【図１３】Parent/Child Group Information Blockの構造を示す図である。
【図１４】Group Descriptorの構造を示す図である。
【図１５】Extended Dataの構造を示す図である。
【図１６】Data Elementの構造を示す図である。
【図１７】Data Type一覧を示す図である。
【図１８】存在しないGroup IDの例を示す図である。
【図１９】Parent/Child Group Member Information Blockの構造を示す図である。
【図２０】Parent/Child Group Member Descriptorの構造を示す図である。
【図２１】File Informationの構造を示す図である。
【図２２】File Descriptorの構造を示す図である。
【図２３】存在しないFile IDの例を示す図である。
【図２４】Text Informationの構造を示す図である。
【図２５】Text Descriptorの構造を示す図である。
【図２６】ディスク内のディレクトリ構造を示す図である。
【図２７】ディスク初期化時のディレクトリ構造を示す図である。
【図２８】ディスク初期化時のＣＭＦ構造を示す図である。
【図２９】ファイル(TAKE0001.MPG)追加時のディレクトリ構造を示す図である。
【図３０】ファイル(TAKE0001.MPG)追加時のＣＭＦ構造を示す図である。
【図３１】プレイリスト(PLAY0001.XML)追加時のディレクトリ構造を示す図である。
【図３２】プレイリスト(PLAY0001.XML)追加時のＣＭＦ構造を示す図である。
【図３３】多数ファイルを含むコメント付き子グループを１つ追加した時のＣＭＦ構造を示す図である。
【図３４】子グループのメンバー追加時にMember Descriptorを新たに追加した時のCMF構造を示す図である。
【図３５】コメント付き親グループを１つ追加した時のＣＭＦ構造を示す図である。
【図３６】初期化時のＣＭＦ容量が一杯になるデータ数を示す図である。
【図３７】ＣＭＦにFile Information Blockを新規追加した場合を示す図である。
【図３８】CMFにChild Group Member Information Blockを新規追加した場合を示す図である。
【図３９】CMFにChild-Group/Text Information Blockを新規追加した場合を示す図である。
【図４０】空き領域のないInformation BlockにGroup Member Descriptorを追加した場合を示す図である。
【図４１】ファイルを1つ削除した場合を示す図である。
【図４２】2つのMember Descriptorsから成るコメント付き子グループを1つ削除した場合を示す図である。
【図４３】CMFファイルの処理手順を示す図である。
【図４４】Information Blockの新規追加手順を示す図である。
【図４５】グループ情報／ファイル情報／テキスト情報の新規追加手順を示す図である。
【図４６】グループメンバー情報の新規追加手順を示す図である。
【図４７】ファイル情報の削除手順を示す図である。
【図４８】テキスト情報の削除手順を示す図である。
【図４９】子グループ情報の削除手順を示す図である。
【図５０】親グループ情報の削除手順を示す図である。
【図５１】グループメンバー情報の移動手順を示す図である。
【図５２】グループへのメンバー追加手順を示す図である。
【図５３】グループからのメンバー削除手順を示す図である。
【図５４】CMFの各Descriptor間の関係を示す図である。
【図５５】親グループ一覧表示例を示す図である。
【図５６】子グループ一覧表示例を示す図である。
【図５７】ファイル一覧表示例を示す図である。
【符号の説明】
【００８３】
１  Management Information
２  Parent Group Information
３  Parent Group Member Information
４  Child Group Information
５  Child Group Member Information
６  File Information
７  Text Information
１１  General Information
１２  File Type Table
１３  Vendor ID Table
１４  Block Type Table
１５  Number Management Table
１６  Information Block Table
２１  Space Bitmap
２２  Parent Group Descriptors
３１  Space Bitmap
３２  Parent Group Member Descriptors
４１  Space Bitmap
４２  Child Group Descriptors
５１  Space Bitmap
５２  Child Group Member Descriptors
６１  Space Bitmap
６２  File Descriptors
７１  Space Bitmap
７２  Text Descriptors
【図３２】
2004537089.tif 000003
【図１】
2004537089.tif 000004
【図２】
2004537089.tif 000005
【図３】
2004537089.tif 000006
【図４】
2004537089.tif 000007
【図５】
2004537089.tif 000008
【図６】
2004537089.tif 000009
【図７】
2004537089.tif 000010
【図８】
2004537089.tif 000011
【図９】
2004537089.tif 000012
【図１０】
2004537089.tif 000013
【図１１】
2004537089.tif 000014
【図１２】
2004537089.tif 000015
【図１３】
2004537089.tif 000016
【図１４】
2004537089.tif 000017
【図１５】
2004537089.tif 000018
【図１６】
2004537089.tif 000019
【図１７】
2004537089.tif 000020
【図１８】
2004537089.tif 000021
【図１９】
2004537089.tif 000022
【図２０】
2004537089.tif 000023
【図２１】
2004537089.tif 000024
【図２２】
2004537089.tif 000025
【図２３】
2004537089.tif 000026
【図２４】
2004537089.tif 000027
【図２５】
2004537089.tif 000028
【図２６】
2004537089.tif 000029
【図２７】
2004537089.tif 000030
【図２８】
2004537089.tif 000031
【図２９】
2004537089.tif 000032
【図３０】
2004537089.tif 000033
【図３１】
2004537089.tif 000034
【図３３】
2004537089.tif 000035
【図３４】
2004537089.tif 000036
【図３５】
2004537089.tif 000037
【図３６】
2004537089.tif 000038
【図３７】
2004537089.tif 000039
【図３８】
2004537089.tif 000040
【図３９】
2004537089.tif 000041
【図４０】
2004537089.tif 000042
【図４１】
2004537089.tif 000043
【図４２】
2004537089.tif 000044
【図４３】
2004537089.tif 000045
【図４４】
2004537089.tif 000046
【図４５】
2004537089.tif 000047
【図４６】
2004537089.tif 000048
【図４７】
2004537089.tif 000049
【図４８】
2004537089.tif 000050
【図４９】
2004537089.tif 000051
【図５０】
2004537089.tif 000052
【図５１】
2004537089.tif 000053
【図５２】
2004537089.tif 000054
【図５３】
2004537089.tif 000055
【図５４】
2004537089.tif 000056
【図５５】
2004537089.tif 000057
【図５６】
2004537089.tif 000058
【図５７】
2004537089.tif 000059
【国際公開パンフレット】
2004537089.tif 000060
2004537089.tif 000061
2004537089.tif 000062
2004537089.tif 000063
2004537089.tif 000064
2004537089.tif 000065
2004537089.tif 000066
2004537089.tif 000067
2004537089.tif 000068
2004537089.tif 000069
2004537089.tif 000070
2004537089.tif 000071
2004537089.tif 000072
2004537089.tif 000073
2004537089.tif 000074
2004537089.tif 000075
2004537089.tif 000076
2004537089.tif 000077
2004537089.tif 000078
2004537089.tif 000079
2004537089.tif 000080
2004537089.tif 000081
2004537089.tif 000082
2004537089.tif 000083
2004537089.tif 000084
2004537089.tif 000085
2004537089.tif 000086
2004537089.tif 000087
2004537089.tif 000088
2004537089.tif 000089
2004537089.tif 000090
2004537089.tif 000091
2004537089.tif 000092
2004537089.tif 000093
2004537089.tif 000094
2004537089.tif 000095
2004537089.tif 000096
2004537089.tif 000097
2004537089.tif 000098
2004537089.tif 000099
2004537089.tif 000100
2004537089.tif 000101
2004537089.tif 000102
2004537089.tif 000103
2004537089.tif 000104
2004537089.tif 000105
2004537089.tif 000106
2004537089.tif 000107
2004537089.tif 000108
2004537089.tif 000109
2004537089.tif 000110
2004537089.tif 000111
2004537089.tif 000112
2004537089.tif 000113
2004537089.tif 000114
2004537089.tif 000115
2004537089.tif 000116
2004537089.tif 000117
2004537089.tif 000118
2004537089.tif 000119
2004537089.tif 000120
2004537089.tif 000121
2004537089.tif 000122
2004537089.tif 000123
2004537089.tif 000124
2004537089.tif 000125
2004537089.tif 000126
2004537089.tif 000127
2004537089.tif 000128
2004537089.tif 000129
2004537089.tif 000130
2004537089.tif 000131
2004537089.tif 000132
2004537089.tif 000133
2004537089.tif 000134
2004537089.tif 000135
2004537089.tif 000136
2004537089.tif 000137
2004537089.tif 000138
2004537089.tif 000139
2004537089.tif 000140
2004537089.tif 000141
2004537089.tif 000142
2004537089.tif 000143
2004537089.tif 000144
2004537089.tif 000145
2004537089.tif 000146
2004537089.tif 000147
2004537089.tif 000148
2004537089.tif 000149
2004537089.tif 000150
2004537089.tif 000151
2004537089.tif 000152
2004537089.tif 000153
2004537089.tif 000154
2004537089.tif 000155
2004537089.tif 000156
2004537089.tif 000157
2004537089.tif 000158
2004537089.tif 000159
2004537089.tif 000160
2004537089.tif 000161
2004537089.tif 000162
2004537089.tif 000163
2004537089.tif 000164
2004537089.tif 000165
2004537089.tif 000166
2004537089.tif 000167
2004537089.tif 000168
2004537089.tif 000169
2004537089.tif 000170
2004537089.tif 000171
2004537089.tif 000172
2004537089.tif 000173
2004537089.tif 000174
2004537089.tif 000175
2004537089.tif 000176
2004537089.tif 000177
2004537089.tif 000178
2004537089.tif 000179
【国際公開パンフレット（コレクトバージョン）】
2004537089.tif 000180
2004537089.tif 000181
【国際調査報告】
2004537089.tif 000182
2004537089.tif 000183
2004537089.tif 000184