Game system, server, and game device

Abstract

The present invention appropriately processes payment of a play charge in a game device. This game system includes a server and a game device. When a payment request for a play charge in the game device is transmitted from a communication terminal of a player to a payment system, the payment system executes payment of the play charge and notifies the server of the completion of the payment. The server includes: a completion notification reception unit that receives payment completion from the payment system; a permission transmission unit that transmits a play permission to the game device on condition that the payment completion has been received; and a settlement management unit that instructs cancellation of payment in the payment system. The game device includes: a permission reception unit that receives the play permission from the server; a game control unit that controls progress of the game on condition that the play permission is received; and a result transmission unit that transmits a reception result indicating non-reception to the server when the permission reception unit could not receive the play permission. The server further includes a result reception unit that receives the reception result from the game device, and the payment management unit instructs the payment system to cancel the payment of the play charge when the non-reception is notified as the reception result from the game device.

Description

Game system, server and game device

[0001] The present invention relates to a payment settlement process for a play fee for a game device.

[0002] In recent years, cashless payments using smartphones and other communication devices to read two-dimensional codes or operate applications have become widespread. Cashless payments are also used to pay for game fees.

[0003] A gaming device that supports cashless payment is connected to a server. The server is also connected to a system that provides cashless payment services (hereinafter referred to as the "payment system"). We will assume a scenario in which a player plays on a gaming device connected in this manner.

[0004] Players pay the play fee for the game device through cashless payment using their own communication terminals, such as smartphones. More specifically, information on the amount of the play fee is transmitted from the player's communication terminal to the payment system. The payment system executes payment settlement based on the information on the amount of the play fee transmitted from the player's communication terminal.

[0005] When payment of the play fee for the game device has been completed, the payment system transmits this information to the server. The server, having received the information that payment of the play fee has been completed, transmits a message to the game device indicating that the player is authorized to play. The game device, having received the message indicating that play is authorized, activates its internal mechanism and begins the game. This process allows the player to play on a game device that supports cashless payment.

[0006] The server and game devices may be wirelessly connected using a short-range wireless communication standard such as ZigBee (registered trademark). This method allows game devices to be installed in any layout without being restricted by the routing of communication cables.

[0007] Patent No. 7251169 Patent No. 7260023 Patent No. 7272499

[0008] Game devices are installed not only in game centers but also in facilities where many people gather, such as commercial facilities, hotels, and theme parks. In these facilities, game devices are sometimes wirelessly connected to a server and installed in the shadows of floor corners, next to escalators, etc., in order to make effective use of available space.

[0009] Generally, such locations often have poor radio wave strength, making communication between the server and the game device unstable. If the game device supports cashless payment, unstable communication may cause problems with play. For example, even if a player pays the play fee using cashless payment, if the game device does not receive permission to play from the server, the player will not be able to play on the game device.

[0010] The present invention has been made in view of the above circumstances, and its main object is to provide a technique for appropriately processing payments when a communication problem occurs between a server and a game device.

[0011] In one aspect of the present invention, a game system includes a server and a game device. When a payment request for a play fee for the game device is sent to the payment system from a player's communication terminal, the payment system executes payment of the play fee and notifies the server of payment completion. The server includes a completion notification receiving unit that receives payment completion from the payment system, a permission sending unit that sends permission to play to the game device on the condition that payment completion has been received, and a payment management unit that instructs the payment system to cancel payment. The game device includes a permission receiving unit that receives permission to play from the server, a game control unit that controls the progress of the game on the condition that permission to play has been received, and a result sending unit that, when the permission receiving unit fails to receive permission to play, sends a reception result to the server indicating non-reception. The server further includes a result receiving unit that receives the reception result from the game device, and the payment management unit instructs the payment system to cancel payment of the play fee when the game device notifies the payment result that non-reception has occurred.

[0012] According to the present invention, it becomes easier to process payments appropriately when a communication problem occurs between a server and a game device.

[0013] FIG. 1 is a hardware configuration diagram of a game system. FIG. 2 is a sequence diagram showing the flow of payment processing when communication between the server and the game device is normal. FIG. 3 is a data structure diagram of transmission / reception history information. FIG. 4 is a data structure diagram of reception history information. FIG. 5 is a functional block diagram of the server. FIG. 6 is a functional block diagram of the game device. FIG. 7 is a sequence diagram showing the flow of payment processing when a communication interruption occurs from the server to the game device. FIG. 8 is a sequence diagram showing the flow of payment processing when a communication interruption occurs from the game device to the server. FIG. 9 is a sequence diagram showing the flow of payment processing when an instruction to execute forced cancellation of payment is given from an operator terminal. FIG. 10 is a hardware configuration diagram of a game system when pairing registration is executed in the server. FIG. 11 is a sequence diagram showing the flow of payment processing when pairing registration is executed in the server. FIG. 12 is a data structure diagram of pairing information. FIG. 13 is a sequence diagram showing the flow of payment processing when credit acceptance suspension processing is executed in the game device.

[0014] First, an overview of the game system of this embodiment will be described. Next, the flow of payment processing in the game system of this embodiment when communication between the server and the game device is normal will be described. Also, the detailed configuration of the game system of this embodiment will be described. Furthermore, the flow of payment processing in the game system of this embodiment when communication trouble occurs between the server and the game device will be described.

[0015] 1 is a hardware configuration diagram of a game system 100. In the game system 100, a plurality of game devices 300a, 300b, ..., 300n (hereinafter collectively referred to as "game devices 300" when referring to them collectively or when no distinction is made) are wirelessly connected to a server 200 using a short-range wireless communication standard such as ZigBee (registered trademark). In the following description, the game device 300 refers to a crane game device.

[0016] A relay device (not shown) may be connected between server 200 and game devices 300. More specifically, server 200 may be connected to the relay device by wire, and the relay device may be connected to multiple game devices 300a, 300b, ..., 300n wirelessly.

[0017] Furthermore, a payment system 102 is connected to the server 200. The payment system 102 is assumed to be a system that provides an existing cashless payment service by reading a two-dimensional code such as a QR code (registered trademark).

[0018] A display (not shown) is provided on the housing of the game device 300. A two-dimensional code including information such as the play fee for the game device 300 is displayed on the display.

[0019] Assume a situation in which a player is playing a game on a game device 300a. The player captures an image of a two-dimensional code appearing on the display of the game device 300a using a communication terminal such as a smartphone owned by the player (hereinafter referred to as a "player terminal 101"). The player terminal 101 that captured the image of the two-dimensional code transmits a notification (hereinafter referred to as a "payment request") requesting payment of the play fee for the game device 300a to the payment system 102. The payment request also includes information such as the play fee for the game device 300a. Note that, as long as the two-dimensional code is associated with each individual game device 300, it may be displayed on each individual game device 300 as a sticker or the like, rather than being displayed on the display.

[0020] Upon receiving the payment request, the payment system 102 completes payment of the play fee for the game device 300a. The payment system 102 transmits a notification to the server 200 indicating that payment of the play fee for the game device 300a has been completed (hereinafter referred to as "payment completion"). The server 200, upon receiving the payment completion for the game device 300a, transmits a notification to the game device 300a permitting the player who has paid the play fee to play (hereinafter referred to as "play permission"). The game device 300a, which has received the play permission, activates its internal mechanism. This allows the player who has paid the play fee via cashless payment to play on the game device 300a.

[0021] The above flow will be explained in more detail. Figure 2 is a sequence diagram showing the flow of the payment process when communication between the server 200 and the game device 300 is normal. Here, the explanation will be given assuming a scene in which a player plays on the game device 300 on July 1st.

[0022] It is assumed that a player ID "0001" is assigned to the player, and a game machine ID "G01" is assigned to the game device 300. The player ID is an ID that identifies the player. The game machine ID is an ID that identifies the game device 300.

