Game server, game operation method, computer program, and game system

Abstract

To provide a game server, a game operation method, a computer program, and a game system that allow a user to acquire an in-game asset while enjoying a game.SOLUTION: A game server 110 includes: a storage unit 118 in which a user ID of a user and history information on the game played by the user are associated and recorded, and a managing unit 114 for bringing about a first state in which the user possesses an optional in-game asset for a first period. When the history information associated with the user ID satisfies a first condition in the first period, the managing unit 114 brings about a second state in which the user possesses the optional in-game asset.SELECTED DRAWING: Figure 1

Description

[Technical field]

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

[0002] In conventional mobile online games and blockchain games, a function is implemented that allows players to obtain in-game assets (e.g., characters, items, etc.) through events that occur when quests are cleared, etc. In addition, in conventional mobile online games and blockchain games, a function is implemented that allows players to obtain in-game assets to be used in the game through random lotteries such as gacha.

[0003] In mobile online games and blockchain games that implement the above functions, the hurdle for users playing the game to obtain the in-game assets they desire can be adjusted by setting the difficulty level of quests and the probability of winning gacha. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2023-063358 A Summary of the Invention [Problem to be solved by the invention]

[0005] If the hurdle for acquiring in-game assets is too high, users may give up on acquiring the in-game assets, which may lead to users abandoning the game. Also, if the hurdle for acquiring in-game assets is too low, users who play the game with the goal of acquiring the in-game assets may lose their motivation to play the game, which may lead to users abandoning the game. For these reasons, if users can acquire the in-game assets they are aiming for while enjoying the game, it is possible to prevent users from abandoning the game.

[0006] The present invention has been made in consideration of the above-mentioned circumstances, and aims to provide a game server, a game operation method, a computer program, and a game system that provide a game in which users can acquire in-game assets while enjoying the game. [Means for solving the problem]

[0007] A game server according to a first aspect of the present invention comprises a memory unit in which a user's user ID and historical information of the user playing a game are recorded in association with each other, and a management unit that puts the user into a first state in which the user owns any in-game assets for a first period of time, and when the historical information associated with the user ID satisfies a first condition during the first period, the management unit puts the user into a second state in which the user owns any in-game assets.

[0008] A game operation method according to a second aspect of the present invention puts a user into a first state in which the user owns any in-game asset for a first period, and puts the user into a second state in which the user owns any in-game asset when historical information of the user playing a game during the first period, which is associated with the user's user ID and recorded in a memory unit, satisfies a first condition.

[0009] A computer program according to a third aspect of the present invention is a program for causing a computer to execute the game operating method according to the second aspect.

[0010] A game system according to a fourth aspect of the present invention includes the game server according to the third aspect; A game system comprising an NFT server that converts any in-game asset into an NFT (Non-Fungible Token) based on a request signal from the game server, wherein when the game server receives a conversion request signal to convert the any in-game asset associated with the user ID into an NFT, the game server transmits the request signal to the NFT server requesting that the any in-game asset be converted into the NFT in a manner indicating the existence of a history of the any in-game asset changing from the first state to the second state. Effect of the Invention

[0011] According to the present invention, it is possible to provide a game server, a game operation method, a computer program, and a game system that provide a game in which a user can acquire in-game assets while enjoying the game. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a game system according to an embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating an example of the configuration of the game system and the game server according to an embodiment. [Diagram 3] FIG. 3 is a flowchart illustrating an example of the lottery process in the game server of the embodiment. [Figure 4] FIG. 4 is a flowchart illustrating an example of the rewrite process in the game server of the embodiment. [Diagram 5] FIG. 5 is a flowchart illustrating an example of the period extension process in the game server of one embodiment. [Figure 6] FIG. 6 is a flowchart illustrating an example of NFT processing in a game server of an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] An example of a game system including a game server and an NFT server 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 already described will be given the same reference numerals and descriptions thereof will be omitted. FIG. 1 is a diagram illustrating an example of the configuration of a game system including a game server and an NFT server of one embodiment.

[0014] The game system 100 of this embodiment is, for example, a system that operates and manages a game using a blockchain (a blockchain game). Note that the game system 100 of this embodiment may be, for example, a system that operates and manages a mobile online game. In that case, in FIG. 1, the NFT server 130, the CEX 300, the DEX 400, and the marketplace 500 can be omitted.

[0015] The game system 100 is communicatively connected to a plurality of user terminals 200, a CEX (Centralized Exchange) 300, a DEX (Decentralized Exchange) 400, and a marketplace 500 via a network.

[0016] CEX300 is a virtual currency exchange operated by a specific company. In this embodiment, CEX300 transfers crypto assets 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 virtual currency transactions with the user terminal 200, and can transfer crypto assets to the user terminal 200 in response to a request from the user terminal 200.

[0017] DEX400 is a virtual currency exchange that does not have an operating company of the exchange and realizes the automatic exchange of crypto assets and tokens by smart contracts. DEX400 in this embodiment transfers crypto assets 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). DEX400 can also conduct virtual currency transactions with the user terminal 200, and can transfer crypto assets and tokens to the user terminal 200 in response to a request from the user terminal 200.

[0018] The marketplace 500 is an online platform where digital assets utilizing NFTs (Non-Fungible Tokens) can be bought, sold, and exchanged. A user who operates the user terminal 200 can convert in-game assets owned in the game system 100 into NFTs through a process described below, and sell the NFT-converted in-game assets on the marketplace 500. Examples of the marketplace 500 include TofuNFT (registered trademark) and OpenSea (registered trademark).

[0019] The user terminal 200, for example, has 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.

[0020] 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 smart watch, 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.

[0021] In this embodiment, the user terminal 200 is, for example, a smartphone, and is able to execute the blockchain game provided by the game system 100 by downloading and installing an application for a game using a blockchain provided by the game system 100. The user terminal 200 may also be, for example, a smartphone, and be able to execute the blockchain game provided by the game system 100 on a browser without downloading and installing an application for a game using a blockchain provided by the game system 100.

[0022] The game system 100 of this embodiment includes a game server 110 and an NFT server 130. The game server 110 and the NFT server 130 are connected to each other via a network so as to be able to communicate with each other.

[0023] The NFT server 130 is a server that performs NFT (conversion to NFT) by recording images (still images and videos), audio, and other types of digital files as unique and non-fungible data units (blocks) on a blockchain (distributed ledger). For example, the NFT server 130 can convert in-game assets in the game server 110 into NFTs upon request and provide the in-game assets converted into NFTs to a user. For example, the in-game assets of this embodiment may include characters, items that can be used in the game, weapons and equipment that can be worn by characters, cards for generating character skills, and the like.

