JP7699322B2 - Game Management System - Google Patents

Description

The present invention relates to a game management system.

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

Furthermore, there is known an item lottery function that allows players to randomly obtain items that can be used in a game (see, for example, Patent Document 1).

JP 2004-41561 A

In conventional games, the billing system was separate for each game, and users paid for each game. If a user wanted to play multiple games with an advantage over others, the user had to pay for each game. Since consolidating the billing into one game allows users to play games with a greater advantage than spreading the billing across multiple games, the games that users play are limited to the few games for which they have paid, and users are less motivated to play games other than those for which they have paid.

The present invention was made in consideration of these circumstances, and its purpose is to increase users' motivation to play multiple games by charging a fee.

According to the present invention, a game management system is provided that includes a reception unit and an awarding unit, in which the reception 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.

By configuring it in this way, the user's fees 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.

Various embodiments of the present invention are exemplified below. The embodiments shown below can be combined with each other. Furthermore, each feature constitutes an invention independently.

Preferably, the multiple games are included in a predetermined group, and the reception unit accepts a charge from the user for the predetermined group. Preferably, the multiple games are included in a predetermined group, and the reception unit accepts 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 multiple games, which is converted based on the charge amount and a coefficient for each of the multiple games. Preferably, the system further includes a target amount setting unit, which sets a target amount for each of the multiple 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 multiple games, which is converted based on the target amount for each of the multiple 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 portion of the amount of the charges received from the user that has not been granted in-game currency for each of the multiple games as a 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 is started to be 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.

1 is a diagram showing an overview of a game management system 100 according to a first embodiment of the present invention. FIG. 2 is a block diagram showing the hardware configuration of a management server 30. FIG. 2 is a block diagram showing the functional configuration of the game management system 100. 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. FIG. 11 is a diagram showing an overview of a game management system 200 according to a second embodiment. FIG. 2 is a block diagram showing the functional configuration of the game management system 200. Fig. 7A is a diagram showing a table configuration of the billing history storage unit 142. Fig. 7B is a diagram showing a table configuration of the currency information storage unit 144. 10 is a diagram illustrating the relationship between the charged amount and the awarded amount in the game management system 200. FIG. FIG. 13 is a diagram showing an overview of a game management system 300 according to a third embodiment. FIG. 2 is a block diagram showing the functional configuration of the game management system 300. Fig. 11A is a diagram showing a table configuration of the billing history storage unit 242. Fig. 11B is a diagram showing a table configuration of the currency information storage unit 244.

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.

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.

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 grants the user 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 the 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.

By configuring it in this way, the user's fees 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.

Here, a group may be, for example, a company that provides games, 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 with an advantage over others by paying for the group, thereby increasing the motivation for users to play multiple games.

