Program and information processing system

The game system improves sustainability by granting NFTs and crypto assets based on event execution, addressing the inadequacies of existing blockchain-based games, and enhancing asset management and reward distribution.

JP2025137666APending Publication Date: 2025-09-19COLOPL
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2025121066
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-07-18
Publication Date
2025-09-19

AI Technical Summary

Technical Problem

The sustainability of blockchain-based games that reward players with crypto assets is inadequate.

Method used

A game system utilizing a blockchain network that grants NFTs and crypto assets to players based on event execution, with a control mechanism for managing assets and events, including a control unit, asset management, and market management units to facilitate transactions and rewards.

Benefits of technology

Enhances the sustainability of the game system by improving asset management and reward distribution, ensuring a stable and engaging gameplay experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025137666000001_ABST
    Figure 2025137666000001_ABST
Patent Text Reader

Abstract

To improve the sustainability of a service.SOLUTION: The program causes a computer to function as exchange means for exchanging a predetermined non-NFT object owned by a user for a crypto asset and as NFT conversion means for converting a predetermined object into an NFT by consuming the crypto asset.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a program and an information processing system. [Background technology]

[0002] Games that utilize blockchain have been known for some time (see, for example, Non-Patent Document 1). Also known as such games are games that allow players to earn crypto assets by playing. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] "STEPN: How to get started and its future prospects | How to earn money / how to do it and how much it costs to level up?" [online] [Searched October 27, 2022], Internet<https: / / www.caica.jp / media / crypto / stepn-about / > Summary of the Invention [Problem to be solved by the invention]

[0004] However, there was a need to improve the sustainability of this type of service.

[0005] The present invention has been made in consideration of the above circumstances, and aims to improve the sustainability of services. [Means for solving the problem]

[0006] According to one embodiment shown in the present disclosure, Computer, a control means for controlling the execution of a predetermined event; a first granting means for granting a first object to a user based on the execution of the predetermined event; and a second granting means for granting at least one of a crypto asset and a second object exchangeable for the crypto asset to the user based on the execution of the predetermined event; The first object is an object that can be in an NFT state. Programs are offered. [Effects of the Invention]

[0007] According to the present invention, the sustainability of the service can be improved. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating a schematic configuration of a game system. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of the game system. [Figure 3] FIG. 10 is a diagram illustrating an example of a map. [Figure 4] FIG. 1 is a diagram for explaining the flow of asset acquisition and consumption. [Figure 5] FIG. 10 is a diagram illustrating a timeline relating to the acquisition and exploration of a dungeon. [Figure 6] 10 is a flowchart illustrating an example of a process for generating a dungeon and determining a reward. [Figure 7] 10 is a flowchart illustrating an example of a process related to acquisition and exploration of a dungeon. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0010] <Game system hardware configuration> 1, the game system 1 of this embodiment includes a plurality of terminal devices 10, a server 20, and a blockchain system 3. The blockchain system 3 also includes a plurality of node devices 30.

[0011] The terminal device 10, the server 20, and the blockchain system 3 (in other words, the node device 30) are connected to each other via a network 2. The network 2 may be configured, for example, by the Internet, a mobile communication system (e.g., 3G, 4G, 5G, LTE (Long Term Evolution), etc.), WiFi (Wireless Fidelity), Bluetooth (registered trademark), other communication lines, or a combination of these.

[0012] The server 20 (in other words, a computer, an information processing device) may be, for example, a general-purpose computer such as a workstation or a personal computer. The server 20 includes a processor 21, a memory 22, a storage 23, a communication IF (interface) 24, and an input / output IF 25. These components of the server 20 are connected to each other by a communication bus.

[0013] The processor 21 controls the overall operation of the server 20. The processor 21 may include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), etc. The processor 21 reads a program from the storage 23 and loads it into the memory 22. The processor 21 executes the loaded program.

[0014] The memory 22 is a main storage device. The memory 22 is configured by storage devices such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 22 temporarily stores programs and various data that the processor 21 reads from the storage 23, thereby providing a working area for the processor 21. The memory 22 also temporarily stores various data that the processor 21 generates while operating according to the programs.

[0015] In this embodiment, the program may be a program that realizes a game by the terminal device 10. The program may also be a program that realizes the game through cooperation between the terminal device 10 and the server 20. The program may also be a program that realizes the game through cooperation between the terminal device 10, the server 20, and the blockchain system 3. The game may, for example, be a game that is executed on a browser launched on the terminal device 10. The various data may also include, for example, data related to the game, such as user information and game information, and instructions and notifications transmitted and received between devices such as the terminal device 10 and the server 20.

[0016] The storage 23 is an auxiliary storage device. The storage 23 is configured by a storage device such as a flash memory or an HDD (Hard Disk Drive). The storage 23 stores various data related to the game.

[0017] The communication IF 24 controls the transmission and reception of various data between the server 20 and the terminal device 10, etc. via the network. The communication IF 24 also controls the transmission and reception of various data between the server 20 and the blockchain system 3 (in other words, the node device 30) via the network.

[0018] The input / output IF 25 is an interface through which the server 20 receives input of data and also an interface through which the server 20 outputs data. The input / output IF 25 may include, for example, an input unit which is an information input device such as a mouse or a keyboard, and a display unit which is a device that displays and outputs images.

[0019] The terminal device 10 (in other words, a computer, an information processing device) may be, for example, a smartphone, a feature phone, a PDA (Personal Digital Assistant), a tablet computer, a personal computer, a wearable terminal, or a game device. The terminal device 10 may be a mobile terminal. The terminal device 10 may be a portable terminal that a user uses when playing a game.

[0020] The terminal device 10 includes a processor 11, a memory 12, a storage 13, a communication IF 14, an input / output IF 15, an input unit 17, and a display unit 18. These components included in the terminal device 10 are connected to each other by a communication bus.

[0021] The processor 11 controls the overall operation of the terminal device 10. The processor 11 may include a CPU, an MPU, a GPU, etc. The processor 11 reads a program from the storage 13 and loads it into the memory 12. The processor 11 executes the loaded program.

[0022] The memory 12 is a main storage device. The memory 12 is configured by storage devices such as a ROM and a RAM. The memory 12 provides a working area for the processor 11 by temporarily storing the programs and various data that the processor 11 reads from the storage 13. The memory 12 also temporarily stores various data that the processor 11 generates while operating according to the programs.

[0023] The storage 13 is an auxiliary storage device. The storage 13 is configured by a storage device such as a flash memory or a HDD. The storage 13 stores various data related to the game.

[0024] The communication IF 14 controls transmission and reception of various data via a network between the terminal device 10 and the server 20, etc. The communication IF 14 may also control transmission and reception of various data via a network between the terminal device 10 and the blockchain system 3 (in other words, the node device 30).

[0025] The input / output IF 15 is an interface through which the terminal device 10 receives input of data and also an interface through which the terminal device 10 outputs data. The input / output IF 15 may input and output data via, for example, a USB (Universal Serial Bus) or the like. The input / output IF 15 may include an input unit 17, a display unit 18, or the like.

[0026] The input unit 17 accepts input from a user. The input unit 17 may be, for example, a pointing device such as a touchpad. The display unit 18 displays images. The display unit 18 may be, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display. The terminal device 10 includes, for example, a touch screen 16 which is an electronic component that combines the input unit 17 and the display unit 18.

[0027] The input unit 17 has a function of detecting a position input on the input surface by a user operation (for example, a touch operation, a tap operation, a slide operation, a swipe operation, a flick operation, a pinch-in operation, a pinch-out operation, etc.) and transmitting information indicating the detected position as an input signal. The touch panel serving as the input unit 17 may be of a capacitance type or a resistive film type, or may be of another type.

[0028] The input unit 17 may be, for example, a keyboard, various physical buttons, various sensors (for example, an acceleration sensor or an angular velocity sensor), an operation stick, a camera, or a microphone. The display unit 18 may be, for example, a projector.

