JP2024064020A - Program, method, information processing device, and system - Google Patents

Abstract

[Problem] To improve the interest of collecting digital assets. [Solution] A program to be executed by a computer having a processor and a memory. The program causes the processor to execute the steps of managing digital items included in the digital assets, and of generating, in response to a request from a user, information representing the digital items owned by the user and to be transferred to the service in order to receive the provision of a benefit, where a service exists that provides a benefit according to the ownership status of the digital items. [Selected Figure] Fig. 16

Description

This disclosure relates to a program, a method, an information processing device, and a system.

In recent years, digital TCGs (Trading Card Games) that are played using digital cards have been gaining attention.

JP 2021-152815 A

In digital TCGs, players build decks by combining the digital cards they own. To build a deck, multiple types of digital cards are required. When trying to build a deck that is superior to other decks, there are digital cards that cannot be incorporated into the deck. Digital cards can be obtained by lottery, but if you do not get the digital cards needed to build a deck, you may feel as if you lost the lottery.

Patent Document 1 also envisions rare items and characters being the subject of auctions.

The purpose of this disclosure is to increase the interest of collecting digital assets.

A program to be executed by a computer having a processor and a memory. The program causes the processor to execute the steps of managing digital items included in digital assets, and generating, in response to a request from a user, information representing the digital items owned by the user to be transferred to the service in order to receive the reward, where a service exists that grants rewards according to the ownership status of the digital items.

The present disclosure aims to increase the interest in collecting digital assets.

1 is a block diagram showing an example of the overall configuration of a system 1. FIG. 2 is a block diagram illustrating an example of the configuration of a terminal device 10 illustrated in FIG. 1. FIG. 2 is a diagram illustrating an example of a functional configuration of a first server 20. FIG. 2 is a diagram illustrating an example of a functional configuration of a second server 30. FIG. 13 is a diagram showing the data structure of card information 182. A diagram showing the data structure of deck information 183. FIG. 2 is a diagram showing the data structure of a user information table 2021. FIG. 2 shows the data structure of a card master table 2022. A diagram showing the data structure of deck information table 2023. 13 is a diagram showing the data structure of a match information table 2024. FIG. FIG. 23 shows the data structure of a card management table 2026. 13 is a diagram showing the data structure of a privilege information table 3021 stored in the second server 30. FIG. 10 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when a user purchases a card. 11 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when managing cards used by users in a match. FIG. 11 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when managing cards based on user support. FIG. 11 is a diagram illustrating an example of the operation of the terminal device 10, the first server 20, and the second server 30 when the second server 30 grants a privilege based on a digital card to a user. FIG. 2 is a schematic diagram showing a display example of a display 141 of a terminal device 10. FIG. 3A and 3B are schematic diagrams illustrating examples of displays on a display 141. 3 is a schematic diagram showing a display example of a display 141. FIG. FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90.

Below, an embodiment of the present disclosure will be described with reference to the drawings. In the following description, the same parts are given the same reference numerals. Their names and functions are also the same. Therefore, detailed descriptions thereof will not be repeated.

<Summary>
In this embodiment, a server that provides digital assets manages digital assets owned by a user. The user requests information indicating the ownership status of the user's digital assets from the server. In response to the user's request, the server generates information indicating the ownership status of the user's digital assets and transmits it to the user. The user transfers the generated information to a service provider that provides a specified service, and receives benefits according to the digital assets owned.

In this embodiment, we will explain the case where digital cards related to a TCG are managed as digital items included in digital assets.

<1 Overall system configuration>
Fig. 1 is a block diagram showing an example of the overall configuration of a system 1. The system 1 shown in Fig. 1 includes, for example, a terminal device 10, a first server 20, and a second server 30. The terminal device 10, the first server 20, and the second server 30 are communicatively connected via, for example, a network 80.

In FIG. 1, an example is shown in which the system 1 includes two terminal devices 10, but the number of terminal devices 10 included in the system 1 is not limited to two. The number of terminal devices 10 included in the system 1 may be one, or three or more.

1 shows an example in which the system 1 includes one each of the first server 20 and the second server 30, but the number of the first server 20 and the second server 30 included in the system 1 is not limited to one each. The first server 20 and the second server 30 may be composed of multiple servers depending on the functions they have. In addition, the first server 20 and the second server 30 may be, for example, a collection of multiple devices as one server. The method of allocating multiple functions required to realize the first server 20 and the second server 30 according to this embodiment to one or multiple pieces of hardware can be appropriately determined in consideration of the processing capacity of each piece of hardware and/or the specifications required for the first server 20 and the second server 30.

The terminal device 10 shown in FIG. 1 is, for example, an information processing device operated by a user who plays a digital TCG. The terminal device 10 is realized, for example, by a mobile terminal such as a smartphone or a tablet. The terminal device 10 may also be realized by a stationary PC (Personal Computer), a laptop PC, or the like, or may be realized by a wearable terminal such as an HMD (Head Mount Display).

The terminal device 10 includes a communication IF (Interface) 12, an input device 13, an output device 14, a memory 15, a storage 16, and a processor 19. The input device 13 is a device (e.g., a touch panel, a touch pad, etc.) for accepting input operations from a user. The output device 14 is a device (a display, a speaker, etc.) for presenting information to the user.

The first server 20 is, for example, an information processing device that manages information related to cards and information related to decks. The first server 20 can be said to be, for example, an information processing device that manages digital assets related to the services used by the user.

The first server 20 is realized, for example, by a computer connected to the network 80. As shown in FIG. 1, the first server 20 includes a communication IF 22, an input/output IF 23, a memory 25, a storage 26, and a processor 29. The input/output IF 23 functions as an input device for accepting input operations from the user, and as an interface with an output device for presenting information to the user.

The second server 30 is, for example, an information processing device that manages information related to a specified service. The services provided by the second server 30 are independent of the services provided by the first server 20. However, the second server 30 grants specified benefits to users based on the users' digital assets managed by the first server 20. There may or may not be a specified relationship between the person managing the first server 20 and the person managing the second server 30.

The second server 30 is realized, for example, by a computer connected to the network 80. The second server 30 includes a communication IF 32, an input/output IF 33, a memory 35, a storage 36, and a processor 39. The input/output IF 33 functions as an input device for accepting input operations from the user, and as an interface with an output device for presenting information to the user.

Each information processing device is configured by a computer equipped with an arithmetic unit and a storage device. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by the hardware configuration will be described later. For each of the terminal device 10, the first server 20, and the second server 30, explanations that overlap with the basic hardware configuration and basic functional configuration of the computer described later will be omitted.

<1.1 Configuration of terminal device>
Fig. 2 is a block diagram showing an example of the configuration of the terminal device 10 shown in Fig. 1. As shown in Fig. 2, the terminal device 10 includes a communication unit 120, an input device 13, an output device 14, an audio processing unit 17, a microphone 171, a speaker 172, a camera 160, a position information sensor 150, a storage unit 180, and a control unit 190. The blocks included in the terminal device 10 are electrically connected to each other, for example, by a bus or the like.

The communication unit 120 performs processes such as modulation and demodulation processes for the terminal device 10 to communicate with other devices. The communication unit 120 performs transmission processing on the signal generated by the control unit 190 and transmits it to the outside (e.g., the first server 20). The communication unit 120 performs reception processing on the signal received from the outside and outputs it to the control unit 190.

The input device 13 is a device for inputting instructions or information by the user operating the terminal device 10. The input device 13 is realized, for example, by a touch-sensitive device 131 or the like where instructions are input by touching the operation surface. When the terminal device 10 is a PC or the like, the input device 13 may be realized by a reader, keyboard, mouse, or the like. The input device 13 converts instructions input by the user into electrical signals and outputs the electrical signals to the control unit 190. The input device 13 may include, for example, a receiving port that receives electrical signals input from an external input device.

The output device 14 is a device for presenting information to a user who operates the terminal device 10. The output device 14 is realized, for example, by a display 141 or the like. The display 141 displays data according to the control of the control unit 190. The display 141 is realized, for example, by an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display or the like.

