Game device and game system

Abstract

The present invention transfers, with a simple configuration, unspent credits between game devices. In the present invention, a plurality of game devices are installed and connected to each other via a network. The game devices each comprises: a first function for receiving a credit transfer instruction from a player and transmitting unspent credits directly or via another game device to a game device to be used by the player in the future; and a second function for receiving a credit acquisition instruction from a player and acquiring unspent credits transmitted from a game device played by the player in the past.

Description

Game device and game system

[0001] The present invention relates to a game device installed in a game center or the like.

[0002] Many game centers are equipped with crane game devices (article acquisition game devices). A stage (game field) is provided inside the housing of the crane game device, on which prizes (articles) such as plush toys and snacks are placed. A player operates an article holding unit such as a crane by making full use of horizontal direction buttons, vertical direction buttons, and the like. If the player can grab a prize with the crane and move the prize to a drop opening, the player can obtain the prize.

[0003] A player obtains credits by paying a play fee before playing. A credit is a right to challenge the crane game, and when the player has 3 credits, the player can challenge the crane game 3 times. Since the prizes of the crane game device cannot be obtained easily, play fees for several credits are often paid in a lump (see Patent Document 1).

[0004] Japanese Unexamined Patent Application Publication No. 2019-201953

[0005] When credits are purchased in a lump, some of the credits may remain unconsumed when the targeted prize is obtained. From the store's perspective, it is desirable for players to continue challenging the crane game using the unconsumed credits, but once their goal is achieved, the players may not feel like continuing to play further. Under such circumstances, there have been few proposals made regarding how to handle unconsumed credits at present.

[0006] The present invention has been made in view of such circumstances, and a main object thereof is to provide a technique for transferring unconsumed credits between game devices with a simple configuration.

[0007] In one embodiment of the present invention, multiple game devices are installed and connected to each other via a network. The game device includes a first function that receives a credit transfer instruction from a player and transmits unused credits directly or via another game device to a game device that the player will play in the future, and a second function that receives a credit acquisition instruction from a player and acquires unused credits transmitted from a game device that the player has played in the past.

[0008] A game system in one aspect of the present invention comprises a plurality of game devices connected to each other via a network. Among the plurality of game devices are a first device and a second device which is played after the first device. The first device includes a transfer receiving unit that receives a credit transfer instruction from a player, and a credit transmission unit that, after receiving a transfer instruction, transmits unused credits to the second device directly or via another game device. The second device includes an acquisition receiving unit that receives a credit acquisition instruction from a player, and a credit acquisition unit that, after receiving an acquisition instruction, acquires unused credits transmitted from the first device.

[0009] According to the present invention, unused credits can be easily transferred between game devices with a simple configuration.

[0010] This is a hardware configuration diagram of the game system. This is a functional block diagram of the game device. This is a sequence diagram showing the flow when a credit transfer is successful. This is a screen diagram of the transfer selection screen. This is a screen diagram of the owner input screen. This is a data structure diagram of the transfer waiting information. This is a screen diagram of the usage selection screen. This is a screen diagram of the transfer quantity selection screen. This is a screen diagram of the acquisition quantity selection screen. This is a sequence diagram showing the flow when a credit transfer fails. This is a sequence diagram showing the case when the received result is not received when a credit transfer is successful. This is a sequence diagram showing the case when the received result is not received when a credit transfer fails. This is a sequence diagram showing the processing flow in modified example 2. This is a sequence diagram showing the processing flow in modified example 3.

[0011] Figure 1 is a hardware configuration diagram of the game system 100. The game system 100 consists of six game machines 101a, 101b, ..., 101f (hereinafter collectively referred to as "game machine 101" when referring to them together or without distinction) installed in the game center C. In Figure 1, six game machines 101 are shown as an example, but the number of game machines 101 that make up the game system 100 is not particularly limited as long as there are multiple machines. In the following explanation, game machine 101 refers to a crane game machine.

[0012] Each game device 101 is wirelessly connected to each other using a short-range wireless communication standard such as ZigBee®. Each game device 101 can exchange data with other game devices 101 directly or through one or more game devices 101. This feature is used to transfer unused credits to other game devices 101.

[0013] A brief explanation of how to use the game system 100 is provided below. Player P, who has paid a play fee to the game device 101a, acquires multiple credits and attempts to win a prize (plays the game). If Player P acquires a prize (clears the game) faster than expected, credits will remain (hereinafter referred to as "unspent credits").

[0014] The operator of Game Center C pre-designates one of the game machines 101a, 101b, ..., 101f as the representative machine (described later). The game can also be played on the representative machine. In this embodiment, game machine 101c is designated as the representative machine. Player P can deposit any unused credits remaining from game machine 101a into game machine 101c (the representative machine). Note that any of the game machines 101a, 101b, ..., 101f may have the function to be designated as the representative machine. Furthermore, it may be possible to pre-configure a specific game machine 101 to be permanently designated as the representative machine. In addition, the game system 100 may be composed of game machines 101 that have the function to be designated as the representative machine and game machines 101 that do not.

[0015] After depositing unused credits, Player P will attempt to win prizes at another game machine 101b. Player P can withdraw the unused credits that were deposited at game machine 101b. Player P can then use the withdrawn unused credits to attempt to win prizes (play).

[0016] Unless otherwise noted, the game device 101a that player P plays first and which is the source of the credit transfer will be referred to as the "transfer device 200" (first device). The game device 101b that player P plays after the transfer device 200 and which is the destination of the credit transfer will be referred to as the "acquisition device 300" (second device). The game device 101c where the credit is saved will be referred to as the "representative device 400".

