JP4934162B2 - Mobile terminal and management program - Google Patents

Description

  The present invention relates to a technique for using an IC card in a mobile terminal.

  An IC card used in a portable terminal is known, such as mobile FeliCa (registered trademark). For a single IC card, data is read and written using a dedicated reader / writer, but for an IC card built in a portable terminal, in addition to reading and writing data using a reader / writer, Data can be read and written from the mobile terminal body. Many portable terminals have a function of performing communication via a network, and various services can be provided by a communication function and an IC card function. In a portable terminal incorporating an IC card, dedicated application software is used to read and write data on the IC card.

  On the other hand, Patent Document 1 discloses a technique for displaying an execution result of an APDU (Application Protocol Data Unit, which is a message transmitted from a terminal device to an IC card) on a web browser ( In particular, paragraphs 0020-0022).

JP 2006-244211 A

When performing communication through the network and reading / writing data to / from the IC card as a series of processing, software for performing communication via the network and software for reading / writing data from / to the IC card are provided. Switching was cumbersome. Also in Patent Document 1, it is necessary to use dedicated software for acquisition and execution of APDU.
On the other hand, the present invention provides a technique for switching software for reading / writing data to / from an IC card to either a script that can be executed from software for performing communication via a network or dedicated software. .

The present invention provides a communication means for communicating via a network, a first application program for executing a specific process, a second application program different from the first application program, a script, and the second application First control means for executing a first management program for managing a program, an antenna, a memory having a plurality of storage areas in which access restrictions can be individually set, a signal from the antenna, or the first control An IC card having a second control means for accessing the memory in accordance with a signal from the means and outputting the access result to the first control means, and specifying a storage area set in the memory The first identifier and the storage area specified by the first identifier are accessed. Storage means for storing a list including a second identifier indicating possible software, and the second application program is a program for accessing one storage area of the plurality of storage areas The script includes a group of instructions for accessing the one storage area, and the first control unit executing the first management program functions as a first management unit, and The first control means executing one application program functions as first application means, and the first control means executing the second application program is second application means. The first management means receives a request to confirm the contents of the list from the first application means, If the second identifier corresponding to the first identifier indicating the one storage area in the list is the identifier of the second application program, the first management Means for updating the list so that the second identifier corresponding to the first identifier indicating the one storage area in the list becomes the identifier of the script; provide.
According to this portable terminal, the software that accesses the IC card is switched to the script while the first application program is being executed.

In a preferred aspect, the first application program includes a group of instructions for executing the script, and after the update of the list, the first management unit performs the operation on the first application unit. When a first instruction to execute a script is given and the first instruction is received, the first application means may execute the script.
According to this portable terminal, the script is executed after the list is updated.

In another preferred embodiment, the first control means executes the second management program for managing the uninstallation of the second application program, and executes the second management program. When the control unit functions as a second management unit and the list is updated, the first management unit performs a second uninstall of the second application program on the second management unit. When the instruction is given and the second instruction is received, the second management unit may uninstall the second application program.
According to this portable terminal, the second application program is automatically uninstalled.

In still another preferred aspect, when the request is received, the second identifier corresponding to the first identifier indicating the one storage area in the list is the identifier of the script, or the one When the second identifier corresponding to the first identifier indicating the storage area is not included in the list, the first management means instructs the first application means to execute the script May be.
According to this portable terminal, the script is executed when it is not necessary to update the list.

In still another preferred aspect, the portable terminal has display means for displaying information, and the specific process receives specific data described in a specific format from the network via the communication means. , A process of displaying information based on the received specific data on the display means, wherein the first application means has received the specific data including trigger information that triggers execution of the script. As an opportunity, the request may be sent to the first management means.
According to this portable terminal, processing by the first application program for displaying information acquired via the network and switching of software for accessing the IC card are seamlessly performed.

Further, the present invention provides a communication means for communicating via a network, a first control means for executing a program, an antenna, a memory having a plurality of storage areas in which access restrictions can be individually set, and the antenna. An IC card having a second control means for accessing the memory in response to a signal or a signal from the first control means and outputting the access result to the first control means; and setting in the memory Storage means for storing a list including a first identifier that identifies a storage area that is stored and a second identifier that indicates software that can access the storage area identified by the first identifier In the portable terminal, the first control means receives a request for confirming the contents of the list, and when the request is received, When the second identifier corresponding to the first identifier indicating a storage area is an identifier of an application program for accessing one of the plurality of storage areas, the first control means A management program for causing the list to be updated so that the second identifier corresponding to the first identifier indicating the one storage area in the list is the identifier of the script. provide.
According to this management program, the software that accesses the IC card is switched from the script to the application program while the first application program is being executed.

It is a figure which shows the structure of the communication system which concerns on one Embodiment. 1 is an external view of a mobile phone 10. FIG. 2 is a diagram showing a hardware configuration of a mobile phone 10. FIG. 2 is a diagram showing a configuration of an IC card 500. FIG. 5 is a diagram illustrating a configuration of a storage area of a memory 504. FIG. It is a figure which shows Java execution environment. 3 is a diagram showing a software configuration of the mobile phone 10. FIG. 2 is a diagram illustrating a configuration of a service server 30. FIG. 2 is a diagram showing a configuration of a remote issuing server 40. FIG. 2 is a diagram illustrating a configuration of a service server 50. FIG. 2 is a diagram illustrating a configuration of a service server 60. FIG. It is a sequence diagram which shows the process by a registration script. It is a figure which illustrates the specific example of HTML data. It is a sequence diagram which shows the process by a read script. It is a sequence diagram which shows the process by a writing script. It is a sequence diagram which shows the process by a deletion script. It is a figure which illustrates an IC card list. It is a figure which illustrates the screen displayed according to an IC card list. It is a sequence diagram which shows the registration process of browser mode. It is a sequence diagram which shows the registration process of application mode. It is a figure which shows the switching process from browser mode to application mode. It is a figure which shows the switching process from application mode to browser mode. It is a flowchart which shows the process which starts a browser or an application program from an IC card list. It is a figure which shows the outline | summary of an encryption technique.

1. Configuration FIG. 1 is a diagram showing a configuration of a communication system according to an embodiment of the present invention. This communication system includes a mobile phone 10, a management server 20, a service server 30, a remote issuing server 40, a service server 50, and a service server 60. The management server 20, service server 30, remote issuing server 40, service server 50, and service server 60 are connected via a network 70. The reader / writer 510 performs wireless communication with an IC (Integrated Circuit) card 500 built in the mobile phone 10 to read / write data.

