MXPA06006121A - Method for storing, authenticalting and executing an application program - Google Patents

Abstract

Conventionally, when the version of a program has been upgraded, the whole of a currently stored program needs to be deleted to be replaced by a new program, and authentication needs to be performed again on such new program when it is activated. However, since the whole of the program is required to be stored and authenticated even when only a part of such program has changed, it consumes time and leads to the decrease in responsiveness. In order to solve this problem, the present invention extracts a difference between a new program and a currently stored old program, when such new program is to be stored, and the new program is to be stored after authentication is performed only on such difference.

Description

METHOD FOR STORING, AUTHENTICATING AND EXECUTING AN APPLICATION PROGRAM FIELD OF THE INVENTION The present invention relates to a method of storing program data files and a method of executing authenticated programs to store a downloaded program after verifying its credibility and executing the program that has been verified as credible. , and more particularly it refers to the updating and authentication of a program.

BACKGROUND OF THE INVENTION The function in a digital television of downloading a program and reviewing / guaranteeing the credibility of this program is described in the specification of the DVB-MHP ?? TSI TS 101 812 VI.2.1 DVB-MHP Specification 1.0.2", and others.

This specification of the DVB-MHP defines the function of verifying that a program superimposed on a transmission wave that is being received has not been altered as well as whether this program was issued or not by a reliable organization. This function makes it possible to avoid activating a rewritten program that does not operate as originally required and therefore could inflict damage to digital television and a third-party REF program. : 173024 supplanted. The function of updating a program is described in the OCAP specification (OCAP 1.0 Profile OC-SP-OCAP1.0-IF-I09-031121). According to this OCAP specification, when it is detected, in an XAIT program (table that describes about programs), a program update signal (the version of a program is updated whenever its descriptions have changed), all the Files of a program such as class file and data file currently stored in a secondary memory (for example, volatile ROM) are deleted and replaced by files of an updated program such as a class file and data file. Meanwhile, Japanese Patent Application Laid-Open No. 2000-259417 describes a technique for replacing an object that constitutes an environment of execution - by executing the following steps in response to a request from a performing entity or another object constituting the execution environment: a step of erasing an object constituting an execution environment and a step of obtaining a new object from an external system. When a program is updated, not all its files such as class files and data files are updated, but this program is only partially updated. However, according to the conventional technique, it is required that all the files of a stored program be deleted to be replaced by files of an updated program, even when the program has to be only partially updated. This is a problem with the conventional technique since the reactivity is reduced in proportion to the length of time required for storage. Moreover, in case of storing a program in a non-volatile memory once to thus activate this program after the device is turned on / off, the program authentication takes place immediately before it is activated. In this case, it is necessary to carry out calculations such as decryption of an encrypted value before the activation of the program starts, which causes a problem that the reactivity is further reduced since more time is required for calculations. Especially in case a program is activated frequently or when the capacity of a program is large, the reactivity is damaged more and more as the amount of calculations increases in proportion to the frequency and capacity of activation. In view of the above problem, it is desired to provide a program execution apparatus such as a digital television with increased reactivity that is capable of shortening the time required for updating programs and shortening the time required before a program is activated, guaranteeing at the same time the credibility of the program.

BRIEF DESCRIPTION OF THE INVENTION The present invention focuses on providing a method of storing program data files as well as a method of executing authenticated programs that is both capable of guaranteeing credibility and improving reactivity by extracting a difference between programs. before and after the update at the time of updating the version of a program, carrying out the authentication and update only for this difference immediately before the program is stored and not carrying out any authentication or only a part of authentication in the moment of the activation of the program. To solve the conventional problem, the method of storing program data files according to the present invention comprises: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the authenticated data files of the first program in a transmission receiver according to information that relates to the storage of each of the data files in the first program; a second stage of receiving information that refers to the storage of each data file of a second program included in a second transport stream and the following stages are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a third stage of verifying if two recast values are consistent or not, one of the recast values being calculated from of the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth stage of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program and the recast value being calculated from a recast file located in a higher directory of the second program; and a sixth stage of authenticating the second program and storing the second program authenticated according to the information that refers to the storage of each of the data files of the second program, in case that the following is satisfied: that 'both recast values are verified as consistent in the third stage; that the certificate file included in the second program is verified as valid in the fourth stage and that the deciphered value and the recast value are verified as consistent in the fifth stage. As a result, it becomes possible to shorten the time required to authenticate and update a program. Moreover, the different data file included in the second program can be a data file that is used to update a data file of the first program that was authenticated at the time of storing the first program. As a result, it becomes possible to update a data file included in the first program, using a data file included in the second program whose version has been updated. Moreover, the different data file included in the second program may be a new data file that is different from any of the data files of the first program that were authenticated at the time of storing the first program. As a result, it becomes possible to store a data file that has just been added to the second program whose version has been updated. Even more, in case each of the programs has a directory structure, each data file included in each directory and the recast file corresponding to each of the data files can be located in the same directory, and the third stage can be run for each directory that includes the different data file included in the second program. As a result, it becomes possible to review, for each data file included in each directory, whether the recast value calculated from the data file and a recast value stored in a recast file corresponding to the data file are consistent or do not. Furthermore, the fourth stage may include a seventh stage of verifying whether two root certificates match or not, one of the root certificates being in the certificate file included in the second program and the other root certificate being installed in the receiver of transmission, and in the fourth stage, the certificate file can be verified as valid in case the two root certificates coincide. Here, the fourth stage can also include an eighth step of verifying a period of validity of each certificate in the certificate file included in the second program, and in the fourth stage, the certificate file can be verified as valid in the event that both of the following conditions are satisfied: that the two root certificates coincide and that the time at which the authentication is carried out is within the period of validity of each certificate in the certificate file. As a result, it becomes possible to prevent a program from being stored in case the root certificates do not match and the validity period of the certificate has expired. Also, the method of executing authenticated programs according to the present invention comprises: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the data files authenticated of the first program in a transmission receiver according to the information that refers to the storage of each of the data files of the first program; a second stage of receiving information that refers to the storage of each of the data files of a second program included in a second transport stream and the following stages that are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that were authenticated at the time of storing the first program; a third stage of verifying whether two recast values are consistent or not, one of the recast values being calculated from the different data file included in the second program and the other recast value being stored in a corresponding recast file to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth stage of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a higher directory of the second program; a sixth stage of authenticating the second program and storing the second authenticated program according to the information that refers to the storage of each of the data files of the second program, in case the following is satisfied: that the two values of recasting shall be verified as consistent in the third stage; that the certificate file included in the second program be verified as valid in the fourth stage and that the deciphered value and the recast value be verified as consistent in the fifth stage; and a ninth step of verifying whether the certificate file included in the second stored program is valid or not in case a second program is to be executed, and an execution step of authenticating the second stored program again and executing the second one authenticated program only in case the certificate file included in the second stored program is verified as valid in the ninth stage. As a result, it becomes possible to shorten the time required to authenticate and update a program, as well as to shorten the time required before a program is activated, while guaranteeing the credibility of the program. Moreover, the ninth stage can include a tenth stage of verifying whether two root certificates coincide or not, one of the root certificates being in the certificate file included in the second stored program and the other root certificate being installed in the second stage. Transmission receiver, and in the ninth stage, the certificate file can be verified as valid in case the two root certificates match. Here, the ninth step may include an eleventh stage of verifying a period of validity of each certificate in the certificate file included in the second stored program, and in the ninth stage, the certificate file may be verified as valid in case it is stored. satisfy both of the following conditions: that the two root certificates match and that the execution time is within the validity period of each certificate in the certificate file. As a result, it becomes possible to prevent a program from being stored in case the root certificates do not match and the validity period of the certificate has expired. Note that not only is it possible to incorporate the present invention as a method of storing program data files and a method of executing authenticated programs as above, but also as a storage device for program data files and an apparatus for execution of authenticated programs that include, as their respective units, the characteristic steps included in the method of storing program data files and the method of executing authenticated programs, and as programs that cause a computer to execute its respective stages. It should also be noted that these programs can be distributed on a recording medium such as a CD-ROM and by means of a transmission medium such as the Internet. As is obvious from the above descriptions, the method of storing data program files according to the present invention is capable of shortening the time required to authenticate and update a program. Moreover, the method of executing authenticated programs according to the present invention is capable of shortening the time required before a program is activated, while at the same time guaranteeing the credibility of the program. The description of Japanese patent application No. 2003-421616 filed on December 18, 2003, the description of Japanese patent application No. 2004- 111802 filed on April 6, 2004 and the description of the application of E.U.A. Provisional No. 60/530663, filed December 19, 2003, including the specification, drawings and claims are hereby incorporated by reference in their entirety.

Brief description of the figures These and other objects, advantages and characteristics of the invention will be apparent from the following description thereof taken in conjunction with the accompanying drawings that illustrate a specific embodiment of the invention. In the drawings: Figure 1 is a diagram showing a structure of a cable television system according to a first embodiment of the present invention. Figure 2 is a diagram showing an example of using frequency bands that are used for communications between a cable head and terminal apparatuses in the cable television system according to the present invention. Figure 3 is a diagram showing an example of using frequency bands that will be used for communications between the cable head and the terminal apparatuses in the cable television system according to the present invention. Figure 4 is a diagram showing an example of using frequency bands that will be used for communications between the cable head and the terminal apparatuses in the cable television system according to the present invention. Figure 5 is a diagram showing a configuration of a terminal apparatus in the cable television system according to the present invention. Figure 6 is a diagram showing an example of an external view of the terminal apparatus in the cable television system according to the present invention. Figure 7 is a diagram showing a hardware configuration of a POD 504 according to the present invention. Figure 8 is a diagram showing a structure of a program stored in the POD 504 according to the present invention. Figure 9 is a diagram showing a structure of a package defined in the MPEG standard. Fig. 10 is a diagram showing an example of a transport stream MPEG2. Figure 11 is a diagram showing an exemplary external view of an input unit 513 in the case when it is configured in the form of a front panel. Fig. 12 is a diagram showing a structure of the program stored in a terminal apparatus 500 according to the present invention. Figure 13A is a diagram showing an example of a display screen presented by a viewer 509 in accordance with the present invention; and Figure 13B is a diagram showing an example of a display screen displayed by the viewer 509. according to the present invention. Figure 14 is a diagram showing an example of information stored in a secondary storage unit 510 according to the present invention. Figures 15A, 15B and 15C are diagrams, each showing an example of information stored in a primary storage unit 511 according to the present invention. Figure 16 is - a schematic diagram showing the contents of a PAT specified in the MPEG2 standard according to the present invention. Figure 17 is a schematic diagram showing the contents of a PMT specified in the PMEG2 standard according to the present invention. Figure 18 is a schematic diagram showing the contents of an AIT according to the present invention. Figure 19 is a schematic diagram showing a file system that will be transmitted in the DSMCC format according to the present invention. Figure 20 is a schematic diagram showing the contents of XAIT according to the present invention. Figure 21 is a diagram showing an example of information stored in the secondary storage unit 510 according to the present invention. Figures 22A, 22B and 22C are diagrams, each showing an example of files including recast values of files or directories according to the present invention. Figure 23 is a diagram showing a structure of a chain of certificates according to the present invention. Fig. 24 is a diagram showing a structure of an X.509 certificate according to the present invention. Figure 25 is a diagram showing a structure of a signature file according to the present invention. Figure 26 is a diagram showing constituent elements of a security module according to the present invention. Figure 27 is a flow diagram showing an operation that will be carried out when a file system is authenticated in accordance with the present invention. Figure 28 is a flowchart in case no authentication is performed when a program pre-activation notification is received in accordance with the present invention. Fig. 29 is a flow diagram showing an operation that will be carried out when an alteration check is performed for a file system according to the present invention. Figure 30 is a flow chart showing an operation that will be carried out when an alteration check is carried out using a signature file according to the present invention. Figure 31 is a flow chart showing an operation that will be carried out when a chain relationship between a certificate of origin and an intermediate certificate is reviewed in accordance with the present invention. Figure 32 is a flow chart showing an operation that will be carried out when a media relationship and a root certificate is reviewed in accordance with the present invention. Figure 33 is a flow diagram showing an operation that will be carried out when a signature on a root certificate is reviewed in accordance with the present invention. Fig. 34 is a diagram showing an example of a file that will be used to specify files to be stored according to the present invention. Figure 35 is a diagram showing an example of file list information describing details of a file 2130 according to the present invention. Figure 36 is a diagram showing constituent elements of an AM according to the present invention. Fig. 37 is a diagram showing an example of file list information describing details of a file 2130 that was previously stored in a secondary storage unit 510 in accordance with the present invention. Fig. 38 is a diagram showing an example of file list information that is generated by extracting a difference according to the present invention. Figure 39 is a flow chart showing the processing carried out by a file comparison unit 3601 according to the present invention. Fig. 40 is a flow chart showing the processing carried out by a file system management unit 3602 according to the present invention. Figure 41 is a flow chart showing the processing carried out by a file system storage unit 3603 according to the present invention. Figure 42 is a flow chart showing processes carried out by the MA and security administrator in accordance with the present invention. Figure 43 is a schematic diagram showing the contents of XAIT according to the present invention. Figure 44 is a diagram showing an example of information stored in the secondary storage unit 510 according to the present invention. Figures 45A45B and 45C are diagrams, each showing an example of files that may include recast values of files or directories according to the present invention. Figure 46 is a flow chart showing d an operation that will be carried out when an alteration check is performed for a file system according to the present invention. Figure 47 is a diagram showing an example of a file that will be used to specify files that 0 will be stored in accordance with the present invention. Figure 48 is a flowchart showing an operation that will be performed when the authentication of a file system is carried out in accordance with the present invention. Figure 49 is a flow chart showing an operation that will be carried out at the time of reviewing the validity of X.509 certificates when a program pre-activation notification is received in accordance with the present invention. Figure 50 is a diagram showing a simplified structure of a code file that will be received from the download module according to the present invention. Figures 51A, 51B and 51C are diagrams, each showing certificates owned by the terminal apparatus being replaced in accordance with the present invention. Figure 52 is a flow chart showing an operation that will be carried out when the replacement of certificates is carried out in accordance with the present invention. Figure 53 is a flow chart showing an operation that will be carried out at the time of comparing root certificates when a program pre-activation notification is received in accordance with the present invention. Fig. 54 is a diagram showing a structure of a CRL according to the present invention. Fig. 55 is a schematic diagram showing a list of certificates revoked in the CRL according to the present invention. Fig. 56 is a diagram showing an example of a file system that includes a CRL according to the present invention. Fig. 57 is a flow chart showing an operation that will be performed when the validity of the CRL is reviewed based on a recast value and a signature value in accordance with the present invention. Fig. 58 is a flow chart showing an operation that will be carried out when the validity of the CRL is reviewed based on a chain relationship between certificates and a comparison between root certificates according to the present invention. Fig. 59 is a diagram showing an example of a file that includes recast values of files or directories according to the present invention. Figure 60 is a flow chart showing an operation for carrying out authentication in case there is a CRL at the time of storing programs according to the present invention. Figure 61 is a flow chart showing an operation to carry out the authentication in case there is a CRL at the time of activation of the program. Figure 62 is a schematic diagram showing a database of revoked certificates in accordance with the present invention. Figure 63 is a diagram showing a sample file system that includes files that are used to specify files to be stored in accordance with the present invention and Figure 64 is a diagram showing an exemplary file used to specify files which will be stored according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION The following describes embodiments of the present invention with reference to the figures.

First Mode An explanation of a preferred embodiment of a cable television system according to the present invention is given with reference to the figures. Figure 1 is a block diagram showing the relationship between apparatuses composing the cable system ", which are a cable head 101, and three terminal apparatuses: a terminal apparatus there, a terminal apparatus B112 and a terminal apparatus C113 In the present embodiment, three terminal apparatuses are connected to a cable head, but it is possible to carry out the present invention if an arbitrary number of terminal apparatuses are connected to the cable head. various terminal devices, transmission signals such as video, audio and data, and receive data transmitted from the terminal devices, to achieve this, frequency bands are divided which are used for the transmission of data between the cable head 101, and the terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113, Figure 2 is a table showing an example of divided frequency bands.There are almost two types of frequency bands. uencia.- Out of Band (which will be abbreviated as OOB) and In Band. A frequency band of 5 ~ 130MHz is assigned to OOB to be used primarily for the exchange of data between the cable head 101 and the terminal apparatus there, the terminal apparatus B112 and the terminal apparatus C113. A band of frequencies of 130MHz ~ 864MHz is assigned to In Band that will be used mainly for transmission channels that include video and audio. QPSK is used for OOB, while QAM64 is used for En Banda as modulation techniques. A detailed explanation of the modulation techniques is omitted here, since they are publicly known techniques which are less related to the present invention. Figure 3 shows a more specific example of how the OOB frequency band is used. A frequency band of 70MHz ~ 74MHz is used to transmit data from the cable head 101. In this case, all of the terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113 receive the same data from the same cable head 101 Meanwhile, a frequency band of 10.0MHz ~ 10.1MHz is used to transmit data from the terminal apparatus there to the cable head 101. A frequency band of 10.1MHz ~ 10.2 MHz is used to transmit data from the terminal apparatus B112 at the cable head 101. A frequency band of 10.2MHz ~ 10.3MHz is used to transmit data from the terminal apparatus C113 to the cable head 101. Accordingly, it becomes possible to transmit unique data for each terminal apparatus to the head of the cable. cable 101 from the terminal apparatus there, the terminal apparatus B112 and the terminal apparatus C113. Figure 4 shows an example of the use of the frequency band In Band. Bands of frequencies of 150 ~ 156MHz and 156 ~ 162MHz are assigned respectively to a television channel 1 and to a television channel 2, and the subsequent frequencies are assigned to the television channels at 6MHz intervals. 310MHz and the subsequent frequencies are assigned to radio channels at 1MHz intervals. Each of the above channels can be used for either analog transmission or digital transmission. In case of digital transmission, the data is transmitted in the transport packet format that complies with the MPEG2 standard, in which case the data destined to several data transmission systems can be transmitted, as well as audio and video data. The cable head 101 is equipped with a QPSK modulation unit, a QAM modulation unit and the like in order to be able to transmit suitable transmission signals to the respective frequency scales. In addition, the cable head 101 is equipped with a demodulation unit QPSK to receive data from the terminal devices. Likewise, the cable head 101 is assumed to be further equipped with various devices related to the modulation units and the previous demodulation unit. However, a detailed explanation of these is omitted here, since the present invention refers especially to terminal devices. The terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113 receive and reproduce transmission signals that are transmitted from the cable head 101. Moreover, the terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113 transmit unique data for each terminal apparatus to the cable head 101. In the present embodiment, these three terminal devices will have the same configuration. Figure 5 is a block diagram showing a hardware configuration of each terminal apparatus. 500 It is a terminal apparatus, which is formed of a demodulation unit QAM 501, a demodulation unit QPSK 502, a demodulation unit QPSK 503, a decoder TS 505, an audio decoder 506, a loudspeaker 507, a decoder video 508, a visual viewer or presenter 509, a secondary storage unit 510, a primary storage unit 511, a ROM 512, an input unit 513 and a CPU 514. In addition, a POD 504 may be attached to / detached from the terminal apparatus 500. Figure 6 shows a thinly shaped television which is an exemplary external view of the terminal apparatus 500. The terminal apparatus may have a variety of configurations, but in the present embodiment, a terminal apparatus that is configured on the basis of OpenCable® and OCAP is described as an example. 601 It is a thin steel TV case, in which all the components of the terminal apparatus 500 except for the POD 504 are contained. 602 It is a visual presenter, which corresponds to the visual presenter 509 of Figure 5. 603 It is a front panel unit which is formed of several buttons and which corresponds to the input unit 513 of Figure 5. 604 It is a terminal signal input to which a cable line is connected to transmit / receive signals to and from the cable head 101. The signal input terminal is connected to the QAM demodulation unit 501, the demodulation unit QPSK 502 and the modulation unit QPSK 503 shown in FIG. 5. 605 It is a POD card corresponding to the POD 504 in FIG. 5. The POD 504 is incorporated independently of the terminal apparatus 500 and can be connected / detached from the terminal apparatus 500, as in the case of the POD card 605 of FIG. 6. A detailed description of the POD 504 is given below. 606 It is an insertion slot in which the POD card 605 is inserted. With reference to Figure 5, the demodulation unit QAM 501 demodulates a signal that has been modulated by QAM and transmits it from the cable head 101, according to with tuning information that includes a frequency specified by the CPU 514, and passes the result to the POD 504. The demodulation unit QPSK 502 demodulates a signal that has been modulated by QPSK and transmits it from the cable head 101, in accordance with the tuning information that includes a frequency specified by the CPU 514, and passes the result to the POD 504. The QPSK modulation unit 503 demodulates by QPSK a signal passed from the POD 504, according to demodulation information that includes a frequency specified by the CPU 514 and transmits the result to the head cable 101. As shown in Figure 6, the POD 504 can be detached from the main body of the terminal apparatus 500. The definition of the connection interface between the main body of the terminal 500 and the POD 504 is given in FIG.