[0023] A display installed on the gaming device 300 (hereinafter referred to as "gaming device 300 (G01)") assigned the gaming device ID "G01" displays a two-dimensional code. The two-dimensional code records the gaming device ID "G01" and address information for accessing the payment system 102. There are multiple systems (companies) that provide cashless payment services. Therefore, the two-dimensional code records address information for multiple payment systems 102.

[0024] A player assigned player ID "0001" (hereinafter referred to as "player (0001)") attempts (plays) to win a prize on the game device 300 (G01). The player (0001) captures an image of a two-dimensional code on the player terminal 101 with the application software for cashless payment service A (hereinafter referred to as "service A") running.

[0025] The player terminal 101 reads the two-dimensional code displayed on the display of the game device 300 (G01) (S10). More specifically, the player terminal 101 acquires the address information of the payment system 102S that provides service A (hereinafter referred to as "address S") from the address information of the payment systems 102 recorded in the two-dimensional code. The player terminal 101 also acquires the game machine ID "G01" from the two-dimensional code.

[0026] The player terminal 101 transmits a payment request together with the game machine ID "G01" and the player ID "0001" to the payment system 102S according to the address S (S12). The payment system 102S receives the payment request and the like from the player terminal 101.

[0027] The payment system 102S transmits a notification (hereinafter referred to as an "amount request") requesting information on the play fee for the game device 300 (G01) together with the game machine ID "G01" to the server 200 (S14). The server 200 receives the amount request from the payment system 102S.

[0028] The server 200 stores amount information in which the play fee for each game device 300 is registered in advance in association with the game machine ID. When the server 200 receives an amount request from the payment system 102, it references the amount information and detects the play fee for the game device 300 (G01). In the amount information of this embodiment, it is assumed that the play fee for the game device 300 (G01) is registered as "300 yen."

[0029] The server 200 transmits a notification (hereinafter referred to as an "amount response") to the payment system 102S informing that the play fee for the game device 300 (G01) is "300 yen" (S16). Upon receiving the amount response from the server 200, the payment system 102S transmits a notification (hereinafter referred to as a "payment confirmation") to the player terminal 101 to confirm whether or not to complete payment of the "300 yen" play fee for the game device 300 (G01) (S18).

[0030] When the player terminal 101 receives the payment confirmation from the payment system 102S, it displays a message on the screen asking whether it is OK to pay 300 yen as the play fee for the game device 300 (G01). To authorize the payment of the play fee, the player (0001) selects an "OK" button (not shown) displayed on the screen of the player terminal 101. When the "OK" button is selected, the player terminal 101 transmits a notification (hereinafter referred to as "payment authorization") to the payment system 102S informing that payment of the play fee has been authorized (S20).

[0031] Upon receiving the payment permission, the payment system 102S completes the payment settlement for the player (0001). That is, the payment of the play fee of "300 yen" for the game device 300 (G01) that used service A by the player (0001) is completed. The payment system 102S transmits a payment completion notice to the server 200 together with the game machine ID "G01" and the player ID "0001" (S22).

[0032] The server 200 receives payment completion and the like from the payment system 102S. The server 200 transmits a play permission including the player ID "0001" to the game device 300 (G01) based on the game machine ID "G01" (S24). The server 200 registers the date and time when the play permission was transmitted to the game device 300 (G01) together with the player ID "0001" in the transmission / reception history information (described below) (S26).

[0033] The game device 300 (G01) receives permission to play from the server 200. The game device 300 (G01) registers the date and time of reception of the permission to play together with the player ID "0001" in the reception history information (described below) (S28). The game device 300 (G01) transmits a reception result to the server 200 notifying that permission to play has been received (S30).

[0034] The server 200 receives a reception result (hereinafter referred to as "reception result (received)") from the game device 300 (G01) indicating that "permission to play has been received." The server 200 registers the date and time of reception of the reception result (received) in the transmission / reception history information (S32). After transmitting the reception result (received), the game device 300 (G01) activates its internal mechanism to start the game (S34). This allows the player (0001) to play on the game device 300 (G01).

[0035] Here, the payment system 102S finalizes the payment at midnight every day based on the total balance for service A throughout the day. More specifically, for example, at midnight on July 1st, the payment system 102S sets the base amount to "0 yen." Assume that user C of service A made multiple payments or charges for using service A on July 1st. The payment system 102S subtracts or adds each time a payment or charge is made using service A, thereby calculating the total balance relative to the base amount (0 yen). At midnight on July 1st, the payment system 102S reflects user C's total balance for July 1st in the balance as of June 30th, thereby calculating the balance as of July 1st. By calculating user C's balance in this way, the payment system 102 finalizes user C's payment.

[0036] Let's assume that player (0001) only used service A on July 1st and paid a play fee of "300 yen" for game device 300 (G01). Therefore, player (0001)'s overall balance on July 1st is 0 yen - 300 yen = -300 yen. At midnight on July 1st, the payment system 102S reflects "-300 yen" in player (0001)'s balance as of June 30th. In other words, "300 yen" is subtracted from player (0001)'s balance as of June 30th. Having calculated player (0001)'s balance as of July 1st in this way, the payment system 102S finalizes player (0001)'s payment for July 1st (S36). If communication between the server 200 and game device 300 (G01) is normal, the payment process in the game system 100 is executed in the above manner.

[0037] 3 is a data structure diagram of the transmission / reception history information 400. The server 200 generates the transmission / reception history information 400 for each game machine ID. As shown in FIG. 3, the transmission / reception history information 400 registers the player ID, the play permission transmission date and time, and the reception result reception date and time.

[0038] As described above, player (0001) played on game device 300 (G01) on July 1st. At this time, communication between server 200 and game device 300 (G01) was normal. Therefore, in transmission / reception history information 400 of server 200, the date and time when play permission was transmitted to game device 300 (G01), "July 1st, 14:00:01", is registered in the "Play Permission Transmission Date and Time" field, along with player ID "0001". In addition, the date and time when the reception result (received) was received from game device 300 (G01), "July 1st, 14:00:01", is also registered in the "Reception Result Reception Date and Time" field.

[0039] 4 is a data structure diagram of reception history information 500. In the reception history information 500 of each game device 300, the date and time at which permission to play was received from the server 200 is registered in the "play permission received date and time" column, along with the player ID. FIG. 4 shows reception history information 500 for game device 300 (G01). FIG. 4 shows that game device 300 (G01) received permission to play from player (0001) at "July 1st, 14:00:01."

[0040] When communication between the server 200 and the game device 300 is normal, the player is allowed to play on the game device 300. In this case, it is assumed that approximately the same date and time are registered in the "Play permission transmission date and time" column and the "Reception result reception date and time" column of the transmission and reception history information 400 corresponding to the player ID, and in the "Play permission reception date and time" column of the reception history information 500.

[0041] By referring to the transmission / reception history information 400 in Fig. 3 and the reception history information 500 in Fig. 4, it can be seen that a communication problem has occurred between the server 200 and the game device 300 (G01). For example, consider a situation in which a player (0002) pays a play fee by cashless payment to play on the game device 300 (G01) after the player (0001).

[0042] The transmission / reception history information 400 in Fig. 3 registers that permission to play for player (0002) was transmitted at "July 1st, 14:18:05." However, the reception history information 500 in Fig. 4 does not register the date and time when the game device 300 (G01) received permission to play for player (0002). Furthermore, the transmission / reception history information 400 in Fig. 3 does not register the date and time when the reception result (received) for player (0002) was received.

[0043] From this, it can be seen that the game device 300 (G01) has not received permission to play for the player (0002) from the server 200, and the reception result (received) has not been transmitted to the server 200. It can also be seen that the server 200 has not received the reception result from the game device 300 (G01). In other words, it can be seen that a communication interruption occurred while permission to play for the player (0002) was being transmitted from the server 200 to the game device 300 (G01).

