WO2023053293A1 - トークン生成装置、トークン生成方法、及びトークン管理プログラム - Google Patents

トークン生成装置、トークン生成方法、及びトークン管理プログラム Download PDF

Info

Publication number
WO2023053293A1
WO2023053293A1 PCT/JP2021/035969 JP2021035969W WO2023053293A1 WO 2023053293 A1 WO2023053293 A1 WO 2023053293A1 JP 2021035969 W JP2021035969 W JP 2021035969W WO 2023053293 A1 WO2023053293 A1 WO 2023053293A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
consumption
paid
amount
asset
Prior art date
Application number
PCT/JP2021/035969
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 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社
Priority to PCT/JP2021/035969 priority Critical patent/WO2023053293A1/ja
Priority to JP2022541972A priority patent/JP7177305B1/ja
Priority to US18/042,491 priority patent/US20240265379A1/en
Publication of WO2023053293A1 publication Critical patent/WO2023053293A1/ja

Links

Images

Classifications

    • 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
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • 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
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/22—Payment schemes or models
    • 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
    • G06Q2220/00—Business processing using cryptography
    • 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates to a token generation device, token generation method, and token management program.
  • Ethereum a platform capable of executing asset transactions between users using smart contracts and issuing tokens in which the transaction history is shared by each node ( For example, Patent Document 1).
  • Ethereum is a platform for building decentralized applications and smart contracts. Smart contracts are implemented on blockchains to automatically execute protocols such as contracts.
  • Tokens implemented with such smart contracts can be issued to users continuously at a fixed price for a fee, for example, as a means for service providers to provide predetermined services (prepaid payment instruments).
  • the service provider can grant users tokens issued free of charge for incentives and rewards (free tokens), in addition to tokens corresponding to prepaid payment instruments issued for a fee (paid tokens).
  • paid tokens and free tokens can be used without distinction in appearance.
  • service providers may have to handle information related to prepaid payment instruments, i.e., paid tokens, separately from free tokens (for example, the unused balance of prepaid payment instruments must be reported to the Director of the Finance Bureau, etc.). ), it is necessary to manage both in a form that can be referred to objectively.
  • the present invention has been made in view of this background, and its object is to provide a token generator capable of continuously providing tokens issued at a fixed price for a fee and tokens issued free of charge.
  • An object of the present invention is to provide an apparatus, a token generation method, and a token management program.
  • One of the present inventions for solving the above problems is a free consumption history storage unit that stores a consumption history of an asset related to a paid token issued at a predetermined price in a token different from the paid token. and a consumption processing unit that receives designation of the consumption amount of the asset and stores information indicating that the designated consumption amount of the asset has been consumed in the token in the consumption history.
  • a token generation device that generates
  • an information processing apparatus stores a history of consumption of an asset related to a paid token issued at a predetermined price in a token different from the paid token. and a consumption processing unit that receives specification of the consumption amount of the asset and stores information indicating that the specified consumption amount of the asset has been consumed in the token in the consumption history.
  • a token generation method that generates a token.
  • Another aspect of the present invention is a free consumption history storage for storing, in an information processing apparatus, a consumption history of an asset related to a paid token issued at a predetermined price, in a token different from the paid token.
  • a token management program for executing processing, and a consumption processing that accepts designation of the consumption amount of the asset and stores in the consumption history information indicating that the designated consumption amount of the asset has been consumed in the token;
  • FIG. 1 is a diagram showing an example of the configuration of a token management system according to this embodiment.
  • FIG. 2 is a diagram illustrating an example of the main functions of smart contracts in tokens (transferable tokens and non-transferable tokens).
  • FIG. 3 is a diagram illustrating an example of hardware included in each node.
  • FIG. 4 is a flowchart illustrating an example of new issue processing.
  • FIG. 5 is a flowchart illustrating an example of additional issue processing.
  • FIG. 6 is a flow diagram illustrating an example of consumption processing.
  • FIG. 7 is a flowchart illustrating an example of the free portion information confirmation process.
  • FIG. 8 is a flowchart for explaining an example of paid/unpaid portion information confirmation processing.
  • FIG. 1 is a diagram showing an example of the configuration of the token management system 1 according to this embodiment.
  • This token management system 1 includes a management terminal 20 (token generation device) that issues tokens 3 and a plurality of user terminals 10 that use the issued tokens 3 .
  • the management terminal 20 and each user terminal 10 are associated with one or more accounts (identifiers).
  • the management terminal 20 and each user terminal 10 share asset information using the token 3, which is blockchain data that records the asset disposal history.
  • this token 3 is shared as an NFT (Non Fungible Token) whose value varies depending on the attribute of the asset.
  • NFT Non Fungible Token
  • the type of asset is not particularly limited, but may be, for example, information on rights to perform predetermined processing or actions, or various media such as images, music, text, and game items.
  • the user terminal 10 and management terminal 20 manage two types of tokens 3, a transferable token 5 and a non-transferable token 7, for a certain asset.
  • the transferable token 5 is a paid asset token that can be transferred between accounts, issued from the management terminal 20 based on a predetermined payment.
  • the transferable token 5 functions as a prepaid payment instrument that is continuously issued (sold) (with no time limit) at a fixed price whose price does not fluctuate.
  • the token management system 1 of this embodiment can be configured even if the transferable token 5 has a limited period or fluctuates in price.
  • the transferable token 5 can be implemented by standard functions (ERC20, etc.) implemented in Ethereum, for example.
  • the non-transferable token 7 is a token related to the same type of asset as the transferable token 5, but is issued from the management terminal 20 as a separate token from the transferable token 5.
  • a non-transferable token 7 is a gratuitous token that does not require payment for its issuance.
  • the non-transferable token 7 cannot be transferred between accounts (for example, trading tokens), and is a unique token that can be consumed only by the account to which it is issued for a predetermined purpose. It is an asset token.
  • the timing of issuing the non-transferable token 7 may be the same as issuing the transferable token 5, before issuing the transferable token 5, or after issuing the transferable token 5.
  • the management terminal 20 and each user terminal 10 execute processing related to each of these tokens (asset in them) by means of a smart contract, which is a program.
  • the management terminal 20 is an information processing device such as a server device.
  • the management terminal 20 issues a transferable token 5 and a non-transferable token 7 to the user terminal 10 account.
  • the user terminal 10 is, for example, an information processing device such as a personal computer or a smart phone.
  • the user terminal 10 uses the token issued by the management terminal 20 to transfer (trade) or consume assets held by the account related to the user terminal 10 .
  • the management terminal 20 and each user terminal 10 are connected by a wired or wireless communication network 2 such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, a dedicated line, or the like.
  • a wired or wireless communication network 2 such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, a dedicated line, or the like.
  • the token management system 1 described above is implemented using, for example, Ethereum, but may be implemented using other platforms as long as each function described below can be implemented.
  • FIG. 2 is a diagram illustrating an example of the main functions of the smart contract in tokens 3 (transferable tokens 5 and non-transferable tokens 7) stored in user terminals 10 and management terminals 20 (hereinafter referred to as nodes). .
  • the transferable token 5 stores a charge transfer history 51.
  • the paid portion transfer history 51 is information that records the transfer history of the transferable token 5 between accounts (history of ownership transfer or transfer).
  • the paid portion transfer history 51 is configured as part of the blockchain data.
  • the paid portion transfer history 51 includes, for example, the transfer source account of the transferable tokens 5, the transfer destination account, and the history of the amount (number) of transferred transferable tokens 5.
  • the transferable token 5 has the functions of a paid portion issuing portion 52, a paid portion transfer execution portion 53, and a paid portion information confirmation portion 54.
  • the paid portion issuing unit 52 generates the transferable token 5 and issues the generated transferable token 5 to the user terminal 10 .
  • Information on the issued transferable token 5 is recorded in the paid portion transfer history 51 .
  • the paid portion issuing unit 52 is executed only when an execution request is received from the account associated with the management terminal 20 . That is, the transferable token 5 can be issued only by the management account (or the management terminal 20).
  • the paid portion transfer execution unit 53 executes transfer (trading) of a specified amount of transferable tokens 5 between specified accounts. For example, the paid portion transfer executing unit 53 transfers ownership of a specified amount (number) of transferable tokens 5 from a transfer source account to a specified transfer destination account. A transfer history of the transferable token 5 is recorded in a charge transfer history 51 .
  • the paid portion transfer execution unit 53 is, for example, a transfer function in Ethereum.
  • the paid portion information confirmation unit 54 acquires information on the transferable token 5 currently possessed by the designated account (for example, information on the current balance), and transmits the acquired information to (the node associated with) the account.
  • the paid portion information confirmation unit 54 is, for example, the balanceOf function in Ethereum.
  • At least one of the paid portion transfer history 51, the paid portion issuing unit 52, the paid portion transfer executing unit 53, and the paid portion information confirmation unit 54 is implemented as a smart contract (or data) in the non-transferable token 7.
  • the non-transferable token 7 stores the free consumption history 71.
  • the free portion consumption history 71 is information recording the acquisition (issuance) and consumption history of the non-transferable token 7 for each account.
  • the free portion consumption history 71 is configured as part of the blockchain data.
  • the non-transferable token consumption history 71 includes, for example, the account of the non-transferable token 7 issuer, the account that acquired the non-transferable token 7, the amount (number) of the non-transferable token 7 consumed, and the consumption usage history.
  • the non-transferable token 7 includes a free portion issuing portion 72, a consumption processing portion 73, a free portion information confirmation portion 74, and a paid/unpaid portion information confirmation portion 75.
  • the non-transferable token issuing unit 72 generates the non-transferable token 7 and issues the generated non-transferable token 7 to the user terminal 10 .
  • Information on the issued token is recorded in the free consumption history 71 .
  • the charged portion issuing unit 52 is executed only when an execution request is received from the account related to the management terminal 20 .
  • the non-transferable token 7 can be issued only by the management account (or the management terminal 20).
  • the free portion issuing unit 72 may be executed together with the paid portion issuing unit 52 .
  • the consumption processing unit 73 accepts the specification of the consumption amount of the non-transferable token 7 and executes the consumption of the specified consumption amount for the non-transferable token 7 .
  • This consumption information is recorded in the free portion consumption history 71 .
  • the consumption processing unit 73 can also consume the transferable token 5 . That is, the consumption processing unit 73 consumes part of the designated consumption amount in the non-transferable token 7 to update the free consumption history 71, and consumes the remainder in the transferable token 5 to update the paid consumption history. Update 51.
  • the consumption processing unit 73 accepts the specification of the consumption rule of the non-transferable token 7, and according to the content of the specified consumption rule, consumes the specified consumption amount of the non-transferable token 7 and the transferable token 5. Distribute and perform in each of
  • the free portion information confirmation unit 74 accepts the designation of the account and outputs the information of the non-transferable token 7 associated with the designated account.
  • the paid/unpaid portion information confirmation unit 75 accepts the designation of an account, and integrates information (for example, transfer The total value of the current possession amount of the non-transferable tokens 7 and the current possession amount of the transferable tokens 5) is output.
  • FIG. 3 is a diagram showing an example of hardware provided in each node.
  • the terminal 5 includes a processing device 91 such as a CPU (Central Processing Unit), a main storage device 92 such as a RAM (Random Access Memory) and a ROM (Read Only Memory), a HDD (Hard Disk Drive), an SSD (Solid State Drive). ), an input device 94 consisting of a keyboard, a mouse, a touch panel, etc., an output device 95 consisting of a monitor (display), etc., and a communication device 96 for communicating with other information processing devices. processing equipment.
  • a processing device 91 such as a CPU (Central Processing Unit)
  • main storage device 92 such as a RAM (Random Access Memory) and a ROM (Read Only Memory), a HDD (Hard Disk Drive), an SSD (Solid State Drive).
  • an input device 94 consisting of a keyboard, a mouse, a touch panel, etc.
  • an output device 95 consisting of a monitor (disp
  • Each function of the node is realized by the hardware of the node or by executing a program (smart contract) stored in the main storage device 92 or the auxiliary storage device 93 by the processing device 91 of the node.
  • these programs are, for example, storage devices such as secondary storage devices, nonvolatile semiconductor memories, hard disk drives, and SSDs, or non-temporary data that can be read by each node, such as IC cards, SD cards, and DVDs. Stored in a storage medium.
  • FIG. 4 is a flowchart illustrating an example of new issue processing, which is processing for issuing the non-transferable token 7 together with the transferable token 5 .
  • a predetermined issue request is input to the transferable token 5 from the account (management account) associated with the management terminal 20. is started (s11).
  • the payment processing is, for example, a credit card payment or an electronic payment for purchasing the transferable token 5 based on a request from an account related to the user terminal 10, which is executed by the management terminal 20 or a payment system linked to the management terminal 20.
  • Settlement for example, settlement by ETH
  • this settlement amount is assumed to be fixed in this embodiment.
  • the paid portion issuing unit 52 identifies the management account included in the issuance request from the management account, the amount (number) of assets related to the transferable token 5 to be issued, and the account to be issued (s13).
  • the paid token issuing unit 52 realizes the generation and issuance of the transferable token 5 by setting the transferable token 5 of the asset amount specified in s13 in the issuer's account (s15). Specifically, the free token issuing unit 72 adds information on the management account specified in s13, the amount of assets related to the transferable token 5, and the issue destination account to the charged token transfer history 51. FIG. After that, the contents of the paid transfer history 51 (transferable token 5) are shared by all nodes.
  • the non-transferable token issuing unit 72 generates and issues the non-transferable token 7 by setting the non-transferable token 7 of the asset amount specified in s13 to the issue destination account (s17).
  • the free token issuing unit 72 calculates the asset amount (issue amount) of the non-transferable token 7 based on the asset amount of the transferable token 5 specified in s13 (for example, the transferable token 5). Then, the free-of-charge issuing unit 72 adds to the free-of-charge consumption history 71 the management account specified in s13, the amount of assets related to the non-transferable token 7, and the account information of the issue destination. Thereafter, the content of the free portion consumption history 71 (non-transferable token 7) is shared by all nodes. With this, the new issue processing ends.
  • the free portion issuing unit 72 may accept a specification of a specific amount of assets related to the non-transferable token 7 to be issued based on an issue request.
  • process of s17 may be performed immediately after the process of issuing the transferable token 5 in s15, may be performed after some time after the process of s15, or may not be performed. good.
  • FIG. 5 is a flowchart illustrating an example of additional issue processing, which is processing for adding an asset to the non-transferable token 7.
  • the additional issuance process is performed after the transferable token 5 is issued when a preset timing arrives, when the management terminal 20 executes a predetermined process, or when a predetermined issuance request is received from the management account. , etc., is entered.
  • the additional issue processing may be executed before issuing the transferable token 5 (in that case, the asset type of the transferable token 5 needs to be specified).
  • the free portion issuing unit 72 specifies the management account included in the issue request, the amount of assets related to the non-transferable token 7 to be issued, and the issue destination account (s31).
  • the non-transferable token issuing unit 72 creates and issues the non-transferable token 7 by setting the non-transferable token 7 of the asset amount specified in s31 in the account of the issuer (s33). Specifically, the free-of-charge issuing unit 72 adds to the free-of-charge consumption history 71 the management account specified in s31, the amount of assets related to the non-transferable token 7, and the account information of the issuer. Thereafter, the content of the free portion consumption history 71 (non-transferable token 7) is shared by all nodes. With this, the additional issue processing ends.
  • FIG. 6 is a flowchart for explaining an example of consumption processing.
  • Consumption processing is started, for example, when a predetermined consumption instruction is input to the non-transferable token 7 from an account associated with the user terminal 10 .
  • the consumption processing unit 73 determines the account, asset consumption amount, usage, and consumption rule (here, priority between consumption in the transferable token 5 and consumption in the non-transferable token 7) included in the input consumption instruction. ) is obtained (s51).
  • the consumption processing unit 73 determines whether or not consumption of the non-transferable token 7 is given priority over consumption of the transferable token 5 based on the distribution method information (s53). If priority is given to consumption with the non-transferable token 7 (s53: YES), the consumption processing unit 73 executes the process of s55, and if priority is not given to consumption with the non-transferable token 7 (s53: NO), consumption processing The unit 73 executes the process of s69 which will be described later.
  • the consumption processing unit 73 acquires the current asset amount of the non-transferable token 7 associated with the account identified in s51. Specifically, the consumption processing unit 73 acquires the current possession amount by referring to the free consumption history 71 .
  • the consumption processing unit 73 confirms whether or not the amount of consumption identified in s51 is greater than or equal to the amount of assets associated with the current non-transferable token 7 acquired (s57).
  • the consumption processing unit 73 executes the process of s59, and the amount of consumption specified in s51 is If it is less than the current amount of assets associated with the current non-transferable token 7 (s57: NO), the consumption processing unit 73 executes the process of s61.
  • the consumption processing unit 73 reduces the possession amount of assets related to the non-transferable token 7 by the consumption amount specified in s51. Specifically, the consumption processing unit 73 specifies in s51 the amount of assets related to the non-transferable token 7 of the account specified in s51 for the use specified in s51 in the free portion consumption history 71. Add history to indicate that it has decreased by the amount consumed.
  • the consumption processing unit 73 may execute a predetermined process indicated by the usage specified in s51.
  • the consumption processing unit 73 acquires the current possession amount of the transferable tokens 5 associated with the account identified in s51 for the paid amount. Specifically, the consumption processing unit 73 acquires the amount of assets related to the current transferable token 5 by referring to the paid transfer history 51 .
  • the consumption processing unit 73 sets the possession amount of assets related to the non-transferable token 7 to 0 (consumes all of them) and, for example, by calling the paid portion transfer execution unit 53, the shortage of assets is transferred to the transferable token 5. (s65).
  • the consumption processing unit 73 indicates in the free portion consumption history 71 that the possession amount of the asset related to the transferable token 5 of the account identified in s51 has been reduced to 0 due to the usage identified in s51. Add history to show.
  • the consumption processing unit 73 determines the possession amount of the asset related to the transferable token 5 of the account specified in s51 for the paid portion transfer history 51, Add history to indicate that was decreased by the amount it was missing.
  • the consumption processing unit 73 may store a history of transferring the decreased amount of assets to another account (that is, store a transfer history) according to the purpose specified in s51.
  • the consumption processing unit 73 confirms whether or not the current total possession amount of assets related to the transferable token 5 and the non-transferable token 7 is greater than or equal to the consumption amount specified in s51, and the total possession amount is specified in s51. If the consumption amount is less than the calculated consumption amount, error information may be output and the consumption process may be terminated.
  • the consumption processing unit 73 may execute a predetermined process indicated by the usage specified in s51.
  • the paid portion transfer history 51 and the free portion consumption history 71 are shared by all nodes (s67). The consumption processing ends here.
  • the consumption processing unit 73 determines whether the amount of assets associated with the transferable token 5 associated with the account identified in s51 is greater than or equal to the consumption amount identified in s51.
  • the consumption processing unit 73 executes the process of s71, and the possession amount equals the consumption amount specified in s51. If it is less than (s69: NO), the consumption processing unit 73 executes the process of s75.
  • the consumption processing unit 73 calls the paid transfer execution unit 53, for example, to reduce the possession amount of assets related to the transferable token 5 by the consumption amount specified in s51.
  • the consumption processing unit 73 specifies in s51 the possession amount of the asset related to the transferable token 5 related to the account specified in s51 for the use specified in s51 in the paid transfer history 51. Add history to show that it has decreased by the amount consumed.
  • the consumption processing unit 73 may store a history of transferring the subtracted amount of assets to another account (i.e., store a transaction history) according to the purpose specified in s51. .
  • the consumption processing unit 73 may execute processing for the purpose specified in s51.
  • the consumption processing unit 73 acquires the amount of assets associated with the non-transferable token 7 of the assets associated with the account specified in s51. Specifically, the consumption processing unit 73 acquires the current possession amount of the asset related to the non-transferable token 7 by referring to the free consumption history 71 .
  • the consumption processing unit 73 sets the possession amount of assets related to the transferable token 5 to 0 (consumes all of them), and, for example, by calling the paid portion transfer execution unit 53, consumes the shortage with the non-transferable token 7. (s77).
  • the consumption processing unit 73 reduces the possession amount of the asset related to the transferable token 5 related to the account specified in s51 to 0 for the use specified in s51 in the paid transfer history 51. Add history to show what you did. In this case, the consumption processing unit 73 stores the history of transferring the subtracted assets to a predetermined account in the paid transfer history 51 (that is, the transaction history is stored). do).
  • the consumption processing unit 73 compares the amount of non-transferable tokens 7 possessed by the account identified in s51 to the amount of consumption identified in s51 for the use identified in s51 in the free portion consumption history 71. to add a history indicating that the possessed amount of the transferable token 5 has decreased by the amount (remaining amount of consumption) that is insufficient.
  • the consumption processing unit 73 may execute a predetermined process for the purpose specified in s51.
  • FIG. 7 is a flowchart illustrating an example of the free portion information confirmation process.
  • the non-transferable portion information confirmation process is started, for example, when a predetermined confirmation request is input to the non-transferable token 7 from an account associated with the user terminal 10 or the management terminal 20 .
  • the free portion information confirmation unit 74 identifies the account included in the input confirmation request (s81).
  • the free portion information confirmation unit 74 confirms whether or not the information of the non-transferable token 7 is originally set in the account specified in s81, and if the information of the non-transferable token 7 is not set, the error information may be output to end the free portion information confirmation processing.
  • the free portion information confirmation unit 74 acquires information on the non-transferable token 7 associated with the account specified in s81 (s83). Specifically, the free portion information confirming unit 74 acquires the current possession amount of the asset related to the non-transferable token 7 related to the account specified in s81 from the free portion consumption history 71 .
  • the free portion information confirmation unit 74 returns the information acquired in s83 to the account that entered the confirmation request (s85). With this, the free portion information confirmation processing ends.
  • FIG. 8 is a flowchart for explaining an example of paid/unpaid portion information confirmation processing.
  • the fee-free portion information confirmation process is started, for example, when a predetermined confirmation request is input to the non-transferable token 7 from the account in the token management system 1 .
  • the paid/unpaid portion information confirmation unit 75 identifies the account included in the input confirmation request (s91).
  • the paid/unpaid portion information confirmation unit 75 acquires information on the transferable token 5 related to the account identified in s91 (s93). Specifically, the paid/unpaid portion information confirmation unit 75 acquires the current possession amount of assets related to the transferable token 5 related to the account identified in s91 from the paid portion transfer history 51 .
  • the paid/unpaid portion information confirmation unit 75 acquires information on the non-transferable token 7 related to the account identified in s91 (s95). Specifically, the paid/unpaid portion information confirming unit 75 acquires the current possession amount of the asset related to the non-transferable token 7 related to the account identified in s91 from the free portion consumption history 71 .
  • the paid/unpaid portion information confirmation unit 75 returns information obtained by integrating the information obtained in s93 and the information obtained in s95 to the account that has input the confirmation request (s97).
  • the paid/unpaid portion information confirmation unit 75 checks the sum of the amount of assets associated with the transferable token 5 acquired in s93 and the amount of assets associated with the non-transferable token 7 acquired in s97, or Return information indicating quantity. With the above, the paid/unpaid portion information confirmation processing ends.
  • the management terminal 20 in the token management system 1 of the present embodiment generates the asset in the non-transferable token 7, which is another token related to the asset of the transferable token 5 issued at a fixed price.
  • (free consumption history 71) generate and issue a token equipped with a smart contract that consumes a designated consumption amount of assets and stores the consumption amount in the free consumption history 71 .
  • non-transferable tokens 7 In addition to the normal transferable tokens for assets (transferable tokens 5), it is possible to handle asset tokens that are only consumed (non-transferable tokens 7). That is, assets acquired for a fee can be transferable tokens, and assets acquired for free can be consumption-only tokens. As a result, for example, the non-transferable tokens 7 obtained free of charge can be used as incentives to encourage more users to purchase the transferable tokens 5 for a fee. In addition, since the transferable token 5 accompanied by the non-transferable token 7 can be further exchanged for tokens related to other services, it is possible to acquire more users (for example, many users across multiple services) through this. can.
  • transferable tokens 5 and non-transferable tokens 7 can be implemented based on the ERC20 standard, so when dealing with content-specific asset tokens such as in-game currency, assets with flexible specifications according to the characteristics of the content Tokens can be defined.
  • transferable tokens 5 and non-transferable tokens 7 can be implemented using existing platforms such as Ethereum, there is no need for platform operators to intervene, and fees related to token settlement can be kept to a minimum. .
  • transferable token 5 and non-transferable token 7 can be configured as a smart contract in the blockchain, the history of asset transfer and consumption is clearly recorded, and tampering by a third party is impossible.
  • the service provider for the asset issues the transferable token 5 as a prepaid payment instrument (for example, JPYC) that does not fall under virtual currency by setting the transferable token 5 at a continuous fixed price.
  • Free non-transferable tokens 7 can also be issued.
  • the user not only enjoys the merit of the incentive of the non-transferable token 7, but also the service provider is obliged to refund the amount equivalent to the transferable token 5 when the service related to the transferable token 5 is terminated. can enjoy the advantage that the value of the transferable token 5 of the invested token is secured.
  • the management terminal 20 token generation device of the present embodiment, it is possible to continuously provide tokens issued at a fixed price for a fee and tokens issued free of charge.
  • the non-transferable token 7 in the token management system 1 of this embodiment stores a part of the consumption amount of the designated asset in the free consumption history 71 of the non-transferable token 7, and the rest is stored in the transferable token 5 store as consumption in In this way, since the asset can be consumed from both the paid portion and the free portion, the user can freely use the asset based on the breakdown of the tokens held by the user.
  • the service provider can clearly distinguish between the two in terms of data. means) can be easily extracted from the transferable token 5 and grasped. As a result, the service provider can easily perform operations such as notifying the unused balance of the transferable token 5 as the prepaid payment means to the prescribed government office.
  • the non-transferable token 7 in the token management system 1 of the present embodiment accepts the specification of the consumption rule of the non-transferable token 7, and according to the consumption rule, the non-transferable token 7 and the non-transferable token 7 Allocate to consumption in transferable tokens 5 .
  • the method of distributing the consumption of the paid portion and the non-transferable portion determining the priority level between the non-transferable token 7 and the transferable token 5 in this embodiment
  • the user can decide how to utilize the incentive. can be selected.
  • the non-transferable token 7 in the token management system 1 of the present embodiment is such that when the consumption priority of the non-transferable token 7 is higher than the consumption priority of the transferable token 5, the specified consumption amount of the non-transferable token 7 is If it is more than the asset amount, all the non-transferable tokens 7 are consumed, and the remaining transferable tokens 5 excluding the amount consumed by the non-transferable tokens 7 are consumed.
  • the user can maximize the possibility of collecting the dropped transferable tokens 5 .
  • part of the smart contract of each node described in this embodiment may be incorporated into another smart contract, or multiple smart contracts may be integrated into one smart contract.
  • smart contract functions of each node described in this embodiment may be executed by a device independent of the blockchain, and executed by tokens (smart contracts).
  • the token management system 1 may handle multiple types of assets (handle transferable tokens 5 and non-transferable tokens 7 for each of multiple types of assets).
  • non-transferable token 7 may be divided into two or more tokens according to attributes such as the type of issuer's account and the purpose of consumption.
  • the purpose of consumption of each account may be specified in advance so that consumption for purposes other than the specified purpose is prohibited.
  • the issuance of the non-transferable token 7 is completely free of charge. good.
  • the paid/unpaid amount information confirmation unit 75 outputs the total value of the amount of tokens possessed, but other integrated information may be output.
  • the consumption processing unit 73 when the consumption rule (distribution method) for the non-transferable token 7 and the transferable token 5 is defined, the consumption processing unit 73 will , but other distribution methods may be defined.
  • the distribution method may be determined such that the non-transferable tokens 7 and the transferable tokens 5 are consumed concurrently at different predetermined rates.
  • upper or lower limits of consumption may be established.
  • the transferable tokens 5 when the non-transferable tokens 7 are exhausted, the transferable tokens 5 may not be consumed even if the consumption amount is insufficient (or vice versa).

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