[0024] The game server 110 is a server that provides a game using a blockchain that can be played by the user terminal 200. The game server 110 is a server that puts any in-game asset selected by lottery into a state (first state) in which the user owns it for a preset period (first period), and puts it into a state (second state) in which the user owns it if it is determined that a predetermined condition (first condition) is satisfied from historical information of the user's game play during the first period. That is, the first state is a state in which the in-game asset is provisionally owned by the user, and the second state is a state in which the in-game asset is owned by the user.

[0025] Next, an example of the configuration of the NFT server 130 and the game server 110 included in the game system 100 shown in FIG. 1 will be described. FIG. 2 is a block diagram illustrating an example of the configuration of a game server and an NFT server according to an embodiment.

[0026] The NFT server 130 includes, for example, at least one processor and a memory in which a program executed by the processor is recorded, and is configured to realize various functions by software or a combination of software and hardware. In this embodiment, the NFT server 130 includes a processor 131, a storage unit 133, an input unit 134, an output unit 135, and a communication unit 136. The processor 131, the storage unit 133, the input unit 134, the output unit 135, and the communication unit 136 are each connected via a bus communication line and can transmit and receive data to and from each other. The processor 131, the storage unit 133, the input unit 134, the output unit 135, and the communication unit 136 may be configured to transmit and receive data to and from each other via wireless communication or the like.

[0027] The input unit 134 is operated by an administrator of the NFT server 130 and may include a user interface such as a mouse or keyboard for inputting various information (e.g., information for changing numerical values ​​of various settings of the NFT server 130), and various sensors such as a microphone and a touch panel.

[0028] The output unit 135 includes, for example, a monitor that visually presents information to the administrator of the NFT server 130, and an audio output means such as a speaker that audibly supplies information to the administrator of the NFT server 130.

[0029] The communication unit 136 can transmit information received from the outside to the configuration within the NFT server 130, and can transmit information received from the configuration within the NFT server 130 to the outside. The communication unit 136 is communicatively connected between each of the game server 110, the user terminal 200, the CEX 300, the DEX 400, and the marketplace 500 via a network such as the Internet.

[0030] The storage unit 133 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 131 when performing various processes. The RAM may be used as a so-called work area for temporarily storing data when the processor 131 performs various processes. The main storage unit of this embodiment is, for example, a RAM, and is used as a memory.

[0031] The auxiliary storage unit is a non-transitory computer-readable storage medium of a computer centered around the processor 131. 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).

[0032] The auxiliary storage unit can store data used by the processor 131 when performing various processes, data generated by the processes in the processor 131, various setting values, and the like.

[0033] The processor 131 is typically a central processing unit (CPU) and / or a graphics processing unit (GPU), but may also be a microcomputer, a field programmable gate array (FPGA), a digital signal processor (DSP), or the like.

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

[0035] The processor 131 includes an NFT processing unit 132. The NFT processing unit 132 acquires a request signal from the conversion unit 116 included in the game server 110. The NFT processing unit 132 uses the digital data of the in-game assets, information on the creator of the digital data, and information on the owner of the digital data, which are included in the 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 and non-fungible data units. Note that the NFT processing of the in-game assets by the NFT processing unit 132 can use existing methods.

[0036] After the NFT processing is completed, the NFT processing unit 132 outputs an NFT processing completion notification to the conversion unit 116 via the communication unit 136. The NFT processing completion notification may include information such as information about the creator of the NFT, information about the owner of the NFT, identification information of the in-game assets that have been NFTed, and the date and time when the NFT processing was completed. The NFT processing unit 132 transmits data of the in-game assets for which the NFT processing has been completed to the user terminal 200 (or to the user terminal 200 via the game server 110) via the communication unit 136.

[0037] The game server 110, for example, has 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.

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

[0039] The input unit 119 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 (e.g., information for changing numerical values ​​of various settings of the game server 110), and various sensors such as a microphone or touch panel.

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

[0041] The communication unit 121 can transmit information received from the outside to the configuration within the game server 110, and can also transmit information received from the configuration within the game server 110 to the outside. The communication unit 121 is communicatively connected to the NFT server 130, the user terminal 200, the CEX 300, the DEX 400, and the marketplace 500 via a network such as the Internet.

[0042] The storage unit 118 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 111 when performing various processes. The RAM may be used as a so-called work area for temporarily storing data when the processor 111 performs various processes. The main storage unit of this embodiment is, for example, a RAM, and is used as a memory.

[0043] 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).

[0044] The auxiliary storage unit can store data used by the processor 111 when performing various processes, data generated by the processes in the processor 111, various setting values, etc. The auxiliary storage unit records game play history information of a user playing a game, information on in-game assets owned by the user, information on in-game currency owned by the user, game play history information of a user, event information for each in-game asset, and the user ID of the user playing the game, in association with each other.

[0045] The historical information may include various types of historical information associated with a user ID, each piece of information, and the corresponding date and time, such as historical information on charges, historical information on battles, historical information on logins, historical information on gacha, historical information on player level, historical information on character levels (character level information), historical information on character skills (character skill information), historical information on items equipped by characters (item equipment information), historical information on character strengthening, historical information on item purchases, historical information on events, historical information on the conversion of in-game assets into NFTs, and historical information on rankings.

[0046] The information on the user's in-game assets includes a character ID owned by the user, an item ID owned by the user, and an equipment ID (dedicated equipment ID) owned by the user. The character ID, item ID, and equipment ID are stored in the storage unit 118 in association with the user ID.

[0047] Information on the in-game currency owned by a user includes, for example, the number of paid stones purchased by the user (number of paid stones purchased), the number of free stones owned by the user (number of free stones owned), the date and time of the paid stone purchase, and the price of the paid stones. The number of paid stones purchased, the number of free stones owned, the date and time of the paid stone purchase, and the price of the paid stones are associated with the user ID.

[0048] The storage unit 118 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 118 may be shared between the game server 110 and the NFT server 130.

[0049] 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 118.

[0050] The processor 111 includes a play management unit 112 and a display processing unit 117 . The play management unit 112 acquires operation information from the user terminal 200 via the communication unit 121, and progresses the game provided by the game server 110 based on the operation information. As the game progresses by the play management unit 112, the display processing unit 117 generates display data for updating the display of the user terminal 200 and supplies the display data to the user terminal 200.

[0051] The play management unit 112 also has a function of managing the play of users of the game provided by the game server 110. The play management unit 112, for example, manages in-game assets such as characters and items that are temporarily owned or owned by users in the game, manages battles that users perform using characters, manages events such as gacha and in-game tournaments that users perform, manages the strengthening and levels of users and in-game assets, and manages the conversion of in-game assets into NFTs.

[0052] The play management unit 112 has a function of managing information (play information) obtained by a user playing a game, and for example, when a user performs initial setup of a game on the user terminal 200, it generates a user ID and begins managing the user's play information.

[0053] The play management unit 112 has, for example, a function for managing information on in-game assets that a user obtains by playing a game (in-game asset information management function), and a function for managing information on a user that a user obtains by playing a game (user information management function).

