WO2024090316A1 - プログラム、方法、情報処理装置、システム - Google Patents

プログラム、方法、情報処理装置、システム Download PDF

Info

Publication number
WO2024090316A1
WO2024090316A1 PCT/JP2023/037798 JP2023037798W WO2024090316A1 WO 2024090316 A1 WO2024090316 A1 WO 2024090316A1 JP 2023037798 W JP2023037798 W JP 2023037798W WO 2024090316 A1 WO2024090316 A1 WO 2024090316A1
Authority
WO
WIPO (PCT)
Prior art keywords
deck
player
user
information
created
Prior art date
Application number
PCT/JP2023/037798
Other languages
English (en)
French (fr)
Inventor
圭太 廣部
拓也 橋本
聡希 中村
俊輔 高木
Original Assignee
株式会社ポケモン
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社ポケモン filed Critical 株式会社ポケモン
Publication of WO2024090316A1 publication Critical patent/WO2024090316A1/ja

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
    • A63F13/69—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor by enabling or updating specific game elements, e.g. unlocking hidden features, items, levels or versions
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/798—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85—Providing additional services to players
    • A63F13/87—Communicating with other players during game play, e.g. by e-mail or chat

Definitions

  • This disclosure relates to a program, a method, an information processing device, and a system.
  • Patent document 1 describes how players create decks and register them for each game they use. However, patent document 1 does not mention how the fun of creating decks can be improved.
  • the purpose of this disclosure is to increase the interest of creating decks.
  • the program causes the processor to execute the steps of accepting a request from a first player to register a deck created by combining multiple digital cards, determining whether the deck for which a registration request has been accepted from the first player satisfies certain conditions including that it is the first deck created, and if the certain conditions are met, 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.
  • This disclosure can increase the interest of creating decks.
  • FIG. 1 is a block diagram showing an example of the overall configuration of a system 1.
  • FIG. FIG. 5 is a block diagram illustrating an example of the configuration of the terminal device 10 illustrated in FIG. 4.
  • FIG. 2 is a diagram illustrating an example of a functional configuration of a server 20.
  • FIG. 13 is a diagram showing the data structure of card information 182.
  • FIG. 2 is a diagram showing the data structure of a user information table 2021.
  • FIG. 2 shows the data structure of a card master table 2022.
  • FIG. 13 is a flowchart showing an example of the operation of the server 20 when registering a deck.
  • 3A and 3B are schematic diagrams illustrating examples of displays on a display 141.
  • 3A and 3B are schematic diagrams illustrating examples of displays on a display 141.
  • 13 is a flowchart showing an example of the operation of the server 20 when registering a deck.
  • 3A and 3B are schematic diagrams illustrating examples of displays on a display 141. A figure explaining an example of the operation of the terminal device 10 and the server 20 when managing deck battle information.
  • 3A and 3B are schematic diagrams illustrating examples of displays on a display 141.
  • FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90.
  • ⁇ Summary> if a deck created by a player satisfies certain conditions, including that the deck is 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 a player.
  • 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.
  • 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.
  • the play mat 30 includes, for example, a mat that indicates the positions where cards are placed.
  • the play mat 30 includes, for example, a deck placement area 31A and a deck placement area 31B (hereinafter sometimes collectively referred to as the "deck placement area 31"), a preparation card placement area 32A and a preparation card placement area 32B (hereinafter sometimes collectively referred to as the "preparation card placement area 32"), a win/lose condition card placement area 33A and a win/lose condition card placement area 33B (hereinafter sometimes collectively referred to as the "win/lose condition card placement area 33"), a battle card placement area 34A and a battle card placement area 34B (hereinafter sometimes collectively referred to as the "battle card placement area 34"), and a consumption card placement area 35A and a consumption card placement area 35B (hereinafter sometimes collectively referred to as the "consumption card placement area 35").
  • each user replenishes their hand with cards from the deck while progressing through a card-to-card battle.
  • 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).
  • the deck placement section 31 is an area for placing any of the cards that make up the deck owned by each user as a deck.
  • the deck placement section 31A is an area for user 5A to place cards as a deck.
  • the deck placement section 31B is an area for user 5B to place cards as a deck.
  • each user 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 deck 91A.
  • User 5B places cards in the deck placement section 31B as deck 91B.
  • 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 between cards placed in the preparation card placement section 32 and cards placed in the battle card placement section 34, and makes the cards placed in the battle card placement section 34 fight each other.
  • each user places cards in the preparation card placement unit 32 or the battle card placement unit 34, and the battle card placement unit 34 makes the cards fight each other. While replenishing their hands from the deck, each user places cards to be used in the battle from their hands in the preparation card placement unit 32 or the battle card placement unit 34.
  • User 5A places cards in the preparation card placement unit 32A.
  • User 5B places cards in the preparation card placement unit 32B.
  • the win/lose condition card placement section 33 is an area that indicates the extent to which each player has fulfilled the win conditions. In this embodiment, each player places a predetermined number of cards from the deck face down in the win/lose condition card placement section 33. As shown in FIG. 2, user 5A places cards in the win/lose condition card placement section 33A. User 5B places cards in the win/lose condition card placement section 33B.
  • the battle card placement section 34 is an area for placing cards that will fight against the opponent's cards.
  • User 5A places cards in the battle card placement section 34A.
  • User 5B places cards in the battle card placement section 34B.
  • 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, weak point attributes, and other parameters set for each card.
  • Cards placed in the battle card placement section 34 are given damage according to the attack power, card attributes, weaknesses, etc., and the damage given is deducted from the vitality.
  • 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 consumed card placement section 35.
  • the consumed card placement section 35 is an area for placing cards consumed in a TCG match. For example, cards that have lost stamina 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.
  • Cards placed in the consumed card placement area 35 can be placed in the deck placement area 31, the preparation card placement area 32, the hand, etc. by activating a specified card effect.
  • the play mat 30 may further have an area for placing cards consumed in a match. This area is referred to as the second consumed card placement area, for example. Cards placed in the second consumed card placement area will not be returned to the field even if a specified card effect is activated. Note that a specified effect may be activated depending on the number of cards placed in the second consumed card placement area.
  • Types of cards used in TCG> 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.
  • Character cards include cards that can be placed in the preparation card placement area 32 or the battle card placement area 34 when the user draws a card from the deck and adds it to their hand (also called “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 called “conditional cards”).
  • conditional card can be placed on the condition that an unconditional card related to the conditional card is placed.
  • an unconditional card can be first presented to the opposing user by placing it on the play mat 30, and then a conditional card related to that unconditional card can be placed on the play mat 30.
  • conditional cards are sometimes called “evolved characters” as they have evolved from unconditional cards.
  • unconditional cards are sometimes called “seed characters” as they can be considered the original characters for placing "evolved characters”.
  • a conditional card can be placed in the preparation card placement area 32 or the battle card placement area 34 by consuming a specific card and moving it to the consumption card placement area 35.
  • a conditional card can be placed in the preparation card placement area 32 or the battle card placement area 34 in exchange for one or more character cards that the user has placed on the play mat 30.
  • a conditional card having an evolution level that corresponds to the evolution level value of the character card placed by the user may be placed.
  • a conditional card of evolution level 3 can be placed on top of these character cards (or in exchange for these character cards).
  • a conditional card participate in a battle in exchange for a number of character cards defined by the conditional card.
  • an auxiliary card which is different from the character card and will be described later, may be consumed to have the conditional card participate in the battle.
  • the effect indicated by the auxiliary card may be such that a specific conditional card can be made to participate in a battle in exchange for a specific unconditional card in the battle card placement area 34, the consumed card placement area 35, etc. of the play mat 30.
  • These cards may also include cards that serve multiple purposes among the character cards, action cards, and support cards described below. For example, they may include special cards that can be used as both character cards and support cards. 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.
  • An action card is a card that a user draws from the deck and adds to his/her hand, and then associates it with a character card and places it on the play mat 30, allowing the user to perform a specific action indicated on the character card.
  • the operation of associating an action card with a character card may be performed, for example, during the user's turn.
  • the action card may be associated with a character card by placing the action card near a character card placed on the play mat 30.
  • the number of times that an action card can be associated with a character card during a turn may be limited. For example, once during the user's turn, an action card in the hand may be associated with one of the character cards placed on the play mat 30.
  • a first attack action and a second attack action may be set for a character card.
  • the first attack action may be available when one action card is associated with the character card
  • the second attack action may be available when one action card is not enough and two action cards are associated with the character card.
  • the action power card associated with that character card may be made unusable during that battle.
  • the action power card associated with that character card may be moved to the consumption card placement section 35.
  • 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 per turn. These support cards also include cards that exert their effect when the user declares that they will use the effect of the support card.
  • auxiliary card may be placed face down in advance in a specific position on the play mat 30 (in this embodiment, the specific position is not shown), and the effect of the auxiliary card may be activated when the user declares the use of the auxiliary card by vocalizing or otherwise declaring the use of the auxiliary card.
  • TCG battle rules The play mat 30 and the types of cards used in the TCG battle have been described above. Next, the TCG battle rules will be described in detail.
  • each user attacks or defends (battles) based on the cards placed in battle card placement section 34A and battle card placement section 34B to progress through the TCG battle.
  • the TCG battle progresses as users take turns acting. 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 finishes his action, it becomes the first user's turn.
  • Each user draws a set number of cards from the deck and adds them to their hand each time a turn comes up.
  • Each user places in the preparation card placement section 32 the cards (character cards) in their hand that they will use to attack or defend against the opponent user's cards.
  • User 5A can swap the cards arranged in the preparation card placement area 32A with the cards arranged in the battle card placement area 34A during user 5A's turn.
  • User 5B can also swap the cards arranged in the preparation card placement area 32A with the cards arranged in the battle card placement area 34A during user 5B's turn.
  • the win/lose condition card placement area 33A and the win/lose condition card placement area 33B are areas for notifying each user of the progress each user has made toward the conditions for winning the match.
  • the condition for a user to win a match may be, for example, that all cards placed in the win/lose condition card placement area 33A or the win/lose condition card placement area 33B are collected.
  • the outcome of the match may be decided when all cards have been collected in either the win/lose condition card placement area 33A or the win/lose condition card placement area 33B.
  • each user places a predetermined number of cards from the deck in the win/lose condition card placement section 33. That is, user 5A removes a predetermined number of cards from deck 91A and places them in win/lose condition card placement section 33A.
  • User 5B removes a predetermined number of cards from deck 91B and places them in win/lose condition card placement section 33B.
  • 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.
  • user 5B dismisses cards placed in the battle card placement section 34A by attacking user 5A's character card on 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.
  • winning condition for the match it may also be that a user loses if there is no character card in either the battle card placement section 34 or the preparation card placement section 32. Also, as a winning condition for the match, it may also be that a user loses if he or she is unable to draw a card from the deck placement section 31 on his or her turn.
  • TCG matches are not limited to those 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 placement, etc., via the Internet.
  • a user plays a match while taking pictures of his/her own area on the play mat 30 with a camera or the like.
  • the taken image is sent to the opponent in real time.
  • the user receives an image of the opponent's area sent by 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 real cards. In this way, users may play a TCG match online using analog cards.
  • the user's face can be photographed and the captured image can be sent to the opponent. This makes it possible to check the opponent's facial expressions during the match, providing the same level of satisfaction as a face-to-face match in an online TCG match.
  • 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.
  • 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.
  • FIG. 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 considered as one server.
  • the method of allocating the multiple functions required to realize the server 20 of this embodiment to one or multiple pieces of hardware can be determined appropriately in consideration of the processing capacity of each piece of hardware and/or the specifications required for the server 20.
  • 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, for example, by a mobile terminal such as a smartphone or a tablet.
  • the terminal device 10 may also be realized by a stationary PC (Personal Computer), a laptop PC, or the like, or may be realized by a wearable terminal such as an HMD (Head Mount Display).
  • HMD Head Mount Display
  • the terminal device 10 comprises a communication IF (Interface) 12, an input device 13, an output device 14, a memory 15, storage 16, and a processor 19.
  • the input device 13 is a device (e.g., a touch panel, a touch pad, etc.) for accepting input operations from a user.
  • the output device 14 is a device (a display, a speaker, etc.) for presenting information to the user.
  • the server 20 is, for example, an information processing device that manages information about cards and decks.
  • the server 20 is realized, for example, by a computer connected to the 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 input device for accepting input operations from the user, and as an interface with an output device for presenting information to the user.
  • Each information processing device is configured by a computer equipped with an arithmetic unit and a storage device.
  • the basic hardware configuration of the computer and the basic functional configuration of the computer realized by the hardware configuration will be described later.
  • descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer described later will be omitted.
  • Fig. 5 is a block diagram showing an example of the configuration of the terminal device 10 shown in Fig. 4.
  • the terminal device 10 includes a communication unit 120, an input device 13, an output device 14, an audio processing unit 17, a microphone 171, a speaker 172, a camera 160, a position information sensor 150, a storage unit 180, and a control unit 190.
  • the blocks included in the terminal device 10 are electrically connected to each other, for example, by a bus or the like.
  • the communication unit 120 performs processes such as modulation and demodulation for the terminal device 10 to communicate with other devices.
  • the communication unit 120 performs transmission processing on signals generated by the control unit 190 and transmits them to the outside (e.g., server 20).
  • the communication unit 120 performs reception processing on signals received from the outside and outputs them to the control unit 190.
  • the input device 13 is a device for inputting instructions or information by the user operating the terminal device 10.
  • the input device 13 is realized, for example, by a touch-sensitive device 131 or the like where instructions are input by touching the operation surface.
  • the terminal device 10 is a PC or the like
  • the input device 13 may be realized by a reader, keyboard, mouse, or the like.
  • the input device 13 converts instructions input by the user into electrical signals and outputs the electrical signals to the control unit 190.
  • the input device 13 may also include, for example, a receiving port that receives electrical signals input from an external input device.
  • the output device 14 is a device for presenting information to a user operating the terminal device 10.
  • the output device 14 is realized, for example, by a display 141 or the like.
  • the display 141 displays data according to the control of the control unit 190.
  • the display 141 is realized, for example, by an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display or the like.
  • the audio processing unit 17 performs digital-to-analog conversion processing of the audio signal.
  • the audio processing unit 17 converts the signal provided by 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 by the audio processing unit 17 into audio and outputs the audio to the outside of the terminal device 10.
  • Camera 160 is a device that receives light using a light receiving element and outputs it as a photographic signal.
  • the location information sensor 150 is a sensor that detects the location of the terminal device 10, and is, for example, a GPS (Global Positioning System) module.
  • the GPS module is a receiving device used in a satellite positioning system. In a satellite positioning system, signals are received from at least three or four satellites, and the current location of the terminal device 10 in which the GPS module is installed is detected based on the received signals.
  • the location information sensor 150 may detect the current location of the terminal device 10 from the location of the wireless base station to which the terminal device 10 is connected.
  • the storage unit 180 is realized, for example, by the memory 15 and the storage 16, and stores data and programs used by the terminal device 10.
  • the storage unit 180 stores, for example, user information 181, card information 182, and deck information 183.
  • User information 181 includes, for example, information about a user who plays a TCG.
  • Information about a user includes, for example, a user ID, the user's name, age, address, date of birth, date of registration, information about other users the user follows, etc.
  • Card information 182 includes, for example, information about cards. Card information 182 may also include information about cards owned by the user. Details will be described later.
  • Deck information 183 includes, for example, information about the deck constructed by the user. Details will be described later.
  • the control unit 190 is realized when the processor 19 reads a program stored in the storage unit 180 and executes instructions contained in the program.
  • the control unit 190 controls the operation of the terminal device 10.
  • the control unit 190 fulfills the functions of an operation reception unit 191, a transmission/reception unit 192, a management unit 193, a display control unit 194, and a battle processing unit 195.
  • the operation reception unit 191 performs processing for receiving instructions or information input from the input device 13. Specifically, for example, the operation reception unit 191 receives instructions or information input from the touch-sensitive device 131, etc.
  • the operation reception unit 191 also receives images input from the camera 160. Specifically, for example, the operation reception unit 191 receives image data captured by the camera 160.
  • the operation reception unit 191 also receives audio information input from the microphone 171. Specifically, for example, the operation reception unit 191 receives audio data that is input from the microphone 171 and converted into digital data by the audio processing unit 17.
  • the transmission/reception unit 192 performs processing for the terminal device 10 to transmit and receive data to and from external devices such as the server 20 in accordance with a communication protocol. Specifically, for example, the transmission/reception unit 192 transmits to the server 20 instructions entered by the user or various pieces of acquired information. The transmission/reception unit 192 also receives information provided by the server 20.
  • the information provided by the server 20 includes, for example, information about a new card acquired by the user or information about the deck.
  • the management unit 193 manages the user information 181, card information 182, and deck information 183 stored in the storage unit 180. For example, when information about a user is edited, the management unit 193 stores the edited information in the user information 181. Furthermore, when information about a card is updated, the management unit 193 updates the card information 182. Furthermore, when information about a deck is updated, the management unit 193 updates the deck information 183.
  • the display control unit 194 controls the output device 14 to display a specific image to the user. For example, the display control unit 194 controls the display 141 to display a management screen for cards owned by the user based on the information managed in the card information 182 and the information managed in the deck information 183. The display control unit 194 also controls the display 141 to display information related to the deck.
  • 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 a deck built with digital cards - Play against other players by reading analog cards with a camera - Play in tournaments
  • Fig. 6 is a diagram showing an example of the functional configuration of the server 20.
  • the server 20 fulfills the functions of a communication unit 201, a storage unit 202, and a control unit 203.
  • the communication unit 201 performs processing for the server 20 to communicate with external devices.
  • the memory unit 202 has, for example, a user information table 2021, a card master table 2022, a deck information table 2023, a match information table 2024, and a bonus information table 2025.
  • the user information table 2021 is, for example, a table that stores information about users who have registered for services related to the TCG. Details will be described later.
  • the card master table 2022 is, for example, a table that stores information about cards available to users. Details will be described later.
  • the deck information table 2023 is, for example, a table that stores information about decks registered by users. Details will be described later.
  • the match information table 2024 is, for example, a table that stores information about matches that have been held in the past. Details will be described later.
  • the bonus information table 2025 is a table that stores, for example, information (bonus information) about bonuses to be granted to users. Details will be described later.
  • the control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions contained in the program. By operating according to the program, the control unit 203 fulfills the functions of a reception control module 2031, a transmission control module 2032, a management module 2033, an assignment module 2034, and a battle processing module 2035.
  • the reception control module 2031 controls the process in which the server 20 receives signals from external devices according to a communication protocol.
  • the transmission control module 2032 controls the process in which the server 20 transmits signals to external devices according to a communication protocol.
  • 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, it updates the deck information table 2023 based on the received instruction. In addition, when the management module 2033 receives information related to a battle, it updates the deck information table 2023 and the battle information table 2024 based on the received information.
  • the granting module 2034 grants a privilege to a user.
  • the granting module 2034 refers to the privilege information table 2025 and grants a privilege to a user who meets the conditions.
  • the match processing module 2035 controls the processing of matches between users. For example, the match processing module 2035 controls matches between players using decks constructed with digital cards. The match processing module 2035 also controls matches between players using analog cards read by a camera, for example.
  • ⁇ 2 Data Structure> 7 and 8 are diagrams showing the data structure of information stored in the terminal device 10. Note that Figs. 7 and 8 are merely examples and do not exclude data not shown.
  • FIG. 7 is a diagram showing the data structure of card information 182.
  • Card information 182 shown in FIG. 7 is a table with a card ID as a key and columns of name, type, attributes, card information, image data, number of cards, etc.
  • card information 182 may also include a card management ID for uniquely identifying cards, even if the cards are identical, information regarding regulations, or rarity, etc.
  • the card ID is an item that stores an identifier for uniquely identifying the type of card.
  • the same card ID is assigned to identical cards. Even if the 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.
  • An attribute is an item that stores the nature to which a character belongs.
  • attributes include, for example, fire, water, lightning, grass, super, steel, evil, fighting, etc.
  • Card information is an item that stores information that explains the contents of the card. If the card type is character, the card information includes, for example, the character's attack power, stamina, the amount of energy required to perform a technique, the amount of energy required to escape, weaknesses, resistance, special properties possessed by the character, etc. If the card type is support, goods, or stadium, the card information includes, for example, the requirements for using the card, effects that occur when the card is used, etc.
  • Image data is an item that stores an image.
  • Image data may also store reference information (path) for an image data file located elsewhere.
  • Quantity 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.
  • FIG. 8 is a diagram showing the data structure of deck information 183.
  • Deck information 183 shown in FIG. 8 is a table having columns such as name, organized cards, completion, update date, and registration information, with the deck ID as a key.
  • deck information 183 may also have information on the nickname of the deck, the deck's usage history, and a representative image.
  • the nickname of the deck is, for example, a name given based on the characteristic cards used in the deck, which succinctly expresses the characteristics of the deck and is given based on a common understanding among multiple users.
  • the representative image is, for example, an image of a card specified by a user from among the cards organized in the deck.
  • the representative image is, for example, an image related to an illustration from the description on the card, excluding text.
  • the representative image is, for example, an image reduced to a predetermined number of pixels, such as a thumbnail image.
  • Deck ID is an item that stores an identifier for uniquely identifying a deck.
  • Name is an item that stores the name of the deck. For example, the name may be generated based on some of the cards that make up the deck, or may be given by the user.
  • 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.
  • Complete is an item that stores whether or not the deck is complete.
  • a circle indicates that the deck is complete, and a cross indicates that the deck is not complete.
  • a completed deck means, for example, that the deck has been assembled with a prescribed number of cards and is ready for use in a match.
  • Update date is an item that stores the date on which the deck configuration was changed. In calculating the update date, using 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.
  • FIGS. 9 to 13 are diagrams showing the data structure of the information stored in the server 20. Note that FIGS. 9 to 13 are merely examples and do not exclude data that is not listed.
  • FIG. 9 is a diagram showing the data structure of the 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 the user ID as a key.
  • the user information table 2021 is not limited to the above, and may also have columns such as proficiency level.
  • User ID is an item that stores an identifier for uniquely identifying a user.
  • Name is an item that stores the user's name.
  • Age is an item that stores the user's age.
  • Address is an item that stores the place where the user lives.
  • Date of birth is an item that stores the date the user was born.
  • Date of registration is an item that stores the date the user began using a service related to the TCG. Following is an item that stores information about other users the user follows. Following stores, for example, the user IDs of other users the user follows.
  • Records in the user information table 2021 are added when a new user is registered.
  • 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, attributes, card information, and image data, with the card ID as a key.
  • Card ID is an item that stores an identifier for uniquely identifying the type of card.
  • Name is an item that stores the name of the card.
  • Type is an item that stores the type of card.
  • Attributes is an item that stores the nature to which the character belongs.
  • Card Information is an item that stores information that explains the contents of the card.
  • Image Data is an item that stores an image.
  • Records in the card master table 2022 are added, for example, when a new card is issued.
  • the deck information table 2023 shown in FIG. 11 is a table having columns such as name, creator, creation date, organization cards, battle information, and publication, with the deck code as a key.
  • the deck information table 2023 may also 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, the date on which the use of the deck fulfilled a specified condition, and the like.
  • 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 one.
  • information that can distinguish between registrants may be included. For example, a number that can identify the order of registration may be included. In other words, if the creator is assigned a "1", the first registrant is assigned a "2". If the first registrant is assigned a "1", the next registrant may be assigned a "2". In this way, the user can understand the order in which the deck was started to be used, and can be aware that they were ahead of the trend, for example.
  • the number of views may, for example, be the number of users who have checked the contents of the deck. If the server 20 provides a function for copying deck configurations, the number of users who have copied the deck may be stored as the number of references.
  • 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 refers, for example, to a deck in which at least a part of the deck is different from existing decks. In other words, a new deck can refer to a deck for 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.
  • 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 ⁇ Match date and time ⁇ Tournaments participated in ⁇ Tournament results
  • Public is an item that stores whether or not a deck is publicly available to other users.
  • 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.
  • a deck that is not publicly available means that only the user can view it.
  • 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 that uses a match ID as a key and has columns such as date and time, opponent, deck code, winner, match log information, and tournament information.
  • the match ID is an item that stores an identifier for uniquely identifying a match.
  • a match ID is issued by the management module 2033 when new information about a match is registered.
  • the date and time is an item that stores the date and time when the match took place.
  • the opponents is an item that stores information about the players who played the match. In this embodiment, for example, the user IDs of the players who played the match are stored in the opponents.
  • the deck code is an item that stores a code that identifies the deck used in a match.
  • a player who 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.
  • the item "deck code” may store information that represents the deck, which is determined from the contents of the cards included in the deck.
  • 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".
  • 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".
  • Match log information is an item that stores the moves adopted by players during a match. Specifically, for example, the match log information stores when a player draws a card from a designated placement area (such as the deck or win/lose condition cards), when a player places a card in a designated placement area, when a player uses the effect of a designated card, etc.
  • the moves adopted by players during a match may be referred to as deck rotation during a match.
  • Tournament information is an item that stores information about a match. For example, tournament information includes the name of the tournament in which the match was held, and the number of rounds in the match in the tournament.
  • the tournament information may include match information in privately held tournaments, regardless of whether the tournament was officially held.
  • tournament information is not limited to tournaments, and may include match information in private matches.
  • FIG. 13 is a diagram showing the data structure of the bonus information table 2025.
  • the bonus information table 2025 shown in FIG. 13 is a table that uses the bonus ID as a key and has columns for bonus content, conditions, etc.
  • the "Benefit ID” is an item that stores an identifier for uniquely identifying a benefit.
  • the "Benefit content” is an item that stores the content of the benefit.
  • the “Condition” is an item that stores the conditions under which the benefit is granted.
  • a user operates the terminal device 10 to edit cards and build a deck made up of a plurality of digital cards.
  • the user inputs an instruction to the terminal device 10 to display a list of cards that the user owns.
  • the user executes an app related to a digital TCG that is installed on the terminal device 10.
  • the user inputs an instruction to the terminal device 10 to display the cards that the user owns.
  • the control unit 190 of the terminal device 10 uses the display control unit 194 to display a list of cards on the display 141 based on the card information 182 and deck information 183.
  • 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 in a card list display for inputting an instruction to display a list of decks.
  • the display control unit 194 displays a list of decks on the display 141 based on the deck information 183.
  • the user may also launch an app related to a digital TCG installed on the terminal device 10, and input an instruction to the terminal device 10 to edit the deck in the launched app.
  • FIG. 14 is a schematic diagram showing an example of a deck list displayed on the terminal device 10.
  • the display control unit 194 displays an area 1411 and an area 1412.
  • Area 1412 is an area that displays decks owned by the user in a format conforming to the display conditions described in area 1411.
  • the display order is displayed as a display condition in area 1411.
  • the display order indicates the rules for the sequence.
  • the display order is selected by the user from among, for example, number order, name order, update date order, etc.
  • "Display order: name order” is selected, and the decks are arranged in area 1412 in the order of their names.
  • a search window 14111 is displayed in area 1411.
  • the user inputs keywords or the like into search window 14111 to search for the desired deck.
  • the display control unit 194 displays on the display 141 the operations that can be performed on the deck selected by the user.
  • FIG. 15 is a schematic diagram showing an example of the display on the display 141.
  • the display control unit 194 displays a window 14121 in which processes for the deck are displayed in a list format so that they can be selected.
  • the display control unit 194 displays, in the window 14121, for example, edit, register, etc. as processes for the deck.
  • the user selects the process for the deck by operating the input device 13.
  • the user for example, 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.
  • 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.
  • the display control unit 194 displays areas 1411, 1413, and 1414.
  • Area 1413 is an area that displays cards constituting the deck in a manner conforming to the display conditions described in area 1411.
  • Area 1414 is an area that displays a list of cards owned by the user in a manner conforming to the display conditions described in area 1411.
  • cards are displayed that can be replaced with cards displayed in area 1413.
  • the cards displayed in area 1413 may be displayed in a manner that allows them to be distinguished from the cards displayed in area 1414. In the example shown in FIG. 16, the cards displayed in area 1413 are displayed larger than the cards displayed in area 1414.
  • the display order is displayed in area 1411 as a display condition.
  • the display order indicates the rules for the order.
  • the display order is selected by the user from among, for example, number order, name order, rarity order, acquisition date order, etc.
  • "display order: number order” is selected, and the cards are arranged in areas 1413 and 1414 in the order of their card IDs.
  • the user operates the terminal device 10 to register the deck that he or she has constructed.
  • 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.
  • the user operates the terminal device 10 to select a desired deck and inputs an instruction to register the selected deck. Specifically, for example, the user selects "Register" in window 14121 shown in FIG. 15.
  • the display control unit 194 of the terminal device 10 displays a screen for confirming that the deck is to be registered.
  • FIG. 18 is a schematic diagram showing an example of the display of the display 141.
  • 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. 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.
  • step S11 the terminal device 10 accepts a deck registration request input by the user through the operation acceptance unit 191.
  • the terminal device 10 transmits the accepted registration request to the server 20 through the transmission/reception unit 192.
  • step S12 the server 20 registers a deck based on a deck registration request from the user. Specifically, for example, the control unit 203 of the server 20 creates, via the management module 2033, a record of the new deck configuration from among the decks for which registration has been requested, in the deck information table 2023.
  • the management module 2033 associates the newly organized deck with the creator of that deck. Specifically, for example, the management module 2033 stores the user ID of the creator of the deck in the "Creator" field of the newly created record.
  • 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 "Registered by" field of the record for the existing deck for which registration is requested.
  • the management module 2033 sets the scope of visibility of the registered deck. Specifically, the management module 2033, for example, asks the user who registered the deck whether or not to make the registered deck visible 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.
  • 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.
  • the user information table 2021 registers other users that a user follows.
  • the management module 2033 may notify users who follow that user that a new deck has been registered by that user. There are users who are skilled at building new decks. By following such users, other users can keep track of current deck trends.
  • FIG. 19 is a flowchart showing an example of the operation of the server 20 when registering a deck.
  • step S21 the control unit 203 of the server 20 uses the management module 2033 to determine whether the deck requested to be registered is a new deck. Specifically, the management module 2033 determines whether at least some of the cards forming the deck are different from cards forming an existing deck. The management module 2033 may determine whether a deck with the exact same configuration exists, or may determine whether a deck exists whose configuration matches a certain condition. The following describes an example where 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 transitions to 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 requested deck registration. That is, the management module 2033 stores the user ID of the user who requested deck registration in the "Creator" field of the record, and stores the date on which it was determined that the record was new in the "Date of Creation" field.
  • 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, along with the deck code of the registered deck, to the terminal device 10 that originated the registration request.
  • 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 also 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 on the server 20.
  • FIG. 20 is a schematic diagram showing an example of the display on the display 141.
  • the display control unit 194 displays a window 14123 for notifying the user 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 contents of the notification, he or she presses the confirmation button 141231.
  • step S13 of FIG. 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.
  • the display control unit 194 displays an image on the display 141 for accepting the selection as to whether or not to make the registered deck public to other users.
  • FIG. 21 is a schematic diagram showing an example of the display of the display 141.
  • the display control unit 194 displays a window 14124 for accepting the selection of whether to make the deck available to other users.
  • buttons 141241 and 141242 for inputting the user's intention are displayed. If the user wishes to make the deck available to other users, the user presses the Yes button 141241.
  • the transmission/reception unit 192 transmits an instruction regarding the release of the deck to the server 20.
  • the server 20 uses the management module 2033 to store information regarding the public in the "Public" item of the deck information table 2023.
  • the server 20 uses the management module 2033 to store information regarding the public in the "Public" item of the deck information table 2023.
  • the management module 2033 stores information regarding the public in the "Public" item of the deck information table 2023.
  • a check mark is stored in the "Public” item
  • other users can also check the composition and creator of the deck.
  • a cross is stored in the "Public” item, only the creator user can check the composition and creator of the deck.
  • step S21 If in step S21 the deck requested to be registered is not a new deck, the management module 2033 transitions the process to step S24.
  • the management module 2033 associates the user who requested the registration with an existing deck. Specifically, for example, the management module 2033 references the deck information table 2023 and acquires a deck that is identical to 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.
  • 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 originated the registration request information that an identical deck already exists, along with the deck code of the existing deck. The transmission control module 2032 may also transmit the user ID of the user who created the existing deck to the terminal device 10 that originated the request. This increases the presence of the user who created the deck, which may motivate them to create a deck first.
  • 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.
  • step S24 is not essential. If there is no need to associate an existing deck with a user, the process of step S24 does not need to be performed. In other words, if there is no need 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.
  • FIG. 22 is a flowchart showing an example of the operation of the server 20 when registering a deck.
  • step S31 the control unit 203 of the server 20 uses the management module 2033 to determine whether the deck requested to be registered is a new deck. If a deck with the exact same configuration does not exist, the management module 2033 determines that the deck requested to be registered is a new deck and transitions to 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.
  • 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 deck registration (for example, user ID) in a specified 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.
  • 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 originated 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 with the deck's creator, and the deck code of the registered deck.
  • 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 user will be associated with the deck as the deck's 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 enables the display control unit 194 to display that the stored deck is a deck registered with the server 20, and that if certain requirements are met, the user will be registered as the creator.
  • FIG. 23 is a schematic diagram showing an example of the display on the display 141.
  • the display control unit 194 displays a window 14125 to notify the user that the deck is a new deck and that the user will be associated as the creator if certain requirements are met.
  • a button for inputting that the notification has been acknowledged may be displayed in the window 14125.
  • step S31 If in step S31 the deck requested to be registered is not a new deck, the management module 2033 transitions the process to step S24.
  • FIG. 24 is a flowchart showing an example of the operation of the server 20 when associating a deck with a deck creator.
  • the management module 2033 determines whether the conditions for use of a new deck are met. Specifically, for example, the management module 2033 references the deck information table 2023, and reads out information in the item "battle information" for decks for which records have been created but the creator is not stored. The management module 2033 determines whether the read out information meets the predetermined conditions for deck use. In other words, the management module 2033 determines whether the predetermined conditions are met by the user who requested registration using the deck. In this embodiment, the predetermined conditions for deck use are, for example, as follows: - The deck has been used in a certain number of matches. - The deck has won a certain number of matches. - The deck has been registered for use in a certain tournament.
  • the deck has participated in a certain number of tournaments.
  • the deck has been entered into a certain number of tournaments.
  • the deck has been ranked in a certain tournament.
  • the management module 2033 transitions the process to step S42.
  • step S42 the management module 2033 updates the deck information table 2023 for the deck that meets the specified conditions of use. Specifically, for example, the management module 2033 stores the user ID of the user who used the deck - in other words, the user who originally created the deck - in the "Creator" field of the record from which the information in the "Battle Information” field was read. In other words, the management module 2033 associates the deck that meets the specified conditions of use with the creator of the deck.
  • 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 that the user has been registered as the creator to the terminal device 10 that originated the deck registration request.
  • 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 also display on the display 141 the conditions met for using 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.
  • FIG. 25 is a schematic diagram showing an example of the display on the display 141.
  • the display control unit 194 displays a window 14126 for notifying the user that the conditions for use have been met and that the user has been associated as a creator. There are no restrictions on the expression of the present tense or past tense in the window 14126.
  • the window 14126 displays a button 141261 for inputting that the notification has been confirmed. When the user has confirmed the contents of the notification, he or she presses the confirmation button 141261.
  • the display control unit 194 displays, for example, a window to accept the selection of whether to make the content public to other users.
  • step S41 If the conditions for use of the new deck are not met in step S41, the control unit 203 repeats the process of step S41.
  • the management module 2033 may delete the record for the new deck if the conditions are not met within a preset period of time.
  • the control unit 203 of the server 20 manages information about decks used in battles using the management module 2033.
  • the user builds a deck by combining cards managed in card information 182.
  • the management unit 193 manages information related to the decks built by the user in deck information 183.
  • 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 "Registering a deck" above.
  • 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.
  • the user uses the terminal device 10 to access the server 20.
  • the terminal device 10 displays a match information registration form set in the server 20 on the display 141.
  • the user uses the form displayed on the display 141 to input information about the match.
  • Information about the match includes, for example, the date and time the match will be held, the opponents, information about the decks to be used in the match, tournament information, etc.
  • the user After inputting the information about the match, the user inputs a request to register the match information into the terminal device 10.
  • step S51 the terminal device 10 accepts a registration request for match information input by the user via the operation reception unit 191.
  • the terminal device 10 transmits the input match information and the registration request to the server 20 via the transmission/reception unit 192.
  • the server 20 updates the match information table 2024 based on the match information input by the user. Specifically, for example, when the management module 2033 receives a request from the user to register match information, it issues a match ID and creates a record in the match information table 2024 with the issued match ID as a key. The management module 2033 stores the date and time, opponent, deck code, and tournament information of the created record based on the information input by the user.
  • the date, time, opponents, and tournament information may be entered in advance by the tournament organizer.
  • 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.
  • the management module 2033 updates the deck information table 2023. Specifically, the management module 2033 stores information about the match, such as 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 participated in, information about the results of the tournament participated in, etc. The more matches there are, the more information is stored. This makes it possible to know in which match the deck was used.
  • 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 "Battle Information" item 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.
  • the terminal device 10 receives information sent from the server 20 and updates the deck information 183 based on the received information. Specifically, for example, the terminal device 10 causes the management unit 193 to store the battle information received from the server 20, for example, a battle ID, in the "battle information" item of the record identified by the deck code. This enables the display control unit 194 to display information about the use of the deck to the user.
  • the control unit 203 controls the match processing between players using the match processing module 2035.
  • the match processing module 2035 stores information about the moves used by the players during the match in the memory unit 202.
  • the management module 2033 stores information about the moves used by the players during the match in the match information table 2024 as match log information.
  • the match processing module 2035 recognizes the player who won the match as the winner.
  • the management module 2033 stores the winner in the match information table 2024.
  • the granting module 2034 grants a privilege to the user based on the privilege information table 2025 .
  • the grant module 2034 determines whether or not the information regarding 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 meets certain conditions. ⁇ The degree to which the user has contributed to other users meets certain conditions.
  • the granting module 2034 grants a bonus to the user who first created the deck (the user registered as the creator) when the degree to which the registered deck has contributed to other users reaches a predetermined value based on the bonus information table 2025.
  • the degree to which a deck has contributed to other users includes, for example, the number of times the deck has been viewed by other users, the number of times the deck has been referenced by other users, the number of times the deck has been registered by other users, the number of times the deck has been used by other users, etc.
  • the granting module 2034 also grants a privilege to a user when the degree of the user's contribution to other users reaches a predetermined value based on the privilege information table 2025.
  • the degree of the user's contribution to other users includes, for example, the number of times a user has created a new deck, the number of other users following the user, etc.
  • a specific benefit is set for each condition.
  • the benefit is as follows: ⁇ Provision of cards ⁇ Granting the right to create original cards ⁇ Granting the right to enter a card lottery ⁇ Advantageous effects in matches ⁇ Advantageous effects in card lotteries
  • the server 20 may present the degree to which a 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 a 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 made up until the point at which a benefit is granted. Also, other users can recognize how useful the deck is to others.
  • the server 20 may also present the degree to which the user 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 user has contributed to other users to the terminal device 10 that made 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 made up to the point at which a benefit is granted. Also, other users can recognize how effective a user's decks are.
  • the terminal device 10 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.
  • FIG. 27 is a schematic diagram showing an example of the display of display 141.
  • display control unit 194 displays area 1411 and area 1413.
  • Area 1411 is an area in which display conditions, etc. are entered.
  • Area 1413 is an area in which registered decks are displayed in a manner conforming to the display conditions entered in area 1411.
  • the display order is displayed in area 1411 as a display condition.
  • the display order indicates the rules for the 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 instructions from the user.
  • "Display order: Name order” is displayed, and the decks are arranged in area 1413 in the order of the deck names.
  • the display control unit 194 displays a list of cards that make up the selected deck on the display 141.
  • the control unit 203 of the server 20 receives a request from the first player via the reception control module 2031 to register a deck created by combining multiple digital cards.
  • the control unit 203 determines via the management module 2033 whether the deck requested to be registered satisfies certain conditions, including that it is the first deck created. If the certain conditions are met, 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 deck information. In this way, decks that meet certain conditions, including that it is the first deck created, are registered together with their creator. This encourages players to work hard to create decks so that their own names are registered together with the decks.
  • the program according to this embodiment can increase the interest of players in creating decks.
  • the management module 2033 includes in the predetermined conditions a condition regarding the use of a deck created for the first time.
  • a player is not registered simply by creating a deck, but is registered when the created deck is actually used. For this reason, if a deck is created with the sole purpose of having it registered, the player is not registered. In other words, information about a deck that can actually be used and that is valuable to other players is registered along with the player.
  • the management module 2033 includes in the conditions for using 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 tournament, or the first player using the deck achieving a specified ranking in a specified tournament. This allows a player to be registered along with the deck when practical conditions for use are met.
  • the management module 2033 when a deck created by a specific player is registered, notifies other players that a 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 by famous players, and to grasp trends in deck creation.
  • 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 other players.
  • the granting module 2034 grants a reward to the first player (the deck creator) based on the degree to which the first player contributed to the second player (the other players). This allows a first player who has created many new decks to receive a reward, which can motivate them to create decks.
  • 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.
  • the information stored in these tables does not have to be stored in the server 20.
  • 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.
  • each digital card is traded on the blockchain as a non-fungible token (NFT).
  • NFT non-fungible token
  • the NFT is assigned, for example, a unique identifier (NFT-ID) for identifying the NFT.
  • NFT-ID unique identifier
  • each deck may also be traded on the blockchain as an NFT.
  • 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.
  • NFT usage is carried out, for example, by a smart contract implemented on the blockchain.
  • the history of NFT usage is stored on the blockchain as transactions. This allows the history of NFT use in matches to be stored on the blockchain.
  • the granting of rewards for creating a deck can be done, for example, by a smart contract implemented on the blockchain. As a result, if the history of deck creation meets certain requirements, the deck creator will be granted a certain reward.
  • control unit 203 of the server 20 uses the management module 2033 to store information about the deck in a distributed ledger formed by a computer network.
  • information about the multiple digital cards that make up the deck and information about the first player are stored in the distributed ledger.
  • control unit 190 of the terminal device 10 may also use the management unit 193 to store information about the deck in a distributed ledger formed by a computer network. This makes it possible to treat the deck as an NFT. It also makes it possible to keep a transparent record of newly created decks.
  • the server 20 stores the match information table 2024.
  • the user's own match information may be stored in the storage unit 180 of the terminal device 10.
  • the management unit 193 may update the match information in the deck information 183 based on the match information stored in the storage unit 180.
  • 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 match information.
  • the management module 2033 may store information in the deck information table 2023 if the deck is new and meets other conditions. In this case, for example, the management module 2033 stores information about a deck that is determined to be new in a specified storage area other than the deck information table 2023, and stores the information in the deck information table 2023 if, for example, conditions related to the use of the deck are met.
  • the management module 2033 may have a wider range of users to register as creators.
  • users who noticed the strength of the deck early on and gained fame in some way may also be registered as creators. In this way, it is possible to distinguish between a "creator” as someone who has gained fame on his or her own, and a "registrant" as someone who has benefited from the wisdom of the "creator.”
  • the management module 2033 registers the first X users who have applied to register a deck as creators.
  • the management module 2033 may register the top X% of users who have applied to register a deck as creators.
  • 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.
  • the processor 91 is hardware for executing a set of instructions written in a program.
  • the processor 91 is composed of an arithmetic unit, registers, peripheral circuits, etc.
  • the main memory device 92 is used to temporarily store programs and data processed by the programs.
  • it is a volatile memory such as a DRAM (Dynamic Random Access Memory).
  • the auxiliary storage device 93 is a storage device for saving data and programs.
  • it is a flash memory, HDD (Hard Disc Drive), optical magnetic disk, CD-ROM, DVD-ROM, semiconductor memory, etc.
  • the communication IF 99 is an interface for inputting and outputting signals for communicating with other computers over a network using wired or wireless communication standards.
  • Networks are composed of the Internet, LANs, various mobile communication systems constructed using wireless base stations, etc.
  • networks include 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), wireless networks that can connect to the Internet via designated access points (e.g., Wi-Fi (registered trademark)), etc.
  • communication protocols include, for example, Z-Wave (registered trademark), ZigBee (registered trademark), Bluetooth (registered trademark), etc.
  • networks also include those that are directly connected using USB (Universal Serial Bus) cables, etc.
  • computers 90 can be virtually realized by distributing all or part of each hardware configuration across multiple computers 90 and connecting them together via a network.
  • the concept of computer 90 includes not only a computer 90 housed in a single housing or case, but also a virtualized computer system.
  • the computer includes at least the functional units of a control unit, a storage unit, and a communication unit.
  • the functional units of the computer 90 can also be realized by distributing all or part of each functional unit across multiple computers 90 that are connected to each other via a network.
  • the concept of computer 90 includes not only a single computer 90 but also a virtualized computer system.
  • the control unit is realized by the processor 91 reading out various programs stored in the auxiliary storage device 93, expanding them in the main storage device 92, and executing processing in accordance with the programs.
  • the control unit can realize functional units that perform various information processing depending on the type of program.
  • the computer is realized as an information processing device that performs information processing.
  • the storage unit is realized by a main storage device 92 and an auxiliary storage device 93.
  • the storage unit stores data, various programs, and various databases.
  • 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.
  • the control unit can cause the processor 91 to execute processes for adding, updating, and deleting data stored in the storage unit in accordance with the various programs.
  • database refers to a relational database, which is used to manage sets of data called tables, which are structured in a tabular format defined by rows and columns, by relating them to each other.
  • a table is called a table
  • a column in a table is called a column
  • a row in a table is called a record.
  • each table has a column set as a key for uniquely identifying a record, but setting a key to a column is not essential.
  • the control unit can cause the processor 91 to add, delete, or update records in a specific table stored in the memory unit according to various programs.
  • the communication unit is realized by the communication IF 99.
  • the communication unit realizes the function of communicating with other computers 90 via a network.
  • the communication unit can receive information sent from other computers 90 and input it to the control unit.
  • the control unit can cause the processor 91 to execute information processing on the received information in accordance with various programs.
  • the communication unit can transmit information output from the control unit to other computers 90.
  • 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: accepting 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 accepted 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) A program described in Appendix 1, in which in the determining step, the specified conditions include conditions regarding the use of a deck created for the first time.
  • 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 of (Appendix 1) to (Appendix 5), which causes a processor to execute a step of granting a benefit to a first player based on the degree to which the registered deck has contributed to a 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 a plurality of digital cards; determining whether the deck for which registration request has been received from the first player satisfies predetermined conditions including being the first deck created; if the predetermined 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.
  • 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 a plurality of 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させる。

