Game server, lottery execution method, and computer program

Abstract

To provide a game server, a privilege imparting method, and a computer program which improve a motivation causing a user to keep playing a game.SOLUTION: A game server 110 according to an embodiment comprises: a providing unit 1131 which executes a lottery by consuming game media owned by a user and provides the user with one of game media of a plurality of types by the lottery; a storage unit 116 which stores the number of first game media provided to the user by the lottery; and a stop unit 1133 which stops the execution of the lottery in a case where the number of the provided first game media stored in the storage unit 116 amounts to a predetermined number.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a game server, a lottery execution method, and a computer program. [Background technology]

[0002] Mobile games and blockchain games are known that have a function that provides users with one of multiple game media, such as characters or items, by lottery. The multiple game media provided to users by lottery have a lottery probability that corresponds to, for example, rarity. Such a lottery method for obtaining game media is one factor that increases users' motivation to enter a lottery to obtain rare game media. [Prior art documents] [Patent documents]

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

[0004] For example, by limiting the number of specific game media or the period during which they can be acquired, users will likely try to acquire the specific game media before other users and will be more motivated to enter the lottery.

[0005] The present invention has been made in consideration of the above circumstances, and aims to provide a game server, a lottery holding method, and a computer program that will increase users' motivation to participate in the lottery. [Means for solving the problem]

[0006] A game server according to a first aspect of the present invention comprises a provision unit that executes a lottery by consuming a game medium owned by a user and provides the user with one of multiple types of game medium through the lottery, a memory unit that stores the number of first game media provided to the user through the lottery, and a cancellation unit that cancels the execution of the lottery when the number of games provided stored in the memory unit reaches a predetermined number.

[0007] A game server according to a second aspect of the present invention comprises a provision unit that executes a lottery by consuming a game medium owned by a user and provides the user with one of multiple types of game medium through the lottery, a memory unit that stores the number of first game media provided to the user through the lottery, and a stop unit that, when the number of games provided stored in the memory unit reaches a predetermined number, stops the provision of the first game medium through the lottery, making the multiple types of game media excluding the first game medium the subject of provision through the lottery.

[0008] A lottery execution method according to a third aspect of the present invention is a method of executing a lottery by consuming a game medium owned by a user, providing one of multiple types of game medium to the user through the lottery, storing the number of first game media provided to the user through the lottery in a memory unit, and terminating the execution of the lottery when the number of games provided stored in the memory unit reaches a predetermined number.

[0009] A fourth aspect of the present invention is a method for conducting a lottery by consuming a game medium owned by a user, providing one of multiple types of game medium to the user through the lottery, storing the number of first game media provided to the user through the lottery in a memory unit, and when the number of games provided stored in the memory unit reaches a predetermined number, stopping the provision of the first game medium through the lottery, with multiple types of game media excluding the first game medium being subject to provision through the lottery. A computer program according to a fifth aspect of the present invention causes a computer to execute the lottery holding method according to the third or fourth aspect. [Effects of the Invention]

[0010] According to the present invention, it is possible to provide a game server, a lottery holding method, and a computer program that increase users' motivation to participate in lotteries. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram schematically illustrating an example of the configuration of a game system and network including a game server according to an embodiment. [Figure 2] FIG. 2 is a block diagram schematically showing an example of the configuration of the game system of the first embodiment. [Figure 3] FIG. 3 is a diagram showing an example of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. [Figure 4] FIG. 4 is a diagram showing an example of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. [Figure 5] FIG. 5 is a diagram showing an example of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. [Figure 6] FIG. 6 is a flowchart illustrating an example of the operation of the game server of one embodiment when conducting a lottery. [Figure 7] FIG. 7 is a diagram showing an example of a display on a user terminal that executes a lottery in a game provided by a game server of an embodiment. [Figure 8] FIG. 8 is a diagram showing an example of a display on a user terminal that executes a lottery in a game provided by a game server of an embodiment. [Figure 9] FIG. 9 is a diagram showing an example of a display on a user terminal that executes a lottery in a game provided by a game server of an embodiment. [Figure 10] FIG. 10 is a diagram showing an example of a display on a user terminal that executes a lottery in a game provided by a game server of an embodiment. [Figure 11]FIG. 11 is a block diagram schematically showing an example of the configuration of a game system according to the second embodiment. [Figure 12] FIG. 12 is a flowchart illustrating an example of the operation of the game server of one embodiment when performing a lottery. [Figure 13] FIG. 13 is a diagram showing an example of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] An example of a game server, a lottery execution method, and a computer program according to an embodiment of the present invention will be described in detail below with reference to the drawings. Note that in the following description, configurations and elements that are the same as or similar to configurations that have already been described will be assigned the same reference numerals and descriptions thereof will be omitted.

[0013] FIG. 1 is a diagram schematically illustrating an example of the configuration of a game system and network including a game server according to an embodiment. The game system 100 of this embodiment is, for example, a system for operating and managing a game using a blockchain. Note that the game system 100 is not limited to a system for operating and managing a blockchain game, but can also be applied to a system for managing and operating a game distributed from a game server.

[0014] The game system 100 is communicatively connected to a plurality of user terminals 200, a CEX (Centralized Exchange) 300, a DEX (Decentralized Exchange) 400, a marketplace 500, an NFT server 600, and an administrator terminal 700 via a network.

[0015] CEX300 is a cryptocurrency exchange operated by a specific company. In this embodiment, CEX300 transfers cryptocurrency information to the game system 100 in response to a request from the game system 100. Examples of CEX300 include Coincheck (registered trademark), bitFlyer (registered trademark), and BITPOINT (registered trademark). CEX300 is also capable of conducting cryptocurrency transactions with the user terminal 200, and can transfer cryptocurrency information to the user terminal 200 in response to a request from the user terminal 200.

[0016] DEX400 is a cryptocurrency exchange that does not have an operating company and that automatically realizes the exchange of cryptocurrencies and tokens using smart contracts. In this embodiment, DEX400 transfers cryptocurrency information to the game system 100 in response to a request from the game system 100. Examples of DEX400 include Uniswap (registered trademark) and PancakeSwap (registered trademark). In addition, DEX400 is also capable of conducting cryptocurrency transactions with the user terminal 200, and can transfer cryptocurrency and token information to the user terminal 200 in response to a request from the user terminal 200.

[0017] The user terminal 200, for example, comprises at least one processor and a memory in which a program executed by the processor is recorded, and is configured to be able to realize various functions by software or a combination of software and hardware.

[0018] The user terminal 200 is an electronic device such as a computer, and may be, for example, a television receiver (including an Internet television), a PC (Personal Computer), a mobile terminal (for example, a tablet, a smartphone, a laptop, a feature phone, a digital music player, an e-book reader, a smartwatch, etc.), a game device (a home game console, a portable game console), a VR (Virtual Reality) terminal, an AR (Augmented Reality) terminal, etc., but is not limited to these. Note that the number of user terminals 200 connected to the network may be zero, or may increase or decrease at any time.

[0019] In this embodiment, the user terminal 200 is, for example, a smartphone, and is able to run a blockchain game provided by the game system 100 by downloading and installing a blockchain-based game application provided by the game system 100. Alternatively, the user terminal 200 may be, for example, a smartphone, and be able to run a blockchain game provided by the game system 100 on a browser without downloading and installing a blockchain-based game application provided by the game system 100.

[0020] The administrator terminal 700, for example, has at least one processor and a memory in which programs executed by the processor are recorded, and is configured to be able to realize various functions by software or a combination of software and hardware.

[0021] The administrator terminal 700 may be an electronic device such as a computer, and may be, for example, a television set (including Internet television), a PC (Personal Computer), a mobile terminal (for example, a tablet, smartphone, laptop, feature phone, digital music player, e-book reader, smart watch, etc.), a gaming device (home gaming console, portable gaming console), a VR (Virtual Reality) terminal, an AR (Augmented Reality) terminal, etc., but is not limited to these.

[0022] In this embodiment, the administrator terminal 700 is, for example, a PC, and information is input by an operation of a game administrator who manages the game provided by the game system 100, and the administrator terminal 700 exchanges information with the game server 110 and the settlement server 120, and can perform various settings (event settings, pre-event settings, lottery settings, etc.) and management of the game using the blockchain provided by the game server 110. Note that multiple administrator terminals 700 may be connected to a network, and each may communicate with the game server 110 and the settlement server 120.

[0023] The NFT server 600 is a server that converts images (still images and videos), audio, and other types of digital files into NFTs (converts them into NFTs) by recording them on a blockchain (distributed ledger) as unique, non-fungible data units (blocks). For example, the NFT server 600 can convert in-game assets in the game server 110 into NFTs upon request and provide the in-game assets converted into NFTs to users.

[0024] The NFT server 600, for example, has at least one processor and memory on which programs executed by the processor are recorded, and is configured to be able to realize various functions by software or a combination of software and hardware.

[0025] The storage unit (including memory) of the NFT server 600 comprises, for example, a main storage unit and an auxiliary storage unit. The main storage unit may include, for example, a ROM (read-only memory) and a RAM (random-access memory). ROM is a non-volatile memory used exclusively for reading data, and can store data and various setting values ​​used by the processor when performing various processes. RAM can also be used as a so-called work area for temporarily storing data when the processor of the NFT server 600 performs various processes. The main storage unit in this embodiment is, for example, a RAM.

[0026] The secondary storage unit of the NFT server 600 is a non-transitory computer-readable storage medium of a processor-based computer. The secondary storage unit is, for example, an EEPROM (registered trademark) (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive).

[0027] The auxiliary memory unit of the NFT server 600 can store data, programs, data generated by processing in the processor, various setting values, etc. used by the processor when performing various processes.

[0028] The processor of the NFT server 600 is typically a CPU (Central Processing Unit) and / or a GPU (Graphics Processing Unit), but may also be a microcontroller, FPGA (Field Programmable Gate Array), or DSP (Digital Signal Processor), etc.

[0029] The processor of the NFT server 600 can realize various functions of the NFT server by executing programs such as system software, application software, or firmware stored in the memory unit.