トークン生成装置は、所定価額で発行される有償トークンに係るアセットに関する、有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶部と、アセットの消費量の指定を受け付け、指定された消費量のアセットを前記トークンにおいて消費したことを示す情報を消費の履歴に記憶する消費処理部７３と、を有するスマートコントラクトを備えるトークンを生成する。

Description

トークン生成装置、トークン生成方法、及びトークン管理プログラム
　本発明は、トークン生成装置、トークン生成方法、及びトークン管理プログラムに関する。
　スマートコントラクト（Smart contract）を利用した電子アセットの取引が広く行われている。例えば、スマートコントラクトによりユーザ間のアセットの取引を実行し、その取引の履歴が各ノードで共有されるようにしたトークンを発行することが可能なプラットフォームであるイーサリアム（Ethereum）が知られている（例えば、特許文献１）。イーサリアムは、分散型アプリケーション及びスマートコントラクトを構築するためのプラットフォームである。スマートコントラクトは、契約などのプロトコルを自動的に実行するようにブロックチェーンに実装されている。
特開２０１９－１６０３１６号公報
　このようなスマートコントラクトで実装されたトークンは、例えば、サービス業者が所定のサービスを提供するための手段として、継続的に固定価格でユーザに有償で発行することができる（前払式支払手段）。この際、サービス業者は有償で発行する前払式支払手段に相当するトークン（有償トークン）とは別に、インセンティブやリワード用途で無償で発行するトークン（無償トークン）をユーザに付与することができる。
　ただ、ユーザがサービスを利用する際は、有償トークンと無償トークンを見た目上区別なく利用できるようことが好ましい。一方で、サービス業者は前払式支払手段すなわち有償トークンに関する情報を無償トークンと区別して取り扱わなければならない場合があり（例えば、前払式支払手段の未使用残高は財務局長等への届出が必要となる）、両者をそれぞれ客観的に参照できる形で管理する必要がある。
　本発明はこのような背景に鑑みてなされたものであり、その目的は、継続的に固定価格で有償で発行されるトークンと、無償で発行されるトークンとを提供することが可能なトークン生成装置、トークン生成方法、及びトークン管理プログラムを提供することにある。
　以上の課題を解決するための本発明の一つは、所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶部と、前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理部と、を有するスマートコントラクトを備えるトークンを生成する、トークン生成装置、とする。
　また、本発明の他の一つは、情報処理装置が、所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶部と、前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理部と、を有するスマートコントラクトを備えるトークンを生成する、トークン生成方法、とする。
　また、本発明の他の一つは、情報処理装置に、所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶処理と、前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理と、を実行させるトークン管理プログラム、とする。
　本発明によれば、継続的に固定価格で有償で発行されるトークンと、無償で発行されるトークンとを提供することができる。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
図１は、本実施形態に係るトークン管理システムの構成の一例を示す図である。 図２は、トークン（譲渡可能トークン及び譲渡不能トークン）におけるスマートコントラクトの主な機能の一例を説明する図である。 図３は、各ノードが備えるハードウェアの一例を示す図である。 図４は、新規発行処理の一例を説明するフロー図である。 図５は、追加発行処理の一例を説明するフロー図である。 図６は、消費処理の一例を説明するフロー図である。 図７は、無償分情報確認処理の一例を説明するフロー図である。 図８は、有償無償分情報確認処理の一例を説明するフロー図である。
　図１は、本実施形態に係るトークン管理システム１の構成の一例を示す図である。このトークン管理システム１は、トークン３を発行する管理端末２０（トークン生成装置）と、発行されたトークン３を利用する複数のユーザ端末１０とを含んで構成されている。管理端末２０及び各ユーザ端末１０は、１又は複数のアカウント（識別子）と対応づけられている。
　管理端末２０及び各ユーザ端末１０は、あるアセットの処分履歴を記録するブロックチェーンデータであるトークン３により、そのアセットの情報を共有している。具体的には、このトークン３は、アセットの属性によって価値が異なるＮＦＴ（Non Fungible Token）として共有される。アセットの種類は特に限定されないが、例えば、所定の処理又は行為を行うための権利の情報であってもよいし、画像、音楽、文章、ゲームアイテム等の様々なメディアであってもよい。
　ユーザ端末１０及び管理端末２０は、あるアセットに関して、譲渡可能トークン５及び譲渡不能トークン７の２種類のトークン３を管理している。譲渡可能トークン５は、所定の決済に基づき管理端末２０から発行される、アカウント間で譲渡が可能な有償のアセットトークンである。
　また、本実施形態では、譲渡可能トークン５は、価格が変動することのない固定価額で継続的に（期間の限定が無く）発行（販売）される前払式支払手段として機能する。ただし、譲渡可能トークン５に期間の限定又は価格の変動があるものとしても、本実施形態のトークン管理システム１は構成可能である。なお、譲渡可能トークン５は、例えばEthereumに実装されている標準的な機能（ERC20等）により実装が可能である。
　一方、譲渡不能トークン７は、譲渡可能トークン５に係るアセットと同一種類のアセットに係るトークンであるが、譲渡可能トークン５とは別のトークンとして、管理端末２０から発行される。譲渡不能トークン７は、その発行に決済が不要である無償のトークンである。ただし、譲渡不能トークン７は、譲渡可能トークン５と異なりアカウント間でのトークンの譲渡（例えばトークンの取引）が不可能であり、発行を受けたアカウントのみが所定の用途のために消費できる特有のアセットトークンである。
　なお、譲渡不能トークン７の発行のタイミングは、譲渡可能トークン５の発行と同じであってもよいし、譲渡可能トークン５の発行前であってもよいし、譲渡可能トークン５の発行後であってもよい。
　管理端末２０及び各ユーザ端末１０は、これらの各トークン（中のアセット）に係る処理を、プログラムであるスマートコントラクト（Smart Contract）により実行する。
　管理端末２０は、サーバ装置等の情報処理装置である。管理端末２０は、譲渡可能トークン５及び譲渡不能トークン７をユーザ端末１０のアカウントに発行する。
　ユーザ端末１０は、例えば、パーソナルコンピュータ、スマートフォン等の情報処理装置である。ユーザ端末１０は、管理端末２０が発行したトークンを用いて、ユーザ端末１０に係るアカウントが保有するアセットの譲渡（取引）又は消費を行う。
　管理端末２０及び各ユーザ端末１０の間は、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、専用線等の有線又は無線の通信ネットワーク２で接続される。
　以上のトークン管理システム１は、例えばイーサリアム（Ethereum）を用いて実現されるが、以下に説明する各機能が実装可能であれば、他のプラットフォームを利用して実現してもよい。
　次に、ユーザ端末１０及び管理端末２０が備える機能を説明する。
　図２は、ユーザ端末１０及び管理端末２０（以下、ノードという）が記憶しているトークン３（譲渡可能トークン５及び譲渡不能トークン７）におけるスマートコントラクトの主な機能の一例を説明する図である。
　まず、譲渡可能トークン５は、有償分譲渡履歴５１を記憶する。有償分譲渡履歴５１は、アカウント間での譲渡可能トークン５の譲渡の履歴（所有権の移転ないし譲渡の履歴）を記録した情報である。本実施形態では、有償分譲渡履歴５１は、ブロックチェーンデータの一部として構成される。有償分譲渡履歴５１は、例えば、譲渡可能トークン５の移転元のアカウント、移転先のアカウント、及び移転した譲渡可能トークン５の量（数）の履歴を含む。
　次に、譲渡可能トークン５は、有償分発行部５２、有償分譲渡実行部５３、及び有償分情報確認部５４の各機能を備える。
　有償分発行部５２は、譲渡可能トークン５を生成し、生成した譲渡可能トークン５をユーザ端末１０に発行する。発行された譲渡可能トークン５の情報は有償分譲渡履歴５１に記録される。なお、有償分発行部５２は、本実施形態では、管理端末２０に係るアカウントからの実行要求があった場合にのみ実行されるものとする。すなわち、譲渡可能トークン５の発行は管理アカウント（又は管理端末２０）のみが実行できる。
　有償分譲渡実行部５３は、指定されたアカウント間の、指定された量の譲渡可能トークン５の譲渡（取引）を実行する。例えば、有償分譲渡実行部５３は、移転元のアカウントから、指定された移転先のアカウントに、指定された量（数）の譲渡可能トークン５の所有権を移転する。譲渡可能トークン５の譲渡の履歴は有償分譲渡履歴５１に記録される。有償分譲渡実行部５３は、例えば、Ethereumにおけるtransfer関数である。
　有償分情報確認部５４は、指定されたアカウントが現在所持する譲渡可能トークン５の情報（例えば、現在の残高の情報）を取得し、取得した情報を当該アカウント（に係るノード）に送信する。有償分情報確認部５４は、例えば、EthereumにおけるbalanceOf関数である。
　なお、上記の有償分譲渡履歴５１、有償分発行部５２、有償分譲渡実行部５３、及び有償分情報確認部５４の少なくともいずれかは、譲渡不能トークン７におけるスマートコントラクト（又はデータ）として実装されてもよい。
　次に、譲渡不能トークン７は、無償分消費履歴７１を記憶する。無償分消費履歴７１は、各アカウントの、譲渡不能トークン７の取得（発行）及び消費の履歴を記録した情報である。本実施形態では、無償分消費履歴７１は、ブロックチェーンデータの一部として構成される。無償分消費履歴７１は、例えば、譲渡不能トークン７の発行元のアカウント、譲渡不能トークン７を取得したアカウント、消費した譲渡不能トークン７の量（数）、及び消費の用途の履歴を含む。
　譲渡不能トークン７は、無償分発行部７２、消費処理部７３、無償分情報確認部７４、及び有償無償分情報確認部７５を備える。
　無償分発行部７２は、譲渡不能トークン７を生成し、生成した譲渡不能トークン７をユーザ端末１０に発行する。発行されたトークンの情報は無償分消費履歴７１に記録される。なお、有償分発行部５２は、本実施形態では、管理端末２０に係るアカウントからの実行要求があった場合にのみ実行される。すなわち、譲渡不能トークン７の発行は管理アカウント（又は管理端末２０）のみが実行できるものとする。無償分発行部７２は、有償分発行部５２と共に実行されてもよい。
　消費処理部７３は、譲渡不能トークン７の消費量の指定を受け付け、指定された消費量の消費を譲渡不能トークン７に関して実行する。この消費の情報は、無償分消費履歴７１に記録される。
　なお、本実施形態では、消費処理部７３は、譲渡可能トークン５に関する消費も実行可能である。すなわち、消費処理部７３は、指定された消費量のうち一部を、譲渡不能トークン７において消費して無償分消費履歴７１を更新し、残部を譲渡可能トークン５において消費して有償分譲渡履歴５１を更新する。
　この場合、消費処理部７３は、譲渡不能トークン７の消費ルールの指定を受け付け、指定された消費ルールの内容に応じて、指定された消費量の消費を、譲渡不能トークン７及び譲渡可能トークン５のそれぞれにおいて分配して行う。
　次に、無償分情報確認部７４は、アカウントの指定を受け付け、指定されたアカウントに対応づけられている譲渡不能トークン７の情報を出力する。
　有償無償分情報確認部７５は、アカウントの指定を受け付け、指定されたアカウントに係る譲渡不能トークン７の情報と、指定されたアカウントに係る譲渡可能トークン５の情報とを統合した情報（例えば、譲渡不能トークン７の現在の所持量と譲渡可能トークン５の現在の所持量の合計値）を出力する。
　ここで、図３は、各ノードが備えるハードウェアの一例を示す図である。端末５は、ＣＰＵ（Central Processing Unit）などの処理装置９１と、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の主記憶装置９２と、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の補助記憶装置９３と、キーボード、マウス、タッチパネルなどからなる入力装置９４と、モニタ（ディスプレイ）等からなる出力装置９５と、他の情報処理装置と通信を行う通信装置９６とを備える情報処理装置である。ノードの各機能は、ノードのハードウェアによって、もしくは、ノードの処理装置９１が主記憶装置９２や補助記憶装置９３に記憶したプログラム（スマートコントラクト）を実行することによって実現される。また、これらのプログラムは、例えば、二次記憶デバイスや不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤなどの記憶デバイス、又は、ＩＣカード、ＳＤカード、ＤＶＤなどの、各ノードで読み取り可能な非一時的データ記憶媒体に格納される。
　続いて、トークン管理システム１において行われる処理について説明する。
＜新規発行処理＞
　図４は、譲渡不能トークン７を譲渡可能トークン５と共に発行する処理である新規発行処理の一例を説明するフロー図である。
　新規発行処理は、ユーザ端末１０に係るアカウントによる譲渡可能トークン５のための決済処理が実行された後、管理端末２０に係るアカウント（管理アカウント）から所定の発行要求が譲渡可能トークン５に入力された場合に開始される（ｓ１１）。決済処理は、例えば、管理端末２０又は管理端末２０に紐付けられる決済システムが実行する、ユーザ端末１０に係るアカウントからの要求に基づいた、譲渡可能トークン５の購入のためのクレジットカード決済又は電子決済（例えばＥＴＨによる決済）等である。なお、この決済額は、本実施形態では固定されているものとする。
　まず、有償分発行部５２は、管理アカウントからの発行要求に含まれる管理アカウント、発行する譲渡可能トークン５に係るアセットの量（数）、及び発行先のアカウントを特定する（ｓ１３）。
　有償分発行部５２は、ｓ１３で特定したアセットの量の譲渡可能トークン５を、発行先のアカウントに設定することで、譲渡可能トークン５の生成及び発行を実現する（ｓ１５）。具体的には、無償分発行部７２は、有償分譲渡履歴５１に、ｓ１３で特定した管理アカウント、譲渡可能トークン５に係るアセットの量、及び発行先のアカウントの情報を追加する。その後、有償分譲渡履歴５１（譲渡可能トークン５）の内容は全ノードで共有される。
　次に、無償分発行部７２は、ｓ１３で特定したアセットの量の譲渡不能トークン７を、発行先のアカウントに設定することで、譲渡不能トークン７の生成及び発行を実現する（ｓ１７）。
　具体的には、無償分発行部７２は、ｓ１３で特定した譲渡可能トークン５に係るアセットの量に基づき、譲渡不能トークン７に係るアセットの量（発行量）を算出する（例えば、譲渡可能トークン５に係るアセットの発行量の所定割合とする）。そして、無償分発行部７２は、無償分消費履歴７１に、ｓ１３で特定した管理アカウント、譲渡不能トークン７に係るアセットの量、及び発行先のアカウントの情報を追加する。その後、無償分消費履歴７１（譲渡不能トークン７）の内容は全ノードで共有される。以上で新規発行処理は終了する。
　なお、無償分発行部７２は、発行する譲渡不能トークン７に係るアセットの具体的な量の指定を発行要求に基づき受け付けてもよい。
　また、ｓ１７の処理は、ｓ１５における譲渡可能トークン５の発行処理後続けて行われてもよいし、ｓ１５の処理後、時間をおいて行われてもよいし、当該処理は行われなくてもよい。
＜追加発行処理＞
　図５は、譲渡不能トークン７にアセットを追加する処理である追加発行処理の一例を説明するフロー図である。追加発行処理は、譲渡可能トークン５の発行後であって、予め設定したタイミングが到来した場合、管理端末２０が所定の処理を実行した場合、又は管理アカウントから所定の発行要求が譲渡不能トークン７に入力された場合等に開始される。ただし、追加発行処理は、譲渡可能トークン５の発行前に実行されてもよい（その場合は、譲渡可能トークン５のアセットの種類は特定されている必要がある）。
　無償分発行部７２は、発行要求に含まれる管理アカウント、発行する譲渡不能トークン７に係るアセットの量、及び発行先のアカウントを特定する（ｓ３１）。
　無償分発行部７２は、ｓ３１で特定したアセット量の譲渡不能トークン７を、発行先のアカウントに設定することで、譲渡不能トークン７の生成及び発行を実現する（ｓ３３）。具体的には、無償分発行部７２は、無償分消費履歴７１に、ｓ３１で特定した管理アカウント、譲渡不能トークン７に係るアセットの量、及び発行先のアカウントの情報を追加する。その後、無償分消費履歴７１（譲渡不能トークン７）の内容は全ノードで共有される。
　以上で追加発行処理は終了する。
＜消費処理＞
　次に、図６は、消費処理の一例を説明するフロー図である。消費処理は、例えば、ユーザ端末１０に係るアカウントから所定の消費指示が譲渡不能トークン７に入力された場合に開始される。
　消費処理部７３は、入力された消費指示に含まれるアカウント、アセットの消費量、用途、及び消費ルール（ここでは、譲渡可能トークン５における消費と譲渡不能トークン７における消費の間の優先順位の高低）の情報を取得する（ｓ５１）。
　消費処理部７３は、分配方法の情報に基づき、譲渡不能トークン７での消費を譲渡可能トークン５での消費より優先するか否かを判定する（ｓ５３）。譲渡不能トークン７での消費を優先する場合は（ｓ５３：ＹＥＳ）、消費処理部７３はｓ５５の処理を実行し、譲渡不能トークン７での消費を優先しない場合は（ｓ５３：ＮＯ）、消費処理部７３は後述するｓ６９の処理を実行する。
　ｓ５５において消費処理部７３は、ｓ５１で特定したアカウントに係る譲渡不能トークン７のアセットの現在の所持量を取得する。具体的には、消費処理部７３は、無償分消費履歴７１を参照することで、現在の所持量を取得する。
　そして、消費処理部７３は、ｓ５１で特定した消費量が、上記取得した現在の譲渡不能トークン７に係るアセットの所持量以上であるか否かを確認する（ｓ５７）。
　ｓ５５で特定した消費量が現在の譲渡不能トークン７に係るアセットの所持量以上である場合には（ｓ５７：ＹＥＳ）、消費処理部７３はｓ５９の処理を実行し、ｓ５１で特定した消費量が現在の現在の譲渡不能トークン７に係るアセットの所持量未満である場合には（ｓ５７：ＮＯ）、消費処理部７３はｓ６１の処理を実行する。
　ｓ５９において消費処理部７３は、譲渡不能トークン７に係るアセットの所持量を、ｓ５１で特定した消費量の分だけ減少させる。具体的には、消費処理部７３は、無償分消費履歴７１に対して、ｓ５１で特定した用途のために、ｓ５１で特定したアカウントの譲渡不能トークン７に係るアセットの所持量をｓ５１で特定した消費量の分だけ減少したことを示す履歴を追加する。
　なお、消費処理部７３は、ｓ５１で特定した用途が示す所定の処理を実行してもよい。
　その後、無償分消費履歴７１の内容は全ノードで共有される（ｓ６１）。以上で消費処理は終了する。
　ｓ６３において消費処理部７３は、有償分における、ｓ５１で特定したアカウントに係る譲渡可能トークン５の現在の所持量を取得する。具体的には、消費処理部７３は、有償分譲渡履歴５１を参照することで、現在の譲渡可能トークン５に係るアセットの所持量を取得する。
　そして、消費処理部７３は、譲渡不能トークン７に係るアセットの所持量を０とする（全て消費する）と共に、例えば有償分譲渡実行部５３を呼び出すことで、不足分のアセットを譲渡可能トークン５で消費する（ｓ６５）。
　具体的には、消費処理部７３は、無償分消費履歴７１に対して、ｓ５１で特定した用途により、ｓ５１で特定したアカウントの譲渡可能トークン５に係るアセットの所持量を０に減少したことを示す履歴を追加する。
　そして消費処理部７３は、有償分譲渡履歴５１に対して、ｓ５１で特定したアカウントの譲渡可能トークン５に係るアセットの所持量を、ｓ５１で特定した消費量に対して譲渡不能トークン７の所持量が不足していた分だけ減少したことを示す履歴を追加する。この場合、消費処理部７３は、ｓ５１で指定された用途に応じて、減少した分のアセットを他アカウントに移転した履歴を記憶する（すなわち譲渡の履歴を記憶する）ようにしてもよい。
　なお、消費処理部７３は、譲渡可能トークン５及び譲渡不能トークン７に係るアセットの現在の合計所持量がｓ５１で特定した消費量以上であるか否かを確認し、合計所持量がｓ５１で特定した消費量未満である場合には、エラー情報を出力して消費処理を終了してもよい。
　また、消費処理部７３は、ｓ５１で特定した用途が示す所定の処理を実行してもよい。
　その後、有償分譲渡履歴５１及び無償分消費履歴７１は全ノードで共有される（ｓ６７）。以上で消費処理は終了する。
　一方、ｓ６９において消費処理部７３は、ｓ５１で特定したアカウントに係る譲渡可能トークン５に係るアセットの所持量が、ｓ５１で特定した消費量以上であるか否かを判定する。
　譲渡可能トークン５に係るアセットの所持量がｓ５１で特定した消費量以上である場合は（ｓ６９：ＹＥＳ）、消費処理部７３はｓ７１の処理を実行し、当該所持量がｓ５１で特定した消費量未満である場合は（ｓ６９：ＮＯ）、消費処理部７３はｓ７５の処理を実行する。
　ｓ７１において消費処理部７３は、例えば有償分譲渡実行部５３を呼び出すことで、譲渡可能トークン５に係るアセットの所持量を、ｓ５１で特定した消費量の分だけ減少させる。具体的には、消費処理部７３は、有償分譲渡履歴５１に対して、ｓ５１で特定した用途のため、ｓ５１で特定したアカウントに係る譲渡可能トークン５に係るアセットの所持量を、ｓ５１で特定した消費量の分だけ減少したことを示す履歴を追加する。なお、この場合、消費処理部７３は、ｓ５１で指定された用途に応じて、減算した分のアセットを他アカウントに移転した履歴を記憶する（すなわち取引の履歴を記憶する）ようにしてもよい。
　なお、消費処理部７３は、ｓ５１で特定した用途のための処理を実行してもよい。
　その後、有償分譲渡履歴５１は、全ノードで共有される（ｓ７３）。以上で消費処理は終了する。
　ｓ７５において消費処理部７３は、ｓ５１で特定したアカウントに係るアセットの譲渡不能トークン７に係るアセットの所持量を取得する。具体的には、消費処理部７３は、無償分消費履歴７１を参照することで、譲渡不能トークン７に係るアセットの現在の所持量を取得する。
　そして、消費処理部７３は、譲渡可能トークン５に係るアセットの所持量を０とする（全て消費する）と共に、例えば有償分譲渡実行部５３を呼び出すことで、不足分を譲渡不能トークン７で消費する（ｓ７７）。
　具体的には、消費処理部７３は、有償分譲渡履歴５１に対して、ｓ５１で特定した用途のために、ｓ５１で特定したアカウントに係る譲渡可能トークン５に係るアセットの所持量を０に減少したことを示す履歴を追加する。なお、この場合、消費処理部７３は、ｓ５１で指定された用途に応じて、減算した分のアセットを所定のアカウントに移転した履歴を有償分譲渡履歴５１に記憶する（すなわち取引の履歴を記憶する）ようにしてもよい。
　そして、消費処理部７３は、無償分消費履歴７１に対して、ｓ５１で特定した用途のために、ｓ５１で特定したアカウントに係る譲渡不能トークン７の所持量を、ｓ５１で特定した消費量に対して譲渡可能トークン５の所持量が不足していた分（消費量の残部）だけ減少したことを示す履歴を追加する。
　なお、消費処理部７３は、ｓ５１で特定した用途のための所定の処理を実行してもよい。
　その後、無償分消費履歴７１及び有償分譲渡履歴５１は全ノードで共有される（ｓ７９）。以上で消費処理は終了する。
＜無償分情報確認処理＞
　図７は、無償分情報確認処理の一例を説明するフロー図である。無償分情報確認処理は、例えば、ユーザ端末１０又は管理端末２０に係るアカウントから所定の確認要求が譲渡不能トークン７に入力された場合に開始される。
　無償分情報確認部７４は、入力された確認要求に含まれるアカウントを特定する（ｓ８１）。なお、無償分情報確認部７４は、ｓ８１で特定したアカウントに譲渡不能トークン７の情報が元々設定されているか否かを確認し、譲渡不能トークン７の情報が設定されていない場合は、エラー情報を出力して無償分情報確認処理を終了してもよい。
　そして、無償分情報確認部７４は、ｓ８１で特定したアカウントに係る譲渡不能トークン７の情報を取得する（ｓ８３）。具体的には、無償分情報確認部７４は、無償分消費履歴７１から、ｓ８１で特定したアカウントに係る譲渡不能トークン７に係るアセットの現在の所持量を取得する。
　そして、無償分情報確認部７４は、ｓ８３で取得した情報を、確認要求を入力してきたアカウントに返信する（ｓ８５）。以上で無償分情報確認処理は終了する。
＜有償無償分情報確認処理＞
　図８は、有償無償分情報確認処理の一例を説明するフロー図である。有償無償分情報確認処理は、例えば、トークン管理システム１におけるアカウントから譲渡不能トークン７に所定の確認要求が入力された場合に開始される。
　有償無償分情報確認部７５は、入力された確認要求に含まれるアカウントを特定する（ｓ９１）。
　有償無償分情報確認部７５は、ｓ９１で特定したアカウントに係る譲渡可能トークン５の情報を取得する（ｓ９３）。具体的には、有償無償分情報確認部７５は、有償分譲渡履歴５１から、ｓ９１で特定したアカウントに係る譲渡可能トークン５に係るアセットの現在の所持量を取得する。
　また、有償無償分情報確認部７５は、ｓ９１で特定したアカウントに係る譲渡不能トークン７の情報を取得する（ｓ９５）。具体的には、有償無償分情報確認部７５は、無償分消費履歴７１から、ｓ９１で特定したアカウントに係る譲渡不能トークン７に係るアセットの現在の所持量を取得する。
　そして、有償無償分情報確認部７５は、ｓ９３で取得した情報とｓ９５で取得した情報とを統合した情報を、確認要求を入力してきたアカウントに返信する（ｓ９７）。
　例えば、有償無償分情報確認部７５は、ｓ９３で取得した譲渡可能トークン５に係るアセットの所持量とｓ９７で取得した譲渡不能トークン７に係るアセットの所持量との合計値、又は、それぞれの所持量を示した情報を返信する。以上で有償無償分情報確認処理は終了する。
　以上のように、本実施形態のトークン管理システム１における管理端末２０（トークン生成装置）は、固定価額で発行される譲渡可能トークン５のアセットに係る他のトークンである譲渡不能トークン７における当該アセットの消費の履歴を記憶し（無償分消費履歴７１）、指定された消費量のアセットを消費すると共にその消費量の消費を無償分消費履歴７１に記憶するスマートコントラクトを備えるトークンを生成、発行する。
　これにより、アセットに関して通常の譲渡が可能なトークン（譲渡可能トークン５）とは別に、消費のみを行うアセットのトークン（譲渡不能トークン７）を取り扱うことができる。すなわち、有償で取得されるアセットは譲渡可能なトークンとし、無償で取得されるアセットは消費のみを行うトークンとすることができる。これにより、例えば、無償で取得される譲渡不能トークン７をインセンティブとして有償の譲渡可能トークン５をより多くのユーザに購入させることができる。また、譲渡不能トークン７を伴う譲渡可能トークン５はさらに他のサービスに係るトークンと交換可能であるから、これを通じてより多くのユーザ（例えば、複数のサービスを跨ぐ多くのユーザ）を獲得することができる。
　また、譲渡可能トークン５及び譲渡不能トークン７はERC20規格をベースに実装することができるので、ゲーム内通貨等、コンテンツ独自のアセットトークンを取り扱う場合に、コンテンツの特性に応じた柔軟な仕様のアセットトークンを定義することができる。また、イーサリアム等の既存のプラットフォームを利用して譲渡可能トークン５及び譲渡不能トークン７を実装できるため、プラットフォーマーを介入させる必要がなく、トークンの決済に係る手数料を最小限に保つことができる。
　また、譲渡可能トークン５及び譲渡不能トークン７はブロックチェーンにおけるスマートコントラクトとして構成することができるため、アセットの譲渡及び消費の履歴が明確に記録され、第三者による改ざんも不可能である。
　また、当該アセットに関するサービス提供者は、譲渡可能トークン５を継続的な固定価格とすることで、譲渡可能トークン５を、仮想通貨に該当しない前払式支払手段（例えば、JPYC）として発行しつつ、無償の譲渡不能トークン７も発行できる。他方、ユーザは譲渡不能トークン７というインセンティブのメリットを享受できるだけでなく、譲渡可能トークン５に係るサービスが終了した場合にはサービス提供者に譲渡可能トークン５相当分の返金義務が発生するため、ユーザにとっては、投資したトークンの譲渡可能トークン５の価値が担保されるというメリットが享受できる。
　このように、本実施形態の管理端末２０（トークン生成装置）によれば、継続的に固定価格で有償で発行されるトークンと、無償で発行されるトークンとを提供することができる。
　また、本実施形態のトークン管理システム１における譲渡不能トークン７は、指定されたアセットの消費量のうち一部を、譲渡不能トークン７における無償分消費履歴７１に記憶し、残部を譲渡可能トークン５における消費として記憶する。このように、アセットの消費を有償分及び無償分のそれぞれから行うことができるので、ユーザは自己の保持するトークンの内訳に基づいて自由にアセットを利用することができる。
　また、ユーザは、譲渡可能トークン５及び譲渡不能トークン７を見た目上区別なく利用可能である一方、サービス提供者は両者をデータ上明確に区別することができ、例えば譲渡可能トークン５（前払式支払手段）の未使用残高の情報を譲渡可能トークン５から容易に抽出して把握できる。これにより、サービス提供者は、前払式支払手段としての譲渡可能トークン５の未使用残高の所定官庁への届出といった業務を容易に行うことができる。
　また、本実施形態のトークン管理システム１における譲渡不能トークン７は、譲渡不能トークン７の消費ルールの指定を受け付け、その消費ルールに応じて、指定された消費量の消費を、譲渡不能トークン７及び譲渡可能トークン５における消費に配分する。このように有償分と無償分の消費の分配方法（本実施形態では譲渡不能トークン７及び譲渡可能トークン５の間の優先順位の高低の決定）を設定することで、ユーザはインセンティブの活用方法を選択することができる。
　また、本実施形態のトークン管理システム１における譲渡不能トークン７は、譲渡不能トークン７の消費優先度が譲渡可能トークン５の消費優先度より高い場合に、指定された消費量が譲渡不能トークン７のアセット量より多ければ、譲渡不能トークン７を全て消費すると共に、譲渡不能トークン７で消費された分を除く残部を譲渡可能トークン５において消費する。このように無償分の消費を特に優先することで、ユーザは、譲渡可能トークン５の投下分の回収の可能性を最大限確保することができる。
　以上に説明した実施形態の説明は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明はその趣旨を逸脱することなく、変更、改良され得ると共に本発明にはその等価物が含まれる。
　例えば、本実施形態で説明した各ノードのスマートコントラクトの一部は、他のスマートコントラクトに組み込んでもよいし、複数のスマートコントラクトを一つのスマートコントラクトに統合してもよい。
　また、本実施形態で説明した各ノードのスマートコントラクトの機能の一部は、ブロックチェーンから独立した装置が実行し、これをトークン（スマートコントラクト）に実行させるものとしてもよい。
　また、トークン管理システム１は、複数種類のアセットを取り扱う（複数種類のアセットのそれぞれに関して、譲渡可能トークン５及び譲渡不能トークン７を取り扱う）ようにしてもよい。
　また、譲渡不能トークン７は、発行先のアカウントの種類、消費の用途等の属性に応じて、２以上のトークンに分割してもよい。
　また、譲渡不能トークン７の発行時に予め、各アカウントの消費の用途を指定し、指定した用途以外の用途による消費ができないようにしてもよい。
　また、本実施形態では、譲渡不能トークン７の発行は完全に無償であるものとしたが、譲渡不能トークン７の発行に、譲渡可能トークン５に係る決済以外の何らかの対価を必要とするものとしてもよい。
　また、本実施形態では、有償無償分情報確認部７５は、トークンの所持量の合計値を出力するものとしたが、その他の統合情報を出力してもよい。
　また、本実施形態では、消費処理部７３は、譲渡不能トークン７及び譲渡可能トークン５の消費ルール（分配方法）を定める場合、譲渡不能トークン７又は譲渡可能トークン５の一方が枯渇した場合に他方を消費することとしたが、それ以外の分配方法の取り扱いを定めてもよい。例えば、譲渡不能トークン７及び譲渡可能トークン５を同時並行的に、それぞれ異なる所定割合で消費するような分配方法の定め方をしてもよい。また、例えば、譲渡不能アセット又は譲渡可能トークン５について、消費の上限又は下限を定めてもよい。また、譲渡不能トークン７が枯渇した場合には、消費量が不足する場合でも、譲渡可能トークン５を消費しないようにしてもよい（その逆にしてもよい）。
１　トークン管理システム、２　通信ネットワーク、１０　ユーザ端末、２０　管理端末、３　トークン、５　譲渡可能トークン、７　譲渡不能トークン、５１　有償分譲渡履歴、５２　有償分発行部、５３　有償分譲渡実行部、５４　有償分情報確認部、７１　無償分消費履歴、７２　無償分発行部、７３　消費処理部、７４　無償分情報確認部、７５　有償無償分情報確認部、９１　処理装置、９２　主記憶装置、９３　補助記憶装置、９４　入力装置、９５　出力装置、９６　通信装置
 

