KR20080068757A - Method and system for managing keys and/or rights objects - Google Patents

Abstract

One or more rights objects (RO) files may be used for storing RO's preferably in the protected area available only to authenticated users. A RO navigation file is stored preferably in an unprotected public area containing status bits, where each status bit identifies whether a location in a RO file contains a valid RO or not. Preferably, there is a one-to-one correspondence between the location for a RO in a RO file and a location in the RO navigation file for the status bit which identifies whether its corresponding location in the RO file contains a valid RO or not. Whether a particular location in a RO file contains a valid RO or not can be found by checking its corresponding status bit in the RO navigation file. By finding out whether a particular location in a RO file contains a valid RO or not in this manner, it is possible to delete ROs without having to go through an authentication process. The process of finding an empty slot in the RO file for storing a new RO is also simplified. This greatly increases the efficiency of RO management. A similar system may be used for management of content encryption/ encryption keys for protecting content files.

Description

Method and system for managing keys and / or rights objects}

The present invention relates generally to an encryption / decryption system, in particular to a system for managing rights objects that control the use or access to content and the keys and / or content used for encryption / decryption.

Media content such as music, video, and games is further distributed into digital files. Such digital content has been widely distributed over a number of channels, including the use of the Internet and storage devices. Digital content may be stored in a number of other types of devices, such as nonvolatile memory such as flash memory, magnetic or optical disks and tapes. On these storage devices, digital content can be viewed as desktop and portable types of personal computers, iPods and other types of built-in or stand-alone media players, personal digital assistants, game controllers, MP3 players, and cellular phone handsets ("host devices"). Can be reproduced, stored and operated by a wide variety of devices.

To reduce or prevent unauthorized access to content for owners of digital content, digital content is frequently encrypted so that only authorized users can access the content. With the proliferation of many other digital files, such as songs, the number of keys needed to be managed can be quite large. Also, for enhanced security, multiple keys can be included in the encryption and decryption of each digital file. Therefore, a problem that can be expected in digital rights management (DRM) is the ability to efficiently manage multiple keys and determine right keys for encrypting and decrypting any particular digital file.

Many key management systems have been used. In a first type of key management system, a content file is named to easily identify and locate an encryption and / or decryption key. In another type of key management system known as an encrypted file system (EFS), the key itself used to encrypt the file is encrypted and the encrypted key is stored in the header of the corresponding encrypted content file. While the key management system may be useful for several applications, they each have limitations. None of the above systems are completely satisfactory. It would therefore be desirable to provide a key management system that is easier and more flexible to use.

In digital rights management (DRM), each content file may be associated with rules that control or note how the content file can be accessed and / or used. Such rules are referred to as rights objects in DRM. For example, a rule may specify that it can be accessed for a limited number of times, either before a predetermined expiration date or only for a predetermined time duration. Therefore, if it is desired to control access and / or use of the content file, a rights object is created, which may contain the rules described above as well as the content encryption / decryption key used to encrypt / decrypt the content profile. have. The rights object is then also associated with a content file controlled by the rights object. Often, rights objects control access to and / or use of content files by controlling access to content encryption / decryption keys used to encrypt / decrypt content files. Thus, in order to be able to use and / or access a protected content file, it can retrieve or otherwise obtain the rights object associated with it, decipher the rules in the rights object, and subsequently use or access the content file according to the rules. do. If the content file is encrypted, the key (s) is retrieved from the relevant rights object and used to decrypt the file before the content can be used or accessed. If it is desired to control the use and / or access of the content file, the rights object is created with rules governing access and / or use of the file and any encryption / decryption keys used to encrypt / decrypt the content file. The object is associated with such a content file.

In DRM, there may be a number of rights objects needed to be managed. Thus, it may also be desirable to provide a management system for managing rights objects that is more flexible and easier to use and capable of managing multiple rights objects.

In accordance with one embodiment of the present invention, a key navigation file and one or more storage files may be used to facilitate key management. The content file to be encrypted and / or decrypted each includes a header portion containing location information indicating that the key storage file contains a key used to encrypt and / or decrypt the content file. The key navigation file includes status information indicating whether the valid key is stored in one or more locations in one or more key storage files. This facilitates the process of locating a location in one or more key storage files for storing keys. Preferably, the status information indicates one or more locations in the key storage file where one or more valid key (s) are not stored.

The key navigation mechanism, including the key navigation file described above and one or more key storage files, can be stored on a non-volatile computer readable medium.

In one implementation of this embodiment, the key navigation file is stored in a public unprotected area of the storage medium and the one or more key storage files for storing the key are stored on a medium that can only be accessed by an authenticated user, application, or device. It is stored in a protected area. For obvious reasons, it is desirable to store one or more key storage files in a protected area that is not accessible to unauthorized access. Thus, by providing a key navigation file in the public area containing status information indicating whether one or more locations in the key storage file (s) contain a valid key, this greatly improves key management performance. Thus, there is no need to access the protected area to find out whether a particular key in the keystore file is valid or not; Instead, this information is readily available in key navigation files that can be accessed without authentication. This feature also makes it particularly easy to delete content files and their encryption / decryption keys. Deletion of a key can be performed in one implementation simply by changing state information in the key navigation file, without actually accessing the key storage file in the protected area containing the key to delete the key.

According to another embodiment of the present invention, the key navigation file and one or more key storage files can be easily used in the process for encrypting / decrypting the content file. Each entry in the key navigation file corresponds to a location in one or more key storage files for storing one of a plurality of encryption / decryption keys. The key navigation file may be opened to allow the discovery of an entry that does not correspond to a valid key at a location in one or more key storage files. An encryption / decryption key is generated and the content file is encrypted / decrypted. The .k encryption / decryption key is stored at a location in one key storage file corresponding to the entry in the key navigation file found at that time.

In one implementation of the above embodiment, the key navigation information may be derived from the location of the entry in the key navigation file found so that it does not correspond to a valid key and this location information is inserted into the header of the encrypted file. do. Thus, in the reverse process, by decrypting the location of the information in the header portion of the encrypted file, the location of the encryption / decryption key can be found in the key storage file or one of the files and the encryption and / or decryption of the encrypted file. Can be searched for.

According to another embodiment of the present invention, the content file can be decrypted using the decryption key in the key storage file in the protected area of the storage medium. The header portion of the content file includes key navigation information indicating the location of the encryption / decryption key in the key storage file for encrypting / decrypting the content file. The key navigation information is retrieved from the header portion of the content file and the position in the key storage file where the decryption key is stored is then obtained from the key navigation information. The decryption key is then obtained from the protected area and used to decrypt the content file. This process can also be used to find a particular key in a key storage file to encrypt the content file, and the location information of such a key can be found in the header of the content file.

In one particular implementation of the above embodiment, a plurality of key storage files are used to store keys. In this implementation, the key navigation information in the header portion of the content file includes an index, which may be an integer. Each key storage file contains m locations for storing keys. The index is divided by m to obtain a quotient. The integer portion of the quotient indicates that one of the plurality of key storage files stores the encryption / decryption key, and the remainder, which is referred to as an offset in the present invention, indicates the position in such a key storage file in which the encryption / decryption key is stored. .

Another embodiment of the present invention uses an encryption / decryption key stored in the key storage file and used to encrypt / decrypt the content file by a key navigation file including status information indicating whether the key stored in the key storage file is valid. It is aimed at the way to invalidate. The content file includes a header portion including location information indicating the location of the key in the key storage file. The location information of the key in the key file is obtained from the header portion of the content file. In the key navigation file, the status information of a key is found using location information.

The key's status information in the key navigation file is changed to indicate that the key is invalid.

Any one of the methods described above may be performed by a computer program executed by a processor, and the program is stored in a computer readable storage medium.

According to another embodiment of the invention, a computer program stored on a computer readable medium can be used to facilitate key management. The computer program creates one or more key storage files and key navigation files if one or more such files do not already exist. Each content file includes a header portion containing location information indicating whether the key storage file includes an encryption / decryption key for such content file. The key navigation file includes state information indicating whether one or more locations in the one or more key storage files contain a valid key.

In one implementation of this embodiment, an entry is found in a key navigation file that does not correspond to a valid key in at least one key storage file. Key navigation information for the content file is obtained from the location of the entry in the key navigation file. An encryption / decryption key is generated and used to encrypt / decrypt the content file. The encryption / decryption key is stored at a location in at least one key storage file corresponding to the entry.

According to another embodiment of the present invention, a computer program stored in a computer readable medium encrypts / decrypts a content file using an encryption / decryption key in a key storage file in a protected area of the storage device. The content file header includes key navigation information indicating the location of the encryption / decryption key in the key storage file. The computer program retrieves the key navigation information from the content file, obtains a location from the key navigation information in the key storage file in which the encryption / decryption key is stored, obtains an encryption / decryption key, and uses the key to encrypt / encrypt the content file. Decrypt In one implementation of this embodiment, a plurality of key storage files each containing m locations are used to store keys. The key navigation information includes an injection, which may be an integer, and the computer program locates and encrypts / encodes in such a keystore file where the key is stored by dividing the index by m to obtain a share of one of the keystore files. Find the store decryption key. The integer portion of the quotient indicates that one of the plurality of key storage files stores the encryption / decryption key, and the remaining portion, the so-called offset in the present invention, indicates the location in such a key storage file in which the decryption / encryption key is stored.

The method executed by the computer program described above is the subject of another aspect of the present invention.

According to another embodiment of the present invention, a nonvolatile computer readable medium stores a key navigation mechanism, and the medium includes at least one protected area and at least one unprotected area. The mechanism includes a key navigation file and at least one key storage file. Each key storage file includes a plurality of keys at corresponding locations in the key storage file, which keys are used for encryption and / or decryption of a corresponding one of the plurality of content files. The mechanism includes a first directory tree in at least one unprotected area of the medium, the first directory tree including a directory comprising a key navigation file and a list of a plurality of content files. The mechanism also includes a second directory tree in at least one protected area of the medium, the second directory tree including a directory comprising a list of keys in at least one key storage file, the two directory trees mirrored each other. (mirror) has a structure.

The systems and methods described above may also be configured to manage content protection information, such as rules governing the use of and / or access to content, instead of or in addition to managing keys. Thus, in one exemplary application, the methods and systems described above may be configured to manage rights objects that control the use and / or access of content files.

