JP2007335035A - Information access managing method and device, and information recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To utilize an access managing method of an AACS or the like in order to protect highly confidential data including font or the like which is copyright-protected. <P>SOLUTION: It is checked whether recording destination is a medium corresponding to the AACS or not (ST500). When the recording destination is the medium corresponding to the AACS (ST500Y), a menu picture using font or the like with copyright is created (ST502), the font or the like with copyright is ciphered by the AACS and recorded in the medium (ST504). On the other hand, when the recording destination is the medium not corresponding to the AACS (ST500N), apparently the other menu is created without using the font or the like with copyright (ST510). <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to information access management using an encryption key or the like. In particular, the present invention relates to protection of highly confidential data recorded on an information recording medium such as an optical disk.

  In recent years, various digital devices for accessing content recorded on a disk medium or the like have been developed. Data recorded on a disk accessed by such a device is subjected to an encryption process in order to prevent unauthorized access or illegal copying. For the encrypted data, DVD (Digital Versatile Disc) mainly adopts an encryption method conforming to the CSS (Content Scramble System) method.

  On the other hand, AACS (Advanced Access Content System) has been proposed as a more advanced encryption method (Patent Document 1). When adopting this AACS system, for example, a set maker obtains a specific key set from a key matrix possessed by a licensee, encrypts different combinations of keys, and incorporates them into individual devices.

  In AACS, each of a plurality of keys is encrypted using a device key assigned to each device that properly records and reproduces content and a randomly generated random number, is registered in a key file together with the random number, and is recorded on a medium. When reproducing the content, the encryption key registered in the key file is decrypted with the random number and the device key of the device to be reproduced. Then, the content is decrypted with the decrypted key, and the content is reproduced.

In the HD_DVD Video Recording Format that employs the AACS system, it is possible to record interoperable content that can be played back by an HD_DVD-Video player. By using fonts (such as copyright-protected vector fonts) used in this interoperable content, a high-definition, beautiful and diverse menu can be created (Patent Document 2).
JP 2005-39480 A Japanese Patent Laying-Open No. 2005-332521 (see paragraphs 0036 to 0038)

  The advanced content described in Patent Document 2 is premised on recording on ROM media such as commercially available package media, and resource data such as copyrighted fonts are created when creating advanced content on recording media. No consideration is given to how it is handled. Patent Document 1 also lacks considerations for protecting copyrighted resource data.

  One of the problems of the present invention is to use an access management system such as AACS for protecting highly confidential data including copyright-protected fonts.

  The information access management according to the embodiment of the present invention is a predetermined screen (menu) using resource information (font, sound effect, still image, etc.) including a part (font with copyright) to be protected from unauthorized access. Alternatively, it is used when information on each screen in the video program is appropriately recorded on the information recording medium (100). In this management, it is checked whether or not the information recording medium (100) is a medium compatible with a predetermined encryption method (AACS) (ST500). When the information recording medium (100) is a medium compatible with the predetermined encryption method (AACS) (ST500Y), the predetermined screen (eg, menu screen: FIG. 13 screen 52a, etc.) (ST502), and the portion of the resource information (such as a font with copyright among fonts used in the menu) is encrypted by the predetermined encryption method (AACS) (FIG. 17). And record on the medium (ST504). On the other hand, when the information recording medium (100) is a medium that does not support the predetermined encryption method (AACS) (ST500N), the resource information (such as a copyrighted font) is not used. A predetermined screen (for example, a menu with a different appearance: 52c in FIG. 13) is created, or the predetermined screen (menu) is not created (ST510).

  If the media to be used does not support AACS, copyright protected resources (fonts, etc.) are not recorded on the media (recording without the copyright protected resources is possible), so copyright protected resources Unauthorized use of (fonts, etc.) can be prevented.

  Hereinafter, various embodiments of the present invention will be described with reference to the drawings. When recording information on an information recording medium such as an optical disk, it may be required to record the information encrypted. In that case, for example, the copyright-protected content is encrypted with an encryption key to be encrypted content, and further, the encryption key used for encryption is concealed so as to be encrypted with another encryption key to be an encryption key. The encryption key and the encrypted content are recorded together on a recording medium to prevent illegal copying.

  Currently, the DVD (Digital Versatile Disc), which is rapidly expanding its market, takes the following measures for copyright protection. That is, the DVD video uses the CSS (Content Scramble System) system licensed by DVD CCA (DVD Copy Control Association), and the DVD audio uses the CPPM (Content Protection for Prerecorded Media) system. A CPRM (Content Protection for Recordable Media) system is used as a copyright protection system for content recorded on a recording medium. The licenses for the CPPM method and the CPRM method are granted by a specific organization (for example, an organization called 4C Entity, LLC).

  On the other hand, development of large-capacity next-generation DVDs and the like that can record and reproduce high-definition video and high-quality multi-channel audio signals is in progress. As a copyright protection method for recording high-quality works on such next-generation recording media, it is required to introduce a method with higher security capability than before. As a specific example, there is an AACS (Advanced Access Content System) system. A content key management method in AACS, which is a content protection technology adopted in the HD DVD-VR (High Density Digital Versatile Disc Video Recording) format, will be described below.

  In the conventional CPRM method, an encryption key is generated using a media key block (MKB) and a media ID (Media ID) existing in the disc, and the content is encrypted. On the other hand, in the AACS system, the content in the disc is encrypted not by a common encryption key but by an encryption key for each content.

  FIG. 1 is a diagram illustrating a configuration example of data in the medium 100. In this example, a maximum of 1998 video objects (VOB) which are contents in a format such as MPEG2-PS and stream objects (SOB) which are contents in a format such as MPEG2-TS are stored in the same medium according to the standard. It is possible to do. In the conventional method, one encryption key is used for all these objects, but in the AACS method, encryption is performed using different encryption keys for each content. The encryption key for each content is stored in the title key file (TKF). That is, a title key file for a video object and a title key file for a stream object are provided, and each title key file can store up to 1998 encrypted title keys (Encrypted Title Key: E-TK for short). It has become.

  FIG. 2 is a diagram for explaining processing for decrypting encrypted contents recorded in the media 100. FIG. 2 shows information stored in the medium 100 on which content is recorded, processing functions provided in the information recording / reproducing apparatus 200, and data flow therebetween.

AACS is a content protection technology adopted in the HD_DVD Video Recording Format. A content key management method in AACS will be described with reference to FIG. The data recorded in the non-rewritable area on the disk used for AACS processing is:
・ Media ID
・ Lead-in MKB
There is.