[0030] The processor of the NFT server 600 includes an NFT processing unit. The NFT processing unit receives an NFT request signal from, for example, the processor 111 included in the game server 110. The NFT processing unit uses the digital data of the in-game assets, information about the creator of the digital data, and information about the owner of the digital data, which are included in the NFT request signal from the game server 110, to generate a distributed ledger (blockchain) in which the in-game assets to be converted into NFTs are unique, non-fungible data units. Note that the NFT processing of the in-game assets by the NFT processing unit can use existing methods.

[0031] After the NFT conversion process is completed, the NFT processing unit outputs an NFT conversion process completion notification to the processor 111 via the network. The NFT conversion process completion notification may include information such as information about the creator of the NFT, information about the owner of the NFT, identification information (identifier) ​​of the in-game asset that has been NFTed, and the date and time when the NFT conversion was completed. The NFT processing unit transmits data about the in-game asset for which the NFT conversion process has been completed to the user terminal 200 (or to the user terminal 200 via the game server 110) via the network.

[0032] The marketplace 500 is an online platform where digital assets utilizing NFTs (Non-Fungible Tokens) can be bought, sold, and exchanged. A user operating the user terminal 200 can convert in-game assets owned by the game system 100 into NFTs through processing described below, thereby enabling the user to sell the NFT-converted in-game assets on the marketplace 500. The user can also purchase digital assets being sold on the marketplace 500. Examples of the marketplace 500 include TofuNFT (registered trademark) and OpenSea (registered trademark). In addition, at least one of the NFT server 600, the marketplace 500, and the administrator terminal 700 may be included in the game system 100.

[0033] The game system 100 of this embodiment includes a game server 110 and a payment server 120. The game server 110 and the payment server 120 are connected to each other via a network so that they can communicate with each other.

[0034] The settlement server 120 is a server that performs settlement processing associated with buying and selling transactions via a network. For example, when a user purchases game media (in-game currency, items, tickets, etc.) sold by the game server 110, the settlement server 120 performs settlement of the necessary amount between the user terminal 200 and the game server 110.

[0035] The game server 110 is a server that provides a game using a blockchain (a blockchain game, hereinafter sometimes simply referred to as a game) that can be played on the user terminal 200. The game server 110 has a function to sell game media (e.g., in-game currency such as paid stones) using crypto assets, and a function to sell game media (e.g., in-game currency) using legal tender (e.g., Japanese yen, dollars, etc.).

[0036] The game server 110 manages the value of game media (in-game assets, tickets, items, etc., in-game currency) purchased by users using crypto assets. Note that the game media in this embodiment include at least in-game assets (for example, characters, items usable in the game, weapons and equipment that can be worn by characters, cards for generating character skills, etc.) and in-game currency (for example, paid stones, unpaid stones, etc.).

[0037] In this embodiment, the game server 110 can handle multiple types of tokens as crypto assets. In a blockchain game provided by the game server 110, for example, the game content that can be purchased with one of the multiple types of crypto assets may be different from the game content that can be purchased with other of the multiple types of crypto assets, and some of the multiple types of crypto assets may be usable for all purposes, while others may be usable only for specific purposes.

[0038] Next, an example of the configuration of the payment server 120 and the game server 110 included in the game system 100 shown in FIG. 1 will be described. FIG. 2 is a block diagram schematically showing an example of the configuration of the game system of the first embodiment. The payment server 120 includes, for example, at least one processor 121 and a memory storing a program executed by the processor 121, and is configured to be able to realize various functions by software or a combination of software and hardware. The payment server 120 may include multiple server devices and function as one virtual server device.

[0039] The payment server 120 includes a processor 121 , a storage unit 123 , an input unit 124 , an output unit 125 , and a communication unit 126 . The input unit 124 is operated by an administrator of the payment server 120 and may include a user interface such as a mouse or keyboard for inputting various information (for example, information for changing the numerical values ​​of various settings of the payment server 120), and various sensors such as a microphone or touch panel.

[0040] The output unit 125 includes, for example, a monitor that visually presents information to the administrator of the payment server 120. The output unit 125 may also include an audio output means, such as a speaker, that audibly supplies information to the administrator of the payment server 120.

[0041] The communication unit 126 can transmit information received from the outside to the components within the payment server 120, and can also transmit information received from the components within the payment server 120 to the outside. The communication unit 126 can be connected to the game server 110, the user terminal 200, the administrator terminal 700, etc., via a network such as the Internet, so as to be able to communicate with them.

[0042] The storage unit (including memory) 123 of the payment server 120 includes, for example, a main storage unit and an auxiliary storage unit. The main storage unit may include, for example, a read-only memory (ROM) and a random-access memory (RAM). The ROM is a non-volatile memory used exclusively for reading data, and can store data and various setting values ​​used by the processor when performing various processes. The RAM may be used as a so-called work area for temporarily storing data when the processor performs various processes. The main storage unit in this embodiment is, for example, a RAM.

[0043] The secondary storage unit of the payment server 120 is a non-transitory computer-readable storage medium of a processor-based computer. The secondary storage unit is, for example, an EEPROM (registered trademark) (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive).

[0044] The auxiliary storage unit of the payment server 120 can store, for example, data used by the processor when performing various processes, programs, data generated by the processor's processing, various setting values, etc. The auxiliary storage unit may also store information necessary for personal authentication when the processor performs payment processing, and personal information such as credit card numbers and account information (legal tender account information, cryptocurrency account information, etc.). For example, information used for personal authentication and personal account information may be stored in an external database accessible by the payment server 120.

[0045] The processor 121 of the payment server 120 is typically a CPU (Central Processing Unit) and / or GPU (Graphics Processing Unit), but may also be a microcomputer, FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), etc. The processor 121 of the payment server 120 can realize various functions of the payment server 120 by executing programs such as system software, application software, or firmware stored in the storage unit 123.

[0046] The processor 121 of the payment server 120 includes a payment processing unit 122. The payment processing unit 122 acquires payment information from the sales unit 112 of the game server 110, which will be described later, via a network. The payment information may include, for example, cryptocurrency remittance information from the user terminal 200 (including payment amount information), information for the user using the user terminal 200 to make a payment (credit card information, legal tender account information, cryptocurrency account information, etc.), and identification information for identifying the user.

[0047] The payment processing unit 122 of the payment server 120 uses the payment information to perform the requested payment process. The payment processing unit 122 can use a commonly known method. That is, the payment processing unit 122 performs payment processing for the amount specified by the payment method specified by the user (credit card, account transfer using legal tender, account transfer using cryptocurrency, etc.). After completing the payment processing, the payment processing unit 122 transmits a payment completion notice to the sales unit 112 via the network. The payment completion notice includes information such as the identifiers of the user and game server 110 (or the game administrator of the game server 110) who performed the payment transaction, the payment amount, and the date and time of the payment.

[0048] The game server 110 includes, for example, at least one processor and a memory in which a program executed by the processor is recorded, and is configured to be able to realize various functions by software or a combination of software and hardware. The game server 110 may include multiple server devices and function as a single virtual server device.

[0049] In this embodiment, the game server 110 includes a processor 111, a storage unit 116, an input unit 117, an output unit 118, and a communication unit 119. The processor 111, the storage unit 116, the input unit 117, the output unit 118, and the communication unit 119 are connected to each other via a bus communication line and can transmit and receive data between them. Note that the processor 111, the storage unit 116, the input unit 117, the output unit 118, and the communication unit 119 may also be configured to transmit and receive data between them via wireless communication or the like.

[0050] The input unit 117 is operated by an administrator of the game server 110 and may include a user interface such as a mouse or keyboard for inputting various information (for example, information for changing the numerical values ​​of various settings of the game server 110), and various sensors such as a microphone or touch panel.

[0051] The output unit 118 includes, for example, a monitor that visually presents information to the administrator of the game server 110. The output unit 118 may also include audio output means, such as a speaker, that audibly supplies information to the administrator of the game server 110.

[0052] The communication unit 119 can transmit information received from the outside to the components within the game server 110, and can also transmit information received from the components within the game server 110 to the outside. The communication unit 119 is communicatively connected to the payment server 120, user terminal 200, CEX 300, DEX 400, marketplace 500, NFT server 600, and administrator terminal 700 via a network such as the Internet.

[0053] The storage unit 116 includes, for example, a main storage unit and an auxiliary storage unit. The main storage unit may include, for example, a ROM (read-only memory) and a RAM (random-access memory). The ROM is a non-volatile memory used exclusively for reading data, and can store data and various setting values ​​used by the processor 111 when performing various processes. The RAM can be used as a so-called work area for temporarily storing data when the processor 111 performs various processes. The main storage unit in this embodiment is, for example, a RAM, and is used as a memory.

[0054] The auxiliary storage unit is a non-transitory computer-readable storage medium of a computer centered around the processor 111. The auxiliary storage unit is, for example, an EEPROM (registered trademark) (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive).

[0055] The auxiliary storage unit can store data and programs used by the processor 111 when it performs various processes, data generated by the processes in the processor 111, various setting values, and the like.

[0056] The auxiliary memory unit stores, for example, information about a lottery held within a game. The information about the lottery may include lottery identification information, the lottery holding period, information about the game media (including in-game assets such as characters and items) that are the subject of the lottery (game media identification information, attribute values ​​(e.g., attack, craftsmanship, magic, life), weapon equipment values ​​(e.g., weapon, shield, decoration), skills, species, offer rate, number offered, remaining number, etc.), lottery execution conditions (type and amount (unit price, set price) of in-game currency required for the lottery, etc.), and other lottery setting information. Note that the auxiliary memory unit may store information about multiple lotteries, and multiple lotteries may include multiple types of lotteries with different rules and settings. Furthermore, the holding periods of multiple lotteries may overlap.

[0057] The auxiliary memory unit stores user information such as the game play history information of the user playing the game, information on the in-game assets owned by the user, information on the game media (in-game currency, etc.) owned by the user, user level, preferential level, and various points awarded to the user, associated with the user identification information (user identifier) ​​of the user playing the game, and also stores the latest sales price (unit price) of game media such as in-game currency in cryptocurrency, the latest sales price (unit price) of game media such as in-game currency in legal tender, and the latest value of cryptocurrency relative to legal tender, etc.