[0044] Also, assume that player (0003) will play on game device 300 (G01) after player (0002) and has paid the play fee through cashless payment. The transmission / reception history information 400 in FIG. 3 registers that permission to play for player (0003) was transmitted at "July 1st, 14:30:32." The reception history information 500 in FIG. 4 also registers that permission to play for player (0003) was received at "July 1st, 14:30:32." In other words, it can be seen that no communication interruption occurred while permission to play for player (0003) was being transmitted from server 200 to game device 300 (G01).

[0045] 3, the "Date and time of reception of reception result" field in the transmission / reception history information 400 is registered as the date and time when the reception result (received) of the permission to play from player (0003) was received, which is approximately one minute after the date and time registered in the "Date and time of transmission of permission to play" field. This shows that a communication interruption occurred while the reception result of the permission to play from player (0003) was being transmitted from 300 (G01) to the server 200.

[0046] More specifically, the circumstances under which the date and time approximately one minute after the play permission transmission date and time was registered in the "reception result reception date and time" field will be explained. As shown in FIG. 4, the game device 300 (G01) receives the play permission from the player (0003) at "July 1st, 14:30:32." The game device 300 (G01) then transmits a reception result (received) to the server 200. However, after transmitting the reception result (received), a communication problem occurred between the server 200 and the game device 300. As a result, the reception result (received) does not reach the server 200.

[0047] The server 200 is unable to receive the reception result (received) even after one minute has passed since the player (0003) sent permission to play. In this case, the server 200 sends a report request along with the player ID "0003" to the game device 300 (G01). The report request is a notification from the server 200 to the game device 300 instructing it to send the reception result when the server 200 is unable to receive the reception result (received) even after a predetermined time has passed since the player (0003) sent permission to play. Note that the "predetermined time" is expected to be anywhere from several tens of seconds to several minutes, but in this embodiment it is assumed to be "one minute."

[0048] The game device 300 (G01) receives a report request together with the player ID "0003" from the server 200. As described above, the game device 300 (G01) successfully receives permission to play from the player (0003). The game device 300 (G01) transmits a reception result (received) to the server 200. At this time, since no communication problems occurred between the server 200 and the game device 300, the server 200 receives the reception result (received) at "July 1st, 14:31:33." The server 200 registers this date and time in the "reception result received date and time" column of the transmission / reception history information 400.

[0049] In this way, if a communication problem occurs while the reception result (received) is being transmitted from the game device 300 to the server 200, the server 200 transmits a report request to the game device 300. The game device 300 that receives the report request retransmits the reception result (received). The server 200 that receives the reception result (received) registers the reception date and time in the "reception result reception date and time" field in the transmission / reception history information 400. In this embodiment, if the server 200 does not receive the reception result (received) even after one minute has passed since permission to play was transmitted, a report request is transmitted to the game device 300. Therefore, the date and time that is approximately one minute after the date and time permission to play was transmitted is registered in the "reception result reception date and time" field.

[0050] Although details will be described later, a report request is also sent if the game device 300 is unable to receive permission to play. In this case, the game device 300 that has received the report request sends a reception result indicating that "permission to play was not received" (hereinafter referred to as "reception result (not received)") to the server 200. Upon receiving the reception result (not received), the server 200 instructs the payment system 102 to cancel payment of the play fee.

[0051] It is assumed that the communication interruption between server 200 and game device 300 immediately after the play permission is transmitted is momentary and that communication is quickly restored. In this case, server 200 can receive the reception result (received) or reception result (not received) from game device 300 immediately after transmitting a report request to game device 300 (approximately one minute after the play permission is transmitted).

[0052] However, if communication between server 200 and game device 300 is interrupted for a long period of time, there is a possibility that game device 300 will not be able to receive a report request even if server 200 transmits the report request. Furthermore, even if game device 300 successfully receives the report request and transmits a reception result (received) or a reception result (not received) to server 200, there is a possibility that the report request will not reach server 200.

[0053] To deal with such a situation, server 200 transmits a report request to game device 300 every minute until it receives a reception result (received) or a reception result (not received). However, no matter how many times server 200 transmits a report request to game device 300, it may not be able to receive a reception result (received) or a reception result (not received) from game device 300. In this case, it is assumed that an abnormality may have occurred in the communication equipment of server 200 or game device 300, and measures such as device replacement will be taken.

[0054] Next, the detailed configurations of the server 200 and the game device 300 will be described. FIG. 5 is a functional block diagram of the server 200. Each component of the server 200 is implemented by hardware including computing units such as a CPU (Central Processing Unit) and various coprocessors, storage devices such as memory and storage, and wired or wireless communication lines connecting these, as well as software stored in the storage devices and supplying processing instructions to the computing units. The computer program may be implemented by device drivers, an operating system, various application programs located above these, and libraries that provide common functions to these programs. Each block described below represents a functional block rather than a hardware configuration. The same applies to each component of the game device 300 described in relation to FIG. 6 below.

[0055] The server 102 includes a communication unit 210, a data storage unit 220, and a data processing unit 230. The communication unit 210 is responsible for communication processing with the payment system 102 and the game device 300. The data storage unit 220 stores transmission / reception history information 400 and amount information (not shown). The data processing unit 230 executes various processes based on the data received by the communication unit 210 and the transmission / reception history information 400 stored in the data storage unit 220. The data processing unit 230 also functions as an interface between the communication unit 210 and the data storage unit 220.

[0056] The communication unit 160 includes a receiving unit 211 that receives various data and a transmitting unit 212 that transmits various data. The receiving unit 211 receives an amount request along with the gaming machine ID "G01" from the payment system 102. The receiving unit 211 also receives a payment completion notification along with the gaming machine ID and player ID from the payment system 102. The receiving unit 211 also receives a reception result from the game device 300.

[0057] The transmitting unit 212 transmits the amount response to the payment system 102. The transmitting unit 212 also transmits permission to play together with the player ID to the game device 300. The transmitting unit 212 then transmits a report request together with the player ID to the game device 300. If the game device 300 does not receive permission to play, the transmitting unit 212 transmits a cancellation instruction (described below) to the payment system 102 to cancel the payment of the play fee.

[0058] The data processing unit 230 includes an amount management unit 231, a play permission management unit 232, a history registration unit 233, a reception result management unit 234, a report request management unit 235, and a settlement management unit 236. When the reception unit 211 receives an amount request, the amount management unit 231 detects the play fee for the game device 300 to be played from the amount information and instructs the transmission unit 212 to transmit an amount response. When the reception unit 211 receives a payment completion notification, the play permission management unit 232 instructs the transmission unit 212 to transmit play permission to the game device 300. The play permission management unit 232 instructs the history registration unit 233 to register the date and time when the play permission was transmitted to the game device 300 in the transmission / reception history information 400. The play permission management unit 232 also notifies the reception result management unit 234 that play permission has been transmitted. The history registration unit 233 receives an instruction from the play permission management unit 232 and registers the date and time when the play permission was transmitted in the transmission / reception history information 400 together with the player ID.

[0059] When the receiving unit 211 receives the reception result (received), the reception result management unit 234 instructs the history registration unit 233 to register the date and time when the reception result (received) was received in the transmission and reception history information 400. In response to the instruction from the reception result management unit 234, the history registration unit 233 registers the date and time when the reception result (received) was received in the transmission and reception history information 400.

[0060] When the receiving unit 211 does not receive a reception result (received) within one minute after being notified that permission to play has been transmitted, the reception result management unit 234 notifies the report request management unit 235 to send a report request. Upon receiving the notification from the reception result management unit 234, the report request management unit 235 instructs the transmitting unit 212 to send a report request to the game device 300.