1-1. Mobile phone 10
FIG. 2 is an external view of the mobile phone 10. The mobile phone 10 is an example of a mobile terminal according to the present invention. The mobile phone 10 has a housing 9A and a housing 9B. The housing 9 </ b> A and the housing 9 </ b> B are connected via the hinge 3. The mobile phone 10 is a so-called foldable mobile phone. The user of the mobile phone 10 performs voice communication and data communication with the housing 9A and the housing 9B opened as shown in FIG.

  The housing 9A includes a speaker 6, an antenna 7, and a display device 8. The speaker 6 outputs voice of a call, operation sound, music sound, and the like. The antenna 7 performs wireless communication with the wireless base station. The display device 8 displays characters and images. The housing 9 </ b> B has a keypad 4 and a microphone 5. The keypad 4 outputs a signal corresponding to a user operation. The microphone 5 converts the input sound into an electric signal and outputs it.

  FIG. 3 is a diagram illustrating a hardware configuration of the mobile phone 10. A CPU (Central Processing Unit) 102 is a control device (an example of a first control unit) that controls each component of the mobile phone 10. A ROM (Read Only Memory) 103 is a storage device that stores programs and data necessary for basic operations of the mobile phone 10. The ROM 103 stores, for example, an IPL (Initial Program Loader), an OS (Operating System) program, and Java (registered trademark) platform software. The IPL is a program for reading a program that is executed first when the mobile phone 10 is powered on. In this embodiment, the IPL reads the OS program. The OS program is a program for realizing input / output of data, access to a storage device, execution of various programs, voice communication, data communication, and other basic functions of the mobile phone 10. Java (registered trademark) platform software is a program and data for realizing a Java execution environment on the OS. The Java execution environment will be described later.

  A RAM (Random Access Memory) 104 is a storage device that functions as a work area when the CPU 102 executes a program. The storage unit 105 (an example of a storage unit) is a storage device that stores application programs and data. The storage unit 105 includes a nonvolatile memory such as a flash memory. In the present embodiment, the storage unit 105 stores a browser program. The browser program is a program for receiving HTML (HyperText Markup Language) data via a network and causing the display device 8 to display information corresponding to the received HTML data (an example of a first application program). The storage unit 105 stores an e-mail program. The e-mail program (mailer) is a program for sending and receiving e-mails via a network and displaying and editing the sent and received e-mails. It is possible to attach image data and address book data as an attached file to the e-mail. In this example, the browser and mailer are Java application programs.

  The operation unit 106 outputs a signal corresponding to a user operation. The operation unit 106 has an input device such as a keypad (keypad 4 in FIG. 2) including a numeric keypad, a call key, an end key, a clear key, a cursor key, a power key, and other keys for performing input. . The user inputs an instruction to the mobile phone 10 by operating the keypad. The display unit 107 (an example of a display unit) displays characters and images. The display unit 107 includes a display device (display device 8 in FIG. 2) such as a liquid crystal display. The display unit 107 displays information processed by the running application program. The display unit 107 includes a display body such as an LCD (liquid crystal display) and a drive circuit that drives the display body. The communication unit 108 (an example of a communication unit) performs voice communication or data communication via a radio base station via an antenna (antenna 7 in FIG. 2). The bus 109 is a transmission path for transmitting signals and data exchanged between components. Furthermore, the mobile phone 10 has an IC card 500. The above components are connected via a bus 109.

  FIG. 4 is a diagram illustrating a configuration of the IC card 500. The antenna 501 is used for transmitting / receiving a radio signal to / from the reader / writer 510. The IC chip 502 performs processing according to the signal received by the antenna 501. The IC chip 502 includes a processor 503 (an example of second control means) and a memory 504.

  The IC card 500 has a signal line 505 used for data transmission / reception with the CPU 102. The processor 503 accesses the memory 504 in accordance with a signal received by the antenna 501 or a signal from the CPU 102, and reads or writes data. The processor 503 executes processing associated with data reading or writing, such as data encryption or decryption.

  FIG. 5 is a diagram illustrating the configuration of the storage area of the memory 504. In this example, two areas of a common area and a free area are set in the memory 504 in the initial state (FIG. 5A). The common area is an area where an area is set for each service and data is written by a predetermined operator (in this example, an operator that manages and operates the remote issuing server 40). The free area is an area where data can be written regardless of the operator.

  The common area can be further divided into a plurality of areas, and data of different services, for example, electronic money data of company A and electronic money of company B can be stored in each area (FIG. 5). (B)). Hereinafter, electronic money provided by Company A and Company B will be referred to as “Company A Money” and “Company B Money”, respectively. Access restrictions (security) can be set for each area individually. Thereby, data used in a plurality of services can be managed in one card, and security of data between services is ensured.

  FIG. 6 is a diagram showing a Java execution environment. When the CPU 102 executes the Java (registered trademark) platform software, the Java execution environment 114 shown in FIG. 6 is realized on the OS 111. The Java execution environment 114 includes a class library 117, a JVM (Java Virtual Machine) 118, and a JAM (Java Application Manager) 119. The class library 117 is a group of program modules (classes) having specific functions combined into one file. The JVM 118 has a function of interpreting and executing bytecode provided as a Java application program. The JAM 119 has a function of managing the download, installation, activation, termination, and other operations of the Java application program (an example of a second management program).

  The JAM 119 includes an API (Application Program Interface) group 120 for accessing the IC card 500. The API group 120 includes, for example, a server communication start API for starting communication with the server, a data read API for reading data from the IC card 500, a data write API for writing data to the IC card 500, and the like. Is included.

  The client software 121 is software for relaying communication with a server such as the remote issuing server 40. The device driver 122 is a driver program for accessing the IC card 500.

  The first storage 115 is an area for storing a Java application program (Jar file and ADF (Application Descriptive File)) downloaded under the management of the JAM 119. The second storage 116 is an area for storing data generated when the Java application program is executed after the end. In the second storage 116, a separate storage area is allocated for each installed Java application program. The data in the storage area allocated to a certain Java application program can be rewritten only while the Java application program is being executed, and another Java application program cannot be rewritten.

  When the CPU 102 executes the Java application program under the Java execution environment 114, the application 112 and the application 113 are realized.

  FIG. 7 is a diagram illustrating a software configuration of the mobile phone 10. An application program such as the browser 130 operates on the OS 111. The browser 130 has a function of causing the display device 8 to display information corresponding to the HTML data. The browser 130 has a function related to a function of displaying information, such as a function of receiving HTML data from the network. The script processing engine 131 is one of such related functions, and has a function of interpreting a Java script and executing a process according to an instruction described in the Java script. The script processing engine 131 includes an API group 132 for accessing the IC card 500. The API group 132 includes, for example, a server communication start API for starting communication with the server, a data read API for reading data from the IC card 500, a data write API for writing data to the IC card 500, and the like. Is included.

  The dedicated application 140 is an application program for accessing the IC card 500 in a specific service such as Company A money or Company B money (an example of a second application program). The dedicated application 140 is a dedicated program specialized for a specific service. For example, A company money and B company money each have their own dedicated application 140. In this example, the dedicated application 140 is a Java application program.

  A list management program 150 (an example of a first management program) is a program for managing an IC card list. The IC card list is a list indicating services registered (or scheduled to be registered) in the mobile phone 10 (details will be described later). The list management program 150 controls the update of the IC card list and the activation of the script processing engine 131 and the dedicated application 140 based on the IC card list.

1-2. Management server 20
The management server 20 is a server for performing processing such as authentication and billing when the mobile phone 10 performs communication via a network.

1-3. Service server 30
FIG. 8 is a diagram illustrating the configuration of the service server 30. The service server 30 is a server that is managed and operated by company A, which is a provider that provides electronic money services. The service server 30 includes HTML data for providing information related to the service, various scripts (balance display script, settlement script, charge script, and deletion script) used for the electronic money service, and a server program for causing the server to function. Are stored in storage means 301 such as an HDD. Details of these scripts will be described later. The service server 30 includes a communication unit 302 such as a communication interface used for communication via a network, and a control unit 303 such as a CPU that executes a program. When the control unit 303 executes the server program and controls the storage unit 301 and the communication unit 302, the service server 30 has a function of transmitting HTML data and a script in response to a request from the mobile phone 10.

1-4. Remote issuing server 40
FIG. 9 is a diagram showing the configuration of the remote issuing server 40. The remote issue server 40 is a server that is managed and operated by a provider that provides the platform of the IC card 500. The remote issuance server 40 executes a process used for the service of the IC card 500 such as a database for recording information related to a service provided by a business operator, a process for registering information in the database, and an authentication process for registration and settlement. Are stored in a storage unit 401 such as an HDD. The remote issuing server 40 includes a communication unit 402 such as a communication interface used for communication via a network, and a control unit 403 such as a CPU that executes a program. A function that performs processing such as service registration and authentication in response to a request from the mobile phone 10 when the control unit 403 executes the server program and controls the storage unit 401 and the communication unit 402. Have

