Game object management system, device, method, and program

Abstract

This game object management system for managing game objects used in a game includes a first management means (333a) for managing game objects that do not satisfy a predetermined requirement from among game objects possessed by a user, by first identification information and a number imparted for each type of game object, and a second management means (333b) for managing game objects that satisfy the predetermined requirement from among game objects possessed by the user, by second identification information imparted for each game object.

Description

Game object management system, device, method and program

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

[0002] In recent years, network systems have been provided that issue non-fungible tokens (NFTs) for in-game digital content and record transactions on a blockchain. Patent Literature 1 (PTL 1) discloses a technology related to in-game digital content transactions, which aims to control the circulation of game media. The technology includes an information processing device that grants a first right to a user, the first right being selected by lottery from one or more rights, each of which has a game medium that is the subject of the right, and a modification unit that, when the user uses the first right, modifies the first game medium that is the subject of the first right in a first trading system from a first state in which the first game medium is ineligible for trading with other users to a second state in which the first game medium is tradable with other users.

[0003] Furthermore, as a technology for managing digital cards in a digital TCG (Trading Card Game), Patent Document 2 discloses a configuration for storing information about multiple digital cards in a manner that allows each card to be uniquely identified, even if they are the same digital card.

[0004] Patent No. 7428926 Patent No. 7510475

[0005] In order to manage game objects used in a game, identification information is assigned to each type of game object, i.e., game objects of the same type are sometimes assigned the same identification information. 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 transactions using NFTs as described above, it is necessary to be able to treat game objects owned by a user 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.

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

[0008] FIG. 1 is a diagram illustrating an example of the configuration of a network system. FIG. 2 is a diagram illustrating a game progression screen. FIG. 3A is a diagram illustrating monster cards. FIG. 3B is a diagram illustrating magic cards. FIG. 4 is a diagram illustrating the functional configuration of a server device. FIG. 5 is a diagram illustrating the functional configuration of a server device. FIG. 6A is a diagram illustrating management of normal cards. FIG. 6B is a diagram illustrating management of special cards. FIG. 7A is a diagram illustrating management of normal cards. FIG. 7B is a diagram illustrating management of special cards. FIG. 8A is a diagram illustrating management of NFT cards. FIG. 8B is a diagram illustrating management of NFT cards. FIG. 9 is a diagram illustrating an example of history information. FIG. 10A is a diagram illustrating an example of a condition under which a used finish can be applied. FIG. 10B is a diagram illustrating an example of a condition under which a sepia finish can be applied. FIG. 10C is a diagram illustrating an example of a condition under which a noise finish can be applied. FIG. 10D is a diagram illustrating an example of a condition under which a damaged finish can be applied. FIG. 10E is a diagram illustrating an example of a condition under which a sand finish can be applied. Fig. 10F is a diagram for explaining an example of a condition that allows stone processing to be applied. Fig. 11 is a diagram showing a selection screen. Fig. 12 is a diagram showing a card list screen. Fig. 13 is a diagram showing an enlarged display screen. Fig. 14 is a diagram showing a possession details screen. Fig. 15 is a diagram showing an exchange screen. Fig. 16 is a diagram showing an enlarged display screen. Fig. 17 is a diagram showing a special card list screen. Fig. 18 is a diagram showing an enlarged display screen. Fig. 19 is a diagram showing a special card list screen. Fig. 20 is a flowchart showing an example of processing by the network system.

