Information processing systems, information processing methods, servers, and programs

Abstract

To enable a player to restrict game play by the player themself.SOLUTION: An information processing system includes a lottery request receiving unit that receives, from a player, a lottery request requesting a lottery for selecting one of multiple game media usable in a game, a lottery condition receiving unit that receives, from the player, a setting instruction of lottery conditions that are conditions related to the lottery, and a determination unit that determines, upon receiving the lottery request, whether the lottery request satisfies the lottery conditions.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to an information processing system, an information processing method, a server, and a program.

Background Art

[0002] Patent Document 1 discloses a technique for enhancing the flexibility of parental controls in a game, in which a parent (guardian) manages and suppresses the actions of a child (protected person). The server system described in Patent Document 1 restricts the play of the game by the child if the use of the electronic payment medium by the child during the play of the game conflicts with the restriction conditions preset by the parent.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the above-described server system and the like cannot set or relax the game restrictions only on the child's game device. Therefore, for example, it was not possible to avoid impulsively repeating gacha by oneself.

[0005] An object of the present disclosure is to provide an information processing system, an information processing method, a server, and a program that allow a game player to restrict the play of the game by oneself.

Means for Solving the Problems

[0006] To solve the above-mentioned problems, the information processing system relating to this disclosure includes a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one of several game media usable in the game, and a setting instruction for lottery conditions, which are the conditions for the lottery. The aforementioned It includes a lottery condition reception unit that receives requests from players, and a determination unit that, upon receiving a lottery request, determines whether or not the lottery request satisfies the lottery conditions. [Effects of the Invention]

[0007] According to the information processing system described in this disclosure, players will be able to restrict their own gameplay. [Brief explanation of the drawing]

[0008] [Figure 1] The configuration of the game system 1 of Embodiment 1 is shown. [Figure 2] The configuration of the server device 2 in Embodiment 1 is shown. [Figure 3] The configuration of the player terminal 3 in Embodiment 1 is shown. [Figure 4] An example of the Game GM screen for Embodiment 1 is shown. [Figure 5] The configuration of the game media information GBJ in Embodiment 1 is shown. [Figure 6] The lottery condition CJ for Embodiment 1 is shown. [Figure 7] This is a flowchart showing the operation of the game system 1 of Embodiment 1. [Figure 8] This is an example of a flowchart showing the operation of the game system 1 of Embodiment 2. [Figure 9] This is another example of a flowchart illustrating the operation of the game system 1 of Embodiment 2. [Figure 10] The achievement level MT and benefits TT for Embodiment 3 are shown. [Figure 11] This is a flowchart showing the operation of the game system 1 of Embodiment 3. [Figure 12] The player conditions PJ of Embodiment 4 are shown. [Figure 13] Shows the proposed information TAJ of Embodiment 4. [Figure 14] It is a flowchart showing the operation of the game system 1 of Embodiment 4. [Figure 15] Shows the content of the message ME of Embodiment 5. [Figure 16] It is a flowchart showing the operation of the game system 1 of Embodiment 5. [Figure 17] Shows the restart information SKJ of Embodiment 6. [Figure 18] It is a flowchart showing the operation of the game system 1 of Embodiment 6. [Figure 19] It is a flowchart showing the operation of the game system 1 of Embodiment 7. [Figure 20] Shows the charging history KR of Embodiment 8. [Figure 21] It is a flowchart showing the operation of the game system 1 of Embodiment 8. [Figure 22] Shows the difference information JYSJ of Embodiment 9. [Figure 23] It is a flowchart showing the operation of the game system 1 of Embodiment 9.

Modes for Carrying Out the Invention

[0009] Embodiments of the game system according to the present disclosure will be described.

[0010] 〈Embodiment 1〉 The game system 1 of Embodiment 1 will be described.

[0011] 〈Configuration of Embodiment 1〉 〈Configuration of the game system 1〉 FIG. 1 shows the configuration of the game system 1 of Embodiment 1.

[0012] The game system 1 of Embodiment 1 includes a server device 2 and player terminals 3(1) to 3(m) (where m is an integer of 2 or more), as shown in Figure 1. The server device 2 and player terminals 3(1) to 3(m) are interconnected via a network 5 (e.g., the Internet).

[0013] Player terminals 3(1) to 3(m) are used by players 4(1) to 4(m). For example, player terminal 3(1) is used by player 4(1), player terminal 3(2) is used by player 4(2), ..., player terminal 3(m) is used by player 4(m).

[0014] In the following, for the sake of ease of explanation and understanding, multiple identical devices may be referred to collectively by a single name; for example, player terminals 3(1) to 3(m) may be collectively referred to as player terminal 3.

[0015] In the game system 1 of Embodiment 1, as shown in Figure 1, player 4 transmits various input information such as the lottery condition CJ and the lottery request CY from player terminal 3 to server device 2 via network 5. Server device 2 can perform the lottery C or send a notification T to player terminal 3 of player 4 via network 5.

[0016] The lottery conditions CJ, lottery request CY, lottery C, and notification T will be described later.

[0017] <Configuration of Server Device 2> Figure 2 shows the configuration of the server device 2 in Embodiment 1.

[0018] The server device 2 of Embodiment 1, as shown in Figure 2, includes a control unit 21, a storage unit 22, an input unit 23, an output unit 24, and a communication unit 25.

[0019] As shown in Figure 2, the control unit 21 includes a lottery condition reception unit 21A, a lottery request reception unit 21B, a determination unit 21C, a decision unit 21D, a notification unit 21E, a lottery unit 21F, a prize determination unit 21G, a prize granting unit 21H, a proposal unit 21J, a switching unit 21K, and a calculation unit 21L.

[0020] As shown in Figure 2, the memory unit 22 stores game media information GBJ, lottery conditions CJ, lottery request CY, bonus information TTJ, proposal information TAJ, restart information SKJ, billing history KR, and difference information JYSJ.

[0021] The functions of the control unit 21 (including the functions of the lottery condition reception unit 21A to the calculation unit 21L) and the functions of the storage unit 22 to the communication unit 25 will be described later.

[0022] <Configuration of Player Terminal 3> Figure 3 shows the configuration of the player terminal 3 in Embodiment 1.

[0023] The player terminal 3 of Embodiment 1, as shown in Figure 3, includes a control unit 31, a storage unit 32, an input unit 33, an output unit 34, and a communication unit 35.

[0024] The functions of the control unit 31 to the communication unit 35 will be explained when describing the operation of the game system 1.

[0025] <Game GM, Game medium GB, Bonus TT> The types of game GMs are not particularly limited and may include, for example, competitive games, puzzle games, action games, baseball games, soccer games, other sports games, quiz games, pinball games, card games, rhythm games, RPGs (role-playing games), location-based games, board games, adventure games, casino games, simulation games, strategy games, racing games, etc.

[0026] In Embodiment 1, the output unit 34 (see Figure 3) of the player terminal 3 displays the game GM screen played by player 4, as shown in Figure 4. The game GM includes, for example, game media GB and bonus TT. The game GM screen can display icons requesting a lottery and icons requesting the setting of conditions related to the lottery. The output unit 34 outputs images, sounds, and vibrations via a touch panel, display, speaker, vibration, etc.

