Information processing system, information processing method, server, and program

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

[0002] Patent Document 1 discloses a technology for increasing the flexibility of parental controls that allow parents (guardians) to manage and restrict the behavior of their children (protected persons) in games. The server system described in Patent Document 1 restricts the child's play of a game if the child's use of an electronic payment medium while playing the game violates the restriction conditions preset by the parent. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-013151 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the server system described above does not allow the child game device to set or relax game restrictions on its own, meaning that the child game device cannot prevent itself from, for example, impulsively repeating gacha.

[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 game players to limit their own game play. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems, the information processing system of the present disclosure includes a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one of a plurality of game media available in the game, a lottery condition receiving unit that receives an instruction from the player to set lottery conditions, which are conditions related to the lottery, and a determination unit that, when the lottery request is received, determines whether the lottery request satisfies the lottery conditions. [Effects of the Invention]

[0007] According to the information processing system of the present disclosure, it becomes possible for a player to limit the play of a game by himself or herself. [Brief explanation of the drawings]

[0008] [Figure 1] 1 shows the configuration of a game system 1 according to a first embodiment. [Figure 2] 2 shows the configuration of a server device 2 according to the first embodiment. [Figure 3] 2 shows the configuration of a player terminal 3 of the first embodiment. [Figure 4] 1 shows an example of a screen of a game GM in embodiment 1. [Figure 5] 1 shows the structure of game media information GBJ according to the first embodiment. [Figure 6] 10 shows the lottery conditions CJ of the first embodiment. [Figure 7] 3 is a flowchart showing the operation of the game system 1 of the first embodiment. [Figure 8] 10 is an example of a flowchart showing the operation of the game system 1 of the second embodiment. [Figure 9] 10 is another example of a flowchart showing the operation of the game system 1 of the second embodiment. [Figure 10] 10 shows the achievement level MT and the benefit TT of the third embodiment. [Figure 11] 10 is a flowchart showing the operation of the game system 1 of the third embodiment. [Figure 12] 10 shows the player condition PJ of the fourth embodiment. [Figure 13] 10 shows proposal information TAJ according to the fourth embodiment. [Figure 14] 10 is a flowchart showing the operation of the game system 1 of the fourth embodiment. [Figure 15] 11 shows the contents of a message ME according to the fifth embodiment. [Figure 16] 10 is a flowchart showing the operation of the game system 1 of the fifth embodiment. [Figure 17] 11 shows resumption information SKJ of the sixth embodiment. [Figure 18] 13 is a flowchart showing the operation of the game system 1 of the sixth embodiment. [Figure 19] 13 is a flowchart showing the operation of the game system 1 of the seventh embodiment. [Figure 20] 13 shows the billing history KR of the eighth embodiment. [Figure 21] 13 is a flowchart showing the operation of the game system 1 of the eighth embodiment. [Figure 22] 10 shows the difference information JYSJ of the ninth embodiment. [Figure 23] 13 is a flowchart showing the operation of the game system 1 of the ninth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] An embodiment of a game system according to the present disclosure will be described.

[0010] First Embodiment A game system 1 according to the first embodiment will be described.

[0011] Configuration of First Embodiment <Configuration of Game System 1> FIG. 1 shows the configuration of a game system 1 according to the first embodiment.

[0012] 1, the game system 1 of the first embodiment includes a server device 2 and player terminals 3(1) to 3(m) (m is an integer equal to or greater than 2). The server device 2 and the player terminals 3(1) to 3(m) are connected to each other 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), and so on, and player terminal 3(m) is used by player 4(m).

[0014] In the following, for ease of explanation and understanding, multiple identical devices may be collectively referred to 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 the first embodiment, as shown in Fig. 1, a player 4 transmits various input information such as a lottery condition CJ and a lottery request CY from a player terminal 3 to a server device 2 via a network 5. The server device 2 can perform a lottery C and transmit a notification T to the player terminal 3 of the player 4 via the network 5.

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

[0017] <Configuration of Server Device 2> FIG. 2 shows the configuration of the server device 2 of the first embodiment.

[0018] As shown in FIG. 2, the server device 2 of the first embodiment 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 receiving unit 21A, a lottery request receiving unit 21B, a judgment unit 21C, a determination unit 21D, a notification unit 21E, a lottery unit 21F, a benefit determination unit 21G, a benefit granting unit 21H, a suggestion unit 21J, a switching unit 21K, and a calculation unit 21L.

[0020] As shown in FIG. 2, the storage unit 22 stores game medium information GBJ, lottery conditions CJ, lottery request CY, benefit 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 receiving 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> FIG. 3 shows the configuration of the player terminal 3 of the first embodiment.

[0023] As shown in FIG. 3, the player terminal 3 of the first embodiment has 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 the operation of the game system 1 is explained.

[0025] <Game GM, Game Media GB, Bonus TT> The type of game GM is not particularly limited, and may be, for example, a competitive game, a puzzle game, an action game, a baseball game, a soccer game, other sports games, a quiz game, a pinball game, a card game, a rhythm game, an RPG (role-playing game), a location-based game, a board game, an adventure game, a casino game, a simulation game, a strategy game, a racing game, etc.

[0026] In the first embodiment, the output unit 34 of the player terminal 3 (see FIG. 3) displays a screen of the game GM played by the player 4, as shown in FIG. 4. The game GM contains, for example, game media GB and a bonus TT. The game GM screen can display an icon requesting a lottery and an icon requesting the setting of lottery conditions. The output unit 34 outputs images, sounds, and vibrations using a touch panel, display, speaker, vibration, etc.

[0027] The game media GB may be, for example, characters, items, or cards representing them used in the game. A player 4 playing the game GM can acquire game media GB through, for example, a lottery C (so-called gacha). Game media GB may be acquired in various ways, such as by paying, completing or clearing a quest, combining game media, or using a predetermined item. The game media GB may also be automatically awarded by the system at a predetermined timing, such as when a player first plays the game or when a player reaches a predetermined stage in the game. The lottery is not limited to gacha, but may also be a drop resulting from the execution of a game element such as a quest (a process in which game media are randomly awarded upon execution of a game element). 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 may execute a lottery in which selection is made based on information input by the player.

