RU2249245C2 - Method and device for processing data with copyrights - Google Patents

Abstract

FIELD: devices for processing data with copyrights.

SUBSTANCE: device for processing data, realizing a method for processing of data with copyrights within limits of given rights, contains memory device for distributed data, means for recording data concerning rights and data, means for converting data, means for realization of processing method.

EFFECT: higher efficiency.

3 cl, 60 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for processing copyright data, and more particularly, to a method and apparatus for processing copyright data distributed via a communication network.

State of the art

In recent years, various sources of information have become widely available and a large number of digital recordings have been distributed with multimedia content environments including images and sounds. Such digital recordings are provided to users by means of recording media such as a compact disc-read-only memory (CD-ROM) or communication media such as the Internet. Downloading personal computers through a communication network is a particularly convenient distribution method, and therefore this method is expected to be widely distributed. Digital recordings are easily copied without sacrificing performance. For this reason, the copyright protection of digital recordings is highly relevant.

The following common procedures are known to protect the copyright of digital recordings. The first common procedure is the content management method used in the music distribution system, which was published in the article: “Internet-based music distribution requires urgent improvements in copyright protection techniques”

Nikkei Electronics, no. No. 738, March 8, 1999, pp. 87-111 ("Internet - based music distribution requires immediate improvements in copyright protection technologies", Nikkei Electronics, Issue, No. 738, March, 8, 1999, pp. 87-111). In a content management method including encrypted music data (hereinafter referred to as file A) and a file containing control information, a decryption key of file A and another (hereinafter referred to as file B) are distributed via a communication network. In order to reproduce the music data contained in file A, it is determined with reference to the control information contained in file B whether it is allowed to play or copy file A.

Fig. 46 is a block diagram showing a structure of a data processing apparatus using the first known procedure. The data processing apparatus shown in FIG. 46 is connected while operating with a communication network (not shown). The distributed data memory unit 101 stores a file A distributed via a communication network such as the Internet and cable television. In the copyright management table 102, a file B distributed via the communication network is stored, the same as for the file A. The processing method purchasing unit 103 establishes a connection with a payment settlement server (not shown) to purchase the right to the processing method required for reproduction, and other processes and records the acquired right to a processing method in a copyright management table 102. When a command is entered using the input block 104, the control unit 105 determines, with reference to the right to the processing method recorded in the copyright management table 102, this command should or should not be executed. The playback device 106 receives the decryption key contained in file B from the control unit 105, and reproduces the music data contained in file A.

As a second conventional procedure, a method is known for preventing unauthorized copying by encrypting digital data, which is disclosed in Japanese Patent Application Laid-open No. 9-320192 (1997-320192). Fig. 47 is a flowchart showing a structure of a copyright protection apparatus according to a second conventional procedure. The copyright protection device shown in FIG. 47 is characterized in that the digital data read from the disk 111 is encrypted before it is sent to the bus 114. In other words, the data formatting unit 112 provides the data read from the original disk 111 encryption information, an encryption key, encryption unit information, copy management information indicating whether or not data copying is allowed, and identification information of the encryption algorithm used. The encryption unit 113 encrypts the data using the encryption key provided by the key delivery unit 110. The encrypted data flows through the bus 114. The decryption unit 115 decrypts the data using the decryption key provided by the key delivery unit 110. The decrypted data is restored by the data formatting unit 116 to the state in which it was read from the disc 111 and then played back by the playback device 117.

Essentially, according to the first ordinary procedure, the received copyright data can be processed within the purchased right to the processing method, however, according to the second ordinary procedure, the copyright data can be protected from unauthorized copying.

These common procedures, however, do not disclose details about how to use the accepted data with copyright. In particular, the format in which the data processing device uses copyright data is not disclosed.

In a music distribution system, for example, a device for processing music data receives music data via a communication network and copies received music data to an external storage medium. A data processing device is provided with music data from many providers. Due to the fact that copyright to the music data belongs to each of the providers, the music data is distributed using the format characteristic of each of the providers. Music data can be copied to various types of external storage media, such as random access memory (RAM), digital video discs, and memory cards. Therefore, when copying to an external storage medium, the distributed music data must be converted to a format specific to each type of external storage medium.

In circumstances where there are many providers and many types of external storage media, as described above, the distributed copyright data cannot be processed efficiently using the above procedures, since the latter do not indicate the format in which the copyright data is processed.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a device for processing copyright data by converting copyright data distributed through a communication network into an internal format suitable for subsequent processing.

The present invention has the following features to achieve this goal.

The first object of the present invention is a device for processing data, processing data with copyright within the acquired rights, including: a distributed data memory unit, which is an example of a means for receiving data, configured to receive data in a distribution format, including at least substantial data for protection and information for calculating payment defining payment conditions for meaningful data; the right purchase unit, which is an example of the implementation of the means for storing and processing information about the purchase rights, made with the possibility of processing information for calculating payment, and for acquiring the right on the terms of the purchase; a block for storing information about the right, which is an example of the implementation of the means for storing information about the right, made with the possibility of storing the right to the processing method acquired by the block of the purchase of the right; a data conversion unit, which is an example of a means for converting data, configured to convert distribution format data including meaningful data to internal format data without payment calculation information when a right to a processing method is acquired for the content data; a data storage unit, an exemplary embodiment of a means for storing data, configured to store internal format data obtained by a data conversion unit, which is an example implementation of a means for converting data; and a processing method implementation unit, which is an example of a processing method implementation means, adapted to process internal format data stored in a data storage unit within a right to a processing method stored in a right information storage unit.

With such a device for processing data, copyright data is converted into internal format data without information for calculating payment and then stored in a storage device (memory). Therefore, this data can be processed in various ways when managing copyright through a single procedure, regardless of the method of calculating payment.

In addition, when the content data can be encrypted and the payment calculation information contains a decryption key for decrypting the encrypted content data, the decryption key can be extracted from the payment calculation information by the data conversion unit and stored in the storage unit of information about the right. The method implementation unit may decrypt the encrypted content data using the decryption key. Thus, the decryption key is controlled by the right information storage unit, thereby providing decryption of the data by the same procedure, regardless of the distribution method of the decryption key.

In addition, distribution format data may include informative data, information for calculating a payment, header and information for controlling the implementation of the method to control the implementation of the processing method for the informative data. A device for processing such data can control data processing, as intended by the creator of the content data, through information to control the implementation of the processing method.

In addition, the data in the internal format may be equivalent to the data received by the department only of information for calculating payment from data in the distribution format. Due to this, the processing method in the data conversion unit becomes easy and the processing speed of the data processing apparatus can be increased.

Another aspect of the present invention with respect to the first object is that the processing method implementation unit includes a data copying device for copying internal format data stored in the data storage unit to a removable storage medium, and the data conversion unit converts the distribution format data into internal format data based on the type of storage medium.

More preferably, the data processing apparatus also includes a storage medium detection unit for determining the type of storage medium, or a storage medium determination unit for determining the type of storage medium, and a data conversion unit can convert the distribution format data to internal format data based on type of storage medium identified or identified by these blocks.

In such a data processing apparatus, copyright data is converted into internal format data suitable for the type of storage medium, and then stored. Therefore, the amount of data in the data processing apparatus can be reduced.

In addition, if the distribution format data contains one or more parts of the content data, the internal format data may include only the content data for copying on a storage medium between one or more parts of the content data. By selecting and storing only the required content data, the amount of data can be significantly reduced.

The second object of the present invention is a data processing method for processing data with copyright within the granted rights, including: the step of receiving data when receiving distribution format data, including at least substantial data for protection and information for calculating payment defining a payment term for meaningful data; the stage of purchasing the right when purchasing processing on the basis of information for calculating payment and acquiring the right to the processing method required to process meaningful data; the stage of storing information about the right while retaining the right to the processing method acquired at the stage of purchasing the right; the step of converting data when converting distribution format data including meaningful data into internal format data without information for calculating payment when the right to a processing method for meaningful data is acquired; the step of storing data when storing data of the internal format obtained at the stage of data conversion; and a step for implementing a processing method when processing internal format data stored in a data storage step, within a right to a processing method stored in a right information storage step.

A third aspect of the present invention is a recording medium for recording programs on it to implement a data processing method on a computer according to a second aspect of the present invention.

In accordance with the second or third objects of the invention, the copyright data is converted into data in the internal format without information for calculating the payment and then entered into the memory unit. Therefore, data can be processed in various ways when managing copyright through the same procedure, regardless of how payment is calculated.

As indicated above, the method and apparatus for processing copyrighted data according to the present invention provides the user with an excellent tool that is extremely effective in practical use.

These and other objectives, features, aspects and advantages of the present invention will become more apparent from the following detailed description of the present invention with reference to the accompanying drawings.

Brief Description of the Drawings

1 is a block diagram showing a structure of a data processing apparatus in accordance with a first embodiment of the present invention,

FIG. 2 is a diagram showing a structure of a music distribution system using a data processing apparatus according to a first embodiment,

3a-3c are diagrams showing music data formats that are used by the data processing apparatus according to the first embodiment,

4 is an exemplary procurement management table in a data processing apparatus according to a first embodiment,

5 is an example copyright management table in a data processing apparatus in accordance with a first embodiment,

6 is a block diagram showing the operation of a control unit in a data processing apparatus in accordance with a first embodiment of the invention,

FIG. 7 is a flowchart showing the operation of a purchasing unit of a processing method in a data processing apparatus according to a first embodiment,

Fig. 8 is another diagram showing a music distribution system using a data processing apparatus in accordance with a first embodiment,