[0027] Game media GB are, for example, characters, items, and cards representing them used in the game. Player 4, who plays Game GM, can acquire game media GB, for example, through lottery C (so-called gacha). Game media GB can be acquired through various methods, such as payment, completing and clearing quests, synthesizing game media, and using specific items. It may also be automatically granted by the system at predetermined times, such as when the player first runs the game or when a predetermined stage is reached through game execution. The lottery is not limited to gacha; it may also be a drop from completing game elements such as quests (a process that randomly grants game media upon completion of game elements). Furthermore, the game may include multiple types of lotteries, and a table associated with multiple game media is stored for each type of lottery. The server device can execute a lottery selected based on the player's input information.

[0028] The bonus TT is something that benefits Player 4 within the game GM. TT This is not limited to anything that is beneficial to the player within the game, and may include, for example, the granting of in-game currency, in-game points, or various items (in-game content), the relaxation (including partial removal) or removal (granting the right to perform various functions) of various in-game restrictions, the modification (increase, decrease) of various parameters (level, experience points, stamina, ability values ​​of in-game items, amount that can be borrowed), the raising of parameter upper limits, the lower limits, the recovery of stamina, etc. Also, benefits TTThis may include changes to the type of game medium, winning probability, rarity, acquisition amount (number) in processes involving various draws (gacha, drops, synthesis, etc.), changes to clear rewards (whether clear rewards are even given, game medium (rarity, type, simultaneous acquisition amount)), changes to the type of success and success rate in enhancement (training) events, changes to attack hit rate, skill activation rate, critical hit rate, type of critical hit, special effect (poison, paralysis, etc.) occurrence rate, evasion success rate, counterattack success rate, defense success rate, escape success rate, skill effect increase, special enemy occurrence rate, special event occurrence rate, etc. (increase, decrease). TT This change is not limited to cases where the above items are made advantageous to your own player, allied players, friends, or other players with whom you have a specific relationship; it may also be made disadvantageous to the enemy player. A change in the above items that disadvantages the enemy player may include, for example, a reduction in the enemy player's ability scores, a decrease in the enemy player's attack accuracy, or a change in the enemy character itself to a character with lower abilities.

[0029] <Game Media Information GBJ> Figure 5 shows the configuration of the game media information GBJ in Embodiment 1.

[0030] The storage unit 22 of the server device 2 (see Figure 2) stores game medium information GBJ, as shown in Figure 2. Game medium information GBJ includes various parameters such as identification information (ID information), name, attribute, rarity, winning probability, and attack power of the game medium GB. Game medium information GBJ includes information on multiple game mediums, such as game medium GB1, game medium GB2, game medium GB3, etc., as shown in Figure 5. As shown in Figure 5, the server device 2 can, for example, assign one (or more) game mediums to player 4(1) in a game GM played by player 4(1) through the execution of lottery C. For example, it assigns game medium GB2, which is the result of that lottery, to player 4(1).

[0031] <Lottery conditions CJ> Figure 6 shows the lottery condition CJ of Embodiment 1. The lottery condition is determined by the memory unit 22 It will be stored in memory.

[0032] The lottery condition CJ in Embodiment 1 is set based on the input information of player 4, as shown in Figure 1. Specifically, the condition setting is shown in Figure 4. instructions When the user selects an icon and enters the number of draws, time limits, etc., this information is sent from the player terminal 3 to the server device 2, and the set conditions are stored in the server device 2. The server device 2 may store the received draw conditions CJ as they are in its storage unit 22 (see Figure 2), or it may modify the received conditions based on predetermined conditions before storing them.

[0033] The lottery condition CJ is a condition (restriction) related to the lottery for each player 4. More specifically, the lottery condition CJ is a condition for lottery C, which involves selecting one of several game media GB (e.g., game media GB1, GB2, GB3, ... (see Figure 5)) that can be used within the game GM. As shown in Figure 6, the lottery condition CJ includes, for example, information on the lottery period KK, the number of attempts KS, and restrictions on the consumption of consideration such as charges KA.

[0034] The period KK can be, for example, 6 hours, 12 hours, 1 day, 2 days, 1 week, etc., as shown in Figure 6. For example, if player 4(1) sends a message to server device 2 indicating that the period KK is 6 hours, server device 2 will allow player 4(1) to make a lottery request CY with a maximum of 6 hours. In other words, player 4(1) can perform the lottery C (have server device 2 perform the lottery process) for only 6 hours from a predetermined time (from the time of the request or the time specified). After 6 hours have elapsed, it may be possible to prevent the execution of the lottery (prevent requests to server device 2 to perform the lottery process), or a message indicating that the time limit has expired may be sent when the player makes a lottery execution request. If a notification is sent, the execution of the lottery may be restricted, or the notification may be sent without restriction.

[0035] The number of rounds KS can be, for example, 1, 5, 10, 30, 50, etc., as shown in Figure 6. For example, if player 4(1) sends a message to server device 2 indicating that the number of rounds KS is 10, server device 2 will allow player 4(1) to make a lottery request CY up to a maximum of 10 times. In other words, player 4(1) can perform the lottery C only 10 times.

[0036] The charge amounts KA are, for example, 100 yen, 200 yen, 500 yen, 1000 yen, etc., as shown in Figure 6. For example, if player 4(1) sends a message to server device 2 indicating that the charge amount KA is 500 yen, server device 2 allows player 4(1) to make a lottery request CY with a maximum limit of 500 yen. In other words, player 4(1) can perform the lottery C up to 500 yen. Note that this is not limited to charges; it is also possible to set limit information on the consumption of other in-game currencies or items such as stones IS (as shown in Figure 6) and jewels, which are necessary for performing lotteries.

[0037] Player 4 can combine any or all of the above-mentioned settings for duration KK, number of times KS, and charge KA to specify a composite condition for the lottery condition CJ, as shown in Figure 6, for example, 10 times / 12 hours, 1000 yen / 2 days, 100 stones / 1 day, etc. For example, if player 4(1) sends a message to server device 2 indicating that the upper limit JG of the lottery condition CJ is 10 times / 12 hours, server device 2 will allow player 4(1) to make a lottery request CY within the range of 10 times / 12 hours, in other words, player 4(1) can execute the lottery C within the range of 10 times / 12 hours. If the conditions are not met, for example, the display of the lottery execution request icon may change and become unselectable, or after accepting the selection of the lottery execution request icon, text or an image indicating that the lottery cannot be executed may be displayed. Alternatively, text or an image indicating that the lottery cannot be executed may be displayed on the screen shown in Figure 4, etc.

[0038] <Operation of Embodiment 1> Figure 7 is a flowchart showing the operation of the game system 1 of Embodiment 1.

[0039] The operation of the game system 1 of Embodiment 1 will be explained with reference to the flowchart in Figure 7.

[0040] To facilitate explanation and understanding, we will assume that communication takes place between player terminal 3(1) of player 4(1) and server device 2.

[0041] Step ST11: Prior to playing as the Game GM (see Figure 4), player 4(1) sends a request to the server device 2 from player terminal 3(1) to set the lottery condition CJ (see Figure 1), for example, "10 times / 12 hours" (see Figure 6). For example, the player can select the icon for requesting the setting of lottery conditions (condition setting instruction icon) in Figure 4 and input conditions related to the number of times the lottery will be executed.

[0042] Step ST12: In server device 2, the lottery condition receiving unit 21A (see Figure 2) receives the setting instruction for the lottery condition CJ described above, that is, accepts the lottery condition CJ. The lottery condition receiving unit 21A stores the accepted lottery condition CJ in the storage unit 22 (see Figure 2).

[0043] Step ST13: Player 4(1) sends a lottery request CY from player terminal 3(1) to server device 2. For example, a player can send a lottery request CY to server device 2 by selecting the lottery request icon in Figure 4.