1-5. Service server 50
FIG. 10 is a diagram illustrating a configuration of the service server 50. The service server 50 is a server that is managed and operated by Company B, which is a provider that provides electronic money services. The service server 50 includes HTML data for providing service-related information, various scripts (balance display script, settlement script, charge script, and deletion script) used for the electronic money service, and a server program for causing the server to function. Are stored in storage means 501 such as an HDD. Details of these scripts will be described later. The service server 50 also includes a communication unit 502 such as a communication interface used for communication via a network, and a control unit 503 such as a CPU that executes a program. When the control unit executes the server program and controls the storage unit 501 and the communication unit 502, the service server 50 has a function of transmitting HTML data and a script in response to a request from the mobile phone 10.

1-6. Service server 60
FIG. 11 is a diagram illustrating a configuration of the service server 60. The service server 60 is a server managed and operated by a company C, which is a third party who is not a provider of electronic money services. Company C operates a shopping site using the service server 60 and conducts a mail order business. The service server 60 includes a product database in which products and product attributes (name, quantity, unit price, image, etc.) are recorded, a point database in which points the user has, HTML data for providing information related to shopping, A server program for functioning as a server is stored in a storage unit 601 such as an HDD. The service server 60 includes a communication unit 602 such as a communication interface used for communication via a network, and a control unit 603 such as a CPU that executes a program. When the control unit 603 executes the server program and controls the storage unit 601 and the communication unit 602, the service server 60 transmits HTML data in response to a request from the mobile phone 10, and performs processing related to purchase of the product. It has a function. The HTML data provided by the service server 60 includes a script link provided by the service server 30 or the service server 50. That is, a script provided by the service server 30 or the service server 50 can be called through the HTML data.

2. Operation 2-1. Script The mobile phone 10 has a function of executing a script from the browser 130 (more specifically, by the function of the script processing engine 131). In this example, the script is described by a Java (registered trademark) script which is an object-oriented programming language. Here, the script executed from the browser includes a script for accessing the IC card 500. “Accessing the IC card 500” means setting a storage area in the memory 504 of the IC card 500, reading data from the set storage area, writing data to the storage area, or storing It means to erase the data stored in the area. The script for accessing the IC card 500 includes a script for performing new registration (hereinafter referred to as “registration script”), a script for reading data (hereinafter referred to as “read script”), and a script for writing data. (Hereinafter referred to as “write script”) and scripts for deleting registered data (hereinafter referred to as “delete script”).

2-1-1. Registration Script The registration script is a script for setting a new storage area in the memory 504 of the IC card 500 and writing initial data in the set storage area. The registration script is used when “issuing” electronic money or an electronic ticket.

  FIG. 12 is a sequence diagram showing processing by a registration script. In the following, software such as “browser”, “mailer”, “script processing engine”, “API”, “script”, “OS”, etc. will be described as the subject of processing. This means that the CPU 102 that executes the instructions included in the command performs processing in cooperation with hardware resources such as the RAM 104, the display unit 107, and the communication unit 108. For example, when it is described that “the browser displays a page according to the HTML data”, the CPU 102 executing the browser program interprets the HTML data and causes the display unit 107 to display a page (image) corresponding to the HTML data. Means that. Alternatively, when it is described that “API delivers data to the browser”, the CPU 102 executing the API stores the data in a predetermined storage area, then executes the browser and reads the data from the storage area. means. In addition, when it is described that “the mailer displays an e-mail message”, the CPU 102 executing the e-mail program interprets the e-mail data and displays an image indicating the content of the e-mail on the display unit 107. It means that In FIG. 12, the browser 130 and the script processing engine 131 are described separately, but the script processing engine 131 is a part of the function of the browser 130 as described above.

  In step S100, the browser 130 reads a registration script. That is, the browser 130 requests the service server 30 to transmit a registration script. When receiving the request for transmitting the registration script from the mobile phone 10, the service server 30 transmits the registration script to the mobile phone 10 (step S101). The browser 130 passes the read registration script to the script processing engine 131 (step S102).

  FIG. 13 is a diagram illustrating a specific example of HTML data for instructing reading of a registration script. In this example, the script is called as an external link using an HTML object tag. If the HTML of a single page includes two links, a balance display script of company A and a balance display script of company B, these scripts are based on predetermined rules (for example, the order described in HTML). Is called in turn. Hereinafter, description will be made with reference to FIG. 12 again.

  When the registration script is received, the script processing engine 131 performs processing in accordance with an instruction described in the script. In step S <b> 103, the script processing engine 131 transmits a ticket issuing request to the remote issuing server 40. Specifically, it is as follows. The registration script includes a command group for calling a server communication start API from the API group 132. When the CPU 102 executes these command groups, the server communication start API is activated. The server communication API calls the client software 121. The client software 121 communicates with the remote issuing server 40 via the communication unit 108. That is, the client software 121 transmits a ticket issuing request to the remote issuing server 40. The ticketing request includes information used for processing in the remote issuing server 40, for example, an identifier for identifying the service of company A and information indicating the user's attributes (hereinafter referred to as “user information”). In FIG. 12, processing such as an API or a device driver called from the registration script is also described as processing of the script processing engine 131 that executes the registration script. The same applies to the other drawings.

  When the ticket issuing request is received, the remote issuing server 40 generates information used for the ticket issuing process (hereinafter referred to as “ticket issuing information”) (step S104). The ticket issuing information includes, for example, an identifier for specifying a service and a user, and initial data written in the IC card 500. When the ticket issuing information is generated, the remote issuing server 40 stores the generated ticket issuing information and corresponding user information. The remote issuing server 40 transmits the ticket issue information to the mobile phone 10 (step S105). The client software 121 of the mobile phone 10 receives the ticket issue information and delivers the received ticket issue information to the script processing engine 131.

  In step S106, the script processing engine 131 performs ticketing processing using the ticketing information. That is, the CPU 102 executing the registration script sets a service area for company A in the memory 504 of the IC card 500, and specifies an identifier for specifying the service of company A and the mobile phone 10 in the set area. A command for writing the identifier is transmitted to the IC chip 502. Upon receiving an instruction from the CPU 102, the processor 503 of the IC chip 502 sets an area for company A's service in the memory 504, and specifies an identifier for identifying the company A's service and the mobile phone 10 in the set area. Write the identifier. Furthermore, the processor 503 receives an instruction from the CPU 102 and writes an initial value of service data for the company A (hereinafter, this data is referred to as “service data”) in the memory 504. Taking the case where the service of company A is electronic money as an example, the service data is data on the balance of electronic money. Alternatively, in another example, if the service is a point card, the service data is a balance of points, and if the service is a ticket issuing service such as an admission ticket or a ticket, the service data includes information identifying the ticket ( Date, seat, etc.).

  When the ticketing process is completed, the script processing engine 131 transmits a notification to the effect that the ticketing has been completed to the remote issuing server 40 (step S107). This notification includes an identifier that identifies the issued service and the mobile phone 10.

  Further, the script processing engine 131 transmits information used for service registration, in this example, user information, an identifier for identifying the service of company A, and an identifier for identifying the mobile phone 10 to the service server 30 (step S108). The service server 30 stores (registers) the information received from the mobile phone 10 (step S109). When the registration of the information is completed, the service server 30 transmits a notification that the registration is completed to the mobile phone 10 (step S110). This notification includes HTML data for displaying the registered information. Upon receiving this notification, the script processing engine 131 passes the HTML data included in the notification to the browser 130 (step S111), and ends the processing by the registered script. The browser 130 displays information according to the acquired HTML data. The processes of steps S103, S106, S107, S108, and S111 are processes performed by the script processing engine 131 in accordance with instructions described in the registration script.

