(57)【要約】【課題】  取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供する。【解決手段】  本発明に係るコンテンツデータ記録媒体は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録されており、少なくともコンテンツデータ記録媒体上におけるコンテンツデータの位置及びサイズを示すリンク情報と、コンテンツデータの内容を記述し、個別ファイルの検索に用いられるメタデータと、リンク情報とメタデータとを含む管理ファイルとを有し、管理ファイルを用いて、コンテンツデータ記録媒体にアクセスするアクセス装置にコンテンツデータを検索させる。【選択図】  図５
2008176796.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体に記録されたコンテンツデータにアクセスするアクセス手段を備える記録装置であって、
前記記録媒体は、コンテンツデータを含むコンテンツファイル群と、前記コンテンツデータの管理情報であるトラックリンクを含むトラックリンクファイルを有し、
前記コンテンツファイル群は、コンテンツデータを記録するコンテンツファイルと、前記コンテンツデータの付加情報である第１のメタデータを記録するメタデータファイルを含み、
前記トラックリンクは、固定長のデータ構造を有し、かつ、前記コンテンツファイルへのリンク情報と、前記第１のメタデータの一部を固定長のデータフォーマットに変換した第２のメタデータを含むように構成されており、
前記アクセス手段は、前記トラックリンクのリンク情報を参照することで、前記コンテンツデータにアクセスする、
ことを特徴とする記録装置。
【請求項２】
前記記録装置は、前記コンテンツデータの再生順序に関するプレイリストを作成するリスト作成手段をさらに備え、
前記リスト作成手段は、前記第２のメタデータに基づき、前記第１のメタデータに含まれる所定フィールド要素を基準として、前記プレイリストのソートを実行する、
ことを特徴とする請求項１に記載の記録装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンテンツデータのそれぞれが、個別ファイルとして記録される場合におけるコンテンツデータ記録装置に関する。
【背景技術】
【０００２】
従来、ＣＤ−ＲやＤＶＤなど、取り外し可能（リムーバブル）な記録媒体（以下、“リムーバブル記録媒体”と適宜省略する）にオーディオデータなどのコンテンツデータを記録するためのフォーマットとして、ＵＤＦ（Universal Disk Format）が広く用いられて
いる。
【０００３】
また、ＵＤＦを拡張して、リムーバブル記録媒体に記録されるコンテンツデータの知的財産権（例えば、著作権）を保護するためのアクセス制御など、セキュリティの確保に関する機能を提供するセキュアＵＤＦの規格も策定されている（非特許文献１参照）。
【非特許文献１】“セキュアＵＤＦ規格１．００版（Secure UDF Specification Revision 1．00）”、［ｏｎｌｉｎｅ］、２００２年２月２６日、オスタ（ＯＳＴＡ）、全文、［平成１６年１１月２６日検索］、インターネット＜URL：http://www.osta.org/specs/pdf/SecureUDF_1_00.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、セキュアＵＤＦでは、暗号化など、セキュリティの確保に関する様々な仕様が規定されているが、リムーバブル記録媒体に記録されているコンテンツデータを取り扱う利用者の利便性については、さらに改善の余地があった。
【０００５】
そこで、本発明は、このような状況に鑑みてなされたものであり、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、記録媒体に記録されたコンテンツデータにアクセスするアクセス手段を備える記録装置であって、前記記録媒体は、コンテンツデータを含むコンテンツファイル群と、前記コンテンツデータの管理情報であるトラックリンクを含むトラックリンクファイルを有し、前記コンテンツファイル群は、コンテンツデータを記録するコンテンツファイルと、前記コンテンツデータの付加情報である第１のメタデータを記録するメタデータファイルを含み、前記トラックリンクは、固定長のデータ構造を有し、かつ、前記コンテンツファイルへのリンク情報と、前記第１のメタデータの一部を固定長のデータフォーマットに変換した第２のメタデータを含むように構成されており、前記アクセス手段は、前記トラックリンクのリンク情報を参照することで、前記コンテンツデータにアクセスすることを要旨とする。
【０００７】
本発明の第２の特徴は、本発明の第１の特徴に係り、前記記録装置は、前記コンテンツデータの再生順序に関するプレイリストを作成するリスト作成手段をさらに備え、前記リスト作成手段は、前記第２のメタデータに基づき、前記第１のメタデータに含まれる所定フィールド要素を基準として、前記プレイリストのソートを実行することを要旨とする。
【０００８】
かかる特徴によれば、コンテンツデータ（例えば、音楽コンテンツなどのオーディオデータ）を利用するユーザは、リンク情報及びメタデータ（例えば、音楽コンテンツのタイトルやアーティスト名）とを含む管理ファイルを用いるため、コンテンツデータの検索、再生がさらに容易かつ速やかに行え、コンテンツデータの取扱いに係る利便性を向上させることができる。
【発明の効果】
【０００９】
本発明の特徴によれば、取り外し可能（リムーバブル）な記録媒体に記録されたオーディオデータなどのコンテンツデータの取扱いに係る利便性を向上させることができるコンテンツデータ構造、コンテンツデータ記録媒体及びコンテンツデータ記録装置を提供することができる。
【発明を実施するための最良の形態】
【００１０】
次に、本発明の実施形態の一例について、図面を参照しながら説明する。なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。
【００１１】
（本実施形態に係るコンテンツデータ構造）
まず、本実施形態に係るコンテンツデータ構造、具体的には、ハードディスクや、書き換え可能な光ディスク、メモリカードなどのリムーバブル記録媒体に音楽コンテンツ（オーディオデータ）を蓄積する場合に用いられるファイルフォーマットの概要、ディレクトリ構成、及び各ファイル構成について説明する。
【００１２】
（１）  ファイルフォーマットの概要
図１は、本実施形態に係るファイルフォーマット（オーディオフォーマット）の概要を示している。“記録済音楽コンテンツ”（Recorded Music Contents、以下、ＭＣと省略する）は、リムーバブル記録媒体に蓄積される音楽コンテンツの実体である。
【００１３】
（１．１）記録済音楽コンテンツ（Recorded Music Contents）
ＭＣ３０１，３０２は、ＣＤをリッピングしたり、通信ネットワークを介して配信されたりしたコンテンツである。
【００１４】
ＭＣ３０１，３０２は、音楽でいうところの１曲で構成される場合、及び複数曲で構成される場合がある。いわゆる“音楽アルバム”という単位は、１つのＭＣで表現することも可能である。なお、“トラック”は、音楽１曲分で構成され、“音楽アルバム”は、複数の曲によって構成される。
【００１５】
また、ＭＣ３０１，３０２は、音楽コンテンツのみではなく、当該音楽コンテンツのメタデータ（曲のタイトルやアーティスト名など）を含む。
【００１６】
さらに、音楽コンテンツが暗号化されている場合には、ＭＣ３０１，３０２は、暗号化された当該音楽コンテンツを復号するための復号鍵や、当該音楽コンテンツの利用条件などが記載されたライセンスファイルとの関連性を示す情報を有する。なお、ＭＣ３０１，３０２に含まれる音楽コンテンツ（オーディオデータ）は、圧縮された状態でリムーバブル記録媒体に記録することも、もちろん可能である。
【００１７】
（１．２）トラックリンク（Track Link）
“トラックリンク”（Track Link、以下ＴＬと省略する）は、ＭＣの中の１曲へのリンク情報（トラックリンク情報）である。ＴＬ２０１〜２０Ｎ＋１によって、音楽コンテンツへの１曲単位のアクセスが可能となる。また、ＴＬ２０１〜２０Ｎ＋１は、ＭＣ３０１，３０２へのトラックリンク情報以外に、ＴＬのＩＤ、ユーザの検索・提示用のメタデータ、最後に再生された音楽コンテンツの位置を記録するリジューム情報、及び後述する“トラックグループ”からのリンク数を記録するリンクカウント情報などを有する。
【００１８】
（１．３）トラックグループ（Track Group）
“トラックグループ”（Track Group、以下ＴＧと省略する）は、ＴＬの集合体（ＴＬのリストで表現される）、またはＴＧの集合体（ＴＧのリストで表現される）である。
【００１９】
ＴＬの集合体によって表現されるＴＧ１０は、当該リストの順序に意味がある場合と、意味がない場合とに区別される。例えば、“音楽アルバム”や、ユーザが気に入った曲を集めた“プレイリスト”などは、リストの順序に意味がある。なお、“プレイリスト”は、ユーザが自由に作成可能であり、複数の曲のリストによって構成される。
【００２０】
一方、ＴＧ１０が、リムーバブル記録媒体に記録された全曲を管理する“基本トラックセット”である場合、リストの順序に意味がない。また、ＴＧの集合体で表現されるＴＧは、リストの順序に意味がない。当該ＴＧの使用例としては、プレイリストを集めたトッププレイリストなどがある。
【００２１】
ＴＧには、グループリストや、ＴＧのＩＤが記録される。また、リストの順序に意味がある場合、リジューム情報などが記録される。
【００２２】
（２）ディレクトリ・ファイル構成
図２は、本実施形態において用いられるディレクトリ及びファイルの構成（ファイルシステム）を示している。なお、本実施形態では、ファイルシステムとして、セキュアＵＤＦが使用される。
【００２３】
ＡＵＲ＿ＲＯＯＴディレクトリ１１０は、ＲＯＯＴディレクトリ１００の配下に位置し、音楽コンテンツ（オーディオデータ）をリムーバブル記録媒体に記録するアプリケーションのルートディレクトリ、つまり、オーディオフォーマット用のルートディレクトリである。
【００２４】
ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、リムーバブル記録媒体に記録済みである全ての音楽コンテンツを管理するファイルである。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０では、上述したＴＬやＴＧも管理される。
【００２５】
ＲＴ＿ＡＵＲＳディレクトリ１３０は、音楽コンテンツの実体が記録されているディレクトリである。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０が音楽コンテンツの実体である。“ｘｘｘｘｘｘｘ”には、７桁（００００００００〜９９９９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。
【００２６】
（３）ＡＵＤ＿ＳＥＴ．ＭＧＲの構成
図３は、ＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示している。主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０には、ＵＤＦによって定義されるストリームファイルがいくつか付属している。ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、ユーザインタフェースへのエントリ情報、ＴＬ及びＴＧの管理情報を有する。
【００２７】
ＴｒａｃｋＬｉｎｋｓストリームファイルは、再生可能な状態の全てのトラックリンク情報を管理する。ＴＧ＿００００は、ＴｒａｃｋＬｉｎｋｓストリームファイルに記述されている全トラックを管理しているＴＧであり、リムーバブル記録媒体を使用する装置（例えば、コンテンツデータ記録装置）によってメンテナンスが実行される。
【００２８】
ＰＲＴＬｓストリームファイルは、再生可能な状態にない全てのトラックリンク情報を管理している。ＴＧ＿９９９９は、ＰＲＴＬｓに記述されている全トラックを管理しているＴＧであり、プリセットモデルの場合にのみ存在する。ＴＧ＿ｘｘｘｘは、ユーザあるいは機器が自由に定義できるＴＧである。ｘｘｘｘは、４桁（００００〜９９９９まで）の数字（ＡＳＣＩＩコード）が記述される。なお、プリセットモデルの内容については、後述する。
【００２９】
（３．１）ＡＵＤ＿ＳＥＴ．ＭＧＲファイル
主ファイルであるＡＵＤ＿ＳＥＴ．ＭＧＲ１２０は、表１に示すようなモジュールの列、すなわち、（ｉ）ユーザインタフェースエントリ情報、（ｉｉ）トラックリンク管理情報、及び（ｉｉｉ）トラックグループ管理情報によって構成される。
【００３０】
【表１】
2008176796.tif 000003
【００３１】
（３．１．１）ユーザインタフェースエントリ情報
ユーザインタフェースエントリ情報は、表２に示すようなエントリ構造を有する。
【００３２】
【表２】
2008176796.tif 000004
【００３３】
“Ａｕｄｉｏ Ｆｏｒｍａｔ Ｉｄｅｎｔｉｆｉｅｒ”には、ＡＳＣＩＩコードによって、“ＡＵＤＩＯ”と記述される。“Ｂｏｏｋ Ｖｅｒｓｉｏｎ”には、ブックのバージョンが記述される。バージョン１．０の場合は、“０ｘ１０”と記述する。
【００３４】
“Ｆｌａｇ”は、表３に示すような構造を有する。
【００３５】
【表３】
2008176796.tif 000005
【００３６】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｐｒｅｓｅｔ”（ｂｉｔ０）は、プリセットモデルなどにおいて、ライセンスを購入していない音楽コンテンツが存在する場合には１ｂ、当該音楽コンテンツが存在しない場合には０ｂに設定される。
【００３７】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記述される。Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤは、リジュームポイント（Ｒｅｓｕｍｅ Ｐｏｉｎｔ）に使用される。
【００３８】
“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”は、表４に示すような構造を有する。
【００３９】
【表４】
2008176796.tif 000006
【００４０】
“Ｒｅｓｅｒｖｅｄ”（ｂｉｔ７〜１）は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｒｅｓｕｍｅ”（ｂｉｔ０）は、リジューム機能をサポートしている機器では１ｂ、リジューム機能をサポートしていない機器では０ｂと記述される。
【００４１】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ Ｄａｔｅ”（表２参照）には、最後にアクセスしたＴＧのＩＤが記録された時刻が記述される。“ＴＩＭＥ”フォーマットは、１４バイト分のＡＳＣＩＩコードによって、次のように表現される。すなわち、西暦４桁、月２桁、日２桁、時２桁（２４時間表示）、分２桁、及び秒２桁で表現される。タイマーを有しない機器の場合では、オール０に設定される。
【００４２】
“Ｎｕｍｂｅｒ ｏｆ ＵＩＥ ＴＧｓ”には、ＡＵＤ＿ＳＥＴ．ＭＧＲ１２０の配下に位置するユーザインタフェースのエントリとなる最上位ＴＧのＩＤの総数が記述される。
【００４３】
“ＵＩＥ ＴＧ＿ＩＤ（１） ｆｏｒ Ｂａｓｅ Ｔｒａｃｋ Ｓｅｔ”には、１番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、ＡＳＣＩＩコードで００００が記述される。当該ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿００００に対応している。ＵＩＥ ＴＧ＿ＩＤは、ストリームファイルＴＧ＿ｘｘｘｘのうち、ｘｘｘｘに対応する。ＴＧ＿００００は、全トラックを管理するＴＧとして必ず存在する。
【００４４】
“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（１）の名前が記述される。すなわち、対応するＴＧ構造体のＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅがコピーされる。具体的には、ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”には、ＴｒａｃｋＳｅｔＢａｓｅと記述される。
【００４５】
“ＵＩＥ ＴＧ＿ＩＤ（２）”には、２番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。
【００４６】
“ＵＩＥ ＴＧ＿ＩＤ（２） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（２）の名前が記述される。
【００４７】
“ＵＩＥ ＴＧ＿ＩＤ（ｎ）”には、ｎ番目のＵＩＥ ＴＧ＿ＩＤが記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。４桁の数字は、ストリームファイルＴＧ＿ｘｘｘｘに対応している。また、“ＵＩＥ ＴＧ＿ＩＤ（ｎ） Ｎａｍｅ”には、“ＵＩＥ ＴＧ＿ＩＤ（１） Ｎａｍｅ”と同様に、ＡＳＣＩＩコードでＵＩＥ ＴＧ＿ＩＤ（ｎ）の名前が記述される。
【００４８】
（３．１．２）トラックリンク管理情報
トラックリンク管理情報は、表５に示すようなエントリ構造を有する。
【００４９】
【表５】
2008176796.tif 000007
【００５０】
“Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＴＬが記録されるファイル名（ＴｒａｃｋＬｉｎｋｓ）が、ＡＳＣＩＩコードで記述される。
【００５１】
“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、リムーバ
ブル記録媒体の購入時から記録されているＴＬが記録されるファイル名が、ＡＳＣＩＩコードで記述される。“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、プリセットモデルにおいて使用される。プリセットモデルの場合、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”には、ＰＲＴＬｓと記述される。プリセットモデル以外では、“Ｐｒｅｒｅｃｏｒｄｅｄ Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ”は、無視される。
【００５２】
（３．１．３）トラックグループ管理情報
トラックグループ管理情報は、表６に示すようなエントリ構造を有する。
【００５３】
【表６】
2008176796.tif 000008
【００５４】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ”には、ＴＧの総数が記述される。“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”には、ＴＧ＿ＩＤの最大値が記述される。具体的には、４桁の数字がＡＳＣＩＩコードで記述される。ただし、“９９９９”は、プリセットモデル用として割り当てられるため、当該最大値として考慮しない。
【００５５】
（３．２）ＴｒａｃｋＬｉｎｋｓストリームファイル・ＰＲＴＬｓストリームファイル
ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルは、表７に示すような構造を有する。
【００５６】
【表７】
2008176796.tif 000009
【００５７】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイルまたはＰＲＴＬｓストリームファイルに含まれているＴＬの総数が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ”には、ＴｒａｃｋＬｉｎｋｓストリームファイル及びＰＲＴＬｓストリームファイルに含まれているＴＬの中で有効なＴＬ数が記述される。
【００５８】
“Ｔｒａｃｋ Ｌｉｎｋ Ｉｎｆｏｒｍａｔｉｏｎ（１）〜（ｎ）”は、ＴＬ構造体がｎ個並んだ構造である。ｎは、“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ”フィールドの数値である。ＴＬのＩＤは、表７に示したように、“１”から昇順で割り当てられる。
【００５９】
なお、本実施形態では、ＴｒａｃｋＬｉｎｋｓストリームファイルのＴＬのＩＤは、ＴＬ＿ＩＤと表記され、ＰＲＴＬｓストリームファイルのＴＬのＩＤは、ＰＲＴＬ＿ＩＤと表記される。
【００６０】
（３．２．１）ＴＬ構造体
ＴＬ構造体は、表８に示すような構造を有する。
【００６１】
【表８】
2008176796.tif 000010
【００６２】
“ＴＬ ＴＹＰＥ”には、ＴＬ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表９参照）が記述される。なお、本実施形態では、日本方式（ＴＹＰＥ１）が定義されている。
【００６３】
【表９】
2008176796.tif 000011
【００６４】
“Ｌｅｎｇｔｈ ｏｆ Ｓｔｒｕｃｔｕｒｅ”（表８参照）には、ＴＬ構造体の長さ（バイト数）が記述される。
【００６５】
“ＴＬ Ｆｌａｇ”は、表１０に示すような構造を有する。
【００６６】
【表１０】
2008176796.tif 000012
【００６７】
“Ｖ（ｂｉｔ７）”には、ＴＬ構造体が有効であるか否かを示す情報が記述される。具体的には、ＴＬ構造体が有効である場合、“Ｖ（ｂｉｔ７）”は、１ｂに設定される。ＴＬ構造体が無効である場合、“Ｖ（ｂｉｔ７）”は、０ｂに設定される。“Ｖ（ｂｉｔ７）”は、ＴＬ構造体の簡易消去に利用される。
【００６８】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ６〜３）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“ＰＳ（ｂｉｔ２）”では、プリセットモデルに係る曲へのリンクの場合には１ｂ、そうでない場合には０ｂが設定される。
【００６９】
“ＰＥ（ｂｉｔ１）”では、再生可能な曲へのリンクの場合、つまり、その曲のライセンスを有している場合、またはその曲が暗号化されてない場合には１ｂ、再生が不可能な場合、つまり、その曲が暗号化されており、その曲のライセンスを有していない場合には０ｂが設定される。
【００７０】
“Ｐａｒｔ（ｂｉｔ０）”では、ＭＣとして複数曲が記録されている場合であって、その一部を指定する場合には、１ｂに設定される。ＭＣが１曲の場合には、０ｂとに設定される。“Ｐａｒｔ（ｂｉｔ０）”が１ｂのときに限って、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００７１】
“Ｌｉｎｋ Ｃｏｕｎｔ”（表８参照）には、ＴＧからリンクされているリンク総数が記述される。“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”には、Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤが記述される。具体的には、コンテンツファイルのＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのｘｘｘｘｘｘｘに相当する数字がＡＳＣＩＩコードで記述される。
【００７２】
“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”では、音楽コンテンツファイルのリンク開始位置が、当該ファイルの先頭からのバイト位置によって指定される。“Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ”には、音楽コンテンツファイルへのリンク範囲（バイト長）が記述される。上述したように、ＴＬ＿ＦｌａｇのＰａｒｔビット（表１０参照）が１ｂの場合にのみ、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及びＣｏｎｔｅｎｔ Ｌｅｎｇｔｈ”フィールドが有効となる。
【００７３】
“Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ”には、最後に再生された音楽コンテンツファイルへのアクセス時刻が記録される。“Ｒｅｓｕｍｅ Ｐｏｉｎｔ”では、音楽コンテンツファイル（ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル）の再生開始位置が、当該ファイルの先頭からのバイト位置によって指定される。
【００７４】
“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”には、再生開始を指示した回数が記述される。なお、“Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ”フィールドに記述される回数には、リジュームによる再生は含まない。“Ｍｙ Ｒａｔｉｎｇ Ｉｎｆｏ”には、ユーザによって入力される１０段階の重み付け情報が記述される。
【００７５】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”では、メタデータフィールドの文字コード（表１１参照）が定義される。
【００７６】
【表１１】
2008176796.tif 000013
【００７７】
“Ｔｉｔｌｅ（ＭｅｔａＤａｔａ、以下ＭＤ）”（表８参照）には、トラックタイトルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７８】
“Ｔｉｔｌｅカナ（ＭＤ）”には、トラックタイトルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００７９】
“Ａｒｔｉｓｔ Ｎａｍｅ（ＭＤ）”には、アーティスト名が記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８０】
“Ａｒｔｉｓｔ Ｎａｍｅカナ（ＭＤ）”には、アーティスト名の検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８１】
“Ｇｅｎｒｅ（ＭＤ）”には、ジャンルが記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８２】
“Ｇｅｎｒｅカナ（ＭＤ）”には、ジャンルの検索用カナが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８３】
“Ｃｏｍｐｏｓｅｒ（ＭＤ）”には、作曲者名が、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８４】
“Ａｌｂｕｍ Ｔｉｔｌｅ（ＭＤ）”には、音楽アルバム（ＣＤ）のタイトルが、全角カタカナによって記述される。文字コードは、“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｏｆ Ｍｅｔａｄａｔａ”フィールドにおいて指定されたものが使用される。トラックタイトルの終端は、ＮＵＬＬ文字を格納することによって行われる。
【００８５】
“Ｔｒａｃｋ Ｎｕｍｂｅｒ ｉｎ ＣＤ（ＭＤ）”では、音楽アルバムの場合におけるトラック番号が記述される。
【００８６】
（３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、表１２に示すような構造を有する。
【００８７】
【表１２】
2008176796.tif 000014
【００８８】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表１３参照）が記述される。
【００８９】
【表１３】
2008176796.tif 000015
【００９０】
“ＴＧ Ｆｌａｇ”は、表１４に示すような構造を有する。
【００９１】
【表１４】
2008176796.tif 000016
【００９２】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。なお、このビットは、文字コードの識別情報用として使用される予定である。
【００９３】
“ＴＬ/ＴＧ（ｂｉｔ１）”では、ＴＬのリストの場合には１ｂ、ＴＧのリストの場合には０ｂに設定される。“Ｓ/Ｇ（ｂｉｔ０）”では、リストの順序が再生順である場合には１ｂ、再生順でない場合には０ｂに設定される。
【００９４】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ”（表１２参照）には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体の名前が、ＡＳＣＩＩコードで記述される。“Ｌｉｎｋ Ｃｏｕｎｔ”には、ＴＧからリンクされているリンク総数が記述される。なお、ユーザインタフェースエントリ情報から参照されている場合も、リンク数１としてカウントされる。
【００９５】
“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”には、リジュームのエレメントの番号が記述される。当該番号は、ｅｌｅｍｅｎｔ ＩＤ（ｘ）のｘに相当する番号である。“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”は、ＴＧ＿ＦｌａｇのＳ／Ｇビットが１の場合にのみ有効となる。
【００９６】
“ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ Ｓｐｅｃｉｆｉｃ Ａｒｅａ”は、ＴＧ Ｓｐｅｃｉｆｉｃな構造体に依存した構造を定義するための領域である。“Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ”には、ＴＧに属するｅｌｅｍｅｎｔの総数が記述される。“ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）”には、各ｅｌｅｍｅｎｔ ＩＤが記述される。
【００９７】
“ｅｌｅｍｅｎｔ ＩＤ（１） Ｎａｍｅ〜ｅｌｅｍｅｎｔ ＩＤ（ｎ） Ｎａｍｅ”には、ｅｌｅｍｅｎｔ ＩＤの名前が記述される。
【００９８】
（３．３．１）ＴＧ＿００００ストリームファイル
ＴＧ＿００００ストリームファイルは、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【００９９】
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・  ＴＧ Ｆｌａｇ ＝ ０ｘ２
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｔｒａｃｋ＿Ｂａｓ
ｅ
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ：  ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されている有効なＴＬ数と一致する
・  ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）：  ＴＬ＿ＩＤが記述される
（３．３．２）ＴＧ＿９９９９ストリームファイル
ＴＧ＿９９９９ストリームファイルは、プリセットモデルの場合にのみ、初期状態において存在し、ＰＲＴＬｓストリームファイルによって管理されているＴＬを管理するＴＧである。上述したＴＧ＿ｘｘｘｘ構造体（ＴＧ＿ｘｘｘｘストリームファイル）で定義されるが、次のような制約がある。
【０１００】
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘＦＦ
・  ＴＧ Ｆｌａｇ ＝ ０ｘ２
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ Ｎａｍｅ ＝ Ｐｒｅｓｅｔ＿Ｔｒ
ａｃｋ＿Ｂａｓｅ
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ：  ＰＲＴＬｓストリームファイルによって管理されている有効なＴＬ数と一致する
・  ｅｌｅｍｅｎｔ ＩＤ（１）〜（ｎ）：  ＰＲＴＬ＿ＩＤが記述される
（３．３．３）ＴＧ＿ｘｘｘｘストリームファイル
ＴＧ＿ｘｘｘｘストリームファイルは、ＴＬのリストまたはＴＧのリストによって表現される。ＴＬのリストで表現される場合は、ｅｌｅｍｅｎｔ＿ＩＤには、ＴｒａｃｋＬｉｎｋｓストリームファイルによって管理されているＴＬ＿ＩＤが記述されなければならない。なお、ＰＲＴＬｓストリームファイルのＰＲＴＬ＿ＩＤは、参照することができない。
【０１０１】
（４）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成
図４は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示している。同図に示すように、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、ＡｕｄｉｏＤａｔａストリームファイル（ＡｕｄｉｏＤａｔａ）、ＭｅｔａＤａｔａストリームファイル（ＭｅｔａＤａｔａ）、及び*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル（*ＵＤＦ＿ＬＩＣＥＮＣＥ）によって構成されている。
【０１０２】
（４．１）ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
主ファイルであるＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０は、表１５に示すようなモジュールの列、すなわち、（ｉ）オーディデータ管理情報、（ｉｉ）メタデータ管理情報、及び（ｉｉｉ）ライセンス管理情報によって構成される。
【０１０３】
【表１５】
2008176796.tif 000017
【０１０４】
（４．１．１）オーディデータ管理情報
オーディデータ管理情報は、表１６に示すようなエントリ構造を有する。
【０１０５】
【表１６】
2008176796.tif 000018
【０１０６】
“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”には、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。
【０１０７】
“ＡＵＤ Ｆｌａｇ”は、表１７に示すような構造を有する。
【０１０８】
【表１７】
2008176796.tif 000019
【０１０９】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜１）”は、将来のためにリザーブされているビットであり、０ｂに設定される。“Ｅｎｃ（ｂｉｔ０）”には、ＡｕｄｉｏＤａｔａストリームファイルのＴｒａｃｋ Ｄａｔａ部分が暗号化されている場合には１ｂ、暗号化されてい
ない場合には０ｂに設定される。
【０１１０】
“Ｐｌａｙｂａｃｋ Ｔｉｍｅ”（表１６参照）には、全トラックの再生時間が記述される。“Ｆｉｌｅ Ｓｉｚｅ”には、ＡｕｄｉｏＤａｔａストリームファイルのファイルサイズが記述される。“Ａｕｄｉｏ Ｆｏｒｍａｔ（Ｃｏｄｅｃ）”には、Ａｕｄｉｏ Ｆｏｒｍａｔ（表１８参照）が記述される。
【０１１１】
【表１８】
2008176796.tif 000020
【０１１２】
“Ｂｉｔ Ｒａｔｅ”（表１６参照）には、ビットレート（単位：ｋｂｐｓ）が記述される。“Ｆｉｌｅ Ｃｒｅａｔｅ Ｄａｔｅ”には、ファイル作成日が記述される。“Ａｕｄｉｏ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”には、オーディオデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＡｕｄｉｏＤａｔａと記述）される。
【０１１３】
（４．１．２）メタデータ管理情報
メタデータ管理情報は、表１９に示すような構造を有する。
【０１１４】
【表１９】
2008176796.tif 000021
【０１１５】
“Ｃｈａｒａｃｔｅｒ Ｓｅｔ ｉｎ Ｍｅｔａｄａｔａ Ｆｉｌｅ”では、ＭｅｔａＤａｔａストリームファイルの文字コード（表２０参照）が定義される。
【０１１６】
【表２０】
2008176796.tif 000022
【０１１７】
“ＭｅｔａＤａｔａ Ｆｏｒｍａｔ”には、ＴＧ Ｓｐｅｃｉｆｉｃな構造体のＴＹＰＥ（表２１参照）が記述される。
【０１１８】
【表２１】
2008176796.tif 000023
【０１１９】
“ＭｅｔａＤａｔａ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表１９参照）には、メタデータが記録されるファイル名が、ＡＳＣＩＩコードで記述（ＭｅｔａＤａｔａと記述）される。
【０１２０】
（４．１．３）ライセンス管理情報
ライセンス管理情報は、表２２に示すような構造を有する。
【０１２１】
【表２２】
2008176796.tif 000024
【０１２２】
“Ｌｉｃｅｎｓｅ Ｆｌａｇ”は、表２３に示すような構造を有する。
【０１２３】
【表２３】
2008176796.tif 000025
【０１２４】
“Ｒｅｓｅｒｖｅｄ（ｂｉｔ７〜２）”は、将来のためにリザーブされているビットであり、０ｂに設定される。
【０１２５】
“ＰＳ（ｂｉｔ１）”では、プリセットモデルの場合には１ｂ、そうでない場合には０ｂが設定される。“ＬＥ（ｂｉｔ０）”では、ライセンスが存在する場合には１ｂ、存在しない場合には０ｂに設定される。
【０１２６】
“Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ”（表２２参照）には、ライセンス（復号鍵及び利用条件）が記録されるファイル名がＡＳＣＩＩコードで記述される。具体的には、Ｌｉｃｅｎｓｅ ＦｌａｇのＬＥビットが１ｂの場合のみ、*ＵＤＦ＿ＬＩＣＥＮＳＥと記述される。
【０１２７】
（４．２）ＡｕｄｉｏＤａｔａストリームファイル
ＡｕｄｉｏＤａｔａストリームファイルは、表２４に示すようなモジュールの列、すなわち、（ｉ）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ及び（ｉｉ）Ｔｒａｃｋ Ｄａｔａによって構成される。
【０１２８】
【表２４】
2008176796.tif 000026
【０１２９】
（４．２．１）Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ
Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、表２５に示すようなエントリ構造を有する。なお、Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒは、暗号化の対象とならない。
【０１３０】
【表２５】
2008176796.tif 000027
【０１３１】
“Ｌｅｎｇｔｈ ｏｆ Ａｕｄｉｏ Ｄａｔａ Ｈｅａｄｅｒ”には、Ａｕｄｉｏ Ｄａｔ
ａ Ｈｅａｄｅｒ長（バイト数）が記述される。“Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ”に
は、ＡｕｄｉｏＤａｔａストリームファイルに記録されているトラック数が記述される。“Ｌｅｎｇｔｈ ｏｆ Ｔｒａｃｋ Ｄａｔａ（＃１）〜（＃ｎ）には、Ｔｒａｃｋ Ｄａｔａ長（バイト数）が記述される。
【０１３２】
（４．２．２）Ｔｒａｃｋ Ｄａｔａ
Ｔｒａｃｋ Ｄａｔａには、Ａｕｄｉｏ Ｆｏｒｍａｔに準じたデータが記録される。なお、Ｔｒａｃｋ Ｄａｔａは、暗号化されている場合もある。
【０１３３】
（４．３）ＭｅｔａＤａｔａストリームファイル
ＭｅｔａＤａｔａストリームファイルは、表２６に示すような構造を有する。
【０１３４】
【表２６】
2008176796.tif 000028
【０１３５】
（４．４）*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル
*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルには、ライセンス（復号鍵及び
利用条件）が記述されている。アプリケーションは、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュア
ストリームファイルが存在すれば、暗号化されたＡｕｄｉｏＤａｔａストリームファイルを復号できる。
【０１３６】
（音楽コンテンツ管理モデル構成例）
次に、上述した本実施形態に係るコンテンツデータ構造を用いた音楽コンテンツの管理モデル構成例について説明する。
【０１３７】
（１）構成例１
図５は、“Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）”を用いたモデル構成例を示している。
【０１３８】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、視聴可能状態で記録されたトラックの全リストを管理しているＴＧである。なお、音楽コンテンツ（ＭＣ３０１，３０２）が暗号化されている場合には、復号するためのライセンスが必要となる。
【０１３９】
Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿００００ストリームファイルとして存在する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴｒａｃｋＬｉｎｋｓストリームファイルとして管理されている全てのＴＬ（ＴＬ２０１〜２０Ｎ＋１）を管理する。
【０１４０】
（２）構成例２
図６は、Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）を用いたモデル構成例を示しているＰｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＰＴＢ）は、“プリセットモデル”の場合にのみ存在するファイル（ＴＧ）である。
【０１４１】
プリセットモデルとは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）をリムーバブル記録媒体に記録した状態でユーザに販売し、ユーザは、表示されるリストの中から気に入ったトラックを購入するというビジネスモデルである。
【０１４２】
プリセットモデルでは、ユーザは、気に入ったトラックの購入時に暗号化された音楽コンテンツ（ＭＣ３０３，３０４）を復号するためのライセンスのみを取得すれば良い。このため、ユーザは、気に入ったトラック（音楽コンテンツ）をサーバなどからダウンロードする必要がなく、速やかに音楽コンテンツを購入できる。
【０１４３】
また、プリセットモデルでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、視聴可能な音楽コンテンツと同様にＲＴ＿ＡＵＲＳディレクトリ１３０の配下に位置するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル１４０（図２参照）に記録される。ただし、当初は、ライセンス（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）がない状態であるため、そのままでは、暗号化された音楽コンテンツ（ＭＣ３０３，３０４）は、再生することができない。
【０１４４】
ＴＬ２１１〜２１Ｎ＋１は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＰＲＴＬｓストリームファイルとして管理され、視聴可能な音楽コンテンツを管理しているＴｒａｃｋＬｉｎｋｓストリームファイルとは別に管理される。
【０１４５】
さらに、プリセットモデルでは、視聴が不可能な状態で記録された、つまり、復号するためのライセンスを有していないトラックの全リストを管理しているＴＧが、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下において、ＴＧ＿９９９９ストリームファイルとして存在する。
【０１４６】
ＴＧ＿９９９９ストリームファイルは、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの配下に位置するＰＲＴＬｓストリームファイルとして管理されている全てのＴＬを管理する。ＰＲＴＬｓストリームファイルとして管理されているＴＬは、ユーザが定義するＴＧからリンクすることができないという制限を有する。
【０１４７】
ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合、当該ＭＣに対応するＴＬは、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される。
【０１４８】
図７及び図８は、ユーザが、暗号化された音楽コンテンツのライセンスを取得（購入）した場合に、当該ＭＣに対応するＴＬが、ＰＲＴＬｓストリームファイルから削除され、ＴｒａｃｋＬｉｎｋｓストリームファイルに追加される様子を示している。
【０１４９】
図７は、ライセンス（復号鍵及び利用条件）の取得前における音楽コンテンツの管理状態を示している。図７に示すように、ＭＣ３０３，３０４については、ライセンスが取得済み（図において、“Ｌｉｃｅｎｃｅ”と表記されている）である。一方、ＭＣ３０１，３０２，３０Ｍについては、ライセンスがまだ取得されていない状態である。
【０１５０】
ここで、ユーザは、ＭＣ３０２のライセンスを新たに取得したものとする。図８は、ＭＣ３０２のライセンスが取得された後における音楽コンテンツの管理状態を示している。図８に示すように、ＰＲＴＬｓストリームファイルから、ＭＣ３０２に対応するＴＬ２１２が削除されている。
【０１５１】
一方、ＴｒａｃｋＬｉｎｋｓストリームファイルには、ＭＣ３０２に対応するＴＬとして、ＴＬ２０３（ＴＬ＿ＩＤ＃３）が追加されている。
【０１５２】
（３）構成例３
図９は、音楽コンテンツ（オーディオデータ）管理モデルの基本的な構成例を示している。図９に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルに含まれるユーザインタフェースエントリ情報（表２参照）に、最初にアクセスするべきＵＩＥ ＴＧ＿ＩＤのリストが存在する。
【０１５３】
図９に示した構成例では、２つのリストが存在する。１つは、ＴＧ＿ＩＤが００００であるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）であり、視聴可能な全てのＴＬを管理する。Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、必ず存在し、コンテンツデータ記録装置は、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）の内容をメンテナンスする必要がある。
【０１５４】
もう１つは、ＴＧ＿ＩＤが０００１であり、プレイリストのエントリとなるＰｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）である。Ｐｌａｙ Ｌｉｓｔ Ｔｏｐ（１０ＰＬＴ）は、ＴＧのリストとして表現される。図９に示した構成例では、３つのプレイリストを管理している。
【０１５５】
Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）は、ＴＧ＿ＩＤ０００２，０００３，０００４にそれぞれ対応している。ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）を新規に作成したり、消去したりすることができる。また、ユーザは、Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３）の内容を編集することができる。それぞれのプレイリストは、ＴＬ（ＴＬ２０１〜２０Ｎ）のリストで表現されている。
【０１５６】
（４）構成例４
図１０は、音楽アルバムを管理する場合における構成例を示している。図９に示したプレイリスト（Ｐｌａｙ Ｌｉｓｔ＃１，＃２，＃３（ＴＧ１０ＰＬ１，１０ＰＬ２，１０ＰＬ３））との違いは、ＣＤをリッピングする際にコンテンツデータ記録装置が、関連するフォルダ及びファイル（Ａｌｂｕｍ Ｔｏｐ（ＴＧ１０ＡＴ），Ａｒｔｉｓｔ Ａ（ＴＧ１０Ａ），Ａｒｔｉｓｔ Ｂ（ＴＧ１０Ｂ），Ａｌｂｕｍ＃１，＃２，＃３（ＴＧ１０Ａ１，ＴＧ１０Ａ２，ＴＧ１０Ａ３）を生成し、当該フォルダ及びファイルは、ユーザからの編集が不可となることである。
【０１５７】
また、本構成例では、Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）は、音楽アルバムの情報については管理しない。
【実施例】
【０１５８】
次に、上述したコンテンツデータ構造を用いた実施例について、図面を参照しながら説明する。
【０１５９】
（コンテンツデータ記録装置の構成）
図１１は、本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の構成を示している。
【０１６０】
図１１に示すように、音楽レコーダ１０００は、ＣＤ１１０１をドライブするＣＤドライブ１１０２を有している。
【０１６１】
ＡＡＣエンコーダ１１０４は、ＣＤドライブ１１０２によって読み込まれた音楽コンテンツ（オーディオデータ）のデータ量を圧縮するものである。具体的には、ＡＡＣエンコーダ１１０４は、ＭＰＥＧ−４ ＡＡＣ（ＩＳＯ／ＩＥＣ１４４９６−３）に基づいて、オーディオデータを圧縮する。
【０１６２】
暗号化処理部１１０６は、ＡＡＣエンコーダ１１０４によって圧縮されたオーディオデータを暗号化するものである。また、復号化処理部１１０８は、暗号化されたオーディオデータを復号化するものである。
【０１６３】
ＡＡＣデコーダ１１１０は、復号化処理部１１０８によって出力され、ＭＰＥＧ−４ ＡＡＣに基づいて圧縮されているオーディオデータを復号（伸長）するものである、Ｄ／Ａ変換部１１１２は、ＡＡＣデコーダ１１１０によって出力されたオーディオデータを、アナログ信号に変換するものである。Ｄ／Ａ変換部１１１２によって出力されたアナログ信号は、スピーカ１１１４を駆動する。
【０１６４】
制御部１１１６は、ＭＰＵなどによって構成されており、制御部１１１６と接続されている各部を制御するものである。また、制御部１１１６は、タイマーを内蔵しており、日付や時刻の情報を取得することができる。
【０１６５】
制御部１１１６は、リムーバブルＨＤＤ１１２６上におけるＭＣの位置及びサイズなどを示すトラックリンク情報（リンク情報）を生成するものであり、本実施形態では、リンク情報生成部を構成する。
【０１６６】
また、制御部１１１６は、ＭＣの内容（例えば、タイトルやアーティスト名）を記述し、ＭＣ（個別ファイル）の検索に用いられるメタデータを取得するものであり、本実施形態では、モデム１１２８とともに、メタデータ取得部を構成する。
【０１６７】
さらに、制御部１１１６は、トラックリンク情報とメタデータとを含むＡＵＤ＿ＳＥＴ．ＭＧＲファイル（管理ファイル）を生成するものであり、本実施形態では、管理ファイル生成部を構成する。
【０１６８】
また、制御部１１１６は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いて、ＭＣを検索するものであり、本実施形態では、コンテンツ検索部を構成する。なお、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルには、上述したように、ＭＣの再生を許可するライセンス管理情報（*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイル）が含まれている。制御部１１１６は、当該ライセンス管理情報に基づいて、ＭＣを再生するものであり、本実施形態では、復号化処理部１１０８とともに、コンテンツ再生部を構成する。
【０１６９】
表示部１１１８は、制御部１１１６によって出力された情報、例えば、音楽コンテンツのトラック数、トラック番号、及びタイトルやアーティスト名などのメタデータを表示するものである。リモコン受光部１１２０は、リモコン１１２２から送信された赤外線光を受光するものである。
【０１７０】
ＡＴＡインタフェース１１２４は、制御部１１１６とリムーバブルＨＤＤ１１２６とを通信可能に接続するためのインタフェース（At Attachment）である。
【０１７１】
リムーバブルＨＤＤ１１２６は、音楽レコーダ１０００からの取り外しが可能なリムーバブル記録媒体である。リムーバブルＨＤＤ１１２６は、ＣＤ１１０１からリッピングされたオーディオデータを記録し、上述したコンテンツデータ構造によって当該オーディオデータが管理される。
【０１７２】
リムーバブルＨＤＤ１１２６には、上述したように、複数の音楽コンテンツ（ＭＣ３０１，３０２など）のそれぞれが、個別ファイルとして記録される。
【０１７３】
モデム１１２８は、音楽レコーダ１０００（制御部１１１６）と、コンテンツサーバ１１３２及びメタデータサーバ１１３４とを、インターネット網１１３０を介して通信可能に接続するための通信デバイスである。
【０１７４】
なお、音楽レコーダ１０００は、インターネット網１１３０との接続に用いられる通信回線の方式に基づいて、モデム１１２８以外の通信デバイス、例えば、メディアコンバータなどを実装することもできる。
【０１７５】
（コンテンツデータ記録装置の動作）
次に、上述した本実施例に係る音楽レコーダ１０００（コンテンツデータ記録装置）の動作について説明する。
【０１７６】
（１）リムーバルＨＤＤの初期化
図１２は、音楽レコーダ１０００に接続されるリムーバブルＨＤＤ１１２６の初期化処理フローを示している。
【０１７７】
図１２に示すように、ステップＳ１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリを作成する。
【０１７８】
ステップＳ２０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを作成する。具体的には、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルを構成するフィールドは、以下のように設定される。
【０１７９】
・  Ｆｌａｇ ＝ ０
・  Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ １
・  ＵＩＥ ＴＧ ＩＤ（１） ＝ ００００（ＡＳＣＩＩ）
・  Ｔｒａｃｋ Ｌｉｎｋ Ｌｏｃａｔｉｏｎ ＝ “．／ＰＲＯＧ＿ＳＥＴ．ＭＧＲ＃ＴｒａｃｋＬｉｎｋｓ”
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ １
・  Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ００００
ステップＳ３０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルを作成する。具体的には、ＴｒａｃｋＬｉｎｋｓストリームファイルを構成するフィールドは、以下のように設定される。
【０１８０】
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ０
ステップＳ４０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルを作成する。具体的には、ＴＧ＿００００ストリームファイルを構成するフィールドは、以下のように設定される。
【０１８１】
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ００
・  ＴＧ Ｆｌａｇ ＝ ０ｘ０２
・  ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ “Ｔｒａｃｋ Ｂａｓｅ”
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ５０において、音楽レコーダ１０００は、ＲＴ＿ＡＵＲＳディレクトリを作成する。
【０１８２】
（２）ＣＤリッピング（１曲）
図１３は、ＣＤ１１０１（図１１参照）に含まれる音楽コンテンツ（オーディオデータ）から、１曲分のオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１８３】
図１３に示すように、ステップＳ１１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１８４】
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ １
・  ＡＵＤ Ｆｌａｇ
・  Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・  Ｆｉｌｅ Ｓｉｚｅ
・  Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・  Ｂｉｔ ｒａｔｅ
・  Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・  Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・  ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・  Ｌｉｃｅｎｓｅ Ｆｌａｇ
・  Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ１２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１８５】
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・  Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋１
・  ＴＬ構造体追加
・  ＴＬ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ１
・  ＴＬ Ｆｌａｇ
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ １ （ｆｒｏｍ ＴＧ＿００００）
・  Ｍｕｓｉｃ Ｃｏｎｔｅｎｔ ＩＤ ＝ ｘｘｘｘｘｘｘ
・  ＭｅｔａＤａｔａ
・  Ｍｙ Ｒａｔｅ Ｉｎｆｏ
・  Ｌａｓｔ Ａｃｃｅｓｓｅｄ Ｔｉｍｅ
・  Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒ
・  Ｒｅｓｕｍｅ Ｐｏｉｎｔ
ステップＳ１３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１８６】
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・  ｅｌｅｍｅｎｔ ＩＤを追加
（３）ＣＤリッピング（音楽アルバム）
図１４は、ＣＤ１１０１に含まれる音楽コンテンツ（オーディオデータ）から、複数曲によって構成されるオーディオデータをリッピングし、リムーバブルＨＤＤ１１２６に記録するフローを示している。
【０１８７】
図１４に示すように、ステップＳ２１０において、音楽レコーダ１０００は、ＣＤ１１０１に含まれるオーディオデータに基づいて、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを作成する。具体的には、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを構成するフィールドは、以下のように設定される。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容に応じて適切なデータが記述される。
【０１８８】
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋｓ ＝ ｍ（音楽アルバムにｍ曲収容されている）
・  ＡＵＤ Ｆｌａｇ
・  Ｐｌａｙｂａｃｋ Ｔｉｍｅ
・  Ｆｉｌｅ Ｓｉｚｅ
・  Ａｕｄｉｏ Ｆｏｒｍａｔ ＝ （ＡＡＣ）
・  Ｂｉｔ ｒａｔｅ
・  Ｆｉｌｅ Ｃｒｅａｔｅｄ Ｄａｔｅ
・  Ｃｈａｒａｃｔｅｒ Ｓｅｔ （Ｕｎｉｃｏｄｅ）
・  ＭｅｔａＤａｔａＦｉｌｅ Ｆｏｒｍａｔ
・  Ｌｉｃｅｎｓｅ Ｆｌａｇ
・  Ｌｉｃｅｎｓｅ Ｆｉｌｅ Ｌｏｃａｔｉｏｎ
ステップＳ２２０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴｒａｃｋＬｉｎｋｓストリームファイルの内容を更新する。なお、以下に示すフィールドにおいて、具体的な内容がないフィールドについては、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの内容などに応じて適切なデータが記述される。
【０１８９】
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ＋ｍ
・  Ｎｕｍｂｅｒ ｏｆ Ｖａｌｉｄ Ｔｒａｃｋ Ｌｉｎｋｓ ＝ ｎ+ｍ
・  ｍ個のＴＬ構造体追加
ステップＳ２３０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿００００ストリームファイルの内容を更新する。
【０１９０】
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ+ｍ
・  ｅｌｅｍｅｎｔ ＩＤを追加（ｍ個）
ステップＳ２４０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを作成する。具体的には、ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０１９１】
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０１
・  ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・  ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ アルバムタイトル
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｍ
・  ｅｌｅｍｅｎｔ ＩＤ：  ｍ個のＩＤを追加する
・  各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ２５０において、音楽レコーダ１０００は、ステップＳ２４０において作成したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０１９２】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ２５０のＹｅｓ）、ステップＳ２６０において、音楽レコーダ１０００は、当該上位ＴＧについてメンテナンスを実行する。具体的には、以下のようなメンテナンスが実行される。
【０１９３】
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・  ｅｌｅｍｅｎｔ ＩＤ：  追加したＴＧ＿ｘｘｘｘストリームファイルのｘｘｘ
ｘ部分を追加
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ２７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０１９４】
・  Ｆｌａｇ ＝ ０
・  Ｎｕｍ ｏｆ ＵＩＥ ＴＧｓ ＝ ２
・  ＵＩＥ ＴＧ ＩＤ（２） ＝ ｘｘｘｘ（ＡＳＣＩＩ）
・  Ｎｕｍｂｅｒ ｏｆ Ｔｒａｃｋ Ｇｒｏｕｐｓ ＝ ２
・  ＵＩＥ ＴＧ ＩＤ（２） Ｎａｍｅ ＝ アルバムタイトル
・  Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ ＝ ｘｘｘｘ
以上、音楽レコーダ１０００が、ＣＤ１１０１に含まれる音楽コンテンツ（音楽コンテンツ）をリッピングする場合の動作について説明したが、音楽レコーダ１０００は、インターネット網１１３０を介して接続されているコンテンツサーバ１１３２に格納されている音楽コンテンツをダウンロードし、リムーバブルＨＤＤ１１２６に記録することもできる。
【０１９５】
（４）ＣＤＤＢからのメタデータ取得
図１５は、ＣＤＤＢから、音楽コンテンツに関するメタデータを取得するフローを示している。
【０１９６】
図１５に示すように、ステップＳ３１０において、ユーザは、ＣＤ１１０１をＣＤドライブ１１０２（図１１参照）に挿入する。
【０１９７】
ＣＤ１１０１がＣＤドライブ１１０２（図１１参照）に挿入されると、ステップＳ３２０において、音楽レコーダ１０００は、メタデータサーバ１１３４からＣＤ１１０１に対応するメタデータを取得する。
【０１９８】
具体的には、音楽レコーダ１０００は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのメタデータ管理情報を取得し、取得したメタデータ管理情報に基づいて、ＭｅｔａＤａｔａストリームファイルにメタデータを登録する。なお、音楽レコーダ１０００は、必要により、メタデータに用いられる文字コードを変換する。
【０１９９】
ステップＳ３３０において、音楽レコーダ１０００は、対応するＴＬ構造体（表８参照）にメタデータを登録する。音楽レコーダ１０００は、登録対象のメタデータがフィールド長より長い場合、当該フィールドに記述することができない当該メタデータの部分を削除する。
【０２００】
（５）再生（タイトル検索・メタデータ表示）
図１６は、リムーバブルＨＤＤ１１２６に含まれる音楽コンテンツ（オーディオデータ）を再生するフローを示している。
【０２０１】
図１６に示すように、ステップＳ４１０において、音楽レコーダ１０００は、ＡＵＲ＿ＲＯＯＴディレクトリの配下に位置するＡＵＤ＿ＳＥＴ．ＭＧＲファイルをオープンし、ＵＩＥ ＴＧ＿ＩＤのリスト及び名前をユーザに表示する。
【０２０２】
ステップＳ４２０において、ユーザは、ＵＩＥ ＴＧ＿ＩＤのリストの中から、１つの
ＴＧ＿ＩＤを選択する。
【０２０３】
ステップＳ４３０において、音楽レコーダ１０００は、選択されたＴＧ＿ＩＤに対応するＴＧ＿ｘｘｘｘストリームファイルをオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストをユーザに表示する。
【０２０４】
ステップＳ４４０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。
【０２０５】
ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ４４０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ４２０からの処理を繰り返す。ｅｌｅｍｅｎｔがＴＧでない場合、すなわち、ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ４４０のＮｏ）、ステップＳ４５０において、ユーザは、ｅｌｅｍｅｎｔ＿ＩＤのリストの中から、１つのＴＬ＿ＩＤを選択する。
【０２０６】
ステップＳ４６０において、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルから、選択されたＴＬ＿ＩＤに対応するＴＬ構造体を取得する。
【０２０７】
ステップＳ４７０において、音楽レコーダ１０００は、取得したＴＬ構造体の“Ｍｕｓｉｃ Ｃｏｎｔｅｎｔｓ ＩＤ”、“Ｓｔａｒｔ Ｐｏｉｎｔ ｉｎ Ｃｏｎｔｅｎｔｓ Ｆｉｌｅ”及び“Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ”から、ＡＵＤｘｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＡｕｄｉｏＤａｔａストリームファイルの再生位置を確保する。
【０２０８】
ステップＳ４８０において、音楽レコーダ１０００は、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルから、ライセンスファイル（復号鍵）を取得する。
【０２０９】
ステップＳ４９０において、音楽レコーダ１０００は、取得した復号鍵を用いて、ＡｕｄｉｏＤａｔａストリームファイルに含まれるオーディオデータを復号して再生する。
【０２１０】
ステップＳ５００において、音楽レコーダ１０００は、ＴＬ構造体のＰｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに“１”加算する。なお、Ｐｌａｙｂａｃｋ Ｃｏｕｎｔｅｒに加算するタイミングは、再生開始時ままたは再生終了時の何れでもよい。
【０２１１】
ステップＳ５１０において、音楽レコーダ１０００は、オーディオデータ、つまり、音楽コンテンツの再生が途中で停止されたか否かを判定する。
【０２１２】
音楽コンテンツの再生が途中で停止された場合（ステップＳ５１０のＹｅｓ）、ステップＳ５２０において、音楽レコーダ１０００は、当該停止した位置に対して、リジュームポイントを設定する。
【０２１３】
（６）プレイリスト作成（ＴＧ）
図１７は、プレイリスト（ＴＧ）を作成するフローを示している。
【０２１４】
図１７に示すように、ステップＳ６１０において、ユーザは、プレイリストのフォルダを作成する。プレイリストのフォルダがユーザによって作成されると、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルを生成する。具体的には、当該ＴＧ＿ｘｘｘｘストリームファイルを構成するフィールドは、以下のように設定される。
【０２１５】
・  ＴＧ Ｓｐｅｃｉｆｉｃ Ｓｔｒｕｃｔｕｒｅ ＴＹＰＥ ＝ ０ｘ０２
・  ＴＧ Ｆｌａｇ ＝ ０ｘ０３
・  ＴＧ ｓｐｅｃｉｆｉｃ ｓｔｒｕｃｔｕｒｅ ｎａｍｅ ＝ プレーリストタイト
ル
・  Ｌｉｎｋ Ｃｏｕｎｔ ＝ ０
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ０
ステップＳ６２０において、ユーザは、ＴＧ＿００００ストリームファイルからユーザがプレイリストに登録するものをピックアップする。
【０２１６】
ステップＳ６３０において、音楽レコーダ１０００は、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。具体的には、音楽レコーダ１０００は、以下に示すように、ＴＧ＿ｘｘｘｘストリームファイルの内容を更新する。
【０２１７】
・  Ｎｕｍｂｅｒ ｏｆ ｅｌｅｍｅｎｔｓ ＝ ｎ＋１
・  ｅｌｅｍｅｎｔ ＩＤ：  選択されたＴＬ＿ＩＤを追加
・  各ｅｌｅｍｅｎｔのＴＬ構造体に含まれるＬｉｎｋ Ｃｏｕｎｔに“１”を加算
ステップＳ６４０において、音楽レコーダ１０００は、さらにプレイリストに追加するものがあるか否かを判定する。
【０２１８】
さらにプレイリストに追加するものがある場合（ステップＳ６４０のＹｅｓ）、ユーザは、ステップＳ６２０からの処理を繰り返す。
【０２１９】
プレイリストに追加するものがない場合（ステップＳ６４０のＮｏ）、ステップＳ６５０において、音楽レコーダ１０００は、ステップＳ６３０において更新したＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧ（例えば、図１０に示したＴＧ１０Ａ）があるか否かを判定する。
【０２２０】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがある場合（ステップＳ６５０のＹｅｓ）、ステップＳ６６０において、音楽レコーダ１０００は、当該上位ＴＧについて、メンテナンスを実行する。具体的には、ステップＳ２６０と同様なメンテナンスが実行される。
【０２２１】
ＴＧ＿ｘｘｘｘストリームファイルがリンクされる上位のＴＧがない場合（ステップＳ２５０のＮｏ）、ステップＳ６７０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。具体的には、音楽レコーダ１０００は、ステップＳ２７０と同様に、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの内容を更新する。
【０２２２】
なお、音楽レコーダ１０００がＴＧ＿ｘｘｘｘストリームファイルを生成する場合、“ｘｘｘｘ”部分の簡易的な割り当て方法としては、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールド（表６参照）を参照して、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる方法が用いられる。
【０２２３】
また、他の割り当て方法としては、全てのＴＧ＿ＩＤをサーチして、欠損している番号（例えば、一度生成されて、その後削除した場合）があれば、当該番号を割り当てる方法がある。この場合、欠損している番号がなければ、上述したように、現状の最大値に“１”を加算した値を割り当てるとともに、“Ｍａｘｉｍｕｍ Ｔｒａｃｋ Ｇｒｏｕｐ ＩＤ”フィールドにも、現状の最大値に“１”を加算した値を割り当てる。
【０２２４】
すなわち、簡易的な割り当て方法では、全てのＴＧ＿ＩＤをサーチする必要がなく、より高速に“ｘｘｘｘ”部分の割り当て処理を実行することができる。
【０２２５】
（７）メタデータによるリストのソート
図１８は、メタデータによって、リストをソートするフローを示している。図１８に示すように、ステップＳ７１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２２６】
ステップＳ７２０において、ユーザは、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）から検索したいフィールドを選択する。
【０２２７】
ステップＳ７３０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルのＭｅｔａＤａｔａストリームファイルから候補のメタデータを検索する。ステップＳ７４０において、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２２８】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストをソートする場合、音楽レコーダ１０００は、ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬについて、以下の処理を実行する。
【０２２９】
（ｉ）  ＴＬ＿ＩＤ ＃ｎ（ｎ＝１〜５）のＴＬ（ＴＬ２０１〜２０５）に対して、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに属するＭｅｔａＤａｔａストリームファイルをオープンする。
【０２３０】
（ｉｉ）  ＭｅｔａＤａｔａストリームファイルの先頭から、“Ｇｅｎｒｅ”フィールドの先頭までのバイト数を演算する（表２６において、１＋ａ＋１＋ｂ＋１＋ｃ＋１＋ｄを演算することに該当）。
【０２３１】
（ｉｉｉ）  “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドの値（＝ｅ）を取得する。
【０２３２】
（ｉｖ）  “Ｌｅｎｇｔｈ ｏｆ Ｇｅｎｒｅ”フィールドに続く“Ｇｅｎｒｅ”フィールドに記述されているデータを取得する。
【０２３３】
（ｖ）  ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２３４】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２３５】
（８）メタデータによるリストの高速ソート
図１９は、メタデータによって、リストを高速にソートするフローを示している。図１９に示すように、ステップＳ７１０Ａにおいて、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２３６】
ステップＳ７２０Ａにおいて、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２３７】
ステップＳ７３０Ａにおいて、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体から候補のメタデータを検索する。ステップＳ７４０Ａにおいて、音楽レコーダ１０００は、該当するＴＬをメタデータ順にソートする。
【０２３８】
すなわち、図１８に示したメタデータによるリストのソート方法では、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるＭｅｔａＤａｔａストリームファイル（メタデータ構造体）をオープンして内容を検索しなければならないが、図１９に示したメタデータによるリストのソート方法では、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、より高速にソートを実行することができる。
【０２３９】
より具体的には、図２６に示すように、５つのトラック（ＴＬ２０１〜２０５，ＭＣ３０１〜ＭＣ３０５）から構成されるＴｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ）からメタデータによってリストを高速にソートする場合、音楽レコーダ１０００は、ＴｒａｃｋＬｉｎｋｓストリームファイルをオープンし、以下の処理を実行する。
【０２４０】
（ｉ）  ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置を取得する。具体的には、ＴＬ＿ＩＤ ＃１の“Ｇｅｎｒｅ”フィールドの先頭位置が、ＴｒａｃｋＬｉｎｋｓストリームファイルの先頭から２１０バイト目（表７において、ＴＬ＿ＩＤ ＃１に係るＴＬ構造体のデータは、８バイト目から開始され、表８において、“Ｇｅｎｒｅ”フィールドは、２０２バイト目から開始されている）であることを認識する。
【０２４１】
（ｉｉ）  “Ｇｅｎｒｅ”フィールドに記述されているデータを取得し、ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを記憶する。
【０２４２】
（ｉｉｉ）  ＴＬ＿ＩＤ ＃２の“Ｇｅｎｒｅ”フィールドの先頭位置（５３４バイト目（２１０＋３２４バイト、表７及び表８参照））を取得する。同様に、ＴＬ＿ＩＤ ＃３，＃４，＃５の先頭位置は、（２１０＋２×３２４）バイト目、（２１０＋３×３２４）バイト目、（２１０＋４×３２４）バイト目となる。
【０２４３】
（ｉｖ）  ＴＬ＿ＩＤとＧｅｎｒｅデータとのリストを、既に取得したリスト（例えば、ＴＬ＿ＩＤ＃３の場合、ＴＬ＿ＩＤ＃１及びＴＬ＿ＩＤ＃２に係るリスト）と比較し、アルファベット順（日本語の場合は５０音順）にソートする。
【０２４４】
ＴＬ＿ＩＤ ＃１〜ＴＬ＿ＩＤ ＃５のＴＬ（ＴＬ２０１〜２０５）について、上述した（ｉ）〜（ｉｖ）の処理を実行した音楽レコーダ１０００は、ソートされたＴＬ＿ＩＤ順にリストの内容を表示する。
【０２４５】
（９）メタデータによるリストの高速検索
図２０は、メタデータによって、リストを高速に検索するフローを示している。図２０に示すように、ステップＳ８１０において、ユーザは、ＴＬのリストで表現されているＴＧを選択する。
【０２４６】
ステップＳ８２０において、ユーザは、ＴＬ構造体によって定義されているメタデータフィールドから、検索したいフィールドを選択する。
【０２４７】
ステップＳ８３０において、ユーザは、選択したフィールドに対応する文字を入力する。
【０２４８】
ステップＳ８４０において、音楽レコーダ１０００は、ＴＧのｅｌｅｍｅｎｔであるＴＬに対応するＴＬ構造体からメタデータを検索し、ユーザが入力した文字とマッチングを実行する。ステップＳ８５０において、音楽レコーダ１０００は、該当するＴＬのリストをユーザに表示する。
【０２４９】
本検索方法でも、３２４バイトの固定長を有するＴＬ構造体（表８参照）が用いられるため、ＭｅｔａＤａｔａストリームファイルをオープンする場合と比較して、より高速な検索を実行することができる。
【０２５０】
（１０）リジュームポイントの設定
図２１は、リジュームポイントを設定するフローを示している。図２１に示すように、ステップＳ９１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルからＵＩＥ ＴＧのリストをユーザに表示する。
【０２５１】
ステップＳ９２０において、ユーザは、ＵＩＥ ＴＧリストから１つのＴＧを選択する。ステップＳ９３０において、音楽レコーダ１０００は、“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”フィールドに選択されたＴＧ＿ＩＤを記述する。また、音楽レコーダ１０００は、当該ＴＧ＿ＩＤを記述した時刻を“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ ｒｅｃｏｒｄｅｄ ｄａｔｅ”に記述する。
【０２５２】
ステップＳ９４０において、音楽レコーダ１０００は、選択されたＴＧのｅｌｅｍｅｎｔリストをユーザに表示する。
【０２５３】
ｅｌｅｍｅｎｔがＴＧである場合（ステップＳ９５０のＮｏ）、ステップＳ９８０において、ユーザは、ＴＧリストから１つのＴＧを選択する。ステップＳ９９０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＧ＿ＩＤを追加する
。
【０２５４】
ｅｌｅｍｅｎｔがＴＬである場合（ステップＳ９５０のＹｅｓ）、ステップＳ９６０において、ユーザは、ＴＬリストから、１つのＴＬを選択する。ステップＳ９７０において、音楽レコーダ１０００は、“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に当該ＴＬ＿ＩＤを追加する。
【０２５５】
以降、音楽レコーダ１０００は、選択されたＴＬ＿ＩＤと対応するＴＬ構造体に基づいて、オーディオデータを再生する（図１６のステップＳ４７０以降の処理を参照）。
【０２５６】
（１１）リジューム再生
図２２は、リジュームポイントに基づいて、オーディオデータを再生（リジューム再生）するフローを示している。図２２に示すように、ステップＳ１０１０において、音楽レコーダ１０００は、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｌａｓｔ Ａｃｃｅｓｓｅｄ ＵＩＥ ＴＧ＿ＩＤ”に記述されているＴＧ＿ＩＤに該当するＴＧ＿ｘｘｘｘストリームファイルをオープンする。
【０２５７】
ステップＳ１０２０において、音楽レコーダ１０００は、該当するＴＧの“Ｒｅｓｕｍｅ ｅｌｅｍｅｎｔ”に記述されているｅｌｅｍｅｎｔ＿ＩＤを取得する。
【０２５８】
ステップＳ１０３０において、音楽レコーダ１０００は、ｅｌｅｍｅｎｔがＴＧか否かを判定する。ｅｌｅｍｅｎｔがＴＧの場合（ステップＳ１０３０のＹｅｓ）、音楽レコーダ１０００は、ステップＳ１０２０からの処理を繰り返す。
【０２５９】
ｅｌｅｍｅｎｔがＴＬの場合（ステップＳ１０３０のＮｏ）、ステップＳ１０４０において、音楽レコーダ１０００は、リジュームポイントが設定されているか否かを判定する。
【０２６０】
リジュームポイントが設定されている場合（ステップＳ１０４０のＹｅｓ）、ステップＳ１０５０において、音楽レコーダ１０００は、リジュームポイントからオーディオデータを再生する。一方、リジュームポイントが設定されていない場合（ステップＳ１０４０のＮｏ）、ステップＳ１０６０において、音楽レコーダ１０００は、曲（または音楽アルバム）の最初からオーディオデータを再生する。
【０２６１】
なお、リジュームポイント設定をオプション仕様とする場合、上述したように、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”が使用される。リジュームをサポートしている音楽レコーダなど（コンテンツデータ記録装置）は、立上げ時（電源投入時など）に１ｂを記録する。一方、リジュームをサポートしていない音楽レコーダなどは、立上げ時に０ｂを記録する。
【０２６２】
また、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を移動後、他の音楽レコーダなどで再生する場合、当該他の音楽レコーダなどは、まず、ＡＵＤ＿ＳＥＴ．ＭＧＲファイルの“Ｒｅｓｕｍｅ Ｓｕｐｐｏｒｔ Ｆｌａｇ”の内容を読み込み、値が１ｂの場合にはリジューム再生を行い、値が０ｂの場合にはリジューム再生を行わない。
【０２６３】
（１２）タイトル削除
図２３は、音楽コンテンツ（オーディオデータ）と対応付けられているタイトルを削除するフローを示している。図２３に示すように、ステップＳ１１１０において、音楽レコーダ１０００は、ＴＧ＿００００ストリームファイル（Ｔｒａｃｋ＿Ｂａｓｅ（ＴＧ１０ＴＢ））をオープンし、ｅｌｅｍｅｎｔ＿ＩＤのリストと名前をユーザに表示する。
【０２６４】
ステップＳ１１２０において、ユーザは、削除するタイトルを１つ選択する。ステップＳ１１３０において、音楽レコーダ１０００は、当該タイトルのＴＬとリンクされているＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されているか否かを判定する。
【０２６５】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されている場合（ステップＳ１１３０のＹｅｓ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２６６】
ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルが１トラックのみで構成されていない場合（ステップＳ１１３０のＮｏ）、すなわち、複数曲で構成されている場合、ステップＳ１１４０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクをサーチする。
【０２６７】
ステップＳ１１５０において、音楽レコーダ１０００は、ＴＬから当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在するか否かを判定する。
【０２６８】
当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが１以上存在する場合（ステップＳ１１５０のＹｅｓ）、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除せず、ステップＳ１１７０の処理を実行する。
【０２６９】
一方、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルへのリンクが全く存在しない場合（ステップＳ１１５０のＮｏ）、ステップＳ１１６０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルを削除する。
【０２７０】
ステップＳ１１７０において、音楽レコーダ１０００は、当該ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルと対応付けられているＴＬ構造体を削除するとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する。具体的には、ＴＬ構造体の“Ｌｉｎｋ Ｃｏｕｎｔ”にＴＧからリンクされている数が記述されているため、音楽レコーダ１０００は、“Ｌｉｎｋ Ｃｏｕｎｔ”に基づいて、当該ＴＬへのリンクを削除する。
【０２７１】
また、ＴｒａｃｋＬｉｎｋｓストリームファイルからＴＬ構造体を削除した場合、他のＴＬ＿ＩＤが、“１”づつ小さくなる（ＴＬ＿ＩＤは、並び順のため）。このため、全てのＴＧに対して、削除したＴＬのＴＬ＿ＩＤ、及び当該ＴＬ以降のＴＬ＿ＩＤのメンテナンスが必要となる。
【０２７２】
すなわち、音楽レコーダ１０００は、削除されたＴＬ＿ＩＤの値よりも大きな値のＴＬ＿ＩＤをリンクしているＴＧのメンテナンスを実行する。具体的には、当該ＴＬ＿ＩＤの値が、それぞれ“１”減らされる。
【０２７３】
図２４は、図２３に示した“タイトル削除”のフローの変更部分を示している。図２４に示すステップＳ１１４１及びステップＳ１１４２の処理は、図２３に示すＳ１１７０の処理に代えて、実行される。
【０２７４】
ステップＳ１１４１において、音楽レコーダ１０００は、削除するＴＬ構造体をリンクしているＴＧから、当該ＴＬのリンクを削除する
ステップＳ１１４２において、音楽レコーダ１０００は、当該ＴＬ構造体のＶａｌｉｄビッドをＯＦＦにするとともに、当該ＴＬ構造体をリンクしているＴＧから、当該ＴＬへのリンクを削除する
なお、この場合、上述したＴＬ＿ＩＤのメンテナンスは必要ない。つまり、ＴＬ構造体自体は削除されないためＴＬ＿ＩＤが変化しない。ただし、ＴＧに対しては、削除したＴＬ＿ＩＤの削除が必要となる。この簡易的な方法によれば、次回ＴＬを追加する場合、ＶａｌｉｄビッドがＯＦＦとなっている領域を再使用することができる。
【０２７５】
（１３）プリセットモデルにおける購入
図２５は、リムーバブルＨＤＤ１１２６に予め暗号化された音楽コンテンツ（オーディオデータ）が記録されたプリセットモデルにおいて、ユーザが、所望の音楽コンテンツを購入するフローを示している。
【０２７６】
プリセットモデルの場合、オーディオデータ（ＡｕｄｉｏＤａｔａストリームファイル）は、ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに記録される。また、ＴＬは、プリセットモデル専用にＰＲＴＬｓストリームファイルに記録される。ユーザは、このようにオーディオデータや各種ファイルが記録されたリムーバブルＨＤＤ１１２６を入手（購入）する。
【０２７７】
この状態では、ユーザは、リムーバブルＨＤＤ１１２６に記録されている音楽コンテンツ（オーディオデータ）を視聴することができないため、購入手続きを行う必要がある。具体的には、図２５に示すように、ステップＳ１２１０において、ユーザは、音楽レコーダ１０００による高速検索（図２０参照）などを利用して、購入する音楽コンテンツを選択する。
【０２７８】
ステップＳ１２２０において、ユーザは、当該音楽コンテンツを視聴するためのライセンス（復号鍵及び利用条件）を購入する。具体的には、ユーザは、コンテンツサーバ１１３２などにアクセスして、当該ライセンスを購入する。
【０２７９】
ユーザによってライセンスが購入されると、ステップＳ１２３０において、音楽レコーダ１０００は、購入した音楽コンテンツに係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルに含まれるライセンス管理情報である“Ｌｉｃｅｎｓｅ Ｆｌａｇ”をセットすると同時に、*ＵＤＦ＿ＬＩＣＥＮＣＥセキュアストリームファイルを生成する。
【０２８０】
ステップＳ１２４０において、音楽レコーダ１０００は、当該ＴＬをＰＲＴＬｓストリームファイルからＴｒａｃｋＬｉｎｋｓストリームファイルに移動する（詳細については、上述した図７及び図８に係る説明を参照）。なお、ＰＲＴＬｓストリームファイルにおけるタイトルは、図２４に示した簡易的な方法によって削除される。
【０２８１】
（作用・効果）
以上説明した本実施形態及び本実施例によれば、音楽コンテンツなどのオーディオデータを利用するユーザは、トラックリンク情報及びメタデータ管理情報（ＭｅｔａＤａｔａストリームファイル）を含むＡＵＤ＿ＳＥＴ．ＭＧＲファイルを用いるため、音楽コンテンツの検索、再生がさらに容易かつ速やかに行え、音楽コンテンツの取扱いに係る利便性を向上させることができる。
【０２８２】
（その他の実施形態）
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【０２８３】
例えば、上述した本発明の実施形態では、音楽コンテンツ（オーディオデータ）を例として説明したが、本発明は、音楽コンテンツのみではなく、例えば、静止画像や動画のコンテンツに適用することもできる。
【０２８４】
また、上述した本発明の実施形態では、リムーバブルＨＤＤ１１２６（リムーバブル記録媒体）を例として説明したが、本発明は、コンテンツデータ記録装置などに内蔵されるハードディスクドライブ（ＨＤＤ）などにも適用することができる。
【０２８５】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは、もちろんである。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【図面の簡単な説明】
【０２８６】
【図１】本発明の実施形態に係るファイルフォーマットの概要を示す図である。
【図２】本発明の実施形態に係るディレクトリ及びファイルの構成を示す図である。
【図３】本発明の実施形態に係るＡＵＤ＿ＳＥＴ．ＭＧＲの構成を示す図である。
【図４】本発明の実施形態に係るＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイルの構成を示す図である。
【図５】本発明の実施形態に係る“Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図６】本発明の実施形態に係る“Ｐｒｅｓｅｔ＿Ｔｒａｃｋ＿Ｂａｓｅ”を用いたモデル構成例を示す図である。
【図７】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）される前の状態を示す図である。
【図８】本発明の実施形態に係るモデル構成例において、暗号化された音楽コンテンツのライセンスが取得（購入）された後の状態を示す図である。
【図９】本発明の実施形態に係る音楽コンテンツ管理モデルの基本的な構成例を示す図である。
【図１０】本発明の実施形態において、音楽アルバムを管理する場合における構成例を示している。
【図１１】本発明の実施例に係る音楽レコーダ（コンテンツデータ記録装置）の構成を示す図である。
【図１２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１６】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１７】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１８】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図１９】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２０】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２１】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２２】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２３】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２４】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２５】本発明の実施例に係る音楽レコーダの動作フローを示す図である。
【図２６】本発明の実施例に係る音楽レコーダにおいて実行されるトラックリンクのソート動作を説明するためのモデル構成図である。
【符号の説明】
【０２８７】
１０，１０Ａ，１０Ａ１〜１０Ａ３，１０ＡＴ，１０Ｂ，１０ＰＬ１〜１０ＰＬ３，１０ＰＬＴ，１０ＰＴＢ，１０ＴＢ…ＴＧ（トラックグループ）
２０１〜２０Ｎ＋１，２１１〜２１Ｎ＋１…ＴＬ（トラックリンク）
３０１〜３０４，３０Ｍ…ＭＣ（記録済み音楽コンテンツ）
１００…ＲＯＯＴディレクトリ
１１０…ＡＵＲ＿ＲＯＯＴディレクトリ
１２０…ＡＵＤ＿ＳＥＴ．ＭＧＲ
１３０…ＲＴ＿ＡＵＲＳディレクトリ
１４０…ＡＵＤｘｘｘｘｘｘｘ．ＡＩＦファイル
１０００…音楽レコーダ
１１０１…ＣＤ
１１０２…ＣＤドライブ
１１０４…ＡＡＣエンコーダ
１１０６…暗号化処理部
１１０８…復号化処理部
１１１０…ＡＡＣデコーダ
１１１２…Ｄ／Ａ変換部
１１１４…スピーカ
１１１６…制御部
１１１８…表示部
１１２０…リモコン受光部
１１２２…リモコン
１１２４…ＡＴＡインタフェース
１１２６…リムーバブルＨＤＤ
１１２８…モデム
１１３０…インターネット網
１１３２…コンテンツサーバ
１１３４…メタデータサーバ
【図１】
2008176796.tif 000029
【図２】
2008176796.tif 000030
【図３】
2008176796.tif 000031
【図４】
2008176796.tif 000032
【図５】
2008176796.tif 000033
【図６】
2008176796.tif 000034
【図７】
2008176796.tif 000035
【図８】
2008176796.tif 000036
【図９】
2008176796.tif 000037
【図１０】
2008176796.tif 000038
【図１１】
2008176796.tif 000039
【図１２】
2008176796.tif 000040
【図１３】
2008176796.tif 000041
【図１４】
2008176796.tif 000042
【図１５】
2008176796.tif 000043
【図１６】
2008176796.tif 000044
【図１７】
2008176796.tif 000045
【図１８】
2008176796.tif 000046
【図１９】
2008176796.tif 000047
【図２０】
2008176796.tif 000048
【図２１】
2008176796.tif 000049
【図２２】
2008176796.tif 000050
【図２３】
2008176796.tif 000051
【図２４】
2008176796.tif 000052
【図２５】
2008176796.tif 000053
【図２６】
2008176796.tif 000054
【手続補正書】
【提出日】平成20年6月17日(2008.6.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記録媒体に記録されたコンテンツデータを視聴させるための制御手段と、
前記コンテンツデータにアクセスするアクセス手段とを備える記録装置であって、
前記記録媒体は、コンテンツデータを含むコンテンツファイル群と、前記コンテンツデータの管理情報であるトラックリンクを含むトラックリンクファイルを有し、
前記トラックリンクファイルは、視聴に制限がある第１のコンテンツデータを管理するための第１のトラックリンクファイルと、視聴に制限のない第２のコンテンツデータを管理するための第２のトラックリンクファイルとを有するように構成されており、
前記コンテンツファイル群は、コンテンツデータを記録するコンテンツファイルと、前記コンテンツデータの付加情報である可変長のメタデータを記録するメタデータファイルを含み、
前記トラックリンクは、固定長のデータ構造を有し、かつ、前記コンテンツファイルへのリンク情報と、前記可変長のメタデータが所定の長さより長い場合、前記可変長のメタデータから、その長い部分を削除することで生成した固定長のメタデータを含み、
前記制御手段は、前記第１のコンテンツデータを視聴するためのライセンスが取得されると、前記ライセンス情報を格納するライセンスファイルを生成する手段と、
前記ライセンスファイルを前記第１のコンテンツデータを含むコンテンツファイルに関連付ける手段と、
前記第１のコンテンツデータに対応したライセンスが取得されたことより、前記第１のコンテンツデータの視聴が許可されると、前記ライセンスが取得された第１のコンテンツデータに対応する第１のトラックリンクを、前記第１のトラックリンクファイルから前記第２のトラックリンクファイルへ移動する移動手段とを備え、
前記アクセス手段は、前記トラックリンクのリンク情報を参照することで、前記コンテンツデータにアクセスする、
ことを特徴とする記録装置。
【請求項２】
前記記録装置は、前記固定長のメタデータに基づき、前記コンテンツデータのソートを実行する、
ことを特徴とする請求項１に記載の記録装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、記録媒体に記録されたコンテンツデータを視聴させるための制御手段と、前記コンテンツデータにアクセスするアクセス手段とを備える記録装置であって、前記記録媒体は、コンテンツデータを含むコンテンツファイル群と、前記コンテンツデータの管理情報であるトラックリンクを含むトラックリンクファイルを有し、前記トラックリンクファイルは、視聴に制限がある第１のコンテンツデータを管理するための第１のトラックリンクファイルと、視聴に制限のない第２のコンテンツデータを管理するための第２のトラックリンクファイルとを有するように構成されており、前記コンテンツファイル群は、コンテンツデータを記録するコンテンツファイルと、前記コンテンツデータの付加情報である可変長のメタデータを記録するメタデータファイルを含み、前記トラックリンクは、固定長のデータ構造を有し、かつ、前記コンテンツファイルへのリンク情報と、前記可変長のメタデータが所定の長さより長い場合、前記可変長のメタデータから、その長い部分を削除することで生成した固定長のメタデータを含み、前記制御手段は、前記第１のコンテンツデータを視聴するためのライセンスが取得されると、前記ライセンス情報を格納するライセンスファイルを生成する手段と、前記ライセンスファイルを前記第１のコンテンツデータを含むコンテンツファイルに関連付ける手段と、前記第１のコンテンツデータに対応したライセンスが取得されたことより、前記第１のコンテンツデータの視聴が許可されると、前記ライセンスが取得された第１のコンテンツデータに対応する第１のトラックリンクを、前記第１のトラックリンクファイルから前記第２のトラックリンクファイルへ移動する移動手段とを備え、前記アクセス手段は、前記トラックリンクのリンク情報を参照することで、前記コンテンツデータにアクセスすることを要旨とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明の第２の特徴は、本発明の第１の特徴に係り、前記記録装置は、前記固定長のメタデータに基づき、前記コンテンツデータのソートを実行することを要旨とする。