JP7803992B2 - Program and information processing system - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act November 30, 2023 (Multi Beta Test)

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

Conventionally, games have been known in which users who have established a specific relationship within the game cooperate with each other to play the game. Furthermore, in recent years, there has been progress in the development of technology related to the provision of various services using blockchain (see, for example, Patent Document 1). It is known that in games utilizing blockchain technology, a relationship of owner and scalar is established between users, and users play the game as either the owner or scalar.

JP 2017-204070 A

By the way, there is a demand for services such as games to be more entertaining.

The purpose of this invention is to improve the interest of services.

According to one embodiment shown in the present disclosure,
Computer,
a setting means for setting a predetermined relationship between a first user and a second user;
a cancellation means for canceling the predetermined relationship between the first user and the second user based on an operation by the first user;
and an erasure means for erasing a predetermined influence that the second user had on an object owned by the first user during a period in which the predetermined relationship was established between the first user and the second user, based on the termination of the predetermined relationship between the first user and the second user.

This invention can improve the interest of services.

FIG. 1 is a diagram illustrating a schematic configuration of a game system. FIG. 2 is a block diagram showing the functional configuration of the game system. FIG. 10 is a diagram illustrating an example of a screen displaying a map. FIG. 10 is a diagram illustrating an example of a home screen. FIG. 10 is a diagram illustrating an example of a screen displaying a list of mountains acquired by a user. FIG. 10 is a diagram showing an example of a game screen when mining is performed. FIG. 1 is a diagram for explaining the flow of asset acquisition and consumption. FIG. 1 is a diagram illustrating a timeline for mountain acquisition and mining. FIG. 10 is a diagram showing an example of a screen related to the purchase of an item. FIG. 10 is a diagram illustrating an example of a screen displaying a list of items owned by a user. FIG. 10 is a diagram showing an example of a menu screen that can be displayed during mining. FIG. 10 is a diagram showing an example of a screen related to the lending of an ice axe. FIG. 10 is a diagram illustrating an example of a screen for recruiting scholars. FIG. 10 is a diagram showing an example of a screen for applying for a scholarship position. 10 is a flowchart illustrating an example of processing related to the generation of a mountain and the determination of items that can be obtained from the mountain. 10 is a flowchart illustrating an example of a process related to mountain acquisition and mining. 10 is a flowchart showing an example of a process for lending an ice axe to another user. 10 is a flowchart illustrating an example of a process for allowing an owner to acquire at least a portion of the results obtained through a scholar's use of an ice axe.

Embodiments of the present invention will be described below with reference to the drawings.

<Game system hardware configuration>
1 , the game system 1 of this embodiment includes a plurality of terminal devices 10, a server 20, and a blockchain system (in other words, a blockchain network) 3. The blockchain system 3 also includes a plurality of node devices 30.

The terminal device 10, server 20, and blockchain system 3 (in other words, node device 30) are connected to each other via network 2. 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.

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 comprises a processor 21, memory 22, 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.

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

Memory 22 is the main storage device. Memory 22 is composed of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). Memory 22 provides a working area for processor 21 by temporarily storing programs and various data that processor 21 reads from storage 23. Memory 22 also temporarily stores various data generated while processor 21 is operating according to the programs.

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

Storage 23 is an auxiliary storage device. Storage 23 is composed of a storage device such as flash memory or an HDD (Hard Disk Drive). Various data related to the game is stored in storage 23.

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

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

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

The terminal device 10 includes a processor 11, memory 12, 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 via a communication bus.

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.

Memory 12 is a main storage device. Memory 12 is composed of storage devices such as ROM and RAM. Memory 12 provides a working area for processor 11 by temporarily storing programs and various data that processor 11 reads from storage 13. Memory 12 also temporarily stores various data generated while processor 11 is operating according to a program.

Storage 13 is an auxiliary storage device. Storage 13 is composed of a storage device such as flash memory or an HDD. Various data related to the game is stored in storage 13.

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

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

The input unit 17 accepts input from the 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 EL (Electro-Luminescence) display. The terminal device 10 may be equipped with, 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 the function of detecting a position input on the input surface by a user operation (for example, a touch operation, a tap operation, a slide operation, a swipe operation, a flick operation, a pinch-in operation, a pinch-out operation, etc.) and transmitting information indicating the detected position as an input signal.

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

In this embodiment, the input unit 17 is described as a keyboard and mouse. Note that in this embodiment, operations on various UI elements such as buttons may be performed by, for example, positioning the mouse cursor over an area on the display unit 18 where the button is displayed and clicking.

Multiple node devices 30 make up the 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 more detail later, in this embodiment, assets held by users are managed in the distributed ledger of the blockchain system 3.

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

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.

Memory 32 is a main storage device. Memory 32 is composed of storage devices such as ROM and RAM. Memory 32 provides a working area for processor 31 by temporarily storing programs and various data that processor 31 reads from storage 33. Memory 32 also temporarily stores various data generated while processor 31 is operating according to a program.

Storage 33 is an auxiliary storage device. Storage 33 is composed of a storage device such as flash memory or an HDD, for example.

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

The input/output IF 35 is an interface through which the node device 30 accepts data input, 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 keyboard, and a display unit that is a device that displays and outputs images.

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.

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

In this embodiment, the server 20 identifies each user and 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's operation, and the server 20 may then create and save each user's account based on the received information.

As shown in FIG. 2, the server 20 functions as a control unit 210 and a storage unit 220 through cooperation of a processor 21, memory 22, storage 23, communication IF 24, 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 the games. The game information and user information are data referenced by the control unit 210 when executing the programs.

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. 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 within the virtual space. Hereinafter, character objects placed in the virtual space may be simply referred to as "characters."

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 the user has acquired (mountains will be described later) (in other words, information about the rights to play the game in a specific virtual space). Owned assets can be said to be value owned 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 the game. In other words, the storage unit 220 may store information such as electronic currency, tokens, items, or characters owned by each user, for example, by associating each user with identification information that can identify each user.

The control unit 210 controls various game-related processes by executing programs stored in the memory 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.

The transmission/reception unit 211 transmits and receives various types of data. For example, the transmission/reception unit 211 receives requests to transmit various types of data and programs, requests for synchronization processing to support multiplayer functions, data to be synchronized, etc. from each terminal device 10, and passes them on to the game control unit 212, asset management unit 213, market management unit 214, etc. The transmission/reception unit 211 also 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.

In this embodiment, the multiplay function is a function that allows game processing by multiple accounts to proceed in a synchronized state. The server 20 and terminal device 10 of the game system 1 perform various processes to support the multiplay function when multiple accounts logged in to the game system 1 participate in the same game.

The game control unit 212 provides a game to the terminal device 10 by executing calculations described in the program stored in the memory unit 220.

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 within the virtual space, and causes the objects to perform predetermined actions.

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 operations. The play information is output in response to the user's input operations. For example, the play information may include, as the content of the player character's operation, player character coordinate information, information regarding the player character's action, or information indicating the button operated by the user. The play information may also include information regarding the player character's settings. For example, the character 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 the action of swinging a pickaxe, the action of using various items, or a jump, 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.

The game control unit 212 places the player characters of multiple players in a single virtual space and can control each player's player character 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.

Furthermore, when the game control unit 212 receives, for example, a request for synchronization processing to support the multiplayer function or data to be subject to synchronization processing from the terminal device 10 via the transmission/reception unit 211, it executes synchronization processing to support the multiplayer function. The game control unit 212 also issues a command to the transmission/reception unit 211 to instruct the transmission of game information or user information. For example, when the server 20 sends information to multiple terminal devices 10, the game control unit 212 synchronizes the game progressing between the terminal devices 10 by simultaneously sending the information to each terminal device 10. By executing synchronization processing, it becomes possible for in-game events resulting from operations input on one terminal device 10 to be reflected simultaneously on the other terminal devices 10.

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 user's assets in the distributed ledger of the blockchain system 3. In other words, the asset management unit 213 may store information about the user's assets in the memory unit 220, or may store the information in the distributed ledger. Note that if the server 20 is configured to function as a node device 30, the asset management unit 213 may store information about the held assets in the distributed ledger stored in its own memory unit 220. Note that if the server 20 is configured not to 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.

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

The terminal device 10 functions as a control unit 110 and a storage unit 120 through cooperation between 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. Examples of the various data include 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.

The control unit 110 controls various processes related to the game executed on the terminal device 10 by executing programs stored in the memory unit 120. 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.

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 the mouse or keyboard serving as the input unit 17. Note that 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.

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

The transmission/reception unit 112 also receives various data, programs, and various requests from the server. As an example, the data that the transmission/reception unit 112 receives 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. As another example, the data that the transmission/reception unit 112 receives from the server may include data for synchronization to support multiplayer functions. The data for synchronization may include, for example, the data to be synchronized, the type of data, and data for specifying the time to synchronize.

The device processing unit 113 executes various processes related to the progress of the game. The device processing unit 113 identifies the user's instructions based on the user's input operations 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 instructions, etc. The device processing unit 113 also progresses the game while communicating with the server 20 based on the results of the determination processes, etc.

The device processing unit 113 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 within 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 on the display unit 18 that corresponds to the progress of the game.

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 in the center of the field of view in a specific orientation. In doing so, 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 non-player character, or a static object such as a building, tree, or stone. Dynamic objects include player characters that act based on the operations of each user, and non-player characters that act based on a program.

The display control unit 114 displays images related to the game on the display unit 18. Specific examples are explained below.

The display control unit 114 generates an image of the virtual space, depicting the area of the field of view of the virtual camera defined by the device processing unit 113 and the objects present in that area, and displays it on the display unit 18. The display control unit 114 can superimpose and draw objects related to the UI (User Interface) required for various game operations, such as icons, buttons, and menus showing various parameters, on the image displayed on the display unit 18.

The control unit 110 of the terminal device 10 may place objects in the virtual space based on object data sent from the server 20 and information indicating the positions of various objects in the virtual space, and display a predetermined area of the virtual space on the display unit 18. The control unit 210 of the server 20 may also place objects in the virtual space and control the virtual camera, generate an image to be displayed on the display unit 18, and send 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, and generation of images to be displayed on the display unit 18 may be performed by either the server 20 or the terminal device 10.

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

The control unit 310 controls the operation of the node device 30 by executing programs stored in the memory unit 320.

When a user acquires various items or a specific token (described below) (for example, from another user or a game operator (for example, by mining, described below)), the control unit 310 receives a request to register information related to the holdings 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 containing hash values and transactions. A transaction may be, for example, information indicating the transaction details of an 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 the information contained in the previous block, and the distributed ledger stores the transaction history of 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, it is possible to store information indicating which users own which items, and information indicating how many specific tokens each user owns, on the blockchain. Note that instead of the transaction history of items, etc., information regarding each user's item ownership status may be managed in a distributed ledger, thereby storing information indicating which users own which items on the blockchain. In this way, in the game of this embodiment, information regarding the ownership of 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.

Note that the functions of the terminal device 10, server 20, and node device 30 shown in FIG. 2 are merely examples. Each of the terminal device 10, server 20, and 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 node device 30 may have some or all of the functional blocks of the terminal device 10, the terminal device 10 or node device 30 may have some or all of the functional blocks of the server 20, or the terminal device 10 or 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, server 20, and node device 30, does not have to be realized by an integrated device, and may be realized, for example, by multiple devices connected via a network or the like. Furthermore, the game system 1 may not include, for example, the terminal device 10, server 20, or node device 30.

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

Here, an overview of the game of this embodiment will be described. In the game of this embodiment, there is a map 40 that is shared among multiple users (specifically, all users) participating in the game. An example of the map 40 is shown in Figure 3. Multiple mountains are located on the map 40. In the map 40 shown in Figure 3, the positions of the mountains are indicated by triangular symbols.

