Game object management system, apparatus, method, and program

Abstract

To handle a game object possessed by a user as a unique object.SOLUTION: A game object management system for managing game objects used in a game, the game object management system including first management means for managing game objects that do not satisfy a predetermined requirement among game objects possessed by a user, using first identification information given to each type of the game objects and the number of the game objects, and second management means for managing game objects that satisfy the predetermined requirement among the game objects possessed by the user, using second identification information given to each game object.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a game object management system, device, method, and program. [Background technology]

[0002] In recent years, network systems have been provided that issue non-fungible tokens (NFTs) of in-game digital content and record transactions on the blockchain. Patent document 1 discloses a technology relating to the trading of digital content within a game, in which, for the purpose of controlling the circulation of game media, an information processing device has a granting unit that grants to a user a first right selected by lottery from one or more types of rights, the game media being the subject of the right, and a change unit that, when the user uses the first right, changes the first game media that is the subject of the first right from a first state in which it cannot be traded with other users to a second state in which it can be traded with other users in a first trading system.

[0003] Furthermore, as a technology relating to the management of digital cards in a digital TCG (Trading Card Game), Patent Document 2 discloses a configuration in which information relating to a plurality of digital cards is stored in a manner that allows each of the same digital cards to be uniquely identified. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 7428926 [Patent Document 2] Patent No. 7510475 Summary of the Invention [Problem to be solved by the invention]

[0005] In order to manage game objects used in a game, identification information is assigned to each type of game object, that is, the same identification information is assigned to game objects of the same type. In this case, convenience would be improved if some of the game objects owned by a user could be treated as unique objects. For example, to realize the above-mentioned NFT-based transactions, it is necessary to enable the game objects owned by a user to be treated as unique objects.

[0006] The present invention has been made in consideration of the above-mentioned problems, and has as its object to enable game objects possessed by a user to be treated as unique objects. [Means for solving the problem]

[0007] The game object management system of the present invention is a game object management system that manages game objects used in a game, and is characterized by comprising a first management means that manages game objects owned by a user that do not satisfy specified requirements using first identification information and a number assigned to each type of game object, and a second management means that manages game objects owned by the user that satisfy the specified requirements using second identification information assigned to each game object. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an example of the configuration of a network system. [Figure 2] FIG. 10 is a diagram showing a game progression screen. [Figure 3] FIG. 10 is a diagram illustrating a card. [Figure 4] FIG. 2 is a diagram illustrating a functional configuration of a server device. [Figure 5] FIG. 2 is a diagram illustrating a functional configuration of a server device. [Figure 6] FIG. 10 is a diagram for explaining management of normal cards and special cards. [Figure 7] FIG. 10 is a diagram for explaining management of normal cards and special cards. [Figure 8] FIG. 10 is a diagram illustrating management of NFT cards. [Figure 9] FIG. 10 is a diagram illustrating an example of history information. [Figure 10] FIG. 10 is a diagram illustrating an example of a condition that allows a used finish to be applied. [Figure 11] FIG. 10 is a diagram showing a selection screen. [Figure 12] FIG. 10 is a diagram showing a card list screen. [Figure 13] FIG. 10 is a diagram showing an enlarged display screen. [Figure 14] FIG. 10 is a diagram showing a possession details screen. [Figure 15] FIG. 10 is a diagram showing an exchange screen. [Figure 16] FIG. 10 is a diagram showing an enlarged display screen. [Figure 17] FIG. 10 shows a special card list screen. [Figure 18] FIG. 10 is a diagram showing an enlarged display screen. [Figure 19] FIG. 10 shows a special card list screen. [Figure 20] 10 is a flowchart illustrating an example of processing by the network system. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. [Network system configuration] FIG. 1 is a diagram showing an example of the configuration of a network system NS according to this embodiment. In the network system NS, the terminal device 10, the server device 30, and the server device 40 are connected to each other via a network 20 in a wired or wireless manner so as to be able to transmit and receive data to and from each other. The network system NS functions as a game object management system to which the present invention is applied.

[0010] The server device 30 provides a service of a game using card objects (hereinafter referred to as a "card game"). A card object is a card-shaped item that exists in a virtual space. Hereinafter, it will be abbreviated as "card". A user uses a terminal device 10 to play the card game provided by the server device 30.

[0011] The server device 40 provides an NFT marketplace service for trading digital assets that utilize NFTs. Hereinafter, when an NFT corresponding to a digital asset is issued and managed on a blockchain, it is referred to as being NFTized. In this embodiment, cards used in a card game provided by the server device 30 are NFTized so that they can be traded on the NFT marketplace. Users use the terminal device 10 to access the NFT marketplace provided by the server device 40.

[0012] The terminal device 10 is configured, for example, as a home game console, a portable communication device such as a smartphone, a portable game console, a personal computer, a tablet, etc. The terminal device 10 includes a CPU 11, a ROM 12, a RAM 13, a communication unit 14, an operation unit 15, a display unit 16, and a storage device 17. Note that while only one terminal device 10 is shown in FIG. 1, multiple terminal devices exist on the network system NS. The hardware configurations of these terminal devices (not shown) are the same as the hardware configuration of the terminal device 10.

[0013] The CPU 11 reads out a control program stored in the ROM 12 into the RAM 13 and executes various processes. The ROM 12 stores a control program (such as an OS) required to operate the terminal device 10. A flash memory (NVRAM) may be used instead of the ROM 12. The RAM 13 is used as a temporary storage area such as the main memory or work area of ​​the CPU 11. The communication unit 14 performs communication processing with the server devices 30, 40 and other external devices via the network 20. The operation unit 15 accepts various operations by the user, and corresponds to, for example, a controller attached to a home game console or a touch panel mounted on the display unit 16. The display unit 16 displays various information such as game screens. The storage device 17 mainly stores game programs related to games, various data related to games, programs related to trading NFT cards, and various data related to trading NFT cards.

[0014] The functions and processes of the terminal device 10 are realized by the CPU 11 reading a program stored in the ROM 12 or the storage device 17 and executing the program. As another example, the CPU 11 may read a program stored in a removable storage medium such as an SD card, rather than reading a program stored in the ROM 12 or the like. The means for supplying the program to the computer may be a computer-readable storage medium such as a CD-ROM storing the program, or a transmission medium such as the Internet for transmitting the program.

[0015] The server device 30 includes a CPU 31, a ROM 32, a RAM 33, a communication unit 34, and a storage device 35. The CPU 31 reads out a control program stored in the ROM 32 into the RAM 33 and executes various processes. The ROM 32 stores a control program (such as an OS) required to operate the server device 30. A flash memory (NVRAM) may be used instead of the ROM 32. The RAM 33 is used as a temporary storage area such as the main memory and work area of ​​the CPU 31. The communication unit 34 performs communication processing with the terminal device 10 and other external devices via the network 20. The storage device 35 stores programs related to the game, user identification information such as the ID of the user operating the terminal device 10, and various other information for each user required for the game. Note that some of this information may be stored in a database (not shown) or the like.

[0016] The server device 40 includes a CPU 41, a ROM 42, a RAM 43, a communication unit 44, and a storage device 45. The CPU 41 reads out the control program stored in the ROM 42 into the RAM 43 and executes various processes. The ROM 42 stores the control program (such as an OS) required to operate the server device 40. A flash memory (NVRAM) may be used instead of the ROM 42. The RAM 43 is used as a temporary storage area such as the main memory and work area of ​​the CPU 41. The communication unit 44 performs communication processing with the terminal device 10 and other external devices via the network 20. The storage device 45 stores programs related to transactions of NFT-enabled cards, user identification information such as the ID of the user operating the terminal device 10, and various other information for each user required for transactions of NFT-enabled cards. Note that some of this information may be stored in a database (not shown) or the like.