Thus, in accordance with another embodiment of the present invention, a rights object navigation file and one or more rights object storage files may be used to facilitate rights object management. The content file controlled by the rights object each includes a header portion containing location information indicating that the rights object storage file includes a rights object used to control access to and / or use of the content file. The rights object navigation file includes state information indicating whether a valid rights object is stored in one or more rights object storage files in one or more locations. This facilitates the process of locating a location in one or more rights object storage files for storing rights object keys. Preferably, the status information indicates one or more locations in one or more rights object storage files in which one or more valid key (s) are not stored.

The rights object navigation mechanism, including the rights object navigation file described above and one or more rights object storage files, may be stored on a non-volatile computer readable medium.

In one implementation of the above embodiment, the rights object navigation file is stored in a public unprotected area of the storage medium and the one or more rights object storage files for storing the rights object may be accessed only by authorized users, applications or devices. Stored in the protected area. For obvious reasons, it is desirable to store one or more rights object storage files in protected areas that are inaccessible to unauthorized access. Thus, by providing a rights object navigation file in the public area that includes state information indicating whether one or more locations in the rights object storage file (s) contain valid rights objects, this greatly improves rights object management performance. Thus, access to the borough area is not required to find out whether a particular rights object in the rights object storage file is valid or not; Instead, this information is readily available in the rights object navigation file that cannot be accessed without authentication. This feature also makes it particularly easy to delete content files and related rights objects. Deletion of a rights object can be performed in one implementation simply by changing the state information in the rights object navigation file, without actually accessing the rights object storage file in the protected area containing the rights object to delete the rights object. Can be.

In accordance with one or more embodiments of the present invention, a rights object navigation file and one or more rights object storage files may be readily used in the process for associating a content file with a rights object. Each entry in the rights object navigation file corresponds to a location in one or more rights object storage files for storing one of a plurality of rights objects. The rights object navigation file may be opened to allow the discovery of entries that do not correspond to valid rights objects at locations in one or more rights object storage files. The rights object is generated and the content file is associated with it. The rights object is then stored at a location in one grouping object storage file corresponding to the entry in the rights object navigation file found.

In one implementation of the above embodiment, the rights object navigation information may be obtained from the location of an entry in the rights object navigation file so that it does not correspond to a valid rights object and this location information is inserted into the header portion of the encrypted file. Thus, in the reverse process, by decrypting the location information in the header portion of the content file, the location of the rights object in the rights object storage file or one of the files can be found and the rights object can be used to access and / or access the content file. Can be retrieved.

According to another embodiment of the present invention, the content file may be encrypted / decrypted using the encryption / decryption rights object of the rights object storage file in the protected area of the storage medium. The header portion of the content file includes rights object navigation information that indicates the location of the rights object in the rights object storage file associated with the content file. The rights object navigation information is retrieved from the header portion of the content file and the location in the rights object storage file where the rights object is stored is obtained from the rights object navigation information. The rights object is then used to obtain and access from the protected area and / or to use the content file in other ways. This process can also be used to find a specific rights object in the rights object storage file if access to and / or use of the content file is required, such location information of the rights object may be found in the header portion of the content file. Can be.

In one particular implementation of the immediately preceding embodiment, a plurality of rights object storage files are used to store rights objects. In this implementation, the rights object navigation information in the header portion of the content file includes an index, which may be an integer. Each rights object storage file contains m locations for storing rights objects. The index is divided by m to get a quotient. The integer portion of the quotient indicates that one of the plurality of rights object storage files stores the rights object, and the remainder, referred to herein as the offset, indicates the location in such a rights object storage file in which the rights object is stored.

Another embodiment of the present invention is directed to a method for invalidating a rights object stored in a rights object storage file and includes rights including state information indicating whether the rights object stored in the rights object storage file is valid or not. Used to control access and / or use of content files by object navigation files. The content file includes a header portion including location information indicating the location of the rights object in the rights object storage file. The location information of the rights object in the rights object file is obtained from the header portion of the content file. In the rights object navigation file, the status information of the rights object is retrieved using the location information. The status information of the rights object in the rights object navigation file is changed to indicate that the rights object is invalid.

Any one of the methods described above can be performed by a computer program executed by a processor, the program being stored in a computer readable storage medium.

According to another embodiment of the invention, a computer program stored on a computer readable medium may be used to facilitate rights object management. The computer program creates one or more rights object storage files if the rights object navigation file and one or more rights object storage files do not already exist. Each content file includes a header portion that includes location information indicating that the rights object storage file contains a rights object for such a content file. The rights object navigation file contains status information indicating whether one or more locations in the rights object storage file of one director contain a valid rights object.

In one implementation of the above embodiment, an entry is found in a rights object navigation file that does not correspond to a valid managed object in at least one rights object storage file. The rights object navigation information for the content file is obtained from the location of the entry in the rights object navigation file. A rights object is generated and associated with the content file. The rights object is stored at a location in at least one rights object storage file corresponding to the entry.

In accordance with another embodiment of the present invention, a computer program stored on a computer readable medium controls access to and / or use of a content file by a rights object in a rights object storage file in a borough region of the storage device. . The content file header includes rights object navigation information indicating the location of the rights object in the rights object storage file. The computer program retrieves the rights object navigation information from the content file, obtains a location from the rights object navigation information in the rights object storage file in which the rights object is stored, obtains the rights object and uses the content file by such rights object; Or approach. In one implementation of this embodiment, a plurality of rights object storage files each containing m locations are used to store rights objects. The rights object navigation information includes an index, which may be an integer, and the computer program divides the index by m for one of the rights object storage files to share, such as the location and rights object in the rights storage file where the rights object is stored. Find it to save. The integer portion of the quotient indicates that one of the plurality of rights object storage files stores the rights object, and the remainder, referred to herein as the offset, indicates the location in such a rights storage file in which the rights object is stored.

According to another embodiment of the present invention, the non-volatile readable medium stores a rights object navigation mechanism, and the medium includes at least one protected area and at least one unprotected area. The mechanism includes a rights object navigation file and at least one rights object storage file. Each rights object store file includes a plurality of rights objects at corresponding locations in the rights object store file, which rights objects are used to control access to and / or use of the corresponding one of the plurality of content files. do. The mechanism includes a first directory tree in at least one unprotected area of the medium, the first directory tree including a directory including a rights object navigation file and a list of a plurality of content files. The mechanism also includes a second directory tree in at least one protected area of the medium, the second directory tree including a directory comprising a list of rights objects in the at least one rights object storage file, the two directory trees being mutually exclusive. It has a mirror symmetrical structure.

The method performed by the computer program described above is a subject of another aspect of the present invention.

The features may be used alone or together in any combination.

1 illustrates a block diagram of a memory system in communication with a host device to illustrate the present invention.

2 is a diagram for explaining the structure of a title key file.

3A is a diagram for explaining the structure of a key navigation file.

FIG. 3B shows a key navigation file in FIG. 3A and a plurality of title key files of the type shown in FIG. 2, and is a diagram for explaining the relationship between them.

4 is a diagram illustrating a directory tree in an unprotected user data area useful for key navigation and key management.

5 is a diagram of a directory tree in a protected area useful for key navigation and key management.

6 is a flowchart illustrating a key navigation mechanism for key management.

7 is a flowchart illustrating a key navigation mechanism for deleting a file to illustrate another feature of the key management system.

8 is a flowchart illustrating a rights object navigation mechanism for rights object management.

9 is a flow diagram illustrating a rights object navigation mechanism for deleting a file to illustrate another feature of the rights object management system.

For the sake of brevity, like elements are identified by like numerals in the present application.

An exemplary memory system that can implement various embodiments of the present invention is illustrated by the block diagram of FIG. As shown in FIG. 1, the memory system 10 includes a central processing unit (CPU) 12 and a buffer management unit (BMU) 14. A host interface module (HIM) 16 and a flash interface module 18, a flash memory 20, and a peripheral access module 22 (PAM). The memory system 10 communicates with a host device 24 via a host interface bus 26 and a port 26a. Flash memory 20, which may be of the NAND type, provides data storage to host device 24. Software code for the CPU 12 may also be stored in the flash memory 20. FIM 18 connects to flash memory 20 via flash interface bus 28 and port 28a. The HIM 16 is suitable for connection to host systems such as digital cameras, desktop or portable personal computers, personal digital assistants, digital media players, MP-3 players, video game players and cellular telephones or other digital devices. Do. Peripheral access module 22 selects appropriate controller modules, such as FIM, HIM, and BMU, to communicate with CPU 12. In one embodiment, all components of the system 10 in a dashed box may be included in a single unit, such as in a memory card or stick 10 'and preferably in a card or stick in the same housing or container. Can be encapsulated.

The buffer management unit 14 includes a host direct memory access (HDMA) 32, a flash direct memory access (FDMA) controller 34, an arbiter 36, a buffer random access memory (BRAM) 38, and A crypto-engine 40. Only one initiator or master (which may be HDMA 32, FDMA 34 or CPU 12) can be active at any time and the slave or target is BRAM 38 The arbiter 36 is a shared bus arbiter. The arbiter is responsible for channeling the appropriate initiator request to the BRAM 38. HDMA 32 and FDMA 34 are responsible for the data transferred between HIM 16, FIM 18 and BRAM 38 or CPU random access memory (CPU RAM) 12a. The operation of HDMA 32 and FDMA 34 is conventional and need not be described in detail herein. The BRAM 38 is used for buffer data transferred between the host device 24, the flash memory 20, and the CPU RAM 12a. HDMA 32 and FDMA 34 are responsible for transferring data between HIM 16 / FIM 18 and BRAM 38 or CPU RAM 12a and indicating sector transfer completion.

First, when data from the flash memory 20 is read by the host device 24, the data encrypted in the memory 20 is transferred to the bus 28, the FDMA 34, the FDMA 34, and the encryption engine 40. The data that is fetched and encrypted through is decrypted and stored in the BRAM 38. The decoded data is transferred from the BRAM 38 to the host device 24 via the HDMA 32, the HIM 16, and the bus 26. The data retrieved from the BRAM 38 may be re-encrypted by the encryption engine 40 before being transferred to the HDMA 32 so that the data sent to the host device 24 is encrypted again, but stored in the memory 20. May be encrypted by other algorithms and / or other keys compared to being decrypted. Preferably, in an alternative embodiment, rather than storing the decoded data in the BRAM 38 in the process described above, the data may be vulnerable to unauthorized access, and the data from the memory 20 may be It may be decrypted and encrypted again by the encryption engine 40 before being sent to the BRAM 38. The encrypted data in the BRAM 38 is then transmitted to the host device 24 as before. This describes the data stream during the reading process.

