US20010006195A1 - Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program - Google Patents

Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program Download PDF

Info

Publication number
US20010006195A1
US20010006195A1 US09/741,809 US74180900A US2001006195A1 US 20010006195 A1 US20010006195 A1 US 20010006195A1 US 74180900 A US74180900 A US 74180900A US 2001006195 A1 US2001006195 A1 US 2001006195A1
Authority
US
United States
Prior art keywords
game
smart card
scripts
application program
loading
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US09/741,809
Other versions
US6681995B2 (en
Inventor
Hiroko Sukeda
Yusuke Mishina
Masaru Ohki
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Assigned to HITACHI, LTD. reassignment HITACHI, LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MISHINA, YUSUKE, OHKI, MASARU, SUKEDA, HIROKO
Priority to US09/798,960 priority Critical patent/US6659345B2/en
Publication of US20010006195A1 publication Critical patent/US20010006195A1/en
Priority to US10/674,401 priority patent/US6834802B2/en
Application granted granted Critical
Publication of US6681995B2 publication Critical patent/US6681995B2/en
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3552Downloading or loading of personalisation data
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3244Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes
    • G07F17/3251Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes involving media of variable value, e.g. programmable cards, programmable tokens
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3244Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes
    • G07F17/3255Incentive, loyalty and/or promotion schemes, e.g. comps, gaming associated with a purchase, gaming funded by advertisements
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326Game play aspects of gaming systems
    • G07F17/3262Player actions which determine the course of the game, e.g. selecting a prize to be won, outcome to be achieved, game to be played

Definitions

  • the present invention relates to a method of loading an application program into a smart card, smart cards, a method of loading scripts into a smart card, a terminal device capable of operating with smart cards, and a storage medium holding an application program; particularly to a computer system with highly-reliable security, especially, such system with its kernel built on an IC card wherein an application program stored into its nonvolatile storage can run inside the card.
  • IC cards or termed smart cards furnished with a built-in CPU (Central Processing Unit) that enables operations inside the card are expected to be used in various application fields, particularly, in financial application such as electronic money, and their introduction has been advanced positively in late years because of their information storage ability and highly-reliable security achievable.
  • CPU Central Processing Unit
  • OSs operating systems
  • MULTOS supplied by Mondex International
  • Java Card supplied by Sun Microsystems, Inc.
  • Smart cards with this kind of multi-application OS are controlled so that the application programs installed on the card will be highly independent of each other when running. Not only a plurality of programs can safely coexist on these cards, but also a new application can be added to these cards after a card is issued or an unnecessary application program can be removed from them.
  • these cards can be regarded as safe computers rather than simple information storage media.
  • smart cards are expected to have applications in the financial field such as credit cards or electronic money, especially, as the implementation of interlinking a plurality of applications.
  • a point system or a customer-loyalty system (hereinafter referred to as a point system) has been generally used as a means of getting more customers.
  • This system is defined as “a system such that a customer's points increase by the use of the customer's card and the customer can be granted a predetermined service according to the accumulated points.” Supposing that customers expect to be granted some privilege by getting points, shop managers and card issuers aim at the effect of promotion of using cards for shopping at their shops. Examples of such system are stamp cards that are valid only in a shopping district, department stores' point systems, or airlines' mileage programs. As one example, a department store's point system is explained below. Customer members have their cards issued from the department store.
  • points the customer gets, according to how much he or she paid for example, 20 points are added per 1,000 yens of payment
  • the customer can exchange the points for a gift certificate (for example, the customer can exchange 1,000 points for a gift certificate of 1,000 yens.
  • Department stores may offer an additional discount in such a manner that the points are added at a double rate during a special campaign period or that if the amount a member customer paid for shopping or service at the department store a year reaches a certain amount, his or her discount rate rises. In this way, department stores usually stimulate the will to buy of their customers. For airlines' mileage programs as another example, flight distance of travel per customer instead of the amount the customer paid is accumulated.
  • the multi-application smart card OSs such as “MULTOS” have a predetermined loading mechanism in view of security.
  • the loading mechanism is used to check that the downloaded application is not falsified, that the authorized programmer has programmed the application, and that the card is granted the permission to download the application program. For example, checking to see whether the application program is falsified is performed as follows.
  • signature data a hash value of the application program, encrypted in the secret-key crypt system of the Certificate Authority (CA) is attached to the application program.
  • This hash value as the signature is compared with a hash value recalculated on the card for a match and thereby verification can be performed. Checking the above matters is important, on which the safety of the smart card is dependent.
  • a strict procedure for each card type is prescribed and the mechanism is designed so that the application program transferred to the card cannot be downloaded unless it is coded in predetermined data format. This regulation is called an “application issue scheme.”
  • An object of the present invention is to provide a game application program to run on a smart card, making it possible to increase game variations to run in the program without being accompanied by a complex procedure of application program replacement, whereby the card user can readily play with one of a plurality of types of games on the card and new games can be developed independent of the difference between the OSs under which they are to run.
  • Another object of the present invention is to provide an application program to run on a smart card, making it possible to increase process variations to run in the program without being accompanied by a complex procedure of application program replacement, whereby the card user can readily request one of a plurality of types of processes on the card and new processes can be developed independent of the difference between the OSs under which they are to run.
  • a conceivable way that is considered primary is sharing the entities (data storage and processor) for the point data as the result of playing games and the rights to play game with a plurality of games.
  • Exchanging or adding scripts means that any script can be stored into an application program and there is a possibility of including a game in ill-intentioned scripts, which may result in that some user could get points by foul play with such game.
  • the security of smart cards is satisfactory, but becomes useless for such foul play.
  • a pseudo issue scheme must be provided within an application program installed on the card to control storing scripts and prevent ill-intentioned scripts from being stored.
  • a controller must be provided to control loading and unloading scripts so that ill-intentioned scripts will be shut out from the application.
  • the present invention assures safety of loading scripts by providing the application program installed on the smart card with the pseudo issue scheme instead of the application program issue scheme that the OS of the card has.
  • the invention also prepares the processing entity for interpreting and executing scripts within the application program, so that a single application program can offer types of games which are different features, though limited.
  • Points may increase, according to the result of playing with a game, and the player can later be granted a predetermined service (for example, exchanging points for a commodity), according to the points.
  • Data of these points can be processed commonly for a plurality of games and in addition can be managed for each game issuer by adding game issuer information to the game definition scripts stored into the card.
  • the present invention comprises the following six major entities.
  • Game executing components A set of modules for implementing the processes programmed in the card, required to execute the game application;
  • Command analyzer Processor to analyze commands from a terminal and call the appropriate process within the program.
  • the processor has the function that manages storing game definition scripts and exchanging scripts. Processing of this processor is based on the game issue scheme prescribed in the application program.
  • Function of executing a game Executes a game by sending user-input commands for playing game to the card and receiving responses from the card by performing data communication with the smart card under a predetermined protocol.
  • a user interface that allows the user to play games is also required.
  • a single terminal may be provided with all of the above functions in items (4) to (6) or separate terminals may take part of the functions.
  • FIG. 1 is a conceptual diagram illustrating how a game and point system using smart cards serves customers
  • FIG. 2 is a diagram illustrating the information flow during program execution on a smart card that supports the compatibility of multiple applications on the card;
  • FIG. 3 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the first one);
  • FIG. 4 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the second one);
  • FIG. 5 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the third one);
  • FIG. 6 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the fourth one);
  • FIG. 7 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the fifth one);
  • FIG. 8 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the sixth one);
  • FIG. 9 is a diagram illustrating an example of game issue operation (the first one).
  • FIG. 10 is a diagram illustrating an example of game issue operation (the second one).
  • FIG. 11 is a diagram illustrating the processing of the script interpreter
  • FIG. 12 gives an example of scripts described in a language to call common process components
  • FIG. 13 illustrates a slot machine game example
  • FIG. 14 gives an example of scripts described for the slot machine game
  • FIG. 15 illustrates a roulette game example
  • FIG. 16 gives an example of scripts described for the roulette game
  • FIG. 17 illustrates a shooting game example
  • FIG. 18 illustrates an example of the processing procedure of the shooting game
  • FIG. 19 gives an example of scripts described for the shooting game.
  • FIG. 20 is a diagram illustrating an example of questionnaire system operation.
  • FIG. 1 shows a conceptual diagram illustrating how a game and point system using smart cards serves customers.
  • the system is roughly divided into the service providers' side ( 101 ) and the users' side ( 109 ).
  • the service providers' side ( 101 ) comprises an application provider ( 102 ) that distributes a game application by loading it into smart cards and terminals, a service administrator ( 103 ) that administrates game operation, and shops ( 104 ) at which a game issue is loaded into a smart card of a user and points are exchanged for a service.
  • a single entity may double the application provider ( 102 ) and service administrator ( 103 ) or the application provider ( 102 ) and service administrator ( 103 ) may be separate entities.
  • a shop ( 104 ) exists in separate sites.
  • a shop ( 104 ) exists only in one site and belongs to the same application provider ( 102 ) and service administrator ( 103 ).
  • the users' side ( 109 ) consists of one or more users ( 113 ) and each user ( 113 ) possesses at least one smart card ( 110 ).
  • the user ( 113 ) may possess a game playable terminal for user ( 111 ) provided with the input/output function for executing a game application installed on the card (but, this terminal is not necessary)
  • the game playable terminal for user ( 111 ) need not be limited to that only having facilities dedicated to playing games, but also may be an ordinary personal computer (PC) with a smart card reader/writer (the smart card accessing device) or a special portable terminal for operating with smart cards, having facilities such as checking the user's balance recorded in the card, provided that it has at least the function of data input/output to/from a smart card ( 110 ) and a support (as an auxiliary) of game application execution.
  • PC personal computer
  • a smart card reader/writer the smart card accessing device
  • a special portable terminal for operating with smart cards having facilities such as checking the user's balance recorded in the card, provided that it has at least the function of data input/output to/from a smart card ( 110 ) and a support (as an
  • the application provider ( 102 ) first loads a game application into the smart card ( 110 ) of each user ( 113 ).
  • a game application is loaded into the card when the smart card ( 110 ) is issued to the user ( 113 ).
  • a game application can be freely loaded into the card, which is a feature of the smart card on which the OS supporting the compatibility of multiple applications on the card is installed.
  • the information on loading applications may be reflected in game management data ( 106 ) which will be described later.
  • the service administrator ( 103 ) retrieves necessary data from the game management data ( 106 ) database in which all kinds of information on the game and point system in question are filed and uses a game management server ( 107 ) to distribute game parameters to terminals ( 108 ) at shop.
  • Shops ( 104 ) issue rights to play game or game patterns to smart cards ( 110 ), according to how much the user ( 113 ) has paid (shopped) at the shop.
  • the rights to play game mean the rights for the user to play with a game and the rights decrement by one after the user plays one game.
  • the game patterns mean types of parameters of games to be executed within the smart card, including rights to play game.
  • users ( 113 ) can play games installed in the card by means of the game playable terminal for user ( 111 ) or a game playable terminal at shop ( 112 ) placed in a shop ( 104 ) (As with the game playable terminal for user, the terminal managed by a shop may be in any form, provided it has the interface with a smart card and the game execution support function). According to the result of game play, the points in the smart card ( 110 ) are updated.
  • the points can be exchanged for a commodity or a prize at a shop ( 104 ).
  • Game issue data, user game play log data, and point exchange log data, whenever generated, are saved and stored into the database of game management data ( 106 ), and fed back to the next process of generating game parameters and issuing a game.
  • the service administrator dynamically controls game parameters by using the latest game data, so that the service provider ( 101 ) can manage overall system circumstances.
  • the smart card ( 201 ) is equipped with an I/O interface ( 202 ), and one or more applications ( 203 ) are assumed to have been loaded into it, according to a predetermined procedure.
  • the application program ( 203 ) and the application program ( 203 ′), shown, are separate independent programs and each program is inhibited from making an illegal access to the other program.
  • a terminal ( 120 ) is equipped with a smart card reader/writer ( 161 ) and an I/O interface ( 164 ), and a terminal OS ( 163 ) is installed on it, and moreover, one or more terminal programs ( 162 ) for processing with a mating application program installed on the smart card are installed on it.
  • One or more terminal programs for processing with one application program on the smart card are normally required.
  • the terminal program ( 162 ) When the user (or a clerk) performs input ( 151 ) to the terminal ( 120 ) via a user interface, the terminal program ( 162 ) generates a command ( 152 ) to be sent to the smart card.
  • the terminal program ( 162 ) sends the command to the smart card ( 110 ) ( 153 ) via the smart card reader/writer ( 161 ).
  • the smart card ( 110 ) receives the command
  • the smart card OS ( 201 ) determines an application program ( 203 ) to which the command is to be sent and sends the command ( 154 ) to the application program ( 203 ) that the terminal program ( 162 ) intends to send it to.
  • the processing part ( 205 ) of the application program ( 203 ) executes processing in accordance with the command; it accesses the application data ( 204 ) database, performs value update ( 155 ), and generates a response ( 156 ). The response is returned ( 158 ) to the terminal ( 120 ), and the terminal program ( 162 ) shows results ( 168 ). This is program execution flow in a series.
  • the intended program execution on the smart card ( 110 ) can be performed via the terminal ( 120 ) by terminal program ( 162 ) switching to the appropriate application program ( 203 ) to which the command is issued.
  • the application programs ( 203 ) on the smart card ( 110 ) are controlled not to affect the data for another program illegally.
  • MULTOS a plurality of application programs can operate in linkage with each other by a predetermined method termed delegation (meaning that one program entrusts or transfers a process to another program). (The latest version of “MULTOS” is provided with this function. The delegation function is not described in detail herein.)
  • FIG. 3 shows a smart card configuration that can be embodied to run game applications according to the previous invention for which the application for patent was filed (as Japanese Patent Application No. Hei 10-239812 and Japanese Patent Application No. Hei 10-321684), wherein two types of games are available on the card.
  • the smart card ( 110 ) operates under the card OS ( 201 ) supporting the compatibility of multiple applications on the card, such as “MULTOS” and “Java Card” and is equipped with the input/output interface ( 202 ) for data transfer to/from the terminal ( 120 ).
  • the specifications of the above previous invention state that one algorithm for result judgment is defined for one application each.
  • game application programs ( 200 ) as the number of game types available on the card are necessary.
  • a first game application is marked (A) and a second game application is marked (B).
  • the game application program (A) ( 200 ) comprises the data storage portions for game parameters ( 221 ), rights to play game ( 222 ), and point data ( 222 ) and actual processing parts, command analyzer ( 211 ), algorithm for result judgment ( 212 ), processor for rights to play ( 213 ), and processor for point data ( 214 ).
  • the shaded portions in the figure, ( 211 ), ( 212 ), ( 213 ), and ( 214 ) are the processing parts that become fixed once the program has been loaded into the card.
  • Data contained in the storage portions ( 221 ), ( 222 ), and ( 223 ) changes with the program execution. Commands from the terminal ( 120 ) are roughly divided into those regarding game issue from a shop and those regarding game play from the user.
  • the command analyzer ( 211 ) distributes commands to the processors, according to the command type, and the processors execute processing and thereby the points may increase and the rights to play game decrement.
  • the game is executed, according to the algorithm of result judgment ( 212 ) and game parameters ( 221 ) depending on the user input.
  • the points in the point data ( 223 ) storage may increase and the count of the rights to play game ( 222 ) decrement by one a game.
  • the count of the rights to play is controlled so that the user cannot play with a game in excess of the user-playable game count corresponding to the rights given to the user from a shop.
  • the game application program (B) ( 200 ′) is also configured the same as the program (A) and include independent processing program components installed. Because commands from the terminal ( 120 ) are sent after application selection, independently set commands are issued to each of the game application programs ( 200 ) and ( 200 ′), thereby running the application program. Of course, point data ( 223 ) and ( 223 ′) are also stored separately, and in principle, integrated processing for point exchange is impossible. Alternatively different parts between game (A) and game (B) are the algorithms for result judgment ( 212 ) and ( 212 ′). Other components for processing of rights to play game and points consist of similar functional units. Notwithstanding, separate programs execute separate processing and this should be considered a problem in view of quiet an ineffective use of limited resources of smart cards.
  • FIG. 4 shows a smart card configuration according to the method in which an game application is installed comprising common parts for point data for which integrated management is desirable and command processing and portions for specific processing such as game parameters and result judgement algorithm. The latter portions are prepared as many as the number of game types.
  • a game application program 200
  • game A
  • game B
  • game C
  • game C
  • the following explanation will discuss the example case where the application program accommodating two games is installed as shown. Note that the game types to be executed are fixed when the application is issued and adding a new game cannot be performed in this example.
  • Point data ( 223 ) storage is common so that points acquired as the result of game play can be processed common for a plurality types of games.
  • the command analyzer ( 211 ) that receives commands from the terminal and supplies them to the appropriate processor is also common to a plurality of games, separate from the game processing components.
  • Game parameters ( 221 ), rights to play game ( 222 ), and algorithm for result judgment ( 212 ) are provided as many as the number of game types as the components to execute different processing for different games.
  • the processor for rights to play ( 213 ) and processor for point data ( 214 ) are provided as common-processors.
  • the command analyzer ( 211 ) analyzes commands it receives, finds which game type to which the commands are supplied, and selects the appropriate algorithm for the commands. If the commands are those for game (a), processing is executed, according to the algorithm for result judgment ( 212 ) for game (A) and the point data ( 223 ) may be updated, according to the result of the processing. Updating the points in the point data ( 223 ) storage is performed in the same way whether game A or game (B) has been executed.
  • FIG. 5 shows a smart card configured according to a game execution method upgraded from the corresponding method for the card shown in FIG. 4.
  • most of game processes can be represented as the iteration of processing user input values, generating a random number in the card in accordance with the input timing, and judging the result from the combinations of local variables and constants given as parameters. Even if the algorithm for result judgment differs between games, most of other portions of a game application can be executed in common.
  • part of the game application is made modular for processes that can be executed in common for a plurality of games, such as generating a random number, addition/subtraction, and iteration as common process components.
  • Common process components ( 244 ) are prepared as component modules for executing processes that are required in similar context.
  • the application includes the storage areas for game parameters ( 221 ) and rights to play game ( 222 ) and definition of component call ( 225 ) in the game (A) main ( 215 ) defines the procedure for judging whether the user wins at the game, that is, what sequence in which the common process components ( 224 ) are to be called.
  • the program is executed in almost the same way as for the method used for the smart card shown in FIG. 4.
  • the command analyzer ( 211 ) selects the appropriate game main, according to the command type. Thereby, a plurality of games, as assembled into the program beforehand, can be processed.
  • the processes that can be executed in common are packaged as components in as large part of the program as possible, so that efficient application operation can be achieved.
  • game definition scripts supercede the definition of component call ( 225 ) used in the game execution method for the card shown in FIG. 5 and a script interpreter for interpreting and executing the game definition scripts is prepared in the processing part of the game application program. Separate suits of the scripts that are replaceable define different games and the interpreter practically interprets and executes each suit of the scripts.
  • FIG. 6 shows a smart card configuration with a game application being installed on the card, the application programmed according to the method in which game definition scripts are described and executed by the interpreter.
  • the shaded portions are fixed components of the program that are predetermined.
  • game definitions and rights to play game are handled as separate entities.
  • the rights to play game ( 222 ) and the point data ( 223 ) are processed by the processor for rights to play ( 213 ) and the processor for point data ( 214 ) in common for all types of games.
  • the common process components ( 224 ) are predefined and the game definition scripts ( 226 ) define the algorithm for result judgement that differs for each game by describing sequence in which these components are to be called.
  • These game definition scripts ( 226 ) are replaceable and a processor for exchanging game scripts ( 216 ) controls loading/unloading the scripts.
  • the strict application issue scheme is prescribed to assure the smart card security, it cannot be denied that there is a possibility of safety loss due to making game exchange in units of game definition scripts possible for simple and convenient game exchange.
  • the following must be checked: the game definition scripts to be stored is not falsified; the authorized programmer has programmed the scripts; and the game application is granted the permission to store the scripts.
  • a particular game issue scheme instead of the OS's application issue scheme must be prepared within the application and storing game scripts must be controlled so that safe game scripts only will be installed on the card, based on this scheme.
  • the processor for exchanging game scripts ( 216 ) fills this controlling role.
  • the rights to play game ( 222 ) are data that defines how many times the card user can play with what type of game and this data is stored into the card when the game is issued.
  • the script interpreter ( 215 ) interprets and executes the contents of the game definition scripts ( 226 ) for the game.
  • the rights to play game ( 223 ) decrement by one as explained for the fundamental card configuration.
  • the card configured as shown in FIG. 6 can accommodate a plurality of game types by storing game definition scripts ( 226 ) for each game type into the game application on the card.
  • a game type can be replaced by another game type even after the application is loaded into the card.
  • the data on the rights to game play is included in game definition scripts. That is, the game definition scripts ( 226 ) are programmed to include one right to play game (may include a plurality of rights to play game, not limited to one right). Once a game has been executed once (or two or more times corresponding to a predetermined playable game count) described in the game definition scripts, control means is required to delete the game scripts so that the same scripts will never be executed again thereafter.
  • the rights to play game and the game definition scripts are managed together under a single processor, namely a processor for storing game data ( 217 ).
  • This processor also deletes game scripts that have been executed completely as well as stores game scripts sent from the terminal when the game is issued into the data area. Needless to say, the processor for storing game data ( 217 ) must perform the script safety check as the processor for exchanging game scripts ( 216 ) shown in FIG. 6 does.
  • FIG. 8 shows a game application configured to adapt the game execution method for the card shown in FIG. 6 for a plurality of issuers of points.
  • the rights to play game ( 222 ) are stored, each data thereof comprising a triple of entries: issuer, game ID, and play count. Accordingly, points are stored per issuer in the storage area for point data ( 223 ).
  • the script interpreter ( 215 ) executes the game, according to the game definition scripts ( 226 ). Following the game execution, points may be added to the point data ( 223 ) for the issuer of the game and the rights to play game ( 222 ) for the issuer of the game that has just been executed decrement by one.
  • This method is application of the point system concept according to the above-mentioned pervious invention for which the application for patent was filed (as Japanese Patent Application No. Hei 10-307216), wherein the point data ( 223 ) is retained separately for a plurality of issuers, but not unified.
  • the card can accommodate not only a plurality of game types, but also a plurality of point service providers.
  • game service administrators can offer shops a game application rental service which would expand the potential availability of game applications.
  • FIG. 9 is a diagram illustrating an example of the game and point system operation using the smart card on which a game application accommodating a plurality of games is installed.
  • game definition scripts and rights to play game are separate.
  • a game application program ( 200 ) is assumed to have been loaded into the smart card ( 110 ).
  • the game application ( 200 ) comprises a command analyzer ( 211 ), a script interpreter ( 215 ), a processor for exchanging game scripts ( 216 ), a processor for rights to play ( 213 ), a processor for point data ( 214 ), and other components.
  • Point data ( 223 ) is stored as points managed per issuer Company. Rights to play game ( 222 ) are also managed per issuer and the game type and playable count per issuer are stored.
  • Game definition scripts ( 226 ) are game contents defined by describing sequence in which the common process components ( 224 ) are to be called. In fact, the script interpreter ( 215 ) interprets the contents of the scripts and executes the scripts. The game definition scripts ( 226 ) can be exchanged for new scripts as required.
  • a command to exchange game scripts ( 132 ) and game definition data (scripts) ( 141 ) are sent to the smart card ( 110 ). Then, once the command analyzer ( 211 ) has interpreted the received command as the command to exchange game scripts ( 132 ), the processor for exchanging game scripts ( 216 ) executes the processing of game definition exchange. At this time, it must be assured that the game definition scripts received from the terminal have been issued from the authorized issuer because the scripts can rewrite the point data.
  • all game definition scripts ( 141 ) issued must include a cipher key that authenticates the authorized issuer of the scripts, the key encrypted in accordance with the game issue scheme predefined within the application.
  • the processor for exchanging game scripts ( 216 ) must perform authentication of the scripts it received.
  • program exchange may be necessary on the terminal side when a new game is issued, because a terminal program appropriate for the new game is required on the game playable terminal ( 111 ) when the user plays the game.
  • a terminal at shop ( 108 ) sends the smart card ( 110 ) a command to add the right to play game ( 133 ) and right to play data ( 142 ).
  • the right to play data ( 142 ) contains information that the user can play with the game (A) once and the issuer is Company (X). To assure safety, encryption is desirable for this data as well.
  • the command analyzer ( 211 ) interprets the command and the processor for rights to play ( 213 ) adds the right to the rights to play game data ( 222 ).
  • Points accumulated as point data ( 223 ) while the card user has so far played games can be exchanged for a predetermined service at a shop ( 104 ).
  • a command to calculate points ( 134 ) is sent to the smart card ( 110 ) from a terminal at shop ( 108 ) (that maybe the same as the terminal from which rights to play game are issued or different from such terminal).
  • the command analyzer ( 214 ) passes the processing control to the processor for point data ( 214 ) and the processor for point data ( 214 ) executes subtraction of points. If the shop ( 104 ) from where the command was sent belongs to Company (X), only the points issued by the Company (X) can be exchanged for a service.
  • the user can play games of as many types as the number of the suits of game definition scripts ( 226 ) (of course, only if the rights to play game exist in the card).
  • game definition scripts ( 226 ) By replacing game definition scripts ( 226 ) with new scripts as required, the game application ( 200 ) can continue to offer a new game without being replaced.
  • FIG. 10 is a diagram illustrating another example of the game and point system operation using the smart card on which a game application accommodating a plurality of games is installed.
  • game definition scripts and rights to play game are unified.
  • the game application ( 200 ) comprises a command analyzer ( 211 ), a script interpreter ( 215 ), a processor for storing game data ( 217 ), a processor for point data ( 214 ), and other components.
  • Point data ( 223 ) is stored as points managed per issuer Company. Difference from the example in FIG.
  • game data ( 227 ) is stored, each data comprising a pair of game definition scripts and issuer information.
  • the script interpreter ( 215 ) executes game definition scripts by interpreting the contents of the scripts.
  • a suit of scripts can be regarded as one right of the user to play game. Game execution may rewrite only the point data ( 223 ) for the issuer of the game. Once the game has finished, the suit of the game scripts is invalidated by deleting it so as not to be executed again.
  • a terminal at shop ( 108 ) sends the smart card ( 110 ) a command to store game scripts issued ( 135 ) and game data ( 143 ) containing game definition scripts and issuer.
  • a cipher key that authenticates the authorized issuer of the scripts, encrypted in accordance with the predefined scheme, must be attached to the game data ( 143 ).
  • the processor for storing game data ( 217 ) must perform authentication of the scripts it received.
  • program exchange may be necessary on the terminal side when a new game is issued, because a terminal program appropriate for the new game is required on the game playable terminal ( 111 ) when the user plays the game.
  • Points accumulated as point data ( 223 ) while the card user has so far played games can be exchanged for a predetermined service at a shop ( 104 ).
  • a command to calculate points ( 134 ) is sent to the smart card ( 110 ) from a terminal at shop ( 108 ) (that maybe the same as the terminal from which rights to play game are issued or different from such terminal).
  • the command analyzer ( 214 ) passes the processing control to the processor for point data ( 214 ) and the processor for point data ( 214 ) executes subtraction of points. If the shop ( 104 ) from where the command was sent belongs to Company (X), only the points issued by the Company (X) can be exchanged for a service.
  • every game data ( 227 ) includes game definition scripts, there may exist duplicated suits of scripts in the card if a plurality of same type games are stored, which may be considered inefficient.
  • the flexibility of game type selection increases as compared with the example illustrated in FIG. 9 wherein game definition scripts are replaced by new scripts as required.
  • the game application ( 200 ) can continue to offer a new game without being replaced.
  • the associated program for playing the game on the terminal needs change. In a situation where game playable terminals are distributed, updating the programs on the terminals is likely to be time-consuming work.
  • the script interpreter has a program counter ( 304 ) as a local variable and work arrays ( 305 ) and is able to read a command parameter ( 306 ) sent from the terminal and rewrite a response parameter ( 307 ) to be returned to the terminal.
  • the script interpreter receives and analyzes the command from the terminal ( 311 ), and selects the specified game type (i.e., it calls the specified game definition scripts) ( 312 ). At this time, the interpreter stores a parameter included in the received command as the command parameter ( 306 ).
  • the interpreter resets ( 313 ) the program counter ( 304 ) and begins to execute the game scripts.
  • the interpreter executes in order the scripts described in the scripts description ( 303 ) part; it basically increments the program counter one by one ( 314 ) while analyzes the scripts in order ( 315 ) and calls appropriate common process components, thereby executing the scripts. If the interpreter encounters a “wait for command” script, it immediately returns the response to the terminal and awaits the next command reception ( 316 ). If the interpreter encounters an “end” script, it returns the response to the terminal and exits from the script execution process ( 317 ).
  • the interpreter If the interpreter encounters a script in which a jump or a branch is specified, it resets the program counter to the jump address and proceeds to analyzing the next script ( 318 ). If the interpreter encounters any other script, it calls the appropriate common process component associated with the script and actually executes the script ( 319 ), and returns to the step of incrementing the program counter by one ( 314 ). During the script execution ( 319 ), the interpreter reads a value of command parameter ( 306 ) while updates a value in the work arrays ( 319 ) and a value of response parameter ( 308 ). By continuing this processing, the game application is run.
  • FIG. 12 illustrates an example of scripts described in a language to call common process components.
  • array [] is one of the work arrays ( 305 )
  • cmd [ ] denotes a command parameter ( 306 )
  • rsp [ ] denotes a response parameter ( 307 ).
  • Each script is to call one common process component and fills the role of running the application program. Up to three parameters are assigned to one script.
  • scripts are described in a likely usual programming language to facilitate understanding. Considering that the scripts are executed on the smart card with small storage capacity, a more specialized language may be suitable for describing the scripts limited to game application (for example, representation in byte strings, each byte consisting of fewer bits). A method may be used in which any compiling means is prepared on the terminal side from which scripts are issued to translate scripts into those represented in byte strings and the translated scripts are issued.
  • FIG. 13 shows examples of slot machine game play screens appearing on the game playable terminal, wherein three boxes (corresponds to three random numbers) are shown and a range of settable values for a random number represented in one box is 0 to 2.
  • the values settable in each box correspond to three fruit symbols: “1” for an apple symbol, “2” for a Japanese orange symbol, and “3” for a banana symbol.
  • the game begins with screen (a).
  • the current points ( 401 ) and remaining games ( 402 ) that the user can play are shown and values in three boxes ( 405 ) are not fixed yet with the reels rotating on the screen as depicted.
  • the user pushes three “Push” buttons ( 406 ) one by one. By each button push, a command to generate a random number is sent to the card and the symbol corresponding to a fixed value of the random number is displayed in the box.
  • Screen (b) is an example screen after the first user choice by the “Push” button, A random number of “0” is assumed generated in the card and the apple symbol is displayed in the corresponding box. This is repeated three times.
  • Screen (c) is an example screen after the third user choice by the “Push” button, when one game is over (the user wins). Because of matching of the symbols in the three boxes, a message ( 403 ) appears, indicating that the game result is “you win” and “100” points the user gained at the game are added to the points. The points increase accordingly.
  • Screen (d) is another example screen after the third user choice by the “Push” button, when one game is over (the user loses). Because of mismatching of the symbols in the three boxes, a message ( 404 ) appears, indicating that “you lose” and no points are added.
  • FIG. 14 shows the scripts description example for the slot machine game shown in FIG. 13, described by using the scripts in FIG. 12.
  • the game is represented in 18 lines of scripts, lines 00 to 11 (binary).
  • Lines 00 to 02 To be called upon the first “Push” button push. One random number is generated and stored into a work array and the fixed value of the random number is returned. To return the operation result to the terminal, a “Return” script is defined.
  • Lines 03 to 05 To be called upon the second “Push” button push. One random number is generated and stored into a work array and the fixed value of the random number is returned.
  • Lines 06 to 08 To be called upon the third “Push” button push. One random number is generated and stored into a work array. A value to indicate “the last” is placed in the response and the processing proceeds to result judgment.
  • Lines 09 to 11 Result judgment. If the stored values of three random numbers all match, predetermined points are added to the current points. Finally, the result is returned to the terminal and the processing terminates.
  • FIG. 15 shows examples of roulette game play screens appearing on the game playable terminal, wherein the win probability is one third and the user is given three betting chances.
  • Three possible values of random numbers correspond to “A,” “B,” and “C.” Illustration in color might be easier to see, though not be presented here.
  • Screen (a) is the initial screen.
  • the current points ( 401 ) and remaining games ( 402 ) that the user can play are shown.
  • To begin the game choose one of betting places ( 407 ) “A,” “B,” and “C” before the roulette ( 408 ) rotates.
  • Screen (b) is a screen that appears, following the game start.
  • the user is assumed to have chosen “B” out of the betting places ( 407 ) and a bullet is placed in the B box.
  • Score ( 410 ) and remaining chances ( 411 ) are shown. Because the user is given three betting chances for this game, “3” is shown as the remaining chances ( 411 ).
  • the remaining chances ( 411 ) decrement by one.
  • Screen (c) is a screen wherein the roulette ( 408 ) is rotating (this state appears on the screen, while the program on the card side waits for command input).
  • the “Stop” button to stop the roulette running ( 406 )
  • the associated command is issued to the smart card.
  • Screen (d) is a screen when one roulette run is over. According to the value of the random number generated in the card, that is, if there is a match between the bet place you chose and the value, a “You Win” ( 403 ) message appears and the score increases.
  • Screen (e) is a screen when one roulette run is over and you lose. A “You lose” ( 404 ) message appears and the score does not increase.
  • FIG. 16 shows the scripts description example for the roulette game shown in FIG. 15, described by using the scripts in FIG. 12.
  • the game is represented in 27 lines of scripts, lines 00 to 1a (binary).
  • Lines 00 to 05 To be called upon the first “Stop” button push.
  • the user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array.
  • the comparison result and the value of the random number are returned to the terminal.
  • Lines 06 to 0b To be called upon the second “Stop” button push.
  • the user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array.
  • the comparison result and the value of the random number are returned to the terminal.
  • Lines 0c to 10 To be called upon the third “Stop” button push.
  • the user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array.
  • Lines 11 to 1a Result judgment. According to the three comparison results, points are added to the current points. Finally, the result is returned to the terminal and the processing terminates.
  • FIG. 17 shows examples of shooting game play screens, wherein five boxes appear and the user is given five chances to play. The user clicks at one of the boxes to hit the target that moves at random, appearing in any box a second. If the target appears in the box at which the user clicked, the user wins. Clicking can be repeated five times.
  • Screen (a) is the initial screen.
  • the current points ( 401 ) and remaining games ( 402 ) that the user can play are shown.
  • Screen (b) is a screen before the user clicks at a box on the screen.
  • the target symbol ( 413 ) appears at random.
  • the target position changes, according to the value of the random number that is generated per second.
  • the current game score ( 410 ) and remaining chances ( 411 ) to play are displayed.
  • Screen (c) is a screen when the user clicks at a box on the screen. In this case, because the target appears in the box that the user has chosen, a “click - hit” ( 414 ) message appears and 10 points are added to the score.
  • Screen (d) is another screen when the user clicks at a box on the screen. If the box that the user has chosen differs from the box where the target appears, a “click - lose” ( 415 ) message appears.
  • FIG. 18 illustrates the procedure of processing between the terminal ( 120 ) side and the card ( 110 ) side regarding the shooting game shown in FIG. 17.
  • the terminal ( 120 ) sends the card a command and a parameter and the card ( 110 ) executes processing in accordance with the received command and returns a response to the card.
  • the smart card on which the current version of MULTOS and other OSs is installed does not have a built-in clock (the operation on the card side is triggered by command reception from the terminal), a request for generating a random number must be sent per second from the terminal in order that the card generates a random number a second to update the screen.
  • the terminal receives the response and updates the screen ( 322 ), according to the value of R.
  • the above command-response process (from sending a command 321 until screen update 322 ) is repeated at intervals of one second.
  • the card receives the command ( 331 ) and compares the last generated random number R that has been stored with the received box number D ( 334 ). If a hit is found by this comparison, points are added and the result of the comparison is returned to the terminal ( 335 ).
  • the terminal receives the result and shows the result on the screen ( 412 ). The above process is repeated by the number of chances to play (five times in the example shown in FIG. 17).
  • FIG. 19 shows the scripts description example for the shooting game illustrated in FIGS. 17 and 18, described by using the scripts in FIG. 12. If the command parameter is “0.” a random number is generated. Unless that, the user input is compared with the value of the last generated random number. Unlike the preceding examples of game scripts, this example of scripts includes a loop.
  • Lines 00 to 02 Work arrays are initialized.
  • Line 03 The beginning of loop
  • Line 04 Branching occurs, according to the value of the command parameter.
  • Lines 05 to 0d When a value other than “0” is given as the command parameter, the user-input value is compared with the value of the random number and the result of comparison is stored. The loop counter increments by one. Unless the loop counter indicates the last time, the result of the comparison is returned to the terminal. After passing the processing control to the terminal, next time it returns, the processing returns to the beginning of loop (line 03).
  • Lines 0e to 11 Following the last loop execution, points are added to the point count, based on the stored results of comparison.
  • Lines 12 to 16 If the command is a dummy, a random number is generated and returned to the terminal. The processing returns to the beginning of loop.
  • a plurality of types of games such as three ones given as examples, can be defined.
  • the foregoing three game scripts are examples and many types of games can be defined by describing the processes of generating a random number and comparing the random number with the input from the user in combination.
  • the script interpreter executes these games defined in script descriptions as illustrated in FIG. 11, so that one application program can offer a plurality of types of games that can be selectively executed.
  • the present invention can be applied to application software for: e.g., a questionnaire system that the user can get points by answering questionnaires, which are updated after answered, shown on the screen; and an advertisement system that the user can get points by reading a specific advertisement.
  • application software for: e.g., a questionnaire system that the user can get points by answering questionnaires, which are updated after answered, shown on the screen; and an advertisement system that the user can get points by reading a specific advertisement.
  • Such application generates value such as points in response to user operation and controls the contents so that the same suit of scripts will never be executed again.
  • questionnaire answer logs and advertisement reading logs for each user must be stored in the card and control is required to prevent same scripts of questionnaire or advertisement from being loaded into the card a plurality of times.
  • game scripts once a suit of scripts has been executed, it is deleted or the rights to play game decrement by one, which is only required for script management.
  • additional requirement is that the shop side collects the answer data.
  • FIG. 20 shows a questionnaire system operation example to which the present invention is applied. This example is essentially similar to the game system operation example illustrated in FIG. 10, except that the questionnaire answer data is collected.
  • a questionnaire application ( 500 ) is assumed to have been loaded into the smart card ( 110 ).
  • This questionnaire application ( 500 ) comprises a command analyzer ( 211 ), a script interpreter ( 215 ), a processor for storing scripts of questionnaire ( 503 ), a processor for point data ( 214 ), and other components.
  • Questionnaire data ( 501 ) is stored, each data thereof comprising a triple of entries: questionnaire scripts, issuer, and answer data.
  • the answer data entry is blank before the user answers the questionnaire that is currently presented. When the user answers the questionnaire, the answer data is stored into place. This answer data entry also fills the role of a flag to indicate whether the user has answered the questionnaire. When this entry contains data, the same suit of questionnaire scripts cannot be executed again.
  • Logs of answers to questionnaires are stored as the answer log ( 502 ) data to control script loading so that any questionnaire once answered will never be loaded again.
  • point data ( 223 ) is stored as points managed per issuer Company.
  • a terminal at shop ( 108 ) sends the smart card ( 110 ) a command to store questionnaire issued ( 506 ) and questionnaire data ( 507 ) containing questionnaire definition scripts and issuer.
  • this data must be assured that it has been issued from the authorized issuer.
  • a cipher key that authenticates the authorized issuer of the scripts the key encrypted in accordance with the predefined scheme, must be attached to the questionnaire data.
  • the processor for storing scripts of questionnaire ( 503 ) must perform authentication of the scripts it received.
  • the processor for storing scripts of questionnaire ( 503 ) also checks to see whether the questionnaire data ( 507 ) it received has been answered by referring to the answer log ( 502 ) database, thereby performing the function of control over scripts to prevent answered questionnaire scripts from being stored into the questionnaire data ( 501 ) database.
  • the application of the present invention can be expanded to cover the questionnaire system, not only applicable to games. Furthermore, the invention can be applied to the advertisement reading system in a similar way.
  • One application program installed on the smart card can offer a plurality of types of games that can be selectively executed.
  • the processor enables the introduction of a new type of game in any time even after the game application program is loaded into the smart card without being accompanied by application program exchange. Consequently, a more flexible game system can be provided.
  • the above processor controls storing game scripts, based on the game issue scheme prescribed in the application program, so that the processing parts of the application program can be changed in safety. This means the release from troublesome and time-consuming tasks accompanied by meeting the application issue scheme prescribed in the card OS.
  • the function allows the user to enjoy playing with a game while the user can get points.
  • Noticeable features of the present invention are the introduction of game definition scripts and a script interpreter and the method of control over storing scripts, based on the game issue scheme prescribed in the application program installed on the card.
  • the invention provides a script loading/unloading method in which the contents of only the part for processing that is dependent on user input in a program, not limited to game application, is replaced by new contents without being accompanied by program exchange.
  • This script loading/unloading method enables the development of more flexible and convenient smart card applications, which is released from platform restrictions.
  • the present invent makes it possible to replace game scripts in a program installed on a smart card by new game scripts without being accompanied by program exchange.
  • An application program that can run under an operating system (OS) installed on a smart card furnished with a storage means and an input/output interface and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program.
  • OS operating system
  • the application program described in item 1 including storage for rights to execute that stores the rights to execute scripts, defining the maximum number of times the processing defined in scripts can be executed, and a function that, immediately following the execution of processing defined in scripts, decrements the count of the rights to execute those scripts by one.
  • OS operating system
  • the storage medium described in item 9 including storage for rights to execute that stores the rights to execute scripts, defining the maximum number of times the processing defined in scripts can be executed, and a function that, immediately following the execution of processing defined in scripts, decrements the count of the rights to execute those scripts by one.
  • a terminal device capable of operating with a smart card furnished with a storage means and an input/output interface, including a means to load an application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program into the smart card via the input/output interface.
  • OS operating system
  • a terminal device capable of operating with a smart card furnished with a storage means and an input/output interface, including a means to load scripts as part of an application program from outside via the input/output interface into the smart card wherein the application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program is stored in the storage means.
  • OS operating system