[0044] Step ST14: In the server device 2, the lottery request receiving unit 21B (see Figure 2) receives the lottery request CY described above, that is, accepts the lottery request CY. The lottery request receiving unit 21B stores the accepted lottery request CY in the storage unit 22. For example, it can be stored in association with the date and time information of when the lottery request CY was received.

[0045] Step ST15: In the server device 2, the determination unit 21C (see Figure 2) performs a determination HT to determine whether the execution of the lottery based on the lottery request CY received in step ST14 satisfies the lottery condition CJ received in step ST12. Specifically, the determination unit 21C performs a determination HT to determine whether the received lottery request CY satisfies the lottery condition CJ "10 times (or less) / 12 hours" described above. The lottery execution history is stored in the memory unit, and the number of lottery executions in a predetermined period (this month, this week, the most recent 12 hours, or the period from a specific time to the present) is referred to to determine whether executing the lottery based on the received lottery request CY satisfies the lottery condition CJ. More specifically, for example, if the number of lottery executions within a predetermined period is less than 10 to date (i.e., the current lottery request is between the 1st and 10th time), it is determined that the current lottery request satisfies the lottery condition CJ. If the number of executions is 10 or more (i.e., the current lottery request is the 11th time or later), it is determined that the current lottery request does not satisfy the lottery condition CJ. The control unit may also store the determination result or transmit it to another device.

[0046] <Effects of Embodiment 1> As described above, in the game system 1 of Embodiment 1, the server device 2 receives the lottery condition CJ and lottery request CY from the player terminal 3(1) of player 4(1), and performs a determination HT to determine whether the lottery request CY satisfies the lottery condition CJ. As a result, for example, if the lottery request CY does not satisfy the lottery condition CJ, the lottery unit 21F (see Figure 2) can either refrain from executing the lottery C (see Figures 1 and 5) or notify the player. As a result, since the player 4(1)'s play as the game GM is restricted, player 4(1) can limit their own play as the game GM, that is, it becomes possible to restrict the period KK, the number of times KS, the charges KA, etc. (see Figure 6) during which player 4(1) can request the lottery C.

[0047] <Embodiment 2> The game system 1 of Embodiment 2 will now be described.

[0048] <Configuration of Embodiment 2> The game system 1 of Embodiment 2 has the same configuration as the game system 1 of Embodiment 1 (see Figures 1 to 3).

[0049] <Operation of Embodiment 2> In the game system 1 of Embodiment 2, in addition to the operation of the game system 1 of Embodiment 1, the decision unit 21D (see Figure 2) of the server device 2 determines, for example, whether or not to perform a lottery C (see Figures 1 and 5) for player 4(1), and whether or not to notify player 4(1) of lottery C (see Figure 1).

[0050] Figure 8 is a flowchart showing the operation of the game system 1 in Embodiment 2.

[0051] The operation of the game system 1 in Embodiment 2 will be explained with reference to the flowchart in Figure 8.

[0052] To facilitate explanation and understanding, we will assume communication between player 4(1)'s player terminal 3(1) and server device 2. Furthermore, we will explain the case where the lottery request CY satisfies the lottery condition CJ and the case where it does not.

[0053] <When the lottery request CY satisfies the lottery condition CJ> Step ST16A: In step ST15 of Embodiment 1 (see Figure 7), if the determination unit 21C (see Figure 2) makes a determination HT that the lottery request CY satisfies the lottery condition CJ, the decision unit 21D decides to perform the lottery C and decides not to send any notification T to player 4(1). Note that a condition may be set to send a notification (such as a notification that the condition is met, or a notification that the lottery can be performed) even if the lottery request CY satisfies the lottery condition CJ. Furthermore, both the determination of whether the lottery can be performed and the determination of whether to send a notification may be performed, or only one of them may be performed.

[0054] Step ST17A: In the server device 2, the lottery unit 21F (see Figure 2) receives a decision from the determination unit 21C to perform lottery C and then performs lottery C.

[0055] Step ST18A: The lottery unit 21F (see Figure 2) performs the lottery C described above and selects one of the game media (for example, game media GB2 (see Figure 5)) from among the multiple game media GB (game media GB1, GB2, GB3, ...) and assigns it to player 4(1). Alternatively, the game media selected by lottery may be associated with the player and stored in memory, thereby assigning the game media to the player or allowing the player to obtain the effects, rights, etc. associated with the game media.

[0056] <If the lottery request CY does not meet the lottery condition CJ> Step ST16B: In step ST15 of Embodiment 1, if the determination unit 21C makes a determination HT that the lottery request CY does not satisfy the lottery condition CJ, then, as shown in Figure 9, the decision unit 21D decides, for example, not to perform the lottery C, and also decides to notify player 4(1) T.

[0057] Step ST17B: In the server device 2, the notification unit 21E (see Figure 2) decides not to perform the lottery C by the decision unit 21D and sends a notification T to the player terminal 3(1) stating, for example, "The lottery request CY does not satisfy the lottery condition CJ, therefore the lottery C cannot be performed."

[0058] <Effects of Embodiment 2> As described above, in the game system 1 of Embodiment 2, the decision unit 21D decides whether or not to perform the lottery C and whether or not to send a notification T, according to the result of the determination unit 21C's determination HT of whether or not the lottery request CY satisfies the lottery condition CJ. In particular, by sending a notification T to player 4(1) stating that "the lottery C cannot be performed," it becomes possible to make player 4(1) more reliably aware than in Embodiment 1 that they are restricting the game GM's play themselves.

[0059] <Embodiment 3> The game system 1 of Embodiment 3 will now be described.

[0060] <Configuration of Embodiment 3> The configuration of the game system 1 in Embodiment 3 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0061] <Operation of Embodiment 3> The game system 1 of Embodiment 3 differs from the game system 1 of Embodiment 1 in that, for example, it grants a reward to the player based on the result of comparing the lottery condition CJ (see Figure 1) set in advance by the player 4(1) with the actual lottery value of the player 4(1). TT The system determines the desired lottery request CY (see Figure 1) and awards the reward TT (see Figure 4) to player 4 based on the difference.

[0062] Figure 10 shows an example of the achievement level MT and reward TT in Embodiment 3.

[0063] As described above, the difference between the lottery request CY and the lottery condition CJ, or more precisely, the difference or ratio between the lottery request CY and the actual value of the lottery condition CJ (especially the upper limit JG (see Figure 6)), is defined as "achievement level MT". For example, if the lottery condition CJ (upper limit of executions) is 10 and the actual number of draws is 5 (the condition is met), the difference is "5", and the ratio is 0.5 (50%). Also, for example, if the lottery condition CJ is 10 and the actual number of draws is 12, the difference is "-2", and the ratio is 1.2 (120%).

[0064] The achievement level (MT) may be displayed as a numerical value (or percentage) of the number of days the condition was met (or not met) within a specified period, for example, "In this month, there were a total of 12 days on which the condition was met (Achievement Level MT1)." Alternatively, it may be expressed as a numerical value (hours, days, weeks, months, etc.) for consecutive days on which the condition was met, for example, "In this month, there were 7 consecutive days on which the condition was met (Achievement Level MT2)." In this case, the unit of the period (seconds, minutes, hours, days, weeks, months, years, etc.) and the specified period (1 hour, 12 hours, 1 day, 1 week, 1 month, 1 year, etc.) are not particularly limited.