[0058] The latest selling price (unit price) of the game medium in cryptocurrency may be set taking into account the value of the cryptocurrency relative to legal tender in accordance with fluctuations in the value of the cryptocurrency, or may be set as a predetermined price. Similarly, the latest selling price (unit price) of the game medium in legal tender may be set taking into account the value of the legal tender relative to the cryptocurrency, or may be set as a predetermined price. In this embodiment, the price of the game medium in legal tender may be set to a predetermined value, and the price of the game medium in cryptocurrency may be set to a value that corresponds to fluctuations in the value of the cryptocurrency relative to legal tender, based on the price set in legal tender. If there are multiple types of game medium, the latest selling price may be set for each of the multiple types of game medium.

[0059] The historical information may include, for example, billing history information, battle history information, login history information, lottery (gacha) history information, player level history information, character level history information, character skill history information, character equipped item history information, character strengthening history information, item purchase history information, in-game asset conversion into NFT, ranking history information, and usage history information for game media (paid stones, other in-game currency, etc.) and in-game assets (characters, items, etc.), each of which is associated with a user identifier and a corresponding date and time. The history information of lotteries (gacha) may include information such as the attribute values ​​(e.g., attack, craftsmanship, magic, life) of game media previously provided to users through lotteries, weapon equipment values ​​(e.g., martial arts, shield, decoration), skills, and race.

[0060] The information on the user's in-game assets includes the character identifier and item identifier owned by the user. The character identifier and item identifier are stored in the storage unit 116 in association with the user identifier.

[0061] The user's in-game currency information includes information on the paid stones and free stones currently owned by the user, as well as information on the user's paid stone purchase history. The user's in-game currency information may include, for example, the number of paid stones purchased by the user, the number of free stones owned by the user, the date and time of the paid stone purchase, and the cryptocurrency price of the paid stones at the date and time of the paid stone purchase. The number of paid stones purchased by the user (number of paid stones purchased), the date and time of the paid stone purchase, and the cryptocurrency price of one paid stone at the date and time of the paid stone purchase are associated with the user identifier.

[0062] In the game server 110 of this embodiment, information on multiple types of paid stones used in the game is stored by type in the storage unit 116. The multiple types of paid stones may be categorized, for example, according to the means by which the user acquired the paid stones. Each of the multiple types of paid stones may also have a set use. For example, paid stones purchased with crypto assets other than the first crypto asset or legal tender may be usable for playing a lottery (gacha), while paid stones purchased with the first crypto asset may be usable for developing, strengthening, and refining in-game assets, as well as for playing a lottery (gacha). A specific lottery (gacha) may also be set so that only specific paid stones can be used. At least some of the multiple in-game assets that a user can acquire when playing a gacha using paid stones purchased with the first crypto asset may differ from at least some of the multiple in-game assets that a user can acquire when playing a lottery (gacha) using paid stones purchased with crypto assets other than the first crypto asset or legal tender.

[0063] The storage unit 116 may be built into the game server 110 or may be externally attached to the game server 110. Furthermore, the data stored in the storage unit 116 may be shared among the game server 110, the payment server 120, and other servers (such as the NFT server 600).

[0064] The processor 111 is typically a CPU (Central Processing Unit) and / or a GPU (Graphics Processing Unit), but may also be a microcomputer, an FPGA (Field Programmable Gate Array), a DSP (Digital Signal Processor), etc. The processor 111 can realize various functions of the game server 110 by executing programs such as system software, application software, or firmware stored in the storage unit 116.

[0065] The processor 111 includes a sales unit 112, a lottery unit 113, a display processing unit 114, and a play management unit 115. The display processing unit 114 generates display data for updating the display of the user terminal 200, for example, as the game provided by the game server 110 progresses, and supplies the display data to the user terminal 200. In addition, the display processing unit 114 generates display data for presenting to the user the provision ratio and number of provided (or remaining) game media that are the subject of the lottery, for example, in response to a lottery execution request or operation information from the user terminal 200, and supplies the display data to the user terminal 200.

[0066] The sales unit 112 can sell game media (in-game currency, items, tickets, etc.) to users. The sales unit 112 includes a first sales unit 1121 and a second sales unit 1122.

[0067] The sales unit 112 externally acquires the value (currency rate) of the crypto asset against legal tender at a preset cycle (predetermined time). Since the game server 110 of this embodiment is capable of handling multiple types of crypto assets, the sales unit 112 can acquire the value of the crypto asset (currency rate) for each of the multiple types of crypto assets from, for example, an external crypto asset exchange server. The cycle is set in advance by an administrator of the game server 110, and can be changed as appropriate.

[0068] The first selling unit 1121 sells game media such as in-game currency using crypto assets in response to a first purchase request from the user terminal 200. The first purchase request from the user terminal 200 may include information such as a user identifier, a game media identifier, the number of game media (such as in-game currency) desired to purchase, and date and time information (date and time of purchase request). The user may, for example, select one of multiple types of crypto assets to use when purchasing in-game currency. In this case, the first purchase request may include the identifier of the crypto asset selected by the user.

[0069] For example, the first sales unit 1121 periodically acquires the latest value of the crypto asset and determines the selling price (unit price) of the game medium (in-game currency, etc.) using the crypto asset according to the acquired value. The first sales unit 1121 records the selling price (unit price) of the game medium (in-game currency, etc.) using the crypto asset in the storage unit 116 in association with date and time information.

[0070] In response to a first purchase request from a user, the first sales unit 1121 calculates the total amount to be paid in cryptocurrency required to purchase the game medium using the number of game medium (in-game currency, etc.) that the user wishes to purchase, the identifier of the game medium, and the sales price of the game medium (in-game currency, etc.) using cryptocurrency recorded in the memory unit 116.

[0071] The first selling unit 1121 supplies the total payment amount to the display processing unit 114, and the display processing unit 114 generates display data displaying the user's total payment amount and transmits it to the user terminal 200. The user's total payment amount is presented to the user on the user terminal 200 via the display data. The user checks the total payment amount displayed on the display or the like of the user terminal 200, settles the amount using the cryptocurrency recorded in the wallet (not shown), and, if proceeding with the buying and selling transaction, operates the user terminal 200 to send payment information (remittance request) to the wallet. At this time, the payment information may be sent to the wallet via the game server 110. The payment information sent to the wallet includes information for identifying the wallet from which the payment is sent (or cryptocurrency account information, etc.), the wallet address of the game server 110 to which the payment is sent (or cryptocurrency account information, etc.), and the remittance amount. The wallet generates remittance data (transaction) based on the payment information and transmits the remittance data to the game server 110.

[0072] The first sales unit 1121 acquires the remittance data sent from the wallet and performs identity authentication to confirm that the remittance is from the user who wishes to purchase the game medium (in-game currency, etc.), and after identity authentication, the display processing unit 114 generates display data (payment completion display data) indicating that the payment has been completed successfully and sends it to the user terminal 200.

[0073] When the settlement with the user is successfully completed, the first selling unit 1121 determines that the buying and selling transaction with the user is completed. The first selling unit 1121 associates information about the game media, such as in-game currency, purchased by the user (e.g., the quantity of paid stones purchased by the user, the date and time of the paid stone purchase, and the price of the paid stones in cryptocurrency at the date and time of the paid stone purchase) with the user identifier included in the first purchase request and records them in the storage unit 116. The date and time of the paid stone purchase may be, for example, the date and time when the first selling unit 1121 sends a settlement completion notification via the communication unit 119, or the date and time when remittance data is received from the wallet. The wallet (not shown) may be included in the settlement server 120, the game server 110, or an application server external to the game system 100.

[0074] The second selling unit 1122 sells game media such as in-game currency with legal tender in response to a second purchase request from the user terminal 200. The second purchase request from the user terminal 200 may include information such as a user identifier, a game media identifier, the number of game media (such as in-game currency) desired to purchase, and date and time information (date and time of purchase request).

[0075] In response to a second purchase request from a user, the second sales unit 1122 calculates the total payment amount in legal tender required to purchase the game media (in-game currency, etc.) using the number of game media (in-game currency, etc.) the user wishes to purchase, the identifier of the game media, and the sales price of the game media (in-game currency, etc.) in legal tender that is pre-stored in the storage unit 116. Note that the sales price of game media (in-game currency, etc.) in legal tender may be periodically reviewed. Because the value of legal tender is less volatile and more stable than the value of cryptocurrency, the sales price of game media (in-game currency, etc.) in legal tender is a more stable value with less fluctuation than the sales price of game media (in-game currency, etc.) in cryptocurrency.

[0076] The second selling unit 1122 supplies the user's total payment amount to the display processing unit 114, and the display processing unit 114 generates display data displaying the user's total payment amount and transmits it to the user terminal 200. The user's total payment amount is presented to the user on the user terminal 200 using the display data. The user checks the total payment amount displayed on the display or the like of the user terminal 200, settles the amount, and, if the user wishes to proceed with the buying and selling transaction, operates the user terminal 200 to transmit second payment information (remittance request) to the game server 110. At this time, the second payment information may be transmitted to the payment server 120 without going through the game server 110.

[0077] The second sales unit 1122 acquires second payment information from the user terminal 200 via the communication unit 119, and transmits a remittance request based on the second payment information to the payment server 120. The second payment information may include, for example, information for a user using the user terminal 200 to make a payment (credit card information, transportation IC card information, electronic money payment information, legal tender account information, etc.), a user identifier (identification information) for identifying the user, identification information for identifying the payment, etc.

[0078] When the payment server 120 completes the payment, the payment server 120 sends a payment completion notification to the game server 110 or the user terminal 200. The payment completion notification from the payment server 120 may include, for example, a user identifier and an identifier that identifies the payment.