2-1-2. Read Script FIG. 14 is a sequence diagram showing processing by the read script. The read script is a script for reading data from a storage area already set in the memory 504 of the IC card 500. Specific examples of the read script include a “balance display script” for displaying the balance of electronic money and point cards, and a “content display script” for confirming the contents of the electronic ticket.

  The read script includes a group of instructions for calling a data read API for reading service data. The data read API is executed by the CPU 102 executing these instruction groups.

  In step S200, the browser 130 reads the read script. That is, the browser 130 requests the service server 30 to transmit a read script. When receiving the request for transmitting the read script from the mobile phone 10, the service server 30 transmits the read script to the mobile phone 10 (step S201). The browser 130 passes the read script that has been read to the script processing engine 131 (step S202).

  When the read script is received, the script processing engine 131 performs processing in accordance with an instruction described in the script. In step S203, the script processing engine delivers an identifier (hereinafter referred to as “service ID”) for identifying the service of company A to the reading API (that is, identifies the service). The service ID is included in the script itself, the file name of the script, or the HTML tag. The data reading API transmits a request to deliver the service data read from the storage area corresponding to the service ID to the IC chip 502 of the IC card 500. This request includes the service ID of company A.

  In step S <b> 204, the script processing engine 131 reads service data from the IC chip 502. Specifically, it is as follows. Upon receiving a data delivery request from the data read API, the processor 503 of the IC chip 502 reads service data (in this example, electronic money balance) from the storage area corresponding to the service ID included in the request in the memory 504. The read service data is delivered to the data read API. The data read API passes the acquired service data to the script processing engine 131.

  In step S205, the script processing engine 131 delivers the acquired service data to the browser 130, and ends the read script processing. The browser 130 displays information based on the acquired service data. The processes in steps S203 to S205 are processes performed by the script processing engine 131 in accordance with instructions described in the read script.

2-1-3. Write Script FIG. 15 is a sequence diagram showing processing by a write script. The writing script is a script for writing data in a storage area already set in the memory 504 of the IC card 500 or rewriting data already stored. Specific examples of the writing script include a charge script for “charging” electronic money and point cards (processing to increase the balance), “settlement” and “using points” for electronic money and point cards (processing to reduce the balance) There is a settlement script to do this.

  In step S300, the browser 130 reads the writing script. That is, the browser 130 requests the service server 30 to transmit a write script. When receiving the request for sending the write script from the mobile phone 10, the service server 30 sends the write script to the mobile phone 10 (step S301). The browser 130 passes the read writing script to the script processing engine 131 (step S302).

  In step S303, the script processing engine 131 calls the data writing API, and delivers the service ID of company A and the target data to be written (for example, data indicating the amount to be settled or the amount to be charged) to the data writing API. The data writing API transmits a request to write the target data to the storage area corresponding to the service ID to the IC chip 502 of the IC card 500. This request includes an identifier for identifying the service of company A and target data.

  Upon receiving a data write request, the processor 503 of the IC chip 502 determines whether the write request satisfies a predetermined constraint (step S304). For example, in the case where the write request is a process of reducing the balance indicated by the service data such as “settlement” or “use of points”, the constraint condition is a value to be subtracted from the service data (amount of settlement or used Point) is less than the balance of the service data. Alternatively, the constraint condition is a condition that, in the case of processing for increasing the balance indicated by the service data such as “charge” as the write request, the balance after processing is equal to or less than a predetermined upper limit value. Note that, depending on the type of write request, it is not necessary to perform the process of determining whether or not the constraint condition is satisfied.

  If it is determined that the write request satisfies the constraint condition (S304: YES), the processor 503 moves the process to step S305. When it is determined that the write request does not satisfy the constraint condition (S304: NO), the processor 503 transmits an error message indicating that to the script processing engine 131 via the data write API. Upon receiving the error message, the script processing engine 131 notifies the browser 130 that an error has occurred (step S312), and ends the process.

  In step S <b> 305, the processor 503 transmits a data write request to the remote issuing server 40. Specifically, it is as follows. The processor 503 calls a server communication API. The server communication API calls the client software 121. The client software 121 communicates with the remote issuing server 40 via the communication unit 108. That is, the client software 121 transmits a data write request to the remote issuing server 40. The write request includes information used for authentication in the remote issuing server 40, for example, the service ID of company A and the identifier of the mobile phone 10.

  When receiving the data write request from the mobile phone 10, the remote issuing server 40 authenticates the received write request (step S306). For the authentication, an encryption technique and an electronic signature technique described later are used. Alternatively, information such as the service ID of company A and the identifier of the mobile phone 10 may be used for authentication. When the authentication process is performed, the remote issuing server 40 transmits the authentication result to the mobile phone 10 (step S307).

  The processor 503 of the IC chip 502 receives the authentication result from the remote issuing server 40 (via the server communication API and the client software 121). The processor 503 determines the next process to be performed according to the authentication result (step S308). When the authentication is successful (step S308: YES), the processor 503 writes the target data in a storage area corresponding to the service of company A in the memory 504 (step S309). When the target data is written in the storage area, the processor 503 transmits a notification to the effect that the writing has been completed to the script processing engine 131 (step S310). When the script processing engine 131 receives the notification that the writing has been completed, the script processing engine 131 notifies the browser 130 that the writing has been completed (step S311), and ends the processing by the writing script.

  If the authentication has failed (step S308: NO), the processor 503 does not write the target data in the memory 504, and transmits a notification that the authentication has failed to the script processing engine 131. When the script processing engine 131 receives the notification that the authentication has failed, the script processing engine 131 notifies the browser 130 that the authentication has failed (step S313), and ends the processing by the writing script. The processes in steps S303, S311, S312 and S313 described above are processes performed by the script processing engine 131 in accordance with the instructions described in the writing script.

2-1-4. Deletion Script The deletion script is a script for deleting data in the storage area set in the memory 504 of the IC card 500 and deleting a service corresponding to the storage area from the IC card 500. The deletion script is used when “deleting” electronic money or an electronic ticket.

  FIG. 16 is a sequence diagram showing processing by a deletion script. In step S400, the browser 130 reads the deletion script. That is, the browser 130 requests the service server 30 to transmit a deletion script. When receiving the request for transmission of the deletion script from the mobile phone 10, the service server 30 transmits the deletion script to the mobile phone 10 (step S401). The browser 130 passes the read deletion script to the script processing engine 131 (step S402).

  When the deletion script is received, the script processing engine 131 performs processing according to an instruction described in the script. In step S <b> 403, the script processing engine 131 transmits a deletion request to the remote issuing server 40. The deletion request includes information used for processing in the remote issuing server 40, for example, the service ID of the company A and user information.

  When receiving the deletion request, the remote issuing server 40 generates information used for the deletion process (hereinafter referred to as “deletion information”) (step S404). The deletion information includes, for example, an identifier that identifies a service and a user to be deleted. When the deletion information is generated, the remote issuing server 40 deletes the stored user information from the storage means such as the HDD. The remote issuing server 40 transmits the deletion information to the mobile phone 10 (step S405). The client software 121 of the mobile phone 10 receives the deletion information and passes the received deletion information to the script processing engine 131.

  In step S406, the script processing engine 131 performs a deletion process using the deletion information. That is, the CPU 102 executing the deletion script transmits to the IC chip 502 a command for deleting the service area for Company A set in the memory 504 of the IC card 500. In response to an instruction from the CPU 102, the processor 503 of the IC chip 502 deletes (deletes) all data stored in the service area for Company A set in the memory 504.

  When the deletion process is completed, the script processing engine 131 transmits a notification that the deletion is completed to the remote issuing server 40 (step S407). This notification includes an identifier that identifies the deleted service and the mobile phone 10.

  Further, the script processing engine 131 transmits information for identifying the deleted service, in this example, user information, a service ID of company A, and an identifier for identifying the mobile phone 10 to the service server 30 (step S408). The service server 30 deletes the data stored in the storage means such as the HDD using the information received from the mobile phone 10 (step S409). When the deletion of information is completed, the service server 30 transmits a notification that the deletion is completed to the mobile phone 10 (step S410). This notification includes HTML data for displaying that the service has been deleted. Upon receiving this notification, the script processing engine 131 passes the HTML data included in the notification to the browser 130 (step S411), and ends the processing by the deletion script. The browser 130 displays information according to the acquired HTML data. The processes in steps S403, S406, S407, S408, and S411 are processes performed by the script processing engine 131 in accordance with the instructions described in the deletion script.