[0065] The memory unit 22 of the server device 2 stores reward information TTJ. Reward information TTJ shows the relationship between achievement level MT and reward TT (see Figure 4). More specifically, reward information TTJ indicates that the greater the achievement level MT (i.e., the larger the difference or percentage value), the more attractive the reward TT will be for player 4. Reward information TTJ may be determined according to the total number of achievements over a predetermined period (e.g., the number of days achieved in one month), or according to the number of consecutive achievements (e.g., the number of consecutive days). Alternatively, reward information TTJ may remain constant regardless of the achievement level.

[0066] The bonus information TTJ indicates, in more detail, for example, that if player 4(1)'s achievement level MT is MT1, server device 2 will grant bonus TT1 to player terminal 3(1), and if player 4(1)'s achievement level MT is MT2, server device 2 will grant bonus TT2 to player terminal 3(1).

[0067] Figure 11 is a flowchart showing the operation of the game system 1 in Embodiment 3.

[0068] The operation of the game system 1 in Embodiment 3 will be explained with reference to the flowchart in Figure 11.

[0069] For the sake of explanation and understanding, we will assume that player 4(1) of player terminal 3(1) is performing lottery C under lottery condition CJ.

[0070] Step ST21: At a predetermined time (for example, when the upper limit JG of the lottery condition CJ (see Figure 6) is "100 times / month", then "1 month" has elapsed), the server device 2's reward determination unit 21G (see Figure 2) compares the lottery condition CJ and the lottery history (which may also be the history of lottery requests CY) stored in the storage unit 22 (see Figure 2) (steps ST12 and ST14 of Embodiment 1). Based on this comparison, the reward determination unit 21G calculates the achievement level MT of player 4(1). Here, for example, let's assume that the achievement level MT is achievement level MT2.

[0071] The reward determination unit 21G decides to grant reward TT2 based on the achievement level MT2 described above, by referring to the reward information TTJ (see Figures 2 and 10).

[0072] Step ST22: In server device 2, the reward granting unit 21H (see Figure 2) transmits the information regarding the above-mentioned reward TT2 to the player terminal 3(1) of player 4(1), i.e., grants it to player 4(1). At that time, the player information in the storage unit of server device 2 is updated based on the reward.

[0073] <Effects of Embodiment 3> As described above, in the game system 1 of Embodiment 3, the reward TT is determined according to the achievement level MT, which is the difference between the lottery condition CJ set by player 4(1) and the lottery request CY made by player 4(1), and the reward TT is awarded to player 4(1). This makes it possible to motivate player 4(1) to limit their own game play. Note that there may be multiple conditions for awarding the reward, such as a first condition with a shorter period and a second condition that is longer than the first condition. For example, the first condition may be "10 times / day," and a condition for a longer period than one day (such as one month) ("1000 times / month," etc., or the total number of times the first condition is achieved or the number of consecutive achievements) may be set as the second condition. Alternatively, the first condition may be set based on user input (instruction to set the lottery condition CJ), and the second condition may be set by the system, or all conditions (for example, the first and second conditions) may be set based on user input (instruction to set the lottery condition CJ).

[0074] <Embodiment 4> The game system 1 of Embodiment 4 will now be described.

[0075] <Configuration of Embodiment 4> The configuration of the game system 1 in Embodiment 4 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0076] <Operation of Embodiment 4> The game system 1 of Embodiment 4 differs from the game system 1 of Embodiment 1 in that, for example, if player 4(1) has a track record of drawing lots in the game GM (or a track record of drawing lottery requests CY) (number of draws KS, consideration charge KA, period KK; see Figure 12), and if the player 4(1) satisfies the predetermined conditions PJ for player 4 (hereinafter referred to as "player conditions"), the system proposes recommended conditions SJ regarding the drawing conditions CJ to player 4(1).

[0077] Figure 12 shows the player conditions PJ of Embodiment 4.

[0078] The player conditions PJ are stored in the memory unit 22 of the server device 2, as shown in Figures 2 and 12. The player conditions PJ are the number of times player 4 actually performed (or requested) the lottery C KS, the charges KA actually used by player 4 for the lottery C, and the period KK that player 4 actually played as the game GM, as shown in Figure 12.

[0079] The number of times Player 4 requested Lottery C (KS) is, for example, 100 times or more per day, or 50 times or more per day. The amount of money Player 4 spent on Lottery C (KA) is, for example, 10,000 yen or more per day, or 5,000 yen or more per day. The cumulative amount of time Player 4 played as Game GM (KK) is, for example, 10 hours or more per day, or 5 hours or more per day.

[0080] Figure 13 shows the proposed information TAJ for Embodiment 4.

[0081] The proposed information TAJ is stored in the storage unit 22 of the server device 2, as shown in Figure 2. The proposed information TAJ includes the recommended condition SJ, as shown in Figure 13. For example, if the lottery request CY by player 4(1) to the game GM (see Figure 4) satisfies the player condition PJ "60 times / day", the proposed information TAJ indicates that the recommended condition SJ "80 times or less / day" should be proposed to player 4(1) instead of the lottery condition CJ set by player 4(1). The recommended condition SJ proposed by the server device 2 may increase the number or frequency of lotteries for player 4 compared to the lottery condition CJ achieved by player 4, or it may restrict the lotteries more strictly. For example, player -4 If the set condition is "60 times or less per day" and the actual number of executions is 40, the system may suggest a condition for the next day that is "80 times or less per day," which is the difference of 20 times from 60. Furthermore, if the condition is not met, the system may suggest stricter conditions depending on the difference. For example, if the player condition project is "60 times per day" and the number of executions is 80, the system may suggest "40 times per day," which is 60 minus the difference of 20, as the recommended condition. In this way, the proposed conditions may be calculated based on the lottery conditions for a given period (e.g., "60 times or less per day"), the actual number of lottery executions during that period (e.g., 40 times), and predetermined calculation conditions (addition, multiplication, division, etc.). In other words, the proposed information is... -4 It may be decided each time. Note that the proposed information is available to all players. -4 It may be common to all players, in which case, at a predetermined time (specified time), all players -4 It may be possible to ensure that proposal information is always presented (notified).

[0082] <Operation of Embodiment 4> Figure 14 is a flowchart showing the operation of the game system 1 in Embodiment 4.

[0083] The operation of the game system 1 in Embodiment 4 will be explained with reference to the flowchart in Figure 13.

[0084] To facilitate explanation and understanding, we will assume that player 4(1)'s player terminal 3(1) and server device 2 communicate with each other.

[0085] Step ST31: In the server device 2, the determination unit 21C (see Figure 2) determines, for example, in the same manner as in step ST13 of Embodiment 1, whether the status of the player 4(1)'s game GM play record (or lottery request CY) during that day satisfies the player condition PJ (for example, 100 times or more / day, 10,000 yen or more / day, 10 hours or more / day), i.e., whether it is applicable or not, after a full day has elapsed since player 4(1) sent the lottery condition CJ to the server device 2 to set the conditions.

[0086] Step ST32: If the determination unit 21C determines that the situation of the lottery request CY by player 4(1) falls under any of the player conditions PJ, the proposal unit 21J (see Figure 2) proposes recommended conditions SJ corresponding to the player condition PJ to player 4(1). One or more conditions may be proposed.

[0087] If the situation of the lottery request CY by player 4(1) falls under, for example, player condition PJ "10,000 yen or more / day", the proposal unit 21J proposes the recommended condition SJ "12,000 yen or less / day" to player 4(1)'s player terminal 3(1) based on predetermined proposal conditions.