The audio processing unit 17 performs, for example, digital-analog conversion processing of an audio signal. The audio processing unit 17 converts the signal provided from the microphone 171 into a digital signal and provides the converted signal to the control unit 190. The audio processing unit 17 also provides the audio signal to the speaker 172. The audio processing unit 17 is realized, for example, by a processor for audio processing. The microphone 171 accepts audio input and provides an audio signal corresponding to the audio input to the audio processing unit 17. The speaker 172 converts the audio signal provided from the audio processing unit 17 into audio and outputs the audio to the outside of the terminal device 10.

The camera 160 is a device that receives light using a light receiving element and outputs the light as a photographic signal.

The position information sensor 150 is a sensor that detects the position of the terminal device 10, and is, for example, a GPS (Global Positioning System) module. The GPS module is a receiving device used in a satellite positioning system. In a satellite positioning system, signals are received from at least three or four satellites, and the current position of the terminal device 10 equipped with the GPS module is detected based on the received signals. The position information sensor 150 may detect the current position of the terminal device 10 from the position of the wireless base station to which the terminal device 10 is connected.

The storage unit 180 is realized, for example, by the memory 15 and the storage 16, and stores data and programs used by the terminal device 10. The storage unit 180 stores, for example, user information 181, card information 182, and deck information 183.

User information 181 includes, for example, information about a user who plays a TCG. Information about a user includes, for example, a user ID, the user's name, age, address, date of birth, date of registration, etc.

Card information 182 includes, for example, information about cards. Card information 182 may also include information about cards owned by the user. Details will be described later.

Deck information 183 includes, for example, information about the deck constructed by the user. Details will be described later.

The control unit 190 is realized when the processor 19 reads a program stored in the memory unit 180 and executes instructions contained in the program. The control unit 190 controls the operation of the terminal device 10. By operating according to the program, the control unit 190 fulfills the functions of an operation reception unit 191, a transmission/reception unit 192, a management unit 193, a display control unit 194, and a battle processing unit 195.

The operation reception unit 191 performs processing for receiving instructions or information input from the input device 13. Specifically, for example, the operation reception unit 191 receives instructions or information input from the touch-sensitive device 131, etc.

The operation reception unit 191 also receives images input from the camera 160. Specifically, for example, the operation reception unit 191 receives image data captured by the camera 160.

The operation reception unit 191 also receives audio information input from the microphone 171. Specifically, for example, the operation reception unit 191 receives audio data that is input from the microphone 171 and converted into digital data by the audio processing unit 17.

The transmission/reception unit 192 performs processing for the terminal device 10 to transmit and receive data to and from external devices such as the first server 20 in accordance with a communication protocol. Specifically, for example, the transmission/reception unit 192 transmits to the first server 20 instructions input by the user or various pieces of acquired information. The transmission/reception unit 192 also receives information provided from the first server 20. The information provided from the first server 20 includes, for example, information on cards newly acquired by the user, information on decks registered in the first server 20, information created based on cards (digital assets) managed by the first server 20, and the like. The transmission/reception unit 192 also transmits predetermined information to the second server 30.

The management unit 193 manages the user information 181, card information 182, and deck information 183 stored in the storage unit 180. For example, when information about a user is edited, the management unit 193 stores the edited information in the user information 181. Furthermore, when the management unit 193 receives information about a card, it updates the card information 182. Specifically, for example, when a match using cards is held, the management unit 193 updates the card information 182. Furthermore, for example, when support is given via a card, the management unit 193 updates the card information 182. Furthermore, when a deck is organized, the management unit 193 updates the deck information 183.

The display control unit 194 controls the output device 14 to display a predetermined image to the user. For example, the display control unit 194 controls the display 141 to display a management screen of cards owned by the user based on the information managed in the card information 182 and the information managed in the deck information 183. The display control unit 194 may control the display 141 to display a management screen of cards owned by the user based on the information managed in the first server 20. The display control unit 194 also controls the display 141 to display information related to a card selected by the user and related to a match played using the card. The display control unit 194 also controls the display 141 to display information related to a card selected by the user and related to support via the card. The display control unit 194 also controls the display 141 to display information created in the first server 20 based on cards (digital assets) managed in the first server 20.

The match processing unit 195 controls processing for a match with another user. For example, the following modes of the match are assumed.
- Play against the CPU using a deck built with digital cards - Play against other players using a deck built with digital cards - Play in tournaments

<1.2 Functional configuration of the first server>
Fig. 3 is a diagram showing an example of a functional configuration of the first server 20. As shown in Fig. 3, the first server 20 fulfills the functions of a communication unit 201, a storage unit 202, and a control unit 203.

The communication unit 201 performs processing for the first server 20 to communicate with external devices.

The memory unit 202 has, for example, a user information table 2021, a card master table 2022, a deck information table 2023, a match information table 2024, and a card management table 2026.

The user information table 2021 is, for example, a table that stores information about users who are registered for services related to the TCG. Details will be described later.

The card master table 2022 is, for example, a table that stores information about cards available to users. Details will be described later.

The deck information table 2023 is, for example, a table that stores information about decks registered by users. Details will be described later.

The match information table 2024 is, for example, a table that stores information about matches that have been held in the past. Details will be described later.

The card management table 2026 is, for example, a table that stores information for managing cards acquired by users. Details will be described later.

The control unit 203 is realized by the processor 29 reading a program stored in the memory unit 202 and executing instructions contained in the program. The control unit 203 functions as a reception control module 2031, a transmission control module 2032, a management module 2033, a generation module 2034, and a battle processing module 2035 by operating according to the program.

The reception control module 2031 controls the process in which the first server 20 receives signals from external devices according to a communication protocol.

The transmission control module 2032 controls the process in which the first server 20 transmits signals to an external device according to a communication protocol. Specifically, for example, the transmission control module 2032 transmits information based on the owned digital assets, generated by the first server 20, to the terminal device 10.

The management module 2033 manages the tables stored in the memory unit 202. In other words, the management module 2033 manages the digital assets stored in the first server 20. Specifically, for example, the management module 2033 updates the card management table 2026 in response to an operation related to a card. The management module 2033 also updates the deck information table 2023 in response to an operation related to a deck. When the management module 2033 receives information related to a match, it updates the match information table 2024 and the card management table 2026. When the management module 2033 receives information related to cheering, it updates the card management table 2026.

The generating module 2034 generates information according to the digital assets managed by the first server 20. For example, when a user requests information indicating that the user has digital assets that satisfy a predetermined condition, the generating module 2034 generates the requested information. Specifically, for example, when a user requests information indicating that the user has two or more predetermined digital cards, the generating module 2034 generates the requested information. The digital card desired by the user is not necessarily based on the rarity of the card. The digital card desired by the user is set, for example, by the second server 30. Also, for example, when a user requests information indicating that the user has a digital card on which a predetermined record is kept, the generating module 2034 may generate the requested information. The digital card on which a predetermined record is kept refers to, for example, a digital card on which information about a predetermined match is stored, a digital card on which information about a predetermined cheer is stored, or a digital card on which a predetermined transaction has been made.

For example, when a user requests information indicating that he or she has a specific deck, the generation module 2034 generates the requested information. The deck desired by the user is set, for example, by the second server 30. For example, when a user requests information indicating that he or she has a deck on which specific records remain, the generation module 2034 may generate the requested information. A deck on which specific records remain refers, for example, to a deck on which information regarding a specific battle is stored.

The match processing module 2035 controls the processing of matches between users. For example, the match processing module 2035 controls matches between players using decks constructed from digital cards.

<1.3 Functional configuration of the second server>
Fig. 4 is a diagram showing an example of a functional configuration of the second server 30. As shown in Fig. 4, the second server 30 fulfills the functions of a communication unit 301, a storage unit 302, and a control unit 303.

The communication unit 301 performs processing for the second server 30 to communicate with external devices.

The storage unit 302 has, for example, a bonus information table 3021. The bonus information table 3021 is, for example, a table that stores information (bonus information) about bonuses to be granted to users. Details will be described later.

The control unit 303 is realized by the processor 39 reading a program stored in the storage unit 302 and executing instructions contained in the program. The control unit 303 performs the functions of a reception control module 3031, a transmission control module 3032, and an assignment module 3033 by operating according to the program.

The reception control module 3031 controls the process in which the second server 30 receives a signal from an external device according to a communication protocol. Specifically, for example, the reception control module 3031 receives information from the terminal device 10 indicating that the user owns a specific digital asset.

