WO2023190005A1 - デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム - Google Patents

デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム Download PDF

Info

Publication number
WO2023190005A1
WO2023190005A1 PCT/JP2023/011436 JP2023011436W WO2023190005A1 WO 2023190005 A1 WO2023190005 A1 WO 2023190005A1 JP 2023011436 W JP2023011436 W JP 2023011436W WO 2023190005 A1 WO2023190005 A1 WO 2023190005A1
Authority
WO
WIPO (PCT)
Prior art keywords
asset
user
token
fungible
digital data
Prior art date
Application number
PCT/JP2023/011436
Other languages
English (en)
French (fr)
Inventor
太郎 鵜川
寛史 大橋
Original Assignee
株式会社プレイシンク
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社プレイシンク filed Critical 株式会社プレイシンク
Publication of WO2023190005A1 publication Critical patent/WO2023190005A1/ja

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/792—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for payment purposes, e.g. monthly subscriptions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof

Definitions

  • the present invention relates to a digital data management system, a digital data management method, and a program.
  • Games are known in which game assets are converted into non-fungible tokens and can be traded.
  • the traded game assets can be used not only in the original game, but also in other corresponding games.
  • Patent Document 1 discloses an example of this type of game.
  • transactions of game assets within the game are managed by a centralized database under the control of the operator, while sales on a decentralized exchange and other transactions outside the game are It will be managed by the blockchain as a non-fungible tokenized game asset transaction.
  • some characters used in games are of a type in which the parameters that characterize the character change. For example, if we take the character of a soccer player used in a soccer game, his attack power and defense power change depending on the results of gameplay and the results of reinforcement (training) performed by the user, and the club he belongs to changes. In some cases.
  • these changing parameters will be collectively referred to as “changing parameters”, and parameters that do not change, such as the character's name, will be collectively referred to as “steady parameters”.
  • one of the objects of the present invention is to provide a digital data management system, a digital data management method, and a program that can describe change parameters in the metadata of non-fungible tokens of game assets.
  • a digital data management system includes a database that stores an asset table that stores one or more asset data in association with a user ID indicating a user, and a server that is connected to the database.
  • the server issues, in response to the user's operation, a non-fungible token indicating one of the one or more asset data stored in the asset table, and the issued non-fungible token.
  • the asset data corresponding to the token is deleted from the asset table, and in response to the user's operation, the asset data corresponding to the issued non-fungible token is added to the asset table, and the added asset
  • a digital data management system that burns the non-fungible token corresponding to data.
  • a digital data management method is a digital data management method executed by a computer connected to a database storing an asset table storing one or more asset data in association with a user ID indicating a user, the method comprising: The computer, in response to the user's operation, issues a non-fungible token indicating one of the one or more asset data stored in the asset table, and corresponds to the issued non-fungible token. the step of deleting the asset data from the asset table, and the computer adding the asset data corresponding to the issued non-fungible token to the asset table in response to the user's operation;
  • the digital data management method includes the step of incinerating the non-fungible token corresponding to the asset data.
  • the program according to the present invention is stored in the asset table in response to an operation by the user, in a computer connected to a database that stores an asset table that stores one or more asset data in association with a user ID indicating a user. issuing a non-fungible token indicating one of the one or more asset data set, and deleting the asset data corresponding to the issued non-fungible token from the asset table; and the user's operation. , adding the asset data corresponding to the issued non-fungible token to the asset table, and burning the non-fungible token corresponding to the added asset data. This is the program.
  • the asset data when a user transacts asset data, the asset data is non-fungible tokenized and deleted from the asset table, while when the user changes a change parameter (for example, using the asset data When playing a game), the asset data is returned to the asset table and the issued non-fungible token is burned, so change parameters should be written in the metadata of the non-fungible token of the game asset. becomes possible.
  • FIG. 1 is a diagram showing the configuration of a system including a digital data management system 1 according to the present embodiment.
  • 1 is a diagram showing an example of the hardware configuration of a digital data management system 1 and a user terminal 3.
  • FIG. (a) is a diagram showing the structure of an asset table T1 stored in the game database 7
  • (b) is a diagram showing the structure of an asset token table T2 stored in the game database 7.
  • (a) and (b) are diagrams illustrating processing executed by the digital data management system 1 using the asset table T1 and the asset token table T2.
  • 3 is a processing flow diagram showing processing executed by the digital data management system 1, the user terminal 3, and the blockchain network 4.
  • FIG. 3 is a processing flow diagram showing processing executed by the digital data management system 1, the user terminal 3, and the blockchain network 4.
  • FIG. 3 is a processing flow diagram showing processing executed by the digital data management system 1, the user terminal 3, and the blockchain network 4.
  • FIG. 3 is a processing flow diagram showing processing executed by the digital data management system 1, the user
  • NFT Non-Fungible Token
  • FIG. 1 is a diagram showing the configuration of a system including a digital data management system 1 according to the present embodiment.
  • a digital data management system 1 is a system that manages asset data, which is digital data owned by users, and as shown in FIG. Connected to 4. Further, the digital data management system 1 is configured to include a game server 5, an NFT bridge server 6, and a game database 7.
  • the game database 7 is configured to store an asset table T1 and an asset token table T2.
  • the asset data is data indicating player cards used in an online soccer game.
  • the game server 5 has a function for the user to purchase player cards from a game operator, a function for the user to develop the player owned by the user through game execution (that is, a function for changing the change parameters of the player card), and a function for the user to develop the player owned by the user through game execution.
  • a function to issue an NFT of a player card in response to an instruction from a user, and a function to add a user's player card based on the NFT of a player card purchased by the user from another person will be implemented. The details of each will be described later.
  • FIG. 2 is a diagram showing an example of the hardware configuration of the digital data management system 1 and the user terminal 3.
  • the digital data management system 1 and the user terminal 3 may each be configured by a computer 100 having the illustrated configuration.
  • the computer 100 that constitutes the digital data management system 1 is a high-performance computer that functions as a server.
  • the computer 100 constituting the user terminal 3 is a personal computer such as a personal computer, a tablet terminal, or a smartphone.
  • the computer 100 may be a computer configured by combining a plurality of computers.
  • the computer 100 has a configuration in which a CPU (Central Processing Unit) 101, a storage device 102, an input device 103, an output device 104, and a communication device 105 are interconnected via a bus 106. ing.
  • a CPU Central Processing Unit
  • the CPU 101 is a device that controls each part of the computer 100 and reads and executes various programs stored in the storage device 102.
  • the game server 5 and the NFT bridge server 6 shown in FIG. It's a computer. However, when the computer 100 is configured by combining a plurality of computers as described above, the game server 5 and the NFT bridge server 6 may be distributed and implemented in a plurality of computers. , the functions of the game server 5 and the NFT bridge server 6 are realized by the CPUs 101 of each computer executing programs stored in the respective storage devices 102. Further, the programs executed by the CPU 101 of the user terminal 3 include browser software or a mobile application that has a function of accessing other devices via the network 2.
  • the storage device 102 includes a main storage device such as a DRAM (Dynamic Random Access Memory), and an auxiliary storage device such as a hard disk, and stores various programs for executing the operating system of the computer 100 and various applications, and these. A device that plays the role of storing data used by programs.
  • the game database 7 shown in FIG. 1 is implemented in the storage device 102 of the digital data management system 1.
  • the input device 103 is a device that receives user input operations and supplies them to the CPU 101, and includes, for example, a keyboard, a mouse, and a touch panel.
  • the output device 104 is a device that outputs the processing results of the CPU 101 to the user, and includes, for example, a display and a speaker.
  • the communication device 105 is a device for communicating with an external device, and transmits and receives data according to instructions from the CPU 101.
  • the digital data management system 1 and the user terminal 3 are each configured to use this communication device 105 to communicate with other devices including the blockchain network 4 and network 2 shown in FIG.
  • the blockchain is configured to record the transfer of NFT ownership (transfer transaction) and the association of newly generated NFTs with any wallet address (issuance transaction).
  • the blockchain network 4 is either the Ethereum network, which is classified as a public chain, or the LINE blockchain, which is classified as a private chain. In the following, the explanation will be continued assuming that the blockchain network 4 is the Ethereum network.
  • each block constituting the blockchain includes a block header and data (transaction data) indicating the specific contents of a transaction.
  • the block header includes a Merkle root, which is data obtained by compressing the size of transaction data, a hash value of the previous block, and a nonce value, which is an arbitrary character string.
  • the hash value of that block in order to connect a new block to the blockchain, the hash value of that block must meet a predetermined condition (for example, a value starting with "000"). Rules are set.
  • a miner who wants to record a block in a blockchain performs work (mining) to find a nonce value using brute force so that the hash value of the block header of that block satisfies the above predetermined condition.
  • the miner who succeeds in discovering the nonce value first will connect that block to the blockchain, completing the recording of the transaction on the blockchain.
  • the blockchain network 4 is the Ethereum network, those who wish to record transactions on the blockchain must pay a fee called "gas" in virtual currency. Gas is paid as a reward to miners who successfully concatenate blocks. This gas can become a cost bottleneck when converting game asset data into NFTs.
  • blockchains without gas there are also blockchains without gas, so if the presence of gas is not acceptable from a cost perspective, a blockchain without gas may be used as the blockchain network 4.
  • the asset table T1 includes information such as name, club, rarity, favorite position, attack power, defense power, power, speed, etc. in association with the player ID uniquely assigned to each player card.
  • This is a table that stores stamina, technique, owner, and deletion flag. Among these, the player ID and name are constant parameters that do not change.
  • club, rarity, favorite position, attack power, defense power, power, speed, stamina, and technique are change parameters that may change depending on the user's operation results while the game is progressing.
  • the owner field stores a user ID indicating the user who owns this player card.
  • the deletion flag is Boolean data that is true (first value) when the corresponding player card has been logically deleted, and false (second value) otherwise.
  • the asset token table T2 stores, for each NFT player card, the corresponding NFT token ID, the corresponding player ID, and the deletion flag in association with each other. It's a table.
  • the deletion flag is Boolean data that is true (first value) when the corresponding token ID is logically deleted, and false (second value) otherwise.
  • FIGS. 4(a) and 4(b) are diagrams illustrating processing executed by the digital data management system 1 using the asset table T1 and asset token table T2 as described above.
  • FIG. 4(a) shows the process of turning a player card into an NFT
  • FIG. 4(b) shows the process of returning the player card turned into an NFT into the asset table T1.
  • a plurality of player cards C including the illustrated player card C0 are stored in the user's asset table T1.
  • the plurality of player cards C are purchased by the user from the game operator or another person.
  • the digital data management system 1 issues (mint) an NFT indicating the player card C0 , and A process is performed to delete the player card C0 from the asset table T1.
  • the digital data management system 1 deletes the player card C 0 by setting the deletion flag of the player card C 0 to true, rather than erasing the record of the player card C 0 from the asset table T1. .
  • the digital data management system 1 acquires a token ID indicating the issued NFT from the blockchain network 4, and adds the acquired token ID to the asset token table T2 in association with the player ID of the player card C0 . I do. At this time, the digital data management system 1 sets the deletion flag corresponding to the acquired token ID to false.
  • the digital data management system 1 first generates an NFT for a player card based on information stored in the asset table T1. At this time, the digital data management system 1 describes the steady parameters and changing parameters (see FIG. 3(a)) of the corresponding player card in the NFT metadata. Next, the digital data management system 1 generates an issuance transaction that associates the generated NFT with the user's wallet address, and transmits it to the blockchain network 4. The blockchain network 4 issues a token ID for the received issued transaction, and records the block including the received issued transaction on the blockchain. After the recording is completed, the blockchain network 4 notifies the digital data management system 1 that the recording is completed. In response to receiving this notification, the digital data management system 1 deletes the player card C0 from the asset table T1, and also associates the player ID of the corresponding player card with the NFT token ID to create a new card in the asset token table. Add to T2.
  • NFT player cards can be traded in the market and can also be used in other compatible games.
  • the game server 5 is configured to limit the player cards that the user can use in the game to those player cards that are stored in the asset table T1 with the deletion flag in a false state. Therefore, the user cannot use the player card for which the NFT has been issued for the game realized by the game server 5.
  • the change parameters of the player card that issued the NFT will not change until the player card is returned to the asset table T1 through the process described later, so the change parameters included in the NFT metadata and the change parameters in the asset table T1 There will be no discrepancy with the change parameters included in the player card.
  • the user uses the user terminal 3 to delete the player card C0.
  • the digital data management system 1 burns the NFT of the player card C0 and deletes the corresponding token ID from the asset token table T2. Furthermore, processing is performed to add information on the player card C0 to the asset table T1. In this case, the digital data management system 1 does not delete the record of the corresponding token ID from the asset token table T2, but sets the deletion flag stored in the asset token table T2 in association with the corresponding token ID to true. By doing so, the corresponding token ID is deleted.
  • the digital data management system 1 adds the information of the player card C0 to the asset table T1 by setting the deletion flag stored in the asset table T1 in association with the corresponding player ID to false. . By adding the information on the player card C0 to the asset table T1, the user can use the player card C0 again in the game.
  • the digital data management system 1 sends information to the blockchain network 4 in order to detect that a player card NFT transfer transaction has occurred. Perform access regularly.
  • the digital data management system 1 detects that a player card NFT transfer transaction has occurred, the user ID stored as the owner in the asset table T1 in association with the corresponding player ID is indicated by the transfer transaction. Update the user ID to the new user ID.
  • the owner of the player card in the game will be the same as the owner of the NFT.
  • 5 to 8 are process flow diagrams showing processes executed by the digital data management system 1, user terminal 3, and blockchain network 4.
  • the processing performed by the digital data management system 1 according to the present embodiment will be described in more detail with reference to these figures.
  • FIG. 5 shows the process when a user purchases a player card from a game operator.
  • a list of purchasable player cards is transmitted from the game server 5 to the user terminal 3 (step S1).
  • a player purchase request specifying the selected player card is sent from the user terminal 3 to the game server 5 (step S3). ).
  • the game server 5 executes a predetermined payment process (step S4) with the user terminal 3, and then generates a corresponding player card (step S5).
  • the game server 5 assigns a player ID that is not yet recorded in the asset table to the player card to be generated.
  • the game server 5 adds the generated player card to the asset table T1 (step S6), and notifies the user terminal 3 of the purchase result (step S7).
  • the above process completes the purchase of the player card, and the user can now use the purchased player card in the game.
  • FIGS. 6 and 7 show a process when one of one or more player cards owned by a user is turned into an NFT.
  • a request for a list of owned player cards is sent from the user terminal 3 to the game server 5 (step S10).
  • the game server 5 searches for a player card stored in the asset table T1 in association with the user ID of the user who sent the request (step S11), and obtains the search results (step S12). .
  • a list of owned player cards is generated based on the search results and transmitted to the user terminal 3 (step S13).
  • the user terminal 3 When the user terminal 3 displays the list of owned player cards received from the game server 5 to the user, and the user performs an operation to select one or more player cards from the list that he/she wishes to turn into an NFT (step S14), The user terminal 3 transmits an NFT conversion request specifying the selected player card to the NFT bridge server 6 (step S15).
  • the NFT bridge server 6 Upon receiving this request, the NFT bridge server 6 searches the asset table T1 and the asset token table T2 for information on the player card specified by the request (step S16), and as a result of the search, it searches for information on the player card specified by the request, , obtains information on NFTs issued so far for player cards (step S17). Based on the NFT information acquired in this way, the NFT bridge server 6 determines whether an NFT has been issued for the corresponding player card (step S18). Specifically, if there is an NFT that has been issued for a player card that has a false deletion flag stored in the asset token table T2, it is determined that it has been issued, and In other cases, it may be determined that the document has not been issued.
  • step S18 If it is determined in step S18 that it has been issued, the NFT bridge server 6 transmits an error notification to the user terminal 3 (step S19). In this case, no processing is performed to issue the NFT. This prevents multiple NFTs from being issued simultaneously for one player card.
  • the NFT bridge server 6 that determined in step S18 that the NFT has not been issued generates an NFT using the information (steady parameters and changing parameters) acquired in step S17, and requests the blockchain network 4 to issue it. (Step S21). Specifically, an issuance transaction that associates the generated NFT with the wallet address of the user of the user terminal 3 is generated and transmitted to the blockchain network 4. The blockchain network 4 executes a process for recording the received issued transaction on the blockchain, and notifies the NFT bridge server 6 of the result (step S22).
  • the NFT bridge server 6 determines whether the NFT has been successfully issued based on the notification received from the blockchain network 4 (step S23). If it is determined that the process has failed, the NFT bridge server 6 transmits an error notification to the user terminal 3 (step S24). In this case, the NFT will not be issued as a result.
  • step S23 deletes the corresponding player card from the asset table T1 (step S25), as shown in FIG.
  • the token ID is added to the asset token table T2 in association with the corresponding player ID (step S26).
  • step S25 is specifically a process of setting the corresponding deletion flag to true.
  • step S26 the NFT bridge server 6 sets the corresponding deletion flag to false.
  • the NFT bridge server 6 After completing up to step S26, the NFT bridge server 6 transmits a success notification to the user terminal 3 (step S27). Through the processing up to this point, conversion of the player card into NFT is completed. At this stage, the information on the NFT player card has been deleted from the asset table T1 (more precisely, the deletion flag is set to true), so the user cannot use this player card in the game. Therefore, the change parameter no longer changes.
  • the processing after step S30 shown in FIG. 7 shows the processing when the NFT of the player card is traded in the market.
  • the NFT bridge server 6 periodically transmits a transaction event detection result request to the blockchain network 4 to detect the occurrence of an NFT transfer transaction of a player card (step S30).
  • the blockchain network 4 searches for the player card NFT transfer transaction from past transactions, and sends the result to the NFT bridge server 6 as a detection result (step S31).
  • the NFT bridge server 6 determines whether or not the NFT of the player card has been transferred (step S32). As a result, if it is determined that a transfer has occurred, the NFT bridge server 6 converts the user ID stored in the asset table T1 in association with the player card targeted for transfer into the user ID indicating the transfer destination user. (step S33), and notifies each of the source user and the destination user that the user ID has been updated (step S34). On the other hand, the NFT bridge server 6 that determines in step S32 that no transfer has occurred ends the process without performing steps S33 and S34. Through the above processing, when an NFT transaction occurs in the market, the result can be reflected in the asset table T1.
  • FIG. 8 shows the process of returning the NFT player card to the asset table T1.
  • a request for a list of owned NFTs is sent from the user terminal 3 to the game server 5 (step S40).
  • the game server 5 searches for a player card stored in the asset table T1 in association with the user ID of the user who sent the request (step S41), and obtains the search results (step S42). .
  • the searched player cards those whose corresponding player ID is stored in the asset token table T2 and whose deletion flag in the corresponding asset token table T2 is false are searched (step S43). , obtains the token ID of the searched record as a search result (step S44).
  • the game server 5 generates a list of owned NFTs based on the one or more token IDs acquired in this way, and transmits it to the user terminal 3 (step S45).
  • the user terminal 3 When the user terminal 3 displays the list of owned NFTs received from the game server 5 to the user, and the user performs an operation to select one or more NFTs (player cards) that he or she wishes to return to the game (step S46), the user terminal 3 transmits a return request specifying the selected NFT to the NFT bridge server 6 (step S47).
  • the NFT bridge server 6 Upon receiving this request, the NFT bridge server 6 requests the blockchain network 4 to burn the NFT specified by the request (step S48). Specifically, a transfer transaction for transferring the NFT to a wallet address whose private key is unknown to anyone is generated and sent to the blockchain network 4. The blockchain network 4 executes processing to record the received transfer transaction on the blockchain, and notifies the NFT bridge server 6 of the result (step S49).
  • the NFT bridge server 6 determines whether or not the NFT was successfully incinerated based on the notification received from the blockchain network 4 (step S50). If it is determined that the process has failed, the NFT bridge server 6 transmits an error notification to the user terminal 3 (step S51). In this case, the player card is not returned to the game, and the user cannot continue to use the player card in the game.
  • the NFT bridge server 6 that has determined that the process was successful in step S50 deletes the corresponding token ID from the asset token table T2 (step S52) and adds the corresponding player card to the asset table T1 (step S53).
  • the deletion in step S52 is specifically a process of setting the corresponding deletion flag to true.
  • the addition in step S53 is specifically a process of setting the corresponding deletion flag to false.
  • the NFT bridge server 6 After completing up to step S53, the NFT bridge server 6 transmits a success notification to the user terminal 3 (step S54). Through the processing up to this point, the NFT player card is returned to the game, and the user can now use the player card in the game.
  • the digital data management system 1 when a user transacts a player card, the player card is converted into NFT and deleted from the asset table T1; When a card is used in the game, the player card is returned to the asset table T1 and the issued NFT is incinerated, so the change parameters of the player card are stored in the NFT metadata of the player card. It becomes possible to write. Furthermore, since the player card in the game and the NFT do not exist at the same time, it is possible to ensure the uniqueness of the player card.
  • the deletion flag of the player card is set instead of erasing the record of the player card from the asset table T1. Since deletion is executed by setting this to true, even if the corresponding NFT is transferred, it becomes possible to match the owner of the player card in the game with the new owner of the NFT.
  • player cards that are not subject to NFT conversion may also be provided.
  • player cards that are not subject to NFT conversion may be prevented from being selected by the user in step S14 of FIG.
  • the deletion when deleting records in the asset table T1 and the asset token table T2, the deletion is executed by setting the deletion flag to true, but deletion is performed by erasing the records from each table. It may also be done.
  • a new record when incinerating the NFT of the player card and adding its information to the asset table T1, a new record may be generated based on the metadata stored in the NFT.
  • the NFT bridge server 6 directly accesses the game database 7 in the processes shown in FIGS. You can also use it as In other words, the NFT bridge server 6 may notify the game server 5 of the processing results, and the game server 5 may manipulate data in the game database 7.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】ゲーム資産の非代替性トークンのメタデータ内に変化パラメータを記述できるようにする。 【解決手段】デジタルデータ管理システム１は、ユーザーの操作に応じて、資産テーブルＴ１に記憶される１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した非代替性トークンに対応する資産データを資産テーブルＴ１から削除し、ユーザーの操作に応じて、発行済みの非代替性トークンに対応する資産データを資産テーブルＴ１に追加するとともに、追加した資産データに対応する非代替性トークンを焼却する。