[0017] [Card game description] An overview of the card game in this embodiment will be described. 2 is a diagram showing a game progress screen G1 displayed on the display unit 16 of the terminal device 10. The game progress screen G1 is displayed when a user uses the terminal device 10 to play a card game provided by the server device 30. The area AR1 in the lower half of the game progression screen G1 displays the user's own hand PAT (hereinafter also referred to as "your hand PAT") and the user's own field PAB (hereinafter also referred to as "your field PAB"). Meanwhile, the area AR2 in the upper half displays the opponent's hand PBT (hereinafter also referred to as "opponent's hand PBT") and the opponent's field PBB (hereinafter also referred to as "opponent's field PBB"). The user's hand PAT and their field PAB are displayed facing the opponent's hand PBT and their field PBB. The user's cards and the opponent's cards are arranged and displayed in the user's hand PAT and their field PAB and the opponent's hand PBT and their field PBB, respectively.

[0018] This card game is a turn-based battle game in which the user and the opponent alternate turns, with the user selecting cards and commands on their turn and the opponent selecting cards and commands on their turn. In this type of card game, the battle is called a duel.

[0019] First, a user prepares a deck, which is a set of cards consisting of a predetermined number of cards arbitrarily combined from cards owned by the user, and multiple cards included in this deck are placed face down in a random order as a deck on the user's field PAB. Specifically, the deck is placed in an area PA1 within the user's field PAB. Next, during the user's turn, a predetermined number of cards drawn from the deck in a random order become the user's hand. These hand cards are placed in the user's hand PAT. Here, the cards placed in the user's hand PAT are placed face up so that the user can see the front side, which lists the card's type and parameters. On the other hand, the cards placed in the opponent's hand PBT are placed face down so that the user cannot see the front side of the card. Furthermore, from the second time onwards, the user can draw one card from the deck each time it is their turn to make it their hand.

[0020] The game progresses by the user placing cards from their hand PAT onto their field PAB to activate the effects of each card, or by comparing the power of cards previously placed on their field PAB with the power of cards on their opponent's field PBB. The user and opponent each start with a certain number of life points (LP), and each player reduces their LP according to certain rules based on card selections and command executions. The first player to reduce their opponent's LP to 0 wins.

[0021] Here, summoning refers to placing a card from your hand (PAT) onto your field (PAB). There are three types of cards: monster cards, spell cards, and trap cards.

[0022] Depending on the type of card, the location on your field PAB where it can be placed by summoning is determined. Area PA2 is where monster cards can be placed. This area PA2 has three areas PA2(1), PA2(2), and PA2(3), each of which can contain one monster card, allowing up to three monster cards to be placed at the same time. In the example shown in Figure 2, of the areas PA2(1), PA2(2), and PA2(3), only area PA2(2) contains monster cards. Area PA3 is where magic cards and trap cards can be placed. This area PA3 has three areas PA3(1), PA3(2), and PA3(3), each of which can contain one magic card or trap card, allowing up to three magic cards and trap cards to be placed at the same time. In the example shown in Figure 2, of the areas PA3(1), PA3(2), and PA3(3), only area PA3(1) contains a magic card or trap card. Area PA4 is where monster cards destroyed by attacks and used spell and trap cards are placed (called the "Graveyard"), and area PA5 is where cards that can be Special Summoned (called the "Extra Area") are placed.

[0023] Monster cards have parameters such as attack power, which is referenced when executing an action based on the attack command (described below), and defense power, which is referenced when the opponent executes an action based on the attack command. Monster cards also come in two types: monster cards with effects that can give you an advantage in a battle by executing an action based on the monster effect command (described below), and monster cards without effects.

[0024] FIG. 3(a) is a diagram for explaining a monster card C1, and shows a schematic example of its front side. The front side of the monster card C1 has a name area C12, an illustration area C13, and a text area C14 arranged inside a frame C11. The name area C12 contains the name of the monster, which will become the card's name. The level C15 indicates the monster's level (rank). The illustration area C13 contains an illustration of the monster. The text area C14 contains the monster's species, monster profile, and card effects and usage. ATK represents attack power, and DEF represents defense power; the higher these values, the greater the advantage in battle.

[0025] Spell and trap cards execute actions based on the Spell and Trap Commands described below, resulting in effects such as performing specific actions, restricting actions the opponent is attempting to perform, or changing card parameters. These effects and execution conditions vary depending on the type of card and effect. Examples of effects include increasing the attack power of a monster card, adding the top card of the deck to your hand, and restricting the opponent's command execution. Examples of execution conditions include the difference in LP between you and your opponent, or the number of monster cards on the field.

[0026] FIG. 3(b) is a diagram for explaining a magic card C2, showing a schematic example of its front side. On the front side of the magic card C2, a name area C22, an illustration area C23, and a text area C24 are arranged inside a frame C21. The name area C22 contains the name of the magic spell, which will become the card's name. The illustration area C23 contains an illustration that evokes the magic. The text area C24 contains the activation conditions and effects of the magic card C2. The same applies to trap cards, and illustrations and explanations thereof will be omitted.

[0027] The backs of monster cards, magic cards, and trap cards all have a predetermined pattern, so that the contents cannot be determined by looking at the backs alone.

[0028] Activating an effect means actually using the effect of a card. Setting means placing various cards face down on the field. Playing a monster card in face-down defense position is also called setting.

[0029] There are three types of magic cards: normal magic cards, equip magic cards, field magic cards, quick-play magic cards, ritual magic cards, and continuous magic cards. Normal magic cards are placed in the Spell & Trap Zone when you declare their activation, and are sent to the Graveyard after their effect is resolved. Equip magic cards grant an effect to one monster and remain on the field after activation. Field magic cards are placed in a dedicated field zone and remain on the field after activation. Quick-play magic cards are special magic cards that can be activated even during your opponent's turn. They can be activated at any time, but if they are to be activated during your opponent's turn, they must be set in the Spell & Trap Zone beforehand. However, they cannot be activated on the turn they are set. Ritual magic cards are special magic cards required to summon monsters called "ritual monsters." Continuous magic cards remain on the field after activation and continue to exert their effects until they leave the field.

[0030] There are three types of Trap Cards: Normal Trap Cards, Permanent Trap Cards, and Counter Trap Cards. Normal Trap Cards must be placed face down in the Spell & Trap Zone and cannot be activated the turn they are set. Normal Trap Cards with one-time effects are sent to the Graveyard after their effect has been resolved, just like Normal Spell Cards. Permanent Trap Cards are Trap Cards that remain on the field after activation and continue to exert their effects, just like Permanent Spell Cards. Some Permanent Trap Cards also have effects similar to those of Effect Monsters. Counter Trap Cards are Trap Cards that are activated in response to the activation of a card and have effects that negate the activation of that card itself.

[0031] Monster cards include Normal Monsters with no effects, Effect Monsters with effects, Fusion Monsters, Ritual Monsters, Synchro Monsters, Xyz Monsters, and Pengulum Monsters. Effect Monsters have three types of effects: Trigger Effects, Ignition Effects, and Instant Trigger Effects, depending on when they are activated. Trigger Effects are effects that activate at a predetermined time. Ignition Effects are effects that can be used by declaring them as the player with priority. These effects can only be activated during your Main Phase unless otherwise stated on the card. Instant Trigger Effects are effects that can be activated at your discretion, even during your opponent's turn.

