Program, method, information processing device, and system

Abstract

To increase the interest to collect digital assets.SOLUTION: Provided is a program to be executed by a computer including a processor and a memory. The program causes the processor to execute the steps of: managing digital items included in the digital assets; and generating information where a service for imparting a privilege exists according to the ownership status of the digital items, digital items owned by a user is represented according to a request from a user, and which is transferred to the service in order to receive the imparting of the privilege.SELECTED DRAWING: Figure 16

Description

[Technical Field]

[0001] The present disclosure relates to a program, a method, an information processing device, and a system. [Background technology]

[0002] In recent years, digital TCGs (Trading Card Games) that are played using digital cards have been attracting attention. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-152815 Summary of the Invention [Problem to be solved by the invention]

[0004] In digital TCGs, players build decks by combining their owned digital cards. Building a deck requires multiple types of digital cards. When trying to build a deck that is superior to other decks, there are digital cards that cannot be included in the deck. Digital cards can sometimes be acquired through a lottery, but if players do not get the digital cards they need to build their deck, they may feel as if they lost the lottery.

[0005] Patent Document 1 also envisages that rare items, characters, etc. will be the subject of auctions.

[0006] The purpose of this disclosure is to increase the interest in collecting digital assets. [Means for solving the problem]

[0007] 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 user request, information representing the digital items owned by the user to be transferred to the service in order to receive the benefit, where a service exists that provides a benefit depending on the ownership status of the digital items. [Effects of the Invention]

[0008] The present disclosure aims to increase the interest in collecting digital assets. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram showing an example of the overall configuration of a system 1. FIG. [Figure 2] 2 is a block diagram illustrating an example of the configuration of a terminal device 10 shown in FIG. [Figure 3] FIG. 2 is a diagram illustrating an example of a functional configuration of a first server 20. [Figure 4] FIG. 2 is a diagram illustrating an example of a functional configuration of a second server 30. [Figure 5] FIG. 10 is a diagram showing the data structure of card information 182. [Figure 6] FIG. 10 is a diagram showing the data structure of deck information 183. [Figure 7] FIG. 2 is a diagram showing the data structure of a user information table 2021. [Figure 8] FIG. 10 is a diagram showing the data structure of a card master table 2022. [Figure 9] FIG. 20 is a diagram showing the data structure of a deck information table 2023. [Figure 10] FIG. 10 is a diagram showing the data structure of a match information table 2024. [Figure 11] FIG. 10 is a diagram showing the data structure of a card management table 2026. [Figure 12] 10 is a diagram showing the data structure of a benefit information table 3021 stored in the second server 30. FIG. [Figure 13] FIG. 10 is a diagram illustrating an example of the operations of the terminal device 10 and the first server 20 when a user purchases a card. [Figure 14] FIG. 10 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. [Figure 15] 10 is a diagram illustrating an example of the operation of the terminal device 10 and the first server 20 when managing cards based on the support of users. FIG. [Figure 16] FIG. 10 is a diagram illustrating an example of the operations 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. [Figure 17] 10 is a schematic diagram showing an example of a display on a display 141 of a terminal device 10. FIG. [Figure 18] 10 is a schematic diagram showing an example of a display on a display 141. FIG. [Figure 19] 10 is a schematic diagram showing an example of a display on a display 141. FIG. [Figure 20] FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. The names and functions of the components are also the same. Therefore, detailed descriptions thereof will not be repeated.

[0011] <Summary> In this embodiment, a server that provides digital assets manages digital assets owned by users. The users request information indicating their ownership status of their digital assets from the server. In response to the user's request, the server generates information indicating the user's ownership status of the digital assets and transmits it to the user. The users transfer the generated information to a service provider that provides a specified service, thereby receiving benefits corresponding to the digital assets they own.

[0012] In this embodiment, a case will be described in which digital cards related to a TCG are managed as digital items included in digital assets.

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

[0014] 1 shows an example 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.

[0015] FIG. 1 shows an example in which the system 1 includes one first server 20 and one second server 30, but the number of first servers 20 and second servers 30 included in the system 1 is not limited to one each. The first server 20 and the second server 30 may be configured from multiple servers depending on the functions they have. Furthermore, the first server 20 and the second server 30 may be, for example, a collection of multiple devices considered as a single server. The way in which the multiple functions required to realize the first server 20 and the second server 30 according to this embodiment are allocated to one or multiple pieces of hardware can be determined appropriately 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.

[0016] 1 is, for example, an information processing device operated by a user who plays a digital TCG. The terminal device 10 is realized by, for example, 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 a wearable terminal such as an HMD (Head Mount Display).

[0017] 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 receiving input operations from a user. The output device 14 is a device (e.g., a display, a speaker, etc.) for presenting information to a user.

