Game delivery server, game delivery system, game delivery method, and game delivery program

Abstract

This invention provides a game delivery server, game delivery system, game delivery method, and game delivery program that can offer a new mechanism to enhance users' motivation to play games. [Solution] A game provision server that provides a game to a user terminal used by a game user, the game having a limited lottery which is unlocked when the conditions for unlocking the lottery are met, the game provision server comprising: a battle result acquisition unit that acquires battle results which are the results of battles between users; an authority granting unit that grants execution authority to the user terminal to execute the limited lottery when the battle results meet the unlock conditions; a lottery execution unit that, when it receives a request for the limited lottery from a user terminal that has been granted execution authority, executes the limited lottery and outputs a lottery result from among the lottery targets which are pre-set lottery targets; and a storage unit that stores battle results, unlock conditions, and execution authority for each user.

Description

Technical Field

[0001] The present disclosure relates to a game providing server, a game providing system, a game providing method, and a game providing program.

Background Art

[0002] In conventional online games, a lottery system (gacha) for acquiring characters and items is widely adopted. Any user can participate in the lottery without particular conditions during the holding period. Lotteries include those that require compensation when executed and those that are free of charge. Paid lotteries often include lottery candidates that are particularly advantageous for progressing in the game. Therefore, in order to gain an advantage in the game, repeating paid lotteries to accumulate lottery results is one of the effective means.

[0003] In addition, among the contents in conventional games, there exists player-versus-player content which is a competition format between users. Player-versus-player content includes PvP (Player vs Player), which is a competition between individual users, and GvG (Guild vs Guild), which is a competition between groups (such as guilds) that users belong to. Since victory or defeat in PvP is determined by the ability and amount of payment among users, it is generally characterized by being more difficult to win than other contents in the game in many cases. In addition, GvG is often characterized by a high entry barrier in that users must belong to a group in the first place.

Prior Art Literature

Patent Literature

[0004]

Patent Literature 1

Summary of the Invention

Problem to be Solved by the Invention

[0005] In traditional gacha (lottery) systems, anyone who pays can draw under the same conditions, which tends to reduce the difference in in-game advantages between heavy spenders and light spenders. This diminishes the sense of superiority and return on investment for paying users, reducing their motivation to spend. Furthermore, in player-versus-player (PvP) content, the outcome is influenced by the skill level and amount of money spent by users, and the high barrier to entry of belonging to a group, combined with the not-so-generous rewards, tends to limit the number of users who participate.

[0006] Therefore, there was a challenge in that we could not provide a new mechanism to improve users' motivation to play games. [Means for solving the problem]

[0007] A game provision server according to the first aspect of this disclosure provides a game to a user terminal used by a user of the game, which includes a limited lottery that is released when a release condition is met, which is a condition for releasing the lottery, and comprises: a battle result acquisition unit that acquires battle results, which are the results of battles between the users; an authority granting unit that grants the user terminal the authority to execute the limited lottery when the battle results satisfy the release condition; a lottery execution unit that, when it receives the limited lottery from the user terminal to which the execution authority has been granted, executes the limited lottery and outputs a lottery result from among the lottery targets which are pre-set targets of the lottery; and a storage unit that stores the battle results, the release condition, and the execution authority for each user.

[0008] A game provision system according to a second aspect of the present disclosure is a game provision system that provides a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a release condition is met, which is a condition for releasing the lottery, the game provision system comprising: a battle result acquisition unit that acquires battle results which are the result of a battle between the users; an authority granting unit that grants the user terminal the authority to execute the limited lottery when the battle results satisfy the release condition; a lottery execution unit that, when it receives the limited lottery from the user terminal to which the authority has been granted, executes the limited lottery and outputs a lottery result from among the lottery targets which are pre-set targets of the lottery; and a storage unit that stores the battle results, the release condition, and the authority for each user.

[0009] A third aspect of the present disclosure is a game provision method that provides a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a release condition is met, which is a condition for releasing the lottery, the method comprising: a battle result acquisition unit that acquires battle results which are the result of a battle between the users; an authority granting unit that grants the user terminal the authority to execute the limited lottery when the battle results satisfy the release condition; a lottery execution unit that, when it receives the limited lottery from the user terminal to which the authority has been granted, executes the limited lottery and outputs a lottery result from among the lottery targets which are pre-set targets of the lottery; and a storage unit that stores the battle results, the release condition, and the authority for each user.

[0010] A game provision program according to a fourth aspect of this disclosure is a game provision program that causes a computer to provide a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a release condition, which is a condition for releasing the lottery, is met, the program comprising: a battle result acquisition unit that acquires battle results which are the results of a battle between the users; an authority granting unit that grants the user terminal the authority to execute the limited lottery when the battle results satisfy the release condition; a lottery execution unit that, when it receives the limited lottery from the user terminal to which the authority has been granted, executes the limited lottery and outputs a lottery result from among the lottery targets which are pre-set targets of the lottery; and a storage unit that stores the battle results, the release condition, and the authority for each user. [Effects of the Invention]

[0011] This disclosure provides a new mechanism to improve user engagement in games. In particular, it aims to address issues such as decreased motivation due to inadequate rewards for winning in competitive content, and monotonous gameplay, thereby encouraging continued participation. [Brief explanation of the drawing]

[0012] [Figure 1] This diagram shows the overall configuration of the game system according to this embodiment. [Figure 2] This block diagram shows the functional configuration of game delivery server 100. [Figure 3] This flowchart shows an example of the limited lottery process for game server 100. [Figure 4] This is an example of the limited lottery screen 710 for game server 100. [Figure 5] This is an example of a user information table 810 that manages user information for game server 100. [Figure 6] This is an example of a match history table 820 that manages the match history of game server 100. [Figure 7]This is an example of an unlock condition table 830 that defines the conditions for unlocking the limited gacha on game server 100. [Figure 8] This is an example of a permission management table 840 that manages the gacha execution permissions granted to users of game server 100. [Figure 9] This is a block diagram showing a typical computer hardware configuration that can realize the game provision server and user terminal in this embodiment. [Modes for carrying out the invention]

[0013] The following describes in detail embodiments for carrying out the present invention. In this embodiment, a game system is described that grants the right to execute a special lottery (limited lottery, so-called limited gacha) based on the results of battles between users, but the present invention is not limited thereto.

[0014] Figure 1 is a diagram showing the overall configuration of the game provision system 1 according to this embodiment. As shown in Figure 1, the game provision system 1 mainly consists of a game provision server 100 that provides online game services and one or more user terminals 200 that users use to play games. The game provision server 100 and each user terminal 200 are connected to each other via a predetermined communication network so that they can communicate data with one another.

[0015] The communication network is a communication infrastructure for sending and receiving various information necessary for the progress of the game between the game provision server 100 and the user terminal 200. This communication network includes, for example, the Internet, dedicated lines, LAN (Local Area Network), WAN (Wide Area Network), mobile phone communication networks (e.g., 3G, 4G / LTE, 5G, etc.), Wi-Fi® networks, WiMAX® networks, or a network combining several of these. The communication network may be a wired communication system or a wireless communication system, and its specific form is not limited.

[0016] The user terminal 200 is an electronic device operated by a user, and has a client function for playing games. The user terminal 200 is any computer terminal having program execution functions and communication functions, such as smartphones, tablet terminals, personal computers (PCs), notebook PCs, portable dedicated game consoles, stationary game consoles, PDAs (Personal Digital Assistants), wearable terminals (e.g., smart watches, smart glasses, head-mounted displays), etc.

