JP7844543B2 - Information processing systems, information processing methods, servers, and programs - Google Patents

Description

This disclosure relates to information processing systems, information processing methods, servers, and programs.

Patent Document 1 discloses a technology for enhancing the flexibility of parental controls in games, which allow parents (guardians) to manage and restrict the behavior of their children (protected individuals). The server system described in Patent Document 1 restricts a child's game play if their use of an electronic payment medium during gameplay violates pre-set restrictions set by the parent.

Japanese Patent Publication No. 2016-013151

However, the server systems mentioned above cannot set or relax game restrictions on the child game device alone. Therefore, for example, the user could not prevent themselves from impulsively repeating gacha pulls.

The purpose of this disclosure is to provide an information processing system, information processing method, server, and program that allows game players to restrict their own gameplay.

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 that can be used in the game; a lottery condition receiving unit that receives instructions from the player to set lottery conditions, which are conditions related to the lottery; and a determination unit that, upon receiving the lottery request, determines whether the lottery request satisfies the lottery conditions.

According to the information processing system described in this disclosure, players will be able to restrict their own gameplay.

The configuration of the game system 1 of Embodiment 1 is shown. The configuration of the server device 2 in Embodiment 1 is shown. The configuration of the player terminal 3 in Embodiment 1 is shown. An example of the Game GM screen for Embodiment 1 is shown. The configuration of the game media information GBJ in Embodiment 1 is shown. The lottery condition CJ of Embodiment 1 is shown. This is a flowchart showing the operation of the game system 1 of Embodiment 1. This is an example of a flowchart showing the operation of the game system 1 of Embodiment 2. This is another example of a flowchart illustrating the operation of the game system 1 of Embodiment 2. The achievement level MT and the reward TT for Embodiment 3 are shown. This is a flowchart showing the operation of the game system 1 of Embodiment 3. The player conditions PJ of Embodiment 4 are shown. The proposed information TAJ for Embodiment 4 is shown. This is a flowchart showing the operation of the game system 1 of embodiment 4. The content of message ME in Embodiment 5 is shown below. This is a flowchart showing the operation of the game system 1 of Embodiment 5. The restart information SKJ of Embodiment 6 is shown. This is a flowchart showing the operation of the game system 1 of embodiment 6. This is a flowchart showing the operation of the game system 1 of Embodiment 7. The billing history KR for Embodiment 8 is shown. This is a flowchart showing the operation of the game system 1 of embodiment 8. The differential information JYSJ of Embodiment 9 is shown. This is a flowchart showing the operation of the game system 1 of embodiment 9.

The embodiments of the game system related to this disclosure will be described below.

<Embodiment 1>
The game system 1 of Embodiment 1 will now be described.

<Configuration of Embodiment 1>
<Game System 1 Configuration>
Figure 1 shows the configuration of the game system 1 of Embodiment 1.

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

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), ..., and player terminal 3(m) is used by player 4(m).

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.

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

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

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

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.

As shown in Figure 2, the control unit 21 comprises 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.

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

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.

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

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.

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

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

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, a game medium (GB) and bonus items (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.

Game media GB refers to, for example, characters, items, and cards representing them used within the game. Player 4, who plays Game GM, can acquire Game Media GB through, for example, a lottery C (a so-called gacha). Game Media GB can be acquired through various methods, such as payment, completing quests, synthesizing Game Media, and using specific items. It may also be automatically granted by the system at predetermined timings, such as when the player first runs the game or when they reach a predetermined stage through gameplay. The lottery is not limited to gacha; it may also include drops resulting 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 the lottery selected based on the player's input information.

The bonus TT is something that benefits Player 4 within the Game GM. The bonus TT is not particularly limited as long as it 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, changes (increases, decreases) of various parameters (level, experience points, stamina, ability values of game media, amount that can be borrowed), raising the upper limit of parameter values, lowering the lower limit, stamina recovery, etc. Furthermore, the bonus TT may also include changes (increases or decreases) to the following: the type of game medium, the probability of winning, the rarity, the amount obtained (number) in processes involving various draws (gacha, drops, synthesis, etc.); changes to clear rewards (whether or not clear rewards are given at all, the game medium (rarity, type, amount obtained simultaneously)); changes to the type of success and success rate in enhancement (training) events; 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. Moreover, the bonus TT is not limited to changes that benefit the player's own players, allied players, friends, or other players with specific relationships; it may also include changes that disadvantage enemy players. For the above items to be changed in a way that puts the opposing player at a disadvantage, this could include, for example, reducing the opposing player's ability scores, decreasing the accuracy of the opposing player's attacks, or changing the opposing character itself into a character with lower abilities.

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

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 of the game medium GB, such as identification information (ID information), name, attributes, rarity, winning probability, and attack power. 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) during a game GM played by player 4(1), selected by the execution of a lottery C. For example, it might assign game medium GB2, which is the result of that lottery, to player 4(1).

