U.S. Pat. No. 8,038,536

BEST MODE FOR CARRYING OUT THE INVENTION

Configuration:

FIG. 1is a block diagram showing a communication system comprising a game system according to an embodiment of the present invention. The communication system has a large number of game devices1, a large number of cards2, a game server device3connected to the Internet5, and a large number of portable terminals4.

Game device1is a terminal that enables a player to play a predetermined game by paying a charge. Game device1is connected to the Internet5and is capable of performing data communication with game server device3. One or more game devices1are installed at a shop or a venue where visitors are able to use game devices1. A player plays a predetermined game at a shop using game device1to thereby gain a game result. A game result is an evaluation of one or a plurality of game plays and is, for example, a score or a level.

Card2is a portable information recording medium that magnetically records information, and it records a card ID (recording medium identifier) identifying the card itself. Though described later in detail, the card ID is read by game device1and is used at game server device3. A player can own one or more cards2and select one of that player's own cards2for use in a play of a predetermined game.

Portable terminal4is an example of a terminal device. Portable terminal4is a computer that notifies its user of a game result of a player, and the terminal4functions as a portable telephone capable of using, via base stations (BS)61, a mobile communication network6which provides data communication and telephone communication services. Base stations61are dispersed so as to cover a service area of mobile communication network6in cooperation with one another, and each base station61is capable of wirelessly communicating with portable terminal4within an area which each base station61covers. Mobile communication network6is connected to the Internet5through a gateway7and is capable of providing a mobile internet access service. The “mobile internet access service” is a service that enables interactive communication between a mobile communication terminal such as a portable telephone service and a website on the Internet. According to this service, a mobile communication terminal is able to display characters and images provided from the site on its display and also to download an application program from the site. Examples of mobile internet access services include, for example, an “i-mode®” service developed by NTT DoCoMo Inc., Tokyo, Japan, and a service in accordance with a “WAP (Wireless Application Protocol)” developed by the WAP Forum. Gateway7converts a communication protocol of mobile communication network6into that of the Internet5, and vice versa. Specifically, gateway7is, for example, an i-mode server in the i-mode service or a WAP proxy (WAP gateway) in the WAP service. Each portable terminal4is capable of performing data communication with game server device3via mobile communication network6and the Internet5. It should be noted that in the present embodiment, portable terminal4that also functions as a portable telephone is used as a terminal device, but the terminal device is not limited thereto. A portable or a fixed computer can also be used as a terminal device.

Game server device3is a computer that retains game results in association with card IDs. Game server device3may be comprised of one computer or of a plurality of network-connected computers. Game server device3is capable of performing data communication with a correspondent device via the Internet5.

FIG. 2is a perspective view showing an external view of game device1comprised in the communication system ofFIG. 2, andFIG. 3is a block diagram showing a configuration of game device1. As shown in these figures, game device1has a processor11, a coin hopper12, a card reading device (reader)13, an input device (inputter)14, a display device (display)15, a speaker16, and a communication interface17, and a storage unit18.

Coin hopper12distinguishes coins inserted from a coin acceptance slot121formed on a body of game server device3, and the hopper accepts a coin if the coin is of a predetermined type and supplies a coin acceptance signal to processor11. The predetermined type of coin is something which has a value corresponding to a game play charge with one or more pieces and is, for example, hard currency (hard money).

There is formed in card reading device13a card acceptance slot131for inserting a card2. Card reading device13, when card2is inserted from card acceptance slot131, reads a card ID from card2to supply a signal indicating the card ID to processor11.

Input device14has a plurality of operators and, when an operator is operated, supplies processor11with a signal that is unique to the operator.

Display device15has a display area151and displays a game screen in display area151after receiving an image data from processor11.

Speaker16outputs sounds after receiving music sound signals from processor11.

Communication interface17is connected to the Internet5directly or via a relay device such as a router and relays data between processor11and the Internet5.

Storage unit18has a nonvolatile memory such as a ROM (Read Only Memory) and has a rewritable memory such as a RAM (Random Access Memory).