[0054] For example, when a user strengthens a character by playing a game, the in-game asset information management function records in memory unit 118 the user's ID, the character's ID, identification information for the strengthening performed, and the date and time of the strengthening in association with each other.

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

[0056] In addition, the in-game asset information management function, for example, when a user plays a game and causes a character to fight, associates the user ID, the character ID, the battle ID, the date and time the battle took place, and the battle result, and records them in the memory unit 118.

[0057] 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 ID, the character ID, the item ID, and the date and time of the equipment in the storage unit 118. 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 ID, the character ID, the item ID, and the date and time of the equipment with an exclusive equipment ID and record them in the storage unit 118.

[0058] Furthermore, for example, when a user performs a gacha, the in-game asset information management function associates the user's ID, the date and time when the gacha was performed, and the result of the gacha (for example, an in-game asset ID (owned ID described below) randomly selected by performing the gacha) and records them in the memory unit 118. For example, the in-game asset ID may include a switching flag that switches whether or not the user can use the in-game asset in the game. The in-game asset information management function may switch the switching 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 the in-game asset is unusable. An in-game asset that is unusable may be treated as not owned by the user on the game play screen.

[0059] In addition, the in-game asset information management function, for example, when an event corresponding to any in-game asset occurs, associates the user ID, the in-game asset ID (character ID), the date and time when the event occurred, the event period, the number of times the event occurred, and the content of the event, and stores them in the memory unit 118.

[0060] In addition, for example, when a user grants a specific item to an arbitrary in-game asset, the in-game asset information management function associates the user ID, character ID, date and time when the item was granted, and item ID of the granted item, and stores them in the memory unit 118.

[0061] In addition, 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 ID, the ID 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 ID, and records them in the memory unit 118.

[0062] 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 ID, the ID of the NFTed in-game assets, the date and time when the NFT was made usable in the game, and the NFT ID, and records them in the memory unit 118.

[0063] The user information management function, for example, when a user plays a game and is charged, records the user ID, the charged amount, and the charging date and time in the storage unit 118 in association with each other.

[0064] In addition, for example, when a user logs in, the user information management function associates the user ID with the login date and time and records them in the memory unit 118, and when the user logs out, the user ID associates the user ID with the logout date and time and records them in the memory unit 118.

[0065] In addition, the user information management function, for example, when a user increases their player level by playing a game, associates the user ID, the user level, and the date and time when the user level was increased, and records them in the memory unit 118.

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

[0067] Furthermore, the user information management function, for example, records information on a user's ranking as a result of the user playing a game in association with the user ID in the storage unit 118. For example, the ranking information may include information such as the ranking when the user participated in a tournament within the game, and the ID of the in-game asset (character or item) used by the user in the tournament.

[0068] The play management unit 112 includes a lottery unit 113, a management unit 114, an event generation unit 115, and a conversion unit .

[0069] The lottery unit 113 obtains history information from the storage unit 118 by detecting a predetermined trigger, and randomly selects any in-game asset from among multiple in-game asset candidates based on the history information. Here, the lottery unit 113 obtains the in-game asset candidates from the storage unit 118. Note that multiple in-game assets that are candidates for the random lottery are stored in advance in the storage unit 118 by an administrator of the game server 110, etc.

[0070] The candidates for the in-game assets include, for example, a certain number of different characters. Note that the candidates for the in-game assets may each form a cluster of, for example, a plurality of different characters, a plurality of different pieces of equipment, and a plurality of different items, and a specific character may be associated with a specific piece of equipment and a specific item.

[0071] The lottery unit 113 associates an in-game asset ID corresponding to the randomly selected in-game asset, a user ID, and the date and time when the in-game asset was randomly selected, and transmits them to the management unit 114. Furthermore, the lottery unit 113 may also associate an in-game asset ID corresponding to the randomly selected in-game asset, a user ID, and the date and time when the in-game asset was randomly selected, and record them in the storage unit 118 as a lottery result history.

[0072] For example, when the selection unit 113 detects the end of a battle between a character operated by a user and an enemy character, it acquires battle information with the character included in the history information from the storage unit 118, and if the battle information satisfies a condition (for example, defeat of a character), it randomly selects an arbitrary in-game asset from among candidates for in-game assets. In addition, when the selection unit 113 detects that a character operated by a user has finished a quest, it may acquire quest information included in the history information from the storage unit 118, and if the quest information satisfies a condition (for example, quest completion), it may randomly select an arbitrary in-game asset from among candidates for in-game assets.

[0073] Furthermore, the lottery unit 113 may be able to randomly select a specific character included in a plurality of in-game asset candidates after a specific quest is accomplished. Furthermore, the lottery unit 113 may vary the probability of random selection according to the rarity of a specific character included in the in-game asset candidates. For example, the lottery unit 113 sets the selection probability of the rarest character to the lowest, and sets the selection probability of the least rare character to the highest. The lottery unit 113 may be able to increase the selection probability of a character with a high rarity and decrease the selection probability of a character with a relatively low rarity according to the achievement of a condition. Note that the rarity of a character is set based on the strength, rarity, etc. of the character.

[0074] Furthermore, the lottery unit 113 may randomly select a character from a character cluster included in multiple in-game asset candidates, randomly select an equipment from an equipment cluster, and randomly select an item from an item cluster. In this case, the randomly selected equipment and item will be equipped and possessed by the randomly selected character. The lottery unit 113 associates the character ID of the randomly selected character, the equipment ID of the equipment, and the item ID of the item, and transmits them to the management unit 114. Furthermore, the lottery unit 113 may associate the character ID, the equipment ID, and the item ID of the randomly selected character, and record them in the storage unit 118 as a history of the lottery results.

[0075] In addition, the lottery unit 113 may randomly select a character from a character cluster included in multiple in-game asset candidates, select equipment associated with the randomly selected character from an equipment cluster, and select an item associated with the randomly selected character from an item cluster.

[0076] The lottery unit 113 excludes any randomly selected in-game asset from the multiple in-game asset candidates. For example, the lottery unit 113 excludes a randomly selected character from the multiple in-game asset candidates. The lottery unit 113 may also exclude a randomly selected piece of equipment and a randomly selected item from the multiple in-game asset candidates. The lottery unit 113 may also exclude a randomly selected character from the multiple in-game asset candidates, and may also exclude an equipment item and an item associated with the character from the multiple in-game asset candidates.

[0077] When the first period has elapsed while the character remains in the first state, the lottery unit 113 sets a waiting period (second period) and adds the randomly selected excluded in-game asset to the multiple in-game asset candidates after the waiting period has elapsed. The waiting period is set in advance by an administrator of the game server 110 or the like and is changed as appropriate. The waiting period may also be set according to the rarity of the character. For example, the higher the rarity of the character, the longer the waiting period may be set, and the lower the rarity of the character, the shorter the waiting period may be set. The waiting period may also be set according to an index (such as favorability rating) corresponding to the character in the first state. The index corresponding to the character in the first state will be described later.