[0029] A plurality of node devices 30 constitute a blockchain system 3. Each node device 30 holds a distributed ledger. Each node device 30 stores the same data in the distributed ledger. As will be described in detail later, in this embodiment, assets held by users are managed in the distributed ledger of the blockchain system 3.

[0030] The node device 30 (in other words, a computer, an information processing device) may be, for example, a general-purpose computer such as a workstation or a personal computer. The node device 30 includes a processor 31, a memory 32, a storage 33, a communication IF 34, and an input / output IF 35. These components included in the node device 30 are connected to each other by a communication bus.

[0031] The processor 31 controls the overall operation of the node device 30. The processor 31 may include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), etc. The processor 31 reads a program from the storage 33 and loads it into the memory 32. The processor 31 executes the loaded program.

[0032] The memory 32 is a main storage device. The memory 32 is configured by storage devices such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 32 temporarily stores programs and various data that the processor 31 reads from the storage 33, thereby providing a working area for the processor 31. The memory 32 also temporarily stores various data that the processor 31 generates while operating according to the programs.

[0033] The storage 33 is an auxiliary storage device and is configured by a storage device such as a flash memory or an HDD (Hard Disk Drive).

[0034] The communication IF 34 controls transmission and reception of various data between the node device 30 and the server 20 via the network. Note that the communication IF 34 may also control transmission and reception of various data between the node device 30 and the terminal device 10 via the network.

[0035] The input / output IF 35 is an interface through which the node device 30 receives input of data and also an interface through which the node device 30 outputs data. The input / output IF 35 may include, for example, an input unit that is an information input device such as a mouse or a keyboard, and a display unit that is a device that displays and outputs images.

[0036] The server 20 and the terminal device 10 may function as the node device 30. In other words, the blockchain system 3 may include the server 20 and the terminal device 10.

[0037] <Functional configuration of the game system> 2 is a block diagram showing the functional configuration of the server 20, the terminal devices 10, and the node devices 30. The server 20 in this embodiment has, for example, a function to provide each terminal device 10 with various data and programs necessary to realize the game, and a function to collect and manage data related to the game from each terminal device 10.

[0038] In this embodiment, the server 20 identifies each user and the terminal device 10 using a user account that is registered in advance for each game. The method of registering an account is not particularly limited. For example, the terminal device 10 or another device such as a personal computer may transmit information required for user account registration to the server 20 based on a user operation, and the server 20 may create and save an account for each user based on the received information.

[0039] 2, the server 20 functions as a control unit 210 and a storage unit 220 through cooperation of a processor 21, a memory 22, a storage 23, a communication IF 24, an input / output IF 25, etc. The storage unit 220 stores various data used by the control unit 210. The various data include, for example, a program, game information 222, and user information 223. The program is a program for realizing a game. The game information 222 and user information 223 are data referenced by the control unit 210 when executing the program.

[0040] The game information 222 includes, for example, information for defining various game spaces. A game space is a virtual space in which objects such as characters that can be controlled by a user (hereinafter also referred to as "controllable characters") are placed. Hereinafter, character objects placed in the game space may be simply referred to as "characters." The game information also includes, for example, information regarding the positions and setting values ​​of various objects (including items) within the game space. The game information 222 also includes, for example, information for performing display related to the game.

[0041] The user information 223 is information managed for each game account. The user information 223 includes, for example, information about the user's character, information about owned assets, information indicating the progress of the game, and information about dungeons (dungeons will be described later) acquired by the user (in other words, information indicating rights related to the execution of events). The owned assets include tokens, item A, item B, item C, etc., which will be described later. In other words, the storage unit 220 may store information such as tokens, item A, item B, or item C owned by each user, in association with identification information that can identify each user.

[0042] The control unit 210 controls various processes related to the game by executing programs stored in the storage unit 220. The control unit 210 has a transmission / reception unit 211, a game control unit 212, an asset management unit 213, and a market management unit 214.

[0043] The transmitting / receiving unit 211 transmits or receives various data. For example, the transmitting / receiving unit 211 receives requests to transmit various data and programs from each terminal device 10 and passes them to the game control unit 212, asset management unit 213, market management unit 214, or the like. The transmitting / receiving unit 211 also transmits various data and programs to each terminal device 10 in accordance with the control of the game control unit 212, asset management unit 213, market management unit 214, or the like.

[0044] The game control unit 212 executes arithmetic processing described in a program stored in the storage unit 220 to provide a game to the terminal device 10.

[0045] The asset management unit 213 manages assets held by users. The asset management unit 213 also manages some or all (in other words, at least some) of the assets held by users in a distributed ledger of the blockchain system 3. In other words, the asset management unit 213 may store information about the assets held by users in the storage unit 220, or may store the information in the distributed ledger. Note that, in a configuration in which the server 20 functions as a node device 30, the asset management unit 213 may store information about the assets held in a distributed ledger stored in its own storage unit 220. Also, in a configuration in which the server 20 does not function as a node device 30, the asset management unit 213 may perform control such as sending a request to the blockchain system 3 for storage in the distributed ledger.

[0046] The terminal device 10 has, for example, a function as an input device that accepts input operations from the user, and a function as an output device that outputs images and sounds of the game.

[0047] The terminal device 10 functions as a control unit 110 and a storage unit 120 through cooperation of the processor 11, memory 12, storage 13, communication IF 14, input / output IF 15, etc. The storage unit 120 stores various data used by the control unit 110. The various data include, for example, a program, game information 122, and user information 123. The program is a program for realizing a game on the terminal device 10 side. The game information 122 and user information 123 are data referenced by the control unit 110 when executing the program.

[0048] The game information 122 includes the same information as the game information 222 of the server 20. Therefore, a description of the game information 122 will be omitted here.

[0049] The user information 123 is data relating to the account of the user who uses the terminal device 10, and includes information similar to the above-described user information 223 of the server 20. Therefore, a description of the user information 123 will be omitted here.

[0050] The control unit 110 executes a program stored in the storage unit 120 to control various processes related to the game executed on the terminal device 10. The control unit 110 includes, for example, an operation reception unit 111, a transmission / reception unit 112, a device processing unit 113, and a display control unit 114.

[0051] The operation reception unit 111 receives an operation (hereinafter also referred to as an "input operation") input by the user via the input unit 17. Specifically, when an input operation is performed on the input unit 17, the operation reception unit 111 detects the coordinates of the input position and the type of input operation. Examples of the types of input operations include various operations performed with fingers, etc., such as a touch operation, a tap operation, a slide operation, a swipe operation, a flick operation, a pinch-in operation, and a pinch-out operation. The input operation is not limited to an operation of physically contacting the input unit 17 (for example, the touch screen 16) but may also include a non-contact operation. Note that an operation of ending a previously performed input operation, such as a touch-off operation of ending contact with the touch screen 16, can also be considered as one form of input operation.

[0052] Here, the operation reception unit 111 can also receive input operations performed using an operation device connected via the input / output IF 15 in the same way as input operations to the input unit 17 .

[0053] The transmitting / receiving unit 112 transmits and receives various types of data. For example, the transmitting / receiving unit 112 transmits game information 122, user information 123, etc. to the server 20. The transmitting / receiving unit 112 also receives various types of data, programs, etc. from the server 20. The transmitting / receiving unit 112 also transmits operation information related to the input operation accepted by the operation accepting unit 111 to the server 20.

[0054] The device processing unit 113 executes various processes related to the progress of the game, which will be explained below with specific examples.

[0055] The device processing unit 113 interprets the user's instruction content based on the coordinates of the input position and the type of input operation detected by the operation reception unit 111. The device processing unit 113 also executes various determination processes related to the progress of the game based on the interpreted instruction content, etc. The device processing unit 113 also progresses the game while communicating with the server 20 based on the results of the determination processes, etc. The device processing unit 113 also updates, adds, or deletes game information 122 and user information 123 according to the progress of the game. The device processing unit 113 also instructs the display control unit 114 to display an image according to the progress of the game on the display unit 18.