[0032] Next, commands that the user uses in conjunction with card selection will be described. Command types include summon, attack / defense change, spell / trap, monster effect, special summon, and attack. A summon command is a command related to the process of placing a specific card on the field. By executing a process based on the summon command, the user places the selected monster card or a monster card to be selected on their field PAB. When placing a monster, it may be possible to choose the orientation, such as vertical, horizontal, face up, or face down. For example, a monster card placed face up vertically can attack. A monster card placed face up horizontally cannot attack, but does not lose LP even if attacked by the opponent. The contents of a card placed face down are not visible to the opponent. For example, placing a monster card face up on the field is called a face-up summon, and placing it face down is called a face-down summon.

[0033] The attack / defense change command is a command that changes the orientation (portrait, landscape, face up, face down, etc.) of monster cards on the field. When the user executes a process based on the attack / defense change command, the orientation of the selected monster card or the monster card to be selected when placed on the player's field PAB will be changed. Magic / Trap Commands are commands that activate effects associated with Magic Cards and Trap Cards. Activating an effect means carrying out the process associated with the effect. When the user carries out a process based on a Magic / Trap Command, the effect associated with the selected Magic Card or Trap Card, or the Magic Card or Trap Card to be selected, is activated. A monster effect command is a command that activates a specific effect associated with a monster card that has an effect. When the user executes a process based on the monster effect command, the specific effect associated with the selected monster card or a monster card to be selected is activated.

[0034] A special summon command is a command that can be used when execution conditions (conditions associated with a card) different from those for face-up summon and face-down summon are met, and is a command that places a monster card on the field. An attack command is a command to attack the opponent with a monster card. When the user executes a process based on the attack command, an attack is made against the opponent with the selected monster card or a monster card to be selected.

[0035] Each of these commands has conditions under which the command's processing can be executed depending on the game situation. The game situation refers to various requirements during game play, such as whether it is the user's or the opponent's turn, the user's and opponent's LP, the number of cards in hand, the number of cards remaining in the deck, the number of monster cards in play, the number of monster cards in the graveyard, the current phase within the turn, the time elapsed since the start of the turn, and the time elapsed since the command selection became possible. A phase is a division within each turn according to the rules. This card game progresses by alternating between the user's turn and the opponent's turn, with each turn consisting of multiple phases. Each turn progresses in the order of phases (1) to (6). (1) Start Phase: At the start of the turn, cards are drawn from the deck. (2) Preparation Phase: Effects that occur automatically at this time are processed. (3) Main Phase 1: The user selects commands and cards, and processes related to the summoning of monster cards and the activation of effects such as spells, traps, and monster effects are carried out. (4) Battle Phase: This phase begins when the user initiates a battle. Attacks are made using cards placed on the field, and the results of the attack are processed. If no battle is conducted, this Battle Phase is not performed and the game proceeds to the End Phase (6). (5) Main Phase 2: Only if the Battle Phase has taken place, the same process as Main Phase 1 is carried out. This phase may be omitted. (6) End Phase: The turn ends. After this, the opponent's turn begins.