[0088] <Effects of Embodiment 4> As described above, in the game system 1 of Embodiment 4, if the determination unit 21C determines, for example, that the situation of the lottery request CY by player 4(1) corresponds to player condition PJ, the proposal unit 21J proposes recommended condition SJ to player 4(1) in place of the lottery condition CJ set by player 4(1). This makes it possible to make suggestions according to the degree to which player 4(1) has achieved the conditions.

[0089] <Embodiment 5> The game system 1 of Embodiment 5 will now be described.

[0090] <Configuration of Embodiment 5> The configuration of the game system 1 in Embodiment 5 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0091] <Operation of Embodiment 5> In the game system 1 of Embodiment 5, for example, player 4(1) is notified of a message ME (see Figure 14) which is determined according to the relationship between the lottery condition CJ (see Figure 1) set by player 4(1) and the number of lottery requests CY (see Figure 1) made by player 4(1) or the amount of consideration paid by player 4(1) for the lottery requests CY.

[0092] Figure 15 shows the contents of message ME in Embodiment 5.

[0093] The message ME of Embodiment 5, as shown in Figure 15, contains, for example, the following: 1. If the lottery conditions CJ are "10 times / day" (1) When the cumulative number of draws (or draw requests CY) per day is "9 times (9th time)" Message ME contains information about the remaining number of attempts until the condition is met, such as "You can make one more lottery request CY." (2) When the cumulative number of draws (or draw requests CY) per day is "10 times" Message ME will contain content such as "This is the last draw C for today," or "You have reached the maximum number of draws for today," indicating that the draw conditions have been met. 2. If the lottery condition CJ is "1,000 yen / day" (1) When the amount of payment spent per day in connection with the lottery (cumulative charge amount for requested CY) is "900 yen" Message ME contains information about the remaining amount needed to reach the conditions, such as "You can request a lottery with the remaining 100 yen." (2) When the cumulative amount of CY requested for the lottery per day is "1,000 yen" Message ME indicates that the lottery conditions have been met, such as "This is the last lottery draw C for today." The timing of such notifications is predetermined and may be when the server receives the player's lottery request.

[0094] Figure 16 is a flowchart showing the operation of the game system 1 in Embodiment 5.

[0095] The operation of the game system 1 in Embodiment 5 will be explained with reference to the flowchart in Figure 16.

[0096] To facilitate explanation and understanding, we will assume that player 4(1)'s player terminal 3(1) and server device 2 communicate with each other.

[0097] Step ST41: In the same manner as steps ST11 and ST12 of Embodiment 1, after the server device 2 receives the lottery condition CJ from the player terminal 3(1) of player 4(1), the determination unit 21C (see Figure 2) in the server device 2 determines whether the lottery request CY received from player 4(1) exceeds the lottery condition CJ, and how much difference there is between the lottery request CY and the lottery condition CJ.

[0098] Step ST42: In the server device 2, the notification unit 21E (see Figure 2) sends a notification T of message ME corresponding to the result of the determination unit 21C to the player terminal 3(1).

[0099] For example, if the determination unit 21C determines that player 4(1)'s lottery condition CJ is "10 times / day" and player 4(1)'s lottery request CY is a request for the "9th" lottery, then player 4(1) can make one more lottery request CY. The notification unit 21E then sends a notification T to player terminal 3(1) with message ME "You can make one more lottery request CY".

[0100] Furthermore, for example, if the determination unit 21C determines that the last lottery C is when the lottery condition CJ for player 4(1) is "1,000 yen / day" and the cumulative amount charged when the lottery is executed based on the lottery request CY from player 4(1) is "1,000 yen / day". The notification unit 21E sends a notification T to the player terminal 3(1) with the message ME "This is the last lottery C for today".

[0101] <Effects of Embodiment 5> As described above, in the game system 1 of Embodiment 5, a notification T is sent to player 4(1) containing a message ME which is determined according to the relationship between the lottery request CY and the number of times player 4(1) has performed a lottery or the amount of money paid for the lottery. This makes it possible to further encourage player 4(1) to restrict the game GM's play themselves compared to the game system 1 of Embodiment 1.

[0102] <Embodiment 6> The game system 1 of Embodiment 6 will now be described.

[0103] <Configuration of Embodiment 6> The configuration of the game system 1 in Embodiment 6 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0104] <Operation of Embodiment 6> In the game system 1 of Embodiment 6, for example, when it is determined that the lottery request CY (see Figure 1) sent from player 4(1) does not satisfy the lottery condition CJ (see Figure 1) set by player 4(1) (for example, when it exceeds the upper limit), the restart condition SJ (see Figure 1) is a condition under which player 4(1) can restart the lottery request CY. 17 See reference.) Notify player 4(1).

[0105] Figure 17 shows the restart information SKJ of Embodiment 6.

[0106] Resumption information SKJ is shown in Figure 2, Figure 17As shown in the figure, the restart information SKJ is pre-stored in the storage unit 22 of the server device 2. 17 As shown, there are multiple restart conditions SJ1, SJ2, SJ3, etc. Restart information SKJ indicates, for example, restart condition SJ1 "after the date changes", restart condition SJ2 "after 6 hours have passed", restart condition SJ3 "after the lottery condition CJ is changed". In other words, restart information SKJ indicates when the cumulative values ​​related to the lottery (cumulative number of times, cumulative amount, cumulative time, etc.) are reset.

[0107] Figure 18 is a flowchart showing the operation of the game system 1 in Embodiment 6.

[0108] The operation of the game system 1 in Embodiment 6 is shown in Figure 18 Refer to the flowchart for explanation.

[0109] To facilitate explanation and understanding, we will assume that player 4(1)'s player terminal 3(1) and server device 2 communicate with each other.

[0110] Steps prior to ST51: In the server device 2, the lottery condition receiving unit 21A receives instructions from the player terminal 3(1) to set the lottery condition CJ from player 4(1) in the same manner as in steps ST11 and ST12 of Embodiment 1.

[0111] Step ST51: In the server device 2, when the lottery request receiving unit 21B (see Figure 2) receives a lottery request CY (see Figure 1) from player terminal 3(1) for player 4(1), similar to step ST13 of Embodiment 1, the determination unit 21C (see Figure 2) determines whether the lottery request CY satisfies the lottery conditions CJ described above. If it is determined that the lottery request CY does not satisfy the lottery conditions CJ, the lottery unit 21F (see Figure 2) does not respond to the lottery request CY, in other words, stops the lottery C for player 4(1) thereafter. Note that if the lottery conditions CJ are not met, the lottery request icon may be changed (hidden, or its color or text changed) so that the lottery request CY cannot be entered.

[0112] Step ST52: In the server device 2, the notification unit 21E (see Figure 2) responds to the determination unit 21C determining that the lottery request CY does not satisfy the lottery condition CJ by sending a notification T of the restart condition SJ to the player terminal 3(1) of player 4(1).

[0113] For example, if the draw condition CJ (period KK; see Figure 6) at the time player 4(1) started the game GM was "10 times / 12 hours", and player 4(1) has already performed 10 draws in "6 hours" while playing as the game GM, then the restart condition SJ2 "after 6 hours have elapsed" notification T is issued.

[0114] Furthermore, for example, if the lottery cannot be conducted without changing the lottery conditions CJ, the notification T for restart condition SJ3 "After changing lottery conditions CJ" will be issued.

[0115] <Effects of Embodiment 6> As described above, in the game system 1 of embodiment 6, when player 4(1)'s lottery request CY does not satisfy player 4(1)'s lottery condition CJ, the lottery C for player 4(1) is stopped, and player 4(1) is notified T of the restart condition SJ. This allows player 4(1) to restrict the game GM's play themselves and to understand the conditions for restarting.