[0061] Assume that after transmitting the report request, the receiving unit 211 receives a reception result (received). In this case, the reception result management unit 234 instructs the history registration unit 233 to register the date and time when the reception result (received) was received in the transmission / reception history information 400. Also, assume that the receiving unit 211 receives a reception result (not received). In this case, the reception result management unit 234 notifies the payment management unit 236 to cancel the payment. Upon receiving the notification from the reception result management unit 234, the payment management unit 236 instructs the transmitting unit 212 to transmit a cancellation instruction to the payment system 102.

[0062] In this embodiment, the receiving unit 211 functions as a "completion notification receiving unit" and a "result receiving unit." The transmitting unit 212 functions as a "permission transmitting unit" and a "request transmitting unit."

[0063] 6 is a functional block diagram of the game device 300. The game device 300 includes a user interface processing unit 310, a communication unit 320, a data storage unit 330, and a data processing unit 340. The user interface processing unit 310 accepts operations from the player via various input devices and is responsible for user interface-related processing such as image display and audio output. The communication unit 320 is responsible for communication processing with the server 200. The data storage unit 330 stores reception history information 500. The data processing unit 340 performs various processes based on data received by the communication unit 320 and the reception history information 500 stored in the data storage unit 330. The data processing unit 340 also functions as an interface between the communication unit 320 and the data storage unit 330.

[0064] The user interface processing unit 310 includes an input unit 311 that accepts input from the player, and an output unit 312 that outputs various information such as images and sounds to the player. The player plays the crane game by operating input devices such as buttons and levers (neither of which is shown) that are provided on the game device 300 as the input unit 311. The game device 300 is provided with a display (not shown) that serves as the output unit 312. A two-dimensional code that stores information such as the play fee is displayed on the display.

[0065] The communication unit 320 includes a receiving unit 321 that receives various data and a transmitting unit 322 that transmits various data. The receiving unit 321 receives a play permission together with a player ID from the server 200. The receiving unit 321 receives a report request together with the player ID from the server 200. The transmitting unit 322 transmits a reception result to the server 200.

[0066] The data processing unit 340 includes a code generation unit 341, a reception result management unit 342, a history registration unit 343, and a game control unit 344. The code generation unit 341 generates a two-dimensional code to be displayed on the output unit 312 (display). When the receiving unit 321 receives a play permission or the like, the reception result management unit 342 instructs the transmitting unit 322 to transmit a reception result (received). The reception result management unit 342 instructs the history registration unit 343 to register the date and time when the play permission was received in the reception history information 500. In response to the instruction from the reception result management unit 342, the history registration unit 343 registers the date and time when the play permission was received in the reception history information 500. Furthermore, after instructing the reception result management unit 342 to transmit the reception result (received), the reception result management unit 342 instructs the game control unit 344 to start the game. In response to the instruction from the reception result management unit 342, the game control unit 344 drives the internal mechanisms of the game device 300 to start the game.

[0067] When the receiving unit 321 receives a report request or the like, the reception result management unit 342 refers to the reception history information 500 stored in the data storage unit 330. The reception result management unit 342 identifies whether or not a play permission reception date and time is registered for the player ID transmitted from the server 200. The reception result management unit 342 instructs the transmitting unit 322 to transmit to the server 200 a reception result according to whether or not a play permission reception date and time is registered in the reception history information 500.

[0068] More specifically, if the play permission reception date and time is registered in the reception history information 500, the reception result management unit 342 instructs the transmission unit 322 to transmit the reception result (received). If the play permission reception date and time is not registered in the reception history information 500, the reception result management unit 342 instructs the transmission unit 322 to transmit the reception result (not received).

[0069] In this embodiment, the receiving unit 321 functions as a "permission receiving unit" and a "request receiving unit." The transmitting unit 322 functions as a "result transmitting unit."

[0070] The following describes the flow of payment processing when a communication interruption occurs between the server 200 and the game device 300 in the game system 100 of this embodiment. Figure 7 is a sequence diagram showing the flow of payment processing when a communication interruption occurs from the server 200 to the game device 300. Here, with reference to the transmission / reception history information 400 in Figure 3 and the reception history information 500 in Figure 4, the description will be given assuming a scene after the player (0002) has paid the play fee for the game device 300 (G01) by cashless payment using service A.

[0071] The processing from S10 to S22 in the player terminal 101 of player (0002), the payment system 102S, and the server 200 is the same as the processing shown in S10 to S22 in FIG. 2. The receiving unit 211 of the server 200 receives payment completion together with the game machine ID "G01" and the player ID "0002" from the payment system 102S. The play permission management unit 232 instructs the transmitting unit 212 to transmit a play permission together with the player ID "0002" to the game device 300 (G01) based on the game machine ID "G01". The transmitting unit 212 transmits the player ID "0002" and the play permission to the game device 300 (G01) (S24).

[0072] The play permission management unit 232 instructs the history registration unit 233 to register the date and time when play permission was transmitted together with the player ID "0002" in the transmission / reception history information 400. The history registration unit 233 registers the date and time when play permission was transmitted in the transmission / reception history information 400 (S26). The play permission management unit 232 also notifies the reception result management unit 234 that play permission has been transmitted.

[0073] Here, suppose that after player (0002) transmits permission to play, a communication interruption occurs between the server 200 and the game device 300 (G01) before the permission to play reaches the game device 300 (G01). As a result, the receiving unit 321 of the game device 300 (G01) is unable to receive the permission to play. In other words, the transmitting unit 322 of the game device 300 (G01) is unable to transmit a reception result (received) to the server 200.

[0074] Even though one minute has passed since the reception result management unit 234 was notified that permission to play had been transmitted, the reception unit 211 of the server 200 does not receive a reception result (received). The reception result management unit 234 notifies the report request management unit 235 to transmit a report request to the game device 300 (G01). The report request management unit 235 instructs the transmission unit 212 to transmit a report request together with the player ID "0002". The transmission unit 212 transmits the report request together with the player ID "0002" to the game device 300 (G01) (S38).

[0075] The receiving unit 321 of the game device 300 (G01) receives a report request along with the player ID "0002" from the server 200. The reception result management unit 342 references the reception history information 500 to determine whether the date and time when permission to play from player (0002) was received is registered (S40). As described above, the receiving unit 321 has not received permission to play from player (0002). Therefore, the date and time when permission to play from player (0002) was received is not registered in the reception history information 500. Based on this result, the reception result management unit 342 instructs the transmission unit 322 to transmit a reception result (not received) to the server 200. The transmission unit 322 transmits the reception result (not received) to the server 200 (S30).

[0076] The receiving unit 211 of the server 200 receives a reception result (not received) from the game device 300 (G01). The reception result management unit 234 notifies the payment management unit 236 to cancel the payment settlement of the play fee for the player (0002). The payment management unit 236 instructs the transmitting unit 212 to transmit a cancellation instruction together with the player ID "0002". The transmitting unit 212 transmits the cancellation instruction together with the player ID "0002" to the payment system 102S (S42).

[0077] The payment system 102S receives the cancellation instruction along with the player ID "0002" from the server 200. The payment system 102S cancels the payment of the play fee for the player (0002) (S44).

[0078] To summarize, suppose a communication problem occurs while permission to play is being transmitted from server 200 to game device 300. In this case, game device 300 is unable to receive permission to play and is therefore unable to transmit a reception result to server 200. Since server 200 is unable to receive a reception result even one minute after transmission of permission to play, it transmits a report request to game device 300. Upon receiving the report request, game device 300 transmits a reception result (not received) to server 200. Upon receiving the reception result (not received), server 200 instructs payment system 102 to cancel payment of the play fee.

[0079] By canceling the payment in this manner, it is possible to prevent a situation in which payment of a player's play fee is confirmed even when the game device 300 is unable to play. Furthermore, even if the server 200 is unable to receive a reception result from the game device 300, the server 200 does not immediately instruct the payment system 102 to cancel the payment. The server 200 transmits a report request, and only transmits a cancellation instruction to the payment system 102 after receiving a reception result (not received) from the game device 300. In other words, the server 200 does not transmit a cancellation instruction to the game device 300 unless it receives a reception result from the game device 300. In this way, the server 200 instructs the cancellation of the payment after reliably recognizing that the game cannot be started on the game device 300, thereby improving the reliability of the payment process.

