JP2009104618A - Terminal device and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To distribute Java-AP (Java application) software whose reliability is ensured without limiting the degree of freedom in IP. <P>SOLUTION: A mobile unit 16 starting the Java-AP software receives SDF (a security description file) 204 from a management server device 18 managed by a reliable institution (a carrier managing a mobile packet communication network 15), obtains ADF 205 from an IP server device 13 using URL included in the SDF, obtains a Jar file 206 from the IP server device 13 using the ADF 205, and installs the Java-AP software including the files therein. Java-AP achieved by starting the Java-AP software is operated within the range of authorization represented by policy information included in the SDF 204. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a technique for distributing an application to a terminal device.

  Java-AP software, which is a software including such a program, is provided with a function for executing a program written in accordance with the Java (registered trademark) programming language to realize a Java-AP (Java application). Mobile devices that can do so are widespread. The procedure for downloading Java-AP software by this type of mobile device is to acquire an ADF (Application Descriptor File) from a server device constituting the WWW (World Wide Web), and then acquire a Jar (Java Archive) file. It has become.

  The ADF has contents dependent on the Jar file. For example, a URL indicating the storage location of the Jar file (hereinafter referred to as a package URL), information indicating the size of the Jar file, information indicating the date and time of the last modification of the Jar file, and the like are essential. It is included as information. The mobile device that has acquired the ADF examines the contents of the ADF, and determines whether or not the Java-AP software to be downloaded can be installed in the mobile device.

  If it is determined that the installation is possible, the mobile device acquires a Jar file from the server device configuring the WWW using the package URL. Java-AP software is stored in the Jar file, and downloading of the Java-AP software is completed upon acquisition of the Jar file. Thereafter, in the mobile device, the Java-AP software is set to be startable, and the installation of the Java-AP software is completed.

  By the way, the restriction on the behavior of Java-AP realized in the mobile device is stricter than the restriction on the behavior of the native application originally provided in the mobile device such as a communication application. For example, Java-AP cannot refer to telephone directory data in a mobile device. Due to such a difference in limitation, it is possible to reliably avoid a situation in which highly confidential information in a mobile device is leaked or tampered with by a maliciously created Java-AP or a faulty Java-AP. .

  However, it is not possible to satisfy the desires of users and IPs (information providers) simply by imposing the above severe restrictions uniformly on all Java-APs. For example, if a certain degree of reliability is guaranteed, it seems that there are not a few users who feel that Java-AP may be given the authority to refer to personal information stored in the mobile device. In addition, there is a desire for IP to provide Java-AP based on the use of personal information stored in a mobile device and the use of many functions of the mobile device.

  As a mechanism that satisfies these wishes, a reliable organization such as a telecommunications carrier that provides a communication service to a user of a mobile device gives authority to Java-AP, notifies this authority to the mobile device, and based on the authority Thus, a mechanism in which the mobile device restricts the behavior of the Java-AP can be considered. This mechanism should ensure that no one other than a trusted authority can be involved in granting and managing authority in order to ensure the reliability of authority.

  When the above-described mechanism is applied to the Java-AP software download procedure, it is appropriate to include authority information in the ADF or Jar file. The Jar file is a type of file that is updated at any time by the IP, and it is appropriate that the Jar file is held by the IP. Therefore, if the Jar file is held by a reliable organization, the ADF is appropriate.

  However, since the ADF depends on the Jar file, when the Jar file on hand is updated by the IP, it is necessary to update the ADF held by a reliable organization. Since the ADF is managed so as to eliminate the other involvement of others in a reliable organization, it is expected that the update operation of the ADF will be a complicated operation. In addition, the ADF may need to be updated without updating the Jar file. For example, in the IP, access to a certain Jar file is concentrated, and this Jar file is moved to another server device. In this case, since the storage location of the Jar file is changed, it is necessary to change the package URL included in the ADF.

  The present invention has been made in view of the above-described circumstances, and restricts the degree of freedom of IP for software for realizing an application distributed by distributing a plurality of dependent files. Rather, it aims at providing the delivery method and delivery system which deliver to the terminal device which permits the action according to the authority with respect to an application.

  In order to solve the above-described problems, the present invention provides an information providing server device that stores an entity file that includes software for realizing an application, and a storage location of the entity file that has contents dependent on the entity file. An information providing server device storing an application description file indicating the first identification information indicating the storage location of the application description file, and the authority given to the application realized by the terminal device executing the software. And a management server device that stores a security description file that includes the authority information to be displayed. When notified of the storage location of the file, the communication system that returns the file performs a behavior according to the authority given to the application. Terminal devices permitted for the application An authority transmission process for transmitting the security description file while ensuring security, and the terminal device is included in the security description file transmitted from the management server apparatus in the authority transmission process. A dependency information acquisition process for acquiring the application description file using identification information, and a program for the terminal device to acquire the entity file from the communication system using the application description file acquired in the dependency information acquisition process A distribution method having an acquisition process is provided.

  According to this distribution method, the terminal device acquires the security description file transmitted from the communication system while ensuring security before acquiring the application description file and the entity file corresponding to the application. In this security description file, the authority given to the application is indicated, and in the terminal device, behavior corresponding to the authority indicated in the acquired security description file is permitted to the application corresponding to the security description file.

  In addition, the present invention stores an information providing server device storing an entity file containing software for realizing an application, and an application description file having contents dependent on the entity file and indicating a storage location of the entity file The information providing server device, the first identification information indicating the storage location of the application description file, and the authority information indicating the authority given to the application realized by executing the software by the terminal device A management server device that stores a security description file, and when the storage location of the file is notified, the communication system that returns the file and the behavior according to the authority given to the application are permitted to the application The management server Transmits the security description file to the terminal device while ensuring security, and the terminal device uses the first identification information included in the security description file transmitted from the communication system. Providing a distribution system for acquiring the application description file and acquiring the entity file from the communication system using the application description file.

  According to this distribution system, the terminal device acquires the security description file transmitted from the communication system while ensuring security before acquiring the application description file and the entity file corresponding to the application. In this security description file, the authority given to the application is indicated, and in the terminal device, behavior corresponding to the authority indicated in the acquired security description file is permitted to the application corresponding to the security description file.

