JP2023168408A - Game system, program, and game service providing method - Google Patents

Abstract

To provide a game system or the like capable of realizing services utilizing currency within a game flexibly.SOLUTION: A game system includes: an increasing part for increasing the remainder by an increment when receiving an increase request for determining the increment of currency within a game; a decreasing part for decreasing the remainder by a decrement when receiving a decrease request for determining the decrease of currency within a game; and a management part for associating the remainder changed by the increasing part and the decreasing part to user's identification information within a range from a value equal to or more than 0 to a value less than 0 and managing it. The decreasing part changes the remainder to less than 0 when receiving a decrease request for determining a decrement larger than the remainder.SELECTED DRAWING: Figure 5

Description

The present invention relates to a game system.

Conventionally, game systems have been known that manage the balance of in-game currency held by the user and allow the user to play the game itself or obtain in-game items by consuming the in-game currency. (For example, Patent Document 1).

Japanese Patent Application Publication No. 2015-159976

However, in conventional game systems, the balance of in-game currency held by the user is managed as a value of 0 or more. That is, whether or not the user can play the game and obtain in-game items has been determined depending on whether or not the user has a sufficient balance of in-game currency. Therefore, users could not flexibly receive services using in-game currency, and service providers could not flexibly provide services to users using in-game currency. For example, if a user wants to play a game and the balance of in-game currency is insufficient, the user needs to replenish the in-game currency to increase the balance before playing the game. If the user feels troubled by the act of replenishing the in-game currency, there is a possibility that the user's desire to play the game will decrease.

The present invention has been made in view of the above-mentioned problems, and its purpose is to provide a game system that can flexibly implement a service using in-game currency.

(1) The present invention is a game system that manages the balance of in-game currency consumed for playing a game or purchasing in-game items by associating it with user identification information, the amount of increase in the in-game currency an increase part that increases the balance by the increase amount when an increase request that specifies the in-game currency is received; and an increase part that increases the balance by the decrease amount when a decrease request that specifies the decrease amount of the in-game currency is received; and a management unit that manages the balance changed by the increase unit and the decrease unit in association with the identification information of the user in a range from a value of 0 or more to a value of less than 0. The present invention relates to a game system that changes the balance to a value less than 0 when a reduction request is received in which the amount of reduction is determined to be greater than the balance.

According to the present invention, the balance of in-game currency is managed in a range from a value of 0 or more to a value of less than 0, and when a reduction request specifying a reduction amount greater than the balance is received, the balance is less than 0. Since the value is changed to a value, it is possible to play the game and obtain in-game items even if the balance of in-game currency is insufficient, and it is possible to realize services that use in-game currency flexibly.

(2) Furthermore, in the game system according to the present invention, when the increase unit receives an increase request specifying an increase amount specified by the user, the increase unit transmits a payment request for an amount corresponding to the increase amount to the billing server. , the balance may be increased by the increased amount when the amount is paid in the billing server in response to the payment request.

According to the present invention, it is possible to realize a service that flexibly uses in-game currency purchased by a user.

(3) Further, in the game system according to the present invention, the management unit manages the balance using a total value of a first parameter having a value of 0 or more and a second parameter having a value of 0 or less, and the increasing unit , when receiving an increase request specifying an increase amount of the in-game currency, the first parameter may be increased by the increase amount.

According to the present invention, when the user specifies an increase amount and requests an increase, even if the balance of in-game currency is less than 0, the first parameter increases by the increase amount. The user can easily recognize that the balance of in-game currency has increased by the specified increase amount.

(4) Furthermore, the game system according to the present invention may further include a display control section that distinguishes the first parameter and the second parameter and displays them on the display section of the user's terminal.

According to the present invention, by displaying the first parameter and the second parameter separately, the user can easily recognize that the balance of in-game currency has increased by the specified increase amount.

(5) Furthermore, in the game system according to the present invention, the management unit determines whether or not the past game usage history of the user satisfies a given trust condition, and reduces the balance of the user who satisfies the trust condition to 0. The balance of a user who does not satisfy the trust condition may be changed to a value less than 0, and the balance of a user who does not satisfy the trust condition may not be changed to a value less than 0.

According to the present invention, it is possible to flexibly provide services using in-game currency to users who satisfy trust conditions.

(6) The game system according to the present invention further includes a restriction section that imposes a given restriction on the user, and the restriction section determines whether the user's past game usage history satisfies the given trust condition. The restriction given to users who satisfy the trust condition may be relaxed.

(7) Furthermore, the game system according to the present invention may further include a restriction section that applies a given restriction to the user when the user's balance becomes a value less than 0.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(8) Furthermore, in the game system according to the present invention, the restriction unit may relax the restriction given to the user as the reliability based on the user's past game usage history increases.

According to the present invention, it is possible to urge a user with low reliability to increase the balance of in-game currency that has become a value less than 0 to a value greater than or equal to 0.

(9) Furthermore, in the game system according to the present invention, the restriction section may impose restrictions on consumption of the in-game currency by the user.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(10) Furthermore, in the game system according to the present invention, the restriction section may impose restrictions that are disadvantageous to the progress of the game.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(11) Further, in the game system according to the present invention, the in-game currency includes paid in-game currency and free in-game currency, and the restriction unit sets the restriction to the user as the restriction to the user. The granting of free in-game currency may be stopped.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(12) Furthermore, in the game system according to the present invention, the restriction unit may apply the restriction to the user until the user's balance reaches a value of 0 or more.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(13) Furthermore, in the game system according to the present invention, the restriction unit may control the balance when the user's balance does not become a value of 0 or more after a predetermined period has passed after the balance of the user becomes a value of less than 0. , the restriction may be given to the user.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(14) Furthermore, in the game system according to the present invention, the management unit may take over the balance that has become a value less than 0 as the balance to be managed in another game.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(15) Furthermore, in the game system according to the present invention, the management section may take over the restriction given to the user as the restriction given to the user in the other game.

According to the present invention, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

(16) Furthermore, in the game system according to the present invention, the management section may transfer the balance when a given condition is satisfied.

According to the present invention, under given conditions, it is possible to prompt the user to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0.

FIG. 1 is a diagram showing a game system of this embodiment. The figure which shows an example of the functional block diagram of the game server of this embodiment. FIG. 2 is a diagram showing an example of a functional block diagram of a terminal according to the present embodiment. A diagram showing an example of table information for managing the balance of in-game currency. 1 is a flowchart showing the flow of processing of the game system of this embodiment.

This embodiment will be described below. Note that this embodiment described below does not unduly limit the content of the present invention described in the claims. Furthermore, not all of the configurations described in this embodiment are necessary components of the present invention.