Specification of OpenCable® CableCARD® Interface (OC-SP-CC-IF-115-031121) and in the specifications mentioned by this description. Note that CableCARD in this description refers to a POD. Here, a detailed description is omitted, and a detailed explanation is given only of the constituent elements relevant to the present invention. Figure 7 is a block diagram showing an internal configuration of the POD 504. The POD 504 is formed of a first descrambling unit 701, a second descrambling unit 702, a scrambling unit 703, a primary storage unit 704, a unit secondary storage 705 and a CPU 706. 0 The first descrambling unit 701 receives a scrambled signal from the demodulation unit QAM 501 under the instructions of the CPU 706 and descrambles this signal. Then, the first descrambler unit 701 transmits the descrambler signal to the TS 505 decoder of the d terminal apparatus 500. The information required for the descrambler such as a key is provided by the CPU 706 according to the needs. More specifically, the cable head 101 transmits several payment channels, and when the user purchased the right to view these 0 payment channels, the first descrambling unit 701 receives the required information such as a key from the CPU 706 and carries out descrambling. As a result, the user can see these payment channels. When required information such as a key is not provided, the first descrambling unit 701 passes the received signal directly to the TS 505 decoder without performing descrambling. The second descrambling unit 702 receives a scrambled signal from the demodulation signal QPSK 502 of the terminal apparatus 500 under the instructions coming from the CPU 706, and descrambles this signal. Then, the second descrambling unit 702 passes the descrambled data to the CPU 706. The scrambling unit 703 scrambles the data received from the CPU 706, under the instruction of the CPU 706, and sends the result to the modulation unit QPSK 503 of the apparatus terminal 500. The primary storage unit 704, a concrete constituent element of which is a primary memory such as a RAM, is intended to store data temporarily when the CPU 706 performs processing. The secondary storage unit 705, a concrete constituent element of which is a secondary storage memory such as a volatile ROM, is intended to store a program that will be executed by the CPU 706 as well as to store data that should never be erased. when the power goes off The CPU 706 executes the program stored in the secondary storage unit 705. The program consists of several subprograms. Figure 8 shows an example of the program stored in the secondary storage unit 705. In Figure 8, a program 800 is formed of several subprograms including a main program 801, an initialization subprogram 802, a network subprogram 803, a subprogram of reproduction 804 and a subprogram PPV 805. Here, PPV, which is an abbreviation of Pay Per Event, refers to a service that allows the user to see a certain program such as a movie on a charging basis. When the user enters their personal identification number, the fact that the user has purchased the right to watch the program is notified to the head of cable 101, and the program is descrambled. Consequently, the user can see this program. This observation of the program requires the user to pay for the purchase at a later date. The main program 801, which is the subprogram activated by the CPU 706 first of all when the power is turned on, controls the other subprograms. The initialization subprogram 802, which is activated by the main program 801 when the power is turned on, performs exchange of information and the like with the terminal apparatus 500 to carry out the initialization processing. This initialization processing is defined in detail in the OpenCable® CableCARD® Interface Specification (OC-SP-CC-IF-115-031121) and in specifications mentioned by this description. Moreover, the initialization subprogram 802 also performs initialization processing not defined in this description. Here, a part of this initialization processing is introduced. When the power is turned on, the initialization subprogram 802 notifies the demodulation unit QPSK 502 of a first frequency stored in the secondary storage unit 705 by means of the CPU 514 of the terminal apparatus 500. The demodulation unit QPSK 502 leads to perform the tuning using the first frequency provided, and transmit the resulting signal to the secondary descrambler unit 702. In addition, the initialization subprogram 802 provides the secondary descrambler unit 702 descrambling information such as a first key stored in the secondary storage unit 705. As a result, the secondary descrambling unit 702 carries out descrambling and passes the result to the CPU 706 executing the initialization program 802. Accordingly, the initialization subprogram 802 can receive the information. In the present embodiment, the initialization subprogram 802 receives information through the network subprogram 803. A detailed description of this is given below.

Moreover, the initialization subprogram 802 notifies the QPSK modulation unit 503 of a second frequency stored in the secondary storage unit 705 via the CPU 514 of the terminal apparatus 500. The initialization subprogram 802 provides the scrambling unit 703 with scrambling information stored in the secondary storage unit 705. When the initialization subprogram 802 provides, via the network subprogram 803, to the scrambling unit 703 the information to be sent, the scrambling unit 703 scrambles the data using the randomization data provided, and provides the randomized data to the QPSK modulation unit 503. The QPSK modulation unit 503 modulates the randomized information it received, and sends the modulated information to the cable head 101. As a result, it becomes possible that the initialization subprogram 802 carries out a bidi communication with the cable head 101 by means of the terminal apparatus 500, the second descrambler unit 702, the scrambler unit 703 and the network subprogram 803. The network subprogram 803, which is used by several subprograms such as the main program 801 and the initialization subprogram 802, is a subprogram intended to carry out a bidirectional communication with the cable head 101. More specifically, the network subprogram 803 behaves as if other subprograms using the network subprogram 803 were carrying performed a bidirectional communication with the cable head 101 according to TCP / IP. A detailed explanation of TCP / IP is omitted here, since it is a publicly known technique that specifies the protocols that will be used when exchanging information between several terminals. When activated by the display subprogram 802 upon power up, the network subprogram 803 notifies, via the terminal apparatus 500, the cable head 101 of a MAC address (an abbreviation of Media Access Control) which is an identifier to identify the POD 504 and which is stored in the secondary storage unit 705 in advance, thus requesting the obtaining of an IP address. The cable head 101 notifies the POD 504 of the IP address via the terminal apparatus 500, and the network subprogram 803 stores this IP address in the primary storage unit 704. Thereafter, the cable head 101 and the POD 504 communicate with each other using this IP address as the identifier of the POD 504. The playback subprogram 804 provides the first descrambling unit 701 with descrambling information such as a second key stored in the secondary storage unit 705 as well as information from descrambling such as a third key provided by the terminal apparatus 500, to thereby enable descrambling to be carried out. Moreover, the playback subprogram 804 receives, via the network subprogram 803, information indicating that the signal input to the first descrambler unit 701 is a PPV channel. After the notification that the signal is a PPV channel, the playback subprogram 804 activates the PPV subprogram 805. When activated, the PPV subprogram 805 visually displays, on the terminal apparatus 500, a message indicating the user to buy the program, and accepts a user's income. More specifically, when the information that is desired to be presented on the screen is sent to the CPU 504 of the terminal apparatus 500, a program running on the CPU 504 of the terminal apparatus 500 shows the message on the visual presenter 509 of the apparatus terminal 500. Then, when the user enters the personal identification number by means of the input unit 513 of the terminal apparatus 500, the CPU 514 of the terminal apparatus 500 accepts it, and sends it to the PPV subprogram 805 running on the CPU 706 of POD 504. Subprogram PPV 805 sends, at the cable head 101 - the personal identification number accepted by means of the network subprogram 803. When this personal identification number is valid, the cable head 101 notifies, through the network subprogram 803, the subprogram PPV 805 of the descrambling information required to descramble this fourth key. The PPV subprogram 805 provides the first descrambler unit 701 with the descrambling information accepted such as the fourth key, and then the first descrambler unit 101 descrambles the input signal. Referring to Figure 5, the TS 505 decoder performs the filtering of the signal it accepted from the POD 504, and passes necessary data to the audio decoder 506, the video decoder 508 and the CPU 514. Here, the signal sent from the POD 504 is an MPEG2 transport stream. A detailed description about an MPEG2 transport stream is given in the MPEG ISO / IEC138181-1 specification, and is therefore not explained in detail in the present embodiment. An MPEG2 transport stream is composed of several fixed-length packets, and a packet ID is assigned to each packet. Figure 9 is a diagram showing the structure of a package. 900 It is a packet, which contains 188 bytes of fixed length. The upper four bytes are a header 901 that stores information to identify the packet, and the other 184 bytes is a payload 902 that stores information that is desired to be carried. 903 Shows the break of header 901. A packet ID is included in 13 bits from the Io to the i2vo ~ 24th bit. Figure 10 is a schematic diagram illustrating several chains of packets that will be transmitted. A packet 1001 contains a packet ID "1" in its header and includes the first video information A in its payload. A packet 1002 contains a packet ID "2" in its header and includes the first audio information A in its payload. A packet 1003 contains a packet ID "3" in its header and includes the first audio B information in its payload. A packet 1004 contains the packet ID "1" in its header and includes the second video information A in its payload, which is the subsequent information of the packet 1001. Similarly, packets 1005, 1026 and 1027 carry data subsequent of the other packages. By concatenating the contents of the payloads of the packets with the same packet IDs in the above manner, it is possible to play video and audio in successive order. Referring to FIG. 10. When the CPU 514 indicates, to the TS 505 decoder, the packet ID "1" as well as the "video decoder 508" as an output destination, the TS 505 decoder extracts packets with the ID of 505. package "1" of the transport stream MPG2 received from the POD 504, and passes them to the video decoder 508. In figure 10, therefore, only the video data is passed to the video decoder 508. At the same time , when the CPU 514 indicates, to the TS 505 decoder, the packet ID 2"as well as the audio decoder 506", the TS 505 decoder extracts packets with the packet ID "2" of the received MPEG2 transport stream. from the POD 504, and passes them to the audio decoder 506. In FIG. 10, only the audio data is passed to the video decoder 508. This processing of extracting only necessary packets according to the packet IDs corresponds to the filtering that will be carried out by the TS 505 decoder. E The TS 505 decoder is capable of carrying out more than one filtering processing simultaneously upon receipt of an instruction from the CPU 514. Referring to FIG. 5, the audio decoder 506 concatenates audio data embedded in the packets in the stream of MPEG2 transport provided by the TS 505 decoder, performs the digital to analog conversion in the concatenated data and sends the result to the loudspeaker 507. The loudspeaker 507 sends the signal provided by the audio decoder 506 as audio. The video decoder 508 concatenates video data inserted into the packets in the MPEG2 transport stream provided by the TS 505 decoder, performs the digital to analogous conversion in the concatenated data and outputs the result to the visual presenter 509. The visual presenter 509, a concrete constituent element of which is a CRT or liquid crystal and the like, sends a video signal provided by the video decoder 508 and visually presents a message specified by the CPU 514, and so on. The secondary storage unit 510, concrete constituent elements of which are a volatile memory, a hard disk and the like, stores and erases data and programs specified by the CPU 514. The stored data and programs are referred by the CPU 514. The data and stored programs are kept under storage even while the terminal apparatus 500 is turned off. The primary storage unit 511, concrete constituent elements of which are a RAM and the like, temporarily stores data and programs specified by the CPU 514 and deletes them. The stored data and programs are referred by the CPU 514. The stored data and programs are deleted when the terminal apparatus 500 is turned off. The ROM 512 is a read-only memory device, concrete constituent elements of which are a ROM, a CD-ROM and a DVD, and the like. The ROM 512 stores a program that will be executed by the CPU 514. The input unit 513, concrete constituent elements of which are a front panel or a remote control, accepts an input from the user. Figure 11 shows an example of the input unit 513 in the case that it is configured in the form of a front panel. 1100 It is a front panel, which corresponds to the front panel unit 603 shown in figure 6. This front panel 1006 is formed of seven buttons: an upward cursor button 1101, downward cursor button 1102, a button cursor to the left 1103, a cursor button to the right 0 1104, an OK button 1105, a cancel button 1106 and an EPG 1107 button. When the user presses a button, the identifier of this pressed button is notified to the CPU 514. The CPU 514 executes the program stored in the ROM 512. According to instructions that come from this program that will be executed, the CPU 514 controls the demodulation unit QAM 501, the demodulation unit QPSK 502, the demodulation unit QPSK 503, the POD 504, the TS 505 decoder, the visual presenter 509, the secondary storage unit 510, the primary storage unit 511 and the ROM 512. Figure 12 is a diagram showing an exemplary program structure. ma which is stored in the ROM 512 and executed by the CPU 514. A program 1200 is formed of several subprograms. To be more specific, the program 1200 is formed of an OS 1201, an EPG 1202, a Java® VM 1203 (hereinafter referred to as VM 1203), a service manager 1204 and a Java® Library 1205 library (hereinafter referred to only as library 1205). OS 1201 is a subprogram that will be activated by the CPU 514 when the terminal apparatus 500 is turned on. OS 1201 is an abbreviation of OS, an example of which is Linux and the like. OS 1201 is a generic name for a publicly known apparatus in the art formed of a core 1201a for executing a program in parallel with another subprogram and a library 1201b, and therefore a detailed explanation is omitted. In the present embodiment, the core 1201a of OS 1201 executes EPG 1202 and VM 1203 as subprograms. Meanwhile, the library 1201b provides these subprograms with plural functions required to control the constituent elements of the terminal apparatus 500. Here, a tuning is introduced as an example of these functions. With the tuning function, tuning information including a frequency is received from another subprogram and then passed to the demodulation unit QAM 501, consequently, it is possible for the demodulation unit QAM 501 to carry out the demodulation based on the tuning information provided, and pass the demodulated data to the POD 504. As a result, the other subprograms can control the demodulation unit QAM by means of the library 1201b. The EPG 1202 is formed of a program display unit 1202a for visually displaying a list of programs to the user as well as for accepting an input from the user, and a playback unit 1102b for selecting channels. Here, EPG is an abbreviation of Electric Program Guide. The EPG 1202 is activated when the terminal apparatus 500 is turned on. In the activated EPG 1202, the program presentation unit 1202a expects input from the user via the input unit 513 of the terminal apparatus 500. Here, in case the input unit 513 has the shape of the front panel illustrated in Figure 11, when the user presses the EPG button 1107 on the input unit 513, the CPU 514 is notified of the identifier of this EPG button. The program display unit 1202a of the EPG 1202, which is a subprogram running on the CPU 514, accepts this identifier, and displays program information on the visual presenter 509. Figure 13A and Figure 13B show examples of a program table displayed on the visual presenter 509. See Figure 13A. The program information is presented visually on the visual presenter 509 in a grid pattern. A column 1301 describes the time information. A column 1302 describes a channel name "channel 1" and programs that will be transmitted during periods of time corresponding to the respective hours described in column 1301. It is shown that a "News 9" program is transmitted from 9:00 a.m. to 10 p.m. : 30, and "Cinema AAA" is broadcast from 10:30 to 12:00 on "Channel 1". A column 1303 describes a channel name "Channel 2" and programs that will be transmitted during periods of time corresponding to the respective hours described in column 1301, as in the case of column 1302. A 0 program "Cinema BBB" is broadcast from 9:00 to 11:00, and "News 11" is broadcast from 11:00 to 12:00. 1330 It is a cursor. The cursor 1130 moves by pressing the left cursor 1103 or the right cursor 1104 on the front panel 1100. When the cursor to the right 1104 is pressed in the state illustrated in FIG. 13A, the cursor 1130 moves to the right as it is shown in Figure 13B. Meanwhile, when the left cursor 1103 is pressed in the state illustrated in FIG. 13B, the cursor 1330 moves to the left as shown in FIG. 0 13A. When the OK button 1105 on the front panel 1100 is pressed in the state shown in FIG. 13A, the program display unit 1202a notifies the reproduction unit 1102b of the "Channel d 1" identifier. Meanwhile, when the OK button 1105 on the front panel 1100 is pressed in the state shown in FIG. 13B, the program display unit 1202a notifies the playback unit 1102b of the identifier of "Channel 2". Moreover, the program display unit 1202a periodically stores program information that will be displayed visually from the cable head 101 in the primary storage unit 511 via the POD 504. Generally, it takes time to obtain program information from the head. of cable. However, it becomes possible to visually display a program table quickly by visually presenting the program information that is pre-stored in the primary storage unit 511 by pressing the EPG button 1107 of the input unit 513. The playback unit 1102b reproduces the channel using the identifier received from the channel. The relationship between channel identifiers and channels is pre-stored by the secondary storage unit 510 as channel information. Figure 14 shows an example of the channel information stored in the secondary storage unit 510. The channel information is stored in tabular form. A column 1401 describes the channel identifiers. A column 1402 describes channel names. A column 1403 describes tuning information. Here, the tuning information is represented by values that will be provided to the demodulation unit QAM 501 such as frequency, transmission rate and coding relation. A column 1404 describes program numbers. Program numbers are numbers used to identify PMTs defined by the MPEG2 standard. A description about PMT is given below. Each of the lines 1411 ~ 1414 indicates a set of the indicator, channel name and tuning information of each channel. Line 1411 describes a set that includes "1" as an identifier, "Channel 1" as a channel name, a frequency of "312MHz" as tuning information and "101" as a program number. The reproduction unit 1102b passes the identifier of the received channel directly to the service manager in order to reproduce the channel in this way. Moreover, when the user presses the upward cursor 1101 and the downward cursor 1102 on the front panel 1100 while the reproduction is taking place, the reproduction unit 1102b receives a notification about this oppression by the user of the input unit. 513 by means of the CPU 514, and changes the channel that is being played by another. First, the playback unit 1102b stores, in the primary storage unit 511, the identifier of the channel that is currently playing. Figures 15A, 15B and 15C show exemplary identifiers of channels stored in the primary storage unit 511. Figure 15A shows that an identifier "3" is stored, and this is shown by referring to Figure 14 that a channel with the Channel name "TV 3" is being played. When the user presses the upward cursor 1101 in a state illustrated in Fig. 15A, the playback unit 1102b references the channel information shown in Fig. 14, and passes the identifier "2" of a channel with the name of "Channel 2" channel to the service manager in order to play a channel with the channel name "Channel 2" again, which is the previous channel in the table. At the same time, the reproduction unit 1102b rewrites the identifier in the channel identifier "2" stored in the primary storage unit 511-. Figure 15B shows this rewritten channel identifier. Meanwhile, when the user presses the downward cursor 1102 in the state illustrated in FIG. 15A, the playback unit 1102b refers to the channel information shown in FIG. 14, and passes the identifier "4" of a channel with the channel name "TV Japan" to the service manager in order to play a channel with the channel name "TV Japan" again, which is the next channel in the table. At the same time, the reproduction unit 1102b rewrites the identifier in the channel identifier "4" stored in the primary storage unit 511. Figure 15C shows this rewritten channel identifier. VM 1203 is a Java® virtual machine that sequentially analyzes and executes programs written in the Java® language. Programs written in the Java® language are compiled in intermediate codes known as byte codes which do not depend on hardware. The Java® virtual machine is an interpreter that executes these byte codes. Some of the Java® virtual machines translate the byte codes into an executable form that can be interpreted by the CPU 514 and pass the result to the CPU 514, which executes them. VM 1203 is activated, with a Java® program that will be executed by being specified by kernel 1201a. In the present embodiment, the core 1201a specifies the service manager 1204 as a Java® program to be executed. A detailed commentary on the Java® language is given in many books that include "Java® Language Specification" (ISBN 0-201-63451-1). Therefore, a detailed description about this is omitted here. Likewise, a detailed commentary on the operation of the Java® VM itself is given in many books that include "Java® Virtual Machine Specification" (ISBN 0-201-73451-X). Therefore, a detailed description of this is omitted here.

Service manager 1204, which is a Java® program written in the Java® language, is executed by VM 1203 sequally. Service manager 1204 may call and be called by another subprogram not written in the Java® language through JNI (Java Native Interface). A common NYI is given in many books that include "Java® Native Interface". Therefore, a detailed description about this is omitted here. The service manager 1204 accepts the idfier of the channel that comes from the reproduction unit 1102b through the JNI. First, service manager 1204 passes the channel idfier to a Tuner 1205c in Library 1205 to request tuning. The Tuner 1205 refers to the channel information stored in the secondary storage unit 510 to obtain the tuning information. Assuming that the service manager 1204 passes the idfier "2" of the channel to the tuner 1205c, the tuner 1205c refers to the column 1412 shown in figure 14, and obtains the tuning information "156MHz", which corresponds to the channel. The Tuner 1205c passes the tuning information to the demodulation unit QAM 501 by means of the library 1201b of the OS 1201. The demodulation unit QAM 501 demodulates the signal sfrom the cable head 101 according to the tuning information given to the demodulation unit QAM 501, and passes the resulting signal to the POD 504. Then, the service administrator 1204 requests a CA 1205b within the Library 1205 to carry out descrambling. The CA 1205d provides the POD 504 with information required for descrambling through the library 1201b in the OS 1201. Based on this provided information, the POD 504 descrambles the signal provided by the demodulation unit QAM 501, and passes the resulting signal to the TS 505 decoder. Then, the service manager 1204 provides a JMF 1205a within the Library 1205 with the channel idfier, to request the reproduction of the video and audio. First, the JMF 1205a obtains, from a PAT and a PMT, packet IDs used to specify the video and audio that will be played. PAT and PMT are tables defined by the MPEG-2 standard that show the alignmof programs included in an MPEG2 transport stream. PAT and PMT are carried on payloads in packages included in an MPEG2 transport stream, along with audio and video. Refer to the specification for a detailed description of PAT and PMT. Here, only a general description of PAT and PMT is given.