[0028] The reward TT is something that benefits Player 4 in the game GM. The reward is not particularly limited as long as it benefits the player in the game, and may be, for example, the granting of game media (in-game content) such as in-game currency, in-game points, or various items, the relaxation (including partial lifting of restrictions) or lifting (granting the right to execute various functions) of various in-game restrictions, the change (increase, decrease) of various parameters (level, experience points, stamina, ability values ​​of game media, amount that can be borrowed), the increase of the upper limit of parameters, the decrease of the lower limit, the recovery of stamina, etc. Furthermore, the benefits may include changes to the type of game media, winning probability, rarity, amount (number) acquired, etc. in processes involving various lotteries (gacha, drop, synthesis, etc.), changes to the clear reward (whether a clear reward is even obtained, game media (rarity, type, amount acquired simultaneously)), changes to the type of success and success rate in a strengthening (development) event, attack hit rate, skill activation rate, critical rate, type of critical, rate of special effect (poison, paralysis, etc.), evasion success rate, counterattack success rate, defense success rate, success rate of escape, increased skill effect, occurrence of special enemies, special event occurrence rate, etc. Furthermore, the benefits are not limited to changes in the above items that are advantageous for the player or a player with a specific relationship such as an ally or friend, but may also change the above items to a disadvantage for the opposing player. Changing the above items to put the enemy player at a disadvantage may mean, for example, that the enemy player's ability value is reduced, the accuracy of the enemy player's attacks is reduced, or the enemy character itself is changed into a character with lower abilities.

[0029] <Game Media Information GBJ> FIG. 5 shows the structure of the game media information GBJ according to the first embodiment.

[0030] The memory unit 22 (see FIG. 2) of the server device 2 stores game medium information GBJ, as shown in FIG. 2. The game medium information GBJ includes various parameters such as the identification information (ID information) of the game medium GB, the name, attributes, rarity, winning probability, and attack power. As shown in FIG. 5, the game medium information GBJ includes information on multiple game media such as game medium GB1, game medium GB2, game medium GB3, etc. As shown in FIG. 5, the server device 2 can, for example, award one (or multiple) game media selected by lottery C in the game GM played by player 4(1). For example, the server device 2 awards game medium GB2, which is the result of the lottery, to player 4(1).

[0031] <Lottery Conditions CJ> 6 shows the selection conditions CJ according to embodiment 1. The selection conditions are stored in the storage unit.

[0032] The lottery conditions CJ in the first embodiment are set based on the input information of the player 4, as shown in Fig. 1. Specifically, when the user selects the condition setting request icon shown in Fig. 4 and inputs the number of lottery draws, the lottery time limit, etc., these are transmitted 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 is in the storage unit 22 (see Fig. 2) of the server device 2, or may change the received conditions based on predetermined conditions and store them.

[0033] The lottery conditions CJ are conditions (restriction conditions) related to the lottery for each player 4. More specifically, the lottery conditions CJ are conditions related to the lottery C for selecting one of multiple game media GB (e.g., game media GB1, GB2, GB3, ... (see FIG. 5)) that can be used in the game GM. As shown in FIG. 6, the lottery conditions CJ include, for example, restriction information on the consumption of consideration such as the lottery period KK, the number of times KS, and the charge KA.

[0034] As shown in FIG. 6, the period KK can be, for example, 6 hours, 12 hours, 1 day, 2 days, 1 week, etc. For example, if player 4(1) transmits to server device 2 that the period KK is 6 hours, server device 2 will allow player 4(1) to make a lottery request CY for up to 6 hours. In other words, player 4(1) can execute lottery C (cause server device 2 to execute lottery processing) for only 6 hours from a predetermined time point (from the time of request or specified time point). Note that after 6 hours have passed, the lottery may no longer be executed (a request to execute lottery processing may no longer be made to server device 2), or a message indicating that the time limit has elapsed may be notified when the player requests to execute a lottery. If a notification is issued, the execution of the lottery may be limited, or the notification may be issued without any limit.

[0035] 6, the number of times KS is, for example, 1 time, 5 times, 10 times, 30 times, 50 times, etc. For example, when player 4(1) transmits to server device 2 that the number of times KS is 10 times, server device 2 allows player 4(1) to make lottery requests CY up to a maximum of 10 times; in other words, player 4(1) can execute lottery C only 10 times.

[0036] As shown in Fig. 6, the charge KA is, for example, 100 yen, 200 yen, 500 yen, 1000 yen, etc. For example, when player 4(1) transmits to server device 2 that the charge KA is 500 yen, server device 2 allows player 4(1) to make a lottery request CY with an upper limit of 500 yen. In other words, player 4(1) can execute lottery C for only 500 yen. Note that the limit is not limited to charges, and it is also possible to set limit information on the consumption of the consideration required to execute the lottery, such as stones IS in Fig. 6, other jewels, and other in-game currencies, items, etc.

[0037] By combining any or all of the setting items of the period KK, the number of times KS, and the charge KA, player 4 can specify a composite condition of the lottery condition CJ, such as 10 times / 12 hours, 1,000 yen / 2 days, or 100 koku / 1 day, as shown in FIG. 6. For example, if player 4(1) transmits to server device 2 that the upper limit value JG of the lottery condition CJ is 10 times / 12 hours, server device 2 allows 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 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 so that it cannot be selected, or after the selection of the lottery execution request icon is accepted, text or an image may be displayed indicating that the lottery cannot be executed. Furthermore, text or an image indicating that the lottery cannot be executed may be displayed on the screen of FIG. 4, etc.

[0038] Operation of the First Embodiment FIG. 7 is a flowchart showing the operation of the game system 1 of the first embodiment.

[0039] The operation of the game system 1 of the first embodiment will be described with reference to the flowchart of FIG.

[0040] For ease of explanation and understanding, it is assumed that communication takes place between the player terminal 3(1) of the player 4(1) and the server device 2.

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

[0042] Step ST12: In the server device 2, the lottery condition receiving unit 21A (see FIG. 2) receives the instruction to set the above-described lottery condition CJ, that is, receives the lottery condition CJ. The lottery condition receiving unit 21A stores the received lottery condition CJ in the storage unit 22 (see FIG. 2).

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

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

