Reproducing method and apparatus

Description of the invention

A method for reproducing data from a recording medium such as a detachable memory card and a device for reproducing data from a recording medium such as a removable memory card, in particular for checking false information about a file stored on the removable memory card.

EEPROM (Electrically Erasable Programmable Fixed Memory) requires a lot of space as each bit consists of two transistors. Hence, the possibilities of EEPROM integration are limited. To solve this problem, flash memories have been developed that allow one bit to be stored with the use of one transistor, implementing an all-bit eraser. Flash memories are expected to succeed conventional recording media such as magnetic disks and optical disks.

There is also a known memory card that uses flash memories. Such a memory card can be freely plugged in and detached from the device. Digital audio recording / reproducing devices that use memory cards instead of conventional optical CD (Compact Disc: Trademark) or MD (Mini Disc: Trademark) discs are possible.

Devices for reproducing data from a recording medium such as a detachable flash memory card, having an audio decoder IC with an audio signal interface and an encoder / decoder block, an interface protection IC, a DES encryption chip and a FIFO queue are known. , a DSP signal processor coupled to the SRAM and connected to an external controller via a communication bus and mounted in a detachable memory card attaching / detaching mechanism that houses a flash memory.

There are two types of memory cards, those that do encryption and those that do not. However, the type of memory cards that are used with a recorder / player that stores copyright-protected data is limited to the encryption type.

Voice data and image data that are saved by the user are saved on memory cards of a type that does not support encryption.

Figure 3 is a block diagram illustrating an exemplary internal structure of a scrambling type memory card 40. The memory card 40 includes a control block 41 and a flash memory 42 which are located in one chip of the chip. A bi-directional serial interface is provided between the recorder / player DSP signal processor and the memory card 40. The bidirectional serial interface consists of ten lines, which are: SCK clock line to transmit the clock signal that is sent with the data, SBS status line, to transmit the status signal, DIO data line, to transmit data, INT interrupt line, two GND ground lines, two INT lines, and two reserved lines.

The clock line SCK is used to transmit a clock signal synchronized with the data. The SBS status line is used to transmit a signal specifying the status of memory card 40. The DIO data line is used to input and output the command and scrambled audio data. The interrupt line INT is used to transmit an interrupt signal which causes memory card 40 to report the interrupt to the recorder / player DSP 30. When a memory card 40 is connected to a recorder / player, it generates an interrupt signal. However, according to the embodiment of the present invention, since the interrupt signal is transmitted over the DIO data line, the interrupt line INT remains grounded.

Serial / parallel conversion, parallel / serial conversion, and interface block (S / P, P / S, I / F block) 43 is an interface between the recorder / player DSP signal processor 30 and the control block 41 of the memory card 40. The S / P, P / S and I / F interface conversion block 43 converts serial data received from the recorder / player DSP signal processor 30 to parallel data and transmits this data in parallel to control block 41. In addition, the S / P, P / S and I / F interface conversion block 43 converts the parallel data received from control block 41 to serial data and provides this serial data to the DSP signal processor 30. When the S / P, P / S and I interface block The / F 43 receives a command and data on the DIO data line, it splits them into those normally available in flash memory 42 and into those that are encrypted.

In a format in which data is transferred over the DIO data line, data is transferred after sending the command. The S / P, P / S and I / F interface block 43 detects the command code and determines whether the command and data are those that are freely available or that they are encoded. Depending on the result obtained, the S / P, P / S block and I / F interface 43, the command that is normally available is stored in the command register 44, and the data that is normally available is stored in the page buffer 45. and in the write register 46. Together with the write register 46, the memory card 40 has an error correction code 41 (ECC) encoder. The error correction code encoder 47 generates a redundancy code, which is a correction code for data temporarily stored in page buffer 45.

The output of command register 44, page buffer 46, write register 46, and error correction code encoder 47 is provided to the flash interface and addressing sequencer (which are referred to herein as I / F memory interface and sequencer circuit). addressing 51). The I / F memory interface and addressing sequencer 51 is the interface between control block 41 and flash memory 42 that controls the data exchange therebetween. Data is written to flash memory via I / F memory interface and address sequencer 51.

Audio data that has been compressed according to the ATRAC3 format and stored in flash memory (this audio data is hereinafter referred to as ATRAC3 data) is encrypted by a security recorder / player IC 20 and by a security block 52 of the memory cards 40 to protect copyright to ATRAC3 data. The protection block 52 includes a memory buffer 53, a DES scrambler 54, and a non-volatile memory 55.

Security block 52 of memory card 40 has a plurality of authentication keys and a memory key unique to each memory card. The non-volatile memory 55 stores the key necessary to encrypt the data. The key stored in the non-volatile memory 55 cannot be parsed. According to an exemplary embodiment, the memory key is stored in the non-volatile memory 55. The protection block 52 also has a random number generator. The security block 52 authenticates the applicable recorder / player and shares the session key with it. In addition, the security block 52 re-encrypts the content with the memory key via DES 54.

For example, when the memory card 40 is attached to a recorder / player, they authenticate each other. The recorder / player security IC 20 and the security block 52 of the memory card 40 authenticate each other. When the recorder / player has authenticated the memory card 40 as the corresponding memory card and the memory card 40 has authenticated the recorder / player as the corresponding recorder / player, this means that they have authenticated each other. After a successful mutual authentication process, the recorder / player and memory card 40 generate the appropriate session keys and share them with each other. Each time the recorder / player and memory card 40 authenticate each other, appropriate session keys are generated.

When content is written to the memory card 40, the recorder / player encrypts the content key with the session key and transfers the encrypted data to the memory card 40. The memory card 40 decrypts the content key using the session key, re-encrypts the content key with the memory key. and delivers the content key to the recorder / player. The memory key is unique to each memory card 40. When the recorder / player receives the encrypted content key, it performs a formatting process for the encrypted content key and stores the encrypted content key and the encrypted content in the memory card 40.

The above section describes the writing process for the memory card 40. The reading process for the memory card 40 will be described below.

Data that is read from flash memory 42 is provided to page buffer 45, read register 48 and error correction circuit 49 via the memory IF interface and addressing sequencer 51. Error correcting circuit 49 corrects the error of data stored in page buffer 45. Output data from the error-corrected page buffer 45 and the output from read register 48 are provided to the S / P, P / S conversion block and I / F interface 43. The output from the S / P, P / S conversion block and I / F interface 43 is fed to the recorder / player DSP signal processor via the serial interface described above.

When data is read from the memory card 40, the content key encrypted with the memory key and the content encrypted with the block key is read from the flash memory 42. Security block 52 decrypts the content key with the memory key. The security block 52 re-encrypts the decrypted content key with the session key and transfers the re-encrypted content key to the recorder / player. The burner / player decrypts the content key using the session key and generates the block key using the decrypted content key. The recorder / player successively decrypts the encrypted data.

PL 208 230 B1

The ROM configuration memory 50 is a memory that stores partition information, information about various types of attributes, and the like information regarding memory card 40. Memory card 40 also has an anti-erasure switch 60. When the switch 60 is in the anti-erasure position, even though a command has been sent to the memory card 40 from the recorder / player to the memory card 40, the memory card cannot erase the data stored in the flash memory 42. OSC 61 is an oscillator that generates a clock signal which is a reference signal for the synchronization of the processes taking place in the memory card 40.

Fig. 4 is a flowchart showing a hierarchy of processes using a known computer system file system that uses a memory stick as storage medium. In the hierarchy, the highest hierarchical layer is the application process layer. The application process layer is followed by the file management layer, the logical address management layer, the physical address management layer, and the flash memory access layer. In the above-mentioned hierarchical structure, the file management layer is the FAT file system. Flash memory blocks are assigned physical addresses. The relationship between flash memory blocks and their physical addresses does not change. Logical addresses are addresses that are handled logically at the file management process layer.

Fig. 5 is a block diagram illustrating the physical structure of data stored in the flash memory 42 of the memory card 40. In memory 42, a unit of data (referred to as a segment) is divided into a number of (equal length) blocks. One block is divided into a certain number of pages (of a fixed length). In flash memory, data is cleared one block at a time. Data is written to or read from flash 42 one side at a time. The size of each block is the same. Likewise, the size of each page is the same. One block is built up from side 0 to side m. For example, one block has a capacity of, for example, 8KB (kilobytes) or 16KB. One page for 512 B (bytes) capacity. When one block has a capacity of 8KB, the total capacity of the flash memory 42 is 4MB (512 blocks) or 8MB (1024 blocks). When one block has a capacity of 16KB, the total capacity of flash memory 42 is 16MB (1024 blocks), 32MB (2048 blocks), or 64MB (4096 blocks).

One page is made up of a 512-byte data portion and a redundant portion of 16 bytes. The first three bytes of the redundant portion are the overwrite portion that is rewritten each time the data is updated. The first three bytes contain the block status area, page status area, and update status area, respectively. The remaining 13 bytes of the redundant part contain constant data depending on the content of the data part. Thirteen bytes include a management tag area (1 byte), a logical address area (2 bytes), a format reserved area (5 bytes), an ECC information spreading area (2 bytes), and an ECC data area (3 bytes). The ECC information spreading area contains redundant data for an error correction process that may appear in the management tag area, the logical address area, and the format reserved area. The ECC data area contains redundant data used in the error correction process over the 512 byte data area.

The management tag area includes the system tag (1: user block, 0: starting block), conversion table tag (1: invalid, 0: table block), prohibit copying tag (1: OK, 0: NG), and access permission tag ( 1: free, 0: read-protected).

The first two blocks, block 0 and 1, are the starting blocks. Block 1 is a backup copy of block 0. The starting blocks are the top blocks that bind to the memory card. When a memory card is connected to a recorder / player, the starting blocks are read first. The remaining blocks are user blocks. Page 0 of a boot block contains a header area, system storage area, and a start area and attribute information. Side 1 of the starting block contains the forbidden data block area. Page 2 of the starting block contains the CIS (Card Information Structure) / IDI (Drive Identification Information) area. The boot block header area contains the boot block ID and the number of successful writes. System records include forbidden data block start positions, this data size, this data type, CIS / IDI area start position, area data size, area data type. The startup information and attribute information include memory card type (read only, writable, hybrid type), block size, number of blocks, total number of blocks, secured / unprotected type, card production date (manufacturing date), and the like.

PL 208 230 B1

Since flash memory has a limitation on the number of possible write cycles due to the deterioration of the quality of the insulating film, it is necessary to prevent heavy access to the same storing area (block) over and over again. Thus, after the data is updated, the relationship between the logical address and the physical address changes. This process is known as the swap process. As a result, the same block is not used over and over again. Thus, the lifetime of the flash memory may be extended.

The logical address is assigned to the data stored in the block. Even if the block with the original data is different from the block with the updated data, the address in the FAT allocation table does not change. Thus, correct access to the same data is possible. However, since the conversion process is performed, it is required to introduce a conversion table that links the logical addresses to the physical addresses (this table is referred to as the logical-physical address conversion table). Using the logical-physical address conversion table, a physical address is obtained that corresponds to the logical address specified in the FAT file allocation table. In this way, it is possible to access the block that is pointed to by the physical address.

The DSP of the writer / reproducer stores a logical-physical address conversion table in the SRAM of the writer / reproducer. When the RAM capacity is small, the logical-physical address conversion table can be stored in flash memory. Logical - physical address conversion table combines logical addresses (2 bytes), stored in ascending order, with physical addresses (2 bytes). Since the maximum capacity of the flash memory is 128MB (8192 blocks), 8192 addresses can be specified by two bytes. The logical - physical address conversion table is operated for each segment. Hence, the size of the logical-physical address conversion table is proportional to the capacity of the flash memory. When the flash memory capacity is 8MB (two segments), two pages are used for each segment for the logical-physical address conversion table. When a logical-physical address conversion table is stored in flash memory, the specified one bit in the management tag area in the redundant portion of each side indicates whether the current block is a block containing the logical physical address conversion table or not.

The memory card described above can be used with the FAT file system of a personal computer like disk recording media. Flash memory has an IPL area, a FAT area, and a root area (not shown in Figure 5). The IPL area contains the address of the program to be loaded into the recorder / player's memory at the beginning. In addition, the IPL area contains various types of memory information. The FAT file allocation table area contains block (cluster) related information. The FAT file allocation table shows the unused blocks, the next block number, the damaged blocks, and the last block number. The root area contains directory entries which are: file attribute, update date [day, month, year], file size, and the like.

Once an audio / video signal is digitized and used in multimedia applications, it becomes important to ensure that the signal's copyright is protected. In the field of information services, the user will be provided with a recordable medium on which digital audio / video information will be recorded, having certain reproduction restrictions. In addition, digital audio / video information having specific playback restriction information will be sent to the user via digital broadcasting and the Internet. The user may reproduce the provided or circulating audio / video information (content) for a specified period of time, or a specified number of times, represented by the playback constraint information. When necessary, the user can save the desired audio / video information to the memory card for a specified cost.

Although the file containing the reproduction limitation information is easy to save and store, if the reproduction limitation information is forged by special means, the reproducing side cannot detect the forged reproduction limitation information. The CRC (Cyclic Redundancy Check) method can be used as a simple way to check the counterfeit information regarding reproduction constraints. Cyclic Redundancy Check) and the value we get thanks to it. However, if the forged CRC has been forged after the forged reproduction / copy restriction information, then the forged reproduction restriction information cannot be detected.

PL 208 230 B1

Thus, it is an object of the present invention to provide a reproduction apparatus and a reproduction method which allows for the safe detection of counterfeit reproduction limitation information, and enables the content to be prevented from being played back.

