Game management system

Abstract

To enhance a user's motivation for playing a plurality of games, by performing charging.SOLUTION: A game management system comprises a reception part and an impartation part. The reception part receives charging from a user. The impartation part imparts each in-game currency for each of a plurality of games, which is converted on the basis of the amount of charged money, to the user.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a game management system.

Background Art

[0002] There are so-called social games provided on a user's mobile terminal such as a smartphone and capable of communicating with other users through an Internet line. In such a social game, a charging system is introduced in which by charging a user, items and characters advantageous to the user can be obtained.

[0003] Also known is an item lottery function for randomly obtaining items available in the game (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In conventional games, the charging system is independent for each game, and users charged for each game. When a user wants to play multiple games more advantageously than others, the user has to charge for each game. For the user, it is more advantageous to play the game by aggregating the charges for one game rather than dispersing the charges for multiple games. Therefore, the games played by the user are limited to some of the games for which they have charged, and it is less likely to motivate the user to play games other than the games for which they have charged.

[0006] The present invention has been made in view of such circumstances, and an object of the present invention is to improve the motivation for a user to play a plurality of games by charging fees.

Means for Solving the Problems

[0007] According to the present invention, there is provided a game management system including a reception unit and a granting unit, where the reception unit receives a charge from a user, and the granting unit grants, to the user, in-game currency for each of a plurality of games converted based on the charged amount of the charge.

[0008] With such a configuration, since the charge from the user is granted as in-game currency in a plurality of games, it becomes possible for the user to play each of the plurality of games more advantageously than others, and the motivation for the user to play a plurality of games can be improved.

[0009] Hereinafter, various embodiments of the present invention will be exemplified. The embodiments shown below can be combined with each other. Also, each feature independently constitutes an invention.

[0010] Preferably, the plurality of games are included in a predetermined group, and the reception unit receives payment from the user for the predetermined group. Preferably, the plurality of games are included in a predetermined group, and the reception unit receives payment from the user for any one game included in the predetermined group. Preferably, the granting unit grants to the user the in-game currency for each of the plurality of games, which is converted based on the payment amount and the coefficient for each of the plurality of games. Preferably, it further includes a target amount setting unit, and the target amount setting unit sets a target amount for conversion into in-game currency for each of the plurality of games among the payment amounts received from the user, and the granting unit grants to the user the in-game currency for each of the plurality of games, which is converted based on the target amount for each of the plurality of games set by the target amount setting unit. Preferably, it further includes a first storage unit and a second storage unit. The first storage unit stores the history information of the payments received from the user, and the second storage unit stores the history information regarding the granting of the in-game currency for each of the plurality of games granted to the user based on the payment received from the user. The target amount setting unit sets, based on the information stored in the first storage unit and the second storage unit, at least a part of the payment amount received from the user, which is the amount for which the in-game currency has not been granted to the user for each of the plurality of games, as the target amount for each of the plurality of games. Preferably, for the game for which the provision has started after the user's payment, the target amount setting unit calculates the cumulative payment amount within a predetermined period based on the payment history information and sets the target amount. Preferably, the first storage unit stores the predetermined period for each of the plurality of games. Preferably, the second storage unit has an upper limit amount of the in-game currency set for each of the plurality of games.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Embodiments for Carrying Out the Invention

[0012] <1. First Embodiment> (1.1. Outline of the Game Management System 100) Referring to FIG. 1, the outline of the game management system 100 according to the first embodiment will be described. As shown in FIG. 1, the game management system 100 includes a management server 30 and a game providing system 50, and is configured to be communicable with the user terminal 10. The game providing system 50 is realized by a plurality of server devices.

[0013] The user terminal 10 is implemented by a mobile terminal such as a smartphone owned by a game user (hereinafter simply referred to as a user). The management server 30 is a server that accepts charging from the user and manages charging information. The game providing system 50 is configured to be able to provide a plurality of games. The game providing system 50 classifies and manages a plurality of games into respective predetermined groups.

[0014] The user performs charging by designating any one of the classified plurality of groups for the games provided by the game providing system 50. The management server 30 accepts charging from the user, and grants the user the in-game currency of each of the plurality of games within the group designated by the user, which is converted based on the amount of the charging and the conversion coefficient (hereinafter also simply referred to as a coefficient) set for each game. In the case where all of the plurality of games belong to the same group, the management server 30 may skip the process of designating a group from the user.

[0015] With such a configuration, since the charging from the user is granted as in-game currency in a plurality of games, for the user, it becomes possible to play each of the plurality of games more advantageously than others, and the motivation for the user to play a plurality of games can be improved.

[0016] Here, the group is, for example, a company that provides games, and the games provided by the company may be classified into the same group. By classifying a plurality of games released by one company into the same group, the user can play each of the plurality of games released by the company more advantageously than others with the charging for the group, and the motivation for the user to play a plurality of games can be improved.

[0017] (1.2. Hardware Configuration of Management Server 30) Referring to FIG. 2, the hardware configuration of the management server 30 will be described. Since the game providing system 50 can be implemented by the configuration provided in the management server 30, the description will not be repeated.

[0018] Figure 2 is a block diagram showing the hardware configuration of the management server 30 according to the present embodiment. The management server 30 includes a main control unit 31 that controls the operation of the entire management server 30, a main memory unit 32 used as a work area and the like when executing various programs by the main control unit 31, and an auxiliary storage unit 33 in which various programs and various data are stored in advance.

[0019] Furthermore, the management server 30 is connected to other information processing devices such as the user terminal 10 and the game providing system 50 via a communication line, and includes a communication unit 34 that transmits and receives various data to and from other information processing devices. In addition, it may include an operation input unit 35 composed of a keyboard, a mouse, and the like that receives input of various operations, and a monitor 36 such as a liquid crystal display device that displays various images.

[0020] These main control unit 31, main memory unit 32, auxiliary storage unit 33, communication unit 34, operation input unit 35, and monitor 36 are electrically connected to each other via a system bus 37. Therefore, the main control unit 31 can access the main memory unit 32 and the auxiliary storage unit 33, grasp the operation state of the operation input unit 35, display an image on the monitor 36, and transmit and receive various data to and from other information processing devices via the communication unit 34.

[0021] (1.3. Functional configuration of the game management system 100) Referring to FIG. 3, the functional configuration of the game management system 100 will be described. As described above, the game management system 100 includes a management server 30 and a game providing system 50.

[0022] (1.3.1. Management server 30) As shown in FIG. 3, the management server 30 includes a reception unit 41, a billing history storage unit 42, and a granting unit 43. The reception unit 41 and the granting unit 43 are realized as functions of the main control unit 31. The billing history storage unit 42 is realized as a function of the auxiliary storage unit 33.

[0023] The reception unit 41 receives payment from the user and registers the payment history information in the payment history storage unit 42.

[0024] The payment history storage unit 42 stores the payment history information received from the user. The payment history storage unit 42 includes a payment history table T1 and an assignment coefficient table T2. Details of the configurations of the payment history table T1 and the assignment coefficient table T2 will be described later.

[0025] The assignment unit 43 refers to the payment history table T1 and the assignment coefficient table T2, and assigns in-game currency for each of a plurality of games converted based on the user's payment amount to the user. Details of the assignment of in-game currency based on the payment amount will be described later. (1.3.2. Game providing system 50)

[0026] The game providing system 50 includes a currency information storage unit 44 and a providing unit 47. The currency information storage unit 44 is realized as a function of the auxiliary storage unit 33. The providing unit 47 is realized as a function of the main control unit 31.

[0027] The currency information storage unit 44 stores the history information of the in-game currency granted by the granting unit 43. The currency information storage unit 44 includes a currency granting table T3. Details of the configuration of the currency granting table T3 will be described later. The providing unit 47 is configured to be able to provide a plurality of games to the user.

[0028] The above-described functional configuration can be realized by the CPU (Central Processing Unit) implemented as the main control unit 31 executing a program, or can also be realized by hardware.

[0029] When implemented by executing a program, the program may be stored in the auxiliary storage unit 33 or in a non-transitory computer-readable recording medium. Alternatively, a program stored in an external storage device may be read and implemented by so-called cloud computing. When implemented by hardware, it can be realized by various circuits such as ASIC, SOC, FPGA, or DRP.

[0030] (1.4. Table configurations of the billing history storage unit 42 and the currency information storage unit 44) Referring to FIGS. 4A and 4B, the table configurations of the billing history storage unit 42 and the currency information storage unit 44 will be described. The billing history storage unit 42 includes a billing history table T1 and an assignment coefficient table T2. The currency information storage unit 44 includes a currency assignment table T3.

[0031] (1.4.1. Billing history table T1) The billing history table T1 is a table that stores the billing history of the user. As shown in FIG. 4A, the billing history table T1 has a billing ID column, a user ID column, a billing group column, a billing amount (yen) column, and a billing date column. The billing ID column holds a billing ID for uniquely identifying the records of the billing history table T1. The user ID column holds a user ID for uniquely identifying the user who performed the billing.

[0032] The billing group column holds the group name specified by the user at the time of billing. In the game management system 100, a plurality of games provided by the game providing system 50 are classified into predetermined groups, and the user is configured to perform billing by specifying a group.

[0033] The billing amount (yen) column holds the amount of billing by the user (hereinafter also referred to as the billing amount). The billing date column holds the date on which the user's billing was performed.

[0034] In this way, the billing history table T1 stores the billing history of the user, and the reception unit 41 receives the billing from the user and registers it in the billing history table T1.

[0035] (1.4.2. Coefficient Assignment Table T2) The coefficient assignment table T2 is a table that stores the conversion coefficient for converting the billing amount by the user into in-game currency for each game provided by the game providing system 50. The coefficient assignment table T2 has a game ID column, a game name column, a game group column, and a coefficient column. The game ID column holds the game ID for uniquely identifying a plurality of games provided by the game providing system 50. The game name column holds the name of the game.

[0036] The game group column holds the name of the group to which the game belongs. The coefficient column holds the conversion coefficient when the game is converted from the billing amount.

[0037] The assignment unit 43 refers to the billing history table T1 and the coefficient assignment table T2, and registers the in-game currency of each of the plurality of games converted based on the user's billing amount in the currency assignment table T3.

[0038] (1.4.3. Currency Assignment Table T3) The currency assignment table T3 is a table that stores the history information of the in-game currency assigned by the assignment unit 43. As shown in FIG. 4B, the currency assignment table T3 has a No column, a billing ID column, an assignment target game column, a currency assignment amount (yen) column, and an addition date column.

[0039] The No column holds a serial number for uniquely identifying a record in the currency assignment table T3. The billing ID column is a foreign key to the billing ID column of the billing history table T1 and holds the billing ID associated with the assignment of the in-game currency by the assignment unit 43.

[0040] The game series to which the currency is to be granted holds the names of the games for which in-game currency has been granted by the granting unit 43. The currency grant amount (yen) series holds the amount of in-game currency granted by the granting unit 43 based on the user's payment amount and the conversion factor. The addition date series holds the date on which the in-game currency was granted by the granting unit 43.

[0041] Note that the granting of in-game currency is carried out in the unit of currency (or an item equivalent to currency) in the target game. Therefore, the currency grant table T3 may include a column that holds the amount in the unit of in-game currency corresponding to each game (or the number of items equivalent to currency).

[0042] (1.4.4. Flow of granting in-game currency) Hereinafter, the granting of in-game currency by the granting unit 43 will be described by way of example in the case where the payment ID = 3 (record R1 in the payment history table T1). When the reception unit 41 receives a payment of 10,000 yen from the user, it registers a record R1 with the payment ID = 3 in the payment history table T1.

[0043] The granting unit 43 refers to the payment history table T1 and the granting coefficient table T2, and registers the amount of in-game currency granted based on the payment amount in the currency grant table T3. Here, since the payment with the payment ID = 3 is a payment made to group A (see record R1 in the payment history table T1), the granting unit 43 refers to the granting coefficient table T2 to obtain the conversion coefficient for the games belonging to group A.

[0044] In the granting coefficient table T2, the conversion coefficients for games A1, A2, and A3 belonging to group A are 1, 1, and 0.5 respectively (see record R2 in the granting coefficient table T2). Therefore, the granting unit 43 grants 10,000 yen, 10,000 yen, and 5,000 yen, which are obtained by multiplying the payment amount of 10,000 yen by the conversion coefficient, to the user as in-game currency in games A1, A2, and A3 belonging to group A, and registers them in the currency grant table T3 (see record R3 in the currency grant table T3 / corresponding to FIG. 1).

[0045] As described above, the game management system 100 according to the present embodiment includes a reception unit 41 and a granting unit 43. The reception unit 41 receives a charge from a user, and the granting unit 43 grants in-game currency for each of a plurality of games converted based on the charged amount to the user.

[0046] With such a configuration, since the charge from the user is granted as in-game currency in a plurality of games, for the user, it becomes possible to play each of the plurality of games more advantageously than others, and it is possible to improve the motivation for the user to play a plurality of games. Further, by including many games in the group, the user can enjoy various games within the group, and long-term use by the user is realized.

[0047] <2. Second Embodiment> With reference to FIGS. 5 to 8, the outline of the game management system 200 according to the second embodiment will be described. In the following, the description will focus on the differences from the first embodiment.

[0048] (2.1. Outline of Game Management System 200) With reference to FIG. 5, the outline of the game management system 200 will be described. As shown in FIG. 5, the game management system 200 is different from the first embodiment in that a user makes a monthly fixed charge to the management server 130.

[0049] The management server 130 that has received the monthly fixed charge from the user grants in-game currency for a plurality of games provided by the game providing system 150 every month. On the other hand, for a new game released after the user's fixed charge has started, in-game currency is granted for the total amount of the charge amount in the released month and the accumulated charge amount up to the released month.

[0050] (2.2. Functional Configuration of Game Management System 200) Referring to FIG. 6, the functional configuration of the game management system 200 will be described. The game management system 200 includes a management server 130 and a game providing system 150.

[0051] As shown in FIG. 6, in addition to a reception unit 141, a charging history storage unit 142, a granting unit 143, and a providing unit 147, the management server 130 includes a target amount setting unit 145. The target amount setting unit 145 sets a target amount to be converted into in-game currency for each of a plurality of games among the charging amounts received from the user.

[0052] Specifically, for games that have already been released when the user's charging starts, the target amount setting unit 145 sets the monthly charging amount as the target amount. On the other hand, for games released after the user's charging starts, the target amount setting unit 145 sets the total amount of the charging amount in the month of release and the cumulative charging amount up to the month of release as the target amount.

[0053] Based on the target amount set by the target amount setting unit 145, the granting unit 143 grants in-game currency for each of a plurality of games and registers it in the currency information storage unit 144 provided in the game providing system 150.

[0054] (2.3. Table Configuration of the Charging History Storage Unit 142 and the Currency Information Storage Unit 144) Referring to FIGS. 7A and 7B, the table configuration of the charging history storage unit 142 and the currency information storage unit 144 will be described. The charging history storage unit 142 includes a charging history table T11, a granting coefficient table T12, and a release condition table T13. The currency information storage unit 144 includes a currency granting table T14.

[0055] (2.3.1. Charging History Table T11) As shown in FIG. 7A, the charging history table T11 has a charging start date column instead of the charging date column in the charging history table T1 of FIG. 4. The charging start date column holds the date when the user's fixed-amount charging starts.

[0056] (2.3.2. Release Condition Table T13) The release condition table T13 stores, for each game provided by the game providing system 150, the release time of the game and the cumulative period of charges for which in-game currency is to be granted at the time of release. The release condition table T13 has a game ID column, a game name column, a release date column, and a cumulative charge period (month) column.

[0057] The release date column holds the date on which the game is released. The cumulative charge period (month) column holds the cumulative period of charges before release (corresponding to the "predetermined period" in the claims) that is set as the conversion target for in-game currency when the game is released.

[0058] (2.3.3. Flow of In-Game Currency Grant) Hereinafter, the case where the charge ID = 1 (record R11 in the charge history table T11) is taken as an example to explain the grant of in-game currency by the grant unit 143. When the reception unit 141 receives the start of a fixed charge of 3000 yen from the user, it registers a record R11 with the charge ID = 1 in the charge history table T11.

[0059] The target amount setting unit 145 sets, for each of a plurality of games included in the charge target group among the charge amounts received from the user, the target amount to be converted into in-game currency.

[0060] Here, at the time when record R11 is registered, games A1 to A3 have already been released (refer to record R12 in the release condition table T13). Therefore, the target amount setting unit 145 sets 3000 yen, which is the fixed charge amount, as the target amount for conversion into in-game currency.

[0061] The awarding unit 143 awards in-game currency for Games A1 to A3 based on the target amount set by the target amount setting unit 145 and the conversion coefficient held in the coefficient column of the awarding coefficient table T12, and registers it in the currency awarding table T14. In this way, each time a monthly fixed charge is made, the history information of the awarded in-game currency is registered in the currency awarding table T14 (record R14 of the currency awarding table T14).

[0062] On the other hand, when Game A4 is released after the start of the fixed charge with the charge ID = 1 (refer to record R13 in the release condition table T13), the target amount setting unit 145 refers to the release condition table T13 and acquires the charge accumulation period for Game A4. Then, based on the fixed charge amount (3000 yen) in the month when Game A4 is released and the charge amount (6000 yen) corresponding to the accumulation period (2 months) for Game A4, the target amount (9000 yen) for conversion to in-game currency is set. The awarding unit 143 awards in-game currency for Game A4 based on the target amount set by the target amount setting unit 145 and the conversion coefficient (1) of Game A4 held in the coefficient column of the awarding coefficient table T12, and registers the history information in the currency awarding table T14 (corresponding to record R15).

[0063] Referring to FIG. 8, the relationship between the charge amount and the awarded amount in the above-described game management system 200 will be described. As shown in FIG. 8, for the charges of a user starting from January, for the existing Games A1 to A3, the amount obtained by multiplying the fixed charge amount by the conversion coefficient is awarded as in-game currency every month. On the other hand, for Game A4 released after the start of the user's fixed charge, a part of the charge before the release (that is, the amount for which in-game currency has not been awarded) is also subject to conversion to in-game currency.

[0064] Thus, the game management system 200 further includes a target amount setting unit 145 that sets a target amount to be converted into in-game currency among the fixed charge amounts received from the user. For games whose provision has started after the start of the user's fixed charge, the target amount setting unit 145 calculates the cumulative charge amount for a predetermined period based on the charge history information and sets the target amount. The granting unit 143 grants in-game currency converted based on the set previous target amount.

[0065] With such a configuration, every time a new game is released, the user will be granted the amount accumulated by the previous charges as in-game currency, which serves as an incentive for the user to play the new game. Also, since it is a fixed charge system, when the number of users using the system increases, the customer attraction increases, which serves as an incentive for new users to join.

[0066] <3. Third Embodiment> Referring to FIGS. 9 to 11, the outline of the game management system 300 according to the third embodiment will be described.

[0067] (3.1. Outline of the Game Management System 300) Referring to FIG. 9, the outline of the game management system 300 will be described. As shown in FIG. 9, the game management system 300 is different from the above embodiment in that it does not include a management server.

[0068] The user designates a game to the game provision system 250 and makes a charge. The game provision system 250 grants in-game currency to the game designated by the user as the charge target and other games within the group to which the game belongs.

[0069] (3.2. Functional Configuration of the Game Management System 300) Referring to FIG. 10, the functional configuration of the game management system 300 will be described. The game management system 300 includes a game providing system 250. As shown in FIG. 10, the game providing system 250 includes a reception unit 241, a charging history storage unit 242, a granting unit 243, a currency information storage unit 244, and a providing unit 247.

[0070] (3.3. Table Configuration of the Charging History Storage Unit 242 and the Currency Information Storage Unit 244) Referring to FIGS. 11A and 11B, the table configuration of the charging history storage unit 242 and the currency information storage unit 244 will be described. The charging history storage unit 242 includes a charging history table T21 and a granting ratio table T22. The currency information storage unit 244 includes a currency granting table T23.

[0071] (3.3.1. Charging History Table T21) As shown in FIG. 11A, the charging history table T21 has a charging game column instead of the charging group column in the charging history table T1 of FIG. 4. The charging game column holds the game name of the charging target specified by the user.

[0072] (3.3.2. Granting Ratio Table T22) The granting ratio table T22 has a ratio column instead of the coefficient column in the granting coefficient table T2 of FIG. 4. The ratio column holds the conversion ratio when converting the charging amount into in-game currency for the game specified by the user at the time of charging and the game.

[0073] (3.3.3. Flow of Granting In-Game Currency) Hereinafter, taking the case where the charging ID = 2 (record R21 in the charging history table T21) as an example, the granting of in-game currency by the granting unit 243 will be described. When the reception unit 241 receives a charge of 6000 yen from the user, it registers a record R21 with the charging ID = 2 in the charging history table T21.

[0074] The granting unit 243 refers to the charging history table T21 and the granting ratio table T22, and registers the amount of in-game currency granted based on the charging amount in the currency granting table T23. Here, the charge with charge ID = 2 is a charge for game A3 (refer to record R21 in the charging history table T21). Therefore, the granting unit 243 refers to the granting ratio table T22 and acquires the conversion coefficient of the games within group A to which game A3 belongs.

[0075] In the granting ratio table T22, the conversion coefficients of games A1, A2, and A3 belonging to group A are 1, 1, and 0.5, respectively (refer to record R22 in the granting ratio table T22). That is, for game A3, the charging amounts of games A1 and A2 are converted into in-game currency at a ratio of 2 times. The granting unit 243 grants 12,000 yen, 12,000 yen, and 6,000 yen as in-game currency for games A1, A2, and A3 with respect to the charging amount of 6,000 yen, and registers them in the currency granting table T23 (corresponding to record R23 in the currency granting table T23 / Figure 9).

[0076] As described above, in the game management system 300, the reception unit 241 receives a charge from a user for any one of the games included in a predetermined group, and the granting unit 243 grants each in-game currency of a plurality of games converted based on the charging amount to the user.

[0077] By adopting such a configuration, it is not necessary to adopt a configuration such as a management server and a game providing system, so the present invention can be applied with a simpler configuration. <4. Other Embodiments>

[0078] Although the embodiments and their modifications in the present invention have been described above, the application of the present disclosure is not limited to the above content. For example, in the above embodiment, the user terminal 10 is realized as a mobile terminal such as a smartphone, but it is not limited to this example. For example, the user terminal 10 may be realized by installing software on a home PC or the like.

[0079] In addition, the currency information storage unit may be configured such that an upper limit of in-game currency given to the user is set for each of a plurality of games. By doing so, in the case of fixed-amount charging or the like, it is possible to prevent problems such as the balance among users in the game being greatly disrupted due to excessive accumulation of the charging amount, and the loss of interest.

[0080] Also, in the second embodiment, it may be configured such that the user can appropriately change the monthly charging amount. In this case, the charging history table T11 may have a charging change date column.

[0081] Also, in the above embodiment, the charging by the user is performed in yen, but it is not limited to this example. For example, it may be performed in a foreign currency such as the dollar, or in a cryptocurrency (virtual currency) based on cryptographic technology such as blockchain. Or it may be performed using points that can be used at the time of shopping issued by a specific company.

[0082] Furthermore, the present invention can also be realized as a program for causing a management server and a game providing system to function in order to realize the above-described system.

[0083] Furthermore, the present invention can also be realized as a computer-readable non-transitory recording medium storing the above-described program.

[0084] Although various embodiments of the present invention have been described, these are presented as examples and are not intended to limit the scope of the invention. The novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. The embodiments and their modifications are included in the scope and gist of the invention, and are also included in the invention described in the claims and its equivalent scope.

Explanation of Signs

[0085] 10: User terminal 30,130: Management server 31: Main control unit 32: Main memory unit 33: Auxiliary memory unit 34: Communication unit 35: Operation input unit 36: Monitor 37: System bus 41,141,241: Reception unit 42,142,242: Billing history memory unit 43,143,243: Granting unit 44,144,244: Currency information memory unit 47,147,247: Provision unit 145: Target amount setting unit 50,150,250: Game provision system 100,200,300: Game management system

Claims

1. A game management system comprising a reception unit and a granting unit, wherein the reception unit receives charging from a user, and the granting unit grants to the user in-game currency for each of a plurality of games converted based on the charging amount of the charging.

2. The game management system according to claim 1, wherein the plurality of games are included in a predetermined group, and the reception unit receives charging from the user for the predetermined group.

3. The game management system according to claim 1, wherein the plurality of games are included in a predetermined group, and the reception unit receives charging from the user for any one game included in the predetermined group.

4. The game management system according to any one of claims 1 to 3, wherein the granting unit grants to the user in-game currency for each of the plurality of games converted based on the charging amount and a coefficient for each of the plurality of games.

5. The game management system according to any one of claims 1 to 4, further comprising a target amount setting unit, wherein the target amount setting unit sets, for each of the plurality of games, a target amount to be a conversion target of in-game currency among the charging amounts received from the user, and the granting unit grants to the user in-game currency for each of the plurality of games converted based on the target amount for each of the plurality of games set by the target amount setting unit.

6. The game management system according to claim 5, further comprising a first storage unit and a second storage unit, wherein the first storage unit stores history information of charging received from the user, the second storage unit stores history information regarding granting of in-game currency for each of the plurality of games granted to the user based on the charging received from the user, and the target amount setting unit, based on the information stored in the first storage unit and the second storage unit, sets at least a part of the charging amount received from the user for which the user has not been granted in-game currency for each of the plurality of games as the target amount for each of the plurality of games.

7. The game management system according to claim 6, wherein, for the game whose provision is started after the user's payment, the target amount setting unit calculates the cumulative payment amount within a predetermined period based on the payment history information and sets the target amount.

8. The game management system according to claim 7, wherein the first storage unit stores the predetermined period for each of the plurality of games.

9. The game provision system according to any one of claims 6 to 8, wherein the second storage unit sets an upper limit amount of the in-game currency for each of the plurality of games.

Images