Hereinafter, a distribution system according to an embodiment of the present invention will be described with reference to the drawings. In the drawings, common parts are denoted by the same reference numerals.
In this distribution system, a telecommunications carrier (trusted organization) that manages a mobile communication network presents information for downloading Java-AP software that can be installed in a mobile device to the user of the mobile device, and receives this presentation. The user downloads and installs the desired Java-AP software on the mobile device by operating the mobile device, and activates the mobile device. Note that downloading of Java-AP software in this system is performed by a procedure in which a screen explaining the contents of the Java-AP software is presented to the user of the mobile device, then ADF is distributed, and further a Jar file is distributed.

(1) Configuration As shown in FIG. 1, this distribution system includes IP server devices 12 to 14 connected to the Internet 11 and a mobile packet communication network 15 used by a communication carrier to provide mobile packet communication services. The mobile device 16 capable of performing wireless packet communication with the mobile station and capable of performing packet communication with a communication partner via the mobile packet communication network 15, and the Internet 11 and the mobile packet communication network 15 are interconnected. And a management server device 18 connected to the gateway server device 17 by a dedicated line. Although there are a large number of mobile devices in this system, only one mobile device 16 is shown in order to avoid complicated drawings. For the same reason, only three IP server apparatuses 12 to 14 are shown.

(1-1) IP Server Device The IP server device 12 is managed by the first IP, and the IP server devices 13 and 14 are managed by the second IP different from the first IP. The IP server devices 12 to 14 constitute a WWW, and each has the same hardware and functions as a general WWW server device. The IP server device 12 includes a nonvolatile memory 12A, the IP server device 13 includes a nonvolatile memory 13A, and the IP server device 14 includes a nonvolatile memory 14A. The IP server devices 12 to 14 each have a connection ( Thereafter, when a TCP connection) is established with the communication partner and a request message using the HTTP GET method is received through this connection, the file specified by the URL specified in the GET method is stored in its own nonvolatile memory. The HTTP connection message including the file is returned and the connection is disconnected.

  Each of the nonvolatile memories 12A, 13A, and 14A is a nonvolatile memory such as a hard disk, and includes a Jar file having a program created using the Java programming language, an ADF describing information about the Jar file, and the program. And an explanation file for explaining the contents of the Java-AP software to the user of the mobile device.

  ADFs that can be stored in the IP server device include ADFs that correspond to trusted Java-AP software, which will be described later, and ADFs that support untrusted Java-AP software. Conventionally, information described in the ADF such as a package URL indicating the storage location of the Jar file on the WWW, information indicating the size of the Jar file, information indicating the last modification date of the Jar file, and the like is also described in both. In addition to this, as shown in FIG. 2, the ADF corresponding to the trusted Java-AP software contains an APID and a hash value of the Jar file, which will be described later, and further, CA ( Signed with the private key given by the certificate authority).

The explanation file is a text file described according to HTML, and when interpreted by the mobile device according to HTML, the object operated by the user when downloading the Java-AP software corresponding to this file and the Java- It is described so that a UI (user interface) in which an SDF (security description file corresponding to the AP software, or ADF if there is no SDF) is associated with a URL indicating a position stored in the WWW is provided is provided. ing. The SDF will be described later.
Each of the IP server devices 12 to 14 has a function of creating and updating each of the files in accordance with a corresponding IP instruction.

(1-2) Gateway Server Device The gateway server device 17 is managed by the above-mentioned communication carrier, and has the same configuration as a general gateway server device that connects the mobile packet communication network 15 and the Internet 11. Communication is relayed among the mobile packet communication network 15, the Internet 11, and the management server device 18.

(1-3) Management Server Device The management server device 18 is managed by the communication carrier described above, constitutes the WWW, and has the same hardware and functions as a general WWW server device. In addition, the management server device 18 includes a nonvolatile memory 18A such as a hard disk, establishes a TCP connection with a communication partner, and receives a request message using the HTTP GET method via this connection. A file specified by the URL specified in the method is read from the nonvolatile memory 18A, an HTTP response message including this file is returned, and the connection is disconnected.

  The nonvolatile memory 18A also includes a list file 200 for introducing Java-AP software that can be downloaded to the mobile device 16 to the user of the mobile device 16, and a Java- that uses the mobile device's trusted API (APplication Interface). A file that is essential when downloading Java-AP software for realizing an AP in a mobile device to the mobile device, and for the Java-AP software, the communication carrier and the IP that provides the Java-AP software The SDF created by the telecommunications carrier according to the contract between them is stored. The trusted API will be described later.

  The list file 200 is a text file described according to HTML. When the list file 200 is interpreted according to HTML, options corresponding to each Java-AP software and positions where the explanation file of the Java-AP software is stored in the WWW. Is described so as to provide a UI associated with a URL indicating.