[0080] 8 is a sequence diagram showing the flow of payment processing when a communication interruption occurs from the game device 300 to the server 200. Here, with reference to the transmission / reception history information 400 in FIG. 3 and the reception history information 500 in FIG. 4, the description will be given assuming a scene after the player (0003) has paid the play fee for the game device 300 (G01) by cashless payment using service A.

[0081] The processing from S10 to S28 in the player terminal 101, the payment system 102S, the server 200, and the game device 300 (G01) is the same as the processing shown in S10 to S28 in Fig. 2. That is, in the case of Fig. 8, the game device 300 (G01) successfully receives the play permission from the player (0003). Furthermore, for the player (0003), the same date and time are registered in the "Play permission transmission date and time" column of the transmission / reception history information 400 in Fig. 3 and the "Play permission reception date and time" column of the reception history information 500 in Fig. 4. Furthermore, the reception result management unit 234 is notified by the play permission management unit 232 that permission to play has been transmitted.

[0082] As described above, the receiving unit 321 of the game device 300 (G01) receives permission to play from the player (0003). The reception result management unit 342 instructs the transmitting unit 322 to transmit the reception result (received). The transmitting unit 322 transmits the reception result (received) to the server 200 (S30). After the reception result (received) is transmitted, the game control unit 344 activates the internal mechanism to start the game (S34). This allows the player (0003) to play on the game device 300 (G01).

[0083] Here, suppose that after the reception result (received) is transmitted, a communication interruption occurs between the server 200 and the game device 300 (G01) before the reception result (received) reaches the server 200. The reception unit 321 of the game device 300 (G01) successfully receives the play permission, but the reception unit 211 of the server 200 is unable to receive the reception result (received). In other words, the server 200 is unable to recognize whether the game device 300 (G01) has received the play permission from the player (0003).

[0084] Even though one minute has passed since the reception result management unit 234 of the server 200 was notified that permission to play had been transmitted, the reception unit 211 does not receive a reception result (received). The reception result management unit 234 notifies the report request management unit 235 to transmit a report request. The report request management unit 235 instructs the transmission unit 212 to transmit a report request together with the player ID "0003" to the game device 300 (G01). The transmission unit 212 transmits the report request together with the player ID "0003" to the game device 300 (G01) (S38).

[0085] The receiving unit 321 of the game device 300 (G01) receives a report request along with the player ID "0003" from the server 200. The reception result management unit 342 references the reception history information 500 and determines whether the date and time when permission to play from player (0003) was received is registered (S40). As described above, the receiving unit 321 has received permission to play from player (0003). Therefore, the date and time when permission to play from player (0003) was received is registered in the reception history information 500. Based on this result, the reception result management unit 342 instructs the transmission unit 322 to resend the reception result (received) to the server 200. The transmission unit 322 transmits the reception result (received) to the server 200 (S30).

[0086] The receiving unit 211 of the server 200 receives a reception result (received) from the game device 300 (G01). The reception result management unit 234 instructs the history registration unit 233 to register the date and time when the reception result (received) was received in the transmission / reception history information 400. The history registration unit 233 registers the date and time when the reception result (received) for player (0003) was received in the transmission / reception history information 400 (S32). In this case, no cancellation instruction is sent from the server 200. Therefore, the payment system 102S finalizes payment of the play fee for player (0003) at midnight on July 1st (S36).

[0087] In summary, suppose a communication problem occurs while the reception result (received) is being sent from the game device 300 to the server 200. In this case, the reception result (received) does not reach the server 200. Because the server 200 has not received the reception result even one minute after sending the permission to play, the server 200 sends a report request to the game device 300. Upon receiving the report request, the game device 300 resends the reception result (received) to the server 200. Upon receiving the reception result (received), the server 200 registers the date and time when the reception result (received) was received in the transmission / reception history information 400. In this case, no cancellation instruction is sent to the payment system 102. Therefore, the payment system 102 finalizes payment of the play fee at midnight that day.

[0088] Even if the reception result (received) cannot be received due to a communication problem, the server 200 does not immediately send a payment cancellation instruction to the payment system 102. The server 200 sends a report request, and only recognizes that the game device 300 has successfully started the game after receiving the reception result (received) from the game device 300. In this case, the server 200 does not send a payment cancellation instruction to the payment system 102, so the payment system 102 finalizes the payment at midnight on that day. In this way, the server 200 has confirmed with certainty that the game has been started on the game device 300 before having the payment system 102 finalize the payment, and therefore, similar to the case of FIG. 7, the robustness of the payment process can be improved.

[0089] [Summary] The gaming system 100 of the present invention has been described above. Cashless payment using communication terminals such as smartphones has become widespread in recent years. Cashless payment is also used to pay play fees for gaming devices 300. Gaming devices 300 that support cashless payment are connected to the server 200, and may be connected wirelessly using a short-range wireless communication standard such as ZigBee (registered trademark). Wireless connection allows gaming devices 300 to be installed in any layout without being restricted by the routing of communication cables. However, if a gaming device 300 is installed in the shadows, communication between the server 200 and the gaming device 300 may become unstable. In such cases, problems may arise, such as the player being unable to start playing despite having paid the play fee using cashless payment.

[0090] In light of the above, this embodiment has described a method for appropriately processing payments when a communication problem occurs between the server 200 and the game device 300. For example, suppose a communication problem occurs while a play permission is being transmitted from the server 200 to the game device 300. The game device 300 cannot start the game because it cannot receive the play permission from the server 200.

[0091] In such a case, the server 200 transmits a report request to the game device 300 a predetermined time, more specifically, one minute, after the transmission of permission to play. When the game device 300 receives the report request, it transmits a reception result to the server 200 indicating that permission to play has not been received. Having received the reception result, the server 200 transmits a cancellation instruction to the payment system 102. Upon receiving the cancellation instruction, the payment system 102 cancels the payment of the play fee. This method makes it possible to prevent improper payment settlements, in which payment is confirmed for a play fee paid by cashless payment even though the player has not played on the game device 300.

[0092] Also, suppose that a communication problem occurs while the reception result (received) is being sent from game device 300 to server 200. In this case, server 200 is unable to receive the reception result even one minute after sending permission to play, and so sends a report request to game device 300. When game device 300 receives the report request, it sends a reception result to server 200 indicating that permission to play has been received. Having received the reception result, server 200 does not send a cancellation instruction to payment system 102, and so payment of the play fee is finalized at midnight that day.

[0093] Even if the server 200 is unable to receive a reception result (received) from the server 200 due to a communication problem, the server 200 does not immediately send a payment cancellation instruction to the payment system 102. The server 200 sends a report request to the game device 300, causing the game device 300 to resend the reception result (received). Upon receiving the reception result (received), the server 200 recognizes that the game device 300 has successfully started the game, and does not send a payment cancellation instruction. This prevents situations where payment of a play fee is canceled even though the game is still being played on the game device 300, and ensures reliable payment processing.

[0094] The present invention is not limited to the above-described embodiments and modifications, and the components can be modified without departing from the spirit of the invention. Various inventions can be formed by appropriately combining multiple components disclosed in the above-described embodiments and modifications. Furthermore, some components can be omitted from all the components shown in the above-described embodiments and modifications.

[0095] [Variation 1] Suppose that a communication interruption occurs while permission to play is being transmitted from the server 200 to the game device 300. In this embodiment, if the server 200 does not receive a reception result (received) one minute after transmitting the permission to play, the server 200 transmits a report request to the game device 300. The game device 300 transmits a reception result (not received) to the server 200. When the reception result (not received) is received, the server 200 instructs the payment system 102 to cancel the payment. As a variation, a communication terminal (not shown) (hereinafter referred to as the "operator terminal") owned by an employee of the facility where the game device 300 is installed (hereinafter referred to as the "operator") may be used to directly instruct the server 200 to cancel the payment.