In the rewritable memory, there are held a current score area181, a personal result area182, a top player score area183, and a competitor result area184. Current score area181is a memory area for storing the score of a game a player is currently playing. Personal result area182is a memory area for past game results of a player currently playing a game. Top player score area183is a memory area for storing the highest score among past game results of all players who have played a game in the game system ofFIG. 1. Competitor result area184is a memory area for storing game results of competitor players of the currently playing player in association with the names of the competitor players. An competitor of the current player is another player specified by the current player in advance.

There has been written in the nonvolatile memory a game program185. Processor11executes game program185, so as to thereby function as a game executor that causes a player to play a predetermined game.

Description will now be given of the details of a predetermined game to facilitate understanding of specific functions of the game executor.

In the predetermined game, one of two play modes can be selected. One of the play modes is a single-player mode in which a single player plays a game using a single game device1, and the other mode is a two-player mode in which two players play a game simultaneously using a single game device1. To enable the two-player mode, input device14has a start button1411and a set of play operators1421for the first player and also has a start button1412and a set of play operators1422for the second player. The set of play operators is a group of operators operated during a play of the predetermined game, and each set of play operators includes one control wheel and seven buttons.

Furthermore, in the predetermined game, one of the two operation modes can be selected. One of the operation modes is a single mode in which play operators1421only are used, and the other operation mode is a double mode in which play operators1421and1422for the first and second players are used. In the single-player mode, only the single mode is selectable.

FIG. 4is a diagram showing an example of a game screen displayed in display area151of game device1.

This screen shows a case in which the predetermined game is played using game device1in the single-player mode and the single mode without using card2. A game area R1is reserved in a left portion of the game screen, and a game area R2is reserved in a right portion. In the game area R1, objects OB appear in an upper portion of the figure, fall along one of eight columns, and disappear in a lower portion of the figure to the music selected in advance. There exists, slightly above a point at which objects OB disappear, a horizontal line HL orthogonal to a falling direction of objects OB. Below the horizontal line HL, eight images indicating play operators included in play operators1421are positioned, the eight images corresponding to the eight columns. According a rule of the game, a player should operate an operator (one of the play operators1421) at a time in which an object OB overlaps with the horizontal line HL, the operator corresponding to the column to which the object OB belongs.

In the lower portion of the game screen, there are shown images indicating the player's score, bonus points, and a level meter LM. The score is increased if, when an object OB overlaps with the horizontal line HL, an operation corresponding to the object OB is performed. The bonus points are added in a case in which the difference between the timing of the operation and the ideal timing of the operation is equal to or smaller than a predetermined range; and the bonus points are initialized to 0 once the difference exceeds the range. After the music ends, the bonus points are multiplied with a predetermined coefficient, and the product is added to the score. The level meter LM shows by length a skill level of a player computed in the game. In a case in which the skill level has reached a predetermined level at the end of music, it is determined that a stage has been cleared. A stage refers to a game period corresponding to one piece of music, and in one stage, a music piece for this stage is reproduced and the music sounds are output from speaker16. One game includes one or a plurality of (a series of) stages. The number of stages comprised in one game varies depending on a selected game mode. One game is terminated when a player fails to clear a stage or when the player succeeds in clearing a game (i.e., in clearing the last stage).

Game modes include a one-piece-of-music mode (single-tune mode), an expert mode, a weekly ranking mode, and a level-certificate mode (level-recognition mode). In the one-piece-of-music mode, any one music piece can be selected for play from among a plurality of music pieces. The number of stages of a game in the one-piece-of-music mode, therefore, is one. In the expert mode, any course can be selected from among a plurality of courses. Each course has five stages, and the composition of stages varies depending on a course. The weekly ranking mode is a mode of playing a game in which a player can compete in scores in an ongoing weekly ranking. A game performed in the weekly ranking mode differs from the one-piece-of-music mode only in that a music piece is specified. In the level-certificate mode, a game level is set to a level of difficulty corresponding to a selected level. It is determined that a player has passed a certificate test for a target level if the game is cleared, and the player can then receive the certificate of the level.