[0045] Step ST15: In the server device 2, the judgment unit 21C (see FIG. 2) performs a judgment HT to determine whether or not the execution of a lottery based on the lottery request CY received in step ST14 satisfies the lottery condition CJ received in step ST12. Specifically, the judgment unit 21C performs a judgment HT to determine whether or not the received lottery request CY satisfies the above-mentioned lottery condition CJ "10 times (or less) / 12 hours." Note that the execution history of lotteries is stored in the storage unit, and the judgment unit 21C determines whether or not the execution of a lottery based on the received lottery request CY satisfies the lottery condition CJ by referring to the number of times lotteries have been executed in a predetermined period (this month, this week, the last 12 hours, or the period from a specific time to the present). More specifically, for example, if the number of lottery executions within a predetermined period up to the present time is less than 10 (i.e., if the current lottery request is the 1st to 10th), it is determined that the current lottery request satisfies the lottery condition CJ, and if the number of lottery executions is 10 or more (i.e., if the current lottery request is the 11th or more), 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 the First Embodiment As described above, in the game system 1 of the first embodiment, the server device 2 receives the lottery condition CJ and the lottery request CY from the player terminal 3(1) of the player 4(1) and performs a determination HT as to 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 FIG. 2) can prevent the lottery C (see FIGS. 1 and 5) from being executed or can issue a notification. As a result, the player 4(1)'s play of the game GM is restricted, allowing the player 4(1) to limit his or her own play of the game GM. In other words, it becomes possible to limit the period KK, the number of times KS, the charge KA, and the like (see FIG. 6) during which the player 4(1) can request the lottery C.

[0047] Second Embodiment A game system 1 according to the second embodiment will be described.

[0048] <Configuration of Second Embodiment> The game system 1 of the second embodiment has the same configuration as the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0049] <Operation of the Second Embodiment> 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 decides, for example, whether or not to execute a lottery C (see Figures 1 and 5) for player 4(1) and whether or not to notify player 4(1) of the lottery C (see Figure 1).

[0050] FIG. 8 is a flowchart showing the operation of the game system 1 of the second embodiment.

[0051] The operation of the game system 1 of the second embodiment will be described with reference to the flowchart of FIG.

[0052] For ease of explanation and understanding, it is assumed that communication takes place between the player terminal 3(1) of the player 4(1) and the server device 2. In addition, the explanation will be divided into cases where the lottery request CY satisfies the lottery condition CJ and where it does not.

[0053] <When the lottery request CY satisfies the lottery condition CJ> Step ST16A: In step ST15 (see FIG. 7) of the first embodiment, when the judgment unit 21C (see FIG. 2) makes a judgment HT that the lottery request CY satisfies the lottery condition CJ, the determination unit 21D decides to hold a lottery C and decides not to issue any notification T to the player 4(1). Note that conditions may be set so that even when the lottery request CY satisfies the lottery condition CJ, a notification (such as a notification that the condition is met or a notification that the lottery can be held) is issued. Furthermore, both a judgment as to whether or not to hold a lottery and a judgment as to whether to issue a notification may be made, or only one of them may be made.

[0054] Step ST17A: In the server device 2, the lottery section 21F (see FIG. 2) holds the lottery C in response to the decision to hold the lottery C by the determination section 21C.

[0055] Step ST18A: The lottery unit 21F (see FIG. 2) executes the above-described lottery C to select one game medium (e.g., game medium GB2 (see FIG. 5)) from the plurality of game media GB (game media GB1, GB2, GB3, ...) and award it to player 4(1). Note that the game medium selected by lottery may be stored in association with the player, thereby awarding the game medium to the player, or allowing the player to obtain effects, rights, etc. associated with the game medium.

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

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

[0058] Effects of the Second Embodiment As described above, in the game system 1 of the second embodiment, the determination unit 21D determines whether to hold the lottery C and whether to issue the notification T, according to the result of the determination unit 21C's determination HT of whether the lottery request CY satisfies the lottery condition CJ. In this way, by issuing the notification T to the player 4(1) that "the lottery C cannot be held," it is possible to make the player 4(1) more aware than in the first embodiment that he or she is restricting the play of the game GM.

[0059] Third Embodiment A game system 1 according to a third embodiment will be described.

[0060] <Configuration of the Third Embodiment> The configuration of the game system 1 of the third embodiment is similar to the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0061] <Operation of the Third Embodiment> The game system 1 of the third embodiment differs from the game system 1 of the first embodiment in that, for example, a benefit to be granted to a player is determined based on the comparison result between the lottery conditions CJ (see FIG. 1) preset by the player 4(1) and the lottery performance value of the player 4(1). A benefit TT (see FIG. 4) is granted to the player 4(1) based on the difference between the lottery request CY (see FIG. 1) desired by the player 4(1).

[0062] FIG. 10 shows an example of the achievement level MT and the reward TT according to the third embodiment.

[0063] 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 (particularly, the upper limit JG (see Figure 6)), is defined as the "achievement level MT." For example, if the lottery condition CJ (the upper limit of the number of times the lottery is executed) is 10 times and the actual value of the lottery is 5 times (when the condition is achieved), the difference between them is "5," and the ratio is 0.5 (50%). Also, if the lottery condition CJ is 10 times and the actual value of the lottery is 12 times, the difference between them is "-2," and the ratio is 1.2 (120%).

[0064] The achievement level MT may be displayed as a number (or a percentage) of days that the condition was met (or not met) in a predetermined period, such as, for example, "This month, there were a total of 12 days when the condition was met (achievement level MT1)." Alternatively, it may be expressed as a number (hours, days, weeks, months, etc.) of consecutive days when the condition was met, such as, "This month, there were 7 consecutive days when the condition was met (achievement level MT2)." In this case, the unit of the period (seconds, minutes, hours, days, weeks, months, years, etc.) or the predetermined period (1 hour, 12 hours, 1 day, 1 week, 1 month, 1 year, etc.) is not particularly limited.

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

[0066] More specifically, the bonus information TTJ indicates that, for example, if the achievement level MT of player 4(1) is achievement level MT1, the server device 2 will grant bonus TT1 to the player terminal 3(1), and if the achievement level MT of player 4(1) is achievement level MT2, the server device 2 will grant bonus TT2 to the player terminal 3(1).

[0067] FIG. 11 is a flowchart showing the operation of the game system 1 of the third embodiment.

