JP2004086890A - Supply method for application program, smart card, script supply method, terminal device, and storage medium with application program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method which enables a plurality of kinds of games to be replaced by increasing flexibility as to application programs, e.g. a game program on an IC card system which has high-level information storage capacity and can actualize high security. <P>SOLUTION: Commonizable treatment parts are provided as components and the components wherein definitions of games are described as scripts are replaced from a terminal when necessary. In a program, an interpreter which interprets and executes a script, a control part which controls the replacement of a script, and a control part which controls point data and game execution right are prepared. Consequently, different kinds of games are dynamically changed and one application handles different kinds of games. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an application program supply method, a smart card, a script supply method, a terminal device, and a storage medium having an application program, and more particularly to a computer system having high security, in particular, storing an application program in a nonvolatile memory, The present invention relates to a computer system having an IC card as a core capable of executing an application program inside.
[0002]
[Prior art]
An IC card (or smart card) that has a CPU (Central Processing Unit) built into the IC chip and can perform calculations inside the card has a high level of information storage capability and high security. In recent years, it has been actively introduced in the financial field such as electronic money.
[0003]
Recently, a card OS (Operating System) that allows a plurality of applications to coexist safely on a single card has become common. As such multi-application compatible card OSs, “MULTIS” by Mondex International, “Java Card” (Java is a registered trademark) by Sun Microsystems, etc. are known. The multi-application compatible IC card managed by such an OS is controlled so that the independence between application programs is high, and not only can a plurality of applications coexist safely, but a new application can be added to the issued card. Programs can be added and unnecessary application programs can be deleted, and can be regarded as a safe computer, not just as an information storage medium. From the viewpoint of taking advantage of the high security of the card or replacing the conventional magnetic card function, it is expected to be applied in the financial field such as credit card and electronic money, especially the cooperation of multiple applications.
[0004]
2. Description of the Related Art Conventionally, a system such as a point system or a loyalty program (hereinafter referred to as a point system) has been generalized as a means for enclosing customers. This is defined as “a system in which points are added according to the use of a card and a predetermined service can be received by accumulating the points”. Aiming. Examples of systems are point systems such as shopping center stamp cards and department stores, or airline mileage programs. For example, in the department store point system as an example, when a member possesses a card and presents the card when shopping at the relevant department store, points are accumulated according to sales along with the purchase history (for example, every 1000 yen shopping) 20 points can be added), when a certain amount of points are accumulated, it can be exchanged for a gift certificate that can be used at the department store (for example, 1000 points can be exchanged for a 1000 yen gift certificate. Yen discount). During the campaign period, the percentage of points added doubles, and the discount rate increases when the purchase amount for one year reaches a certain amount or more, thereby encouraging consumers to purchase. As another example, an airline's frequent flyer program may accumulate a flight distance rather than a purchase price and receive a free airline ticket or seat upgrade service when a certain flight distance is reached. In this case as well, by providing a service according to the member's usage history, the member is motivated to select the same airline. By making such a point system into an IC card, the points of the card user can be correctly managed on the card. In a multi-application compatible IC card, a plurality of applications can be effectively linked by combining with an electronic money or a credit card function.
[0005]
As one of the applications on the card that takes advantage of the characteristics of the multi-application compatible IC card as described above, a game function is added to the point system, and the point value is linked according to the result of executing the game stored on the card. An "IC card system with a point system with game" has been proposed. This application has been filed in Japanese Patent Application No. 10-239812 and Japanese Patent Application No. 10-321684. In these inventions, the number of times that the user can execute the game is defined as “game execution right”, and the game execution right and the value of the point as a result of the game execution are managed, whereby the IC card program In this paper, we proposed a method that can run the game safely.
[0006]
In addition, as a method for managing the point system on the IC card, a system having a plurality of unique programs in the point management program has been proposed. This system has been filed in Japanese Patent Application No. 10-307216, and according to this method, a single point application program can be used for multiple sales by embedding a unique program in the point management program for each store. It becomes possible to manage points for the store.
[0007]
[Problems to be solved by the invention]
Each OS corresponding to multi-applications such as “MULTIS” has a predetermined load mechanism from the viewpoint of security. When downloading an application, the loading mechanism checks items such as whether the downloaded application program has been tampered with, developed by a valid developer, or whether the card has the right to download the application program. . For example, the presence / absence of tampering can be verified by associating data obtained by signing the hash value of the application program with the secret key of the certificate authority (CA) with the application program and comparing and matching the hash value recalculated with the card. it can. Since these checks affect the safety of the IC card, strict procedures are prescribed for each card, and the application program to be transferred can be downloaded only if it has a predetermined data format. . This specification is called an application issue scheme.
[0008]
For this reason, in order to load an application program onto an IC card equipped with a multi-application-compatible OS, predetermined application authorization and registration procedures must be performed in accordance with the above-described application issuance scheme. Therefore, although it is possible in principle to replace the application program on the issued card, considerable effort and time are required to actually replace the application program. This is to maintain the safety of the IC card, and in the case of a normal financial application, the contents of the program are not changed so frequently, so that this is not a big problem.
[0009]
However, in the case of a game application, there is a high possibility that the user will get bored if there is no variation in the type of game, and there is a great demand to change the contents of the game frequently. If the procedure for approving and registering the application is performed every time in response to a request to frequently change the type of game, the procedure is complicated and the features of the game application cannot be fully utilized.
[0010]
Also, if different application programs were developed and distributed for different types of games, procedures for transferring points earned from old types of games to new types of games are required, and point management for this purpose There is a problem that becomes complicated.
[0011]
In terms of development, if each application with similar functions was developed separately each time, it would be wasteful in processing, and during the development and distribution of many types of game applications, issue management and card distribution Distribution management at the time of loading is required.
[0012]
Furthermore, in the current situation where several different IC card OSs such as “MULTIS” and “Java Card” are mixed, game application programs on IC cards are built separately on multiple platforms each time the game type is changed. There is a problem that the development man-hour becomes large.
[0013]
Note that these problems are not limited to game applications, and similar problems are expected to occur in applications on IC cards whose processing contents are to be changed frequently.
[0014]
The object of the present invention is to eliminate the need for complicated application program replacement processing even when game variations are increased in a game application executed on an IC card. And a game application program that can develop a new game without depending on the difference in OS.
[0015]
Further, if this is extended not only to a game application but also to a general application, another object of the present invention is that no complicated application program replacement processing is required even when processing variations are increased in an IC card application. Accordingly, it is an object to provide an application program on an IC card that can easily handle a plurality of types of processing and can develop a new game without depending on a difference in OS.
[0016]
[Means for Solving the Problems]
In order to achieve the above object, a means for handling a plurality of types of games with a single application program on an IC card is proposed.
[0017]
The first possible policy is to share the point data that is the result of game execution and the part for handling game execution rights (data storage unit and processing unit) among a plurality of games. If the point data and the game execution right management part are made common in the processing of the game program, it may be considered that only the algorithm that actually determines the game result is different depending on the game.
[0018]
However, when examining the types of games that are mainly executed on an IC card, which cannot be said to be so complicated, the game execution part “receives data sent from the user via the terminal” “generates random numbers” It can be seen that it repeats the processes of “”, “simple addition / subtraction”, “data storage”, “data comparison and branching”, and combinations thereof. When the parts that perform these processes are made into parts as “components”, the definition of each game can be expressed as a “script” that defines the calling order of these components. In other words, if a processing component “component” that performs processing for executing a game and an “interpreter” that interprets and executes a script are prepared in one application program of an IC card, a game definition generated outside the program By executing the “script”, a different game process can be performed.
[0019]
If this script is exchanged from the outside of the application program through the terminal as required, it is possible to execute a plurality of different types of games by a single game application program on the IC card.
[0020]
However, if it is possible to replace and add scripts, if any script is stored inside the application program, the malicious script may result in incorrect game results. Yes, the security of the precious IC card OS is not utilized. Therefore, in place of the application program issuance scheme defined by the OS, a pseudo issuance scheme must be defined inside the application so that an illegal script is not stored. Specifically, it is necessary to prepare a control unit that controls the replacement of scripts so that illegal scripts are not stored.
[0021]
In other words, instead of the OS's application program issuance scheme, the application program prepares a pseudo game issuance scheme to ensure safety and to prepare a processing unit that interprets and executes scripts inside the application program. Thus, although it has a limited function, it is possible to execute different types of games with a single program.
[0022]
In addition, point data that changes depending on the outcome of the game and can receive a predetermined service (exchange with goods, etc.) later can be processed in common among multiple games. By adding the game issuer information to the game definition script stored in, points can be managed for each issuer.
[0023]
Accordingly, as means for solving the problems of the present invention, the following six items are listed.
[0024]
First, as a means on the IC card side,
(1) Application program consisting of the following elements:
(A) Game execution component: A component that collects the processes in a card program necessary for executing a game
(B) Game definition script storage: An area for storing a script that defines the execution order of components
(C) Script interpreter: interpreter that interprets and executes game definition scripts
(D) Point data storage unit / processing unit: an area for storing point values that change as a result of the game, and a processing unit for managing point data
(E) Game execution right storage unit / processing unit: an area for storing a value related to the right to execute a game and a processing unit for managing the game execution right
(F) Command processing unit: A processing unit that processes commands from a terminal and calls each process within the program.
This is essential, and if necessary,
(2) Game definition script storage processing unit: has a function of managing storage and replacement of game definition scripts. Process based on the game issuance scheme defined by the application program.
[0025]
(3) Issuer-specific point management function: has a function of managing points and game execution rights by issuer.
[0026]
Is prepared.
[0027]
Next, as a terminal device for handling this IC card,
(4) Game issuing function: has a function of performing data communication with the IC card according to a predetermined protocol and issuing game definition script data and / or game execution right data to the IC card. The game definition script and the game execution right may be managed separately or may be managed as the same thing.
[0028]
(5) Game execution function: Data communication is performed with the IC card according to a predetermined protocol, and the game is executed according to a command for executing the game. There is also a need for a user interface that allows the user to run the game.
[0029]
(6) Point calculation function: Data communication with the IC card is performed according to a predetermined protocol, and a value for point data stored in the card is acquired and a new value is set (mainly subtracted). When the point data is managed for each issuer, point calculation is performed with an identifier for each issuer.
[0030]
Is required. The functions (4) to (6) may all be in the same terminal, or may be shared among different terminals.
[0031]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 shows a service image diagram of a point system with a game using an IC card. The system is roughly divided into a service provider side (101) that provides a service and a user side (109) that receives a service. The service provider (101) provides an application provider (102) that supplies game applications to IC cards and terminals, a service manager (103) that manages game operations, game supply and point exchange to each user, etc. It is comprised from the store (104) to perform. Here, the application provider (102) and the service manager (103) may serve both roles or may be shared. Usually, there are a plurality of stores (104) at different points, but there may be a case where the store is the same as the application provider (102) or the service manager (103) at only one place. The user side (109) is composed of one or more users (113), and each user (113) owns one or more IC cards (110). The user (113) may have a user game execution terminal (111) having an input / output function for executing a game inside the card (not required). The user game execution terminal (111) does not need to limit the function only to the game execution, and is provided with an input / output function for the IC card (110) to assist the game execution. Even if it is a normal PC (Personal Computer: personal computer) equipped with a reader / writer (Reader / Writer: a device that accesses the IC card), it is a dedicated mobile phone for handling IC cards that has a function to check the balance in the card. It may be a terminal.
[0032]
First, the application provider (102) loads a game application to the IC card (110) of each user (113). The game application may be loaded in the card when the IC card (110) is issued to the user (113), but the game application can be freely loaded on the card even after the card is issued. Is the feature of the IC card with OS for multi-applications. Information relating to application loading may be reflected in the game management data (106) described below.
[0033]
The service manager (103) receives necessary data from the game management data (106) that collects various types of information regarding the point system with the game, and the game management server (107) sets various parameters for the game at each store. Delivered to the store terminal (108) of (104).
[0034]
In the store (104), a game execution right or a game pattern is issued to the IC card (110) according to the use of the user (113) (shopping or the like). Here, the right to execute the game is the right for the user to execute the game and disappears after the game is executed. The game pattern is various parameters of a game executed in the IC card and includes a game execution right.
[0035]
The user (113), with the game execution right given to the IC card (110), has an in-store game execution terminal (112) (store side) provided in the user game execution terminal (111) or the store (104). The terminal to manage.As with the game execution terminal for the user, it is not necessary to limit to the game execution function alone, and the game inside the card is executed through the interface with the IC card and the game execution function. . The value of the point in the IC card (110) is updated according to the game execution result.
[0036]
These points are exchanged for goods and prizes at the store (104). Data such as game issuance status, user execution history, point exchange history, etc. are accumulated in the game management data (106) as needed, and fed back to the next game parameter generation or game issuance. In this way, the service manager (101) can manage the status of the entire system by dynamically controlling the game parameters using the latest game data.
[0037]
Next, the flow of information in program execution on the multi-application IC card will be briefly described with reference to FIG. The IC card (110) includes a card OS (201) and an input / output interface (202), and one or more application programs (203) are loaded according to a predetermined procedure. In the figure, the application program (203) and the application program (203 ′) are separate independent programs, and both of them are prohibited from illegally accessing the other data. The terminal (120) includes an IC card reader / writer (161), an input / output interface (164), and a terminal OS (163), and there is one terminal program (162) for handling application programs in the IC card. It has been loaded. Usually, one or more terminal programs are required for one application program of an IC card.
[0038]
When a user (or a store clerk) inputs to the terminal (120) through the user interface (151), the terminal program (162) generates a command to be transmitted to the IC card (152). The terminal program (162) transmits this command to the IC card (110) through the reader / writer (161) (153). When the IC card (110) receives the command, the card OS (201) determines the command transmission destination application program (203), and the terminal program (162) transmits the command to the intended application program (203). (154). The execution processing unit (205) in the application program (203) performs processing according to this command, accesses the application data (204), updates values (155), and generates a response (156). . The response is returned to the terminal (120) (157), and the terminal program (162) presents this result (158). This is a sequence of program execution.
[0039]
Even when a plurality of application programs (203) are loaded, by switching the partner application program (203) that issues a command in the terminal program (162), the terminal program (203) can be switched over on the IC card (110) Program execution is possible. Basically, the application program (203) on the IC card is controlled so as not to affect each other's data illegally. For example, in the case of “MULTIS”, delegation means delegation A plurality of application programs can operate in cooperation with each other by a predetermined method called “having”. (The latest “MULTIS” has this function. Details of the delegation function are omitted.)
Next, a specific configuration of the IC card in the game point system realized by the embodiment of the present invention will be described with reference to FIGS. Here, a case where the number of game types is increased to two will be described as an example. Here, the “type” of the game is a variation of a different algorithm that defines how the result of the game execution is reflected in the points. The algorithm referred to here is basically data in the IC card. It is defined by a combination of the above operation and random number generation.
[0040]
FIG. 3 shows the configuration of an IC card that can be realized by a game application according to the inventions already filed (Japanese Patent Application No. 10-239812 and Japanese Patent Application No. 10-321684) when the number of game types is increased to two. The IC card (110) operates under a multi-application compatible card OS (201) such as “MULTIS” or “Java Card” and has an input / output interface (202) for exchanging data with the terminal (120). I have. In the application configuration of the invention of the already filed application, there are one result determination algorithm for one application, and the game application program (200) is required for each type of game. Here, the first game is (A), and the second game is (B).
[0041]
The game application program (A) (200) includes a game parameter (221), a game execution right (222), a portion for storing data of point data (223), a command processing unit (211), a result determination algorithm ( 212), an execution right processing unit (213), and a point data processing unit (214) that actually execute processing. In the figure, the shaded portions of (211), (212), (213), and (214) are portions for executing processing, and once the program is loaded on the card, it is fixed in the program. It shows that. In the data storage units (221), (222), and (223), the contents of the stored data change as the program is executed. The commands from the terminal (120) are roughly classified into commands related to game issuance from the store and commands related to game execution from the user. The command processing unit (211) processes each of the types of commands. The processing is distributed to the execution unit, thereby increasing or decreasing the point data or game execution right data. In response to a game execution command from the user, the game is executed based on the result determination algorithm (212) and the value of the game parameter (221) according to the user input, and point data (223) is determined according to the result. At the same time, the game execution right (222) is decreased, and control is performed so that the game is not executed more than the executable number given from the store.
[0042]
The game application program (B) (200 ′) has the same configuration as (A), and the program is mounted as an independent processing system. Since the command from the terminal (120) is sent after selecting the application, the application program operates by issuing a command set independently for each of the game application programs (200) and (200 ′). Of course, the point data (223) and (223 ′) generated as a result of the game execution are also stored separately, and as a general rule, it is not possible to perform processing collectively when exchanging points. The decisive difference between the game (A) and the game (B) is the result determination algorithm (212) (212 ′), and other parts that process game execution rights and points are composed of similar functions. In spite of this, processing as separate programs has the problem that the IC card with limited resources is wasteful.
[0043]
In “MULTIS”, the game application (A) program (200) and the game application (B) program (200 ′) are basically different applications. The application registration / certification process is required according to the issuance scheme defined by. Although the great feature of multi-application IC cards is that applications can be dynamically installed and deleted after the card is issued, a game that operates with a different algorithm is developed for applications that require frequent changes, such as games. It is cumbersome and burdensome to perform application registration / authorization processing each time. In addition, when the game is changed from (A) to (B), it is natural for the user that the points accumulated as a result of the execution of the game (A) can be used continuously even if the game type changes. Although it is a requirement, in the configuration of FIG. 3, it is not easy to transfer points between different games and to manage the point information associated therewith.
[0044]
One possible solution to the problem of sharing points between multiple games is to make the point management application different from the game application. This method is a means that can be realized also by the above-described inventions already filed. A point application program is prepared separately from the game application, and point data is managed therein. The point value changing process is performed using a delegation process of the card OS (201) in response to a request from the game application. However, even if the point management problem is solved using this method, there is no change in the need to register and authorize the application when adding a new game, and it will not be a fundamental solution. .
[0045]
Therefore, consider a method of handling multiple types of games on a single application.
[0046]
In FIG. 4, the point data to be managed collectively and the command processing are used as a common part, and the part that performs specific processing such as game parameters and result determination algorithm is prepared for only the type of game. The configuration is shown. The IC card (110) is loaded with a game application program (200), in which two types of games, game (A) and game (B), can be handled. Of course, another type of game (C) can be placed, but in the example of this figure, the description will be continued assuming that two types of games are installed. Note that the types of games that can be handled when an application is issued are determined, and new games cannot be added.
[0047]
The point data (223) obtained as a result of the game execution can be handled in common for a plurality of types of games. In addition, the command processing unit (211) that receives a command from the terminal and branches the processing can be shared by a plurality of games separately from the game processing. The game parameter (221), the game execution right (222), and the result determination algorithm (212) are set as different portions depending on the game, and the execution right processing unit (213) and the point data processing unit (214) are provided. Prepare as a common processing unit.
[0048]
The command system sent from the terminal (120) can be identified by the type of game, and the command processing unit (211) analyzes the sent command and determines which type of game the command is directed to. To switch the process. If it is a command to the game (A), processing is performed according to the result determination algorithm (212) of the game (A), and the point data (223) is updated according to the result. Similarly, the value of the point data (221) is updated by both the game (A) and the game (B).
[0049]
A step forward from the method of FIG. 4 is the method illustrated by FIG. The game on the IC card basically processes the value input from the user, generates a random number in the card according to the input timing, and combines local variables and constants given as parameters Most of them are expressed by repetition of judging the result, and even if the result judging algorithm is different, there are many parts that can be shared by other parts. Therefore, components that can be shared among a plurality of games, such as random number generation, addition / subtraction, and repetition, are made into components as common processing components. In the common processing component (224), parts that perform similar processing are prepared as components.
[0050]
The game (A) has a storage unit for game parameters (221) and game execution right data (222), and the execution unit (215) of the game (A) has a common process according to the component call definition (225). A processing procedure is defined in which order the components (224) are called to determine the correct answer of the game. The execution of the program is almost the same as the method of FIG. 4, and by switching the game by the command processing unit (211) depending on the type of command, a plurality of games can be executed within the range incorporated in the program in advance. Can be handled. In the example of FIG. 5, compared with the example of FIG. 4, the efficiency of the application is achieved by making components that can be shared as much as possible into components.
[0051]
In the method of FIG. 4 and the method of FIG. 5 as well, it is possible to handle a plurality of types of games pre-installed at the time of application development, and to switch and execute a number of games according to commands from the terminal. Another kind of game cannot be incorporated after application development / publishing. In order to be able to execute another type of game later, it is necessary to develop a new application, perform registration / authorization processing, and replace the application.
[0052]
Therefore, in FIGS. 6 and 7, a method is proposed in which game types can be exchanged or added without the need to perform application registration / authorization processing or application exchange.
[0053]
More specifically, the component call definition (225) used in the method of FIG. 5 is advanced one step into the script definition, and an interpreter for interpreting and executing the game definition script is prepared in the execution unit. Then, different games are defined depending on interchangeable scripts, and each script is actually interpreted and executed by an interpreter.
[0054]
FIG. 6 shows a configuration of an IC card having a game application in which a game definition is scripted and executed by an interpreter. Again, the shaded portion is a fixed portion determined in advance by the program.
[0055]
In this example, the game definition and the execution right definition are handled separately. The game execution right (222) and point data (223) are handled in common for all types of games by the execution right processing unit (213) and the point data processing unit (214), as in the example up to FIG. The common processing component (224) is defined in advance, and the game definition script (226) defines different result determination algorithms for each game by describing the calling order of these components.
[0056]
This game definition script (226) can be replaced, and the game definition script replacement processing unit (216) controls the replacement of the script. Despite the fact that strict application issuance schemes have been established to protect the security of IC cards, it is safe to change the game type by script definition for easy game type exchange. It cannot be denied that there is a possibility of sacrificing sex. Therefore, items such as whether the game definition script to be stored has been falsified, developed by a legitimate developer, or whether the game has the right to store the script must be checked inside the application program. I must. That is, instead of the application issuing scheme possessed by the OS, an original game issuing scheme is prepared inside the application, and based on this, only a safe game script is controlled to be stored inside the card. This role is performed by the game definition script replacement processing unit (216).
[0057]
The game execution right (222) data is data that defines how many times each type of game can be executed, and is stored in the card when the game is issued. When a command related to game execution is received from the terminal (120), if there is a game execution right (222), the contents of the game definition script (226) are interpreted and executed by the script interpreter (215). When the execution of the game is over, the process of reducing the game execution right (222) is the same as that of the configuration already described. By storing a plurality of types of game definition scripts (226), it is possible to handle a plurality of types of games, and even after the application is loaded onto the card by the game definition script replacement processing unit (216), the types of games Can be replaced.
[0058]
FIG. 7 is similar to the example of FIG. 6 except that the game definition script includes a game execution right, and the game definition script (226), that is, the game definition including the game execution right for one time. It has become. Therefore, once a game described in the game definition script is executed, the script needs to be deleted and controlled so that it cannot be executed again. Further, the management of the game execution right and the management of the game definition script are the same, and the game data storage processing unit (217) manages them. The script sent from the terminal when the game is issued is stored in the data area, and the script deletion after the script execution is also processed here. Needless to say, the game data storage processing unit (217) must perform the same script safety check as the game definition script replacement processing unit (216) in FIG.
[0059]
FIG. 8 further corresponds to the method of FIG. 6 corresponding to a plurality of point sequences. The game execution right (222) is stored as data in which the issuer, the game type, and the number of executions are combined. The point data (223) is also stored for each issuer. When a game execution command is sent from the terminal, the execution authority (222) for each issuer is checked, and the script interpreter (215) determines the game type with the execution authority according to the game definition script (226). Execute. For the addition of point data (223) accompanying the game execution, the score is added for each issuer, and the executed issuer-specific execution right (222) is subtracted.
[0060]
This method applies the concept of the point system of the previously filed invention (Japanese Patent Application No. 10-307216), and the point data (223) is not a single line but corresponds to a plurality of point series. It is. In this way, not only a plurality of game types but also a plurality of point service providers can be handled. As a result, the game service operator can also lend the game application to each store, and the possibilities of the game application are further expanded.
[0061]
Next, a system operation example in the point system with game using the IC card having the configuration described in FIGS. 6 and 7 will be described with reference to FIGS. 9 and 10. Here, the operation example of FIG. 9 corresponds to the IC card of FIG. 6, and the game definition script and the game execution right are separated, and the game type is assumed to be replaced at an appropriate timing. is there. The operation example of FIG. 10 corresponds to the IC card of FIG. 7 and is a combination of the game definition script and the game execution right, and the script is invalidated (deleted) every time the game is executed. It is.
[0062]
FIG. 9 is a diagram illustrating an operation example of a point system with a game using an IC card on which game applications corresponding to a plurality of games are mounted. In this example, the game definition script and the game execution right data are different from each other. It has become.
[0063]
First, a game application program (200) is loaded on the IC card (110). The game application (200) includes a command processing unit (211), a script interpreter (215), a game definition script replacement processing unit ( 216), an execution right processing unit (213), a point data processing unit (214), and the like. The point data (223) is stored as point score data managed for each issuing company. The game execution right (222) is also managed for each issuer, and stores the type of game and the number of times it can be executed. The game definition script (226) defines the game contents by describing the calling order of the common processing components (224), and actually interprets and executes the script contents by the script interpreter (215). . This game definition script (226) can be replaced as necessary.
[0064]
Hereinafter, the processing procedure will be described for each stage of game replacement, game issuance, game execution, and point exchange.
[0065]
(Game replacement)
A game replacement command (132) and game definition data (141) are transmitted to the IC card (110) from the game definition issuing terminal (114) in the store (104) or other places. Then, the command processing unit (211) interprets the command, and if it is found that the command is a game replacement command (132), the game definition script replacement processing unit (216) performs a game definition replacement process. At this time, the sent game definition script can rewrite the point data, so it must be guaranteed that the game definition script is correctly issued from the issuer. For this purpose, the game definition data (141) to be issued is attached with an encryption key for authenticating that the issuer is the correct script in accordance with the game issue scheme defined in advance by the application. It is necessary to perform authentication processing at (216). In addition, since a terminal program corresponding to the game execution terminal (111) is necessary when executing the game, it may be necessary to replace the program on the terminal side when issuing a new game.
[0066]
(Game issue)
In response to purchase at the store (104) of (X), the store terminal (108) transmits an execution right issue command (133) and execution right data (142) to the IC card (110). The execution right data (142) includes information that the game (A) can be executed once and the issuer is (X) company. It is desirable that this data is also encrypted for security. The command processing unit (211) interprets the command, and the execution right processing unit (213) adds data to the game execution right data (222).
[0067]
(Game execution)
When the user (113) executes the game, a game execution command (131) is transmitted to the IC card (110). If the game execution right (222) exists, the corresponding type of game can be executed. As the game is executed, the value of the point data (223) changes. In this case, the game execution right issuer point included in the execution right data (222) being executed is updated. After the game is executed, processing for reducing the corresponding game execution right (222) is performed. When a game is executed, an execution terminal program corresponding to the type of IC card game is required in the game execution terminal (111).
[0068]
(Point exchange)
The point data (223) accumulated by the game execution can be exchanged for a prescribed service at the store (108), but at that time, the store terminal (108) (the same thing as the terminal that issues the game execution right is different) The point calculation command (134) is transmitted to the IC card (110). The command processing unit (211) passes the processing to the point data processing unit (214), and the point data processing unit (214) performs point subtraction processing. In this case, if the store (104) that sent the command is (X) company, only the points issued by (X) company can be exchanged.
[0069]
In this method, the user can execute the game only for the type of the game definition script (226) (of course, only when the game execution right exists). By replacing the game definition script (226) as necessary, a new game can always be executed without replacing the game application (200).
[0070]
FIG. 10 is a diagram showing another operation example of the point system with a game using an IC card on which game applications corresponding to a plurality of games are mounted. In this example, the game definition script is integrated with the game execution right data. It has become. As in the operation example of FIG. 9, a game application program (200) is loaded on the IC card (110). The game application (200) includes a command processing unit (211), a script interpreter (215), a game A data storage processing unit (217), a point data processing unit (214), and the like are included. The point data (223) is stored as point score data managed for each issuing company. The difference from the example of FIG. 9 is that the game data (227) is stored as a set of a combination of a game definition script and issuer information. The game definition script is the same in that the script interpreter (215) interprets and executes the contents of the script. This script can be regarded as a game execution right for one time, and at the time of game execution, only the point data (223) of the corresponding issuer can be rewritten. And prevent the same script from being executed again.
[0071]
Hereafter, the processing procedure will be described in stages of game replacement, game issuance, game execution, and point exchange.
[0072]
(Game issue)
In response to purchase at the store (104) of the company (X), the store terminal (108) sends a game issuance command (135) and game data including a game definition script and an issuer to the IC card (110). (143) is transmitted. For safety, the game data (143) to be issued is attached with an encryption key for authenticating that the issuer is the correct script by a pre-defined method, so that the game data storage processing unit (217) It is necessary to perform authentication processing. In addition, since a terminal program corresponding to the game execution terminal (111) is necessary when executing the game, it may be necessary to replace the program on the terminal side when issuing a new game.
[0073]
(Game execution)
When the user (113) executes the game, a game execution command (131) is transmitted to the IC card (110). If game data (227) exists, the game described by the game definition script can be executed. As the game is executed, the point data (223) is increased. In this case, the issuer point included in the game data (227) being executed is increased. After the game is executed, the corresponding game data (227) is erased together with the script so that it cannot be executed again. When a game is executed, an execution terminal program corresponding to the type of IC card game is required in the game execution terminal (111).
[0074]
(Point exchange)
The point data (223) saved by the game execution can be exchanged later for a prescribed service at the store (108). In this case, the store terminal (108) (the same as the terminal that issues the game execution right) The point calculation command (134) is transmitted to the IC card (110). The command processing unit (211) passes the processing to the point data processing unit (214), and the point data processing unit (214) performs point subtraction processing. In this case, if the store (104) that sent the command is (X) company, only the points issued by (X) company can be exchanged.
[0075]
In this method, the game definition script is included as the game data (227). Therefore, when a plurality of games of the same type are stored, the script may be sloppy and may be wasted. Compared with the example of FIG. 9 in which the game definition script is replaced, the flexibility for the game type is increased. Since the game execution right is issued, that is, a new game is issued, a new game can always be executed without replacing the game application (200). However, since it is necessary to change the program on the terminal side every time a new game type is developed, there is a possibility that it takes time to update the terminal program when the game execution terminals are distributed.
[0076]
Next, the process flow of the game process execution unit will be described with reference to FIG. The game definition data (226) stores a parameter definition (301), an execution right definition (302), and a script description (303). Apart from this, there is point data (308).
[0077]
The game processing execution unit has a program counter (304) and an execution array (305) as local variables, and also refers to a parameter (306) of a command sent from the terminal / response parameter (307) to be returned to the terminal. ) Can be rewritten.
[0078]
When a command is sent from the terminal, the game process execution unit receives and analyzes the command from the terminal (311), and switches to the designated game type (that is, calls the designated game definition) (312). ). At this time, the parameter sent accompanying the command is stored in the command parameter (306).
[0079]
The value of the program counter (304) is initialized (313) and game execution is started. The scripts described in the script description part (303) are executed in order. Basically, the script is analyzed in order while the value of the program counter (304) is advanced one by one (314). (315), and the script is executed by calling the common processing component. If the script is “waiting for command”, a response is once returned to the terminal and the next command reception is waited (316). If the script is “finished”, a response is returned and the script processing is terminated (317). If the script specifies jump or branch, the program counter is changed to the jump destination and the process proceeds to the next script analysis (318). In the case of other scripts, the corresponding common processing component associated with the script is called, the script is actually executed (319), and the process returns to the process of advancing the program counter (314). In script execution (319), the value of the array for execution (305) and the value of the response parameter (308) are updated while referring to the value of the command parameter (306). By continuing this process, the game is executed.
[0080]
FIG. 12 shows an example of a script language definition for calling a common component. Here, array [] is an execution array (305), cmd [] is a command parameter (306), and rsp [] is a response parameter (307). Each script is responsible for calling a common component and actually executing the program. Up to three parameters are attached to one script.
[0081]
In this example, the script is written in a language system that is close to a normal programming language for easy understanding. However, considering that it is executed with an IC card with a small memory capacity, a more special form is provided when limited to games. A scripting language system (for example, expressing a byte sequence with a small number of digits) may be more appropriate. There is also a method in which some compile means is prepared on the terminal side that issues the script, and the script re-expressed in a byte string is issued.
[0082]
Hereinafter, three types of game implementation examples will be described with reference to FIG. 13 to FIG. 19, in which the game definition is expressed using the script defined in FIG. 12.
[0083]
FIG. 13 shows an example of the game execution screen in the game execution terminal of the slot machine in which the number of boxes (= number of random numbers) is 3 and the range of numbers (random numbers) expressed by one box is 0 to 2. is there. Regarding the value of each box, “0” is represented by an apple, “1” by a mandarin orange, and “2” by a banana.
[0084]
(A) is a screen of the state which started the game. The current number of points (401) and the number of remaining executable games (402) are displayed, and the three boxes (405) have not yet been determined, and the screen is rotating on the screen. When the user presses three “Push” buttons (406) one by one, a random number generation command is sent to the card, and a picture corresponding to the random number value is displayed in the box.
[0085]
(B) is a screen example after the first “Push” selection. Since the random number generated in the card was “0”, an apple picture is displayed in the corresponding box. Repeat three times.
[0086]
(C) is an example of a screen in a state where “Push” for the third time is selected and one game is completed (in the case of hitting). Since all the pictures in the three boxes match, the score “100” given to the game is added to the user's points. A message (403) indicating that the game result is “hit” and 100 points have been added is displayed, indicating that points have been added.
[0087]
(D) is an example of a screen in a state where “Push” for the third time is selected and one game is completed (in the case of a loss). If the pictures in the three boxes do not match, a “missing” message (404) is displayed and no points are added.
[0088]
FIG. 14 shows an example in which the slot machine shown in FIG. 13 is described by the script of FIG. It is expressed by a script of 18 lines from 00 lines to 11 lines (binary).
[0089]
Lines 00 to 02: Called when “Push” is pressed for the first time. Generate one random number, store it in the execution array, and return the value of the random number. When it is desired to return the operation to the terminal, a “Return” script is defined.
[0090]
Lines 03 to 05: Called when the second “Push” is pressed. Generate one random number, store it in the execution array, and return the value of the random number.
[0091]
Lines 06 to 08: Called when the third “Push” is pressed. Generate one random number and store it in the execution array. A value indicating “this is the last” is entered in the response, and the process proceeds to result determination.
[0092]
Lines 09 to 11: Result determination. When all three stored random numbers match, a predetermined score is added to the point. Finally, return the result and finish.
[0093]
FIG. 15 is an example of a game execution screen on a game execution terminal of a roulette game with a probability of winning of one third and a game number of three. The three numbers are represented as “A”, “B”, and “C”, respectively. Although it does not appear in the figure, it is easy to see if it is color-coded.
[0094]
(A) is an initial screen. The current number of points (401) and the number of remaining executable games (402) are displayed. In order to start the game, before rotating the roulette (408), one of “A”, “B”, and “C” is selected from the betting area (407).
[0095]
(B) is a screen after the game starts. Here, when “B” is selected from the betting place (407), a black circle is placed at “B”. The score (410) and the remaining number of games (411) are displayed. Since the game number is “3” in this game, the remaining game number (411) is displayed as “3”. Here, when the “Start” button (409) is pressed to start rotation, the remaining number of games (411) decreases.
[0096]
(C) is a state in which the roulette (408) is rotated (this is how it looks on the screen and is in a waiting state in the program on the card side), and a “Stop” button (button for stopping rotation) (406) When is pressed, a command is issued to the IC card.
[0097]
(D) is a screen in a state where one game has been completed. In accordance with the value of the random number generated on the card, if it matches the bet number, a score is added as “Hit” (403).
[0098]
(E) is a screen in the case where the game is finished after one game. The score is not added as “out of” (404).
[0099]
(F) The game is over when the rotation and random number generation are repeated three times. “GAME OVER” and the score value are displayed (412).
[0100]
FIG. 16 shows an example in which the roulette shown in FIG. 15 is described by the script shown in FIG. It is expressed by a script of 27 lines from 00 line to 1a line (binary).
[0101]
Lines 00 to 05: Called when “Stop” is pressed for the first time. The user input value sent as the command parameter is compared with the execution array and the one that generated one random number, and the comparison result is stored in the array. Return the comparison result and the random value to the terminal.
[0102]
Lines 06 to 0b: Called when the second “Stop” is pressed. The user input value sent as the command parameter is compared with the execution array and the one that generated one random number, and the comparison result is stored in the array. Return the comparison result and the random value to the terminal.
[0103]
Lines 0c to 10: Called when the third “Stop” is pressed. The user input value sent as the command parameter is compared with the execution array and the one that generated one random number, and the comparison result is stored in the array.
[0104]
Lines 01 to 1a: Result determination. Points are added to the points according to the comparison results for three times. Finally, return the result and finish.
[0105]
FIG. 17 is a screen example of a game execution screen of a shooting game with five boxes and five games. This is a game in which the user clicks on a box aiming at a target that moves randomly every second, and competes with the box where the target appears. Repeat this click 5 times.
[0106]
(A) is an initial screen. The current number of points (401) and the number of remaining executable games (402) are displayed. When the “Start” button (409) is clicked, the game is started.
[0107]
(B) is a screen before the user clicks on the screen. Target pictures (413) appear randomly in the five boxes (405). This changes according to the value of a random number generated every second. On the screen, the current game score (410) and the number of remaining games (411) are displayed.
[0108]
(C) is a screen where the user is clicking the screen. In this case, since the box selected by the user matches the box in which the target appears, a score of 10 points is added as “Hit” (414).
[0109]
(D) is a screen where the user is clicking the screen. If the box selected by the user does not match the box in which the target appears, the result is “out” (415).
[0110]
(E) is a game end screen. When the game is completed five times, "GAME OVER" and the score value are displayed (412). If there are still games remaining (402), a new “Start” button (409) is displayed.
[0111]
FIG. 18 is a diagram showing the processing procedure of the shooting game shown in FIG. 17 separately for the terminal (120) side and the card (110) side. Like other programs on the IC card, the terminal (120) basically sends commands and parameters to the card, and the card (110) executes processing according to the received command and returns a response. Become a procedure. Since the current IC card equipped with MULTIS does not have a built-in clock (actually triggered by receiving a command from the terminal), in order for the card to generate a random number every second and update the screen, The terminal needs to send a random number generation request to the card every second.
[0112]
First, the terminal (120) issues a random number generation request command (parameter = 0) (321).
[0113]
The card (110) receives the command (321), substitutes the random number generated in the range of the number of boxes into the variable R (332), and transmits a response with parameter = R (333). In response to this, the terminal redisplays the screen according to the value of R (322). This (from 321 to 322) is repeated at 1 second intervals by the timer (323) every second.
[0114]
When there is an input (click) from the user, the box number selected by the user is substituted for variable D (324), and a command is issued with parameter = D (321). The card receives the command (331), and if the parameter is D (other than 0), the stored random number R is compared with the received box number D (324). And the comparison result is returned to the terminal (335). The terminal receives the result and displays the result on the screen (412). This is repeated by the number of games (5 times in the example of FIG. 17).
[0115]
FIG. 19 shows an example in which the shooting game described in FIGS. 17 and 18 is described by the script in FIG. If the command parameter is “0”, a random number is generated. Otherwise, the user input is compared with the value of the previous random number. In this example script, unlike the previous two examples, a loop is implemented.
[0116]
Lines 00-02: Initializing the execution array
Line 03: Top of the loop
Line 04: Branch according to the value of the command parameter
Lines 0-5d: When a value other than “0” is passed to the command parameter, the input value of the user is compared with the value of the random number, and the comparison result is stored. Increase the loop counter by one. If the loop counter is other than the last time, the comparison result is returned to the terminal. When the process is passed to the terminal and the process returns next time, the process returns to the top of the loop (line 03).
[0117]
Lines 0e to 11: In the case of the final loop. Based on the stored comparison results, points are added to the points.
[0118]
Lines 12 to 16: Command is a dummy. Generate a random number and return the random number to the terminal. Return to the top of the loop.
[0119]
By repeating this, the process of FIG. 18 can be realized by a script.
[0120]
As described above, by using the script shown in FIG. 12, a plurality of types of games such as the three types of games given as examples can be defined. These three types are merely examples, and many other types of games can be defined by a combination of random number generation and comparison with user input. By executing the game defined by these script descriptions by a script interpreter (execution unit) as shown in FIG. 11, a plurality of types of games can be executed by one application program.
[0121]
As described above, the application program capable of executing a plurality of types of games on the IC card and its operation have been described. However, this method can be applied to applications other than games. For example, a user's operation creates value such as points, such as a questionnaire system that earns points by answering on a screen that is updated one after another, and an advertising system that earns points by browsing a specific advertisement In addition, the present invention can be applied as an application for controlling the same script not to be executed again. In this case, however, it is necessary to store the questionnaire response history and advertisement browsing history in the card and control the same questionnaire / advertisement script not to be loaded multiple times. In the case of a game, it is only necessary to delete the script or subtract the execution right after executing the script. However, in the case of a questionnaire, it is necessary to collect the answer data at the store side.
[0122]
FIG. 20 shows an operation example in which the present invention is applied to a questionnaire system. Basically, it is similar to the operation example of the game system shown in FIG. 10, but the part for collecting the questionnaire responses is slightly different.
[0123]
A questionnaire application (500) is loaded on the IC card (110). The questionnaire application (500) includes a command processing unit (211), a script interpreter (215), a questionnaire data storage processing unit (503), and point data. It consists of a processing unit (214) and the like. The questionnaire data (501) is stored as a set of a questionnaire script, an issuer, and answer data. The answer data is empty until the user answers the questionnaire, and the answer data is stored when the user answers the questionnaire. This answer data also serves as a flag indicating whether or not the questionnaire has been answered. If this data is included, the same questionnaire cannot be executed again. The answer history for the questionnaire is stored as answer history data (502), and control is performed so that the answered questionnaire is not loaded. Similarly to FIG. 9 and FIG. 10, the point data (223) is stored as point score data managed for each issuing company.
[0124]
In the store (104) of company (X), the store terminal (108) transmits a questionnaire issue command (506) and questionnaire data (507) including a questionnaire definition script and an issuer to the IC card (110). To do. In order to ensure that this data is correctly issued from the publisher, as in the case of the game, an encryption key that authenticates that the publisher is a correct script is obtained by a predefined method. Thus, it is necessary to perform an authentication process in the questionnaire data storage processing unit (503). The questionnaire data storage processing unit (503) also checks whether or not the sent questionnaire data (507) has been answered against the answer history data (502), and the questionnaire data (501) for the answered questionnaire. It also plays a role of controlling so that it is not stored in the.
[0125]
When the user (113) answers the questionnaire at the user terminal (509), a questionnaire execution command (505) is transmitted to the IC card (110). If the questionnaire data (501) exists, the game described by the questionnaire definition script can be executed. The questionnaire is designed not only to answer a question simply but also to allow the user to select the level of detail of the answer and to change the contents of the next question depending on the contents of the previous answer. If the questionnaire is answered, the points weighted according to the contents of the answer are added to the point data (223) of the issuer, and the answer data is added to the questionnaire data (501). The questionnaire data (501) to which the answer data is added cannot be answered again. That is, adding the answer data to the answered questionnaire data (501) is equivalent to invalidating the corresponding questionnaire data.
[0126]
When exchanging points at the store terminal (108) or when issuing the next questionnaire of the same publisher, the questionnaire response data that was previously answered must be collected. Since the questionnaire data that has already been answered is invalidated with the answer data added, the questionnaire data (501) may overflow if you collect it without collecting the answer data. It is necessary to collect response data. When collection of response data is requested, the questionnaire response collection processing unit (504) encrypts the response data, returns it to the terminal (108), and erases the corresponding questionnaire data (501) together with the response history data. History information is added to (502).
[0127]
With such a system, the present invention can be developed not only in a game but also in a questionnaire system. The advertisement browsing system can be applied in a similar manner.
[0128]
As described above, the effects of the embodiments of the present invention are listed along the six items listed in “Means for Solving Problems”.
First, according to the IC card realized by the embodiment of the present invention,
(1) Application program consisting of the following elements:
(A) Game execution component
(B) Game definition script storage
(C) Script interpreter
(D) Point data storage / processing unit
(E) Game execution right storage / processing unit
(F) Command processing unit
Thus, a plurality of types of games can be executed by one application program on the IC card.
[0129]
In addition to this,
(2) Game definition script storage processing unit
Thus, even after the game application program is loaded onto the IC card, a new type of game can be introduced at any time without requiring replacement of the application program, and a more flexible game system can be provided. .
[0130]
By controlling the storage based on the game issuance scheme defined by the application program, the processing of the application program can be switched safely, and the troublesome application issuance scheme defined by the card OS is released.
[0131]
In addition, if a game application program that performs the same processing is loaded onto an IC card equipped with a different OS such as “MULTIS” or “Java Card”, the difference between the OSs is not affected when developing a new game. It is possible to develop a similar game.
[0132]
(3) With the issuer-specific point management function, a plurality of types of games can be managed by a plurality of issuers using a single application, and a more widely used game system can be provided.
[0133]
Next, as a terminal device for handling this IC card,
(4) Game issue function
(6) Point calculation function
This makes it possible to issue multiple types of games to an IC card without replacing the game application program, and to safely operate a flexible game system including point management. Become.
[0134]
Also equipped with a user interface for running each game
(5) Game execution function
Thus, the user can earn points by executing the game while having fun.
[0135]
Therefore, according to the embodiment of the present invention, a more flexible game application can be safely introduced into the IC card system. By linking the game results with points, the user's willingness to use the card increases, which is effective for enclosing the customer of the application provider and greatly helps spread the IC card system.
[0136]
In addition, the method of changing the processing contents of the program without replacing the program is not limited to the game application by the method of controlling the script storage based on the game issuance scheme defined by the script definition and the application program. Development of open, more flexible and simple IC card applications is possible.
[0137]
【The invention's effect】
According to the present invention, for example, a game can be replaced without replacing a program.
[Brief description of the drawings]
FIG. 1 is a service image diagram of a point system with a game using an IC card.
FIG. 2 is a diagram showing a flow of information in executing a program on a multi-application IC card.
FIG. 3 is a diagram (No. 1) for explaining a specific configuration of an IC card in the point system with game according to the embodiment of the present invention;
FIG. 4 is a diagram (No. 2) for explaining a specific configuration of an IC card in the point system with game according to the embodiment of the present invention;
FIG. 5 is a diagram (No. 3) for explaining a specific configuration of an IC card in the point system with game according to the embodiment of the present invention.
FIG. 6 is a diagram (No. 4) for explaining a specific IC card configuration in the point system with game according to the embodiment of the present invention;
FIG. 7 is a view (No. 5) for explaining the specific structure of the IC card in the point system with game according to the embodiment of the present invention.
FIG. 8 is a diagram (No. 6) for explaining a specific configuration of the IC card in the point system with game according to the embodiment of the present invention.
FIG. 9 is a diagram showing an example of game issuance operation (part 1);
FIG. 10 is a diagram showing an example of game issuance operation (part 2);
FIG. 11 is a diagram showing processing of a script interpreter (execution unit).
FIG. 12 is a diagram showing an example of a common component call script language definition.
FIG. 13 is a diagram showing an example of a slot machine.
FIG. 14 is a view showing a script description example in the slot machine.
FIG. 15 is a diagram illustrating an example of a roulette.
FIG. 16 is a diagram showing a script description example in roulette.
FIG. 17 shows an example of a shooting game.
FIG. 18 is a diagram illustrating an example of a shooting game processing procedure;
FIG. 19 is a diagram showing a script description example in a shooting game.
FIG. 20 is a diagram showing an operation example of a questionnaire system.
[Explanation of symbols]
101: Service provider side
102: Application provider
103: Service administrator
104: Store (game supplier)
105: Application loading terminal
106: Game management data
107: Game management server
108: Terminal for store
109: User side
110: IC card
111: User game execution terminal
112: In-store game execution terminal
113: User
114: Game data issuing terminal
120: Terminal
131: Game execution command
132: Game replacement command
133: Execution right issue command
134: Point calculation command
135: Game issue command
141: Game definition data to be issued
142: Execution right data to be issued
143: Game data to be issued
151-158: Data flow
161: IC card R / W
162: Terminal program
163: Terminal OS
164: Input / output interface (of terminal)
200: Game application program
201: Card OS
202: Input / output interface
203: Application program
204: Application data
205: Execution processing unit
211: Command processing unit
212: Result determination algorithm
213: Execution right processing unit
214: Point data processing unit
215: Script interpreter (execution unit)
216: Game definition script replacement processing unit
217: Game data storage processing unit
221: Game parameters
222: Game execution right data
223: Point data
224: Common processing component
225: Component call definition
226: Game definition script
227: Game data (script + publisher)
300: Game definition data
301: Parameter definition
302: Execution right definition
303: Script description
304: Program counter
305: Execution array
306: Command parameter
307: Response parameter
308: Point data
311 to 319: processing steps of game processing execution unit
321: Command issue processing
322: Redisplay processing
323: Timer
324: Input data substitution processing
331: Command reception processing
332: Random number generation and substitution processing
333: Response transmission process
334: Data comparison processing
335: Result return processing
401: Number of points
402: Number of remaining games
Message per 403:
404: Missing message
405: Box
406: Button to stop rotation
407: betting area
408: Rotating roulette
409: Start button
410: Score
411: Remaining game
412: Game result
413: Target
414: When hit
415: When it comes off
500: Questionnaire application
501: Questionnaire data
502: Answer history data
503: Questionnaire data storage processing unit
504: Questionnaire response collection processing section
505: Questionnaire execution command
506: Questionnaire issue command
507: Questionnaire data to be issued
508: Response data to be collected
509: User terminal.