[0116] <Embodiment 7> The game system 1 of Embodiment 7 will now be described.

[0117] <Configuration of Embodiment 7> The configuration of the game system 1 in Embodiment 7 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0118] <Operation of Embodiment 7> The game system 1 of Embodiment 7 switches, for example, whether or not to execute a determination HT (see Figure 7) in response to a lottery request CY from player 4(1), in response to a request from player 4(1).

[0119] Figure 19 is a flowchart showing the operation of the game system 1 in Embodiment 7.

[0120] The operation of the game system 1 in Embodiment 7 will be explained with reference to the flowchart in Figure 19.

[0121] To facilitate explanation and understanding, we will assume that communication takes place between player terminal 3(1) of player 4(1) and server device 2.

[0122] Steps prior to ST61: In the same manner as in steps ST11 and ST12 of Embodiment 1, the lottery condition CJ (see Figure 1) of player 4(1) has been transmitted from player terminal 3(1) of player 4(1) to server device 2, meaning that server device 2 has already received the lottery condition CJ of player 4(1). Note that server device 2 does not necessarily have to have received the lottery condition CJ.

[0123] Step ST61: Player 4(1) sends a request from player terminal 3(1) to server device 2 to switch whether or not lottery restrictions and lottery notifications are necessary. For example, player 4(1) sends a request to switch whether or not a determination HT is necessary to determine whether or not the lottery request CY that will be made by player 4(1) in the future satisfies the lottery conditions CJ that player 4(1) has already set, i.e., whether or not the determination HT should be executed. For example, by selecting the restriction switching icon and the notification switching icon in Figure 4, the necessity of executing the lottery restriction function and the lottery notification function, respectively (on or off), can be switched. Note that the necessity of executing both the lottery restriction function and the lottery notification function (on or off) can be switched together, or only one of them can be switched.

[0124] Step ST62: In server device 2, the switching unit 21K (see Figure 2) switches whether to perform the determination HT for determining whether a lottery is necessary or to notify, or to stop the determination HT, in response to the above-mentioned request. That is, it switches whether to have the determination unit 21C (see Figure 2) perform the determination HT or not to have the determination unit 21C perform the determination HT. The determination requirement is updated in the storage unit each time the switch is made.

[0125] Step ST63a: In step ST62 described above, if the request from player 4(1) indicates that a determination HT is unnecessary, that is, that the determination HT should be stopped, the determination unit 21C (see Figure 2) in the server device 2 will no longer perform the determination HT to determine whether the lottery request CY from player 4(1) satisfies the lottery request CY that player 4(1) has set in advance. In other words, player 4(1) will no longer be restricted in the execution of the lottery C by the lottery unit 21F (see Figure 2), or it will be executed without notification. This allows the lottery restriction and notification functions to be turned off, so players can use the restriction and notification functions only when necessary, improving convenience. Also, since there is no need to perform judgment or other processing each time a lottery is held, the processing load on the server can be reduced.

[0126] Step ST63b: In contrast to step ST63a described above, if in step ST62 the request from player 4(1) indicates that a determination HT is required, that is, that a determination HT should be performed, then the determination unit 21C in the server device 2 will subsequently perform a determination HT to determine whether the lottery request CY from player 4(1) satisfies the lottery request CY that player 4(1) has set in advance. In other words, player 4(1) will be able to perform the lottery C by the lottery unit 21F within the range of the lottery conditions CJ.

[0127] <Effects of Embodiment 7> As described above, in the game system 1 of Embodiment 7, the server device 2 switches whether to perform a judgment HT in response to a request from player 4(1) regarding the necessity of the judgment HT, that is, in response to a request from player 4(1) regarding whether to perform the judgment HT or stop it. This allows player 4(1) to decide for themselves whether or not to restrict the game GM's play, improving convenience. The control unit may also prevent the lottery from being performed if the player turns off at least one or both of the restriction and notification functions.

[0128] <Embodiment 8> The game system 1 of embodiment 8 will now be described.

[0129] <Configuration of Embodiment 8> The configuration of the game system 1 in Embodiment 8 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0130] <Operation of Embodiment 8> In the game system 1 of Embodiment 8, for example, the billing history KR (Figure 6, Figure 12) is the history of billing KA (see Figure 6, Figure 12) at the game GM (see Figure 4) of player 4(1). 20 See reference.) and, upon request from player 4(1), notify player 4(1) of player 4(1) of their billing history KR.

[0131] Figure 20 shows the billing history KR for Embodiment 8.

[0132] The billing history KR is stored in the memory unit 22 of the server device 2, as shown in Figures 2 and 20. The billing history KR shows the billing KA for lottery C, the purchase of game medium GB, and the total amount, as shown in Figure 20. More specifically, the billing history KR shows, for example, that on the 1st (Thursday), player 4(1) spent 1,000 yen on billing KA for lottery C, and 500 yen on the purchase of game medium GB, for a total of 1,500 yen (= 1,000 yen + 500 yen). Such billing history is stored in the memory unit (the memory unit is updated) each time a billing occurs. The billing history KR may also provide more detailed information about the items and amounts of billing. For example, if there are multiple types of paid in-game currency (such as paid gems) or game mediums (such as characters and items), the billing amount may be shown for each type of in-game currency and game medium. Furthermore, the information is not limited to being presented daily; it can also be presented by time of day, week, or month.

[0133] Figure 21 is a flowchart showing the operation of the game system 1 in embodiment 8.

[0134] The operation of the game system 1 in Embodiment 8 will be explained with reference to the flowchart in Figure 21.

[0135] To facilitate explanation and understanding, we will assume that communication takes place between player terminal 3(1) of player 4(1) and server device 2.

[0136] Step ST71: After going through steps ST11 and ST12 of Embodiment 1, and after performing the lottery request CY in step ST13 at least once, player terminal 3(1) requests server device 2 to notify player 4(1) of the billing history KR. For example, an icon to request the billing history can be displayed on the screen shown in Figure 4, and the player can request the server to display the billing history by selecting this icon.

[0137] Step ST72: In the server device 2, the notification unit 21E (see Figure 2) responds to a request from player 4(1) and, as shown in Figure 20, sends a notification T to player 4(1) stating the player's billing history KR, for example, "On Friday the 2nd, 1,500 yen was spent on billing KA for lottery C, and 2,000 yen was spent on purchasing game media GB, for a total of 3,500 yen (2,000 yen + 1,500 yen)." In this way, the items (types) for which the consideration was spent and the amount of consideration spent (amount for each item, total amount) can be presented.

[0138] <Effects of Embodiment 8> As described above, in the game system 1 of Embodiment 8, for example, the billing history KR of player 4(1) within the game GM is stored, and based on a request from player 4(1), the billing history KR of player 4(1) is notified T of player 4(1). This makes it possible for player 4(1) to more reliably restrict their own play in the game GM by referring to their own billing history KR compared to Embodiment 1.

[0139] <Embodiment 9> The game system 1 of embodiment 9 will now be described.

[0140] <Configuration of Embodiment 9> The configuration of the game system 1 in Embodiment 9 is the same as the configuration of the game system 1 in Embodiment 1 (see Figures 1 to 3).

[0141] <Operation of Embodiment 9> In the game system 1 of Embodiment 9, for example, difference information JYSJ (Figure) shows the difference between the lottery condition CJ set by player 4(1) and the history of the actual lottery results (or lottery request CY) performed by player 4(1). 22 See reference.) Calculate the difference information JYSJ of player 4(1) and, in response to a request from player 4(1), notify player 4(1) of the difference information JYSJ.