Claims (13)

  1. 　所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶部と、
    　前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理部と、
    　を有するスマートコントラクトを備えるトークンを生成する、トークン生成装置。
  2. 　前記消費処理部は、
    　前記アセットの消費量の指定を受け付け、指定された前記消費量のうち一部を前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶し、前記指定された消費量のうち残部を前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項１に記載のトークン生成装置。
  3. 　前記消費処理部は、
    　前記トークンに関する消費ルールの指定をさらに受け付け、指定された前記消費ルールに従って、前記指定された消費量のうち前記有償トークン及び前記トークンにおける消費量をそれぞれ決定し、決定した前記第２のトークンにおける消費量を前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶し、前記決定した前記有償トークンにおける消費量を前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項２に記載のトークン生成装置。
  4. 　前記消費処理部は、
    　前記トークンにおける消費の優先度が前記有償トークンにおける消費の優先度より高い旨の前記消費ルールを受け付けた場合に、前記指定された消費量が前記トークンおけるアセットの現在量より多いか否かを確認し、前記指定された消費量が前記トークンにおけるアセットの現在量より多い場合には、前記トークンにおいて前記アセットの現在量の全てを消費したことを示す情報を前記消費の履歴に記憶すると共に、前記指定された消費量のうち前記消費した現在量を除いた残部のアセットを前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項３に記載のトークン生成装置。
  5. 　アカウントの指定を受け付け、指定された前記アカウントに対応づけられている前記トークンにおけるアセットの情報を出力する無償分情報確認部を備える、
    　請求項１に記載のトークン生成装置。
  6. 　アカウントの指定を受け付け、指定された前記アカウントに対応づけられている前記トークンにおけるアセットの情報と、前記指定されたアカウントに対応づけられている、前記有償トークンにおけるアセットの情報とを統合した情報を出力する有償無償分情報確認部を備える、
    　請求項１に記載のトークン生成装置。
  7. 　情報処理装置が、
    　所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶部と、
    　前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理部と、
    　を有するスマートコントラクトを備えるトークンを生成する、トークン生成方法。
  8. 　前記情報処理装置が、前記消費処理において、
    　前記アセットの消費量の指定を受け付け、指定された前記消費量のうち一部を前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶し、前記指定された消費量のうち残部を前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項７に記載のトークン生成方法。
  9. 　前記情報処理装置が、前記消費処理において、
    　前記トークンに関する消費ルールの指定をさらに受け付け、指定された前記消費ルールに従って、前記指定された消費量のうち前記有償トークン及び前記トークンにおける消費量をそれぞれ決定し、決定した前記トークンにおける消費量を前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶し、前記決定した前記有償トークンにおける消費量を前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項８に記載のトークン生成方法。
  10. 　前記情報処理装置が、前記消費処理において、
    　前記トークンにおける消費の優先度が前記有償トークンにおける消費の優先度より高い旨の前記消費ルールを受け付けた場合に、前記指定された消費量が前記トークンおけるアセットの現在量より多いか否かを確認し、前記指定された消費量が前記トークンにおけるアセットの現在量より多い場合には、前記トークンにおいて前記アセットの現在量の全てを消費したことを示す情報を前記消費の履歴に記憶すると共に、前記指定された消費量のうち前記消費した現在量を除いた残部のアセットを前記有償トークンにおいて消費したことを示す情報を前記有償トークンに記憶する、
    　請求項９に記載のトークン生成方法。
  11. 　前記情報処理装置が、
    　アカウントの指定を受け付け、指定された前記アカウントに対応づけられている前記トークンにおけるアセットの情報を出力する、
    　請求項７に記載のトークン生成方法。
  12. 　前記情報処理装置が、
    　アカウントの指定を受け付け、指定された前記アカウントに対応づけられている前記トークンにおけるアセットの情報と、前記指定されたアカウントに対応づけられている、前記有償トークンにおけるアセットの情報とを統合した情報を出力する、
    　請求項７に記載のトークン生成方法。
  13. 　情報処理装置に、
    　所定価額で発行される有償トークンに係るアセットに関する、前記有償トークンと異なるトークンにおける当該アセットの消費の履歴を記憶する無償分消費履歴記憶処理と、
    　前記アセットの消費量の指定を受け付け、指定された前記消費量のアセットを前記トークンにおいて消費したことを示す情報を前記消費の履歴に記憶する消費処理と、
    　を実行させるトークン管理プログラム。
     