[0056] The display control unit 114 causes the display unit 18 to display images relating to the game.

[0057] The node device 30 functions as a control unit 310 and a storage unit 320 through cooperation of a processor 31, a memory 32, a storage 33, a communication IF 34, an input / output IF 35, etc. The storage unit 320 stores programs including part of a game program, a distributed ledger used in the blockchain system 3, etc.

[0058] The control unit 310 controls the operation of the node device 30 by executing a program stored in the storage unit 320 .

[0059] When a user acquires various items (including specific tokens, described later) (for example, from another user or from the administrator (for example, by executing an event, described later)), the control unit 310 receives a request to register information related to the possession of the item, transmitted from the server 20, and registers the information in the distributed ledger. The control unit 310 may register transaction history information for each item in the distributed ledger, for example, based on information related to item transactions (in other words, transfers) transmitted from the server 20 or the terminal device 10. Specifically, the distributed ledger stores multiple blocks containing hash values ​​and transaction data. The transaction data may be, for example, information indicating the details of an item transaction. The transaction data includes, for example, input information indicating the transfer source and output information indicating the transfer destination. The hash value is calculated from information contained in the previous block, and the distributed ledger stores the transaction history of each item, with each block linked like a chain by the hash value. By managing such item transaction history in a distributed ledger of each node device 30, information indicating which user owns which item can be stored on the blockchain. Note that, instead of the item transaction history, information regarding each user's item ownership status can be managed in a distributed ledger, thereby storing information indicating which user owns which item on the blockchain. In this way, in the game of this embodiment, item ownership information is stored on the blockchain. Note that there may be items whose ownership information is not stored on the blockchain.

[0060] The functions of the terminal device 10, the server 20, and the node device 30 shown in FIG. 2 are merely examples. Each of the terminal device 10, the server 20, and the node device 30 may have at least some of the functions of the other devices. In other words, the server 20 or the node device 30 may have some or all of the functional blocks of the terminal device 10 in this embodiment, the terminal device 10 or the node device 30 may have some or all of the functional blocks of the server 20, or the terminal device 10 or the server 20 may have some or all of the functional blocks of the node device 30. Furthermore, each of the devices, such as the terminal device 10, the server 20, and the node device 30, does not have to be realized by an integrated device, and may be realized by, for example, multiple devices connected via a network or the like. Furthermore, the game system 1 may not include, for example, the terminal device 10, the server 20, or the node device 30.

[0061] <Processing according to this embodiment> Next, the processing according to this embodiment will be described. Note that in this embodiment, the processor 11 of the terminal device 10, the processor 21 of the server 20, or the processor 31 of the node device 30 executes a program stored in the game system 1 to perform each of the processes described below. However, at least a portion of the processing performed by the processor 11, which is described below, may be executed by a processor other than the processor 11 (e.g., the processor 21 or the processor 31). Also, at least a portion of the processing performed by the processor 21, which is described below, may be executed by a processor other than the processor 21 (e.g., the processor 11 or the processor 31). Also, at least a portion of the processing performed by the processor 31, which is described below, may be executed by a processor other than the processor 31 (e.g., the processor 11 or the processor 21). In other words, the computer that executes the program in this embodiment may be any of the terminal device 10, the server 20, and the node device 30, or may be realized by a combination of multiple devices. Also, some or all of the various processes may be executed on a blockchain.

[0062] Here, an overview of the game of this embodiment will be described. In the game of this embodiment, there is a map that is common to multiple users (specifically, all users) participating in the game. Furthermore, multiple dungeons are arranged on this map. An example of the map is shown in FIG. 3. In the map shown in FIG. 3, the locations of dungeons are indicated by crosses.

[0063] The user acquires (or selects) the dungeon they will explore (or in other words, the dungeon where the event will take place) from the map. Note that the acquisition of the dungeon may be performed, for example, by an operation to select a specific dungeon on the map displayed on display unit 18 (for example, a touch operation on input unit 17). The acquisition of the dungeon may also be performed, for example, by an operation to move the playable character and guide the playable character to the location within the map (or in other words, within the virtual space) where the specific dungeon is located.

[0064] Furthermore, the user is able to explore the dungeon that he or she has acquired. In other words, the user is able to play a quest for the dungeon that he or she has acquired. In yet other words, once the user has acquired a dungeon, the user is able to execute an event to explore the dungeon. Note that, in this embodiment, the event (in other words, a quest) refers to exploring a dungeon, but it may also be, for example, an event aiming to defeat a predetermined character (e.g., a non-player character or a character controlled by another user), an event aiming to win a predetermined sport, or an event to watch or watch a predetermined game. In this way, in the game of this embodiment, once a predetermined condition is met (in other words, once a dungeon is acquired), an event aiming to achieve a predetermined objective can be executed.

[0065] In addition, in the game of this embodiment, an item A is provided that is used to explore the dungeon. To explore the dungeon, the user must possess item A. In other words, item A is an item required to participate in the game (in other words, to execute an event). Note that in the game of this embodiment, multiple types of item A with different characteristics are provided. Item A can be converted into an NFT (Non-Fungible Token). The NFT state refers to a state in which information proving that item A is unique is stored on a blockchain. In other words, the NFT state refers to a state in which an NFT corresponding to item A is issued and managed on a blockchain. Note that, hereinafter, digital assets such as items for which a corresponding NFT has been issued are also referred to as NFTs. In this embodiment, the conversion of item A into an NFT (in other words, the generation of item A) is performed by the game operator, and cannot be performed by the user (in other words, minted by the user). In other words, in this game, a user cannot obtain item A that is not converted into an NFT.

[0066] Furthermore, in the game of this embodiment, items B and C can be awarded to the user as rewards based on the exploration of the dungeon. As will be described in detail later, item B is an item that can be converted into an NFT. Item C is an item that can be exchanged for a specific token. Hereinafter, a token that can be acquired in exchange for item C is referred to as a "specific token."

[0067] In addition, in the game of this embodiment, there are multiple types of item B, which are collectible items. Specifically, item B is a monster that the user collects. Item A is an item used to capture the monster serving as item B. In other words, the game of this embodiment has the gameplay of exploring a dungeon using a capture item serving as item A, capturing a monster serving as item B, and collecting the monster.

[0068] Furthermore, the specific token that can be acquired by exchanging it for item C is a crypto asset (for example, virtual currency). In the game of this embodiment, the specific token can be used to level up item A, repair item A (in other words, fix it), turn item B into an NFT, and for various time-saving purposes.

[0069] Regardless of whether they have been converted into NFTs or not, assets such as Item A, Item B, or Item C held by each user may be managed on a blockchain (in other words, a distributed ledger).

[0070] A dungeon exploration as a predetermined event may be performed, for example, as follows. That is, the user may perform an operation to instruct the start of exploration of the dungeon that the user has acquired, thereby starting the dungeon exploration. The dungeon exploration may also be automatically carried out by the game control unit 212. Alternatively, the dungeon exploration may be carried out by the game control unit 212 based on a user operation. That is, for example, once an operation to instruct the start of dungeon exploration is performed, the exploration may then proceed without any user operation, and the user may be granted item B or item C as a reward for the exploration. Alternatively, for example, once an operation to instruct the start of dungeon exploration is performed, the user may then be able to explore the dungeon (in other words, within the virtual space) by, for example, moving the playable character, and any item B or item C placed in the dungeon that the user discovers may be granted as a reward.

[0071] The probability of acquiring item B in exploring a dungeon may be set lower than the probability of acquiring item C. In other words, item B may be rarer than item C. In other words, the probability of acquiring item B in exploring a dungeon may be set lower than the probability of acquiring a specific token. Item B may be an item that may not be acquired in a single exploration. Item C may be an item that can always be acquired in a single exploration. In this embodiment, it is possible to acquire approximately the same amount of item C (in other words, specific tokens) in any dungeon.