[0068] The operation of the game system 1 of the third embodiment will be described with reference to the flowchart of FIG.

[0069] For ease of explanation and understanding, it is assumed that player 4(1) of player terminal 3(1) is executing lottery C under lottery condition CJ.

[0070] Step ST21: At a predetermined point in time (for example, when the upper limit value JG (see FIG. 6) of the lottery condition CJ is "100 times / month," this is the point in time when "one month" has passed), in the server device 2, the benefit determination unit 21G (see FIG. 2) compares the lottery condition CJ with the lottery history (which may be the history of the lottery request CY) stored in the memory unit 22 (see FIG. 2) (steps ST12 and ST14 in embodiment 1). The benefit determination unit 21G calculates the achievement level MT of the player 4(1) through this comparison. Here, for example, it is assumed that the achievement level MT is the achievement level MT2.

[0071] The benefit determination unit 21G determines to grant a benefit TT2 based on the above-mentioned achievement level MT2 by referring to the benefit information TTJ (see FIGS. 2 and 10).

[0072] Step ST22: In the server device 2, the benefit granting unit 21H (see FIG. 2) transmits information about the benefit TT2 to the player terminal 3(1) of the player 4(1), that is, grants the benefit to the player 4(1). At that time, the player information in the storage unit of the server device 2 is updated based on the benefit.

[0073] Effect of the Third Embodiment As described above, in the game system 1 of the third embodiment, a reward TT is determined based on the achievement level MT, which is the difference between the lottery condition CJ set by the player 4(1) and the lottery request CY made by the player 4(1), and the reward TT is granted to the player 4(1). This can motivate the player 4(1) to limit his or her own game play. The conditions for granting a reward may include multiple conditions, such as a first condition with a short period and a second condition with a longer period. For example, the first condition may be "10 times / day," and a condition for a period longer than one day (e.g., one month) (e.g., "1,000 times / month," or the total number of times the first condition is achieved or the number of consecutive times the first condition is achieved) may be set as the second condition. Furthermore, the first condition may be set based on a user input (an instruction to set the lottery condition CJ), and the second condition may be set by the system. Alternatively, all conditions (e.g., the first and second conditions) may be set based on a user input (an instruction to set the lottery condition CJ).

[0074] Fourth Embodiment A game system 1 according to a fourth embodiment will be described.

[0075] <Configuration of Fourth Embodiment> The configuration of the game system 1 of the fourth embodiment is similar to the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0076] <Operation of the Fourth Embodiment> The game system 1 of embodiment 4 differs from the game system 1 of embodiment 1 in that, for example, if the lottery record (or lottery request record CY) by player 4(1) at the game GM (number of times KS, fee charged KA, period KK; see Figure 12), and the conditions (hereinafter referred to as "player conditions") PJ predefined for player 4 are met, recommended conditions SJ related to the lottery conditions CJ are proposed to player 4(1).

[0077] FIG. 12 shows the player condition PJ in the fourth embodiment.

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

[0079] The number of times KS that player 4 has requested lottery C is, for example, 100 or more times per day, or 50 or more times per day. The amount of money KA that player 4 has spent on lottery C is, for example, 10,000 yen or more per day, or 5,000 yen or more per day. The (cumulative) period KK that player 4 has played game GM is, for example, 10 hours or more per day, or 5 hours or more per day.

[0080] FIG. 13 shows the proposal information TAJ according to the fourth embodiment.

[0081] As shown in FIG. 2, the suggested information TAJ is stored in the storage unit 22 of the server device 2. As shown in FIG. 13, the suggested information TAJ includes recommended conditions SJ. For example, when a lottery request CY by player 4(1) in the game GM (see FIG. 4) satisfies the player condition PJ of "60 times / day," the suggested information TAJ indicates that recommended conditions SJ of "80 times or less / day" should be proposed to player 4(1) instead of the lottery conditions CJ set by player 4(1). The recommended conditions SJ proposed by the server device 2 may increase the number or frequency of lottery draws for player 4 compared to the lottery conditions CJ achieved by player 4, or may impose stricter restrictions on lottery draws. For example, if the condition set by the player is "60 times or less / day" and the actual number of draws is 40, the suggested condition for the next day may be "80 times or less / day," which is calculated by adding 20 times, the difference between 60 and 40. Furthermore, if the target is not achieved, stricter conditions may be proposed according to the difference. For example, if the player condition PJ is "60 times / day" and the number of times the game has been played is 80 times, "40 times / day" may be proposed as the recommended condition, which is 60 minus the difference of 20. 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 lottery performance value for 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. Note that the proposed information may be common to all players, and in that case, the proposed information may be presented (notified) to all players at a predetermined timing (predetermined time).

[0082] <Operation of the Fourth Embodiment> FIG. 14 is a flowchart showing the operation of the game system 1 of the fourth embodiment.

[0083] The operation of the game system 1 of the fourth embodiment will be described with reference to the flowchart of FIG.

[0084] For ease of explanation and understanding, it is assumed that the player terminal 3(1) of the player 4(1) and the server device 2 are communicating with each other.

[0085] Step ST31: In the server device 2, the judgment unit 21C (see Figure 2) judges, for example, in the same manner as in step ST13 of embodiment 1, whether or not the status of the game GM play record (or lottery request CY) by player 4(1) for that one day satisfies, i.e., whether or not it corresponds to, the player conditions PJ (e.g., 100 times or more / day, 10,000 yen or more / day, 10 hours or more / day) when a full day has passed since player 4(1) sent the lottery conditions CJ to the server device 2 and set the conditions.

[0086] Step ST32: If the determination unit 21C determines that the situation of the lottery request CY by the player 4(1) corresponds to any of the player conditions PJ, the suggestion unit 21J (see FIG. 2) proposes to the player 4(1) the recommended conditions SJ corresponding to the player conditions PJ. The proposed conditions may be one or multiple.

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

[0088] Effects of the Fourth Embodiment As described above, in the game system 1 of the fourth embodiment, when the determination unit 21C determines that the situation of the lottery request CY by the player 4(1) meets the player condition PJ, the suggestion unit 21J proposes the recommended condition SJ to the player 4(1) instead of the lottery condition CJ set by the player 4(1). This makes it possible to make a suggestion according to the degree to which the player 4(1) has achieved the condition.