[0142] Figure 22 shows the difference information JYSJ for Embodiment 9.

[0143] The differential information JYSJ is stored in the storage unit 22 of the server device 2, as shown in Figures 2 and 22. The differential information JYSJ, as shown in Figure 22, includes, for example, the lottery condition CJ set in advance by player 4(1), the number of lottery requests CY made by player 4(1) KS, the difference JYS which is the difference between the lottery condition CJ and the lottery request CY, and the differential (cumulative) JYS(R) which is the cumulative difference JYS.

[0144] The differential information JYSJ, in more detail, indicates, for example, that if player 4(1) has a draw condition CJ of 10 times / day, and on day 1 (Thursday) player 4(1) made 7 draw requests CY, the differential JYS is -3 times (= 7 times - 10 times), and the differential (cumulative) JYS(R) is -3 times.

[0145] The difference information JYSJ also shows, for example, that, similar to the above, player 4(1) has a draw condition CJ of 10 times / day, and on Friday the 2nd, player 4(1) made 11 draw requests CY, so the difference JYS is +1 (=11 - 10), and the difference (cumulative) JYS(R) is -2 (=-3 + 1).

[0146] Figure 23 is a flowchart showing the operation of the game system 1 in Embodiment 9.

[0147] The operation of the game system 1 in Embodiment 9 will be explained with reference to the flowchart in Figure 23.

[0148] To facilitate explanation and understanding, we will assume that communication takes place between player terminal 3(1) of player 4(1) and server device 2.

[0149] Step ST81: In steps ST11 and ST12 of Embodiment 1, after player 4(1) has set the lottery condition CJ and sent a lottery request CY from player 4(1) to server device 2 at least once in ST13, player 4(1) requests server device 2 to notify player 4(1) of differential information JYSJ T.

[0150] Step ST82: In the server device 2, the calculation unit 21L (see Figure 2) calculates the differential information JYSJ. More specifically, as shown in Figure 22, the calculation unit 21L calculates that for player 4(1), given that the lottery condition CJ is 10 times / day, on the 3rd day (Saturday), the number of lottery requests CY is 8, the differential JYS is -2, and the differential (cumulative) JYS(R) is -4.

[0151] Step ST83: In the server device 2, the notification unit 21E (see Figure 2) notifies the player 4(1) of the difference information JYSJ calculated by the calculation unit 21L.

[0152] <Effects of Embodiment 9> As described above, in the game system 1 of Embodiment 9, the calculation unit 21L calculates difference information JYSJ, which is the difference between the lottery conditions CJ of player 4(1) and the history of lottery requests CY actually made by player 4(1), and condition / requirement difference (cumulative) JYS(R). The notification unit 21E notifies player 4(1) of the difference information JYSJ in response to a request from player 4(1). By referring to the difference information JYSJ, and in particular by referring to the difference (cumulative) JYS(R), player 4(1) can check whether or not they have made too many lottery requests CY, thereby more effectively restricting the game GM's play than in Embodiment 1.

[0153] <Hardware configuration of the embodiment> The server device 2 and player terminal 3 of Embodiments 1 to 9 include a processing circuit SYO to perform the functions described above, and optionally further include an input circuit NYU and an output circuit SYU. The processing circuit SYO is dedicated hardware. The processing circuit SYO mainly implements the functions of the control unit 21 of the server device 2 (see Figure 2) and the control unit 31 of the player terminal 3 (see Figure 3). The processing circuit SYO may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination thereof. The input circuit NYU and output circuit SYU exchange inputs and outputs related to the operation of the processing circuit SYO with, for example, the outside of the server device 2 and player terminal 3.

[0154] <Hardware configuration based on software implementation of the embodiment> The server device 2 and player terminal 3 of Embodiments 1 to 9 include a processor PRO and a memory circuit KIO, and optionally further include an input circuit NYU and an output circuit SYU. The processor PRO is a CPU (Central Processing Unit, also called a central processing unit, processing unit, arithmetic unit, microprocessor, microcomputer, or DSP (Digital Signal Processing)) that executes programs. The processor PRO mainly implements the functions of the control unit 21 of the server device 2 (see Figure 2) and the control unit 31 of the player terminal 3 (see Figure 3). The processor PRO implements the above functions by software, firmware, or a combination of software and firmware. The software and firmware are written as a program PRG and stored in the memory circuit KIO. The processor PRO implements the above functions by reading the program PRG from the memory circuit KIO and executing it. The above program PRG can also be said to mainly cause the computer to execute the procedures and methods of the control unit 21 of the server device 2 and the control unit 31 of the player terminal 3. Here, memory circuits (KIO) include, for example, non-volatile or volatile semiconductor memories such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, EPROM (Erasable Programmable Read Only Memory), and EEPROM (Electrically Erasable Programmable Read-Only Memory), as well as magnetic disks, flexible disks, optical disks, compact disks, minidiscs, DVDs (Digital Versatile Discs), etc.

[0155] Some of the functions of the control unit 21 of the server device 2 and the control unit 31 of the player terminal 3 may be implemented by the processing circuit SYO, while other functions may be implemented by the processor PRO.

[0156] As described above, the functions of the control unit 21 of the server device 2 and the control unit 31 of the player terminal 3 can be realized primarily through hardware, software, firmware, or a combination thereof. The input circuit NYU and output circuit SYU exchange inputs and outputs related to the operation of the processor PRO with, for example, the outside of the server device 2 and the player terminal 3.

[0157] The present invention is not limited to the embodiments described above, and various modifications are possible without departing from the spirit of the invention.

[0158] In the above example, the number of draws may be set as a condition for the number of draws, with a number pre-associated with the draw event. For example, in the case of a draw event where a specific rarity of game material or a specific game material is awarded when the same type of gacha is performed a predetermined number of times (e.g., 10, 50, 100 times, etc.) within a predetermined period, such as a so-called "ceiling gacha," the ceiling number may be set as the upper limit of the draw event. In this way, by setting a predetermined number as the draw condition for each draw event, it becomes possible to allow draws until the objective of the draw event is achieved, or to notify the player when the ceiling number is reached. As a result, the enjoyment of the game can be enhanced. In this case, a specific number (number condition information such as the ceiling number) is pre-associated with each type of draw and stored in the memory unit. Not limited to the ceiling number, conditions for the content of any rewards, such as granting a predetermined reward to the player after a predetermined number of draws, can be associated with the number and the draw event. The control unit of the server device may display the pre-associated number information on the draw event introduction screen or condition setting screen. In this way, by displaying the count information associated with the lottery event to the player's terminal, the player can refer to the count information associated with the lottery event when setting the lottery conditions.

[0159] Furthermore, the control unit of the server device may execute a notification suggesting the use of the restriction function to players who meet predetermined suggestion conditions. The suggestion conditions are stored in the memory unit in advance. Suggestion conditions include, for example, the number of lottery draws performed in a predetermined period exceeding a specific value (threshold), or the cumulative value of consumption during a predetermined period exceeding a specific value (threshold). The specific value (threshold) may be an upper limit value entered or selected by the player, or a value calculated based on the upper limit value. A value calculated based on the upper limit value is, for example, a value calculated based on a calculation formula stored in advance. Specifically, if the upper limit value is 10 times, it can be a value obtained by multiplying by a predetermined number (0.9, 0.8, 0.6, etc.) (9 times, 8 times, 6 times, etc.), but is not limited to this. The control unit can determine from each player's play history whether these conditions are met and send a notification if they are met. This allows, for example, the restriction function to be suggested to players who exceed 100 lottery draws in a day or who spend more than 100,000 yen. Furthermore, this proposal is preferably applied to players who have either or both of the restriction and / or notification functions turned off. This would allow for prompting players who excessively participate in the lottery to limit their participation or send notifications.