The transmission control module 3032 controls the process in which the second server 30 transmits a signal to an external device according to a communication protocol. Specifically, for example, the transmission control module 3032 transmits information related to the benefit to the terminal device 10.

The granting module 3033 grants a privilege to the user. For example, the granting module 3033 refers to the privilege information table 3021 and determines whether the digital asset owned by the user satisfies the conditions for granting a privilege. If the conditions are satisfied, the granting module 3033 grants the privilege to the user. The granting of the privilege to the user may be realized, for example, by the transmission control module 3032 transmitting the privilege to the user. Furthermore, the granting of the privilege to the user may be realized, for example, by the granting module 3033 handing the privilege to the user at a store after confirming that the conditions for granting the privilege are satisfied.

<2 Data Structure>
5 and 6 are diagrams showing the data structure of information stored in the terminal device 10. Note that Fig. 5 and Fig. 6 are merely examples, and do not exclude data not shown.

Figure 5 is a diagram showing the data structure of card information 182. Card information 182 shown in Figure 5 is a table with a card management ID as a key and columns such as card ID, name, type, attribute, card information, match information, support information, image data, etc. In addition to these, card information 182 may also include information regarding regulations or rarity, etc.

The card management ID is an item that stores an identifier for uniquely identifying a card. In this embodiment, cards with the same name, effect, rarity, and regulations, i.e., exactly the same cards, are assigned different card management IDs. The card ID is an item that stores an identifier for uniquely identifying the type of card. In this embodiment, the same card ID is assigned to exactly the same cards. The name is an item that stores the name of the card. The type is an item that stores the type of card. In this embodiment, card types include, for example, character cards that can fight during a match, action cards (energy cards) that are used in association with characters, and effect cards that exert specific effects during a match (support cards, goods cards, stadium cards, etc.).

Attributes are items that store the properties to which a character belongs. In this embodiment, attributes include, for example, fire, water, lightning, grass, super, steel, evil, fighting, etc. There are attributes that are advantageous when faced against, and attributes that are disadvantageous. Card information is an item that stores information that explains the contents of the card. If the card type is character, the card information includes, for example, the character's attack power, stamina, the amount of energy required to perform a technique, the amount of energy required to escape, weaknesses, resistance, special properties possessed by the character, etc. If the card type is support, goods, or stadium, the card information includes, for example, the requirements for using the card, effects that occur when the card is used, etc.

The battle information is an item that stores information about a TCG battle that was conducted by incorporating the corresponding card into a deck. In this embodiment, a battle ID that can identify the battle is stored as the battle information. The first server 20, for example, registers, as the battle information, information that identifies a battle that was conducted by a user using a deck that incorporated the corresponding card. The item "Battle Information" is, for example, battle information registered by the first server 20 that is transmitted to and stored in the terminal device 10.

Cheering information is an item that stores information about a TCG match that was supported in association with the corresponding card. In this embodiment, a match ID that can identify the match that was supported is stored as the cheering information. The first server 20, for example, manages the cheering provided by the user in association with the corresponding card by linking it to the card management ID. The item "Cheering information" is cheering information managed by the first server 20 that is sent to the terminal device 10 and stored therein.

Image data is an item that stores an image. Image data may also store reference information (path) to an image data file located elsewhere.

Figure 6 is a diagram showing the data structure of deck information 183. Deck information 183 shown in Figure 6 is a table with columns such as name, organization cards, completion, update date, and registration information, with deck ID as a key. In addition to these, deck information 183 may also have information on the nickname of the deck, deck usage history, etc. The nickname of the deck is a name given based on a common understanding among multiple users, for example, based on characteristic cards used in the deck, succinctly expresses the characteristics of the deck.

Deck ID is an item that stores an identifier for uniquely identifying a deck. Name is an item that stores the name of the deck. The name is given by, for example, the user. Organization card is an item that stores the cards that make up the deck. In the organization card, for example, the card management ID of the card that makes up the deck is stored.

Complete is an item that stores whether or not the deck is complete. In this embodiment, a circle indicates that the deck is complete, and a cross indicates that the deck is not complete. In this embodiment, a completed deck means, for example, that the deck has been assembled with a specified number of cards and is ready to be used in a match. Update date is an item that stores the date on which the deck configuration was changed. In calculating the update date, the use of a card used in one deck in another deck may also be treated as a change. Registration information is an item that stores the relationship with a deck registered in the first server 20. The registration information stores, for example, a deck code issued when the deck is registered in the first server 20.

Records for decks are added when a new deck is created on the terminal device 10 at the user's instruction.

Figures 7 to 11 are diagrams showing the data structure of the information stored in the first server 20. Note that Figures 7 to 11 are merely examples and do not exclude data that is not listed.

Figure 7 is a diagram showing the data structure of the user information table 2021. The user information table 2021 shown in Figure 7 is a table having columns such as name, age, address, date of birth, and date of registration, with the user ID as a key. The user information table 2021 is not limited to the above, and may also have proficiency as a column.

The user ID is an item that stores an identifier for uniquely identifying a user. The name is an item that stores the user's name. The age is an item that stores the user's age. The address is an item that stores the place where the user lives. The date of birth is an item that stores the date the user was born. The registration date is an item that stores the date the user started using a service related to the TCG.

Records in the user information table 2021 are added when a new user is registered.

Figure 8 is a diagram showing the data structure of the card master table 2022. The card master table 2022 shown in Figure 8 is a table that uses the card ID as a key and has columns such as name, type, attributes, card information, and image data.

The card ID is an item that stores an identifier for uniquely identifying the type of card. The name is an item that stores the name of the card. The type is an item that stores the type of card. The attribute is an item that stores the nature to which the character belongs. The card information is an item that stores information that describes the contents of the card. The image data is an item that stores an image.

Records in the card master table 2022 are added, for example, when a new card is issued.

Figure 9 is a diagram showing the data structure of the deck information table 2023. The deck information table 2023 shown in Figure 9 is a table that uses the deck code as a key and has columns such as name, user ID, registration date, first organization card, second organization card, and publication. In addition to these, the deck information table 2023 may also have information regarding the nickname of the deck.

The deck code is an item that stores an identifier for uniquely identifying a registered deck. The deck code is issued by the management module 2033 when a user registers a new deck. The deck code shown in FIG. 9 is, for example, an identifier different from the deck ID shown in FIG. 6. This is because the deck code shown in FIG. 9 is for managing publicly available decks, while the deck ID shown in FIG. 6 is for managing one's own deck. The name is an item that stores the name of the deck. The name is given by the user. The user ID is an item that stores the user ID of the user who registered the deck. The registration date is an item that stores the date the deck was registered.

The first organization card and the second organization card are items that store the cards that will be used to organize the deck. In the first organization card, for example, the card IDs of the cards that will be used to organize the deck are stored. In the second organization card, for example, the card management IDs of the cards that will be used to organize the deck are stored. "Public" is an item that stores whether or not the deck is publicly available to other users. In this embodiment, a circle indicates that the deck is publicly available to other users, and a cross indicates that the deck is not publicly available to other users. In this embodiment, a deck that is not public means that it can only be viewed by the user himself.

Records in the deck information table 2023 are added when a new deck is registered.

Figure 10 is a diagram showing the data structure of the match information table 2024. The match information table 2024 shown in Figure 10 is a table that uses a match ID as a key and has columns such as date and time, opponent, deck code, winner, match log information, and tournament information.

The match ID is an item that stores an identifier for uniquely identifying a match. A match ID is issued by the management module 2033 when new information about a match is registered. The date and time is an item that stores the date and time when the match took place. The opponents is an item that stores information about the players who played the match. In this embodiment, for example, the user IDs of the players who played the match are stored in the opponents.

The deck code is an item that stores a code that identifies the deck used in a match. In this embodiment, for example, the player who played the match is associated with the deck code of the deck used by that player. Note that the deck code does not necessarily have to be stored. In other words, the deck code does not necessarily have to be registered.

