Game management system
The game management system addresses the issue of limited game exploration by converting user charges into in-game currency for multiple games, thereby enhancing user motivation and gaming experience.
Patent Information
- Application Number
- JP2024165375
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2024-09-24
- Publication Date
- 2025-06-27
- Estimated Expiration
- 2039-03-26
AI Technical Summary
In conventional games, the charging system is independent for each game, leading to users being motivated to play only the games for which they have charged, rather than exploring multiple games.
A game management system that includes a reception unit to receive charges from users and a granting unit to convert the charge into in-game currency for multiple games, allowing users to play each game more advantageously.
This system enhances user motivation to play multiple games by allowing charges to be utilized across various games, rather than being limited to a single game, thereby improving overall gaming experience and engagement.
Smart Images

Figure 0007699322000001 
Figure 0007699322000002 
Figure 0007699322000003
Abstract
Description
Technical Field
[0001] The present invention relates to a game management system.
Background Art
[0002] There is a so-called social game provided on a user's mobile terminal such as a smartphone and capable of communicating with other users through an Internet connection. In such a social game, a charging system is introduced in which a user can obtain advantageous items or characters by charging.
[0003] Also known is an item lottery function for randomly obtaining items available in a 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 a plurality of 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 concentrating the charges on one game rather than dispersing the charges among a plurality of games. Therefore, the games played by the user are limited to some of the games for which the user has charged, and it is difficult to motivate the user to play games other than the charged games.
[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 a fee.
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, wherein 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 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 of each of the plurality of games, which is converted based on the payment amount and a coefficient for each of the plurality of games. Preferably, the game further includes a target amount setting unit, and the target amount setting unit sets a target amount to be converted 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 of each of the plurality of games, which is converted based on the target amount set for each of the plurality of games by the target amount setting unit. Preferably, the game further includes a first storage unit and a second storage unit, the first storage unit stores history information of payments received from the user, the second storage unit stores history information regarding the granting of the in-game currency of each of the plurality of games granted to the user based on the payment received from the user, and 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 a game whose 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 sets an upper limit amount of the in-game currency 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
Mode for Carrying Out the Invention
[0012] <1. First Embodiment> (1.1. Overview of the Game Management System 100) Referring to FIG. 1, an overview 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 a 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 makes a charge for a game provided by the game providing system 50 by designating any one of the classified plurality of groups. The management server 30 accepts the charge 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 charge and the conversion coefficient (hereinafter also simply referred to as a coefficient) set for each game. When 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 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.
[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 charge 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 overall operation of the 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 and a mouse and the like that accepts 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 perform access to 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 charging 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 charging history storage unit 42 is realized as a function of the auxiliary storage unit 33.
[0023] The reception unit 41 receives the charge from the user and registers the charge history information in the charge history storage unit 42.
[0024] The charge history storage unit 42 stores the charge history information received from the user. The charge history storage unit 42 includes a charge history table T1 and an assignment coefficient table T2. Details of the configurations of the charge history table T1 and the assignment coefficient table T2 will be described later.
[0025] The awarding unit 43 refers to the charge history table T1 and the assignment coefficient table T2, and awards the in-game currency for each of the plurality of games converted based on the user's charge amount to the user. Details of the awarding of the in-game currency based on the charge 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 awarded by the awarding unit 43. The currency information storage unit 44 includes a currency awarding table T3. Details of the configuration of the currency awarding 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 a CPU (Central Processing Unit) implemented as the main control unit 31 executing a program, or may be realized by hardware.
[0029] When implemented by executing a program, the program may be stored in the auxiliary storage unit 33 or may be stored in a non-transitory computer-readable recording medium. Also, a program stored in an external storage device may be read out and implemented by so-called cloud computing. When implemented by hardware, it can be implemented by various circuits such as an ASIC, an SOC, an FPGA, or a DRP.
[0030] (1.4. Table Configuration of Billing History Storage Unit 42 and Currency Information Storage Unit 44) Referring to FIGS. 4A and 4B, the table configuration 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 a 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. Award Coefficient Table T2) The award coefficient 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 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 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 awarding unit 43 refers to the billing history table T1 and the award coefficient 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 awarding table T3.
[0038] (1.4.3. Currency Awarding Table T3) The currency awarding table T3 is a table that stores the history information of the in-game currency awarded by the awarding unit 43. As shown in FIG. 4B, the currency awarding table T3 has a No column, a billing ID column, an awarding target game column, a currency awarding amount (yen) column, and an addition date column.
[0039] The No column holds a serial number for uniquely identifying a record in the currency awarding 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 awarding of the in-game currency by the awarding unit 43.
[0040] The game series for granting holds the names of the games to which in-game currency is 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 coefficient. The addition date series holds the date on which in-game currency was granted by the granting unit 43.
[0041] Note that the granting of in-game currency is performed 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, regarding the granting of in-game currency by the granting unit 43, the case where the payment ID = 3 (record R1 in the payment history table T1) will be exemplified and explained. When the reception unit 41 receives a payment of 10,000 yen from the user, it registers the 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 made for group A (refer to record R1 in the payment history table T1), the granting unit 43 refers to the granting coefficient table T2 and acquires the conversion coefficient of the games belonging to group A.
[0044] In the granting coefficient table T2, the conversion coefficients of games A1, A2, and A3 belonging to group A are 1, 1, and 0.5, respectively (refer to 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, as in-game currency to the user in games A1, A2, and A3 belonging to group A, and registers them in the currency grant table T3 (refer to 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 to the user the in-game currency of each of a plurality of games converted based on the charged amount.
[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. In addition, 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, an overview 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. Overview of Game Management System 200) With reference to FIG. 5, an overview 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 every month for a plurality of games provided by the game providing system 150. 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 for the month of release and the accumulated charge up to the month of release.
[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, for each of a plurality of games, a target amount to be converted into in-game currency 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 the plurality of games and registers it in the currency information storage unit 144 provided in the game providing system 150.
[0054] (2.3. Table Structures of the Charging History Storage Unit 142 and the Currency Information Storage Unit 144) Referring to FIGS. 7A and 7B, the table structures 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) will be exemplified 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 the 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 for conversion into in-game currency.
[0060] Here, at the time when the record R11 is registered, the games A1 to A3 have already been released (refer to the 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 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 held in the coefficient column of the granting coefficient table T12, and registers it in the currency granting table T14. In this way, each time a monthly fixed charge is made, the history information of the granted in-game currency is registered in the currency granting table T14 (record R14 of the currency granting 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 for conversion to in-game currency (9000 yen) is set. 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) of 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] Referring to FIG. 8, the relationship between the charge amount and the granted amount in the game management system 200 described above will be explained. As shown in FIG. 8, for the charges of the 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 granted 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 granted) is also subject to conversion to in-game currency.
[0064] As described above, 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 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 providing system 250 and makes a charge. The game providing 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 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, the granting of in-game currency by the granting unit 243 will be described by exemplifying the case where the charging ID = 2 (record R21 in the charging history table T21). When the reception unit 241 receives a charge of 6,000 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 billing history table T21 and the granting ratio table T22, and registers the amount of in-game currency granted based on the billing amount in the currency granting table T23. Here, the billing with billing ID = 2 is for game A3 (refer to record R21 in the billing history table T21). Therefore, the granting unit 243 refers to the granting ratio table T22 and obtains 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 billing 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 respectively for the billing 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 the user's billing 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 billing amount to the user.
[0077] With 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] The embodiments and their modifications in the present invention have been described above, but 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 flat-rate 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, the configuration may be such that the user can appropriately change the monthly charging amount. In this case, the charging history table T11 may have a column for the charging change date.
[0081] 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 that causes the management server and the 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 that stores 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 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.
2. The processor stores the history information of the in-game currency in a memory 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 .
3. The charging is carried out by points issued by a specific company. The information processing device according to claim 1 .
4. 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.
5. 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.
6. 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.
Citation Information
Patent Citations
Game program
JP2004041561A
License management method and content processing system
JP2011070524A
Game system, and game control method
JP2014113371A
Server system
JP2015192751A
Game program and game system
JP2018079153A
Cited By
Game management system
JP2025105898A