[0079] When the second sales unit 1122 receives a payment completion notice from the payment server 120, it considers the buying and selling transaction with the user to be completed. Based on the payment completion notice, the second sales unit 1122 associates information about the game media (in-game currency, etc.) purchased by the user (e.g., the quantity of paid stones purchased by the user, the date and time of the paid stone purchase, and the price of the paid stones in cryptocurrency at the date and time of the paid stone purchase) with the user identifier included in the payment completion notice, and records them in the storage unit 116. Note that the date and time of the paid stone purchase completion may be, for example, the payment completion date and time included in the payment completion notice, or the date and time when the payment completion notice was received.

[0080] The play management unit 115 has a function of managing play by users of games provided by the game server 110. The play management unit 115 performs, for example, user authentication, management of in-game assets such as characters and items owned by users in the game, management of battles played by users using characters, management of events such as in-game tournaments, management of the strengthening and levels of users and in-game assets, and management related to the conversion of in-game assets into NFTs.

[0081] The play management unit 115 has the function of managing information (play information) obtained by a user playing a game, and for example, when the initial settings of the game are performed on the user terminal 200 owned by the user, it generates a user identifier and begins managing the user's play information.

[0082] The play management unit 115 has, for example, a function for managing information on in-game assets that users obtain by playing the game (in-game asset information management function), and a function for managing information on users that users obtain by playing the game (user information management function).

[0083] For example, when a user strengthens a character by playing a game, the in-game asset information management function associates the user identifier, the character identifier, identification information of the strengthening performed, and the date and time of the strengthening, and records them in memory unit 116.

[0084] Furthermore, for example, when a character's level increases as a result of the user playing the game, the in-game asset information management function associates the user's identifier, the character's identifier, the increased level, and the date and time when the level increased in the storage unit 116. For example, the in-game asset management function may associate an awakening ID, which is an identifier indicating that the in-game character's level has reached a certain level, or that the in-game character's level has exceeded the limit of its ability value and become capable of being strengthened (awakened) after reaching a certain level, with the character's identification information and the date and time when the character awakened in the storage unit 116.

[0085] In addition, the in-game asset information management function, for example, when a user plays a game and pits characters against each other, associates the user identifier, the character identifier, the battle identifier, the date and time of the battle, and the battle result, and records them in the memory unit 116.

[0086] Furthermore, for example, when a user equips a character with an item by playing a game, the in-game asset information management function associates the user identifier, the character identifier, the item identifier, and the date and time the item was equipped in the storage unit 116. For example, when a user equips a character owned by the user with an item such as exclusive equipment for the character, the in-game asset information management function may further associate the user identifier, the character identifier, the item identifier, and the date and time the item was equipped in the storage unit 116 with an exclusive equipment ID.

[0087] Furthermore, for example, when a user draws a lottery (gacha), the in-game asset information management function associates the user's identifier, the date and time the gacha was drawn, and the result of the gacha (for example, the identifier of the in-game asset (including game content) obtained through the gacha), and records them in the storage unit 116. For example, the identifier of the in-game asset may include a switch flag that switches whether the user can use the in-game asset in the game. The in-game asset information management function may switch the switch flag to switch between a state in which the in-game asset is usable by the user in the game and a state in which it is unusable. An in-game asset that is unusable may be treated as not owned by the user on the game play screen.

[0088] Furthermore, for example, when a user converts in-game assets into NFTs by playing a game, the in-game asset information management function associates the user identifier, the identifier of the NFTed in-game assets, the date and time when the NFT conversion was performed (for example, the date and time when the NFT conversion was completed or the date and time when the NFT conversion process completion notification was received), and the NFT identifier, and records them in memory unit 116.

[0089] In addition, when the in-game asset information management function receives a request (return request signal) from a user to make in-game assets that have already completed the NFT process usable in the game, it associates the user identifier, the identifier of the in-game assets that have been NFTed, the date and time the NFT was made usable in the game, and the NFT identifier, and records them in the memory unit 116.

[0090] For example, when a user plays a game and is charged, the user information management function records the user identifier, the charged amount, and the charging date and time in the storage unit 116 in association with each other.

[0091] Furthermore, the user information management function, for example, when a user logs in, associates the user identifier with the login date and time and records them in the storage unit 116, and when the user logs out, associates the user identifier with the logout date and time and records them in the storage unit 116.

[0092] In addition, for example, when a user increases their player level by playing a game, the user information management function associates the user's identifier, the user level, and the date and time when the user level increased, and records them in the memory unit 116.

[0093] Furthermore, for example, when a user purchases an item by playing a game, the user information management function records the user identifier, the item identifier, and the date and time of the item purchase in association with each other in the storage unit 116.

[0094] Furthermore, the user information management function, for example, records information on a user's ranking as a result of the user playing the game in association with the user identifier in the storage unit 116. For example, the ranking information may include information such as the user's ranking when participating in an in-game tournament, and the identifiers of in-game assets (such as characters or items) used by the user in the tournament.

[0095] The play management unit 115 may have a conversion function. The conversion function has a function of making in-game assets associated with a user identifier convertible into an NFT (Non-Fungible Token) when, for example, history information associated with the user identifier satisfies predetermined conditions (NFT conversion conditions).

[0096] The conversion function receives a conversion request signal from the user terminal 200 via the communication unit 119, requesting the conversion of in-game assets into NFTs. The conversion request signal includes the user's user identifier and the identifier of the in-game assets that the user wishes to convert into NFTs. In response to the conversion request signal acquired from the user terminal 200 via the communication unit 119, the conversion function acquires history information associated with the corresponding user identifier from the storage unit 116. The conversion function may enable the conversion of the in-game assets associated with the user identifier into NFTs when the acquired history information satisfies a predetermined condition. Note that the conversion function may wait for conversion request information from the user terminal 200 after enabling the conversion of the in-game assets associated with the user identifier into NFTs when the history information associated with the user identifier in the storage unit 116 satisfies a predetermined condition.

[0097] When the conversion function receives a conversion request signal and the historical information associated with the user identifier satisfies predetermined conditions, it makes the in-game assets associated with the user identifier convertible to NFTs and generates an NFT conversion request signal that requests the NFT server to convert the in-game assets into NFTs.

[0098] The NFT request signal includes at least digital data such as image data corresponding to the in-game assets to be NFTed, information about the creator of the in-game assets to be NFTed, and information about the owner of the in-game assets to be NFTed. Note that the information about the creator and the information about the owner of the in-game assets may be the same information, and the information about the creator and the information about the owner of the in-game assets may include a user identifier for the game. The conversion function sends the NFT request signal to the NFT server.

[0099] Upon receiving a notification of completion of the NFT conversion process from the NFT server (information about the creator of the NFT, information about the owner of the NFT, identification information for the in-game assets that have been NFTed, and the date and time when the NFT conversion was completed), the conversion function causes the in-game assets for which the NFT conversion process has been completed, which are associated with the user identifier and stored in the storage unit 116, to be in a state where they are not owned by the user in the game. Upon receiving a notification of completion of the NFT conversion process from the NFT server, the conversion function may switch a switching flag for the in-game assets for which the NFT conversion process has been completed, making the in-game assets unusable by the user in the game.

[0100] The lottery unit 113 executes and manages lotteries that are executed when a user consumes game media such as paid stones. The lottery unit 113 includes a providing unit 1131 and a lottery management unit 1132. The lottery management unit 1132 includes a canceling unit 1133. The lottery unit 113 receives a lottery execution request from the user terminal 200.

[0101] The providing unit 1131, for example, in response to a lottery execution request from the user terminal 200, executes a lottery by consuming in-game currency such as paid stones owned by the user, and provides the user with one of a plurality of types of game media selected by lottery from a set of multiple types of game media. The lottery execution request from the user terminal 200 includes, for example, user identification information, lottery identification information, and information on the requested number of lottery executions. The providing unit 1131 can obtain information about the lottery linked to the lottery identification information included in the lottery execution request from the storage unit 116.

[0102] In response to a request to hold a lottery, the providing unit 1131 consumes an amount of in-game currency owned by the user equal to the requested number of times to hold the lottery, and holds a lottery for game media. The amount of in-game currency required to hold the lottery (unit price, set unit price) may be set depending on the type of lottery. The amount of in-game currency required to hold the lottery may also differ depending on the user's preferential treatment level.

[0103] The type of in-game currency consumed to execute a lottery may vary depending on the type of lottery. For example, the multiple types of lotteries may include lotteries that can be executed by consuming in-game currency purchased with crypto assets, lotteries that can be executed only by consuming in-game currency purchased with specific crypto assets, or lotteries that can be executed by consuming in-game currency purchased with crypto assets and legal tender. Furthermore, the providing unit 1131 may execute a lottery for game media by consuming game media other than in-game currency owned by the user. For example, the providing unit 1131 can execute a lottery for game media by consuming game media other than in-game currency, such as in-game assets, items, or tickets owned by the user.

[0104] The providing unit 1131 selects game media to be provided to the user from a collection of multiple types of game media in accordance with the provision ratio set for each game media, associates the selected game media with the user's user identifier and records it in the storage unit 116, and provides the user with the game media selected by lottery. The providing unit 1131 provides identification information of the game media selected by lottery to the lottery management unit 1132.

[0105] The lottery management unit 1132 sets and manages lotteries (gacha) held within the game. The lottery management unit 1132 receives information related to the lottery from, for example, the administrator terminal 700, such as the lottery period, the game media (characters, items, tickets, etc.) to be selected, the in-game currency with which the lottery can be executed, the amount of in-game currency required to execute the lottery, the initial values ​​of the distribution rate and the number of game media that can be provided, and lottery identification information, and records this information in the storage unit 116.

[0106] Furthermore, the lottery management unit 1132 may analyze game media information (e.g., attribute values ​​(e.g., attack, craftsmanship, magic, life), weapon equipment values ​​(e.g., weapon, shield, decoration), skills, race, etc.) provided by lotteries in the past, and set the number of game media to be included as lottery targets in the next lottery. For example, the lottery management unit 1132 may set the number of game media to be provided in the next lottery to be reduced for game media of attributes, weapon equipment, skills, and races that were provided in small numbers among game media provided by lotteries in the past. This can further increase the rarity of game media such as attributes that were provided in small numbers in the past.

