WO2022065028A1 - トークン管理方法、エンドユーザ管理装置、およびトークン処理装置 - Google Patents

トークン管理方法、エンドユーザ管理装置、およびトークン処理装置 Download PDF

Info

Publication number
WO2022065028A1
WO2022065028A1 PCT/JP2021/032910 JP2021032910W WO2022065028A1 WO 2022065028 A1 WO2022065028 A1 WO 2022065028A1 JP 2021032910 W JP2021032910 W JP 2021032910W WO 2022065028 A1 WO2022065028 A1 WO 2022065028A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
information
user
management
policy
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2021/032910
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
佑樹 近藤
康範 橋本
丈利 境
太一 石榑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to US18/025,919 priority Critical patent/US20230370266A1/en
Publication of WO2022065028A1 publication Critical patent/WO2022065028A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present invention relates to an electronic trading system.
  • the token economy is operated by a consortium consisting of multiple stakeholders, and there are “consortium owners” who design the composition and governance of the consortium, and “consortium participating companies” who participate in the blockchain network.
  • consortium owner and multiple consortium participating companies operate the blockchain network by owning or substantially controlling the blockchain node.
  • possession or substantial control may be simply referred to as “owning”.
  • owner or corporation may be called the "owner”.
  • end users who issue and distribute tokens using the system infrastructure of the consortium.
  • the end user does not own the blockchain node, and uses a terminal such as a PC or mobile to access the blockchain network and make a transaction.
  • the consortium owner or end user When creating a new token, the consortium owner or end user designs the token specifications, and the consortium owner develops the token program (that is, smart contract) based on the specifications. Then, the consortium participating companies deploy the token program on the blockchain network, so that the end user can issue and distribute the token.
  • the token program that is, smart contract
  • Patent Document 1 As a technique for deploying smart contracts such as tokens on a blockchain, for example, a system and a method for managing a blockchain cloud service (Patent Document 1) are known. By providing the function of building blockchain nodes and deploying smart contracts as a service, this system provides a mechanism for system administrators of consortium participating companies to operate smart contracts without manual work.
  • the present invention has been made in view of the above problems, and the end user is opposed to the end user entrusting the operation of the token to the blockchain network participating organization and the entrusted organization performing the deployment operation.
  • the purpose is to require the consent of the user and to confirm that the system is operated according to the consent of the end user.
  • One aspect of the present invention uses an information processing system composed of a plurality of computers including an arithmetic unit and a storage device, and having a token registration unit, a user management unit, a token management unit, a policy management unit, and a life cycle management unit.
  • a token management method that deploys tokens based on end-user requests.
  • the token registration unit registers the electronic signature and hash, which are the test results and confirmation evidence of the token program, in the storage device as repository information.
  • the user management unit records the end user's consent to entrust the operation of the token to a virtual organization as a trail, and registers it in the storage device as user information management information.
  • the token management unit records the end user's consent to deploy the token as a trail, and registers it in the storage device as token information management information.
  • the policy management unit updates the policy definition registered in the storage device so that the signature of the virtual organization entrusted with the operation is indispensable for deploying the token.
  • the lifecycle management unit Upon receiving the token deployment request, the lifecycle management unit refers to the policy definition and deploys the token when the deployment request satisfies the policy definition.
  • Another aspect of the present invention is an end-user management device connected to a plurality of token processing devices for deploying tokens via a network.
  • This device has a user management unit, and when the user management unit receives a user registration request from a user other than the owner of the token processing device or the end user management device, the information identifying the user and the token A set of information that identifies at least one owner of the processing device and the end user management device as an agent is registered in the user information management table, and the user information management table is stored as a distributed ledger.
  • Another aspect of the present invention is the token processing device connected to the end user management device via a network.
  • This device has registered a set of information that identifies the user, information that identifies at least one owner of the token processing device and the end user management device as an agent, and information that identifies available tokens. , Stores the user information management table.
  • the user information management table constitutes a distributed ledger that employs a blockchain together with a user information management table stored by another token processing device.
  • the present invention makes it possible to deploy tokens with the consent of the end user and to verify the evidence in the token economy, and to improve the transparency of the token economy from the end user's point of view. can.
  • FIG. 1 is a block diagram showing Example 1 of the present invention and showing an example of a device configuration of a token management system. It is a block diagram which shows Example 1 of this invention and shows an example of an end user management apparatus. It is a block diagram which shows Example 1 of this invention and shows an example of a token processing apparatus. It is a block diagram which shows Example 1 of this invention and shows an example of a management terminal. It is a figure which shows Example 1 of this invention and shows an example of a repository information table. It is a figure which shows Example 1 of this invention and shows an example of a user information management table. It is a figure which shows Example 1 of this invention and shows an example of the token information management table.
  • FIG. 1 is a flowchart showing Example 1 of the present invention and showing an example of token issuance request processing executed by an end user management device.
  • FIG. 1 is a flowchart showing Example 1 of the present invention and showing an example of token issuance request processing executed by an end user management device.
  • Example 1 is a flowchart showing Example 1 of the present invention and showing an example of token distribution request processing executed by an end user management device. It is a flowchart which shows Example 1 of this invention and shows an example of the policy management program executed by the token processing apparatus. It is a flowchart which shows Example 1 of this invention and shows an example of the life cycle management program executed by the token processing apparatus. It is a flowchart which shows Example 1 of this invention and shows an example of the audit program executed by the token processing apparatus.
  • Notations such as “first”, “second”, and “third” in the present specification and the like are attached to identify components, and do not necessarily limit the number, order, or contents thereof. is not it. Further, the numbers for identifying the components are used for each context, and the numbers used in one context do not always indicate the same composition in the other contexts. Further, it does not prevent the component identified by a certain number from functioning as the component identified by another number.
  • One embodiment is a token management system comprising a management terminal having a processor and a memory, an end user management device having the processor and the memory, and a token processing device having the processor and the memory, wherein the management terminal is a token.
  • the test result and confirmation evidence of the program are registered in the repository, and the end user management device records and shares the end user's consent to outsource the operation of the token as a trail to virtualize the end user.
  • the end user's consent to deploy the token is recorded and shared as a trail, and the token processing device updates the policy definition so that the signature of the virtual organization entrusted with the operation is essential for deploying the token, and deploys it. Deploy the token only if the request meets the policy definition and verify that the policy definition is written as agreed by the end user.
  • FIG. 1 is a block diagram showing a first embodiment of the present invention and showing an example of a device configuration of a token management system.
  • the token management system of the first embodiment relates to a consortium composed of a consortium owner, a consortium participating company, an end user, and the like.
  • the companies participating in the consortium are, for example, financial institutions that mediate transactions and auditing organizations that audit transaction results.
  • End users are, for example, token issuers, individual investors, institutional investors, and the like.
  • the test results and confirmation evidence of the token program are registered in the repository, and the end user's consent to entrust the operation of the token is recorded and shared on the system as a trail.
  • the policy definition is updated so that the end user is distributed to the virtual organization, the end user's consent to deploy the token is recorded and shared as a trail, and the signature of the virtual organization entrusted with the operation on the system is required for the token deployment. do. Then, the token is deployed only when the deploy request satisfies the policy definition, and it is verified that the policy definition is described according to the end user's agreement.
  • the token management system receives requests from one or more operation terminals 100 owned by an end user such as an issuer company or an investor, and the operation terminal 100, and manages and trades tokens on behalf of the end user.
  • An end-user management device 200 for performing, a plurality of token processing devices 300 for deploying tokens and executing and recording transactions, a plurality of management terminals 400 for managing token processing devices, and a repository device 110 for storing token programs. ,including.
  • the device 200, the token processing device 300, and the management terminal 400 are arranged.
  • the end user owns the operating terminal 100.
  • the consortium participating company or the consortium owner owns the end user management device 200, the token processing device 300, the management terminal 400, and the repository device 110.
  • FIG. 2 is a block diagram showing an example of the end user management device 200.
  • the end user management device 200 is a computer including a memory 201, an arithmetic unit 202, an input device 203, an output device 204, a communication device 205, and a storage device 206.
  • the memory and the storage device may be collectively referred to as a storage device.
  • the storage device 206 includes a user management program 600 that confirms the identity of the end user and records and shares the consent of the end user to entrust the operation of the token to the virtual organization as a trail, and the end user's consent to deploy the token. Is recorded and shared as a trail, and a token management program 700 that requests the deployment of tokens on behalf of the end user is stored.
  • the "end user's agent” means that the end user management device 200 not owned by the end user requests the deployment of the token triggered by the request from the end user.
  • the input device 203 is composed of, for example, a keyboard, a mouse, or a touch panel.
  • the output device 204 is composed of, for example, a display or the like.
  • the communication device 205 is connected to the network and communicates with other computers.
  • the user management program 600 and the token management program 700 are loaded into the memory 201 and executed by the arithmetic unit 202.
  • the arithmetic unit 202 operates as a functional unit that provides a predetermined function by executing processing according to the program of each functional unit.
  • the arithmetic unit 202 functions as a user management unit by executing processing according to the user management program 600. The same applies to other programs.
  • the arithmetic unit 202 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are devices and systems including these functional parts.
  • FIG. 3 is a block diagram showing an example of the token processing device 300.
  • the token processing device 300 is a computer including a memory 301, an arithmetic unit 302, an input device 303, an output device 304, a communication device 305, and a storage device 306.
  • the storage device 306 includes a token program 307 that performs transactions such as issuance and distribution of tokens, a policy management program 800 that manages a system operation policy in the token processing device 300, and a deployment request for the token program only when the policy definition is satisfied.
  • Life cycle management program 900 to be deployed to audit program 1000 to verify the validity of operation policy, user information management table 1200 to record end user information, and token information to record the history of token applications from end users.
  • the management table 1300 and the policy table 1400 that manages the operation policy are stored.
  • the input device 303 is composed of, for example, a keyboard, a mouse, or a touch panel.
  • the output device 304 is composed of, for example, a display or the like.
  • the communication device 305 is connected to the network and communicates with other computers.
  • the token program 307, the policy management program 800, the life cycle management program 900, and the audit program 1000 are loaded into the memory 301 and executed by the arithmetic unit 302.
  • the arithmetic unit 302 operates as a functional unit that provides a predetermined function by executing processing according to the program of each functional unit.
  • the arithmetic unit 302 functions as a policy management unit by executing processing according to the policy management program 800. The same applies to other programs.
  • the arithmetic unit 302 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are devices and systems including these functional parts.
  • the user information management table 1200, the token information management table 1300, and the policy table 1400 are management ledgers distributed and shared by the participants of the token economy, and are the distributed ledgers 1500 described later.
  • the token processing device 300 is stored in the token processing device 300 owned by the consortium owner, the financial institution, and the auditing institution, and the user information, the token information, and the policy are shared.
  • FIG. 4 is a block diagram showing an example of the management terminal 400.
  • the management terminal 400 is a computer including a memory 401, an arithmetic unit 402, an input device 403, an output device 404, a communication device 405, and a storage device 406.
  • the storage device 406 stores a token registration program 500 that executes a test of the token program and registers the test result and the electronic signature in the repository device 110.
  • the input device 403 is composed of, for example, a keyboard, a mouse, or a touch panel.
  • the output device 404 is composed of, for example, a display or the like.
  • the communication device 405 is connected to the network and communicates with other computers.
  • the token registration program 500 is loaded into the memory 401 and executed by the arithmetic unit 402.
  • the arithmetic unit 402 operates as a functional unit that provides a predetermined function by executing processing according to the program of each functional unit.
  • the arithmetic unit 402 functions as a token registration unit by executing a process according to the token registration program 500. The same applies to other programs.
  • the arithmetic unit 402 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are devices and systems including these functional parts.
  • each of the above computers may be configured by a single computer, or any part may be configured by another computer connected by a network.
  • the functions equivalent to each functional part composed of software and programs can be realized by hardware such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit).
  • FIG. 5 is a diagram showing an example of the repository information table 1100.
  • the repository information table 1100 is managed by the repository device 110. Being managed means that access such as recording, modification, and reading is possible.
  • the repository device 110 stores, for example, the source code of a token program, which is a product when a plurality of organizations / developers cooperate to develop one system.
  • the repository information table 1100 includes the token ID 1101, the source code path 1102, the test result 1103, and the hash 1104 in one entry.
  • the token ID 1101 stores a name or an identifier that uniquely identifies the token.
  • the source code path 1102 stores the path of a directory representing a location in the repository device 110 in which the token program identified by the token ID 1101 is located.
  • the test result for the token program is stored in the test result 1103.
  • the hash value of the token program is stored in the hash 1104.
  • FIG. 6 is a diagram showing an example of the user information management table 1200.
  • the user information management table 1200 is distributed and shared among the participants of the consortium, and is managed by the token processing device 300.
  • the user information management table 1200 includes the user ID 1201, the virtual organization ID 1202, and the available token 1203 in one entry.
  • the user ID 1201 stores a name or identifier representing an end user such as an issuer or an investor.
  • the user ID 1201 is a unique value within the consortium.
  • the virtual organization ID 1202 stores a value that uniquely identifies an organization (for example, a consortium participating company or a consortium owner) to which the user identified by the user ID 1201 entrusts the operation of the token within the consortium.
  • the available token 1203 stores a list of token IDs as a list of tokens that can be used by the end user.
  • FIG. 7 is a diagram showing an example of the token information management table 1300.
  • the token information management table 1300 is distributed and shared among the participants of the consortium, and is managed by the token processing device 300.
  • the token information management table 1300 includes an application number 1301, a user ID 1302, a virtual organization ID 1303, a token ID 1304, an application category 1305, and a time stamp 1306 in one entry.
  • the application number 1301 stores the matter processing number issued each time a token application is accepted.
  • the user ID 1302 stores the user ID of the end user who applied for the matter.
  • the virtual organization ID 1303 stores the ID of the virtual organization outsourced to the end user who applied for the matter.
  • a token ID representing the token that is the target of the application in the case is stored.
  • a code indicating the application purpose of the case is stored, and the value of the code is issuance or distribution.
  • the time stamp 1306 stores the date and time when the application for the matter was submitted.
  • FIG. 8 is a diagram showing an example of the policy table 1400.
  • the policy table 1400 is distributed and shared among the consortium participants and managed by the token processing device 300.
  • the policy table 1400 includes the policy name 1401, the policy definition 1402, and the time stamp 1403 in one entry.
  • One entry corresponds to one token and specifies the policy of the token.
  • the policy name 1401 stores a name or identifier that uniquely identifies the policy of the system operation setting.
  • the policy definition 1402 stores the rule definition information of the policy represented by the policy name.
  • the time stamp 1403 stores the last date and time when the policy was updated.
  • FIG. 9 is a diagram showing an example of sharing the user information management table 1200, the token information management table 1300, and the policy table 1400 as the distributed ledger 1500.
  • a block chain is adopted for the distributed ledger 1500, and one entry shown in FIGS. 6, 7, and 8 is regarded as one transaction, and blocks 1511, 1512, and 1513 are used with a plurality of transactions and hash values.
  • blocks 1511, 1512, and 1513 are used with a plurality of transactions and hash values.
  • configuring is an example of configuring.
  • the hash value of the block is calculated from the contents of a plurality of transactions in the block and the hash value of the immediately preceding block, and the transaction contents and the hash value are calculated in each block 1511, 1512, 1513. Each is retained.
  • the blockchain technology is a well-known technology, and it is a decentralized ledger management system that combines a P2P network, a consensus algorithm, a smart contract, anti-counterfeiting and encryption technology.
  • decentralization indicates that specific participants are prohibited from monopolizing the management of data, and each participant participating in the blockchain can manage the data.
  • transparency indicates that the information generated by each participant is disclosed to all participants and shared by all participants. Participants participating in the token community will be able to view all information and ensure the consistency of the recorded information.
  • Falsification resistance suppresses data tampering by generating transactions for each participant and connecting each transaction in a chain based on the electronic signature and hash value. In addition, by disclosing the information generated by each participant, it is possible to suppress the willingness to falsify the data.
  • Fault tolerance means that each participant retains the data or a copy of the data with the participants participating in the blockchain, preventing the data from being damaged or lost even if some participants fail. Is.
  • automatic execution it indicates that the transaction or information issuance is executed after the judgment results related to multiple requirements are aggregated. Alternatively, it indicates that an agreement on the issued information can be made efficiently.
  • the hash value of the transaction content and the transaction identifier may be stored in each block instead of the transaction content.
  • the hash value of the block may be calculated from the hash value of the immediately preceding block, the hash value of the transaction content, and the transaction identifier.
  • the contents of the transaction may be retained by each participant.
  • a device for storing the transaction contents of each participant may be provided.
  • the content of each transaction can be kept private, and the content of the transaction between each participant can be provided to a limited number of participants.
  • FIG. 10 is a flowchart showing an example of the token registration program 500 of the management terminal 400. This process is started when the registration request of the token program is received. It is assumed that the token ID 1101 and the source code path 1102 of the repository information table 1100 have already been registered before the registration request of the token program.
  • the token registration program 500 will be described as the subject of processing, but the arithmetic unit 402 may be the subject of processing.
  • the subject of this process may be called the token registration unit.
  • the token registration program 500 receives a token program registration request from the management terminal 400 (S501).
  • the registration request message includes, for example, a token ID.
  • the token registration program 500 searches the repository information table 1100 for an entry having the token ID.
  • the token registration program 500 acquires the token program from the source code path of the repository information table of the repository device 110 (S502).
  • the token registration program 500 stores the token program 307 in the token processing device 300 and requests the token test execution (S503).
  • the token program 307 is executed and tested on the token processing device 300.
  • the token registration program 500 receives the test result from the token processing device (S504).
  • the token registration program 500 registers the test result 1103 in the repository information table 1100 (S505).
  • the token registration program 500 determines whether the test result has been completed normally (S506). If it is Success, the process proceeds to S507, and if it is Erlor, the process ends.
  • the token registration program 500 adds an electronic signature to the token program shown in the source code path 1102 of the repository information table 1100 and registers it in the repository device 110 (S507). Further, the token registration program 500 calculates the hash value of the token program and registers it in the repository information table 1100 (S508).
  • FIG. 11 is a flowchart showing an example of the user management program 600 of the end user management device 200. This process is started when the user registration request is received.
  • the user management program 600 will be described as the subject of processing, but the arithmetic unit 202 may be the subject of processing.
  • the subject of this process may be referred to as the user management unit.
  • the user management program 600 receives a user registration request from the operation terminal 100 (S601).
  • the user registration request message includes, for example, the user's name and profile information.
  • the user is an end user such as a token issuing company or an investor.
  • the user management program 600 acquires identity verification data (S602).
  • Identity verification data is a document that confirms that the user's name and profile are correct, such as a copy of a driver's license or passport.
  • the user management program 600 determines whether the registration data included in the user registration request message of S601 and the identity verification data acquired in S602 match (S603). If Yes, the process proceeds to S604, and if No, the process ends.
  • the user management program 600 requests the end user's consent to outsource the operation of the token (S604).
  • the end user indicates his / her consent or disagreement via the operation terminal 100.
  • the user management program 600 determines whether or not consent has been obtained (S605). If Yes, the process proceeds to S606, and if No, the process ends.
  • the user management program 600 adds the user ID and the virtual organization ID to the user information management table 1200 of the token processing device 300.
  • the virtual organization ID is an organization name or organization ID that identifies the organization to which the end user entrusts the operation of the token. Information that identifies the virtual organization, such as the organization name and organization ID, is included in the user registration request. Alternatively, an organization entrusted by the end user may be registered in advance. For example, when the consortium owner operates the end user management device 200, the organization ID of the consortium owner may be assigned to the virtual organization ID. Further, the organization ID of the blockchain participating organization other than the consortium owner may be assigned to the virtual organization ID.
  • virtual organizations to be outsourced may be selected from blockchain participating organizations other than the consortium owner and grouped according to the attributes of the end user. For example, a virtual organization ID may be assigned to each country / region in which the end user resides.
  • the virtual organization is, for example, an owner who owns at least one pair of a token processing device 300 and a management terminal 400.
  • FIG. 12A is a flowchart showing an example of the token management program 700 of the end user management device 200. This process is started when the end user management device 200 receives the token application request from the operation terminal 100.
  • the token management program 700 will be described as the subject of processing, but the arithmetic unit 202 may be the subject of processing. For convenience, the subject of this process may be called the token management unit.
  • the token management program 700 accepts a token application request from the operation terminal 100 (S701).
  • the token application request includes, for example, the user ID and token ID of the end user who applies.
  • the token management program 700 extracts the token ID from the request message of S701, searches the repository information table 1100 by the token ID, and acquires the test result 1103 of the corresponding token (S502).
  • the test result is the operation verification result of the corresponding token program carried out by the constituent organization of the consortium (specifically, the token processing device 300).
  • the token management program 700 determines whether the test result has been completed normally (S703). If it is Success, the process proceeds to S704, and if it is Erlor, the process ends.
  • the token management program 700 determines the application classification of the request message received in S701 (S704). If the processing category is issuance, the process proceeds to S705, and if the processing category is distribution, the process proceeds to S706.
  • the token management program 700 executes a token issuance request process (S705). Details of this process will be described later with reference to S711 to S720 shown in FIG. 12B.
  • the token management program 700 executes the token distribution request processing (S706). Details of this process will be described later in S721 to S724 shown in FIG. 12C.
  • the token management program 700 determines whether the execution results of S705 and S706 have been completed normally (S707). If Yes, the process proceeds to S708, and if No, the process ends.
  • the token management program 700 adds the token ID of the corresponding token to the available token 1203 of the user information management table 1200 (S708).
  • FIG. 12B shows S711 to S720 that perform token issuance request processing in the flowchart showing an example of the token management program 700 of the end user management device 200.
  • the token management program 700 requests the end user to make a final confirmation as to whether or not to deploy the token (S711).
  • the token management program 700 acquires a response from the end user and determines whether consent has been obtained (S712). Requests and responses are made via the operation terminal 100. If Yes, the process proceeds to S713, and if No, the process proceeds to S720.
  • the token management program 700 sets the application category to "issue" and uniquely defines the application category 1301, the user ID 1302, the virtual organization ID 1303, and the token ID 1304 as end-user consent information in the application category 1305 of the token information management table 1300. And add an entry with the time stamp 1306 (S713).
  • User ID 1302 and token ID 1304 are obtained from the token application request.
  • the virtual organization ID 1303 is specified from the user information management table 1200 based on the user ID 1302 and the token ID 1304. Timestamp 1306 is the time to receive the token application request or the time to add the entry.
  • the token management program 700 acquires the DeplayPolice of the token ID from the policy table 1400 (S714).
  • the acquired policy definition is, for example, "Majority [Majority [Org1, Org2, Org3]" for the token T001.
  • This definition means that a consensus building when deploying tokens requires the signature of a majority of the three organizations Org1, Org2, and Org3.
  • Org1, Org2, and Org3 are consortium participating companies that own the token processing device 300 and are responsible for the system operation of the blockchain network. Since the entire system agrees whether to deploy the token program, the default policy definition is that the majority of the node-owning organizations sign.
  • the token management program 700 creates a policy change request with the condition that the signature of the virtual organization is required for DepleyPoly (S715).
  • the updated policy definition is, for example, "Org1 AND Majority [Org1, Org2, Org3]". This definition means that consensus building when deploying tokens requires the signature of Org1 and the signature of a majority of the three organizations Org1, Org2, and Org3. The default policy required the consensus of a majority of organizations with the intention of system-wide stability.
  • the policy definition is updated so that the signature of the virtual organization entrusted with the operation of the token by the end user, that is, Org1 who is the agent is required. .. Org1 is mandatory and new tokens cannot be deployed with only the signatures of a majority of organizations.
  • the token management program 700 of the end user management device 200 transmits a policy change request to the policy management program 800 of the token processing device 300 (S716).
  • the token management program 700 receives the execution result of the policy update (S717).
  • the token management program 700 of the end user management device 200 transmits a deployment request for the token to the life cycle management program 900 of the token processing device 300 (S718).
  • the token management program 700 receives the execution result of the deployment (S719).
  • the token management program 700 generates error information when the end user does not agree to deploy in S712 (S720).
  • FIG. 12C shows S721 to S724 that perform token distribution request processing in the flowchart showing an example of the token management program 700 of the end user management device 200.
  • the token management program 700 requests the end user to make a final confirmation as to whether or not to use the token (S721).
  • the token management program 700 acquires a response from the end user and determines whether consent has been obtained (S722). Requests and responses are made via the operation terminal 100. If Yes, the process proceeds to S723, and if No, the process proceeds to S724.
  • the token management program 700 sets the application category to "distribution" and uniquely defines the application number 1301, the user ID 1302, the virtual organization ID 1303, the token ID 1304, and the time stamp 1306 as the consent information of the end user in the token information management table 1300. And add an entry (S723).
  • the virtual organization ID 1303 is specified from the user information management table 1200 based on the user ID 1302 and the token ID 1304. Others are the same as the "issue" process.
  • the token management program 700 generates error information when the end user does not agree to use the token (S724).
  • FIG. 13 is a flowchart showing an example of the policy management program 800 of the token processing device 300. This process is started when a policy change request is received.
  • the policy management program 800 will be described as the subject of processing, but the arithmetic unit 302 may be the subject of processing. For convenience, the subject of this process may be called the policy management department.
  • the policy management program 800 receives a policy change request from the token management program 700 of the end user management device 200 (S801).
  • the policy change request message includes, for example, a token ID and a virtual organization ID acting as an agent.
  • the policy management program 800 acquires the name of the organization that sent the policy change request (S802).
  • the policy management program 800 determines in the user information management table 1200 whether or not there is a record in the user information management table 1200 that trusts the virtual organization acquired by the user in the previous step S802 (S803). If Yes, the process proceeds to S804, and if No, the process ends.
  • the policy management program 800 determines whether or not there is a record in the token information management table 1300 that the user has agreed to deploy to the token (S804). If Yes, the process proceeds to S805, and if No, the process ends.
  • the policy management program 800 updates the policy table 1400 regarding the token (S805).
  • the policy management department when the policy management department receives the policy change request, it acquires the information for identifying the token related to the policy change request and the information for identifying the organization that sent the policy change request based on the policy change request. .. Then, the user information management table is referred to, and the entry associated with the organization that sent the policy change request is extracted for the token related to the policy change request. Then, refer to the token information management table, check whether the user specified in the entry has consented to the issuance of the token for the token related to the policy change request, and only if the consent can be confirmed, the policy table To change.
  • FIG. 14 is a flowchart showing an example of the life cycle management program 900 of the token processing device 300. This process is started when a deploy request is received.
  • the life cycle management program 900 will be described as the main body of processing, but the arithmetic unit 302 may be the main body of processing.
  • the main body of this process may be called the life cycle management department.
  • the life cycle management program 900 receives a deployment request from the token management program 700 of the end user management device 200 (S901).
  • the life cycle management program 900 searches the repository information table 1100 with the token ID to be deployed, and acquires the token program and hash value of the corresponding record (S902).
  • the life cycle management program 900 calculates the hash value of the tested token program (S903).
  • the life cycle management program 900 determines whether or not the hash value registered in the repository acquired in S902 matches the hash value calculated in S903 (S904). If Yes, the process proceeds to S905, and if No, the process proceeds to S911.
  • the reason for confirming the hash match here is to verify that there is no change or tampering with the token program from the time when the token registration program 500 executes the test to the time when the deployment request is received. If the hash values do not match, the token program has been changed or tampered with, so deployment is not performed.
  • the lifecycle management program 900 is executed by each organization in the consortium, so that each organization can check the token program. In addition, since the end user outsources the operation of the token to the virtual organization, the virtual organization can verify the change or falsification of the token program.
  • the life cycle management program 900 acquires the Deployment Request of the token related to the deployment request from the policy table 1400 (S905). Further, the life cycle management program 900 acquires a signed organization from the token program acquired in S902 (S906).
  • the signature here is an electronic signature given by the token registration program 500 of the management terminal 400 when the test of the token program is normally completed. Since the token registration program 500 is executed by each organization in the consortium, electronic signatures of a plurality of organizations are given.
  • the life cycle management program 900 determines whether the organization list acquired in S906 satisfies the policy definition acquired in S905 (S907). If Yes, the process proceeds to S906, and if No, the process proceeds to S910.
  • the life cycle management program 900 executes the deployment of the token program when the policy definition is satisfied (S908).
  • the life cycle management program 900 returns a response that the execution result is successful (S909).
  • the life cycle management program 900 terminates the deployment of the token program abnormally (S910).
  • the life cycle management program 900 returns a response that the execution result is a failure (S911).
  • FIG. 15 is a flowchart showing an example of the audit program 1000 of the token processing device 300. This process starts when an audit request is received.
  • the audit request is issued, for example, by an input from the input device 303 or a request from the operation terminal 100 or the management terminal 400.
  • the audit program 1000 will be described as the subject of processing, but the arithmetic unit 302 may be the subject of processing.
  • the subject of this process may be called the Audit Department.
  • the audit program 1000 receives the audit request (S1001).
  • the audit request includes a user ID and a token ID.
  • the audit program 1000 searches the user information management table 1200 by the user ID and the token ID, and acquires the virtual organization ID (S1002).
  • the audit program 1000 acquires the Deplay Policy corresponding to the token ID from the policy table 1400 (S1003).
  • the audit program 1000 extracts the organization ID of the organization that must be signed at the time of deployment from DeploymentPoly (S1004).
  • the audit program 1000 determines whether the virtual organization ID acquired in S1002 and the organization ID acquired in S1004 match (S1005). If Yes, the process ends, and if No, the process proceeds to S1006. The audit program 1000 notifies an alert of policy fraud (S1006).
  • the policy definition becomes invalid, for example, "Org3 AND Majority [Org1, Org2, Org3]".
  • This definition means that consensus building when deploying tokens requires the signature of Org3 and the signature of a majority of the three organizations Org1, Org2 and Org3. Since it is Org1 that the end user entrusts the operation of the token, although the signature of Org1 is normally required, this policy allows the token to be deployed with the approval of Org2 and Org3. .. This will result in transactions that the end user does not want, so it will be detected as a policy fraud and notified to the end user.
  • the consent of the end user in the consortium composed of the token issuing company, its investors, the financial institution that mediates the transaction, the auditing institution that audits the transaction result, and the like. You can deploy tokens under the consortium and validate their evidence.
  • corporate bonds are given as an example of tokens, but the present invention is not limited to these.
  • the information storage in the table is illustrated in the first embodiment, the information storage is not limited to the table and may be stored as schemaless data.
  • the repository device 110 is distributed and the repository information table 1100 is shared as the distributed ledger 1500.
  • a blockchain is adopted for the distributed ledger 1500, and one entry shown in FIG. 11 is regarded as one transaction, and a block is composed of a plurality of transactions and hash values.
  • the token economy it is possible to deploy the token with the consent of the end user and to verify the evidence thereof, and improve the transparency of the token economy from the end user's point of view. be able to.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