[0072] The quality or quantity of item B or item C that can be acquired as a reward by exploring a dungeon may vary depending on the level or durability of item A used in the exploration. For example, the higher the level of item A, the higher the quality of item B that can be acquired, or the greater the amount of item B or item C that can be acquired (e.g., the expected amount). Also, for example, item A may have a durability value set, and the durability value may decrease as it is used in exploration (e.g., decreasing from a durability value of "100" to a durability value of "0"). As the durability value decreases, it may become more difficult to acquire high-quality item B, or the amount of item B or item C that can be acquired (e.g., the expected amount) may decrease. Furthermore, when the durability value reaches a predetermined value, it may become impossible to explore the dungeon using item A, or item A may break and its durability value may no longer be able to be restored (e.g., the user may lose item A). In such cases, the operation receiving unit 111 may receive an operation to instruct item A to level up. Information regarding the operation may then be sent from the terminal device 10 to the server 20, and the control unit 210 of the server 20 may perform processing to increase the level of item A based on the operation. A predetermined amount of specific tokens may be required to increase the level of item A, and the predetermined amount of specific tokens may be consumed when increasing the level of item A through the operation. The operation receiving unit 111 may also receive an operation by the user instructing recovery of the durability value of item A (in other words, repairing item A). Information regarding the operation may then be sent from the terminal device 10 to the server 20, and the control unit 210 of the server 20 may perform processing to restore the durability value of item A based on the operation. A predetermined amount of specific tokens may be required to restore the durability value of item A, and the predetermined amount of specific tokens may be consumed when restoring the durability value of item A through the operation. That is, the specific tokens may be usable to change a predetermined parameter related to item A.

[0073] In the game of this embodiment, items that can be obtained through acquisition routes different from item A, item B, and item C may be prepared. For example, there may be items that can be purchased in the game (for example, items such as clothes (in other words, skins) that can be equipped by the playable character) using in-game currency that is not a cryptocurrency (for example, assets held by the user that are not managed by a blockchain but are managed in the storage unit 220, etc.). The game currency may be something that can be purchased using legal tender, etc.

[0074] Furthermore, various items in this embodiment (for example, item A, item B, and item C) may be read as objects. Objects include characters, items, etc. In other words, item B and item C granted by the execution of an event may be characters, etc.

[0075] In this embodiment, the map is updated (in other words, newly generated) at predetermined intervals (specifically, once a day). In addition, in conjunction with the map updates, the dungeons are also updated (in other words, newly generated) at predetermined intervals (specifically, once a day). Furthermore, only one user can acquire one dungeon, and once a user acquires a dungeon, that dungeon cannot be acquired by other users. In other words, acquisition of dungeons is first come, first served. Note that map updates and dungeon updates may involve completely renewing past maps and dungeons (in other words, new maps and dungeons are generated and past maps and dungeons are deleted), or may involve expanding past maps or adding new dungeons in addition to dungeons generated in the past.

[0076] Here, the flow of asset acquisition and consumption in the game of this embodiment will be described with reference to FIG.

[0077] As described above, in the game of this embodiment, a user must possess item A in order to participate in the game. In this embodiment, item A can be purchased in the in-game marketplace, and the user purchases item A in the marketplace. Item A can be purchased with a predetermined cryptocurrency. The predetermined cryptocurrency may be a specific token that can be acquired in exchange for item C, or may be other cryptocurrency. Transactions in the marketplace are managed by the market management unit 214. Specifically, for example, the operation reception unit 111 of the terminal device 10 receives an operation by the user to select an item that the user wishes to purchase. Information regarding the operation is then sent to the market management unit 214 of the server 20 via the transmission / reception units 112, 211. Based on the operation, the market management unit 214 transfers the item selected by the user to the user and transfers the payment from the user to the seller of the item.

[0078] Next, the user explores the dungeon using the acquired item A. In exploring the dungeon, it is possible to acquire multiple types of items, including item B and item C.

[0079] Item C acquired by the user can be exchanged for a specific token. Note that in order to exchange for a specific token, it may be necessary to accumulate a predetermined amount of item C. Furthermore, in this embodiment, item C is granted to the user by exploring the dungeon, and the user exchanges item C for a specific token. However, the specific token may be granted directly to the user instead of or in addition to item C by exploring the dungeon. In other words, the game may be configured so that at least one of item C and a specific token is granted by exploring the dungeon. Here, granting at least one includes a configuration in which the other is not granted.

[0080] Furthermore, the specific token acquired through exchange with item C is a token that can be exchanged for other crypto assets (e.g., virtual currency) at a predetermined exchange (e.g., a decentralized exchange). The specific token is also a utility token. Note that the specific token is a unique token related to the game of this embodiment, and is a token with an issuance limit set, but it may also be virtual currency or the like that can be used outside the game.

[0081] Furthermore, item B acquired by the user can be converted into an NFT. That is, in this embodiment, an NFT corresponding to item B can be issued and managed on a blockchain. Specifically, the operation receiving unit 111 of the terminal device 10 may receive an operation by the user to select item B that the user wants to convert into an NFT in the game. Information regarding the operation is then sent to the asset management unit 213 of the server 20 via the transmission / reception units 112, 211, and the asset management unit 213 may perform a process of converting the selected item B into an NFT based on the operation. Furthermore, a predetermined amount of specific tokens may be required for NFT conversion, and when converting item B into an NFT through the operation, the predetermined amount of specific tokens may be consumed. Furthermore, the NFTed item B may be able to be bought and sold on the in-game marketplace. In other words, converting an item into an NFT can be considered as making the item available for buying and selling on the marketplace. Specifically, for example, the operation receiving unit 111 of the terminal device 10 may receive an operation by the user to select item B that the user wants to sell. Information regarding the operation is then sent to the market management unit 214 of the server 20 via the transmission / reception units 112, 211, and the market management unit 214 may then put the item selected by the user up for sale based on the operation. If there is another user who wishes to purchase the item, the market management unit 214 may then transfer the item to the other user and perform processing to have the other user transfer the price to the user who sold the item.

[0082] Furthermore, item B may be exchangeable for a specific token. Specifically, the operation receiving unit 111 of the terminal device 10 may receive an operation by the user to select item B that the user wishes to exchange for a specific token in the game. Information regarding the operation is then sent to the server 20 via the transmission / reception units 112, 211, and the asset management unit 213 may grant the specific token to the user in exchange for the selected item B based on the operation. In other words, item B may be an item that can be converted into an NFT and exchanged for a specific token.

[0083] Furthermore, it may be possible to combine multiple (e.g., two) items B (in other words, NFTs) to generate another new item B (in other words, NFT). In other words, it may be possible to use (in other words, burn) multiple items B to generate (in other words, mint) a new item B. Specifically, it may be possible to generate a new item B using multiple NFT-ed items B. That is, the operation receiving unit 111 may receive an operation by the user to select multiple items B to be used to generate item B in the game. Information related to the operation is then sent to the asset management unit 213 via the transmission / reception units 112, 211, and the asset management unit 213 may generate a new item B using the selected multiple items B based on the operation.

[0084] Note that item B does not have to be an item that can be converted into an NFT (in other words, an item that can be in an NFTed state). Item B, which is an item different from item C (in other words, an object), may be an item that can be exchanged for a specific token or other cryptocurrency. In this embodiment, a specific token or other cryptocurrency may be directly awarded to the user instead of item B as a result of exploring the dungeon. Item B that has not been converted into an NFT (for example, not in an NFTed state) may be available for buying and selling in an in-game marketplace.

[0085] The game control unit 212 controls the game played by the user. The game control unit 212 has an event management unit 231, an event execution unit 232, and a reward granting unit 233. The event management unit 231 also executes a map creation process for creating a map, a reward summary determination process for determining a reward summary, a dungeon creation process for creating a dungeon, and a reward detail determination process for determining the details of the reward.