<Lottery conditions CJ>
Figure 6 shows the lottery condition CJ of Embodiment 1. The lottery condition is stored in the storage unit 22 .

The lottery conditions CJ in Embodiment 1 are set based on the input information of the player 4, as shown in Figure 1. Specifically, when the user selects the condition setting instruction icon shown in Figure 4 and inputs the number of draws, the limit on the draw time, 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 lottery conditions CJ as they are in the storage unit 22 of the server device 2 (see Figure 2), or it may modify the received conditions based on predetermined conditions and store them.

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)) usable within the game GM. As shown in Figure 6, the lottery condition CJ includes, for example, information on restrictions on the lottery period KK, the number of attempts KS, and the consumption of consideration such as charges KA.

The duration 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 duration KK is 6 hours, server device 2 allows player 4(1) to make a lottery request CY with a maximum duration of 6 hours. In other words, player 4(1) can execute the lottery C (cause server device 2 to execute the lottery process) for only 6 hours from a predetermined point in time (from the time of the request or specified time). After 6 hours have elapsed, the lottery may no longer be executed (players may no longer be able to request server device 2 to execute 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.

The number of attempts 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 attempts KS is 10, server device 2 allows 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.

The charge amount KA is, as shown in Figure 6, for example, 100 yen, 200 yen, 500 yen, 1000 yen, etc. 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; limit information on the consumption of other in-game currencies or items, such as stones IS (as shown in Figure 6) or jewels, required for lottery execution may also be set.

Player 4 can combine any or all of the above-mentioned settings for period KK, number of times KS, and charge KA to specify, as shown in Figure 6, a composite condition for the lottery condition CJ, such as 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.

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

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

To facilitate explanation and understanding, we assume communication between player 4(1)'s player terminal 3(1) and server device 2.

Step ST11: Prior to playing the game with the Game GM (see Figure 4), player 4(1) sends a request to the server device 2 from the 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 the lottery condition (condition setting instruction icon) in Figure 4 and input conditions related to the number of lottery draws, etc.

Step ST12: In the server device 2, the lottery condition reception unit 21A (see Figure 2) receives the instruction to set the lottery condition CJ described above, i.e., accepts the lottery condition CJ. The lottery condition reception unit 21A stores the accepted lottery condition CJ in the storage unit 22 (see Figure 2).

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 shown in Figure 4.

Step ST14: In the server device 2, the lottery request receiving unit 21B (see Figure 2) receives the lottery request CY described above, i.e., 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.

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 referenced 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 lottery), the system determines that the current lottery request satisfies lottery condition CJ. If the number of executions is 10 or more (i.e., the current lottery request is the 11th or later lottery request), the system determines that the current lottery request does not satisfy lottery condition CJ. The control unit may also store the determination result or transmit it to other devices.

<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 game GM's play by player 4(1) is restricted, player 4(1) can limit the game GM's play themselves, that is, it becomes possible to restrict the period KK, number of times KS, charge KA, etc. (see Figure 6) during which player 4(1) can request the lottery C.

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

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

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

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

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

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 cases where the lottery request CY satisfies the lottery condition CJ and where it does not.

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

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.

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

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

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

<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 draw C and whether or not to send a notification T, based on the result of the determination unit 21C's determination HT of whether or not the draw request CY satisfies the draw condition CJ. In particular, by sending a notification T to player 4(1) stating that "the draw 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.

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

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

<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 determines the reward TT to be given 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). Based on the difference with the lottery request CY (see Figure 1) that the player desires, the reward TT (see Figure 4) is given to the player 4.

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

The difference between the lottery request CY and the lottery condition CJ, or more precisely, the difference or percentage 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 percentage 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 percentage is 1.2 (120%).