On the other hand, data that is used in AACS processing and exists as a file on the disk 100 includes:
・ Read Write MKB
・ Title Key File
・ Usage Rule File
There is. Also, data based on a random number called Binding Nonce is recorded in the protected area at the head address of the Title Key File.

  In AACS, the process of generating a “title key (Kt)” for encrypting content is large and executed in the following order. That is, first, MKB processing is performed using a newer version of Lead-in MKB and Read Write MKB. The key generated by this processing is called “media key (Km)”. When protected media key processing (Kpa processing) is performed using the media key Km and Binding Nonce as inputs, a “protected area key (Kpa)” is generated. By performing Title Key processing (TK processing) using the Kpa, Usage Rule File data and Title Key File data as input, the encrypted title key (Encrypted Title Key) described in the Title Key File is originally Can be converted to the title key Kt.

  MKB is data called Media Key Block, which is a media key Km encrypted and recorded. Further, information on unauthorized devices is also recorded in the MKB, so that unauthorized devices cannot take out Km. Since unauthorized device information is updated, it is necessary to use a new MKB. For this reason, in the AACS of HD_DVD, the Lead-in MKB embedded in the media Lead-in Area, the Read Write MKB stored as a file on the disk, and the Device MKB stored in the nonvolatile memory inside the device itself There are three types of MKB, and it is stipulated that the newest MKB is overwritten on the Read Write MKB. However, when the MKB is updated to a new one, the value of Km is changed, so that all key information (Kpa, Kt, etc.) after Km needs to be regenerated.

  2 includes a control unit 210, a reading unit 220, and a writing unit 230. The control unit 210 controls each function and each processing operation of the information recording / reproducing apparatus 200 shown in FIG. The reading unit 220 reads data from the medium 100 into the information recording / reproducing apparatus 200. The writing unit 230 writes data in the information recording / reproducing apparatus 200 to the medium 100.

  Lead-in MKB (Media Key Block) is stored in the read-only lead-in area of the medium 100, and Read Write MKB is stored in the User Data Area which is a rewritable area. MKB has established a mathematical system by encrypting a media key (Km), which is a base key for content encryption, with a set of device keys (Kd) installed as a secret key in the information recording / reproducing apparatus 200. Media key block ".

  In S10 of FIG. 2, the versions of Lead-in MKB and Read Write MKB recorded on the medium 100 are compared, and the new MKB of the version is read as Media MKB. In S11, the MKB process is performed using the device key set (Set of Device Keys or Device Key Set) and Media MKB stored in the information recording / reproducing apparatus 200. This device key set is composed of a plurality of device keys Kd.

  Here, information for generating a protected area key (Kpa) is encrypted and stored in the MKB, but in addition, revoke information (Revoke Information: revocation information or invalidation information) is also included. . That is, when a security hole exists in a certain device key set and the licensor prohibits the use of the corresponding device key Kd, revocation information related to the corresponding device key Kd is described. This revoked information makes it impossible for the device having the corresponding device key Kd to decrypt the cipher (that is, the revoked information cannot be reproduced). Since unauthorized device information is gradually updated as time passes, it is necessary to use a new MKB (the latest updated MKB). Therefore, the newer version is used as Media MKB as described above.

  A media key (Km) is generated by this MKB process. In S12 of FIG. 2, the generated media key is verified. If the generated media key is invalid as a result of verification, the device key set is regarded as invalid, and the process related to AACS is terminated.

  On the other hand, “data based on random numbers” combined with a file called Binding Nonce is recorded in the protected area at the head address of the title key file (TKF). This Binding Nonce cannot be copied by, for example, a PC (personal computer) Write command, and can be copied only by a command defined by AACS. As described above, the information can be prevented from being leaked through the PC by enabling the copying only with the hardware having the AACS license.

  Next, in S13 of FIG. 2, Kpa processing that is encryption processing is performed using Km and Binding Nonce. For this Kpa processing, AES (Advanced Encrypted Standard) -G which is an encryption algorithm is used. As a result of this Kpa processing, a protected area key (Kpa) is generated.

  Next, title key processing for generating a title key (TK) from Kpa will be described. This process is indicated by S14 in FIG. The title key file (TKF) stores random data called TKFN (Title Key File Nonce). This TKFN is random number data used to encrypt the title key in the encryption process (described later). In addition, the disc 100 has a Usage Rule File describing content usage rules. In this Usage Rule File, information (Usage Rule) as to whether to apply the usage rule is described as 0 or 1 bit information for each of the plurality of usage rules.

  Further, a Media ID is recorded in a read-only burst cutting area (BCA) provided inside the lead-in area of the disc 100. Media ID is a unique ID added to each medium. In the user data area, which is a rewritable area, Media ID MAC, which is a falsification prevention code MAC (Message Authentication Code) using Media ID, is stored.

  In the title key process shown in S14 of FIG. 2, the process using the AES-D algorithm is performed based on the result of processing the above Usage Rule, Kpa and TKFN, and the encrypted title key (E-TK). Is decrypted to generate a title key (TK). At this time, it is verified that the MAC generated using the Media ID stored in the BCA and the Media ID MAC stored in the disk are not falsified. In S15 of FIG. 2, the TK thus generated and the encrypted content (Encrypted contents) are processed by the AES-G algorithm to generate a content key. In S16, the content key is used. The encrypted content (Encrypted contents) is decrypted to generate the content.

  FIG. 3 is a diagram for explaining a process of encrypting the content and recording it on the optical disc 100 such as HD_DVD-R / RW / RAM. The terminology used is the same as in FIG. In S20 of FIG. 3, the versions of Lead-in MKB and Read Write MKB recorded on the medium 100 are compared, and the new MKB of the version is read as Media MKB. Next, the versions of Media MKB and Device MKB possessed by information recording / reproducing apparatus 200 are compared. If the Device MKB version is newer, the MKB update process is started in S21, and the value of Device MKB is updated to Read Write MKB. However, if the Media MKB version is newer, whether to update the Device MKB value is a set specification. In S22 of FIG. 3, the MKB process is performed using the device key set stored in the information recording / reproducing apparatus 200 and the Media MKB. A media key (Km) is generated by this MKB process.

  In S23 of FIG. 3, the generated media key is verified. If the generated media key is invalid as a result of the verification, the device key set is regarded as invalid and the processing related to AACS is terminated. On the other hand, in S24 of FIG. 3, Kpa processing that is encryption processing is performed using Km and Binding Nonce. As a result of the Kpa process using AES-G, a protected area key (Kpa) is generated.

  In S25 of FIG. 3, the title key (TK) and the content are processed by an AES-G algorithm to generate a content key. In step S26, the content key is encrypted to generate encrypted contents, which are recorded on the medium 100. In S27, a MAC is generated using the Media ID and TK, and stored in the medium 100 as the Media ID MAC. On the other hand, in S28, random number data used for encrypting the title key is generated and recorded on the medium 100 as a Title Key File Nonce. In S29, the process using the AES-E algorithm is performed based on the result of hash processing (known technology) on the Usage Rule and Kpa and TK to generate an encrypted title key (E-TK). And stored in the medium 100. The Usage Rule is recorded on the medium 100 in S30.

  As described above, the title key or the like plays an important role in content encryption and decryption. However, since the title key or the like is recorded on the medium 100 as a file that can be read / written, if the surface of the medium becomes dirty with, for example, a fingerprint, there is a possibility that the content cannot be easily read. Therefore, AACS provides a backup for a title key file (TKF) that stores information such as these title keys.

  FIG. 4 is an explanatory diagram showing a structure example of a title key file and a title key file as a backup file thereof. In the description of this backup method, the title key file is represented as TKF1, and the title key files as backup files are represented as TKF2 and TKF3. TKF 1 to 3 are stored in the medium 100.

  Each title key file (TKF 1 to 3) includes Binding Nonce 1 to 3 (BN 1 to 3), Title Key File Generation 1 to 3 (TKFG 1 to 3), Title Key File Nonce to 3 (TKFN 1 to 3), and Encrypted. Title Key 1 to 3 (encrypted title keys ETK 1 to 3) are registered. Here, Binding Nonce 1 to 3 (BN 1 to 3) are random number data used for encryption of its own title key file as described above. Title Key File Generations 1 to 3 (TKFG1 to 3) represent the number of changes of title key files (TKF1 to 3). Title Key File Nonce to 3 (TKFN1 to 3) are random numbers for generating an encrypted title key (ETK1 to 3) of a file other than its own title key file or backup file.