Winner is an item that stores the winner of a match. Match log information is an item that stores the moves adopted by players during a match. Specifically, for example, the match log information stores the player drawing a card from a specified placement section (such as the deck or the win/lose condition card), the player placing a card in a specified placement section, the player using the effect of a specified card, etc. The moves adopted by players during a match may be referred to as deck rotation during a match. Tournament information is an item that stores information about a match. For example, the tournament information includes the name of the tournament in which the match was held, and the number of rounds of the match in the tournament. The tournament information may include match information in a privately held tournament, regardless of whether it was an officially held tournament. Furthermore, the tournament information is not limited to tournaments, and may include match information in private matches.

Records in the match information table 2024 are added when a new match is registered.

Figure 11 is a diagram showing the data structure of the card management table 2026. The card management table 2026 shown in Figure 11 is a table that uses the card management ID as a key and has columns such as card ID, match information, support information, owner, transferee, transferor, transaction date, and value.

The owner is an item that stores information about the user who owns the card. In this embodiment, the owner stores the user ID of the user who owns the card.

Transferee, Transferor, Transaction Date, and Consideration are items that store information about the transaction of the card identified by the card management ID. Transferee, Transferor, Transaction Date, and Consideration are added for each transaction. Transferee represents the person who received the card in the transaction. Transferor represents the person who transferred the card in the transaction. Transaction Date represents the date the transaction was carried out. Consideration represents the cost paid from the transferee to the transferor when trading the card.

Figure 12 is a diagram showing the data structure of the bonus information table 3021 stored by the second server 30. Note that Figure 12 is an example, and does not exclude data that is not listed. The bonus information table 3021 shown in Figure 12 is a table that uses the bonus ID as a key and has columns for bonus content, conditions, etc.

The reward ID is an item that stores an identifier for uniquely identifying a reward. The reward content is an item that stores the content of the reward. The condition is an item that stores the condition under which the reward is granted. The reward content is, for example, a coupon, a specified product, points, etc. For example, if the second server 30 is managed by an aquarium, the condition may be possession of a digital card related to water, and the reward content may be a discount on the fee.

<3 Operation>
The operations of the terminal device 10, the first server 20, and the second server 30 when a user receives a benefit from the second server 30 based on the digital assets managed by the first server 20 will be described.

(Card management table update process Digital asset purchase)
The first server 20 sells, for example, digital cards. The first server 20 sells, for example, cards in a manner in which the user can grasp the contents of the cards. The first server 20 may also sell cards in a manner in which the user cannot grasp the contents of the cards. The first server 20 sells cards in units of one card. The first server 20 may also sell cards in units of multiple cards.

The first server 20 may also function as a platform for users to sell cards to other users. The first server 20 makes cards available to other users for purchase, for which sales conditions such as price have been set by the user. If the user agrees to the sales conditions set by the other user, he or she can select the card and purchase it.

Figure 13 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when a user purchases a card.

When purchasing a card, a user uses the terminal device 10 to access the first server 20. The terminal device 10 obtains information about cards being sold by the first server 20 and displays it on the display 141. The user refers to the cards displayed on the display 141 and selects the desired card. The user inputs a request to purchase the selected card into the terminal device 10.

In step S11, the terminal device 10 accepts a card purchase request input by the user via the operation acceptance unit 191. The terminal device 10 transmits the accepted purchase request to the first server 20 via the transmission/reception unit 192.

In step S12, the first server 20 acquires a card based on a purchase request from the user. Specifically, for example, the first server 20 acquires a card selected by the user by consuming a predetermined asset associated with the user through the management module 2033. The predetermined asset is, for example, the following:
・Game media used in the game ・Crypto assets ・Tokens ・Information about currencies

If the user selects a card that is being sold in a manner in which the card contents can be ascertained, the management module 2033 acquires the card ID of the card selected by the user. If the user selects a card that is being sold in a manner in which the card contents cannot be ascertained, the management module 2033 executes a card lottery and acquires the card ID of the card selected by the lottery. If the user selects a card sold by another user, the management module 2033 acquires the card management ID of the card selected by the user from the card management table 2026.

In step S13, the management module 2033 updates the card management table 2026 based on the acquired card ID. Specifically, for example, when a card ID is acquired for a card that is sold in a manner that allows the card contents to be ascertained, or when a card ID is acquired for a card selected by lottery, the management module 2033 issues a card management ID for the corresponding card. The management module 2033 issues a record in the card management table 2026 using the card management ID as a key, and stores information on the card ID and owner in the record.

For example, when the management module 2033 acquires the card management ID of a card being sold by another user, the management module 2033 changes the owner of the card in the card management table 2026. The management module 2033 also stores information about the transaction in a record that uses the acquired card management ID as a key. Specifically, for example, the management module 2033 stores the transferee, transferor, transaction date, and consideration in a record that uses the acquired card management ID as a key.

In step S14, the first server 20 transmits information about the card purchased by the user to the terminal device 10. Specifically, for example, the management module 2033 reads information about the card purchased by the user from the card master table 2022 based on the card ID. The management module 2033 reads, for example, the name, type, attributes, card information, and image data as information about the card from the card master table 2022. The transmission control module 2032 transmits the card ID, the read information, and the card management ID to the terminal device 10.

In step S15, the terminal device 10 receives the information transmitted from the first server 20 and updates the card information 182 based on the received information. Specifically, for example, the terminal device 10 creates a new record in the card information 182 using the management unit 193, and stores the card management ID, card ID, name, type, attributes, card information, and image data.

(Card management table update process, battle information storage)
The control unit 203 of the first server 20 manages, by the management module 2033, information on which cards have been used in a match for each card.

The user builds a deck by combining cards managed in card information 182. The management unit 193 manages information related to the deck built by the user in deck information 183.

The user also registers the deck that he or she has constructed in the first server 20. Specifically, the user uses the terminal device 10 to access the first server 20. The terminal device 10 displays a deck registration form set in the first server 20 on the display 141. The user uses the form displayed on the display 141 to select cards to construct the deck. The user inputs a request to the terminal device 10 to register the deck constructed from the selected cards and the name of the deck. The user may set whether or not to make the registered deck public to other users.

When a deck registration request is input by a user, the management module 2033 issues a new deck code and creates a record in the deck information table 2023 with the issued deck code as a key. The management module 2033 stores, for example, the name of the created record, the user ID, the registration date, the first organization card, the second organization card, and the publication based on the information input by the user.

Figure 14 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when managing cards used by a user in a match.

When starting a match, the user uses the terminal device 10 to access the first server 20. The terminal device 10 displays on the display 141 a registration form for match information that has been set in the first server 20. The user uses the form displayed on the display 141 to input information about the match. Information about the match includes, for example, the date and time when the match will be held, the opponents, information about the decks to be used in the match, tournament information, etc. After inputting the information about the match, the user inputs a request to register the match information into the terminal device 10.

In step S21, the terminal device 10 accepts a registration request for battle information input by the user via the operation reception unit 191. The terminal device 10 transmits the input battle information and the registration request to the first server 20 via the transmission/reception unit 192.

In step S22, the first server 20 updates the card management table 2026 based on the match information input by the user. Specifically, for example, when the management module 2033 receives a request to register match information from the user, it issues a match ID and creates a record in the match information table 2024 with the issued match ID as a key. The management module 2033 stores the date and time, opponent, deck code, and tournament information of the created record based on the information input by the user.

The date and time, opponents, and tournament information may be entered in advance by the tournament organizer. In this case, a battle ID has already been issued, and a record has been created in the battle information table 2024. Information regarding the decks to be used in the battle may also be registered in advance by the user. For example, multiple decks to be used in the tournament may be registered before the battle, and the user may select one of the registered decks at the start of the battle.

When the management module 2033 stores information in the match information table 2024, it updates the card management table 2026. Based on the card management IDs of the cards included in the deck, the management module 2033 stores information about the match in which the deck is used, such as the match ID, in the "match information" item of the corresponding record in the card management table 2026. The more matches there are, the more information is stored in the match information. This makes it possible to know in which match the card was used.

In step S23, the first server 20 transmits information managed in the card management table 2026 to the terminal device 10. Specifically, for example, when a new battle ID is stored in the "Battle Information" item of the card management table 2026, the management module 2033 reads out the newly stored battle ID, the card management ID, and the user ID of the owner. The transmission control module 2032 transmits the read battle ID and card management ID to the terminal device 10 owned by the user identified by the user ID.