PCT/JP2021/035969 2021-09-29 2021-09-29 トークン生成装置、トークン生成方法、及びトークン管理プログラム WO2023053293A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2021/035969 WO2023053293A1 (ja) 2021-09-29 2021-09-29 トークン生成装置、トークン生成方法、及びトークン管理プログラム
JP2022541972A JP7177305B1 (ja) 2021-09-29 2021-09-29 トークン生成装置、トークン生成方法、及びトークン管理プログラム
US18/042,491 US20240265379A1 (en) 2021-09-29 2021-09-29 Token generation apparatus, token generation method, and token management program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/035969 WO2023053293A1 (ja) 2021-09-29 2021-09-29 トークン生成装置、トークン生成方法、及びトークン管理プログラム

Publications (1)

Publication Number Publication Date
WO2023053293A1 true WO2023053293A1 (ja) 2023-04-06

Family

ID=84144808

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/035969 WO2023053293A1 (ja) 2021-09-29 2021-09-29 トークン生成装置、トークン生成方法、及びトークン管理プログラム

Country Status (3)

Country Link
US (1) US20240265379A1 (ja)
JP (1) JP7177305B1 (ja)
WO (1) WO2023053293A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7479728B1 (ja) 2023-02-16 2024-05-09 天宿智能科技股▲分▼有限公司 ブロックチェーンを統合するインタレストトークン処理システム及びその方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010527079A (ja) * 2007-05-10 2010-08-05 マイクロソフト コーポレーション 仮想ポイント取引所
JP5785350B1 (ja) * 2014-12-24 2015-09-30 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2017078932A (ja) * 2015-10-20 2017-04-27 大日本印刷株式会社 電子マネー口座の管理サーバ、電子マネーシステム、電子マネープログラム
JP2019067351A (ja) * 2017-09-28 2019-04-25 ゴ カン，チャン オープンマーケットでの電子商取引を介した仮想通貨の作成システムとその方法
WO2020255372A1 (ja) * 2019-06-21 2020-12-24 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 トークン発行方法、情報処理装置、及びブロックチェーンシステム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010527079A (ja) * 2007-05-10 2010-08-05 マイクロソフト コーポレーション 仮想ポイント取引所
JP5785350B1 (ja) * 2014-12-24 2015-09-30 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2017078932A (ja) * 2015-10-20 2017-04-27 大日本印刷株式会社 電子マネー口座の管理サーバ、電子マネーシステム、電子マネープログラム
JP2019067351A (ja) * 2017-09-28 2019-04-25 ゴ カン，チャン オープンマーケットでの電子商取引を介した仮想通貨の作成システムとその方法
WO2020255372A1 (ja) * 2019-06-21 2020-12-24 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 トークン発行方法、情報処理装置、及びブロックチェーンシステム