[0017] From here on, we will explain the details of transferring unused credits, focusing on the transfer device 200, the acquisition device 300, and the representative device 400, while touching upon the differences in the processes performed by these three game devices 101.

[0018] Figure 2 is a functional block diagram of the game device 101. Each component of the game device 101 is realized by hardware including a CPU (Central Processing Unit) and various coprocessors, memory and storage devices, and wired or wireless communication lines connecting them, as well as software stored in the storage devices that supplies processing instructions to the arithmetic units. The computer program may consist of device drivers, an operating system, various application programs located at a higher layer, and libraries that provide common functions to these programs. The blocks described below represent functional units, not hardware units.

[0019] All game devices 101 can function as either a transfer device 200, an acquisition device 300, or a representative device 400. The blocks described below are common to all game devices 101.

[0020] The game device 101 includes a user interface processing unit 110, a communication unit 120, a data storage unit 130, and a data processing unit 140. The user interface processing unit 110 accepts operations from player P via various input devices and is responsible for processing related to the user interface, such as image display and sound output. The communication unit 120 is responsible for communication processing with other game devices 101. The data storage unit 130 stores transfer waiting information and credit information.

[0021] Transfer waiting information is used by the representative device 400 to manage unused credits. In this embodiment, only the game device 101 designated as the representative device 400 utilizes the transfer waiting information. Credit information manages the number of credits available on that device. That is, all game devices 101 manage the available credits as credit information.

[0022] The data processing unit 140 performs various processes based on the data input from the user interface processing unit 110, the data received by the communication unit 120, and the data stored in the data storage unit 130. The data processing unit 140 also functions as an interface for the user interface processing unit 110, the communication unit 120, and the data storage unit 130.

[0023] The user interface processing unit 110 includes an input unit 111 that receives input from player P, and an output unit 112 that outputs various information such as images and sounds to player P. Player P plays the crane game by operating input devices such as buttons and levers (not shown) installed as the input unit 111 on the game device 101.

[0024] The game device 101 is also equipped with a display (not shown). Various screens, which will be described later, are displayed on the display. The player P performs operations such as credit transfer by selecting buttons displayed on the various screens. In other words, the display serves as both an input unit 111 and an output unit 112.

[0025] The communication unit 120 includes a transmission unit 121 that transmits various data to other game devices 101 and a reception unit 122 that receives data from other game devices 101.

[0026] The data processing unit 140 includes a transfer acceptance unit 141, an acquisition acceptance unit 142, a credit management unit 143, a game control unit 144, a result management unit 145, and a request management unit 146.

[0027] The transfer reception unit 141 receives a transfer instruction (described later) from player P at the transfer device 200 and deposits the unused credits into the representative device 400. The acquisition reception unit 142 receives an acquisition instruction (described later) from player P at the acquisition device 300 and withdraws the unused credits from the representative device 400.

[0028] The credit management unit 143 registers the number of unused credits deposited from the transfer device 200 in the transfer waiting information on the representative device 400. When the credit management unit 143 receives a withdrawal instruction from the acquisition device 300, it deletes the number of unused credits from the transfer waiting information. In this way, the transfer waiting information functions as a ledger of unused credits (usable credits) deposited by each player.

[0029] When the credit management unit 143 of the representative device 400 is instructed to withdraw unused credits, it grants unused credits (permission to acquire unused credits) to the acquisition device 300.

[0030] The acquisition receiving unit 142 of the acquisition device 300 registers the credit in its own credit information (not shown) when it has successfully withdrawn a credit (successful credit transfer). The credit information indicates the number of credits available for use in the acquisition device 300.

[0031] The game control unit 144 of the acquisition device 300 starts the game when instructed to use credits. Player P can try to acquire prizes using the acquisition device 300 up to the number of remaining credits registered in the credit information.

[0032] Furthermore, since wireless communication may become unstable within Game Center C, there is a possibility that the acquisition device 300 may fail to withdraw unused credits (credit transfer failure). To prepare for such cases, the result management unit 145 of the acquisition device 300 sends information indicating the success or failure of the withdrawal of unused credits (hereinafter referred to as "received result") to the representative device 400. When the credit management unit 143 of the representative device 400 receives a received result (hereinafter referred to as "received result (not received)") notifying that it was not able to receive credits despite requesting their withdrawal, it updates the transfer waiting information, but the details will be described later.

[0033] Temporary instability in wireless communication may cause failure to transmit the received results. In this case, the request management unit 146 of the representative device 400 requests the acquisition device 300 to retransmit the received results (report request). Upon receiving the report request, the acquisition device 300 retransmits the received results (described later).

[0034] The following explains the difference in processing when the transfer of unused credits is successful and when it fails. First, referring to Figures 4 to 7 as appropriate, we will explain the process when the transfer of unused credits is successful, following Figure 3.

[0035] First, let's assume that one credit costs 100 yen. When player P pays 1000 yen at game device 101a (transfer device 200), player P receives 10 credits and can play 10 times.

[0036] Let's assume that the prize was obtained by spending 2 credits (S10). There are 8 credits remaining in the transfer device 200. So, let's assume that player P deposits the 8 unused credits.

[0037] Player P instructs the transfer selection screen 500 (see Figure 4) displayed on the transfer device 200 to deposit credits, and then enters the player ID on the owner input screen 510 (see Figure 5) that is displayed next.