[0009] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. [Network System Configuration] Fig. 1 is a diagram showing an example configuration of a network system NS according to this embodiment. In the network system NS, a terminal device 10, a server device 30, and a server device 40 are connected via a network 20 via a wired or wireless connection so that data can be transmitted and received between them. 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 for a game using card objects (hereinafter referred to as a "card game"). Card objects are card-shaped items that exist in a virtual space. Hereinafter, they will be abbreviated to "cards." 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 converted into NFTs so that they can be traded on the NFT marketplace. A user uses a 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 control programs stored in the ROM 12 into the RAM 13 and executes various processes. The ROM 12 stores control programs (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 CPU 11's main memory or work area. 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, various game-related data, programs related to NFT card transactions, and various data related to NFT card transactions.

[0014] The functions and processes of the terminal device 10 are realized by the CPU 11 reading and executing a program stored in the ROM 12 or the storage device 17. 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. 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 has a CPU 31, a ROM 32, a RAM 33, a communication unit 34, and a storage device 35. The CPU 31 reads 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 game-related programs, user identification information such as the ID of the user operating the terminal device 10, and various other user-specific information 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 loads a control program stored in the ROM 42 into the RAM 43 and executes various processes. The ROM 42 stores a 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 involving NFT cards, user identification information such as the ID of the user operating the terminal device 10, and various other user-specific information required for transactions involving NFT cards. Note that some of this information may be stored in a database (not shown) or the like.

[0017] [Description of Card Game] An overview of the card game in this embodiment will be described. FIG. 2 is a diagram showing a game progression screen G1 displayed on the display unit 16 of the terminal device 10. The game progression 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 player's cards and the opponent's cards are arranged and displayed in the player's hand PAT and the player's field PAB, and the opponent's hand PBT and the opponent's 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 a predetermined number of cards that are any combination of cards that the user possesses, and a plurality of 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. Meanwhile, 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 activating the effects of each card by placing cards from their hand PAT onto their field PAB, or by comparing the power of cards previously placed onto their field PAB with the power of cards on the opponent's field PBB. The user and opponent each start with a predetermined life point LP, and each player reduces their LP according to predetermined rules based on card selections and command executions, and 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, magic 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 accommodate 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 accommodate 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 magic 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. 3A is a diagram for explaining a monster card C1, and schematically shows an 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 instructions. ATK represents attack power, and DEF represents defense power; the higher these values, the greater the advantage in battle.

[0025] Spell cards and trap cards perform actions based on the Spell and Trap Commands described below, resulting in effects such as performing specific actions, restricting the actions your 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 your deck to your hand, and restricting your 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] 3B is a diagram for explaining a magic card C2, and schematically shows an 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, we will explain the commands that the user uses in conjunction with card selection. 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). Note that when placing a monster card, the user may be able to choose the orientation, such as vertical, horizontal, face up, or face down. For example, a monster card placed face up and vertically can attack. A monster card placed face up and 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 card 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 a monster card to be selected when placed on the player's field PAB is changed. The magic / trap command is a command that activates an effect associated with a magic card or trap card. Activating an effect refers to executing a process associated with an effect. When the user executes a process based on the magic / trap command, the effect associated with the selected magic card or trap card or a magic card or trap card to be selected is activated. The monster effect command is a command that activates a specified effect associated with a monster card that has an effect. When the user executes a process based on the monster effect command, the specified effect associated with the selected monster card or a monster card to be selected is activated.

[0034] The Special Summon command is a command that can be used when different execution conditions (conditions associated with the card) than face-up summon and face-down summon are met, and it is a command that places a monster card on the field. The Attack command is a command that attacks the opponent with a monster card. When the user executes a process based on the Attack command, an attack will be made against the opponent with the selected monster card or a monster card to be selected.

[0035] Each of these commands has a set of conditions under which the command's processing can be executed depending on the game situation. The game situation refers to various factors during gameplay, 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 the hand, the number of cards remaining in the deck, the number of monster cards on the field, the number of monster cards in the graveyard, the current phase of 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 of the rules within each turn. This card game progresses by alternating between the user's turn and the opponent's turn, with each turn consisting of multiple phases. A 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: Automatic effects that occur at this time are processed. (3) Main Phase 1: The user selects a command and a card, and processing is carried out regarding the summoning of monster cards and the activation of effects such as spells, traps, and monster effects. (4) Battle Phase: Starts with a battle operation by the user, where an attack is made against the opponent using cards placed on the field, and the results of the attack are processed. If no battle is conducted, this Battle Phase does not take place, and the game proceeds to the End Phase (6). (5) Main Phase 2: Only if the Battle Phase has taken place, processing similar to Main Phase 1 is carried out. This phase may be omitted. (6) End Phase: Processing to end the turn is carried out. After this, the game moves to the opponent's turn.