PAT, which is an abbreviation of Program Association Table, is carried in packages with the package ID "0". To obtain the PAT, the JMF 1205a indicates, to the TS 505 decoder, the packet ID "0" and the CPU 514 through the library 1201b of the OS 1201. Then, the TS 505 decoder carries out the filtering based on the packet ID "0", and passes the result to the CPU 514. Accordingly, the JMF 1205a can collect the PAT packets. Figure 16 illustrates a table schematically showing an example of the PAT information collected. A column 1601 describes program numbers. A column 1602 describes packet IDs. The package IDs shown in the column 1602 are used to obtain the PAT. Each of lines 1611 ~ 1613 is a pair of program number of a channel and a packet ID corresponding thereto. Here, three channels are defined. Line 1611 defines a pair of program number "101" and packet ID "501". Assuming that the channel idfier provided to JMF 1205a was "2", JMF 1205a refers to column 1412 in Figure 14, to obtain the program number "102" that corresponds to this channel idfier, and then refers to line 1612 in the PAT shown in Figure 16, so as to obtain packet ID "502" which corresponds to program number "102". PMT, which is an abbreviation of Program Map Table, is carried in packages with the package IDs specified in the PAT. In order to obtain the PMT, the JMF 1205a indicates, to the TS 505 decoder, a packet ID and to the CPU 514 through the library 1201b of the OS 1201. Here, a packet ID that will be specified is "502". Then, the TS 505 decoder performs the filtering based on the packet ID "502", and passes the result to the CPU 514. Accordingly, the JMF 1205a can collect the PMT packets. Figure 17 illustrates a table schematically showing an example of the collected PMT information. A column 1701 describes current types. A column 1702 describes packet IDs. The information specified in the respective current types is carried in the payloads of packets with the packet IDs specified in column 1702. A column 1703 describes additional information. Each of the lines 1711 ~ 1714 is a pair of a packet ID and the type of information that is being transmitted, which is known as an elementary stream. Line 1711, which is a pair of the "audio" stream type and packet ID "5011", indicates that audio data is stored in the payload of the packet with packet ID "5011". The JMF 1205a obtains, from the PMT, the packet IDs of the video and audio that will be reproduced. Referring to Figure 17, JMF 1205a obtains the audio packet ID "5011" from line 1711, and the video packet ID "5012" from line 1712. Then, JMF 1205a provides the TS 505 decoder. the pairs of the audio packet IDs obtained and the audio decoder 506 as an output destination as well as the video packet ID and the video decoder 508 as an output destination, by means of library 1201b of OS 1201 The TS 505 decoder performs filtering based on these package IDs provided and the output destinations. Here, the packet with the packet ID "511" is passed to the audio decoder 506 and the packet with the packet ID "502" is passed to the video decoder 508. The audio decoder 506 carries out the digital conversion to analogous in the package provided, in order to reproduce the audio by means of the loudspeaker 507. The video decoder 508 performs the digital to analogous conversion in the package provided, in order to present the video on the visual presenter 509. Finally, the service administrator 1204 provides the channel identifier to an AM 1205b of the library 1205, in order to request the reproduction of the data transmission. Here, reproduction of the data transmission means extracting an AM 1205b program included in the MPEG2 transport stream and causing the VM 1203 to execute it. As a technique for inserting a Java® program into an MPEG2 transport stream, a method known as DSMCC is used, which is described in the MPEG ISO / IEC138181-6 specification. A detailed explanation of DSMCC is omitted here. The DSMCC specification defines a method for coding a file system comprising directories and files used by a computer, in packets within an MPEG2 transport stream. The information about the Java® program that will be executed is carried in packets in the MPEG2 transport stream in the form of AIT. AIT is an abbreviation of Application Information Table whose definition is given in chapter ten of the DVB-MHP standard (formally known as ETSI TS 101 812 DVB-MHP specification VI.0.2). First, to obtain the AIT, the AM 1205b obtains the PAT and PMT as in the case of the JMF 1205a, to obtain the packet ID of the package stored by the AIT. Assuming that "2" was the channel identifier provided and that the PAT shown in Figure 16 and the PMT shown in Figure 17 were being transmitted, the AM 1205b obtains the PMT shown in Figure 17 according to the same procedure followed for the JMF 1205a. Later, AM 1205b extracts, from the PMT, the packet ID of the elementary current whose current type is "Data" and which has "AIT" as additional information. As shown in Fig. 17, the elementary current on line 1713 corresponds to this elementary stream, and therefore AM 1205b obtains packet ID "5013" thereof. The AM 1205b provides the TS 505 decoder with the packet ID of the AIT and the CPU 514 as a 5-destination destination through the library 1201b of the OS 1201. Afterwards, the TS 505 decoder carries out the filtering based on this Package ID provided, and pass the result to the CPU 514. Accordingly, the AM 1205b can collect the AIT packets. 0 Figure 18 is a table schematically showing an example of the AIT information collected. A column 1801 describes identifiers of Java® programs. In accordance with the MHP specification, these identifiers are defined as Application IDs, which identify whether a Java® program is a program that must be authenticated by a security administrator 1205f of the terminal apparatus 500. Authentication is not required when the value of an identifier is on the scale of 0x0 to 0x3fff, while an authentication is required when the value of a 0 identifier is on the scale of 0x4000 to 0x7fff. A Java® program whose identifier value is within the above scale is referred to as an "unsigned program" and a Java® program whose identifier value is within the last scale is referred to as a "signed program". A column 1802 describes control information to control 64 the Java programs. The control information includes "auto start", "present" and "delete". "Auto start" means that the terminal apparatus 500 automatically executes the program quickly. "Present" means that the program is not executed automatically. "Delete" means that the program will be terminated. A column 1803 describes DSMCC identifiers used to extract packet IDs that include Java® programs in the DSMCC format. A column 1804 describes program names of Java® programs. Each of lines 1811 and 1812 is a set of information about a Java® program. The Java® program defined in line 1811 is a set of an identifier "301", control information "auto start", a DSMCC identifier "1", and a program name "a / TopXlet". The Java® program defined in line 1812 is a set of an identifier "302", control information "present", a DSMCC identifier "1" and a program name "b / GameXlet". Here, these two Java® programs have the same DSMCC identifier. This indicates that two Java® programs are included in the file system which has been encoded according to the same DSMCC method. Here, only four pieces of information are specified for the respective Java® programs, but more pieces of information are actually specified. Refer to the DVB-MHP specification for 65 details The AM 1205b finds the Java® program "autorun" from the AIT, and extracts the corresponding DSMCC identifier and the Java® program name. Referring to Figure 18, the AM 1205b extracts the Java® program on line 1811, and obtains the DSMCC identifier "1" and the Java® program name "a / TopXlet". Then, the AM 1205b obtains, from the PMT, the packet ID of packets storing Java® programs in the DSMCC format, using the DSMCC identifier obtained from the AIT. More specifically, AM 1205b obtains, from the PMT, the packet ID included in the elementary stream whose current type is "Data" and whose identifier DSMCC in the additional information matches. Here, assuming that this DSMCC identifier is "1" and the PMT was that shown in Figure 17, the elementary current on line 1714 satisfies the previous condition. Therefore, packet ID "5014" will be extracted. The AM 1205b indicates, to the TS 505 decoder, the package packet ID in which data is inserted in the DSMCC format as well as the CPU 514 as an output destination through the library 1201b of the OS 1201. Here, the ID of package "5014" is provided. Then, the TS 505 decoder performs filtering based on the provided packet ID, and passes the result to the CPU 514. Accordingly, the AM 1205b can collect the required packets. The AM 1205b reconstructs the file system from the packets collected in accordance with the DSMCC method, and stores the reconstructed file system in the primary storage unit 511. The process for extracting data such as the packet file system in the MPEG2 transport stream and store the extracted data in storage units such as the primary storage unit 511 is hereinafter referred to as download. Figure 19 shows an example of the file system downloaded. In the diagram, circles represent directories and squares represent files, where 1901 is a root directory, 1902 is a "a" directory, 1903 is a "b" directory, 1904 is a "TopXlet. Class" file, and 1905 is a file "GameXlet. Class". Subsequently, the AM 1205b passes, to VM 1203, a Java® program that will be executed outside the file system downloaded to the primary storage unit 511. Here, assuming that the name of the Java® program to be executed is "a / TopXlet ", a file" a / TopXlet. Class "that resulted from attaching". Class "to the previous Java® program is a file that will be executed. "/" is a delimiter between a directory and a file name, and as shown in Figure 19, the 1904 file is a Java® program that will be executed. Then, AM 1205b passes file 1904 to VM 1203 since column 1801 describing the Java® program identifier indicates unsigned program, meaning that there is no need to request security administrator 1205f to authenticate this Java® program. VM 1203 runs this received Java® program. After receiving the identifier of another channel, the service manager 1204 ends the video and audio playback as well as the execution of the Java® program that is being carried out through each library included in the library 1205, through each library included in the same library 1205, and then performs video and audio playback as well as running a Java® program based on the newly received channel identifier. The library 1205 is a collection of several Java® libraries stored in the ROM 512. In the present embodiment, the library 1205 includes the JMF 1205a, the AM 1205b, the Tuner 1205c, the CA 1205d, a POD Lib 1205e, the administrator of security 1205f, a download module 1206, and the like. The service manager 1204 and the download module 1206 perform bidirectional communication with the cable head 101 via the POD Lib 1205e included in the library 1205. This bidirectional communication can be achieved by the POD Lib 1205e using the unit of demodulation QPSK 502 and the modulation unit QPSK 503 by means of library 1201b of OS 1201 and POD 504. Discharge module 1206 can receive code data from cable head 101 through this communication. Code data refers to binary data including an X.509 certificate and / or firmware of the "terminal 500" apparatus. Figure 20 illustrates a table schematically showing an example of the XAIT information obtained from the cable head 101. A column 2001 describes the identifier of a Java® program A column 2002 describes control information to control the Java® program Control information includes "auto start" and "present." "Auto start" means that the program is executed automatically when the device terminal 500 is on, and "present" means that the program will not be executed automatically A column 2003 describes a DSMCC identifier used to extract a package ID that includes the Java® program in the DSMCC format. program name of the Java® program A column 2005 describes the priority of the Java® program A column 2006 describes a version number of the Java program. The 2011 line indicates a set of information about the Java® program. The Java® program defined in line 2011 is a set of an identifier "0x7001", control information "autoinicio", a DSMCC identifier "1" and a program name "a / xletl". It can be known from your Java® program application ID that this Java® program is a signed program. Here, only six pieces of information are specified for the Java® program, but the present invention can be carried out even when more pieces of information are defined. After receiving the XAIT information, the AM 1205b stores the file system that comes from the transport stream MPEG2 in the primary storage unit 511, according to the same procedure as that to download the Java® program from the information of the AIT. After this, the file system is stored in the secondary storage unit 510, but if this file system includes "application description file" as shown in figure 34, the AM 1205b stores specific files in the system. files according to the descriptions of the "application description file". The AM 1205b carries out a pre-storage notification to the security administrator 1205f immediately before it stores the file system in the secondary storage unit 510. In response to this, the security administrator 1205f carries out authentication, and notifies the AM 1205b that the activation is enabled. When it is notified by the security administrator 1205f that the activation is enabled, the AM 1205b stores, in the secondary storage unit 510, a specified file included in the file system. These processes carried out by the AM 1205b and the security administrator 1205f, which are major functions of the present invention, will be described in detail below. Then, the AM 1205b stores, in the secondary storage unit 510, the result of associating the XAIT information with a storage position of the downloaded file system. Figure 21 shows an example of the XAIT information and the downloaded file system stored in the secondary storage unit 510 in association with one another. Here, a file defined in the OCAP specification is described as an example. The elements of Figure 21 which are the same as those of Figure 20 are the same to each other, and therefore an explanation of these elements is omitted. A column 2101 stores the storage position of the downloaded file system. In Figure 21, these storage positions are indicated by arrows. 2110 Is the file system downloaded, in which a top directory (also referred to as a root directory) 2120, a directory "a" 2121, a directory "b" 2122, a file "ocap. Storage" 2130, a file "ocap. certificates. 1" 2131, a file "ocap, signaturefile. 1" 2132, files "ocap. hashfile" 2140 ~ 2142, a file "xletl. class" 2150 and a file "sub. class" 2151 are included. The file 2130, which is an "application description file", is described in an XML format (language for describing web pages) as shown in Figure 34. Figure 35 is a diagram showing an example of information from list of files that shows the descriptions of file 2130. 351 In figure 35 is the file list information that indicates the descriptions of file 2130. A column 3511 describes file names. A column 3512 describes the version numbers of the respective files. Here, only two pieces of information are specified for the "application description file", but it is possible to carry out the present invention if more pieces of information are defined. Note that as the version number of each of the files described in column 3512, the value of a program number 2006 of the program that includes this file is basically given, and that as the version number of only one file described in Column 3512 whose contents will not change even when the version of your program is updated, is given the value of program number 2006 of this program before being updated. The 2140 ~ 2142 files are recast files in which file names or directory names and the corresponding recast values are included. Figures 22A, 22B and 22C are schematic diagrams showing the details of "ocap hashfiles". 221 shows "hashfile ocap" 2116, 222 in figure 22B shows "hashfile ocap" 2117 and 223 in figure 22C shows "hashfile ocap" 2118. "hashfile ocap" of 221, which exists in the directory "/" 2120, includes, in column 2211, a file "ocap. storage" 2130, a file "ocap. certificates. 1" 2131 and a directory "a" 2121 that exist in the same directory 2120 A column 2212 indicates which recast algorithm was used to calculate each value described in a column 2213. Column 2213, which refers to files or directories in column 2211, includes recast values that were calculated by using the recasting algorithm specified in column 2212. Currently, the recast algorithms that are used mainly are SHAl (Secure Recast Algorithm 1) and MD5 (Compendium of Messages 5). These are publicly known algorithms for converting data with an arbitrary length into a fixed-length byte value, which has the following characteristics: it is impossible to predict the original data after it is converted and it is used to check if a file has been destroyed or altered. Meanwhile, a recast value is a pseudo random number that is generated by the use of a recast algorithm. When a recast algorithm is SHAl, the length of a recast value is 20 bytes, whereas when a recast algorithm is MD5, the length of a recast value becomes 16 bytes. For details about SHA1 and MD5, refer to the standard "FIPS-PUB 186-2 Secure Hash Standard" and "IETF RFC1321", respectively. Here, the recast value corresponding to the directory "a" described in column 2211 is a recast value SHAl that has been calculated for the file "ocap hashfile" 2141 that exists in the directory d • As in the case of " ocap. hashfile "in 221," ocap. hashfile "in 222 includes file name, file" xletl. class "2150 as well as directory name, recast algorithm and recast value of directory" b "2122. Similarly, "ocap. hashfile" in 223 includes the file name, recast algorithm, and recast value of a "sub class" file 2151 that exists in the same directory 2122.

Here, only the attributes that are related to the present invention are described, and thus the specification of the OCAP "OpenCable® Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAPl .0-IF-109-031121) "should be referred for details about" ocap. hashfile. "A file 2131 is a chain of certificates, Figure 23 is a diagram that shows a detailed structure of the file" ocap. get certified 1"2131. 231, which illustrates a typical structure of" ocap. certify, x "(x is a positive integer), contains a root certificate 2311, an intermediate certificate 2312 and a certificate of origin 2313. They are in a chain relation in which the holder of the root certificate 2311 issues the intermediate certificate 2312 and the holder of the intermediate certificate 2312 issues the certificate of origin 2313. For example, note that according to the OCAP specification, a chain of certificates related to a signature file "ocap. signaturefile x "is" ocap. certify yourself, x "that has the same value" x. "In the case of figure 21, a chain of certificates that corresponds to the" ocap. signaturefile 1"is the" ocap. get certified 1. "Also, the root certificate 2311, the intermediate certificate 2312 and the certificate of origin 2313 are configured in the same X.509 certificate format. The X.509 certificates are widely used in various fields of the information industry and communications as a de facto standard for certificate representation format, as a recommendation of the ITU-T In Figure 23, only three certificates are illustrated, but there is a case in which there is a plurality of intermediate certificates. in this case these intermediate certificates must be in a chain state in which they are related to each other Figure 24 is a diagram showing the structure of an X. 509 certificate. Here, only the attributes required for Explain the present invention For details about X.509 certificates, refer to IETF RFC3280"Internet X, 509 Public Key Infrastructure Certify and CRL Profile". attribute area of the X. 509 certificate and 242 indicates the signature value of the X certificate. 509. The serial number 2411 indicates the number to identify the certificate, signature algorithm 2412 indicates the algorithm used to determine the signature value 242, this update date and time 2413 indicates the date and time at which this X. 509 certificate is valid, next update date and time 2414 indicates the date and time at which this X. 509 certificate expires, issuer name 2415 indicates the name of the authority that issued this certificate X. 509, subject name 2416 indicates to the holder of this certificate X. 509, public key 2417 indicates the public key of the subject name 2416 and signature value 242 indicates a value that has been signed (encrypted) with the private key of the issuer of this certificate X. 509. In this mode, this date and time of update 2413 and the following d date and time of update 2414 require date and time information, but it is The date and time of update 2413 and the following date and time of update 2414 do not always require information about the time. As a system that uses public keys and 0 private keys, public key encryption systems are widely used for electronic commerce and others. In a public-key encryption system, an encrypted text is decrypted with a key that is different from the key used to encrypt the text. Since the key to encryption and the key to decryption are different, it is impossible to calculate the key for encryption from the key for decryption. This key for encryption corresponds to the private key and this key for decryption corresponds to the public key. Representative examples of 0 public key encryption systems include RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Standard). File 2132 is a signature file. Figure 25 is a schematic diagram showing the file "ocap, signaturefile.1" 2132. 251 Indicates a certificate identifier to identify which X.509 certificate is related, 252 indicates a recast signature algorithm and 253 indicates a signature value that has been calculated from "hashfile ocap" 2140 by using the recast signature algorithm indicated at 252. Once a Java® program is stored in the secondary storage unit 510, it is possible to activate this Java® program without having to wait for the download as long as the AM 1205b has received the XAIT shown in figure 20, even in case the Java® program was deleted from the primary storage unit 511 due to causes such as channel change and switching off of the terminal apparatus 500. In other words, in figure 20, the control information 2002 of the program "/ a / xletl" is "auto start". Thus, in 2011 in Figure 21, when a search is made for storage location 2101 of the file system corresponding to "/ a / xletl" and then file 2150 is passed to VM 1203, the Java® program " xletl "stored in this file system is activated. Following are descriptions of processes carried out by the AM 1205b and the security administrator 1205f, which are main functions of the present invention, to authenticate a file system stored in the primary storage unit 511 and store the system of files authenticated on secondary storage unit 510.

