Program, method, information processing apparatus, system
The program addresses the challenge of building advantageous decks in digital TCGs by managing digital items and granting privileges based on ownership, enhancing the interest and engagement in collecting digital assets.
Patent Information
- Application Number
- JP2022172297
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-10-27
- Publication Date
- 2025-06-09
- Estimated Expiration
- 2042-10-27
AI Technical Summary
In digital Trading Card Games (TCGs), players face challenges in building decks that are advantageous due to the rarity of digital cards, leading to frustration when they cannot acquire necessary cards, even through lotteries or auctions.
A program that manages digital items within digital assets, allowing users to request and generate information representing their owned digital items, which can be used to grant privileges in a service, enhancing the interest in collecting digital assets.
The solution improves the interestingness of collecting digital assets by providing users with privileges based on their ownership, thereby increasing engagement and motivation in acquiring and utilizing digital items.
Smart Images

Figure 0007689940000001 
Figure 0007689940000002 
Figure 0007689940000003
Abstract
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 owned digital cards to play. To build a deck, multiple types of digital cards are required. When trying to build a deck that is advantageous over other decks, there are digital cards that cannot be included in the deck. Digital cards can be acquired by lottery, but if a player does not get the digital cards needed to build a deck, they may feel as if they lost the lottery.
[0005] Patent Document 1 also anticipates that highly rare items, characters, etc. will be the subject of auctions.
[0006] An objective of the present disclosure is to increase the interest of collecting digital assets. [Means for solving the problem]
[0007] A program for causing a computer including a processor and a memory to execute. The program causes the processor to perform steps of managing digital items included in a digital asset, and there is a service that grants privileges according to the ownership status of the digital items, and in response to a request from a user, generates information to be transferred to the service to receive the grant of privileges, which represents the digital items owned by the user.
Effect of the Invention
[0008] According to the present disclosure, it is to improve the interestingness of collecting digital assets.
Brief Description of the Drawings
[0009]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Embodiments for Carrying Out 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. Their names and functions are also the same. Therefore, detailed descriptions thereof will not be repeated.
[0011] <Overview> In the present embodiment, a server that provides digital assets manages the digital assets owned by a user. The user requests the server for information indicating the ownership status of their digital assets. The server generates information indicating the ownership status of the user's digital assets in response to the request from the user and transmits it to the user. The user receives a privilege corresponding to the digital assets owned by transferring the generated information to a service provider that provides a predetermined service.
[0012] In this embodiment, a case where digital cards related to TCG are managed as digital items included in digital assets will be described.
[0013] <1 Configuration diagram of the entire system> FIG. 1 is a block diagram showing an example of the overall configuration of 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] In FIG. 1, an example in which system 1 includes two terminal devices 10 is shown, but the number of terminal devices 10 included in system 1 is not limited to two. The number of terminal devices 10 included in system 1 may be one, or may be three or more.
[0015] In FIG. 1, an example in which system 1 includes one first server 20 and one second server 30 each is shown, but the number of the first server 20 and the second server 30 included in system 1 is not limited to one each. The first server 20 and the second server 30 may be composed of a plurality of servers according to the functions they have. Further, the first server 20 and the second server 30 may be, for example, an aggregate of a plurality of devices regarded as one server. The way of distributing the plurality of functions required to implement the first server 20 and the second server 30 according to this embodiment for one or a plurality of hardware can be appropriately determined in view of the processing capabilities of each hardware and / or the specifications required for the first server 20 and the second server 30.
[0016] The terminal device 10 shown in FIG. 1 is, for example, an information processing device operated by a user who plays a digital TCG. The terminal device 10 is realized by, for example, a mobile terminal such as a smartphone or a tablet. Further, the terminal device 10 may be realized by a stationary PC (Personal Computer), a laptop PC, etc., or may be realized by 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 (such as a touch panel, a touch pad, etc.) for receiving an input operation from a user. The output device 14 is a device (such as a display, a speaker, etc.) for presenting information to the 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 equivalently described as an information processing device that manages digital assets related to services used by a user.
[0019] The first server 20 is realized, for example, by a computer connected to the network 80. As shown in FIG. 1, the first server 20 includes a communication IF 22, an input / output IF 23, a memory 25, a storage 26, and a processor 29. The input / output IF 23 functions as an interface between an input device for receiving an input operation from a user and 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 service provided by the second server 30 is independent of the service provided by the first server 20. However, the second server 30 grants a predetermined privilege to the user based on the digital assets of the user managed by the first server 20. There may or may not be a predetermined relationship between the person who manages the first server 20 and the person who manages the second server 30.
[0021] The second server 30 is realized, for example, by a computer connected to the network 80. The second server 30 includes a communication IF 32, an input / output IF 33, a memory 35, a storage 36, and a processor 39. The input / output IF 33 functions as an interface between an input device for receiving an input operation from a user and an output device for presenting information to the user.
[0022] Each information processing device is composed of a computer including an arithmetic unit and a storage unit. 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 overlapping with the basic hardware configuration of the computer and the basic functional configuration of the computer described later will be omitted.
[0023] <1.1 Configuration of Terminal Device> FIG. 2 is a block diagram showing a configuration example 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. Each block included in the terminal device 10 is electrically connected by, for example, a bus or the like.
[0024] The communication unit 120 performs processes such as modulation / demodulation processing 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 a user operating the terminal device 10 to input instructions or information. The input device 13 is realized by, for example, a touch-sensitive device 131 where an instruction is input by touching the operation surface. When the terminal device 10 is a PC or the like, the input device 13 may be realized by a reader, a keyboard, a mouse, or the like. The input device 13 converts an instruction input from the user into an electrical signal and outputs the electrical signal to the control unit 190. Note that the input device 13 may include, for example, a reception port for receiving an electrical signal input from an external input device.
[0026] The output device 14 is a device for presenting information to the user who operates the terminal device 10. The output device 14 is realized by, for example, 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 by, for example, an LCD (Liquid Crystal Display), 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 the signal given from the microphone 171 into a digital signal and gives the converted signal to the control unit 190. Also, the audio processing unit 17 gives the audio signal to the speaker 172. The audio processing unit 17 is realized by, for example, a processor for audio processing. The microphone 171 receives an audio input and gives an audio signal corresponding to the audio input to the audio processing unit 17. The speaker 172 converts the audio signal given 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 by a light-receiving element and outputs it as a shooting 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 from at least three or four satellites are received, and based on the received signals, the current position of the terminal device 10 equipped with the GPS module is detected. 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, a memory 15 and a 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] User information 181 includes information about a user who plays the TCG, for example. Information about the user includes, for example, user ID, the user's name, age, address, date of birth, registration date, etc.
[0032] Card information 182 includes information about a card, for example. Card information 182 may include information about the cards owned by the user. Details will be described later.
[0033] Deck information 183 includes information about the deck constructed by the user, for example. Details will be described later.
[0034] The control unit 190 is realized by the processor 19 reading the program stored in the storage unit 180 and executing the instructions included in the program. The control unit 190 controls the operation of the terminal device 10. By operating according to the program, the control unit 190 functions as 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 an instruction or information input from the input device 13. Specifically, for example, the operation reception unit 191 receives an instruction or information input from a touch-sensitive device 131 or the like.
[0036] Also, the operation reception unit 191 receives an image input from the camera 160. Specifically, for example, the operation reception unit 191 receives the shooting data captured by the camera 160.
[0037] Also, the operation reception unit 191 receives voice information input from the microphone 171. Specifically, for example, the operation reception unit 191 receives the voice data input from the microphone 171 and converted into digital data by the voice processing unit 17.
[0038] The transmission / reception unit 192 performs processes for the terminal device 10 to transmit and receive data from an external device such as the first server 20 according to a communication protocol. Specifically, for example, the transmission / reception unit 192 transmits an instruction input by the user or various pieces of acquired information to the first server 20. Further, the transmission / reception unit 192 receives information provided from the first server 20. The information provided from the first server 20 includes, for example, information regarding a newly obtained card by the user, information regarding a deck registered in the first server 20, information created based on the cards (digital assets) managed by the first server 20, and the like. Also, the transmission / reception unit 192 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 regarding the user is edited, the management unit 193 stores the edited information in the user information 181. Also, when receiving information regarding a card, the management unit 193 updates the card information 182. Specifically, for example, when a battle using the card is performed, the management unit 193 updates the card information 182. Also, for example, when support is given via the card, the management unit 193 updates the card information 182. Also, 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 for the user. For example, the display control unit 194 controls the display 141 to display a management screen of the cards owned by the user based on the information managed by the card information 182 and the information managed by the deck information 183. The display control unit 194 may control the display 141 to display a management screen of the cards owned by the user based on the information managed by the first server 20. Further, the display control unit 194 controls the display 141 to display information regarding the battles conducted using the card, which is associated with the card selected by the user. Further, the display control unit 194 controls the display 141 to display information regarding the cheering via the card, which is associated with the card selected by the user. Further, the display control unit 194 controls the display 141 to display the information created by the first server 20 based on the cards (digital assets) managed by the first server 20.
[0041] The battle processing unit 195 controls the battle processing with other users. The following modes are assumed for the battle, for example. · Battle with the CPU using a deck constructed with digital cards · Battle with another player using a deck constructed with digital cards · Battle in a tournament
[0042] <1.2 Functional Configuration of the First Server> FIG. 3 is a diagram showing an example of the functional configuration of the first server 20. As shown 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 processes 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 information about users registered for services related to, for example, TCG. Details will be described later.
[0046] The card master table 2022 is a table that stores information about cards available to users. Details will be described later.
[0047] The deck information table 2023 is a table that stores information about decks registered by users. Details will be described later.
[0048] The battle information table 2024 is a table that stores information about battles conducted in the past. Details will be described later.
[0049] The card management table 2026 is a table that stores information for managing the cards acquired by users. Details will be described later.
[0050] The control unit 203 is realized by the processor 29 reading the program stored in the storage unit 202 and executing the instructions included in the program. By operating according to the program, the control unit 203 functions as a reception control module 2031, a transmission control module 2032, a management module 2033, a generation module 2034, and a battle processing module 2035.
[0051] The reception control module 2031 controls the process of the first server 20 receiving a signal from an external device according to a communication protocol.
[0052] The transmission control module 2032 controls the process of the first server 20 transmitting a signal to an external device according to a communication protocol. Specifically, for example, the transmission control module 2032 transmits information based on the digital assets owned and generated by the first server 20 to the terminal device 10.
[0053] The management module 2033 manages the tables stored in the storage unit 202. It can also be said that the management module 2033 manages the digital assets stored in the first server 20. Specifically, for example, the management module 2033 updates the card management table 2026 according to the operations related to the cards. Also, the management module 2033 updates the deck information table 2023 according to the operations related to the decks. Further, when the management module 2033 receives information related to a battle, it updates the battle information table 2024 and the card management table 2026. Also, when the management module 2033 receives information related to cheering, it updates the card management table 2026.
[0054] The generation module 2034 generates information according to the digital assets managed by the first server 20. For example, when the generation module 2034 is requested by the user for information indicating that it has digital assets satisfying a predetermined condition, it generates the requested information. Specifically, for example, when the generation module 2034 is requested by the user for information indicating that it has two or more predetermined digital cards, it 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 by, for example, the second server 30. Also, for example, when the generation module 2034 is requested by the user for information indicating that it has digital cards with a predetermined record left, it may generate the requested information. Digital cards with a predetermined record left refer to, for example, digital cards with information related to a predetermined battle stored, digital cards with information related to a predetermined cheering stored, or digital cards through which a predetermined transaction has taken place, etc.
[0055] Also, for example, when information indicating that the generation module 2034 has a predetermined deck is requested from the user, the generation module 2034 generates the requested information. The deck desired by the user is set by, for example, the second server 30. Also, for example, when information indicating that the generation module 2034 has a deck with a predetermined record is requested from the user, the generation module 2034 may generate the requested information. The deck with a predetermined record represents, for example, a deck in which information regarding a predetermined battle is stored, etc.
[0056] The battle processing module 2035 controls the battle processing between users. For example, the battle processing module 2035 controls the battle between players using decks constructed with digital cards.
[0057] <1.3 Functional Configuration of the Second Server> FIG. 4 is a diagram showing an example of the functional configuration of the second server 30. As shown in FIG. 4, the second server 30 exhibits 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 an external device.
[0059] The storage unit 302 has, for example, a privilege information table 3021. The privilege information table 3021 is a table that stores information (privilege information) regarding privileges to be given to users, for example. 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 exhibits functions as a reception control module 3031, a transmission control module 3032, and a granting module 3033 by operating according to the program.
[0061] The reception control module 3031 controls the process in which the second server 30 receives a signal from an external device according to a communication protocol. Specifically, for example, the reception control module 3031 receives information from the terminal device 10 indicating that the user owns a predetermined digital asset.
[0062] The transmission control module 3032 controls the process in which the second server 30 transmits a signal to an external device according to a communication protocol. Specifically, for example, the transmission control module 3032 transmits information regarding benefits to the terminal device 10.
[0063] The granting module 3033 grants a benefit to the user. For example, the granting module 3033 refers to the benefit information table 3021 and determines whether the digital asset owned by the user satisfies the conditions for granting a benefit. If the conditions are satisfied, the granting module 3033 grants a benefit to the user. The granting of a benefit to the user may be realized, for example, by the transmission control module 3032 transmitting the benefit to the user. Also, the granting of a benefit to the user may be realized, for example, by physically handing it to the user at a store after the granting module 3033 confirms that the conditions for granting the benefit are satisfied.
[0064] <2 Data Structure> FIG. 5 and FIG. 6 are diagrams showing the data structure of the information stored in the terminal device 10. Note that FIG. 5 and FIG. 6 are examples and do not exclude data not described.
[0065] FIG. 5 is a diagram showing the data structure of the card information 182. The card information 182 shown in FIG. 5 is a table having columns such as a card ID, name, type, attribute, card information, battle information, support information, and image data, with the card management ID as the key. In addition to these, the card information 182 may have information regarding regulations or rarity, etc.
[0066] The card management ID is an item that stores an identifier for uniquely identifying a card. In the present embodiment, different card management IDs are assigned even to cards with the same name, the same effect, the same rarity, and the same regulation, that is, exactly the same cards. The card ID is an item that stores an identifier for uniquely identifying the type of a card. In the present 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 the card. In the present embodiment, the types of cards include, for example, character cards that can engage in battles during a duel, action cards (energy cards) used in association with characters, and effect cards (support cards, item cards, stadium cards, etc.) that exhibit specific effects during a duel.
[0067] The attribute is an item that stores the nature to which a character belongs. In the present embodiment, the attributes include, for example, fire, water, thunder, grass, psychic, steel, dark, fighting, etc. Among the attributes, there are attributes that are advantageous and attributes that are disadvantageous when opposed. The card information is an item that stores information for explaining the content of the card. When the type of the card is a character, the card information includes, for example, the attack power, the physical strength, the amount of energy required to use a skill, the amount of energy required to flee, the weaknesses, the resistances, and the special characteristics that the character has. When the type of the card is support, item, or stadium, the card information includes, for example, the usage requirements of the card and the effects that occur when the card is used.
[0068] The duel information is an item that stores information regarding the TCG duel implemented by incorporating the corresponding card into a deck. In the present embodiment, it shows the case where a duel ID capable of identifying a duel is stored as the duel information. The first server 20 registers, as the duel information, information for specifying a duel implemented using a deck incorporated with the corresponding card by a user, for example. The item "duel information" is, for example, the duel information registered in the first server 20 that is transmitted to and stored in the terminal device 10.
[0069] The support information is an item that stores information about the TCG battles supported in association with the corresponding card. In this embodiment, it shows a case where a battle ID that can identify the supported battle is stored as the support information. The first server 20 manages, for example, the support associated by the user with the corresponding card in association with the card management ID. The item "support information" is what is stored after the support information managed by the first server 20 is transmitted to and stored in the terminal device 10.
[0070] The image data is an item that stores an image. The image data may store reference information (path) to an image data file located elsewhere.
[0071] FIG. 6 is a diagram showing the data structure of the deck information 183. The deck information 183 shown in FIG. 6 is a table having columns such as a name, a compiled card, completion, update date, registration information, etc. with the deck ID as a key. In addition to these, the deck information 183 may have information regarding the common name of the deck, the usage history of the deck, etc. The common name of the deck is, for example, a name that is attached based on the characteristic cards used in the deck, that represents the characteristics of the deck in a straightforward manner, and that is attached under the common recognition among a plurality of 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, for example, given by the user. The compiled card is an item that stores the cards that make up the deck. In the compiled card, for example, the card management ID of the cards that make up the deck is stored.
[0073] Completed is an item that stores whether or not the deck is complete. In this embodiment, a circle indicates that the deck is complete, and a cross indicates that the deck is not complete. In this embodiment, a completed deck means, for example, that the deck is 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, the use of a card used in one deck in another deck may also be treated as a change. Registration information is an item that stores the relationship with the deck registered in the first server 20. The registration information stores, for example, a deck code issued when the deck is registered in the first server 20.
[0074] A record for 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 data structures of information stored in the first server 20. Note that, Figs. 7 to 11 are merely examples, and do not exclude data that is not shown.
[0076] Fig. 7 is a diagram showing the data structure of a 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 a user ID as a key. The user information table 2021 is not limited to the above, and may also have a column for proficiency.
[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 services related to the TCG.
[0078] A record in the user information table 2021 is added when a new user is registered.
[0079] Figure 8 is a diagram showing the data structure of the card master table 2022. The card master table 2022 shown in Figure 8 is a table having columns such as name, type, attribute, card information, and image data, with the card ID as the key.
[0080] The card ID is an item for storing an identifier for uniquely identifying the type of card. The name is an item for storing the name of the card. The type is an item for storing the type of card. The attribute is an item for storing the property to which the character belongs. The card information is an item for storing information explaining the content of the card. The image data is an item for storing an image.
[0081] Records in the card master table 2022 are added, for example, when a new card is issued.
[0082] Figure 9 is a diagram showing the data structure of the deck information table 2023. The deck information table 2023 shown in Figure 9 is a table having columns such as name, user ID, registration date, first compiled card, second compiled card, and publication, with the deck code as the key. The deck information table 2023 may have information regarding the common name of the deck, etc., in addition to these.
[0083] The deck code is an item for storing an identifier for uniquely identifying the registered deck. The deck code is issued by the management module 2033 when a new deck is registered by the user. The deck code shown in Figure 9 is, for example, a different identifier from the deck ID shown in Figure 6. This is because the deck code shown in Figure 9 manages the published decks, while the deck ID shown in Figure 6 is for managing one's own deck. The name is an item for storing the name of the deck. The name is given by the user. The user ID is an item for storing the user ID of the user who registered the deck. The registration date is an item for storing the date when the deck was registered.
[0084] The first compilation card and the second compilation card are items that store the cards for compiling the deck. In the first compilation card, for example, the card ID of the card for compiling the deck is stored. In the second compilation card, for example, the card management ID of the card for compiling the deck is stored. Public is an item that stores whether the deck is publicly available to other users. In this embodiment, a circle indicates that the deck is publicly available to other users, and a cross indicates that the deck is not publicly available to other users. In this embodiment, that the deck is not publicly available means that only the user himself / herself can view it.
[0085] Records in the deck information table 2023 are added when a new deck is registered.
[0086] Figure 10 is a diagram showing the data structure of the battle information table 2024. The battle information table 2024 shown in Figure 10 is a table having columns such as date and time, opponents, deck code, winner, battle log information, tournament information, etc. with the battle ID as the key.
[0087] The battle ID is an item that stores an identifier for uniquely identifying a battle. The battle ID is issued by the management module 2033 when new information related to the battle is registered. The date and time is an item that stores the date and time when the battle was conducted. The opponents is an item that stores information about the players who participated in the battle. In this embodiment, for example, the user IDs of the players who participated in the battle are stored in the opponents.
[0088] The deck code is an item that stores a code for identifying the deck used in the battle. In this embodiment, for example, the player who participated in the battle 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. That is, the deck code may not be registered.
[0089] The winner is an item that remembers the winner of the battle. The battle log information is an item that remembers the moves adopted by the player during the battle. Specifically, for example, the battle log information includes the player drawing a card from a predetermined placement section (such as a deck or a win / loss condition card), the player placing a card in a predetermined placement section, the player using the effect of a predetermined card, etc. The moves adopted by the player during the battle may be referred to as deck shuffling during the battle. The tournament information is an item that remembers information related to the battle. For example, the tournament information includes the name of the tournament in which the battle was held and the number of rounds of the battle in the tournament. The tournament information may include battle information in a privately held tournament regardless of whether it is an officially held tournament. Also, the tournament information is not limited to tournaments and may include battle information in a private battle.
[0090] Records in the battle information table 2024 are added when a new battle is registered.
[0091] Figure 11 is a diagram showing the data structure of the card management table 2026. The card management table 2026 shown in Figure 11 is a table having columns such as card ID, battle information, support information, owner, recipient, transferor, transaction date, consideration, etc. with the card management ID as the key.
[0092] The owner is an item that remembers information about the user who owns the card. In this embodiment, the user ID of the user who owns the card is remembered as the owner.
[0093] The recipient, transferor, transaction date, and consideration are items that remember information related to the transaction of the card specified by the card management ID. The recipient, transferor, transaction date, and consideration are added for each transaction. The recipient 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 on which the transaction was carried out. The consideration represents the fee paid from the recipient to the transferor when the card is transacted.
[0094] FIG. 12 is a diagram showing the data structure of the privilege information table 3021 stored in the second server 30. Note that FIG. 12 is an example and does not exclude data not described. The privilege information table 3021 shown in FIG. 12 is a table having columns such as privilege content and conditions, with the privilege ID as the 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 condition under which the privilege is granted. The privilege content is, for example, a coupon, a predetermined product, points, etc. For example, when the administrator of the second server 30 is an aquarium, the condition may be the possession of a digital card related to water, and the privilege content may be a discount on the fee.
[0096] <3 Operations> Based on the digital assets managed by the first server 20, the operations of the terminal device 10, the first server 20, and the second server 30 when the user receives a privilege from the second server 30 will be described.
[0097] (Update Process of Card Management Table Purchase of Digital Assets) The first server 20 sells, for example, digital cards. The first server 20 sells the cards in a manner that allows the user to grasp the content of the cards. Also, the first server 20 may sell the cards in a manner that does not allow the user to grasp the content of the cards. The first server 20 sells the cards on a per-card basis. Also, the first server 20 may sell a plurality of cards as a sales unit.
[0098] Also, the first server 20 may function as a platform for the user to sell cards to other users. The first server 20 makes public to other users a card with sales conditions such as price set by the user so that other users can purchase it. When the user agrees to the sales conditions set by other users, the user can select the card and purchase the card.
[0099] FIG. 13 is a diagram for explaining an example of operations of the terminal device 10 and the first server 20 when a user purchases a card.
[0100] When purchasing a card, the user accesses the first server 20 using the terminal device 10. The terminal device 10 acquires information about the cards 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 a desired card. The user inputs a request to purchase the selected card to the terminal device 10.
[0101] In step S11, the terminal device 10 receives, via the operation reception unit 191, a card purchase request input by the user. The terminal device 10 transmits, via the transmission / reception unit 192, the received purchase request to the first server 20.
[0102] In step S12, the first server 20 acquires a card based on the user's card purchase request. Specifically, for example, the first server 20 acquires the card selected by the user by consuming a predetermined asset associated with the user by the management module 2033. The predetermined asset is, for example, the following. · Game media used in games · Cryptocurrency · Tokens · Information related to currency
[0103] When the user selects a card sold in a manner that enables the card content to be grasped, the management module 2033 acquires the card ID of the card selected by the user. When the user selects a card sold in a manner that does not enable the card content to be grasped, the management module 2033 executes a lottery for the card and acquires the card ID of the card selected by the lottery. When 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 card ID of a card sold in a manner that enables the card content to be grasped is acquired, or when the card ID of a card selected by lottery is acquired, the management module 2033 issues a card management ID for the corresponding card. The management module 2033 issues a record using the card management ID as the key in the card management table 2026, and stores information in the card ID and the owner in the record.
[0105] Also, for example, when the card management ID of a card sold by another user is acquired, the management module 2033 changes the owner of the card in the card management table 2026. Further, the management module 2033 stores information related to the transaction in the record using the acquired card management ID as the key. Specifically, for example, the management module 2033 stores the transferee, transferor, transaction date, and consideration in the record using the acquired card management ID as the key.
[0106] In step S14, the first server 20 transmits information related to the card purchased by the user to the terminal device 10. Specifically, for example, the management module 2033 reads out information related to the card purchased by the user from the card master table 2022 based on the card ID. The management module 2033 reads out, for example, the name, type, attribute, card information, and image data as information related to 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 updates the card information 182 based on the received information. Specifically, for example, the terminal device 10 creates a new record in the card information 182 by the management unit 193, and stores the card management ID, card ID, name, type, attribute, card information, and image data.
[0108] (Update Process of Card Management Table, Storage of Battle Information) The control unit 203 of the first server 20 manages, for each card, information on cards used in battles by the management module 2033.
[0109] The user constructs a deck by combining the cards managed by the card information 182. The management unit 193 manages information regarding the deck constructed by the user with the deck information 183.
[0110] Also, the user registers the deck constructed by himself / herself with the first server 20. Specifically, the user accesses the first server 20 using the terminal device 10. The terminal device 10 displays, on the display 141, a deck registration form set in the first server 20. The user uses the form displayed on the display 141 to select the cards for constructing the deck. The user inputs, to the terminal device 10, a request to register the deck constructed by the selected cards and the name of the deck. The user may set whether to make the registered deck public to other users.
[0111] When a deck registration request is input from the user, the management module 2033 issues a new deck code and creates a record in the deck information table 2023 with the issued deck code as the key. The management module 2033 stores, for example, the name, user ID, registration date, first organized card, second organized card, and public status of the created record based on the information input from the user.
[0112] FIG. 14 is a diagram for explaining an example of the operations of the terminal device 10 and the first server 20 when managing the cards used by the user in battles.
[0113] When starting a battle, the user accesses the first server 20 using the terminal device 10. The terminal device 10 displays on the display 141 a registration form for battle information set in the first server 20. The user uses the form displayed on the display 141 to input information regarding the battle. Information regarding the battle is, for example, the date and time of the battle, the opponents, information about the deck to be used in the battle, tournament information, and the like. When the user inputs information regarding the battle, the user inputs a request to register the battle information into the terminal device 10.
[0114] In step S21, the terminal device 10 receives, via the operation reception unit 191, a request to register battle information input by the user. The terminal device 10 transmits, via the transmission / reception unit 192, the input battle information and the registration request to the first server 20.
[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 request to register battle information is input by the user, the management module 2033 issues a battle ID and creates a record in the battle information table 2024 with the issued battle ID as the key. The management module 2033 stores the date and time, opponents, deck code, and tournament information of the created record based on the information input by the user.
[0116] The date and time, opponents, and tournament information may be input in advance by the tournament operator. In this case, the battle ID has already been issued and a record has been created in the battle information table 2024. Also, information about the deck to be used in the battle may be registered in advance by the user. For example, a plurality of decks planned to be used in the tournament are registered before the battle, and the user may select any of the registered decks at the start of the battle.
[0117] When the management module 2033 stores information in the battle information table 2024, it updates the card management table 2026. Based on the card management ID of the cards included in the deck, the management module 2033 stores information regarding the battle in which the deck is used, such as the battle ID, in the item "battle information" of the corresponding record in the card management table 2026. As the number of battles increases, the information to be stored increases. This makes it possible to grasp in which battles the cards were used.
[0118] In step S23, the first server 20 transmits the 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 item "battle information" of the card management table 2026, the management module 2033 reads out the newly stored battle ID, the card management ID, and the user ID as 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 stores, by the management unit 193, the battle information received from the first server 20, such as the battle ID, in the item "battle information" of the record specified by the card management ID.
[0120] When the battle starts, the control unit 203 controls the battle process between players by the battle processing module 2035. The battle processing module 2035 stores information regarding the moves adopted by the players during the battle in the storage unit 202. The management module 2033 stores the information regarding the moves adopted by the players during the battle in the battle information table 2024 as battle log information. When the battle ends, the battle processing module 2035 designates the player who won the battle as the winner. The management module 2033 stores the winner in the battle information table 2024.
[0121] (Update Process of Card Management Table: Storage of Support Information) The control unit 203 of the first server 20 manages, for each card, information on the decks supported by the card management module 2033.
[0122] A user may support a player using a deck in which there are cards with special memories. In this embodiment, the support for the decks related to the cards is managed in association with the card information.
[0123] FIG. 15 is a diagram for explaining an example of the operations of the terminal device 10 and the first server 20 when managing cards based on user support.
[0124] For example, before a tournament is held, it is assumed that information about the tournament participants and the decks used by the tournament participants is made public. The user refers to the tournament participants and the decks and selects the player to be supported by the user. Before the tournament is held or before a predetermined time on the day of the tournament, the user accesses the first server 20 using the terminal device 10. The terminal device 10 displays the support form set in the first server 20 on the display 141. The user uses the form displayed on the display 141 to select the card serving as the basis for support and inputs the other player using the deck to be supported in association with the selected card. When the user inputs information related to the support, the user inputs a request to register the support information to the terminal device 10. The information related to the support includes, for example, the card management ID of the selected card and the user ID of the player to be supported. The user ID of the player to be supported may be the participant ID when participating in the tournament. The information related to the support may include, for example, information identifying the tournament and information identifying the match in the tournament.
[0125] The card that serves as the basis for support is, for example, a card that has the same effect as the cards that make up the deck to be supported. When the user has an attachment to a certain card, there arises a desire to support a player who uses a deck composed of cards having the same effect as this card. The user supports a player who uses a deck composed of the card based on the cards the user owns. Note that the cards to be supported may have different rarities. If the deck does not contain a card having the same effect as the card the user owns, it may be made impossible to support the player who uses that deck.
[0126] The player who can be supported based on one card is, for example, only one person. Note that regardless of the number of cards, the player who can be supported may be limited to one person. Also, it may be possible to support one player throughout the tournament, or the player to be supported may be changed for each match.
[0127] Also, the object of support may be a deck instead of a player.
[0128] During the period when the management unit 193 supports a deck, the control unit 190 may set the card that serves as the basis for support so that the user cannot use it with the deck. As a result, while the deck is being supported, since the selected deck cannot be used, the user will select the deck to be supported more seriously.
[0129] In step S31, the terminal device 10 receives, via the operation reception unit 191, a registration request for support information input by the user. The terminal device 10 transmits, via the transmission / reception unit 192, the input information regarding the support and the registration request to the first server 20.
[0130] In step S32, the first server 20 updates the card management table 2026 based on the information about the support input by the user. Specifically, for example, when a registration request for support information is input by the user, the management module 2033 reads out the information about the game from the game information table 2024. Based on the card management ID included in the information about the support input by the user, the management module 2033 stores the information based on the game information in the item "support information" of the corresponding record in the card management table 2026. The predetermined information stored in the item "support information" includes, for example, the game ID and the user ID of the player being supported. As the number of times of support increases, the information to be stored increases. This makes it possible to grasp that support has been given based on the card.
[0131] In step S33, the first server 20 transmits the information managed in the card management table 2026 to the terminal device 10. Specifically, for example, when a game ID and a user ID are newly stored in the item "support information" of the card management table 2026, the management module 2033 reads out the newly stored game ID and user ID, the card management ID, and the user ID as the owner. The transmission control module 2032 transmits the read game ID and user ID and the 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 stores, by the management unit 193, the support information received from the first server 20, such as the game ID and the user ID, in the item "support information" of the record specified by the card management ID.
[0133] When the battle starts, the control unit 203 controls the battle process between players by the battle processing module 2035. The battle processing module 2035 stores information about the moves adopted by the players during the battle in the storage unit 202. The management module 2033 stores the information about the moves adopted by the players during the battle in the battle information table 2024 as battle log information. When the battle ends, the battle processing module 2035 determines the player who won the battle as the winner. The management module 2033 stores the winner in the battle information table 2024. The management module 2033 may store the information regarding the win or loss in the item "support information" of the card management table 2026. The management module 2033 may store the result of the tournament in the battle information table 2024. For example, when a player wins in the final of the tournament, the winner may be stored in the battle information table 2024, and as the result of the tournament, the fact of winning may also be stored in the battle information table 2024.
[0134] (Bonus Granting Process) The second server 30 provides a service independent of the service related to the TCG. That is, the second server 30 provides a service separated from the service related to the TCG. Specifically, the second server 30 is, for example, an aquarium, a museum, a retail store, or a restaurant.
[0135] The service provided by the second server 30 is independent of the service provided by the first server 20, but has a predetermined relationship with the service provided by the first server 20. The predetermined relationship is, for example, to provide a part of the service provided by the second server 30 to the user according to the digital assets owned by the user for the service provided by the first server 20. Specifically, when 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 coupon tickets (discount tickets or product exchange tickets) that can be used in the store according to the digital assets related to the first server 20.
[0136] For the service of the second server 30 to have a predetermined relationship with the service of the first server 20, for example, a predetermined period may be set. The predetermined period related to having a predetermined relationship may be set in advance, or may vary according to predetermined requirements. The period set in advance may be set as, for example, a campaign period. That is, during the campaign period, the second server 30 provides, for example, a part of the service provided by the second server 30 to the user according to the digital assets owned by the user regarding the service provided by the first server 20.
[0137] The predetermined requirements for the predetermined period to vary mean, for example, the number of products provided in a predetermined relationship, or the number of users related to a predetermined relationship, etc. Specifically, for example, in the case of a campaign product with a limited number of benefits, when the product runs out, the period ends. That is, the second server 30 provides, for example, a campaign product to the user according to the digital assets owned by the user regarding the service provided by the first server 20 until the campaign product runs out. Also, in the case of a campaign experience with a limited number of people for the benefits, when the number of people is reached, the period ends. That is, the second server 30 provides, for example, a campaign experience to the user according to the digital assets owned by the user regarding the service provided by the first server 20 until the number of applicants reaches a predetermined number.
[0138] In the following description, the case where the second server 30 grants a privilege to the user according to the digital card owned by the user will be described as an example.
[0139] FIG. 16 is a diagram for explaining 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 privilege based on a digital card to the user.
[0140] In step S41, the second server 30 sets privilege information. For example, the control unit 303 of the second server 30 sets the privilege content and its conditions by the granting module 3033. The granting module 3033 may arbitrarily set conditions regarding the ownership of digital assets.
[0141] For example, the awarding module 3033 may be conditioned on the total number of digital cards. Also, the awarding module 3033 may be conditioned on the number of digital cards with a predetermined card ID. Also, the awarding module 3033 may be conditioned on a combination of predetermined card IDs or the like. Also, the awarding module 3033 may include the information associated with the digital card as a condition. For example, the awarding module 3033 may be conditioned on information related to battles. Also, the awarding module 3033 may be conditioned on information related to cheering. Also, the awarding module 3033 may be conditioned on information related to transactions. Also, the awarding module 3033 may be conditioned on owning a predetermined deck.
[0142] Specifically, for example, the awarding module 3033 is set to award product AAAA on the condition of owning digital cards with card IDs: C0001, C0002, and C0003.
[0143] In step S42, the second server 30 publishes the set privilege information by a predetermined method. Any existing method may be used as the publishing 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 a list of privilege information on the display 141.
[0145] FIG. 17 is a schematic diagram showing an example of the display on the display 141 of the terminal device 10. In FIG. 17, the display control unit 194 displays the area 1411. The area 1411 is an area for displaying information related to privileges. A search window 14111 is displayed in the area 1411. When the user has a desired privilege or a digital asset that seems to meet the conditions, the user inputs a keyword or the like into the search window 14111.
[0146] The display control unit 194 displays the privilege information in a list form in the area 1411, for example. The display order can be arbitrarily set, such as in the order of product names, identification numbers, product values, difficulty levels of collecting digital assets, etc. The difficulty level of collecting digital assets can be calculated based on, for example, the rarity of digital cards. In FIG. 17, the display control unit 194 displays information about one privilege in the object 14112. In the object 14112, the display control unit 194 displays the product name and the digital assets required as conditions.
[0147] The display control unit 194 may display only the information about the privileges that meet the conditions for digital assets in the area 1411. Specifically, for example, the management unit 193 compares the conditions of the privileges with the digital assets owned by the user. The management unit 193 extracts the information of the privileges that meet the conditions. The display control unit 194 displays the extracted information about the privileges on the display 141. As a result, since the privileges displayed on the display 141 are acquirable by the user, the user does not need to confirm which of the displayed privileges can be acquired.
[0148] In FIG. 17, the user selects a desired privilege and performs an operation of contacting the object that displays the selected privilege.
[0149] When the user contacts the object, the terminal device 10 displays, by the display control unit 194, a screen for confirming the acquisition of the selected privilege.
[0150] FIG. 18 is a schematic diagram showing a display example of the display 141. In the example shown in FIG. 18, the display control unit 194 displays a window 14113 for confirming the acquisition of the selected privilege. Buttons 141131 and 141132 for inputting the user's intention are displayed on the window 14113. If there is no mistake in acquiring the privilege, the user presses the Yes button 141131. In the present embodiment, pressing the button 141131 means inputting a generation request for information regarding the digital asset displayed on the object and a privilege granting request.
[0151] In step S44, the terminal device 10 receives, by the operation reception unit 191, the generation request and the granting request input by the user. The terminal device 10 transmits the generation request to the first server 20 by the transmission / reception unit 192. The generation request includes, for example, the user's identification information (e.g., user ID, a predetermined address set for the user) and information regarding the condition (e.g., card ID).
[0152] In step S45, the first server 20 confirms 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 the information regarding the condition from the received generation request by the management module 2033. The management module 2033 refers to the card management table 2026 based on the acquired information and confirms whether the user owns the digital card presented as the condition.
[0153] In step S46, the first server 20 generates information regarding the digital asset. Specifically, when the user has the digital card presented as the condition, for example, the control unit 203 of the first server 20 generates, by the generation module 2034, proof information for proving the ownership of the digital card as the information regarding the digital asset.
[0154] The proof information is, for example, information indicating that there are the required number of cards with the target card ID. Also, the proof information is, for example, information indicating that there are the required number of digital cards with the required additional information. Also, the proof information is, for example, information indicating that the target deck is available. The generation module 2034 may include the generation date and time in the proof information.
[0155] The information regarding the digital asset is not the digital item itself included in the digital asset. That is, the information regarding the digital asset does not maintain the data structure of the digital item related to the information. Therefore, even if the information regarding the digital asset is transferred to another service, the transferee cannot use the corresponding digital item. Also, even if the information regarding the digital asset is transferred to another service, the owner of the corresponding digital item does not change. That is, there is no change in the data structure of the digital items managed by the first server 20.
[0156] The generation module 2034 assumes that the owner of the generated information regarding the digital asset is the user who input the generation request. The control unit 203 of the first server 20 transmits the generated information regarding the digital asset to the terminal device 10 by the transmission control module 2032.
[0157] In step S47, the terminal device 10 transfers the information regarding 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 regarding the digital asset by the transceiver unit 192. The transceiver unit 192 transmits the information regarding the digital asset and the grant request to the second server 30. The transceiver unit 192 transmits an instruction to change the owner of the information regarding the digital asset to the second server 30 (which can also be paraphrased as the provider of the service) to the first server 20. The first server 20 changes the owner of the information regarding the digital asset to the second server 30. The grant request includes, for example, the user's identification information (e.g., user ID, a predetermined address set for the user) and information identifying the privilege selected by the user.
[0158] In step S48, the second server 30 grants a privilege to the terminal device 10. Specifically, for example, the control unit 303 of the second server 30 receives information regarding the digital asset and the grant request by the grant module 3033. The grant module 3033 acquires the user identification information and the identification information of the selected privilege from the grant request. The grant module 3033 reads out the conditions for the privilege selected by the user from the privilege information table 3021. The grant module 3033 collates the information regarding the digital asset with the conditions for the privilege. When the information regarding the digital asset matches the conditions for the privilege, the grant module 3033 grants the privilege to the user.
[0159] When the terminal device 10 is granted a privilege from the second server 30, the display control unit 194 displays a screen for notifying 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 the privilege has been granted. A button 141141 for inputting the user's intention is displayed in the window 14114. When the user confirms that the privilege has been granted, the user presses the Yes button 141141.
[0161] As described above, in the above embodiment, there is a service that grants privileges according to the ownership status of digital items. The control unit 203 of the first server 20 manages the digital items included in the digital asset by the management module 2033. The control unit 203 generates, by the generation module 2034, information representing the digital items owned by the user and transferred to the service to receive the grant of privileges in response to a request from the user. Thereby, the user can receive privileges based on the digital items owned.
[0162] Therefore, according to this embodiment, the interestingness of collecting digital assets can be improved.
[0163] Also, in the above embodiment, the generation module 2034 receives from the user a designation of a digital item for which the ownership status is to be confirmed, and generates information indicating that the user owns the designated digital item. As a result, the number of digital items for which ownership is to be confirmed when generating information is reduced, and it becomes possible to reduce the processing of the generation module 2034.
[0164] Also, in the above embodiment, the generation module 2034 generates information indicating that the user owns a digital item to which predetermined related information is attached. Thereby, it becomes possible to set privilege information not only based on the number of digital items but also on what is done using the digital items. Therefore, it becomes possible to improve the interestingness of using digital items.
[0165] Also, in the above embodiment, even if the generation module 2034 generates information regarding digital assets, it does not affect the digital items to be managed. As a result, since the number of digital items does not decrease even when information is generated, it becomes possible to receive privileges without hesitation.
[0166] Also, in the above embodiment, in the information regarding digital assets, the data structure of the digital item related to the information is not maintained. Thereby, even if the information is transferred, the transferee cannot use it as a digital item. Therefore, it becomes possible to suppress an increase in 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 depending on the ownership status of the digital items is a service separate from the game. This makes it easy to associate the acquisition of a digital item related to the game with the service separate from the game, and can motivate players to play the game. It also makes it possible to reduce the burden on service providers when linking the service with 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 block chain (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 on the digital asset is traded on the blockchain as an NFT. For example, the generation module 2034 may be realized by a smart contract implemented on the blockchain. Upon receiving a generation request, the smart contract generates proof information as an NFT based on information on the conditions included in the generation request.
[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] In addition, the management regarding the use of NFTs is executed, for example, by smart contracts implemented on a blockchain. The usage history of NFTs is stored on the blockchain as a transaction. As a result, the history of using NFTs in battles and the history of supporting other players based on NFTs are stored on the blockchain.
[0172] In addition, the granting of benefits regarding the usage history of NFTs is executed, for example, by smart contracts implemented on a blockchain. As a result, when the history of using NFTs in battles meets predetermined requirements, predetermined benefits are granted to the owner of the NFT at that time. Also, when the history of supporting other players based on NFTs meets predetermined requirements, predetermined benefits are granted to the owner of the NFT at that time.
[0173] The granting module 3033 may be realized, for example, by a smart contract implemented on a blockchain. When the smart contract receives a granting request and information regarding the digital asset, it collates the information regarding the digital asset with the conditions regarding the benefits. When the information regarding the digital asset matches the conditions regarding the benefits, the smart contract grants the benefits to the user.
[0174] In this way, the control unit 203 of the first server 20 stores information regarding a plurality of digital cards in a distributed ledger formed by a computer network through the management module 2033. Note that the control unit 190 of the terminal device 10 may store information regarding a plurality of digital cards in a distributed ledger formed by a computer network through the management unit 193. As a result, it becomes possible to handle digital cards as NFTs. Also, it becomes possible to leave a fair record regarding digital cards.
[0175] In addition, the management module 2033 stores information regarding the use of the card as a transaction of the corresponding digital card in the distributed ledger. Note that the management unit 193 may also store information regarding the use of the card as a transaction of the corresponding digital card in the distributed ledger. This makes it possible to leave a fair record of the usage history of the digital card.
[0176] In addition, the management module 2033 or the management unit 193 stores information regarding the battle as a transaction of the corresponding digital card in the distributed ledger. This makes it possible to leave a fair record of the information regarding the battle of the digital card.
[0177] In addition, the management module 2033 or the management unit 193 stores information regarding the support as a transaction of the corresponding digital card in the distributed ledger. This makes it possible to leave a fair record of the information regarding the support based on the digital card.
[0178] In addition, the management module 2033 or the management unit 193 stores information regarding the transaction as a transaction of the digital card being transacted in the distributed ledger. This makes it possible to leave a fair record of the transaction of the digital card.
[0179] In the above embodiment, the case where the first server 20 stores the battle information table 2024 has been described. The battle information of the user himself / herself may be stored in the storage unit 180 of the terminal device 10. The management unit 193 may update the battle information in the card information 182 based on the battle information stored in the storage unit 180. When the card information 182 is updated, the transmission / reception unit 192 transmits information regarding 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 to grasp the battle information in the terminal device 10.
[0180] In the above embodiment, as an example of using the card, the battle using the deck formed by the cards and the support based on the cards were described. However, the use of the cards is not limited to these. For example, the display of the cards etc. may be included in the use of the cards.
[0181] In the above embodiment, the case where the digital item included in the digital asset is a digital card was described. However, the digital item is not limited to the digital card. The digital item may be a digital character etc.
[0182] In the above embodiment, the case where the privilege is granted from the second server 30 according to the digital asset owned by the user was described. However, the granting of the privilege from the second server 30 is not limited to being based on the owned digital asset. For example, there is a system in which an event occurs according to a predetermined rule. At this time, the management means of the system stores the event generated by the user. The generation means of the system generates information regarding the occurrence of the event according to the request from the user.
[0183] Specifically, for example, there is a game in which an event occurs according to a predetermined rule. At this time, the management module 2033 of the first server 20 that provides the game manages the event (progress of the game) generated by the player. The generation module 2034 generates information regarding the occurrence of the event (progress of the game, acquisition status of the digital item) according to the request from the user.
[0184] The second server 30 sets the occurrence status of an event as a condition for a privilege. At this time, the granting module 3033 may use, for example, the extent to which the event has occurred as a condition. Also, the granting module 3033 may use the number of occurrences of a predetermined event as a condition. Further, the granting module 3033 may use a combination of predetermined events or the like as a condition. Also, the granting module 3033 may include information associated with a predetermined event in the conditions. For example, the granting module 3033 may use the state of the player when the event occurs as a condition. Also, the granting module 3033 may use the state and number of other players when the event occurs as a condition. The second server 30 grants a privilege to the user based on information regarding the occurrence of an event presented by the user.
[0185] In a system where events occur according to a predetermined rule, information regarding the events generated by the user may be stored on the blockchain as an NFT.
[0186] In this way, based on the log of events that have occurred in the system, the user can receive a privilege from another system independent of the system, so the user's motivation to generate events increases. That is, based on the progress of a predetermined game, the player can receive a privilege from a provider of a service different from the game, so the player's motivation to advance the game increases.
[0187] Also, the second server 30 grants a privilege based on information regarding the events generated by the user. Therefore, when granting a privilege, the second server 30 does not need to sequentially start the target game to check the progress status within the game. The second server 30 only needs to confirm that there is information (e.g., including NFT) to prove the progress, so the operation effort can be saved. Also, complex condition settings can be made without much effort.
[0188] In the above embodiment, an example of managing all digital cards in the card management table 2026 has been described. However, the digital cards managed in the card management table 2026 may be selected by the user. For example, the management module 2033 can allocate the record frames of the card management table 2026 to the user according to the request from the user. The management module 2033 allocates the number of record frames requested by the user to the user. The management module 2033 may request a predetermined asset from the user according to the number of allocated record frames.
[0189] The user stores the desired digital card in the allocated record frame. That is, the user instructs the first server 20 to store the data of a predetermined digital card in any of the allocated record frames.
[0190] The management module 2033 stores the information of the digital card specified by the user in the record frame. When the digital card stored in the record frame is used, the management module 2033 stores the information related to 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, the information related to the use is not stored, or less information than the digital card stored in the record frame is stored. The management module 2033 may make only the digital cards stored in the record frame viewable by other users. Note that a predetermined number of record frames are allocated for each user, but the number of record frames allocated to the user may increase when the user pays a price or the user progresses the game.
[0191] As a result, various information about the digital card specified by the user will be managed. Therefore, it is possible to accurately manage the information about the digital cards that the user feels necessary while reducing the management cost of the entire digital card game.
[0192] In addition, in the above-described embodiment, the case where the user selects a desired privilege has been described. However, the selection of the privilege by the user is not essential. When the user requests information regarding the digital asset, the first server 20 may generate information regarding the digital asset owned by the user with reference to the card management table 2026. That is, the first server 20 may generate information regarding the digital asset without receiving a specification of conditions regarding the digital asset from the user. The generated information regarding the digital asset is transmitted to the second server 30. The second server 30 compares the received information regarding the digital asset with the conditions stored in the privilege information table 3021 and determines the privilege that can be granted to the user.
[0193] As a result, the user can obtain the privilege without selecting the privilege. In addition, the user can obtain the privilege without specifying the digital asset.
[0194] In addition, in the above-described embodiment, the case where the user obtains the digital card by purchasing the digital card or the like has been described. However, the digital card may be obtained by reading the analog card.
[0195] <4 Basic Hardware Configuration of Computer> FIG. 20 is a block diagram showing a basic hardware configuration of a computer 90. The computer 90 includes at least a processor 91, a main storage device 92, an auxiliary storage device 93, and a communication IF 99 (Interface). These are electrically connected to each other by a bus.
[0196] The processor 91 is hardware for executing a set of instructions described in a program. The processor 91 is composed of an arithmetic unit, registers, peripheral circuits, and the like.
[0197] The main memory device 92 is for temporarily storing programs and data processed by programs and the like. For example, it is a volatile memory such as DRAM (Dynamic Random Access Memory).
[0198] The auxiliary storage device 93 is a storage device for storing data and programs. For example, it includes flash memory, HDD (Hard Disc Drive), magneto-optical disk, CD-ROM, DVD-ROM, semiconductor memory, and the like.
[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 various mobile communication systems constructed by the Internet, LAN, wireless base stations, etc. For example, the network includes 3G, 4G, 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi (registered trademark)) that can be connected to the Internet by a predetermined access point. When connecting wirelessly, communication protocols such as Z-Wave (registered trademark), ZigBee (registered trademark), Bluetooth (registered trademark), etc. are included. When connecting wired, the network also includes those directly connected by a USB (Universal Serial Bus) cable or the like.
[0201] Note that all or part of each hardware configuration can be distributed and provided to a plurality of computers 90, and the computers 90 can be virtually realized by connecting them to each other via a network. In this way, the computer 90 is a concept that includes not only a single housing and the computer 90 housed in a case but also a virtualized computer system.
[0202] <Basic Functional Configuration of Computer 90> The functional configuration of a computer realized by the basic hardware configuration of computer 90 shown in FIG. 20 will be described. The computer includes at least functional units of a control unit, a storage unit, and a communication unit.
[0203] Note that the functional units included in computer 90 can also be realized by dispersing all or part of each functional unit among a plurality of computers 90 interconnected by a network. 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 out various programs stored in the auxiliary storage device 93 and expanding them in the main storage device 92, and executing processing according to the programs. The control unit can realize a functional unit that performs various information processes according to the type of program. Thereby, the computer is realized as an information processing device that performs information processing.
[0205] The storage unit is realized by the main storage device 92 and the auxiliary storage device 93. The storage unit stores data, various programs, and various databases. Also, the processor 91 can secure a storage area corresponding to the storage unit in the main storage device 92 or the auxiliary storage device 93 according to the program. Further, the control unit can cause the processor 91 to execute processes of adding, updating, and deleting data stored in the storage unit according to various programs.
[0206] The database refers to a relational database and is for managing a set of data called a table in a tabular format structurally defined by rows and columns in association with each other. In a database, a table is called a table, a column of a table is called a column, and a row of a table is called a record. In a relational database, relationships between tables can be set and associated.
[0207] Generally, each table is set with a column serving as a key for uniquely identifying records, but setting a key for 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 a function of communicating with other computers 90 via a network. The communication unit can receive information transmitted from other computers 90 and input it to the control unit. The control unit can cause the processor 91 to execute information processing on the received information according to various programs. Further, the communication unit can transmit the information output from the control unit to other computers 90.
[0209] As described above, some embodiments of the present disclosure have been explained. However, these embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are to be included in the scope and gist of the invention, and are also to be included in the invention described in the claims and the equivalent scope thereof.
[0210] <Supplementary Note> The matters described in each of the above embodiments are appended below. (Supplementary Note 1) A program for causing a computer including a processor and a memory to execute, the program causing the processor to manage digital items included in a digital asset, and there being a service for granting a privilege according to the ownership status of the digital item, and generating, in response to a request from a user, information for transferring to the service to receive the grant of the privilege, which represents the digital items owned by the user. (Supplementary Note 2) The program according to (Supplementary Note 1), wherein in the generating step, a designation of a digital item for which the ownership status is to be confirmed is received from the user, and information indicating that the designated digital item is owned is generated. (Appendix 3) In the generating step, a program according to (Appendix 1) or (Appendix 2), which generates information indicating that the digital item is associated with predetermined related information. (Appendix 4) In the generating step, a program according to any one of (Appendix 1) to (Appendix 3), which generates information without affecting the digital item to be managed even if information is generated. (Appendix 5) In the information, a program according to any one of (Appendix 1) to (Appendix 4), in which the data structure of the digital item related to the information is not maintained. (Appendix 6) In the managing step, a program according to any one of (Appendix 1) to (Appendix 5), in which the digital item is usable in a game provided by a predetermined entity, and in the generating step, the service is a service separated from the game. (Appendix 7) In the managing step, a program according to any one of (Appendix 1) to (Appendix 6), which manages an event generated by a user, and in the generating step, there is a service that grants a privilege according to the occurrence status of the event, and generates information representing the event generated by the user and transferred to the service in order to receive the grant of the privilege in response to a request from the user. (Appendix 8) In the generating step, a program according to (Appendix 7), which generates information indicating that an event associated with predetermined information is occurring. (Appendix 9) In the managing step, a program according to (Appendix 1) to (Appendix 8), which manages the digital item in a distributed ledger formed by a computer network. (Appendix 10) In the generating step, a program according to any one of (Appendix 1) to (Appendix 9), which manages the generated information in a distributed ledger formed by a computer network. (Appendix 11) In the management step, a program as described in (Appendix 7) that manages events generated by a user using a distributed ledger formed by a computer network. (Appendix 12) A program for causing a computer including a processor and a memory to execute. The program causes the processor to execute steps of receiving information representing a digital item owned by a predetermined user, where the digital item is issued by a predetermined game service, is available in the game service, and is included in digital assets, and transferring the information; and based on the information representing the digital item owned by the received predetermined user, granting a privilege related to a service separated from the game service to the user. (Appendix 13) A method executed by a computer including a processor and a memory. The method includes steps where the processor manages digital items included in digital assets, and there is a service that grants privileges according to the ownership status of the digital items, and in response to a request from a user, generates information to be transferred to the service to receive the grant of a privilege, which represents the digital items owned by the user. (Appendix 14) An information processing apparatus including a control unit and a storage unit. The control unit manages digital items included in digital assets, and there is a service that grants privileges according to the ownership status of the digital items, and in response to a request from a user, generates information to be transferred to the service to receive the grant of a privilege, which represents the digital items owned by the user. (Appendix 15) A system comprising means for managing digital items included in digital assets, means for setting conditions for granting privileges according to the ownership status of digital items, means for generating information representing 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 privilege provider, and means for granting a privilege when the ownership status of the user's digital items satisfies the conditions based on the information whose owner has been changed.
Explanation of Signs
[0211] 1…System 10…Terminal device 12…Communication IF 120…Communication section 13…Input device 131…Touch-sensitive device 14…Output device 141…Display 15…Memory 150…Position information sensor 16…Storage 160…Camera 17…Audio processing section 171…Microphone 172…Speaker 180…Storage section 19…Processor 190…Control section 20…Server
Claims
1. A program for causing a computer including a processor and a memory to execute, the program causing the processor to manage digital items included in a digital asset; and there is a service that grants a privilege according to the ownership status of a digital item, and in response to a request from a user, generate information that proves that the user owns the digital item rather than the digital item itself, and transfer the information to the service to receive the privilege. A program to be executed.
2. The program according to claim 1, wherein in the generating step, a designation of a digital item for which the ownership status is to be confirmed is received from the user, and the information that proves that the user owns the designated digital item is generated.
3. The program according to claim 1, wherein in the generating step, the information that proves that the user owns a digital item with which predetermined related information is attached is generated.
4. The program according to claim 1, wherein in the generating step, even if the information is generated, it does not affect the digital item to be managed.
5. In the managing step, the digital item can be used in a game provided by a predetermined entity, The program according to claim 1, wherein in the generating step, the service is a service separated from the game.
6. The program according to claim 1, wherein in the managing step, the digital item is managed in a distributed ledger formed by a computer network.
7. 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.
8. A program for causing a computer including a processor and a memory to execute, the program causing the processor to transfer information that proves that a predetermined user owns a digital item and is not the digital item itself, wherein the digital item is issued by a predetermined game service, is available in the game service, and is included in a digital asset. Based on information proving that the specified user who received the transfer owns the digital item, granting the user the benefits related to the service separated from the game service A program for execution. **Claim 9** A method executed on a computer comprising a processor and a memory, wherein the processor manages digital items included in digital assets; there is a service that grants benefits according to the ownership status of digital items, and in response to a request from a user, generates information that proves the user owns the digital item rather than the digital item itself, and that is to be transferred to the service to receive the grant of the benefit A method for execution. **Claim 10** An information processing apparatus comprising a control unit and a storage unit, wherein the control unit manages digital items included in digital assets; there is a service that grants benefits according to the ownership status of digital items, and in response to a request from a user, generates information that proves the user owns the digital item rather than the digital item itself, and that is to be transferred to the service to receive the grant of the benefit An information processing apparatus for execution. **Claim 11** Means for managing digital items included in digital assets; 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 that proves the user owns the digital item rather than the digital item itself; Means for changing the owner of the information from the user to the provider of the benefit; Means for granting the benefit when the ownership status of the user's digital item satisfies the conditions based on the information with the changed owner A system comprising.
Citation Information
Patent Citations
Information processor
JP2002056293A
Game system and computer program used for the same
JP2020054892A
Game system and auction program
JP2021152815A
JPP6710401B
JPP7044927B