JP7724759B2 - program, information processing device - Google Patents

Description

This disclosure relates to a program and an information processing device.

In order to improve the rate of continued use of provided content, services, etc., it has been known to provide users with a login bonus as a login benefit when providing game content, in order to encourage them to log in (use the content). For example, there are known systems that provide a benefit based on the user's login frequency (e.g., Patent Document 1), and systems that provide a benefit based on the number of days a user logs in consecutively (e.g., Non-Patent Document 1).

Japanese Patent Application Laid-Open No. 2018-020143

“[Pokodan] Log in every day! Introducing the login bonus [Pokoron Dungeons]”, [online], [searched July 22, 2022], Internet <https://gamewith.jp/pocodun/article/show/163007>

However, in conventional systems, the benefits granted when a user uses the service (for example, logging in) and then uses it again at a different time (for example, logging in the next day) are determined uniformly for each user. For example, the benefits granted are determined uniformly depending on the user's frequency of use, the number of days of use, etc.

This disclosure provides a program that can effectively encourage repeat use by making it possible to change the sense of expectation and specialness regarding the benefits that can be obtained by repeat use.

The program disclosed herein causes a computer to function as a means for granting a perk associated with the timing of the start of use to a user when the user initiates use, and as a means for notifying the user, before the specified period has elapsed, of information that identifies the possibility that a perk different from the perk associated with the timing of the resumption of use may be granted when the user initiates use again within a specified period of time after the perk was granted upon the start of use.

One aspect of the present disclosure makes the method of determining and awarding rewards more interesting than conventional methods.

FIG. 2 is a diagram illustrating a hardware configuration of the game system. FIG. 2 is a block diagram showing the functional configuration of a user terminal and a server. 10A and 10B show examples of a login bonus screen, where (A) shows an example before the login bonus is awarded, (B) shows an example after today's login bonus has been awarded, and (C) shows an example after the login bonus for the next day has been determined. 10A and 10B are diagrams showing an example of a login bonus screen for the quantity lottery process, where (A) is an example of a lottery screen, and (B) is an example of a screen showing the lottery results. FIG. 10 is a diagram showing an example of a quantity lottery table. 10 is a flowchart illustrating an example of a number lottery process. 10A and 10B show examples of a login bonus screen, where (A) shows an example before the login bonus is awarded, (B) shows an example after today's login bonus has been awarded, and (C) shows an example after the login bonus for the next day has been determined. 10A and 10B are diagrams showing an example of a login bonus screen for the type lottery process, where (A) is a diagram showing an example of a lottery screen, and (B) is a diagram showing an example of the lottery results. FIG. 10 is a diagram showing an example of a type lottery table. 10 is a flowchart illustrating an example of a type lottery process. FIG. 10 is a diagram showing an example of a lottery table. 10 is a flowchart illustrating an example of a lottery table determination process for a consecutive login bonus. 10A and 10B are diagrams showing an example of a login bonus screen, where (A) is a diagram showing an example of a lottery screen for the next day's lottery table, and (B) is a diagram showing an example of a lottery screen for consecutive logins. 10 is a flowchart illustrating an example of a lottery process for determining a consecutive login bonus. FIG. 10 is a diagram showing an example of a login bonus screen. FIG. 10 is a diagram showing an example of a rank lottery table.

As an example of a system according to the present disclosure, a game system for providing a game to multiple users is shown. In this embodiment, the game system awards a so-called login bonus (benefit) when a user logs in to the game and begins using the game in response to a user's operation. Furthermore, in this embodiment, the game system awards a benefit associated with the timing of the user's login (start of use). However, if the user logs in (starts use) again a predetermined period of time (e.g., the next day) after the benefit was awarded, a different benefit may be awarded. Below, a game system is described with reference to the drawings as an example of a system according to the present disclosure. Note that the present invention is not limited to these examples, and is intended to include all modifications within the meaning and scope equivalent to the claims. In the following description, identical elements in the drawings will be designated by the same reference numerals, and redundant explanations will not be repeated.

<Hardware Configuration of Game System 1>
FIG. 1 is a diagram showing the hardware configuration of a game system 1. As shown in FIG. 1, the game system 1 includes a plurality of user terminals 100 and a server 200. Each user terminal 100 is connected to the server 200 via a network 2. The network 2 is made up of the Internet and various mobile communication systems constructed using wireless base stations (not shown). Examples of such mobile communication systems include so-called 3G and 4G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi (registered trademark)) that can connect to the Internet via a predetermined access point.

Server 200 (computer, information processing device) may be a general-purpose computer such as a workstation or a personal computer. Server 200 comprises a processor 20, memory 21, storage 22, a communication IF 23, and an input/output IF 24. These components of server 200 are electrically connected to each other by a communication bus.

The user terminal 100 (computer, information processing device) may be a mobile terminal such as a smartphone, feature phone, PDA (Personal Digital Assistant), or tablet computer. The user terminal 100 may also be a device installed in a store or the like and operated by a user or in response to a user's request. The user terminal 100 may also be a gaming device suitable for game play. As shown in the figure, the user terminal 100 comprises a processor 10, memory 11, storage 12, a communication interface (IF) 13, an input/output IF 14, a touch screen 15 (display unit and input unit), a camera 17, and a distance sensor 18. These components of the user terminal 100 are electrically connected to each other via a communication bus.

The user terminal 100 may not have a touch screen 15, and the input/output IF 14 may include an input unit that is an information input device such as a mouse or keyboard, and a display unit that is a device that displays and outputs images.

Furthermore, as shown in FIG. 1, the user terminal 100 may be configured to be able to communicate with one or more controllers 1020. The controller 1020 establishes communication with the user terminal 100 in accordance with a communication standard such as Bluetooth (registered trademark). The controller 1020 may have one or more buttons, etc., and transmits output values based on user input operations on the buttons, etc., to the user terminal 100. The controller 1020 may also have various sensors, such as an acceleration sensor and an angular velocity sensor, and transmits output values from the various sensors to the user terminal 100.

In addition to or instead of the user terminal 100 being equipped with a camera 17 and a distance measurement sensor 18, the controller 1020 may also have the camera 17 and the distance measurement sensor 18.

For example, when starting a game, the user terminal 100 preferably prompts the user using the controller 1020 to input user identification information, such as the user's name or login ID, via the controller 1020. This enables the user terminal 100 to link the controller 1020 with the user, and can identify which user the output value belongs to based on the sender (controller 1020) of the received output value.

For example, when a user terminal 100 communicates with multiple controllers 1020, each user can hold a controller 1020, allowing multiplayer play to be achieved on that single user terminal 100 without communicating with other devices such as the server 200 via the network 2. Alternatively, multiple user terminals 100 can communicate with each other using a wireless standard such as a wireless local area network (LAN) standard (connecting to communicate without going through the server 200) to achieve local multiplayer play. When a single user terminal 100 achieves the above-described local multiplayer play, the user terminal 100 may further include at least some of the various functions provided by the server 200, which will be described later. When multiple user terminals 100 achieve the above-described local multiplayer play, the multiple user terminals 100 may include the various functions provided by the server 200, which will be described later, in a distributed manner.

Even when the above-mentioned multiplayer mode is implemented locally, the user terminal 100 may communicate with the server 200. For example, information indicating the results of a game, such as the score or win/loss, may be associated with user identification information and transmitted to the server 200.

The controller 1020 may also be configured to be detachable from the user terminal 100. In this case, a connection section for the controller 1020 may be provided on at least one surface of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are connected via a wired connection via the connection section, the user terminal 100 and the controller 1020 send and receive signals via the wired connection.

As shown in FIG. 1, the user terminal 100 may accept the insertion of a storage medium 1030, such as an external memory card, via the input/output IF 14. This allows the user terminal 100 to read programs and data recorded on the storage medium 1030. The program recorded on the storage medium 1030 may be, for example, a game program.

The user terminal 100 may store in the memory 11 of the user terminal 100 a program acquired by communicating with an external device such as the server 200, or may store in the memory 11 a program acquired by reading it from the storage medium 1030.

As explained above, the user terminal 100 includes a communication IF 13, an input/output IF 14, a touch screen 15, a camera 17, and a distance sensor 18 as examples of mechanisms for inputting information to the user terminal 100. Each of the above-mentioned components as input mechanisms can be considered an operation unit configured to accept input operations from the user.

For example, if the operation unit is composed of at least one of the camera 17 and the distance sensor 18, the operation unit detects an object 1010 near the user terminal 100 and identifies an input operation from the detection result of the object. As an example, the object 1010 may be a user's hand or a marker of a predetermined shape, and the input operation is identified based on the color, shape, movement, or type of the object 1010 obtained as the detection result. More specifically, when the user's hand is detected in an image captured by the camera 17, the user terminal 100 identifies and accepts the gesture (a series of movements of the user's hand) detected based on the captured image as the user's input operation. Note that the captured image may be a still image or a video.

Alternatively, if the operation unit is configured with a touch screen 15, the user terminal 100 identifies and accepts user operations performed on the input unit 151 of the touch screen 15 as user input operations. Alternatively, if the operation unit is configured with a communication IF 13, the user terminal 100 identifies and accepts a signal (e.g., an output value) transmitted from the controller 1020 as user input operations. Alternatively, if the operation unit is configured with an input/output IF 14, the user terminal 100 identifies and accepts a signal output from an input device (not shown) connected to the input/output IF 14 that is different from the controller 1020 as user input operations.

<Hardware components of each device>
The processor 10 controls the overall operation of the user terminal 100. The processor 20 controls the overall operation of the server 200. The processors 10 and 20 each include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and a GPU (Graphics Processing Unit).

Processor 10 reads the program from storage 12, which will be described later, and expands it in memory 11, which will be described later. Processor 20 reads the program from storage 22, which will be described later, and expands it in memory 21, which will be described later. Processor 10 and processor 20 execute the expanded programs.

Memories 11 and 21 are main storage devices. Memories 11 and 21 are composed of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). Memory 11 provides a working area for processor 10 by temporarily storing programs and various data that processor 10 reads from storage 12, which will be described later. Memory 11 also temporarily stores various data generated while processor 10 is operating according to a program. Memory 21 provides a working area for processor 20 by temporarily storing various programs and data that processor 20 reads from storage 22, which will be described later. Memory 21 also temporarily stores various data generated while processor 20 is operating according to a program.

In this embodiment, the program may be a game program for realizing a game by the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation between the user terminal 100 and the server 200. Note that, as an example, a game realized through cooperation between the user terminal 100 and the server 200 may be a game executed on a browser launched on the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation between multiple user terminals 100. Furthermore, the various data include data related to the game, such as user information and game information, as well as instructions or notifications sent and received between the user terminal 100 and the server 200 or between multiple user terminals 100.

Storages 12 and 22 are auxiliary storage devices. Storages 12 and 22 are composed of storage devices such as flash memory or HDDs (Hard Disk Drives). Storage 12 and storage 22 store various data related to the game.

Communication IF 13 controls the sending and receiving of various data in the user terminal 100. Communication IF 23 controls the sending and receiving of various data in the server 200. Communication IFs 13 and 23 control, for example, communication via a wireless LAN (Local Area Network), internet communication via a wired LAN, wireless LAN, or mobile phone network, and communication using short-range wireless communication, etc.

The input/output IF 14 is an interface through which the user terminal 100 accepts data input and outputs data. The input/output IF 14 may input and output data via a USB (Universal Serial Bus) or the like. The input/output IF 14 may include, for example, physical buttons, a camera, a microphone, or a speaker of the user terminal 100. The input/output IF 24 of the server 200 is an interface through which the server 200 accepts data input and outputs data. The input/output IF 24 may include, for example, an input unit which is an information input device such as a mouse or keyboard, and a display unit which is a device that displays and outputs images.

The touch screen 15 of the user terminal 100 is an electronic component that combines an input unit 151 and a display unit 152. The input unit 151 is, for example, a touch-sensitive device, and is composed of, for example, a touchpad. The display unit 152 is, for example, composed of a liquid crystal display or an organic EL (Electro-Luminescence) display.

The input unit 151 has the function of detecting the position at which a user operation (mainly a physical contact operation such as a touch operation, a slide operation, a swipe operation, or a tap operation) is input on the input surface, and transmitting information indicating the position as an input signal. The input unit 151 is only required to include a touch sensing unit (not shown). The touch sensing unit may be of any type, such as a capacitive type or a resistive type.

Although not shown, the user terminal 100 may be equipped with one or more sensors for identifying the holding orientation of the user terminal 100. This sensor may be, for example, an acceleration sensor or an angular velocity sensor. If the user terminal 100 is equipped with a sensor, the processor 10 may identify the holding orientation of the user terminal 100 from the output of the sensor and perform processing according to the holding orientation. For example, when the user terminal 100 is held in portrait orientation, the processor 10 may select portrait screen display, in which a portrait-oriented image is displayed on the display unit 152. On the other hand, when the user terminal 100 is held in landscape orientation, the processor 10 may select landscape screen display, in which a landscape-oriented image is displayed on the display unit. In this way, the processor 10 may be able to switch between portrait screen display and landscape screen display depending on the holding orientation of the user terminal 100.

The camera 17 includes an image sensor and generates a captured image by converting incident light from the lens into an electrical signal.

The distance measurement sensor 18 is a sensor that measures the distance to the measurement object. The distance measurement sensor 18 includes, for example, a light source that emits pulse-converted light and a light-receiving element that receives the light. The distance measurement sensor 18 measures the distance to the measurement object based on the timing of light emission from the light source and the timing of reception of reflected light that is generated when the light emitted from the light source hits the measurement object and is reflected. The distance measurement sensor 18 may also include a light source that emits directional light.

Here, we will further explain an example in which the user terminal 100 uses the camera 17 and distance measurement sensor 18 to detect an object 1010 near the user terminal 100, and receives the detection result as a user input operation. The camera 17 and distance measurement sensor 18 may be provided, for example, on the side of the housing of the user terminal 100. The distance measurement sensor 18 may be provided near the camera 17. For example, an infrared camera may be used as the camera 17. In this case, the camera 17 may be provided with a lighting device that irradiates infrared light and a filter that blocks visible light. This can further improve the accuracy of object detection based on images captured by the camera 17, regardless of whether the location is indoors or outdoors.