9 is a block diagram showing a structure of a data processing apparatus in accordance with a second embodiment of the present invention,

10 is a flowchart showing the operation of a data conversion unit in a data processing apparatus in accordance with a second embodiment,

11 is a block diagram showing in detail the operation of the data conversion unit in the data processing apparatus according to the second embodiment,

12 is an exemplary packet management table in a data processing apparatus according to a second embodiment,

13a-13c are diagrams showing the effect of a data conversion method in a data processing apparatus according to a second embodiment,

FIG. 14 is a diagram showing another music data format processed by a data processing apparatus according to a second embodiment,

15 is a block diagram showing a structure of a data processing apparatus according to a third embodiment of the present invention,

Fig. 16 is a diagram showing a screen for determining an external storage medium by a data processing apparatus in accordance with a third embodiment,

17 is a flowchart showing the operation of a data conversion unit in a data processing apparatus according to a third embodiment,

FIG. 18 is a diagram showing a packet structure of a secure digital audio format (WCD) in accordance with a fourth embodiment of the present invention, FIG.

Figa-19c are diagrams showing other structures ZZZF packages

Fig. 20 is a diagram showing how to divide a WZZF title into WZZF packets,

Fig. 21 is a diagram showing an example of an SCZF packet;

Fig is a diagram showing the structure of the header,

23 and 24 are illustrations of source codes describing the structure of the header using the C ++ language;

Figa-25C are diagrams showing how to determine the table of defining signs of ELS using the label structure,

FIG. 26 is a diagram showing a correspondence between key pairs and content elements (ELS), FIG.

Fig. 27 is an illustration of source codes describing the structure of key pairs using the C ++ language,

28 is a diagram showing how to access an ELS based on navigation data,

Fig.29 and 30 are diagrams showing the structure of navigation data,

Fig is a table showing the characteristics of the international standard for compression and reproduction of moving images MPEG2-AAC, applicable to audio ELS,

Fig is a table showing the characteristics of the international standard for the compression of full-color still video JPEG images applicable to video ELS,

33 is a table showing the characteristics of an MPEG-1 frame applicable to ELS video,

Fig. 34 is a table showing the characteristics of PNG applicable

to the ELS video,

Fig. 35 is a table showing the characteristics of MPEG2 applicable to ELS video,

Fig. 36 is a diagram showing a structure of a temporary search map,

37, 38a and 38b are tables and diagrams showing in detail the title contained in the temporary search map,

Fig. 39 is a table showing each entry in detail entered in a temporary search table,

40 is a table showing an example of an ELS forwarders,

Figa-41C are diagrams showing examples of how to distribute the SCZF package,

Figa-42C are diagrams showing examples of how to create a SCZF package,

Fig. 43 is an external view of a portable music player;

Figures 44 and 45 are block diagrams showing the structure of a data conversion unit,

Fig. 46 is a block diagram showing a structure of a known data conversion apparatus, and

Fig. 47 is a block diagram showing a structure of a known copyright protection device.

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiments of the present invention are described below with reference to the drawings. First, as a first and up to a third embodiment, data conversion devices for converting distributed copyright data into a predetermined internal format are described. Then, as a fourth embodiment, a specific example of copyright data is described in detail in accordance with the first and third embodiments.

It is noted that the copyright data according to the fourth embodiment is merely an example of data in accordance with the first and third embodiments, and it goes without saying that the data processing apparatus according to the first and third embodiments can process other copyright data . In addition, although a description will be given here with the assumption that the copyright data is music data, the copyright data in the present invention is not limited to music data, but it can be video data, text data, or combinations thereof and music data.

(First Embodiment)

1 is a block diagram showing a structure of a data processing apparatus according to a first embodiment of the present invention. The data processing device 1 shown in FIG. 1 comprises an input unit 10, a data reception and storage unit 11, which is an example of a data reception device configured to receive and store data in a distribution format, a procurement management table 12, a purchasing unit 13 of the processing method, data conversion unit 14, internal data storage unit 15, which is an example of the implementation of means for storing data, copyright management table 16, which is an example of the implementation of means for remembering information about the right, control unit 17, playback unit 18, input and output control unit 19, blocks 17, 18, 19, which are an example of the implementation of the processing method, and display unit 21. Device 1 for data processing performs playback, copying and other operations with distributed music data with copyright and is characterized in that the distributed music data is converted into an internal format for storage in a storage device.

Before a detailed description of the data processing apparatus 1, a music distribution system using the data processing apparatus 1 and music data formats processed in the data processing apparatus 1 are described with reference to FIGS. 2 and 3.

As shown in FIG. 2, the data processing apparatus 1 is connected via a communication network 4 to a distribution server 5 and a server 6 for calculating a charge. Communication network 4 is a network such as the Internet or a network for cable television, satellite communications or cell phones. Distribution server 5 stores in its memory a large amount of music data with copyright. In response to a request from the data processing apparatus 1, the distribution server 5 distributes the music data. Server 6 for calculating payment performs the operation of calculating payment for distributed music data. The external storage medium 7 is removable both from the data processing device 1 and from the music portable player 8. The data processing device 1 identifies each external storage medium 7 using a storage medium identifier specific to each medium 7 or a user-defined label for each environment 7.

Now, copyright management for music data will be briefly described below. The distribution server 5 distributes the encrypted music data and decryption keys to the data processing apparatus 1. The data processing device 1 transmits information that the user agrees to pay for the music data to the server 6 to calculate the payment before or after the distribution in order to purchase the right to process for the distributed music data. For example, the data processing apparatus 1 reproduces music data using decryption keys as many times as there were reproductions determined by the purchased right.

In addition, the data processing device 1 can copy the music data and decryption keys on the external storage medium 7 (such processing will hereinafter be called debugging) and erase the copied music data from the external storage medium 7 (such processing will hereinafter be called control). Device 1 for processing data can debug music data as many times as many debugs are determined by purchased right. The right to debug, which allows only one-time debugging, is restored when the debug data is checked. However, music data can only be controlled by a data device that has debugged music data. In addition, if debugged and edit-protected music data is recorded on an external storage medium, the data processing apparatus 1 does not control the music data.

The music data processed by the data processing apparatus 1 also contains, in addition to audio content, content such as video information, images, text and programs.

3a-3c are diagrams showing three formats of music data processed by the data processing apparatus 1. The distribution format shown in Fig. 3a is used to distribute music data. The internal format shown in FIG. 3b is used to store music data in the data processing apparatus 1. The copy format shown in FIG. 3c is used to debug music data for the external storage medium 7.

The music data is distributed to the device 1 for processing data through a unit called a package. In the distribution format shown in FIG. 3a, a packet consists of four data elements: a header 40, navigation information 41, one or more contents 42, and information 43 for calculating a charge. The header 40 contains information such as a packet identifier for identifying the packet and information about the location and size of other data. Content 42 is content data, such as audio data, video data, images, text or programs. Each content has its own content identifier, which is unique within a particular package, and is encrypted as required.

The navigation information 41 is used as information for controlling reproduction in controlling reproduction of music data. To refer to each content 42 of the navigation information 41, a content identifier is used. The content entered in the package to which the navigation information belongs is referenced only by its identifier, and the content in another package is referenced by its package identifier and content identifier. Information 43 for calculating the payment contains the condition of use, price and decryption key for each content 42.

In the device 1 for processing data, music data is processed when information 43 for calculating the payment is separated from them. In the internal format shown in FIG. 3b, the music data consists of a header 40, navigation information 41 and contents 42.

The music data is converted into a format corresponding to the type of external storage medium 7 before debugging for it. For example, if the external storage medium 7 is a protected digital memory card, the music data is converted into a format so that the audio contents for the memory card memory are entered into it and the video contents are not entered. In the copy format shown in FIG. 3c, the music data consists of a header 44, a content 42, and a decryption key 45. The header 44 corresponds to the type of external storage medium 7. The decryption key 45 is extracted from the information 43 for calculating payment in a distribution format. The content 42 is content data selected based on the type of external storage medium 7 from the music data in the internal format. The music data shown in FIG. 3c contains only one content 42, but may contain one or more contents. When music data is debugged, music data in copy format can be divided into a large number of files for copying.

Figure 1 shows the structure of the device 1 for data processing, described below. Now briefly describe the operation of the device 1 for processing data. The distributed music data is converted into the internal format by the data conversion unit 14 and then stored in the internal data storage unit 15. Information about the right to process each content included in the music data is recorded in the copyright management table 16. The control unit 17 refers to copyright management table 16 to determine whether or not the entered command 30 should be executed. If it is determined that the command should be executed, the control unit 17 issues a command to start playback, debugging, and other operations.

The user enters a command 30 for content by means of an input unit 10. The commands described in the present embodiment are commands for distribution, purchase, reproduction, debugging, and control. In addition, other examples include moving, setting a mode, commands for classifying data, editing data, searching for data, importing, exporting, adding user data, entering torn contents, and checking credentials.

The distributed data memory unit 11 stores music data in a distribution format distributed by the distribution server 5. The purchasing management table 12 stores, as shown in FIG. 4, a packet identifier 50, a content identifier 51, and a purchasing condition 52 as a set for each content entered into the music data stored in the distributed data memory unit 11. The purchase condition is determined when purchasing content. For example, such a condition includes only reproduction, full purchase, and trial listening. If the purchase condition is only reproduction, then the content may be reproduced only a certain number of times or only in a certain period. If the condition of the purchase is a full purchase, then the content can be freely reproduced and debugged only a certain number of times. If the condition for the purchase is trial listening, then the content can be played an unlimited number of times within a certain period of time.