The achievement level (MT) may be expressed 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 time (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.

The server device 2's memory unit 22 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 based on the total number of achievements over a predetermined period (e.g., the number of achievement days in one month), or based on the number of consecutive achievements (e.g., the number of consecutive days). Alternatively, reward information TTJ may remain constant regardless of the achievement level.

The bonus information TTJ indicates, more specifically, that if player 4(1)'s achievement level MT is MT1, the server device 2 will grant bonus TT1 to player terminal 3(1). Furthermore, if player 4(1)'s achievement level MT is MT2, the server device 2 will grant bonus TT2 to player terminal 3(1).

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

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

For the sake of clarity and ease of understanding, we assume that player 4(1) of player terminal 3(1) is performing lottery C under lottery condition CJ.

Step ST21: At a predetermined point in 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 the achievement level MT is MT2.

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

Step ST22: In the 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 the reward to player 4(1). At that time, the player information in the storage unit of the server device 2 is updated based on the reward.

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

<Embodiment 4>
The game system 1 of embodiment 4 will now be described.

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

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

Figure 12 shows the player condition PJ of Embodiment 4.

The player condition PJ is stored in the storage unit 22 of the server device 2, as shown in Figures 2 and 12. The player condition PJ, as shown in Figure 12, consists of the number of times player 4 actually performed (or requested) the lottery C (KS), the amount of money KA actually used by player 4 for the lottery C, and the duration KK during which player 4 actually played as the game GM.

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 (KA) Player 4 spent on Lottery C is, for example, 10,000 yen or more per day, or 5,000 yen or more per day. The cumulative duration (KK) Player 4 played as Game GM is, for example, 10 hours or more per day, or 5 hours or more per day.

Figure 13 shows the proposed information TAJ for Embodiment 4.

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 player 4(1)'s lottery request CY 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, if the condition set by player 4 is "60 times or less/day" and the actual number of times performed is 40, the server device 2 may propose "80 times or less/day" as the condition for the next day, which is the difference of 20 times between 60 and 40. Furthermore, if the target is not met, stricter conditions may be proposed in proportion to the difference. For example, if the player condition PJ is "60 times/day" and the number of times it has been conducted is 80, then "40 times/day" (60 minus the difference of 20) may be proposed as the recommended condition. In this way, the proposed conditions may be calculated based on the lottery conditions for a predetermined period (e.g., "60 times or less/day"), the actual number of lotteries performed during that period (e.g., 40 times), and predetermined calculation conditions (addition, multiplication, division, etc.). In other words, the proposed information may be determined for each player 4. Note that the proposed information may be common to all players 4 , in which case the proposed information may be presented (notified) to all players 4 at a predetermined time.

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

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

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

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, after a full day has elapsed since player 4(1) sent the lottery condition CJ to the server device 2 and set the conditions.

Step ST32: If the determination unit 21C determines that the status of the lottery request CY by player 4(1) matches 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). The proposed conditions may be one or more.

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.

<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 proposals according to the degree to which player 4(1) has achieved the conditions.

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

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

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

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

The message ME of Embodiment 5, as shown in Figure 15, has the following content, for example.
1. When the lottery condition CJ is "10 times/day" (1) When the cumulative number of lotteries (or lottery request CY) per day is "9 times (9th time)" the message ME will contain information about the number of times remaining 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", the message ME will be something to the effect of "This is the last draw C for today", or something to the effect of "You have reached the maximum number of draws for today", indicating that the draw conditions have been met.
2. When the lottery condition CJ is "1,000 yen/day" (1) When the amount of consideration spent per day in connection with the lottery (cumulative amount of requested CY) is "900 yen", the message ME is information about the remaining consideration until the condition is met, such as "You can request 100 yen more for the lottery".
(2) When the cumulative amount of CY requested for the lottery per day is "1,000 yen", the message ME will be something like "This is the last lottery C for today" indicating that the lottery conditions have been met. The timing of such notifications is predetermined and may be when the server receives the player's lottery request,

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

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

To facilitate explanation and understanding, it is assumed that player 4(1)'s player terminal 3(1) and server device 2 communicate with each other.

Step ST41: In the same manner as in 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 the extent of the difference between the lottery request CY and the lottery condition CJ.

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

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 for the "9th" lottery, it determines that one more lottery request CY can be made. The notification unit 21E then sends a notification T to player terminal 3(1) with message ME "One more lottery request CY can be made."

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", then the determination unit 21C determines that it is the last lottery C. 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."

<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 by themselves compared to the game system 1 of Embodiment 1.