[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 designating your own card and the opponent's card to be attacked. For example, tap (touch the touch panel) a monster card placed in any of areas PA2(1), PA2(2), or PA2(3), slide your finger toward the opponent's card to be attacked, and untap (remove your finger from the touch panel). In addition, under certain circumstances (e.g., when there are no monster cards on the opponent's field 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 field (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 deck (PAB), 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 field (PAB), but cannot be executed if there is no monster card. A special summon command can be executed if a monster card that meets the special summoning conditions, which cannot be summoned by normal means, is in your hand (PAT) or your field (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 field (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] 4 is a diagram showing the functional configuration of the server device 30. 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 status 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 a user.

[0040] The card data storage unit 322 stores card data, which is information about cards used in the card game. Each type of card is associated with a card ID (hereinafter referred to as "identifier X"). 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 the card game played by the 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 the 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 by 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 regular cards. "Owned by a user" means that the card is associated with a player ID. "Managing cards" means collecting, organizing, and making accessible card information. The card management unit 333 includes a first management unit 333a that manages regular cards and a second management unit 333b that manages special cards. Figures 6A, 6B, 7A, and 7B are diagrams for explaining management of regular cards and special cards owned by a user.

[0047] The first management unit 333a manages cards owned by a user that are not specially processed as normal cards, using an identifier X and the number of cards. The first management unit 333a functions as a first management means in the present invention, and the identifier X corresponds to first identification information in the present invention. FIG. 6A is a diagram for explaining the management of normal cards owned by a certain user. As shown in FIG. 6A, the first management unit 333a manages cards by type in a management area 1 provided by the card management data storage unit 324 using 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. 6A, the user owns four normal cards, card B.

[0048] There is no upper limit to 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 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 each card. The second management unit 333b functions as a second management means in the present invention, and the identifier Y corresponds to the first identification information in the present invention. FIG. 6B is a diagram for explaining management of special cards possessed by a certain user. As shown in FIG. 6B, the second management unit 333b assigns identifier Y, which is a unique card ID, to each special card and manages each card using identifier Y and identifier X in management area 2 provided by the card management data storage unit 324. In the example of FIG. 6B, the user possesses one special card, Card B (special).

[0051] By applying special processing to a normal card owned by a user, the card can be made into a special card. As shown in FIGS. 7A and 7B, when special processing is applied to Card B, a normal card owned by a user, the card becomes Card B (special), a special card, and is assigned a unique identifier Y. As a result, from the state shown in FIGS. 6A and 6B, the number of Cards B (special) managed by the second management unit 333b increases by one as shown in FIG. 7B, and the number of Cards B managed by the first management unit 333a changes from four to three as shown in FIG. 7A. In addition to users applying special processing to cards they own through their own operations, cards may also be configured to already have special processing applied (become special cards) when acquired by the user through purchase or other means. For example, when 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 Figures 6B and 7B. The history information includes the details of the processing performed after the card became a special card, information on the timing of the processing, and the usage status of the card in the card game after the card 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 memory unit 320, and is constantly updated, and the URL is added. Figure 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 FIGS. 6B and 7B.

[0054] An upper limit is set on the number of cards (special cards) managed by the second management unit 333b. It is possible to increase the number of special cards 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 a 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] In addition, 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 references the PvP usage history of the special card, and when certain conditions, such as the number of times it has been used, are met, the special card becomes eligible for the 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 the 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 special processing or used processing is made visible.

[0059] Although special cards can be put up for sale on the NFT marketplace, some special cards (such as cards distributed on the assumption that each user will own one or two) cannot be put up for sale. Cards that are prohibited from being put up for sale are 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) has reached its upper limit, it is no longer 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 cannot be received are stored for an appropriate period of time in a specified area of ​​the memory unit 320.

[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 can be changed back into normal cards. For example, a special card can only be changed back into a normal card 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 for world championships) cannot be changed back into normal cards. A flag indicating that the card cannot be converted into a normal card will be added to the history information. When a special card is changed back into a normal card, if the processing it had when it was a normal card is saved in the history, it will be reverted to that processing. If the processing it had when it was a normal card is not saved in the history, such as when the card was obtained as a special card from the beginning, it will be reverted 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] 5 is a diagram showing the functional configuration of the server device 40. The server device 40 includes a communication unit 410, a storage unit 420, and a control unit 430. The communication unit 410 is connected 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 NFT card.

[0066] The transaction status data storage unit 423 stores transaction status data, which is information on the transaction status of NFT cards in the NFT marketplace. Since the transaction status changes from moment to moment depending on transactions of NFT cards, the transaction status data is updated as needed depending on transactions of NFT 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 transmission and reception of data with other devices, and controls the writing of data to and reading of data from the storage unit 420. The data management unit 431 outputs data acquired from the terminal device 10 and data read from the storage 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 to the storage unit 420.