[0018] 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 rephrased as, for example, an information processing device that manages digital assets related to services used by users.

[0019] The first server 20 is realized by, for example, a computer connected to a 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 receiving input operations from a user and as an interface with an output device for presenting information to the user.

[0020] The second server 30 is, for example, an information processing device that manages information related to a predetermined 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 predetermined benefits to users based on the users' digital assets managed by the first server 20. There may or may not be a predetermined relationship between the person managing the first server 20 and the person managing the second server 30.

[0021] The second server 30 is realized by, for example, 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 receiving input operations from a user and as an interface with an output device for presenting information to the user.

[0022] 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, descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer will be omitted.

[0023] <1.1 Terminal device configuration> Fig. 2 is a block diagram showing an example 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 by, for example, a bus or the like.

[0024] The communication unit 120 performs processing such as modulation and demodulation 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 (for example, 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.

[0025] The input device 13 is a device for inputting instructions or information by a user operating the terminal device 10. The input device 13 is realized, for example, by a touch-sensitive device 131 or the like, which inputs instructions by touching an 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.

[0026] The output device 14 is a device for presenting information to a user operating 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.

[0027] The audio processing unit 17 performs, for example, digital-to-analog conversion processing of an audio signal. The audio processing unit 17 converts a 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 receives 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.

[0028] The camera 160 is a device that receives light with a light receiving element and outputs the light as an image capturing signal.

[0029] 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 the 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.

[0030] The storage unit 180 is realized by, for example, the memory 15, the storage 16, etc., 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.

[0031] The user information 181 includes, for example, information about the user who plays the TCG. The information about the user includes, for example, the user ID, the user's name, age, address, date of birth, and date of registration.

[0032] The card information 182 includes, for example, information about cards. The card information 182 may include information about cards owned by the user. Details will be described later.

[0033] The deck information 183 includes, for example, information about a deck constructed by a user, which will be described in detail later.

[0034] The control unit 190 is realized by the processor 19 reading a program stored in the storage unit 180 and executing instructions included in the program. The control unit 190 controls the operation of the terminal device 10. By operating in accordance with 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.

[0035] 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 or the like.

[0036] Furthermore, the operation receiving unit 191 receives an image input from the camera 160. Specifically, for example, the operation receiving unit 191 receives image data captured by the camera 160.

[0037] Furthermore, the operation reception unit 191 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.

[0038] The transmitting / receiving 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 transmitting / receiving unit 192 transmits instructions input by the user or various pieces of acquired information to the first server 20. The transmitting / receiving unit 192 also receives information provided from the first server 20. The information provided from the first server 20 includes, for example, information about cards newly acquired by the user, information about decks registered in the first server 20, information created based on cards (digital assets) managed by the first server 20, and the like. The transmitting / receiving unit 192 also transmits predetermined information to the second server 30.

[0039] 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 provided via cards, the management unit 193 updates the card information 182. Furthermore, when a deck is organized, the management unit 193 updates the deck information 183.

[0040] 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 for cards owned by the user based on information managed in the card information 182 and information managed in the deck information 183. The display control unit 194 may also control the display 141 to display a management screen for cards owned by the user based on information managed by the first server 20. The display control unit 194 also controls the display 141 to display information associated with 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 associated with 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 by the first server 20 based on cards (digital assets) managed by the first server 20.

[0041] The battle processing unit 195 controls the battle processing with other users. The battle may take the following forms, for example. - Play against the CPU using a deck built with digital cards - Battle other players using decks built with digital cards Tournament matches

[0042] <1.2 Functional configuration of the first server> 3 is a diagram illustrating an example of the functional configuration of the first server 20. As illustrated in FIG. 3, the first server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

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

[0044] The storage unit 202 includes, for example, a user information table 2021, a card master table 2022, a deck information table 2023, a battle information table 2024, and a card management table 2026.

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

[0046] The card master table 2022 is a table that stores, for example, information about cards available to users, as will be described in detail later.

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

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

[0049] The card management table 2026 is a table that stores, for example, information for managing cards acquired by users, as will be described in detail later.

[0050] The control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. The control unit 203 operates in accordance with the program to fulfill the functions of a reception control module 2031, a transmission control module 2032, a management module 2033, a generation module 2034, and a battle processing module 2035.

[0051] The reception control module 2031 controls the process in which the first server 20 receives a signal from an external device in accordance with a communication protocol.

[0052] The transmission control module 2032 controls the process of the first server 20 transmitting a signal to an external device in accordance with a communication protocol. Specifically, for example, the transmission control module 2032 transmits information based on the owned digital assets, which is generated by the first server 20, to the terminal device 10.

[0053] The management module 2033 manages tables stored in the storage unit 202. In other words, the management module 2033 manages 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 battle, it updates the battle information table 2024 and the card management table 2026. When the management module 2033 receives information related to cheering, it also updates the card management table 2026.

[0054] The generation module 2034 generates information according to digital assets managed by the first server 20. For example, when a user requests information indicating that the user owns digital assets that satisfy predetermined conditions, the generation module 2034 generates the requested information. Specifically, for example, when a user requests information indicating that the user owns two or more predetermined digital cards, the generation module 2034 generates the requested information. The digital cards desired by the user are not necessarily based on the rarity of the cards. The digital cards desired by the user are set, for example, by the second server 30. Furthermore, for example, the generation module 2034 may generate the requested information when a user requests information indicating that the user owns a digital card on which a predetermined record is kept. A 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 predetermined support is stored, or a digital card on which a predetermined transaction has been made.

[0055] Furthermore, for example, when a user requests information indicating that the user has a predetermined deck, the generation module 2034 generates the requested information. The deck desired by the user is set, for example, by the second server 30. Furthermore, for example, when a user requests information indicating that the user has a deck on which a predetermined record is kept, the generation module 2034 may generate the requested information. A deck on which a predetermined record is kept refers to, for example, a deck on which information regarding a predetermined battle is stored.

[0056] The battle processing module 2035 controls the processing of battles between users. For example, the battle processing module 2035 controls battles between players using decks constructed with digital cards.

[0057] <1.3 Functional configuration of the second server> 4 is a diagram illustrating an example of the functional configuration of the second server 30. As illustrated in FIG. 4, the second server 30 functions as a communication unit 301, a storage unit 302, and a control unit 303.

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

[0059] The storage unit 302 includes, for example, a privilege information table 3021. The privilege information table 3021 is a table that stores, for example, information (privilege information) related to privileges to be granted to users. Details will be described later.

[0060] The control unit 303 is realized by the processor 39 reading a program stored in the storage unit 302 and executing instructions included in the program. The control unit 303 functions as a reception control module 3031, a transmission control module 3032, and an assignment module 3033 by operating in accordance with the program.

[0061] The reception control module 3031 controls the process of the second server 30 receiving a signal from an external device in accordance with a communication protocol. Specifically, for example, the reception control module 3031 receives, from the terminal device 10, information indicating that the user owns a predetermined digital asset.

[0062] The transmission control module 3032 controls the process of transmitting a signal to an external device by the second server 30 in accordance with a communication protocol. Specifically, for example, the transmission control module 3032 transmits information related to a benefit to the terminal device 10.

[0063] The granting module 3033 grants a reward to a user. For example, the granting module 3033 references the reward information table 3021 and determines whether the digital asset owned by the user satisfies the conditions for granting a reward. If the conditions are met, the granting module 3033 grants the reward to the user. The granting of the reward to the user may be realized, for example, by the transmission control module 3032 transmitting the reward to the user. Alternatively, the granting of the reward to the user may be realized, for example, by handing the reward to the user at a store after the granting module 3033 confirms that the conditions for granting the reward are met.

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

[0065] Fig. 5 is a diagram showing the data structure of card information 182. Card information 182 shown in Fig. 5 is a table having columns such as card ID, name, type, attribute, card information, battle information, support information, image data, etc., with card management ID as a key. In addition to these, card information 182 may also have information such as regulations or rarity.

[0066] The card management ID is an item that stores an identifier for uniquely identifying a card. In this embodiment, different card management IDs are assigned to cards with the same name, same effect, same rarity, and same regulations, i.e., exactly the same cards. 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.).