Also Published As

Publication number Publication date
JP7177305B1 (ja) 2022-11-22
JPWO2023053293A1 (ja) 2023-04-06
US20240265379A1 (en) 2024-08-08

Similar Documents

Publication Publication Date Title
CN108960822B (zh) 一种基于区块链的可用资源配额的兑换方法及装置
CN103038790B (zh) 有效的储值卡交易
WO2019019490A1 (zh) 一种用于支付区块链网络中交易费用的方法和系统
JP5580436B2 (ja) 対価計算システム及び対価計算用のコンピュータプログラム
JP7097980B2 (ja) 利用可能なリソース割当量のためのブロックチェーンベースのセット交換方法および装置
CN107430749A (zh) 结算处理装置、方法以及计算机程序
JP2004171527A (ja) サーバ管理型決済システム
JP2020140400A (ja) 電子通貨、プログラム及び電子通貨取引システム
CN112015577B (zh) 一种智能合约的调用方法和装置
JP7177305B1 (ja) トークン生成装置、トークン生成方法、及びトークン管理プログラム
TWI694403B (zh) 基於區塊鏈的可用資源配額的預兌換方法及裝置
KR20010044264A (ko) 선불식 카드의 운용 방법
JP5945289B2 (ja) ポイント管理システム、並びにそのポイント管理方法及びコンピュータプログラム
CN107533725A (zh) 应用专用的移动数据分配
JP6887170B2 (ja) ゲームシステム、その制御方法及びコンピュータプログラム
JPWO2018092443A1 (ja) デジタルコンテンツ商取引管理装置、デジタルコンテンツ商取引管理方法およびプログラム
JP2024052545A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP2015153039A (ja) 決済システム、並びにその特典管理方法及びコンピュータプログラム
JPWO2021100118A1 (ja) 契約処理方法、及び契約処理システム
JP2015176249A (ja) ポイント管理システム、ポイント管理方法及びコンピュータプログラム
JP6313796B2 (ja) アミューズメント施設向けの決済システム、及びその決済制御方法
CN111932286A (zh) 虚拟奖金发放方法
KR102591081B1 (ko) 블록체인 기반의 디지털 결제 플랫폼 장치 및 그 방법
JP7216858B1 (ja) 情報処理装置及び情報処理方法
JP7242083B2 (ja) 決済システム、並びにその特典管理方法及びコンピュータプログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2022541972

Country of ref document: JP

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

Ref document number: 21959337

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21959337

Country of ref document: EP

Kind code of ref document: A1