A method for reproducing data from a removable memory card recording medium containing a flash memory according to the present invention, wherein the flash memory is logically divided into physical blocks constituting a data area and a management area, where files are stored in the data area, and management information or management files to manage the playback of those files that are stored in the data area, in which method is measured in response to the control signal from the DSP signal processor whether a detachable memory card is currently connected, authenticates the card with the DSP signal processor, then reads the management information or management file corresponding to the played file from the flash memory of the memory card and saves it is stored in SRAM memory and is characterized by that in response to each file playback command, a signal with the current hash value for the playback parameters is generated by the hash function calculator using the key, and then fed to the DES encoder to be stored in an externally inaccessible block of non-volatile memory which is included in the DES scrambler, and further transmits this signal to the comparator, is read from the second, externally inaccessible block of non-volatile memory, the previous hash value for the reproduction parameters and fed it to the comparator, the comparator compares the signals with the current and the previous hash value for the reproduction parameters, then, based on the signal received from the comparator, and based on the signal with at least one of the plurality of individual parameters from the comparator. block of limiting values, contained in the management file, a control signal is generated in the control system, allowing or disallowing playback of the file corresponding to the current restore command.

The apparatus for reproducing data from a record carrier such as a detachable flash memory card according to the invention, comprising an audio decoder chip with an audio signal interface and an encoder / decoder block, an interface security chip with a DES encryption chip and a FIFO queue, a signal processor DSP connected to SRAM memory and connected to an external controller via a communication bus, and the detachable memory card fitted in the attaching / detaching mechanism houses a flash memory, a control block and a security block with a DES encryption / decryption circuit, characterized in that it is provided with an authentication circuit including a hash function computation circuit for generating , using the key, signal u with a hash value for the reproduction parameters in response to each reproduction command, coupled to the encryption system DES, comprising a memory chip including non-volatile memory blocks for storing the hash value of the playback parameters for the current and the previous restore command, a comparator, connected to the DES encryption circuit, for determining the match between the hash value of the playback parameters for the current and previous playback command, and the control circuit connected to the comparator with internal clock, permitting or disallowing, based on the signal from the comparator and the second input with at least one of the plurality of individual parameters from a block of limiting values ​​contained in the management file, to play back the file corresponding to the current reproduction command.

Preferably, the comparator and the non-volatile memory chip for storing the hash value are housed in one controller.

The subject of the invention is presented in an exemplary embodiment in the figures in which:

Fig. 1 is a block diagram showing the structure of a digital audio player employing a memory card according to the present invention; Fig. 2 is a block diagram showing the internal structure of a DSP 30 of the present invention, Fig. 3 is a block diagram showing the internal structure of of the memory card 40, Fig. 4 is a block diagram showing the management file structure of the memory card being the storage medium, Fig. 5 is a block diagram illustrating the physical structure of the data located in the flash memory 42 of the memory card 40, Fig. 6 is the data structure of the memory card 40 according to the present invention.

Fig. 7 is a block diagram showing a structure hierarchy of files residing on memory card 40, Fig. 8 is a block diagram showing a data structure of a PBLIST.MSF recovery management file, which is a subdirectory stored in memory card 40, Fig. 9 is a block diagram showing the data structure in the case where one ATRAC3 data file is divided into blocks of a specific unit length and where attribute files have been added to it, Fig. 10A is a block diagram showing the file structure before two files can be edited using linked processes Fig. 10B is a block diagram illustrating a file structure after two files have been edited using combined processes. 10C is a block diagram showing a file structure after one file has been edited using a split process, Fig. 11 is a block diagram showing a data structure of a PBLIST recovery management file, Fig. 12A is a block diagram showing a data structure in the header portion of a PBLIST recovery management file. 12B is a block diagram illustrating the data structure in the main data portion of the PBLIST recovery management file. 12C is a block diagram showing the data structure in a data part with side information of a PBLIST recovery management file, Fig. 13 is a table that links side information types with their code values, Fig. 14 is a table that links side information types with their code values. ; Fig. 15 is a table that links additional information types with their code values, 16A is a block diagram showing a data structure with side information, Fig. 16B is a block diagram showing a data structure with side information, when the side information data is an artist name, Fig. 16C is a block diagram showing a data structure with side information. , where the data with the additional information is a copyright code, fig. 16D is a block diagram showing the data structure with side information when the side information data is date / time information, Fig. 16E is a block diagram showing the data structure with side information when the side information data is a register 17 is a block diagram detailing the data structure of the ATRAC3 data file in Fig. 18 is a block diagram showing the data structure of the top part of the attribute header which is contained in the ATRAC3 file, Fig. 19 is a block diagram showing the data structure of the middle part of the attribute header which is contained in the ATRAC3 file, write modes, write time, and other parameters with each other, Fig. 21 is a table showing copy control states, Fig. 22 is a block diagram illustrating the data structure of the lower part of the attribute header which is contained in an ATRAC3 file, Fig. 23 is a block diagram showing the data structure of an ATRAC3 file data block header, Figs. 24 to 24C are flowcharts illustrating a data recovery method according to of the present invention, in the case where the FAT area has been destroyed, Fig. 25 is a block diagram illustrating the structure of a file residing in memory stick 40 according to a second embodiment of the present invention, Fig. 26 is a block diagram illustrating a relationship between a TRKLIST.MSF track information management file and an ATRAC3 A3Dnnnnn.MSA data file, Fig. 27 is a block diagram detailing the data structure of the path information management file TRKLIST.MSF, Fig. 28 is a block diagram detailing the NAME1 data structure for name management,

Fig. 29 is a block diagram detailing the NAME2 data structure for name management, Fig. 30 is a block diagram detailing the structure of ATRAC3 A3Dnnnnn.MSA data file, Fig. 31 is a block diagram detailing the data structure of an INFLIST file. .MSF, which represents additional information, Fig. 32 is a block diagram detailing the data structure of an INFLIST.MSF file that represents data with side information, Fig. 33 is a program flow diagram illustrating a data recovery method, according to a second embodiment of the present invention, in case a FAT is damaged, Fig. 34 is a block diagram illustrating the spoof checking system of the present invention, Fig. 35 is a flowchart showing a security forgery checking process according to the first embodiment of the present invention, Fig. 36 is a flowchart showing a security forgery checking process according to a second embodiment of the present invention.

An embodiment of the present invention will be described below. Fig. 1 is a block diagram showing the structure of a digital audio player / recorder employing memory cards, according to an embodiment of the present invention. The digital audio signal player / recorder records and plays back digital audio signals using detachable memory cards. In fact, the player / recorder comprises an audio system having an amplifier unit, a loudspeaker, a CD player, a mini MD disc recorder, a radio tuner, and the like. However, it should be noted that the present invention is also applicable to other audio recorders. In other words, the present invention can be applied to portable recorders / reproducers. Additionally, the present invention can be used in STB ( set top box), which record audio signal data that is broadcast by satellite, digital broadcasting, or over the Internet. Moreover, the present invention can be applied to systems that record / reproduce data, data with moving images and just images, not audio data. A system according to an embodiment of the present invention can record and play back additional information, such as image and text, other than the digital audio signal.

The recorder / reproducer has an audio encoder / decoder IC 10, a protection IC 20, a DSP 30 (Digital Signal Processor). Each of these devices is housed in one chip of the integrated circuit. The recorder / reproducer device includes a detachable memory card 40. The chip of the memory card chip 40 houses a flash memory (non-volatile memory), a memory control block, and a security block. The security block has an encryption chip, DES (Data Encryption Standard). According to an exemplary embodiment, the recording / reproducing apparatus may use a microcomputer instead of the DSP 30. The encoder / decoder IC 10 has an audio interface 11 and an encoder / decoder block 12. The encoder / decoder block 12 encodes digital audio data according to a highly efficient encoding method and stores the encoded data in a memory card 40. In addition, the decoder block 12 decodes the encoded data that is read from the memory card 40. The Mini-Disc technology uses a highly efficient ATRAC3 encoding method, which is a modification of ATRAC (Adaptive Transform Audio Coding). Acoustic Coding).

In the ATRAC3 format, the audio signal, sampled at 44.1kHz and quantized at 16-bit resolution, is highly efficiently encoded. In the ATRAC3 format, the minimum unit of audio data that is processed is the sound unit (SU). 1 SU is data that has been compressed from 1024 sample data (1024 x 16 bits x 2 channels) to a size of several hundred bytes. The duration of 1 SU is approximately 23 msec. In this highly efficient encoding method, the amount of audio data is compressed to an amount approximately 10 times smaller than the amount of the original data. Compared to the ATRAC1 format used in Mini-Dics media, the audio signal compressed and decompressed respectively in the ATRAC3 format deteriorates less in terms of the quality of the audio signal.

Line-in selector 13 provides selectively reproduced output from MD, tuner output, or reconstructed tape output to A / D analog to digital converter 14. A / D converter 14 processes the input signal linear to digital audio signal (sampling frequency = 44.1kHz, number of quantization bits = 16). Digital input selector 16 selectively feeds a digital output signal from an MD, CD or CS (Digital Satellite Broadcasting) to a digital input receiver 17. The digital input signal is transmitted, for example, via an optical fiber. The output from digital input receiver 17 is fed to sampling converter 15. The sampling converter 15 converts the digital input signal into a digital audio signal (sampling rate = 44.1kHz, number of quantization bits = 16).

The encoder / decoder block 12 of the audio encoder / decoder chip 10 provides the encoded data to the DES scrambler 22 via the interface 21 of the security chip 20. The DES scrambler 22 has a FIFO 23 (first in, first out). DES encryption chip 22 is positioned to protect the content copyrights. Memory card 40 also has a DES encryption chip. The DES encoder 22 of the recorder / reproducer has a plurality of master keys and a device-unique memory key. DES encoder 22 also has a random number generator. DES encryption circuit 22 may share the authentication process and session key with a memory card that includes the DES encryption circuit. In addition, DES encoder 22 may re-encrypt data using the DES encoder memory key.

The encrypted audio data, which is output to the DES scrambler chip, is then supplied to the DSP 30. The DSP 30 communicates with the memory card via an interface. In this example, the memory card 40 is mounted in a turning on / off mechanism (not shown) of the recording / reproducing apparatus. The DSP 30 stores the encrypted data in a flash memory of the memory card 40. The encrypted data is transferred serially between the DSP 30 and the memory card 40. Furthermore, an external SRAM 31 (Static Random Access Memory) is connected to the DSP 30. SRAM 31 provides the writer / reproducer with sufficient memory capacity to control the memory card 40.

A bus 32 interface is connected to the DSP 30 signal processor. Data from an external controller (not shown) is supplied to the DSP 30 signal processor via the bus 33. The external controller controls all operations of the audio system. The external controller supplies data such as a write command or a reproduction command, which is generated in response to user actions by the operation part, and is provided to the DSP 30 via the bus interface 32. In addition, the external controller provides additional information such as image information or text information to the DSP 30 via interface 32. The rail 33 is a two-way communication path. The side information, which is read from memory card 40, is provided to the external controller via DSP 30, bus interface 32, and bus 33. In fact, the external controller is located, for example, in the amplifier unit of the audio system. In addition, the external driver causes the display device to display additional information, the operating status of the recorder, and the like. The display device is shared by the entire audio chip. Since the data exchanged over the bus 33 is not copyrighted data, it is not encrypted.

The encrypted audio data that is read from the memory card 40 by the DSP 30 is decrypted by the security chip 20. The audio encoder / decoder IC 10 decodes the data encoded according to the ATRAC3 format. The output of the audio encoder / decoder 10 is provided to a D / A converter 18. The D / A converter 18 converts the output data from the audio encoder / decoder 10 to an analog signal. The analog audio signal is fed to the line signal output 19.

The analog audio signal is fed to the amplification unit (not shown) via the line signal output 19. The analog audio signal is output through the loudspeaker or headphones. The external controller supplies a mute signal to the digital to analog converter 18. When the mute signal represents the mute-on state, it means that the external driver is preventing the audio signal from appearing on the line signal output 19.

Fig. 2 is a block diagram showing the internal structure of DSP 30. Referring to Fig. 2, DSP 30 includes core 34, flash 35, SRAM 36, bus interface 37, memory card interface 40, bus bridges. Signal processor

PL 208 230 B1

The DSP 30 has the same function as a microcomputer. Core 34 is the equivalent of a CPU CPU. Flash memory 35 stores a program that instructs the DSP 30 to perform certain processes. SRAM 36 and external SRAM 31 are used as the RAM of the writer / reproducer.

DSP 30, in response to an operating signal, such as a write command, received via the bus interfaces 32 and 37, controls the process of writing scrambled audio data and additional information to the memory card 40 and controls the process of reading them from the card. In other words, the DSP 30 is sandwiched between the application software side of the audio circuit which stores / reproduces audio data and additional information, and the memory card 40. The DSP signal processor 30 operates while the memory card 40 is being accessed. In addition, the DSP signal processor 30 operates in accordance with software, such as a file system.

The DSP 30 manages the files stored on the memory card 40 using the FAT file system used in conventional personal computers. In addition to the file system, according to an embodiment of the present invention, it is possible to use a management file. The management file will be described later. The management file is used to manage the data files stored in the memory card 40. The management file, being the first file management information, is used to manage audio data files. On the other hand, the FAT file allocation table, being the second file management information, is used to manage all files, including audio data files and management files, stored in the flash memory of the memory card 40. The management file is stored in the memory card 40. . The FAT file allocation table is stored in a flash memory in the root directory, along with similar information, before the memory card 40 is shipped by sea or land. The details of the FAT file allocation table will be described later.

Referring to Fig. 6, a management method using a FAT file allocation table will be described.

Fig. 6 is a block diagram illustrating a memory map. The top area of ​​the memory map is the partition table. After the file allocation table part there is a block area, boot sector, FAT file allocation table area, FAT file allocation table copy area, root area, subdirectory area, data area. In the memory map, logical addresses have been converted to physical addresses according to the logical-physical address conversion table.