Abstract

The invention provides a method that enables loading/unloading a plurality of types of games as part of an application program, typically, a game application program installed on a smart card system with high ability of storing information for which highly-reliable security is achievable, extending the use range of the card. Of a program to run on the card, the processing parts that can be executed in common are packaged as modules and game definitions described in scripts are loaded/unloaded into/from the card as required from a terminal operating with the card. In the program, a script interpreter that interprets and executes scripts, a controller that controls scripts loading/unloading, a controller that performs the management of point data and rights to play game are prepared, whereby dynamic loading/unloading of types of games is possible and one application can offer a plurality of types of games that can be selectively executed.

Description

    BACKGROUND OF THE INVENTION
  • The present invention relates to a method of loading an application program into a smart card, smart cards, a method of loading scripts into a smart card, a terminal device capable of operating with smart cards, and a storage medium holding an application program; particularly to a computer system with highly-reliable security, especially, such system with its kernel built on an IC card wherein an application program stored into its nonvolatile storage can run inside the card. [0001]
  • IC cards (or termed smart cards) furnished with a built-in CPU (Central Processing Unit) that enables operations inside the card are expected to be used in various application fields, particularly, in financial application such as electronic money, and their introduction has been advanced positively in late years because of their information storage ability and highly-reliable security achievable. [0002]
  • Recently, operating systems (OSs) for such cards, enabling the safe coexistence of multiple applications on a single card have been generally used. As these OSs for such cards that support multiple applications on the card, “MULTOS” supplied by Mondex International and “Java Card” (TM) supplied by Sun Microsystems, Inc. are known. Smart cards with this kind of multi-application OS are controlled so that the application programs installed on the card will be highly independent of each other when running. Not only a plurality of programs can safely coexist on these cards, but also a new application can be added to these cards after a card is issued or an unnecessary application program can be removed from them. Thus, these cards can be regarded as safe computers rather than simple information storage media. From the viewpoint of active use of their highly-reliable security feature or new cards that supercede the conventional magnetic card function, smart cards are expected to have applications in the financial field such as credit cards or electronic money, especially, as the implementation of interlinking a plurality of applications. [0003]
  • Conventionally, a point system or a customer-loyalty system (hereinafter referred to as a point system) has been generally used as a means of getting more customers. This system is defined as “a system such that a customer's points increase by the use of the customer's card and the customer can be granted a predetermined service according to the accumulated points.” Supposing that customers expect to be granted some privilege by getting points, shop managers and card issuers aim at the effect of promotion of using cards for shopping at their shops. Examples of such system are stamp cards that are valid only in a shopping district, department stores' point systems, or airlines' mileage programs. As one example, a department store's point system is explained below. Customer members have their cards issued from the department store. Whenever a member customer does shopping at the store and presents his or her card to the clerk, points the customer gets, according to how much he or she paid (for example, 20 points are added per 1,000 yens of payment) are accumulated and recorded in the customer's purchase log. When predetermined points have been accumulated, the customer can exchange the points for a gift certificate (for example, the customer can exchange 1,000 points for a gift certificate of 1,000 yens. In other words, member customers gain by a discount rate that is 1,000 yens per shopping amounting to 50,000 yens, according to the calculation in this case.) Department stores may offer an additional discount in such a manner that the points are added at a double rate during a special campaign period or that if the amount a member customer paid for shopping or service at the department store a year reaches a certain amount, his or her discount rate rises. In this way, department stores usually stimulate the will to buy of their customers. For airlines' mileage programs as another example, flight distance of travel per customer instead of the amount the customer paid is accumulated. In the system of this kind, if the total distance that a customer traveled by using an airline reaches a predetermined flight distance, the airline grants the customer some privilege such as a free airline ticket or a seat upgrading service. In this case, similarly, the airline offers service in accordance with the log of a member customer who has used the airline, thereby motivating customers to select the same airline again. By installing such point system on a smart card, points of the card user can be correctly managed by means of the card. For a smart card with the multi-application OS, linking with electronic money or with credit card facilities can use the point system more effectively. [0004]
  • As one application that utilizes the feature of the above-described smart card supporting the compatibility of multiple applications, a “point system with game on smart cards” has been proposed. This system is such that game program is integrated with a point system on the card and point value may increase according to the result of the game stored in the card. The patents for the inventions regarding this system were applied for in Japanese Patent Application No. Hei 10-239812 and Japanese Patent Application No. Hei 10-321684. In these inventions, the count of user-playable games is defined as “rights to play game”, and a method in which the smart card program can implement game application safely by managing the rights to play game and the points as the result of games has been proposed. [0005]
  • Moreover, another system in which a plurality of specific programs can be incorporated into a point management program has been proposed as a method of managing a point system on smart cards. The patent for the invention regarding this system was applied for in Japanese Patent Application No. Hei 10-307216. According to this method, by embedding shop-specific programs into the point management program, points from a plurality of shops can be managed on a shop-by-shop basis by running a single program of point application. [0006]
  • SUMMARY OF THE INVENTION
  • The multi-application smart card OSs such as “MULTOS” have a predetermined loading mechanism in view of security. The loading mechanism is used to check that the downloaded application is not falsified, that the authorized programmer has programmed the application, and that the card is granted the permission to download the application program. For example, checking to see whether the application program is falsified is performed as follows. As signature data, a hash value of the application program, encrypted in the secret-key crypt system of the Certificate Authority (CA) is attached to the application program. This hash value as the signature is compared with a hash value recalculated on the card for a match and thereby verification can be performed. Checking the above matters is important, on which the safety of the smart card is dependent. Thus, a strict procedure for each card type is prescribed and the mechanism is designed so that the application program transferred to the card cannot be downloaded unless it is coded in predetermined data format. This regulation is called an “application issue scheme.” [0007]
  • Accordingly, in order to load an application program into a smart card with the multi-application OS is installed, a predetermined application authentication and registration procedure must be carried out, according to the above application issue scheme. Consequently, actual operation of replacing an application program installed on the card by another program requires considerable time and labor, though this is, in principle, possible after the card is issued. This is inevitable for maintaining the safety of the smart card. Notwithstanding, this problem is not [0008]
  • considered significant for ordinary financial applications for which program contents do not change much frequently. [0009]
  • For game applications, however, frequent updating of their contents is required much, because users may tend to lose interest in playing a game unless varieties of games are available. Considering that the application authentication and registration procedure must be carried out each time a new game is loaded, while frequent game exchange is desirable, such complex procedure would deter us from turning game application features to full account. [0010]
  • Another problem arises with separately developing and distributing different application programs for different types of games. When points acquired by playing an old type game are transferred into a new type game, some procedure is required and point management in view of this transfer becomes complex. [0011]
  • In the application development phase, separately programming applications with similar facilities by each request is much time-consuming process. During developing and distributing many types of game applications, management of issues and management of distribution when applications are loaded into cards are required. [0012]
  • Furthermore, in the current situation where different OS types for smart cards such as “MULTOS” and “Java Card” coexist, an OS incompatibility problem further increases the reprogramming time. Game applications that run on smart cards under different OS types must be rebuilt separately on a plurality of platforms that use different OS types whenever game exchange occurs. [0013]
  • These problems are not limited to game applications, but similar problems are expected to occur with applications to run on smart cards for which frequent update of the contents for processing is desirable. [0014]
  • An object of the present invention is to provide a game application program to run on a smart card, making it possible to increase game variations to run in the program without being accompanied by a complex procedure of application program replacement, whereby the card user can readily play with one of a plurality of types of games on the card and new games can be developed independent of the difference between the OSs under which they are to run. [0015]
  • If the invention is extended to general applications beside game applications, another object of the present invention is to provide an application program to run on a smart card, making it possible to increase process variations to run in the program without being accompanied by a complex procedure of application program replacement, whereby the card user can readily request one of a plurality of types of processes on the card and new processes can be developed independent of the difference between the OSs under which they are to run. [0016]
  • In order to attain the above objects, means to run one of a plurality of types of games in a single application program installed on a smart card are proposed. [0017]
  • A conceivable way that is considered primary is sharing the entities (data storage and processor) for the point data as the result of playing games and the rights to play game with a plurality of games. Once the entities of managing the point data and the rights to play game have been set to commonly run in the game program processing, virtually, it can be thought that only the algorithm for judging game result differs depending on the game that is requested to run [0018]
  • Through close examination of types of games to primarily run on smart cards that are not regarded as having complicated calculation capability, it is obvious that processes required to execute games are “receiving data sent from the user via the terminal,” “generating a random number,” “simple addition/subtraction,” “storing data,” and “data comparison and branching” in combination that are iterated. If part of an application program is made modular, that is, it is made up of “components” that independently implement the above processes, games can be defined in “scripts” like representation that defines sequence in which these components are called. Specifically, preparing processing modules, namely “components” to implement the processes required to execute games and an “interpreter” for interpreting and executing scripts in a single application program is essential. This makes it possible to run one of different games by selectively executing the game definition “scripts” generated outside the program. [0019]
  • If such scripts are permitted to be loaded from outside or unloaded if necessary as part of an application program through a terminal, it becomes possible for a single game application program on a smart card to offer a plurality of games of different types that can be selectively executed. [0020]
  • Exchanging or adding scripts, if assumed feasible, however, means that any script can be stored into an application program and there is a possibility of including a game in ill-intentioned scripts, which may result in that some user could get points by foul play with such game. The security of smart cards is satisfactory, but becomes useless for such foul play. As the substitution for the application program issue scheme defined as the card OS security mechanism, a pseudo issue scheme must be provided within an application program installed on the card to control storing scripts and prevent ill-intentioned scripts from being stored. Specifically, a controller must be provided to control loading and unloading scripts so that ill-intentioned scripts will be shut out from the application. [0021]
  • The present invention assures safety of loading scripts by providing the application program installed on the smart card with the pseudo issue scheme instead of the application program issue scheme that the OS of the card has. The invention also prepares the processing entity for interpreting and executing scripts within the application program, so that a single application program can offer types of games which are different features, though limited. [0022]
  • Points may increase, according to the result of playing with a game, and the player can later be granted a predetermined service (for example, exchanging points for a commodity), according to the points. Data of these points, of course, can be processed commonly for a plurality of games and in addition can be managed for each game issuer by adding game issuer information to the game definition scripts stored into the card. [0023]
  • Therefore, as the means to solve the above-mentioned problems, the present invention comprises the following six major entities. [0024]
  • As the means to be provided on the smart card side. [0025]
  • (1) An application program consisting of the following elements: [0026]
  • (a) Game executing components: A set of modules for implementing the processes programmed in the card, required to execute the game application; [0027]
  • (b) Storage for game definition scripts: Area for storing scripts that define sequence in which the components are to be executed; [0028]
  • (c) Script interpreter: Interpreter for interpreting and executing game definition scripts; [0029]
  • (d) Storage and processor for point data: Area for storing points that may increase, according to the result of playing a game, and the processor for point data management; [0030]
  • (e) Storage and processor for rights to play game: Area for storing the count of rights to play game and the processor for managing the rights to play game; and [0031]
  • (f) Command analyzer: Processor to analyze commands from a terminal and call the appropriate process within the program. [0032]
  • The above are necessary. In addition, [0033]
  • (2) Processor for storing game definition scripts: The processor has the function that manages storing game definition scripts and exchanging scripts. Processing of this processor is based on the game issue scheme prescribed in the application program. [0034]
  • (3) Function of point management per issuer: Manages points and rights to play game per issuer. [0035]
  • The above two functional entities are prepared as required. [0036]
  • The following are required for a terminal device for operating with the smart card in question: [0037]
  • (4) Function of issuing a game: Issues game definition scripts and/or rights to play game to the smart card by performing data communication with the smart card under a predetermined protocol. Game definition scripts and rights to play game may be separately managed or put under integrated management. [0038]
  • (5) Function of executing a game: Executes a game by sending user-input commands for playing game to the card and receiving responses from the card by performing data communication with the smart card under a predetermined protocol. A user interface that allows the user to play games is also required. [0039]
  • (6) Function of calculating points: Obtains the point count stored in the card and sets a new point count (by subtraction, primarily) by performing data communication with the smart card under a predetermined protocol. Point calculation is executed with an issuer identifier if point data management per issuer is performed. [0040]
  • A single terminal may be provided with all of the above functions in items (4) to (6) or separate terminals may take part of the functions. [0041]
  • Other and further objects, features and advantages of the invention will appear more fully from the following description. [0042]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A preferred form of the present invention is illustrated in the accompanying drawings in which: [0043]
  • FIG. 1 is a conceptual diagram illustrating how a game and point system using smart cards serves customers; [0044]
  • FIG. 2 is a diagram illustrating the information flow during program execution on a smart card that supports the compatibility of multiple applications on the card; [0045]
  • FIG. 3 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the first one); [0046]
  • FIG. 4 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the second one); [0047]
  • FIG. 5 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the third one); [0048]
  • FIG. 6 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the fourth one); [0049]
  • FIG. 7 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the fifth one); [0050]
  • FIG. 8 is a diagram for illustrating a concrete smart card configuration for the game and point system concerned with a preferred embodiment of the present invention (the sixth one); [0051]
  • FIG. 9 is a diagram illustrating an example of game issue operation (the first one); [0052]
  • FIG. 10 is a diagram illustrating an example of game issue operation (the second one); [0053]
  • FIG. 11 is a diagram illustrating the processing of the script interpreter; [0054]
  • FIG. 12 gives an example of scripts described in a language to call common process components; [0055]
  • FIG. 13 illustrates a slot machine game example; [0056]
  • FIG. 14 gives an example of scripts described for the slot machine game; [0057]
  • FIG. 15 illustrates a roulette game example; [0058]
  • FIG. 16 gives an example of scripts described for the roulette game; [0059]
  • FIG. 17 illustrates a shooting game example; [0060]
  • FIG. 18 illustrates an example of the processing procedure of the shooting game; [0061]
  • FIG. 19 gives an example of scripts described for the shooting game; and [0062]
  • FIG. 20 is a diagram illustrating an example of questionnaire system operation. [0063]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • FIG. 1 shows a conceptual diagram illustrating how a game and point system using smart cards serves customers. The system is roughly divided into the service providers' side ([0064] 101) and the users' side (109). The service providers' side (101) comprises an application provider (102) that distributes a game application by loading it into smart cards and terminals, a service administrator (103) that administrates game operation, and shops (104) at which a game issue is loaded into a smart card of a user and points are exchanged for a service. Here, a single entity may double the application provider (102) and service administrator (103) or the application provider (102) and service administrator (103) may be separate entities. In normal situation, a plurality of shops (104) exist in separate sites. In some case, a shop (104) exists only in one site and belongs to the same application provider (102) and service administrator (103). The users' side (109) consists of one or more users (113) and each user (113) possesses at least one smart card (110). The user (113) may possess a game playable terminal for user (111) provided with the input/output function for executing a game application installed on the card (but, this terminal is not necessary) The game playable terminal for user (111) need not be limited to that only having facilities dedicated to playing games, but also may be an ordinary personal computer (PC) with a smart card reader/writer (the smart card accessing device) or a special portable terminal for operating with smart cards, having facilities such as checking the user's balance recorded in the card, provided that it has at least the function of data input/output to/from a smart card (110) and a support (as an auxiliary) of game application execution.
  • The application provider ([0065] 102) first loads a game application into the smart card (110) of each user (113). In the typical case, a game application is loaded into the card when the smart card (110) is issued to the user (113). After the issue of the card, a game application can be freely loaded into the card, which is a feature of the smart card on which the OS supporting the compatibility of multiple applications on the card is installed. The information on loading applications may be reflected in game management data (106) which will be described later.
  • The service administrator ([0066] 103) retrieves necessary data from the game management data (106) database in which all kinds of information on the game and point system in question are filed and uses a game management server (107) to distribute game parameters to terminals (108) at shop.
  • Shops ([0067] 104) issue rights to play game or game patterns to smart cards (110), according to how much the user (113) has paid (shopped) at the shop. The rights to play game mean the rights for the user to play with a game and the rights decrement by one after the user plays one game. The game patterns mean types of parameters of games to be executed within the smart card, including rights to play game.
  • Having rights to play game given to the smart card ([0068] 110), users (113) can play games installed in the card by means of the game playable terminal for user (111) or a game playable terminal at shop (112) placed in a shop (104) (As with the game playable terminal for user, the terminal managed by a shop may be in any form, provided it has the interface with a smart card and the game execution support function). According to the result of game play, the points in the smart card (110) are updated.
  • The points can be exchanged for a commodity or a prize at a shop ([0069] 104). Game issue data, user game play log data, and point exchange log data, whenever generated, are saved and stored into the database of game management data (106), and fed back to the next process of generating game parameters and issuing a game. In this way, the service administrator dynamically controls game parameters by using the latest game data, so that the service provider (101) can manage overall system circumstances.
  • Now, information flow during program execution on a smart card that supports the compatibility of multiple applications on the card will be briefly explained with reference to FIG. 2. The smart card ([0070] 201) is equipped with an I/O interface (202), and one or more applications (203) are assumed to have been loaded into it, according to a predetermined procedure. The application program (203) and the application program (203′), shown, are separate independent programs and each program is inhibited from making an illegal access to the other program. A terminal (120) is equipped with a smart card reader/writer (161) and an I/O interface (164), and a terminal OS (163) is installed on it, and moreover, one or more terminal programs (162) for processing with a mating application program installed on the smart card are installed on it. One or more terminal programs for processing with one application program on the smart card are normally required.
  • When the user (or a clerk) performs input ([0071] 151) to the terminal (120) via a user interface, the terminal program (162) generates a command (152) to be sent to the smart card. The terminal program (162) sends the command to the smart card (110) (153) via the smart card reader/writer (161). When the smart card (110) receives the command, the smart card OS (201) determines an application program (203) to which the command is to be sent and sends the command (154) to the application program (203) that the terminal program (162) intends to send it to. The processing part (205) of the application program (203) executes processing in accordance with the command; it accesses the application data (204) database, performs value update (155), and generates a response (156). The response is returned (158) to the terminal (120), and the terminal program (162) shows results (168). This is program execution flow in a series.
  • Even if a plurality of application programs ([0072] 203) have been loaded, the intended program execution on the smart card (110) can be performed via the terminal (120) by terminal program (162) switching to the appropriate application program (203) to which the command is issued. Basically, the application programs (203) on the smart card (110) are controlled not to affect the data for another program illegally. However, for example, under “MULTOS,” a plurality of application programs can operate in linkage with each other by a predetermined method termed delegation (meaning that one program entrusts or transfers a process to another program). (The latest version of “MULTOS” is provided with this function. The delegation function is not described in detail herein.)
  • Next, concrete smart card configurations for the game and point system embodied in a preferred embodiment of the present invention will be explained with reference to FIGS. [0073] 3 to 8. The following explanation will be made by using the case where two types of games are available on the card as an example. Here, the “types” of games are game variations for which different algorithms are used to define how game results are reflected in points, where algorithms shall be basically defined by the combination of the processes within the card, such as data calculation and random number generation.
  • FIG. 3 shows a smart card configuration that can be embodied to run game applications according to the previous invention for which the application for patent was filed (as Japanese Patent Application No. Hei 10-239812 and Japanese Patent Application No. Hei 10-321684), wherein two types of games are available on the card. The smart card ([0074] 110) operates under the card OS (201) supporting the compatibility of multiple applications on the card, such as “MULTOS” and “Java Card” and is equipped with the input/output interface (202) for data transfer to/from the terminal (120). The specifications of the above previous invention state that one algorithm for result judgment is defined for one application each. Thus, as many game application programs (200) as the number of game types available on the card are necessary. In this configuration shown, a first game application is marked (A) and a second game application is marked (B).
  • The game application program (A) ([0075] 200) comprises the data storage portions for game parameters (221), rights to play game (222), and point data (222) and actual processing parts, command analyzer (211), algorithm for result judgment (212), processor for rights to play (213), and processor for point data (214). The shaded portions in the figure, (211), (212), (213), and (214) are the processing parts that become fixed once the program has been loaded into the card. Data contained in the storage portions (221), (222), and (223) changes with the program execution. Commands from the terminal (120) are roughly divided into those regarding game issue from a shop and those regarding game play from the user. The command analyzer (211) distributes commands to the processors, according to the command type, and the processors execute processing and thereby the points may increase and the rights to play game decrement. When receiving commands for playing a game from the user, the game is executed, according to the algorithm of result judgment (212) and game parameters (221) depending on the user input. According to the game result, the points in the point data (223) storage may increase and the count of the rights to play game (222) decrement by one a game. The count of the rights to play is controlled so that the user cannot play with a game in excess of the user-playable game count corresponding to the rights given to the user from a shop.
  • The game application program (B) ([0076] 200′) is also configured the same as the program (A) and include independent processing program components installed. Because commands from the terminal (120) are sent after application selection, independently set commands are issued to each of the game application programs (200) and (200′), thereby running the application program. Of course, point data (223) and (223′) are also stored separately, and in principle, integrated processing for point exchange is impossible. Definitely different parts between game (A) and game (B) are the algorithms for result judgment (212) and (212′). Other components for processing of rights to play game and points consist of similar functional units. Notwithstanding, separate programs execute separate processing and this should be considered a problem in view of quiet an ineffective use of limited resources of smart cards.
  • To run the game application (A) program ([0077] 200) and the game application (B) program (200′) which are essentially separate applications under “MULTOS,” it is necessary to carry out the application registration and authentication procedure for each program in accordance with the application issue scheme defined for the OS when installing the applications. An outstanding feature of smart cards supporting the compatibility of multiple applications on the card is that dynamic application loading and unloading are possible after the card issue. For applications such as game software for which frequent updating of the contents is desirable, however, whenever a new game program programmed to run with another algorithm is loaded, carrying out the application registration and authentication procedure is troublesome and burdensome. Moreover, when switching from game (A) to game (B) occurs, the user might wish the accumulated points as the result of the previous plays with the game (A) to be inherited for natural feelings. For the smart card configuration shown in FIG. 3, however, it is not simple to transfer points from one game to another and perform accompanied point information management.
  • As concerns counting points in common for a plurality of games, a possible method of resolving the program is using a special application for point management besides game applications. This method is feasible by the above previous invention. This method is such that a point application program in addition to game applications is prepared and point data management is performed within it. When requested from the game applications, point change processing is executed by using the delegation of the card OS ([0078] 201). Even if the integrated point management problem is solved by using this method, however, the application registration and authentication procedure for a new game program to be added is still required and the above method does not provide a drastic solution.
  • Then, a method of processing a plurality of types of games within a single application will be considered below. [0079]
  • FIG. 4 shows a smart card configuration according to the method in which an game application is installed comprising common parts for point data for which integrated management is desirable and command processing and portions for specific processing such as game parameters and result judgement algorithm. The latter portions are prepared as many as the number of game types. On the smart card ([0080] 110), a game application program (200) is installed, wherein two types of games, game (A) and game (B) can be processed. Although another game type, game (C), of course, can be incorporated into the program, the following explanation will discuss the example case where the application program accommodating two games is installed as shown. Note that the game types to be executed are fixed when the application is issued and adding a new game cannot be performed in this example.
  • Point data ([0081] 223) storage is common so that points acquired as the result of game play can be processed common for a plurality types of games. The command analyzer (211) that receives commands from the terminal and supplies them to the appropriate processor is also common to a plurality of games, separate from the game processing components. Game parameters (221), rights to play game (222), and algorithm for result judgment (212) are provided as many as the number of game types as the components to execute different processing for different games. The processor for rights to play (213) and processor for point data (214) are provided as common-processors.
  • Establish a command identification scheme in advance so that commands sent from the terminal ([0082] 120) can be identified, according to the game type. The command analyzer (211) analyzes commands it receives, finds which game type to which the commands are supplied, and selects the appropriate algorithm for the commands. If the commands are those for game (a), processing is executed, according to the algorithm for result judgment (212) for game (A) and the point data (223) may be updated, according to the result of the processing. Updating the points in the point data (223) storage is performed in the same way whether game A or game (B) has been executed.
  • FIG. 5 shows a smart card configured according to a game execution method upgraded from the corresponding method for the card shown in FIG. 4. Basically, most of game processes can be represented as the iteration of processing user input values, generating a random number in the card in accordance with the input timing, and judging the result from the combinations of local variables and constants given as parameters. Even if the algorithm for result judgment differs between games, most of other portions of a game application can be executed in common. Thus, part of the game application is made modular for processes that can be executed in common for a plurality of games, such as generating a random number, addition/subtraction, and iteration as common process components. Common process components ([0083] 244) are prepared as component modules for executing processes that are required in similar context.
  • With the focus on game (A), the application includes the storage areas for game parameters ([0084] 221) and rights to play game (222) and definition of component call (225) in the game (A) main (215) defines the procedure for judging whether the user wins at the game, that is, what sequence in which the common process components (224) are to be called. The program is executed in almost the same way as for the method used for the smart card shown in FIG. 4. The command analyzer (211) selects the appropriate game main, according to the command type. Thereby, a plurality of games, as assembled into the program beforehand, can be processed. For the smart card example shown in FIG. 5, as compared with that shown in FIG. 4, the processes that can be executed in common are packaged as components in as large part of the program as possible, so that efficient application operation can be achieved.
  • Whether in the game execution method for the card shown in FIG. 4 or in the corresponding method for the card shown in FIG. 5, a plurality of game types assembled in advance into the application as the application was programmed can be processed and one of different games can be executed, the appropriate one being selected in accordance with the commands from the terminal, but another game type cannot be assembled into the application once the programmed application has been issued. To enable another game type to be executed on the card, it is necessary to program a new application that accommodates the game and replace the existing application on the card by the new application, when the application registration and authentication procedure must be carried out again. [0085]
  • In FIG. 6 and FIG. 7 that follow, a method is proposed in which replacing a game type by another game type or adding another game type can be performed without being accompanied by the application registration and authentication procedure and application replacement. [0086]
  • Specifically, game definition scripts supercede the definition of component call ([0087] 225) used in the game execution method for the card shown in FIG. 5 and a script interpreter for interpreting and executing the game definition scripts is prepared in the processing part of the game application program. Separate suits of the scripts that are replaceable define different games and the interpreter practically interprets and executes each suit of the scripts.
  • FIG. 6 shows a smart card configuration with a game application being installed on the card, the application programmed according to the method in which game definition scripts are described and executed by the interpreter. Here, again, the shaded portions are fixed components of the program that are predetermined. [0088]
  • In this example, game definitions and rights to play game are handled as separate entities. In the same manner as for the examples shown in FIG. 1 to FIG. 5, the rights to play game ([0089] 222) and the point data (223) are processed by the processor for rights to play (213) and the processor for point data (214) in common for all types of games. The common process components (224) are predefined and the game definition scripts (226) define the algorithm for result judgement that differs for each game by describing sequence in which these components are to be called.
  • These game definition scripts ([0090] 226) are replaceable and a processor for exchanging game scripts (216) controls loading/unloading the scripts. Despite that the strict application issue scheme is prescribed to assure the smart card security, it cannot be denied that there is a possibility of safety loss due to making game exchange in units of game definition scripts possible for simple and convenient game exchange. Within the application program, therefore, the following must be checked: the game definition scripts to be stored is not falsified; the authorized programmer has programmed the scripts; and the game application is granted the permission to store the scripts. Specifically, a particular game issue scheme instead of the OS's application issue scheme must be prepared within the application and storing game scripts must be controlled so that safe game scripts only will be installed on the card, based on this scheme. The processor for exchanging game scripts (216) fills this controlling role.
  • The rights to play game ([0091] 222) are data that defines how many times the card user can play with what type of game and this data is stored into the card when the game is issued. When the card receives the commands for playing a game from the terminal, if the rights to play game (222) exist, the script interpreter (215) interprets and executes the contents of the game definition scripts (226) for the game. When the game play finishes, the rights to play game (223) decrement by one as explained for the fundamental card configuration. The card configured as shown in FIG. 6 can accommodate a plurality of game types by storing game definition scripts (226) for each game type into the game application on the card. In addition, under the control of the processor for exchanging game scripts (216), a game type can be replaced by another game type even after the application is loaded into the card.
  • For the smart card example shown in FIG. 7, which resembles the example shown in FIG. 6, the data on the rights to game play is included in game definition scripts. That is, the game definition scripts ([0092] 226) are programmed to include one right to play game (may include a plurality of rights to play game, not limited to one right). Once a game has been executed once (or two or more times corresponding to a predetermined playable game count) described in the game definition scripts, control means is required to delete the game scripts so that the same scripts will never be executed again thereafter. The rights to play game and the game definition scripts are managed together under a single processor, namely a processor for storing game data (217). This processor also deletes game scripts that have been executed completely as well as stores game scripts sent from the terminal when the game is issued into the data area. Needless to say, the processor for storing game data (217) must perform the script safety check as the processor for exchanging game scripts (216) shown in FIG. 6 does.
  • FIG. 8 shows a game application configured to adapt the game execution method for the card shown in FIG. 6 for a plurality of issuers of points. The rights to play game ([0093] 222) are stored, each data thereof comprising a triple of entries: issuer, game ID, and play count. Accordingly, points are stored per issuer in the storage area for point data (223). When the card receives the commands for playing a game sent from the terminal, the rights to play the game (222) are checked. For the game type for which the rights to play remains, the script interpreter (215) executes the game, according to the game definition scripts (226). Following the game execution, points may be added to the point data (223) for the issuer of the game and the rights to play game (222) for the issuer of the game that has just been executed decrement by one.
  • This method is application of the point system concept according to the above-mentioned pervious invention for which the application for patent was filed (as Japanese Patent Application No. Hei 10-307216), wherein the point data ([0094] 223) is retained separately for a plurality of issuers, but not unified. In this method, the card can accommodate not only a plurality of game types, but also a plurality of point service providers. Using this method, game service administrators can offer shops a game application rental service which would expand the potential availability of game applications.
  • With reference to FIG. 9 and FIG. 10, now, system operation examples of the game and point system using either of the smart cards configured as illustrated in FIG. 6 and FIG. 7 will be explained below. In the system operation example illustrated in FIG. 9 wherein the smart card shown in FIG. 6 is used, game definition scripts and rights to play game are separate and game exchange is assumed to be performed at suitable timing. In the system operation example illustrated in FIG. 10 wherein the smart card shown in FIG. 7 is used, game definition scripts and rights to play game are put together and the scripts of a game are invalidated (deleted) whenever the game has been executed completely. [0095]
  • FIG. 9 is a diagram illustrating an example of the game and point system operation using the smart card on which a game application accommodating a plurality of games is installed. In this example, game definition scripts and rights to play game are separate. [0096]
  • A game application program ([0097] 200) is assumed to have been loaded into the smart card (110). The game application (200) comprises a command analyzer (211), a script interpreter (215), a processor for exchanging game scripts (216), a processor for rights to play (213), a processor for point data (214), and other components. Point data (223) is stored as points managed per issuer Company. Rights to play game (222) are also managed per issuer and the game type and playable count per issuer are stored. Game definition scripts (226) are game contents defined by describing sequence in which the common process components (224) are to be called. In fact, the script interpreter (215) interprets the contents of the scripts and executes the scripts. The game definition scripts (226) can be exchanged for new scripts as required.
  • The processing procedure for each phase of game exchange, game issue, game play, and exchanging points for a service will be explained below. [0098]
  • (Game exchange) [0099]
  • From a game maintenance terminal ([0100] 114) at a shop (104) or any other place, a command to exchange game scripts (132) and game definition data (scripts) (141) are sent to the smart card (110). Then, once the command analyzer (211) has interpreted the received command as the command to exchange game scripts (132), the processor for exchanging game scripts (216) executes the processing of game definition exchange. At this time, it must be assured that the game definition scripts received from the terminal have been issued from the authorized issuer because the scripts can rewrite the point data. For the assurance thereof, all game definition scripts (141) issued must include a cipher key that authenticates the authorized issuer of the scripts, the key encrypted in accordance with the game issue scheme predefined within the application. According to the cipher key, the processor for exchanging game scripts (216) must perform authentication of the scripts it received. Furthermore, program exchange may be necessary on the terminal side when a new game is issued, because a terminal program appropriate for the new game is required on the game playable terminal (111) when the user plays the game.
  • (Game issue) [0101]
  • According to how much the user paid for shopping or service at a shop ([0102] 104) of Company (X), a terminal at shop (108) sends the smart card (110) a command to add the right to play game (133) and right to play data (142). The right to play data (142) contains information that the user can play with the game (A) once and the issuer is Company (X). To assure safety, encryption is desirable for this data as well. The command analyzer (211) interprets the command and the processor for rights to play (213) adds the right to the rights to play game data (222).
  • (Game play) [0103]
  • When the user ([0104] 113) is playing with a game, commands for playing game (131) are sent to the smart card (110). If the rights to play game (222) exist, the user can play the game of the appropriate type. Following the game play, the points retained in the point data (223) storage may increase, wherein the game result may update the points for the issuer of the rights to play game included in the rights to play game data (222) for the game just executed. After the game play, the rights to play game (222) decrement by one. To enable game execution, a game executing terminal program appropriate for the game type within the smart card must exist in the game playable terminal (111).
  • (Exchanging points for a service) [0105]
  • Points accumulated as point data ([0106] 223) while the card user has so far played games can be exchanged for a predetermined service at a shop (104). When the card user wants to exchange points for a service, a command to calculate points (134) is sent to the smart card (110) from a terminal at shop (108) (that maybe the same as the terminal from which rights to play game are issued or different from such terminal). The command analyzer (214) passes the processing control to the processor for point data (214) and the processor for point data (214) executes subtraction of points. If the shop (104) from where the command was sent belongs to Company (X), only the points issued by the Company (X) can be exchanged for a service.
  • In the system operation scheme illustrated in FIG. 9, the user can play games of as many types as the number of the suits of game definition scripts ([0107] 226) (of course, only if the rights to play game exist in the card). By replacing game definition scripts (226) with new scripts as required, the game application (200) can continue to offer a new game without being replaced.
  • FIG. 10 is a diagram illustrating another example of the game and point system operation using the smart card on which a game application accommodating a plurality of games is installed. In this example, game definition scripts and rights to play game are unified. As is the case with the system operation example in FIG. 9, it is assumed that a game application program ([0108] 200) have been loaded into the smart card (110). The game application (200) comprises a command analyzer (211), a script interpreter (215), a processor for storing game data (217), a processor for point data (214), and other components. Point data (223) is stored as points managed per issuer Company. Difference from the example in FIG. 9 is that game data (227) is stored, each data comprising a pair of game definition scripts and issuer information. Similarly, the script interpreter (215) executes game definition scripts by interpreting the contents of the scripts. A suit of scripts can be regarded as one right of the user to play game. Game execution may rewrite only the point data (223) for the issuer of the game. Once the game has finished, the suit of the game scripts is invalidated by deleting it so as not to be executed again.
  • For this example, the processing procedure for each phase of game issue, game play, and exchanging points for a service will be explained below. [0109]
  • (Game issue) [0110]
  • According to how much the user paid for shopping or service at a shop ([0111] 104) of Company (X), a terminal at shop (108) sends the smart card (110) a command to store game scripts issued (135) and game data (143) containing game definition scripts and issuer. To assure safety, a cipher key that authenticates the authorized issuer of the scripts, encrypted in accordance with the predefined scheme, must be attached to the game data (143). According to the cipher key, the processor for storing game data (217) must perform authentication of the scripts it received. Furthermore, program exchange may be necessary on the terminal side when a new game is issued, because a terminal program appropriate for the new game is required on the game playable terminal (111) when the user plays the game.
  • (Game play) [0112]
  • When the user ([0113] 113) is playing with a game, commands for playing game (131) are sent to the smart card (110). At this time, if the game data (227) exists, the user can play the game described in the game definition scripts. Following the game play, the points retained in the point data (223) storage may increase, wherein the game result may increase the points for the issuer included in the game data (222) for the game just executed. After the game play, the game data (227), the scripts of the game are erased so as not to be executed again. To enable game execution, a game executing terminal program appropriate for the game type within the smart card must exist in the game playable terminal (111).
  • (Exchanging points for a service) [0114]
  • Points accumulated as point data ([0115] 223) while the card user has so far played games can be exchanged for a predetermined service at a shop (104). When the card user wants to exchange points for a service, a command to calculate points (134) is sent to the smart card (110) from a terminal at shop (108) (that maybe the same as the terminal from which rights to play game are issued or different from such terminal). The command analyzer (214) passes the processing control to the processor for point data (214) and the processor for point data (214) executes subtraction of points. If the shop (104) from where the command was sent belongs to Company (X), only the points issued by the Company (X) can be exchanged for a service.
  • In the system operation scheme illustrated in FIG. 10, because every game data ([0116] 227) includes game definition scripts, there may exist duplicated suits of scripts in the card if a plurality of same type games are stored, which may be considered inefficient. However, the flexibility of game type selection increases as compared with the example illustrated in FIG. 9 wherein game definition scripts are replaced by new scripts as required. Because issuing the right to play game means issuing a new game, the game application (200) can continue to offer a new game without being replaced. Whenever a new type game is developed, however, the associated program for playing the game on the terminal needs change. In a situation where game playable terminals are distributed, updating the programs on the terminals is likely to be time-consuming work.
  • Next, the flow of processing of the script interpreter will be explained with reference to FIG. 11. In the game definition data ([0117] 300) area, parameters (301), rights to play (302), and scripts description (303) are stored. Separate from the game data, point data (308) exists.
  • The script interpreter has a program counter ([0118] 304) as a local variable and work arrays (305) and is able to read a command parameter (306) sent from the terminal and rewrite a response parameter (307) to be returned to the terminal.
  • When a command is sent to the smart card from the terminal, the script interpreter receives and analyzes the command from the terminal ([0119] 311), and selects the specified game type (i.e., it calls the specified game definition scripts) (312). At this time, the interpreter stores a parameter included in the received command as the command parameter (306).
  • The interpreter resets ([0120] 313) the program counter (304) and begins to execute the game scripts. The interpreter executes in order the scripts described in the scripts description (303) part; it basically increments the program counter one by one (314) while analyzes the scripts in order (315) and calls appropriate common process components, thereby executing the scripts. If the interpreter encounters a “wait for command” script, it immediately returns the response to the terminal and awaits the next command reception (316). If the interpreter encounters an “end” script, it returns the response to the terminal and exits from the script execution process (317). If the interpreter encounters a script in which a jump or a branch is specified, it resets the program counter to the jump address and proceeds to analyzing the next script (318). If the interpreter encounters any other script, it calls the appropriate common process component associated with the script and actually executes the script (319), and returns to the step of incrementing the program counter by one (314). During the script execution (319), the interpreter reads a value of command parameter (306) while updates a value in the work arrays (319) and a value of response parameter (308). By continuing this processing, the game application is run.
  • FIG. 12 illustrates an example of scripts described in a language to call common process components. Here, array [] is one of the work arrays ([0121] 305), cmd [ ] denotes a command parameter (306), and rsp [ ] denotes a response parameter (307). Each script is to call one common process component and fills the role of running the application program. Up to three parameters are assigned to one script.
  • In this example, scripts are described in a likely usual programming language to facilitate understanding. Considering that the scripts are executed on the smart card with small storage capacity, a more specialized language may be suitable for describing the scripts limited to game application (for example, representation in byte strings, each byte consisting of fewer bits). A method may be used in which any compiling means is prepared on the terminal side from which scripts are issued to translate scripts into those represented in byte strings and the translated scripts are issued. [0122]
  • With reference to FIGS. 13 through 19, examples of three types of games that the program application can offer will be given below, wherein game definitions are represented by using the scripts defined in FIG. 12. [0123]
  • FIG. 13 shows examples of slot machine game play screens appearing on the game playable terminal, wherein three boxes (corresponds to three random numbers) are shown and a range of settable values for a random number represented in one box is 0 to 2. The values settable in each box correspond to three fruit symbols: “1” for an apple symbol, “2” for a Japanese orange symbol, and “3” for a banana symbol. [0124]
  • The game begins with screen (a). The current points ([0125] 401) and remaining games (402) that the user can play are shown and values in three boxes (405) are not fixed yet with the reels rotating on the screen as depicted. The user pushes three “Push” buttons (406) one by one. By each button push, a command to generate a random number is sent to the card and the symbol corresponding to a fixed value of the random number is displayed in the box.
  • Screen (b) is an example screen after the first user choice by the “Push” button, A random number of “0” is assumed generated in the card and the apple symbol is displayed in the corresponding box. This is repeated three times. [0126]
  • Screen (c) is an example screen after the third user choice by the “Push” button, when one game is over (the user wins). Because of matching of the symbols in the three boxes, a message ([0127] 403) appears, indicating that the game result is “you win” and “100” points the user gained at the game are added to the points. The points increase accordingly.
  • Screen (d) is another example screen after the third user choice by the “Push” button, when one game is over (the user loses). Because of mismatching of the symbols in the three boxes, a message ([0128] 404) appears, indicating that “you lose” and no points are added.
  • FIG. 14 shows the scripts description example for the slot machine game shown in FIG. 13, described by using the scripts in FIG. 12. The game is represented in 18 lines of scripts, [0129] lines 00 to 11 (binary).
  • [0130] Lines 00 to 02: To be called upon the first “Push” button push. One random number is generated and stored into a work array and the fixed value of the random number is returned. To return the operation result to the terminal, a “Return” script is defined.
  • [0131] Lines 03 to 05: To be called upon the second “Push” button push. One random number is generated and stored into a work array and the fixed value of the random number is returned.
  • [0132] Lines 06 to 08: To be called upon the third “Push” button push. One random number is generated and stored into a work array. A value to indicate “the last” is placed in the response and the processing proceeds to result judgment.
  • [0133] Lines 09 to 11: Result judgment. If the stored values of three random numbers all match, predetermined points are added to the current points. Finally, the result is returned to the terminal and the processing terminates.
  • FIG. 15 shows examples of roulette game play screens appearing on the game playable terminal, wherein the win probability is one third and the user is given three betting chances. Three possible values of random numbers correspond to “A,” “B,” and “C.” Illustration in color might be easier to see, though not be presented here. [0134]
  • Screen (a) is the initial screen. The current points ([0135] 401) and remaining games (402) that the user can play are shown. To begin the game, choose one of betting places (407) “A,” “B,” and “C” before the roulette (408) rotates.
  • Screen (b) is a screen that appears, following the game start. Here, the user is assumed to have chosen “B” out of the betting places ([0136] 407) and a bullet is placed in the B box. Score (410) and remaining chances (411) are shown. Because the user is given three betting chances for this game, “3” is shown as the remaining chances (411). When the roulette starts to run as the user pushes the “Start” button (409), the remaining chances (411) decrement by one.
  • Screen (c) is a screen wherein the roulette ([0137] 408) is rotating (this state appears on the screen, while the program on the card side waits for command input). When the user pushes the “Stop” button (to stop the roulette running) (406), the associated command is issued to the smart card.
  • Screen (d) is a screen when one roulette run is over. According to the value of the random number generated in the card, that is, if there is a match between the bet place you chose and the value, a “You Win” ([0138] 403) message appears and the score increases.
  • Screen (e) is a screen when one roulette run is over and you lose. A “You lose” ([0139] 404) message appears and the score does not increase.
  • One game ends with screen (f) after three roulette runs with a random number generated. A “GAME OVER” message and the score count are displayed ([0140] 412).
  • FIG. 16 shows the scripts description example for the roulette game shown in FIG. 15, described by using the scripts in FIG. 12. The game is represented in 27 lines of scripts, [0141] lines 00 to 1a (binary).
  • [0142] Lines 00 to 05: To be called upon the first “Stop” button push. The user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array. The comparison result and the value of the random number are returned to the terminal.
  • [0143] Lines 06 to 0b: To be called upon the second “Stop” button push. The user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array. The comparison result and the value of the random number are returned to the terminal.
  • Lines 0c to 10: To be called upon the third “Stop” button push. The user-input value received as a command parameter is stored into a work array and compared with a random number generated and the result of comparison is stored into another array. [0144]
  • [0145] Lines 11 to 1a: Result judgment. According to the three comparison results, points are added to the current points. Finally, the result is returned to the terminal and the processing terminates.
  • FIG. 17 shows examples of shooting game play screens, wherein five boxes appear and the user is given five chances to play. The user clicks at one of the boxes to hit the target that moves at random, appearing in any box a second. If the target appears in the box at which the user clicked, the user wins. Clicking can be repeated five times. [0146]
  • Screen (a) is the initial screen. The current points ([0147] 401) and remaining games (402) that the user can play are shown. To begin the game, click the “Start” button (409).
  • Screen (b) is a screen before the user clicks at a box on the screen. In any of the five boxes ([0148] 405), the target symbol (413) appears at random. The target position changes, according to the value of the random number that is generated per second. In the screen, the current game score (410) and remaining chances (411) to play are displayed.
  • Screen (c) is a screen when the user clicks at a box on the screen. In this case, because the target appears in the box that the user has chosen, a “click - hit” ([0149] 414) message appears and 10 points are added to the score.
  • Screen (d) is another screen when the user clicks at a box on the screen. If the box that the user has chosen differs from the box where the target appears, a “click - lose” ([0150] 415) message appears.
  • The game ends with screen (e). When the user finishes using five play chances, a “GAME OVER” message and the score count are displayed ([0151] 412). If the count of the remaining games (402) is other than 0, a new “Start” button (409) appears.
  • FIG. 18 illustrates the procedure of processing between the terminal ([0152] 120) side and the card (110) side regarding the shooting game shown in FIG. 17. In this procedure that is the same for other programs on the smart card, basically, the terminal (120) sends the card a command and a parameter and the card (110) executes processing in accordance with the received command and returns a response to the card. Because the smart card on which the current version of MULTOS and other OSs is installed does not have a built-in clock (the operation on the card side is triggered by command reception from the terminal), a request for generating a random number must be sent per second from the terminal in order that the card generates a random number a second to update the screen.
  • First, the terminal ([0153] 120) sends a command (parameter=0) (321) that requests the card to generate a random number.
  • The card ([0154] 110) receives the command (331), generates a random number in the value range corresponding to the number of boxes, assigns the random number to variable R (332), and sends a response with parameter=R back to the terminal (333). The terminal receives the response and updates the screen (322), according to the value of R. Based on a one-second timer (323), the above command-response process (from sending a command 321 until screen update 322) is repeated at intervals of one second.
  • When an input from the user (clicking at a box) occurs, the box number that the user has chosen is assigned to variable D ([0155] 324) and the terminal sends a command with parameter=D (321). The card receives the command (331) and compares the last generated random number R that has been stored with the received box number D (334). If a hit is found by this comparison, points are added and the result of the comparison is returned to the terminal (335). The terminal receives the result and shows the result on the screen (412). The above process is repeated by the number of chances to play (five times in the example shown in FIG. 17).
  • FIG. 19 shows the scripts description example for the shooting game illustrated in FIGS. 17 and 18, described by using the scripts in FIG. 12. If the command parameter is “0.” a random number is generated. Unless that, the user input is compared with the value of the last generated random number. Unlike the preceding examples of game scripts, this example of scripts includes a loop. [0156]
  • [0157] Lines 00 to 02: Work arrays are initialized.
  • Line 03: The beginning of loop [0158]
  • Line 04: Branching occurs, according to the value of the command parameter. [0159]
  • [0160] Lines 05 to 0d: When a value other than “0” is given as the command parameter, the user-input value is compared with the value of the random number and the result of comparison is stored. The loop counter increments by one. Unless the loop counter indicates the last time, the result of the comparison is returned to the terminal. After passing the processing control to the terminal, next time it returns, the processing returns to the beginning of loop (line 03).
  • [0161] Lines 0e to 11: Following the last loop execution, points are added to the point count, based on the stored results of comparison.
  • [0162] Lines 12 to 16: If the command is a dummy, a random number is generated and returned to the terminal. The processing returns to the beginning of loop.
  • By repeating the above, the processing illustrated in FIG. 18 can be implemented. [0163]
  • As described above, by using the scripts given in FIG. 12, a plurality of types of games, such as three ones given as examples, can be defined. The foregoing three game scripts are examples and many types of games can be defined by describing the processes of generating a random number and comparing the random number with the input from the user in combination. The script interpreter executes these games defined in script descriptions as illustrated in FIG. 11, so that one application program can offer a plurality of types of games that can be selectively executed. [0164]
  • Although the above explanation discussed a game application program and its operation enabling a plurality of types of games to run on the smart card, this method can be applied to applications other than games. The present invention can be applied to application software for: e.g., a questionnaire system that the user can get points by answering questionnaires, which are updated after answered, shown on the screen; and an advertisement system that the user can get points by reading a specific advertisement. Such application generates value such as points in response to user operation and controls the contents so that the same suit of scripts will never be executed again. For this purpose, questionnaire answer logs and advertisement reading logs for each user must be stored in the card and control is required to prevent same scripts of questionnaire or advertisement from being loaded into the card a plurality of times. For game scripts, once a suit of scripts has been executed, it is deleted or the rights to play game decrement by one, which is only required for script management. For questionnaire scripts, additional requirement is that the shop side collects the answer data. [0165]
  • FIG. 20 shows a questionnaire system operation example to which the present invention is applied. This example is essentially similar to the game system operation example illustrated in FIG. 10, except that the questionnaire answer data is collected. [0166]
  • A questionnaire application ([0167] 500) is assumed to have been loaded into the smart card (110). This questionnaire application (500) comprises a command analyzer (211), a script interpreter (215), a processor for storing scripts of questionnaire (503), a processor for point data (214), and other components. Questionnaire data (501) is stored, each data thereof comprising a triple of entries: questionnaire scripts, issuer, and answer data. The answer data entry is blank before the user answers the questionnaire that is currently presented. When the user answers the questionnaire, the answer data is stored into place. This answer data entry also fills the role of a flag to indicate whether the user has answered the questionnaire. When this entry contains data, the same suit of questionnaire scripts cannot be executed again. Logs of answers to questionnaires are stored as the answer log (502) data to control script loading so that any questionnaire once answered will never be loaded again. As is the case in FIG. 9 and FIG. 10, point data (223) is stored as points managed per issuer Company.
  • At a shop ([0168] 104) of Company (X), a terminal at shop (108) sends the smart card (110) a command to store questionnaire issued (506) and questionnaire data (507) containing questionnaire definition scripts and issuer. As is the case with game scripts, this data must be assured that it has been issued from the authorized issuer. For this purpose, a cipher key that authenticates the authorized issuer of the scripts, the key encrypted in accordance with the predefined scheme, must be attached to the questionnaire data. According to the cipher key, the processor for storing scripts of questionnaire (503) must perform authentication of the scripts it received. The processor for storing scripts of questionnaire (503) also checks to see whether the questionnaire data (507) it received has been answered by referring to the answer log (502) database, thereby performing the function of control over scripts to prevent answered questionnaire scripts from being stored into the questionnaire data (501) database.
  • When the user ([0169] 113) answers a questionnaire at the user terminal (509), commands for answering (505) are sent to the smart card (110). If the questionnaire data (501) exists, the user can answer the questionnaire described in the questionnaire definition scripts. The questionnaire contents, not only requesting the user to answer straightforwardly, are elaborated so that the user can select the detail level of answer and the next questionnaire contents will change, according to the answer to the preceding one. Once the user has answered the questionnaire, points weighted in accordance with the answer are added to the point data (223) for the issuer of the questionnaire and the answer data is added to the questionnaire data (501) database in place coupled with the scripts. The questionnaire data (501) complete with the scripts and the answer data cannot be answered again. Adding answer data to the answered questionnaire data (501) is, in other words invalidating the questionnaire data.
  • When points are exchanged for a service at a terminal at shop ([0170] 108) or the next questionnaire of the same issuer is issued, the answer data to the previously answered questionnaires must be collected. Because the answered questionnaire scripts coupled with answer data are retained in the invalid state, the questionnaire data (501) overflow is likely to occur if answer data is accumulated without being collected. Thus, collecting answer data at suitable timing is required. When a request for collecting answer data is issued to the card,, the processor for collecting answer (504) encrypts answer data and returns it to the terminal (108). At the same time, the above processor erases the questionnaire data (501) for the scripts for which the answer data is lost and adds log information for the lost answer data to the answer log (502) database.
  • In the way described above, the application of the present invention can be expanded to cover the questionnaire system, not only applicable to games. Furthermore, the invention can be applied to the advertisement reading system in a similar way. [0171]
  • How the present invention which can be preferably embodied as explained above produces effects will be described in detail for each of the six major entities of the invention, specified in the section of “Means for Solving the Problems.” [0172]
  • On the smart card that can be embodied as a preferred embodiment of the present invention with [0173]
  • (1) An application program comprising the following elements: [0174]
  • a) Game executing components [0175]
  • b) Storage for game definition scripts [0176]
  • c) Script interpreter [0177]
  • d) Storage and processor for point data [0178]
  • e) Storage and processor for rights to play game [0179]
  • f) Command analyzer [0180]
  • One application program installed on the smart card can offer a plurality of types of games that can be selectively executed. [0181]
  • In addition, [0182]
  • (2) Processor for storing game definition scripts [0183]
  • The processor enables the introduction of a new type of game in any time even after the game application program is loaded into the smart card without being accompanied by application program exchange. Consequently, a more flexible game system can be provided. [0184]
  • The above processor controls storing game scripts, based on the game issue scheme prescribed in the application program, so that the processing parts of the application program can be changed in safety. This means the release from troublesome and time-consuming tasks accompanied by meeting the application issue scheme prescribed in the card OS. [0185]
  • Once the game application program for executing common processes has been loaded into smart cards on which different OSs are installed, such as “MULTOS” and “Java Card,” programmers can program new games that are compatible on these cards without caring about the difference between the OSs. [0186]
  • (3) Function of point management per issuer enables the management of a plurality of types of games that are issued from a plurality of different issuers within one application. Consequently, a game system that is used more widely can be provided. [0187]
  • On the terminal device for operating with the smart card in question [0188]
  • (4) Function of issuing a game [0189]
  • (6) Function of calculating points [0190]
  • These functions make it possible that a plurality of types of games are issued to the smart card without being accompanied by game application program exchange and a flexible game system including point management is operated in safety. [0191]
  • Equipped with the user interface for playing games [0192]
  • (5) Function of executing a game [0193]
  • The function allows the user to enjoy playing with a game while the user can get points. [0194]
  • According to the present invention that can be preferably embodied as described herein, therefore, game applications for more flexible use can be introduced into a smart card system in safety. Increase of points linked with game results motivates the user to use the card more often and is effective for getting more customers from the viewpoint of the application provider. Furthermore, the present invention is significantly useful for making smart card systems popular. [0195]
  • Noticeable features of the present invention are the introduction of game definition scripts and a script interpreter and the method of control over storing scripts, based on the game issue scheme prescribed in the application program installed on the card. The invention provides a script loading/unloading method in which the contents of only the part for processing that is dependent on user input in a program, not limited to game application, is replaced by new contents without being accompanied by program exchange. This script loading/unloading method enables the development of more flexible and convenient smart card applications, which is released from platform restrictions. [0196]
  • The present invent makes it possible to replace game scripts in a program installed on a smart card by new game scripts without being accompanied by program exchange. [0197]
  • Technical items in connection with the present invention are listed below. [0198]
  • 1. An application program that can run under an operating system (OS) installed on a smart card furnished with a storage means and an input/output interface and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program. [0199]
  • 2. The application program described in [0200] item 1, wherein the smart card includes point data storage for storing points the card user gained, the count of which may be updated by the result of program execution in accordance with the run procedure defined in scripts.
  • 3. The application program described in [0201] item 1, wherein processing defined in scripts can generate different results, according to the input by the user of the smart card and the timing of execution thereof, and the user cannot predict the result of processing in advance.
  • 4. The application program described in [0202] item 1, including a function that, following the execution of processing defined in scripts, invalidates those scripts and sets the processing impossible to do.
  • 5. The application program described in [0203] item 1, including storage for rights to execute that stores the rights to execute scripts, defining the maximum number of times the processing defined in scripts can be executed, and a function that, immediately following the execution of processing defined in scripts, decrements the count of the rights to execute those scripts by one.
  • 6. The application program described in [0204] item 1, configured such that scripts can be stored into the storage means through the input/output interface after the application program is loaded.
  • 7. The application program described in [0205] item 1, including an authentication handler that performs a predetermined authentication procedure to assure that valid scripts, free of falsity, are stored when scripts are stored into the storage means through the input/output interface after the application program is loaded.
  • 8. The application program described in [0206] item 2, including a function that adds up points per script issuer, attaches the identifier of issuer to the scripts or the rights to execute scripts, and just after processing defined in scripts is executed, updates only the points associated with the issuer of the scripts, according to the result of the processing.
  • 9. A storage medium holding an application program that can run under an operating system (OS) installed on a smart card furnished with a storage means and an input/output interface and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program. [0207]
  • 10. The storage medium described in item 9, wherein the smart card includes point data storage for storing points the card user gained, the count of which may be updated by the result of program execution in accordance with the run procedure defined in scripts. [0208]
  • 11. The storage medium described in item 9, wherein processing defined in scripts can generate different results, according to the input by the user of the smart card and the timing of execution thereof, and the user cannot predict the result of processing in advance. [0209]
  • 12. The storage medium described in item 9, including a function that, following the execution of processing defined in scripts, invalidates those scripts and sets the processing impossible to do. [0210]
  • 13. The storage medium described in item 9, including storage for rights to execute that stores the rights to execute scripts, defining the maximum number of times the processing defined in scripts can be executed, and a function that, immediately following the execution of processing defined in scripts, decrements the count of the rights to execute those scripts by one. [0211]
  • 14. The storage medium described in item 9, configured such that scripts can be stored into the storage means through the input/output interface after the application program is loaded. [0212]
  • 15. The storage medium described in item 9, including an authentication handler that performs a predetermined authentication procedure to assure that valid scripts, free of falsity, are stored when scripts are stored into the storage means through the input/output interface after the application program is loaded. [0213]
  • 16. The storage medium described in [0214] item 10, including a function that adds up points per script issuer, attaches the identifier of issuer to the scripts or the rights to execute scripts, and just after processing defined in scripts is executed, updates only the points associated with the issuer of the scripts, according to the result of the processing.
  • 17. A terminal device capable of operating with a smart card furnished with a storage means and an input/output interface, including a means to load an application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program into the smart card via the input/output interface. [0215]
  • 18. A terminal device capable of operating with a smart card furnished with a storage means and an input/output interface, including a means to load scripts as part of an application program from outside via the input/output interface into the smart card wherein the application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program is stored in the storage means. [0216]
  • As many apparently widely different embodiments of this invention may be made without departing from the spirit and scope thereof, it is to be understood that the invention is not limited to the specific embodiments thereof except as defined in the appended claims. [0217]