When data is written to the memory 20 by the host device 24, the direction of the data stream is reversed. For example, if unencrypted data is sent by the host device to the encryption engine 40 via bus 26, HIM 16, HDMA 32, such data is stored in BRAM 38. Before it can be encrypted by the engine 40. Alternatively, unencrypted data may be stored in the BRAM 38. The data is then encrypted before being sent to the FDMA 34 on the way to the memory 20. The recorded data undergoes a multi-level encryption process, preferably the engine 40 completes such processing before the processed data is stored in the BRAM 38.

While memory system 10 of FIG. 1 includes flash memory, alternatively the system may instead include other types of non-volatile memory, such as magnetic disks, optical CDs, as well as all other types of rewritable non-volatile memory systems. And the various advantages described above may equally apply to such alternative embodiments. In an alternative embodiment, the memory is also encapsulated within the same physical body (such as a memory card or stick), preferably along with the remaining components of the memory system.

Title key management

Fig. 2 is a schematic diagram showing the structure of a title key file for explaining one embodiment of the present invention. If multiple encryption / decryption keys are used for digital rights management, it may be convenient to organize and store the keys in a plurality of individual title key files, as shown in FIG. In the embodiment of FIG. 2, the title key file 102 is designed with 127 slots or locations to contain 127 keys. As shown in FIG. 2, file 102 includes a total of 128 slots or locations, and immediately the first slot or location 102a is reserved in the header and is not used to store the key. Initially, all 127 slots or locations may contain 1 or 0, or any value, which is not a valid key value. Preferably, a valid title key entry ("TKE") is successively written to 127 slots or positions by overwriting the initial value, so that if all 127 slots or positions are filled with valid key values, they are It may include the following values: TKE1, TKE2, ... TKE127. Preferably, whether or not a particular title key entry is a valid key is indicated by title key status bits stored in the key navigation file described in FIG. 3A. Thus, by examining the corresponding title key status bits of any particular title key entry in file 102, it is possible to determine whether such an entry is made of or contains a valid key without actually accessing the title key file 102. It is possible.

3A is a schematic diagram of a key navigation file to explain the structure of the key navigation file. As shown in FIG. 3A, the key navigation file 104 includes a number of key file status ("KFS") fields, namely KFS000, KFS001, ... KFS031, KFS032, KFS033, ... KFS063 ... . Each title key status field contains a title key status bit of the corresponding title key file. Thus, the key file status field 104a labeled KFS000 contains 127 title key status bits of 127 title key entries in the title key file 102. If the number of keys used for encryption / decryption exceeds 127, all slots or positions in the title key file 120 are exhausted, so a new title key file needs to be created to store keys exceeding 127. There is. Title key status field 104b is then created in key navigation file 104 for storing title key status bits to indicate the status of excess title key entries in the new title key file. 3A illustrates a situation in which at least 64 title key files are generated, key navigation file 104 includes at least 64 title key status fields, from KFS000 to KFS063. The relationship between the key navigation file 104 and the title key file is described in more detail in FIG. 3B.

As shown in Figs. 3A and 3B, the title key file is named in the format "key_file.xxx", where xxx is the serial number of the title key file. Thus, the first generated key file 102 is given a file name of key_file.000 and the next generated key file is assigned a name of key_file.001.

In one embodiment, each slot or location and entry in key navigation file 104 has a known one-to-one correspondence with the title key entry in that slot or location and a particular slot or location in one of the key files. Has In this manner, in order to check whether a particular title key entry contains a valid key, the location or slot is found in the key navigation file 104 corresponding to such a title key entry in the title key file and the key navigation file ( It may only be necessary to check the key file status bit at that location in 104.

In this embodiment of the present invention, title key entries are sequentially labeled across other title key files as shown in FIG. 3B. Thus, the title key entry in the title key file key_file.000 is labeled TKE1-TKE127. Title key entries in the title key file key_file.001 are labeled TKE129-TKE255. The title key entry in the title key file key_file.002 is labeled TKE257-TKE383. The first location and entry (ie, TKE0, TKE128, TKE 256, ...) of each title key file is reserved for the header, which indicates the size of the file, the version number and the like. May contain other information. Thus, each title key entry has a unique number associated with it, which is one such as 1-127, 129-255, 257-383, or the like. Preferably this unique number is then used to identify a particular location in the key navigation file from which the corresponding key file status bit was found. As shown in Fig. 3B, a key file status bit corresponding to a title key entry is stored at a position in the same sequence as a title key entry via another title key file. For example, as described in FIG. 3B, the key file status bit "KFS [i]" for indicating whether or not the title key entry TKE [i] contains a valid key is defined in the first key file status field KFS000. It is stored in the i th position in the key navigation file 104, which calculates from the first position on top, and the i th position is in a key file status field different from KFS000. In other words, this unique number is unique in every key status field and is the first position at the top of KFS000 across all key file status fields KFS000, KFS001, ..., from key navigation file 104 to the last tee file status entry. Are numbered starting consecutively from.

In this way, by examining the specific location of the key file status bits and the unique number associated with such bits in the sequence of unique numbers in the key navigation file 104, the specific title key file, and the location in such a file, is then: Using the simple procedure described, one can easily determine that a corresponding title key entry can be found. So the opposite process is also true. Knowing the unique number associated with a particular key title key file and the location of that particular title key entry in such a file, the corresponding key file status bit for such an entry can be found in the key navigation file 104.

In this one embodiment, the process for finding a title key entry corresponding to a particular key file state in the key navigation file 104 may be implemented as follows. The unique number associated with each title key entry and corresponding key file status bit is referred to as the key search index ("KNI"). Thus, the KNI values 0, 128, 256, 384 ... (N + 128) are illegal, where N is an integer. Therefore, the KNI is also the offset of the key file status bit in the key navigation file 104 from the first status bit directly in the header of KFS000. By noting the position, offset, and corresponding value of the KNI of a particular status bit in the key navigation file 104, the position of the corresponding title key entry can be easily determined. This is done by dividing the number of slots in each title key file and key file status field, i.e. by 128 in the embodiment of FIG. 3B. The integer portion of the quotient then provides the serial number of the title key file containing the corresponding title key entry. In other words, the serial number of the title key file containing the title key entry is given by the integer portion of KNI / 128. The specific location of such a title key entry in a title key file containing such an entry may be found from the rest of this portion or by KNI% 128 or KNI mod 128; This value is the offset of the specific position of this title key entry from the top entry in such a title key file where the title key entry is found.

In one embodiment described in FIG. 3B, suppose we want to find a specific title key file and location within such a file for title key entry i (TKE i) such that key search index KNI is i. Thus, the title key entry representing the state of such a title key entry is KFS [i] in the key navigation file 104. In the specific example described in FIG. 3B, such a status bit is found in the key file status field 001, ie KFS001. The specific title key file where such a title key entry can be found is given by i% 128 or i mod 128. In the illustrated example of FIG. 3B, i has a value between 129 and 255 so that the integer portion of i divided by 128 is 1 and it is easy to determine that the title key file key_file.001 contains the corresponding title key entry i. The remainder of the division is then determined by performing the operator i mod128, which provides the offset of the title key entry TKEi from the top entry in the title key file key_file.001. Thus, by two very simple operators as described above, a location within such a file containing a title key entry corresponding to a particular location in a particular title key file and key navigation file can be found.

In the above embodiment, each title key file contains 128 entries of 16 bytes. Obviously, the title key file may include a number of entries other than 128, where each entry may have a number of bytes different from sixteen. Thus, if each title key file has m entries, where m is any positive integer, then the above operator needs to be changed so that the KNI or key search index is divided by m instead of 128. The offset is found by i mod m instead of finding the offset of the title key entry TKEi from the top entry in such a title key file. All such changes are within the scope of the present invention.

Instead of using the operators i / m and i mod m and the unique number KNI as described above to find the key in the title key file or to find the status bits in the key navigation file, the entries in the key navigation file and each A one-to-one correspondence between TKEs of the title key file may be established by a look-up table. The CPU 12 may need to examine the lookup table to find the location of the corresponding key given the location of the status bits in the key navigation file, and vice versa (ie, in a particular title key file). To find the status bits in the key navigation file that reveal the key state given by the location of the key). Such and other changes are within the scope of the present invention.

In one embodiment, only 7 of 16 bytes are used for each title key entry for the value of the key for encryption / decryption. Preferably, the key value is encrypted using another key. In the embodiment of FIG. 3B, if the title key status bit is made of a value of zero, it is a title key entry that is busy, which is reserved as in the case of the header of each title key file, or Or a corresponding title key entry contains a valid key, and therefore is not available for storing a new key. If the title key status bit is set to 1, this indicates that the corresponding title key entry is empty or does not contain a valid key, such that the corresponding slot or position in the title key file is the title key entry in that slot or position. Can be used to store the encryption / decryption key by overwriting the.

The length of the key navigation file is not defined by the number of title key files but is determined. In the embodiment described in Figures 3A and 3B, the key navigation file includes a 512 byte record. Therefore, even if the length of the file is not defined, it is within a multiple of 512 bytes in the embodiment of Figs. 3A and 3B. New records can be added to the file if needed. The title key status bit value is a Boolean number, while the serial number, key search index of the title key file is decimal in the embodiment of FIGS. 3A and 3B.