In step S24, the terminal device 10 receives the information transmitted from the first server 20 and updates the card information 182 based on the received information. Specifically, for example, the terminal device 10 stores the battle information received from the first server 20, for example, the battle ID, in the "battle information" item of the record identified by the card management ID, via the management unit 193.

When a match begins, the control unit 203 controls the match processing between players using the match processing module 2035. The match processing module 2035 stores information about the moves used by the players during the match in the memory unit 202. The management module 2033 stores information about the moves used by the players during the match in the match information table 2024 as match log information. When the match ends, the match processing module 2035 recognizes the player who won the match as the winner. The management module 2033 stores the winner in the match information table 2024.

(Card management table update process, support information storage)
The control unit 203 of the first server 20 manages, by the management module 2033, information on supporting the deck related to the card for each card.

Users may support players who use decks that contain cards that they have a special attachment to. In this embodiment, support for decks related to cards is managed in association with card information.

Figure 15 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when managing cards based on user support.

For example, before a tournament is held, information about the tournament participants and the decks used by the tournament participants is made public. A user refers to the tournament participants and the decks and selects the player he or she will support. The user accesses the first server 20 using the terminal device 10 before the tournament is held or a specified time on the day of the tournament. The terminal device 10 displays the support form set in the first server 20 on the display 141. The user uses the form displayed on the display 141 to select a card that will be the basis of the support, and inputs other players who use the deck to support in association with the selected card. After inputting the support information, the user inputs a request to register the support information to the terminal device 10. The support information includes, for example, the card management ID of the selected card and the user ID of the player to support. The user ID of the player to support may be the participant ID when participating in the tournament. The support information may include, for example, information identifying the tournament and information identifying the match in the tournament.

The card that is the basis for cheering is, for example, a card that has the same effect as the cards that make up the deck being cheered for. If a user has an attachment to a particular card, they may wish to cheer for a player who is using a deck that includes cards that have the same effect as this card. Based on the cards they own, users will cheer for a player who is using a deck that includes those cards. Note that the cards that are the subject of cheering may be of different rarities. If a deck does not include any cards that have the same effect as the cards they own, it may be possible to prevent the user from cheering for the player who is using that deck.

For example, only one player can be supported based on one card. Note that the number of players that can be supported may be limited to one regardless of the number of cards. Also, a player may be supported throughout the tournament, or the supported player may be changed for each match.

Also, the target of support may not be the player, but the deck.

The control unit 190 may set, via the management unit 193, that the card that is the basis of the support cannot be used in the deck by the user while the deck is being supported. This makes it possible to select the deck to support more carefully, since the selected deck cannot be used while the deck is being supported.

In step S31, the terminal device 10 receives a request to register cheering information input by the user via the operation reception unit 191. The terminal device 10 transmits the input cheering information and the registration request to the first server 20 via the transmission/reception unit 192.

In step S32, the first server 20 updates the card management table 2026 based on the cheering information input by the user. Specifically, for example, when a cheering information registration request is input by the user, the management module 2033 reads information about the match from the match information table 2024. Based on the card management ID included in the cheering information input by the user, the management module 2033 stores information based on the information about the match in the "cheering information" item of the corresponding record in the card management table 2026. The specified information stored in the "cheering information" item includes, for example, the match ID and the user ID of the cheering player. As the number of cheers increases, the amount of cheering information stored increases. This makes it possible to grasp the cheering that has been done based on the card.

In step S33, the first server 20 transmits information managed in the card management table 2026 to the terminal device 10. Specifically, for example, when a new battle ID and user ID are stored in the "support information" item of the card management table 2026, the management module 2033 reads out the newly stored battle ID and user ID, the card management ID, and the user ID as the owner. The transmission control module 2032 transmits the read battle ID and user ID, and the card management ID to the terminal device 10 owned by the user identified by the user ID.

In step S34, the terminal device 10 receives the information transmitted from the first server 20 and updates the card information 182 based on the received information. Specifically, for example, the terminal device 10 stores the cheering information received from the first server 20, such as the battle ID and user ID, in the "cheering information" item of the record identified by the card management ID, via the management unit 193.

When a match starts, the control unit 203 controls the match processing between the players by the match processing module 2035. The match processing module 2035 stores information about the moves used by the players during the match in the storage unit 202. The management module 2033 stores information about the moves used by the players during the match in the match information table 2024 as match log information. When the match ends, the match processing module 2035 recognizes the player who won the match as the winner. The management module 2033 stores the winner in the match information table 2024. The management module 2033 may store information about the win or loss in the "support information" item of the card management table 2026. The management module 2033 may store the results of the tournament in the match information table 2024. For example, if a player wins the final of a tournament, the winner may be stored in the match information table 2024, and the fact that the player won the tournament may be stored in the match information table 2024 as the result of the tournament.

(Benefit Granting Process)
The second server 30 provides a service independent of the service related to the TCG. In other words, the second server 30 provides a service separate from the service related to the TCG. Specifically, the second server 30 is, for example, an aquarium, a museum, a retail store, or a restaurant.

The services provided by the second server 30 are independent of the services provided by the first server 20, but have a predetermined relationship with the services provided by the first server 20. The predetermined relationship means, for example, providing a part of the services provided by the second server 30 to the user in accordance with the digital assets owned by the user for the services provided by the first server 20. Specifically, if the second server 30 provides services such as an aquarium, museum, retail store, or restaurant, the second server 30 distributes coupons (discount coupons or product exchange vouchers) that can be used at the store in accordance with the digital assets related to the first server 20.

For example, a predetermined period may be set for the service of the second server 30 to have a predetermined relationship with the service of the first server 20. The predetermined period for having the predetermined relationship may be set in advance or may vary according to predetermined requirements. The predetermined period may be set as a campaign period, for example. In other words, during the campaign period, the second server 30 provides the user with a part of the service provided by the second server 30, for example, in accordance with the digital assets owned by the user for the service provided by the first server 20.

The specified requirement that changes the specified period means, for example, the number of products provided in a specified relationship, or the number of users related to the specified relationship. Specifically, for example, if the benefit is a campaign product with a limited number of products, the period ends when the products run out. In other words, the second server 30 provides the user with campaign products according to the digital assets owned by the user for the service provided by the first server 20, for example, until the campaign products run out. Also, if the benefit is a campaign experience with a limited number of people, the period ends when the number of people is reached. In other words, the second server 30 provides the user with a campaign experience according to the digital assets owned by the user for the service provided by the first server 20, for example, until the number of applicants reaches a specified number.

The following explanation uses as an example a case where the second server 30 grants a benefit to a user based on the digital card the user possesses.

Figure 16 is a diagram illustrating an example of the operation of the terminal device 10, the first server 20, and the second server 30 when the second server 30 grants a user a benefit based on a digital card.

In step S41, the second server 30 sets the bonus information. For example, the control unit 303 of the second server 30 sets the bonus content and its conditions using the granting module 3033. The granting module 3033 may set any conditions regarding the ownership of the digital assets.

For example, the grant module 3033 may use the total number of digital cards as a condition. The grant module 3033 may use the number of digital cards with a specified card ID as a condition. The grant module 3033 may use a combination of specified card IDs as a condition. The grant module 3033 may also include information linked to the digital cards as a condition. For example, the grant module 3033 may use information related to a match as a condition. The grant module 3033 may use information related to cheering as a condition. The grant module 3033 may use information related to a transaction as a condition. The grant module 3033 may use ownership of a specified deck as a condition.

Specifically, for example, the granting module 3033 sets the condition that product AAAA will be granted on the possession of digital cards with card IDs: C0001, C0002, and C0003.

In step S42, the second server 30 makes the set bonus information public using a predetermined method. Any existing method may be used as the method of disclosure.

In step S43, the terminal device 10 acquires the bonus information related to the second server 30. The control unit 190 of the terminal device 10 causes the display control unit 194 to display a list of the bonus information on the display 141.

Figure 17 is a schematic diagram showing an example of the display of the display 141 of the terminal device 10. In Figure 17, the display control unit 194 displays an area 1411. Area 1411 is an area for displaying information related to benefits. A search window 14111 is displayed in area 1411. When a user finds a desired benefit or a digital asset that appears to meet the conditions, the user inputs keywords, etc., into the search window 14111.