Upon receipt of the purchase command 30 from the input unit 10, the processing purchase unit 13 transmits information that the user agrees to pay for the music data to the server 6 to calculate the payment in order to acquire the right to distributed music data. Therefore, the processing procurement unit 13 records the acquired processing right in the procurement management table 12. If certain content is not stored in the distributed data memory unit 11, the processing purchasing unit 13 requests the distribution server 5 to distribute music data including the content. After receiving the music data, the processing purchase unit 13 provides the control signal 31 to the data conversion unit 14 as a data conversion command.

Upon receipt of the control signal 31, the data conversion unit 14 converts certain music data into an internal format. In other words, the data conversion unit 14 separates payment information 43 from the distributed package to obtain music data of the internal format. The data conversion unit 14 also extracts the decryption key 54 for each content from the payment calculation information 43 and writes the decryption key in the copyright management table 16.

The internal data storage unit 15 stores music data in an internal format output from the data conversion unit 14. Music data stored in memory must be played, debugged, etc.

In the copyright management table 16, as shown in FIG. 5, copyright management information for each content stored in the internal data storage unit 15 is stored. The copyright management table 16 contains the package identifier 50, the content identifier 51, the purchase condition 52, the right purchase date 53, the decryption key 54, the number of 55 plays, the number of 56 debugs and the debug addressing information 57. Note that FIG. 5 shows one table divided into two parts, shown as (a) and (b), and in this table, before its division, the number of 55 reproductions follows the decryption key 54.

Package identifier 50, content identifier 51, and purchasing condition 52 are the same data as the data stored in the procurement management table 12. Date 53 of the procurement law indicates the date of procurement of content. The decryption key 54 is used to decrypt the encrypted content. The number of 55 reproductions indicates the number of reproductions of the content. The number of 56 debugs indicates how many contents have been debugged. The debug addressing information 57 contains a storage medium identifier and a label for the external storage medium on which the content was debugged. A label is assigned to an external storage medium when music data is initially debugged on it.

The packet identifier 50, the content identifier 51, the purchase condition 52, the right purchase date 53 and the decryption key 54 are set to set values when new music data is input to the internal data storage unit 15. The packet identifier 50, the content identifier 51 and the purchase condition 52 are set to the values set by the processing purchase unit 13, and the decryption key 54 is set to the value set by the data conversion unit 14. The number of 55 reproductions and the number of 56 debugs are initially set to 0, and the debug addressing information 57 is erased. Copyright management table 16 is encrypted using an encryption method that is unusual for data processing device 1 and serves to protect against unauthorized access to data.

The control unit 17 refers to the copyright management table 16 to determine whether the command 30 should be executed or not. When it is determined that the command 30 should be executed, the control unit 17 generates a command to start playback or debugging. Now, the operation of the control unit 17 is described with reference to the flowchart shown in FIG. 6. Upon receipt of the content command 30 (step S101), the control unit 17 reads copyright management information of that content from the copyright management table (step S102). The control unit 17 then uses the read copyright management information to determine whether or not the command 30 should be executed (step S103). For example, when a playback command is received, the control unit 17 refers to the number of allowed plays or to the allowed play period entered in purchase condition 52. If the number of reproductions is not more than the number of permitted reproductions or if the given time is within the allowed period of reproduction after the date 53 of the purchase of the right, then the control unit 17 determines that the reproduction command should be executed.

When it is determined that the command should be executed, the control unit 17 updates the number of 55 reproductions, the number of 56 debugs or other relevant parameters contained in the copyright management table 16 (step S104). The control unit 17 generates a control signal 32 supplied to the corresponding processing unit to start processing (step S105). At this time, the control unit 17 also outputs a decryption key 54, read from the copyright management table 16 and input to the control signal 32. On the other hand, when determining that the command should not be executed, the control unit 17 outputs the control signal 32 for warning indication a display unit 21 (step S106).

Upon receipt of the control signal 32 to start playback, the playback device 18 reads the specific content from the music data stored in the internal data storage unit 15 and reproduces the content using the received decryption key 54.

When receiving the control signal 32 to start debugging, the verification unit 19 for inputs and outputs for processing reads certain content from the music data stored in the internal data memory unit 15, converts it into a format for copying, and writes the converted music data to an external storage medium 7. When receiving the control signal 32 to start monitoring, the control unit 19 at the inputs and outputs erases the music data copied to the external storage medium 7.

The control unit 19 for inputs and outputs also reads the identifier 33 of the storage medium from the external storage medium 7 and outputs it to the control unit 17. The control unit 17 records the received storage medium identifier 33 in the copyright management table 16 after debugging. The control unit 17 also determines before the control whether or not control can be carried out depending on whether the received storage medium identifier 33 has been recorded or not in the copyright management table 16.

Upon receipt of a control signal 32 for a warning indication, the display unit 21 generates a warning indication and displays it on a CRT or a liquid crystal display.

The data conversion operation that characterizes the data processing apparatus 1 is described below. With reference to the flowchart shown in FIG. 7, the operation of the processing purchase unit 13 is first described to explain the conditions for data conversion.

The processing purchase unit 13 first receives a command 30 for purchasing content from the input unit 10 (step S201). The procurement team 30 determines the identifier of the content to be procured and the condition for its procurement. The purchase condition for the content is equivalent to the purchase condition 52 shown in FIG. 4, including only reproduction, full purchase, trial listening and more. Then, the processing purchase unit 13 establishes a connection with the payment calculation server 6 to pay for the acquisition of certain content under a certain purchasing condition (step S202). Processing purchase block 13 pays, referring to information 43 for calculating payment for a certain content. The processing purchase unit 13 then determines whether the purchase was successful or not (step S203). For example, in step S202, the processing purchase unit 13 transmits to the payment calculation server 6 information that the user agrees to pay for certain content under a certain purchasing condition. Then, in step S203, when receiving information from the payment calculation server 6 to confirm the payment calculation, the processing purchase unit 13 determines whether the payment has followed or not. It should be noted that the manner of payment made by the processing purchase unit 13 is not limited to the above.

If a purchase has occurred, the processing purchase unit 13 further determines whether or not certain content is stored in the distributed data memory unit 11 (step S204). If the content is not stored in the memory unit, the processing purchase unit 13 requests the distribution server 5 to distribute music data including the content (step S205). After introducing certain content into the distributed data memory unit 11, the processing purchasing unit 13 outputs a control signal 31 for converting data to the data converting unit 14 (step S206). The data conversion unit 14 converts the music data in a distribution format stored in the distribution data memory unit 11 into an internal format. The converted music data is stored in the internal data storage unit 15.

If the purchase in step S203 has not occurred, the processing purchase unit 13 outputs a control signal (not shown) to notify that the purchase has not occurred on the display unit 21 (step S207). Upon receipt of the control signal, the display unit 21 displays a warning indication indicating that a purchase has not occurred. It should be noted that the procurement does not occur when a certain content is not found or cannot be purchased under a certain procurement condition, or, for example, the amount of payment is insufficient.

As described above, data conversion is performed in the data processing apparatus when the purchase has been made, i.e. when a certain content was purchased under a certain purchasing condition.

Next, the operation of the data processing apparatus 1 in accordance with the present invention is described. Fig. 8 is a diagram showing how music data is distributed from a large number of providers to a data processing device. Each of the distributed music data includes one or more contents 42 and information 43 for calculating payment, and have a format specific to each provider. Of the types of distributed music data, the navigation information 41 and the content 42 cannot be distributed for reproduction or other operations. On the other hand, information 43 for calculating payment is required only for the purchase, but not for reproduction or other operations.

For this reason, the music data of the distribution format is converted into music data of the internal format by separating information 43 for calculating payment from the music data of the distribution format, thereby ensuring that the following operations are performed through a single procedure, regardless of the method of calculating payment for the music data.

In addition, a key 54 for decrypting the encrypted content 42 is extracted from the information 43 for calculating the payment, and then it is stored in the copyright management table 16. Thus, complete control of the decryption key 54 allows you to decrypt the music data through the same procedure, regardless of how the decryption key is distributed.

In addition, the internal format is similar to the distribution format without information 43 for the calculation of payment. Therefore, data conversion can be carried out without decrypting the encrypted data, and then encryption. This makes a simple operation in the data conversion unit 14 and the processing speed of the data processing apparatus becomes higher.

In addition, information for the calculation of payment is separated from the music data of the distribution format after data conversion. Therefore, the amount of data in the data conversion apparatus 1 can be reduced for information 43 for calculating the data. This method is quite effective if the calculation information 43 is large in size for a complex payment calculation operation.

In the present embodiment, the copyright information of the music data is stored in the copyright management table 16. Or, each row in the copyright management table 16 shown in FIG. 5 can be added to each package, thereby providing copyright management through the package. In addition, from the characteristics included in the copyright management table 16, the number of 55 reproductions, the number of 56 debugs and the debug addressing information 57 can be managed together in a separate table. Thus, these characteristics are set only once, and the characteristics that are updated, each time the data is converted, can be individually controlled using various tables, thereby improving data protection.

In addition, in the present embodiment, music data of a distribution format and music data of an internal format are stored separately in various data memory units. Or, the musical data of these two types can be stored in one data memory unit.

(Second Embodiment)

