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 technology]

[0002] There are so-called social games that are provided to users' mobile devices such as smartphones and allow them to interact with other users via the Internet. These social games employ a payment system that allows users to obtain advantageous items and characters by paying a fee.

[0003] Also known is an item lottery function that allows a user to randomly obtain items that can be used in a game (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2004-41561 A Summary of the Invention [Problem to be solved by the invention]

[0005] In conventional games, the billing system was independent for each game, and users were charged for each game. If a user wanted to play multiple games more advantageously than others, the user had to pay for each game. For users, consolidating billing into one game allows them to play games more advantageously than distributing billing across multiple games. Therefore, the games that users play are limited to the few games for which they have paid, and it is difficult to create motivation to play games other than the games for which they have paid.

[0006] The present invention has been made in view of the above circumstances, and an object of the present invention is to increase the motivation for users to play multiple games by charging a fee. [Means for solving the problem]

[0007] According to the present invention, there is provided a game management system comprising a receiving unit and an awarding unit, wherein the receiving unit receives a charge from a user, and the awarding unit awards to the user in-game currency for each of a plurality of games, the in-game currency being converted based on the charge amount of the charge.

[0008] With this configuration, charges made by the user are awarded as in-game currency in multiple games, enabling the user to play each of the multiple games with an advantage over others, thereby increasing the user's motivation to play multiple games.

[0009] Various embodiments of the present invention will be described below. The embodiments described below can be combined with each other. Each feature constitutes an invention independently.

[0010] Preferably, the plurality of games are included in a predetermined group, and the reception unit receives a charge from the user for the predetermined group. Preferably, the plurality of games are included in a predetermined group, and the reception unit receives a charge from the user for any one of the games included in the predetermined group. Preferably, the granting unit grants to the user in-game currency for each of the plurality of games, which is converted based on the charge amount and a coefficient for each of the plurality of games. Preferably, the game system further includes a target amount setting unit, which sets a target amount for each of the plurality of games among the charge amounts received from the user, to be converted into in-game currency, 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, the game device further includes a first storage unit and a second storage unit, the first storage unit stores history information of charges received from the user, the second storage unit stores history information on the grant of in-game currency for each of the multiple games granted to the user based on the charges received from the user, and the target amount setting unit sets at least a part of the amount of the charges received from the user that has not been granted in-game currency for each of the multiple games to the target amount for each of the multiple games based on the information stored in the first storage unit and the second storage unit. Preferably, for a game that has been provided after the user's charge, the target amount setting unit calculates a cumulative charge amount for a predetermined period based on the charge history information and sets the target amount. Preferably, the first storage unit stores the predetermined period for each of the multiple games. Preferably, the second storage unit sets an upper limit of the in-game currency for each of the multiple games. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram showing an overview of a game management system 100 according to a first embodiment of the present invention. [Diagram 2] 2 is a block diagram showing a hardware configuration of a management server 30. FIG. [Diagram 3] FIG. 2 is a block diagram showing the functional configuration of the game management system 100. [Figure 4] Fig. 4A is a diagram showing a table configuration of the billing history storage unit 42. Fig. 4B is a diagram showing a table configuration of the currency information storage unit 44. [Diagram 5] FIG. 1 is a diagram showing an overview of a game management system 200 according to a second embodiment. [Figure 6] FIG. 2 is a block diagram showing the functional configuration of the game management system 200. [Figure 7] Fig. 7A is a diagram showing a table configuration of billing history storage unit 142. Fig. 7B is a diagram showing a table configuration of currency information storage unit 144. [Figure 8] 10 is a diagram illustrating the relationship between a charged amount and a granted amount in the game management system 200. FIG. [Figure 9] FIG. 11 is a diagram showing an overview of a game management system 300 according to a third embodiment. [Figure 10] FIG. 2 is a block diagram showing the functional configuration of the game management system 300. [Figure 11] Fig. 11A is a diagram showing a table configuration of billing history storage unit 242. Fig. 11B is a diagram showing a table configuration of currency information storage unit 244. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] <1. First embodiment> (1.1. Overview of the Game Management System 100) An overview of a game management system 100 according to a first embodiment will be described with reference to Fig. 1. 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 able to communicate with a user terminal 10. The game providing system 50 is realized by a plurality of server devices.

[0013] The user terminal 10 is realized 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 charges from users and manages billing information. The game providing system 50 is configured to be able to provide multiple games. The game providing system 50 classifies the multiple games into predetermined groups and manages them.

[0014] A user specifies one of the multiple classified groups for a game provided by the game providing system 50 and makes a payment. The management server 30 accepts a payment from the user and provides the user with in-game currency for each of the multiple games in the group specified by the user, which is converted based on the amount of the payment and a conversion coefficient (hereinafter simply referred to as a coefficient) set for each game. Note that if all of the multiple games belong to the same group, the management server 30 may skip the process of having the user specify a group.

[0015] With this configuration, charges made by the user are awarded as in-game currency in multiple games, enabling the user to play each of the multiple games with an advantage over others, thereby increasing the user's motivation to play multiple games.

[0016] Here, a group may be, for example, a company that provides a game, and games provided by that company may be classified into the same group. By classifying multiple games released by one company into the same group, a user can play each of the multiple games released by that company more advantageously than others by paying for the group, which can increase the motivation for users to play multiple games.

[0017] (1.2. Hardware Configuration of Management Server 30) The hardware configuration of the management server 30 will be described with reference to Fig. 2. Note that since the game providing system 50 can be implemented by the configuration of the management server 30, the description will not be repeated.

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

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

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

[0021] (1.3. Functional Configuration of the Game Management System 100) The functional configuration of the game management system 100 will be described with reference to Fig. 3. As described above, the game management system 100 includes the management server 30 and the game providing system 50.

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

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

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

[0025] The granting unit 43 refers to the charge history table T1 and the granting coefficient table T2, and grants the user in-game currency for each of the multiple games, which is converted based on the user's charge. The granting of in-game currency based on the charge will be described in detail 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 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. The configuration of the currency granting table T3 will be described in detail later. The providing unit 47 is configured to be able to provide a plurality of games to the user.

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

[0029] When the function is realized by executing a program, the program may be stored in the auxiliary storage unit 33 or in a non-transitory recording medium readable by a computer. The function may also be realized by reading out a program stored in an external storage device and using so-called cloud computing. When the function is realized by hardware, the function may be realized by various circuits such as ASIC, SOC, FPGA, or DRP.

[0030] (1.4. Table configuration of billing history storage unit 42 and currency information storage unit 44) The table configuration of billing history storage unit 42 and currency information storage unit 44 will be described with reference to Fig. 4A and Fig. 4B. Billing history storage unit 42 includes a billing history table T1 and an allotting coefficient table T2. Currency information storage unit 44 includes a currency allotting table T3.

[0031] (1.4.1. Billing History Table T1) The billing history table T1 is a table that stores the history of billing by users. 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 a record in the billing history table T1. The user ID column holds a user ID for uniquely identifying the user who made the billing.

[0032] The charging group column holds the group name designated by the user when charging. 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 designate a group and perform charging.

[0033] The charge amount (yen) column holds the amount charged to the user (hereinafter also referred to as the charge amount). The charge date column holds the date on which the user was charged.

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

[0035] (1.4.2. Assignment coefficient table T2) The award coefficient table T2 is a table that stores a conversion coefficient for converting a user's billing amount into in-game currency for each game provided by the game providing system 50. The award coefficient table T2 has a game ID column, a game name column, a game group column, and a coefficient column. The game ID column holds a game ID for uniquely identifying multiple 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 that the game is classified in. The coefficient column holds the conversion coefficient used to convert the charge for the game.

[0037] The granting unit 43 refers to the charge history table T1 and the granting coefficient table T2, and registers in-game currencies for each of a plurality of games, which are converted based on the user's charge amount, in a currency granting table T3.

[0038] (1.4.3. Currency Grant Table T3) The currency granting table T3 is a table that stores history information of the in-game currency granted by the granting unit 43. As shown in Fig. 4B, the currency granting table T3 has a No. column, a charge ID column, a grant target game column, a currency grant amount (yen) column, and an addition date column.

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

[0040] The "Granted Game" column holds the name of the game to which the in-game currency was granted by the granting unit 43. The "Granted Currency Amount (yen)" column holds the amount of in-game currency granted by the granting unit 43 based on the user's billing amount and a conversion coefficient. The "Addition Date" column holds the date on which the granting unit 43 granted the in-game currency.

[0041] In-game currency is awarded in units of the currency in the target game (or items equivalent to the currency). Therefore, the currency awarding table T3 may include a column for holding amounts in units of the in-game currency corresponding to each game (or the number of items equivalent to the currency).

[0042] (1.4.4. Flow of in-game currency granting) The granting of in-game currency by the granting unit 43 will be described below using the case of billing ID=3 (record R1 in billing history table T1) as an example. When the accepting unit 41 accepts a billing of 10,000 yen from a user, it registers record R1 of billing ID=3 in the billing history table T1.

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

[0044] In the granting coefficient table T2, the conversion coefficients for the 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 the user 10,000 yen, 10,000 yen, and 5,000 yen, which are obtained by multiplying the charge amount of 10,000 yen by the conversion coefficient, as in-game currency for the games A1, A2, and A3 belonging to group A, and registers the amounts in the currency granting table T3 (see record R3 in the currency granting table T3 / corresponding to FIG. 1).

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

[0046] With this configuration, the user's charges are awarded as in-game currency in multiple games, allowing the user to play each of the multiple games with an advantage over others, thereby increasing the user's motivation to play multiple games. Also, by including many games in a group, the user can enjoy a variety of games within the group, realizing long-term use by the user.

[0047] <2. Second embodiment> An overview of a game management system 200 according to the second embodiment will be described with reference to Figures 5 to 8. Note that the following description will focus on the differences from the first embodiment.

[0048] (2.1. Overview of the Game Management System 200) An overview of the game management system 200 will be described with reference to Fig. 5. As shown in Fig. 5, the game management system 200 differs from the first embodiment in that the user pays a fixed monthly fee to the management server 130.

[0049] The management server 130, which has accepted a monthly flat-rate charge from a user, grants in-game currency every month for a plurality of games provided by the game providing system 150. Meanwhile, for a new game released after the user's flat-rate charge has begun, the management server 130 grants in-game currency for the total amount of the charge for the month of release and the charge accumulated up to the month of release.

[0050] (2.2. Functional configuration of the game management system 200) The functional configuration of the game management system 200 will be described with reference to Fig. 6. The game management system 200 includes a management server 130 and a game providing system 150.

[0051] 6, the management server 130 includes a receiving unit 141, a charge history storage unit 142, an awarding unit 143, a providing unit 147, and 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, out of the charge amounts received from the user.

[0052] Specifically, for a game that has already been released when the user's billing starts, the target amount setting unit 145 sets the monthly billing amount as the target amount, while for a game that is released after the user's billing starts, the target amount is set to the sum of the billing amount for the month of release and the billing amount accumulated up to the month of release.

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

[0054] (2.3. Table configuration of billing history storage unit 142 and currency information storage unit 144) 7A and 7B, the table configurations of the billing history storage unit 142 and the currency information storage unit 144 will be described. The billing history storage unit 142 includes a billing history table T11, an allotted coefficient table T12, and a release condition table T13. The currency information storage unit 144 includes a currency allotted table T14.

[0055] (2.3.1. Billing History Table T11) As shown in Fig. 7A, billing history table T11 has a billing start date column instead of the billing date column in billing history table T1 of Fig. 4. The billing start date column holds the date when flat-rate billing by the user started.

[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 time of game release and the charge accumulation period 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 charge accumulation period (months) column.

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

[0058] (2.3.3. Flow of in-game currency granting) The granting of in-game currency by the granting unit 143 will be described below using as an example the case where the billing ID is 1 (record R11 in the billing history table T11). When the accepting unit 141 accepts the start of a flat-rate billing of 3000 yen from the user, it registers record R11 with the billing ID=1 in the billing history table T11.

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

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

[0061] The granting unit 143 grants in-game currency for the 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 granting coefficient table T12, and registers the in-game currency in the currency granting table T14. In this way, every time a monthly flat-rate charge is made, history information of the granted in-game currency is registered in the currency granting table T14 (record R14 in the currency granting table T14).

[0062] In contrast, when game A4 is released after the start of flat-rate charging for charging ID=1 (see record R13 in release condition table T13), the target amount setting unit 145 refers to the release condition table T13 and acquires the cumulative charging period for game A4. Then, based on the flat-rate charging amount (3000 yen) in the month game A4 was released and the charging amount (6000 yen) corresponding to the cumulative period (2 months) for game A4, it sets the target amount (9000 yen) for conversion into in-game currency. The granting unit 143 grants in-game currency for game A4 based on the target amount set by the target amount setting unit 145 and the conversion coefficient (1) for game A4 held in the coefficient column of the granting coefficient table T12, and registers the history information in the currency granting table T14 (corresponding to record R15).

[0063] The relationship between the charged amount and the granted amount in the above-mentioned game management system 200 will be described with reference to Fig. 8. As shown in Fig. 8, for existing games A1 to A3, an amount obtained by multiplying the fixed charged amount by a conversion coefficient is granted as in-game currency every month for a user's charge that began in January. In contrast, for game A4, which was released after the user's fixed-rate charge began, a portion of the charge before release (i.e., the amount before the in-game currency is granted) is also subject to conversion into in-game currency.

[0064] In this way, the game management system 200 further includes a target amount setting unit 145, which sets a target amount to be converted into in-game currency from the fixed amount charged from the user. For games that are provided after the start of the user's fixed amount charging, the target amount setting unit 145 calculates the cumulative charge amount for a predetermined period based on charging history information and sets the target amount. The granting unit 143 grants the in-game currency converted based on the set target amount.

[0065] With this configuration, each time a new game is released, the user is given the amount of in-game currency that they have accumulated through previous charges, which motivates the user to play new games. Also, because the system is a flat-rate charging system, as the number of users using the system increases, customer attraction increases, which motivates new users to enter the game.

[0066] <3. Third embodiment> An overview of a game management system 300 according to a third embodiment will be described with reference to FIGS.

[0067] (3.1. Overview of the Game Management System 300) An overview of the game management system 300 will be described with reference to Fig. 9. As shown in Fig. 9, the game management system 300 differs from the above-described embodiment in that it does not include a management server.

[0068] A user specifies a game and makes a charge to the game providing system 250. The game providing system 250 grants in-game currency to the game specified by the user that is the subject of a charge and to other games in the group to which the specified game belongs.

[0069] (3.2. Functional configuration of the game management system 300) The functional configuration of the game management system 300 will be described with reference to Fig. 10. 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 charge 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 billing history storage unit 242 and currency information storage unit 244) 11A and 11B, the table configurations of billing history storage unit 242 and currency information storage unit 244 will be described. Billing history storage unit 242 includes a billing history table T21 and a grant ratio table T22. Currency information storage unit 244 includes a currency grant table T23.

[0071] (3.3.1. Billing History Table T21) As shown in Fig. 11A, the charge history table T21 has a charge-based game column instead of the charge group column in the charge history table T1 of Fig. 4. The charge-based game column holds the names of games for which a charge is required, designated by the user.

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

[0073] (3.3.3. Flow of in-game currency granting) The granting of in-game currency by the granting unit 243 will be described below using as an example the case of billing ID=2 (record R21 in billing history table T21). When the accepting unit 241 accepts a billing of 6000 yen from the user, it registers record R21 of billing ID=2 in the billing history table T21.

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

[0075] In the grant ratio table T22, the conversion coefficients for games A1, A2, and A3 belonging to group A are 1, 1, and 0.5, respectively (see record R22 in the grant ratio table T22). That is, the charge amount for games A1 and A2 is converted into in-game currency at a rate twice that of game A3. For a charge amount of 6,000 yen, the granting unit 243 grants 12,000 yen, 12,000 yen, and 6,000 yen as in-game currency to games A1, A2, and A3, and registers them in the currency granting table T23 (corresponding to record R23 of the currency granting table T23 / FIG. 9).

[0076] In this manner, in the game management system 300, the receiving unit 241 receives a charge from a user for any one of the games included in a specified group, and the granting unit 243 grants to the user the in-game currency for each of the multiple games, which is converted based on the charge amount.

[0077] By adopting such a configuration, it becomes unnecessary to have a configuration such as a management server and a game providing system, and therefore it becomes possible to apply the present invention with a simpler configuration. <4. Other embodiments>

[0078] Although the embodiment and its modified examples of the present invention have been described above, the application of the present disclosure is not limited to the above. For example, in the above embodiment, the user terminal 10 is realized as a mobile terminal such as a smartphone, but the present disclosure 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] The currency information storage unit may also be configured to set an upper limit for the amount of in-game currency granted to a user for each of a plurality of games. In this way, in the case of flat-rate charges, for example, it is possible to prevent problems such as a significant loss of interest due to an excessive accumulation of charges, which can upset the balance between users in the game.