<Embodiment 6>
The game system 1 of embodiment 6 will now be described.

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

<Operation of Embodiment 6>
In the game system 1 of Embodiment 6, for example, when it is determined that a 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 system notifies player 4(1) of a restart condition SJ (see Figure 17 ), which is the condition under which player 4(1) can restart the lottery request CY.

Figure 17 shows the restart information SKJ of Embodiment 6.

The restart information SKJ is pre-stored in the storage unit 22 of the server device 2, as shown in Figures 2 and 17. The restart information SKJ indicates a plurality of restart conditions SJ1, SJ2, SJ3, etc., as shown in Figure 17. For example, the restart information SKJ indicates restart condition SJ1 "after the date changes", restart condition SJ2 "after 6 hours have passed", and restart condition SJ3 "after the lottery condition CJ has been changed". In other words, the restart information SKJ indicates the timing at which cumulative values related to the lottery (cumulative number of times, cumulative amount of consideration, cumulative time, etc.) are reset.

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

The operation of the game system 1 in Embodiment 6 will be explained with reference to the flowchart in Figure 18 .

To facilitate explanation and understanding, it is assumed that player 4(1)'s player terminal 3(1) and server device 2 communicate with each other.

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

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) by 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, it 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) to prevent the input of a lottery request CY.

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

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

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

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

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

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

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

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

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

To facilitate explanation and understanding, it is assumed that communication will occur between player 4(1)'s player terminal 3(1) and server device 2.

Steps prior to ST61: Similar to 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) to server device 2; that is, server device 2 has already received the lottery condition CJ from player 4(1). Note that server device 2 does not necessarily need to have received the lottery condition CJ.

Step ST61: Player 4(1) sends a request from player terminal 3(1) to server device 2 to switch the necessity of lottery restrictions and lottery notifications. For example, player 4(1) sends a request to switch whether or not the determination HT is necessary to determine whether the upcoming lottery request CY satisfies the lottery conditions CJ already set by player 4(1), i.e., whether to execute or stop the determination HT. 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/off), can be switched. Note that the necessity of executing both the lottery restriction function and the lottery notification function (on/off) may be switched together, or only one of them may be switched.

Step ST62: In the server device 2, the switching unit 21K (see Figure 2) switches whether to perform the determination HT (determination time) for determining whether a lottery is necessary or for notification, 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. The determination of whether a determination is necessary is updated in the storage unit each time the switch is made.

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 pre-set by player 4(1). 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 may 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.

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 necessary, that is, that a determination HT should be performed, then the determination unit 21C in the server device 2 will perform a determination HT to determine whether the lottery request CY from player 4(1) satisfies the lottery request CY pre-set by player 4(1). In other words, player 4(1) can perform the lottery C by the lottery unit 21F within the range of the lottery conditions CJ.

<Effects of Embodiment 7>
As described above, in the game system 1 of embodiment 7, the server device 2 switches whether to perform or not perform the decision HT in response to a request from player 4(1) regarding the necessity of the decision HT, that is, in response to a request regarding whether to perform the decision 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.

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

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

<Operation of Embodiment 8>
In the game system 1 of embodiment 8, for example, the billing history KR (see Figure 20), which is the history of billing KA (see Figures 6 and 12) by player 4(1) at the game GM (see Figure 4 ), is stored, and in response to a request from player 4(1), the billing history KR of player 4(1) is notified to player 4(1).

Figure 20 shows the billing history KR of Embodiment 8.

The billing history KR is stored in the storage unit 22 of the server device 2, as shown in Figures 2 and 20. The billing history KR shows the charge KA for lottery C, the purchase of game media 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 the charge KA for lottery C, and 500 yen on the purchase of game media GB, for a total of 1,500 yen (= 1,000 yen + 500 yen). Such billing history is stored in the storage unit (the storage unit is updated) each time a charge is made. The billing history KR may also provide more detailed information about the items and amounts charged. For example, if there are multiple types of paid in-game currency (such as paid gems) or game media (such as characters and items), the billing amount may be displayed for each type of in-game currency and game media. Furthermore, the information is not limited to being presented daily; it can also be presented by time of day, week, or month.

Figure 21 is a flowchart showing the operation of the game system 1 in Embodiment 8.

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

To facilitate explanation and understanding, we assume communication between player 4(1)'s player terminal 3(1) and server device 2.