9 is a block diagram showing the structure of a data processing apparatus 2 according to a second embodiment of the present invention. The data processing device 2 shown in FIG. 9 comprises an input unit 10, a distributed data memory unit 11, a procurement management table 12, a procurement processing unit 13, a data conversion unit 22, an internal data memory unit 15, a copyright management table 16, control unit 17, playback device 18, input and output control unit 19, display unit 21 and external storage medium determination unit 23. The data processing device 2 is used in the same music distribution system as the data processing device 1 in accordance with the first embodiment. The data processing device 2 is characterized by converting the distributed music data into an internal format based on the type of external storage medium detected. The components in the second embodiment are similar to the components in the first embodiment and are provided with the same digital references, and their description is omitted here.

An external storage medium 7 of various types, such as a random access memory (RAM) on a digital video disc and a memory card, can be connected to the device 2 for processing data. Therefore, debugging requires that the music data be converted to a copy format specific to each type of external storage medium. Pending subsequent conversion to a format for copying, the data converting device 2 converts music data in a distribution format to music data in an internal format based on the type of external storage medium 7.

The external storage medium determination unit 23 determines the type of the external storage medium 7 and outputs a determining signal 35 indicating the detected medium type to the data conversion unit 22. Based on the determining signal 35, the data conversion unit 22 converts the music data stored in the distributed data memory unit 11 into an internal format specified for each type of external storage medium 7.

10 is a flowchart showing the operation of the data conversion unit 22. When receiving a control signal indicative of data conversion (step S301), the data conversion unit 22 performs the following operations (steps S302-306) with music data stored in the distributed data memory unit 11 based on the determining signal 35.

Upon receiving a determining signal 35 indicating that a digital memory is attached to the video disc (step S302), the data converting unit 22 converts the music data into an internal format for the RAM on the digital video disc (step S303). When receiving a determining signal 35 indicating that a memory adapter is connected (step S304), the data converting unit 22 converts the music data into an internal format for the memory card (step S305). In another technique, the data conversion unit 22 converts the music data into a conventional internal format, as shown in FIG. 3b (step S306).

The data conversion unit 22 converts the music data into an internal format based on the type of external storage medium 7 by the following procedure. 11 is a flowchart showing a method of converting to an internal format for RAM on a digital video disc. The method shown in FIG. 11 corresponds to the method in step S303 of the flowchart shown in FIG. 10.

The data conversion unit 22 first copies the header 40 and the navigation information 41 contained in the distribution format (step S401), and sets the variable I to 1 (step S402). Then, the data conversion unit 22 performs the processing operations of steps S403-S407 for each content 42. The data conversion unit 22 reads the determining attribute of the 1st content from the header 40 (step S403). Based on the read defining feature, the data conversion unit 22 determines whether or not the 1st content should be copied to the RAM in the digital video disc (step S404) and, if so, then the 1st content will be copied to the external storage medium 7 (step S405). Then, the data conversion unit 22 increments the variable I by 1 (step S406). If the variable I is not greater than the number of contents, the procedure returns to step S403 (step S407).

In the flowcharts of FIGS. 10 and 11, a method for converting data for some types of external storage media is shown. If another type of external storage medium is connected to the data processing device 2, then a similar processing method is introduced into each flowchart.

The control unit 17 controls the internal format music data using the packet management table shown in FIG. The package management table shown in FIG. 12 contains a packet identifier 60, a number of 61 files, a file name 62, and a file type 63. Each row in FIG. 12 corresponds to one packet.

A packet identifier 60 is used to identify each packet. However, if the header changes during the conversion from distribution format to internal format, a new package identifier is assigned to the package. The number of 61 files is the number of files contained in the package, and the name 62 of the file is the name of each file. Type 63 of the file is the defining characteristic of the file contained in the package. A file of type "distributed" indicates that the file is a distributed file, and a file of type "created" indicates that the file was created by the user.

Next, the operation of the data processing apparatus 2 in accordance with the present embodiment is described. 13a, 13b and 13c are diagrams showing music data in a distribution format, in an internal format and in a format for copying, respectively. The music data in a distribution format shown in FIG. 13a includes audio contents 42-1 and 42-2 and image content 42-3. It is assumed that of these contents, only the audio content 42-2 can be debugged on the external storage medium 7. In this case, the music data in the format for copying shown in Fig.13c, contain only the content 42-2.

Pending subsequent conversion to a format for copying, the data processing apparatus 2 converts the music data from the distribution format to the internal format shown in FIG. 13b for storage. Music data in the internal format includes only audio content 42-2, which can be debugged on the external storage medium 7.

As described above, by converting the distributed music data to an internal format suitable for the type of external storage medium 7, the amount of data in the data processing apparatus 2 can be reduced. The content 42 is large in the amount of data since it contains compressed audio and image content. Therefore, by storing only content that can be debugged later, the amount of data can be significantly reduced.

In addition, distributed music data may contain a large number of contents obtained by applying a large number of compression methods to one source data. On Fig shows an example of such music data. It is assumed in FIG. 14 that the audio contents 42-1 and 42-2 were obtained using two compression methods to the same source data. In this case, the navigation data contains content selection data 46 indicating that one content can be selected from a large number of contents.

When such music data is distributed, the data conversion unit 22 selects contents that can be debugged on the attached external storage medium from a large number of contents. Music data in the internal format contains only selected content. For example, if the external storage medium is a memory card, music data in the internal format includes only content that can be debugged on the memory card. By selecting and storing the contents as described above, the amount of data stored in the internal data storage unit 15 can be reduced.

In addition, the distributed music data may contain a large number of 41 pieces of navigation information based on each type of external storage medium. In this case also, navigation information suitable for the attached external storage medium is selected from a large number of 41 pieces of navigation information, and only the selected navigation information is contained in the music data in the internal format. Here, the navigation information may comprise a larger number of programs supporting the type of data processing device or portable music player. In addition, if the music data includes a large number of contents providing a large number of languages, then contents in a particular language are selected.

As described above, even if the music data includes a large number of contents or a large number of pieces of navigation information, the distributed music data is converted to an internal format based on the type of external storage medium, thereby reducing the amount of data stored in the memory.

In the present embodiment, the music data is copied.

in RAM on a digital video disc in a memory card. If the copyright data is gaming software, the type of gaming machine is set, and then the data is copied to the memory board for the gaming machine, etc.

(Third Embodiment)

FIG. 15 is a block diagram showing a structure of a data processing apparatus 3 according to a third embodiment of the present invention. The data processing apparatus 3 shown in FIG. 15 comprises an input unit 10, a distributed data storage unit 11, a purchasing management table 12, a purchasing operation unit 13, a data conversion unit 22, an internal data storage unit 15, a copyright management table 16 , a control unit 17, a playback device 18, an input and output control unit 19, a display unit 21 and an external storage medium determining unit 24. The data processing apparatus 3 is used in the same music distribution system as the data processing apparatus in accordance with the first and second embodiments. The data processing apparatus 3 is characterized by converting the distributed music data into an internal format based on the type of specific storage medium. Components in the third embodiment, similar to components in the second embodiment, are provided with the same digital references, and a description thereof is omitted here.

In the device 3 for processing data, the user sets the type of external storage medium 7 by means of the input unit 10. The user can specify not only the type of external storage medium that is connected at that moment, but also the type of external storage medium that will be connected later. When the user sets the type of external storage medium, the display unit 21 lights up an indication as shown in FIG. 16. According to this indication, any of the RAMs on a digital video disc (DVD) and memory cards can be set as an external storage medium. The screen shows that at this moment the memory card is being set. Through this screen, the user can specify the type of external storage medium on which the music data is debugged.

As again shown in FIG. 15, upon receipt of a command 30 to define an external storage medium 7 by means of an input unit 10, the external storage medium determination unit 24 stores in memory a type of a predetermined external storage medium. The external storage medium determination unit 24 then provides a determining signal 36 indicating the type of the external storage medium stored in the memory to the data conversion unit 22.

Similarly to the second embodiment, the data conversion unit 22 operates in accordance with the flowchart shown in FIG. Based on the determining signal 36, the data conversion unit 22 converts the music data stored in the distributed data memory unit 11 into an internal format set for each predetermined type of external storage medium. The block diagram shown in FIG. 17 is similar to the block diagram shown in FIG. 10, and therefore, a description thereof is omitted here.

Next, the operation of the data processing apparatus 3 according to the present embodiment will be described. The musical data in the internal format in the device 3 for processing data includes only content that can be debugged on a given external storage medium. Therefore, as for the second embodiment, the number of data stored in the memory can be reduced.

In addition, the user can also specify the type of external storage medium that will be connected later. Therefore, it is possible to transform the music data in such a way that it matches such an external storage medium. Thus, when the user sets the appropriate debugging addressing, the amount of data input into the memory can be further reduced.

It should be noted that the data processing devices in accordance with the first and up to the third inclusive embodiments may be implemented by a combination of a computer and a program for that computer. The data processing apparatus of the present invention can be implemented by recording a program on a recording medium, typically a floppy disk, and installing the program in an arbitrary computer system.

(Fourth Embodiment)

As a fourth embodiment, as a specific example of the copyright data mentioned in the first to third embodiments, inclusively, a format for distributing contents called a DSCF (Protected Digital Audio Format) is described below. With reference to

Figs. 18-39 first describe the details of a SCZF and then referring to Figs. 40-45 describe how to use a SCZF.

A content distribution format (DLC) in accordance with the present embodiment is used to describe multimedia contents that include data such as audio, images, video, text and files. The multimedia contents described by WZZF are hereinafter referred to as the ZZZF title. Each reproduction data containing an SCZF title is here referred to as a content item (hereinafter abbreviated ELS). Each ELS is assigned an ELS identifier, which is unique in the WZZF title (hereinafter abbreviated ELS ID).