[0089] Fifth Embodiment The game system 1 of the fifth embodiment will be described.

[0090] <Configuration of the Fifth Embodiment> The configuration of the game system 1 of the fifth embodiment is similar to the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

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

[0092] FIG. 15 shows the contents of the message ME in the fifth embodiment.

[0093] The message ME of the fifth embodiment has the following content, for example, as shown in FIG. 1. When the lottery condition CJ is "10 times / day" (1) When the cumulative number of lottery draws (or lottery request CY) per day is "9 times (9th time)" The message ME contains information about the number of times remaining until the condition is reached, such as "You can make one more lottery request CY." (2) When the cumulative number of lottery draws (or lottery request CY) per day is "10th" The message ME contains a message indicating that the lottery conditions have been met, such as "Today is the last lottery C," or "The maximum number of draws has been reached today." 2. When the lottery condition CJ is "1,000 yen / day" (1) When the amount of the fee for the lottery per day (the cumulative amount of the required CY) is 900 yen The message ME is information about the remaining amount until the condition is reached, such as "You can request a lottery CY for the remaining 100 yen." (2) When the cumulative amount of lottery request CY charges per day is 1,000 yen The message ME indicates that the lottery conditions have been met, such as "Today is the last lottery C." The timing of such notification is predetermined, and may be when the server receives a lottery request from the player, or

[0094] FIG. 16 is a flowchart showing the operation of the game system 1 of the fifth embodiment.

[0095] The operation of the game system 1 of the fifth embodiment will be described with reference to the flowchart of FIG.

[0096] For ease of explanation and understanding, it is assumed that the player terminal 3(1) of the player 4(1) and the server device 2 are interacting with each other.

[0097] Step ST41: Similar to steps ST11 and ST12 in embodiment 1, after the server device 2 receives the lottery condition CJ from the player terminal 3(1) of player 4(1), the judgment 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 FIG. 2) sends a notification T of a message ME corresponding to the result of the determination by the determination unit 21C to the player terminal 3(1).

[0099] For example, if the lottery condition CJ of player 4(1) is "10 times / day" and the lottery request CY from player 4(1) requests a "ninth" lottery, the determination unit 21C determines that the remaining lottery request CY can be made. Then, the notification unit 21E sends a message ME to the player terminal 3(1) stating that "the remaining lottery request CY can be made."

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

[0101] Effect of the Fifth Embodiment As described above, in the game system 1 of the fifth embodiment, a notification T is sent to the player 4(1) containing a message ME whose content is determined according to the relationship between the lottery request CY and the number of times the player 4(1) has entered the lottery or the amount of money paid for the lottery. This makes it possible to further encourage the player 4(1) to limit his or her own play of the game GM compared to the game system 1 of the first embodiment.

[0102] Sixth Embodiment A game system 1 according to a sixth embodiment will be described.

[0103] Configuration of Sixth Embodiment The configuration of the game system 1 of the sixth embodiment is similar to the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0104] Operation of the Sixth Embodiment For example, when the game system 1 of embodiment 6 determines 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, if it exceeds the upper limit), it notifies player 4(1) of the restart condition SJ (see Figure 16), which is the condition under which player 4(1) can restart the lottery request CY.

[0105] FIG. 17 shows the restart information SKJ of the sixth embodiment.

[0106] 2 and 16, the restart information SKJ is stored in advance in the storage unit 22 of the server device 2. As shown in FIG. 16, the restart information SKJ indicates a plurality of restart conditions SJ1, SJ2, SJ3, etc. For example, the restart information SKJ indicates restart condition SJ1 "after the date changes," restart condition SJ2 "after six hours have passed," and restart condition SJ3 "after the lottery condition CJ is changed." In other words, the restart information SKJ indicates the timing at which accumulated values ​​related to the lottery (accumulated number of times, accumulated consideration amount, accumulated time, etc.) are reset.

[0107] FIG. 18 is a flowchart showing the operation of the game system 1 of the sixth embodiment.

[0108] The operation of the game system 1 of the sixth embodiment will be described with reference to the flowchart of FIG.

[0109] For ease of explanation and understanding, it is assumed that the player terminal 3(1) of the player 4(1) and the server device 2 are interacting with each other.

[0110] Before step ST51: In the server device 2, the selection condition receiving unit 21A receives an instruction to set the selection condition CJ for player 4(1) from the player terminal 3(1) in the same manner as in steps ST11 and ST12 of the first embodiment.

[0111] Step ST51: In the server device 2, the lottery request receiving unit 21B (see FIG. 2) receives a lottery request CY (see FIG. 1) from the player terminal 3(1), similar to step ST13 in embodiment 1. The determination unit 21C (see FIG. 2) determines whether the lottery request CY satisfies the lottery condition CJ. If it is determined that the lottery request CY does not satisfy the lottery condition CJ, the lottery unit 21F (see FIG. 2) does not respond to the lottery request CY; in other words, it stops the lottery C for the player 4(1) thereafter. Note that if the lottery condition CJ is not satisfied, the lottery request icon may be changed (hide it, or change the color or text) to prevent the lottery request CY from being entered.

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

[0113] For example, if the lottery condition CJ (period KK, see Figure 6) at the time when player 4 (1) started the game GM was "10 times / 12 hours," and player 4 (1) had been playing the game GM for "6 hours" and had already performed 10 lotteries, notification T of the resumption condition SJ2 "after 6 hours have passed" will be made.

[0114] Also, for example, in a situation where the lottery cannot be executed unless the lottery condition CJ is changed, a notification T of the restart condition SJ3 "after the lottery condition CJ is changed" is made.

[0115] Effects of the Sixth Embodiment As described above, in the game system 1 of the sixth embodiment, when the lottery request CY of player 4(1) does not satisfy the lottery condition CJ of player 4(1), the lottery C for player 4(1) is stopped, and notification T of the restart condition SJ is sent to player 4(1). This allows player 4(1) to limit the play of the game GM by himself, and also allows him to understand the restart conditions.

[0116] Seventh Embodiment A game system 1 according to a seventh embodiment will be described.

