Program and information processing system

Abstract

The present invention reduces users' reservations about services that use a blockchain.　This program causes a computer to function as: a lending means that lends a specific object that has been converted into an NFT and that can be used in a virtual space from an owner, who is a user owning the specific object, to another user; and an acquisition means that allows the owner to acquire at least a part of the results obtained by the other user using the lent specific object within the virtual space.

Description

Program and information processing system

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

[0002] Conventionally, technologies relating to the provision of various services using blockchain have been known (see, for example, Patent Document 1).

[0003] JP 2017-204070 A

[0004] However, services that use blockchain technology have been cumbersome, requiring various registration procedures related to blockchain-based transactions. Furthermore, due to the need for such registration procedures and the fact that transactions may require monetary payments, blockchain-based services generally present a hurdle for users to use.

[0005] The present invention aims to reduce users' resistance to services that use blockchain.

[0006] According to one embodiment of the present disclosure, a program is provided that causes a computer to function as: a lending means for lending a specific NFT-enabled object that can be used in a virtual space from an owner, who is a user who owns the specific object, to another user; and an acquisition means for allowing the owner to acquire at least a portion of the results obtained by the other user using the loaned specific object in the virtual space.

[0007] According to the present invention, it is possible to reduce users' resistance to services that utilize blockchain.

[0008] 1 is a diagram showing a schematic configuration of a game system. FIG. 2 is a block diagram showing the functional configuration of the game system. FIG. 3 is a diagram showing an example of a screen displaying a map. FIG. 4 is a diagram showing an example of a home screen. FIG. 5 is a diagram showing an example of a screen displaying a list of mountains acquired by the user. FIG. 6 is a diagram showing an example of a game screen when mining is performed. FIG. 7 is a diagram explaining the flow of asset acquisition and consumption. FIG. 8 is a diagram explaining a timeline related to mountain acquisition and mining. FIG. 9 is a diagram showing an example of a screen related to item purchase. FIG. 10 is a diagram showing an example of a screen displaying a list of items owned by the user. FIG. 11 is a diagram showing an example of a menu screen that can be displayed while mining is in progress. FIG. 12 is a diagram showing an example of a screen related to the lending of a pickaxe. FIG. 13 is a diagram showing an example of a screen for recruiting scholars. FIG. 14 is a diagram showing an example of a screen for applying for a scholarship recruitment. A flowchart showing an example of processing related to mountain generation and determination of items that can be acquired in a mountain. A flowchart showing an example of processing related to mountain acquisition and mining. A flowchart showing an example of processing for lending a pickaxe to another user. A flowchart showing an example of processing for allowing the owner to acquire at least a portion of results obtained by a scholar's use of the pickaxe.

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

[0010] 1, the game system 1 of this embodiment includes a plurality of terminal devices 10, a server 20, and a blockchain system (in other words, a blockchain network) 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.), Wi-Fi (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 central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), 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 read-only memory (ROM) and a random access memory (RAM). The memory 22 temporarily stores programs and various data read by the processor 21 from the storage 23, thereby providing a working area for the processor 21. The memory 22 also temporarily stores various data generated while the processor 21 is 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 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 a hard disk drive (HDD). The storage 23 stores various data related to the game.

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