2-2. IC card list 2-2-1. Outline of IC Card List In this example, in the mobile phone 10, services registered in the IC card 500 are managed using the IC card list.

  FIG. 17 is a diagram illustrating an IC card list. The IC card list is stored in the storage unit 105. In this example, the IC card list includes records of “area ID”, “service ID”, “activation mode”, “URL”, and “ticketed”. “Area ID” is an identifier for specifying a storage area in the memory 504. “Service ID” is an identifier for identifying a service registered in the storage area. The “startup mode” is an identifier indicating whether the software that can access the storage area (access is permitted) is a script or a dedicated application. In this example, the identifier “application” can be accessed by a dedicated application program (hereinafter this state is referred to as “application mode”), and the identifier “browser” can be accessed by script (hereinafter this state). "Browser mode"). The application mode and the browser mode are collectively referred to as “startup mode”. “URL” is information indicating the location of a script when the accessible software is a script. “Ticketed” is a flag indicating whether or not ticketing has been completed for the corresponding service. The flag “Done” indicates that ticketing has been completed. The flag “incomplete” indicates that ticketing has not been completed.

  In this example, data related to the service specified by the service ID “A company money” is stored in the storage area specified by the area ID “0001”. Further, it is indicated that the startup mode of the company A money is the application mode. In the storage area specified by the area ID “0002”, data related to the service specified by the service ID “B company money” is stored. Further, it is indicated that the startup mode of the B company money is the browser mode. Furthermore, it is indicated that the location of this script is “http://www.b-money.com/”. In this example, for the browser mode service, there is no distinction between issued and unissued tickets, and the record is blank.

  FIG. 18 is a diagram illustrating a screen displayed on display unit 107 in accordance with the IC card list. FIG. 18 shows a screen displayed according to the IC card list of FIG. Character strings 601, 602, 603 and 604 are character strings indicating service IDs. The icon 605 is an image indicating that the activation mode is the application mode. The icon 606 is an image indicating that the activation mode is the browser mode. The icon 607 is an image indicating that the corresponding service has been issued. The icon 608 is an image indicating that the corresponding service has not been issued. The image display shown in FIG. 18 is performed by a list management program. In this example, there is no distinction between issued and unissued tickets in the browser mode, but an icon 607 is displayed for convenience. As for the application mode service, since the ticket is issued and not issued, an icon corresponding to the ticket issuing state is displayed.

2-2-2. Registration to IC card list (browser mode)
FIG. 19 is a sequence diagram showing registration processing of a new service (browser mode) to the IC card list. In this example, registration of a new service in the IC card list is performed in accordance with the ticketing process in step S106 of FIG. In this example, the registration script downloaded in step S101 in FIG. 12 includes data for registering a service in the IC card list, for example, an area ID, a service ID, and a URL.

  In step S <b> 501, the script processing engine 131 acquires ticketing information from the remote issuing server 40. When the ticket issuing information is acquired, the script processing engine 131 instructs the IC card 500 to issue a ticket (step S502). When receiving an instruction from the script processing engine 131, the processor 503 of the IC card 500 sets an area in the memory 504, and writes initial data in the set area (step S503). When the writing of the initial data is completed, the processor 503 notifies the script processing engine 131 to that effect.

  When the ticketing process is completed, the script processing engine 131 instructs the list management program 150 to register the service in the IC card list (step S504). The instruction from the script processing engine 131 to the list management program 150 includes information used for registration in the IC card list, in this example, an area ID, a service ID, and a URL.

  When the script processing engine 131 is instructed to register a service, the list management program 150 updates the IC card list using information included in the instruction (step S505). When a service is newly registered, the list management program 150 newly creates a record including the area ID included in the instruction in step S504 in the IC card list, and registers the service ID in this record. In this example, the “startup mode” is set to “browser”. When the update of the IC card list is completed, the list management program 150 notifies the script processing engine 131 that the update of the IC card list is completed (step S506). When the update completion is notified from the list management program 150, the script processing engine 131 notifies the remote issuing server 40 that the ticketing process is completed (step S507). This process corresponds to the process in step S107 of FIG. The processes in steps S501 to S506 are performed along with the process in step S106 in FIG. Thereafter, the process shown in FIG. 12 is performed.

2-2-3. Registration to IC card list (application mode)
FIG. 20 is a sequence diagram showing registration processing of a new service (application mode) in the IC card list. In this example, registration of a new service to the IC card list is performed with the installation of the dedicated application 140.

  When a predetermined event (for example, an event that a button for starting a new registration of an application mode service is pressed on the screen displayed by the browser) occurs, the browser 130 is dedicated from a server connected to the network 70. The application 140 is downloaded (step S601).

  In this example, the installation of the dedicated application 140 uses three files: an ADF (Application Descriptor File), an SDF (Security Descriptor File), and a Jar (Java ARchive) file. The ADF is a file that defines application program attributes. The ADF includes information specifying the URL of the SDF and the Jar file. The SDF is a file including information for specifying a Jar file. The Jar file is an application program entity file. In step S601, the ADF is downloaded. When the ADF is downloaded, the browser 130 instructs the JAM 119 to install the dedicated application 140 using the ADF. When receiving the instruction, the JAM 119 installs the dedicated application 140 using the ADF.

  The installation of the dedicated application 140 in step S602 is performed as follows, for example. The JAM 119 acquires the SDF from the resource specified by the URL described in the acquired ADF. The JAM 119 confirms that the Jar file specified by the information described in the ADF and the Jar file specified by the information described in the SDF are the same. When it is confirmed that the Jar files specified by the ADF and the SDF are the same, the JAM 119 acquires the Jar file. The URL of the Jar file is described in ADF.

  When acquiring the Jar file, the JAM 119 installs the dedicated application 140. Installation refers to storing information used to start an application program and an entity file of the application program in the storage unit 105.

  When the installation is completed, the JAM 119 instructs the list management program 150 to register the service in the IC card list (step S603). The instruction from the JAM 119 to the list management program 150 includes information used for registration in the IC card list, in this example, an area ID and a service ID.

  When the JAM 119 is instructed to register a service, the list management program 150 updates the IC card list using information included in the instruction (step S604). When a service is newly registered, the list management program 150 newly creates a record including the area ID included in the instruction in step S603 in the IC card list, and registers the service ID in this record. In this example, “activation mode” is set to “application”. At this time, the “issued ticket” flag is set to “incomplete”. When the update of the IC card list is completed, the list management program 150 notifies the JAM 119 that the update of the IC card list is completed (step S605).

  When notified of the completion of the update of the IC card list, the JAM 119 activates the dedicated application 140 in order to perform ticketing processing (step S606). Alternatively, the dedicated application 140 may be manually activated by the user. In this case, the JAM 119 or the OS 111 displays a message prompting the user to start the dedicated application 140. When activated, the dedicated application 140 performs ticketing processing. Although the subject of the ticketing process is not the script processing engine 131 but the dedicated application 140, the contents of the ticketing process are the same as those described in steps S103 to S106 of FIG. That is, the dedicated application 140 communicates with the remote issuing server 140 and acquires ticketing information (step S607). When the ticket issuing information is acquired, the dedicated application 140 instructs the IC card 500 to issue a ticket (step S608). Upon receiving a ticketing instruction, the processor 503 of the IC card 500 sets an area in the memory 504 and writes initial data (step S609).

  When the ticketing process is completed, the dedicated application 140 notifies the list management program 150 that the ticketing process has been completed. The notification from the dedicated application 140 to the list management program 150 includes information used for registration in the IC card list, in this example, an area ID and a service ID.

  When the completion of the ticketing process is notified from the dedicated application 140, the list management program 150 updates the IC card list using the information included in the notification (step S610). Here, the value of the flag “issued ticket” is set to “completed”. When the update of the IC card list is completed, the list management program 150 notifies the dedicated application 140 that the update of the IC card list is completed (step S611). When the update completion is notified from the list management program 150, the dedicated application 140 notifies the remote issuing server 40 that the ticketing process has been completed (step S612). Thereafter, processing according to the operation of the dedicated application 140 is performed.