[0117] <Configuration of Seventh Embodiment> The configuration of the game system 1 of the seventh embodiment is the same as the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0118] Operation of the Seventh Embodiment The game system 1 of the seventh embodiment switches whether or not to execute a judgment HT (see FIG. 7) in response to a lottery request CY from the player 4(1), for example, in response to a request from the player 4(1).

[0119] FIG. 19 is a flowchart showing the operation of the game system 1 of the seventh embodiment.

[0120] The operation of the game system 1 of the seventh embodiment will be described with reference to the flowchart of FIG.

[0121] For ease of explanation and understanding, it is assumed that communication takes place between the player terminal 3(1) of the player 4(1) and the server device 2.

[0122] Before step ST61: As in steps ST11 and ST12 in the first embodiment, the selection conditions CJ (see FIG. 1) of player 4(1) are transmitted from player terminal 3(1) of player 4(1) to server device 2. In other words, server device 2 has already accepted the selection conditions CJ of player 4(1). Note that the selection conditions CJ may not necessarily be accepted.

[0123] Step ST61: The player 4(1) transmits a request from the player terminal 3(1) to the server device 2 to switch whether or not the lottery limit and lottery notification are required. For example, a request is transmitted to switch whether or not a determination HT is required to determine whether or not a lottery request CY to be made in the future by the player 4(1) satisfies the lottery condition CJ already set by the player 4(1), that is, whether or not the determination HT should be executed or stopped. For example, by selecting the restriction switching icon and the notification switching icon in FIG. 4, respectively, the necessity or necessity (on (ON) / off (OFF)) of execution of the current lottery limit function and lottery notification function can be switched. Note that the necessity or necessity (on / off) of execution of both the lottery limit function and the lottery notification function may be switched together, or only one of them may be switched.

[0124] Step ST62: In the server device 2, the switching unit 21K (see FIG. 2) switches between executing the determination HT for determining whether or not a lottery is necessary and for notification, and stopping the determination HT, in response to the request described above. That is, it switches between causing the determination unit 21C (see FIG. 2) to execute the determination HT, and not causing the determination unit 21C to execute the determination HT. Whether or not a determination is necessary is updated in the storage unit every time the switching is performed.

[0125] Step ST63a: In step ST62 described above, if the request from player 4(1) indicates that the judgment HT is unnecessary, i.e., that the judgment HT should be stopped, the judgment unit 21C (see FIG. 2) in the server device 2 will no longer perform the judgment HT to determine whether the lottery request CY from player 4(1) satisfies the lottery request CY preset by player 4(1). In other words, player 4(1) will no longer be restricted from executing the lottery C by the lottery unit 21F (see FIG. 2), or the lottery C will be executed without notification. This allows the player to turn off the lottery restriction and notification functions, allowing the player to use the restriction and notification functions only when necessary, improving convenience. Furthermore, since there is no need to perform processing such as judgment every time a lottery is drawn, the processing load on the server can be reduced.

[0126] Step ST63b: In contrast to the above-described step ST63a, when the request from the player 4(1) in the above-described step ST62 indicates that a judgment HT is necessary, that is, that a judgment HT should be executed, the judgment unit 21C in the server device 2 thereafter executes a judgment HT to determine whether or not the lottery request CY from the player 4(1) satisfies the lottery request CY preset by the player 4(1). In other words, the player 4(1) is able to execute a lottery C by the lottery unit 21F within the scope of the lottery condition CJ.

[0127] Effect of the Seventh Embodiment As described above, in the game system 1 of the seventh embodiment, the server device 2 switches between implementing and not implementing the judgment HT in response to a request from the player 4(1) as to whether or not the judgment HT is necessary, that is, in response to a request as to whether or not the judgment HT should be executed or stopped. This allows the player 4(1) to decide for himself or herself whether or not to restrict play of the game GM, improving convenience. Note that the control unit may prevent the lottery from being executed if the player turns off at least one or both of the restriction and notification functions.

[0128] Eighth Embodiment The game system 1 of the eighth embodiment will be described.

[0129] <Configuration of Eighth Embodiment> The configuration of the game system 1 of the eighth embodiment is the same as the configuration of the game system 1 of the first embodiment (see FIGS. 1 to 3).

[0130] Operation of the Eighth Embodiment In the game system 1 of embodiment 8, for example, a billing history KR (see FIG. 19) which is the history of charges KA (see FIGS. 6 and 12) for the game GM (see FIG. 4) of player 4(1) 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).

[0131] FIG. 20 shows the billing history KR of the eighth embodiment.

[0132] The charge history KR is stored in the storage unit 22 of the server device 2 as shown in FIGS. 2 and 20. As shown in FIG. 20, the charge history KR indicates the charge KA for lottery C, the purchase of game media GB, and the total amount. More specifically, the charge history KR indicates that, for example, player 4(1) spent 1,000 yen on the charge KA for lottery C on the 1st (Thursday) and 500 yen on the purchase of game media GB, for a total of 1,500 yen (= 1,000 yen + 500 yen). Such a charge history is stored (updated) in the storage unit each time a charge is made. Note that the charge history KR may also provide more detailed information about the object and amount of the charge. For example, if there are multiple types of paid in-game currency (such as paid stones) or game media (such as characters or items), the charge amount may be displayed for each in-game currency and game media. Furthermore, the information is not limited to being presented by day, but may be presented by time period, week, or month.

[0133] FIG. 21 is a flowchart showing the operation of the game system 1 of the eighth embodiment.

[0134] The operation of the game system 1 of the eighth embodiment will be described with reference to the flowchart of FIG.

[0135] For ease of explanation and understanding, it is assumed that communication takes place between the player terminal 3(1) of the player 4(1) and the server device 2.

[0136] Step ST71: After going through steps ST11 and ST12 of the first embodiment and making a lottery request CY at least once in step ST13, the player 4(1) requests the server device 2 from the player terminal 3(1) to notify the player 4(1) of the billing history KR. For example, an icon requesting the billing history may be displayed on the screen of FIG. 4, and the player may select the icon to request the server to display the billing history.

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

[0138] Effect of the Eighth Embodiment As described above, the game system 1 of the eighth embodiment stores, for example, the billing history KR of player 4(1) within the game GM, and notifies player 4(1) of the billing history KR of player 4(1) based on a request from player 4(1). This allows player 4(1) to restrict his or her own play in the game GM more reliably than in the first embodiment by referencing player 4(1)'s own billing history KR.