Description

デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム
　本発明は、デジタルデータ管理システム、デジタルデータ管理方法、及びプログラムに関する。
　ゲーム資産を非代替性トークン化して取引できるようにしたゲームが知られている。取引したゲーム資産は、元のゲームで利用できることは勿論、対応する他のゲームでも利用できるようになる。
　特許文献１には、この種のゲームの一例が開示されている。特許文献１に記載のゲームでは、ゲーム内におけるゲーム資産の取引が運営者の管理下にある集中型データベースによって管理される一方、分散型取引所での売却やゲーム外でのその他の取引は、非代替性トークン化したゲーム資産の取引トランザクションとしてブロックチェーンにより管理される。
特開２０２２－０２３８０１号公報
　ところで、ゲームで用いられるキャラクターには、そのキャラクターを特徴付けるパラメータの内容が変化していくタイプのものがある。例えば、サッカーゲームで用いられるサッカー選手のキャラクターを例に取ると、ゲームプレイの結果やユーザーが行った強化（トレーニング）の結果に応じて攻撃力や防御力などが変化するし、所属クラブが変化する場合もある。以下、これらの変化するパラメータを「変化パラメータ」と総称し、キャラクターの名前などの変化しないパラメータを「定常パラメータ」と総称する。
　上記のようなタイプのキャラクターをゲーム資産として非代替性トークンを作成する場合、定常パラメータは勿論、変化パラメータについても、それぞれの具体的な内容を非代替性トークンのメタデータ内に記述しておくことが好ましい。ＵＲＬによる外部参照の形で記述することも可能であるが、そうすると、パラメータの具体的な内容を保持している外部サーバ（通常は、ゲーム運営者が運用しているサーバ）が閉鎖された場合に非代替性トークンの価値が失われることになり、ゲーム資産を非代替性トークン化する意義が損なわれてしまうからである。
　しかしながら、記録後の改ざんが実質的に不可能であるというブロックチェーンの特性から、一旦ブロックチェーンに記録された非代替性トークンの内容は、メタデータも含めて一切変更できない。その結果、これまでゲーム資産の非代替性トークンのメタデータ内に変化パラメータを記述することは不可能であったので、ゲーム資産の非代替性トークンのメタデータ内に変化パラメータを記述できるようにすることが求められていた。
　したがって、本発明の目的の一つは、ゲーム資産の非代替性トークンのメタデータ内に変化パラメータを記述できるデジタルデータ管理システム、デジタルデータ管理方法、及びプログラムを提供することにある。
　本発明によるデジタルデータ管理システムは、ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースと、前記データベースに接続されるサーバと、を備えるデジタルデータ管理システムであって、前記サーバは、前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除し、前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却する、デジタルデータ管理システムである。
　本発明によるデジタルデータ管理方法は、ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースに接続されるコンピュータによって実行されるデジタルデータ管理方法であって、前記コンピュータが、前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除するステップと、前記コンピュータが、前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却するステップと、を含むデジタルデータ管理方法である。
　本発明によるプログラムは、ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースに接続されるコンピュータに、前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除するステップと、前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却するステップと、を実行させるためのプログラムである。
　本発明によれば、ユーザーが資産データの取引を行う際には資産データを非代替性トークン化し、かつ、資産テーブルから削除する一方、ユーザーが変化パラメータを変化させる際（例えば、資産データを用いてゲームを行う際）には資産データを資産テーブルに戻し、かつ、発行済みの非代替性トークンを焼却しているので、ゲーム資産の非代替性トークンのメタデータ内に変化パラメータを記述することが可能になる。
本実施の形態によるデジタルデータ管理システム１を含むシステムの構成を示す図である。 デジタルデータ管理システム１及びユーザー端末３のハードウェア構成の一例を示す図である。 （ａ）は、ゲームデータベース７に記憶される資産テーブルＴ１の構造を示す図であり、（ｂ）は、ゲームデータベース７に記憶される資産トークンテーブルＴ２の構造を示す図である。 （ａ）（ｂ）は、資産テーブルＴ１及び資産トークンテーブルＴ２を用いてデジタルデータ管理システム１が実行する処理を説明する図である。 デジタルデータ管理システム１、ユーザー端末３、及びブロックチェーンネットワーク４によって実行される処理を示す処理フロー図である。 デジタルデータ管理システム１、ユーザー端末３、及びブロックチェーンネットワーク４によって実行される処理を示す処理フロー図である。 デジタルデータ管理システム１、ユーザー端末３、及びブロックチェーンネットワーク４によって実行される処理を示す処理フロー図である。 デジタルデータ管理システム１、ユーザー端末３、及びブロックチェーンネットワーク４によって実行される処理を示す処理フロー図である。
　以下、添付図面を参照しながら、本発明の実施の形態について詳細に説明する。以下では、非代替性トークンを「ＮＦＴ」（Non-Fungible Token）と称する。
　図１は、本実施の形態によるデジタルデータ管理システム１を含むシステムの構成を示す図である。デジタルデータ管理システム１は、ユーザーによって所有されるデジタルデータである資産データの管理を行うシステムであり、図１に示すように、例えばインターネットであるネットワーク２を介して、ユーザー端末３及びブロックチェーンネットワーク４に接続される。また、デジタルデータ管理システム１は、ゲームサーバ５、ＮＦＴブリッジサーバ６、及びゲームデータベース７を含んで構成される。ゲームデータベース７は、資産テーブルＴ１及び資産トークンテーブルＴ２を記憶するよう構成される。
　典型的な例では、資産データは、オンラインサッカーゲームで用いられる選手カードを示すデータである。以下では、この例を前提に説明を続けるが、本発明が他の種類の資産データにも適用可能であることは勿論である。この例におけるゲームサーバ５には、ユーザーがゲーム運営者から選手カードを購入する機能、ユーザーがゲームの実行を通じて所有する選手を育成する機能（すなわち、選手カードの変化パラメータを変化させる機能）、ユーザーの指示に応じて選手カードのＮＦＴを発行する機能、及び、ユーザーが他者から購入した選手カードのＮＦＴに基づき、ユーザーの選手カードを追加する機能が実装される。それぞれの詳細については、後述する。
　図２は、デジタルデータ管理システム１及びユーザー端末３のハードウェア構成の一例を示す図である。デジタルデータ管理システム１及びユーザー端末３はそれぞれ、図示した構成を有するコンピュータ１００によって構成され得る。典型的な例では、デジタルデータ管理システム１を構成するコンピュータ１００は、サーバとして機能する高性能コンピュータである。また、ユーザー端末３を構成するコンピュータ１００は、パーソナルコンピュータ、タブレット端末、スマートフォンなどの個人用コンピュータである。なお、コンピュータ１００は、複数のコンピュータの結合によって構成されるコンピュータであってもよい。
　図２に示すように、コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１、記憶装置１０２、入力装置１０３、出力装置１０４、及び通信装置１０５がバス１０６を介して相互に接続された構成を有している。
　ＣＰＵ１０１は、コンピュータ１００の各部を制御するとともに、記憶装置１０２に記憶される各種のプログラムを読み出して実行する装置である。図１に示したゲームサーバ５及びＮＦＴブリッジサーバ６はそれぞれ、デジタルデータ管理システム１のＣＰＵ１０１が、デジタルデータ管理システム１の記憶装置１０２に記憶されるプログラムを実行することによって実現される仮想的なコンピュータである。ただし、上述したようにコンピュータ１００を複数の複数のコンピュータの結合によって構成する場合には、ゲームサーバ５及びＮＦＴブリッジサーバ６を複数のコンピュータに分散して実装することとしてもよく、この場合には、各コンピュータのＣＰＵ１０１がそれぞれの記憶装置１０２に記憶されるプログラムを実行することによって、ゲームサーバ５及びＮＦＴブリッジサーバ６の機能が実現される。また、ユーザー端末３のＣＰＵ１０１によって実行されるプログラムには、ネットワーク２を介して他の装置にアクセスする機能を有するブラウザソフト又はモバイルアプリが含まれる。
　記憶装置１０２は、ＤＲＡＭ（Dynamic Random Access Memory）などの主記憶装置と、ハードディスクなどの補助記憶装置とを含み、コンピュータ１００のオペレーティングシステムや各種のアプリケーションを実行するための各種のプログラム、及び、これらのプログラムによって利用されるデータを記憶する役割を果たす装置である。図１に示したゲームデータベース７は、デジタルデータ管理システム１の記憶装置１０２内に実装される。
　入力装置１０３は、ユーザーの入力操作を受け付けてＣＰＵ１０１に供給する装置であり、例えばキーボード、マウス、タッチパネルを含んで構成される。出力装置１０４は、ＣＰＵ１０１の処理結果をユーザーに対して出力する装置であり、例えばディスプレイ、スピーカーを含んで構成される。通信装置１０５は、外部の装置と通信するための装置であり、ＣＰＵ１０１の指示にしたがってデータの送受信を行う。デジタルデータ管理システム１及びユーザー端末３はそれぞれ、この通信装置１０５を用いて、図１に示したブロックチェーンネットワーク４及びネットワーク２を含む他の装置との間で通信を行うよう構成される。
　図１に戻る。ブロックチェーンネットワーク４は、ピアツーピアによって接続された複数のコンピュータのネットワークであり、各ユーザー（ユーザー端末３のユーザー、デジタルデータ管理システム１のユーザー（＝ゲーム運営者）を含む）に割り当てられるウォレットアドレス間でのＮＦＴの所有権の移転（移転トランザクション）、及び、新たに生成されたＮＦＴのいずれかのウォレットアドレスへの対応付け（発行トランザクション）をブロックチェーンに記録するように構成される。
　一般に、ブロックチェーンには、特定の管理者がいないパブリックチェーン、単一の組織により管理されているプライベートチェーン、複数の組織により管理されているコンソーシアムチェーンの３種類があるが、ブロックチェーンネットワーク４はこれらのいずれであってもよい。典型的な例では、ブロックチェーンネットワーク４は、パブリックチェーンに分類されるイーサリアムネットワーク、及び、プライベートチェーンに分類されるＬＩＮＥブロックチェーンのいずれかである。以下では、ブロックチェーンネットワーク４はイーサリアムネットワークであるとして説明を続ける。
　トランザクションのブロックチェーンへの記録は、ブロックチェーンネットワーク４に接続されたいくつかのコンピュータ（以下、「マイナー」と称する）によって実行される。具体的に説明すると、ブロックチェーンを構成する各ブロックは、ブロックヘッダと、トランザクションの具体的な内容を示すデータ（取引データ）とを含んで構成される。このうちブロックヘッダには、取引データのサイズを圧縮してなるデータであるマークルルートと、１つ前のブロックのハッシュ値と、任意の文字列であるナンス値とが含まれる。ブロックチェーンネットワーク４においては、新たなブロックをブロックチェーンに接続するには、そのブロックのハッシュ値が所定の条件（例えば、「０００」で始まる値である、という条件）を満たしていなければならないというルールが定められている。そこで、ブロックチェーンにあるブロックを記録しようとするマイナーは、そのブロックのブロックヘッダのハッシュ値が上記所定の条件を満たすこととなるよう、総当たり的にナンス値を見つける作業（マイニング）を行う。この作業の結果として、最も早くナンス値の発見に成功したマイナーがそのブロックをブロックチェーンに連結することによって、トランザクションのブロックチェーンへの記録が完了する。
　ブロックチェーンネットワーク４がイーサリアムネットワークである場合、トランザクションをブロックチェーンに記録しようとする者は、「ガス」と呼ばれる手数料を仮想通貨によって支払う必要がある。ガスは、ブロックの連結に成功したマイナーに対し、報酬として支払われる。ゲーム用の資産データのＮＦＴ化においては、このガスがコスト面のネックとなり得る。ガスの存在しないブロックチェーンも存在するので、コスト面からガスの存在が許容できない場合には、ガスの存在しないブロックチェーンをブロックチェーンネットワーク４として用いればよい。
　図３（ａ）は、ゲームデータベース７に記憶される資産テーブルＴ１の構造を示す図であり、図３（ｂ）は、ゲームデータベース７に記憶される資産トークンテーブルＴ２の構造を示す図である。初めに図３（ａ）を参照すると、資産テーブルＴ１は、選手カードごとにユニークに割り当てられる選手ＩＤに対応付けて、名前、クラブ、レアリティ、得意ポジション、攻撃力、防御力、パワー、スピード、スタミナ、テクニック、所有者、削除フラグを記憶するテーブルである。このうち選手ＩＤ及び名前は、変化しない定常パラメータである。一方、クラブ、レアリティ、得意ポジション、攻撃力、防御力、パワー、スピード、スタミナ、テクニックは、ゲームが進行している間に、ユーザーの操作結果などに応じて変化することのある変化パラメータである。所有者には、この選手カードを所有しているユーザーを示すユーザーＩＤが格納される。削除フラグは、対応する選手カードが論理的に削除された状態になっているときに真（第１の値）、そうでない場合に偽（第２の値）となるブール型のデータである。
　次に図３（ｂ）を参照すると、資産トークンテーブルＴ２は、ＮＦＴ化された選手カードのそれぞれについて、対応するＮＦＴのトークンＩＤと、対応する選手ＩＤと、削除フラグとを対応付けて記憶するテーブルである。削除フラグは、対応するトークンＩＤが論理的に削除された状態になっているときに真（第１の値）、そうでない場合に偽（第２の値）となるブール型のデータである。
　図４（ａ）（ｂ）は、以上のような資産テーブルＴ１及び資産トークンテーブルＴ２を用いてデジタルデータ管理システム１が実行する処理を説明する図である。図４（ａ）は、選手カードをＮＦＴ化する処理を示し、図４（ｂ）は、ＮＦＴ化された選手カードを資産テーブルＴ１に戻す処理を示している。
　初めに図４（ａ）を参照すると、初期状態では、図示した選手カードＣ０を含む複数の選手カードＣがユーザーの資産テーブルＴ１の中に格納されている。複数の選手カードＣは、ユーザーがゲーム運営者又は他者から購入したものである。この状態において、ユーザーがユーザー端末３において選手カードＣ０のＮＦＴの発行を指示するための操作を行うと、デジタルデータ管理システム１は、選手カードＣ０を示すＮＦＴを発行（ｍｉｎｔ）するとともに、選手カードＣ０を資産テーブルＴ１から削除する処理を行う。この場合においてデジタルデータ管理システム１は、選手カードＣ０のレコードを資産テーブルＴ１から消し去るのではなく、選手カードＣ０の削除フラグを真とすることによって、選手カードＣ０の削除を実行する。また、デジタルデータ管理システム１は、発行したＮＦＴを示すトークンＩＤをブロックチェーンネットワーク４から取得し、取得したトークンＩＤを、選手カードＣ０の選手ＩＤに対応付けて資産トークンテーブルＴ２に追加する処理を行う。このときデジタルデータ管理システム１は、取得したトークンＩＤに対応する削除フラグを偽に設定する。
　デジタルデータ管理システム１による選手カードのＮＦＴの発行について詳しく説明すると、デジタルデータ管理システム１はまず、資産テーブルＴ１に記憶されている情報に基づき、選手カードのＮＦＴを生成する。このときデジタルデータ管理システム１は、対応する選手カードの定常パラメータ及び変化パラメータ（図３（ａ）を参照）をＮＦＴのメタデータ内に記述する。次いでデジタルデータ管理システム１は、生成したＮＦＴをユーザーのウォレットアドレスに対応付ける発行トランザクションを生成し、ブロックチェーンネットワーク４に対して送信する。ブロックチェーンネットワーク４は、受信した発行トランザクションに対してトークンＩＤを発行するとともに、受信した発行トランザクションを含むブロックのブロックチェーンへの記録を行う。記録が完了した後、ブロックチェーンネットワーク４は、記録が完了したことをデジタルデータ管理システム１に通知する。デジタルデータ管理システム１は、この通知を受信したことに応じて、選手カードＣ０を資産テーブルＴ１から削除するとともに、対応する選手カードの選手ＩＤとＮＦＴのトークンＩＤとを対応付けて資産トークンテーブルＴ２に追加する。
　ＮＦＴ化された選手カードは、市場における取引の対象となる他、対応する他のゲームで利用することも可能になる。一方、ゲームサーバ５は、ユーザーがゲームに使用することができる選手カードを、削除フラグが偽の状態で資産テーブルＴ１内に記憶されている選手カードに限定するよう構成される。したがってユーザーは、ＮＦＴを発行した選手カードを、ゲームサーバ５によって実現されるゲームのために使用することはできない。結果として、ＮＦＴを発行した選手カードの変化パラメータは、後述する処理により当該選手カードが資産テーブルＴ１に戻されるまで変化しないことになるので、ＮＦＴのメタデータに含まれる変化パラメータと資産テーブルＴ１内の選手カードに含まれる変化パラメータとの不一致が生ずることはない。
　次に図４（ｂ）を参照すると、削除フラグが偽の状態で選手カードＣ０のトークンＩＤ及び選手ＩＤが資産トークンテーブルＴ２に記憶されているときに、ユーザーがユーザー端末３において選手カードＣ０を資産テーブルＴ１に戻すことを指示するための操作を行うと、デジタルデータ管理システム１は、選手カードＣ０のＮＦＴを焼却（ｂｕｒｎ）するとともに、対応するトークンＩＤを資産トークンテーブルＴ２から削除し、さらに、選手カードＣ０の情報を資産テーブルＴ１に追加する処理を行う。この場合においてデジタルデータ管理システム１は、対応するトークンＩＤのレコードを資産トークンテーブルＴ２から消し去るのではなく、対応するトークンＩＤに対応付けて資産トークンテーブルＴ２内に記憶される削除フラグを真とすることによって、対応するトークンＩＤの削除を実行する。また、デジタルデータ管理システム１は、対応する選手ＩＤに対応付けて資産テーブルＴ１内に記憶される削除フラグを偽とすることによって、資産テーブルＴ１への選手カードＣ０の情報の追加を実行する。選手カードＣ０の情報が資産テーブルＴ１に追加されることにより、ユーザーは、選手カードＣ０をゲーム内で再び使用できるようになる。
　ここで、選手カードのＮＦＴが市場において取引された場合の処理について説明すると、デジタルデータ管理システム１は、選手カードのＮＦＴの移転トランザクションが発生したことを検知するために、ブロックチェーンネットワーク４へのアクセスを定期的に実行する。そして、選手カードのＮＦＴの移転トランザクションが発生したことを検知したデジタルデータ管理システム１は、対応する選手ＩＤに対応付けて資産テーブルＴ１内に所有者として記憶されるユーザーＩＤを、移転トランザクションにより示される移転先のユーザーＩＤに更新する。これにより、ゲーム内における選手カードの所有者がＮＦＴの所有者と一致することになる。
　図５～図８は、デジタルデータ管理システム１、ユーザー端末３、及びブロックチェーンネットワーク４によって実行される処理を示す処理フロー図である。以下、これらの図を参照しながら、本実施の形態によるデジタルデータ管理システム１が行う処理について、より詳しく説明する。
　図５には、ユーザーがゲーム運営者から選手カードを購入する場合の処理を示している。初めに、ゲームサーバ５からユーザー端末３に対し、購入可能な選手カードのリストが送信される（ステップＳ１）。ユーザーがこのリストの中から購入したい１以上の選手カードを選択すると（ステップＳ２）、ユーザー端末３からゲームサーバ５に対し、選択された選手カードを特定する選手購入要求が送信される（ステップＳ３）。この要求を受けたゲームサーバ５は、ユーザー端末３との間で所定の決済処理（ステップＳ４）を実行した後、対応する選手カードを生成する（ステップＳ５）。このときゲームサーバ５は、生成する選手カードに対し、資産テーブルに未だ記録されていない選手ＩＤを割り当てる。続いてゲームサーバ５は、生成した選手カードを資産テーブルＴ１に追加し（ステップＳ６）、購入結果をユーザー端末３に通知する（ステップＳ７）。以上の処理により選手カードの購入が完了し、ユーザーは、購入した選手カードをゲーム内で使用できるようになる。
　図６及び図７には、ユーザーにより所有される１以上の選手カードのうちの１つをＮＦＴ化する場合の処理を示している。初めに、ユーザー端末３からゲームサーバ５に対し、所有選手カードの一覧要求が送信される（ステップＳ１０）。この要求を受けたゲームサーバ５は、要求を送信してきたユーザーのユーザーＩＤと対応付けて資産テーブルＴ１内に記憶される選手カードを検索し（ステップＳ１１）、検索結果を取得する（ステップＳ１２）。そして、検索結果に基づいて所有選手カードのリストを生成し、ユーザー端末３に送信する（ステップＳ１３）。
　ユーザー端末３がゲームサーバ５から受信した所有選手カードのリストをユーザーに対して表示し、ユーザーがその中からＮＦＴ化したい１以上の選手カードを選択するための操作を行うと（ステップＳ１４）、ユーザー端末３は、選択された選手カードを特定するＮＦＴ化要求をＮＦＴブリッジサーバ６に対して送信する（ステップＳ１５）。
　この要求を受けたＮＦＴブリッジサーバ６は、要求により特定された選手カードの情報を資産テーブルＴ１及び資産トークンテーブルＴ２内で検索し（ステップＳ１６）、検索結果として、選手カードに含まれる各情報とともに、選手カードに対してこれまでに発行されたＮＦＴの情報を取得する（ステップＳ１７）。ＮＦＴブリッジサーバ６は、こうして取得したＮＦＴの情報に基づき、対応する選手カードに対してＮＦＴを発行済みであるか否かを判定する（ステップＳ１８）。具体的には、選手カードに対してこれまでに発行されたＮＦＴのうち資産トークンテーブルＴ２に記憶される削除フラグが偽になっているものが存在する場合に発行済みであると判定し、それ以外の場合に発行済みでないと判定すればよい。
　ステップＳ１８において発行済みであると判定した場合、ＮＦＴブリッジサーバ６は、ユーザー端末３に対してエラー通知を送信する（ステップＳ１９）。この場合、ＮＦＴを発行するための処理は行われない。これにより、１つの選手カードに対して同時に複数のＮＦＴを発行してしまうことが防止される。
　一方、ステップＳ１８において発行済みでないと判定したＮＦＴブリッジサーバ６は、ステップＳ１７で取得した情報（定常パラメータ及び変化パラメータ）を用いてＮＦＴを生成し、ブロックチェーンネットワーク４に対してその発行を要求する（ステップＳ２１）。具体的には、生成したＮＦＴをユーザー端末３のユーザーのウォレットアドレスに対応付ける発行トランザクションを生成し、ブロックチェーンネットワーク４に対して送信する。ブロックチェーンネットワーク４は、受信した発行トランザクションをブロックチェーンに記録するための処理を実行し、その結果をＮＦＴブリッジサーバ６に通知する（ステップＳ２２）。
　ＮＦＴブリッジサーバ６は、ブロックチェーンネットワーク４から受信した通知に基づき、ＮＦＴの発行に成功したか否かを判定する（ステップＳ２３）。ここで失敗したと判定した場合、ＮＦＴブリッジサーバ６は、ユーザー端末３に対してエラー通知を送信する（ステップＳ２４）。この場合、結果的にＮＦＴは発行されないことになる。
　一方、ステップＳ２３において成功したと判定したＮＦＴブリッジサーバ６は、図７に示すように、対応する選手カードを資産テーブルＴ１から削除する（ステップＳ２５）とともに、ブロックチェーンネットワーク４からの通知に含まれるトークンＩＤを、対応する選手ＩＤに対応付けて資産トークンテーブルＴ２に追加する（ステップＳ２６）。なお、ステップＳ２５の削除は、具体的には、対応する削除フラグを真に設定する処理である。また、ステップＳ２６においてＮＦＴブリッジサーバ６は、対応する削除フラグを偽に設定する。
　ステップＳ２６まで完了した後、ＮＦＴブリッジサーバ６は、ユーザー端末３に対して成功通知を送信する（ステップＳ２７）。ここまでの処理により、選手カードのＮＦＴ化が完了する。この段階では、ＮＦＴ化した選手カードの情報は資産テーブルＴ１から削除されている（より正確には、削除フラグが真になっている）ので、ユーザーは、この選手カードをゲームに使用することはできず、したがって、変化パラメータが変化することもなくなっている。
　図７に示すステップＳ３０以降の処理は、選手カードのＮＦＴが市場において取引された場合の処理を示している。ＮＦＴブリッジサーバ６は、ブロックチェーンネットワーク４に対して定期的に、選手カードのＮＦＴの移転トランザクションの発生を検知するためのトランザクションイベント検知結果要求を送信する（ステップＳ３０）。この要求を受けたブロックチェーンネットワーク４は、過去のトランザクションの中から選手カードのＮＦＴの移転トランザクションを検索し、その結果を、検知結果としてＮＦＴブリッジサーバ６に送信する（ステップＳ３１）。
　検知結果を受信したＮＦＴブリッジサーバ６は、選手カードのＮＦＴの移転が発生したか否かを判定する（ステップＳ３２）。その結果、移転が発生したと判定した場合、ＮＦＴブリッジサーバ６は、移転の対象となった選手カードに対応付けて資産テーブルＴ１内に記憶されるユーザーＩＤを、移転先のユーザーを示すユーザーＩＤにより更新する（ステップＳ３３）とともに、移転元のユーザー及び移転先のユーザーのそれぞれに対して、ユーザーＩＤの更新が発生したことを通知する（ステップＳ３４）。一方、ステップＳ３２において移転が発生していないと判定したＮＦＴブリッジサーバ６は、ステップＳ３３，Ｓ３４を行うことなく、処理を終了する。以上の処理により、市場においてＮＦＴの取引が発生した場合に、その結果を資産テーブルＴ１に反映させることが可能になる。
　図８には、ＮＦＴ化された選手カードを資産テーブルＴ１に戻す処理を示している。初めに、ユーザー端末３からゲームサーバ５に対し、所有ＮＦＴの一覧要求が送信される（ステップＳ４０）。この要求を受けたゲームサーバ５は、要求を送信してきたユーザーのユーザーＩＤと対応付けて資産テーブルＴ１内に記憶される選手カードを検索し（ステップＳ４１）、検索結果を取得する（ステップＳ４２）。そしてさらに、検索された選手カードのうち、対応する選手ＩＤが資産トークンテーブルＴ２に記憶されており、かつ、対応する資産トークンテーブルＴ２内の削除フラグが偽であるものを検索し（ステップＳ４３）、検索されたレコードのトークンＩＤを検索結果として取得する（ステップＳ４４）。ゲームサーバ５は、こうして取得した１以上のトークンＩＤに基づいて所有ＮＦＴのリストを生成し、ユーザー端末３に送信する（ステップＳ４５）。
　ユーザー端末３がゲームサーバ５から受信した所有ＮＦＴのリストをユーザーに対して表示し、ユーザーがその中からゲームに戻したい１以上のＮＦＴ（選手カード）を選択するための操作を行うと（ステップＳ４６）、ユーザー端末３は、選択されたＮＦＴを特定する戻し要求をＮＦＴブリッジサーバ６に対して送信する（ステップＳ４７）。
　この要求を受けたＮＦＴブリッジサーバ６は、要求により特定されたＮＦＴの焼却をブロックチェーンネットワーク４に対して要求する（ステップＳ４８）。具体的には、誰も秘密鍵を知らないウォレットアドレスに対して当該ＮＦＴを移転する移転トランザクションを生成し、ブロックチェーンネットワーク４に対して送信する。ブロックチェーンネットワーク４は、受信した移転トランザクションをブロックチェーンに記録するための処理を実行し、その結果をＮＦＴブリッジサーバ６に通知する（ステップＳ４９）。
　ＮＦＴブリッジサーバ６は、ブロックチェーンネットワーク４から受信した通知に基づき、ＮＦＴの焼却に成功したか否かを判定する（ステップＳ５０）。ここで失敗したと判定した場合、ＮＦＴブリッジサーバ６は、ユーザー端末３に対してエラー通知を送信する（ステップＳ５１）。この場合、選手カードはゲームに戻されず、ユーザーは、その選手カードをゲーム内で引き続き使えないことになる。
　一方、ステップＳ５０において成功したと判定したＮＦＴブリッジサーバ６は、対応するトークンＩＤを資産トークンテーブルＴ２から削除する（ステップＳ５２）とともに、対応する選手カードを資産テーブルＴ１に追加する（ステップＳ５３）。なお、ステップＳ５２の削除は、具体的には、対応する削除フラグを真に設定する処理である。また、ステップＳ５３の追加は、具体的には、対応する削除フラグを偽に設定する処理である。
　ステップＳ５３まで完了した後、ＮＦＴブリッジサーバ６は、ユーザー端末３に対して成功通知を送信する（ステップＳ５４）。ここまでの処理により、ＮＦＴ化されていた選手カードがゲーム内に戻され、ユーザーは、その選手カードをゲーム内で使用できるようになる。
　以上説明したように、本実施の形態によるデジタルデータ管理システム１によれば、ユーザーが選手カードの取引を行う際には選手カードをＮＦＴ化し、かつ、資産テーブルＴ１から削除する一方、ユーザーが選手カードをゲーム内で使用する際には、その選手カードを資産テーブルＴ１に戻し、かつ、発行済みのＮＦＴを焼却しているので、選手カードのＮＦＴのメタデータ内に、選手カードの変化パラメータを記述することが可能になる。また、ゲーム内の選手カードとＮＦＴが同時には存在しなくなるので、選手カードの唯一性を確保することが可能になる。
　また、本実施の形態によるデジタルデータ管理システム１によれば、選手カードを資産テーブルＴ１から削除する際、その選手カードのレコードを資産テーブルＴ１から消し去るのではなく、その選手カードの削除フラグを真とすることによって削除を実行しているので、対応するＮＦＴの移転が発生した場合においても、ゲーム内における当該選手カードの所有者をＮＦＴの新たな所有者に一致させることが可能になる。
　以上、本発明の好ましい実施の形態について説明したが、本発明はこうした実施の形態に何等限定されるものではなく、本発明が、その要旨を逸脱しない範囲において、種々なる態様で実施され得ることは勿論である。
　例えば、上記実施の形態では、すべての選手カードがＮＦＴ化の対象であることを前提として説明したが、ＮＦＴ化の対象でない選手カードを設けることとしてもよい。この場合、ＮＦＴ化の対象でない選手カードについては、図６のステップＳ１４においてユーザーが選択できないようにすればよい。
　また、上記実施の形態では、資産テーブルＴ１及び資産トークンテーブルＴ２のレコードを削除する際、削除フラグを真とすることによって削除を実行していたが、各テーブルからレコードを消し去ることによって削除を実行することとしてもよい。この場合において、選手カードのＮＦＴを焼却してその情報を資産テーブルＴ１に追加する際には、ＮＦＴに格納されているメタデータに基づいて新たなレコードを生成すればよい。
　また、上記実施の形態では、図６～図８に示した処理においてＮＦＴブリッジサーバ６がゲームデータベース７に直接アクセスしていたが、ゲームサーバ５を介して、ゲームデータベース７内のデータにアクセスすることとしてもよい。つまり、ＮＦＴブリッジサーバ６からゲームサーバ５に対して処理結果を通知し、ゲームサーバ５からゲームデータベース７のデータ操作を行うこととしてもよい。
１　　　デジタルデータ管理システム
２　　　ネットワーク
３　　　ユーザー端末
４　　　ブロックチェーンネットワーク
５　　　ゲームサーバ
６　　　ＮＦＴブリッジサーバ
７　　　ゲームデータベース
１００　コンピュータ
１０１　ＣＰＵ
１０２　記憶装置
１０３　入力装置
１０４　出力装置
１０５　通信装置
１０６　バス
Ｔ１　　資産テーブル
Ｔ２　　資産トークンテーブル