The boot sector, FAT file allocation table area, FAT file allocation table copy area, root area, subdirectory area, and data area are referred to as the FAT partition area.

The partition table contains the start addresses and end addresses of a FAT partition.

The FAT file allocation table used in conventional floppy disks does not contain such a partition table. Since the first path only contains the partition table, there is a blank space there. The boot sector includes the structure size of the FAT file allocation table (12 bit FAT file allocation table or 16 bit FAT file allocation table), the cluster size, and the size of each area. The FAT file allocation table is used to manage the position of the file stored in the data area. The FAT file allocation table backup area is the area where the FAT file allocation table backup is located. The root area contains the names of the files, the addresses of their starting clusters, and their various attributes. Root area uses 32 bytes for each file.

The subdirectory area is implemented as a subdirectory, which is a file with the directory attribute. In the embodiment shown in Figure 6, the subdirectory area has four files named PBLIST.MSF, CAT.MSF, DOG.MSF, and MAN.MFA. The subdirectory area is used to manage file names and save their entries in the FAT file allocation table. In other words, the frame with the name of the CAT.MSF file is assigned address 5 in the file allocation table. The frame with the name of the CAT.MSF file is assigned the address 10 in the file allocation table. The area after the cluster 2 is used as the data area. In this embodiment, audio data that has been compressed in the ATRAC3 format has been recorded. The highest frame named MAN.MSA is assigned address 110 in the FAT file allocation table. According to an embodiment of the present invention, the audio data together with the name of the CAT.MSF file is stored in clusters 5 to 8. The DOG-1 audio data, which is the first half of the file named DOG.MSF, is stored in clusters 10 to 12. The DOG-2 audio data, which is the second half of the file named DOG.MSF, is stored in clusters 100 and 101. The audio data with the file name MAN.MSF is stored in clusters 110 and 111.

PL 208 230 B1

In an embodiment of the present invention, a single file is described that is divided into two parts and stored in a distributed manner. In an exemplary embodiment, the area indicated as Blank in the data area is the writable area. The cluster space 200 is used for file name management. The CAT.MSF file is saved to cluster 200. The DOG.MSF file is saved to cluster 201. The MAN.MSF file is saved to cluster 202. When the file positions are changed, the area below cluster 200 is reorganized. When a memory card is connected, the beginning and end of the FAT partition area are written relative to the top of the partition table. After restoring part of the boot sector, the root area and subdirectory area are restored. In the subdirectory area, the PBLIST.MSF recovery management information frame is detected. In this way, the address of the end of the frame of the PBLIST.MSF file is obtained. In the exemplary embodiment, since address 200 has been stored at the end of the PBLIST.MSF file, a referral is made to the cluster 200.

The area below cluster 200 is used to manage the playback order of files. In an exemplary embodiment, the CAT.MSA file is the first program. The DOG.MSA file is the second program. The MAN.MSA file is the third program. After referencing to the area below cluster 200, reference is made to CAT.MSA, DOG.MSA, and MAN.MSA file frames. In Fig. 6, address 10 is assigned to the end of the frame of the DOG.MSA file. The address 110 is assigned to the start of the MAN.MSA file frame. When the entry address at address 5 is searched in the FAT file allocation table, the cluster address is obtained 6. When the entry address at address 6 is searched in the FAT file allocation table, the cluster address is obtained. FAT file allocation table, the address of the entry at address 8 is searched, then the FFF code is obtained, indicating the end. Thus, the CAT.MSA file uses clusters 5, 6, 7, and 8. After referencing clusters 5, 6, 7, and 8 in the data area, you can access the ATRAC3 data area in a file named CAT.MSA.

Next, the method of searching for the DOG.MSF file that has been saved in a distributed manner will be described. The end of the DOG.MSA file frame is assigned address 10. When an input address in a FAT file allocation table is searched at address 10, the cluster address is obtained 11. When an input address in a FAT file allocation table is searched at address 11, address 12. When an input address in the FAT file allocation table is searched from at address 12, we get address 100, and so on. When reference is made to input address 101, we get an FFF code representing the end. Thus, the DOG.MSF file uses clusters 10, 11, 12, 100, and 101. When clusters 10, 11, and 12 are referenced, the first ATRAC3 data portion of the DOG.MSF file is obtained. When the reference is made to clusters 100 and 101, the second part of the ATRAC3 data of the DOG.MSF file is obtained. In addition, when an input address is searched for at address 110 in the FAT file allocation table, cluster address 101 is obtained. When an input address is searched for at address 110 in the FAT file allocation table, an FFF code is obtained indicating the end. Thus, it is clear that the MAN.MSA file uses clusters 110 and 111. As described above, data files scattered in flash memory can be combined and sequentially recreated.

According to an embodiment of the present invention, in addition to the file management system defined in the memory card format 40, a management file is used to manage the tracks and portions of the music files. The management file is stored in the user block in the flash memory 42 of the memory card 40. Thus, as will be described below, even if the FAT file allocation table of the memory card 40 is destroyed, the file can be recovered.

According to an embodiment of the present invention, to protect the copyright of the data, the audio data that has been compressed according to the ATRAC3 encoding format is encrypted. At the same time, since there is no need to protect the copyright of the management file, the file is not encrypted.

The management file is generated by the DSP signal processor 30. When the recorder / player is powered on, the DSP signal processor 30 determines whether the memory card 40 is connected to the recorder / player or not. When the memory card is connected, DSP signal processor 30 authenticates memory card 40. When DSP signal processor 30 positively authenticates memory card 40, it reads flash memory boot block 42. In this way, the DSP 30 reads the physical-logical address conversion table and stores the read data in the SRAM. The FAT file allocation table and the root directory are saved in the pa12 flash memory

The memory card 40 is stored before the memory card 40 is sent to the end user. When data is written to memory card 40, a management file is generated.

In other words, a write command issued by a user external controller, or the like, is provided to the DSP 30 from the external controller via the bus and the bus interface 32. The encoder / decoder IC 10 compresses the received audio data and provides the resulting ATRAC3 data to the protection circuit IC. 20. Security chip IC 20 scrambles ATRAC3 data. ATRAC3 encrypted data is saved in flash memory 42 of memory card 40. Then, the FAT file allocation table and the management file are updated. Each time a file is updated (in fact, each time the audio data writing process is completed), the FAT file allocation table and management file that reside in SRAMs 31 and 36 are rewritten. When the memory card 40 is removed or the recorder / player is powered off, the FAT file allocation table and the management file that are delivered from the SRAM 34 and 36 are written to the flash memory 42. Alternatively, each time the data writing process is performed audio, FAT file allocation table and management file which are already stored in flash memory 42 can be written there again. When the audio data is edited, the content of the management file is updated.

In the data structure according to the embodiment, additional information is included in the management file. The supplementary information is updated and stored in flash memory 42. In another management file data structure, in addition to the track management file, a supplemental information management file is generated. The additional information is provided from the external controller to the DSP 30 via the bus and bus interface 32. The note information is stored in the flash memory 42 of the memory card 40. As the note information is not supplied to the security chip IC 20, it is not encrypted. When the memory card 40 is disconnected from the recorder / player or its power is turned off, additional information is written from the SRAM memory of the DSP 30 to the flash memory 42.

Fig. 7 is a block diagram showing the file structure of memory card 40. In the file structure, there are: photo directory, movie directory, voice recording directory, control directory, music directory (HIFI). According to an exemplary embodiment, music programs are recorded and played back. The music catalog will be described below. The music directory contains two types of files. The first type is the PBLIST.MSF recovery management file (hereinafter referred to as PBLIST). The second type is the ATRAC3 A3Dnnnn.MSA data file which stores encrypted music data. The music directory can store up to four hundred ATRAC3 files (namely 400 music programs). ATRAC3 data files are registered in the playback management file and are generated by the recorder / player.

Fig. 8 is a block diagram showing a structure of a playback management file. Fig. 9 is a block diagram showing the structure of an ATRAC3 data file. The recovery management file is a fixed-length 16KB file. For each music program, an ATRAC3 data file is made up of an attribute header area and an encrypted data area. The attribute data has a fixed length of 16KB. The structure of the attribute header is similar to that of the recovery management file.

The playback management file shown in Fig. 8 is composed of a header, the name of the NM-1S memory card (for a single byte code), the name of the NM2-S memory card (for a double byte code), the play sequence table of TRKTBL programs, and the additional information of the INF memory card. S. The attribute header (shown in Fig. 9) is at the beginning of the data file and is built of header, NM1 program name (for single byte code), NM2 program name (for double byte code), TRKINF path information (such as path key information), PRTINF part information, and additional information about the INF path. The header contains information on the total number of 'parts', the name attribute, the size of the additional information, and the like.

The attribute data is followed by the ATRAC3 music data. The music data is grouped in blocks of 16KB each. Each block begins with a header. The header contains the initial value used to decrypt the encrypted data. Only the music data in the ATRAC3 data file is encrypted. Thus, other data such as the playback management file, header, and the like information are not encrypted.

Next, with reference to Figs. 10A to 10C, the relationship between music programs and ATRAC3 data files will be described. One track corresponds to one music program. Moreover, one music program is made up of one ATRAC3 data (see

Fig. 9). An ATRAC3 data file is an audio data file that has been compressed according to the ATRAC3 format. The ATRAC3 data file is stored in the memory of memory card 40 as a cluster. One cluster has a capacity of 16KB. The set of files is not written to a single cluster. The minimum unit of data that can be erased from flash memory 42 is one block. In the case of memory card 40 for music data, a block is synonymous with a cluster. Moreover, one cluster is equivalent to one sector.

A single music program is essentially made up of one part. However, when a music program is edited, then a single music program may have multiple parts. A 'part' is a unit of data that is written successively. Normally one track consists of one 'part'. The combination of a part of a music program is made using the information about the PRTINF ( part information PRTINF), contained in the attribute header of each music program. In other words, the size of the 'part' is represented by the 'part size PRTSIZE' (4 bytes) in the 'PRTINF part information'. The first two bytes of the 'PRTSIZE part size' correspond to the total number of clusters of the current part. The next two bytes correspond to the position of the 'start sound unit (SU)' and the 'end sound unit (SU)' of the starting and ending clusters, respectively. Hereinafter, 'sound unit' is abbreviated as SU. With such a part record, when the music data is edited, the movement of the music data can be canceled. When the music data is edited for each block, although its movement may be canceled out, the block editing unit is much larger than the SU editing unit.

'SU unit' is the minimum unit of 'parts'. Moreover, the SU unit is the minimum data unit in the case where the audio data is compressed according to the ATRAC3 format. A single 'SU unit' is audio data consisting of 1024 samples taken at 44.1kHz (1024x16bitx2channels) and compressed to approximately 10 times the size of the original data. The duration of one 'SU unit' is approximately 23 [msec]. Typically, one 'part' is made up of several thousand 'SU' units. When one cluster is composed of 42 SU units, then one cluster is capable of generating a sound of 1 second. The number of 'parts' making up one track depends on the size of the additional information. Since the number of 'parts' is obtained by subtracting the header, program name, supplemental data, and the like from one block, when no additional information is available, the maximum number of parts (645 parts) may be used.

Fig. 10A is a block diagram illustrating a file structure in the case where two music programs derived from CD or the like are successively recorded. The first program (file 1), for example, consists of five clusters. Since one cluster cannot contain two files, the first program and the second program, file 2 starts at the beginning of the next cluster. So the end of the 'part 1' corresponding to file 1 is in the middle of one cluster and the rest of the cluster area contains no data. Likewise, the second music program (file 2) is made up of one 'part'. For file 1, the size of the 'part' is 5. The first cluster starts with a zero SU. The last cluster ends with the fourth SU.

There are four types of editing operations which are, split process, merge process, delete process, and move process. The splitting process is performed to divide the track into two parts. When the dividing process is performed, the total number of tracks is increased by one. In the splitting process, one file is split into two files in the file system. So in this case, the playback management file and the FAT file allocation table are updated. The combining process is performed to merge the two paths into one. When the combining process is performed, the total number of tracks is reduced by one. In the linking process, two files are joined together to form one file on the file system. Thus, when the merging process is performed, the reproduction management file and the FAT file allocation table are updated. The deletion process is performed to delete the path. The total number of tracks is reduced by one after a track is deleted. The move process is performed to change the sequence of the tracks. Thus, during the execution of the delete or move process, the recovery management file and the FAT file allocation table are updated.

Fig. 10B is a block diagram illustrating the result of combining two programs (file 1 and file 2) shown in Fig. 10A. As a result of the linking process, the linked file consists of two 'parts'. Fig. 10C is a diagram showing a split result in which one file

(File 1) has been split in the middle of cluster 2. As a result of the split process, file 1 consists of two clusters 0, 1 and the initial part of cluster 2. File 2 consists of the final part of cluster 2 and clusters 3 and 4.

As mentioned above, in accordance with an embodiment of the present invention, since the notation of 'parts' is defined, as a result of combining (see Fig. 10B) the start position of' part 1 ', the end position of the' part 1 ', and the end position' lots 2 'can be identified by' SU units'. Thus, in order to use the resulting merging space, there is no need to move the music data of 'part 2'. Moreover, as a result of the division (see Fig. 10C) there is no need to move the data and occupy the space at the beginning of the file 2.

Fig. 11 is a block diagram detailing the data structure of a PBLIST recovery management file. Fig. 12A and 12B show the header part and the remainder of a PBLIST recovery management file. The size of the recovery management file is one cluster (one block = 16KB). The size of the header shown in Fig. 12A is 32 bytes. The remainder of the PBLIST recovery management file shown in Fig. 12B contains NM1-S name area (256 bytes) (for memory card), NM2-S name area (512 bytes), content key area, MAC area, S-YMDHMS area, TRKTBL playback sequence management table area (800 bytes), an additional information area of ​​the IF-S memory card (12720 bytes), and a header overflow information area. The start positions of these areas are defined in the recovery management file.

