Game system, server, and game device

Abstract

To appropriately process settlement when a communication trouble occurs between a server and a game device.SOLUTION: In a game system including a server and a game device, the server includes a completion notification reception part for receiving settlement completion from a settlement system, a permission transmission part for transmitting play permission to the game device on condition that the settlement completion is received, a settlement management part for instructing cancellation of settlement in the settlement system, and a result reception part for receiving a reception result from the game device. The game device includes a permission reception part for receiving the play permission from the server, a game control part for controlling the progress of the game on condition that the play permission is received, and a result transmission part for transmitting a reception result indicating non-reception to the server when the permission reception part cannot receive the play permission. A settlement management part of the server instructs the settlement system to cancel the settlement of the play charge when non-reception is notified as a reception result from the game device.SELECTED DRAWING: Figure 7

Description

[Technical Field]

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

[0002] In recent years, cashless payments have become commonplace, using communication devices such as smartphones to read 2D codes or operate applications. 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"). Let us 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. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Patent No. 7251169 [Patent Document 2] Patent No. 7260023 [Patent Document 3] Patent No. 7272499 Summary of the Invention [Problem to be solved by the invention]

[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. [Means for solving the problem]

[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. [Effects of the Invention]

[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. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 2 is a hardware configuration diagram of the game system. [Figure 2] FIG. 10 is a sequence diagram showing the flow of a settlement process when communication between the server and the game device is normal. [Figure 3] FIG. 10 is a data structure diagram of transmission / reception history information. [Figure 4] FIG. 10 is a data structure diagram of reception history information. [Figure 5] FIG. 2 is a functional block diagram of a server. [Figure 6] FIG. 2 is a functional block diagram of the game device. [Figure 7] FIG. 10 is a sequence diagram showing the flow of a settlement process when communication from the server to the game device is interrupted. [Figure 8] FIG. 10 is a sequence diagram showing the flow of a settlement process when a communication interruption occurs from the game device to the server. [Figure 9] FIG. 10 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. [Figure 10] FIG. 10 is a hardware configuration diagram of a game system when pairing registration is performed on a server. [Figure 11] FIG. 10 is a sequence diagram showing the flow of a payment process when pairing registration is performed in the server. [Figure 12] FIG. 10 is a data structure diagram of pairing information. [Figure 13] FIG. 10 is a sequence diagram showing the flow of a settlement process when a credit card acceptance suspension process is executed in the gaming device. DETAILED DESCRIPTION OF THE INVENTION

[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] FIG. 1 is a diagram showing the hardware configuration of a game system 100. As shown in FIG. 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 device 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 notice (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 the two-dimensional code may be displayed on each game device 300 as a sticker or the like, rather than displayed on the screen, as long as it is associated with each individual game device 300.

[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 to the server 200 a notification that payment of the play fee for the game device 300a has been completed (hereinafter referred to as "payment completion"). Upon receiving the payment completion for the game device 300a, the server 200 transmits to the game device 300a a notification permitting the player who has paid the play fee to play (hereinafter referred to as "play permission"). Upon receiving the play permission, the game device 300a activates its internal mechanism. This allows the player who has paid the play fee by 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 game device 300 (hereinafter referred to as "game device 300 (G01)") assigned the game device ID "G01" displays a two-dimensional code. The two-dimensional code records the game 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 the address information of 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 requesting information on the play fee for the game device 300 (G01) (hereinafter referred to as an "amount request") 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 to complete payment of the play fee of "300 yen" 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 notifying 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 "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 notification of payment completion, etc. from the payment system 102S. The server 200 transmits permission to play, 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 permission to play 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 player ID "0001" and the date and time when permission to play was received in the reception history information (described later) (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 enables 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, and calculates the total balance relative to the base amount (0 yen). At midnight on July 1st, the payment system 102S reflects the total balance for July 1st in user C's balance as of June 30th, and calculates 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] Assume that player (0001) used service A on July 1st, and only paid the play fee of "300 yen" for the 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 the game device 300 (G01) is normal, the payment process is executed in the game system 100 according to the above flow.

[0037] FIG. 3 is a diagram showing the data structure of the transmission / reception history information 400. As shown in FIG. The server 200 generates 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] FIG. 4 is a diagram showing the data structure of the reception history information 500. In the reception history information 500 of each game device 300, the date and time when 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 the reception history information 500 of the game device 300 (G01). Fig. 4 shows that the 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 / 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 player (0002) pays the play fee by cashless payment to play on the game device 300 (G01) after 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 the 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." This means that no communication interruption occurred while permission to play for player (0003) was being transmitted from the server 200 to the 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 described. As shown in FIG. 4, the game device 300 (G01) receives 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 occurs 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 to the game device 300 (G01) along with the player ID "0003." 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 is assumed to be "one minute" in this embodiment.

[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" field 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 date and time of reception in the "reception result reception date and time" field of 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 the play permission was transmitted, a report request is transmitted to the game device 300. Therefore, the date and time that is approximately one minute after the play permission transmission date and time is registered in the "reception result reception date and time" field.

[0050] Although details will be described later, a report request is also sent when the game device 300 fails to receive permission to play. In this case, the game device 300 that 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. The server 200 that received the reception result (not received) instructs the payment system 102 to cancel payment of the play fee.

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

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

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

[0054] Next, a detailed description will be given of the configurations of the server 200 and the game device 300. FIG. Each component of the server 200 is realized 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 them, as well as software stored in the storage devices and supplying processing instructions to the computing units. The computer program may be composed of device drivers, an operating system, various application programs located above them, and libraries that provide common functions to these programs. Each block described below represents a functional block, not a hardware configuration. The same applies to each component of the game device 300 described in relation to Figure 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 the amount request together with the game machine ID "G01" from the payment system 102. The receiving unit 211 also receives a payment completion notification together with the game machine ID and the 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 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 receiving 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 transmitting unit 212 to transmit an amount response. When the receiving unit 211 receives a payment completion notification, the play permission management unit 232 instructs the transmitting 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 play permission was transmitted to the game device 300 in the transmission and reception history information 400. The play permission management unit 232 also notifies the reception result management unit 234 that play permission has been transmitted. In response to the instruction from the play permission management unit 232, the history registration unit 233 registers the date and time when play permission was transmitted to the transmission and reception history information 400, along 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] FIG. 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 processing related to the user interface, 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 executes various processes based on the 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 receives 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. A display (not shown) is provided on the game device 300 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 generating unit 341 , a reception result managing unit 342 , a history registering 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 reception unit 321 receives permission to play, etc., the reception result management unit 342 instructs the transmission 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 permission to play 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 permission to play was received in the reception history information 500. Furthermore, after instructing the transmission of 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 the 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 transmission unit 322 to transmit to the server 200 a reception result according to whether or not the 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 the settlement process when a communication interruption occurs between the server 200 and the game device 300 in the game system 100 of this embodiment. Fig. 7 is a sequence diagram showing the flow of payment processing when communication from the server 200 to the game device 300 is interrupted. 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 (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 a payment completion notification 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 the player (0002) transmits the play permission, a communication interruption occurs between the server 200 and the game device 300 (G01) before the play permission reaches the game device 300 (G01). As a result, the receiving unit 321 of the game device 300 (G01) cannot receive the play permission. In other words, the transmitting unit 322 of the game device 300 (G01) cannot transmit the 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 the 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 together with the player ID "0002" 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 for player (0002) was received is registered (S40). As described above, the receiving unit 321 has not received permission to play for player (0002). Therefore, the date and time when permission to play for 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 settlement system 102S receives the cancellation instruction along with the player ID "0002" from the server 200. The settlement 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 the server 200 to the game device 300. In this case, the game device 300 is unable to receive permission to play and is therefore unable to transmit a reception result to the server 200. The server 200 is unable to receive the reception result even one minute after transmission of permission to play, and therefore transmits a report request to the game device 300. Upon receiving the report request, the game device 300 transmits a 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.

[0079] By canceling the payment using this method, it is possible to prevent a situation in which payment of a player's play fee is finalized even when the player is unable to play on the game device 300. 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 sends a report request, and only sends 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 send 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] Fig. 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 processes from S10 to S28 in the player terminal 101, the payment system 102S, the server 200, and the game device 300 (G01) are the same as the processes 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 drives the internal mechanism to start the game (S34). This enables 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 the 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 together with the player ID "0003" from the server 200. The reception result management unit 342 refers to 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 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 game system 100 according to the present invention has been described above. In recent years, cashless payment using communication terminals such as smartphones has become widespread. Cashless payment is also used to pay play fees for game devices 300. Game 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 game devices 300 to be installed in any layout without being restricted by the routing of communication cables. However, if a game device 300 is installed in the shadows, communication between the server 200 and the game device 300 may become unstable. In such cases, problems may occur, such as the player being unable to start playing even though the player has 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 the server 200 is transmitting permission to play to the game device 300. The game device 300 cannot receive permission to play from the server 200, and therefore cannot start the game.

[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 can prevent improper payment settlements, such as when a play fee paid by cashless payment is confirmed 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 therefore 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 therefore 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 the 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] Assume 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 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 variant, an employee (hereinafter referred to as the "operator") of the facility where the game device 300 is installed may be able to directly instruct the server 200 to cancel the payment using a communication terminal (hereinafter referred to as the "operator terminal") (not shown) owned by the employee.

[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 or she has paid the play fee to the game device 300 (G01) by cashless payment but is unable to start playing, and would like a refund of the play fee. At this time, the operator uses his or her 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 the transmission / reception history information 400 of the game device 300 with the specified game machine 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 the payment settlement 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 the game machine ID "G01" and confirms that no date and time is registered in the "Reception result reception date and time" field for the player ID "0004." The operator enters the 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 the payment settlement 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 transmission unit 212 to send the cancellation instruction together with the player ID "0004". The transmission unit 212 transmits 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 requests 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 receive 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 is sent. In such a case, the player cannot play on the game device 300, so 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 device 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 for whom 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 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 explained that the payment system 102 transmits a payment completion notice to the server 200 once payment of the play fee has been completed. As a variation, the payment of the play fee may be carried out 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 diagram showing the hardware configuration 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 existing cashless payment services using credit cards.

[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 the display. The player (0005) captures an image of 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 captured 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 and the like 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 for 300 yen" or "2 plays for 500 yen." It is assumed that player (0005) selects the "1 play for 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 processes from S22 to S36 in the payment system 102T, the server 200, and the game device 300 (G01) are the same as the processes 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 this embodiment, the description has been given assuming that the play fee for the game device 300 is paid by cashless payment. As a variation, the game device 300 also accepts payment of the play fee in cash (coins). Suppose that coins are inserted into the game device 300 between the time when 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, and the time when permission to play arrives at the game device 300. In this case, the game device 300 may be able to cancel payment of the play fee.

[0122] More specifically, the game 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 game device 300, regardless of whether the payment is cashless or in 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 where 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 sends a payment completion notice to the server 200, the information on the paid play fee, "100 yen," is also sent along with the game machine ID and player ID. Similarly, when the server 200 sends permission to play, the information on the paid play fee, "100 yen," is also sent 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 game device 300 (G02) can accept up to 5 credits at a time. That is, the upper limit of the play fee that the game 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 game 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 that the play permission has not been accepted (hereinafter referred to as a "reception result (acceptance refusal)"). Note that when the server 200 receives a reception result (acceptance refusal) from the game device 300 (G02), the server 200 transmits a cancellation instruction to the payment system 102, in the same way as when a reception result (not received) has been received.

[0126] 13 is a sequence diagram showing the flow of the payment process when the credit card acceptance stop process 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 contains 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 or the like from the player terminal 101. The payment system 102S transmits an amount request together with the game machine ID "G02" to the server 200 (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 them 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 the 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) also transmits information about the cancellation amount along with the acceptance result (acceptance refusal) to the server 200. The server 200 also transmits information about the cancellation amount along with the cancellation instruction to the payment system 102. The payment system 102 may cancel the payment settlement by 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 this embodiment, a system that provides existing cashless payment services using two-dimensional code reading or credit cards 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 a manufacturer M. By providing the server 200 with the functionality of a payment system 102, the manufacturer M provides a unique payment service that allows the play fee for its game device 300 to be paid by cashless payment. 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. Upon receiving the payment request, the payment system 102 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 two-dimensional code may record the play fee for the gaming device 300. 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, let us take as an example a situation in which a player (0001) pays a play fee of "300 yen" by cashless payment using service A to play on the game device 300 (G01). The 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 the payment system 102S, and the play fee per play on the game device 300 (G01), "300 yen".

[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. [Explanation of symbols]

[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 server and a game device are provided, when a payment request for a play fee for said game device is transmitted from the communication terminal of the player to a payment system, said payment system executes payment for said play fee and notifies said server of completion of payment; The server a completion notification receiving unit that receives the completion of the payment from the payment system; a permission sending unit that sends a play permission to the game device on condition that the payment completion has been received; a payment management unit that instructs cancellation of payment in the payment system; The game device includes: a permission receiving unit for receiving the permission to play from the server; a game control unit that controls the progress of the game on the condition that the permission to play has been received; a result sending unit that sends a reception result indicating non-reception to the server when the permission receiving unit fails to receive the play permission, The server a result receiving unit that receives the reception result from the game device, When the game device notifies the payment manager that the reception result is non-reception, the payment manager instructs the payment system to cancel the payment of the play fee.

2. A server and a game device are provided, when a payment request for a play fee for said game device is transmitted from the communication terminal of the player to a payment system, said payment system executes payment for said play fee and notifies said server of completion of payment; The server a completion notification receiving unit that receives the completion of the payment from the payment system; a permission sending unit that sends a play permission to the game device on condition that the payment completion has been received; a payment management unit that instructs cancellation of payment in the payment system; The game device includes: a permission receiving unit for receiving the permission to play from the server; a game control unit that controls the progress of the game on the condition that the permission to play has been received; a result sending unit that sends a reception result indicating whether or not the play permission has been received to the server, The server a result receiving unit that receives the reception result from the game device, A game system in which 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 play permission was sent, even if the reception result cannot be received from the game device.

3. The server a request sending unit that sends a report request regarding whether the permission to play has been received to the game device, The game device includes: a request receiving unit that receives the report request, 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 transmitting the play permission; 3. The game system according to claim 1, wherein the result transmitting unit of the game device transmits the received result to the server when the request receiving unit receives the report request.

4. The game device includes: The game device further includes a game machine ID that identifies the game device in a format designated by the payment system, and a code generation unit that generates a two-dimensional code that includes the play fee; 4. The game system according to claim 3, wherein the communication terminal of the player transmits a payment request for the play fee to the payment system when the two-dimensional code is imaged.

5. The server a data storage unit that stores a transmission / reception history of the play permission and the reception result, When the transmission / reception history is referred to from the operator's communication terminal, if the transmission / reception history indicates that the play permission has been transmitted and the reception result has not yet been received, 5. The game system according to claim 4, wherein the operator's communication terminal instructs the server to cancel payment of the play fee to the payment system.

6. The server a player management unit that performs pairing registration of a player ID that identifies the player and a game machine ID that identifies the game machine, 4. The game system according to claim 3, wherein, on condition that the player ID and the game machine ID are paired and registered, the communication terminal of the player transmits a payment request for the play fee to the payment system.

7. a completion notification receiving unit that receives a completion of payment of a play fee for the game device from the payment system; a permission sending unit that sends a play permission to the game device on condition that the payment completion has been received; a result receiving unit that receives from the game device a reception result indicating that the play permission has not been received; a payment management unit that instructs cancellation of payment in the payment system; The server, wherein the settlement management unit instructs the settlement system to cancel the settlement of the play fee when the game device notifies the server that the game has not been received as the reception result.

8. a completion notification receiving unit that receives a completion of payment of a play fee for the game device from the payment system; a permission sending unit that sends a play permission to the game device on 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 play permission has been received; a payment management unit that instructs cancellation of payment in the payment system; The server, wherein the payment management unit does not instruct the payment system to cancel the payment of the play fee until a predetermined time has elapsed since the transmission of the play permission, even if the reception result cannot be received from the game device.

9. a permission receiving unit that receives a play permission transmitted from the server on condition that a payment completion of the play fee through the payment system has been received; a game control unit that controls the progress of the game on the condition that the permission to play has been received; a request receiving unit that receives a report request from the server inquiring whether the play permission has been received; a result sending unit that sends a reception result indicating whether or not the play permission has been received to the server; the permission receiving unit, when receiving a play permission, records in a predetermined storage area that the play permission has been received; the result sending unit, when the play permission is received, sends to the server a reception result indicating that the permission has been received, and, when the report request is received, refers to the storage area and sends to the server a reception result indicating whether the play permission has been received or not.

Images