Description

プログラム、方法、情報処理装置、システム
　本開示は、プログラム、方法、情報処理装置、システムに関する。
　近年、デジタルカードを用いてプレイするデジタルＴＣＧ（Trading Card Game）が注目されている。
特開２０１３－０３４６２４号公報
　デジタルＴＣＧでは、他プレイヤ又はＣＰＵと対戦するために、所有する複数のデジタルカードを組み合わせてデッキを構築する。強いデッキ、個性的なデッキ等、デッキを構築することは、ＴＣＧの楽しみの一つである。
　特許文献１では、プレイヤがデッキを作成し、作成したデッキを、使用するゲーム毎に登録することは記載されている。しかしながら、特許文献１では、デッキを作成する興趣性を向上させることについては述べられていない。
　本開示の目的は、デッキを作成する興趣性を向上させることである。
　プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させる。
　本開示によれば、デッキを作成する興趣性を向上させることができる。
本実施形態に係るＴＣＧの対戦を準備する局面を示す図である。 本実施形態に係るＴＣＧの対戦を開始しようとする局面を示す図である。 各ユーザがＴＣＧの対戦を進行させている局面を示す図である。 システム１の全体構成の例を示すブロック図である。 図４に示す端末装置１０の構成例を表すブロック図である。 サーバ２０の機能的な構成の例を示す図である。 カード情報１８２のデータ構造を示す図である。 デッキ情報１８３のデータ構造を示す図である。 ユーザ情報テーブル２０２１のデータ構造を示す図である。 カードマスタテーブル２０２２のデータ構造を示す図である。 デッキ情報テーブル２０２３のデータ構造を示す図である。 対戦情報テーブル２０２４のデータ構造を示す図である。 特典情報テーブル２０２５のデータ構造を示す図である。 端末装置１０に表示されるデッキ一覧の例を表す模式図である。 ディスプレイ１４１の表示例を表す模式図である。 端末装置１０に表示される、デッキ２の編集画面の例を表す模式図である。 ユーザがデッキを登録する際の端末装置１０とサーバ２０との動作の例を説明する図である。 ディスプレイ１４１の表示例を表す模式図である。 デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 ディスプレイ１４１の表示例を表す模式図である。 デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 デッキと、デッキの作成者とを対応付ける際のサーバ２０の動作の例を示すフローチャートである。 ディスプレイ１４１の表示例を表す模式図である。 デッキの対戦情報を管理する際の端末装置１０とサーバ２０との動作の例を説明する図である。 ディスプレイ１４１の表示例を表す模式図である。 コンピュータ９０の基本的なハードウェア構成を示すブロック図である。
　以下、図面を参照しつつ、本開示の実施形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称及び機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
　＜概略＞
　本実施形態に係るプログラムは、プレイヤが作成したデッキが、初めて作成されたデッキであることを含む所定の条件を満たす場合、当該デッキを、当該デッキを初めて作成した第１プレイヤと関連付けて登録する。登録したデッキに関する情報は、第１プレイヤに関する情報を含み、第１プレイヤ、又は第１プレイヤ及びプレイヤからのアクセスにより公開される。
　まず、本実施形態に係るＴＣＧの概要について説明する。次いで、カードの管理システムについて説明する。
　＜０　ＴＣＧの概要＞
　図１は、本実施形態に係るＴＣＧの対戦を準備する局面を示す図である。図２は、本実施形態に係るＴＣＧの対戦を開始しようとする局面を示す図である。図３は、各ユーザがＴＣＧの対戦を進行させている局面を示す図である。
　ユーザは、プレイマット３０を配置し、ＴＣＧの対戦に使用するカードを組み合わせて構築したデッキを用い、ＴＣＧの対戦を行う。
　＜０．１　プレイマット３０の構成＞
　図１を参照して、各ユーザがＴＣＧの対戦で使用する各種用品について説明する。図１に示すように、ユーザ５Ａ（第１ユーザ）と、ユーザ５Ｂ（第２ユーザ）とが、ＴＣＧの対戦を開始するにあたり、ユーザ５Ａとユーザ５Ｂとの間にプレイマット３０を配置する。プレイマット３０は、デッキに含まれるカードを配置するためのものである。各ユーザは、プレイマット３０に山札等としてカードを配置し、山札からカードを手札に加えつつＴＣＧの対戦を進行させる。
　プレイマット３０の構成について説明する。プレイマット３０は、例えば、カードを配置する位置が表されるマットを含む。プレイマット３０は、例えば、山札配置部３１Ａ及び山札配置部３１Ｂ（以下、「山札配置部３１」と総称することもある）と、準備カード配置部３２Ａ及び準備カード配置部３２Ｂ（以下、「準備カード配置部３２」と総称することもある）と、勝敗条件カード配置部３３Ａ及び勝敗条件カード配置部３３Ｂ（以下、「勝敗条件カード配置部３３」と総称することもある）と、バトルカード配置部３４Ａ及びバトルカード配置部３４Ｂ（以下、「バトルカード配置部３４」と総称することもある）と、消費カード配置部３５Ａ及び消費カード配置部３５Ｂ（以下、「消費カード配置部３５」と総称することもある）と、を含む。
　図３示すように、ＴＣＧの対戦において、各ユーザは、山札からカードを手札に補充しつつ、カード同士のバトルを進行させる。図３の例では、ユーザ５Ａは、手札９３Ａ（図３の例では手札に２枚のカード）を有している。ユーザ５Ｂは、手札９３Ｂ（図３の例では手札に３枚のカード）を有している。
　山札配置部３１は、各ユーザが所有するデッキを構成するカードのうちいずれかを、山札として配置するための領域である。山札配置部３１Ａは、ユーザ５Ａがカードを山札として配置するための領域である。山札配置部３１Ｂは、ユーザ５Ｂがカードを山札として配置するための領域である。
　図２に示すように、各ユーザがＴＣＧの対戦を開始するにあたり、各ユーザは、デッキを構成するカードを混ぜ、カードを裏向きにして山札配置部３１に配置する。ユーザ５Ａは、山札配置部３１Ａにカードを山札９１Ａとして配置する。ユーザ５Ｂは、山札配置部３１Ｂにカードを山札９１Ｂとして配置する。
　準備カード配置部３２は、対戦相手のカードと戦うことができるカードを準備するための領域である。各ユーザは、準備カード配置部３２に配置されているカードと、バトルカード配置部３４に配置されているカードとを入れ替えつつ、バトルカード配置部３４に配置されているカード同士を戦わせる。
　図２に示すように、ＴＣＧの対戦を開始する前においては、準備カード配置部３２、バトルカード配置部３４にはカードは配置されていない。一方、図３に示すように、ＴＣＧの対戦が進行すると、各ユーザが準備カード配置部３２、バトルカード配置部３４にカードを配置し、バトルカード配置部３４にカード同士を戦わせる。各ユーザは山札から手札を補充しつつ、手札の中からバトルに使用するカードを準備カード配置部３２、バトルカード配置部３４に配置する。ユーザ５Ａは、準備カード配置部３２Ａにカードを配置する。ユーザ５Ｂは、準備カード配置部３２Ｂにカードを配置する。
　勝敗条件カード配置部３３は、各プレイヤが勝利条件をどの程度満たしているかを示す領域である。本実施形態では、勝敗条件カード配置部３３に、各プレイヤが山札から所定枚数のカードを裏向きにして勝敗条件カード配置部３３に配置する。図２に示すように、ユーザ５Ａは、勝敗条件カード配置部３３Ａにカードを配置する。ユーザ５Ｂは、勝敗条件カード配置部３３Ｂにカードを配置する。
　バトルカード配置部３４は、対戦相手のカードと戦うカードを配置するための領域である。ユーザ５Ａは、バトルカード配置部３４Ａにカードを配置する。ユーザ５Ｂは、バトルカード配置部３４Ｂにカードを配置する。本実施形態では、基本的には、バトルカード配置部３４Ａに配置されるカードと、バトルカード配置部３４Ｂに配置されるカードとが、各カードに設定される体力、攻撃力、カードに示されるキャラクタの属性、弱点の属性、その他のパラメータに基づいて戦う。バトルカード配置部３４に配置されているカードは、攻撃力・カードの属性・弱点等に応じたダメージが与えられ、与えられたダメージが体力から減らされていく。攻撃を受ける等によりカードに設定される体力が失われると、カードがバトルカード配置部３４から退場させられ、消費カード配置部３５に配置される。
　消費カード配置部３５は、ＴＣＧの対戦で消費したカードを配置するための領域である。例えば、バトルで体力を失ったカード、効果を発動させたカード等が消費カード配置部３５に配置される。図３に示すように、ユーザ５Ａは、消費カード配置部３５Ａに、対戦で消費したカードを、カード９２Ａとして配置する。ユーザ５Ｂは、消費カード配置部３５Ｂに、対戦で消費したカードを、カード９２Ｂとして配置する。
　消費カード配置部３５に配置されたカードは、所定のカードの効果を発動させることで、山札配置部３１、準備カード配置部３２、手札等に配置させることが可能である。プレイマット３０は、消費カード配置部３５の他に、対戦で消費したカードを配置するための領域をさらに有してもよい。当該領域を、例えば、第２消費カード配置部と称する。第２消費カード配置部に配置されたカードは、所定のカードの効果を発動させても、場に戻ってくることはない。なお、第２消費カード配置部に配置されたカードの枚数によって、所定の効果が発動するようにしてもよい。
　＜０．２　ＴＣＧで使用するカードの種類＞
　本実施形態のＴＣＧでは、カードの種類として、（ｉ）バトルに使用することができるキャラクタカードと、（ｉｉ）キャラクタカードに関連付けて使用する行動力カード（エネルギーカード）と、（ｉｉｉ）対戦中に特定の効果を発揮させる効果カード（サポートカード、グッズカード、スタジアムカード等）とがある。
　（ｉ）キャラクタカードには、ユーザが山札からカードを引いて手札に加えると、準備カード配置部３２又はバトルカード配置部３４に配置することができるカード（「無条件カード」とも言う）と、特定の条件を満たすことにより、準備カード配置部３２又はバトルカード配置部３４に配置することができるカード（「条件付きカード」とも言う）とが含まれる。
　（ｉＡ）例えば、条件付きカードは、条件付きカードに関連する無条件カードを配置することを条件として、配置することができる。例えば、キャラクタの進化になぞらえて、まず無条件カードをプレイマット３０に配置すること等により対戦相手のユーザに提示したうえで、当該無条件カードに関連する条件付きカードをプレイマット３０に配置する。このような条件付きカードは、無条件カードから進化させたものとして「進化キャラクタ」とも称されることがある。また、無条件カードは、「進化キャラクタ」を配置するための元となるキャラクタともいえるため、「たねキャラクタ」とも称されることがある。
　（ｉＢ）例えば、条件付きカードは、特定のカードを消費して消費カード配置部３５に移動させることにより、準備カード配置部３２又はバトルカード配置部３４に配置できる。具体的には、特定のカードとして、プレイマット３０に配置されている無条件カードを消費して（消費カード配置部３５に移動させて）、条件付きカードを準備カード配置部３２又はバトルカード配置部３４に配置できる、としてもよい。
　例えば、条件付きカードは、プレイマット３０にユーザが配置した単数又は複数のキャラクタカードと引き換えに、準備カード配置部３２又はバトルカード配置部３４に配置できる。例えば、各キャラクタカードに、カードに示されるキャラクタの攻撃力等の個々のパラメータとは別に、キャラクタの総合的な性能を示すパラメータ（例えば、進化レベルなど）が付されている場合に、ユーザが配置したキャラクタカードの進化レベルの値に対応した進化レベルを有する条件付きカードを配置してもよい。例えば、進化レベル１のキャラクタと進化レベル２のキャラクタとをプレイマット３０に配置した状態で、これらキャラクタのカードに重ねて（または、これらのキャラクタカードと引き換えに）、進化レベル３の条件付きカードを配置できる。
　この他にも、条件付きカードにより定められる複数のキャラクタカードと引き換えに、当該条件付きカードをバトルに参加させることができる、としてもよい。このとき、キャラクタカードとは異なる後述する補助カードを消費して、条件付きカードをバトルに参加させることとしてもよい。例えば、補助カードに示される効果として、プレイマット３０のバトルカード配置部３４、消費カード配置部３５等にある特定の無条件カードと引き換えに、特定の条件付きカードをバトルに参加させられることが定められている。
　（ｉＣ）これらカードには、上記キャラクタカード、後述する行動力カード、補助カードのうち複数を兼ねるものも含まれる。例えば、キャラクタカードとしても使用でき、補助カードとしても使用できる特殊なカードが含まれることとしてもよい。ユーザは、当該特殊なカードを、キャラクタカードを配置すべき位置(例えば準備カード配置部３２、バトルカード配置部３４)に配置した場合は、キャラクタカードとして使用することができる。
　（ｉｉ）行動力カード（エネルギーカード）は、ユーザが山札からカードを引いて手札に加えたのち、キャラクタカードと関連付けてプレイマット３０に配置することにより、キャラクタカードに示される所定の行動を行うことを可能とするものである。行動力カードをキャラクタカードに関連付ける操作は、例えば、ユーザのターン中に行えることとしてもよい。例えば、プレイマット３０に配置されるキャラクタカードの近傍に行動力カードを配置することで、キャラクタカードに行動力カードを関連付けたとしてもよい。また、ターン中に行動力カードをキャラクタカードに関連付けられる回数は制限があってもよい。例えば、ユーザのターン中に１回、プレイマット３０に配置されるキャラクタカードのいずれかに、手札中の行動力カードを関連付けるよう配置することができる。例えば、キャラクタカードに、第１の攻撃アクションと、第２の攻撃アクションとが設定されているとする。第１の攻撃アクションは、キャラクタカードに１枚の行動力カードが関連付けられている場合に使用可能であり、第２の攻撃アクションは、１枚の行動力カードでは足りず２枚の行動力カードがキャラクタカードに関連付けられている場合に使用可能であるとしてもよい。
　キャラクタカードがバトルにより体力値が尽きる等により、バトルカード配置部３４から退場することとなった場合、当該キャラクタカードに関連付けられている行動力カードを当該対戦中で使用不可とすることとしてもよい。また、当該キャラクタカードに関連付けられている行動力カードを消費カード配置部３５へ移動させてもよい。
　（ｉｉｉ）対戦を補助する補助カードには、ユーザの手札にある限り、ユーザがターン中に何枚でも使用できるカード種と、ターン中に１枚だけ使用できるカード種とが含まれる。これら補助カードには、ユーザが補助カードの効果を使用することを宣言することで効果を発揮させるものも含まれる。
　なお、補助カードとして、予めプレイマット３０の所定の位置（本実施形態では、当該所定の位置については図示していない）に、裏向きにするなどして配置したうえで、ユーザが補助カードの使用を発声等により宣言することで補助カードの効果を発揮させるものも含まれる。
　＜０．３　ＴＣＧの対戦ルールの概要＞
　以上のように、ＴＣＧの対戦で使用するプレイマット３０と、カードの種類とについて説明した。次に、ＴＣＧの対戦ルールについて詳細に説明する。
　本実施形態に示すＴＣＧでは、上記のように、各ユーザがバトルカード配置部３４Ａ、バトルカード配置部３４Ｂに配置したカードに基づき攻撃または防御（バトル）を行ってＴＣＧの対戦を進行させるものとする。ＴＣＧの対戦は、ユーザがターン毎に交互に行動して進行するものとする。例えば、第１ユーザが行動した後にターンを終えると、第２ユーザのターンとなる。第２ユーザは自身のターンで行動し、行動が終了すると、第１ユーザのターンとなる。
　各ユーザは、ターンが到来するごとに、山札から所定枚数のカードを引いて手札に加える。
　各ユーザは、手札にあるカードのうち、対戦相手のユーザのカードへの攻撃または防御に使用するカード（キャラクタカード）の候補を準備カード配置部３２に配置する。
　ユーザ５Ａは、準備カード配置部３２Ａに並べられたカードと、バトルカード配置部３４Ａに並べられたカードとを、ユーザ５Ａのターン中に入れ替えることができる。また、ユーザ５Ｂは、準備カード配置部３２Ａに並べられたカードと、バトルカード配置部３４Ａに並べられたカードとを、ユーザ５Ｂのターン中に入れ替えることができる。
　勝敗条件カード配置部３３Ａと勝敗条件カード配置部３３Ｂとは、上記のように、それぞれのユーザが対戦に勝利する条件に対してどの程度の進捗があるかを各ユーザに通知するための領域である。ここで、ユーザが対戦に勝利する条件としては、例えば、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂに配置されるカードが全て回収されることとしてもよい。すなわち、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂのいずれかにおいて、全てのカードが回収されたことにより、勝敗が決することとしてもよい。
　例えば、各ユーザが、ＴＣＧの対戦に先立ち、山札から勝敗条件カード配置部３３に所定枚数のカードを配置する。すなわち、ユーザ５Ａは、山札９１Ａから所定枚数のカードを抜き出して勝敗条件カード配置部３３Ａに配置する。ユーザ５Ｂは、山札９１Ｂから所定枚数のカードを抜き出して勝敗条件カード配置部３３Ｂに配置する。ユーザ５Ａとユーザ５Ｂとが、バトルカード配置部３４Ａに配置したキャラクタカードと、バトルカード配置部３４Ｂに配置したキャラクタカードとを対戦させ、キャラクタカードに設定される退場条件が満たされると（例えば、キャラクタカードに設定される体力値が、対戦相手のキャラクタカードに設定される攻撃力に基づき減算され、尽きた場合）、当該キャラクタカードのキャラクタが気絶したものとして、当該キャラクタカードを消費カード配置部３５（「トラッシュ」ともいう）へ移動させる。
　これにより、バトルに勝利して対戦相手のキャラクタカードを退場させたユーザは、勝敗条件カード配置部３３Ａ又は勝敗条件カード配置部３３Ｂに配置されたカードを手札に加える。例えば、ユーザ５Ｂが、自身のターンでユーザ５Ａのキャラクタカードに攻撃をすることによりバトルカード配置部３４Ａに配置されるカードを退場させた場合、勝敗条件カード配置部３３Ｂに配置されるカードから所定枚数のカードを取って手札に加える。一方、ユーザ５Ａが、自身のターンでユーザ５Ｂのキャラクタカードに攻撃をすることによりバトルカード配置部３４Ｂに配置されるカードを退場させた場合、勝敗条件カード配置部３３Ａに配置されるカードから所定枚数のカードを取って手札に加える。これら操作を繰り返し、ユーザ５Ｂが勝敗条件カード配置部３３Ｂに配置されるカードを全て回収したとき、または、ユーザ５Ａが勝敗条件カード配置部３３Ａに配置されるカードを全て回収したときに、回収しきったユーザを、ＴＣＧの対戦に勝利したユーザと決定することとしてもよい。
　なお、対戦の勝利条件としては、この他に、バトルカード配置部３４と準備カード配置部３２のいずれにもキャラクタカードがない場合に敗北する、としてもよい。また、対戦の勝利条件としては、各ユーザが自分のターンで山札配置部３１から山札を引けない場合に敗北する、としてもよい。
　図１～図３では、ユーザ同士が対面してＴＣＧの対戦を行う例を説明している。しかしながら、ＴＣＧの対戦は、ユーザ同士が対面するものに限定されない。ユーザ同士がインターネットで接続し、相手の音声及び相手のカード配置等をインターネットを介して取得することで対戦を行ってもよい。具体的には、例えば、ユーザは、プレイマット３０における自身の領域をカメラ等で撮影しながら対戦を行う。撮影された画像は、リアルタイムで対戦相手へ送信される。ユーザは、対戦相手から送られてきた、対戦相手の領域についての画像を受信し、受信した画像をディスプレイに表示する。これにより、ユーザは、現実の自身のカードを扱いながら、画面越しに対戦相手のカードをリアルタイムに確認することが可能となる。このように、ユーザは、アナログカードを用いたＴＣＧの対戦をオンラインで実施してもよい。
　カメラが複数ある場合、又は、カメラの視野角を調整可能なデバイスがある場合、ユーザの顔を撮影し、撮影した画像を対戦相手へ送信してもよい。こうすることで、対戦中の相手の表情を確認することが可能となるため、オンラインでのＴＣＧの対戦で、対面での対戦の満足度を得ることが可能となる。
　＜１　システム全体の構成図＞
　図４は、システム１の全体構成の例を示すブロック図である。図４に示すシステム１は、例えば、端末装置１０、及びサーバ２０を含む。端末装置１０、及びサーバ２０は、例えば、ネットワーク８０を介して通信接続する。
　図４において、システム１が端末装置１０を３台含む例を示しているが、システム１に含まれる端末装置１０の数は、３台に限定されない。システム１に含まれる端末装置１０は、２台以下であってもよいし、４台以上であってもよい。
　図４において、システム１がサーバ２０を１台含む例を示しているが、システム１に含まれるサーバ２０の数は、１台に限定されない。サーバ２０は、有する機能に応じ、複数のサーバから構成されていてもよい。また、サーバ２０は、例えば、複数の装置の集合体を１つのサーバとしてもよい。１つ又は複数のハードウェアに対して本実施形態に係るサーバ２０を実現することに要する複数の機能の配分の仕方は、各ハードウェアの処理能力及び／又はサーバ２０に求められる仕様等に鑑みて適宜決定することができる。
　図４に示す端末装置１０は、例えば、デジタルＴＣＧをプレイするユーザが操作する情報処理装置である。端末装置１０は、例えば、スマートフォン、タブレット等の携帯端末により実現される。また、端末装置１０は、据え置き型のＰＣ（Personal Computer）、ラップトップＰＣ等により実現されてもよいし、ＨＭＤ（Head Mount Display）等のウェアラブル端末により実現されてもよい。
　端末装置１０は、通信ＩＦ（Interface）１２と、入力装置１３と、出力装置１４と、メモリ１５と、ストレージ１６と、プロセッサ１９とを備える。入力装置１３は、ユーザからの入力操作を受け付けるための装置（例えば、タッチパネル、タッチパッド等）である。出力装置１４は、ユーザに対して情報を提示するための装置（ディスプレイ、スピーカー等）である。
　サーバ２０は、例えば、カードに関する情報及びデッキに関する情報を管理する情報処理装置である。
　サーバ２０は、例えば、ネットワーク８０に接続されたコンピュータにより実現される。図４に示すように、サーバ２０は、通信ＩＦ２２と、入出力ＩＦ２３と、メモリ２５と、ストレージ２６と、プロセッサ２９とを備える。入出力ＩＦ２３は、ユーザからの入力操作を受け付けるための入力装置、及び、ユーザに対して情報を提示するための出力装置とのインタフェースとして機能する。
　各情報処理装置は演算装置と記憶装置とを備えたコンピュータにより構成されている。コンピュータの基本ハードウェア構成及び、当該ハードウェア構成により実現されるコンピュータの基本機能構成は後述する。端末装置１０、及びサーバ２０のそれぞれについて、後述するコンピュータの基本ハードウェア構成及びコンピュータの基本機能構成と重複する説明は省略する。
　＜１．１　端末装置の構成＞
　図５は、図４に示す端末装置１０の構成例を表すブロック図である。図５に示すように、端末装置１０は、通信部１２０と、入力装置１３と、出力装置１４と、音声処理部１７と、マイク１７１と、スピーカー１７２と、カメラ１６０と、位置情報センサ１５０と、記憶部１８０と、制御部１９０とを備える。端末装置１０に含まれる各ブロックは、例えば、バス等により電気的に接続される。
　通信部１２０は、端末装置１０が他の装置と通信するための変復調処理等の処理を行う。通信部１２０は、制御部１９０で生成された信号に送信処理を施し、外部（例えば、サーバ２０）へ送信する。通信部１２０は、外部から受信した信号に受信処理を施し、制御部１９０へ出力する。
　入力装置１３は、端末装置１０を操作するユーザが指示、又は情報を入力するための装置である。入力装置１３は、例えば、操作面へ触れることで指示が入力されるタッチ・センシティブ・デバイス１３１等により実現される。端末装置１０がＰＣ等である場合には、入力装置１３は、リーダー、キーボード、マウス等により実現されてもよい。入力装置１３は、ユーザから入力される指示を電気信号へ変換し、電気信号を制御部１９０へ出力する。なお、入力装置１３には、例えば、外部の入力機器から入力される電気信号を受け付ける受信ポートが含まれてもよい。
　出力装置１４は、端末装置１０を操作するユーザへ情報を提示するための装置である。出力装置１４は、例えば、ディスプレイ１４１等により実現される。ディスプレイ１４１は、制御部１９０の制御に応じたデータを表示する。ディスプレイ１４１は、例えば、ＬＣＤ（Liquid Crystal Display）、又は有機ＥＬ（Electro-Luminescence）ディスプレイ等によって実現される。
　音声処理部１７は、例えば、音声信号のデジタル－アナログ変換処理を行う。音声処理部１７は、マイク１７１から与えられる信号をデジタル信号に変換して、変換後の信号を制御部１９０へ与える。また、音声処理部１７は、音声信号をスピーカー１７２へ与える。音声処理部１７は、例えば音声処理用のプロセッサによって実現される。マイク１７１は、音声入力を受け付けて、当該音声入力に対応する音声信号を音声処理部１７へ与える。スピーカー１７２は、音声処理部１７から与えられる音声信号を音声に変換して当該音声を端末装置１０の外部へ出力する。
　カメラ１６０は、受光素子により光を受光し、撮影信号として出力するためのデバイスである。
　位置情報センサ１５０は、端末装置１０の位置を検出するセンサであり、例えばＧＰＳ（Global Positioning System）モジュールである。ＧＰＳモジュールは、衛星測位システムで用いられる受信装置である。衛星測位システムでは、少なくとも３個または４個の衛星からの信号を受信し、受信した信号に基づいて、ＧＰＳモジュールが搭載される端末装置１０の現在位置を検出する。位置情報センサ１５０は、端末装置１０が接続する無線基地局の位置から、端末装置１０の現在の位置を検出してもよい。
　記憶部１８０は、例えば、メモリ１５、及びストレージ１６等により実現され、端末装置１０が使用するデータ、及びプログラムを記憶する。記憶部１８０は、例えば、ユーザ情報１８１、カード情報１８２、デッキ情報１８３を記憶する。
　ユーザ情報１８１は、例えば、ＴＣＧをプレイするユーザに関する情報を含む。ユーザに関する情報には、例えば、ユーザＩＤ、ユーザの氏名、年齢、住所、生年月日、登録年月日、ユーザがフォローしている他ユーザに関する情報等が含まれる。
　カード情報１８２は、例えば、カードに関する情報を含む。カード情報１８２は、ユーザが所有するカードに関する情報を含んでいてもよい。詳細は後述する。
　デッキ情報１８３は、例えば、ユーザが構築したデッキに関する情報を含む。詳細は後述する。
　制御部１９０は、プロセッサ１９が記憶部１８０に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部１９０は、端末装置１０の動作を制御する。制御部１９０は、プログラムに従って動作することにより、操作受付部１９１、送受信部１９２、管理部１９３、表示制御部１９４、対戦処理部１９５としての機能を発揮する。
　操作受付部１９１は、入力装置１３から入力される指示、又は情報を受け付けるための処理を行う。具体的には、例えば、操作受付部１９１は、タッチ・センシティブ・デバイス１３１等から入力される指示、又は情報を受け付ける。
　また、操作受付部１９１は、カメラ１６０から入力される画像を受け付ける。具体的には、例えば、操作受付部１９１は、カメラ１６０により撮影された撮影データを受信する。
　また、操作受付部１９１は、マイク１７１から入力される音声情報を受け付ける。具体的には、例えば、操作受付部１９１は、マイク１７１から入力され、音声処理部１７でデジタルデータに変換された音声データを受信する。
　送受信部１９２は、端末装置１０が、サーバ２０等の外部の装置と、通信プロトコルに従ってデータを送受信するための処理を行う。具体的には、例えば、送受信部１９２は、ユーザから入力された指示、又は取得した種々の情報をサーバ２０へ送信する。また、送受信部１９２は、サーバ２０から提供される情報を受信する。サーバ２０から提供される情報は、例えば、新たにユーザが入手したカードに関する情報、又は、デッキに関する情報を含む。
　管理部１９３は、記憶部１８０に記憶される、ユーザ情報１８１、カード情報１８２、デッキ情報１８３を管理する。例えば、管理部１９３は、ユーザに関する情報が編集されると、編集された情報をユーザ情報１８１に記憶する。また、管理部１９３は、カードに関する情報が更新されると、カード情報１８２を更新する。また、管理部１９３は、デッキに関する情報が更新されると、デッキ情報１８３を更新する。
　表示制御部１９４は、ユーザに対して所定の画像を表示するため、出力装置１４を制御する。例えば、表示制御部１９４は、カード情報１８２で管理される情報と、デッキ情報１８３で管理される情報とに基づき、ユーザが所有しているカードの管理画面を表示するように、ディスプレイ１４１を制御する。また、表示制御部１９４は、デッキに関する情報を表示するように、ディスプレイ１４１を制御する。
　対戦処理部１９５は、他デッキとの対戦処理を制御する。対戦は、例えば、以下の態様が想定される。
・デジタルカードで構築したデッキを用いたＣＰＵとの対戦
・デジタルカードで構築したデッキを用いた他プレイヤとの対戦
・アナログカードをカメラで読み込んで行う他プレイヤとの対戦
・大会での対戦
　＜１．２　サーバの機能的な構成＞
　図６は、サーバ２０の機能的な構成の例を示す図である。図６に示すように、サーバ２０は、通信部２０１と、記憶部２０２と、制御部２０３としての機能を発揮する。
　通信部２０１は、サーバ２０が外部の装置と通信するための処理を行う。
　記憶部２０２は、例えば、ユーザ情報テーブル２０２１、カードマスタテーブル２０２２、デッキ情報テーブル２０２３、対戦情報テーブル２０２４、特典情報テーブル２０２５を有する。
　ユーザ情報テーブル２０２１は、例えば、ＴＣＧに関するサービスに登録しているユーザに関する情報を記憶するテーブルである。詳細は後述する。
　カードマスタテーブル２０２２は、例えば、ユーザが入手可能なカードに関する情報を記憶するテーブルである。詳細は後述する。
　デッキ情報テーブル２０２３は、例えば、ユーザにより登録されたデッキに関する情報を記憶するテーブルである。詳細は後述する。
　対戦情報テーブル２０２４は、例えば、過去に実施された対戦に関する情報を記憶するテーブルである。詳細は後述する。
　特典情報テーブル２０２５は、例えば、ユーザに付与する特典に関する情報（特典情報）を記憶するテーブルである。詳細は後述する。
　制御部２０３は、プロセッサ２９が記憶部２０２に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部２０３は、プログラムに従って動作することにより、受信制御モジュール２０３１、送信制御モジュール２０３２、管理モジュール２０３３、付与モジュール２０３４、対戦処理モジュール２０３５としての機能を発揮する。
　受信制御モジュール２０３１は、サーバ２０が外部の装置から通信プロトコルに従って信号を受信する処理を制御する。
　送信制御モジュール２０３２は、サーバ２０が外部の装置に対し通信プロトコルに従って信号を送信する処理を制御する。
　管理モジュール２０３３は、記憶部２０２に記憶されるテーブルを管理する。具体的には、例えば、管理モジュール２０３３は、デッキに関する指示を受信すると、受信した指示に基づき、デッキ情報テーブル２０２３を更新する。また、管理モジュール２０３３は、対戦に関する情報を受信すると、受信した情報に基づき、デッキ情報テーブル２０２３、対戦情報テーブル２０２４を更新する。
　付与モジュール２０３４は、ユーザに対し、特典を付与する。例えば、付与モジュール２０３４は、特典情報テーブル２０２５を参照し、条件を満たしたユーザに特典を付与する。
　対戦処理モジュール２０３５は、ユーザ同士の対戦処理を制御する。例えば、対戦処理モジュール２０３５は、デジタルカードで構築したデッキを用いたプレイヤ同士の対戦を制御する。また、対戦処理モジュール２０３５は、例えば、アナログカードをカメラで読み込んで行うプレイヤ同士の対戦を制御する。
　＜２　データ構造＞
　図７、図８は、端末装置１０が記憶する情報のデータ構造を示す図である。なお、図７、図８は一例であり、記載されていないデータを除外するものではない。
　図７は、カード情報１８２のデータ構造を示す図である。図７に示すカード情報１８２は、カードＩＤをキーとして、名称、種別、属性、カード情報、画像データ、枚数等のカラムを有するテーブルである。カード情報１８２は、これらの他に、全く同じカードに対してもカードを一意に特定するためのカード管理ＩＤ、レギュレーション、又はレアリティに関する情報等を有していてもよい。
　カードＩＤは、カードの種類を一意に識別するための識別子を記憶する項目である。本実施形態において、全く同じカードに対しては同一のカードＩＤが割り当てられている。同一の名称であっても、効果が異なるカード、レアリティが異なるカード、レギュレーションが異なるカードには、異なるカードＩＤが割り振られている。名称は、カードの名称を記憶する項目である。種別は、カードの種類を記憶する項目である。本実施形態において、カードの種類は、例えば、キャラクタ、エネルギー、サポート、グッズ、スタジアム等を含む。
　属性は、キャラクタが属する性質を記憶する項目である。本実施形態において、属性は、例えば、炎、水、雷、草、超、鋼、悪、闘等を含む。属性には、相対すると有利になる属性、及び不利になる属性が存在する。カード情報は、カードの内容を説明する情報を記憶する項目である。カードの種別がキャラクタである場合、カード情報は、例えば、キャラクタの攻撃力、体力、技を出すのに必要なエネルギー量、逃げるのに必要なエネルギー量、弱点、抵抗力、キャラクタが有する特殊な特性等を含む。カードの種別がサポート、グッズ、スタジアムである場合、カード情報は、例えば、カードの使用要件、カード使用時に発生する効果等を含む。
　画像データは、画像を記憶する項目である。画像データは、他の場所に配置された画像データファイルに対する参照情報（パス）を記憶するものとしてもよい。枚数は、ユーザが所持している、同一のカードＩＤが割り振られているカードの枚数を記憶する項目である。本実施形態において、同一の名称であっても、効果が異なるカードには、異なるカードＩＤが割り振られている。また、同一の名称であっても、レアリティが異なるカードには、異なるカードＩＤが割り振られている。また、同一の名称であっても、レギュレーションが異なるカードには、異なるカードＩＤが割り振られている。なお、所有しているカードがカード管理ＩＤによりそれぞれ一意に管理されている場合、枚数は管理されなくてもよい。
　図８は、デッキ情報１８３のデータ構造を示す図である。図８に示すデッキ情報１８３は、デッキＩＤをキーとして、名称、編成カード、完成、更新日、登録情報等のカラムを有するテーブルである。デッキ情報１８３は、これらの他に、デッキの通称名称に関する情報、デッキの使用履歴、代表画像等を有していてもよい。デッキの通称名称は、例えば、デッキに用いられている特徴的なカードに基づいて付けられる、デッキの特徴を端的に表す、複数のユーザ間で共通の認識のもと付けられる名称である。代表画像は、例えば、デッキに編成されるカードのうち、ユーザにより指定されたカードについての画像である。代表画像は、例えば、カードの記載のうち、文章を除く、イラストに係る画像である。代表画像は、例えば、画素数を所定の数まで縮小させた画像、例えば、サムネイル画像である。
　デッキＩＤは、デッキを一意に識別するための識別子を記憶する項目である。名称は、デッキの名称を記憶する項目である。名称は、例えば、デッキを編成するカードの一部に基づいて生成されたり、ユーザにより付けられる。編成カードは、デッキを編成するカードを記憶する項目である。編成カードでは、例えば、デッキを編成するカードのカードＩＤが記憶される。
　完成は、デッキが完成しているか否かを記憶する項目である。本実施形態において、丸は、デッキが完成していることを表し、ばつは、デッキが完成していないことを表す。本実施形態において、デッキが完成しているとは、例えば、規定枚数のカードによりデッキを組み上げ、対戦に使用可能な状態となったことを表す。更新日は、デッキの構成を変更した日を記憶する項目である。更新日の算定において、一のデッキに採用されるカードを他のデッキで採用することも変更と扱ってもよい。登録情報は、サーバ２０に登録されているデッキとの係りを記憶する項目である。登録情報には、例えば、デッキがサーバ２０に登録されたときに発行されるデッキコードが記憶される。
　デッキについてのレコードは、ユーザからの指示により、端末装置１０において新たなデッキが作成されたときに追加される。
　図９～図１３は、サーバ２０が記憶する情報のデータ構造を示す図である。なお、図９～図１３は一例であり、記載されていないデータを除外するものではない。
　図９は、ユーザ情報テーブル２０２１のデータ構造を示す図である。図９に示すユーザ情報テーブル２０２１は、ユーザＩＤをキーとして、氏名、年齢、住所、生年月日、登録年月日、フォロー等のカラムを有するテーブルである。ユーザ情報テーブル２０２１は、上記に限らず、熟練度等をカラムとして有してもよい。
　ユーザＩＤは、ユーザを一意に識別するための識別子を記憶する項目である。氏名は、ユーザの氏名を記憶する項目である。年齢は、ユーザの年齢を記憶する項目である。住所は、ユーザが住んでいる場所を記憶する項目である。生年月日は、ユーザが生まれた日付を記憶する項目である。登録年月日は、ユーザがＴＣＧに係るサービスの利用を開始した日付を記憶する項目である。フォローは、ユーザがフォローしている他ユーザに関する情報を記憶する項目である。フォローは、例えば、ユーザがフォローしている他ユーザのユーザＩＤが記憶される。
　ユーザ情報テーブル２０２１におけるレコードは、ユーザが新たに登録されると追加される。
　図１０は、カードマスタテーブル２０２２のデータ構造を示す図である。図１０に示すカードマスタテーブル２０２２は、カードＩＤをキーとして、名称、種別、属性、カード情報、画像データ等のカラムを有するテーブルである。
　カードＩＤは、カードの種類を一意に識別するための識別子を記憶する項目である。名称は、カードの名称を記憶する項目である。種別は、カードの種類を記憶する項目である。属性は、キャラクタが属する性質を記憶する項目である。カード情報は、カードの内容を説明する情報を記憶する項目である。画像データは、画像を記憶する項目である。
　カードマスタテーブル２０２２におけるレコードは、例えば、カードが新たに発行されると追加される。
　図１１は、デッキ情報テーブル２０２３のデータ構造を示す図である。図１１に示すデッキ情報テーブル２０２３は、デッキコードをキーとして、名称、作成者、作成日、編成カード、対戦情報、公開等のカラムを有するテーブルである。デッキ情報テーブル２０２３は、これらの他に、デッキの通称名称に関する情報、代表画像、登録者、閲覧回数、ユーザが登録を要求した日、デッキの使用が所定の条件を達成した日等を有していてもよい。登録者は、例えば、デッキを登録したユーザのうち、作成者ではないユーザを記憶する。つまり、登録者は、２番目以降にデッキを作成して登録したユーザのユーザＩＤを表す。また、登録者を区別可能な情報が含まれていてもよい。例えば、登録した順番を認識可能な番号が含まれていてもよい。つまり、作成者に「１」が付される場合、最初の登録者には「２」が付される。最初の登録者に「１」が付される場合には、次の登録者に「２」が付されてもよい。こうすることで、ユーザは、該当するデッキを使い始めた順序を把握することが可能となり、例えば、流行に先駆けたことを意識することが可能となる。閲覧回数は、例えば、デッキの内容を確認したユーザ数を記憶する。デッキ編成をコピーする機能をサーバ２０が提供している場合、コピーしたユーザの数を参照回数として記憶してもよい。
　デッキコードは、登録されているデッキを一意に識別するための識別子を記憶する項目である。デッキコードは、ユーザから公開が要求されたデッキが新規なデッキである場合、管理モジュール２０３３により発行される。新規なデッキとは、例えば、デッキの少なくとも一部が既存のデッキと異なるデッキを表す。また、新規なデッキとは、例えば、全く同一の構成のデッキが存在しないデッキを表すと換言可能である。図１１に示すデッキコードは、例えば、図８に示すデッキＩＤとは異なる識別子となっている。図１１に示すデッキコードは、公開されているデッキを管理するものであり、図８に示すデッキＩＤは、自身のデッキを管理するためのものであるからである。
　名称は、デッキの名称を記憶する項目である。名称はユーザにより付けられる。作成者は、デッキを最初に作成したユーザのユーザＩＤを記憶する項目である。作成日は、デッキが最初に作成された日付を記憶する項目である。編成カードは、デッキを編成するカードを記憶する項目である。編成カードでは、例えば、デッキを編成するカードのカードＩＤが記憶される。対戦情報は、デッキコードにより識別されるデッキを用いて実施した対戦に関する情報を記憶する項目である。対戦情報は、例えば、以下の情報を含む。
・対戦を識別するための対戦ＩＤ
・対戦の日時
・参加した大会
・大会の結果
　公開は、デッキが他ユーザに公開されているか否かを記憶する項目である。本実施形態において、丸は、デッキが他ユーザに公開されていることを表し、ばつは、デッキが他ユーザに公開されていないことを表す。本実施形態において、デッキが公開されていないとは、自身のみが確認可能なことを意味する。
　デッキ情報テーブル２０２３におけるレコードは、デッキが新たに登録されると追加される。
　図１２は、対戦情報テーブル２０２４のデータ構造を示す図である。図１２に示す対戦情報テーブル２０２４は、対戦ＩＤをキーとして、日時、対戦者、デッキコード、勝者、対戦ログ情報、大会情報等のカラムを有するテーブルである。
　対戦ＩＤは、対戦を一意に識別するための識別子を記憶する項目である。対戦ＩＤは、対戦に関する新たな情報が登録されると、管理モジュール２０３３により発行される。日時は、対戦が行われた日時を記憶する項目である。対戦者は、対戦を行ったプレイヤに関する情報を記憶する項目である。本実施形態では、例えば、対戦者には、対戦を行ったプレイヤ同士のユーザＩＤが記憶されている。
　デッキコードは、対戦に用いられたデッキを識別するコードを記憶する項目である。本実施形態では、例えば、対戦を行ったプレイヤと、そのプレイヤが使用したデッキのデッキコードとが関連付けられている。なお、デッキコードは必ずしも記憶されていなくてもよい。つまり、デッキコードが登録されていなくてもよい。デッキコードが登録されていない場合、例えば、項目「デッキコード」には、デッキに含まれるカードの内容から判別される、デッキを表す情報が記憶されてもよい。このとき、例えば、管理モジュール２０３３は、デッキに含まれるカードに基づき、デッキを表す情報を作成し、作成した情報を項目「デッキコード」に記憶する。例えば、管理モジュール２０３３は、デッキに含まれる主要なカードの名称に基づき、デッキを表す情報を作成する。また、管理モジュール２０３３は、デッキに含まれるカードについての情報を項目「デッキコード」に記憶してもよい。
　勝者は、対戦の勝者を記憶する項目である。対戦ログ情報は、対戦中にプレイヤが採用した手を記憶する項目である。具体的には、例えば、対戦ログ情報には、プレイヤが所定の配置部（山札又は勝敗条件カード等）からカードを引くこと、プレイヤが所定の配置部にカードを配置すること、プレイヤが所定のカードの効果を使用すること等が記憶される。対戦中にプレイヤが採用した手は、対戦中のデッキ回しと称してもよい。大会情報は、対戦に関する情報を記憶する項目である。例えば、大会情報には、対戦が行われた大会名、大会における対戦のラウンド数が含まれる。大会情報は、公式に開催された大会に関わらず、プライベートで開催された大会での対戦情報を含んでもよい。また、大会情報は、大会に限定されず、プライベートでの対戦での対戦情報を含んでもよい。
　対戦情報テーブル２０２４におけるレコードは、対戦が新たに登録されると追加される。
　図１３は、特典情報テーブル２０２５のデータ構造を示す図である。図１３に示す特典情報テーブル２０２５は、特典ＩＤをキーとして、特典内容、条件等のカラムを有するテーブルである。
　特典ＩＤは、特典を一意に識別するための識別子を記憶する項目である。特典内容は、特典の内容を記憶する項目である。条件は、特典が付与される条件を記憶する項目である。
　＜３　動作＞
　ユーザがデッキを構築し、構築したデッキを登録する際の端末装置１０と、サーバ２０との動作について説明する。
（デッキの構築）
　ユーザは、端末装置１０を操作することで、カードを編集し、複数のデジタルカードから編成されるデッキを構築する。
　ユーザは、端末装置１０に対し、自身が所有しているカードの一覧を表示するように指示を入力する。具体的には、例えば、ユーザは、端末装置１０にインストールされているデジタルＴＣＧに係るアプリを実行させる。ユーザは、立ち上げたアプリにおいて、所有するカードを表示させる指示を端末装置１０に入力する。端末装置１０の制御部１９０は、表示制御部１９４により、カード情報１８２、デッキ情報１８３に基づき、カードの一覧をディスプレイ１４１に表示する。
　ユーザは、端末装置１０に対し、自身が所有しているデッキの一覧を表示するように指示を入力する。具体的には、例えば、ユーザは、カードの一覧表示において、デッキの一覧を表示させる指示を入力するための指示オブジェクトに接触する。表示制御部１９４は、デッキ情報１８３に基づき、デッキの一覧をディスプレイ１４１に表示する。なお、ユーザは、端末装置１０にインストールされているデジタルＴＣＧに係るアプリを立ち上げ、立ち上げたアプリにおいて、デッキを編集する指示を端末装置１０に入力してもよい。
　図１４は、端末装置１０に表示されるデッキ一覧の例を表す模式図である。図１４において、表示制御部１９４は、領域１４１１と、領域１４１２とを表示する。領域１４１２は、領域１４１１で記載される表示条件に則った態様で、ユーザが所有するデッキを表示する領域である。
　図１４に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、更新日付順等のうちからユーザにより選択される。図１４に示す例では、「表示順：名称順」となっており、領域１４１２に、デッキが、名称の並び順で、配列されている。
　領域１４１１には、検索ウィンドウ１４１１１が表示されている。ユーザは、所望のデッキがある場合、検索ウィンドウ１４１１１にキーワード等を入力し、所望のデッキを検索する。
　ユーザがデッキを選択すると、表示制御部１９４は、ユーザにより選択されたデッキに対して実施可能な処理をディスプレイ１４１に表示する。
　図１５は、ディスプレイ１４１の表示例を表す模式図である。図１５に示す例では、表示制御部１９４は、デッキに対する処理が選択可能にリスト状に表示されたウィンドウ１４１２１を表示する。表示制御部１９４は、ウィンドウ１４１２１に、デッキに対する処理として、例えば、編集、登録等を表示する。ユーザは、入力装置１３を操作することで、デッキに対する処理を選択する。
　ユーザは、例えば、端末装置１０に対し、選択しているデッキの編集画面を表示するように指示を入力する。具体的には、例えば、ユーザは、図１５に示されるウィンドウ１４１２１において、「編集」を選択する。表示制御部１９４は、カード情報１８２、デッキ情報１８３に基づき、デッキの編集画面をディスプレイ１４１に表示する。
　図１６は、端末装置１０に表示される、デッキ２の編集画面の例を表す模式図である。図１６では、デッキ２がユーザにより選択された場合の編集画面を示しているが、ユーザにより選択されるデッキはデッキ２に限定されない。図１６において、表示制御部１９４は、領域１４１１と、領域１４１３と、領域１４１４とを表示する。領域１４１３は、領域１４１１で記載される表示条件に則った態様で、デッキを構成しているカードを表示する領域である。領域１４１４は、領域１４１１で記載される表示条件に則った態様で、ユーザが所有するカードの一覧を表示する領域である。領域１４１４には、領域１４１３に表示されるカードと入れ替え可能にカードが表示される。領域１４１３に表示されるカードは、領域１４１４に表示されるカードと識別可能な態様で表示されてもよい。図１６に示す例では、領域１４１３に表示されるカードは、領域１４１４に表示されるカードよりも大きく表示されている。
　図１６に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、レアリティ順、取得日付順等のうちからユーザにより選択される。図１６に示す例では、「表示順：番号順」となっており、領域１４１３、１４１４に、カードが、カードＩＤの並び順で配列されている。
（デッキの登録）
　ユーザは、端末装置１０を操作することで、構築したデッキを登録する。
　図１７は、ユーザがデッキを登録する際の端末装置１０とサーバ２０との動作の例を説明する図である。
　ユーザは、例えば、端末装置１０を操作して所望のデッキを選択し、選択しているデッキを登録するように指示を入力する。具体的には、例えば、ユーザは、図１５に示されるウィンドウ１４１２１において、「登録」を選択する。
　端末装置１０は、ユーザにより「登録」が選択されると、表示制御部１９４により、デッキを登録することを確認するための画面を表示する。
　図１８は、ディスプレイ１４１の表示例を表す模式図である。図１８に示す例では、表示制御部１９４は、デッキを登録することを確認するためのウィンドウ１４１２２を表示する。ウィンドウ１４１２２には、ユーザの意思を入力するためのボタン１４１２２１、１４１２２２が表示されている。デッキを登録することに間違いがない場合、ユーザは、Ｙｅｓボタン１４１２２１を押下する。本実施形態において、ボタン１４１２２１の押下が登録要求の入力を意味する。
　ステップＳ１１において、端末装置１０は、操作受付部１９１により、ユーザから入力されたデッキの登録要求を受け付ける。端末装置１０は、送受信部１９２により、受け付けた登録要求をサーバ２０へ送信する。
　ステップＳ１２において、サーバ２０は、ユーザからのデッキの登録要求に基づき、デッキを登録する。具体的には、例えば、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録要求のあったデッキのうち、新しい編成のデッキのレコードをデッキ情報テーブル２０２３に作成する。
　管理モジュール２０３３は、新たな編成のデッキと、当該デッキの作成者とを対応付ける。具体的には、例えば、管理モジュール２０３３は、デッキの作成者のユーザＩＤを、新たに作成したレコードの項目「作成者」に記憶する。
　管理モジュール２０３３は、新規でないデッキに対する登録要求については、当該登録を要求したユーザと、登録が要求された既存のデッキとを関連付ける。例えば、管理モジュール２０３３は、登録が要求された既存のデッキについてのレコードの項目「登録者」に、登録を要求したユーザのユーザＩＤを記憶する。
　ステップＳ１３において、管理モジュール２０３３は、登録したデッキの公開範囲を設定する。具体的には、管理モジュール２０３３は、例えば、デッキを登録したユーザに対し、登録したデッキを自身以外の他ユーザに公開するか否かを確認する。
　管理モジュール２０３３は、ユーザが他ユーザにも公開することを望む場合、他ユーザからのアクセスが可能なようにデッキを管理する。例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３の項目「公開」に丸を記憶する。
　管理モジュール２０３３は、ユーザが他ユーザへの公開を望まない場合、他ユーザからのアクセスができないようにデッキを管理する。例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３の項目「公開」にばつを記憶する。
　ユーザ情報テーブル２０２１には、ユーザがフォローする他ユーザが登録されている。管理モジュール２０３３は、所定のユーザによりデッキが登録されると、当該ユーザをフォローしているユーザに対し、当該ユーザにより新たなデッキが登録されたことを通知してもよい。新たなデッキを構築することに長けたユーザが存在している。他ユーザは、このようなユーザをフォローすることで、現在のデッキのトレンドを把握することが可能となる。
（デッキの登録における詳細処理１）
　図１７のステップＳ１２に示す制御部２０３の処理を詳細に説明する。
　図１９は、デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。
　ステップＳ２１において、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録が要求されたデッキが新規のデッキであるか否かを判断する。具体的には、管理モジュール２０３３は、デッキを編成するカードの少なくとも一部のカードが、既存のデッキを編成するカードと異なるか否かを判断する。管理モジュール２０３３は、全く同一の構成のデッキが存在するか否かを判断してもよいし、構成の一致度合いが一定の条件を満たすデッキが存在するか否かを判断してもよい。以下は全く同一の構成のデッキが存在しない場合を例に説明する。
　全く同一の構成のデッキが存在しない場合、管理モジュール２０３３は、登録要求があったデッキが新規のデッキであると判断し、処理をステップＳ２２へ移行させる。
　ステップＳ２２において、管理モジュール２０３３は、デッキ情報テーブル２０２３に新たなレコードを作成し、作成したレコードにデッキコードを割り当てる。管理モジュール２０３３は、作成したレコードに、要求があったデッキに関する情報を記憶する。管理モジュール２０３３は、例えば、作成したレコードの名称、編成カードを、ユーザから入力される情報に基づいて記憶する。また、管理モジュール２０３３は、新たに作成したデッキレコードと、デッキの登録を要求してきたユーザとを対応付ける。すなわち、管理モジュール２０３３は、レコードにおける項目「作成者」に、デッキの登録を要求してきたユーザのユーザＩＤを記憶し、項目「作成日」に、新規であると判断した日付を記憶する。
　ステップＳ２３において、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことと、登録されたデッキのデッキコードとを、登録要求の要求元の端末装置１０へ送信する。
　サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが登録されたことと共に、ユーザが作成者として対応付けられたことをディスプレイ１４１に表示する。表示制御部１９４は、登録を要求したデッキが新しい構成のデッキであるために登録されたという理由をディスプレイ１４１に表示してもよい。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードにデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであることを表示することが可能となる。
　図２０は、ディスプレイ１４１の表示例を表す模式図である。図２０に示す例では、表示制御部１９４は、デッキが登録され、ユーザが作成者として対応付けられたことを通知するためのウィンドウ１４１２３を表示する。なお、ウィンドウ１４１２３における現在形、又は過去形の表現には制限はない。ウィンドウ１４１２３には、通知を確認したことを入力するためのボタン１４１２３１が表示されている。通知内容を確認した場合、ユーザは、確認ボタン１４１２３１を押下する。
　図１７のステップＳ１３において、端末装置１０は、登録されたデッキを他ユーザに公開するか否かの選択をユーザから受け付ける。具体的には、表示制御部１９４は、登録されたデッキを他ユーザに公開するか否かの選択を受け付けるための画像をディスプレイ１４１に表示する。
　図２１は、ディスプレイ１４１の表示例を表す模式図である。例えば、図２０に示す画面においてユーザが確認ボタン１４１２３１を押下すると、表示制御部１９４は、他ユーザへの公開の選択を受け付けるためのウィンドウ１４１２４を表示する。ウィンドウ１４１２４には、ユーザの意思を入力するためのボタン１４１２４１、１４１２４２が表示されている。デッキを他ユーザにも公開する場合、ユーザは、Ｙｅｓボタン１４１２４１を押下する。送受信部１９２は、デッキの公開に関する指示をサーバ２０へ送信する。
　デッキの公開に関する指示を受信すると、サーバ２０は、管理モジュール２０３３により、公開に関する情報をデッキ情報テーブル２０２３の項目「公開」に記憶する。これにより、項目「公開」に丸が記憶される場合、他ユーザもデッキの編成、及び作成者を確認することが可能となる。一方、項目「公開」にばつが記憶される場合、作成者であるユーザだけがデッキの編成、及び作成者を確認することが可能となる。
　ステップＳ２１において、登録が要求されたデッキが新規のデッキでない場合、管理モジュール２０３３は、処理をステップＳ２４へ移行させる。
　ステップＳ２４において、管理モジュール２０３３は、例えば、既存のデッキに、登録を要求したユーザを関連付ける。具体的には、例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３を参照し、登録が要求されたデッキと同一のデッキを取得する。管理モジュール２０３３は、取得したデッキのレコードに、登録を要求したユーザのユーザＩＤを記憶する。これにより、登録を要求したユーザに対し、既存のデッキを関連付けることが可能となる。
　ステップＳ２４において、送信制御モジュール２０３２は、登録が要求されたデッキが既に存在していることを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、同一のデッキが既に存在することと、既存のデッキのデッキコードとを登録要求の要求元の端末装置１０へ送信する。送信制御モジュール２０３２は、既存のデッキを作成したユーザのユーザＩＤを要求元の端末装置１０へ送信してもよい。これにより、デッキを作成したユーザの存在感が高まり、デッキを先に作成することの動機となり得る。
　サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが既に存在していることをディスプレイ１４１に表示する。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードに、既存のデッキのデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであることを表示することが可能となる。
　なお、ステップＳ２４の処理は必須ではない。既存のデッキと、ユーザとの関連付けが不要である場合、ステップＳ２４の処理を実施しなくてもよい。つまり、既存のデッキと、ユーザとの関連付けが不要である場合、例えば、ステップＳ２１で、登録が要求されたデッキが新規のデッキでないと判断すると、送信制御モジュール２０３２は、デッキが既に存在していることを端末装置１０へ通知する。
（デッキの登録における詳細処理２）
　図１７のステップＳ１２に示す制御部２０３の処理のその他の例を詳細に説明する。詳細処理１では、登録が要求されたデッキが新規である場合に、登録を要求したユーザを作成者としてデッキ情報と紐づけることを説明した。詳細処理２では、デッキの新規作成者として登録されるための条件が複数ある場合を説明する。
　図２２は、デッキを登録する際のサーバ２０の動作の例を示すフローチャートである。
　ステップＳ３１において、サーバ２０の制御部２０３は、管理モジュール２０３３により、登録が要求されたデッキが新規のデッキであるか否かを判断する。全く同一の構成のデッキが存在しない場合、管理モジュール２０３３は、登録要求があったデッキが新規のデッキであると判断し、処理をステップＳ３２へ移行させる。
　ステップＳ３２において、管理モジュール２０３３は、デッキ情報テーブル２０２３に新たなレコードを作成し、作成したレコードにデッキコードを割り当てる。管理モジュール２０３３は、作成したレコードに、要求があったデッキに関する情報を記憶する。管理モジュール２０３３は、例えば、作成したレコードの名称、編成カードを、ユーザから入力される情報に基づいて記憶する。図２２で説明するフローでは、図１９で説明するフローと異なり、管理モジュール２０３３は、ステップＳ３２において、新たに作成したデッキレコードの項目「作成者」と、項目「作成日」に情報を記憶しない。管理モジュール２０３３は、作成したレコードの所定の項目に、デッキの登録を要求してきたユーザに関する情報（例えば、ユーザＩＤ）を記憶する。こうすることで、管理モジュール２０３３は、デッキの登録要求を送信してきたユーザを記憶することが可能となる。
　ステップＳ３３において、送信制御モジュール２０３２は、登録が要求されたデッキが登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、登録が要求されたデッキが新規な構成のデッキであること、デッキを使用することで所定の要件を満たす場合、ユーザがデッキの作成者として対応付けられること、及び登録されたデッキのデッキコードを、登録要求の要求元の端末装置１０へ送信する。
　サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、デッキが新しい編成であること、及び所定の要件を満たすとデッキの作成者としてデッキと対応付けられることをディスプレイ１４１に表示する。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードにデッキコードを関連付ける。これにより、表示制御部１９４は、記憶されているデッキがサーバ２０に登録されているデッキであり、所定の要件を満たすことで作成者として登録されることを表示することが可能となる。
　図２３は、ディスプレイ１４１の表示例を表す模式図である。図２３に示す例では、表示制御部１９４は、デッキが新規のデッキであり、所定の要件を満たすとユーザが作成者として対応付けられることを通知するためのウィンドウ１４１２５を表示する。ウィンドウ１４１２５には、通知を確認したことを入力するためのボタンが表示されていてもよい。
　ステップＳ３１において、登録が要求されたデッキが新規のデッキでない場合、管理モジュール２０３３は、処理をステップＳ２４へ移行させる。
　図２４は、デッキと、デッキの作成者とを対応付ける際のサーバ２０の動作の例を示すフローチャートである。
　ステップＳ４１において、管理モジュール２０３３は、新規のデッキについての使用の条件が満たされたか否かを判断する。具体的には、例えば、管理モジュール２０３３は、デッキ情報テーブル２０２３を参照し、レコードは作成されているが、作成者が記憶されていないデッキについて、項目「対戦情報」の情報を読み出す。管理モジュール２０３３は、読み出した情報がデッキの使用についての所定の条件を満たすか否かを判断する。つまり、管理モジュール２０３３は、登録を要求してきたユーザがデッキを使用することで、所定の条件を満たしたか否かを判断する。本実施形態において、デッキの使用についての所定の条件とは、例えば、以下である。
・デッキを使用した対戦の回数が所定回数に達したこと
・デッキを使用した対戦の勝利数が所定回数に達したこと
・所定の対戦会でのデッキの使用登録
・所定の対戦会への出場回数が所定回数に達したこと
・所定の対戦会のエントリー回数が所定回数に達したこと
・所定の対戦会での所定順位の獲得
・デッキの公開後、登録を要求したユーザ以外のユーザがデッキを使用して上記の条件を達成したこと
　読み出した情報がデッキの使用についての所定の条件を満たす場合、管理モジュール２０３３は、処理をステップＳ４２へ移行させる。
　ステップＳ４２において、管理モジュール２０３３は、所定の使用条件を満たしたデッキについて、デッキ情報テーブル２０２３を更新する。具体的には、例えば、管理モジュール２０３３は、項目「対戦情報」の情報を読み出したレコードの項目「作成者」に、デッキを使用したユーザ、言い換えると、デッキを最初に作成したユーザのユーザＩＤを記憶する。つまり、管理モジュール２０３３は、所定の使用条件を満たしたデッキと、デッキの作成者とを対応付ける。
　ステップＳ４３において、送信制御モジュール２０３２は、ユーザがデッキの作成者として登録されたことを端末装置１０へ通知する。具体的には、送信制御モジュール２０３２は、ユーザがデッキの作成者として登録されたことと、作成者として登録されたデッキのデッキコードとを、デッキの登録要求の要求元の端末装置１０へ送信する。
　サーバ２０からの通知を受信すると、端末装置１０の制御部１９０は、表示制御部１９４により、登録されているデッキに、ユーザが作成者として対応付けられたことをディスプレイ１４１に表示する。表示制御部１９４は、デッキの使用について満たした条件をディスプレイ１４１に表示してもよい。また、制御部１９０は、管理部１９３により、デッキ情報１８３において対応するレコードに、ユーザが作成者になったことを記憶する。これにより、表示制御部１９４は、記憶されているデッキがユーザにより初めて作成されたデッキであることを表示することが可能となる。
　図２５は、ディスプレイ１４１の表示例を表す模式図である。図２５に示す例では、表示制御部１９４は、使用についての条件を満たしたことで、ユーザが作成者として対応付けられたことを通知するためのウィンドウ１４１２６を表示する。なお、ウィンドウ１４１２６における現在形、又は過去形の表現には制限はない。ウィンドウ１４１２６には、通知を確認したことを入力するためのボタン１４１２６１が表示されている。通知内容を確認した場合、ユーザは、確認ボタン１４１２６１を押下する。
　図２５に示す画面においてユーザが確認ボタン１４１２６１を押下すると、表示制御部１９４は、例えば、他ユーザへの公開の選択を受け付けるためのウィンドウを表示する。
　ステップＳ４１において、新規のデッキについての使用の条件が満たされていない場合、制御部２０３は、ステップＳ４１の処理を繰り返す。管理モジュール２０３３は、予め設定した期間において条件が満たされない場合、新規のデッキについてのレコードを削除してもよい。
　（対戦情報テーブルの更新処理）
　サーバ２０の制御部２０３は、管理モジュール２０３３により、デッキが対戦で使用された情報を管理する。
　ユーザは、カード情報１８２で管理されているカードを組み合わせることでデッキを構築する。管理部１９３は、ユーザが構築したデッキに関する情報をデッキ情報１８３で管理している。
　また、ユーザは、自身が構築したデッキをサーバ２０に登録している。具体的には、例えば、ユーザは、上記の「デッキの登録」で示すように端末装置１０を操作することで、自身が構築したデッキをサーバ２０に登録している。
　図２６は、デッキの対戦情報を管理する際の端末装置１０とサーバ２０との動作の例を説明する図である。
　ユーザは、対戦を開始する際に、端末装置１０を用いて、サーバ２０にアクセスする。端末装置１０は、サーバ２０で設定されている、対戦情報の登録フォームをディスプレイ１４１に表示する。ユーザは、ディスプレイ１４１に表示されるフォームを利用し、対戦に関する情報を入力する。対戦に関する情報は、例えば、対戦を実施する日時、対戦者、対戦で使用するデッキに関する情報、大会情報等である。ユーザは、対戦に関する情報を入力すると、対戦情報を登録する要求を端末装置１０に入力する。
　ステップＳ５１において、端末装置１０は、操作受付部１９１により、ユーザから入力された対戦情報の登録要求を受け付ける。端末装置１０は、送受信部１９２により、入力された対戦情報と、登録要求とをサーバ２０へ送信する。
　ステップＳ５２において、サーバ２０は、ユーザから入力された対戦情報に基づいて対戦情報テーブル２０２４を更新する。具体的には、例えば、管理モジュール２０３３は、対戦情報の登録要求がユーザから入力されると、対戦ＩＤを発行し、対戦情報テーブル２０２４に、発行した対戦ＩＤをキーとするレコードを作成する。管理モジュール２０３３は、作成したレコードの日時、対戦者、デッキコード、大会情報を、ユーザから入力される情報に基づいて記憶する。
　日時、対戦者、大会情報は、大会の運営者により事前に入力されていてもよい。この場合、すでに対戦ＩＤは発行されており、対戦情報テーブル２０２４にレコードが作成されている。また、対戦で使用するデッキに関する情報は、ユーザにより事前に登録されてもよい。例えば、大会で利用する予定の複数のデッキが対戦の前に登録されており、ユーザは、対戦の開始時に、登録されているデッキのうちいずれかを選択してもよい。
　ステップＳ５３において、管理モジュール２０３３は、デッキ情報テーブル２０２３を更新する。具体的には、管理モジュール２０３３は、デッキコードにより識別されるデッキのレコードの項目「対戦情報」に、対戦に関する情報、例えば、対戦ＩＤを記憶する。デッキが使用される対戦に関する情報は、参加した大会に関する情報、参加した大会の結果に関する情報等を含んでもよい。対戦情報は、対戦回数が増えると、記憶する情報が増える。これにより、デッキがどの対戦で利用されたかを把握することが可能となる。
　サーバ２０は、デッキ情報テーブル２０２３で管理される情報を端末装置１０へ送信してもよい。具体的には、例えば、対戦情報テーブル２０２４の項目「対戦情報」に新たに対戦ＩＤが記憶された場合、管理モジュール２０３３は、新たに記憶された対戦ＩＤと、デッキに関連付けられているユーザＩＤとを読み出す。送信制御モジュール２０３２は、読み出した対戦ＩＤを、ユーザＩＤにより識別されるユーザが所有する端末装置１０へ送信する。
　端末装置１０は、サーバ２０から送信される情報を受信し、受信した情報に基づき、デッキ情報１８３を更新する。具体的には、例えば、端末装置１０は、管理部１９３により、デッキコードにより特定されるレコードの項目「対戦情報」に、サーバ２０から受信した対戦情報、例えば、対戦ＩＤを記憶する。これにより、表示制御部１９４は、ユーザに対し、デッキを使用した情報を表示することが可能となる。
　対戦が開始されると、制御部２０３は、対戦処理モジュール２０３５により、プレイヤ同士の対戦処理を制御する。対戦処理モジュール２０３５は、対戦中にプレイヤが採用した手に関する情報を記憶部２０２に記憶する。管理モジュール２０３３は、対戦中にプレイヤが採用した手に関する情報を、対戦情報テーブル２０２４に対戦ログ情報として記憶する。対戦処理モジュール２０３５は、対戦が終了すると、対戦に勝ったプレイヤを勝者として認定する。管理モジュール２０３３は、勝者を対戦情報テーブル２０２４に記憶する。
　（特典付与処理）
　付与モジュール２０３４は、特典情報テーブル２０２５に基づき、ユーザに特典を付与する。
　具体的には、例えば、付与モジュール２０３４は、デッキに関する情報が、特典情報テーブル２０２５で設定される条件を充足するか否かを判断する。特典情報テーブル２０２５で設定される条件は、例えば、以下である。
・登録されているデッキが他ユーザに貢献した度合が所定の条件を満たしていること
・ユーザが他ユーザに貢献した度合が所定の条件を満たしている
　具体的には、例えば、付与モジュール２０３４は、特典情報テーブル２０２５に基づき、登録されているデッキが他ユーザに貢献した度合が所定値に達した場合、デッキを最初に作成したユーザ（作成者として登録されているユーザ）に特典を付与する。デッキが他ユーザに貢献した度合は、例えば、他ユーザがデッキを閲覧した閲覧回数、他ユーザがデッキを参照した参照回数、他ユーザがデッキを登録した登録回数、他ユーザがデッキを使用した使用回数等を含む。
　また、付与モジュール２０３４は、特典情報テーブル２０２５に基づき、ユーザが他ユーザに貢献した度合が所定値に達した場合、当該ユーザに特典を付与する。ユーザが他ユーザに貢献した度合は、例えば、新規のデッキを作成した回数、他ユーザからフォローされている人数等を含む。
　特典情報テーブル２０２５において、条件毎に所定の特典内容が設定されている。特典内容は、例えば、以下である。
　・カードの提供
　・オリジナルカードを作成できる権利の付与
　・カードの抽選権の付与
　・対戦における有利な効果
　・カードの抽選における有利な効果
　サーバ２０は、登録されているデッキが他ユーザに貢献した度合を、ユーザ又は他ユーザに提示してもよい。具体的には、送信制御モジュール２０３２は、ユーザ又は他ユーザからの要求に応じ、登録されているデッキが他ユーザに貢献した度合に関する情報を要求元の端末装置１０へ送信する。端末装置１０は、受信した情報に基づき、貢献した度合をディスプレイ１４１に表示させる。これによりユーザは、特典を付与されるまでの貢献度を把握することが可能となる。また、他ユーザは、どれほど他者に役立っているデッキかを認識することが可能となる。
　また、サーバ２０は、ユーザが他ユーザに貢献した度合を、ユーザ又は他ユーザに提示してもよい。具体的には、送信制御モジュール２０３２は、ユーザ又は他ユーザからの要求に応じ、ユーザが他ユーザに貢献した度合に関する情報を要求元の端末装置１０へ送信する。端末装置１０は、受信した情報に基づき、貢献した度合をディスプレイ１４１に表示させる。これによりユーザは、特典を付与されるまでの貢献度を把握することが可能となる。また、他ユーザは、どれほど効果的なデッキを作成しているユーザかを認識することが可能となる。
　（デッキ情報の表示）
　端末装置１０は、ユーザからの指示に応じ、サーバ２０で登録されているデッキの一覧を表示する。端末装置１０の制御部１９０は、表示制御部１９４により、デッキ情報テーブル２０２３に基づき、登録されているデッキの一覧をディスプレイ１４１に表示する。
　図２７は、ディスプレイ１４１の表示例を表す模式図である。図２７において、表示制御部１９４は、領域１４１１と、領域１４１３とを表示する。領域１４１１は、表示条件等を記載する領域である。領域１４１３は、領域１４１１で記載される表示条件に則った態様で、登録されているデッキを表示する領域である。
　図２７に示す例では、領域１４１１に、表示条件として、表示順が表示されている。表示順は、順序の規則を表す。表示順は、例えば、番号順、名称順、レアリティ順、取得日付順等のうちからユーザにより選択される。表示順は、ユーザからの指示に基づき、例えば、番号順から、名称順、レアリティ順、取得日付順等に切り替えることが可能である。図２７に示す例では、「表示順：名称順」となっており、領域１４１３に、デッキが、デッキの名称の並び順で配列されている。
　表示制御部１９４は、領域１４１３に表示されるデッキがユーザにより選択されると、選択されたデッキを構築するカードの一覧をディスプレイ１４１に表示する。
　以上のように、上記実施形態では、サーバ２０の制御部２０３は、受信制御モジュール２０３１により、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける。制御部２０３は、管理モジュール２０３３により、登録を要求されたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断する。管理モジュール２０３３は、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録する。管理モジュール２０３３は、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含める。これにより、初めて作成されたデッキであることを含む所定の条件を満たしたデッキが、作成者と共に登録される。このため、プレイヤは自身の名前がデッキと共に登録されるように、デッキの作成に励むようになる。
　したがって、本実施形態に係るプログラムによれば、プレイヤがデッキを作成する興趣性を向上させることができる。
　また、上記実施形態では、管理モジュール２０３３は、所定の条件に、初めて作成されたデッキの使用に関する条件を含む。これにより、デッキを作成したのみでは、プレイヤが登録されず、作成したデッキを実際に使用した場合にプレイヤが登録されるようになる。このため、デッキを登録させることのみを目的としてデッキを作成した場合には、プレイヤが登録されない。つまり、実際に使用され得る、他プレイヤにとって価値のあるデッキの情報がプレイヤと共に登録されることになる。
　また、上記実施形態では、管理モジュール２０３３は、初めて作成されたデッキの使用に関する条件に、デッキが使用された対戦の回数、デッキが使用された対戦の勝利数、所定の対戦会へのデッキのエントリー回数、又は所定の対戦会でのデッキを使用した第１プレイヤの所定順位の獲得を少なくとも含む。これにより、実用性のある使用条件を満たした場合に、デッキと共にプレイヤが登録されるようになる。
　また、上記実施形態では、管理モジュール２０３３は、所定のプレイヤにより作成されたデッキが登録されると、当該プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知する。これにより、新たなデッキを作成することに長けたプレイヤ、又は有名なプレイヤが作成するデッキを追跡することが可能となり、デッキ作成のトレンドを把握することが可能となる。
　また、上記実施形態では、付与モジュール２０３４は、登録されたデッキが第２プレイヤ（他プレイヤ）に貢献した度合に基づいて第１プレイヤ（デッキの作成者）に特典を付与する。これにより、他プレイヤに役に立つデッキを作成する動機となり得る。
　また、上記実施形態では、付与モジュール２０３４は、第１プレイヤ（デッキの作成者）が第２プレイヤ（他プレイヤ）に貢献した度合に基づいて第１プレイヤに特典を付与する。これにより、新たなデッキを多く作成した第１プレイヤは特典を受けることが可能となり、デッキを作成する動機となり得る。
　＜変形例＞
　上記実施形態では、ユーザ情報テーブル２０２１、カードマスタテーブル２０２２、デッキ情報テーブル２０２３、対戦情報テーブル２０２４、特典情報テーブル２０２５がサーバ２０に記憶される場合を説明した。しかしながら、これらのテーブルで記憶される情報は、サーバ２０に記憶されていなくてもよい。例えば、少なくともデッキ情報テーブル２０２３で記憶されるデッキ情報は、Ｐ２Ｐのコンピュータネットワークにより形成されるブロックチェーン（分散型台帳）に記憶されてもよい。
　このとき、デジタルカードのそれぞれは、ノンファンジブルトークン（ＮＦＴ）としてブロックチェーンにおいて取引される。上記実施形態において、ＮＦＴには、例えば、ＮＦＴを識別するための固有の識別子（ＮＦＴ－ＩＤ）が割り当てられる。なお、デッキのそれぞれがＮＦＴとしてブロックチェーンにおいて取引されてもよい。
　ＮＦＴに対する取引は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。ＮＦＴについての取引履歴はトランザクションとしてブロックチェーンに記憶される。これにより、ＮＦＴの所有者の履歴がブロックチェーンに記憶される。
　また、ＮＦＴの使用に関する管理は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。ＮＦＴの使用履歴は、トランザクションとしてブロックチェーンに記憶される。これにより、ＮＦＴを対戦で使用した履歴がブロックチェーンに記憶される。
　また、デッキを作成したことによる特典の付与は、例えば、ブロックチェーンに実装されるスマートコントラクトにより実行される。これにより、デッキの作成に関する履歴が所定の要件を満たすと、デッキの作成者に所定の特典が付与される。
　このように、サーバ２０の制御部２０３は、管理モジュール２０３３により、デッキに関する情報を、コンピュータネットワークにより形成される分散型台帳に記憶する。つまり、デッキを構築する複数のデジタルカードに関する情報と、第１プレイヤに関する情報とを分散型台帳に記憶する。なお、端末装置１０の制御部１９０が、管理部１９３により、デッキに関する情報を、コンピュータネットワークにより形成される分散型台帳に記憶してもよい。これにより、デッキをＮＦＴとして扱うことが可能となる。また、新規に作成されるデッキについて公明な記録を残すことが可能となる。
　上記実施形態では、サーバ２０が対戦情報テーブル２０２４を記憶している場合を説明した。ユーザ自身の対戦情報は、端末装置１０の記憶部１８０に記憶されてもよい。管理部１９３は、記憶部１８０に記憶される対戦情報に基づき、デッキ情報１８３における対戦情報を更新してもよい。送受信部１９２は、デッキ情報１８３が更新されると、デッキに関する情報をサーバ２０へ送信する。サーバ２０の管理モジュール２０３３は、端末装置１０から送信された情報に基づき、デッキ情報テーブル２０２３を更新する。これにより、端末装置１０において、対戦情報を把握することが可能となる。
　上記実施形態では、デッキが新しいと、当該デッキに関する情報がデッキ情報テーブル２０２３に記憶されるようにしている。しかしながら、デッキが新しいとの条件のみを満たす場合において、デッキに関する情報がデッキ情報テーブル２０２３に記憶されないようにしてもよい。例えば、管理モジュール２０３３は、デッキが新しく、かつ、デッキがその他の条件を満たした場合に、デッキ情報テーブル２０２３に情報を記憶するようにしてもよい。この場合、例えば、管理モジュール２０３３は、新しいと判断したデッキに関する情報を、デッキ情報テーブル２０２３以外の所定の記憶領域に記憶し、例えば、デッキの使用に関する条件を満たした場合に、デッキ情報テーブル２０２３に情報を記憶する。
　上記実施形態では、デッキを最初に登録したユーザが作成者として登録される場合を説明した。しかしながら、作成者として登録されるのは、デッキを最初に登録したユーザのみに限定されない。例えば、管理モジュール２０３３は、作成者として登録するユーザに幅を持たせてもよい。つまり、最初にデッキを登録したユーザに加え、早期にデッキの強さに気が付き、何らかの形で名声を得たユーザも作成者として登録してもよい。こうすると、「作成者」は、自身で名声を取得した者であり、「登録者」は、「作成者」の知恵からの恩恵を得た者と区分することが可能である。具体的には、例えば、管理モジュール２０３３は、デッキについて登録を申請してきた先着Ｘ人のユーザを作成者としても登録する。また、管理モジュール２０３３は、デッキについて登録を申請してきたユーザのうち、先に申請してきた上位Ｘ％のユーザを作成者としてもよい。
　＜４　コンピュータの基本ハードウェア構成＞
　図２８は、コンピュータ９０の基本的なハードウェア構成を示すブロック図である。コンピュータ９０は、プロセッサ９１、主記憶装置９２、補助記憶装置９３、通信ＩＦ９９（インタフェース、Interface）を少なくとも備える。これらはバスにより相互に電気的に接続される。
　プロセッサ９１とは、プログラムに記述された命令セットを実行するためのハードウェアである。プロセッサ９１は、演算装置、レジスタ、周辺回路等から構成される。
　主記憶装置９２とは、プログラム、及びプログラム等で処理されるデータ等を一時的に記憶するためのものである。例えば、ＤＲＡＭ（Dynamic Random Access Memory）等の揮発性のメモリである。
　補助記憶装置９３とは、データ及びプログラムを保存するための記憶装置である。例えば、フラッシュメモリ、ＨＤＤ（Hard Disc Drive）、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等である。
　通信ＩＦ９９とは、有線又は無線の通信規格を用いて、他のコンピュータとネットワークを介して通信するための信号を入出力するためのインタフェースである。
　ネットワークは、インターネット、ＬＡＮ、無線基地局等によって構築される各種移動通信システム等で構成される。例えば、ネットワークには、３Ｇ、４Ｇ、５Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えば、Ｗｉ－Ｆｉ（登録商標））等が含まれる。無線で接続する場合、通信プロトコルとして例えば、Ｚ－Ｗａｖｅ（登録商標）、ＺｉｇＢｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等が含まれる。有線で接続する場合は、ネットワークには、ＵＳＢ（Universal Serial Bus）ケーブル等により直接接続するものも含む。
　なお、各ハードウェア構成の全部または一部を複数のコンピュータ９０に分散して設け、ネットワークを介して相互に接続することによりコンピュータ９０を仮想的に実現することができる。このように、コンピュータ９０は、単一の筐体、ケースに収納されたコンピュータ９０だけでなく、仮想化されたコンピュータシステムも含む概念である。
　＜コンピュータ９０の基本機能構成＞
　図２８に示すコンピュータ９０の基本ハードウェア構成により実現されるコンピュータの機能構成を説明する。コンピュータは、制御部、記憶部、通信部の機能ユニットを少なくとも備える。
　なお、コンピュータ９０が備える機能ユニットは、それぞれの機能ユニットの全部または一部を、ネットワークで相互に接続された複数のコンピュータ９０に分散して設けても実現することができる。コンピュータ９０は、単一のコンピュータ９０だけでなく、仮想化されたコンピュータシステムも含む概念である。
　制御部は、プロセッサ９１が補助記憶装置９３に記憶された各種プログラムを読み出して主記憶装置９２に展開し、当該プログラムに従って処理を実行することにより実現される。制御部は、プログラムの種類に応じて様々な情報処理を行う機能ユニットを実現することができる。これにより、コンピュータは情報処理を行う情報処理装置として実現される。
　記憶部は、主記憶装置９２、補助記憶装置９３により実現される。記憶部は、データ、各種プログラム、各種データベースを記憶する。また、プロセッサ９１は、プログラムに従って記憶部に対応する記憶領域を主記憶装置９２または補助記憶装置９３に確保することができる。また、制御部は、各種プログラムに従ってプロセッサ９１に、記憶部に記憶されたデータの追加、更新、削除処理を実行させることができる。
　データベースは、リレーショナルデータベースを指し、行と列によって構造的に規定された表形式のテーブルと呼ばれるデータ集合を、互いに関連づけて管理するためのものである。データベースでは、表をテーブル、表の列をカラム、表の行をレコードと呼ぶ。リレーショナルデータベースでは、テーブル同士の関係を設定し、関連づけることができる。
　通常、各テーブルにはレコードを一意に特定するためのキーとなるカラムが設定されるが、カラムへのキーの設定は必須ではない。制御部は、各種プログラムに従ってプロセッサ９１に、記憶部に記憶された特定のテーブルにレコードを追加、削除、更新を実行させることができる。
　通信部は、通信ＩＦ９９により実現される。通信部は、ネットワークを介して他のコンピュータ９０と通信を行う機能を実現する。通信部は、他のコンピュータ９０から送信された情報を受信し、制御部へ入力することができる。制御部は、各種プログラムに従ってプロセッサ９１に、受信した情報に対する情報処理を実行させることができる。また、通信部は、制御部から出力された情報を他のコンピュータ９０へ送信することができる。
　以上、本開示のいくつかの実施形態を説明したが、これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものとする。
　＜付記＞
　以上の各実施形態で説明した事項を以下に付記する。
　（付記１）
　プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、プログラムは、プロセッサに、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行させるプログラム。
　（付記２）
　判断するステップにおいて、所定の条件は、初めて作成されたデッキの使用に関する条件を含む（付記１）に記載のプログラム。
　（付記３）
　初めて作成されたデッキの使用に関する条件は、デッキが使用された対戦の回数、デッキが使用された対戦の勝利数、所定の対戦会へのデッキのエントリー回数、又は所定の対戦会でのデッキを使用した第１プレイヤの所定順位の獲得の少なくともいずれか一つの条件を含む（付記２）に記載のプログラム。
　（付記４）
　登録するステップにおいて、デッキを構築する複数のデジタルカードに関する情報と第１プレイヤに関する情報とを、コンピュータネットワークにより形成される分散型台帳に記憶する（付記１）乃至（付記３）のいずれかに記載のプログラム。
　（付記５）
　所定のプレイヤにより作成されたデッキが登録されると、プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知するステップをプロセッサに実行させる（付記１）乃至（付記４）のいずれかに記載のプログラム。
　（付記６）
　登録されたデッキが第２プレイヤに貢献した度合に基づいて第１プレイヤに特典を付与するステップをプロセッサに実行させる（付記１）乃至（付記５）のいずれかに記載のプログラム。
　（付記７）
　第１プレイヤが第２プレイヤに貢献した度合に基づいて第１プレイヤに特典を付与するステップをプロセッサに実行させる（付記１）乃至（付記６）のいずれかに記載のプログラム。
　（付記８）
　プロセッサと、メモリとを備えるコンピュータに実行される方法であって、プロセッサが、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行する方法。
　（付記９）
　制御部と、記憶部とを備える情報処理装置であって、制御部が、第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録するステップと、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含めるステップとを実行する情報処理装置。
　（付記１０）
　第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける手段と、登録する要求を第１プレイヤから受け付けたデッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、所定の条件を満たす場合、デッキを、デッキを初めて作成した第１プレイヤと関連付けて登録する手段と、登録したデッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、デッキに関する情報に、デッキを作成した第１プレイヤに関する情報を含める手段とを具備するシステム。
１…システム
１０…端末装置
１２…通信ＩＦ
１２０…通信部
１３…入力装置
１３１…タッチ・センシティブ・デバイス
１４…出力装置
１４１…ディスプレイ
１５…メモリ
１５０…位置情報センサ
１６…ストレージ
１６０…カメラ
１７…音声処理部
１７１…マイク
１７２…スピーカー
１８０…記憶部
１９…プロセッサ
１９０…制御部
２０…サーバ