ZZZF title is distributed divided into units called ZZZF packages. Each ZZZF package is assigned a package identifier, which is unique in the entire distribution system. Fig. 18 is a diagram illustrating an example of an SCZF packet. As shown in FIG. 18, the ZZZF title 2000 consists of a large number of ZZZF packets. Each 2001 package consists of a 2011 heading, 2012 navigation data, a large number of ELS 2013, and a 2014 offer.

The header 2011 contains information such as the location, size, and identifying attribute of each data in the packet. Such information determines the structure of the package. The navigation data 2012 is information for controlling playback defining the operation of the player when playing a DZZF title. Based on the navigation data 2012, they refer to the ELS contained in the package to which the navigation data belongs, or in other packages. ELS 2013 is obtained by encrypting each reproduction data constituting the SCZF header, and more specifically by encrypting data such as audio, images, video, text or files. Two keys for decrypting ELS 2013 and ELS ID are called a key pair. Proposal 2014 contains a large number of key pairs and purchase rules that describe the purchase price and the available time period for each key pair.

19a-19c are diagrams showing three types of SCLC packets. The complete package 2001 shown in FIG. 19c contains, as in FIG. 18, a heading 2011, navigation data 2012, a large number of ELS 2013 and a sentence 2014. The proposal package 2002 shown in FIG. 19a contains a heading 2011, navigation data 2012 and the sentence 2014, but does not contain any ELS 2013. The ELS package 2003 shown in FIG. 19b contains the heading 2011 and a large number of ELS 2013. Since the 2012 navigation data is required to play the NWTC title, the full package 2001 and the package offer 2002 can only be played, but the ELS 2003 package cannot.

ELS package is used to separate the ZZZF title in accordance with the distribution channel. For example, when distributing using ROM on CD, ZZZF title is recorded as a complete package in ROM on CD. On the other hand, in the case of distribution through the Internet of the ZZZF, the title is divided into one full package and a large number of ELS packages for distribution. For example, the ZZZF title is divided into one complete packet containing audio ELS and a large number of ELS packets containing video ELS that are accessed from the complete packet for distribution.

In addition, as shown in FIG. 20, the ZZZF title can be divided into a large number of ZZZF packets by tracks. In batch separation, as shown in FIG. 20, the SCZF title 2020 containing audio data for five tracks is divided into three packets 2021-2023. Three packages 2021-2023 have respectively package names: Single 1, Single 2 and album. The first and second packets 2021 and 2022 both contain ELS audio for one track and navigation data for controlling ELS playback. The third packet 2023 contains audio ELS for three tracks and navigation data to control the playback of all audio ELS contained in three packets 2021-2023. At the same time, by dividing the ZZZF title into a large number of ZZZF packets, each data can be made smaller and easy to process.

The title, sentence, navigation data and ELS that make up the ZZZF package are described in the same order below.

First, heading 2011 is described. Here, the SCLC packet shown in FIG. 21 is taken as an example, and heading 2031 of the SCCP packet 2030 is described. In the SCPS packet 2030, it is believed that the size of the navigation data 2032 and the size of the proposal 2034 individually is 400N in hexadecimal notation. This package contains three ELS 2033, and their types are, starting with the first, audio, image and file. It is believed here that the sizes of these ELSs, starting from the first, are 400000N, 18000N and 8000N in hexadecimal notation.

FIG. 22 is a diagram showing a structure of a header 2031. In a header 2031, data, as described below, is sequentially stored in a memory, and the header size is DTC in a hexadecimal notation.

It should be noted that the structure of the header 2031 can be described in C ++, as shown in FIGS. 23 and 24. FIGS. 23 and 24 are a diagram showing a sequential source code divided into two, and before the separation, the source code 2062 shown in FIG. .24 follows the source code 2061 shown in FIG.

At the beginning of header 2031, system code 2041 (4 bytes) is entered into memory, indicating that the file is in the format of the SCZF. The value of the system code 2041 is a string of characters "ZZZF". Then, the version number 2042 (4 bytes) of the SCZF is entered into the memory. After that, the ID 2043 packet (16 bytes) and the packet size 2044 (4 bytes) are entered into memory. Then, the information 2045 about the location of the navigation data (ZZZF POSITION NAV in Fig. 23), the information 2046 about the location of the offer (ZZZF Location of the Offer in Fig. 23) and the number of ELS in the packet 2047 are then entered into the memory. Then, the information 2048 (ZZZF is stored in the memory) The location of the ELS in Fig.24) for each ELS. And finally, entered into the memory table 2049 of the defining signs of ELS, indicating the definitive sign of each ELS.

Information 2045 about the location of the navigation data indicates the location and size of the navigation data 2032. Information 2046 about the location of the offer indicates the location and size of the offer 2034. These two types of information consist of both the offset (4 bytes) from the beginning of the DZZF packet and each size (4 bytes) .

ELS information 2048 consists of an ELS identifier (ID) 2051 (16 bytes), an ELS type 2052 (2 bytes), an ELS encryption type 2053 (2 bytes), information about the location of the ELS data 2054, and information 2055 about the location of the ELV definition table. ELS ID 2051 is the identifier of the content element, which is unique in the ZZZF title. The ELS 2052 type accepts any value of audio, images, video, text and files. ELS encryption type 2053 indicates the algorithm used to encrypt ELS. Information 2054 about the location of the ELS data and information 2055 about the location of the table of defining signs of ELS consist both of the offset (4 bytes) from the beginning of the SCZF packet and each of their size (4 bytes). If the offset or size is 0, then this means that no data exists.

The defining characteristic table 2049 is a list of defining characteristics defined for each type of ELS. The table of the defining features of the audio ELS (SZZF EDIT AUDIO on Fig) contains at least a codec, the number of quantized bits, the sampling frequency and the number of audio channels. The table of defining signs of ELS images (ZZZF IDENTIFICATION SCHEDULE in Fig.24) contains at least the height and width of the image and the type of encryption. The table of defining features of an ELS video contains at least the height and width of the video and the type of encryption. The table of defining features of a text contains at least a type of text encryption, such as Unicode or JIS (Japanese Industrial Standards) musical bias. The table of defining characteristics of an ELS file contains at least the MIME type (Multipurpose Internet Mail Extensions).

An ELS defining feature table 2049 is defined not as a fixed-length table, but with a variable-length label structure, as shown in FIGS. 25a-25c. If a tag structure is used, then the tag length and tag ID are stored in memory before the data, as shown in FIG. 25a. For example, the table of defining signs of ELS images consists of a characteristic label 2063 and a label such as encryption 2064. Elements of the table are specified by using the label structure, thereby a new table element can be added to the data format or the data format can only be changed by adding a label. A table of defining signs of ELS is defined by using a label structure that has great potential for expansion.

Then, proposal 2014 is described. As described above, the proposal contains a large number of key pairs and purchasing rules for each key pair. Each key pair consists of a key to decrypt the ELS and ELS ID. 26 is a diagram showing a correspondence between a key pair and an ELS. As shown in FIG. 26, a key pair 2072 consists of a decryption key 2073 and an ELS ID 2074, and each key pair 2072 is associated with each ELS 2071. The proposal contains not only the key ELS pair entered in the WZZF packet, but also all the key ELS pairs Packages of the same ZZZF title introduced into WZZF. In other words, when one ZZZF title is divided into a large number of ZZZF packages, only one ZZZF package contains a sentence, and this proposal contains all the key ELS pairs contained in the ZZZF title.

The procurement rules are described using a language to describe the terms of use of a key pair, called the law of control language. The terms of use of the key pair contain the date of purchase, the period of use and whether or not a special ELS or ZZZF title was purchased. The procurement rules are determined by these purchasing conditions and due to this the same ELS can be sold at different prices depending on these conditions.

Then, the navigation data 2012 is described. The navigation data is created by the content creator so that the user can use the ELS most effectively by defining the logical structure of the WTFZ title.

In WZZF, an extensible markup language (XML), which is a language for writing off labels in a text format, is used to describe navigation data. When the data structure is described in XML, the label structure in text format is used. Therefore, the data described in XML is redundant in comparison with binary data. However, XML has been adopted because of its excellent extensibility.

To refer to the ELS from the navigation data, the ELS locator is used. The ELS locator is the connection of the packet ID and the ELS ID for which the limiter is "?" (question mark). However, for the ELS contained in the ZZZF packet, which contains navigation data, the packet identifier and limiter are excluded, and the ELS ID becomes the ELS locator. The ELS locator can determine the ELS regardless of the physical address of the ELS.

FIG. 28 is a diagram showing how to access an ELS from navigation data using an ELS locator. 28, navigation data and data for playback 2082 are shown as an example. Conditions for playback 2082 contain audio ELS 2083, encoded according to the MPEG2-AAC standard, and ELS images 2084, encoded according to the JPEG standard. Package ID and ELS Audio ID ELS 2083 are both equal to 1, and ELS images 2084 are respectively 1 and 2. In this case, the ELS locator "1? 1" contained in the navigation data 2081 indicates the audio ELS 2083 with its packet ID "1 "and on ELS ID with" 1 ". The locator ELS "1? 2" indicates the ELS images 2084 with its package ID "1" and ELS ID "2". As is known from this example, only a change in the ID of the ELS locator package after creating the ZZZF title can cause a change in the structure of the ZZZF package. Therefore, you can structure the WZZF title as one package or structure the WZZF title into a large number of ZZZF packages.