[0078] The management unit 114 acquires an in-game asset ID randomly selected from the lottery unit 113 and attribute information of the in-game asset included in the in-game asset. The management unit 114 also acquires history information associated with the user ID from the memory unit 118. The attribute information includes state information of any in-game asset. For example, the attribute information is composed of three flags. The unowned flag represents a state in which the in-game asset is not owned by the user. The temporary owned flag represents a state in which the in-game asset is temporarily owned by the user. The owned flag represents a state in which the in-game asset is owned by the user. Note that the attribute information of any in-game asset randomly selected by the lottery unit 113 is assumed to have a temporary owned flag set to 1.

[0079] In this embodiment, the in-game asset ID of an in-game asset having attribute information where the unowned flag is 1 and the temporary owned flag and the owned flag are 0 is referred to as a unowned ID, the in-game asset ID of an in-game asset having attribute information where the temporary owned flag is 1 and the unowned flag and the owned flag are 0 is referred to as a temporary owned ID, and the in-game asset ID of an in-game asset having attribute information where the owned flag is 1 and the unowned flag and the owned flag are 0 is referred to as an owned ID.

[0080] The management unit 114 determines the state of any in-game asset from the acquired attribute information. When the management unit 114 detects from the attribute information of a randomly selected in-game asset that the temporary ownership flag is 1 and the non-ownership flag and the ownership flag are 0, the management unit 114 records the temporary ownership ID, the user ID, and the date and time information in association with each other in the storage unit 118. That is, the first state is a state in which the temporary ownership ID that causes the user to own any in-game asset for a first period and the user ID are associated and stored in the storage unit 118. Note that the first period is set in advance by an administrator of the game server 110 or the like, and is changed as appropriate. The first period may be set according to the rarity of the in-game asset (character).

[0081] The management unit 114 determines whether the acquired history information satisfies a first condition during the first period. For example, the management unit 114 determines whether parameter information of a character in a first state during the first period satisfies a predetermined threshold. The parameter information of a character includes, for example, favorability rating, intimacy rating, growth level, popularity level, and the like. To be more specific, the favorability rating of a character (intimacy rating, growth level, or popularity level) starts with an initial value of 0, and can be increased when a user uses a character to fight or engage in a quest, gives a gift to a character, or performs a gacha. For example, when a user performs a gacha, the user obtains a fragment corresponding to a character. The user can increase the character's favorability rating by collecting a certain number of fragments corresponding to the character. As a specific example, when the user obtains n fragments corresponding to a character, the favorability rating increases by 1. When the user obtains fragments equivalent to a preset favorability threshold (if the favorability threshold is 10, the number of fragments is 10n), the management unit 114 determines that the history information satisfies the first condition. Note that the number of fragments required to increase the favorability rating may be set for each character, or may be set according to the rarity of the character.

[0082] In addition, the management unit 114 determines whether the favorability rating of a character in the first state meets a predetermined threshold value by engaging in normal battles or specific battles during the first period. Note that normal battles are unlocked as the story or scenario progresses. The number of times that specific battles can be performed in one day may be preset. In addition, the number of times that specific battles can be performed in one day may be set according to the rarity of the character, and the upper limit on the number of times that specific battles can be performed in one day may be released by using paid stones, etc.

[0083] In addition, the management unit 114 determines whether the favorability rating meets a predetermined threshold value by completing a normal quest or a specific quest using a character in the first state during the first period. Note that the normal quest is one that is unlocked as the story or scenario progresses. The specific quest may be set differently for each character, or may be set according to the rarity of the character.

[0084] Furthermore, the management unit 114 determines whether the paid stone usage information satisfies a predetermined threshold during the first period. More specifically, the management unit 114 determines whether the number of times the user has used paid stones on a character in the first state during the first period satisfies a predetermined threshold. The management unit 114 may determine whether the user has equipped a character in the first state with equipment or an item purchased using paid stones during the first period.

[0085] Furthermore, the management unit 114 determines whether the character level information satisfies a predetermined threshold during the first period. More specifically, the management unit 114 determines whether the level of the character in the first state satisfies a predetermined threshold during the first period.

[0086] When the management unit 114 determines that the acquired history information satisfies the first condition during the first period, it rewrites the temporary ownership ID associated with the user ID to an ownership ID that brings the in-game asset into the second state. More specifically, the management unit 114 rewrites the temporary ownership flag included in the attribute information of the arbitrary in-game asset from 1 to 0, and rewrites the ownership flag from 0 to 1. The second state is a state in which an ownership ID that brings the arbitrary in-game asset into a state in which the user owns the arbitrary in-game asset is associated with the user ID and stored in the storage unit 118. The management unit 114 records in the storage unit 118 as history information that the arbitrary in-game asset has changed from the first state to the second state.

[0087] Furthermore, when the management unit 114 determines that the acquired history information does not satisfy the first condition at the end of the first period, it rewrites the temporarily owned ID associated with the user ID to an unowned ID that brings the user into a third state. More specifically, the management unit 114 rewrites the temporarily owned flag included in the attribute information of any in-game asset from 1 to 0, and rewrites the unowned flag from 0 to 1. The third state is a state in which an unowned ID that brings the user into a state in which the user does not own any in-game asset is associated with the user ID and is stored in the storage unit 118.

[0088] Furthermore, even if the management unit 114 rewrites a temporarily owned ID to an owned ID, or even if the management unit 114 rewrites a temporarily owned ID to a non-owned ID, the character's parameter information, paid stone usage information, and character level contained in the history information will not be reset.

[0089] In this embodiment, an example is given of a transition from a first state to a second state in which a user transitions from a state in which the user temporarily owns an in-game asset to a state in which the user owns the asset indefinitely, but this is not limited thereto, and for example, the first state may be divided into a plurality of states in stages.

[0090] Furthermore, when the event generating unit 115, which will be described later, generates an event corresponding to any in-game asset during the first period, the management unit 114 acquires an event occurrence notification from the event generating unit 115. The management unit 114 acquires the event period of the event corresponding to any in-game asset included in the event occurrence notification, and determines whether the history information satisfies the first condition during the period during which the event occurs. Specifically, the event in this embodiment is a withdrawal event. The withdrawal event is an event that occurs during the first period when the parameter information of a character in a first state does not satisfy a predetermined threshold value.