[0017] A dedicated application program (a so-called game app) for executing the game according to the present embodiment is pre-installed in the user terminal 200. By starting this application program, the user can communicate with the game providing server 100 and play the game. Alternatively, the user terminal 200 does not require a dedicated application program, and may be configured to access a web page provided from the game providing server 100 via a web browser and play the game as a browser game described in HTML5 or the like.

[0018] The user terminal 200 includes an input unit for receiving input from a user, and an output unit for outputting information such as a game screen. The input unit is, for example, a touch panel, physical buttons, a keyboard, a mouse, a game controller, a joystick, a microphone (for voice input), a camera (for image recognition), or the like. The output unit is, for example, a display screen such as a liquid crystal display (LCD) or an organic EL (OLED) display, a speaker, a headphone jack, a vibrator, or the like. The user terminal 200 has a function of transmitting user operation information received via the input unit to the game providing server 100, drawing a game screen on the display screen based on game data received from the game providing server 100, and outputting sound effects and BGM from a speaker.

[0019] The game providing server 100 is an information processing device that comprehensively manages the game service according to the present embodiment and provides the game service to user terminals 200. The game providing server 100 is managed and operated by a business operator that provides the game. The game providing server 100 may be physically configured by a single server computer, or may be configured as a distributed system in which a plurality of server computers operate in cooperation (e.g., a server cluster for load distribution, a cloud computing environment).

[0020] In addition, the game providing server 100 may be configured from a plurality of server groups logically or physically divided for each function. For example, an authentication server that performs user authentication and account management, a game logic server that processes main game logic, a database server that manages user data and game data, a matching server that performs matching processing for matches between users, a payment server that performs billing payment processing, a content delivery network (CDN) server that distributes static content (images, audio data, etc.) can cooperate with each other to realize the entire function as the game providing server 100.

[0021] Figure 2 is a block diagram showing the functional configuration of the game providing server 100. As shown in Figure 2, the game providing server 100 mainly includes a communication unit 110, a storage unit 120, and a processing unit 130.

[0022] The communication unit 110 is a communication interface for performing data communication with external devices such as a user terminal 200 via a communication network. The communication unit 110 is implemented by hardware such as a network interface card (NIC), wireless communication module, or modem, and driver software that implements a communication protocol such as TCP / IP. The communication unit 110 has the function of receiving various requests transmitted from the user terminal 200, such as user operation information, requests to participate in a match, and requests to execute a limited lottery, and outputting them to the processing unit 130. The communication unit 110 also has the function of transmitting the processing results from the processing unit 130, such as game progress data, match results, lottery results, and data necessary for drawing the game screen, to the user terminal 200.

[0023] The memory unit 120 is a storage device that stores programs for realizing various functions of the game provision server 100, as well as various data necessary for game operation. The memory unit 120 is composed of a combination of main memory such as ROM (Read Only Memory) and RAM (Random Access Memory), and auxiliary storage devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), and flash memory. The RAM is used as a work area when the processing unit 130 executes programs, and the HDD and SSD are used as persistent storage areas for programs and data.

[0024] The memory unit 120 stores an operating system for controlling the entire game provision server 100, as well as game programs for providing the game services according to this embodiment. The memory unit 120 also stores various databases necessary for game operation. These databases include, for example, user information, character information, item information, quest information, in-game currency information, battle history information, and lottery setting information that defines the targets and probabilities of the lottery (gacha). Particularly relevant to this embodiment, the memory unit 120 stores a user information table 810, a battle history table 820, an unlock condition table 830, and an access control table 840. The specific data structures of these tables will be described later.

[0025] The processing unit 130 is the central part that controls the operation of the entire game provision server 100 and is composed of one or more processors. The processing unit 130 is, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), or an electronic circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array) that implements these functions. The processing unit 130 reads and executes the game program stored in the memory unit 120, thereby realizing each functional block such as the battle result acquisition unit 131, the authorization granting unit 132, and the lottery execution unit 133, which will be described later.

[0026] Although Figure 2 only illustrates the main functional blocks of this embodiment, the processing unit 130 also implements various other functions necessary for providing the game. For example, it may include as functional blocks an authentication unit for authenticating user logins, a billing unit for managing the purchase and consumption of in-game currency, a game progress control unit for controlling the progress of game scenarios and quests, a matching unit for determining opponents, and a community management unit for providing chat functions between users.

[0027] Next, the main functional blocks of the processing unit 130 will be described. The battle result acquisition unit 131 has the function of acquiring the results of battles conducted between users. Here, "battle" broadly refers to competitive content in the game in which two or more users compete to determine superiority or inferiority. The forms of battles include various types, such as PvP (Player vs Player) where one user battles against another user, GvG (Guild vs Guild) where groups (guilds, clans, teams, etc.) to which users belong battle against each other, battle royale format in which multiple users fight together, and asynchronous battles (a format in which you battle against a defense party set up by another user).

[0028] The "match results" acquired by the match result acquisition unit 131 may include not only simple win / loss information (win, loss, draw), but also detailed information that allows for the determination of the user's performance in the match. The match results may include the number of wins, ranking, number of matches played, win rate, or specific performance within the match. For example, the score at the end of the match, changes in the ranking, the number of kills the user obtained and the amount of damage dealt, the number of consecutive wins and losses at the end of the match, the number of matches participated in, and information on the character and item configuration (deck information) used in the match may be acquired as match results. The match result acquisition unit 131 has the function of acquiring this information from notifications from the user terminal 200 or from the match processing logic executed on the server, and recording it in a predetermined data format in the match history table 820 of the storage unit 120.

[0029] Action achievements may take the form of, for example, "successfully executing a specific tactic (e.g., a quick attack to win within one minute of the start, or an endurance battle to win after surviving for a certain amount of time) a predetermined number of times," or "winning by restoring an ally's HP to a predetermined amount or more."

[0030] Furthermore, the achievements of the actions may take the form of, for example, "winning against a party that includes the character with the highest usage rate," or "winning using the character with the lowest usage rate."

[0031] The authorization granting unit 132 has the function of determining whether the match results obtained by the match result acquisition unit 131 satisfy predetermined release conditions, and granting execution rights to perform a specific lottery (limited lottery) to users who satisfy the conditions. This function is implemented as an information processing function that takes match result information and release condition information as input and generates execution rights information as output.

[0032] "Unlock conditions" are goals that users must achieve in order to be allowed to participate in limited-time draws, and are defined in the unlock condition table 830 of the memory unit 120. Unlock conditions are conditions related to battle performance and participation status, such as "winning 3 or more battles in a day," "ranking within the top 100 in the weekly battle rankings," "reaching a total of 50 battles," or "achieving 5 consecutive wins in battles." In addition, unlock conditions may have a set period during which the conditions must be met (achievement period). For example, this may include period settings such as "daily (resets every day)," "weekly (resets every week)," and "season (during a specific event period)."

[0033] "Execution permission" refers to information indicating a user's right to perform a limited lottery. This can be implemented as, for example, flag information linked to a user account, electronic ticket information with an expiration date, or permission information to access a specific gacha screen. The permission granting unit 132 has the function of generating this execution permission when it detects that the release conditions have been met, and recording it in the permission management table 840 of the storage unit 120 in association with the user ID.