Claims (8)

  1. 　ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースと、
    　前記データベースに接続されるサーバと、を備えるデジタルデータ管理システムであって、
    　前記サーバは、
    　　前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除し、
    　　前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却する、
    　デジタルデータ管理システム。
  2. 　前記データベースは、非代替性トークンを示すトークンＩＤを前記資産データに対応付けて記憶するトークンテーブルをさらに記憶し、
    　前記サーバは、
    　　前記非代替性トークンを発行したことに応じ、対応する前記資産データに対応付けて、該非代替性トークンを示すトークンＩＤを前記トークンテーブルに追加し、
    　　前記非代替性トークンを焼却したことに応じ、該非代替性トークンを示すトークンＩＤを前記トークンテーブルから削除する、
    　請求項１に記載のデジタルデータ管理システム。
  3. 　前記資産データは、変化しない定常パラメータ、及び、前記資産テーブルに記憶されている間に変化することのある変化パラメータを含み、
    　前記非代替性トークンは、対応する前記資産データに含まれる前記定常パラメータ及び前記変化パラメータを含む、
    　請求項１又は２に記載のデジタルデータ管理システム。
  4. 　前記サーバは、前記ユーザーの操作結果に応じて前記変化パラメータを変化させる、
    　請求項３に記載のデジタルデータ管理システム。
  5. 　前記資産テーブルは、前記１以上の資産データのそれぞれに対応付けて削除フラグを記憶し、
    　前記サーバは、前記削除フラグを第１の値とすることにより、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除する処理を行い、
    　前記サーバは、前記削除フラグを第２の値とすることにより、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加する処理を行う、
    　請求項１乃至４のいずれか一項に記載のデジタルデータ管理システム。
  6. 　前記サーバは、前記非代替性トークンの移転が発生した場合に、対応する前記資産データに対応付けて前記資産テーブルに記憶される前記ユーザーＩＤを、移転先のユーザーを示すユーザーＩＤにより更新する、
    　請求項５に記載のデジタルデータ管理システム。
  7. 　ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースに接続されるコンピュータによって実行されるデジタルデータ管理方法であって、
    　前記コンピュータが、前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除するステップと、
    　前記コンピュータが、前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却するステップと、
    　を含むデジタルデータ管理方法。
  8. 　ユーザーを示すユーザーＩＤに対応付けて１以上の資産データを記憶する資産テーブルを記憶するデータベースに接続されるコンピュータに、
    　前記ユーザーの操作に応じて、前記資産テーブルに記憶される前記１以上の資産データのうちの１つを示す非代替性トークンを発行するとともに、発行した前記非代替性トークンに対応する前記資産データを前記資産テーブルから削除するステップと、
    　前記ユーザーの操作に応じて、発行済みの前記非代替性トークンに対応する前記資産データを前記資産テーブルに追加するとともに、追加した前記資産データに対応する前記非代替性トークンを焼却するステップと、
    　を実行させるためのプログラム。