[0038] First, immediately after player P acquires a prize, the transfer selection screen 500 shown in Figure 4 is displayed (S12). The transfer selection screen 500 displays the number of unused credits "8" along with a transfer permission button 501 and a transfer rejection button 502. To deposit credits, select the transfer permission button 501. To cancel the deposit, select the transfer rejection button 502. At this time, the 8 unused credits remain in the transfer device 200, and player P can continue to play 8 more times. Alternatively, an amount equivalent to 8 credits (800 yen) may be refunded to player P.

[0039] Next, the owner input screen 510 shown in Figure 5 is displayed. Let's assume that Player P's Player ID is "A0001". Player P selects the number button 511 and enters the Player ID. The entered number is displayed in the ID display field 512. After completing the input, Player P selects the confirm button 513. Player P can correct the entered number using the correction button 514. Player P can return to the previous screen (transfer selection screen 500) by selecting the cancel button 515.

[0040] When the confirmation button 513 is selected, the deposit of unused credits is executed. Specifically, a transfer instruction specifying the player ID and the number of unused credits (8 credits) is sent to the representative device 400 (game device 101c) (S14). The credit management unit 143 of the representative device 400 associates the player ID with the number of unused credits and registers it in the transfer waiting information 600 (S16). With this, the deposit of unused credits from the transfer device 200 to the representative device 400 is completed.

[0041] FIG. 6 is a diagram of the data structure of transfer waiting information 600. The transfer waiting information 600 is stored in the data storage unit 130 of the representative device 400. As shown in FIG. 6, in addition to the player P, the number of unused credits for four people is registered in the transfer waiting information 600. The representative device 400 (game device 101c) collectively accepts unused credits generated in all game devices 101, registers them in the transfer waiting information 600, and manages them. The credit management unit 143 updates the transfer waiting information 600 each time credit deposit and withdrawal are executed.

[0042] Next, it is assumed that the player P (A0001) withdraws all 8 deposited credits at the game device 101b (acquisition device 300).

[0043] Also on the acquisition device 300, the owner input screen 510 (see FIG. 5) is displayed. The player P inputs the player ID on the owner input screen 510. A usage selection screen 520 is displayed after the owner input screen 510. The player P instructs the withdrawal of unused credits on the usage selection screen 520.

[0044] On the owner input screen 510 (FIG. 5), the player P inputs the player ID (S18). An inquiry about the stored number of credits is transmitted to the representative device 400 together with the player ID (S20).

[0045] The credit management unit 143 of the representative device 400 refers to the transfer waiting information 600, and detects the credit number "8" associated with the player ID "A0001". "8" is notified as the stored number (S22).

[0046] Next, the acquisition device 300 displays a usage selection screen 520 (see FIG. 7). On the usage selection screen 520, a usage approval button 521 and a usage rejection button 522 are displayed together with the credit number "8". When the player P wishes to withdraw the credits, the player selects the usage approval button 521 (S24). When the usage rejection button 522 is selected, the usage selection screen 520 is closed without withdrawing the credits.

[0047] When the player P performs the series of operations up to this point (acquisition instruction), credits are withdrawn from the representative device 400 to the acquisition device 300. Specifically, a withdrawal request for unconsumed credits is transmitted to the representative device 400 together with the player ID input by the player P (S26).

[0048] Upon receiving the player ID and the withdrawal request, the credit management unit 143 of the representative device 400 deletes the player ID and the credit number "8" from the transfer waiting information 600 (S28). The credit management unit 143 records the player ID and the credit number deleted from the transfer waiting information 600 in the cache memory in case the acquisition device 300 cannot withdraw the credits due to unstable communication (details will be described later) (S30). After that, the unconsumed credits (8 credits) are transmitted to the acquisition device 300 (S32).

[0049] The acquisition reception unit 142 of the acquisition device 300 receives the unconsumed credits (8 credits) and registers them in the credit information. As described above, the withdrawal of unconsumed credits from the representative device 400 to the acquisition device 300 (credit acquisition) is completed (S34).

[0050] The result management unit 145 of the acquisition device 300 transmits a reception result indicating that the credits have been successfully received (hereinafter referred to as "reception result (received)") (S36). Upon receiving the reception result (received), the credit management unit 143 of the representative device 400 deletes the player ID and the credit number recorded in the cache memory (S38). Thereby, the registered content of the transfer waiting information 600 is committed (finalized). That is, the 8 credits managed by the representative device 400 are extinguished.

[0051] On the other hand, the game control unit 144 of the acquisition device 300 starts a game using the remaining credits (S40). When the credit transfer to the acquisition device 300 is successful, the player P can play the game through such a process.

[0052] Furthermore, when player P withdraws credits from the acquisition device 300, the acquisition device 300 may display the owner input screen 510 after the usage selection screen 520. That is, when player P selects the usage approval button 521 on the usage selection screen 520, the acquisition device 300 displays the owner input screen 510. Player P enters their player ID. The acquisition device 300 sends the withdrawal request to the representative device 400 along with the entered player ID. The representative device 400 checks whether credits corresponding to the received player ID are recorded, and if they are, sends the recorded 8 credits to the acquisition device 300. In this way, unused credits may be withdrawn.

[0053] Player P does not have to deposit all of the unused credits (8 credits) generated by the transfer device 200. For example, Player P may deposit only 5 of the 8 credits into the representative device 400.

[0054] Specifically, the transfer device 200 displays a transfer quantity selection screen 530 (see Figure 8) after the transfer selection screen 500. Player P inputs the intention to deposit 5 credits using the number buttons 531. The number of credits to be transferred is displayed in the credit quantity display field 532. The number of credits to be transferred can be corrected using the correction button 534. Selecting the cancel button 535 returns the user to the previous screen (transfer selection screen 500).