Step ST71: After completing steps ST11 and ST12 of Embodiment 1, and after performing the lottery request CY in step ST13 at least once, player 4(1) requests the server device 2 from the player terminal 3(1) to notify player 4(1) of the billing history KR. For example, an icon for requesting 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.

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 the lottery C billing KA, and 2,000 yen was spent on the game medium GB, for a total of 3,500 yen (2,000 yen + 1,500 yen)." In this way, the object (type) of the payment and the amount of the payment (amount for each item, total amount) can be presented.

<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 to player 4(1) T. 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.

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

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

<Operation of Embodiment 9>
In the game system 1 of embodiment 9, for example, difference information JYSJ (see Figure 22) is calculated, which shows the difference between the lottery conditions CJ set by player 4(1) and the history of actual lottery results (or lottery requests CY) performed by player 4( 1 ). In response to a request from player 4(1), the difference information JYSJ is notified to player 4(1) T.

Figure 22 shows the differential information JYSJ of Embodiment 9.

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

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

The differential information JYSJ also indicates, for example, that, similarly to the above, if player 4(1)'s draw condition CJ is 10 times/day, then on Friday the 2nd, player 4(1) made 11 draw requests CY, resulting in a differential JYS of +1 (= 11 - 10), and a differential (cumulative) JYS(R) of -2 (= -3 + 1).

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

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

To facilitate explanation and understanding, we assume communication between player 4(1)'s player terminal 3(1) and server device 2.

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

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 times, and the differential (cumulative) JYS(R) is -4 times.

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

<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 on their own compared to Embodiment 1.

<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 further include an input circuit NYU and an output circuit SYU as needed. 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 is, 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 the 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 the player terminal 3.

<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 (also called a Central Processing Unit, 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-mentioned program PRG can be said to primarily 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, the memory circuit KIO is, for example, non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), as well as magnetic disks, flexible disks, optical disks, compact disks, minidiscs, DVDs (Digital Versatile Discs), etc.

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.

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 player terminal 3.

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

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 draws, 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. Note that it is 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. By displaying the count information associated with the lottery event on the player's terminal in this way, players can refer to this information when setting the lottery conditions.

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 times the lottery is performed within a predetermined period exceeding a specific value (threshold), or the cumulative value of the consumption price within 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. According to this, for example, a restriction function can be suggested to players who exceed 100 lottery entries per day or spend more than 100,000 yen. It is preferable that this suggestion be applied to players who have either the restriction function, the notification function, or both turned off. This allows for prompting players who excessively participate in lotteries to limit their entries or receive notifications.

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

[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,
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 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 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 lottery conditions and the player's actual lottery results at a predetermined point in time.
[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 will be 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 information processing system according to claim 1, wherein the lottery condition receiving unit receives a specification of a period from the player as an instruction to set the lottery conditions.
[Item 7]
The information processing system according to claim 1, further comprising a proposal unit that proposes recommended conditions regarding the lottery conditions to the player who satisfies predetermined proposal conditions.
[Item 8]
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.
[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 information processing system according to claim 1, further comprising a notification unit that outputs the differential information based on the player's request.
[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,
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 that includes this .
[Item 14]
A lottery request acceptance step in which a player submits a lottery request requesting 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,
Information processing methods including
[Item 15]
On the computer,
A lottery request acceptance step in which a player submits a lottery request requesting 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.

Claims (14)

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. 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 conduct the lottery, based on the result of the determination. 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.
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. The information processing system according to claim 1, wherein the lottery conditions include an upper limit on the cumulative amount of consideration consumed when executing the lottery during a predetermined period. 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.
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. 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 proposal unit that proposes recommended conditions regarding the lottery conditions to the aforementioned player who meets predetermined proposal conditions. 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 lottery draws or the cumulative value of the prize money received within a predetermined period reaches a specific value based on the lottery conditions. The information processing system according to claim 1, further comprising a notification unit that, if the determination unit determines that the lottery request does not satisfy the lottery conditions, notifies the player of the conditions under which the player can resume the lottery. 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 switching unit that switches whether or not to perform the determination based on a request from the player. 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. 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 information processing system according to claim 1, further comprising a notification unit that outputs the differential information based on the player's request. 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 a comparison result between the lottery conditions and the player's actual lottery results at a predetermined point in time . A lottery request acceptance step in which a player submits a lottery request requesting 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. On the computer,
A lottery request acceptance step in which a player submits a lottery request requesting 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 .