The first 32 bytes (0x0000) to (0x0010) shown in Fig. 12A are used for the header. In the file, 16 byte areas are marked as 'frames'. Referring to Fig. 12A, header is placed in the first and second frames. The header contains the following areas. The area marked as Reserved is the undefined area. Typically, zero values ​​(0x00) are stored in the reserved area. However, even if there is data stored in the reserved area, the data written in the reserved area is ignored. In future versions, some reserved areas may be used. In addition, it is forbidden to write data in reserved areas. When an optional area is unused, it is treated as a reserved area.

= BLKID-TL0 (4 bytes)

Meaning: Block ID, File ID

Function: Identifies the beginning of the playback management file.

Value: Constant value = TL = 0 (for example, 0x544C2D30).

= MCode (2 bytes)

Meaning: Manufacturer's code

Function: Identifies the manufacturer and model of the recorder / player.

Value: the most significant 10 bits (manufacturer's code); 6 minor bits (model code).

= REVISION (4 bytes)

Meaning: The number of records of the PBLIST file made

Function: Increased each time the playback management file is rewritten.

Value: starts at 0 and increases by 1.

= S-YMDHMS (4 bytes) (Optional)

Meaning: year, month, day, hour. Minute, second recorded by a recorder / player with a suitable clock.

Function: Identifies the date and time of the last save.

Value: Bits 25 to 31: Year 0 to 99 (1980 to 2079)

Month 0 to 12 Days 0 to 31

Hour 0 to 23 Minute 0 to 59 seconds 0 to 29 (two-bit space).

bits 25 to 31 bits 21 to 24 bits 16 to 20 bits 11 to 15 bits 05 to 10 bits 00 to 04 = SY1C + L (2 bytes)

Importance:

Function:

Value:

00:

Name attribute (one byte code) of the memory card, stored in the NM1-S area. represents character code and language code as one byte code Character code (C): one most significant byte

No character code, binary number

PL 208 230 B1

01: ASCII (American Standard Code for Information Interchange)

02: ASCII + KANA

03: Modified 8859-1

81: MS-JIS

82: KS C 5601-1989

83: GB (UK) 2312-80

S-JIS (Japanese industry standard) (for voice coding).

Language code (L): least significant byte, Identifies the language based on the EBU Tech 3258 standard,

00: No settings,

08: German

09: English

0A: Spanish

0F: French

15: Italian

1D: Dutch

65: Korean

69: Japanese

75: Chinese

When data is not written, this area is filled with zeros. = SN2C = L (2 bytes)

Importance:

Function:

Value:

= SINFSIZE

Importance:

Function:

Value: = T-TRK (2 bytes) Meaning: Function: Value:

Memory card name attribute in NM2-S area.

represents character code and language code as a one-byte code. same as for SN1C + L (2 bytes)

Total size of the additional information in the INF-S area of ​​the memory card.

represents the size of the data, incremented every 16 bytes. When data is not written, this area is filled with zeros.

Size: 0x0001 to 0x39C (924) = VerNo

Importance

Function:

Value:

Total number of tracks. represents the total number of paths.

to 0x0190 (Maximum 400 tracks) when no data is written this area is filled with zeros.

(2 bytes)

Format version number.

represents the major version number (high order byte) and supplemental version number (minor byte)

0x0100 (version 1.0)

0x0203 (version 2.3)

The regions (see Fig. 13B) that follow the header will be described below.

= NM1-S

Name of the memory card (as a one-byte code)

Represents the name of the memory card as a single-byte code (up to 256). At the end of this area, the end code (0x00) is written. The size is counted from the end code. When data is not written, zero values ​​(0x00) are written from the beginning of this area (0x0020) in at least one byte.

various types of character codes.

Importance

Function:

Value:

= NM2-S

Importance

Function:

Name of the memory card (as a two-byte code)

Represents the name of the memory card as a two-byte code (up to 512). At the end of this area, the end code (0x00) is written. The size is counted from the end code. When data is not saved, from

At the beginning of this area (0x0120), zero values ​​(0x00) are stored in at least two bytes.

Value: various character codes.

= CONTENT KEY:

Importance:

Function:

Value:

= MAC

Importance:

Function:

Value:

= TRK-nnn

Importance:

Function:

Value:

= INF-S

Importance:

Value corresponding to a music program. Secured with the use of MG (M) and memorized. Same as CONTENT KEY. used as a key to calculate the MAC for S-YMDhms. 0 to 0xFFFFFFFFFFFFFFFF Control value of falsified copyright information.

Represents the value generated using S-YMDhms and the content key.

0 to 0xFFFFFFFFFFFFFFFF

The SQN (sequence) number of the ATRAC3 data file being restored.

Represents the FNo TRKINF number.

1 to 400 (0x190)

Value:

= S-YMDhms

Importance:

Value:

Additional information on the memory card (for example, information regarding photos, songs, guides, and the like).

Function: Represents variable length additional information along with the header.

Many types of additional information may be used. Each type of additional information has its own ID and size. Each side information area comprises a header composed of at least 16 bytes and multiples of 4 bytes. Details are presented in the next section.

Compare with the contents of the item Data structure of the additional information.

(4 bytes) (Optional) year, month, day, hour. Minute, second recorded by a recorder / player with a suitable clock. Function: Identifies the date and time of the last save. For EMD, this area is mandatory. bits 25 to 31: Year 0 to 99 (1980 to 2079) bits 21 to 24: Month 0 to 12 bits 16 to 20: Day 0 to 31 bits 11 to 15: Hour 0 to 23 bits 05 to 10: Minute 0 to 59 bits 00 to 04: second 0 to 29 (two-bit space)

In the last frame of the playback management file, the same values ​​as in the header are written: BLKID-TL0, MCode, VERIFICATION.

When data is being written to the memory card, the card may be accidentally or unintentionally disconnected, or the power of the recorder / player may be turned off. When such inappropriate operation is performed, an error should be detected. As described above, the VERIFICATION area is placed at the beginning and end of each block. Each time data is rewritten, the VERIFICATION value is increased. If the defective termination occurs somewhere in the middle of a block, the value of the VERIFICATION area at the beginning will not match the value of the VERIFICATION area at the end of the block. Thus, such a faulty termination can be detected. As there are two areas of VERIFICATION, abnormal termination can be detected with high probability. When an abnormal termination is detected, an alarm such as an error message is generated.

Moreover, since the fixed value BLKID-TL0 is stored at the beginning of one block (16KB), in case of destruction of the FAT file allocation table, the fixed value is used as a reference for the recovered data. In other words, by referring to a constant value, it is possible to determine the file type. Since the constant BLKID-TL0 is stored redundantly in the header and tail of each block, operational reliability can be ensured. Alternatively, the same playback management file may be redundantly written.

PL 208 230 B1

The amount of data in the ATRAC3 data file is much larger than that contained in the recovery management file. In addition, the block number BLOCK SERIAL is added to the ATRAC3 data file as will be described later. However, since many ATRAC3 files are stored on the memory card, both CONNUM0 and BLOCK SERIAL are used to prevent redundancy. Otherwise, if the FAT file allocation table was destroyed, it would be difficult to recover the file. In other words, a single ATRAC3 data file may be composed of multiple blocks that are separately written. The CONNUM0 area is used to identify blocks belonging to the same file. In addition, the BLOCK SERIAL area is used to identify the order of blocks in the ATRAC3 data file.

Similarly, at the beginning and at the end of each block, the manufacturer's code (Mcode) is redundantly written, so that in the case where the file was incorrectly recorded, in a situation where the file allocation table has not been destroyed, the manufacturer and the device model are identified.

Fig. 12C is a block diagram showing the data structure of the side information. The additional information is composed of the following header and variable length data. The header has the following areas.

= INF

Meaning: Field identifier, FIELD ID

Function: Represents the beginning of additional information (constant value).

Value: 0x69 = ID

Meaning: additional information key code.

Function: Represents a category of notes.

Value: 0 to 0xFF = SIZE

Meaning: the size of each additional information.

Function: Represents the size of each type of additional information. Nevertheless, the size of the data is not limited, it should be at least 16 bytes and a multiple of 4 bytes. The rest of the data should be filled with zeros (0x00).

Value: 16 to 14784 (0x39C0) = MCode

Meaning: Manufacturer's code

Function : It identifies the manufacturer and model of the recorder / player.

Value: the most significant 10 bits (manufacturer's code); Less significant 10 bits (device code).

= C + L

Meaning: Character attribute in the data area starting with the 12th byte.

Function: Represents a character code and language code as a single-byte code.

Value: Same as SNC + L = DATA

Meaning: individual additional information.

Function: Represents any type of additional information with variable-length data.

The actual data starts with the 12th byte. The length (size) of the actual data should be at least 4 bytes and a multiple of 4 bytes. The rest of the data area should be filled with zeros (0x00).

Value: Individually defined, corresponding to the content of each type of additional information.

Fig. 13 is a table that links the most important code values ​​(0 to 63) of the side information with its type. Code values ​​(0 to 31) are assigned to character music information. Code values ​​(32 to 63) are assigned to URLs (Uniform Resource Locator) (network information). Music character information and URL information contain character information regarding album title, artist name, CM, and the like additional information.

Fig. 14 is a table that links the code values ​​(64 to 127) of the side information with their types. Code values ​​(64 to 95) are assigned to track / other. The code values ​​(96/127) are assigned to the numerical control data. For example, ID = 98 corresponds to the TOC-ID which is additional information. TOC-ID represents the first music program number, the last music program number, the current music program number, the total recording time,

The current duration of the music program corresponding to the TOC information for a CD (Commpact Disk).

Fig. 15 is a table that links the code values ​​(128 to 159) of the side information with their types. Code values ​​(128 to 159) are assigned to the synchro recovery information. In Fig. 15, EMD means a method of distributing music in electronic form.

Examples of actual additional information will be described below with reference to Figs. 16A to 16E. Like Fig. 12C, Fig. 16A shows the data structure of the additional information. In Fig. 16B the code value ID = 3 (artist name as additional information). SIZE = 0x1C (28 bytes) corresponds to the length of the additional information including the header 28 bytes; C + L indicates the type of character code C = 0x01 (ASCII code), and the language code L- = 0x09 (English language). Variable-length data after byte 12 contain single-byte SIMON & GRAFUNKEL data corresponding to the contractor's name. Since the additional information data length should be a multiple of 4 bytes, the rest of the data is filled with zeros (0x00).

In Fig. 16C, the code value ID = 97 indicating that the additional information is ISRC (International Standard Code). SIZE = 0x14 (20 bytes) corresponds to the side information data length of 20 bytes. C = 0x00 and L = 0x00 indicate that the character code type and language have not been set. So the data is in binary code. Variable-length data is an eight-byte ISRC that represents copyright information (country, copyright owner, year recorded, serial number).

In Fig. 16D the ID code value is 103 indicating that the additional information is date and time of recording. SIZE = 0x10 (16 bytes) corresponds to the side information length of 16 bytes. C = 0x00 and L = 0x00 indicate that the character code and language have not been set. Variable-length data is a four-byte (32-bit) code representing the date and time of recording (year, month, day, hour, minute, second).

In Fig. 16E the code value ID = 107 indicating that the additional information is a play register. SIZE = 0x10 (16 bytes) corresponds to the side information data length of 16 bytes. C = 0x00 and L = 0x00 indicates that the character code and language have not been selected. Variable-length data is a four-byte code representing the playback log (year, month, day, hour, minute, second). While the recorder / player has a play log keeping function, it saves 16 byte data each time it plays music data.

Fig. 17 is a block diagram showing the data structure of the ATRAC3 data file A3Dnnnn in the case where one SU is N bytes (e.g., N = 384 bytes). Fig. 17 shows an attribute header (1 block) of a data file and a music data file (1 block). Figure 17 shows the first byte (0x0000 to 0x7FF0) of each frame of two blocks (16x2 = 32 kilobytes). As shown in Fig. 18, the first 32 bytes of the attribute header are used as header; 256 bytes are used as the NM1 music program area (256 bytes); and 512 bytes the title area of ​​NM2 music program (512 bytes) is used. The header of the attribute header includes the following areas.

= BLKID-HD0 (4 bytes)

Meaning: FIELD ID, BLOCK ID

Function: Identifies the beginning of an ATRAC3 data file.

Value: constant value = HD = 0 (for example, 0x48442D30) = MCode (2 bytes)

Meaning: MANUFACTURER CODE

Function: Identifies the manufacturer and model of the recorder / player.

Value: Most Significant 10 bits (manufacturer code); Least Significant 6 Bits (Device Code).

= BLOCK SERIAL (4 bytes)

Meaning: serial number of the track

Function: starts at 0 and increases by 1. Even if the music program is being edited, this value does not change.

Value:

= N1C + L Meaning Function: Value:

up to 0xFFFFFFFFFFFFFFFF (2 bytes) represents the data attributes (NM1) of the track (music program title). represents character code and language code for NM1 as a single-byte code. same as for SN1C + L

PL 208 230 B1

<td>= N2C + L Meaning: Function: Value: = INFSIZE Importance: Function:</td><td>(2 bytes) represents the track data (NM2) attributes (music program title). represents character code and language code for NM1 as a single-byte code. same as for SN1C + L (2 bytes) the total size of the notes for the current track. represents the size of the data in multiples of 16 bytes. When data is not written, this area should be filled with zeros.</td>

<td>Value: = T-PRT Importance: Function:</td><td>0x0000 to 0x3C6 (966) (2 bytes) Total number of bytes. represents the number of 'parts' that make up the current path. Normally the value of T-PRT is 1.</td>

<td>Value: = T-SU Importance: Function:</td><td>1 to 285 (645) (4 bytes) Total number of SU units. Represents the total number of SU in one path that corresponds to the program recovery time.</td>

<td>Value: = INX Importance: Function:</td><td>0x01 to 0x001FFFFF (2 bytes) (Optional) INDEX relative position. Used as an indicator that represents the beginning of a 'part' that is representative of a music program. The INX value is determined by the value of the current number of SU units, divisible by four, corresponding to the current program location. The INX value is equivalent to four times the length of the SU unit (approximately 93 msec).</td>

<td>Value: = XT Importance: Function:</td><td>0 to 0xFFFF (approximately 6084 seconds maximum). (2 bytes) (Optional) index recovery time. denotes the recovery time of the INDEX as specified by Inx-nnn in values ​​where the SU number is divisible by 4. The INX value is equivalent to four times the SU unit (about 93msec).</td>

<td>Value:</td><td>0x0000 (no settings); 0x01 to 0xFFFE (up to 6084 seconds); 0xFFFF (to the end of the music program).</td>

The title areas of the NM1 and NM2 = NM1 program will be described below

<td>Importance: Function:</td><td>A string of characters that identifies the title of the music program. Represents the title of a music program as single-byte (up to 256 characters) (variable length) codes. The title area should be padded with an end code (0x00). The size should be calculated based on the position of the end code. When data is not written, zero (x00) should be written in at least one byte at the beginning (0x0020) of the area.</td>

<td>Value: = NM2 Importance: Function:</td><td>Various character codes. A string of characters that identifies the title of the music program. Represents the title of a music program as double-byte (up to 512 characters) (variable length) codes. The title area should be padded with an end code (0x00). The size should be calculated based on the position of the end code. When data is not written, zero (x100) should be written in at least two bytes at the beginning (0x0120) of the area.</td>

<td>Value:</td><td>Various character codes.</td>

80-byte data starting with a fixed address (0x320) in the attribute header is marked as TRKINF path information area. This area is mainly used for the overall management of security information and copy control information. Figure 19 shows part of a TRKINF. The TRKINF area includes the following areas.

PL 208 230 B1 = CONTENT KEY (8 bytes)

Importance:

Function:

Value:

= MAC

Importance:

Function:

Value for each music program. The content key value is protected in the security block of the memory card and then stored. Used as a key to play a music program. It is used to calculate the MAC value.

to 0xFFFFFFFFFFFFFFFF Check value for falsified copyright information. Represents a value generated using multiple TRKINF values, including cumulative content numbers and a secret sequence number.

The secret sequence number is the sequence number stored in the secret area of ​​the memory card. A recorder without copyright protection cannot read data in the secret area of ​​the memory card. On the other hand, a recorder with copyright protection and a computer with a program that can read data from a memory card may have access to a secret area.

= A (1 byte) Meaning: Function: Value:

'parts' attribute.

Represents information such as the 'part' compression mode.

Details will be provided below (see Figures 19 and 20). The values ​​of area A will be described below. In the following description, mono mode (N = 0 or 1) has been defined as a special combined mode where bit 7 = 1, subsignal = 0, main signal = (L + R). A player without copyright protection may ignore the information in bits 2 and 1.

Bit 0 of area A represents information that specifies the on / off state. Bit 1 of area A represents playback skip or normal playback information. Bit 2 of area A represents data type information such as audio data, facsimile data, and the like. Bit 3 of area A is not defined. As Fig. 20 shows, ATRAC3 mode information is defined using a combination of bits 4, 5, and 6. In other words, N is a three-bit mode value. For the five modes that are mono (N = 0 or 1), the bullets are LP (N = 2), SP (N = 4), EX (N = 5), and HQ (n = 7), the duration of the recording (only 64MB memory card), data transmission rate, number of SU units per block. The number of bytes per SU depends on the mode. The number of SU bytes in mono mode is 136 bytes. The number of bytes in SU in LP mode is 192 bytes. The number of bytes in SU in SP mode is 304 bytes. The number of bytes in SU in EX mode is 384 bytes. The number of bytes in SU in HQ mode is 512 bytes. Area A bit 7 represents ATRAC3 modes (0: double, 1: combined).

For example, an example 64MB memory card using SP mode will be described. The 64 megabyte memory card has 3968 blocks. In the SP mode, since 304 bytes correspond to SU, one block contains 53 SUs. The SU unit is the equivalent of (1024/44100) seconds. So one block is (1024/44100) x53x (3968-10) = 4863 seconds = 81 minutes. The transmission rate is (44100/1024) x304x8 = 104 737 bps.

= LT (one byte)

Meaning: marker of restriction of restoration (bits 7 and 6) and of the protection partition (bits 5 to 0).

Function: Represents information about restrictions on the use of the current path.

Value: bit 7: 0 = no restriction, 1 = restriction, bit 6: 0 = current, 1 = expired bit 5 to 0: protection partition (playback forbidden, other than 0) = FNo (2 bytes)

Meaning: File number.

Function: Represents an initially stored track number that specifies the location of the MAC computed value stored in the secret area of ​​the memory card.

Value: 1 to 0x190 (400) = MG (D) SERIAL-nnn (16 bytes)

Meaning: Represents the serial number of the safety block (security chip

IC 20) recorder / player.

PL 208 230 B1

<td>Function: Value: = CONNUM Importance: Function:</td><td>Unique value for each recorder / player. 1 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (4 bytes) Cumulative content number. Represents a unique cumulative value for each music program.</td>

The value is used by the recorder / player protection block. The upper limit of the value is 2³²that is 4,200,000,000. It is used to identify the recorded

<td>gram. Value: = YMDhms-S Importance:</td><td>1 to 0xFFFFFFFF (4 bytes) (Optional) Date and time of playback start and duration of the track, including playback restrictions.</td>

<td>Function:</td><td>Represents the date and time for which data playback is allowed under EMD (electronic music distribution).</td>

<td>Value: = YMDhms-E Importance:</td><td>Same as date and time notation in other examples. (4 bytes) (Optional) Date and time for playback end and duration of the track, including playback restrictions.</td>

<td>Function:</td><td>Represents the date and time for which the recovery right for the EMD has expired.</td>

<td>Value: = MT Importance: Function: Value: = CT Importance: Function:</td><td>Same as date and time notation in other examples. (1 byte) (Optional) Maximum number of plays allowed. Represents the maximum number of plays allowed by the EMD. 1 to 0xFF. When not used, the value of the MT area is 00. (1 byte) (Optional) Number of plays. Represents the number of plays, which is included in the number of plays allowed. Each time data is played back, the value of the CT area is decreased.</td>

<td>Value:</td><td>0x00 to FF. When not used, the value of the CT area is 0x00. When bit 7 of the LT area is set to 1 and the value of the CT area is 00, data cannot be restored any more.</td>

<td>= CC Importance: Function: Value:</td><td>(1 byte) COPY CONTROL - Copy control. controls the copy operation. Bits 6 and 7 represent copy control information. Bits 4 and 5 represent information controlling high speed digital copying operation. Bits 2 and 3 represent the security block authorization level. Beats 0 and 1 are undefined.</td>

Example of a CC value

<td>(bits 7 and 6) 11: 01: 00: (bits 3 and 2) 00:</td><td>unlimited copying operation. copying prohibited. once copy operation allowed. recording with analog / digital input. The MG authorization level is 0.</td>

When the digital save operation being performed is using CD-derived data, (bits 7

<td>and 6): 00 and (bits 3 and 2): 00. = CN Importance:</td><td>(1 byte) (Optional) Number of copies allowed for the serial copy management system</td>

<td>Function:</td><td>speed at high speed Extension of copying rights by the number of copies, not limited to</td>

One-time copying, and free copying license. Only valid when the first copy is generated. The value in the CN area is decreased each time a copy operation is performed.

Value: 00: copying prohibited.

up to 0xFE: number of times 0xFF: unlimited number of times.

After the TRKINF path information area, there is a 24 byte "parts" management information area (PRTINF) starting at 0x0370. When one track is built up of multiple 'parts', the PRTINF area values ​​for the individual parts are arranged successively on the timeline. Fig. 22 shows a portion of the PRTINF area. In the following, the areas in the PRTINF area will be described in the order in which they are arranged.

= PRTSIZE (4 bytes)

Meaning: Size of the 'part'.

Function: Represents the size of the 'part'. Cluster: 2 bytes (highest position), SU starting unit: (1 byte), SU ending unit (lowest position)

Value: clusters 1 to 0x1F40 (8000) start SU unit: 0 to 0xA0 (160) end SU unit: 0 to 0xA0 (16) (note that SU units start at 0).

= PRTKEY (8 bytes)

Meaning: The 'parts' scrambling value.

Function: Lets you encrypt the 'part'.

Initial value = 0. Note that editing rules apply.

Value: 0 to 0xFFFFFFFFFFFFFFFF = CONNUM0 (4 bytes)

Meaning: Initially generates a key for cumulative content.

Function: Uniquely identifies the content ID.

Value: Same values ​​as the key values ​​of the initial cumulative content value.

As shown in FIG. 17, the ATRAC3 data file attribute header includes additional INF information. The side information is the same as the side information INF-S (see Figs. 11 and 12B) of the playback management file except that the start position is not fixed. Below the last byte position (a multiple of four) at the end of one or more parts is the additional information INF data.

= INF

Additional information about the path.

Represents variable length additional information along with the header. It may contain a lot of additional information of different types. Each of the additional information areas has an ID and data specifying its size. Each side information area is made up of at least 16 bytes and has a length of a multiple of 4 bytes.

same as INF-S info file for playback management file.

The attribute header described above is followed by data for each block of the ATARC3 data file. As shown in Fig. 23, header is added to each block. The data of each block will be described below.

= BLKID-A3D (4 bytes)

Importance:

Function:

Value:

Meaning: Block ID, File ID.

Function: Identifies the start of the ATRAC3 data.

Value: Constant value = A3D (for example, 0x41334420).

= MCode (2 bytes)

Meaning: Manufacturer's code

Function: Identifies the manufacturer and model of the recorder / player.

Value: Most Significant 10 bits (manufacturer code); Least Significant 6 (model code).

= CONNUM0 (4 bytes)

Meaning: Cumulative number of initially created content.

PL 208 230 B1

Function: Indicates a unique ID for the content. Even while the content is being edited, the value of CONNUM0 does not change.

Value: Same as the starting key of the cumulative content.

= BLOCK SERIAL (4 bytes)

Meaning: serial number of each track.

Function: starts at 0 and increases by 1. Even if the music program is being edited, the BLOCK SERIAL value does not change.

Value: 0 to OxFFFFFFFF = BLOCK-SEED (8 bytes)

Meaning: The key for encrypting one block.

Function: The start of block is a random number generated by the recorder / player protection block. The random number is followed by the value incremented by 1. When the value of the BLOCK-SEED area is lost, ie when no sound is generated for about one second, which corresponds to one block, the same data is written to the header and at the end of the block. Even when the content is edited, the BLOCK-SEED value does not change.

Value: Initial 8-bit random number.

= INITIALIZATION VECTOR (8 bytes)

Meaning: Value necessary to encrypt / decrypt ATARC3 data.

Function: Represents the start value necessary to encrypt and decrypt ATRAC3 data for each block. The block starts at 0. The next block starts at the last eight-bit encrypted value in the last SU. When a block is split, the last eight bytes just before the starting SU are used. Even if the content is edited, the value of the INITIALIZATION VECTOR area does not change.

Value: 0 to 0xFFFFFFFFFFFFFFFF = SU-nnn

Meaning: Data of the sound unit.

Function: representation of compressed data from 1024 samples. The number of bytes in the output depends on the compression mode. Even when the content is edited, the SU-nnn area value does not change.

Value: ATRAC3 data values.

In Fig. 17, since N = 384, 42 SU are stored in one block. The first two frames (4 bytes) of one block are used for the header. In the last frame (two bytes), the areas BLKIS-A3D, MCode, CONNUM0, and BLOCK SERIAL are redundant. So the M bytes of the remaining area are (16.384 - 384x42 - 16x3 = 208) bytes. As shown above, the BLOCK SEED eight byte area is redundant.

When an area of ​​the file allocation table is destroyed, all flash memory blocks are searched. It is determined whether the values ​​of the BLKID (block identifier) ​​at the beginning of each block are TL0, HD0 or A3D. As shown in Figs. 24A through 24C, in step SP1, it was determined whether the value of the BLKID area at the beginning of the peak block was BLKID-TL0 or not. When the result determined in step SP1 is: No, goes to step SP2. In step SP2, the block number is incremented. Then, in step SP3, it is determined whether the last block has been searched or not.

When the result obtained in step SP3 is negative No, it returns to step SP1.

When the result obtained in step SP1 is positive, it goes to step SP4. In step SP4, it is determined whether or not searched block is a PBLIST recovery management file. Then, it goes to step SP5. In step SP5, the total number of T-TRK tracks in the PBLIST recovery management file is stored as N in the register. For example, when 10 ATRAC3 data files (10 music programs) are stored in memory, the number 10 is stored in the T-TRK value.

With respect to the value of the total number of tracks T-TRK, subsequent blocks TRK-001 to TRK-400 are referenced. In this example, since 10 music programs are stored, reference is made to blocks TRK-001 through TRK-010. Since the number of FNO files is stored in TRK-XXX (where X = 1 to 400) in step SP7, the table that connects nu24 is written to the memory.

TRK-XXX track mer with FNO file number. Then, in step SP8, the N stored in the register is reduced. A loop composed of steps SP6, SP7 and SP8 is executed until N = 0 in step SP9.

When the determined result in step SP9 is positive, i.e. Yes, it goes to step SP10. In step SP10, the indicator is reset to zero and points to the top block. The search process is repeated starting at the top block. Then it goes to step SP11. In step SP11, it is determined whether the BLKID value of the peak block is BLKID-HD or not. When the obtained result in step SP11 is negative No, it goes to step SP12. In step SP12, the block number is incremented. In step SP13, it is determined whether the last block has been searched or not.

When the obtained result in step SP13 is No, it goes to step SP11. The searching process is repeated until the result obtained in step SP11 is Yes.

When the result of step SP11 is Yes, it goes to step SP14. In step SP14, it is determined if the block is an attribute header (see Fig. 8) (0x000 to 0x03FFF of Fig. 18) at the beginning of an ATARC3 data file.

Then, in step SP15, with respect to the FNO file number, the BLOCK SERIAL sequence number of the same ATRAC data file and the cumulative content key CONNUM0 contained in the attribute header are stored in the memory. When 10 ATRAC3 data files are stored, since there are 10 blocks with BLKID area values ​​of the peak BLKID-TLO block, the search process continues until all 10 blocks have been searched.

When the result determined in step SP13 is Yes, it goes to step SP16. In step SP16, the indicator is reset to zero and set to the top block. The search process is repeated from the top block.

Then, it goes to step SP17. In step SP17, it is determined whether the value of the BLKID area of ​​the peak block is BLKID-A3D or not.

When the result obtained in step SP17 is No, it goes to step SP18. In step SP18, the block number is increased. Then, in step SP18 ', it is determined whether or not the last block has been searched. When the result of step SP18 'is No, it returns to step SP17.

When the result determined in step SP7 is Yes, it goes to step SP19. In step SP19, it is determined whether the block contains ATRAC3 data. Then a transition to step SP20 is made. In step SP20, the following are stored in the memory: the BLOCK SERIAL serial number stored in the ATRAC3 data block and CONNUM0 cumulative content key.

In the same ATRAC3 data file, a common number is assigned to CUNNUM0 of the cumulative content key. In other words, when one ATRAC3 data file is made up of 10 blocks, a common number is assigned to all CONNUM0 area values.

In addition, when one ATRAC3 data consists of 10 blocks, values ​​in the BLOCK SERIAL areas of 10 blocks are assigned serial numbers 1 through 10.

With respect to the values ​​of the areas CONNUM0 and BLOCK SERIAL, it is determined whether the current block is the same content, and the sequence of reproducing the current block with the same content (namely, a linking sequence) is determined.

When 10 ATRAC3 data files (namely 10 music programs) have been written and each ATARC3 data file is composed of 10 blocks, there are 100 blocks.

With respect to the values ​​of the CONNUM0 and BLOCK SERIAL areas, the reproduction order and interrelationship of the 100 block music programs is obtained.

When the result of step SP19 is Yes, it means that all blocks have been searched for recovery management file, ATRAC3 data file, and attribute file. Thus, in step SP21, based on the values ​​of CONNUM0, BLOCK SERIAL, FNO and TRKX, in order of the block numbers stored in memory, the file merger state was obtained.

After obtaining the connection status, it is possible to generate the file allocation table in the free memory space.

The playback management file according to the second embodiment of the present invention will be described below. Fig. 25 shows a file structure according to a second embodiment of the present invention. Regarding fig. 25, the music directory contains the TRKLIST.MSF path information management file (henceforth TRKLIST), the backup copy of the TRKLISTB.MSF path information management file (henceforth TRKLISTB), the INFLIST.MSF additional information file (which contains artist name, ISRC code, timestamp, image data, and the like (this file is referred to as INFIST)), ATRAC3 A3Dnnnn.MSF data file (hereinafter referred to as A3nnnn). The TRKLIST file contains two areas NAME1 and NAME2. The NAME1 area is the area that contains the name of the memory card and the program name (one-byte code corresponding to the character code in ASCII / 8859-1 standard). The NAME2 area is the area that contains the name of the memory card and the program name (a two-byte code corresponding to a character code in MS-JIS / Hankul / Chinese).

Fig. 26 shows the relationship between TRKLIST path information management file, NAME1 and NAME2m areas, and ATRAC3 data file A3Dnnnn. The TRKLIST file is a fixed length of 64 kilobytes (= 16k x 4). The 32KB area of ​​the file is used to accommodate the NAME1 and NAME2 areas. Although the NAME1 and NAME2 areas for program names can be created in the form of a file other than a path information management file, in a memory-tight system it is convenient to handle the path information management file and program name files as a whole.

The TRKINF-nnnn path information area and the 'PRTINF-nnnn' part information area of ​​the TRKLIST path information management file are used to manage A3Dnnnn data files and the INFLIST supplementary information. Only the ATRAC3 data A3Dnnnn file is encrypted. In Fig. 26, the data length in the horizontal direction is 16 bytes (0 to F). The vertical hexadecimal number specifies the value at the beginning of the current line.

According to the second embodiment, three files are used, which are: TRKLIST track management file (including program title file), INFLIST additional information management file, A3Dnnnn data file. According to the first embodiment (see Figs. 7, 8 and 9), two files are used, which are: a PBLIST recovery management file for managing the entire memory card and an ATRAC3 data file storing programs.

The data structure according to the second embodiment will be described below. For simplicity, in the data structure according to the second embodiment, description of parts similar to those of the first embodiment will be omitted.

Fig. 27 shows in detail the structure of a TRKLIST file for path information management. In the TRKLIST path information management file, one cluster (block) is made up of 16 kilobytes. The size and data of the TRKLISTB file are the same as those of the TRKLISTB backup file. The first 32 bytes of the path information management file are used as the header. Along with the PBLIST recovery management file header, the TRKLIST file header includes the BLKID-TL0 / TL1 (backup file identifier) ​​area (4 bytes), the T-TRK area (2 bytes) where the total number of tracks is stored, the manufacturer's code area Mcode ( 2 bytes), the VERIFICATION area (4 bytes) specifying the number of times the TRKLIST file was rewritten, and the S-YMDhms area (4 bytes) (Optional) in which the update date and time are stored. The meanings and functions of these data areas are the same as those described in the first embodiment. In addition, the TRKLIST file contains the following areas.

= YMDhms (4 bytes)

Represents the date and time of the last update (year, month, day, hour, minute, second).

= N1 (1 byte) (Optional) represents the sequence number in the memory card (counter). When the memory card is in use, the value of the N1 area is 0x01.

= N2 (1 byte) (optional)

Represents the sequence number on the memory card (denominator). When the memory card is used, the value of the N2 area is 0x01.

= MSID (2 bytes) (optional) represents the ID of the memory card. When multiple memory cards are used, the MSID value of each memory card is the same (TBD) (TBD (to be defined) means the value is to be defined in the future).

= S-TRK (2 bytes)

Represents a special path (TB.BD) Normally the value of the S-TRK area is 0x0000.

= PASS (2 bytes) (optional)

Represents a password (TBD)

PL 208 230 B1 = APP (2 bytes) (optional)

Represents Playback Application Definitions (TBD) (Normally the APP area value is

0x0000).

= INF-S (2 bytes) (optional) represents the additional information pointer for the entire memory card. When no additional information is available, the value of the INF-S area is 0x00.

The last 16 bytes of the TRKLIST file are used for the BLKID-TL0 area, the Mcode area, and the VERIFICATION area, which are the same as those in the header. The TRKLISTB backup file contains the header described above. In this case, the header includes a BLKID-TL1 area, a Mcode area, and a VERIFICATION area.

After the header, there is a track information area TRKINF containing information related to each track, and a PRTINF part information area containing information related to each track and each part of tracks (music programs). Fig. 27 shows the regions followed by the TRKLIST region. The lower part of the TRKLISTB area shows the detailed structure of these areas. In Fig. 27, the hatched area represents the unused area.

The TRKINF-nnn path information area and the PRTINF-nnn part information area contain ATRAC3 data file areas. In other words, TRKINF-nnn path information area and PRTINF part information area, each contain L1 playback restriction tag area (1 byte), CONTENTS KEY content key area (8 bytes), recorder / player protection block serial number area MG (D) SERIAL (16 bytes), XT area (2 bytes) optional) representing future 'parts' of the music program, INX area (2 bytes) (optional), YDMhms-S area (4 bytes), YDMhms-E area (4 bytes) (optional), MT area (1 byte) (optional), CT area (1 byte) (optional), CC area (1 byte) (optional), CN area (1 byte) (optional ) (TMDhms-S, YMDhms-E, MT, CT, CC and CN areas are used as playback limiting information and copy control information), A area (1 byte) used as part attribute, PRTSIZE 'part size' area ( 4 bytes), the key area of ​​the 'parts' part key area) PRTKEY (8 bytes), and the cumulative number area of ​​CONNUM content (4 bytes). The meanings, functions and values ​​of these areas are the same as those in the first embodiment. In addition, the path information area TRKINF-nnn and the information area of ​​the PRTINF-nnn part each include the following areas.