No information relating to a play is displayed in game area R2except that card2is used in the game, as will be described below in detail. In addition, when a double mode is selected, objects OB appear in both game areas R1and R2, so that the objects OB fall along the total of 16 columns. In this case, eight images are positioned, below the line of game area R2, so as to correspond to eight columns of game area R2, the eight images indicating play operators included in play operators1422. In other words, a player can operate not only play operators1421but also play operators1422. Furthermore, in a case in which the two-player mode is selected, objects OB for the first player are displayed in game area R1, and objects OB for the second player are displayed in game area R2. In this case, images showing scores, bonus points, and a level meter are displayed in a lower portion of game area R2.

Processor11executes game program185, so as to thereby function as a means for performing a comparison process described below.

FIG. 5is a block diagram showing a configuration of game server device3comprised in the communication system. Game device1has a processor31, a communication interface32, and a storage unit33. Communication interface32is connected to the Internet5directly or via a relay device such as a router and relays data between processor31and the Internet5. Storage unit33has a ROM in which an IPL (Initial Program Loader) is written, has a RAM used as a work area and has a hard disk. There are stored on the hard disk an individual information table T1, an association table T2, a competitor specifying table T3, a single-piece-of-music table T4, an expert table T5, a weekly ranking table T6, a schedule table T7, and a level table T8.

FIG. 6is a diagram showing the details of individual information table T1. The table is for associating private player identifiers, individual information, and public player identifiers, and each private player identifier has a record. A private player identifier identifies each one of a plurality of players. Individual information includes name information indicating the name of a player, and district information indicating the location of the player, and scores (points) of the player. A public player identifier is information for identifying each of a plurality of players. A private player identifier is information that must not be made open to the general public (excluding an operator of the game system), whereas a public player identifier is information that can be made open to the general public.

FIG. 7is a diagram showing details of an association table T2in game server device3. This table is for associating multiple card IDs with a single private player identifier, and each card ID has a record. The table is used for converting a card ID into a private player identifier. This conversion is performed so that no updating of other tables is required for a new card2in a case in which an old card2is not functional due to it being damaged or deteriorated. The conversion is also performed so as to cope with a case in which one player owns more than one card2for use at game device1, in preparation for the case of card2being disabled.

FIG. 8is a diagram showing details of competitor specifying table T3of game server device3. This table is for associating a player and an competitor of the player, and a record is generated for each competitor relationship. In each record, a private player identifier is that of a player who has specified a competitor player, whereas a competitor private player identifier is a private player identifier of a competitor player who has been specified as a competitor by the player. In a case in which no player has specified a competitor, the number of records is 0.

FIG. 9is a diagram showing details of single-piece-of-music table T4of game server device3. This table stores scores of games performed in the one-piece-of-music mode, each score being stored in association with a private player identifier of a player and a music number. There are stored in each record a private player identifier, a music number, a single-mode score, a double-mode score, a clear flag, a date of last update, and the number of plays. In each record, the music number is an identifier for identifying one of a plurality of music pieces, and the single-mode score is information indicating a score obtained when a player having a corresponding private player identifier plays a game of a music piece identified by the music number. The double-mode score is information indicating a score obtained when the player plays the game in the double mode, the clear flag is information whether the player has ever cleared the game in playing the game, the date of last update is a date on which this record is last updated, and the number of plays is information indicating the number of times which the player has played this game.

FIG. 10is a diagram showing details of the expert table T5of game server device3. This table stores scores of games played in the expert mode, each score being stored in association with a set of a private player identifier, a course ID, and a mode ID. Each record stores a private player identifier, a course ID, a mode ID, a score, a clear flag, a date of last update, and the number of plays. The course ID is an identifier for identifying each of courses (i.e., the composition of stages) of the expert mode. Furthermore, the mode ID is an identifier for distinguishing the single mode or the double mode. In each record, the score is information indicating a score obtained when a player having a corresponding private player identifier plays a game under a course of the corresponding course ID in a mode of the corresponding mode ID, the clear flag is information whether the player has ever cleared the game in playing the game in the mode of the corresponding mode ID, the date of last update is a date on which this record is last updated, and the number of plays is information indicating the number of times which the player has played this game in the mode of the corresponding mode ID.

FIG. 11is a diagram showing details of weekly ranking table T6of game server device3. This table stores scores of games of the weekly ranking mode, each score being associated with a set of a private player identifier, a week identifier, and a mode ID. Each record of this table differs from that of expert table T5in that a week ID (described below) is stored instead of the course ID.