The function of the AM 1205b is first described, the function of the security manager 1205f is described later and at the end the process flow carried out by the AM 1205b and the security administrator 1205f is described. First, AM 1205b is described. Figure 36 shows constituent elements of the AM 1205b for storing a file system stored in the primary storage unit 511 in the secondary storage unit 510. A file system comparison unit 3601 compares, when a newly downloaded Java® program is going to be stored, the "ocap. Storage" descriptions included in the "/" directory of the file system stored in the primary storage unit 511 with the "ocap. Storage" descriptions "included in the directory" / "stored in the secondary storage unit 510 in which the Java® program is to be stored. Then, the file system comparison unit 3601 extracts information from file lists indicating the files to be stored (hereinafter simply referred to as file list information), and passes, to a file system management unit 3602, a couple of the extracted file list information and the Java® 2001 program identifier. The file system management unit 3602 provides the file list information after a query of a file system storage unit 3603, by using the file list information passed from the file system comparison unit 3601. The file system storage unit 3603 makes a request to the file system management unit 3602 to obtain the file system 3602. file list information, and stores files from the primary storage unit 511 in the one secondary storage 510 based on this obtained file list information. For example, consider the following case: Figure 37 shows the details of the file list information based on "ocap. Storage" in the file system of a Java® program that has been stored in the secondary storage unit 510 after it is stored in the primary storage unit 511 at the time of the previous and authenticated download; and Figure 35 shows the details of the file list information based on "ocap. storage" in the file system of a Java® program that has been stored in the primary storage unit 511 by the download that has led to according to the XAIT information shown in FIG. 21. In this case, the file system comparison unit 3601 passes, to the file system management unit 3602, the first list information shown in FIG. 38 and FIG. the program identifier 2001 of the Java® program that has just been stored in the primary storage unit 511. As indicated in figure 38, shown in the file list information of figure 38 are files that are shown in the figure 37 but that are not shown in Figure 35 (ie, "/ a / c / ocap. Hashfile" and "/ a / c / sub. Class") as well as files that are shown in both figure 37 and figure 35 but whose version numbers are n different (ie, "/ ocap. hashfile "," / ocap. singaturefile. 1"," / a / ocap. hashfile "and" / a / xlet. class "), with the commonly displayed files in Figure 37 and Figure 35 not being described in the file list information of Figure 38. The file system management unit 3602 administers a pair of the 2001 program identifier of the Java® program and file list information, and the file system storage unit 3603 requests the filesystem management unit 3602 to be stored, in order to store files according to the list information of received files The following describes detailed processes carried out by the file system comparison unit 3601, the file system management unit 3602 and the file system storage unit 3603, when taking the case in which the Java® program defined in the 2011 line is going to be stored. Figure 39 is a flow chart showing the processing carried out by the file system comparison unit 3601. The file system comparison unit 3601 checks if there is an "ocap. Storage" that exists in the directory " / "of a file system stored in the primary storage unit 511 (Step S391). When "ocap. Storage" exists, the file system comparison unit 3601 generates file list information 351 based on the "ocap. Storage" descriptions stored in the primary storage unit 511 (Step S392). When "ocap. Storage" does not exist as a result of the revision carried out in Step S391, the processing is concluded in the present example, but it is also possible to move to Step S393 using the file list information 351 that includes ( i) a file name column 3511 that is generated with reference to the filesystem file structure stored in the primary storage unit 511 and (ii) a column of version numbers 3512 that is generated from a number of version 2006. Next, a file system comparison unit 3601 checks if there is "ocap. storage" that exists in the "/" directory stored in the secondary storage unit 510 in which the Java® program is stored. downloaded (in the present embodiment, a description is given of an example in which the Java® program shown in Figure 21 is replaced by the newly downloaded Java® program) (Step S393). When "ocap. Storage" exists, the file system comparison unit 3601 generates file list information 371 based on the "ocap. Storage" descriptions stored in the secondary storage unit 510 (Step S394). When "ocap. Storage" does not exist as a result of the revision carried out in Step S393, the processing is concluded in the present example, but it is also possible to move to Step S395 using the file list information 371 that includes ( i) a file name column 3711 that is generated with reference to the file system file structure stored in the secondary storage unit 510 and (ii) a column of version number 3712 that is generated from 1 which It is the smallest version number. Then, the file comparison unit 3601 compares the file list information 351 and the file list information 371 to extract a difference, and generates file list information 381 (Step S395). Finally, the file comparison unit 3601 passes, to the file management unit 3602, a pair of the Java® 2001 program identifier and the file list information 381 (Step S396). Fig. 40 is a flow chart showing the processing carried out by the file system management unit 3602. When it receives the Java® 2001 program identifier as well as a request about file list information (Step S401) , the file system management unit 3602 returns, to the inquisitor, the file list information 381 corresponding to the received Java® 2001 program identifier (Step S402). Figure 41 is a flow chart showing the processing carried out by the file system storage unit 3603. When it receives the Java® 2001 program identifier as well as a request to store the Java® program (Step S411), the file system storage unit 3603 obtains the file list information 381 corresponding to the Java® 2001 program identifier provided to the file system management unit 3602 (Step S412). After, the file system storage unit 3603 judges whether the file list information 381 has been obtained or not (Step S413). When it is judged that the file list information 381 has been obtained (yes in Step 413), the file system storage unit 3603 compares the d version number 2006 with each version number described in column 3812 of the file list information obtained 381, starting with the top line (Step S414). When the 2006 version number is larger (Step S415), the file storage unit of files 3603 erases a file stored in the secondary storage unit 510 corresponding to the file name described in column 3811 of the current line in the file list information 381. In an example shown in figure 38, two files "/ a / c / ocap. hashfile" and d "/ a / c / sub. class" (Step S416). When the 2006 version number is not larger, the file system storage unit 3603 judges whether the version number currently compared is equal to the version number 2006 (Step S417). When those version numbers are equal, the file system storage unit 3603 stores, in the secondary storage unit 510, a file stored in the primary storage unit 511 corresponding to the file name described in column 3811 of the current line in the first list of information 381 (Step S418). Note that "store a file" refers here to "overwrite a file" in case this file exists in the secondary storage unit 510, and refers to "store a file in addition" in case there is no file in the secondary storage unit 510. Note also that before the storage operation here, an authentication operation has been completed which will be described later. Finally, the file system storage unit 3603 judges whether the last line of the file list information has been reached or not (Step S419). When this is not the last line, file system storage unit 3603 returns to Step S414, while when it is the last line, processing is concluded. Note that another method can be used, as long as this method is capable of storing a file of a larger version and of deleting a file of an older version. Moreover, the above descriptions have been given by using version number 2006 and a version number described in column 3812 of the file list information 381 to distinguish between files of larger and older versions, but you can use another method as long as this method is able to distinguish between files of larger and older versions. The following is a description of the general operations carried out by security administrator 1205f. Assume, for example, that the security administrator 1205f receives, from the AM 1205b, a pre-storage notification indicating that the Java® program defined in the 2011 line is going to be stored. After receiving this notification, the security administrator 1205f checks the value of the Java® 2001 program identifier to judge whether it is an unsigned program or a signed program. Here, since the Java® program is a signed 0 program, the security administrator 1205f carries out the file system authentication lower than the "/" directory. To verify the file system, authentication is carried out by using the ocap. hashfile (2140 ~ 2142), the ocap. certificates. 1 (2131) and the 6 ocap. signature 1 (2132). Figure 26 shows the constituent elements of the security manager 1205f for carrying out the authentication of a file system. A notification receiving unit 261 is 0 intended to receive a pre-storage notification immediately before the AM 1205b is about to store a file system, as well as to notify this fact to a unit of judgment 262. The unit of judgment 262 judges a result of the authentication. Requests a recast calculation unit 263 to do recast calculations for the file system to receive recast values. The judgment unit 262 extracts from the recast values 2213 and 2223 that exist in the "ocap hashfile" file, a value that will be compared and checked if it coincides or not with the recast values received. If they do not coincide, the judgment unit 262 judges that there has been an alteration, and the authentication ends in failure. In addition, the judgment unit 262 extracts each of the X.509 certificates using a certificate extraction unit 265, and judges whether the current time is not earlier than this update date and time 2413 of each of the X certificates. 509 and not after the following date and time of update 2414 of each of the X. 509 certificates (call, the current time is between this date and time of update 2413 and the following date and time of update 2414 of each of the X. 509 certificates). The current date and time is obtained from the library 1201b of OS 1201. If the validity period does not satisfy "this date and time of update <The current date and time of the updating date and time ", the judgment unit 262 judges that the authentication is a failure, Moreover, in order to authenticate the chain of certificates, the judgment unit 262 requests the recast calculation unit 263 perform a recast calculation for the attribute area 241 of each of the X certificates. 509. Next, it asks for a signature value decryption unit 264 to carry out a calculation to decrypt the signature value 242 included in each one of the X.509 certificates, and compares the resulting cipher value with the recast values obtained by the recast calculation unit 263 to check the status of the certificate chain, if they do not match, it means that the certificates They are not in a chain relationship, and in this way the authentication is judged to be a failure.Meanwhile, when these values coincide and it has been verified that the certificates are n in a chain relation, it is checked whether the root certificate in the certificate chain is included in the secondary storage unit 510 of the terminal apparatus 500. If it is not included, the judgment unit 262 judges that the authentication is a failure , considering that it is impossible to carry out the comparison. The judgment unit 262 judges that the authentication is successful when all the following conditions are met: (1) there has been no alternation; (2) there is validity of the period; (3) that the certificates are in a chain relation and (4) that the root certificates coincide. When requested by the judgment unit 262 to calculate a recast value of each of the files, the calculation unit 263 extracts each of the files from library 1201b of OS 1201 to carry out recast calculations for them, and passes the resulting values to the judgment unit 262. In addition, the recast calculation unit 263 obtains each of the X.509 certificates in the certificate chain 231 that comes from the certificate extraction unit 265, and performs recast calculations for attribute area 241 of each of them. The judgment unit 262 requests the signature value decryption unit 264 to carry out a calculation to decrypt the signature value of either each X.509 certificate or "ocap. Signaturefile.x". When a calculation is performed to decrypt the signature of each X.509 certificate, the signature value decryption unit 264 obtains each of the X certificates. 509 in the certificate chain 231 of a certificate extraction unit 265 , and then performs a calculation to decrypt the signature of each of them, and returns the result to the judgment unit 262. The certificate extraction unit 265 is requested to extract each of the X.509 certificates in the chain of certificates 231 by the judgment unit 262, the recast calculation unit 263 and the signature value decryption unit 264, and extract and return the X. 509 certificates. Figure 27 is a flow chart summarizing a operation carried out by the security administrator 1205f when carrying out the authentication of a file system. Based on this flow chart, an explanation is given of the operation that will be carried out in case the file system has the configuration shown in figure 21. After receiving a notification of pre-storage for the system of files from the AM 1205b (Step S271), the security administrator 1205f performs an alteration check for the file system below the "/" directory of the upper level of the file system (Step S272). In the revision of alteration, it is verified, when comparing recast values, that there is no corruption or changes in the files that exist in each directory of the file system. Figure 29 and Figure 30 are detailed flow charts of Step S272. First, the security administrator 1205b obtains, from the file system management unit 3602, the file list information 381 that corresponds to the program identifier 2001 (Step S290). Then, the security manager 1205f focuses on the directory "/" in the file system (Step S291), and performs a comparison to judge whether the 381 file list information obtained includes a file that is included in the file. focused directory (Step S292). If the trial is that there is a file (yes in Step S293), the security administrator 1205f calculates the recast values of the "ocap. certificates. 1" and "ocap. storage" files, and the "a" directory (Step S294). The recast value of directory "a" is calculated from the file "/ a / ocap hashfile" 222.

Then, the security administrator 1205f compares each of the recast values calculated in Step S294 with each of the recast values described in 2213 of "/ ocap hashfile" (Step S295). In Step S296, if any of the calculated recast values differ from the recast values in 2213, the security administrator 1205f judges that there has been tampering (Step S299). Meanwhile, when all the calculated recast values coincide with the recast values at 2213, the security administrator 1205f proceeds to Step S297. If the trial is that there is no file (not in Step S293), the security administrator 1205f goes to Step S297. In Step S297, it is reviewed 'if there is a subdirectory for which a alteration revision has not been completed. In the current stage, the "a" directory exists as the subdirectory of the "/" directory. Therefore, a focus is placed on the "a" directory in order to carry out an alteration review for this one, such as Step S298, when a process equivalent to the one carried out for the "/" directory is carried out. . After the alteration review for the "a" directory is completed, an alteration check is then carried out for the "b" directory which is a subdirectory of the "a" directory. When alteration reviews for all directories have been completed, then a focus is placed on the "/" directory, and the process for Step S301 in Figure 30 is carried out. In Step S301, the certificate of origin 2313 is extracted from the file "/ ocap. Certificates. 1" 2131, which is the certificate chain 231. Then, in Step S302, the public key 2417 is taken out of the certificate of origin. extracted 2313. Subsequently, in Step S303, a recast value is calculated for the "ocap hashfile" file 221. Meanwhile, in Step S304, decryption is performed in the signature value 242 in the file " / ocap.sign filefile 1"2132, using the public key 2417 that exists in the certificate of origin 2313 in the file" / ocap.certificatefile.1"2131. In Step S305, it is checked whether the recast value calculated in the Step S303 is equal to the value obtained in Step S304 when deciphering the signature value. If these calculated values match, it is possible to judge that the file system lower than the "/" directory has not been violated (Step S306). Meanwhile, if the calculated values do not match, it is possible to judge that the file system has been violated (Step S307). Note that a description has been given for an example in which alteration revisions are carried out by starting with the top-level "/" directory towards the subdirectories in descending order, but the present invention is not limited thereto. Therefore, the processes can be carried out by starting with the lowest level directory to the top level directory in ascending order. Through the above processes, the result of Step S272 is obtained in Figure 27. In Step S273, when the result in Step S272 is "there has been tampering", the authentication is judged to have failed and a notification about this fact (Stage S279), after which the process is concluded. When the result of Step S272 is "there is no alteration", the process for Step S274 is executed. Next, with reference to Figure 31 to Figure 33, a detailed description of the authentication of certificate chains is given (Step S274). Assuming that a revision is first made for the intermediate certificate 2312 and the certificate of origin 2313, a flow chart for this is shown in figure 31. First, the intermediate certificate 2312 and the certificate of origin 2313 are extracted from the supply chain. certificates 231 (Step S311). From this extracted source certificate 2313, this date and time of update 2413, next date and time of update 2414 and the name of the emitter 2415 are extracted (Step S312). Of these, it is judged whether the current date and time is between this date and time of update 2413 and next date and time of update 2414 during which the certificate may remain valid (Step S313). If it is beyond the period during which the certificate may remain valid, the authentication of the certificate chain ends in failure (Step S319). Meanwhile, when judged to be within the valid period of the certificate, the subject name 2416 and the public key 2417 in the intermediate certificate 2312 are extracted (Step S314), and a comparison is made between the name of the subject 2416 of the intermediate certificate 2312 and the name of the issuer 2415 of the certificate of origin 2313 to judge whether the intermediate certificate 2312 and the certificate of origin 2313 are in a chain relation or not (Stage S315). If these certificates are not in a chain relation, the authentication of the certificate chain is a failure. Meanwhile, when there is a chain relationship between them, a recast value is calculated for the attribute area 241 in source certificate 2313 (Step S316). Moreover, the signature value 242 in the certificate of origin 2313 is decrypted with the public key 2417 of the intermediate certificate 2312 (Step S317). When Step S316 and Step S317 are completed, it is checked whether the recast value and the deciphered signature value obtained in the respective Steps coincide or not (Step S318). If they do not match, the authentication of the certificate chain ends in failure (Step S319). Then, a revision is made between the root certificate 2311 and the intermediate certificate 2312. Figure 32 is a flow chart showing this process. The root certificate 2311 and the intermediate certificate 2312 are extracted from the certificate chain 231 (Step S321), and a process that is equivalent to the revision carried out for the intermediate certificate 2312 and the certificate of origin 2313 is carried out for the root certificate 2311 and the intermediate certificate 2312 (Stage S322 ~ Stage S328). When judged in Step S328 that the values match, a revision is carried out only for the root certificate 2311. Figure 33 is a flow chart showing a revision that will be carried out only for the 2311 root certificate From the root certificate 2311 extracted in Step S321, this date and time of update 2413, next date and time of update 2414 and the name of emitter 2415 are extracted (Step S331). Of these, it is judged whether the current date and time is between this date and time of update 2413 and next date and time of update 2414 during which the certificate may remain valid (Step S332). If it is beyond the period during which the certificate can remain valid, the authentication of the certificate chain ends in failure. Meanwhile, when judged to be within the validity period of the certificate, a recast value for the attribute area 241 of the root certificate 2311 is calculated (Step S334). In addition, the signature value 242 in the root certificate 2311 is decrypted with the public key 2417 of the root certificate 2311 (Step S335). When Stage S334 and Step S335 are completed, it is checked whether the recast value and the deciphered signature value obtained in the respective Steps coincide or not (Step S336). If they match, the authentication of the certificate chain is successful (Step S337), while if they do not match, the authentication of the certificate chain ends in failure (Step S338). At this point, the process of Step S274 concludes. The process is carried out differently than Step S275 depending on the result of Step S274. When the result of Step S274 is "certificate chain authentication failed" the authentication is judged to have failed and a notification is made about this (Step S279), and then the file system authentication is concluded. Meanwhile, in case of "the authentication of the certificate chain was successful", the process of Step S276 is carried out. Then, the secondary storage unit 510 of the terminal apparatus 500 is scrutinized to find a certificate that is the same as the root certificate 2311 of the file "/ ocap.certify 1" 2119 (Step S276). When the same certificate is not present in the secondary storage unit 510, it is judged in the S277 hearth that the authentication of the certificate chain 231 is a fault, and a notification is made about this authentication failure (Step S279), after which the process is concluded. Meanwhile, when the root certificate 2311 is included, it is judged that the file system authentication is successful, and the AM 1205b is notified about this authentication success (Step S278). Referring to Figure 28, even if a pre-activation notification for a Java® program is received after (Step S281) the process is concluded without accomplishing anything. Finally, referring to Figure 42, a flow of processes carried out by the AM 1205b and the security administrator 1205f is described. When a Java® program is going to be stored, the AM 1205b requests the file system comparison unit 3601 to extract file list information. In response to this, the file system comparison unit 3601 performs processing according to a flow chart shown in Figure 39 (Step S421). Next, the AM 1205b requests the security administrator 1205f to authenticate the Java® program (an example authentication is the following: the authentication of a new file (including a file whose version has been updated) according to the extracted file list information revision of the "/ ocap hashfile" alteration of a recently downloaded Java® program (alteration review does not necessarily have to be carried out again as long as it has already been carried out when authenticating the previous file) and root authentication of the certificate file of a newly downloaded Java® program) (Step S422). The AM 1205b judges whether the authentication has failed or not (Step S423), and if the authentication has not failed (ie it is successful) (not in Step S423), the AM 1205b requests the file system storage unit 3603 store the Java® program. In response to this, the file system storage unit 3603 performs processing according to a flow chart shown in Figure 41 (Step S424). As described, when extracting a difference between a Java® program currently stored in the secondary storage unit 510 and a Java® program that will be newly stored, it is not necessary to authenticate and store the entire Java® program that will be stored. Moreover, if a Java® program is activated after a certain period of time, it is not necessary to carry out the authentication again at this time of activation, since the authentication has already been carried out in this file system immediately before it is stored. To be more specific, it is not necessary, at the time of the execution of a program, to carry out again an authentication that is the same as the authentication carried out at the time of storing the program, and only a root authentication, for example, can be carried out. Note that the file system storage unit 3603 is intended to store and delete a file that is different from any of the files included in a file system stored in the secondary storage unit 510 at the time of prior storage, without storing again a file that is the same as the files included in the file system stored in the secondary storage unit 510 at the time of previous storage. However, the file system storage unit 3603 can overwrite the same file with this different file without performing an authentication again.