[0107] Furthermore, the lottery management unit 1132 can manage the duration of the lottery, the number of game media already provided (or the remaining number) to users through the lottery, the rate at which game media are provided, etc. In this embodiment, the game media that are the subject of the lottery may be referred to as units.

[0108] For example, the lottery management unit 1132 enables acceptance of a lottery holding request from the user terminal 200 when the lottery holding period begins, and disables acceptance of a lottery holding request from the user terminal 200 when the lottery holding period ends.

[0109] The lottery management unit 1132 can set multiple types of lotteries. For example, for each unit period included in the lottery holding period, the maximum number of specific game media (first game media) that are the subject of the lottery that can be provided to users may be set. The lottery holding period may include one or multiple unit periods. The multiple unit periods may have different lengths, the multiple unit periods may be consecutive, or there may be intervals between the unit periods.

[0110] For example, in a lottery held over a five-day period (24 hours x 5), the lottery management unit 1132 sets the maximum number of specific game media that can be provided in each unit period (e.g., 24 hours) to 10. In this case, up to 50 specific game media can be provided to users in the five-day lottery period according to the set provision ratio. The lottery management unit 1132 determines whether specific game media have been provided to users, and stores and manages the number of specific game media provided and the remaining number in the memory unit 116.

[0111] In this embodiment, a lottery that includes the specific game media as a draw target is referred to as a Type 1 lottery. In Type 1 lottery, specific game media not provided to users in each unit period are not carried over to the next unit period. At the start of a unit period, the lottery management unit 1132 sets the maximum number of specific game media that can be provided to users in that period and restores the proportion of game media provided to users to the value at the start of the lottery period. For example, if seven specific game media have been provided to users and the first unit period of the lottery period ends, the three specific game media that were not provided to users in the first unit period are not carried over to the second unit period, and the lottery management unit 1132 sets the maximum number of specific game media that can be provided to users at the start of the second unit period to 10.

[0112] As a variation of the first-type lottery, specific game media not provided to users in each unit period may be set to be carried over to the next unit period. In this case, at the start of a unit period, the lottery management unit 1132 calculates the maximum number of specific game media that can be provided to users in that period by adding the number of specific game media not provided to users in the previous unit period and the number of specific game media set as the maximum number that can be provided to users in that unit period, and restores the provision rate of game media subject to the lottery to the value at the start of the lottery period. In this variation, the maximum number of specific game media that can be provided to users in each of multiple unit periods varies, and the predetermined number used as a threshold by the cancellation unit 1133 (described later) when determining whether to cancel the execution of the first-type lottery also varies depending on the maximum number of specific game media that can be provided to users.

[0113] In the first type of lottery, the specific game medium to be selected may be one type or multiple types. In the first type of lottery, the lottery management unit 1132, for example, allows game media other than the specific game medium to be selected (or a group combining multiple types) to be provided to users according to a set provision ratio without setting a maximum number that can be provided.

[0114] The lottery management unit 1132 may also set a lottery that does not include the above-mentioned specific game media as the lottery items (a lottery other than the first type lottery). In this case, the lottery management unit 1132 may set a provision rate for each of the multiple types of game media that are the lottery items or for each group that combines multiple types of game media. The lottery management unit 1132 may also set a so-called gacha box-type lottery in which the number of each of the multiple types of game media that are the lottery items that can be provided over the entire period in which the lottery is held is preset.

[0115] 3 to 5 are diagrams showing examples of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. Here, the game media subject to the lottery are referred to as units. The game media (units) subject to the lottery are assigned a rarity (degree of scarcity) corresponding to the probability of winning the lottery (provision rate). The unit with the highest rarity (lowest provision rate) is the G unit, followed by the SR unit, R unit, N unit, and other items, with the provision rates increasing in that order.

[0116] In the example shown in FIG. 3, G units correspond to specific game media (first game media) in the first type lottery. The provision rate of G units is, for example, 0.0001%, and the maximum number of units provided to a user in each of the multiple unit periods during the first type lottery is 10. The provision rate of SR units is 1.50%, the provision rate of R units is 3.50%, the provision rate of N units is 10.00%, and the provision rate of other items is 84.9999%, with the total provision rate of all units eligible for the lottery being 100%. As described above, the lottery management unit 1132 can assign a degree of rarity to units eligible for the lottery by setting a provision rate for the units eligible for the lottery.

[0117] In the example shown in FIG. 4, two types of G units are set by the lottery management unit 1132. In this example, G unit 1 and G unit 2 each correspond to specific game media (first game media) for the first type lottery. The provision rate of G unit 1 and G unit 2 is 0.0001%, and the maximum number provided to users in each of multiple unit periods during the period in which the first type lottery is held is 10 units each. Note that the provision rates and the maximum number that can be provided in each unit period for multiple types of specific game media may differ from one another.

[0118] 4, the provision rate of SR units is 1.50%, the provision rate of R units is 3.50%, the provision rate of N units is 10.00%, and the provision rate of other items is 84.9998%, and the total provision rate of all units subject to lottery is 100%. As described above, the lottery management unit 1132 can assign a rarity level to units by setting a provision rate for units subject to lottery.

[0119] The lottery management unit 1132 can adjust the provision rate of the units to be selected in accordance with the provision status of G units in the first type lottery, for example. When the lottery management unit 1132 adjusts the provision rate of the units to be selected in the lottery, the lottery management unit 1132 records the adjusted provision rate in the storage unit 116.

[0120] In the example shown in Figure 5, two types of G units are set by the lottery management unit 1132. In this example, G unit 1 and G unit 2 each correspond to a specific game medium (first game medium) for the first type lottery. Figure 5 shows an example of the provision ratio when the provision rates of G unit 1 and G unit 2 at the start of a unit period are each set to 0.0001%, and the maximum number provided to users in each of multiple unit periods during which the first type lottery is held is 10 units each, but before the unit period during which the first type lottery is held ends, 10 G units 2 are provided to users, and the provision of G unit 2 for the unit period ends (the remaining number becomes zero), and it is no longer eligible for the lottery.

[0121] In this case, the lottery management unit 1132 sets the provision rate of G unit 2, which has sold out (remaining quantity is zero), to 0%, and adds the 0.0001% that was set as the provision rate of G unit 2 to the provision rates of the other units, making the total provision rate of all units subject to the lottery 100%. In the example shown in Figure 5, for example, the lottery management unit 1132 adds the 0.0001% that was originally the provision rate of G unit 2 to the provision rates of the other items. As a result, the provision rate of G unit 1 is 0.0001%, the provision rate of SR units is 1.50%, the provision rate of R units is 3.50%, the provision rate of N units is 10.00%, and the provision rate of other items is 84.9999 (84.9998 + 0.0001)%. Here, if the total provision rate of all units eligible for the lottery is 100%, the lottery management unit 1132 may divide the provision rate of a sold-out unit (a unit whose remaining quantity is zero and is no longer eligible for the lottery) and add it to multiple other units.

[0122] In the examples shown in Figures 3 to 5, the unit with the highest rarity (lowest provision rate) is set as the specific game medium (first game medium) for the first type of lottery, but units other than the unit with the highest rarity may also be the specific game medium (first game medium) for the first type of lottery. For example, only the SR unit may be the specific game medium for the first type of lottery, or the SR unit and the R unit, which have different rarities, may each be the specific game medium for the first type of lottery. Furthermore, it is not necessary for the specific game medium (first game medium) to be included as a lottery target in all unit periods included in the period during which the first type of lottery is held; it is sufficient that the specific game medium (first game medium) be included as a lottery target in at least one unit period included in the period during which the first type of lottery is held.

[0123] Furthermore, if the period during which the first type lottery is held includes multiple unit periods, the type of specific game medium (first game medium) may be different for each unit period. For example, the lottery management unit 1132 may set G unit 1 as the specific game medium in the first unit period of the first type lottery, and set G unit 2 as the specific game medium in the second unit period following the first unit period.

[0124] The lottery management unit 1132, for example, in response to a request from the user terminal 200, supplies setting information for the first-type lottery to the display processing unit 114, and the display processing unit 114 can generate display data displaying the setting information for the first-type lottery and supply it to the user terminal 200 via the communication unit 119. The display processing unit 114 may, for example, generate display data that presents to the user the provision rate of each of multiple types of game media (units) provided by the first-type lottery in a manner corresponding to the value of the provision rate. The display processing unit 114 may, for example, generate display data that presents to the user the size, color, font, etc. of the text for the provision rate of a unit with a low provision rate (high rarity) in a manner different from that of other units.

[0125] In addition, the lottery management unit 1132 may supply setting information for the first type lottery to the display processing unit 114, for example, in response to a request from the user terminal 200, and the display processing unit 114 may generate display data to indicate that the provision rate of a specific game medium (for example, a G unit) in the first type lottery is a specific game medium (first game medium) by displaying it in a manner that highlights it with a predetermined mark ``G'' or distinguishes the color, size, or font of the characters from other units, for example, as shown in Figures 3 to 5.

[0126] When the number of specific game media provided to users in a unit period during which the first-type lottery is being held reaches a predetermined number (the maximum number that can be provided in a unit period), the canceling unit 1133 cancels the execution of the first-type lottery in which the specific game media are the subject of the lottery. In other words, the canceling unit 1133 makes it impossible to accept a lottery execution request from the user terminal 200. At this time, the canceling unit 1133 notifies the display processing unit 114 of the cancellation of the first-type lottery.

[0127] After canceling the execution of the first type lottery, the canceling unit 1133 keeps the execution of the first type lottery canceled until the unit period in which the first type lottery was canceled ends, and resumes the first type lottery from the start of the next unit period.

[0128] Next, an example of the operation of the game server 110 that performs the first type lottery will be described. 6 is a flowchart illustrating an example of the operation of the game server according to an embodiment when conducting a lottery. The flowchart in FIG. 6 illustrates an example of the operation of the lottery unit 113 during each of a plurality of unit periods included in the period during which the first type lottery is held.