[0086] Furthermore, among the various processes in this embodiment, there is a process with randomness. In this embodiment, the process with randomness is realized by performing calculations using a predetermined seed. The predetermined seed includes a seed using a blockchain (for example, a Bitcoin blockchain) and a seed using a dungeon ID, which will be described later, but it may also include only one of them. Specifically, in this embodiment, two types of seeds using blockchain (hereinafter, referred to as "seed") are used. hlast "," "seed hfirst ") and one seed using the dungeon ID (hereinafter referred to as "seed mdid ") is available.

[0087] More specifically, a seed related to the hash of a blockchain (specifically, for example, the Bitcoin blockchain) as a seed using a blockchain and a seed related to a dungeon ID are used to achieve randomness. In this embodiment, the last hash (in other words, the hash value of the last generated block) of an arbitrary period (for example, one day) is used. last_yyyymmdd and hash last_yyyymmdd hash, which is the first hash of the day after the block was generated (in other words, the hash value of the first generated block) first_yyyymmdd+2 is used as a seed for the hash. In this embodiment, the dungeon ID is used as a seed for the dungeon ID. hlast =hash last_yyyymmdd and seed hfirst =hashfirst_yyyymmdd+2 and seed mdid =Dungeon ID.

[0088] In this embodiment, maps, rewards, etc. are randomly determined based on various seeds, but since the method of randomly determining specified items such as maps and rewards based on a certain seed is well known, explanation will be omitted.

[0089] In the map creation process, the event management unit 231 creates a map. Specifically, as part of the map creation process, the event management unit 231 performs a process of determining the topography of a map (in other words, a virtual world) on which multiple dungeons will be placed, and a process of determining the placement of each dungeon on that map. Furthermore, in the map creation process, the event management unit 231 assigns an ID (in other words, identification information; hereinafter, referred to as a "dungeon ID") to each dungeon in the map to be created, allowing each dungeon to be identified. In other words, each dungeon in the map to be created is assigned a unique dungeon ID. The dungeon ID may be composed of one or more numbers, and for example, each dungeon may be assigned a consecutive number starting from 1.

[0090] In this embodiment, maps are created randomly. In other words, the map creation process has a random nature. Specifically, the event management unit 231 generates random numbers by performing calculations using a predetermined seed (hereinafter referred to as a "map creation seed"), and determines the topography of the map and the layout of each dungeon in the map based on the random numbers. The map creation seed includes the following: hlast In other words, the event management unit 231 includes the seed hlast The event management unit 231 creates a map using a function with the seed specified as an argument. hlast (in other words, the hash of the blockchain)

[0091] In the reward summary determination process, the event management unit 231 determines a reward summary for each dungeon. Specifically, in the reward summary determination process, the event management unit 231 determines the number of rewards for each dungeon and an overview of the size of each reward (for example, approximately 3 to 5 levels of size, such as small, medium, and large). Here, rewards include items B and C. That is, in the reward summary determination process, for example, the monsters that serve as item B obtained when exploring a certain dungeon are determined to be five small monsters, three medium monsters, and one large monster. Note that in this embodiment, there is one type of item C, and the reward summary determination process determines the number of items C that can be obtained when exploring a certain dungeon, but there may be multiple types of item C.

[0092] In this embodiment, the reward summary (specifically, the number of rewards and the size of each reward) is determined randomly. In other words, the determination of the reward summary is random. Specifically, the event management unit 231 generates a random number by performing a calculation using a predetermined seed (hereinafter referred to as "summary determination seed"), and determines the reward summary based on the random number. The summary determination seed includes the following: hlast and seed mdid In other words, the event management unit 231 includes the seed hlast and seed mdid In other words, the event management unit 231 determines the reward summary using a function in which the seed hlast and seed mdid When determining the reward summary for a certain dungeon, the event management unit 231 uses the dungeon ID of the certain dungeon as a seed. mdid That is, the event management unit 231 uses the seed for each dungeon. hlast (in other words, the hash of the blockchain) and the dungeon ID of each dungeon to determine the reward summary.

[0093] In the dungeon creation process, the event management unit 231 creates a dungeon as a three-dimensional virtual space that includes the reward determined in the reward summary determination process (in other words, where the reward is granted). Here, creating a dungeon may involve determining the structure of the dungeon, etc. The dungeon creation process can also be said to determine the difficulty level of the dungeon (specifically, the difficulty level of exploration). Note that, for example, in a configuration in which dungeon exploration is performed automatically, the time required for exploration (in other words, the time from the start to the end of exploration) may be longer as the difficulty level increases.

[0094] In this embodiment, dungeons are created randomly. In other words, the dungeon creation process has a random nature. Specifically, the event management unit 231 generates a random number by performing a calculation using a predetermined seed (hereinafter referred to as a "dungeon creation seed"), and creates a dungeon based on the random number. The dungeon creation seed includes the following: hlast and seed mdid The event management unit 231 then hlast and seed mdid and the reward summary determined in the reward summary determination process are specified as arguments to create a dungeon using a function. In other words, the event management unit 231 hlast and seed mdid When a dungeon is created, the event management unit 231 creates a dungeon ID of the dungeon by using the seed mdid When creating a dungeon, the event management unit 231 uses the reward summary determined for the dungeon as an argument. That is, the event management unit 231 determines whether each dungeon is created using the seed hlast Dungeons are created based on the blockchain hash (in other words), the dungeon ID of each dungeon, and the reward summary of each dungeon determined in the reward summary determination process.

[0095] In the reward detail determination process, the event management unit 231 determines the details of the rewards to be obtained in each dungeon, as determined in the reward summary determination process. Specifically, the event management unit 231 determines the details of the type, color, size, and so on of item B determined as the reward in the reward summary determination process. More specifically, for example, if the reward summary is determined to be five small monsters, three medium monsters, and one large monster, as described above, the event management unit 231 determines the types of each small, medium, and large monster, such as dragon, tiger, etc. The event management unit 231 also determines the colors of each small, medium, and large monster, such as gold, blue, white, etc. The event management unit 231 also determines the details of the size of each small, medium, and large monster, such as a body length of 50 meters, 100 meters, etc.

[0096] In this embodiment, the details of the reward (specifically, the type, color, and detailed size of item B) are determined randomly. In other words, the determination of the details of the reward is random. Specifically, the event management unit 231 generates a random number by performing a calculation using a predetermined seed (hereinafter referred to as a "detail determination seed"), and determines the details of the reward based on the random number. The detail determination seed includes the following: hfirst and seed mdid The event management unit 231 then hfirst and seed mdid The reward details are determined using a function in which the reward summary determined in the reward summary determination process is specified as an argument. In other words, the event management unit 231 determines the reward details using a function in which the reward summary determined in the reward summary determination process is specified as an argument. hfirst and seed mdid When determining the details of the reward for a certain dungeon, the event management unit 231 uses the dungeon ID of the certain dungeon as a seed. mdidWhen determining the details of the reward for a certain dungeon, the event management unit 231 uses the summary of the reward determined for that certain dungeon as an argument. That is, the event management unit 231 uses the seed hfirst (In other words, the hash of the blockchain), the dungeon ID of each dungeon, and the reward summary for each dungeon determined in the reward summary determination process.

[0097] As described above, in this embodiment, details of item B (such as the type or quantity) that may be granted based on dungeon exploration are not finalized until the reward detail determination process is executed. Details of item C (or specific tokens) that may be granted based on dungeon exploration (such as the type or quantity) may be finalized at the time the reward summary determination process is executed (in other words, before the right to execute the event is granted to the user). Furthermore, in the reward summary determination process and reward detail determination process, the summary and details of item B as a reward may be determined, and the type and quantity of item C (or specific tokens) that may be granted based on dungeon exploration may be determined, for example, at the time the reward summary determination process is executed, by a process using a seed different from the summary determination seed and the detail determination seed (a process different from the reward summary determination process). In this case, unlike the reward summary determination process and reward detail determination process, the logic of the process for determining item C and the seed used in this process may not be stored or disclosed on the blockchain (disclosure of the reward summary determination process and reward detail determination process will be described later). In other words, the seed used in the process does not have to be a blockchain-based seed (e.g., a seed related to a hash of the blockchain).

