Program, method, information processing device, and system

Abstract

To increase the interest of creating a deck.SOLUTION: Provided is a program to be executed by a computer including a processor and a memory. The program causes the processor to execute the steps of: accepting a request to register a deck created by combining a plurality of digital cards from a first player; determining whether predetermined conditions including a fact that the deck having accepted a request to be registered from the first player is a deck which is created first are satisfied; registering the deck in association with the first player who has created the deck first, when predetermined conditions are satisfied; and allowing a second player to access the information regarding the registered deck, in which the information regarding the first player who has created the deck is included in the information regarding the deck.SELECTED DRAWING: Figure 20

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] JP 2013-034624 A Summary of the Invention [Problem to be solved by the invention]

[0004] In digital TCGs, players build decks by combining multiple digital cards they own in order to play against other players or the CPU. Building a strong deck, a unique deck, etc. is one of the joys of TCGs.

[0005] Patent Document 1 describes that a player creates a deck and registers the created deck for each game that is used. However, Patent Document 1 does not describe how to improve the interest of creating a deck.

[0006] An object of the present disclosure is to increase the interest in creating a deck. [Means for solving the problem]

[0007] A program to be executed by a computer having a processor and a memory. The program causes the processor to execute the steps of: accepting a request from a first player to register a deck created by combining a plurality of digital cards; determining whether the deck requested to be registered from the first player satisfies a predetermined condition including that the deck is the first deck created; if the predetermined condition is satisfied, registering the deck in association with the first player who created the deck; and allowing a second player to access information related to the registered deck and including information related to the first player who created the deck in the information related to the deck. Effect of the Invention

[0008] According to the present disclosure, it is possible to increase the interest in creating a deck. [Brief description of the drawings]

[0009] [Figure 1] FIG. 2 is a diagram showing a situation in which a TCG match is being prepared according to the present embodiment. [Diagram 2] FIG. 2 is a diagram showing a situation in which a TCG match according to the present embodiment is about to begin. [Diagram 3] FIG. 2 shows a situation in which each user is progressing in a TCG match. [Figure 4] 1 is a block diagram showing an example of the overall configuration of a system 1. FIG. [Diagram 5] 5 is a block diagram illustrating an example of the configuration of a terminal device 10 shown in FIG. 4. [Figure 6] FIG. 2 is a diagram illustrating an example of a functional configuration of a server 20. [Figure 7] FIG. 13 is a diagram showing the data structure of card information 182. [Figure 8] FIG. 13 is a diagram showing the data structure of deck information 183. [Figure 9] FIG. 2 is a diagram showing the data structure of a user information table 2021. [Figure 10] FIG. 2 shows the data structure of a card master table 2022. [Figure 11] FIG. 23 is a diagram showing the data structure of a deck information table 2023. [Figure 12] 13 is a diagram showing the data structure of a match information table 2024. FIG. [Figure 13] FIG. 23 is a diagram showing the data structure of a benefit information table 2025. [Figure 14] 2 is a schematic diagram showing an example of a deck list displayed on the terminal device 10. FIG. [Figure 15] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 16] 1 is a schematic diagram showing an example of an editing screen for deck 2 displayed on the terminal device 10. FIG. [Figure 17] 10 is a diagram illustrating an example of the operation of the terminal device 10 and the server 20 when a user registers a deck. [Figure 18] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 19] 13 is a flowchart showing an example of the operation of the server 20 when registering a deck. [Figure 20] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 21] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 22] 13 is a flowchart showing an example of the operation of the server 20 when registering a deck. [Figure 23] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 24] 13 is a flowchart showing an example of the operation of the server 20 when associating a deck with a creator of the deck. [Diagram 25] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 26] 10 is a diagram illustrating an example of the operation of the terminal device 10 and the server 20 when managing deck battle information. FIG. [Figure 27] 2 is a schematic diagram showing a display example of a display 141. FIG. [Figure 28] FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment 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 description thereof will not be repeated.

[0011] <Summary> In the program according to the present embodiment, if a deck created by a player satisfies certain conditions, including the deck being the first deck created, the deck is registered in association with the first player who created the deck for the first time. Information about the registered deck includes information about the first player, and is made public by access from the first player, or the first player and players.

[0012] First, an overview of the TCG according to this embodiment will be described, followed by a description of the card management system.

[0013] <0 Overview of TCG> Fig. 1 is a diagram showing a situation in which a TCG match according to the present embodiment is being prepared. Fig. 2 is a diagram showing a situation in which a TCG match according to the present embodiment is about to start. Fig. 3 is a diagram showing a situation in which each user is progressing in a TCG match.

[0014] A user places a play mat 30 and plays a TCG match using a deck constructed by combining cards to be used in the TCG match.

[0015] <0.1 Composition of 30 playmats> With reference to Fig. 1, various items used by each user in a TCG match will be described. As shown in Fig. 1, when a user 5A (first user) and a user 5B (second user) start a TCG match, a play mat 30 is placed between the user 5A and the user 5B. The play mat 30 is for placing cards included in a deck. Each user places cards on the play mat 30 as a deck or the like, and proceeds with the TCG match while adding cards from the deck to their hand.

[0016] The structure of the play mat 30 will be described. The play mat 30 includes, for example, a mat on which the positions for placing cards are indicated. The play mat 30 includes, for example, a deck placement section 31A and a deck placement section 31B (hereinafter, sometimes collectively referred to as the "deck placement section 31"), a preparation card placement section 32A and a preparation card placement section 32B (hereinafter, sometimes collectively referred to as the "preparation card placement section 32"), a win / lose condition card placement section 33A and a win / lose condition card placement section 33B (hereinafter, sometimes collectively referred to as the "win / lose condition card placement section 33"), a battle card placement section 34A and a battle card placement section 34B (hereinafter, sometimes collectively referred to as the "battle card placement section 34"), and a consumption card placement section 35A and a consumption card placement section 35B (hereinafter, sometimes collectively referred to as the "consumption card placement section 35").

[0017] As shown in Fig. 3, in a TCG match, each user replenishes their hand with cards from the deck while progressing through a card battle. In the example of Fig. 3, user 5A has hand 93A (two cards in the hand in the example of Fig. 3). User 5B has hand 93B (three cards in the hand in the example of Fig. 3).

[0018] The deck placement section 31 is an area for placing any of the cards constituting the deck owned by each user as a deck. The deck placement section 31A is an area for the user 5A to place cards as a deck. The deck placement section 31B is an area for the user 5B to place cards as a deck.

[0019] 2, when each user starts a TCG match, each user shuffles the cards that make up the deck and places the cards face down in the deck placement section 31. User 5A places cards in the deck placement section 31A as a deck 91A. User 5B places cards in the deck placement section 31B as a deck 91B.

[0020] The preparation card placement section 32 is an area for preparing cards that can be used to fight against the opponent's cards. Each user switches the cards placed in the preparation card placement section 32 with the cards placed in the battle card placement section 34, and makes the cards placed in the battle card placement section 34 fight each other.

[0021] As shown in Fig. 2, before the start of a TCG match, no cards are placed in the preparation card placement unit 32 and the battle card placement unit 34. On the other hand, as shown in Fig. 3, as the TCG match progresses, each user places cards in the preparation card placement unit 32 and the battle card placement unit 34, and the cards are made to fight each other in the battle card placement unit 34. Each user places cards to be used in the battle from their hand in the preparation card placement unit 32 and the battle card placement unit 34 while replenishing their hand from the deck. User 5A places cards in the preparation card placement unit 32A. User 5B places cards in the preparation card placement unit 32B.

[0022] The win / loss condition card placement section 33 is an area showing to what extent each player has satisfied the win condition. In this embodiment, each player places a predetermined number of cards from the deck face down in the win / loss condition card placement section 33. As shown in FIG. 2, user 5A places cards in the win / loss condition card placement section 33A. User 5B places cards in the win / loss condition card placement section 33B.