[0034] The lottery execution unit 133 has the function of executing a lottery process in response to a user request and providing the result to the user. In particular, the lottery execution unit 133 in this embodiment has the function of managing the execution of limited lotteries. Specifically, when the lottery execution unit 133 receives a request to execute a limited lottery from a user terminal 200, it first refers to the authority management table 840 and has the function of verifying whether the requesting user has valid execution authority for the limited lottery.

[0035] If it is confirmed that execution privileges are valid, the lottery execution unit 133 executes the lottery process. The lottery process is the process of determining one or more lottery results from a pre-set list of lottery targets based on predetermined probabilities. The lottery targets are, for example, characters usable in the game, items (weapons, armor, accessories, etc.), equipment, skills, or materials for developing them. The lottery execution unit 133 determines the lottery results by generating random numbers or the like, using a lottery table that defines the lottery targets and their probability of being drawn.

[0036] Furthermore, the lottery execution unit 133 may have a function to change the probability of obtaining the lottery target or the content of the lottery target itself according to the stage in achieving the unlock conditions (for example, a high number of wins, a high ranking, etc.). It may also have a function to set a higher probability of obtaining a specific lottery target depending on the character used in the battle or the status of the organization to which the user belongs. After the lottery is executed, the lottery execution unit 133 has a function to reflect the information of the determined lottery result in the user's possession data and to transmit the result to the user terminal 200. It may also have a function to generate special animation data according to the battle result when a limited lottery is executed and to transmit it to the user terminal 200 along with the lottery result.

[0037] The lottery may be in the form of a "win against a higher-ranked opponent (or a gold star)" gacha that is linked to the opponent's assets (deck). When a user wins against a higher-ranked opponent (e.g., an opponent with a higher rank than themselves, or an opponent who possesses a specific rare character), the battle result acquisition unit 131 may analyze the opponent's deck information. The lottery execution unit 133 may automatically set the "characters used by the defeated opponent" as the target of the limited gacha's release (lineup) or the target of probability changes.

[0038] Next, an example of the configuration of the main data tables stored in the storage unit 120 will be described. These tables may be configured as relational database tables, or they may be managed in other types of databases such as KVS (Key-Value Store).

[0039] User Information Table 810 is a data table for managing the profile information of each user playing the game. This table has columns (fields) such as "User ID," "Username," "Level," "Paid Virtual Currency," "Free Virtual Currency," "Current Rank," and "Organization ID." "User ID" is an identifier that uniquely identifies each user and is the primary key of this table. "Username" is the name of the user displayed in the game. "Level" is an indicator of the user's progress in the game. "Virtual Currency" is the amount of in-game currency the user possesses, and "paid" virtual currency purchased with real money and "free" virtual currency obtained through gameplay are managed separately. "Current Rank" is information that indicates the user's rank or rating in competitive content such as PvP. "Organization ID" is an ID used to identify the organization, such as a guild or clan, to which the user belongs.

[0040] The battle history table 820 is a data table for recording historical information about individual battles played by a user. This table has columns such as "Battle ID," "User ID," "Battle Date and Time," "Battle Type," "Battle Result," "Score," "Deck Information Used," and "Winning Streak." "Battle ID" is an identifier that uniquely identifies each battle. "User ID" is the ID of the user who participated in that battle. "Battle Date and Time" is a timestamp indicating the date and time the battle ended. "Battle Type" is information indicating the category of the battle, such as individual battle or team battle. "Battle Result" is information indicating the result, such as win, loss, or draw. "Score" is the points the user earned in that battle. "Deck Information Used" is data indicating the combination of characters and items the user used in that battle, and is stored in JSON format or as a comma-separated string, for example, as a list of character IDs. "Winning Streak" is an integer value indicating the number of consecutive wins at the time of winning that battle.

[0041] The unlock condition table 830 is a master data table that defines the conditions for unlocking limited-time draws. This table has columns such as "Condition ID," "Condition Type," "Threshold," "Achievement Period Setting," and "Limited Draw ID to be Unlocked." The "Condition ID" is an identifier that uniquely identifies each unlock condition. The "Condition Type" is information that indicates the type of indicator used to determine the condition (e.g., "Number of Wins," "Ranking," "Number of Matches," etc.). The "Threshold" is a specific numerical value (e.g., 3 wins, 100th place) or rank (e.g., "Rank A") required to determine that the condition has been met. The "Achievement Period Setting" is information that indicates the aggregation period for the condition (e.g., "Daily," "Weekly"). The "Limited Draw ID to be Unlocked" is an ID that identifies the limited-time draw to which execution privileges are granted when the condition is met.

[0042] The permission management table 840 is a data table for managing the status of the privileges granted to each user to execute limited lotteries. This table has columns such as "Permission ID," "User ID," "Limited Lottery ID," "Grant Date and Time," "Expiration Date," and "Status." The "Permission ID" is an identifier that uniquely identifies each granted permission. The "User ID" and "Limited Lottery ID" are information that indicates which user has been granted which limited lottery privilege. The "Grant Date and Time" is a timestamp indicating the date and time the privilege was granted. The "Expiration Date and Time" is a timestamp indicating the date and time the privilege expires, after which the privilege becomes invalid. The "Status" is information that indicates the current status of the privilege (e.g., "Unused," "Used," "Expired").

[0043] Figure 3 is a flowchart showing an example of the limited lottery process of the game provision server 100. The limited lottery process is realized when the processing unit 130 of the game provision server 100 executes the game program stored in the storage unit 120.

[0044] This flow defines the process of granting specific users the authority to conduct limited draws based on the results of matches between users, and then executing the draws based on that authority.

[0045] In step S102, the battle result acquisition unit 131 of the processing unit 130 acquires the battle result, which is the result of a battle between users. This process starts when a user plays in-game battle content (e.g., PvP arena, ranked match, guild battle, etc.) using the user terminal 200 and the battle ends. Specifically, when the battle ends, a battle processing module (not shown) in the game provision server 100 determines the winner. Alternatively, the battle may proceed on the user terminal 200 side, and the result may be sent from the user terminal 200 to the game provision server 100.

[0046] The battle result acquisition unit 131 generates or receives battle result information that includes at least the user ID of each user who participated in the battle, the result of the battle (win, loss, draw, etc.), the date and time of the battle, and the type of battle (individual battle, team battle, etc.). Furthermore, the battle result information may also include information that shows the details of the battle, such as the battle score, the composition information of the characters and items used by the user in the battle (deck information), the action log during the battle, and the number of consecutive wins or losses. The battle result acquisition unit 131 associates this acquired battle result information with the user ID and records it as a new record in the battle history table 820 stored in the storage unit 120. This recording process is performed accurately and comprehensively because it is used later for determining the release conditions and adjusting the lottery parameters.

[0047] Next, in step S104, the authorization unit 132 of the processing unit 130 determines whether the match results obtained and recorded in step S102 satisfy the pre-set release conditions. The release conditions are trigger conditions for enabling the limited lottery to be executed, and their contents are defined in the release condition table 830 stored in the memory unit 120. The release condition table 830 stores a condition ID that uniquely identifies the condition, the type of condition (e.g., number of wins, ranking, number of matches), a threshold used to determine whether the condition has been met (e.g., 3 wins, rank A or higher), and the period for which the condition is to be aggregated (e.g., daily, weekly, season), etc., associated with the ID of the limited lottery to be released.