= T0 (1 byte)

Fixed value (T0 = 0x74) = INF-nnn (optional) (2 bytes)

Represents the additional information pointer of each track (0 to 409). 00: Music program without additional information.

= FNM-nnn (4 bytes)

Represents the file number (0x0000 to 0xFFFF) for an ATRK3 data file. Nnnn number (in code

ASCII) ATRAC3 data file name (A3Dnnnn) is converted to 0xnnnnn.

= APP_CTL (4 bytes) (optional)

Represents an application parameter (TBD) (normally the APP_CTL area value is 0x0000).

= P-nnn (2 bytes)

Represents the number of parts (1 through 2039) that make up the music program. This area corresponds to the aforementioned T-PART area.

= PR (1 byte)

Fixed value (PR = 0x50)

The areas NAME1 (for single-byte code) and NAME2 (for double-byte code) for name management will be described below. Fig. 28 shows in detail the structure of the NAME1 (for single-byte code) area. Each of the NAME1 and NAME2 areas (which will be described later) is divided into eight bytes. Thus, one frame is made of eight bytes. At the address 0x8000, which is the beginning of each of these areas, a header is placed. Below the header are the indicator and the name. The last frame of the NAME1 area contains the same areas as the header.

= BLKID-NM1 (4 bytes)

Represents the contents of a block (constant value) (NM1 -0x4E4D2D31).