FIG. 12is a diagram showing details of schedule table T7of game server device3. This table has a record indicating a ranking schedule for each weekly ranking. There are stored in each record a week ID, a music number, a start date, and an end date. In each record, the week ID indicates a week in which the weekly ranking is held, the music number indicates a music piece specified in the weekly ranking, the start date indicates the start date of the week, and the end date indicates the end date of the week. It should be noted that a period from the start date to the end date (a week) does not necessarily correspond to a calendar week.

FIG. 13is a diagram showing details of level table T8of game server device3. In this table, a game result of the level-certificate mode is stored in association with a private player identifier of a player and a level ID. The level IDs are identifiers for identifying each of a plurality of levels. In each record of level table T8, the level ID indicates a level that a player having a corresponding private player identifier pursues to receive a certificate, and a pass or fail flag indicates whether the player has passed a certificate test of the level.

On the hard disk, there has been written a management program331that guides a view response process, a competitor registration response process, and a competitor candidate response process (described below). Processor31reads the IPL from ROM for execution, to thereby perform a process of reading management program331from the hard disk for execution. There is stored on the hard disk a control program that is executable at portable terminal4, and processor31, when it receives from portable terminal4a request for downloading the control program, identifies a private player identifier of a player that is using this portable terminal4to deliver the identified private player identifier and the control program to the requesting portable terminal4. Examples of control programs that can be downloaded by the mobile internet access service and that can be executed by a portable terminal of this type are as follows: i-appli® for i-mode compatible portable terminals, an application program operable at a portable terminal in accordance with BREW® (Binary Runtime Environment for Wireless) developed by Qualcomm Incorporated, San Diego, Calif., USA, and an application program operable at a portable terminal in accordance with MIDP (Mobile Information Device Profile) for J2ME® CLDC (Java® 2 Micro Edition Connected Limited Device Configuration).

FIG. 14is a diagram showing an external view of portable terminal4comprised in the communication system, andFIG. 15is a block diagram showing a configuration of portable terminal4. As shown in these figures, portable terminal4has a processor41, a microphone42, a speaker43, an input device (inputter)44, a display device (display)45, a wireless communication interface46, and a storage unit47.

Microphone42is used for voice communication, and it collects voice sounds of a user and supplies the collected sounds to processor41.

Speaker43is used for voice communication, and it outputs sounds after receiving voice sound signals from processor41.

Input device44has a plurality of buttons operated by a user, and when a button is pressed down, it supplies a signal unique to the pressed button to processor41. The plurality of buttons includes a button used for inputting data and a button used for inputting instructions.

Display device45has a display area451, and it displays a game screen in display area451after receiving image data from processor41.

Wireless communication interface46has an antenna461, and it relays data between processor41and base stations61. Communication paths between wireless communication interface46and base stations61are wireless communication paths.

Storage unit47has a RAM, ROM, and EEPROM (Electrically Erasable Programmable ROM). There is stored in ROM an operating system of portable terminal4, and the operating system is executed when portable terminal4is started. This operating system is for providing portable terminal4with a telephone communication function and a data communication function, a function of downloading other programs, and a function of executing a downloaded program. There are reserved in EEPROM a program area471for storing downloaded programs and a data area472corresponding to the program area471. A program stored in program area471is only allowed to access data area472. In a case in which a control program for guiding a later-described competitor monitoring process is stored in program area471, data area472includes a personal ID area4721, a personal result area4722, and a competitor area4723.

Operations:

In the following, description will be given of operations of the communication system having the above configuration. In this example, it is assumed that the above control program has already been written in program area471of portable terminal4. Also, in personal ID area4721of portable terminal4, a private player identifier (a private player identifier of a player who uses the control program) has been written, where the private player identifier is delivered from game server device3at the time of downloading the control program. Furthermore, it is assumed that a card ID of card2used in game device1has already been registered in association table T2.