4 is a schematic diagram of a directory tree structure 130 in an unprotected user data area used to describe one embodiment of the present invention. The directory tree structure 130 in FIG. 4 is a file stored in the flash memory 20 in which the directory structure can be accessed by any user, device or application without authentication, because it is stored in the unprotected user data area. to be. As shown in Fig. 4, the directory tree structure has a root directory and two side branches, namely, the Player 1 directory and the Player 2 directory. Player 1 or Player 2 can be any user, device or application. Two branches allow easy access by two different players. The Player 1 directory lists a number of other content files such as "Mysong, MP3", "Another.MP3" ... and key navigation file "KNF.bin". The Player 2 directory contains a similar list of content files and other key navigation files, "KNF.bin". Thus, when Player 1 accesses the user data area, Player 1 is directed towards the Player 1 directory and content files and key navigation files under such a directory. The same is true for access by Player 2, which is directed towards content files within the Player 2 directory as well as key navigation files in such directories. Thus, when Player 1 creates a content file, this file is created and added to the list under the Player 1 directory. If a content file is created for Player 2, this new content file is also listed in the Player 2 directory.

The content files in tree 130 (eg, "Mysong, MP3", "Another.MP3" ...) are encrypted using the keys stored in the directory in tree 150 in FIG. In some applications, both the encrypted content file and the unencrypted content file (not shown in FIG. 4) may also be stored in the same unprotected user data area that can be accessed without authentication.

FIG. 5 is a schematic diagram of the directory tree 150 in a protected area in the memory device 20 in which the directory trees 130 and 150 of FIGS. 4 and 5 are mirror-symmetric with each other. Thus, in FIG. 5, the directory tree has a root directory as well as a player 1 directory and a player 2 directory. The Player 1 directory lists a title key file key_file.000 that contains a number of different title key entries in the tree 130 for encrypting and / or decrypting content files in the Player 1 directory. The Player 2 directory also includes a title key file key_file.000 that contains a number of title key entries. Note that even if two title key files under the two directors have the same name (ie key_file.000), they cannot be confused because they are in different directories. The same thing is true for the key navigation file in two directories in the tree 130 in FIG.

The two directory trees 130, 150 are mirror symmetric with each other because they have the same branch, that is, the player 1 directory and the player 2 directory, although the contents of directory players 1 and 2 are different in the two trees 130, 150. It is possible that two directories between each tree 130 and tree 150 have more branches at the same level, such as Player 1 and Player 2, such as Player 3 (not shown in FIGS. 4 and 5), and the like. Do. It is also possible for two directories Player 1 and Player 2 to have subdirectories. For example, the player 1 directory in tree 130 may have two subdirectories, one for audio files (not shown in FIG. 4) and one for video files. The audio file subdirectory may include a list of audio files, such as songs, and key navigation files for searching among such audio files. The video subdirectory may contain video files and key navigation files for searching between such video files. In such an event, directory tree 150 in FIG. 5 also has a similar tree structure. Thus, the Player 1 directory in tree 150 may have two different subdirectories, namely audio and video subdirectories (not shown in FIG. 5). The video subdirectory contains a list of title key files or files, each containing a title key entry used to encrypt / decrypt the video file in the video subdirectory of directory tree 130. Directory tree 150 also includes one or more title key files, each containing one or more title key entries, wherein the audio subdirectory each includes a title key entry used to encrypt / decrypt the corresponding audio file listed in the audio subdirectory of directory tree 130. You can have audio subdirectories under a directory. As described below, having directory trees 130, 150 that are mirror symmetric with respect to each other in the unprotected and protected areas facilitates the operation of the key navigation mechanism.

Before any protected content file is created in memory device 20, there is typically no key storage file or key navigation file in memory device 20. In such an event, when a first content file to be protected is created, the key manager mentioned in the present invention as a key navigation mechanism also generates a first title key storage file in the protected area and a key navigation file in the unprotected user area.

6 is a flow chart illustrating a process or method performed by a key navigation mechanism. The mechanism for performing the process of FIG. 6 may include computer program code that is executed and stored by the host device 24 that sends instructions to a memory system where content files, title key files, and key navigation files are stored. Alternatively, the mechanism may include computer program code stored in flash memory 20 that is loaded into and executed by the CPU 12. Thus, the computer program for the key navigation mechanism of FIGS. 6 and 7 can be stored in a computer readable medium that is part of or coupled to host device 24; Alternatively, such a computer program may be stored in flash memory 20 where title key files, key navigation files and content files are stored. All such changes are within the scope of the present invention.

Referring to FIG. 6, the process of the mechanism of FIG. 6 begins if the protected content file is to be opened or if a protected content file is desired to be created (block 202). The key navigation mechanism determines whether the content file exists (diamond 204). If the content file does not exist, this means that the content file needs to be created and the host device 24 or the CPU 12 goes on to create the file, as for player 1 in the directory tree 130. (Block 206). After the content file is created, the key navigation mechanism checks whether the key navigation file already exists or has already been created (diamond 207a). If it does not exist or has not been created, the mechanism creates a key navigation file (block 207b). If already present or created, the mechanism opens the key navigation file found in the same directory as the newly created content file, in a directory such as directory 130 described in FIG. 4 (block 208). In both cases, the mechanism examines the key navigation file in the Player 1 directory in the tree 130 and finds a first key entry with a " empty " status. The offset of the "empty" state in the key navigation file utilizes the above embodiment using KNI and provides a key navigation index (KNI) (blocks 208, 210).

If a title key file and a key navigation file are used in the above transition, the position or title key entry in the title key file is used sequentially. This means that if one encryption / decryption key is generated and needs to be stored in the title key file, the slot or position in the title key file starts with the title key entry 1 in the title key file key_file.000 and stores the keys sequentially. It is meant to be used to. After such a key is stored and forms a key entry, TKE1, or part thereof, the corresponding key file status bit KFS [1] value now contains a valid key because this location is not a reserved location for the header. It is changed from 1 to 0, indicating that it is not empty and that it is in use now. Initially, all key file status bits have a value of 1 except for the key file status bits for 0, 128, 256, ... which have a value of zero.

After the KNI is obtained, the key navigation mechanism then computes the same nnn as the key file index or integer portion of KNI / 128 (block 212), with each title key file having 128 slots or locations. nnn or the key file index is the integer part of the number KNI / 128. This nnn or key file index value is the serial number of the title key file. This offset in the title key file is then obtained by calculating the quantity KNI% 128 or KNI mod 128 (block 214).

As mentioned above, the content file is created in a directory, such as the Player 1 directory in directory tree 130 of FIG. In order to obtain the location in the title key file in the protected area for storing the encryption / decryption key for encrypting and / or decrypting the generated content file immediately, the key navigation mechanism then uses the public partition name for the unprotected user data area. Is replaced by a protected partition name for the protected area, thereby replacing the access path configured according to the directory tree 130 in the unprotected user data area with the access path configured according to the directory tree 150 in the protected area or partition. Convert (block 216). The key navigation mechanism then forms a key file name: "key_file.nnn" (block 218). The key navigation mechanism forms the full key file name (block 220). As an example, assume that Player 1 is creating a new song file to be encrypted along blocks 208, 210, 212, 214, 216, 218 and 220. In such an event, the generated full key file name would be "prot_partition / player1directory / key_file.nnn".

The key navigation mechanism then checks to see if a title key file exists with this key file name (diamond 221a). If this title key file does not exist, the mechanism creates a title key file and adds it to the appropriate directory (eg, player 1) in directory tree 150 (block 221b). If this title key file exists, the mechanism opens the title key file using the access path according to the full key file name (block 222). The key navigation mechanism then checks whether the content file originally existed before block 206 (diamond 224). In the example above, such a content file does not exist prior to its creation at block 206, so the key navigation mechanism goes to block 226 to insert the KNI in the file header of the generated file. A content encryption key (CEK) is generated by the encryption engine 40 and used to encrypt the generated file (block 228). The newly generated encryption file is added to the tree 130 as a directory player 1 in the memory device 20. This generated key is encrypted and inserted into the title key file identified at block 212 and at the location identified by the offset obtained at block 214 (block 230), and a new title key file to directory player 1 in tree 150. It is added as a title key entry. The key navigation mechanism then closes the title key file (block 232) and the player 1 in the tree 130 where the key file status bits are found by using the value of KNI as an offset in the key navigation file in the player 1 directory in the tree 130. Change the value of the corresponding status bit in the key navigation file to the directory from 1 to 0. The key navigation file is then closed (blocks 234, 236).

The above is a process for a key navigation mechanism that uses two directory trees 130, 150 when an encrypted (and / or decrypted) content file is first created. If the key navigation mechanism wishes to decrypt the content file such that it is requested to find the decryption key needed to decrypt the content file, the key navigation mechanism of FIG. 6 operates as follows. The key navigation mechanism may open the protected content file in a particular directory, such as the Player 1 directory in tree 130, because the content file already exists, and goes to block 252. The key navigation mechanism then retrieves the value KNI from the file header of the content file (block 252). When the key navigation mechanism opens the protected content file, it operates within the directory tree 130 in the unprotected user data area. For example, if the protected content file is one of the song files in the Player 1 directory, such as the song "Mysong.MP3", then the access path to this content file is organized according to directory tree 130. The key navigation mechanism then finds the nnn or key file index of any title key file in which the decryption key for decrypting (and / or encrypting) the content file is stored, and the offset indicating the location of the key in such a title key file. To operate in blocks 212-222 in the manner described above. The key navigation mechanism also converts access paths along the directory tree 130 to public or unprotected user data areas from protected areas to access paths configured along directory tree 150 and along the blocks 216, 218 and 220 in the protected area. Form the full key file name for the decryption key. After the authentication process, the key navigation mechanism then opens the title key file in the protected area along with the full key file name so that the content decryption key is readily available for retrieval (block 222). The key navigation mechanism then checks whether the content file exists before the above-described operation. In this example, a mechanism exists to go to block 254 to retrieve the encrypted content encryption key from the key entry offset in the appropriate title key file (block 254). The content encryption key is then used to decrypt / encrypt the content file that will be decrypted and protected by encryption or protected (block 256).