= PNM1-nnn (4 bytes) (optional)

Represents a pointer to the NM1 area (for a single-byte code)

PL 208 230 B1 = PNM1-S

Represents a pointer to a name pointing to a memory card.

nnn (= 1 to 408) represents the pointer to the title of the music program.

The pointer represents the start position (2 bytes) of the block, character code type (2 bits), data size (14 bits).

= NM1-nnn (optional)

Represents the name of the memory stick and the title of the music program for a single byte (variable length) code. The end code (0x00) is written at the end of each area.

Fig. 29 shows in detail the data structure of the NAME2 (for the double-byte code). At the address 0x8000, which is the beginning of the area, the header is placed. Below the header are the indicator and the name. The last frame of the NAME2 area contains the same areas as the header.

= BLKID-NM2 (4 bytes)

Represents the contents of a block (constant value) (NM2 - 0x4E4D2D32).

= PNM2-nnn (4 bytes) (optional)

Represents a pointer to the NM2 region (for a double-byte code) = PNM2-S

Represents a pointer to a name representing a memory card. nnn (= 1 to 408) represents a pointer to the title of the music program.

The pointer represents the start position (2 bytes) of the block, character code type (2 bits), data size (14 bits).

= NM2-nnn (optional)

Represents the name of the memory stick and the title of the music program for a double-byte (variable length) code. The end code (0x0000) is written at the end of each area.

Fig. 30 shows the data arrangement (for one block) of the ATRAC3 data file A3Dnnnn, in which case the SU is made of N bytes. In this file, one frame is made up of eight bytes. Fig. 30 shows the values ​​of the first (top) 'part' (0x000 to 0x3FF8) of each frame. The first four frames of the file are used as the header. As in the first embodiment where the data block is preceded by an attribute header, the header is included here. The header includes the BLKID-A3D area (4 bytes), the Mcode manufacturer code area (2 bytes), the BLOCK-SEED area (8 bytes) necessary in the encryption process, the CONNUM0 area (4 bytes) used by the cumulative number of the initial content, the BLOCK serial number area SERIAL (4 bytes) for each path, and the INITIALIZATION VECTOR area (8 bytes) necessary for the encryption / decryption process.

The second-most block frame redundantly includes a BLOCK SEED area. The last frame contains the BLKID-A3D and Mcode areas. As in the first embodiment, the audio unit data SU-nnnn is located below the header.

Fig. 31 shows in detail the data structure of the side information management file INFLIST which includes the side information. In the second embodiment, the following header is placed at the beginning (0x0000) of the INFLIST file. Below the heading are the indicator and areas below.

= BLKID-INF (4 bytes)

Represents the contents of a block (constant value) (INF = 0x494E464F).

= T-DAT (2 blocks) represents the total number of data regions (0 to 409).

= Mcode (2 bytes)

Represents the recorder / player manufacturer's code.

= YMDhms (4 bytes)

Represents the updated date and time of the recording.

= INF-nnnn (4 bytes)

Represents a pointer to the DATA area of ​​additional information (variable length, as it takes 2 bytes (frame) each time). The starting position is represented by sixteen more significant bits (000 to FFFF).

= DATASLOT-0000 (0x0800)

It represents the offset value from the start (each time in the number of frames).

The data size is represented by the least significant 16 bits (0001 to 7FFF). Mark28

The trip factor is set to the most significant bit. MSB = 0 (on), MSB = 1 (off).

The data size represents the total amount of data contained in the music program.

Data starts at the beginning of each frame. (The frame area containing no data is filled with 00 zeros.)

The first INF represents a pointer to the notes for the entire album (normally INF-409).