Second Mode An explanation of a preferred embodiment of a cable television system according to the present invention is given with reference to the figures. Figure 1 is a block diagram showing the relationship between apparatuses that make up the cable system, which are a cable head 101, and three terminal apparatuses: a terminal apparatus there, a terminal apparatus B112 and a terminal apparatus C113 . In the present embodiment, three terminal apparatuses are connected to a cable head, but it is possible to carry out the present invention if an arbitrary number of terminal apparatuses are connected to the cable head. The cable head 101 transmits, to several terminal devices, transmission signals such as video, audio and data, and receives data transmitted from the terminal devices. To achieve this, bands of 0 frequency are divided to be used in the transmission of data between the cable head 101, and the terminal apparatus there, the terminal apparatus B112 and the terminal apparatus C113. Figure 2 is a table showing a table of divided frequency bands. There are approximately two types of frequency bands: Out of Band (which will be abbreviated as OOB) and In Band. A frequency band of 5-130 MHz is assigned to OOB to be used primarily for the exchange of data between the cable head 101 and the terminal apparatus there, the terminal apparatus B112 and the terminal apparatus C113. A band of frequencies of 130MHz ~ 864 MHz is assigned to In-Band to be used mainly for transmission channels that include video and audio. QPSK is used for OOB, while QAM64 is used for En Banda as modulation techniques. A detailed explanation of modulation techniques is omitted here, since they are publicly known techniques that are less related to the present invention. Figure 3 shows a more specific example of how the OOB frequency band is used. A frequency band of 70MH ~ 74MHz is used to transmit data from the cable head 101. In this case, all terminal devices There, the terminal apparatus B112 and the terminal apparatus C113 receive the same data from the same cable head 101 Meanwhile, a frequency band of 10.0MHz ~ 10.1MHz is used to transmit data from the terminal apparatus there to the cable head 101. A frequency band of 10. lMHz ~ 10.2MHz is used to transmit data from the terminal apparatus B112 at the cable head 101. A frequency band of 10.2MHz ~ 10.3MHz is used to transmit data from the terminal apparatus C113 to the cable head 101. Accordingly, it becomes possible to transmit unique data for each terminal apparatus to the head of the cable. cable 101 from the terminal apparatus there, the terminal apparatus B112 and the terminal apparatus C113. Figure 4 shows an exemplary use of the frequency band In Band. The frequency bands of 150 ~ 156MHz and 156 ~ 162MHz are assigned respectively to a television channel 1 and a television channel 2, and the subsequent frequencies are assigned to television channels at 6MHz intervals. 310 MHz and the subsequent frequencies are assigned to radio channels at 1 MHz intervals. Each of the above channels can be used for either analog transmission or digital transmission. In case of digital transmission, the data is transmitted in the transport packet format that complies with the MPEG2 specification, in which case the data intended for various data transmission systems can be transmitted, in addition to audio and video data. The cable head 101 is equipped with a QPSK modulation unit, a QAM modulation unit and the like in order to be able to transmit suitable transmission signals to the respective frequency scales. In addition, the cable head 101 is equipped with a demodulation unit QPSK to receive data from the terminal devices. Likewise, the cable head 101 is assumed to be further equipped with various devices related to the modulation units and the previous demodulation unit. Nevertheless, a detailed explanation of them is omitted here since the present invention is mainly related to the terminal devices. The terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113 receive and reproduce transmission signals transmitted from the cable head 101. Moreover, the terminal apparatus There, the terminal apparatus B112 and the terminal apparatus C113 transmit unique data for each terminal apparatus to the cable head 101. In the present embodiment, these three terminal devices must have the same configuration. Figure 5 is a block diagram showing a hardware configuration of each terminal apparatus. 500 It is a terminal apparatus, which is formed of a demodulation unit QAM 501, a demodulation unit QPSK 502, a modulation unit QPSK 503, a decoder TS 505, an audio decoder 506, a loudspeaker 507, a decoder video 508, a visual presenter 509, a secondary storage unit 510, a primary storage unit 511, a ROM 512, an input unit 513 and a CPU 514. In addition, a POD 504 may be attached or detached from the terminal apparatus 500 Figure 6 shows a thin television, which is an example of an external view of the terminal apparatus 500. The terminal apparatus may have a variety of configurations, but in the present embodiment, the terminal apparatus which is configured on the basis , OpenCable ™ and OCAP is described as an example. 601 It is a thin steel TV case, in which all the components of the terminal apparatus 500 except for the POD 504 are contained. 602 It is a visual presenter, which corresponds to the visual presenter or viewer 509 in Figure 5. 603 It is a front panel unit that is formed 0 of several buttons and which corresponds to the input unit 513 in Figure 5. 604 It is a signal input terminal to which a cable line is connected to transmit / receive signals to and from the cable head 101. The signal input terminal 6 is connected to the demodulation unit QAM 501, the signal unit. QPSK demodulation 502 and the QPSK modulation unit 503 shown in Figure 5. 605 It is a POD card corresponding to the POD 504 in Figure 5. The POD 504 is incorporated 0 independently of the terminal apparatus 500 and can be attached or detached from the apparatus terminal 500, as in the case of POD card 605 in figure 6. A detailed explanation of POD 504 is given below. 606 It is an insertion slot into which the POD 605 card is inserted.

Referring to Figure 5, the demodulation unit QAM 501 demodulates a signal that has been modulated by QAM and transmitted from the cable head 101, according to the tuning information including a frequency specified by the CPU 504, and passes the result to the POD 504. The demodulation unit QPSK 502 demodulates a signal that has been modulated by QPSK and transmitted from the cable head 101, according to tuning information including a frequency specified by the CPU 514, and passes the result to the POD 504. The QPSK modulation unit 503 demodulates by QPSK a signal passed from the POD 504, according to demodulation information including a frequency specified by the CPU 514 and transmits the result to the cable head 101. As shown in FIG. shown in Figure 6, the POD 504 can be detached from the main body of the terminal apparatus 500.

The definition of the connection interface between the main body of the terminal 500 and the POD 504 is given in the OpenCable® CableCARD® Interface Specification (OC-SP-CC-IF-115-031121) and in the specifications mentioned by this description. Note that CableCARD in this description refers to a POD. Here, a detailed description is omitted, and a detailed explanation is given only of the constituent elements relevant to the present invention.

Figure 7 is a block diagram showing an internal configuration of the POD 504. The POD 504 is formed of a first descrambling unit 701, a second descrambling unit 702, a scrambling unit 703, a primary storage unit 704, a scrambling unit secondary storage 705 and a CPU 706. The first descrambling unit 701 receives a scrambled signal from the demodulation unit QAM 501 under the instructions of the CPU 706 and descrambles this signal. Then, the first descrambler unit 701 transmits the descrambler signal to the TS 505 decoder of the terminal apparatus 500. The information required for the descrambler such as a key is provided by the CPU 706 according to the needs. More specifically, the cable head 101 transmits several payment channels, and when the user purchased the right to view these payment channels, the first descrambling unit 701 receives the required information such as a key from the CPU 706 and carries out desalination. As a result, the user can see these payment channels. When required information such as a key is not provided, the first descrambling unit 701 passes the received signal directly to the TS 505 decoder without performing descrambling.

The second descrambling unit 702 receives a scrambled signal from the demodulation signal QPSK 502 of the terminal apparatus 500 under the instructions from the CPU 706, and descrambles this signal. Then, the second descrambling unit 702 passes the descrambled data to the CPU 706. The scrambling unit 703 scrambles the data received from the CPU 706, under the instruction of the CPU 706, and sends the result to the modulation unit QPSK 503 of the apparatus terminal 500. The primary storage unit 704, a concrete constituent element of which is a primary memory such as a RAM, is intended to store data temporarily when the CPU 706 performs processing. The secondary storage unit 705, a concrete constituent element of which is a secondary storage memory such as a volatile ROM, is intended to store a program that will be executed by the CPU 706 as well as to store data that should never be erased. when the power goes off The CPU 706 executes the program stored in the secondary storage unit 705. The program consists of several subprograms. Figure 8 shows an example of the program stored in the secondary storage unit 705. In Figure 8, a program 800 is formed of several subprograms including a main program 801, an initialization subprogram 802, a network subprogram 803, a subprogram of reproduction 804 and a subprogram PPV 805. Here, PPV, which is an abbreviation of Payment by Event, refers to a service that allows the user to see a certain program such as a movie on a charge basis. When the user enters their personal identification number, the fact that the user has purchased the right to watch the program is notified to the head of cable 101, and the program is descrambled. Consequently, the user can see this program. This observation of the program requires the user to pay for the purchase at a later date. The main program 801, which is the subprogram activated by the CPU 706 first of all when the power is turned on, controls the other subprograms. The initialization subprogram 802, which is activated by the main program 801 when the power is turned on, performs exchange of information and the like with the terminal apparatus 500 to carry out the initialization processing. This initialization processing is defined in detail in the OpenCable® CableCARD® Interface Specification (OC-SP-CC-IF-115-031121) and in specifications mentioned by this description. Moreover, the initialization subprogram 802 also performs initialization processing not defined in this description. Here, a part of this initialization processing is introduced. When the power is turned on, the initialization subprogram 802 notifies the demodulation unit QPSK 502 of a first frequency stored in the secondary storage unit 705 by means of the CPU 514 of the terminal apparatus 500. The demodulation unit QPSK 502 leads to perform the tuning using the first frequency provided, and transmit the resulting signal to the secondary descrambler unit 702. In addition, the initialization subprogram 802 provides the secondary descrambler unit 702 descrambling information such as a first key stored in the secondary storage unit 705. As a result, the secondary descrambling unit 702 carries out descrambling and passes the result to the CPU 706 executing the initialization program 802. Accordingly, the initialization subprogram 802 can receive the information. In the present embodiment, the initialization subprogram 802 receives information through the network subprogram 803. A detailed description of this is given below. Moreover, the initialization subprogram 802 notifies the QPSK modulation unit 503 of a second frequency stored in the secondary storage unit 705 via the CPU 514 of the terminal apparatus 500. The initialization subprogram 802 provides the scrambling unit 703 with scrambling information d stored in the secondary storage unit 705. When the initialization subprogram 802 provides, via the network subprogram 803, to the scrambling unit 703 the information to be sent, the scrambling unit 703 scrambles the data using the 0 randomization data provided, and provides the randomized data to the QPSK modulation unit 503. The QPSK modulation unit 503 modulates the randomized information it received, and sends the modulated information to the cable head 101. As a result, it is makes it possible for the initialization subprogram 802 to carry out a communication bidirectional with the cable head 101 by means of the terminal apparatus 500, the second descrambler unit 702, the scrambler unit 703 and the network subprogram 803. The network subprogram 803, which is used by several subprograms such as the main program 801 and the initialization subprogram 802, is a subprogram intended to carry out bidirectional communication with the cable head 101. More specifically, the network subprogram 803 behaves as if other subprograms using the network subprogram 803 were carrying performed a bidirectional communication with the cable head 101 according to TCP / IP. A detailed explanation of TCP / IP is omitted here, since it is a publicly known technique that specifies the protocols that will be used when exchanging information between several terminals. When activated by the display subprogram 802 upon power up, the network subprogram 803 notifies, via the terminal apparatus 500, the cable head 101 of a MAC address (an abbreviation of Media Access Control) which is an identifier to identify the POD 504 and which is stored in the secondary storage unit 705 in advance, thus requesting the obtaining of an IP address. The cable head 101 notifies the POD 504 of the IP address via the terminal apparatus 500, and the network subprogram 803 stores this IP address in the primary storage unit 704. Thereafter, the cable head 101 and the POD 504 communicate with each other using this IP address as the identifier of the POD 504. The playback subprogram 804 provides the first descrambling unit 701 with descrambling information such as a second key stored in the secondary storage unit 705 as well as information from descrambling such as a third key provided by the terminal apparatus 500, to thereby enable descrambling to be carried out. Moreover, the playback subprogram 804 receives, via the network subprogram 803, information indicating that the signal input to the first descrambler unit 701 is a PPV channel. After the notification that the signal is a PPV channel, the playback subprogram 804 activates the PPV subprogram 805. When activated, the PPV subprogram 805 visually displays, on the terminal apparatus 500, a message indicating the user to buy the program, and accepts a user's income. More specifically, when the information that is desired to be presented on the screen is sent to the CPU 504 of the terminal apparatus 500, a program running on the CPU 504 of the terminal apparatus 500 shows the message on the visual presenter 509 of the apparatus terminal 500. Then, when the user enters the personal identification number by means of the input unit 513 of the terminal apparatus 500, the CPU 514 of the terminal apparatus 500 accepts it, and sends it to the PPV subprogram 805 running on the CPU 706 of the POD 504. The subprogram PPV 805 sends, at the head of cable 101, the personal identification number accepted by means of the network subprogram 803. When this personal identification number is valid, the cable head 101 notifies, by means of of the network subprogram 803, to the subprogram PPV 805 of the desalination information required to descramble "this fourth key." The subprogram PPV 805 provides the first desalination unit 701 descrambling information accepted as the fourth key, and then the first descrambling unit 101 descrambles the input signal. Referring to Figure 5, the TS 505 decoder performs the filtering of the signal it accepted from. POD 504, and passes necessary data to the audio decoder 506, the video decoder 508 and the CPU 514. Here, the signal sent from the POD 504 is a transport stream MPEG2. A detailed description about an MPEG2 transport stream is given in the MPEG ISO / IEC138181-1 specification, and is therefore not explained in detail in the present embodiment. An MPEG2 transport stream is composed of several fixed-length packets, and a packet ID is assigned to each packet. Figure 9 is a diagram showing the structure of a package. 900 It is a packet, which contains 188 bytes of fixed length. The upper four bytes are a header 901 that stores information to identify the packet, and the other 184 bytes is a payload 902 that stores information that is desired to be carried. 903 Shows the break of header 901. A packet ID is included in 13 bits from 1st through the 12th ~ 24th bit. Figure 10 is a schematic diagram illustrating several chains of packets that will be transmitted. A packet "1001 contains a packet ID" 1"in its header and includes the first video information A in its payload A packet 1002 contains a packet ID" 2"in its header and includes the first audio information A in its payload A packet 1003 contains a packet ID "3" in its header and includes the first audio information B in its payload A packet 1004 contains packet ID "1" in its header and includes the second video information A in your payload, which is the subsequent information of the packet 1001. Similarly, the packets 1005, 1026 and 1027 carry subsequent data of the other packets. By concatenating the contents of the payloads of the packets with the same packet IDs in the above manner, it is possible to play video and audio in successive order. Referring to Figure 10. When the CPU 514 indicates, to the TS 505 decoder, the packet ID "1" as well as the "video decoder 508" as an output destination, the TS 505 decoder extracts packets with the ID of 505. package "1" of the transport stream MPG2 received from the POD 504, and passes them to the video decoder 508. In figure 10, therefore, only the video data is passed to the video decoder 508. At the same time , when the CPU 514 indicates, to the TS 505 decoder, the packet ID "2" as well as the "audio decoder 506", the TS 505 decoder extracts packets with the packet ID "2" of the received MPEG2 transport stream. from the POD 504, and passes them to the audio decoder 506. In FIG. 10, only the audio data is passed to the video decoder 508. This processing of extracting only necessary packets according to the packet IDs corresponds to the filtering that will be carried out by the TS 505 decoder. E The TS 505 decoder is capable of carrying out more than one filtering processing simultaneously upon receipt of an instruction from the CPU 514. Referring to FIG. 5, the audio decoder 506 concatenates audio data embedded in the packets in the stream of MPEG2 transport provided by the TS 505 decoder, performs the digital to analog conversion in the concatenated data and sends the result to the loudspeaker 507. The loudspeaker 507 sends the signal provided by the audio decoder 506 as audio. The video decoder 508 concatenates video data inserted into the packets in the transport stream MPEG2 provided by the TS 505 decoder, performs the digital to analog conversion in the concatenated data and outputs the result to the visual presenter 509. The visual presenter 509, a particular constituent element of which is a CRT or a liquid crystal and the like, sends a video signal provided by the video decoder 508 and visually displays a message specified by the CPU 514, and so on. The secondary storage unit 510, concrete constituent elements of which are a volatile memory, a hard disk and the like, stores and erases data and programs specified by the CPU 514. The stored data and programs are referred by the CPU 514. The data and stored programs are kept under storage even while the terminal apparatus 500 is turned off. The primary storage unit 511, concrete constituent elements of which are a RAM and the like, temporarily stores data and programs specified by the CPU 514 and deletes them. The stored data and programs are referred by the CPU 514. The stored data and programs are deleted when the terminal apparatus 500 is turned off. The ROM 512 is a read-only memory device, concrete constituent elements of which are a ROM, a CD-ROM and a DVD, and the like. The ROM 512 stores a program that will be executed by the CPU 514. The input unit 513, concrete constituent elements of which are a front panel or a remote control, accepts an input from the user. Figure 11 shows an example of the input unit 513 in the case that it is configured in the form of a front panel. 1100 It is a front panel, which corresponds to the front panel unit 603 shown in figure 6. This front panel 1006 is formed of seven buttons: an upward cursor button 1101, downward cursor button 1102, a button cursor to the left 1103, a cursor button to the right 1104, an OK button 1105, a cancel button 1106 and an EPG 1107 button. When the user presses a button, the identifier of this button pressed is notified to the CPU 514. The CPU 514 executes the program stored in the ROM 512. According to instructions that come from this program that will be executed, the CPU 514 controls the demodulation unit QAM 501, the demodulation unit QPSK 502, the demodulation unit QPSK 503, the POD 504, the decoder TS 505, the visual presenter 509, the secondary storage unit 510, the primary storage unit 511 and the ROM 512. Figure 12 is a diagram showing an exemplary structure of the program that is stored in ROM 512 and executed by CPU 514. A program 1200 is formed of several subprograms. To be more specific, program 1200 is comprised of an OS 1201, an EPG 1202, a Java® VM 1203, a service manager 1204 and a Java Library Library 1205. OS 1201 is a subprogram that will be activated by the CPU 514 when the terminal apparatus 500 is turned on. OS 1201 is an abbreviation of OS, an example of which is Linux and the like. OS 1201 is a generic name for a publicly known apparatus in the art formed of a core 1201a for executing a program in parallel with another subprogram and a library 1201b, and therefore a detailed explanation is omitted. In the present embodiment, the core 1201a of OS 1201 executes EPG 1202 and JavaVM 1203 as subprograms. Meanwhile, the library 1201b provides these subprograms with plural functions required to control the constituent elements of the terminal apparatus 500. Here, a tuning is introduced as an example of these functions. With the tuning function, tuning information including a frequency is received from another subprogram and then passed to the demodulation unit QAM 501, consequently, it is possible for the demodulation unit QAM 501 to carry out the demodulation based on the provided tuning information, and pass the demodulated data to the POD 504. As a result, the other subprograms can control the demodulation unit QAM by means of the library 1201b. The EPG 1202 is formed of a program display unit 1202a for visually displaying a list of programs to the user as well as for accepting an input from the user, and a playback unit 1102b for selecting channels. Here, EPG is an abbreviation of Electric Program Guide. The EPG 1202 is activated when the terminal apparatus 500 is turned on. In the activated EPG 1202, the program presentation unit 1202a expects input from the user via the input unit 513 of the terminal apparatus 500. Here, in case the input unit 513 has the shape of the front panel illustrated in Figure 11, when the user presses the EPG button 1107 on the input unit 513, the CPU 514 is notified of the identifier of this EPG button. The program display unit 1202a of the EPG 1202, which is a subprogram running on the CPU 514, accepts this identifier, and displays program information on the visual presenter 509. Figure 13A and Figure 13B show examples of a program table displayed on the visual presenter 509. See Figure 13A. The program information is presented visually on the visual presenter 509 in a grid pattern. A column 1301 describes the time information. A column 1302 describes a channel name "channel .1" and programs that will be transmitted during periods of time corresponding to the respective hours described in column 1301. It is shown that a "News 9" program is transmitted from 9:00 a.m. 10:30, and "Cinema AAA" is broadcast from 10:30 to 12:00 on "Channel 1". A column 1303 describes a channel name "Channel 2" and programs that will be transmitted during periods of time corresponding to the respective hours described in column 1301, as in the case of column 1302. A "Cinema BBB" program is broadcast from 9:00 to 11:00, and "News 11" is broadcast from 11:00 to 12:00. 1330 It is a cursor. The cursor 1130 moves by pressing the left cursor 1103 or the right cursor 1104 on the front panel 1100. When the cursor to the right 1104 is pressed in the state illustrated in FIG. 13A, the cursor 1130 moves to the right as shown in FIG. shown in Figure 13B. Meanwhile, when the left-hand cursor 1103 is pressed in the state illustrated in FIG. 13B, the cursor 1330 moves to the left as shown in FIG. 13A. When the OK button 1105 on the front panel 1100 is pressed in the state shown in FIG. 13A, the program display unit 1202a notifies the playback unit 1102b of the identifier of "Channel 1". Meanwhile, when the OK button 1105 on the front panel 1100 is pressed in the state shown in FIG. 13B, the program display unit 1202a notifies the playback unit 1102b of the identifier of "Channel 2". Moreover, the program display unit 1202a periodically stores program information that will be displayed visually from the cable head 101 in the primary storage unit 511 via the POD 504. Generally, it takes time to obtain program information from the head. of cable. However, it becomes possible to visually display a program table quickly by visually displaying the program information that is pre-stored in the primary storage unit 511 by pressing the EPG button 1107 of the input unit 513. The playback unit 1102b reproduces the channel using the identifier received from the channel. The relationship between channel identifiers and channels is pre-stored by the secondary storage unit 510 as channel information. Figure 14 shows an example of the channel information stored in the secondary storage unit 510. The channel information is stored in tabular form. A column 1401 describes the channel identifiers. A column 1402 describes channel names. A column 1403 describes tuning information. Here, the tuning information is represented by values that will be provided to the demodulation unit QAM 501 such as frequency, transmission rate and coding ratio. A column 1404 describes program numbers. Program numbers are numbers used to identify PMTs defined by the MPEG2 standard. A description about PMT is given below. Each of the lines 1411 ~ 1414 indicates a set of the indicator, channel name and tuning information of each channel. Line 1411 describes a set that includes "1" as an identifier, "Channel 1" as a channel name, a frequency of "312MHz" as tuning information and "101" as a program number. The reproduction unit 1102b passes the identifier of the received channel directly to the service manager in order to reproduce the channel in this way. Moreover, when the user presses the upward cursor 1101 and the downward cursor 1102 on the front panel 1100 while the reproduction is taking place, the reproduction unit 1102b receives a notification about this oppression by the user of the input unit. 513 by means of the CPU 514, and changes the channel that is being played by another. First, the playback unit 1102b stores, in the primary storage unit 511, the identifier of the channel that is currently playing. Figures 15A, 15B and 15C show exemplary identifiers of channels stored in the primary storage unit 511. Figure 15A shows that an identifier "3" is stored, and this is shown by referring to Figure 14 that a channel with the Channel name "TV 3" is being played. When the user presses the cursor upwards 1101 in a state illustrated in figure 15A, the reproduction unit 1102b refers to the channel information shown in figure 14, and passes the identifier "2" of a channel with the channel name of "Channel 2" to the service manager in order to reproduce again a channel with the channel name "Channel 2", which is the previous channel in the table. At the same time, the reproduction unit 1102b rewrites the identifier in the channel identifier "2" stored in the primary storage unit 511. Figure 15B shows this rewritten channel identifier. Meanwhile, when the user presses the downward cursor 1102 in the state illustrated in FIG. 15A, the playback unit 1102b refers to the channel information shown in FIG. 14, and passes the identifier "4" of a channel with the channel name "TV Japan" to the service manager in order to play a channel with the channel name "TV Japan" again, which is the next channel in the table. At the same time, the reproduction unit 1102b rewrites the identifier in the channel identifier "4" stored in the primary storage unit 511. Figure 15C shows this rewritten channel identifier. The JavaVM 1203 is a Java virtual machine that sequentially analyzes and executes programs written in the Java® language. The programs written in the Java language are compiled in intermediate codes known as byte codes which do not depend on hardware. The Java virtual machine is an interpreter that executes these byte codes. Some of the Java virtual machines translate the byte codes into an executable form that can be interpreted by the CPU 514 and pass the result to the CPU 514, which executes them. The JavaVM 1203 is activated, with a Java program that will be executed being specified by the kernel 1201a. In the present embodiment, the core 1201a specifies the service manager 1204 as a Java program that will be executed. A detailed commentary on the Java language is given in many books that include "Java Language Specification" (ISBN 0-201-63451-1). Therefore, a detailed description about this is omitted here. Also, a detailed commentary on the operation of the Java VM itself is given in many books that include "Java Virtual Machine Specification" (ISBN 0-201-73451-X). Therefore, a detailed description of this is omitted here. Service manager 1204, which is a Java program written in the Java language, is executed by JavaVM 1203 sequentially. It is possible that the service manager 1204 calls and is called by another subprogram not written in the Java language through JNI (Java Native Interface). A comment on the NYI is given in many books that include "Java Native Interface". Therefore, a detailed description about this is omitted here. The service manager 1204 accepts the identifier of the channel that comes from the reproduction unit 1102b through the JNI. First, the service manager 1204 passes the channel identifier to a Tuner 1205c in the Java library 1205 to request tuning. The Tuner 1205 refers to the channel information stored in the secondary storage unit 510 to obtain the tuning information. Assuming that the service manager 1204 passes the identifier "2" of the channel to the tuner 1205c, the tuner 1205c refers to the column 1412 shown in figure 14, and obtains the tuning information "156MHz", which corresponds to the channel. The Tuner 1205c passes the tuning information to the demodulation unit QAM 501 by means of the library 1201b of the OS 1201. The demodulation unit QAM 501 demodulates the signal sent from the cable head 101 according to the tuning information given to the demodulation unit QAM 501, and pass the resulting signal to the POD 504. After, the service administrator 1204 requests a CA 1205b within the Java library 1205 to carry out descrambling. The CA 1205d provides the POD 504 with information required for descrambling through the library 1201b in the OS 1201. Based on this provided information, the POD 504 descrambles the signal provided by the demodulation unit QAM 501, and passes the resulting signal to the TS 505 decoder. Then, the service manager 1204 provides a JMF 1205a within the Java library 1205 with the identifier of the channel, to request the reproduction of the video and audio. First, the JMF 1205a obtains, from a PAT and a PMT, packet IDs used to specify the video and audio that will be played. PAT and PMT are tables defined by the MPEG-2 standard that show the alignment of programs included in an MPEG2 transport stream. PAT and PMT are carried on payloads in packages included in an MPEG2 transport stream, along with audio and video. Refer to the specification for a detailed description of PAT and PMT. Here, only a general description of PAT and PMT is given. PAT, which is an abbreviation of Program Association Table, is carried in packages with the package ID "0". To obtain the PAT, the JMF 1205a indicates, to the TS 505 decoder, the packet ID "0" and the CPU 514 through the library 1201b of the OS 1201. Then, the TS 505 decoder carries out the filtering based on the packet ID "0", and passes the result to the CPU 514. Accordingly, the JMF 1205a can collect the PAT packets. Figure 16 illustrates a table schematically showing an example of the PAT information collected. A column 1601 describes program numbers. A column 1602 describes packet IDs. The packet IDs shown in column 1602 are used to obtain the PAT. Each of lines 1611 ~ 1613 is a pair of program number of a channel and a packet ID corresponding thereto. Here, three channels are defined. Line 1611 defines a pair of program number "101" and packet ID "501". Assuming that the channel identifier provided to JMF 1205a was "2", JMF 1205a refers to column 1412 in Figure 14, to obtain the program number "102" that corresponds to this channel identifier, and then refers to line 1612 in the PAT shown in Figure 16, so as to obtain packet ID "502" which corresponds to program number "102". PMT, which is an abbreviation of Program Map Table, is carried in packages with the package IDs specified in the PAT. In order to obtain the PMT, the JMF 1205a indicates, to the TS 505 decoder, a packet ID and to the CPU 514 through the library 1201b of the OS 1201. Here, a packet ID that will be specified is "502". Then, the TS 505 decoder performs the filtering based on the packet ID "502", and passes the result to the CPU 514. Accordingly, the JMF 1205a can collect the PMT packets. Figure 17 illustrates a table schematically showing an example of the collected PMT information. A column 1701 describes current types. A column 1702 describes packet IDs. The information specified in the respective current types is carried in the payloads of packets with the packet IDs specified in column 1702. A column 1703 describes additional information. Each of the lines 1711 ~ 1714 is a pair of a packet ID and the type of information that is being transmitted, which is known as an elementary stream. Line 1711, which is a pair of the "audio" stream type and packet ID "5011", indicates that audio data is stored in the payload of the packet with packet ID "5011". The JMF 1205a obtains, from the PMT, the packet IDs of the video and audio that will be reproduced. Referring to Figure 17, JMF 1205a obtains audio packet ID "5011" from line 1711, and the video packet ID "5012" of the line 1712. Next, the JMF 1205a provides the TS 505 decoder with the pairs of the audio packet IDs obtained and the audio decoder 506 as an output destination as well as the Video packet ID and video decoder 508 as an output destination, through library 1201b of OS 1201. The TS 505 decoder performs filtering based on these provided packet IDs and output destinations. Here, the package with the packet ID "5011" is passed to the audio decoder 506 and the packet with the packet ID "5012" is passed to the video decoder 508. The audio decoder 506 performs the digital conversion to analogous in the package provided, in order to reproduce the audio by means of the loudspeaker 507. The video decoder 508 performs the digital to analogous conversion in the package provided, in order to present the video on the visual presenter 509. Finally, the service administrator 1204 provides the channel identifier to an AM 1205b in the Java library 1205, in order to request the reproduction of the data transmission. Here, reproduction of the data transmission means extracting a Java program included in the MPEG2 transport stream and causing the JavaVM 1203 to execute it. As a technique for inserting a Java program into an MPEG2 transport stream, a method known as DSMCC is used, which is described in the MPEG ISO / IEC138181-6 specification. A detailed explanation of DSMCC is omitted here. The DSMCC specification defines a method for coding a file system comprising directories and files used by a computer, in packets within an MPEG2 transport stream. The information about the Java program that will be executed is carried in packets in the MPEG2 transport stream in the form of AIT. AIT is an abbreviation of Application Information Table whose definition is given in chapter ten of the DVB-MHP standard (formally known as ETSI TS 101 812 DVB-MHP specification VI.0.2). First, to obtain the AIT, the AM 1205b obtains the PAT and PMT as in the case of the JMF 1205a, to obtain the packet ID of the package stored by the AIT. Assuming that "2" was the channel identifier provided and that the PAT shown in Figure 16 and the PMT shown in Figure 17 were being transmitted, the AM 1205b obtains the PMT shown in Figure 17 according to the same procedure followed for the JMF 1205a. Subsequently, AM 1205b extracts, from the PMT, the packet ID of the elementary current whose current type is "Data" and which has "AIT" as additional information. As shown in Fig. 17, the elementary current on line 1713 corresponds to this elementary stream, and therefore AM 1205b obtains packet ID "5013" thereof. The AM 1205b provides the TS 505 decoder with the packet ID of the AIT and the CPU 514 as an output destination through the library 1201b of the OS 1201. Then, the TS 505 decoder carries out the filtering based on this ID of package provided, and passes the result to the CPU 514. Accordingly, the AM 1205b can collect the d AIT packets. Figure 18 is a table schematically showing an example of the AIT information collected. A column 1801 describes identifiers of Java programs. According to the MHP specification, these identifiers are defined as Application IDs, which identify whether 0 a Java program is a program that must be authenticated by a security administrator 1205f of the terminal apparatus 500. Authentication is not required when the value of an identifier is on the scale of 0x0 to 0x3fff, while an authentication is required when the value of a d identifier is on the scale of 0x4000 to 0x7fff. A Java program whose identifier value is within the above scale is referred to as an "unsigned program" and a Java program whose identifier value is within the last scale is referred to as a "signed program". A 0 column 1802 describes control information for controlling Java programs. The control information includes "auto start", "present" and "eliminate". "Auto start" means that the terminal apparatus 500 automatically executes the program quickly. "Present" means that the program is not executed automatically. "Delete" means that the program will be terminated. A column 1803 describes DSMCC identifiers used to extract packet IDs that include Java programs in the DSMCC format. A column 1804 describes program names of Java programs. Each of lines 1811 and 1812 is a set of information about a Java program. The Java program defined in line 1811 is a set of an identifier "301", control information "auto start", a DSMCC identifier "1", and a program name "a / TopXlet". The Java program defined in line 1812 is a set of an identifier "302", control information "present", a DSMCC identifier "1" and a program name "b / GameXlet". Here, these two Java programs have the same DSMCC identifier. This indicates that two Java programs are included in the file system which has been encoded according to the same DSMCC method. Here, only four pieces of information are specified for the respective Java programs, but more pieces of information are actually specified. Refer to the DVB-MHP specification for details. The AM 1205b finds the Java program "autoinicio" of the AIT, and extracts the corresponding DSMCC identifier and the name of the Java program. Referring to Figure 18, the AM 1205b extracts the Java program on line 1811, and obtains the DSMCC identifier "1" and the Java program name "a / TopXlet". Then, the AM 1205b obtains, from the PMT, the packet ID of packets that store Java programs in the DSMCC format, using the DSMCC identifier obtained from the AIT. More specifically, the AM 1205b obtains, from the PMT, the packet ID included in the elementary stream whose current type is "Data" and whose DSMCC identifier in the additional information matches. Here, assuming that this DSMCC identifier is "1" and the PMT is that shown in Figure 17, the elementary stream on line 1714 satisfies the previous condition. Therefore, packet ID "5014" will be extracted. The AM 1205b indicates, to the TS 505 decoder, the package packet ID in which data is inserted in the DSMCC format as well as the CPU 514 as an output destination through the library 1201b of the OS 1201. Here, the ID of package "5014" is provided. Then, the TS 505 decoder performs filtering based on the provided packet ID, and passes the result to the CPU 514. Accordingly, the AM 1205b can collect the required packets. The AM 1205b reconstructs the file system from the packets collected in accordance with the DSMCC method, and stores the reconstructed file system in the primary storage unit 511. The process for extracting data such as the packet file system in the MPEG2 transport stream and store the extracted data in storage units such as the primary storage unit 511 is hereinafter referred to as download. 5 Figure 19 shows an example of the file system downloaded. In the diagram, circles represent directories and squares represent files, where 1901 is a root directory, 1902 is a "a" directory, 1903 is a "b" directory, 1904 is a "TopXlet. 0 class" file, and 1905 is a "GameXlet. class" file. Subsequently, the AM 1205b passes, to the JavaVM 1203, a Java program that will be executed outside the file system downloaded to the primary storage unit 511. Here, assuming that the name of the Java program that d will be executed is "a / TopXlet ", a file" a / TopXlet. class "that resulted from attaching". class "to the previous Java program is a file that will be executed. "/" is a delimiter between a directory and a file name, and as shown in figure 19, the file 1904 is a Java program that will be 0 executed. Then, the AM 1205b passes the file 1904 to the JavaVM 1203 since the column 1801 that describes the Java program identifier indicates unsigned program, meaning that there is no need to request the security administrator 1205f to carry out the authentication of this program Java.