[0098] Here, the timeline for dungeon acquisition and exploration is explained with reference to Figure 5. Here, the last generated hash for May 29, 2022 is last_20220529 seed hlastIt is used as the hash of the first generated hash on May 31, 2022. first_20220531 seed hfirst This section explains an example where the game is used to generate maps and dungeons, determine rewards, etc.

[0099] First, the event management unit 231 performs a map creation process using the last hash of May 29, 2022, to create a map. Here, the last hash of May 29 (in other words, the last block) is confirmed after the fact when the date of the timestamp included in the block of the blockchain changes to May 30. In other words, the seed hlast is determined when the first hash (in other words, the first block) is generated on May 30, 2022. Therefore, in this embodiment, the event management unit 231 determines the hash last_20220529 Create a map using the following.

[0100] The event management unit 231 also performs a reward summary determination process using the last hash on May 29, 2022, and determines the reward summary for each dungeon. The event management unit 231 also performs a dungeon creation process using the last hash on May 29, 2022, and creates a dungeon that includes the rewards determined in the reward summary determination process. In this embodiment, the event management unit 231 creates a hash at the time the first hash on May 30 is generated (in other words, after the hash is generated). last_20220529 The event management unit 231 determines the reward summary using the hash value at the timing when the first hash value is generated on May 30th (in other words, after the hash value is generated). last_20220529 Use to create a dungeon.

[0101] The event management unit 231 also controls to limit the period during which the dungeon can be acquired. In this embodiment, the period during which the dungeon can be acquired is determined based on the first hash generated on that day (the seed related to the last hash of the previous day). hlastis confirmed), the first hash is generated the next day (the seed for that hash) hfirst In other words, the event management unit 231 last_20220529 The period during which a dungeon created using the above method can be acquired is controlled to be the period until the details of the reward for that dungeon are determined. In other words, once a dungeon (in other words, a map) is created, the created dungeon can be acquired until the next dungeon (in other words, a map) is created. Note that the period during which a dungeon can be acquired may be set, for example, from the generation of the first hash of that day until the end of that day (in other words, the day the dungeon was created).

[0102] In addition, the event management unit 231 performs a reward detail determination process using the first hash on May 31, 2022, and determines the details of the reward for which the last hash on May 29, 2022 was used to determine the summary. In this embodiment, the event management unit 231 performs a process to determine the details of the reward for which the last hash on May 29, 2022 was used to determine the summary. In this embodiment, the event management unit 231 performs a process to determine the details of the reward for which the first hash on May 31 was generated (in other words, after the hash was generated). first_20220531 The event management unit 231 determines the details of the reward for a dungeon after the period during which the dungeon can be acquired has elapsed. In other words, the event management unit 231 controls so that the dungeon cannot be acquired after the details of the reward have been determined.

[0103] Dungeons in which the outline and details of rewards are determined in this way are granted to users based on their operations, and can be explored.

[0104] When a user performs an operation to select a dungeon to explore, the event management unit 231 grants the selected dungeon to the user based on the operation. In other words, the event management unit 231 grants the user the right to explore the dungeon selected by the user (in other words, the right to execute an event). Specifically, for example, the operation reception unit 111 of the terminal device 10 accepts an operation to select a dungeon to explore from multiple dungeons in a map. In other words, the operation reception unit 111 accepts an operation to acquire a specific dungeon from multiple dungeons. In yet other words, the operation reception unit 111 accepts an operation to acquire the right to execute a specific event (specifically, explore a specific dungeon). In other words, in this embodiment, the user is able to explore the dungeon that he or she has acquired, and acquiring a dungeon can be rephrased as acquiring the right to explore the dungeon (in other words, execute an event). Note that granting the right to execute an event here may be any right that results in the execution of an event (e.g., exploring a dungeon). In other words, granting the right to execute an event can be said to be a process of validating the execution of the event by the user.

[0105] Furthermore, upon receiving an operation to acquire a dungeon, the display control unit 114 causes the display unit 18 to display information regarding rewards that can be acquired by exploring the dungeon. Specifically, for example, the device processing unit 113 receives information regarding an overview of the dungeon rewards from the event management unit 231, and, based on that information, causes the display unit 18 to display the number of rewards that can be acquired when exploring the dungeon, an overview of the size of each reward, and the like. More specifically, for example, in a configuration in which acquiring a dungeon is performed by an operation to select a specific dungeon on a map displayed on the display unit 18, when a specific dungeon is selected on the map, information regarding rewards that can be acquired by exploring that specific dungeon may be displayed on the display unit 18, and the user may be able to select whether or not to acquire that specific dungeon after viewing that information. Furthermore, for example, in a configuration in which acquiring a dungeon is performed by moving a playable character and guiding the playable character to a location on a map where a specific dungeon is located, when the playable character is moved to the location where the specific dungeon is located, information regarding rewards that can be acquired by exploring the specific dungeon is displayed on the display unit 18, and the user may choose whether or not to acquire the specific dungeon after viewing the information. That is, in this embodiment, the event management unit 231 is capable of presenting to the user information regarding rewards that can be acquired by executing an event before the user acquires the right to execute the event, and the information is displayed on the display unit 18. Note that the display of the information is not limited to directly indicating an outline of the rewards that can be acquired, but may also indicate the outline indirectly (for example, by suggesting the degree of expectation regarding the quantity or quality of the rewards that can be acquired).

[0106] Furthermore, the event management unit 231 stores information indicating dungeons acquired by a user on a blockchain (e.g., the Ethereum blockchain). Specifically, when a user acquires a dungeon, the event management unit 231 stores information indicating that the user has acquired the dungeon on the blockchain. That is, in this embodiment, a history of dungeon acquisition by a user is stored on the blockchain. In other words, in this embodiment, information regarding the user's right to play an event is stored on the blockchain. This configuration makes it possible to prevent the acquisition of dungeons, items, and the like through fraudulent means. That is, in this embodiment, a user is entitled to earn a reward by acquiring a dungeon with a limited acquisition period (in other words, a right to play an event), and information indicating the dungeons acquired by the user is stored on the blockchain, which is difficult to tamper with. Therefore, with this configuration, even if a user acquires an item through fraudulent means, it is possible to confirm that the user does not have acquisition information for a dungeon in which the item can be acquired, thereby proving the user's fraud. In addition, in this embodiment, dungeon acquisition information is stored on a blockchain that is difficult to rewrite, and the timing for determining reward details is after the period during which the dungeon can be acquired has elapsed, making it possible to more firmly prevent the fraudulent acquisition of items.

[0107] The event execution unit 232 starts searching a dungeon acquired by the user based on an operation by the user instructing the start of a dungeon search. That is, the operation acceptance unit 111 accepts an operation by a user who has the right to execute a predetermined event (in other words, to search a specific dungeon) to instruct the execution (in other words, start) of the predetermined event. Information related to the operation is then sent to the event execution unit 232 via the transmission / reception units 112, 211, and the event execution unit 232 starts the predetermined event based on the operation. Specifically, for example, information related to a dungeon acquired by the user may be displayed on the display unit 18, and the operation acceptance unit 111 may accept an operation instructing the start of a dungeon search while the information is being displayed.

[0108] In the game of this embodiment, exploration of a dungeon is possible after the outline of the rewards has been determined and the dungeon has been created, and it is also possible to explore the dungeon before the details of the rewards have been determined. It is also possible to explore the dungeon after the details of the rewards have been determined.