The display control unit 194 displays the bonus information in a list in area 1411, for example. The display order can be set arbitrarily, such as by product name, identification number, product value, or difficulty of collecting digital assets. The difficulty of collecting digital assets can be calculated, for example, based on the rarity of the digital card. In FIG. 17, the display control unit 194 displays information about one bonus in object 14112. In object 14112, the display control unit 194 displays the product name and the digital assets required as a condition.

The display control unit 194 may display in the area 1411 only information related to the benefits that satisfy the conditions for the digital assets. Specifically, for example, the management unit 193 compares the conditions for the benefits with the digital assets owned by the user. The management unit 193 extracts information about the benefits that satisfy the conditions. The display control unit 194 displays the information about the extracted benefits on the display 141. As a result, the benefits displayed on the display 141 are available to the user, and the user does not need to check which of the displayed benefits is available to the user.

In FIG. 17, the user selects the desired benefit and touches the object that displays the selected benefit.

When the user touches the object, the display control unit 194 of the terminal device 10 displays a screen for confirming that the user wishes to obtain the selected benefit.

Figure 18 is a schematic diagram showing an example of the display of the display 141. In the example shown in Figure 18, the display control unit 194 displays a window 14113 for confirming acquisition of the selected benefit. Buttons 141131 and 141132 for inputting the user's intention are displayed in the window 14113. If there is no mistake in acquiring the benefit, the user presses the Yes button 141131. In this embodiment, pressing the button 141131 signifies a request to generate information about the digital asset to be displayed on the object, and input of a request to grant the benefit.

In step S44, the terminal device 10 accepts the generation request and the grant request input by the user through the operation acceptance unit 191. The terminal device 10 transmits the generation request to the first server 20 through the transmission/reception unit 192. The generation request includes, for example, the user's identification information (e.g., a user ID, a specific address set for the user) and information related to the conditions (e.g., a card ID).

In step S45, the first server 20 checks the digital assets owned by the user based on the request from the user. Specifically, for example, the control unit 203 of the first server 20 acquires the user's identification information and information related to the conditions from the received generation request via the management module 2033. The management module 2033 refers to the card management table 2026 based on the acquired information, and checks whether the user owns the digital card presented as a condition.

In step S46, the first server 20 generates information about the digital assets. Specifically, if the user has a digital card that is presented as a condition, for example, the control unit 203 of the first server 20 generates, via the generation module 2034, certification information that certifies that the user owns the digital card, as information about the digital assets.

The certification information is, for example, information indicating that the required number of cards with the target card ID are possessed. The certification information is also, for example, information indicating that the required number of digital cards with required additional information attached are possessed. The certification information is also, for example, information indicating that the target deck is possessed. The generation module 2034 may include the generation date and time in the certification information.

Information about digital assets is not the digital items themselves contained in the digital assets. In other words, information about digital assets does not maintain the data structure of the digital items related to that information. Therefore, even if information about digital assets is transferred to another service, the transferee cannot use the corresponding digital items. Furthermore, even if information about digital assets is transferred to another service, the owner of the corresponding digital items does not change. In other words, there is no change to the data structure of the digital items managed by the first server 20.

The generation module 2034 determines that the owner of the information about the generated digital asset is the user who input the generation request. The control unit 203 of the first server 20 transmits the information about the generated digital asset to the terminal device 10 via the transmission control module 2032.

In step S47, the terminal device 10 transfers the information about the digital asset generated by the first server 20 to the second server 30. Specifically, for example, the control unit 190 of the terminal device 10 receives the information about the digital asset by the transmission/reception unit 192. The transmission/reception unit 192 transmits the information about the digital asset and a grant request to the second server 30. The transmission/reception unit 192 transmits an instruction to the first server 20 to change the owner of the information about the digital asset to the second server 30 (which can also be said as the service provider). The first server 20 changes the owner of the information about the digital asset to the second server 30. The grant request includes, for example, user identification information (for example, a user ID, a specific address set for the user) and information identifying the benefit selected by the user.

In step S48, the second server 30 grants a privilege to the terminal device 10. Specifically, for example, the control unit 303 of the second server 30 receives information about the digital asset and a grant request via the grant module 3033. The grant module 3033 obtains the user's identification information and the identification information of the selected privilege from the grant request. The grant module 3033 reads the conditions for the privilege selected by the user from the privilege information table 3021. The grant module 3033 compares the information about the digital asset with the conditions for the privilege. If the information about the digital asset matches the conditions for the privilege, the grant module 3033 grants the privilege to the user.

When a bonus is granted by the second server 30, the display control unit 194 of the terminal device 10 displays a screen to notify the user that a bonus has been granted.

Figure 19 is a schematic diagram showing an example of the display of the display 141. In the example shown in Figure 19, the display control unit 194 displays a window 14114 for notifying the user that a special benefit has been granted. In the window 14114, a button 141141 for inputting the user's intention is displayed. When the user confirms that a special benefit has been granted, he or she presses the Yes button 141141.

As described above, in the above embodiment, there is a service that grants benefits based on the ownership status of digital items. The control unit 203 of the first server 20 manages the digital items included in the digital assets using the management module 2033. In response to a request from a user, the control unit 203 generates, using the generation module 2034, information that represents the digital items owned by the user and that is to be transferred to the service in order to receive a benefit. This allows the user to receive a benefit based on the digital items they own.

Therefore, this embodiment can increase the interest in collecting digital assets.

In addition, in the above embodiment, the generation module 2034 receives from the user the specification of the digital items for which ownership status is to be confirmed, and generates information indicating that the specified digital items are owned. This reduces the number of digital items for which ownership is to be confirmed when generating information, making it possible to reduce the processing load of the generation module 2034.

In addition, in the above embodiment, the generation module 2034 generates information indicating the possession of a digital item to which predetermined related information is attached. This makes it possible to set bonus information based on not only the number of digital items, but also on what was done with the digital items. This makes it possible to increase the interest in using digital items.

In addition, in the above embodiment, even if the generation module 2034 generates information about digital assets, it does not affect the digital items being managed. As a result, even if information is generated, the digital items are not reduced, so that benefits can be received without hesitation.

In addition, in the above embodiment, the data structure of the digital items related to the information about digital assets is not maintained. As a result, even if the information is transferred, the transferee cannot use it as a digital item. This makes it possible to prevent the increase in digital items.

In the above embodiment, the digital items can be used in games provided by a specific entity. The service that grants benefits depending on the ownership status of digital items is a service separate from the game. This makes it easy to associate the acquisition of a digital item related to a game with a service separate from the game, and can motivate players to play the game. It also makes it possible to reduce the burden on service providers when linking the service with a game.

<Modification>
In the above embodiment, a case has been described in which the user information table 2021, the card master table 2022, the deck information table 2023, the battle information table 2024, and the card management table 2026 are stored in the first server 20. However, the information stored in these tables does not have to be stored in the first server 20. For example, at least the card information stored in the card management table 2026 may be stored in a block chain (distributed ledger) formed by a P2P computer network.

At this time, each digital card is traded on the blockchain as a non-fungible token (NFT). The card management ID in the above embodiment corresponds to, for example, a unique identifier (NFT-ID) for identifying the NFT. Furthermore, information on the digital asset is traded on the blockchain as an NFT. For example, the generation module 2034 may be realized by a smart contract implemented on the blockchain. Upon receiving a generation request, the smart contract generates proof information as an NFT based on information on the conditions included in the generation request.

Transactions for NFTs are executed, for example, by smart contracts implemented on the blockchain. The transaction history for NFTs is stored on the blockchain as transactions. This allows the history of NFT owners to be stored on the blockchain.

In addition, management of NFT usage is carried out, for example, by a smart contract implemented on the blockchain. The history of NFT usage is stored on the blockchain as transactions. This allows the history of NFT use in matches and the history of supporting other players based on NFTs to be stored on the blockchain.

In addition, the granting of rewards related to the usage history of NFTs is executed, for example, by a smart contract implemented on the blockchain. As a result, when the history of using an NFT in a match meets certain requirements, the owner of the NFT at that time is granted a specified reward. In addition, when the history of supporting other players based on the NFT meets certain requirements, the owner of the NFT at that time is granted a specified reward.