[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 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.

[0019] The terminal device 10 (in other words, a computer or 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 also be a mobile terminal. The terminal device 10 may also 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 of 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 temporarily stores programs and various data that the processor 11 reads from the storage 13, thereby providing a working area for the processor 11. 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 the 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 the 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 outputs data from the terminal device 10. The input / output IF 15 may input and output data via, for example, a Universal Serial Bus (USB) 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 or a mouse. The display unit 18 displays images. The display unit 18 may be, for example, a liquid crystal display or an organic electroluminescence (EL) display. The terminal device 10 may include, for example, a touch screen, which is an electronic component that combines the input unit 17 and the display unit 18. In this case, the input unit 17 may have 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.

[0027] 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.

[0028] In this embodiment, the description will be given assuming that the input unit 17 is a keyboard and a mouse. Note that in this embodiment, operations on various UIs such as buttons may be performed by, for example, placing a mouse cursor on an area on the display unit 18 where the button or the like is displayed and clicking.

[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 of 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, an MPU, a GPU, 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 and a RAM. The memory 32 temporarily stores the 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, for example.

[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] Note that 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] 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. Examples of the various data include programs, game information, and user information. The programs are programs for realizing games. The game information and user information are data referenced by the control unit 210 when executing the programs.

[0040] The game information includes, for example, information for defining various virtual spaces (in other words, game spaces). A virtual space is a space in which objects such as characters that can be controlled by a user (hereinafter also referred to as "player characters") are placed. The game information also includes, for example, information regarding the placement positions and setting values ​​of various objects such as buildings, trees, stones, and items placed in the virtual space. Hereinafter, character objects placed in the virtual space may also be simply referred to as "characters."

[0041] User information is information managed for each game account. User information includes, for example, information about the player character, information about owned assets, information indicating the progress of the game, and information about mountains acquired by the user (mountains will be described later) (in other words, information about rights related to playing a game in a specific virtual space). Owned assets can be considered to be value possessed by the user in the virtual space. Examples of such value include electronic currency, tokens, items, characters, etc. Examples of electronic currency include virtual currency (in other words, crypto assets) and in-game currency that can be used in a game. That is, the storage unit 220 may store information about electronic currency, tokens, items, characters, etc. possessed 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 types of data. For example, the transmitting / receiving unit 211 receives requests to transmit various types of data and programs, requests for synchronization processing to support the multiplay function, data to be subjected to synchronization processing, etc. from each terminal device 10, and passes them to the game control unit 212, asset management unit 213, market management unit 214, etc. Furthermore, the transmitting / receiving unit 211 transmits various types of 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, etc.

[0044] In this embodiment, the multi-play function is a function that synchronizes game processing by multiple accounts. When multiple accounts logged in to the game system 1 participate in the same game, the server 20 and the terminal device 10 of the game system 1 execute various processes to support the multi-play function.

[0045] 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 .

[0046] The game control unit 212 defines the virtual space based on information for defining the virtual space included in the game information. The game control unit 212 places objects in the virtual space based on object setting information included in the game information. The game control unit 212 controls the objects placed in the virtual space. Specifically, the game control unit 212 changes the position, orientation, shape, color, etc. of the objects in the virtual space, and causes the objects to perform predetermined actions.

[0047] The game control unit 212 also places the player character in the virtual space based on the play information transmitted from the terminal device 10. The game control unit 212 also performs various determination processes related to the progress of the game based on the play information transmitted from the terminal device 10. In other words, the game control unit 212 controls objects and performs various determination processes based on the user's input operation. The play information is output in response to the user's input operation. For example, the play information may include, as the operation content of the player character, coordinate information of the player character, information regarding the player character's action, or information indicating a button operated by the user. The play information may also include information regarding the player character's settings. For example, the character's coordinate information is information indicating the character's position in the game space. For example, the action information is information regarding the character's action. For example, the character's action may include, for example, swinging a pickaxe, using various items, or jumping, as described below. For example, the information regarding the character's settings may include information regarding the character's equipment, appearance, etc. The character's settings may also be changed by the user.

[0048] The game control unit 212 can place the player characters of the multiple players in one virtual space and control the player characters of each player based on play information transmitted from each player's terminal device 10. In other words, the game control unit 212 performs control so that a game space, which is an example of a virtual space, can be shared by multiple users.

[0049] Furthermore, when the game control unit 212 receives, for example, a request for synchronization processing to support the multiplay function or data to be subjected to synchronization processing from the terminal device 10 via the transmission / reception unit 211, the game control unit 212 executes synchronization processing to support the multiplay function. The game control unit 212 also issues a command to the transmission / reception unit 211 to instruct the transmission / reception unit 211 to transmit game information or user information. For example, when the server 20 transmits information to multiple terminal devices 10, the game control unit 212 synchronizes the game progressing among the terminal devices 10 by simultaneously transmitting the information to each terminal device 10. By executing synchronization processing, it becomes possible to simultaneously reflect in-game events resulting from operations input on one terminal device 10 on the other terminal devices 10.

[0050] The asset management unit 213 manages the assets held by the user. The asset management unit 213 also manages some or all (in other words, at least some) of the assets held by the user in the distributed ledger of the blockchain system 3. In other words, the asset management unit 213 may store information about the assets held by the user 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 the distributed ledger stored in its own storage unit 220. Note that, 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.

[0051] 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.

[0052] 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, programs, game information, and user information. The programs are programs for realizing games on the terminal device 10 side. The game information and user information are data referenced by the control unit 110 when executing the programs. The game information and user information stored in the storage unit 120 may include information similar to the game information and user information stored in the storage unit 220.

[0053] 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.

[0054] The operation reception unit 111 receives operations (hereinafter also referred to as "input operations") input by the user via the input unit 17. Specifically, the operation reception unit 111 detects input operations on a mouse or keyboard serving as the input unit 17. Note that the input operations are not limited to operations that involve physical contact with the input unit 17, but may also include non-contact operations. Note that the operation reception unit 111 can also receive input operations performed using an operating device connected via the input / output IF 15, in the same way as input operations on the input unit 17.

[0055] The transmitting / receiving unit 112 transmits or receives various types of data. The transmitting / receiving unit 112 transmits, for example, various types of data and various requests to the server 20. As an example, the data transmitted by the transmitting / receiving unit 112 to the server may include play information, game information, and user information. In other words, the transmitting / receiving unit 112 transmits information regarding the input operation received by the operation receiving unit 111 to the server 20.

[0056] The transmission / reception unit 112 also receives various data, programs, and various requests from the server. For example, the data received by the transmission / reception unit 112 from the server 20 may include the type of object (e.g., character or item) to be placed in the game space, object coordinate information, character action information, information related to character settings, and other information. For example, the data received by the transmission / reception unit 112 from the server may include synchronization data for supporting a multiplayer function. The synchronization data may include, for example, the data to be synchronized, the type of data, and data for specifying the time to synchronize.

[0057] The device processing unit 113 executes various processes related to the progress of the game. The device processing unit 113 identifies the user's instruction content based on the user's 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 identified 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.

[0058] The device processing unit 113 defines a virtual camera for specifying an area of ​​the virtual space to be presented to the user. The device processing unit 113 places the virtual camera in the virtual space by defining the position and orientation of the virtual camera within the virtual space. The device processing unit 113 instructs the display control unit 114 to generate an image depicting the field of view defined by the virtual camera and the objects located in this field of view. In other words, the device processing unit 113 instructs the display control unit 114 to display an image corresponding to the progress of the game on the display unit 18.

[0059] The position and orientation of the virtual camera can be determined appropriately for each virtual space. For example, the device processing unit 113 uses the position and orientation of a specific object as a reference and positions the virtual camera so that the specific object is located at the center of the field of view in a specific orientation. In this case, the device processing unit 113 adjusts the position and orientation of the virtual camera using the direction, distance, and angle relative to the specific object. The specific object may be, for example, a dynamic object such as a player character or a non-player character, or a static object such as a building, tree, or stone. Dynamic objects include player characters that act based on the operation of each user and non-player characters that act based on a program.

[0060] The display control unit 114 displays images relating to the game on the display unit 18. A specific example will be described below.

[0061] The display control unit 114 generates an image that depicts the area of ​​the virtual space that is within the field of view of the virtual camera, as defined by the device processing unit 113, and the objects that exist in that area, and displays the image on the display unit 18. The display control unit 114 can superimpose and draw objects related to a UI (User Interface) that are necessary for various game operations, such as icons, buttons, and menus that indicate various parameters, on the image to be displayed on the display unit 18.

[0062] The control unit 110 of the terminal device 10 may arrange objects in the virtual space based on object data sent from the server 20, information indicating the positions of various objects in the virtual space, etc., and display a predetermined area of ​​the virtual space on the display unit 18. The control unit 210 of the server 20 may arrange objects in the virtual space and control the virtual camera, generate an image to be displayed on the display unit 18, and transmit it to the terminal device 10, and the control unit 110 of the terminal device 10 may display the image on the display unit 18. In other words, various processes related to control of objects based on user input operations, control of the virtual camera, generation of images to be displayed on the display unit 18, etc. may be performed by the server 20 or by the terminal device 10.

[0063] 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.

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

[0065] When a user acquires various items or a specific token (described later) (for example, from another user or a game operator (for example, by mining, described later)), the control unit 310 receives a registration request for information related to the holding of the item or specific token, 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 or specific token in the distributed ledger, for example, based on information related to transactions (in other words, transfers) of the item or specific token transmitted from the server 20 or the terminal device 10. Specifically, the distributed ledger stores multiple blocks each containing a hash value and a transaction. A transaction may be, for example, information indicating the transaction details of the item or specific token. A transaction 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 transaction history information for the item or specific token, with each block linked like a chain by the hash value. By managing such transaction history in a distributed ledger in each node device 30, information indicating which user owns which item and information indicating how many specific tokens each user owns can be stored on the blockchain. Note that, instead of the transaction history of items, etc., information regarding the ownership status of each user's items, etc. may be managed in a distributed ledger, so that information indicating which user owns which item, etc. can be stored on the blockchain. In this way, in the game of this embodiment, ownership information for items and specific tokens is stored on the blockchain. Note that there may be items, etc. whose ownership information is not stored on the blockchain.

[0066] 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, in this embodiment, the server 20 or the node device 30 may have some or all of the functional blocks of the terminal device 10, 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. For example, they may be realized by 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.

[0067] <Processing According to the Present Embodiment> Next, the processing according to the present embodiment will be described. Note that in the present 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 the present 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.

[0068] An overview of the game of this embodiment will now be described. In the game of this embodiment, a map 40 exists that is shared among multiple users (specifically, all users) participating in the game. An example of the map 40 is shown in FIG. 3. Multiple mountains are arranged on the map 40. In the map 40 shown in FIG. 3, the positions of the mountains are indicated by triangular symbols.

[0069] The user acquires (or selects) a mountain from the map 40 to be mined (or a virtual space in which the game is played). Acquisition of a mountain is performed, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display a map 40 (or a list of mountains that the user can acquire) as shown in FIG. 3 based on a predetermined input operation by the user. The user can then acquire a specific mountain by selecting the specific mountain on the map 40 displayed on the display unit 18 (for example, by clicking on the specific displayed mountain). Specifically, for example, when an operation to select a specific mountain from the mountains displayed on the map 40 is performed, the display control unit 114 causes the display unit 18 to display an acquire button 41 that accepts an operation to acquire the selected mountain. The game control unit 212 then causes the user to acquire the mountain selected by the user based on the operation on the acquire button 41.

[0070] Furthermore, the user is able to mine for predetermined items in the mountain that the user has acquired. In other words, once the user has acquired a mountain, the user is able to play a game in which the user mines in the acquired mountain. That is, in this embodiment, "acquiring a specific mountain" can be rephrased as "acquiring the right to mine in a specific mountain," or further, as "acquiring the right to play a game in a specific virtual space." Note that the system may be configured so that the user can mine in a mountain without acquiring the mountain (in other words, without acquiring the right to mine).

[0071] In addition, in the game of this embodiment, item A is provided, which is used for mining in the mountain. To mine, the user must have item A. In other words, item A is an item necessary to participate in the game. In this embodiment, item A is a pickaxe. It may be configured so that a user without item A cannot acquire the mountain. 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. Hereinafter, digital assets such as items issued with corresponding NFTs 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 users cannot perform this (in other words, mint by users). In other words, in the game of this embodiment, the user is prevented from obtaining item A that has not been converted into an NFT. However, the user may be able to convert item A into an NFT.

[0072] Furthermore, in the game of this embodiment, the user can acquire items B and C through mining. 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."

[0073] Furthermore, in the game of this embodiment, there are multiple types of item B, which are collectible items. Specifically, item B is a gem that the user collects. Item C is a mineral (hereinafter referred to as "pyroxene") that is different from gems. That is, the game of this embodiment has the gameplay of mining in the mountains using a pickaxe as item A to obtain gems as item B and pyroxene as item C.

[0074] 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, and turn item B into an NFT.

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

[0076] Mining a mountain as a predetermined event is performed, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display a home screen 42 illustrated in FIG. 4 based on a predetermined input operation by the user. The home screen 42 displays a start mining button 43 that accepts an operation related to starting mining in the mountain acquired by the user. Then, the game control unit 212 causes the user to start mining in the mountain acquired by the user based on the operation on the start mining button 43.

[0077] The home screen 42 is initially displayed when the game (or, in other words, an application related to a predetermined service) is launched on the terminal device 10. Here, "first displayed when launched" includes the case where the home screen 42 is displayed after various launch-related displays (e.g., a title display, a loading display, etc.) are displayed. The home screen 42 is not limited to being displayed at launch, but may be displayed upon a predetermined trigger. For example, the home screen 42 may be displayed when the home button 90 is operated or when in-game mining in the mountains is completed. The home screen 42 may display a predetermined background image (e.g., a background image including a player character, etc.). The home screen 42 may also display multiple menu items related to the game. Specifically, the home screen 42 may display various UIs that accept operations related to the display of various screens. For example, the UIs may include a mine button 91, an item button 92, a loan-related button 93, a shop button 94, and a home button 90. The display control unit 114 may then display, on the display unit 18, a screen displaying a map 40 as illustrated in FIG. 3 or a screen displaying a list 44 of acquired mountains as illustrated in FIG. 5, based on an operation on the mine button 91. The display control unit 114 may also display, on the display unit 18, an item screen 64 as illustrated in FIG. 10, based on an operation on the item button 92. The display control unit 114 may also display, on the display unit 18, a loan-related screen 400 as illustrated in FIG. 12, based on an operation on the loan-related button 93. The display control unit 114 may also display, on the display unit 18, a shop screen 60 as illustrated in FIG. 9, based on an operation on the shop button 94. The display control unit 114 may also display, on the display unit 18, a home screen 42, based on an operation on the home button 90. In addition, the display control unit 114 may switch the display between a screen displaying the map 40 illustrated in FIG. 3 and a screen displaying the list of acquired mountains 44 illustrated in FIG. 5 based on operations on the map display button 95 and the my mine display button 96 shown in FIG. 3 and FIG. 5, respectively.The mine button 91, item button 92, loan-related button 93, shop button 94, and home button 90 may be displayed while various screens other than the home screen 42 are displayed.

[0078] The mountain to be mined by the user is determined, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display a list 44 of mountains acquired by the user, as shown in FIG. 5 , based on a predetermined input operation by the user. The list 44 of mountains may be, for example, a list of mountains acquired by the user on a map 40 displayed on the display unit 18. When an operation to select a specific mountain from the mountains acquired by the user (in other words, the listed mountains) displayed on the display unit 18 (e.g., a click operation on the specific mountain) is performed, the display control unit 114 causes the display unit 18 to display a mining target determination button 46 that accepts an operation to determine the selected mountain as the mountain to be mined. Furthermore, the game control unit 212 sets the mountain selected by the user as the mountain to be mined based on an operation on the mining target determination button 46. When the start mining button 43 is operated, mining begins on the mountain set as the mountain to be mined by operating the mining target determination button 46. That is, in this embodiment, the user can select (in other words, change) the mountain to be mined by selecting a mountain to be mined from the acquired mountain list 44 and operating the mining target selection button 46. When the user selects a specific mountain from the acquired mountain list 44, a start mining button 43 may be displayed instead of or in addition to the select mining target button 46 (see FIG. 5 ), and operating the start mining button 43 may start mining in the specific mountain. As shown in FIG. 4 , the home screen 42 (i.e., the screen that accepts operations related to starting mining) may display a display 48 that allows the user to identify the mountain set as the mountain to be mined (i.e., the mountain from which mining will begin upon an operation to start mining). The home screen 42 may also display a display 49 that allows the user to identify the pickaxe set as the pickaxe to be used for mining (i.e., the pickaxe equipped on the player character).

[0079] When the mining start button 43 is operated, the game control unit 212 places the player character 38 in a mountain 37, which is a virtual space where mining is to be performed, as shown in FIG. 6 . The game control unit 212 then moves the player character 38 based on the user's input operation. That is, the mountain 37 is a virtual space in which the user can operate the player character 38 to play a predetermined game (specifically, a mining game, in other words, a predetermined in-game) (in other words, to execute a predetermined event). That is, starting mining on a specific mountain 37 can be considered the start of playing a game in a specific virtual space, or entering a specific virtual space. Based on the user's input operation, the game control unit 212 moves the player character 38 within the virtual space and causes the player character 38 to perform an action using the pickaxe 39 (specifically, swinging the pickaxe 39). The method of operating the player character 38 within the virtual space can be similar to that of a conventional action game, but may also be, for example, as follows. The game control unit 212 may move the player character 38 within the mountain 37 based on an operation of the "W", "A", "S", or "D" keys on the keyboard. The game control unit 212 may also cause the player character 38 to jump based on an operation of the space key on the keyboard. The game control unit 212 may also cause the player character 38 to perform a mining action of swinging the pickaxe 39 and digging into the mountain 37 based on a left-click operation of the mouse.

[0080] Gems and pyroxenes are buried (in other words, arranged) in the mountain 37. The user can acquire the gems and pyroxenes that he or she digs up (in other words, discovers). That is, when the player character 38 operated by the user digs up an item such as a gem or pyroxene, the game control unit 212 grants the excavated item to the user (in other words, allows the user to acquire the excavated item).

[0081] Note that mining can be interrupted midway. For example, the display control unit 114 of the terminal device 10 displays a menu screen 70 shown in FIG. 11 on the display unit 18 based on a predetermined input operation by the user (e.g., an operation on the Tab key on the keyboard). The menu screen 70 displays an Exit button 71 that accepts an operation related to exiting the mountain. The game control unit 212 then causes the player character 38 to exit the mountain 37 (in other words, ends mining) based on the operation of the Exit button 71. At this time, the game control unit 212 stores the mining progress status in the storage unit 220. Then, when mining in the same mountain 37 is started next time, the game control unit 212 reads out the stored progress status and resumes mining from where it left off. In other words, when mining is resumed, the previously excavated portion of the mountain 37 will be in a completely excavated state, and the gems and other objects buried in the mountain 37 that were previously dug up will be in a completely excavated state. In other words, when the user exits and re-enters mountain 37 as a specific virtual space, the changes made by the user the last time the user entered the space are reflected in the specific virtual space. In other words, in this embodiment, it is possible to suspend a game in a specific virtual space and resume it from where it was interrupted.

[0082] Furthermore, the user can dispose of the mountains he or she has acquired at will. For example, as shown in FIG. 5 , when an operation is performed to select a specific mountain from the mountains acquired by the user and displayed on the display unit 18 (in other words, the mountains displayed in a list), the display control unit 114 causes the display unit 18 to display a disposal button 47 that accepts an operation related to disposing of the selected mountain. Then, based on the operation on the disposal button 47, the game control unit 212 disposes of the selected mountain (in other words, cancels the user's acquisition of the selected mountain). The disposed mountain disappears from the list 44 of mountains acquired by the user, and mining at that mountain becomes unavailable.

[0083] In this embodiment, the pickaxe to be used in mining is selected before mining begins by operating the mining start button 43. The operation for selecting such a pickaxe can be similar to the operation for selecting the weapon to be used (in other words, equipped to the player character 38) in conventional games. The pickaxe to be used may be changeable while mining is in progress.

[0084] Pickaxes used for mining have a durability value set, and the durability value decreases as they are used for mining (for example, from a durability value of "100" to a durability value of "0"). When the durability value reaches a predetermined value (for example, a durability value of "0"), the pickaxe becomes unusable. In other words, mining cannot be performed using a pickaxe whose durability value has reached the predetermined value. Specifically, when the durability value reaches the predetermined value, the pickaxe can be swung, but it cannot dig the surface even when swung. Note that when the durability value reaches the predetermined value, mining using the pickaxe may still be possible, although its performance will decrease.

[0085] The operation receiving unit 111 also receives an operation by the user instructing the recovery of the durability of the pickaxe (in other words, repairing item A). The game control unit 212 then performs processing to recover the durability of the pickaxe based on the operation. A predetermined amount of specific tokens is required to recover the durability of the pickaxe, and the predetermined amount of specific tokens is consumed when the durability of the pickaxe is recovered by the operation.

[0086] Furthermore, pickaxes are assigned a rank. Note that rank includes so-called levels, etc. As the pickaxe's rank increases, certain parameters of the pickaxe change. Specifically, as the pickaxe's rank increases, certain parameters that affect the ease of obtaining gems and gemstones (in other words, the efficiency of mining) change. More specifically, as the pickaxe's rank increases, parameters related to the pickaxe's swing speed change, increasing the pickaxe's swing speed. This increases the mining speed and therefore the mining efficiency. Furthermore, as the pickaxe's rank increases, the pickaxe's maximum durability value increases. This increases the amount of time that mining can continue without the durability value recovering, thereby increasing the mining efficiency. Furthermore, as the pickaxe's rank increases, the pickaxe's power increases, which may increase the amount of material that can be dug with one swing (in other words, the impact that one operation has on the mountain). This increases the mining speed and therefore the mining efficiency.

[0087] The operation receiving unit 111 also receives an operation to instruct an increase in the rank of the pickaxe. The game control unit 212 then performs processing to increase the rank of the pickaxe based on the operation. Increasing the rank of the pickaxe also requires a predetermined amount of specific tokens, and when the rank of the pickaxe is increased by the operation, the predetermined amount of specific tokens is consumed.

[0088] In the game of this embodiment, items may be prepared that can be obtained through acquisition routes different from items A, B, and C. For example, there may be items (e.g., items that can be equipped by a player character) that can be purchased in the game using in-game currency that is not a crypto asset (e.g., assets held by a user that are not managed by a blockchain but are managed in the storage unit 220, etc.). The in-game currency may be purchased using legal tender, etc.

[0089] Furthermore, various items (e.g., item A, item B, and item C) in this embodiment may be referred to as objects. Objects include characters, items, etc. That is, item B and item C, which are acquired by playing a game (in other words, executing an event) in a mountain as a specific virtual space, may be characters, etc.

[0090] In this embodiment, the map is updated (in other words, newly generated) at predetermined intervals (specifically, once a day). Acquirable mountains are also updated (in other words, newly generated) at predetermined intervals (specifically, once a day) in conjunction with the map updates. Only one user can acquire a mountain, and once a user acquires a mountain (in other words, the right to mine that mountain), that mountain cannot be acquired by other users. In other words, mountains are acquired on a first-come, first-served basis. Updates to the map and acquireable mountains may involve completely replacing past maps and mountains (in other words, new maps and mountains are generated, and past maps are deleted or past mountains are no longer acquireable), or may involve expanding past maps or adding new mountains to previously generated mountains (in other words, increasing the number of acquireable mountains).

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

[0092] As described above, in the game of this embodiment, a user is required to have a pickaxe in order to participate in the game. In this embodiment, the pickaxe can be purchased in the in-game marketplace, and the user purchases the pickaxe in the marketplace. The pickaxe can be purchased using a specific token. 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 this 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 performs processing to transfer the item selected by the user to the user based on the operation, and to transfer the payment from the user to the person who sold the item.

[0093] The user then uses the pickaxe to mine in the mountains, obtaining a variety of items including gems and gemstones.

[0094] The pyroxene acquired by the user can be exchanged for a specific token. The exchange of the pyroxene for the specific token may be performed automatically or based on an operation by the user instructing the exchange. For example, all pyroxene owned by the user may be periodically converted into the specific token. Specifically, all pyroxene owned by the user may be automatically converted into the specific token at a predetermined time every day, and all pyroxene owned by the user at that time may be lost. Furthermore, the pyroxene may be automatically exchanged for the specific token at a specific timing, such as when the user leaves the mountain. In this embodiment, pyroxene is granted to the user through mining in the mountain, and the pyroxene is exchanged for the specific token. However, the specific token may be granted directly to the user in place of or in addition to the pyroxene mined in the mountain.

[0095] In this embodiment, the specific token is a virtual currency managed by a blockchain. The specific token may be a token that can be exchanged for other crypto assets at a predetermined exchange (for example, a decentralized exchange). The specific token may be a unique token related to the game of this embodiment, a token with an issuance limit set, or a virtual currency that can be used outside the game.

[0096] Furthermore, gems acquired by a user can be converted into NFTs by satisfying certain conditions. In other words, in this embodiment, NFTs corresponding to gems can be issued and managed on a blockchain. Specifically, for example, after a user acquires a gem, the process of converting the gem into an NFT may be initiated in response to a user operation on the acquired gem, or the process of converting the gem into an NFT may be initiated automatically without any user operation on the acquired gem. For example, the operation reception unit 111 of the terminal device 10 may receive an operation by the user to select a gem to be converted into an NFT in the game. Information regarding this operation may then be sent via the transmission / reception units 112 and 211 to the asset management unit 213 of the server 20, and the asset management unit 213 may convert the selected gem into an NFT based on this operation. Furthermore, NFT conversion requires a fee (e.g., a predetermined amount of specific tokens), and when converting a gem into an NFT through this operation, this fee may be consumed from the user's assets. Furthermore, NFT-converted gems may be traded on an in-game marketplace, etc. In other words, converting an item into an NFT can be considered as making the item available for buying and selling on a marketplace. Specifically, for example, the operation reception unit 111 of the terminal device 10 may receive an operation in which a user selects a gemstone they want to sell (specifically, an NFT-converted gemstone). Information regarding the operation may then be sent to the market management unit 214 of the server 20 via the transmission / reception units 112 and 211, and the market management unit 214 may then put the gemstone selected by the user up for sale based on the operation. If there is another user who wishes to purchase the gemstone, the market management unit 214 may then transfer the gemstone to the other user and transfer the payment from the other user to the user who sold the gemstone. In other words, the NFT-converted item B may be tradeable with other users.

[0097] Furthermore, the gem may be exchangeable for a specific token. Specifically, the operation reception unit 111 of the terminal device 10 may receive an operation by the user to select a gem 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 and 211, and the asset management unit 213 may grant the specific token to the user in exchange for the selected gem based on the operation. In other words, the gem may be an item that can be converted into an NFT and exchanged for a specific token. Note that the exchange of the gem for the specific token may be performed either before or after the gem is converted into an NFT, or may be performed both ways.

[0098] The game control unit 212 controls the game played by the user. The game control unit 212 has a virtual space management unit 231 and a reward granting unit 233. The virtual space management unit 231 also executes a map creation process for creating a map, an item overview determination process for determining an overview of items that can be obtained on each mountain (in other words, items to be placed in each virtual space), a virtual space creation process for creating mountains, and an item detail determination process for determining details of items that can be obtained on each mountain.

[0099] 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 an operation using a predetermined seed. The predetermined seed includes a seed using a blockchain (for example, a Bitcoin blockchain) and a seed using a virtual space 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" and "seed") are used. ｈｌａｓｔ "," "seed ｈｆｉｒｓｔ ") and one type of seed using a virtual space ID (hereinafter referred to as "seed ｍｄｉｄ ") is available.

[0100] More specifically, a seed related to the hash of a blockchain (specifically, for example, a Bitcoin blockchain) as a seed using a blockchain and a seed related to a virtual space ID are used to achieve randomness. In this embodiment, hashlast_yyyymmdd, which is the last hash (in other words, the hash value of the last generated block) of an arbitrary period (for example, one day), and hashfirst_yyyymmdd+2, which is the first hash (in other words, the hash value of the first generated block) on the day after hashlast_yyyymmdd was generated, are used as seeds related to the hash. Also, in this embodiment, the virtual space ID is used as a seed related to the virtual space ID. That is, in this embodiment, seed ｈｌａｓｔ = hashlast_yyyymmdd, seed ｈｆｉｒｓｔ = hashfirst_yyyymmdd+2, and seed ｍｄｉｄ = Virtual space ID.

[0101] In this embodiment, items that can be obtained on the map and in each mountain are randomly determined based on various seeds, but since the method of randomly determining specific items such as the map and various objects based on a certain seed is well known, explanation will be omitted.

[0102] In the map creation process, the virtual space management unit 231 creates a map. Specifically, as part of the map creation process, the virtual space management unit 231 performs a process of determining the topography of a map (in other words, a virtual world) on which multiple mountains are arranged and a process of determining the arrangement of each mountain in the map. In addition, in the map creation process, the virtual space management unit 231 assigns an ID (in other words, identification information; hereinafter, referred to as a "virtual space ID") to each mountain in the map to be created, allowing the mountain to be identified. In other words, each mountain in the map to be created is assigned a unique virtual space ID. Note that the virtual space ID may be composed of one or more numbers; for example, each mountain may be assigned a consecutive number starting from 1.

[0103] In this embodiment, the map is created randomly. In other words, the map creation process is random. Specifically, the virtual space 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 placement of each mountain on the map based on the random numbers. The map creation seed includes ｈｌａｓｔ In other words, the virtual space management unit 231 includes the seed ｈｌａｓｔ The virtual space management unit 231 creates a map using a function with the seed specified as an argument. ｈｌａｓｔ (in other words, the hash of the blockchain).

[0104] In the item overview determination process, the virtual space management unit 231 determines an overview of the items that can be obtained for each mountain (in other words, the items to be placed in each virtual space). Specifically, as part of the item overview determination process, the virtual space management unit 231 determines the number of items B buried in each mountain and an overview of the size of each item B (for example, a rough size such as small, medium, or large). That is, in the item overview determination process, for example, the number of gems buried in each mountain that can be obtained by mining that mountain is determined to be one large gem and two small gems. Note that the item overview determination process may also determine the number of pyroxenes buried in each mountain, etc.

[0105] In this embodiment, the outline of an obtainable item (specifically, the number and size of item B) is determined randomly. In other words, the determination of the outline of an obtainable item is random. Specifically, the virtual space management unit 231 generates a random number by performing a calculation using a predetermined seed (hereinafter referred to as a "outline determination seed"), and determines the outline of an obtainable item based on the random number. The outline determination seed includes ｈｌａｓｔ and seed ｍｄｉｄ In other words, the virtual space management unit 231 includes the seed ｈｌａｓｔ and seed ｍｄｉｄIn other words, the virtual space management unit 231 determines the outline of the obtainable items using a function with the seed and ｈｌａｓｔ and seed ｍｄｉｄ When determining the outline of the items that can be acquired for a certain mountain, the virtual space management unit 231 uses the virtual space ID of the certain mountain as a seed. ｍｄｉｄ That is, the virtual space management unit 231 uses the seed ｈｌａｓｔ (In other words, the hash of the blockchain) and the virtual space ID of each mountain, an overview of the items that can be obtained is determined.

[0106] In the virtual space creation process, the virtual space management unit 231 creates a mountain as a three-dimensional virtual space where the item determined in the item summary determination process can be obtained (in other words, where the item is placed). In this embodiment, the mountain is created randomly. In other words, the virtual space creation process has randomness. For example, the topography of the mountain and the location where each item is buried on the mountain may be determined randomly. The virtual space management unit 231 generates a random number by performing a calculation using a predetermined seed (hereinafter referred to as a "virtual space creation seed"), and creates a mountain based on the random number. The virtual space creation seed includes the following: ｈｌａｓｔ and seed ｍｄｉｄ The virtual space management unit 231 then ｈｌａｓｔ and seed ｍｄｉｄ The virtual space management unit 231 creates a mountain using a function in which the outline of the obtainable item determined in the item outline determination process is specified as an argument. ｈｌａｓｔ and seed ｍｄｉｄ When creating a mountain, the virtual space management unit 231 assigns the virtual space ID of the mountain to the seed ｍｄｉｄ When creating a mountain, the virtual space management unit 231 uses the outline of the obtainable items determined for the mountain as an argument. ｈｌａｓｔThe mountains are created based on the block chain ID (in other words, the hash of the blockchain), the virtual space ID of each mountain, and the summary of the obtainable items for each mountain determined in the item summary determination process.

[0107] In the item detail determination process, the virtual space management unit 231 determines details of the items obtainable from each mountain determined in the item summary determination process. Specifically, the virtual space management unit 231 determines the type, detailed size, shape, or quality of the item B obtainable from each mountain determined in the item summary determination process. More specifically, for example, if the overview of the obtainable items is determined to be two small gems and one large gem, as described above, the virtual space management unit 231 determines the type of each small gem and large gem, such as diamond, aquamarine, red spinel, etc. The virtual space management unit 231 also determines the quality of each small gem and large gem, such as low quality, medium quality, or high quality. The virtual space management unit 231 also determines the size details of each small gem and large gem, such as 0.2 carats or 6.4 carats. Note that the quality of gems may also be determined taking into account their carat weight. For example, the higher the carat weight, the higher the quality of the gem.

[0108] In this embodiment, the details of the obtainable item (specifically, the type, quality, and detailed size of item B) are determined randomly. In other words, the determination of the reward details is random. Specifically, the virtual space 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 obtainable item based on the random number. The detail determination seed includes ｈｆｉｒｓｔ and seed ｍｄｉｄ The virtual space management unit 231 then ｈｆｉｒｓｔ and seed ｍｄｉｄ The virtual space management unit 231 determines the details of the obtainable item using a function that has the outline of the obtainable item determined in the item outline determination process and the outline of the obtainable item specified as arguments. ｈｆｉｒｓｔ and seed ｍｄｉｄWhen determining the details of the items that can be acquired for a certain mountain, the virtual space management unit 231 uses the virtual space ID of the certain mountain as a seed ｍｄｉｄ When determining details of obtainable items for a certain mountain, the virtual space management unit 231 uses the outline of obtainable items determined for that mountain as an argument. ｈｆｉｒｓｔ (In other words, the hash of the blockchain), the virtual space ID of each mountain, and the summary of the obtainable items for each mountain determined in the item summary determination process are used to determine the details of the obtainable items.

[0109] In this way, in this embodiment, details of the gems that can be obtained through mining (e.g., type, quality, or some of the details such as detailed size) are not determined until the item detail determination process is executed.

[0110] The timeline for acquiring and mining the mountain will now be described with reference to Figure 8. Here, the last generated hash on May 29, 2022, which is hashlast_20220529, is the seed. ｈｌａｓｔ The first hash generated on May 31, 2022, hashfirst_20220531, is used as the seed. ｈｆｉｒｓｔ This will be explained using an example where it is used to generate maps and mountains, determine obtainable items, etc.

[0111] First, the virtual space 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 ｈｌａｓｔis determined when the first hash (in other words, the first block) is generated on May 30, 2022. Therefore, in this embodiment, the virtual space management unit 231 creates a map using hashlast_20220529 at the time the first hash is generated on May 30 (in other words, after the hash is generated).

[0112] The virtual space management unit 231 also performs an item summary determination process using the last hash of May 29, 2022, to determine a summary of the items that can be obtained for each mountain. The virtual space management unit 231 also performs a virtual space creation process using the last hash of May 29, 2022, to create mountains in which the items whose summaries have been determined in the item summary determination process are placed. In this embodiment, the virtual space management unit 231 determines a summary of the items that can be obtained for each mountain using hashlast_20220529 when the first hash of May 30 is generated (in other words, after the hash is generated). The virtual space management unit 231 also creates mountains using hashlast_20220529 when the first hash of May 30 is generated (in other words, after the hash is generated).

[0113] In addition, the virtual space management unit 231 controls to limit the period during which the mountain can be acquired. In this embodiment, the period during which the mountain 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). ｈｌａｓｔ is confirmed), the first hash is generated the next day (the seed for that hash) ｈｆｉｒｓｔ is determined). In other words, the virtual space management unit 231 controls the period during which a mountain created using hashlast_20220529 can be acquired so that it is the period until the details of the items that can be acquired from that mountain are determined. In other words, once a mountain (in other words, a map) is created, the created mountain can be acquired until the next mountain (in other words, a map) is created. Note that the period during which a mountain 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 mountain was created).