[0091] For example, the management unit 114 determines whether the parameter information of the character in the first state satisfies a predetermined threshold during the period when the event is occurring. The parameter information of the character is the same as above, and includes favorability rating, intimacy rating, growth level, popularity level, etc. During the period when the event is occurring, the rate of increase in the favorability rating (intimacy rating, growth level, or popularity level) of the character may be changed. During the period when the event is occurring, the favorability rating can be increased when the user uses the character to fight or engage in a quest, gives a gift to the character, plays gacha, etc. For example, the setting may be such that when a user performs a gacha during a period when no event is occurring, the user can obtain at least one piece corresponding to the character, and when a user performs a gacha during a period when an event is occurring, the user can obtain more pieces than during a period when no event is occurring, or the number of pieces may be less than during a period when no event is occurring, or may be set to 0. A user can increase the favorability of a character by collecting a certain number of pieces corresponding to the character. As a specific example, when n pieces corresponding to a character are obtained, the favorability increases by 1. When a user obtains pieces equivalent to a preset favorability threshold (if the favorability threshold is 10, the number of pieces is 10n), the management unit 114 determines that the history information satisfies the first condition. The number of pieces necessary to increase the favorability may be set for each character, or may be set according to the rarity of the character.

[0092] In addition, the management unit 114 determines whether the favorability level of a character in the first state meets a predetermined threshold by engaging in a normal battle or a specific battle during a period in which an event occurs. The normal battle is unlocked as the story or scenario progresses. The number of times that a specific battle can be performed in one day during a period in which an event does not occur and a period in which an event occurs may be preset to the same number, and the number of times that a specific battle can be performed in one day during a period in which an event does not occur and a period in which an event occurs may be preset to different numbers. In addition, even during a period in which an event occurs, the number of times that a specific battle can be performed in one day may be set according to the rarity of the character, and the upper limit of the number of times that a specific battle can be performed in one day may be released by using paid stones, etc.

[0093] Furthermore, the management unit 114 determines whether the favorability rating meets a predetermined threshold value by completing a normal quest or a specific quest using a character in the first state during a period when an event is occurring. Note that a normal quest is one that is unlocked as a story or scenario progresses. The specific quest during a period when no event is occurring and the specific quest during a period when an event is occurring may be the same or different. Also, during a period when an event is occurring, the favorability rating may be set differently for each character, or may be set according to the rarity of the character.

[0094] The management unit 114 also determines whether the paid stone usage information satisfies a predetermined threshold during the period when the event occurs. More specifically, the management unit 114 determines whether the number of times the user has used paid stones on a character in the first state during the period when the event occurs satisfies a predetermined threshold. The management unit 114 may also determine whether the user has equipped a character in the first state with equipment or an item purchased using paid stones during the period when the event occurs.

[0095] In addition, the management unit 114 determines whether the character level information satisfies a predetermined threshold during the period in which the event occurs. More specifically, the management unit 114 determines whether the level of the character in the first state satisfies a predetermined threshold during the period in which the event occurs.

[0096] When the management unit 114 determines that the acquired history information satisfies the first condition during the period in which the event occurs, the management unit 114 rewrites the temporary ownership ID associated with the user ID to an ownership ID to be put into the second state. More specifically, the management unit 114 rewrites the temporary ownership flag included in the attribute information of any in-game asset from 1 to 0, and rewrites the ownership flag from 0 to 1.

[0097] Furthermore, when the management unit 114 determines that the first period has ended and the acquired history information does not satisfy the first condition at the end of the period during which the event occurs, the management unit 114 rewrites the temporarily owned ID associated with the user ID to a non-owned ID that is set to the third state. More specifically, the management unit 114 rewrites the temporarily owned flag included in the attribute information of any in-game asset from 1 to 0, and rewrites the non-owned flag from 0 to 1.

[0098] Furthermore, the management unit 114 obtains the event period of the event corresponding to any in-game asset included in the event occurrence notification, and determines whether the history information satisfies the second condition during the period during which the event occurs. For example, the management unit 114 determines whether the user has given a specific item to a character in the first state during the period during which the event occurs. The specific item may be common to all characters, or may be set to be different for each character.

[0099] When the management unit 114 determines that the history information satisfies the second condition during the period in which the event occurs, the management unit 114 extends a first period corresponding to any in-game asset. Specifically, when the management unit 114 determines that the user has given a specific item to a character in the first state during the period in which the withdrawal event occurs, the management unit 114 extends the first period, which is the period in which the character is in the first state, according to the specific item. Furthermore, when the management unit 114 determines that the user has given a specific item to a character in the first state during the period in which the withdrawal event is occurring, it increases the favorability rating of the character in accordance with the specific item. The extension period and the rate of increase in favorability may be the same for all characters or may be different, and may be set according to the rarity of a particular item or the number of paid stones used when purchasing a particular item.

[0100] The event generating unit 115 acquires event information associated with the in-game asset ID of the randomly selected in-game asset from the storage unit 118. The event information includes an event for each character included in the in-game asset, an event occurrence frequency, and the number of times the event occurs. The event generating unit 115 generates an event corresponding to the randomly selected in-game asset based on the event information during a first period.

[0101] The event generating unit 115 generates an event at any timing during the first period based on the event occurrence frequency. Furthermore, the event generating unit 115 generates an event at least once during the first period based on the number of events. For example, the event generating unit 115 may generate an event at equal intervals, or may not generate an event from immediately after the start of the first period until the middle of the period, and may generate an event from the middle of the period until just before the end of the first period. Furthermore, the event generating unit 115 may set the event occurrence frequency according to the rarity of the in-game assets (characters).

[0102] After generating an event corresponding to any in-game asset, the event generating unit 115 transmits an event occurrence notification to the management unit 114. The event occurrence notification includes, for example, the in-game asset ID of the character in the first state, the user ID associated with the in-game asset ID, and information on the event period.

[0103] The display processing unit 117 generates display data for displaying any in-game asset randomly selected by the lottery unit 113 on the display of the user terminal 200. The display processing unit 117 transmits the generated display data to the user terminal 200 via the communication unit 121, and can cause the user terminal 200 to present the in-game asset randomly selected to the user. The display processing unit 117 also generates display data for displaying an aspect representing the current state of each character on the display of the user terminal 200.

[0104] The conversion unit 116 has a function of making in-game assets associated with a user ID convertible into an NFT (Non-Fungible Token) when the historical information associated with the user ID satisfies certain conditions (NFT conditions).

[0105] The conversion unit 116 receives a conversion request signal requesting the conversion of in-game assets into NFTs from the user terminal 200 via the communication unit 121. The conversion request signal includes the user's user ID and the ID of the in-game assets that the user wishes to convert into NFTs.

[0106] The conversion unit 116 acquires history information associated with the corresponding user ID from the storage unit 118 in response to a conversion request signal acquired from the user terminal 200 via the communication unit 121. When the acquired history information satisfies a predetermined condition, the conversion unit 116 enables the in-game assets associated with the user ID to be converted into NFTs.