[0048] The authorization granting unit 132 refers to the match history table 820 and the user information table 810 based on the user ID of the user whose match has ended. For example, if the release condition is "win 3 matches daily", the authorization granting unit 132 searches the match history table 820 for the user ID and finds "win" records for the current day according to the server's system time, and counts the number of such records. If this count is equal to or greater than the threshold "3" defined in the release condition table 830, the authorization granting unit 132 determines that the release condition has been met and proceeds to step S106. If the condition is not met (NO), the authorization granting process in this flow is not performed, and the process proceeds to step S108.

[0049] In step S106, if it is determined that the release conditions have been met (S104: YES), the authorization granting unit 132 grants the user the authority to execute a specific limited lottery. Specifically, the authorization granting unit 132 adds a new record to the authorization management table 840 stored in the storage unit 120. This record records the authorization ID that identifies the authorization, the user ID of the user to whom the authorization is granted, the ID of the limited lottery that is permitted to be executed, the date and time (timestamp) when the authorization was granted, the expiration date indicating the period during which the authorization is valid, and the status of the authorization (e.g., "unused"). The expiration date is set based on the settings in the release conditions table 830, for example, "the end time of the achievement period (e.g., 23:59 on the current day)" or "24 hours after granting".

[0050] After granting execution privileges, the authorization granting unit 132 notifies the user's user terminal 200 via the communication unit 110 that privileges have been granted. This notification may be sent as a push notification to the game application, or it may be displayed as a dialog or message box shown when logging into the game. Upon receiving this notification, the user terminal 200 updates the display of the limited lottery screen 710. For example, it may change the execution button for the limited gacha, which was previously grayed out and unclickable, to an activated state where it can be clicked, or it may display an effect such as "Unlocking!". This allows the user to visually recognize that they have gained the right to perform the limited lottery.

[0051] In step S108, the lottery execution unit 133 of the processing unit 130 determines whether or not it has received a request to execute a limited lottery from the user terminal 200 of a user who has been granted execution privileges. When the user presses the activated execute button on the limited lottery screen 710 of the user terminal 200, the user terminal 200 sends an execution request containing the user's user ID and the ID of the limited lottery they wish to execute to the game provision server 100 via the network NW.

[0052] When the communication unit 110 of the game provision server 100 receives this execution request, the lottery execution unit 133 searches the authorization management table 840 using the user ID and limited lottery ID included in the request as keys. It then verifies whether a corresponding record exists, whether the "status" of that record is "unused", and whether the current server time is within the "expiration date" recorded in the record. If all of these conditions are met, the lottery execution unit 133 determines that it has received a legitimate execution request (YES) and proceeds to step S110. If a corresponding authorization record does not exist, has already been used, or has expired, it considers it an invalid request, sends an error response to the user terminal 200, and terminates the process (NO).

[0053] In step S110, the lottery execution unit 133, having received a legitimate execution request, executes a limited lottery. First, the lottery execution unit 133 updates the "status" of the corresponding record in the privilege management table 840 to "used," or temporarily changes it to a status such as "processing." This is an exclusive control measure to prevent multiple lotteries from being executed with the same privileges by a user repeatedly pressing a button in a short period of time.

[0054] Next, the lottery execution unit 133 reads a list of lottery targets (item pool) pre-set in the memory unit 120 and a probability table that defines the probability of each lottery target being drawn. Then, based on this probability table, it performs a lottery process using a random number generator to determine one or more lottery targets (characters, items, etc.) to be drawn. Since this lottery logic is executed on the server side, it is possible to prevent fraudulent operations by users.

[0055] In step S112, the lottery execution unit 133 outputs the lottery results determined in step S110 and completes the series of processes. Specifically, it performs an update process to add the determined lottery target data to the user's possession data (such as the list of owned characters and the list of owned items). After that, the lottery execution unit 133 generates lottery result information, including a list of acquired lottery targets, and transmits it to the user terminal 200 via the communication unit 110. The user terminal 200 receives this lottery result information and displays an animation in which a gacha capsule opens and characters or items appear from it, and finally presents the user with a list of acquired lottery targets. After confirming that all processes have been completed successfully, the lottery execution unit 133 definitively updates the status of the corresponding record in the authorization management table 840 to "used".

[0056] Thus, according to one embodiment of the present invention, for example, a user can first pay to win a player-versus-player (PvP) battle, and then pay again to participate in a limited lottery unlocked by winning the PvP battle, thereby gaining an even greater advantage in the game. This helps to prevent a diminished sense of superiority and return on investment for paying users, maintains their willingness to pay, and increases the number of participants in PvP battles.

[0057] Furthermore, according to one embodiment of the present invention, the match results used to determine the release conditions include the number of wins in the match, ranking, number of matches, win rate, or specific action records within the match. This process is mainly implemented in the release condition determination process of step S104.

[0058] If the unlock condition is based on the "number of wins," the authorization granting unit 132 extracts and aggregates the user's win records from the match history table 820 based on the achievement period defined in the unlock condition table 830 (e.g., daily, weekly). For example, if the condition is "10 wins in a week," the authorization granting unit 132 counts the number of "win" records recorded by the user during the period from the start date and time of the week to the current time, and determines whether that number is 10 or more.

[0059] If the unlock condition is based on "ranking," the authorization granting unit 132 refers to the value of the "current rank" field stored in the user information table 810. For example, if the condition is "rank is Gold or higher," it determines whether the user's current rank is Gold, Platinum, Master, or any other high rank. The ranking can be configured to be compiled and updated based on the match results of all users by a batch process that is executed periodically, and reflected in the user information table 810.

[0060] If the unlock condition is based on the "number of matches played," the authorization granting unit 132 counts the number of times the user has participated in matches, regardless of wins or losses. For example, if the condition is "play 50 matches during the period," the authorization granting unit 132 counts the number of all match records (including wins, losses, and draws) of the user recorded in the match history table 820 within the period specified in the unlock condition table 830 (e.g., during the event period), and determines whether that number is 50 or more. This makes it possible for even beginner users, for whom winning itself is difficult, to have a chance at the limited lottery by playing continuously.

[0061] Furthermore, according to one embodiment of the present invention, the authorization granting unit 132 grants execution privileges to users who have met the release conditions within a predetermined achievement period. This process is closely related to the determination process in step S104 and the authorization granting process in step S106.

[0062] When the authorization granting unit 132 makes the determination in step S104, it always refers to the "achievement period setting" defined in the release condition table 830. If the achievement period is "daily", the start time of the period is set to 0:00 on the server's system time and the end time to 23:59:59, and only the battle history within that range is included in the calculation. Similarly, if it is "weekly", the achievement period is from 0:00 on Monday to 23:59:59 on Sunday, and if it is "season", the achievement period is set from the separately defined season start date to the season end date. When this achievement period ends, the progress such as the number of wins and battles accumulated up to that point is reset, and the count starts again from zero in the next period.

[0063] Then, when granting execution privileges in step S106, the privilege granting unit 132 often links the "expiration date" set in the privilege management table 840 to this achievement period. For example, the expiration date of privileges granted by completing a daily mission is set to 23:59 on that day. This is expected to give users an incentive to "exercise their rights today" and encourage them to access the game again.