[0129] 7 to 10 are diagrams showing examples of displays on the display of a user terminal that executes a lottery in a game provided by a game server of one embodiment. First, based on the information input from the administrator terminal 700, the lottery management unit 1132 records information related to the lottery, such as the period during which the first type lottery will be held, multiple types of game media that are the subject of the lottery, specific game media, the provision ratio of multiple types of game media that are the subject of the lottery, the number of specific game media that can be provided in a unit period, the type and amount of in-game currency that will be consumed to execute the lottery, and images that will be presented to the user when the lottery is executed, in the memory unit 116, and sets up the lottery.

[0130] When the lottery period begins, the lottery management unit 1132 becomes ready to accept a lottery holding request from the user terminal 200. The lottery unit 113 acquires a lottery execution request from the user terminal 200 via the communication unit 119 (step SA1).

[0131] FIG. 7 shows a schematic example of a display on the display of the user terminal 200 when the game server 110 receives a request to hold a first type lottery. 7 shows a screen 20 that accepts a request to draw lottery C in response to a user operation during the period when three types of lotteries A, B, and C are being held, displayed on the display of the user terminal 200. In the example shown in FIG. 7, lottery C is a first type lottery, and includes one type of G unit as the game medium to be drawn.

[0132] Screen 20 includes a display 21 showing the number of G units to be offered that are the subject of lottery C, a display 22 showing the time until the next unit period, an operation button 23 for requesting the display of detailed information about G units, operation buttons 24 and 25 for requesting the execution of lottery G, and a display 26 showing the period (end) of lottery C.

[0133] Display 21 includes an indication of the number of G units already provided (number provided) in the unit period, "7", and the maximum number of G units that can be provided in the unit period, "10". Note that display 21 may also include an indication of the remaining number of G units that can be provided in the unit period, "3". The display 22 includes a display of the hours, minutes, and seconds until the next unit period, and is a display that counts down to the next unit period.

[0134] Operation buttons 23-25 ​​indicate areas that can be selected by user operations such as clicking or pressing on the display of user terminal 200. By selecting operation button 23 on the display of user terminal 200, the user can display information about the G unit that is the subject of lottery C (for example, profile information such as name, appearance, attribute values ​​(for example, attack, craftsmanship, magic, life), weapon equipment values ​​(for example, martial arts, shield, decoration), skills, race, level, etc.), the distribution ratio by lottery (probability of winning), etc.

[0135] Furthermore, the user can proceed with the procedure to request the holding of lottery C a desired number of times by selecting operation buttons 24 and 25 on the display of user terminal 200. Operation button 24 is an operation button selected when proceeding with the procedure to request the holding of lottery C once. Operation button 24 is an operation button selected when proceeding with the procedure to request the holding of lottery C ten times at once.

[0136] FIG. 8 shows an example of a usage confirmation screen that is displayed on the display of the user terminal 200 after the user selects the operation buttons 24 and 25 on the screen 20. In FIG. Here, the user is informed that paid stones will be consumed for the number of draws requested by the user, and the remaining number of specific game media (G units) that can be provided to the user through the lottery (number already provided in a unit period / maximum number that can be provided in a unit period (initial setting number)) is presented to the user. After confirming the presented information, the user can request a lottery by selecting the "OK" button on the usage confirmation screen.

[0137] 8 shows an example in which the first type lottery for which the user requests the lottery includes two types of specific game media (G units) as the lottery targets. The user can request the lottery after checking the remaining number of specific game media (G units) that can be won on the usage confirmation screen.

[0138] Based on the request to hold a lottery, the providing unit 1131 identifies the user and the lottery to be held, and holds the lottery by consuming the in-game currency owned by the user for the requested number of draws (step SA2).

[0139] The in-game currency consumed to execute the first type lottery may be a specific in-game currency among multiple types of in-game currencies (for example, in-game currency purchased with specific crypto assets). The in-game currency consumed to execute the first type lottery may be any of multiple types of in-game currencies purchased by the user with legal tender or crypto assets. Also, the in-game currency consumed to execute the first type lottery may be any of multiple types of in-game currencies purchased by the user with crypto assets.

[0140] The providing unit 1131 associates one of the game media selected by lottery from the set of multiple types of game media that are the subject of the lottery with the user's identifier, records it in the storage unit 116, and provides the game media to the user (step SA3). The lottery management unit 1132 determines whether or not a specific game medium (G unit) has been won through the lottery executed by the provision unit 1131 (step SA4).

[0141] If the winning game medium is a specific game medium (G unit) (step SA4, YES), the lottery management unit 1132 updates the number of provided (or remaining) game mediums (G units) stored in the memory unit 116 (step SA5). Depending on the number of provided (or remaining) game mediums stored in the memory unit 116, the display processing unit 114 generates display data for displaying the screen 20 with updated values ​​for the displays 21, 211, and 212, and supplies the display data to the user terminal 200, causing the display to be updated.

[0142] If the winning game medium is not a specific game medium (G unit) (step SA4, NO), the lottery management unit 1132 does not update the number of provided (remaining) specific game media (G units), and the providing unit 1131 accepts a request to draw a first type lottery (step SA1), conducts the lottery (step SA2), and provides the winning game medium (step SA3). Note that the processing of steps SA4-SA5 and the processing of steps SA1-SA3 may be performed in parallel.

[0143] The canceling unit 1133 determines whether the number of provided specific game media (G units) of all types stored in the memory unit 116 has reached a predetermined number (the maximum number provided to users in a unit period) (the remaining number has reached zero) (step SA6). The canceling unit 1133 does not cancel the first type lottery until the number of provided specific game media (G units) of all types has reached the predetermined number (until the remaining number has reached zero), and the processing of steps SA1 to SA6 is executed.

[0144] When the number of all types of specific game media (G units) provided reaches a predetermined number (the remaining number becomes zero) (step SA6, YES), the cancellation unit 1133 cancels the first type lottery in which the specific game media (G units) are the subject of the lottery (step SA7).

[0145] As described above, when the objects of the first type lottery include multiple types of specific game media (G units), the cancellation unit 1133 cancels the first type lottery in which the objects of the lottery include the multiple types of specific game media (G units) when the specified number of all types of specific game media (G units) has been reached (the remaining number has reached zero).

[0146] 9 shows a schematic example of a display on the display of the user terminal 200 when a request to hold a first-type lottery is accepted. This example shows a screen 20 displayed on the display of the user terminal 200, which accepts a request to hold a lottery C in response to a user operation during the period when three types of lotteries A, B, and C are being held. Lottery C is a first-type lottery, and includes two types of specific game media (G units) as game media to be selected.

[0147] Screen 20 includes displays 211, 212 showing the number of specific game media (G Unit 1 and G Unit 2) that are the subject of lottery C to be offered, a display 22 of the time until the next unit period, an operation button 23 for requesting the display of detailed information about G Units, operation buttons 24, 25 for requesting the execution of lottery G, and a display 26 showing the period (end) of lottery C.

[0148] Display 211 includes an indication of the number of G units 1 provided in the unit period, "7," for one type of G unit 1, and the maximum number of G units 1 that can be provided in the unit period, "10." Note that display 211 may also include an indication of the remaining number of G units 1 of one type that can be provided in the unit period.

[0149] Display 212 includes an indication of the number of G units 2 of the other type provided in the unit period, "10," and the maximum number of G units 2 that can be provided in the unit period, "10." Note that display 212 may also include an indication of the remaining number of G units 2 of the other type that can be provided in the unit period.

[0150] Screen 20 shows a state in which the maximum number of G units 2 that can be provided to a user in a unit period have already been provided to the user, and the provision of G units 2 for the unit period has ended. For one type of G unit 1, the number that has already been provided is "7", which is less than the maximum number that can be provided in a unit period, "10", and therefore lottery C has not been canceled by the canceling unit 1133.

[0151] 10 is a schematic diagram showing an example of a display on the display of the user terminal 200 when a request to hold a first-type lottery is accepted. This example shows a screen 20 displayed on the display of the user terminal 200, which accepts a request to hold a lottery C in response to a user operation during the period when three types of lotteries A, B, and C are being held. Lottery C is a first-type lottery, and includes two types of G units as game media to be selected.

[0152] Screen 20 includes displays 211, 212 showing the number of multiple types of G units (G unit 1 and G unit 2) available that are the subject of lottery C, a display 22 of the time until the next unit period, an operation button 23 for requesting the display of detailed information about G units, operation buttons 24, 25 for requesting the execution of lottery C, a display 26 showing the period (end) of lottery C, and a display 27 indicating that lottery C for the unit period has been canceled.

[0153] Display 211 includes an indication of the number of G units provided in the unit period, "10," for one type of G unit 1, and the maximum number of G units 1 that can be provided in the unit period, "10." Note that display 211 may also include an indication of the remaining number of G units 1 of one type that can be provided in the unit period.

[0154] Display 212 includes an indication of the number of G units 2 of the other type provided in the unit period, "10," and the maximum number of G units 2 that can be provided in the unit period, "10." Note that display 212 may also include an indication of the remaining number of G units 2 of the other type that can be provided in the unit period.

[0155] 10 shows a state in which the maximum number of G units of all types that can be provided in a unit period have already been provided to the user, and lottery C has been stopped by the cancellation unit 1133. When lottery C is stopped by the cancellation unit 1133, the display processing unit 114 generates display data for displaying screen 20 including a display 27 to the effect that G units for the unit period have been sold out (provision has ended), provides this to the user terminal 200, and causes the display to be updated. In addition, the cancellation unit 1133 causes the display processing unit 114 to generate display data that, for example, causes the user to be unable to select operation buttons 24 and 25 on screen 20, thereby causing the user to be unable to request the execution of lottery C.

[0156] The canceling unit 1133 cancels the type 1 lottery by, for example, making it impossible to accept a request to hold the type 1 lottery until the start of the next unit period during which the type 1 lottery is being held. When the next unit period during which the type 1 lottery is being held starts, the cancellation of the lottery is canceled, and a request to hold the type 1 lottery can be accepted until the number of G units available for provision in that unit period has been provided to users.