PCT/JP2021/032910 2020-09-25 2021-09-07 トークン管理方法、エンドユーザ管理装置、およびトークン処理装置 Ceased WO2022065028A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/025,919 US20230370266A1 (en) 2020-09-25 2021-09-07 Token management method, end-user management apparatus, and token processing apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-161506 2020-09-25
JP2020161506A JP7428622B2 (ja) 2020-09-25 2020-09-25 トークン管理方法、エンドユーザ管理装置、およびトークン処理装置

Publications (1)

Publication Number Publication Date
WO2022065028A1 true WO2022065028A1 (ja) 2022-03-31

Family

ID=80845293

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/032910 Ceased WO2022065028A1 (ja) 2020-09-25 2021-09-07 トークン管理方法、エンドユーザ管理装置、およびトークン処理装置

Country Status (3)

Country Link
US (1) US20230370266A1 (https=)
JP (1) JP7428622B2 (https=)
WO (1) WO2022065028A1 (https=)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7546178B1 (ja) 2024-01-31 2024-09-05 Kddi株式会社 情報処理装置、情報処理方法及びプログラム
JP7595738B1 (ja) 2023-12-26 2024-12-06 Kddi株式会社 情報処理装置、情報処理方法及びプログラム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11695772B1 (en) * 2022-05-03 2023-07-04 Capital One Services, Llc System and method for enabling multiple auxiliary use of an access token of a user by another entity to facilitate an action of the user
US20240333537A1 (en) * 2023-03-28 2024-10-03 Micro Focus Llc Audit Chain for Hashes Using Tokenization
US20250097035A1 (en) * 2023-09-20 2025-03-20 BitsProof Inc. Systems, methods, and devices for identity verificaton
JP7564387B1 (ja) * 2024-01-22 2024-10-08 Kddi株式会社 情報処理装置、情報処理方法及びプログラム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020144526A (ja) * 2019-03-05 2020-09-10 株式会社日立製作所 決済システム及び決済方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020144526A (ja) * 2019-03-05 2020-09-10 株式会社日立製作所 決済システム及び決済方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7595738B1 (ja) 2023-12-26 2024-12-06 Kddi株式会社 情報処理装置、情報処理方法及びプログラム
JP2025101897A (ja) * 2023-12-26 2025-07-08 Kddi株式会社 情報処理装置、情報処理方法及びプログラム
JP2025102674A (ja) * 2023-12-26 2025-07-08 Kddi株式会社 情報処理装置、情報処理方法及びプログラム
JP7546178B1 (ja) 2024-01-31 2024-09-05 Kddi株式会社 情報処理装置、情報処理方法及びプログラム
JP2025117723A (ja) * 2024-01-31 2025-08-13 Kddi株式会社 情報処理装置、情報処理方法及びプログラム