[0064] Furthermore, according to one embodiment of the present invention, the lottery execution unit 133 varies the probability of drawing a target item in accordance with the stage in which the release conditions are met. This process is mainly implemented in the limited lottery execution process of step S110.

[0065] Upon receiving a request from a user to execute a limited lottery, the lottery execution unit 133 evaluates the user's "achievement stage of the release condition" immediately before executing the lottery logic. The achievement stage is an indicator that shows not only whether or not the condition has been met, but also the degree to which it has been achieved. For example, if the release condition is a ranking, the achievement stage corresponds to the user's specific rank (S rank, A rank, B rank, etc.). If the release condition is the number of wins, the achievement stage corresponds to the specific number of wins (10 wins, 20 wins, 50 wins, etc.).

[0066] The lottery execution unit 133 dynamically selects or adjusts the applicable drop probability table according to the achievement stage. For example, the memory unit 120 has multiple probability tables pre-prepared, such as a probability table for rank S users (with a 5% drop rate for the highest rarity), a probability table for rank A users (with a 3% drop rate), and a probability table for rank B users (with a 1% drop rate). The lottery execution unit 133 obtains the user's current rank, reads the corresponding probability table, and uses it for the lottery process. Alternatively, the system may apply correction values ​​according to the achievement stage to the basic probability table to change the drop rate of a specific rarity in real time. This increases the likelihood that users who achieve higher results will receive better rewards, stimulating their desire to take on further challenges.

[0067] Furthermore, according to one embodiment of the present invention, the lottery execution unit 133 changes the contents (lineup) of the lottery targets according to the stage in which the release conditions are met. This process is also embodied in the limited lottery execution process of step S110.

[0068] In this embodiment, the lottery execution unit 133 changes the list of lottery targets itself, which is the population of the lottery, according to the user's achievement stage. For example, the memory unit 120 has different lottery target master tables for each achievement stage. Control is performed such that the list of targets for the limited lottery drawn by users with "Gold rank or higher" includes the limited character "X", but the list of targets for the limited lottery drawn by users with "Silver rank" does not include that character "X".

[0069] Alternatively, the type of limited-time gacha that can be drawn could differ depending on the level of achievement. For example, a user who wins 10 matches could be granted access to a "Bronze-only gacha," while a user who wins 50 matches could be granted access to a separate "Gold-only gacha." The "Gold-only gacha" could then feature more powerful and rarer items and characters not included in the "Bronze-only gacha." This would create a special reward pool accessible only to top achievers, strongly stimulating a sense of status among users.

[0070] Furthermore, according to one embodiment of the present invention, the target of the limited lottery is different from the target of the lottery offered in other lotteries (such as regular gacha). This differentiation is mainly achieved by the data structure of the storage unit 120 and the data referenced in the lottery execution process of step S110.

[0071] The memory unit 120 stores independent master tables for each type of lottery. For example, there are separate "item master tables for regular gacha," "item master tables for featured gacha," and "item master tables for limited gacha" according to this embodiment. The "item master tables for limited gacha" contain data on characters and items specifically for limited lotteries that are not registered in the other master tables.

[0072] In step S110, the lottery execution unit 133 performs the lottery process by referring only to the corresponding "Limited Gacha Item Master" and related probability tables based on the ID of the requested limited lottery. This creates a situation where the user can never obtain the lottery target exclusive to the limited lottery unless they achieve predetermined conditions in battle. This means that participation in the game and effort are directly linked to rare rewards, embodying the "Play to Win" philosophy.

[0073] Furthermore, according to one embodiment of the present invention, the lottery targets include characters or items that are usable in the game and are granted abilities that can give an advantage in the game. This process relates to how the lottery results obtained in step S112 affect subsequent gameplay. Abilities that can give an advantage in the game may include, for example, powerful attack power, useful enhancement buffs, powerful healing power, increased experience points gained, or increased item drop rates.

[0074] If a character or item with special abilities is drawn as a result of the lottery in step S110, the data for that character or item will be added to the user's possession data in step S112. This character or item data includes parameters that define special abilities, such as "attack power increases by 10% during PvP battles" or "movement speed increases by 5% on certain maps."

[0075] Subsequently, when a user engages in a battle, the battle processing module of the game server 100 reads information about the character and equipment items to be used from the user's owned data and reflects the parameters of the special abilities attached to them in the status calculation during the battle. As a result, users who have obtained powerful items through the limited lottery can proceed with subsequent battles more advantageously. This forms a positive feedback loop that increases user engagement: "Win a battle → Draw a limited lottery → Obtain more powerful items → Become even more likely to win battles."

[0076] Furthermore, according to one embodiment of the present invention, when the battle is a battle between individual users, the probability of drawing a target related to the character used in the battle is set to be higher. This process is a specific example of probability adjustment in the limited draw execution process of step S110.

[0077] In this embodiment, before performing the lottery execution, the lottery execution unit 133 obtains information about the characters used by the user in the match that triggered the granting of privileges, or in the most recent match. This information can be obtained from the "Deck Used" column of the match history table 820, etc. For example, suppose a user wins a match with a deck consisting of characters "A", "B", and "C", and obtains the right to participate in the limited lottery.

[0078] The lottery execution unit 133 reads the basic probability table and then dynamically increases the probability of obtaining lottery items related to the acquired characters "A", "B", and "C". Related lottery items include, for example, character "A" itself (for limit breaking), character "A"'s exclusive equipment, and character "A"'s training materials. The probability increase is achieved by multiplying the probability value of the relevant lottery item by a specific coefficient or by increasing the weighting in the probability calculation. This makes it easier for users to strengthen the characters they prefer to use, deepens their attachment to specific characters, and increases their motivation to aim for victory using those characters.

[0079] Furthermore, according to one embodiment of the present invention, when a battle is a battle between organizations (guilds, etc.) to which users belong, the probability of drawing a lottery target related to the in-game assets held by the organization or the user's position within the organization is set to be higher. This process is also an example of probability adjustment in step S110.

[0080] This scenario assumes that, as a result of winning a Guild vs. Guild (GvG) battle, the members of a guild are granted the authority to conduct a limited lottery. The lottery execution unit 133 retrieves the "Affiliated Guild ID" and the "Position" within the guild (e.g., Guild Master, Sub-Master, Regular Member) from the user information table 810 based on the user ID of the user conducting the lottery.

[0081] Furthermore, the lottery execution unit 133 uses the acquired organization ID as a key to refer to a separately managed organization information database (not shown) and obtains information on the "in-game assets" (e.g., specific castles, bases, resource production facilities) owned by that organization. It then sets a higher probability for the lottery items related to these roles and in-game assets. For example, if an organization owns a "Flame Castle," the probability of obtaining a special ore item that can only be produced in the "Flame Castle" from the limited lottery increases. Also, if the user's role is "Guild Master," the probability of obtaining special leader-oriented items, such as buff items that improve the overall capabilities of the guild, increases. This allows for increased motivation to contribute to the organization and a sense of belonging, not just as an individual.

[0082] Furthermore, according to one embodiment of the present invention, a method for displaying a visual effect corresponding to the match result when a limited lottery is performed is described. This process is mainly included in the information transmitted to the user terminal 200 in the lottery result output process in step S112.