The processor 10 may perform one or more of the following processes (1) to (5) on the image captured by the camera 17. (1) The processor 10 performs image recognition processing on the image captured by the camera 17 to determine whether the captured image includes a user's hand. The processor 10 may use, for example, pattern matching as the analysis technology employed in the image recognition processing. (2) The processor 10 also detects a user gesture from the shape of the user's hand. For example, the processor 10 determines the number of fingers (number of outstretched fingers) of the user from the shape of the user's hand detected in the captured image. The processor 10 further determines the gesture performed by the user from the determined number of fingers. For example, if the number of fingers is five, the processor 10 determines that the user has performed a "paper" gesture. If the number of fingers is zero (no fingers detected), the processor 10 determines that the user has performed a "rock" gesture. Furthermore, if the number of fingers is two, the processor 10 determines that the user has made a "scissors" gesture. (3) The processor 10 performs image recognition processing on the image captured by the camera 17 to detect whether the user's fingers are in a state where only the index finger is extended or whether the user's fingers are flicking. (4) The processor 10 detects the distance between the user terminal 100 and an object 1010 (such as the user's hand) near the user terminal 100 based on at least one of the image recognition results of the image captured by the camera 17 and the output value of the distance measurement sensor 18. For example, the processor 10 detects whether the user's hand is near the user terminal 100 (e.g., a distance less than a predetermined value) or far away (e.g., a distance equal to or greater than a predetermined value) based on the size of the shape of the user's hand identified from the image captured by the camera 17. Note that if the captured image is a video, the processor 10 may detect whether the user's hand is approaching or moving away from the user terminal 100. (5) If it is determined that the distance between the user terminal 100 and the user's hand is changing while the user's hand is detected based on the image recognition results of the image captured by the camera 17, the processor 10 recognizes that the user is waving their hand in the direction of the camera 17. If the distance measurement sensor 18, which has a stronger directionality than the camera 17's imaging range, detects and does not detect an object, the processor 10 recognizes that the user is waving their hand in a direction perpendicular to the camera's imaging direction.

In this way, the processor 10 detects whether the user has clenched their hand (whether it is a "rock" gesture or another gesture (e.g., "paper")) by performing image recognition on the image captured by the camera 17. The processor 10 also detects the shape of the user's hand and how the user is moving their hand. The processor 10 also detects whether the user is moving their hand closer to or farther away from the user terminal 100. Such operations can correspond to operations using a pointing device such as a mouse or touch panel. For example, the user terminal 100 moves the pointer on the touch screen 15 in response to the movement of the user's hand and detects the user's "rock" gesture. In this case, the user terminal 100 recognizes that the user is continuing a selection operation. Continuing a selection operation corresponds, for example, to the mouse being clicked and maintained in a pressed state, or to a touch panel being touched and maintained in a touched state after a touchdown operation. Furthermore, if the user moves their hand further while the user terminal 100 has detected the "rock" gesture, the user terminal 100 can recognize this series of gestures as an operation corresponding to a swipe operation (or a drag operation). Furthermore, if the user terminal 100 detects a gesture of the user snapping their fingers based on the detection results of the user's hand in an image captured by the camera 17, the user terminal 100 may recognize this gesture as an operation corresponding to a mouse click or a tap operation on a touch panel.

<Functional Configuration of Game System 1>
2 is a block diagram showing the functional configuration of the server 200 and the user terminal 100 included in the game system 1. Each of the server 200 and the user terminal 100 may include a functional configuration (not shown) required to function as a general computer, and a functional configuration required to realize well-known functions in the game.

The user terminal 100 functions as an input device that accepts user input operations, and as an output device that outputs game images and sounds. The user terminal 100 functions as a control unit 110 and a memory unit 120 through cooperation of the processor 10, memory 11, storage 12, communication IF 13, and input/output IF 14.

The server 200 has the function of communicating with each user terminal 100 and assisting the user terminal 100 in progressing through the game. For example, it sells valuable data and provides services. If the game is a multiplayer game, the server 200 may have the function of communicating with each user terminal 100 participating in the game and mediating interactions between the user terminals 100. The server 200 functions as a control unit 210 and a memory unit 220 through cooperation of the processor 20, memory 21, storage 22, communication IF 23, input/output IF 24, etc.

The memory unit 120 and the memory unit 220 store a game program 131, game information 132, and user information 133. The game program 131 is a game program executed by the user terminal 100 and the server 200. The game information 132 is data referenced by the control unit 110 and the control unit 210 when executing the game program 131. The user information 133 is data related to the user's account. In the memory unit 220, the game information 132 and the user information 133 are stored for each user terminal 100.

(Functional configuration of server 200)
The control unit 210 executes the game program 131 stored in the storage unit 220 to exercise overall control over the server 200. For example, the control unit 210 transmits various data, programs, and the like to the user terminal 100. The control unit 210 receives some or all of the game information or user information from the user terminal 100 and stores it in the storage unit 220. Furthermore, in response to a request from the user terminal 100, the control unit 210 transmits the game information or user information of the user stored in the storage unit 220. If the game is a multiplayer game, the control unit 210 may receive a request for multiplayer synchronization from the user terminal 100 and transmit data for synchronization to the user terminal 100.

The control unit 210 functions as a lottery execution unit 211 in accordance with the description of the game program 131. Depending on the nature of the game being played, the control unit 210 can also function as other functional blocks (not shown) to support the progress of the game on the user terminal 100.

In response to a request from the user terminal 100, the lottery execution unit 211 executes a lottery to determine various benefits available in the game. The lottery execution unit 211 reflects the lottery results in the user information 133 of the requesting user stored in the memory unit 220, and also transmits the results to the requesting user terminal 100.

In response to a request from the user terminal 100, the quest management unit 212 obtains data indicating a list of ongoing quests, i.e., quests that the user can play, and sends this data to the user terminal 100. The quest management unit 212 also performs other processes related to the management of each quest.

In response to a request from the user terminal 100, the login bonus screen management unit 213 acquires data related to the login bonus screen, such as a screen for awarding login bonuses, a login bonus list confirmation screen (in calendar format, stamp rally format, etc.), a login bonus lottery screen, or information indicating upcoming events related to login bonuses, or information indicating an event calendar or the like incorporating these, and transmits this data to the user terminal 100.

(Functional configuration of user terminal 100)
The control unit 110 executes the game program 131 stored in the storage unit 120 to exercise overall control over the user terminal 100. For example, the control unit 110 progresses the game in accordance with the game program 131 and user operations. Furthermore, while the game is progressing, the control unit 110 communicates with the server 200 as necessary to send and receive information.

Game information 132 includes various data referenced by game program 131. Game information 132 includes, for example, information about objects placed in the virtual space in the game, information about effects associated with the objects (for example, information about skills set for game characters), etc. User information 133 includes information about the users playing the game. User information 133 includes, for example, information about each user's login bonus (referred to as a login bonus table), information identifying the user of the user terminal 100 playing the game (including login information such as a user ID), information identifying other users playing the game cooperatively during multiplayer, and other information.

Data required to play a quest, such as data indicating the components of the quest, may be stored for each quest in the storage unit 220 of the server 200, or in the storage unit 120 of the user terminal. However, in this embodiment, at least a portion of the data required for the quest to be played is stored in the storage unit 220 of the server 200.

The control unit 110 functions as an operation reception unit 111, a display control unit 112, a user interface (hereinafter referred to as UI) control unit 113, an animation generation unit 114, a lottery unit 115, a determination unit 116, a benefit management unit 117, and a game progression unit 118, in accordance with the description of the game program 131. The control unit 110 can also function as other functional blocks (not shown) in order to progress the game, depending on the nature of the game being executed.

The operation reception unit 111 detects and accepts user input operations on the input unit 151. The operation reception unit 111 determines what input operation has been performed based on the user's actions on the touch screen 15 and the console via other input/output IF 14, and outputs the results to each element of the control unit 110.

For example, the operation reception unit 111 receives an input operation on the input unit 151, detects the coordinates of the input position of the input operation, and identifies the type of input operation. The operation reception unit 111 identifies the type of input operation as, for example, a touch operation, a slide operation, a swipe operation, or a tap operation. Furthermore, when a continuously detected input is interrupted, the operation reception unit 111 detects that the touch input from the touch screen 15 has been released.

The UI control unit 113 controls UI objects displayed on the display unit 152 to construct a UI. UI objects are tools that allow the user to input necessary information to the user terminal 100 as the game progresses, or to obtain information from the user terminal 100 that is output during the game. UI objects include, but are not limited to, icons, buttons, lists, menu screens, etc.

The animation generation unit 114 generates animations showing the motion of various objects based on the control modes of the various objects. For example, it may generate animations that show how a lottery is being drawn.

The display control unit 112 outputs a game screen that reflects the results of the processing performed by each of the above-mentioned elements to the display unit 152 of the touch screen 15. The display control unit 112 may display a game screen that includes animation generated by the animation generation unit 114 on the display unit 152. The display control unit 112 may also draw the above-mentioned UI objects superimposed on the game screen.

Hereinafter, the operation reception unit 111 detecting and receiving an input operation to the input unit 151 will also be referred to simply as "the input operation being received." Furthermore, the output of various game screens by other functional blocks to the display unit 152 via the display control unit 112 will also be referred to simply as "displaying."

The lottery unit 115 requests the server 200 to hold a lottery to determine various benefits available in the game. The lottery unit 115 also obtains the lottery results from the server 200. For example, the lottery unit 115 requests the server to hold a lottery when certain conditions are met after logging in. The lottery unit 115 may also request the server to hold a lottery in exchange for a lottery ticket held by the user, virtual currency, etc.

The determination unit 116 executes various determination processes necessary for the game to progress. For example, the determination unit 116 determines whether the login bonus for the day the user logged in has already been awarded to the user.

The reward management unit 117 manages rewards available to or owned by the user among multiple types of rewards available for use in the game. These rewards include various objects, such as characters, weapons, materials, and other items and accessories that can be equipped by the character, as well as skills that the character can use. The rewards also include, for example, objects that can be consumed or exchanged to acquire specific items, objects that can be consumed to enter lottery processes, and objects that can be used as virtual currency (e.g., coins, jewels, etc.). Examples of rewards include lottery tickets that can be exchanged for a specific number to enter lotteries. The rewards managed by the reward management unit 117 also include the right to increase the chances of winning the game or the right to challenge special quests (rare quests, high-value quests, etc.). Examples of rewards that increase the chances of winning the game include, for example, increasing the likelihood of HP decreasing as the quest progresses or increasing attack power. The reward management unit 117 can identify the objects available to the user (objects owned by the user) by, for example, storing information indicating the objects available to the user (objects owned) in the storage unit 120. Furthermore, when a user is granted a benefit (for example, when the user logs in to the game and receives a login bonus), the benefit management unit 117 stores information indicating the benefit in the storage unit 120, thereby making it possible to identify the benefit as an object available to the user. As given in the example above, the benefits that can be granted to the user are not limited to those listed above, and can be anything that is necessary or interesting for the user as they progress through the game. Note that information indicating objects available to the user (objects owned) is also managed on the server 200 side, for example as user information 133, and is updated as the benefit is granted to the user or consumed.

The game progression unit 118 performs various processes related to the execution of the game. For example, the game progression unit 115 interprets the user's instructions indicated by the coordinates of the input position of the input operation received by the operation reception unit 111 and the type of operation, and performs processing to progress the game based on this interpretation.

Note that the functions of the server 200 and user terminal 100 shown in FIG. 2 are merely examples. The server 200 may have at least some of the functions of the user terminal 100. The user terminal 100 may also have at least some of the functions of the server 200. Furthermore, devices other than the user terminal 100 and server 200 may be components of the game system 1, and some of the processing in the game system 1 may be executed by these other devices. In other words, the computer that executes the game program in this embodiment may be any of the user terminal 100, the server 200, and other devices, or may be implemented by a combination of these multiple devices.

<Game Overview>
The game system 1 is a system that progresses through a unit of play selected by a user within a game based on a game program 131 .

Here, a play unit may be an event called a quest in the game, with set conditions for achievement. Hereinafter, the above-mentioned play unit will also be referred to simply as a quest.

The game system 1 grants a login bonus (benefit) to a user when the user logs in (uses) the game system in response to a user's operation. For example, when a user logs in, the user is granted a benefit associated with the timing of the login. The timing of the login is, for example, the date the user logged in. Furthermore, when the user logs in, the user is notified that if the user logs in again the following day (consecutive logins), the user may be granted a benefit different from the benefit associated with the following day. As a result, conventional login bonuses are unable to change the sense of anticipation or specialness regarding the benefit obtained by consecutive logins, which can give the user a monotonous impression and may not effectively encourage consecutive logins. However, the game system 1 makes it possible to change the sense of anticipation and specialness regarding the benefit (consecutive login bonus) that may be granted if the user logs in again the following day. As a result, it is possible to effectively encourage the user to log in again the following day.

In addition, the rewards that can be awarded to users if they log in again the following day are determined by lottery. This means that consecutive login bonuses are determined for each user by lottery, creating a sense of specialness for the rewards obtained through the lottery. As a result, users can be more effectively encouraged to log in again the following day.

Furthermore, if the user logs in again the following day, the rewards that can be granted to the user will be those that are more advantageous (valuable) to the user than the rewards associated with the following day, at a higher rate, and the user will be notified of this. This allows the user to recognize that logging in again the following day could be advantageous to the user, and as a result, the user's motivation to log in again the following day can be increased.

Game system 1 is not limited to a specific genre, and may be a system for executing games of any genre, as long as the game has the above-mentioned configuration. For example, the game may be a game based on a sport such as tennis, table tennis, dodgeball, baseball, soccer, or hockey, a puzzle game, a quiz game, a RPG, an adventure game, a shooting game, a simulation game, a training game, or an action game.

Furthermore, the game system 1 is not limited to a specific play style, and may be a system for executing games of any play style. For example, it may be a single-player game played by a single user, a multiplayer game played by multiple users, or, within the multiplayer game, a competitive game in which multiple users compete against each other, or a cooperative game in which multiple users cooperate. In other words, the quests described above may include both single-player quests and multiplayer quests. Furthermore, there may be quests that can be played in both single-player and multiplayer modes.

<Processing flow and game screen example>
An execution flow and screen examples for granting a login bonus in a game based on the game system 1 will be described with reference to FIGS. 1 to 16. Note that the process based on the following description is an example, and the invention according to this embodiment is not limited to a specific configuration. Furthermore, in the following description, among the series of processing steps described using flowcharts, at least some of the steps described as being executed by the user terminal 100 may be executed by the server 200. Furthermore, at least some of the steps described as being executed by the server 200 may be executed by the user terminal 100. The same applies to the process based on the flowcharts described below.