[0096] 9 is a sequence diagram showing the flow of payment processing when an instruction to execute forced cancellation of payment is given from the operator terminal. Here, a situation will be described in which the player (0004) pays the play fee for the game device 300 (G01) by cashless payment, and then the operator terminal gives an instruction to execute forced cancellation of payment.

[0097] The processes from S10 to S26 in the player terminal 101 of player (0004), the payment system 102S, the server 200, and the game device 300 (G01) are the same as the processes shown in S10 to S26 in Fig. 7. That is, after the play permission is transmitted, a communication interruption occurs between the server 200 and the game device 300 (G01) before the play permission reaches the game device 300 (G01). Because the receiving unit 321 of the game device 300 (G01) cannot receive the play permission, the transmitting unit 322 cannot transmit a reception result (received) to the server 200.

[0098] Normally, when the player (0004) pays the play fee for the game device 300 (G01) using cashless payment, the internal mechanism of the game device 300 (G01) immediately starts up, and the player (0004) is able to play on the game device 300 (G01). However, because the game device 300 (G01) is unable to receive permission to play from the server 200, the game device 300 (G01) is unable to start up its internal mechanism. The player (0004) is unable to play on the game device 300 (G01) and is forced to wait in front of the game device 300 (G01).

[0099] In this situation, the player (0004) calls a nearby operator and tells them that he has paid the play fee to the game device 300 (G01) by cashless payment but cannot start playing, and would like a refund of the play fee. At this time, the operator uses his operator terminal to instruct the server 200 to cancel the payment.

[0100] More specifically, the operator terminal includes a transmission / reception history acquisition unit and an instruction transmission unit (both not shown). The transmission / reception history acquisition unit accesses the server 200 and acquires transmission / reception history information 400 of the game device 300 with the specified game device ID. The instruction transmission unit transmits to the server 200 a notification (hereinafter referred to as a "forced cancellation instruction") instructing the server 200 to forcibly cancel payment of the play fee for the specified player.

[0101] Upon receiving a request from the player (0004), the operator enters the game machine ID "G01" of the game machine 300 on which the player (0004) was scheduled to play in a game machine ID input field (not shown) displayed on a game machine designation screen (not shown) of the operator terminal. The operator selects a transmission / reception history acquisition button (not shown). When the transmission / reception history acquisition button is selected, the transmission / reception history acquisition unit accesses the server 200 and acquires the transmission / reception history information 400 of the game machine ID "G01" entered in the game machine ID input field (S46). The operator terminal displays the acquired transmission / reception history information 400.

[0102] The operator references the displayed transmission / reception history information 400 for game machine ID "G01" and confirms that no date and time is registered in the "Reception result reception date and time" field for player ID "0004." The operator enters player ID "0004" in the player ID input field (not shown) and selects the cancel button (not shown). When the cancel button is selected, the instruction sending unit sends an instruction to the server 200 to forcibly cancel payment of the play fee for player (0004) (S48).

[0103] The receiving unit 211 of the server 200 receives the forced cancellation instruction from the operator terminal. The reception result management unit 234 receives the forced cancellation instruction and notifies the payment management unit 236 to send a cancellation instruction for the payment settlement of the play fee for player (0004). The payment management unit 236 instructs the transmitting unit 212 to send the cancellation instruction together with the player ID "0004". The transmitting unit 212 sends the cancellation instruction together with the player ID "0004" to the payment system 102 (S42).

[0104] The payment system 102 receives the cancellation instruction along with the player ID "0004" from the server 200. The payment system 102 cancels the payment of the play fee for the player (0004) based on the player ID "0002" (S44).

[0105] In this way, if a player cannot start playing immediately despite having paid the play fee for the game device 300 by cashless payment, the player can request the operator to cancel the play. The operator uses the operator terminal at hand to instruct the server 200 to cancel the play fee. This allows the player to get a refund for the play fee. The play fee that was intended to be paid to the game device 300 can be used to pay for other goods or services.

[0106] As described above, if a communication interruption occurs for a long period of time between the server 200 and the game device 300, the server 200 may not receive the reception result (not received) even after the report request has been sent. In such a case, the player cannot play on the game device 300, and the operator terminal may instruct the server 200 to cancel the payment.

[0107] The operator terminal may include a transmission history acquisition unit (not shown) and access the game devices 300 in a similar manner to acquire the reception history information 500 of a specific game device 300. In this case, the operator terminal acquires the reception history information 500 from the game device 300. The operator confirms that no date and time is registered in the "Play Permission Receipt Date and Time" field for the player whose payment is to be canceled. Then, the operator enters the player ID in the player ID input field and selects the cancel button. Using this method, the cancellation instruction unit may send a forced cancellation instruction to the server 200 for the payment of the play fee.

[0108] [Variation 2] In this embodiment, the player terminal 101 reads the two-dimensional code displayed on the display of the game device 300, and transmits a payment request together with the play fee and the like to the payment system 102. It has been described that the payment system 102 transmits a payment completion notice to the server 200 when payment of the play fee is completed. As a variation, payment of the play fee may be performed using a dedicated application (hereinafter referred to as "Crane Service (CS) software") for using services provided for the crane game, such as pairing registration, which will be described later.

[0109] In this case, the hardware configuration of the game system 100 differs from that shown in Fig. 1. Fig. 10 is a hardware configuration diagram of the game system 100 when pairing registration is performed in the server 200. In Fig. 10, the player terminal 101 is connected to the server 200, not the payment system 102. The payment system 102 is connected to the player terminal 101 via the server 200.

[0110] 11 is a sequence diagram showing the flow of payment processing when pairing registration is performed in the server 200. Here, a scene will be described in which the player (0005) performs pairing registration and then pays the play fee for the game device 300 (G01) by cashless payment.

[0111] It is assumed that the player (0005) has previously registered with the server 200 that he / she will use the payment system 102T to pay the play fee by cashless payment using the CS software. The payment system 102T is a system that provides an existing cashless payment service using a credit card.

[0112] The server 200 includes a player management unit and a transfer instruction unit (both not shown). The player management unit associates a player ID with a game device ID and performs pairing registration. By performing pairing registration, the server 200 can grasp the current player of the game device 300 (G01). The transfer instruction unit instructs the transmission unit 212 to transmit a payment request, etc. transmitted from the player terminal 101 to the payment system 102.

[0113] The game device 300 (G01) displays a two-dimensional code recording the game machine ID "G01" on its display. The player (0005) images the two-dimensional code using the player terminal 101 while the CS software is running. The player terminal 101 reads the two-dimensional code displayed on the display of the game device 300 (G01) (S10). The two-dimensional code records the game machine ID "G01" and address information of the server 200. The player terminal 101 acquires this information from the imaged two-dimensional code.

[0114] The player terminal 101 transmits a pairing request to the server 200 together with the game machine ID "G01" and the player ID "0005" in accordance with the address information of the server 200 (S50). The pairing request is a notification requesting pairing registration of the game machine ID and the player ID.

[0115] 12 is a data structure diagram of the pairing information 600. The receiving unit 211 of the server 200 receives a pairing request, etc. from the player terminal 101. The player management unit associates the player ID "0005" with the game machine ID "G01" and registers them in the pairing information 600 as shown in FIG. 12 (S52).

[0116] After the pairing registration is completed, the player management unit instructs the transmission unit 212 to transmit a notification that the pairing registration is completed (hereinafter referred to as a "registration notification"). The transmission unit 212 transmits the registration notification to the player terminal 101 of the player (0005) (S54).