PCT/JP2023/011436 2022-04-01 2023-03-23 デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム WO2023190005A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022062179 2022-04-01
JP2022-062179 2022-04-01

Publications (1)

Publication Number Publication Date
WO2023190005A1 true WO2023190005A1 (ja) 2023-10-05

Family

ID=88201990

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/011436 WO2023190005A1 (ja) 2022-04-01 2023-03-23 デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2023190005A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200103275A (ko) * 2019-02-25 2020-09-02 주식회사 호두잇 블록체인 기반의 게임 리소스 공유 시스템
JP2020191092A (ja) * 2019-05-21 2020-11-26 歐簿客科技股▲ふん▼有限公司 アイテム管理方法、ブロックチェーン分析手法、及びそれらを使用するコンピュータシステム
WO2021132483A1 (ja) * 2019-12-26 2021-07-01 シビラ株式会社 アプリケーション連携方法、コンピュータプログラム及びアプリケーション連携システム
WO2021186814A1 (ja) * 2020-03-19 2021-09-23 ｂａｃｏｏｒ ｄＡｐｐｓ株式会社 コンピュータシステムによって実行される方法及びコンピュータシステム
JP2021152815A (ja) * 2020-03-24 2021-09-30 株式会社Gaia ゲームシステム及びオークションプログラム
JP2022023801A (ja) * 2020-07-16 2022-02-08 ビッグ タイム スタジオズ エルティーディー． スマートコントラクトによって管理されるトークン化されたブロックチェーンゲーム資産を効率的に保存、発行、取引するためのコンピュータシステムおよび方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200103275A (ko) * 2019-02-25 2020-09-02 주식회사 호두잇 블록체인 기반의 게임 리소스 공유 시스템
JP2020191092A (ja) * 2019-05-21 2020-11-26 歐簿客科技股▲ふん▼有限公司 アイテム管理方法、ブロックチェーン分析手法、及びそれらを使用するコンピュータシステム
WO2021132483A1 (ja) * 2019-12-26 2021-07-01 シビラ株式会社 アプリケーション連携方法、コンピュータプログラム及びアプリケーション連携システム
WO2021186814A1 (ja) * 2020-03-19 2021-09-23 ｂａｃｏｏｒ ｄＡｐｐｓ株式会社 コンピュータシステムによって実行される方法及びコンピュータシステム
JP2021152815A (ja) * 2020-03-24 2021-09-30 株式会社Gaia ゲームシステム及びオークションプログラム
JP2022023801A (ja) * 2020-07-16 2022-02-08 ビッグ タイム スタジオズ エルティーディー． スマートコントラクトによって管理されるトークン化されたブロックチェーンゲーム資産を効率的に保存、発行、取引するためのコンピュータシステムおよび方法