Fig. 32 shows the structure of the side information. The eight-byte header is placed at the beginning of one side information data area. The structure of the side information is the same as that of the first embodiment (see Fig. 12C). In other words, the side information includes an IN area (2 bytes) representing an ID identifier, an ID key area (1 byte), a SIZE area (2 bytes) which represents the size of each side information area, and a manufacturer code area Mcode (2 bytes). Moreover, the side information includes a SID area (1 byte) as the additional identifier.

According to a second embodiment of the present invention, in addition to the file system defined in the memory card format, a track information management file or music data is used. Thus, even if the FAT file allocation table is destroyed, the file can be recovered. Fig. 33 shows the flow of the file recovery process. To recover a file, a computer is used that runs a file recovery program and that has access to connected memory cards and storage devices (hard disk, RAM, or similar devices). The computer is the functional equivalent of the DSP 30 signal processor. The file recovery process using the TRKLIST path information management file will be described below.

All flash memory blocks whose FAT file allocation table has been destroyed are searched for TL-0, which is the value (BLKID) at the top of each block. Moreover, all blocks are searched for NM-1, which is the value (BLKID) at the beginning of each block. Then, all blocks are searched for NM-2 value, which is the value (BLKID) placed at the top of each block. The entire contents of the four blocks (path information management file) are stored, for example, on the hard drive of the recovery computer.

The total number of paths is obtained from the data after the fourth byte of the path information management file. From the twentieth byte of the track information area TRKINF-001 we get the value of the area CONNUM-001 of the first music program, and the value of the next area P-001. The number of 'parts' is obtained from the value of area P-001. The PRTSIZE values ​​of all 'parts' of track 1 of the PRTINF area were obtained. The total number of blocks (clusters) n is calculated and obtained.

After obtaining the path information management file, the process proceeds to step 102. In step 102, a voice data file (ATRAC3 data file) is searched for. All blocks other than the management file are searched in the flash memory. Blocks with a peak value (BLKID) of A3D are collected.

A block is searched for which the value of the CONNUM0 area in byte 16 A3Dnnnn is the same as that of the CONNUM-001 area of ​​the first music program in the path information management file, and whose BLOCK SERIAL area value that starts with byte twentieth is 0. After obtaining the first block, a block (cluster) with the same CONNUM area value as in the first block is searched, and the BLOCK SERIAL value is increased by 1 (1 = 0 + 1). After obtaining the second block, a block with the same CONNUM0 area value as the second block is searched, and the BLOCK SERIAL area value has been increased by 1 (2 = 1 + 1).

By repeating this process, the ATRAC3 data file is searched until n blocks (clusters) of track 1 are obtained. Once all blocks (clusters) have been obtained, they are successively stored on the hard disk.

The same process as for track 1 is performed for track 2. In other words, a block is searched for whose CONNUM0 area value is the same as the CONNUM-002 area value of the first music program in the track information management file, and the value of which is the BLOCK SERIAL area. starts at byte twentieth. Then, in the same way as with

After lane 1, the ATRAC3 data file is searched until the last block (cluster) n 'is detected. After all blocks (clusters) are obtained, they are successively saved on the hard disk.

By repeating the processes described above for all tracks (number of tracks: m), all ATARC3 data is written to the hard drive controlled by the recovery computer.

In step 103, the memory card whose FAT file allocation table has been corrupted is reinitialized, thereby restoring the file allocation table. Predefined directories are created on the memory card. Then, the path information management file, and the ATRAC3 data file for m tracks are copied from the hard disk to the memory card. So, the recovery process is complete.

In the management file and the data file, important parameters (in particular, codes in the headers) can be written three times rather than twice. When data is stored redundantly, the same data may be written anywhere as long as they are at least one page apart.

The forge-checking process for the data file according to the first embodiment is described below. Various kinds of information can be checked for spoofing, such as the PBLIST.MSF playback management file and the ATRAC3 data file that contains compressed audio data. Since the reproduction management file PBLIST.MSF contains S-YMDhms clock information, clock information is checked to prevent the user from falsifying it.

The forge-check code is generated by computing the hash value using the content key (CK) of the ATRAC3 data file generated with the recovery management file using the hash function. Also, because the file can be deleted or moved, the content key value (CK) is stored in another file. In the event that S-YMDhms clock information has not been entered, all hash values ​​are set to zero without any computation. Each time S-YMDhms clock information is updated, the hash values ​​are calculated.

With regard to an ATRAC3 data file that contains audio data, the following are the subject of a falsification (integrity check) check: track attribute A, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, cumulative number of CONNUM contents, date / time YMDhms-S start of playback, date / time YMDhms-E playback expiration, number of plays CT track number of allowed MT track plays, CC copy control, number of CN high speed digital copy authorizations (optional), preventing the user from spoofing them. The authenticity (integrity) code is generated by computing the hash value using the content key (CK) of the ATRAC3 data file using the hash function (hash function). When an ATRAC3 data file is split or linked, the hash value is calculated with the new content key.

Fig. 34 is a block diagram showing an authentication circuit (integrity) in a digital recorder according to the present invention. When a memory card is connected to the digital audio recorder or when the play key is pressed, the connected memory card is authenticated. After the memory card has passed the authentication process, the DSP signal processor 30 reads the path information management file TRKLIST.MSF from the flash memory of the memory card 40 and stores it in the S-RAM (static RAM) 31.

In Fig. 34, a playback restriction value block 70 is included in the path information management file. The reproduction management file is stored in a specific area of ​​the flash memory of the memory card 70. The reproduction restriction value block 70 is read from the flash memory and placed in the SRAM 34 (36). The reproduction restriction value block 70 is checked for spoofing. The authentication (integrity) circuit shown in Fig. 34 includes: hash calculator 71, scrambler 22 having specific memory regions (72 and 73) that are non-volatile memory, comparator 74, control circuit 75. Control circuit 75 has an internal clock 76. Hash calculator 71 comparator 74 , and the control circuit 75 are implemented as a hardware structure or in a software manner. The program routines are executed by the DSP 30. A comparator (74) and a non-volatile memory chip (72, 73) for storing the hash values ​​are housed in one controller. The system calculates30

The hash function 71 may be implemented, for example, as a functional device that forms part of the scrambler 22.

The control circuit 75 monitors the attachment state of the memory card 40. When the memory card is connected to a digital audio player, the control circuit 75 determines whether or not the reproduction operation of the files stored in the memory card 40 is allowed, depending on the corresponding predetermined information contained in block. 70 value limiting playback. The predetermined values ​​are for example: track attribute A, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, content of the cumulative number CONNUM, date / time YMDhms-S start of playback, date / time YMDhms-E playback expiration, number of plays CT track, number of MT track repetitions allowed, CC copy control, CN high speed digital copy authorizations (optional), content key (CK), and the like. As for the playback start date / time and the playback capability expiration date / time, they are compared with the internal clock date / time 76 to determine if the playback operation is allowed. As for the number of plays of the CT track and the number of allowed plays of the track MT , it is determined whether the reconstitution operation is feasible or not.

The hash function calculator 71 computes hash values ​​for the individual parameters included in the reproduction restriction value block 70. The hash values ​​are obtained by using a hash function. When the block 70 of reproduction restriction values ​​is forged, the hash values ​​differ. The hash function (hash function) is generally defined in ISO / IEC 10118-1, JIS X5057-1. A hash function is a function for which two different input values ​​cannot give the same output value. The computed result of hash function 71 is fed to scrambler 22.

The control information is supplied from the control circuit 75 to the non-volatile memory of the scrambler 22. The hash values ​​computed prior to the reproduction operation are stored in the defined memory area 72 as the current hash values. On the other hand, the hash values ​​computed after the previous restore operation are stored as the previous hash values ​​in the specified memory area 73. The current hash values ​​and the previous hash values. former hash values ​​stored in scrambler 72 are read and provided to comparator 74. Values ​​in predetermined areas (72 and 73) of encoder flash memory 22 cannot be read externally from digital audio recorder. Thus, it is impossible to access the hash values ​​which are stored in the areas 72 and 73 from the outside. Only the result of the comparator 74 is readable from the outside. An area that cannot be accessed from the outside is known as a tamper resistent area.

Comparator 74 compares the current hash values ​​with the previous hash values. Depending on whether the current hash values ​​are the same as the previous hash values, it is determined whether the block 70 of reproduction restriction values ​​has been forged or not. The output from comparator 74 is fed to controller 75.

The control circuit 75 determines whether the restore operation is allowed or forbidden based on the values ​​of the track attribute A, recovery restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, cumulative CONNUM content, date / time YMDhms- S Playback Start Date / Time YMDhms-E Playback Expiration Count CT Track Playback Number Allowed Track MT Playback Control CC Copy the number of high speed digital copying licenses CN (optional), the content key (CK), and the output from comparator 74. The control circuit 75 generates control information corresponding to a predetermined result. In other words, when the block 70 of reproduction restriction values ​​has been determined to have not been forged and a reproduction operation is allowed, the control circuit 75 generates control information that allows the reproduction operation to be performed.

On the other hand, when the block 70 of reproduction restriction values ​​has been forged, the control circuit 75 generates control information that prevents the reproduction operation from being performed. Even if the block 70 of reproduction restriction values ​​has not been forged, i.e. when the restore operation is prohibited due to the values: A track attribute, playback restriction tag, LT security version, MG (D) serial number, MG (D) SERIAL, CONNUM cumulative content, YMDhms-S start date / time, YMDhms-E playback expiration date / time, play count CT path, number of allowed reproductions of path MT, copy configuration CC, number of high speed digital copying licenses CN (optional), content key (CK), then the reproduction operation is prohibited.

In the above-described embodiment, an authentication process for an ATRAC3 data file has been described. Similarly, such an authentication process is performed for the S-YMDhms clock information contained in the reproduction management file PBLIST.MSF. The authenticity (integrity) code is generated by computing the hash value using the content key (CK). contents key) of the first ATRAC3 data file program generated with the PBLIST.MSF recovery management file, using the hash function.

The calculation process in this example is the same as that for the ATARC3 data file. The circuit for conducting this computation process may be shared with that used for the computation for the ATRAC3 data file. Since the file can be deleted and moved, the content key value (CK) is stored in another file. When clock information S-YMDhms has not been entered, all hash values ​​are set to zero without any computation. The hash values ​​are computed each time S-YMDhms clock information is updated.

Fig. 35 shows the process by which an EMD (electronic music distribution) terminal (not shown) downloads an ATRAC3 data file in the format according to the first embodiment to the memory card. Furthermore, Fig. 35 shows the process by which the EMD terminal downloads to a memory card over a public line (ISDN line, telephone line or satellite connection) an ATRAC3 data file that has been compressed and encrypted. In this example, it is assumed that an unused memory card (flash memory) is connected to the EMD terminal, namely a blank memory card (flash memory).

In step SP101, when the blank memory card is connected to the EMD terminal, a reproduction management file PBLIST.MSF is generated. Moreover, information about the download date / time is generated. The retrieval date / time information is stored as S-YMDhms clock information in the replay management file PBLIST.MSF.

In step SP102, when the ATRAC3 data file which has been compressed and encrypted is received over the public line (ISDN line, telephone line, satellite link) and stored in flash memory, an attribute header as shown in Fig. 9 is generated. which is added to the ATRAC3 data file.

In step SP103, a hash function calculator 71 using the content key (CK) contained in the attribute header using the hash function, computes the clock information hash value S-YMDhms of the recovery management file PBLIST.MSF, and stores the computed value. a hash in the memory area 73 of the scrambler 22.

In step SP104, the hash function calculator 71 using the content key (CK) contained in the attribute header, using the hash function. hash function), computes hash values ​​for playback restriction information: (A path attribute, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, contents of the cumulative number CONNUM, date / time YMDhms-S of playback start, date / time YMDhms-E of playback expiration, number CT track plays, MT track plays allowed, CC copy control, CN high speed digital copy authorizations (optional)), ATRAC3 data file. The computed value obtained with the hash function 71 is stored in the memory area 73 of the scrambler 22.

In addition, the hash function calculator 71, using the content key (CK) contained in the attribute header, using the hash function, computes the hash value for the serial number MG (D) SERIAL and the content of the cumulative number CONNUM generated with with the attribute file. The computed value obtained by the hash function 71 is stored in the memory area 73 of the scrambler 22. Since data is written to a blank memory card, no data has been written to memory area 72.

In step SP105, it is determined whether or not the flash has been disconnected from the EMD terminal. When the result of the test of step SP105 is Yes, it moves to step SP106. In step SP106, it is determined whether the flash memory has been reconnected or not. When the result of the test of step SP105 is No, it moves to step SP107. In step SP107, it is determined whether the EMD has been powered off or not.

PL 208 230 B1

When the result of the test of step SP107 is Yes, it moves to step SP108. In step SP108, it is determined whether the power has been turned back on or not.

When the result of the test of step SP106 is Yes, or the result of the test of step SP108 is Yes, it moves to step SP109. In step SP109, the hash function calculator 71 using the content key (CK) contained in the attribute header calculates, using the hash function, a hash value for the clock information S-YMDhms of the PBLIST.MSF recovery management file. The computed value obtained by the hash function 71 is written to the memory area 72 of the scrambler 22.

In step SP110, it is determined whether the current hash values u stored in the memory area of ​​the encoder 22 correspond to previous hash values ​​stored in the memory area 73 of the encoder 22. When the result of the examination in step SP110 is Yes, the current hash values ​​stored in the memory area 72 of the scrambler 22 are copied in place of the previous hash values ​​stored in the memory area 73 of the scrambler 22.