[0055] After entering the number of credits, Player P selects the confirmation button 533. Then, Player P enters their Player ID on the owner input screen 510. As a result, the Player ID and 5 credits are sent to the representative device 400. The credit management unit 143 of the representative device 400 associates the Player ID with the number of unused credits "5" and registers it in the transfer waiting information 600. The remaining unused credits (3 credits) that are not transferred remain in the transfer device 200, so Player P can play three more times. Alternatively, an amount equivalent to 3 credits (300 yen) may be refunded to Player P.

[0056] Player P does not have to withdraw all of the unused credits deposited in the representative device 400. For example, if Player P has deposited 8 credits in the representative device 400, Player P may withdraw only 3 credits.

[0057] Specifically, the acquisition device 300 displays the acquisition quantity selection screen 540 (see Figure 9) after the usage selection screen 520. Player P inputs that they want to withdraw 3 credits using the number buttons 541. The number of credits is displayed in the credit quantity display field 542. Similar to the transfer quantity selection screen 530, Player P can correct the input or cancel the input using the correction button 544 and the cancel button 535.

[0058] After entering the number of credits, Player P selects the confirmation button 543. The withdrawal request, along with the number of credits "3" entered by Player P, is sent to the representative device 400. The credit management unit 143 of the representative device 400 updates the number of credits in the transfer waiting information 600 to "5" (= 8 - 3). Subsequently, 3 credits are sent to the acquisition device 300. As a result, the acquisition device 300 can acquire 3 credits.

[0059] Next, we will explain the process when the transfer of unused credits fails, following Figure 10. The process from steps S10 to S30 in Figure 10 is the same as the process from steps S10 to S30 in Figure 3.

[0060] When unused credits are sent from the representative device 400 to the acquisition device 300, the communication becomes temporarily unstable, and the credits do not reach the acquisition device 300 (S32). In this case, the credit transfer fails, and the acquisition device 300 cannot start the game.

[0061] For example, suppose a request to withdraw unused credits is sent to the representative device 400, and five seconds have passed, but the acquisition device 300 has not been able to withdraw the credits. In this case, the acquisition device 300 sends a reception result (not received) to the representative device 400 (S34). Assume that the transmission of the reception result (not received) was successful. Upon receiving the reception result (not received), the representative device 400 re-registers the player ID and the number of credits recorded in the cache memory in the transfer waiting information 600 (S36). In other words, the deletion of credits in S28 is canceled.

[0062] This prevents a bug where credits are deleted even though the credit withdrawal failed.

[0063] Up to this point, we have explained using the example of a case where the reception result reaches the representative device 400, regardless of whether the acquisition device 300 has received or not received any unused credits. However, depending on the timing of communication instability, it is conceivable that the reception result may not reach the representative device 400.

[0064] If the acquisition device 300 has acquired the credits (indicating a successful credit transfer), but the reception result (received) does not reach the representative device 400, player P can still play the game. In this case, the credits can remain deleted and do not need to be restored. However, if the representative device 400 does not receive the reception result (received), it cannot know whether the credit withdrawal was successful, and therefore cannot commit (confirm) the contents of the transfer waiting information 600.

[0065] If the acquisition device 300 fails to acquire credits (credit transfer failure), and the representative device 400 does not receive a reception result (not received), player P cannot play the game. In this case, it is necessary to restore the credits. However, if the representative device 400 does not receive a reception result (not received), it does not know whether the credit withdrawal was successful, and therefore does not know whether or not to restore the credits. In this case as well, the transfer waiting information 600 cannot be committed.

[0066] To avoid such situations, in this embodiment, if the reception result does not reach the representative device 400, the representative device 400 requests the acquisition device 300 to resend the reception result. The difference in processing when the reception result (received) is not received when the credit transfer is successful and when the reception result (not received) is not received when the credit transfer fails will be explained below.

[0067] Figure 11 shows the flow when the received result (received) does not reach the representative device 400 upon successful credit transfer. The flow from steps S10 to S34 in Figure 11 is the same as the flow from steps S10 to S34 in Figure 3.

[0068] Suppose that although the credits were successfully withdrawn, the reception result (received) did not reach the representative device 400 due to unstable communication afterward (S36). In this case, player P can start the game (S38). On the other hand, the representative device 400 cannot commit the transfer.

[0069] For example, suppose that five seconds have passed since the acquisition device 300 sent the credit, but the representative device 400 has not received the reception result (received). In this case, the representative device 400 requests the acquisition device 300 to resend the reception result (S40). The acquisition device 300 sends the reception result (received) to the representative device 400 (S42). Suppose that the reception result (received) was successfully received this time. Since the credit has been received, there is no need to cancel the credit deletion, so the representative device 400 removes the number of credits from the cache memory (S44). As a result, the representative device 400 can commit the transfer.

[0070] In other words, if the acquisition of credits is successful, player P can play the game. However, if the reception result (received) is not received due to temporary communication instability, the representative device 400 requests the acquisition device 300 to resend the reception result. After the representative device 400 successfully receives the reception result (received), the representative device 400 can commit the registration contents of the transfer waiting information 600. If the reception result (received) is still not received after the resend request, the representative device 400 periodically requests the acquisition device 300 to resend the reception result.

[0071] Figure 12 shows the flow when the credit transfer fails and the reception result (not received) does not reach the representative device 400. The flow from step S10 to S32 in Figure 12 is the same as the flow from step S10 to S32 in Figure 10.