2-2-4. Switching from Browser Mode to Application Mode FIG. 21 is a diagram illustrating a process for switching from the browser mode to the application mode. Here, a case where the service of company B can be switched from the browser mode to the application mode will be described as an example. Switching from the browser mode to the application mode is performed when the browser 130 receives HTML data that triggers the switching. Details are as follows.

  In step S701, the browser 130 receives HTML data from the service server 50 (the service server of company B). The HTML data includes information that triggers switching to the application mode, for example, a link to an instruction to download a dedicated application of company B (hereinafter referred to as “dedicated application 140B”). This link includes an identifier indicating that the application program to be downloaded is an application program for accessing the IC card 500. This identifier is included in the file name of the application program, for example. Alternatively, this identifier may be included in the HTML tag of the link. Further alternatively, this identifier may be included in the ADF or SDF.

  When the download of the dedicated application 140B is requested, the browser 130 notifies the list management program 150 to that effect (step S702). Upon receiving the notification from the browser 130, the list management program 150 confirms whether the service corresponding to the dedicated application to be downloaded is already registered in the IC card list in either the browser mode or the application mode (step S703). . That is, the list management program 150 reads the IC card list from the storage unit 105, and the service ID corresponding to the dedicated application 140B (in this example, “B company money”) is already registered in the read IC card list. Judge whether it has been.

  The service ID of the dedicated application to be downloaded is included in, for example, a link, a file name, or an HTML tag. Alternatively, the service ID may be included in ADF or SDF. In this case, the browser 130 downloads ADF or SDF prior to the determination in step S703.

  When the service corresponding to the dedicated application to be downloaded is already registered in the IC card list in the application mode (S703: application mode), the list management program 150 displays that fact and cancels the download. The browser 130 is instructed (step S704). In response to this instruction, the browser 130 displays that the service has already been registered in the application mode, and stops the download (step S705). Thus, double registration of the dedicated application 140B is prevented. When the download is stopped, the browser 130 or the OS 111 activates the dedicated application 140B.

  If the service corresponding to the dedicated application to be downloaded is already registered in the browser mode in the IC card list (S703: browser mode), the list management program 150 instructs the browser 130 to change the activation mode (step) S706). In response to this instruction, the browser 130 displays that the activation mode is switched to the application mode (step S707). Furthermore, the browser 130 downloads the dedicated application 140B (step S708). Note that the process of step S707 may be omitted. Alternatively, in step S707, the browser 130 may request the user to approve the activation mode change, and if approved, the browser 130 may shift the process to step S708.

  After downloading the dedicated application 140B in step S708, the dedicated application 140B is installed in the same manner as the flow of FIG. However, in this case, the service (the service with the service ID “B company money” in this example) is not newly registered, but is already registered in the IC card list. If it is not a new registration of the service, the area is already set in the IC card 500 and the initial data is written, so the processes of steps S605, 606, 607, 608, and 609 are not performed. That is, when registration to the IC card list is instructed in step S603, the list management program 150 determines whether the registration instruction is for new registration or activation mode switching. In the case of new registration, the list management program 150 operates as already described in the flow of FIG. In the case of switching the activation mode, the list management program rewrites the activation mode of the IC card list in step S604, and then skips the processes in steps S605 to S609 and moves the process to step S610.

  When it is determined that the service corresponding to the dedicated application to be downloaded is not yet registered in the IC card list (S703: unregistered), the list management program 150 instructs the browser 130 to download the dedicated application 140. (Step S709). In response to this instruction, the browser 130 downloads the dedicated application 140B (step S710).

  After downloading the dedicated application 140B in step S710, the dedicated application 140B is installed according to the flow of FIG. Along with the installation, new registration of the service to the IC card list is performed. Note that the JAM 119 or the OS 111 may activate the dedicated application 140B after the installation of the dedicated application 140B is completed.

2-2-5. Switching from Application Mode to Browser Mode FIG. 22 is a diagram illustrating a switching process from the application mode to the browser mode. Switching from the application mode to the browser mode is performed when the browser 130 receives HTML data that triggers the switching. Details are as follows. In FIG. 22, processing by the browser 130 and the script processing engine 131 is described as browser processing. Here, a case where the service of company A is switched from the application mode to the browser mode will be described as an example.

  In step S801, the browser 130 receives HTML data from the service server 30 (the service server of company A). The HTML data includes information for triggering switching to the browser mode, for example, a script for accessing the service of company A (hereinafter simply referred to as “script of company A”). This HTML data includes an identifier indicating that the script to be activated is a script for accessing the IC card 500. This identifier is included in the file name of the script, for example. Alternatively, this identifier may be included in the HTML tag of the link. Further alternatively, this identifier may be included in the script itself. When the user performs an operation of selecting this link, the browser 130 requests the script processing engine 131 to start the script of company A according to this instruction. When the script of the company A is requested to be activated, the script processing engine 131 instructs the list management program 150 to determine whether the activation mode needs to be changed (step S802).

  When receiving an instruction from the script processing engine 131, the list management program 150 confirms whether the service corresponding to the script to be started is already registered in the IC card list in either the browser mode or the application mode (step S803). ). That is, the list management program 150 reads the IC card list from the storage unit 105, and the service ID (in this example, “A company money”) corresponding to the script of company A is already included in the read IC card list. Determine if it is registered. The service ID of the script to be started is included in, for example, the script itself, the script file name, or the HTML tag.

  If it is determined that the service corresponding to the script to be activated is not yet registered in the IC card list (S803: not registered), or the service corresponding to the script to be activated is already in the IC card list in the browser mode. If registered (S803: browser mode), the list management program 150 instructs the browser 130 to execute the script (step S804). Upon receiving this instruction, the browser 130 delivers the script to the script processing engine 131. Thereafter, the script is executed according to the flow of any of the processes after step S103 in FIG. 12 and the processes after steps S203, S303, and S403 in FIGS. If the service has not yet been registered in the IC card list, registration in the IC card list is performed according to the flow of FIG. Note that if the registration script is already registered in the IC card list in the browser mode, there is a possibility that double registration occurs and a problem may occur, so the list management program 150 may prohibit the execution of the registration script. .

  When the service corresponding to the script to be activated is already registered in the IC card list in the application mode (S803: application mode), the list management program 150 instructs the browser 130 to change the activation mode ( Step S805). In response to this instruction, the browser 130 displays that the activation mode is switched to the browser mode (step S806). In addition, the list management program 150 shifts the processing to step S807. The browser 130 may reject the mode switching according to a user instruction or the like. In this case, the browser 130 notifies the list management program 150 that mode switching has been rejected before the process of step S807. Further, the browser 130 (script processing engine 131) executes the script as much as possible (for example, the registration script is not executed, but the read script is executed). Alternatively, the browser 130 may display that a script execution error has occurred.

  In step S807, the list management program 150 rewrites the IC card list). That is, in the IC card list, the list management program 150 sets the startup mode of the A company money to “browser”, and records the URL of the script of the A company in the “URL” record. The URL of the script of company A is included in the instruction in step S802, for example. Alternatively, at this stage, the list management program 150 may acquire the URL of the script of company A from the browser 130. When the IC card list is updated, the list management program 150 moves the process to step S804. Thereafter, as already described, the processes of FIGS. 12 and 14-16 are performed according to the type of script.

  The list management program 150 may instruct the JAM 119 to uninstall the dedicated application 140 whose activation mode has been rewritten to the browser mode after the rewriting of the IC card list in step S807 is completed. Upon receiving this instruction, the JAM 119 uninstalls the corresponding dedicated application 140.