1. Configuration FIG. 1 shows the game system of this embodiment. In this embodiment, it is configured by a plurality of terminals 10, a game server 20 (server system), and a billing server 30. In other words, as shown in FIG. 1, the game system of this embodiment includes a game server 20 that provides game services, a billing server 30 that settles billing amounts, and terminals 10 (10A, 10B, 10C...). is configured to be connectable to the network.

The game server 20 is an information processing device that provides online game services in response to requests from the terminals 10. The game server 20 can be composed of one or more servers (an authentication server, a matching server, a game processing server, a communication server, a database server, etc.). The billing server 30 is an information processing device that provides payment services in response to requests from the game server 20. Note that the billing server 30 may communicate with a credit card company or other payment system server.

In this embodiment, a game program is executed on the terminal 10, and the game server 20 stores information such as user account information, game results of the game executed on the terminal 10, and in-game items (characters (virtual)) that can be used in the game. Information such as game media (such as cards), items, etc., and in-game currency (virtual currency consumed for playing games or purchasing in-game items) is managed. Here, "game" includes action games, RPGs, puzzle games, rhythm games, shooting games, sports games, training games, simulation games, etc., which are generally called games, as well as virtual games in virtual space. In video distribution services, viewers can communicate with a character (virtual character) (conversation, send comments), give gifts or ratings (likes, etc.) to a virtual character, and Guests can use terminals (smartphones, PCs, etc.) to communicate with others, give gifts and ratings to video streamers, and give gifts and ratings to video streamers. It also includes those that react to events. "Running the game" also includes consuming in-game currency and sending comments and evaluations to virtual characters, video distributors, performers at events and concerts, etc. in order to communicate. In addition, "in-game items" are used to change the avatar that the user uses in the virtual space, gifts to the virtual character (such as coins, bouquets, costumes for the virtual character, etc.), and background objects and lighting in the virtual space. items used to modify the content of a concert or event (such as concert lighting).

The terminal 10 is an information processing device such as a mobile terminal (smartphone, mobile phone, portable game machine, etc.), a personal computer (PC), a game device, an image generation device, etc. This is a device that can be connected to servers (game server 20, billing server 30). Note that the communication line between the terminal 10 and the server may be wired or wireless.

FIG. 2 shows an example of a functional block diagram of the game server 20 of this embodiment. Note that the game server of this embodiment may have a configuration in which some of the components (each part) in FIG. 2 are omitted.

The storage section 270 stores programs and various data for making the computer function as each section of the processing section 200, and also functions as a work area for the processing section 200, and its functions can be realized by a hard disk, RAM, or the like. Storage unit 270 includes a storage unit 272 (eg, a database).

The storage unit 272 stores user information of each of a plurality of users who participate in the online game executed by the game system of this embodiment. For example, the storage unit 272 stores the user name (user account), password, destination information (IP address, etc.) of the terminal 10 in association with the user identification information (user ID, terminal ID used by the user, etc.) of each of a plurality of users. etc.) are stored as user information. The storage unit 272 also stores information for identifying other users who are in a friend relationship (an example of a predetermined relationship) with the user as user information. Furthermore, the storage unit 272 stores, as user information, in-game items (game media), in-game currency, etc. held by the user, and game play results of the user, in association with the user identification information.

The communication unit 296 performs various controls for communicating with the terminal 10 and the billing server 30, and its functions can be realized by hardware such as various processors or communication ASICs, programs, and the like.

The processing unit 200 (processor) performs various processes such as user information management, login/logout processing, and communication control processing based on data, programs, etc. transmitted from the terminal 10 and received via the communication unit 296. The processing unit 200 performs various processes using the storage unit 270 as a work area. The functions of the processing unit 200 can be realized by hardware such as various processors (CPU, DSP, etc.), ASIC (gate array, etc.), and programs. The processing section 200 includes an increase section 210, a decrease section 212, a management section 214, and a display control section 216.

When the increasing unit 210 receives an increase request specifying the amount of increase in the in-game currency, the increase unit 210 increases the balance of the in-game currency by the amount of increase. There may be multiple types of in-game currency, including paid in-game currency (in-game currency that the user purchases using a payment service), free in-game currency, and paid in-game currency. There may be multiple types of currencies. Free in-game currency is, for example, in-game currency given to the user as a login bonus when logging in, or in-game currency given to the user as a benefit according to game results (such as clearing a quest or winning a battle). It is currency. When increasing the balance of paid in-game currency, when the increase unit 210 receives an increase request specifying the increase amount specified by the user, the increase unit 210 transmits a payment request for the amount corresponding to the increase amount to the billing server 30. However, when the amount is paid in the billing server 30 in response to the payment request, the balance of the in-game currency of the user is increased by the amount of increase. Note that the user specifying the increase amount may mean that the user inputs and specifies the increase amount numerically, or the game operator etc. may specify the increase amount in advance as "1,000" or "2". , 000'', etc., and the user selects and specifies the increase amount from those options. Further, instead of the user directly specifying the amount of increase in the in-game currency itself, the user may specify only the amount, thereby indirectly specifying the amount of increase corresponding to that amount. Note that in the case of free in-game currency, the amount of increase is specified by the game operator, etc. Furthermore, the amount of paid in-game currency may be increased on a monthly basis. In the case of a monthly system, for example, if the user specifies an increase amount of "5,000" each month once, then an increase request specifying the increase amount of "5,000" will be accepted at a fixed timing every month, and the billing server will The billing process (settlement process) at 30 is performed, and the balance of the in-game currency of the user increases. In this case, the user specifies the increase amount at the time of subscribing to the monthly service, but after that, the increase amount is automatically specified and the increase request is accepted. In this case, an increase request may be sent from the user's terminal 10 every month, or the servers (game server 20, PF server described later, billing server 30) are fixed every month while subscribed to the monthly service. The increase request may be automatically generated or transmitted at the appropriate timing. Alternatively, the balance of in-game currency may be increased by first paying the fee in one lump sum and then dividing the fee into installments. For example, if an increase request with an increase amount of "10,000" is received from the user's terminal 10, instead of increasing the in-game currency balance by the increase amount "10,000" immediately, Increase the balance of in-game currency by ``200'' at the same time. In this case, a payment request for the amount corresponding to the increase amount "10,000" is sent to the billing server 30 to make the payment, and then an increase request specifying the increase amount "200" is made without going through the billing server 30. may be generated and transmitted at a fixed timing every month, so that the user's in-game currency balance increases by "200". Note that if both paid in-game currency and free in-game currency exist, the increase unit 210 increases the balance of the user's paid in-game currency only when the user purchases the paid in-game currency. The balance of the user's free in-game currency is increased only when the user is given free in-game currency, and the balance of the user's free in-game currency is increased only when the user is given free in-game currency. The balance of in-game currency may be increased, or when a user is given free in-game currency, the balance of paid in-game currency of the user may not be increased.