Claims (17)

What is claimed is:
1. A method of loading an application program into a smart card furnished with a storage means and an input/output interface, whereby the application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program is loaded from outside via the input/output interface into the smart card.
2. The method of loading an application program into a smart card according to
claim 1
, wherein the application program is configured such that common process components as a set of a plurality of processing modules each of which outputs a given result in response to a given command are packaged inside the program in order that the processing modules in the common process components are selectively called when the scripts are interpreted and executed.
3. The method of loading an application program into a smart card according to
claim 1
, wherein the scripts are installed into the smart card after the application program is installed into the smart card.
4. The method of loading an application program into a smart card according to
claim 1
, wherein the scripts are stored into the storage means through the input/output interface after the application program is loaded.
5. The method of loading an application program into a smart card according to
claim 1
, wherein a first script is installed into the smart card after the application program is installed into the smart card and a second script that is different type from the first script is installed into the smart card.
6. The method of loading an application program into a smart card according to
claim 1
, wherein processing defined in the scripts can generate different results, according to the input by the user of the smart card and the timing of execution thereof, and the user cannot predict the result of processing in advance.
7. The method of loading an application program into a smart card according to
claim 1
, including a process that, following the execution of processing defined in the scripts, invalidates those scripts and makes the processing impossible to do.
8. The method of loading an application program into a smart card according to
claim 1
, including storage for rights to execute that stores the rights to execute scripts, defining the maximum number of times the processing defined in the scripts can be executed, and a function that, immediately following the execution of processing defined in the scripts, decrements the count of the rights to execute those scripts by one.
9. The method of loading an application program into a smart card according to
claim 1
, wherein a predetermined authentication procedure is carried out to assure that valid scripts, free of falsity, are stored when the scripts are stored into the storage means through the input/output interface after the application program is loaded.
10. The method of loading an application program into a smart card according to
claim 1
, wherein the scripts define a game and by the execution of a suit of scripts by using the smart card on which the script suit has been installed, the game defined in the script suit can be executed.
11. The method of loading an application program into a smart card according to
claim 1
, wherein the scripts define a game, points may be added, according to the result of executing the game, and the accumulated points are retained in the smart card.
12. The method of loading an application program into a smart card according to
claim 1
, wherein the scripts define a game, the game can be executed only if rights to play with the game are given to the card user, and the rights to play define what number of times a type of game can be executed and are stored into the smart card when the game is issued.
13. The method of loading an application program into a smart card according to
claim 11
, wherein data of the rights to play game may be stored separately from the scripts or the right(s) to play game may be included in the game scripts; in the latter case, the right(s) to play will be lost, following the execution of the game.
14. The method of loading an application program into a smart card according to
claim 11
, wherein the data of rights to play game includes the script issuer that offers the point service, the type of game playable, and the count of games that the user can play with that game.
15. The method of loading an application program into a smart card according to
claim 11
, wherein the point data is stored per script issuer that offers the point service.
16. A method of loading scripts into a smart card furnished with a storage means and an input/output interface, whereby the scripts are loaded as part of an application program from outside via the input/output interface into the smart card wherein the application program that can run under an operating system (OS) installed on the smart card and includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program is stored in the storage means.
17. A smart card furnished with a storage means and an input/output interface, holding an application program that can run under an operating system (OS) installed on the smart card, includes an interpreter for interpreting and executing scripts described to define the run procedure of the application program, and is loaded from outside via the input/output interface into the smart card.
US09/741,809 1999-12-27 2000-12-22 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program Expired - Lifetime US6681995B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US09/798,960 US6659345B2 (en) 1999-12-27 2001-03-06 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program
US10/674,401 US6834802B2 (en) 1999-12-27 2003-10-01 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP11-369142 1999-12-27
JP36914299A JP2001184472A (en) 1999-12-27 1999-12-27 Supply method for application program, smart card, script supply method, terminal device, and storage medium with application program

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/798,960 Continuation US6659345B2 (en) 1999-12-27 2001-03-06 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program