[0083] After the lottery process is completed in step S110, in step S112, the lottery execution unit 133 generates "animation specification information" that specifies the animation to be displayed along with the lottery result information and sends it to the user terminal 200. This animation specification information is determined according to the user's battle results. For example, the lottery execution unit 133 refers to the battle history table 820 and obtains the user's most recent winning streak. If the winning streak is 10 or more, it determines the grade of the animation, such as "rainbow special gacha animation," if it is 5 or more, it determines the "gold gacha animation," and otherwise it determines the "normal gacha animation," and includes this specification information in the lottery result.

[0084] When the user terminal 200 receives lottery result information and animation specification information from the game server 100, it first plays the specified animation. For example, if a user who has won 10 consecutive times draws a gacha, a special animation is displayed in which the gacha machine's casing glows in rainbow colors and a congratulatory message "10 consecutive wins achieved!" appears in the background. The elaborate animation enhances the expectation of drawing a high-rarity item, maximizing the user's sense of accomplishment and excitement. After the animation finishes playing, the final acquired items are displayed.

[0085] Furthermore, according to one embodiment of the present invention, the limited lottery is carried out by consuming paid virtual currency as consideration. This process is performed at the beginning of the limited lottery execution process in step S110.

[0086] Upon receiving a valid execution request in step S108, the lottery execution unit 133 first performs billing processing before executing the lottery logic in step S110. If the cost of paid virtual currency required to execute the limited lottery is predefined, the lottery execution unit 133 refers to the user information table 810 using the user's user ID as the key and checks the value of the "Held Virtual Currency (Paid)" column.

[0087] If the balance of paid virtual currency held by the user falls below the cost required for the lottery, the lottery execution unit 133 interrupts the lottery process and sends an error message such as "Insufficient paid currency" to the user terminal 200. The user terminal 200 displays this message and, if necessary, guides the user to the virtual currency purchase screen. If the balance is sufficient, the lottery execution unit 133 performs an update process that subtracts the cost amount from the value of "Held virtual currency (paid)" in the user information table 810. This subtraction process is managed as a series of transactions with the subsequent lottery process, and if an error occurs during the lottery process, the subtraction process is also rolled back (canceled) to ensure that the currency is not consumed. This mechanism makes it possible to monetize the special experience of exercising rights obtained through battles.

[0088] Figure 4 shows an example of the limited lottery screen 710 of the game server 100. The limited lottery screen 710 is an example of a screen displayed in the "Gacha" menu within the game.

[0089] At the top of the limited lottery screen 710, a banner for the "Limited Gacha" is displayed. Here, advantages over the regular gacha are emphasized, such as "5x higher drop rate for featured characters!", designed to stimulate the user's gambling instincts. In addition, a large illustration of the featured character (e.g., the female knight) is displayed.

[0090] At the bottom center of the limited-time lottery screen 710, there are buttons for performing the gacha. The screen 710 displays both a "Single Gacha" button and a "Ten-Time Gacha" button. The important point here is the control over the display of these buttons based on the status of achieving the unlock conditions.

[0091] The state of the limited lottery screen 710 schematically indicates that the conditions have not been met (or that it is locked). A padlock icon or the message "Unlock conditions not met" is displayed above the button, and the button itself is grayed out (deactivated) and cannot be pressed. Alternatively, even if the button is pressed, only a hint such as "It will be unlocked after winning 3 matches today" is displayed, and the gacha is not executed.

[0092] On the other hand, once a user completes a match and meets the conditions (e.g., 3 wins), and is granted execution privileges, this screen display will change immediately or on the next access. Specifically, the padlock icon will disappear (or an unlocking animation will be displayed), and the button will change to a brighter color and become clickable (activated). In addition, effects and text such as "Unlocking!" and "2 hours remaining" will be displayed around the button to encourage the user to exercise their rights.

[0093] Furthermore, when executing the gacha on the limited lottery screen 710, an effect reflecting the results of the previous battle may be displayed. For example, when the button is pressed, a highlight scene from the battle the user won may be inserted as a cut-in in the background, or the color of the gacha machine's aura may change from blue to red to rainbow depending on the score at the time of victory.

[0094] Figure 5 shows an example of a user information table 810 that manages user information for the game provision server 100. The user information table 810 has a "User ID" as its primary key to uniquely identify a user, and includes items such as "User Name," "Level," "Amount of Virtual Currency Held (Paid / Free)," "Current Rank," and "Affiliated Organization ID."

[0095] "Owned Virtual Currency" manages the balance of in-game currency held by the user. Here, it is preferable to distinguish between "paid currency" purchased with actual money and "free currency" distributed for free through gameplay, etc. This is because limited-time gacha draws may be set to be playable with "paid currency only".

[0096] "Current Rank" indicates the user's rank (Gold, Bronze, etc.) in PvP and other battles. This rank information is used as a condition for unlocking limited-time gacha (e.g., unlocked at Gold rank or higher) and as a factor in affecting drop rates. "Affiliated Group ID" is an identifier for the guild or other group to which the user belongs. This is used for determining the outcome of GvG battles and for determining rewards related to the group.

[0097] Figure 6 shows an example of a match history table 820 that manages the match history of the game provision server 100. The match history table 820 stores items such as "User ID," "Match Date and Time," "Match Type" (individual match, team match, etc.), "Match Result" (win, loss, etc.), "Score," "Deck Information Used," and "Number of Consecutive Wins" associated with a "Match ID" that identifies each individual match.

[0098] The "Deck Used" field stores a list of character IDs ([C001, C005...] etc.) used by the user in that match. This "Deck Used" field is referenced in the process of "setting a higher drop rate for characters used." The "Winning Streak" field records the number of consecutive wins at the end of the match. This is used to determine unlock conditions such as "3 consecutive wins."

[0099] Figure 7 is an example of an unlock condition table 830 that defines the unlock conditions for the limited gacha on game server 100. The unlock condition table 830 defines the "condition type" (number of wins, rank, etc.), "threshold" (3 wins, rank A or higher, etc.), "achievement period setting" (daily, weekly, etc.), and "limited lottery ID to be unlocked" for each "condition ID".

[0100] For example, condition ID "CND001" indicates that the condition type is "Number of Wins," the threshold is "3 Wins," and the period is "Daily," and that fulfilling these conditions will unlock the limited gacha "LG001." The game server 100 refers to this table after each match to determine whether the user's match record meets the conditions.

[0101] Figure 8 shows an example of a permission management table 840 that manages the gacha execution privileges granted to users of the game provision server 100. The permission management table 840 records the "User ID", "Limited Lottery ID", "Grant Date and Time", "Expiration Date", and "Status" (unused, used, etc.) for each "Permission ID".

[0102] When the authorization granting unit 132 confirms that the conditions have been met, it adds a new record to this table. For example, it records that user "U001" has been granted the right to the limited gacha "LG001" and that its expiration date is "23:59 on the same day".

[0103] The lottery execution unit 133, upon receiving a gacha execution request, refers to this table and executes the lottery process only if a record exists for the target user and the target gacha, and if it is "within the expiration date" and its "status" is "unused". After execution, it updates the "status" to "used".

[0104] Figure 9 is a block diagram showing an example of the hardware configuration of a typical computer 900 that can realize the game provision server 100 and user terminal 200 in this embodiment. The computer 900 includes a control unit 901 which is a processor such as a CPU, a storage unit 902 which includes main memory such as RAM and ROM and auxiliary storage such as HDD and SSD, a communication unit 903 for connecting to a network, an input unit 904 for inputting data, and an output unit 905 for outputting data. These units are electrically connected to each other via a bus 910 which bundles an address bus, a data bus, a control bus, etc.