29 and 30 are diagrams showing a navigation data structure based on the following presentation manner. Each rectangle represents a navigation data item. An arrow going from element A to element B indicates that element A contains element B as an inheriting element. Each character at the beginning of each arrow indicates the following: * indicates that the element contains O or more inheriting elements; + indicates that an element contains 1 or more inheriting elements; and the question (?) indicates that the element contains 0 or 1 inheriting element. If element A contains part P without any arrow, then this means that element A has part P as a defining feature.

The underlined parts are ELS locators. RSDATA is a chain of characters consisting of characters contained in a given set of characters. This view defines a hierarchical structure with the title element as the root.

Title element 2101 describes the delivery information of the WCPF title. This element has three defining attributes:

UPC, Version and Language. The defining feature of UPC describes UPC (Universal Product Code), which is the international standard for product codes. The defining characteristic Version describes the version number of the navigation structure of the ZZZF. Defining attribute Language describes the type of language in accordance with the international standard ISO 639. Its default value is "en", indicating English.

The METADATE 2102 element describes information such as the genre of the PLAYLIST or TRACK element. The METADATE element has the defining attribute TYPE. The defining characteristic TYPE describes the type of the METADATE element. The ASSOC element 2103 describes information related to the ELS contained in other ZZZF titles. This element has the defining attribute REF. The defining sign of REF describes an ELS locator.

The URL element 2104 describes a Uniform Resource Locator (URL). This element has two defining attributes: ID and TYPE. ID defining attribute describes the identification number of this element. The defining characteristic TYPE describes the type of URL element.

PLAYLIST element 2105 describes the playlist, which is the basic component for the NZZF title. The list of reproductions corresponds to the album in ordinary packaged media and is contained in all ZZZF titles. A PLAYLIST item may contain a MENU item, which is a menu for a playlist. The PLAYLIST element has five defining attributes: NAME, ARTIST, PRODUCTID, MINICOPY ID and ONSTART. The defining attribute NAME describes the name of the playlist. PRODUCTID is the defining characteristic determines the information corresponding to the catalog code in the CD. The defining feature of the MINICOPY ID is an ELS ELS image locator, which is common in the playlist. ONSTART defining feature describes an operation for playing a playlist. If the ONSTART defining attribute is “MENU”, the player stops playback and displays the playlist menu. If "TREK", then the player starts playing the first TREK element contained in the PLAYLIST element. All PLAYLIST elements have at least one TRACK element 2106.

TREC element 2106 describes a track containing one audio ELS. A TRACK element may contain a menu of tracks, slide view, text, file, and more. The TREC element has seven defining attributes: ID, NAME, ARTIST, ISRC, AUDIOID, IDKVP and MINICOPY ID. ID defining attribute describes an identification number, which is unique in ZZZF header. The defining attribute NAME describes the name of the TRACK element. The defining attribute ARTIST describes the name of the artist. The ISRC defining attribute describes an International Standard Recording Code (ISRC). A defining feature AUDIOID describes an ELS ELS audio locator associated with a TREC element. The defining feature of IDCWP describes the ELS locator of the time search card corresponding to the ELS audio. A time search map will be described later. The defining feature of the MINICOPY ID describes the ELS ELS image locator, which is typical for a TREC element.

The MARKER 2107 element describes a marker for use in locating a beginning in a TREC element. This element has two defining attributes: TIME and NAME. The defining attribute TIME describes the location of the marker in milliseconds. The defining attribute NAME describes the name of the marker.

The SYNCHLIDE VIEW element 2108 describes a slide view for displaying slides or a menu after displaying the temporary information specified by the SYNMEP element 2109. The SYNCHLIDE VIEW element 2108 has three defining attributes: ID, NAME, and TYPE. ID defining attribute describes an identification number, which is unique in ZZZF title. The defining attribute NAME describes the name of the slide view. The defining characteristic TYPE describes a category of information in a track, such as credits, lyrics, sheet music, biographies, image collections or advertising.

The SYNCMEP element 2109 describes the display time information for a slide or menu specified in the SYNCHLIP VIEW element. SYNCMEP element 2109 has three defining attributes: MENOID, PLAYID, and TIME. The hallmark MENOID describes the identification number of the slide or menu that will be displayed. The defining attribute PLAYID describes the serial number for determining the button that is set to the playback state on the menu. The defining characteristic TIME describes the countdown of the display time in milliseconds.

The SLIDE VIEW element 2110 describes a slide view for displaying slides or menus at specific display intervals. This element has four defining attributes: ID, NAME, TYPE and INTERVAL. The defining attribute of the ID describes the identification number, which is unique in the title of ZZZF. The defining attribute NAME describes the name of the slide view. The defining characteristic TYPE describes a category of information in a track, such as credits, lyrics, notes, biographies, a collection of images, or an advertisement. The defining attribute INTERVAL describes the interval in which a slide or menu is displayed.

SYNTEXT element 2111 describes text information that is displayed at predetermined time intervals. Text information is described by using the SYNTEXTBLOCK element 2112. Or, text information can be specified by reference to a portion of the text ELS. The SYNTEXT element has four defining attributes: ID, TEXTID, REFID, and TYPE. The defining attribute of the ID describes the identification number, which is unique in the title of ZZZF. The defining feature TEXTID describes an ELS text ELS locator. The defining attribute REFID describes the identification number of the TEXTREF element in the text ELS specified by the defining attribute TEXTID. The TEXTREF element will be described later. The defining characteristic TYPE describes a category of information in a track, such as credits, lyrics, notes, biographies, a collection of images, or an advertisement.

SYNTEXTBLOCK element 2112 describes text information that is displayed at predetermined time intervals. This element has the defining attribute TIME. The defining characteristic TIME describes the specified display time in milliseconds.

Text element 2113 describes text information. Text information is described in text data format. Or, textual information can be specified by reference to a portion of textual ELS. The TEXT element has the same types of defining features as the SYNTEXT element.

The VIDEO 2114 element describes any existing ELS video. This element has three defining attributes: ID, VIDEOID and TYPE. The defining attribute of the ID describes the identification number, which is unique in the title of ZZZF. The defining feature VIDEOID describes an ELS ELS video locator. The defining characteristic TYPE describes a category of information in a track, such as credits, lyrics, notes, biographies, a collection of images, or an advertisement.

FILE 2115 describes any existing file ELS. This element has three defining attributes: ID, FILE, and TYPE. The defining attribute of the ID describes the identification number, which is unique in the WZZF header. The defining attribute FILE describes an ELS file ELS locator. The defining characteristic TYPE describes a category of information such as credits, lyrics, sheet music, biographies, a collection of images or advertising.

The element SLIDE 2116 describes the slide. This element has three defining attributes: ID, NAME and FONID. The defining attribute of the ID describes the identification number, which is unique in the WZZF header. The defining attribute NAME defines the name of the slide. The defining characteristic PHONID describes an ELS ELS locator of images on a slide screen.

Menu item 2117 describes the menu. A menu has one or more on-screen buttons. The MENU element has four defining attributes: ID, NAME, FONID and CHOICE. The defining attribute of the ID describes the identification number, which is unique in the title of ZZZF. The defining characteristic NAME describes the name of the menu. The defining characteristic PHONID describes the ELS locator ELS images displayed on the menu screen. The defining flag CHOICE describes the serial number for determining the button to be installed in the selected state.

BUTTON 2118 describes the on-screen buttons located on the menu screen. The BUTTON element contains, as hereditary elements, one or more pairs of TEKSTKNOPKA and TEAM elements or pairs of GRAPHICCOPE and TEAM elements. The BUTTON element has seven defining attributes: INDEX, TEB, UP, DOWN, RIGHT, LEFT, and AUTO. The defining attribute INDEX describes a serial number that is unique in the MENU element. The defining sign of the fuel and energy complex describes the serial number sequentially and repeatedly provided by each of the buttons on the menu. The defining signs UP, DOWN, LEFT, RIGHT describe the serial number of the destination button located respectively at the top, bottom, left and right of the involved button. The defining attribute AUTO ACTION describes a pointer indicating whether the state changes automatically from the selected to the active.

TEXT BUTTON 2119 describes an on-screen button represented by text. This element has eleven defining attributes: X, Y, WIDTH, HEIGHT, FONT SIZE, NORMAL COLOR, SELECT COLOR, ACTION COLOR, PLAYBACK, TEXTIDE and REFID. Each of the defining signs X, Y, WIDTH and HEIGHT describes the displayed button location using the coordinate system with its beginning in the upper left corner of the menu. The FONT SIZE element describes the font size in points. The defining features NORMAL COLOR, SELECT COLOR, ACTION COLOR and PLAYBACK describe the display color in RGB format when the button position is normal, selected, effective and reproducing accordingly. The defining feature TEXTID describes an ELS locator of an external text ELS. REFID defining attribute describes the identification number TEXTREF of the element in the text ELS specified by TEXTID.

GRAPHIC BUTTON 2120 describes an on-screen button presented as a graphic. This element has eight defining attributes: X, Y, WIDTH, HEIGHT, NORMALID, SELECT, ACTION, and REPRODUCE. Each of the defining signs X, Y, WIDTH and HEIGHT describes the displayed button location using the coordinate system with its beginning in the upper left corner of the menu. Each of the defining features NORMALID, SELECTION, ACTION and REPRODUCE describes the ELS locator of the displayed ELS images when the button position is respectively normal, selected, effective and reproducing.