[0114] Furthermore, the virtual space management unit 231 performs an item detail determination process using the first hash of May 31, 2022, and determines details for items whose overviews were determined using the last hash of May 29, 2022. In this embodiment, the virtual space management unit 231 determines details of obtainable items using hashfirst_20220531 at the time the first hash of May 31 is generated (in other words, after the hash is generated). That is, the virtual space management unit 231 determines details of obtainable items for a mountain after the obtainable period for the mountain has elapsed. In other words, the virtual space management unit 231 exercises control so that a mountain cannot be obtained after details of obtainable items have been determined.

[0115] The mountain (in other words, the right to mine the mountain), in which the overview and details of the items that can be obtained are determined in this way, is acquired by the user based on the user's operations, and items can be obtained through mining.

[0116] When the user performs an operation to select a mountain to acquire, the virtual space management unit 231 grants the selected mountain to the user based on the operation. In other words, the virtual space management unit 231 grants the user the right to mine the mountain selected by the user (in other words, the right to play the game in the selected virtual space).

[0117] When receiving an operation to select a mountain to acquire, the display control unit 114 causes the display unit 18 to display detailed information 50 about the mountains that the user can acquire, as shown in FIG. 3 . For example, when the user selects a specific mountain on the map 40 that displays the mountains that the user can acquire, the display control unit 114 causes the display unit 18 to display detailed information 50 about the specific mountain. In this embodiment, information about gems that can be acquired from the specific mountain is displayed as the detailed information 50. In other words, a display about the expected reward for the specific mountain is displayed as the detailed information 50. Specifically, the device processing unit 113 receives information about an overview of the items that can be acquired from the specific mountain from the virtual space management unit 231, and, based on the information, causes the display unit 18 to display, for example, the number of gems that can be acquired by mining the mountain and an overview of the size of each gem. This allows the user to view the detailed information 50 and decide whether or not to acquire the specific mountain. That is, in this embodiment, before the user acquires the right to play a game in the virtual space, the virtual space management unit 231 can present the user with information regarding the rewards that can be obtained by playing the game (in other words, detailed information 50), and this information is displayed on the display unit 18. Note that in this embodiment, the number of gems that can be obtained in the mountain and an outline of the size of each gem are presented as detailed information 50, and it is ensured that the presented number of gems and gems of a size corresponding to the presented size can be obtained; however, the number and sizes of gems presented as detailed information 50 are merely a guide, and there may be cases where the number of gems presented as detailed information 50 or gems corresponding to the presented size (in other words, rewards as shown in detailed information 50) cannot be obtained.

[0118] Furthermore, the virtual space management unit 231 stores information indicating the mountains acquired by the user on a blockchain (e.g., the Ethereum blockchain). Specifically, when a user acquires a mountain, the virtual space management unit 231 stores information indicating that the user has acquired the mountain on the blockchain. That is, in this embodiment, a history of users' mountain acquisitions is stored on the blockchain. In other words, in this embodiment, information regarding rights to play games in a specific virtual space is stored on the blockchain. This configuration makes it possible to prevent the acquisition of mountains, items, etc. by fraudulent means. That is, in this embodiment, the right to acquire a specific item is acquired by acquiring a mountain that has a limited acquisition period, and information indicating the mountain 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 (specifically, a gem) by fraudulent means, it is possible to confirm that the user does not have acquisition information for a mountain that can acquire the item, making it possible to prove the user's fraud. In addition, in this embodiment, mountain acquisition information is stored on a blockchain that is difficult to rewrite, and the details of acquireable items are determined after the period during which the mountain can be acquired has elapsed, thereby more firmly preventing the fraudulent acquisition of items.

[0119] The game control unit 212 starts mining in the mountain that the user has acquired based on an operation by the user to instruct the user to start mining in the mountain. In the game of this embodiment, mining in the mountain is possible after the outline of the obtainable items has been determined and the mountain has been created, and it is also possible to start mining before the details of the obtainable items have been determined. It is also possible to start mining in the mountain after the details of the obtainable items have been determined.

[0120] The reward granting unit 233 grants items to the user based on the results of mining in the mountain. Specifically, in this embodiment, gems and pyroxenes discovered through mining are granted to the user.

[0121] Here, the timing at which the grant of an item based on mining in a mountain is determined can be either before or after the details of the item are determined. In other words, there may be cases where the details of the item have not yet been determined when the grant of the item is determined. Specifically, in this embodiment, a state may exist in which a gem is discovered through mining in a mountain (in other words, the grant of the gem is determined), but the details of the discovered gem have not yet been determined. In other words, in this embodiment, the details of the gem are determined after a predetermined period during which the mountain can be acquired (in other words, the period during which the right to play a game in a specific virtual space can be acquired) has elapsed. Furthermore, mining in the mountain is possible during the period during which the mountain can be acquired, and a situation may arise in which mining in the mountain is performed and gems are acquired during the period during which the mountain can be acquired. The user can view the gems they have acquired on a predetermined screen, such as a screen displaying a list of the user's items (e.g., a screen that can be opened after leaving the mountain). However, after the user acquires a gem, only an overview of the gem is displayed on the predetermined screen until the details of the gem are determined. Once the details have been decided, the details of the jewel can be confirmed on the specified screen.