FIG. 16is a flow chart of a competitor monitoring process performed by processor41of portable terminal4. In the competitor monitoring process, processor41first determines whether a competitor is specified (Step SA1). This determination is performed by checking whether a private player identifier is stored in competitor area4723. In a case in which the determination result changes to “YES”, processor41generates a view request containing a private player identifier stored in personal ID area4721as a private player identifier of a requesting player and also containing a private player identifier stored in competitor area4723as a private player identifier of a competitor player (Step SA2). The view request is data that instructs that information showing a game result be transmitted as a reply. In a case in which the determination result changes to “NO”, processor41generates a view request containing a private player identifier stored in personal ID area4721as a private player identifier of a requesting player and not containing a private player identifier of a competitor player (Step SA3). Processor41then transmits the generated view request to game server device3(Step SA4).

FIG. 17is a flow chart showing a view response process performed by processor31of game server device3. Processor31, when it receives a view request from portable terminal4, determines whether the view request contains a private player identifier of a competitor player (Step SB1). In a case in which the determination result changes to “YES”, processor41generates a view response using a private player identifier of a requesting player and that of a competitor player contained in the view request (Step SB2).

Specifically, for the private player identifier of the requesting player, a search is performed in tables T1, T4to T6, and T8for the private player identifier. All the data (a game result of the requesting player) stored in a hit record is then retrieved. For the private player identifier of the competitor player, a search is performed in tables T1, T5, T6, and T8for the private player identifier. In this search, however, a range of the search performed in weekly ranking table T6is limited to records corresponding to an ongoing weekly ranking. From among records hit in the search, the search is refined for records hit in level table T8so that only records indicating a pass to the highest level will remain. All the data (a game result of the competitor player) stored in a thus obtained record is then retrieved. A view response containing the retrieved game results is then generated.

On the other hand, in a case in which a result of the determination of Step SB1changes to “NO”, processor41generates a view response using a private player identifier of a requesting player contained in the view request (Step SB3). Specifically, for the private player identifier of the requesting player, a search is performed in tables T1, T4to T6, and T8for the private player identifier, and all the data (a game result of the requesting player) stored in a hit record is retrieved. A view response is then generated so as to contain the retrieved game result.

Processor31subsequently replies to portable terminal4with the generated view response (Step SB4).

Processor41of portable terminal4, upon receiving a view response from game server device3(Step SA5ofFIG. 16), stores the game result contained in the view response (Step SA6). Specifically, a game result of a requesting player contained in the view response is written in personal result area4722. If there is a personal game result that has been written in personal result area4722prior to the writing of the game result contained in the view response, processor41performs a process of retaining only the last written personal game result as a previous personal game result. In a case in which the received view response contains a game result of a competitor player, processor41writes this game result in competitor area4723in association with a private player identifier of the competitor player. In a case in which, prior to this writing operation, a competitor game result has written in competitor area4723, processor41performs a process of retaining only the last written competitor game result as the previous competitor game result.

Subsequently, processor41determines whether the requesting player has been overtaken by the competitor (Step SA7). Specifically, it is determined, in each of the expert mode, weekly ranking mode, and level-certificate mode, whether a score or a level contained in the previous personal game result exceeds a score or a level contained in the previous competitor game result and whether a score or a level contained in the personal game result of this time falls below a score or a level contained in the competitor game result of this time. It is to be noted that the present embodiment can be modified so that scores are used as an element of this determination. In a case in which a result of the determination changes to “YES” for at least one of the modes, a result of the determination of Step SA7changes to “YES”.

In a case in which the result of the determination of Step SA7is “YES”, processor41displays on display device45a warning screen G1notifying that the requesting player has been overtaken by the competitor (Step SA8).FIG. 18is a diagram for describing various screen displayed on portable terminal4, in which an example of the warning screen G1is shown. The warning screen G1shown in this figure stays on the display until an “OK” button on the screen is clicked on by the player (Step SA9: NO). When the player operates input device44to input an instruction of selecting the “OK” button (Step SA9: YES), processor41performs a menu process (Step SA10).

In the menu process, processor41first displays a menu screen G2and waits for the player's instruction. An example of menu screen G2is shown inFIG. 18. The menu screen G2shown in this figure has three buttons. The first button is an “input and register” button for specifying a competitor by manually inputting a public player identifier of the competitor for registration; the second button is a “search and register” button for searching candidates for a competitor and specifying a competitor by selecting one of the search results for registration; and the third button is an “information” button for displaying a personal game result in contrast with a competitor game result.