[0117] When the player terminal 101 receives the registration notification, it displays a play fee selection screen (not shown). The play fee selection screen displays play fee buttons (not shown) that indicate the number of times a player can play for the amount paid, such as "1 play: 300 yen" or "2 plays: 500 yen." It is assumed that player (0005) selects the "1 play: 300 yen" play fee button (S56). When the play fee button is selected, the player terminal 101 transmits a payment request to the server 200 together with the player ID "0005" and the play fee of "300 yen" (S12).

[0118] The receiving unit 211 of the server 200 receives the payment request, etc. The request forwarding unit references the pairing information 600 and detects the game machine ID "G01" that is registered in association with the player ID "0005." The request forwarding unit instructs the transmitting unit 212 to transmit a payment request to the payment system 102T, along with the player ID "0005" and the play fee "300 yen." The transmitting unit 212 transmits the payment request, etc. to the payment system 102T (S58).

[0119] The payment system 102T receives a payment request or the like from the player terminal 101 of the player (0005). The payment system 102T completes the payment settlement for the player (0005). After the payment settlement is completed, the processing from S22 to S36 in the payment system 102T, the server 200, and the game device 300 (G01) is the same as the processing shown in S22 to S36 in FIG. 2.

[0120] In this embodiment, the cashless payment process using a two-dimensional code has been described. Furthermore, the payment of the play fee for the game device 300 can also be made by the above-described method.

[0121] [Variation 3] In the present embodiment, the description has been given assuming that the play fee for the gaming device 300 is paid by cashless payment. As a variation, the gaming device 300 also accepts payment of the play fee in cash (coins). Suppose that coins are inserted into the gaming device 300 between the time the player terminal 101 transmits a payment request to the payment system 102 and the completion of payment of the play fee by cashless payment until permission to play arrives at the gaming device 300. In this case, the gaming device 300 may be able to cancel payment of the play fee.

[0122] More specifically, the gaming device 300 includes a credit management unit (not shown). The credit management unit calculates the total amount of credits by adding credits (number of available plays) corresponding to the amount paid to the gaming device 300, regardless of whether the payment is made by cashless payment or cash, to a credit counter.

[0123] Assume that the gaming device 300 (G02) requires payment of 100 yen per credit. For example, imagine a situation in which a player inserts a 100 yen coin into the gaming device 300 (G02) to pay a play fee. At this time, the credit management unit adds "1" to the credit counter. As a result, the total credit becomes "1."

[0124] As another example, consider a situation in which a player pays 100 yen as a play fee to the game device 300 (G02) by cashless payment. In this case, when the payment system 102 transmits a payment completion notice to the server 200, the information on the paid play fee, "100 yen," is also transmitted along with the game machine ID and player ID. Similarly, when the server 200 transmits permission to play, the information on the paid play fee, "100 yen," is also transmitted along with the player ID. The credit management unit of the game device 300 (G02) converts the play fee information, "100 yen," received together with the permission to play into one credit and adds it to the credit counter. This brings the total credit to "1."

[0125] Furthermore, it is assumed that the gaming device 300 (G02) can accept up to 5 credits at a time. That is, the upper limit of the play fee that the gaming device 300 (G02) can accept at a time is 500 yen. In this case, it is assumed that 500 yen has been paid to the gaming device 300 (G02). That is, it is assumed that the value of the credit counter has reached "5" or more. At this time, the credit management unit executes a credit acceptance suspension process. In the credit acceptance suspension process, when a play permission is transmitted from the server 200, the credit management unit notifies the reception result management unit 342 to transmit a notification to the server 200 indicating that the play permission has not been accepted (hereinafter referred to as a "reception result (acceptance refusal)"). Note that, if the server 200 receives a reception result (acceptance refusal) from the gaming device 300 (G02), the server 200 transmits a cancellation instruction to the payment system 102, just as it would if a reception result (not received) had been received.

[0126] 13 is a sequence diagram showing the flow of the payment process when credit card acceptance suspension processing is executed in the game device 300. Here, it is assumed that the player (0006) pays the play fee to the game device 300 (G02) by cashless payment using service A.

[0127] The player (0006) uses the player terminal 101 to capture the two-dimensional code displayed on the display of the game device 300 (G02) while the application software for service A is running. The two-dimensional code records the game device ID "G02" and the address S.

[0128] The player terminal 101 reads the two-dimensional code in which the game machine ID "G02" and address S are recorded from among the multiple two-dimensional codes displayed on the display of the game device 300 (G02) (S10). At this time, it is assumed that the player (0006) wishes to play for 5 credits. In accordance with the address S, the player terminal 101 transmits a payment request to the payment system 102S together with the game machine ID "G02" and player ID "0006" (S12).

[0129] The payment system 102S receives a payment request, etc. from the player terminal 101. The payment system 102S transmits an amount request to the server 200 together with the game machine ID "G02" (S14). The amount management unit 231 of the server 200 detects from the amount information that the play fee for 5 credits of the game device 300 (G02) is "500 yen". The amount management unit 231 instructs the transmission unit 212 to transmit an amount response indicating that the play fee is "500 yen". The transmission unit 212 transmits the amount response to the player terminal 101 (S16).

[0130] When the payment system 102S receives the amount response from the server 200, it transmits a payment confirmation for the play fee of "500 yen" for the game device 300 (G02) to the player terminal 101 (S18). The player (0006) selects the "Allow" button on the screen of the player terminal 101 to authorize payment of the play fee. When the "Allow" button is selected, the player terminal 101 transmits payment authorization to the payment system 102S (S20).

[0131] When the payment system 102S receives the payment permission, it completes the payment settlement for the player (0006) for the play fee of "500 yen" for the game device 300 (G02). The payment system 102S transmits a payment completion notice to the server 200 together with the game machine ID "G02", the player ID "0006", and the play fee of "500 yen" (S22). The processing of S24 and S26 in the server 200 is the same as the processing shown in S24 and S26 in FIG. 2.

[0132] Now, suppose that after a payment request or the like is transmitted to the payment system 102S, but before the game device 300 (G02) receives permission to play, the player (0006) wants to play one more credit and inserts a 100 yen coin into the game device 300 (G02) (S60). At this time, the credit management unit of the game device 300 (G02) adds "1" to the credit counter. That is, the value of the credit counter becomes "1."

[0133] Thereafter, the game device 300 (G02) receives from the server 200 the play fee information "500 yen" along with the play permission and the player ID. The credit management unit converts the play fee information "500 yen" into 5 credits and adds this to the credit counter. Therefore, the total credit becomes "6." Because the value of the credit counter is now "5" or greater, the credit management unit executes a credit acceptance stop process (S62).

[0134] When the credit management unit executes the credit acceptance suspension process, the reception result management unit 342 instructs the transmission unit 322 to transmit a reception result (acceptance refusal) to the server 200 without referencing the reception history information 500. The transmission unit 322 transmits the reception result (acceptance refusal) to the server 200 (S30). Thereafter, the server 200 and the payment system 102 execute processes similar to those shown in S42 and S44 of FIG. 7, and the payment settlement of the play fee for player (0006) is canceled. This method makes it possible to prevent the payment of a play fee that exceeds the upper limit of credits that can be accepted by the game device 300.

[0135] The game device 300 (G02) transmits information about the cancellation amount along with the acceptance result (acceptance refusal) to the server 200. The server 200 transmits the cancellation instruction and information about the cancellation amount to the payment system 102. The payment system 102 may cancel the payment settlement for the cancellation amount. For example, in the above case, the cancellation amount may be the full amount of the play fee paid by cashless payment (500 yen), or the amount corresponding to the amount exceeding the upper limit of the credit counter (600 yen - 500 yen = 100 yen).

[0136] [Variation 4] In the present embodiment, a system that provides an existing cashless payment service using two-dimensional code reading or a credit card has been described as the payment system 102. As a variation, the server 200 may have the function of the payment system 102.