When the reduction unit 212 receives a reduction request specifying the amount of reduction in in-game currency, it reduces the balance of in-game currency by the amount of reduction. When there are multiple types of in-game currency, the decrease unit 212 decreases the balance of one type of in-game currency, and the increase unit 210 decreases the balance of another type of in-game currency (for example, the balance is less than 0) by the decreased amount. You may increase the balance of the in-game currency (which has a value of ). Further, the decrease unit 212 may decrease the balance of free in-game currency, and the increase unit 210 may increase the balance of paid in-game currency by the amount of decrease, or the decrease unit 212 may decrease the balance of paid in-game currency by the decreased amount. The balance of the in-game currency may be decreased, and the increasing unit 210 may increase the balance of the free in-game currency by the decreased amount. Note that the amount of reduction may be determined by the game operator (for example, ``200'' of in-game currency is consumed per Gacha). Alternatively, the user may specify the amount of reduction.

The management unit 214 manages the balance changed by the increase unit 210 and the decrease unit 212 in a range from a value of 0 or more to a value of less than 0 in association with the user's identification information. The reduction unit 212 changes the balance to a value less than 0 when receiving a reduction request specifying a reduction amount greater than the balance. Furthermore, the management unit 214 may manage the balance using a total value of a first parameter having a value of 0 or more and a second parameter having a value of 0 or less. In this case, when the increase unit 210 receives an increase request with a predetermined increase amount, the increase unit 210 may increase the first parameter by the increase amount. The management unit 214 also determines whether the user's past game usage history satisfies a given trust condition, allows the user who satisfies the trust condition to change the balance to a value less than 0, and sets the trust condition. The balance of the user who does not satisfy the requirement may be made unchangeable to a value less than 0.

The display control unit 216 performs control to display the user's in-game currency balance on the display unit of the user's terminal 10. When the management unit 214 manages the balance using the total value of the first parameter and the second parameter, the display control unit 216 distinguishes the first parameter and the second parameter and displays them on the display unit of the user's terminal 10. You may let them.

The processing unit 200 may further include a restriction unit 218. The restriction unit 218 gives the user certain restrictions (for example, restrictions on consumption of in-game currency, restrictions that are disadvantageous in progressing the game, and restrictions on granting free in-game currency). When the user's balance becomes a value less than 0, the restriction unit 218 may limit the user until the user's balance reaches a value of 0 or more. Further, the restriction unit 218 controls whether the user's balance becomes a value of 0 or more after a predetermined period (a predetermined time, number of days, number of months, number of years, etc.) has elapsed after the balance of the user becomes a value less than 0. If not, restrictions may be imposed on the user. For example, after the user's balance becomes a value less than 0, if the balance does not become a value greater than 0 24 hours later, or if the balance does not become a value greater than 0 one month after the user's balance becomes a value less than 0. , restrictions may be imposed on the user. Further, the predetermined period may be from the time when the balance becomes a value less than 0 to the time when a predetermined limit is determined. For example, the restriction may be imposed if the balance does not reach a value of 0 or more from the time when the balance becomes a value less than 0 until 24:00 on the same day (predetermined restriction determination time). That is, the length of the predetermined period may change depending on at what point the balance becomes a value less than 0. Further, the restriction unit 218 may determine whether or not the user's past game usage history satisfies a given trust condition, and may relax the restriction given to the user who satisfies the trust condition. Further, the restriction unit 218 may relax the restriction given to the user as the reliability based on the user's past game usage history increases.

The management unit 214 also manages the user's in-game currency balance for each game played by the user (for example, a game application installed on the user's terminal 10), and manages the balance of the user's in-game currency for each game played by the user (for example, a game application installed on the user's terminal 10). In some cases, the balance that has become a value less than 0 in a given game may be taken over as the balance managed in another game. In this case, the management unit 214 may take over the restrictions given to the user in a given game as restrictions given to the user in another game.

FIG. 3 shows an example of a functional block diagram of the terminal 10 of this embodiment. Note that the terminal of this embodiment may have a configuration in which some of the components (each part) in FIG. 3 are omitted.

The input unit 150 is a device for inputting (detecting) input information from a user, and outputs the user input information (operation input) to the processing unit 100. The functions of the input unit 150 can be realized by input devices such as a touch panel, a touch pad, a mouse, direction keys and buttons, and a keyboard.

The storage section 170 stores programs and various data for making the computer function as each section of the processing section 100, and also functions as a work area for the processing section 100, and its functions can be realized by a hard disk, a RAM, or the like.

The display unit 190 outputs the game image generated by the processing unit 100, and its function can be realized by a display such as a touch panel, LCD, or HMD (head mounted display) that also functions as the input unit 150.

The sound output section 192 outputs the sound generated by the processing section 100, and its function can be realized by a speaker, headphones, or the like.

The communication unit 196 performs various controls for communicating with the game server 20, billing server 30, and other terminals 10, and its functions are performed by hardware such as various processors or communication ASICs, and programs. This can be achieved by

Note that programs and various data for making the computer function as each part of the processing unit 100 stored in the information storage medium and storage unit of the game server 20 are received via the network, and the received programs and data are stored. The information may be stored in the section 170. The scope of the present invention also includes the case where the terminal functions by receiving programs and various data in this manner.

The processing unit 100 (processor) performs processing such as game processing, image generation processing, sound generation processing, etc. based on input information (operation information) from the input unit 150, a program, data received via the communication unit 196, etc. I do. The functions of the processing unit 100 include various processors (CPU, DSP,
etc.), ASIC (gate array, etc.) or other hardware, or a program. The processing section 100 includes a game processing section 110, an image generation section 120, and a sound generation section 130.

Based on input information from the input unit 150 and information received from the game server 20, the game processing unit 110 performs a game using in-game items (for example, causes a character that is an in-game item to appear in the game as a player character). Performs processing to advance the game (game).

The image generation unit 120 performs drawing processing based on the results of various processes performed by the processing unit 100, thereby generating a game image and outputting it to the display unit 190. The image generation unit 120 may generate an image (a so-called three-dimensional image) that can be seen from a virtual camera (a given viewpoint) in an object space (game space).

The sound generation unit 130 performs sound processing based on the results of various processes performed by the processing unit 100, generates game sounds such as BGM, sound effects, or voices, and outputs them to the sound output unit 192.