[0072] Suppose that the reception result (not received) did not reach the representative device 400 due to unstable communication (S34). In this case, the representative device 400 cannot re-register the number of credits in the transfer waiting information 600.

[0073] For example, suppose that even after 5 seconds have passed since the acquisition device 300 sent the credit, the representative device 400 has not received the reception result (not received). The representative device 400 requests the acquisition device 300 to resend the reception result (S36). The acquisition device 300 sends the reception result (not received) to the representative device 400 (S38). Let's assume that the reception result (not received) has now been received. Since the credit has not been withdrawn, the representative device 400 re-registers the number of credits recorded in the cache memory in the transfer waiting information 600 (S40). This allows the unused credits to be restored.

[0074] In other words, if credit acquisition fails due to temporary communication instability, player P will not be able to play the game. Furthermore, if the reception result (not received) is also not received, the representative device 400 requests the acquisition device 300 to resend the reception result. If the representative device 400 successfully receives the reception result (not received), the representative device 400 can restore the credits. If the reception result (received) is still not received after the resend request, the representative device 400 periodically requests the acquisition device 300 to resend the reception result. This method avoids the loss of credits that would otherwise occur if the player could not play the game.

[0075] [Summary] The game system 100 of the present invention has been described above. The game system 100 consists of game devices 101 that are wirelessly connected to each other. Player P can transfer unused credits from the transfer device 200 to the acquisition device 300 via another game device 101 (representative device 400). Since the game device 101 has a function to manage transfer waiting information 600, there is no need to install a dedicated server for managing transfer waiting information 600. The operator of the game center C only needs to designate the game device 101 located in the best communication environment from among the multiple game devices 101 as the representative device 400.

[0076] When the transfer device 200 is instructed to deposit unused credits, the representative device 400 adds the unused credits to the transfer waiting information 600. When the acquisition device 300 receives an instruction to acquire unused credits, the representative device 400 transmits the number of credits registered in the transfer waiting information 600 to the acquisition device 300.

[0077] Player P can also specify the number of credits they wish to withdraw using the acquisition device 300. Player P can withdraw any unused credits managed by the representative device 400, whenever and in any amount, and play games. Player P can visit Game Center C multiple times over several days to use up their credits. This allows the operator of Game Center C to provide Player P with an incentive to continue using Game Center C.

[0078] If no credits are received from the representative device 400, player P cannot play the game. In this case, the acquisition device 300 sends a reception result (not received). The representative device 400 cancels the deletion of the credit count. This prevents player P from wasting unused credits.

[0079] In this embodiment, the transmission unit 121 functions as a "credit transmission unit," a "permission transmission unit," a "result transmission unit," and a "request transmission unit." The reception unit 122 functions as a "permission reception unit," a "result reception unit," and a "request reception unit." The acquisition reception unit 142 functions as a "credit acquisition unit."

[0080] [Modification 1] As Modification 1, the representative device 400 may not be set, and all or more game devices 101 may manage the number of unused credits in the transfer waiting information 600. In Modification 1, all game devices 101 have "transfer waiting information 600" and manage the number of unused credits. According to Modification 1, even if the number of credits in the transfer waiting information 600 of any game device 101 is fraudulently increased, the tampering can be detected by comparing the number of credits managed by all (or more) game devices 101.

[0081] Specifically, let's describe an example where unused credits are managed across all game devices 101. Suppose unused credits are generated in the transfer device 200 (let's call it game device 101a). Upon receiving a transfer instruction from player P, the transfer device 200 transmits the player ID and the number of unused credits to all other game devices 101. The other game devices 101 associate the player ID and the number of credits and register them in their respective transfer waiting information 600. The transfer device 200 also registers the player ID and the number of credits in its own transfer waiting information 600. In this way, unused credits are distributed and stored (registered) across all game devices 101.