Encrypted Title Keys 1 to 3 (encrypted title keys: ETK1, ETK2, and ETK3) are expressed by the following equations (eq.1) to (eq.3):
ETK1 = f (TK, BN1, TKFN3) (eq.1)
ETK2 = f (TK, BN2, TKFN1) (eq.2)
ETK3 = f (TK, BN3, TKFN2) (eq.3)
Here, TK represents an unencrypted plaintext title key, and the encryption processing function f includes the first parameter (TK), the second parameter (BN1 to 3) and the third parameter (TKFN1 to 3) as an encryption key. As shown in FIG. For the encryption process f, a known encryption algorithm such as AES (Advanced Encryption Standard) may be used.

  That is, TKF1 is associated with TKF3, and the title key (TK) is encrypted with (BN1) and (TKFN3) of the associated TKF3. Further, TKF2 is associated with TKF1, and the title key (TK) is encrypted with (BN2) and (TKFN1) of the associated TKF1. Furthermore, TKF3 is associated with TKF2, and the title key (TK) is encrypted with (BN3) and (TKFN2) of the associated TKF2.

  Thus, the title key file TKF1 and the backup files TKF2 and TKF3 are associated with each other, and the encrypted title keys (E-TK1, E-TK2, E-TK3) are registered in its own file. (BN1, BN2, BN2) and (TKFN1, TKFN2, TKFN3) registered in other associated files are used to encrypt the title key (TK).

  By storing three TKFs and storing TKFN in a separate file as described above, even if one TKF is broken due to data corruption or the like, the broken data can be restored from the remaining two TKF data.

  It should be noted that unauthorized copying can be prevented by setting the above Binding Nonce as data that can be read and written only by a special drive command. That is, even if TKF is copied, the binding nonce associated therewith is not copied, so that it is possible to prevent unauthorized encryption / decryption by a malicious third party.

  The association between the title key file and the TKFN of the other backup files is not limited to the above formulas (eq.1) to (eq.3), but (eq.1) to (eq.1). 3) The title key file and the backup file TKFN may be associated with a pattern other than the formula.

  With reference to FIGS. 5, 6, and 7, data on the media necessary for AACS recording / reproduction processing will be described in detail. In the Protected Area on the medium 100, that is, the Protected Area of the file storing the E-TK, the Binding Nonce and its backup data are stored. In addition, a Media ID is recorded in a BCA (Burst Cutting Area) in the read-only area of the medium 100, and Lead-in MKB is recorded in a lead-in area (110 in FIG. 11 described later).

  In the user data area on the medium 100, management information that is information related to the copy protection pointer of the video object (VOB) and / or stream object (SOB) is stored. The user data area stores Read Write MKB, encrypted title key (E-TK), Media ID MAC, Usage Rule, and backup files thereof. Further, the user data area can store up to 1998 encrypted contents.

  FIG. 8 shows the structure of an encrypted title key file (E-TKF). FIG. 8 shows the E-TKF structure for the stream object (SOB), but the video object (VOB) has the same structure. In the byte position, 0 to 15 bytes describe fixed information (STKF_ID, HR_STKF_EA) for specifying the title key file, and 32 to 33 bytes describe the AACS version number. In 128 to 143 bytes, Title Key File Generation is stored, and in 144 to 159 bytes, Title Key File Nonce is stored. In 160 to 64095 bytes, 1998 sets of encrypted title key (E-TK) and Media ID MAC are described as Title Key Information (KTI).

  Each content is encrypted using one of the 1998 title keys. However, it is not necessary to record the Encrypted Title Key in all 1998 items, and an unused one is described by encrypting a numerical value of 0 by TK processing. The Title Key File Generation contains a value that is incremented each time this file is updated. As described above, the title key file has a total of three files for backup. If all the values of Title Key File Generation of these three files do not match, it means that there was some trouble during file writing.

  Next, a method for updating the title key file will be described. The types of media to which AACS is applied include rewritable media and write-once media. In a rewritable medium, for example, a new title key is added every time new content is recorded. Therefore, it is necessary to re-encrypt all title keys in the title key file using a new Kpa. That is, it is necessary to update the title key file.

  By the way, although the numerical value based on a random number called Binding Nonce is described in the protected area of the title key file, this Binding Nonce is used to prevent unauthorized decryption. Nonce is updated whenever the title key file is updated.

  On the other hand, in the write-once media, every time the title key file is updated, the title key file is written at a new address. For this reason, the address to which the Binding Nonce is written is also different each time. However, since AACS requires that the Binding Nonce be overwritten at the same location, in the case of a write-once medium, the title key file must not be updated. Therefore, the rewritable media and the write-once media have different title key file update conditions.

  In the Title Key File of FIG. 8, 1998 encrypted title keys are recorded. The content is encrypted using one of the 1998 keys. It is not necessary to record the Encrypted Title Key in all of 1998, and the unused one is to describe a value obtained by encrypting a numerical value “0” by TK processing. The Title Key File Generation contains a value that is incremented each time this file is updated. The Title Key File stores the title key. If the title key file cannot be read due to a defect on the media, the content cannot be reproduced at all. For this reason, three files are written for backup. If all the values of Title Key File Generation of these three files do not match, it means that there was some trouble during file writing.

  A numerical value based on a random number called Binding Nonce is recorded in the protected area of the address where the Title Key File is written on the medium 100. The protected area is an area that can be read and written only by a special command dedicated to AACS. By recording elements constituting Kpa in this portion, unauthorized descrambling using a personal computer or the like can be prevented.

  The title key in the Title Key File is encrypted by performing TK processing in combination with the protected area key and Binding Nonce. At this time, Title Key File # 1 is encrypted using Title Key File # 2 Binding Nonce, and Title Key File # 2 encrypted Binding Nonce is used. By doing so, even if one of the three Title Key Files is damaged, it can be restored by using the other two files. Thus, since Binding Nonce is used for encryption of the title key, it is updated every time the Title Key File is updated.

  On the other hand, Binding Nonce depends on the address at which the file is written. In the case of write-once media such as HD_DVD-R, the Title Key File itself is stored at a new address each time, and the position where the Binding Nonce is written It ’s not one place. However, since AACS requires that the Binding Nonce be overwritten at the same location, the Title Key File is not updated for write-once media.

  The Title Key File can store 1998 title keys. This is consistent with the number of video objects (VOB) and stream objects (SOB), and it is assumed that the title key (Kt) is changed for each video object. This is because, for example, when content is moved from the disc to another medium, a loophole that can be illegally copied remains unless the title key used is erased. If the title key is deleted, other objects sharing the same title key cannot be decrypted, so it is necessary to assign a different key to each object as much as possible. Therefore, in the recording / playback apparatus, a new title key is generated for each recording process, and the video object and the stream object are encrypted with the title key.

  On the other hand, particularly in the case of recording by a stream object (SOB), it is necessary to dynamically divide the stream object according to the contents of the digital broadcast to be recorded. Specifically, when the constituent elements of the stream object (SOB) change, such as the number of audio streams changes at a program boundary, the SOB is automatically divided there. In such a case, it is practically impossible to switch the title key there. (If it is attempted to switch the title key, it takes time to generate a new key. Part of the recording is missing). In such a case, encryption using the same title key is continued.

  If the disc is a write-once medium (a medium that cannot be overwritten), the Title Key File cannot be updated, and therefore, an existing title key is used in the process of generating a key at the start of recording.

  FIG. 9 is a flowchart showing a procedure for updating a title key file of a rewritable medium when a rewritable medium (HD_DVD-RW / RAM or HDD) is used as the medium 100. Therefore, a title key file has already been generated and written on the rewritable medium. 9 is realized by the control unit 210 of the information recording / reproducing apparatus 200 (or the firmware of the AACS processing unit 210a of FIG. 13 described later).

  For example, when the user turns on the power of the information recording / reproducing apparatus 200 and inserts a rewritable medium in S40 of FIG. 9, the MKB process (S41) and the TKF reading process (S42) are executed collectively. In the MKB process (S41), the signature added to the Read Write MKB and the Lead-in MKB is verified. If it is determined that the verification result is valid, the version of each MKB is acquired. The Read Write MKB version must be the same as or newer than the Lead-in MKB version, otherwise it restricts playback and recording. In the TKF reading process (S42), the title key file in the medium is developed on the SDRAM (22 in FIG. 13, which will be described later).

  In S43 and S44, it is determined whether to update the title key file in response to the user's content recording operation, content editing operation, content deleting operation, media ejecting operation, and power-off operation of the information recording / reproducing apparatus 200. To do. That is, the title key file is updated only when at least one of the following three conditions is satisfied.

(1) When content is recorded and deleted When content is recorded and deleted, an Encrypted Title Key in the title key file is newly added or deleted. Therefore, the title key file is updated.

(2) When MKB is updated For example, when the version of Device MKB, which is the MKB held in the information recording / reproducing apparatus 200, is newer than the version of Read Write MKB, the value of Device MKB is changed to Read Write MKB. The media key (Km) of Device MKB is changed by copying. Therefore, the title key file is updated and the title key is re-encrypted.