[0122] In this embodiment, map creation, mountain creation (i.e., virtual space creation), determination of an overview of obtainable items for each mountain, and determination of details of obtainable items are performed every day, and the map and obtainable mountains are updated daily. That is, for example, in the example shown in FIG. 8 , the map creation process, item overview determination process, and virtual space creation process are performed using the last hash value on May 30th, and the item detail determination process for items whose overviews were determined in the item overview determination process is performed using the first hash value on June 1st. In this embodiment, the next map update and obtainable mountain update are performed after the mountain acquisition period ends, but the next map update and obtainable mountain update may also be performed during the mountain acquisition period. In other words, the hash value used to create the map, create the mountains, determine the overview of obtainable items for each mountain, or determine details of obtainable items does not have to be the last or first hash value of the day.

[0123] In this embodiment, the map and mountains are created and the overview of obtainable items is determined using the hash generated at the end of the day. 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 mountains are created and the overview of obtainable items is determined after the first hash of the next day is generated. Therefore, it is possible to create the map and mountains and determine the overview of obtainable items using the first hash of the next day. However, in this embodiment, the map and mountains are created and the overview of obtainable items is determined using the hash generated at the end of the day. This allows the map and mountains to be created and the overview of obtainable items to be determined based on different hashes, and the details of obtainable items to be determined based on different hashes. In other words, when processes related to the creation of the map and mountains and the determination of obtainable items are performed every day, the hash used to determine the details of the items whose overviews were determined the previous day is not the same as the hash used to determine the item overviews of the current day. In other words, in this embodiment, the game control unit 212 determines the details of an item using a specific hash within a recurring arbitrary period (specifically, the first hash of the day), and determines an overview of the item 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 mountains are created and an overview of obtainable items 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.

[0124] In the game of this embodiment, the lottery logic for jewels as item B is stored on the blockchain and made public. Specifically, the logic for the item summary determination process and the item detail determination process is made public as a smart contract.ｈｌａｓｔ The logic for determining the reward summary using the seed will be published as a smart contract. ｈｆｉｒｓｔ The logic for determining the details of the reward using the seed will be published as a smart contract. ｈｌａｓｔ and seed ｈｆｉｒｓｔis a blockchain hash and is a publicly available seed. In other words, in this embodiment, the overview of items obtainable at each mountain 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 item overview using the publicly available seed and the predetermined logic. In addition, in this embodiment, the details of items obtainable at each mountain 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 item 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 allocation of items and clearly presents this information to users. Furthermore, by using a blockchain hash 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 allocation of items cannot be controlled by even the operator, and users can verify the allocation 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 outline and details of an item 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 a specific object to appear. The logic of the virtual space creation process may also be stored on the blockchain and made public, or may not be stored on the blockchain and kept private.

[0125] The detailed mountain information 50 may be displayed not only when the user acquires a mountain, but also when the user selects a mountain to mine from the acquired mountains, when the user starts mining at a mountain, etc. For example, as shown in FIG. 5 , when a list 44 of the mountains acquired by the user is displayed on the display unit 18 and an operation to select a specific mountain is performed, the display control unit 114 causes the display unit 18 to display the detailed mountain information 50 about the specific mountain. For example, the detailed information 50 may display information about gems that can be acquired at the specific mountain (e.g., the number of gems and an outline of the size of each gem). In other words, the detailed information 50 may display an indication of the expected reward for the specific mountain. This allows the user to determine whether or not to mine at the specific mountain after viewing the detailed information 50. The detailed information 50 may also display the progress of mining. Specifically, detailed information 50 may display, for example, how many gems have been discovered, what percentage of the gem reserves have been discovered, how many pyroxenes have been discovered, what percentage of the pyroxene reserves have been discovered, or the degree of mining progress for the mountain (in other words, the degree of progress in the game for that mountain) calculated based on the amount of gems discovered, etc.

[0126] (Processes Requiring Payment of Virtual Currency) In this embodiment, there are processes (hereinafter referred to as "paid processes") that require payment of virtual currency (specifically, specific tokens) managed by the blockchain. Specifically, there are multiple types of paid processes, including a process related to purchasing a pickaxe (in other words, a process that allows a user to acquire a pickaxe), a process related to repairing a pickaxe (in other words, a process that restores the durability value of a pickaxe), and a process related to increasing the rank of a pickaxe (in other words, a process that increases the rank of a pickaxe).

[0127] The process for purchasing a pickaxe will be described. As described above, pickaxes can be purchased in the in-game marketplace. The purchase of a pickaxe is performed, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display a shop screen 60, as illustrated in FIG. 9 , based on a predetermined input operation by the user. The shop screen 60 displays a list of pickaxes available for purchase. The operation reception unit 111 also receives an operation to select a pickaxe to purchase from the list of pickaxes displayed (e.g., a click operation on a specific displayed pickaxe). When the pickaxe to purchase is selected, the display control unit 114 also displays a dialog box (not shown) on the display unit 18 to confirm whether to purchase the selected pickaxe. The dialog box includes an execute button for receiving an operation to execute the purchase and a cancel button for receiving an operation to cancel the purchase. When the execute button is operated, the control unit 110 of the terminal device requests the server 20 to purchase the selected pickaxe. Based on the request, the market management unit 214 of the server 20 executes a process of granting the selected ice axe to the user and having the user pay the purchase price (in other words, a process of reducing the specific tokens held by the user by the amount of the purchase price). That is, based on the user's operation related to the execution of a paid transaction, the control unit 210 executes a process of having the user acquire the ice axe as a paid transaction. Note that when a specific ice axe is displayed as a purchasable ice axe on a user's terminal device 10, this is also referred to as the specific ice axe being lined up in the user's shop.

[0128] Next, a process related to ice axe repair and a process related to increasing the rank of an ice axe will be described. Ice axe repair and a rank increase are performed, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display an item screen 64 illustrated in FIG. 10 based on a predetermined input operation by the user. The item screen 64 displays a list of items owned by the user (in other words, usable items). Specifically, the item screen 64 displays a list of ice axes owned by the user (in other words, usable ice axes). The operation receiving unit 111 also receives an operation to select a specific ice axe from the ice axes displayed on the item screen 64 (for example, a click operation on the specific ice axe). When a specific ice axe is selected, the display control unit 114 also causes the display unit 18 to display a UI that receives various operations for the selected ice axe. Specifically, the display control unit 114 displays, as the UI, a repair button 65 that accepts an operation related to restoring the durability of the pickaxe, an upgrade button 66 that accepts an operation related to increasing the rank of the pickaxe, and a sell button 67 that accepts an operation related to selling the pickaxe on the display unit 18. Note that the item screen 64 may also display an indication of the remaining durability of the selected pickaxe or the pickaxes displayed in a list. In the example shown in FIG. 10 , a meter 68 indicating the remaining durability is displayed as an indication of the remaining durability, but the indication of the remaining durability may also be a numerical value or the like.

[0129] When the repair button 65 is operated, the control unit 110 of the terminal device 10 requests the server 20 to restore the durability of the selected pickaxe. Based on the request, the game control unit 212 of the server 20 restores the durability of the selected pickaxe and executes a process of having the user pay the price for the durability restoration (in other words, a process of reducing the specific tokens held by the user by the price for the durability restoration). In other words, the control unit 210 executes a process of restoring the durability of the pickaxe as a paid process based on the user's operation related to the execution of a paid process.

[0130] Furthermore, when the upgrade button 66 is operated, the control unit 110 of the terminal device requests the server 20 to increase the rank of the selected ice axe. Based on this request, the game control unit 212 of the server 20 increases the rank of the selected ice axe and executes processing to have the user pay the price for the increase in rank (in other words, processing to reduce the specific tokens held by the user by the price for the increase in rank). In other words, the control unit 210 executes processing to increase the rank of the ice axe as a paid process, based on the user's operation related to the execution of a paid process.

[0131] Furthermore, when the sell button 67 is operated, the control unit 110 of the terminal device requests the server 20 to put the selected ice axe up for sale on the marketplace. Based on this request, the market management unit 214 of the server 20 puts the ice axe selected by the user up for sale, allowing other users who wish to purchase the ice axe to purchase it from the user (for example, by paying specific tokens). In other words, the put up ice axe will be displayed on the shop screens 60 of other users.

[0132] In this embodiment, the pickaxes offered for sale on the marketplace include those sold by the game operator and those sold by other users. That is, a user can purchase a pickaxe from the game operator or from another user. When purchasing a pickaxe from the game operator, the purchase price is transferred to the game operator. When purchasing a pickaxe from another user, the purchase price is transferred to the other user. The price for restoring the pickaxe's durability is transferred to the game operator. The price for increasing the pickaxe's rank is transferred to the game operator.

[0133] Furthermore, in this embodiment, it is possible to repair a pickaxe even while mining is in progress. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display a menu screen 70 illustrated in FIG. 11 based on a predetermined input operation by the user (e.g., an operation on the Tab key on the keyboard) while mining is in progress. The menu screen 70 displays a pickaxe operation button 72 related to receiving operations for the pickaxe owned by the user (in other words, the pickaxe being used). When the pickaxe operation button 72 is operated, the display control unit 114 causes the display unit 18 to display a UI that receives various operations for the pickaxe owned by the user. Specifically, the display control unit 114 causes the display unit 18 to display, as the UI, a repair button 73 that receives operations related to restoring the durability value of the pickaxe and a switch button 74 that receives operations related to changing (in other words, switching) the pickaxe being used.

[0134] When the repair button 73 is operated, the control unit 110 of the terminal device requests the server 20 to restore the durability of the pickaxe owned by the user (for example, the pickaxe currently in use). Based on the request, the game control unit 212 of the server 20 executes a process to restore the durability of the pickaxe owned by the user and to have the user pay a fee for the durability restoration (in other words, a process to reduce the specific tokens held by the user by the fee for the durability restoration). In other words, the control unit 210 executes a process to restore the durability of the pickaxe owned by the user based on a predetermined operation by the user while mining is in progress.

[0135] Furthermore, when the switch button 74 is operated, the display control unit 114 displays a list 75 of switchable ice axes on the display unit 18. Then, when an operation is performed to select a specific ice axis from among the ice axes displayed in the list 75 of switchable ice axes (for example, by clicking on a specific ice axis), the control unit 110 of the terminal device 10 requests the server 20 to change the ice axis used by the user to the specific ice axis. Based on this request, the game control unit 212 of the server 20 executes processing to change the ice axis used by the user to the specific ice axis.

[0136] The menu screen 70 may display the user name, the user's current rank, etc. The menu screen 70 may also display how many gems have been discovered in the mountain currently being mined, what percentage of the gem reserves the discovered gems have been, how many pyroxenes have been discovered, what percentage of the pyroxene reserves the discovered gems have been, or the progress of mining in the mountain calculated based on the amount of gems discovered, etc.

[0137] (Lending an Ice Axe) In this embodiment, item A owned by a user can be lent to another user. In the following, a user who owns an ice axe as item A and lends the ice axe to another user will be referred to as an "owner." Furthermore, a user who borrows an ice axe from another user will be referred to as a "scalar."

[0138] Scalars can mine in the mountains using a pickaxe loaned by the owner. In other words, users who do not own a pickaxe can borrow one from a user who owns one and play the game (specifically, mine).

[0139] The operations related to starting mining in a mountain and the operations for operating the player character to perform mining in a mountain may be the same for both the owner and the scholar. That is, for example, a scholar can start mining in a mountain based on an operation on the start mining button 43 on the home screen 42 displayed on his / her own terminal device 10. Here, in this embodiment, the mountain in which the scholar performs mining using a pickaxe loaned by the owner is a mountain owned by the owner. When loaning the pickaxe, the owner specifies the mountain in which the scholar will perform mining using the pickaxe. Then, when the scholar performs mining using the pickaxe loaned by the owner, the scholar will perform mining in the mountain specified by the owner.

[0140] Furthermore, a scholar can earn rewards by mining using a pickaxe borrowed from the owner. In this embodiment, by digging up items using the pickaxe, the scholar can earn a reward that is a portion of the excavated items that is set as the scholar's share. Specifically, when the player character operated by the scholar excavates pyroxene, the reward granting unit 233 grants the scholar an amount of pyroxene corresponding to a set percentage of the excavated pyroxene as a reward. As will be described in detail later, this percentage is set by the owner. For example, if the percentage is set to 30%, when the player character operated by the scholar excavates pyroxene, the reward granting unit 233 grants 70% of the excavated pyroxene to the owner and 30% to the scholar. At this time, an effect may be performed in which the owner acquires all of the excavated pyroxene at once on the scholar's terminal device 10 or the owner's terminal device 10, and the owner distributes the pyroxene to the scholar.

[0141] In this embodiment, the owner can set the scalar's share, but it may be determined independently of the owner's setting. Furthermore, in this embodiment, all gems among the items excavated by the scalar are acquired by the owner and are not distributed to the scalar. That is, the reward granting unit 233 allows the owner to acquire all first objects (e.g., gems) obtained by the scalar using the loaned specific object (e.g., pickaxe) in the virtual space (e.g., a mountain owned by the owner), and allows the owner to acquire a portion of second objects (e.g., pyroxene) obtained by the scalar using the loaned specific object in the virtual space.

[0142] In this embodiment, multiple scalars may be assigned to one owner. In such cases, when a player character controlled by one of the multiple scalars digs up pyroxene, each scalar is awarded a reward of an amount of pyroxene corresponding to their mining work (in other words, their gameplay). In this embodiment, the reward awarded to each scalar is determined based on the following rules: When a scalar digs up pyroxene, the owner's share of the excavated pyroxene and the scalar's share are determined according to the ratio set by the owner. The scalar's share is shared among all scalars. Each scalar is awarded an amount of pyroxene corresponding to their own workload (specifically, the percentage of the mountain they excavated) from their share. The workload of each scalar is calculated by dividing the "durability of the pickaxe consumed by the player / durability of the pickaxes consumed by all scalars" during a specified period. - The scalar who digs up the gemstone will be given a certain amount of bonus (specifically, a 5% bonus) from his / her share.

[0143] Here, the predetermined period for calculating the workload of each scalar is the period from the last time a pyroxene was discovered in the mountain until the pyroxene to be distributed is acquired. Also, if the pyroxene to be distributed is the first pyroxene discovered in the mountain, it is the period from when mining in the mountain becomes possible until the pyroxene to be distributed is acquired. However, the predetermined period is not limited to this and can be set as appropriate.

[0144] Then, when any scalar digs up a pyroxene, the reward granting unit 233 determines the reward to be granted to the scalar who dug up the pyroxene and to each of the scalars other than the scalar who dug up the pyroxene according to the following formula, and grants the reward to each scalar. Reward for scalar who dug up a pyroxene = (diamond dug up) x (percentage of reward set by owner) x (coefficient for bonus payment) x (durability of pickaxe consumed by the scalar / durability of pickaxe consumed by all scalars) + (diamond dug up) x (percentage set by owner) x (coefficient for bonus received) Reward for scalars other than the scalar who dug up a pyroxene = (diamond dug up) x (percentage of reward set by owner) x (coefficient for bonus payment) x (durability of pickaxe consumed by the scalar / durability of pickaxe consumed by all scalars)

