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/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/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/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)

Priority Applications (1)

Applications Claiming Priority (2)

Related Child Applications (1)

Publications (1)

Family

ID=90367075

Family Applications (1)

Country Status (3)

Citations (3)

• 2022
  • 2022-10-27 JP JP2022172296A patent/JP7455176B1/ja active Active
• 2023
  • 2023-10-19 WO PCT/JP2023/037798 patent/WO2024090316A1/ja not_active Ceased
• 2024
  • 2024-03-12 JP JP2024037817A patent/JP2024070277A/ja active Pending
• 2025
  • 2025-04-24 US US19/188,043 patent/US20250249368A1/en active Pending

Patent Citations (3)

Also Published As

Similar Documents

Legal Events