Publications (2)

Publication Number Publication Date
US20010006195A1 true US20010006195A1 (en) 2001-07-05
US6681995B2 US6681995B2 (en) 2004-01-27

Family

ID=18493675

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/741,809 Expired - Lifetime US6681995B2 (en) 1999-12-27 2000-12-22 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program
US09/798,960 Expired - Lifetime US6659345B2 (en) 1999-12-27 2001-03-06 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program
US10/674,401 Expired - Fee Related US6834802B2 (en) 1999-12-27 2003-10-01 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program

Family Applications After (2)

Application Number Title Priority Date Filing Date
US09/798,960 Expired - Lifetime US6659345B2 (en) 1999-12-27 2001-03-06 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program
US10/674,401 Expired - Fee Related US6834802B2 (en) 1999-12-27 2003-10-01 Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program

Country Status (3)

Country Link
US (3) US6681995B2 (en)
EP (1) EP1113407A3 (en)
JP (1) JP2001184472A (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6425522B1 (en) * 1998-07-23 2002-07-30 Hitachi, Ltd. IC card information processing system, and apparatus and cards for the same
US20030028699A1 (en) * 2001-08-02 2003-02-06 Michael Holtzman Removable computer with mass storage
US20040209690A1 (en) * 2000-04-07 2004-10-21 Igt Gaming machine communicating system
US20040249710A1 (en) * 2003-05-16 2004-12-09 David Smith Methods and apparatus for implementing loyalty programs using portable electronic data storage devices
US20050009600A1 (en) * 2002-04-02 2005-01-13 Igt Gaming environment including portable transaction devices
US20050124407A1 (en) * 2000-11-22 2005-06-09 Igt EZ pay smart card and ticket system
US20060094498A1 (en) * 2000-05-10 2006-05-04 Jorasch James A Gaming token having a variable value
US20070053529A1 (en) * 2005-09-05 2007-03-08 Yamaha Corporation Digital mixer
US20080188308A1 (en) * 2000-04-07 2008-08-07 Igt Virtually tracking un-carded or anonymous patron session data
US20100127767A1 (en) * 2008-11-27 2010-05-27 Eui Seung Kim Integrated Circuit Device Including Noise Filter
US7783040B2 (en) 2000-03-08 2010-08-24 Igt Encryption in a secure computerized gaming system
US20100285869A1 (en) * 2007-03-21 2010-11-11 Walker Jay S Gameplay-altering portable wagering media
US7837556B2 (en) 2001-09-28 2010-11-23 Igt Decoupling of the graphical presentation of a game from the presentation logic
US7931533B2 (en) 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
US8231455B2 (en) 2007-02-05 2012-07-31 Igt Method and apparatus for providing a bonus to a player
US8382582B2 (en) 2006-09-26 2013-02-26 Igt Systems and methods for portable wagering mediums
US8708828B2 (en) 2001-09-28 2014-04-29 Igt Pluggable modular gaming modifiers and configuration templates for gaming environments

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2384502B (en) * 1998-11-16 2004-10-13 Shell Oil Co Coupling an expandable tubular member to a preexisting structure
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US7409685B2 (en) 2002-04-12 2008-08-05 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
GB0106082D0 (en) * 2001-03-13 2001-05-02 Mat & Separations Tech Int Ltd Method and equipment for removing volatile compounds from air
JP4322440B2 (en) * 2001-04-23 2009-09-02 パイオニア株式会社 Point card management device and system
JP2003108898A (en) * 2001-09-28 2003-04-11 Sony Corp Ic card, ic card operating system, point issue device, clearing device, center device and claim device
JP2003168093A (en) * 2001-11-30 2003-06-13 Hitachi Ltd Card system, method for loading application on card and method for confirming application performance
US7240830B2 (en) * 2002-02-15 2007-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Layered SIM card and security function
US20030218064A1 (en) * 2002-03-12 2003-11-27 Storcard, Inc. Multi-purpose personal portable electronic system
JP4009131B2 (en) * 2002-04-23 2007-11-14 日本電信電話株式会社 IC card interoperability method and system by common tenant administrator
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8233893B2 (en) * 2002-08-22 2012-07-31 Hewlett-Packard Development Company, L.P. Mobile handset update package generator that employs nodes technique
US9852437B2 (en) * 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US20040148224A1 (en) * 2002-09-13 2004-07-29 Visa U.S.A. Method and apparatus for electronic support and delivery of multiple lottery and sweepstake programs, in substantially off-line environments
US7121456B2 (en) 2002-09-13 2006-10-17 Visa U.S.A. Inc. Method and system for managing token image replacement
US7611405B2 (en) 2002-10-15 2009-11-03 Igt Dynamic menu system
GB2395915A (en) 2002-12-05 2004-06-09 Revahertz Networks Inc A bingo-like game
US20050176491A1 (en) * 2002-12-05 2005-08-11 Kane Steven N. Game of chance and system and method for playing games of chance
US6986458B2 (en) * 2002-12-11 2006-01-17 Scheidt & Bachmann Gmbh Methods and systems for user media interoperability
JP4067985B2 (en) 2003-02-28 2008-03-26 松下電器産業株式会社 Application authentication system and device
US20060063575A1 (en) * 2003-03-10 2006-03-23 Cyberscan Technology, Inc. Dynamic theming of a gaming system
GB0305806D0 (en) * 2003-03-13 2003-04-16 Ecebs Ltd Smartcard based value transfer
JP4710215B2 (en) * 2003-03-24 2011-06-29 富士ゼロックス株式会社 Information management apparatus, information management method, and information management program
DE10318031A1 (en) * 2003-04-19 2004-11-04 Daimlerchrysler Ag Method to ensure the integrity and authenticity of Flashware for ECUs
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US7584466B1 (en) * 2003-06-16 2009-09-01 Hewlett-Packard Development Company, L.P. Management tree management in a mobile handset
WO2005003980A1 (en) * 2003-07-01 2005-01-13 T & D Corporation Multipurpose semiconductor integrated circuit device
US8043152B2 (en) 2003-07-03 2011-10-25 Igt Methods and system for providing paper-based outcomes
US7152782B2 (en) * 2003-07-11 2006-12-26 Visa International Service Association System and method for managing electronic data transfer applications
JP4597568B2 (en) * 2003-07-15 2010-12-15 パナソニック株式会社 Secure device, information processing terminal, and information processing system
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US7104446B2 (en) * 2003-09-03 2006-09-12 Visa U.S.A., Inc. Method, system and portable consumer device using wildcard values
US7510478B2 (en) 2003-09-11 2009-03-31 Igt Gaming apparatus software employing a script file
US7051923B2 (en) * 2003-09-12 2006-05-30 Visa U.S.A., Inc. Method and system for providing interactive cardholder rewards image replacement
US8555273B1 (en) 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US20050071226A1 (en) * 2003-09-30 2005-03-31 Visa U.S.A. Inc. Method and system for managing dynamic terms and conditions and user interaction
US7653602B2 (en) * 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
GB0330179D0 (en) * 2003-12-30 2004-02-04 Ecebs Ltd Improved smartcard system
US7761362B2 (en) * 2004-02-26 2010-07-20 Trading Technologies International Inc. System and method for changing the view of a trading screen
JP2005293109A (en) 2004-03-31 2005-10-20 Canon Inc Software execution management device, software execution management method, and control program
US8641496B2 (en) * 2004-04-16 2014-02-04 Scientific Games Holdings Limited System and method for conducting a game
US7904895B1 (en) 2004-04-21 2011-03-08 Hewlett-Packard Develpment Company, L.P. Firmware update in electronic devices employing update agent in a flash memory card
US20060242406A1 (en) 2005-04-22 2006-10-26 Microsoft Corporation Protected computing environment
US8109828B2 (en) 2004-05-07 2012-02-07 Scientific Games Holdings Limited System and method for playing a game having online and offline elements
US7819747B2 (en) * 2004-05-07 2010-10-26 Gamelogic Inc. Method and apparatus for conducting a game of chance
US8047917B2 (en) * 2004-05-07 2011-11-01 Scientific Games Holdings Limited Method and apparatus for conducting a game of chance
US20050250569A1 (en) * 2004-05-07 2005-11-10 Kane Steven N Method and apparatus for conducting a game of chance
US8047907B2 (en) * 2004-05-07 2011-11-01 Scientific Games Holdings Limited Method and apparatus for conducting a game of chance using pull-tab tickets
US8512134B2 (en) 2004-05-07 2013-08-20 Dow K. Hardy Method and apparatus for providing player incentives
US8025567B2 (en) 2004-05-07 2011-09-27 Gamelogic Inc. Method and apparatus for conducting a game of chance
US7815502B2 (en) * 2004-05-07 2010-10-19 Gamelogic Inc. Method and apparatus for conducting a game of chance
US8425297B2 (en) * 2004-05-07 2013-04-23 Scientific Games Holdings Limited Method and apparatus for conducting a game of chance including a ticket
US7959502B2 (en) * 2004-05-07 2011-06-14 Gamelogic Inc. Method of playing a game of chance including a computer-based game
US8038529B2 (en) 2004-05-07 2011-10-18 Gamelogic, Inc. Method and apparatus for conducting a game of chance
US7771264B2 (en) * 2004-05-07 2010-08-10 Gamelogic Inc. Method and apparatus for conducting a wagering game of chance including a prize wheel game
US8727867B2 (en) * 2004-05-07 2014-05-20 Scientific Games Holdings Limited Method and apparatus for conducting a first and second level game and a game of chance
US8845409B2 (en) * 2004-05-07 2014-09-30 Scientific Games Holdings Limited Method and apparatus for reinvesting winnings
US7976374B2 (en) 2004-05-07 2011-07-12 Gamelogic, Inc. Method and apparatus for conducting a game of chance
US8029361B2 (en) * 2004-05-07 2011-10-04 Gamelogic Inc. Method and apparatus for providing player incentives
US8100759B2 (en) 2004-05-07 2012-01-24 Scientific Games Holdings Limited Method and apparatus for providing player incentives
US8512133B2 (en) * 2004-05-07 2013-08-20 Scientific Games Holdings Limited Method and apparatus for providing player incentives
US20060025197A1 (en) * 2004-05-07 2006-02-02 Gamelogic, Inc. Method and apparatus for conducting a game of chance
US20070257430A1 (en) * 2004-05-07 2007-11-08 Dow Hardy Method and apparatus for conducting a game of chance
US7666082B2 (en) * 2004-05-07 2010-02-23 Gamelogic Inc. Method and apparatus for conducting a game of chance
US20060082056A1 (en) * 2004-05-07 2006-04-20 Kane Steven N Method and apparatus for conducting a game tournament
US8425300B2 (en) 2004-05-07 2013-04-23 Scientific Games Holdings Limited Method and apparatus of conducting a game of chance including bingo
US7766739B2 (en) * 2004-05-07 2010-08-03 Gamelogic, Inc. Method and apparatus for conducting a game of chance
US9129476B2 (en) 2004-05-07 2015-09-08 Scientific Games Holdings Limited Method and apparatus for providing player incentives
US7357715B2 (en) * 2004-08-03 2008-04-15 Gamelogic, Inc. System and method for playing a role-playing game
KR20060014600A (en) * 2004-08-11 2006-02-16 삼성전자주식회사 Apparatus and methods for checking the change of data stored in the external storage
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
AU2005222507B2 (en) * 2004-10-15 2010-10-28 Microsoft Corporation Portable computing environment
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US8464348B2 (en) 2004-11-15 2013-06-11 Microsoft Corporation Isolated computing environment anchored into CPU and motherboard
US8176564B2 (en) 2004-11-15 2012-05-08 Microsoft Corporation Special PC mode entered upon detection of undesired state
US20060167752A1 (en) * 2004-12-29 2006-07-27 Pozesky Brian A Automated segmentation and yield management
WO2006081267A2 (en) * 2005-01-25 2006-08-03 Gamelogic Inc. Method and apparatus for redeeming keno tickets
JP4612435B2 (en) * 2005-02-25 2011-01-12 日本電信電話株式会社 Acoustic model learning device and speech recognition device
US8360858B2 (en) * 2005-03-11 2013-01-29 Scientific Games Holdings Limited System and method for rewarding game players
US7549922B2 (en) * 2005-03-17 2009-06-23 Atronic International Gmbh Software security for gaming devices
US20060211490A1 (en) * 2005-03-17 2006-09-21 Falvey Grahame M Security for gaming devices
JP2006262393A (en) * 2005-03-18 2006-09-28 Ntt Docomo Inc Tamper-resistant device and file generating method
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
JP2006277178A (en) * 2005-03-29 2006-10-12 Aruze Corp Game card
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US8353046B2 (en) 2005-06-08 2013-01-08 Microsoft Corporation System and method for delivery of a modular operating system
US8484632B2 (en) * 2005-12-22 2013-07-09 Sandisk Technologies Inc. System for program code execution with memory storage controller participation
US8479186B2 (en) * 2005-12-22 2013-07-02 Sandisk Technologies Inc. Method for program code execution with memory storage controller participation
US8118667B2 (en) * 2006-02-08 2012-02-21 Scientific Games Holdings Limited Multiplayer gaming incentive
AU2007212246B2 (en) * 2006-02-08 2012-04-12 Scientific Games, Llc Method and system for remote entry in frequent player programs
FR2897705A1 (en) * 2006-02-22 2007-08-24 Proton World Internatinal Nv Electronic circuit`s e.g. integrated circuit, data updating method for e.g. bank card, involves sending execution control of updating program of prechraged programs in memory to circuit, where control has identification elements of program
CN101472651B (en) * 2006-04-25 2012-05-30 盖姆劳吉克公司 Method for conducting a game of chance
EP2025095A2 (en) 2006-06-08 2009-02-18 Hewlett-Packard Development Company, L.P. Device management in a network
US8752044B2 (en) 2006-07-27 2014-06-10 Qualcomm Incorporated User experience and dependency management in a mobile device
WO2008016960A2 (en) * 2006-08-01 2008-02-07 Gamelogic, Inc. Method for playing multi-level games of chance
EP2084681A4 (en) 2006-11-14 2011-01-26 Mudalla Technology Inc Dynamic gaming library
US8011593B2 (en) * 2007-03-15 2011-09-06 Joseph Frank Preta Smart apparatus for making secure transactions
US7689665B2 (en) * 2007-04-27 2010-03-30 Microsoft Corporation Dynamically loading scripts
EP2243109A4 (en) * 2007-12-26 2012-01-18 Gamelogic Inc System and method for collecting and using player information
US8219595B2 (en) 2008-02-14 2012-07-10 Hewlett-Packard Development Company, L.P. System and method for efficient remote data access for server management
JPWO2009133727A1 (en) 2008-04-30 2011-08-25 日本電気株式会社 Terminal, web application operating method and program
US20100011632A1 (en) * 2008-07-17 2010-01-21 Hallmark Cards, Incorporated Greeting card having connectivity capabilities
AU2009230767A1 (en) * 2008-11-03 2010-05-20 Aristocrat Technologies Australia Pty Limited A method and gaming device for controlling use of one of more peripheral devices
WO2010068905A1 (en) * 2008-12-12 2010-06-17 Herrmann Mark E Method and apparatus for off property prize pooling
JP5368147B2 (en) 2009-04-02 2013-12-18 フェリカネットワークス株式会社 Communication device, information processing device, program, and reader / writer providing system
US20110145082A1 (en) * 2009-12-16 2011-06-16 Ayman Hammad Merchant alerts incorporating receipt data
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
JP5635305B2 (en) 2010-05-26 2014-12-03 任天堂株式会社 Portable information processing apparatus, information processing program, and information processing method
US8781119B2 (en) * 2010-12-14 2014-07-15 Nxp, B.V. User-controlled Random-ID generation function for smartcards
US9092608B2 (en) 2010-12-14 2015-07-28 Nxp B.V. Random-ID function for smartcards
JP5704951B2 (en) 2011-02-10 2015-04-22 ソニー株式会社 Information processing apparatus, information processing method, and computer program
US8990572B2 (en) * 2012-04-24 2015-03-24 Daon Holdings Limited Methods and systems for conducting smart card transactions
JP5814889B2 (en) * 2012-08-27 2015-11-17 株式会社コナミデジタルエンタテインメント GAME SELECTION CONTROL METHOD, GAME SOFTWARE DISTRIBUTION CONTROL METHOD, AND GAME SOFTWARE DISTRIBUTION SERVER
JP2017221327A (en) * 2016-06-14 2017-12-21 株式会社レベルファイブ Program, recording medium, and communication device
JP2018020029A (en) * 2016-08-06 2018-02-08 株式会社オリンピア Game machine

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2657445B1 (en) * 1990-01-25 1992-04-10 Gemplus Card Int METHOD FOR LOADING APPLICATION PROGRAMS INTO A MICROPROCESSOR MEMORY CARD READER AND SYSTEM FOR ITS IMPLEMENTATION.
DE4242893A1 (en) * 1992-12-18 1994-07-07 Friedrich Blanke Magnetic data card operated games machine
US5404528A (en) * 1993-01-19 1995-04-04 Canon Information Systems, Inc. Scripting system
US5871398A (en) * 1995-06-30 1999-02-16 Walker Asset Management Limited Partnership Off-line remote system for lotteries and games of skill
DE19536169A1 (en) * 1995-09-29 1997-04-03 Ibm Multifunctional chip card
GB9613450D0 (en) * 1996-06-27 1996-08-28 Europay Int Sa Payment system
US5923884A (en) * 1996-08-30 1999-07-13 Gemplus S.C.A. System and method for loading applications onto a smart card
US5953524A (en) * 1996-11-22 1999-09-14 Sybase, Inc. Development system with methods for runtime binding of user-defined classes
US6317832B1 (en) * 1997-02-21 2001-11-13 Mondex International Limited Secure multiple application card system and process
JPH10307216A (en) 1997-03-03 1998-11-17 Amp Japan Ltd Optical fiber cable excessive-length storage case, case storage body, and storage case assembly
CA2288824A1 (en) * 1997-03-24 1998-10-01 Marc B. Kekicheff A system and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6298370B1 (en) * 1997-04-04 2001-10-02 Texas Instruments Incorporated Computer operating process allocating tasks between first and second processors at run time based upon current processor load
US6092147A (en) * 1997-04-15 2000-07-18 Sun Microsystems, Inc. Virtual machine with securely distributed bytecode verification
FR2766949B1 (en) * 1997-07-31 2001-10-05 Gemplus Card Int SECURE MACHINE SYSTEM
US6147767A (en) * 1997-09-05 2000-11-14 Comtec Informations Systems, Inc. Computer system for a printer which stores and operates multiple application programs
US6480959B1 (en) * 1997-12-05 2002-11-12 Jamama, Llc Software system and associated methods for controlling the use of computer programs
AU2436999A (en) * 1998-03-09 1999-09-27 Schlumberger Systemes Ic card system for a game machine
US6250557B1 (en) * 1998-08-25 2001-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for a smart card wallet and uses thereof
TW460847B (en) * 1998-08-26 2001-10-21 Hitachi Ltd IC card, terminal apparatus and service management server
US6390374B1 (en) * 1999-01-15 2002-05-21 Todd Carper System and method for installing/de-installing an application on a smart card
US6256690B1 (en) * 1999-01-15 2001-07-03 Todd Carper System and method for facilitating multiple applications on a smart card
US6402028B1 (en) * 1999-04-06 2002-06-11 Visa International Service Association Integrated production of smart cards

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6425522B1 (en) * 1998-07-23 2002-07-30 Hitachi, Ltd. IC card information processing system, and apparatus and cards for the same
US7783040B2 (en) 2000-03-08 2010-08-24 Igt Encryption in a secure computerized gaming system
US20040209690A1 (en) * 2000-04-07 2004-10-21 Igt Gaming machine communicating system
US7883417B2 (en) 2000-04-07 2011-02-08 Igt Gaming machine communicating system
US8876608B2 (en) 2000-04-07 2014-11-04 Igt Virtually tracking un-carded or anonymous patron session data
US20080188308A1 (en) * 2000-04-07 2008-08-07 Igt Virtually tracking un-carded or anonymous patron session data
US8029357B2 (en) 2000-05-10 2011-10-04 Igt Gaming token having a variable value
US20060094498A1 (en) * 2000-05-10 2006-05-04 Jorasch James A Gaming token having a variable value
US20070293309A1 (en) * 2000-05-10 2007-12-20 Jorasch James A Gaming token having a variable value
US8696444B2 (en) * 2000-05-10 2014-04-15 Igt Gaming token having a variable value
US20050124407A1 (en) * 2000-11-22 2005-06-09 Igt EZ pay smart card and ticket system
US7418344B2 (en) * 2001-08-02 2008-08-26 Sandisk Corporation Removable computer with mass storage
US20080288700A1 (en) * 2001-08-02 2008-11-20 Michael Holtzman Removable computer with mass storage
US20030028699A1 (en) * 2001-08-02 2003-02-06 Michael Holtzman Removable computer with mass storage
US8176335B2 (en) 2001-08-02 2012-05-08 Sandisk Technologies Inc. Removable computer with mass storage
US8708828B2 (en) 2001-09-28 2014-04-29 Igt Pluggable modular gaming modifiers and configuration templates for gaming environments
US8251807B2 (en) 2001-09-28 2012-08-28 Igt Game development architecture that decouples the game logic from the graphics logic
US7837556B2 (en) 2001-09-28 2010-11-23 Igt Decoupling of the graphical presentation of a game from the presentation logic
US7931533B2 (en) 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
US7988554B2 (en) 2001-09-28 2011-08-02 Igt Game development architecture that decouples the game logic from the graphics logic
US20050009600A1 (en) * 2002-04-02 2005-01-13 Igt Gaming environment including portable transaction devices
US20040249710A1 (en) * 2003-05-16 2004-12-09 David Smith Methods and apparatus for implementing loyalty programs using portable electronic data storage devices
US7865737B2 (en) * 2005-09-05 2011-01-04 Yamaha Corporation Digital mixer
US20070053529A1 (en) * 2005-09-05 2007-03-08 Yamaha Corporation Digital mixer
US8382582B2 (en) 2006-09-26 2013-02-26 Igt Systems and methods for portable wagering mediums
US8597115B2 (en) 2006-09-26 2013-12-03 Igt Systems and methods for portable wagering mediums
US8231455B2 (en) 2007-02-05 2012-07-31 Igt Method and apparatus for providing a bonus to a player
US8562424B2 (en) 2007-03-21 2013-10-22 Igt Gameplay-altering portable wagering media
US20100285869A1 (en) * 2007-03-21 2010-11-11 Walker Jay S Gameplay-altering portable wagering media
US9098975B2 (en) 2007-03-21 2015-08-04 Igt Gameplay-altering portable wagering media
US9196121B2 (en) 2007-03-21 2015-11-24 Igt Gameplay-altering portable wagering media
US9424713B2 (en) 2007-03-21 2016-08-23 Igt Gameplay-altering portable wagering media
US9734667B2 (en) 2007-03-21 2017-08-15 Igt Gameplay-altering portable wagering media
US20100127767A1 (en) * 2008-11-27 2010-05-27 Eui Seung Kim Integrated Circuit Device Including Noise Filter

Also Published As

Publication number Publication date
US6834802B2 (en) 2004-12-28
US20040060979A1 (en) 2004-04-01
US6681995B2 (en) 2004-01-27
US20020125328A1 (en) 2002-09-12
EP1113407A2 (en) 2001-07-04
US6659345B2 (en) 2003-12-09
EP1113407A3 (en) 2001-09-26
JP2001184472A (en) 2001-07-06

Similar Documents

Publication Publication Date Title
US6659345B2 (en) Method of loading an application program into a smart card, smart card, method of loading scripts into a smart card, terminal device capable of operating with a smart card, and storage medium holding an application program
TW460847B (en) IC card, terminal apparatus and service management server
US6901375B2 (en) Methods and apparatus for electronically storing and retrieving value information on a portable card
US5179517A (en) Game machine data transfer system utilizing portable data units
CA2281576C (en) Multi-application ic card system
EP0949595A2 (en) Method and system for managing applications for a multi-function smartcard
US20010037450A1 (en) System and method for process protection
EP0878784B1 (en) Electronic money card, electronic money receiving/paying machine, and electronic money card editing device
JP2002512715A (en) Secure multi-application card system and process
CN107077383A (en) System and method for determining partition identifier in multi-tenant application server environment
US20020112236A1 (en) Smart card, method for loyalty program using smart card, and smart card system
Chiu et al. Incentive compatibility on the blockchain
US11798359B2 (en) Blockchain-based smart contract instant lottery ticket
US20020069169A1 (en) Data processing method of smart card system
US7562050B2 (en) Aging of electronic payment units
US7350695B2 (en) Method, system, and computer program product for implementing pin-based data transfer activities
JPH1131190A (en) Electronic money card, electronic money reception/ payment machine and electronic money card editing device
JP2004086890A (en) Supply method for application program, smart card, script supply method, terminal device, and storage medium with application program
Hellwig et al. Smart contracts
da Costa Padrões de Desenho para Contratos Inteligentes em Ethereum
KR101013162B1 (en) System for Relaying Application and Service Code for Card with ICC and MS
KR101124262B1 (en) Method for Creating and Relaying Application and Service Code for Card with ICC and MS
JP2004030239A (en) Control system for application addition
JPH05298499A (en) Authenticating system
Jang Secure Object Sharing on Java Card

Legal Events

Date Code Title Description
AS Assignment

Owner name: HITACHI, LTD., JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SUKEDA, HIROKO;MISHINA, YUSUKE;OHKI, MASARU;REEL/FRAME:011421/0526;SIGNING DATES FROM 20001214 TO 20001218

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12