[0145] For example, suppose there are two scalars, Scalar A and Scalar B, and Scalar A digs up 100g of pyroxene. The owner sets the reward rate to 30% (in other words, the owner's share is set to 70%). Scalar A consumes 40 points of durability on the pickaxe loaned to him by the owner, and Scalar B consumes 60 points of durability on the pickaxe loaned to him by the owner. In this case, Scalar A receives 100g x 0.3 x 0.95 x (40 / (40 + 60)) + 100g x 0.3 x 0.05 = 12.9g of pyroxene as a reward. Scalar B receives 100g x 0.3 x 0.95 x (60 / (40 + 60)) = 17.1g of pyroxene as a reward. Additionally, the owner will be given 100g x 0.7 = 70g of pyroxene as his / her share.

[0146] Furthermore, as described above, the pyroxene owned by each user may be periodically converted into specific tokens. That is, the flow until a scalar acquires a specific token may be as follows: First, when one of multiple scalars who has been loaned a pickaxe by one owner digs up a pyroxene, the pyroxene is distributed to the owner and the multiple scalars. Note that in this embodiment, the pyroxene is granted to the owner and the multiple scalars at the time of digging (in other words, immediately), but it may also be granted at a predetermined time, such as at the end of an event. All pyroxene owned by each user is set to be automatically converted into specific tokens at a specific time every day, and through this conversion, each scalar (and the owner) obtains a specific token. In other words, at that specific time, neither the owner nor the multiple scalars (in other words, for example, all users playing the game of this embodiment) owns any pyroxene.

[0147] In this embodiment, the owner can lend a pickaxe to a scholar to find gems and pyroxenes on his or her behalf. In other words, lending a pickaxe in this embodiment can be interpreted as recruiting a scholar to help with the discovery of gems and pyroxenes. In other words, the owner can recruit a scholar to help with an event aimed at achieving a predetermined goal (e.g., discovering gems and pyroxenes), and the collaborator participates in the event using an object (e.g., a pickaxe) loaned from the owner. Note that an event in which a collaborator participates using an object loaned from the owner may involve defeating a predetermined opponent (here, "opponent" may refer to another user or an NPC. Also, an opponent may include an enemy character in a so-called quest), reaching a predetermined destination, or obtaining a predetermined object. Furthermore, an event in which a collaborator participates using an object loaned from the owner may be an event that can be progressed through multiplayer between the owner and the collaborator, or an event that can be progressed through multiplayer between multiple collaborators who have been loaned objects from a single owner. Furthermore, an event in which a collaborator participates using an object loaned from the owner may be an event that can be progressed by the collaborator alone.

[0148] Furthermore, in this embodiment, when one of multiple scalars loaned a pickaxe from a single owner achieves a predetermined result, the reward granting unit 233 determines the reward to be granted to each scalar according to the amount of work each scalar does, and grants the reward to each user. In this regard, in a game such as this embodiment, for example, between scalar A and scalar B loaned a pickaxe from the owner, a situation may arise in which scalar A, who has done a lot of work, is not achieving a result (specifically, a situation in which scalar A has not found a pyroxene despite digging a lot), while scalar B, who has done less work, is fortunate to achieve a result (specifically, a situation in which scalar B has found a pyroxene despite digging a little). In such a case, depending on how the reward is granted, users such as scalar A may feel a sense of unfairness. According to the configuration of this embodiment, a larger reward is distributed to users who have done a lot of work, which reduces the likelihood of users feeling a sense of unfairness and motivates them to actively play the game. In addition, in such a case, it is possible that Scalar B was able to discover the gemstone because Scalar A had done a lot of work, and according to the configuration of this embodiment, it is possible to reward the play of a user such as Scalar A.

[0149] As described above, each user's reward is determined based on the amount of work each user has done until one of the users achieves a predetermined result (specifically, until they discover a pyroxene). Then, when one of the users achieves a predetermined result again, the reward for each user is determined based on the amount of work each user has done since the last time the user achieved the predetermined result until the next time the user achieves the predetermined result. That is, in this embodiment, when one of the users achieves a predetermined result, the amount of work each user has done in relation to the calculation of the reward is reset, and the starting point for calculating the amount of work is changed to the time when the predetermined result was achieved. However, the amount of work does not have to be reset when one of the users achieves a predetermined result. For example, regardless of whether one of the users has achieved a predetermined result along the way, each user may be awarded a reward based on the cumulative amount of work each user has done since they started mining (in other words, since mining in the mine became possible) until the reward award trigger occurs.

[0150] As described above, in this embodiment, when one of multiple users who participate in a specified event and use a specific object that has been converted into an NFT achieves a specified result by using the specific object in the virtual space, the reward granting unit 233 determines the reward to be granted to each user according to the amount of work each of the multiple users does, and grants the reward to each user.However, the specified event does not have to be an event in which participants participate using an object loaned from the owner, and the specific object does not have to be an object loaned from the owner.

[0151] Furthermore, in this embodiment, the workload of each user is determined based on the consumption of the durability of the pickaxe (in other words, the amount of the mountain dug), but the workload may be determined in a manner appropriate to the type of game. For example, in an event in which enemy characters appear, the workload may be determined based on the number of enemy characters defeated or the total amount of damage inflicted on the enemy characters. Furthermore, points are assigned for various actions that the player character can perform during the event, and the workload may be determined based on the cumulative points of actions actually performed during the event. The workload may also be determined based on parameters indicating, for example, how much each user played, how many effective actions they performed during the event, or how much they contributed to the results (in other words, in the event).

[0152] In this embodiment, the reward given to the scalar varies depending on the results achieved by the scalar, but it is also possible to give a fixed reward regardless of the results.

[0153] Next, the lending of ice axes will be explained in detail with reference to various displays related to the lending of ice axes.

[0154] The display control unit 114 of the terminal device 10 displays a loan-related screen 400, illustrated in FIG. 12 , on the display unit 18 based on a predetermined input operation by the user. The loan-related screen 400 displays a scholarship recruitment button 401, which accepts operations related to scholarship recruitment (in other words, lending an ice axe), and an owner search button 402, which accepts operations related to applying as a scholarship (in other words, searching for an owner, or further in other words, borrowing an ice axe). Furthermore, based on an operation on the scholarship recruitment button 401, the display control unit 114 displays a recruitment screen 420, illustrated in FIG. 13 , on the display unit 18. Furthermore, based on an operation on the owner search button 402, the display control unit 114 displays an application screen 440, illustrated in FIG. 14 , on the display unit 18.

[0155] The recruitment screen 420 is a screen for performing operations related to recruiting scholars. In other words, the recruitment screen 420 is a screen for performing operations related to lending the user's own ice axe. Specifically, the recruitment screen 420 allows settings for the case (in other words, the event) for which a scholar is being recruited. That is, in this embodiment, it is possible to recruit a scholar for one case (in other words, the event), namely, mining in a specific mountain, and the recruitment screen 420 allows settings to be made for the case for which a scholar is being recruited, such as the reward to be given to the scholar and the ice axe to be loaned to the scholar.

[0156] The recruitment screen 420 displays a mountain selection UI 421, a reward setting UI 422, a message input UI 423, a loan object selection UI 424, and a recruitment start button 425 as a UI for starting scholarship recruitment.

[0157] The mountain selection UI 421 is a UI that accepts operations related to the selection of a mountain for which a scalar is to be recruited (in other words, a mountain for which a scalar will be mined). In other words, the mountain selection UI 421 is a UI that accepts operations related to the selection of a project for which a scalar is to be recruited (in other words, an event). In this embodiment, when the mountain selection UI 421 is clicked, it switches to a state that displays a list 430 of mountains owned by the user. At this time, it may switch to a state that displays a screen similar to the screen illustrated in FIG. 5 . Then, by selecting a specific mountain from the displayed list of mountains, it is possible to select a mountain for which a scalar is to be recruited. Note that by selecting a specific mountain from the displayed list of mountains, detailed information 50 about the specific mountain may be displayed, and the user may confirm the detailed information 50 and then decide on a mountain for which a scalar is to be recruited. The operation reception unit 111 receives user operations on the mountain selection UI 421 (for example, a click operation on the mountain selection UI 421 and a click operation on a specific mountain from the list of mountains displayed based on the click operation) as an operation to select a mountain from among the mountains owned by the user that is eligible for scholarship recruitment.

[0158] The reward setting UI 422 is a UI that accepts operations related to setting a reward for results obtained by using the loaned pickaxe (in other words, a reward to the scalar for cooperation with the owner). In other words, the reward setting UI 422 is a UI that accepts operations to set conditions related to the loan of the pickaxe (specifically, conditions related to the reward). In this embodiment, the scalar's share of the results obtained by the scalar using the loaned pickaxe (in other words, the owner's share) is set as the reward for the results. More specifically, in this embodiment, when the scalar uses the pickaxe to dig up pyroxene, the excavated pyroxene is divided between the owner and the scalar, and the distribution of the excavated pyroxene between the owner and the scalar is set as the reward for the results.

[0159] The reward setting UI 422 accepts an operation to set the percentage of the pyroxene dug up by the scalar that will be awarded to the scalar. For example, if a percentage of "30%" is set in the reward setting UI 422, 70% of the pyroxene dug up by the scalar will go to the owner, and 30% will go to the scalar. The reward setting UI 422 may be an input field that allows a numerical value such as "30%" to be entered by operating the keyboard, or may be a pull-down menu that displays multiple selectable percentage options and allows a specific percentage to be selected from the multiple options. The operation receiving unit 111 accepts a user's operation on the reward setting UI 422 as an operation to set a reward for another user for results achieved by that other user using the pickaxe loaned by the user. In other words, the operation receiving unit 111 receives a user's operation on the reward setting UI 422 as an operation to set the scalar share (in other words, the owner's share) for a specified object obtained based on another user using a pickaxe loaned by the user.

[0160] In this embodiment, the owner can set the scalar's share of the results achieved by the scalar between "0%" and "100%." ​​If it is set to "0%, the owner will acquire all of the pyroxene dug up by the scalar. If it is set to "100%, the scalar will acquire all of the pyroxene dug up by the scalar.

[0161] The reward setting UI 422 may accept an operation to set the type of item (e.g., whether to grant a gem or a gemstone to the scalar) to the scalar as a reward for the scalar's achievements (in other words, the scalar's share). The reward granted to the scalar does not have to be an item discovered by the scalar; for example, a predetermined reward (e.g., a specific amount of tokens according to the achievements) may be granted from the owner's assets according to the achievements of the scalar.

[0162] The message input UI 423 is a UI that accepts operations related to inputting messages to be sent to scalars. In this embodiment, the message input UI 423 accepts an operation to input, as a message, the type of user to be recruited as a scalar. Specifically, the message input UI 423 may be able to select text information to be set as a message from multiple text information such as "Beginners Welcome," "Casual Miners Welcome," "Serious Miners Only," "Experienced Miners Wanted," "Emphasis on Teamwork," and "Profit Sharing Available." Note that the message input UI 423 may display multiple selectable message candidates and provide a pull-down menu from which a specific message can be selected. Alternatively, the message input UI 423 may provide an input field in which the user can enter any character string (i.e., a free comment) by operating the keyboard. The operation receiving unit 111 accepts a user's operation on the message input UI 423 as an operation to input (i.e., set) a message to be sent to a user who will borrow a pickaxe from the user.

[0163] In this embodiment, the message entered in the message input UI 423 is merely a comment, and even users who do not meet the requirements described in the message can apply to be a scholar and borrow an ice axe. That is, for example, even if "Experienced People Wanted" is selected as the message, regardless of whether they are beginners or experienced, they can apply to be a scholar and borrow an ice axe. However, restrictions may be placed on users who do not meet the requirements described in the message so that they cannot apply to be a scholar and borrow an ice axe. Specifically, the control unit 110 or the control unit 210 may perform processing to restrict users who do not meet the requirements described in the message from borrowing an ice axe.

[0164] The loan object selection UI 424 is a UI that accepts operations related to the selection of ice axes to be loaned to a scholar. In this embodiment, a maximum of six scholars can be recruited for each mountain owned by the user (i.e., each mountain selected in the mountain selection UI 421). In other words, a maximum of six scholars can be recruited for one job. Furthermore, a different ice axe must be loaned to each recruited scholar. That is, the loan object selection UI 424 allows the selection of up to six ice axes to be loaned to a scholar. In this embodiment, the loan object selection UI 424 has six slots 426. When an operation (e.g., a click operation) is performed on each slot 426, the UI switches to a state displaying a list 432 of ice axes owned by the user. Then, an operation (e.g., a click operation on a specific ice axe) to select a specific ice axe from the listed ice axes sets the specific ice axe to the selected slot 426. The ice axe set in each slot 426 is then loaned to the scholar. Note that by performing an operation to select a specific ice axe from the list of ice axes displayed, detailed information (e.g., performance, etc.) about the specific ice axe may be displayed, and the user may decide on the ice axe to loan to the scholar after checking the detailed information. The operation receiving unit 111 receives a user operation on the loan object selection UI 424 (e.g., a click operation on a slot 426 and a click operation on a specific ice axe from the list of ice axes displayed based on the click operation) as an operation to select a ice axe to loan to the scholar from the ice axes owned by the user.

[0165] When the start recruitment button 425 is operated, recruitment of a scholar begins according to each item entered on the recruitment screen 420. Specifically, when the start recruitment button 425 is operated, recruitment begins for a user (in other words, a scholar) who will borrow the pickaxe selected in the lending object selection UI 424 to mine in the mountain selected in the mountain selection UI 421. In other words, based on the user's operation of the start recruitment button 425, lending of the pickaxe owned by the user begins. Furthermore, a user who applies for the recruitment will borrow the pickaxe under the conditions for reward set in the reward setting UI 422, and can earn a reward according to the conditions set in the reward setting UI 422 as a reward for results obtained by mining using the loaned pickaxe.

[0166] When the start recruitment button 425 is operated, the control unit 110 of the owner's terminal device 10 transmits to the server 20 information regarding the mountain selected in the mountain selection UI 421, the scalar share set in the reward setting UI 422, the message input in the message input UI 423, and the pickaxe selected in the lending object selection UI 424, and requests the server 20 to start recruiting scholars. The control unit 210 of the server 20 then begins recruiting scholars based on the information transmitted from the terminal device 10. Specifically, the control unit 210 begins recruiting scholars to mine by borrowing the pickaxe selected in the lending object selection UI 424 under the conditions set in the reward setting UI 422 for the job of mining in the mountain selected in the mountain selection UI 421.

[0167] Note that "start recruitment" means that information related to the recruitment run by the user as the owner is made available to be displayed on the terminal devices 10 of other users (specifically, the application screen 440 described below). In other words, it means that other users are made available to apply for the recruitment run by the user as the owner. When the owner inputs various information on the recruitment screen 420 and operates the start recruitment button 425, the control unit 210 of the server registers the recruitment corresponding to the various input information as a recruitment that can be displayed on the application screen 440 of other users.