Also Published As

Publication number Publication date
JP2022054353A (ja) 2022-04-06
JP7428622B2 (ja) 2024-02-06
US20230370266A1 (en) 2023-11-16

Similar Documents

Publication Publication Date Title
JP7428622B2 (ja) トークン管理方法、エンドユーザ管理装置、およびトークン処理装置
US11935037B2 (en) Method and apparatus for automated committed settlement of digital assets
JP7204231B2 (ja) 信頼度が低い、または信頼度が皆無の当事者間での価値転送を円滑化する装置、システム、または方法
Alketbi et al. Novel blockchain reference model for government services: Dubai government case study
JP7737198B2 (ja) 方法、システム及びコンピュータプログラム（ブロックチェーンネットワークにおけるコンプライアンスメカニズム）
US20250094945A1 (en) Distributed cryptographic tokens with downstream administrative control
CA3060791C (en) Product promotion using smart contracts in blockchain networks
JP6636058B2 (ja) 分散トランザクションデータベースにおける出所保証のシステムおよび方法
US20230306412A1 (en) Docket credential insertion in non-fungible tokens
US20170243193A1 (en) Hybrid blockchain
CN115880074A (zh) 用于在区块链上记录多个交易的方法和系统
JP7625068B2 (ja) 仮想通貨の有効期限を可能にする電子ウォレット
US20250117848A1 (en) Integrated platform for digital asset registration, tracking and validation
GB2578168A (en) Computer-implemented method and system for digital signing of transactions
KR102590475B1 (ko) 증권형 토큰 정보 관리 서비스 방법 및 sto 플랫폼
Xu et al. Design process for applications on blockchain
Mencias et al. An optimized blockchain solution for the IBM z14
Lu et al. Patterns for blockchain-based payment applications
CN114846765B (zh) 提供去中心化身份验证的方法和设备
CN117201048A (zh) 基于区块链的数据授权方法、装置、设备以及介质
Bouidani Design and implementation of a blockchain shipping application
US20220067028A1 (en) Trustless operations for blockchain networks
HK40017349B (en) Method and apparatus for automated committed settlement of digital assets
HK40017349A (en) Method and apparatus for automated committed settlement of digital assets
Novotny et al. An optimized blockchain solution for the IBM z14

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: 21872159

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: 21872159

Country of ref document: EP

Kind code of ref document: A1