The user acquires (or selects) the mountain they will mine (or the virtual space in which they will play the game) from the map 40. Acquiring 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 available for acquisition by the user) as shown in FIG. 3 based on a predetermined input operation by the user. The user can then acquire a specific mountain by selecting it on the map 40 displayed on the display unit 18 (for example, by clicking on the specific mountain displayed). Specifically, for example, when an operation is performed to select a specific mountain from the mountains displayed on the map 40, 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.

In addition, users are able to mine for specific items in the mountains they have acquired. In other words, once a user acquires a mountain, they are able to play a game in which they mine in the acquired mountain. In other words, in this embodiment, "acquiring a specific mountain" can be rephrased as "acquiring the right to mine in a specific mountain," or even "acquiring the right to play a game in a specific virtual space." Note that the system may be configured so that users can mine in a mountain without acquiring the mountain (in other words, without acquiring the right to mine).

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 required 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). An NFT state refers to a state in which information proving that item A is unique is stored on the blockchain. In other words, an NFT state refers to a state in which an NFT corresponding to item A has been issued and is managed on the blockchain. Hereinafter, digital assets such as items for which a corresponding NFT has been issued will also be 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 convert item A into an NFT (in other words, mint it). In other words, in the game of this embodiment, users will not be able to obtain item A that has not been converted into an NFT. However, users may be able to convert item A into an NFT.

In addition, in the game of this embodiment, users can acquire items B and C through mining. As will be described in detail below, 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, tokens that can be acquired in exchange for item C will be referred to as "specific tokens."

In addition, 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 different from gems (hereinafter referred to as "pyroxene"). In other words, 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.

Furthermore, the specific token that can be acquired in exchange for item C is a crypto asset (e.g., virtual currency). In the game of this embodiment, the specific token can be used to level up item A, repair item A (in other words, fix it), and turn item B into an NFT, etc.

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

Mining in a mountain as a specified event is carried out, for example, as follows. For example, the display control unit 114 of the terminal device 10 causes the display unit 18 to display the home screen 42 illustrated in FIG. 4 based on a specified input operation by the user. The home screen 42 displays a start mining button 43 that accepts operations 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 based on the operation on the start mining button 43.

The home screen 42 is the first screen displayed when the game (or, in other words, an application related to a specific 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 also be displayed at a specific 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 specific 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 mine button 91, item button 92, loan-related button 93, shop button 94, and home button 90 may be displayed as such UIs. 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. The display control unit 114 may switch the display between a screen displaying the map 40 shown in FIG. 3 and a screen displaying a list of acquired mountains 44 shown in FIG. 5, based on an operation 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.

The mountain that the user will mine 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, for example, be a list of mountains acquired by the user on a map 40 displayed on the display unit 18. When an operation (e.g., a click operation on a specific mountain) is performed to select a specific mountain from the mountains acquired by the user (in other words, the listed mountains) displayed on the display unit 18, 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. Based on an operation on the mining target determination button 46, the game control unit 212 sets the mountain selected by the user as the mountain to be mined. When the start mining button 43 is operated, mining begins on the mountain that was set as the mountain to be mined by operating the mining target determination button 46. That is, in this embodiment, the user can select (or change) the mountain to be mined by selecting the mountain they wish to mine from the list of mountains 44 they have acquired and operating the mining target selection button 46. When the user selects a specific mountain from the list of mountains 44 they have acquired, 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 that 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 identifies 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 identifies the pickaxe set as the pickaxe to be used for mining (i.e., the pickaxe equipped on the player character).

When the mining start button 43 is operated, the game control unit 212 places the player character 38 in the mountain 37 where mining will take place, 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). In other words, the start of mining on a specific mountain 37 can be considered the start of game play in a specific virtual space, or entry into 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 conventional action games, but may also be as follows, for example. The game control unit 212 may move the player character 38 within the mountain 37 based on operations using the "W", "A", "S", and "D" keys on the keyboard. The game control unit 212 may also cause the player character 38 to jump based on operations using the space bar 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 operations using the left mouse button.

Gems and pyroxenes are buried (in other words, arranged) in the mountain 37. Users can acquire the gems and pyroxenes they dig up (in other words, discover). That is, when a player character 38 operated by a 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 item).

Note that mining can be interrupted midway. For example, the display control unit 114 of the terminal device 10 displays the 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 to exit 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 memory unit 220. Then, the next time mining in the same mountain 37 is started, 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 remain excavated, and the gems, etc. buried in the mountain 37 that were previously dug up will remain unextracted. In other words, when a user leaves and re-enters mountain 37 as a specific virtual space, the changes made by the user the last time they entered are reflected in the specific virtual space. In other words, in this embodiment, it is possible to pause a game in a specific virtual space and resume it from where it left off.

The user can also dispose of the mountains they have acquired at their discretion. 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 operations 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 impossible.

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 also be changeable while mining is in progress.

Pickaxes used for mining have a durability value, which 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 will not be able to dig into the surface. Note that once the durability value reaches the predetermined value, mining may still be possible using the pickaxe, although its performance will decrease.

The operation reception unit 111 also receives an operation from 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 that operation. A predetermined amount of specific tokens is required to recover the durability of the pickaxe, and when the durability of the pickaxe is recovered through that operation, that predetermined amount of specific tokens is consumed.

Pickaxes also have a rank. Note that rank includes so-called level, 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, mining efficiency) change. More specifically, as the pickaxe's rank increases, parameters related to the pickaxe's swing speed change, and the pickaxe's swing speed increases. This increases the mining speed and therefore the mining efficiency. Furthermore, as the pickaxe's rank increases, the pickaxe's maximum durability increases. This increases the amount of time that mining can continue without the durability recovering, and therefore the mining efficiency. Furthermore, as the pickaxe's rank increases, the pickaxe's power increases, and the amount that can be dug with one swing (in other words, the amount of impact that one operation has on the mountain) and other factors may increase. This increases the mining speed and therefore the mining efficiency.

The operation reception 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 that operation. Increasing the rank of the pickaxe also requires a predetermined amount of specific tokens, and when the pickaxe's rank is increased through that operation, that predetermined amount of specific tokens is consumed.

Note that in the game of this embodiment, items may be available 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 cryptocurrency (e.g., user-owned assets that are not managed by the blockchain but are managed in the storage unit 220, etc.). Note that the in-game currency may also be something that can be purchased using legal tender, etc.

Furthermore, the various items in this embodiment (for example, item A, item B, and item C) may be referred to as objects. Objects include characters, items, etc. In other words, item B and item C, which are granted by playing a game (in other words, by performing an event) in a mountain as a specific virtual space, may be characters, etc.