[0168] In this embodiment, the scholar uses the loaned ice axe on the mountain selected in the mountain selection UI 421, and the mountain selection UI 421 can also be considered a UI that accepts an operation to specify a location where the loaned ice axe is permitted to be used. In other words, the mountain selection UI 421 can also be considered a UI that accepts an operation to set conditions related to the loan of the ice axe (specifically, conditions regarding the location of use). When the scholar mines using the loaned ice axe, the game control unit 212 controls the mining location so that the mountain selected in the mountain selection UI 421 is the location where the mining will be performed. In other words, the game control unit 212 determines the location where the scholar can use the loaned ice axe based on the owner's operation on the mountain selection UI 421.

[0169] In this embodiment, the loaned pickaxe can be used in a location designated by the owner as a location where the use of the pickaxe is permitted (in other words, an event set by the owner in the mountain selection UI 421), but the loaned pickaxe may be usable without restrictions on location, event, etc. In other words, for example, the mountain selection UI 421 may not exist on the recruitment screen 420, and the scholar may be able to mine by selecting a mountain on which to use the loaned pickaxe.

[0170] The application screen 440 is a screen for performing operations related to applications for recruitments posted by owners. In this embodiment, a user who owns an ice axe and a mountain can recruit scholars as an owner, and the application screen 440 can present multiple recruitments posted by multiple owners. As shown in FIG. 14 , the application screen 440 displays owner information 441, mountain information 442, reward information 443, loan object information 444, and additional information 445 for each project. Note that, by performing a predetermined operation (e.g., scrolling the screen in a predetermined direction) on the application screen 440, information about each project for which scholars are being recruited is displayed sequentially.

[0171] The owner information 441 is information about the owner who is recruiting. In this embodiment, the owner's username is displayed as the owner information 441. The owner's user ID, etc., may also be displayed as the owner information. That is, the application screen 440 displays, for each job, information indicating the user who entered various information on the recruitment screen 420 and started recruitment by operating the start recruitment button 425.

[0172] The mountain information 442 is information about the mountain that the scholar will mine if he or she applies for the recruitment. In other words, the mountain information 442 is information about the mountain that the owner selected using the mountain selection UI 421. In this embodiment, the mountain information 442 displays information 442a indicating the mountain where mining will be performed and information 442b about objects (e.g., gems) that can be obtained on that mountain. Specifically, the information 442a indicating the mountain where mining will be performed displays the name of the mountain and a virtual space ID that identifies each mountain. The information 442a indicating the mountain where mining will be performed can also be considered information indicating the event that the scholar will play using the loaned pickaxe. Furthermore, the information 442b about the obtainable object displays the expected probability of obtaining gems on that mountain. Note that the information 442b about the obtainable object may also display the expected probability of obtaining pyroxene on that mountain. In other words, the information 442b about the obtainable object can function as reward information 443.

[0173] The reward information 443 is information regarding the reward related to the achievements of the scalar (in other words, the reward for cooperation with the owner). In other words, the reward information 443 is information regarding the reward set by the owner in the reward setting UI 422. In this embodiment, the reward information 443 displays the scalar's share set in the reward setting UI 422 (specifically, the proportion of the pyroxene dug up by the scalar that will be given to the scalar).

[0174] The loan object information 444 is information about the ice axe as an object loaned to the scholar. In other words, the loan object information 444 is information about the ice axe selected by the owner in the loan object selection UI 424. In this embodiment, the loan object information 444 displays, for each ice axe selected in the loan object selection UI 424, an image of the ice axe, the name of the ice axe, an ID that makes each ice axe identifiable (in other words, identification information), and information related to the durability of the ice axe (for example, an indication of the remaining durability).

[0175] The additional information 445 is additional information about the case. In this embodiment, the additional information 445 displays the message input by the owner in the message input UI 423.

[0176] Each image of an ice axe in the lending object information 444 functions as a UI (in other words, a button) that accepts an operation to borrow the corresponding ice axe. That is, the operation receiving unit 111 accepts an operation to select a specific ice axe to borrow from among the multiple ice axes (specifically, ice axe images) displayed on the application screen 440 (e.g., a click on the image of a specific ice axe). In this embodiment, if an owner selects multiple ice axes to lend and is recruiting scholars, a user who applies for the recruitment can select which of the multiple ice axes to borrow to become a scholar. Furthermore, when a user selects a ice axe to borrow, the display control unit 114 displays a dialog box 448 on the display unit 18 to confirm whether to borrow the selected ice axe. The dialog box 448 includes an execute button that accepts an operation to borrow the ice axe and a cancel button that accepts an operation to cancel the borrowing. When the execute button is operated, the control unit 110 of the terminal device requests the server 20 to borrow the selected pickaxe. Based on the request, the control unit 210 of the server 20 executes a process to loan the selected pickaxe from the owner to the user who selected the pickaxe. Specifically, the control unit 210 stores information indicating that the pickaxe is being loaned from the owner to the user as a scalar (hereinafter referred to as "loan information") in the storage unit 220. Note that the loan of the pickaxe from the owner to the scalar can also be considered the conclusion of a contract or the establishment of a cooperative relationship between the owner and the scalar. If the loan information is stored, the game control unit 212 restricts the owner from using the loaned pickaxe. Specifically, the game control unit 212 prevents the owner from mining using the loaned pickaxe. In addition, the process of restricting the use of a loaned ice pick may be, for example, a process of making it impossible to select the loaned ice pick as the ice pick to be used for mining, or a process of not accepting operation of the start mining button 43 when the loaned ice pick has been selected as the ice pick to be used for mining.

[0177] Furthermore, if the loan information is stored, the game control unit 212 causes the scholar to start mining using the loaned pickaxe based on a predetermined operation by the scholar. For example, the game control unit 212 causes the scholar to start mining using the loaned pickaxe based on the scholar operating the start mining button 43 on the home screen 42 displayed on the scholar's own terminal device 10. At this time, the game control unit 212 causes the scholar to start mining at a mountain selected by the owner who loaned the pickaxe in the mountain selection UI 421. In other words, the game control unit 212 places the scholar's player character on the mountain specified by the owner and moves the player character based on the input operation by the scholar. The scholar can perform mining by moving the player character in the virtual space and swinging the loaned pickaxe in the same way as when the owner performs mining.

[0178] On the application screen 440, among the ice axes selected by the owner as the ice axes to lend, those that have already been borrowed by another user will have a borrowed icon 449 indicating that the ice axes are borrowed by another user. Ice axes that have the borrowed icon 449 displayed cannot be borrowed. In other words, one ice axis cannot be lent to multiple users at the same time.

[0179] In this embodiment, a scholar can borrow a pickaxe from an owner in advance and start or stop mining at any time. That is, a scholar who has borrowed a specific pickaxe on the application screen 440 can select the specific pickaxe and operate the start mining button 43 at any time to start mining using the specific pickaxe in a specific mountain. Furthermore, a scholar who has borrowed the specific pickaxe can end mining by performing an operation related to leaving the specific mountain (e.g., operating the exit button 71), or can resume mining using the specific pickaxe in the specific mountain by operating the start mining button 43 again. Note that, for example, the pickaxe may be configured to be loaned only during the period in which mining is being performed. Specifically, for example, when a user who does not own a pickaxe operates the start mining button 43, a screen displaying the pickaxes that the owner is lending out (for example, the application screen 440) may be displayed on the user's terminal device 10, and mining may begin by selecting the pickaxe to borrow. Then, when mining is finished (in other words, interrupted), the pickaxe may be automatically returned to the owner.

[0180] As described above, in this embodiment, an owner can recruit up to six scholars for each mountain he or she owns and lend the six scholars a pickaxe. Scholars can also start mining using the pickaxe they have been loaned at any time. Therefore, if an owner loans a pickaxe to multiple scholars, the multiple scholars may simultaneously mine on the same mountain. For example, if user A, who serves as the owner, loans a pickaxe to users B and C, users B and C can simultaneously mine on a specific mountain by operating the mining start button 43. If one of users B and C starts mining while the other is already mining, the game control unit 212 provides a multiplayer game in which users B and C play together. The game control unit 212 places user B's player character and user C's player character on the specific mountain and moves each player character based on the operations of each user. That is, on the terminal device 10 of user B and the terminal device 10 of user C, in addition to displaying how each user's own player character moves and digs into the mountain in response to the user's own operation, the game control unit 212 also displays how the player characters of the other users move and dig into the mountain in response to the operations of the other users. Furthermore, the game control unit 212 imparts a predetermined change to the specific mountain (e.g., a change such as the mountain being eroded by mining) based on the operation of user B, and also imparts a predetermined change to the specific mountain (e.g., a change such as the mountain being eroded by mining) based on the operation of user C. That is, for example, user B and user C can play the game while cooperating or competing with each other, such as by digging together at a location in the specific mountain that is likely to contain gems or pyroxene.

[0181] Furthermore, if user B and user C have been loaned a pickaxe by user A as the owner, user A can also start mining in a specific mountain by operating the mining start button 43. That is, for example, the game control unit 212 provides a multiplayer game in which user A plays together with user B and user C. That is, the game control unit 212 places the player character of user A and the player characters of user B and user C on the specific mountain, and moves each player character based on the operation of each user.

[0182] In this manner, in this embodiment, the game control unit 212 controls the execution of a multiplayer game in which multiple scholars participate. The game control unit 212 also controls the execution of a multiplayer game in which the owner and scholars participate. In other words, in this embodiment, an event in which the owner recruits scholars is an event that can proceed through multiplayer.

[0183] When recruiting scholarships, the owner may be able to limit the users to be recruited. For example, the recruitment screen 420 may display a UI that accepts an operation related to limiting the users to be recruited, and the users to be recruited may be limited based on an operation on the UI. In other words, the operation receiving unit 111 may accept an operation by the owner to limit the users to be recruited to specified users (hereinafter referred to as a "target limiting operation"). Specifically, the target limiting operation may accept an operation to limit the targets of recruitment to users who have a specified friendship relationship with the owner, such as the owner's friends, stored in the storage unit 220. Furthermore, the target limiting operation may accept an operation to limit the targets of recruitment to only users specified by the owner (for example, specified by user-identifiable information such as a user ID or a username). When the users eligible for the recruitment are limited, information related to the recruitment is displayed on the application screen 440 on the terminal device 10 of the eligible users, allowing them to apply, whereas information related to the recruitment is not displayed on the application screen 440 on the terminal device 10 of non-eligible users, making it impossible for them to apply.

[0184] In this embodiment, the maximum number of people who can participate in a multiplayer game is limited to six. If the owner recruits six scholars for mining on a specific mountain (in other words, a specific event) and lends pickaxes to the six scholars, the owner is prevented from mining on that specific mountain. That is, the game control unit 212 restricts the owner's use of the pickaxe on that specific mountain based on the fact that the owner has lent the pickaxe to a specified number of users (six in this case) for use on that specific mountain. Specifically, if the owner has lent the pickaxe to a specified number of users (six in this case) for use on that specific mountain, the game control unit 212 controls the owner so that the owner cannot perform mining on that specific mountain. Here, "restricting use based on whether the ice axe has been loaned to a specified number of users" may mean, for example, restricting use when the specified number of users are using the loaned ice axe (in other words, when the user is actually mining), restricting use regardless of whether the specified number of users are using the loaned ice axe, or restricting use regardless of whether the specified number of users have actually borrowed the ice axe (in other words, restricting use from the point at which applications are initiated by selecting the specified number of ice axes in the loan object selection UI 424). Note that in this embodiment, when an operation to select a sixth ice axe is performed in the loan object selection UI 424 (e.g., an operation on an empty slot 426 when five slots 426 are filled), the display control unit 114 causes the display unit 18 to display a warning display 434, as shown in FIG. 13 , warning that by loaning the specified number of ice axes, the user (i.e., the owner) will no longer be able to mine in the mountain to which the ice axe is loaned.

[0185] In this embodiment, the game control unit 212 performs processing to restrict the use of specific abilities that the owner can use when mining with a pickaxe by a scholar using the pickaxe loaned by the owner. Specifically, in this embodiment, a user who owns a pickaxe can use special items when mining. Special items are, for example, items that increase mining efficiency. Specifically, as shown in FIG. 11 , special items such as a bomb 77 and a ladder 78 are provided. Using the bomb 77 allows the player character to destroy the ground (i.e., rocks) and dig into mountains. Using (or placing) the ladder 78 allows the player character to move to higher or lower places. The special items can be used, for example, by performing a predetermined operation (e.g., scrolling the mouse wheel or operating a specific keyboard key) to change the item held by the player character from the pickaxe to a specific special item, followed by left-clicking the mouse. The game control unit 212 enables the use of the bomb 77 when the owner performs mining using a pickaxe. That is, the game control unit 212 places the bomb 77 on the mountain and explodes the bomb based on an operation to change the item held by the player character to the bomb 77 or a left-click operation of the mouse after performing that operation. On the other hand, the game control unit 212 disables the use of the bomb 77 when the scholar performs mining using a loaned pickaxe. That is, the game control unit 212 does not execute processing to place the bomb 77 on the mountain or processing to explode the bomb 77 based on an operation to change the item held by the player character to the bomb 77 or a left-click operation of the mouse after performing that operation. Note that the restriction on the use of abilities is not limited to disabling the use of abilities, and may, for example, reduce the number of times an ability can be used.

[0186] The lending-related screen 400 displays information about the lending or borrowing of the ice axe that the user is currently performing. Specifically, as shown in Fig. 12 , the lending-related screen 400 displays mountain information 405, owner information 406, reward information 407, additional information 408, and loaned object information 409 for each project for which the user is lending or borrowing their ice axe. Note that by performing a predetermined operation (for example, an operation on the arrow button 410 shown in Fig. 12 ), the lending-related screen 400 sequentially displays information about each project for which the user is lending or borrowing their ice axe.

[0187] The mountain information 405 is information about the mountain where the scholar will mine using the loaned pickaxe. In this embodiment, the mountain information 405 displays the name of the mountain and a virtual space ID that enables identification of each mountain. The mountain information 405 can also be considered information that indicates the event in which the scholar will play using the loaned pickaxe.

[0188] The owner information 406 is information about the owner who is lending the ice axe. In this embodiment, the owner's username is displayed as the owner information 406. Note that the owner's user ID, etc. may also be displayed as the owner information 406.

[0189] The reward information 407 is information about the reward for the achievements of the scalar (in other words, the reward for cooperation with the owner). In this embodiment, the reward information 407 displays the scalar's share set by the owner (specifically, the percentage of the pyroxene that the scalar will receive from the pyroxene that the scalar has dug up).

[0190] The additional information 408 is additional information about the case. In this embodiment, the additional information 408 displays information to be communicated to the scalar entered by the owner.