[0137] More specifically, the server 200 and the game device 300 are assumed to be operated by manufacturer M. Manufacturer M provides its own payment service, which allows the payment of play fees for its game devices 300 by cashless payment, by providing the server 200 with the functionality of the payment system 102. In such a case, the player terminal 101 accesses the server 200 to pay the play fee. When the server 200 has completed payment of the play fee, it transmits permission to play to the game device 300. In this manner, the player may be allowed to play on the game device 300 after paying the play fee by cashless payment.

[0138] [Variation 5] In this embodiment, the two-dimensional code records a gaming machine ID and address information for accessing the payment system 102. When the player terminal 101 captures an image of the two-dimensional code, it transmits a payment request to the payment system 102. The payment system 102, having received the payment request, transmits an amount request to the server 200. The server 200 receives information (amount response) about the play fee for the gaming device 300 detected from the amount information, and transmits it to the payment system 102. The payment system 102 then transmits a payment confirmation to the player terminal 101 and receives payment authorization from the player terminal 101. The payment system 102 has been described as completing payment of the play fee for the gaming device 300 when it receives payment authorization in this manner. As a variation, the play fee for the gaming device 300 may be recorded in the two-dimensional code. In this case, the payment system 102 may complete payment of the play fee when it receives a payment request from the player terminal 101.

[0139] More specifically, an example will be described in which a player (0001) pays a play fee of "300 yen" by cashless payment using service A to play on game device 300 (G01). Game device 300 (G01) displays a two-dimensional code on its display. The two-dimensional code records the game machine ID "G01", address information (address S) of payment system 102S, and the play fee of "300 yen" per play on game device 300 (G01).

[0140] The player (0001) uses the player terminal 101 to capture an image of the two-dimensional code while the application software for service A is running. The player terminal 101 acquires the game machine ID "G01", address S, and the play fee of "300 yen" for the game device 300 (G01) from the two-dimensional code. The player terminal 101 transmits a payment request to the payment system 102S according to the address S, along with the game machine ID "G01", player ID "0001", and the play fee of "300 yen" for the game device 300 (G01).

[0141] The payment system 102S receives a payment request or the like from the player terminal 101. The payment system 102S completes payment settlement for the player (0001) based on the information on the play fee of "300 yen" for the game device 300 (G01). The payment system 102S transmits a payment completion notice to the server 200 along with the game machine ID "G01" and the player ID "0001". In this way, by recording the play fee for the game device 300 in the two-dimensional code, the payment system 102S can complete payment settlement for the play fee when it receives a payment request from the player terminal 101.

[0142] 100 Game system, 101 Player terminal, 102 Payment system, 103 Communication network, 200 Server, 210 Communication unit, 211 Receiving unit, 212 Transmitting unit, 220 Data storage unit, 230 Data processing unit, 231 Play permission management unit, 232 History registration unit, 233 Reception result management unit, 234 Report request management unit, 235 Payment management unit, 300 Game device, 310 User interface processing unit, 311 Input unit, 312 Output unit, 320 Communication unit, 321 Receiving unit, 322 Transmitting unit, 330 Data storage unit, 340 Data processing unit, 341 Code generation unit, 342 Reception result management unit, 343 History registration unit, 344 Game control unit, 400 Transmission and reception history information, 500 Reception history information, 600 Pairing information

Claims

1. A game system comprising a server and a game device, wherein when a payment request for a play fee on said game device is sent from a player's communication terminal to the payment system, said payment system executes payment of said play fee and notifies said server of payment completion, said server comprising: a completion notification receiving unit that receives said payment completion from said payment system; a permission sending unit that sends permission to play to said game device on condition that said payment completion has been received; and a payment management unit that instructs the payment system to cancel payment, said game device comprising: a permission receiving unit that receives said permission to play from said server; a game control unit that controls the progress of the game on condition that said permission to play has been received; and a result sending unit that, when said permission receiving unit fails to receive said permission to play, sends a reception result indicating non-reception to said server, said server further comprising: a result receiving unit that receives the reception result from said game device, and when said payment management unit is notified from said game device that said reception result indicates non-reception, it instructs said payment system to cancel payment of said play fee.

2. A game system comprising a server and a game device, wherein when a payment request for payment of a play fee for said game device is sent from a player's communication terminal to the payment system, said payment system executes payment of said play fee and notifies said server of payment completion, said server comprising: a completion notification receiving unit that receives said payment completion from said payment system; a permission sending unit that sends permission to play to said game device on condition that said payment completion has been received; and a payment management unit that instructs cancellation of payment in said payment system, said game device comprising: a permission receiving unit that receives said permission to play from said server; a game control unit that controls the progress of the game on condition that said permission to play has been received; and a result sending unit that sends a reception result indicating whether or not said permission to play was received to said server, said server further comprising: a result receiving unit that receives said reception result from said game device, and said payment management unit does not instruct said payment system to cancel payment of said play fee until a predetermined time has elapsed since the transmission of said permission to play, even if it is unable to receive the reception result from said game device.

3. The game system described in claim 1 or 2, wherein the server further includes a request sending unit that sends a report request to the game device regarding whether or not the play permission has been received, and the game device further includes a request receiving unit that receives the report request, and the request sending unit of the server sends the report request to the game device when the result receiving unit fails to receive the reception result within a predetermined time after the play permission has been sent, and the result sending unit of the game device sends the reception result to the server when the request receiving unit receives the report request.

4. The game system described in claim 3, wherein the game device further includes a game machine ID that identifies the game device in a format specified by the payment system, and a code generation unit that generates a two-dimensional code that includes the play fee, and when the player's communication terminal captures an image of the two-dimensional code, it transmits a payment request for the play fee to the payment system.

5. The game system described in claim 4, wherein the server further includes a data storage unit that stores a transmission / reception history of the play permission and the reception result, and when the transmission / reception history is referenced from an operator's communication terminal, if the transmission / reception history indicates that the play permission has been sent and the reception result has not yet been received, the operator's communication terminal instructs the server to cancel payment of the play fee to the payment system.

6. The game system described in claim 3, wherein the server further includes a player management unit that registers a player ID that identifies the player and a game machine ID that identifies the game device in pairing, and on condition that the player ID and the game machine ID have been registered in pairing, the player's communication terminal transmits a payment request for the play fee to the payment system.

7. A server including: a completion notification receiving unit that receives from a payment system notification that payment of a play fee for a game device has been completed; a permission sending unit that sends permission to play to the game device on the condition that the payment completion has been received; a result receiving unit that receives from the game device a reception result indicating that the permission to play has not been received; and a payment management unit that instructs the payment system to cancel payment, wherein the payment management unit instructs the payment system to cancel payment of the play fee when notified from the game device that the reception result indicates that the permission has not been received.

8. A server comprising: a completion notification receiving unit that receives from a payment system the completion of payment of a play fee for a game device; a permission sending unit that sends permission to play to the game device on the condition that the payment completion has been received; a result receiving unit that receives from the game device a reception result indicating whether or not the permission to play was received; and a payment management unit that instructs the payment system to cancel payment, wherein the payment management unit does not instruct the payment system to cancel payment of the play fee until a predetermined time has elapsed since the transmission of the play permission, even if the reception result is not received from the game device.

9. A game device comprising: a permission receiving unit that receives permission to play sent from a server on condition that completion of payment of a play fee via a payment system has been received; a game control unit that controls the progress of a game on condition that the permission to play has been received; a request receiving unit that receives a report request from the server inquiring whether the permission to play has been received; and a result sending unit that sends a reception result to the server indicating whether the permission to play has been received, wherein the permission receiving unit records in a specified memory area when the permission to play is received, and the result sending unit sends to the server a reception result indicating that the permission to play has been received, when the permission to play is received, and when the report request is received, refers to the memory area and sends to the server a reception result indicating whether the permission to play has been received or not.

Images