Claims (10)

  1. 　プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
    　第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
    　登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、
    　前記所定の条件を満たす場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
    　登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを作成した前記第１プレイヤに関する情報を含めるステップと
    を実行させるプログラム。
  2. 　前記判断するステップにおいて、前記所定の条件は、初めて作成された前記デッキの使用に関する条件を含む請求項１記載のプログラム。
  3. 　前記初めて作成された前記デッキの使用に関する条件は、前記デッキが使用された対戦の回数、前記デッキが使用された対戦の勝利数、所定の対戦会への前記デッキのエントリー回数、又は所定の対戦会での前記デッキを使用した前記第１プレイヤの所定順位の獲得の少なくともいずれか一つの条件を含む請求項２記載のプログラム。
  4. 　前記登録するステップにおいて、前記デッキを構築する複数のデジタルカードに関する情報と前記第１プレイヤに関する情報とを、コンピュータネットワークにより形成される分散型台帳に記憶する請求項１乃至請求項３のいずれかに記載のプログラム。
  5. 　所定のプレイヤにより作成されたデッキが登録されると、前記プレイヤが作成したデッキが新たに登録されたことを他プレイヤに通知するステップを前記プロセッサに実行させる請求項１乃至請求項４のいずれかに記載のプログラム。
  6. 　登録されたデッキが前記第２プレイヤに貢献した度合に基づいて前記第１プレイヤに特典を付与するステップを前記プロセッサに実行させる請求項１乃至請求項５のいずれかに記載のプログラム。
  7. 　前記第１プレイヤが前記第２プレイヤに貢献した度合に基づいて前記第１プレイヤに特典を付与するステップを前記プロセッサに実行させる請求項１乃至請求項６のいずれかに記載のプログラム。
  8. 　プロセッサと、メモリとを備えるコンピュータに実行される方法であって、前記プロセッサが、
    　第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
    　登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、
    　前記所定の条件を満たす場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
    　登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを作成した前記第１プレイヤに関する情報を含めるステップと
    を実行する方法。
  9. 　制御部と、記憶部とを備える情報処理装置であって、前記制御部が、
    　第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付けるステップと、
    　登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、
    　前記所定の条件を満たす場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録するステップと、
    　登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを作成した前記第１プレイヤに関する情報を含めるステップと
    を実行する情報処理装置。
  10. 　第１プレイヤから、複数のデジタルカードを組み合わせて作成したデッキを登録する要求を受け付ける手段と、
    　登録する要求を前記第１プレイヤから受け付けた前記デッキが、初めて作成されたデッキであることを含む所定の条件を満たすか判断するステップと、
    　前記所定の条件を満たす場合、前記デッキを、前記デッキを初めて作成した前記第１プレイヤと関連付けて登録する手段と、
    　登録した前記デッキに関する情報に対して、第２プレイヤからのアクセスを可能とし、前記デッキに関する情報に、前記デッキを作成した前記第１プレイヤに関する情報を含める手段と
    を具備するシステム。

     