Furthermore, when the game is started, the processing unit 100 transmits information for notifying that the game has started to the game server 20, and when the game is finished, the processing unit 100 transmits the game results regarding the game results and various game parameters. Information (information regarding in-game items held by the user, information regarding in-game currency held by the user, game play results) is transmitted to the game server 20. The game server 20 updates various data associated with each user based on the game result information transmitted from the game device (terminal 10). Note that the game result information generated on the terminal 10 side is not limited to the example of transmitting the game result information to the game server 20, but the game server 20 side can also transmit information based on various information sequentially transmitted from the terminal 10 to the game server 20 during game execution. Game result information may also be generated. Furthermore, whether or not the game has ended may be determined on the terminal 10 side or on the game server 20 side.

Further, the game system may be configured by the terminal 10 and the game server 20. In this case, the game server 20 has the function of the billing server 30. Further, the game system may be configured by the terminal 10 and the billing server 30. In this case, the billing server 30 has the functions of the game server 20. The game system also includes a terminal 10, a game server 20, and a platform server (PF server) that manages user information (user's personal information, information on each game played by the user, friend information in each game, etc.). , and the billing server 30. In this case, a payment request may be sent from the game server 20 to the billing server 30, or a payment request may be sent from the PF server to the billing server 30. Further, the game system may be configured by the terminal 10, the game server 20, and the PF server. In this case, the PF server has the function of the billing server 30. Further, the game system may be configured by the terminal 10, the PF server, and the billing server 30. In this case, the PF server has the function of the game server 20. Further, the game system may be configured by the terminal 10 and the PF server. In this case, the PF server has the functions of the game server 20 and the billing server 30. If the game can be executed only on the terminal 10 side, the game server 20 may not be provided. Alternatively, the game may basically be executed only on the terminal 10 side, and the game server 20 may execute only some games (games requiring online elements). The terminal 10 may be able to directly access the game server 20 and the PF server. The terminal 10, the game server 20, the PF server, etc. receive information from the billing server 30 regarding the success or failure of the payment regarding the purchase of paid in-game currency. In addition, the terminal 10, game server 20, PF server, etc. receive information regarding the user's refund request from the billing server 30 (refund processing progress, refund availability, refund amount, paid in-game currency for which the refund was made). amount). Further, the information regarding these payments and refunds may be used as is or may be modified as necessary and manually entered into the game server 20 or the PF server directly, rather than via the network. Further, the balance of in-game currency may be managed by any one of the terminal 10, the game server 20, the PF server, and the billing server 30. That is, the functions of the increase section 210, the decrease section 212, the management section 214, the display control section 216, and the restriction section 218 may be provided in any one of the terminal 10, the game server 20, the PF server, and the billing server 30. Further, the balance of in-game currency may be managed by different servers (for example, the game server 20 and the PF server). In this case, each server may manage a common balance of in-game currency, or each server may manage balances of different types of in-game currency. In this case, each in-game currency may be consumed separately, the sum of the balances of each in-game currency may be consumed, or a specific type of in-game currency may be consumed. Currency may be consumed preferentially.

2. Method of this embodiment Next, the method of this embodiment will be explained using the drawings.

In the game system of this embodiment, in-game currency (paid or free in-game currency) held by the user is consumed to play the game or purchase in-game items (characters, items, etc. that can be used in the game). A mechanism is provided that allows you to obtain (purchase).

FIG. 4 is a diagram showing an example of table information for managing the balance of in-game currency held by the user. This table information is stored in the storage section 272. The table information 300 stores the user's in-game currency balance 320 and the user's game usage history 350 in association with the user's user ID 310 (user identification information). In the example shown in FIG. 4, the in-game currency balance 320 of the user with user ID "001" is "1,000", and the in-game currency balance 320 of the user with user ID "002" is "-500". It shows that there is.

When the user performs an operation on the terminal 10 to request the purchase of paid in-game currency, the increase unit 210 of the game server 20 receives an increase request specifying the increase amount (purchase amount) specified by the user. The increase unit 210 that has received the increase request transmits a request for payment of the amount corresponding to the increase amount specified in the increase request to the billing server 30, and receives a notification from the billing server 30 that the payment for the amount has been completed. , the balance 320 of the user is increased by the increased amount.

Additionally, when the game server 20 (service provider) distributes free in-game currency to the user as a login bonus or a benefit according to game results, the user instructs the terminal 10 to receive the in-game currency. When the user performs an operation to access the game server 20 from the terminal 10 (logs in), the increase unit 210 receives an increase request specifying the increase amount (distribution amount), and the increase unit 210 The balance 320 of is increased by the amount of increase determined by the increase request. Note that an increase request may be sent from the terminal 10 to the game server 20 by the user performing an operation to receive the login bonus or accessing the game, or the game server 20 may receive the login bonus at the terminal 10. When it is detected that there has been a receiving operation or that there has been an access to the game, an increase request may be generated within the game server 20 and output to the increase unit 210.

In addition, when the user performs an operation on the terminal 10 to request the play of a given game (including the execution of Gacha), a reduction request (request for reduction) in which the amount of in-game currency required to play the game is defined as the reduction amount ( A reduction request sent from the terminal 10 to the game server 20, a reduction request generated within the game server 20 according to information received from the terminal 10) is received by the reduction unit 212, and the reduction unit 212 reduces the balance 320 of the user. is reduced by the amount of reduction specified in the reduction request. Further, when the user performs an operation on the terminal 10 to request the purchase of an in-game item, the reduction unit 212 receives a reduction request that specifies the amount of in-game currency necessary for purchasing the in-game item as the reduction amount. , the reduction unit 212 reduces the balance 320 of the user by the amount of reduction determined by the reduction request. In addition, the user requests a refund of unused in-game currency, or the unused in-game currency is refunded to the user due to service termination, and the refund associated with the refund is completed (for example, when the billing server 30 The game server 20 receives a notification that the refund has been completed) and a reduction request that specifies the amount of in-game currency equivalent to the refund amount as the reduction amount (the game server 20 receives a notification from the billing server 30, PF server, or external device). A reduction request sent to the user, a reduction request generated within the game server 20 according to information received from the billing server 30, the PF server, or an external device) is received by the reduction unit 212, and the reduction unit 212 The balance 320 is reduced by the amount of reduction determined by the reduction request.