The JavaVM 1203 executes this received Java program. After receiving the identifier of another channel, the service administrator 1204 terminates the video and audio reproduction as well as the execution of the Java program that is being carried out through each library included in the Java 1205 library, through each library included in the same Java 1205 library, and then performs video and audio playback as well as running a Java program based on the newly received channel identifier. The Java library 1205 is a collection of several Java libraries stored in ROM 512. In this mode, the Java 1205 library includes the JMF 1205a, the AM 1205b, the Tuner 1205c, the CA 1205d, a POD Lib 1205e, the administrator security 1205f, a download module 1206, and the like. The service manager 1204 and the download module 1206 perform bidirectional communication with the cable head 101 via the POD Lib 1205e included in the Java library 1205. This bidirectional communication can be achieved by the POD Lib 1205e using the QPSK demodulation unit 502 and QPSK modulation unit 503 via library 1201b of OS 1201 and POD 504. Download module 1206 can receive code data from cable head 101 through this communication. Code data refers to binary data including an X.509 certificate and / or firmware of the terminal apparatus 500. FIG. 50 is a schematic diagram showing d code data describing only a part related to the present invention. When it receives data of code 5000, the download module 1206 extracts a root certificate 5001 if it is included, and passes it to the security administrator 1205f. 5002 Indicates other data 0 such as firmware. The AM 1205b receives, from the cable head 101, information about Java programs that the terminal apparatus 500 must store in the secondary storage unit 510. This information is referred to as XAIT information. The XAIT information is transmitted between the cable head 101 and the POD 504 in an arbitrary manner. The present invention can be carried out regardless of the transmission format, provided that required information is included as XAIT. Figure 43 illustrates a table schematically showing an example of the XAIT information obtained from the cable head 101. A column 4301 describes the identifiers of Java programs. A column 4302 describes control information for controlling Java programs. The control information includes "auto start" and "present".

"Auto start" means that the program is executed automatically when the terminal apparatus 500 is turned on, and "present" means that the program will not be executed automatically. A column 4303 describes DSMCC identifiers used to extract packet IDs that include Java programs in the DSMCC format. A column 4304 describes the program name of the Java programs. A column 4305 describes the priorities of Java programs. Each of the lines 4311 and 4312 is a set of information about the respective Java programs. The Java program defined in line 4311 is a set of an identifier "0x7001", control information "autoinicio", a DSMCC identifier "1" and a program name "a / PPVlXlet". It can be known from your Java Program Application ID that this Java program is a signed program. Here, only five pieces of information are specified for the respective Java programs, but the present invention can be carried out even when more pieces of information are defined. After receiving the XAIT information, the AM 1205b stores the file system that comes from the MPEG2 transport stream in the primary storage unit 511, according to the same procedure as that to download the Java program from the AIT information . After that, the AM 1205b carries out a pre-storage notification to the security administrator 1205f immediately before it stores the file system in the secondary storage unit 510. At this time, an authentication operation is initiated by the security administrator 1205f according to the present invention, but its details are described below. After the notification of the security administrator 1205f that the activation is enabled, the AM 1205b stores the file system in the secondary storage unit 510. Then, the AM 1205b stores, in the secondary storage unit 510, the result of associate the XAIT information with a storage position of the downloaded file system. Figure 44 shows an example of the XAIT information and the downloaded file system stored in the secondary storage unit 510 in association with one another. Here, a file defined in the OCAP specification is described as an example. The elements of figure 44 which are the same as those of figure 43 are the same to each other, and therefore an explanation of these elements is omitted. A 4401 column stores the storage position of the downloaded file system. In the drawing, these storage positions are indicated by arrows. 4410 Is the file system downloaded, in which a top directory 4411, a directory "a" 4412, a directory "b" 4413, a file "PPVlXlet. Class" 4414, a file "PPV2Xlet. Class" 4415, files "ocap. hashfile" 4416 ~ 4418, a file "ocap certify yourself." 1 4419 and a file "ocap. signaturefile. 1" 4420 are included. The 4416 ~ 4418 files are recast files in which file names or directory names and the corresponding recast values are included. Figures 45A, 45B and 45C are schematic diagrams showing the details of "ocap hashfiles". 451 In figure 45A it shows "hashfile ocap" 4416, 452 in figure 45B shows "hashfile ocap" 4417 and 453 in figure 45C shows "hashfile ocap" 4418. "hashfile ocap" of 451, which exists in the directory "/" 4411, includes, in column 4511, an "ocap certify yourself 1" 4419 file, an "ocap file signaturefile.1" 4420, a directory "a" 4412 and a directory "b" 4413 that exist in the same directory 4411. A column 4512 indicates which recast algorithm was used to calculate each value described in a column 4513. Column 4513, which refers to the files or directories in column 4511, includes values of recast that were calculated using the recast algorithm specified in column 4512. Currently, recast algorithms that are used mainly are SHAl (Secure Recast Algorithm 1) and MD5 (Compendium of Messages 5). These are publicly known algorithms for converting data with an arbitrary length into a fixed-length byte value, which has the following characteristics: it is impossible to predict the original data after it is converted and is used to check if a file has been destroyed or altered. Meanwhile, a recast value is a pseudo random number that is generated by the use of a recast algorithm. When a recast algorithm is SHAl, the length of a recast value is 20 bytes, whereas when a recast algorithm is MD5, the length of a recast value becomes 16 bytes. For details about SHAl and MD5, refer to the standard "FIPS-PUB 186-2 Secure Standard Hash" and "IETF RFC1321", respectively. Here, the recast values corresponding to the respective "a" and "b" directories described in column 4511 are recast values SHAl that have been calculated respectively for the "hashfile ocap" file 4417 that exists in the "a" directory "and the file" ocap. hashfile "4418 that exists in the" b "directory. As in the case of "ocap hashfile" in 451, "ocap. hashfile" in 452 includes the file name, recast algorithm, and recast value of a file "PPVlXlet.class" 4414 that exists in the same directory 4412. Similarly, the file name is included in 453 , recast algorithm and recast value of a file "PPV2Xlet.class" 4415 that exists in the same directory 4413. Here, only the attributes that are related to the present invention are described, and in this way the specification of the OCAP " OpenCable® Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAP1, O-IF-109-031121) "should be referred to for details about" ocap. hashfile. "A file 4419 is a chain of certificates, Figure 23 is a diagram that shows a detailed structure of the file" ocap. get certified 1"4419. 231, which illustrates a typical structure of" ocap. certify yourself, x "(x is a positive integer), contains a root certificate 2311, an intermediate certificate 2312 and a certificate of origin 2313. They are in a chain relation in which the holder of the root certificate 2311 issues the intermediate certificate 2312 and the holder of the intermediate certificate 2312 issues the certificate of origin 2313. For example, note that according to the OCAP specification, a chain of certificates related to a signature file "ocap. signaturefile x "is" ocap. certify yourself, x "that has the same value" x. "In the case of figure 44, a chain of certificates corresponding to" ocap. signaturefile 1"is the" ocap. get certified 1. "Also, the root certificate 2311, the intermediate certificate 2312 and the certificate of origin 2313 are configured in the same X.509 certificate format. The X.509 certificates are widely used in various fields of the information industry and communications as a de facto standard for certificate representation format, as a recommendation of the ITU-T In Figure 23, only three certificates are illustrated, but there is a case in which there is a plurality of intermediate certificates. in this case these intermediate certificates must be in a chain state in which they are related to each other Figure 24 is a diagram showing the structure of an X. 509 certificate. Here, only the attributes required for Explain the present invention For details about X.509 certificates, refer to IETF RFC3280"Internet X, 509 Public Key Infrastructure Certify and CRL Profile". attribute area of the X. 509 certificate and 242 indicates the signature value of the X certificate. 509. The serial number 2411 indicates the number to identify the certificate, signature algorithm 2412 indicates the algorithm used to determine the signature value 242, this update date and time 2413 indicates the date and time at which this X. 509 certificate is valid, next update date and time 2414 indicates the date and time at which this X. 509 certificate expires, issuer name 2415 indicates the name of the authority that issued this certificate X. 509, subject name 2416 indicates to the holder of this certificate X. 509, public key 2417 indicates the public key of the subject name 2416 and signature value 242 indicates a value that has been signed (encrypted) with the private key of the issuer of this certificate X. 509. In this mode, this date and time of update 2413 and the following date and time of update 2414 require date and time information, but this Date and time of update 2413 and the following date and time of update 2414 do not always require information about the time. As a system that uses public keys and private keys, public key encryption systems are widely used for electronic commerce and others. In a public-key encryption system, an encrypted text is decrypted with a key that is different from the key used to encrypt the text. Since the key to encryption and the key to decryption are different, it is impossible to calculate the key for encryption from the key for decryption. This key for encryption corresponds to the private key and this key for decryption corresponds to the public key. Representative examples of public key encryption systems include RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Standard). File 4420 is a file of signatures. Figure 25 is a schematic diagram showing the file "ocap. signaturefile 1"4420. 251 Indicates a certificate identifier to identify which X. 509 certificate is related, 252 indicates a recast signature algorithm and 253 indicates a signature value that has been calculated from "hashfile ocap" 4416 by using the recast signature algorithm indicated at 252. Once a Java program is stored in the secondary storage unit 510, it is possible to activate this Java program without having to wait for the download as long as the AM 1205b has received the XAIT shown in figure 20, even in case the Java program was deleted from the unit. primary storage 511 due to causes such as changing the channel and switching off the terminal apparatus 500. In other words, in figure 43, the control information 4302 of the program "/ a / PPVlXlet" is "self-start". Thus, at 4311 in Figure 44, when a search is made for storage position 4401 of the file system corresponding to "/ a / PPVlXlet" and then file 4414 is passed to JavaVM 1203, the Java program "PPVlXlet "stored in this file system is activated. Next, a description of the security manager 1205f is given which is a main functionality of the present invention. Security administrator 1205f receives, from service manager 1204, a pre-storage notification indicating that "/ a / PPVlXlet" and "/ b / PPVXlet2" indicated at 4304 in Figure 43 are about to be stored. After receiving this notification, the security administrator 1205f checks the value of the Java program identifier 4301 to judge whether it is an unsigned program or a signed program. Here, since the Java program is a signed program, the security administrator 1205f carries out the file system authentication lower than the "/" directory. To verify the file system, authentication is carried out through the use of the ocap. hashfiles (4416 ~ 4418), the ocap. get certified 1 (4419) and the ocap. signaturefile 1 (4420) illustrated in figure 44. Figure 26 shows the constituent elements of the security manager 1205f for carrying out the authentication of a file system. A notification receiving unit 261 is intended to receive a pre-storage notification immediately before the AM 1205b is about to store a file system, as well as to report this fact to a judgment unit 262. The unit of judgment 262 judges a result of the authentication. Requests a recast calculation unit 263 to do recast calculations for the file system to receive recast values. The judgment unit 262- extracts from the remelting values 4513, 4523 and 4533 that exist in the file "ocap hashfile", a value that will be compared and checked if it coincides or not with the recast values received. If they do not coincide, the judgment unit 262 judges that there has been an alteration, and the authentication ends in failure. In addition, the judgment unit 262 extracts each of the X.509 certificates using a certificate extraction unit 265, and judges whether the current time is not earlier than this update date and time 2413 of each of the X certificates. 509 and not after the following date and time of update 2414 of each of the X. 509 certificates (call, the current time is between this date and time of update 2413 and the following date and time of update 2414 of each of the X. 509 certificates). The current date and time is obtained from the 1201b library of OS 1201. If the validity period does not satisfy "this date and time of update < current date &time < following date and time of update", the unit of judgment 262 judges that the authentication is a failure. Furthermore, in order to authenticate the certificate chain, the judgment unit 262 requests the recast calculation unit 263 to carry out a recast calculation for the attribute area 241 of each of the X certificates. 509. Next, calls for a signature value decryption unit 264 to carry out a calculation to decrypt the signature value 242 included in each of the X.509 certificates, and compares the resulting cipher value with the recast values obtained by the unit of calculation of recast values 263 to check the status of the certificate chain. If they do not match, it means that the certificates are not in a chain relation, and in this way the authentication is judged to be a failure. Meanwhile, when these values coincide and 'it has been verified that the certificates are in a chain relation, it is checked whether the root certificate in the certificate chain is included in the secondary storage unit 510 of the terminal apparatus 500. If it is not included, the judgment unit 262 judge that the authentication is a failure, considering that it is impossible to carry out the comparison. The judgment unit 262 judges that the authentication is successful when all the following conditions are met: (1) there has been no alternation; (2) there is validity of the period; (3) that the certificates are in a chain relation and (4) that the root certificates coincide. When requested by the judgment unit 262 to calculate a recast value of each of the files, the calculation unit 263 extracts each of the files from library 1201b of OS 1201 to carry out recast calculations for them, and passes the resulting values to the judgment unit 262. In addition, the recast calculation unit 263 obtains each of the X.509 certificates in the certificate chain 231 that comes from the certificate extraction unit 265, and performs recast calculations for attribute area 241 of each of them. The judgment unit 262 requests the signature decryption unit 264 to carry out a calculation to decipher the signature value of either each X.509 certificate or "ocap.signfilefile.x". When a calculation is carried out to decrypt the signature of each X certificate 509, the signature value decryption unit 264 obtains each of the X.509 certificates in the certificate chain 231 of a certificate extraction unit 265, and then performs a calculation to decrypt the signature of each of them. , and returns the result to the judgment unit 262. The certificate extraction unit 265 is requested to extract each of the certificates X. 509 in the certificate chain 231 by the judgment unit 262, the recast calculation unit 263 and the signature value decryption unit 264, and extract and return the X. 509 certificates.