PCT/JP2023/037798 2022-10-27 2023-10-19 プログラム、方法、情報処理装置、システム WO2024090316A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-172296 2022-10-27
JP2022172296A JP7455176B1 (ja) 2022-10-27 2022-10-27 プログラム、方法、情報処理装置、システム

Publications (1)

Publication Number Publication Date
WO2024090316A1 true WO2024090316A1 (ja) 2024-05-02

Family

ID=90367075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/037798 WO2024090316A1 (ja) 2022-10-27 2023-10-19 プログラム、方法、情報処理装置、システム

Country Status (2)

Country Link
JP (2) JP7455176B1 (ja)
WO (1) WO2024090316A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019180940A (ja) * 2018-04-12 2019-10-24 株式会社 ディー・エヌ・エー 情報処理装置、ゲームプログラム、及び、情報処理方法
JP2020031846A (ja) * 2018-08-29 2020-03-05 株式会社セガゲームス 情報処理装置、プログラム及び情報処理システム
JP2021040904A (ja) * 2019-09-10 2021-03-18 株式会社カプコン コンピュータプログラム、およびコンピュータ装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019180940A (ja) * 2018-04-12 2019-10-24 株式会社 ディー・エヌ・エー 情報処理装置、ゲームプログラム、及び、情報処理方法
JP2020031846A (ja) * 2018-08-29 2020-03-05 株式会社セガゲームス 情報処理装置、プログラム及び情報処理システム
JP2021040904A (ja) * 2019-09-10 2021-03-18 株式会社カプコン コンピュータプログラム、およびコンピュータ装置