The TEAM 2121 element describes a navigation operation when a user clicks on one of the on-screen buttons. This element has two defining attributes: TYPE and GOAL. The defining characteristic TYPE describes any one of the commands: VIEW, FUNCTIONING, TRANSITION, NEXT and PREVIOUS. The VIEW command is used to display the element specified by the defining sign PURPOSE. The FUNCTIONING command is used to execute the element specified by the defining attribute PURPOSE. This command is used when the playlist menu is displayed. The TRANSIT command is used to move from the element currently displayed to the specified similar element. The PREVIOUS item is used to move from the item currently displayed to the previous similar item. The defining attribute GOAL describes the command parameter defined by the defining attribute of the TYPE. If the VIEW command is specified, the defining characteristic GOAL describes the identification number of the displayed item. If the FUNCTIONING command is given, the defining characteristic PURPOSE describes the identification number of the element being executed. If the TRANSIT command is given, the defining target PURPOSE describes the identification number of a similar element with respect to the currently displayed element.

The TEXTREF element describes a category of text information used when referring from navigation data to a part of text data stored in a text ELS. The text data contained in the TEXTREF element is referenced by setting the identification number of the TEXTREF element from the navigation data. The defining attribute TEXTREF has the defining attribute ID. The defining attribute of the ID describes the identification number, which is unique in the title of ZZZF.

Then, ELS 2013 is described. ELS is of five types: audio, image, video, text and file. In ZZZF data format and parameter are set for each type of ELS.

The data contained in the audio ELS is audio data encoded in accordance with the international standard MPEG2-AAC (advanced audio coding) [low complexity profile]. It should be noted that MPEG2-AAC is defined in MOC / IEC 13818-7: 1997 (E) Information technology - Group coding of moving images and associated audio information - Part 7 Advanced audio coding (AAC). The bitstream encoded by MPEG2-AAC is believed to be in the ADTS (audio transport stream) format. In addition, the parameters described in MOC / IEC 13818-7 are limited, as shown in FIG. Of these parameters, the parameters, in addition to the indicator of the gating frequency and the channel configuration, are limited due to the choice of the low complexity profile specified by MOS / IEC 13818-7. In addition, the average bit rate is 64 or 128 kbps.

The data contained in the ELS images are image data encoded in accordance with JPEG, MPEG -1 frame or PNG (portable network graphics). 32, 33 and 34 are tables respectively showing specifications of JPEG, MPEG-1 frame, and PNG. The specifications for encryption algorithms applicable to ELS images are limited, as shown in these figures.

The data contained in the ELS video is video data encoded in accordance with MPEG2. Fig. 35 is a table showing the MPEG2 specification. The specification for the encryption algorithm applicable to ELS video is limited, as shown in FIG. 35.

The data contained in a text ELS is unencrypted text or XML text in WZZF. The encryption type is Unicode standard or Japanese standard JIS music bias.

As an example of an ELS file, an ELS of a time search map that contains a time search map as data is now described. A temporary search card is a table consisting of the address of an audio frame. 36 is a diagram showing the structure of a time search map. As shown in FIG. 36, the time search map 2090 consists of a header 2091 and a large number of items 2092. FIGS. 37, 38a and 38b are table and diagrams showing in detail a header 2091. As shown in FIGS. 37, 38a and 38b, a header 2091 contains the duration of playback between points, expressed in milliseconds, and the total number of points. Fig. 39 is a table showing each item in detail. As shown in FIG. 39, each item contains the address of the audio frame at its input point. The first paragraph indicates the initial location of the audio frame contained in the audio ELS.

It should be noted that in the present embodiment, MPEG2-AAC is used to compress the music data contained in the ELS audio. Or, they can be used MP3 (audio level 3 MPEG1), Dolby - ACS or DTS technique (digital theater system).

Then, with reference to FIGS. 40-45, how to use the SCZF is described. As described above, DZZF is a format for describing multimedia content, and it is mainly used for the distribution of music data. ZZZF can be applied to various types of recording medium: usually hard disks, optical disks, such as RAM on a digital video disc, and semiconductor memory, such as memory cards.

In addition to distributing music data, the WZZF can be used in combination with existing music data. For example, as mentioned below, the ZZZF can be used in combination with music data that complies with the CVP - Audio standards. Similarly, the ZZZF may be applicable to other recording media, for example CVP, CD, video CD and photo CD.

The music data conforming to the CVP-Audio standards contains LIKM (linear pulse code modulation) audio content and MPEGI frame content of images. A player that complies with the CVP-Audio standards displays a menu on the screen for user interaction. In the CDC-Audio standards, such a menu is displayed on the screen when one of the maximum four-color sub-video images is superimposed on the background image to display and provide a large number of rectangular areas in the sub-video images. Such rectangular areas are called buttons, and each button is given a command. However, some restrictions apply to the number of colors displayed and to the shape of the / button, and therefore the content creator cannot freely create menus on the screen.

This problem can be solved by the previous recording of the menu data on the screen described in the SCWF, on a conventional DVD-ROM audio disc, and displaying this menu on the screen using this data during playback. More specifically, a multimedia content is recorded on the CVD audio disc described in the DZZF and in the ELS redirector for sending from the DZZF to the original contents on the DVD-ROM. Further, the CVD audio disc with such data recorded thereon will be referred to as the extended CVD audio disc, and the player for reproducing the expanded CVD audio disc will be referred to as the CVD audio player corresponding to the WZZF.

FIG. 40 is a diagram showing an example of ELS forwarders that correspond to one DAC audio disc. Each row indicates an ELS redirector for each content entered in the original DVD-audio CD. ELS forwarder contains ELS ID 2201, file name 2202, source address 2203 and end address 2204. ELS ID 2201 is an identifier for content that is unique in the disk. The file name 2202 is the name of the file that contains each content. The source and destination addresses 2203 and 2204 are offset values showing, respectively, the source location and the final location of each content in the file. ELS redirector is written to a file called, for example, DVDA. MAP in the WZZF directory provided in the ROM area of the extended DVD-audio CD.

All of the various playback control functions, such as controlling the audio playback order, playing back images for a slideshow, and the menu function defined by the CVP-Audio standards, can be described using the navigation data of the ZZZF. For example, a menu function can be implemented by overlaying JPEG button images with any number of colors and shapes onto an MPEG - I frame background image to display and associate each button area with a command.

When the information for controlling playback contained in the DVD-ROM audio disc is converted into navigation data of the SCWF, information indicating the contents is converted into an ELS ID using an ELS forwarder. The menu on the screen is converted to JPEG button images. The resulting images are arranged so that they can be superimposed on the background image. The navigation data and button images obtained in the manner described above are stored in one WZZF package and recorded in a file called the WZZF. ZTsP, for example, in ZTsZF the directory provided in ROM area of the expanded TsVD-audio disk. Below will be described a method of playing an expanded DVD-audio CD.

Then, the SCZF player for reproducing multimedia contents described in the SCZF is described below. The SCZF player reproduces the distributed music data as follows. First, the player searches for packet IDs and navigation information to collect the ELS ID ELS required for playback. The player searches the purchasing database using the sets of collected batch IDs and ELS IDs to determine if the ELS was purchased or not. If any ELS that has not yet been purchased is found, the player analyzes the encoded offer and pays the assigned price through the existing electronic distribution system. After the purchase, the key pair stored in the proposal is entered into the memory of the procurement database. If it is determined that the SCC packet required for playback was not found in the player, then the player transmits the packet ID to the data distribution device. A device for distributing data distributes the SCZF packet with the received packet ID to the player. After purchasing all the ELS required for playback, the player decrypts the ELS using the key pairs stored in the procurement database for playback. At this time, the player interprets the navigation data to control playback.

ZZZF title is distributed to the player, being divided into one or more ZZZF packets. Figa-41C are diagrams showing examples of how to distribute DZZF packets. In the distribution method, as shown in Fig. 41a, the packet 2301 contains only audio content, and the packet 2302 contains only image content or video content. In addition, a reference is made from the packet 2302 to the audio content contained in the packet 2301. Therefore, a user who has purchased only the packet 2301 can only reproduce the audio content. The user who purchased the package 2302, in addition to the package 2301, can reproduce the graphic content along with the audio content. The name of the SCZF itself can be determined by adding an ELS to an existing track.

In the distribution method, as shown in FIG. 4b, packet 2303 contains a large number of audio contents and graphic contents. By itself, one package may include all ELS contained in the WZZF header.

In the distribution method, as shown in FIG. 41c, one SCZF title is divided into packets 2304, 2305 and 2306 for distribution. Package 2305 includes content for track # 1, and package 2306 includes content for track # 2. In this distribution method, one of the packages 2305 and 2306 for distribution can be selected.

In addition, a new ZCZF package owned by the user can be created in the player. Figa-42C are diagrams showing examples of how to create DZZF packets. In Figures 42a-42c, the user packet is a SCZF packet created by the user, and the purchased packet is a distributed ZZZF packet. Content surrounded by a thick line belongs to the user. Here it is assumed that the user owns the data read from the CD, i.e. audio content extracted from the CD and graphic content created by him / her.

As shown in FIG. 42a, a user can create a package 2401 including audio content belonging to him / her. Furthermore, as shown in FIG. 42b, a user can create a package 2402 including audio and graphic content belonging to him / her. In addition, as shown in Fig. 42c, the user can create a package 2404 that references the audio content entered in the purchased package 2403. If the package 2404 is reproduced, then the audio content entered in the purchased package and the graphic content are reproduced. owned by the user. Therefore, the image contained in the purchased package can be replaced with an image created by the user, or a new image created by the user can be added to the purchased package.

Then, a DAC audio player corresponding to the SCZF is described for reproducing an expanded DAC audio disc. The player controls the playback operation, following the navigation data described by the SCZF, instead of the source information for controlling playback corresponding to the DAC Audio Standards. The player reads the navigation data and the ELS locator from the advanced DVD-audio CD and works according to the read navigation data. If the initial audio or image content is indicated in the navigation data, the player contacts the ELS locator to obtain information about the location where the content is stored, and reproduces the content. The player reads the background image from the DAC audio area on the disk and the button images from the DZZF data and combines them to display the menu on the screen.