[0191] The loaned object information 409 is information about objects loaned to the scalar. In this embodiment, the loaned object information 409 displays, for a pickaxe loaned to a scalar, an image of the pickaxe, scalar information 409a indicating the user to whom the pickaxe is loaned, and achievement information 409b indicating the achievements the scalar has made by using the pickaxe. Specifically, the achievement information 409b displays the number of gems and gemstones the scalar has discovered by using the pickaxe.

[0192] Here, the loan-related screen 400 displayed on the owner's terminal device 10 (in other words, for a case in which the owner has loaned an ice axe) displays loaned object information 409 for all ice axes loaned to the scholar. On the other hand, the loan-related screen 400 displayed on the scholar's terminal device 10 (in other words, for a case in which the owner has loaned an ice axe) displays only the loaned object information 409 for the ice axe loaned to the scholar, and does not display the loaned object information 409 for ice axes loaned to other users. That is, for example, if user A, as the owner, loans ice axes to user B and user C, user A's terminal device 10 displays both the loaned object information 409 for the ice axe loaned to user B and the loaned object information 409 for the ice axe loaned to user C, as illustrated in FIG. 12 . On the other hand, in this case, on user B's terminal device 10, loaned object information 409 for the ice axe loaned to user B is displayed, but loaned object information 409 for the ice axe loaned to user C is not displayed.

[0193] The loan-related screen 400 also displays a cancel button 415 as a UI that accepts an operation to terminate the contract between the owner and the scalar (in other words, to end the loan of the pickaxe, or in other words, to terminate the cooperative relationship). When the owner or scalar operates the cancel button 415 on their own terminal device 10, the contract is terminated and the pickaxe loaned to the scalar is returned to the owner. When the cancel button 415 is operated, the control unit 110 of the terminal device requests the server 20 to cancel the contract. Based on the request, the control unit 210 of the server 20 executes a process to terminate the relationship between the owner and the scalar and return the pickaxe loaned to the scalar to the owner. Specifically, the control unit 210 erases the loan information for the pickaxe. This allows the owner to use the pickaxe to mine, and the scalar to no longer be able to use the pickaxe to mine. In this embodiment, the cancellation button 415 is displayed on the terminal device 10 of both the owner and the scalar, and the owner and the scalar can cancel the contract by operating the cancellation button 415.

[0194] In this embodiment, both the owner lending the ice axe and the scholar to whom the ice axe is loaned can terminate the contract and return the ice axe without the consent of the other party. However, the consent of the other party may be required to terminate the contract. For example, when one user operates the cancellation button 415 on their terminal device 10, the control unit 210 may execute a process to return the ice axe loaned to the scholar to the owner based on the other user performing a predetermined operation on their terminal device 10 to agree to the contract termination. In addition, in this embodiment, both the owner lending the ice axe and the scholar to whom the ice axe is loaned can cancel the contract by operating the cancellation button 415, but it is also possible for only one of them to cancel the contract.

[0195] In this embodiment, the durability of a pickaxe can only be restored by the owner of the pickaxe, not by a scholar. A scholar who wishes to restore the durability of a pickaxe loaned to them by the owner can request the owner to restore the durability, and the owner will then restore the durability.

[0196] As described above, the display control unit 114 of the terminal device 10 may cause the display unit 18 to display an item screen 64 that displays a list of ice axes available to the user, as shown in FIG. 10. Here, if the user is a scholar, ice axes borrowed from the owner are displayed on the item screen 64. Furthermore, when a specific ice axis owned by the user and displayed on the item screen 64 is selected, the display control unit 114 causes the display unit 18 to display a repair button 65 that accepts an operation related to restoring the durability of the specific ice axis, as described above. However, if the specific ice axis is a ice axis loaned by the owner (in other words, another user), the display unit 18 displays a repair request button (not shown) that accepts an operation related to restoring the durability of the specific ice axis instead of the repair button 65 (see FIG. 10).

[0197] When the repair request button is operated (e.g., clicked), the control unit 110 of the scholar's terminal device 10 transmits a request to restore the durability of the selected pickaxe to the owner's terminal device 10 via the server 20. Upon receiving the request, the control unit 110 of the owner's terminal device 10 notifies the owner of the request (in other words, that the scholar is requesting that the durability of the loaned pickaxe be restored). This notification may be made, for example, by displaying a message informing the owner of the request, such as "Pickaxe repair request received," in a log window 501 or the like displayed on the display unit 18 during mining, as shown in FIG. 6 , or by displaying a pop-up message informing the owner of the request. Furthermore, this notification may be made by displaying an icon 502 informing the owner of the request on a UI that accepts predetermined operations related to the pickaxe, such as the item button 92 or the pickaxe operation button 72 (see FIG. 10 ). The log window 501 may be, for example, a display area that displays events that have occurred in the virtual space. Specifically, the log window 501 may display a message informing the player that they (the owner) or another user participating in the multiplayer game (the scalar) have discovered a specific object (e.g., a gem or a gemstone), a message informing the player that another user has entered the mountain where they are mining, or a message informing the player that the durability of their pickaxe has decreased by a specific amount.

[0198] Furthermore, a request for recovery of the durability value of the pickaxe from the scalar may be made while the scalar is mining. For example, when an operation is performed on the pickaxe operation button 72 on the menu screen 70 displayed based on the operation of the scalar, the display control unit 114 of the scalar's terminal device 10 may display the repair request button, which accepts an operation related to the request for recovery of the durability value, on the display unit 18 instead of the repair button 73 (see FIG. 11 ).

[0199] The owner who has received the request then performs a predetermined operation to restore the durability of the pickaxe they have lent to the scholar (e.g., selecting the pickaxe displayed on the item screen 64 and operating the repair button 65, or operating the repair button 73 on the menu screen 70, etc.), thereby restoring the durability of the pickaxe. In other words, when the predetermined operation is performed, the control unit 110 of the owner's terminal device 10 requests the server 20 to restore the durability of the pickaxe for which the scholar has requested restoration of durability. Based on the request, the game control unit 212 of the server 20 restores the durability of the pickaxe and executes a process to have the owner pay a fee for the restoration of the durability (in other words, a process to reduce the specific tokens owned by the owner by the fee for the restoration of the durability). In other words, the game control unit 212 restores the durability of the pickaxe that the owner has lent to the scholar based on the owner's operation to instruct restoration of the durability of the pickaxe. In addition, the operation by the owner to instruct the recovery of the durability of the pickaxe may be executable both when the owner is mining and when the owner is not, or may be executable only in one of the two situations.

[0200] Note that requests for durability recovery may not be executed consecutively. For example, when a request for durability recovery is sent to the owner's terminal device 10 based on an operation related to the request for durability recovery by a scalar, the control unit 110 of the scalar's terminal device 10 may perform control so as not to accept any further operations related to the request for durability recovery by the scalar for a predetermined period of time (e.g., 60 minutes).

[0201] As mentioned above, in this embodiment, the scholar cannot restore the durability of the loaned pickaxe based on an operation to instruct the restoration of durability (for example, an operation on the repair button 65 or the repair button 73). However, in this embodiment, if the scholar discovers a gem while using the loaned pickaxe, the game control unit 212 restores a predetermined amount of durability of the pickaxe based on the discovery of the gem.

[0202] In addition, as shown in Figure 10, the item screen 64 may display a display 505 that allows the user to recognize an ice axe that has been loaned to another user, or a display 506 that allows the user to recognize an ice axe that has been loaned by another user.

[0203] In this embodiment, each user can only borrow one ice axe from another user, but it may be possible for a user to borrow multiple ice axes. Also, a user who owns an ice axe can borrow an ice axe from another user, but it may be possible for a user who owns an ice axe not to borrow an ice axe from another user. Also, a user who owns only one ice axe may or may not be able to lend the ice axe to another user.

[0204] In this embodiment, the scholar can play a predetermined event (in other words, a predetermined game) using a pickaxe as a specific object loaned to him by the owner. However, the specific object may be an item other than a pickaxe. For example, if the predetermined event is an event in which the scholar competes against an opponent, the specific object may be an item that can be used in the competition. The specific object may also be a character (e.g., a character controllable by the user) used in the progression of the predetermined event. In this embodiment, the pickaxe as a specific object has a durability value as a predetermined parameter that changes depending on the use of the pickaxe. The durability value is restored based on a predetermined operation by the owner. However, the predetermined parameter may be hit points or the like as a durability value when the specific object is a character. The predetermined parameter is not limited to durability, and may be any parameter that changes depending on the use of the specific object.

[0205] (Processing Flow) Next, an example of processing executed by the game system 1 will be described with reference to a flowchart. First, an example of processing related to mountain generation and determination of items that can be acquired from the mountain will be described with reference to the flowchart shown in FIG.

[0206] The virtual space management unit 231 acquires the hash generated at the end of the day from a specific blockchain (step S1). Next, the virtual space management unit 231 uses the acquired hash as a seed (specifically, a seed ｈｌａｓｔ ) to perform calculations and create a map (step S2). Specifically, the virtual space management unit 231 determines the topography of the map and the placement of mountains on the map, and assigns a virtual space ID to each mountain in the map so that the mountain can be identified.

[0207] Next, the virtual space management unit 231 determines an overview of the items that can be obtained for each mountain on the map created in step S2 (step S3). Specifically, the virtual space management unit 231 generates a seed (specifically, seed ｈｌａｓｔ , seed ｍｄｉｄ ) to determine the number of obtainable items for each pile and the approximate size of each item.

[0208] Next, the virtual space management unit 231 creates a pile of items that can be acquired (in other words, piles in which the items are arranged) whose outlines were determined in step S3 (step S4). Specifically, the virtual space management unit 231 creates a seed (specifically, a seed ｈｌａｓｔ , seed ｍｄｉｄ ) to perform calculations and create mountains.

[0209] Next, the virtual space 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 virtual space management unit 231 determines the details of the reward for each mountain on the map created in step S2 (step S6). Specifically, the virtual space management unit 231 generates a seed (specifically, seed ) using the hash acquired in step S5 and the virtual space ID of each mountain. ｈｆｉｒｓｔ , seed ｍｄｉｄ) to perform calculations to determine the type, size details, shape, quality, etc. of item B that can be obtained from each mountain.

[0210] Next, an example of processing related to mountain acquisition and mountain mining will be described with reference to the flowchart shown in FIG.

[0211] The operation reception unit 111 of the terminal device 10 receives an operation to acquire a mountain to be mined from among multiple mountains within a map (step S11). In other words, the operation reception unit 111 receives an operation to select a specific mountain from among the multiple mountains. In yet other words, the operation reception unit 111 receives an operation related to the acquisition of rights to play a game in a specific virtual space.

[0212] When an operation to acquire a mountain for mining is performed, the game control unit 212 grants the specific mountain to the user based on the operation (step S12). In other words, the game control unit 212 grants the user the right to play the game in a specific virtual space based on the user's operation.

[0213] Furthermore, the operation receiving unit 111 receives an operation to instruct the user to start mining in the mountain acquired by the user (step S13). In other words, the operation receiving unit 111 receives an operation by the user to instruct the user to start playing a game in a virtual space in which the user has the right to play the game.

[0214] Furthermore, the game control unit 212 starts mining based on an operation by the user instructing the start of mining in the mountain (step S14). In other words, the game control unit 212 starts playing a game in a specific virtual space based on an operation by the user instructing the start of playing a game in the specific virtual space. The started game may be one in which the user manually operates a player character or the like, or may be one in which the game control unit 212 automatically progresses without user operation. Specifically, for example, the player character may automatically perform mining, and gems or the like excavated by the player character may be given to the user as a reward. Furthermore, the user may be able to select whether to progress the game manually or automatically.

[0215] Next, the reward granting unit 233 grants a reward to the user based on the mining in the mountain (step S15). In other words, the reward granting unit 233 grants a reward to the user based on playing a game in a specific virtual space. Specifically, the reward granting unit 233 grants the user gems or pyroxene based on the mining in the mountain.

[0216] Next, an example of a process for lending a pickaxe, which is a specific object owned by an owner, to another user will be described with reference to the flowchart shown in FIG.