[0107] In addition, when historical information associated with a user ID in the memory unit 118 satisfies certain conditions, the conversion unit 116 may wait for conversion request information from the user terminal 200 after making the in-game assets associated with the user ID convertible into NFTs.

[0108] When history information associated with the user ID satisfies a predetermined condition, the conversion unit 116 may be able to convert the in-game assets associated with the user ID into NFTs and at the same time, may be able to convert the display mode of the in-game assets convertible to NFTs in the game. For example, the in-game assets convertible to NFTs may be able to be converted into a display mode (such as color, shape, appearance, facial expression, background, size, or making a stationary character perform a specific action) different from other in-game assets, and may be able to convert the sound, background music, video, video, entrance effects, special move effects, etc., of the in-game assets convertible to NFTs.

[0109] The conversion unit 116 may also set a predetermined condition for enabling conversion to NFT for each of a plurality of in-game assets associated with a user ID. For example, the conversion unit 116 has a function of setting different predetermined conditions to be satisfied when a character associated with a user ID is convertible to an NFT and when an item associated with a user ID is convertible to an NFT. Also, for example, the conversion unit 116 has a function of setting different predetermined conditions to be satisfied when a first character associated with a user ID is convertible to an NFT and when a second character associated with a user ID is convertible to an NFT.

[0110] The conversion unit 116 may determine that a character (in-game asset) owned by a user can be turned into an NFT if the level of that character is equal to or higher than a threshold. The conversion unit 116 may determine that a predetermined condition is met if the current (at the time of determination) character level of a character that the user wishes to turn into an NFT exceeds a threshold based on character level information included in history information associated with the user's ID.

[0111] Furthermore, when a specific ID such as an awakening ID is given to the character from the history of character level information included in the history information associated with the user ID, the conversion unit 116 may determine that the character satisfies a predetermined condition. The awakening ID is an ID indicating, for example, that the level of a character in the game has reached a certain level, or that the character's level has exceeded the limit of its ability value and become capable of being strengthened (awakened) after reaching a certain level, and is associated with the character's identification information together with the date and time when the character was awakened and recorded in the storage unit 118.

[0112] In addition, if the item equipment information included in the history information associated with the user ID indicates that the character that the user wishes to turn into an NFT has been assigned a specific equipment ID, such as an equipment ID indicating that the character is equipped with exclusive equipment, the conversion unit 116 may determine that the specified conditions are met.

[0113] If the character strengthening information included in the history information indicates that the number of times a character has been strengthened in the past is equal to or greater than a threshold, the conversion unit 116 may determine that a specified condition is satisfied. Also, if the past battle information included in the history information indicates that a specific quest has been cleared using a character, the conversion unit 116 may determine that a specified condition is satisfied.

[0114] Other examples of the predetermined condition for the conversion unit 116 include a case where an item or equipment is purchased with paid stones, or a case where paid stones or free stones are used to strengthen a character owned by the user. When the number of times that the user has purchased an item or equipment with paid stones exceeds a threshold based on the item purchase information included in the history information, the conversion unit 116 may determine that the predetermined condition is satisfied. In addition, when the number of times that the user has strengthened a character using in-game currency (paid stones or free stones) exceeds a threshold based on the character strengthening information included in the history information, the conversion unit 116 may determine that the predetermined condition is satisfied.

[0115] When the conversion unit 116 acquires a conversion request signal and the historical information associated with the user ID satisfies certain conditions, it makes the in-game assets associated with the user ID convertible into NFTs, and generates a request signal requesting the NFT server 130 to convert the in-game assets into NFTs.

[0116] In addition, when the conversion unit 116 acquires a conversion request signal and the history information associated with the user ID satisfies a predetermined condition, it may make the in-game assets in the second state associated with the user ID in a state that is convertible to an NFT in a manner that indicates the existence of a history of the first state changing to the second state, and generate a request signal requesting the NFT server 130 to convert the in-game assets into an NFT.

[0117] The request signal includes at least digital data such as image data corresponding to the in-game assets to be NFT'd, information on the creator of the in-game assets to be NFT'd, and information on the owner of the in-game assets to be NFT'd. Note that the information on the creator of the in-game assets and the information on the owner may be the same information, and the information on the creator of the in-game assets and the information on the owner may include a user ID in the game. The conversion unit 116 transmits a request signal to the NFT server 130.

[0118] When the conversion unit 116 receives an NFT process completion notification from the NFT server 130 (information about the creator of the NFT, information about the owner of the NFT, identification information of the in-game assets that have been NFTed, and the date and time when the NFT process was completed), it puts the in-game assets for which the NFT process has been completed and which are associated with the user ID and stored in the memory unit 118 into a state where they are not owned by the user in the game. In other words, when the conversion unit 116 receives an NFT process completion notification from the NFT server 130, it switches the switching flag for the in-game assets for which the NFT process has been completed, making the in-game assets unusable by the user in the game.

[0119] In addition, the conversion unit 116 may be configured to make it possible to convert the display mode of the in-game assets when NFTed (to make it possible to send a display mode change request from the user terminal 200 to the game server 110) when the historical information associated with the user ID satisfies a condition (display mode change condition) different from the above-mentioned specified condition (NFT condition).

[0120] If the in-game asset to be NFTed is a game character, the conversion unit 116 may generate digital data that changes the display mode of the character requesting NFT when generating a request signal for the in-game asset. For example, when the conversion unit 116 acquires a request to change the display mode from the user terminal 200 via the communication unit 121, the conversion unit 116 may generate a request signal so that the NFTed character is smiling (having a predetermined facial expression) while the character is displayed on the user terminal 200 with a straight face (no facial expression) in the game.

[0121] For in-game assets whose display mode can be changed, image data in a plurality of display modes may be stored in advance in the storage unit 118. In addition, the conversion unit 116 may combine image data of the in-game assets to be converted into NFT with other image data, for example, to generate image data with a different display mode for the in-game assets. The display mode change request may be, for example, a facial expression change request, or a background image change request to use a predetermined background image.

[0122] For example, when a specific ID such as an awakening ID is given to a character based on character level information included in the history information, and when a different specific ID such as an awakening ID is given by further raising the level after the awakening ID is given, the conversion unit 116 may determine that the display mode change condition is satisfied. Also, when the number of times in-game assets associated with a user ID included in the history information have been converted to NFTs in a predetermined period is equal to or greater than a set threshold, the conversion unit 116 may determine that the display mode change condition is satisfied.

[0123] Furthermore, when a user who participated in a tournament in a blockchain game achieves a ranking equal to or higher than a threshold based on the ranking information included in the history information, the conversion unit 116 may determine that the display mode change condition is satisfied. In this case, when converting the character or item used by the user in the tournament, i.e., the in-game assets associated with the user ID included in the ranking information, into NFTs, the conversion unit 116 may have a function that enables the display mode to be changed, such as by displaying the ranking and tournament prizes (items and backgrounds corresponding to the ranking) together with an image of the in-game assets, or by changing the character's facial expression or posture according to the ranking.