Thus, when using the extended DAC audio CD, the existing DAC audio player can perform normal playback, and the DAC audio player corresponding to the DZZF can display the menu on the screen using navigation data by the DZZF.

In the above description, the SCZF packet and the ELS redirector are stored in the disk. Or, such data can be downloaded via the network to the player. This method can be applied to CD and DVD drives that have already been sold to the user. In addition, using the HRM (Unified Resource Locator), using this method, you can access the ELS, which are available through the communication network.

Then, a device for converting data for copying multimedia contents specified in the SCWF to an external storage medium for portable music players is described. Here, a portable music player is designed using semiconductor memory as an external storage medium, and it is characterized by small dimensions and mass and the ability to record data on it with high speed. The portable music player comprises, as shown in FIG. 43, a liquid crystal display 2501 capable of displaying text, a control panel 2502 for controlling audio playback, and headphones 2503 for outputting sound. In addition, a removable memory card 2500 for storing audio data may be attached to the portable music player. The portable music player plays back MPEG2-AAC compliant music content and also displays text information. However, the format for recording data on the memory card is not a ZZZF, but a special format.

Fig. 44 is a block diagram showing a structure of a data conversion apparatus for converting contents recorded on an expanded DVD-ROM in a specific format, and recording the converted contents on a memory card for a portable music player. On Fig, it is assumed that on the disk 2601 recorded audio content LIKM format, the content of the images in MPEG-I frame format, information for playback control, described by DZZF format, and additional text information.

In the data conversion apparatus shown in FIG. 44, a playback control information reading unit 2602 reads information for managing playback from a disc 2601 and feeds it to an information analysis unit 2603 for managing playback. A playback control information analysis unit 2603 analyzes the read information for playback control to determine whether content recorded on the disc 2601 can be played back or if it needs to be converted.

Then, the data reading unit 2602 sequentially reads from the disc 2601 contents that can be played by the portable music player, and supplies the read contents to the data converting unit 2605. At this time, contents that cannot be played by the portable music player are not read. Block 2605 data conversion converts the read contents in accordance with the type of the card 2500 memory. For example, text information that can be directly played back by a portable music player, such as titles, is not converted. On the other hand, audio content in LIKM format is converted to MPEG2-AAC format so that the portable music player can play the content.

The playback control information conversion unit 2604 generates playback control information for the portable music player based on the playback control information analyzed by the playback control information analysis unit 2603. The data recording unit 2606 records information for reproducing control generated by the information converting unit 2604 for reproduction management and contents converted by the data converting unit 2605 on the memory board 2500.

It should be noted that the data conversion unit shown in FIG. 44 can convert arbitrary data other than audio contents into a predetermined format and record the converted contents on the memory board 2500. In addition, the data recording format of the memory card may be an arbitrary format different from the SCZF. In addition, to provide a large number of external storage media, the data conversion device may include a data conversion unit, an information conversion unit for controlling reproduction, and a data recording unit for each external storage medium.

In addition, if no navigation data is recorded, from the WZZF on the disk 2601, as shown in Fig. 45, the missing data can be obtained through the communication network. On Fig, it is assumed that the identification number is recorded on the disk 2601. For example, the identification number of the musical CD is a directory code, a code MCH and others.

Block 2602 data reader reads the identification number of the disk and feeds it to block 2607 communication. The communication unit 2607 establishes communication with the server 2611 via the communication network 2610. The communication unit 2607 may have access to the content server 2611 via the Internet or may have direct access to the content server 2611 via the telephone network. The content information server 2611 stores in its memory the missing data related to the identification number, and in response to a request from the data conversion device, transmits the missing data to the data conversion device. After receiving the missing data, the data conversion device performs the same operation as the data conversion device shown in FIG.

As described above, the format for distributing the contents of the WCH in accordance with the present embodiment is a format for describing multimedia contents, and it is mainly used for distributing music data. Also, the use of WZZF in combination with existing music data can expand the function of existing music data.

It should be noted that, as is known from a comparison of FIGS. 3 and 18, the relationship between the music data described in the first and up to the third embodiment, inclusive, and the SCZF in accordance with the present embodiment is as follows. Those. the header 40 shown in FIG. 3 corresponds to the header 2011 shown in FIG. 18. The navigation information 41 shown in FIG. 3 corresponds to the navigation data 2012 shown in FIG. 18. The content 42 shown in FIG. 3 corresponds to the ELS 2013 shown in FIG. 18. The payment calculation information 43 shown in FIG. 3 corresponds to the proposal 2014 shown in FIG. 18.

Although the invention has been described in detail, the foregoing description in all its aspects is illustrative and not restrictive. It should be noted that numerous other modifications and variations can be made without departing from the scope of the invention.

Industrial application

As described above, the copyright data processing apparatus in accordance with the present invention converts the copyright data into internal format data without information for calculating payment for storage thereof. Therefore, various processes can be carried out thanks to a single data processing procedure for copyright management, regardless of how payment is calculated.

Claims (10)

1. A device (1, 2, 3) for data processing, implementing a method of processing data with copyright within the granted rights, including means (11) of distributed data memory configured to receive and store data in a distributed format, including at least substantial data (42) for protecting information (43) and information for calculating payment defining payment conditions for said substantial data (42), means (12, 13) for storing and processing information on procurement rights the possibility of processing information (43) for calculating payment and for acquiring the right under the terms (52) of the purchase required to process the said substantial data (42), means (16) for storing information about the right, made with the possibility of storing the said right on the terms (52) ) purchases acquired by the said means (12, 13); purchase of rights; means (14, 22) for converting data made with the possibility of converting distributed format data, including meaningful data (42), into internal form data that without said information (43) for calculating payment, when the said right under the conditions of purchase (52) was acquired for said substantial data (42), a means (15) for storing data made with the possibility of storing said internal format data obtained by means of ( 14, 22) data conversion, and means (17, 18, 19) for implementing a processing method configured to implement a method for processing internal format data stored in said means (15) for storing data within the limits mentioned The new purchase condition (52) stored in the said means (16) for storing information about the right. 2. The device according to claim 1, characterized in that said substantial data (42) is encrypted, said information (43) for calculating payment contains a decryption key (54) for decryption of said encrypted substantial data (42), said means (14, 22 ) for data conversion, it is possible to extract said decryption key (54) from said information (43) for calculating payment, said means (16) for storing information about the right stores said extracted decryption key (54), said means (17, 18, 19) to implement the processing method, it is possible to decrypt the encrypted said substantial data (42) using said decryption key (54) stored in said means (16) for storing information about the right. 3. The device according to claim 1, characterized in that said data in a distributed format include said substantial data (42), separating said information (43) for calculating payment, header (40) and information (41) for controlling the implementation of the processing method the mentioned substantial data (42). 4. The device according to claim 1, characterized in that said internal format data is equivalent to data obtained by separating said information (43) for calculating payment from said distribution format data. 5. The device according to claim 1, characterized in that said means (17, 18, 19) for implementing the processing method includes means (19) for copying data, configured to copy the said data in an internal format stored in said means ( 15) storing data on a removable storage medium (7), and said means (22) for converting data is configured to convert said distributed format data into said internal format data based on the type of said stored s medium (7). 6. The device according to claim 5, characterized in that it also includes means (23) for detecting a storage medium, configured to detect type (35) of a storage medium (7), said means (22) for converting data made with the possibility of converting said distributed format data into said internal format data based on the type (35) of said storage medium (7) detected by said storage medium detection means (23). 7. The device according to claim 5, characterized in that it also includes means (24) for determining a storage medium, configured to determine the type (36) of said storage medium (7), said means (22) for converting data with the possibility of converting said distribution format data into internal format data based on the type (36) of said storage medium (7) defined by said means (24) for determining the storage medium. 8. The device according to claim 5, characterized in that said distribution format data contains at least one part of said content data (42), and said internal format data, including only content data for copying onto said storage medium (7) at least between one part of said content data (42). 9. A method of processing data for processing data with copyright within the granted right, according to which data of a distribution format including at least substantial data for protection and information for calculating payment defining payment conditions for said informative data is received, purchase rights when purchasing processing on the basis of the information mentioned for calculating payment and acquiring the right to the processing method required to process the mentioned informative data s, remember information about the right while retaining the said right to the processing method acquired during the purchase of the right, convert the data when converting the distribution format data, including the meaningful data, into internal format data without information for calculating payment, when the right to the processing method is acquired for said substantial data, data is stored during storage of said internal format data obtained by said data conversion, and processing is performed when the processing of said internal format data stored during data storage, within the limits of the right to a processing method stored when storing information about the right. 10. A recording medium with a program recorded thereon for implementing a method for processing data with copyright on a computer within the conferred right, said method comprising: receiving distribution format data including at least substantial data for protection and information for calculation payment, which determines the terms of payment for the meaningful data, they purchase the right when purchasing processing on the basis of the above information to calculate the payment and acquire the right to the processing method required for processing said substantial data, information about the right is stored while retaining said right to a processing method acquired upon purchase of a right, data is converted when converting distribution format data including meaningful data into internal format data without said information for calculating payment, when right for a processing method acquired for said substantial data, data is stored while storing said internal format data obtained with said data conversion, and carry out processing when implementing a method for processing said internal format data stored when storing data within said right to a processing method stored when said storing information about the right.

Images