Here, in this embodiment, when a reduction request specifying a reduction amount greater than the balance 320 is received, the balance 320 is changed to a value less than 0. For example, when the balance of in-game currency is "500" and the balance is decreased by the reduction amount "1,000", the balance becomes "-500". Note that only when the balance 320 is to be reduced by refunding in-game currency, the balance 320 can be changed to a value less than 0 (accepting a reduction request that specifies a reduction amount greater than the balance 320), and game play requests and When the balance 320 is to be reduced by a request to purchase an in-game item, the balance 320 may not be changed to a value less than 0 (a reduction request specifying a reduction amount greater than the balance 320 may not be accepted). Additionally, if there is both free in-game currency and paid in-game currency, only the balance of the paid in-game currency can be changed to a value less than 0, and the balance of the free in-game currency can be changed to a value less than 0. You may also make it so that it cannot be changed. In addition, when communication between the game server 20 and the billing server 30 cannot be performed normally, or when an abnormal signal is received from the billing server 30, the game server 20 enters a state in which the billing server 30 cannot perform payment processing normally. If it is determined that there is, in that case, the balance of the in-game currency may be changed to a value less than zero. In addition, it is possible to change the balance of in-game currency to a value less than 0 when the device that performs the necessary processing to increase in-game currency through billing is not limited to the billing server 30. You may also do so. In this case, it is necessary to be able to reduce the in-game currency and manage the in-game currency only with devices that can operate normally. When an abnormality occurs, the normal device performs various processes, and after the abnormality is recovered, changes related to game data that occurred during the abnormality, such as the history of in-game currency consumption and the amount of in-game currency, are stored in the system. be consistent between devices. In addition, when consuming in-game currency to run a limited-time event game, or when consuming in-game currency to purchase a limited-time in-game item, near the end time of the period (e.g. , one hour before the end time), the balance of in-game currency may be changed to a value less than zero.

Further, in this embodiment, as shown in FIG. 4, the balance 320 may be managed by the sum of a first parameter 330 with a value of 0 or more and a second parameter 340 with a value of 0 or less. Furthermore, when displaying the user's in-game currency balance 320 on the display unit 190 of the user's terminal 10, the first parameter 330 and the second parameter 340 may be displayed separately (distinguishably). good. In this case, when an increase request that specifies the amount of increase in in-game currency is received, even if the second parameter 340 has a value less than 0, the first parameter 330 may be increased by the amount of increase. . For example, in the example shown in FIG. 4, if the user with user ID "002" purchases "1,000" of in-game currency and increases the balance 320 of the user by the increase amount "1,000", the user The first parameter 330 of is increased from "0" to "1,000", and the balance 320, which is the sum of the first parameter 330 ("1,000") and the second parameter 340 ("-500"), is "500". In this way, by checking the first parameter 330 when purchasing in-game currency, the user can easily recognize that the balance of in-game currency has certainly increased by the purchased amount (specified increase amount). I can do it. Note that when the value of the first parameter 330 of the user is greater than 0 and the value of the second parameter 340 is less than 0, the first parameter 330 is decreased by the specified amount and the second parameter 340 is decreased by the user's operation. may be increased by the specified amount. Further, when a reduction request that specifies the amount of decrease in in-game currency is received, the first parameter 330 may be decreased by the amount of decrease, or the second parameter 340 may be decreased by the amount of decrease. You may also do so. In addition, when displaying the user's in-game currency balance 320 on the display unit 190 of the user's terminal 10, if the balance 320 is less than 0, the balance 320 may be displayed in red letters, etc. The balance may be displayed in a different display mode than when the value is greater than 0), or the balance may be displayed as "0" in red letters or the like. Further, when there is both free in-game currency and paid in-game currency, the balance of free in-game currency and the balance of paid in-game currency may be displayed separately. Furthermore, the user may be able to specify whether the first parameter or the second parameter is to be increased by the increase request. Furthermore, the user may be able to specify whether the first parameter or the second parameter is to be decreased by the decrease request. In this case, the increase request or decrease request itself may include an increase destination or decrease destination that indicates which parameter is to be changed, or after accepting the increase request or decrease request, the request may be changed by the user's operation. It may also be possible to specify an increase destination or a decrease destination. Also, for example, if a request for an increase of "5,000" is received (if the user has purchased only "5,000" of in-game currency), the first parameter is increased by "2,000", For example, the second parameter may be increased by "3,000", so that the user or the like may be able to specify the destination of the increase, the amount to be increased, the distribution, etc. Similarly, when a reduction request is received, the user or the like may be able to specify the reduction destination, reduction amount, allocation, etc. In this case, if necessary, the user's terminal 10 may display a dialog or the like on the game screen for the user to specify the destination for increase (destination for decrease), allocation, etc.

In addition, in this embodiment, a user's past game usage history (in-game currency increase/decrease history, game play history, etc.) is stored as the game usage history 350 in association with the user ID of the user, and It is possible to determine whether the usage history satisfies a given trust condition and change the in-game currency balance of a user who satisfies the trust condition to a value less than 0 (accepting a reduction request that specifies a reduction amount greater than the balance). ), and the in-game currency balance of a user who does not satisfy the trust condition may not be changed to a value less than 0 (a reduction request specifying a reduction amount greater than the balance may not be accepted). For example, the history of increases and decreases in the user's in-game currency is stored, and if the number of times the user's in-game currency balance has become a value less than 0 is large, and the balance has become a value less than 0, it has become a value greater than or equal to 0. It may be determined that the user's game usage history satisfies the reliability condition if the time it took to reach the target is short, or if the lowest historical value of the user's in-game currency balance is high. In addition, if a user has a long game play history (a long time has elapsed since the start of the game, a large number of games have been played), it is determined that the user's game play history satisfies the trust condition. It's okay.

Further, in this embodiment, when the balance of the user's in-game currency becomes a value less than 0, a given restriction may be imposed on the user. In this case, when decreasing the balance of the user's in-game currency, if the balance becomes a value less than 0 due to the decrease, the user is notified of this (displaying a notification on the display unit 190). Good too. Note that a restriction may be imposed when the total value (balance) of the first parameter and the second parameter becomes a value less than zero. In this case, by displaying the first parameter and the second parameter separately or by allowing the user to specify which parameter to increase, the user can increase the first parameter without being restricted. After setting the value to a value of 0 or more, it is possible to decide whether to purchase an in-game item by consuming in-game currency while checking the value of each parameter. For example, when the first parameter is "0" and the second parameter is "-500", the first parameter is increased to "1,000" because if it continues as it is, it will be restricted. After that, when a desired item A that consumes ``600'' in-game currency and a desired item B that consumes ``500'' in-game currency appear, select item B to avoid the restriction. It is possible to decide whether to accept the restrictions and select item A without making a new charge. Note that although the total value (balance) of the first parameter and the second parameter is 0 or more, a restriction may be imposed when the second parameter is less than 0. For example, if the first parameter is "2,000" and the second parameter is "-500", the combined balance is a value greater than or equal to 0 ("1,500"), but the second parameter is less than 0. Since it is a value (“-500”), a limit is given. In this case, in order to avoid being restricted, the user's intention (operation) is to subtract "500" from the first parameter and increase the second parameter by "500". You can set it to 0. In cases where there are such restrictions, if it is possible to increase or decrease each parameter, the following can be achieved. For example, after the second parameter becomes "-2,000" and the user is restricted, the user charges to increase the in-game currency by "10,000" and changes the first parameter to "10,000". 000'' and the second parameter is set to ``-2,000''. In this case, although there are restrictions, the first parameter can be consumed until the desired in-game item is obtained without making a new charge, and the first parameter remains after obtaining the desired in-game item. If so, the user can select to use the surplus amount to set the second parameter to a value of 0 or more without charging a new fee, which improves convenience.