Using the above-described key navigation file and title key file structure is particularly simple when the content file is deleted. This is illustrated in the flow chart of FIG. Thus, a key navigation mechanism for this purpose, which may be a computer program stored in and executed by the memory system 10 or the host device 24, first identifies in the directory the protected content file to be deleted (block 302). The content file may be in an unprotected notarized area of memory 20. The key navigation mechanism then opens the content file, obtains a KNI from the file header, and closes the file (block 304). The mechanism then opens the key navigation file in the same directory as the content file (block 306). For example, if the content file to be deleted is in the Player 1 directory in directory tree 130, for example, the bit offset is found in the key navigation file in the same directory (in this case, Player 1 directory) as the content file. The key navigation mechanism is then used as an offset from the first entry in the key navigation file to find the location of the key file status bit indicating the status of the title key entry in the title key file used to encrypt / decrypt the content file being deleted. Use KNI. The key file status bit found at the offset position from 0 to 1 is then reset, indicating that the corresponding title key entry TKE in the title key file of the file status bit does not contain a valid key (block 308). Therefore, this indicates that the location of this corresponding TKE in the title key file can be used to store the new key and is essentially "empty". You don't actually have to go to the protected area (typically requesting authentication) and you don't have to delete the key at this location in the title key file. The key navigation mechanism closes the key navigation file and deletes the content file (blocks 310 and 312).

Rights Object Management

The above-described system for managing keys can also be used to manage other types of content protection information, such as rules specifying that a limited number of content files can be accessed before or during a predetermined expiration date. have. In DRM, such rules are handled with the content encryption / decryption keys used to protect content in objects known as rights objects. To find out how an encrypted content file can be used and / or accessed, the rights object is first looked up, the encryption / decryption key is extracted from it, and the rules control its use. The content file is then decrypted / encrypted using the key and the content can be accessed. Sometimes a content file may be downloaded or otherwise received, and its rights object is needed to be found. If the file is encrypted if it is downloaded, it is necessary to purchase the right for access; In such an event, the rights object will be supplied and can be downloaded after purchase. If the downloaded file is not encrypted, then a rights object can be created to protect the content file. Once the rights object is obtained, the key in the rights object is extracted from the rights object and the content file is encrypted or decrypted using the key. The file can then be further treated as appropriate. Conversely, after the file is created, a rights object can be created, and the object contains the key used for encryption / decryption.

If additional security is required, the decrypted content file can be re-encrypted using a key different from the key in the rights object. In this way, an unauthorized user who also has access to the rights object for the content file will not be able to access such re-encrypted content file. Thus, the user who has downloaded the content file can generate a key different from the key in the rights object obtained from the rights issuer and re-encrypt the content file after decrypting using the key in the rights object obtained from the rights issuer. The key in the rights object is then replaced by the key generated by the user. Alternatively, the user can simply encrypt the content file using the generated key without first decrypting the file so that the content file can be decrypted by two different keys, i.e. (the content file is decrypted by the first key in the rights object). The key from the issuer of the rights, and the second key generated by the user available only to the user who had generated it. The user then stores an additional second key in the rights object as well.

8 is a flow diagram illustrating a rights object (RO) navigation mechanism for rights object management. The RO navigation mechanism that performs the process of FIG. 8 may include computer program code stored in and executed by a host device 24 that sends instructions to a memory system where content files, RO files, and key navigation files are stored. have. Alternatively, the mechanism may include computer program code stored in flash memory 20 that is loaded into and executed by CPU 12. Thus, the computer program for the RO search mechanism of FIGS. 8 and 9 can be stored in a computer readable medium that is connected to or is part of the host device 24; Alternatively, such computer programs may be stored in flash memory 20 where RO files, rights object navigation files and content files are stored. All such variations are within the scope of the present invention. On the one hand, the comparison of Figs. 6, 7 and on the other hand, Figs. 8, 9 shows that they are quite similar, so that the RO management process of Figs. 8 and 9 is quite similar to the key management process of Figs. 6 and 7, respectively. Do.

In such an event, the architecture and concept for RO management similar to key management described above is similar to that described in FIG. 3B, in which a label of RO entry (ROE) is labeled across the RO file (similar to the concept for KNI). Can be used, as is the RONI used to attach. The status bit ROS [i] in the RO search file is used to indicate whether the corresponding i th RO is valid in one of the RO files. The RO navigation file can be stored in a public partition or area along with the content file in a directory in the directory tree in the same manner as shown in FIG. 4 including key management. The RO file is stored in a protected partition or area in a directory in the directory tree in the same manner as shown in FIG. 5 for key management, the trees in the two areas being mirror symmetric with each other (not shown).

Referring to FIG. 8, the process of the mechanism of FIG. 8 begins when one wishes to open or download a protected content file (block 402). The RO navigation mechanism determines whether the content file has been downloaded (diamond 404). If the content file has not been downloaded, this means that the content file already exists so that it does not need to be downloaded. Assuming the content file has been downloaded and needs to be protected, the mechanism goes to block 406 and stores the file in the assigned directory in the public area (similar to the public area in FIG. 4). The RO search mechanism checks whether the RO search file exists in the same directory (diamond 407a). If not present, the mechanism then creates an RO search file (block 407b). If present, then the mechanism opens the RO search file found in the same directory as the downloaded content file, similar to that found in FIG. 4 (block 408). In both cases, the mechanism examines the RO search file in the appropriate directory in the directory tree and finds the first RO entry with a "empty" or "not valid" status. The offset of the "empty" or "invalid" state in the RO search file provides the RO search index (RONI), using the above embodiment using RONI (blocks 408, 410).

If the RO file and the RO search file are used in the above transition, the position or RO entry in the RO file is used sequentially. This means that if one RO is created and needs to be stored in the RO file, the location or slot in the RO file starts with RO entry 1 into the RO file RO_file.000 and is used to store the RO sequentially. After such an RO is stored and forms the first RO entry, or part thereof, the corresponding RO file status bit ROS [1] value contains the current valid RO since this position is not reserved for the header. It is converted from 1 to 0, which means it is not empty and is currently in use. Initially, all RO file status bits have a value of 1 except for the RO file status bits for 0, 128, 256, ... which have a value of zero. However, it will be appreciated that instead of this embodiment, a lookup table can be used instead as in the case of a key navigation mechanism; All such changes are within the scope of the present invention.

After the RONI is obtained, the RO search mechanism then computes the same nnn as the RO file index or integer portion of RONI / 128 (block 412), with each RO file having 128 slots or locations. The nnn or RO file index is an integer part of the number RONI / 128. This nnn or RO file index value is the serial number of the RO file. The offset in this RO file is then obtained by calculating the quantity KNI% 128 or KNI mod 128 (block 414).

As mentioned above, the downloaded content file is assigned to a directory (such as a directory similar to the Player 1 directory in directory tree 130 of FIG. 4). In order to obtain a location in the RO file in a protected area for storing the RO to access and / or control the use of the downloaded content file directly, the RO navigation mechanism is then unprotected, in a manner similar to that in FIG. 6. By replacing the public partition name for the protected user data area with the protected partition name for the protected area, an access path constructed along the directory tree in the unprotected user data area is configured according to the directory tree in the protected area or partition. Convert to an access path (block 416). The RO search mechanism then forms an RO file name: "RO_file.nnn" (block 418). The RO search mechanism then forms the full RO file name (block 420). As an example, assuming that player x creates a new content file controlled by an RO that is created or downloaded, the full RO file name for which the RO is to be stored is represented by blocks 408, 410, 412, 414, 416, 418 and 420. It is configured accordingly. In such an event, the full RO file name generated would be "prot_partition / playerxdirectory / RO_file.nnn".

The RO search mechanism then checks to see if the RO file exists with this RO file name (diamond 421a). If this RO file does not exist, the mechanism creates the RO file and adds it to the appropriate area in the directory tree (eg, player x) in the protected area or partition (block 421b). If this RO file exists, the mechanism opens the RO file using the access path according to the full RO file name (block 422). The RO navigation mechanism then checks whether the content file originally existed at block 406 (diamond 424). In the above example, since such a content file has been downloaded, the RO navigation mechanism goes to block 426 to insert the RONI into the file header of the downloaded file. Thus, the RONI also serves to associate the content file under control with each RO, while utilizing the functionality described above for RO navigation and management.

The RO (including the key) is generated by the encryption engine 40 or obtained and generated by another method (e.g., a purchase after purchase) or so obtained is used to encrypt the downloaded file (block 428). . The newly created encrypted file is added to the directory player x of the tree in the public area or partition in the memory device 20. This RO is encrypted and inserted into the RO file identified at block 412 at the location indicated by the offset obtained at block 414 (block 430), and a new RO entry as a RO file to directory player x in the tree in the protected partition or region. Is added as. The RO navigation mechanism then closes the RO file (block 432), and the player in the tree in the aerial area is found by using the value of RONI as the offset in the RO navigation file in the player x directory in the player x directory in the tree in the public area. Change the value of the corresponding status bit in the RO search file into the x directory from 1 to 0. The RO search file is then closed (blocks 434, 436).

The above is a process for an RO search mechanism that uses two directory trees when a content file associated with an RO is first downloaded and encrypted (and / or decrypted). If the RO navigation mechanism wishes to access an existing content file (i.e. not downloaded) to be requested to find the RO needed to access the content file, the RO navigation mechanism of FIG. 8 operates as follows. The RO navigation mechanism can open the protected content file in a particular directory, such as the player x directory in the public area, because the content file already exists, and goes to block 452. The RO navigation mechanism then retrieves the value RONI from the file header of the content file (block 452). When the RO navigation mechanism opens a protected content file, it operates within the directory tree in the unprotected user data area. For example, if the protected content file is one of the song files in the player x directory, then the access path to such content file is organized according to directory tree 130. The RO navigation mechanism then blocks 412 in the manner described above to find the nnn or RO file index of any RO file in which the RO associated with the content file is stored, and an offset indicating the location of the RO in such a RO key file. Perform the operation at -422. The RO navigation mechanism also converts access paths from public areas to public or unprotected user data areas along the directory tree to access paths configured from protected areas along the directory tree, and along the blocks 416, 418, and 420 to decrypted ROs in the protected areas. Form the full RO file name. After the authentication process, the RO search mechanism then opens the RO file in the protected area along with the full RO file name that is readily configured for RO to be searched (block 422). The RO search mechanism then checks whether the content file exists before the operation described above. In this example, a mechanism exists to go to block 454 to retrieve the encrypted RO from the RO entry at the offset in the appropriate RO file (block 454). The RO is then decrypted and the key is used to decrypt / encrypt the content file following the rules in the RO (block 456).