Also Published As

Publication number Publication date
JP7455176B1 (ja) 2024-03-25
JP2024070277A (ja) 2024-05-22
JP2024064019A (ja) 2024-05-14

Similar Documents

Publication Publication Date Title
KR101451165B1 (ko) 게임 시스템
KR100742129B1 (ko) 온라인 고스톱 게임 시스템 및 고스톱 게임 제공 방법
US11497998B2 (en) Video game in which groups of players earn reward boxes
JP6757982B2 (ja) ゲーム装置、及びプログラム
JP2022168334A (ja) ゲームプログラム、ゲーム装置、ゲームシステム
JP6970445B2 (ja) ゲームシステム、及びプログラム
JP2015044035A (ja) ゲームシステム
JP2019177037A (ja) サーバシステム及びゲームシステム
WO2024090316A1 (ja) プログラム、方法、情報処理装置、システム
JP5513664B1 (ja) プログラム、及びソーシャルゲームシステムの制御方法
JP7510475B2 (ja) プログラム、方法、情報処理装置、システム
WO2024111307A1 (ja) プログラム、方法、情報処理装置、及びシステム
JP2015006310A (ja) プログラム、及びソーシャルゲームシステムの制御方法
JP2022049195A (ja) コンピュータプログラム、およびコンピュータ装置
JP2021122522A (ja) コンピュータプログラム、およびコンピュータ装置
JP6947583B2 (ja) 携帯端末の制御プログラム、携帯端末の制御方法及び携帯端末
JP7477702B2 (ja) プログラム、情報処理装置、及び情報処理方法
WO2024090317A1 (ja) プログラム、方法、情報処理装置、システム
JP6887005B2 (ja) コンピュータプログラム、およびコンピュータ装置
JP7386953B1 (ja) プログラム、方法、情報処理装置、システム
JP7369980B2 (ja) ゲーム制御方法、コンピュータ及び制御プログラム
JP2024081167A (ja) プログラム、方法、情報処理装置、及びシステム
JP6943991B2 (ja) 制御方法、コンピュータ及び制御プログラム
JP2024096449A (ja) 情報処理装置
JP2024096446A (ja) 情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23882521

Country of ref document: EP

Kind code of ref document: A1