2-2-6. Activation from IC Card List FIG. 23 is a flowchart showing processing for activating a browser or an application program from the IC card list. Here, the state where the screen of FIG. 18 is displayed by the list management program 150 will be described as an example.

  In step S901, the list management program 150 selects one item (service) from the IC card list in accordance with a user operation. The list display application activates software corresponding to the selected item.

  When starting the software, the list management program 150 determines the next process according to the type of software to be started (step S902). When activation of a script is requested (step S902: script), the list management program 150 shifts the processing to step S903. If activation of the application program is requested (step S902: application), the list management program 150 shifts the processing to step S905.

  In step S903, the list management program 150 acquires a script and requests the browser 130 to execute the acquired script. This request includes the URL of the script. The browser 130 acquires a script from the URL included in the request. The script processing engine 131 activates and executes the acquired script (step S904).

  In step S905, the list management program 150 activates and executes the requested dedicated application 140.

3. Security Next, the security of the service described above will be described. Although detailed description has been omitted so far, encryption technology is used for accessing the IC card 500 by a script.

FIG. 24 is a diagram showing an outline of encryption technology used in the communication system. The certificate authority CA is a certificate authority that is managed and operated by a predetermined operator (for example, a line operator of the mobile phone 10). The certificate authority CA issues the certificate authority's private key K _pr ^CA and public key K _pub ^CA. Further, the certificate authority CA issues an electronic certificate S _m to the mobile phone 10. The electronic certificate S _m includes the electronic signature of the certificate authority CA and the public key K _pub ^CA. The mobile phone 10 stores an electronic certificate _Dm .

The certificate authority CA issues a secret key K _pr ^CP and a public key K _pub ^CP to the service provider. In FIG. 24, company A operating the service server 30 is illustrated as a service provider. The service provider that has received the key application applies to the certification authority CA to use the IC card service. This application for use includes the public key K _pub ^CP . The certificate authority CA receives the use application and issues an electronic certificate _SCP and ID data indicating the ID of the service provider. The electronic certificate S _CP includes the electronic signature of the certificate authority CA and the public key K _pub ^CP . The electronic signature of the certificate authority CA is obtained by encrypting the message digest of the public key K _pub ^CP using a hash function with the private key K _pr ^CA. The service server 30 stores a private key K _pr ^CP , a public key public key K _pub ^CP , an electronic certificate S _CP and ID data.

The script that the service server 30 transmits to the mobile phone 10 is a package of an execution code (script body), an electronic certificate _SCP , and ID data. Upon receiving the script, the mobile phone 10 extracts the electronic certificate S _CP from the package. Mobile phone 10, the extracted digital signature included in the electronic certificate S _CP, decoded by the public key K _pub ^CA included in the electronic certificate _Dm, to acquire a message digest. Further, the mobile phone 10 applies a hash function to the public key K _pub ^CA included in the electronic certificate _Dm , and generates a message digest. The mobile phone 10 compares the generated message digest with the message digest obtained by decryption. If the two match, the mobile phone 10 determines that the script is valid and executes the execution code. If the two do not match, the mobile phone 10 determines that the script is invalid and does not execute the execution code. In the mobile phone 10, these processes are performed by software.

  The above is the technology for confirming the validity of the script received from the service server 30. However, communication using the encryption technology is similarly performed between the IC card 500 and the remote issuing server 40. The IC card 500 stores software for encrypted communication, and performs encrypted communication with the remote issuing server 40 using the software. The specific processing of the encrypted communication described above is merely an example, and other encryption techniques may be used as long as the validity of the communication partner can be confirmed.

4). Other Embodiments The present invention is not limited to the above-described embodiments, and various modifications can be made. Hereinafter, some modifications will be described. Two or more of the following modifications may be used in combination.

4-1. Modification 1
The request for confirming the contents of the IC card list is not limited to that described in the embodiment. In the above-described embodiment, an instruction to confirm the IC card list from the browser 130 to the list management program 150 in step S802 is an example of this request. However, this request may be any data, flag, command, request, or the like as long as it is information for causing the list management program 150 to start checking the IC card list. For example, this request may be an instruction to execute a script. Alternatively, this request may be an instruction to change the activation mode.

4-2. Modification 2
The application program that sends a request for confirming the contents of the IC card list to the list management program 150 is not limited to the browser. That is, the specific data described in a specific format is not limited to HTML data. Any application program may be used as long as it sends a request to the list management program 150 when a predetermined condition is satisfied. For example, the dedicated application 140 may send a request to the list management program 150. Alternatively, the application program that sends the start information may be an application program other than the browser 130 and the dedicated application 140 such as a game program. In this case, the game program sends start information to the list management program 150 when a specific condition is satisfied as part of the process. Alternatively, in yet another example, this application program may send start information to the list management program 150 in response to a user instruction. As the “predetermined condition”, any of a specific operation input, a specific command executed, a specific HTML data received, etc. may be used.

4-3. Modification 3
The instruction (first instruction) for causing the browser 130 to execute the script is not limited to that described in the embodiment. In the embodiment, the instruction from the list management program 150 to the browser 130 in step S804 is an example of the first instruction. However, as long as the first instruction is information for causing the browser 130 to execute a script, the first instruction may be any data, flag, command, request, or the like.

4-4. Modification 4
The instruction (second instruction) for causing the JAM 119 to uninstall the dedicated application 140 is not limited to that described in the embodiment. In the embodiment, it has been described that the dedicated application 140 may be uninstalled after rewriting the list in step S807. In this case, the list management program 150 instructs the JAM 119 to uninstall the dedicated application 140. This is an example of the second instruction. However, the second instruction may be any data, flag, command, request, or the like as long as it is information for causing the JAM 119 to uninstall the dedicated application 140.

4-5. Modification 5
The trigger information that triggers the browser 130 to send a request to the list management program 150 is not limited to that described in the embodiment. In the embodiment, “script” in step S801 in FIG. 22 is an example of opportunity information. However, as long as the trigger information is information that triggers the browser 130 to send a request to the list management program 150, specifically, any information such as data, a flag, a command, and a request may be used. For example, the opportunity information may be a link to a script. Alternatively, the opportunity information may be an instruction for downloading or executing a script.