[0069] The transaction processing unit 432 controls the execution of transactions using NFT cards. When the terminal device 10 accepts a transaction operation from a user, it notifies the server device 40 of the details of the transaction operation. The server device 40 executes processing to progress the transaction based on the details 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. The terminal device 10 then 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, NFT-enabled cards offered in the NFT marketplace among cards owned by each user. The card management unit 433b functions as a third management means according to the present invention. FIG. 8A is a diagram illustrating the management of NFT-enabled cards owned by a certain user. As shown in FIG. 8A, 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 (hereinafter referred to as "identifier Z") in the NFT marketplace. The identifier Z is information that uniquely identifies a card traded in 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 to NFT, they are converted to NFT at this time.

[0071] In addition, as shown in FIG. 8A , the card management unit 433 adds status information (preparing to put up for sale, putting up for sale) to each card. When an NFT card is set up for sale in the server device 40, the card management unit 433 sets the status information to "preparing to put up for sale." The setting to "preparing to put up for sale" is performed on the condition that the card is removed from the deck. As shown in FIG. 8A , when an NFT card (in the illustrated example, card B (special) (identifier Z: aaab, identifier Y: 900004)) is set up for sale, the card management unit 433 sets the status information of the card to "preparing to put up for sale." In response to this, as shown in FIG. 8B , the second management unit 333b of the server device 30 sets the card set up for sale (in the illustrated example, card B (special) (identifier Y: 900004)) to "unusable." A card set up for sale cannot be added to a deck. Furthermore, a card set up for sale cannot have its processing changed or be restored 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 server device 40 can also refer to the history of the NFT-converted card by referring to the URL.

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

[0074] Surface treatments are effects applied to the surface of a card. A common feature of 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 treatments include parallel treatment, ultra treatment, secret treatment, and prismatic treatment. Parallel treatment is a treatment that makes the illustration areas C13 and C23 and the frames C11 and C21 appear to be sprinkled with prism fragments. Ultra treatment is a foil treatment for the illustration areas C13 and C23. Secret treatment is a treatment that adds a granular vertical and horizontal grid pattern to the illustration areas C13 and C23. Prismatic treatment is a treatment that adds a granular vertical and horizontal grid pattern similar to the secret treatment to the illustration areas C13, C23, and the frames C11 and C21. In addition, for secret and prismatic finishes, there are three patterns for the display position of the grid pattern, and the pattern to be applied may be randomly determined. The grid pattern position pattern number (a value of 0, 1, or 2) is recorded as the card's history information (see Figure 9, a hidden parameter that the user cannot access). When the card is displayed, the display position of the grid pattern 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, an animation finish that makes monsters in illustration areas C13 and C23 appear to move may be considered a special finish. The used finish described below may also be considered a special finish. A metallic finish that gives the entire surface of the card a metallic color may also be considered a special finish. A relief finish that creates a rugged surface on the card, creating a three-dimensional appearance depending on the viewing angle, may also be considered a special finish.

[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 the 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] The stamp is a processing that makes it look like a stamp has been pressed in a predetermined position on the front of the card (for example, the lower right corner of the illustration areas C13 and C23). For example, a stamp with a specific design is pressed as a reward for achieving good results in an event, etc.

[0078] A screen for applying special effects (not shown) is displayed on the display unit 16 of the terminal device 10 that is using the card game provided by the server device 30. On this screen, a user can select a card to which the user wants to apply special effects, and then select the desired effect (surface effect, frame color effect, character color effect, stamp), thereby applying the special effect 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 added with 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 Finish] Distressed finishes can be applied to special cards. Distressed finishes primarily represent the fading, smudges, and creases that occur on physical cards, such as paper. Types of distressed finishes include sepia, noise, damage, sand, and stone finishes. Sepia finish fades the illustration areas C13 and C23 to a sepia tone. Note that changing the color of the frames C11 and C21 reduces the card's distinctiveness, so sepia finish is not applied to the frames. Noise finish applies digital noise to the illustration areas C13, C23, and frames C11, C21, sometimes creating a blurred outline. Distressed finish fades the illustration areas C13, C23, and frames C11, C21, creating a crease-like pattern on the card itself. Sand finish applies a dirt pattern resembling dust and sand to the illustration areas C13, C23, and frames C11, C21. Stone processing adds a stone slab-like texture to the 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 and C23 and frames C11 and C21.