[0139] Ninth Embodiment The game system 1 of the ninth embodiment will be described.

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

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

[0142] FIG. 22 shows the difference information JYSJ of the ninth embodiment.

[0143] 2 and 22, the difference information JYSJ is stored in the storage unit 22 of the server device 2. As shown in Fig. 22, the difference information JYSJ indicates, for example, a lottery condition CJ preset by the player 4(1), the number of lottery requests CY KS made by the player 4(1), a difference JYS which is the difference between the lottery condition CJ and the lottery request CY, and a difference (accumulation) JYS(R) which is the accumulation of the difference JYS.

[0144] More specifically, the difference information JYSJ indicates that, for example, the lottery condition CJ for player 4(1) is 10 times / day, and on the 1st (Thursday) player 4(1) made 7 lottery requests CY, the difference JYS is -3 times (= 7 times - 10 times), and the difference (cumulative) JYS(R) is -3 times.

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

[0146] FIG. 23 is a flowchart showing the operation of the game system 1 of the ninth embodiment.

[0147] The operation of the game system 1 of the ninth embodiment will be described with reference to the flowchart of FIG.

[0148] For ease of explanation and understanding, it is assumed that communication takes place between the player terminal 3(1) of the player 4(1) and the server device 2.

[0149] Step ST81: In steps ST11 and ST12 of embodiment 1, player 4(1) sets lottery conditions CJ, and in ST13, player 4(1) sends a lottery request CY to server device 2 at least once. After this, player 4(1) requests server device 2 to notify player 4(1) of difference information JYSJ.

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

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

[0152] Effect of the 9th embodiment As described above, in the game system 1 of the ninth embodiment, the calculation unit 21L calculates the difference JYS, which is the difference between the lottery condition CJ of the player 4(1) and the history of lottery request CY requests actually made by the player 4(1), and the difference information JYSJ indicating the condition / requirement difference (accumulated) JYS(R), and the notification unit 21E notifies the player 4(1) of the difference information JYSJ in response to a request from the player 4(1). By referring to the difference information JYSJ, and in particular the difference (accumulated) JYS(R), the player 4(1) can check whether or not too many lottery requests CY have been made, which further encourages the player 4(1) to limit his or her own play of the game GM compared to the first embodiment.