[0105] The control unit 901 comprehensively controls the operation of the entire computer 900 by reading and executing the operating system and various programs stored in the memory unit 902. The memory unit 902 stores programs executed by the control unit 901 and temporary data used during program execution. The communication unit 903 transmits and receives data to and from an external network. The input unit 904 receives instructions from users and administrators. The output unit 905 outputs processing results to a display, speaker, etc.

[0106] The game provision server 100 is built based on the architecture of the computer 900. In this case, the control unit 901 executes the game program stored in the memory unit 902, thereby realizing the aforementioned functions such as the battle result acquisition unit 131, the authorization granting unit 132, and the lottery execution unit 133 as software. Similarly, the user terminal 200 is also built based on the architecture of the computer 900, and the control unit 901 executes game applications, etc., to realize various functions as a game client.

[0107] (Other Example 1) In another embodiment, the lottery results may be such that the reward is upgraded based on a "handicap declaration". The game server 100 may accept handicap settings such as "win without a healer" or "start with 50% HP" from the user terminal 200 before the start of the match. The authorization unit 132 may determine whether the handicap was followed when the player wins. The lottery execution unit 133 may increase the "pickup rate" from 5 to 10 times, or discount the amount of paid currency consumed, depending on the difficulty coefficient of the handicap.

[0108] This eliminates the feeling of "work" for advanced players and provides a high-risk, high-reward competitive experience.

[0109] (Another example 2) In another embodiment, the expiration date may be affected by a "time decay" probability fluctuation. The authorization granting unit 132 may grant authorization immediately after the user's victory (e.g., 12:10). The lottery execution unit 133 may calculate the difference between the time the user attempts to perform the gacha and the "granting date and time". The game provision server 100 may dynamically control the probability curve so that the execution is performed while the excitement of victory is still fresh, such as "5% chance of getting the highest rarity if spun within 10 minutes of victory", "3% if within 1 hour", and "1% thereafter".

[0110] This allows for a countdown animation on the limited-time lottery screen 710, displaying "〇 minutes left until the probability drops!", which helps eliminate user hesitation and strongly encourages immediate payment and execution (consumption of paid currency).

[0111] (Other Example 3) In another embodiment, the unlock conditions may be based not only on winning or losing, but also on the user's play style in the match or the state of the in-game environment (meta).

[0112] In this case, the battle result acquisition unit 131 acquires detailed action logs during the battle and usage rate data of the characters used by the opponent as battle results. The authorization granting unit 132 determines that the unlock conditions have been met when a specific play style is achieved, such as "successfully executing a specific tactic (for example, a quick attack to win within one minute of the start, or an endurance match to win after enduring for a certain period of time) a predetermined number of times" or "winning by restoring an ally's HP to a predetermined amount or more".

[0113] Furthermore, the authorization unit 132 may refer to the character usage statistics (metadata) of all users stored in the memory unit 120 and determine whether conditions that are mindful of the game environment have been met, such as "winning against a party that includes the character with the highest usage rate" or "winning using the character with the lowest usage rate." This prevents monotonous gameplay focused solely on winning, promotes diversity in gameplay, and encourages the use of less popular characters.

[0114] (Other example 4) In other embodiments, the granting of execution rights may be based on the fragmentation of rights (ticket system) or on user choice.

[0115] The authorization granting unit 132 may grant the user "fragments of limited lottery tickets (fragment data)" each time the unlocking condition (e.g., 1 win) is met, instead of granting the user the authority to immediately execute a limited lottery. The user can perform one limited lottery by collecting a predetermined number of these fragments (e.g., 10 fragments). This allows for setting goals that cannot be achieved with a single win, encouraging the user to continue playing.

[0116] Furthermore, the authorization granting unit 132 may present a selection screen to the user terminal 200 when the conditions are met and grant permissions based on the user's selection input. Specifically, it may present options with different risks and rewards, such as "one limited gacha ticket that can be obtained with certainty" or "three limited gacha tickets that can be obtained with a 50% probability (zero if unsuccessful)." This can add a gamified element to the reward acquisition process itself, increasing user excitement.

[0117] (Other example 5) In another embodiment, the prizes for the limited draw may include items that affect the opponent, limited cosmetic data, or the right to unlock content.

[0118] The lottery execution unit 133 may include consumable items that directly affect the next battle, such as "reducing the attack power of the next opponent," as targets for the limited lottery. This allows the battle and gacha cycles to be more closely linked. The lottery execution unit 133 may also dispense "limited skins (appearance change data)" that do not affect the character's stats. This allows users to satisfy their need for recognition and self-expression without disrupting the game balance.

[0119] Furthermore, the lottery execution unit 133 may also include flags granting access to new game content, such as "the right to view special story episodes" or "the right to challenge high-difficulty bosses," as targets for the lottery, in addition to item data. This allows winning a battle to lead not only to acquiring items but also to experiences that expand the game's world, thereby improving user loyalty.

[0120] <Note> (Note 1) A game provider server that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by a user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. For each user, a storage unit stores the match results, the release conditions, and the execution rights. A game server equipped with the necessary features.

[0121] (Note 2) The aforementioned match results include the number of wins, ranking, number of matches, win rate, or actions taken within the match, as defined in Appendix 1 of the game provider server.

[0122] (Note 3) The aforementioned authorization granting unit grants the execution rights to the user terminal associated with the user who has met the release conditions within a predetermined achievement period, which is a game provision server as described in either Appendix 1 or 2.

[0123] (Note 4) The aforementioned lottery execution unit is a game provision server as described in any of Appendix 1 to 3, which changes the probability of drawing the lottery target according to the stage in which the release conditions are achieved. (Note 5) The lottery execution unit is a game provision server according to any one of the appendices 1 to 4, which changes the content of the lottery target according to the stage in which the release conditions are achieved.

[0124] (Note 6) The target of the lottery is the game provider server described in Appendix 1, which is different from the target of the lottery provided in other lotteries.

[0125] (Note 7) The subject of the lottery is a game provider server as described in any of Appendix 1 to 6, which includes characters or items that can be used in the game and are granted abilities that can give an advantage in the game.

[0126] (Note 8) The game server according to any one of the appendices 1 to 7, wherein the aforementioned battle is a battle between individual users, and the lottery execution unit sets a high probability for the lottery target related to the character used by the user in the battle.

[0127] (Note 9) A game provider server as described in any of Appendix 1 to 8, wherein the aforementioned match is between organizations to which the user belongs, and the lottery execution unit sets a high probability for the lottery target related to in-game assets owned by the organization or the user's position within the organization.

[0128] (Note 10) The aforementioned lottery execution unit is a game provision server as described in any of Appendix 1 to 9, which displays a visual effect corresponding to the match result when the limited lottery is executed.

[0129] (Note 11) The aforementioned limited lottery is conducted by a game provider server as described in any of the appendices 1 to 10, using paid virtual currency as payment.

[0130] (Note 12) The aforementioned unlocking condition includes the user defeating another user who is of a higher rank in the aforementioned match between users. The battle result acquisition unit analyzes the deck information used by the other user in the battle, The game provider server according to any one of the appendices 1 to 11, wherein the lottery execution unit, when it wins against the other user who is of a higher rank in the match, changes the contents of the lottery target to at least one of the characters included in the other user's deck information.