[0067] Attributes are items that store the characteristics to which a character belongs. In this embodiment, attributes include, for example, fire, water, lightning, grass, super, steel, dark, and fighting. Attributes include attributes that are advantageous when facing other characters, and attributes that are disadvantageous when facing other characters. Card information is an item that stores information that explains the contents of a card. If the card type is a 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, and special characteristics possessed by the character. If the card type is support, goods, or stadium, the card information includes, for example, the requirements for using the card, the effects that occur when the card is used, and the like.

[0068] 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 information that identifies a battle that was conducted by a user using a deck that incorporated the corresponding card as the battle information. 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.

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

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

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

[0072] The deck ID is an item that stores an identifier for uniquely identifying a deck. The name is an item that stores the name of the deck. The name is given, for example, by the user. The 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.

[0073] Completed is an item that stores whether or not a 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 a deck has been assembled with a specified number of cards and is ready to be used in a battle. Update date is an item that stores the date on which the deck configuration was changed. In calculating the update date, using cards used in one deck in another deck may also be treated as a change. Registration information is an item that stores the relationship with decks registered in the first server 20. The registration information stores, for example, a deck code that is issued when a deck is registered in the first server 20.

[0074] A record about a deck is added when a new deck is created on the terminal device 10 in response to an instruction from the user.