Figure 27 is a flow chart that summarizes an operation carried out by the security administrator 1205f when carrying out the authentication of a file system. Based on this flow chart, an explanation of the operation is given that will be carried out in case the file system has the configuration shown in figure 44. After receiving a notification of pre-storage for the system of files from the AM 1205b (Step S271), the security administrator 1205f carries out an alteration check for the file system below the "/" directory of the upper level of the file system (Step S272). In the revision of alteration, it is verified, when comparing recast values, that there is no corruption or changes in the files that exist in each directory of the file system. Figure 46 and Figure 30 are detailed flow charts of Step S272. First, as shown in Step S461, recast values are calculated for the "ocap, certify. 1" and ocap files. signaturefile 1"0" and the respective "a" and "b" directories that exist in the directory "/." Note that the recast values of the "a" and "b" directories are calculated from the file "/ a / ocap. hashfile "452 and the file" / b / ocap. hashfile "453, respectively In Step S463, the recast values calculated in Step S462 are compared with each of the recast values described in 4513 in" / ocap. hashfile. "In Step S464, if any of the calculated recast values differ from the recast values in 4513, it is judged to have been tampered with (Step S467) .Meanwhile, when all calculated recast values match the values of recast at 4513, the security administrator 1205f proceeds to Step S465. In Step S465, it is checked if there is a subdirectory for which a tampering revision has not been completed. "b" exist as the subdirectories of the "/" directory, for which alteration revisions have not yet been carried out, therefore alteration reviews have to be carried out for these "a" and "b" directories First, a focus is placed on the "a" directory in Step S466, where a process equivalent to the one carried out for the "/" directory takes place After the alteration review for the directory "a "it is completed, it will be eva to carry out an alteration review for directory "b". When alteration revisions for all directories "a" and "b" have been completed, then a focus is placed on the "/" directory, and the process for Step S301 in Figure 30 is carried out. In Step S301, the certificate of origin 2313 is extracted from the file "/ ocap certificarcate 1" 4419, which is the chain of certificates 231. Then, in Step S302, the public key 2417 is taken out of the certificate of origin extracted 2313. Subsequently, in Step S303, a recast value is calculated for the "hashfile ocap." 451. Meanwhile, in Step S304, the decryption is performed in the signature value 242 in the file " / ocap, signaturefile 1"4420, using the public key 2417 that exists in the certificate of origin 2313 in the file" / ocap.certificatefile.1"4419. In Step S305, it is checked whether the recast value calculated in the Step S303 is equal to the value obtained in Step S304 when deciphering the signature value. If these calculated values match, it is possible to judge that the file system lower than the "/" directory has not been violated (Step S306). Meanwhile, if the calculated values do not match, it is possible to judge that the file system has been violated (Step S307). Note that a description has been given for an example in which alteration revisions are carried out by starting with the top-level "/" directory towards the subdirectories in descending order, but the present invention is not limited to this. Therefore, the processes can be carried out by starting with the lowest level directory to the top level directory in ascending order. Through the above processes, the result of Step S272 is obtained in Figure 27. In Step S273, when the result in Step S272 is "there has been tampering", the authentication is judged to have failed and a notification about this fact (Stage S279), after which the process is concluded. When the result of Step S272 is "there is no alteration", the process for Step S274 is executed. Next, with reference to Figure 31 to Figure 33, a detailed description of the authentication of certificate chains is given (Step S274). Assuming that a revision is first made for the intermediate certificate 2312 and the certificate of origin 2313, a flow chart for this is shown in figure 31. First, the intermediate certificate 2312 and the certificate of origin 2313 are extracted from the supply chain. certificates 231 (Step S311). From this extracted source certificate 2313, this date and time of update 2413, next date and time of update 2414 and the name of the emitter 2415 are extracted (Step S312). Of these, it is judged whether the current date and time is between this date and time of update 2413 and next date and time of update 2414 during which the certificate may remain valid (Step S313). If it is beyond the period during which the certificate may remain valid, the authentication of the certificate chain ends in failure (Step S319). Meanwhile, when judged to be within the valid period of the certificate, the subject name 2416 and the public key 2417 in the intermediate certificate 2312 are extracted (Step S314), and a comparison is made between the subject name 2416 of the certificate intermediate 2312 and the issuer name 2415 of the certificate of origin 2313 to judge whether the intermediate certificate 2312 and the certificate of origin 2313 are in a chain relationship or not (Step S315). If these certificates are not in a chain relation, the authentication of the certificate chain is a failure. Meanwhile, when there is a chain relationship between them, a recast value is calculated for the attribute area 241 in source certificate 2313 (Step S316). Moreover, the signature value 242 in the certificate of origin 2313 is decrypted with the public key 2417 of the intermediate certificate 2312 (Step S317). When Step S316 and Step S317 are completed, it is checked whether the recast value and the deciphered signature value obtained in the respective Steps coincide or not (Step S318). If they do not match, the authentication of the certificate chain ends in failure (Step S319). Then, a revision is made between the root certificate 2311 and the intermediate certificate 2312. Figure 32 is a flow chart showing this process. The root certificate 2311 and the intermediate certificate 2312 are extracted from the certificate chain 231 (Step S321), and a process that is equivalent to the revision carried out for the intermediate certificate 2312 and the certificate of origin 2313 is carried out for the root certificate 2311 and the intermediate certificate 2312 (Stage S322 ~ Stage S328). When judged in Step S328 that the values match, a revision is carried out only for the root certificate 2311. Figure 33 is a flow chart showing a revision that will be carried out only for the 2311 root certificate From the root certificate 2311 extracted in Step S321, this date and time of update 2413, next date and time of update 2414 and the name of emitter 2415 are extracted (Step S331). Of these, it is judged whether the current date and time is between this date and time of update 2413 and next date and time of update 2414 during which the certificate may remain valid (Step S332). If it is beyond the period during which the certificate can remain valid, the authentication of the certificate chain ends in failure. Meanwhile, when judged to be within the validity period of the certificate, a recast value for the attribute area 241 of the root certificate 2311 is calculated (Step S334). In addition, the signature value 242 in the root certificate 2311 is decrypted with the public key 2417 of the root certificate 2311 (Step S335). When Stage S334 and Step S335 are completed, it is checked whether the recast value and the deciphered signature value obtained in the respective Steps coincide or not (Step S336). If they match, the authentication of the certificate chain is successful (Step S337), whereas if they do not match, the authentication of the certificate chain ends in failure (Step S338). At this point, the process of Step S274 concludes. The process is carried out differently than Step S275 depending on the result of Step S274. When the result of Step S274 is "certificate chain authentication failed" the authentication is judged to have failed and a notification is made about this (Step S279), and then the file system authentication is concluded. Meanwhile, in case of "the authentication of the certificate chain was successful", the process of Step S276 is carried out. Then, the secondary storage unit 510 of the terminal apparatus 500 is scrutinized to find a certificate that is the same as the root certificate 2311 of the file "/ ocap.certify 1" 2119 (Step S276). When the same certificate is not present in the secondary storage unit 510, it is judged in the S277 hearth that the authentication of the certificate chain 231 is a fault, and a notification is made about this authentication failure (Step S279), after which the process is concluded. Meanwhile, when the root certificate 2311 is included, it is judged that the file system authentication is successful, and the AM 1205b is notified about this authentication success (Step S278). Referring to Figure 28, even if a pre-activation notification for a Java® program is received after (Step S281) the process is concluded without accomplishing anything. In the second mode, when a stored Java program is to be activated after a certain period of time, there is no need to carry out an authentication at that point since the file system was already authenticated immediately before it was stored. Here, a description is given of the case in which "application description file" shown in Figure 47 exists in the file system and only the files described there are going to be stored. According to the OCAP specification, for example, "application description file" is described in XML format (language to describe web pages). Figure 47 shows an example of "application description file". In Figure 47, there is no description of "PPV2Xlet.class" 4415 shown in Figure 44. Therefore, in this case, the "PPV2Xlet.class" 4415 is not included as storage targets. In this case, no recast value is calculated in S462 for the "PPV2Xlet.class" 4415 and thus no comparison is made in S463 with the recast value in 4533 described in the "hashfile ocap" file 4418. In the Step S462, a transition can be made to the S465 process by stipulating that files not included as storage targets are out of application.

Third Mode When a Java program (PPVlXlet. Class 4414 or PPV2Xlet. Class 4415) included in the file system is going to be activated for a certain period of time after this file system is stored, there is a possibility that the validity of one of the X.509 certificates included in the file "/ ocap.certify. 1" 4419 has expired (ie date and time of activation of the Java program> that following date and time of activation 2414). However, the second mode allows the Java program to be activated even if an X.509 certificate that has already expired is included in the certificate chain 231. Thus, the present modality is achieved by adding, to the second mode, the function of verify, at the time of activating a Java program, that the validity of each of the certificates 2311, 2312 and 2313 included in the certificate chain 231 has not expired. Figure 26 shows the constituent elements in the present embodiment. The constituent elements 261-265 required for the present embodiment were already described in the second embodiment, and therefore descriptions thereof are no longer given here. As flow charts, the flow chart of Figure 27 is replaced by the flow chart of Figure 48 and the flow chart of Figure 49 is added. 0 Referring to Figure 48, the processes that will be carried out immediately before the file system is stored (Step S481 to Step S487) are the same as the processes explained in the second mode (Step S271 to Step S277), and therefore the descriptions thereof are omitted. If the authentication does not fail, the process goes to the flow chart shown in Figure 49. When a notification that PPVlXlet. class 4414, which is a Java program, will be activated after a certain period of time (Stage S491), each of the X.509 certificates, that is, the root certificate 2311, the intermediate certificate 2312 and the certificate of origin 2313 are extracted from the file "certify yourself." 4419 (Step S492). Then, the extracted X. 509 certificates are selected one by one in order starting with the certificate of origin up to the root certificate (Step S493), and it is checked if the current date and time is between this date and time of update 2413 and the following date and time of update 2414 of each of the X. 509 certificates selected (Step S494). If the current date and time is not between this update date and time 2413 and the following update date and time 2414, the authentication is judged to be a failure and notification is made about this fact (Step S497). In the other case, it is checked whether revisions have been carried out for all X.509 certificates or not (Stage S495). If revisions have not been completed for all X.509 certificates, the process returns to S493, and the subsequent processes are repeated. Meanwhile, when all the X.509 certificates have already been reviewed in Step S495, the authentication is judged to be successful, and a notification about this authentication success is made (Step S496), after which the process is finished. By adding the processes shown in the flow chart of Figure 49, it is possible to notify the AM 1205b of the authentication failure so that a Java program whose validity period has expired is not activated. When notified by the security administrator 1205f of an authentication failure, the AM 1205b aborts the activation without passing this Java program to the JavaVM 1203.

Fourth Modality As described in the second embodiment, the secondary storage unit 510 includes an X.509 certificate which is the root certificate, which is compared to the root certificate 2311 in the certificate chain 231. The root certificate stored in the secondary storage unit 51 is replaced by a new X.509 certificate (hereinafter referred to as certificate replacement) in preparation for the case in which the credibility of the certificate is degraded due to hacking and others. The new X.509 certificate is transmitted from the cable head 101 to the terminal apparatus 500 to be delivered to the security administrator 1205f by means of the download module 106. Figures 51A, 51B and 51C are diagrams, showing each, one or more root certificates in the secondary storage unit 510 being replaced (certificate replacement) by the security administrator 1205f. In this case, an A5101 certificate is an old certificate that will be replaced, while a B5102 certificate is a new certificate. 51-1 Figure 51A shows the certificate stored in the secondary storage unit 510 before the certificate replacement takes place, 51-2 in Figure 51B shows the certificate in the middle of being replaced and 51-3 in Figure 51C shows the certificate stored in the secondary storage unit 510 after the replacement of certificates was carried out. In the second mode and the third mode, even when certificate replacement is carried out after a Java program is stored, no consideration is made for a new certificate at the time of activation of the Java program. Consider, for example, that the root certificate 2311 in the certificate chain 231 matches the A5101 certificate when the security administrator 1205f is authenticating a Java program in response to its pre-storage notification and that the security administrator 1205f receives a certificate. pre-activation notification for the Java program after the A5101 certificate is replaced by the B5102 certificate. At this point in time, the secondary storage unit 510 does not include any certificates that match the root certificate 2311 in the certificate chain 231, meaning that this certificate is not credible. However, in the second modality and the third modality, since no comparison is made between root certificates immediately before the activation of a Java program (that is, the root certificate 2311 in the certificate chain 231 is not compared with the B5102 certificate), no notification is made to the AM 1205b about the authentication failure. As a result, the AM 1205b causes the Java program to be activated. Thus, to the present modality, the function of carrying out a comparison of root certificates in consideration of the replacement of certificates at the time of the activation of a Java program is added. Figure 26 shows the constituent elements in the present embodiment. The constituent elements 261 ~ 265 have already been described and therefore the explanations thereof are omitted. A certificate replacement unit 266, a certificate replacement specification unit 267, and a certification reception unit 268 are added. When the certificate replacement specification unit 267 judges a certificate that is older than the received certificate is stored in the secondary storage unit 510, the certificate replacement unit 266 replaces this old certificate with the new certificate. Meanwhile, when the certificate replacement specification unit 267 judges that an older certificate is not stored, the certificate replacement unit 266 stores the new certificate in the secondary storage unit 510. The certificate replacement specification unit 267 receives the certificate received by the certificate reception unit 268. Then, it checks the certificate stored in the secondary storage unit 510 to see if it is some certificate whose issuer is the same and which is older than the received certificate, by means of the use of the library 1201b of OS 1201. The certificate receiving unit 268 receives a new certificate when the download module 1206 receives this new certificate from the cable head 101. After receiving the certificate, the reception unit of certificates 268 passes it to the certificate replacement unit 266 and the specification unit of certificate replacement 267. In addition, Figure 52 and Figure 53 are subsequently added to the flow chart in Figure 48. Figure 52 is a flow chart at the time of certificate replacement., while figure 53 is a flow chart at the time of activating the Java program after certificate replacement is carried out. Referring to Figure 52, when a request for a certificate replacement is received (Step S521), the viewer name of this received certificate is extracted (Step S522). It is checked whether an old certificate that needs to be replaced is present in the secondary storage unit 510 of the terminal apparatus 500 (Step S523), and only when an old certificate is present this certificate is erased. Then, the received certificate is stored in the secondary storage unit 510 (Step S525). When an activation notification for the Java program is received after a certain period of time (Step S531), the secondary storage unit 510 is scrutinized to look for the certificate that matches the root certificate 2311 in the certificate chain 231 (Stage S532), and if there is one (Step S533), the authentication is judged to be successful and notification is made about this fact (Step S534). If there is no certificate that matches (Step S533), the authentication is judged to be a failure, and notification is made about this fact (Step S535). Note that before it is judged in Stage S534 that the authentication is successful, it is also possible to conclude that the authentication is successful after verifying that each of the X.509 certificates in the certificate chain satisfies "this date and time of update <Current date and time < next date and time of update. "Furthermore, in addition to checking if the root certificates match, it is also possible to judge that the authentication is successful / inexistent after carrying out, before S532, the revision shown in figures 31 ~ 33 to see if the certificates in the certificate chain are in a chain relationship or not.

In addition, the above descriptions have been given for the case in which a certificate to be replaced is specified based on the name of the issuer, but the certificate can also be specified based on another attribute value such as the name of the subject .