[0109] The event execution unit 232 also automatically progresses the exploration of the dungeon. That is, for example, when the operation reception unit 111 receives an operation instructing the execution of an event, the event execution unit 232 progresses the event without requiring user operation. Specifically, the event (in other words, the exploration of the dungeon) ends when a predetermined period (e.g., several hours) has elapsed since the start of the event. Furthermore, the predetermined period can be shortened by consuming specific tokens based on a user selection. Note that the event may end immediately after it has started. Furthermore, the exploration of the dungeon may be progressed by the event execution unit 232 based on a user operation. Specifically, for example, when an operation instructing the execution of an event is performed, the operation reception unit 111 may then receive an operation to move the playable character within the dungeon (in other words, within the virtual space) (in other words, an operation to search for an item placed within the dungeon, etc.), and the item that the user discovers may be granted as a reward.

[0110] The reward granting unit 233 grants a reward to the user based on the exploration of the dungeon. In other words, the reward granting unit 233 grants a reward to the user based on the execution of an event. Specifically, in this embodiment, the exploration of the dungeon proceeds automatically, and when the exploration is completed, items B and C discovered during the exploration are granted to the user. Note that, for example, when the exploration of the dungeon proceeds manually, the discovered items may be granted to the user as rewards each time the user operates the playable character to discover items B and C in the dungeon. Furthermore, at least a portion of the rewards granted based on the execution of an event may not be items discovered during the exploration, but may be granted as a reward for the exploration, etc.

[0111] Here, the timing at which the granting of item B or item C is determined based on the dungeon exploration (in other words, for example, when the dungeon exploration ends) can be either before or after the details of the reward (specifically, the details of item B) are determined. In other words, whether the dungeon exploration is performed automatically or manually, there may be cases where the details of the reward have not yet been finalized at the time when the granting of the reward is determined. Specifically, in this embodiment, there may be a situation where a monster as item B is discovered by exploring the dungeon before the details of the monster as item B are determined (in other words, the granting of item B is determined) (however, the details of item B are not yet known). Therefore, if the granting of item B is determined before the details of the reward are determined (in other words, when item B is discovered), the reward granting unit 233 does not grant item B at the time when the granting of item B is determined (in other words, for example, when the dungeon exploration ends), but grants item B as a reward after the details of item B are determined. In other words, in this embodiment, the details of the reward are determined after the dungeon obtainable period (in other words, the period during which the right to execute the event can be obtained) has elapsed as a predetermined period. There may be cases where a dungeon is explored (in other words, an event) is performed during the dungeon obtainable period and the granting of a reward is determined. However, if the granting of a reward is determined during the dungeon obtainable period, the reward granting unit 233 may grant the reward after the details of the reward are determined. Here, "granting a reward after the details of the reward are determined" in this embodiment means granting a specific monster as item B, the details of which have been determined. In other words, "granting a reward after the details of the reward are determined" may include, for example, a configuration in which an item, etc., that replaces a specific monster as item B (for example, an item indicating that a certain monster will be granted after the details have been determined) is granted before the details of the reward are determined.

[0112] In this embodiment, map creation, dungeon creation, reward summary determination, and reward detail determination are performed every day, and map and dungeon updates are performed daily. That is, for example, in the example shown in FIG. 5, the map creation process, reward summary determination process, and dungeon creation process are performed using the last hash of May 30, and the reward detail determination process is performed using the first hash of June 1 for the rewards whose summary is determined in the reward summary determination process. In this embodiment, the next map update and dungeon update are performed after the dungeon acquisition period ends, but the next map update and dungeon update may also be performed during the dungeon acquisition period. In other words, the hash used to create the map, create the dungeon, determine the reward summary, or determine the reward detail does not have to be the last or first hash of the day.

[0113] In this embodiment, the hash generated at the end of the day is used to create the map and dungeon and determine the reward summary. However, the hash generated at the end of the day (i.e., the last block of the day) is determined after the first hash of the next day (i.e., the first block of the next day) is generated. Therefore, the map and dungeon are created and the reward summary is determined after the first hash of the next day is generated. Therefore, it is possible to create the map and dungeon and determine the reward summary using the first hash of the next day. However, in this embodiment, the map and dungeon are created and the reward summary is determined using the hash generated at the end of the day, so that the map and dungeon creation and reward summary determination are performed based on different hashes from the determination of the reward details. In other words, when processes related to the map and dungeon creation and reward determination are performed on consecutive days, the hash used to determine the reward details for the summary determined the previous day is not the same as the hash used to determine the reward summary on the current day. In other words, in this embodiment, the game control unit 212 determines the details of the reward using a specific hash within a recurring arbitrary period (specifically, the first hash of the day), and determines the outline of the reward using a hash different from the specific hash (specifically, the last hash of the day). Also, while blockchains can branch, in this embodiment, when the first hash of the next day is generated, the map and dungeon are created and the outline of the reward is determined using the hash generated at the end of the day, making it possible to perform processing using hashes (in other words, blocks) that are likely to be adopted.

[0114] In the game of this embodiment, the lottery logic for item B is stored and published on the blockchain. Specifically, the logic for the reward summary determination process and the reward detail determination process is published as a smart contract. hlastThe logic for determining the reward summary using the above will be published as a smart contract. hfirst The logic for determining the reward details using the seed will be published as a smart contract. hlast and seed hfirst is a hash of the blockchain and is a publicly available seed. In other words, in this embodiment, the outline of the rewards obtainable in each dungeon is determined by a predetermined logic using a predetermined seed. The predetermined seed and the predetermined logic are publicly available, allowing each user to verify whether or not any fraudulent activity has occurred in determining the reward outline using the publicly available seed and the predetermined logic. In addition, in this embodiment, the details of the rewards obtainable in each dungeon are determined by a predetermined logic using a predetermined seed. The predetermined seed and the predetermined logic are publicly available, allowing each user to verify whether or not any fraudulent activity has occurred in determining the reward details using the publicly available seed and the predetermined logic. This configuration provides a highly transparent system that prevents the operator from interfering with the granting of rewards and clearly presents this information to users. Furthermore, by using a hash of the blockchain as the seed, the seed can be made unpredictable even to the operator and unchanging and clear to anyone. In other words, in this embodiment, the granting of rewards cannot be controlled by even the operator, and users can verify the granting of rewards using publicly available logic, making it impossible to predict in advance. This prevents fraudulent item allocation and damage to the value of the system. Furthermore, in this embodiment, the random numbers used to determine the reward summary and details are determined based on the hash of the blockchain, making the random numbers identifiable. This makes it possible to detect fraudulent manipulation of random numbers and prevent fraud such as manipulating random numbers to fraudulently cause specified objects to appear. The logic of the dungeon creation process may also be stored on the blockchain and made public, or may not be stored on the blockchain and kept private.

[0115] Item A owned by a user may be available for loan to other users. Specifically, when a user loans item A to another user, the operation receiving unit 111 of the terminal device 10 of the other user may receive an operation by the other user instructing the execution of an event for which the user has the right to execute. Information regarding the operation may then be sent to the event executing unit 232 via the transmitting / receiving units 112, 211, and the event executing unit 232 may start the event based on the operation by the other user. In other words, even if the other user does not own item A, the other user may be able to borrow item A and play the game. In this case, the reward granting unit 233 may grant a portion of the reward earned from the event executed based on the operation of the other user to the user who loaned item A. This provides the user who loans item A with the advantage of being able to get help from other users in clearing the dungeon, thereby improving the efficiency of the dungeon clearing process. Furthermore, the user who borrows the item benefits from being able to participate in the game without purchasing item A.

[0116] Next, the process of generating a dungeon and determining a reward will be described with reference to the flowchart shown in FIG.

[0117] The event management unit 231 acquires the hash generated at the end of a day from a specific blockchain (step S1). Next, the event management unit 231 uses the acquired hash as a seed (specifically, a seed hlast ) to perform calculations and create a map (step S2). Specifically, the event management unit 231 determines the topography of the map and the placement of dungeons on the map, and assigns an ID to each dungeon in the map so that each dungeon can be identified.