In step SP111, it is determined whether or not a reproduction command has been issued. When the result of the checking in step SP111 is YES, and when the result of the checking in step SP110 is YES, then going to step SP112 is carried out. In step SP112, in response to the reproduction command, the hash function calculator 71 using the content key (CK) contained in the attribute header using a scrambling function ( hash function), computes the hash value for the attribute file attached to the ATRAC3 data file: track attribute A, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, cumulative CONNUM content, date / time YMDhms-S playback start, date / time YMDhms-E playback expiration, number of plays CT track number of allowed MT track plays, CC copy supervision, number of high speed digital copy authorizations CN (optional) of the attribute file attached to the ATRAC3 data file. The computed value obtained by the hash function 71 is stored in the memory area 72 of the scrambler 22.

Then it moves to step SP113. In step SP113, a check is performed as to whether or not hash values ​​stored in memory area 72 of scrambler 22 obtained from hash function calculator 71 correspond to hash values ​​stored in memory area of ​​scrambler 22.

Comparator 74 compares the currently computed hash values ​​with the previously computed hash values. If they match, it is determined whether any of the information represented by the following has been falsified in the attribute file: track attribute A, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, cumulative CONNUM content, date / time YMDhms-S playback start, date / time YMDhms-E playback expiration, number of plays CT track number of allowed MT track plays, CC copy control, number of CN high speed digital copy authorizations (optional). Then it moves to the step SP114. In step SP114, the restore operation of the ATRAC3 file is allowed.

When the result of the checking performed in step SP113 is the result, No, it means that it has been found that some of the information has been falsified in the attribute file: track attribute A, playback restriction tag, LT security version, MG (D) serial number MG (D) SERIAL, content of the cumulative number CONNUM, date / time YMDhms-S start of playback, date / time YMDhms-E playback expiration, number of plays CT track number of allowed MT track plays, CC copy control, number of CN high speed digital copy authorizations (optional). In this case, it goes to step SP115. In step SP115, an ATRAC3 data file restore operation is prohibited. This is followed by a move to step SP116. In step SP116, the forging flag is set.

When an ATRAC3 data file is to be played, it is checked whether the predetermined values ​​(any positive integers) have been entered in the areas: number of CT track plays and number of allowed MT track plays. When any predetermined value is the repetition count of the CT track, it is decreased by 1. When the recycle count of the CT path is zero, and the specified number (any positive integer) is the number set in the recycle count MT area, since the restore operation has been performed the allowable number of times, the restore operation of the ATRAC3 data file is prohibited.

PL 208 230 B1

Next, a real example of EMD working with the format according to the second embodiment will be described in detail. Fig. 36 shows an example of a process in which an EMD (electronic music distribution) terminal downloads a music file having a playback restriction of two times. For simplicity, it is assumed that the playback rights expiration date / time is unlimited. The EMD terminal has the same scrambling chip (not shown) as the digital audio recorder described above. The encryption chip authenticates the attached memory card. After the attached memory card has been positively authenticated, the encryption chip writes the encrypted audio file (ATRAC3 data file) to the memory of the card. In addition, the EMD terminal provides the digital audio recorder with limiting information on playing the audio file.

The digital audio recorder carries out the formatting process for the audio file and playback restriction information, and records the formatted data to a flash memory. In Fig. 36, when the EMD is downloading data to a digital audio recorder, it performs the process denoted by S201. In step S1, the digital audio recorder receives data from the EMD terminal having a reproduction limit and sets (MT = 2) and (CT = 2) in the TRKINF area of ​​the TRKLIST path information management file.

In addition, the hash function calculator 71 computes hash values ​​for several parameters (a block 70 of reproduction restriction values) including the MT, CT and the CONTENT ID. The hash values ​​computed by the hash calculator 71 are stored in the memory area 73 of the scrambler 22. Then, when the power to the digital audio recorder is turned off or the memory card 40 is removed, the block 70 of playback restriction values ​​is checked for spoofed information. If necessary, the block 70 of reproduction restriction values ​​may be checked for spurious information each time a reproduction operation is performed.

After the memory card 40 is disconnected and reconnected, when the play command is given in step S3, it goes to step S202. In step S4, hash calculator 71 calculates hash values ​​for the block 70 of reproduction restriction values. The hash values ​​computed by the hash calculator 71 are stored as the current hash values ​​in the memory area 72 of the encoder 22. The current hash values ​​and previous hash values ​​are read and provided to comparator 74. Comparator 74 compares the current hash values ​​with the previous hash values. Depending on whether they match or not, comparator 74 determines whether the block 70 of reproduction restriction values ​​has been forged or not. The comparator 74 supplies the result obtained to the control circuit 75.

Depending on the output from comparator 74, control circuit 75 creates control information. In other words, when the block 70 of reproduction restriction values ​​has not been forged, i.e. when the current scramble values ​​match the previous scramble values, the counterfeit information is not detected. In that case, when the number of CT retries is not zero (CT # 0), it goes to step S5. In step S5, the control part creates control information to control the reproduction operation and starts the reproduction operation. After the reproduction operation is completed, it goes to step S6. In step S6, the number of CT retries is reduced, so that the value (CT = 1) is set. In addition, the hash values ​​for the block 70 of recovery limiting values ​​are computed and written to memory area 73 as the previous hash values.

After removing the memory card 40 and reconnecting it, when a reproduction command is given in step S7, it goes to step S203. In step S203, the same process is performed as in step S202. In other words, the hash values ​​for the block 70 of reproduction restriction values ​​are computed and compared to the previous hash values. Thus (at step S8) it is checked whether the block 70 of reproduction restriction values ​​has been forged. When the block 70 of reproduction restriction values ​​has not been forged, a reproducing operation is performed (at step S9). After that, (in step S10), the number of plays is reduced by 1, so that the value (CT = 0) is set.

After the CT retry count is set to zero (CT = 0), regardless of whether the block of copy limiting values ​​70 has been forged or not, the CT retry count has a higher priority. Thus, the restore operation is prohibited. For example, after the memory card 40 has been disconnected and disconnected again, and when the reproduction command has been issued in step S11, it goes to step S12. In step S12, hash values ​​are calculated. hash values) for a block 70 of restore restriction values, and then these current hash values ​​are compared with the previous hash values. When the current hash values ​​match the previous hash values, then

The restore operation is allowed normally. However, when the CT restoration count is zero (CT = 0), the restoration operation is prohibited. Thus, in this case, the control circuit 75 creates control information that prohibits the reproduction operation (at step S13). In addition, the user is informed by means of the loudspeaker / display that since the number of plays of the CT corresponds to the number of allowed plays of the MT, a reproduction operation is impossible.

The following will describe the case where the TRKINF information of the TRKLIST path information management file was falsified. For example, it is assumed that the TRKINF has been falsified in step S11, and that the number of allowed plays MT of the music file has been falsified to be 10 (MT = 10).

When the reproducing command is given in step S22, it goes to step S23. In step S23, the hash values ​​for the block 70 of reproduction restriction values ​​are calculated. The hash values ​​are stored as the current hash values ​​in memory area 72. The comparator 74 determines whether the current hash values ​​correspond to the previous hash values. In this case, since the block 70 of reproduction restriction values ​​has been forged, these values ​​do not match. Thus, the control circuit 75 creates control information that prohibits the reproduction operation from being performed (at step S23). Thus, in step S24, the reproduction operation is not performed. In this case, the user is informed by the loudspeaker / display that since the block 70 of reproduction restriction values ​​has been forged, the reproduction operation is prohibited.

After all this goes to step S25. In step S25, a forging flag is displayed at a specific location (e.g., in the RESERVED area shown in FIG. 27) TRKINF of the TRKLIST file. The hash values ​​are calculated and stored. In the situation where the spoof flag is issued, even if the number of allowed recreations MT is set to 2 (MT = 2), the reproduction operation is forbidden (at step S26) because the spoof flag was issued. In other words, the presence of a spoof flag is checked before the ATRAC3 data file is restored. When the spoof flag is detected, the control circuit 75 determines that the reproduction operation is prohibited. Hence, in this case, the control circuit 75 creates control information that prohibits the reproduction operation from being performed. Thus, the restore operation is not performed.

In the example described above, each time a restore operation is performed, the number of CT reproductions is reduced by 1. When the number of CT reproductions is zero (CT = 0), the restoration operation is prohibited.

Alternatively, each time a restoration operation is performed, the number of CT restoration may be increased by 1. When the number of CT restoration is equal to the number of permissible MT restoration (MT = CT), the restoration operation may be prohibited. Another alternative method is to decrease the number of allowed MT plays back by 1 without using the number of CT plays.

The following will describe a case where only the playback rights expiration date / time (YMDhms-E) of the track was set in the TRKINF information in the TRKLIST file, without setting the number of allowed MT plays and the number of CT plays.

When a file having a playback rights expiration date / time is downloaded from the EMD terminal to a memory card, the playback rights expiration date / time is stored in the memory card path information management file. The hash values ​​for the block 70 of reproduction limitation values ​​that include the playback rights expiration date / time are computed. The hash values ​​are stored as the previous hash values ​​in the memory area 73 of the scrambler 22. Then, when the power to the digital audio recorder is turned off, when the memory card 40 is removed, or if necessary, when a reproduction command is issued, the block 70 of playback restriction values ​​is checked for tampering before performing the reproduction operation. In addition, the date / time of the internal clock 76 of the controller 75 is compared with the expiration date / time of the reproduction rights.

After the memory card 40 is disconnected and reconnected when a reproduction command is issued, the hash values ​​for the block 70 of playback constraints are computed. Comparator 74, compares the currently computed hash values ​​with the previously computed hash values. Depending on whether they match or not, comparator 74 determines whether the block 70 of reproduction restriction values ​​has been forged or not. In addition, comparator 74 compares the internal clock 76 date / time with the expiration date / time

PL 208 230 B1 for reconstitution. When the block 70 of reproduction restriction values ​​has not been forged and the date / time of the internal clock 76, as a result of a check by comparator 74, is prior to the expiration date / time of the reproduction rights, the reproducing operation is performed.

On the other hand, when the block 70 of reproduction restriction values ​​has been forged as determined by the comparator 74, the reproduction operation is forbidden. Moreover, in the case where the date / time of the internal clock 76 is later than the date / time of the expiration of the playback rights, as determined by the comparator 74, even if the block 70 of playback limiting values ​​has not been forged, in the specified time (e.g., in the RESERVED area shown in FIG. 27) TRKINF of the TRKLIST file, the expiry flag is set. In addition, the playback rights expiration date / time is given a higher priority regardless of whether or not the block of playback restriction values ​​has been forged. Thus, the restore operation is prohibited.

In other words, the current hash and previous hash values ​​are compared before the data file is restored. If they do not match, the block 70 of restraining values ​​70 has been forged, and the reproduction operation is forbidden. However, even if the current hash values ​​match the previous hash values, as long as the restore rights expiration date / time is not valid, the restore operation is prohibited. When the reproduction operation is prohibited, the user is informed by means of a loudspeaker or a display with an appropriate message. Even if the internal clock 76 date / time is later than the playback rights expiration date / time, the hash values ​​for the recovery restriction value block 70 are anyway computed and stored in memory to provide protection against future spoofing attempts.

The case where only the start date / time (YMDhms-S) of the music file is set in TRKINF of the TRKLIST file, and the number of allowed MT plays and the number of CT plays are not set will be described below.

When a music file is downloaded from the EMD terminal to the memory card, the playback start date / time is stored in the track information management file. The hash values ​​for the block 70 of reproduction restriction values, which includes the playback rights expiration date / time, are calculated and then fed to the scrambler 22. The hash values ​​are stored as previous scrambles in the memory area 73 of the scrambler 22. When the power of the digital audio recorder is turned off, or when the memory card 40 is disconnected, it is checked whether or not the block 70 containing the playback restriction values ​​has been performed before performing the playback operation. Further, it is determined whether the date / time of the internal clock 76 of the controller 75 corresponds to the date / time of the reproduction start.

For example, after disconnecting and reconnecting the memory card 40, when the reproduction command is issued, the current hash values ​​and the previous hash values ​​are compared. Depending on whether they are compatible or not, a determination is made as to whether or not the block 70 of reproduction restriction values ​​has been forged. In addition, the date / time of the internal clock 76 and the playback start date / time are compared. When the block 70 of reproduction restriction values ​​has not been forged and the comparison results to determine that the date / time of the internal clock 76 is later than the reproduction start date / time, the reproducing operation is allowed.

On the other hand, the reproduction operation is prohibited when the block 70 of reproduction restriction values ​​has been forged, such as in the case described above. Further, even if the block 70 of playback restriction values ​​has not been forged and the comparison results to determine that the internal clock 76 date / time is not later than the reproduction start date / time, the reproduction start date / time is given priority over falsified information. Thus, the restore operation is prohibited.

In the example described above, to detect the forged information, the hash values ​​of the individual parameters (content ID ID, CT plays, MT play counts, play rights expiration date / time, and play start date / time) included in the block of limiting values ​​are calculated. playing. Alternatively, such hash values ​​may be computed for each music file.

In the example described above, the present invention has been applied to a digital audio recorder. Alternatively, the present invention can be applied to other devices and can handle other types of data, such as video data, audio data, program data, and the like.

In accordance with the present invention, hash values ​​for the playback constraint information are calculated. The obtained hash value is stored in an area of ​​memory that cannot be

PL 208 230 B1 accessible from the outside of the device. Depending on whether the previous hash values ​​and the current hash values ​​are compatible or not, it is determined whether or not the reproduction restriction information has been falsified. When the control part detects the forged information based on the output from the comparing means, the control part prohibits the reproducing operation from being performed. Thus, according to the present invention, falsified information can be safely detected. When the counterfeit information is detected, the operation of reproducing the file having the counterfeit information may be prohibited.

Although the present invention has been illustrated and described with reference to the most preferred embodiment, it will be understood by those of skill in the art that further various changes, omissions and additions to its form and details may be made without departing from the scope of the present invention.