[0023] The battle card placement section 34 is an area for placing cards that will fight against the opponent's cards. The user 5A places cards in the battle card placement section 34A. The user 5B places cards in the battle card placement section 34B. In this embodiment, the cards placed in the battle card placement section 34A and the cards placed in the battle card placement section 34B basically fight based on the vitality, attack power, character attributes shown on the cards, weak point attributes, and other parameters set for each card. The cards placed in the battle card placement section 34 are given damage according to the attack power, card attributes, weak points, etc., and the given damage is reduced from the vitality. When the vitality set for a card is lost due to being attacked, etc., the card is removed from the battle card placement section 34 and placed in the consumption card placement section 35.

[0024] The consumed card placement section 35 is an area for placing cards consumed in a TCG match. For example, cards that have lost vitality in a battle, cards that have activated their effects, etc. are placed in the consumed card placement section 35. As shown in FIG. 3, user 5A places cards consumed in a match as cards 92A in the consumed card placement section 35A. User 5B places cards consumed in a match as cards 92B in the consumed card placement section 35B.

[0025] The cards placed in the consumed card placement section 35 can be placed in the deck placement section 31, the preparation card placement section 32, the hand, etc., by activating a predetermined card effect. The play mat 30 may further have an area for placing cards consumed in a match in addition to the consumed card placement section 35. This area is referred to as, for example, a second consumed card placement section. The cards placed in the second consumed card placement section will not be returned to the field even if the effect of the predetermined card is activated. Note that a predetermined effect may be activated depending on the number of cards placed in the second consumed card placement section.

[0026] <0.2 Types of cards used in TCG> In the TCG of this embodiment, the types of cards include: (i) character cards that can be used in battle, (ii) action cards (energy cards) that are used in association with character cards, and (iii) effect cards (support cards, goods cards, stadium cards, etc.) that exert specific effects during battle.

[0027] (i) Character cards include cards that can be placed in the preparation card placement area 32 or the battle card placement area 34 when a user draws a card from the deck and adds it to their hand (also referred to as “unconditional cards”), and cards that can be placed in the preparation card placement area 32 or the battle card placement area 34 by satisfying certain conditions (also referred to as “conditional cards”).

[0028] (iA) For example, a conditional card can be placed on the condition that an unconditional card related to the conditional card is placed. For example, in analogy with character evolution, an unconditional card is first presented to an opponent user by placing it on the play mat 30, and then a conditional card related to the unconditional card is placed on the play mat 30. Such a conditional card is sometimes called an "evolved character" as it is evolved from an unconditional card. In addition, the unconditional card is sometimes called a "seed character" because it can be said to be a character that is the source of the "evolved character" to be placed.

[0029] (iB) For example, a conditional card can be placed in the preparation card placement section 32 or the battle card placement section 34 by consuming a specific card and moving it to the consumption card placement section 35. Specifically, it may be possible to consume an unconditional card placed on the play mat 30 as a specific card (by moving it to the consumption card placement section 35) and place the conditional card in the preparation card placement section 32 or the battle card placement section 34.

[0030] For example, a conditional card can be placed in the preparation card placement section 32 or the battle card placement section 34 in exchange for one or more character cards placed by the user on the play mat 30. For example, if each character card is provided with a parameter (e.g., an evolution level) indicating the overall performance of the character in addition to individual parameters such as the attack power of the character shown on the card, a conditional card having an evolution level corresponding to the evolution level value of the character card placed by the user may be placed. For example, with a character of evolution level 1 and a character of evolution level 2 placed on the play mat 30, a conditional card of evolution level 3 can be placed on top of the cards of these characters (or in exchange for these character cards).

[0031] In addition, the conditional card may be allowed to participate in the battle in exchange for a plurality of character cards defined by the conditional card. In this case, the conditional card may be allowed to participate in the battle by consuming an auxiliary card, which will be described later, different from the character card. For example, the effect indicated by the auxiliary card may be set such that a specific conditional card can be allowed to participate in the battle in exchange for a specific unconditional card in the battle card arrangement section 34, the consumption card arrangement section 35, or the like of the play mat 30.

[0032] (iC) These cards include cards that serve as multiple of the above-mentioned character cards, action power cards, and support cards described below. For example, special cards that can be used as both character cards and support cards may be included. When the user places the special card in a position where a character card should be placed (e.g., the preparation card placement area 32, the battle card placement area 34), the user can use the special card as a character card.

[0033] (ii) An action power card (energy card) is a card that a user draws from a deck and adds to his / her hand, and then associates it with a character card and places it on the play mat 30, thereby enabling the user to perform a predetermined action indicated on the character card. The operation of associating an action power card with a character card may be performed, for example, during the user's turn. For example, the action power card may be associated with a character card by placing the action power card near the character card placed on the play mat 30. In addition, the number of times that an action power card can be associated with a character card during a turn may be limited. For example, once during the user's turn, an action power card in the hand may be associated with any of the character cards placed on the play mat 30. For example, a first attack action and a second attack action are set to the character card. The first attack action may be available when one action power card is associated with the character card, and the second attack action may be available when one action power card is not enough and two action power cards are associated with the character card.

[0034] When a character card is removed from the battle card placement section 34 due to the exhaustion of its vitality value in a battle, the action power card associated with the character card may be made unusable during the battle. Also, the action power card associated with the character card may be moved to the consumption card placement section 35.

[0035] (iii) Support cards that assist in a match include card types that a user can use any number of times during a turn as long as they are in the user's hand, and card types that a user can use only one card during a turn. These support cards also include cards that have their effect activated when the user declares that they will use the effect of the support card.

[0036] In addition, the auxiliary card may be placed face down in advance in a predetermined position on the play mat 30 (in this embodiment, the predetermined position is not shown), and the effect of the auxiliary card may be exerted when the user declares the use of the auxiliary card by vocalization or the like.

[0037] <0.3 Overview of TCG battle rules> The play mat 30 and the types of cards used in the TCG match have been explained above. Next, the TCG match rules will be explained in detail.

[0038] In the TCG shown in this embodiment, as described above, each user performs an attack or defense (battle) based on the cards placed in the battle card placement section 34A and the battle card placement section 34B to progress the TCG battle. The TCG battle progresses as the users take turns to act. For example, when a first user acts and ends his turn, it becomes the second user's turn. The second user acts during his turn, and when he ends his action, it becomes the first user's turn.

[0039] Each time a turn comes, each user draws a predetermined number of cards from the deck and adds them to their hand.

[0040] Each user places, from among the cards in his / her hand, candidates for cards (character cards) to be used in attack or defense against the opponent user's cards in the preparation card placement section 32.

[0041] The user 5A can switch between the cards arranged in the preparation card placement unit 32A and the cards arranged in the battle card placement unit 34A during the turn of the user 5A. Also, the user 5B can switch between the cards arranged in the preparation card placement unit 32A and the cards arranged in the battle card placement unit 34A during the turn of the user 5B.

[0042] As described above, the win / loss condition card placement section 33A and the win / loss condition card placement section 33B are areas for notifying each user of the degree of progress toward the conditions for winning the match. Here, the condition for a user to win the match may be, for example, that all cards placed in the win / loss condition card placement section 33A or the win / loss condition card placement section 33B are collected. In other words, the outcome of the match may be decided when all cards are collected in either the win / loss condition card placement section 33A or the win / loss condition card placement section 33B.