[0080] In the second embodiment, the user may be able to change the monthly billing amount as appropriate. In this case, the billing history table T11 may have a billing change date column.

[0081] In the above embodiment, the user is charged in yen, but the present invention is not limited to this example. For example, the user may be charged in a foreign currency such as dollars, or in cryptocurrency (virtual currency) based on cryptography such as blockchain. Alternatively, the user may be charged in points issued by a specific company that can be used when shopping.

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

[0083] Furthermore, the present invention can also be realized as a computer-readable non-transitory recording medium storing the above-mentioned 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, substitutions, and modifications can be made without departing from the spirit of the invention. The embodiments and their modifications are included within the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

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

Claims

1. accepting a flat-rate charge from a user once per predetermined period for a first game group including a first game and a second game having a different release date from the first game; controlling the user to acquire at least one of an item and an in-game currency that can be used in the first game during the first period based on the one-time fixed amount charge for the first period; controlling the user to acquire at least one of an item and an in-game currency that can be used in the second game during the first period based on the one-time fixed-amount charge for the first period; said one-time fixed-amount charge for said first period does not provide said user with at least one of an item and an in-game currency that can be used in a game included in a second game group different from said first game group during said first period; system.

2. when a third game is added to the first game group during a second period that is later than the first period, control is performed so that the user can acquire, during the second period, at least one of an item and an in-game currency usable in the first game, at least one of an item and an in-game currency usable in the second game, and at least one of an item and an in-game currency usable in the third game, based on a fixed-amount charge equal to the one-time fixed-amount charge for the second period; The system of claim 1 .

3. the computer accepts a flat-rate charge from a user once per predetermined period for a first group of games including a first game and a second game having a different release date from the first game; the computer allows the user to acquire at least one of an item and an in-game currency that can be used in the first game during the first period based on the one-time fixed-amount charge for the first period; the computer allows the user to acquire at least one of an item and an in-game currency that can be used in the second game during the first period based on the one-time fixed-amount charge for the first period; the computer does not provide the user with at least one of an item and an in-game currency that can be used in a game included in a second game group different from the first game group during the first period, as a result of the one-time fixed charge for the first period; Information processing methods.

Images