[0075] 7 to 11 are diagrams showing the data structure of information stored in the first server 20. Note that FIGS. 7 to 11 are merely examples, and do not exclude data not shown.

[0076] Fig. 7 is a diagram showing the data structure of the user information table 2021. The user information table 2021 shown in Fig. 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.

[0077] 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 began using the TCG-related services.

[0078] A record in the user information table 2021 is added when a new user is registered.

[0079] Fig. 8 is a diagram showing the data structure of the card master table 2022. The card master table 2022 shown in Fig. 8 is a table having columns such as name, type, attribute, card information, and image data, with the card ID as a key.

[0080] 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 explains the contents of the card. The image data is an item that stores an image.

[0081] A record in the card master table 2022 is added, for example, when a new card is issued.

[0082] Fig. 9 is a diagram showing the data structure of the deck information table 2023. The deck information table 2023 shown in Fig. 9 is a table having columns such as name, user ID, registration date, first organization card, second organization card, and disclosure, with the deck code as a key. In addition to these, the deck information table 2023 may also have information such as the nickname of the deck.

[0083] The deck code is an item that stores an identifier for uniquely identifying a registered deck. A deck code is issued by the management module 2033 when a user registers a new deck. The deck code shown in FIG. 9 is an identifier that is different from, for example, 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.

[0084] The first organization card and the second organization card are items that store the cards that will be used to organize the deck. The first organization card, for example, stores the card IDs of the cards that will be used to organize the deck. The second organization card, for example, stores the card management IDs of the cards that will be used to organize the deck. Public is an item that stores whether or not the deck is public to other users. In this embodiment, a circle indicates that the deck is public to other users, and a cross indicates that the deck is not public to other users. In this embodiment, a deck that is not public means that only the player can view it.

[0085] A record in the deck information table 2023 is added when a new deck is registered.

[0086] Fig. 10 is a diagram showing the data structure of the match information table 2024. The match information table 2024 shown in Fig. 10 is a table having columns such as date and time, opponent, deck code, winner, match log information, and tournament information, with a match ID as a key.

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

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

[0089] The winner is an item that stores the winner of a match. The 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 predetermined placement section (such as the deck or a win / loss condition card), the player placing a card in a predetermined placement section, and the player using the effect of a predetermined card. The moves adopted by players during a match may also be referred to as deck rotations during the match. The tournament information is an item that stores information about the 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 from 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 from private matches.

[0090] A record is added to the match information table 2024 when a new match is registered.

[0091] Fig. 11 is a diagram showing the data structure of the card management table 2026. The card management table 2026 shown in Fig. 11 is a table having columns such as card ID, match information, support information, owner, transferee, transferor, transaction date, and consideration, with the card management ID as a key.

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

[0093] The transferee, transferor, transaction date, and consideration are items that store information about transactions of a card identified by the card management ID. The transferee, transferor, transaction date, and consideration are added for each transaction. The transferee represents the person who received the card in the transaction. The transferor represents the person who transferred the card in the transaction. The transaction date represents the date the transaction was carried out. The consideration represents the fee paid by the transferee to the transferor when trading the card.

[0094] Fig. 12 is a diagram showing the data structure of a benefit information table 3021 stored in the second server 30. Note that Fig. 12 is an example and does not exclude data not shown. The benefit information table 3021 shown in Fig. 12 is a table having columns for benefit content, conditions, etc., with a benefit ID as a key.

[0095] The privilege ID is an item that stores an identifier for uniquely identifying a privilege. The privilege content is an item that stores the content of the privilege. The condition is an item that stores the conditions under which the privilege is granted. The privilege content may be, 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 privilege content may be a discount on the fee.

[0096] <3 operations> 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.