[0157] For each of a plurality of unit periods included in the period during which the first-type lottery is held, the lottery unit 113 executes the processing of steps SA1-SA7, and the winning game media is provided to the user. Note that in this embodiment, if the user requests the execution of the first-type lottery at approximately the same time as the cancellation unit 1133 cancels the first-type lottery, the provision unit 1131 processes the execution of the first-type lottery by the user as an error, and the in-game currency owned by the user is not consumed.

[0158] According to the game server 110, lottery execution method, and computer program of the above embodiment, the selection of a specific game medium is made up of a set maximum number of games that can be provided to a user within a unit period included in the lottery period, thereby increasing the motivation of users to enter the lottery.

[0159] In many cases, lotteries (gacha) implemented in games have special prizes with a low probability of being offered, and users often enter the lottery with the aim of winning the special prize. Also, if the special prize has a very low probability of being offered but the number of prizes offered is not limited, users can win many special prizes by spinning the lottery (gacha) many times.

[0160] On the other hand, in the case of a Type 1 lottery in which the number of specific game media provided per unit period is limited, users will be eager to enter the Type 1 lottery in an attempt to acquire the specific game media before it sells out. Furthermore, in the game provided by the game server 110 of this embodiment, the number of specific game media that have already been provided to users in a unit period is presented, so that users can recognize the number of specific game media that remain, and users who wish to obtain specific game media before other users are likely to more proactively execute the first type lottery in order to obtain the remaining specific game media.

[0161] Furthermore, in blockchain games, it is possible to convert game content such as items provided to users through lotteries into NFTs, but even if game content that is widely available is converted into NFTs, the value of the NFTs is unlikely to increase, and users are likely to lose sight of the significance of winning game content through lotteries or converting the game content they have acquired into NFTs. As a result, users will lose motivation to enter lotteries.

[0162] In contrast, game media that are provided in limited quantities may have a high degree of rarity, and in this embodiment, when the number of specific game media provided per unit period reaches the maximum, the first type lottery cannot be held.Therefore, it is thought that users will attempt to hold the first type lottery to obtain a game medium with a high degree of rarity before another user acquires the specific game medium and the first type lottery is canceled.

[0163] That is, in the blockchain game provided by the game server 110 of this embodiment, it becomes possible to reduce the number of specific game media provided, further increasing the rarity of the specific game media and increasing their value after conversion to NFTs. As a result, it is possible to increase users' motivation to participate in the first type lottery and to convert the specific game media they have acquired into NFTs.

[0164] Furthermore, for example, by limiting the in-game currency consumed when requesting the execution of a first-type lottery to a specific in-game currency, a user who requests the execution of a first-type lottery will be required to make a payment to purchase the specific in-game currency, which will encourage users to make payments. As described above, according to this embodiment, it is possible to provide a game server, a lottery holding method, and a computer program that increase users' motivation to participate in lotteries.

[0165] Next, a game server, a lottery holding method, and a computer program according to a second embodiment will be described in detail with reference to the drawings. In the following description, the same components as those in the first embodiment will be denoted by the same reference numerals, and the description thereof will be omitted.

[0166] 11 is a block diagram schematically illustrating an example of the configuration of a game system according to the second embodiment. The game server 110 of this embodiment differs from the first embodiment in that the lottery management unit 1132 of the lottery unit 113 includes a stopping unit 1134 instead of the canceling unit 1133. The following description of the game server 110 of the second embodiment will mainly focus on the configuration and operation of the stopping unit 1134 of the lottery management unit 1132.

[0167] The lottery management unit 1132 can set multiple types of lotteries. For example, for each unit period included in the lottery holding period, the maximum number of specific game media (first game media) that can be provided to users as the subject of the lottery may be set. The lottery holding period may include one or more unit periods. In the lottery holding period, the lengths of the multiple unit periods may be different from one another, the multiple unit periods may be consecutive, or there may be intervals between the unit periods.

[0168] For example, in a lottery held over a five-day period (24 hours x 5), the lottery management unit 1132 sets the maximum number of specific game media that can be provided in each unit period (e.g., 24 hours) to 10. In this case, up to 50 specific game media can be provided to users in the five-day lottery period according to the set provision ratio. The lottery management unit 1132 determines whether specific game media have been provided to users, and stores and manages the number of specific game media provided and the remaining number in the memory unit 116.

[0169] In this embodiment, the lottery set by the lottery management unit 1132 to include the specific game media as the lottery target is referred to as a second-type lottery. The lottery management unit 1132 can set the second-type lottery in the same way as the first-type lottery in the first embodiment described above.

[0170] When the number of specific game media provided to users in a unit period during which the second type lottery is being held reaches a predetermined number (the maximum number that can be provided in a unit period), the stopping unit 1134 stops providing the specific game medium (first game medium) through the second type lottery, making multiple types of game media other than the specific game medium eligible for provision through the second type lottery.

[0171] At this time, the stopping unit 1134 notifies the display processing unit 114 that the specific game medium (first game medium) has been sold out, while remaining in a state where it is possible to accept a lottery execution request from the user terminal 200. Upon receiving the notification from the stopping unit 1134 that the specific game medium (first game medium) has been sold out, the display processing unit 114 generates display data for displaying the screen 20 including a message that the specific game medium for the unit period has been sold out, provides this to the user terminal 200, and updates the display.

[0172] For example, if the initial provision ratios of multiple types of game media are set as shown in Figure 3, the stopping unit 1134 sets the provision ratio of a specific game medium (G unit) that has sold out (remaining quantity is zero) to 0%, adds the 0.0001% that was set as the provision ratio of that specific game medium (G unit) to the provision ratios of other game media that are subject to the lottery, and sets the total provision ratios of all other types of game media that are subject to the lottery excluding the specific game medium that has sold out to 100%, and excludes the specific game medium that has sold out from being included in the second type lottery.

[0173] After stopping the provision of the specific game medium in the second type lottery, the stopping unit 1134 keeps the provision of the specific game medium stopped until the end of the unit period, and resumes the provision of the specific game medium from the start of the next unit period. For example, at the start of the next unit period, the stopping unit 1134 sets the provision ratio of multiple types of game media including the specific game medium to an initial setting value (initial value), and makes multiple types of game media including the specific game medium that were sold out in the previous unit period the subject of the second type lottery.

[0174] Next, an example of the operation of the game server 110 that performs the second type lottery will be described. 12 is a flowchart illustrating an example of the operation of the game server according to an embodiment when the game server performs a lottery. The flowchart in FIG. 12 illustrates an example of the operation of the lottery unit 113 during each of a plurality of unit periods included in the period during which the second-type lottery is held.

[0175] First, based on the information input from the administrator terminal 700, the lottery management unit 1132 records information related to the lottery, such as the period during which the second type lottery will be held, multiple types of game media that are the subject of the lottery, specific game media, the provision ratio of multiple types of game media that are the subject of the lottery, the number of specific game media that can be provided in a unit period, the type and amount of in-game currency that will be consumed to execute the lottery, and images that will be presented to the user when the lottery is executed, in the memory unit 116, and sets up the lottery.

[0176] When the lottery period begins, the lottery management unit 1132 becomes ready to accept a lottery holding request from the user terminal 200. The lottery unit 113 acquires a lottery execution request from the user terminal 200 via the communication unit 119 (step SB1). The user can make a lottery execution request for the second type lottery, for example, in the same way as when making a lottery execution request for the first type lottery in the first embodiment described above.

[0177] Based on the request to hold a lottery, the providing unit 1131 identifies the user and the lottery to be held, and holds the lottery by consuming the in-game currency owned by the user for the requested number of times of holding the lottery (step SB2).

[0178] The in-game currency consumed to execute the second type lottery may be a specific in-game currency among multiple types of in-game currencies (for example, in-game currency purchased with specific crypto assets). The in-game currency consumed to execute the second type lottery may be any of multiple types of in-game currencies purchased by the user with legal tender or crypto assets. Furthermore, the in-game currency consumed to execute the second type lottery may be any of multiple types of in-game currencies purchased by the user with crypto assets.

[0179] The providing unit 1131 associates one of the game media selected by lottery from the set of multiple types of game media that are the subject of the lottery with the user's identifier, records it in the storage unit 116, and provides the game media to the user (step SB3). The lottery management unit 1132 determines whether or not a specific game medium (G unit) has been won through the lottery executed by the provision unit 1131 (step SB4).

[0180] If the winning game medium is a specific game medium (G unit) (step SB4, YES), the lottery management unit 1132 updates the number of provided (or remaining) game mediums (G units) stored in the memory unit 116 (step SB5). Depending on the number of provided (or remaining) game mediums stored in the memory unit 116, the display processing unit 114 generates display data for displaying the screen 20 with updated values ​​for the displays 21, 211, and 212, and supplies the display data to the user terminal 200, causing the display to be updated.

[0181] If the winning game medium is not a specific game medium (G unit) (step SB4, NO), the lottery management unit 1132 does not update the number of provided (remaining) specific game media (G units), and the providing unit 1131 accepts a request to draw a first type lottery (step SB1), conducts the lottery (step SB2), and provides the winning game medium (step SB3). Note that the processing of steps SB4-SB5 and the processing of steps SB1-SB3 may be performed in parallel.

[0182] The stopping unit 1134 determines whether the number of specific game media (G units) provided stored in the storage unit 116 has reached a predetermined number (the maximum number provided to a user in a unit period) (the remaining number has reached zero) (step SB6). The processing of steps SB1 to SB6 is executed until the number of specific game media (G units) provided reaches the predetermined number (until the remaining number reaches zero).

[0183] When the number of specific game media (G units) provided reaches a predetermined number (remaining number becomes zero) (step SB6, YES), the stopping unit 1134 adjusts the provision ratio of multiple types of game media that are the subject of the second type lottery, thereby excluding the specific game media (G units) from the lottery subjects, and continues the second type lottery with multiple types of game media excluding the specific game media that has sold out (remaining number becomes zero) as the subject of the lottery (step SB7). Therefore, in this embodiment, when a specific game medium is sold out, the operation buttons 24 and 25 become selectable (active) on the screen 20 of FIG. 10, for example.