The given restriction may be a restriction on the consumption of in-game currency by the user. As a restriction on the consumption of in-game currency, when reducing the balance (consuming in-game currency) by requesting to play a game or request to purchase an in-game item, the balance of the user's in-game currency must be 0 or more. The balance can only be reduced when the balance is less than 0 (accepting a reduction request based on a play request or a purchase request), and the balance cannot be reduced when the balance is less than 0 (a reduction request based on a play request or a purchase request is accepted). The request may not be accepted). In addition, as a restriction on the consumption of in-game currency, when the balance is less than 0, the period in which the balance can be reduced is limited, and after that period, the balance will be reduced unless it is reduced to a value greater than 0. You may also make it impossible to do so. For example, if the balance of the user's in-game currency becomes less than 0 in January, the balance can be reduced during January, but if the balance is not reduced to more than 0 in February, the balance will be reduced. It may also be possible to make it impossible to reduce. Additionally, as a restriction on the consumption of in-game currency, a lower limit value (for example, "-10,000") of the balance less than 0 is set, and the balance cannot be reduced to a value less than the lower limit value. Good too.

Further, as the given restriction, a restriction that is disadvantageous to the progress of the game may be given. For example, when a user's in-game currency balance becomes less than 0, the recovery speed of the stamina value (a parameter that recovers over time) required for the user's game play may be reduced, or the stamina value (parameter that recovers over time) may be reduced. The maximum value may be lowered, the ability value of the user's character may be lowered, or the user may be unable to use strong characters (for example, characters with high rarity) in the game. The user may be able to play only some games (for example, unable to perform Gasha), the game stage may not be released to the user, or the user may It may be possible to disable multiplayer, or the user may be excluded from rankings. In addition, the history of acquisition of in-game items by the user's consumption of in-game currency is stored, and if the balance becomes a value less than 0 as a result of the user consuming in-game currency to acquire in-game items. In addition, the use of the in-game items acquired at that time may be restricted (such as making them unusable, limiting the usable period or number of times they can be used, etc.). Also,
The use of in-game items acquired within a predetermined period of time from the time when the balance becomes less than 0 may be restricted.

Further, as a given restriction, a restriction regarding the provision of free in-game currency may be given. For example, if free in-game currency is given (distributed) to a user as a login bonus or benefit, if the user's in-game currency balance becomes less than 0, the user will receive free in-game currency. The provision of currency may be stopped or the amount distributed may be reduced.

In addition, from the time the user's in-game currency balance becomes less than 0 until the balance becomes 0 or more, the user is given a given restriction, and the user is given a certain limit until the balance becomes 0 or more. In such a case, the restriction may be lifted. In addition, a given restriction is imposed on the user for a predetermined period of time after the user's in-game currency balance becomes less than 0 (regardless of whether or not the balance becomes 0 or more). If the balance reaches a value of 0 or more during the predetermined period, the restriction may be canceled in the next period following the predetermined period. In addition, after the user's in-game currency balance becomes less than 0, the user will not be given a given restriction for a predetermined period of time, and after the predetermined period has passed, the balance becomes 0 or more. If this is not the case, a given restriction may be given to the user.

In addition, the user's past game usage history (in-game currency increase/decrease history, game play history) is stored as the game usage history 350 in association with the user ID of the user, and the game usage history is It may be determined whether or not the conditions are met, and the given restrictions given to users who meet the trust conditions may be relaxed. For example, the history of increases and decreases in the user's in-game currency is stored, and if the number of times the user's in-game currency balance has become a value less than 0 is large, and the balance has become a value less than 0, it has become a value greater than or equal to 0. The shorter the time it took to reach the user's in-game currency balance, and the higher the historical lowest value of the user's in-game currency balance, the trust condition is satisfied and the restrictions on in-game currency consumption are relaxed (for example, You may lengthen the period during which the user's in-game currency balance can be less than 0, lower the lower limit of the balance less than 0, or relax restrictions that are disadvantageous to game progress ( For example, it may be possible to reduce the recovery speed of stamina value or the extent to which the maximum value is reduced, or to shorten the period during which the use of in-game items is restricted, or to ease restrictions on the granting of free in-game currency. (For example, the period during which free in-game currency is suspended may be shortened, or the amount of distribution may be reduced to a lesser degree). Furthermore, the longer the user has played the game, the more restrictions on in-game currency consumption may be relaxed, assuming that the trust condition is satisfied, or the restrictions that are disadvantageous to the game progress may be relaxed. , restrictions regarding the provision of free in-game currency may be relaxed. In addition, reliability based on the user's past game usage history (for example, the number of times the user's in-game currency balance has become a value less than 0, and the balance has become a value less than 0 and then a value greater than 0) The shorter the time it took to reach the limit, the higher the historical minimum of the user's in-game currency balance, the longer the user's gameplay history, the higher the value), the easier the restrictions will be for the user. You may also do so. Note that a given restriction given to a user determined not to satisfy the trust condition may be strengthened (made more severe). In addition, the restrictions given to users who are determined to meet the trust conditions are less strict than the restrictions given to users who are determined not to meet the trust conditions, and the restrictions given to users who are determined to meet the trust conditions are uniformly (same). (to a certain extent).

Also, only when the balance is reduced by refunding in-game currency, a given limit is given to the user when the balance becomes a value less than 0, and the balance is reduced by requesting to play the game or purchasing in-game items. In this case, the given limit may not be imposed on the user even if the balance becomes a value less than 0. In addition, the types of restrictions given to the user when the balance becomes a value less than 0, whether the balance is reduced by refunding in-game currency or by a play request or purchase request. You may change it. For example, it is better to reduce a user's balance by refunding in-game currency than to reduce the balance by requesting to play or make a purchase. You may choose to make it stricter. Also, regardless of whether or not the balance has become a value less than 0, a given limit is given to the user, and it is determined whether the user's past game usage history satisfies the trust condition, and the trust condition is A given restriction may be relaxed for a user who satisfies the above requirements, or the higher the reliability (degree of trust) based on the user's past game usage history, the more relaxed the given restriction is for the user. .