[0097] (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 that allows the user to know the contents of the cards. Alternatively, the first server 20 may sell cards in a manner that prevents the user from knowing the contents of the cards. The first server 20 sells cards in units of one card. Alternatively, the first server 20 may sell cards in units of multiple cards.

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

[0099] FIG. 13 is a diagram illustrating an example of the operations of the terminal device 10 and the first server 20 when a user purchases a card.

[0100] When purchasing a card, a user accesses the first server 20 using the terminal device 10. 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.

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

[0102] In step S12, the first server 20 acquires a card based on a card purchase request from the user. Specifically, for example, the first server 20 acquires the card selected by the user by consuming predetermined assets associated with the user via the management module 2033. The predetermined assets are, for example, as follows: Game media used in games Cryptocurrency ·token Currency information

[0103] If the user selects a card that is sold in a manner that allows the contents of the card to be known, the management module 2033 acquires the card ID of the card selected by the user. If the user selects a card that is sold in a manner that prevents the contents of the card from being known, 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.

[0104] In step S13, the management module 2033 updates the card management table 2026 based on the acquired card ID. Specifically, for example, when the management module 2033 acquires the card ID of a card that is sold in a manner that allows the card contents to be ascertained, or when the management module 2033 acquires the card ID of 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.

[0105] Furthermore, 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 card owner 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.

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

[0107] In step S15, the terminal device 10 receives the information transmitted from the first server 20, and based on the received information, updates the card information 182. 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.

[0108] (Card management table update process, battle information storage) The control unit 203 of the first server 20 uses the management module 2033 to manage, for each card, information on which card was used in the match.

[0109] A user builds a deck by combining cards managed in card information 182. Management unit 193 manages information related to the deck built by the user in deck information 183.

[0110] 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 register the deck constructed from the selected cards and the name of the deck into the terminal device 10. The user may set whether or not to make the registered deck public to other users.

[0111] When a deck registration request is input by the user, the management module 2033 issues a new deck code and creates a record with the issued deck code as a key in the deck information table 2023. 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.

[0112] FIG. 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 users in a match.

[0113] When starting a match, the user accesses the first server 20 using the terminal device 10. The terminal device 10 displays a registration form for match information set in the first server 20 on the display 141. The user uses the form displayed on the display 141 to input information about the match. The information about the match includes, for example, the date and time of the match, 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.

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

[0115] In step S22, the first server 20 updates the card management table 2026 based on the battle information input by the user. Specifically, for example, when a battle information registration request is input by the user, the management module 2033 issues a battle ID and creates a record with the issued battle ID as a key in the battle information table 2024. 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.

[0116] The date, 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 deck 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.

[0117] After storing information in the match information table 2024, the management module 2033 updates the card management table 2026. Based on the card management ID of the card 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" field of the corresponding record in the card management table 2026. The more matches there are, the more information stored in the match information. This makes it possible to know in which matches the cards were used.

[0118] 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, card management ID, and 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.

[0119] 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 causes the management unit 193 to store the battle information received from the first server 20, for example, the battle ID, in the item "battle information" of the record identified by the card management ID.

[0120] When a match starts, 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.

[0121] (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 associated with the card for each card.

[0122] A user may support a player who uses a deck that includes cards that the user has a special attachment to. In this embodiment, support for a deck related to cards is managed in association with card information.

[0123] FIG. 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 the support of users.

[0124] For example, assume that information regarding tournament participants and the decks they will use is made public before a tournament is held. A user references the tournament participants and their decks and selects the player they will support. The user accesses the first server 20 using the terminal device 10 before the tournament is held or a predetermined time on the day of the tournament. The terminal device 10 displays on the display 141 a support form set in the first server 20. The user uses the form displayed on the display 141 to select a card that will be the basis of the support and enters another player who uses the deck they will support in association with the selected card. After entering the support information, the user inputs a request to register the support information into 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 they will support. The user ID of the player they will support may be the participant ID when participating in the tournament. The support information may also include, for example, information identifying the tournament and information identifying the match in the tournament.

[0125] The card that serves as 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 certain card, they may feel a desire to cheer for a player who uses a deck that includes cards that have the same effect as that card. Based on the cards they own, users cheer for a player who uses a deck that includes those cards. Note that the cards to be cheered for may have 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 a player who uses that deck.

[0126] 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 support one player throughout the tournament, or the player that is supported may change for each match.

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

[0128] The control unit 190 may set, via the management unit 193, that the user cannot use the cards that are the basis of the support in the deck while the deck is being supported. This will encourage the user to take more care in selecting the deck to support, since the selected deck cannot be used while the deck is being supported.

[0129] In step S31, the terminal device 10 accepts a request to register cheering information input by the user via the operation accepting unit 191. The terminal device 10 transmits the input cheering information and the registration request to the first server 20 via the transmitting / receiving unit 192.

[0130] In step S32, the first server 20 updates the card management table 2026 based on the information about cheering input by the user. Specifically, for example, when a request to register cheering information 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 information about cheering 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 predetermined 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 cheering times increases, the amount of information stored in the cheering information increases. This makes it possible to grasp the cheering that has been done based on the cards.

[0131] 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 of the owner. The transmission control module 2032 transmits the read battle ID, user ID, and card management ID to the terminal device 10 owned by the user identified by the user ID.

[0132] 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 causes the management unit 193 to store the support information received from the first server 20, such as the battle ID and user ID, in the item "support information" of the record identified by the card management ID.

[0133] When a match starts, 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 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 in 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 also be stored in the match information table 2024 as a result of the tournament.

[0134] (Benefit granting process) The second server 30 provides a service independent of the TCG-related service. In other words, the second server 30 provides a service separate from the TCG-related service. Specifically, the second server 30 is, for example, an aquarium, a museum, a retail store, or a restaurant.

[0135] 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, that the second server 30 provides a portion 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, for example, an aquarium, a museum, a retail store, or a restaurant as a service, 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.

[0136] 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 portion of the service provided by the second server 30 in accordance with the digital assets owned by the user for the service provided by the first server 20.

[0137] The predetermined requirement that changes the predetermined period refers to, for example, the number of products provided in the predetermined relationship or the number of users related to the predetermined 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 the campaign product according to the digital assets owned by the user for the service provided by the first server 20, for example, until the campaign product runs out. Also, if the benefit is a campaign experience with a limited number of participants, the period ends when the limited number of participants is reached. In other words, the second server 30 provides the user with the 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 predetermined number.

[0138] In the following description, an example will be described in which the second server 30 grants a benefit to a user according to a digital card held by the user.

[0139] FIG. 16 is a diagram illustrating an example of the operations 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.

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

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

[0142] Specifically, for example, the granting module 3033 sets that product AAAA will be granted on the condition that the user possesses a digital card with card ID: C0001, C0002, or C0003.

[0143] In step S42, the second server 30 makes the set benefit information public by a predetermined method, which may be any existing method.

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

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

[0146] The display control unit 194 displays the benefit 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 the digital assets. The difficulty of collecting the digital assets can be calculated, for example, based on the rarity of the digital cards. In FIG. 17 , the display control unit 194 displays information about one benefit in object 14112. In object 14112, the display control unit 194 displays the product name and the digital asset required as a condition.

[0147] The display control unit 194 may display only information related to benefits that satisfy conditions for digital assets in the area 1411. 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 related to benefits that satisfy the conditions. The display control unit 194 displays the extracted information related to 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 can be acquired.

[0148] In FIG. 17, the user selects a desired benefit and performs an operation of touching an object that displays the selected benefit.

[0149] When the user touches the object, the display control unit 194 of the terminal device 10 displays a screen for confirming that the user wants to acquire the selected benefit.

[0150] Fig. 18 is a schematic diagram showing an example of display on the display 141. In the example shown in Fig. 18, the display control unit 194 displays a window 14113 for confirming that the user wants to acquire the selected benefit. The window 14113 displays buttons 141131 and 141132 for inputting the user's intention. If the user is sure about 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 an input of a request to grant the benefit.

[0151] In step S44, the terminal device 10 receives a generation request and an assignment request input by the user via the operation reception unit 191. The terminal device 10 transmits the generation request to the first server 20 via the transmission / reception unit 192. The generation request includes, for example, user identification information (e.g., user ID, a predetermined address set for the user) and information related to the conditions (e.g., card ID).

[0152] 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 using 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.

[0153] In step S46, the first server 20 generates information related to the digital asset. Specifically, if the user has the digital card 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 related to the digital asset.

[0154] The certification information is, for example, information indicating that the required number of cards with the target card ID are possessed. Furthermore, the certification information is, for example, information indicating that the required number of digital cards with required additional information attached are possessed. Furthermore, the certification information is, 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.

[0155] 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 in the data structure of the digital items managed by the first server 20.

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

[0157] 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 via 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 (e.g., user ID, a predetermined address set for the user) and information identifying the benefit selected by the user.

[0158] In step S48, the second server 30 grants a benefit 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 granting module 3033. The granting module 3033 acquires the user's identification information and the identification information of the selected benefit from the grant request. The granting module 3033 reads the conditions for the benefit selected by the user from the benefit information table 3021. The granting module 3033 compares the information about the digital asset with the conditions for the benefit. If the information about the digital asset matches the conditions for the benefit, the granting module 3033 grants the benefit to the user.

[0159] When the second server 30 grants the privilege to the terminal device 10, the display control unit 194 displays a screen for notifying the user that the privilege has been granted.

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

[0161] 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 digital items included in 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.

[0162] Therefore, according to this embodiment, it is possible to increase the interest in collecting digital assets.

[0163] 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, thereby reducing the processing load of the generation module 2034.

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

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

[0166] Furthermore, 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 proliferation of digital items.

[0167] In the above embodiment, the digital items can be used in a game provided by a specific entity. The service that provides benefits based 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 the service separate from the game, thereby providing motivation to play the game. Furthermore, it also reduces the burden on the service provider when linking the service with the game.

[0168] <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 blockchain (distributed ledger) formed by a P2P computer network.

[0169] 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 related to 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 related to the conditions included in the generation request.

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

[0171] Furthermore, management of NFT usage is carried out, for example, by smart contracts implemented on the blockchain. The history of NFT usage is stored on the blockchain as transactions. This allows the history of NFT usage in battles and the history of support for other players based on NFTs to be stored on the blockchain.

[0172] Furthermore, the granting of rewards related to the NFT usage history 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 certain reward. Also, when the history of supporting another player based on the NFT meets certain requirements, the owner of the NFT at that time is granted a certain reward.

[0173] The granting module 3033 may be implemented, 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.

[0174] 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 also 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 public records of digital cards.

[0175] Furthermore, the management module 2033 stores information about card usage as a corresponding digital card transaction in the distributed ledger. Alternatively, the management unit 193 may store information about card usage as a corresponding digital card transaction in the distributed ledger. This makes it possible to keep a transparent record of the digital card usage history.

[0176] Furthermore, the management module 2033 or the management unit 193 stores information about the battle as a transaction of the corresponding digital card in the distributed ledger, thereby making it possible to keep a public record of information about the battle of digital cards.

[0177] Furthermore, 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, thereby making it possible to keep a transparent record of information about cheering based on the digital card.

[0178] The management module 2033 or the management unit 193 also stores information about the transaction in the distributed ledger as a digital card transaction, thereby making it possible to keep a transparent record of digital card transactions.

[0179] 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 storage 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 storage 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.

[0180] In the above embodiment, the use of cards has been described as examples of playing a match using a deck of cards and cheering on players based on the cards. However, the use of cards is not limited to these. For example, the use of cards may also include displaying cards.

[0181] In the above embodiment, the digital items included in the digital assets are digital cards. However, the digital items are not limited to digital cards. The digital items may be digital characters or the like.

[0182] In the above embodiment, a case has been described in which a benefit is granted from the second server 30 in accordance with the digital assets owned by the user. However, the granting of a benefit 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 events caused by the user. The generation means of the system generates information regarding the occurrence of an event in response to a request from the user.

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

[0184] The second server 30 sets the occurrence status of the event as a condition for the benefit. In this case, the granting module 3033 may use, for example, how many times the event has occurred as a condition. The granting module 3033 may also use, for example, the number of occurrences of a predetermined event as a condition. The granting module 3033 may also use, for example, 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, for example, the state of the player when the event occurred as a condition. The granting module 3033 may also use, for example, 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 presented by the user.

[0185] In a system in which events occur according to predetermined rules, information about events generated by users may be stored on the blockchain as NFTs.

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

[0187] Furthermore, the second server 30 grants rewards based on information about 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 confirm the existence of information (including, for example, NFTs) that proves progress, which reduces operational effort. Furthermore, complex conditions can be set without much effort.

[0188] 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 the number of record slots requested by the user to the user. The management module 2033 may request a predetermined amount of assets from the user in accordance with the number of allocated record slots.

[0189] 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 predetermined digital card in one of the allocated record slots.

[0190] 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 predetermined 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 than for 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 predetermined number of record frames are allocated to each user, but the record frames allocated to that user may increase as the user pays a fee or progresses through the game.

[0191] This allows various information to be managed for the digital cards selected by the user, reducing the management costs of the digital card game as a whole while enabling accurate management of information for the digital cards that the user feels are necessary.

[0192] Furthermore, in the above embodiment, a case where the user selects a desired benefit is described. However, the user's selection of a benefit is not required. 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.

[0193] This allows the user to acquire a benefit without selecting a benefit, and also allows the user to acquire a benefit without specifying a digital asset.

[0194] In the above embodiment, the user acquires a digital card by purchasing the digital card, etc. However, the user may acquire a digital card by reading an analog card.

[0195] <4 Basic computer hardware configuration> 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 memory device 92, an auxiliary memory device 93, and a communication IF (interface) 99. These are electrically connected to each other by a bus.

[0196] The processor 91 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

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

[0198] The auxiliary storage device 93 is a storage device for saving data and programs, such as a flash memory, a hard disk drive (HDD), a magneto-optical disk, a CD-ROM, a DVD-ROM, or a semiconductor memory.

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

[0200] 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 predetermined 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 a network that is directly connected using a USB (Universal Serial Bus) cable, etc.

[0201] It should be noted that the computer 90 can be virtually realized by distributing all or part of each hardware configuration across multiple computers 90 and interconnecting them via a network. In this way, the computer 90 is a concept that includes not only a computer 90 housed in a single housing or case, but also a virtualized computer system.

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

[0203] The functional units of the computer 90 can also be realized by distributing all or part of the functional units among multiple computers 90 interconnected via a network. The computer 90 is a concept that includes not only a single computer 90 but also a virtualized computer system.

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

[0205] 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 allocate a storage area corresponding to the storage unit in the main storage device 92 or the auxiliary storage device 93 in accordance with the programs. 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.

[0206] A database refers to a relational database, which manages data sets called tables, which are structured 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, relationships between tables can be set and associated.

[0207] Usually, each table has a column set as a key for uniquely identifying a record, but setting a key to 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 storage unit according to various programs.

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

[0209] Although several embodiments of the present disclosure have been described above, these embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and modifications are intended to be included in the scope of the inventions and their equivalents as defined in the claims, as well as in the scope and spirit of the inventions.

[0210] <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 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 benefit, where a service exists that grants benefits depending on the ownership status of the digital items. (Appendix 2) The program according to claim 1, wherein the generating step receives, from the user, a designation of a digital item for which ownership status is to be confirmed, and generates information indicating that the designated digital item is owned. (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) The program according to any one of (Supplementary Note 1) to (Supplementary Note 3), wherein in the generating step, even if the information is generated, it does not affect the digital item being managed. (Appendix 5) The program according to any one of (Supplementary Note 1) to (Supplementary Note 4), wherein the information does not maintain the data structure of the digital item related to the information. (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 managing step, events generated by the user are managed, and in the generating step, there is a service that grants benefits depending on the occurrence status 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 in order to receive the grant of a benefit. (Appendix 8) The program according to claim 7, wherein in the generating step, information indicating that an event linked to the predetermined information has occurred is generated. (Appendix 9) The program according to any one of (Appendix 1) to (Appendix 8), wherein in the managing step, the digital items are managed in a distributed ledger formed by a computer network. (Appendix 10) A program according to any one of (Appendix 1) to (Appendix 9), wherein 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 managing 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 digital assets; 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 received specified user. (Appendix 13) A method executed by a computer having a processor and memory, wherein the processor executes the steps of managing digital items included in digital assets, and 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. (Appendix 14) An information processing device having a control unit and a memory unit, wherein the control unit executes the steps of managing digital items included in digital assets, and a step of generating, in response to a request from a user, information to be transferred to the service in order to receive a benefit, representing the digital items owned by the user, where a service exists that grants benefits 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 benefits 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 provider of the benefit; and means for granting a benefit if the user's ownership status of the digital items satisfies the conditions based on the information with the changed owner. [Explanation of symbols]

[0211] 1. System 10...Terminal device 12...Communication IF 120…Communications Department 13...Input device 131...Touch-sensitive devices 14...Output device 141...Display 15...Memory 150...Location information sensor 16…Storage 160...camera 17...Audio processing unit 171...Mike 172...Speaker 180...Storage section 19...Processor 190...Control unit 20...Server

Claims

1. A program to be executed by a computer having a processor and a memory, the program causing the processor to: managing digital items included in a digital asset; a step 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 benefit, wherein a service exists that grants a benefit depending on the ownership status of the digital items; A program that executes the following.

2. 2. The program according to claim 1, wherein the generating step receives from the user a specification of a digital item for which ownership status is to be confirmed, and generates the information indicating that the specified digital item is owned.

3. 2. The program according to claim 1, wherein the generating step generates the information indicating that the user owns a digital item to which predetermined related information is attached.

4. 2. The program according to claim 1, wherein in the generating step, even if the information is generated, the digital item being managed is not affected.

5. The program according to claim 1 , wherein the information does not maintain a data structure of a digital item related to the information.

6. In the managing step, the digital item can be used in a game provided by a predetermined entity; 2. The program according to claim 1, wherein in the generating step, the service is a service separate from the game.

7. In the managing step, managing events generated by a user; The program of claim 1, wherein in the generating step, there is a service that grants benefits depending on the occurrence of an event, and in response to a request from a user, information representing the event caused by the user is generated to be transferred to the service in order to receive the benefit.

8. 8. The program according to claim 7, wherein the generating step generates the information indicating that an event linked to predetermined information has occurred.

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

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

11. 8. The program according to claim 7, wherein in the managing step, events generated by the user are managed in a distributed ledger formed by a computer network.

12. A program to be executed by a computer having a processor and a memory, the program causing the processor to: receiving information representing a digital item owned by a given user, the digital item being issued by a given game service, usable on the game service, and included in a digital asset; granting a benefit related to a service separated from the game service to the user based on information representing the digital item owned by the transferred user; A program that executes the following.

13. 1. A computer-implemented method comprising a processor and a memory, the processor: managing digital items included in a digital asset; a step 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 benefit, wherein a service exists that grants a benefit depending on the ownership status of the digital items; How to do it.

14. An information processing device including a control unit and a storage unit, wherein the control unit: managing digital items included in a digital asset; a step 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 benefit, wherein a service exists that grants a benefit depending on the ownership status of the digital items; An information processing device that executes the above.

15. a means for managing digital items included in the digital asset; 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; means for granting the benefit when the user's ownership status of the digital item satisfies the condition based on the information on the change of owner; A system comprising:

Images