Fifth Mode When a Java program (PPVlXlet. Class 4414 or PPV2Xlet. Class 4415) included in the file system is going to be activated for certain periods of time after this file system is stored, there is a case in which a certificate is revoked due to reasons other than that the validity of any of the X.509 certificates included in the file "/ ocap.certify. 1" 4419 has expired and that the root certificate was replaced. This configuration allows the Java program to be activated even when there is a revoked certificate. Here, CRL (Certificate Revocation List) is a widely known certificate revokerer. Figure 54 is a diagram showing the structure of a CRL. Here, only the attributes necessary to explain the present invention are illustrated. For more details about CRL, refer to IETF RF C3280"Internet X. 509 Public Key Infrastructure Certify and CRL Profile". 541 Indicates an attribute area of the CRL, 542 indicates the signature algorithm of a signature value 543, and 543 indicates the signature value of the CRL. The name of issuer 5411 indicates the issuer of this CRL, this date and time of update 5412 indicates the date and time when the CRL becomes valid, next date and time of update 5413 indicates the date and time when the validity of the CRL expires , and list of revoked certificates 5414 indicates information about X. 509 certificates revoked. Figure 55 is a diagram showing the structure of the list of revoked certificates 5414. Only the attributes that are necessary to explain the present invention are illustrated here as well. Information about a plurality of revoked X. 509 certificates is stored in the list of revoked certificates 5414. In the case of figure 55, as information about a "revoked certificate A" 551, a serial number 5511 to uniquely identify the certificate and date and time 5512 when "certificate A" 551 was revoked are included. Other revoked certificates are also equivalent to 551. Figure 56 is an exemplary configuration of a file system that includes a CRL. A directory "/" 561, a directory "a" 562, a file "SimpleXlet. Class" 563, files "ocap. Hashfile" 564 ~ 565, a file "ocap. Certify yourself." 1 566, a file "ocap. 1"567, an" ocap .crl. 2"568 file and an" ocap. Certify. "2" 569 file are stored internally. The authentication of a file system that includes CRL is as described in the first modality. Thus, the attention in this modality focuses on the file "ocap.crl.2" 568 which is structured in the CRL format and the file "ocap.certificate." 2"569 which is the chain of certificates in this file. Note that according to the OCAP specification, the "ocap.crl.x" certificate chain is "ocap.certify yourself, x". In the case of Figure 56, the chain of certificates of "Occa.Cr.2" is "Certify. Figure 59 is a schematic diagram showing the file "ocap hashfile" 564. 591 Shows the details of the ocap. hashfile 564. Ocap. hashfile in 591, which exists in the directory "/" 561, includes the recast values related to each of the file "certify ocap." 1 566, the file "ocap. signatrefile. 1" 567, the directory "a" 562, the file "ocap.crl.2" 568 and the file "ocap.certificarcate." 2"569 that exist in the same directory 561. Figure 57 is a flow chart to explain the authentication of a CRL. The following description is given for an example in which the file system has the configuration shown in Figure 56. First, this date and time of update 5412 and the following date and time of update 5413 are extracted from the CRL (Step S571 ), and it is checked if the current date and time is between this date and time of update 5412 and the next date and time of update 5413 (Stage S572). Otherwise, this CRL is judged to be invalid (Step S577). If the current date and time are between them, a recast value for an attribute area 541 is calculated to be able to verify the signature value of the file "occap cr..2" 568 (Step S573). At this time, the public key 2417 of the certificate of origin 2313 is extracted from the file "ocap. Certificate." 2 569, which is a chain of certificates (Step S574), and the signature value 543 of the file "ocap. 2"568 is decrypted with extracted public key 2417 (Step S575). Next, it is checked whether the recast value obtained in Step S573 is equal to the deciphered value obtained in Step S575 (Step S576). If they are not equal, it is judged that the CRL is invalid (Step S577). If they are the same, with reference to figure 58, an authentication is carried out for the file "ocap. Certificate 2" 569 which is a chain of certificates (Step S581). A method for authenticating the certificate chain is the same as that shown in Figure 31 to Figure 33 and is therefore not described here. Subsequently, it is judged whether the authentication of the certificate chain is successful or not (Step S582), and if the authentication is a failure, this CRL is judged to be invalid (Step S586). Meanwhile, if the authentication is successful, the secondary storage unit 510 is scrutinized for a certificate which is the same as the root certificate (Step S583). Here, if there is no matching root certificate, it is judged that the authentication is a failure and that this CRL is invalid (Step S586), whereas if a matching root certificate is included, it is judged that the authentication is successful and that the CRL is valid (Step S585). The following describes a solution to the problem of a Java program being activated even though a certificate is revoked in accordance with the CRL. To be able to support this, to the present modality is added the function of judging if a certificate that was used to authenticate a Java program is one that is revoked or not in the CRL, when a notification for this activation for this Java program is made. Figure 26 shows the constituent elements of the present embodiment. Except for 262 to which a certain addition was made and 269 which has not yet been described, no description is given for the constituent elements that have already been described above. The judgment unit 262, which is also capable of authenticating a CRL, requests the certificate revocation specification unit 269 to specify a certificate that will be revoked by the CRL. Then, when the notification receiving unit 261 receives a pre-activation notification for a Java program that is related to a revoked certificate specified by the certificate revocation specification unit 269, the judgment unit 262 judges that the authentication is a failure. Meanwhile, when the notification receiving unit is 261 it receives a pre-activation notification for the Java program in the state in which the judgment unit 262 has failed to authenticate the CRL and therefore judged that this CRL was invalid , the judgment unit 262 judges that the authentication is successful. When the judgment unit 262 recognizes that the authentication of the CRL was successful, the certificate revocation specification unit 269 specifies which of the X.509 certificates extracted by the certificate extraction unit 265 is a revoked certificate. As flow charts, figure 60 and figure 61 are added. The following description is given according to these flow graphs. It is assumed that a pre-storage notification for the file system shown in Figure 44 is now done, the processes shown in the flow chart of Figure 48 are initiated, and the process of Stage S487 is completed in due time. Assuming that a pre-storage notification for another file system shown in Figure 56 is then accepted, Stage S6001 to Stage S6007 is executed after the conclusion of the processes shown in the graph of Figure 57. The processes of the Step S6001 to Step S6007 are the same as those of Step S481 to Step S487. When Stage S6008 is reached and if the authentication of the file "ocap .crl.2" 563 (the flow charts of Figure 57 and Figure 58) is successful, the information about revoked certificates contained in this file is written in the database of revoked certificates. Figure 62 is a schematic diagram showing the database of revoked certificates. The sender names are stored in a column 621, serial numbers of certificates are stored in a column 622 and the dates and times of revocation are stored in a column 623. Here, when a pre-activation notification for the "PPVlXlet. class "4414 is accepted (Stage S611), it is checked if any of the certificates X. 509 included in the certificate chain 231 of the file" ocap. certificate. 1"4419 is included in the database of revoked certificates (Step S613). If there is any of the certificates that apply, it is judged that the authentication is a failure and notification is made about this (Step S616). Meanwhile, when there is no applicable certificate, a review is carried out for the entire certificate chain (Step S614), and a notification is made judging the notification to be successful (Step S615). Throughout the previous processes, it is possible to solve the problem that a Java program that should not be activated is activated, judging that the authentication of the file is a failure for a file system whose certificate was valid at the time of the verification but which was revoked by the CRL at the time the Java program was activated. Note that in the first to fifth modes, when a pre-activation notification for a Java program is received, it is also possible to carry out verification to check whether the tree structure of a file system is correct or not by using of "ocap. hashfile" placed in each directory. Moreover, there is only one intermediate certificate in a certificate chain for simplification reasons, but there may be a plurality of intermediate certificates. However, all intermediate certificates must be in a chain relationship when the authentication of their certificate chain is carried out. In addition, the following processes have been described in order of mention, but the present invention is not limited to this order: Review the presence / absence of alteration; authentication of a certificate chain and review to see if the secondary storage unit includes a root certificate that is the same as the root certificate in the certificate chain. In addition, regarding the storage of a file system, the security administrator 1205f can store it using the library 1201b of the OS. Likewise, the first to fifth modalities are also applicable to the case in which "application description file" is provided in the upper level directory "/" of a file system, and as its contents, only a part of the system of Files are indicated as files that will be stored. In this way, no problem occurs if only files that will be stored are handled. Moreover, the programs have been described above as storage targets, but non-program data can also be storage targets, meaning that the first to fifth modes can also be applied to data. In addition, there is the possibility that more than one "ocap.certificate.x" corresponds to "ocap.signaturefile.x", in which case the authentication of at least one of the files "ocap.certificate.x" is required to be successful Also, "ocap. Certificate. X" has been presented as an exemplary certificate chain, "ocap. Hashfile" has been presented as an example of a file that has a recast value and "ocap. a file example to check whether "ocap hashfile" in a directory "/" has been violated or not, but the present invention is not limited to these file names. Moreover, in the case of an authentication failure, the authentication can be carried out again after a redischarge. In addition, in the case of an authentication failure, a stored program as well as a chain of certificates, a file of signatures, recast files that have been used for authentication can be deleted in order to reserve suient capacity for the storage area . Here, a description is given for the case in which a file system constituting a program has a configuration shown in figure 63 and there is no description of files that is used for authentication as in the case of "description file of application "shown in Figure 64. 6311 A 6320 shown in Figure 63 are equivalent to 4411 to 4420 shown in Figure 44. 6321 It means" application description file "that describes files that will be stored. In "application description file" in figure 64, there is no description of "ocap. certificate. 1" 6319, "ocap.filefile.1" 6320 and "ocap. hashfile" 6317 required for authentication. In this case, if the files are stored as shown in Figure 64, the files required to carry out the authentication will not be stored. Thus, the authentication presented in the third, fourth and fifth modes can not be carried out at the time of activation. When a stored program is to be activated, and the files shown in Figure 63, which shows files before this program is stored, are ready to be downloaded, the stored files can be used as two files that constitute the program and the files used for authentication can be downloaded again for their authentication use. However, there may be a case in which the files shown in Figure 63, which shows files before the program is stored, can not be downloaded. Therefore, the files that are required for authentication can be stored for use in authentication that takes place at the time of activation of the program, even if they are not described in "application description files". Although only some exemplary embodiments of this invention have been described in detail above, those skilled in the art will readily appreciate that many modifications to the exemplary embodiments are possible without materially departing from the teachings and novel advantages of this invention. Accordingly, all of these modifications are intended to be included within the scope of this invention.

Industrial Applicability The method of storing files of program data and the method of executing authenticated programs according to the present invention are applicable to a program execution apparatus, such as a digital television receiver and a mobile telephone, which unloads and execute a program. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (24)

CLAIMS Having described the invention as above, the content of the following claims is claimed as property:

1. A method of storing program data files, characterized in that it comprises: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the authenticated data files of the first program in a transmission receiver according to information that refers to the storage of each of the data files in the first program; a second stage of receiving information that refers to the storage of each data file of a second program included in a second transport stream and the following stages are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a third stage of verifying if two recast values are consistent or not, one of the recast values being calculated from of the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth stage of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program and the recast value being calculated from a recast file located in a higher directory of the second program and a sixth stage of authenticating the second program and storing the second authenticated program in accordance with the information refers to the storage of each of the data files of the second program, in case the following is satisfied: that the two recast values are verified as being consistent in the third stage; that the certificate file included in the second program is verified as valid in the fourth stage and that the deciphered value and the recast value are verified as consistent in the fifth stage. The method of storing program data files according to claim 1, characterized in that the different data file included in the second program is a data file that is used to update a data file of the first program that has been authenticated at the time of storing the first program. The storage method of program data files according to claim 1, characterized in that the different data file included in the second program is a new data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program. 4. The method of storing program data files according to claim 1, characterized in that in case each of the programs has a directory structure, each data file included in each directory and the corresponding recast file each of the data files are located in the same directory, and the third stage is executed for each directory that includes the different data file included in the second program. The storage method of program data files according to claim 1, characterized in that in the sixth stage, the second program will not be stored in case at least one of the following conditions is satisfied: that the two values of recasting are not verified as consistent in the third stage; that the certificate file included in the second program is not verified as valid in the fourth stage and that the deciphered value and the recast value are not verified as consistent in the fifth stage. 6. The method of storage of program data files according to claim 1, characterized in that in the sixth stage, in case the data files of the second program include a data file that is the same as any of the data files of the first program, the same data file included in the second program will not be stored in the transmission receiver. The method of storing program data files according to claim 1, characterized in that in the sixth stage, in case the data files of the second program include a data file that is the same as any of the data files. data files of the first program, the data file of the first program is overwritten by the same data file included in the second program and stored in the transmission receiver. The method of storing program data files according to claim 1, characterized in that the fourth step includes a seventh step of verifying whether two root certificates match or not, one of the root certificates being in the file certificates included in the second program and the other root certificate being installed in the transmission receiver, and in the fourth stage, the certificate file is verified as valid in case the two root certificates match. The method of storing program data files according to claim 8, characterized in that the fourth step further includes an eighth step of verifying a period of validity of each certificate in the certificate file included in the second program, and In the fourth stage, the certificate file is verified as valid if both of the following conditions are met: the two root certificates coincide and the time at which the authentication is carried out is within the period of validity of each certificate in the certificate file. 10. A method of executing authenticated programs, characterized in that it comprises: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the authenticated data files of the first program in a transmission receiver according to information that refers to the storage of each of the data files in the first program; a second stage of receiving information that refers to the storage of each data file of a second program included in a second transport stream and the following stages are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a third stage of verifying if two recast values are consistent or not, one of the recast values being calculated from of the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth step of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a higher directory of the second program; a sixth stage of authenticating the second program and storing the second authenticated program according to the information that refers to the storage of each of the data files of the second program, in case the following is satisfied: that the two values of recasting shall be verified as consistent in the third stage; that the certificate file included in the second program be verified as valid in the fourth stage and that the deciphered value and the recast value be verified as consistent in the fifth stage and a ninth stage in verifying whether the certificate file included in the second stored program is valid or not in case a second program is to be executed and an execution step of authenticating the second stored program again and running the second authenticated program only in case the certificate file included in the second stored program is verified as valid in the ninth stage. The method of executing authenticated programs according to claim 10, characterized in that the ninth step includes a tenth stage of verifying whether two root certificates coincide or not, one of the root certificates being in the certificate file included in the second stored program and the other root certificate being installed in the transmission receiver, and in the ninth stage, the certificate file is verified as valid in case the two root certificates coincide. The method of executing authenticated programs according to claim 11, characterized in that the ninth step includes an eleventh stage of verifying a period of validity of each certificate in the certificate file included in the second stored program, and in the ninth stage stage, the certificate file is verified as valid if both of the following conditions are met: the two root certificates coincide and the time at which the execution is carried out is within the validity period of each certificate in the certificate file. The method of executing authenticated programs according to claim 10, characterized in that the different data file included in the second program is a data file that is used to update a data file of the first program that has been authenticated in the time to store the first program. The method of executing authenticated programs according to claim 10, characterized in that the different data file included in the second program is a new data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program. 15. The method of executing authenticated programs according to claim 10, characterized in that in case each of the programs has a directory structure, each data file included in each directory and the recast file corresponding to each one. The data files are located in the same directory, and the third stage is executed for each directory that includes the different data file included in the second program. 16. The method of executing authenticated programs according to claim 10, characterized in that in the sixth stage, the second program will not be stored if at least one of the following conditions is satisfied: that the two recast values do not be verified as consistent in the third stage; that the certificate file included in the second program is not verified as valid in the fourth stage and that the deciphered value and the recast value are not verified as consistent in the fifth stage. 17. The method of executing authenticated programs in accordance with claim 10, characterized in that in the sixth stage, in case the data files of the second program include a data file that is the same as any of the data files of the first program, the same data file included in the second program does not will be stored in the transmission receiver. 18. The method of executing authenticated programs according to claim 10, characterized in that in the sixth stage, in case the data files of the second program include a data file that is the same as any of the data files of the first program, the data file of the first program is overwritten by the same data file included in the second program and stored in the transmission receiver. 19. The method of executing authenticated programs according to claim 10, characterized in that the fourth step includes a seventh stage of verifying whether two root certificates coincide or not, one of the root certificates being in the certificate file included in the second program and the other root certificate being installed in the transmission receiver, and in the fourth stage, the certificate file is verified as valid in case the two root certificates coincide. The method of executing authenticated programs according to claim 19, characterized in that the fourth stage also includes an eighth step of verifying a period of validity of each certificate in the certificate file included in the second program, and in the fourth stage, the certificate file is verified as valid if both of the following conditions are met: the two root certificates coincide and the time at which the authentication is carried out is within the validity period of each certificate in the certificate file. 21. A program storage apparatus, characterized in that it comprises: a first storage unit that functions to authenticate each of the data files of a first program included in a first transport stream, and store each of the data files authenticated from the first program in a transmission receiver according to information that refers to the storage of each of the data files in the first program; a storage information receiving unit that functions to receive information that relates to the storage of each data file of a second program included in a second transport stream and the following units that carry out operations thereof in the event that the data files of the second program include a data file that is different from any of the data files of the first program that were authenticated at the time of storing the first program: a first verification unit that works to verify if two values of recasting are consistent or not, one of the recast values being calculated from the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a second verification unit that works to verify whether a certificate file included in the second program is valid or not; a third verification unit that works to verify whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key of a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a top directory of the second program and a second storage unit that works to authenticate the second program and store the second program authenticated according to the information that refers to the storage of each of the data files of the second program, in case that the following is satisfied: that the two recast values are verified as being consistent in the first verification unit; that the certificate file included in the second program is verified as valid by the second verification unit and that the decrypted value and the recast value are verified as consistent by the third verification unit. 2

2. An apparatus for executing authenticated programs, characterized in that it comprises: a first storage unit that functions to authenticate each of the data files of a first program included in a first transport stream, and to store each of the files of authenticated data of the first program in a transmission receiver according to information referring to the storage of each of the data files in the first program; an information reception unit that functions to receive information that relates to the storage of each data file of a second program included in a second transport stream and the following units that carry out operations thereof in case the files data of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a first verification unit that works to verify if two values of recast are consistent or not, one of the recast values being calculated from the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second Program; a second verification unit that works to verify whether a certificate file included in the second program is valid or not; a third verification unit that works to verify whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key of a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a higher directory of the second program; a second storage unit that works to authenticate the second program and store the second program authenticated according to the information that refers to the storage of each of the data files of the second program, in case the following is satisfied: the two recast values are verified as consistent by the first verification unit; the certificate file included in the second program is verified as valid by the second verification unit, and the decrypted value and the value of recast d verified as consistent by the third verification unit, and a fourth verifying unit that works to check whether the certificate file included in the second stored program is valid or not in case a 0 second program will be executed and an execution unit operable to authenticate the second stored program again and run the second authenticated program only in case the certificate file included in the second stored program is verified as valid by the fourth verification unit. 2

3. A program characterized because it is to cause a computer to run: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the first authenticated data files program in a transmission receiver according to information that refers to the storage of each of the data files in the first program; a second stage of receiving information that refers to the storage of each data file of a second program included in a second transport stream and the following stages are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a third stage of verifying whether two recast values are consistent or not, one of the recast values being calculated from of the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth stage of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a higher directory of the second program and a sixth stage of authenticating the second program and storing the second authenticated program in accordance with d information that refers to the storage of each of the data files of the second program, in case that the following is satisfied: that the two recast values are verified as being consistent in the third stage; that the certificate file included in the second program is verified as valid in the fourth stage and that the deciphered value and the recast value are verified as consistent in the fifth stage. 2

4. A program characterized in that it is to cause a computer to run: a first step of authenticating each of the data files of a first program included in a first transport stream, and storing each of the first authenticated data files program in a transmission receiver according to information that refers to the storage of each of the data files in the first program; a second stage of receiving information that refers to the storage of each data file of a second program included in a second transport stream and the following stages are executed in case the data files of the second program include a data file that is different from any of the data files of the first program that have been authenticated at the time of storing the first program: a third stage of verifying if two recast values are consistent or not, one of the recast values being calculated from of the different data file included in the second program and the other recast value being stored in a recast file corresponding to the different data file included in the second program; a fourth stage of verifying whether a certificate file included in the second program is valid or not; a fifth stage of verifying whether a deciphered value and a recast value are consistent or not, the deciphered value being obtained by deciphering a signature value from a signature file included in the second program using a public key from a certificate of origin in the certificate file of the second program, and the recast value being calculated from a recast file located in a higher directory of the second program; a sixth stage of authenticating the second program and storing the second authenticated program according to the information that refers to the storage of each of the data files of the second program, in case the following is satisfied: that the two values of recasting are verified as being consistent in the third stage; that the certificate file included in the second program be verified as valid in the fourth stage and that the deciphered value and the recast value be verified as consistent in the fifth stage and a ninth stage in verifying whether the certificate file included in the second stored program is valid or not in case a second program is to be executed and an execution step of authenticating the second stored program again and running the second authenticated program only in case the certificate file included in the second stored program is verified as valid in the ninth stage.