(1-4) Mobile Device As shown in FIG. 3, the mobile device 16 includes OS (operating system) software, Java-AP environment software for constructing an environment for executing Java-AP, ROM 16A storing various native AP software and the like, CPU 16B connected to ROM 16A for reading and executing programs from ROM 16A, display unit 16C, nonvolatile memory 16D, RAM 16E, communication unit 16F and operation unit 16G connected to CPU 16B Have

  The display unit 16C has a liquid crystal display panel, for example, and displays an image represented by data supplied from the CPU 16B. The nonvolatile memory 16D is, for example, an SRAM or an EEPROM, and data is read and written by the CPU 16B. As will be described in detail later, the nonvolatile memory 16D is used to store Java-AP software (including ADF and Jar) downloaded from a server device (hereinafter referred to as a Web server device) constituting the WWW, and SDF. The

  The communication unit 16F performs wireless packet communication with the mobile packet communication network 15, and relays packets between the CPU 16B and the mobile packet communication network 15. The communication unit 16F includes a CODEC, a microphone, a speaker, and the like for calling in addition to the antenna and the wireless transmission / reception unit. The mobile device 16 performs a call by line switching via a mobile communication network (not shown). You can also. The operation unit 16G includes an operation element, and supplies a signal corresponding to the operation of the operation element to the CPU 16B.

  When a power supply (not shown) is turned on, the CPU 16B uses the RAM 16E as a work area and reads and executes a program included in the OS software from the ROM 16A. Thereby, the function of providing a UI or the like is realized in the CPU 16B. That is, the CPU 16B activates the OS software to realize the OS shown in FIG. The OS specifies a user instruction based on the signal supplied from the operation unit 16G and the state of the UI, and performs processing according to the instruction.

  If the user's instruction is to request activation of communication software that is native AP software, the OS activates the communication software and implements the communication AP in the mobile device 16. By using this communication AP, the user can make a call with the other party.

  If the user's instruction is to request activation of the phone book AP which is native AP software, the OS activates the phone book software and implements the phone book AP in the mobile device 16. By using this telephone directory AP, the user can refer to, use, and change the contents of the telephone directory (hereinafter referred to as telephone directory data) stored in the nonvolatile memory 16D.

  If the user's instruction is to request activation of Web browser software that is native AP software, the OS activates the Web browser software and implements the Web browser in the mobile device 16. The Web browser provides a UI, specifies a user instruction based on the state of the UI and a signal supplied from the operation unit 16G, and performs processing according to the instruction. For example, in the case of an instruction to acquire a file in which the instruction is specified from the WWW, the communication unit 16F is controlled to establish a TCP connection with the Web server device storing the file, and this connection Then, an HTTP request message in which the URL indicating the specified position is specified in the GET method is transmitted, a response message corresponding to the request message is received, and the connection is disconnected. Further, the Web browser interprets the file included in the received response message according to HTML, generates a UI including the Web page, and provides it to the user. If the user's instruction is to request downloading of Java-AP software, this instruction is notified to a Java Application Manager (JAM) described below. Specifically, when an anchor represented by an anchor tag for which an object tag is specified is pressed (click operation or press operation) on a Web page, the Web browser is specified in the data attribute of the object tag. The URL is extracted, and JAM is notified that downloading of Java-AP software from the URL is requested.

  If the user's instruction is to request activation of JAM software which is native AP software, the OS activates the JAM software and implements JAM in the mobile device 16. The JAM presents a list of Java-AP software installed in the mobile device 16 to the user, and activates the Java-AP software designated by the user. Specifically, if the user's instruction to JAM requests that Java-AP software be activated, the Java-AP environment software is activated to realize the Java-AP environment in the mobile device 16, and then The designated Java-AP software is activated to implement Java-AP in the Java-AP environment. The Java-AP environment includes a KVM that is a lightweight Java virtual machine suitable for a mobile terminal, and an API provided to the Java-AP. APIs provided to Java-AP include trusted APIs that are permitted to be used only by Java-APs (hereinafter referred to as trusted APs) whose telecommunications carriers have guaranteed reliability based on contracts with IP, and any Java. -It is divided into untrusted APIs that are allowed to be used by APs.

In addition, when an instruction to request downloading of Java-AP is notified from the Web browser, the JAM performs processing for downloading and installing the Java-AP software on the mobile device 16. The flow of this process is shown in FIG.
As shown in FIG. 5, JAM first determines whether or not the Java-AP software to be downloaded is Java-AP software (hereinafter referred to as trusted Java-AP software) for realizing the trusted AP. (Step S11). Specifically, JAM refers to the file name at the end of the URL notified from the Web browser. If the extension of this file is “sdf”, it is trusted Java-AP software, and if it is not “sdf”, it is untrusted. Judged to be Java-AP software. When it is determined that the Java-AP software to be downloaded is the trusted Java-AP software, the same download and installation processing as before is performed (step S12).

  If it is determined that the Java-AP software to be downloaded is the trusted Java-AP software, the JAM acquires the SDF corresponding to the software from the management server device 18 (step S13). That is, the JAM establishes a TCP connection with the management server device 18, and requests the management server device 18 to transmit the SDF stored at the position indicated by the URL notified from the Web browser via this connection. A request message having the content to be transmitted is generated and transmitted, a response message to the message is received, and the connection is disconnected.

  The SDF is a file created by the communication carrier for each trusted AP. As shown in FIG. 6, the SDF uniquely identifies the trusted Java-AP software, policy information to be described later, and the Java-AP software. ADF-URL, which is a URL indicating the storage location of the ADF corresponding to, and a public key assigned by the CA to the IP providing the Java-AP software. The JAM extracts the APID, ADF-URL, and public key from the SDF included in the response message, and writes the SDF in the nonvolatile memory 16D.

  Next, JAM obtains ADF (step S14). Specifically, the JAM establishes a TCP connection with the Web server device that stores the ADF specified by the ADF-URL extracted from the SDF, and generates a request message having a content for requesting transmission of the ADF. The message is transmitted, a response message to the message is received, and the TCP connection is disconnected.

  The ADF corresponding to the trusted Java-AP software is different from the normal ADF corresponding to the untrusted Java-AP software, and includes the aforementioned APID and the hash value of the Jar file, and further provides the trusted Java-AP software. The IP is signed (encrypted) by a secret key assigned by the CA. The JAM verifies (decrypts) the signature of the ADF included in the response message using the public key extracted from the SDF, and determines the validity of the ADF (step S15).

  If it is determined that the ADF is valid, the JAM compares the APID extracted from the SDF with the APID included in the ADF, and determines whether or not they match (step S16). If it is determined that the two match, the JAM determines whether or not the trusted Java-AP software can be installed in the mobile device 16 based on the content of the ADF (step S17). The criteria for this determination are the same as in the prior art.

  If it is determined that installation is possible, the JAM obtains a Jar file. Specifically, the JAM writes the ADF into the mobile device 16 and extracts a hash value and a package URL from the ADF. Furthermore, the JAM establishes a TCP connection with the Web server device that stores the Jar file specified by the package URL, generates and transmits a request message having a content for requesting transmission of the Jar file, and responds to this message. The response message is received and the TCP connection is disconnected (step S18).

  Further, the JAM calculates a hash value for the acquired Jar file (step S19). The hash function used for calculating the hash value is arbitrary, but the hash function used in the mobile device and the hash function used when calculating the hash value included in the ADF must match. Actually, the IP that provides the trusted Java-AP software uses the hash function used in the mobile device to calculate the hash value and generate the ADF.

  The JAM compares the hash value calculated by the JAM with the hash value extracted from the ADF (step S20), and if they match, the acquired Jar file is written in the management server device 18 and the trusted Java-AP software is written. Various processes related to the installation are performed (step S21), and the user is notified of the successful installation (step S22).

  When it is determined that the ADF is not valid, when the APID of the SDF and the APID of the ADF do not match, when it is determined that the Java-AP software to be installed cannot be installed, the calculated hash value and the ADF are If the hash value does not match, the JAM notifies the user that the installation has failed, and returns the state of the mobile device 16 to the state before the acquisition of the SDF.

  JAM also monitors Java-AP behavior and limits the use of trusted APIs. This restriction is performed according to the policy information in the SDF stored in the nonvolatile memory 16D. The policy information in the SDF has contents as conceptually shown in FIG. 7, for example. In the policy information shown in FIG. 7, “getPhoneList ()”, which is an essential trusted API when referring to the phone book data stored in the mobile device, and the trusted API, which is essential when acquiring the status of the mobile device. Use of “getMsStatus ()” is permitted, and use of “getCallHistory ()”, which is an essential trusted API when referring to outgoing / incoming call history data stored in the mobile device, is prohibited.