The login bonus screen according to this embodiment is a screen displayed on the user terminal 100 that has requested login, and may be included in the first screen displayed after the user logs in. Alternatively, it may be displayed after one or more screens are displayed sequentially after the user logs in. It may also be displayed in response to a specified operation by the user. Login bonus screens include, for example, a screen that awards login bonuses, a screen that displays login bonuses in a calendar or stamp rally format so that login bonuses can be viewed in a list, and a screen that determines login bonuses by lottery. It is also possible to display only one or all of these screens. For example, the screen that determines login bonuses by lottery may be displayed so that it is superimposed on an image such as a calendar, or it may be displayed as a separate screen that occupies the entire display unit 152.

<Embodiment 1>
In the consecutive login bonus according to the first embodiment, for example, the number of benefits associated with the next day is determined in advance by lottery and announced, and the determined number is awarded to the user when the user actually logs in again the next day. The execution flow and screen examples for awarding the login bonus according to the first embodiment will be described below.

An example of a login bonus screen according to this embodiment 1 will be described with reference to Figure 3. The login bonus screen according to this embodiment 1 is, for example, in the form of a calendar showing a predetermined period, as shown in Figure 3. In Figure 3, when the calendar is displayed in monthly units, information on bonuses associated with each date is displayed. The calendar may also function as an event calendar related to the game or the user.

On the server 200 side (game operator side), as shown in Figure 3, login bonuses are pre-associated with each date. The login bonuses (including the type and number of bonuses) pre-associated with each date are specified, for example, by a login bonus table included in the user information 133 for each user in the memory unit 220. The login bonus screen can be displayed by having the server 200 read out the login bonus table for the logged-in user and send information specifying the login bonus associated with each date to the requesting user terminal 100.

Furthermore, when a user logs in and a lottery is held in advance to determine the rewards to be awarded upon login the following day, the rewards associated with the following day in the login bonus table stored as the user's user information 133 are stored and updated with rewards corresponding to the lottery results. In this way, the login bonus table for each user is updated according to the user's login status. Furthermore, when the login bonus table is updated, information specifying the rewards associated with the following day is sent to the requesting user terminal 100. As a result, the user information 133 including the login bonus table is also updated on the user terminal 100 side, making it possible to always display on the user terminal 100 the rewards associated with each date specified from the latest login bonus table.

The login bonus table in user information 133 is a table for storing and updating information for identifying each user's login bonus (for example, information for identifying the type and number of bonuses, information used in lotteries, etc.). In other words, the login bonus associated with the timing of a user's login can be identified by the login bonus table included in user information 133, and processing is performed to execute a lottery, award a bonus, or display a screen for effects on the display unit 152 (for example, the server 200 sends information for displaying an image on the screen of the display unit 152 to the corresponding user terminal 100). By updating the login bonus table, the information regarding each user's login bonus can change depending on the timing of the user's login. The same applies to other embodiments below.

In the calendar shown in FIG. 3, date boxes 65a representing each date for a week starting on Sunday are arranged in a horizontal row. Groups 65b of date boxes representing each week are arranged vertically. A date box 65a with icon 64 "GET" superimposed thereon indicates that a login bonus was awarded to the user on the date indicated by that date box 65a. A date box 65a with icon 72 superimposed thereon indicates that the date indicated by that date box 65a is an event date. In the calendar shown in FIG. 3, events such as "Thunder Quest" indicate quests that are available for a limited time, and events such as "Gacha A" indicate lotteries that are available for a limited time. Note that if an event spans multiple days, icon 72 may be placed on the first day of the event period, or icon 72 may be placed across multiple days.

In this embodiment, a default number is set depending on the type of perk that can be granted to the user. For example, the default number for the first type of perk is 1, the default number for the second type of perk is 10, and the default number for the third type of perk is 100. Note that the types of perks and default numbers are not limited to these. In FIG. 3, items 80a-80c displayed in each date box 65a indicate the login bonus (perk) associated with that date. A number 66 such as "x1" displayed near each date box 65a indicates the number of login bonuses displayed in the corresponding date box 65a that will be granted if the user logs in on the date corresponding to the date box 65a. In this embodiment, the number of perks that can be granted to the user may vary from the default number depending on whether the user logs in consecutively.

In the first embodiment shown in Figure 3, the day the user logged in (today) is the 3rd (Monday) as an example. The benefit associated with today, the 3rd, is item 80c, and the default number of items 80c is set to 10. The benefit associated with tomorrow, the 4th, is item 80a, and the default number of items 80a is set to 10.

Icon 64 "GET" indicates that the user logged in on the corresponding date and was awarded a login bonus. In other words, the day on which icon 64 "GET" is displayed is a day on which the user logged in in the past.

Figure 3(B) shows the screen after logging in today, the 3rd, and after Figure 3(A) is displayed, an effect is performed to grant item 80c associated with the 3rd. As shown in Figure 3(B), the display is updated to show icon 73 "TODAY GET" superimposed on item 80c associated with the 3rd. In Figure 3, icon 64 "GET" is not displayed on the 2nd, the day before today, the 3rd, indicating that the user did not log in on the previous day. Therefore, as a login bonus for today, the 3rd, 10 items 80c are granted, which are the benefit pre-associated with the 3rd (for example, a benefit set by the game operator). In other words, because the user did not log in the day before the day they logged in (today), only the default number of 10 items 80c are granted as the benefit pre-associated with Monday the 3rd.

As mentioned above, in this embodiment, the number of bonuses awarded to a user when the user logs in consecutively is determined by lottery and can change (the number of bonuses can change to different numbers). In this embodiment, after the login bonus for the day the user logged in is awarded (for example, after Figure 3(B) is displayed), as shown in Figure 4(a), for example, a roulette 90 or the like is displayed on the display unit 152, and an effect is executed in which the number of bonuses for the next day is drawn by lottery.

The lottery for the next day's login bonus is conducted on the server 200 side by referring to (using) the number lottery tables shown in Figures 5(A) to (C). The "Number of Winnings" column in each table shows the number of perks to be awarded. The "Winning Probability" column shows the probability of winning the "Number of Winnings" in the same row. For example, the first number lottery table 301 is referenced when the default number of perks associated with the next day's login bonus is "1." The second number lottery table 302 is referenced when the default number of perks associated with the next day's login bonus is "10." The third number lottery table 303 is referenced when the default number of perks associated with the next day's login bonus is "100."

As shown in Figures 5 (A) to (C), in all tables, the probability of winning when the default number is determined is 5%, which is set to be lower than the probability of winning when a number greater than the default is determined. This means that the login bonus that can be awarded when a user logs in consecutively the next day is a higher number than when there are no consecutive logins (default number), and can be awarded at a higher rate. As a result, the user's motivation to log in again the next day can be increased. Note that the winning probability is just an example, and is not limited to this, as long as it is set so that the winning probability is higher when the number of wins is greater than the default. The number of wins is also just an example, and is not limited to the number shown in Figure 5.

In this embodiment, as shown in FIG. 3(A), item 80a is pre-associated as the login bonus for the 4th, the day after the 3rd. Because the default number of items 80a is 10, the second number lottery table 302 in FIG. 5 is referenced to perform the lottery. FIG. 4(B) displays the results of the lottery, which is performed by reference to the second number lottery table 302 in FIG. 5. For example, if the server 200 determines that the number of items 80a is 100, the user's login bonus table (the bonus associated with the following day, the 4th) is updated and the information is sent to the user terminal 100. As a result, as shown in FIG. 4(B), a message image stating, "Tomorrow's login bonus has been determined to be 100 items!" is displayed. Furthermore, if a number greater than the default is won, a special effect (for example, the roulette 90 is displayed in a more luxurious manner than in FIG. 4(A)) is performed, as shown in FIG. 4(B).

When the number of rewards for the next day's login bonus is drawn, as described above, the user's login bonus table is updated and the information is sent to the user terminal 100. As shown in Figure 3 (C), the number 66 at the bottom of the following day, the 4th, is updated to show "x100." This allows the user to recognize that the number of items 80a, which are the login bonus for the next day, has been changed to 100. If the user then logs in on the following day, the 4th, they will be granted 100 items 80a, determined by the lottery at their previous login (the previous day), as their login bonus. However, if they do not log in on the following day, the 4th, and instead log in on, for example, the 5th or later, they will not be granted 100 items 80a, and will instead be granted the default number of rewards pre-associated with the day they subsequently log in.

Furthermore, after the login bonus for the next day has been determined, the date box 65a corresponding to the next day and the bonus displayed within the date box 65a may be highlighted (e.g., highlight 82 in Figure 3(C)) on the calendar in Figure 3. This makes it easier for users to recognize information about the login bonus for the next day, increasing their motivation to log in again the next day.

The calendar shown in Figure 3 shows an example where the date starts on a Sunday. However, this is not limited to this; for example, the date may start on a Monday, or the week's date slots 65a included in the date slot group 65b may start on the first day of the month. In either case, the same effect as the calendar shown in Figure 3 can be achieved.