(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.

Figure 2 is a block diagram showing the 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.

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 for transmitting and receiving various data between the other information processing devices. It may also include an operation input unit 35, which is composed of a keyboard, mouse, etc., and accepts input of various operations, and a monitor 36, such as a liquid crystal display device, for displaying various images.

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 each other 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 send and receive various data with other information processing devices, etc. via the communication unit 34.

(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.

(1.3.1. Management Server 30)
3, the 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 the main control unit 31. The billing history storage unit 42 is realized as a function of the auxiliary storage unit 33.

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

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 allocation coefficient table T2. The configurations of the billing history table T1 and the allocation coefficient table T2 will be described in detail later.

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)

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

The currency information storage unit 44 stores historical 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 below. The providing unit 47 is configured to be able to provide multiple games to the user.

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 it may be realized by hardware.

When it is realized by executing a program, the program may be stored in the auxiliary storage unit 33, or may be stored in a non-transitory recording medium that can be read by a computer. It may also be realized by reading out a program stored in an external storage device, so-called cloud computing. When it is realized by hardware, it can be realized by various circuits such as an ASIC, an SOC, an FPGA, or a DRP.

(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 Figs. 4A and 4B. Billing history storage unit 42 includes billing history table T1 and grant coefficient table T2. Currency information storage unit 44 includes currency grant table T3.

(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 a user who made a bill.

The charging group column holds the group name specified by the user when charging. In the game management system 100, the multiple games provided by the game providing system 50 are classified into predetermined groups, and the user is configured to specify a group when charging.

The Charged Amount (yen) column holds the amount charged by the user (hereinafter referred to as the charged amount). The Charged Date column holds the date on which the user was charged.

In this way, the billing history table T1 stores the history of billing by the user, and the reception unit 41 accepts billing from the user and registers it in the billing history table T1.

(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 charged 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.

The game group column holds the name of the group to which the game belongs. The coefficient column holds the conversion coefficient used to convert the charge for the game.

The granting unit 43 refers to the billing history table T1 and the granting coefficient table T2, and registers the in-game currency of each of the multiple games, which is converted based on the user's billing amount, in the currency granting table T3.

(1.4.3. Currency Granting 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.

The No. column holds a sequential number for uniquely identifying records in the currency granting table T3. The charge ID column is an external key to the charge ID column in the charge history table T1, and holds a charge ID linked to the granting of in-game currency by the granting unit 43.

The "Granted Game" column holds the name of the game to which the granting unit 43 granted in-game currency. 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 the conversion coefficient. The "Addition Date" column holds the date on which the granting unit 43 granted in-game currency.

Note that 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 that holds the amount in units of the in-game currency corresponding to each game (or the number of items equivalent to the currency).

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

The granting unit 43 refers to the billing history table T1 and the granting coefficient table T2, and registers the amount of in-game currency granted based on the billing amount in the currency granting table T3. Here, since the charge for billing ID = 3 was charged to 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.

In the granting coefficient table T2, the conversion coefficients for games A1, A2, and A3 in group A are 1, 1, and 0.5, respectively (see record R2 in the granting coefficient table T2). Therefore, the granting unit 43 multiplies the charge amount of 10,000 yen by the conversion coefficient to grant the user 10,000 yen, 10,000 yen, and 5,000 yen as in-game currency for games A1, A2, and A3 in group A, and registers this in the currency granting table T3 (see record R3 in the currency granting table T3/corresponding to Figure 1).

As described above, the game management system 100 according to this 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 the user in-game currency for each of a plurality of games, which is converted based on the charge.

By configuring it in this way, 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, which increases the user's motivation to play multiple games. Also, by including many games in a group, users can enjoy a variety of games within the group, which leads to long-term user usage.

<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. The following description will focus on the differences from the first embodiment.

(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.

The management server 130, which accepts a monthly flat-rate charge from a user, grants in-game currency every month for multiple games provided by the game provision system 150. On the other hand, for new games 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.

(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.

As shown in FIG. 6, the management server 130 includes a reception unit 141, a charge history storage unit 142, a granting unit 143, a provision 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 from the charge amounts received from the user.

Specifically, for games that have already been released at the time that the user starts paying, the target amount setting unit 145 sets the monthly charge amount as the target amount. On the other hand, for games that are released after the user starts paying, the target amount is set to the sum of the charge amount for the month of release and the charge amount accumulated up to the month of release.

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.

(2.3. Table configurations 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.

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

(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.

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 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.

(2.3.3. Flow of granting in-game currency)
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 receiving unit 141 receives a request from the user to start a flat-rate billing of 3,000 yen, the receiving unit 141 registers record R11 with billing ID=1 in the billing history table T11.

The target amount setting unit 145 sets the target amount to be converted into in-game currency for each of the multiple games included in the charging group, from the charging amount received from the user.

Here, at the time record R11 was registered, games A1 to A3 had already been released (see record R12 in release condition table T13). Therefore, the target amount setting unit 145 sets the fixed charge amount of 3,000 yen as the target amount for conversion into in-game currency.

The granting unit 143 grants 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 stored in the coefficient column of the granting coefficient table T12, and registers the amount in the currency granting table T14. In this way, each time a monthly flat-rate charge is made, historical information on the granted in-game currency is registered in the currency granting table T14 (record R14 in the currency granting table T14).

In contrast, when game A4 is released after the start of flat-rate charging with charging ID=1 (see record R13 in the release condition table T13), the target amount setting unit 145 references the release condition table T13 and obtains the cumulative charging period for game A4. Then, based on the flat-rate charging amount (3,000 yen) for the month game A4 was released and the charging amount (6,000 yen) equivalent to the cumulative period (2 months) for game A4, it sets the target amount (9,000 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).

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

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

By configuring it this way, each time a new game is released, users are given the amount of in-game currency that they have accumulated through previous charges, which motivates users to play new games. Also, because it is a flat-rate charge system, as the number of users using the system increases, customer attraction increases, which motivates new users to enter the game.

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

(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 embodiment in that it does not include a management server.

The user specifies a game and makes a payment to the game providing system 250. The game providing system 250 grants in-game currency to the game specified by the user for which payment is required, and to other games in the group to which the game belongs.

(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.

(3.3. Table configurations of billing history storage unit 242 and currency information storage unit 244)
11A and 11B, the table configurations of the billing history storage unit 242 and the currency information storage unit 244 will be described. The billing history storage unit 242 includes a billing history table T21 and a grant ratio table T22. The currency information storage unit 244 includes a currency grant table T23.

(3.3.1. Charging 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.

(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 used when converting a charge amount into in-game currency for the game specified by the user at the time of charging and for that game.

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

The granting unit 243 refers to the charge history table T21 and the grant ratio table T22, and registers the amount of in-game currency granted based on the charge amount in the currency granting table T23. Here, the charge for charge ID = 2 is charged 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 games in group A to which game A3 belongs.

In the grant ratio table T22, the conversion factors 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). In other words, 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 this in the currency granting table T23 (corresponding to record R23 in the currency granting table T23/Figure 9).

In this manner, 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 specified group, and the granting unit 243 grants the user the in-game currency for each of the multiple games, which is converted based on the charge amount.

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

The above describes the embodiment of the present invention and its modified examples, but 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.

The currency information storage unit may also be configured to set an upper limit on the amount of in-game currency granted to a user for each of multiple games. This can prevent problems such as a flat-rate charge, where the charged amount accumulates too much, upsetting the balance between users in the game and causing a loss of interest.

Furthermore, in the second embodiment, the user may be able to change the monthly charge amount as appropriate. In this case, the charge history table T11 may have a charge change date column.

In addition, in the above embodiment, the user is charged in yen units, but this is not limited to the example. For example, the user may be charged in a foreign currency such as dollars, or in cryptocurrency (virtual currency) based on cryptographic technology such as blockchain. Or, the user may be charged in points issued by a specific company that can be used when shopping.

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

Furthermore, the present invention can also be realized as a computer-readable non-transitory recording medium that stores the above-mentioned program.

Various embodiments of the present invention have been described, but these are presented as examples and are not intended to limit the scope of the invention. The novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. The embodiments and their modifications are within the scope and gist of the invention, and are included in the scope of the invention and its equivalents as set forth in the claims.

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: Charge 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 (6)

a processor, the processor comprising :
providing a plurality of games , treating at least a first game and a second game among the plurality of games as one group, and accepting a charge from a user for any one game included in the group;
In-game currency of the user is added in the first game based on the charge ; and
adding an in-game currency of the user in the second game based on the charge;
Information processing device. The processor stores the history information of the in-game currency in a storage unit together with a user ID for uniquely identifying the user who made the charge and identification information of the group.
The information processing device according to claim 1 . The charge is made by points issued by a specific company.
The information processing device according to claim 1 . the processor provides a plurality of games , treats at least a first game and a second game among the plurality of games as one group, and accepts a charge from a user for any one game included in the group;
A processor causes the user's in-game currency to be added in the first game based on the charge ; and
adding an in-game currency of the user in the second game based on the charge;
method. causing a processor to provide a plurality of games, and to accept a charge from a user for any one of the games included in a group including at least a first game and a second game among the plurality of games;
causing a processor to add an in-game currency of the user in the first game based on the charge ;
adding an in-game currency of the user in the second game based on the charge;
program. A terminal device and a server device connected to the terminal device,
The server device includes :
providing a plurality of games , treating at least a first game and a second game among the plurality of games as one group, and accepting a charge from a user for any one game included in the group;
In-game currency of the user is added in the first game based on the charge ; and
adding an in-game currency of the user in the second game based on the charge;
system.

Images