9 is a flow diagram illustrating a rights object navigation mechanism for deleting a file to illustrate another characteristic of a rights object management system. Using the above-described RO search file, RO file structure, the content file is particularly simple when the content file is deleted. This is illustrated in the flow chart of FIG. Thus, the RO search mechanism for this purpose, which may be a computer program stored in and executed by the memory system 10 or the host device 24, first identifies in the directory the protected content file to be deleted (block 502). The content file may be in an unprotected notarized area of memory 20. The RO navigation mechanism then opens the content file, obtains an RONI from the file header, and closes the file (block 504). The mechanism then opens the RO search file in the same directory as the content file (block 506). For example, if the content file to be deleted is in the player x directory in the directory tree in the public domain or partition, for example, the bit offset is found in the RO navigation file in the same directory as the content file (in this case the player x directory). do. The RO search mechanism then uses the RONI as an offset from the first entry in the RO search file to find the location of the RO file status bit that indicates the status of the RO entry in the RO file associated with the deleted content file. This resets the key file status bit found at the offset position from 0 to 1, thereby indicating that the corresponding RO entry (ROE) in the RO file of the file status bit does not contain a valid RO (block 508). Therefore, there is no need to actually go to the protected area (typically requesting authentication), and there is no need to delete the RO at this location in the RO file. The RO navigation mechanism closes the RO navigation file and deletes the content file (blocks 510 and 512).

While the invention has been described above with reference to various embodiments, it is understood that changes and modifications may be made without departing from the scope of the invention, which should be defined only by the appended claims and their equivalents. For example, a process similar to that of FIG. 6 may be performed to find a location in one of the title tee storage file (s) for storing and decrypting the key for generated decryption, and to encrypt the existing file. It can be applied to find the encryption key present in one of the). The key or RO may be used for the protection of any content, including media titles such as songs, movie games, as well as other types of content with or without titles. The search or location information may be stored in the header and in other parts of the content file, such as in the file name. All references mentioned in the present invention are incorporated by reference.

Included in the present invention.

Claims (101)