[0124] Furthermore, the conversion unit 116 may receive from the user terminal 200 a return request signal (including a user ID, an in-game asset ID, an NFT ID, and NFT data) that includes an NFT (in-game assets for which NFT conversion has been completed) and requests that the NFT be used again in the game. The conversion unit 116 may have a function of switching a switching flag for the in-game assets for which NFT conversion has been completed and that are stored in the storage unit 118, based on the NFT ID included in the received return request signal, to make the in-game assets for which NFT conversion has been completed usable in the game, and to change the ability value of the in-game assets for which NFT conversion has been completed.

[0125] For example, when the conversion unit 116 receives a restoration request signal from the user terminal 200, it acquires character level information of the in-game assets (characters and items usable in the game, weapons and equipment that can be worn by characters, cards for generating character skills, etc.) for which the NFT process has been completed and which are to be restored from the storage unit 118. The conversion unit 116 may change parameters such as the level of the in-game assets for which the NFT process has been completed based on the character level information. For example, the conversion unit 116 may increase or decrease the character level of the in-game assets for which the NFT process has been completed.

[0126] Furthermore, when the conversion unit 116 receives a return request signal from the user terminal 200, it acquires from the storage unit 118 character skill information of the in-game assets (characters and items usable in the game, weapons and equipment that can be worn by characters, cards for generating character skills, etc.) for which the NFT process has been completed and which are to be returned. The conversion unit 116 may change parameters such as skills for the in-game assets for which the NFT process has been completed based on the character skill information. For example, the conversion unit 116 may impart a new skill to the in-game assets for which the NFT process has been completed, or may strip existing skills from them.

[0127] Furthermore, when the conversion unit 116 receives a return request signal from the user terminal 200, it may set the ability values ​​(character level information, character skill information, item equipment information, etc.) of the in-game assets to be returned and for which the NFT process has been completed to initial values, or may set them to the ability values ​​at the time of NFT. Furthermore, when the conversion unit 116 receives a return request signal from the user terminal 200, it may change parameters such as ability values ​​of the in-game assets to be returned and for which the NFT process has been completed.

[0128] Furthermore, if the information on the creator of the in-game assets for which the NFT conversion process has been completed to be restored, which is included in the NFT of the return request signal received from the user terminal 200, differs from the information on the owner of the in-game assets for which the NFT conversion process has been completed to be restored (for example, when the NFT has been bought and sold), the conversion unit 116 obtains the information on the in-game assets for which the NFT conversion process has been completed from the storage unit 118, and associates it with the user ID included in the return request signal of the user terminal 200. The conversion unit 116 may set the ability value based on the information on the in-game assets associated with the user ID, or may set the ability value to an initial value.

[0129] An example of the lottery process, rewrite process, and period extension process of the game server 110 will be described below with reference to the drawings. FIG. 3 is a flowchart illustrating an example of the lottery process in the game server of the embodiment. FIG. 4 is a flowchart illustrating an example of the rewrite process in the game server of the embodiment. FIG. 5 is a flowchart illustrating an example of the period extension process in the game server of one embodiment.

[0130] In this embodiment, the lottery process, the rewrite process, and the period extension process are started at any timing. The lottery unit 113 judges whether the lottery occurrence condition is met (step S1). The lottery unit 113 waits without performing any process until the lottery occurrence condition is met (step S1, NO).

[0131] When the lottery unit 113 determines that the lottery generating condition is met (step S1, YES), it randomly selects an arbitrary in-game asset from among a plurality of in-game asset candidates (step S2).

[0132] The lottery unit 113 excludes the randomly selected arbitrary in-game asset from the multiple in-game asset candidates (step S3).

[0133] In this embodiment, the rewrite process starts when the process of step S3 ends. The management unit 114 acquires an in-game asset ID of an in-game asset randomly selected from the lottery unit 113 and attribute information of the in-game asset included in the in-game asset. The management unit 114 also acquires history information associated with the user ID from the storage unit 118. From the attribute information of any acquired in-game asset, the management unit 114 detects that the temporary ownership flag is 1 and the unowned flag and the owned flag are 0, and records the temporary ownership ID, the user ID, and date and time information in association with each other in the storage unit 118 (step S4).

[0134] The management unit 114 uses the history information acquired from the storage unit 118 to determine whether the history information satisfies the first condition during the first period (step S5). If the management unit 114 determines that the acquired history information during the first period satisfies the first condition (step S5, YES), it rewrites the temporary owned ID associated with the user ID to an owned ID to be put into the second state (step S6), and ends the process.

[0135] If the management unit 114 determines that the acquired history information does not satisfy the first condition during the first period (step S5, NO), it determines whether the first period has elapsed (step S7). If the management unit 114 determines that the first period has not elapsed (step S7, NO), the event occurrence unit 115 determines whether it is time for the event to occur based on the event occurrence frequency included in the event information acquired from the storage unit 118 (step S8).

[0136] If the event generating unit 115 determines that it is not the timing for an event to occur based on the event occurrence frequency (step S8, NO), the process returns to step S5. If the event generating unit 115 determines that it is the timing for an event to occur based on the event occurrence frequency (step S8, YES), the process proceeds to step S9.

[0137] The event generation unit 115 determines whether the event has occurred a specified number of times based on the number of events included in the event information acquired from the storage unit 118 (step S9). For example, if the specified number of events for a given in-game asset is three times, the event generation unit 115 determines whether the number of events has exceeded three.

[0138] When the event generating unit 115 determines that the event has occurred the specified number of times based on the event count (step S9, YES), the process returns to step S5. When the event generating unit 115 determines that the event has not occurred the specified number of times based on the event count (step S9, NO), the event generating unit 115 generates an event corresponding to any in-game asset (step S10).

[0139] The management unit 114 determines whether the history information satisfies the second condition during the period when the event occurs (step S11). If the management unit 114 determines that the history information satisfies the second condition during the period when the event occurs (step S11, YES), it extends the first period corresponding to any in-game asset (step S12) and returns to the processing of step S5. If the management unit 114 determines that the history information does not satisfy the second condition during the period when the event occurs (step S11, NO), it returns to the processing of step S5.

[0140] When the management unit 114 determines that the first period has elapsed (step S7, YES), it waits until it determines that the second period has elapsed (step S13, NO). When the management unit 114 determines that the second period has elapsed (step S13, YES), the lottery unit 113 adds the randomly selected excluded in-game asset back to the multiple in-game asset candidates (step S14), and ends the process.

[0141] According to the game server, game operation method, computer program, and game system of this embodiment, the user can increase the parameter values ​​of a randomly selected character by fulfilling various conditions, and a character that is owned for a limited time can be made to be owned indefinitely. This makes it possible to clarify the criteria for acquisition while retaining an element of uncertainty associated with conventional methods of acquiring characters (e.g., gacha), thereby improving the game's appeal and preventing players from abandoning it.