[0043] For example, each user places a predetermined number of cards from the deck in the win / lose condition card placement section 33 before a TCG match. That is, the user 5A removes a predetermined number of cards from the deck 91A and places them in the win / lose condition card placement section 33A. The user 5B removes a predetermined number of cards from the deck 91B and places them in the win / lose condition card placement section 33B. The user 5A and the user 5B make the character card placed in the battle card placement section 34A and the character card placed in the battle card placement section 34B battle each other, and when the exit condition set for the character card is satisfied (for example, when the vitality value set for the character card is subtracted based on the attack power set for the opponent's character card and runs out), the character of the character card is considered to have fainted, and the character card is moved to the consumption card placement section 35 (also called "trash").

[0044] As a result, the user who has won the battle and dismissed the opponent's character card adds the cards placed in the win / loss condition card placement section 33A or the win / loss condition card placement section 33B to his / her hand. For example, when the user 5B dismisses the cards placed in the battle card placement section 34A by attacking the character card of the user 5A in his / her turn, he / she takes a predetermined number of cards from the cards placed in the win / loss condition card placement section 33B and adds them to his / her hand. On the other hand, when the user 5A dismisses the cards placed in the battle card placement section 34B by attacking the character card of the user 5B in his / her turn, he / she takes a predetermined number of cards from the cards placed in the win / loss condition card placement section 33A and adds them to his / her hand. By repeating these operations, when the user 5B collects all the cards placed in the win / loss condition card placement section 33B, or when the user 5A collects all the cards placed in the win / loss condition card placement section 33A, the user who has collected all the cards may be determined to be the user who won the TCG battle.

[0045] Alternatively, the winning condition of the match may be that a user loses if there is no character card in either the battle card placement unit 34 or the preparation card placement unit 32. Alternatively, the winning condition of the match may be that a user loses if he or she is unable to draw a deck from the deck placement unit 31 during his or her turn.

[0046] 1 to 3 illustrate an example in which users face each other to play a TCG match. However, the TCG match is not limited to one in which users face each other. Users may connect to each other via the Internet and play a match by acquiring the opponent's voice and the opponent's card arrangement, etc., via the Internet. Specifically, for example, a user plays a match while taking a picture of his / her own area on the play mat 30 with a camera or the like. The taken image is transmitted to the opponent in real time. The user receives an image of the opponent's area sent from the opponent, and displays the received image on a display. This allows the user to check the opponent's cards in real time through the screen while handling his / her own cards in reality. In this way, the user may play a TCG match using analog cards online.

[0047] If there are multiple cameras or if there is a device that allows the viewing angle of the camera to be adjusted, the user's face may be photographed and the photographed image may be sent to the opponent. This allows the opponent's facial expression to be confirmed during the match, making it possible to obtain the same level of satisfaction in an online TCG match as in a face-to-face match.

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

[0049] 4 shows an example in which the system 1 includes three terminal devices 10, but the number of terminal devices 10 included in the system 1 is not limited to three. The number of terminal devices 10 included in the system 1 may be two or less, or may be four or more.

[0050] 4 shows an example in which the system 1 includes one server 20, but the number of servers 20 included in the system 1 is not limited to one. The server 20 may be composed of multiple servers depending on the functions it has. Also, the server 20 may be, for example, a collection of multiple devices that constitutes one server. The method of allocating multiple functions required to realize the server 20 according to this embodiment to one or multiple pieces of hardware can be appropriately determined in consideration of the processing capacity of each piece of hardware and / or the specifications required for the server 20.

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

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

[0053] The server 20 is, for example, an information processing device that manages information related to cards and information related to decks.

[0054] The server 20 is realized by, for example, a computer connected to a network 80. As shown in Fig. 4, the 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 with an input device for receiving an input operation from a user and an output device for presenting information to the user.

[0055] Each information processing device is configured by a computer equipped with a calculation device and a storage device. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by the hardware configuration will be described later. For each of the terminal device 10 and the server 20, descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer described later will be omitted.

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

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

[0058] The input device 13 is a device for inputting instructions or information by a user who operates the terminal device 10. The input device 13 is realized, for example, by a touch-sensitive device 131 or the like in which an instruction is input by touching an operation surface. In the case where 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 by a 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 receiving port that receives an electrical signal input from an external input device.

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

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

[0061] The camera 160 is a device for receiving light with a light receiving element and outputting the received light as an image capturing signal.

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

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

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

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

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

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

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

[0069] Furthermore, operation acceptance unit 191 accepts an image input from camera 160. Specifically, operation acceptance unit 191 receives image data captured by camera 160, for example.

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

[0071] The transmitting / receiving unit 192 performs processing for the terminal device 10 to transmit and receive data to and from an external device such as the server 20 in accordance with a communication protocol. Specifically, for example, the transmitting / receiving unit 192 transmits instructions input by the user or various pieces of acquired information to the server 20. The transmitting / receiving unit 192 also receives information provided from the server 20. The information provided from the server 20 includes, for example, information about a new card acquired by the user or information about the deck.

[0072] Management unit 193 manages user information 181, card information 182, and deck information 183 stored in storage unit 180. For example, when information about a user is edited, management unit 193 stores the edited information in user information 181. Furthermore, when information about a card is updated, management unit 193 updates card information 182. Furthermore, when information about a deck is updated, management unit 193 updates deck information 183.

[0073] The display control unit 194 controls the output device 14 to display a predetermined image to the user. For example, the display control unit 194 controls the display 141 to display a management screen of cards owned by the user based on information managed in the card information 182 and information managed in the deck information 183. The display control unit 194 also controls the display 141 to display information related to the deck.

[0074] The battle processing unit 195 controls the battle processing with other decks. The battle may take the following forms, for example. - Play against the CPU using a deck built with digital cards - Play against other players using decks built with digital cards - Play against other players by reading analog cards with a camera · Competition

[0075] <1.2 Functional configuration of the server> 6 is a diagram showing an example of a functional configuration of the server 20. As shown in FIG. 6, the server 20 fulfills the functions of a communication unit 201, a storage unit 202, and a control unit 203.

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

[0077] The memory unit 202 has, for example, a user information table 2021, a card master table 2022, a deck information table 2023, a battle information table 2024, and a benefit information table 2025.

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

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

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

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

[0082] The privilege information table 2025 is a table that stores, for example, information (privilege information) about privileges to be granted to users, as will be described in detail later.

[0083] The control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. The control unit 203 performs functions as a reception control module 2031, a transmission control module 2032, a management module 2033, an assignment module 2034, and a battle processing module 2035 by operating according to the program.

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

[0085] The transmission control module 2032 controls the process in which the server 20 transmits signals to external devices in accordance with a communication protocol.

[0086] The management module 2033 manages the tables stored in the storage unit 202. Specifically, for example, when the management module 2033 receives an instruction related to a deck, the management module 2033 updates the deck information table 2023 based on the received instruction. Furthermore, when the management module 2033 receives information related to a battle, the management module 2033 updates the deck information table 2023 and the battle information table 2024 based on the received information.

[0087] The granting module 2034 grants a privilege to a user. For example, the granting module 2034 refers to the privilege information table 2025 and grants a privilege to a user who satisfies a condition.

[0088] The match processing module 2035 controls the processing of a match between users. For example, the match processing module 2035 controls a match between players using decks constructed with digital cards. The match processing module 2035 also controls a match between players using analog cards read by a camera, for example.

[0089] <2 Data Structure> Figures 7 and 8 are diagrams showing the data structure of information stored in the terminal device 10. Note that Figures 7 and 8 are merely examples, and do not exclude data that is not shown.

[0090] Fig. 7 is a diagram showing the data structure of card information 182. Card information 182 shown in Fig. 7 is a table having columns such as name, type, attribute, card information, image data, and number of cards, with a card ID as a key. In addition to these, card information 182 may also have information such as a card management ID for uniquely identifying a card even when the card is identical, regulations, or rarity.

[0091] The card ID is an item that stores an identifier for uniquely identifying the type of card. In this embodiment, the same card ID is assigned to identical cards. Even if cards have the same name, different card IDs are assigned to cards with different effects, different rarities, or different regulations. The name is an item that stores the name of the card. The type is an item that stores the type of card. In this embodiment, card types include, for example, character, energy, support, goods, stadium, etc.

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

[0093] Image data is an item that stores an image. Image data may store reference information (path) for an image data file located elsewhere. Number is an item that stores the number of cards owned by the user that are assigned the same card ID. In this embodiment, cards with the same name but different effects are assigned different card IDs. Also, cards with the same name but different rarities are assigned different card IDs. Also, cards with the same name but different regulations are assigned different card IDs. Note that if owned cards are each uniquely managed by a card management ID, the number does not need to be managed.

[0094] FIG. 8 is a diagram showing the data structure of the deck information 183. The deck information 183 shown in FIG. 8 is a table having columns such as name, organized card, completion, update date, and registration information, with the deck ID as a key. The deck information 183 may also have information on the nickname of the deck, the use history of the deck, and a representative image, in addition to the above. The nickname of the deck is, for example, a name given based on a characteristic card used in the deck, which succinctly expresses the characteristics of the deck and is given based on a common recognition among multiple users. The representative image is, for example, an image of a card designated by a user among the cards organized in the deck. The representative image is, for example, an image related to an illustration among the descriptions on the card, excluding text. The representative image is, for example, an image reduced to a predetermined number of pixels, for example, a thumbnail image.

[0095] 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 may be generated, for example, based on a portion of the cards that make up the deck, or may be given by the user. The organization card is an item that stores the cards that make up the deck. In the organization card, for example, the card IDs of the cards that make up the deck are stored.

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

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

[0098] Figures 9 to 13 are diagrams showing data structures of information stored in the server 20. Note that Figures 9 to 13 are merely examples, and do not exclude data that is not shown.

[0099] Fig. 9 is a diagram showing the data structure of a user information table 2021. The user information table 2021 shown in Fig. 9 is a table having columns such as name, age, address, date of birth, date of registration, and following, with a user ID as a key. The user information table 2021 is not limited to the above, and may have columns such as proficiency level.

[0100] 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 a service related to the TCG. The following is an item that stores information about other users that the user is following. For example, the user IDs of other users that the user is following are stored in the following.

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

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

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

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

[0105] FIG. 11 is a diagram showing the data structure of the deck information table 2023. The deck information table 2023 shown in FIG. 11 is a table having columns such as name, creator, creation date, organization card, match information, and publication, with the deck code as a key. In addition to these, the deck information table 2023 may have information on the nickname of the deck, a representative image, a registrant, the number of views, the date on which the user requested registration, and the date on which the use of the deck achieved a predetermined condition. The registrant, for example, stores a user who is not the creator among users who have registered a deck. In other words, the registrant represents the user ID of the user who created and registered a deck after the second time. In addition, information that can distinguish the registrants may be included. For example, a number that can recognize the order of registration may be included. In other words, when the creator is assigned "1", the first registrant is assigned "2". When the first registrant is assigned "1", the next registrant may be assigned "2". In this way, the user can understand the order in which the deck was started to be used, and can be aware of being ahead of the trend, for example. The number of views may be, for example, the number of users who have confirmed the contents of the deck. If the server 20 provides a function for copying deck composition, the number of users who have copied the deck may be stored as the number of references.

[0106] The deck code is an item that stores an identifier for uniquely identifying a registered deck. The deck code is issued by the management module 2033 when the deck requested to be made public by the user is a new deck. A new deck, for example, refers to a deck in which at least a part of the deck is different from existing decks. In other words, a new deck can be said to refer to a deck in which no deck with the exact same configuration exists. The deck code shown in FIG. 11 is an identifier that is different from, for example, the deck ID shown in FIG. 8. This is because the deck code shown in FIG. 11 is for managing public decks, and the deck ID shown in FIG. 8 is for managing one's own deck.

[0107] Name is an item that stores the name of the deck. The name is given by the user. Creator is an item that stores the user ID of the user who originally created the deck. Creation date is an item that stores the date the deck was originally created. Organization card is an item that stores the cards that make up the deck. In the organization card, for example, the card IDs of the cards that make up the deck are stored. Match information is an item that stores information about a match that was performed using a deck identified by a deck code. Match information includes, for example, the following information: - Match ID to identify the match Date and time of the match -Participated competitions Competition Results

[0108] The "Public" field stores whether or not the deck is publicly available to other users. In this embodiment, a circle indicates that the deck is publicly available to other users, and a cross indicates that the deck is not publicly available to other users. In this embodiment, a deck that is not publicly available means that only the user can view it.

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

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

[0111] 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 about a battle is registered. The date and time is an item that stores the date and time when the battle took place. The opponents is an item that stores information about the players who fought the battle. In this embodiment, for example, the opponents store the user IDs of the players who fought the battle.

[0112] The deck code is an item that stores a code that identifies the deck used in the match. In this embodiment, for example, a player who has played a match is associated with the deck code of the deck used by that player. The deck code does not necessarily have to be stored. In other words, the deck code does not have to be registered. When the deck code is not registered, for example, the item "deck code" may store information that represents the deck, which is determined from the contents of the cards included in the deck. At this time, for example, the management module 2033 creates information that represents the deck based on the cards included in the deck, and stores the created information in the item "deck code". For example, the management module 2033 creates information that represents the deck based on the names of the main cards included in the deck. The management module 2033 may also store information about the cards included in the deck in the item "deck code".

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

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

[0115] Fig. 13 is a diagram showing the data structure of the privilege information table 2025. The privilege information table 2025 shown in Fig. 13 is a table having columns such as privilege content, conditions, etc., with a privilege ID as a key.

[0116] The privilege ID is an item for storing an identifier for uniquely identifying a privilege. The privilege content is an item for storing the content of the privilege. The condition is an item for storing the condition for granting the privilege.

[0117] <3 operations> The operations of the terminal device 10 and the server 20 when a user constructs a deck and registers the constructed deck will be described.

[0118] (Deck Construction) A user operates the terminal device 10 to edit cards and build a deck made up of multiple digital cards.

[0119] The user inputs an instruction to the terminal device 10 to display a list of cards owned by the user. Specifically, for example, the user executes an application related to a digital TCG installed in the terminal device 10. In the launched application, the user inputs an instruction to the terminal device 10 to display the cards owned by the user. The control unit 190 of the terminal device 10 causes the display control unit 194 to display the list of cards on the display 141 based on the card information 182 and deck information 183.

[0120] The user inputs an instruction to the terminal device 10 to display a list of decks owned by the user. Specifically, for example, the user touches an instruction object for inputting an instruction to display a list of decks in a list display of cards. The display control unit 194 displays a list of decks on the display 141 based on the deck information 183. The user may launch an app related to a digital TCG installed in the terminal device 10, and input an instruction to the terminal device 10 to edit the deck in the launched app.

[0121] Fig. 14 is a schematic diagram showing an example of a deck list displayed on the terminal device 10. In Fig. 14, the display control unit 194 displays an area 1411 and an area 1412. The area 1412 is an area that displays decks owned by the user in a format conforming to the display conditions described in the area 1411.

[0122] In the example shown in FIG. 14, a display order is displayed in area 1411 as a display condition. The display order indicates a rule of sequence. The display order is selected by the user from among, for example, number order, name order, update date order, etc. In the example shown in FIG. 14, "display order: name order" is selected, and the decks are arranged in area 1412 in the order of their names.

[0123] A search window 14111 is displayed in area 1411. When a user finds a desired deck, the user inputs keywords or the like into search window 14111 to search for the desired deck.

[0124] When the user selects a deck, the display control unit 194 displays on the display 141 processes that can be performed on the deck selected by the user.

[0125] Fig. 15 is a schematic diagram showing a display example of the display 141. In the example shown in Fig. 15, the display control unit 194 displays a window 14121 in which processes for the deck are displayed in a selectable list form. The display control unit 194 displays, for example, edit, register, etc. as processes for the deck in the window 14121. The user operates the input device 13 to select the process for the deck.

[0126] For example, the user inputs an instruction to the terminal device 10 to display an editing screen for the selected deck. Specifically, for example, the user selects "Edit" in the window 14121 shown in Fig. 15. The display control unit 194 displays the deck editing screen on the display 141 based on the card information 182 and deck information 183.

[0127] FIG. 16 is a schematic diagram showing an example of an editing screen for deck 2 displayed on the terminal device 10. FIG. 16 shows an editing screen in the case where deck 2 is selected by the user, but the deck selected by the user is not limited to deck 2. In FIG. 16, the display control unit 194 displays an area 1411, an area 1413, and an area 1414. The area 1413 is an area for displaying cards constituting the deck in a manner conforming to the display conditions described in the area 1411. The area 1414 is an area for displaying a list of cards owned by the user in a manner conforming to the display conditions described in the area 1411. In the area 1414, cards are displayed in a manner that can be replaced with the cards displayed in the area 1413. The cards displayed in the area 1413 may be displayed in a manner that can be distinguished from the cards displayed in the area 1414. In the example shown in FIG. 16, the cards displayed in the area 1413 are displayed larger than the cards displayed in the area 1414.

[0128] In the example shown in FIG. 16, a display order is displayed in area 1411 as a display condition. The display order indicates a rule of sequence. The display order is selected by the user from among, for example, number order, name order, rarity order, acquisition date order, etc. In the example shown in FIG. 16, "display order: number order" is selected, and the cards are arranged in areas 1413 and 1414 in the order of card ID.

[0129] (Deck Registration) The user operates the terminal device 10 to register the constructed deck.

[0130] FIG. 17 is a diagram illustrating an example of the operation of the terminal device 10 and the server 20 when a user registers a deck.

[0131] For example, the user operates the terminal device 10 to select a desired deck and input a command to register the selected deck. Specifically, for example, the user selects "Register" in the window 14121 shown in FIG.

[0132] When the user selects "Register", the terminal device 10 causes the display control unit 194 to display a screen for confirming that the deck is to be registered.

[0133] Fig. 18 is a schematic diagram showing an example of display on the display 141. In the example shown in Fig. 18, the display control unit 194 displays a window 14122 for confirming that the deck is to be registered. Buttons 141221 and 141222 for inputting the user's intention are displayed in the window 14122. If there is no mistake in registering the deck, the user presses the Yes button 141221. In this embodiment, pressing the button 141221 means inputting a registration request.

[0134] In step S11, the terminal device 10 accepts a deck registration request input by the user via the operation acceptance unit 191. The terminal device 10 transmits the accepted registration request to the server 20 via the transmission / reception unit 192.

[0135] In step S12, the server 20 registers a deck based on a deck registration request from a user. Specifically, for example, the control unit 203 of the server 20 creates, in the deck information table 2023, a record of a new deck configuration among the decks for which registration has been requested, by the management module 2033.

[0136] The management module 2033 associates the newly organized deck with the creator of the deck. Specifically, for example, the management module 2033 stores the user ID of the creator of the deck in the item "creator" of the newly created record.

[0137] For a registration request for a deck that is not new, the management module 2033 associates the user who requested the registration with the existing deck for which registration is requested. For example, the management module 2033 stores the user ID of the user who requested the registration in the "registrant" field of the record for the existing deck for which registration is requested.

[0138] In step S13, the management module 2033 sets the disclosure range of the registered deck. Specifically, the management module 2033, for example, checks with the user who registered the deck whether or not the registered deck is to be disclosed to other users other than the user.

[0139] If a user wishes to make the deck public to other users, the management module 2033 manages the deck so that it can be accessed by other users. For example, the management module 2033 stores a circle in the “Public” item in the deck information table 2023.

[0140] If a user does not want to make the deck public to other users, the management module 2033 manages the deck so that other users cannot access it. For example, the management module 2033 stores a cross in the “Public” item in the deck information table 2023.

[0141] In the user information table 2021, other users that the user follows are registered. When a deck is registered by a specific user, the management module 2033 may notify users following the user that a new deck has been registered by the user. There are users who are skilled at building new decks. By following such users, other users can grasp the current trends of decks.

[0142] (Details on deck registration 1) The process of the control unit 203 shown in step S12 of FIG. 17 will be described in detail.

[0143] FIG. 19 is a flowchart showing an example of the operation of the server 20 when registering a deck.

[0144] In step S21, the control unit 203 of the server 20 determines, via the management module 2033, whether or not the deck requested to be registered is a new deck. Specifically, the management module 2033 determines whether or not at least some of the cards forming the deck are different from cards forming an existing deck. The management module 2033 may determine whether or not a deck with the exact same configuration exists, or may determine whether or not a deck exists whose configuration matches a certain condition. The following describes an example in which a deck with the exact same configuration does not exist.

[0145] If a deck with the exact same configuration does not exist, the management module 2033 determines that the deck for which registration has been requested is a new deck, and moves the process to step S22.

[0146] In step S22, the management module 2033 creates a new record in the deck information table 2023 and assigns a deck code to the created record. The management module 2033 stores information about the requested deck in the created record. The management module 2033 stores, for example, the name of the created record and the organization card based on information input by the user. The management module 2033 also associates the newly created deck record with the user who has requested the deck registration. That is, the management module 2033 stores the user ID of the user who has requested the deck registration in the record's "creator" item, and stores the date on which it was determined that the deck was new in the record's "creation date" item.

[0147] In step S23, the transmission control module 2032 notifies the terminal device 10 that the deck requested to be registered has been registered. Specifically, the transmission control module 2032 transmits the information that the deck requested to be registered has been registered, together with the deck code of the registered deck, to the terminal device 10 that issued the registration request.

[0148] Upon receiving the notification from the server 20, the control unit 190 of the terminal device 10 causes the display control unit 194 to display on the display 141 that the deck has been registered and that the user has been associated as the creator. The display control unit 194 may display on the display 141 the reason that the deck requested to be registered has been registered because it is a deck with a new configuration. The control unit 190 also causes the management unit 193 to associate the deck code with the corresponding record in the deck information 183. This enables the display control unit 194 to display that the stored deck is a deck registered in the server 20.

[0149] Fig. 20 is a schematic diagram showing a display example of the display 141. In the example shown in Fig. 20, the display control unit 194 displays a window 14123 for notifying that a deck has been registered and that the user has been associated as the creator. There is no restriction on the expression of the present tense or past tense in the window 14123. The window 14123 displays a button 141231 for inputting that the notification has been confirmed. When the user has confirmed the notification content, he or she presses the confirmation button 141231.

[0150] 17, the terminal device 10 accepts a selection from the user as to whether or not to make the registered deck public to other users. Specifically, the display control unit 194 displays on the display 141 an image for accepting the selection as to whether or not to make the registered deck public to other users.

[0151] Fig. 21 is a schematic diagram showing an example of display on the display 141. For example, when the user presses the confirmation button 141231 on the screen shown in Fig. 20, the display control unit 194 displays a window 14124 for accepting a selection of disclosing to other users. Buttons 141241 and 141242 for inputting the user's intention are displayed on the window 14124. When disclosing the deck to other users, the user presses the Yes button 141241. The transmission / reception unit 192 transmits an instruction regarding disclosing the deck to the server 20.

[0152] When an instruction regarding the publication of a deck is received, the server 20, via the management module 2033, stores information regarding the publication in the "Public" item of the deck information table 2023. As a result, when a check mark is stored in the "Public" item, other users can also check the composition and creator of the deck. On the other hand, when a cross is stored in the "Public" item, only the creator user can check the composition and creator of the deck.

[0153] If it is determined in step S21 that the deck requested to be registered is not a new deck, the management module 2033 transitions the process to step S24.

[0154] In step S24, the management module 2033, for example, associates the user who requested the registration with an existing deck. Specifically, for example, the management module 2033 refers to the deck information table 2023 and acquires a deck that is the same as the deck requested to be registered. The management module 2033 stores the user ID of the user who requested the registration in the record of the acquired deck. This makes it possible to associate the existing deck with the user who requested the registration.

[0155] In step S24, the transmission control module 2032 notifies the terminal device 10 that the deck requested to be registered already exists. Specifically, the transmission control module 2032 transmits to the terminal device 10 that has issued the registration request a message indicating that an identical deck already exists and the deck code of the existing deck. The transmission control module 2032 may also transmit to the terminal device 10 that has issued the request a user ID of the user who created the existing deck. This increases the presence of the user who created the deck, which may motivate the user to create a deck first.

[0156] Upon receiving the notification from the server 20, the control unit 190 of the terminal device 10 causes the display control unit 194 to display on the display 141 that a deck already exists. The control unit 190 also causes the management unit 193 to associate the deck code of the existing deck with the corresponding record in the deck information 183. This enables the display control unit 194 to display that the stored deck is a deck registered in the server 20.

[0157] The process of step S24 is not essential. If it is not necessary to associate an existing deck with a user, it is not necessary to perform the process of step S24. In other words, if it is not necessary to associate an existing deck with a user, for example, if it is determined in step S21 that the deck requested to be registered is not a new deck, the transmission control module 2032 notifies the terminal device 10 that the deck already exists.

[0158] (Details on deck registration 2) Other examples of the process of the control unit 203 shown in step S12 of Fig. 17 will be described in detail. In the detailed process 1, it was explained that when the deck requested to be registered is new, the user who requested the registration is linked to the deck information as the creator. In the detailed process 2, a case where there are multiple conditions for being registered as a new deck creator will be described.

[0159] FIG. 22 is a flowchart showing an example of the operation of the server 20 when registering a deck.

[0160] In step S31, the control unit 203 of the server 20 determines whether the deck requested to be registered is a new deck using the management module 2033. If there is no deck with the exact same configuration, the management module 2033 determines that the deck requested to be registered is a new deck, and moves the process to step S32.

[0161] In step S32, the management module 2033 creates a new record in the deck information table 2023 and assigns a deck code to the created record. The management module 2033 stores information about the requested deck in the created record. The management module 2033 stores, for example, the name of the created record and the organization card based on information input by the user. In the flow described in FIG. 22, unlike the flow described in FIG. 19, the management module 2033 does not store information in the items "Creator" and "Creation Date" of the newly created deck record in step S32. The management module 2033 stores information about the user who has requested the deck registration (for example, a user ID) in a predetermined item of the created record. In this way, the management module 2033 is able to store the user who has sent the deck registration request.

[0162] In step S33, the transmission control module 2032 notifies the terminal device 10 that the deck requested to be registered has been registered. Specifically, the transmission control module 2032 transmits to the terminal device 10 that issued the registration request, information that the deck requested to be registered is a deck with a new configuration, that if use of the deck satisfies certain requirements, the user will be associated as the creator of the deck, and the deck code of the registered deck.

[0163] Upon receiving the notification from the server 20, the control unit 190 of the terminal device 10 causes the display control unit 194 to display on the display 141 that the deck is a new composition, and that if certain requirements are met, the deck will be associated with the deck as the deck creator. The control unit 190 also causes the management unit 193 to associate the deck code with the corresponding record in the deck information 183. This makes it possible for the display control unit 194 to display that the stored deck is a deck registered in the server 20, and that if certain requirements are met, the deck will be registered as the creator.

[0164] Fig. 23 is a schematic diagram showing a display example of the display 141. In the example shown in Fig. 23, the display control unit 194 displays a window 14125 for notifying the user that the deck is a new deck and that the user will be associated as the creator if a predetermined requirement is met. A button for inputting that the notification has been confirmed may be displayed in the window 14125.

[0165] If it is determined in step S31 that the deck requested to be registered is not a new deck, the management module 2033 transitions the process to step S24.

[0166] FIG. 24 is a flowchart showing an example of the operation of the server 20 when associating a deck with a creator of the deck.

[0167] In step S41, the management module 2033 determines whether the conditions for use of a new deck are met. Specifically, for example, the management module 2033 refers to the deck information table 2023, and reads out information in the item "battle information" for decks for which records have been created but the creators are not stored. The management module 2033 determines whether the read out information satisfies a predetermined condition for deck use. In other words, the management module 2033 determines whether the predetermined condition is met by the user who requested registration using the deck. In this embodiment, the predetermined condition for deck use is, for example, as follows. The number of matches using the deck has reached a certain number. The number of victories using the deck has reached a certain number. -Registering decks for use in designated tournaments - The number of times you have participated in a specific tournament has reached a certain number. The number of entries for a given tournament has reached a certain number. -Achieving a certain rank in a certain tournament After the deck is published, a user other than the user who requested registration has used the deck to fulfill the above conditions.

[0168] If the read information satisfies a predetermined condition regarding the use of the deck, the management module 2033 shifts the process to step S42.

[0169] In step S42, the management module 2033 updates the deck information table 2023 for the deck that meets the specified usage conditions. Specifically, for example, the management module 2033 stores the user who used the deck, in other words, the user ID of the user who first created the deck, in the "creator" item of the record from which the information in the "battle information" item is read. In other words, the management module 2033 associates the deck that meets the specified usage conditions with the creator of the deck.

[0170] In step S43, the transmission control module 2032 notifies the terminal device 10 that the user has been registered as the creator of the deck. Specifically, the transmission control module 2032 transmits the fact that the user has been registered as the creator of the deck and the deck code of the deck registered as the creator to the terminal device 10 that has issued the deck registration request.

[0171] Upon receiving the notification from the server 20, the control unit 190 of the terminal device 10 causes the display control unit 194 to display on the display 141 that the user has been associated with the registered deck as the creator. The display control unit 194 may display on the display 141 the conditions satisfied for use of the deck. The control unit 190 also causes the management unit 193 to store, in the corresponding record in the deck information 183, that the user has become the creator. This enables the display control unit 194 to display that the stored deck is the first deck created by the user.

[0172] Fig. 25 is a schematic diagram showing a display example of the display 141. In the example shown in Fig. 25, the display control unit 194 displays a window 14126 for notifying the user that the conditions for use have been satisfied and the user has been associated as a creator. There is no restriction on the expression of the present tense or past tense in the window 14126. In the window 14126, a button 141261 for inputting that the notification has been confirmed is displayed. When the user confirms the notification contents, he or she presses the confirmation button 141261.

[0173] When the user presses the confirmation button 141261 on the screen shown in FIG. 25, the display control unit 194 displays, for example, a window for accepting the selection of whether to make the content public to other users.

[0174] In step S41, if the conditions for use of the new deck are not met, the control unit 203 repeats the process of step S41. If the conditions are not met within a preset period, the management module 2033 may delete the record for the new deck.

[0175] (Match information table update process) The control unit 203 of the server 20 uses the management module 2033 to manage information about the decks used in a battle.

[0176] A user constructs a deck by combining cards managed in card information 182. Management unit 193 manages information related to the deck constructed by the user in deck information 183.

[0177] In addition, the user registers the deck that he / she has constructed in the server 20. Specifically, for example, the user registers the deck that he / she has constructed in the server 20 by operating the terminal device 10 as shown in the above "Deck registration".

[0178] FIG. 26 is a diagram illustrating an example of the operation of the terminal device 10 and the server 20 when managing deck battle information.

[0179] When starting a match, the user accesses the server 20 using the terminal device 10. The terminal device 10 displays a registration form for match information set in the server 20 on the display 141. The user uses the form displayed on the display 141 to input information related to the match. The information related to the match is, for example, the date and time when the match will be held, the opponents, information related to the decks to be used in the match, tournament information, etc. After inputting the information related to the match, the user inputs a request to register the match information into the terminal device 10.

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

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

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

[0183] In step S53, the management module 2033 updates the deck information table 2023. Specifically, the management module 2033 stores information about the match, for example, a match ID, in the "match information" item of the record of the deck identified by the deck code. Information about the match in which the deck is used may include information about the tournament in which the deck was participated, information about the results of the tournament in which the deck was participated, etc. As the number of matches increases, the amount of match information stored increases. This makes it possible to know in which match the deck was used.

[0184] The server 20 may transmit information managed in the deck information table 2023 to the terminal device 10. Specifically, for example, when a new battle ID is stored in the item "battle information" of the battle information table 2024, the management module 2033 reads out the newly stored battle ID and the user ID associated with the deck. The transmission control module 2032 transmits the read battle ID to the terminal device 10 owned by the user identified by the user ID.

[0185] The terminal device 10 receives information transmitted from the server 20 and updates the deck information 183 based on the received information. Specifically, for example, the terminal device 10 stores the battle information received from the server 20, for example, a battle ID, in the "battle information" item of the record identified by the deck code, by the management unit 193. This enables the display control unit 194 to display information regarding the use of the deck to the user.

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

[0187] (Benefit granting process) The granting module 2034 grants a reward to the user based on the reward information table 2025 .

[0188] Specifically, for example, the grant module 2034 determines whether or not the information about the deck satisfies the conditions set in the bonus information table 2025. The conditions set in the bonus information table 2025 are, for example, as follows. The degree to which the registered deck has contributed to other users must meet certain conditions. - The degree to which a user has contributed to other users meets certain conditions

[0189] Specifically, for example, the granting module 2034 grants a reward to the user who first created the deck (the user registered as the creator) when the degree to which the registered deck contributed to other users reaches a predetermined value based on the reward information table 2025. The degree to which the deck contributed to other users includes, for example, the number of times other users viewed the deck, the number of times other users referenced the deck, the number of times other users registered the deck, the number of times other users used the deck, etc.

[0190] Furthermore, the granting module 2034 grants a privilege to a user when the degree of contribution of the user to other users reaches a predetermined value based on the privilege information table 2025. The degree of contribution of the user to other users includes, for example, the number of times a user has created a new deck, the number of users followed by other users, and the like.

[0191] Predetermined contents of the benefit are set for each condition in the benefit information table 2025. For example, the contents of the benefit are as follows. · Card provision - Granting the right to create original cards · Granting card lottery rights -Advantageous effects in battle Advantageous effect in card draws

[0192] The server 20 may present the degree to which the registered deck has contributed to other users to the user or other users. Specifically, in response to a request from the user or other users, the transmission control module 2032 transmits information regarding the degree to which the registered deck has contributed to other users to the requesting terminal device 10. Based on the received information, the terminal device 10 displays the degree of contribution on the display 141. This allows the user to understand the degree of contribution until a privilege is granted. Also, other users can recognize how useful the deck is to others.

[0193] Furthermore, the server 20 may present the degree of the user's contribution to other users to the user or other users. Specifically, in response to a request from the user or other users, the transmission control module 2032 transmits information regarding the degree of the user's contribution to other users to the terminal device 10 that originated the request. Based on the received information, the terminal device 10 displays the degree of contribution on the display 141. This allows the user to understand the degree of contribution until a privilege is granted. Also, other users can recognize how effective a deck the user is creating.

[0194] (Display deck information) In response to an instruction from a user, the terminal device 10 displays a list of decks registered in the server 20. The control unit 190 of the terminal device 10 causes the display control unit 194 to display the list of registered decks on the display 141 based on the deck information table 2023.

[0195] Fig. 27 is a schematic diagram showing a display example of the display 141. In Fig. 27, the display control unit 194 displays an area 1411 and an area 1413. The area 1411 is an area in which display conditions and the like are entered. The area 1413 is an area in which registered decks are displayed in a manner conforming to the display conditions entered in the area 1411.

[0196] In the example shown in FIG. 27, a display order is displayed in area 1411 as a display condition. The display order indicates a rule of sequence. The display order is selected by the user from among, for example, number order, name order, rarity order, acquisition date order, etc. The display order can be switched, for example, from number order to name order, rarity order, acquisition date order, etc., based on an instruction from the user. In the example shown in FIG. 27, "display order: name order" is displayed, and the decks are arranged in area 1413 in the order of the deck names.

[0197] When a deck displayed in area 1413 is selected by the user, display control unit 194 displays on display 141 a list of cards that constitute the selected deck.

[0198] As described above, in the above embodiment, the control unit 203 of the server 20 receives a request from the first player through the reception control module 2031 to register a deck created by combining a plurality of digital cards. The control unit 203 determines through the management module 2033 whether the deck requested to be registered satisfies predetermined conditions, including that the deck is the first deck created. If the predetermined conditions are satisfied, the management module 2033 registers the deck in association with the first player who created the deck. The management module 2033 allows the second player to access information about the registered deck, and includes information about the first player who created the deck in the information about the deck. In this way, a deck that satisfies predetermined conditions, including that the deck is the first deck created, is registered together with the creator. This encourages the player to work hard to create a deck so that his or her name is registered together with the deck.

[0199] Therefore, according to the program of this embodiment, it is possible to increase the interest of the player in creating a deck.

[0200] Furthermore, in the above embodiment, the management module 2033 includes, in the predetermined conditions, a condition regarding the use of a deck created for the first time. As a result, a player is not registered simply by creating a deck, but is registered when the created deck is actually used. Therefore, if a deck is created with the sole purpose of having the deck registered, the player is not registered. In other words, information about a deck that can actually be used and is valuable to other players is registered together with the player.

[0201] In the above embodiment, the management module 2033 includes, as conditions for use of a deck created for the first time, at least the number of matches in which the deck has been used, the number of wins in matches in which the deck has been used, the number of times the deck has been entered into a specified battle, or the achievement of a specified ranking by a first player using the deck in a specified battle. This allows a player to be registered together with the deck when practical conditions for use are met.

[0202] In the above embodiment, when a deck created by a specific player is registered, the management module 2033 notifies other players that the deck created by that player has been newly registered. This makes it possible to track decks created by players who are skilled at creating new decks or famous players, and to grasp trends in deck creation.

[0203] In the above embodiment, the granting module 2034 grants a reward to the first player (the creator of the deck) based on the degree to which the registered deck has contributed to the second player (the other players). This can motivate the first player to create a deck that is useful to the other players.

[0204] In the above embodiment, the granting module 2034 grants a reward to the first player (the creator of the deck) based on the degree to which the first player contributed to the second player (the other players). This allows the first player who has created many new decks to receive a reward, which can motivate them to create decks.

[0205] <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 benefit information table 2025 are stored in the server 20. However, the information stored in these tables does not have to be stored in the server 20. For example, at least the deck information stored in the deck information table 2023 may be stored in a blockchain (distributed ledger) formed by a P2P computer network.

[0206] At this time, each of the digital cards is traded on the blockchain as a non-fungible token (NFT). In the above embodiment, the NFT is assigned, for example, a unique identifier (NFT-ID) for identifying the NFT. Each of the decks may be traded on the blockchain as an NFT.

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

[0208] In addition, management of NFT usage is performed, for example, by a smart contract implemented on the blockchain. The history of NFT usage is stored on the blockchain as transactions. This allows the history of NFT usage in battles to be stored on the blockchain.

[0209] In addition, the awarding of rewards for creating a deck is executed, for example, by a smart contract implemented on the blockchain, whereby, when the deck creation history meets certain requirements, a specific reward is awarded to the deck creator.

[0210] In this way, the control unit 203 of the server 20 stores information about the deck in a distributed ledger formed by a computer network through the management module 2033. That is, information about the multiple digital cards that construct the deck and information about the first player are stored in the distributed ledger. Note that the control unit 190 of the terminal device 10 may store information about the deck in a distributed ledger formed by a computer network through the management unit 193. This makes it possible to treat the deck as an NFT. Also, it becomes possible to keep a fair record of the newly created deck.

[0211] In the above embodiment, a case has been described in which the server 20 stores the battle information table 2024. The user's own battle information may be stored in the storage unit 180 of the terminal device 10. The management unit 193 may update the battle information in the deck information 183 based on the battle information stored in the storage unit 180. When the deck information 183 is updated, the transmission / reception unit 192 transmits information related to the deck to the server 20. The management module 2033 of the server 20 updates the deck information table 2023 based on the information transmitted from the terminal device 10. This makes it possible for the terminal device 10 to grasp the battle information.

[0212] In the above embodiment, when a deck is new, information about the deck is stored in the deck information table 2023. However, when only the condition that the deck is new is satisfied, information about the deck may not be stored in the deck information table 2023. For example, the management module 2033 may store information in the deck information table 2023 when the deck is new and satisfies other conditions. In this case, for example, the management module 2033 stores information about a deck determined to be new in a predetermined storage area other than the deck information table 2023, and stores the information in the deck information table 2023 when, for example, a condition related to the use of the deck is satisfied.

[0213] In the above embodiment, the case where the user who first registered the deck is registered as the creator has been described. However, the user who is registered as the creator is not limited to the user who first registered the deck. For example, the management module 2033 may have a wide range of users to be registered as creators. In other words, in addition to the user who first registered the deck, a user who noticed the strength of the deck early on and gained fame in some way may also be registered as a creator. In this way, it is possible to distinguish between a "creator" as a person who has gained fame by himself, and a "registrant" as a person who has benefited from the wisdom of the "creator". Specifically, for example, the management module 2033 registers the first X users who have applied to register the deck as creators. In addition, the management module 2033 may register the top X% of users who have applied to register the deck as creators.

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

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

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

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

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

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

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

[0221] <Basic functional configuration of computer 90> A description will now be given of the functional configuration of a computer realized by the basic hardware configuration of a computer 90 shown in Fig. 28. The computer includes at least the functional units of a control unit, a storage unit, and a communication unit.

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

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

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

[0225] A database refers to a relational database, which is used to manage data sets called tables, which are structured according to rows and columns, by relating them to each other. In a database, a table is called a table, a column in a table is called a column, and a row in a table is called a record. In a relational database, it is possible to set relationships between tables and associate them.

[0226] Usually, a column is set in each table as a key for uniquely identifying a record, but setting a key in the 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.

[0227] 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 the information to the control unit. The control unit can cause the processor 91 to execute information processing on the received information in accordance with various programs. In addition, the communication unit can transmit information output from the control unit to other computers 90.

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

[0229] <Additional Notes> The matters described in the above embodiments will be supplemented below. (Appendix 1) A program to be executed by a computer having a processor and a memory, the program causing the processor to execute the following steps: receiving a request from a first player to register a deck created by combining multiple digital cards; determining whether the deck for which registration request has been received from the first player satisfies certain conditions including being the first deck created; if the certain conditions are satisfied, registering the deck in association with the first player who created the deck for the first time; and making information relating to the registered deck accessible to a second player and including information about the first player who created the deck in the information about the deck. (Appendix 2) In the determining step, the predetermined conditions include conditions regarding the use of a deck created for the first time (Appendix 1), a program described in the above. (Appendix 3) The conditions regarding the use of a deck created for the first time include at least one of the following conditions: the number of matches in which the deck has been used, the number of wins in matches in which the deck has been used, the number of times the deck has been entered into a specified tournament, or the first player using the deck achieving a specified ranking in a specified tournament (Appendix 2). (Appendix 4) A program described in any one of (Appendix 1) to (Appendix 3), in which, in the registration step, information regarding the multiple digital cards to construct the deck and information regarding the first player are stored in a distributed ledger formed by a computer network. (Appendix 5) A program described in any of (Appendix 1) to (Appendix 4), which causes a processor to execute a step of notifying other players that a deck created by a specific player has been newly registered when the deck created by the player is registered. (Appendix 6) A program described in any one of (Appendix 1) to (Appendix 5), which causes a processor to execute a step of granting a reward to a first player based on the degree to which the registered deck has contributed to a second player. (Appendix 7) The program according to any one of (Supplementary Note 1) to (Supplementary Note 6), which causes a processor to execute a step of granting a reward to the first player based on a degree of contribution made by the first player to the second player. (Appendix 8) A method executed by a computer having a processor and a memory, the method comprising the steps of: receiving a request from a first player to register a deck created by combining multiple digital cards; determining whether the deck for which registration request has been received from the first player satisfies certain conditions including being the first deck created; if the certain conditions are satisfied, registering the deck in association with the first player who created the deck for the first time; and making information relating to the registered deck accessible to a second player and including information about the first player who created the deck in the information about the deck. (Appendix 9) An information processing device comprising a control unit and a memory unit, wherein the control unit executes the following steps: receiving a request from a first player to register a deck created by combining multiple digital cards; determining whether the deck for which the registration request has been received from the first player satisfies certain conditions including being the first deck created; if the certain conditions are satisfied, registering the deck in association with the first player who created the deck for the first time; and allowing a second player to access information relating to the registered deck and including information about the first player who created the deck in the information about the deck. (Appendix 10) A system comprising: means for receiving a request from a first player to register a deck created by combining a plurality of digital cards; a step for determining whether the deck for which registration request has been received from the first player satisfies predetermined conditions including being the first deck created; means for registering the deck in association with the first player who created the deck if the predetermined conditions are satisfied; and means for allowing a second player to access information relating to the registered deck and for including information relating to the first player who created the deck in the information relating to the deck. [Explanation of symbols]

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

Claims

1. A program to be executed by a computer having a processor and a memory, the program causing the processor to: receiving a request from a player to register a deck created by combining a plurality of digital cards; registering information about the deck that is the subject of the received request; managing access to information about the registered deck; a step of determining, when a request to register a first deck is received from a first player, whether or not the first deck was created by referring to a second deck created by a second player different from the first player; When the first deck is created by referring to the second deck, updating first information relating to the manner of reference to the second deck among information relating to the second deck; A program that executes the following.

2. the first information includes information regarding the number of players who have referred to the second deck; The program according to claim 1.

3. causing the processor to further execute a step of granting a benefit to the second player when the first information satisfies a predetermined condition; The program according to claim 1 or 2.

4. causing the processor to further perform the step of presenting the first information to the second player or another player; The program according to claim 1 or 2.

5. and causing the processor to further execute a step of registering, when the first deck is created with reference to the second deck, second information relating to the manner of reference to the second deck in information about the first deck. The program according to claim 1.

6. the second information includes information regarding the order in which the first player registered the decks created by referring to the second deck; The program according to claim 5.

7. 1. A computer-implemented method comprising a processor and a memory, the processor: receiving a request from a player to register a deck created by combining a plurality of digital cards; registering information about the deck that is the subject of the received request; managing access to information about the registered deck; a step of determining, when a request to register a first deck is received from a first player, whether or not the first deck was created by referring to a second deck created by a second player different from the first player; When the first deck is created by referring to the second deck, updating first information relating to the manner of reference to the second deck among information relating to the second deck; How to do it.

8. An information processing device including a control unit and a storage unit, wherein the control unit: receiving a request from a player to register a deck created by combining a plurality of digital cards; registering information about the deck that is the subject of the received request; managing access to information about the registered deck; a step of determining, when a request to register a first deck is received from a first player, whether or not the first deck was created by referring to a second deck created by a second player different from the first player; When the first deck is created by referring to the second deck, updating first information relating to the manner of reference to the second deck among information relating to the second deck; An information processing device that executes the above.

9. A means for receiving a request from a player to register a deck created by combining multiple digital cards; a means for registering information about the deck that is the subject of the received request; a means for managing access to information about the registered deck; a means for determining, when a request to register a first deck is received from a first player, whether or not the first deck was created by referencing a second deck created by a second player different from the first player; means for updating, when the first deck is created by referring to the second deck, first information relating to the manner of reference to the second deck among information relating to the second deck; A system comprising:

Images