4-6. Modification 6
12 and 16-16, the operation of each script has been described separately for the function of the script itself and the API and device driver functions called from the script. However, the distribution of functions is limited to that described in the embodiment. Not. For example, a group of instructions for realizing the function described as the API function in the embodiment may be described in the script body. That is, the script body may have the function. Alternatively, a group of instructions for realizing the function described as the script function in the embodiment may be described in an API, a module, another script, a function, or the like other than the script body. In short, as long as the processing shown in FIGS. 12 and 16-16 is realized by a group of instructions described directly or indirectly in the script body, any division of roles among software may be used.

4-7. Modification 7
The programming language for describing the application program is not limited to Java (registered trademark). Other object-oriented programming languages such as C ++ may be used. Alternatively, a non-object oriented programming language may be used. In addition, the process of installing the application program described in steps S601-602 is merely an example, and the file configuration of the application program and the installation procedure are not limited thereto.

4-8. Modification 8
The programming language for describing the script is not limited to the Java script. Other object-oriented programming languages such as C ++ and browser content such as Flash may be used. Alternatively, a non-object oriented programming language may be used.

4-9. Modification 9
The location information indicating the location of the script is not limited to the URL. Any information may be used as long as the location of the script can be specified.

4-10. Modification 10
The “IC card” in this paper does not necessarily have a card shape. The “card” is a word symbolizing the function of the IC card 500 and does not specify the shape. The IC card accesses the memory in accordance with an antenna, a memory having a plurality of storage areas in which access restrictions can be individually set, and a signal from the antenna or a signal from the first control means (CPU 102 in the embodiment). As long as it has the second control means (the processor 503 in the embodiment), its shape may be any. Further, the configuration of the storage area of the memory 504 of the IC card 500 is not limited to that shown in FIG. The memory 504 may not have a free area. Alternatively, the memory 504 may have another third area in addition to the free area.

4-11. Modification 11
The hardware configuration of the mobile phone 10 is not limited to that described with reference to FIG. The mobile phone 10 may have any hardware configuration as long as necessary functions can be realized. In particular, when the mobile phone 10 has a multiprocessor (a plurality of processors) as a configuration that enables parallel processing by a plurality of programs, the plurality of processors as a whole corresponds to the “first control means” in this paper. In this case, each processor may execute a different program. For example, the first processor may execute JAM, and the second processor may execute an application program such as a browser. In this example, the first processor that executes JAM functions as “management means”, and the second processor that executes the browser functions as “first application means”. “The first application means sends data to the management means” means that signals are exchanged between the first processor and the second processor.

4-12. Modification 12
In the above-described embodiment, the program executed by the CPU 102 includes a magnetic recording medium (magnetic tape, magnetic disk (HDD (Hard Disk Drive), FD (Flexible Disk)), etc.), optical recording medium (optical disk (CD (Compact Disk)). , DVD (Digital Versatile Disk), etc.), magneto-optical recording medium, semiconductor memory (flash ROM, etc.) and the like. The program may be downloaded via a network such as the Internet.

DESCRIPTION OF SYMBOLS 3 ... Hinge, 4 ... Keypad, 5 ... Microphone, 6 ... Speaker, 7 ... Antenna, 8 ... Display device, 10 ... Mobile phone, 20 ... Management server, 30 ... Service server, 40 ... Remote issue server, 50 ... Service Server, 60 ... Service server, 70 ... Network, 102 ... CPU, 103 ... ROM, 104 ... RAM, 105 ... Storage unit, 106 ... Operation unit, 107 ... Display unit, 108 ... Communication unit, 109 ... Bus, 111 ... OS 112 ... Application, 113 ... Application, 114 ... Java execution environment, 115 ... First storage, 116 ... Second storage, 117 ... Class library, 118 ... JVM, 119 ... JAM, 120 ... API group, 121 ... Client software, 122 ... Device driver, 500 ... IC card, 501 ... Antenna, 502 ... IC chip, 503 ... processor, 504 ... memory, 510 ... reader / writer, 601 ... string, 605 ... icon 606 ... icon 607 ... icon 608 ... icon

Claims (6)

A communication means for communicating via a network;
A first application program for executing a specific process, a second application program different from the first application program, a script that operates on the first application program, and the second application program are managed. First control means for executing a first management program;
An antenna, a memory having a plurality of storage areas in which access restrictions can be individually set, the memory is accessed according to a signal from the antenna or a signal from the first control means, and the access result is An IC card having second control means for outputting to one control means;
The first identifier for specifying the storage area set in the memory and the software that can access the storage area specified by the first identifier are either the script or the second application program. Storage means for storing a list including a second identifier indicating an activation mode indicating
The second application program is a program for accessing a storage area of the plurality of storage areas;
The script includes a group of instructions for accessing the one storage area,
The first control means executing the first management program functions as a first management means;
The first control means executing the first application program functions as first application means;
The first control means executing the second application program functions as second application means;
The first management means receives a request to confirm the contents of the list from the first application means,
When the request is received, when the second identifier corresponding to the first identifier indicating the one storage area in the list is an identifier indicating an activation mode corresponding to the second application program The first management means sets the list so that the second identifier corresponding to the first identifier indicating the one storage area in the list is an identifier indicating an activation mode corresponding to the script. A mobile terminal characterized by updating. The first application program includes a group of instructions for executing the script,
After the update of the list, the first management means gives a first instruction to cause the first application means to execute the script,
The portable terminal according to claim 1, wherein upon receiving the first instruction, the first application unit executes the script. The first control means executes a second management program for managing uninstallation of the second application program;
The first control means executing the second management program functions as a second management means;
When the list is updated, the first management unit instructs the second management unit to perform a second instruction for uninstalling the second application program,
3. The mobile terminal according to claim 1, wherein upon receiving the second instruction, the second management unit uninstalls the second application program. 4. When the request is received, when the second identifier corresponding to the first identifier indicating the one storage area in the list is an identifier indicating an activation mode corresponding to the script, or the one When the second identifier corresponding to the first identifier indicating the storage area is not included in the list, the first management unit instructs the first application unit to execute the script. The mobile terminal according to claim 1, wherein the mobile terminal is a mobile terminal. Having display means for displaying information;
The specific process is a process of receiving specific data described in a specific format from the network via the communication unit, and displaying information based on the received specific data on the display unit,
The first application means sends the request to the first management means when receiving the specific data including the trigger information that triggers the execution of the script. The portable terminal as described in any one of Claims 1-4. A communication means for communicating via a network;
A first application program for executing a specific process, a second application program different from the first application program, and a first control means for executing a script operating on the first application program;
An antenna, a memory having a plurality of storage areas in which access restrictions can be individually set, the memory is accessed according to a signal from the antenna or a signal from the first control means, and the access result is An IC card having second control means for outputting to one control means;
A first identifier for specifying a storage area set in the memory and software capable of accessing the storage area specified by the first identifier are the first application program and the second application program. Storage means for storing a list including a second identifier indicating a startup mode indicating which one of
In the portable terminal which is a program for the second application program to access one of the plurality of storage areas ,
The first control means receiving a request to confirm the contents of the list;
When the request is received, when the second identifier corresponding to the first identifier indicating the one storage area in the list is an identifier indicating an activation mode corresponding to the second application program The first control means sets the list so that the second identifier corresponding to the first identifier indicating the one storage area in the list is an identifier indicating an activation mode corresponding to the script. A management program for executing the step of updating and.

Images