JP4150278B2 - 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体 - Google Patents

半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体 Download PDF

Info

Publication number
JP4150278B2
JP4150278B2 JP2003092578A JP2003092578A JP4150278B2 JP 4150278 B2 JP4150278 B2 JP 4150278B2 JP 2003092578 A JP2003092578 A JP 2003092578A JP 2003092578 A JP2003092578 A JP 2003092578A JP 4150278 B2 JP4150278 B2 JP 4150278B2
Authority
JP
Japan
Prior art keywords
aob
tki
track
memory card
playback
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2003092578A
Other languages
English (en)
Other versions
JP2004030586A5 (ja
JP2004030586A (ja
Inventor
照人 廣田
健二 田川
智一 石川
信治 井上
秀樹 松島
雅之 小塚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2003092578A priority Critical patent/JP4150278B2/ja
Publication of JP2004030586A publication Critical patent/JP2004030586A/ja
Publication of JP2004030586A5 publication Critical patent/JP2004030586A5/ja
Application granted granted Critical
Publication of JP4150278B2 publication Critical patent/JP4150278B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
    • G11C7/16—Storage of analogue signals in digital stores using an arrangement comprising analogue/digital [A/D] converters, digital memories and digital/analogue [D/A] converters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32101—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N1/32106—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file
    • H04N1/32112—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file in a separate computer file, document page or paper sheet, e.g. a fax cover sheet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3261—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of multimedia information, e.g. a sound signal
    • H04N2201/3264—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of multimedia information, e.g. a sound signal of sound signals

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Storage Device Security (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、オーディオデータ、制御データを格納する半導体メモリカードと、当該半導体メモリカードについての再生装置、記録装置、再生方法、記録方法、コンピュータ読み取り可能な記録媒体に関し、特に、電子音楽配信等のコンテンツ配信サービスにおいて、コンテンツとして配信されたオーディオデータ、管理情報を格納する場合の改良に関する。
【０００２】
【従来の技術】
近年、電子音楽配信を実現するためのインフラストラクチャが整備されつつあり、CD,カセットテープ等のパッケージソフトの流通を主体としていた音楽業界は、壮大な変革期を迎えようとしている。
かかる電子音楽配信音楽コンテンツの引き渡しは、消費者が所有するコンピュータが、音楽会社のサーバコンピュータから音楽コンテンツをダウンロードすることにより実現される。電子音楽配信の利用者は、こうしてダウンロードにより入手した音楽コンテンツを持ち運ぼうとする場合、音楽コンテンツを可搬式の記録媒体に格納させねばならない。電子音楽配信により入手した音楽コンテンツの格納に最も適しているといわれているものが上述した半導体メモリカードである。
【０００３】
半導体メモリカードは、フラッシュATAカードやコンパクトフラッシュ（登録商標）カードと呼ばれるものが知られている。これら半導体メモリカードは、フラッシュメモリ(EEPROM)と呼ばれる半導体デバイスを内蔵しており、MD,CD-R等と比較して、データの高速書き込みが可能であり、膨大なデータ長を有する音楽コンテンツの格納を短期間で完遂することができる。
【０００４】
その反面、電子音楽配信にて配信された音楽コンテンツが半導体メモリカードに格納されれば、半導体メモリカードに格納された音楽コンテンツを更にコピーすることにより、音楽著作物の不正な複製品が氾濫する恐れがある。特に半導体メモリカードは、CD-R,MDと比較して、高速なデータ書き込みが可能であるので、複製品の氾濫は、より深刻化すると考えられる。そのような著作権者の不安を払拭するためには、電子音楽配信にて配信された音楽コンテンツを半導体メモリカードに格納する場合に、著作権者側の不安を払拭するような高度な暗号化方式で、音楽コンテンツを暗号化せねばならない。不正コピーを防止することを念頭においたコンテンツの格納方式の1つに、DVD-Audio規格のタイトル格納方式がある。音楽アプリケ−ションプログラムを一例にとるなら、タイトルとは、音楽アルバムに相当し、曲に該当するコンテンツを複数含む。タイトルを構成する複数コンテンツは、コンテンツはその製作者が定めた暗号鍵（一般にタイトル鍵と呼ばれる。）により暗号化された状態で、DVD-Audioに記録される。タイトル鍵は、コンテンツが記録されたDVD-Audioについて固有な暗号鍵（一般にディスク鍵と呼ばれる。）を用いた暗号化を経てDVD-Audioにおけるセクタヘッダ領域に記録される。そのディスク鍵自身も、コンテンツのデコード装置を製作した製作会社が定めた暗号鍵（一般にマスタ鍵と呼ばれる。）を用いて、暗号化されてDVD-Audioのリードイン領域に記録される。これらセクタヘッダ領域と、リードイン領域は、一般ユーザがアクセスできない領域なので、DVD-Audioに記録されたタイトル鍵を不正に取得することは、極めて困難になる。
【０００５】
また磁気式、光学式の記録媒体と比較して、半導体メモリカードはその容量が制限されていることが多いので、音楽コンテンツを半導体メモリカードに格納する際には、音楽コンテンツをより高度に圧縮しておく必要がある。そのような高圧縮率を得ることができる符号化方式の1つにMPEG2-AAC方式がある。MPEG2-AAC方式の特徴は、人間の聴覚特性を考慮して、各オーディオフレーム（オーディオフレームとは、符号化、再生の最小単位となる時間帯であり、大体20msecの時間長に相当する）に割り当てるべきビット長を変化させる点にある。即ち、可聴帯域（人間が聞くことができる帯域）を多く有するオーディオフレームに多くのビット長を割り当て、不可聴帯域（人間が聞く事ができない帯域）を多く有するオーディオフレームには、割り当てるべきビット長を削減するのである。
【０００６】
このようにMPEG2-AAC方式は可聴帯域の含有量に応じてオーディオフレームに割り当てるべきビット長を変化させるので、言い換えれば可変長符号化方式であるので、高圧縮率且つ高音質な音楽コンテンツを得ることができる。高圧縮率且つ高音質な音楽コンテンツは、公衆ネットワークでの伝送に好適であり、容量が制限された半導体メモリカードに蓄積する場合に好適である。
【０００７】
尚、半導体メモリカードに関する先行技術文献には、以下の特許文献に記載されたものがある。
【０００８】
【特許文献１】
特開平０９−１０７５３６号公報
【特許文献２】
特開平０７−３１９６３５号公報
【特許文献３】
特開平１０−２６９２９０号公報
【特許文献４】
特開平１１−０４５５０７号公報
【０００９】
【発明が解決しようとする課題】
ところで、従来のコンテンツの格納方式では、その音楽コンテンツの暗号化に用いたタイトル鍵が解読されれば、その記録媒体に記録されている全ての音楽コンテンツの復号が可能になるので、いったんタイトル鍵が暴露されると、その半導体メモリカードに格納されている全ての曲が容易に復号化されてしまうという第１の問題点がある。そのような事態は頻繁に起こるとは言い難いが、希にでも発生すれば、それに起因して生じる著作権者の損害は、はかりしえないものとなる。特に、近年におけるコンピュータの処理能力の向上には目覚ましいものがあり、音楽コンテンツの暗号化に用いたタイトル鍵が解読されることは、完全に有り得ないとは断言し難い。万が一にでもタイトル鍵が暴露された場合に、著作権者の損害を最小限に留めるようなデータ構造は、従来技術には存在しないという問題点がある。
【００１０】
また、電子音楽配信において配信されるべき音楽コンテンツは、著作権を保護せねばならないので、暗号化された状態のまま音楽コンテンツを配信し、半導体メモリカードも、暗号化がなされたまま、音楽コンテンツを格納しておく必要がある。しかし暗号化された状態のまま音楽コンテンツを半導体メモリカードに格納した場合、正当な対価を支払って音楽コンテンツを入手した操作者から、音楽コンテンツを自由に編集する機会を奪ってしまうという第２の問題点がある
即ち、音楽コンテンツが暗号化されれば、曲の再生順序を入れ替えたり、また一部の曲を削除するという編集が困難となる。これは、電子音楽配信において正当な対価を支払って音楽コンテンツを入手した操作者からも音楽コンテンツを自由に編集する機会を奪う結果になる。
【００１１】
一方、半導体メモリカードと同じ音楽の録音用途に用いられるミニディスク(MD)の記録装置は、TOC(Table Of Contens)を用いて各曲にトラックという再生単位を割り当てることにより、各トラックの再生順序を入れ替えたり、トラックを分割したり、複数トラックを1つに統合するといった編集操作、いわゆるトラック編集を実現している。半導体メモリカードにおいてトラック編集が実現できないのでは、既存のミニディスクと比較して、機能的に見劣りすることになってしまい、現状のミニディスクのユーザに、半導体メモリカードの機能価値を強くアピールできないという問題点がある。
【００１２】
本発明の目的は、音楽コンテンツの著作権を保護しつつも、音楽コンテンツの編集を行うことができる半導体メモリカードを提供することである。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明に係る半導体メモリカードは、 プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、 管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示すことを特徴としている。
【００１４】
【発明の実施の形態】
以降、図面を参照しながら半導体メモリカード（フラッシュメモリカード）の実施形態について説明を行う。
尚、以降の各文には、その文頭に以下のような体系を有する分類番号を付している。
【００１５】
[x1-x2_x3-x4]
分類番号の桁数は、その項目の階層的な深さを意味している。具体的にいうと、x1は、説明に引用している図番である。本明細書に添付している図には、明細書において引用する順番に沿った番号を付しているので、この図番の順序が、説明の順序とほぼ同一となる。x2は、x1に示される図を引用して説明する場合の説明の順序を示す。x3は、x2の構成要素をより詳細に説明するために説明図を引用する場合、その説明図の図番を示し、x4は、x3に示される図を引用して説明する場合の説明の順序を示す。
【００１６】
（第１実施形態）
[1-1_2] フラッシュメモリカード３１の外観形状
初めに、フラッシュメモリカード３１の外観形状について説明する。図１は、フラッシュメモリカード３１を上面から見た場合の形状示す図であり、図２は、フラッシュメモリカード３１をその下面から見た場合の構造を示す図である。図１、図２に示すように、フラッシュメモリカード３１の大きさは、長さが約32.0mm、幅は約24.0 mm、厚さ約2.0 mmであり、指先で把持できる程度の大きさ（切手サイズの大きさ）である。下面には、機器との接続のための9本のコネクタが設けられており、側面には、記憶内容の上書きを許可するか禁止するかを操作者が設定することができるプロテクトスイッチ３２が設けられている。
【００１７】
[3-1] フラッシュメモリカード３１の物理構造
図３は、本実施形態に係る半導体メモリカード（以下、フラッシュメモリカード３１と称する）の階層構造を示す図である。本図に示すように、フラッシュメモリカード３１の階層構造は、物理層、ファイルシステム層、応用層からなる点で、DVD（Digital Video Disc）の階層構造と同一であるが、各層における論理構造、物理構造は大きく相違する。
【００１８】
[3-2] フラッシュメモリカード３１の物理構造
先ずフラッシュメモリカード３１の物理層について説明する。フラッシュメモリは、複数のセクタからなり、各セクタは512バイトのディジタルデータを格納する。例えば64MByteタイプのフラッシュメモリカード３１の場合、そのメモリー容量は、67108864(=64×1024×1024)バイトであり、このときの有効セクタ数は131072(=67108864/512)となる。更に、この有効セクタからエラー用の代替セクタ数を差し引けば、残りの有効セクタ数は、128,000となり、ここに各種データが記録されることなる。
【００１９】
[3-2_4A-1] 物理層における3つの領域
これら有効セクタからなる領域には、図４（ａ）に示す3つの領域が設けられる。図４（ａ）は、フラッシュメモリカード３１の物理層に設けられた『システム領域』、『プロテクト領域』、『ユーザデータ領域』を示す図である。以降、これら3つの領域について説明する。
【００２０】
『ユーザデータ領域』は、フラッシュメモリカード３１と接続された機器が様々なデータを自由に書き込むことができ、データを自由に読み出すことができる領域であり、その内部領域がファイルシステムにより管理されている。
『システム領域』は、フラッシュメモリカード３１のそれぞれについてユニークな値を持つメディアIDが格納される領域である。ユーザデータ領域が書込可能であるのに対して、システム領域は、読出専用であり、ここに格納されたメディアIDを書き換えることはできない。
【００２１】
『プロテクト領域』は、ユーザデータ領域同様、データ書き込みが可能な領域である。ユーザデータ領域との差違は、ユーザデータ領域では、データの読み書きが自由に行なえるのに対して、プロテクト領域では、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１とが互いの正当性を確認した場合のみ読み書きすることができる点、即ち、フラッシュメモリカード３１と接続された機器と、フラッシュメモリカード３１との相互認証が成功した場合のみ、読み書き可能となる点である。
【００２２】
[3-2_4A-2] 物理層における3つの領域の用途
フラッシュメモリカード３１に接続された機器がフラッシュメモリカード３１にデータを書き込む際、そのデータの著作権保護の要否に応じて、これら3つの領域は利用される。ここで、著作権の保護が必要なデータをフラッシュメモリカード３１に書き込む場合、当該データは、所定の暗号鍵(FileKeyと呼ばれる。)を用いて暗号化された後にユーザデータ領域に格納される。このFileKeyは著作権者が自由に設定できるものであり、これだけでも、当該データの著作権は保護されるが、更に万全を期すため、この暗号化に用いたFileKey自身も暗号化する。FileKey自身を暗号化する際、鍵として用いられるのは、システム領域に格納されているメディアIDを所定の演算式に適用することにより得られる任意の値であり、プロテクト領域は、当該任意の値を用いて暗号化されたFileKeyを格納する。著作権保護が必要なデータは、所定のFileKeyを用いて暗号化し、このFileKey自身もメディアIDに基づいた値を用いて暗号化するという二段階の暗号化がなされるので、不正コピーなどの著作権侵害行為は、極めて困難になる。
【００２３】
[3-2_4B-1] ファイルシステムの概要
フラッシュメモリカード３１の物理層の構成は以上説明した通りであり、著作権保護の改良がなされていることがわかる。続いてこの物理層上に存在するファイルシステム層の構成について説明する。
DVDのファイルシステム層は、UDF(universal disk format)型のファイルシステムであるの対して、フラッシュメモリカード３１のファイルシステム層は、FAT型のファイルシステム（FAT:File Allocation Table,ISO/IEC 9293）であり、この点がDVDと異なる。
【００２４】
図４（ｂ）は、ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。図４（ｂ）においてファイルシステムにおけるプロテクト領域及びユーザデータ領域は、『パーティションブートセクタ』と、『ファイルアロケーションテーブル(FAT)』と、『ルートディレクトリエントリ』と、『データ領域』とを含んでおり、プロテクト領域とユーザデータ領域は共に同じ構成となっていることがこの図からも明らかである。図５は、これらファイルシステム構成の詳細を示す図である。以降、ユーザデータ領域についての構成を図４、図５を参照しながら説明する。
【００２５】
[3-2_4B-2] パーティションブートセクタ
『パーティションブートセクタ』は、フラッシュメモリカード３１が汎用パーソナルコンピュータに装填され、当該汎用パーソナルコンピュータのオペレーティングシステムの起動ディスクにフラッシュメモリカード３１を割り当てられた場合、汎用パーソナルコンピュータがブート時に参照すべき内容が記載されているセクタである。
【００２６】
[3-2_4B-3_5] データ領域
『データ領域』は、クラスタを最小単位にして、フラッシュメモリカード３１に接続された機器によりアクセスされる領域である。フラッシュメモリカード３１のセクタサイズが512バイトであるのに対して、クラスタサイズは、16Kバイトであるので、ファイルシステム層では32個のセクタを一単位として、データの読み書きが行われる。クラスタサイズを16Kバイトとした理由は、以下の通りである。即ち、フラッシュメモリカード３１にデータを書き込む場合、当該フラッシュメモリカード３１に格納されているデータを一旦イレーズ(消去)してから、データ書き込みを行わねばならない。フラッシュメモリカード３１において、そのようにデータをイレーズできるサイズは、16Kバイトであるので、このイレーズ可能なサイズにクラスタサイズを設定することにより、データ書き込みが好適に行われるようにしている。図５における破線の引き出し線ff2は、データ領域に含まれる複数のクラスタ002,003,004,005・・・・・を示す。図中の番号002,003,004,005,006,007,008・・・・・・・は、各クラスタを識別するために付与された3桁の16進数表記のクラスタ番号を示す。データ領域に対するアクセスは、クラスタを最小単位として行われるので、データ領域の内部位置は、これらのクラスタ番号を用いて、指示される。
【００２７】
[3-2_4B-4_5] ファイルアロケーションテーブル
『ファイルアロケーションテーブル』は、ISO/IEC 9293に準拠したファイルシステム構造を有しており、複数のFAT値からなる。各FAT値は各クラスタに対応づけられており、対応するクラスタが読み出された場合、次にどのクラスタを読み出せばよいかを示す。図５の破線の引き出し線ff1は、ファイルアロケーションテーブルに含まれる複数のFAT値002,003,004,005・・を示す。このFAT値に付与された数値『002,003,004,005・・』は、各FAT値がどのクラスタに対応づけられているか、つまり、各FAT値が対応づけられているクラスタのクラスタ番号を示す。
【００２８】
[3-2_4B-5_5-1] ルートディレクトリエントリ
『ルートディレクトリエントリ』は、ルートディレクトリにどのようなファイルが存在するかを示す情報である。具体的にいうと、ルートディレクトリエントリーには、存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記載されている。
【００２９】
[3-2_4B-5_5-2] サブディレクトリのディレクトリエントリ
ルートディレクトリにあるファイルについての情報は、このルートディレクトリエントリーに記載されるが、サブディレクトリについての情報は、このルートディレクトリエントリーには記載されない。サブディレクトリについてのディレクトリエントリーは、データ領域内に作成される。図５のデータ領域内に記載されたSD_Audioディレクトリエントリーは、サブディレクトリについてのディレクトリエントリーの一例であり、本SD_Audioディレクトリエントリーは、ルートディレクトリエントリー同様、そのサブディレクトリに存在するファイルの『ファイル名』と、そのファイルの『拡張子』と、『ファイル属性』と、ファイルの『更新時刻及び年月日』と、ファイルの先頭部が格納されている『ファイル最初のクラスタ番号』とが記述される。
【００３０】
[3-2_4B-5_6-1] AOBファイルの格納方式
ここで、SD_AudioディレクトリにAOB001.SA1というファイルを格納する場合、AOB001.SA1がどのように格納されるか、即ち、ファイル格納方式の一例を図６を参照しながら説明する。上述したようにデータ領域の最小アクセス単位はクラスタであるので、AOB001.SA1は、クラスタサイズを最小単位にしてデータ領域に格納せねばならない。AOB001.SA1は、先ずクラスタサイズに分割されて、各クラスタに書き込まれる。図６は、AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【００３１】
[3-2_4B-5_7-1] AOBファイルの格納方式
AOB001.SA1が分割格納されると、ディレクトリエントリー及びファイルアロケーションテーブルは、図７のように設定されねばならない。
図７は、AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。本図においてAOB001.SA1の先頭部分がクラスタ003に記録されている場合、SD_Audioディレクトリエントリーにおける『最初のクラスタ番号』には、その先頭部分が格納されているクラスタについてのクラスタ番号003が記載される。以降、AOB001.SA1の後続する部分は、クラスタ004、クラスタ005に格納されていることがわかる。AOB001.SA1の先頭部分を格納しているクラスタ003には、FAT値003(004)が対応しているが、このFAT値は、AOBファイルの後続する部分を格納しているクラスタ004を示すものである。またこれに後続している部分を格納しているクラスタ004,005には、FAT値004(005),FAT値005(00A)が対応しているが、これのFAT値は、AOBファイルの次の後続する部分を格納しているクラスタ005,00Aを示すものである。
【００３２】
これらFAT値に記載されたクラスタ番号を矢印fk1,fk2,fk3,fk4,fk5・・・・・に示すように順次読みとってゆけば、AOB001.SA1の分割部分を全て読み取ることができる。以上の説明により、フラッシュメモリカード３１のデータ領域は、クラスタを最小単位としてアクセスされ、また各クラスタにはそれぞれFAT値が対応づけられていることがわかる。尚、AOBファイルの末尾の部分を格納したクラスタ(図７の一例では、クラスタ00C)に対応づけられているFAT値には、そのクラスタがファイルの最終部分を格納していることを示すクラスタ番号『FFF』が記述される。
【００３３】
以上で、本発明のフラッシュメモリカード３１のファイルシステムに関する説明を終え、続いて、上述したファイルシステム上に存在する応用層の構成について説明する。
[3-3] フラッシュメモリカード３１における応用層の概要
フラッシュメモリカード３１における応用層の概要は、図３に記載された通りである。図３における破線の引き出し線PN1に示すようにフラッシュメモリカード３１における応用層は、プレゼンテーションデータと、プレゼンテーションデータの再生を制御するためのナビゲーションデータとからなる。
【００３４】
本図の破線の引き出し線PN2に示すように、プレゼンテーションデータは、音楽等の音声データをエンコードすることにより得られたオーディオオブジェクト群(AOB群)を含み、ナビゲーションデータは、プレイリストマネージャー(PlaylistManager(PLMG))と、トラックマネージャー(Track Manager(TKMG))とを含む。
[3-3_8A,B-1] ディレクトリ構成
図８（ａ）、（ｂ）は、応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。本図における『SD_AUDIO.PLM』、『SD_AUDIO.TKM』は、プレイリストマネージャー(PlaylistManager(PLMG))、トラックマネージャー(Track Manager(TKMG))といったナビゲーションデータを収録したファイルであり、『AOB001.SA1』『AOB002.SA1』『AOB003.SA1』『AOB004.SA1』・・・・・は、プレゼンテーションデータであるオーディオオブジェクトを格納したファイル（以下、AOBファイルという）である。
【００３５】
『AOB0xx.SA1』における拡張子『SA』は、『Secure Audio』の略であり、これらの格納内容は、著作権保護の必要性があることを示す（尚、図８（ａ）にはAOBファイルが8個だけ記述されているが、これは単なる一例であり、SD_AudioディレクトリはAOBファイルを最大999個まで格納することができる。）。このようにプレゼンテーションデータに著作権保護の必要性がある場合、プロテクト領域には、SD_Audioディレクトリという名称のサブディレクトリが設けられ、そのSD_Audioディレクトリの配下に暗号鍵格納ファイルAOBSA1.KEYが作成される。図８（ｂ）は、SD_Audioの下に格納された暗号鍵格納ファイルAOBSA1.KEYを示す図である。暗号鍵格納ファイルAOBSA1.KEYには、複数の暗号鍵FileKeyを所定の順序に配列してなる暗号鍵列であるFileKey#1〜#8が格納されている。
【００３６】
電子音楽配信において音楽会社のサーバコンピュータは、この図８（ａ）、（ｂ）に示すSD_Audioディレクトリを保持しており、当該音楽コンテンツの購入要求が消費者から発せられれば、このSD_Audioディレクトリを圧縮し、暗号化した後、購入要求を発した消費者が所有するSD_Audioディレクトリを公衆ネットワークを介して送信する。消費者が所有するコンピュータがこのSD_Audioディレクトリを受信すると、このディレクトリの暗号化を解除すると共に、伸長を行い、SD_Audioディレクトリを得る（尚、ここでいう公衆ネットワークは、ISDN回線等の有線通信網、携帯電話に代表される無線通信網等、公衆に利用が解放されている全てのネットワークを含む）。尚、AOBファイルを音楽会社のサーバコンピュータからダウンロードし、消費者が所有するコンピュータが、フラッシュメモリカード３１においてこの図８（ａ）、（ｂ）に示すSD_Audioディレクトリを作成しても良い。
【００３７】
[3-3_9-1] AOBSA1.KEYと、AOBファイルとの対応
図９は、SD_Audioの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。本図においてユーザデータ領域における暗号化ファイルを暗号化する際に用いたFileKeyは、プロテクト領域に対応する暗号鍵格納ファイルに格納される。
【００３８】
暗号化されたAOBファイルと、暗号鍵格納ファイルとは、以下の一定の規則(1)(2)(3)に基づく対応関係を有する。
(1)暗号鍵格納ファイルは、暗号化されたファイルが格納されているディレクトリと同じディレクトリ名に配置される。図９のユーザデータ領域においてSD_AudioディレクトリにAOBファイルが配されており、暗号鍵格納ファイルもSD_Audioディレクトリに配されていることからも、この規則に従った、ファイル配置が行われていることがわかる。
【００３９】
(2)暗号鍵格納ファイルには、データ領域におけるAOBファイルのファイル名の先頭3文字と、所定の拡張子「.key」とを組み合わせたファイル名が付与される。AOBファイルのファイル名が『AOB001.SA1』である場合、暗号鍵格納ファイルには、矢印nk1,nk2に示すように、この先頭３文字『AOB』と、『SA1』と、拡張子『.key』とからなる『AOBSA1.KEY』というファイル名が付与されることがわかる。
【００４０】
(3) AOBファイルのファイル名には、暗号鍵格納ファイル内の暗号鍵列において、そのオーディオオブジェクトに対応するFilekeyが何番目に位置するか、即ち、対応するFileKeyの順位を示すシリアル番号が付与される。
図９における暗号鍵格納ファイル内の『File Key Entry#1,#2,#3・・・・・#8』は、暗号鍵格納ファイル内の各FileKeyが格納されている領域の先頭位置を示す。一方AOBファイルのファイル名には、"001","002","003","004"といったシリアル番号が付与されている。これらのAOBファイル内のシリアル番号は、対応するFileKeyが暗号鍵列において何番目に位置するかを意味するので、各AOBファイルを暗号化する際に用いたFileKeyは、同一のシリアル番号を有する『File Key Entry』に存在することなる。図９における矢印AK1,AK2,AK3は、AOBファイルとFileKeyとの対応関係を示す。即ち、ユーザデータ領域におけるAOB001.SA1は『File Key Entry#1』に格納されているFileKeyと対応しており、AOB002.SA1は、『File Key Entry#2』以降に格納されたFileKey、AOB003.SA1は『File Key Entry#3』以降に格納されたFileKeyに対応していることを示す。以上の(3)からもわかるように、AOBファイルの暗号化に用いたFileKeyは、各ファイル毎に異なるものであり、それらは、ファイル名に組み込まれている"001","002","003","004"といったシリアル番号と、同一のシリアル番号を有する『File Key Entry』に格納されている。各AOBファイルは異なるFileKeyを用いて暗号化されるので、仮に、特定のAOBファイルの暗号化キーが暴露された場合でも、他のAOBファイルは、暴露されたFileKeyを用いても暗号化を解除することはできない。これにより、AOBファイルを暗号化した際のFileKeyが暴露された場合の損害を最小限に留めることができる。
【００４１】
[3-3_10-1] AOBファイルの内部構成
続いてAOBファイルの内部構成について説明する。図１０は、AOBファイルのデータ構成を階層的に示す図である。本図の第１段目は、AOBファイルを示し、第２段目は、AOBを示す。第３段目は、AOB_BLOCKを示し、第４段目はAOB_ELEMENT、第５段目は、AOB_FRAMEを示す。
【００４２】
図１０の第５段目における『AOB_FRAME』は、AOBを構成する最小単位であり、ADTSヘッダと、ADTS（Audio Data Transport Stream）形式のオーディオデータとからなる。ADTS形式のオーディオデータは、MPEG2-AAC [ Low Complexity Profile]にて符号化され、16Kbps〜144Kbpsの伝送速度で再生されるストリームデータである（尚、既存のコンパクトディスクに記録されるPCMデータの伝送速度は1.5Mbpsであるので、PCMデータと比較して、一段と低いことがわかる。）。これらのAOB_FRAME列のデータ構造は、電子音楽配信にて配信されるオーディオデータトランスポートに含まれるオーディオフレーム列と同一である。即ち、AOB_FRAME列として格納されるべきオーディオデータトランスポートストリームは、MPEG2-ACCにてエンコードされ、更に暗号化された状態で、公衆ネットワークを伝送し、消費者宛に伝送される。AOBファイルは、そのように伝送されたオーディオデータトランスポートストリームを、AOB_FRAME列として分割して格納しているのである。
【００４３】
｛3-3_10-1_11｝MPEG2-AACについて
MPEG2-AACの詳細に関しては、ISO/IEC 13818-7:1997(E) Information technology - Generic coding of moving pictures and associated audio information- Part7 Advanced Audio Coding (AAC)を参照されたい。ここで注意すべきは、AOBは、ISO/IEC13818-7に記述されているパラメータ表を図１１（ａ）のように制限して適用されたMPEG2-AAC方式にて圧縮されている点である。図１１（ａ）は、ISO/IEC13818-7に記述されているパラメータ表を示す図であり、Parameter欄と、Value欄と、Comment欄の内容を示すコメント欄とからなる。
【００４４】
パラメータ欄『profile』は、ISO/IEC 13838-7で規定されているLC-profileの制限が適用されていることを示す。
パラメータ欄『sampling_frequency_index』は、『48kHz,44.1kHz,32kHz,24kHz,22.05kHZ,16kHz』といったサンプリング周波数が適用されていることを示す。パラメータ欄『number_of_data_block_in_frame』は、1header/1raw_data_blockに設定されていることを示す。
【００４５】
尚、AOB_FRAMEは、MPEG-AAC方式にて符号化されているものとして説明したが、AOB_FRAMEは、MPEG-Layer3(MP3)方式、Windows（登録商標） Media Audio(WMA方式等他の符号化方式にて符号化されてもよい。この際、図１１（ａ）に示したパラメータの代わりに、図１１（ｂ）、図１１（ｃ）に示すパラメータ表を用いねばならない。
【００４６】
[3-3_10-2_12] AOB_FRAMEの構成
『AOB_FRAME』は、以上の制限下で符号化されたオーディオデータを含むが、AOB_FRAMEに含まれるオーディオデータのデータ長は、その再生時間が20ミリ秒となるデータに過ぎない。しかし、MPEG2-AAC方式は可変長符号化方式であるので、各AOB_FRAMEに含まれるオーディオデータのデータ長は、それぞれのAOB_FRAME毎に異なる。以下、図１２を参照しながら、AOB_FRAMEの構成の詳細について説明する。本図の第１段目は、AOB_FRAMEの全体構成を示し、第２段目は、AOB_FRAMEのそれぞれの部位がどのように暗号化されているかを示す。この第２段目を参照すれば、ADTSヘッダは、非暗号化部、即ち、暗号化がなされていないことがわかる。また、オーディオデータは、暗号化された部分と、非暗号化部分との双方を含む。暗号化部分は、8バイトの暗号化データを複数配したものである。8バイトの暗号化データは、64ビットの元データを56ビットのFileKeyを用いて暗号化することにより生成されている。非暗号化部分は、そのように64ビット単位に暗号化が行われた際、64ビットに満たないために暗号化されずに残したものである。
【００４７】
第３段目は、非暗号化部分であるADTSヘッダの内容を示す図である。ADTSヘッダは7バイトであり、12ビットの同期ワード(FFFと設定されている)と、同じAOB_FRAMEに含まれるオーディオデータのデータ長と、そのオーディオデータをエンコードする際のサンプリング周波数とが記載されている。
[3-3_10-3_13] AOB_FRAMEのバイト長設定
図１３は、3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。本図において、AOB_FRAME#1に含まれるオーディオデータ#1のデータ長はx1、AOB_FRAME#2に含まれるオーディオデータ#2のデータ長はx2、AOB_FRAME#3に含まれるオーディオデータ#3のデータ長はx3であり、x1,x2,x3というようにそれぞれのデータ長が互いに異なる場合、AOB_FRAME#1に含まれるADTSヘッダには、データ長x1が記載され、AOB_FRAME#2に含まれるADTSヘッダには、データ長x2、AOB_FRAME#3に含まれるADTSヘッダには、データ長x3が記載される。オーディオデータそのものは、暗号化されているが、ADTSヘッダ自体は暗号化されていないので、各AOB_FRAMEにおけるADTSヘッダから、オーディオデータのデータ長を読み取ってゆけば、後続するAOB_FRAMEがどこから存在するかを知得することができる。以上でAOB_FRAMEについての説明を終える。
【００４８】
[3-3_10-4] AOB_ELEMENTについて
続いて図１０において第４段目に位置するAOB_ELEMENTについて説明する。
『AOB_ELEMENT』は、連続する複数のAOB_FRAMEの集合である。ここで、どれだけの数のAOB_FRAMEがAOB_ELEMENTに含まれるかは、図１１（ａ）に示したsampling_frequency_indexの設定と、符号化方式とに従って変化する。即ち、AOB_ELEMENTに含まれるAOB_FRAMEの個数は、そのAOB_ELEMENTに含まれるAOB_FRAMEの再生時間が大体2秒になるように定められており、サンプリング周波数と、符号化方式に応じて、異なる個数となる。
【００４９】
[3-3_10-5_14] AOB_ELEMENTに含まれるAOB_FRAME数
図１４は、sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。本図においてNはAOB_ELEMENTの再生期間を秒単位に示したものであり、符号化方式がMPEG-AAC方式であれば"2"となる。またsampling_frequencyが48kHzである場合、AOB_ELEMENTに含まれるフレーム数は、94(=47×2)個となり、sampling_frequencyが44.1kHzである場合、AOB_ELEMENTに含まれるフレーム数は86(=43×2)個、sampling_frequencyが32kHzである場合、AOB_ELEMENTに含まれるフレーム数は64(=32×2)個、sampling_frequencyが24kHzである場合、フレーム数は48(=24×2)個、sampling_frequencyが22.05kHzである場合、AOB_ELEMENTに含まれるフレーム数は44(=22×2)個、sampling_frequencyが16kHzである場合、AOB_ELEMENTに含まれるフレーム数は32(=16×2)個となる。但し、AOBを分割などの編集を行った場合、AOBの先頭と最後のAOB_ELEMENTのAOB_FRAME数は、図１４の個数より少なくなる場合がある。
【００５０】
AOB_ELEMENTには、ヘッダ等の特別な情報は付与されていないが、その代わりにそのデータ長がタイムサーチテーブルに示されている。
[3-3_10-6_15] AOB_ELEMENT及びAOB_FRAMEの時間長の一例
図１５は、AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。本図の第１段目は、複数AOB_BLOCKの並びであり、第２段目は、複数AOB_ELEMENTの並びを示す。第３段目は、複数AOB_FRAMEの並びを示す。
【００５１】
本図を参照すると、AOB_ELEMENTは、約2.0秒という再生時間長に相当し、本図におけるAOB_FRAMEは、20msecという再生時間長に対応することが判る。AOB_ELEMENTのそれぞれに付されている『TMSRT_entry』という文字列は、各AOB_ELEMENTのデータ長がタイムサーチテーブルに記載されていることを示す。このようなTMSRT_entryを参照して、順方向サーチ再生、逆方向サーチ再生を行うことにより、例えば2.0秒をスキップして、240ミリ秒分だけ再生するという間欠な再生を実現することができるのである。
【００５２】
[3-3_10-7] AOB_BLOCKについて
以上でAOB_ELEMENTについての説明を終え、続いてAOB_ELEMENTの上位、即ち、図１０のAOBファイルのデータ構成を示す図における第３段目に位置するのAOB_BLOCKについて説明する。
『AOB_BLOCK』は、有効なAOB_ELEMENTからなる領域であり、AOBファイル中に一つ存在する。AOB_ELEMENTが2秒という再生時間に相当するのに対して、AOB_BLOCKは8.4分の再生時間を上限とした再生時間に相当する。各AOBを8.4分の再生時間に限定した理由は、AOB_BLOCKに含まれるAOB_ELEMENTの個数を制限することにより、タイムサーチテーブルのサイズを504バイト以下に抑制するためである。
【００５３】
[3-3_10-8] タイムサーチテーブルの抑制
以下、再生時間の限定により、タイムサーチテーブルの抑制が可能となった理由を詳細に説明する。
順方向サーチ再生、逆方向サーチ再生の再生を行う際、2秒分読み出しをスキップして240ミリ秒だけ再生するという『2秒スキップ240ミリ秒再生』が行われる。このように2秒という時間長をスキップする場合、原則として、AOB_FRAMEのADTSヘッダに示されているデータ長を順次参照してゆけばよいのだが、その場合、2秒という時間間隔をスキップするために100個(=2秒／20ミリ秒)ものAOB_FRAMEを順次検出せねばならず、再生装置に余分な処理負荷を与えてしまう。そのような処理負荷を軽減するには、その2秒間隔の読出先アドレスをタイムサーチテーブルに記述して、順方向サーチ再生及び逆方向サーチ再生が命じられた際、再生装置がこれを参照すればよい。即ち、タイムサーチテーブルには、2秒先、4秒先の読出先アドレスを算出するための情報、具体的には、各AOB_ELEMENTについてのデータ長を記述しておき、再生装置は、これを参照して、順方向サーチ再生-逆方向サーチ再生を行えばよいのである。2秒に相当するデータ長がどの程度になるかについて考察する。オーディオデータの再生時のビットレートは、上述したように16Kbps〜144Kbpsの範囲であるので、2秒当たりに再生されるデータ長は4Kbyte(=16Kbps×2／8)〜36Kbyte(=144Kbps×2/8)となる。
【００５４】
2秒当たりのデータ長が4Kbyte〜36Kbyteであるなら、オーディオデータのデータ長が記述されるためのタイムサーチテーブル内のエントリーのデータ長は、2バイト(16ビット)必要となる。何故なら、エントリーに16ビット長を割り当てたならば、0〜64KByteの数値が記述されることができるからである。一方、タイムサーチテーブルの総データサイズを例えば504バイト(これは後述するTKTMSRTのデータサイズである)内に制限する場合を考えると、このタイムサーチテーブル内に設けるべきエントリーは、252(=504/2)個に制限せねばならない。上述したように、エントリーは、2秒毎に設けられるものであるので252エントリーに対応する再生時間は、504秒(=2秒×252)となり、8分24秒(=8.4分)となる。このようにAOB_BLOCKにおける再生時間を8.4分以下に制限したことにより、タイムサーチテーブルのデータサイズを504バイト以下とすることができる。
【００５５】
[3-3_10-9] AOBについて
以上でAOB_BLOCKについての説明を終え、続いてAOBについて説明する。
図１０の第２段目に位置するAOBは、AOB_BLOCKの前後に無効領域が付与された領域であり、AOBファイル中に一つ存在する。
この無効領域は、当該、AOB_BLOCKと同じクラスタに格納され、当該AOB_BLOCKと供に読み書きされる領域である。AOBにおいて、何処から何処までがAOB_BLOCKに該当するのかは、ナビゲーションデータに含まれるBIT(その詳細についての説明は、後段で行う。)にて指定される。
【００５６】
以上で、各AOBファイルにどのようなデータが格納されているかが明らかとなった。続いて、図９に示した8つのAOBファイルに含まれるAOB、AOB_BLOCKが連続して読み出されることにより、どのような内容が再生されるかを説明する。
[3-3_10-10_16]
図１６は、AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す。第１段目は、ユーザデータ領域における8つのAOBファイルを示し、第２段目は、各AOBファイルに収録されている8つのAOBを示す。第３段目は、それぞれのAOBに含まれる8つのAOB_BLOCKを示す。
【００５７】
第５段目は、5つのコンテンツ部からなるタイトルを示す。5つのコンテンツ部は、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれを示し、タイトルは、これら5つの曲（コンテンツ）からなる音楽アルバムを示す。破線AS1,AS2,AS3・・・・AS7,AS8は、音楽アルバムの分割部分と、AOB_BLOCKとの対応関係を示し、第４段目は、第５段目の音楽アルバムがどのような単位で分割されるかを示す。
【００５８】
これらの破線を参照すると、各AOB_1に含まれるAOB_Blockは、6.1分という時間にて再生される曲(SongA)であり、各AOB_2に含まれるAOB_Blockは、3.3分という時間にて再生される曲(SongB)、各AOB_3に含まれるAOB_Blockは、5.5分という時間にて再生される曲(SongC)である。以上のようにAOB001.SA1〜AOB003.SA1は、それぞれが独立した曲に対応するものであることがわかる。第６段目は、TrackA〜Eからなるトラックシーケンスを示す。これらTrackA〜Eは、SongA、SongB、SongC、SongD、SongEという5つの曲のそれぞれと1対1に対応しており、一個の独立した再生単位として扱われる。
【００５９】
一方、AOB_4は、30.6分という時間にて再生される曲(SongD)の先頭部分であり、8.4分という再生時間にて再生される。AOB_5、AOB_6に含まれるAOB_BLOCKはSongDの中間部分であり、8.4分という再生時間、AOB_7に含まれるAOB_BLOCKは、SongDの終端部分であり、5.4分という再生時間にて再生される。このように30.6分という再生時間を有する曲は、(8.4分+8.4分+8.4分+5.4分)という単位で分割され、各AOBに含まれていることがわかる。この図からも理解できるように、AOBファイルに含まれる全ての曲は、再生時間長が8.4分という時間長以内に収められていることがわかる。
【００６０】
以上の説明によりAOBの再生時間長を制限することにより、各AOBに対応づけられているタイムサーチテーブルのデータサイズも制限されていることが明らかとなった。続いて、このタイムサーチテーブルを含むナビゲーションデータについて説明する。
[3-3_8A,B-2]
ナビゲーションデータは、『SD_Audio.PLM』『SD_Audio.TKM』という2つのファイルからなることは既に述べた通りである。ファイル『SD_Audio.PLM』は、プレイリストマネージャ(Playlistmanager)を含み、ファイル『SD_Audio.TKM』は、トラックマネージャ(TrackManager)を含む。
【００６１】
プレゼンテーションデータの説明で述べたように、複数のAOBファイルは、符号化されたAOBを収録しているが、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等は何等記載されていない。一方、複数のAOBは、複数のAOBファイルに収録されているのみなので、それらをどのような順序で再生させるかは一切記載されていない。トラックマネージャ、プレイリストマネージャーは、こういった情報を再生装置に通知するために設けられている。
【００６２】
ここでトラックマネージャーは、AOBファイルに収録されているAOBと、トラックとの対応関係を示し、これらのAOBの再生時間がどれだけであるか、また、それぞれのAOBがどのような曲名であり、作曲者は誰であるか等の諸情報を示す複数のトラック管理情報を含む。トラックとは、ユーザにとって意味のある再生単位であり、フラッシュメモリカード３１に音楽著作物を格納しようとする場合、トラックは曲に対応し、フラッシュメモリカード３１にリーディングブックを格納しようとする場合（リーディングブックとは、書籍ではなく、読み上げ音声により表現された文書著作物をいう）、ブックジャンルであるなら、トラックは、文の章／節に対応する。トラックマネージャーは、複数AOBファイルに収録されている複数のAOBをトラックの集合として管理するために設けられている。
【００６３】
プレイリストとは、トラックの複数の再生順序を規定するものであり、プレイリストマネージャーは、このようなプレイリストを複数含んでいる。
以降、トラックマネージャーについて図面を参照しながら説明する。
[17-1_18] Playlistmanager及びTrackManagerの詳細構成
図１７は、実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図であり、図１８は、PlayListManager及びTrackManagerのサイズを示す図である。即ち、本図において右段に位置する論理フォーマットは、その左段に位置する論理フォーマットを詳細化したものであり、破線に示す引き出し線は、右段の論理フォーマットがその左段の論理フォーマット内のどの部分を詳細化したかを明確にしている。
【００６４】
このような表記に従って図１７におけるTrackManagerの構成を参照すると、TrackManagerは、破線の引き出し線h1に示すように、Track Information(TKIと略す)#1,#2,#3,#4・・・・・#nからなる。これらのTKIはAOBファイルに収録されているAOBを、トラックとして管理するための情報であり、各AOBファイルに対応している。
【００６５】
図１７を参照すると各TKIは、破線の引き出し線h2に示すように、Track_General_Information(TKGI) 、TKIに固有なテキスト情報が記述されるTrack_Text_Information_Data_Area(TKTXTI_DA)、タイムサーチテーブルの役割を有するTrack_Time_Serch_Table(TKTMSRT)からなることがわかる。図１８を参照すると、TKI自体は固定サイズ（1024バイト）であり、TKGIとTKTXTI_DAとは合計で512バイト固定長であることがわかる。TKTMSRTも512バイト固定長である。またTrackManagerにおいて、TKIは、最大999個まで設定することができる。
【００６６】
このTKTMSRTは、破線の引き出し線h3に示すように、TMSRT_Headerと、TMSRT_etry#1,#2,#3・・・・・#nとからなることがわかる。
[17-2_19] TKIと、AOBファイル及びAOBとの相互関係
図１９は、図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。図１９の第１段目における四角枠はTrackA〜Eとからなるトラックシーケンス、図１９の第２段目における四角枠はTrackManagerを示し、第３、第４段目は図１６に示した8つのAOBファイルを示す。第５段目における8つの枠は、8つのAOBを示す。この8つのAOBファイルは、図１６に示した8つのAOBを収録していたものであり、TrackA、TrackB、TrackC、TrackD、TrackEを含む音楽アルバムを形成している。第２段目は、8つのTKIを示す。これらTKIに付与された数値"1","2","3","4"は、各TKIを識別するためのシリアル番号であり、各TKIは、同じシリアル番号001,002,003,004,005・・・・・が付与されたAOBファイルと対応づけられている。この点に注意して、図１９を参照すれば、TKI#1がAOB001.SA1に対応していて、TKI#2がAOB002.SA1、TKI#3がAOB003.SA1、TKI#4がAOB004.SA1に対応していることがわかる（本図における矢印TA1,TA2,TA3,TA4・・・・・・は、各TKIがどのAOBファイルと対応しているかを示す。）。このように各TKIは、各AOBファイルに収録されているAOBと、1対1の対応関係を有するので、各TKIには、AOBに固有な情報を詳細に記載しておくことができる。
【００６７】
[17-3_20] TKTMSRTのデータ構造について
AOBファイルに収録されているAOBに固有な情報として、先ず初めにTKTMSRTについて説明する。図２０は、図１７に示したTKTMSRTの詳細なデータ構造を示す図である。本図の右側には、タイムサーチテーブルヘッダ(TMSRT_Header)の詳細なデータ構造が示されている。図２０において、タイムサーチテーブルヘッダのデータサイズは8バイトであり、TMSRT_ID(0バイト目から1バイト目まで)、reserved(2バイト目から3バイト目まで)、Total TMSRT_entry_Number(4バイト目から7バイト目まで)という3つのフィールドを有する。『TMSRT_ID』には、TMSRTを一意に識別できるIDが記述される。『Total TMSRT_entry Number』には、当該TMSRT内にあるTMSRT_entryの総数が記述される。
【００６８】
[17-3_21-1] TKTMSRTの具体例について
続いてTKTMSRTについてより詳細に説明する。図２１は、TKTMSRTについての一例を示す図である。本図の左側に、AOBを示し、右側にTKTMSRTを示す。本図左側のAOBは、複数のAOB_ELEMENT#1,#2,#3・・・・・・#nからなり、その右側における複数の領域AR1,AR2,AR3・・・・・・ARnを占有している。また図中の『0』『32000』『64200』『97000』『1203400』『1240000』といった数値は、AOBに含まれるAOB_BLOCK先頭からの各AOB_ELEMENTの占有領域AR1,AR2,AR3,ARn-1,ARnまでの相対アドレスを示す。AOB_ELEMENT#2は、AOB_BLOCK先頭から『32000』だけ隔てられた位置に記録されていることを示す。AOB_ELEMENT#3は、AOB_BLOCK先頭から『64200』だけ隔てられた位置に、AOB_ELEMENT#n-1は、AOB_BLOCK先頭から『1203400』だけ隔てられた位置に記録されていることを示す。
【００６９】
注意すべきは、各占有領域の先頭アドレスの間隔が一定値ではないこと、即ち、各AOB_ELEMENTの占有領域が、それぞれ異なるサイズだけ複数クラスタを占有していることである。各占有領域のサイズがそれぞれ異なるのは、各AOB_FRAMEにおける符号割り当てが可変長だからである。
各AOB_ELEMENTの占有サイズが異なるので、各AOB_ELEMENTの先頭にジャンプする場合、各AOB_ELEMENTがAOB内の何処に存在するかを予め再生装置に指示しておく必要がある。このような目的をもって、複数のTMSRT_entryは記載されている。矢印RT1,RT2,RT3・・・・・・RTn-1,RTnは、これら各AOB_ELEMENTの占有領域AR1,AR2,AR3・・・・・・ARn-1,ARnと、TMSRT_entry#1、TMSRT_entry#2、TMSRT_entry#3・・・・・・TMSRT_entry#n-1,TMSRT_entry#nとの対応関係を示す。即ち、AOB_ELEMENT#1の占有領域AR1がどれだけのサイズを占有しているかがTMSRT_entry#1に記載され、AOB_ELEMENT#2、AOB_ELEMENT#3の占有領域AR2,AR3がどれだけのサイズを占有しているかがTMSRT_entry#2、TMSRT_entry#3に記載される。
【００７０】
ここで、占有領域AR1は、AOBの先頭から、AOB_ELEMENT#2の先頭『32000』迄を占有しているので、TMSRT_entry#1は32000(=32000-0)と記述され、占有領域AR2は、AOB_ELEMENT#1の先頭『32000』から、AOB_ELEMENT#2の先頭『64200』迄を占有しているので、TMSRT_entry#2は『32200(=64200-32000)』と記述、占有領域AR3は、AOB_ELEMENT#3の先頭『64200』から、AOB_ELEMENT#4の先頭『97000』迄を占有しているので、TMSRT_entry#3は『32800(=97000-64200)』、占有領域ARn-1は、AOB_ELEMENT#n-1の先頭『1203400』から、AOB_ELEMENT#nの先頭『1240000』迄を占有しているので、TMSRT_entry#n-1は『36600(=1240000-1203400)』と記述されている。
【００７１】
[17-3_21-2] TKTMSRTの読み出し方式
このようにタイムサーチテーブルには、AOB_ELEMENTのデータサイズが記載されていることがわかる。一方、AOB_ELEMENTの説明で述べたように、各AOB_BLOCKのデータ長は、再生時間が8.4分内になるように定めらているので、1つのAOBに含まれるAOB_ELEMENTの総数は、所定数(図２０に示す252個)以下に抑えられている。AOB_ELEMENT数が所定数以下に抑えられるので、AOB_ELEMENTに対応するTMSRT_entryの総数も所定数以下となり、これらを含むTKTMSRTのデータサイズも所定サイズ以下となる。TKTMSRTのサイズを抑制したため、再生装置は、以下のようにTKIを読み出して、利用することができる。
【００７２】
あるAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、メモリに格納する。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。当該AOBの再生が終われば、これに後続するAOBが読み出されて、その再生が開始されると、それに対応するTKIを読み出して、それまでメモリ上に格納されていたTKIを、新たに読み出されたTKIを用いて上書きする。以降、当該AOBの再生が継続している期間において、このTKIをメモリに格納しておく。
【００７３】
TKIの読み出しと、メモリへの格納とをこのように行えば、再生装置におけるメモリの実装量が小規模であっても、必要なTKIを読み出すだけで順方向サーチ再生、逆方向サーチ再生といった特殊再生を行うことができる。尚、本実施形態では、あるAOB_ELEMENTの先頭アドレスから次のAOB_ELEMENTの先頭アドレスまでのデータ長をTMSRT_entryとして記載したが、AOB_BLOCKの先頭から、各AOB_ELEMENTの先頭までの相対アドレスを記載してもよい。
【００７４】
[17-3_21-3] AOB_ELEMENTを含むクラスタの特定
最後にTKTMSRTを参照して、任意のAOB_ELEMENTをどうやって読み出せばよいかについて説明する。各AOB_ELEMENTのサイズが記載されたTKTMSRTを参照して、AOBにおいて先頭からy番目に位置するAOB_ELEMENT#yを読み出す場合、以下の｛数式１｝を満たすクラスタuを求めて、そのクラスタuの先頭からオフセットv以降を読み出せばよい。
｛数式１｝
クラスタu = (AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset)／クラスタサイズ
オフセットv =(AOB_ELEMENT#1からAOB_ELEMENT#y-1までのTMSRT_entryの総和+DATA_Offset) mod クラスタサイズ
c =a mod bとある場合、cは、aをbで割った場合の余りを示し、DATA_Offsetは、BITに記載されている情報であり、後述する。
【００７５】
[17-4] TKTXTI_DAについて
以上で、タイムサーチマップ(TKTMSRT)の説明を終わる。次に、図１７においてTKTMSRTの上段に記載されているTrack Text Information Data Area(TKTXTI_DA)について説明する。
Track Text Information Data Area(TKTXTI_DA)には、アーティスト名、アルバム名、編曲者名、プロデューサ名等を示すテキスト情報が記述される。テキストデータが存在しない場合でも、この領域は確保される。
【００７６】
[17-5] TKGIについて
続いてTKTXTI_DAの上段にあるTKGIについて説明する。図１７においてTKIのTKGIは、破線の引き出し線h4に示すように、TKIの識別子『TKI_ID』、TKI番号『TKIN』、TKIのサイズ『TKI_SZ』、次のTKIへのリンクポインタ『TKI_LNK_PTR』、ブロック属性『TKI_BLK_ATR』、再生時間『TKI_PB_TM』、TKIのオーディオ属性『TKI_AOB_ATR』、『ISRC』、ブロック情報『BIT』という一連の情報が記録されていることがわかる（尚、本図は、説明の簡略化のため、一部のフィールドについては省略して表記している。）。
【００７７】
[17-5_22-1] TKGIについて
以下、図２２を参照しながらTKGIの詳細構成について説明する。本図と、図１７との違いは、図１７に示したTKGIのデータ構成が図中左側に配置されており、図１７では明らかにされてなかった『TKI_BLK_ATR』,『TKI_AOB_ATR』,『ISRC』のビット構成が、図中の右側に配置されている点である。
【００７８】
[17-5_22-2] TKI_IDについて
『TKI_ID』には、TKIを一意に識別できるID(本実施形態では2バイトの"A4"というコード)が記述される。
[17-5_22-3] TKINについて
『TKIN』には、1から999までの範囲のTKI番号が記述される。なお、このTKI番号は他のTKIのTKINに記述されるTKI番号と重複してはならない。このようなTKINとして、TrackManagerにおけるTKIの順位、即ち、TrackManagerにおいてTKIが何番目に位置するかを記述するものとする。本図におけるTKI#1なら、TKI番号は、"1"と記載され、TKI#2ならTKI番号は、"2"と、TKI#3ならTKI番号は、"3"と記載される。
【００７９】
[17-5_22-4] TKI_SZについて
『TKI_SZ』には、TKIのデータサイズがバイト数単位で記述される。図２２では、TKIのデータサイズが1024バイトと規定されているので、本実施形態において1024バイトと記述される。
[17-5_22-5] TKI_LNK_PTRについて
『TKI_LNK_PTR』には、当該TKIのリンク先のTKIについてのTKINが記述される。ここで、TKI間の対応関係について説明する。
【００８０】
トラックが複数のAOBから構成され、それらが複数のAOBファイルに収録されている場合、それら複数のAOBファイルに対応づけられている複数のTKIは一体となって、当該トラックを管理することになる。このように複数のTKIが一体となっている場合、これらTKIに対応するAOBファイルに、どのTKIに対応するAOBファイルが後続するかを示す必要がある。TKI_LNK_PTRは、各TKIに後続するTKIについてのTKINを記述するという用途に用いられる。
【００８１】
[17-5_22-6_19] TKI_LNK_PTRについて
以降、図１９に示した8つのTKIにおいて、TKI_LNK_PTRがどのように設定されているかについて説明する。１トラックを構成するTKI#1〜TKI#3、TKI#8において、そのTKI_LNK_PTRは設定されないが、TrackDを構成する4つのAOBファイルに対応するTKI#4、TKI#5、TKI#6、TKI#7は、各TKI_LNK_PTRが次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL4,TL5,TL6に示すように、TKI#4のTKI_LNK_PTRはTKI#5を指示しており、TKI#5のTKI_LNK_PTRはTKI#6を、TKI#6のTKI_LNK_PTRはTKI#7を指示している。これらは、何れもTrackDを構成する。4つのAOBファイルに対応づけられているTKIにおけるこれらTKI_LNK_PTRを参照することにより、TKI#4〜TKI#7という4つのTKI、及びAOB004.SA1〜AOB007.SA1という4つのAOBファイルが、一体となってTrackDを構成しているということがわかる。
【００８２】
[17-5_22-7] TKI_BLK_ATRについて
『TKI_BLK_ATR』には、TKIについての属性が記述される。図２２においてTKI_BLK_ATRから破線にて引き出された枠に、TKI_BLK_ATRのビット構成を示す。本図においてTKI_BLK_ATRは16ビットであり、b3ビットからb15ビットまでが将来の拡張のために確保されている。ビット番号b2からb0までの3ビットを用いて、TKIについての属性が記述される。
【００８３】
TKIが使用されており、１個のTKIが１個のトラックに含まれる場合、TKI_BLK_ATRには"000b"の値が記述される(以降、この設定を『Track』という。)。TKIが使用されており、１トラックが複数のTKIを含み、当該TKIがその先頭である場合は、TKI_BLK_ATRには"001b"の値が記述される（以降、この設定を『Head_of_Track』という。）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその中間である場合は、TKI_BLK_ATRには"010b"の値が記述される（以降、この設定を『Midpoint_of_Track』という）。TKIが使用されており、１トラックが複数のTKIから構成され、当該TKIがその終端である場合、TKI_BLK_ATRには"011b"の値が記述される（以降、この設定を『End_of_Track』という。）。TKIが未使用であり、TKIの領域がある場合、すなわち削除されたTKIである場合は、"100b"の値が記述される（以降、この設定を『Unused』という）。TKIが未使用であり、TKIの領域がない場合、すなわち初期状態のTKIである場合は、"101b"の値が記述される。
【００８４】
[17-5_22-8_19] TKI_BLK_ATRの設定例
図１９の一例では、それぞれのTKIについてのTKI_BLK_ATRがどのように設定されているかについて説明する。
各TKIにおけるTKI_BLK_ATRを参照すれば、TKI#1（AOB001.SA1）、TKI#2（AOB002.SA1）、TKI#3（AOB003.SA1）、TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているので、TKI#1、TKI#2、TKI#3、TKI#8のTKI_BLK_ATRは、『Track』と設定されている。
【００８５】
TKI#4におけるTKI_BLK_ATRは『Head_of_Track』と設定され、TKI#7におけるTKI_BLK_ATRは『End_of_Track』と、TKI#5、TKI#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、TKI#4と対応関係を有するTKI#4（AOB004.SA1）はトラックの先頭部と、TKI#5、TKI#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）はトラックの中間部と、TKI#7と対応関係を有するTKI#7（AOB007.SA1）はトラックの終端部であることを意味する。
【００８６】
このように各TKIにおけるTKI_BLK_ATRの記載に従って、TKI（AOBファイル）の組みを分類すれば、TKI#1（AOB001.SA1）が1つ目のトラック(TrackA)を構成していることがわかる。TKI#2（AOB002.SA1）が2つ目のトラック(TrackB)、TKI#3（AOB003.SA1）が3つ目のトラック(TrackC)を構成していることがわかる。
TKI#4（AOB004.SA1）が4つ目のトラック(TrackD)の先頭部分を構成しており、TKI#5（AOB005.SA1）、TKI#6（AOB006.SA1）がTrackDの中間部分を構成しており、TKI#7（AOB007.SA1）がTrackDの終端部分を構成していることがわかる。TKI#8（AOB008.SA1）は独立して5つ目のTrackEの終端部分を構成していることがわかる。
【００８７】
[17-5_22-9] TKI_PB_TMについて
『TKI_PB_TM』には、TKIに対応するAOBファイルに収録されているAOBにより構成されるトラック(曲)の再生時間が記述される。
トラックが複数のTKIから構成される場合、先頭のTKIについてのTKI_PB_TMには、トラック全体の再生時間が記述される。また2番目以降のTKIには、それぞれのTKIに対応するAOBの再生時間が記述される。
【００８８】
[17-5_22-10] TKI_AOB_ATRについて
『TKI_AOB_ATR』には、TKIに対応するAOBファイルに収録されているAOBがどのようなサンプリング周波数でサンプリングされているか、どのようなビットレートで転送されるか、チャネル数がどれだけであるか等、AOBを生成する際のエンコード条件が記述される。『TKI_AOB_ATR』から破線にて引き出された枠は、TKI_AOB_ATRのビット構成を示す。本図においてTKI_AOB_ATRは、20ビットであり、ビット番号b16からビット番号b19までのフィールドには、コーディングモードが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"0000b"の値が、MPEG-layer3(MP3)でエンコードされている場合には、"0001b"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"0010b"がそれぞれ記述される。
【００８９】
ビット番号b15からビット番号b8までのフィールドには、ビットレートが記述される。MPEG-2 AAC(with ADTS header)でエンコードされている場合には、"16"〜"72"の値が、MPEG1-layer3(MP3)でエンコードされている場合には"16"〜"96"の値が、MPEG2-layer3(MP3) LSFでエンコードされている場合には"16"〜"80"の値が、Windows（登録商標） Media Audio(WMA)でエンコードされている場合、"8"〜"16"の値がそれぞれ記述される。
【００９０】
ビット番号b7からビット番号b4には、サンプリング周波数が記述される。48kHzの場合は"0000b"、44.1kHzの場合は"0001b"、32kHzの場合は"0010b"、24kHzの場合は"0011b"、22.05kHzの場合は"0100b"、16kHzの場合は"0101b"の値が記述される。
ビット番号b3からビット番号b1までのフィールドには、チャネル数が記述される。1ch(mono)の場合は、"000b"が記述される。2ch(stereo)の場合は、"001b"が記述される。
【００９１】
ビット番号b31からビット番号b20、およびビット番号b0の領域は、将来の拡張用に予約されている。
[17-5_22-11] ISRCについて
『ISRC』には、TKGIにおけるISRC（International Standard Recording Code）が記述される。図２２における『ISRC』から破線にて引き出された枠はISRCの内容を示す。この枠に示されているように、ISRCは、10バイトからなり、ビット番号b4からビット番号b7までのフィールドにRecording-item code(#12)が記述され、ビット番号b8からビット番号b11までのフィールドにRecording code/Recording-item code(#11)が記述される。
【００９２】
ビット番号b12からビット番号b23までのフィールドにRecording code(ISRC#10,#9,#8)が記述される。ビット番号b24からビット番号b31までのフィールドにYear-of-Recording code(ISRC#6,#7)が記述される。
以降、ビット番号b32からビット番号b37までのフィールド、ビット番号b40からビット番号b45までのフィールド、ビット番号b48からビット番号b53までのフィールドには、First Owner Code(ISRC#3,#4,#5)が記述される。ビット番号b56からビット番号b61までのフィールド、ビット番号b64からビット番号b69までのフィールドには、Country code(ISRC#1,#2,#3)が記述される。ビット番号b79のフィールドには、1ビットのValidity flagが記述される。尚、ISRCの詳細については、ISO3901 : 1986 ''Documentation-International Standard Recording Code (ISRC) ''を参照されたい。
【００９３】
[17-5_22-12_23A-1] BITについて
『ブロック情報テーブル(BIT)』は、AOB_BLOCKを管理するテーブルである。図２３（ａ）、（ｂ）は、BITの詳細構成を示す図である。図２３（ａ）に示すように、BITは、60バイト目から63バイト目までを占めるDATA_OFFSETフィールドと、64バイト目から67バイト目までを占めるSZ_DATAフィールドと、68バイト目から71バイト目までを占めるTMSRTE_Nsフィールドと、72バイト目から73バイト目までを占めるFNs_1st_TMSRTEフィールドと、74バイト目から75バイト目までを占めるFNs_Last_TMSRTEフィールドと、76バイト目から77バイト目までを占めるFNs_Middle_TMSRTEフィールドと、78バイト目から79バイト目までを占めるTIME_LENGTHフィールドとからなる。以下、各構成要素の説明を行う。
【００９４】
[17-5_22-12_23A-2] DATA_Offsetについて
『DATA_OFFSET』には、クラスタ境界から各AOB_BLOCKの先頭までの相対アドレスがバイト単位で記述される。これにより、AOBからAOB_BLOCKまでの間に無効領域がどれだけ存在するかが表現される。AOBとしてフラッシュメモリカード３１に格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、BITにおけるDATA_Offsetを設定することにより、この不要音声をAOB_BLOCKから除外して再生させないようにすることができる。
【００９５】
[17-5_22-12_23A-3] SZ_DATAについて
『SZ_DATA』には、各AOB_BLOCKのデータ長がバイト単位で記述される。SZ_DATAとDATA_Offsetとを加算した値をAOBを収録しているファイルサイズ(クラスタサイズの整数倍)から差し引けば、AOB_BLOCKに後続する無効領域がどれだけのサイズであるかを求めることができる。
【００９６】
[17-5_22-12_23A-4] TMSRTE_Nsについて
『TMSRTE_Ns』には、各AOB_BLOCKに含まれるTMSRT_entryの総数が記述される。
[17-5_22-12_23A-5] 『FNs_1st_TMSRTE』、『FNs_Last_TMSRTE』、『FNs_Middle_TMSRTE』について
『FNs_1st_TMSRTE』には、当該AOB_BLOCK中の先頭に位置するAOB_ELEMENTに含まれるAOB_FRAME数が記述される。
【００９７】
『FNs_Last_TMSRTE』には、AOB_BLOCKの最後尾のAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
『FNs_Middle_TMSRTE』には、先頭と最後尾のAOB_ELEMENTを除くAOB_ELEMENT、即ち、AOB_BLOCKの中間部に位置するAOB_ELEMENTに含まれるAOB_FRAMEの個数が記述される。
【００９８】
『TIME_LENGTH』は、図２３（ｃ）に示すフォーマットにてAOB_ELEMENTの再生期間をミリ秒オーダーの時間精度で記述するフィールドである。図２３（ｃ）に示すように、TIME_LENGTHフィールドは、16ビット長であり、符号化方式がMPEG-AAC方式やMPEG-Layer3方式であれば、AOB_ELEMENTの再生期間は2秒となるので、TIME_LENGTHには、2000の値が記述される。
【００９９】
[17-5_22-13_23B]
図２３（ｂ）は、FNs_Middle_TMSRTEにAOB_FRAMEが幾つ格納されているかを示す図である。本図は図１４同様、sampling_frequencyと、中間部のAOB_ELEMENTに含まれるAOB_FRAME数との対応関係を示している。本図におけるsampling_frequencyと、AOB_ELEMENTに含まれるフレーム個数との対応関係は図１４と全く同一であり、サンプリング周波数に応じて異なる個数になっていることがわかる。『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』におけるフレーム数は、『FNs_Middle_TMSRTE』におけるフレーム数と原則同一のフレーム数に設定されるが、AOB_BLOCKの先頭又は末尾に位置するAOB_ELEMENTに無効領域を設定する場合、『FNs_1st_TMSRTE』及び『FNs_Last_TMSRTE』は、『FNs_Middle_TMSRTE』と異なる値となる。
【０１００】
[17-5_22-14_24] AOB_ELEMENTの格納例
図２４は、AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。AOBが図２４に示すように格納されている場合に、BITがどのように設定されるかについて説明する。これらクラスタ007〜クラスタ00Eに格納されているAOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれには、三角旗状の記号が付与されているが、これらは、AOB_ELEMENT#1〜AOB_ELEMENT#4のそれぞれに、TKIに含まれるTMSRT_entryが設定されていることを示す。
【０１０１】
この際、AOB先端におけるAOB_ELEMENT#1の先端部分は、クラスタ007に格納されており、AOB末尾におけるAOB_ELEMENT#4の終端部分は、クラスタ00Eに格納されている。AOB_ELEMENT#1〜#4は、クラスタ007の途中md0からクラスタ00Eの途中md4迄を占有している。BIT内のSZ_DATAは、矢印sd1に示すようにAOB_ELEMENT#1からAOB_ELEMENT#4の最後までを指示しており、クラスタ007,00E内の領域であって、AOB_ELEMENTにより占有されていない部分ud0,ud1を指示していない。
【０１０２】
これに対して、AOBは、クラスタ007、クラスタ00E内の領域であって、AOB_ELEMENT#1、AOB_ELEMENT#4により占有されていない部分ud0,ud1までも含んでいる。BIT内のDATA_Offsetは、非占有部分ud0のデータ長、即ち、クラスタ007の先頭から、AOB_ELEMENT#1の先頭までの相対値を指示している。
本図においてAOB_ELEMENT#1は、クラスタ007の途中md0からクラスタ008の途中md1までを占有している。このAOB_ELEMENT#1は、クラスタ008全体を占有しているのではなく、その終端部分以降は、AOB_ELEMENT#2に占有されている。AOB_ELEMENT#4は、クラスタ00Cの途中部分md3から、クラスタ00Eの途中部分md4までを占有している。このようにAOB_ELEMENTには、クラスタの境界を跨ぐように、記録されているものが存在することがわかる。つまり、AOB_ELEMENTは、クラスタの境界とは全く関係無く、記録されているのである。BIT内の『FNs_1st_TMSRTE』は、クラスタ007〜クラスタ008におけるAOB_ELEMENT#1のフレーム数を示しており、BIT内の『FNs_Last_TMSRTE』は、クラスタ00C〜クラスタ00EにおけるAOB_ELEMENT#4のフレーム数を示している。
【０１０３】
このように、各AOB_ELEMENTは、クラスタの境界に関係なく、自由に配置されており、BITにより、クラスタ境界からAOB_ELEMENTまでのオフセットや各AOB_ELEMENT毎のフレーム数が管理されていることがわかる。
[17-5_22-14_25] 各AOB_ELEMENT毎のフレーム数の利用法１
BITに記載されている各AOB_ELEMENT毎のフレーム数がどのように利用されるかを以下に説明する。BITに記載されているフレーム数は、先ず第１に、再生経過時刻を2秒スキップして、240ミリ秒だけ再生するという順方向サーチ再生、逆方向サーチ再生を行う場合に用いられる。
【０１０４】
図２５は、AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
本図は、AOB_ELEMENT#yに含まれるAOB_FRAME#xが再生されている時点において、順方向サーチ再生が指示された場合を想定して作図した図である。本図において、tは、所定の間欠再生時間(=240ミリ秒)、f(t)は、間欠再生時間に相当するフレーム数、間欠スキップ時間skip_timeは、間欠再生を行う際にスキップすべき時間長（この場合は2秒)、この間欠スキップ時間skip_timeに対応するフレーム数をf(skip_time)とする。ここで間欠再生は、以下の▲１▼▲２▼▲３▼の手順を繰り返すことにより行われる。
【０１０５】
▲１▼TKTMSRTに記載されているTMSRT_entryを参照して、旗(AOB_ELEMENT)の先頭へとジャンプする。
▲２▼240ミリ秒だけ再生を行う
▲３▼次の旗(AOB_ELEMENT)の先頭へとジャンプする。
尚、本実施形態では、240ミリ秒再生し、2秒後の箇所にジャンプし、240ミリ秒再生するという、より正確な間欠再生を実現する方法について説明する。
【０１０６】
AOB_ELEMENT#yに含まれるAOB_FRAME#xから、2秒+240ミリ秒後のAOB_FRAME#x+1は、AOB_ELEMENT#y+1内に存在する筈である。2秒+240ミリ秒後のAOB_FRAME#x+1を特定する場合、次のAOB_ELEMENT#y+1についての先頭アドレスは、TKTMSRTにおけるTMSRT_entryを読み出すことにより即座に算出することができるが、そのAOB_ELEMENT#y+1の先頭アドレスからAOB_FRAME#x+1までに介在するAOB_FRAME数は、TMSRT_entryのみでは知り得ない。そのようなAOB_FRAME数を算出するためには、AOB_FRAME#xがAOB_ELEMENT#yの先頭から何番目に位置するかを示す#xと、f(t)と、f(skip_time)との和から、AOB_ELEMENT#yに含まれる全フレーム数を差し引くことにより求める必要がある。そのように、次のAOB_ELEMENT#y+1におけるAOB_FRAME#x+1の相対フレーム位置を簡易に算出するため、BITに各AOB_ELEMENTについての『FNs_1st_TMSRTE』、『FNs_Middle_TMSRTE』、『FNs_Last_TMSRTE』を記載しているのである。
【０１０７】
[17-5_22-15_26A] 各AOB_ELEMENT毎のフレーム数の利用法２
BITに記載されているフレーム数は、第２に、任意の再生時刻から再生を開始するという機能（タイムサーチ機能）を実行する際に利用される。図２６（ａ）は、任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【０１０８】
任意の時刻が指定されて再生が指示された場合、再生指定時刻をJmp_Entry(秒)とすると、以下の式を満たすAOB_ELEMENT#yと、AOB_FRAME位置xとから、再生を開始すればよい。
｛数式２｝
Jmp_Entry(秒)＝(FNs_1st_TMSRTE＋FNs_middle_TMSRTE×y＋x)×20msec
これら『FNs_1st_TMSRTE』及び『FNs_Middle_TMSRTE』はBITに記載されているので、これらを｛数式２｝に適用することによりAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTを参照して、AOBにおいてy+2番目に位置するAOB_ELEMENT#y+2の先頭アドレスを求めて、この先頭アドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。これにより、Jmp_Entry(秒)にて指定された時刻から、再生を開始することができる。
【０１０９】
この際、AOBファイルのADTSヘッダ部分を検索せず、TKTMSRTにTMSRT_entryが記述されているAOB_ELEMENT単位で検索を行えばよいので、再生指定時刻に対応する再生位置を高速に探し出すことができる。
同様に、複数のAOBからなるトラックに対して、タイムサーチ機能が実行され、Jmp_Entry(秒)が指定された場合、以下の｛数式３｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出すればよい。
Figure 0004150278
ここでAOB_1からAOB_nまでのAOBの再生時間の総和は、以下の通りである。
AOB_1からAOB_nまでの再生時間の総和＝
(『FNs_1st_TMSRTE』(#1)+『FNs_Middle_TMSRTE』(#1)・(TMSRT_entry数#1-2)+『FNs_Last_TMSRTE』(#1)
+ 『FNs_1st_TMSRTE』(#2)+『FNs_Middle_TMSRTE』(#2)・TMSRT_entry数#2-2)+『FNs_Last_TMSRTE』(#2)
+ 『FNs_1st_TMSRTE』(#3)+『FNs_Middle_TMSRTE』(#3)・TMSRT_entry数#3-2)+『FNs_Last_TMSRTE』(#3)
・・・・・・・・・
+ 『FNs_1st_TMSRTE』(#n)+『FNs_Middle_TMSRTE』(#n)・TMSRT_entry数#n-2)+『FNs_Last_TMSRTE』(#n))・20msec
｛数式３｝を満たすAOB_n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB_n+1に対応するTKTMSRTを参照して、y+2番目のAOB_ELEMENT#y+2に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０１１０】
[17-5_22-16_27A,B] AOBファイル及びTKIの削除
TKIに含まれる情報を全て説明したところで、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、TKIがどのように更新されるかについて説明する。
【０１１１】
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図２７（ａ）、（ｂ）は、トラックを削除する場合を想定した図である。本図は、図１９に示したTrackManagerを示すものであり、本図においてTrackBを削除することを操作者が希望しているものとする。このTrackBに対応するAOBは、AOB002.SA1に収録されており、それがTKI#2に対応づけられているので、AOB002.SA1が削除されると共に、TKI#2のTKI_BLK_ATRが『Unused』に設定される。AOB002.SA1が削除され、TKI#2のTKI_BLK_ATRが『Unused』に設定された状態を図２７（ｂ）に示す。AOB002.SA1が削除されたので、データ領域においてAOB002.SA1が占有していた領域は空き領域に解放される。それと共に、TrackManagerにおいては、TKI#2のTKI_BLK_ATRが『Unused』に設定されていることがわかる。
【０１１２】
[17-5_22-17_28A,B] 新たにAOBファイルを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。
図２８（ａ）は、トラックの削除が複数回行われた後のTrackManagerを示す図である。本図において、複数のトラックが削除され、これらがTKI#2、TKI#4、TKI#5、TKI#7、TKI#8に対応づけられているとすれば、これらのTKIのTKI_BLK_ATRが『Unused』に設定される。AOBファイルの削除は、通常のファイルと同様に行われるが、TrackManagerは、該当するTKIのTKI_BLK_ATRが『Unused』に設定されるのみで削除処理は完了する。そうすると、本図に示すように『Unused』のTKIが虫食い状にTrackManager上に現れることになる。
【０１１３】
図２８（ｂ）は、『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。ここで4つのAOBからなるトラックを書き込もうとする場合を想定する。ここでAOBの記録にどの空きTKIを割り当てるかは、後述するDPL_TK_SRPにより決定されるか、又は、任意のTKIが割り当てられる。その4つのAOBには、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8が割り当てられる。
【０１１４】
これら4つのAOBは1つのトラックを構成するものなので、TKI#2についてのTKI_BLK_ATRを『Head_of_Track』と、TKI#4、TKI#7についてのTKI_BLK_ATRを『Midpoint_of_Track』と、TKI#8についてのTKI_BLK_ATRは、『End_of_Track』と設定される。トラックTrackDを構成する4つのTKI#2、TKI#4、TKI#7、TKI#8は、各TKI_LNK_PTRが、トラックTrackDを構成する次のTKI_LNK_PTRを指示するよう設定されている。即ち、矢印TL2,TL4,TL7に示すように、TKI#2のTKI_LNK_PTRはTKI#4を指示しており、TKI#4のTKI_LNK_PTRはTKI#7を、TKI#7のTKI_LNK_PTRはTKI#8を指示している。
【０１１５】
その後、TKI#2、TKI#4、TKI#7、TKI#8のそれぞれと同じ番号を有する4つのファイルAOB002.SA1、AOB004.SA1、AOB007.SA1、AOB008.SA1が作成されて、これら4つのファイルにTrackDを構成する4つのAOBが収録される。
かかるTKI_BLK_ATR、TKI_LNK_PTRの設定により、4つ目のトラックTrackDは、TKI#2、TKI#4、TKI#7、TKI#8を用いて管理されることなる。
【０１１６】
以上のように、フラッシュメモリカード３１に新たにトラックを書き込む場合、それまでTrackManagerに『Unused』に設定されているTKIを、その新規に記録すべきトラックについてのTKIに割り当てていることがわかる。
[17-5_22-18_29A,B] 2つのトラックを統合する場合のTKI設定
続いてトラックの統合(case3)を行う際の、TKIの更新について説明する。
【０１１７】
図２９（ａ）、（ｂ）は、2つのトラックを1つに統合する場合にTKIがどのように設定されるかを示す図である。図２９（ａ）は、図１９に示したTrackManagerと同一であり、図２９（ａ）において、TrackCとTrackEとを1つのトラックに統合するという編集操作を操作者が希望しているものとする。これらTrackC、TrackEに対応するAOBがAOB003.SA1、AOB008.SA1に収録されており、それらがTKI#3、TKI#8に対応づけられているので、これらTKI#3及びTKI#8のTKI_BLK_ATRの書き換えが行われる。図２９（ｂ）は、TKIのTKI_BLK_ATRの書き換え後を示す図である。本図においてTKI#3、TKI#8のTKI_BLK_ATRはTrackと記載されているが、図２９（ｂ）では、TKI#3のTKI_BLK_ATRは『Head_of_Track』に書き換えられ、TKI#8のTKI_BLK_ATRは『End_of_Track』に書き換えられている。このように、TKI_BLK_ATRが書き換えられることにより、TKI#3、TKI#8、これらに対応するAOB003.SA1、AOB008.SA1は、TrackCという1つのトラックとして扱われる。これに加えて、TKI#3のTKI_LNK_PTRがリンク先としてTKI#8を指示するように書き換えられる。
【０１１８】
ここで留意すべきは、TKIのTKI_BLK_ATRは書き換えられたが、AOB003.SA1とAOB008.SA1とを統合するという処理は行われなかった点である。何故なら、これらのAOBファイルは、互いに異なるFileKeyにて暗号化されているので、これらを1つに統合するとなると、暗号化されたAOBファイルを復号して再度暗号化するという復号化−暗号化という2つの処理が各AOBファイルについて行う必要があり、多大な処理負荷が要求されるからである。また、統合後のAOBファイルは、1つのFileKeyにて暗号化されるので、統合前と比較して、著作権保護の弱体化を招くからである。
【０１１９】
加えてTKIは、元々TKTMSRTのサイズが大きくならないように定められているのに、編集操作においてこれを1つに統合するとなると、統合後のTKIのサイズが、大きくなり過ぎる恐れがあるからである。
以上のように、本実施形態におけるトラックの統合化編集は、AOBファイルの暗号化を維持したまま、TKI_BLK_ATRの属性変更のみで実現されることがわかる。
【０１２０】
[17-5_22-18_29A,B-1_30,31] トラックを統合する場合に満たすべき条件
トラックの統合は、TKI_BLK_ATRの属性変更にて実現されることは上述した通りであるが、トラックの統合にあたっては、統合されるトラックに含まれるAOBが以下の条件を満たしていることが要求される。
1つ目の条件とは、後続するトラックに含まれるAOBと、先行するトラックに含まれるAOBとのオーディオ属性（オーディオコーディングモード、ビットレート、サンプリング周波数、チャネル数）が一致していることである。これは、AOBのオーディオ属性が前後のAOBで異なると、再生装置は、デコーダの動作を一旦リセットする必要があり、連続する2つのAOBをシームレスに（途切れることなく）再生することが困難になるという理由による。
【０１２１】
2つ目の条件とは、統合後により得られるトラックにおいて、AOB_FRAME数が『FNs_Middle_TMSRTE』に満たないAOB_ELEMENTのみからなるAOBが3つ以上連続しないことである。
AOB_ELEMENTのうち少なくとも1つが、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているか否かにより、AOBは2つのタイプに分類される。1つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有するAOB_ELEMENTを少なくとも1つ有しているAOBであり、2つ目のタイプのAOBは、『FNs_Middle_TMSRTE』にて指示されたフレーム数と同数のAOB_FRAMEを有しているAOB_ELEMENTを一切有していないAOBである。即ち、2つ目のタイプのAOBにおけるAOB_ELEMENTは、何れも『FNs_Middle_TMSRTE』にて指示されたフレーム数を下回っており、上述した2つ目の条件は、Type2のAOBが3つ以上連続することを禁じているのである。その禁止理由は以下の通りである。即ちAOBを順次読み出してゆく際、再生装置内のバッファは、充分な数のAOB_FRAMEにて満たされていることが望ましいが、Type2のAOBが連続していると、再生装置内のバッファを、AOB_FRAMEで満たすことができなくなる。そうすると、再生装置内のバッファがアンダーフローを起こし、AOBの再生の連続性が保てなくなる。そうしたアンダフローの発生を避けるため、Type2のAOBが3つ以上連続することを2つ目の条件は禁じているのである。
【０１２２】
図３０（ａ）は、Type1のAOBを示し、図３０（ｂ）は、Type2のAOBを示す図である。図３０（ｂ）におけるAOBは2つ以下のAOB_ELEMENTのみからなり、それら2つ以下のAOB_ELEMENTは、『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していない（尚、この場合BITには、FNs_1st_TMSRTEのみが記述される。）。
『FNs_Middle_TMSRTE』に示されるAOB_FRAMEを有していないことがType2AOBの要件なので、たった1つのAOB_FRAMEにより構成されるAOBであっても、このType2のAOBに分類されることなる。
【０１２３】
図３１（ａ）は、Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続することは避けられているので、これらは1つのトラックに統合される。
図３１（ｂ）は、Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。この場合、Type2のAOBが3つ連続しているので、これらを1つのトラックに統合することは禁じられる。
【０１２４】
[17-5_22-18_29A,B-1_32] Type1、Type2の組合せを考慮したトラック統合
図３１（ａ）に示したトラックの統合によれば、先行するトラックの終端がType1である場合、このトラックは、先頭にType2のAOBを配したトラック、又は、先頭にType1のAOBを配したトラックと統合することができる。図３２（ａ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。また図３２（ｂ）は、先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。これらは何れも、条件2を満たすので、1つのトラックに統合することができる。
【０１２５】
先行するトラックの終端がType2であり、そのType2の直前にType1のAOBが配置されている場合、このトラックは、先頭がType1のトラック、又は、先頭にType2のAOBが配され、その直後にType1のAOBが配置されたトラックと統合することができる。
図３２（ｃ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。図３２（ｄ）は、先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。これらも、条件2を満たすので、1つのトラックに統合することができる。
【０１２６】
先行するトラックの終端がType2であり、そのType2の直前にType2のAOBが配置されている場合、このトラックは、先頭にType1のAOBが配されたトラックと統合することができる。図３２（ｅ）は、先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。これも、条件2を満たすので、1つのトラックに統合することができる。以上のように、トラックの統合にあたっては、統合されるべき2つのトラックが上述した2つの条件を満たすかを前もって判定し、これらの2つの条件を満たすと判定された場合のみ、2つのトラックを1つに統合する。
【０１２７】
続いてトラックの分割(case4)を行う際の、TKIの更新について説明する。
[17-5_22-19_33A,B] トラックを分割する場合のTKI設定
図３３（ａ）、（ｂ）は、1つのトラックを2つのトラックに分割する場合を想定した図である。本図におけるTrackManagerは、図２７に示すTrackManagerと同一であり、本図において、TrackCをTrackC−TrackFという2つのトラックに分割するという編集を操作者が希望しているものとする。TrackCをTrackC−TrackFに分割しようとすると、TrackFに対応するAOB002.SA1が生成される。図３３（ａ）では、TKI#2が『Unused』に設定されており、分割の結果、図３３（ｂ）に示すように『Unused』に設定されているTKI#2は、新たに生成されたAOB002.SA1に割り当てられる。
【０１２８】
[17-5_22-19_33A,B-1_34A,B]
ディレクトリエントリー及びFAT値の更新
ここでAOB003.SA1を分割して、AOB002.SA1を生成する際、ディレクトリエントリー及びFAT値を更新せねばならない。これらディレクトリエントリー及びFAT値をどのように更新するかを以下に説明する。図３４（ａ）は、分割前において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。AOB003.SA1は、複数に分割されて、クラスタ007,008,009,00A・・・・00D,00Eに格納されているものとする。この場合、ディレクトリエントリーにおけるAOB003.SA1について『ファイル最初のクラスタ番号』は、『007』と記述され、クラスタ007,008,009,00A・・・・00Dに対応するFAT値007,008,009,00A・・・・00Dは、それぞれ(008),(009),(00A)・・・・(00D),(00E)と記述されている。
【０１２９】
この状態でAOB003.SA1の後半部を分割してAOB002.SA1を得る場合、SD_Audioディレクトリエントリーには、AOB002.SA1についての『ファイル名』、『ファイル拡張子』、『ファイル最初のクラスタ番号』が追加される。図３４（ｂ）は、分割後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかを示す図である。
【０１３０】
本図におけるクラスタ00Fは、操作者により指定された分割境界を含むクラスタ00Bの内容のコピーを格納したものである。クラスタ00Bに格納されているAOB002.SA1の分割部分に後続する分割部分は、クラスタ00C,00D,00E以降に格納されている。AOB002.SA1の先頭部分はクラスタ00Fに格納され、残りの部分は、クラスタ00C,00D,00E以降に格納されているので、AOB002.SA1についての『ファイル最初のクラスタ番号』には、クラスタ00Fを示すクラスタ番号00Fが記述され、クラスタ00F,00C,00D,00Eに対応づけられているFAT値00F,00C,00D,00Eには、(00C),(00D),(00E)が記述される。
【０１３１】
[17-5_22-19_33A,B-2_35A,B] TKI内の情報要素の設定
以上のディレクトリエントリー及びFAT値の更新によりAOB002.SA1を得た後、AOB002.SA1についてのTKI内の情報要素をどのように設定するかについて説明する。分割されたトラックについてのTKIを生成する場合、TKIの情報要素には、元のTKIに記載されているものをコピーして継承すればよいもの(1)、元のTKIに基づいて更新せねばならないもの(2)の二種類が存在する。前者に該当するのは、TKTXTI_DA,ISRCであり、後者に該当するのは、BIT、TKTMSRTを初めとする残りの構成要素である。これら両者が存在するので、本実施形態では、分割されたトラックについてのTKIを生成する際、分割元のTKIをコピ−して新たなTKIの雛型を作成すると共に、それに含まれるTKTMSRT、BITを分割・更新を行い、残りの情報要素を更新するという手順がなされる。
【０１３２】
図３５（ａ）は、AOBを任意のAOB_FRAMEで分割する場合を想定した図である。本図において第１段目は、4つのAOB_ELEMENTであるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3、AOB_ELEMENT#4を示す。これら4つのAOB_ELEMENTのそれぞれのデータ長は、4つのTMSRT_entry#k-1,#k,#k+1,#k+2(ここでk=2とする)としてTKTMSRTに設定されている。本図において、AOB_ELEMENT#2において分割境界bd1が設定されたとすると、AOB_ELEMENT#2は、分割境界bd1より前方のフレームからなる領域▲１▼と、分割境界bd1より後方のフレームからなる領域▲２▼とに分割される。図３５（ｂ）は、AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB_1、AOB_2という2つのAOBが得られた状態を示す図である。
【０１３３】
[17-5_22-19_33A,B-3_36] BITの設定
図３６は、図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。図３５に示したAOBは、分割境界bd1にて分割されており、その分割により得られたAOB_1は、AOB_ELEMENT#1と、AOB_ELEMENT#2という2つのAOB_ELEMENTを含み、AOB_2は、AOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3という3つのAOB_ELEMENTを含んでいることがわかる。
【０１３４】
これらのAOB_ELEMENTのそれぞれにも、三角旗状の記号が付与されているが、これらは、それぞれAOBに対応するTKIに含まれるTMSRT_entryが設定されていることを示す。先ず最初に分割により得られたAOB_1について説明する。AOB_1に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2は、クラスタ007〜クラスタ00Aを占有しているので、AOB_1は、クラスタ007〜クラスタ00Aを一単位として扱われる。ここでAOB_1におけるAOB_ELEMENT#2は、クラスタ00Aの終端迄を占有しているのではなく、クラスタ00Aの存在する分割境界bd1迄を占有しているのでAOB_1についてのSZ_DATAは、領域md0から、クラスタ00Aにおける分割境界bd1までのデータ長を指示することになる。AOB_1の『FNs_1st_TMSRTE』は分割前と変わらないが、AOB_1の『FNs_Last_TMSRTE』は、AOB_ELEMENT#2の分割前の先頭から、分割境界bd1までのフレーム数を指示している点が分割前と異なる。
【０１３５】
続いて分割により得られたAOB_2について説明する。AOB_2に含まれるAOB_ELEMENT#1、AOB_ELEMENT#2、AOB_ELEMENT#3は、クラスタ00B〜クラスタ00Fを占有している。クラスタ00Fとは、クラスタ00Aの内容のコピーを格納しているクラスタである（クラスタ00Fにクラスタ00Aのコピーを格納している理由は、クラスタ00Aは、AOB_1のAOB_ELEMENT#2により占有されているので、このクラスタと異なるクラスタをAOB_2に含まれるAOB_ELEMENT#1に割り当てる必要があるからである。）。
【０１３６】
AOB_2におけるAOB_ELEMENT#1は、クラスタ00Fの先端から占有しているのではなく、クラスタ00Fの存在する分割境界bd1以降を占有しているのでAOB_2についてのSZ_DATAは、クラスタ00Bの先頭から、クラスタ00Eにおける途中部分までのデータ長と、クラスタ00FにおいてAOB_ELEMENT#1が占有しているデータ長との和を指示することになる。
【０１３７】
クラスタ00Fに格納されているクラスタ00Aのコピーには、AOB_1のAOB_ELEMENT#2が記録されており、AOB_1のAOB_ELEMENT#2により占有されている部分を、AOB_2から除外されねばならないので、AOB_2のBITについてのDATA_Offsetは、クラスタ00FにおいてAOB_1のAOB_ELEMENT#2により占有されているサイズが設定されている。
【０１３８】
この図からもわかるように、AOBの分割においては、分割境界を含むAOB_ELEMENTのみが2つに分割され、その分割境界の前後のAOB_ELEMENTは、分割前のものから変化していないことがわかる。そのため、AOB_2の『FNs_Last_TMSRTE』は、分割前のAOB_ELEMENT#4の『FNs_Last_TMSRTE』と同じ値に設定され、AOB_2の『FNs_1st_TMSRTE』は、AOB_2のAOB_ELEMENT#1、即ち、分割前のAOB_ELEMENT#2における分割境界以降の終端部分に含まれるフレーム数が設定される。
【０１３９】
[17-5_22-19_33A,B-4_37] BITの設定
図３７は、分割の前後でBITがどのように変化するかを更に具体的に示す図である。図３７の左側のBITは、分割前のBITの設定例を示す。トラックを分割する前のBITは、Data_OffsetがXに設定され、SZ_DATAが『52428』、TMSRTE_Nsが『n』個と設定される。FNs_1st_TMSRTEは『80フレーム』、FNs_Middle_TMSRTEについては『94フレーム』に設定され、FNs_Last_TMSRTEは『50フレーム』に設定されることがわかる。
【０１４０】
図３７の右側に、分割後の2つのトラックについてのBITの設定を示す。本BITに対応するAOBが図３５（ａ）に示すように分割された場合、１トラック目のBITにおいて、Data_Offsetは分割前と同一値『x』に設定されるが、SZ_DATAに分割点bd1までのデータ長『Q』に更新され、TMSRTE_Nｓには、1番目のTMSRT_entryからk番目のTMSRT_entryまでのTMSRT_entryの個数である『k個』に更新される。FNs_1st_TMSRTE及びFNs_Middle_TMSRTEについては分割前同様、80,94フレームに設定されるが、分割後の1トラック目のAOBの最後のAOB_ELEMENTには、図３５（ａ）においてp個のAOB_FRAMEが含まれているので、FNs_Last_TMSRTEは『pフレーム』に設定される。
【０１４１】
２トラック目のBITは、Data_OffsetがRに設定され、SZ_DATAがオリジナルのSZ_DATA52428−分割点bd1までのデータ長『Q』、TMSRTE_Nsがn-k+1個と設定される（k番目のTMSRT_entryからn番目のTMSRT_entryまでのTMSRT_entry個数であるn-k個と、分割のために新たに追加されたk番目のTMSRT_entryの個数である1個とを加算した数である。）。FNs_Middle_TMSRTE及びFNs_Last_TMSRTEについては分割前同様、94,50フレームに設定されるが、分割後の2トラック目のAOBの最初のAOB_ELEMENTには、94-p個のAOB_FRAMEが含まれているので、FNs_1st_TMSRTEは『94-pフレーム』に設定される。
【０１４２】
[17-5_22-19_33A,B-5_38] BITの設定
図３８は、分割後のTKTMSRTを示す図である。まずTMSRTについては以下のようになる。１トラック目のTMSRTは分割前のAOBのTMSRTのはじめからk番目のエントリまで(TMSRT_entry#1〜TMSRT_entry#k)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、領域▲１▼を含むのみなので、このk番目のエントリーは、この領域▲１▼に相当する部分のデータサイズのみが含まれている。２トラック目のTMSRTは、分割前のk番目のエントリからn番目のエントリまで(TMSRT_entry#k〜TMSRT_entry#n)を含む。ここで注意すべきは、分割境界を含むAOB_ELEMENT#kは、2トラック目において領域▲２▼を含むのみなので、分割前のk番目のエントリーは、この領域▲２▼に相当する部分のデータサイズのみが含まれている。
【０１４３】
TKIをコピ−すると共に、TKTMSRT、BITを分割・更新を行い、残りの情報要素を更新すれば、分割により得られた新たなトラックについてのTKIが得られることになる。統合の場合と同様、暗号化されたAOBファイルを復号化することなく、暗号化された状態のままAOBファイルに対応するトラックを2つに分割することができる。AOBファイル分割の際に復号・再暗号化が伴わないので、トラックを分割する際の処理負荷が軽減されていることがわかる。これにより、再生装置の処理性能が低い場合でも、トラックの編集を行うことができる。
【０１４４】
以上長文となったが、TKIについての説明を終了する。続いてプレイリストについて説明する。
[17-6] Playlistmanager
図１７に示すPlaylistmanagerは、破線の引き出し線h5に示すように、フラッシュメモリカード３１内に格納されているプレイリストを管理するPlaylistManager_Information(PLMGI)と、フラッシュメモリカード３１に格納される全トラックを管理するDefault_Playlist_Information(DPLI)と、PlaylistInformation(PLI)#1,#2,#3,#4,#5・・・・・#nとからなり、Default_Playlist情報は、破線の引き出し線h6に示すように、Default_Playlist_General_Information(DPLGI),Default_Playlist_Track_Serch_Pointer(DPL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。また各PLIは、破線の引き出し線h7に示すように、Playlist_General_Information(PLGI),Playlist_Track_Serch_Pointer(PL_TK_SRP)#1,#2,#3,#4・・・・#mからなることがわかる。
【０１４５】
ここでDefault_Playlist情報と、PlayList情報との差違について説明しておく。Default_Playlist情報は、全てのトラックを指定することが義務付けられているのに対して、PlayList情報は、そのような義務は存在せず、任意のトラックを指定すれば良い。そのため、ユーザが、自分の好みのトラックのみを指定しているようなPlayList情報を生成してフラッシュメモリカード３１に記憶させたり、またフラッシュメモリカード３１に記憶される複数のトラックのうち、所定のジャンルのトラックのみを指定しているようなPlayList情報を再生装置が自動的に生成してフラッシュメモリカード３１に記憶させるという用途に適している。
【０１４６】
[17-7_18] プレイリストの個数、データサイズ
図１８を参照すると、プレイリストの最大数は99個である。また、Playlist Manager Information(PLMGI)とDefault Playlist Information(DPLI)は、合計で2560バイトの固定長である。Playlist Information(PLI)もまた、512バイトの固定長である。Default_Playlist情報に含まれるDPL_TK_SRPは、DPL_TK_ATR,DPL_TKINを含んでいる。一方、PlayList情報に含まれるPL_TK_SRPは、PL_TKINのみを含んでいる。これらのDPL_TK_ATR,DPL_TKIN,PL_TKINは、図３９に示すフォーマットを有する。
【０１４７】
[17-8_39-1] DPL_TK_SRPのフォーマット
図３９（ａ）は、DPL_TK_SRPのフォーマットを示す図である。図３９（ａ）においてDPL_TK_SRPは、0ビット目から9ビット目までに、DPL_TKINが記述され、13ビット目から15ビットまでには、DPL_TK_ATRが記述され、10ビット目から12ビットまでは予約用に確保(reserved)されている。
【０１４８】
次に、0ビット目から9ビット目までのフィールドを占めるDPL_TKINには、TKI番号が記述される。ここにTKI番号を記述することにより、TKIを特定することが可能となる。
[17-9_39B] PL_TK_SRPのフォーマット
図３９（ｂ）は、PL_TK_SRPのフォーマットを示す図である。PL_TK_SRPは、0ビット目から9ビット目までのフィールドを有しており、ここにPL_TKIN、即ち、TKI番号が記述される。
【０１４９】
[17-8_39A-2] DPL_TK_ATRの構成
図３９（ａ）の『DPL_TK_ATR』から破線の矢印h51,h52にて引き出された枠内に、DPL_TK_ATRの設定例を示す。この枠内の記載からも理解できるように、DPL_TK_SRPについてのDPL_TK_ATRの設定は、TKIについてのTKI_BLK_ATRの設定と同一であり、『Track』、『Head_of_Track』、『Midpoint_of_Track』、『End_of_Track』の何れかが設定される。
【０１５０】
具体的には、TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルに１個のトラックに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Track』）、DPL_TK_ATRは"000b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの先頭部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Head_of_Track』）、DPL_TK_ATRは"001b"の値が設定される。
【０１５１】
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの中間部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『Midpoint_of_Track』）、DPL_TK_ATRには"010b"の値が設定される。
TKINにて指定されたTKIが使用中であり、当該TKIに対応するAOBファイルにトラックの終端部のみに対応するオーディオオブジェクトが収録されている場合（TKIのTKI_BLK_ATRにおける『End_of_Track』）、DPL_TK_ATRには、"011b"の値が設定される。
【０１５２】
TKINにて指定されたTKIが未使用であり、TKIの領域のみが確保されている場合、すなわち削除されたTKIである場合（TKIのTKI_BLK_ATRにおける『Unused』）、"100b"の値が設定される。
TKINにて指定されたTKIが未使用であり、TKIの領域が確保されていない場合、すなわち初期状態のTKIである場合は、"101b"の値が設定される。
【０１５３】
『DPL_TK_SRP』は、DPL_TKINにTKIの番号を記述することにより、複数のTKIのうち、何れかのものとの対応関係を有する。また、Default_Playlist情報におけるDPL_TK_SRPの順位は、DPL_TK_SRPと対応関係を有するTKIに対応するAOB（AOBファイル）が何番目に再生されるかを示す。これらのことにより、Default_Playlist情報におけるDPL_TK_SRPの順序は、複数のトラックをどのような順序で再生させるか、即ち、トラックの再生順序を定義することなる。
【０１５４】
[17-9_40-1] Default_Playlist情報、TKI、AOBファイルの相互関係
図４０は、Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。本図における第２、第３、第４段目は、図１９の第１段目、第２段目、第３段目と同一であり、8つのTKIを含むTrackManager、8つのAOBファイルを示す。図１９と異なるのは、第１段目にDefault_Playlist情報を示す四角枠が記述されている点である。第１段目の枠に含まれる8つの小枠は、Default_Playlist情報に含まれる8つのDPL_TK_SRPを示す。これらの小枠の上段はDPL_TK_ATRを示し、下段はDPL_TKINを示す。
【０１５５】
本図における矢印DT1,DT2,DT3,DT4・・・・・を参照すれば、DPL_TK_SRP#1と、TKI#1との間に対応関係が成立しており、DPL_TK_SRP#2と、TKI#2との間、DPL_TK_SRP#3と、TKI#3との間、DPL_TK_SRP#4と、TKI#4との間にも対応関係が成立していることがわかる。
更に、各DPL_TK_SRPにおけるDPL_TK_ATRを参照すれば、DPL_TK_SRP#1、DPL_TK_SRP#2、DPL_TK_SRP#3、DPL_TK_SRP#8は何れも、Trackと設定されている。即ち、DPL_TK_SRP#1→TKI#1（AOB001.SA1）、DPL_TK_SRP#2→TKI#2（AOB002.SA1）、DPL_TK_SRP#3→TKI#3（AOB003.SA1）、DPL_TK_SRP#8→TKI#8（AOB008.SA1）という4つの組みは、それぞれが独立したトラックに対応しているのである。
【０１５６】
DPL_TK_SRP#4、DPL_TK_SRP#5、DPL_TK_SRP#6、DPL_TK_SRP#7のDPL_TK_ATRは何れもTrackと設定されず、DPL_TK_SRP#4におけるDPL_TK_ATRは『Head_of_Track』と設定され、DPL_TK_SRP#7におけるDPL_TK_ATRは『End_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6は『Midpoint_of_Track』と設定されていることがわかる。このことは、DPL_TK_SRP#4と対応関係を有するTKI#4（AOB004.SA1）が、トラックの先頭部であり、DPL_TK_SRP#5,#6と対応関係を有するTKI#5（AOB005.SA1）及びTKI#6（AOB006.SA1）が、トラックの中間部と、DPL_TK_SRP#7と対応関係を有するTKI#7（AOB007.SA1）が、トラックの終端部であることを意味する。
【０１５７】
DefaultPlaylistにおけるDPL_TK_SRPの順序は、各TKIに対応づけられているAOBをどのような順序で再生させるかを示す。本図のDefaultPlaylist内のDPL_TK_SRP#1,#2,#3,#4・・・・・・#8のDPL_TKINは、TKI#1,#2,#3,#4・・・・・・#8を示しているので、矢印(1)(2)(3)(4)・・・・・(8)に示すようにTKI#1に対応するAOB001.SA1が1番目に再生され、TKI#2に対応するAOB002.SA1が2番目、TKI#3に対応するAOB003.SA1が3番目、TKI#4に対応するAOB004.SA1が4番目に再生されることになる。
【０１５８】
[17-10_41] DefaultPlaylist、PlayList情報の設定例
図４１は、DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。本図における第１段目における四角枠はDefault_Playlist情報を示し、第２段目における3つの四角枠はPlayList情報を示す。DefaultPlaylistに含まれる小枠は、DefaultPlaylistに含まれる8つのDPL_TK_SRPを示し、PlayList情報に含まれる小枠は、3つ又は4つのPL_TK_SRPを示す。本図のDefault_Playlist情報に含まれる各DPL_TK_SRPのTKINの設定は、図４０と同一である。しかし、PlayList情報に含まれるPL_TK_SRPのTKINの設定は、DPL_TK_SRPのそれと全く異なることがわかる。
【０１５９】
[17-10_42] DPL_TK_SRPとTKIとの対応
図４２は、図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。図４２においてPlaylist#1は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#3と記載されており、PL_TK_SRP#2のPL_TKINは#1と、PL_TK_SRP#3のPL_TKINは#2と記載されているので、PlayList情報#1を用いてトラックを再生する場合、矢印(11)(12)(13)に示すように複数のAOBはAOB_3,#1,#2の順序で再生される。
【０１６０】
Playlist#2は、PL_TK_SRP#1,#2,#3からなる。このうちPL_TK_SRP#1のPL_TKINは#8と記載されており、PL_TK_SRP#2,#3のPL_TKINは#3、#1と記載されているので、PlayList情報#2を用いてトラックを再生する場合、矢印(21)(22)(23)に示すように複数のAOBはAOB#8,#3,#1という順序、即ちPlaylist#1と全く異なる順序で再生される。
【０１６１】
Playlist#3は、PL_TK_SRP#1,#2,#3,#4からなる。このうちPL_TK_SRP#1,#2,#3,#4のPL_TKINは#8,#4,#3,#1と記載されているので、PlayList情報#3を用いてトラックを再生する場合以下に示す再生順序でAOBが再生される。先ず矢印(31)に示すようにTrackEを構成するAOB_8が再生され、矢印(32)に示すようにTrackDを構成するAOB_4,AOB_5,AOB_6,AOB_7がこれに続いて再生される。続いて、矢印(33)(34)に示すようにTrackC、TrackAを構成するAOB_3,AOB_1という順序で再生される。ここで注意すべきは、トラックが複数のTKIから構成される場合、PL_TK_SRPのエントリーには、複数TKIのうち、先頭のTKI番号のみが記述されている点である。具体的にいうと、Default_Playlist情報におけるDPL_TK_SRPは、TrackDについての4つのTKIであるTKI#4、TKI#5、TKI#6、TKI#7を指定していたが、PlayList情報におけるPL_TK_SRPは、それら4つのTKIを指定する必要はない。Playlist#3のPL_TK_SRP#2がTKI#4〜TKI#7のうち、TKI#4のみを指定していることは、このことを意味している。
【０１６２】
一方、複数のDPL_TK_SRPを含むDPLIは、1セクタに収まるようなデータサイズを有しており、RAM上に常駐されている。そのため、Playlistに基づいて各トラックを再生する場合、RAM上に常駐されているDPL_TK_SRPを参照することにより、各TKIを高速に検索することが可能となる。即ち、複数TKIのうち、先頭のTKI番号のみが記述されているPL_TK_SRPを用いてTKI(AOB)を再生するには、PL_TK_SRPに記述されているTKIを元にRAM上に常駐されているDPL_TK_SRPを検索し、トラックが複数のTKIから構成されているか否かを判定する。複数のTKIから構成されている場合には、対応するTKI(AOB)を全て再生するという手順を経るのである。
【０１６３】
以上のように、PlayListManagerにはDefaultPlaylist、複数のPlayList情報が記述され、これらを構成するDPL_TK_SRP、PL_TK_SRPのDPL_TKIN、PL_TKINにそれぞれ相異なる再生順序が記載されていれば、複数AOBは、それぞれ相異なる再生順序で再生されることになる。全く異なる再生順序で再生されれば、操作者は、複数の音楽アルバムが格納されているような感覚でフラッシュメモリカード３１を利用することができる。
【０１６４】
また、注意すべきは、何れもAOBファイルに対応づけられているDPL_TK_SRP、TKIのうち、DPL_TK_SRPのデータサイズは小さく(2バイトに過ぎない)、TKIのデータサイズは大きい(1024バイトもある。)点である。TrackManagerにおけるTKIの順序を入れ替えることは、フラッシュメモリカード３１に対するアクセスが多く発生するが、Default_Playlist情報、PlayList情報におけるDPL_TK_SRPの順序を入れ替えても、フラッシュメモリカード３１に対するアクセスはそれほど多くなならない。この点に鑑み、ナビゲーションデータは、その編集時において、編集操作に応じてDefaultPlaylistにおけるDPL_TK_SRPの順序を積極的に変化させる一方、TrackManagerにおけるTKIの順序は、編集操作にかかわらず、一定に維持するようにしている。
【０１６５】
[17-9_40-2_43A,B] DPL_TK_SRPの順序を入れ替え
次に、Default_Playlist情報におけるDPL_TK_SRPの順序を入れ替えることにより、トラックの再生順序を変更するという編集操作がどう行われるかについて説明する。図４３（ａ）、（ｂ）は、トラックの順序を入れ替える場合を想定した図である。図４３（ａ）におけるDPL_TK_SRP、TKIの設定は、図４０と同じである。図４０（ａ）においてDPL_TK_SRP#3におけるDPL_TKINはTKI#3、DPL_TK_SRP#8におけるDPL_TKINはTKI#8と設定されていたが、この状態において、太枠で囲ったDPL_TK_SRP#3と、DPL_TK_SRP#8との順番を入れ替える。図４３（ｂ）における(1)(2)(3)(4)(5)(6)(7)(8)は、順番入れ替え後のトラックの再生順序を示す。このことに留意すると、図４３（ａ）における再生順序は、TrackA、TrackB、TrackC、TrackD、TrackEであるが、図４３（ｂ）におけるDefault_Playlist情報では、DPL_TK_SRP#3、DPL_TK_SRP#8についてのDPL_TKINの順序が入れ替えられたので、TrackA、TrackB、TrackE、TrackD、TrackCの順序で再生されることになる。このように、Default_Playlist情報における、DPL_TK_SRPの順序を入れ替えることにより、簡易にトラックの再生順序を変更することができる。
【０１６６】
トラックの変更操作という編集操作について説明したところで、TKIの場合と同様、一部のトラックが削除された場合(case1)、一部のトラックが削除された後、新たなトラックを記録する場合(case2)、複数のトラックのうち、任意の2つを1つのトラックに統合する場合(case3)、1つのトラックを分割して、2つのトラックを得る場合(case4)において、DPL_TK_SRP及びTKIがどのように更新されるかについて説明する。
【０１６７】
[17-9_40-3_44A,B] トラックを削除する場合
先ず初めに、一部のトラックが削除された場合(case1)について説明する。
図４４（ａ）、（ｂ）は、図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。図４４は、TKIの削除の説明で引用した図２７と同一部分を有する。即ち、図４４における第２、第３、第４段目は図２７と同一である。異なるのは図４０同様、第１段目に複数のDPL_TK_SRPを含むDefault_Playlist情報が記載されている点である。図４４（ａ）において太枠で囲ったDPL_TK_SRP#2→TKI#2（AOB002.SA1）からなるTrackBをユーザが削除したものとする。この場合、Default_Playlist情報においてはDPL_TK_SRP#2が削除されて、DPL_TK_SRP#3〜DPL_TK_SRP#8は、DPL_TK_SRP#2が占有していたフィールドを詰めるように、順番が1つずつ繰り上がる。このように各DPL_TK_SRPの順番を繰り上がり、一番最後のDPL_TK_SRP#8が『Unused』に設定される。これに対してTKIは、図２７（ａ）、（ｂ）を用いて説明したように『Unused』に設定されているのみで、TKI#2を詰めるような移動は行われていない。またAOB002.SA1は、削除されていることがわかる。DPL_TK_SRPについては順番の繰り上げが行われたが、TKIについては順番の繰り上げが行われていないので、図４４（ｂ）では、DPL_TK_SRPにおけるDPL_TKINが更新されている。即ち、新たなDPL_TK_SRP#2のDPL_TKINは、矢印DT11に示すようにTKI#3を指示しており、DPL_TK_SRP#3のDPL_TKINは矢印DT12に示すようにTKI#4を、DPL_TK_SRP#4のDPL_TKINはTKI#5、DPL_TK_SRP#5のDPL_TKINはTKI#6をそれぞれ指示している。更に、『Unused』に設定されたDPL_TK_SRP#8のDPL_TKINは、矢印DT13に示すように、『Unused』に設定されたTKI#2を設定していることがわかる。
【０１６８】
トラックの削除が行われた場合、使用中であるDPL_TK_SRPが先頭に繰り上げられるが、それに対応するTKIは、もとの配置を保ったまま、未使用に設定されることがわかる。このように、TKIの配置を編集前後において、不動とするので、編集処理に伴う処理負荷を軽減することができる。
[17-9_40-4_45A,B] トラックを記録する場合のTKIの割り当て
続いて一部のトラックが削除された後、新たなトラックを記録する場合(case2)について説明する。図４５（ａ）、（ｂ）は、『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。図４５（ａ）、（ｂ）において、『Unused』のTKIに新たなTKIを割り当てるケースを説明した際、引用した図２８（ａ）〜（ｂ）と同一部分を有する。即ち、図４５（ａ）、（ｂ）における第２、第３、第４段目は、図２８（ａ）、（ｂ）の第１、第２、第３段目と同一である。異なるのは、図４５の第１段目に複数のDPL_TK_SRPからなるDefault_Playlist情報が記述されている点である。図４５（ａ）において、DPL_TK_SRP#4〜DPL_TK_SRP#8が『Unused』であり、一方、図２８（ａ）に示したようにTKI#2、TKI#4、TKI#5、TKI#7、TKI#8が『Unused』であることがわかる。TrackManagerにおいて『Unused』のTKIが虫食い状に存在しているのに対して、Default_Playlist情報において『Unused』のDPL_TK_SRPがまとめられているのは、上述したように、DPL_TK_SRPは、『Unused』以外のDPL_TK_SRPの繰り上げが行われるのに対して、TKIは、そのような繰り上げが行われないからである。
【０１６９】
ここで4つのAOBからなるTrackDを書き込もうとする場合を想定する。その4つのAOBのそれぞれについてのTKIは、TrackManagerにおいて、『Unused』に設定されているTKI#2、TKI#4、TKI#7、TKI#8のそれぞれに書き込まれる。
一方、これら4つのAOBについてのDPL_TK_SRPは、Default_Playlist情報におけるDPL_TK_SRP#4〜DPL_TK_SRP#7に書き込まれる。これら4つのAOBは1つのトラックを構成するものなので、DPL_TK_SRP#4についてのDPL_TK_ATRは『Head_of_Track』と、DPL_TK_SRP#5、DPL_TK_SRP#6についてのDPL_TK_ATRは『Midpoint_of_Track』と、DPL_TK_SRP#7についてのDPL_TK_ATRは『End_of_Track』と設定されている。
【０１７０】
また、DPL_TK_SRP#4についてのDPL_TKINはTKI#2と設定され、DPL_TK_SRP#5についてのDPL_TKINはTKI#4、DPL_TK_SRP#6についてのDPL_TKINはTKI#7、DPL_TK_SRP#7についてのDPL_TKINはTKI#8と設定されている。
以上のようなDPL_TKIN、DPL_TK_ATRの設定により、TKI#2,TKI#4,TKI#7,TKI#8は、4つ目のトラックTrackDとして管理されることなる。
【０１７１】
以上の処理において、『Unused』のTKIに対する書き込みが行われたが、TKI#1、TKI#2、TKI#3、TKI#4に関しては、何の変動もなされていない点は図２８の場合と同様である。
[17-9_40-5_46A,B] トラックの統合(case3)を行う場合について
続いてトラックの統合(case3)を行う際の、Default_Playlist情報の更新について説明する。図４６（ａ）、（ｂ）は、トラックの統合を行う場合を想定した図である。本図は、TKIの統合処理を説明した際に引用した図２９（ａ）、（ｂ）と同一部分を有する。即ち、図４６（ａ）、（ｂ）における第２、第３、第４段目は、図２９（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４６（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。本図において、図２９に示したようなトラックの統合処理が、AOBファイル及びTKIに対してなされると、DPL_TK_SRP#3〜DPL_TK_SRP#6の内容を1つずつずらして、太枠で囲ったDPL_TK_SRP#7の記述内容をDPL_TK_SRP#3にコピーする。TKIについては、図２９に示した場合と同様の更新処理がなされる。
【０１７２】
[17-9_40-6_47A,B] トラックの分割(case4)を行う場合について
続いてトラックの分割(case4)を行う際の、Default_Playlist情報の更新について説明する。
図４７（ａ）、（ｂ）は、トラックの分割を行う場合を想定した図である。本図は、TKIについての分割処理を説明した際に引用した図３３（ａ）、（ｂ）と同一部分を有する。即ち、本図における第２段目、第３段目は、図３３（ａ）、（ｂ）における第１段目、第２段目と同一である。差違点は、図４７（ａ）、（ｂ）では、Default_Playlist情報が記載されており、それに含まれるDPL_TK_SRP#8が『Unused』に設定されていて、同じく『Unused』に設定されているTKI#2と対応関係を有している点である。この状態において、図３３の場合と同様に、太枠で囲ったTKI#3、AOB003.SA1を2つに分割しようとすると、DPL_TK_SRP#3〜DPL_TK_SRP#7の順序を一つずつ繰り下げて、Default_Playlist情報における『Unused』のDPL_TK_SRPをDPL_TK_SRP#3まで移動する。移動後のDPL_TK_SRP#3には、分割により得られたTKI#2が対応づけられる。TKI#2に対応づけられているAOB002.SA1は、元々AOB003.SA1の後半部を格納したものであるが、TKI#2に対応づけられているDPL_TK_SRP#3の前に、DPL_TK_SRP#2が存在し、このDPL_TK_SRP#2は、TKI#2−AOB002.SA1が対応づけられている。即ち、AOB002.SA1及びAOB003.SA1は、元のAOB003.SA1の後半部分、前半部分を格納しているが、これらを指定しているDPL_TK_SRP#2、DPL_TK_SRP#3は、AOB003.SA1、AOB002.SA1の順序で、これらのAOBファイルを再生するよう再生順序を指定しているので、元のAOB003.SA1の後半部分、前半部分は、DPL_TK_SRPの再生順序指定により、前半部分、後半部分の順に、再生されることなる。
【０１７３】
[17-9_40-8] 編集処理の応用
以上の4つの編集操作を組み合わせることにより、操作者は、様々な編集操作を行うことができる。即ち、あるトラックの先頭部分にディスクジョッキーのアナウンスが入っており、これを削除したい場合、上記のトラックの分割処理にて、そのアナウンス部分を一個のトラックとして分割し、その後、そのトラックを削除すれば、ディスクジョッキーのアナウンスのみを部分的に削除することができる。
【０１７４】
以上でナビゲーションデータについての説明を終え、続いて、このようなナビゲーションデータ、プレゼンテーションデータを再生するために構成された再生装置について説明する。
[48-1] 再生装置の外観
図４８は、本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。本図において再生装置は、フラッシュメモリカード３１が挿入される挿入口、再生、順方向サーチ再生、逆方向サーチ再生、早送り、巻き戻し、停止等のキー操作を操作者から受け付けるためのキーパネルと、液晶ディスプレィとを有しており、通常の携帯型音響機器同様の外観を有する。キーパネルには、プレイリスト／トラックの選択を受け付けるPlaylistキー、トラックの先頭へのスキップを受け付ける『|<<キー』、次トラックの先頭へのスキップを受け付ける『>>|キー』、早送り、巻き戻し、順方向サーチ再生、逆方向サーチ再生を受け付ける『>>キー』,『<<キー』、フラッシュメモリカード３１に静止画が格納されている場合に、静止画を表示させる操作を受け付けるDisplayキー、録音操作を操作者から受け付けるRecキー、Stereo/Monoral選択、サンプリング周波数選択を操作者から受け付けるAudioキー、ブックマークの指定を受け付けるMarkキー、トラックの編集、タイトル入力を受け付けるEditキーが備えられている。
【０１７５】
[48-2] フラッシュメモリカード３１の携帯型再生装置における改良点
このフラッシュメモリカード３１の携帯型再生装置が通常の携帯型音響機器と異なるのは、以下の改良点(1)〜(4)である。即ち、操作者からDefault_Playlist情報、PlayList情報、トラックの指定を受け付けるために、液晶ディスプレィには、プレイリスト、トラックの一覧表示がなされること(1)、また、そのように一覧表示されたプレイリスト又はトラックのうち、任意のものを再生対象又は編集対象として指定させるためのキー割り当てがなされていること(2)、トラックの再生進行と共に、液晶ディスプレィには、トラックの再生経過時刻が表示されること(3)、タイムサーチ機能や分割編集を行う際に、再生開始時間を設定するために用いられるジョグダイアルが設けられていること(4)である。
【０１７６】
[48-2_49_50] 改良点(2)の詳細
改良点(2)の詳細は以下の通りである。図４９は、プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図であり、図５０は、トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
図４９における『DEFAULTPLAYLIST』『PLAYLIST#1』『PLAYLIST#2』『PLAYLIST#3』『PLAYLIST#4』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストと、4つのプレイリストを示すASCII文字列である。また、図５０（ａ）における『TRACK#1』『TRACK#2』『TRACK#3』『TRACK#4』『TRACK#5』は、フラッシュメモリカード３１に格納されているデフォルトプレイリストにて、再生順序が指定される5つのトラックを示すASCII文字列である。図４９及び図５０（ａ）にて、ハッチングを付したこれらのプレイリスト及びトラックは、再生対象又は編集対象として指定されていることを示す。このように液晶ディスプレィにプレイリストにて再生順序が規定されるトラックが一覧表示され、TRACK#1が再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｂ）に示すように一覧表示された複数トラックのうち、その下のTRACK#2が再生対象に指定される。TRACK#2が、再生対象に指定された状態で>>|キーの押下がなされると、図５０（ｃ）に示すように一覧表示された複数トラックのうち、更に下段のTRACK#3が再生対象に指定される。TRACK#3が再生対象に指定された状態で|<<キーの押下がなされると、一覧表示された複数トラックのうち、図５０（ｄ）に示すように一段上のTRACK#2が再生対象に指定される。このように>>|キー、|<<キーの押下に応じて、何れかのトラックが再生対象として選択されるので、何れかのトラックが再生対象として選択された際に、図５０（ｅ）に示すように再生キーが押下されれば、そのトラックの再生が開始され、Editキーが押下されれば、そのトラックが編集対象として指定される。
【０１７７】
[48-3_51] 改良点(4)の詳細
続いて改良点(4)の詳細について説明する。図５１は、ジョグダイアルの操作例を示す図である。ジョグダイアルにより、操作者による回転操作を受け付けて、その回転量に応じて、液晶ディスプレィに表示されている再生経過時刻を増減させる。例えば図５１（ａ）に示すように、液晶ディスプレィに再生開始時刻が『00:00:20』と表示されているものとする。この場合、図５１（ｂ）に示すように、ジョグダイアルが反時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて減少して『00:00:10』となる。また図５１（ｃ）に示すように、ジョグダイアルが時計回りに回転されたとすると、再生開始時刻は、その回転量に応じて増加して『00:00:30』となる。
【０１７８】
このように再生時間時間を増減させるのは、トラックにおける任意の再生時刻を指定するためであり、ジョグダイアルの回転により、任意の再生時刻が指定され、再生キーが押下されれば、上記｛数式２｝｛数式３｝に従って指定された位置からAOBを再生する。
また、分割編集においてジョグダイアルは、任意の再生開始時間を分割境界として特定する際、分割境界を微調整するために用いられる。
【０１７９】
[52-1] 再生装置の内部構成について
続いて再生装置の内部構成について説明する。図５２は、再生装置の内部構成を示す図である。本図において再生装置は、フラッシュメモリカード３１を接続するためのカードコネクタ１と、キーパネル、ジョグダイアルと接続されるユーザインターフェイス部２と、RAM３と、ROM４と、プレイリスト、トラックを一覧表示する一覧表示枠、再生経過時刻が表示される再生経過時刻枠を有する液晶ディスプレィ５と、液晶ディスプレィを駆動するためのLCDドライバ６と、AOBファイル毎に異なるFileKeyを用いて、AOB_FRAMEの暗号化を解除するデ・スクランブラ７と、デ・スクランブラ７によりAOB_FRAMEのデスクランブルが行われれば、当該AOB_FRAMEのADTSヘッダを参照して、当該AOB_FRAMEを復号することにより、PCMデータを得るAACデコーダ８と、AACデコーダ８の復号により得られたPCMデータをD/A変換して、ヘッドホン端子を介してスピーカーに出力するD/Aコンバータ９と、再生装置内の統合処理を行うCPU１０とを備える。このハードウェア構成からも判るように、本再生装置には、TrackManager、Default_Playlist情報を処理するための新規の構成は見られない。TrackManager、Default_Playlist情報の処理のために設けられているのは、RAM３内に確保されているDPLI常駐領域１１、PLI格納領域１２、TKI格納領域１３、FileKey格納領域１４、ダブルバッファ１５と、ROM４に格納されている再生制御プログラム及び編集制御プログラムである。
【０１８０】
[52-2] DPLI常駐領域１１
DPLI常駐領域１１は、カードコネクタ１に接続されフラッシュメモリカード３１から読み出されたDefault_Playlist情報を常駐させるために確保されている領域である。
[52_12] PLI格納領域１２
PLI格納領域１２は、操作者により選択され、再生対象になっているPlayList情報を格納しておくために確保されている領域である。
【０１８１】
[52-3] TKI格納領域１３
TKI格納領域１３は、TrackManagerに含まれる複数のTKIのうち、再生対象になっているAOBファイルに対応するTKIのみを格納しておくために確保されている領域であり、TKI1個分のデータサイズを有する。
[52-4] FileKey格納領域１４
FileKey格納領域１４は、プロテクト領域内のAOBSA1.KEYに含まれる複数のFileKeyのうち、再生対象になっているAOBファイルに対応するFileKeyのみを格納しておくために確保されている領域である。
【０１８２】
[52-5] ダブルバッファ１５
ダブルバッファ１５は、フラッシュメモリカード３１から読み出されたクラスタデータ（クラスタ一個当たりに格納されるデータ）を順次入力して格納するという入力処理と、格納されたクラスタデータから暗号化AOB_FRAMEを読み出して、順次デ・スクランブラ７に出力するという出力処理とを並列に行う場合に用いられる入出力バッファである。ダブルバッファ１５は、AOB_FRAMEとしての出力が済んだクラスタが占有していた領域を順次空き領域に解放し、この空き領域を、新たに読み出されたクラスタの格納に用いるという領域確保、即ち、リングポインタを用いた巡回式の領域確保を行う。
【０１８３】
[52-5_53_54A,B] ダブルバッファ１５における入出力
図５３は、ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。図５４（ａ）、（ｂ）は、リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
これらの図において左下向きの矢印は、クラスタデータの書込先アドレスについてポインタ、即ち、書込先ポインタを示す。左上向きの矢印は、クラスタデータの読出先アドレスについてのポインタ、即ち、読出先ポインタを示す。これらのポインタは、リングポインタとして用いられる。
【０１８４】
[54-6_53] フラッシュメモリカード３１がカードコネクタ１に接続されると、このフラッシュメモリカード３１のユーザデータ領域におけるクラスタデータは、矢印w1,w2に示すようにフラッシュメモリカード３１から読み出される。読み出されたクラスタデータは、ダブルバッファ１５において、書込先ポインタWP1,WP2に示される位置に順次格納されてゆく。
【０１８５】
[52-7_54A] このように格納されたクラスタデータに含まれるAOB_FRAMEのうち、読出先ポインタ▲１▼▲２▼▲３▼▲４▼▲５▼▲６▼▲７▼▲８▼▲９▼に指示される位置に存在するAOB_FRAMEは、矢印r1,r2,r3,r4,r5・・・・・・に示すように順次デ・スクランブラ７へと出力されてゆく。ここでダブルバッファ１５にクラスタデータ002,003が格納されており、読出先ポインタにてに示さる読出先が図５３の▲１▼▲２▼▲３▼▲４▼に示すように移動して、▲５▼に達した場合、クラスタ002に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ004を読み出して、図５４（ａ）の矢印w6に示すように、クラスタ002が占有していた領域に上書きする。
【０１８６】
[52-8_54B] また読出先ポインタにてに示さる読出先が▲６▼▲７▼に示すように移動して、▲９▼に達すれば、クラスタ003に含まれるAOB_FRAMEは全て読み出されたことになるので、新たにクラスタ005を読み出して、図５４（ｂ）の矢印w7に示すように、クラスタ003が占有していた領域に上書きする。以上のような、AOB_FRAMEの出力と、クラスタデータの上書きとが何度も繰り返されて、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７、AACデコーダ８に出力されてゆく。
【０１８７】
[52-9_55〜58] ROM４に格納されている再生制御プログラム
続いてROM４に格納されている再生制御プログラムについて説明する。
図５５は、AOBファイル読み出し処理の処理手順を示すフローチャートであり、図５６、図５７、図５８は、AOB_FRAME出力処理の処理手順を示すフローチャートである。
【０１８８】
[52-9_55-1] これらのフローチャートにおいて、変数wとは、複数DPL_TK_SRPのそれぞれを指示する変数であり、変数zとは、それぞれのAOBファイルと、それに対応するTKIと、それに含まれるAOBとを一意に指示するための変数である。変数yとは、変数zにて指示されるAOB_zに含まれる個々のAOB_ELEMENTを指示するための変数であり、変数xとは、変数yにて指示されるAOB_ELEMENT#yに含まれるそれぞれのAOB_FRAMEを指示する変数である。先ず図５５を参照しながらAOBファイル読出処理の処理手順について説明する。
【０１８９】
[52-9_55-2] ステップＳ１においてCPU１０はPlayListManagerを読み出して、Default_Playlist情報及びPlayList情報を一覧表示する。ステップＳ２においてCPU１０は、Default_Playlist情報、PlayList情報の何れに従ってAOBを再生させるかの指定を待つ。ここで、Default_Playlist情報が指定された場合、ステップＳ２からステップＳ３に移行して、変数wを初期化し（#w←1）、ステップＳ４では、Default_Playlist情報におけるDPL_TK_SRP#wに対応づけられたDPL_TKINにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。そして、ステップＳ５においてTKI#zと同じ番号を有するAOBファイル#zを特定する。ここまでの手順で、ようやく、再生すべきAOBファイルが特定されたことになる。特定されたAOBファイルは、暗号化されているので、このAOBファイルの暗号化を解除すべく、以降ステップＳ６、ステップＳ７の処理を行う。即ち、ステップＳ６では、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該AOBファイル#zと同じ番号を有するFile Key Entry#zに格納されているFileKey#zを読み出す。ステップＳ７においてCPU１０は、FileKey#zをデ・スクランブラ７に設定する。かかる設定により、FileKeyはデ・スクランブラ７に設定されたので、以降、AOBファイルに含まれるAOB_FRAMEが順次デ・スクランブラ７に投入されれば、AOB_FRAMEは順次再生されることになる。
【０１９０】
[52-9_55-3] 以降、AOBファイルを格納している各クラスタを順次読み出してゆく。ステップＳ８では、ディレクトリエントリーにおけるそのAOBファイル#zについての『ファイル最初のクラスタ番号』を特定し、ステップＳ９においてCPU１０は、そのクラスタに格納されているデータをフラッシュメモリカード３１から読み出す。ステップＳ１０では、FAT値にクラスタ番号がFFFと記述されているか否かを判定し、もしFAT値がFFF以外の値なら、ステップＳ１１においてそのFAT値にて指示されているクラスタに格納されているデータを読み出す。かかる読み出し後、ステップＳ１０に移行する。ここで、何れかのクラスタに格納されているデータを読み出し、そのクラスタに対応づけられているFAT値を参照した際、そのFAT値にFFF以外の何れかのクラスタ番号が記述されている限り、ステップＳ１０−ステップＳ１１の処理は繰り返し行われる。これにより、そのFAT値により指示されているクラスタが順次読み出されてゆく。そのFAT値にクラスタ番号がFFFと記述されている場合、AOBファイル#zを構成するクラスタは全て読み出されたことになるので、ステップＳ１０からステップＳ１２に移行する。
【０１９１】
[52-9_55-4] ステップＳ１２においてCPU１０は、変数#wがDPL_TK_SRPの総数と一致したか否かを判定する。一致しないなら、ステップＳ１３に移行して、変数#wをインクリメントした後（#w←#w+1）、ステップＳ４に移行する。ステップＳ４においてDefault_Playlist情報におけるDPL_TK_SRP#wのDPL_TKIN#wにより指定されているTKI#zを特定して、そのTKI#zのみをTKI格納領域１３に読み出す。この際、TKI格納領域１３にはそれまで使用されていたTKIが格納されているが、CPU１０は、TKI格納領域１３に既に格納されているTKIを新たに読み出したTKIを用いて上書きする。このような上書きによりTKI格納領域１３には、最新のTKIのみが格納されることになる。このようにTKIが上書きされれば、ステップＳ５〜ステップＳ１２の処理をAOBファイル#zについて繰り返す。ステップＳ５〜ステップＳ１２の処理が繰り返され、Default_Playlist情報に含まれる全てのDPL_TK_SRPに対応するTKI、AOBファイルが読み出されれば、変数#wとDPL_TK_SRPの総数とが一致して、ステップＳ１２がYesとなり、本フローチャートを終了する。
【０１９２】
[52-9_56_57_58] AOB_FRAME出力処理
かかるAOBファイル読出処理と並行して、CPU１０は、図５６、図５７、図５８のフローチャートに従い、AOB_FRAME出力処理を行う。本フローチャートにおいてplay_timeとは、これまで再生が経過した時間、即ち、再生経過時刻を示す変数であり、液晶ディスプレィ５の時刻表示枠内の時刻は、このplay_timeの更新に応じて、表示内容が書き換えられる。また、play_dataとは、これまで再生されたデータ長である。
【０１９３】
[52-9_56-1] ステップＳ２１において、CPU１０は、AOBファイル#zについてのクラスタデータがダブルバッファ15に蓄積されたかを監視している。クラスタデータが蓄積されない限り、このステップＳ２１を繰り返し行うが、クラスタデータが蓄積されれば、ステップＳ２２において、#x、#yの初期化を行い（#x←1,#y←1）、その後、ステップＳ２３において、AOBファイル#zについてのクラスタにおいて、TKI#zに含まれるBIT#zのData_Offset以降からAOB_ELEMENT#yにおけるAOB_FRAME#xを検出する。ここでSZ_DATAから7バイトは、ADTSヘッダが占有しているものとして、当該ADTSヘッダを参照し、ADTSヘッダに示されているデータ長が本体部のオーディオデータであると解析して、当該ADTSヘッダと、本体部のオーディオデータとを読み出し、デ・スクランブラ７に出力する。デ・スクランブラ７によりAOB_FRAMEの暗号化が解除され、AACデコーダ８により復号が行われれば、音声として再生されることになる。
【０１９４】
[52-9_56-2] 検出後、ステップＳ２４において、AOB_FRAME#xをデ・スクランブラ7に出力し、ステップＳ２５において、再生経過時刻play_timeをAOB_FRAME#xに相当する再生時間だけインクリメントし、再生済みデータ数play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。ここでAOB_FRAMEの再生時間長は、20msecであるので、再生経過時刻play_timeには、20msecが加算されることになる。
【０１９５】
1番目のAOB_FRAMEがデ・スクランブラ７に出力されれば、ステップＳ２６においてAOB_FRAME#xのADTSヘッダを参照して、次のAOB_FRAMEが何処に存在するかを特定する。ステップＳ２７では、変数#xのインクリメントを行い（#x←#x+1）、次のAOB_FRAMEをAOB_FRAME#xとする。ステップＳ２８においてAOB_FRAME#xをデ・スクランブラ7に投入する。その後、ステップＳ２９では、play_timeを、AOB_FRAME#xに相当する再生時間だけインクリメントすると供に、play_dataをAOB_FRAME#xに相当するデータ数だけインクリメントする。AOB_FRAME#xをインクリメントした後、ステップＳ３０においてCPU１０は、#xが『FNs_1st_TMSRTE』に達したかを判定する。#xが『FNs_1st_TMSRTE』に達しないのなら、ステップＳ３１において、Playキー以外のキーが押下されたかどうかを確認した後、ステップＳ２６に移行する。以降、#xが『FNs_1st_TMSRTE』に達するまで、または、Playキー以外のキーが押下されるまで、ステップＳ２６〜ステップＳ３１の処理は繰り返し行われる。ここでPlayキー以外のキーが押下された場合、本フローチャートを終了して、押下されたキーに該当する処理を行う。押下されたキーが停止キーなら再生処理を停止し、押下されたキーが一時停止キーなら一時停止を行う。
【０１９６】
[52-9_57-1] 一方、#xが『FNs_1st_TMSRTE』に達したなら、ステップＳ３０がYesとなり、図５７のステップＳ３２に移行する。ステップＳ２６からステップＳ３０までの処理にて、AOB_ELEMENTに含まれる全てのAOB_FRAMEがデ・スクランブラ７に投入されたので、次のAOB_ELEMENTに処理対象を移行すべく、ステップＳ３２において#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。
【０１９７】
その後、ステップＳ３３においてTKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出する。以降、ステップＳ３４〜ステップＳ４２からなる処理を行う。ステップＳ３４〜ステップＳ４２の処理は、AOB_ELEMENTに含まれるAOB_FRAMEを次々と読み出す処理である点で、ステップＳ２４〜ステップＳ３１からなる処理と同一であるといえる。ステップＳ２４〜ステップＳ３１の処理と異なるのは、後者におけるループ処理の終了条件は、#xが『FNs_1st_TMSRTE』に達することであるのに対し、前者におけるループ処理の終了条件は、#xが『FNs_Middle_TMSRTE』に達することである。#xが『FNs_Middle_TMSRTE』に達して、ステップＳ３４〜ステップＳ４２からなるループ処理が終了すると、ステップＳ４１がYesとなってステップＳ４３に移行する。ステップＳ４３においてCPU１０は#yをインクリメントすると共に、#xを初期化する（#y←#y+1,#x←1）。その後、ステップＳ４４において、変数yが、TKI#zのTMSRT_Headerにおける(TotalTMSRT_entry_Number-1)と等しい値に達したかを判定する。#yが(TotalTMSRT_entry_Number-1)より小さい場合、AOB_ELEMENT#yは未だ、最後のAOB_ELEMENTに達してしていないので、ステップＳ４４からステップＳ３２に移行することにより、ステップＳ３２〜ステップＳ４２の処理を継続して行う。#yが(TotalTMSRT_entry_Number-1)に達した場合、最後のAOB_ELEMENTの1つ前のAOB_ELEMENTまで、AOB_FRAMEの読み出し処理は完遂したと考えられるので、ステップＳ４４がYesとなり、図５８のステップＳ４５に移行する。
【０１９８】
[52-9_57-2] ステップＳ４５〜ステップＳ５４の処理は、最後のAOB_ELEMENTに含まれる複数のAOB_FRAMEをそれぞれ読み出す処理であるという点において、上述したステップＳ３３〜ステップＳ４２の処理と同一といえる。異なるのは、ステップＳ３３〜ステップＳ４２におけるループ処理は、ステップＳ４１において#xが『FNs_Middle_TMSRTE』に達することがループ処理の終了条件であったのに対して、ステップＳ５３では、#xが『FNs_Last_TMSRTE』であり、かつ、これまで読み出されたデータサイズを示すPlay_dataがSZ_DATAに達することが、ループ処理の終了条件になっている点である。
【０１９９】
このステップＳ５３の条件が満たされるまで、ステップＳ４９〜ステップＳ５４の処理は繰り返し行われ、この条件が満たされれば、ステップＳ５３がYesとなって、ステップＳ５５に移行する。ステップＳ５５においてCPU１０は、#zをインクリメントしてからステップＳ２１に移行して（#z←#z+1）、次のAOBファイルがダブルバッファ１５に蓄積されるのを待つ。蓄積されれば、ステップＳ２１からステップＳ２２に移行し、次のAOBファイルについて、ステップＳ２２〜ステップＳ５４の処理を繰り返し行う。即ち、次のDPL_TK_SRPのDPL_TKINにより指定されているTKIを特定し、そのTKIに対応するAOBファイル、即ち、TKIと同じ番号を有するAOBファイルを特定する。その後、プロテクト領域をアクセスして、暗号鍵格納ファイルにおいて当該TKIと同じ番号を有するFileKeyを特定し、当該FileKeyを読み出して、当該FileKeyをデ・スクランブラに設定してから、そのTKIと同じ番号を有するAOBファイルに含まれるAOB_FRAMEを順次読み出して再生してゆくのである。
【０２００】
[52-9_57-3_59] 再生経過時刻の更新
図５９は、液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。本図（ａ）では、再生経過時刻は00:00:00.000であるが、AOB_FRAME#1の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.020に更新されている。AOB_FRAME#2の再生が終了した時点で、再生経過時刻にAOB_FRAMEの時間長20msecが加算されて00:00:00.040に、AOB_FRAME#6の再生が終了した時点で、再生経過時刻は00:00:00.120となっていることがわかる。
【０２０１】
以上がAOB_FRAME出力処理の全貌である。本フローチャートのステップＳ３１において、Playキー以外のキーの押下時に、本フローチャートの処理を中断することは既に述べた通りであり、そのようなPlayキー以外のキーとして一時停止キーや停止キーがあることも説明済みであるが、一時停止キーや停止キー以外にも、特殊再生を再生装置に行わせるためのキーが押下された場合も、図５６、図５７、図５８のフローチャートの処理は中断し、その押下されたキーに応じた処理が実行される。以降、>>キーが押下され、順方向サーチ再生を実行する場合のCPU１０の処理手順と、一時停止キーや停止キーが押下された後に、ジョグダイアルが操作されることにより、タイムサーチ機能が実行される場合のCPU１０の処理手順とについて説明する。
【０２０２】
[52-10_60] 順方向サーチ再生
図６０は、順方向サーチ再生を行う場合のCPU１０の処理手順を示すフローチャートである。>>キーが操作者により押下されて図５６、図５７、図５８のステップＳ３１、ステップＳ４２、ステップＳ５４がYesになった際、CPU１０により実行されるのが本フローチャートである。
【０２０３】
ステップＳ６１において、CPU１０はAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入する。ここで、『t』とは、間欠再生時間であり、f(t)を、間欠再生時間に相当するフレーム数、d(t)を間欠再生時間に相当するデータ数とすると、ステップＳ６２では、再生経過時刻を示すplay_time、再生済みデータ数を示すplay_dataを、t:間欠再生時間、f(t):間欠再生時間に相当するフレーム数、d(t):間欠再生時間に相当するデータ数に基づいて更新する（x←x+f(t)、play_time←play_time+t、play_data←play_data+d(t) 尚、一般に間欠再生時間は240ミリ秒(12個のAOB_FRAMEの再生時間長)に相当する。）。
【０２０４】
[52-10_60-1_61A,B] 図６１（ａ）、（ｂ）は、順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。図６１（ａ）は、再生経過時刻の初期状態を示し、再生時点は、AOB_ELEMENT#51のAOB_FRAME#1であることを示す。この場合の再生経過時刻は、00:00:01.000であることがわかる。ここで、間欠再生時間として、1番目から12番目までのAOB_FRAMEがデ・スクランブラ７に投入されて、再生経過時刻に1AOB_FRAMEの時間長である240ミリ秒が加算されると、図６１（ｂ）に示すように、再生経過時刻は、00:00:01.240となる。
【０２０５】
[52-10_60-2] これらを更新した後、ステップＳ６３においてCPU１０は、インクリメント後のAOB_FRAME#xと、AOB_ELEMENT#yの総フレーム数との大小比較して、インクリメント後のAOB_FRAME#xがAOB_ELEMENT#y内に存在するかを判定する。具体的には、AOBの先頭に位置するAOB_ELEMENTのフレーム数は『FNs_1st_TMSRTE』であり、中間のもののフレーム数は『FNs_Middle_TMSRTE』、最後のもののフレーム数は『FNs_Last_TMSRTE』に示されるので、これらと、AOB_FRAME#xとを比較することにより、判定を行う。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在しないのなら、ステップＳ６４においてAOB_ELEMENT#yに後続するAOB_ELEMENTが存在するかを判定する。ここでAOB_ELEMENT#yが最後のAOB_ELEMENTであり、後続するAOB_ELEMENTが存在しない場合、ステップＳ６４がNoとなり、本フローチャートの処理を終了するが、後続するAOB_ELEMENTが存在する場合、ステップＳ６５において、AOB_FRAME#xからAOB_ELEMENT#yにおけるフレーム数を減じ、ステップＳ６６において#yを更新することにより（y←y+1）、AOB_FRAME#xを後続するAOB_ELEMENT#yにおけるAOB_FRAMEのフレーム位置に変換する。もし更新後のAOB_FRAME#xがAOB_ELEMENT内に存在するのなら、これらステップＳ６５〜ステップＳ６６をスキップして、ステップＳ６７に移行する。
【０２０６】
[52-10_60-3] 続いて、間欠スキップ間隔に応じて、AOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataの更新を行う。ここで、間欠スキップ間隔に相当する時間をskip_time(2秒)とし、間欠スキップ間隔skip_timeに相当するフレーム数をf(skip_time)、間欠スキップ間隔skip_timeに相当するデータ数d(skip_time)とすると、ステップＳ６７において、これらを用いてAOB_FRAME#x、再生経過時刻play_time、再生済みデータ数play_dataを更新する（x←x+f(skip_time),play_time←play_time+skip_time,play_data←play_data+d(skip_time)）。
【０２０７】
[52-10_60-4_61C] 図６１（ｃ）に示すように、AOB_ELEMENT#51内のフレーム位置を示すAOB_FRAME#xに間欠スキップ間隔を加算したものとする。この加算後の#xがAOB_ELEMENT#51のフレーム数を上回れば、AOB_ELEMENTを次のAOB_ELEMENTに更新すると共に、加算後の#xから、AOB_ELEMENT#51のフレーム数を減じることにより、AOB_FRAME#xを、AOB_ELEMENT#52におけるフレーム位置に変換する。この場合、AOB_ELEMENT#yがAOB_ELEMENT#52となり、再生経過時刻は、00:00:01.240に2.000を加算することにより、00:00:03.240となる。AOB_FRAME#xは、AOB_ELEMENT#52におけるAOB_FRAME#62(=(3240msec-2000msec)/20msec)となる。
【０２０８】
[52-10_60-5_61(d)] その後、AOB_ELEMENT#52におけるAOB_FRAME#62がデ・スクランブラ７に投入されれば、図６１（ｄ）に示すように再生経過時刻は、00:00:03.240に0.240を加算することにより、00:00:03.480となる。
ステップＳ６７において間欠的スキップ時間に応じた更新を行えば、ステップＳ６８〜ステップＳ７１の処理を行う。このステップＳ６８〜ステップＳ７１の処理は、ステップＳ６３〜ステップＳ６６の処理と同一であり、間欠スキップ間隔skip_timeに相当するフレーム数が加算された後のAOB_FRAMEがAOB_ELEMENT#y内に存在するかどうかの判定がなされて、存在するのなら、その次のAOB_ELEMENTをAOB_ELEMENT#yとし、AOB_FRAME#xを、新たなAOB_ELEMENT#yにおけるフレーム位置に変換する。
【０２０９】
間欠再生時間及び間欠的スキップ時間に応じて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされれば、ステップＳ７２において、CPU１０は、TKTMSRTを参照してAOB_ELEMENT#yについての先頭アドレスを算出し、ステップＳ７３においてAOB_ELEMENT#yにおける先頭アドレスからADTSヘッダの探索を開始することにより、AOB_FRAME#xを検出する。そして、ステップＳ７４において、順方向スキップキー以外のキーが押下されたか否かを判定した後、ステップＳ６１においてAOB_ELEMENT#yのAOB_FRAME#xからx+f(t)-1までをデ・スクランブラ7に投入し、再度ステップＳ６２〜ステップＳ７３の処理を繰り返し行う。
【０２１０】
以上の処理にて、AOB_FRAME#x、AOB_ELEMENT#yがインクリメントされ、再生位置が進行してゆく。その後、操作者により再生キーが押下されれば、ステップＳ７４がNoとなり、本フローチャートの処理を終了する。
[52-11] タイムサーチ機能の実行
タイムサーチ機能が行われた場合の処理について説明する。Default_Playlist情報におけるトラックを一覧表示し、任意のトラックの指定を受け付ける。トラックが指定され、ジョグダイアルが操作されると、再生開始時刻を更新する。再生開始時刻が増減した後、再生キーが押下されると、その再生が指定された時刻をJmp_Entry(秒)と特定する。一方、指定されたトラックが複数のAOBからなるか、単一のAOBからなるかを判定する。単一のAOBからなる場合、｛数式２｝を満たすAOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOBに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２１１】
[52-12]
複数のAOBからなる場合、｛数式３｝を満たすAOB_n、AOB_ELEMENT#yと、AOB_FRAME#xとを算出する。｛数式３｝を満たすAOB_n、AOB_ELEMENT#y、AOB_FRAME#xが算出されれば、このAOB_nに対応するTKTMSRTにおいて、y+2番目に位置するアドレスから、AOB_FRAME#xの探索を始め、x番目のAOB_FRAMEが探索されれば、このx番目のAOB_FRAMEから再生を開始する。
【０２１２】
続いてBITにおけるFNs_1st_TMSRTEは80フレームであり、FNs_Last_TMSRTEは50フレーム、FNs_Middle_TMSRTEが94フレームであるAOBにおいて、任意の再生時刻から再生を開始する場合について説明する。
[52-13_62A,B]
ここで、タイムサーチ機能が行われる場合の具体例として、ジョグダイアルにより、再生開始時刻が指定された場合に再生を開始すべきAOB_ELEMENT、再生を開始すべきフレーム位置をどのように特定するかについて説明する。図６２は、タイムサーチ機能が行われる場合の具体例を示す図である。ここで図６２（ａ）に示すように、再生装置が把持されて、あるAOBが再生対象として指定された状態で、その右手の親指により、ジョグダイアルの回転操作がなされ、 再生開始時刻=00:04:40.000(=280.00sec)が指定されたものとする。このAOBについてTKI内のBITが、図６２（ｂ）に示す内容である場合、再生開始時刻=00:04:40.000(=280.00sec)を｛数式２｝に適用すると、
Figure 0004150278
となるので、｛数式２｝を満たすAOB_ELEMENT#y、AOB_FRAME#xとして、y=148,x=8のAOB_FRAMEが得られる。
【０２１３】
このようにy=148と特定されたので、y+2番目のAOB_ELEMENT#150(=148+2)のエントリーアドレスをTKTMSRTから取得して、ここから8番目のAOB_FRAMEから、再生を開始すれば、 再生経過時刻=00:04:40.000(=280.00sec)から、再生を開始することができる。
[52-14_63_64_65]
以上でPlayキーが押下された場合の、CPU１０の処理内容の説明を終える。続いてROMに格納されている編集制御プログラムについて説明する。本編集制御プログラムは、Editキーが押下された場合に実行されるものであり、図６３、図６４、図６５にその処理手順を示す。以降、これらのフローチャートを参照しながら、編集制御プログラムの処理内容について説明する。
【０２１４】
[52-14_63-1] 編集制御プログラム
Editキーが押下されれば、図６３のステップＳ１０１において削除、分割、統合といった典型的な編集操作の何れを行うかを操作者に提示する対話画面を表示し、その後、ステップＳ１０２において、対話画面に対する処理が指定されたかを判定する。ここで対話画面の操作において、>>|キー、|<<キーをそれぞれ上下カーソル操作を受け付けるためのキー、即ち、上下カーソルキーとして用いるものとする。削除処理が指定されると、ステップＳ１０３、ステップＳ１０４からなるループ処理に移行する。ステップＳ１０３では、>>|キー、|<<キーが押下されたか否かを判定し、ステップＳ１０４では、編集キーが押下されたか否かを判定する。>>|、|<<キーが押下されれば、ステップＳ１０３からステップＳ１０５に移行して、指示されたトラックを編集対象として指定する。一方、編集キーが押下されれば、削除すべきトラックが特定されたとして、図４４に示した処理を行い、指定されたトラックについてのTKIのTKI_BLK_ATRを『Unused』に設定することにより、特定されたトラックを削除する。
【０２１５】
[52-14_63-2] 統合編集処理
統合編集が指定されると、ステップＳ１０２からステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。ステップＳ１０７〜ステップＳ１０９からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１０７からステップＳ１１０に移行して、指示されたトラックに対するハイライト表示を行う。編集キーが押下されれば、ステップＳ１０８がYesとなり、ステップＳ１１１に移行する。ステップＳ１１１では、カーソルキーにて指示されたトラックを、編集対象として指定し、再度、ステップＳ１０７〜ステップＳ１０９からなるループ処理に移行する。
【０２１６】
2トラック目の編集対象が特定されれば、ステップＳ１０９がYesとなって、ステップＳ１１２に移行する。ステップＳ１１２では、先行するトラック、後続するトラックについてのTKIのBITを参照することにより、両トラックの末尾及び先頭に配置されているAOB（その前後にもAOBが配されている場合は、その前後のAOB）のタイプがType1、Type2の何れであるかを判定する。
【０２１７】
各AOBのタイプが判明したのなら、ステップＳ１１３においてそれら各タイプのAOBの配置画像に示した何れの配置パターンに該当するかを判定する。図３２（ａ）〜（ｄ）の何れかの配置パターンに該当し、統合後においても、Type2AOBが3つ連続しないことが明らかならば、ステップＳ１１５において先行するトラック、後続するトラックを1つのトラックに統合する。即ち、これらに対応づけられたTKI、DPL_TK_SRPに対して、図４６に示した操作を行い、TKIのTKI_BLK_ATRを書き換えることにより、それら操作対象として選択された複数のトラックを1つのトラックに統合する。図３２（ａ）〜（ｄ）の何れの配置パターンにも該当せず、統合後にType2のAOBが3つ連続してしまう場合は、ステップＳ１１４において統合後のトラックにアンダーフローの発生の恐れがある旨を表示し、統合処理を中断する。
【０２１８】
[52-14_64-1] トラックの分割処理
トラックの分割が指定されると、ステップＳ１０２からステップＳ１１６〜ステップＳ１１７からなるループ処理に移行する。ステップＳ１１６〜ステップＳ１１７からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下とを受け付ける。>>|｜、|<<キーが押下されれば、ステップＳ１１６からステップＳ１１８に移行して、指示されたトラックを編集対象として指定する。編集キーが押下されれば、ステップＳ１１７がYesとなり、ステップＳ１１９に移行する。ステップＳ１１９では、カーソルキーにて指示されたトラックを、編集対象として指定する。その後、ステップＳ１２０では、分割が指定されたトラックの再生を開始して、ステップＳ１２１においてMarkキーの押下を受け付ける。Markキーの押下が行われると、トラックの再生を一時停止し、ステップＳ１２２〜ステップＳ１２３からなるループ処理に移行する。ステップＳ１２２では、ジョグダイアルに対する回転操作を受け付け、ジョグダイアルに対して回転操作がなされると、ステップＳ１２４においてその回転操作に伴い、再生開始時間を増減させる。その後、ステップＳ１２２〜ステップＳ１２３からなるループ処理に再度移行する。回転操作により再生開始時刻が増減された状態で、編集キーが押下されれば、ステップＳ１２３からステップＳ１２５に移行し、ステップＳ１２５において、編集キーが押下された再生時間を分割境界として指定する（尚、分割境界の指定にあたっては、アンドゥ機能（編集の取り消し）が可能である。）。その後、ステップＳ１２６において図４７で説した処理を行い、DPLI、TKIを更新することにより、トラックの分割を行う。
【０２１９】
[52-14_65-1] プレイリストの設定編集処理
プレイリストの設定編集が指定されると、図６５のフローチャートに移行する。本フローチャートにおいて変数kとは、これから設定されるプレイリストにより、再生順序が規定される個々のトラックを指示するための変数であり、図６５のフローチャートでは、先ずステップＳ１３１においてこの変数kに1を設定した後、ステップＳ１３２〜ステップＳ１３４からなるループ処理に移行する。ステップＳ１３２〜ステップＳ１３４からなるループ処理では、>>|キー、|<<キーの押下と、編集キーの押下と、停止キーの押下とを受け付ける。>>|キー、|<<キーが押下されれば、ステップＳ１３２からステップＳ１３５に移行して、>>|キー、|<<キーにより指示されたトラックを指定する。編集キーが押下されれば、ステップＳ１３３がYesとなり、ステップＳ１３６に移行する。ステップＳ１３６では、編集キーにて指示されたトラックを、k番目に再生されるべきトラックとして特定する。その後、ステップＳ１３７において、変数kをインクリメントして、ステップＳ１３２〜ステップＳ１３４のループ処理に移行する。このような処理を繰り返すことにより、2トラック目、3トラック目、4トラック目のトラックが順次特定される。このようにして、新たに作成されたプレイリストにて再生されるべき複数のトラックが特定された状態で停止キーが押下されると、ステップＳ１３４からステップＳ１３８に移行して、これらに対応づけられたTKIを特定するPL_TK_SRPからなるPlayList情報を生成する。
【０２２０】
（記録装置）
[66-1] 記録装置
続いて、フラッシュメモリカード３１の記録装置についての一例を説明する。図６６は、フラッシュメモリカード３１の記録装置の一例を示す図である。本図における記録装置は、インターネットを介した通信が可能であり、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが配信されてくる場合にこれらを受信することができる汎用パーソナルコンピュータである。
【０２２１】
[67-1] 記録装置のハードウェア構成
図６７は、記録装置のハードウェア構成を示す図である。本図において記録装置は、フラッシュメモリカード３１を接続するためのカードコネクタ２１と、RAM２２と、記録装置の統合制御を行うための記録制御プログラムを格納した固定ディスク装置２３と、マイクから入力された音声をA/D変換して、PCMデータを得るA/Dコンバータ２４と、単位時間当たりのPCMデータをエンコードして、ADTSヘッダを付与することにより、AOB_FRAMEを得るACCエンコーダ２５と、各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化するスクランブル部２６と、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、電子音楽配信によりオーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合に、オーディオデータトランスポートストリームを受信するモデム装置２７と、記録装置内の統合制御を行うCPU２８と、操作者からの操作を受け付けるキーボード２９と、ディスプレィ３０とを有する。
【０２２２】
[67-2] 入力経路RT1〜RT4
電子音楽配信によりデータ領域及びプロテクト領域に書き込むべきSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、記録装置はこれらを正当に受信した時点で、フラッシュメモリカード３１のデータ領域及びプロテクト領域に書き込めばよい。しかし、SD_Audioディレクトリィでは無く、電子音楽配信によりオーディオデータトランスポートストリームそのものが伝送されてくる場合、またPCMデータの状態で記録装置に入力されてくる場合、原音の状態で記録装置に入力されてくる場合、記録装置は、以下に示す4つの入力経路を経て、フラッシュメモリカード３１にオーディオデータトランスポートストリームを書き込むことなる。
【０２２３】
本図における記録装置がフラッシュメモリカード３１に、オーディオデータトランスポートストリームを格納する際、オーディオデータトランスポートストリームの入力経路には、図６７に示す入力経路RT1、入力経路RT2、入力経路RT3、入力経路RT4がある。
[67-3] 入力経路RT1
入力経路RT1は、電子音楽配信によりSD_Audioディレクトリィが暗号化された状態で通信回線を介して伝送されてくる場合、又は、オーディオデータトランスポートストリームが通信回線を介して伝送されてくる場合の入力経路であり、この場合、トランスポートストリームに含まれるAOB_FRAMEは、一個のAOBに属するもの毎に異なるFileKeyを用いて暗号化されている。暗号化済みのトランスポートストリームに対しては、再度の暗号化、符号化の必要は存在しないので、SD_Audioディレクトリィ又はオーディオデータトランスポートストリームは、暗号化された状態で、RAM２２に格納される。
【０２２４】
[67-4] 入力経路RT2
入力経路RT2は、マイクから音声が入力されてくる場合の入力経路である。この場合、A/Dコンバータ２４にマイクから入力された音声をA/D変換を行わせて、PCMデータを得る。そしてPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOBファイル毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータをRAM２２に格納する。
【０２２５】
[67-5] 入力経路RT3
入力経路RT3は、CDから読み出されたPCMデータが装置に入力されてくる場合の入力経路である。PCMデータの状態で入力されてくるので、当該PCMデータは、そのままAACエンコーダ２５に入力される。そのように入力されたPCMデータのエンコードをAACエンコーダ２５に行わせて、ADTSヘッダを付与することにより、AOB_FRAMEを得る。その後、スクランブル部２６に各AOB_FRAME毎のFileKeyを用いて、AOB_FRAMEを暗号化を行わせることにより、暗号化がなされたオーディオデータを得る。その後、オーディオデータはRAM２２に格納される。
【０２２６】
[67-6] 入力経路RT4
入力経路RT4は、3つの入力経路RT1,RT2,RT3において入力されたトランスポートストリームを、フラッシュメモリカード３１に書き込む際の入力経路である。かかるオーディオデータの格納に伴い、TKI、Default_Playlist情報は生成される。再生装置の場合と同様、かかる記録装置の機能主体も、ROMに記録されている記録プログラムである。即ち、AOBの記録やTrackManager、PlayListManagerの記録といった本実施形態特有の処理は、固定ディスク装置に記録されている記録プログラムにより実現される。
【０２２７】
[67-7_68] 記録処理の処理手順
以降、フローチャートを参照しながら、上記入力経路RT1,RT2,RT3,RT4において、トランスポートストリームをフラッシュメモリカード３１に書き込む場合の記録処理の処理手順について説明する。図６８は、記録処理の処理手順を示すフローチャートである。本フローチャートにおいて引用する変数としては、Frame_Number、Data_Sizeといったものがある。Frame_Numberとは、これまでAOBファイルに記録されたAOB_FRAMEの総数を管理するための変数であり、Data_Sizeとは、これまでAOBファイルに記録されたAOB_FRAMEのデータサイズを管理するための変数である。
【０２２８】
本フローチャートが実行されると、ステップＳ２００においてCPU２８は、DefaultPlaylist,TrackManagerを作成し、ステップＳ２０１において、変数#z,#wを初期化する（z←1,w←1）。ステップＳ２０２では、AOBファイル#zを作成してフラッシュメモリカード３１におけるデータ領域に格納する。この状態で、データ領域におけるSD_Audioディレクトリのディレクトリエントリーには、AOBファイル#zのファイル名、ファイル拡張子、最初のクラスタ番号が設定されることになる。続くステップＳ２０３において、CPU２８は、TKI#zを作成してTrackManagerに格納し、ステップＳ２０４においてCPU２８は、DPL_TK_SRP#wを作成してDefaultPlaylist情報に格納する。以降ステップＳ２０５において変数#yを初期化し（y←1）、ステップＳ２０６において、Frame_Number、Data_Sizeのそれぞれを初期化する（Frame_Number←0、Data_Size←0）。
【０２２９】
ステップＳ２０７においてCPU２８は、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したかを判定する。AACエンコーダ２５により符号化され、スクランブル部２６により暗号化されたオーディオデータトランスポートストリームが続々とRAM２２に格納されており、クラスタデータの書き込みを継続する必要がある場合、ステップＳ２０７がNoとなりステップＳ２０９に移行する。ステップＳ２０９においてCPU２８は、クラスタサイズ分のAACオーディオデータがRAM２２に蓄積したかを判定する。RAM２２にクラスタデータが蓄積した場合、ステップＳ２０９がYesとなり、ステップＳ２１０に移行して、RAM２２に蓄積されたクラスタサイズのAACオーディオデータをフラッシュメモリカード３１に書き込んだ後ステップＳ２１１に移行する。クラスタデータの蓄積が完了していない場合、ステップＳ２１０をスキップしてステップＳ２１１に移行する。ステップＳ２１１においてCPU２８は、Frame_Numberをインクリメントし(Frame_Number←Frame_Number+1)、Data_SizeをそのAOB_FRAMEのデータサイズだけインクリメントする。かかる更新を行った後、ステップＳ２１２においてFrame_Numberが、『FNs_Middle_TMSRTE』として定めているフレーム数に達したか否かを判定する。ここで『FNs_Middle_TMSRTE』は、オーディオデータトランスポートストリームが符号化された際のサンプリング周波数に応じた値となるので、Frame_Numberが、『FNs_Middle_TMSRTE』に達した場合は、ステップＳ２１２はYesとなるが、そうでない場合、ステップＳ２１２はNoになり、ステップＳ２０７に移行する。以降、ステップＳ２０７、ステップＳ２１２がYesとなるまで、ステップＳ２０７〜ステップＳ２１２は繰り返し行われる。
【０２３０】
Frame_Numberが『FNs_Middle_TMSRTE』に達してステップＳ２１２がYesとなった場合、ステップＳ２１２からステップＳ２１３に移行し、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納してステップＳ２１４において#yをインクリメントした後（y←y+1）、ステップＳ２１５において変数yが252に達したか否かを判定する。ここで252という値は、一個のAOBに格納できるAOB_ELEMENTの総数を示す値であり、変数yが252に達しない場合、ステップＳ２１６に移行する。ステップＳ２１６では、無音状態が所定時間以上継続しており、オーディオデータがトラック間の境界に達したか否かを判定する。無音状態が存在しない場合、ステップＳ２０６〜ステップＳ２１５の処理を繰り返し行う。変数yが252に達した場合、又は、無音状態が所定時間以上継続した場合、ステップＳ２１５、ステップＳ２１６の何れか一方がYesとなり、ステップＳ２１７に移行して、変数#z,#wをインクリメントする（z←z+1,w←w+1）。その後、インクリメントされた#zについて、ステップＳ２０２〜ステップＳ２１６の処理を繰り返し行う。かかる繰り返しにより、複数のAOB_ELEMENTを含むAOBが次々とフラッシュメモリカード３１に書き込まれてゆく。
【０２３１】
ここで、AACエンコーダ２５、スクランブル部２６、モデム装置２７からのオーディオデータトランスポートストリームの伝送が終了した場合、AOBファイル#zに書き込むべき、オーディオデータトランスポートストリームの入力が終了したことになるので、ステップＳ２０７がYesとなり、ステップＳ２０８に移行する。ステップＳ２０８においてCPU２８は、Data_SizeをAOB_ELEMENT#yについてのTMSRT_entry#yとしてTKI#zのTKTMSRTに格納し、RAM22に蓄積されたオーディオデータをAOB_zに対応するAOBファイルに格納した後、本フローチャートの処理を終了する。
【０２３２】
以上の処理により、暗号化されたオーディオデータトランスポートストリームは、フラッシュメモリカード３１に格納されたことになるが、この暗号化を解除するためのFileKeyは、以下の処理により、プロテクト領域に格納される。
入力経路RT2,RT3の場合は、一個のAOBの符号化が開始される度に、CPU２８は異なるFileKeyを生成して、スクランブル部２６に設定し、そのFileKeyでスクランブル部２６に暗号化を行わせると共に、それらのFileKeyをプロテクト領域に存在する暗号鍵格納ファイルのFileKey Entry以降に格納する。
【０２３３】
一方入力経路RT1の場合は、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイル、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルは、電子音楽配信のプロバイダより、送信される。CPU２８は、それらを受信して、AOBファイル、TKMGを格納したファイル、PLMGを格納したファイルをユーザデータ領域に書き込み、AOB毎の異なるFileKeyを格納した暗号鍵格納ファイルをプロテクト領域に書き込む。
【０２３４】
以上のように本実施形態によれば、AOBを格納したファイルは、それぞれ異なる暗号鍵にて暗号化されているので、1つのファイルを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるAOBは、1つのファイルに格納されているAOBだけであり、他のファイルに格納されたAOBには何の影響も及ぼさない。暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２３５】
なお、上記実施形態は現状において最善の効果が期待できるシステム例として説明したに過ぎない。本発明は、その要旨を逸脱しない範囲で実施変更することができる。具体的には、以下の（ａ）〜（ｆ）に示すような変更実施が可能である。
（ａ）本実施の形態では、記録媒体を半導体メモリ（フラッシュメモリカード）として説明を行ったが、これに限られるものではなく、DVD-RAMなどの光ディスクやハードディスクなどに置き換えることができる。
【０２３６】
（ｂ）本実施の形態では、音楽データとしてAACを使用したが、これに限られるものではなく、MP3（MPEG 1 Audio Layer 3）、Dolby-AC3、DTS（Digital Theater System）などであってもよい。
（ｃ）TKMGを格納したファイル、PLMGを格納したファイルのそのものを電子音楽配信にて配信するのではなく、TKMG,PLMGの元となる情報を、AOBファイル、AOB毎の異なる暗号鍵を格納した暗号鍵格納ファイルと共に配信し、記録装置において、このTKMG,PLMGの元となる情報を加工することによりTKMG,PLMGを得て、フラッシュメモリカードに記録しても良い。
【０２３７】
（ｄ）説明の便宜上、記録装置、再生装置をそれぞれ別装置としたが、携帯型再生装置に記録装置の機能を具備してもよいし、パソコン型の記録装置に再生装置の機能を具備させてもよい。また、これら携帯型再生装置、パソコン型記録装置以外にも、ネットワークからコンテンツをダウンロードすることができる通信機器に、これら再生装置、記録装置の機能を具備させてもよい。例えば、インタネットのアクセスが可能な携帯型電話機に、第１実施形態に示した再生装置、記録装置の機能を具備させ、携帯型電話機が無線ネットワークを介してダウンロードしたコンテンツを、第１実施形態に示したように、フラッシュメモリカード３１に格納しても良い。更に、本実施形態ではインターネットとの接続のために記録装置は、モデム装置２７を有していたが、これに替えて、ISDN回線との接続を行うためのターミナルアダプタ等を具備していてもよい。
【０２３８】
（ｅ）図５５〜図５８、図６０、図６３〜図６５、図６８のフローチャートを参照して説明した手順等を実行形式プログラムにより実現し、これを記録媒体に記録して流通・販売の対象にしても良い。このような記録媒体には、ICカードや光ディスク、フロッピー（登録商標）ディスク等があるが、これらに記録された機械語プログラムは汎用コンピュータにインストールされることにより利用に供される。この汎用コンピュータは、インストールした実行形式プログラムを逐次実行して、本実施形態に示した再生装置、記録装置の機能を実現するのである。
【０２３９】
（ｆ）本実施形態においてフラッシュメモリカード３１に複数のAOBと、複数のFileKeyとを格納させたが、フラッシュメモリカード３１に1つのAOBと、1つのFileKeyとを格納させてよい。また、AOBの暗号化を行わず、AAC方式のAOBをフラッシュメモリカード３１に格納させてもよい。
（第２実施形態）
第１実施形態では、フラッシュメモリカード３１における記憶領域を示したのみで、その内部にどのようなハードウェア構成が実装されているかの説明は行わなかったが、第２実施形態は、かかるハードウェア構成を詳細に示す実施形態である。
【０２４０】
[69-1] フラッシュメモリカード３１のハードウェア構成
図６９は、フラッシュメモリカード３１のハードウェア構成を示す図である。このフラッシュメモリカード３１は、３つのICチップ（コントロールIC３０２、フラッシュメモリ３０３、ROM３０４）を内蔵している。
ROM３０４は、その内部に第１実施形態に示したシステム領域を有し、第１実施形態に示したメディアIDの他に、そのメディアIDを暗号化して得られるセキュアメディアID３４３も格納されている。
【０２４１】
コントロールIC３０２は、アクティブ素子（論理ゲート等）からなる制御回路であり、認証部３２１、コマンド解読部３２２、マスター鍵記憶部３２３、システム領域アクセス制御部３２４、プロテクト領域アクセス制御部３２５、非プロテクト領域アクセス制御部３２６及び暗号・復号化回路３２７等を有する。
認証部３２１は、COMMANDピンを介して、このフラッシュメモリカード３１にアクセスしようとする機器とチャレンジ・レスポンス型の相互認証を行う回路であり、乱数発生器や暗号器等を有し、その暗号器と同一の暗号器を相手側機器が有しているか否かを検出することによって、相手側機器の正当性を認証する。ここでチャレンジ・レスポンス型の相互認証とは、相手側機器の正当性を検証するためにチャレンジデータを相手側機器に送り、それに対して相手側機器において自己の正当性を証明する処理が施こされて生成されたレスポンスデータを相手側機器から受け取り、それらチャレンジデータとレスポンスデータとを比較することで相手側機器を認証することができるか否かを判断するという認証ステップを、双方の機器が相互に行うことである。
【０２４２】
コマンド解読部３２２は、COMMANDピンを介して入力されたコマンド（このフラッシュメモリカード３１への命令）の種類を判定し実行するデコード回路や制御回路からなるコントローラであり、入力されたコマンドの種類に応じて、各種構成要素３２１〜３２７を制御する。
コマンドには、フラッシュメモリ３０３のデータを読み・書き・消去するコマンド等がある。例えば、データの読み書きに関しては、プロテクト領域にアクセスするためのコマンド「SecureRead address count」、「SecureWrite address count」や、非プロテクト領域にアクセスするためのコマンド「Read address count」、「Write address count」等が定義されている。ここで、「address」は、読み書きの対象となる一連のセクタ群の最初のセクタの番号であり、「count」は、読み書きする合計セクタ数を示す。また、セクタは、フラッシュメモリカード３１に対してデータを読み書きする際の単位であり、ここでは、５１２バイトである。
【０２４３】
マスター鍵記憶部３２３は、暗号化されたマスター鍵３２３aを予め記憶している。マスタ鍵とは、メディアIDの暗号化に用いられる暗号鍵であり、フラッシュメモリカード３１が機器に接続された際、暗号化がなされたまま、その機器に引き渡される。このマスタ鍵の暗号化は、このマスタ鍵を受け取った機器に固有な鍵情報（一般にデバイス鍵と呼ばれる。）を用いた場合のみ復号される。
【０２４４】
システム領域アクセス制御部３２４は、システム領域であるROM３０４に格納されたメディアID等を読み出す回路である。システム領域アクセス制御部３２４により読み出されたメディアIDは、この区間に接続された機器に引き渡され、その機器において、デバイス鍵により復号されたマスタ鍵を用いて暗号化される。プロテクト領域アクセス制御部３２５及び非プロテクト領域アクセス制御部３２６は、それぞれ、フラッシュメモリ３０３のプロテクト領域及び非プロテクト領域へのデータ書き込み及びデータ読み出しを実行する回路であり、４本のデータピンを介して外部機器（第１実施形態に示した記録装置、再生装置等）との間でデータを送受信する。
【０２４５】
なお、これらアクセス制御部３２５、３２６は、内部に１ブロック分のバッファメモリを有し、DATA1〜4ピンを介した入出力を行う。この入出力は、論理的にはセクタを単位として行われるが、フラッシュメモリ３０３の内容を書き換えるときには、ブロック（３２個のセクタ、１６Kバイト）を単位として入出力する。具体的には、ある１個のセクタデータを書き換える場合には、フラッシュメモリ３０３から該当するブロックをバッファメモリに読み出し、そのブロックを一括消去するともに、バッファメモリ中の該当セクタを書き換えた後に、そのブロックをバッファメモリからフラッシュメモリ３０３に書き戻す。
【０２４６】
暗号・復号化回路３２７は、プロテクト領域アクセス制御部３２５及び非プロテクト領域アクセス制御部３２６による制御の下で、マスター鍵記憶部３２３に格納されたマスター鍵３２３aを用いて暗号化及び復号化を行う回路であり、フラッシュメモリ３０３にデータを書き込む際にそのデータを暗号化して書き込み、フラッシュメモリ３０３からデータを読み出した際にそのデータを復号化する。これは、不正なユーザがこのフラッシュメモリカード３１を分解してフラッシュメモリ３０３の内容を直接解析し、プロテクト領域に格納されたパスワードを盗む等の不正行為を防止するためである。
【０２４７】
[69_70] AOBを再生する場合の通信シーケンス
図７０は、フラッシュメモリカード３１に接続された再生装置が、暗号鍵FileKeyを読み出して、AOBを再生する場合の通信シーケンスを示す図である。
再生装置は、フラッシュメモリカード３１にマスタ鍵を読み出す旨のコマンドを発行する(sc1)。コマンドが発行されると、コマンド解読部３２２は、マスター鍵記憶部３２３に記憶されている暗号化マスター鍵３２３bを取り出し、再生装置に引き渡す(sc2)。
【０２４８】
暗号化マスター鍵３２３bを受け取った再生装置は、自身が保持しているデバイス鍵２１１aを用いて暗号化マスター鍵３２３bを復号する(sc3)。この復号処理に用いられる復号アルゴリズムは、フラッシュメモリカード３１に格納されている暗号化マスター鍵３２３bが生成された際に用いられた暗号アルゴリズムに対応したものなので、この再生装置が有するデバイス鍵２１１aが予定されたもの（正規のもの）であれば、この復号によってマスター鍵は正常に復元されることなる。
【０２４９】
マスタ鍵を得た再生装置は、フラッシュメモリカード３１にメディアIDを読み出す旨の専用コマンドをフラッシュメモリカード３１に発行する(sc4)。システム領域アクセス制御部３２４は、フラッシュメモリカード３１のROM３０４に記憶されているメディアIDを取り出し、再生装置に引き渡す(sc5)。暗号・復号化回路３２７は、復元により得られた上記マスター鍵を用いて、取り出されたメディアIDを暗号化する(sc6)。ここでの暗号アルゴリズムは、フラッシュメモリカード３１に格納されているセキュアメディアID３４３が生成された際に用いられた暗号アルゴリズムと同一である。従って、この暗号化によって、フラッシュメモリカード３１が有するセキュアメディアID３４３と同一のセキュアメディアIDが得られる。
【０２５０】
同一セキュアメディアIDを得ることに成功した再生装置は、フラッシュメモリカード３１における認証部３２１との相互認証を行なう(sc7)。その結果、いずれの機器においても、相手側機器の認証に成功したか否かを示す（OK／NG）情報と、その認証結果に依存して定まる時変の鍵であるセキュア鍵とを両者は享有することなる。
【０２５１】
相互認証に成功した再生装置は、フラッシュメモリカード３１のプロテクト領域にアクセスするためのコマンドを生成する。例えばプロテクト領域からデータを読み出す場合であれば、そのコマンド「SecureRead address count」のパラメータ（２４ビット長のアドレス「address」と８ビット長のカウント「count」）をセキュア鍵で暗号化し(sc8)、得られた暗号化パラメータと、そのコマンドのタグ（コマンドの種類「SecureRead」を示す６ビット長のコード）とを連結することにより暗号化コマンドを生成して(sc9)、フラッシュメモリカード３１に送る(sc10)。
【０２５２】
暗号化コマンドを受け取ったフラッシュメモリカード３１は、そのタグからコマンドの種類を判定する(sc11)。ここでは、プロテクト領域からの読出コマンド「SecureRead」であると判定する。
読出コマンドであると判定した場合、暗号・復号化回路３２７は、そのコマンドに含まれていたパラメータを、相互認証で得られたセキュア鍵を用いて(sc12)復号する(sc13)。ここでの復号に用いられるアルゴリズムは、再生装置において暗号化コマンドを生成する際に用いられた暗号アルゴリズムに対応するので、相互認証が成功していれば、即ち、双方の機器で用いられるセキュア鍵が一致していれば、この復号によって得られるパラメータは、再生装置で用いられた元のパラメータに等しくなる。
【０２５３】
正当なパラメータを含むコマンドを得たプロテクト領域アクセス制御部３２５は、その正当なパラメータによって特定されるセクタをアクセスして、そこに格納された暗号鍵FileKeyをプロテクト領域から読み出す。暗号・復号化回路３２７は、相互認証により得られたセキュア鍵を用いて(sc14)、プロテクト領域のAOBSA1.KEYに格納されている暗号鍵FileKeyを暗号化する(sc15)。暗号・復号化回路３２７による暗号化が行われると、プロテクト領域アクセス制御部３２５は、プロテクト領域のAOBSA1.KEYに格納されている暗号鍵FileKeyを再生装置に送信して引き渡す(sc16)。
【０２５４】
再生装置は、送られてきた暗号鍵FileKeyを、相互認証で得られたセキュア鍵を用いて(sc17)、復号する(sc18)。ここでの復号アルゴリズムは、フラッシュメモリカード３１において暗号鍵FileKeyの暗号化に用いられたアルゴリズムに対応するので、相互認証が成功していれば、即ち、双方の機器で用いられるセキュア鍵が一致していれば、この復号により、元の暗号鍵FileKeyを得ることができる(sc19)。その後、得られた暗号鍵FileKeyをマスター鍵３２３aとメディアIDで復号化し、暗号鍵FileKeyを抽出する(sc20)。
【０２５５】
暗号鍵FileKeyが得られ、非プロテクト領域からこの暗号鍵FileKeyに対応するAOBが読み出されると(sc21)、AOBをこの暗号鍵FileKeyを用いて復号しながら音楽を再生していく。
[69_70_71] 相互認証における詳細な通信シーケンス
図７１は、図７０に示された相互認証における詳細な手順を示す通信シーケンス図である。ここでは、フラッシュメモリカード３１と再生装置は、チャレンジ・レスポンス型の相互認証を行う。
【０２５６】
フラッシュメモリカード３１における認証部３２１は、再生装置の正当性を検証するために、乱数を生成し(sc30)、それをチャレンジデータとして再生装置に送る(sc50)。再生装置は、自己の正当性を証明するために、そのチャレンジデータを暗号化し(sc31)、レスポンスデータとしてフラッシュメモリカード３１における認証部３２１に返す(sc32)。フラッシュメモリカード３１における認証部３２１は、チャレンジデータとして送った乱数を暗号化し(sc33)、そのレスポンスデータと、暗号化チャレンジデータとを比較する(sc34)。一致している場合には、再生装置の認証に成功した（OK）と認識し、その再生装置から送られてくるプロテクト領域へのアクセスコマンドを受け付ける。一方、比較の結果、一致しなかった場合には、認証に成功しなかった（NG）と認識し、もし、その後に再生装置からプロテクト領域へのアクセスコマンドが送られてきたとしても、その実行を拒絶する。
【０２５７】
同様にして、再生装置は、フラッシュメモリカード３１の正当性を検証するために、上記認証と同様のやりとりを行う。つまり、乱数を生成し(sc40)、それをチャレンジデータとしてフラッシュメモリカード３１における認証部３２１に送る(sc51)。認証部３２１は、自己の正当性を証明するために、そのチャレンジデータを暗号化し(sc41)、レスポンスデータとして再生装置に返す。再生装置は、チャレンジデータとして送った乱数を暗号化し(sc43)、その結果得られる暗号化チャレンジデータと、そのレスポンスデータとを比較し(sc44)、一致している場合には、フラッシュメモリカード３１の認証に成功した（OK）と認識し、そのフラッシュメモリカード３１のプロテクト領域へのアクセスを行う。一方、比較の結果、一致しなかった場合には、認証に成功しなかった（NG）と認識し、そのフラッシュメモリカード３１のプロテクト領域へのアクセスは断念する。
【０２５８】
なお、これら相互認証における暗号化アルゴリズムは、フラッシュメモリカード３１及び再生装置が正当な機器である限り、全て同一である。また、フラッシュメモリカード３１及び再生装置は、それぞれの認証及び証明において生成した暗号化チャレンジデータとレスポンスデータとを排他的論理和演算を行い(sc45,46)、得られた結果をセキュア鍵として、フラッシュメモリカード３１のプロテクト領域へのアクセスのために用いる。そうすることで、フラッシュメモリカード３１と、これに接続された機器との相互認証に成功した場合にのみ共通となり、かつ、時変のセキュア鍵を共有し合うことが可能となり、これによって、プロテクト領域にアクセスする条件として相互認証に成功していることが条件とされることになる。
【０２５９】
また、セキュア鍵の生成方法として、暗号化チャレンジデータとレスポンスデータとセキュアメディアIDとの排他的論理和をとることしてもよい。
以上のように本実施形態によれば、これにより、著作権保護に関わるデータをプロテクト領域に格納し、そうでないデータを非プロテクト領域に格納することで、デジタル著作物と非著作物とを混在させて使用することができ、両方の用途を兼ね備えた半導体メモリカードが実現される。
【０２６０】
【発明の効果】
本発明に係る半導体メモリカードは、プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示している。
【０２６１】
複数のオーディオオブジェクトは、複数の暗号鍵にて暗号化することが可能であるので、1つのオーディオオブジェクトを暗号化に用いられた暗号鍵が解読され、暴露されたとしても、その解読によって復号できるそのオーディオオブジェクト唯1つだけであり、他のオーディオオブジェクトには何の影響も及ばないので、暗号鍵が暴露された場合の損失を最小限に抑える事ができる。
【０２６２】
暗号化された複数のオーディオオブジェクトをどのようなオーディオトラックとして管理するかは、属性情報に示されているので、例えば2つのオーディオオブジェクトが、2つの独立したオーディオトラックとして管理されている場合、これら2つのオーディオオブジェクトにおける属性情報を、オーディオトラックの先頭部分と、オーディオトラックの終端部分とに変更することにより、2つのオーディオオブジェクトを1つのオーディオトラックに統合することができる。属性情報変更によりオーディオトラックの統合編集が行なえるので、オーディオオブジェクトの暗号化をむやみに解除することなく、統合編集を高速に行うことができる。
【０２６３】
オーディオフレームの前方に無効部分が存在する場合に、その無効部分のデータ長がどれだけであるか、有効部分のデータ長がどれだけであるかは、ブロック情報により設定されるので、格納されている音楽が、エアチェックして録音された音楽であり、その音楽のイントロの部分にディスクジョッキーの音声が混じっている場合、ブロック情報におけるデータオフセットを設定することにより、この不要音声をオーディオオブジェクトから除外して再生させないようにすることができる。ブロック情報の設定により、不要音声を再生させないように設定することが可能なので、オーディオオブジェクトの一部を削除するという編集がオーディオオブジェクトの暗号化を解除することなく、高速に行うことができる。
【図面の簡単な説明】
【図１】フラッシュメモリカード３１を上面から見た場合の形状を示す図である。
【図２】フラッシュメモリカード３１をその下面から見た場合の形状を示す図である。
【図３】本実施形態に係るフラッシュメモリカード３１の階層構造を示す図である。
【図４】（ａ）フラッシュメモリカード３１の物理層に設けられたシステム領域と、プロテクト領域と、ユーザデータ領域の構成を示す図である。
（ｂ）ファイルシステム層におけるプロテクト領域及びユーザデータ領域の構成を示す図である。
【図５】ファイルシステム層における構成の詳細を示す図である。
【図６】 AOB001.SA1をクラスタサイズに合わせて5つに分割し、各分割部分を、クラスタ003,004,005,00A,00Cに格納する状態を想定した図である。
【図７】 AOB001.SA1が複数のクラスタに記録されている場合のディレクトリエントリー及びファイルアロケーションテーブルについての設定例を示す図である。
【図８】（ａ）（ｂ）応用層におけるこれら2つのデータを格納する場合、ファイルシステム層においてユーザデータ領域及びプロテクト領域には、どのようなディレクトリが構成され、どのようなファイルが当該ディレクトリの配下に作成されるかを示す図である。
【図９】 SD_Audioディレクトリの下にあるAOBSA1.KEYと、AOBファイルとの対応を示す図である。
【図１０】 AOBファイルのデータ構成を階層的に示す図である。
【図１１】（ａ）ISO/IEC13818-7に記述されているパラメータを表形式に示す図である。
（ｂ）MPEG-Layer3(MP3)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
（ｃ）Windows（登録商標） Media Audio(WMA)方式にて符号化する際に使用すべきパラメータを表形式に示す図である。
【図１２】 AOB_FRAMEの構成の詳細を示す図である。
【図１３】 3つのAOB_FRAMEにおいて、それぞれのAOB_FRAMEにおけるオーディオデータのバイト長がどのように設定されるかを示す図である。
【図１４】 sampling_frequencyと、AOB_ELEMENTに含まれるAOB_FRAME数との対応を示す図である。
【図１５】 AOB_ELEMENTの時間長及びAOB_FRAMEの時間長の一例を示す図である。
【図１６】 AOBファイルに収録されている各AOB、AOB_BLOCKが連続して再生されることにより、どのような再生内容が再生されるかを示す図である。
【図１７】第１実施形態におけるPlaylistmanager及びTrackManagerの構成を段階的に詳細化した図である。
【図１８】 PlayListManager及びTrackManagerのサイズを示す図である。
【図１９】図１７に示したTKIと、図１６に示したAOBファイル及びAOBとの相互関係を示す図である。
【図２０】図１７に示したTKTMSRTの詳細なデータ構造を示す図である。
【図２１】 TKTMSRTについての一例を示す図である。
【図２２】 TKGIの詳細構成を示す図である。
【図２３】（ａ）（ｂ）BITの詳細構成を示す図である。
（ｃ）TIME_LENGTHフィールドのデータフォーマットを示す図である。
【図２４】 AOB_ELEMENT#1〜#4からなるAOBが格納されているクラスタ007〜クラスタ00Eを示す図である。
【図２５】 AOB内の任意のAOB_ELEMENT#yにおけるAOB_FRAME#xから順方向サーチ再生を行う場合、次に再生すべきAOB_FRAME#x+1をどのように設定するかを示す図である。
【図２６】（ａ）（ｂ）任意の再生開始時刻が指定された場合、その指定時刻に対応するAOB、AOB_ELEMENT、AOB_FRAMEをどのように特定するかを示す図である。
【図２７】（ａ）（ｂ）トラックを削除する場合を想定した図である。
【図２８】（ａ）トラックの削除が複数回行われた後のTrackManagerを示す図である。
（ｂ）『Unused』のTKIが存在しており、ここに新たなTKI、AOBファイルを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図２９】（ａ）（ｂ）2つのトラックを統合する場合にTKIがどのように設定されるかを示す図である。
【図３０】（ａ） Type1のAOBを示す図である。
（ｂ）Type2のAOBを示す図である。
【図３１】（ａ）Type1＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
（ｂ）Type1＋Type2＋Type2＋Type2＋Type1の組み合わせで、複数トラックを1つに統合する場合を示す図である。
【図３２】（ａ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｂ）先行するトラックの終端にType1のAOBが配され、後続するトラックの先頭にType2のAOBが配されている配置パターンを示す図である。
（ｃ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
（ｄ） 先行するトラックの終端にType1、Type2順でAOBが配され、後続するトラックの先頭に、Type2、Type1のAOBが配されている配置パターンを示す図である。
（ｅ） 先行するトラックの終端にType2、Type2のAOBが配され、後続するトラックの先頭にType1のAOBが配されている配置パターンを示す図である。
【図３３】（ａ）（ｂ）1つのトラックを2つのトラックに分割する場合を想定した図である。
【図３４】（ａ）（ｂ）分割前後において、AOB003.SA1が属するSD_AudioディレクトリについてのSD_Audioディレクトリエントリーがどのように記述されているかかを示す図である。
【図３５】（ａ）AOBをAOB_ELEMENT#2の途中部分で分割する場合を想定した図である。
（ｂ）AOB_ELEMENT#2の途中部分でAOBが分割されて、AOB_1、AOB_2という2つのAOBが得られた状態を示す図である。
【図３６】図３５に示したようにAOBが分割された場合に、BITがどのように設定されるかを示す図である。
【図３７】分割の前後でBITがどのように変化するかを具体的に示す図である。
【図３８】分割の前後でTKTMSRTがどのように変化するかを具体的に示す図である。
【図３９】（ａ）DPL_TK_SRPのフォーマットを示す図である。
（ｂ）PL_TK_SRPのフォーマットを示す図である。
【図４０】 Default_Playlist情報、TKI、AOBファイルの相互関係を示す図である。
【図４１】 DefaultPlaylist、PlayList情報の設定例を、図４０と同様の表記で示した図である。
【図４２】図４０と同じ表記法を用いてDPL_TK_SRPとTKIとの対応を示す図である。
【図４３】（ａ）（ｂ）トラックの順序を入れ替える場合を想定した図である。
【図４４】（ａ）（ｂ）図４０に示したDefaultPlaylistのうち、DPL_TK_SRP#2及びTKI#2を削除する場合にDefaultPlaylist、TrackManager、AOBファイルがどのように更新されるかを示す図である。
【図４５】（ａ）（ｂ）『Unused』のTKIと、DPL_TK_SRPとが存在しており、ここに新たなTKI、DPL_TK_SRPを書き込む場合、その書き込みがどのように行われるかを示す図である。
【図４６】（ａ）（ｂ）トラックの統合を行う場合を想定した図である。
【図４７】（ａ）（ｂ）トラックの分割を行う場合を想定した図である。
【図４８】本実施形態に係るフラッシュメモリカード３１についての携帯型の再生装置を示す図である。
【図４９】プレイリストの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５０】（ａ）〜（ｅ）トラックの選択が行われる際の液晶ディスプレィの表示内容の一例を示す図である。
【図５１】（ａ）〜（ｃ）ジョグダイアルの操作例を示す図である。
【図５２】再生装置の内部構成を示す図である。
【図５３】ダブルバッファ１５におけるデータ入出力がどのように行われるかを示す図である。
【図５４】（ａ）（ｂ）リングポインタを用いた巡回式の領域確保がどのように行われるかを示す図である。
【図５５】 AOBファイル読み出し処理の処理手順を示すフローチャートである。
【図５６】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５７】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５８】 AOB_FRAME出力処理の処理手順を示すフローチャートである。
【図５９】（ａ）〜（ｄ）液晶ディスプレィ５の時刻表示枠に表示される再生経過時刻が、変数Play_Timeの更新したがい、増加してゆく様子を示す図である。
【図６０】順方向サーチ再生処理時におけるCPU１０の処理手順を示すフローチャートである。
【図６１】（ａ）〜（ｄ）順方向サーチ再生時において、再生経過時刻がインクリメントされてゆく様子を示す図である。
【図６２】（ａ）〜（ｂ）タイムサーチ機能が行われる場合の具体例を示す図である。
【図６３】編集制御プログラムの処理手順を示すフローチャートである。
【図６４】編集制御プログラムの処理手順を示すフローチャートである。
【図６５】編集制御プログラムの処理手順を示すフローチャートである。
【図６６】フラッシュメモリカード３１の記録装置の一例を示す図である。
【図６７】記録装置のハードウェア構成を示す図である。
【図６８】記録処理の処理手順を示すフローチャートである。
【図６９】フラッシュメモリカード３１のハードウェア構成を示す図である。
【図７０】フラッシュメモリカード３１に接続された再生装置が、暗号鍵FileKeyを読み出して、AOBを再生する場合の通信シーケンスを示す図である。
【図７１】図７０に示された相互認証における詳細な手順を示す通信シーケンス図である。
【符号の説明】
１ カードコネクタ
２ ユーザインターフェイス部
３ RAM
４ ROM
５ 液晶ディスプレィ
６ LCDドライバ
７ デ・スクランブラ
８ AACデコーダ
９ A/Dコンバータ
１１ DPLI常駐領域
１２ PLI格納領域
１３ TKI格納領域
１４ FileKey格納領域
１５ ダブルバッファ
２１ カードコネクタ
２２ RAM
２３ 固定ディスク装置
２４ コンバータ
２４ A/DステップＳ
２５ AACエンコーダ
２６ スクランブル部
２７ モデム装置
２８ CPU
２９ キーボード
３０ ディスプレィ
３１ フラッシュメモリカード
３２ プロテクトスイッチ
２１１ デバイス鍵
３０３ フラッシュメモリ
３２１ 認証部
３２２ コマンド解読部
３２３ マスター鍵
３２４ システム領域アクセス制御部
３２５ プロテクト領域アクセス制御部
３２６ 非プロテクト領域アクセス制御部
３２７ 復号化回路

Claims (5)

  1. プロテクト領域と非プロテクト領域とを備える半導体メモリカードであって、
    プロテクト領域には、接続される機器と半導体メモリカードの間で互いの正当性が認証された場合のみ、当該機器によりアクセスできる領域であるとともに、複数の暗号鍵を所定の順序に配列してなる暗号鍵列が格納され、
    非プロテクト領域には、複数の暗号化されたオーディオオブジェクトと、管理情報が格納され、
    各オーディオオブジェクトは、固有識別情報を有し、再生すべき有効部分のみからなるものと、有効部分と共に、再生不要な無効部分をその先端及び／又は終端に含むものがあり、
    各暗号鍵は、固有識別情報によって各オーディオオブジェクトと対応付けられるとともに、対応するオーディオオブジェクトを復号化し、
    管理情報は、属性情報と、ブロック情報と、リンク情報と、プレイリストを含み、
    属性情報は、各オーディオオブジェクトが、オーディオトラックの先頭部分、中間部分、終端部分、全体部分のいずれであるかを示し、
    ブロック情報は、各オーディオオブジェクトの有効部分の開始位置を示すオフセットと、当該オフセットからの有効部分のデータ長とを示し、
    リンク情報は、オーディオトラックの先頭部分又は中間部分を構成するオーディオオブジェクトについて、それらに後続される中間部分又は終端部分との接続関係を有するオーディオオブジェクトを示し、
    プレイリストは、オーディオトラックの再生順序を示すとともに、各オーディオトラックにおけるオーディオオブジェクトの再生順序を示す、半導体メモリカード。
  2. 前記オーディオトラックの再生には、オーディオオブジェクトの有効部分の再生をスキップすることなく行う通常再生と、オーディオオブジェクトの有効部分を所定の第１時間ずつスキップし、スキップの度に同有効部分の再生を所定の第２時間だけ行うオーディオトラックの間欠再生とがあり、
    前記オーディオトラックは更に、複数のオーディオオブジェクトのそれぞれに１対１の比率で割り当てられた複数のエントリー位置情報を含み、
    複数のエントリー位置情報は、オーディオオブジェクト内部の、第１時間おきの位置を示す、請求項１記載の半導体メモリカード。
  3. 請求項１記載の半導体メモリカードについての再生装置であって、
    プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出し手段と、
    接続される半導体メモリカードと再生装置の間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証手段と、
    認証手段で認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出し手段と、
    読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号手段と、
    復号されたオーディオオブジェクトを前記オフセット位置から再生する再生手段とを備える、再生装置。
  4. 請求項１記載の半導体メモリカードについての再生手順をコンピュータに行わせるプログラムをコンピュータ読取可能な形式で記録している記録媒体であって、
    プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出しステップと、
    接続される半導体メモリカードとコンピュータの間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証ステップと、
    認証ステップで認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出しステップと、
    読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号ステップと、
    復号されたオーディオオブジェクトを前記オフセット位置から再生する再生ステップと、
    を含む手順をコンピュータに行わせるプログラムが記録されているコンピュータ読取可能な記録媒体。
  5. 請求項１記載の半導体メモリカードを再生するコンピュータにおいて適用される再生方法であって、
    プレイリストに基づいて、再生すべきオーディオトラック内のオーディオオブジェクトを特定し、特定したオーディオオブジェクトを半導体メモリカードの非プロテクト領域から読み出す第１読み出しステップと、
    接続される半導体メモリカードとコンピュータの間で互いの正当性が認証された場合のみ、当該半導体メモリカードのプロテクト領域へのアクセスを許可する認証ステップと、
    認証ステップで認証に成功した場合に、再生すべきオーディオオブジェクトに対応する暗号鍵をプロテクト領域から読み出す第２読み出しステップと、
    読み出されたオーディオオブジェクトを、読み出された暗号鍵を用いて復号する復号ステップと、
    復号されたオーディオオブジェクトを前記オフセット位置から再生する再生ステップと
    を含む、再生方法。
JP2003092578A 1999-05-28 2003-03-28 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体 Expired - Lifetime JP4150278B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003092578A JP4150278B2 (ja) 1999-05-28 2003-03-28 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP14989399 1999-05-28
JP23672499 1999-08-24
JP37260699 1999-12-28
JP2003092578A JP4150278B2 (ja) 1999-05-28 2003-03-28 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2000156757A Division JP3425119B2 (ja) 1999-05-28 2000-05-26 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体

Publications (3)

Publication Number Publication Date
JP2004030586A JP2004030586A (ja) 2004-01-29
JP2004030586A5 JP2004030586A5 (ja) 2007-06-14
JP4150278B2 true JP4150278B2 (ja) 2008-09-17

Family

ID=27319843

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2000156757A Expired - Lifetime JP3425119B2 (ja) 1999-05-28 2000-05-26 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体
JP2003092578A Expired - Lifetime JP4150278B2 (ja) 1999-05-28 2003-03-28 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2000156757A Expired - Lifetime JP3425119B2 (ja) 1999-05-28 2000-05-26 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体

Country Status (10)

Country Link
US (3) US6865431B1 (ja)
EP (1) EP1056092B1 (ja)
JP (2) JP3425119B2 (ja)
CN (1) CN1187756C (ja)
BR (1) BR0006882B1 (ja)
CA (1) CA2338634C (ja)
DE (1) DE60035455T2 (ja)
ID (1) ID27746A (ja)
MY (1) MY125354A (ja)
WO (1) WO2000074059A1 (ja)

Families Citing this family (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2769736C (en) 1997-07-09 2013-05-14 Advanced Audio Devices, Llc Device for editing and non-volatile optical storage of digital audio
US7558472B2 (en) * 2000-08-22 2009-07-07 Tivo Inc. Multimedia signal processing system
US8577205B2 (en) 1998-07-30 2013-11-05 Tivo Inc. Digital video recording system
US8380041B2 (en) * 1998-07-30 2013-02-19 Tivo Inc. Transportable digital video recorder system
US6233389B1 (en) * 1998-07-30 2001-05-15 Tivo, Inc. Multimedia time warping system
CA2338695C (en) * 1999-05-28 2009-07-07 Matsushita Electric Industrial Co., Ltd. Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium
CN1196130C (zh) * 1999-05-28 2005-04-06 松下电器产业株式会社 半导体存储器卡、重放装置、记录装置、重放方法、记录方法、和计算机可读存储介质
WO2001022729A1 (en) 1999-09-20 2001-03-29 Tivo, Inc. Closed caption tagging system
JP2002042451A (ja) * 2000-07-24 2002-02-08 Victor Co Of Japan Ltd オーディオデータ記録再生ディスク及びその再生装置、再生方法並びに記録方法
ATE426674T1 (de) * 2000-11-03 2009-04-15 Genentech Inc Stoffwechselanderungen in garungen zur produktion rekombinanter proteine
AU2002232494A1 (en) * 2000-12-07 2002-06-18 Sandisk Corporation System, method, and device for playing back recorded audio, video or other content from non-volatile memory cards, compact disks or other media
KR100852311B1 (ko) * 2001-01-26 2008-08-14 소니 가부시끼 가이샤 집적회로 카드 및 집적회로 카드 어댑터 장치
JP2002268874A (ja) * 2001-03-07 2002-09-20 Toshiba Corp 乱数シード生成回路及びこれを備えたドライバ、並びに、ｓｄメモリカードシステム
US7220615B2 (en) * 2001-06-11 2007-05-22 Micron Technology, Inc. Alternative method used to package multimedia card by transfer molding
JP3849465B2 (ja) * 2001-06-27 2006-11-22 富士通株式会社 情報管理方法
JP2003032634A (ja) * 2001-07-13 2003-01-31 Canon Inc 再生装置及びその方法
KR20040015818A (ko) * 2001-07-18 2004-02-19 마츠시타 덴끼 산교 가부시키가이샤 기입장치, 반도체 메모리 카드, 기입프로그램 및 기입방법
US7327486B2 (en) * 2001-08-23 2008-02-05 Hewlett-Packard Development Company, L.P. Printing device with reader for removable media storage container
GB0123417D0 (en) * 2001-09-28 2001-11-21 Memquest Ltd Improved data processing
EP1440439A1 (en) * 2001-10-12 2004-07-28 Koninklijke Philips Electronics N.V. Apparatus and method for reading or writing block-wise stored user data
JP2003123044A (ja) * 2001-10-18 2003-04-25 Sanyo Electric Co Ltd アクセス制御方法及び電子機器
JP2003132622A (ja) * 2001-10-22 2003-05-09 Victor Co Of Japan Ltd 記録装置、再生装置及び記録媒体
JP4408601B2 (ja) * 2001-12-27 2010-02-03 富士通株式会社 情報再生装置およびセキュアモジュール
JP3849528B2 (ja) * 2002-01-11 2006-11-22 ヤマハ株式会社 電子音楽装置およびプログラム
US7065651B2 (en) * 2002-01-16 2006-06-20 Microsoft Corporation Secure video card methods and systems
US20030145183A1 (en) * 2002-01-31 2003-07-31 Muehring Phillip T. Applications for removable storage
US7174017B2 (en) * 2002-03-04 2007-02-06 Lenovo Singapore Pte, Ltd Decryption system for encrypted audio
GB2386245B (en) * 2002-03-08 2005-12-07 First 4 Internet Ltd Data protection system
JP2003323761A (ja) * 2002-05-02 2003-11-14 Sony Corp デジタルデータの記録媒体、記録方法、記録装置、再生方法、再生装置、送信方法および送信装置
US7515173B2 (en) * 2002-05-23 2009-04-07 Microsoft Corporation Head pose tracking system
US7634532B2 (en) 2002-05-31 2009-12-15 Onkyo Corporation Network type content reproduction system
US8155314B2 (en) * 2002-06-24 2012-04-10 Microsoft Corporation Systems and methods for securing video card output
US7228054B2 (en) * 2002-07-29 2007-06-05 Sigmatel, Inc. Automated playlist generation
CA2462192C (en) 2002-09-07 2013-07-30 Lg Electronics Inc. Recording medium having data structure for managing reproduction of still images from a clip file recorded thereon and recording and reproducing methods and apparatuses
KR20040022640A (ko) * 2002-09-09 2004-03-16 삼성전자주식회사 컴퓨터시스템 및 컴퓨터시스템의 데이터전송방법
US7136874B2 (en) 2002-10-16 2006-11-14 Microsoft Corporation Adaptive menu system for media players
US7668842B2 (en) * 2002-10-16 2010-02-23 Microsoft Corporation Playlist structure for large playlists
US7043477B2 (en) * 2002-10-16 2006-05-09 Microsoft Corporation Navigating media content via groups within a playlist
US7054888B2 (en) 2002-10-16 2006-05-30 Microsoft Corporation Optimizing media player memory during rendering
JP4660073B2 (ja) * 2002-10-18 2011-03-30 株式会社東芝 暗号化記録装置、再生装置及びプログラム
US8204226B2 (en) 2002-10-18 2012-06-19 Kabushiki Kaisha Toshiba Encoding and recording apparatus, playback apparatus, and program
CA2474229C (en) 2002-11-20 2014-11-04 Lg Electronics Inc. Recording medium having data structure for managing reproduction of still images recorded thereon and recording and reproducing methods and apparatuses
US7478248B2 (en) * 2002-11-27 2009-01-13 M-Systems Flash Disk Pioneers, Ltd. Apparatus and method for securing data on a portable storage device
US7293178B2 (en) * 2002-12-09 2007-11-06 Microsoft Corporation Methods and systems for maintaining an encrypted video memory subsystem
MXPA05006428A (es) * 2002-12-17 2005-08-19 Thomson Licensing Sa Metodo y aparato para etiquetar y desplegar canciones en un reproductor de audio digital.
WO2004066282A1 (en) 2003-01-20 2004-08-05 Lg Electronics Inc. Recording medium having data structure for managing reproduction of still pictures recorded thereon and recording and reproducing methods and apparatuses
US7734154B2 (en) 2003-02-14 2010-06-08 Lg Electronics Inc. Recording medium having data structure for managing reproduction duration of still pictures recorded thereon and recording and reproducing methods and apparatuses
JP2004302921A (ja) * 2003-03-31 2004-10-28 Toshiba Corp オフライン情報を利用したデバイス認証装置及びデバイス認証方法
KR100860985B1 (ko) * 2003-05-23 2008-09-30 삼성전자주식회사 패딩 정보를 이용한 기록/재생 방법
US20060156355A1 (en) * 2003-06-11 2006-07-13 Masahiro Kawasaki Reproduction apparatus, program, integrated circuit
JP4624732B2 (ja) * 2003-07-16 2011-02-02 パナソニック株式会社 アクセス方法
CN100440179C (zh) * 2003-08-14 2008-12-03 索尼株式会社 信息处理装置和方法
JP4336957B2 (ja) 2003-09-30 2009-09-30 日本電気株式会社 トランスポートストリームの暗号化装置及び編集装置並びにこれらの方法
US7644446B2 (en) * 2003-10-23 2010-01-05 Microsoft Corporation Encryption and data-protection for content on portable medium
FI20035235A0 (fi) * 2003-12-12 2003-12-12 Nokia Corp Järjestely tiedostojen käsittelemiseksi päätelaitteen yhteydessä
EP2506486A1 (en) 2004-02-23 2012-10-03 Lexar Media, Inc. Secure compact flash
CN100571132C (zh) * 2004-03-22 2009-12-16 国际商业机器公司 多密钥内容处理***和方法
JP4643164B2 (ja) 2004-03-29 2011-03-02 パナソニック株式会社 コンテンツ送信装置及びコンテンツ受信装置
US20050238314A1 (en) * 2004-03-30 2005-10-27 Sako Asayama Recording system, recording apparatus, recording method, recording program and recording medium
JP4701175B2 (ja) 2004-06-30 2011-06-15 パナソニック株式会社 記録媒体並びに記録媒体に情報を記録する記録装置及び記録方法
US8090920B2 (en) 2004-07-06 2012-01-03 Panasonic Corporation Recording medium, and information processing device and information processing method for the recording medium
KR101174131B1 (ko) * 2004-10-14 2012-08-14 삼성전자주식회사 멀티미디어 방송 수신시의 에러 검출 방법 및 장치
JP4794269B2 (ja) * 2004-11-08 2011-10-19 パナソニック株式会社 セキュアデバイスおよび中継端末
JP3847764B2 (ja) * 2004-11-12 2006-11-22 オンキヨー株式会社 ネットワーク型コンテンツ再生システム
US7895633B2 (en) 2004-11-19 2011-02-22 Tivo Inc. Method and apparatus for secure transfer and playback of multimedia content
KR20060066626A (ko) * 2004-12-13 2006-06-16 엘지전자 주식회사 컨텐트의 암호/해독을 위한 키를 기록하고 사용하는 방법및 장치와 그 방법에 의해 키가 기록되어 있는 기록매체
TW200636554A (en) * 2004-12-21 2006-10-16 Sandisk Corp Memory ststem with versatile content control
JP4701748B2 (ja) * 2005-02-25 2011-06-15 ソニー株式会社 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
US8363837B2 (en) * 2005-02-28 2013-01-29 HGST Netherlands B.V. Data storage device with data transformation capability
KR20070119650A (ko) * 2005-03-18 2007-12-20 토니움 에이비 디스크자키 기능이 내장된 휴대용 컴퓨팅 디바이스
US7634494B2 (en) * 2005-05-03 2009-12-15 Intel Corporation Flash memory directory virtualization
US7788701B1 (en) * 2005-07-26 2010-08-31 Advanced Micro Devices, Inc. Content transfer restriction system for personal internet communicator
EP1953671A4 (en) * 2005-10-31 2010-12-29 Panasonic Corp CONTENT DATA STRUCTURE AND MEMORY CARD
WO2007094874A2 (en) * 2005-11-18 2007-08-23 Sandisk Corporation Method and system for managing keys and/or rights objects
US8156563B2 (en) 2005-11-18 2012-04-10 Sandisk Technologies Inc. Method for managing keys and/or rights objects
AU2007243473A1 (en) * 2006-04-24 2007-11-08 Encryptakey, Inc. Portable device and methods for performing secure transactions
JP5027805B2 (ja) * 2006-06-15 2012-09-19 パナソニック株式会社 メモリコントローラ、不揮発性記憶装置、及び不揮発性記憶装置システム
US7508609B2 (en) * 2006-10-25 2009-03-24 Spectra Logic Corporation Formatted storage media providing space for encrypted text and dedicated space for clear text
US8285757B2 (en) * 2007-01-31 2012-10-09 Agency For Science, Technology And Research File system for a storage device, methods of allocating storage, searching data and optimising performance of a storage device file system
JP4259588B2 (ja) * 2007-03-30 2009-04-30 富士ゼロックス株式会社 情報処理システム及び情報処理プログラム
JP5006388B2 (ja) * 2007-04-19 2012-08-22 パナソニック株式会社 データ管理装置
JP5175494B2 (ja) * 2007-07-13 2013-04-03 株式会社日立製作所 暗号化コンテンツ編集方法およびコンテンツ管理装置
JP4469879B2 (ja) * 2007-08-07 2010-06-02 株式会社東芝 半導体メモリ蓄積装置とその素材管理方法
JP5406044B2 (ja) * 2007-12-17 2014-02-05 パナソニック株式会社 個別販売に用いられる記録媒体、記録装置、再生装置、それらの方法
TW200933362A (en) * 2008-01-30 2009-08-01 Coretronic Corp Memory card and accessing method and accessing system for the same
JP5248153B2 (ja) * 2008-03-14 2013-07-31 株式会社東芝 情報処理装置、方法及びプログラム
US8695087B2 (en) * 2008-04-04 2014-04-08 Sandisk Il Ltd. Access control for a memory device
JP2009284019A (ja) * 2008-05-19 2009-12-03 Panasonic Corp メディア処理装置及び記録媒体制御方法
US8543230B2 (en) * 2008-05-30 2013-09-24 Nokia Corporation Optimizing seek functionality in media content
TWI473016B (zh) * 2008-07-16 2015-02-11 Sisvel Internat S A 用以處理多視圖視訊位元串流之方法與裝置及電腦可讀媒體
JP4620158B2 (ja) * 2009-03-31 2011-01-26 株式会社東芝 コンテンツ保護装置およびコンテンツ保護方法
CN102687157B (zh) * 2009-08-17 2015-09-16 克拉姆全球有限责任公司 数字内容管理和递送
TWI488107B (zh) * 2009-12-09 2015-06-11 Silicon Motion Inc 用來增進快退效能之方法以及相關的電子裝置
JP2011253589A (ja) * 2010-06-02 2011-12-15 Funai Electric Co Ltd 画像音声再生装置
GB2485373B (en) * 2010-11-11 2013-04-10 Nds Ltd Service protection
US9633391B2 (en) 2011-03-30 2017-04-25 Cram Worldwide, Llc Secure pre-loaded drive management at kiosk
KR20140052243A (ko) * 2012-10-23 2014-05-07 한국전자통신연구원 네트워크 데이터 서비스 장치 및 방법, 네트워크 데이터 서비스를 위한 클라이언트 단말 장치
WO2014165761A1 (en) 2013-04-05 2014-10-09 Pny Technologies, Inc. Reduced length memory card
USD734756S1 (en) * 2014-04-04 2015-07-21 Pny Technologies, Inc. Reduced length memory card
JP2018155967A (ja) * 2017-03-17 2018-10-04 メモリーテック・ホールディングス株式会社 記録媒体及び携帯型音声再生機
CN107085690A (zh) * 2017-04-27 2017-08-22 武汉斗鱼网络科技有限公司 加密方法、解密方法及装置
CN110072227B (zh) * 2019-04-11 2022-05-10 北京小米移动软件有限公司 一种写卡方法及装置

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4977594A (en) * 1986-10-14 1990-12-11 Electronic Publishing Resources, Inc. Database usage metering and protection system and method
US5895123A (en) * 1991-09-03 1999-04-20 Canon Kabushiki Kaisha Information recording/reproduction apparatus for reproducing picture and audio signals in synchronization
TW223171B (en) * 1993-01-06 1994-05-01 Sony Co Ltd Playback method and device
US5596639A (en) * 1993-07-26 1997-01-21 Elonex Ip Holdings Ltd. Cd-prom
CA2168327C (en) * 1995-01-30 2000-04-11 Shinichi Kikuchi A recording medium on which a data containing navigation data is recorded, a method and apparatus for reproducing a data according to navigationdata, a method and apparatus for recording a data containing navigation data on a recording medium.
US5727061A (en) * 1995-02-13 1998-03-10 Eta Technologies Corporation Personal access management systems
US20020044757A1 (en) * 1995-08-04 2002-04-18 Sony Corporation Information carrier, device for reading and device for providing the information carrier and method of transmitting picture information
US5857020A (en) * 1995-12-04 1999-01-05 Northern Telecom Ltd. Timed availability of secured content provisioned on a storage medium
JP3778985B2 (ja) * 1996-03-19 2006-05-24 パイオニア株式会社 情報記録媒体、記録装置及び記録方法並びに再生装置及び再生方法
JP3696327B2 (ja) * 1996-03-22 2005-09-14 パイオニア株式会社 情報記録装置及び方法並びに情報再生装置及び方法
JP3938605B2 (ja) * 1996-03-22 2007-06-27 パイオニア株式会社 情報記録装置及び方法、情報再生装置及び方法並びに情報処理装置及び方法
US6636772B1 (en) * 1997-05-16 2003-10-21 Renau Corporation System and method for enabling device operation attribute-controlling commands to be entered and indicated by the operation of elements from outside the device
JP3211772B2 (ja) * 1998-06-02 2001-09-25 日本ビクター株式会社 円盤状の記録媒体
US6370090B1 (en) * 1998-06-10 2002-04-09 U.S. Philips Corporation Method, device, and information structure for storing audio-centered information with a multi-level table-of-contents (toc) mechanism and doubling of area-tocs, a device for use with such mechanism and a unitary storage medium having such mechanism
US6665240B1 (en) * 1998-10-07 2003-12-16 Sony Corporation Apparatus and method for manufacturing optical disks, apparatus and method for recording data on optical disks, apparatus and method for reproducing data from optical disks, and optical disk
MY122279A (en) * 1999-03-03 2006-04-29 Sony Corp Nonvolatile memory and nonvolatile memory reproducing apparatus
JP4135049B2 (ja) * 1999-03-25 2008-08-20 ソニー株式会社 不揮発性メモリ
GB2351819B (en) * 1999-03-03 2003-07-16 Sony Corp Reproducing apparatus and reproducing method
JP4214651B2 (ja) * 1999-03-31 2009-01-28 ソニー株式会社 データコミュニケーションシステム、データ管理方法
JP4543554B2 (ja) * 1999-03-03 2010-09-15 ソニー株式会社 データ処理装置およびデータ処理方法
WO2000062295A1 (fr) * 1999-04-07 2000-10-19 Kabushiki Kaisha Toshiba Systeme d'enregistrement d'informations numeriques, y compris d'informations audio
US6601140B1 (en) * 1999-04-07 2003-07-29 Sony Corporation Memory unit, data processing unit, and data processing method using memory unit type
JP4470242B2 (ja) * 1999-04-23 2010-06-02 ソニー株式会社 半導体メモリカード
JP3389186B2 (ja) 1999-04-27 2003-03-24 松下電器産業株式会社 半導体メモリカード及び読み出し装置
WO2000074054A2 (en) * 1999-05-28 2000-12-07 Matsushita Electric Industrial Co., Ltd. Semiconductor memory card, apparatus for recording data onto the semiconductor memory card, and apparatus for reproducing data of the semiconductor memory card
CN1196130C (zh) * 1999-05-28 2005-04-06 松下电器产业株式会社 半导体存储器卡、重放装置、记录装置、重放方法、记录方法、和计算机可读存储介质
CN1312593C (zh) * 1999-09-01 2007-04-25 松下电器产业株式会社 分布***、半导体存储卡、接收装置、计算机可读记录介质和接收方法
JP2001155466A (ja) * 1999-11-24 2001-06-08 Toshiba Corp 画像付音声情報を記録するシステム
CN100414864C (zh) * 2000-03-09 2008-08-27 松下电器产业株式会社 具有编辑装置和记录媒体的音频数据重放管理***及方法
JP4348818B2 (ja) * 2000-03-10 2009-10-21 ソニー株式会社 データ配信システムとその方法およびデータ記録媒体
JP2002093047A (ja) * 2000-09-20 2002-03-29 Sony Corp データ記録媒体、データ記録装置および方法、データ出力装置および方法、データ表示方法、コンテンツデータ並びにデータ再生装置および方法
AU2002232494A1 (en) * 2000-12-07 2002-06-18 Sandisk Corporation System, method, and device for playing back recorded audio, video or other content from non-volatile memory cards, compact disks or other media
US7287160B2 (en) * 2001-09-14 2007-10-23 Sanyo Electric Co., Ltd. Recording medium, reproducing device, and recording/reproducing device
DE10213535A1 (de) * 2002-03-26 2003-10-16 Siemens Ag Vorrichtung zur positionsabhängigen Informationsdarstellung
GB0216142D0 (en) * 2002-07-11 2002-08-21 Knox Alistair J Method and apparatus for optical disc access control
JP4073892B2 (ja) * 2004-05-10 2008-04-09 株式会社ソニー・コンピュータエンタテインメント コンテンツ再生装置、コンテンツ再生方法、コンピュータプログラム
JP4557759B2 (ja) * 2005-03-14 2010-10-06 株式会社東芝 情報処理装置、情報処理方法およびデータ更新方法
EP1953671A4 (en) * 2005-10-31 2010-12-29 Panasonic Corp CONTENT DATA STRUCTURE AND MEMORY CARD

Also Published As

Publication number Publication date
CA2338634A1 (en) 2000-12-07
EP1056092B1 (en) 2007-07-11
JP2001249695A (ja) 2001-09-14
CN1187756C (zh) 2005-02-02
DE60035455T2 (de) 2007-11-08
CN1318196A (zh) 2001-10-17
ID27746A (id) 2001-04-26
BR0006882A (pt) 2001-08-07
CA2338634C (en) 2007-06-26
US7596698B2 (en) 2009-09-29
EP1056092A1 (en) 2000-11-29
DE60035455D1 (de) 2007-08-23
US20050192686A1 (en) 2005-09-01
WO2000074059A1 (en) 2000-12-07
JP3425119B2 (ja) 2003-07-07
JP2004030586A (ja) 2004-01-29
US6865431B1 (en) 2005-03-08
US20100064145A1 (en) 2010-03-11
BR0006882B1 (pt) 2014-03-18
MY125354A (en) 2006-07-31
US8156347B2 (en) 2012-04-10

Similar Documents

Publication Publication Date Title
JP4150278B2 (ja) 半導体メモリカード、再生装置、再生方法、及びコンピュータ読み取り可能な記録媒体
KR100655034B1 (ko) 반도체 메모리카드, 재생장치, 기록장치, 재생방법, 기록방법
CA2338725C (en) Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and a computer-readable storage medium
JP4219680B2 (ja) 不揮発性メモリカード、コンパクトディスクまたはその他のメディアから記録済みのオーディオ、ビデオまたはその他のコンテンツを再生するためのシステム、方法およびデバイス
JP3366896B2 (ja) 半導体メモリカード、記録再生装置、記録再生方法、コンピュータ読み取り可能な記録媒体
JP3882460B2 (ja) メモリ装置、データ処理装置、データ処理システムおよびデータ処理方法
JP4469125B2 (ja) 半導体メモリカード、編集装置、編集方法、コンピュータ読み取り可能な記録媒体
RU2255382C2 (ru) Плата полупроводниковой памяти, устройство воспроизведения, устройство записи, способ воспроизведения, способ записи и считываемый посредством компьютера носитель записи
RU2259604C2 (ru) Плата полупроводниковой памяти, устройство воспроизведения, устройство записи, способ воспроизведения, способ записи и считываемый посредством компьютера носитель информации
JP3327898B2 (ja) 半導体メモリカード、再生装置、再生方法、コンピュータ読み取り可能な記録媒体
JP2003162300A (ja) 半導体メモリカードについての再生装置、コンピュータ読み取り可能な記録媒体、再生方法
MXPA01000997A (en) Semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070423

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070423

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080603

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080627

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110704

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4150278

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110704

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120704

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120704

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130704

Year of fee payment: 5

EXPY Cancellation because of completion of term