(3) When only one of the three Title Key File Generations is different As described above, one of the three title key files is damaged. Therefore, the damaged title key file is repaired (updated) using the two remaining normal title key files. That is, when at least one of the above three conditions is satisfied (S44Y), the title key file is updated (S45). If all of the above three conditions are not satisfied (S44N), the process is terminated without updating the title key file (S46).

  FIG. 10 is a flowchart showing a write-on procedure for a title key file of a write-once medium when a write-once medium (one-sided single-layer HD_DVD-R or single-sided dual-layer HD_DVD-R: DL) is used as the medium 100. . Similar to FIG. 9, the processing operation shown in FIG. 10 can be executed by the control unit 210 of the information recording / reproducing apparatus 200 (or the AACS processing unit 210a of FIG. 13).

  For example, when the user turns on the power of the information recording / reproducing apparatus 200 and inserts a write-once medium in S50 of FIG. 10, the MKB process (S51) and the TKF read process (S52) are collectively executed. In the MKB process (S51), the signature added to the Read Write MKB and the Lead-in MKB is verified. If it is determined that the verification result is valid, the version of each MKB is acquired. The Read Write MKB version must be the same as or newer than the Lead-in MKB version, otherwise it restricts playback and recording. In the TKF reading process (S52), the title key file in the medium is expanded on the SDRAM (22 in FIG. 13).

  In S53 and S54, it is determined whether or not to write the title key file in response to the user's content recording operation, content editing operation, content deleting operation, media ejecting operation, and power-off operation of the information recording / reproducing apparatus 200. To do. That is, if the following two conditions are satisfied, the title key file is written.

(1 *) When content is recorded (2 *) When a title key file is not recorded on the disc.

  In AACS, the Title Key File is required to be overwritten at the same location. Therefore, in the case of a write-once medium, the Title Key File is written only when the conditions (1 *) and (2 *) are satisfied. The reason for doing so is described below.

  If only the condition (1 *) is used, a write request occurs each time content is recorded, which causes a problem with write-once media that cannot be overwritten at the same location. Under the condition (2 *) alone, when no content is recorded on the disc, a valid content key has not been generated, so that a Title Key File with only an invalid Encrypted Title Key becomes a problem. When both of the conditions (1 *) and (2 *) are satisfied, writing is performed when the title key file is not recorded on the disc, so the effective Encrypted Title Key is 1 Only one Title Key File generated will be recorded.

  When the above two conditions are both satisfied (S54Y), the title key file is written on the disc (S55). If all the above two conditions are not satisfied (S54N), the process is terminated without writing the title key file (S56).

  According to the embodiment described above, the condition for writing the title key file is provided for each media type, and writing is performed on the disc only when the condition is met. According to this condition, in the case of a rewritable medium, the Title Key File is not updated unnecessarily, and the number of times of writing to the disk can be reduced. In the case of write-once media, writing a problematic title key file can be eliminated.

  FIG. 11 is a diagram for explaining an example of the data structure according to the embodiment of the present invention. As a typical example of a recordable or re-writable information storage medium, a DVD disc (DVD ± R, DVD having a single recording layer or a plurality of recording layers using a red laser having a wavelength of around 650 nm or a blue-violet or blue laser having a wavelength of 405 nm or less) ± RW, DVD-RAM, etc.) 100. As shown in FIG. 11, the disk 100 includes a volume / file structure information area 111 containing a file system and a data area 112 for actually recording a data file. The file system includes information indicating which file is recorded where.

  The data area 112 includes areas 120 and 122 for recording by a general computer and an area 121 for recording audio video data (AV data). In the AV data recording area 121, an AV data management information area 130 having a video manager file (VMG or HDVR_MG) for managing AV data and an object data file conforming to the DVD-Video (ROM Video) standard are recorded. ROM_Video object group recording area 131, VR object group recording area 132 in which object data (ESOBS: Extended Video Object Set) files (VRO files) conforming to the video recording (VR) standard are recorded, and digital broadcasting The recording area 133 includes a stream object data (ESOBS: Extended Stream Object Set) file (SRO file) in which a corresponding object is recorded. Note that the recording standard for the SRO file is appropriately described as a stream recording (SR) standard.

  FIG. 12 is a view for explaining an example of the file structure according to the embodiment of the present invention. As shown in FIG. 12, the DVD_HDVR directory includes an HD_DVD-VR format management information file HR_MANGER.IFO and an analog video input object file VRO file (an EVOB file with a maximum rate allowed up to 30.24 Mbps). An HDVR_VOB directory, an HDVR_SOB directory including an SRO file (ESOB file) for digital broadcasting, and the like are configured. The DVD_RTAV directory under the same root directory as the DVD_HDVR directory is a VR-MANGER.IFO DVD-VR format management information file and a VRO file (analog video input object file) (conventional DVD with a maximum rate of 10.08 Mbps) -VR VOB file).

  That is, in the file structure according to this embodiment, the HDVR MPEG2-TS data file, the HDVR MPEG2-PS data file, and the VR MPEG2-PS data file are managed under the same root directory. For example, if a shortcut file linked to HR_MOVIE.VRO is title thumbnails A and C, a shortcut file linked to VR_MOVIE.VRO is title thumbnail B, and a shortcut file linked to HR_STRnn.SRO is title thumbnail D. These title thumbnails A to D can be displayed on the same menu screen (see the display example of the monitor screen 52a in FIG. 13). As a result, the user can perform menu operations on different objects (objects in which MPEG2-PS and MPEG2-TS are mixed) in the same screen operation environment.

  FIG. 13 is a block diagram illustrating a configuration example of a recording / reproducing apparatus (HD_DVD recorder) according to an embodiment of the present invention. The analog AV output of the TV tuner 10 having a reception function of satellite digital TV broadcast, terrestrial digital TV broadcast, and terrestrial analog TV broadcast is input to the Video ADC 14 and the Audio ADC 16. An analog AV input from the external analog input terminal 12 is also input to the Video ADC 14 and the Audio ADC 16. The video stream digitized by the Video ADC 14 and the audio stream digitized by the Audio ADC 16 are input to the MPEG Encoder 20. A digital stream (MPEG2-TS or the like) from the external digital input terminal 18 is input to the MPEG Encoder 20 via an interface 19 such as IEEE1394 (or HDMI). Although not shown, a digital stream (MPEG2-TS or the like) from the TV tuner 10 is also input to the MPEG Encoder 20 as appropriate. The MPEG Encoder 20 encodes the input stream to MPEG2-PS or encodes to MPEG4-AVC, except when the input MPEG2-TS is not passed through.

  Here, when encoding to MPEG2-PS, encoding to MPEG2-PS based on the DVD-VR standard (maximum rate 10.08 Mbps; maximum resolution 720x480 or 720x576), encoding to MPEG2-PS based on the HD_DVD-VR standard There are two cases: high rate encoding (maximum rate 30.24 Mbps; maximum resolution 1920x1080) and low rate encoding to MPEG2-PS within the HD_DVD-VR standard (maximum rate 10.08 Mbps; maximum resolution 720x480 or 720x576).