In a case in which the player operates input device44to input an instruction of selecting the “input and register” button, processor41causes a screen G3prompting for an input of a public player identifier of a competitor player to be displayed on display device45. When the player inputs the public player identifier of the competitor player in a predetermined field of the screen by operating input device44and performs a further operation of inputting an instruction of selecting a “transmit” button of the screen, processor41generates a competitor registration request containing the input public player identifier and the private player identifier stored in the personal ID area for transmission to game server device3. The competitor registration request is data that instructs that a player indicated by the public player identifier be registered as a competitor of the requesting player.

FIG. 19is a flow chart showing a competitor registration response process performed by processor31of game server device3. Processor31performs a competitor registration response process upon receiving the above competitor registration request. In the competitor registration response process, processor31first searches in individual information table T1for a public player identifier contained in the received competitor registration request (Step SC1). Processor31then determines whether there is any record hit in this search, i.e., whether a competitor specified is a real player (Step SC2). In a case in which a result of the determination is “YES”, a private player identifier stored in association with the public player identifier is identified as a competitor private player identifier (Step SC3). Processor31then stores, in association table T2, a record associating the identified private player identifier as a competitor private player identifier with the private player identifier contained in the competitor registration request, thereby registering a competitor (Step SC4). Processor31then replies portable terminal4with a competitor registration response containing the identified private player identifier (Step SC5). The competitor registration request is data indicating that the registration of a competitor is completed. On the other hand, in a case in which a result of the determination of Step SC2changes to “NO”, processor31replies portable terminal4with a competitor registration response indicating that the registration could not be completed (Step SC6).

Processor41of portable terminal4, upon receiving a competitor registration response indicating that the registration is completed, stores in competitor area4723the private player identifier contained in the competitor registration response in association with the public player identifier contained in the above competitor registration request. Processor41then causes a screen G4notifying that the registration is completed to be displayed on display device45. When the player then operates input device44to input an instruction of selecting an “OK” button on the screen, processor41causes a menu screen G2to be displayed. On the other hand, in a case in which a competitor registration response indicating that the registration was unsuccessful is received, a screen indicating that the registration was unsuccessful is displayed for a certain period before menu screen G2is displayed.

When the player operates input device44to input an instruction of selecting the “search and register” button, processor41causes a screen G5prompting for an input of search conditions for competitor candidates to be displayed on display device45. In screen G5, a name of a competitor and a district indicating a competitor's location can be input as search conditions. When the player operates input device44to input desired search conditions and to input an instruction for selecting a “transmit” button of the screen, processor41transmits, to game server device3, a competitor candidate request containing the input search conditions and the private player identifier stored in the personal ID area. The competitor candidate request is data instructing that data on candidates of players who can be compared with the request player be transmitted as a response.

FIG. 20is a flow chart showing a competitor candidate response process performed by processor31of game server device3. Processor31performs a competitor candidate response process upon receiving the competitor candidate request. In the competitor candidate response process, individual information table T1is searched with search conditions contained in the received competitor candidate request (Step SD1). For example, in a case in which a name is specified as a search condition, a record having name information including a character string indicating the specified name is searched; in a case in which a district is specified as a search condition, a record having district information including a character string indicating the specified district as a part is searched; and in a case in which both a name and a district are specified as search conditions a record having name information including a character string indicating the specified name and also having district information including a character string indicating the specified district as a part is searched.

Subsequently, it is determined whether there is any record hit in this search, i.e., whether there is any competitor candidate fulfilling the specified search condition(s) (Step SD2). In a case in which the determination result is “YES”, processor31extracts a private player identifier(s) from the hit record(s) and refers to a record(s) corresponding to the private player identifier(s) in individual information table T1and level table T8to obtain a score, a district name, name information, and the highest level for each private player identifier (Step SD3). Subsequently, processor31obtains the highest level corresponding to the private player identifier contained in the competitor candidate request, and competitor candidates are narrowed down by specifying a private player identifier(s) whose highest level(s) falls within a predetermined range with the obtained highest level as center or a standard (Step SD4). Processor31then generates a competitor candidate response containing the specified private player identifier(s) and a score, a district name, a highest level, and name information corresponding to each of the specified private player identifiers, i.e., information relating to competitor candidates, for transmission to portable terminal4(Step SD5). On the other hand, in a case in which a result of the determination of SD2changes to “NO”, processor31replies to portable terminal4with a competitor candidate response indicating that there are no competitor candidates fulfilling the conditions (Step SD6). Competitor candidates can be narrowed down instead by selecting a predetermined number of competitors whose last update date is close to the current date.