[0142] Next, an example of the NFT processing of the game server 110 will be described with reference to the drawings. FIG. 6 is a flowchart illustrating an example of an NFT process of a game server in one embodiment.

[0143] In this embodiment, the NFT process is started at any timing. The conversion unit 116 determines whether a conversion request signal has been received from the user terminal 200 (step S21). The conversion unit 116 waits without performing any process until the conversion request signal is received (step S21, NO).

[0144] When the conversion unit 116 receives a conversion request signal from the user terminal 200 via the communication unit 121 (step S21, YES), it determines whether the history information associated with the user ID included in the conversion request signal satisfies a predetermined condition (step S22). When the conversion unit 116 determines that the history information associated with the user ID does not satisfy the predetermined condition (step S22, NO), it ends the NFT process.

[0145] When the history information associated with the user ID satisfies a predetermined condition (step S22, YES), the conversion unit 116 determines whether the history information records that any in-game asset has changed from a first state to a second state (step S23).

[0146] If the conversion unit 116 determines that the history information records that any in-game asset has changed from a first state to a second state (step S23, YES), it makes the in-game asset in the second state associated with the user ID in a state that can be converted into an NFT in a manner that indicates the existence of a history of the asset changing from the first state to the second state, generates a request signal, and transmits the request signal to the NFT server 130 via the communication unit 121 (step S24), and terminates the processing.

[0147] If the conversion unit 116 determines that the history information does not record that any in-game assets have changed from the first state to the second state (step S23, NO), it makes the in-game assets associated with the user ID in a state that can be converted into an NFT, generates a request signal, and transmits the request signal to the NFT server 130 via the communication unit 121 (step S43), and terminates the processing.

[0148] When the NFT server 130 completes the NFT conversion, the conversion unit 116 receives an NFT process completion notification from the NFT server 130. Based on the NFT process completion notification, the conversion unit 116 switches the switching flag of the in-game asset for which the NFT process associated with the user ID has been completed, and makes the in-game asset for which the NFT process has been completed unusable.

[0149] The processing order of the NFT process in the above steps S21-S25 is not limited to the above. For example, the conversion unit 116 determines which of the multiple in-game assets associated with the user ID of the user satisfies a predetermined condition in the history information associated with the user ID. Thereafter, the conversion unit 116 uses the display processing unit 117 to display the multiple in-game assets that satisfy the predetermined condition on the user terminal 200, and presents the in-game assets that can be converted to NFT to the user. Next, the conversion unit 116 receives a conversion request signal, generates a request signal corresponding to the in-game assets that satisfy the predetermined condition selected by the user and are included in the conversion request signal, and transmits the request signal to the NFT server 130. The conversion unit 116 may proceed with the NFT process according to the above processing procedure instead of the above steps S21-S25.

[0150] According to the game server, game operation method, computer program, and game system of this embodiment, characters acquired by a user can be developed under various conditions and converted into NFTs that can be held as crypto assets. In addition, by increasing the parameter values ​​of a character owned for a limited period of time, it becomes possible to indicate on the NFT that the character is owned indefinitely, and by making it possible to sell the character, it is possible to increase the interest of players and prevent them from abandoning the game.

[0151] That is, according to the present embodiment, it is possible to provide a game server, a game operation method, a computer program, and a game system that provide a game in which a user can acquire in-game assets while enjoying the game.

[0152] The present invention is not limited to the above-mentioned embodiment, and can be modified in various ways without departing from the gist of the present invention. The embodiments may be combined as appropriate, and in that case, the combined effect can be obtained. Furthermore, the above-mentioned embodiment includes various inventions, and various inventions can be extracted by combinations selected from the multiple components disclosed. For example, if the problem can be solved and the effect can be obtained even if some components are deleted from all the components shown in the embodiment, the configuration from which the components are deleted can be extracted as an invention. [Explanation of symbols]

[0153] 100...game system, 110...game server, 111...processor, 112...play management unit, 113...lottery unit, 114...management unit, 115...event generation unit, 116...conversion unit, 117...display processing unit, 118...storage unit, 119...input unit, 120...output unit, 121...communication unit, 130...NFT server, 131...processor, 132...NFT processing unit, 133...storage unit, 134...input unit, 135...output unit, 136...communication unit, 200...user terminal, 300...CEX (Centralized Exchange), 400...DEX (Decentralized Exchange), 500...marketplace

Claims

1. a storage unit for storing a user ID of a user and history information of the user playing a game in association with each other; A management unit that changes the user to a first state in which the user owns any in-game asset for a first period of time; Equipped with The management unit, when the history information associated with the user ID satisfies a first condition during the first period, changes the user to a second state in which the user owns any in-game asset.

2. 2. The game server of claim 1, further comprising a lottery unit that randomly selects the in-game asset to be owned by the user for the first period from a plurality of pre-set candidates and excludes the selected in-game asset from the candidates.

3. 2. The game server according to claim 1, wherein the first state is a state in which a temporary ownership ID that causes the user to own any in-game asset for the first period is associated with the user ID and stored in the memory unit.

4. The game server of claim 3, wherein the management unit, when the historical information associated with the user ID satisfies the first condition during the first period, rewrites the temporary ownership ID associated with the user ID to an ownership ID that brings the user into the second state in which the user owns any in-game asset.

5. an event generating unit that generates an event corresponding to the arbitrary in-game asset at least once before the end of the first period; The game server according to claim 4 , wherein the management unit extends the first period when the history information satisfies a second condition during the period in which the event occurs.

6. The game server according to claim 2 , wherein the selection unit adds the arbitrary in-game asset to the candidates after a second period has elapsed if the arbitrary in-game asset remains in the first state for the first period.

7. A first state in which the user owns any in-game asset for a first period of time; A game operation method, in which, when historical information of the user playing a game, associated with the user's user ID and recorded in a memory unit, during the first period satisfies a first condition, the user is put into a second state in which the user owns any of the in-game assets.

8. 8. The game operation method according to claim 7, further comprising randomly selecting the in-game asset to be owned by the user during the first period from a plurality of pre-set candidates, and excluding the selected in-game asset from the candidates.

9. A computer program for causing a computer to execute the game operating method according to claim 7 or 8.

10. A game server according to any one of claims 1 to 6; A game system including an NFT server that converts the arbitrary in-game asset into an NFT (Non-Fungible Token) based on a request signal from the game server, A game system in which, when the game server receives a conversion request signal to convert any in-game asset associated with the user ID into an NFT, the game server sends the request signal to the NFT server requesting that the in-game asset be converted into the NFT in a manner indicating the existence of a history of the in-game asset changing from the first state to the second state.

Images