[0081] Used effects can be applied depending on the card's usage history. Examples of certain conditions that allow the application of used effects are as follows: (1) For each special card in the deck, a determination is made, based on a predetermined probability, for each number of uses, whether or not to proceed to the unlock determination (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 the card's history. For magic and trap cards, the number of times its effect has been activated in the card's history. The probability of proceeding to the unlock determination is predetermined, for example, as shown in FIG. 10A . The higher the number of uses, the higher the probability of proceeding to the unlock determination. Note that if all effects (sepia, noise, damage, sand, and stone) have been unlocked up to level 3 (maximum), no determination is made as to whether or not to proceed to the unlock determination.

[0082] (2) The unlock determination is performed based on the probability determined by the parameters determined for each processing. Processing that has already reached level 3 (maximum) is not evaluated. As shown in Figure 10B, sepia processing is more likely to be unlocked the older the card (the longer you have owned and used the card). As shown in Figure 10C, noise processing is more likely to be unlocked the newer the card (the more you used the card soon after acquiring it). As shown in Figure 10D, damage processing is more likely to be unlocked the more times it has been destroyed (whether by battle or effect). 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 10E, sand processing (both processing methods exclusive to monster cards) is more likely to be unlocked the more times it has been destroyed by battle. As shown in Figure 10F, stone processing (a processing method exclusive to monster cards) is more likely to be unlocked the more times it has been destroyed by battle. For example, if a particular card is damaged and has been used 100-149 times (4% in Figure 10A) and destroyed 21-30 times (10% in Figure 10D), the probability of it being unlocked is 0.4%.

[0083] (3) When unlocked, the level of the processing increases by "1" and processing up to the reached level can be applied. 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 will be displayed to notify the user that the used processing can be applied. The server device 30 does not automatically apply the used processing, and the user can choose whether or not to apply the used processing. Once the conditions are met, the used processing can be applied at any time (even later) and any number of times.

[0084] [Screen Transition Examples] 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 Card" 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 user's own cards.

[0086] When "Card List" is selected on the selection screen G2 of 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] The card list screen G3 also 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 not be included in a deck, only one of which may be included. A semi-limited card refers to a card that may not be included in a deck, only two of which may be included. 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 of the card list screen G3 is selected, the display 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 of the card list screen G3 is selected. The enlarged display screen G4 displays the full effect of the processing applied to Card C. The cross star on Card C symbolically indicates that a special processing has been applied. Additionally, the number of cards of the same type (a / b / c / d) held by the player 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, shine processing cards, and basic processing cards, respectively. As mentioned above, premium processing, shine processing, and basic processing are applied to regular cards, unlike special processing. Even when 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 333 a of the server device 30 .

[0089] In addition, the enlarged display screen G4 displays a possession details button E41 and an exchange button E42. Operating the possession details button E41 on the enlarged display screen G4 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, a card C can be selected from the card list CL61 and exchanged 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 of 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, the thumbnail of the monster card of monster b on the left in the card list CL51 of the possession details screen G5 is selected. The enlarged display screen G7 displays the full effect of the processing applied to card C. The cross star drawn on card C schematically indicates that special processing has been applied. In addition, the numbers a / b / c / d of cards of the same type held are 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 the card C is a normal card. When the history button E71 is operated, a dialog box presenting history information for 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. A card list CL81 is displayed on the special card list screen G8. 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 card is displayed. Each thumbnail is designed to reflect some degree of special processing. In the illustrated example, there are special card management frames 1 to 32, starting 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] Additionally, the special card list screen G8 displays a purchase button E81 for a special card management slot. Operating the purchase button E81 transitions to a shop screen (not shown), where a special card management slot can be purchased. When a "special card" is selected on the selection screen G2, 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 any of the cards managed by the second management unit 333b of the server device 30 have not yet been converted to NFT, they are converted to NFT 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 effects applied to card C are displayed in full effect. Note that the cross star drawn on card C schematically indicates that special effects have been applied. In addition, the numbers a / b / c / d of cards of the same type held are displayed in the lower right of card C.

[0096] The enlarged display screen G9 also displays a history button E91, a prepare to put up for sale button E92, and a normalize 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 button 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 the 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 set as unusable in the game. Thereafter, when a listing operation is performed on the server device 40 side (NFT marketplace side) for a special card C for which listing preparation has been performed, the thumbnail (management frame 1) of the special card for which a listing operation has been performed 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 via a confirmation screen (not shown). When converting a special NFT card to a normal card, if authentication by the NFT marketplace is required, the normalize button E93 becomes active only if the 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 returns to that processing; if the processing performed when the card was a normal card is not saved in the history, the card returns to basic processing.