Processor41of portable terminal4, upon receiving a competitor candidate response, causes a screen G6to be displayed on display device45, the screen G6giving information contained in the competitor candidate response in contrast to a personal game result of this time stored in personal result area4722.FIG. 18shows an example of screen G6. This example shows a case in which the number of competitor candidates whose information is contained in the competitor candidate response is 1. In a case in which there are multiple competitor candidates, the player is able to select among competitors candidates whose information is displayed. Furthermore, screen G6is a screen for asking the player whether to register the displayed competitor candidate as a competitor. Therefore, when the player operates input device44to input an instruction of selecting an “YES” button of the screen, processor41generates a competitor registration request for transmission to game server device3in the same way as it was done when the instruction of selecting the “transmit” button is input in screen G3. However, the competitor registration request generated in this case contains a private player identifier of a competitor player instead of a public player identifier of a competitor player. Hereinafter, a process that is the same as the competitor registration response process ofFIG. 19is performed at game server device3, except that Steps SC1to SC3are skipped since a private player identifier is contained in the competitor registration request in this case and except that a step of registering a competitor and a step of transmitting a competitor registration response (Steps SC4and SC5) are performed. Subsequently, a screen G4is displayed at portable terminal4.

In a case in which the player operates input device44to input an instruction for selecting the “information” button, processor41determines whether a competitor is specified. Processor41performs no process in a case in which no competitor is specified, whereas, in a case in which a competitor is specified, processor41causes a screen G7to be displayed on display device45, the screen G7for notifying a personal game result of the time stored in personal result area4722in contrast with a competitor game result of this time stored in competitor area4723.FIG. 18shows an example of screen G7. This example shows a case in which the number of specified competitors is 1, and, in a case in which there are multiple competitors, the player is able to select among competitors whose information is displayed. When the player operates input device44to input an instruction of selecting an “OK” button of the screen G7, processor41causes menu screen G2to be displayed.

In a case in which the player operates input device44to input an instruction for forcible termination, processor41terminates a menu process regardless of the type of screen displayed at the time of the instruction. As a result, the competitor monitoring process is terminated.

FIG. 21is a flow chart showing a comparison process performed by processor11of game device1.

Processor11of game device1starts a comparison process when card2is inserted from card acceptance slot131. In the comparison process, processor11first causes card reading device13to read a card ID from card2(Step SE1).

Processor11then generates a competitor notification request containing the card ID read by card reading device13for transmission to game server device3(Step SE2). The competitor notification request requests game server device3to transmit as a response a private player identifier of a competitor player registered in association with a private player identifier of the requesting player. The competitor notification request differs considerably from the above view request in that it contains a card ID instead of a private player identifier of the requesting player.

Processor31of game server device3replies with a competitor notification response upon receiving a competitor notification request from game device1. However, since the competitor notification request contains a card ID instead of a private player identifier of the requesting player, processor31performs a process of identifying a private player identifier of the requesting player corresponding to the card ID contained in the competitor notification request by referring to association table T2, before identifying, in competitor specifying table T3, one or a plurality of competitor private player identifiers that are in association with the private player identifier. Processor31then transmits to game device1a competitor notification response containing a competitor private player identifier(s). At this stage, the competitor notification response does not contain a game result of a competitor player. Furthermore, at this stage, a private player identifier of a top player in the one-piece-of-music mode is contained in the competitor notification response, where the top player is a player who has gained the highest score in past game results in the game system ofFIG. 1.

