[go: up one dir, main page]

JP2001076464A - データコミュニケーションシステム、データ管理方法 - Google Patents

データコミュニケーションシステム、データ管理方法

Info

Publication number
JP2001076464A
JP2001076464A JP2000038815A JP2000038815A JP2001076464A JP 2001076464 A JP2001076464 A JP 2001076464A JP 2000038815 A JP2000038815 A JP 2000038815A JP 2000038815 A JP2000038815 A JP 2000038815A JP 2001076464 A JP2001076464 A JP 2001076464A
Authority
JP
Japan
Prior art keywords
data
content
file
block
memory card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2000038815A
Other languages
English (en)
Other versions
JP4214651B2 (ja
Inventor
Teppei Yokota
哲平 横田
Nobuyuki Kihara
信之 木原
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.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2000038815A priority Critical patent/JP4214651B2/ja
Priority to EP00301764A priority patent/EP1033665A3/en
Priority to TW089105274A priority patent/TW522386B/zh
Priority to MYPI20001164A priority patent/MY125136A/en
Priority to SG200001739A priority patent/SG103814A1/en
Priority to US09/538,169 priority patent/US6691149B1/en
Priority to CNB001186450A priority patent/CN1229742C/zh
Priority to KR1020000016833A priority patent/KR100714665B1/ko
Publication of JP2001076464A publication Critical patent/JP2001076464A/ja
Application granted granted Critical
Publication of JP4214651B2 publication Critical patent/JP4214651B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/16—Program or content traceability, e.g. by watermarking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
    • G11B20/00746—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number
    • G11B20/00753—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number wherein the usage restriction limits the number of copies that can be made, e.g. CGMS, SCMS, or CCI flags
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
    • G11B20/0084—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific time or date
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C16/00—Erasable programmable read-only memories
    • G11C16/02—Erasable programmable read-only memories electrically programmable
    • G11C16/06—Auxiliary circuits, e.g. for writing into memory
    • G11C16/10—Programming or data input circuits
    • G11C16/20—Initialising; Data preset; Chip identification
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C16/00—Erasable programmable read-only memories
    • G11C16/02—Erasable programmable read-only memories electrically programmable
    • G11C16/06—Auxiliary circuits, e.g. for writing into memory
    • G11C16/22—Safety or protection circuits preventing unauthorised or accidental access to memory cells
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C2207/00—Indexing scheme relating to arrangements for writing information into, or reading information out from, a digital store
    • G11C2207/16—Solid state audio
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99937—Sorting
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Mathematical Physics (AREA)
  • Technology Law (AREA)
  • Library & Information Science (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

(57)【要約】 【課題】 コンテンツのムーブを支障無く且つ高いセキ
ュリティを確保して行う。 【解決手段】 蓄積装置としてのハードディスクドライ
ブ２０１ａに、２枚のＣＤからの曲がコピーされる。Ｃ
Ｄの再生出力中の情報によってトラック管理ファイル２
０１Ｆが作成される。蓄積した曲の内の一部がメモリカ
ード４０ａにムーブされる。この移動履歴が識別情報を
使用して管理ファイル２０３Ｆ上に作成される。そし
て、メモリカードから再びハードディスクに曲を戻す場
合、戻されるデータの識別情報と移動履歴管理ファイル
中の識別情報とが照合される。同じ識別情報であること
を検出すると、データの戻しであると決定する。その場
合には、識別情報を参照することによって、ハードディ
スクドライブの元の場所と同じ場所にメモリカード４０
ｂからのデータが記録される。その結果のハードディス
クドライブ２０１ｃは、ハードディスクドライブ２０１
ａにおけるのと同じ順序で曲を蓄積したものとなる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】この発明は、大容量メモリを
備えたサーバと端末の相互間でコンテンツの移動を行う
際にデータの移動履歴を管理するデータコミュニケーシ
ョンシステムおよびデータ管理方法に関する。
【０００２】
【従来の技術】ＥＥＰＲＯＭ(Electrically Erasable P
rogrammable ROM)と呼ばれる電気的に書き換え可能な不
揮発性メモリは、１ビットを２個のトランジスタで構成
するために、１ビット当たりの占有面積が大きく、集積
度を高くするのに限界があった。この問題を解決するた
めに、全ビット一括消去方式により１ビットを１トラン
ジスタで実現することが可能なフラッシュメモリが開発
された。フラッシュメモリは、磁気ディスク、光ディス
ク等の記録媒体に代わりうるものとして期待されてい
る。
【０００３】また、フラッシュメモリを機器に対して着
脱自在に構成したメモリカードも知られている。このメ
モリカードを使用すれば、従来のＣＤ（コンパクトディ
スク：登録商標）、ＭＤ（ミニディスク：登録商標）等
のディスク状媒体に換えてメモリカードを使用するディ
ジタルオーディオ記録／再生装置を実現することができ
る。
【０００４】メモリカードを記録媒体とするオーディオ
レコーダでは、ディジタル記録／再生を行うので、比較
的高品質のデータを復元できる圧縮方式を使用している
場合には、記録／再生される曲等の著作権を保護する必
要がある。その方法の一つとして、暗号化技術によっ
て、真正なメモリカード以外のメモリカードを使用不可
能とする方法がある。すなわち、真正なレコーダと真正
なメモリカードの組み合わせによって、暗号化を復号化
することを可能とするものである。
【０００５】従来のメモリカードは、それ自体に暗号化
の機能を持っていなかった。従って、機密性の必要なデ
ータをメモリカードに記録しようとする場合、セット側
においてデータを暗号化し、暗号化されたデータをメモ
リカードに記録することが必要とされる。しかしなが
ら、復号化のキーをメモリカード上に格納する場合に
は、機密性が保たれない。一方、復号化のキーをセット
内にとどめた場合には、暗号化されたデータをそのセッ
ト以外に復号化することができず、メモリカードの互換
性を保てない問題がある。例えば自分のセットで記録し
たメモリカードを他人のセットでは、復号できない。こ
の問題を解決するために、セットおよびメモリカードの
両者が暗号化の機能を持ち、相互認証を行うことによっ
て、機密性とカードの互換性を確保することが提案され
ている。
【０００６】一方、オーディオ・映像情報のディジタル
化およびマルチメディアへの対応に伴って、音楽配信サ
ーバからインターネット、ディジタル放送等のネットワ
ークを介して音楽データをパソコン（パーソナルコンピ
ュータ）によって受け取る音楽配信サービスも実用化さ
れつつある。このサービスでは、配信されたコンテンツ
がパソコンによりハードディスク上に蓄積される。ま
た、ハードディスク上には、ＣＤ等のディスク再生出力
が蓄積される。
【０００７】そして、ハードディスクをオーディオサー
バとするシステムでは、ハードディスクからメモリカー
ドにオーディオデータを移動し、そのメモリカードを使
用して例えば携帯型プレーヤによって移動したデータを
再生することが可能とされる。逆に、メモリカードから
サーバのハードディスクにオーディオデータを移動する
ようになされる。著作権保護の目的と、データの累積を
防止するために、このようなデータの移動は、データの
複製とは異なり、移動後にデータが残らないようにされ
る。
【０００８】従来、ハードディスクをオーディオサーバ
とするシステムにおいて、ハードディスクからメモリカ
ードへデータを移動する時に、ハードディスクの内容を
全て移動し、移動後のメモリカード内のデータを破棄し
ていた。この方法は、暗号化その他の処理が不要であっ
て、簡単なものであり、高速のデータの移動が可能であ
った。
【０００９】
【発明が解決しようとする課題】しかしながら、ＣＤ等
の媒体からのオーディオデータをハードディスクに蓄積
し、その後、メモリカードへムーブし、さらに、メモリ
カードにムーブしたオーディオデータを再び元のハード
ディスクに戻した時に、上述した方法は、曲の順番等が
元のＣＤとは異なるものとなる。例えばＣＤからコピー
したアルバムの中で、曲番号２，４，６のように、ラン
ダムに選択した３曲をメモリカードに移動した場合、聞
き終わってから元のサーバに戻しても、コピー元のＣＤ
に対応するデータからは、この３曲が欠落し、代わりに
この３曲からなる新たなＣＤに対応するデータがハード
ディスク上に作成される。利用者は、メモリカードから
元のハードディスクに戻した時に、ハードディスク上で
は、元のＣＤと同じ順序で、同じ曲が管理されているこ
とを望むことが多い。更に、ＣＤ等の媒体からオーディ
オデータをハードディスクに一旦蓄積を行った後にメモ
リカードに上記ハードディスクから移動または複写を行
い、上記コピー元とは異なるハードディスクに上記メモ
リカードから更に複写を行えるようにすると無限にメモ
リカードに複写ができてしまい、著作権上問題が生じる
ことになる。
【００１０】従って、この発明の目的は、以前サーバか
らムーブしたコンテンツを再びサーバへ戻す時に、元々
の場所に戻すことができるデータコミュニケーションシ
ステム、データ管理方法を提供することにある。
【００１１】
【課題を解決するための手段】請求項１の発明は、情報
源と、情報源に接続され、情報源から供給されるコンテ
ンツを記憶する大容量メモリに記憶されたコンテンツを
移動して記憶可能なクライアントからなるデータコミュ
ニケーションシステムにおいて、クライアントは、サー
バから移動されたコンテンツと、移動履歴を管理する移
動履歴管理データとを記憶する記憶手段と、記憶手段に
記憶されたコンテンツをサーバ内の大容量メモリに戻す
ときに移動履歴管理データを送信する送信手段とを備
え、サーバは、情報源からコンテンツを大容量メモリに
記憶する際にコンテンツ毎に管理する管理データを生成
する生成手段と、生成手段にて生成した管理データを、
コンテンツと共に大容量メモリに記憶する制御手段と、
クライアント側の送信手段から送信される移動履歴管理
データを受信する受信手段と、サーバの大容量メモリに
記憶されたコンテンツをクライアント内の記憶手段に記
憶されたコンテンツをサーバ内の大容量メモリに戻す際
に受信手段にて受信した移動履歴管理データに基づいて
管理データを編集する編集手段とを備えることを特徴と
するデータコミュニケーションシステムである。
【００１２】請求項１０の発明は、複数のコンテンツ
と、複数のコンテンツを管理する管理データを記憶した
大容量メモリ備えたサーバと、サーバに接続され、大容
量メモリから所定のコンテンツを移動可能な端末からな
るデータコミュニケーションシステムにおけるデータ管
理方法において、サーバから所定のコンテンツを移動す
る際に移動管理データを生成するステップと、端末か
ら、サーバに再度コンテンツを戻す際にサーバに生成し
た移動履歴管理データを送信するステップと、端末から
サーバに再度コンテンツを戻す際に大容量メモリに蓄積
された管理データと端末から送信された移動履歴管理デ
ータとを参照するステップと、参照結果に基づいて、端
末から戻されたコンテンツが元々大容量メモリに憶され
ていたコンテンツであるか否かを判別するステップとを
有することを特徴とするデータ管理方法である。
【００１３】
【発明の実施の形態】以下、この発明の一実施形態につ
いて説明する。図１は、この発明の一実施形態における
メモリカードを使用したディジタルオーディオレコーダ
／プレーヤの全体の構成を示す。この一実施形態は、記
録媒体として、着脱自在のメモリカードを使用するディ
ジタルオーディオ信号の記録および再生機である。より
具体的には、このレコーダ／プレーヤは、アンプ装置、
スピーカ、ＣＤプレーヤ、ＭＤレコーダ、チューナ等と
共にオーディオシステムを構成する。この発明は、これ
以外のオーディオレコーダに対しても適用できる。すな
わち、携帯型記録再生装置に対しても適用できる。ま
た、衛星を使用したデータ通信、ディジタル放送、イン
ターネット等を経由して配信されるディジタルオーディ
オ信号を記録するセットトップボックスに対しても適用
できる。さらに、ディジタルオーディオ信号以外に動画
データ、静止画データ等の記録／再生に対してもこの発
明を適用できる。一実施形態においても、ディジタルオ
ーディオ信号以外の画像、文字等の付加情報を記録／再
生可能としている。
【００１４】記録再生装置は、それぞれ１チップＩＣで
構成されたオーディオエンコーダ／デコーダＩＣ１０、
セキュリティＩＣ２０、ＤＳＰ(Digital Signal Proces
sor)３０を有する。さらに、記録再生装置本体に対して
着脱自在のメモリカード４０を備える。メモリカード４
０は、フラッシュメモリ（不揮発性メモリ）、メモリコ
ントロールブロック、ＤＥＳ(Data Encryption Standar
d)の暗号化回路を含むセキュリティブロックが１チップ
上にＩＣ化されたものである。なお、この一実施形態で
は、ＤＳＰ３０を使用しているが、マイクロコンピュー
タを使用しても良い。
【００１５】オーディオエンコーダ／デコーダＩＣ１０
は、オーディオインタフェース１１およびエンコーダ／
デコーダブロック１２を有する。エンコーダ／デコーダ
ブロック１２は、ディジタルオーディオ信号をメモリカ
ード４０に書き込むために高能率符号化し、また、メモ
リカード４０から読み出されたデータを復号する。高能
率符号化方法としては、ミニディスクで採用されている
ＡＴＲＡＣ(AdaptiveTransform Acoustic Coding)を改
良したＡＴＲＡＣ３が使用される。
【００１６】上述のＡＴＲＡＣ３では、サンプリング周
波数＝４４．１ｋHzでサンプリングした量子化ビットが
１６ビットのオーディオデータを高能率符号化処理す
る。ＡＴＲＡＣ３でオーディオデータを処理する時の最
小のデータ単位がサウンドユニットＳＵである。１ＳＵ
は、１０２４サンプル分（１０２４×１６ビット×２チ
ャンネル）を数百バイトに圧縮したものであり、時間に
して約２３ｍ秒である。上述の高能率符号化処理により
約１／１０にオーディオデータが圧縮される。ミニディ
スクで適用されたＡＴＲＡＣ１と同様に、ＡＴＲＡＣ３
方式において、信号処理されたオーディオ信号の圧縮／
伸長処理による音質の劣化は少ない。
【００１７】ライン入力セレクタ１３は、ＭＤの再生出
力、チューナの出力、テープ再生出力を選択的にＡ／Ｄ
変換器１４に供給する。Ａ／Ｄ変換器１４は、入力され
るライン入力信号をサンプリング周波数＝４４．１ｋH
z、量子化ビット＝１６ビットのディジタルオーディオ
信号へ変換する。ディジタル入力セレクタ１６は、Ｍ
Ｄ、ＣＤ、ＣＳ（衛星ディジタル放送）のディジタル出
力を選択的にディジタル入力レシーバ１７に供給する。
上述のディジタル入力は、例えば光ケーブルを介して伝
送される。ディジタル入力レシーバ１７の出力がサンプ
リングレートコンバータ１５に供給され、ディジタル入
力のサンプリング周波数が４４．１ｋHz、量子化ビット
が１６ビットのデジタルオーディオ信号に変換される。
【００１８】オーディオエンコーダ／デコーダＩＣ１０
のエンコーダ／デコーダブロック１２からの符号化デー
タがセキュリティＩＣ２０のインタフェース２１を介し
てＤＥＳの暗号化回路２２に供給される。ＤＥＳの暗号
化回路２２は、ＦＩＦＯ２３を有している。ＤＥＳの暗
号化回路２２は、コンテンツの著作権を保護するために
備えられている。メモリカード４０にも、ＤＥＳの暗号
化回路が組み込まれている。記録再生装置のＤＥＳの暗
号化回路２２は、複数のマスターキーと機器毎にユニー
クなストレージキーを持つ。さらに、ＤＥＳの暗号化回
路２２は、乱数発生回路を持ち、ＤＥＳの暗号化回路を
内蔵するメモリカードと認証およびセッションキーを共
有することができる。よりさらに、ＤＥＳの暗号化回路
２２は、ＤＥＳの暗号化回路を通してストレージキーで
キーをかけなおすことができる。
【００１９】ＤＥＳの暗号化回路２２からの暗号化され
たオーディオデータがＤＳＰ(Digital Signal Processo
r)３０に供給される。ＤＳＰ３０は、着脱機構（図示し
ない）に装着されたメモリカード４０とメモリインタフ
ェースを介しての通信を行い、暗号化されたデータをフ
ラッシュメモリに書き込む。ＤＳＰ３０とメモリカード
４０との間では、シリアル通信がなされる。また、メモ
リカードの制御に必要なメモリ容量を確保するために、
ＤＳＰ３０に対して外付けのＳＲＡＭ(StaticRandom Ac
cess Memory) ３１が接続される。
【００２０】さらに、ＤＳＰ３０に対して、バスインタ
フェース３２が接続され、図示しない外部のコントロー
ラからのデータがバス３３を介してＤＳＰ３０に供給さ
れる。外部のコントローラは、オーディオシステム全体
の動作を制御し、操作部からのユーザの操作に応じて発
生した録音指令、再生指令等のデータをＤＳＰ３０にバ
スインタフェース３２を介して与える。また、画像情
報、文字情報等の付加情報のデータもバスインタフェー
ス３２を介してＤＳＰ３０に供給される。バス３３は、
双方向通信路であり、メモリカード４０から読み出され
た付加情報データ、制御信号等がＤＳＰ３０、バスイン
ターフェース３２、バス３３を介して外部のコントロー
ラに取り込まれる。外部のコントローラは、具体的に
は、オーディオシステム内に含まれる他の機器例えばア
ンプ装置に含まれている。さらに、外部のコントローラ
によって、付加情報の表示、レコーダの動作状態等を表
示するための表示が制御される。表示部は、オーディオ
システム全体で共用される。ここで、バス３３を介して
送受信されるデータは、著作物ではないので、暗号化が
されない。
【００２１】ＤＳＰ３０によってメモリカード４０から
読み出した暗号化されたオーディオデータは、セキュリ
ティＩＣ２０によって復号化され、オーディオエンコー
ダ／デコーダＩＣ１０によってＡＴＲＡＣ３の復号化処
理を受ける。オーディオエンコーダ／デコーダ１０の出
力がＤ／Ａ変換器１８に供給され、アナログオーディオ
信号へ変換される。そして、アナログオーディオ信号が
ライン出力端子１９に取り出される。
【００２２】ライン出力は、図示しないアンプ装置に伝
送され、スピーカまたはヘッドホンにより再生される。
Ｄ／Ａ変換器１８に対してミューティング信号が外部の
コントローラから供給される。ミューティング信号がミ
ューティングのオンを示す時には、ライン出力端子１９
からのオーディオ出力が禁止される。
【００２３】図２は、ＤＳＰ３０の内部構成を示す。Ｄ
ＳＰ３０は、Ｃｏｒｅ３４と、フラッシュメモリ３５
と、ＳＲＡＭ３６と、バスインタフェース３７と、メモ
リカードインタフェース３８と、バスおよびバス間のブ
リッジとで構成される。ＤＳＰ３０は、マイクロコンピ
ュータと同様な機能を有し、Ｃｏｒｅ３４がＣＰＵに相
当する。フラッシュメモリ３５にＤＳＰ３０の処理のた
めのプログラムが格納されている。ＳＲＡＭ３６と外部
のＳＲＡＭ３１とがＲＡＭとして使用される。
【００２４】ＤＳＰ３０は、バスインタフェース３２、
３７を介して受け取った録音指令等の操作信号に応答し
て、所定の暗号化されたオーディオデータ、所定の付加
情報データをメモリカード４０に対して書き込み、ま
た、これらのデータをメモリカード４０から読み出す処
理を制御する。すなわち、オーディオデータ、付加情報
の記録／再生を行うためのオーディオシステム全体のア
プリケーションソフトウェアと、メモリカード４０との
間にＤＳＰ３０が位置し、メモリカード４０のアクセ
ス、ファイルシステム等のソフトウェアによってＤＳＰ
３０が動作する。
【００２５】ＤＳＰ３０におけるメモリカード４０上の
ファイル管理は、既存のパーソナルコンピュータで使用
されているＦＡＴシステムが使用される。このファイル
システムに加えて、一実施形態では、後述するようなデ
ータ構成の管理ファイルが使用される。管理ファイル
は、メモリカード４０上に記録されているデータファイ
ルを管理する。第１のファイル管理情報としての管理フ
ァイルは、オーディオデータのファイルを管理するもの
である。第２のファイル管理情報としてのＦＡＴは、オ
ーディオデータのファイルと管理ファイルを含むメモリ
カード４０のフラッシュメモリ上のファイル全体を管理
する。管理ファイルは、メモリカード４０に記録され
る。また、ＦＡＴは、ルートディレクトリ等と共に、予
め出荷時にフラッシュメモリ上に書き込まれている。Ｆ
ＡＴの詳細に関しては後述する。
【００２６】なお、一実施形態では、著作権を保護する
ために、ＡＴＲＡＣ３により圧縮されたオーディオデー
タを暗号化している。一方、管理ファイルは、著作権保
護が必要ないとして、暗号化を行わないようにしてい
る。また、メモリカードとしても、暗号化機能を持つも
のと、これを持たないものとがありうる。一実施形態の
ように、著作物であるオーディオデータを記録するレコ
ーダが対応しているメモリカードは、暗号化機能を持つ
メモリカードのみである。上述の暗号化機能を有さない
メモリカードには、個人が録音したＶｏｉｃｅまたは録
画した画像が記録される。
【００２７】図３は、メモリカード４０の構成を示す。
メモリカード４０は、コントロールブロック４１とフラ
ッシュメモリ４２が１チップＩＣとして構成されたもの
である。プレーヤ／レコーダのＤＳＰ３０とメモリカー
ド４０との間の双方向シリアルインタフェースは、１０
本の線からなる。主要な４本の線は、データ伝送時にク
ロックを伝送するためのクロック線ＳＣＫと、ステータ
スを伝送するためのステータス線ＳＢＳと、データを伝
送するデータ線ＤＩＯ、インターラプト線ＩＮＴとであ
る。その他に電源供給用線として、２本のＧＮＤ線およ
び２本のＶＣＣ線が設けられる。２本の線Ｒｅｓｅｒｖ
は、未定義の線である。
【００２８】クロック線ＳＣＫは、データに同期したク
ロックを伝送するための線である。ステータス線ＳＢＳ
は、メモリカード４０のステータスを表す信号を伝送す
るための線である。データ線ＤＩＯは、コマンドおよび
暗号化されたオーディオデータを入出力するための線で
ある。インターラプト線ＩＮＴは、メモリカード４０か
らプレーヤ／レコーダのＤＳＰ３０に対しての割り込み
を要求するインターラプト信号を伝送する線である。メ
モリカード４０を装着した時にインターラプト信号が発
生する。但し、この一実施形態では、インターラプト信
号をデータ線ＤＩＯを介して伝送するようにしているの
で、インターラプト線ＩＮＴを接地している。
【００２９】コントロールブロック４１のシリアル／パ
ラレル変換・パラレル／シリアル変換・インタフェース
ブロック（以下、Ｓ／Ｐ・Ｐ／Ｓ・ＩＦブロックと略
す）４３は、上述した複数の線を介して接続されたレコ
ーダのＤＳＰ３０とコントロールブロック４１とのイン
タフェースである。Ｓ／Ｐ・Ｐ／Ｓ・ＩＦブロック４３
は、プレーヤ／レコーダのＤＳＰ３０から受け取ったシ
リアルデータをパラレルデータに変換し、コントロール
ブロック４１に取り込み、コントロールブロック４１か
らのパラレルデータをシリアルデータに変換してプレー
ヤ／レコーダのＤＳＰ３０に送る。また、Ｓ／Ｐ・Ｐ／
Ｓ・ＩＦブロック４３は、データ線ＤＩＯを介して伝送
されるコマンドおよびデータを受け取った時に、フラッ
シュメモリ４２に対する通常のアクセスのためのコマン
ドおよびデータと、暗号化に必要なコマンドおよびデー
タとを分離する。
【００３０】データ線ＤＩＯを介して伝送されるフォー
マットでは、最初にコマンドが伝送され、その後にデー
タが伝送される。Ｓ／Ｐ・Ｐ／Ｓ・ＩＦブロック４３
は、コマンドのコードを検出して、通常のアクセスに必
要なコマンドおよびデータか、暗号化に必要なコマンド
およびデータかを判別する。この判別結果に従って、通
常のアクセスに必要なコマンドをコマンドレジスタ４４
に格納し、データをページバッファ４５およびライトレ
ジスタ４６に格納する。ライトレジスタ４６と関連して
エラー訂正符号化回路４７が設けられている。ページバ
ッファ４５に一時的に蓄えられたデータに対して、エラ
ー訂正符号化回路４７がエラー訂正符号の冗長コードを
生成する。
【００３１】コマンドレジスタ４４、ページバッファ４
５、ライトレジスタ４６およびエラー訂正符号化回路４
７の出力データがフラッシュメモリインタフェースおよ
びシーケンサ（以下、メモリＩ／Ｆ・シーケンサと略
す）５１に供給される。メモリＩＦ・シーケンサ５１
は、コントロールブロック４１とフラッシュメモリ４２
とのインタフェースであり、両者の間のデータのやり取
りを制御する。メモリＩＦ・シーケンサ５１を介してデ
ータがフラッシュメモリ４２に書き込まれる。
【００３２】フラッシュメモリ４２に書き込まれるＡＴ
ＲＡＣ３により圧縮されたオーディオデータ（以下、Ａ
ＴＲＡＣ３データと表記する）は、著作権保護のため
に、プレーヤ／レコーダのセキュリティＩＣ２０とメモ
リカード４０のセキュリティブロック５２とによって、
暗号化されたものである。セキュリティブロック５２
は、バッファメモリ５３と、ＤＥＳの暗号化回路５４
と、不揮発性メモリ５５とを有する。
【００３３】メモリカード４０のセキュリティブロック
５２は、複数の認証キーとメモリカード毎にユニークな
ストレージキーを持つ。不揮発性メモリ５５は、暗号化
に必要なキーを格納するもので、チップ解析を行っても
解析不能な構造となっている。この実施形態では、例え
ばストレージキーが不揮発性メモリ５５に格納される。
さらに、乱数発生回路を持ち、対応可能なプレーヤ／レ
コーダと認証ができ、セッションキーを共有できる。Ｄ
ＥＳの暗号化回路５４を通して、コンテンツキーをスト
レージキーでキーのかけ直しを行う。
【００３４】例えばメモリカード４０をプレーヤ／レコ
ーダに装着した時に相互に認証がなされる。認証は、プ
レーヤ／レコーダのセキュリティＩＣ２０とメモリカー
ド４０のセキュリティブロック５２によって行わせる。
プレーヤ／レコーダは、装着されたメモリカード４０が
対応可能なメモリカードであることを認証し、また、メ
モリカード４０が相手のプレーヤ／レコーダが対応可能
なプレーヤ／レコーダであることを認証すると、相互認
証処理が正常に行われたことを意味する。認証が行われ
ると、プレーヤ／レコーダとメモリカード４０がそれぞ
れセッションキーを生成し、セッションキーを共有す
る。セッションキーは、認証の度に生成される。
【００３５】メモリカード４０に対するコンテンツの書
き込み時には、プレーヤ／レコーダがセッションキーで
コンテンツキーを暗号化してメモリカード４０に渡す。
メモリカード４０では、コンテンツキーをセッションキ
ーで復号し、ストレージキーで暗号化してプレーヤ／レ
コーダに渡す。ストレージキーは、メモリカード４０の
一つ一つにユニークなキーであり、プレーヤ／レコーダ
は、暗号化されたコンテンツキーを受け取ると、フォー
マット処理を行い、暗号化されたコンテンツキーと暗号
化されたコンテンツをメモリカード４０に書き込む。
【００３６】以上、メモリカード４０に対する書き込み
処理について説明したが、以下メモリカード４０からの
読み出し処理について説明する。フラッシュメモリ４２
から読み出されたデータがメモリＩＦ・シーケンサ５１
を介してページバッファ４５、リードレジスタ４８、エ
ラー訂正回路４９に供給される。ページバッファ４５に
記憶されたデータがエラー訂正回路４９によってエラー
訂正がなされる。エラー訂正がされたページバッファ４
５の出力およびリードレジスタ４８の出力がＳ／Ｐ・Ｐ
／Ｓ・ＩＦブロック４３に供給され、上述したシリアル
インタフェースを介してプレーヤ／レコーダのＤＳＰ３
０に供給される。
【００３７】読み出し時には、ストレージキーで暗号化
されたコンテンツキーとブロックキーで暗号化されたコ
ンテンツとがフラッシュメモリ４２から読み出される。
セキュリティブロック５２によって、ストレージキーで
コンテンツキーが復号される。復号したコンテンツキー
がセッションキーで再暗号化されてプレーヤ／レコーダ
側に送信される。プレーヤ／レコーダは、受信したセッ
ションキーでコンテンツキーを復号する。プレーヤ／レ
コーダは、復号したコンテンツキーでブロックキーを生
成する。このブロックキーによって、暗号化されたＡＴ
ＲＡＣ３データを順次復号する。
【００３８】なお、ConfigＲＯＭ５０は、メモリカード
４０のバージョン情報、各種の属性情報等が格納されて
いるメモリである。また、メモリカード４０には、ユー
ザが必要に応じて操作可能な誤消去防止用のスイッチ６
０が備えられている。このスイッチ６０が消去禁止の接
続状態にある場合には、フラッシュメモリ４２を消去す
ることを指示するコマンドがレコーダ側から送られてき
ても、フラッシュメモリ４２の消去が禁止される。さら
に、ＯＳＣ Cont.６１は、メモリカード４０の処理のタ
イミング基準となるクロックを発生する発振器である。
【００３９】図４は、メモリカードを記憶媒体とするコ
ンピュータシステムのファイルシステム処理階層を示
す。ファイルシステム処理階層としては、アプリケーシ
ョン処理層が最上位であり、その下に、ファイル管理処
理層、論理アドレス管理層、物理アドレス管理層、フラ
ッシュメモリアクセスが順次積層される。上述の階層構
造において、ファイル管理処理層がＦＡＴシステムであ
る。物理アドレスは、フラッシュメモリの各ブロックに
対して付されたもので、ブロックと物理アドレスの対応
関係は、不変である。論理アドレスは、ファイル管理処
理層が論理的に扱うアドレスである。
【００４０】図５は、メモリカード４０におけるフラッ
シュメモリ４２のデータの物理的構成の一例を示す。フ
ラッシュメモリ４２は、セグメントと称されるデータ単
位が所定数のブロック（固定長）へ分割され、１ブロッ
クが所定数のページ（固定長）へ分割される。フラッシ
ュメモリ４２では、ブロック単位で消去が一括して行わ
れ、書き込みと読み出しは、ページ単位で一括して行わ
れる。各ブロックおよび各ページは、それぞれ同一のサ
イズとされ、１ブロックがページ０からページｍで構成
される。１ブロックは、例えば８ＫＢ（Ｋバイト）バイ
トまたは１６ＫＢの容量とされ、１ページが５１２Ｂの
容量とされる。フラッシュメモリ４２全体では、１ブロ
ック＝８ＫＢの場合で、４ＭＢ（５１２ブロック）、８
ＭＢ（１０２４ブロック）とされ、１ブロック＝１６Ｋ
Ｂの場合で、１６ＭＢ（１０２４ブロック）、３２ＭＢ
（２０４８ブロック）、６４ＭＢ（４０９６ブロック）
の容量とされる。
【００４１】１ページは、５１２バイトのデータ部と１
６バイトの冗長部とからなる。冗長部の先頭の３バイト
は、データの更新に応じて書き換えられるオーバーライ
ト部分とされる。３バイトの各バイトに、先頭から順に
ブロックステータス、ページステータス、更新ステータ
スが記録される。冗長部の残りの１３バイトの内容は、
原則的にデータ部の内容に応じて固定とされる。１３バ
イトは、管理フラグ（１バイト）、論理アドレス（２バ
イト）、フォーマットリザーブの領域（５バイト）、分
散情報ＥＣＣ（２バイト）およびデータＥＣＣ（３バイ
ト）からなる。分散情報ＥＣＣは、管理フラグ、論理ア
ドレス、フォーマットリザーブに対する誤り訂正用の冗
長データであり、データＥＣＣは、５１２バイトのデー
タに対する誤り訂正用の冗長データである。
【００４２】管理フラグとして、システムフラグ（その
値が１：ユーザブロック、０：ブートブロック）、変換
テーブルフラグ（１：無効、０：テーブルブロック）、
コピー禁止指定（１：ＯＫ、０：ＮＧ）、アクセス許可
（１：ｆｒｅｅ、０：リードプロテクト）の各フラグが
記録される。
【００４３】先頭の二つのブロック０およびブロック１
がブートブロックである。ブロック１は、ブロック０と
同一のデータが書かれるバックアップ用である。ブート
ブロックは、カード内の有効なブロックの先頭ブロック
であり、メモリカードを機器に装填した時に最初にアク
セスされるブロックである。残りのブロックがユーザブ
ロックである。ブートブロックの先頭のページ０にヘッ
ダ、システムエントリ、ブート＆アトリビュート情報が
格納される。ページ１に使用禁止ブロックデータが格納
される。ページ２にＣＩＳ(Card Information Structur
e)／ＩＤＩ(Identify Drive Information)が格納され
る。
【００４４】ブートブロックのヘッダは、ブートブロッ
クＩＤ、ブートブロック内の有効なエントリ数が記録さ
れる。システムエントリには、使用禁止ブロックデータ
の開始位置、そのデータサイズ、データ種別、ＣＩＳ／
ＩＤＩのデータ開始位置、そのデータサイズ、データ種
別が記録される。ブート＆アトリビュート情報には、メ
モリカードのタイプ（読み出し専用、リードおよびライ
ト可能、両タイプのハイブリッド等）、ブロックサイ
ズ、ブロック数、総ブロック数、セキュリティ対応か否
か、カードの製造に関連したデータ（製造年月日等）等
が記録される。
【００４５】フラッシュメモリは、データの書き換えを
行うことにより絶縁膜の劣化を生じ、書き換え回数が制
限される。従って、ある同一の記憶領域（ブロック）に
対して繰り返し集中的にアクセスがなされることを防止
する必要がある。従って、ある物理アドレスに格納され
ているある論理アドレスのデータを書き換える場合、フ
ラッシュメモリのファイルシステムでは、同一のブロッ
クに対して更新したデータを再度書き込むことはせず
に、未使用のブロックに対して更新したデータを書き込
むようになされる。その結果、データ更新前における論
理アドレスと物理アドレスの対応関係が更新後では、変
化する。スワップ処理を行うことで、同一のブロックに
対して繰り返して集中的にアクセスがされることが防止
され、フラッシュメモリの寿命を延ばすことが可能とな
る。
【００４６】論理アドレスは、一旦ブロックに対して書
き込まれたデータに付随するので、更新前のデータと更
新後のデータの書き込まれるブロックが移動しても、Ｆ
ＡＴからは、同一のアドレスが見えることになり、以降
のアクセスを適正に行うことができる。スワップ処理に
より論理アドレスと物理アドレスとの対応関係が変化す
るので、両者の対応を示す論理−物理アドレス変換テー
ブルが必要となる。このテーブルを参照することによっ
て、ＦＡＴが指定した論理アドレスに対応する物理アド
レスが特定され、特定された物理アドレスが示すブロッ
クに対するアクセスが可能となる。
【００４７】論理−物理アドレス変換テーブルは、ＤＳ
Ｐ３０によってＳＲＡＭ上に格納される。若し、ＲＡＭ
容量が少ない時は、フラッシュメモリ中に格納すること
ができる。このテーブルは、概略的には、昇順に並べた
論理アドレス（２バイト）に物理アドレス（２バイト）
をそれぞれ対応させたテーブルである。フラッシュメモ
リの最大容量を１２８ＭＢ（８１９２ブロック）として
いるので、２バイトによって８１９２のアドレスを表す
ことができる。また、論理−物理アドレス変換テーブル
は、セグメント毎に管理され、そのサイズは、フラッシ
ュメモリの容量に応じて大きくなる。例えばフラッシュ
メモリの容量が８ＭＢ（２セグメント）の場合では、２
個のセグメントのそれぞれに対して２ページが論理−物
理アドレス変換テーブル用に使用される。論理−物理ア
ドレス変換テーブルを、フラッシュメモリ中に格納する
時には、上述した各ページの冗長部における管理フラグ
の所定の１ビットによって、当該ブロックが論理−物理
アドレス変換テーブルが格納されているブロックか否か
が指示される。
【００４８】上述したメモリカードは、ディスク状記録
媒体と同様にパーソナルコンピュータのＦＡＴシステム
によって使用可能なものである。図５には示されてない
が、フラッシュメモリ上にＩＰＬ領域、ＦＡＴ領域およ
びルート・ディレクトリ領域が設けられる。ＩＰＬ領域
には、最初にレコーダのメモリにロードすべきプログラ
ムが書かれているアドレス、並びにメモリの各種情報が
書かれている。ＦＡＴ領域には、ブロック（クラスタ）
の関連事項が書かれている。ＦＡＴには、未使用のブロ
ック、次のブロック番号、不良ブロック、最後のブロッ
クをそれぞれ示す値が規定される。さらに、ルートディ
レクトリ領域には、ディレクトリエントリ（ファイル属
性、更新年月日、開始クラスタ、ファイルサイズ等）が
書かれている。
【００４９】図６にＦＡＴ管理による管理方法を説明す
る。この図６は、メモリ内の模式図を示しており、上か
らパーティションテーブル部、空き領域、ブートセク
タ、ＦＡＴ領域、ＦＡＴのコピー領域、Ｒｏｏｔ Ｄｉ
ｒｅｃｔｏｒｙ領域、ＳｕｂＤｉｒｅｃｔｏｒｙ領域、
データ領域が積層されている。なお、メモリマップは、
論理−物理アドレス変換テーブルに基づいて、論理アド
レスから物理アドレスへ変換した後のメモリマップであ
る。
【００５０】上述したブートセクタ、ＦＡＴ領域、ＦＡ
Ｔのコピー領域、Ｒｏｏｔ Ｄｉｒｅｃｔｏｒｙ領域、
Ｓｕｂ Ｄｉｒｅｃｔｏｒｙ領域、データ領域を全部ま
とめてＦＡＴパーティション領域と称する。
【００５１】上述のパーティションテーブル部には、Ｆ
ＡＴパーティション領域の始めと終わりのアドレスが記
録されている。通常フロッピーディスクで使用されてい
るＦＡＴには、パーティションテーブル部は備えられて
いない。最初のトラックには、パーティションテーブル
以外のものは置かないために空きエリアができてしま
う。
【００５２】次に、ブートセクタには、１２ビットＦＡ
Ｔおよび１６ビットＦＡＴの何れかであるかでＦＡＴ構
造の大きさ、クラスタサイズ、それぞれの領域のサイズ
が記録されている。ＦＡＴは、データ領域に記録されて
いるファイル位置を管理するものである。ＦＡＴのコピ
ー領域は、ＦＡＴのバックアップ用の領域である。ルー
トディレクトリ部は、ファイル名、先頭クラスタアドレ
ス、各種属性が記録されており、１ファイルにつき３２
バイト使用する。
【００５３】サブディレクトリ部は、ディレクトリとい
うファイルの属性のファイルとして存在しており、図６
の実施形態ではＰＢＬＩＳＴ．ＭＳＦ、ＣＡＴ．ＭＳ
Ａ、ＤＯＧ．ＭＳＡ、ＭＡＮ. ＭＳＡという４つのファ
イルが存在する。このサブディレクトリ部には、ファイ
ル名とＦＡＴ上の記録位置が管理されている。すなわ
ち、図６においては、ＣＡＴ．ＭＳＡというファイル名
が記録されているスロットには「５」というＦＡＴ上の
アドレスが管理されており、ＤＯＧ．ＭＳＡというファ
イル名が記録されているスロットには「１０」というＦ
ＡＴ上のアドレスが管理されている。
【００５４】クラスタ２以降が実際のデータ領域で、こ
のデータ領域にこの実施形態では、ＡＴＲＡＣ３で圧縮
処理されたオーディオデータが記録される。さらに、Ｍ
ＡＮ.ＭＳＡというファイル名が記録されているスロッ
トには「１１０」というＦＡＴ上のアドレスが管理され
ている。
【００５５】この発明の実施形態では、クラスタ５、
６、７および８にＣＡＴ．ＭＳＡというファイル名のＡ
ＴＲＡＣ３で圧縮処理されたオーディオデータが記録さ
れ、クラスタ１０、１１および、１２にＤＯＧ．ＭＳＡ
というファイル名の前半パートであるＤＯＧ−１がＡＴ
ＲＡＣ３で圧縮処理されたオーディオデータが記録さ
れ、クラスタ１００および１０１にＤＯＧ．ＭＳＡとい
うファイル名の後半パートであるＤＯＧ−２がＡＴＲＡ
Ｃ３で圧縮処理されたオーディオデータが記録されてい
る。さらに、クラスタ１１０および１１１にＭＡＮ．Ｍ
ＳＡというファイル名のＡＴＲＡＣ３で圧縮処理された
オーディオデータが記録されている。
【００５６】この実施形態においては、単一のファイル
が２分割されて離散的に記録されている例を示してい
る。また、データ領域上のＥｍｐｔｙとかかれた領域は
記録可能領域である。
【００５７】クラスタ２００以降は、ファイルネームを
管理する領域であり、クラスタ２００には、ＣＡＴ．Ｍ
ＳＡというファイルが、クラスタ２０１には、ＤＯＧ．
ＭＳＡというファイルが、クラスタ２０２にはＭＡＮ．
ＭＳＡというファイルが記録されている。ファイル順を
並び替える場合には、このクラスタ２００以降で並び替
えを行えばよい。
【００５８】この実施形態のメモリカードが初めて挿入
された場合には、先頭のパーティションテーブル部を参
照してＦＡＴパーティション領域の始めと終わりのアド
レスが記録されている。ブートセクタ部の再生を行った
後にＲｏｏｔ Ｄｉｒｅｃｔｏｒｙ、Ｓｕｂ Ｄｉｒｅ
ｃｔｏｒｙ部の再生を行う。そして、Ｓｕｂ Ｄｉｒｅ
ｃｔｏｒｙ部に記録されている再生管理情報ＰＢＬＩＳ
Ｔ．ＭＳＦが記録されているスロットを検索して、ＰＢ
ＬＩＳＴ．ＭＳＦが記録されているスロットの終端部の
アドレスを参照する。
【００５９】この実施形態の場合には、ＰＢＬＩＳＴ．
ＭＳＦが記録されているスロットの終端部には「２０
０」というアドレスが記録されているのでクラスタ２０
０を参照する。クラスタ２００以降は、ファイル名を管
理すると共に、ファイルの再生順を管理する領域であ
り、この実施形態の場合には、ＣＡＴ. ＭＳＡというフ
ァイルが１曲目となり、ＤＯＧ．ＭＳＡというファイル
が２曲目となり、ＭＡＮ．ＭＳＡというファイルが３曲
目となる。
【００６０】ここで、クラスタ２００以降を全て参照し
たら、サブデレクトリ部に移行して、ＣＡＴ. ＭＳＡ、
ＤＯＧ．ＭＳＡおよびＭＡＮ．ＭＳＡという名前のファ
イル名と合致するスロットを参照する。この図６におい
ては、ＣＡＴ．ＭＳＡというファイル名が記録されたス
ロットの終端には「５」というアドレスが記録され、Ｄ
ＯＧ. ＭＳＡというファイルが記録されたスロットの終
端には「１０」というアドレスが記録され、ＭＡＮ．Ｍ
ＳＡというファイルが記録されたスロットの終端には１
１０というアドレスが記録されている。
【００６１】ＣＡＴ．ＭＳＡというファイル名が記録さ
れたスロットの終端に記録された「５」というアドレス
に基づいて、ＦＡＴ上のエントリアドレスを検索する。
エントリアドレス５には、「６」というクラスタアドレ
スがエントリされており、「６」というエントリアドレ
スを参照すると「７」というクラスタアドレスがエント
リされており、「７」というエントリアドレスを参照す
ると「８」というクラスタアドレスがエントリされてお
り、「８」というエントリアドレスを参照すると「ＦＦ
Ｆ」という終端を意味するコードが記録されている。
【００６２】よって、ＣＡＴ．ＭＳＡというファイル
は、クラスタ５、６、７、８のクラスタ領域を使用して
おり、データ領域のクラスタ５、６、７、８を参照する
ことでＣＡＴ．ＭＳＡというＡＴＲＡＣ３データが実際
に記録されている領域をアクセスすることができる。
【００６３】次に、離散記録されているＤＯＧ. ＭＳＡ
というファイルを検索する方法を以下に示す。ＤＯＧ.
ＭＳＡというファイル名が記録されたスロットの終端に
は、「１０」というアドレスが記録されている。ここ
で、「１０」というアドレスに基づいて、ＦＡＴ上のエ
ントリアドレスを検索する。エントリアドレス１０に
は、「１１」というクラスタアドレスがエントリされて
おり、「１１」というエントリアドレスを参照すると
「１２」というクラスタアドレスがエントリされてお
り、「１２」というエントリアドレスを参照すると「１
００」というクラスタアドレスがエントリされている。
さらに、「１００」というエントリアドレスを参照する
と「１０１」というクラスタアドレスがエントリされて
おり、「１０１」というエントリアドレスを参照すると
ＦＦＦという終端を意味するコードが記録されている。
【００６４】よって、ＤＯＧ．ＭＳＡというファイル
は、クラスタ１０、１１、１２、１０１０１というクラ
スタ領域を使用しており、データ領域のクラスタ１０、
１１、１２を参照することでＤＯＧ．ＭＳＡというファ
イルの前半パートに対応するＡＴＲＡＣ３データが実際
に記録されている領域をアクセスすることができる。さ
らに、データ領域のクラスタ１００、１０１を参照する
ことでＤＯＧ．ＭＳＡというファイルの後半パートに対
応するＡＴＲＡＣ３データが実際に記録されている領域
をアクセスすることができる。
【００６５】さらに、ＭＡＮ．ＭＳＡというファイル名
が記録されたスロットの終端に記録された「１１０」と
いうアドレスに基づいて、ＦＡＴ上のエントリアドレス
を検索する。エントリアドレス１１０には、「１１１」
というクラスタアドレスがエントリされており、「１１
１」というエントリアドレスを参照すると「ＦＦＦ」と
いう終端を意味するコードが記録されている。
【００６６】よって、ＭＡＮ．ＭＳＡというファイル
は、クラスタ１１０、１１１というクラスタ領域を使用
しており、データ領域のクラスタ１１０、１１１を参照
することでＭＡＮ．ＭＳＡというＡＴＲＡＣ３データが
実際に記録されている領域をアクセスすることができ
る。
【００６７】以上のようにフラッシュメモリ上で離散し
て記録されたデータファイルを連結してシーケンシャル
に再生することが可能となる。
【００６８】この一実施形態では、上述したメモリカー
ド４０のフォーマットで規定されるファイル管理システ
ムとは別個に、音楽用ファイルに対して、各トラックお
よび各トラックを構成するパーツを管理するための管理
ファイルを持つようにしている。この管理ファイルは、
メモリカード４０のユーザブロックを利用してフラッシ
ュメモリ４２上に記録される。それによって、後述する
ように、メモリカード４０上のＦＡＴが壊れても、ファ
イルの修復を可能となる。
【００６９】この管理ファイルは、ＤＳＰ３０により作
成される。例えば最初に電源をオンした時に、メモリカ
ード４０の装着されているか否かが判定され、メモリカ
ードが装着されている時には、認証が行われる。認証に
より正規のメモリカードであることが確認されると、フ
ラッシュメモリ４２のブートブロックがＤＳＰ３０に読
み込まれる。そして、論理−物理アドレス変換テーブル
が読み込まれる。読み込まれたデータは、ＳＲＡＭに格
納される。ユーザが購入して初めて使用するメモリカー
ドでも、出荷時にフラッシュメモリ４２には、ＦＡＴ
や、ルートディレクトリの書き込みがなされている。管
理ファイルは、録音がなされると、作成される。
【００７０】すなわち、ユーザのリモートコントロール
等によって発生した録音指令が外部のコントローラから
バスおよびバスインターフェース３２を介してＤＳＰ３
０に与えられる。そして、受信したオーディオデータが
エンコーダ／デコーダＩＣ１０によって圧縮され、エン
コーダ／デコーダＩＣ１０からのＡＴＲＡＣ３データが
セキュリティＩＣ２０により暗号化される。ＤＳＰ３０
が暗号化されたＡＴＲＡＣ３データをメモリカード４０
のフラッシュメモリ４２に記録する。この記録後にＦＡ
Ｔおよび管理ファイルが更新される。ファイルの更新の
度、具体的には、オーディオデータの記録を開始し、記
録を終了する度に、ＳＲＡＭ３１および３６上でＦＡＴ
および管理ファイルが書き換えられる。そして、メモリ
カード４０を外す時に、またはパワーをオフする時に、
ＳＲＡＭ３１、３６からメモリカード４０のフラッシュ
メモリ４２上に最終的なＦＡＴおよび管理ファイルが格
納される。この場合、オーディオデータの記録を開始
し、記録を終了する度に、フラッシュメモリ４２上のＦ
ＡＴおよび管理ファイルを書き換えても良い。編集を行
った場合も、管理ファイルの内容が更新される。
【００７１】さらに、この一実施形態のデータ構成で
は、付加情報も管理ファイル内に作成、更新され、フラ
ッシュメモリ４２上に記録される。管理ファイルの他の
データ構成では、付加情報管理ファイルがトラック管理
用の管理ファイルとは別に作成される。付加情報は、外
部のコントローラからバスおよびバスインターフェース
３２を介してＤＳＰ３０に与えられる。ＤＳＰ３０が受
信した付加情報をメモリカード４０のフラッシュメモリ
４２上に記録する。付加情報は、セキュリティＩＣ２０
を通らないので、暗号化されない。付加情報は、メモリ
カード４０を取り外したり、電源オフの時に、ＤＳＰ３
０のＳＲＡＭからフラッシュメモリ４２に書き込まれ
る。
【００７２】図７は、メモリカード４０のファイル構成
の全体を示す。ディレクトリとして、静止画用ディレク
トリ、動画用ディレクトリ、Ｖｏｉｃｅ用ディレクト
リ、制御用ディレクトリ、音楽用（ＨＩＦＩ）ディレク
トリが存在する。この一実施形態は、音楽の記録／再生
を行うので、以下、音楽用ディレクトリについて説明す
る。音楽用ディレクトリには、２種類のファイルが置か
れる。その１つは、再生管理ファイルＰＢＬＩＳＴ．Ｍ
ＳＦ（以下、単にＰＢＬＩＳＴと表記する）であり、他
のものは、暗号化された音楽データを収納したＡＴＲＡ
Ｃ３データファイルＡ３Ｄｎｎｎｎ．ＭＳＡ（以下、単
にＡ３Ｄｎｎｎと表記する）とからなる。ＡＴＲＡＣ３
データファイルは、最大数が４００までと規定されてい
る。すなわち、最大４００曲まで収録可能である。ＡＴ
ＲＡＣ３データファイルは、再生管理ファイルに登録し
た上で機器により任意に作成される。
【００７３】図８は、再生管理ファイルの構成を示し、
図９が１ＦＩＬＥ（１曲）のＡＴＲＡＣ３データファイ
ルの構成を示す。再生管理ファイルは、１６ＫＢ固定長
のファイルである。ＡＴＲＡＣ３データファイルは、曲
単位でもって、先頭の属性ヘッダと、それに続く実際の
暗号化された音楽データとからなる。属性ヘッダも１６
ＫＢ固定長とされ、再生管理ファイルと類似した構成を
有する。
【００７４】図８に示す再生管理ファイルは、ヘッダ、
１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バ
イトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再
生テーブルＴＲＫＴＢＬ、メモリカード全体の付加情報
ＩＮＦ−Ｓとからなる。図９に示すデータファイルの先
頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ
１、２バイトコードの曲名ＮＭ２、トラックのキー情報
等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮ
Ｆと、トラックの付加情報ＩＮＦとからなる。ヘッダに
は、総パーツ数、名前の属性、付加情報のサイズの情報
等が含まれる。
【００７５】属性ヘッダに対してＡＴＲＡＣ３の音楽デ
ータが続く。音楽データは、１６ＫＢのブロック毎に区
切られ、各ブロックの先頭にヘッダが付加されている。
ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データ
ファイル中の音楽データのみであって、それ以外の再生
管理ファイル、ヘッダ等のデータは、暗号化されない。
【００７６】図１０を参照して、曲とＡＴＲＡＣ３デー
タファイルの関係について説明する。１トラックは、１
曲を意味する。１曲は、１つのＡＴＲＡＣ３データファ
イル（図９参照）で構成される。ＡＴＲＡＣ３データフ
ァイルは、ＡＴＲＡＣ３により圧縮されたオーディオデ
ータである。メモリカード４０に対しては、クラスタと
呼ばれる単位で記録される。１クラスタは、例えば１６
ＫＢの容量である。１クラスタに複数のファイルが混じ
ることがない。フラッシュメモリ４２を消去する時の最
小単位が１ブロックである。音楽データを記録するのに
使用するメモリカード４０の場合、ブロックとクラスタ
は、同意語であり、且つ１クラスタ＝１セクタと定義さ
れている。
【００７７】１曲は、基本的に１パーツで構成される
が、編集が行われると、複数のパーツから１曲が構成さ
れることがある。パーツは、録音開始からその停止まで
の連続した時間内で記録されたデータの単位を意味し、
通常は、１トラックが１パーツで構成される。曲内のパ
ーツのつながりは、各曲の属性ヘッダ内のパーツ情報Ｐ
ＲＴＩＮＦで管理する。すなわち、パーツサイズは、Ｐ
ＲＴＩＮＦの中のパーツサイズＰＲＴＳＩＺＥという４
バイトのデータで表す。パーツサイズＰＲＴＳＩＺＥの
先頭の２バイトがパーツが持つクラスタの総数を示し、
続く各１バイトが先頭および末尾のクラスタ内の開始サ
ウンドユニット（以下、ＳＵと略記する）の位置、終了
ＳＵの位置を示す。このようなパーツの記述方法を持つ
ことによって、音楽データを編集する際に通常、必要と
される大量の音楽データの移動をなくすことが可能とな
る。ブロック単位の編集に限定すれば、同様に音楽デー
タの移動を回避できるが、ブロック単位は、ＳＵ単位に
比して編集単位が大きすぎる。
【００７８】ＳＵは、パーツの最小単位であり、且つＡ
ＴＲＡＣ３でオーディオデータを圧縮する時の最小のデ
ータ単位である。４４．１ｋHzのサンプリング周波数で
得られた１０２４サンプル分（１０２４×１６ビット×
２チャンネル）のオーディオデータを約１／１０に圧縮
した数百バイトのデータがＳＵである。１ＳＵは、時間
に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵ
によって１つのパーツが構成される。１クラスタが４２
個のＳＵで構成される場合、１クラスタで約１秒の音を
表すことができる。１つのトラックを構成するパーツの
数は、付加情報サイズに影響される。パーツ数は、１ブ
ロックの中からヘッダや曲名、付加情報データ等を除い
た数で決まるために、付加情報が全く無い状態が最大数
（６４５個）のパーツを使用できる条件となる。
【００７９】図１０Ａは、ＣＤ等からのオーディオデー
タを２曲連続して記録する場合のファイル構成を示す。
１曲目（ファイル１）が例えば５クラスタで構成され
る。１曲目と２曲目（ファイル２）の曲間では、１クラ
スタに二つのファイルが混在することが許されないの
で、次のクラスタの最初からファイル２が作成される。
従って、ファイル１に対応するパーツ１の終端（１曲目
の終端）がクラスタの途中に位置し、クラスタの残りの
部分には、データが存在しない。第２曲目（ファイル
２）も同様に１パーツで構成される。ファイル１の場合
では、パーツサイズが５、開始クラスタのＳＵが０、終
了クラスタが４となる。
【００８０】編集操作として、デバイド、コンバイン、
イレーズ、ムーブの４種類の操作が規定される。デバイ
ドは、１つのトラックを２つに分割することである。デ
バイドがされると、総トラック数が１つ増加する。デバ
イドは、一つのファイルをファイルシステム上で分割し
て２つのファイルとし、再生管理ファイルおよびＦＡＴ
を更新する。コンバインは、２つのトラックを１つに統
合することである。コンバインされると、総トラック数
が１つ減少する。コンバインは、２つのファイルをファ
イルシステム上で統合して１つのファイルにし、再生管
理ファイルおよびＦＡＴを更新する。イレーズは、トラ
ックを消去することである。消された以降のトラック番
号が１つ減少する。ムーブは、トラック順番を変えるこ
とである。以上イレーズおよびムーブ処理についても、
再生管理ファイルおよびＦＡＴを更新する。
【００８１】図１０Ａに示す二つの曲（ファイル１およ
びファイル２）をコンバインした結果を図１０Ｂに示
す。コンバインされた結果は、１つのファイルであり、
このファイルは、二つのパーツからなる。また、図１０
Ｃは、一つの曲（ファイル１）をクラスタ２の途中でデ
バイドした結果を示す。デバイドによって、クラスタ
０、１およびクラスタ２の前側からなるファイル１と、
クラスタ２の後側とクラスタ３および４とからなるファ
イル２とが発生する。
【００８２】上述したように、この一実施形態では、パ
ーツに関する記述方法があるので、コンバインした結果
である図１０Ｂにおいて、パーツ１の開始位置、パーツ
１の終了位置、パーツ２の開始位置、パーツ２の終了位
置をそれぞれＳＵ単位でもって規定できる。その結果、
コンバインした結果のつなぎ目の隙間をつめるために、
パーツ２の音楽データを移動する必要がない。また、パ
ーツに関する記述方法があるので、デバイドした結果で
ある図１０Ｃにおいて、ファイル２の先頭の空きを詰め
るように、データを移動する必要がない。
【００８３】図１１は、再生管理ファイルＰＢＬＩＳＴ
のより詳細なデータ構成を示し、図１２Ａおよび図１２
Ｂは、再生管理ファイルＰＢＬＩＳＴを構成するヘッダ
とそれ以外の部分をそれぞれ示す。再生管理ファイルＰ
ＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）の
サイズである。図１２Ａに示すヘッダは、３２バイトか
ら成る。図１２Ｂに示すヘッダ以外の部分は、メモリカ
ード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名
前ＮＭ２−Ｓ（５１２バイト）、ＣＯＮＴＥＮＴＳＫＥ
Ｙ、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理する
テーブルＴＲＫＴＢＬ（８００バイト）、メモリカード
全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）
および最後にヘッダ中の情報の一部が再度記録されてい
る。これらの異なる種類のデータ群のそれぞれの先頭
は、再生管理ファイル内で所定の位置となるように規定
されている。
【００８４】再生管理ファイルは、図１２Ａに示す（０
ｘ００００）および（０ｘ００１０）で表される先頭か
ら３２バイトがヘッダである。なお、ファイル中で先頭
から１６バイト単位で区切られた単位をスロットと称す
る。ファイルの第１および第２のスロットに配されるヘ
ッダには、下記の意味、機能、値を持つデータが先頭か
ら順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されて
いるデータは、未定義のデータを表している。通常ヌル
（０ｘ００）が書かれるが、何が書かれていてもＲｅｓ
ｅｒｖｅｄのデータが無視される。将来のバージョンで
は、変更がありうる。また、この部分への書き込みは禁
止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合
は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【００８５】ＢＬＫＩＤ−ＴＬ０（４バイト） 意味：BLOCKID FILE ID 機能：再生管理ファイルの先頭であることを識別するた
めの値 値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３
０） ＭＣｏｄｅ（２バイト） 意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード 値：上位１０ビット（メーカーコード） 下位６ビット
（機種コード） ＲＥＶＩＳＩＯＮ（４バイト） 意味：ＰＢＬＩＳＴの書き換え回数 機能：再生管理ファイルを書き換える度にインクリメン
ト 値：０より始まり＋１づつ増加する Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ） 意味：信頼できる時計を持つ機器で記録した年・月・日
・時・分・秒 機能：最終記録日時を識別するための値 値：２５〜３１ビット 年 ０〜９９（１９８０〜２０７９） ２１〜２４ビット 月 ０〜１２ １６〜２０ビット 日 ０〜３１ １１〜１５ビット 時 ０〜２３ ０５〜１０ビット 分 ０〜５９ ００〜０４ビット 秒 ０〜２９（２秒単位）。
【００８６】ＳＮ１Ｃ＋Ｌ（２バイト） 意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前
（１バイト）の属性を表す 機能：使用する文字コードと言語コードを各１バイトで
表す 値：文字コード（Ｃ）は上位１バイトで下記のように文
字を区別する 00: 文字コードは設定しない。単なる２進数として扱う
こと 01: ASCII(American Standard Code for Information I
nterchange) 02:ASCII+KANA 03:modifided8859-1 81:MS-JIS 82:KS C 5601-1989 83:GB(Great Britain)
2312-80 90:S-JIS(Japanese Industrial Standards)(for Voic
e)。
【００８７】言語コード（Ｌ）は下位１バイトで下記の
ようにEBU Tech 3258 規定に準じて言語を区別する 00: 設定しない 08:German 09:English 0A:Spanish 0F:French 15:Italian 1D:Dutch 65:Korean 69:Japanese 75:Chinese データが無い場合オールゼロとすること。
【００８８】ＳＮ２Ｃ＋Ｌ（２バイト） 意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前
（２バイト）の属性を表す 機能：使用する文字コードと言語コードを各１バイトで
表す 値：上述したＳＮ１Ｃ＋Ｌと同一 ＳＩＮＦＳＩＺＥ（２バイト） 意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関
する付加情報の全てを合計したサイズを表す 機能：データサイズを１６バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること 値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４） Ｔ−ＴＲＫ（２バイト） 意味：TOTAL TRACK NUMBER 機能：総トラック数 値：１から０ｘ０１９０（最大４００トラック）、デー
タが無い場合はオールゼロとすること ＶｅｒＮｏ（２バイト） 意味：フォーマットのバージョン番号 機能：上位がメジャーバージョン番号、下位がマイナー
バージョン番号
【００８９】上述したヘッダに続く領域に書かれるデー
タ（図１３Ｂ）について以下に説明する。
【００９０】ＮＭ１−Ｓ 意味：メモリカード全体に関する１バイトの名前 機能：１バイトの文字コードで表した可変長の名前デー
タ（最大で２５６） 名前データの終了は、必ず終端コード（０ｘ００）を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ００２０）からヌル（０
ｘ００）を１バイト以上記録すること 値：各種文字コード ＮＭ２−Ｓ 意味：メモリカード全体に関する２バイトの名前 機能：２バイトの文字コードで表した可変長の名前デー
タ（最大で５１２） 名前データの終了は、必ず終端コード（０ｘ００）を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ０１２０）からヌル（０
ｘ００）を２バイト以上記録すること 値：各種文字コード。
【００９１】ＣＯＮＴＥＮＴＳ ＫＥＹ 意味：曲ごとに用意された値でＭＧ（Ｍ）で保護されて
から保存される。ここでは、１曲目に付けられるＣＯＮ
ＴＥＮＴＳ ＫＥＹと同じ値 機能：Ｓ−ＹＭＤｈｍｓのＭＡＣの計算に必要となる鍵
となる 値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで ＭＡＣ 意味：著作権情報改ざんチェック値 機能：Ｓ−ＹＭＤｈｍｓの内容とＣＯＮＴＥＮＴＳ Ｋ
ＥＹから作成される値 値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦま
で。
【００９２】ＴＲＫ−ｎｎｎ 意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ
（シーケンス）番号 機能：ＴＲＫＩＮＦの中のＦＮｏを記述する 値：１から４００（０ｘ１９０） トラックが存在しない時はオールゼロとすること ＩＮＦ−Ｓ 意味：メモリカード全体に関する付加情報データ（例え
ば写真、歌詞、解説等の情報） 機能：ヘッダを伴った可変長の付加情報データ 複数の異なる付加情報が並べられることがある。それぞ
れにＩＤとデータサイズが付けられている。個々のヘッ
ダを含む付加情報データは最小１６バイト以上で４バイ
トの整数倍の単位で構成される。その詳細については、
後述する値：付加情報データ構成を参照 Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ） 意味：信頼できる時計を持つ機器で記録した年・月・日
・時・分・秒 機能：最終記録日時を識別するための値、ＥＭＤの時は
必須 値：２５〜３１ビット 年 ０〜９９（１９８０〜２０７９） ２１〜２４ビット 月 ０〜１２ １６〜２０ビット 日 ０〜３１ １１〜１５ビット 時 ０〜２３ ０５〜１０ビット 分 ０〜５９ ００〜０４ビット 秒 ０〜２９（２秒単位）。
【００９３】再生管理ファイルの最後のスロットとし
て、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、Ｍ
Ｃｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【００９４】民生用オーディオ機器として、メモリカー
ドが記録中に抜かれたり、電源が切れることがあり、復
活した時にこれらの異常の発生を検出することが必要と
される。上述したように、ＲＥＶＩＳＩＯＮをブロック
の先頭と末尾に書き込み、この値を書き換える度に＋１
インクリメントするようにしている。若し、ブロックの
途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳ
ＩＯＮの値が一致せず、異常終了を検出することができ
る。ＲＥＶＩＳＩＯＮが２個存在するので、高い確率で
異常終了を検出することができる。異常終了の検出時に
は、エラーメッセージの表示等の警告が発生する。
【００９５】また、１ブロック（１６ＫＢ）の先頭部分
に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡ
Ｔが壊れた場合の修復の目安に固定値を使用できる。す
なわち、各ブロックの先頭の固定値を見れば、ファイル
の種類を判別することが可能である。しかも、この固定
値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロ
ックの終端部分に二重に記述するので、その信頼性のチ
ェックを行うことができる。なお、再生管理ファイルＰ
ＢＬＩＳＴの同一のものを二重に記録しても良い。
【００９６】ＡＴＲＡＣ３データファイルは、トラック
情報管理ファイルと比較して、相当大きなデータ量であ
り、ＡＴＲＡＣ３データファイルに関しては、後述する
ように、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付け
られている。但し、ＡＴＲＡＣ３データファイルは、通
常複数のファイルがメモリカード上に存在するので、Ｃ
ＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯ
ＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡ
Ｔが壊れた場合のファイルの復旧が困難となる。換言す
ると単一のＡＴＲＡＣ３データファイルは、複数のＢＬ
ＯＣＫで構成されると共に、離散して配置される可能性
があるので、同一ＡＴＲＡＣ３データファイルを構成す
るＢＬＯＣＫを判別するためにＣＯＮＮＵＭ０を用いる
と共に、同一ＡＴＲＡＣ３データファイル内の昇降順を
ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬで決定する。
【００９７】同様に、ＦＡＴの破壊までにはいたらない
が、論理を間違ってファイルとして不都合のあるような
場合に、書き込んだメーカーの機種が特定できるよう
に、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と
末尾に記録されている。
【００９８】図１２Ｃは、付加情報データの構成を示
す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ
以降に可変長のデータが書かれる。
【００９９】ＩＮＦ 意味：FIELD ID 機能：付加情報データの先頭を示す固定値 値：０ｘ６９ ＩＤ 意味：付加情報キーコード 機能：付加情報の分類を示す 値：０から０ｘＦＦ ＳＩＺＥ 意味：個別の付加情報の大きさ 機能：データサイズは自由であるが、必ず４バイトの整
数倍でなければならない。また、最小１６バイト以上の
こと。データの終わりより余りがでる場合はヌル（０ｘ
００）で埋めておくこと 値：１６から１４７８４（０ｘ３９Ｃ０） ＭＣｏｄｅ 意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード 値：上位１０ビット（メーカーコード） 下位６ビット
（機種コード） Ｃ＋Ｌ 意味：先頭から１２バイト目からのデータ領域に書かれ
る文字の属性を表す 機能：使用する文字コードと言語コードを各１バイトで
表す 値：前述のＳＮＣ＋Ｌと同じ ＤＡＴＡ 意味：個別の付加情報データ 機能：可変長データで表す。実データの先頭は常に１２
バイト目より始まり、長さ（サイズ）は最小４バイト以
上、常に４バイトの整数倍でなければならない。データ
の最後から余りがある場合はヌル（０ｘ００）で埋める
こと 値：内容により個別に定義される。
【０１００】図１３は、付加情報キーコードの値（０〜
６３）と、付加情報の種類の対応の一例を示す。キーコ
ードの値（０〜３１）が音楽に関する文字情報に対して
割り当てられ、その（３２〜６３）がＵＲＬ(Uniform R
esource Locator)（Ｗｅｂ関係）に対して割り当てられ
ている。アルバムタイトル、アーティスト名、ＣＭ等の
文字情報が付加情報として記録される。
【０１０１】図１４は、付加情報キーコードの値（６４
〜１２７）と、付加情報の種類の対応の一例を示す。キ
ーコードの値（６４〜９５）がパス／その他に対して割
り当てられ、その（９６〜１２７）が制御／数値・デー
タ関係に対して割り当てられている。例えば（ＩＤ＝９
８）の場合では、付加情報がＴＯＣ（Table of Conten
t）−ＩＤとされる。ＴＯＣ−ＩＤは、ＣＤ（コンパク
トディスク）のＴＯＣ情報に基づいて、最初の曲番号、
最後の曲番号、その曲番号、総演奏時間、その曲演奏時
間を示すものである。
【０１０２】図１５は、付加情報キーコードの値（１２
８〜１５９）と、付加情報の種類の対応の一例を示す。
キーコードの値（１２８〜１５９）が同期再生関係に対
して割り当てられている。図１５中のＥＭＤ(Electroni
c Music Distribution)は、電子音楽配信の意味であ
る。
【０１０３】図１６を参照して付加情報のデータの具体
例について説明する。図１６Ａは、図１２Ｃと同様に、
付加情報のデータ構成を示す。図１６Ｂは、キーコード
ＩＤ＝３とされる、付加情報がアーティスト名の例であ
る。ＳＩＺＥ＝０ｘ１Ｃ（２８バイト）とされ、ヘッダ
を含むこの付加情報のデータ長が２８バイトであること
が示される。また、Ｃ＋Ｌが文字コードＣ＝０ｘ０１と
され、言語コードＬ＝０ｘ０９とされる。この値は、前
述した規定によって、ＡＳＣＩＩの文字コードで、英語
の言語であることを示す。そして、先頭から１２バイト
目から１バイトデータでもって、「ＳＩＭＯＮ＆ＧＲＡ
ＦＵＮＫＥＬ」のアーティスト名のデータが書かれる。
付加情報のサイズは、４バイトの整数倍と決められてい
るので、１バイトの余りが（０ｘ００）とされる。
【０１０４】図１６Ｃは、キーコードＩＤ＝９７とされ
る、付加情報がＩＳＲＣ(International Standard Reco
rding Code：著作権コード) の例である。ＳＩＺＥ＝０
ｘ１４（２０バイト）とされ、この付加情報のデータ長
が２０バイトであることが示される。また、Ｃ＋ＬがＣ
＝０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が
無いこと、すなわち、データが２進数であることが示さ
れる。そして、データとして８バイトのＩＳＲＣのコー
ドが書かれる。ＩＳＲＣは、著作権情報（国、所有者、
録音年、シリアル番号）を示すものである。
【０１０５】図１６Ｄは、キーコードＩＤ＝９７とされ
る、付加情報が録音日時の例である。ＳＩＺＥ＝０ｘ１
０（１６バイト）とされ、この付加情報のデータ長が１
６バイトであることが示される。また、Ｃ＋ＬがＣ＝０
ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無い
ことが示される。そして、データとして４バイト（３２
ビット）のコードが書かれ、録音日時（年、月、日、
時、分、秒）が表される。
【０１０６】図１６Ｅは、キーコードＩＤ＝１０７とさ
れる、付加情報が再生ログの例である。ＳＩＺＥ＝０ｘ
１０（１６バイト）とされ、この付加情報のデータ長が
１６バイトであることが示される。また、Ｃ＋ＬがＣ＝
０ｘ００、Ｌ＝０ｘ００とされ、文字、言語の設定が無
いことが示される。そして、データとして４バイト（３
２ビット）のコードが書かれ、再生ログ（年、月、日、
時、分、秒）が表される。再生ログ機能を持つものは、
１回の再生毎に１６バイトのデータを記録する。
【０１０７】図１７は、１ＳＵがＮバイト（例えばＮ＝
３８４バイト）の場合のＡＴＲＡＣ３データファイルＡ
３Ｄｎｎｎｎのデータ配列を示す。図１７には、データ
ファイルの属性ヘッダ（１ブロック）と、音楽データフ
ァイル（１ブロック）とが示されている。図１７では、
この２ブロック（１６×２＝３２Ｋバイト）の各スロッ
トの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示
されている。図１８に分離して示すように、属性ヘッダ
の先頭から３２バイトがヘッダであり、２５６バイトが
曲名領域ＮＭ１（２５６バイト）であり、５１２バイト
が曲名領域ＮＭ２（５１２バイト）である。属性ヘッダ
のヘッダには、下記のデータが書かれる。
【０１０８】ＢＬＫＩＤ−ＨＤ０（４バイト） 意味：BLOCKID FILE ID 機能：ＡＴＲＡＣ３データファイルの先頭であることを
識別するための値 値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３
０） ＭＣｏｄｅ（２バイト） 意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード 値：上位１０ビット（メーカーコード） 下位６ビット
（機種コード） ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト） 意味：トラック毎に付けられた連続番号 機能：ブロックの先頭は０から始まり次のブロックは＋
１づつインクリメント編集されても値を変化させない 値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【０１０９】Ｎ１Ｃ＋Ｌ（２バイト） 意味：トラック（曲名）データ（ＮＭ１）の属性を表す 機能：ＮＭ１に使用される文字コードと言語コードを各
１バイトで表す 値：ＳＮ１Ｃ＋Ｌと同一 Ｎ２Ｃ＋Ｌ（２バイト） 意味：トラック（曲名）データ（ＮＭ２）の属性を表す 機能：ＮＭ２に使用される文字コードと言語コードを各
１バイトで表す 値：ＳＮ１Ｃ＋Ｌと同一 ＩＮＦＳＩＺＥ（２バイト） 意味：トラックに関する付加情報の全てを合計したサイ
ズを表す 機能：データサイズを１６バイト単位の大きさで記述、
無い場合は必ずオールゼロとすること 値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６） Ｔ−ＰＲＴ（２バイト） 意味：トータルパーツ数 機能：トラックを構成するパーツ数を表す。通常は１ 値：１から０ｘ２８５（６４５dec ） Ｔ−ＳＵ（４バイト） 意味：トータルＳＵ数 機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏
時間に相当する 値：０ｘ０１から０ｘ００１ＦＦＦＦＦ ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ） 意味：INDEX の相対場所 機能：曲のさびの部分（特徴的な部分）の先頭を示すポ
インタ。曲の先頭からの位置をＳＵの個数を１／４した
数で指定する。これは、通常のＳＵの４倍の長さの時間
（約９３ｍ秒）に相当する 値：０から０ｘＦＦＦＦ（最大、約６０８４秒） ＸＴ（２バイト）（Ｏｐｔｉｏｎ） 意味：INDEX の再生時間 機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間
のＳＵの個数を１／４した数で指定する。これは、通常
のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する 値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦ
Ｅ（最大６０８４秒） ０ｘＦＦＦＦ：曲の終わりまで。
【０１１０】次に曲名領域ＮＭ１およびＮＭ２について
説明する。
【０１１１】ＮＭ１ 意味：曲名を表す文字列 機能：１バイトの文字コードで表した可変長の曲名（最
大で２５６） 名前データの終了は、必ず終端コード（０ｘ００）を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ００２０）からヌル（０
ｘ００）を１バイト以上記録すること 値：各種文字コード ＮＭ２ 意味：曲名を表す文字列 機能：２バイトの文字コードで表した可変長の名前デー
タ（最大で５１２） 名前データの終了は、必ず終端コード（０ｘ００）を書
き込むこと サイズはこの終端コードから計算すること、データの無
い場合は少なくとも先頭（０ｘ０１２０）からヌル（０
ｘ００）を２バイト以上記録すること 値：各種文字コード。
【０１１２】属性ヘッダの固定位置（０ｘ３２０）から
始まる、８０バイトのデータをトラック情報領域ＴＲＫ
ＩＮＦと呼び、主としてセキュリティ関係、コピー制御
関係の情報を一括して管理する。図１９にＴＲＫＩＮＦ
の部分を示す。ＴＲＫＩＮＦ内のデータについて、配置
順序に従って以下に説明する。
【０１１３】ＣＯＮＴＥＮＴＳ ＫＥＹ（８バイト） 意味：曲毎に用意された値で、メモリカードのセキュリ
ティブロックで保護されてから保存される 機能：曲を再生する時、まず必要となる最初の鍵とな
る。ＭＡＣ計算時に使用される 値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで ＭＡＣ（８バイト） 意味：著作権情報改ざんチェック値 機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの
内容と隠しシーケンス番号から作成される値 隠しシーケンス番号とは、メモリカードの隠し領域に記
録されているシーケンス番号のことである。著作権対応
でないレコーダは、隠し領域を読むことができない。ま
た、著作権対応の専用のレコーダ、またはメモリカード
を読むことを可能とするアプリケーションを搭載したパ
ーソナルコンピュータは、隠し領域をアクセスすること
ができる。
【０１１４】Ａ（１バイト） 意味：パーツの属性 機能：パーツ内の圧縮モード等の情報を示す 値：図２０を参照して以下に説明する ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ
信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎ
ｔモードをモノラルとして規定する。ｂｉｔ２，１の情
報は通常の再生機は無視しても構わない。
【０１１５】Ａのビット０は、エンファシスのオン／オ
フの情報を形成し、ビット１は、再生ＳＫＩＰか、通常
再生かの情報を形成し、ビット２は、データ区分、例え
ばオーディオデータか、ＦＡＸ等の他のデータかの情報
を形成する。ビット３は、未定義である。ビット４、
５、６を組み合わせることによって、図示のように、Ａ
ＴＲＡＣ３のモード情報が規定される。すなわち、Ｎ
は、この３ビットで表されるモードの値であり、モノ
（Ｎ＝０，１）、ＬＰ（Ｎ＝２）、ＳＰ（Ｎ＝４）、Ｈ
Ｘ（Ｎ＝５）、ＨＱ（Ｎ＝７）の５種類のモードについ
て、記録時間（６４ＭＢのメモリカードの場合）、デー
タ転送レート、１ブロック内のＳＵ数がそれぞれ示され
ている。１ＳＵのバイト数は、（モノ：１３６バイト、
ＬＰ：１９２バイト、ＳＰ：３０４バイト、ＥＸ：３８
４バイト、ＨＱ：５１２バイト）である。さらに、ビッ
ト７によって、ＡＴＲＡＣ３のモード（０：Dual １：
J0int ）が示される。
【０１１６】一例として、６４ＭＢのメモリカードを使
用し、ＳＰモードの場合について説明する。６４ＭＢの
メモリカードには、３９６８ブロックがある。ＳＰモー
ドでは、１ＳＵが３０４バイトであるので、１ブロック
に５３ＳＵが存在する。１ＳＵは、（１０２４／４４１
００）秒に相当する。従って、１ブロックは、 （１０２４／４４１００）×５３×（３９６８−１６）
＝４８６３秒＝８１分 転送レートは、 （４４１００／１０２４）×３０４×８＝１０４７３７
bps となる。
【０１１７】ＬＴ（１バイト） 意味：再生制限フラグ（ビット７およびビット６）とセ
キュリティバージョン（ビット５〜ビット０） 機能：このトラックに関して制限事項があることを表す 値：ビット７： ０＝制限なし １＝制限有り ビット６： ０＝期限内 １＝期限切れ ビット５〜ビット０：セキュリティバージョン０（０以外であれば再生禁 止とする） ＦＮｏ（２バイト） 意味：ファイル番号 機能：最初に記録された時のトラック番号、且つこの値
は、メモリカード内の隠し領域に記録されたＭＡＣ計算
用の値の位置を特定する 値：１から０ｘ１９０（４００） ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト） 意味：記録機器のセキュリティブロック（セキュリティ
ＩＣ２０）のシリアル番号 機能：記録機器ごとに全て異なる固有の値 値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ＣＯＮＮＵＭ（４バイト） 意味：コンテンツ累積番号 機能：曲毎に累積されていく固有の値で記録機器のセキ
ュリティブロックによって管理される。２の３２乗、４
２億曲分用意されており、記録した曲の識別に使用する 値：０から０ｘＦＦＦＦＦＦＦＦ。
【０１１８】 ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ） 意味：再生制限付きのトラックの再生開始日時 機能：ＥＭＤで指定する再生開始を許可する日時 値：上述した日時の表記と同じ ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ） 意味：再生制限付きのトラックの再生終了日時 機能：ＥＭＤで指定する再生許可を終了する日時 値：上述した日時の表記と同じ ＭＴ（１バイト）（Ｏｐｔｉｏｎ） 意味：再生許可回数の最大値 機能：ＥＭＤで指定される最大の再生回数 値：１から０ｘＦＦ 未使用の時は、０ｘ００ ＬＴのｂｉｔ７の値が０の場合はＭＴの値は００とする
こと ＣＴ（１バイト）（Ｏｐｔｉｏｎ） 意味：再生回数 機能：再生許可された回数の内で、実際に再生できる回
数。再生の度にデクリメントする 値：０ｘ００〜０ｘＦＦ 未使用の時は、０ｘ００であ
る ＬＴのｂｉｔ７が１でＣＴの値が００の場合は再生を禁
止すること。
【０１１９】ＣＣ（１バイト） 意味：COPY CONTROL 機能：コピー制御 値：図２１に示すように、ビット６および７によってコ
ピー制御情報を表し、ビット４および５によって高速デ
ィジタルコピーに関するコピー制御情報を表し、ビット
２および３によってセキュリティブロック認証レベルを
表す。ビット０および１は、未定義 ＣＣの例：（ｂｉｔ７，６）１１：無制限のコピーを許
可、０１：コピー禁止、００：１回のコピーを許可 （ｂｉｔ３，２）００：アナログないしディジタルイン
からの録音、ＭＧ認証レベルは０とする ＣＤからのディジタル録音では（ｂｉｔ７，６）は０
０、（ｂｉｔ３，２）は１０となる ＣＮ（１バイト）（Ｏｐｔｉｏｎ） 意味：高速ディジタルコピーＨＳＣＭＳ(High speed Se
rial Copy ManagementSystem)におけるコピー許可回数 機能：コピー１回か、コピーフリーかの区別を拡張し、
回数で指定する。コピー第１世代の場合にのみ有効であ
り、コピーごとに減算する 値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘ
ＦＦ：回数無制限。
【０１２０】上述したトラック情報領域ＴＲＫＩＮＦに
続いて、０ｘ０３７０から始まる２４バイトのデータを
パーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１
つのトラックを複数のパーツで構成する場合に、時間軸
の順番にＰＲＴＩＮＦを並べていく。図２２にＰＲＴＩ
ＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、
配置順序に従って以下に説明する。
【０１２１】ＰＲＴＳＩＺＥ（４バイト） 意味：パーツサイズ 機能：パーツの大きさを表す。クラスタ：２バイト（最
上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バ
イト（最下位） 値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始
ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０
ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，
２，と０から開始する） ＰＲＴＫＥＹ（８バイト） 意味：パーツを暗号化するための値 機能：初期値＝０、編集時は編集の規則に従うこと 値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ ＣＯＮＮＵＭ０（４バイト） 意味：最初に作られたコンテンツ累積番号キー 機能：コンテンツをユニークにするためのＩＤの役割 値：コンテンツ累積番号初期値キーと同じ値とされる。
【０１２２】ＡＴＲＡＣ３データファイルの属性ヘッダ
中には、図１７に示すように、付加情報ＩＮＦが含まれ
る。この付加情報は、開始位置が固定化されていない点
を除いて、再生管理ファイル中の付加情報ＩＮＦ−Ｓ
（図１１および図１２Ｂ参照）と同一である。１つまた
は複数のパーツの最後のバイト部分（４バイト単位）の
次を開始位置として付加情報ＩＮＦのデータが開始す
る。
【０１２３】ＩＮＦ 意味：トラックに関する付加情報データ 機能：ヘッダを伴った可変長の付加情報データ。複数の
異なる付加情報が並べられることがある。それぞれにＩ
Ｄとデータサイズが付加されている。個々のヘッダを含
む付加情報データは、最小１６バイト以上で４バイトの
整数倍の単位 値：再生管理ファイル中の付加情報ＩＮＦ−Ｓと同じで
ある。
【０１２４】上述した属性ヘッダに対して、ＡＴＲＡＣ
３データファイルの各ブロックのデータが続く。図２３
に示すように、ブロック毎にヘッダが付加される。各ブ
ロックのデータについて以下に説明する。
【０１２５】ＢＬＫＩＤ−Ａ３Ｄ（４バイト） 意味：BLOCKID FILE ID 機能：ＡＴＲＡＣ３データの先頭であることを識別する
ための値 値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２
０） ＭＣｏｄｅ（２バイト） 意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード 値：上位１０ビット（メーカーコード） 下位６ビット
（機種コード） ＣＯＮＮＵＭ０（４バイト） 意味：最初に作られたコンテンツ累積番号 機能：コンテンツをユニークにするためのＩＤの役割、
編集されても値は変化させない 値：コンテンツ累積番号初期値キーと同じ値とされる ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト） 意味：トラック毎に付けられた連続番号 機能：ブロックの先頭は０から始まり次のブロックは＋
１づつインクリメント編集されても値を変化させない 値：０より始まり０ｘＦＦＦＦＦＦＦＦまで ＢＬＯＣＫ−ＳＥＥＤ（８バイト） 意味：１ブロックを暗号化するための１つの鍵 機能：ブロックの先頭は、記録機器のセキュリティブロ
ックで乱数を生成、続くブロックは、＋１インクリメン
トされた値、この値が失われると、１ブロックに相当す
る約１秒間、音が出せないために、ヘッダとブロック末
尾に同じものが二重に書かれる。編集されても値を変化
させない 値：初期は８バイトの乱数 ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイ
ト） 意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号
化する時に必要な初期値 機能：ブロックの先頭は０から始まり、次のブロックは
最後のＳＵの最後の暗号化された８バイトの値。デバイ
ドされたブロックの途中からの場合は開始ＳＵの直前の
最後の８バイトを用いる。編集されても値を変化させな
い 値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ ＳＵ−ｎｎｎ 意味：サウンドユニットのデータ 機能：１０２４サンプルから圧縮されたデータ、圧縮モ
ードにより出力されるバイト数が異なる。編集されても
値を変化させない（一例として、ＳＰモードの時では、
Ｎ＝３８４バイト） 値：ＡＴＲＡＣ３のデータ値。
【０１２６】図１７では、Ｎ＝３８４であるので、１ブ
ロックに４２ＳＵが書かれる。また、１ブロックの先頭
の２つのスロット（４バイト）がヘッダとされ、最後の
１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏ
ｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二
重に書かれる。従って、１ブロックの余りの領域Ｍバイ
トは、（１６，３８４−３８４×４２−１６×３＝２０
８（バイト）となる。この中に上述したように、８バイ
トのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【０１２７】ここで、上述したＦＡＴ領域が壊れた場合
には、フラッシュメモリの全ブロックの探索を開始し、
ブロック先頭部のブロックＩＤ ＢＬＫＩＤがＴＬ０
か、ＨＤ０か、Ａ３Ｄかを各ブロックについて判別す
る。この処理を図２４に示すフローチャートを参照し
て、説明する。ブロック先頭のブロックＩＤ ＢＬＫＩ
ＤがＢＬＫＩＤ−ＴＬ０であるか否かをステップＳＰ１
で判別する。
【０１２８】このステップＳＰ１において、ブロック先
頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−ＴＬ０で
無い場合には、ステップＳＰ２において、ブロック番号
をインクリメント処理して、ステップＳＰ３において、
ブロックの終端部まで検索したかを判別する。ステップ
ＳＰ３において、ブロックの終端部まで至ってないと判
別された場合には、再度ステップＳＰ１に戻る。
【０１２９】そして、ステップＳＰ１において、ブロッ
ク先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−ＴＬ
０と判別された場合には、ステップＳＰ４において、検
索したブロックが再生管理ファイルＰＢＬＩＳＴである
と判定される。次に、ステップＳＰ５において、再生管
理ファイルＰＢＬＩＳＴ内に含まれる総トラック数Ｔ−
ＴＲＫを参照して、レジスタにＮとして記憶する。一例
として、メモリ上に１０曲のＡＴＲＡＣ３データファイ
ルが存在する場合には（すなわち１０ファイル）Ｔ−Ｔ
ＲＫには１０が記録されている。
【０１３０】次に、ステップＳＰ６において、総トラッ
ク数Ｔ−ＴＲＫに基づいてブロック内に記録されている
ＴＲＫ−００１からＴＲＫ−４００を順次参照する。上
述した一例の場合には、メモリ内に１０曲収録されてい
るのでＴＲＫ−００１からＴＲＫ−０１０までを参照す
ればよい。
【０１３１】ステップＳＰ７において、ＴＲＫ−ＸＸＸ
（ＸＸＸ＝００１〜４００）には、対応するファイル番
号ＦＮＯが記録されているので、上記トラック番号ＴＲ
Ｋ−ＸＸＸとファイル番号ＦＮＯの対応表をメモリに記
憶する。
【０１３２】ステップＳＰ８において、レジスタに記憶
したＮをデクリメント処理して、ステップＳＰ９におい
て、Ｎ＝０になるまでステップＳＰ６、ＳＰ７およびＳ
Ｐ８を繰り返す。ステップＳＰ９において、Ｎ＝０と判
断されたらステップＳＰ１０において、先頭のブロック
にポインタをリセットして、先頭のブロックから探索を
やり直す。
【０１３３】次に、ステップＳＰ１１において、ブロッ
ク先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−ＨＤ
０か否かを判別する。このステップＳＰ１１において、
ブロック先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ
−ＨＤ０で無い場合には、ステップＳＰ１２において、
ブロック番号をインクリメント処理して、ステップＳＰ
１３において、ブロックの終端部まで検索したか否かを
判別する。
【０１３４】そして、ステップＳＰ１３において、ブロ
ックの終端部まで至ってないと判別された場合には、再
度ステップＳＰ１１に制御が戻る。
【０１３５】ステップＳＰ１１において、ブロック先頭
のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−ＨＤ０であ
ると判断されるまで、先頭ブロックからの探索を開始す
る。ステップＳＰ１１において、ブロック先頭のブロッ
クＩＤ ＢＬＫＩＤがＢＬＫＩＤ−ＨＤ０と判断された
場合には、ステップＳＰ１４において、そのブロック
は、図１８の0x0000〜0x03FFF に示すＡＴＲＡＣ３デー
タファイルの先頭部分の属性ヘッダ（図８参照）と判断
される。
【０１３６】次に、ステップＳＰ１５において、属性ヘ
ッダ内に記録されているファイル番号ＦＮＯ、同一ＡＴ
ＲＡＣ３データファイル内での通し番号を表すＢＬＯＣ
ＫＳＥＲＩＡＬ、コンテンツ累積番号キーＣＯＮＮＵＭ
０を参照して、メモリに記憶する。ここで、１０個のＡ
ＴＲＡＣ３データファイルが存在する（すなわち、１０
曲収録されている）場合には、先頭のブロックＩＤ Ｂ
ＬＫＩＤがＢＬＫＩＤ−ＴＬ０と判断されるブロックが
１０個存在するので、１０個索出されるまで上記処理を
続ける。
【０１３７】ステップＳＰ１３において、ブロックの終
端部まで至っていると判別された場合には、ステップＳ
Ｐ１６において、先頭のブロックにポインタをリセット
して、先頭のブロックから探索をやり直す。
【０１３８】次に、ステップＳＰ１７において、ブロッ
ク先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−Ａ３
Ｄか否かを判断する。このステップＳＰ１７において、
ブロック先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ
−Ａ３Ｄで無い場合には、ステップＳＰ１８において、
ブロック番号をインクリメント処理して、ステップＳＰ
１９において、ブロックの終端部まで検索したか否かを
判別する。ステップＳＰ１９において、ブロックの終端
部まで至ってないと判別された場合には、再度ステップ
ＳＰ１７に制御が戻る。
【０１３９】そして、ステップＳＰ１７において、ブロ
ック先頭のブロックＩＤ ＢＬＫＩＤがＢＬＫＩＤ−Ａ
３Ｄであると判断された場合には、ステップＳＰ２０に
おいて、ブロックはＡＴＲＡＣ３データファイルが実際
に記録されているブロックと判断される。
【０１４０】次に、ステップＳＰ２１において、ＡＴＲ
ＡＣ３データブロック内に記録されている通し番号ＢＬ
ＯＣＫ ＳＥＲＩＡＬ、コンテンツ累積番号キーＣＯＮ
ＮＵＭ０を参照して、メモリに記憶する。このコンテン
ツ累積番号キーＣＯＮＮＵＭ０は同一ＡＴＲＡＣ３デー
タファイル内では共通の番号が付与されている。即ち１
つのＡＴＲＡＣ３データファイルが１０個のブロックか
ら構成されている場合には、上記ブロック内に各々記録
されているＣＯＮＮＵＭ０には全部共通の番号が記録さ
れている。
【０１４１】さらに、１つのＡＴＲＡＣ３データファイ
ルが１０個のブロックから構成されている場合には、１
０個のブロックの各々のＢＬＯＣＫ ＳＥＲＩＡＬには
１〜１０のいずれかの通し番号が付与されている。ＣＯ
ＮＮＵＭ０およびＢＬＯＣＫＳＥＲＩＡＬに基づいて同
一コンテンツを構成するブロックか、さらに同一コンテ
ンツ内の再生順序（連結順序）が判る。
【０１４２】この実施形態では、１０個のＡＴＲＡＣ３
データファイル（即ち１０曲）が記録され、例えば各々
のＡＴＲＡＣ３データファイルが１０個のブロックから
構成される場合には、１００個のデータブロックが存在
することになる。この１００個のデータファイルがどの
曲番を構成し、どの順序で連結されるべきかはＣＯＮＮ
ＵＭ０およびＢＬＯＣＫ ＳＥＲＩＡＬを参照して行わ
れる。
【０１４３】ステップＳＰ１９において、ブロックの終
端部まで至っていると判別された場合には、全ブロック
に対して、再生管理ファイル、ＡＴＲＡＣ３データファ
イル、属性ファイルの全ての検索が終了したことを意味
するので、ステップＳＰ２２は、メモリ上に記憶された
ブロック番号に対応するＣＯＮＮＵＭ０、ＢＬＯＣＫＳ
ＥＲＩＡＬ、ＦＮＯ、ＴＲＫ−ＸＸＸに基づいてファイ
ルの連結状態を再現する。連結状態が確認できたらメモ
リ上の破壊されていない空きエリアにＦＡＴを作成し直
しても良い。
【０１４４】次に、上述した管理ファイルと異なるデー
タ構成の管理ファイル他の例について、説明する。図２
５は、メモリカード４０のファイル構成の他の例を全体
として示す。音楽用ディレクトリには、トラック情報管
理ファイルＴＲＫＬＩＳＴ．ＭＳＦ（以下、単にＴＲＫ
ＬＩＳＴと表記する）と、トラック情報管理ファイルの
バックアップＴＲＫＬＩＳＴＢ．ＭＳＦ（以下、単にＴ
ＲＫＬＩＳＴＢと表記する）と、アーチスト名、ＩＳＲ
Ｃコード、タイムスタンプ、静止画像データ等の各種付
加情報データを記述するＩＮＦＬＩＳＴ．ＭＳＦ（以
下、単にＩＮＦＩＳＴと表記する）と、ＡＴＲＡＣ３デ
ータファイルＡ３Ｄｎｎｎｎ．ＭＳＡ（以下、単にＡ３
Ｄｎｎｎｎと表記する）とが含まれる。ＴＲＫＬＩＳＴ
には、ＮＡＭＥ１およびＮＡＭＥ２が含まれる。ＮＡＭ
Ｅ１は、メモリカード名、曲名ブロック（１バイトコー
ド用）で、ＡＳＣＩＩ／８８５９−１の文字コードによ
り曲名データを記述する領域である。ＮＡＭＥ２は、メ
モリカード名、曲名ブロック（２バイトコード用）で、
ＭＳ−ＪＩＳ／ハングル語／中国語等により曲名データ
を記述する領域である。
【０１４５】図２６は、音楽用ディレクトリのトラック
情報管理ファイルＴＲＫＬＩＳＴと、ＮＡＭＥ１および
２と、ＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎ間の
関係を示す。ＴＲＫＬＩＳＴは、全体で６４Ｋバイト
（＝１６Ｋ×４）の固定長で、その内の３２Ｋバイトが
トラックを管理するパラメータを記述するのに使用さ
れ、残りの３２ＫバイトがＮＡＭＥ１および２を記述す
るのに使用される。曲名等を記述したファイルＮＡＭＥ
１および２は、トラック情報管理ファイルと別扱いでも
実現できるが、ＲＡＭ容量の小さいシステムは、トラッ
ク情報管理ファイルと曲名ファイルとを分けない方が管
理ファイルをまとめて管理することができ、操作しやす
くなる。
【０１４６】トラック情報管理ファイルＴＲＫＬＩＳＴ
内のトラック情報領域ＴＲＫＩＮＦ−ｎｎｎｎおよびパ
ーツ情報領域ＰＲＴＩＮＦ−ｎｎｎｎによって、データ
ファイルＡ３Ｄｎｎｎｎおよび付加情報用のＩＮＦＬＩ
ＳＴが管理される。なお、暗号化の処理を受けるのは、
ＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎのみであ
る。図２６中で、横方向が１６バイト（０〜Ｆ）であ
り、縦方向に１６進数（０ｘか１６進数を意味する）で
その行の先頭の値が示されている。
【０１４７】他の例では、トラック情報管理ファイルＴ
ＲＫＬＩＳＴ（曲名ファイルを含む）と、付加情報管理
ファイルＩＮＦＬＩＳＴと、データファイルＡ３Ｄｎｎ
ｎｎとの３個のファイルの構成とされ、ＴＲＫＬＩＳＴ
によってＩＮＦＬＩＳＴおよびＡ３Ｄｎｎｎｎが管理さ
れる。前述したデータ構成の一例（図７、図８および図
９）では、メモリカードの全体を管理する再生管理ファ
イルＰＢＬＩＳＴと、各トラック（曲）のデータファイ
ルＡＴＲＡＣ３との２種類のファイルの構成とされる。
【０１４８】以下、データ構成の他の例について説明す
るが、上述したデータ構成の一例と同一の点について
は、その説明を省略することにする。
【０１４９】図２７は、トラック情報管理ファイルＴＲ
ＫＬＩＳＴのより詳細な構成を示す。トラック情報管理
ファイルＴＲＫＬＩＳＴは、１クラスタ（１ブロック）
＝１６ＫＢのサイズで、その後に続くバックアップ用の
ＴＲＫＬＩＳＴＢも同一サイズ、同一データのものであ
る。トラック情報管理ファイルは、先頭から３２バイト
がヘッダである。ヘッダには、上述した再生管理ファイ
ルＰＢＬＩＳＴ中のヘッダと同様に、ＢＬＫＩＤ−ＴＬ
０／ＴＬ１（バックアップファイルのＩＤ）（４バイ
ト）、総トラック数Ｔ−ＴＲＫ（２バイト）、メーカー
コードＭＣｏｄｅ（２バイト）、ＴＲＫＬＩＳＴの書き
換え回数ＲＥＶＩＳＩＯＮ（４バイト）、更新日時のデ
ータＳ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ）が
書かれる。これらのデータの意味、機能、値は、前述し
た通りである。これらのデータ以外に下記のデータが書
かれる。
【０１５０】ＹＭＤｈｍｓ（４バイト） 最後にＴＲＫＬＩＳＴが更新された年月日 Ｎ１（１バイト）（Ｏｐｔｉｏｎ） メモリカードの連番号（分子側）で、１枚使用時はすべ
て（０ｘ０１） Ｎ２（１バイト）（Ｏｐｔｉｏｎ） メモリカードの連番号（分母側）で、１枚使用時はすべ
て（０ｘ０１） ＭＳＩＤ（２バイト）（Ｏｐｔｉｏｎ） メモリカードのＩＤで、複数組の時は、ＭＳＩＤが同一
番号（Ｔ．Ｂ．Ｄ．）（Ｔ．Ｂ．Ｄ．は、将来定義され
うることを意味する） Ｓ−ＴＲＫ（２バイト） 特別トラック（４０１〜４０８）の記述（Ｔ．Ｂ．
Ｄ．）で、通常は、０ｘ００００ ＰＡＳＳ（２バイト）（Ｏｐｔｉｏｎ） パスワード（Ｔ．Ｂ．Ｄ．） ＡＰＰ（２バイト）（Ｏｐｔｉｏｎ） 再生アプリケーションの規定（Ｔ．Ｂ．Ｄ．）（通常
は、０ｘ００００） ＩＮＦ−Ｓ（２バイト）（Ｏｐｔｉｏｎ） メモリカード全体の付加情報ポインタであり、付加情報
がないときは、０ｘ００とする。
【０１５１】ＴＲＫＬＩＳＴの最後の１６バイトとし
て、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、Ｍ
Ｃｏｄｅと、ＲＥＶＩＳＩＯＮとが配される。また、バ
ックアップ用のＴＲＫＬＩＳＴＢにも上述したヘッダが
書かれる。この場合、ＢＬＫＩＤ−ＴＬ１と、ＭＣｏｄ
ｅと、ＲＥＶＩＳＩＯＮとが配される。
【０１５２】ヘッダの後にトラック（曲）ごとの情報を
記述するトラック情報領域ＴＲＫＩＮＦと、トラック
（曲）内のパーツの情報を記述するパーツ情報領域ＰＲ
ＴＩＮＦが配置される。図２７では、ＴＲＫＬＩＳＴの
部分に、これらの領域が全体的に示され、下側のＴＲＫ
ＬＩＳＴＢの部分にこれらの領域の詳細な構成が示され
ている。また、斜線で示す領域は、未使用の領域を表
す。
【０１５３】トラック情報領域ＴＲＫＩＮＦ−ｎｎｎお
よびパーツ情報領域ＰＲＴＩＮＦ−ｎｎｎに、上述した
ＡＴＲＡＣ３データファイルに含まれるデータが同様に
書かれる。すなわち、再生制限フラグＬＴ（１バイ
ト）、コンテンツキーＣＯＮＴＥＮＴＳ ＫＥＹ（８バ
イト）、記録機器のセキュリティブロックのシリアル番
号ＭＧ（Ｄ）ＳＥＲＩＡＬ（１６バイト）、曲の特徴的
部分を示すためのＸＴ（２バイト）（Ｏｐｔｉｏｎ）お
よびＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）、再生制限情
報およびコピー制御に関連するデータＹＭＤｈｍｓ−Ｓ
（４バイト）（Ｏｐｔｉｏｎ）、ＹＭＤｈｍｓ−Ｅ（４
バイト）（Ｏｐｔｉｏｎ）、ＭＴ（１バイト）（Ｏｐｔ
ｉｏｎ）、ＣＴ（１バイト）（Ｏｐｔｉｏｎ）、ＣＣ
（１バイト）、ＣＮ（１バイト）（Ｏｐｔｉｏｎ）、パ
ーツの属性を示すＡ（１バイト）、パーツサイズＰＲＴ
ＳＩＺＥ（４バイト）、パーツキーＰＲＴＫＥＹ（８バ
イト）、コンテンツ累積番号ＣＯＮＮＵＭ（４バイト）
が書かれている。これらのデータの意味、機能、値は、
前述した通りである。これらのデータ以外に下記のデー
タが書かれる。
【０１５４】Ｔ０（１バイト） 固定値（Ｔ０＝０ｘ７４） ＩＮＦ−ｎｎｎ（Ｏｐｔｉｏｎ）（２バイト） 各トラックの付加情報ポインタ（０〜４０９）、００：
付加情報がない曲の意味 ＦＮＭ−ｎｎｎ（４バイト） ＡＴＲＡＣ３データのファイル番号（０ｘ００００〜０
ｘＦＦＦＦ） ＡＴＲＡＣ３データファイル名（Ａ３Ｄｎｎｎｎｎ）の
ｎｎｎｎｎ （ＡＳＣＩＩ）番号を０ｘｎｎｎｎｎに変
換した値 ＡＰＰ ＣＴＬ（４バイト）（Ｏｐｔｉｏｎ） アプリケーション用パラメータ（Ｔ．Ｂ．Ｄ．）（通
常、０ｘ００００） Ｐ−ｎｎｎ（２バイト） 曲を構成するパーツ数（１〜２０３９）で、前述のＴ−
ＰＡＲＴに対応する ＰＲ（１バイト） 固定値（ＰＲ＝０ｘ５０）。
【０１５５】次に、名前をまとめて管理する名前の領域
ＮＡＭＥ１およびＮＡＭＥ２について説明する。図２８
は、ＮＡＭＥ１（１バイトコードを使用する領域）のよ
り詳細なデータ構成を示す。ＮＡＭＥ１および後述のＮ
ＡＭＥ２は、ファイルの先頭から８バイト単位で区切ら
れ、１スロット＝８バイトとされている。先頭の０ｘ８
０００には、ヘッダが書かれ、その後ろにポインタおよ
び名前が記述される。ＮＡＭＥ１の最後のスロットにヘ
ッダと同一データが記述される。
【０１５６】ＢＬＫＩＤ−ＮＭ１（４バイト） ブロックの内容を特定する固定値（ＮＭ１＝０ｘ４Ｅ４
Ｄ２Ｄ３１） ＰＮＭ１−ｎｎｎ（４バイト）（Ｏｐｔｉｏｎ） ＮＭ１（１バイトコード）へのポインタ ＰＮＭ１−Ｓは、メモリカードを代表する名前のポイン
タ ｎｎｎ（＝１〜４０８）は、曲名のポインタ ポインタは、ブロック内の開始位置（２バイト）と文字
コードタイプ（２ビット）とデータサイズ（１４ビッ
ト）を記述 ＮＭ１−ｎｎｎ（Ｏｐｔｉｏｎ） １バイトコードで、メモリカード名、曲名データを可変
長で記述 名前データの終端コード（０ｘ００）を書き込む。
【０１５７】図２９は、ＮＡＭＥ２（２バイトコードを
使用する領域）のより詳細なデータ構成を示す。先頭
（０ｘ８０００）には、ヘッダが書かれ、ヘッダの後ろ
にポインタおよび名前が記述される。ＮＡＭＥ２の最後
のスロットにヘッダと同一データが記述される。
【０１５８】ＢＬＫＩＤ−ＮＭ２（４バイト） ブロックの内容を特定する固定値（ＮＭ２＝０ｘ４Ｅ４
Ｄ２Ｄ３２） ＰＮＭ２−ｎｎｎ（４バイト）（Ｏｐｔｉｏｎ） ＮＭ２（２バイトコード）へのポインタ ＰＮＭ２−Ｓは、メモリカードを代表する名前のポイン
タ ｎｎｎ（＝１〜４０８）は、曲名のポインタ ポインタは、ブロック内の開始位置（２バイト）と文字
コードタイプ（２ビット）とデータサイズ（１４ビッ
ト）を記述 ＮＭ２−ｎｎｎ（Ｏｐｔｉｏｎ） ２バイトコードで、メモリカード名、曲名データを可変
長で記述 名前データの終端コード（０ｘ００００）を書き込む。
【０１５９】図３０は、１ＳＵがＮバイトの場合のＡＴ
ＲＡＣ３データファイルＡ３Ｄｎｎｎｎのデータ配列
（１ブロック分）を示す。このファイルは、１スロット
＝８バイトである。図３０では、各スロットの先頭（０
ｘ００００〜０ｘ３ＦＦ８）の値が示されている。ファ
イルの先頭から４個のスロットがヘッダである。前述し
たデータ構成の一例におけるデータファイル（図１７参
照）の属性ヘッダに続くデータブロックと同様に、ヘッ
ダが設けられる。すなわち、このヘッダには、ＢＬＫＩ
Ｄ−Ａ３Ｄ（４バイト）、メーカーコードＭＣｏｄｅ
（２バイト）、暗号化に必要なＢＬＯＣＫ ＳＥＥＤ
（８バイト）、最初に作られたコンテンツ累積番号ＣＯ
ＮＮＵＭ０（４バイト）、トラック毎の連続番号ＢＬＯ
ＣＫ ＳＥＲＩＡＬ（４バイト）、暗号化／復号化に必
要なＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８
バイト）が書かれる。なお、ブロックの最後の一つ前の
スロットに、ＢＬＯＣＫ ＳＥＥＤが二重記録され、最
後のスロットにＢＬＫＩＤ−Ａ３ＤおよびＭＣｏｄｅが
記録される。そして、前述したデータ構成の一例と同様
に、ヘッダの後にサウンドユニットデータＳＵ−ｎｎｎ
ｎが順に配される。
【０１６０】図３１は、付加情報を記述するための付加
情報管理ファイルＩＮＦＬＩＳＴのより詳細なデータ構
成を示す。他のデータ構成においては、このファイルＩ
ＮＦＬＩＳＴの先頭（０ｘ００００）には、下記のヘッ
ダが記述される。ヘッダ以降にポインタおよびデータが
記述される。
【０１６１】ＢＬＫＩＤ−ＩＮＦ（４バイト） ブロックの内容を特定する固定値（ＩＮＦ＝０ｘ４９４
Ｅ４６４Ｆ） Ｔ−ＤＡＴ（２バイト） 総データ数を記述（０〜４０９） ＭＣｏｄｅ（２バイト） 記録した機器のメーカーコード ＹＭＤｈｍｓ（４バイト） 記録更新日時 ＩＮＦ−ｎｎｎ（４バイト） 付加情報のＤＡＴＡ（可変長、２バイト（スロット）単
位）へのポインタ 開始位置は、上位１６ビットで示す（００００〜ＦＦＦ
Ｆ） ＤａｔａＳｌｏｔ−００００の（０ｘ０８００）先頭か
らのオフセット値（スロット単位）を示す データサイズは、下位１６ビットで示す（０００１〜７
ＦＦＦ）（最上位ビットＭＳＢに無効フラグをセットす
る。ＭＳＢ＝０（有効を示す）、ＭＳＢ＝１（無効を示
す） データサイズは、その曲のもつ総データ数を表す（デー
タは、各スロットの先頭から始まり、データの終了後
は、スロットの終わりまで００を書き込むこと） 最初のＩＮＦは、アルバム全体の持つ付加情報を示すポ
インタ（通常ＩＮＦ−４０９で示される）。
【０１６２】図３２は、付加情報データの構成を示す。
一つの付加情報データの先頭に８バイトのヘッダが付加
される。この付加情報の構成は、上述したデータ構成の
一例における付加情報の構成（図１２Ｃ参照）と同様の
ものである。すなわち、ＩＤとしてのＩＮ（１バイ
ト）、キーコードＩＤ（１バイト）、個々の付加情報の
大きさを示すＳＩＺＥ（２バイト）、メーカーコードＭ
Ｃｏｄｅ（２バイト）が書かれる。さらに、ＳＩＤ（１
バイト）は、サブＩＤである。
【０１６３】上述したこの発明の一実施形態では、メモ
リカードのフォーマットとして規定されているファイル
システムとは別に音楽用データに対するトラック情報管
理ファイルＴＲＫＬＩＳＴを使用するので、ＦＡＴが何
らかの事故で壊れても、ファイルを修復することが可能
となる。図３３は、ファイル修復処理の流れを示す。フ
ァイル修復のためには、ファイル修復プログラムで動作
し、メモリカードをアクセスできるコンピュータ（ＤＳ
Ｐ３０と同様の機能を有するもの）と、コンピュータに
接続された記憶装置（ハードディスク、ＲＡＭ等）とが
使用される。最初のステップ１０１では、次の処理がな
される。なお、図２５〜図３２を参照して説明したトラ
ック管理ファイルＴＲＫＬＩＳＴに基づいてファイルを
修復する処理を説明する。
【０１６４】ＦＡＴが壊れたフラッシュメモリの全ブロ
ックを探索し、ブロックの先頭の値（ＢＬＫＩＤ）がＴ
Ｌ−０を探す。このフラッシュメモリの全ブロックを探
索し、ブロックの先頭の値（ＢＬＫＩＤ）がＴＬ−１を
探す。このフラッシュメモリの全ブロックを探索し、ブ
ロックの先頭の値（ＢＬＫＩＤ）がＮＭ−１を探す。こ
のフラッシュメモリの全ブロックを探索し、ブロックの
先頭の値（ＢＬＫＩＤ）がＮＭ−２を探す。この４ブロ
ック（トラック情報管理ファイル）の全内容は、修復用
コンピュータによって例えばハードディスクに収集す
る。
【０１６５】トラック情報管理ファイルの先頭から４バ
イト目以降のデータから総トラック数ｍの値を見つけ把
握しておく。トラック情報領域ＴＲＫＩＮＦ−００１の
先頭から２０バイト目、１曲目のＣＯＮＮＵＭ−００１
とそれに続くＰ−００１の値を見つける。Ｐ−００１の
内容から構成されるパーツの総数を把握し、続くＰＲＴ
ＩＮＦの中のトラック１を構成する全てのＰＲＴＳＩＺ
Ｅの値を見つけ出し、それらを合計した総ブロック（ク
ラスタ）数ｎを計算し、把握しておく。
【０１６６】トラック情報管理ファイルは見つかったの
で、ステップ１０２では、音のデータファイル（ＡＴＲ
ＡＣ３データファイル）を探索する。フラッシュメモリ
の管理ファイル以外の全ブロックを探索し、ＡＴＲＡＣ
３データファイルであるブロックの先頭の値（ＢＬＫＩ
Ｄ）がＡ３Ｄのブロック群の収集を開始する。
【０１６７】Ａ３Ｄｎｎｎｎの中で先頭から１６バイト
目に位置するＣＯＮＮＵＭ０の値がトラック情報管理フ
ァイルの１曲目のＣＯＮＮＵＭ−００１と同一で、２０
バイト目からのＢＬＯＣＫ ＳＥＲＩＡＬの値が０のも
のを探し出す。これが見つかったら、次のブロック（ク
ラスタ）として同一のＣＯＮＮＵＭ０の値で、２０バイ
ト目からのＢＬＯＣＫ ＳＥＲＩＡＬの値が＋１された
もの（１＝０＋１）を探し出す。これが見つかったら、
同様に、次のブロック（クラスタ）として同一のＣＯＮ
ＮＵＭ０の値で、２０バイト目からのＢＬＯＣＫ ＳＥ
ＲＩＡＬの値が＋１されたもの（２＝１＋１）を探し出
す。
【０１６８】この処理を繰り返して、トラック１の総ク
ラスタであるｎ個になるまでＡＴＲＡＣ３データファイ
ルを探す。全てが見つかったら、探したブロック（クラ
スタ）の内容を全てハードディスクに順番に保存する。
【０１６９】次のトラック２に関して、上述したトラッ
ク１に関する処理を行う。すなわち、ＣＯＮＮＵＭ０の
値がトラック情報管理ファイルの１曲目のＣＯＮＮＵＭ
−００２と同一で、２０バイト目からのＢＬＯＣＫ Ｓ
ＥＲＩＡＬの値が０のものを探し出し、以下、トラック
１の場合と同様に、最後のブロック（クラスタ）ｎ’ま
でＡＴＲＡＣ３データファイルを探し出す。全てが見つ
かったら、探したブロック（クラスタ）の内容を全て外
部のハードディスクに順番に保存する。
【０１７０】全トラック（トラック数ｍ）について、以
上の処理を繰り返すことによって、全てのＡＴＲＡＣ３
データファイルが修復用コンピュータが管理する外部の
ハードディスクに収集される。
【０１７１】そして、ステップ１０３では、ＦＡＴが壊
れたメモリカードを再度初期化し、ＦＡＴを再構築し、
所定のディレクトリを作り、トラック情報管理ファイル
と、ｍトラック分のＡＴＲＡＣ３データファイルをハー
ドディスク側からメモリカードへコピーする。これによ
って、修復作業が完了する。
【０１７２】なお、管理ファイル、データファイルにお
いて、重要なパラメータ（主としてヘッダ内のコード）
を二重に限らず、三重以上記録しても良く、重要なパラ
メータに対して専用のエラー訂正符号の符号化を行うよ
うにしても良い。また、このように多重記録する場合の
位置は、ファイルの先頭および末尾の位置に限らず、１
ページ単位以上離れた位置であれば有効である。
【０１７３】以上の一実施形態および他の実施形態は、
システムオーディオセットのプレーヤ／レコーダとして
メモリカードレコーダを使用する例について説明した。
この発明は、例えばＣＤプレーヤの再生ディジタル信号
をハードディスクに保存し、ハードディスクをオーディ
オサーバとして使用し、ハードディスクから上述したフ
ォーマットのメモリカード４０にムーブし、上述したよ
うなディジタルオーディオプレーヤ／レコーダ、または
携帯型プレーヤ／レコーダによって聞くことを可能とす
るものである。以下、図７〜図２３に示すこの発明の一
実施形態と図２５〜図３２に示したこの発明の他の実施
形態とに基づいて、ハードディスクとメモリカードへコ
ンテンツとの間のムーブに関連する部分をより詳細に説
明する。
【０１７４】図３４は、ハードディスクドライブを有す
る蓄積装置例えばパソコンを示す。以下の説明では、蓄
積装置を単にホストまたはホスト側と称する。２０１が
ハードディスクドライブを示し、ハードディスクドライ
ブ２０１がＣＰＵ２０２の制御によって動作される。ま
た、ＣＰＵ２０２と関連して、外部不揮発性メモリ（外
部ＮＶＲＡＭ）２０３、操作ボタン２０４および表示デ
バイス２０５が設けられている。
【０１７５】また、ＡＴＲＡＣ３のオーディオエンコー
ダ／デコーダ２０６が設けられ、アナログ入力２０７が
Ａ／Ｄ変換器２０８でディジタルオーディオ信号へ変換
され、オーディオエンコーダ／デコーダ２０６によりＡ
ＴＲＡＣ３方式により圧縮される。また、ＣＤプレーヤ
２０９からのディジタル入力２１０がディジタル入力レ
シーバ２１１を介してオーディオエンコーダ／デコーダ
２０６に供給され、ＡＴＲＡＣ３方式により圧縮され
る。さらに、ホスト側は、ハードディスクドライブ２０
１に格納されているオーディオデータを復号化し、オー
ディオエンコーダ／デコーダ２０６でディジタルオーデ
ィオ信号へ復号化し、Ｄ／Ａ変換器２１３によって、ア
ナログオーディオ出力２１４を得ることが可能とされて
いる。更に図示しないが、インターネット等に公衆回線
で接続して圧縮／非圧縮のディジタルオーディオデータ
をハードディスクＨＤＤ２０１にダウンロードするよう
にしても良い。
【０１７６】オーディオエンコーダ／デコーダ２０６か
らの圧縮オーディオデータがホスト側のセキュリティブ
ロックＳ−ＳＡＭ（Ｄ）２１２に供給され、暗号化され
る。暗号化は、上述したオーディオレコーダにおけるの
と同様にコンテンツキーを使用してなされるものであ
る。暗号化されたＡＴＲＡＣ３のデータがＣＰＵ２０２
の制御の下で、ハードディスクドライブ２０１に格納さ
れる。また、ディジタル入力の場合、ＩＳＲＣ（Indust
ry Standard Recording Code）、ＴＯＣ(Table Of Cont
ent) ＩＤ等のディスクに予め記録されている曲を特定
する情報も得ることができる。セキュリティブロックＳ
−ＳＡＭ（Ｄ）２１２では、コンテンツ毎（この一実施
形態では、オーディオファイル（トラック）毎）にコン
テンツキー、コンテンツ累積番号ＣＯＮＮＵＭを発生
し、また、各ホスト毎に固有のシリアル番号を有する。
これらの値も、ハードディスクドライブ２０１および／
または外部不揮発性メモリ２０３に保存される。
【０１７７】ハードディスクドライブ２０１に保存され
た暗号化されたＡＴＲＡＣ３のデータファイルを暗号化
した装置（ホスト）以外の機器で再生するために、上述
したメモリカード４０にムーブする。ムーブしたデータ
ファイルは、ハードディスクドライブ２０１に残らず、
その点でコピーとムーブは異なる処理である。
【０１７８】また、ＡＴＲＡＣ３のデータがコンテンツ
キーによって暗号化されているので、若し、データがコ
ピーされてもコピー先で復号化できなければ、再生する
ことができない。しかしながら、暗号の鍵であるコンテ
ンツキーを盗まれると、暗号化が無意味となってしま
う。そこで、コンテンツキー自体を更に暗号化して、コ
ンテンツキー自身の値を外部に漏らすことはない。例え
ばハードディスクドライブ２０１からメモリカード４０
に対してムーブする時には、セッションキーによってコ
ンテンツキーを暗号化し、ハードディスクドライブ２０
１からメモリカード４０へ暗号化されたコンテンツキー
が伝送される。メモリカード４０では、セッションキー
によりコンテンツキーを復号し、次にメモリカード４０
のストレージキーでコンテンツを暗号化し、暗号化され
たコンテンツキーがメモリカード４０に保存される。
【０１７９】メモリカード４０からハードディスクドラ
イブ２０１へデータをムーブする時も同様に、メモリカ
ード４０とハードディスクドライブ２０１間では、コン
テンツキーがセッションキーで暗号化されて伝送され
る。ハードディスクドライブ２０１に記録されるコンテ
ンツキーと、メモリカード４０に記録されるコンテンツ
キーの値は異なる。このように、常にオーディオデータ
とコンテンツキーが移動先でペアで存在する必要があ
る。
【０１８０】ムーブを行う時の処理について、図３５を
参照してさらに詳細に説明する。最初に、図１に示すオ
ーディオプレーヤ／レコーダについて説明したようなフ
ォーマットでもってメモリカード４０に記録されている
データをホスト側のハードディスクドライブ２０１にム
ーブする時の処理について説明する。電源オン等の初期
状態において、メモリカード４０が装着されているかど
うかが決定され、メモリカード４０が装着されている時
には、ホスト側とメモリカード４０間で認証がなされ
る。認証が成立すると、ホスト側とメモリカード側がセ
ッションキーＳｅｋを共有する。
【０１８１】次に、ホストがメモリカード４０を読み出
し、この発明の一実施形態では再生管理ファイルＰＢＬ
ＩＳＴ中に含まれるコンテンツキーＣＫを、この発明の
他の実施形態においてはトラック情報領域ＴＲＫＩＮＦ
からメモリカード４０のそれぞれに固有のストレージキ
ーＫｓｔｍで暗号化されたコンテンツキーＣＫ（ＤＥＳ
（Data Encription Standard）（Ｋｓｔｍ，ＣＫ）と表
記する。）を抽出する。そして、このＤＥＳ（Ｋｓｔ
ｍ，ＣＫ）をホストからメモリカード４０へ伝送する。
メモリカード４０がストレージキーＫｓｔｍで復号化す
る。復号化したコンテンツキーをセッションキーＳｅｋ
で暗号化する。
【０１８２】メモリカード４０からセッションキーＳｅ
ｋで暗号化されたコンテンツキーＤＥＳ（Ｓｅｋ，Ｃ
Ｋ）をホスト側が受け取る。ホスト側では、セッション
キーＳｅｋでコンテンツキーＣＫを復号化し、ホストに
固有のストレージキーＫｓｔｄで再暗号化し、ハードデ
ィスクドライブ２０１内に保存する。つまり、キーは、
新たなコンテンツキーとなって保存される。ストレージ
キーＫｓｔｄおよびＫｓｔｍは、外部からその値自身を
読みだすことができないように保存される。
【０１８３】図３５において、ホスト側のセキュリティ
ブロック２１２ａがメモリカード４０のセキュリティブ
ロックと認証を行い、セッションキーＳｅｋを共有する
ことが示されている。また、セキュリティブロック２１
２ａからのストレージキーＫｓｔｄと、コンテンツキー
ＣＫとが暗号器２１２ｂに供給され、暗号化されたコン
テンツキーＤＥＳ（Ｋｓｔｄ，ＣＫ）が生成される。
【０１８４】２１５の経路で示すように、メモリカード
４０から、既に暗号化されているＡＴＲＡＣ３データが
そのままホスト側へムーブされ、ハードディスクドライ
ブ２０１に保存される。この場合、図２７を参照して説
明したように、メモリカード４０上に記録されているト
ラック管理情報ＴＲＫＩＮＦもデータファイルと共に、
ホスト側へ伝送される。特に、トラック情報領域ＴＲＫ
ＩＮＦ−ｎｎｎｎに元から存在する曲毎のコンテンツ累
積番号（ＣＯＮＮＵＭ）、Ｓ−ＳＡＭシリアル番号およ
びファイル番号ＦＮＭ−ｎｎｎｎをそのままコピーし
て、ホスト側のトラック情報領域ＴＲＫＩＮＦとして記
録される。これらの属性情報は、コンテンツキーと異な
り、暗号化されない。
【０１８５】若し、これらの情報をホスト側に移動しな
いと、ハードディスクドライブ２０１にオーディオデー
タを保存することができても、ホスト自身が保存したオ
ーディオデータの復号化を行うことができず、再び保存
したオーディオデータをメモリカードにムーブしないか
ぎり、そのオーディオデータを再生することができな
い。
【０１８６】ここで、コンテンツ累積番号ＣＯＮＮＵＭ
は、メモリカード４０およびホスト側のそれぞれのセキ
ュリティブロックの暗号器を通して曲を記録したときの
１曲毎の累積の番号である。２32＝４２億曲分用意され
ており、常に最後の番号を暗号器が不揮発性メモリの中
に覚えているので、一つのメモリカード内では重複する
ことがない。Ｓ−ＳＡＭシリアル番号（ＳＥＲＩＡＬ）
は、暗号器に付けられた固有の番号で、２128 個の番号
が用意され、重複することがない。ファイル番号ＦＮＭ
−ｎｎｎｎは、ＡＴＲＡＣ３のデータファイルに付けら
れた番号であって、ハードウエアにより自由にその値を
決められるので、重複がありうる。そのため、コンテン
ツ累積番号ＣＯＮＮＵＭおよびＳ−ＳＡＭシリアル番号
（ＳＥＲＩＡＬ）が補助として追加され、合計３個の番
号でもって、データファイル（トラック、曲）を記録し
た時に、そのファイルを特定することができる。
【０１８７】以上のように、認証および暗号化のため
に、ホスト側のセキュリティブロック２１２が生成また
は有するものは、 自分の固有の番号（Ｓ−ＳＡＭシリアル番号） コンテンツキーＣＫ（コンテンツ毎に作成される） ストレージキーＫｓｔｄ セッションキーＳｅｋ である。この発明の一実施形態において、上述のＳ−Ｓ
ＡＭシリアル番号、コンテンツキーＣＫ、コンテンツ累
積番号ＣＯＮＮＯＭ、ファイル番号ＦＮＭ−ｎｎｎを図
１７のＡ３Ｄｎｎｎｎ．ＭＳＡ（ＡＴＲＡＣデータファ
イル）のＭＧ（Ｄ）Ｓｅｒｉａｌ−ｎｎｎ，ＣＯＮＴＥ
ＮＴＳＫＥＹ，ＣＯＮＮＵＭ，およびＢｌｏｃｋＳｅｒ
ｉａｌに各々対応つけて記録される。
【０１８８】更にこの発明の他の実施形態において、ホ
スト側のハードディスクドライブ２０１および／または
外部不揮発性メモリ２０３において、暗号化されたオー
ディオデータファイルとそれぞれ対応するトラック情報
領域ＴＲＫＩＮＦには、 ファイル番号ＦＮＭ−ｎｎｎｎ 暗号化されたコンテンツキーＣＫ Ｓ−ＳＡＭシリアル番号 コンテンツ累積番号ＣＯＮＮＵＭ が記録される。
【０１８９】さらに、ハードディスクドライブ２０１に
対して例えばＣＤプレーヤ２０９からのディジタル入力
を直接的に記録する場合には、オーディオエンコーダ／
デコーダ２０６によりＡＴＲＡＣ３でオーディオデータ
を圧縮する。そして、ホスト側のセキュリティブロック
２１２で、コンテンツ（曲）毎にコンテンツキーＣＫを
作り、自分のストレージキーＫｓｔｄでコンテンツキー
を暗号化する。この暗号化したコンテンツキーＤＥＳ
（Ｋｓｔｄ，ＣＫ）に基づいてＡＴＲＡＣ３データに暗
号器２１２ｃによって暗号化をかけて、暗号化したオー
ディオデータ２１６をハードディスクドライブ２０１に
保存する。この時に、曲毎にコンテンツ累積番号ＣＯＮ
ＮＵＭ、Ｓ−ＳＡＭ（Ｄ）シリアル番号もホスト側のセ
キュリティブロック２１２ａで発生し、この発明の一実
施形態においては図１７のＡ３Ｄｎｎｎｎ．ＭＳＡ（Ａ
ＴＲＡＣデータファイル）としてハードディスクドライ
ブ２０１に記録され、この発明の他の実施形態において
は、トラック情報領域ＴＲＫＩＮＦとしてハードディス
クドライブ２０１に保存する。但し、これらの属性情報
は、コンテンツキーと異なり、ストレージキーＫｓｔｄ
によって暗号化されない。
【０１９０】また、ホスト自身、ハードディスクドライ
ブ２０１に蓄積されているコンテンツを復号化して再生
することができる。ホストにおける記録または再生のた
めに、操作ボタン２０４が操作され、表示デバイス２０
５の表示が使用される。
【０１９１】さらに、ホスト側では、ＣＤプレーヤ２０
９からのディジタル入力をハードディスクドライブ２０
１にコピーした場合には、ディジタルレシーバ２１１に
おいて、ＴＯＣ ＩＤまたは各曲のＩＳＲＣのようなＣ
Ｄプレーヤ２０９が再生したＣＤ上の曲を特定する情報
を得ることができる。ＣＤプレーヤ２０９からのディジ
タル入力をコピーする際には、１枚のＣＤ毎にディレク
トリ名を設定する。
【０１９２】上述した処理と逆に、ホスト側からメモリ
カード４０へデータをムーブすることもできる。最初に
認証動作がなされ、認証成立によってセッションキーＳ
ｅｋが共有される。ホストは、ハードディスクドライブ
２０１からＤＥＳ（Ｋｓｔｄ，ＣＫ）を読み出し、スト
レージキーＫｓｔｄで復号化する。復号化したコンテン
ツキーをセッションキーＳｅｋで暗号化し、暗号化され
たコンテンツキーＤＥＳ（Ｓｅｋ，ＣＫ）をメモリカー
ド４０へ送信する。
【０１９３】メモリカード４０側では、セッションキー
ＳｅｋでコンテンツキーＣＫが復号化される。そして、
メモリカードに固有のストレージキーＫｓｔｍによっ
て、コンテンツキーＣＫを再暗号化する。暗号化された
コンテンツキーＤＥＳ（Ｋｓｔｍ，ＣＫ）をこの発明の
一実施形態においては再生管理ファイルＰＢＬＩＳＴお
よびＡＴＲＡＣデータファイルに，この発明の他の実施
形態においてはトラック情報領域ＴＲＫＩＮＦに保存す
る。コンテンツキー以外の情報（コンテンツ累積番号Ｃ
ＯＮＮＵＭ、Ｓ−ＳＡＭ（）シリアル番号等）は、再暗
号化されず、そのまま記録される。
【０１９４】この発明の一実施形態において、図３６を
参照して、１枚のＣＤ全体をホスト側のハードディスク
ドライブ２０１にコピーする処理の流れを以下に説明す
る。
【０１９５】最初にハードディスクドライブ２０１の空
領域にＣＤ−ｎｎｎのディレクトリを作成する。ｎは、
１から始まり最大９９９であり、ハードディスクドライ
ブの容量にも依存するが、９９９枚のＣＤがコピー可能
である。入力ソースとしては、ＣＤ以外にＭＳ（メモリ
カード）、ＢＳ（放送衛星を使用したディジタル放送の
チューナ）、ＣＳ（通信衛星を使用したディジタル放送
のチューナ）、ＤＡＴ（テープを使用したディジタルオ
ーディオレコーダ）、ＭＤ（ミニディスク）、ＴＶチュ
ーナ、ＦＭチューナ、ＡＭチューナ、インターネット等
があり、それぞれのディレクトリも同様に存在する。何
れも、ＭＳ−ｎｎｎ，ＢＳ−ｎｎｎ，ＣＳ−ｎｎｎ等と
表現する。その下にトラック情報管理ファイルＴＲＫＬ
ＩＳＴ．ＭＳＦが作られる。すなわち、ホストにおいて
は、図７、図２５に示したメモリカードと同様のファイ
ル構成をとる。ＣＤ−ｎｎｎのディレクトリと、メモリ
カードのディレクトリとの相違点は、この発明の一実施
形態ではＣＤの場合に、附加情報データＩＮＦ−Ｓに図
１４および図１５に示すように、ＴＯＣ ＩＤや、ＵＰ
Ｃ／ＪＡＮ、ＩＳＲＣが追加される程度である。この発
明の他の実施形態の場合には、ＴＲＫＬＩＳＴのヘッダ
部分に上述のＴＯＣ ＩＤや、ＵＰＣ／ＪＡＮが追加さ
れ、トラック情報領域ＴＲＫＩＮＦにＩＳＲＣが追加さ
れる。
【０１９６】また、ムーブの履歴を管理するために、外
部不揮発性メモリ２０３上にホスト側からムーブしたコ
ンテンツのデータが管理される。このトラック移動履歴
管理ファイルには、ムーブされた日時、ムーブされたコ
ンテンツのディレクトリ名、ＴＯＣ ＩＤ、米／日にお
けるバーコードの規格であるＵＰＣ／ＪＡＮ（Universa
l Product Code）、トラック番号の第１分類と、コンテ
ンツキー、コンテンツ累積番号ＣＯＮＮＵＭ、Ｓ−ＳＡ
Ｍシリアル番号の第２分類とが記録される。ムーブされ
たコンテンツ（曲）は、例えば表示デハイス２０５のリ
スト表示において、通常より薄く表示され、既にハード
ディスクドライブ２０１内に無いことが利用者が分かる
ようにされる。
【０１９７】一方、メモリカード４０からホストへのム
ーブの要求が発生した場合、要求されているムーブが新
規のムーブであるか、以前ムーブしたコンテンツの戻り
であるかを判断する必要がある。このため、先ず、メモ
リカード４０の，この発明の一実施形態におけるＡＴＲ
ＡＣデータファイルまたはこの発明の他の実施形態にお
けるトラック情報領域ＴＲＫＩＮＦに含まれる上記の第
２分類に相当する３つの情報が移動履歴管理ファイル上
の中にあるかどうかを検索する。
【０１９８】この検索の結果、該当するものがなけれ
ば、新規のムーブ（録音）と決定して、新たなディレク
トリＭＳ−ｎｎｎが作成される。そして、上述したよう
に、キーの掛け替えを行った後に、全てのデータをムー
ブする。
【０１９９】検索の結果、該当するものがあれば、コン
テンツの戻りと決定する。トラック移動履歴管理ファイ
ル中の上記第１分類のディレクトリ名に元の状態でデー
タをムーブさせる。充分なセキュリティが確保されてお
り、ホスト側にデータファイルを残せる場合には、メモ
リカード側のデータファイルのみを消去し、ホスト側
は、復帰のフラグを立てるのみで良い。データファイル
の移動を省略できる分、処理を高速とできる。
【０２００】図３６は、ＣＤからのオーディオデータを
ホストのハードディスクドライブ２０１にコピーする時
の処理の一例を概略的に示す。図３６Ａに示すように、
２０１ａで示すハードディスクドライブに、ＣＤ１に記
録されている全ての曲（例えば１４曲）と、ＣＤ２に記
録されている全ての曲（例えば１０曲）とがコピーされ
る。ＣＤ１およびＣＤ２毎にディレクトリ名が設定さ
れ、ディレクトリがそれぞれ作成される。ハードディス
クドライブ２０１上のトラック管理ファイル２０１Ｆに
は、各ＣＤの曲の情報が記録される。
【０２０１】次に、図３６Ｂに示すように、メモリカー
ド４０ａに対して、ハードディスクドライブ２０１ａ中
の全２４曲の内の７曲がムーブされる。この７曲がＣＤ
１中の番号１，２および１２の曲と、ＣＤ２中の番号
２，３，８および９の曲であると、外部不揮発性メモリ
２０３上のトラック移動履歴管理ファイル２０３Ｆに、
これらのムーブした曲の情報が履歴として記録される。
７曲のムーブによって、ハードディスクドライブに残っ
ている曲は、１７曲となる。
【０２０２】その後、図３６Ｃに示すように、メモリカ
ード４０ａからハードディスクドライブに対して７曲の
ムーブが行われる。この場合には、トラック移動履歴管
理ファイル２０３Ｆと、ＨＤＤトラック管理ファイル２
０１Ｆとの両方を参照して、戻りであるとホスト側が決
定する。戻りであると決定すると、ホスト側は、ハード
ディスクドライブ２０１ａにおいて元々その７曲が存在
していた所と同一の所に７曲をムーブさせる。その結
果、ハードディスクドライブ２０１ａに２４曲が再び蓄
積されることになる。しかも、その２４曲は、元のハー
ドディスクドライブ２０１ａ上で蓄積されているのと同
じファイル管理の下で管理される。従って、ＣＤに記録
されていた時の順序と曲の順序が異なることが防止でき
る。
【０２０３】現在ＳＤＭＩ（Secured Digital Music In
stitute）で定められている規格では、１枚のディスク
から４台までの複製を許可している。例えば、ＣＤプレ
ーヤを所定のインターフェースでハードディスクを搭載
したパーソナルコンピュータに接続し、ＣＤプレーヤに
搭載されたＣＤディスクから再生されたコンテンツをパ
ーソナルコンピュータ内のハードディスクに複写を行
う。上述のパーソナルコンピュータのハードディスクに
複写されたコンテンツは上記ＳＤＭＩの規格では３台ま
での携帯端末若しくは３枚までのメモリに移動されるの
で、結果的に合計４台までの複製を許可していることに
なる。
【０２０４】更に、上述した３台までの携帯端末若しく
は３枚までのメモリに記憶されたコンテンツは、上述の
パーソナルコンピュータのハードディスクに戻すことが
可能である。上述の携帯端末若しくはメモリからハード
ディスクにコンテンツを戻すことを“ｃｈｅｃｋ ｉ
ｎ”と称して，上述のハードディスクから上述の携帯端
末若しくはメモリにコンテンツを移動することを“ｃｈ
ｅｃｋ ｏｕｔ”と称する。“ｃｈｅｃｋ ｉｎ”、
“ｃｈｅｃｋ ｏｕｔ”処理時に同様にトラック移動履
歴管理ファイルおよび管理ファイルを各々作成してファ
イルの管理を行っても良い。
【０２０５】更に、上述の実施例では、ハードディスク
内の移動履歴管理ファイル内の移動履歴管理ファイル内
に記憶されている第２分類であるコンテンツキー、コン
テンツ累積番号ＣＯＮＮＵＭ，Ｓ−ＳＡＭシリアル番号
の３つの情報と上述のメモリ内の第１の実施例のＡＴＲ
ＡＣデータファイルまたは第２の実施例のトラック情報
領域ＴＲＫＩＮＦに含まれるコンテンツキー、コンテン
ツ累積番号ＣＯＮＮＵＭ，Ｓ−ＳＡＭシリアル番号の３
つの情報との照合に基づいて、ムーブ時のコピー元への
帰還か否かを判別したが、上記３つの情報の全てを用い
なくてもいいことはいうまでもない。
【０２０６】更に、上述３つの情報に追加して上述した
第１分類であるＩＳＲＣ（Industrial Standard Cod
e），ＵＰＣ／ＪＡＮ，ＴＯＣ−ＩＤ等に関しても照合
をとって判別を厳しくすることで著作権管理を厳しくし
ても良い。
【０２０７】なお、上述した説明においては、蓄積装置
としてのハードディスクドライブとメモリカードの間の
データの通信について説明したが、ハードディスクドラ
イブを含むホスト例えばパソコンが電子的コンテンツ配
信システムの端末とのインタフェースを行うように構成
されていても良い。この場合、上述したハードディスク
とメモリカードとの間のムーブに関連する処理と同様の
処理が端末とパソコンとの間でなされる。
【０２０８】また、上述した説明においては、オーディ
オデータがコンテンツの場合に説明したが、オーディオ
以外の映像データ、プログラムデータ等に対してこの発
明を適用しても良い。また、ハードディスク以外の蓄積
媒体（光磁気ディスク、相変化型ディスク、半導体メモ
リ）を使用する場合に対してもこの発明を適用すること
ができる。
【０２０９】
【発明の効果】この発明によれば、蓄積装置から以前に
記憶媒体例えばメモリカードにムーブしたコンテンツを
戻す時に、以前の記憶されていた場所と同じ場所に元の
順序で戻すことができる。従って、ソース例えばＣＤの
アルバムをコピーしたデータを蓄積していた時に、メモ
リカードへ一部をムーブし、再びムーブした曲を戻した
後でも、蓄積装置上において曲の順序が元のものから変
化することを防止することができる。
【図面の簡単な説明】
【図１】この発明の不揮発性メモリカードを使用したデ
ジタルオーディオレコーダ／プレーヤーに関するブロッ
ク図である。
【図２】この発明に適応されるＤＳＰの内部ブロック図
を示す。
【図３】この発明に適応されるメモリカードの内部ブロ
ック図を示す。
【図４】この発明に適応されるメモリカードを記憶媒体
とするファイル管理構造を示す模式図である。
【図５】この発明に適応されるメモリカード内のフラッ
シュメモリのデータの物理的構造を示す。
【図６】この発明に適応されるメモリカード内のデータ
構造を示す、
【図７】メモリカード内に記憶されるファイル構造を示
す枝図面である。
【図８】メモリカード内に記憶されるサブディレクトリ
である再生管理ファイルＰＢＬＩＳＴ. ＭＳＦのデータ
構造を示す。
【図９】連続した１つのＡＴＲＡＣ３データファイルを
所定単位長ごとに分割するとともに属性ファイルを付加
した場合のデータ構造図である。
【図１０】この発明のコンバイン編集処理および分割編
集処理を説明するための構造図である。
【図１１】再生管理ファイルＰＢＬＩＳＴのデータ構造
図を示す。
【図１２】再生管理ファイルＰＢＬＩＳＴのデータ構造
図を示す。
【図１３】上記付加情報データの種類の対応表を示す。
【図１４】上記付加情報データの種類の対応表を示す。
【図１５】上記付加情報データの種類の対応表を示す。
【図１６】付加情報データのデータ構造を示す。
【図１７】ＡＴＲＡＣ３データファイルの詳細なデータ
構造図である。
【図１８】ＡＴＲＡＣ３データファイルを構成する属性
ヘッダーの上段のデータ構造図である。
【図１９】ＡＴＲＡＣ３データファイルを構成する属性
ヘッダーの中段のデータ構造図である。
【図２０】録音モードの種類と各録音モードにおける録
音時間等を示す表である。
【図２１】コピー制御状態を示す表である。
【図２２】ＡＴＲＡＣ３データファイルを構成する属性
ヘッダーの下段のデータ構造図である。
【図２３】ＡＴＲＡＣ３データファイルのデータブロッ
クのヘッダーのデータ構造図である。
【図２４】この発明におけるＦＡＴ領域が破壊された場
合の回復方法を示すフローチャートである。
【図２５】メモリカード４０内に記憶されるファイル構
造を示す、この発明の他の実施形態における枝図面であ
る。
【図２６】トラック情報管理ファイルＴＲＫＬＩＳＴ．
ＭＳＦとＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎ
ｎ．ＭＳＡとの関係を示す図である。
【図２７】トラック情報管理ファイルＴＲＫＬＩＳＴ．
ＭＳＦの詳細なデータ構造を示す。
【図２８】名前を管理するＮＡＭＥ１の詳細なデータ構
造である。
【図２９】名前を管理するＮＡＭＥ２の詳細なデータ構
造である。
【図３０】ＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎ
ｎ．ＭＳＡの詳細なデータ構造を示す。
【図３１】付加情報を示すＩＮＦＬＩＳＴ. ＭＳＦの詳
細なデータ構造を示す。
【図３２】付加情報データを示すＩＮＦＬＩＳＴ. ＭＳ
Ｆの詳細なデータ構造を示す。
【図３３】この発明の他の実施形態におけるＦＡＴ領域
が破壊された場合の回復方法を示す遷移図である。
【図３４】この発明のムーブ処理を説明するための略線
図である。
【図３５】ムーブ処理時の鍵の掛け直しを説明するため
のブロック図である。
【図３６】ＣＤ、不揮発性メモリ、ハードディスクの間
でのデータの受け渡しについて説明するための略線図で
ある。
【符号の説明】
１０・・・オーディオエンコーダ／デコーダＩＣ、２０
・・・セキュリティＩＣ、３０・・・ＤＳＰ、４０・・
・メモリカード、４２・・・フラッシュメモリ、５２・
・・セキュリティブロック、ＰＢＬＩＳＴ・・・再生管
理ファイル、ＴＲＫＬＩＳＴ・・・トラック情報管理フ
ァイル、ＩＮＦＬＩＳＴ・・・付加情報管理ファイル、
Ａ３Ｄｎｎｎ・・・オーディオデータファイル

Claims (13)

    【特許請求の範囲】
  1. 【請求項１】 情報源と、上記情報源に接続され、上記
    情報源から供給されるコンテンツを記憶する大容量メモ
    リに記憶されたコンテンツを移動して記憶可能なクライ
    アントからなるデータコミュニケーションシステムにお
    いて、 クライアントは、上記サーバから移動されたコンテンツ
    と、移動履歴を管理する移動履歴管理データとを記憶す
    る記憶手段と、上記記憶手段に記憶されたコンテンツを
    上記サーバ内の大容量メモリに戻すときに上記移動履歴
    管理データを送信する送信手段とを備え、 サーバは、 上記情報源からコンテンツを上記大容量メモリに記憶す
    る際に上記コンテンツ毎に管理する管理データを生成す
    る生成手段と、 上記生成手段にて生成した管理データを、コンテンツと
    共に大容量メモリに記憶する制御手段と、 上記クライアント側の送信手段から送信される移動履歴
    管理データを受信する受信手段と、 上記サーバの上記大容量メモリに記憶されたコンテンツ
    を上記クライアント内の記憶手段に記憶されたコンテン
    ツを上記サーバ内の大容量メモリに戻す際に上記受信手
    段にて受信した移動履歴管理データに基づいて上記管理
    データを編集する編集手段とを備えることを特徴とする
    データコミュニケーションシステム。
  2. 【請求項２】 請求項１において、 上記受信手段にて受信した移動管理データと、上記大容
    量メモリに記憶している管理データとに基づいて、上記
    クライアントから戻されたコンテンツが元々上記大容量
    メモリに記憶されていたコンテンツであるか否かを判別
    する判別手段を、更に上記サーバ内に備えたことを特徴
    とするデータコミュニケーションシステム。
  3. 【請求項３】 請求項２において、 上記判別手段にて、上記クライアントから戻されたコン
    テンツが元々上記大容量メモリに記憶されていたコンテ
    ンツであると判定された場合には、コンテンツの順序を
    元通りになるように上記管理データを上記編集手段にて
    編集することを特徴とするデータコミュニケーションシ
    ステム。
  4. 【請求項４】 請求項１において、 上記サーバと上記クライアントとの間で送受信されるコ
    ンテンツに対して暗号化が施されて送信されることを特
    徴とするデータコミュニケーションシステム。
  5. 【請求項５】 請求項１において、 上記サーバ内の上記大容量メモリから３台までのクライ
    アントにコンテンツ移可能とすることを特徴とするデー
    タコミュニケーションシステム。
  6. 【請求項６】 請求項１において、 上記クライアント内の上記記憶手段は、着脱可能な不揮
    発性メモリであることを特徴とするデータコミュニケー
    ションシステム。
  7. 【請求項７】 請求項１において、 上記判別手段は、上記移動管理データに含まれるデータ
    コンテンツに対する暗号化を施すコンテンツキーと、上
    記管理データに含まれるコンテンツに対する暗号化を施
    すコンテンツキーとを照合することで上記クライアント
    から戻されたコンテンツが元々上記大容量メモリに記憶
    されていたコンテンツであるか否かを判定することを特
    徴とするデータコミュニケーションシステム。
  8. 【請求項８】 請求項１において、 上記判別手段は、上記移動管理データに含まれるコンテ
    ンツ累積番号と、上記管理データに含まれるコンテンツ
    累積番号とを照合することで上記クライアントから戻さ
    れたコンテンツが元々上記大容量メモリに記憶されてい
    たコンテンツであるか否かを判定することを特徴とする
    データコミュニケーションシステム。
  9. 【請求項９】 請求項１において、 上記判別手段は、上記移動管理データに含まれる記録機
    器固有の識別子と上記管理データに含まれる記録機器毎
    固有の識別子とを照合することで上記クライアントから
    戻されたコンテンツが元々上記大容量メモリに記憶され
    ていたコンテンツであるか否かを判定することを特徴と
    するデータコミュニケーションシステム。
  10. 【請求項１０】 複数のコンテンツと、上記複数のコン
    テンツを管理する管理データを記憶した大容量メモリ備
    えたサーバと、上記サーバに接続され、上記大容量メモ
    リから所定のコンテンツを移動可能な端末からなるデー
    タコミュニケーションシステムにおけるデータ管理方法
    において、 上記サーバから所定のコンテンツを移動する際に移動管
    理データを生成するステップと、 上記端末から、上記サーバに再度コンテンツを戻す際に
    上記サーバに上記生成した移動履歴管理データを送信す
    るステップと、 上記端末から上記サーバに再度コンテンツを戻す際に上
    記大容量メモリに蓄積された管理データと上記端末から
    送信された移動履歴管理データとを参照するステップ
    と、 上記参照結果に基づいて、上記端末から戻されたコンテ
    ンツが元々上記大容量メモリに記憶されていたコンテン
    ツであるか否かを判別するステップとを有することを特
    徴とするデータ管理方法。
  11. 【請求項１１】 請求項１０において、 上記判別ステップにて、上記端末から戻されたコンテン
    ツが元々上記大容量メモリに記憶されていたコンテンツ
    と判別された場合には、コンテンツの順序を元通りにな
    るように上記管理データを編集することを特徴とするデ
    ータ管理方法。
  12. 【請求項１２】 請求項１０において、 上記サーバと、上記端末との間で送受信されるコンテン
    ツに対して暗号化が施されてなることを特徴とするデー
    タ管理方法。
  13. 【請求項１３】 請求項１０において、 上記サーバ内の大容量メモリから、３台までの端末にコ
    ンテンツ移動が可能とされることを特徴とするデータ管
    理方法。
JP2000038815A 1999-03-03 2000-02-16 データコミュニケーションシステム、データ管理方法 Expired - Lifetime JP4214651B2 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2000038815A JP4214651B2 (ja) 1999-03-31 2000-02-16 データコミュニケーションシステム、データ管理方法
EP00301764A EP1033665A3 (en) 1999-03-03 2000-03-03 Data communication system and data managing method
TW089105274A TW522386B (en) 1999-03-31 2000-03-22 Data communication system and data managing method
MYPI20001164A MY125136A (en) 1999-03-31 2000-03-23 System for distributing music data files between a server and a client and retuning the music data files back to the previous locations
SG200001739A SG103814A1 (en) 1999-03-31 2000-03-24 Data communication system and data managing method
US09/538,169 US6691149B1 (en) 1999-03-31 2000-03-30 System for distributing music data files between a server and a client and returning the music data files back to the previous locations
CNB001186450A CN1229742C (zh) 1999-03-31 2000-03-31 数据通信系统和数据管理的方法
KR1020000016833A KR100714665B1 (ko) 1999-03-31 2000-03-31 데이터 통신 시스템 및 데이터 관리 방법

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP9363299 1999-03-31
JP18871099 1999-07-02
JP11-188710 1999-07-02
JP11-93632 1999-07-02
JP2000038815A JP4214651B2 (ja) 1999-03-31 2000-02-16 データコミュニケーションシステム、データ管理方法

Publications (2)

Publication Number Publication Date
JP2001076464A true JP2001076464A (ja) 2001-03-23
JP4214651B2 JP4214651B2 (ja) 2009-01-28

Family

ID=27307342

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000038815A Expired - Lifetime JP4214651B2 (ja) 1999-03-03 2000-02-16 データコミュニケーションシステム、データ管理方法

Country Status (7)

Country Link
US (1) US6691149B1 (ja)
JP (1) JP4214651B2 (ja)
KR (1) KR100714665B1 (ja)
CN (1) CN1229742C (ja)
MY (1) MY125136A (ja)
SG (1) SG103814A1 (ja)
TW (1) TW522386B (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003016725A (ja) * 2001-06-27 2003-01-17 Sony Corp コンテンツデータの送信装置および送信方法、並びにコンテンツデータの処理装置および処理方法
JP2003022080A (ja) * 2001-07-06 2003-01-24 Sony Corp 記録装置および方法、記録媒体、並びにプログラム
WO2003019561A1 (fr) * 2001-08-31 2003-03-06 Sony Corporation Appareil et procede de traitement d'informations
US7130251B1 (en) 1999-09-21 2006-10-31 Sony Corporation Communication system and its method and communication apparatus and its method
US7573785B2 (en) 2002-04-15 2009-08-11 Sony Corporation Method and apparatus for recording audio tracks into large storage device
US7797456B2 (en) 1999-12-17 2010-09-14 Sony Corporation Information processing apparatus and associated method of transferring grouped content

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1085420A4 (en) * 1999-03-03 2006-12-27 Sony Corp DATA PROCESSING DEVICE, METHOD, DEVICE AND TRANSMISSION METHOD
JP2001036423A (ja) * 1999-05-20 2001-02-09 Yamaha Corp 番組再生システム及び番組再生方法
CA2338634C (en) * 1999-05-28 2007-06-26 Matsushita Electric Industrial Co., Ltd. A semiconductor memory card, playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium
US6975995B2 (en) * 1999-12-20 2005-12-13 Hanseulsoft Co., Ltd. Network based music playing/song accompanying service system and method
US7444353B1 (en) 2000-01-31 2008-10-28 Chen Alexander C Apparatus for delivering music and information
JP4568963B2 (ja) 2000-06-08 2010-10-27 ソニー株式会社 情報処理装置、情報通信システム
US7178169B1 (en) * 2000-09-01 2007-02-13 Zoran Corporation Method and apparatus for securing transfer of and access to digital content
JP4378590B2 (ja) * 2000-10-12 2009-12-09 ソニー株式会社 情報処理装置および情報処理方法、並びにプログラム格納媒体
JP2002132556A (ja) * 2000-10-30 2002-05-10 Minolta Co Ltd ファイル管理装置、ファイル管理方法およびファイル管理プログラムを記録したコンピュータ読取可能な記録媒体
EP1205838A3 (en) * 2000-11-07 2007-10-10 Matsushita Electric Industrial Co., Ltd. Carryable memory media, portable information terminal using the same and method for managing files therein
US9520993B2 (en) * 2001-01-26 2016-12-13 International Business Machines Corporation Renewable traitor tracing
US7039803B2 (en) * 2001-01-26 2006-05-02 International Business Machines Corporation Method for broadcast encryption and key revocation of stateless receivers
JP4465577B2 (ja) * 2001-04-19 2010-05-19 ソニー株式会社 情報処理装置および方法、情報処理システム、記録媒体、並びにプログラム
JP2003022232A (ja) * 2001-07-06 2003-01-24 Fujitsu Ltd コンテンツデータ転送システム
DE60215016T2 (de) * 2001-07-19 2007-05-03 Koninklijke Philips Electronics N.V. Vorrichtung und Verfahren zur Wiedergabe von Benutzerdaten
EP1292084A3 (de) * 2001-09-07 2005-10-26 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten in einem paketorientierten Datennetz
US7899778B1 (en) * 2001-10-30 2011-03-01 Palm Inc. Category based user interface for management of auxiliary storage on a portable computer system
JP2004014084A (ja) * 2002-06-11 2004-01-15 Pioneer Electronic Corp 情報再生記録システム、情報再生記録方法、情報再生記録処理プログラム
US7516491B1 (en) * 2002-10-17 2009-04-07 Roger Schlafly License tracking system
US7835520B2 (en) * 2003-02-20 2010-11-16 Zoran Corporation Unique identifier per chip for digital audio/video data encryption/decryption in personal video recorders
WO2004097635A2 (en) 2003-04-25 2004-11-11 Apple Computer, Inc. Graphical user interface for browsing, searching and presenting media items
US9406068B2 (en) 2003-04-25 2016-08-02 Apple Inc. Method and system for submitting media for network-based purchase and distribution
US7426637B2 (en) * 2003-05-21 2008-09-16 Music Public Broadcasting, Inc. Method and system for controlled media sharing in a network
JP2004355444A (ja) * 2003-05-30 2004-12-16 Pioneer Electronic Corp データ転送再生装置
US7593922B1 (en) * 2003-06-13 2009-09-22 At&T Intellectual Property, I. L.P. Method and system for providing delivery of segmented data files
TW200502758A (en) * 2003-07-07 2005-01-16 Yuen Foong Paper Co Ltd Portable secure information accessing system and method thereof
TWI235303B (en) * 2003-07-22 2005-07-01 Yuen Foong Paper Co Ltd Digital content management system, method and application method thereof
US7321770B2 (en) * 2003-08-29 2008-01-22 Casio Computer Co., Ltd. Communication terminal apparatus and program for processing communication information
US7844548B2 (en) * 2003-10-15 2010-11-30 Apple Inc. Techniques and systems for electronic submission of media for network-based distribution
CN1316821C (zh) * 2003-10-20 2007-05-16 松下电器产业株式会社 信息传送装置及信息转送方法和视频服务器系统
US8346157B1 (en) 2004-06-16 2013-01-01 Colby Steven M Content customization in asymmertic communication systems
JP4537893B2 (ja) * 2004-06-23 2010-09-08 株式会社リコー 情報処理装置、移動履歴管理方法
WO2006077822A1 (ja) * 2005-01-24 2006-07-27 Matsushita Electric Industrial Co., Ltd. 署名生成装置及び署名検証装置
US8635526B2 (en) 2006-05-25 2014-01-21 Qualcomm Incorporated Target advertisement in a broadcast system
US8515336B2 (en) 2006-01-06 2013-08-20 Qualcomm Incorporated Apparatus and methods of selective collection and selective presentation of content
US7962634B2 (en) 2006-05-15 2011-06-14 Apple Inc. Submission of metadata content and media content to a media distribution system
US8015237B2 (en) 2006-05-15 2011-09-06 Apple Inc. Processing of metadata content and media content received by a media distribution system
US7827162B2 (en) * 2006-05-15 2010-11-02 Apple Inc. Media package format for submission to a media distribution system
US7865212B2 (en) * 2007-01-17 2011-01-04 Research In Motion Limited Methods and apparatus for use in transferring user data between two different mobile communication devices using a removable memory card
US20080239888A1 (en) * 2007-03-26 2008-10-02 Yamaha Corporation Music Data Providing System
US7756920B2 (en) * 2007-11-28 2010-07-13 Apple Inc. Resubmission of media for network-based distribution
US10255580B2 (en) 2008-05-05 2019-04-09 Apple Inc. Network-based distribution of application products
US9342287B2 (en) 2008-05-05 2016-05-17 Apple Inc. Software program ratings
US9076176B2 (en) 2008-05-05 2015-07-07 Apple Inc. Electronic submission of application programs for network-based distribution
US20090307683A1 (en) * 2008-06-08 2009-12-10 Sam Gharabally Network-Based Update of Application Programs
US20100235889A1 (en) * 2009-03-16 2010-09-16 Michael Kuohao Chu Application products with in-application subsequent feature access using network-based distribution system
US20100299219A1 (en) * 2009-05-25 2010-11-25 Cortes Ricardo D Configuration and Management of Add-ons to Digital Application Programs for Network-Based Distribution
US20110004750A1 (en) * 2009-07-03 2011-01-06 Barracuda Networks, Inc Hierarchical skipping method for optimizing data transfer through retrieval and identification of non-redundant components
US8280895B2 (en) * 2009-07-03 2012-10-02 Barracuda Networks Inc Multi-streamed method for optimizing data transfer through parallelized interlacing of data based upon sorted characteristics to minimize latencies inherent in the system
US9729609B2 (en) * 2009-08-07 2017-08-08 Apple Inc. Automatic transport discovery for media submission
US8935217B2 (en) * 2009-09-08 2015-01-13 Apple Inc. Digital asset validation prior to submission for network-based distribution
US9069771B2 (en) * 2009-12-08 2015-06-30 Xerox Corporation Music recognition method and system based on socialized music server
US9203624B2 (en) 2012-06-04 2015-12-01 Apple Inc. Authentication and notification heuristics
US8990188B2 (en) 2012-11-30 2015-03-24 Apple Inc. Managed assessment of submitted digital content
US9087341B2 (en) 2013-01-11 2015-07-21 Apple Inc. Migration of feedback data to equivalent digital assets

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481701A (en) * 1991-09-13 1996-01-02 Salient Software, Inc. Method and apparatus for performing direct read of compressed data file
JPH05167646A (ja) * 1991-12-12 1993-07-02 Nec Corp ファイル転送を行う企業間通信業務の自動化方式
US5666544A (en) * 1993-05-10 1997-09-09 Mita Industrial Co., Ltd. Method and system for communicating data between independent controllers
US5666293A (en) * 1994-05-27 1997-09-09 Bell Atlantic Network Services, Inc. Downloading operating system software through a broadcast channel
JPH0863382A (ja) * 1994-08-19 1996-03-08 Fujitsu Ltd 分散システムにおけるデータ整合性確認方法及びデータ整合性確認装置
JPH0869404A (ja) * 1994-08-29 1996-03-12 Fujitsu Ltd データのバックアップ方法及びそれを利用したデータ処理装置
US5623699A (en) * 1994-12-06 1997-04-22 Thunderwave, Inc. Read only linear stream based cache system
JP3447432B2 (ja) * 1995-06-07 2003-09-16 三菱電機株式会社 ネットワークデータサーバ装置およびプログラマブルロジックコントローラシステム
JPH103745A (ja) * 1996-06-12 1998-01-06 Sony Corp 記録媒体、デジタルコピー管理方法、再生装置、及び記録装置
US5857201A (en) * 1996-06-18 1999-01-05 Wright Strategies, Inc. Enterprise connectivity to handheld devices
JPH1011339A (ja) * 1996-06-20 1998-01-16 Hitachi Ltd マルチメディアデータベース管理システム
US6061451A (en) * 1996-09-03 2000-05-09 Digital Vision Laboratories Corporation Apparatus and method for receiving and decrypting encrypted data and protecting decrypted data from illegal use
US5926624A (en) * 1996-09-12 1999-07-20 Audible, Inc. Digital information library and delivery system with logic for generating files targeted to the playback device
JPH10124352A (ja) * 1996-10-24 1998-05-15 Matsushita Electric Ind Co Ltd ライブラリ内ファイルの管理方法、及びライブラリ用サーバ装置
JPH10340219A (ja) * 1997-06-06 1998-12-22 Nec Corp Ｕｎｉｘサーバー・汎用機間ファイル転送装置
KR100224962B1 (ko) * 1997-06-30 1999-10-15 윤종용 이동 통신 시스템의 시스템 로딩 내역 관리 방법
JP3799757B2 (ja) * 1997-07-18 2006-07-19 富士ゼロックス株式会社 被検証データ生成装置、及び被検証データ生成プログラムを記録したコンピュータ読み取り可能な記録媒体
AUPO899697A0 (en) * 1997-09-05 1997-10-02 Bardell, Norman John Charles Data dissemination system for computer networks
US6745237B1 (en) * 1998-01-15 2004-06-01 Mci Communications Corporation Method and apparatus for managing delivery of multimedia content in a communications system
JP4320817B2 (ja) * 1998-02-09 2009-08-26 ソニー株式会社 記録再生装置、記録再生システム、記録再生方法およびプログラム
JPH11259971A (ja) * 1998-03-10 1999-09-24 Sony Corp ダビングシステム、ダビング方法
US6189008B1 (en) * 1998-04-03 2001-02-13 Intertainer, Inc. Dynamic digital asset management
US6192375B1 (en) * 1998-07-09 2001-02-20 Intel Corporation Method and apparatus for managing files in a storage medium
JP2000113087A (ja) * 1998-09-30 2000-04-21 Casio Comput Co Ltd データベースサーバおよびそのプログラム記録媒体
AU3715700A (en) 1999-03-01 2000-09-21 Quark Media House Sarl Digital media asset management system and process
AU2001271772A1 (en) * 2000-06-30 2002-01-14 Eddie H. Williams Online digital content library

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8291134B2 (en) 1999-09-21 2012-10-16 Sony Corporation Communication system and its method and communication apparatus and its method
US10277675B2 (en) 1999-09-21 2019-04-30 Data Scape, Ltd. Communication system and its method and communication apparatus and its method
US10708354B2 (en) 1999-09-21 2020-07-07 Data Scape Ltd. Communication system and its method and communication apparatus and its method
US7130251B1 (en) 1999-09-21 2006-10-31 Sony Corporation Communication system and its method and communication apparatus and its method
US10645161B2 (en) 1999-09-21 2020-05-05 Data Scape Ltd. Communication system and its method and communication apparatus and its method
US7617537B2 (en) 1999-09-21 2009-11-10 Sony Corporation Communication system and its method and communication apparatus and its method
US7720929B2 (en) 1999-09-21 2010-05-18 Sony Corporation Communication system and its method and communication apparatus and its method
US8554888B2 (en) 1999-09-21 2013-10-08 Sony Corporation Content management system for searching for and transmitting content
US10027751B2 (en) 1999-09-21 2018-07-17 Data Scape, Ltd. Communication system and its method and communication apparatus and its method
US9736238B2 (en) 1999-09-21 2017-08-15 Data Scape, Ltd. Communication system and its method and communication apparatus and its method
US8108572B2 (en) 1999-09-21 2012-01-31 Sony Corporation Communication system and its method and communication apparatus and its method
US8122163B2 (en) 1999-09-21 2012-02-21 Sony Corporation Communication system and its method and communication apparatus and its method
US9712614B2 (en) 1999-09-21 2017-07-18 Data Scape, Ltd. Communication system and its method and communication apparatus and its method
US9160818B2 (en) 1999-09-21 2015-10-13 Sony Corporation Communication system and its method and communication apparatus and its method
US9380112B2 (en) 1999-09-21 2016-06-28 Sony Corporation Communication system and its method and communication apparatus and its method
US7797456B2 (en) 1999-12-17 2010-09-14 Sony Corporation Information processing apparatus and associated method of transferring grouped content
US10176177B2 (en) 1999-12-17 2019-01-08 Sony Corporation Information processing apparatus and associated method of content exchange
US9241022B2 (en) 1999-12-17 2016-01-19 Sony Corporation Information processing apparatus and associated method of content exchange
US8522150B2 (en) 1999-12-17 2013-08-27 Sony Corporation Information processing apparatus and associated method of content exchange
US8463868B2 (en) 1999-12-17 2013-06-11 Sony Corporation Information processing apparatus and associated method of content exchange
JP2003016725A (ja) * 2001-06-27 2003-01-17 Sony Corp コンテンツデータの送信装置および送信方法、並びにコンテンツデータの処理装置および処理方法
JP2003022080A (ja) * 2001-07-06 2003-01-24 Sony Corp 記録装置および方法、記録媒体、並びにプログラム
US8108310B2 (en) 2001-07-06 2012-01-31 Sony Corporation Recording apparatus and method, and communication device and method
WO2003019561A1 (fr) * 2001-08-31 2003-03-06 Sony Corporation Appareil et procede de traitement d'informations
US7903504B2 (en) 2002-04-15 2011-03-08 Sony Corporation Method and apparatus for recording data tracks into large storage device
US7573785B2 (en) 2002-04-15 2009-08-11 Sony Corporation Method and apparatus for recording audio tracks into large storage device

Also Published As

Publication number Publication date
KR100714665B1 (ko) 2007-05-07
JP4214651B2 (ja) 2009-01-28
SG103814A1 (en) 2004-05-26
US6691149B1 (en) 2004-02-10
CN1229742C (zh) 2005-11-30
TW522386B (en) 2003-03-01
CN1274893A (zh) 2000-11-29
KR20000071530A (ko) 2000-11-25
MY125136A (en) 2006-07-31

Similar Documents

Publication Publication Date Title
JP4214651B2 (ja) データコミュニケーションシステム、データ管理方法
JP4543554B2 (ja) データ処理装置およびデータ処理方法
JP4135049B2 (ja) 不揮発性メモリ
JP4281185B2 (ja) 編集装置および方法
JP4779183B2 (ja) 再生装置および再生方法
JP4842417B2 (ja) 記録装置
JPWO2000052581A1 (ja) データ処理装置、データ処理方法、端末装置およびデータ処理装置の伝送方法
JP2001117821A (ja) 記録媒体、編集装置、記録システム
JP2000347696A (ja) 再生装置および再生方法
JP2002175090A (ja) 再生装置および再生方法
JP4524921B2 (ja) 記録装置、記録方法、再生装置および再生方法
JP4406988B2 (ja) 不揮発性記録媒体、記録方法、記録装置
JPWO2000052684A1 (ja) 記録装置、記録方法、再生装置および再生方法
JP4897138B2 (ja) 再生装置および再生方法
US7519277B2 (en) Editing apparatus and editing method
EP1033665A2 (en) Data communication system and data managing method
EP1041574B1 (en) Nonvolatile memory
RU2252448C2 (ru) Устройство и способ редактирования
EP1041575B1 (en) Editing apparatus and editing method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061012

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080708

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080904

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: 20081014

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: 20081027

R151 Written notification of patent or utility model registration

Ref document number: 4214651

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

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

Free format text: PAYMENT UNTIL: 20111114

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20121114

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20131114

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term