Claims (30)

An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program An application program supply method comprising: supplying an application program having an interpreter function for interpretation and execution from outside to inside of the smart card via the input / output interface. 2. The smart card according to claim 1, further comprising a point data storage unit that stores point data whose value is updated according to an execution result of a program according to an operation procedure defined by the script. . The process defined by the script is a process that has a possibility of obtaining different results depending on the input and execution timing of a smart card user, and the user cannot predict the result in advance. The smart card according to claim 1. The smart card according to claim 1, further comprising means for invalidating a corresponding script and setting the process to be unexecutable after executing the process defined by the script. An execution right storage unit for storing a script execution right for defining the maximum number of times the process defined by the script can be executed, and after executing the process defined by the script, the execution right data of the corresponding script The smart card according to claim 1, further comprising means for subtracting. 2. The script supply method according to claim 1, wherein after the application program is supplied, the script is stored in the storage unit through the input / output interface. An authentication processing unit for performing a predetermined authentication process when the script is stored in the storage unit through the input / output interface after the application program is supplied, and for ensuring that a correct script that has not been falsified is stored; The smart card according to claim 1, further comprising: Aggregating the point data by publisher,
Add an identifier indicating the issuer to the script or execution right data,
The smart card according to claim 2, further comprising means for updating only point data corresponding to the issuer data in accordance with an execution result of the process defined by the script. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program A script supply method characterized in that the application program having an interpreter function for interpreting and executing supplies the script from outside to inside of the smart card stored in the storage means via the input / output interface. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program A smart card having an application program, wherein an application program having an interpreter function for interpretation and execution is supplied from the outside to the inside of the smart card via the input / output interface. The smart card according to claim 10, wherein the script is stored in the storage unit. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program A terminal device comprising means for supplying an application program having an interpreter function for interpretation and execution to the smart card via the input / output interface. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program The application program having an interpreter function for interpretation and execution has means for supplying the script via the input / output interface from outside to inside of the smart card stored in the storage means. Terminal device. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program A terminal device comprising means for supplying an application program having an interpreter function for interpretation and execution to the smart card via the input / output interface. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program An application program having an interpreter function for interpretation and execution. 16. The application program according to claim 15, wherein the smart card has a point data storage unit for storing point data whose value is updated according to an execution result of the program according to the operation procedure defined by the script. . The process defined by the script is a process which has a possibility of obtaining different results depending on the input and execution timing of a smart card user, and the user cannot predict the result in advance. Item 15. The application program according to Item 15. 16. The application program according to claim 15, further comprising a function of invalidating a corresponding script and setting the process to be unexecutable after executing the process defined by the script. An execution right storage unit for storing a script execution right for defining the maximum number of times the process defined by the script can be executed, and after executing the process defined by the script, the execution right data of the corresponding script 16. The application program according to claim 15, which has a function of subtracting. 16. The application program according to claim 15, wherein the application program is configured to be able to be stored in the storage unit through the input / output interface after the application program is supplied. An authentication processing unit for performing a predetermined authentication process when the script is stored in the storage unit through the input / output interface after the application program is supplied, and for ensuring that a correct script that has not been falsified is stored; 16. The application program according to claim 15, further comprising: Aggregating the point data by publisher,
Add an identifier indicating the issuer to the script or execution right data,
17. The application program according to claim 16, further comprising a function of updating only point data corresponding to the issuer data in accordance with an execution result of processing defined by the script. An application program operable on an operating system (OS) mounted on a smart card having a CPU, storage means, and an input / output interface, and a script for defining an operation procedure of the application program A storage medium having an application program having an interpreter function for interpretation and execution. 24. The storage medium according to claim 23, wherein the smart card has a point data storage unit for storing point data whose value is updated in accordance with an execution result of a program according to an operation procedure defined by the script. . The process defined by the script is a process which has a possibility of obtaining different results depending on the input and execution timing of a smart card user, and the user cannot predict the result in advance. Item 24. The storage medium according to Item 23. 24. The storage medium according to claim 23, wherein after executing the process defined by the script, the function is set so that the corresponding script is invalid and the process cannot be executed. An execution right storage unit for storing a script execution right for defining the maximum number of times the process defined by the script can be executed, and after executing the process defined by the script, the execution right data of the corresponding script 24. The storage medium according to claim 23, which has a function of subtracting. 24. The storage medium according to claim 23, wherein the script can be stored in the storage unit through the input / output interface after the application program is supplied. An authentication processing unit for performing a predetermined authentication process when the script is stored in the storage unit through the input / output interface after the application program is supplied, and for ensuring that a correct script that has not been falsified is stored; 24. The storage medium according to claim 23, comprising: Aggregating the point data by publisher,
Add an identifier indicating the issuer to the script or execution right data,
The storage medium according to claim 24, wherein the storage medium has a function of updating only point data corresponding to the issuer data in accordance with an execution result of the process defined by the script.

Images