In this embodiment, the map is updated (or, in other words, newly generated) at predetermined intervals (specifically, once a day). Acquirable mountains are also updated (or, in other words, newly generated) at predetermined intervals (specifically, once a day) in conjunction with the map updates. Each mountain can only be acquired by one user, and once a user acquires a mountain (or, 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 available mountains may involve completely replacing past maps and mountains (or, in other words, creating new maps and mountains, and erasing past maps or making past mountains unacquirable), or may involve expanding past maps or adding new mountains to those previously created (or, in other words, increasing the number of available mountains).

Here, the flow of asset acquisition and consumption in the game of this embodiment will be explained with reference to Figure 7.

As mentioned above, in the game of this embodiment, the user must 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 from 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 they wish 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 this operation, and to transfer payment from the user to the person who sold the item.

The user then uses the pickaxe they have acquired to mine in the mountains. Through mining, they can obtain several types of items, including gems and gemstones.

The pyroxene acquired by the user can be exchanged for specific tokens. The exchange of pyroxene for specific tokens may be performed automatically, or may be performed based on the user's operation to instruct the exchange. For example, all pyroxene owned by the user may be converted into specific tokens on a regular basis. Specifically, at a predetermined time each day, all pyroxene owned by the user may be automatically converted into specific tokens, and all pyroxene owned by the user at that time may be lost. Furthermore, pyroxene may be automatically exchanged for specific tokens at a specific time, 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 specific tokens. However, specific tokens may also be granted directly to the user through mining in the mountain, in place of or in addition to the pyroxene.

In addition, 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 also 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.

Gemstones acquired by a user can be converted into NFT tokens by satisfying certain conditions. In other words, in this embodiment, NFT tokens corresponding to the gemstones can be issued and managed on the blockchain. Specifically, for example, after a user acquires a gemstone, the process of converting the gemstone into an NFT token may be initiated in response to a user operation on the acquired gemstone, or the process of converting the gemstone into an NFT token may be initiated automatically without any user operation on the acquired gemstone. For example, the operation reception unit 111 of the terminal device 10 may receive an operation by the user to select a gemstone to be converted into an NFT token within the game. Information regarding this operation is then 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 gemstone into an NFT token based on this operation. Furthermore, NFT conversion requires a fee (e.g., a predetermined amount of specific tokens), and when converting a gemstone into an NFT token through this operation, this fee may be consumed from the user's assets. Furthermore, NFT-converted gemstones may be traded on an in-game marketplace, etc. In other words, turning 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 the user selects a gem they want to sell (specifically, an NFT-converted gem). Information related to 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 may then put the gem selected by the user up for sale based on this operation. If there is another user who wishes to purchase the gem, the market management unit 214 may then transfer the gem to the other user and transfer the payment from the other user to the user who sold the gem. In other words, the NFT-converted item B may be tradeable with other users.

Gems may also be exchangeable for specific tokens. Specifically, the operation reception unit 111 of the terminal device 10 may receive an operation by the user to select the gems they wish to exchange for specific tokens in the game. Information regarding this operation is then sent to the server 20 via the transmission/reception units 112, 211, and the asset management unit 213 may grant the specific tokens to the user in exchange for the selected gems based on this operation. In other words, gems may be items that can be converted into NFTs and exchanged for specific tokens. Note that the exchange of gems for specific tokens may be possible either before or after the gems are converted into NFTs, or both.

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 to create a map, an item overview determination process to determine the 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 to create mountains, and an item detail determination process to determine the details of items that can be obtained on each mountain.

Furthermore, among the various processes in this embodiment, there is a process having randomness. In this embodiment, the process having randomness is realized by performing an operation using a predetermined seed. The predetermined seed includes a seed using a blockchain (e.g., the Bitcoin blockchain) and a seed using a virtual space ID, which will be described later, but it may include only one of them. Specifically, in this embodiment, two types of seeds using a blockchain (hereinafter referred to as "seed _hlast " and "seed _hfirst ") and one type of seed using a virtual space ID (hereinafter referred to as "seed _mdid ") are prepared.

More specifically, a seed related to the hash of a blockchain (specifically, for example, a Bitcoin blockchain) as a seed using the blockchain and a seed related to a virtual space ID are used to achieve randomness. In this embodiment, hash _{last_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 hash first_yyyymmdd+2, which is the first hash (in other words, the hash value of the first generated block) _two days after hash _{last_yyyymmdd} was generated, are used as the seeds related to the hash. Also, in this embodiment, the virtual space ID is used as the seed related to the virtual space ID. That is, in this embodiment, seed _hlast = hash _{last_yyyymmdd} , seed _hfirst = hash _{first_yyyymmdd+2} , and seed _mdid = virtual space ID.

In this embodiment, the 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 maps and various objects based on a seed is well known, an explanation of this method will be omitted.

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 the map (in other words, the virtual world) on which multiple mountains will be placed, and a process of determining the placement of each mountain on the map. Furthermore, 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 consist of one or more numbers; for example, each mountain may be assigned a consecutive number starting from 1.

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 a seed _hlast . In other words, the virtual space management unit 231 creates a map using a function in which the seed _hlast is specified as an argument. That is, the virtual space management unit 231 creates a map according to the seed _hlast (in other words, the hash of the blockchain).

In the item overview determination process, the virtual space management unit 231 determines an overview of the items that can be obtained from each mountain (in other words, the items that will 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). In other words, 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.

In this embodiment, the overview of the obtainable items (specifically, the number and size of item B) is determined randomly. In other words, the determination of the overview of the obtainable items 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 "overview determination seed"), and determines the overview of the obtainable items based on the random number. The overview determination seed includes _{seed_hlast} and _{seed_mdid} . In other words, the virtual space management unit 231 determines the overview of the obtainable items using a function in which _{seed_hlast} and _{seed_mdid} are specified as arguments. In yet other words, the virtual space management unit 231 determines the overview of the obtainable items by performing a predetermined lottery using _{seed_hlast} and _{seed_mdid} . When determining an overview of obtainable items for a mountain, the virtual space management unit 231 uses the virtual space ID of the mountain as the seed _mdid . That is, the virtual space management unit 231 determines an overview of obtainable items for each mountain based on the seed _hlast (in other words, the hash of the blockchain) and the virtual space ID of each mountain.

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 is random. 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 a seed _hlast and a seed _mdid . The virtual space management unit 231 then creates the mountain using a function in which the seed _hlast , the seed _mdid , and the summary of the obtainable item determined in the item summary determination process are specified as arguments. In other words, the virtual space management unit 231 creates mountains by conducting a predetermined lottery using the seed _hlast and seed _mdid . Note that when creating a mountain, the virtual space management unit 231 uses the virtual space ID of the mountain as the seed _mdid . Also, when creating a mountain, the virtual space management unit 231 uses the summary of the obtainable items determined for the mountain as an argument. In other words, the virtual space management unit 231 creates mountains so that each mountain corresponds to the seed _hlast (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.

In the item detail determination process, the virtual space management unit 231 determines the details of the items obtainable from each mountain, as determined in the item summary determination process. Specifically, the virtual space management unit 231 determines the type, detailed size, shape, or quality of Item B obtainable from each mountain, as determined in the item summary determination process. More specifically, for example, if the overview of 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 fine quality. The virtual space management unit 231 also determines the detailed size 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.

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 seed _hfirst and seed _mdid . The virtual space management unit 231 then determines the details of the obtainable item using a function that has as arguments seed _hfirst , seed _mdid , and the overview of the obtainable item determined in the item overview determination process. In other words, the virtual space management unit 231 determines the details of the obtainable item by performing a predetermined lottery using seed _hfirst and seed _mdid . Note that when determining details of obtainable items for a certain mountain, the virtual space management unit 231 uses the virtual space ID of the certain mountain as the seed _mdid . Furthermore, when determining details of obtainable items for a certain mountain, the virtual space management unit 231 uses the outline of the obtainable items determined for the certain mountain as an argument. That is, for each mountain, the virtual space management unit 231 determines details of the obtainable items based on the seed _hfirst (in other words, the hash of the blockchain), the virtual space ID of each mountain, and the outline of the obtainable items for each mountain determined in the item outline determination process.

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

Here, a timeline for mountain acquisition and mining will be described with reference to Figure 8. Here, an example will be described in which the last hash generated on May 29, 2022, hash _{last_20220529} , is used as the seed _hlast , and the first hash generated on May 31, 2022, hash _{first_20220531} , is used as the seed _hfirst , and a map, mountains, and obtainable items are generated.

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 determined ex post when the date of the timestamp included in a block of the blockchain changes to May 30. In other words, seed _hlast is determined when the first hash of May 30, 2022 (in other words, the first block) is generated. Therefore, in this embodiment, the virtual space management unit 231 creates a map using hash _{last_20220529} at the time when the first hash of May 30 is generated (in other words, after the hash is generated).

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 hash _{last_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 hash _{last_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 controls the period during which a mountain can be acquired. In this embodiment, the period during which a mountain can be acquired is set to the period from when the first hash of the day is generated (the seed _hlast related to the last hash of the previous day is determined) to when the first hash of the next day is generated (the seed _hfirst related to this hash is determined). In other words, the virtual space management unit 231 controls the period during which a mountain created using hash _{last_20220529} can be acquired to the period until the details of the items that can be acquired on 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 when the first hash of the day is generated to the end of that day (in other words, the day the mountain was created).

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 hash _{first_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 on 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.

In this way, the mountain (or in other words, the right to mine the mountain), whose overview and details of the obtainable items are determined, is acquired by the user based on the user's operations, and items can be obtained through mining.

When a 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 that 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).

When an operation to select a mountain to acquire is received, the display control unit 114 displays detailed information 50 about the mountains available to the user on the display unit 18, as shown in FIG. 3. For example, when the user selects a specific mountain on the map 40 that displays the mountains available to the user, the display control unit 114 displays detailed information 50 about the specific mountain on the display unit 18. In this embodiment, the detailed information 50 displays information about the gems available to acquire on the specific mountain. In other words, the detailed information 50 displays a display about the expected reward for the specific mountain. Specifically, the device processing unit 113 receives information about an overview of the items available on the specific mountain from the virtual space management unit 231, and based on that information, displays on the display unit 18 the number of gems available to acquire when mining the mountain, an overview of the size of each gem, and so on. This allows the user to view the detailed information 50 and then decide whether or not to acquire the specific mountain. That is, in this embodiment, the virtual space management unit 231 can present the user with information regarding the rewards that can be obtained by playing the game in the virtual space (in other words, detailed information 50) before the user acquires the right to play the game in the virtual space, 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 size 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 of a size corresponding to the presented size (in other words, the rewards indicated in detailed information 50) cannot be obtained.

The virtual space management unit 231 also 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, the 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 mountains 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) through 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. Additionally, in this embodiment, mountain acquisition information is stored on a blockchain that is difficult to rewrite, and the details of obtainable items are determined after the period during which the mountain can be acquired has elapsed, making it possible to more effectively prevent the unauthorized acquisition of items.

The game control unit 212 starts mining in the mountain that the user has acquired based on the user's operation to instruct the start of mining in the mountain. In the game of this embodiment, mining in the mountain is possible once 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.

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.

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 finalized 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 granting of a 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 the specified 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). 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 carried out and gems are acquired during the period during which the mountain can be acquired. The user can check the gems they have acquired on a specified screen, such as a screen that displays a list of the user's items (for example, 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 specified screen until the details of the gem are determined. Once the details have been decided, the details of the gem can be viewed on the specified screen.

In this embodiment, map creation, mountain creation (in other words, 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 of May 30th, and for items whose overviews were determined in the item overview determination process, the item detail determination process is performed using the first hash of June 1st. In this embodiment, the next map update and obtainable mountain update are performed after the mountain acquisition period has ended, but the next map update and obtainable mountain update may also occur during the mountain acquisition period. In other words, the hash 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 of the day.

In this embodiment, the hash generated at the end of the day is used to create the map and mountains and determine the overview of obtainable items. However, the hash generated at the end of the day (in other words, the last block of the day) is determined after the first hash of the next day (in other words, 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, so that the map and mountains are created and the overview of obtainable items are determined based on different hashes, and the details of obtainable items are 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 overview was determined the previous day is not the same as the hash used to determine the item overview on the current day. In other words, in this embodiment, the game control unit 212 determines item details 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 hash generated at the end of the day is used to create the map and mountains and determine an overview of the obtainable items, making it possible to perform processing using hashes (in other words, blocks) that are likely to be adopted.

In the game of this embodiment, the lottery logic for the gem as item B is stored and made public on the blockchain. Specifically, the logic for the item summary determination process and the item detail determination process is made public as a smart contract. That is, the logic for the process of determining the reward summary using seed _hlast is made public as a smart contract. Also, the logic for the process of determining the reward details using seed _hfirst is made public as a smart contract. Furthermore, seed _hlast and seed _hfirst are hashes of the blockchain and serve as public seeds. That is, in this embodiment, the summary of the items obtainable from each mountain is determined by a predetermined logic using a predetermined seed, and the predetermined seed and the predetermined logic are made public, allowing each user to verify whether any fraud has occurred in determining the item summary using the published predetermined seed and the predetermined logic. In this embodiment, the details of the 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 users to verify whether any fraudulent activity has occurred in determining the item details using the publicly available predetermined 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 by the operator and unchanging and clear to anyone. In other words, the configuration of this embodiment makes it impossible for even the operator to control the allocation of items, and users can verify the calculations using the publicly available logic, making it unpredictable in advance. This prevents fraudulent activity in the allocation of items and damage to the value of the system. In this embodiment, random numbers used to determine the outline and details of items are determined based on the blockchain hash, making the random numbers identifiable. This makes it possible to detect fraudulent activity involving random number manipulation and prevent fraudulent activity, such as the manipulation of random numbers to fraudulently cause specific objects to appear. The logic of the virtual space creation process may be stored on the blockchain and made public, or may not be stored on the blockchain and kept private.

Note that detailed information 50 about a mountain may be displayed not only when the user acquires a mountain, but also when the user selects a mountain to mine from among the mountains acquired by the user, when the user begins mining at a mountain, etc. For example, as shown in FIG. 5, when a list 44 of 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 detailed information 50 about the specific mountain to be displayed on the display unit 18. For example, 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, detailed information 50 displays an indication of the expected reward for the specific mountain. This allows the user to view detailed information 50 and decide whether or not to mine at the specific mountain. Furthermore, 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 that mountain (in other words, the degree of game progress for that mountain) calculated based on the amount of gems discovered, etc.

(Processing 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).

The process for purchasing a pickaxe will now be described. As mentioned above, pickaxes can be purchased through the in-game marketplace. A pickaxe is purchased, 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 (for example, a click 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 accepting an operation to execute the purchase and a cancel button for accepting 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 this request, the market management unit 214 of the server 20 grants the selected pickaxe to the user and executes a process to have the user pay the purchase price (in other words, a process to reduce the specific tokens held by the user by the amount of the purchase price). In other words, based on the user's operation to execute a paid transaction, the control unit 210 executes a process to have the user acquire the pickaxe as a paid transaction. Note that when a specific pickaxe is displayed as available for purchase on a user's terminal device 10, this is also referred to as the specific pickaxe being displayed in the user's shop.

Next, the process for repairing an ice axe and increasing its rank will be described. Ice axe repair and increasing its rank 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 the 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 reception 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 a specific ice axe). When a specific ice axe is selected, the display control unit 114 also receives an operation to display a UI on the display unit 18 that receives various operations for the selected ice axe. Specifically, the display control unit 114 causes the display unit 18 to display, as the UI, a repair button 65 that accepts operations related to restoring the durability of the pickaxe, an upgrade button 66 that accepts operations related to increasing the rank of the pickaxe, and a sell button 67 that accepts operations related to selling the pickaxe. Note that the item screen 64 may also display a display showing the remaining durability of the selected pickaxe or the pickaxes displayed in a list. In the example shown in FIG. 10, a meter 68 showing 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.

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 this request, the game control unit 212 of the server 20 restores the durability of the selected pickaxe and executes a process to have the user pay the cost of restoring the durability (in other words, a process to reduce the specific tokens held by the user by the cost of restoring the durability). In other words, the control unit 210 executes a process to restore the durability of the pickaxe as a paid process based on the user's operation to execute a paid process.

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 pickaxe. Based on this request, the game control unit 212 of the server 20 increases the rank of the selected pickaxe and executes processing to have the user pay the fee for the rank increase (in other words, processing to reduce the specific tokens held by the user by the amount of the fee for the rank increase). In other words, the control unit 210 executes processing to increase the rank of the pickaxe as a paid transaction based on the user's operation related to the execution of a paid transaction.

Furthermore, when the sell button 67 is operated, the control unit 110 of the terminal device requests the server 20 to list the selected ice axe 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 it to purchase the ice axe from the user (for example, by paying specific tokens). In other words, the listed ice axe will be displayed on the shop screens 60 of other users.

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, users can purchase pickaxes from the game operator and from other users. 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.

In addition, 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, as shown in FIG. 11 , based on a predetermined input operation by the user while mining is in progress (e.g., an operation on the Tab key on the keyboard). The menu screen 70 displays a pickaxe operation button 72 for accepting 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 for accepting various operations for the pickaxe owned by the user. Specifically, the display control unit 114 causes the display unit 18 to display, as part of the UI, a repair button 73 for accepting operations for restoring the durability of the pickaxe, and a switch button 74 for accepting operations for changing (in other words, switching) the pickaxe being used.

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 (e.g., the pickaxe currently in use). Based on this request, the game control unit 212 of the server 20 restores the durability of the pickaxe owned by the user and executes a process to have the user pay the price for the durability restoration (in other words, a process to reduce the specific tokens held by the user by the price 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 specific operation by the user while mining is in progress.

Furthermore, when the switch button 74 is operated, the display control unit 114 causes a list 75 of switchable ice axes to be displayed 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 that 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 that specific ice axis.

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

(Provision of ice axes)
In this embodiment, item A owned by a user can be lent to other users. In the following, a user who owns a pickaxe as item A and lends the pickaxe to another user will be referred to as an "owner." Also, a user who borrows a pickaxe from another user will be referred to as a "scalar."

Scalars can mine in the mountains using a pickaxe loaned to them 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).

Operations related to starting mining in a mountain and operations for controlling the player character to mine 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 by operating the Start Mining button 43 on the home screen 42 displayed on his or her own terminal device 10. Here, in this embodiment, the mountain where the scholar mines using a pickaxe loaned by the owner is a mountain owned by the owner. When loaning the pickaxe, the owner specifies the mountain where the pickaxe will be used to mine. Then, when the scholar mines using the pickaxe loaned by the owner, the scholar will mine in the mountain specified by the owner.

Scholars can also earn rewards by mining using a pickaxe borrowed from the owner. In this embodiment, by digging up items using the pickaxe, scholars can earn a reward equal to the scholar's share of the excavated items. 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 more detail below, 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, the scholar's terminal device 10 and the owner's terminal device 10 may display an effect in which the owner acquires all of the excavated pyroxene at once, and then distributes the pyroxene to the scholar.

In this embodiment, the scalar's share can be set by the owner, 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. In other words, 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.

In this embodiment, treasure chests are placed on the mountain in addition to gems and gemstones. When a player discovers a treasure chest, the treasure chest serves as an object that allows the player to acquire a predetermined item (specifically, equipment for the player character, such as clothing or gloves) as its contents. The game control unit 212 grants the contents of the treasure chest to the owner, whether the owner or a scholar discovers the treasure chest. In other words, the game control unit 212 adds the contents of the treasure chest to the owner's assets, whether the owner or a scholar discovers the treasure chest. The contents of the treasure chest are determined by lottery at a predetermined timing (e.g., when the treasure chest is discovered or placed). When the owner or a scholar discovers a treasure chest and the owner already possesses the contents of the treasure chest determined by lottery, the game control unit 212 grants gemstones to the owner in place of the contents of the treasure chest determined by lottery. Here, "granting pyroxene in place of the contents of the treasure chest determined by lottery" may mean that the contents of the treasure chest determined by lottery are first granted and then automatically converted into pyroxene, or that the pyroxene is granted without first going through the process of granting the contents of the treasure chest determined by lottery. In this embodiment, one treasure chest is placed per mountain, but multiple treasure chests may be placed per mountain, or there may be no treasure chests at all.

In this embodiment, there are cases where multiple scalars are assigned to one owner. In such cases, when a player character controlled by one of the multiple scalars digs up a pyroxene, each scalar is awarded a reward of an amount of pyroxene corresponding to their mining work (in other words, their game play). In this embodiment, the reward awarded to each scalar is determined based on the following rules:
When a scalar digs up a gemstone, the owner's share of the gemstone and the scalar's share are determined according to the ratio set by the owner.
-Scalar's share is shared among all scalars.
- Each scalar will be given a certain amount of gemstones from their share based on the amount of work they have done (specifically, the percentage of the mountain they have excavated).
- The workload of each scalar is calculated by dividing the durability of the pickaxe consumed by that scalar by the durability of the pickaxe 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.

Note that the specified period for calculating the workload of each scalar is the period from when the pyroxene was last discovered in the mountain until the pyroxene to be distributed is acquired. Furthermore, 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 specified period is not limited to this and can be set as appropriate.

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 scalar other than the scalar who dug up the pyroxene according to the following calculation formula, and grants the reward to each scalar.
・Reward for a scalar who excavates pyroxene = (amount of pyroxene excavated) x (reward percentage set by the owner) x (coefficient for bonus payment) x (durability of the pickaxe used by the player/durability of all pickaxes used by the scalar) + (amount of pyroxene excavated) x (percentage set by the owner) x (coefficient for bonus payment)
・Reward for scalars other than the one who dug up the gemstone = (gems dug up) x (reward rate set by owner) x (bonus payment coefficient) x (durability of pickaxe consumed by oneself / durability of pickaxe consumed by all scalars)

For example, suppose there are two scalars, Scalar A and Scalar B, and Scalar A digs up 100g of pyroxene. The owner has set the reward rate to 30% (in other words, the owner's share is set to 70%). Scalar A has used 40 of the durability of the pickaxe loaned to him by the owner, and Scalar B has used 60 of the durability of the pickaxe loaned to him by the owner. In this case, Scalar A will be awarded 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 will be awarded 100g x 0.3 x 0.95 x (60/(40 + 60)) = 17.1g of pyroxene as a reward. Additionally, the owner will receive 100g x 0.7 = 70g of pyroxene as their share.

Furthermore, as mentioned 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, one of multiple scalars who has been loaned a pickaxe by an owner digs up a pyroxene, and 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 it is dug up (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 automatically convert into specific tokens at a specific time every day, and through this conversion, each scalar (and 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.

In this manner, in this embodiment, the owner can lend a pickaxe to a scholar to find gems and pyroxenes on their behalf. That is, in this embodiment, lending a pickaxe can be rephrased 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. In other words, the owner can hire a scholar. Note that an event in which a collaborator participates using an object loaned from the owner may be one in which the goal is to defeat a predetermined opponent (here, "opponent" may be another user or an NPC. Also, an enemy character in a so-called quest may be considered an opponent), one in which the goal is to reach a predetermined destination, or one in which the goal is to obtain 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.

In addition, 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 has done, and grants the reward to each user. In this regard, in a game like this embodiment, for example, between Scalar A and Scalar B, who are loaned a pickaxe from the owner, Scalar A, who has done a lot of work, may not achieve a specific 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, may be lucky enough to achieve a specific result (specifically, a situation in which Scalar B has found a pyroxene despite digging a small amount). 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, thereby reducing the likelihood of users feeling a sense of unfairness and motivating them to actively play the game. In addition, in such cases, it is possible that Scalar B was able to discover the gemstone because Scalar A had done a lot of work, and with the configuration of this embodiment, it is possible to reward the play of a user like Scalar A.

As mentioned above, each user's reward is determined based on the amount of work they do until one of them achieves the specified result (specifically, until they discover a pyroxene). Then, when one of the users achieves the specified result again, the reward for each user is determined based on the amount of work they do from the last time they achieved the specified result until the next time they achieve the specified result. In other words, in this embodiment, when one of the users achieves the specified result, the amount of work for each user related to the reward calculation is reset, and the starting point for calculating the amount of work is changed to the time when the specified result was achieved. However, the amount of work does not have to be reset when one of the users achieves the specified result. For example, regardless of whether or not one of the users achieves the specified result along the way, each user may be awarded a reward based on the cumulative amount of work they do from the time they start mining (in other words, from the time mining becomes possible in the mine) until the reward is awarded.

In this manner, in this embodiment, when one of multiple users who participate in a specified event and who use a specific object that has been converted into an NFT achieves a specified result using the specific object in virtual space, the reward granting unit 233 determines the reward to be granted to each user according to the amount of work each user has done, 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.

In addition, in this embodiment, the workload of each user is determined based on the amount of durability consumed by the pickaxe (in other words, the amount of 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 enemy characters. Points may also be 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 that indicate, 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, to the event).

In this embodiment, the reward given to the Scholar varies depending on the achievements of the Scholar, but it is also possible to give a fixed reward regardless of the achievements.

Next, we will explain in detail about ice axe lending, referring to various signs related to ice axe lending.

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 that accepts operations related to scholarship recruitment (in other words, lending an ice axe), and an owner search button 402 that accepts operations related to applying as a scholarship (in other words, searching for an owner, or 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.

Recruitment screen 420 is a screen for performing operations related to recruiting scholars. In other words, recruitment screen 420 is a screen for performing operations related to lending out the user's own ice axe. Specifically, recruitment screen 420 allows settings to be made for the project (in other words, the event) for which a scholar is being recruited. In other words, in this embodiment, it is possible to recruit a scholar for a single project (in other words, the event) of mining in a specific mountain, and recruitment screen 420 allows settings to be made for the project for which a scholar is being recruited, such as the reward to be awarded to the scholar and the ice axe to be loaned to the scholar.

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.

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, 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, detailed information 50 about the specific mountain may be displayed, and the user may confirm the detailed information 50 before deciding 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 that click operation) as an operation to select a mountain from among the mountains owned by the user that is eligible for scholarship recruitment.

The reward setting UI 422 is a UI that accepts operations related to setting the reward for results obtained through use of the loaned pickaxe (in other words, the 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 the conditions related to the loan of the pickaxe (specifically, the conditions related to the reward). In this embodiment, the scalar's share of the results obtained through the scalar's use of 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.

The reward setting UI 422 accepts operations 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 be the scalar's share. The reward setting UI 422 may be an input field in which a number such as "30%" can be entered by operating the keyboard, or may be a pull-down menu that displays multiple selectable percentage options and allows the user to select a specific percentage from among the multiple options. The operation reception unit 111 accepts user operations on the reward setting UI 422 as operations to set a reward for other users for results achieved by other users using the pickaxe loaned by the user. In other words, the operation reception 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 specific object obtained when another user uses a pickaxe loaned by the user.

In this embodiment, the owner can set the scalar's share of the results achieved by the scalar between "0%" and "100%." If set to "0%, the owner will receive all of the pyroxene dug up by the scalar. If set to "100%, the scalar will receive all of the pyroxene dug up by the scalar.

The reward setting UI 422 may also accept an operation to set the type of item (e.g., whether to grant the scalar a gem or a gemstone) to be granted to the scalar as a reward for the scalar's achievements (in other words, the scalar's share). Furthermore, 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 scalar's achievements.

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 operations to input, as messages, the type of users to be recruited as scalars. Specifically, it may be possible to select text information to be set as messages from multiple text information such as "Beginners Welcome," "Casual Miners Welcome," "Serious Miners Only," "Experienced Miners Wanted," "Teamwork Emphasis," and "Profit Sharing." 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, it may provide an input field in which the user can enter any character string (in other words, a free comment) by operating the keyboard. The operation reception unit 111 accepts user operations on the message input UI 423 as operations to input (in other words, set) messages to be sent to users who will borrow a pickaxe from the user.

In this embodiment, the messages entered in the message input UI 423 are merely comments, and even users who do not meet the requirements set forth in the messages can apply to be a scholarship and borrow an ice axe. That is, for example, even if "Experienced people wanted" is selected as the message, beginners and experienced people can still apply to be a scholarship and borrow an ice axe. However, restrictions may be placed so that users who do not meet the requirements set forth in the messages cannot apply to be a scholarship 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 set forth in the messages from borrowing an ice axe.

The loan object selection UI 424 is a UI that accepts operations related to the selection of ice axes as objects to be loaned to scholars. 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. In other words, the loan object selection UI 424 allows the selection of up to six ice axes to be loaned to scholars. 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, by selecting a specific ice axe from the listed ice axes (e.g., by clicking on a specific ice axe), the specific ice axe is set to the selected slot 426. The ice axe set in each slot 426 is then loaned to the scholar. Note that by selecting a specific ice axe from the list of ice axes displayed, detailed information about that specific ice axe (e.g., performance, etc.) may be displayed, allowing the user to confirm the detailed information and then decide which ice axe to loan to the scholar. The operation reception unit 111 accepts user operations on the loan object selection UI 424 (e.g., a click on a slot 426 and a click on a specific ice axe from the list of ice axes displayed based on that click) as an operation to select a ice axe to loan to the scholar from the ice axes owned by the user.

When the Start Recruitment button 425 is pressed, recruitment of scholars begins according to the information entered on the recruitment screen 420. Specifically, when the Start Recruitment button 425 is pressed, recruitment begins for users (in other words, scholars) who will borrow the pickaxe selected in the Loan 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, the user's pickaxe will be loaned out. Furthermore, users who apply for this recruitment will borrow the pickaxe under the reward conditions set in the Reward Settings UI 422, and will be able to earn rewards according to the conditions set in the Reward Settings UI 422 as rewards for the results achieved by mining using the loaned pickaxe.

When the Start Recruitment button 425 is operated, the control unit 110 of the owner's terminal device 10 sends information to the server 20 regarding the mountain selected in the mountain selection UI 421, the scalar share set in the reward setting UI 422, the message entered in the message input UI 423, and the pickaxe selected in the loan object selection UI 424, and requests the server 20 to start recruiting scholars. The control unit 210 of the server 20 then starts recruiting scholars based on the information sent from the terminal device 10. Specifically, the control unit 210 starts recruiting scholars to mine by borrowing the pickaxe selected in the loan 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.

Note that "start recruitment" means that information related to the recruitment run by the user as owner is made available to be displayed on the terminal device 10 of other users (specifically, the application screen 440, described below). In other words, it means that other users are able to apply for the recruitment run by the user as 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 20 registers the recruitment corresponding to the various information input as a recruitment that can be displayed on the application screen 440 of other users.

In this embodiment, the scholar uses the loaned pickaxe on the mountain selected in the mountain selection UI 421, and the mountain selection UI 421 can also be considered a UI that accepts operations to specify the location where the loaned pickaxe is permitted to be used. In other words, the mountain selection UI 421 can also be considered a UI that accepts operations to set the conditions related to the loan of the pickaxe (specifically, the conditions regarding the location of use). When the scholar uses the loaned pickaxe to mine, the game control unit 212 controls the mining location so that it is the mountain selected in the mountain selection UI 421. In other words, the game control unit 212 determines the location where the scholar can use the loaned pickaxe based on the owner's operations on the mountain selection UI 421.

In this embodiment, the loaned pickaxe can be used in locations designated by the owner where use of the pickaxe is permitted (in other words, events set by the owner in the mountain selection UI 421), but the loaned pickaxe may also 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.

The application screen 440 is a screen for performing operations related to applying for a job posting issued by an owner. In this embodiment, a user who owns an ice axe and a mountain can, as the owner, recruit scholarship recipients, and the application screen 440 can present multiple recruitment posts made 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 job. Note that by performing a specified operation (for example, scrolling the screen in a specified direction) on the application screen 440, information about each job for which scholarship recipients are being recruited is displayed sequentially.

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

Mountain information 442 is information about the mountain that the scholar will mine if they apply for the recruitment. In other words, mountain information 442 is information about the mountain that the owner selected using mountain selection UI 421. In this embodiment, 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, 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. 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, information 442b about obtainable objects displays the expected probability of obtaining gems on that mountain. Note that information 442b about obtainable objects may also display the expected probability of obtaining pyroxene on that mountain. In other words, information 442b about obtainable objects can function as reward information 443.

Reward information 443 is information regarding the reward for the achievements of the scalar (in other words, the reward for cooperation with the owner). In other words, reward information 443 is information regarding the reward set by the owner in the reward setting UI 422. In this embodiment, reward information 443 displays the scalar's share set in the reward setting UI 422 (specifically, the proportion of the pyroxene mined by the scalar that will be awarded to the scalar).

Lend object information 444 is information about the ice pick as an object loaned to the scholar. In other words, lend object information 444 is information about the ice pick selected by the owner in the lend object selection UI 424. In this embodiment, the lend object information 444 displays, for each ice pick selected in the lend object selection UI 424, an image of the ice pick, the name of the ice pick, an ID that identifies each ice pick (in other words, identification information), and information related to the ice pick's durability (for example, an indication of the remaining durability).

Additional information 445 is additional information about the case. In this embodiment, the additional information 445 displays the message entered by the owner in the message input UI 423.

The image of each ice axe in the loan 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 reception unit 111 accepts an operation to select the ice axe to borrow from among the multiple ice axes (specifically, ice axe images) displayed on the application screen 440 (for example, 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 the ice axe to borrow is selected, the display control unit 114 displays a dialog 448 on the display unit 18 to confirm whether to proceed with borrowing the selected ice axe. The dialog 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's use of the loaned pickaxe. Specifically, the game control unit 212 prevents the owner from mining using the loaned pickaxe. The process of restricting the use of a loaned pickaxe may be, for example, a process of making it impossible to select the loaned pickaxe as the pickaxe to be used for mining, or a process of not accepting operation of the start mining button 43 when the loaned pickaxe has been selected as the pickaxe to be used for mining.

If loan information is stored, the game control unit 212 causes the scholar to begin mining using the loaned pickaxe based on a specified operation by the scholar. For example, the game control unit 212 causes the scholar to begin 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 begin mining at the mountain selected in the mountain selection UI 421 by the owner who loaned the pickaxe. 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 input operations by the scholar. The scholar can perform mining by moving the player character within the virtual space and swinging the loaned pickaxe in the same way as when the owner performs mining.

On the application screen 440, if an ice axe selected by the owner to lend has already been borrowed by another user, a borrowed icon 449 will be displayed indicating that the ice axe is currently borrowed by another user. Ice axes that have the borrowed icon 449 displayed cannot be borrowed. In other words, a single ice axe cannot be lent to multiple users at the same time.

In this embodiment, a scholar can borrow a pickaxe from an owner in advance and start or stop mining at any time. That is, by selecting a specific pickaxe on the application screen 440, the scholar who has been loaned that specific pickaxe can operate the Start Mining button 43 at any time to begin mining using that specific pickaxe in a specific mountain. Furthermore, the scholar who has been loaned that specific pickaxe can end mining by performing an operation to exit that specific mountain (e.g., operating the Exit button 71), or resume mining using that specific pickaxe in that 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 currently on loan from the owner (e.g., 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 completed (in other words, interrupted), the pickaxe may be automatically returned to the owner.

As described above, in this embodiment, an owner can recruit up to six scholars for each mountain they own and lend them 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, these 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 the user's own player character moving and digging the mountain in response to the user's operation, the terminal device 10 also displays the player characters of other users moving and digging the mountain in response to the operations of the other users. Furthermore, the game control unit 212 imparts predetermined changes to the specific mountain based on user B's operation (for example, changes such as the mountain being worn down by mining or an item being placed by using an item), and also imparts predetermined changes to the specific mountain based on user C's operation (for example, changes such as the mountain being worn down by mining or an item being placed by using an item). 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 point in the specific mountain that is likely to contain gems or pyroxene.

Furthermore, if user B and user C have been loaned a pickaxe by user A as the owner, user A can also start mining on 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 with user B and user C. That is, the game control unit 212 places user A's player character and user B and user C's player characters on the specific mountain, and moves each player character based on the operation of each user.

In this way, 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 be progressed through multiplayer.

When recruiting scholarships, the owner may be able to limit the users to whom the scholarship is to be recruited. For example, the recruitment screen 420 may display a UI that accepts operations related to limiting the users to whom the scholarship is to be recruited, and the users to whom the scholarship is to be recruited may be limited based on operations on the UI. In other words, the operation receiving unit 111 may accept an operation by the owner to limit the users to whom the scholarship is 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 the recruitment to users who have a specified friendship relationship with the owner, such as the owner's friends, stored in the memory unit 220. The target limiting operation may also accept an operation to limit the targets of the recruitment to only users specified by the owner (for example, specified by information that can identify the user, such as a user ID or username). When the users eligible for the recruitment are limited, information related to the recruitment will be displayed on the application screen 440 on the terminal device 10 of the eligible users, allowing them to apply, but information related to the recruitment will not be displayed on the application screen 440 on the terminal device 10 of non-eligible users, and they will not be able to apply.

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. In other words, 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 a specified number of users (here, six) pickaxes for use on that specific mountain. Specifically, if the owner has lent a specified number of users (here, six pickaxes) for use on that specific mountain, the game control unit 212 controls so that the owner is prevented from mining on that specific mountain. Here, "restricting use based on whether the pickaxe 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 pickaxe (in other words, when the user is actually mining), restricting use regardless of whether the specified number of users are using the loaned pickaxe, or restricting use regardless of whether the specified number of users have actually borrowed the pickaxe (in other words, restricting use from the point at which applications are initiated by selecting the specified number of pickaxes in the loan object selection UI 424). In this embodiment, when an operation to select a sixth pickaxe 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 pickaxes, the user (i.e., the owner) will no longer be able to mine in the mountain to which the pickaxe is loaned.

In this embodiment, the game control unit 212 performs processing to restrict the use of specific abilities available to a scholar using a pickaxe loaned by the owner when the owner mines using the pickaxe. 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 include a bomb 77, a ladder 78, a spray 79, and a marker 80. Using the bomb 77 can destroy the ground surface (i.e., rocks) and dig into the mountain. Using (or placing) the ladder 78 allows the player to move to higher or lower areas. Using the spray 79 allows the player to draw shapes or letters on the mountain. Using (or placing) the marker 80 allows the player to mark specific points on the mountain. The marked points (i.e., the points where the marker 80 is placed) are displayed on the in-game map. The special item 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 a pickaxe to a specific special item, and then performing a left-click operation on the mouse. The game control unit 212 enables the use of a bomb 77 when the owner mines using the pickaxe. That is, the game control unit 212 places the bomb 77 on the mountain and explodes the bomb based on the operation to change the item held by the player character to the bomb 77 or the left-click operation on the mouse after performing that operation. On the other hand, the game control unit 212 disables the use of the bomb 77 when a scholar mines using a loaned pickaxe. That is, the game control unit 212 does not execute a process to place the bomb 77 on the mountain or an operation to explode the bomb 77 based on the operation to change the item held by the player character to the bomb 77 or the left-click operation on the mouse after performing that operation. Note that restrictions on the use of abilities are not limited to making the ability unusable, but may also, for example, reduce the number of times the ability can be used.

The loan-related screen 400 displays information about the user's own ice axe lending and borrowing. Specifically, as shown in FIG. 12, the loan-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 specific operation (for example, an operation on the arrow button 410 shown in FIG. 12), the loan-related screen 400 sequentially displays information about each project for which the user is lending or borrowing their ice axe.

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 identifies each mountain. Mountain information 405 can also be thought of as information that indicates the event in which the scholar will play using the loaned pickaxe.

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

Reward information 407 is information regarding the reward for the scalar's achievements (in other words, the reward for cooperation with the owner). In this embodiment, reward information 407 displays the scalar's share set by the owner (specifically, the percentage of the pyroxene mined by the scalar that will be awarded to the scalar).

Additional information 408 is additional information about the case. In this embodiment, additional information 408 displays information entered by the owner to be communicated to the scholar.

Lend object information 409 is information about objects loaned to the scalar. In this embodiment, for a pickaxe loaned to a scalar, the lend object information 409 displays 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, achievement information 409b displays the number of gems and gemstones the scalar has discovered by using the pickaxe.

Here, the loan-related screen 400 displayed on the owner's terminal device 10 (in other words, for a project 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 project in which the owner has loaned an ice axe) displays only loaned object information 409 for the ice axe loaned to the scholar, and does not display loaned object information 409 for ice axes loaned to other users. That is, for example, if user A, as the owner, has loaned ice axes to users B and C, user A's terminal device 10 displays both loaned object information 409 for the ice axe loaned to user B and loaned object information 409 for the ice axe loaned to user C, as illustrated in FIG. 12. Meanwhile, 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.

The loan-related screen 400 also displays a cancel button 415 as a UI that accepts operations related to terminating the contract between the owner and the scholar (in other words, ending the loan of the pickaxe, or in other words, terminating the cooperative relationship). When the owner or scholar operates the cancel button 415 on their own terminal device 10, the contract is terminated and the pickaxe loaned to the scholar 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 this request, the control unit 210 of the server 20 executes processing to terminate the relationship between the owner and the scholar and return the pickaxe loaned to the scholar 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 scholar to no longer be able to use the pickaxe to mine. In this embodiment, the cancel button 415 is displayed on both the owner's and the scalar's terminal device 10, and the owner and scalar can cancel the contract by operating the cancel button 415.

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 the cancellation button 415 is operated on one user's 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 a predetermined operation performed on the other user's terminal device 10 to agree to the contract cancellation. Also, 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.

In addition, in this embodiment, only the owner of the pickaxe can restore the durability of the pickaxe, and not a scholar. A scholar who wishes to restore the durability of a pickaxe loaned to them by the owner can request that the owner restore the durability, and the owner will then restore the durability.

As described above, the display control unit 114 of the terminal device 10 can 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 displays a repair button 65 that accepts operations related to restoring the durability of the specific ice axis, as described above. However, if the specific ice axis is one loaned by the owner (in other words, another user), the display unit 18 displays a repair request button (not shown) that accepts operations related to restoring durability instead of the repair button 65 (see FIG. 10).

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 requested," 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. This notification may also be made by displaying an icon 502 informing the owner of the request on a UI that accepts specific 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 messages such as a message informing the player that they (i.e., the owner) or another user participating in multiplayer (i.e., a scholar) have discovered a specific object (e.g., a gem or pyroxene), a message informing the player that another user has entered the mountain where the player is mining, or a message informing the player that the durability of the pickaxe they are using has decreased by a specific amount.

Furthermore, a request from a scalar to restore the durability of a pickaxe 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 scalar's operation, the display control unit 114 of the scalar's terminal device 10 may display the repair request button, which accepts operations related to the request to restore durability, on the display unit 18 instead of the repair button 73 (see FIG. 11).

Then, the owner who received the request performs a predetermined operation to restore the durability of the pickaxe they are lending 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), thereby restoring the durability of the pickaxe. That is, 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. Based on this 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 the price for the restoration of the durability (in other words, a process to reduce the specific tokens owned by the owner by the price of the restoration of the durability). That is, 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 the restoration of the durability of the pickaxe. Note that the owner's operation to instruct the recovery of the durability of the pickaxe may be executable both when the owner is mining and when he or she is not, or may be executable only when he or she is mining.

It should be noted 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 a request for durability recovery by a scalar, the control unit 110 of the scalar's terminal device 10 may be controlled to not accept any further operations related to the request for durability recovery by that scalar for a predetermined period of time (e.g., 60 minutes).

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

In addition, as shown in FIG. 10, the item screen 64 may display a display 505 that allows the user to recognize ice axes that have been loaned to other users, or a display 506 that allows the user to recognize ice axes that have been loaned to them by other users.

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 one from another user, but it may be possible for a user who owns an ice axe to not be able to borrow one from another user. Also, a user who owns only one ice axe may or may not be able to lend it to another user.

In this embodiment, the scholar can play a specified event (in other words, a specified game) using a pickaxe as a specified object loaned to him by the owner, but the specified object may be an item other than a pickaxe. For example, if the specified event is an event in which the scholar competes against an opponent, the specified object may be an item that can be used in the competition. The specified object may also be a character (for example, a character controllable by the user) used to progress through the specified event. In this embodiment, the specified object is set to a durability value as a specified parameter that changes depending on the use of the pickaxe, and is restored based on a specified operation by the owner, but the specified parameter may also be hit points or the like as a durability value when the specified object is a character. The specified parameter is not limited to durability, as long as it changes depending on the use of the specified object.

(Operations when contract is terminated)
In this embodiment, the control unit 210 establishes a predetermined relationship (specifically, an owner-scalar relationship, or in other words, an employment relationship or a cooperative relationship) between the first user and the second user. In other words, the control unit 210 concludes a contract between the owner and the scalar. Furthermore, the control unit 210 terminates the predetermined relationship between the first user and the second user based on a predetermined operation by the first user or the second user. In other words, the control unit 210 terminates the contract between the owner and the scalar based on a predetermined operation by the owner or the scalar. Note that establishing a predetermined relationship between the first user and the second user can also be considered to store information indicating that the first user and the second user have a predetermined relationship in the storage unit 220. Furthermore, dissolving the predetermined relationship between the first user and the second user can also be considered to erase information indicating that the first user and the second user have a predetermined relationship from the storage unit 220.

A scalar can affect (in other words, act on) an object owned by the owner (specifically, a mountain) while a contract with the owner is in place (in other words, while a specified relationship is established). In other words, a scalar cannot affect (in other words, act on) an object owned by the owner (specifically, a mountain) while a contract with the owner is not in place (in other words, when a specified relationship is not established). There are two types of influences a scalar can have on an object owned by the owner: a first influence and a second influence.

The first effect may be an effect that transforms an object owned by the owner. In this embodiment, the scalar is able to dig into a mountain owned by the owner, and by digging, he is able to transform part of the mountain (in other words, to make it look like it has been cut down). That is, the first effect may be an effect that is caused by the scalar using a first item. In this embodiment, the first item is a pickaxe. The first effect may also be an effect that is caused by the scalar performing a first operation (for example, an operation that transforms an object owned by the owner). In this embodiment, the first operation is an operation to dig into a mountain.

The second effect may be the effect that the scalar has by using a second item (e.g., a special item).

For example, a scalar can use a ladder 78 as a second item in a mountain owned by the owner, and by using the ladder 78, the ladder 78 can be placed on the mountain (in other words, the point where it was used). The control unit 210 places the ladder 78 on the mountain based on the operation of using the ladder 78 by a scalar who is mining in the mountain owned by the owner. In other words, the second effect may be the effect of placing (in other words, adding) the ladder 78 as a specific object on an object owned by the owner. The second effect may also be the effect exerted by the scalar through a second operation (for example, an operation of using a second item or an operation of adding a specific object to an object owned by the owner).

Furthermore, for example, a scalar may be able to use a spray 79 (in other words, a writing implement) as a second item on a mountain owned by the owner, and may use the spray 79 to draw (in other words, attach) shapes or letters on the mountain (in other words, the point where it was used). The control unit 210 may attach shapes or letters drawn with the spray 79 to the mountain based on the operation of a scalar using the spray 79 while mining on the mountain owned by the owner. The second effect may be an effect in which a specific object, such as a shape or letter drawn with the spray 79, is added to an object owned by the owner. In other words, the second effect may be an effect exerted by a scalar through a second operation (for example, an operation to draw a specific object on an object owned by the owner).

Furthermore, for example, a scholar may be able to use a marker 80 as a second item in a mountain owned by the owner, and may use the marker 80 to mark a specific point on the mountain. Specifically, a scholar may use the marker 80 to place the marker 80 at a specific point on the mountain (in other words, to place a pin). Based on the operation of a scholar using the marker 80 while mining in the mountain owned by the owner, the control unit 210 places the marker 80 at the point on the mountain where the marker 80 was used (in other words, marks the point). The second effect may be an effect of marking an object owned by the owner. The marked point (in other words, the point where the marker 80 was placed) may be shown on an in-game map (e.g., a map used by the scholar who performed the marking). In other words, marking can be said to impart a specific attribute to a specific point on an object owned by the owner. In other words, the second effect may be an effect of imparting a specific attribute to an object owned by the owner. In addition, the marked points may not simply be shown on an in-game map; by selecting a marked point on the map, the player character of the operating user may be automatically moved to the selected point.

The impact of a scalar on an object owned by the owner can be recognized by the owner. Furthermore, the impact of a scalar on an object owned by the owner is also recognized by scalars other than the scalar who affected it. In other words, when one of multiple scalars mining a specific mountain owned by the owner affects that specific mountain, the impact is reflected in the play environment of the owner and other scalars and is recognized by the owner and other scalars. Specifically, when a scalar excavates a mountain, the portion excavated by that scalar appears excavated on the owner's screen and the screens of other scalars. Furthermore, for example, when a scalar places a ladder 78 on a mountain, the ladder 78 appears to be placed in the location where the scalar placed the ladder 78 on the owner's screen and the screens of other scalars. Note that the ladder 78 placed by that scalar may be usable by the owner or other scalars (e.g., the ladder 78 may be able to be ascended or descended), or it may be unavailable to the owner or other scalars. Furthermore, for example, when a scalar paints a shape or letter on a mountain with spray paint 79, the shape or letter drawn by that scalar may also appear on the owner's screen and the screens of other scalars. Furthermore, for example, when a scalar marks a specific point on a mountain, the marked point may also be shown on maps used by the owner and other scalars. Furthermore, the owner and other scalars may also be able to automatically move their own player characters to the selected point by selecting a point marked by that scalar.

The control unit 210 erases a specified influence that the second user had on an object owned by the first user during a period in which a specified relationship was established between the first and second users, based on the termination of the specified relationship between the first and second users. Specifically, the control unit 210 erases a second influence that the scalar had on an object owned by the owner during a period in which a relationship between the owner and scalar was established, based on the termination of the relationship between the owner and scalar. At this time, the control unit 210 erases the second influence, while leaving intact the first influence that the scalar had on an object owned by the owner during the period in which the relationship between the owner and scalar was established.

Specifically, when a contract is terminated based on the owner or scalar operating the cancellation button 415, the control unit 210 erases the second influence of the influence on the mountain that the scalar whose contract was terminated has had, but not the first influence.

More specifically, when the relationship between the owner and scalar is dissolved, the control unit 210 removes the ladder 78 placed on the mountain owned by the dissolved scalar from the mountain. As a result, the ladder 78 will no longer appear on the screen of the owner or other scalars mining on the mountain. Furthermore, in a configuration in which the owner or other scalars can use the ladder 78 placed by the scalar, the ladder 78 placed by the scalar will no longer be usable by the owner or other scalars.

Furthermore, when the relationship between the owner and the scalar is dissolved, the control unit 210 erases from the mountain any figures or letters that the disbanded scalar has drawn with spray paint 79 on the mountain owned by the owner. As a result, the figures, letters, etc. drawn by the scalar will no longer appear on the screens of the owner or other scalars mining in the mountain.

Furthermore, when the relationship between the owner and the scalar is dissolved, the control unit 210 erases the marker 80 that the dissolved scalar placed on the mountain owned by the owner. In other words, when the relationship between the owner and the scalar is dissolved, the control unit 210 returns the points marked by the dissolved scalar to an unmarked state. As a result, the marker 80 placed by the scalar will no longer appear on the screens of the owner or other scalars mining in the mountain. Furthermore, in a configuration in which the owner or other scalars can automatically move their own player characters to points marked by the scalar, the owner or other scalars will no longer be able to automatically move their own player characters to points marked by the scalar. In other words, when the relationship between the owner and the scalar is dissolved, the control unit 210 removes specific attributes that the dissolved scalar placed on objects owned by the owner.

On the other hand, even if the relationship between the owner and the scalar is dissolved, the control unit 210 leaves the portions of the mountain owned by the owner that were excavated by the disbanded scalar in their excavated state. In other words, even if the relationship between the owner and the scalar is dissolved, the portions of the object owned by the owner that were transformed by the disbanded scalar will remain in their transformed state. Furthermore, in this embodiment of the game, the game (or in other words, the event) progresses by digging into the mountain, and the degree to which the mountain has been excavated can correspond to the progress of the game. In other words, "not erasing the first influence exerted by the scalar" can be interpreted as meaning that the portions of the game that the scalar has advanced will remain in their advanced state and will not be returned to their state before the advancement.

The control unit 210 can also be said to erase from the virtual space items used by the second user in the virtual space (in other words, items placed in the virtual space) during the period in which a predetermined relationship was established between the first user and the second user, based on the termination of the predetermined relationship between the first user and the second user. Here, the control unit 210 may erase from the virtual space all of the items used by the second user in the virtual space during the period in which a predetermined relationship was established between the first user and the second user, or may leave some of the items. In other words, erasing the influence that the second user had on objects owned by the first user may include erasing objects that the second user added to objects owned by the first user.

Furthermore, the control unit 210 can be said to erase from the virtual space the effects of items used by the second user in the virtual space during the period in which a predetermined relationship was established between the first user and the second user (for example, the effect of allowing passage through (in other words, ascending or descending) a predetermined location by placing a ladder 78, the effect of shapes or letters drawn with a spray paint 79 appearing, or the effect of points marked with a marker 80 being displayed on a map, etc.) based on the termination of the predetermined relationship between the first user and the second user. Here, the control unit 210 may erase from the virtual space all of the effects of items used by the second user in the virtual space during the period in which a predetermined relationship was established between the first user and the second user, or may leave some of the effects intact. In other words, erasing the influence that the second user had on objects owned by the first user may include erasing the effects of items used by the second user.

In this embodiment, a scalar whose contract has been terminated will no longer be able to enter the owner's mountain. In other words, a scalar can enter the owner's mountain only if the contract with the owner has been concluded. Furthermore, while the scalar is in the mountain (in other words, while an event based on the contract with the owner is in progress), the contract may be terminated based on the owner's operation. In this case, the control unit 210 will forcibly remove the scalar whose contract has been terminated from the mountain. The timing of the forced removal may be immediately after the owner performs the operation related to the contract removal, or may be after a predetermined time has passed since the operation. In this embodiment, when a scalar leaves the mountain based on the termination of the contract (in other words, when the scalar is forcibly removed), the control unit 210 erases the specified influence that the scalar has had on the mountain. However, when a scalar leaves the mountain without terminating the contract (specifically, when the scalar leaves based on the operation of the Exit button 71), the control unit 210 does not erase the specified influence that the scalar has had on the mountain. Specifically, when a scalar exits the mountain by operating the exit button 71, the ladder 78 or the like that the scalar placed on the mountain remains placed, and after the scalar leaves the mountain, the owner, another scalar, or the scalar who re-enters the mountain can use the ladder 78. In other words, when the control unit 210 ends (in other words, forcibly ends) the progress of an event by a scalar based on the termination of the contract, it erases the specified influence that the scalar had on the mountain, but when the control unit 210 ends (in other words, interrupts) the progress of an event by a scalar without the termination of the contract, it does not erase the specified influence that the scalar had on the mountain.

According to this embodiment, when the specified relationship is dissolved, at least a portion of the influence that the second user had on the objects owned by the first user disappears, thereby removing traces of the second user. From the first user's perspective, if traces of the second user remain after the specified relationship is dissolved, this may interfere with subsequent gameplay, or the first user may feel uncomfortable if the relationship between the first user and the second user is not good. On the other hand, if traces remain on objects owned by another user after the specified relationship is dissolved, the second user may feel that they have been taken advantage of, or may feel uncomfortable about the traces themselves. This embodiment solves these problems. Furthermore, while there is a possibility that the second user may abuse the ability to influence objects owned by the first user during the period in which the specified relationship is set, and harass the first user, the configuration of this embodiment allows the effects of harassment to be erased by dissolving the specified relationship.

Furthermore, in this embodiment, a large number of users can influence an object owned by the first user. Specifically, in this embodiment, the owner can simultaneously employ a maximum of six scholars. However, dismissing a scholar restores the employment limit, making it possible to dismiss a scholar and hire another user as a scholar. Therefore, the number of users who can influence a single mountain object (or, in other words, a single virtual space) owned by the owner is virtually unlimited. Therefore, even if there is a limit on the number of specific objects (e.g., the number of ladders 78) that a single user can add to an object owned by the owner, if no measures are taken, there is a risk that the number of specific objects added to a single object owned by the owner will become enormous. Furthermore, if the number of specific objects added becomes enormous, it may interfere with gameplay or place an excessive load on the server 20 and terminal device 10. In this embodiment, these problems can be resolved by causing at least some of the objects added by the second user with whom the specified relationship has been terminated to disappear when the specified relationship has been terminated.

Furthermore, when a specified relationship between a first user and a second user is terminated, the control unit 210 will grant the second user a reward based on the second user's work in the virtual space during the period in which the specified relationship was established. Specifically, as described above, in this embodiment, the scalar is granted a reward of an amount of pyroxene based on his or her own mining work (specifically, his or her work in the owner's mountain), but even after the contract between the owner and the scalar is terminated, the scalar will be granted a reward of an amount of pyroxene based on the mining work he or she performed during the contract.

For example, as mentioned above, if one of multiple scalars under contract with the owner digs up a gemstone, the scalars other than the one who dug it up will be awarded a reward determined according to the following formula:
・Reward for scalars other than the one who dug up the gemstone = (gems dug up) x (reward rate set by owner) x (bonus payment coefficient) x (durability of pickaxe consumed by oneself / durability of pickaxe consumed by all scalars)

Here, each scalar is awarded a reward determined according to the formula, even if their contract with the owner is terminated. In other words, the term "scalar" in the formula includes scalars whose contracts have already been terminated at the time the pyroxene is mined (in other words, at the time the reward is awarded). For example, suppose there are two scalars, Scalar A and Scalar B, who are under contract with a certain owner. Furthermore, suppose that Scalar A and Scalar B each performed mining work in a mountain owned by the owner while under contract with the owner. In this case, suppose that the contract between the owner and Scalar A is terminated, and then Scalar B, who is under contract with the owner, mines pyroxene in the mountain owned by the owner. At this time, although Scalar A's contract with the owner has already been terminated, Scalar A is awarded a reward based on Scalar A's work during the contract (in other words, the amount of work and contribution during the contract). In other words, for Scalar A whose contract with the owner has been terminated, the reward granting unit 233 determines a reward according to the aforementioned formula at a specific opportunity after the contract with the owner is terminated (for example, when Scalar B digs up pyroxene), and grants the reward to Scalar A (and Scalar B).

In this embodiment, contract termination can be performed either based on a request from the owner or a request from the scalar. The reward granted to the scalar after the contract is terminated (specifically, the reward based on the scalar's work during the contract) is calculated according to the aforementioned formula, regardless of whether the contract is terminated based on a request from the owner or a request from the scalar. In other words, the method for determining the reward for a scalar whose contract is terminated (in other words, the determination logic) is the same when the contract is terminated based on a request from the owner and when the contract is terminated based on a request from the scalar. However, the method for determining the reward for a scalar whose contract is terminated based on a request from the owner may differ from the method for determining the reward for a scalar whose contract is terminated based on a request from the owner. For example, the reward granting unit 233 may control the reward for a scalar whose contract is terminated based on a request from the scalar so that the reward is lower when the contract is terminated based on a request from the scalar than when the contract is terminated based on a request from the owner. Here, "low reward" includes the case where the lower reward is zero.

In this embodiment, when a predetermined relationship between a first user and a second user is terminated, the reward granting unit 233 grants a reward to the second user at a predetermined timing after the termination of the relationship, based on the work of the second user during the period when the predetermined relationship was established. Here, the predetermined timing may be when at least one of the first user and another user who has established a predetermined relationship with the first user achieves a predetermined result. The predetermined result may also be the discovery of a predetermined object such as a gemstone or a jewel, the defeat of an enemy character, or the completion of an event. In other words, when a predetermined relationship between a first user and a second user is terminated, the reward granting unit 233 may grant a reward to the second user based on the work performed during the period when the relationship was established, triggered by the achievement of a predetermined result by at least one of the first user and another user who has established a predetermined relationship with the first user. The reward granted to the second user can also be considered a reward based on the action the second user performed on an object (specifically, a mountain) owned by the first user during the period when the relationship was established. Furthermore, the reward granted to the second user can also be considered a reward based on the effect the second user had on a specific object (specifically, a mountain) using an object (specifically, a pickaxe) owned by the first user during the period in which the relationship was established.

In this embodiment, a second user whose specified relationship with a first user has been dissolved is granted a portion of the results of the event in which the second user participated, based on the second user's efforts; however, the rewards granted based on the second user's efforts are not limited to this. For example, the value owned by the first user (e.g., electronic currency or items in an amount based on the second user's efforts) may be granted as a reward based on the second user's efforts. Furthermore, a portion of the reward for clearing an event (e.g., a reward granted to a member who clears an event) may be granted as part of the results of the event, based on the second user's efforts.

Furthermore, compensation according to work may mean that the content of the compensation (for example, the amount or type of compensation) changes depending on the work, and there are no particular limitations on the specific logic (for example, calculation formula, etc.) used to determine the compensation.

In this embodiment, when a specified relationship between a first user and a second user is terminated, a reward based on the second user's work during the period in which the specified relationship was established is granted to the second user at a specified time after the relationship is terminated, but the reward granted to the second user may be constant regardless of the second user's work during that period.

In this embodiment, if one of multiple scalars under contract with the owner digs up a pyroxene, all scalars other than the one who dug it up will be awarded a reward determined according to the above-mentioned formula, even if they are leaving the mountain when the pyroxene is dug up.

The control unit 210 also prevents, for a predetermined period of time, a second user whose specified relationship with a first user has been terminated from exerting an effect (in other words, a predetermined influence) on objects owned by the first user that the second user was able to exert an effect (in other words, a predetermined influence) on while the specified relationship was in place. Specifically, the control unit 210 controls a scalar whose contract with an owner has been terminated to prohibit the second user from re-entering a contract with the owner (in other words, re-establishing a specified relationship) for a predetermined period of time. More specifically, the control unit 210 may control a scalar whose contract with an owner has been terminated to prevent the owner's recruitment from being displayed on the application screen 440 of the scalar's terminal device 10 for a predetermined period of time. The control unit 210 may also control a scalar whose contract with an owner has been terminated to display the owner's recruitment on the application screen 440 of the scalar's terminal device 10 for a predetermined period of time, but not to be able to apply. In other words, the control unit 210 restricts a scalar whose contract with an owner has been terminated from borrowing an ice axe from the owner for a predetermined period of time. For example, if an owner owns multiple mountains, including a first mountain and a second mountain, the control unit 210 may prohibit a scalar whose contract for mining in the first mountain has been terminated from making a contract for mining in the first mountain for a certain period of time, while not prohibiting a contract for mining in the second mountain, or may prohibit contracts for mining in all mountains owned by the owner. In other words, the control unit 210 may be able to restrict, for a certain period of time, the second user's ability to exert influence (i.e., a specified influence) on a specific mountain on which the second user was able to exert influence (i.e., a specified influence) during the period in which the specified relationship was established. Furthermore, the control unit 210 may not restrict a scalar whose contract with the owner has been terminated from re-entering a contract with the owner, but may instead prohibit the scalar from entering the mountain for a certain period of time even if the scalar re-enters a contract with the owner, or may prohibit the scalar from using specified items such as a pickaxe or special item.

In this embodiment, a second user whose specified relationship with a first user has been terminated is given a reward based on the work they did during the period the specified relationship was in place, preventing the second user from doing unnecessary work. Specifically, this prevents the owner from abusing the contract cancellation function and forcing the scholar to work for free, thereby improving the scholar's satisfaction. Furthermore, since the second user is given a reward based on the work they did, it prevents the second user from engaging in malicious behavior against the first user in retaliation for being forced to do unnecessary work.

Furthermore, in this embodiment, a second user whose specified relationship with a first user has been dissolved is unable to act (in other words, have a specified influence) on objects owned by the first user for a specified period of time. This prevents the second user whose specified relationship with the first user has been dissolved from harassing or stalking the first user after the specified relationship has been dissolved, thereby improving the interest of the service.

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

The virtual space management unit 231 acquires the hash generated at the end of each day from a specific blockchain (step S1). Next, the virtual space management unit 231 performs calculations using the acquired hash as a seed (specifically, seed _hlast ) to 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 that enables the mountain to be identified.

Next, the virtual space management unit 231 determines an outline of obtainable items for each mountain on the map created in step S2 (step S3). Specifically, the virtual space management unit 231 performs calculations using the hash obtained in step S1 and the virtual space ID of each dungeon as seeds (specifically, seed _hlast , seed _mdid ) to determine the number of obtainable items for each mountain and an outline of the size of each item.

Next, the virtual space management unit 231 creates a pile where the items whose outlines were determined in step S3 can be obtained (in other words, where the items are arranged) (step S4). Specifically, the virtual space management unit 231 performs calculations using the hash obtained in step S1 and the virtual space ID of each pile as seeds (specifically, seed _hlast , seed _mdid ) to create the piles.

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 reward details for each mountain on the map created in step S2 (step S6). Specifically, the virtual space management unit 231 performs calculations using the hash acquired in step S5 and the virtual space ID of each mountain as seeds (specifically, seed _hfirst , seed _mdid ) to determine the type, detailed size, shape, or quality of item B, an item that can be acquired from each mountain.

Next, an example of the process for acquiring a mountain and mining in the mountain will be explained with reference to the flowchart shown in Figure 16.

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

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

The operation reception unit 111 also receives an operation to instruct the user to start mining in the mountain that the user has acquired (step S13). In other words, the operation reception 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.

The game control unit 212 also starts mining based on a user operation instructing the user to start 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 a user operation instructing the user to start playing a game in that specific virtual space. The game that is started may be one that is progressed manually by the user operating a player character, etc., or may be one that is progressed automatically by the game control unit 212 without user operation. Specifically, for example, the player character may automatically mine, and the gems, etc. that the player character unearths may be given to the user as a reward. The user may also be able to select whether to progress the game manually or automatically.

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 gems or pyroxene to the user based on the mining in the mountain.

Next, an example of the process of lending a pickaxe, a specific object owned by an owner, to another user will be explained with reference to the flowchart shown in Figure 17.

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

The control unit 110 of the owner's terminal device 10 then transmits to the server 20 information indicating the ice axe to be lent to the other user selected by the owner, as well as information indicating the conditions for lending the ice axe set by the owner, and requests the server 20 to begin recruiting users 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 begin recruiting users based on the various information entered on the recruitment screen 420.

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.

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 an operation to display the application screen 440, which displays available ice axes (specifically, ice axes that can be lent by the owner to the scholar, in other words, ice axes that can be borrowed by the scholar) (step S24).

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

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 available ice axes registered in the memory unit 220 to the terminal device 10 (step S26).

Next, the control unit 110 of the scholar candidate's terminal device 10 causes the display unit 18 to display the application screen 440, which displays the available ice axes registered in the memory unit 220, based on the information on 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 memory unit 220, and the application screen 440 also displays the conditions for lending the available ice axes. The information on available ice axes transmitted from the server 20 may be transmitted to the scholar candidate's terminal device 10 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.

Next, the control unit 110 of the scholarship candidate's terminal device 10 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).

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

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

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

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

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 the scalar's player character digs up a location in the mountain where pyroxene is buried. When the pyroxene is dug up, the game control unit 212 determines that the scalar has discovered a pyroxene.

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 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 each scalar's share according to the aforementioned formula and grants each scalar the amount of pyroxene corresponding to their share. The game control unit 212 also determines the share of scalars whose contracts with the owner have already been terminated according to the aforementioned formula and grants each scalar the amount of pyroxene corresponding to their share.

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 for various processes may be hashes from the same blockchain, or may be hashes from other blockchains. Existing blockchains, such as Ethereum and Bitcoin, may also be used. NFTs corresponding to item A and item B (in other words, NFTized objects) may be able to be bridged from the blockchain on which they were issued to other blockchains.

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.

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

<Additional Notes>
The configuration of this embodiment may be used to, for example, improve the interest of a service. The matters described in the above embodiment may also be written as in the following supplementary notes.

(Appendix 1-1)
Computer,
A setting means (for example, the control unit 210) for setting a predetermined relationship between a first user and a second user;
a cancellation means (e.g., a control unit 210) that cancels the predetermined relationship between the first user and the second user based on an operation by the first user;
A program that functions as a reward granting means (e.g., a control unit 210) that, when the specified relationship between the first user and the second user is terminated, grants the second user a reward based on the second user's work in the game during the period in which the specified relationship was established.
With this configuration, even if a second user who has a predetermined relationship with a first user has terminated the predetermined relationship, the second user can be rewarded for the work done during the period in which the predetermined relationship was established. This prevents the second user from performing unnecessary work, thereby improving the interest of the service.

(Appendix 1-2)
The program described in Appendix 1-1, wherein the second user is able to affect objects in the game owned by the first user during a period in which the specified relationship is established between the first user and the second user.
With this configuration, even if a second user who has a predetermined relationship with a first user and is able to affect an object owned by the first user is dissolved, the second user can be rewarded for the work done during the period in which the predetermined relationship was established.

(Appendix 1-3)
Computer,
The program described in Appendix 1-2 functions as a restriction means (e.g., control unit 210) that prevents a second user, whose specified relationship with the first user has been terminated, from acting on objects owned by the first user that the second user was able to act on during the period in which the specified relationship was established, for a specified period of time.
With this configuration, a second user whose specified relationship with a first user has been terminated can be prevented from harassing or stalking the first user after the specified relationship has been terminated, thereby improving the interest of the service.

(Appendix 1-4)
a setting means for setting a predetermined relationship between a first user and a second user;
a cancellation means for canceling the predetermined relationship between the first user and the second user based on an operation by the first user;
and a reward granting means for granting a reward to the second user in accordance with the second user's work in the game during the period in which the specified relationship was established, when the specified relationship between the first user and the second user is terminated.
With this configuration, it is possible to achieve the same effects as the program described in Supplementary Note 1-1.

(Appendix 2-1)
Computer,
A setting means (for example, the control unit 210) for setting a predetermined relationship between a first user and a second user;
a cancellation means (e.g., a control unit 210) that cancels the predetermined relationship between the first user and the second user based on an operation by the first user;
and a program that functions as an erasure means (e.g., a control unit 210) that erases a specified influence that the second user had on an object owned by the first user during a period in which the specified relationship was established between the first user and the second user, based on the termination of the specified relationship between the first user and the second user.
With this configuration, the function of setting and canceling a predetermined relationship can be balanced, improving the sense of satisfaction and understanding of the first and second users and increasing the interest of the service.

(Appendix 2-2)
During a period in which the predetermined relationship is established between the first user and the second user, the second user may have a first influence and a second influence on an object owned by the first user;
The program described in Appendix 2-1, wherein the erasing means erases the second influence when the specified relationship between the first user and the second user is dissolved, while leaving the first influence that the second user has on an object owned by the first user.
With this configuration, the influence of a user with whom a specified relationship has been established can be divided into influences that remain after the specified relationship is dissolved and influences that do not remain, thereby improving the interest of the service.

(Appendix 2-3)
Computer,
The program described in Appendix 2-1 or 2-2 functions as a restriction means (e.g., control unit 210) that prevents a second user, whose specified relationship with the first user has been terminated, from exerting the specified influence on objects owned by the first user for a specified period of time, which the second user was able to exert the specified influence on during the period in which the specified relationship was established.
With this configuration, a second user whose specified relationship with a first user has been terminated can be prevented from harassing or stalking the first user after the specified relationship has been terminated, thereby improving the interest of the service.

(Appendix 2-4)
a setting means for setting a predetermined relationship between a first user and a second user;
a cancellation means for canceling the predetermined relationship between the first user and the second user based on an operation by the first user;
and an erasure means for erasing a predetermined influence that the second user had on an object owned by the first user during a period in which the predetermined relationship was established between the first user and the second user, based on the termination of the predetermined relationship between the first user and the second user.
With this configuration, it is possible to achieve the same effects as the program described in Supplementary Note 2-1.

The problem-solving means constituted by the above-mentioned program (for example, the components described in the appendix) can be appropriately adapted for use in devices, systems, methods, media, etc.

1 Game System, 3 Blockchain System, 10 Terminal Device, 11 Processor, 12 Memory, 13 Storage, 14 Communication Interface, 15 Input/Output Interface, 17 Input Unit, 18 Display Unit, 20 Server, 21 Processor, 22 Memory, 23 Storage, 24 Communication Interface, 25 Input/Output Interface, 30 Node Device, 31 Processor, 32 Memory, 33 Storage, 34 Communication Interface, 35 Input/Output Interface, 110 Control Unit, 111 Operation Reception Unit, 112 Transmitting/Received Unit, 113 Terminal Processing Unit, 114 Display Control Unit, 120 Memory Unit, 210 Control Unit, 211 Transmitting/Received 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 (4)

Computer,
a setting means for setting a cooperative relationship between a first user and a second user regarding a specific event that is being carried out in a virtual space owned by the first user ;
a cancellation means for canceling the relationship between the first user and the second user based on an operation by the first user while the specific event is in progress ;
and erasing means for erasing a predetermined influence that the second user had on the virtual space during a period in which the relationship between the first user and the second user was established, based on the termination of the relationship between the first user and the second user ;
The first user can continue the specific event in the virtual space in which the predetermined influence has been erased based on the termination of the relationship between the first user and the second user.
program. The influence that the second user can have on the virtual space during a period in which the relationship is established between the first user and the second user includes a first influence and a second influence,
The program of claim 1, wherein the erasing means erases the second influence , while leaving the first influence that the second user has had on the virtual space, when the relationship between the first user and the second user is terminated. Computer,
The program described in claim 1 or 2 functions as a restriction means that prevents a second user whose relationship with the first user has been terminated from exerting the specified influence on the virtual space, which the second user was able to exert the specified influence on during the period in which the relationship was established, for a specified period of time. a setting means for setting a cooperative relationship between a first user and a second user regarding a specific event that is being carried out in a virtual space owned by the first user ;
a cancellation means for canceling the relationship between the first user and the second user based on an operation by the first user while the specific event is in progress ;
an erasure means for erasing a predetermined influence that the second user had on the virtual space during a period in which the relationship between the first user and the second user was established, based on the termination of the relationship between the first user and the second user ;
The first user can continue the specific event in the virtual space in which the predetermined influence has been erased based on the termination of the relationship between the first user and the second user.
Information processing system.