The stream data encoded (or passed through) by the MPEG Encoder 20 is temporarily buffered in a high-speed memory such as an SDRAM (Synchronous Dynamic Random Access Memory) 22. On this SDRAM 22, the following stream rewriting processes 1 to 3 are appropriately performed:
1. If Audio is Liner PCM, rewrite the value of sub_stream_id of Audio Pack;
2. Rewrite the contents of RDI-PCK;
3. Decrypt CPRM cipher and re-encrypt to AACS, or vice versa.

  The stream data buffered in the SDRAM 22 and processed there is transferred to the HDD 104, the HD_DVD Drive 26, or the DVD Drive 28 at a predetermined timing according to the contents. As the HDD 104, a large-capacity hard disk drive (for example, 1 TB) is used. A blue laser (for example, wavelength λ = 405 nm) is used for the HD_DVD Drive 26, and a red laser (for example, wavelength λ = 650 nm) is used for the DVD Drive 28.

  The HD_DVD Drive 26 and the DVD Drive 28 constitute a Drive Unit 24. The Drive Unit 24 has two independent drives including a rotary drive system, and an HD_DVD / DVD compatible drive (shared with the rotary drive system and having a blue laser optical head and a red laser optical head separately ( There are cases where a twin pickup type) is provided, and cases where a mechanism of a rotary drive system and an optical head is common and a two-wavelength optical system that switches between a blue laser and a red laser is used (single pickup type).

  In the embodiment of FIG. 13, the case where there are two independent Drives 26 and 28 including the rotational drive system is illustrated. As information storage media (blue laser optical disk 100 and red laser optical disk 102) used in these drives, the optical disk of -R / -RW / RAM type is used regardless of whether a blue laser or a red laser is used. Besides, + R / + RW type optical discs can be used. In the future, it is possible to use a large-capacity optical disk using a hologram.

The HD_DVD Drive 26 supports recording / reproduction based on the HD_DVD-VR standard, and the DVD Drive 28 supports recording / reproduction based on the DVD-VR standard. The DVD Drive 28 is also a DVD-VR standard disc for MPEG-PS data whose maximum rate, video attributes, etc. are within the framework of the DVD-VR standard, even if the data is encoded based on the HD_DVD-VR standard. (Single-sided single-layer DVD-R / RW / RAM, single-sided dual-layer DVD-R, double-sided single-layer DVD-RAM, etc.) ing. (For example, MPEG2-PS data of NTSC video recorded on the HDD 104 at a maximum rate of 10.08 Mbps is a DVD-VR standard disc even if it is encoded based on the HD_DVD-VR standard. The MPEG2-PS data encoded based on the HD_DVD-VR standard can also be copied / high-speed dubbed to the HD_DVD-VR standard disc 100. )
Stream data reproduced from the HD_DVD Drive 26, the DVD Drive 28, and / or the HDD 104 is transferred to the MPEG Decoder 30 via the SDRAM 22. The MPEG Decoder 30 is a function for decoding MPEG2-TS, a function for decoding MPEG2-PS, a function for decoding MPEG4-AVC, and other decoding functions (for example, defined in the HD_DVD-VR standard) in accordance with the transferred stream. Has a function to decode VC-1). The video data (MPEG2-TS or MPEG2-PS) decoded by the MPEG Decoder 30 is converted by the Video DAC 32 into an analog video signal of standard image quality or high-definition image quality and output from the Video Out terminal 36. The audio data decoded by the MPEG Decoder 30 is converted into an analog audio signal by the Audio DAC 34 and output from the Audio Out terminal 38. Further, when the decoded data is MPEG2-TS, it is externally output from the Digital Out terminal 39 via an interface 37 such as IEEE1394 (or HDMI) as appropriate. AV signals (analog video signal and analog audio signal) decoded by the MPEG Decoder 30 and D / A converted by the DACs 32 and 34 are input to an external monitor.

  The operation of the recording / playback apparatus (HD_DVD recorder) in FIG. 13 is controlled by the MPU 40. The MPU 40 is attached with an EEPROM 42 for storing firmware and various control parameters, a work RAM 44, a timer 46, and the like. The firmware of the MPU 40 includes a GUI display control unit 400 that provides a graphic user interface, an encoding parameter detection processing unit 402, a high-speed copy (high-speed dubbing) processing unit 404, and a rate conversion copy (constant-speed copy / constant-speed dubbing). There are a control unit 406, a recording / playback control unit (management information processing unit) 408, an AACS processing unit 210a (corresponding to the control unit 210 in FIG. 2), and the like. The processing result of the GUI display control unit 400 is displayed on an external monitor via an on-screen display unit (OSD) 50 (title thumbnail display screens 52a and 52c and the like can be obtained by the processing of the OSD 50).

  In the embodiment of FIG. 13, the HDD 104 may be a single ultra-high capacity HDD (for example, 1 TB) or a combination of a plurality of large capacity HDDs (for example, 500 GB + 500 GB). In addition, as the usage of the recording area of the HDD, there are a case where the recording area is logically divided into a plurality of partitions and a usage is specified for each physical HDD. In the former case, for example, the first partition of 400 GB out of 1 TB is allocated for MPEG2-TS recording of digital high-definition broadcasting (for TS title), and the second partition of 400 GB is used for recording MPEG4-AVC of digital high-definition broadcasting. It is conceivable that the third partition of 200 GB is assigned for analog broadcast, digital broadcast, or external input MPEG2-PS recording (for VR title). In the latter case, for example, the first 400 GB HDD is allocated for MPEG2-TS recording (for TS title), the second 400 GB HDD is allocated for MPEG4-AVC recording (for HDVR title), and the third 200 GB HDD is allocated. For example, it may be assigned to MPEG2-PS recording (for VR title).

  In one embodiment of the present invention, the VR title includes MPEG2-PS recording in which the maximum rate is suppressed to 10.08 Mbps in the next-generation HD_DVD standard in addition to MPEG2-PS recording according to the current DVD-VR standard. It is. The distinction between whether the stream data of a certain VR title is MPEG2-PS according to the DVD-VR standard or MPEG2-PS with the maximum rate being suppressed to 10.08 Mbps in the HD_DVD standard is based on specific information in the object data (for example, This can be done depending on whether the description of "program maximum rate" program_mux_rate ") is" 10.08Mbps "or" 30.24Mbps ". Also, at the management information level, before the reproduction of the title, whether or not the specific information (for example, video attribute “V_ATR”) in the management information includes a resolution (for example, 1280x1080) that cannot be the current DVD-VR standard. It can be carried out.

  In the embodiment of the present invention, a plurality of types of titles (TS title, HDVR title, VR title) described above are managed in the same directory as illustrated in FIG. Therefore, icons or thumbnails of a plurality of types of titles (TS title, HDVR title, VR title) can be displayed on the same screen 52a (or 52c). This allows users to record multiple titles in any standard (HD_DVD-VR, DVD-VR, etc.) under any circumstances (HD_DVD-VR recording with a maximum rate of 10.08 Mbps, maximum rate Can be operated in the same way.

  On the menu screen 52a, the thumbnail of each title includes a text Fx using a copyrighted font and a copyrighted image Ix, in addition to the font Fz that does not exercise copyright and the image character pattern Fy that does not exercise copyright. It is used. The information on the menu screen 52a and the title object (VOB and / or SOB) corresponding to the information are encrypted with AACS and recorded in the AACS-compatible medium 100 (described later with reference to FIG. 18).

  Here, “Font Fz that does not exercise copyright” means that the copyright holder can use it freely by a third party, even if the copyright is alive, in addition to the font that has become public domain due to the expiration of the copyright. Includes fonts that are tolerated or tolerated. On the other hand, even if the font is in the public domain, for example, a font having a new look-and-feel as a result of a change made by the device manufacturer in FIG. 13 can be a copyrighted font.

  When the recording destination is a medium that does not support AACS (for example, a conventional DVD-R / RW / RAM disk 102 or a medium based on a standard other than HD_DVD), text Fx using a copyrighted font and copyrighted A menu screen 52c without an image Ix is created, and the information is recorded on the AACS non-compliant medium 102 (in this case, for example, a CSS (Content Scramble System) method is used for object encryption).

  Alternatively, if the recording destination is a media that does not support AACS (for example, a disc that is made available for use with an HD_DVD drive but does not have a Media ID required for AACS recorded), a menu is not created (result) In other words, the menu may not be recorded on an AACS non-compliant disc). In the case of HD_DVD Interoperable Content, the menu is treated as an option as with conventional DVD Video. For this reason, if a disc that can be used for HD_DVD but does not support AACS is inserted into the drive, the title recorded on the disc is immediately displayed in the management information VMG / HDVR_MG without displaying anything. (In accordance with the description of the program chain information). In this case, there is no need to use a copyright protected font.

  FIG. 14 is a flowchart for explaining a recording method according to an embodiment of the present invention. This recording method process is executed each time a certain object (VOB or SOB) is recorded. For example, it is assumed that copyright-protected digital broadcast programs A and B are reserved for recording by using an electronic program guide (EPG) or the like. In this case, when the reserved recording of program A is performed, the processing of FIG. 14 is executed (using a certain encryption key), for example, a video object VOB (eg, MPEG4AVC) corresponding to program A is encrypted and an optical disc (for example, 13) or a hard disk (for example, 104 in FIG. 13). Further, when the scheduled recording of the program B is performed, the process of FIG. 14 is executed again (using another encryption key), for example, the stream object SOB (MPEG2TS or the like) corresponding to the program B is encrypted and the optical disc (100 ) Or the hard disk (104).

  When the one-time recording as described above is started, a key (title key Kt or Contents key) used for AACS encryption is generated (ST100). This key generation process can be performed in the same manner as the process described with reference to FIG. If the recording destination medium is an overwritable medium such as a hard disk or HD_DVD-RW / RAM, a new key is generated in ST100.

  However, when the recording destination medium is a write-once medium that cannot be overwritten, such as HD_DVD-R (or single-sided dual-layer HD_DVD-R: DL), a desired number of keys (Title Keys) is obtained by the process of FIG. ) Are prepared in advance in the same file (Title Key File). By using these prepared keys as appropriate (or sequentially), the key can be substantially updated even in a write-once medium that cannot be overwritten.

  Necessary and sufficient numbers of these keys are prepared in advance so that they will not be used up in updating. However, if all the prepared keys are used up for some reason, the last updated key is used as the existing key (Kt) in the media, and the existing key (Kt) is used thereafter. You may make it do (refer the last parenthesis writing in ST100).

  If there is no division of the object during recording of the object to be recorded (ST102N), the encrypted object is recorded while encrypting the object using the key generated in ST100 (by the AACS method) (ST106). Recording is performed on a medium (hard disk, optical disk, or semiconductor memory) (ST108). While the one-time recording on the object to be recorded is not completed (ST110N), the processes of ST102 to ST110 are repeated.

  During recording of an object to be recorded (for example, SOB of program B), when the object is divided due to, for example, a recording pose or a change in video attribute (ST102Y), if the subsequent recording process is counted as another recording process, Apparently it is not a single recording process. However, in this case, it is regarded as an event in one recording process, and the key (Kt) used for encryption of the object before division (for example, the first half of the program B) is divided into the object (for example, the second half of the program B). (STB). In this way, since a new key generation process (the process described with reference to FIG. 3) can be omitted, there is no time lag for generating a new key, and the divided object is encrypted (ST106). The recording (ST108) can be executed without delay (specifically, the possibility of the beginning being cut off when the recording of the divided object is continued) can be eliminated.

  As described above, when one recording of the object to be recorded is completed (ST110Y), various management information necessary for reproducing the recorded object is recorded in the HR_MANGR.IFO file (see FIG. 12). (ST112), and the recording process of FIG. 14 ends.

  FIG. 15 is a flowchart for explaining a reproduction method according to an embodiment of the present invention. The management information of the object to be reproduced (for example, the SOB of the program B) is read from the disc 100 on which the object data (VOB and / or SOB) and management information are recorded by the processing as shown in FIG. 14 (ST200). This management information (for example, HR_MANGR.IFO in FIG. 12) is also information on a menu (for example, 52a or 52c in FIG. 13) used when the user selects a reproduction target among a plurality of titles (objects) recorded on the disc 100. Can be included. The read management information is temporarily stored in the work memory (eg, 44 in FIG. 13) of the playback device.

  This playback device (equivalent to 200 in FIG. 2) uses information on encryption of an object to be played back (information used to generate Km, Kpa, Kt, etc.) as an optical disk (for example, 100 in FIG. 13) or a hard disk. (For example, 104 in FIG. 13) (ST202), and a decryption key (Kt or Contents Key) is generated from the read information (ST204). Here, the base information for generating Km, Kpa, Kt, etc. refers to Lead-in MKB, Read Write MKB, Binding Nonce, Title Key File, Usage Rule File, etc. (see FIG. 2). This decryption key generation process can be performed in the same manner as the process described with reference to FIG. Using the management information (HR_MANGR.IFO file) read in this way and the generated decryption key (Kt or Contents Key), the reproduction target object is reproduced while being decrypted (ST206). When this playback process is completed up to the end of the playback target object (or when the user or device control program instructs playback stop) (ST208Y), the playback process of FIG. 15 ends.

  By the way, a numerical value based on a random number called Binding Nonce is recorded in the protected area of the address where the Title Key File is written on the medium 100. The protected area is an area that can be read and written (accessed) only by a special command dedicated to AACS. By recording elements constituting the Protected Area Key (Kpa) in this area, a personal computer (PC) or the like is used. Unauthorized decryption can be prevented. This Binding Nonce needs to be updated every time the Title Key File is updated.

  On the other hand, Binding Nonce depends on the address at which the file is written. In the case of write-once media such as HD DVD-R, the Title Key File itself is stored at a new address each time, and the position where the Binding Nonce is written. Is no longer one place. However, since AACS requires that the Binding Nonce be overwritten at the same location, in the case of a write-once medium, the Title Key File cannot be updated as long as AACS is adopted.

  In this way, the Title Key File cannot be updated with write-once media, so when using the media for recording for the first time, only the required number of Title Keys are generated when creating the Title Key File for the first time. deep. However, the maximum number of 1988 does not need to be created, and only the minimum necessary number may be created. The necessary minimum number means that if all contents are shared by one key, only one is required. However, this makes it impossible to record individual contents (for example, individual plural digital broadcast programs) managed by AACS on one write-once medium.

  AACS has a file called Title Usage Rule File that describes usage restrictions for each content. An example of this Title Usage Rule File is shown in FIG. There are 1998 columns for Usage Restriction Rules, Usage Rule # 1 to Rule # 1998 shown in FIG. 16A, which correspond to Title Key numbers. That is, the Usage Rule of Title Key # 1 is relative to Usage Rule # 1.

  FIG. 16B shows the data structure of Usage Rule, and UR_FLG is a bit indicating validity / invalidity of this rule. In the case of an invalid rule, 0 is written in the bit of UR_FLG. Subsequent DOT-P and DOT are rules (usage rules or usage restrictions). For example, when DOT (Digital Only Token) is 1, the content should not be output in analog. As described above, since the rule is relative to the Title Key, the Title Key must be different if the adoption rule for encrypting the content is different. For this reason, according to the number of types of Usage Rule, two Title Keys are required: a Title Key to which the rule is applied and a Title Key to which the rule is not applied. At present, since two rules of DOT and DOT-P are defined in AACS, it is necessary to create at least four kinds of Title Keys in advance in actual operation.

