JP4172131B2 - データ処理装置、データ処理システムおよびその方法 - Google Patents
データ処理装置、データ処理システムおよびその方法 Download PDFInfo
- Publication number
- JP4172131B2 JP4172131B2 JP2000076391A JP2000076391A JP4172131B2 JP 4172131 B2 JP4172131 B2 JP 4172131B2 JP 2000076391 A JP2000076391 A JP 2000076391A JP 2000076391 A JP2000076391 A JP 2000076391A JP 4172131 B2 JP4172131 B2 JP 4172131B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- block
- processing
- encrypted
- encryption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Storage Device Security (AREA)
Description
【発明の属する技術分野】
この発明は、例えば圧縮などの所定の処理ブロックを単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶手段に記憶するデータ処理装置、データ処理手段およびその方法に関する。
【0002】
【従来の技術】
例えば、著作権侵害となる不正利用を防止するために、オーディオデータなどのデータを所定のデータ長の暗号化ブロックを単位として暗号化して記憶媒体に記憶することがある。この場合に、暗号化しようとするデータは、通常、所定の圧縮処理ブロックを単位として圧縮されていることが多い。
【0003】
【発明が解決しようとする課題】
ところで、上述したように圧縮されたデータを暗号化して記憶媒体に記録する場合に、圧縮ブロックと暗号化ブロックと通常一致しない。そのため、例えば、圧縮ブロックを単位として記憶媒体からデータを読み出すと暗号化ブロックのうちの一部のブロックのデータが読み出されないことがあり、正確な復号を行えなくなる。このような事態を回避するために、圧縮ブロックおよびおよび暗号化ブロックの双方を考慮して読み出しを行うと、処理が煩雑となる問題がある。
【0004】
また、記憶媒体に記録したデータを編集する場合などは、例えば圧縮ブロックを単位としてデータの分割および結合などが行われるが、この場合にも、編集後のデータに暗号化ブロックの一部のデータが含まれなくなる可能性が高く、同様に、正確な復号が行えなくなるという問題がある。また、圧縮されていないデータであっても、例えば音楽用のCD(Compact Disc:登録商標 )フォーマットなどのように、所定のブロックを単位として処理が行われる場合にも上述した場合と同様の問題が生じる。
【0005】
この発明の目的は、上述した従来技術の問題点に鑑みてなされ、例えば圧縮などの所定の処理ブロック単位で処理されたデータを所定の暗号化ブロックを単位として暗号化して記憶媒体に記憶する際に、所定の処理ブロックに基づいた処理と復号処理とを簡単な構成で正確に行うことができるデータ処理装置、データ処理システムおよびその方法を提供することにある。
【0006】
【課題を解決するための手段】
上述した課題を解決するために、請求項1の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、暗号化したデータを記憶する記憶手段と、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出す制御手段とを有し、制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理装置である。
【0007】
請求項11の発明は、所定のデータ長の暗号化ブロックを単位としてデータを暗号化し、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行い、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、処理ブロックを単位としてデータを記憶手段から読み出し、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理方法である。
【0008】
請求項7の発明は、記憶装置とデータ処理装置との間で相互認証を行いながらデータの入出力を行うデータ処理システムにおいて、記憶装置は、データ処理装置との間で相互認証処理を行う第1の相互認証処理手段と、データを記憶する記憶手段と、相互認証処理によってデータ処理装置が正当な相手であると認めたときに、データ処理装置と記憶手段との間でデータの入出力を行わせる第1の制御手段とを有し、データ処理装置は、記憶装置との間で相互認証処理を行う第2の相互認証処理手段と、所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、相互認証処理によって、記憶装置が正当な相手であると認めたときに、書き込み処理および読み出し処理の少なくとも一方を行い、書き込み処理において、一の暗号化ブロックを構成するデータが同じ処理ブロック内に位置するように、暗号化したデータを記憶手段に書き込み、読み出し処理において、処理ブロックを単位としてデータを記憶手段から読み出す第2の制御手段とを有し、第2の制御手段は、単数または複数の処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理システムである。
【0009】
【発明の実施の形態】
以下、この発明の実施形態に係わるオーディオシステムについて説明する。図1は、一実施形態のオーディオシステム1のシステム構成図、図2は図1に示す携帯用記憶装置3および携帯用プレーヤ4の内部構成図である。図1に示すように、オーディオシステム1は、例えば、コンピュータ2、携帯用記憶装置3、携帯用プレーヤ4、CD−ROMドライブ6およびCDプレーヤ7を有する。
【0010】
コンピュータ2
コンピュータ2は、ネットワーク5に接続されており、例えば、EMD(Electronic Music Distribution: 電子音楽配信)などのサービスを提供する図示しないサービスプロバイダのホストコンピュータから、ネットワーク5を介してオーディオデータ(トラックデータ)を受信し、当該受信したオーディオデータを必要に応じて復号して、携帯用プレーヤ4に出力する。また、コンピュータ2は、コンテンツデータを受信するに当たって、必要に応じて、サービスプロバイダのホストコンピュータとの間で認証処理および課金処理などを行う。また、コンピュータ2は、例えば、CD−ROMドライブ6から入力したオーディオデータを携帯用プレーヤ4に出力する。
【0011】
携帯用記憶装置3
携帯用記憶装置3は、携帯用プレーヤ4に対して着脱自在とされ、例えば、メモリスティック(Memory Stick:商標)であり、フラッシュメモリなどの書き換え可能な半導体メモリを内蔵している。本明細書において、メモリカードの用語が使用されることもあるが、メモリカードは、携帯用記憶装置を指すものとして使用している。図2に示すように、携帯用記憶装置3は、例えば、主制御モジュール31、通信インターフェイス32、制御モジュール33、フラッシュメモリ34およびフラッシュメモリ管理モジュール35を有する。
【0012】
〔制御モジュール33〕
図2に示すように、制御モジュール33は、例えば、乱数発生ユニット50、記憶ユニット51、鍵生成/演算ユニット52、相互認証ユニット53、暗号化/復号ユニット54および制御ユニット55を有する。制御モジュール33は、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール33は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット50は、乱数発生指示を受けると、64ビット(8バイト)の乱数を発生する。
【0013】
記憶ユニット51は、例えば、EEPROM(Electrically Erasable Programmable Read Only Memory) などの不揮発性メモリであり、認証処理に必要な鍵データなどの種々のデータを記憶している。図3は、記憶ユニット51に記憶されているデータを説明するための図である。図3に示すように、記憶ユニット51は、認証鍵データIK0 〜IK31、装置識別データIDm および記憶用鍵データSKm を記憶している。
【0014】
認証鍵データIK0 〜IK31は、携帯用記憶装置3が携帯用プレーヤ4との間で相互認証を行う際に用いられる鍵データであり、後述するように相互認証を行う度に認証鍵データIK0 〜IK31のうち一の認証鍵データがランダムに選択される。なお、認証鍵データIK0 〜IK31および記憶用鍵データSKm は、携帯用記憶装置3の外部から読めないようになっている。装置識別データIDm は、携帯用記憶装置3に対してユニークに付けられた識別データであり、後述するように、携帯用記憶装置3が携帯用プレーヤ4との間で相互認証を行う際に読み出されて携帯用プレーヤ4に出力される。記憶用鍵データSKm は、後述するように、コンテンツ鍵データCKを暗号化してフラッシュメモリ34に記憶する際に用いられる。
【0015】
鍵生成/演算ユニット52は、例えば、ISO/IEC9797のMAC(Message Authentication Code) 演算などの種々の演算を行って鍵データを生成する。このとき、MAC演算には、例えば、"Block cipher Algorithm"としてFIPSPUB46−2に規定されるDES(Data Encryption Standard)が用いられる。MAC演算は、任意の長さのデータを固定の長さに圧縮する一方向性ハッシュ関数演算であり、関数値が秘密鍵に依存して定まる。
【0016】
相互認証ユニット53は、携帯用プレーヤ4からオーディオデータを入力してフラッシュメモリ34に書き込む動作を行うのに先立って、携帯用プレーヤ4との間で相互認証処理を行う。また、相互認証ユニット53は、フラッシュメモリ34からオーディオデータを読み出して携帯用プレーヤ4に出力する動作を行うのに先立って、携帯用プレーヤ4との間で相互認証処理を行う。また、相互認証ユニット53は、相互認証処理において、前述したMAC演算を行う。当該相互認証処理では、記憶ユニット51に記憶されているデータが用いられる。
【0017】
暗号化/復号ユニット54は、DES、IDEA、MISTYなどのブロック暗号アルゴリズムでの暗号化を行う。使用するモードは、FIPS PUB81”DES MODES OF OPERATION”に規定されているようなECB(Electronic Code Book)モードおよびCBC(Cipher Block Chaining) モードである。また、暗号化/復号ユニット54は、DES、IDEA、MISTYなどのブロック復号アルゴリズムでの復号を行う。使用するモードは、上記ECBモードおよびCBCモードである。当該ECBモードおよびCBCモードのブロック暗号化/復号では、指定された鍵データを用いて指定されたデータを暗号化/復号する。制御ユニット55は、乱数発生ユニット50、記憶ユニット51、鍵生成/演算ユニット52、相互認証ユニット53および暗号化/復号ユニット54の処理を統括して制御する。
【0018】
〔フラッシュメモリ34〕
フラッシュメモリ34は、例えば、32Mバイトの記憶容量を有する。フラッシュメモリ34には、相互認証ユニット53による相互認証処理によって正当な相手であると認められたときに、携帯用プレーヤ4から入力したオーディオデータが書き込まれる。また、フラッシュメモリ34からは、相互認証ユニット53による相互認証処理によって正当な相手であると認められたときに、オーディオデータが読み出されて携帯用プレーヤ4に出力される。
【0019】
以下、フラッシュメモリ34に記憶されるデータおよびそのフォーマットについて説明する。図4は、フラッシュメモリ34に記憶されるデータを説明するための図である。図4に示すように、フラッシュメモリ34には、例えば、再生管理ファイル100、トラックデータファイル1010 ,1011 ,1012 ,1013 が記憶されている。ここで、再生管理ファイル100はトラックデータファイル1010 〜1013 の再生を管理する管理データを有し、トラックデータファイル1010 〜1013 はそれぞれ対応するトラックデータ(オーディオデータ)を有している。なお、本実施形態では、トラックデータは、例えば、1曲分のオーディオデータを意味する。
【0020】
図5は、再生管理ファイルの構成を示し、図6が一つ(1曲)のトラックデータファイル(以下においてATRAC3データファイルの用語がさすものもトラックデータファイルと同義である)の構成を示す。再生管理ファイルは、16KB固定長のファイルである。ATRAC3データファイルは、曲単位でもって、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダも16KB固定長とされ、再生管理ファイルと類似した構成を有する。
【0021】
再生管理ファイルは、ヘッダ、1バイトコードのメモリカードの名前NM1−S、2バイトコードのメモリカードの名前NM2−S、曲順の再生テーブルTRKTBL、メモリカード全体の付加情報INF−Sとからなる。データファイルの先頭の属性ヘッダは、ヘッダ、1バイトコードの曲名NM1、2バイトコードの曲名NM2、トラックのキー情報等のトラック情報TRKINF、パーツ情報PRTINFと、トラックの付加情報INFとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【0022】
属性ヘッダに対してATRAC3の音楽データが続く。音楽データは、16KBのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。なお、暗号化の処理を受けるのは、ATRAC3データファイル中の音楽データのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【0023】
図7は、再生管理ファイルPBLISTのより詳細なデータ構成を示し、図8A、図8Bは、再生管理ファイルPBLISTを構成するヘッダとそれ以外の部分をそれぞれ示す。再生管理ファイルPBLISTは、1クラスタ(1ブロック=16KB)のサイズである。ヘッダ(図8A)が32バイトである。ヘッダ以外の部分(図8B)がメモリカード全体に対する名前NM1−S(256バイト)、名前NM2−S(512バイト)、CONTENTS KEY、MAC、S−YMDhmsと、再生順番を管理するテーブルTRKTBL(800バイト)と、メモリカード全体に対する付加情報INF−S(14720バイト)であり、最後にヘッダ中の情報の一部が再度記録される。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【0024】
再生管理ファイルは、(0x0000)および(0x0010)で表される先頭から32バイト(図8A)がヘッダである。なお、ファイル中で先頭から16バイト単位で区切られた単位をスロットと称する。ファイルの第1および第2のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。なお、Reservedと表記されているデータは、未定義のデータを表している。通常ヌル(0x00)が書かれるが、何が書かれていてもReservedのデータが無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Optionと書かれた部分も使用しない場合は、全てReservedと同じ扱いとされる。
【0025】
BLKID−TL0(4バイト)
意味:BLOCKID FILE ID
機能:再生管理ファイルの先頭であることを識別するための値
値:固定値=”TL=0”(例えば0x544C2D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
REVISION(4バイト)
意味:PBLISTの書き換え回数
機能:再生管理ファイルを書き換える度にインクリメント
値:0より始まり+1づつ増加する
【0026】
SN1C+L(2バイト)
意味:NM1−S領域に書かれるメモリカードの名前(1バイト)の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:文字コード(C)は上位1バイトで下記のように文字を区別する
00: 文字コードは設定しない。単なる2進数として扱うこと
01: ASCII 02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB2312-80 90:S-JIS(for Voice) 。
【0027】
言語コード(L)は下位1バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとすること。
【0028】
SN2C+L(2バイト)
意味:NM2−S領域に書かれるメモリカードの名前(2バイト)の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:上述したSN1C+Lと同一
SINFSIZE(2バイト)
意味:INF−S領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す
機能:データサイズを16バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値:サイズは0x0001から0x39C(924)
T−TRK(2バイト)
意味:TOTAL TRACK NUMBER
機能:総トラック数
値:1から0x0190(最大400トラック)、データが無い場合はオールゼロとすること
【0029】
上述したヘッダに続く領域に書かれるデータ(図8B)について以下に説明する。
【0030】
NM1−S
意味:メモリカード全体に関する1バイトの名前
機能:1バイトの文字コードで表した可変長の名前データ(最大で256)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録すること
値:各種文字コード
NM2−S
意味:メモリカード全体に関する2バイトの名前
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録すること
値:各種文字コード。
【0031】
CONTENTS KEY
意味:曲ごとに用意された値でMG(M)で保護されてから保存される。ここでは、1曲目に付けられるCONTENTS KEYと同じ値
機能:S−YMDhmsのMACの計算に必要となる鍵となる
値:0から0xFFFFFFFFFFFFFFFFまで
MAC
意味:著作権情報改ざんチェック値
機能:S−YMDhmsの内容とCONTENTS KEYから作成される値
値:0から0xFFFFFFFFFFFFFFFFまで。
【0032】
TRK−nnn
意味:再生するATRAC3データファイルのSQN(シーケンス)番号
機能:TRKINFの中のFNoを記述する
値:1から400(0x190)
トラックが存在しない時はオールゼロとすること
INF−S
意味:メモリカード全体に関する付加情報データ(例えば写真、歌詞、解説等の情報)
機能:ヘッダを伴った可変長の付加情報データ
複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小16バイト以上で4バイトの整数倍の単位で構成される。その詳細については、後述する
値:付加情報データ構成を参照
【0033】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のBLKID−TL0と、MCodeと、REVISIONとが書かれる。
【0034】
民生用オーディオ機器として、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。上述したように、REVISIONをブロックの先頭と末尾に書き込み、この値を書き換える度に+1インクリメントするようにしている。若し、ブロックの途中で異常終了が発生すると、先頭と末尾のREVISIONの値が一致せず、異常終了を検出することができる。REVISIONが2個存在するので、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【0035】
また、1ブロック(16KB)の先頭部分に固定値BLKID−TL0を挿入しているので、FATが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値BLKID−TL0は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルPBLISTの同一のものを二重に記録しても良い。
【0036】
ATRAC3データファイルは、トラック情報管理ファイルと比較して、相当大きなデータ量(例えば数千のブロックが繋がる場合もある)であり、ATRAC3データファイルに関しては、後述するように、ブロック番号BLOCK SERIALが付けられている。但し、ATRAC3データファイルは、通常複数のファイルがメモリカード上に存在するので、CONNUM0でコンテンツの区別を付けた上で、BLOCK SERIALを付けないと、重複が発生し、FATが壊れた場合のファイルの復旧が困難となる。
【0037】
同様に、FATの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード(MCode)がブロックの先頭と末尾に記録されている。
【0038】
図8Cは、付加情報データの構成を示す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【0039】
INF
意味:FIELD ID
機能:付加情報データの先頭を示す固定値
値:0x69
ID
意味:付加情報キーコード
機能:付加情報の分類を示す
値:0から0xFF
SIZE
意味:個別の付加情報の大きさ
機能:データサイズは自由であるが、必ず4バイトの整数倍でなければならない。また、最小16バイト以上のこと。データの終わりより余りがでる場合はヌル(0x00)で埋めておくこと
値:16から14784(0x39C0)
MCode
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
C+L
意味:先頭から12バイト目からのデータ領域に書かれる文字の属性を表す
機能:使用する文字コードと言語コードを各1バイトで表す
値:前述のSN1C+Lと同じ
DATA
意味:個別の付加情報データ
機能:可変長データで表す。実データの先頭は常に12バイト目より始まり、長さ(サイズ)は最小4バイト以上、常に4バイトの整数倍でなければならない。データの最後から余りがある場合はヌル(0x00)で埋めること
値:内容により個別に定義される。
【0040】
以下、トラックデータファイル1010 〜1013 について説明する。図9は、トラックデータファイル1010 の構成を説明するための図である。図9に示すように、トラックデータファイル1010 は、1個のパーツからなり、当該パーツが5個のクラスタCL(0),CL(1),CL(2),CL(3),CL(4)で構成されている。当該パーツは、クラスタCL(0)の先頭から開始し、クラスタCL(4)のサウンドユニットSU(4)で終了している。なお、トラックデータファイル1011 〜1013 は、基本的に、図9に示す構成をしているが、パーツ数、クラスタ数およびクラスタ内に含まれるサウンドユニットSUの数は、図9に示すものには限定されず、独立して決められている。
【0041】
1トラックは、1曲を意味する。1曲は、1つのATRAC3データファイル(図6参照)で構成される。ATRAC3データファイルは、ATRAC3により圧縮されたオーディオデータである。メモリカード40に対しては、クラスタと呼ばれる単位で記録される。1クラスタは、例えば16KBの容量である。1クラスタに複数のファイルが混じることがない。フラッシュメモリ42を消去する時の最小単位が1ブロックである。音楽データを記録するのに使用するメモリカード40の場合、ブロックとクラスタは、同意語であり、且つ1クラスタ=1セクタと定義されている。
【0042】
1曲は、基本的に1パーツで構成されるが、編集が行われると、複数のパーツから1曲が構成されることがある。パーツは、録音開始からその停止までの連続した時間内で記録されたデータの単位を意味し、通常は、1トラックが1パーツで構成される。曲内のパーツのつながりは、各曲の属性ヘッダ内のパーツ情報PRTINFで管理する。すなわち、パーツサイズは、PRTINFの中のパーツサイズPRTSIZEという4バイトのデータで表す。パーツサイズPRTSIZEの先頭の2バイトがパーツが持つクラスタの総数を示し、続く各1バイトが先頭および末尾のクラスタ内の開始サウンドユニット(SUと略記する)の位置、終了SUの位置を示す。このようなパーツの記述方法を持つことによって、音楽データを編集する際に通常、必要とされる大量の音楽データの移動をなくすことが可能となる。ブロック単位の編集に限定すれば、同様に音楽データの移動を回避できるが、ブロック単位は、SU単位に比して編集単位が大きすぎる。
【0043】
SUは、パーツの最小単位であり、且つATRAC3でオーディオデータを圧縮する時の最小のデータ単位である。44.1kHzのサンプリング周波数で得られた1024サンプル分(1024×16ビット×2チャンネル)のオーディオデータを約1/10に圧縮した数百バイトのデータがSUである。1SUは、時間に換算して約23m秒になる。通常は、数千に及ぶSUによって1つのパーツが構成される。1クラスタが42個のSUで構成される場合、1クラスタで約1秒の音を表すことができる。1つのトラックを構成するパーツの数は、付加情報サイズに影響される。パーツ数は、1ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数(645個)のパーツを使用できる条件となる。
【0044】
図10は、1SUがNバイト(例えばN=384バイト)の場合のATRAC3データファイルA3Dnnnnのデータ配列を示す。図10には、データファイルの属性ヘッダ(1ブロック)と、音楽データファイル(1ブロック)とが示されている。図10では、この2ブロック(16×2=32Kバイト)の各スロットの先頭のバイト(0x0000〜0x7FF0)が示されている。図11に分離して示すように、属性ヘッダの先頭から32バイトがヘッダであり、256バイトが曲名領域NM1(256バイト)であり、512バイトが曲名領域NM2(512バイト)である。属性ヘッダのヘッダには、下記のデータが書かれる。
【0045】
BLKID−HD0(4バイト)
意味:BLOCKID FILE ID
機能:ATRAC3データファイルの先頭であることを識別するための値
値:固定値=”HD=0”(例えば0x48442D30)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
BLOCK SERIAL(4バイト)
意味:トラック毎に付けられた連続番号
機能:ブロックの先頭は0から始まり次のブロックは+1づつインクリメント
編集されても値を変化させない
値:0より始まり0xFFFFFFFFまで。
【0046】
N1C+L(2バイト)
意味:トラック(曲名)データ(NM1)の属性を表す
機能:NM1に使用される文字コードと言語コードを各1バイトで表す
値:SN1C+Lと同一
N2C+L(2バイト)
意味:トラック(曲名)データ(NM2)の属性を表す
機能:NM2に使用される文字コードと言語コードを各1バイトで表す
値:SN1C+Lと同一
INFSIZE(2バイト)
意味:トラックに関する付加情報の全てを合計したサイズを表す
機能:データサイズを16バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値:サイズは0x0000から0x3C6(966)
T−PRT(2バイト)
意味:トータルパーツ数
機能:トラックを構成するパーツ数を表す。通常は1
値:1から0x285(645dec )
T−SU(4バイト)
意味:トータルSU数
機能:1トラック中の実際の総SU数を表す。曲の演奏時間に相当する
値:0x01から0x001FFFFF
INX(2バイト)(Option)
意味:INDEX の相対場所
機能:曲のさびの部分(特徴的な部分)の先頭を示すポインタ。曲の先頭からの位置をSUの個数を1/4した数で指定する。これは、通常のSUの4倍の長さの時間(約93m秒)に相当する
値:0から0xFFFF(最大、約6084秒)
XT(2バイト)(Option)
意味:INDEX の再生時間
機能:INX-nnnで指定された先頭から再生すべき時間のSUの個数を1/4した数で指定する。これは、通常のSUの4倍の長さの時間(約93m秒)に相当する
値:0x0000:無設定 0x01から0xFFFE(最大6084秒)
0xFFFF:曲の終わりまで。
【0047】
次に曲名領域NM1およびNM2について説明する。
【0048】
NM1
意味:曲名を表す文字列
機能:1バイトの文字コードで表した可変長の曲名(最大で256)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0020)からヌル(0x00)を1バイト以上記録すること
値:各種文字コード
NM2
意味:曲名を表す文字列
機能:2バイトの文字コードで表した可変長の名前データ(最大で512)
名前データの終了は、必ず終端コード(0x00)を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭(0x0120)からヌル(0x00)を2バイト以上記録すること
値:各種文字コード。
【0049】
属性ヘッダの固定位置(0x320)から始まる、80バイトのデータをトラック情報領域TRKINFと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。図12にTRKINFの部分を示す。TRKINF内のデータについて、配置順序に従って以下に説明する。
【0050】
CONTENTS KEY(8バイト)
意味:曲毎に用意された値で、メモリカードのセキュリティブロックで保護されてから保存される
機能:曲を再生する時、まず必要となる最初の鍵となる。MAC計算時に使用される
値:0から0xFFFFFFFFFFFFFFFFまで
MAC(8バイト)
意味:著作権情報改ざんチェック値
機能:コンテンツ累積番号を含む複数のTRKINFの内容と隠しシーケンス番号から作成される値
隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【0051】
A(1バイト)
意味:パーツの属性
機能:パーツ内の圧縮モード等の情報を示す
値:図13を参照して以下に説明する
ただし、N=0,1のモノラルは、bit7が1でサブ信号を0、メイン信号(L+R)のみの特別なJointモードをモノラルとして規定する。bit2,1の情報は通常の再生機は無視しても構わない。
【0052】
Aのビット0は、エンファシスのオン/オフの情報を形成し、ビット1は、再生SKIPか、通常再生かの情報を形成し、ビット2は、データ区分、例えばオーディオデータか、FAX等の他のデータかの情報を形成する。ビット3は、未定義である。ビット4、5、6を組み合わせることによって、図示のように、ATRAC3のモード情報が規定される。すなわち、Nは、この3ビットで表されるモードの値であり、モノ(N=0,1),LP(N=2),SP(N=4),EX(N=5),HQ(N=7)の5種類のモードについて、記録時間(64MBのメモリカードの場合)、データ転送レート、1ブロック内のSU数がそれぞれ示されている。1SUのバイト数は、(モノ:136バイト、LP:192バイト、SP:304バイト、EX:384バイト、HQ:512バイト)である。さらに、ビット7によって、ATRAC3のモード(0:Dual 1:Joint )が示される。
【0053】
一例として、64MBのメモリカードを使用し、SPモードの場合について説明する。64MBのメモリカードには、3968ブロックがある。SPモードでは、1SUが304バイトであるので、1ブロックに53SUが存在する。1SUは、(1024/44100)秒に相当する。従って、1ブロックは、
(1024/44100)×53×(3968−16)=4863秒=81分
転送レートは、
(44100/1024)×304×8=104737 bps
となる。
【0054】
FNo(2バイト)
意味:ファイル番号
機能:最初に記録された時のトラック番号、且つこの値は、メモリカード内の隠し領域に記録されたMAC計算用の値の位置を特定する
値:1から0x190(400)
MG(D)SERIAL−nnn(16バイト)
意味:記録機器のセキュリティブロック(制御モジュ−ル43)のシリアル番号
機能:記録機器ごとに全て異なる固有の値
値:0から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
CONNUM(4バイト)
意味:コンテンツ累積番号
機能:曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。2の32乗、42億曲分用意されており、記録した曲の識別に使用する
値:0から0xFFFFFFFF。
【0055】
YMDhms−S(4バイト)(Option)
意味:再生制限付きのトラックの再生開始日時
機能:EMDで指定する再生開始を許可する日時
値:上述した日時の表記と同じ
YMDhms−E(4バイト)(Option)
意味:再生制限付きのトラックの再生終了日時
機能:EMDで指定する再生許可を終了する日時
値:上述した日時の表記と同じ
【0056】
CC(1バイト)
意味:COPY CONTROL
機能:コピー制御
値:図14に示すように、ビット6および7によってコピー制御情報を表し、ビット4および5によって高速ディジタルコピーに関するコピー制御情報を表し、ビット2および3によってセキュリティブロック認証レベルを表す。ビット0および1は、未定義
CCの例:(bit7,6)11:無制限のコピーを許可、01:コピー禁止、00:1回のコピーを許可
(bit3,2)00:アナログないしディジタルインからの録音、MG認証レベルは0とする
CDからのディジタル録音では(bit7,6)は00、(bit3,2)は00となる
CN(1バイト)(Option)
意味:高速ディジタルコピーHSCMS(High speed Serial Copy Management System)におけるコピー許可回数
機能:コピー1回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第1世代の場合にのみ有効であり、コピーごとに減算する
値:00:コピー禁止、01から0xFE:回数、0xFF:回数無制限。
【0057】
上述したトラック情報領域TRKINFに続いて、0x0370から始まる24バイトのデータをパーツ管理用のパーツ情報領域PRTINFと呼び、1つのトラックを複数のパーツで構成する場合に、時間軸の順番にPRTINFを並べていく。図15にPRTINFの部分を示す。PRTINF内のデータについて、配置順序に従って以下に説明する。
【0058】
PRTSIZE(4バイト)
意味:パーツサイズ
機能:パーツの大きさを表す。クラスタ:2バイト(最上位)、開始SU:1バイト(上位)、終了SU:1バイト(最下位)
値:クラスタ:1から0x1F40(8000)、開始SU:0から0xA0(160)、終了SU:0から0xA0(160)(但し、SUの数え方は、0,1,2,と0から開始する)
PRTKEY(8バイト)
意味:パーツを暗号化するための値
機能:初期値=0、編集時は編集の規則に従うこと
値:0から0xFFFFFFFFFFFFFFFF
CONNUM0(4バイト)
意味:最初に作られたコンテンツ累積番号キー
機能:コンテンツをユニークにするためのIDの役割
値:コンテンツ累積番号初期値キーと同じ値とされる。
【0059】
ATRAC3データファイルの属性ヘッダ中には、図10に示すように、付加情報INFが含まれる。この付加情報は、開始位置が固定化されていない点を除いて、再生管理ファイル中の付加情報INF−S(図7および図8B参照)と同一である。1つまたは複数のパーツの最後のバイト部分(4バイト単位)の次を開始位置として付加情報INFのデータが開始する。
【0060】
INF
意味:トラックに関する付加情報データ
機能:ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにIDとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小16バイト以上で4バイトの整数倍の単位
値:再生管理ファイル中の付加情報INF−Sと同じである。
【0061】
上述した属性ヘッダに対して、ATRAC3データファイルの各ブロックのデータが続く。図16に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【0062】
BLKID−A3D(4バイト)
意味:BLOCKID FILE ID
機能:ATRAC3データの先頭であることを識別するための値
値:固定値=”A3D”(例えば0x41334420)
MCode(2バイト)
意味:MAKER CODE
機能:記録した機器の、メーカー、モデルを識別するコード
値:上位10ビット(メーカーコード) 下位6ビット(機種コード)
CONNUM0(4バイト)
意味:最初に作られたコンテンツ累積番号
機能:コンテンツをユニークにするためのIDの役割、編集されても値は変化させない
値:コンテンツ累積番号初期値キーと同じ値とされる
BLOCK SERIAL(4バイト)
意味:トラック毎に付けられた連続番号
機能:ブロックの先頭は0から始まり次のブロックは+1づつインクリメント編集されても値を変化させない
値:0より始まり0xFFFFFFFFまで
BLOCK−SEED(8バイト)
意味:1ブロックを暗号化するための1つの鍵
機能:ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、+1インクリメントされた値、この値が失われると、1ブロックに相当する約1秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない
値:初期は8バイトの乱数
INITIALIZATION VECTOR(8バイト)
意味:ブロック毎にATRAC3データを暗号化、復号化する時に必要な初期値
機能:ブロックの先頭は0から始まり、次のブロックは最後のSUの最後の暗号化された8バイトの値。デバイドされたブロックの途中からの場合は開始SUの直前の最後の8バイトを用いる。編集されても値を変化させない
値:0から0xFFFFFFFFFFFFFFFF
SU−nnn
意味:サウンドユニットのデータ
機能:1024サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない(一例として、SPモードの時では、N=384バイト)
値:ATRAC3のデータ値。
【0063】
図10では、N=384であるので、1ブロックに42SUが書かれる。また、1ブロックの先頭の2つのスロット(4バイト)がヘッダとされ、最後の1スロット(2バイト)にBLKID−A3D、MCode、CONNUM0、BLOCK SERIALが二重に書かれる。従って、1ブロックの余りの領域Mバイトは、(16,384−384×42−16×3=208(バイト)となる。この中に上述したように、8バイトのBLOCK SEEDが二重に記録される。
【0064】
また、サウンドユニットSU(0)〜(101)は、図2に示す暗号化/復号ユニット64においてCBC(Cipher Block Chainning)モードで64ビット(8バイト)の暗号化ブロックを単位として暗号化して生成された8バイトの暗号文Ci によって構成される。本実施形態では、サウンドユニットSUのバイト数(例えば160バイト)を、暗号化の単位である暗号化ブロックのバイト数(例えば8バイト)の整数倍にしている。すなわち、1サウンドユニットSUは例えば20個の暗号文Ci からなる。このとき、個々の暗号文Ci は一のサウンドユニットSU内に位置し、一の暗号文Ci が複数のサウンドユニットSUに跨がって位置することはない。
【0065】
ここで、フラッシュメモリ34に記憶されているオーディオデータは、後述するように例えば、ATRAC3方式で圧縮されており、当該圧縮の単位がサウンドユニットSUである。従って、携帯用記憶装置3から携帯用プレーヤ4にオーディオデータを読み出す場合には、読み出しの最小単位は当該サウンドユニットSUとなる。
【0066】
このようにすることで、フラッシュメモリ34に記憶されている暗号化されたオーディオデータにアクセスする際に、暗号化ブロックの区切りを意識する必要がなくなり、当該アクセスに伴う処理負担を軽減できる。なお、各クラスタ内に含まれるサウンドユニットSUの数は、1個以上102個以下の範囲で任意である。また、オーディオデータの圧縮方式は、ATRAC3などのATRAC方式以外のCODEC方式でもよい。
【0067】
ブロックシードデータBSは、各ブロック毎に例えば乱数を発生して生成されたデータであり、後述するように、携帯用プレーヤ4内でブロック毎にブロック鍵データBKを生成する際に用いられる。当該ブロックシードデータBSは、エラー対策としてブロック内の2箇所に格納されている。なお、各クラスタに含まれるサウンドユニットは、暗号化された順でフラッシュメモリ34の連続したアドレスに記憶される。また、各サウンドユニット内の暗号化ブロックは、暗号化された順にフラッシュメモリ34の連続したアドレスに記憶される。
【0068】
〔フラッシュメモリ管理モジュール35〕
フラッシュメモリ管理モジュール35は、フラッシュメモリ34へのデータの書き込み、フラッシュメモリ34からのデータの読み出しなどの制御を行う。
【0069】
携帯用プレーヤ4
図2に示すように、携帯用プレーヤ4は、例えば、主制御モジュール41、通信インターフェイス42、制御モジュール43、編集モジュール44、圧縮/伸長モジュール45、スピーカ46、D/A変換器47およびA/D変換器48を有する。
【0070】
〔主制御モジュール41〕
主制御モジュール41は、携帯用プレーヤ4の処理を統括的に制御する。
【0071】
〔制御モジュール43〕
図2に示すように、制御モジュール43は、例えば、乱数発生ユニット60、記憶ユニット61、鍵生成/鍵演算ユニット62、相互認証ユニット63、暗号化/復号ユニット64および制御ユニット65を有する。制御モジュール43は、制御モジュール33と同様に、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール43は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット60は、乱数発生指示を受けると、64ビット(8バイト)の乱数を発生する。記憶ユニット61は、認証処理に必要な種々のデータを記憶している。
【0072】
図17は、記憶ユニット61に記憶されているデータを説明するための図である。図17に示すように、記憶ユニット61は、マスター鍵データMK0 〜MK31および装置識別データIDd を記憶している。ここで、マスター鍵データMK0 〜MK31と、認証鍵データIK0 〜IK31との間には、前述した携帯用記憶装置3の装置識別データIDm を用いて、下記式(1)に示す関係がある。なお、下記式において、f(a,b)は、例えば、引数a,bから値を導出する関数である。
【0073】
【数1】
IKj =f(MKj ,IDm ) ・・・(1)
但し、iは、0≦j≦31の整数。
【0074】
また、記憶ユニット61における認証鍵データIK0 〜IK31の記憶アドレスは、例えば5ビットで表現され、それぞれ記憶ユニット51におけるマスター鍵データMK0 〜MK31と同じ記憶アドレスが割り当てられている。
【0075】
鍵生成/鍵演算ユニット62は、例えば、ISO/IEC9797のMAC演算方式を用いた演算などの種々の演算を行って鍵データを生成する。このとき、"Block cipher Algorithm"としてFIPS PUB 46−2に規定されるDESが用いられる。
【0076】
相互認証ユニット63は、例えば、コンピュータ2から入力したオーディオデータを携帯用記憶装置3に出力する動作を行うのに先立って、携帯用記憶装置3との間で相互認証処理を行う。また、相互認証ユニット63は、携帯用記憶装置3からオーディオデータを入力する動作を行うのに先立って、携帯用記憶装置3との間で相互認証処理を行う。また、相互認証ユニット63は、相互認証処理において、前述したMAC演算を行う。当該相互認証処理では、記憶ユニット61に記憶されているデータが用いられる。なお、相互認証ユニット63は、必要に応じて、例えば、コンピュータ2あるいはネットワーク5上のコンピュータとの間でオーディオデータの入出力を行う動作に先立って、コンピュータ2あるいはネットワーク5上のコンピュータとの間で相互認証処理を行う。
【0077】
暗号化/復号ユニット64は、前述したように、FIPS PUB 81に規定されたECBモードおよびCBCモードを選択的に用いてブロック暗号化を行う。ここで、暗号化/復号ユニット64は、CBCモードにおいて、56ビットの鍵データkを用いて、コンピュータ2あるいはCDプレーヤ7から入力したオーディオデータ(平文)を、64ビットからなる暗号化ブロックを単位として下記式(2)に基づいて暗号化して暗号化されたオーディオデータ(暗号文)を生成する。下記式(2)から分かるように、CBCモードでは、一つ前の暗号文と次の平文との排他的論理和を暗号化するため、同一の平文が入力されても異なる暗号文が出力され、解読が困難であるという利点がある。
【0078】
【数2】
Ci =Ek (Pi XOR Ci-1 ) ・・・(2)
i:1以上の整数
Pi :平文(64ビット)
Ci :暗号文(64ビット)
XOR:排他的論理和
Ek :56ビットの鍵データkを用いたDES方式の暗号処理
上記式(2)の演算は、図18で表現される。なお、図18において、「IV」は、ブロック暗号化初期値(64ビット)であり、図2に示す携帯用記憶装置3のフラッシュメモリ34において、図8に示すようにクラスタCL内のサウンドユニットSU(0)の直前に記憶される。
【0079】
なお、コンピュータ2あるいはCDプレーヤ7から入力したオーディオデータ(平文)は、ATRAC(Adaptive TRansform Audio Coder)方式を改良したATRAC3方式で圧縮されている。なお、ATRACは、MD(Mini Disk:商標) のための符号化圧縮方式であり、例えば、288kbit/sで44.1kHzサンプルのステレオ信号が、帯域分割とMDCT(Modified Discrete Cosine Transform)とを併用して符号化されている。すなわち、先ず、帯域分割フィルタで1/4,1/4,1/2の3つの帯域に分割され、それぞれの帯域の信号がダウンサンプルされ、時間領域の信号としてMDCTで周波数領域に変換され、当該MDCTの係数が適応ビット配分を行ってスカラ量子化されている。
【0080】
暗号化/復号ユニット64は、FIPS81のモードのうち、前述したECBモードおよびCBCモードの復号を選択的に行う。ここで、暗号化/復号ユニット64は、CBCモードにおいて、56ビットの鍵データkを用いて、暗号文を、64ビットからなる暗号化ブロックを単位として下記式(3)に基づいて復号して平文を生成する。
【0081】
【数3】
Pi =Ci-1 XOR Dk (Ci ) ・・・(3)
i:1以上の整数
Pi :平文(64ビット)
Ci :暗号文(64ビット)
XOR:排他的論理和
Dk :56ビットの鍵データkを用いたDES方式の復号処理
上記式(3)の演算は、図19で表現される。なお、図19において、「IV」は、ブロック暗号化初期値(64ビット)であり、図2に示す携帯用記憶装置3のフラッシュメモリ34において図8に示すようにクラスタCL内のサウンドユニットSU(0)の直前に記憶されたものが用いられる。
【0082】
制御ユニット65は、乱数発生ユニット60、記憶ユニット61、鍵生成/鍵演算ユニット62、相互認証ユニット63および暗号化/復号ユニット64の処理を統括的に制御する。
【0083】
〔編集モジュール44〕
編集モジュール44は、例えば、図4に示すように携帯用記憶装置3のフラッシュメモリ34内に記憶されたトラックデータファイル1010 〜1013 を、ユーザからの操作指示に基づいて編集して新たなトラックデータファイルを生成する。当該編集には、1個のトラックデータファイルを分割して2個のトラックデータファイルを生成する分割編集処理と、2個のトラックデータファイルを結合して1個のトラックデータファイルを生成する結合編集処理とがある。なお、当該編集にあたって、再生管理ファイル100およびトラックデータファイル1010 〜1013 が書き換えられる。編集モジュール44における編集処理については後に詳細に説明する。
【0084】
〔圧縮/伸長モジュール45〕
圧縮/伸長モジュール45は、例えば、携帯用記憶装置3から入力した暗号化されたオーディオデータを復号した後に再生する際に、ATRAC3方式で圧縮されているオーディオデータを伸長し、当該伸長したオーディオデータをD/A変換器47に出力する。また、例えば、CDプレーヤ7あるいはコンピュータ2から入力したオーディオデータを、携帯用記憶装置3に記憶する際に、当該オーディオデータをATRAC3方式で圧縮する。
【0085】
〔D/A変換器47〕
D/A変換器47は、圧縮/伸長モジュール45から入力したデジタル形式のオーディオデータをアナログ形式のオーディオデータに変換してスピーカ46に出力する。
【0086】
〔スピーカ46〕
スピーカ46は、D/A変換器47から入力したオーディオデータに応じた音響を出力する。
【0087】
〔A/D変換器48〕
A/D変換器48は、例えば、CDプレーヤ7から入力したアナログ形式のオーディオデータをデジタル形式に変換して圧縮/伸長モジュール45に出力する。
【0088】
以下、図1に示すオーディオシステム1の動作について説明する。
【0089】
携帯用記憶装置3への書き込み動作
図20は、携帯用プレーヤ4から携帯用記憶装置3への書き込み動作を説明するためのフローチャートである。
【0090】
ステップS1:携帯用プレーヤ4から携帯用記憶装置3に、書き込み要求信号が出力される。
【0091】
ステップS2:携帯用記憶装置3と携帯用プレーヤ4との間で、相互認証処理を行う際に用いる認証鍵データIKj の選択処理が行われる。当該処理については後述する。
【0092】
ステップS3:携帯用記憶装置3と携帯用プレーヤ4との間で相互認証処理が行われる。当該処理については後述する。
【0093】
ステップS4:ステップS3の相互認証処理によって携帯用記憶装置3および携帯用プレーヤ4の双方が相手を正当であると認めた場合には、ステップS5の処理が行われ、そうでない場合には処理が終了する。
【0094】
ステップS5:携帯用記憶装置3および携帯用プレーヤ4において、セッション鍵データSekが生成される。当該処理については後述する。
【0095】
ステップS6:携帯用プレーヤ4から携帯用記憶装置3に、通信インターフェイス32,42を介して、暗号化したオーディオデータを出力して書き込む。当該処理については後述する。
【0096】
このように、オーディオシステム1によれば、携帯用記憶装置3と携帯用プレーヤ4との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、携帯用プレーヤ4から携帯用記憶装置3に、暗号化されたオーディオデータが書き込まれる。そのため、著作権侵害を招くようなオーディオデータの不正な複製が容易に行われることを回避できる。
【0097】
〔認証鍵データIKj の選択処理(図20に示すステップS2)〕
図21は、認証鍵データIKj の選択処理を説明するための図である。図21に示すように、図2に示す携帯用プレーヤ4の乱数発生ユニット60によって64ビットの乱数Rj が生成される。当該乱数Rj は、携帯用プレーヤ4から携帯用記憶装置3に出力される。そして、携帯用記憶装置3の相互認証ユニット53によって、64ビットの乱数Rj の下位5ビットを用いて、記憶ユニット51に記憶されている認証鍵データIK0 〜IK31のうち一の認証鍵データIKj (jは0≦j≦31を満たす整数)が特定される。
【0098】
また、携帯用記憶装置3の記憶ユニット51から読み出された装置識別データIDm が、携帯用記憶装置3から携帯用プレーヤ4に出力される。
【0099】
そして、携帯用プレーヤ4の相互認証ユニット63によって、乱数Rj の下位5ビットを用いて、マスター鍵データMK0 〜MK31のうち一のマスター鍵データMKj が特定される。
【0100】
そして、鍵生成/鍵演算ユニット62において、前記特定されたマスター鍵データMKj と、携帯用記憶装置3から入力した装置識別データIDm とを用いて、下記式(4)に基づいて、認証鍵データIKj を生成する。下記式(4)において、f(a,b)は、例えば、引数a,bから値を導出する任意の関数である。
【0101】
【数4】
IKj =f(MKj ,IDm ) ・・・(4)
これにより、携帯用記憶装置3と携帯用プレーヤ4とが、上記式(4)に示す関係を持つ認証鍵データIK0 〜IK31およびマスター鍵データMK0 〜MK31を有している場合には、図21に示す処理によって同じ認証鍵データIKj が選択される。当該選択された認証鍵データIKj は、後述する相互認証処理を行う際に、秘密鍵として用いられる。また、このとき、32個の認証鍵データIKj のうち選択される認証鍵データは、図21に示す処理を行う毎に乱数Rj に応じてランダムに決定される。そのため、不正な認証が成功する確率を、一の認証鍵データを固定して用いる場合の1/32倍にすることができ、不正な認証が行われることを高い確率で回避できる。
【0102】
なお、上述した実施形態では、乱数を用いて8個の認証鍵データIKj のうち一の認証鍵データを選択する場合を例示したが、携帯用記憶装置3および携帯用プレーヤ4の外部から入力した鍵指定信号に基づいて選択する認証鍵データを決定してもよい。
【0103】
〔携帯用記憶装置3と携帯用プレーヤ4との間の相互認証処理(図20に示すステップS3)〕
図22は、携帯用記憶装置3と携帯用プレーヤ4との間の相互認証処理を説明するための図である。なお、当該相互認証処理を開始するときには、前述した図21に示す認証鍵データIKj の選択処理が終了しており、携帯用プレーヤ4の相互認証ユニット53と携帯用記憶装置3の相互認証ユニット63は、選択した認証鍵データIKj 、携帯用記憶装置3の装置識別データIDm を有している。
【0104】
ステップS10:携帯用記憶装置3の乱数発生ユニット50において、64ビットの乱数Rmsを生成し、これを携帯用プレーヤ4に出力する。
【0105】
ステップS11:携帯用プレーヤ4の乱数発生ユニット60において、64ビットの乱数Rd およびSd を生成する。
【0106】
ステップS12:携帯用プレーヤ4の相互認証ユニット63において、図20に示すステップS2で得た認証鍵データIKj および「Rd ‖Rms‖IDm 」を用いて、下記式(5)に基づいてMAC演算を行い、MACA を求める。
【0107】
ここで、A‖Bは、AとBの連結(nビットのAの後ろにmビットのBを結合して(n+m)ビットとしたもの)を示す。
【0108】
【数5】
MACA =MAC(IKj ,Rd ‖Rms‖IDm ) ・・・(5)
ステップS13:携帯用プレーヤ4は、「Rd ‖Sd ‖MACA ‖j」を携帯用記憶装置3に出力する。
【0109】
ステップS14:携帯用記憶装置3の相互認証ユニット53において、図20に示すステップS2で得た認証鍵データIKj および「Rd ‖Rms‖IDm 」を用いて、下記式(6)に基づいてMAC演算を行い、MACB を求める。
【0110】
【数6】
MACB =MAC(IKj ,Rd ‖Rms‖IDm ) ・・・(6)
ステップS15:携帯用記憶装置3の相互認証ユニット53において、ステップS14で求めたMACB とステップS13で入力したMACA とを比較し、一致していれば、携帯用プレーヤ4が適切な認証鍵データIKj を有していることが分かるため、携帯用記憶装置3は携帯用プレーヤ4が正当な相手であると認証する。
【0111】
ステップS16:携帯用記憶装置3の相互認証ユニット53において、図20に示すステップS2で得た認証鍵データIKj および「Rms‖Rd 」を用いて、下記式(7)に基づいてMAC演算を行い、MACC を求める。
【0112】
【数7】
MACC =MAC(IKj ,Rms‖Rd ) ・・・(7)
ステップS17:携帯用記憶装置3の乱数発生ユニット50において、64ビットの乱数Smsを生成する。
【0113】
ステップ18:携帯用記憶装置3から携帯用プレーヤ4に、「Sms‖MACC 」を出力する。
【0114】
ステップS19:携帯用プレーヤ4の相互認証ユニット63において下記式(8)に基づいてMAC演算を行い、MACd を求める。
【0115】
【数8】
MACd =MAC(IKj ,Rms‖Rd ) ・・・(8)
ステップS20:携帯用プレーヤ4の相互認証ユニット63において、ステップS19で求めたMACd とステップS18で入力したMACC とを比較し、一致していれば、携帯用記憶装置3が適切な認証鍵データIKj を有していることが分かるため、携帯用プレーヤ4は携帯用記憶装置3が正当な相手であると認証する。以上の処理によって、携帯用記憶装置3と携帯用プレーヤ4との間の相互認証が行われる。
【0116】
〔セッション鍵データSekの生成処理(図20に示すステップS5)〕
図23は、セッション鍵データSekの生成処理を説明するための図である。なお、当該セッション鍵データSekの生成処理を開始するときには、前述した図21に示す認証鍵データIKj の選択処理および図22に示す相互認証処理が終了しており、携帯用記憶装置3および携帯用プレーヤ4の双方は、選択した認証鍵データIKj および乱数Sd ,Smsを有している。
【0117】
ステップS30:携帯用プレーヤ4の相互認証ユニット63は、選択した認証鍵データIKj および「Sd ‖Sms」を用いて、下記式(9)に基づいてMAC演算を行い、セッション鍵データSekを生成する。
【0118】
【数9】
セッション鍵データSek=MAC(IKj ,Sd ‖Sms) ・・・(9)
ステップS31:携帯用記憶装置3の相互認証ユニット53は、選択した認証鍵データIKj および「Sd ‖Sms」を用いて、下記式(10)に基づいてMAC演算を行い、セッション鍵データSekを生成する。当該セッション鍵データSekは、正当な相手同士であれば、携帯用プレーヤ4で生成したセッション鍵データSekと同じになる。
【0119】
【数10】
セッション鍵データSek=MAC(IKj ,Sd ‖Sms) ・・・(10)
〔携帯用記憶装置3へのオーディオデータの書き込み処理(図20に示すステップS6)〕
図24は、携帯用プレーヤ4から携帯用記憶装置3へのオーディオデータの書き込み処理を説明するための図である。なお、当該書き込み処理を開始するときには、前述した図23に示すセッション鍵データSekの生成処理は終了しており、携帯用記憶装置3および携帯用プレーヤ4は同じセッション鍵データSekを有している。
【0120】
ステップS40:携帯用プレーヤ4は、乱数発生ユニット60にトラックデータファイル毎に乱数を発生させ、当該乱数に応じたコンテンツ鍵データCKを生成する。
【0121】
ステップS41:携帯用プレーヤ4は、暗号化/復号ユニット64において、ステップS40で生成したコンテンツ鍵データCKを、セッション鍵データSekを用いて暗号化する。
【0122】
ステップ42:携帯用プレーヤ4は、ステップS41で暗号化したコンテンツ鍵データCKを携帯用記憶装置3に出力する。
【0123】
ステップS43:携帯用記憶装置3は、ステップS42で入力した暗号化されたコンテンツ鍵データCKを、暗号化/復号ユニット54において復号する。
【0124】
ステップS44:携帯用記憶装置3は、暗号化/復号ユニット54において、ステップS43で復号したコンテンツ鍵データCKを、記憶ユニット51から読み出した記憶用鍵データSKm を用いて暗号化する。
【0125】
ステップS45:携帯用記憶装置3は、当該暗号化されたコンテンツ鍵データCKを携帯用プレーヤ4に出力する。
【0126】
ステップS46:携帯用プレーヤ4は、当該暗号化されたコンテンツ鍵データCKを、トラックデータファイル100n内のTRKINF内に設定する。
【0127】
ステップS47:携帯用プレーヤ4は、乱数発生ユニット60にパーツ毎に乱数を発生させ、当該乱数に応じたパーツ鍵データPKを生成する。また、携帯用プレーヤ4は、当該生成したパーツ鍵データPKを、トラックデータファイル101nの管理データPRTINF内に設定する。
【0128】
ステップS48:携帯用プレーヤ4は、例えば、パーツ毎に、鍵生成/演算ユニット62において、下記式(11)に示すように、ステップS47で生成したパーツ鍵データPKとコンテンツ鍵データCKとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データTMKとする。なお、テンポラリ鍵データTMKの生成は、排他的論理和を用いるものには限定されず、例えば、パーツ鍵データPKとコンテンツ鍵データCKとを加算する加算演算やその他の関数演算を用いるようにしてもよい。
【0129】
【数11】
TMK=PK XOR CK ・・・(11)
ステップS49:携帯用プレーヤ4は、乱数発生ユニット60にブロック毎に乱数を発生させ、当該乱数に応じたブロックシードデータBSを生成する。また、携帯用プレーヤ4は、当該生成したブロックシードデータBSを、当該ブロック内の図10に示す対応する位置に設定する。
【0130】
ステップS50:携帯用プレーヤ4は、例えば、鍵生成/鍵演算ユニット62において、下記式(12)に示すように、ステップS46で生成したテンポラリ鍵データTMKと、ステップS47で生成したブロックシードデータBSとを用いてMAC演算を行い、ブロック毎にブロック鍵データBKを生成する。
【0131】
【数12】
BK=MAC(TMK,BS) ・・・(12)
なお、MAC演算の他に、例えば、SHA−1(Secure Hash Algorithm) 、RIPEMD−160などの一方向性ハッシュ関数(one-way hash function) の入力に秘密鍵を用いた演算を行ってブロック鍵データBKを生成してもよい。
【0132】
ここで、一方向性関数fとは、xよりy=f(x)を計算することは容易であるが、逆にyよりxを求めることが難しい関数をいう。一方向性ハッシュ関数については、例えば、"Handbook of Applied Cryptography,CRC Press"などに詳しく記述されている。
【0133】
ステップS51:携帯用プレーヤ4は、コンピュータ2あるいは携帯用プレーヤ4から入力したオーディオデータを、圧縮/伸長モジュール45において、ATRAC3方式で圧縮する。そして、暗号化/復号ユニット64において、ステップS50で生成したブロック鍵データBKを用いて、前記圧縮したオーディオデータをCBCモードで暗号化する。
【0134】
ステップS52:携帯用プレーヤ4は、ステップS51で暗号化したオーディオデータに属性ヘッダを付加して、通信インターフェイス32,42を介して、携帯用記憶装置3に出力する。
【0135】
ステップS53:携帯用記憶装置3は、ステップS52で入力した暗号化されたオーディオデータと属性ヘッダを、フラッシュメモリ34にそのまま書き込む。以上の処理によって、携帯用プレーヤ4から携帯用プレーヤ4へのオーディオデータの書き込み処理が終了する。なお、ここでは、図4のトラックデータファイル1010 〜1013 についてのみ述べたが、携帯用プレーヤ4は、図4の再生管理ファイルについても同様に適宜更新を行う。
【0136】
携帯用記憶装置3からの読み出し動作
図25は、携帯用記憶装置3から携帯用プレーヤ4への読み出し動作を説明するためのフローチャートである。
【0137】
ステップS61:携帯用プレーヤ4から携帯用記憶装置3に、読み出しを要求するトラックデータ(曲)を特定した読み出し要求信号が出力される。
【0138】
ステップS2:図21を用いて前述したように、携帯用記憶装置3と携帯用プレーヤ4との間で相互認証処理を行う際に用いる認証鍵データIKj の選択処理が行われる。
【0139】
ステップS3:図22を用いて前述したように、携帯用記憶装置3と携帯用プレーヤ4との間で相互認証処理が行われる。
【0140】
ステップS4:ステップS3の相互認証処理によって携帯用記憶装置3および携帯用プレーヤ4の双方が相手を正当であると認めた場合には、ステップS5の処理が行われ、そうでない場合には処理が終了する。
【0141】
ステップS5:携帯用記憶装置3および携帯用プレーヤ4において、セッション鍵データSekが生成される。
【0142】
ステップS63:暗号化されたオーディオデータを、通信インターフェイス32,42を介して、携帯用記憶装置3から携帯用プレーヤ4に読み出す。当該処理については後述する。
【0143】
すなわち、オーディオシステム1では、携帯用記憶装置3と携帯用プレーヤ4との間で相互認証が行われ、双方が相手を正当であると認めた場合にのみ、後述するように、携帯用プレーヤ4において、携帯用記憶装置3から携帯用プレーヤ4に出力された暗号化されたコンテンツ鍵データCKを適切なセッション鍵データSekで解読できる。そのため、著作権侵害を招くようなオーディオデータの不正な利用が容易に行われることを回避できる。
【0144】
〔携帯用記憶装置3からのオーディオデータの読み出し処理(図25に示すステップS63)〕
図26は、携帯用記憶装置3から携帯用プレーヤ4へのオーディオデータの読み出し処理を説明するための図である。なお、当該読み出し処理は、前述した図20に示す書き込み処理の後に行われるため、図4に示すトラックデータファイル1010 〜1013 には、図10に示すように、TRINFにコンテンツ鍵データCKが設定され、パーツ毎にパーツ鍵データPKが設定され、各クラスタCL内にはブロックシードデータBSが設定されている。また、ステップS5の処理が終了しているため、携帯用記憶装置3および携帯用プレーヤ4は、正当な相手同士であれば、同じセッション鍵データSekを有している。
【0145】
ステップS71:携帯用記憶装置3は、フラッシュメモリ34に記憶されている図4に示すトラックデータファイル1010 〜1013 のうち読み出し要求信号で特定されるトラックデータに対応するトラックデータファイルを特定し、当該特定したトラックデータファイルを構成するクラスタ内のオーディオデータを、サウンドユニットSUを単位として読み出して携帯用プレーヤ4に出力する。携帯用記憶装置3は、また、上記トラックデータファイルの属性ヘッダを読み出して携帯用プレーヤ4に出力する。
【0146】
ステップS72:携帯用プレーヤ4は、当該入力された属性ヘッダのうち、TRINFから暗号化されたコンテンツ鍵CKを抽出し、携帯用記憶装置3に出力する。
【0147】
ステップS73:携帯用記憶装置3の暗号化/復号ユニット54は、ステップS72で入力されたコンテンツ鍵データCKを、記憶ユニット51に記憶されている記憶用鍵データSKm を用いて復号する。
【0148】
ステップS74:携帯用記憶装置3の暗号化/復号ユニット54は、ステップS73で復号したコンテンツ鍵データCKを、図25に示すステップS5で得られたセッション鍵データSekを用いて暗号化する。
【0149】
ステップS75:携帯用記憶装置3は、ステップS74で暗号化したコンテンツ鍵データCKを携帯用プレーヤ4に出力する。
【0150】
ステップS76:携帯用プレーヤ4の暗号化/復号ユニット64は、ステップS73で携帯用記憶装置3から入力したコンテンツ鍵データCKを、セッション鍵データSekを用いて復号する。
【0151】
ステップS77:携帯用プレーヤ4の鍵生成/演算ユニット62は、ステップS76で復号されたコンテンツ鍵データCKと、ステップS71で入力された属性ヘッダの中のPRTINFに含まれるパーツ鍵データPKとの排他的論理和を演算し、当該演算結果をテンポラリ鍵データTMKとする。
【0152】
【数13】
TMK=PK XOR CK ・・・(13)
ステップS78:携帯用プレーヤ4の鍵生成/鍵演算ユニット62において、ステップS76で生成したテンポラリ鍵データTMKと、ステップS71で入力されたトラックデータファイルのクラスタ内の図10に示すブロックシードデータBSとを用いて、下記式(14)に示すMAC演算を行い、当該演算結果をブロック鍵データBKとする。ブロック鍵データBKは、ブロック毎に求められる。
【0153】
【数14】
BK=MAC(TMK,BS) ・・・(14)
ステップS79:携帯用プレーヤ4は、暗号化/復号ユニット64において、ステップS78で生成したブロック鍵データBKを用いて、ステップS71で入力したオーディオデータを復号する。このとき、オーディオデータの復号は、各ブロック毎に、それそれ個別に求められたブロック鍵データBKを用いて行われる。また、復号は、暗号化の単位である8バイトのブロックを単位として行われる。
【0154】
ステップS80:携帯用プレーヤ4は、圧縮/伸長モジュール45において、ステップS79で復号したオーディオデータをATRAC3方式で伸長し、当該伸長したオーディオデータを、D/A変換器47でデジタル形式に変換した後に、スピーカ46に出力する。このとき、圧縮/伸長モジュール45は、ステップS78で復号したオーディオデータを、サウンドユニットSUを単位として伸長する。以上の処理によって、携帯用記憶装置3から携帯用プレーヤ44へのオーディオデータの読み出しおよび再生が終了する。
【0155】
〔トラックデータファイルの分割編集処理〕
前述したように、携帯用プレーヤ4の編集モジュール44は、1個のトラックデータファイルを分割して2個のトラックデータファイルを生成する分割編集処理と、2個のトラックデータファイルを結合して1個のトラックデータファイルを生成する結合編集処理とを行う。
【0156】
先ず、分割編集処理について説明する。図27は、携帯用プレーヤ4の編集モジュール44によるトラックデータファイルの分割編集処理を説明するための図である。編集モジュール44は、例えば、図27Aに示す1個のトラックデータファイル(1)を、図27Bに示すトラックデータファイル(1)と、図27Cに示すトラックデータファイル(2)とに分割する。このとき、分割の区切りとなる最小単位はサウンドユニットSUであり、当該例では、図27Bに示すように、トラックデータファイル(1)のクラスタCL(2)のサウンドユニットSU(3)とSU(4)との間で分割されている。
【0157】
当該分割により、分割後のトラックデータファイル(1)のクラスタCL(2)は図28Aに示すようになり、新たに生成されたトラックデータファイル(2)のクラスタCL(0)は図28Bに示すようになる。このとき、図28Bに示すように、トラックデータファイル(2)のクラスタCL(0)のサウンドユニットSU(0)は分割前のトラックデータファイル(1)のクラスタ(2)のサウンドユニットSU(4)となり、ラックデータファイル(2)のクラスタCL(0)のサウンドユニットSU(1)は分割前のトラックデータファイル(1)のクラスタ(2)のサウンドユニットSU(5)となる。また、図28Bに示すトラックデータファイル(2)のクラスタCL(0)のブロック暗号化初期値IVには、図27A,Bに示すトラックデータファイル(1)のクラスタCL(2)内のサウンドユニットSU(3)の最後の8バイトが設定される。
【0158】
本実施形態では、前述したように各クラスタ内において、最初のサウンドユニットSU(0)の直前にブロック暗号化初期値IVを配置したことで、分割の際に、分割位置の直前の8バイトをそのままブロック暗号化初期値IVとして用いれば良く、新たなトラックデータファイルを作成する際の処理を簡単にできる。また、再生時に、サウンドユニットSU(0)と共に、その直前のブロック暗号化初期値IVを読み出せばよいため、再生処理も簡単になる。
【0159】
本実施形態では、分割前のトラックデータファイル(1)のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれCK_1、PK_1およびBK_1である。また、分割後のトラックデータファイル(1)のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれCK_1’、PK_1’およびBK_1である。また、トラックデータファイル(2)のコンテンツ鍵データ、パーツ鍵データおよびブロック鍵データは、それぞれCK_2、PK_2およびBK_1である。
【0160】
図29は、携帯用プレーヤ4の編集モジュール44において、新たなトラックデータファイル(2)のコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するための図である。分割により生成された新たなトラックデータファイル(2)は、トラックデータファイル(1)とは別に新たなコンテンツ鍵データCK_2を有する。本実施形態では、パーツ鍵データPK_2を以下に示すように算出することで、ブロック鍵データBK_1を分割前と同じにする。
【0161】
ステップS90:編集モジュール44は、トラックデータファイルの分割指示を入力したか否かを判断し、入力したと判断した場合にはステップS91の処理を実行し、入力していないと判断した場合にはステップS90の処理を繰り返す。
【0162】
ステップS91:編集モジュール44は、乱数発生ユニット60に乱数を発生させ、当該乱数に応じたコンテンツ鍵データCK_2を新たに生成する。
【0163】
ステップS92:携帯用記憶装置3の暗号化/復号ユニット54において、ステップS91で生成したコンテンツ鍵データCK_2を、記憶ユニット51に記憶されている記憶用鍵データSKm を用いて暗号化する。
【0164】
ステップS93:編集モジュール44は、当該暗号化されたコンテンツ鍵データCK_2を、当該トラックデータファイルのTRKINFに書き込む。
【0165】
ステップS94:編集モジュール44は、トラックデータファイル(2)のパーツ鍵データPK_2を下記式(15)に基づいて生成する。
【0166】
【数15】
PK_2=CK_1 XOR PK_1 XOR CK_2・・・(15)
これにより、トラックデータファイル(2)について、前記式(11)に基づいてされるテンポラリ鍵データは、トラックデータファイル(1)のテンポラリ鍵データと同じになり、前記式(12)に基づいて生成されるブロック鍵データも分割前のブロック鍵データBK_1と同じにできる。そのため、トラックデータファイル(2)内のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要がない。
【0167】
ステップS95:編集モジュール44は、ステップS94で生成したパーツ鍵データPK_2を、当該トラックデータファイルPRTINFにそのまま書き込む。
【0168】
このように、オーディオシステム1では、分割して新たに生成したトラックデータファイル(2)のコンテンツ鍵データとして、新たなコンテンツ鍵データCK_2を用いた場合でも、上記式(15)に基づいてパーツ鍵データPK_2を生成することで、テンポラリ鍵データを分割前のテンポラリ鍵データと同じにできる。その結果、ブロック鍵データも分割前のブロック鍵データBK_1と同じにでき、トラックデータファイル(2)内のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要がない。また、同様に、分割後のトラックデータファイル(1)のパーツ鍵データPK_1’も、ブロック鍵データBK_1を変えないように、コンテンツ鍵データCK_1’に応じた決定される。その結果、分割後のトラックデータファイル(1)内のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要もない。そのため、トラックデータファイルの分割編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図4のトラックデータファイルについてのみ述べたが、編集モジュール44は、図4の再生管理ファイル100についても同様に適宜更新を行う。
【0169】
次に、トラックデータファイルの結合編集処理について説明する。図30は、携帯用プレーヤ4の編集モジュール44によるトラックデータファイルの結合編集処理を説明するための図である。図30に示すように、編集モジュール44は、例えば、図30Aに示すトラックデータファイル(1)と、図30Bに示すトラックデータファイル(2)とを結合して、図30Cに示すトラックデータファイル(3)を生成する。
【0170】
当該結合により、結合前のトラックデータファイル(1)からなるパーツ(1)と、結合前のトラックデータファイル(2)からなるパーツ(2)とを含む新たなトラックデータファイル(3)が生成される。また、トラックデータファイル(3)のコンテンツ鍵データとして新たなコンテンツ鍵データCK_3が生成され、パーツ(1)のパーツ鍵データPK_3_1およびパーツ(2)のパーツ鍵データPK_3_2が後述するようにして新たに生成される。また、当該トラックデータファイル(3)のTRKINFおよびPRTINFに、新たに生成された鍵データが後述するように設定される。
【0171】
また、パーツ(1)の図6に示すPRTSIZEが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル(1)のクラスタCL(0)およびCL(4)がそれぞれ設定される。また、パーツ(2)のPRTSIZEが示す開始クラスタおよび終了クラスタとして、結合前のトラックデータファイル(2)のクラスタCL(0)およびCL(5)がそれぞれ設定される。
【0172】
図31は、携帯用プレーヤ4の編集モジュール44において、新たに生成したトラックデータファイル(3)のパーツ(1)および(2)のパーツ鍵データを生成する処理を説明するための図である。なお、本実施形態では、結合の対象となるトラックデータファイル(1)がコンテンツ鍵データCK_1、パーツ鍵データPK_1およびブロック鍵データBK_1を用いており、トラックデータファイル(2)がコンテンツ鍵データCK_2、パーツ鍵データPK_2およびブロック鍵データBK_2を用いてる場合を例示して説明する。
【0173】
ここで、トラックデータファイル(3)は新たなコンテンツ鍵データCK_3を得るが、パーツ(1)および(2)のパーツ鍵データを以下に示すように算出することで、各ブロックのブロック鍵データBK_1およびBK_2を結合前と同じにできる。
【0174】
ステップS100:編集モジュール44は、トラックデータファイルの結合指示を入力したか否かを判断し、入力したと判断した場合にはステップS101の処理を実行し、入力していないと判断した場合にはステップS100の処理を繰り返す。
【0175】
ステップS101:編集モジュール44は、乱数発生ユニット60に乱数を発生させ、当該乱数に応じたコンテンツ鍵データCK_3を新たに生成する。
【0176】
ステップS102:携帯用記憶装置3の暗号化/復号ユニット54において、ステップS101で生成したコンテンツ鍵データCK_3を、記憶ユニット51に記憶されている記憶用鍵データSKm を用いて暗号化する。
【0177】
ステップS103:編集モジュール44は、当該暗号化されたコンテンツ鍵データCK_3を当該トラックデータファイルのTRKINFに書き込む。
【0178】
ステップS104:編集モジュール44は、トラックデータファイル(3)のパーツ(1)のパーツ鍵データPK_3_1を下記式(16)に基づいて生成する。
【0179】
【数16】
PK_3_1=CK_1 XOR PK_1 XOR CK_3・・・(16)
これにより、前記式(11)に基づいて生成されるパーツ(1)のテンポラリ鍵データを結合前のトラックデータファイル(1)のテンポラリ鍵データと同じにでき、その結果、前記式(12)に基づいて生成されるパーツ(1)のブロック鍵データも結合前のトラックデータファイル(1)のブロック鍵データBK_1と同じにできる。そのため、パーツ(1)のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要がない。
【0180】
ステップS105:編集モジュール44は、トラックデータファイル(3)のパーツ(2)のパーツ鍵データPK_3_2を下記式(17)に基づいて生成する。
【0181】
【数17】
PK_3_2=CK_2 XOR PK_2 XOR CK_3・・・(17)
これにより、前記式(11)に基づいて生成されるパーツ(2)のテンポラリ鍵データを結合前のトラックデータファイル(2)のテンポラリ鍵データと同じにでき、その結果、前記式(12)に基づいて生成されるパーツ(2)のブロック鍵データも結合前のトラックデータファイル(2)のブロック鍵データBK_2と同じにできる。そのため、パーツ(2)のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要がない。
【0182】
ステップS106:編集モジュール44は、ステップS104で生成したパーツ鍵データPK_3_1をトラックデータファイル(3)のパーツ(1)のPRTINFにそのまま書き込む。
【0183】
ステップS107:編集モジュール44は、ステップS105で生成したパーツ鍵データPK_3_2をトラックデータファイル(3)のパーツ(2)のPRTINFにそのまま書き込む。
【0184】
このように、オーディオシステム1では、結合して新たに生成したトラックデータファイル(3)のコンテンツ鍵データとして、新たなコンテンツ鍵データCK_3を用いた場合でも、上記式(16)および(17)に基づいてパーツ鍵データPK_3_1およびPK_3_2を生成することで、各パーツのテンポラリ鍵データを結合前と同じにできる。その結果、各パーツのブロック鍵データも結合前のブロック鍵データBK_1およびBK_2とそれぞれ同じにでき、パーツ(1)および(2)内のサウンドユニットSUを新たなブロック鍵データを用いて再度暗号化する必要がない。そのため、トラックデータファイルの結合編集に伴い演算量が大幅に増加することを回避できる。なお、ここでは、図4のトラックデータファイルについてのみ述べたが、編集モジュール44は、図4の再生管理ファイルについても同様に適宜更新を行う。
【0185】
この発明は、上述した実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えば、上述した実施形態では、ATRAC3方式の圧縮の単位であるサウンドユニットSUのバイト数(160バイト)が、CBCモードの暗号化の単位である暗号化ブロックのバイト数(8バイト)の整数倍になる場合を例示したが、この発明は、例えば、整数倍にならない場合には、サウンドユニットSUにデータ長調整用のデータであるパディング(padding) を挿入して調整するようにしてもよい。
【0186】
また、上述した実施形態では、携帯用記憶装置3と携帯用プレーヤ4との間で相互認証処理を行う場合に、図22に示すように、先ず始めに携帯用記憶装置3で生成した乱数Rmsを携帯用プレーヤ4に出力する場合を例示したが、先ず始めに携帯用プレーヤ4で生成した乱数を携帯用記憶装置3に出力するようにしてもよい。
【0187】
また、上述した実施形態では、図21に示すように、記憶ユニット51および61に32組の認証鍵データおよびマスター鍵データを記憶した場合を例示したが、これらの組の数は2以上であれば任意である。
【0188】
また、上述した実施形態では、図21に示すように、携帯用プレーヤ4において、マスター鍵データMK0 〜MK31から認証鍵データIK0 〜IK31を生成する場合を例示したが、携帯用プレーヤ4に、携帯用記憶装置3と同じように、認証鍵データIK0 〜IK31を記憶し、乱数Rj に応じた認証鍵データを選択するようにしてもよい。
【0189】
また、上述した実施形態では、図21に示すように、携帯用記憶装置3および携帯用プレーヤ4において、携帯用プレーヤ4で生成した乱数Rj を用いて、認証鍵データIKj およびマスタ−鍵データMKj を選択する場合を例示したが、携帯用記憶装置3で生成した乱数を用いてもよいし、携帯用記憶装置3および携帯用プレーヤ4の双方で発生した乱数を用いてもよい。
【0190】
また、上述した実施形態では、図21に示すように、携帯用記憶装置3および携帯用プレーヤ4において乱数Rj に基づいて認証鍵データIKj およびマスタ−鍵データMKj を選択する場合を例示したが、この発明は、例えば、携帯用記憶装置3および携帯用プレーヤ4に外部から5ビットの鍵選択指示データを入力し、当該鍵選択指示データで指示される相互に対応する認証鍵データIKj およびマスタ−鍵データMKj を、携帯用記憶装置3および携帯用プレーヤ4で選択してもよい。
【0191】
また、上述した実施形態では、トラックデータとしてオーディオデータを含むデータを例示したが、この発明は、その他、動画像データ、静止画像データ、文書データおよびプログラムデータなどを含むトラックデータをフラッシュメモリ34に記憶する場合にも適用できる。
【0192】
【発明の効果】
以上説明したように、この発明のデータ処理システムおよびその方法によれば、記憶手段に記憶された暗号化されたデータを、所定の処理ブロックを単位として効率的に処理できる。
【図面の簡単な説明】
【図1】この発明の一実施形態のオーディオシステムのシステム構成を示すブロック図である。
【図2】携帯用記憶装置および携帯用プレーヤの内部構成を示すブロック図である。
【図3】携帯用記憶装置内の記憶ユニットに記憶されているデータを説明するための略線図である。
【図4】携帯用記憶装置のフラッシュメモリに記憶されるデータを説明するための略線図である。
【図5】再生管理ファイルのデータ構成を概略的に示す略線図である。
【図6】データファイルのデータ構成を概略的に示す略線図である。
【図7】再生管理ファイルのデータ構成をより詳細に示す略線図である。
【図8】再生管理ファイルの各部分と付加情報領域の構成を示す略線図である。
【図9】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図10】データファイルのデータ構成をより詳細に示す略線図である。
【図11】データファイルの属性ヘッダの一部を示す略線図である。
【図12】データファイルの属性ヘッダの一部を示す略線図である。
【図13】録音モードの種類と、各録音モードにおける録音時間等を示す略線図である。
【図14】コピー制御情報を説明するための略線図である。
【図15】データファイルの属性ヘッダの一部を示す略線図である。
【図16】データファイルの各データブロックのヘッダを示す略線図である。
【図17】携帯用プレーヤの記憶ユニットに記憶されているデータを説明するための略線図である。
【図18】携帯用プレーヤの暗号化/復号ユニットのCBCモードにおける暗号化処理を説明するための略線図である。
【図19】携帯用プレーヤの暗号化/復号ユニットのCBCモードにおける復号処理を説明するための略線図である。
【図20】携帯用プレーヤから携帯用記憶装置への書き込み動作を説明するためのフローチャートである。
【図21】相互認証ユニットによる認証鍵データIKj の選択処理を説明するための略線図である。
【図22】携帯用記憶装置と携帯用プレーヤとの間の相互認証処理を説明するためのフローチャートである。
【図23】セッション鍵データSekの生成処理を説明するための略線図である。
【図24】携帯用プレーヤから携帯用記憶装置へのオーディオデータの書き込み処理を説明するためのフローチャートである。
【図25】携帯用記憶装置から携帯用プレーヤへの読み出し動作を説明するためのフローチャートである。
【図26】携帯用記憶装置から携帯用プレーヤへのオーディオデータの読み出し処理を説明するためのフローチャートである。
【図27】携帯用プレーヤの編集モジュールによるトラックデータファイルの分割編集処理を説明するための略線図である。
【図28】分割編集処理を行った後のクラスタ内のデータを説明するための略線図である。
【図29】携帯用プレーヤの編集モジュールにおいて、分割編集時に、新たなトラックデータファイルのコンテンツ鍵データおよびパーツ鍵データを生成する方法を説明するためのフローチャートである。
【図30】携帯用プレーヤの編集モジュールによるトラックデータファイルの結合編集処理を説明するための略線図である。
【図31】携帯用プレーヤ4の編集モジュールにおいて、新たに生成したトラックデータファイル(3)のパーツ(1)および(2)のパーツ鍵データを生成する処理を説明するための略線図である。
【符号の説明】
1・・・オーディオシステム、2・・・コンピュータ、3・・・携帯用記憶装置、4・・・携帯用プレーヤ、5・・・ネットワーク、33,43・・・制御モジュール、50,60・・・乱数発生ユニット、51,61・・・記憶ユニット、52,62・・・鍵生成/演算ユニット、53,63・・・相互認証ユニット、54,74・・・暗号化/復号ユニット、55,65・・・制御ユニット、34・・・フラッシュメモリ、44・・・編集モジュール、45・・・圧縮/伸長モジュール、46・・・スピーカ
Claims (15)
- 所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、
上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、
上記暗号化したデータを記憶する記憶手段と、
一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記処理ブロックを単位として上記データを上記記憶手段から読み出す制御手段とを有し、
上記制御手段は、単数または複数の上記処理ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理装置。 - 請求項1において、
上記制御手段は、上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理装置。 - 請求項1において、
上記暗号化手段は、上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化するデータ処理装置。 - 請求項1において、
上記制御手段は、単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、上記記憶手段に記憶された上記暗号化されたデータを管理するデータ処理装置。 - 請求項1において、
上記制御手段は、上記処理ブロック単位で読み出した上記データを上記処理手段に出力するデータ処理装置。 - 請求項1において、
上記データは、圧縮されており、上記処理手段は、上記記憶手段から読み出された上記データを、上記処理ブロックを単位として伸長するデータ処理装置。 - 記憶装置とデータ処理装置との間で相互認証を行いながらデータの入出力を行うデータ処理システムにおいて、
上記記憶装置は、
上記データ処理装置との間で相互認証処理を行う第1の相互認証処理手段と、
上記データを記憶する記憶手段と、
上記相互認証処理によって上記データ処理装置が正当な相手であると認めたときに、上記データ処理装置と上記記憶手段との間でデータの入出力を行わせる第1の制御手段とを有し、
上記データ処理装置は、
上記記憶装置との間で相互認証処理を行う第2の相互認証処理手段と、
所定のデータ長の暗号化ブロックを単位としてデータを暗号化する暗号化手段と、上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行う処理手段と、
上記相互認証処理によって、上記記憶装置が正当な相手であると認めたときに、書き込み処理および読み出し処理の少なくとも一方を行い、上記書き込み処理において、一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記読み出し処理において、上記処理ブロックを単位として上記データを上記記憶手段から読み出す第2の制御手段とを有し、
上記第2の制御手段は、単数または複数の上記処理ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、上記クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理システム。 - 請求項7において、
上記第2の制御手段は、上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理システム。 - 請求項7において、
上記暗号化手段は、上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化するデータ処理システム。 - 請求項7において、
上記第2の制御手段は、単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、上記記憶手段に記憶された上記暗号化されたデータを管理するデータ処理システム。 - 所定のデータ長の暗号化ブロックを単位としてデータを暗号化し、
上記暗号化ブロックの整数倍のデータ長を持つ処理ブロックを単位としてデータに圧縮処理を行い、一の上記暗号化ブロックを構成するデータが同じ上記処理ブロック内に位置するように、上記暗号化したデータを上記記憶手段に書き込み、上記処理ブロックを単位として上記データを上記記憶手段から読み出し、
単数または複数の上記処理ブロックを暗号化された順で記憶手段の連続したアドレスに記憶し、さらに、上記処理ブロック内の単数または複数の暗号化ブロックを暗号化された順で上記記憶手段の連続したアドレスに記憶し、上記クラスタ内で最初に暗号化された処理ブロック内でさらに最初に暗号化された暗号化ブロックが記憶された上記記憶手段のアドレスの直前のアドレスにブロック暗号化初期値を記憶するデータ処理方法。 - 請求項11において、
上記処理ブロックにデータ長調整用のデータを入れて、上記処理ブロックのデータ長が上記暗号化ブロックのデータ長の整数倍になるように調整するデータ処理方法。 - 請求項11において、
上記暗号化を行おうとする上記暗号化ブロックと当該暗号化ブロックの直前の暗号化ブロックを暗号化して得た暗号文との排他的論理演算を行い、当該演算の結果を暗号化して上記暗号化を行うデータ処理方法。 - 請求項11において、
単数または複数の上記処理ブロックと、上記ブロック暗号化初期値とを含むクラスタ単位で、記憶された上記暗号化されたデータを管理するデータ処理方法。 - 請求項11において、
読み出された上記データを、上記処理ブロックを単位として伸長するデータ処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000076391A JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP6915299 | 1999-03-15 | ||
JP11-69152 | 1999-03-15 | ||
JP2000076391A JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2000330872A JP2000330872A (ja) | 2000-11-30 |
JP4172131B2 true JP4172131B2 (ja) | 2008-10-29 |
Family
ID=26410342
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000076391A Expired - Lifetime JP4172131B2 (ja) | 1999-03-15 | 2000-03-14 | データ処理装置、データ処理システムおよびその方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4172131B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9143326B2 (en) | 2012-03-29 | 2015-09-22 | International Business Machines Corporation | Method and system for encrypting data |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4534382B2 (ja) * | 2001-02-09 | 2010-09-01 | ソニー株式会社 | 符号列生成装置及び方法、信号再生装置及び方法、並びにコンテンツ供給システム |
JP2003143015A (ja) * | 2001-11-07 | 2003-05-16 | Sony Corp | 信号処理方法及び装置並びに符号列生成方法及び装置 |
JP4608931B2 (ja) | 2004-01-09 | 2011-01-12 | ソニー株式会社 | 情報処理装置および方法、プログラム、並びに記録媒体 |
JP4853026B2 (ja) * | 2006-01-10 | 2012-01-11 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
JP5772031B2 (ja) | 2011-02-08 | 2015-09-02 | 富士通株式会社 | 通信装置およびセキュアモジュール |
JP6453202B2 (ja) * | 2015-10-30 | 2019-01-16 | 日本電産サンキョー株式会社 | 相互認証装置及び相互認証方法 |
-
2000
- 2000-03-14 JP JP2000076391A patent/JP4172131B2/ja not_active Expired - Lifetime
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9143326B2 (en) | 2012-03-29 | 2015-09-22 | International Business Machines Corporation | Method and system for encrypting data |
US9344274B2 (en) | 2012-03-29 | 2016-05-17 | International Business Machines Corporation | Method and system for encrypting data |
US9634827B2 (en) | 2012-03-29 | 2017-04-25 | International Business Machines Corporation | Encrypting data |
US10396977B2 (en) | 2012-03-29 | 2019-08-27 | International Business Machines Corporation | Encrypting data |
US11539505B2 (en) | 2012-03-29 | 2022-12-27 | Kyndryl, Inc. | Encrypting data |
Also Published As
Publication number | Publication date |
---|---|
JP2000330872A (ja) | 2000-11-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100718477B1 (ko) | 암호화된 데이터 전송을 위한 처리 방법 및 장치 | |
KR100648388B1 (ko) | 장치간의 상호 식별용 데이터 처리 시스템 및 방법 | |
JP4366845B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
JP4660899B2 (ja) | データ処理装置およびデータ処理方法、並びにプログラム提供媒体 | |
JP4608749B2 (ja) | データ処理装置、データ処理方法、およびライセンスシステム、並びにプログラム提供媒体 | |
JP4543554B2 (ja) | データ処理装置およびデータ処理方法 | |
KR100934108B1 (ko) | 암호화된 데이터 전송을 위한 데이터 처리 방법, 장치 및시스템 | |
JP4779183B2 (ja) | 再生装置および再生方法 | |
US6601140B1 (en) | Memory unit, data processing unit, and data processing method using memory unit type | |
US7155013B2 (en) | Recording apparatus, recording method, reproducing apparatus, and reproducing method | |
JP2002108710A (ja) | 情報処理システム、情報処理方法、および情報処理装置、並びにプログラム提供媒体 | |
KR100699189B1 (ko) | 비휘발성 기록 매체, 기록 방법, 및 기록 장치 | |
JP4172131B2 (ja) | データ処理装置、データ処理システムおよびその方法 | |
JP3925033B2 (ja) | データ処理装置、記憶装置、データ処理システムおよびその方法 | |
JP2000332748A (ja) | データ処理システムおよびその方法 | |
RU2253146C2 (ru) | Воспроизводящее устройство и способ воспроизведения |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040212 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070215 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080129 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080331 |
|
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: 20080722 |
|
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: 20080804 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4172131 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: 20110822 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120822 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: 20130822 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 |