[0082] Next, player P decides to withdraw unused credits from acquisition device 300 (let's call it game device 101b). Upon player P's acquisition instruction, acquisition device 300 sends withdrawal requests to all other game devices 101. Game devices other than acquisition device 300 (game device 101b) delete the player ID and credit count from transfer waiting information 600 and send the number of unused credits to acquisition device 300. Acquisition device 300 checks whether the number of credits received from each of the other game devices 101 is the same as the number of credits registered in its own transfer waiting information 600. If all the credit counts are the same, the credit withdrawal is successful.

[0083] If the number of credits does not match exactly, the withdrawal will fail. In this case, the acquisition device 300 sends a failure notification to all other game devices 101. When each game device 101 receives a withdrawal failure notification, it cancels the deletion of credits from the transfer waiting information 600 and returns to its original state. The acquisition device 300 (game device 101b) also cancels the deletion of credits in the same manner.

[0084] Using this method makes it easier to detect fraudulent manipulation of the credit count compared to when only the representative device 400 manages the credit count.

[0085] [Modification 2] In this embodiment, it was explained that the number of credits is deleted from the transfer waiting information 600 before the unused credits are sent to the acquisition device 300, but the order may be reversed. In Modification 2, the representative device 400 deletes the number of credits after receiving the reception result (received). In other words, the representative device 400 does not delete the number of credits until the reception result (received) is received.

[0086] In this case, assume that the acquisition device 300 was able to acquire unused credits, and player P was able to play the game. However, assume that due to temporary communication instability, the reception result (received) did not reach the representative device 400.

[0087] Since the reception result (received) is not received, the representative device 400 cannot delete the credit count. In other words, an inconsistency occurs where the game can be played, but the credits do not decrease. To avoid this situation, the representative device 400 requests the acquisition device 300 to resend the reception result. The following describes the processing flow in this case.

[0088] Figure 13 is a sequence diagram showing the processing flow in Modification 2. The flow from step S10 to S26 in Figure 12 is the same as the flow from step S10 to S26 in Figure 3.

[0089] Upon receiving a withdrawal request, the representative device 400 transmits the unused credits to the acquisition device 300 (S28). At this point, the representative device 400 does not yet remove the number of credits from the transfer waiting information 600.

[0090] When the acquisition device 300 acquires credits (S30), it transmits the reception result (received) to the representative device 400 (S32). The acquisition device 300 starts the game (S34).

[0091] Now, let's assume that due to unstable communication, the representative device 400 did not receive the reception result (received). In this case, the representative device 400 cannot delete the credit count from the transfer waiting information 600.

[0092] For example, suppose that five seconds have passed since the transmission of unused credits to the representative device 400, but the acquisition device 300 has not received a reception result (received). The representative device 400 instructs the acquisition device 300 to resend the reception result (S36). The acquisition device 300 transmits the reception result (received) to the representative device 400 (S38). Once the reception result (received) is received, the representative device 400 removes the credit count from the transfer waiting information 600 (S40).

[0093] In cases where the number of credits is deleted from the transfer waiting information 600 after the credits have been sent, if the reception result (received) is not received, the representative device 400 requests the acquisition device 300 to resend the reception result. When the representative device 400 receives the reception result from the acquisition device 300, it deletes the number of credits from the transfer waiting information 600. This ensures consistency between the registered contents of the transfer waiting information 600 and the credit usage status.

[0094] [Variation 3] Suppose player P, who is playing on game device 101a (transfer device 200), has decided to play on game device 101b (acquisition device 300) next. In Variation 3, unused credits are sent directly from transfer device 200 to acquisition device 300 without going through representative device 400.

[0095] Game device 101 is assigned a game machine ID. The game machine ID of transfer device 200 is "G01", and the game machine ID of acquisition device 300 is "G02". The following describes the case in which unused credits are directly transferred from transfer device 200 (G01) to acquisition device 300 (G02).

[0096] Figure 14 is a sequence diagram showing the processing flow in Modification 3. Assume that play on the transfer device 200 is completed (S10) and unused credits have been generated. The transfer device 200 displays a device selection screen (not shown) after the transfer selection screen 500. On the device selection screen, player P enters the game machine ID "G02" of the game device 101 to which the unused credits will be transferred (S12).

[0097] Furthermore, player P enters the player ID. The transfer device 200 transmits the player ID and unused credits to the acquisition device 300 (G02) (S14). The acquisition device 300 registers the player ID and the number of credits in the credit information (S16).

[0098] In the acquisition device 300, player P can make the credits sent from the transfer device 200 available for use by entering the player ID (S18). The acquisition device 300 removes the player ID and the number of credits from the credit information (S20). The acquisition device 300 acquires the credits (S22) and starts the game (S24).

[0099] This method allows player P to directly transfer credits to the next game device 101 they wish to play. Let's assume that there are only two wirelessly connected game devices 101: a transfer device 200 (G01) and an acquisition device 300 (G02). In this case, once player P approves the transfer on the transfer selection screen 500, the transfer device 200 may send (transfer) any unused credits to the acquisition device 300.

[0100] If the transfer device 200 (G01) fails to transmit credits to the acquisition device 300 (G02), the transfer device 200 (G01) may temporarily deposit the credits with the representative device 400, similar to the method used in this embodiment. The transfer device 200 (G01) may also transmit the credits, player ID, and destination game machine ID = G02 to another game device 101x located in a communication-enabled location, instead of to the acquisition device 300 (G02). The game device 101x may identify the acquisition device 300 (G02) by the game machine ID = G02 and transmit the player ID and credits. In this way, when the transfer device 200 (G01) cannot directly transmit credits to the acquisition device 300 (G02), the credits may be transmitted to another game device 101 acting as a proxy and stored there. Alternatively, the credits may be stored directly in the transfer device 200 (G01). The credits stored in this way may be transmitted to the acquisition device 300 (G02) later.

[0101] Player P may enter a passcode of their choosing instead of a Player ID. This allows players to use the credit transfer function without registering as a member, even if they would normally need to complete procedures such as member registration to obtain a Player ID. For example, Player P might choose a 10-digit alphanumeric string as a passcode and send it when depositing credits. Player P then makes a note of this secret passcode. In the transfer waiting information 600, the passcode and the number of credits are registered in association. Later, when Player P plays a game using the acquisition device 300, they enter the passcode. If they enter the passcode correctly, they can use the credits they deposited the other day. The representative device 400 may delete unused credits along with the passcode if no withdrawals using the passcode are made for a predetermined period of time, for example, 30 days or more.

[0102] In this case, the transmission unit 121 functions as a "credit transmission unit," and the acquisition reception unit 142 functions as a "credit acquisition unit."

[0103] [Modification 4] In the game device 101, even if player P1 is in a state where credits can be transferred, acquired, or used (hereinafter referred to as "ready state"), if the following operation is not performed for a certain period of time or longer, another player P2 may be able to play the game. In Modification 4, if no new operation is performed on the game device 101 for a certain period of time or longer after it has entered the ready state, the game device 101 is set to be inoperable. In this inoperable state, if player P1 enters their player ID, player P1 will be able to use the game device 101 again.

[0104] More specifically, suppose that while the user selection screen 520 is displayed, player P moves away from the acquisition device 300 and there is no operation for a predetermined time (for example, 15 seconds). The acquisition device 300 stops displaying the user selection screen 520 and displays the previous screen (owner input screen 510) to request the player ID to be re-entered. Alternatively, the acquisition device 300 displays the aforementioned payment acceptance screen and requests that a new play fee be inserted. This prevents a third party from selecting the usage approval button 521 and fraudulently acquiring unused credits to play.

[0105] Alternatively, in a situation where the transfer of unused credits is being approved, if there is no operation for a while, the transfer device 200 may interrupt the credit transfer. More specifically, suppose that player P moves away from the transfer device 200 for a while while the owner input screen 510 is being displayed. The transfer device 200 will stop displaying the owner input screen 510 and display the previous screen (transfer selection screen 500). This prevents a third party from entering their own player ID on the owner input screen 510 and transferring player P's unused credits in a way that would essentially steal them.

[0106] In addition, the following processes may be performed regarding the storage and transfer of credits:

[0107] [Modification 5] In Modification 5, Player P possesses a terminal (not shown) on which the Player ID is stored. A server (not shown) is also provided that can communicate with each game device 101 and terminal and manages unused credits. In this case, instead of manually entering the Player ID into the transfer device 200 or acquisition device 300, Player P may deposit or withdraw credits by sending the Player ID stored in the terminal to the server. With this method, even if the Player ID consists of a complex and long string, Player P does not need to remember the Player ID and does not have to spend time entering it.

[0108] More specifically, the player P's terminal is equipped with dedicated application software (hereinafter referred to as "app") that can exchange data with the server. The game device 101 includes a code generation unit (not shown). The code generation unit generates a two-dimensional code on which its own game machine ID is recorded.

[0109] Before playing on the transfer device 200, Player P uses the terminal's camera to scan a 2D code on the transfer device 200 that contains the game machine ID. The terminal reads the game machine ID from the 2D code and sends it to the server along with the Player ID. The server associates the game machine ID with the Player ID and registers them as a paired device.

[0110] When unused credits are generated in the transfer device 200, the transfer device 200 sends the credits to the server along with the game machine ID. The server registers the credits in association with the player ID that has been paired with the game machine ID.

[0111] Before playing with the acquisition device 300, Player P scans a 2D code containing the game machine ID of the acquisition device 300 using the camera on their terminal. The terminal reads the game machine ID from the 2D code and sends the Player ID and game machine ID to the server. Based on the received game machine ID, the server sends the credits registered in association with the Player ID to the acquisition device 300. This allows the acquisition device 300 to start the game.

[0112] In this way, before starting to play on the transfer device 200 and before starting to play on the acquisition device 300, player P scans the 2D code displayed on each game device 101 instead of manually entering the player ID. This allows player P to transfer credits from the transfer device 200 to the acquisition device 300 without any extra effort.

[0113] Furthermore, when Player P finishes playing and there are unused credits, the transfer device 200 may display a 2D code. At this time, Player P can also transfer credits by scanning the 2D code with their terminal.

[0114] In connection with this, unused credits may be transferred via a terminal owned by player P. The game device 101 is equipped with a two-dimensional code display function and an imaging function. First, the transfer device 200 displays a two-dimensional code indicating the number of unused credits. Player P images the two-dimensional code with the camera on their terminal. Player P has the transfer device 200 display the imaged two-dimensional code on their terminal and have the acquisition device 300's camera capture it. The acquisition device 300 reads and acquires the credits from the imaged two-dimensional code. Credits can also be transferred by this method.

[0115] [Variation 6] In Variation 6, player P1 can reserve a game on game machine 101 by sending credits to the game machine 101 they wish to play on. Suppose player P1 wants to play a game on game machine 101 (G02). First, player P1 pays the play fee and purchases credits at any game machine 101 or any transfer device 200 such as a change machine. Player P1 also enters their player ID and the game machine ID (G02) of the game machine 101 they wish to reserve. The transfer device 200 sends the player ID and credits to game machine 101 (G02).

[0116] If game device 101 (G02) is available, it becomes reserved for player P1. While reserved, other players cannot use game device 101 (G02). Player P1 can release the reservation by entering their player ID on game device 101 (G02) and play the game using the credits that were sent to them.

[0117] If the game device 101 (G02) is currently being used by another player P2, the game device 101 (G02) will become occupied after player P2 finishes playing. In this case, player P1 can also release the occupied state by entering their player ID on the game device 101 (G02).

[0118] If player P1's credits are sent to game device 101 (G02) while player P2 is playing, player P1's credits may be automatically added to player P2's credits. For example, suppose player P1 and player P2 are friends. Player P1 plays separately on game device 101 (G01), and player P2 plays separately on game device 101 (G02). Suppose player P1 wins a prize first on game device 101 (G01) and has credits left over. Player P1, who still wants to play the crane game, transfers the remaining credits to game device 101 (G02) to help player P2, who has not yet won a prize. At this time, player P1's credits are added to player P2's credits, allowing both player P1 and player P2 to try (play) more times to win prizes on game device 101 (G02).

[0119] [Other variations] The data entered by player P may include something other than the player ID or game machine ID. For example, an electronic money ID, a user-specified password, a one-time password issued by the game device 101, or a facial photograph may be used. The type of data is not particularly limited as long as it can uniquely identify the player or the game device 101.

[0120] If the game device 101 is installed in a secluded location, communication is often unstable. For example, it may not be possible to directly transmit unused credits from game device 101a (transfer device 200) to game device 101b (acquisition device 300). In this case, unused credits may be transmitted to game device 101b via other game devices 101c to 101f, where communication is stable.

[0121] The present invention is not limited to the embodiments or modifications described above, and can be materialized by modifying the components without departing from the spirit of the invention. Various inventions may be formed by appropriately combining the multiple components disclosed in the embodiments and modifications described above. Furthermore, some components may be deleted from all the components shown in the embodiments and modifications described above.

[0122] 100 Game system, 101 Game device, 110 User interface processing unit, 111 Input unit, 112 Output unit, 120 Communication unit, 121 Transmission unit, 122 Receiving unit, 130 Data storage unit, 140 Data processing unit, 141 Transfer acceptance unit, 142 Acquisition acceptance unit, 143 Credit management unit, 144 Game control unit, 200 Transfer device, 300 Acquisition device, 400 Representative device, 500 Transfer selection screen, 501 Transfer permission button, 502 Transfer rejection button, 510 Owner input screen, 511 Number buttons, 512 ID display field, 513 Confirm button, 514 Correction button, 515 Cancel button, 520 Usage selection screen, 521 Usage approval button, 522 Usage rejection button, 530 Transfer number selection screen, 531 Number buttons, 532 Credit number display field, 533 Confirm button, 534 Correction button, 535 Cancel button, 540 Number of acquisition selection screen, 541 Number buttons, 542 Credit count display field, 543 Confirm button, 544 Correction button, 545 Cancel button, 600 Information awaiting transfer

Claims

1. A game device comprising multiple units installed and connected to each other via a network, the game device having a first function that receives a credit transfer instruction from a player and transmits unused credits directly or via another game device to a game device that the player will play in the future, and a second function that receives a credit acquisition instruction from the player and acquires unused credits transmitted from a game device that the player has played in the past.

2. The game device according to claim 1, wherein at least one of the multiple game devices installed further comprises a management function that registers unused credits to be transferred as transfer waiting information, transmitted from the game device that received the transfer instruction, and deletes unused credits to be acquired from the transfer waiting information, transmitted to the game device that received the acquisition instruction.

3. The game device according to claim 2, wherein the second function further includes the process of acquiring an amount of unspent credits equal to the specified number of credits to be acquired from among the unspent credits registered in the transfer waiting information, after receiving an acquisition instruction from the player, and the management function further includes the process of subtracting an amount from the credits registered in the transfer waiting information equal to the number specified by the player.

4. The game device according to claim 2, wherein the management function further includes the process of, upon receiving the acquisition instruction, deleting the unspent credits to be acquired from the transfer waiting information, and then transmitting a credit acquisition permission to the game device that received the acquisition instruction; the second function further includes the process of receiving the credit acquisition permission, and transmitting a reception result indicating whether or not the credit acquisition permission was received to the game device that sent the credit acquisition permission; the management function further includes the process of, if, after transmitting the credit acquisition permission, the reception result was not received within a predetermined time, transmitting a report request to the game device that sent the credit acquisition permission; the second function further includes the process of receiving the report request, and after receiving the report request, transmitting the reception result to the game device that sent the report request; and the management function further includes the process of, if, after transmitting the report request, a reception result indicating that the credit acquisition permission was not received, re-registering the deleted credits as unspent credits in the transfer waiting information.

5. The game device according to claim 2, wherein the management function further includes a process of transmitting a credit acquisition permission to a game device that has received the acquisition instruction; the second function further includes a process of receiving the credit acquisition permission and a process of transmitting a reception result indicating whether or not the credit acquisition permission has been received to the game device that is the source of the credit acquisition permission; the management function further includes a process of receiving the reception result and, if the reception result could not be received within a predetermined time after the transmission of the credit acquisition permission, a process of transmitting a report request to the game device that is the recipient of the credit acquisition permission; the second function further includes a process of receiving the report request and, after receiving the report request, a process of transmitting the reception result to the game device that is the source of the report request; and the management function further includes a process of deleting the unconsumed credits to be acquired from the transfer waiting information, provided that a reception result indicating that the credit acquisition permission has been received has been received.

6. The game device according to claim 1, wherein each of the multiple installed game devices further comprises a management function that registers unused credits to be transferred, transmitted from the game device that received the transfer instruction, into the transfer waiting information, and deletes unused credits to be acquired, transmitted to the game device that received the acquisition instruction, from the transfer waiting information, the first function further comprises a process of transmitting the unused credits to be transferred to one or more game devices connected to the network with the device after receiving the transfer instruction, and the second function further comprises a process of acquiring the unused credits to be acquired from one or more game devices connected to the network with the device after receiving the acquisition instruction.

7. A game device comprising multiple units installed and connected to each other via a network, the game device having a first function that, after receiving a credit transfer instruction from a player including a game machine ID that identifies the next game device to be played, transmits unused credits directly or via another game device to the game device specified by the game machine ID; and a second function that, after receiving a credit acquisition instruction from the player, acquires unused credits transmitted from game devices previously played by the player.

8. A game system comprising a plurality of game devices connected to each other via a network, wherein the plurality of game devices include a first device and a second device that is played after the first device, the first device includes a transfer receiving unit that receives a credit transfer instruction from a player, and a credit transmission unit that, after receiving the transfer instruction, transmits unused credits to the second device directly or via another game device, and the second device includes an acquisition receiving unit that receives a credit acquisition instruction from a player, and a credit acquisition unit that, after receiving the acquisition instruction, acquires unused credits transmitted from the first device.

Images