[0160] <Example of structure> The game system 1 etc. related to this disclosure has, for example, the following configuration:

[0161] [Item 1] A lottery request reception unit that receives lottery requests from players requesting to be entered into a lottery to select one of several game media available for use within the game, The instruction to set the lottery conditions, which are the conditions for the aforementioned lottery, The aforementioned The lottery entry acceptance section accepts entries from players, When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system that includes this. [Item 2] The information processing system according to claim 1, further comprising a determination unit that determines whether or not to issue a notification regarding the lottery or whether or not to carry out the lottery, based on the result of the determination. [Item 3] The lottery conditions at a predetermined time, The aforementioned The information processing system according to claim 1, further comprising a reward granting unit that determines the reward to be granted to the player based on the result of comparing the player's performance in the aforementioned lottery. [Item 4] The information processing system according to claim 1, wherein the lottery conditions include an upper limit on the number of times the lottery is performed during a predetermined period. [Item 5] The information processing system according to claim 1, wherein the lottery conditions include an upper limit on the cumulative amount of consideration consumed when performing the lottery during a predetermined period. [Item 6] The aforementioned Lottery conditions The information processing system according to claim 1, wherein the reception unit receives a designation of a period from the player as an instruction to set the lottery conditions. [Item 7] The proposal must meet the predetermined conditions. The aforementioned The information processing system according to claim 1, further comprising a suggestion unit that suggests recommended conditions regarding the aforementioned lottery conditions to the player. [Item 8] If the cumulative number of draws or the amount of consideration within a predetermined period reaches a specific value based on the draw conditions, The aforementioned Player - The information processing system according to claim 1, further comprising a notification unit that provides a predetermined notification. [Item 9] The information processing system according to claim 1, further comprising a notification unit that notifies the player of the conditions under which the player can resume the lottery if the determination unit determines that the lottery request does not satisfy the lottery conditions. [Item 10] The information processing system according to claim 1, further comprising a switching unit that switches whether or not to perform the determination based on a request from the player. [Item 11] A storage unit that stores the player's in-game billing history, The information processing system according to claim 1, further comprising a notification unit that outputs information regarding the player's billing history based on the player's request. [Item 12] A calculation unit calculates difference information showing the difference between the aforementioned lottery conditions and the history of the lottery actually performed by the player, The system further includes a notification unit that outputs the differential information based on the player's request. The information processing system according to claim 1. [Item 13] A lottery request reception unit that receives lottery requests from players requesting to be entered into a lottery to select one of several game media available for use within the game, The instruction to set the lottery conditions, which are the conditions for the aforementioned lottery, The aforementioned The lottery entry acceptance section accepts entries from players, When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions. 、 of Includes servers. [Item 14] A lottery request acceptance step in which a player submits a lottery request requesting to be entered into a draw to select one of several game media available for use within the game, The instruction to set the lottery conditions, which are the conditions for the aforementioned lottery, The aforementioned The lottery entry process accepted from players, When the lottery request is received, a determination step is taken to determine whether the lottery request satisfies the lottery conditions, Information processing methods including [Item 15] On the computer, A lottery request acceptance step in which a player submits a lottery request requesting to be entered into a draw to select one of several game media available for use within the game, The instruction to set the lottery conditions, which are the conditions for the aforementioned lottery, The aforementionedThe lottery entry process accepted from players, When the lottery request is received, a determination step is taken to determine whether the lottery request satisfies the lottery conditions, A program to execute.

Claims

1. A lottery request reception unit that receives lottery requests from players requesting to be entered into a lottery to select one of several game media available for use within the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. An information processing system further comprising a reward granting unit that determines the reward to be granted to the player based on the result of comparing the lottery conditions and the player's actual lottery results at a predetermined point in time.

2. The information processing system according to claim 1, further comprising a determination unit that determines whether or not to issue a notification regarding the lottery or whether or not to carry out the lottery, based on the result of the determination.

3. A lottery request receiving unit that receives a lottery request from a player requesting to select one of several game media that can be used in the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. The lottery conditions include an upper limit on the number of times the lottery can be performed during a predetermined period, and is part of an information processing system.

4. The information processing system according to claim 1, wherein the lottery conditions include an upper limit on the cumulative amount of consideration consumed when performing the lottery during a predetermined period.

5. A lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one of several game media that can be used in the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. The lottery condition reception unit is an information processing system that receives a period specification from the player as an instruction to set the lottery conditions.

6. A lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one of several game media that can be used in the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. An information processing system further comprising a proposal unit that proposes recommended conditions regarding the lottery conditions to the aforementioned player who meets predetermined proposal conditions.

7. The information processing system according to claim 1, further comprising a notification unit that provides a predetermined notification to the player when the cumulative number of times the lottery is performed or the cumulative value of the consideration within a predetermined period reaches a specific value based on the lottery conditions.

8. The information processing system according to claim 1, further comprising a notification unit that notifies the player of the conditions under which the player can resume the lottery if the determination unit determines that the lottery request does not satisfy the lottery conditions.

9. A lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one of several game media that can be used in the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, An information processing system including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. An information processing system further comprising a switching unit that switches whether or not to perform the determination based on a request from the player.

10. A storage unit that stores the player's in-game billing history, The information processing system according to claim 1, further comprising a notification unit that outputs information regarding the player's billing history based on the player's request.

11. A calculation unit calculates difference information showing the difference between the aforementioned lottery conditions and the history of the lottery actually performed by the player, The system further includes a notification unit that outputs the differential information based on the player's request. The information processing system according to claim 1.

12. A lottery request reception unit that receives lottery requests from players requesting to be entered into a lottery to select one of several game media available for use within the game, A lottery condition receiving unit that receives instructions from the player regarding the setting of lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination unit determines whether the lottery request satisfies the lottery conditions, A server including, After the lottery condition receiving unit receives the instruction to set the lottery conditions, the lottery request receiving unit receives the lottery request. A server further comprising a reward granting unit that determines the reward to be granted to the player based on the result of comparing the lottery conditions and the player's actual lottery results at a predetermined time.

13. A lottery request acceptance step in which a player submits a lottery request requesting to be entered into a draw to select one of several game media available for use within the game, A lottery condition acceptance step in which the player provides instructions for setting lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination step is taken to determine whether the lottery request satisfies the lottery conditions, An information processing method including, After receiving the instruction to set the lottery conditions in the lottery condition acceptance step, the lottery request acceptance step receives the lottery request, An information processing method further comprising a reward granting step, in which a reward to be granted to a player is determined based on a comparison result between the lottery conditions and the player's actual lottery results at a predetermined point in time.

14. On the computer, A lottery request acceptance step in which a player submits a lottery request requesting to be entered into a draw to select one of several game media available for use within the game, A lottery condition acceptance step in which the player provides instructions for setting lottery conditions, which are the conditions for the lottery; When the lottery request is received, a determination step is taken to determine whether the lottery request satisfies the lottery conditions, A program to execute, After receiving the instruction to set the lottery conditions in the lottery condition acceptance step, the lottery request acceptance step receives the lottery request, A program further comprising a reward granting step, which determines the reward to be granted to the player based on the result of comparing the lottery conditions at a predetermined time with the player's actual lottery results.

Images