[0100] [Example of processing by the network system] A processing flow 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 processing flow will be described 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.

[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 the operation on the deck editing screen. Description of the operation on the deck editing screen and the processing in accordance with it 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 yet been converted to NFT, they are converted to NFT 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 regular 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 owned by the user using an identifier Y assigned to each card. A regular card can be transformed into a special card by applying special processing, or a special card can be reverted to a regular 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 on which NFT is prohibited, it cannot be developed across multiple platforms as is. To address this issue, special cards are managed in server device 30, and a separate area for managing special NFT cards is provided in server device 40, providing a separate area. This makes it possible to use special cards in card games while preventing access to NFT cards on platforms where NFT is prohibited, and makes it possible to develop NFT games across multiple platforms as is.

[0109] Furthermore, by requiring that special processing be applied to make the card special when converting it to NFT and by imposing a limit on the number of special cards each user may own, the circulation volume of NFT converted cards in the NFT marketplace is controlled, and sudden fluctuations in the circulation volume are suppressed. This makes it possible to suppress 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 suppress sudden fluctuations in the value of cards.

[0110] [Modifications] While 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 without departing from the spirit of the present invention. In this embodiment, monster cards, magic cards, and trap cards used in competitive games are used as examples, but the present invention is not limited to these. Any card used in a card game may be used, such as a card of a sports player (e.g., a baseball player or a soccer player) used in a competitive game or a training game. Furthermore, the present invention is not limited to cards (card objects) used in card games, and can be widely applied to game objects used in various games. Game objects are items and characters that exist in a virtual space.

[0111] It should be noted that the above-described embodiments are merely examples of specific embodiments for carrying out the present invention, and the technical scope of the present invention should not be construed as being limited by these embodiments. In other words, the present invention can be carried out in various forms without departing from its technical concept or main features.

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

[0113] (9) A game object management device according to one aspect of the present invention is a game object management device 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.

[0114] (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, comprising the steps of: managing 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 managing game objects possessed by the user that satisfy the predetermined requirements using second identification information assigned to each game object.

[0115] (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 owned 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 owned by the user that satisfy the predetermined requirements using second identification information assigned to each game object. Note that one aspect of the present invention may be a computer-readable storage medium that stores the program.

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

[0117] (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 for 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 unusable in the game. According to the invention related to (2) above, the game object that has been made a unique object can be traded, for example, in an NFT marketplace.

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

[0119] (4) In one aspect of the present invention, in any one of the aspects (1) to (3) above, the game object management system according to claim 1 or 2 is characterized in that the game objects managed by the second management means (333b) are not exchangeable with other objects within the game. According to the invention according to (4) above, it is possible to reduce the risk of accidentally losing a game object that has been made a unique object.

[0120] (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.

[0121] (6) In one aspect of the present invention, in any one of the aspects (1) to (5) above, 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 the game object that has been made a unique object.

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

[0123] (8) In one aspect of the present invention, in the aspect (7) above, when certain conditions are met, the processing means can apply a used look, and the user can select 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 select not to apply the used look.

Claims

1. A game object management system for managing game objects used in a game, comprising: a first management means for managing game objects owned 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 for managing game objects owned by the user that satisfy the predetermined requirements using second identification information assigned to each game object.

2. A game object management system as described in claim 1, further comprising a third management means for managing game objects managed by said second management means, wherein when a predetermined setting is made to a game object managed by said third management means, said second management means sets the game object for which said predetermined setting has been made to be unusable in said game.

3. A game object management system as described in claim 1 or 2, characterized in that the predetermined requirement is that the game object has been given a predetermined processing.

4. A game object management system according to claim 1 or 2, characterized in that the game objects managed by said second management means are not exchangeable with other objects within said game.

5. A game object management system according to claim 1 or 2, characterized in that the game object managed by said second management means can be changed to a game object managed by said first management means.

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

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

8. A game object management system as described in claim 7, characterized in that 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.

9. A game object management device for managing game objects used in a game, comprising: a first management means for managing 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 for managing game objects possessed by the user that satisfy the predetermined 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 the steps of: managing 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 managing game objects owned by the user that satisfy the specified requirements using second identification information assigned to each game object.

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

Images