Furthermore, in this embodiment, each game ID of a plurality of games played by the user is managed in association with the user's user ID (ID for identifying the user and the user's terminal 10), and the game ID of each game is managed. Table information 300 for managing the balance of in-game currency in each game may be stored in association with the ID. In this case, if the balance of in-game currency associated with a game ID associated with the user's user ID is less than 0, the balance is transferred to a game associated with another game ID associated with the user ID. It may also be carried over as a balance of local currency. For example, if the balance of in-game currency managed by the game "A" that the user is playing is "-500", and the user starts playing another game "B", the game "A" Instead of changing the balance of in-game currency managed in game "B" from "-500" to "0", change the balance of in-game currency managed in game "B" from the initial value "0" at the start of the game to "-" 500". In addition, if the user is already playing another game "C", instead of reducing the balance of in-game currency managed by game "C" by "500", the balance of in-game currency managed by game "A" will be reduced by "500". The balance of the in-game currency to be played may be changed from "-500" to "0". In addition, the balance of in-game currency managed in game "A" played by the user that has become a value less than 0 will be carried over as the balance of in-game currency managed in another game "B" played by the user. In this case, a given restriction given to the user in game "A" may be inherited as a given restriction given to the user in game "B". Furthermore, the balance of in-game currency and given restrictions may be carried over only when given conditions are met. For example, if the balance of in-game currency managed by the game "A" that the user is playing becomes less than 0, the user stops playing the game "A" (for example, if the user stops playing the game "A" ”), if the user withdraws from the game “A”, or if the user deletes the game “A” app from the terminal 10, the balance and the amount given to the user will be The given restriction may be carried over to another game "B" played by the user. For example, in addition to the user ID of the user in the game "A", a terminal ID for identifying the user's terminal 10 and a user ID of the user in the PF server are set, and the user's user ID in the game "A" is set. When the balance of in-game currency managed by the user ID is less than 0, the game is accessed using the user ID of the user on the PF server or the terminal ID of the user's terminal 10. In this case, the in-game currency balance and given limits managed by the user ID in game "A" are inherited as the in-game currency balance and given limits managed by the user ID and terminal ID in the PF server. You can do it like this. In addition, at the request of the user or service provider, the balance of in-game currency managed in game "A" played by the user may be reduced, and the balance of in-game currency managed in game "B" played by the user may be reduced. The currency balance may be increased by the amount of the decrease.

According to this embodiment, the balance of in-game currency is managed in a range from a value of 0 or more to a value of less than 0, and when a reduction request specifying a reduction amount greater than the balance is received, the balance becomes less than 0. Even if the balance of in-game currency is insufficient, you can play the game or obtain in-game items without making a new charge (purchasing in-game currency). This makes it possible to flexibly implement services that use in-game currency. for example,
When purchasing a prepaid card at a store and paying for it, even if the balance is insufficient, the in-game currency can be consumed without going out of your way to buy a prepaid card. Also, if you want to run the game or purchase in-game items when your balance is insufficient, an error occurs in the communication between the billing server 30 and the game server 20, making it impossible to communicate. In-game currency can be consumed even if an abnormality occurs in the communication between the devices that make up the game system. Allowing in-game currency to be spent even when there is insufficient balance is particularly useful when spending in-game currency to run limited-time event games or to purchase limited-time in-game items. be. Furthermore, according to the present embodiment, after the user's in-game currency balance becomes a value less than 0 until it becomes a value greater than or equal to 0, or after a predetermined period of time has elapsed after the balance becomes a value less than 0. If the balance is not a value of 0 or more, certain restrictions are imposed on the user (restrictions on the consumption of in-game currency, restrictions that are disadvantageous to game progress, restrictions on the granting of free in-game currency) ), the user is prompted to increase the balance of in-game currency that has become less than 0 to a value greater than or equal to 0, and the balance of in-game currency becomes a value less than 0. This can be suppressed.

3. Processing Next, an example of the processing of the game system (game server 20) of this embodiment will be described using the flowchart of FIG. 5.

First, the reduction unit 212 determines whether a reduction request specifying the amount of reduction in in-game currency has been received from the terminal 10 (step S10). If a reduction request has not been received (N in step S10), the process moves to step S14. When a reduction request is received (Y in step S10), the reduction unit 212 reduces the balance of in-game currency associated with the user ID of the user of the terminal 10 by the reduction amount specified in the reduction request. (Step S11). Next, the restriction unit 218 determines whether or not the user's in-game currency balance has changed from a value of 0 or more to a value of less than 0 (step S12), and if the balance has become a value of less than 0; (Y in step S12), a given restriction is given to the user (step S13).

Next, the increase unit 210 determines whether an increase request specifying an increase amount of in-game currency has been received from the terminal 10 (step S14). If an increase request has not been received (N in step S14), the process moves to step S20. When the increase request is received (Y in step S14), the increase unit 210 transmits a payment request for the amount corresponding to the increase amount determined in the increase request to the billing server 30 (step S15), and It is determined whether or not a notification to the effect that the payment has been completed has been received from (step S16). If the notification that the payment has not been completed has not been received (N in step S16) (if the notification that the payment has not been completed has been received), the process moves to step S20. If a notification that the payment has been completed is received (Y in step S16), the balance of the in-game currency associated with the user ID of the user of the terminal 10 is increased by the amount of increase specified in the increase request. (Step S17). Next, the restriction unit 218 determines whether the user's in-game currency balance has changed from a value less than 0 to a value greater than or equal to 0 (step S18), and if the balance has become a value greater than or equal to 0; (Y in step S18), the given restriction given to the user is canceled (step S19).

Next, the processing unit 200 determines whether or not to continue the process (step S20), and if the process is to be continued (Y in step S20), the process moves to step S10.

The present invention is not limited to what has been described in the above embodiments, and can be implemented in various modifications. For example, terms cited as broad or synonymous terms in the description or drawings can be replaced with broad or synonymous terms in other descriptions in the specification or drawings.

DESCRIPTION OF SYMBOLS 10... Terminal, 20... Game server, 30... Billing server, 100... Processing section, 110... Game processing section, 120... Image generation section, 130... Sound generation section, 150... Input section, 170... Storage section, 190... Display Section, 192... Sound output section, 196... Communication section, 200... Processing section, 210... Increase section, 212... Decrease section, 214... Management section, 216... Display control section, 218... Limiting section, 270... Storage section, 272 ...Storage section, 296...Communication section

Claims (18)