In addition to the key for encrypting the content, a key is also required for encrypting the Advanced Resource File of the interoperable content. Since a common key may be used for all Resource Files, the minimum number of keys for encrypting the Advanced Resource File of the Interoperable Content is 1. (“Interoperable Content” refers to content that can be played back by a player compliant with the playback HD_DVD-Video standard among the content recorded within the recording / playback HD_DVD-Video Recording standard.)
Therefore, when the Title Key File is first created on the write-once medium 100, if the number of Title Usage Rule Files + 1 content title keys and one Advanced Resource File title key are generated in advance, Even if it is a write-once medium in which the Title Key File cannot be updated, the AACS can be operated.

  FIG. 17 is a flowchart for explaining an example of a processing procedure when the Title Key File is first written to the write-once medium. The key (Title Key or Kt) file (Title Key File) for encrypting the content (Title) to be protected from unauthorized access by AACS is first created, for example, from the start of FIG. 14 to FIG. When entering the process (or within the process of ST100 of FIG. 14). At that time, the number of title keys (or Kt) corresponding to the number of rules in the Usage Rule File (for example, two of DOT and DOT-P in FIG. 16B) (the number of combinations of Usage Rules, for example, 4) is used Create (ST300 to ST302). Also, when there is a copyright-protected Advanced Resource File (ARF), or when such an ARF can be created in the future (when an ARF is expected to be created in the future) (ST304Y), the Title for that ARF A key (or Kt) is created separately (ST306). Thus, as many title keys (or Kt) as desired (the number of usage rule combinations and the number of ARF title keys as appropriate) are created (ST300 to ST306). The created number of Title Keys (or Kt) is written in Title Key File (ST308).

  After that, the process returns to the process of FIG. 14, and the content (Title) is encrypted using the Title Key (or Kt) written in the Title Key File (ST100) (ST106), and the encrypted content (Title) is written. Recording on once media (HD_DVD-R or the like) (ST108 to ST112).

  Here, resource information including contents to be protected separately from the content (Title), that is, specific examples of the Advanced Resource File (ARF) include information on fonts, sound effects, still images, and the like. In particular, beautiful vector fonts used on a high-definition screen (for example, each title character displayed on the monitor screen 52a in FIG. 13 and its program description font, or a font such as subtitles on a screen other than the menu although not shown) are copyrighted. There is a high need for protection (there is a high possibility that the font will be illegally used without permission of the copyright holder using a personal computer). Therefore, as long as the high-definition font is copyright-protected (not in the public domain), it can be a target for encryption / decryption by AACS.

  The process shown in FIG. 17 can be simply organized as follows. First, the number of rules to be written in the Usage Rule File is determined (ST300), and the same number of Title Keys are generated (ST302). If encryption of the Advanced Resource File is necessary (ST304Y), one more Title Key is generated (ST306). The generated Title Key encrypted by TK processing is written in Title Key File (ST308).

  If the recording destination medium is not a write-once medium but a medium that can be repeatedly rewritten (for example, HD_DVD-RAM, hard disk, semiconductor flash memory, etc.), ST300 in FIG. 17 is skipped and one Title Key is inserted at ST302. You may make it produce | generate.

  FIG. 18 is a flowchart for explaining an example of a processing procedure when a copyright-protected information resource (font or the like) is used for a menu or the like. For example, when a disc is loaded into the HD_DVD Drive 26 in FIG. 13, the firmware of the MPU 40 in FIG. 13 reads the information in the BCA or lead-in area of the disc to determine whether the disc is an AACS compatible medium. (ST500). If the disc is a medium compatible with AACS (ST500Y), for example, the menu screen 52a of FIG. 13 is created using resource information (such as a copyrighted font) such as ARF of FIG. 17 (ST502). Then, a part of ARF (such as a font with a copyright among fonts used in the menu) is encrypted with AACS (similar to ST306 in FIG. 17) and recorded on medium 100 (ST504).

  On the other hand, if the medium is not compatible with AACS (ST500N), a menu (for example, 52c in FIG. 13) with a different appearance is created without using the part of the ARF (such as a font with copyright). ST510). Alternatively, if the recording destination is a medium that does not support AACS (for example, a conventional DVD-R / RW / RAM disk 102 or a medium based on a standard other than HD_DVD), a menu is not created in the processing of ST510 (result) In other words, the menu may not be recorded on an AACS non-compliant disc).

  By the way, in the HD_DVD Video Recording Format, a “script of XML format of HD_DVD Video Advance Content format called Interoperable Content” called “Interoperable Content” is recorded on the recorder (for example, FIG. 13) side so that HD_DVD Video Player can also play back the content composed of VOB. Recording is an essential function.

  In Interoperable Content, for example, a font used to display text in a menu is stored in a file called Advance Resource File (ARF) in the disc. Therefore, the characters cannot be displayed on the menu unless the font is written on the disc by the recorder. This font data is in the Open Type Font format and is general that can be used on a personal computer or the like. Therefore, when the font data is written on the disk by the recorder, the font can be used for other purposes.

  In order to prevent this, the HD_DVD Advance Resource File is allowed by the AACS to be encrypted. If it is encrypted, it cannot be decrypted even if the file is copied from the HD_DVD disc, and the diversion of the font can be prevented. AACS performs encryption using a Media ID or the like recorded on a compatible medium. Therefore, encryption cannot be performed on AACS non-compliant media. For this reason, first, AACS support / non-support determination is performed, and in the case of AACS non-support media, text data is not used for an interoperable content menu or the like, and image data that does not require encryption (Fy, Fz in the example of FIG. 13). Only, and copyright-protected fonts (Fx, Ix in the example of FIG. 13) are not stored on the disk. On the other hand, in the case of the AACS compatible medium 100, since the font is protected by encryption, a menu using text is generated (ST502 in FIG. 18), and the font data (file including the data) is encrypted by AACS (FIG. 18). 18 ST504).

  In the menu screen 52a of FIG. 13, the thumbnail of each title includes text Fx using a copyrighted font and copyright, in addition to a font Fz that does not exercise copyright and an image character pattern Fy that does not exercise copyright. An image Ix is used. The information on the menu screen 52a and the title object (VOB and / or SOB) corresponding to the information are encrypted by AACS and recorded on the AACS-compatible medium 100.

  On the other hand, when the recording destination is a medium that does not support AACS (for example, the conventional DVD_R / RW / RAM disc 102), the menu screen has neither the text Fx using the copyrighted font nor the copyrighted image Ix. 52c is created (ST510 in FIG. 18), and the information is recorded on the AACS non-compliant medium 102 (in this case, for example, the CSS (Content Scramble System) method is used for object encryption).

  Note that whether or not the target medium is “AACS-compatible medium” can be appropriately determined according to the type of the medium, for example. For example, when the medium is an HD_DVD-R / RW / RAM disc, a BCA (Burst Cutting Area) in which information unique to the disc is recorded in a barcode-like pattern inside a part of the lead-in area of the disc. ) Is provided. In this BCA record, information (BCA Record ID) including an HD_DVD standard identifier (HD_DVD book type Identifier), HD_DVD standard format and disc format information (Book type and Disc type), and the like can be described. If it is determined from the BCA record including such information that the disc is an HD_DVD standard disc, it can be determined that the disc is “AACS compatible media” (when the BCA record indicates that the disc is not an HD_DVD standard disc) , Can be treated as non-AACS compatible media).

  In addition, when the above-mentioned Media ID is present in the BCA of the target medium, there is a method of determining “whether it is an AACS compatible medium” from the Media ID.

  Also, an RMA (Recording Management Area) is provided in the lead-in area of the disc, and disc-specific information (Unique Disc ID) for identifying that the disc is an HD_DVD standard disc is described in this RMA. For example, there is a method for determining that the disc is “AACS-compatible media” based on the description content (when the disc cannot be identified as a disc of the HD_DVD standard from the Unique Disc ID, it can be handled as an AACS-incompatible media). .

  Furthermore, when the medium is HD_DVD-R / RW / RAM or HD_DVD Video (ROM disc), physical format information can be recorded inside the lead-in area of the disc. If the HD_DVD standard format and its part version information (Book type and Part version) are described in the physical format information, it can be determined from the description that the disc is “AACS-compatible media” (Book When the type and part version does not correspond to the HD_DVD standard, it can be handled as an AACS non-compliant medium).