[0184] FIG. 13 is a diagram showing an example of the game media provision ratios that are the subject of a lottery set by the game server of one embodiment. Here, an example of the provision ratios of multiple types of game media after adjustment by the stopping unit 1134 is shown, so as to exclude specific game media (G units) from the lottery.

[0185] The stopping unit 1134, for example, sets the provision rate of a specific game medium (G unit) that has sold out (remaining quantity is zero) to 0%, adds the 0.0001% that was set as the provision rate of the specific game medium (G unit) to the provision rates of the other units, sets the total provision rate of all units eligible for the lottery to 100%, and excludes the specific game medium that has sold out from being eligible for the second type lottery.

[0186] 13, for example, the stopping unit 1134 adds 0.0001%, which was the provision rate of the specific game medium (G unit) that has sold out, to 84.9999%, which is the provision rate of other items. As a result, the provision rate of SR units is 1.50%, the provision rate of R units is 3.50%, the provision rate of N units is 10.00%, and the provision rate of other items is 85(84.9999+0.0001)%. Here, if the total provision rate of all units eligible for the lottery is 100%, the stopping unit 1134 may divide the provision rate of the sold-out unit (unit excluded from the lottery) and add it to the other multiple units.

[0187] For example, if the items to be drawn in the second type lottery include multiple types of specific game media (G units), the stopping unit 1134 adjusts the provision ratio so that, when the number of each of the multiple types of specific game media (G units) provided reaches a predetermined number (the remaining number becomes zero), the specific game media (G units) that have sold out (the remaining number becomes zero) are excluded from the items to be drawn in the second type lottery.

[0188] In addition, the stop unit 1134 notifies the display processing unit 114 that the specific game medium (G unit) has been sold out, and the display processing unit 114 generates display data for displaying a screen 20 including a message that the specific game medium (G unit) for the unit period has been sold out, provides this to the user terminal 200, and updates the display.

[0189] The stopping unit 1134 records the adjusted provision rate in the memory unit 116, and, for example, makes it possible to accept a request to hold a second-type lottery, with provision of the sold-out specific game media suspended until the start of the next unit period during the period in which the second-type lottery is held. The stopping unit 1134 resumes provision of the specific game media from the start of the next unit period. In other words, when the next unit period during which the second-type lottery is held starts, the stopping unit 1134 sets the provision rate of the game media to the initial setting value (the maximum number that can be provided to users in the unit period), and the number of specific game media (G units) that can be provided in the next unit period becomes the set maximum number (initial value).

[0190] For each of a plurality of unit periods included in the period during which the second-type lottery is held, the lottery unit 113 executes the processing of steps SB1 to SB7, and the game media selected by the lottery is provided to the user.

[0191] The game server 110, the lottery method, and the computer program of the present embodiment can achieve the same effects as those of the first embodiment. For example, according to the present embodiment, the maximum number of specific game media that can be provided to users in a unit period included in the lottery period is set as the object of the lottery, thereby increasing the motivation of users to participate in the lottery.

[0192] In the case of a second-type lottery in which the number of specific game media provided per unit period is limited, users will eagerly enter the second-type lottery in an attempt to acquire the specific game media before they are sold out. Furthermore, in the game provided by the game server 110 of this embodiment, the number of specific game media that have already been provided to users in a unit period is presented, so that users can recognize the number of specific game media that remain, and users who wish to obtain specific game media before other users are likely to more proactively execute the second type lottery in order to obtain the remaining specific game media.

[0193] Furthermore, game media with a limited number of offers may have a high degree of rarity, and in this embodiment, when the number of specific game media offered per unit period reaches a maximum, the provision of the specific game media is stopped. Therefore, it is thought that users will try to obtain a game medium with a high degree of rarity by entering a second type lottery before other users acquire the specific game medium and it is sold out.

[0194] That is, in the blockchain game provided by the game server 110 of this embodiment, it becomes possible to reduce the number of specific game media provided, further increasing the rarity of the specific game media and increasing their value after conversion to NFTs. As a result, it is possible to increase users' motivation to participate in the first type lottery and to convert the specific game media they have acquired into NFTs.

[0195] Furthermore, since requests for the second type lottery to be held continue to be accepted even after a specific game medium has been sold out, it is likely that users who wish to obtain a game medium with a high degree of rarity other than the specific game medium will continue to actively hold the second type lottery.

[0196] Furthermore, for example, by limiting the in-game currency consumed when requesting the execution of a second-type lottery to a specific in-game currency, a user who requests the execution of a second-type lottery will be required to make a payment to purchase the specific in-game currency, which will encourage users to make payments.

[0197] As described above, according to this embodiment, it is possible to provide a game server, a lottery holding method, and a computer program that increase users' motivation to participate in lotteries.

[0198] The present invention is not limited to the above-described embodiments, and various modifications can be made in the implementation stage without departing from the spirit of the invention. Furthermore, the embodiments may be implemented in appropriate combinations, in which case the combined effects can be obtained. Furthermore, the above-described embodiments include various inventions, and various inventions can be extracted by combining selected elements from the disclosed elements. For example, if the problem can be solved and the desired effect can be obtained even if some elements are deleted from all elements shown in the embodiments, the configuration from which these elements are deleted can be extracted as an invention.

[0199] In the above-mentioned first and second embodiments, the first type lottery and the second type lottery have been described as having a set period of time (a limited period of time), but the first type lottery and the second type lottery may also be set as permanent lotteries with no set period of time.

[0200] Furthermore, in the first embodiment, the display processing unit 114 may change the display mode of the icon for selecting the first type of lottery on the display of the user terminal 200 depending on whether the first type of lottery is being held or is being canceled. The display processing unit 114 may change the color of the icon for selecting the first type of lottery or make it blink, thereby displaying the icon on the display of the user terminal 200 in a mode that makes it possible to distinguish between whether the first type of lottery is being held or is being canceled.

[0201] Furthermore, in the second embodiment, the display processing unit 114 may change the display mode of the icon for selecting the second-type lottery on the display of the user terminal 200 depending on whether a specific game medium is excluded from the selection targets of the second-type lottery and whether a specific game medium is included as a selection target of the second-type lottery. The display processing unit 114 may change the color of the icon for selecting the second-type lottery or cause it to blink, thereby displaying the icon on the display of the user terminal 200 in a manner that makes it possible to distinguish whether a specific game medium is a neutral target in the second-type lottery.

[0202] Furthermore, in the first and second embodiments described above, the display processing unit 114 may display a specific game medium (first game medium) that may be provided in a unit period and other game media that are the subject of the lottery in different display modes on the display screen of the user terminal 200 when the first-type lottery and the second-type lottery are executed. For example, when the first-type lottery and the second-type lottery are executed, the display processing unit 114 may display, on the display of the user terminal 200, still images and videos that increase the user's expectation of winning a game medium with a high degree of rarity, or may display, on the display of the user terminal 200, still images and videos in which the display mode of the game media that are the subject of the lottery differs depending on the degree of rarity, such as emphasizing and making the specific game medium more noticeable than the other game media that are the subject of the lottery. [Explanation of symbols]

[0203] 100...game system, 110...game server, 111...processor, 112...sales department, 1121...first sales department, 1122...second sales department, 113...lottery department, 1131...providing department, 1132...lottery management department, 1133...cancellation department, 1134...stopping department, 114...display processing department, 115...play management department, 116...memory department, 117...input department, 118...output department, 119...communication department, 120...payment server, 121...processor, 122...payment processing department, 123...memory department, 124...input department, 125...output department, 126...communication department, 200...user terminal, 500...marketplace, 600...NFT server, 700...administrator terminal

Claims

1. a providing unit that executes a lottery by consuming a game medium owned by a user and provides one of a plurality of types of game medium to the user through the lottery; a storage unit that stores the number of first game media provided to the user through the lottery; A game server comprising: a canceling unit that cancels the execution of the lottery when the number of offers stored in the memory unit reaches a predetermined number.

2. a providing unit that executes a lottery by consuming a game medium owned by a user and provides one of a plurality of types of game medium to the user through the lottery; a storage unit that stores the number of first game media provided to the user through the lottery; A game server comprising: a stopping unit that, when the number of games provided stored in the memory unit reaches a predetermined number, stops providing the first game medium by lottery, with multiple types of game media excluding the first game medium as the subject of provision by lottery.

3. The game server according to claim 1 or claim 2, further comprising a display processing unit that presents the number of provided first game media stored in the storage unit to the user.

4. A game server as described in claim 1 or claim 2, wherein the game medium consumed to conduct the lottery is any one of multiple types of game medium that a user can purchase with legal tender or cryptocurrency.

5. The game server according to claim 4 , wherein the game medium consumed to execute the lottery is any one of a plurality of types of game medium that can be purchased by a user with cryptocurrency.

6. The game server of claim 2, wherein the stopping unit adds part or all of the provision rate of the first game medium to at least one of the multiple types of game media that are the subject of the lottery after the stopping, sets the provision rate of the first game medium to zero, and stops the provision of the first game medium.

7. 3. The game server according to claim 1, further comprising a display processing unit that presents to the user the provision rate of each of the plurality of types of game media provided by the lottery in a manner corresponding to the value of the provision rate.

8. A lottery is held by consuming a game medium owned by the user, and one of the plurality of types of game medium is provided to the user through the lottery; storing the number of first game media provided to the user through the lottery in a storage unit; A lottery execution method, wherein execution of the lottery is stopped when the number of offers stored in the memory unit reaches a predetermined number.

9. A lottery is held by consuming a game medium owned by the user, and one of the plurality of types of game medium is provided to the user through the lottery; storing the number of first game media provided to the user through the lottery in a storage unit; A lottery execution method in which, when the number of games provided stored in the memory unit reaches a predetermined number, the provision of the first game medium by the lottery is stopped, with multiple types of game media excluding the first game medium being subject to provision by the lottery.

10. A computer program that causes a computer to execute the lottery holding method according to claim 8 or 9.

Images