Similar Documents

Publication Publication Date Title
JP7495350B2 (ja) 安全な非集中型ビデオゲーム取引プラットフォーム
JP5552505B2 (ja) ゲームシステム
KR102062896B1 (ko) 네트워크 내의 분산 데이터베이스를 위한 방법 및 장치
WO2023058269A1 (ja) 非代替性トークンを利用したコンテンツ出力システム、方法及びプログラム
TW202008252A (zh) 基於中心化結算與區塊鏈存證的交易方法及系統
US20080052704A1 (en) Media management system for management of games acquired from a media server
JP6404435B1 (ja) アイテム取引システム及びアイテム取引プログラム
JP7085687B2 (ja) 個人情報管理システム、個人情報管理装置、および個人情報管理方法
JP2022534196A (ja) オフチェーン機能をもたらすブロックチェーントランザクションの使用
KR20190003134U (ko) 네트워크 비디오 게임 시스템의 디지털 아이템에 대한 자산 및 영구 데이터 기록을 생성하는 시스템 및 방법
US20230120476A1 (en) Methods and systems for creation and distribution of non-fungible tokens
JP2022525251A (ja) ブロックチェーン・トランザクションを検証するプロトコル
KR20200119671A (ko) 디지털 컨텐츠의 이용 권리 증서를 발행 수량 만큼 유통시키는 방법, 상기 방법을 수행하는 서버, 및 상기 방법을 실행하기 위하여 매체에 저장된 컴퓨터 프로그램
JP2023510320A (ja) 分散型台帳ネットワークにおけるコンテンツのセキュアなピアツーピア送信のためのシステムおよび方法
US11693824B2 (en) Computer-readable recording medium recording communication program, communication method, and communication device
WO2023190005A1 (ja) デジタルデータ管理システム、デジタルデータ管理方法、及びプログラム
JP2019003503A (ja) ランダム仲介手数料設定機能を有する不動産仲介システム、不動産仲介方法、及び不動産仲介プログラム
JP7098734B2 (ja) ブロックチェーンシステム、及びブロックチェーンシステムの制御方法
Haley Embracing Digital
JP2024083998A (ja) 情報処理装置、方法、プログラム、およびシステムの生産方法
JP2019040621A (ja) 取引仲介システム、取引仲介方法及び取引仲介プログラム
KR102446213B1 (ko) 블록체인 변환 방법 및 장치
JP6896813B2 (ja) トランザクション実行方法およびシステム
WO2023013279A1 (ja) 販売済み商品管理システム、販売済み商品管理方法、及びプログラム
JP2020028052A (ja) データ管理方法

Legal Events

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

Ref document number: 23780016

Country of ref document: EP

Kind code of ref document: A1