The calendar in Figure 3 has been described as displaying each date for one month. In this case, a calendar for another month may be displayed based on the operation of the next month button or previous month button (neither of which are shown). The calendar may be configured to be displayed monthly as described above, or in other units. Other units include, for example, weekly, annual, or specific time periods (such as Golden Week, so-called anniversary event periods based on the number of years since the game's release, or pre- and post-anniversary event periods). The calendar may also be configured to allow the user to view calendars for past or future dates that cannot be displayed on a single screen by scrolling left and right or up and down.

In this way, the calendar in Figure 3 makes it easy to see whether a user is logged in on each date, the details of the login bonus, and the date of an event. This calendar allows users to understand upcoming events and login bonuses that may be awarded in the future. As a result, users' motivation to log in to the game can be increased.

Figure 6 shows the quantity lottery process in this embodiment 1, which is executed on the server 200 side. The quantity lottery process is executed by accepting a login request from a user. The login request includes user information 133, such as the account of the logged-in user.

When a login request is received, in step S01, it is determined whether the login bonus for today (the day of login) has already been granted to the user who made the login request. Whether a login bonus has already been granted is determined based on user information 133 (e.g., a login bonus table). If it is determined in step S01 that the login bonus for today has already been granted to the user, the quantity lottery process is terminated.

On the other hand, if it is not determined in step S01 that today's login bonus has already been awarded, the process proceeds to step S02. In step S02, processing is performed to display a calendar on the display unit 152 of the user terminal 100. Specifically, information for identifying the login bonus associated with each date based on the login bonus table contained in the user information 133 of the user requesting login is sent to the requesting user terminal 100. As a result, the calendar exemplified in Figure 3 (A) and elsewhere is displayed on the display unit 152.

Next, as shown in step S03, processing of step S04A or step S4B is performed depending on whether the user logged in during a predetermined period. In this embodiment, the predetermined period is, for example, the period corresponding to the day after the user last logged in. The same applies to the other embodiments below. Note that the predetermined period is not limited to the day after, as will be described later.

If the user logged in during the specified period, step S04A is processed. If the user logged in outside the specified period, it is not a consecutive login, and step S04B is processed. That is, processing is performed to identify and award today's login bonus based on the login bonus table included in user information 133, which can be updated depending on whether today's login is a consecutive login following yesterday's. For example, in the login situation shown in Figure 3(A), no login was performed on Sunday the 2nd. Furthermore, today, Monday the 3rd, is already the day after the specified period from the last login on Saturday the 1st. Therefore, in this case, the user logged in outside the specified period, and step S04B is processed.

In the login bonus table stored as the user's user information 133, because the user did not log in on Sunday the 2nd, the pre-assigned bonus remains associated as the login bonus for the 3rd. Therefore, in step S04B, 10 items 80c are identified and granted to the user as a normal login bonus based on the login bonus table, and the display unit 152 displays the fact that the items have been granted. The granting of a normal login bonus means granting the default number of bonuses that were pre-associated with the date the user logged in based on the login bonus table included in the user information 133. The login bonus is then displayed, and the "TODAY GET" icon 73, as shown in FIG. 3B, indicates to the user that today's login bonus has been granted. When the login bonus is granted, the login bonus table is updated with information indicating that the bonus has already been granted. This makes it possible to identify that the login bonus associated with the day of login, for example, has already been granted. This also applies to the other embodiments described below.

From step S05 onwards, processing is carried out to draw the number of login bonuses for the next day. In step S05, a number drawing table corresponding to the login bonus for the next day is identified. For example, in Figure 3, the next day is Tuesday the 4th, so item 80a is pre-associated as a bonus. The second number drawing table 302 in Figure 5(B) is identified (referenced) according to the default number of 10 items 80a.

Next, the process proceeds to step S06, where a lottery screen for determining the number of login bonuses for the following day is displayed. In step S07, the number of login bonuses for the following day is determined by lottery, and the process proceeds to step S08.

In step S08, the login bonus determined by lottery as the login bonus for the next day is stored, and the program proceeds to step S09. That is, the number of bonuses associated with the next day in the login bonus table included in user information 133 is updated to the number determined in step S07. In step S09, based on the login bonus table updated in step S08, processing is performed to display the number of bonuses determined in step S07 on display unit 152 as the login bonus for the next day (for example, processing to send information specifying the determined number of bonuses), and the number lottery processing ends.

In this way, by processing steps S06 to S09, the display unit 152 of the user terminal displays, for example, a quantity lottery screen such as that shown in FIG. 4(A), and then displays, as shown in FIG. 4(B), a message indicating that 100 items 80a have been determined as the login bonus for the next day. The calendar also displays this information, as shown on the 4th day in FIG. 3(C). In steps S06 and S09, the server 200 transmits information to the corresponding user terminal 100 for displaying the screens exemplified in FIG. 4(A), FIG. 4(B), and FIG. 3(C).

Returning to step S03, if the user logs in during a predetermined period (for example, logging in on the 4th in FIG. 3C), step S04A is performed. In step S04A, the login bonus stored in step S08 for the previous login (the day before) is awarded, and a message to that effect is displayed on the display unit 152. For example, if a user logs in on the 3rd in FIG. 3 and then logs in the following day on the 4th, the 100 items 80a stored as the login bonus for the following day are identified as the login bonus and awarded to the user. Note that, as described above, in the login bonus table stored as the user's user information 133, the login bonus for the 4th was updated in step S08 at the time of login on the 3rd to the login bonus corresponding to the result of the lottery in step S07. Therefore, 100 items 80a are identified from the login bonus table and awarded as the login bonus for the 4th. After the login bonus is awarded in step S04A, the process proceeds to step S05, where the same process as described above is performed, and the number lottery process ends.

As described above, in this embodiment 1, when a user logs in, the number of perks to be awarded as the login bonus for the following day is determined by lottery on the day of the current login, and the determined number of perks is notified to the user in advance so that the user can understand. Furthermore, in this lottery, there is a high probability of winning a number greater than the default number of perks pre-associated with the following day (normal login bonus). Therefore, if the user logs in again the following day, they will be able to recognize that they may be awarded a number that is different from the default number of perks pre-associated with the following day and that is advantageous to the user. As a result, the user can feel a sense of anticipation and specialness about the login bonus for the following day, which increases their motivation to log in again the following day and effectively encourages them to log in the next day.

<Embodiment 2>
In the first embodiment, an example was described in which the degree of benefit value (e.g., number) of the consecutive login bonus can change, but in the second embodiment, an example in which the type can change will be described. That is, in the consecutive login bonus according to the second embodiment, for example, the type of benefit associated with the next day is determined in advance by lottery and notified, and the determined type of benefit is awarded to the user when the user actually logs in again the next day. Below, the execution flow and screen examples for awarding the login bonus according to the second embodiment will be described.

An example of a login bonus screen according to this second embodiment will be described with reference to Figure 7. The login bonus screen according to this second embodiment is, for example, in a calendar format showing a predetermined period, as shown in Figure 7. Since it is the same as Figure 3 except for the login bonuses associated with each date, a detailed description will be omitted.

For each date on the calendar shown in Figure 7(A), a standard login bonus of 10 coins 80d (the same bonus regardless of the date) is pre-determined. For example, if you log in on the 3rd on the calendar in Figure 7(A), you will be awarded 10 coins 80d displayed in box 65a as a login bonus.

Similar to the first embodiment described above, after the login bonus for the day the user logged in (today) has been awarded, the icon 73 "TODAY GET" is displayed in the box 65a for the 3rd day, as shown in FIG. 7(B). Then, as shown in FIG. 8(A), a lottery screen for the login bonus for the next day is displayed. In this second embodiment, the server 200 refers to (uses) the type lottery table 401 shown in FIG. 9 and executes a lottery to determine the type of benefit to be awarded as the login bonus for the next day.

Here, in the game of this embodiment 2, 10 coins are relatively easy for the user to obtain as they progress through the game, and are not particularly valuable to the user. In contrast, items A, B, C, premium lottery ticket A, and premium lottery ticket B shown in the type lottery table 401 of Figure 9 are more advantageous (valuable) to the user in progressing through the game than 10 coins. For example, these are items that cannot be exchanged unless 11 or more coins are consumed. Furthermore, the type lottery table 401 determines the probability of winning a type of benefit that is more valuable to the user than 10 coins at a higher rate.

After the type lottery table 401 is referenced and the lottery is drawn, the benefit determined as the login bonus for the next day is displayed, as shown in Figure 8 (B). For example, in this case, "Premium Lottery Ticket A" is determined as the login bonus for the next day, and a message image is displayed to that effect, stating, "Tomorrow's login bonus has been determined to be Premium Lottery Ticket A!" The lottery screen shown in Figure 8 may be displayed superimposed on a calendar, such as in Figure 7, or may be displayed as a separate screen across the entire display unit 152.

After the login bonus for the next day has been determined by lottery, as shown in FIG. 7(C), the "Premium Lottery Ticket A" determined by lottery is displayed in box 65a as the login bonus for the following day, the 4th. This allows the user to recognize that if they log in again the following day, they will be awarded a benefit that is more valuable to them than a regular login bonus. Note that when a benefit is determined in advance, as described above in embodiment 1, the benefit associated with the next day in the login bonus table is updated and stored with a benefit corresponding to the lottery results, and information for identifying the benefit associated with each date is sent to the user terminal 100 of the corresponding user. This updates the user information 133 on the user terminal 100, making it possible to display screens such as those shown in FIG. 7(C) and FIG. 8(B) on the user terminal 100.

Figure 10 shows the type lottery process in this embodiment 2, which is executed on the server 200 side. The type lottery process is executed by accepting a login request from a user.

When a login request is received, in step S11, it is determined whether the login bonus for today (the day of login) has already been granted to the user who made the login request. In other words, it is determined based on user information 133 (e.g., the login bonus table) whether the login bonus corresponding to the date the user logged in has already been granted. If it is determined in step S11 that the login bonus for today has already been granted to the user, the type lottery process is terminated.

On the other hand, if it is not determined in step S11 that today's login bonus has already been awarded, the process proceeds to step S12. In step S12, processing is performed to display a calendar on the display unit 152 of the user terminal 100. Specifically, information for identifying the login bonus associated with each date based on the login bonus table contained in the user information 133 of the user requesting login is sent to the requesting user terminal 100. As a result, the calendar shown in Figure 7 (A) and other figures is displayed on the display unit 152.

Next, as shown in step S13, step S14A or step S14B is performed depending on whether the user logged in within a predetermined period. The process identifies and awards today's login bonus based on the login bonus table included in user information 133, which can be updated depending on whether today's login is a consecutive login following yesterday's. For example, in the login situation shown in Figure 7(A), the user did not log in on Sunday the 2nd. Furthermore, today, Monday the 3rd, is already past the next day, which is the predetermined period from the last login on Saturday the 1st. Therefore, in this case, the user did not log in within the predetermined period, so step S14B is performed.

In the login bonus table stored as the user's user information 133, because the user did not log in on Sunday the 2nd, the pre-assigned bonus remains associated as the login bonus for the 3rd. Therefore, in step S14B, the normal login bonus of 10 coins 80d is identified and awarded to the user based on the login bonus table, and processing is performed to display on the display unit 152 that the bonus has been awarded. Awarding a normal login bonus means that a pre-assigned bonus is awarded based on the date the user logged in based on the login bonus table included in the user information 133. The user is then notified that today's login bonus has been awarded by the effect of awarding the login bonus and the display of icon 73 "TODAY GET" as shown in FIG. 7(B).

From step S15 onwards, processing is carried out to draw the type of login bonus for the next day. In step S15, processing is carried out to display a lottery screen for the type of login bonus for the next day, and in step S16, the login bonus for the next day is determined by referencing a type lottery table. Note that the type lottery table referenced in steps S15 and S16 is not limited to one; one lottery table may be identified according to the date of the next day from multiple types of lottery tables with different possible bonuses and winning probabilities, and the lottery may be carried out by referencing that lottery table.

Proceed to step S17, where the login bonus determined in step S16 is stored as the login bonus for the next day, and proceed to step S18. That is, the bonus associated with the next day in the login bonus table included in user information 133 is updated to the bonus type determined in step S16. In step S18, processing is performed to display the bonus type determined in step S16 as the login bonus for the next day on the display unit 152 based on the login bonus table updated in step S17 (for example, processing to transmit information specifying the determined bonus type), and the type lottery processing ends.

In this way, by processing steps S15 to S18, the display unit 152 of the user terminal displays a type lottery screen such as that shown in FIG. 8(A), and then displays a message indicating that "Premium Lottery Ticket A" has been selected as the login bonus for the next day, as shown in FIG. 8(B). The calendar also displays this information, as shown on the 4th in FIG. 7(C). In steps S15 and S18, the server 200 transmits information to the corresponding user terminal 100 for displaying the screens shown in FIGS. 8(A), 8(B), and 7.

Returning to step S13, if the user logs in during a predetermined period (for example, logging in on the 4th in FIG. 7C), step S14A is performed. In step S14A, the login bonus stored in step S18 for the previous login (the day before) is awarded, and a message to that effect is displayed on the display unit 152. For example, if a user logs in on the 3rd in FIG. 7 and then logs in again the following day on the 4th, the "Premium Lottery Ticket A" stored as the login bonus for the next day is identified as the login bonus and awarded to the user. Note that, as described above, in the login bonus table stored as the user's user information 133, the login bonus for the 4th was updated in step S17 at the time of login on the 3rd to the login bonus corresponding to the lottery result in step S16. Therefore, "Premium Lottery Ticket A" is identified from the login bonus table and awarded as the login bonus for the 4th. After the login bonus is awarded in step S14A, the process proceeds to step S15, where the same processing as described above is performed, and the type lottery process ends.

As described above, in this second embodiment, when a user logs in, the type of benefit to be granted as a login bonus the following day is determined by lottery on the day of the current login, and the determined type of benefit is notified to the user in advance so that the user can understand it. Furthermore, in this lottery, there is a high probability that the user will win a benefit that is more valuable to the user than the benefit pre-associated with the following day (the normal login bonus). Therefore, the user will be able to recognize that if they log in again the following day, they may be granted a benefit of a different type from the pre-assigned benefit for the following day that will be advantageous to the user. As a result, the user can feel a sense of anticipation and specialness about the login bonus the following day, which increases the user's motivation to log in again the following day and effectively encourages them to log in the next day.

<Embodiment 3>
In the first and second embodiments, examples were described in which a consecutive login bonus was determined and notified in advance. However, in the third embodiment, an example is described in which a table (a lottery table associated with each date) to be referenced in determining the consecutive login bonus is determined, and the degree of advantage (the table's degree of advantage) in the event of a lottery being held is notified in advance. That is, the consecutive login bonus according to the third embodiment involves, for example, determining and notifying in advance a table (a lottery table associated with the next day) for drawing a prize that may be awarded the next day, and when the user actually logs in again the next day, drawing a prize with reference to the determined lottery table, and awarding the prize determined by the lottery to the user. Below, an execution flow and screen examples for awarding a login bonus according to the third embodiment are described.

In this third embodiment, the benefits granted as login bonuses are objects that can be consumed in the game. When a user logs in, the lottery table to be referenced (used) for the next day's login bonus lottery is determined from multiple lottery tables (lottery tables with different degrees of advantage) with different winning probabilities assigned to each winning number, as shown in Figures 11 (A) to (C). If the user logs in consecutively, the number of benefits to be granted is determined by lottery by reference to (using) the lottery table determined at the previous (previous day's) login.

In this embodiment, ten coins 80d are pre-assigned as the default number of login bonuses for each date. In this embodiment, the number of coins 80d awarded to a user may vary from the default number depending on whether the user logs in consecutively. The lottery tables 401-403 shown in Figures 11(A)-(C) set winning probabilities to increase the chances of winning more than the default number of coins. For example, the expected value (e.g., the sum of the number of winning coins x the winning probability) when the lottery is drawn with reference to the normal rank lottery table 401 is 151 coins. The expected value when the lottery is drawn with reference to the high rank lottery table 402 is 291 coins. The expected value when the lottery is drawn with reference to the highest rank lottery table 403 is 370 coins. Thus, if a user does not log in consecutively, ten coins 80d are awarded as the default, whereas if the user logs in consecutively, the chances of winning more than ten coins increases. Furthermore, the lottery tables 401-403 have different numbers of winnings and winning probabilities that provide different degrees of advantage (value), with the highest rank lottery table 403 being set to have the highest degree of advantage.

Furthermore, in the above-mentioned first and second embodiments, an example was described in which a calendar was displayed as the login bonus screen after a login request was made by the user. However, in this third embodiment, an example is described in which a lottery screen or a login bonus award screen is displayed without displaying a calendar or the like. For example, immediately after the user logs in for the first time today, a lottery screen or a login bonus award screen is displayed. Furthermore, the login bonus that has been awarded or may be awarded may be confirmed by the user operating a menu tab such as the gift box, for example.

Figure 12 shows the table lottery process in this embodiment 3, which is executed on the server 200 side. The table lottery process is executed by accepting a login request from a user.

When a login request is received, in step S21, it is determined whether the login bonus for today (the day of login) has already been granted to the user who made the login request. In other words, it is determined based on user information 133 (e.g., the login bonus table) whether the login bonus corresponding to the date the user logged in has already been granted. If it is determined in step S21 that the login bonus for today has already been granted to the user, the table lottery process is terminated.

On the other hand, if it is not determined in step S21 that today's login bonus has already been awarded, the process proceeds to step S22, where, as shown in step S22, processing of step S23 or step S25B is performed depending on whether the user logged in during a specified period. Processing is performed to identify and award today's login bonus based on the login bonus table included in user information 133, which can be updated depending on whether today's login is a consecutive login following yesterday's.

For example, if the user's last login was on July 1st, but today's login is on July 3rd, step S25B is performed because the user's login did not occur within the specified period. In the login bonus table stored as the user's user information 133, the pre-assigned bonus remains associated with today's login bonus because the user did not log in the previous day. Therefore, in step S25B, 10 coins 80d are identified and awarded to the user as a regular login bonus based on the login bonus table, and the fact that they have been awarded is displayed on the display unit 152. Awarding a regular login bonus means awarding a bonus that is pre-associated with each date based on the login bonus table included in the user information 133.

In step S26, the lottery table to be referenced for the login bonus for the next day is determined, and the process proceeds to step S27. For example, as shown in (A) to (C) of Figure 11, one table is determined by lottery from among multiple lottery tables with different degrees of advantage.

In step S27, information for specifying the determined lottery table is stored in association with the login bonus table for the day after, and the program proceeds to step S28. That is, the information for specifying the lottery table determined in step S26 is associated and updated for the day after the login bonus table included in user information 133. In step S28, based on the login bonus table updated in step S27, processing is performed to display information regarding the degree of advantage of the lottery table determined in step S26 on display unit 152 (for example, processing to transmit information specifying the rank of the determined lottery table), and the table lottery processing ends.

In this way, by processing steps S26 to S28, information that can identify the table to be referenced in determining the login bonus for the next day is displayed on the display unit 152 of the user terminal. For example, if the highest rank lottery table 403 is determined, as shown in FIG. 13(A), a message such as "Log in again tomorrow and you can draw with the highest rank roulette!" is displayed, indicating that if you log in again tomorrow, a roulette with a high expected number of coins 80d will be used. In steps S23, S25A, S25B, and S28, the server 200 transmits information to the user terminal 100 for displaying a screen such as the example shown in FIG. 13(A). Note that the lottery screen such as that shown in FIG. 13 may be displayed so as to be superimposed on a game screen or the like displayed on the display unit 152, or may be displayed as a separate screen occupying the entire display unit 152.

Returning to step S22, if the user's login occurs within a predetermined period (e.g., if the user logs in on July 3rd and then logs in the following day, July 4th), step S23 is performed. In step S23, a lottery screen (a lottery screen corresponding to the rank in the lottery table) corresponding to the lottery table stored in step S28 at the previous login (the previous day) is displayed on the display unit 152. In step S24, the login bonus is determined by referencing the stored lottery table. Note that, in the login bonus table stored as the user's user information 133, for example, if the previous login was on July 3rd and today's login is on July 4th, and the login bonus for the following day, July 4th, was determined and stored in the highest rank lottery table 403 in steps S26 and S27 at the previous login on July 3rd, the highest rank lottery table 403 is updated to identify the highest rank lottery table 403 in association with today, July 4th. Therefore, when determining today's login bonus from the login bonus table, the highest rank lottery table 403 is referenced.

Next, the process proceeds to step S25A, where the login bonus determined in step S24 is awarded, and processing is performed to display this fact on the display unit 152. As described above, by processing steps S23 to S25A, assuming, for example, that a user logs in on July 3rd and then logs in the following day, July 4th, as described above, a lottery screen is displayed on the display unit 152 of the user terminal, informing the user that a lottery will be held by referencing the highest rank lottery table 403 determined at the previous login (the day before). If 500 coins 80d are won in the lottery, as shown in FIG. 13(B), a message such as "Today's login bonus is set to 500 coins 80d!" is displayed, indicating that today's login bonus has been set to 500 coins 80d. After today's login bonus is awarded and processing is performed to display this fact on the display unit 152 in step S25A, processing similar to that described above is performed, and the table lottery processing ends.

As described above, in this third embodiment, when a user logs in, the lottery table that will be referenced if the user logs in the following day is determined by lottery on the day the user logs in, and information regarding the advantageous degree (value) of the determined lottery table is notified to the user in advance, allowing the user to understand this. The determined lottery table has a high probability of winning a greater number of rewards than the default number of rewards pre-associated with the following day (normal login bonus). Therefore, if the user logs in again the following day, they will be able to recognize that they may be awarded a number of rewards that is different from the default number of rewards pre-associated with the following day, but that is advantageous to the user. As a result, the user can feel a sense of anticipation and specialness about the login bonus for the following day, which increases their motivation to log in again the following day and effectively encourages them to log in the next day.

In this third embodiment, an example has been described in which the number of benefits is drawn as the lottery to be executed upon login the following day. However, instead of or in addition to this, the type of benefit may be drawn as in the second embodiment. In this case, multiple types of tables with different types of benefit to be drawn and different winning probabilities may be provided as type lottery tables for drawing the type of benefit. When a user logs in, the type lottery table to be referenced when the user logs in the following day may be determined by lottery on the day the user logs in this time (today), and information regarding the degree of advantage of the determined type lottery table may be notified in advance.

<Fourth Embodiment>
In this fourth embodiment, if a predetermined period after login (e.g., the next day) is a special period, a lottery table for the special period, which has a higher chance of winning a prize than the lottery table referenced when the special period is not in effect, is referenced (used) to determine a prize to be awarded in advance by lottery when the user logs in the next day, and the determined prize is then awarded to the user when the user actually logs in again the next day. This fourth embodiment also illustrates an example of a case where, if the value of the login bonus awarded for consecutive logins (e.g., logging in the next day) is less than a predetermined value, the user can select a new lottery upon consecutive logins. Below, an execution flow and screen examples for awarding a login bonus according to this fourth embodiment are described. Note that, as in the third embodiment, a calendar or the like is not displayed, and instead a lottery screen and a login bonus award screen are displayed. In this embodiment, the prize awarded as a login bonus is an object that can be consumed in the game, as in the third embodiment. Coins are pre-associated with the login bonus for each date in this embodiment, with the default number set to 10.

Figure 14 shows the lottery process in this embodiment 4, which is executed on the server 200 side. The lottery process in this embodiment 4 is executed by accepting a login request from a user.

When a login request is received, in S31 it is determined whether the login bonus for today (the day of login) has already been granted to the user who made the login request. In other words, it is determined based on user information 133 (e.g., the login bonus table) whether the login bonus corresponding to the date the user logged in has already been granted. If it is determined in step S31 that the login bonus for today has already been granted to the user, the lottery process is terminated.

On the other hand, if it is not determined in step S31 that today's login bonus has already been awarded, the process proceeds to step S32. As shown in step S32, depending on whether the user logged in during a predetermined period, the process proceeds to step S33, where step S34, step S38B, or step S38C is performed. The process identifies and awards today's login bonus based on the login bonus table included in user information 133, which can be updated depending on whether today's login is a consecutive login following yesterday's.

For example, suppose the user's last login was on July 1st, but today's login is on July 3rd. Since the user's login did not occur within the specified period, step S38C is performed. In the login bonus table stored as the user's user information 133, the pre-assigned bonus remains associated with today's login bonus because the user did not log in the previous day. Therefore, in step S38C, 10 coins are identified and awarded to the user as a regular login bonus based on the login bonus table, and processing is performed to display on display unit 152 that the bonus has been awarded, after which the process proceeds to step S39. The awarding of a regular login bonus means that the default number of 10 coins is identified and awarded as a bonus pre-assigned based on the login bonus table included in user information 133 according to the date the user logged in, and the fact that the bonus has been awarded is displayed on display unit 152.

In step S39, processing of step S40A or step S40B is performed depending on whether the next specified period (the next day) is a special period. A special period could be, for example, a special day such as the birthday of the user or a specific character appearing in the game, or a limited-time campaign for a start dash campaign for beginners or a game event date. For example, if the day after the user logs in is the user's birthday, the next specified period is a special period, and processing of step S40B is performed to determine the lottery table for the login bonus for the day after the special period. On the other hand, if the day after the user logs in is not a special period, processing of step S40A is performed to determine the lottery table for the login bonus for the next day. In step S40A, one of multiple lottery tables with different degrees of advantage is selected by lottery, as shown in Figures 11(A) to 11(C), for example. The lottery screen has the same display format as Figure 4 in the first embodiment described above.

After the lottery table for the next day's login bonus is identified in step S40A, the process proceeds to step S41A, where a process is performed to display the lottery screen for the identified login bonus number for the next day on the display unit 152, and the process proceeds to step S42.

On the other hand, returning to step S39, if the next specified period is a special period, processing of step S40B is performed. In step S40B, a lottery table for the special period is identified, and in step S41B, processing is performed to display on the display unit 152 a lottery screen for the login bonus for the day after the identified special period, and then processing proceeds to step S42.

A lottery table for a special period is, for example, a table such as special lottery table 404 shown in FIG. 11 (D), which has a higher expected number of coins 80d to be won than lottery tables 401-403 that are referenced when the next specified period is not a special period. In this case, a special effect is executed, unlike the lottery screen for the login bonus for the next day that is displayed when the next specified period in step S41A is not a special period. For example, a message such as "Tomorrow is Mr./Ms. XX's (user name) birthday! I hope you win something great!" is displayed on display unit 152, creating a luxurious effect.

In step S42, the lottery table identified in step S40A or step S40B is referenced to determine the login bonus for the next day by lottery, and the process proceeds to step S43. In step S43, the login bonus determined by lottery as the login bonus for the next day is stored, and the process proceeds to step S44. That is, the number of perks associated with the next day in the login bonus table included in user information 133 is updated to the number determined in step S42. In step S44, processing is performed to display the number of perks determined in step S42 as the login bonus for the next day on display unit 152 based on the login bonus table updated in step S43 (for example, processing to transmit information specifying the determined number of perks).

In this way, steps S39 to S44 described above allow the user to recognize that when the next day falls within a special period, a different benefit will be awarded if the user logs in the next day than if the next day were not a special period, and that the benefit will be even more advantageous (valuable). This creates a sense of anticipation and specialness in the user regarding the login bonus the next day, increasing their motivation to log in again the next day and effectively encouraging them to log in the next day.

In step S44, processing is performed to display the next day's consecutive login bonus determined in step S42 on the display unit 152, and then the process proceeds to step S45. In step S45, it is determined whether the value of the next day's login bonus determined by lottery is less than a predetermined value. If it is determined in step S45 that it is not less than the predetermined value, the lottery process ends. The predetermined value refers to the degree to which the notification can raise the user's expectations to a certain level or above. Specifically, in the case of coins, if it is necessary to play the game for more than one hour to earn 100 coins, while it takes less than one hour to earn 50 coins, 50 coins may be determined to be less than the predetermined value, and 100 coins may be determined to be greater than the predetermined value. Note that the predetermined value is not limited to this and may be set appropriately depending on the game content, etc.

On the other hand, if it is determined in step S45 that the value of the login bonus for the next day determined by lottery is less than the predetermined value, the process proceeds to step S46. In step S46, processing is performed to display on the display unit 152 that a new lottery will be possible if the user logs in again the next day, and the lottery process ends. For example, if in step S42 the login bonus for the next day is determined to be less than 100 coins, which is determined to be less than the predetermined value, a message such as "If you log in again tomorrow, you can enter a new lottery for the login bonus!" may be displayed on the display unit 152. This allows the user to understand that a new lottery will be possible if the user logs in again the next day, effectively encouraging the user to log in the next day.

Returning to step S32, if the user logged in during the specified period, proceed to step S33 and determine whether the value of the login bonus stored in step S43 at the previous login is less than the specified value.

If step S33 does not determine that the login bonus is less than the predetermined value, step S38B is performed to award the stored login bonus and display on the display unit 152 that the login bonus has been awarded. That is, if the login bonus associated with the current day (when the user logged in) in the login bonus table stored as the user's user information 133 was determined at the previous (previous) login, and the value of the associated login bonus is not less than the predetermined value, the login bonus determined at the previous day is awarded as is. For example, if 100 coins were determined as the login bonus for the next day at step S42 at the previous (previous) login, 100 coins are identified and awarded as today's login bonus. After step S38B, the process proceeds to step S39, where the same process as described above is performed, and the lottery process ends.

On the other hand, if it is determined in step S33 that the degree is less than the predetermined level, then in step S34, a process is performed to display a selection screen on the display unit 152, prompting the user to select whether or not to hold a re-draw. For example, a message such as "Do you want to hold a re-draw for the login bonus determined yesterday?" is displayed on the display unit 152 along with selection tabs such as "YES" and "NO." In step S35, it is determined whether or not the user has selected a re-draw, and if a re-draw has not been selected (if "NO" is selected), the process proceeds to step S38B, where the same process as described above is performed, and the lottery process ends.

If a re-draw is selected in step S35 (when "YES" is selected), the process proceeds to step S36, where a re-draw screen is displayed on the display unit 152, showing the re-draw in progress. Next, in step S37, the login bonus is determined by the re-draw. The lottery table referenced in this re-draw is the same lottery table referenced at the previous (previous day) login. That is, it is possible that the login bonus stored in step S43 at the previous (previous day) login will be won, and the login bonus may be lower or higher in value than the stored login bonus. This creates tension and anticipation for the user as they decide whether or not to draw again, enhancing the enjoyment of the game. In step S38A, the login bonus determined by the re-draw is awarded, and a message to that effect is displayed on the display unit 152. The process then proceeds to step S39, where the same processing as described above is performed, and the lottery process ends. The lottery table referenced in the re-lottery in step S37 does not have to be the same lottery table referenced at the previous login (the day before), but may be determined by lottery from among multiple lottery tables (for example, determined by performing the same processing as in steps S39, S40A, and S40B).

In this way, even if the login bonus that can be awarded upon login the following day is determined to be less than the predetermined value, the user will be notified that they can re-enter the lottery by logging in the following day, which allows the user to understand that there is a possibility that the value of the bonus can be increased. As a result, the user can feel a sense of anticipation and specialness about the login bonus the following day, which increases their motivation to log in again the following day and effectively encourages them to log in the next day.

In this fourth embodiment, an example was described in which the number of bonuses is selected by lottery for the next day's login bonus. However, instead of or in addition to this, the type of bonus may be selected by lottery, as in the second embodiment. In this case, multiple types of tables with different types of bonuses and winning probabilities may be provided as type lottery tables for selecting the type of bonus. The type lottery table for the next day's login bonus may be determined by lottery on the day the user logs in this time (today). The type of bonus for the next day may then be determined by reference to the determined type lottery table and notified in advance. In this case, "less than a predetermined degree" may also include, regardless of the value of the login bonus, items already owned by the user, for example, determined by lottery as having low value to the user. For example, this may include the case where an item that is not very useful in the game, even if the user owns multiple items, is selected.

<Modification>
Modifications of the above-described first to fourth embodiments (hereinafter collectively referred to as "embodiments") are listed below.

(1) In the above embodiment, a calendar format such as that shown in Figures 3 and 7 was used as an example of a login bonus screen. However, this is not limited to this, and a stamp rally format such as that shown in Figure 15 may also be used. In this case, the start of the first day may be the first day the user logs in, or may be the first day depending on the start of a period such as an event period. It may also represent all days of the event period, or may display a predetermined period (10 days) during the event period (e.g., one month) calculated from the day the user first logged in. For example, a maximum number of login days may be set at 10 days, and on the 11th day of consecutive logins, the screen may start again from day 1.

In this way, even when the login bonus screen is displayed in a stamp rally format, a login bonus (normal login bonus) is associated with each day (date) from Day 1 to Day 10 in Figure 15. When a user logs in consecutively, a different bonus can be awarded than the login bonus (normal login bonus) awarded when the user does not log in consecutively. In this case, regardless of whether the login is consecutive (progressing to the actual date), the number of days in the stamp rally progresses to Day 2, Day 3, etc., depending on the number of days the user actually logged in. For example, assume that coins 80d are pre-associated with each of the 10 days in Figure 15, with a default number of 10 coins. On Day 1, the default number of coins 80d is awarded. Furthermore, when a user logs in on Day 1, a login bonus for Day 2, which can only be awarded when the user logs in the following day, is determined by lottery. For example, if "Premium Lottery Ticket A" is determined, "Premium Lottery Ticket A" is displayed in the date box 65a' corresponding to Day 2, as shown in Figure 15(B). This allows the user to recognize that if they log in again the next day, they may be awarded a different benefit than the login bonus (10 coins 80d) that was previously associated with the second day. As a result, it is possible to effectively encourage the user to log in again the next day. Note that if the user does not log in the next day, but instead logs in two days or later and completes the second day, they will be awarded the login bonus (10 coins 80d) that was previously associated with the second day, but will not be awarded the login bonus ("Premium Lottery Ticket A") that was previously only available for logging in the next day. Note that if the consecutive login streak is interrupted, the next login may start from day 1 again.

When the login bonus screen is displayed in a stamp rally format as shown in Figure 15, the bonus for the 11th consecutive day of login (the first day of the second or subsequent login) may be even more valuable (more advantageous) to the user than the previous first day, and a lottery may be held in advance on the 10th day. Furthermore, lottery screens such as those shown in Figures 4, 8, and 13 described in the above embodiments may be displayed superimposed on such a stamp rally format image, or may be displayed as a separate screen occupying the entire display unit 152.

(2) In the above embodiment, as shown in Figure 4 and elsewhere, an example was given in which the display format of the lottery (the display method when the login bonus is determined) is a roulette. However, the display format of the lottery is not limited to this, and various other lottery methods can be used, such as slots, lottery, selecting one card from shuffled cards, omikuji, and other mini-games. For example, a multiplication roulette could be used in a slot format, such as "x1 → x2 → x3... → x5... x20," in which the multiplier for the number of bonus wins changes, allowing the user to stop the slot at any time, or it could stop automatically. In this case, when determining consecutive login bonuses, the probability of winning something that is more valuable (advantageous) to the user than a regular login bonus can be controlled.

(3) In the above embodiment, an example was described in which a login bonus is pre-associated with a date regardless of whether consecutive logins are performed. However, this is not limited to this. A regular login bonus may also be determined by lottery each time a user logs in, rather than being pre-associated with a date. In this case, the lottery table referenced in determining the consecutive login bonus determines the type, number, and winning probability of the bonus to be selected so that a bonus with a higher value (degree of advantage) is determined more frequently than the lottery table referenced in determining the regular login bonus. Therefore, even if consecutive logins are not performed, a bonus determined by reference to a lottery table pre-associated with a date can be awarded to the associated user as the login bonus for the day the user logged in (today). For example, for a regular login bonus, the normal rank lottery table 401 in FIG. 11 is referenced. On the other hand, for consecutive login bonuses, when a user logs in, the lottery table for the login bonus to be awarded upon consecutive logins may be determined by lottery from either (B) or (C) in Figure 11, and information regarding the degree of advantage associated with the determined lottery table may be notified to the user in advance, and the number determined by reference to the lottery table may also be notified to the user in advance. Furthermore, when consecutive logins are performed, one of the tables from (A) to (C) in Figure 11 is determined by lottery, but it may be determined so that Figure 11 (A) has the lowest probability of winning.

(4) In the above embodiment, an example was described in which a login bonus is pre-associated with all dates, and can be awarded regardless of whether consecutive logins are performed. However, this is not limited to this, and some dates may not have a pre-associated login bonus (dates on which no login bonus is awarded). Even on dates on which no login bonus is pre-associated (hereinafter also referred to as "no-login-days"), if a user logs in on the day before the no-login-day and then logs in on the next day, a consecutive login bonus may be awarded (the login bonus may be associated with the previous login or the day of consecutive logins). In this case, on the previous day (the previous login), a notification may be given of the login bonus that will be awarded if the user logs in consecutively on the next day, or a notification that a login bonus will be awarded. Alternatively, no login bonus may be associated with any days, and a login bonus may only be awarded for consecutive logins (the login bonus may be associated with the date at the previous login or the day of consecutive logins), and no login bonus may be awarded for logins that do not qualify as consecutive logins.

(5) In the above embodiment, an example was described in which a different type or number of consecutive login bonuses may be awarded instead of the type or number of bonuses (normal login bonus) that are pre-associated with the date. However, this is not limited to this, and a different type or number of bonuses may be awarded as a consecutive login bonus in addition to the normal login bonus. For example, suppose 10 coins are set as the bonus to be awarded regardless of whether or not a user has logged in consecutively. Furthermore, if, when a user logs in (at the time of login), for example, item A is determined as the consecutive login bonus by referring to the type lottery table in Figure 9, the user may be notified that an additional item A will be awarded if the user logs in again the next day on the day of login (today), and when the user logs in the next day, 10 coins and item A may be awarded. Alternatively, when a user logs in, they may be notified that an additional bonus will be awarded if they log in the following day, or information indicating the degree of advantage of the lottery table used to draw the additional bonus, and the additional login bonus to be awarded when they log in the following day may be determined by lottery, with the determined login bonus being awarded along with the regular login bonus for the following day.

(6) In the above embodiment, an example was described in which a consecutive login bonus with a higher value (degree of advantage) to the user than the type and number of perks pre-associated with the date (normal login bonus) was more likely to be won. However, this is not limited to this, and the consecutive login bonus may always be a bonus with a higher value (degree of advantage) to the user than the normal login bonus. As an example, when determining the consecutive login bonus with reference to the number lottery table shown in FIG. 5, a table may be referenced that ensures that the number of winning perks to be selected does not include any numbers less than the default number, but only numbers greater than the default number (the number is always determined to be greater than the default number). Alternatively, instead of awarding the number of perks selected by lottery as the consecutive login bonus, the number of perks awarded may be determined by lottery to determine how many more perks than the default number will be awarded. In other words, the number of perks awarded may be the default number plus the number of perks won. This lets users know that if they log in again the next day, they will definitely receive a login bonus with higher value (degree of advantage) than if they had not logged in consecutively (the number of bonuses awarded will always be greater than the default number). As a result, this increases the motivation to log in consecutively so as not to miss the chance to receive the consecutive login bonus.

(7) In the above fourth embodiment, the user can choose whether or not to perform a re-draw, as in steps S34 and S35 of FIG. 14. However, this is not limited to this. If the value of the login bonus stored in step S43 is less than a predetermined value, a re-draw that increases the value may be performed. For example, even if the login bonus that can be awarded was determined to have a low value by the draw at the previous login, the value can be increased by logging in consecutively. This makes it more advantageous for the user to log in consecutively, thereby increasing the user's motivation to log in consecutively.

Furthermore, while the above description illustrates an example in which the consecutive login bonus's value (degree of advantage) to the user is at least equal to or greater than the value of a regular login bonus, the present invention is not limited to this. It is also possible for a consecutive login bonus to be awarded with a value (degree of advantage) less than the value of a regular login bonus. For example, when determining a consecutive login bonus by referring to the number lottery table shown in FIG. 5, a table may be referenced in which the number of consecutive login bonuses to be selected by lottery includes a number less than the default number (e.g., 5, less than the default 10, in the case of second number lottery table 302). Note that in this configuration, the percentage of consecutive login bonuses that are determined to be less than the value of the regular login bonus may be set lower than the percentage of consecutive login bonuses that are determined to be equal to or greater than the value of the regular login bonus, and an extremely low percentage (e.g., 1%) is preferable. Even in this case, unlike when the same bonus is awarded to all users, a bonus different from the regular login bonus may be awarded. This adds an element of surprise to the consecutive login bonus, making it less likely for users to tire of it and adding interest.

Furthermore, while the above description provides an example in which consecutive login bonuses with a higher value (advantage) to the user than the standard login bonus are more likely to be won, the present invention is not limited to this. The standard login bonus may be won at a higher rate than items with a higher value (advantage) to the user, or the rate at which items with a higher value (advantage) to the user are won may be the same as the rate at which the standard login bonus is won. For example, when determining the consecutive login bonus by referencing the number lottery table shown in FIG. 5, a table may be referenced that sets a higher probability of winning for the default number than for numbers greater than the default number, or a table that sets the same probability of winning for the default number as for numbers greater than the default number. Even in this case, a login bonus different from the standard login bonus may be awarded. As a result, unlike when the same bonus is awarded to all users, adding an element of surprise to the consecutive login bonus reduces user boredom and adds interest. Even when the same login bonus as the standard login bonus is awarded, the tension and anticipation surrounding the lottery creates a kind of gambling element, increasing interest in trying again the next day.

(8) The consecutive login bonus in the above embodiment may have a gradually increasing value (degree of advantage) with repeated consecutive logins. For example, when determining the consecutive login bonus by referring to the number lottery table shown in FIG. 5, the number of winning items to be selected may gradually increase with each consecutive login day, or the probability of winning a number greater than the default number may increase. Specifically, the second number lottery table 302 in FIG. 5 may reference a lottery table in which the number of winning items to be selected is doubled with repeated consecutive logins (e.g., every week), such as "20, 40, 60, 100, 200, 2000," or a lottery table in which the probability of winning the default number is halved and added to the probability of winning a number greater than the default number. Furthermore, if the lottery determines the type of perk, the rarity or level of the type of perk to be won may increase. For example, the type of benefit defined in the winning types shown in Figure 9 may be set to level 1 for item A at the beginning of consecutive logins, but the lottery table may be updated so that as consecutive logins are repeated, the level gradually increases to 2, 3, etc.

In addition, an upper limit may be set on the value (degree of advantage) that increases in stages. If the upper limit is reached, the next login may start from the initial stage again, or may return to a certain stage. For example, as shown in Figure 9, item A, which is defined as a winning type, has ranks from 1 to 10. If, through repeated consecutive logins, item A of rank 10 is updated to be defined as the winning type, rank 1 may be defined again one week after the last update of the type lottery table. Alternatively, the type lottery table may be updated to go back five stages and define item A of rank 5. Furthermore, users may be notified in advance of the system and control by in-game notifications or by having a notice displayed on the display unit 152 to that effect each time they log in.

(9) In the above embodiment, the consecutive login bonus can be a combination of a lottery to determine the type of perk and a lottery to determine the number of perks. For example, when a user logs in, the type of perk itself may be determined by lottery and notified as the login bonus for the next day. If the user logs in the next day, the number of perks that can be granted based on the previous day's decision may be determined by lottery the following day, and the determined number of perks may be granted and notified.

Alternatively, the number of perks can be determined by lottery the previous day and announced, and the type of perk that can be awarded with that number can be determined by lottery the following day. In this case, for example, a default number is associated in advance with each date, and when a user logs in, a number lottery table corresponding to the default number associated in advance for the following day is referenced to determine and announce the number that can be awarded the following day. Alternatively, when a user logs in the following day, a type lottery table corresponding to the default number associated in advance for that day (which defines types of perks with the same default number) is referenced to determine, award, and announce the type of perk.

Also, when a user logs in, both the type of perk and the number of perks may be determined by lottery and notified as the login bonus for the next day. Alternatively, when a user logs in, the lottery table to be referenced the next day may be determined by lottery, and the user may be notified of information regarding the advantageous degree (value) of that lottery table; and when the user logs in the next day, the lottery for the type and number of perks may be drawn by reference to the lottery table determined the previous day (at the previous login).

(10) In the above embodiment, the number of bonuses was selected by lottery as an example of changing the value of a bonus when determining the consecutive login bonus. However, examples of changing the value of a bonus are not limited to changing the number of bonuses. Instead of or in addition to changing the number, other parameters of the bonus may be changed. For example, in the case of an item, parameters for determining the item's advantageous value (value) or various parameters defined for the character (e.g., ranks with different rarity levels, levels corresponding to maturity, attack parameters, etc.) may be changed. For example, if a game defines multiple ranks with different rarity levels for items, characters, etc., a rank lottery table such as those shown in Figures 16(A) to 16(C) may be specified according to the rank of the item, character, etc. pre-associated with the login bonus according to the date, and a lottery may be held to change the pre-associated rank. For example, if the default rank of the pre-associated character on the following day is 1, the first rank lottery table 501 in Figure 16(A) may be referenced. Similarly, if the default rank of the character previously associated the following day is 2, the second rank lottery table 502 in FIG. 16(B) is referenced; if the rank is 3, the third rank lottery table 503 in FIG. 16(C) is referenced. In both rank lottery tables, the rank identical to the rank previously associated the following day is set to have the lowest probability of winning, and ranks higher than the rank previously associated the following day are set to have a higher probability of winning. In other words, if a user logs in consecutively the following day, a higher-ranked bonus may be awarded than if the user did not log in consecutively. More specifically, if character A is previously associated as the next day's bonus and the default rank of character A is 1, when the user logs in, the level of character A may be determined by lottery using (reference) first rank lottery table 501 as the login bonus for the next day, and the level of character A determined by lottery may be announced. If the user logs in the next day, the character A of the level determined by lottery may be awarded.

Furthermore, in the first embodiment, an example was described in which a default number corresponding to the benefit is predetermined as a normal login bonus. However, depending on the date, a different number may be predetermined as the default number even for the same type of benefit. Even in this case, the consecutive login bonus may be determined and announced by referring to a lottery table in which a greater number of benefits than the number pre-associated with the following date can be won.

(11) The login bonus lottery table in the above embodiment may be determined based on the user's game progress. The user's game progress may include, for example, attributes such as the user's level. When a user whose level is below a predetermined value (a beginner player of the game) logs in, the login bonus for the next day may be determined and notified by referring to a lottery table that includes items that are necessary or difficult to obtain for beginner players. On the other hand, when a user whose level is above a predetermined value (an intermediate or advanced player of the game) logs in, the login bonus for the next day may be determined and notified by referring to a lottery table that includes items that are necessary or difficult to obtain for intermediate or advanced players. More specifically, suppose a certain equipment item can be obtained by completing a predetermined quest. If the specified quest is easy for advanced gamers but difficult for beginner gamers, when a beginner user logs in, a type lottery table in which the equipment item is included in the lottery items may be referenced, while when an intermediate or advanced gamer whose level is above a predetermined value logs in, a type lottery table in which items that cannot be used by beginner gamers (items that can only be used in quests that cannot be played by beginner gamers) may be referenced. This makes it possible to grant benefits that are more valuable (more advantageous) to each user according to the user's progress.

In addition, items that are compatible with items already owned by the user, or items awarded as a result of game progress or login bonuses on the day the user logged in (today), may be awarded with a high probability as consecutive login bonuses. "Compatible" items mean, for example, items that can be combined to strengthen, evolve, or create a different item. In this case, a lottery table containing compatible items based on owned or awarded items is referenced. For example, if weapon A is awarded on the day the user logs in, the lottery table that determines the login bonus for the next day may include materials that can strengthen weapon A. Alternatively, without relying on a lottery, it may be determined that specific compatible items based on owned or awarded items will be awarded as consecutive login bonuses.

(12) In the above embodiment, the consecutive login bonus lottery table is selected from among multiple lottery tables, as shown in FIGS. 5 and 11, based on a login bonus previously associated with a date (e.g., item 80a associated with the day after the 3rd in FIG. 3). Also, in step S26 of FIG. 12, the lottery table to be referenced upon consecutive logins is determined from among multiple lottery tables with different degrees of advantage when a user logs in. However, this is not limited to this, and the table referenced upon consecutive logins may be predetermined. For example, the table may be uniformly determined for all dates, or a different lottery table may be predetermined depending on the date, and the user may be notified the day before that they can refer to that table to enter the lottery upon consecutive logins. In this case, the table that can be referenced upon consecutive logins may have predetermined bonus types and winning probabilities so that a login bonus with greater value (advantage) for the user than a regular login bonus may be awarded. For example, the consecutive login bonus lottery may uniformly refer to the third number lottery table in FIG. 5 regardless of the type of bonus predetermined for the next day (regardless of the default number), or one lottery table may be selected by lottery from among multiple lottery tables depending on the date. For example, in FIG. 3, even if the default number of 10 items 80a is associated with the following day, the 4th, one lottery table may be selected by lottery from among the first number lottery table 301 to the third number lottery table 303 in FIG. 5, and the selected lottery table may be referenced to determine the number of items 80a.

(13) In the above embodiment, the timing for notifying information regarding consecutive login bonuses or lottery tables was described as occurring after the login bonus for the day the user logged in (today) was awarded. However, this is not limited to this. For example, the timing may be after the login bonus for the day the user logged in (today) has been awarded, when the user performs a specified operation, or when the game progress for that day has reached a specified stage (for example, when a specified mission such as a quest has been completed).

(14) In the above embodiment, an example of a predetermined period is the period corresponding to the day after the day the user logged in (today). This next day is not limited to a period in which one day switches between 0:00 and 24:00, but may also be a period in which a predetermined time (for example, 4:00 PM) is set each day and the switch to the next day begins.

Furthermore, the specified period is not limited to one day, but may be a period of more than one day or more than 24 hours. The specified period may be, for example, three days from the day after the user logs in (today), or not just the day after, but two days from now and three days from now, or one week from the day after, or a day determined by lottery within the week from the day after, and if the user logs in within that period, it may be treated as consecutive logins and a different benefit from the pre-associated benefit may be granted.

The timing when the login bonus is awarded may also be set as the start of the next specified period. For example, the start time may be when the user logs in and receives today's login bonus (e.g., 1:00 PM on July 3rd). If 24 hours have passed since then (1:00 PM on July 4th), and the user logs in again within 24 hours (by 12:59 PM on July 5th), the login bonus determined by lottery at the previous login will be awarded. The next login bonus may also be awarded 24 hours after the bonus was awarded (e.g., 3:00 PM on July 4th) (3:00 PM on July 5th). Furthermore, if the start time of the next specified period is set to one week, the starting date for the next week may be calculated from the day the user logs in on any day during that week, or may change every week regardless of which day the user logs in on any day during the week.

The specified period may also be longer than one day, and a login bonus determined in advance by lottery may be awarded if the user logs in during a predetermined period within the specified period. For example, in the calendar shown in Figure 3, if the user logs in on the 1st, the specified period may be one week from Sunday the 2nd to Saturday the 8th, and the consecutive login bonus determined before the start of the week may not be awarded unless the user logs in on the third day of that week. In this case, the user is not notified that the predetermined period within the week is three days. Furthermore, in this case, the starting day of the next week may change every week regardless of which day the user logs in during the week. In addition, if the user logs in during a predetermined period within the week during which a login bonus may be awarded (for example, the third day of the week as mentioned above), the next week may start the following day.

(15) In the above embodiment, the consecutive login bonus may be set to a specific period longer than the predetermined period, and if a user logs in during any predetermined period within the specific period, a bonus different from the bonus associated with the predetermined period may be awarded. For example, a one-week period from the day of login may be set as the specific period, and a bonus different from the bonus associated with the next day may be awarded when the user logs in the next day, and a bonus different from the bonus associated with the period may be awarded when the user logs in during a predetermined period within the specific period. For example, in the calendar shown in FIG. 3, when a user logs in on the 1st, the specific period may be from Saturday the 1st to Friday the 7th, and the login bonus for the following day, the 2nd, or a table for determining the login bonus may be determined and announced. A predetermined period (also referred to as a specific day) within the specific period may be determined by lottery (e.g., Monday the 3rd), and a login bonus for the specific day or a table for determining the login bonus may be determined and announced. When informing the user about the login bonus for a predetermined period (specific day) or the table for determining said login bonus, the user is only informed that the bonus will be awarded if they log in on any day between the 1st and the 7th, but is not informed that the bonus will be awarded if they log in on Monday the 3rd, which has been determined as a specific day. For example, a message such as "You may receive item X if you log in any day within one week from tomorrow" may be displayed. This increases the user's motivation to continue logging in not just the next day, but the days after that, since they do not know which day in the week they need to log in to receive the bonus.

In addition, a login bonus awarded by logging in during a predetermined period (specific day) within a specific period may be awarded before the predetermined period is reached if certain conditions are met. The certain conditions may be, for example, payment of a fee, consumption of a consumable object, or completion of a certain quest. For example, the bonus may be awarded by the predetermined period (specific day) upon payment of a fee, or it may be awarded immediately upon payment. When notifying a user about the login bonus for a predetermined period (specific day) or the table used to determine the login bonus, the user may also be notified that the login bonus can be obtained if certain conditions are met.

(16) In the above example, the predetermined period was longer than 24 hours, but it is not limited to this and may be shorter than 24 hours, such as 12 hours. For example, if the first login occurs between midnight and 11:59 in one day, and the next login occurs between 12:00 and 23:59, it can be considered to be consecutive logins.

(17) In the above embodiment, an example was described in which a consecutive login bonus is awarded if a user logs in during a specified period. However, it may also be possible to set a condition that the bonus is awarded only if the user logs in within a specified time period. For example, if the user logs in between 11:00 and 13:00 every day, a consecutive login bonus different from the pre-associated login bonus may be awarded. In this case, regardless of whether the user logged in between 11:00 and 13:00 on the previous day, a lottery may be set to determine the login bonus that will be awarded if the user logs in between 11:00 and 13:00 the following day. Alternatively, if the user logged in between 11:00 and 13:00, a lottery may be set to determine the login bonus that will be awarded if the user logs in between 11:00 and 13:00 the following day.

(18) In the above embodiment, the login bonus is awarded only once on the day the user logs in (today). However, this is not limited to this, and the bonus may be awarded multiple times in a single day. Furthermore, one of the consecutive login bonuses that can be awarded multiple times may be awarded only if the user logs in within a specified time period within a single day. For example, consecutive login bonuses may coexist, including one that is awarded regardless of the time the user logs in the next day and one that is awarded only if the user logs in within a specified time period (for example, from 11:00 to 13:00).

(19) In the above embodiment, an example was described in which a login bonus for the day is awarded when a user logs in. However, the login bonus does not have to be awarded immediately after a user logs in; it may also be awarded when a condition for awarding is met based on the user's game progress. The condition for awarding may be met, for example, when a predetermined amount of game play time is reached, or when a predetermined quest is cleared. Furthermore, awarding a login bonus based on the user's game progress may apply to only one of the regular login bonus and consecutive login bonus, or to both.

(20) In the above embodiment, an example was described in which the consecutive login bonus was not awarded unless the user logged in within a specified period (e.g., the next day). However, even if the user was unable to log in within the specified period, the login bonus that would have been awarded if the user had logged in consecutively may be awarded to the user, provided that the user pays a fee or consumes a consumable object, etc. This allows the user to acquire a rare item, for example, even if the user won a rare item as a consecutive login bonus but was unable to log in within the specified period and thus was unable to obtain the item. For example, the numbers 66 below the date boxes 65a corresponding to the 24th, 27th, and 30th on the calendar in Figure 3 display the number determined by lottery at the time of login the previous day. However, because the user did not log in the following day, the login bonuses that were scheduled to be awarded on the 24th, 27th, and 30th were not awarded. However, the previous day, it was determined that 1,000 items 80a would be awarded on the 27th, and the user was unable to acquire the item, even though it would be highly valuable to the user. Even in such a case, for example, by touching the 27th and paying, the user may be able to acquire 1,000 items 80a that would have been awarded if they had logged in on the 27th. As a result, providing a relief measure can help maintain the user's motivation. Note that the period during which consecutive login bonuses can be awarded by paying outside of the specified period may be limited to a certain period (for example, within one week from the following day).

(21) In the above embodiment, an example was described in which information related to the consecutive login bonus, such as information regarding the type and number of bonuses that can be awarded as consecutive login bonuses in step S09 of FIG. 6, step S18 of FIG. 10, step S28 of FIG. 12, and step S44 of FIG. 14, and the advantageous degree of the lottery table, or information related to the consecutive login bonus, such as the possibility of a re-lottery in step S46 of FIG. 14, was displayed on the display unit 152. However, the information related to the consecutive login bonus is not limited to what is displayed on the display unit 152 as long as it can inform the user of the information, and for example, a voice notification such as "Log in tomorrow and you'll receive XX!" may also be used. Furthermore, information related to the consecutive login bonus may not only be displayed on the game screen displayed on the display unit 152, but may also be notified via so-called push notifications to a smartphone or the like.

(22) In the above embodiment, an example was described in which information regarding consecutive login bonuses was displayed on the display unit 152 when the consecutive login bonus was determined by lottery or the like when the user logged in (today). However, the user may be notified multiple times before a predetermined period of time has elapsed (ended), not just when the bonus was determined by lottery or the like. Furthermore, the multiple notifications to the user may be a combination of multiple different methods, such as display on the game screen displayed on the display unit 152 as described above or push notification. In addition to the notification on the day of login (today), for example, a push notification such as "If you log in today, you will receive 20 times the jewels!" may be sent the next day based on the consecutive login bonus determined the previous day. By reminding the user in this way, it is possible to prevent them from forgetting to log in the next day.

(23) In the above embodiment, an example was described in which the contents of the bonus are displayed on the display unit 152 when the login bonus for the next day is determined. However, it is also possible to display only the silhouette of the determined bonus without clearly displaying what may be awarded as a consecutive login bonus, for example. Furthermore, when the number of bonuses is to be drawn by lottery, it is also possible to disclose only the number of digits of the number, or only a predetermined number of digits (for example, only the hundreds digit), or only part of the bonus information such as attributes or rank. In this way, by making the contents of the determined consecutive login bonus not only available in full, but also available in part, the user will become curious about and excited about the results, which can further increase motivation to log in the next day.

(24) In the above embodiment, an example was described in which a login bonus (normal login bonus) that is pre-associated with a date can be recognized by the user even if it is a login bonus for a future date, as shown in Figures 3 and 7 (for example, in Figure 3, the login date is the 3rd, but item 80d is displayed on the 6th). However, this is not limited to this, and the present invention may also be applied to a login bonus for a future date that is not revealed until a predetermined number of days have passed. For example, as shown in Figure 15, a login bonus for a future date may be hidden by icon 64b "?", and after today's login bonus is awarded, the login bonus for the next day may be announced, as displayed for the second day in Figure 15(B).

(25) In the above embodiment, the consecutive login bonus determined by the lottery in FIG. 3 is a number different from the default number of bonuses pre-associated with the date, and the probability of winning a number advantageous to the user is high. If the user logs in consecutively, the bonus is awarded in the number determined by the lottery. However, even if consecutive logins are not possible (the next login is after a predetermined period has elapsed), the bonus that would have been awarded for consecutive logins may be awarded in the default number at the next login, in addition to the regular login bonus, or as the regular login bonus for that day. For example, as shown in FIG. 3, if a user logs in on Monday the 3rd and the number of items 80a pre-associated with Tuesday the 4th is determined by lottery as the consecutive login bonus for the following day, the user may be awarded a number of items 80a different from the default if the user logs in on the following day, the 4th. However, if the user logs in two days later, the 6th, without logging in on the following day, the 4th, the number of items 80a different from the default may not be awarded, but may be awarded in the default number, i.e., the original value. In this case, the default number of 1 item 80b, which is a pre-associated bonus, will be granted as a normal login bonus on the 6th, and the default number of 10 items 80a, which was pre-associated on the 4th, the day after the previous login, will also be granted.

(26) In the above embodiment, Figure 14 describes an example in which, when the next specified period is a special period, a lottery table corresponding to the special period is identified (referenced). However, this is not limited to this, and even when the day the user logged in (today) is a special period, the lottery table for the login bonus for the next day may be identified as a lottery table corresponding to the special period. For example, if the day the user logged in was the user's birthday, the login bonus for the next day may be determined by referencing the lottery table for the special period.

(27) In the above fourth embodiment, an example was described in which the special lottery table 404, which can be referenced for the login bonus on the day after a special period, specifies that the number of winning items eligible for the lottery is only greater than the default number of rewards. However, this is not limited to this, and the special lottery table 404 may include the default number in the number of winning items eligible for the lottery, as long as the probability of winning a reward that is more valuable to the user is higher than when there is no special period.

(28) In the above embodiment, an example was described in which a selection screen for whether or not to perform a re-draw was displayed when the degree of value of the login bonus stored in step S34 of FIG. 14 was less than a predetermined degree. However, if consecutive logins are made, it may be possible to select whether or not to perform a re-draw, regardless of the degree of value of the stored bonus. For example, in a lottery to determine the type of bonus, even if the value of the bonus won is high, depending on the user's current game progress, it may not be the bonus they want at the moment. In such cases, the user may be able to select a re-draw.

(29) In the above embodiment, the re-draw of the login bonus in step S37 of FIG. 14 is performed by referencing the same lottery table as the lottery table referenced the previous day, and therefore an example was described in which it was not certain whether the value of the login bonus won would be higher or lower than the currently determined and stored value of the login bonus. However, in the re-draw of the login bonus in step S37, it may be possible to ensure that the login bonus won is always higher in value than the currently determined and stored value of the login bonus due to consecutive logins.

(30) In the above embodiment, an example was described in which, in step S34 of FIG. 14, a selection screen for whether or not to perform a re-draw is displayed if the value of the login bonus stored at the time of the previous day's login is less than a predetermined value. This re-draw may be performed multiple times, depending on the user. In this case, a re-draw may be selected regardless of whether the value of the login bonus determined by the first re-draw is less than a predetermined value, and the previous drawing results may not be reverted. For example, if the drawing is performed with reference to the high rank table 402 of FIG. 11, and the number of winning balls in the first drawing was 50, but the user selects a re-draw, the second drawing may be performed with reference to the same high rank table 402 again. Alternatively, the drawing may be performed with reference to a drawing table in which the number of winning balls eligible for the drawing is 10, 100, and 500, excluding 50. Alternatively or additionally, even if the number of winning balls in the second drawing is 10, it may not be possible to cancel this and return to the first drawing of 50 balls.

(31) In the above embodiment, the program is described as a program for progressing through a game. However, the program is not limited to a program for progressing through a game, and can also be applied to, for example, login points for online shopping. Furthermore, the program is not limited to such continuous use on the Internet, but can also be applied to store visit points that can be used for shopping at actual stores. In this case, the user terminal 100 is an information processing device with a function for reading external memory cards, point cards, etc., or, instead of or in addition to these, a wireless IC card reading function for reading barcodes, QR codes (registered trademark), etc., presented by the user.

When the above embodiment is applied to a visit to an actual store, the user terminal 100 may be operated by the user themselves, or a store employee may scan the user's terminal 100 on their behalf. The user may also scan a card containing identification information such as a user ID into the user terminal 100 installed in the store. Furthermore, the benefits that can be awarded to a user are not limited to points; for example, discount coupons can also be awarded. Specifically, a points card that awards points every day of a visit may be scanned into the information processing device, and points for each day of the visit are awarded. The number of points awarded on the next visit can also be determined by lottery. In this case, the next visit does not have to be the next day; for example, if the user visits within one week, the number of points determined by the lottery can be awarded. This allows users to receive potentially advantageous benefits by visiting the store frequently (or daily), thereby increasing the motivation for frequent use of the store.

[Software implementation example]
The control blocks of the control unit 210 (particularly, the lottery execution unit 211, the quest management unit 212, and the login bonus screen management unit 213) and the control blocks of the control unit 110 (particularly, the lottery unit 115, the judgment unit 116, the benefit management unit 117, and the game progression unit 118) may be realized by logic circuits (hardware) formed on an integrated circuit (IC chip) or the like, or may be realized by software using a CPU (Central Processing Unit).

In the latter case, an information processing device equipped with control unit 210, control unit 110, or both, includes a CPU that executes program instructions, which are software that realizes each function; a ROM (Read Only Memory) or storage device (these are referred to as "recording media") on which the program and various data are recorded so that they can be read by a computer (or CPU); and a RAM (Random Access Memory) on which the program is deployed. The object of the present invention is achieved when the computer (or CPU) reads and executes the program from the recording media. The recording media can be "non-transitory tangible media," such as tapes, disks, cards, semiconductor memories, and programmable logic circuits. The program may also be supplied to the computer via any transmission medium capable of transmitting the program (such as a communications network or broadcast waves). One aspect of the present invention can also be realized when the program is embodied through electronic transmission in the form of a data signal embedded in a carrier wave.

<Additional Notes>
The matters described in the above embodiments will be supplemented below.

(Appendix 1):
According to one aspect of the present disclosure, the program causes a computer (server 200, user terminal 100) to function as: a means for granting a privilege to a user when the user starts using the service (e.g., logging in) in response to the start of use (e.g., logging in) in accordance with the timing (e.g., date) of the start of use (steps S04A and S04B of FIG. 6 , steps S14A and S14B of FIG. 10 , steps S25A and S25B of FIG. 12 , steps S38A, S38B, and S38C of FIG. 14 ); and a means for notifying, before the predetermined period has elapsed, of information (information stored and updated in a login bonus table included in user information 133) that identifies that a privilege different from the privilege associated with the timing of the start of use may be granted when the user starts using the service again within a predetermined period (e.g., the next day) after the privilege was granted in response to the start of use.

(Appendix 2):
In (Supplementary Note 1), when the period includes the timing of the start of use (e.g., the day the user logs in) or the specified period is a special period (step S39 YES in FIG. 14), the means for notifying notifies (step S44 in FIG. 14) information that can identify that a benefit different from the benefit associated with the timing of the start of use again may be granted at a higher rate when use is started again during the specified period than when the special period is not.

(Appendix 3):
In (Appendix 1), the computer functions as a means (step S16 in FIG. 10) for drawing by lottery the benefit to be granted when use is resumed within the specified period from among a plurality of types of benefits (see FIG. 9), including benefits of a different type from the benefit associated with the timing of the resumption of use (see FIG. 7).

(Appendix 4):
In (Appendix 3), the information specifies that when use is resumed within the specified period, a type of benefit of higher value than the benefit associated with the timing of the resumption of use will be granted, and the lottery means draws the lottery so that a type of benefit of higher value than the benefit associated with the timing of the resumption of use will be won (step S16 of Figure 10).

(Appendix 5):
In (Appendix 1), the multiple types of benefits include a benefit whose value degree can be changed to one of multiple levels of value degree, including a first value degree which is the default value degree, and a second value degree whose value degree is different from the first value degree, and when a benefit of the first value degree is pre-associated as a benefit whose value degree can be changed depending on when use is started again during the specified period (see Figure 3), the computer functions as a means (step S07 of Figure 6) for drawing by lottery from among the multiple levels of value degrees (see Figure 5) the value degree of the benefit to be granted when use is started again during the specified period.

(Appendix 6):
In (Appendix 5), the second value degree is higher than the first value degree, the information is information specifying that a benefit of the second value degree will be granted as a benefit that can change the value degree granted when use is started again within the specified period, and the means for drawing lots draws so that the second value degree is won (step S07 of Figure 6).

(Appendix 7):
In (Appendix 5), when use is not initiated within the specified period and is initiated after the specified period has elapsed (for example, two days later), the granting means can grant a benefit of the first value degree (default value degree) as a benefit that can change the value that would have been granted if use had been initiated again within the specified period.

(Appendix 8):
In (Appendix 3) or (Appendix 5), the means for notifying notifies, during use (e.g., during the day the user logs in) after the start of use, information that can identify the result of the lottery drawn by the lottery drawing means, as information that can identify that the different benefit may be granted.

(Appendix 9):
In (Appendix 8), when the means for notifying notifies information that the degree of value of the benefit will be less than a predetermined degree (YES in step S45 of Figure 14) based on information that can identify that a different benefit may be granted depending on the result of the lottery by the means for drawing, the means for notifying can notify information that can identify that the benefit to be granted upon re-start of use within the predetermined period will be re-drawn by the means for drawing (step S37 of Figure 14) and the degree of value may become equal to or greater than the predetermined degree (step S46 of Figure 14).

(Appendix 10):
In (Supplementary Note 9), the lottery means can perform the re-lottery by accepting a specific operation from the user (YES in step S35 of FIG. 14).

(Appendix 11):
In (Appendix 3) or (Appendix 5), the computer is made to function as a means for determining (step S26 of FIG. 12) a lottery table to be used in the lottery by the lottery means from among a plurality of lottery tables with different degrees of advantage for the user (see (A) to (C) of FIG. 11) during use as a result of the start of use (for example, during the day when the user logs in), and the means for notifying notifies, during use as a result of the start of use, information regarding the degree of advantage of the lottery table according to the determination result by the determination means as information that can identify that the different benefits may be granted (step S28 of FIG. 12), and the lottery means draws for a benefit to be granted when use is started again within the specified period using the lottery table determined by the determination means (step S24 of FIG. 12).

(Appendix 12):
In (Appendix 1), the means for granting can grant a benefit according to the timing at which use is initiated when a specific progress condition is met after use is initiated (for example, when the game progress on the day the user logs in reaches a predetermined stage).

(Appendix 13):
In (Appendix 1), the benefits associated with the timing of the start of use may be different for the first timing (e.g., item 80c on the 3rd day in Figure 3(A)) and the second timing (e.g., item 80a on the 4th day in Figure 3(A)).

(Appendix 14):
In (Supplementary Note 1), the predetermined period is a period corresponding to the day following the day on which use is started by the user's operation.

(Appendix 15):
In (Appendix 1), a specific period (for example, from Saturday the 1st to Friday the 7th) that is longer than the specified period and includes the specified period is set, and the means for notifying, when notifying information that can identify that the different benefit may be granted, notifies that if usage is started again at a timing within any of the predetermined periods within the specific period (for example, Monday the 3rd), a benefit different from the benefit associated with that timing may be granted.

(Appendix 16):
In (Appendix 1), the means for notifying notifies identifiable information that the different benefits may be granted before the specified period has elapsed at least twice (for example, at login on the first day and on the following day, the second day).

(Appendix 17):
According to one aspect of the present disclosure, an information processing device (server 200, user terminal 100) includes: means for granting to a user a benefit associated with the timing (e.g., date) of the start of use (e.g., logging in, reading a card with identification information) by a user operation (e.g., logging in, reading a card with identification information) of the start of use; and means for notifying, before the predetermined period has elapsed, information that can identify that a benefit different from the benefit associated with the timing of the start of use may be granted if the user starts use again within a predetermined period (e.g., the next day) after the benefit was granted upon the start of use (information stored or updated in a login bonus table included in user information 133).

The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention.

1 Game system, 2 Network, 10, 20 Processor, 11, 21 Memory, 12, 22 Storage, 13, 23 Communication IF (operation unit), 14, 24 Input/output IF (operation unit), 15 Touch screen (display unit, operation unit), 17 Camera (operation unit), 18 Distance measurement sensor (operation unit), 100 User terminal (information processing device), 110, 210 Control unit, 111 Operation reception unit, 112 Display control unit, 113 UI control unit, 114 Animation generation unit, 115 Lottery unit, 116 Determination unit, 117 Benefit management unit, 118 Game progression unit, 120, 220 Memory unit, 131 Game program, 132 Game information, 133 User information, 151 Input unit (operation unit), 152 Display unit, 200 Server, 211 Lottery execution unit, 212 Quest management unit, 213 Login bonus screen management unit, 1010: Object, 1020: Controller (operation unit), 1030: Storage medium

Claims (11)

Computer,
a means for granting a benefit associated with the start of use to the user in response to the start of use through an operation by the user;
the function of the device is to notify, before the predetermined period has elapsed, information that can identify that a benefit different from the benefit associated with the timing of the resumption of use may be granted if the user resumes use within a predetermined period after the benefit is granted upon the resumption of use ;
The means for notifying is a program that notifies identifiable information that, when the period including the timing of the start of use or the specified period is a special period, a benefit different from the benefit associated with the timing of the start of use again may be granted at a higher rate by starting use again during the specified period than when the period is not a special period . Computer,
a means for granting a benefit associated with the start of use to the user in response to the start of use by the user's operation;
means for notifying, before the predetermined period has elapsed, information that can identify that a benefit different from the benefit associated with the timing of the restart of use may be granted if the user starts using the service again within a predetermined period after the benefit is granted upon the start of use;
The program functions as a means for drawing a lottery for a benefit to be given when the use is started again during the predetermined period from among a plurality of types of benefits including a benefit different in type from the benefit associated with the timing of the start of use again . the information is information specifying that, when the use is resumed within the predetermined period, a benefit of a type higher in value than a benefit associated with the timing of the use being resumed will be granted;
3. The program according to claim 2 , wherein the lottery means draws a lottery so that a type of benefit higher in value than a benefit associated with the timing of the restart of use is won. Computer,
a means for granting a benefit associated with the start of use to the user in response to the start of use through an operation by the user;
the function of the device is to notify, before the predetermined period has elapsed, information that can identify that a benefit different from the benefit associated with the timing of the resumption of use may be granted if the user resumes use within a predetermined period after the benefit is granted upon the resumption of use ;
The plurality of types of benefits include a benefit whose value degree can be changed to one of a plurality of value degrees including a first value degree that is a default value degree and a second value degree that is different in value degree from the first value degree,
The computer
When a benefit of the first value degree is pre-associated as a benefit whose value degree can be changed depending on when use is resumed within the specified period, the program functions as a means for drawing a lottery from among the multiple value degrees to determine the value degree of the benefit to be granted when use is resumed within the specified period . The second value degree is higher than the first value degree,
the information is information specifying that a benefit of the second value degree will be granted as a benefit whose value degree is variable when the use is resumed within the predetermined period,
5. The program according to claim 4 , wherein the lottery means draws the lottery so that the second value degree is won. The program described in claim 4, wherein the granting means is capable of granting a benefit of the first degree of value as a benefit that can change the value that would have been granted if usage had started again within the specified period when usage was not started within the specified period and usage was started after the specified period has elapsed. The program described in claim 2 or claim 4, wherein the means for notifying notifies, during use following the start of use, information that can identify the lottery result drawn by the lottery drawing means as information that can identify the possibility of the different benefit being granted. The program described in claim 7, wherein the means for notifying is capable of notifying information that can identify that a different benefit may be awarded depending on the lottery result by the lottery means, and that when the means for notifying is capable of notifying information that can identify that the benefit to be awarded upon re-start of use within the specified period will be re-drawn by the lottery means and that the degree of value may be greater than or equal to the specified degree. The program according to claim 8 , wherein the lottery-drawing means is capable of conducting the re-lottery by accepting a specific operation from the user. The computer
During the use resulting from the start of the use, the device functions as a means for determining a lottery table to be used in the lottery by the lottery drawing means from among a plurality of types of lottery tables having different degrees of advantage for the user,
The notifying means notifies, during the use resulting from the start of use, information regarding the advantageous degree of the lottery table according to the determination result by the determining means, as information that can identify that the different benefit may be granted,
5. The program according to claim 2 , wherein the lottery means draws the benefit to be granted when the service is resumed within the specified period using a lottery table determined by the determination means. a means for granting a benefit associated with the start of use to the user in response to the start of use through an operation by the user;
and means for notifying, before the predetermined period has elapsed, information that can identify that a benefit different from the benefit associated with the timing of the restart of use may be granted if the user starts using the service again within a predetermined period after the benefit is granted upon the start of use ;
The information processing device is configured so that the means for notifying notifies identifiable information that, when the period including the timing at which use is started or the specified period is a special period, a benefit different from the benefit associated with the timing at which use is started again may be granted at a higher rate by starting use again during the specified period than when the period is not a special period.