[0131] (Note 13) A game provision system that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by the user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. For each user, a storage unit stores the match results, the release conditions, and the execution rights. A game delivery system equipped with the following features.

[0132] (Note 14) A game provision method that provides a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a computer meets the conditions for releasing the lottery, the conditions for releasing the lottery which is A match result acquisition step, which acquires the match result, which is the result of the match between the aforementioned users, If the aforementioned match result satisfies the aforementioned release conditions, the user terminal is granted the authority to execute the aforementioned limited lottery; When the user terminal to which the execution rights have been granted accepts the limited lottery, the lottery execution step includes executing the limited lottery and selecting the lottery result from among the lottery targets which have been set in advance, For each user, a storage step is provided to store the match results, the release conditions, and the execution rights. Sharp's method of providing games.

[0133] (Note 15) A game provision program that causes a computer to provide a game to a user terminal used by a user of the game, the game having a limited lottery which is released when the conditions for releasing the lottery are met, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. A game provision program characterized by comprising a storage unit for storing the match results, the unlock conditions, and the execution rights for each user. [Explanation of Symbols]

[0134] 1 Game provision system, 100 Game provision server, 110, 903 Communication unit, 120, 902 Memory unit, 130 Processing unit, 131 Match result acquisition unit, 132 Authorization unit, 133 Lottery execution unit, 200 User terminal, 710 Limited lottery screen, 810 User information table, 820 Match history table, 830 Release condition table, 840 Authorization management table, 900 Computer, 901 Control unit, 904 Input unit, 905 Output unit, 910 Bus

Claims

1. A game provider server that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by a user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. Each of the aforementioned users is provided with a storage unit that stores the match results, the release conditions, and the execution rights, The aforementioned match is between organizations to which the user belongs, and the lottery execution unit sets a high probability for the lottery target related to the in-game assets owned by the organization or the user's position within the organization. Game server.

2. A game provider server that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by a user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. Each of the aforementioned users is provided with a storage unit that stores the match results, the release conditions, and the execution rights, The aforementioned unlocking condition includes the user defeating another user who is of a higher rank in the aforementioned match between users. The aforementioned battle result acquisition unit analyzes the deck information used by the other user in the battle, The lottery execution unit, upon defeating the other user who is of higher rank in the match, changes the contents of the lottery target to at least one of the characters included in the other user's deck information. Game server.

3. The game server according to claim 1 or 2, wherein the match results include the number of wins, ranking, number of matches, win rate, or specific action record within the match.

4. The game provision server according to claim 1 or 2, wherein the authorization granting unit grants the execution authority to the user terminal associated with the user who has fulfilled the release conditions within a predetermined achievement period.

5. The game provider server according to claim 1 or 2, wherein the lottery target is different from the lottery target provided in other lotteries different from the limited lottery.

6. The game server according to claim 1 or 2, wherein the target of the lottery includes characters or items that can be used in the game and are granted abilities that can give an advantage in the game.

7. The game provision server according to claim 1 or 2, wherein the match is a match between individual users, and the lottery execution unit sets a high probability for the lottery target related to the character used by the user in the match.

8. The game provision server according to claim 1 or 2, wherein the lottery execution unit displays a visual effect corresponding to the match result when the limited lottery is executed.

9. The game provider server according to claim 1 or 2, wherein the aforementioned limited lottery is performed by consuming paid virtual currency as consideration.

10. A game provision system that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by the user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. Each of the aforementioned users is provided with a storage unit that stores the match results, the release conditions, and the execution rights, The aforementioned match is between organizations to which the user belongs, and the lottery execution unit sets a high probability for the lottery target related to the in-game assets owned by the organization or the user's position within the organization. Game delivery system.

11. A game provision method that provides a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a computer meets the conditions for releasing the lottery, the conditions for releasing the lottery which is The steps include obtaining the match results, which are the results of the match between the aforementioned users, If the result of the aforementioned battle satisfies the unlocking conditions, the user terminal is granted the authority to execute the limited lottery; When the user terminal to which the execution rights have been granted accepts the limited lottery, the limited lottery is executed, and the lottery results are extracted from the lottery targets which have been set in advance. The step includes storing the match results, the release conditions, and the execution rights for each user, The match is between organizations to which the user belongs, and the step of performing the lottery includes setting a high probability for the lottery target related to the in-game assets owned by the organization or the user's position within the organization. How to provide the game.

12. A game provision program that causes a computer to provide a game to a user terminal used by a user of the game, the game having a limited lottery which is released when the conditions for releasing the lottery are met, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. The computer is characterized by functioning as a memory unit that stores the match results, the release conditions, and the execution rights for each user. The aforementioned match is between organizations to which the user belongs, and the lottery execution unit sets a high probability for the lottery target related to the in-game assets owned by the organization or the user's position within the organization. Game provision program.

13. A game provision system that provides a game, which includes a limited lottery that is unlocked when the conditions for unlocking the lottery are met, to a user terminal used by the user of the game, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. Each of the aforementioned users is provided with a storage unit that stores the match results, the release conditions, and the execution rights, The aforementioned unlocking condition includes the user defeating another user who is of a higher rank in the aforementioned match between users. The aforementioned battle result acquisition unit analyzes the deck information used by the other user in the battle, The lottery execution unit, upon defeating the other user who is of higher rank in the match, changes the contents of the lottery target to at least one of the characters included in the other user's deck information. Game delivery system.

14. A game provision method that provides a game to a user terminal used by a user of the game, the game having a limited lottery which is released when a computer meets the conditions for releasing the lottery, the conditions for releasing the lottery which is The steps include obtaining the match results, which are the results of the match between the aforementioned users, If the result of the aforementioned battle satisfies the unlocking conditions, the user terminal is granted the authority to execute the limited lottery; When the user terminal to which the execution rights have been granted accepts the limited lottery, the limited lottery is executed, and the lottery results are extracted from the lottery targets which have been set in advance. The step includes storing the match results, the release conditions, and the execution rights for each user, The aforementioned unlocking condition includes the user defeating another user who is of a higher rank in the aforementioned match between users. The step of obtaining the match results involves analyzing the deck information used by the other user in the match, The step of performing the lottery involves, if the user wins against the other user who is of higher rank in the match, changing the contents of the lottery target to at least one of the characters included in the other user's deck information. How to provide the game.

15. A game provision program that causes a computer to provide a game to a user terminal used by a user of the game, the game having a limited lottery which is released when the conditions for releasing the lottery are met, A match result acquisition unit that acquires the match result, which is the result of the match between the aforementioned users, A power granting unit grants the user terminal the authority to execute the limited lottery if the match result satisfies the release conditions, A lottery execution unit, upon receiving the limited lottery request from the user terminal to which the execution rights have been granted, executes the limited lottery and outputs the lottery result from among the lottery targets that have been set in advance. The computer is characterized by functioning as a memory unit that stores the match results, the release conditions, and the execution rights for each user. The aforementioned unlocking condition includes the user defeating another user who is of a higher rank in the aforementioned match between users. The aforementioned battle result acquisition unit analyzes the deck information used by the other user in the battle, The lottery execution unit, upon defeating the other user who is of higher rank in the match, changes the contents of the lottery target to at least one of the characters included in the other user's deck information. Game provision program.

Images