(2) Operation Example Next, an operation example of the above-described system will be described.
Note that, in the operations described below, the TCP connection establishment and disconnection operations are general operations in HTTP, and thus description thereof is omitted. In addition, since the operations performed by the OS, Web browser, JAM, Java-AP, native AP, and the like described above are the operations of the mobile device 16, the main body of the operation is the mobile device 16 in the following description.
Further, as shown in FIG. 8, it is assumed that a list file 200 and an SDF 204 are stored in the nonvolatile memory 18A of the management server device 18. These are created by a telecommunications carrier in accordance with a contract between an IP that manages the IP server device 13 and the IP server device 14 and a telecommunications carrier that manages the management server device 18. Among these, the list file 200 is described so as to provide a list page 201 shown in FIG. 9 when interpreted and executed by the mobile device 16. In addition, when the option 201A constituting the list page 201 is pressed (clicked or pressed), the list file 200 has a URL (“http://www.main.bbb.co. jp / ghi.html ") as a parameter of the GET method is described so as to be generated. Further, when the option 201B constituting the list page 201 is pressed (clicked or pressed), the list file 200 is a URL (“http://www.ccc.co.jp/ It is described that a request message including jkl.html ") as a parameter of the GET method is generated.

  Further, the SDF 204 has “0001” as the APID, information on the contents shown in FIG. 7 as the policy information, “http://www.main.bbb.co.jp/viewer.jam” as the ADF-URL, and the public key The public key assigned by the CA to the IP managing the IP server device 13 and the IP server device 14 is included.

  The nonvolatile memory 12A of the IP server device 12 stores an explanation file 211, an ADF 213, and a Jar file 214 corresponding to the Java-AP software (hereinafter referred to as the first Java-AP software) named “Stuffed Shogi”. It shall be. These are created by the IP that manages the IP server device 12. Among these, the contents of the explanation file 211 are as shown in FIG. 10, and are described so as to provide the explanation page 212 shown in FIG. 11 when interpreted and executed in the mobile device 16. The ADF 213 includes the URL of the Jar file 214 (“http://www.ccc.co.jp/shogi.jar”) as a package URL.

  The nonvolatile memory 12A of the IP server device 12 stores an explanation file 207, an ADF 209, and a Jar file 210 corresponding to Java-AP software (hereinafter referred to as second Java-AP software) named “Horoscope”. It is assumed that These are created by the IP that manages the IP server device 12. Among these, the contents of the explanation file 207 are as shown in FIG. 12, and are described so as to provide an explanation page 208 shown in FIG. The ADF 209 includes the URL of the Jar file 210 (“http://www.ccc.co.jp/horoscope.jar”) as a package URL.

The nonvolatile memory 13A of the IP server device 13 includes an explanation file 202, an ADF 205, and a Jar file 206 corresponding to Java-AP software (hereinafter referred to as third Java-AP software) named “phone book viewer”. It shall be remembered. These are created by the IP that manages the IP server device 13 and the IP server device 14. Among these, the contents of the explanation file 202 are as shown in FIG. 14, and are described so as to provide the explanation page 203 shown in FIG. 15 when interpreted and executed by the mobile device 16. The ADF 205 includes “0001” as the APID, the hash value of the Jar file 206 as the hash value, and the URL of the Jar file 206 (“http://www.main.bbb.co.jp/viewer.jar”) as the package URL. The IP that manages the IP server device 13 and the IP server device 14 is signed using a secret key assigned by the CA.
Further, it is assumed that the mobile device 16 is in a state in which the first to third Java-AP software can be installed.

(2-1) Installation Operation First, an operation example when Java-AP software is installed in the mobile device 16 will be described for each Java-AP software.

(2-1-1) First Java-AP Software The installation operation of the first Java-AP software starts when the user operates the mobile device 16 and tries to acquire the explanation file 211. As a result, the mobile device 16 generates a request message tm12 including the URL (“http://www.ccc.co.jp/mno.html”) of the explanation file 211 as a parameter of the GET method. This request message tm12 is transmitted from the mobile device 16 and received by the IP server device 12, as shown in FIG. In the IP server device 12, a response message tm13 including the explanation file 211 is generated corresponding to the content of the request message tm12. The response message tm13 is transmitted from the IP server device 12 and received by the mobile device 16. In the mobile device 16, a UI corresponding to the contents of the explanation file 211 is provided to the user. As a result, an explanation page 212 as shown in FIG. 11, for example, is displayed on the display unit 16C.

  When the user viewing the explanation page 212 operates the mobile device 16 so that the anchor 212A in the explanation page 212 is pressed, the mobile device 16 uses the anchor tag (“<A The object tag (tag starting with “<OBJECT”) whose value specified in the id attribute of the tag attribute starting with “” is specified, and the URL (specified in the data attribute of this object tag) “Http://www.ccc.co.jp/shogi.jam”) is extracted, and a request message tm16 having a content requesting transmission of the ADF 213 specified by this URL is generated. This request message tm16 is transmitted from the mobile device 16 and received by the IP server device 12. In the IP server device 12, a response message tm17 including the ADF 213 is generated corresponding to the content of the request message tm16. The response message tm17 is transmitted from the IP server device 12 and received by the mobile device 16.

  In the mobile device 16, it is determined whether or not the first Java-AP software can be installed based on the content of the ADF 213. As described above, since the mobile device 16 is in a state where the first Java-AP software can be installed, it is determined that the mobile device 16 can install the first Java-AP software.

Next, in the mobile device 16, the ADF 213 is written into the nonvolatile memory 16D1. Further, the mobile device 16 extracts the package URL (“http://www.ccc.co.jp/shogi.jar”) from the ADF 213 and requests transmission of the Jar file 214 specified by the package URL. Request message tm18 is generated. This request message tm 18 is transmitted from the mobile device 16 and received by the IP server device 12. In the IP server device 12, a response message tm19 including the Jar file 214 is generated corresponding to the content of the request message tm18. This response message tm 19 is transmitted from the IP server device 12 and received by the mobile device 16. In the mobile device 16, the Jar file 214 is written into the nonvolatile memory 16D1, and the installation of the first Java-AP software is completed.
When it is determined that the first Java-AP software cannot be installed in the mobile device 16, the state of the mobile device 16 returns to the state before starting acquisition of the ADF 213.

(2-1-2) Second Java-AP Software The installation operation of the second Java-AP software starts when the user operates the mobile device 16 and tries to acquire the explanation file 207 or the list file 200. Since operations starting from attempting to acquire the description file 207 are a subset of operations starting from attempting to acquire the list file 200, only operations starting from attempting to acquire the list file 200 will be described here. .

  As shown in FIG. 17, in the mobile device 16, a request message tm20 including the URL (“http://www.aaa.co.jp/def.html”) of the list file 200 as a parameter of the GET method is generated. The The request message tm20 is transmitted from the mobile device 16 and received by the management server device 18. In the management server device 18, a response message tm21 containing the list file 200 is generated corresponding to the content of the request message tm20. The response message tm21 is transmitted from the management server device 18 and received by the mobile device 16. In the mobile device 16, the reception of the response message tm 21 is triggered, and the list file 200 in the response message tm 21 is interpreted according to HTML, and a UI corresponding to the contents of the list file 200 is provided to the user of the mobile device 16. . As a result, a list page 201 as shown in FIG. 9 is displayed on the display unit 16C of the mobile device 16, for example.

  When the user who views the list page 201 operates the mobile device 16 so that the option 201B in the list page 201 is pressed, the mobile device 16 uses a URL (“http: //” associated with the option 201B. A request message tm22 including “www.ccc.co.jp/jkl.html”) as a parameter of the GET method is generated. The request message tm22 is transmitted from the mobile device 16 and received by the IP server device 12. In the IP server device 12, a response message tm23 including the explanation file 207 is generated corresponding to the content of the request message tm22. The response message tm23 is transmitted from the IP server device 12 and received by the mobile device 16. In the mobile device 16, a UI corresponding to the contents of the explanation file 207 is provided to the user. As a result, for example, an explanation page 208 as shown in FIG. 13 is displayed on the display unit 16C.

  When the user who views the explanation page 208 operates the mobile device 16 so that the anchor 208A in the explanation page 208 is pressed, the mobile device 16 uses the anchor tag (“<A” described in the explanation file 207 of FIG. The object tag (tag starting with “<OBJECT”) whose value specified in the id attribute of the tag attribute starting with “” is specified, and the URL (specified in the data attribute of this object tag) “Http://www.ccc.co.jp/horoscope.jam”) is extracted, and a request message tm26 having a content for requesting transmission of the ADF 209 specified by this URL is generated. This request message tm 26 is transmitted from the mobile device 16 and received by the IP server device 12. In the IP server device 12, a response message tm27 including the ADF 209 is generated corresponding to the content of the request message tm26. The response message tm27 is transmitted from the IP server device 12 and received by the mobile device 16.

  The mobile device 16 determines whether or not the second Java-AP software can be installed based on the content of the ADF 209. As described above, since the mobile device 16 is in a state where the second Java-AP software can be installed, it is determined that the mobile device 16 can install the second Java-AP software.

Next, in the mobile device 16, the ADF 209 is written in the nonvolatile memory 16D1. Further, the mobile device 16 extracts the package URL (“http://www.ccc.co.jp/horoscope.jar”) from the ADF 209 and requests the transmission of the Jar file 210 specified by the package URL. Request message tm28 is generated. This request message tm 28 is transmitted from the mobile device 16 and received by the IP server device 12. In the IP server device 12, a response message tm29 including the Jar file 210 is generated corresponding to the content of the request message tm28. This response message tm 29 is transmitted from the IP server device 12 and received by the mobile device 16. In the mobile device 16, the Jar file 210 is written into the non-volatile memory 16D1, and the installation of the second Java-AP software is completed.
If the mobile device 16 determines that the second Java-AP software cannot be installed, the state of the mobile device 16 returns to the state before the acquisition of the ADF 209 is started.

(2-1-3) Third Java-AP Software The installation operation of the third Java-AP software starts when the user operates the mobile device 16 and tries to acquire the explanation file 202 or the list file 200. Since operations starting from attempting to acquire the description file 202 are a subset of operations starting from attempting to acquire the list file 200, descriptions of operations starting from attempting to acquire the description file 202 are omitted.

  As shown in FIG. 18, in the operation starting from the attempt to acquire the list file 200, the mobile device 16 receives the response message tm21, and for example, until the list page 201 as shown in FIG. The same operation as shown in FIG. When the user who views the list page 201 operates the mobile device 16 so that the option 201A in the list page 201 is pressed, the mobile device 16 uses a URL (“http: //” associated with the option 201A. A request message tm32 including “www.main.bbb.co.jp/ghi.html”) as a parameter of the GET method is generated. The request message tm32 is transmitted from the mobile device 16 and received by the IP server device 13. In the IP server device 13, a response message tm33 including the explanation file 202 is generated corresponding to the content of the request message tm32. The response message tm33 is transmitted from the IP server device 13 and received by the mobile device 16. In the mobile device 16, a UI corresponding to the contents of the explanation file 202 is provided to the user. As a result, an explanation page 203 as shown in FIG. 15, for example, is displayed on the display unit 16C.

  When the user who views the explanation page 203 operates the mobile device 16 so that the anchor 203A in the explanation page 203 is pressed, the mobile device 16 uses the anchor tag (“<A” described in the explanation file 202 of FIG. The object tag (tag starting with “<OBJECT”) whose value specified in the id attribute of the tag attribute starting with “” is specified, and the URL (specified in the data attribute of this object tag) “Http://www.aaa.co.jp/abc.sdf”) is extracted, and a request message tm34 having a content for requesting transmission of the SDF 204 specified by this URL is generated. This request message tm 34 is transmitted from the mobile device 16 and received by the management server device 18. In the management server device 18, a response message tm35 including the SDF 204 is generated corresponding to the content of the request message tm34. The response message tm35 is transmitted from the management server device 18 and received by the mobile device 16 via the gateway server device 17 and the mobile packet communication network 15. Since the communication path between the management server device 18 and the gateway server device 17 is a dedicated line, and the gateway server device 17 is directly connected to the mobile packet communication network 15 with secured security, the mobile device 16 There is no possibility that the SDF 204 will be tampered before it is received.

  In the mobile device 16, the SDF 204 is written into the nonvolatile memory 16D1 of the nonvolatile memory 16D. Further, the mobile device 16 extracts the APID (“0001”), the ADF-URL (“http://www.main.bbb.co.jp/viewer.jam”), and the public key from the SDF 204, and this ADF- A request message tm 36 having a content for requesting transmission of the ADF 205 specified by the URL is generated. This request message tm 36 is transmitted from the mobile device 16 and received by the IP server device 13. In the IP server device 13, a response message tm37 including the ADF 205 is generated in accordance with the content of the request message tm36. The response message tm 37 is transmitted from the IP server device 13 and received by the mobile device 16.

  The mobile device 16 determines the validity of the ADF 205 using the public key extracted from the SDF 204. As described above, since the public key included in the SDF 204 corresponds to the secret key used when signing the ADF 205, communication from the IP server device 13 or from the IP server device 13 to the mobile device 16 is performed. As long as the ADF 205 is not changed in the route, it is determined that the ADF 205 is valid.

  If it is determined that the ADF 205 is valid, the mobile device 16 compares the APID extracted from the SDF 204 with the APID included in the ADF 205. As described above, since the ADF 205 in the IP server device 13 is defined so that an APID that matches the APID in the SDF 204 is described, the APID and the ADF 205 extracted from the SDF 204 are stored as long as there is no description error. The included APID matches.

  If the APIDs match, the mobile device 16 determines whether or not the third Java-AP software can be installed based on the contents of the ADF 205. As described above, since the mobile device 16 is in a state where the third Java-AP software can be installed, it is determined that the mobile device 16 can install the third Java-AP software.

  Next, in the mobile device 16, the ADF 205 is written into the nonvolatile memory 16D1. Further, the mobile device 16 extracts the hash value and the package URL (“http://www.main.bbb.co.jp/viewer.jar”) from the ADF 205, and the Jar file 206 specified by the package URL. A request message tm38 having a content requesting transmission is generated. This request message tm38 is transmitted from the mobile device 16 and received by the IP server device 13. In the IP server device 13, a response message tm39 including the Jar file 206 is generated corresponding to the content of the request message tm38. This response message tm39 is transmitted from the IP server device 13 and received by the mobile device 16.

  The mobile device 16 calculates a hash value using the Jar file 206 and a predetermined hash function, and compares this hash value with the hash value extracted from the ADF 205. As described above, since it is determined that the hash value of the Jar file corresponding to the ADF 205 is described in the ADF 205, the two hash values match unless there is a description mistake or the like. When the two hash values match, the mobile device 16 writes the Jar file 206 in the nonvolatile memory 16D1, and the installation of the third Java-AP software is completed.

  If the mobile device 16 determines that the ADF 205 is not valid, or if the APID extracted from the SDF 204 and the APID included in the ADF 205 do not match, it is determined that the third Java-AP software cannot be installed. In the case where the calculated hash value and the hash value extracted from the ADF 205 do not match, the state of the mobile device 16 returns to the state before the acquisition of the SDF 204 is started.

(2-2) Behavior of the mobile device 16 when the Java-AP software is activated Next, the behavior of the mobile device 16 when the Java-AP software is activated will be described.
(2-2-1) First Java-AP Software The first Java-AP software installed in the mobile device 16 by the above-described installation operation is started in the mobile device 16 in which JAM is realized, and the software is The behavior of the mobile device 16 when a corresponding function (hereinafter, first Java-AP) is realized in the mobile device 16 will be described.

When the API to be used by the first Java-AP is an untrusted API, the use of the API is permitted by JAM. Therefore, the first Java-AP can use the API.
When the API that the first Java-AP intends to use is a trusted API, the JAM checks whether or not the SDF corresponding to the Java-AP is stored in the nonvolatile memory 16D. Since such SDF is not stored in the nonvolatile memory 16D, JAM prohibits the use of the API by the first Java-AP. Therefore, the first Java-AP cannot use the API.

(2-2-2) Second Java-AP software The second Java-AP software installed in the mobile device 16 is activated in the mobile device 16 in which JAM is realized, and functions corresponding to the software are moved. The behavior of the mobile device 16 when realized in the device 16 is the same as the behavior of the mobile device 16 when the first Java-AP software is activated.

(2-2-3) Third Java-AP Software The third Java-AP software installed in the mobile device 16 is activated in the mobile device 16 in which JAM has been realized, and functions corresponding to the software (hereinafter, The behavior of the mobile device 16 when the third Java-AP) is realized in the mobile device 16 will be described.

When the API to be used by the third Java-AP is an untrusted API, the use of the API is permitted by JAM. Therefore, the third Java-AP can use the API.
When the API that the third Java-AP intends to use is a trusted API, the behavior of the mobile device 16 depends on the API to be used. Hereinafter, the behavior of the mobile device 16 will be described for each API to be used.

(2-2-3-1) getPhoneList ()
Since “getPhoneList ()” is a trusted API, whether or not the API can be used is determined by JAM based on policy information in the SDF 204 stored in the nonvolatile memory 16D. Since the contents of this policy information are as shown in FIG. 7, use of “getPhoneList ()” is permitted by JAM. Therefore, the third Java-AP can use “getPhoneList ()”. That is, the third Java-AP can read the phone book data.

(2-2-3-2) getCallHistory ()
Since “getCallHistory ()” is a trusted API, whether or not the API can be used is determined by JAM based on policy information in the SDF 204. Since the contents of this policy information are as shown in FIG. 7, use of “getCallHistory ()” is prohibited by JAM. Therefore, the third Java-AP cannot use “getCallHistory ()”. That is, the third Java-AP cannot read outgoing / incoming history data.

(2-3) Operation after the change of the third Java-AP software Next, when the IP managing the IP server device 13 and the IP server device 14 changes the distribution form and contents of the third Java-AP software The system operation will be described. However, the change here includes a change in the contents of the Jar file 206 for the purpose of improving the third Java-AP software and a change in the distribution form for the purpose of reducing the load on the IP server device 13. Including. In order to achieve the latter change, the IP managing the IP server device 13 and the IP server device 14 sends the changed Jar file 206 (hereinafter referred to as the Jar file 215) to the IP server device 14 as shown in FIG. The content of the ADF 205 is changed to correspond to the Jar file 215 and stored as the ADF 216 in the nonvolatile memory 14A. The work necessary for the distribution of the third Java-AP software after the change is as described above, and there is no work to be performed by the communication carrier managing the management server device 18.

  The installation operation of the third Java-AP software after such a change is as shown in FIG. The operation shown in this figure begins to differ from the operation shown in FIG. 18 after the IP server device 13 generates a response message tm47 containing ADF216, not a response message tm37 containing ADF205. In both figures, the response message tm47 corresponds to the response message tm37, the request message tm48 corresponds to the request message tm38, and the response message tm49 corresponds to the response message tm39.

  The operations after the generation of the response message tm47 in the IP server device 13 are substantially different from the operations shown in FIG. 18 in that the ADF 216 and the Jar file 215 are processing targets and included in the ADF 216. A request message tm48 with a content requesting transmission of the Jar file 215 specified by the package URL (“http://www.sub.bbb.co.jp/viewer.jar”) is generated by the mobile device 16. The request message tm48 is transmitted from the mobile device 16 and received by the IP server device 14, the response message tm49 including the Jar file 215 is generated in the IP server device 14, and the response message tm49 is It is only a point transmitted from the IP server device 14 and received by the mobile device 16.

(3) Modification In the distribution system described above, the mobile device confirms the validity of the correspondence between the SDF and the creator of the ADF using the signature data by the secret key and the public key. Depending on the required security level, the public key is not included in the SDF, the signature using the secret key for the ADF is not performed in the IP server device, and the confirmation process is omitted in the mobile device. The processing amount in the mobile device and the IP server device and the communication amount between the mobile device and the management server device and the IP server device may be reduced.

  In the distribution system described above, the hash value of the Jar file is included in the ADF corresponding to the Jar file, while it is generated in the mobile device, the two are compared, and the validity of the correspondence between the Jar file and the ADF is confirmed. However, depending on the security level required for the system, the confirmation processing is omitted without including the hash value in the ADF, the processing amount in the mobile device and the IP server device, and the mobile device and the IP server device. The amount of communication between the two may be reduced.

  In the distribution system described above, it is determined whether the correspondence between the SDF and the ADF (and the Jar file) is valid by using an APID unique to the trusted Java-AP, but the trusted Java-AP It is also possible to determine whether or not the correspondence between the SDF and the ADF (and the Jar file) is valid using a CID unique to the information provider that provides the information. Further, depending on the security level required for the system, the determination using the APID or CID may be omitted.

In the distribution system described above, a server is specified using a domain name, but a server may be specified using an IP address.
Also, in the mobile device, the domain name of the server device that is the source of SDF is compared with a preset character string, and the SDF is recognized as valid only when the domain name of the server device is managed by a trusted organization. It is good. In this aspect, the character string to be compared (for example, a character string indicating the domain name of the communication carrier) is stored in advance in the ROM or nonvolatile memory of the mobile device. Since the character string cannot be rewritten in the form stored in advance in the ROM, higher security can be ensured. Moreover, in the aspect stored in advance in the non-volatile memory, since a reliable organization can be stored after the mobile device is bought and sold, excellent convenience can be provided to the user and the reliable organization.

  Further, in the distribution system described above, high security is ensured as a reliable organization for a communication provider that provides a communication channel used for SDF distribution. However, the present invention is based on a reliable organization for providing a communication channel. The technical scope also includes embodiments that are not performed. For example, a trusted organization and a mobile device may be connected by an encrypted communication path, and the trusted organization may distribute the SDF via this communication path. Even if the security of the communication path is not ensured, if the SDF is encrypted and distributed, and the mobile device decrypts the SDF, the SDF can be distributed with a certain degree of security.

In the distribution system described above, files are transmitted and received according to HTTP. However, the system may be modified so as to ensure higher security by using HTTPS.
In the distribution system described above, it is needless to say that a reliable organization may be IP, that is, the management server device may also serve as the IP server device.

  Furthermore, in the distribution system described above, the API is cited as a target for restricting the use of Java-AP. However, the present invention is not limited to this, and any resource can be targeted. The resource here may be a hardware resource, or a network resource or a software resource described later. Hardware resources include memory, speakers, microphones, infrared controllers, LEDs (Light Emitting Diodes) and other mobile devices, UIM (User Identity Module) and SIM (Subscriber Identity Module) that can work with mobile devices. External devices such as are also included.

  Next, network resources will be described. As described above, the mobile device performs wireless communication with the mobile communication network. During this wireless communication, the mobile device uses wireless resources such as a wireless channel provided by the mobile communication network. This radio resource is a kind of network resource. Further, the mobile device uses communication resources such as a packet transmission path and a communication path for line connection in a communication protocol layer higher than the communication protocol layer to which the radio resource belongs. Such communication resources are also a kind of network resources.

  Next, software resources will be described. Software resources include APIs, classes, packages, and the like. The functions provided by the software resources vary, but typical functions include a calculation processing function such as cryptographic calculation, and a function of sending and receiving data to and from other applications such as a Web browser. The present invention also includes in the technical scope an aspect in which the software resources of the external device are also restricted.

  By the way, the use of hardware resources and network resources by Java-AP is generally performed using software resources. The mobile device in the distribution system described above also has software resources for using hardware resources and network resources. By restricting the use of such software resources, the hardware resources and the network are indirectly used. The use of resources is restricted. In this way, by providing a form of indirect restriction, if various software resources are prepared, only the trusted Java-AP of Java-AP has the authority to change the authority of the other Java-AP. It can only be achieved by changing the restrictions on multiple resources, such as removing the restriction that it can only communicate with the server device that provides or downloads, or making it possible to access a specific storage area of the memory. It becomes possible to easily specify such things. Note that an aspect in which the use of software resources in the mobile device is restricted to restrict the use of software resources in the external device indirectly is also included in the technical scope of the present invention.

  As a permission expression method, one resource and one flag (permitted / prohibited) may be associated with each other, or the permission of a plurality of resources may be indicated by one information.

  In the present invention, it is also possible to set permissions so as to indicate the types of use permitted (or prohibited) for resources having a plurality of types of use. In this case, finer control is realized in the mobile device. For example, since there are two usage modes (types of usage) for memory, it is used only for reading for untrusted Java-AP, but it is used for both reading and writing for trusted Java-AP. You can also get it. Also, for example, in a mobile device that can share a single packet transmission path, when a Web browser or the like is started while a Java-AP having the authority to use the packet transmission path is started, If the Java-AP is not allowed to “exclusively use the packet transmission path”, sharing of the packet transmission path by a web browser or the like cannot be excluded. A Java-AP that is permitted to “use exclusively” can control such that the packet transmission path can be occupied and used. Furthermore, by modifying this example, a Java-AP given a certain kind of permission can exclusively use the packet communication path without asking the user permission, and can be given another permission. Java-AP can use the packet communication path without asking the user for permission, but in order to use the packet communication path exclusively, it is necessary to obtain the user's permission. A given Java-AP can use a packet communication path without asking for permission from the user, but cannot exclusively use a packet communication path, and a Java- The AP can use the packet communication channel only after obtaining permission from the user, and gives another permission. Java-AP which is not even possible to use the packet communication path, the control also allows such. As is clear from this example, the “type of use” in the present invention includes the type of procedure (procedure for obtaining user permission / procedure for obtaining no user permission) when the resource is used.

  In the distribution system described above, the same list page is provided for all mobile devices, but a different list page may be provided for each mobile device.

  In the above distribution system, the Java-AP behavior is restricted when the Java-AP is executed. However, when the Jar file is downloaded, the policy information is included in the Jar file stored in the IP server device. In the mobile device, the policy information is compared with the policy information in the SDF, and if the two do not match, the Java-AP corresponding to the Jar file cannot be started, or the Java- The AP software may not be installed. Of course, only the permissions for items that match both policy information may be validated.

In addition, the SDF uses the private key assigned by the CA to sign the SDF and then distributes the SDF, and the mobile device verifies the SDF signature using the public key assigned to the carrier by the CA. You may make it do. Of course, the public key of the communication carrier must be stored in the mobile device in advance. As a method for storing the public key in the mobile device in advance, a method in which the public key is distributed by communication and written in the nonvolatile memory, a method in which the mobile device is sold after being written in the ROM, or the like can be considered.
In the above distribution system, the software is distributed to the mobile device, but the technical scope of the present invention includes a mode of distributing to a terminal device other than the mobile device.

  As described above, according to the present invention, in the terminal device, the behavior corresponding to the authority indicated in the acquired security description file is permitted to the application corresponding to the security description file. Therefore, various applications can be provided. Furthermore, since the information indicating the authority is transmitted from the management server apparatus to the terminal apparatus after security is secured, there is no possibility that the authority is tampered by a third party. Further, since there is no need to store the application description file and the entity file having the dependency relationship in the management server device, the degree of freedom of IP is not limited.

It is a block diagram which shows the structure of the delivery system which concerns on one Embodiment of this invention. It is a conceptual diagram which shows the data structure of ADF peculiar to the system. It is a block diagram which shows the structure of the mobile device 16 which comprises the system. 3 is a conceptual diagram showing a functional configuration of the mobile device 16. FIG. 10 is a flowchart showing a flow of processing in which the mobile device 16 downloads and installs Java-AP software. It is a conceptual diagram which shows the data structure of SDF stored in the management server apparatus 18 in the same system. It is a conceptual diagram which shows the content of the policy information included in the same SDF. It is a block diagram for demonstrating operation | movement of the delivery system. It is a figure which shows the list page delivered by the delivery system. It is a figure which shows the content of the description file which the IP server apparatus 12 which comprises the delivery system has stored. It is a figure which shows the description page delivered with the delivery system. It is a figure which shows the content of the description file which the IP server apparatus 12 has stored. It is a figure which shows the description page delivered with the delivery system. It is a figure which shows the content of the description file which the IP server apparatus 13 which comprises the delivery system has stored. It is a figure which shows the description page delivered with the delivery system. It is a sequence diagram for demonstrating operation | movement of the delivery system. It is a sequence diagram for demonstrating operation | movement of the delivery system. It is a sequence diagram for demonstrating operation | movement of the delivery system. It is a block diagram for demonstrating other operation | movement of the delivery system. It is a sequence diagram for demonstrating other operation | movement of the delivery system.

Explanation of symbols

11 Internet 12, 13, 14 IP server device 15 Mobile packet communication network 16 Mobile device 17 Gateway server device 18 Management server device 16D, 12A, 13A, 14A, 18A Non-volatile memory 16A ROM
16B CPU
16C display unit 16E RAM
16F communication unit 16G operation unit

Claims (8)

A first type of program using an authority information description file including authority information, which is information used to control access from at least one of a hardware resource, a network resource, and a software resource, and the authority information description; Execution means capable of executing a second type of program that does not use a file;
Determining means for determining whether the program executed by the executing means is a first type program or a second type program;
When the determination unit determines that the program to be executed is the first type program, the access to the at least one resource is controlled based on the first condition based on the authority information, and the determination unit When it is determined that the program to be executed is the second type program, control means for controlling access to the at least one resource under a second condition;
First acquisition means for acquiring the authority information description file via a network;
The authority information description file indicates the storage location of the application information description file;
The application information description file indicates a storage location of an entity file containing the program to be executed;
Second acquisition means for acquiring the application information description file from the storage location indicated by the authority information description file;
Third acquisition means for acquiring the entity file from the storage location indicated by the application information description file;
Installation means for installing the program included in the entity file in the terminal device;
The execution means executes the program installed by the installation means,
An access to a resource controlled by the first condition is permitted more than an access to a resource controlled by the second condition. The first condition is a condition that allows access to a resource based on the authority information in addition to access to the resource based on a predetermined condition,
The terminal device according to claim 1, wherein the second condition is a condition that allows access to a resource based on the predetermined condition. The terminal device according to claim 1, wherein the software resource is an API (Application Program Interface), a class, or a package. The terminal device according to any one of claims 1 to 3, wherein the authority information indicates a type of resource use. The terminal device according to any one of claims 1 to 4, wherein the hardware resource includes any one of a memory, a speaker, a microphone, an infrared controller, and an LED (Light Emitting Diode). The terminal device according to claim 1, wherein the hardware resource is an external device that is a device other than the terminal device. The terminal device has wireless communication means for performing communication via a network;
The terminal device according to claim 1, wherein the network resource is any one of a wireless channel, a packet transmission path, and a line-connected communication path provided by the network. A first type of program using an authority information description file including authority information, which is information used to control access from at least one of a hardware resource, a network resource, and a software resource, and the authority information description; A computer apparatus having execution means capable of executing a second type program that does not use a file,
Determining whether the program executed by the execution means is a first type program or a second type program;
When it is determined that the program to be executed is a first type program, access to the at least one resource is controlled under a first condition based on the authority information, and the program to be executed is a second type If it is determined that the program is a type of program, the step of controlling access to the at least one resource under a second condition;
Obtaining the authority information description file via a network; obtaining the application information description file from a storage location indicated by the authority information description file;
Obtaining the entity file from the storage location indicated by the application information description file;
Installing the program included in the entity file on the terminal device; and
The authority information description file indicates the storage location of the application information description file;
The application information description file indicates a storage location of an entity file containing the program to be executed;
The execution means executes the program installed by the installation means,
An access to a resource controlled by the first condition is permitted more than an access to a resource controlled by the second condition.

Images