[0153] <Hardware configuration of the embodiment> The server device 2 and player terminal 3 of the first to ninth embodiments include a processing circuit SYO to perform the above-described functions, and may further include an input circuit NYU and an output circuit SYU as necessary. The processing circuit SYO is dedicated hardware. The processing circuit SYO mainly realizes the functions of the control unit 21 of the server device 2 (see FIG. 2) and the control unit 31 of the player terminal 3 (see FIG. 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 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.

[0154] <Hardware configuration based on software implementation of the embodiment> The server device 2 and player terminal 3 of the first to ninth embodiments include a processor PRO and a memory circuit KIO, and may further include an input circuit NYU and an output circuit SYU as necessary. The processor PRO is a CPU (also called a central processing unit, processing device, arithmetic unit, microprocessor, microcomputer, or DSP (Digital Signal Processing)) that executes a program. The processor PRO mainly implements the functions of the control unit 21 of the server device 2 (see FIG. 2) and the control unit 31 of the player terminal 3 (see FIG. 3). The processor PRO implements the above-mentioned functions using 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-mentioned functions by reading and executing the program PRG from the memory circuit KIO. The program PRG can be said to mainly cause a 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, a 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 a magnetic disk, flexible disk, optical disk, compact disk, mini disk, DVD (Digital Versatile Disc), etc.

[0155] Of the functions of the control unit 21 of the server device 2 and the control unit 31 of the player terminal 3, some of the functions may be realized by the processing circuit SYO, while other functions may be realized 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 mainly by hardware, software, firmware, or a combination of these. The input circuit NYU and the 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 above-described embodiment, and various modifications are possible without departing from the spirit of the invention.

[0158] In the above example, a number of times pre-associated with a lottery event may be set as the lottery count condition. For example, in the case of a lottery event set so that a game medium of a specific rarity or a specific game medium is won when the same type of gacha is executed a predetermined number of times (e.g., 10, 50, 100, etc.) within a predetermined period, such as a so-called "ceiling gacha," the ceiling number of times may be set as the upper limit of the lottery event. By setting a predetermined number of times for each lottery event as the number of times of the lottery condition, it is possible to allow lotteries until the objective of the lottery event is achieved, or to notify the player when the ceiling number of times is reached. As a result, the entertainment value of the game can be increased. In this case, a specific number of times (count condition information such as the ceiling number of times) is pre-associated with each type of lottery and stored in the storage unit. Note that conditions such as a predetermined benefit or the like can be associated with the number of times and the lottery event, without being limited to the ceiling number of times, such as granting a predetermined benefit to the player when the predetermined number of times is executed. The control unit of the server device may present the pre-associated count information on an introduction screen for the lottery event, a condition setting screen, or the like. In this way, by presenting the number of times information associated with the lottery event to the player terminal, the player can refer to the number of times information associated with the lottery event when setting the lottery conditions.

[0159] The control unit of the server device may also execute a notification suggesting the use of the restricted function to a player who meets predetermined proposal conditions. The proposal conditions are stored in advance in the storage unit. The proposal conditions may be, for example, the number of lottery draws executed in a predetermined period exceeding a specific value (threshold) or the cumulative value of the consumption fee in a predetermined period exceeding a specific value (threshold). The specific value (threshold) may be an upper limit value input or selected by the player, or a value calculated based on the upper limit value. The value calculated based on the upper limit value is, for example, a value calculated based on a pre-stored calculation formula. Specifically, if the upper limit value is 10 times, the value may be calculated by multiplying it by a predetermined numerical value (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 whether these conditions are met based on each player's play history and issue a notification if they are met. This may suggest the use of the restricted function to a player who, for example, draws more than 100 lotteries in a day or spends more than 100,000 yen. It is preferable that this suggestion be made to a player for whom either or both of the limiting function and the notification function are turned off, so that a player who plays the lottery excessively can be prompted to limit the lottery or to turn on notifications.

[0160] <Example of composition> A game system 1 etc. according to the present disclosure has, for example, the following configuration.

[0161] [Item 1] a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one game medium from a plurality of game media that can be used in the game; a lottery condition receiving unit that receives a lottery condition setting instruction from a player, the lottery condition being a condition related to the lottery; a determination unit that, when receiving the lottery request, determines whether the lottery request satisfies the lottery condition; An information processing system including: [Item 2] 2. The information processing system according to claim 1, further comprising a determination unit that determines whether or not a notification regarding the lottery is required or whether or not the lottery should be held based on a result of the determination. [Item 3] The information processing system according to claim 1, further comprising a bonus awarding unit that determines a bonus to be awarded to the player based on a comparison result between the lottery conditions and the player's actual lottery results at a predetermined time. [Item 4] 2. The information processing system according to claim 1, wherein the lottery conditions include an upper limit on the number of times the lottery is to be held within a predetermined period. [Item 5] 2. The information processing system according to claim 1, wherein the lottery conditions include an upper limit of a cumulative amount of a consideration consumed when the lottery is held in a predetermined period. [Item 6] 2. The information processing system according to claim 1, wherein the condition specification receiving unit receives a period specification from the player as the instruction to set the lottery conditions. [Item 7] The information processing system according to claim 1, further comprising a suggestion unit that suggests recommended conditions related to the lottery conditions to a player who satisfies a predetermined suggestion condition. [Item 8] 2. The information processing system according to claim 1, further comprising a notification unit that issues a predetermined notification to a player when the number of times the lottery has been held or the cumulative value of the compensation within a predetermined period reaches a specific value based on the lottery conditions. [Item 9] The information processing system of claim 1, further comprising a notification unit that notifies the player of conditions under which the player can resume the lottery when the determination unit determines that the lottery request does not satisfy the lottery conditions. [Item 10] 2. The information processing system according to claim 1, further comprising a switching unit that switches whether or not to execute the determination based on a request from the player. [Item 11] a storage unit that stores the player's in-game billing history; 2. The information processing system according to claim 1, further comprising: a notification unit that outputs information relating to the billing history of the player based on a request from the player. [Item 12] a calculation unit that calculates difference information indicating a difference between the lottery conditions and the history of lottery actually performed by the player; a notification unit that outputs the difference information based on a request from the player. 2. The information processing system according to claim 1. [Item 13] a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one game medium from a plurality of game media that can be used in the game; a lottery condition receiving unit that receives a lottery condition setting instruction from a player, the lottery condition being a condition related to the lottery; a determination unit that, when receiving the lottery request, determines whether the lottery request satisfies the lottery condition; Contains Server containing. [Item 14] a lottery request receiving step of receiving from a player a lottery request for a lottery to select one game medium from a plurality of game media available in the game; a lottery condition receiving step of receiving, from a player, an instruction to set lottery conditions, which are conditions related to the lottery; a determination step of determining, when the lottery request is received, whether or not the lottery request satisfies the lottery condition; An information processing method including: [Item 15] On the computer, a lottery request receiving step of receiving from a player a lottery request for a lottery to select one game medium from a plurality of game media available in the game; a lottery condition receiving step of receiving, from a player, an instruction to set lottery conditions, which are conditions related to the lottery; a determination step of determining, when the lottery request is received, whether or not the lottery request satisfies the lottery condition; A program to execute.

Claims

1. a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one game medium from a plurality of game media that can be used in the game; a lottery condition receiving unit that receives a lottery condition setting instruction from a player, the lottery condition being a condition related to the lottery; a determination unit that, when receiving the lottery request, determines whether the lottery request satisfies the lottery condition; An information processing system including:

2. The information processing system according to claim 1 , further comprising a determination unit that determines whether or not a notification regarding the lottery is required or whether or not the lottery should be held based on the result of the determination.

3. 2. The information processing system according to claim 1, further comprising a bonus awarding unit that determines a bonus to be awarded to the player based on a comparison result between the lottery conditions and the player's actual lottery results at a predetermined time.

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 to be held within a predetermined period.

5. The information processing system according to claim 1 , wherein the lottery conditions include an upper limit of a cumulative amount of a consideration consumed when the lottery is held in a predetermined period.

6. The information processing system according to claim 1 , wherein the condition specification receiving unit receives a period specification from the player as the instruction to set the lottery conditions.

7. The information processing system according to claim 1 , further comprising a proposal unit that proposes recommended conditions related to the lottery conditions to a player who satisfies a predetermined proposal condition.

8. 2. The information processing system according to claim 1, further comprising a notification unit that issues a predetermined notification to a player when the number of times the lottery has been executed or the cumulative value of the compensation within a predetermined period reaches a specific value based on the lottery conditions.

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

10. The information processing system according to claim 1 , further comprising a switching unit that switches whether or not to execute said determination based on a request from said player.

11. a storage unit that stores the player's in-game billing history; 2. The information processing system according to claim 1, further comprising: a notification unit that outputs information relating to the player's billing history based on a request from the player.

12. a calculation unit that calculates difference information indicating a difference between the lottery conditions and the history of lottery actually performed by the player; a notification unit that outputs the difference information based on a request from the player. The information processing system according to claim 1 .

13. a lottery request receiving unit that receives a lottery request from a player requesting a lottery to select one game medium from a plurality of game media that can be used in the game; a lottery condition receiving unit that receives a lottery condition setting instruction from a player, the lottery condition being a condition related to the lottery; a determination unit that, when receiving the lottery request, determines whether the lottery request satisfies the lottery condition; Contains Server containing.

14. a lottery request receiving step of receiving from a player a lottery request for a lottery to select one game medium from a plurality of game media available in the game; a lottery condition receiving step of receiving, from a player, an instruction to set lottery conditions, which are conditions related to the lottery; a determination step of determining, when the lottery request is received, whether or not the lottery request satisfies the lottery condition; An information processing method including:

15. On the computer, a lottery request receiving step of receiving from a player a lottery request for a lottery to select one game medium from a plurality of game media available in the game; a lottery condition receiving step of receiving, from a player, an instruction to set lottery conditions, which are conditions related to the lottery; a determination step of determining, when the lottery request is received, whether or not the lottery request satisfies the lottery condition; A program to execute.

Images