Processor11of game device1, upon receiving a competitor notification response returned from game server device3, writes the information contained in the competitor notification response into a corresponding area (top player score area183and competitor result area184) (Step SE3). Subsequently, processor11performs a process of prompting a player who owns card2to select an object (a game result of another player) to be plotted on a graph, so that the game result of another player is compared with the player's own result (Step SE4).FIG. 22shows a diagram for describing changing images displayed on game device1, and is an example of an image for having the player to select the object to be plotted on a graph (a result of another player). In the process of prompting the user to select the object to be made into a graph, an image shown as an example inFIG. 22is displayed on display device15. An item candidate displayed in a middle line of each image is an item candidate that is provisionally selected, and the provisionally selected item candidate is determinately selected when a predetermined operator is operated. The player switches an item candidate that is being provisionally selected by rotating a dial, as indicated by arrows in the figure. When the predetermined operator is operated in a state in which a desired item candidate is provisionally selected, the desired item candidate is determinately selected as an item. Individual competitor players and a top player can be item candidates.

When a desired item is determinately selected by the player, processor11stores the selected item. Processor11also generates a view request containing a private player identifier corresponding to the selected item for transmission to game server device3(Step SE5). Processor31of game server device3, upon receiving a view request from game device, performs a process that is the same as the view response process ofFIG. 17and generates a view response for reply. In this case, a view response generated by processor31contains a game result corresponding to the private player identifier contained in the view request from game device1, when the private player identifier is that of a competitor or of a top player. Furthermore, when the view response is generated, a search is performed in single-piece-of-music table T4for a record having a private player identifier of the requesting player; and therefore, a game result having reflected this search result is contained in the view response.

Processor11of game device1, upon receiving a view response transmitted from game server device3, writes information contained in the view response in a corresponding area (personal result area182, a top player score area183, and competitor result area184) (Step SE6).

Subsequently, processor11waits for various modes relating to the game such as a play mode, a game mode, and an operation mode to be selected (Step SE7). When these modes are selected, it is determined whether the single-player mode, the single mode, and the one-piece-of-music mode are selected, i.e., whether it is possible to use game area R2for displaying a graph (Step SE8). In a case in which the determination changes to “YES”, processor11displays in game area R2a graph showing various scores in contrast with one another as shown inFIG. 23(Step SE9).FIG. 23is a diagram showing an example of a game screen displayed on game device1. From among the bars included in the graph, the left bar shows a score of a game currently being played, and its length is changeable during the game. The center bar shows the highest score (personal best score) which the player has ever obtained in the past, and the right bar shows a score of an item selected in Step SE4. The lengths of the center and the right bars never change during the game play. Each score corresponds to a mode of a game that is being played.

When the game is completed, processor11transmits a game result of the finished play to game server device3(Step SE10), thereby completing the comparison process. Game server device3receives a game result from game device1and updates corresponding tables as appropriate so that this game result is reflected. Thus, data stored in game server device3is kept updated.

A player's being provided with information regarding game situations such as the player being overtaken by a competitor in a game result or a game result of the player closing in on or falling behind that of a competitor could lead to increased motivation for the player to use game device1. As described above, since portable terminal4is used as a terminal device in the present embodiment, such information that could lead to increased motivation can be conveyed to the player regardless of time and place. Therefore, according to the present embodiment, it is possible to attract a player as a customer to visit a shop to play, which could lead to increased frequency of using game device1by the player. As a result, a utilization rate (an amount of time in which game device1is used by players divided by an amount of time in which game device1can be used by players) of game device1and a productivity (profit from a game device1per unit time) of game device1are expected to rise. Furthermore, according to the present embodiment, it is possible, using game device1, to provide to a player who is playing a game information that could lead to increased motivation. In this case, it is possible to give a player a realistic sensation of being engaged in a contest with a competitor while playing, which leads to increased desire to play or “gameworthiness”.

In the foregoing, description has been given of the present embodiment. However, it is possible to modify the present embodiment such that an IC card is used as the above card. In this modification, in an IC card, a private player identifier of a user of the IC card and a private player identifier of a player specified by the user as a competitor may be stored. When the IC card is set to a game device, the game device may read, from the set IC card, the private player identifier of the competitor player for transmission to a server device, so as to thereby obtain a game result of a competitor.