[0217] The control unit 110 of the owner's terminal device 10 accepts an operation by the owner to select an ice axe to lend to another user from among the ice axes he or she owns, and an operation to set conditions for the lending (step S21). Specifically, the control unit 110 of the owner's terminal device 10 accepts an operation to set, as a condition for the lending, the scalar share (in other words, the owner's share) for results obtained by another user using the loaned ice axe in the virtual space. The control unit 110 of the owner's terminal device 10 also accepts an operation to set, as a condition for the lending, the location where the loaned ice axe can be used. In other words, the control unit 110 of the owner's terminal device 10 accepts an operation to input various information related to the recruitment of scalars on the recruitment screen 420.

[0218] Next, the control unit 110 of the owner's terminal device 10 transmits to the server 20 information indicating the ice axe to be lent to the other user selected by the owner, and information indicating the conditions for lending the ice axe set by the owner, and requests the server 20 to start recruiting users who want to borrow the ice axe under those conditions (step S22). In other words, the control unit 110 of the owner's terminal device 10 requests the server 20 to start recruiting users based on the various information entered on the recruitment screen 420.

[0219] Next, based on the information transmitted from the owner's terminal device 10 and the request to start the recruitment, the control unit 210 of the server 20 begins recruiting users to borrow the ice axe selected by the owner under the conditions set by the owner (step S23). Specifically, the control unit 210 registers the ice axe in the storage unit 220 as an ice axe that the owner can lend to other users. The control unit 210 also sets the conditions for lending the ice axe based on the information transmitted from the owner's terminal device 10 and stores the information related to the settings in the storage unit 220.

[0220] In addition, the control unit 110 of the terminal device 10 of the scholar candidate (in other words, a user looking for an ice axe to borrow) accepts operations related to displaying the application screen 440 as a screen displaying ice axes available for loan (specifically, ice axes that can be loaned from owners to scholars, in other words, ice axes that can be borrowed by scholars) (step S24).

[0221] Next, the control unit 110 of the terminal device 10 of the scholarship candidate requests information about the ice axes to be displayed as loanable ice axes on the application screen 440 from the server 20 based on the operation of the scholarship candidate to display the application screen 440 (step S25).

[0222] Next, based on a request from the terminal device 10 of the scholar candidate, the control unit 210 of the server 20 transmits information about the ice axes available for loan that are registered in the memory unit 220 to the terminal device 10 (step S26).

[0223] Next, the control unit 110 of the terminal device 10 of the scholar candidate causes the display unit 18 to display the application screen 440, which displays the available ice axes registered in the storage unit 220, based on the information on the available ice axes transmitted from the server 20 (step S27). The server 20 also transmits information indicating the conditions for lending the available ice axes registered in the storage unit 220, and the application screen 440 also displays the conditions for lending the available ice axes. The information on the available ice axes transmitted from the server 20 may be transmitted to the terminal device 10 of the scholar candidate in advance, for example, before an operation related to displaying the application screen 440 is performed. Then, when the operation is performed, the application screen 440 may be displayed based on the information transmitted in advance.

[0224] Next, the control unit 110 of the terminal device 10 of the scholarship candidate accepts an operation to select the ice axe to be loaned (in other words, borrowed) from the ice axes available for loan displayed on the application screen 440 (step S28).

[0225] Next, the control unit 110 of the terminal device 10 of the scholar candidate requests the server 20 to lend the selected ice axe based on the operation of the scholar candidate to select the ice axe to be loaned (step S29).

[0226] Next, based on the request, the control unit 210 of the server 20 loans the ice axe selected as the ice axe to be loaned from the owner to the user who selected the ice axe (step S30). Specifically, the control unit 210 stores loan information in the storage unit 220 indicating that the ice axe has been loaned from the owner to the user as a scalar. Note that upon loan, the candidate for scalar status becomes a scalar. Note that information indicating that a certain user is a scalar for a certain owner may be stored in the storage unit 220 separately from the loan information, or the loan information may serve as this information.

[0227] Next, an example of a process for allowing the owner to acquire at least a portion of the results obtained by the scholar using the pickaxe as a loaned specific object in the virtual space will be described with reference to the flowchart shown in Figure 18.

[0228] Based on the scholar's operation, the game control unit 212 causes the scholar to start mining using the loaned pickaxe (step S41).

[0229] Next, the game control unit 212 determines whether the scalar has discovered a pyroxene (step S42). The game control unit 212 moves the scalar's player character based on the scalar's operation, and when the scalar's player character digs up a place in the mountain where pyroxene is buried and the pyroxene is dug up, determines that the scalar has discovered a pyroxene.

[0230] If it is determined that the scalar has discovered a pyroxene (YES in step S42), the game control unit 212 determines how much of the discovered pyroxene to give to the scalar and how much to give to the owner based on the conditions set for lending the pickaxe. Specifically, the game control unit 212 determines the amount of the discovered pyroxene minus the scalar's share set by the owner as a condition for lending the pickaxe as the pyroxene to be granted to the owner, and grants it to the owner (step S43). That is, the game control unit 212 adds the discovered pyroxene that corresponds to the owner's share to the owner's assets. Furthermore, the game control unit 212 determines the discovered pyroxene that corresponds to the scalar's share set by the owner as a condition for lending the pickaxe as the pyroxene to be granted to the scalar, and grants it to the scalar (step S44). That is, the game control unit 212 adds the discovered pyroxene that corresponds to the scalar's share to the scalar's assets. If there are multiple scalars, the game control unit 212 determines the share of each scalar according to the above-mentioned calculation formula, and grants each scalar the amount of gemstones corresponding to their share.

[0231] In this embodiment, the items, virtual currencies, tokens, and various logics (in other words, smart contracts) managed by the blockchain may be managed by the same blockchain, or some of them may be managed by different blockchains. The hashes used in various processes may be hashes from the same blockchain or from other blockchains. Existing blockchains, such as Ethereum and Bitcoin, may be used. NFTs corresponding to item A and item B (in other words, NFTized objects) may be bridged from the blockchain on which they were issued to other blockchains.

[0232] 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.

[0233] The present invention is not limited to the above-described embodiments and can be implemented in various modifications without departing from the spirit of the invention. Within the scope of the present invention, the components can be freely combined, any components can be modified, or any components can be omitted. Furthermore, the process flow described in this specification is merely an example, and the order and configuration of each process may be different. Furthermore, some processes, such as the various determination processes described in this specification, may not exist. In other words, the process flow and specific determination processes may differ from those exemplified in this specification.

[0234] <Additional Notes> The matters described in the above embodiment can also be written as the following additional notes.

[0235] (Supplementary Note 1-1) A program that causes a computer to function as: a lending means (e.g., a control unit 210) that lends an NFT-enabled specific object that can be used in a virtual space from an owner (i.e., a user who owns the specific object) to another user; and an acquisition means (e.g., a control unit 210) that allows the owner to acquire at least a portion of the results achieved by the other user using the loaned specific object in the virtual space. With this configuration, for example, even a user who does not own the NFT-enabled specific object can borrow the specific object from the owner and use it in the virtual space. Therefore, for example, it becomes possible to use the service without acquiring the specific object as their own object, thereby reducing user resistance to the service. Furthermore, for example, because the owner can acquire at least a portion of the results achieved by a user who uses the loaned specific object, the owner can be motivated to lend the specific object to other users or to acquire it in order to lend it. Therefore, for example, it becomes easier for users who do not own the specific object to borrow the specific object from the owner, making the service easier to use.

[0236] (Supplementary Note 1-2) The program according to Supplementary Note 1-1 causes a computer to function as a setting means (e.g., a control unit 210) that sets conditions for lending the specific object based on the owner's operation, and the acquisition means determines which of the results the owner is to acquire based on the set conditions. With this configuration, for example, the portion of the results achieved by a user using the loaned specific object that the owner acquires is determined based on the conditions set by the owner. Therefore, for example, it becomes easier for the owner to lend the specific object, and easier for users who do not own the specific object to borrow the specific object from the owner, making it easier to use the service.

[0237] (Supplementary Note 1-3) The program according to Supplementary Note 1-1, wherein the objects that can be obtained by the other user using the loaned specific object in the virtual space include a first object and a second object, and the acquisition means causes the owner to acquire all of the first objects that have been obtained by the other user using the loaned specific object in the virtual space, and causes the owner to acquire some of the second objects that have been obtained by the other user using the loaned specific object in the virtual space. With this configuration, for example, the owner will acquire all of the objects that are part of the multiple objects that can be obtained by the other user using the loaned specific object, which can motivate users who want to acquire some of the objects to own the specific objects.

[0238] (Supplementary Note 1-4) The program according to Supplementary Note 1-1 causes the computer to function as recovery means (e.g., control unit 210) that recovers predetermined parameters that are set for the specific object and change depending on the use of the specific object, and the recovery means recovers the predetermined parameters of the specific object that is being loaned to the other user based on an operation by the owner instructing the recovery of the predetermined parameters. With this configuration, for example, it is possible to prevent the connection between the owner and the specific object, or the connection between the owner and the user who borrowed the specific object, from becoming weak after the specific object is loaned.

[0239] (Supplementary Note 1-5) The program according to Supplementary Note 1-4, wherein the specific parameter of the specific object currently being lent to the other user cannot be restored based on an operation by the other user instructing the restoration of the specific parameter. With this configuration, for example, after the specific object is lent, it is possible to strongly prevent the connection between the owner and the specific object, or the connection between the owner and the user who borrowed the specific object, from becoming weak.

[0240] (Supplementary Note 1-6) The program according to Supplementary Note 1-1, which causes a computer to function as a restriction means (e.g., the control unit 210) that restricts the use by the other user of the loaned specific object of a specific ability that can be used by the owner when attempting to obtain the result using the specific object. With this configuration, for example, a user who uses a loaned specific object is restricted in the use of the specific ability, which can motivate the user to own the specific object.

[0241] (Supplementary Note 1-7) The program according to Supplementary Note 1-1 causes a computer to function as a use location determination means (e.g., the control unit 210) that determines a location where the other user can use the loaned specific object based on an operation by the owner. With this configuration, for example, it is possible to prevent a user to whom a specific object has been loaned from being able to use the specific object without any restrictions.

[0242] (Supplementary Note 1-8) The program according to Supplementary Note 1-1, wherein the virtual space is a space in which a multiplayer game is played, in which the owner and the other users who use the loaned specific object participate. With this configuration, for example, the owner can loan the specific object they own to other users to enjoy a game together, and can earn at least a portion of the achievements made by the other users in return for the loan.

[0243] (Appendix 1-9) An information processing system comprising: a lending means (e.g., a control unit 210) for lending a specific object converted into an NFT that can be used in a virtual space from an owner (a user who owns the specific object) to another user; and an acquisition means (e.g., a control unit 210) for allowing the owner to acquire at least a portion of the results obtained by the other user using the lent specific object in the virtual space. With this configuration, it is possible to achieve the same effects as the program described in Appendix 1-1.

[0244] (Supplementary Note 2-1) A program that causes a computer to function as: a lending means (e.g., a control unit 210) that lends a specific NFT object that can be used in a virtual space from the owner of the specific object to a user; and a reward granting means (e.g., a control unit 210) that grants the user a reward based on results achieved by the user using the loaned specific object in the virtual space. With this configuration, for example, even a user who does not own the specific NFT object can borrow the specific object from the owner and use it in the virtual space. Therefore, for example, it becomes possible to use a service without acquiring the NFT object as their own object, thereby reducing user resistance to services that use NFT objects. Furthermore, because users who are loaned a specific object receive a reward based on results achieved by using the loaned specific object, they may be more proactive in using the service to achieve high results, for example, thereby reducing user resistance to the service.

[0245] (Supplementary Note 2-2) The program described in Supplementary Note 2-1, wherein the reward granting means determines the reward to be granted to each of the multiple users who have been loaned the specific object from the same owner, based on the amount of work each of the multiple users has done, when one of the users achieves a predetermined result. With this configuration, for example, a user who borrows an NFT-converted object can earn a reward even if another user who borrowed the NFT-converted object has achieved a predetermined result. Therefore, for example, interest in using a service using an NFT-converted object can be increased, and users' reluctance to borrow an NFT-converted object can be reduced. Furthermore, for example, if multiple users are loaned a specific object from an owner, if the presence or absence of a reward is determined solely by whether or not the user has achieved a predetermined result, a user who worked harder than other users but failed to achieve the predetermined result may feel a sense of unfairness. In contrast, with this configuration, when another user achieves a predetermined result, the user can receive a reward based on their own amount of work, thereby reducing the likelihood of such a sense of unfairness. Furthermore, even if a predetermined result is not achieved, the person's efforts will not be wasted, which can motivate them to borrow and use the NFT object.

[0246] (Supplementary Note 2-3) The program according to Supplementary Note 2-1 or 2-2 causes a computer to function as a setting unit that sets conditions for lending the specific object based on the owner's operation, and the reward granting unit determines the reward based on the set conditions. With this configuration, for example, a reward for achievements achieved by a user using the loaned specific object is determined based on the conditions set by the owner. This makes it possible to diversify the relationship between achievements and rewards, making it easier to lend and borrow NFT-converted objects.

[0247] (Appendix 2-4) The program described in Appendix 2-1 or 2-2 includes a first object and a second object as objects that can be obtained by the user using the loaned specific object in the virtual space, and the reward granting means grants all of the first objects obtained by the user using the loaned specific object in the virtual space to the owner, and grants a portion of the second objects obtained by the user using the loaned specific object in the virtual space to the user as the reward. With this configuration, for example, the owner will acquire all of the multiple objects that can be obtained by the user using the loaned specific object, thereby motivating users who want to acquire some of the objects to own the specific objects. Therefore, for example, the user's resistance to acquiring the specific objects can be reduced.

[0248] (Supplementary Note 2-5) The program according to Supplementary Note 2-1 or 2-2, which causes a computer to function as a use location determination means (e.g., the control unit 210) that determines a location where the user can use the loaned specific object based on an operation by the owner. With this configuration, for example, it is possible to prevent a user to whom a specific object has been loaned from being able to use the specific object without any restrictions.

[0249] (Supplementary Note 2-6) The program described in Supplementary Note 2-1, wherein the virtual space is a space where a multiplayer game is played, in which the owner and the user using the loaned specific object participate. With this configuration, for example, even users who do not own a specific object can participate in a multiplayer game. In addition, even if a user participates in a multiplayer game using a specific object loaned by the owner, the user can receive rewards based on their own achievements, allowing the user to fully enjoy the service. Therefore, for example, it is possible to make it easier to start using the service, and reduce user resistance to the service.

[0250] (Supplementary Note 2-7) The program according to Supplementary Note 2-2, wherein the virtual space is a space in which a multiplayer game is played in which multiple users who have been loaned the specific object by the same owner participate. With this configuration, for example, it becomes possible for users who do not own the specific object to play a multiplayer game. Therefore, for example, it is possible to make it easier to start using the service and reduce user resistance to the service.

[0251] (Supplementary Note 2-8) A program that causes a computer to function as a reward granting unit that, when one of multiple users participating in a predetermined event and using a specific NFT object achieves a predetermined result in a virtual space, determines a reward to be granted to each of the multiple users based on the amount of work done by each of the multiple users, and grants the reward to each of the multiple users. With this configuration, for example, a user participating in a predetermined event using an NFT object can earn a reward even if another user participating in the predetermined event using an NFT object achieves a predetermined result. Therefore, for example, the interest in services that use NFT objects can be increased, and users' resistance to services that use NFT objects can be reduced. Furthermore, for example, if the presence or absence of a reward is determined solely by whether or not a predetermined result is achieved when participating in a predetermined event using an NFT object, a user who worked harder than other users but did not achieve the predetermined result may feel a sense of unfairness. In contrast, with this configuration, when another user achieves a predetermined result, the user can earn a reward based on the user's amount of work, thereby reducing the likelihood of such a sense of unfairness. Furthermore, even if a predetermined result is not achieved, the user's efforts will not be wasted, which can motivate the user to use the NFT object.

[0252] (Supplementary Note 2-9) An information processing system comprising: a lending means for lending a specific object converted into an NFT that can be used in a virtual space from an owner of the specific object to a user; and a reward granting means for granting the user a reward according to the results obtained by the user using the loaned specific object in the virtual space. With this configuration, it is possible to achieve the same effects as the program described in Supplementary Note 2-1.

[0253] (Supplementary Note 2-10) An information processing system that functions as a reward granting means that, when one of a plurality of users who participate in a predetermined event and use a specific object converted into NFT achieves a predetermined result by using the specific object in a virtual space, determines a reward to be granted to each of the plurality of users according to the amount of work each of the plurality of users does, and grants the reward to each of the plurality of users. With this configuration, it is possible to achieve the same effects as the program described in Supplementary Note 2-8.

[0254] 1 Game system, 3 Blockchain system, 10 Terminal device, 11 Processor, 12 Memory, 13 Storage, 14 Communication IF, 15 Input / output IF, 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 Virtual space management unit, 233 Reward granting unit, 310 Control unit, 320 Memory unit

Claims

1. A program that causes a computer to function as: a lending means for lending a specific object that has been converted into an NFT and that can be used in a virtual space from an owner, who is a user who owns the specific object, to another user; an acquisition means for allowing the owner to acquire at least a portion of the results obtained by the other user using the loaned specific object in the virtual space; and a recovery means for recovering specified parameters that are set in the specific object and change depending on the use of the specific object, wherein the recovery means recovers the specified parameters of the specific object being loaned to the other user based on an operation by the owner instructing the recovery of the specified parameters.

2. The program according to claim 1, wherein the specified parameters of the specific object being lent to the other user cannot be restored based on an operation by the other user instructing the restoration of the specified parameters.

3. An information processing system comprising: a lending means for lending a specific object that has been converted into an NFT and can be used in a virtual space from an owner, who is a user who owns the specific object, to another user; an acquisition means for allowing the owner to acquire at least a portion of the results obtained by the other user using the loaned specific object in the virtual space; and a recovery means for recovering specified parameters that are set in the specific object and change depending on the use of the specific object, wherein the recovery means recovers the specified parameters of the specific object being loaned to the other user based on an operation by the owner instructing the recovery of the specified parameters.

Images