<Summary of Embodiment>
(1) In a recording / playback apparatus that records HD_DVD media in HD DVD Video Recording Format, when the media inserted in the disk drive of the apparatus is compatible with AACS, the font used in the interoperable content is set to Advanced Resource. A file is encrypted and recorded by AACS.

  (2) In a recording / playback apparatus for recording on an HD_DVD medium in the HD DVD Video Recording Format, if the medium inserted into the disk drive of the apparatus does not support AACS, a copyright protected font is used. Interoperable Content is generated that displays a menu composed of only image data (or font and image data for which copyright is not exercised) without using characters.

<Effect of Embodiment>
When generating the interoperable content, whether or not the (copyright protected) font is recorded on the disc depending on whether the media on which the interoperable content is recorded is AACS-compatible or not (or a menu including such a font is recorded on the disc. By separating (recording / not recording), unauthorized diversion of fonts can be prevented.

<Others>
(01) An information access management method according to an embodiment of the present invention uses resource information (font, sound effect, still image, etc.) including a part (such as a copyrighted font) to be protected from unauthorized access. It is used when information of a predetermined screen (menu or each screen in a video program) is appropriately recorded on the information recording medium (100). Here, it is checked whether or not the information recording medium (100) is a medium compatible with a predetermined encryption system (AACS) (ST500), and the medium is compatible with the predetermined encryption system (AACS). In this case (ST500Y), the predetermined screen (eg, menu screen: screen 52a in FIG. 13) is created using the resource information (such as a copyrighted font) (ST502), and the portion of the resource information (menu Among the fonts used, a copyrighted font or the like) is encrypted by the predetermined encryption method (AACS) (similar to ST306 in FIG. 17) and recorded on the medium (ST504). On the other hand, when the medium does not support the predetermined encryption method (AACS) (ST500N), the predetermined screen (for example, the appearance is different) without using the portion (such as a copyrighted font) of the resource information. Menu (52c in FIG. 13, etc.) or the predetermined screen (menu) is not created (ST510).

  (02) The information recording medium (100) is a recordable medium compatible with the predetermined encryption method (AACS) and can be played back by a playback-only player (HD_DVD video player). In the case of a medium (HD_DVD-R / RW / RAM, etc.) capable of recording (Content), a menu (52a in FIG. 13) is created using the font used in the interoperable content (ST502), and the interoperable The font used in the bull content is stored in a predetermined file (Advanced Resource File: ARF), and the file (ARF) is encrypted by the predetermined encryption method (AACS) and recorded on the information recording medium (100). (ST306 and ST308 in FIG. 17).

  (03) The information recording medium (100) is a recordable medium that does not support the predetermined encryption method (AACS) and can be played back by a playback-only player (HD_DVD video player). For media that can record (Content) (HD_DVD-R / RW / RAM, etc.), create a menu (52c in FIG. 13) without using the font used in the interoperable content, or create a menu. No (ST510).

  (04) The management information (HR_MANGR.IFO) including the information on the menu is read from the information recording medium (100) on which the information on the menu (52a or 52c in FIG. 13) is recorded (ST200). Can be played back (ST202 to ST206).

  (05) The recording apparatus according to the embodiment of the present invention (the encoding side in FIG. 13) uses resource information (font, sound effect, still image) including a portion (such as a copyrighted font) to be protected from unauthorized access. Etc.) is recorded on the information recording medium (100) on a predetermined screen (such as 52a in FIG. 13). This apparatus checks whether or not the information recording medium (100) is a medium compatible with a predetermined encryption system (AACS) (ST500 in FIG. 18), and supports the predetermined encryption system (AACS). In the case of the media (ST500Y), means for creating the predetermined screen (52a, etc. in FIG. 13) using the resource information (font with copyright, etc.) and 210a in FIG. 13 for processing ST502 in FIG. 400), and encrypting the portion of the resource information (such as a copyrighted font among the fonts used in the menu) with the predetermined encryption method (AACS) (same as ST306 in FIG. 17) And recording means (210a, 408, 20-24 in FIG. 13 for processing ST504 in FIG. 18).

  (06) A playback apparatus (decoding side in FIG. 13) according to an embodiment of the present invention uses a predetermined key (Title Key or Kt) to encrypt content (AACS) encrypted by a predetermined encryption method (AACS). Title) and the encrypted resource file (ARF) are reproduced from the information recording medium (100) corresponding to the predetermined encryption method (AACS). This apparatus includes means for reading management information (HR_MANGR.IFO) of the content (Title) from the information recording medium (100) (the processing of ST200 408, 22-24), and information related to the encryption (Kt, etc.) Means for generating a decryption key (Kt or Contents Key) by reading from the information recording medium (100) (210a, 22-24 for performing processing of ST202 to ST204), and the information recording Using the management information (HR_MANGR.IFO) read from the medium (100) and the generated decryption key (Kt or Contents Key), the encrypted resource file (ARF) or the encrypted content (Title ) For decoding while decoding (210a, 408, 22-30 for performing the processing of ST206).

  (07) An information storage medium (a disc on which an ARF including a font encrypted with AACS) according to an embodiment of the present invention is a recordable medium compatible with a predetermined encryption system (AACS). There is a medium (such as HD_DVD-R / RW / RAM) that can record interoperable content that can be played back by a player dedicated to playback (HD_DVD video player). The information recording medium (100) includes an area (HR_MANGR.IFO) for storing information of a menu (52a in FIG. 13) created (ST502) using a font used in the interoperable content, and the interoperator. An area (HR_MANGR.IFO) for storing a predetermined file (ARF) encrypted by the predetermined encryption method (AACS).

  The present invention is not limited to the above-described embodiment, and can be variously modified within the scope of the gist of the present invention or a future implementation stage based on the technology available at that time. It is.

  In addition, the embodiments may be appropriately combined as much as possible, and in that case, the combined effect can be obtained. Further, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. For example, even if some configuration requirements are deleted from all the configuration requirements shown in the embodiment, a configuration from which these configuration requirements are deleted can be extracted as an invention.