A computer readable medium storing a computer program for facilitating management of a plurality of keys, comprising: The computer program generates a key navigation file and one or more key storage files if one or more of the key navigation file and the one or more key storage files do not exist, and each of the key storage files has a corresponding location in such a key storage file. Used or intended to include one or more keys in each of said keys, each of said keys being used or intended to be used for encryption and / or decryption of a corresponding one of a plurality of content files, each content file comprising a header portion Wherein the location information in the header portion of each content file indicates one of the key storage file (s) from which the corresponding key was found, and the corresponding location of such a key in such a key storage file, wherein the key navigation file Status indicating whether the valid key is stored in one or more locations in one or more keystore files Computer-readable media containing information. The method of claim 1, The key navigation file and one or more key storage files are stored on a storage device, the storage device including at least one protected area and at least one unprotected area, wherein the at least one protected area is accessible only to an authenticated user. And if the one or more key storage file (s) does not exist, the computer program generates the one or more key storage files for storing the encrypted key in at least one protected area. The method of claim 2, And the computer program generates the key navigation file in the at least one unprotected area if the search file does not exist. The method of claim 1, The key navigation file includes an entry, each of the entries in the key navigation file corresponding to a location in one or more key storage files for storing one of a plurality of encryption / decryption keys, wherein the valid key is such a location. A computer readable medium providing status information about whether or not it is stored on a computer. The method of claim 4, wherein And the computer program finds, from the status information provided by the entry in the key navigation file, an entry that provides status information indicative of a corresponding location in one of the key storage files for which no valid key is stored. The method of claim 5, wherein The computer program generates a key for encrypting and / or decrypting one of the plurality of content files, and stores the key generated at the corresponding location in one of the key storage files indicated by the found entry, such content A computer-readable medium for inserting location information in the header of a file. The method of claim 6, Each of the entries in the key navigation file corresponds to a different value of index i, each of the index values is associated with status information of a corresponding location in one or more key storage files, and the computer program uses the generated key. Inserting the index i for the entry found in the key navigation file into the header portion of the corresponding content file being encrypted / decrypted. The method of claim 7, wherein The computer program uses N key storage files numbered from 1 to N, where N is greater than 1 and each of the N key storage files has m locations for storage of m keys, each being a positive integer. And an integer portion of the number i / m represents a particular file of the N key storage files in which the corresponding key is stored or to be stored, and i mod m represents the corresponding key in the specific key storage file corresponding to the entry found. Indicating a location, the computer program performing an operation to find an integer portion of the number i / m and to find i mod m. The method of claim 8, And the computer program finds, from the integer portion, a key storage file used to store keys generated among N key storage files. The method of claim 9, And the computer program uses i mod m to find the corresponding location in the key storage file used to store the generated key. The method of claim 1, The key navigation file comprises a plurality of bits, each of the bits indicating whether a valid key is stored at a corresponding location in one or more key storage files. The method of claim 1, The computer program generates the key navigation file and the one or more key storage files in a storage device when one or more of the key navigation file and the one or more key storage files do not exist, and the device is separate from the media. Readable Media. The method of claim 1, The computer program generates the key navigation file and the one or more key storage files in a storage device when one or more of the key navigation file and the one or more key storage files do not exist, and wherein the medium is part of the device. Readable Media. The method of claim 1, And the computer program uses location information in the header portion of the content file to find a corresponding location in a key storage file that is to be used or to be used to store a key corresponding to each content file. A non-volatile computer readable medium storing a key navigation mechanism, the mechanism comprising a key navigation file and at least one key storage file, each key storage file having a plurality of keys at corresponding locations in such key storage file. Wherein the key is used for encryption and / or decryption of a corresponding content file among a plurality of content files, each content file including a header portion, and information in the header portion of each respective content file (s). Denotes one of the key storage file (s) for which a corresponding key was found, and a corresponding location of such a key in such a key storage file, wherein the key navigation file is one or more locations in the at least one key storage file. A non-volatile computer readable medium containing information indicating whether or not it contains. The method of claim 15, And the medium comprises a nonvolatile flash memory cell in a memory card. The method of claim 15, The medium includes at least one protected area and at least one unprotected area, the protected area is accessible only to an authenticated user, the at least one key storage file is stored in at least one protected area, the key navigation The file is stored in at least one unprotected area. A nonvolatile computer readable medium storing a key navigation mechanism, the medium comprising at least one protected area and at least one unprotected area, the mechanism comprising: A key navigation file and at least one key storage file; A first directory tree comprising, in at least one unprotected area of the medium, a directory comprising a list of a plurality of content files and a key navigation file; And A second directory in at least one protected area of the medium, the second directory comprising a directory comprising a list of keys in at least one key storage file, each of the key storage files having a corresponding location in such a key storage file And a plurality of encrypted keys, wherein each of the keys is used for encrypting and / or decrypting a corresponding one of a plurality of content files, the two directories having a mirror-symmetric structure with each other. Computer readable media. A computer readable medium for storing a computer program that decrypts / encrypts a content file using a decryption / encryption key in a key storage file in a protected area of a storage device, wherein the content file is a key storage file for decrypting / decrypting a content file. And key navigation information indicative of an access path to a decryption / encryption key in. Retrieve key navigation information from the content file; Obtaining a location in a key storage file from the key navigation information in a protected area of a storage device in which the decryption / encryption key is stored; Obtain a decryption / encryption key from a key storage file in a protected area of the storage medium using the obtained location; And And decrypt / encrypt a content file using the decryption / encryption key. The method of claim 19, The computer program uses a plurality of key storage files each having m locations for storing keys, the key navigation information includes an index, and the computer program divides the index by m to obtain a share. In order to obtain an integer equal to the integer part of the quotient, and to obtain an offset equal to the remainder of the quotient, one of a plurality of key storage files is stored with a decryption / encryption key and the decryption / encryption key. Computer-readable medium for finding a location in such a key storage file. The method of claim 20, Wherein the integer indicates that one of the one or more key storage file (s) stores a decryption / encryption key and the offset indicates a location in such a key storage file where the decryption / encryption key is stored. The method of claim 19, The storage device includes an unprotected area, and the computer program also converts an access path to a location in the unprotected area into an access path for accessing the protected area. The method of claim 22, The storage device is: A first directory tree comprising a directory in the unprotected area of the medium, the directory including a list of a plurality of content files and at least one key navigation file; And A second directory tree comprising a directory containing at least one key storage file in at least one protected area of the medium, the two directory trees having a structure that is mirror symmetric with each other, The computer program reads a computer for converting an access path for accessing a location in the unprotected area into an access path for accessing a location in a key storage file in which a decryption / encryption key is stored using the two directory trees. Media available. The method of claim 19, And the medium is part of the storage device. A computer readable medium storing a computer program for facilitating management of a plurality of rights objects, the computer program comprising: a rights object navigation file and one if one or more of the rights object navigation file and one or more rights object storage files do not exist; Generate more than one rights object storage file, each of the rights object storage files being used or intended to include one or more rights objects in a corresponding location in such rights object storage file, each of the rights objects being a plurality of Used or intended to control the use and / or access of a corresponding one of the content files, each content file includes a header portion, and the location information in the header portion of each content file is determined by the corresponding rights object. One of the stored rights object storage file (s), and such A corresponding position of such a rights object in the rights object storage file, wherein the rights object navigation file includes computer information including status information indicating whether a valid rights object is stored in one or more locations in the one or more rights object storage files. Media available. The method of claim 25, The rights object navigation file and one or more rights object storage files are stored on a storage device, the storage device including at least one protected area and at least one unprotected area, wherein the at least one protected area is for an authenticated user only. The computer program may generate the one or more rights object storage files for storing the encrypted rights object in at least one protected area if accessible and one or more rights object storage file (s) do not exist. . The method of claim 26, And the computer program always generates the rights object navigation file in at least one unprotected area if no rights object navigation file exists. The method of claim 25, The rights object navigation file includes an entry, each of the entries in the rights object navigation file corresponding to a location in one or more rights object storage files for storing one of a plurality of rights objects, wherein the effective rights object is the same. A computer readable medium providing status information about whether it is stored in the same location. The method of claim 28, The computer program reads from the status information provided by the entry in the rights object navigation file an entry that provides status information indicative of a corresponding location in one of the rights object storage files in which no valid rights object is stored. media. The method of claim 29, The computer program generates a rights object for controlling the use and / or access of the plurality of content files, and stores the rights object generated at the corresponding location in one of the rights object storage files indicated by the found entry, A computer-readable medium for inserting location information into the header of such a content file. The method of claim 30, Each of the entries in the rights object navigation file corresponds to a different value of index i, each of the index values is associated with status information of a corresponding location in one or more rights object storage files, and the computer program generates a generated right. And insert the index i for the entry found in the rights object navigation file into the header portion of the corresponding content file controlled using the object. The method of claim 31, wherein The computer program uses N rights object storage files numbered from 1 to N, where N is greater than 1 and each of the N rights object storage files is a positive integer, m for storage of m rights objects. And an integer portion of the number i / m represents a particular file of the N rights object storage files in which the corresponding rights object is stored or is to be stored, and i mod m stores the specific rights object corresponding to the entry found. Indicating a position of a corresponding rights object in a file, said computer program performing an operation to find an integer portion of the number i / m and to find i mod m. The method of claim 32, And the computer program finds, from the integer portion, a rights object storage file used to store a rights object generated among N rights object storage files. The method of claim 33, wherein And the computer program uses i mod m to find a corresponding location in the rights object storage file used to store the generated rights object. The method of claim 25, The rights object navigation file comprises a plurality of bits, the bits indicating whether a valid rights object is stored at a corresponding location in one or more rights object storage files. The method of claim 25, The computer program generates the rights object navigation file and the one or more rights object storage files in a storage device when one or more of the rights object navigation file and the one or more rights object storage files do not exist, and the storage device is a medium. Computer-readable media separate from the computer. The method of claim 25, The computer program generates the rights object navigation file and the one or more rights object storage files in a storage device when one or more of the rights object navigation file and the one or more rights object storage files do not exist, and the medium is the device. Computer-readable media that are part of. The method of claim 25, And the computer program uses location information of the header portion of the content file to find the corresponding location in the rights object storage file that is to be used or to be used to store the rights object corresponding to each content file. A non-volatile computer readable medium storing a rights object navigation mechanism, the mechanism comprising a rights object navigation file and at least one rights object storage file, wherein each rights object storage file corresponds to such a rights object storage file. Includes a plurality of rights objects, wherein the rights objects are used for use and / or access to a corresponding one of a plurality of content files, each content file including a header portion, and a header of each of the content file (s) The information in the section indicates one of the rights object storage file (s) in which the corresponding rights object was found, and the corresponding location of such rights object in such rights object storage file, wherein the rights object navigation file contains at least one rights object. Information indicating whether one or more locations in the save file contain effective rights objects. Non-volatile computer-readable medium comprising. The method of claim 39, And the medium comprises a nonvolatile flash memory cell in a memory card. The method of claim 39, The medium includes at least one protected area and at least one unprotected area, the protected area is accessible only to an authenticated user, the at least one rights object storage file is stored in at least one protected area, and the right The object navigation file is stored in at least one unprotected area. A non-volatile computer readable medium storing a rights object navigation mechanism, the medium comprising at least one protected area and at least one unprotected area, the mechanism comprising: A rights object navigation file and at least one rights object storage file; A first directory tree comprising, in at least one unprotected area of the medium, a directory comprising a list of a plurality of content files and a rights object navigation file; And At least one protected area of the medium, comprising a second directory tree comprising a directory comprising a list of rights objects in at least one rights object storage file, each of the rights object storage files storing such rights object A plurality of encrypted rights objects at corresponding locations in the file, each of the rights objects controlling the use and / or access of a corresponding one file of the plurality of content files, the two directory trees mirrored each other A nonvolatile computer readable medium having a phosphorus structure. A computer readable program for storing a computer program for controlling the use and / or access of a content file using a rights object to a rights object storage file in a protected area of the storage device, wherein the content file is the use and / or use of the content file. And containing rights object navigation information indicating a path of access to a rights object in a rights object storage file for controlling access. Retrieve rights object navigation information from the content file; Obtain a location in the rights object storage file from the rights object navigation information in the protected area of the storage device in which the rights object is stored; Obtain the rights object from the rights object storage file in the protected area of the storage medium using the obtained location; And Computer readable medium for using and / or accessing content files in accordance with the rights object. The method of claim 43, The computer program uses a plurality of rights object storage files each having m locations for storing a rights object, wherein the rights object navigation information includes an index and divides the index by m to obtain a share; In order to obtain an integer equal to the integer portion of the quotient, and to obtain an offset equal to the remainder of the quotient, the computer program may be configured such that one of the plurality of rights object storage files is a rights object, and the rights object is stored therein. A computer-readable medium for finding a location in the same rights object storage file. The method of claim 44, Wherein the integer indicates that one of the one or more rights object storage file (s) stores the rights object and the offset indicates a location in such a rights object storage file in which the rights object is stored. The method of claim 43, The storage device includes an unprotected area, and the computer program also converts an access path to a location in the unprotected area into an access path for accessing the protected area. 47. The method of claim 46 The storage device is: A first directory tree comprising, in at least one unprotected area of the medium, a directory comprising a list of a plurality of content files and a rights object navigation file; And In at least one protected area of the medium, a second directory tree comprising a directory comprising one or more rights object storage files, the two directory trees having a mirror symmetric structure with each other, The computer program uses the two directory trees to convert an access path for accessing a location in the unprotected area into an access path for accessing a location in a rights object storage file in which a rights object is stored. media. The method of claim 43, And the medium is part of the storage device. A computer readable medium for storing a computer program for invalidating an encryption / decryption key stored in a key storage file and used for encrypting / decrypting a content file, wherein the content file includes a key stored in the key storage file. A key navigation file containing status information indicating whether or not it is valid, the header portion including position information indicating a position of a key in the key storage file, wherein the computer program comprises: Obtain position information of a key in the key file from a header portion of a content file; Find status information of a key in a key navigation file using the location information; And change status information of a key in a key navigation file to indicate that the key is invalid. The method of claim 49, A plurality of key storage files are used to store keys to protect one or more content files, wherein the key navigation file includes state information indicating whether keys stored in the plurality of key storage files are valid, and the location information Also indicates whether one of the key storage files contains a key that is invalidated. The method of claim 49, The key navigation file and the key storage file are stored in a storage device, the device including at least one protected area and at least one unprotected area, at least one protected area accessible only to an authenticated user, and The key storage file is stored in at least one protected area, wherein the key in the key storage file is invalidated without access to the at least one protected area. A computer readable medium storing a computer program for invalidating a rights object stored in a rights object storage file and used to control the use and / or access of the content file, wherein the content file is stored in the rights object storage file. And, by the rights object navigation file containing status information indicating whether the rights object is valid, a header portion containing position information indicating the position of the rights object in the rights object storage file, wherein the computer program comprises: Obtain position information of a rights object in the rights object file from a header portion of a content file; Use the location information to find state information of the rights object in the rights object navigation file; And change status information of the rights object in the rights object navigation file to indicate that the rights object is invalid. The method of claim 52, wherein The plurality of rights object storage files are used to store rights objects for protecting one or more content files, and the rights object navigation file includes state information indicating whether the rights objects stored in the plurality of rights object storage files are valid or not. And wherein the location information also indicates that one of the rights object storage files includes a rights object that is invalidated. The method of claim 52, wherein The rights object navigation file and the rights object storage file are stored in a storage device, the storage device including at least one protected area and at least one unprotected area, the at least one protected area only accessible to an authenticated user. And the rights object storage file is stored in at least one protected area, wherein the rights object in the rights object storage file is invalidated without access to at least one protected area. A method for encrypting / decrypting a content file using a key navigation file and one or more key storage files, each entry in the key navigation file storing one of a plurality of encryption / decryption keys in the one or more key storage files. Corresponding to a position to: Opening the key navigation file; Finding an entry in the key navigation file that does not correspond to a location of a valid key in the one or more key storage files; Generating an encryption / decryption key; Encrypting / decrypting a content file with the encryption / decryption key; And Storing the encryption / decryption key at a location in one of the key storage file (s) corresponding to the entry. The method of claim 55, The method further comprises obtaining key navigation information for the content file from the location of the entry in the key navigation file. The method of claim 56, wherein The method uses a plurality of key storage files each having m entries, wherein the key navigation information includes an index having a different value for each entry in the key navigation file, and the method includes an encryption / decryption key. Discovering a location in the one or more key storage files corresponding to the entry for storing, wherein the discovering step is equal to the remainder of the share, to obtain an integer equal to the integer portion of the share, to obtain a share. A method of encrypting / decrypting a content file comprising dividing the index by m to obtain an offset. The method of claim 57, The integer represents one of the one or more key storage file (s) in which the encryption / decryption key is stored by the storing and the offset is such a key storage file in which the encryption / decryption key is stored by the storing. A method of encrypting / decrypting content files indicating their location in. The method of claim 57, And inserting an index into the header of the encrypted / decrypted content file. The method of claim 55, Changing an entry in the key navigation file to correspond to a valid key in the at least one key storage file. The method of claim 55, The key navigation file and the one or more key storage files are stored in a storage medium, the medium including at least one protected area and at least one unprotected area, wherein the at least one protected area is accessible only to an authenticated user. And the at least one key storage file is stored in the at least one protected area, and wherein the storing comprises storing the encryption / decryption key in at least one protected area. The method of claim 55, And configuring an access path to one key storage file that includes a location corresponding to the entry for storing the encryption / decryption key. 63. The method of claim 62, The configuring step includes the step of forming a key file name from the key navigation information. The method of claim 63, wherein The key navigation file and the one or more key storage files are stored in a storage medium, the medium including at least one protected area and at least one unprotected area, the protected area accessible only to an authenticated user, and One or more key storage files are stored in the at least one protected area, and the configuring step comprises obtaining an access path from the file name to the one key storage file in the at least one protected area. Decryption method. 63. The method of claim 62, The medium includes at least one protected area and at least one unprotected area, and the configuring comprises converting an access path to a location in the at least one unprotected area into an access path for accessing the at least one protected area. A method of encrypting / decrypting a content file comprising the steps. 66. The method of claim 65, The medium is: A first directory tree comprising, in at least one unprotected area of the medium, a directory comprising a list of a plurality of content files and a key navigation file; And A second directory tree comprising a directory in the at least one protected area of the medium, the directory including a list of keys in one or more key storage files, the two directory trees having a mirror symmetric structure with each other, The converting may include encrypting / decrypting a content file using two directory trees to convert an access path for accessing a location in an unprotected area from a key storage file in the protected area to an access path for accessing a location. . A method for decrypting / encrypting a content file using a decryption / encryption key in a key storage file in a protected area of a storage medium, the content file having a decryption / encryption key in a key storage file for decrypting / decrypting the content file. And key navigation information indicative of location, the method comprising: Retrieving the key navigation information from the content file; Obtaining a location in a key storage file from the key navigation information in a protected area of a storage device in which the encryption / decryption key is stored; Obtaining an encryption / decryption key from a key storage file in a protected area of the storage medium using the obtained location; And Encrypting / decrypting a content file using the encryption / decryption key. The method of claim 67 wherein The method uses a plurality of key storage files each having m locations for storing keys, wherein the key navigation information comprises an index, and the method divides the index by m to obtain a quot; In order to obtain an integer equal to the integer portion of the quotient, and to obtain an offset equal to the remainder of the quotient, one of the plurality of key storage files is such that the decryption / encryption key and the decryption / encryption key are stored. And storing the location in the key storage file. The method of claim 68, wherein Wherein the integer indicates that one of the one or more key storage file (s) stores the decryption / encryption key and the offset indicates a location in such a key storage file where the decryption / encryption key is stored. The method of claim 67 wherein The medium includes an unprotected area, and the obtaining step also converts an access path to a location in the unprotected area into an access path for accessing the protected area. The method of claim 70, The medium is: A first directory tree comprising a directory in the unprotected area of the medium, the directory including a list of a plurality of content files and at least one key navigation file; And A second directory tree comprising a directory containing at least one key storage file in at least one protected area of the medium, the two directory trees having a structure that is mirror symmetric with each other, The converting may include converting an access path for accessing a location in the unprotected area using the two directory trees into an access path for accessing a location in a key storage file in which a decryption / encryption key is stored. How to decrypt / encrypt a file. Generating the key navigation file if the key navigation file does not exist; Generating the at least one key navigation file if at least one key storage file does not exist; Finding an entry in the key navigation file that does not correspond to a valid key in the at least one key storage file; Obtaining key navigation information for the content file from the location of the entry in the key navigation file; Generating an encryption / decryption key; Encrypting / decrypting a content file with the encryption / decryption key; and Storing the encryption / decryption key at a location in the at least one key storage file corresponding to the entry, wherein each of the entries in the key navigation file is a plurality of encryptions in the at least one key storage file. A method of encrypting / decrypting a content file corresponding to a location for storing one of / decryption keys. A method for controlling the use and / or access of a content file using a rights object navigation file and one or more rights object storage files, wherein each of the entries in the rights object navigation file are multiple in the one or more rights object storage files. Corresponding to a location for storing one of the rights object of, the method comprising: Opening the rights object navigation file; Finding an entry in the rights object navigation file that does not correspond to a location of a valid rights object in the one or more rights object storage files; Obtaining a rights object; Controlling the use and / or access of the content file along the rights object; And Storing the rights object at a location in one of the rights object storage file (s) corresponding to the entry. The method of claim 73, wherein The method further comprises obtaining rights object navigation information for the content file from the location of the entry in the rights object navigation file. The method of claim 74, wherein The method uses a plurality of rights object storage files each having m entries, the rights object navigation information comprising an index having a different value for each entry in the rights object navigation file, the method being a rights object And further comprising: finding a location in the one or more rights object storage file corresponding to the entry to store the location, wherein the discovering step comprises: to obtain an integer, the remainder of the share, to obtain an integer equal to the integer portion of the share; Dividing the index by m to obtain an offset equal to < RTI ID = 0.0 > m. ≪ / RTI > 76. The method of claim 75 wherein The integer indicating one of the one or more rights object storage file (s) in which the rights object is stored by the storing and the offset indicating a location in such rights object storage file being stored by the storing. How to control the use and / or access to files. 76. The method of claim 75 wherein And inserting an index into the header of the content file. The method of claim 73, wherein And modifying an entry in the rights object navigation file to correspond to a valid rights object in the at least one rights object storage file. The method of claim 73, wherein The rights object navigation file and the one or more rights object storage files are stored in a storage medium, the medium including at least one protected area and at least one unprotected area, wherein the at least one protected area is for an authenticated user only. The at least one rights object storage file is accessible and is stored in the at least one protected area so that the storing step controls the use and / or access of the content file storing the rights object in at least one protected area. Way. The method of claim 73, wherein Constructing an access path to one rights object storage file that includes a location corresponding to an entry for storing the rights object. 81. The method of claim 80, The configuring step includes the step of forming a rights object file name from the rights object navigation information. 82. The method of claim 81 wherein The rights object navigation file and the one or more rights object storage files are stored in a storage medium, the medium including at least one protected area and at least one unprotected area, the protected area accessible only to an authenticated user, The one or more rights object storage files are stored in the at least one protected area, and the configuring step further includes obtaining an access path from the file name to one rights object storage file in the at least one protected area. How to control the use and / or access to files. 81. The method of claim 80, The medium includes at least one protected area and at least one unprotected area, and the configuring comprises converting an access path to a location in the at least one unprotected area into an access path for accessing the at least one protected area. A method of controlling use and / or access to a content file comprising the steps. 84. The method of claim 83 wherein The medium is: A first directory tree comprising, in at least one unprotected area of the medium, a directory comprising a list of a plurality of content files and a rights object navigation file; And In at least one protected area of the medium, a second directory tree comprising a directory comprising one or more rights object storage files, the two directory trees having a mirror symmetric structure with each other, The converting step includes the use of a content file for converting an access path for accessing a location in an unprotected area using two directory trees to an access path for accessing a location in a rights object storage file in the protected area; And / or how to control access. The method of claim 73, wherein The acquiring step includes generating the rights object. The method of claim 73, wherein The acquiring step includes downloading the rights object. 87. The method of claim 86, Generating a key and encrypting the content key using the generated key. 88. The method of claim 87 wherein Decrypting the content file using a key from the rights object, wherein the encrypting occurs after the decrypting. 88. The method of claim 87 wherein Replacing the key in the rights object by a generated key. 88. The method of claim 87 wherein The encrypting step controls the use and / or access of the content file to encrypt the content file whose content file is already encrypted by a key in the rights object. 92. The method of claim 90, And storing the generated key in the rights object. A method for controlling the use and / or access of a content file using a rights object in a protected area of a storage medium, wherein the content file is a rights object for controlling the use and / or access of the content file. And includes rights object navigation information indicating the location of the rights object in the storage file, the method comprising: Retrieving the rights object navigation information from the content file; Obtaining from the rights object navigation information a location in the rights object storage file in a protected area of a storage device in which the rights object is stored; Obtaining the rights object from the rights object storage file in the protected area of the storage medium using the obtained location; And Controlling the use and / or access of the content file according to the rights object. 92. The method of claim 92, The method uses a plurality of rights object storage files each having m locations for storing the rights object, the rights object navigation information includes an index, and the method divides the index by m to obtain a share. Thus, to obtain an integer equal to the integer portion of the quotient, and to obtain an offset equal to the remainder of the quotient, one of the plurality of rights object storage files is a rights object, and such a rights object is stored. And detecting the location in the rights object storage file. 94. The method of claim 93, The integer indicates that one of the one or more rights object storage file (s) stores the rights object and the offset controls the use and / or access to the content file indicating the location in the rights object storage file in which the rights object is stored. Way. 92. The method of claim 92, The medium includes an unprotected area, and the obtaining step also converts an access path to a location in the unprotected area into an access path for accessing the protected area. 97. The method of claim 95, The medium is: A first directory tree in the unprotected area of the medium, the directory comprising a directory comprising a list of a plurality of content files and a rights object navigation file; And In at least one protected area of the medium, a second directory tree comprising a directory comprising one or more rights object storage files, the two directory trees having a mirror symmetric structure with each other, The converting may include converting an access path for accessing a location in the unprotected area using the two directory trees into an access path for accessing a location in a rights object storage file in which a rights object is stored. To control the use and / or access of the method. Generating the rights object navigation file if the rights object navigation file does not exist; Generating the at least one rights object navigation file if at least one rights object storage file does not exist; Finding an entry in the rights object navigation file that does not correspond to a valid rights object in the at least one rights object storage file; Obtaining rights object navigation information for the content file from the location of the entry in the rights object navigation file; Generating a rights object; Controlling use and / or access to content files in accordance with the rights object; and Storing the rights object at a location in the at least one rights object storage file corresponding to the entry, wherein each of the entries in the rights object navigation file is a plurality of entries in the at least one rights object storage file. A method of controlling the use and / or access of a content file corresponding to a location for storing one of a rights object. CLAIMS 1. A method for invalidating an encryption / decryption key stored in a key storage file and used to encrypt / decrypt a content file, wherein the content file includes status information indicating whether the key stored in the key storage file is valid or not. A key navigation file, comprising a header portion containing location information indicating a location of a key in the key storage file, the method comprising: Obtaining location information of a key in the key file from a header portion of a content file; Finding status information of a key in a key navigation file using the location information; And Changing state information of a key in the key navigation file to indicate that the key is invalid. 99. The method of claim 98, The key navigation file and the key storage file are stored in a storage device, the storage device including at least one protected area and at least one unprotected area, the at least one protected area being accessible only to an authenticated user, And the key storage file is stored in at least one protected area, so that the key in the key storage file becomes invalid without accessing at least one protected area. A method for invalidating a rights object stored in a rights object storage file and used to control the use and / or access of the content file, wherein the content file is a valid object stored in the rights object storage file. A rights object navigation file including state information indicating a, comprising a header portion including position information indicating a position of a rights object in the rights object storage file. Obtaining location information of a rights object from the header part of a content file in the rights object file; Finding state information of the rights object in the rights object navigation file using the location information; And Changing state information of the rights object in the rights object navigation file to indicate that the rights object is invalid. 101. The method of claim 100, The rights object navigation file and the rights object storage file are stored in a storage device, the storage device including at least one protected area and at least one unprotected area, the at least one protected area being accessible only to an authenticated user. And the rights object storage file is stored in at least one protected area so that the rights object in the rights object storage file is invalid without accessing at least one protected area.

Images