The granting module 3033 may be realized, for example, by a smart contract implemented on a blockchain. When the smart contract receives the granting request and the information about the digital asset, it compares the information about the digital asset with the conditions for the reward. If the information about the digital asset matches the conditions for the reward, the smart contract grants the reward to the user.

In this way, the control unit 203 of the first server 20 uses the management module 2033 to store information about multiple digital cards in a distributed ledger formed by a computer network. Note that the control unit 190 of the terminal device 10 may use the management unit 193 to store information about multiple digital cards in a distributed ledger formed by a computer network. This makes it possible to treat digital cards as NFTs. It also makes it possible to keep transparent records about the digital cards.

The management module 2033 also stores information regarding card usage in the distributed ledger as a transaction of the corresponding digital card. The management unit 193 may also store information regarding card usage in the distributed ledger as a transaction of the corresponding digital card. This makes it possible to keep a transparent record of the usage history of the digital card.

The management module 2033 or the management unit 193 also stores information about the match in the distributed ledger as a transaction of the corresponding digital card. This makes it possible to keep a transparent record of information about the match between digital cards.

In addition, the management module 2033 or the management unit 193 stores information about cheering in the distributed ledger as a transaction of the corresponding digital card. This makes it possible to keep a transparent record of information about cheering based on the digital card.

In addition, the management module 2033 or the management unit 193 stores information about the transaction in the distributed ledger as a transaction of the transacted digital card. This makes it possible to keep a transparent record of the digital card transaction.

In the above embodiment, a case has been described in which the first server 20 stores the match information table 2024. The user's own match information may be stored in the memory unit 180 of the terminal device 10. The management unit 193 may update the match information in the card information 182 based on the match information stored in the memory unit 180. When the card information 182 is updated, the transmission/reception unit 192 transmits information related to the card to the first server 20. The management module 2033 of the first server 20 updates the card master table 2022 based on the information transmitted from the terminal device 10. This makes it possible for the terminal device 10 to grasp the match information.

In the above embodiment, examples of card uses were described as battles using decks of cards and cheering based on cards. However, card uses are not limited to these. For example, card uses may also include displaying cards.

In the above embodiment, the digital items included in the digital assets are described as digital cards. However, the digital items are not limited to digital cards. The digital items may be digital characters, etc.

In the above embodiment, a case has been described in which the second server 30 grants a bonus based on the digital assets owned by the user. However, the granting of bonuses from the second server 30 is not limited to being based on the owned digital assets. For example, there is a system in which events occur according to predetermined rules. In this case, the management means of the system stores the events caused by the user. The generation means of the system generates information related to the occurrence of an event at the request of the user.

Specifically, for example, there is a game in which events occur according to a predetermined rule. At this time, the management module 2033 of the first server 20 that provides the game manages the events (game progress) generated by the player. The generation module 2034 generates information about the occurrence of events (game progress, digital item acquisition status) upon request from the user.

The second server 30 sets the occurrence status of the event as a condition for the benefit. At this time, the granting module 3033 may, for example, use the extent to which the event has occurred as a condition. The granting module 3033 may also use the number of occurrences of a predetermined event as a condition. The granting module 3033 may also use a combination of predetermined events as a condition. The granting module 3033 may also include information linked to a predetermined event as a condition. For example, the granting module 3033 may use the state of the player when the event occurred as a condition. The granting module 3033 may also use the state and number of other players when the event occurred as a condition. The second server 30 grants a benefit to a user based on information related to the occurrence of the event provided by the user.

In a system where events occur according to specified rules, information about events generated by users may be stored on the blockchain as NFTs.

In this way, because users can receive rewards from other systems independent of the system in question based on the log of events that have occurred in that system, users are more motivated to cause events to occur. In other words, because players can receive rewards from a service provider other than the game based on their progress in a specific game, players are more motivated to progress in the game.

The second server 30 also grants rewards based on information related to events caused by the user. Therefore, when granting rewards, the second server 30 does not need to start the target game one by one and check the progress status within the game. The second server 30 only needs to check the existence of information proving progress (including, for example, NFT), which reduces operational effort. In addition, complex conditions can be set without much effort.

In the above embodiment, an example has been described in which all digital cards are managed in the card management table 2026. However, the digital cards managed in the card management table 2026 may be selected by the user. For example, the management module 2033 is capable of allocating record slots in the card management table 2026 to a user in response to a request from the user. The management module 2033 allocates to the user the number of record slots requested by the user. The management module 2033 may request a specified amount of assets from the user in accordance with the number of record slots allocated.

The user stores the desired digital card in the allocated record slot. That is, the user instructs the first server 20 to store the data of a specific digital card in one of the allocated record slots.

The management module 2033 stores information about a digital card specified by a user in a record frame. When a digital card stored in the record frame is used, the management module 2033 stores information about the use in a specified item in the record frame. On the other hand, when a digital card not stored in the record frame is used, no information about the use is stored, or less information is stored compared to the digital card stored in the record frame. The management module 2033 may allow other users to view only the digital cards stored in the record frame. Note that a specified number of record frames are assigned to each user, but the record frames assigned to a user may increase as the user pays a fee or progresses through the game.

This allows various information to be managed for the digital cards specified by the user. This reduces the management costs of the digital card game as a whole, while allowing the user to accurately manage information for the digital cards they feel are necessary.

In the above embodiment, the case where the user selects the desired benefit is described. However, the user is not required to select a benefit. When the user requests information about a digital asset, the first server 20 may generate information about the digital asset owned by the user by referring to the card management table 2026. In other words, the first server 20 may generate information about the digital asset without receiving any conditions for the digital asset from the user. The generated information about the digital asset is transmitted to the second server 30. The second server 30 compares the received information about the digital asset with the conditions stored in the benefit information table 3021, and determines the benefit that can be granted to the user.

This allows the user to acquire a reward without selecting a reward. It also allows the user to acquire a reward without specifying a digital asset.

In the above embodiment, a case has been described in which a user acquires a digital card by, for example, purchasing the digital card. However, a digital card may also be acquired by reading an analog card.

<4. Basic hardware configuration of computer>
20 is a block diagram showing the basic hardware configuration of a computer 90. The computer 90 includes at least a processor 91, a main storage device 92, an auxiliary storage device 93, and a communication IF (interface) 99. These are electrically connected to each other by a bus.

The processor 91 is hardware for executing a set of instructions written in a program. The processor 91 is composed of an arithmetic unit, registers, peripheral circuits, etc.

The main memory device 92 is used to temporarily store programs and data processed by the programs. For example, it is a volatile memory such as a DRAM (Dynamic Random Access Memory).

The auxiliary storage device 93 is a storage device for saving data and programs. For example, it is a flash memory, a hard disk drive (HDD), a magneto-optical disk, a CD-ROM, a DVD-ROM, a semiconductor memory, etc.

The communication IF 99 is an interface for inputting and outputting signals for communicating with other computers over a network using wired or wireless communication standards.

The network is composed of the Internet, LAN, various mobile communication systems constructed by wireless base stations, etc. For example, the network includes 3G, 4G, 5G mobile communication systems, LTE (Long Term Evolution), wireless networks that can connect to the Internet via a specified access point (e.g., Wi-Fi (registered trademark)), etc. In the case of a wireless connection, communication protocols include, for example, Z-Wave (registered trademark), ZigBee (registered trademark), Bluetooth (registered trademark), etc. In the case of a wired connection, the network also includes those directly connected by a USB (Universal Serial Bus) cable, etc.

The computer 90 can be realized virtually by distributing all or part of each hardware configuration across multiple computers 90 and connecting them together via a network. In this way, the concept of computer 90 includes not only a computer 90 housed in a single housing or case, but also a virtualized computer system.

<Basic Functional Configuration of Computer 90>
A description will be given of the functional configuration of a computer realized by the basic hardware configuration of a computer 90 shown in Fig. 20. The computer includes at least the functional units of a control unit, a storage unit, and a communication unit.

The functional units of the computer 90 can also be realized by distributing all or part of each functional unit across multiple computers 90 connected to each other via a network. The concept of computer 90 includes not only a single computer 90 but also a virtualized computer system.