The figure explaining the structure of the data (title key file) in the medium (information recording medium) concerning one embodiment of this invention. The figure explaining the process example which decodes the encryption content recorded on the medium. The figure explaining the example of a process which encrypts a content and records on DVD. Explanatory drawing which shows the structure of a title key file as a title key file and its backup file. The figure which shows the data on the media required by the recording / reproducing process using the encryption system (AACS system) employ | adopted by one embodiment of this invention. The figure which shows the data on the media required by the recording / reproducing process of an AACS system. The figure which shows the data on the media required by the recording / reproducing process of an AACS system. The figure which shows the structural example of the encrypted title key file (E-TKF). The flowchart figure explaining the update procedure of the title key file of a rewritable medium. The flowchart figure explaining the write-in procedure of the title key file of write-once media. The figure explaining the data structure example which concerns on one embodiment of this invention. The figure explaining the example of a file structure concerning one embodiment of this invention. The block diagram explaining the structural example of the recording / reproducing apparatus (HD_DVD recorder) which concerns on one embodiment of this invention. The flowchart figure explaining the recording method concerning one embodiment of this invention. The flowchart figure explaining the reproducing | regenerating method which concerns on one embodiment of this invention. The figure which shows the structural example of Title Usage Rule File. The flowchart figure explaining an example of the process sequence at the time of writing Title Key File first to information recording media, such as HD_DVD-R. The flowchart figure explaining an example of the process sequence in the case of using the information resources (font etc.) by which copyright protection was used for a menu etc.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 20 ... Encoder; 24 ... Optical disk drive unit; 26 ... Blue laser optical disk drive (HD_DVD Drive); 28 ... Red laser optical disk drive (DVD-R / RW / RAM Drive); 30 ... Decoder; 40 ... Control microprocessor ( MPU); 400 ... Graphic user interface (GUI) display control unit (firmware); 402 ... Encoding parameter detection processing unit (firmware); 404 ... High speed copy / high speed dubbing processing unit (firmware); 406 ... Rate conversion copy / Rate conversion dubbing control unit (firmware); 408... Recording / playback control unit (management information processing unit) (firmware); 210a... AACS processing unit; 50 .. On-screen display (OSD) unit; Display example: 100, 102 ... Information storage medium (optical disk) 104 ... information storage medium (hard disk drive); 200 ... information recording and reproducing apparatus, 210 ... controller, 220 ... read unit, 230 ... writing unit.

Claims (7)

Information on a predetermined screen using resource information including a part to be protected from unauthorized access is appropriately recorded on an information recording medium,
Check whether the information recording medium is a medium compatible with a predetermined encryption method,
When the medium is compatible with the predetermined encryption method, the predetermined screen is created using the resource information, and the portion of the resource information is encrypted with the predetermined encryption method and recorded on the medium. ,
An information access management method that creates the predetermined screen without using the portion of the resource information when the medium does not support the predetermined encryption method, or does not create the predetermined screen.   Used in the interoperable content when the information recording medium is a recordable medium corresponding to the predetermined encryption method and can record an interoperable content that can be played back by a player dedicated to playback. 2. A menu is created using a predetermined font, the font used in the interoperable content is stored in a predetermined file, and the file is encrypted by the predetermined encryption method and recorded on the information recording medium. The method described in 1.   Used in the interoperable content when the information recording medium is a recordable medium that does not correspond to the predetermined encryption method and can record an interoperable content that can be played back by a player dedicated to playback. The method of claim 1, wherein the menu is created without using the generated font, or the menu is not created.   A method for reading management information including information on the menu from the information recording medium on which the information on the menu according to claim 2 is recorded, and reproducing an object managed by the management information. Recording information on a predetermined screen using resource information including a part to be protected from unauthorized access on an information recording medium,
It is checked whether or not the information recording medium is a medium corresponding to a predetermined encryption method, and if the medium is compatible with the predetermined encryption method, the predetermined screen is created using the resource information Means,
A recording apparatus comprising: means for encrypting the portion of the resource information with the predetermined encryption method and recording the encrypted information on the medium. An apparatus for reproducing content encrypted by a predetermined encryption method using a predetermined key and an encrypted resource file from an information recording medium corresponding to the predetermined encryption method,
Means for reading the content management information from the information recording medium;
Means for reading the information relating to the encryption from the information recording medium and generating a decryption key;
A playback device comprising: means for playing back the encrypted resource file or the encrypted content using the management information read from the information recording medium and the generated decryption key. It is a recordable medium corresponding to a predetermined encryption method, and can record interoperable content that can be played back by a player dedicated to playback,
An area for storing information of a menu created using the font used in the interoperable content;
An information recording medium comprising an area for storing a font used in the interoperable content and storing a predetermined file encrypted by the predetermined encryption method.

Images