[0036] For example, commands such as summon and offense / defense change can only be executed during the main phase. On the other hand, attack commands can only be executed during the battle phase. Attack commands are executed by specifying your own card and the opponent's card to attack. For example, tap (touch the touch panel) a monster card placed in either area PA2(1), PA2(2), or PA2(3), slide your finger toward the opponent's card to attack, and untap (remove your finger from the touch panel). Also, in certain situations (for example, when there are no monster cards on the opponent's PBB), a direct attack to attack the opposing player is possible. A direct attack is an attack that directly damages the opponent's controlled character and reduces the controlled character's Life Points.

[0037] In addition, the conditions for executing each command are determined by other battle situations besides the phase. For example, a summon command can be executed if a monster card is in your hand PAT, but cannot be executed if there is no monster card. An attack / defense change command can be executed if a monster card is in your PAB, but cannot be executed if there is no monster card. A monster effect command can be executed if a monster card with an effect is in your hand PAT, your PAB deck, or your Graveyard, but cannot be executed if there is no monster card. A spell / trap command can be executed if a spell card or trap card is in your hand PAT or your PAB, but cannot be executed if there is no monster card. A special summon command can be executed if a monster card with the corresponding special summon condition, which cannot be summoned by normal means, is in your hand PAT or your PAB (area PA5), but cannot be executed if there is no monster card. An attack command can be executed if a monster card is in your PAB, but cannot be executed if there is no monster card. Furthermore, each attack command can only be executed once per turn for each monster card. Note that the conditions under which processing based on these commands can be executed are just examples, and various conditions may be defined depending on the type of each card, the relative size of your LP and your opponent's LP, whether it is your turn or your opponent's turn, etc.

[0038] [Functional configuration of server device 30] FIG. 4 is a diagram showing the functional configuration of the server device 30. As shown in FIG. The server device 30 includes a communication unit 310, a storage unit 320, and a control unit 330. The communication unit 310 is connected to the network 20 and communicates with the terminal device 10 and the server device 40 .

[0039] The storage unit 320 includes a user data storage unit 321 , a card data storage unit 322 , a game situation data storage unit 323 , and a card management data storage unit 324 . The user data storage unit 321 stores user data, which is information about users who play the card game. The user data includes, for example, information such as player level, username, friend users, amount of in-game currency, and owned items, associated with a player ID. The player ID is information that identifies the user.

[0040] The card data storage unit 322 stores card data, which is information about cards used in a card game. A card ID (hereinafter referred to as "identifier X") is associated with each type of card. The identifier X is information that uniquely identifies the type of card. The type of card refers to the type of monster in the case of a monster card, or the type of magic or trap in the case of a magic card or trap card. In other words, monster cards of the same monster are assigned the same identifier X. Furthermore, magic cards of the same magic and trap cards of the same trap are each assigned the same identifier X.

[0041] The game situation data storage unit 323 stores game situation data, which is information about the game situation of a card game played by a user. Since the game situation changes from moment to moment as the game progresses, the game situation data is updated as the game progresses. The game situation data includes, for example, information about the placement of cards and information about the status of the match between the user and their opponent.

[0042] The card management data storage unit 324 stores data for managing cards owned by each user.

[0043] The control unit 330 controls each component included in the server device 30. The control unit 330 is realized by the CPU 31 executing a control program. The control unit 330 includes a data management unit 331 , a game processing unit 332 , a card management unit 333 , and a processing unit 334 .

[0044] The data management unit 331 manages data related to processing of the server device 30, controls transmission and reception of data with other devices, and controls writing of data to the storage unit 320 and reading of data from the storage unit 320. The data management unit 331 outputs data acquired from the terminal device 10 and data read from the storage unit 320 to the game processing unit 332. The data management unit 331 also transmits data acquired from the game processing unit 332 to the terminal device 10 and writes the data to the storage unit 320.

[0045] The game processing unit 332 performs control for executing the card game. In the present embodiment, as an example, the server device 30 performs substantial card game processing. In this case, when the terminal device 10 accepts a game operation from a user, it notifies the server device 30 of the content of the game operation. The server device 30 executes processing for progressing the card game based on the content of the game operation notified from the terminal device 10. At this time, the server device 30 updates various data as necessary. The server device 30 notifies the terminal device 10 of the processing result. Then, the terminal device 10 displays a game screen or plays game audio based on the processing result notified from the server device 30. This makes it possible to update the game screen or play audio according to the content of the operation. The game processing unit 332 also performs processing such as matching users together.

[0046] The card management unit 333 manages cards owned by each user for each user using the card management data storage unit 324 of the storage unit 320. In this embodiment, cards owned by a user that have been given a predetermined processing (hereinafter referred to as "special processing"), which will be described later, are managed as special cards. Cards that are not special cards (cards without special processing) are referred to as normal cards. "Owned by a user" means that the card is associated with a player ID. "Managing cards" means collecting and organizing card information and making it accessible. The card management unit 333 includes a first management unit 333a that manages normal cards and a second management unit 333b that manages special cards. Figures 6 and 7 are diagrams for explaining management of normal cards and special cards owned by a certain user.

[0047] The first management unit 333a manages cards possessed by a user that are not given special processing as normal cards, with an identifier X and the number of cards. The first management unit 333a functions as the first management means of the present invention, and the identifier X corresponds to the first identification information of the present invention. FIG. 6(a) is a diagram for explaining management of normal cards possessed by a certain user. As shown in FIG. 6(a), the first management unit 333a manages cards by type in the management area 1 provided by the card management data storage unit 324 with an identifier X and the number of cards. For example, card B is a monster card of a certain monster, and this monster card is uniformly assigned the identifier X "11112". In the example of FIG. 6(a), the user possesses four card B, which are normal cards.

[0048] There is no upper limit set on the number of cards (normal cards) managed by the first management unit 333a. Furthermore, within the card game provided by the server device 30, normal cards can be exchanged for other objects (other normal cards, in-game currency, etc.), or normal cards can be discarded. Normal cards cannot be put up for sale on the NFT marketplace.

[0049] Regular cards can be given basic, shine, or premium processing. Basic processing is a basic processing with no effects. Shine processing is a processing that displays a glowing effect at regular intervals. Premium processing is a processing that displays a sparkling effect. These basic, shine, and premium processing are different from special processing and are given to regular cards, so even if a processing is given to a card, it will remain a regular card.

[0050] The second management unit 333b manages cards possessed by a user that have been given special processing as special cards using a card ID (hereinafter referred to as "identifier Y") assigned to each card. The identifier Y is information that uniquely identifies a card. The second management unit 333b functions as the second management means of the present invention, and the identifier Y corresponds to the first identification information of the present invention. FIG. 6(b) is a diagram for explaining management of special cards possessed by a certain user. As shown in FIG. 6(b), the second management unit 333b assigns an identifier Y, which is a unique card ID, to each special card, and manages the special cards with the identifier Y and the identifier X for each card in the management area 2 provided by the card management data storage unit 324. In the example of FIG. 6(b), the user possesses one special card, Card B (special).

[0051] By applying special processing to an ordinary card possessed by a user, it can be made into a special card. As shown in Figures 7(a) and (b), when special processing is applied to Card B, which is an ordinary card possessed by a user, it becomes a special card, Card B (special), and is assigned a unique identifier Y. As a result, from the state shown in Figure 6, as shown in Figure 7(b), the number of Cards B (special) managed by the second management unit 333b increases by one, and as shown in Figure 7(a), the number of Cards B managed by the first management unit 333a changes from four to three. In addition to the user being able to apply special effects to cards they own through their own operations, cards may also be configured to already have special effects applied (become special cards) when the user obtains them by purchasing them, etc. For example, if a package of multiple cards is purchased, special cards may be dispensed according to predetermined rules.

[0052] The second management unit 333b also adds history information to each card, as shown in FIGS. 6(b) and 7(b). The history information includes the details of the processing performed on the special card after it became a special card, information on the timing of the processing, and the usage status of the special card in the card game after it became a special card. For example, in the server device 30, history information for each special card is converted into a file and stored in the storage unit 320, and the file is constantly updated, and a URL for the file is added. FIG. 9 shows an example of history information. Note that duel history is counted and recorded only in PvP (Player versus Player) duels. This is because there are concerns about cheating in PvE (Player vs. Enemy, Player vs. Environment) duels.

[0053] Furthermore, the second management unit 333b adds information to each card as to whether or not it can be used in a card game, as shown in FIG. 6(b) and FIG. 7(b).

[0054] An upper limit is set on the number of cards (special cards) managed by the second management unit 333b. Note that the number of special cards may be increased by purchasing a special card management slot. To reduce the risk of accidentally losing special cards, special cards cannot be exchanged for other objects (other regular cards, in-game currency, etc.) or discarded within the card game provided by the server device 30. Special cards can be put up for sale on the NFT marketplace.

[0055] In this way, the card management unit 333 manages the cards owned by each user by dividing them into normal cards and special cards. If we use an analogy of physical cards such as paper, this is similar to storing normal cards in a box and storing valuable rare cards in a card binder.

[0056] The processing unit 334 applies special processing to the card. As described above, applying special processing to a normal card can turn it into a special card. The processing unit 334 applies special processing to a card selected by the user. Since applying special processing is a requirement for turning a card into a special card, the appearance of the special card can be made different from that of a normal card.

[0057] Furthermore, the processing unit 334 applies a used finish to special cards. By applying a used finish to special cards in this way, the appearance of the special cards can be made different from that of normal cards. The processing unit 334 refers to the PvP usage history of the special card, and when certain conditions, such as the number of times the card has been used, are met, the special card becomes eligible for application of a used finish. When the results of a PvP duel are displayed, if a special card that meets certain conditions is included in the deck, a dialog box is displayed to notify the user that a used finish can be applied. When certain conditions are met, the used finish can be applied, but since it is expected that there will be users who do not like the used finish, the user is allowed to choose whether or not to apply the used finish.

[0058] The processing unit 334 applies a filter to the card displayed on the display unit 16 of the terminal device 10 so that the special processing or used processing is made visible.

[0059] Although special cards can be listed on the NFT marketplace, some special cards (such as cards distributed with the assumption that each user will own one or two) will not be allowed to be listed. Cards that are prohibited from being listed will be managed in master by identifier X. Furthermore, if the number of special cards managed by the second management unit 333b (the management limit for special cards) reaches its upper limit, it is not possible to add special processing to a normal card to turn it into a special card, or to receive a new special card. Special cards that could not be received are stored in a specified area of ​​the storage unit 320 for an appropriate period of time.

[0060] Additionally, to prevent players from reaching the limit on the number of special cards and being unable to acquire new special cards, special cards will be made convertible to regular cards. For example, special cards will be made convertible back to regular cards only when all special card slots are filled. However, special cards currently listed on the market (including those being prepared for listing) and rare special cards (such as prizes from world championships) will not be able to be converted back to regular cards. A flag indicating that the card cannot be converted to a regular card will be added to the history information. When returning a special card to a normal card, if the card's normal card processing history is saved, it will be restored to that processing. If the card was obtained as a special card from the beginning, and the card's normal card processing history is not saved, it will be restored to basic processing.

[0061] After the duel is over, evaluation points are awarded according to the content of the duel. For example, if a quick win or a come-from-behind victory is achieved, the evaluation points are added and the evaluation points become higher. In such duel evaluation, evaluation points may be added when a special card is used in the duel.

[0062] [Functional configuration of server device 40] FIG. 5 is a diagram showing the functional configuration of the server device 40. As shown in FIG. The server device 40 includes a communication unit 410, a storage unit 420, and a control unit 430. The communication unit 410 connects to the network 20 and communicates with the terminal device 10 and the server device 30 .

[0063] The storage unit 420 includes a user data storage unit 421 , a card data storage unit 422 , a transaction status data storage unit 423 , and a card management data storage unit 424 .

[0064] The user data storage unit 421 stores user data, which is information about users who use the NFT marketplace. If a user whose user data is stored in the user data storage unit 421 is also a user whose user data is stored in the user data storage unit 321 of the server device 30 (a user who uses a card game), the users are associated with each other.

[0065] The card data storage unit 422 stores card data, which is information about an NFTed card.

[0066] The transaction status data storage unit 423 stores transaction status data, which is information on the transaction status of NFTized cards in the NFT marketplace. Because the transaction status changes from moment to moment depending on transactions of NFTized cards, the transaction status data is updated as needed depending on transactions of NFTized cards.

[0067] The card management data storage unit 424 stores data for managing the NFT cards possessed by each user for each user.

[0068] The control unit 430 controls each component included in the server device 40. The control unit 430 is realized by the CPU 41 executing a control program. The control unit 430 includes a data management unit 431 , a transaction processing unit 432 , and a card management unit 433 . The data management unit 431 manages data related to processing by the server device 40, controls the sending and receiving of data to and from other devices, and controls the writing of data to and reading of data from the memory unit 420. The data management unit 431 outputs data acquired from the terminal device 10 and data read from the memory unit 420 to the transaction processing unit 432. The data management unit 431 also transmits data acquired from the transaction processing unit 432 to the terminal device 10 and writes the data into the memory unit 420.

[0069] The transaction processing unit 432 performs control for executing transactions of NFTed cards. When the terminal device 10 accepts a transaction operation from a user, it notifies the server device 40 of the contents of the transaction operation. The server device 40 executes processing to progress the transaction based on the contents of the transaction operation notified from the terminal device 10. At this time, the server device 40 updates various data as necessary. The server device 40 notifies the terminal device 10 of the processing results. Then, the terminal device 10 displays a transaction screen, etc., based on the processing results notified from the server device 40.

[0070] The card management unit 433 uses the card management data storage unit 424 of the storage unit 420 to manage, for each user, NFTized cards to be offered on the NFT marketplace, from among the cards owned by each user. The card management unit 433b functions as the third management means of the present invention. FIG. 8(a) is a diagram for explaining the management of NFTized cards owned by a certain user. As shown in FIG. 8(a), the card management unit 433 manages cards managed by the second management unit 333b of the server device 30, i.e., special cards, in the management area 3 provided by the card management data storage unit 424. Each card managed by the card management unit 433 is assigned an ID in the NFT marketplace (hereinafter referred to as "identifier Z"). The identifier Z is information that uniquely identifies a card traded on the NFT marketplace. When a predetermined operation is performed on server device 30, card information is synchronized between server device 30 and server device 40, so that the cards managed by card management unit 433 are reflected in the cards managed by second management unit 333b of server device 30. If there are any cards managed by second management unit 333b of server device 30 that have not been converted into NFTs, they are converted into NFTs at this time.

[0071] Furthermore, the card management unit 433 adds status information (preparing to put up for sale, putting up for sale) to each card, as shown in FIG. 8(a). When an NFTed card is set to be ready to be put up for sale in the server device 40, the card management unit 433 sets the status information to "preparing to be put up for sale." The setting to "preparing to be put up for sale" is performed on the condition that the card is removed from the deck. As shown in FIG. 8(a), when an NFTed card (in the illustrated example, card B (special) (identifier Z: aaab, identifier Y: 900004)) is set to be ready to be put up for sale, the card management unit 433 sets the status information of the card to "preparing to be put up for sale." In response to this, as shown in FIG. 8(b), the second management unit 333b of the server device 30 sets the card that has been set to be ready to be put up for sale (in the illustrated example, card B (special) (identifier Y: 900004)) to be unusable. A card that has been set to be unusable cannot be added to a deck. Furthermore, a card that has been set to be unusable cannot have its processing changed or be returned to a normal card.

[0072] In addition, since the history information of each card managed by the card management unit 433 is stored in the server device 30, the history of the NFTed card can also be referenced on the server device 40 by referring to the URL.

[0073] [Special processing] In this embodiment, there are four types of special processing, which are the predetermined requirements for making a special card: surface processing, frame color processing, character color processing, and stamping. The following description will be made with reference to the reference numerals attached to FIG. 3.

[0074] Surface treatments are effects applied to the surface of the card. Note that a common specification for surface treatments is that no effects are applied to the text areas C14 and C24. Furthermore, no effects are applied to the main elements (monster bodies, faces, etc.) in the illustration areas C13 and C23. Surface finishes include parallel, ultra, secret, and prismatic finishes. Parallel finishes are finishes that scatter prism fragments across the illustration areas C13 and C23 and the frames C11 and C21. Ultra finishes are foil finishes for the illustration areas C13 and C23. Secret finishes are finishes that create a vertical and horizontal granular grid pattern in the illustration areas C13 and C23. Prismatic finishes are finishes that create a vertical and horizontal granular grid pattern similar to the secret finish in the illustration areas C13, C23, and the frames C11 and C21. Secret and prismatic finishes have three grid pattern display patterns, and the pattern that applies the finish may be determined randomly. The grid pattern position pattern number (0, 1, or 2) is recorded as card history information (see Figure 9; a hidden parameter that cannot be accessed by the user). When the card is displayed, the grid pattern display position changes according to this value. There are a wide variety of surface finishes, and they are not limited to those described here. Other surface finishes may be used in addition to or instead of these. For example, special finishes may include animation finishes that make monsters in illustration areas C13 and C23 appear to move. The distressed finish described below may also be considered special finishes. Special finishes may also include metallic finishes that give the entire surface of the card a metallic color. Special finishes may also include relief finishes that create irregularities on the surface of the card, making it appear three-dimensional depending on the viewing angle.

[0075] Frame color processing is a process that changes the color of the frames C11 and C21 on the surface of the card. For example, the color of the frames C11 and C21, which are black on normal cards (cards without processing), changes to gold, silver, or black iron (black with a metallic feel added). All of these have a metallic texture, and the gloss appears to change even when the card is stationary.

[0076] For example, the color of the card name in name areas C12 and C22 can be blue, red, gold, or silver. All of these have a metallic texture, and the gloss appears to change even when the card is stationary.

[0077] Stamps are a process that makes it appear as if a stamp has been pressed in a specific location on the front of the card (for example, the bottom right corner of illustration areas C13 and C23). For example, a stamp with a specific design can be pressed as a reward for achieving good results in an event.

[0078] A screen for applying special effects (not shown) is displayed on the display unit 16 of the terminal device 10 using the card game provided by the server device 30. On this screen, a card to which a special effect is to be applied is selected, and then the desired effect (surface effect, frame color effect, character color effect, stamp) is selected, whereby the special effect can be applied to the selected card.

[0079] It is also possible to add special processing to special cards, allowing different types of processing to coexist. On the other hand, if a processing of the same type has already been added, it will be overwritten by the processing added later. For example, if a special card with an ultra processing is given a prismatic processing, the ultra processing will be lost. The second management unit 333b manages the history information of special cards (see Figure 9), and the history of special processing will remain.

[0080] [Distressed processing] Special cards can be given a distressed look. Distressed effects primarily represent the fading, fading, and creases that occur on physical cards, such as paper. Types of distressed effects include sepia, noise, distressed, sanded, and stoned. Sepia fades the illustration areas C13 and C23 to a sepia tone. Sepia is not applied to the frames C11 and C21 because changing the color of the frames would reduce the card's distinctiveness. Noise is applied to the illustration areas C13, C23, and frames C11 and C21, creating a digital noise effect that sometimes blurs the outlines. Distressed effects blur the illustration areas C13, C23, and frames C11 and C21, creating a crease pattern on the card itself. Sanded effects create a dirt pattern resembling dust and sand in the illustration areas C13, C23, and frames C11 and C21. Stone processing adds a stone slab-like texture to frames C11 and C21. For example, sand processing and stone processing are exclusive to monster cards. Each processing has three levels, and the higher the level, the greater the difference from the original illustration area C13, C23 and frames C11, C21.

[0081] The used effect can be applied depending on the card's usage history. Examples of certain conditions that make it possible to apply the used effect are as follows. (1) For each special card in the deck, a decision is made based on a predetermined probability for each number of uses to determine whether or not to proceed to the unlock check (2) (determining whether or not to allow the application of each effect). For monster cards, the number of uses is the sum of the number of times the card has been summoned or special summoned and the number of times its effect has been activated in its history. For spell and trap cards, the number of times its effect has been activated in its history. The probability of proceeding to the unlock check is predetermined, as shown in Figure 10(a), for example. The higher the number of uses, the higher the probability of proceeding to the unlock check. Note that if all of the effects (sepia, noise, damage, sand, and stone) have been unlocked up to level 3 (maximum), the decision to proceed to the unlock check is not made.

[0082] (2) The unlock determination is performed based on the probability determined by the parameters determined for each processing. Processing that is already at level 3 (maximum) is not considered. As shown in Figure 10(b), the older the card's creation date and time, the more likely it is to be unlocked with sepia processing (i.e., the longer you've owned and used the card). As shown in Figure 10(c), the more likely it is to be unlocked with noise processing (i.e., the more recently you've acquired the card and used it), the more likely it is to be unlocked with noise processing. As shown in Figure 10(d), the more times a card is destroyed (whether by battle or by effect), the more likely it is to be unlocked with damage processing. The number of times a monster card has been destroyed is the sum of the number of times it has been destroyed by battle and the number of times it has been destroyed by effect. As shown in Figure 10(e), the more likely it is to be unlocked with sand processing (both of which are exclusively for monster cards) the more times it has been destroyed by battle. As shown in Figure 10(f), the more likely it is to be unlocked with stone processing (exclusive to monster cards) the more times it has been destroyed by battle. For example, if we consider the damage processing of a certain special card, if the number of uses is 100-149 (4% in Figure 10(a)) and the number of times it has been destroyed is 21-30 (10% in Figure 10(d)), the probability of it being unlocked is 0.4%.

[0083] (3) Once unlocked, the processing level will increase by 1, and processing up to the level reached will be available. When displaying the results of a PvP duel, if a deck contains a special card that meets certain conditions, a dialog box will appear to notify the user that a used effect can be applied. The server device 30 does not automatically apply the used effect, and the user can choose whether or not to apply the used effect. Once the conditions are met, the used effect can be applied any number of times (even later).

[0084] [Screen transition example] Next, transition examples of various screens G2 to G10 displayed on the display unit 16 of the terminal device 10 will be described with reference to Figures 11 to 19. Screens G2 to G10 are displayed when a user uses the terminal device 10 to play a card game provided by the server device 30. Note that each figure is intended to provide an overview of screens G2 to G10, and for example, the designs of cards displayed on the screens are omitted or simplified.

[0085] As shown in FIG. 11, "My Deck," "Card List," and "Special Cards" can be selected on the selection screen G2. When "My Deck" is selected on the selection screen G2 in Fig. 11, the screen transitions to a deck editing screen (not shown). On the deck editing screen, the user can edit a deck, which is a set of cards consisting of a predetermined number of cards that are arbitrarily combined from the cards the user owns.

[0086] When "Card List" is selected on the selection screen G2 in FIG. 11, the screen transitions to a card list screen G3 as shown in FIG. 12. The card list screen G3 displays a card list CL31. The card list CL31 displays thumbnails of cards that meet the narrowing criteria, among the normal cards and special cards owned by the user. The card list CL31 displays only one card of each type. That is, the card list CL31 displays the cards owned by the user in units of identifier X. For example, if the user owns multiple monster cards of the same monster, a representative card is selected according to a predetermined rule and displayed. When a thumbnail of a special card is displayed, special processing is applied to some extent to make it visible that it is a special card. Alternatively, the fact that the card is special may be clearly indicated by text or the like.

[0087] Furthermore, the card list screen G3 displays a card list narrowing button E31, a card list narrowing content display E32, a back button E33, a limit regulation display button E34, a shop button E35, and a home button E36. The card list narrowing button E31 is an operator for selecting the conditions for cards to be displayed in the card list CL31. The card list narrowing content display E32 displays information indicating the current narrowing conditions. The back button E33 is an operator for returning to the previous screen. The limit regulation display button E34 is an operator for displaying the current limit regulation. The limit regulation refers to the current contents of banned cards, limited cards, and semi-limited cards. A banned card refers to a card that may not be used in the battle part. A limited card refers to a card that may only be included in one copy in a deck. A semi-limited card refers to a card that may only be included in two copies in a deck. The shop button E35 is an operator for transitioning to a shop screen. The home button E36 is an operator for returning to the home screen.

[0088] When a thumbnail in the card list CL31 on the card list screen G3 is selected, the screen transitions to an enlarged display screen G4, which displays an enlarged view of the selected card, as shown in FIG. 13. In the illustrated example, the thumbnail of a monster card for Monster B (labeled "MoB" in the figure) in the card list CL31 on the card list screen G3 is selected. The enlarged display screen G4 displays the full effect of the processing applied to Card C. Note that a cross star drawn on Card C schematically indicates that a special processing has been applied. In addition, the number of cards of the same type (a / b / c / d) held by the user is displayed in the lower right corner of Card C. "a" indicates the number of special cards, i.e., the number of cards managed by the second management unit 333b of the server device 30. "b," "c," and "d" indicate the number of premium processing cards, the number of shine processing cards, and the number of basic processing cards, respectively. As described above, premium processing, shine processing, and basic processing are applied to regular cards, unlike special processing. Even if a processing is applied, the card remains regular. The sum of b, c, and d is the number of normal cards, that is, the number of cards managed by the first management unit 333a of the server device 30.

[0089] In addition, the enlarged display screen G4 displays an possession details button E41 and an exchange button E42. When the possession details button E41 on the enlarged display screen G4 is operated, the display transitions to a possession details screen G5 for card C (monster card of monster b) displayed on the enlarged display screen G4, as shown in FIG. 14. A card list CL51 is displayed on the possession details screen G5. The card list CL51 displays thumbnails of cards of the same type as card C (monster card of monster b) displayed on the enlarged display screen G4. In the illustrated example, the user possesses six monster cards of monster b, three of which are special cards. Here too, when thumbnails of special cards are displayed, special processing is reflected to some extent. Alternatively, the fact that the cards are special may be clearly indicated by text or the like.

[0090] When the exchange button E42 on the enlarged display screen G4 is operated, the screen transitions to an exchange screen G6 for card C (monster card of monster b) displayed on the enlarged display screen G4, as shown in FIG. 15. The exchange screen G6 displays a card list CL61 similar to the card list CL51 on the possession details screen G. On the exchange screen G6, it is possible to select card C from the card list CL61 and exchange it for another object. As described above, special cards cannot be exchanged for other objects in the card game, and therefore special cards cannot be selected on the exchange screen G6.

[0091] When a thumbnail in the card list CL51 on the possession details screen G5 is selected, the screen transitions to an enlarged display screen G7, which displays an enlarged view of the selected card, as shown in FIG. 16. In the illustrated example, it is assumed that the thumbnail of the monster card of monster B on the left in the card list CL51 on the possession details screen G5 is selected. In the enlarged display screen G7, the processing applied to card C is displayed in full effect. The cross star drawn on card C schematically indicates that special processing has been applied. In addition, the number of cards of the same type held (a / b / c / d) is displayed in the lower right corner of card C.

[0092] Furthermore, a history button E71 is displayed on the enlarged display screen G7. The history button E71 is active only when the card C displayed on the enlarged display screen G7 is a special card, and is inactive when it is a normal card. When the history button E71 is operated, a dialog box presenting history information of the card C displayed on the enlarged display screen G7 is displayed. Although the illustration of the dialog box is omitted, information based on the history information for the card C managed by the second management unit 333b is displayed.

[0093] When "Special Card" is selected on the selection screen G2 of FIG. 11, the screen transitions to a special card list screen G8 as shown in FIG. 17. The special card list screen G8 displays a card list CL81. The card list CL81 displays thumbnails of all of the special cards owned by the user. That is, the card list CL81 displays the special cards owned by the user in units of identifier Y. For example, if the user owns multiple special cards of the same monster, each of them is displayed. Each thumbnail is designed to reflect special processing to a certain extent. In the illustrated example, there are special card management frames 1 to 32 from the top left (the upper limit of the number of special cards is 32), and thumbnails are displayed in these management frames 1 to 32.

[0094] Furthermore, the special card list screen G8 displays a purchase button E81 for the management slots of special cards. When the purchase button E81 is operated, the screen transitions to a shop screen (not shown), where the management slots of special cards can be purchased. When a "special card" is selected on selection screen G2, card information is synchronized between server device 30 and server device 40, so that the cards managed by card management unit 433 of server device 40 reflect the cards managed by second management unit 333b of server device 30. If there are any cards managed by second management unit 333b of server device 30 that have not been converted into NFTs, they are converted into NFTs at this time.

[0095] When a thumbnail in the card list CL81 of the special card list screen G8 is selected, the screen transitions to an enlarged display screen G9, which displays an enlarged view of the selected card, as shown in FIG. 18. In the illustrated example, the thumbnail of the monster card of monster b in the upper left (management slot 1) of the card list CL81 of the special card list screen G8 is selected. In the enlarged display screen G9, the processing applied to card C is displayed in full effect. The cross star drawn on card C schematically indicates that special processing has been applied. In addition, the number of cards of the same type owned (a / b / c / d) is displayed in the lower right corner of card C.

[0096] In addition, the enlarged display screen G9 displays a history button E91, a preparation for exhibition button E92, and a normalization button E93. The history button E91 is similar to the history button E71 on the enlarged display screen G7 in FIG. 16, and when this is operated, a dialog box presenting history information of the card C displayed on the enlarged display screen G9 is displayed.

[0097] When the Prepare to Sell button E92 on the enlarged display screen G9 is operated, a message is displayed informing the user that the card C displayed on the enlarged display screen G9 will become unusable. Upon confirmation, the server device 30 sends an instruction to the server device 40 to prepare the card C for sale, and the screen transitions to a special card list screen G10, as shown in FIG. 19 . The special card list screen G10 displays a card list CL101 similar to the card list CL81 on the special card list screen G8 of FIG. 17 , and a thumbnail (management frame 1) of the special card C for which preparation for sale has been set indicates that the card is being prepared for sale. Note that, if the Prepare to Sell button E92 is operated and the card C displayed on the enlarged display screen G9 is in a deck, a message is displayed instructing the user to remove the card from the deck. In this way, the server device 30 can set cards managed by the card management unit 433 of the server device 40 to be prepared for sale. When the setting for preparation for sale is made, the second management unit 333b sets the card for which preparation for sale has been made to be unusable in the game. Subsequently, when a listing operation is performed on the server device 40 side (NFT marketplace side) for special card C that has been set up for listing, the thumbnail (management frame 1) of the special card that has been listed will indicate in the card list CL101 that it is being listed.

[0098] In addition, a cancel exhibition preparation button E101 is displayed on the special card list screen G10. When the cancel exhibition preparation button E101 is operated with a card C for which exhibition preparation is to be canceled selected from the card list CL101, an instruction to cancel exhibition preparation for the card C is sent from server device 30 to server device 40.

[0099] When the normalize button E93 on the enlarged display screen G9 is operated, the card is converted to a normal card after passing through a confirmation screen (not shown). When converting a special NFT card to a normal card, if authentication from the NFT marketplace is required, the normalize button E93 becomes active only if authentication is successful. When converting a special card back to a normal card, if the processing performed when the card was a normal card is saved in the history, the card will revert to that processing; if the processing performed when the card was a normal card is not saved in the history, the card will revert to basic processing.

[0100] [Example of processing using a network system] The flow of processing by the network system NS according to the embodiment will be described. Fig. 20 is a flowchart showing an example of processing by the network system NS. Here, the flow of processing when the selection screen G2 of Fig. 11 is displayed on the display unit 16 of the terminal device 10 and a selection is made by a user operation will be described.

[0101] In S100, the server device 30 determines whether or not "My Deck" has been selected on the selection screen G2. If "My Deck" has been selected, the process proceeds to S102. If "Card List" or "Special Card" has been selected instead of "My Deck," the process proceeds to S106.

[0102] In S102, the server device 30 displays a deck editing screen (not shown) on the display unit 16 of the terminal device 10. Then, in S104, the server device 30 executes processing in accordance with operations on the deck editing screen. Description of operations on the deck editing screen and the processing in accordance therewith will be omitted.

[0103] In S106, the server device 30 determines whether or not "Card List" has been selected on the selection screen G2. If "Card List" has been selected, the process proceeds to S108. If "Special Card" has been selected instead of "Card List," the process proceeds to S112.

[0104] In S108, the server device 30 displays the card list screen G3 of Fig. 12 on the display unit 16 of the terminal device 10. Then, in S110, the server device 30 executes processing in response to an operation on the card list screen G3. Details of the processing in response to an operation on the card list screen G3 are as described in [Example of Screen Transition]. For example, when a thumbnail in the card list CL31 on the card list screen G3 is selected, the server device 30 displays an enlarged display screen G4 (Fig. 13) on the display unit 16.

[0105] In S112, the server device 30 displays the special card list screen G8 of FIG. 17 on the display unit 16 of the terminal device 10. At this timing, in S114, card information is synchronized between the server device 30 and the server device 40, so that the cards managed by the card management unit 433 of the server device 40 reflect the cards managed by the second management unit 333b of the server device 30. If there are any cards managed by the second management unit 333b of the server device 30 that have not been converted into NFTs, they are converted into NFTs at this timing. Then, in S116, the server device 30 executes processing in response to the operation on the special card list screen G8. Details of the processing in response to the operation on the special card list screen G8 are as described in [Screen Transition Example]. For example, when a thumbnail in the card list CL81 on the special card list screen G8 is selected, the server device 30 displays an enlarged display screen G9 ( FIG. 18 ) on the display unit 16.

[0106] [summary] As described above, the server device 30 includes a first management unit 333a that manages normal cards among the cards owned by the user using an identifier X assigned to each type of card and the number of cards, and a second management unit 333b that manages special cards among the cards owned by the user using an identifier Y assigned to each card. A normal card can be transformed into a special card by applying special processing, or a special card can be reverted to a normal card. In this way, a portion of the cards owned by the user that the user desires can be treated as a unique object (one and only object).

[0107] Furthermore, since the server device 40 is equipped with a card management unit 433 that manages cards managed by the second management unit 333b of the server device 30, special cards can be converted into NFTs and traded on the NFT marketplace.

[0108] When attempting to develop an NFT game across multiple platforms, if there is a platform where NFTs are prohibited, it cannot be developed across multiple platforms as is. To address this issue, special cards are managed on server device 30, and a separate area for managing NFTed special cards is provided in server device 40. This makes it possible to use special cards in card games while preventing access to NFTed cards on platforms where NFTs are prohibited, making it possible to develop an NFT game across multiple platforms as is.

[0109] Furthermore, by requiring that special processing be applied to create a special card when converting it into an NFT, and by imposing a limit on the number of special cards each user may own, the circulation volume of NFTed cards in the NFT marketplace is controlled, preventing sudden fluctuations in circulation volume. This makes it possible to prevent sudden fluctuations in the load on the server device 40 that accompanies NFT conversion. Furthermore, because the value of digital assets is influenced by the circulation volume in the trading market, it is possible to prevent sudden fluctuations in the value of cards.

[0110] [Variations] Although the embodiments of the present invention have been described in detail with reference to the drawings, the specific configuration is not limited to the above-described embodiments and can be modified as appropriate within the scope of the present invention. In this embodiment, monster cards, magic cards, and trap cards used in fighting games are used as examples, but the present invention is not limited to these. Cards used in card games may also be cards of athletes (for example, baseball players or soccer players) used in fighting games or training games. Furthermore, the present invention is not limited to cards (card objects) used in card games, but can be widely applied to game objects used in various games. Game objects are items and characters that exist in virtual space.

[0111] [Note] The present invention can be understood, for example, as follows. (1) A game object management system according to one embodiment of the present invention is a game object management system that manages game objects used in a game, and includes a first management means (333a) that manages game objects possessed by a user that do not satisfy predetermined requirements using first identification information and a number assigned to each type of game object, and a second management means (333b) that manages game objects possessed by the user that satisfy the predetermined requirements using second identification information assigned to each game object.

[0112] (9) A game object management device according to one embodiment of the present invention is a game object management device that manages game objects used in a game, and is equipped with a first management means (333a) that manages game objects possessed by a user that do not satisfy specified requirements using first identification information and a number assigned to each type of game object, and a second management means (333b) that manages game objects possessed by the user that satisfy the specified requirements using second identification information assigned to each game object.

[0113] (10) A game object management method according to one aspect of the present invention is a game object management method for managing game objects used in a game, and includes the steps of managing game objects owned by a user that do not meet certain requirements using first identification information and a number assigned to each type of game object, and managing game objects owned by the user that meet the certain requirements using second identification information assigned to each game object.

[0114] (11) A program according to one aspect of the present invention is a program for managing game objects used in a game, and causes a computer to function as a first management means (333a) that manages game objects possessed by a user that do not satisfy predetermined requirements using first identification information and a number assigned to each type of game object, and a second management means (333b) that manages game objects possessed by the user that satisfy the predetermined requirements using second identification information assigned to each game object.

[0115] According to the inventions (1), (9), (10) or (11) above, game objects possessed by a user can be treated as unique objects.

[0116] (2) In one aspect of the present invention, in the aspect (1) above, a third management means (433) is provided for managing game objects managed by the second management means (333b), and when a predetermined setting is made to a game object managed by the third management means (433), the second management means (333b) sets the game object for which the predetermined setting has been made to be unusable in the game. According to the invention related to (2) above, game objects that are unique objects can be traded, for example, on an NFT marketplace.

[0117] (3) In one aspect of the present invention, in the above aspect (1) or (2), the predetermined requirement is that a predetermined process be applied to the game object. According to the invention related to (3) above, the appearance of the unique game object can be made different from that of a normal game object.

[0118] (4) In one aspect of the present invention, in any one of the aspects (1) to (3) above, the game object management system described in 1 or 2 is characterized in that the game objects managed by the second management means (333b) cannot be exchanged for other objects within the game. According to the invention related to (4) above, it is possible to reduce the risk of accidentally losing a game object that has been made a unique object.

[0119] (5) In one aspect of the present invention, in any one of the aspects (1) to (4) above, the game object managed by the second management means (333b) can be changed to a game object managed by the first management means (333a). According to the invention related to (5) above, a game object that has been made a unique object can be returned to a normal game object.

[0120] (6) In one aspect of the present invention, in any one of the above aspects (1) to (5), the second management means (333b) adds history information of the game object. According to the invention related to (6) above, it is possible to check the history of game objects that have been made into unique objects.

[0121] (7) In one aspect of the present invention, in any one of the above aspects (1) to (6), a processing applying means (334) is provided that applies a used processing to the game object managed by the second management means (333b). According to the invention related to (7) above, the appearance of the game object that is made a unique object can be made different from that of a normal game object.

[0122] (8) In one aspect of the present invention, in the above aspect (7), when certain conditions are met, the processing means can apply a used look, and the user can choose whether or not to apply the used look. According to the invention related to (8) above, a user who does not like the used look can choose not to apply the used look. [Explanation of symbols]

[0123] NS: network system, 10: terminal device, 20: network, 30: server device, 31: CPU, 32: ROM, 33: RAM, 34: communication unit, 35: storage device, 40: server device, 41: CPU, 42: ROM, 43: RAM, 44: communication unit, 45: storage device, 310: communication unit, 320: storage unit, 324: card management data storage unit, 330: control unit, 333: card management unit, 333a: first management unit, 333b: second management unit, 334: processing unit, 410: communication unit, 420: storage unit, 424: card management data storage unit, 430: control unit, 433: card management unit

Claims

1. A game object management system that manages game objects used in a game, a first management means for managing game objects possessed by a user that do not satisfy a predetermined requirement by using first identification information and a number assigned to each type of game object; A game object management system characterized by comprising a second management means for managing game objects possessed by the user that satisfy the specified requirements using second identification information assigned to each game object.

2. a third management means for managing game objects managed by the second management means; The game object management system described in claim 1, characterized in that when a predetermined setting is made to a game object managed by the third management means, the second management means sets the game object for which the predetermined setting has been made to be unusable in the game.

3. 3. The game object management system according to claim 1, wherein the predetermined requirement is that the game object be given a predetermined processing.

4. 3. A game object management system according to claim 1, wherein the game object managed by said second management means is not exchangeable with other objects within said game.

5. 3. The game object management system according to claim 1, wherein the game object managed by the second management means can be changed to a game object managed by the first management means.

6. 3. The game object management system according to claim 1, wherein said second management means adds history information of the game object.

7. 3. A game object management system according to claim 1, further comprising a processing applying means for applying a used finish to the game objects managed by said second management means.

8. When a certain condition is met, the processing means can apply a used finish to the product.

8. The game object management system according to claim 7, wherein the user can select whether or not to apply a used look to the object.

9. A game object management device that manages game objects used in a game, a first management means for managing game objects possessed by a user that do not satisfy a predetermined requirement by using first identification information and a number assigned to each type of game object; A game object management device characterized by having a second management means for managing game objects possessed by the user that meet the specified requirements using second identification information assigned to each game object.

10. A game object management method for managing game objects used in a game, comprising: managing game objects possessed by the user that do not satisfy a predetermined requirement using first identification information and a number assigned to each type of game object; A game object management method characterized by comprising a step of managing game objects possessed by the user that meet the specified requirements using second identification information assigned to each game object.

11. A program for managing game objects used in a game, a first management means for managing game objects possessed by a user that do not satisfy a predetermined requirement by using first identification information and a number assigned to each type of game object; A program for causing a computer to function as a second management means for managing game objects possessed by the user that meet the specified requirements using second identification information assigned to each game object.

Images