A game system that manages the balance of in-game currency consumed for playing a game or purchasing in-game items by associating it with user identification information,
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
a management unit that manages the balance changed by the increase unit and the decrease unit in association with identification information of the user in a range from a value of 0 or more to a value of less than 0;
The decreasing part is
Only when a reduction request is received that specifies the reduction amount that is greater than the balance when the payment processing for purchasing the in-game currency or the processing for increasing the in-game currency cannot be performed normally; A game system characterized by changing the balance to a value less than 0. A game system that manages the balance of in-game currency consumed for playing a game or purchasing in-game items by associating it with user identification information,
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
a management unit that manages the balance changed by the increase unit and the decrease unit in association with identification information of the user in a range from a value of 0 or more to a value of less than 0;
The decreasing part is
If a reduction request is received that specifies the reduction amount that is greater than the balance, change the balance to a value less than 0,
further comprising a restriction unit that applies a given restriction to the user when the balance of the user becomes a value less than 0,
The restriction part is
Only when the balance becomes a value less than 0 due to the refund accompanying the refund of the in-game currency, the above restriction is given to the user, or the balance becomes less than 0 due to the refund accompanying the refund of the in-game currency. The game system is characterized in that the type of the restriction given to the user is changed depending on whether the balance becomes a value less than 0 due to the execution of the game or the purchase of the in-game item. In claim 2,
The restriction part is
A game system characterized in that the higher the reliability based on the user's past game usage history, the more relaxed the restrictions given to the user are. In claim 2 or 3,
The restriction part is
A game system characterized by imposing restrictions on consumption of the in-game currency by a user. In any one of claims 2 to 4,
The restriction part is
A game system characterized by giving restrictions that are disadvantageous to the progress of the game. In any one of claims 2 to 5,
The restriction part is
A game system characterized in that the restriction is applied to the user until the user's balance reaches a value of 0 or more. In any one of claims 2 to 6,
The restriction part is
A game system characterized in that, after the user's balance becomes a value less than 0, if the balance does not become a value of 0 or more after a predetermined period has elapsed, the restriction is given to the user. . In any one of claims 1 to 7,
The management department is
A game system characterized in that the balance that has become a value less than 0 is inherited as the balance managed by another game. In claim 8 depending on any one of claims 2 to 7,
The management department is
A game system characterized in that the restriction given to the user is inherited as the restriction given to the user in the other game. In claim 8 or 9,
The management department is
A game system characterized in that the balance is transferred when a given condition is met. In any one of claims 1 to 10,
The increased portion is
When an increase request with an increase amount specified by the user is received, a payment request for the amount corresponding to the increase amount is sent to the billing server, and the amount is settled on the billing server in response to the payment request. A game system characterized in that the balance is increased by the increase amount. In any one of claims 1 to 11,
The management department is
managing the balance as a total value of a first parameter having a value of 0 or more and a second parameter having a value of 0 or less;
The increased portion is
A game system characterized in that, when an increase request that specifies an increase amount of the in-game currency is received, the first parameter is increased by the increase amount. In claim 12,
The game system further includes a display control section that distinguishes the first parameter and the second parameter and causes them to be displayed on a display section of a user's terminal. In any one of claims 1 to 13,
The management department is
It is determined whether a user's past game usage history satisfies a given trust condition, the balance of the user who satisfies the trust condition can be changed to a value less than 0, and the balance of the user who does not satisfy the trust condition is changed to a value less than 0. A game system characterized in that a balance cannot be changed to a value less than 0. A program for managing the balance of in-game currency consumed for playing a game or purchasing in-game items in association with user identification information, the program comprising:
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
causing the computer to function as a management unit that manages the balance changed by the increase unit and the decrease unit in association with identification information of the user in a range from a value of 0 or more to a value of less than 0;
The decreasing part is
Only when a reduction request is received that specifies the reduction amount that is greater than the balance when the payment processing for purchasing the in-game currency or the processing for increasing the in-game currency cannot be performed normally; A program characterized by changing the balance to a value less than 0. A program for managing the balance of in-game currency consumed for playing a game or purchasing in-game items in association with user identification information, the program comprising:
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
causing the computer to function as a management unit that manages the balance changed by the increase unit and the decrease unit in association with identification information of the user in a range from a value of 0 or more to a value of less than 0;
The decreasing part is
If a reduction request is received that specifies the reduction amount that is greater than the balance, change the balance to a value less than 0,
further causing the computer to function as a restriction unit that imposes a given restriction on the user when the balance of the user becomes a value less than 0;
The restriction part is
Only when the balance becomes a value less than 0 due to the refund accompanying the refund of the in-game currency, the above restriction is given to the user, or the balance becomes less than 0 due to the refund accompanying the refund of the in-game currency. The program is characterized in that the type of restriction given to the user is changed depending on whether the balance becomes a value less than 0 due to execution of the game or purchase of the in-game item. A game service providing method in which a server that manages the balance of in-game currency consumed for playing the game or purchasing in-game items by associating it with user identification information provides the game service in response to a request from a terminal. There it is,
The server is
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
a management unit that manages the balance changed by the increase unit and the decrease unit in association with the user's identification information in a range from a value of 0 or more to a value of less than 0;
The decreasing portion is
Only when a reduction request is received that specifies the reduction amount that is greater than the balance when the payment processing for purchasing the in-game currency or the processing for increasing the in-game currency cannot be performed normally; When changing the balance to a value less than 0,
A game service providing method characterized in that the terminal transmits the increase request and the decrease request to a server. A game service providing method in which a server that manages the balance of in-game currency consumed for playing the game or purchasing in-game items by associating it with user identification information provides the game service in response to a request from a terminal. There it is,
The server is
an increase unit that increases the balance by the increase amount when an increase request that specifies the increase amount of the in-game currency is received;
a reduction unit that reduces the balance by the amount of reduction when a reduction request that specifies the amount of reduction of the in-game currency is received;
a management unit that manages the balance changed by the increase unit and the decrease unit in association with identification information of the user in a range from a value of 0 or more to a value of less than 0;
The decreasing portion is
If a reduction request is received that specifies the reduction amount that is greater than the balance, change the balance to a value less than 0,
The server further includes a restriction unit that applies a given restriction to the user when the balance of the user becomes a value less than 0, and
The restriction part is
Only when the balance becomes a value less than 0 due to the refund accompanying the refund of the in-game currency, the above restriction is given to the user, or the balance becomes less than 0 due to the refund accompanying the refund of the in-game currency. In the case where the type of restriction given to the user is changed depending on the case where the balance becomes a value less than 0 due to the execution of the game or the purchase of the in-game item,
A game service providing method characterized in that the terminal transmits the increase request and the decrease request to a server.

Images