The control unit is realized by the processor 91 reading out various programs stored in the auxiliary storage device 93, expanding them in the main storage device 92, and executing processing according to the programs. The control unit can realize functional units that perform various information processing depending on the type of program. In this way, the computer is realized as an information processing device that performs information processing.

The storage unit is realized by a main storage device 92 and an auxiliary storage device 93. The storage unit stores data, various programs, and various databases. Furthermore, the processor 91 can secure a storage area corresponding to the storage unit in the main storage device 92 or the auxiliary storage device 93 in accordance with a program. Furthermore, the control unit can cause the processor 91 to execute processes for adding, updating, and deleting data stored in the storage unit in accordance with the various programs.

The term "database" refers to a relational database, which is used to manage sets of data called tables, which are structured in a tabular format defined by rows and columns, by relating them to each other. In a database, a table is called a table, a column in a table is called a column, and a row in a table is called a record. In a relational database, it is possible to set relationships between tables and associate them.

Typically, each table has a column set as a key for uniquely identifying a record, but setting a key on a column is not essential. The control unit can cause the processor 91 to add, delete, or update records in a specific table stored in the memory unit according to various programs.

The communication unit is realized by the communication IF 99. The communication unit realizes the function of communicating with other computers 90 via a network. The communication unit can receive information transmitted from other computers 90 and input the information to the control unit. The control unit can cause the processor 91 to execute information processing on the received information in accordance with various programs. In addition, the communication unit can transmit information output from the control unit to other computers 90.

Although several embodiments of the present disclosure have been described above, these embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are considered to be within the scope of the invention and its equivalents as set forth in the claims, as well as within the scope and spirit of the invention.

<Additional Notes>
The matters described in the above embodiments will be supplemented below.
(Appendix 1)
A program to be executed by a computer having a processor and a memory, the program causing the processor to execute the steps of managing digital items included in digital assets, and generating, in response to a request from a user, information representing the digital items owned by the user to be transferred to the service in order to receive the grant of a bonus, where a service exists that grants bonuses based on the ownership status of the digital items.
(Appendix 2)
A program as described in claim 1, in which in the generating step, a specification of a digital item for which ownership status is to be confirmed is accepted from a user, and information indicating ownership of the specified digital item is generated.
(Appendix 3)
The program according to (Supplementary Note 1) or (Supplementary Note 2), wherein in the generating step, information indicating possession of a digital item to which predetermined related information is attached is generated.
(Appendix 4)
A program as described in any one of (Supplementary Note 1) to (Supplementary Note 3), wherein even if the information is generated in the generating step, it does not affect the digital item being managed.
(Appendix 5)
A program described in any one of (Appendix 1) to (Appendix 4), wherein the data structure of the digital item related to the information is not maintained.
(Appendix 6)
A program described in any one of (Appendix 1) to (Appendix 5), wherein in the managing step, the digital items are usable in a game provided by a specified entity, and in the generating step, the service is a service separate from the game.
(Appendix 7)
A program described in any of (Appendix 1) to (Appendix 6), in which in the management step, events generated by the user are managed, and in the generation step, a service exists that grants benefits depending on the occurrence circumstances of the event, and in response to a request from the user, information representing the event generated by the user is generated to be transferred to the service to receive the grant of a benefit.
(Appendix 8)
A program according to claim 7, wherein in the generating step, information indicating that an event to which the specified information is linked has occurred is generated.
(Appendix 9)
A program as described in any one of (Appendix 1) to (Appendix 8), in which in the managing step, the digital items are managed in a distributed ledger formed by a computer network.
(Appendix 10)
A program described in any one of (Appendix 1) to (Appendix 9), in which, in the generating step, the generated information is managed in a distributed ledger formed by a computer network.
(Appendix 11)
A program as described in Appendix 7, in which, in the management step, events generated by the user are managed in a distributed ledger formed by a computer network.
(Appendix 12)
A program to be executed by a computer having a processor and a memory, the program causing the processor to execute the steps of: receiving information representing a digital item owned by a specified user, the digital item being issued by a specified game service, usable in the game service, and included in a digital asset; and granting the user a benefit related to a service separate from the game service based on the information representing the digital item owned by the specified user that has been received.
(Appendix 13)
A method executed by a computer having a processor and a memory, the method comprising the steps of: managing digital items included in digital assets; and, in a service that grants rewards based on the ownership status of digital items, generating, in response to a request from a user, information representing the digital items owned by the user to be transferred to the service in order to receive the rewards.
(Appendix 14)
An information processing device having a control unit and a memory unit, wherein the control unit executes a step of managing digital items included in digital assets, and a step of generating, in response to a request from a user, information representing the digital items owned by the user to be transferred to the service in order to receive the grant of a bonus, where a service exists that grants bonuses depending on the ownership status of the digital items.
(Appendix 15)
A system comprising: means for managing digital items included in digital assets; means for setting conditions for granting a bonus according to the ownership status of the digital items; means for generating information representing the digital items owned by a user in response to a request from the user; means for changing the owner of the information from the user to a bonus provider; and means for granting a bonus when the user's ownership status of the digital items satisfies the conditions based on the information with the changed owner.

1... System 10... Terminal device 12... Communication IF
120...Communication unit 13...Input device 131...Touch-sensitive device 14...Output device 141...Display 15...Memory 150...Location information sensor 16...Storage 160...Camera 17...Audio processing unit 171...Microphone 172...Speaker 180...Memory unit 19...Processor 190...Control unit 20...Server

Claims (15)

A program for causing a computer having a processor and a memory to execute the program, the program causing the processor to:
managing digital items included in a digital estate;
A program that executes a step in which a service exists that grants benefits depending on the ownership status of digital items, and in response to a request from a user, generates information representing the digital items owned by the user to be transferred to the service in order to receive the benefit. The program according to claim 1, wherein in the generating step, a specification of a digital item for which ownership status is to be confirmed is received from the user, and the information indicating ownership of the specified digital item is generated. The program according to claim 1, wherein in the generating step, the information indicating the ownership of a digital item to which predetermined related information is attached is generated. The program according to claim 1, wherein in the generating step, generating the information does not affect the digital item being managed. The program of claim 1, wherein the data structure of the digital item related to the information is not maintained. In the managing step, the digital item is usable in a game provided by a predetermined entity;
2. The program according to claim 1, wherein in said generating step, said service is a service separate from said game. In the managing step, managing events generated by a user;
The program of claim 1, wherein in the generating step, a service exists that grants rewards depending on the occurrence of an event, and in response to a request from a user, information is generated that represents the event caused by the user and that can be transferred to the service to receive the reward. The program according to claim 7, wherein in the generating step, the information is generated to indicate that an event to which a specific piece of information is linked has occurred. The program according to claim 1, wherein in the managing step, the digital items are managed in a distributed ledger formed by a computer network. The program according to claim 1, wherein in the generating step, the generated information is managed in a distributed ledger formed by a computer network. The program according to claim 7, wherein in the managing step, the events generated by the user are managed in a distributed ledger formed by a computer network. A program for causing a computer having a processor and a memory to execute the program, the program causing the processor to:
receiving information representing a digital item owned by a given user, the digital item being issued by and available on a given game service, and included in a digital asset;
and a step of granting to the user a benefit related to a service separated from the game service based on information representing the digital item owned by the specified user that has been transferred. 1. A computer-implemented method comprising a processor and a memory, the processor comprising:
managing digital items included in a digital estate;
A method in which a service exists that grants rewards based on the ownership status of digital items, and in response to a request from a user, generates information representing the digital items owned by the user to be transferred to the service in order to receive the rewards. An information processing device including a control unit and a storage unit,
managing digital items included in a digital estate;
An information processing device that executes a step in which a service exists that grants benefits depending on the ownership status of digital items, and in response to a request from a user, generates information representing the digital items owned by the user to be transferred to the service in order to receive the benefit. a means for managing digital items included in the digital estate;
A means for setting conditions for granting benefits according to the ownership status of digital items;
means for generating, in response to a request from a user, information representative of the digital items owned by the user;
A means for changing the owner of the information from the user to a provider of the benefit;
and a means for granting the privilege when the user's ownership status of the digital item satisfies the condition based on the information regarding the change of owner.