[0118] Next, the event management unit 231 determines a reward summary for each dungeon in the map created in step S2 (step S3). Specifically, the event management unit 231 generates a seed (specifically, a seed hlast , seed mdid ) to determine the number of rewards for each dungeon and the approximate size of each reward.

[0119] Next, the event management unit 231 creates a dungeon to which the reward outlined in step S3 is to be awarded (in other words, the dungeon that includes the reward) (step S4). Specifically, the event management unit 231 creates a seed (specifically, a seed hlast , seed mdid ) to perform calculations and create dungeons.

[0120] Next, the event management unit 231 acquires the first hash generated two days after the day the hash acquired in step S1 was generated (step S5). Next, the event management unit 231 determines the details of the reward for each dungeon in the map created in step S2 (step S6). Specifically, the event management unit 231 uses the hash acquired in step S5 and the dungeon ID of each dungeon as a seed (specifically, seed hfirst , seed mdid ) to perform calculations to determine the type, color, and specific size of item B as a reward for each dungeon.

[0121] Next, the process of acquiring and searching a dungeon will be described with reference to the flowchart shown in FIG.

[0122] The operation acceptance unit 111 of the terminal device 10 accepts an operation to acquire a dungeon to be explored from among a plurality of dungeons in a map (step S11). In other words, the operation acceptance unit 111 accepts an operation to select a specific dungeon from among a plurality of dungeons. In yet other words, the operation acceptance unit 111 accepts an operation to acquire the right to execute a specific event (specifically, to explore a specific dungeon).

[0123] When an operation to acquire a dungeon to explore is performed, the event management unit 231 grants the specific dungeon to the user based on the operation (step S12). In other words, the event management unit 231 grants the right to execute an event to the user based on the user's operation.

[0124] Furthermore, the operation receiving unit 111 receives an operation to instruct the user to start searching the acquired dungeon (step S13). In other words, the operation receiving unit 111 receives an operation by the user to instruct the execution of an event that the user has the right to execute.

[0125] Furthermore, the event execution unit 232 starts the search based on a user operation instructing the start of a dungeon search (step S14). In other words, the event execution unit 232 executes an event based on a user operation instructing the execution of an event. The executed event may be progressed by the event execution unit 232 in response to a user operation (in other words, manually), or may be progressed automatically by the event execution unit 232 without any user operation. The user may be able to select whether to progress the event manually or automatically.

[0126] Next, the reward granting unit 233 grants a reward to the user based on the exploration of the dungeon (step S15). In other words, the reward granting unit 233 grants a reward to the user based on the execution of the event. Specifically, the reward granting unit 233 grants items B and C based on the exploration of the dungeon.

[0127] In this embodiment, the items, tokens, and various logics (in other words, smart contracts) managed on the blockchain are managed on the same blockchain, but some may be managed on different blockchains. The hashes used for various processes may be hashes from the same blockchain or from another blockchain. Existing blockchains such as Ethereum and Bitcoin may be used. NFTs corresponding to item A and item B (in other words, NFTed item A and item B) may be able to be bridged from the blockchain on which they were issued to another blockchain.

[0128] Note that each configuration according to this embodiment can also be applied to content (in other words, services) other than the game according to this embodiment.

[0129] The present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention. Within the scope of the present invention, the components can be freely combined, any component can be modified, or any component can be omitted. Furthermore, the processing flow described in this specification is merely an example, and the order and configuration of each process may be different.

[0130] <Additional Notes> The matters described in the above embodiment can also be described as follows:

[0131] (Appendix 1) Computer, A control means (for example, an event execution unit 232) for controlling the execution of a predetermined event; a first granting means (e.g., a reward granting unit 233) for granting a first object to a user based on the execution of the predetermined event; and a second granting means (e.g., a reward granting unit 233) that grants at least one of a crypto asset and a second object exchangeable for the crypto asset to the user based on the execution of the predetermined event; The first object is an object that can be in an NFT state. program. This configuration makes it possible to provide a service that grants cryptocurrency or an object exchangeable for cryptocurrency upon the execution of a specific event, i.e., a service that allows users to acquire cryptocurrency upon the execution of a specific event. However, such services tend to encourage users to earn cryptocurrency. However, there is a risk that the value of cryptocurrency will decline and the economy will collapse if the acquisition of cryptocurrency exceeds the consumption of cryptocurrency. In other words, this type of service has issues with sustainability. However, this configuration makes it possible to acquire not only cryptocurrency upon the execution of a specific event, but also objects that can be converted into NFTs. Therefore, the circulation of NFT-ized objects can revitalize the economy and improve the sustainability of the service.

[0132] (Appendix 2) The probability that the first object will be awarded in the predetermined event is lower than the probability that the cryptocurrency will be awarded or the probability that the second object will be awarded in the predetermined event. The program described in Appendix 1. According to this configuration, the rarity value of the first object can be increased, and therefore it is possible to prevent the value of the first object from decreasing and the sustainability of the service from decreasing.

[0133] (Appendix 3) The computer further functions as an exchange means for exchanging the first object held by the user for the cryptocurrency. The program described in Appendix 1. This configuration strengthens the connection between the first object and the cryptocurrency, revitalizing the economy and improving the sustainability of the service.

[0134] (Appendix 4) The computer further functions as an NFT conversion means (for example, an asset management unit 213) that consumes the crypto asset to convert the first object into an NFT. A program according to any one of appendices 1 to 3. According to this configuration, when the first object is converted into an NFT and distributed, consumption of crypto assets can be required, making it possible to strike a balance between the acquisition and consumption of users' assets, thereby improving the sustainability of the service.

[0135] (Appendix 5) A control means (for example, an event execution unit 232) for controlling the execution of a predetermined event; a first granting means (e.g., a reward granting unit 233) for granting a first object to a user based on the execution of the predetermined event; and second granting means (e.g., a reward granting unit 233) that grants at least one of a crypto asset and a second object exchangeable for the crypto asset to the user based on the execution of the predetermined event. Information processing system. According to this configuration, the same effects as those of the program described in Supplementary Note 1 can be achieved. [Explanation of symbols]

[0136] 1 Game system, 3 Blockchain system, 10 Terminal device, 11 Processor, 12 Memory, 13 Storage, 14 Communication IF, 15 Input / output IF, 16 Touch screen, 17 Input unit, 18 Display unit, 20 Server, 21 Processor, 22 Memory, 23 Storage, 24 Communication IF, 25 Input / output IF, 30 Node device, 31 Processor, 32 Memory, 33 Storage, 34 Communication IF, 35 Input / output IF, 110 Control unit, 111 Operation acceptance unit, 112 Transmission / reception unit, 113 Terminal processing unit, 114 Display control unit, 120 Memory unit, 210 Control unit, 211 Transmission / reception unit, 212 Game control unit, 213 Asset management unit, 214 Market management unit, 220 Memory unit, 231 Event management unit, 232 Event execution unit, 233 Reward granting unit, 310 Control unit, 320 Memory unit

Claims

1. Computer, An exchange method for exchanging a user's non-NFT designated object for crypto assets; NFT conversion means for converting the predetermined object into an NFT by consuming the crypto asset; to function as program.

2. The predetermined object can be converted into an NFT and traded with other users, or can be exchanged for the crypto asset without trading with other users under the control of the exchange means. The program according to claim 1.

3. An exchange means for exchanging a predetermined non-NFT object held by a user for cryptocurrency; NFT conversion means for converting the predetermined object into an NFT by consuming the crypto asset; Equipped with Information processing system.

Citation Information

Patent Citations

  • Game program, method, and information processing device

    JP2019136317A

  • Program, information processing method and information processing device

    JP2021069858A

  • Game system and auction program

    JP2021152815A

  • Method and system for converting digital assets in a gaming platform

    US20190299105A1

  • Fraud detection in electronic subscription payments

    WO2021141582A1