WO2020162574A1 - Procédé de commande, structure de données, serveur et programme - Google Patents

Procédé de commande, structure de données, serveur et programme Download PDF

Info

Publication number
WO2020162574A1
WO2020162574A1 PCT/JP2020/004679 JP2020004679W WO2020162574A1 WO 2020162574 A1 WO2020162574 A1 WO 2020162574A1 JP 2020004679 W JP2020004679 W JP 2020004679W WO 2020162574 A1 WO2020162574 A1 WO 2020162574A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
deposit
distributed ledger
service
token
Prior art date
Application number
PCT/JP2020/004679
Other languages
English (en)
Japanese (ja)
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 CN202080011810.0A priority Critical patent/CN113424217A/zh
Priority to JP2020571276A priority patent/JPWO2020162574A1/ja
Publication of WO2020162574A1 publication Critical patent/WO2020162574A1/fr
Priority to US17/385,131 priority patent/US20210350365A1/en

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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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
    • 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/401—Transaction verification
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates to a control method, a data structure, a server, and a program.
  • the present invention provides a control method and the like that can improve the power consumption efficiency of the system.
  • a control method is a control method executed by one of the plurality of servers in a service management system including a plurality of servers that hold a distributed ledger, and a service application.
  • Receiving the first transaction data which is transaction data regarding the service storing the received first transaction data in the distributed ledger provided in each of the plurality of servers, and the service satisfies a predetermined target condition for the service.
  • Is a service that provides a token to an applicant who is a user who has applied for the service, and when it is determined that the target condition is satisfied, a token predetermined for the service is
  • the second transaction data which is the transaction data indicating to be provided to the user, is stored in the distributed ledger, the first transaction data is stored in the distributed ledger, and then it is determined whether or not the target condition is satisfied.
  • the third transaction data which is transaction data indicating that the user is provided with a deposit, which is a predetermined temporary token for the service, is stored in the distributed ledger at a predetermined timing included in the period up to.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program. It may be realized by any combination of the recording medium and the recording medium.
  • the control method of the present invention can improve the power consumption efficiency of the system.
  • FIG. 1 is a block diagram schematically showing the configuration of the system according to the first embodiment.
  • FIG. 2 is a block diagram schematically showing the configuration of the server according to the first embodiment.
  • FIG. 3 is an explanatory diagram schematically showing deposit issue transaction data according to the first embodiment.
  • FIG. 4 is an explanatory diagram schematically showing the deposit providing transaction data in the first embodiment.
  • FIG. 5 is an explanatory diagram schematically showing deposit invalidation transaction data according to the first embodiment.
  • FIG. 6 is an explanatory diagram schematically showing the token providing transaction data in the first embodiment.
  • FIG. 7 is a flowchart showing the first example of the processing of the server in the first embodiment.
  • FIG. 8 is a flowchart showing a second example of the processing of the server according to the first embodiment.
  • FIG. 9 is a sequence diagram showing the processing of the entire system corresponding to FIG.
  • FIG. 10 is a block diagram schematically showing the configuration of the system in Modification 1 of each embodiment.
  • FIG. 11 is a block diagram schematically showing the configuration of the system according to the second modification of each embodiment.
  • FIG. 12 is a flowchart showing the processing of the server in the modification 3 of each embodiment.
  • FIG. 13 is a block diagram schematically showing the configuration of the server according to the modified example 3 of each embodiment.
  • FIG. 14 is an explanatory diagram showing the data structure of the block chain.
  • FIG. 15 is an explanatory diagram showing the data structure of transaction data.
  • Crowdfunding is a mechanism that collects money from multiple applicants on the Internet and provides the applicants with a financial return obtained by investment etc. using the money.
  • the present invention provides a control method and the like that can improve the power consumption efficiency of the system.
  • a control method is performed by one of the plurality of servers in a service management system including a plurality of servers having a distributed ledger.
  • a first control data that is transaction data relating to a service application, and stores the received first transaction data in the distributed ledger provided in each of the plurality of servers, wherein the service is A service that provides a token to an applicant who is a user who applied for the service when a predetermined target condition for the service is satisfied, and when it is determined that the target condition is satisfied,
  • the second transaction data which is transaction data indicating that a predetermined token for the service is provided to the user, is stored in the distributed ledger, the first transaction data is stored in the distributed ledger, and then the target is stored.
  • a third transaction which is transaction data indicating that a deposit, which is a temporary token predetermined for the service, is provided to the user at a predetermined timing included in a period until it is determined whether or not a condition is satisfied.
  • Data is stored in the distributed ledger.
  • the system provides the user with a temporary token deposit corresponding to the token that is the value information to be provided in the future until the target condition is achieved.
  • Deposits may be managed by a distributed ledger to be used in the same way as tokens or in a token equivalent manner. Therefore, the system can improve the power consumption efficiency by performing the process of giving the value information to the user until the target condition is achieved. Therefore, the control method according to the present invention can improve the power consumption efficiency of the system.
  • the management information related to the provision of deposits managed by the system is managed properly. If the management information is tampered with, the distribution of value information such as deposits and tokens becomes inappropriate. According to the control method of one aspect of the present invention, the management information is stored in the distributed ledger, and tampering is substantially impossible. Therefore, the distribution of the value information such as the deposit and the token can be appropriately managed.
  • a fourth transaction which is transaction data indicating that the deposit holder provides the deposit to a recipient to whom the deposit is provided. Data may be stored in the distributed ledger.
  • the system can further distribute the value information provided to the applicant among the users by the process of providing the deposit to the recipient. Since the system performs the process of distributing the value information in this way, the power consumption efficiency can be further improved. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system.
  • the fifth transaction data may be stored in the distributed ledger.
  • the system performs the process of invalidating the deposit when the target condition is not achieved, so that the validity of the deposit can be appropriately controlled. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the sixth transaction data which is data, may be stored in the distributed ledger.
  • the system performs the process of providing the token corresponding to the deposit when the target condition is achieved, so that the deposit can be managed to be replaced with the token after the target condition is achieved. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the holder holding the deposit may be notified.
  • the system can prompt the action (that is, exchange) to replace the deposit with the token after the target condition is achieved by notifying when the target condition is achieved. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the seventh transaction data which is the transaction data provided by the person to the holder, may be stored in the distributed ledger.
  • the system manages the token that replaces the deposit held by the holder who is not the applicant, as if provided by the applicant. If the deposit held by the holder were simply disappeared, the distribution of the value information would be inappropriate. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the fourth transaction data when storing the fourth transaction data in the distributed ledger, if the deposit is provided more than a predetermined number of times, the fourth transaction data is stored in the distributed ledger. You may restrict what you do.
  • the system can manage the deposit so that it is not provided more than a predetermined number of times.
  • the deposit is intended to limit the range that can be provided in view of the fact that the deposit is used as a token only for the period until the target condition is satisfied. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the process of storing the third transaction data in the distributed ledger may be performed by a smart contract executed when the first transaction data is stored in the distributed ledger.
  • the system executes the process of providing the deposit quickly and safely without the intervention of another person or another system. Therefore, the control method according to the present invention can improve the power consumption efficiency of the system while performing early and safe processing.
  • the consensus algorithm when storing the transaction data in a distributed ledger provided in each of the plurality of servers, the consensus algorithm may be executed by each of the plurality of servers and then stored in the distributed ledger.
  • the system stores the distributed ledger with the execution of the consensus algorithm. Therefore, the control method according to the present invention can more easily improve the power consumption efficiency of the system by executing the consensus algorithm.
  • a data structure is a data structure used in a service management system including a plurality of servers holding a distributed ledger, and is a deposit that is a temporary token predetermined for the service. Information that can uniquely identify the deposit, the identification information that uniquely identifies the recipient to which the deposit is provided, information indicating the amount of the deposit, and an electronic signature of the issuer of the deposit.
  • a server is a server of the plurality of servers in a service management system including a plurality of servers holding a distributed ledger, and includes a processing unit, a control unit, and And the processing unit receives first transaction data that is transaction data related to application for a service, stores the received first transaction data in the distributed ledger provided in each of the plurality of servers, and the service includes A service that provides a token to an applicant who is a user who has applied for the service when a predetermined target condition for the service is satisfied, and the control unit determines that the target condition is satisfied.
  • the second transaction data which is transaction data indicating that a predetermined token for the service is provided to the user
  • the first transaction data is stored in the distributed ledger.
  • the third transaction data which is data, is stored in the distributed ledger.
  • a program according to one aspect of the present invention is a program for causing a computer to execute the above control method.
  • a data structure is a data structure recorded in the distributed ledger in a service management system including a plurality of servers holding a distributed ledger, and the data structure is the service.
  • the first ID indicating a deposit, which is a temporary token given to the applicant of the service, which is valid only until the predetermined time limit, the amount of the deposit, and the use condition of the deposit.
  • a second ID indicating the applicant, and the second ID is recorded in the distributed ledger, and is used in a process of giving the deposit to the applicant.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • it may be realized by any combination of recording media.
  • This system is a system that provides services to applicants.
  • the service is a service that provides value information to an applicant who is a user who has applied for the service when a predetermined target condition for the service is satisfied.
  • a token will be described as an example of the value information.
  • One example of the service is crowdfunding, and this case will be described as an example, but the service may be a financial product such as deposit, insurance, or investment.
  • the unit of fund procurement in a fund is also called a project. It is assumed that the project collects money from a plurality of applicants and uses the money to provide the applicant with a financial return obtained by investment or the like. Regarding a project, the person who manages the project is called the administrator, and the person who applies for funding is called the applicant. The manager recruits funds and manages value information. A project is said to "be true” if it is able to receive an application for funding with a defined target amount during the defined recruitment period for the project.
  • FIG. 1 is a block diagram schematically showing the configuration of the system 1 in this embodiment.
  • the system 1 includes servers 10A, 10B and 10C and terminals 40, 50 and 51.
  • the devices included in the system 1 are connected to each other via a network N so that they can communicate with each other.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the servers 10A, 10B, and 10C are also referred to as "server 10A and the like".
  • the server 10A is one of a plurality of servers 10A, 10B, and 10C that manage crowdfunding performed by the system 1.
  • the server 10A is one of the plurality of servers 10A, 10B, and 10C holding the distributed ledger.
  • the distributed ledger held by the server 10A stores various transaction data related to procedures or processes in crowdfunding. By receiving the transaction data, the server 10A accepts a procedure or process related to a deposit and a token in crowdfunding.
  • fund provision in the project is managed as token provision by the distributed ledger.
  • the token is value information managed by the distributed ledger and corresponds to money, a gift certificate or a coupon, or can be exchanged for money, a gift certificate or a coupon.
  • a deposit means a temporary token that can be used as a token until a token (also referred to as a true token) is provided based on the satisfaction of a target condition. That is, the deposit is managed so that it is valid after the token is provided until it is provided, and is invalid after the token is provided.
  • the deposit can be said to be value information that is temporarily deposited from the system 1 to the user.
  • Each of the servers 10B and 10C is a device having the same function as the server 10A, and operates independently of the server 10A. Note that the number of servers is not limited to three and may be any number.
  • the servers 10A and the like are communicably connected to each other, and may be connected via the network N.
  • the server 10A receives transaction data from the terminal 40 or the like or sends a notification to the terminal 40 or the like, but another server (server 10B or 10C). May perform the above processing.
  • the terminal 40 is a terminal device owned by the administrator.
  • the administrator determines the project recruitment period and the target amount, and registers the system 1 with the terminal 40. Thereby, the administrator recruits the funding by the applicant so that the total amount of the applications for funding by the applicant reaches the target amount.
  • the terminal 40 is, for example, a personal computer, a smartphone, a tablet, or the like.
  • the terminal 50 is a terminal device owned by the applicant.
  • the applicant uses the terminal 50 to refer to the information regarding the offer of funding and apply for funding. Applicants will be provided with a deposit before the project is completed. The deposit provided may also be provided by the applicant to others. The person who holds the deposit (holder) will be provided with a token when the project is completed. It should be noted that the fund may be provided from the applicant to the administrator at the time of application.
  • the terminal 51 is a fund applicant, and is a terminal device owned by an applicant different from the applicant who owns the terminal 50.
  • the terminal 51 is a device having the same function as the terminal 50, and operates independently of the terminal 50.
  • the number of terminals possessed by the applicant is not limited to two, and there are as many terminals as there are applicants.
  • FIG. 2 is a block diagram schematically showing the configuration of the server 10A in this embodiment.
  • the server 10A includes a processing unit 11, a ledger management unit 12, and a control unit 13.
  • the functional unit included in the server 10A can be realized by, for example, a CPU (Central Processing Unit) executing a program using a memory.
  • a CPU Central Processing Unit
  • the processing unit 11 is a processing unit that manages various information by a distributed ledger.
  • the processing unit 11 provides the received or acquired transaction data to the ledger management unit 12 when the transaction data is received from the device in the system 1 or when the transaction data generated by the control unit 13 is acquired.
  • the transaction data includes deposit issue transaction data, deposit providing transaction data, deposit invalidation transaction data, and token providing transaction data. Each transaction data will be described in detail later.
  • the ledger management unit 12 is a processing unit that manages the distributed ledger.
  • the ledger management unit 12 stores the transaction data provided by the processing unit 11 in the distributed ledger. Transaction data from the past to the present is stored in the distributed ledger.
  • the transaction data is managed so as not to be tampered with based on the characteristic that it is difficult to tamper with the information recorded in the distributed ledger.
  • the ledger management unit 12 has a storage unit 15 and a ledger storage unit 16.
  • the storage unit 15 is a processing unit that stores new transaction data to be stored in the distributed ledger in the ledger storage unit 16.
  • the storage unit 15 stores new transaction data in the ledger storage unit 16 by a method according to the type of distributed ledger. Further, the storage unit 15 transmits/receives communication data to/from the storage unit 15 of another server such as the server 10A, and causes the ledger storage unit 16 of the other server to store the new transaction data. For example, when the distributed ledger is a block chain, the storage unit 15 generates a block including new transaction data, synchronizes the generated block with the server 10A, and stores the block in the ledger. It is stored in the section 16.
  • the ledger storage unit 16 is a storage device that stores a distributed ledger.
  • the distributed ledger stored in the ledger storage unit 16 stores one or more transaction data and is managed so as to be difficult to tamper with by using a characteristic such as a hash value (described later).
  • the distributed ledger is, for example, a block chain, and this case will be described as an example, but a distributed ledger of another method (for example, IOTA or hash graph) can be adopted.
  • the distributed ledger may execute a consensus algorithm (for example, PBFT (Practical Byzantine Fault Tolerance), PoW (Proof of Work), or PoS (Proof of Stake)) when storing new data. , May not be executed.
  • PBFT Practice Byzantine Fault Tolerance
  • PoW Proof of Work
  • PoS Proof of Stake
  • Hyperledger fabric As an example of the distributed ledger technology that does not execute the consensus algorithm, there is Hyperledger fabric.
  • the control unit 13 is a processing unit that determines whether or not the target conditions of the crowdfunding project have been achieved, and controls deposits and tokens.
  • the control unit 13 receives the target condition for crowdfunding from the terminal 40.
  • the control unit 13 also receives an application for funding from the terminals 50 and 51.
  • the control unit 13 determines whether or not a crowdfunding target condition is satisfied.
  • control unit 13 determines that the target condition is satisfied, the control unit 13 sends the token providing transaction data (corresponding to the second transaction data) that is the transaction data indicating that the predetermined token for the service is provided to the applicant.
  • the token providing transaction data corresponding to the second transaction data
  • the control unit 13 sends the token providing transaction data (corresponding to the second transaction data) that is the transaction data indicating that the predetermined token for the service is provided to the applicant.
  • control unit 13 controls the provision and effectiveness of the deposit as the control of the deposit. Specifically, the control unit 13 stores a predetermined deposit for the service at a predetermined timing after the application transaction data is stored in the distributed ledger and before it is determined whether the target condition is satisfied. To provide. When the deposit is provided to the applicant, deposit issue transaction data (corresponding to third transaction data), which is transaction data indicating that the deposit is provided, is stored in the distributed ledger.
  • the predetermined timing may be the timing at which it is determined that the condition for providing the deposit to the applicant (also referred to as deposit issuing condition) is satisfied.
  • control unit 13 may determine in advance whether or not the deposit issuance condition is satisfied, and if it is determined that the deposit issuance condition is satisfied, the deposit may be provided to the applicant. .. In addition, providing the deposit from the system 1 to the applicant is also referred to as “issuing”.
  • the deposit issuance condition can be, for example, that a predetermined number of application transaction data have been received, or that the rate of increase in the number of received application transaction data has exceeded a predetermined rate. This is because in these cases, the probability that it is determined that the target condition is satisfied is relatively high.
  • control unit 13 can control the provision of a deposit from a user to another user as the control of the provision of a deposit. That is, the control unit 13 stores the deposit issuance transaction data in the distributed ledger, and then the deposit providing transaction, which is the transaction data indicating that the deposit holder provides the deposit to the recipient to whom the deposit is provided. Data (corresponding to the fourth transaction data) is stored in the distributed ledger.
  • control of the validity of the deposit is to control whether the deposit is treated as valid or invalid.
  • the issued deposit is managed as valid.
  • the token provision transaction data in which the token corresponding to the deposit is provided when the target condition is satisfied is stored in the distributed ledger, the deposit is managed so as to become invalid.
  • the control unit 13 invalidates the deposit when it is determined that the target condition is satisfied or when the target condition is not satisfied.
  • the deposit invalidation transaction data (corresponding to the fifth transaction data), which is the transaction data indicating that the deposit is invalidated, is stored in the distributed ledger.
  • control unit 13 manages so that the deposit is replaced with a true token if the target condition is satisfied after providing the deposit. That is, when the control unit 13 stores the deposit issuance transaction data in the distributed ledger and then determines that the target condition is satisfied, the control unit 13 is a transaction that provides a token corresponding to the deposit to the holder who holds the deposit.
  • the token providing transaction data (sixth transaction data), which is data, is stored in the distributed ledger.
  • the control unit 13 when the target condition is satisfied after providing the deposit, the control unit 13 notifies the deposit holder (more specifically, performs a procedure of exchanging the deposit for a true token). You may make a notification). That is, the control unit 13 may notify the holder holding the deposit when it determines that the target condition is satisfied after storing the deposit issuance transaction data in the distributed ledger.
  • the control unit 13 changes the holder's deposit to a true token.
  • the token may be managed so that it is replaced with the token and the token corresponding to the deposit of the holder is collected from the applicant. That is, the token corresponding to the deposit of the holder may be managed to be provided from the applicant to the holder. That is, the control unit 13 stores the deposit issuance transaction data in the distributed ledger, and then determines that the target condition is not satisfied, and when the deposit holder is not the applicant, a token corresponding to the deposit is sent from the applicant.
  • the token providing transaction data (corresponding to the seventh transaction data) which is the transaction data provided to the holder is stored in the distributed ledger.
  • the control unit 13 may limit the number of deposits provided. That is, when storing the deposit-provided transaction data in the distributed ledger, the control unit 13 stores the deposit-provided transaction data in the distributed ledger if the deposit is provided more than a predetermined number of times. You may restrict what you do.
  • control unit 13 can be performed by a smart contract realized by executing the contract code stored in the ledger storage unit 16, but is not limited to this.
  • the deposit providing process may be performed by a smart contract executed based on storing the first transaction data in the distributed ledger.
  • FIG. 3 is an explanatory diagram schematically showing a first example of deposit issue transaction data in the present embodiment.
  • the deposit issuance transaction data shown in FIG. 3 is generated by the server 10A or the like when the deposit is issued.
  • the deposit issuance transaction data shown in FIG. 3 includes a deposit ID, a provider ID, a deposit amount, an issue date and time, a remaining usage count, and a signature.
  • the deposit ID is an identifier that can uniquely identify the deposit issued by the deposit issuing transaction data.
  • the provider ID is an identifier that can uniquely identify the user who is the provider of the deposit issued by the deposit issuing transaction data.
  • the deposit amount is information indicating the amount of deposit (or the amount of deposit) issued by the deposit issue transaction data.
  • the issue date and time is information indicating the date and time when a deposit is issued according to the deposit issue transaction data.
  • the number of remaining uses is information indicating the number of times the deposit issued by the deposit issue transaction data can be used.
  • the term "use" as used herein means, for example, provision of a deposit, and in this case, the number of remaining uses indicates the number of times the deposit can be provided.
  • the number of remaining uses is an example of restriction information indicating a condition attached to the issued or provided deposit.
  • the limit information may include, in addition to the number of remaining uses, for example, information indicating a ratio of a further provided deposit out of the deposit provided by the deposit providing transaction data.
  • the signature is an electronic signature given by the device or person who generated the deposit issue transaction data.
  • the deposit issuance transaction data shown in FIG. 3 is transaction data for issuing a deposit having a deposit ID “67g4” to the user apa.
  • the issued deposit has a deposit amount of "1", an issue date and time of "2018.10.05 10:00:30", and a remaining usage count of "3 times”.
  • the signature is an electronic signature of the server 10A or the like.
  • the user whose user ID is "A” was described as "user A”. The same applies hereafter.
  • the deposit issuance transaction data shown in FIG. 3 is a data structure used in a service management system including a plurality of servers holding a distributed ledger, and a deposit, which is a temporary token predetermined for a service, is stored. It can be said that the data structure includes uniquely identifiable information, uniquely identifiable information to which the deposit is provided, information indicating the amount of deposit, and the electronic signature of the deposit issuer. ..
  • the deposit issuance transaction data shown in FIG. 3 is a data structure recorded in the distributed ledger in a service management system including a plurality of servers holding the distributed ledger, and the data structure is stored until a predetermined deadline for the service.
  • the first ID indicating the deposit which is a temporary token that is valid only during the period of time and is given to the service applicant, the amount of the deposit, the use condition of the deposit, and the second ID indicating the applicant. It can be said that this is a data structure used for the process of adding a deposit to the applicant after being recorded in the distributed ledger.
  • FIG. 4 is an explanatory diagram schematically showing the deposit-provided transaction data in the present embodiment.
  • the deposit providing transaction data shown in FIG. 4 is generated by the server 10A or the like when the deposit is provided.
  • the deposit providing transaction data shown in FIG. 4 includes a deposit ID, a providing ID, a providing ID, a deposit amount, a providing date and time, a remaining usage count, and a signature.
  • the deposit ID is an identifier that can uniquely identify the deposit provided by the deposit providing transaction data.
  • the provider ID is an identifier that can uniquely identify the user who is the provider of the deposit provided by the deposit providing transaction data.
  • the destination ID is an identifier that can uniquely identify the user who is the destination of the deposit provided by the deposit providing transaction data.
  • the amount of deposit is information indicating the amount of deposit (or the amount of deposit) provided by the deposit providing transaction data.
  • the provision date and time is information indicating the date and time at which a deposit is provided by the deposit provision transaction data.
  • the number of remaining uses is information indicating the number of times the deposit provided by the deposit providing transaction data can be used.
  • the remaining usage count is an example of restriction information indicating a condition attached to the provided deposit.
  • the restriction information may include, for example, information indicating a ratio that can be further provided after being provided by the deposit providing transaction data.
  • the signature is an electronic signature given by the device or person who generated the deposit-provided transaction data.
  • the deposit-provided transaction data shown in FIG. 4 is transaction data for providing a deposit having a deposit ID of “67g4” from the user apa to the user apb.
  • the amount of the deposit is “1”
  • the provision date and time is “2018.10.14 15:00:00”
  • the remaining usage frequency is “2 times”.
  • the signature is an electronic signature of the provider “apa”.
  • FIG. 5 is an explanatory diagram schematically showing deposit invalidation transaction data according to the present embodiment.
  • the deposit invalidation transaction data shown in FIG. 5 is generated by the server 10A or the like when the deposit is invalidated.
  • the deposit invalidation transaction data shown in FIG. 5 includes a deposit ID, an invalidation date and time, and a signature.
  • the deposit ID is an identifier that can uniquely identify the deposit invalidated by the deposit invalidation transaction data.
  • the invalidation date and time is information indicating the date and time when the deposit is invalidated by the deposit invalidation transaction data.
  • the signature is an electronic signature attached by the device or person who generated the deposit invalidation transaction data.
  • the deposit invalidation transaction data shown in FIG. 5 is transaction data for invalidating the deposit having the deposit ID “67g4”.
  • the date and time when the deposit is invalidated is "50:00:2018.10.30".
  • the signature is an electronic signature of the server 10A or the like.
  • FIG. 6 is an explanatory diagram schematically showing the token providing transaction data in the present embodiment.
  • the token providing transaction data shown in FIG. 6 is generated by the server 10A or the like when the token is provided.
  • the token providing transaction data shown in FIG. 6 includes a token ID, a providing source ID, a providing destination ID, a token amount, a providing date and time, and a signature.
  • Token ID is an identifier that can uniquely identify the token provided by the token providing transaction data.
  • the provider ID is an identifier that can uniquely identify the user who is the provider of the token provided by the token providing transaction data.
  • the destination ID is an identifier that can uniquely identify the user who is the destination of the token provided by the token providing transaction data.
  • Token amount is information indicating the amount of token (or the amount of token) provided by the token providing transaction data.
  • the provision date and time is information indicating the date and time when the token is provided by the token provision transaction data.
  • the signature is an electronic signature given by the device or person who generated the token providing transaction data.
  • the token providing transaction data shown in FIG. 6 is transaction data for providing the token having the token ID “10067g4” from the user apa to the user usx.
  • the token to be provided has a token amount of “1” and a provision date and time is “2018.10.30 30:05:00:00”.
  • the signature is an electronic signature of the server 10A or the like.
  • FIG. 7 is a flow chart showing a first example of processing of the server 10A and the like in the present embodiment. It is assumed that the control unit 13 has already acquired the target condition from the terminal 40 of the administrator U1 at the start of the flow chart shown in FIG. 7.
  • step S101 the processing unit 11 determines whether or not the application transaction data is received from the terminal 50 of the applicant U2. If the application transaction data has been received (Yes in step S101), the process proceeds to step S102, and if not (No in step S101), the process proceeds to step S103.
  • step S102 the processing unit 11 stores the application transaction data received in step S101 in the distributed ledger by providing it to the ledger management unit 12. Further, the processing unit 11 transmits the application transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S103 the control unit 13 determines whether the deposit issuance condition is satisfied. If it is determined that the deposit issuance condition is satisfied (Yes in step S103), the process proceeds to step S104, and if not (No in step S103), the process proceeds to step S106.
  • step S104 the control unit 13 generates deposit providing transaction data for issuing a deposit.
  • step S105 the control unit 13 stores the deposit provision transaction data generated in step S104 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the deposit-provided transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like. After this, the provided deposit can be provided to other users. The process of providing the deposit to other users will be described later.
  • step S106 the control unit 13 determines whether the recruitment period has ended. Whether or not the recruitment period has ended is determined by whether or not a predetermined recruitment deadline has arrived. If it is determined that the recruitment period has ended (Yes in step S106), the process proceeds to step S107, and if not (No in step S106), the process proceeds to step S101.
  • step S107 the control unit 13 notifies the applicant U3 and the like, that is, the terminal 50 and the like that the recruitment period has ended. Note that step S107 does not have to be executed.
  • step S108 the control unit 13 determines whether or not the target conditions of the crowdfunding project are satisfied. If it is determined that the target condition is satisfied (Yes in step S108), the process proceeds to step S109, and if not (No in step S108), the process proceeds to step S121.
  • step S109 the control unit 13 notifies the applicant U3 and the like, that is, the terminal 50 and the like that the target condition has been achieved. Note that step S109 may not be executed.
  • step S110 the control unit 13 generates invalidation transaction data for invalidating the deposit.
  • step S111 the control unit 13 stores the invalidation transaction data generated in step S110 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the invalidation transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S112 the control unit 13 generates token providing transaction data for providing a token from the administrator to the deposit holder.
  • the token amount provided is an amount corresponding to the deposit amount held by the holder.
  • step S113 the control unit 13 stores the token providing transaction data generated in step S112 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the token providing transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S121 the control unit 13 notifies the applicant U3 and the like, that is, the terminal 50 and the like that the target condition has not been achieved. Note that step S121 does not have to be executed.
  • step S122 the control unit 13 generates invalidation transaction data for invalidating the deposit.
  • step S123 the control unit 13 stores the invalidation transaction data generated in step S122 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the invalidation transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S124 the control unit 13 generates token providing transaction data for providing a token from the applicant to the recipient.
  • the token amount provided is an amount corresponding to the deposit amount held by the recipient.
  • step S125 the control unit 13 stores the token providing transaction data generated in step S124 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the token providing transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S113 or S125 the series of processing shown in FIG. 7 ends.
  • FIG. 8 is a flowchart showing a second example of processing of the server 10A in this embodiment.
  • the process shown in FIG. 8 is the same as the process shown in FIG. 7 until the deposit is invalidated (step S111 or S123 in FIG. 7) after the deposit is issued (step S105 in FIG. 7). It is a process that is executed in parallel.
  • step S201 the processing unit 11 determines whether or not the deposit providing transaction data is received from the terminal 50 or the like of the applicant U2. If the deposit-provided transaction data has been received (Yes in step S201), the process proceeds to step S202, and if not (No in step S201), step S201 is executed again. That is, the processing unit 11 waits in step S201 until it receives the deposit-provided transaction data.
  • step S202 the control unit 13 refers to the number of remaining uses included in the deposit providing transaction data received in step S201, and determines whether the number of remaining uses is 1 or more. If it is determined that the number of remaining uses is 1 or more (Yes in step S202), the process proceeds to step S203, and if not (No in step S202), the process proceeds to step S211.
  • step S203 the processing unit 11 stores the deposit-provided transaction data received in step S201 in the distributed ledger by providing it to the ledger management unit 12. Further, the processing unit 11 transmits the deposit-provided transaction data to another server 10B or the like and stores it in the distributed ledger of all the servers 10A or the like.
  • step S204 the control unit 13 subtracts 1 from the remaining number of times the deposit is used for the deposit providing transaction data received in step S201.
  • step S204 ends, the process proceeds to step S201.
  • step S211 the control unit 13 notifies the provider that the number of times of use exceeds the limit. At this time, the fact that the number of times of use exceeds the limit may be stored in the distributed ledger.
  • step S211 the process proceeds to step S201.
  • step S202, step S204, and step S211 do not need to be executed if the limit on the number of deposits is not managed.
  • FIG. 9 is a sequence diagram showing the processing of the entire system 1 corresponding to FIG. FIG. 9 shows the processing of the entire system 1 when the target condition is satisfied. Note that the same processes as those in the flowchart of FIG. 7 are denoted by the same reference numerals as those in FIG. 7, and detailed description thereof will be omitted.
  • the terminal 40 of the administrator U1 generates target conditions in advance and sends them to the server 10A and the like (step S301).
  • the target condition includes information such as a deadline for offering and a target amount.
  • the server 10A receives the transmitted target condition and shares it with the server 10A and the like (step S100).
  • step S311 the terminal 50 generates application transaction data and sends it to the server 10A or the like. At this time, the terminal 51 may transmit the generated application transaction data to one of the servers 10A or the like, or may transmit to the plurality of servers.
  • the server 10A, etc. receives the transmitted application transaction data and stores it in the distributed ledger (steps S101 and S102). In addition, when the server 10A or the like determines that the deposit issuance condition is satisfied, the server 10A or the like generates deposit providing transaction data for issuing a deposit to the applicant U3 associated with the terminal 51 that is the transmission source of the application transaction data, and stores it in the distributed ledger. It is stored (steps S103 to 105). When the recruitment period has ended, a notification that the recruitment period has ended is transmitted (steps S106 and S107).
  • the server 10A or the like generates invalidation transaction data for invalidating the already issued deposit and stores it in the distributed ledger (steps S110 to S111).
  • token providing transaction data for providing the token to the holder holding the deposit is generated and stored in the distributed ledger (steps S112 to S113).
  • FIG. 10 is a block diagram schematically showing the configuration of the system 2 in this modification.
  • the system 2 includes servers 10A, 10B and 10C and terminals 40, 50 and 51.
  • the devices included in the system 2 are communicably connected to each other via a network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the servers 10A, 10B and 10C are connected to each other via the network N.
  • a terminal 51 is connected to the server 10A
  • a terminal 50 is connected to the server 10B
  • a terminal 40 is connected to the server 10C.
  • Such a configuration can be used, for example, when a plurality of organizations operate the system 2 and when a server managed by each organization is connected via the network N.
  • the server 10A and the terminal 51 belong to the group A
  • the server 10B and the terminal 50 belong to the group B
  • the server 10C and the terminal 40 belong to the group C.
  • FIG. 11 is a block diagram schematically showing the configuration of the system 3 in this modification.
  • the system 3 includes a server 10D and terminals 40, 50 and 51.
  • the devices included in the system 3 are communicably connected to each other via a network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the server 10D and the terminals 50 and 51 are connected to each other via the network N. Further, the terminal 40 is connected to the server 10D. In this case, each of the terminals 50 and 51 operates as the server 10A and the like in each of the above embodiments.
  • Such a configuration is used, for example, when one or more groups and one or more individuals operate the system 3 and when connecting servers or terminals managed by each group or each individual via the network N. obtain.
  • the server 10D and the terminal 40 belong to the group D, and the group D and the individual applicants U2 and U3 operate the system 3.
  • FIG. 12 is a flowchart showing the processing of the server in this modification.
  • the flow chart shown in FIG. 12 is a control method executed by one of the plurality of servers in a service management system including a plurality of servers holding a distributed ledger.
  • the server receives the first transaction data, which is the transaction data related to the service application, and stores the received first transaction data in the distributed ledger provided in each of the plurality of servers (step S401).
  • the service is a service for providing a token to an applicant who is a user who has applied for the service when a predetermined target condition for the service is satisfied.
  • the server determines that the target condition is satisfied (Yes in step S403), the server stores the second transaction data, which is the transaction data indicating that the predetermined token for the service is provided to the user, in the distributed ledger. (Step S404).
  • the server deposits a temporary token predetermined for the service at a predetermined timing included in the period from the storage of the first transaction data in the distributed ledger to the determination of whether or not the target condition is satisfied.
  • the third transaction data which is the transaction data indicating that the data is provided to the user, is stored in the distributed ledger (step S402).
  • the service management system can improve the power consumption efficiency of the system.
  • FIG. 13 is a block diagram schematically showing the configuration of the server in this modification.
  • one server 60A of the plurality of servers includes a processing unit 61 and a control unit 63.
  • the processing unit 61 receives the first transaction data, which is transaction data related to service application, and stores the received first transaction data in the distributed ledger provided in each of the plurality of servers.
  • the service is a service that provides a token to an applicant who is a user who has applied for the service when a predetermined target condition for the service is satisfied.
  • control unit 63 determines that the target condition is satisfied, the control unit 63 stores, in the distributed ledger, second transaction data that is transaction data indicating that a predetermined token for the service is provided to the user.
  • control unit 63 stores the first transaction data in the distributed ledger, and at a predetermined timing included in the period from the determination of whether or not the target condition is satisfied, the control unit 63 determines a provisional predetermined service.
  • Third transaction data which is transaction data indicating that a deposit that is a token is provided to the user, is stored in the distributed ledger.
  • the service management system can improve the power consumption efficiency of the system.
  • FIG. 14 is an explanatory diagram showing the data structure of the block chain.
  • a block chain is one in which blocks, which are the recording units, are connected in a chain.
  • Each block has a plurality of transaction data and the hash value of the immediately preceding block.
  • the block B2 includes the hash value of the previous block B1.
  • the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2.
  • FIG. 15 is an explanatory diagram showing the data structure of transaction data.
  • the transaction data shown in FIG. 15 includes a transaction body P1 and a digital signature P2.
  • the transaction body P1 is a data body included in the transaction data.
  • the electronic signature P2 is generated by signing the hash value of the transaction body P1 with the signature key of the creator of the transaction data, more specifically, by encrypting with the private key of the creator. is there.
  • the system of the above-described embodiment provides the user with a temporary token deposit corresponding to the token, which is the value information provided in the future, until the target condition is achieved.
  • Deposits may be managed by a distributed ledger to be used in the same way as tokens or in a token equivalent manner. Therefore, the system can improve the power consumption efficiency by performing the process of giving the value information to the user until the target condition is achieved. Therefore, the control method according to the present invention can improve the power consumption efficiency of the system.
  • the management information related to the provision of deposits managed by the system is managed properly. If the management information is tampered with, the distribution of value information such as deposits and tokens becomes inappropriate. According to the control method of one aspect of the present invention, the management information is stored in the distributed ledger, and tampering is substantially impossible. Therefore, the distribution of the value information such as the deposit and the token can be appropriately managed.
  • the system can further distribute the value information provided to the applicant among the users by the process of providing the deposit to the recipient. Since the system performs the process of distributing the value information in this way, the power consumption efficiency can be further improved. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system.
  • the system performs processing to invalidate the deposit when the target condition is not achieved, so it is possible to appropriately control the validity of the deposit. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the system can prompt the action (that is, exchange) to replace the deposit with the token after the target condition is achieved by notifying when the target condition is achieved. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the system also manages tokens provided by the applicant to replace the deposits held by the holder who is not the applicant when the target conditions are met. If the deposit held by the holder were simply disappeared, the distribution of the value information would be inappropriate. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the system can manage the deposit so that it is not provided more than a predetermined number of times.
  • the deposit is intended to limit the range that can be provided in view of the fact that the deposit is used as a token only for the period until the target condition is satisfied. Therefore, the control method according to the present invention can further improve the power consumption efficiency of the system while more appropriately managing the distribution of the value information.
  • the system executes the process of providing the deposit early and safely without the intervention of another person or other system. Therefore, the control method according to the present invention can improve the power consumption efficiency of the system while performing early and safe processing.
  • the system gets the execution of the consensus algorithm and stores the distributed ledger. Therefore, the control method according to the present invention can more easily improve the power consumption efficiency of the system by executing the consensus algorithm.
  • each component may be configured by dedicated hardware, or may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded in a recording medium such as a hard disk or a semiconductor memory.
  • the software that realizes the content management system and the like of the above embodiment is the following program.
  • this program is a control method executed by one of the plurality of servers in a service management system including a plurality of servers that hold a distributed ledger in a computer, and is a transaction related to a service application.
  • the first transaction data which is data
  • the received first transaction data is stored in the distributed ledger provided in each of the plurality of servers, and the service satisfies a predetermined target condition for the service.
  • it is a service that provides a token to an applicant who is a user who has applied for the service, and when it is determined that the target condition is satisfied, a token predetermined for the service is provided to the user.
  • a control method for storing third transaction data which is transaction data indicating provision of a temporary token deposit predetermined for the service to the user, in the distributed ledger is executed. It is a program to let.
  • the present invention can be used for a service management system that manages a service that provides a token to an applicant.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention comprend les étapes consistant à : recevoir des premières données de transaction concernant une application destinée à un service et stocker les premières données de transaction reçues dans un registre distribué fourni à chaque serveur d'une pluralité de serveurs (S401) ; stocker, dans le registre distribué, des secondes données de transaction indiquant la fourniture, à un utilisateur, d'un jeton qui a été prédéterminé en rapport avec le service si une condition cible qui a été prédéterminée pour ce service est déterminée comme ayant été satisfaite, le service impliquant la fourniture, si la condition cible a été satisfaite, du jeton à un demandeur qui est l'utilisateur ayant fait la demande de ce service (S404) ; et stocker, dans le registre distribué, des troisièmes données de transaction indiquant la fourniture, à l'utilisateur, d'un dépôt qui est un jeton provisoire qui a été prédéterminé par rapport au service, à un moment prédéterminée compris dans une durée à partir du moment où les premières données de transaction sont stockées dans le registre distribué jusqu'à ce que la détermination soit faite (S403) quant à la satisfaction de la condition cible (S402).
PCT/JP2020/004679 2019-02-08 2020-02-06 Procédé de commande, structure de données, serveur et programme WO2020162574A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080011810.0A CN113424217A (zh) 2019-02-08 2020-02-06 控制方法、数据结构、服务器、以及程序
JP2020571276A JPWO2020162574A1 (ja) 2019-02-08 2020-02-06 制御方法、データ構造、サーバ、および、プログラム
US17/385,131 US20210350365A1 (en) 2019-02-08 2021-07-26 Control method, data structure, server, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962802861P 2019-02-08 2019-02-08
US62/802,861 2019-02-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/385,131 Continuation US20210350365A1 (en) 2019-02-08 2021-07-26 Control method, data structure, server, and recording medium

Publications (1)

Publication Number Publication Date
WO2020162574A1 true WO2020162574A1 (fr) 2020-08-13

Family

ID=71947784

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/004679 WO2020162574A1 (fr) 2019-02-08 2020-02-06 Procédé de commande, structure de données, serveur et programme

Country Status (4)

Country Link
US (1) US20210350365A1 (fr)
JP (1) JPWO2020162574A1 (fr)
CN (1) CN113424217A (fr)
WO (1) WO2020162574A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (fr) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ Procédé de commande, serveur et programme

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9830651B1 (en) * 2014-01-29 2017-11-28 Square, Inc. Crowdfunding framework
JP2018538639A (ja) * 2015-10-09 2018-12-27 シェ、ウェー 統一されたコード発行に基づく情報処理ネットワーク及び方法並びにセンシングアクセス装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101955833B1 (ko) * 2014-07-11 2019-03-07 로얄 코퍼레이션 트랜잭션 및 비-트랜잭션 커머스를 장려하는 배포형 원장 프로토콜
WO2017027484A1 (fr) * 2015-08-09 2017-02-16 Ramasamy Celambarasan Système et procédé de financement et de distribution de contenu basé sur le micropartage
US20170140408A1 (en) * 2015-11-16 2017-05-18 Bank Of America Corporation Transparent self-managing rewards program using blockchain and smart contracts
WO2018213672A1 (fr) * 2017-05-18 2018-11-22 Codex Llc Procédé et système de distribution décentralisé de contenu numérique utilisant des chaînes de blocs
US11580538B2 (en) * 2017-11-09 2023-02-14 Minuteman Capital Llc Transparent crowd sourcing for projects
US10713722B2 (en) * 2018-02-14 2020-07-14 Equity Shift, Inc. Blockchain instrument for transferable equity
JP2019191744A (ja) * 2018-04-20 2019-10-31 株式会社ウインライト 活動資金のための出資公募システム
US20220005023A1 (en) * 2018-05-23 2022-01-06 Visa International Service Association Programmable Transactions
CN108846747A (zh) * 2018-05-24 2018-11-20 阿里巴巴集团控股有限公司 一种基于区块链的虚拟资源交付、众筹方法及装置
US11763335B2 (en) * 2018-08-27 2023-09-19 Gemini Ip, Llc Real-time distribution of cryptocurrency rewards for a loyalty program
KR102201468B1 (ko) * 2018-09-17 2021-01-12 엔에이치엔 주식회사 블록체인 기반의 게임 제작을 위한 크라우드펀딩 시스템의 동작 방법 및 서비스 환경을 구현하기 위한 시스템
KR102112288B1 (ko) * 2018-10-23 2020-06-10 박기업 블록체인 기반의 콘텐츠 공유창작 서버, 콘텐츠 배급서버 및 이를 포함하는 시스템

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9830651B1 (en) * 2014-01-29 2017-11-28 Square, Inc. Crowdfunding framework
JP2018538639A (ja) * 2015-10-09 2018-12-27 シェ、ウェー 統一されたコード発行に基づく情報処理ネットワーク及び方法並びにセンシングアクセス装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WATANABE, ATSUSHI: "Blockchain application for the first time, 1st edition", SHOEISHA CO., LTD., 3 August 2017 (2017-08-03), pages 138 - 159 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (fr) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ Procédé de commande, serveur et programme

Also Published As

Publication number Publication date
JPWO2020162574A1 (ja) 2021-12-16
CN113424217A (zh) 2021-09-21
US20210350365A1 (en) 2021-11-11

Similar Documents

Publication Publication Date Title
JP7385706B2 (ja) ブロックチェーンに登録されたデジタルアセットを分配する方法及び自律計算エージェント
US11785079B2 (en) Free storage protocol for blockchain platform
CN109155036B (zh) 用于经由区块链控制资产有关的动作的系统及方法
Baird et al. Hedera: A governing council & public hashgraph network
Wijaya et al. A new blockchain-based value-added tax system
CN109325747B (zh) 基于区块链的汇款方法及装置
CN111899012B (zh) 基于区块链的汇款方法及装置
JP2020108044A (ja) トークン管理システムおよびトークン管理方法
KR20210050527A (ko) 투자자의 스마트 계약 기반 글로벌 레지스트리를 컨설팅하는 스마트 계약 기반 준수 규칙을 구현하는 자체 규제 증권형 토큰
WO2020019798A1 (fr) Procédé et dispositif de distribution de droits et d'intérêts, et dispositif électronique
CN118037290A (zh) 区块链实现的系统和方法
CN107924389A (zh) 对分布式交易数据库的安全溯源的系统和方法
Hwang et al. InfiniteChain: A multi-chain architecture with distributed auditing of sidechains for public blockchains
CN112819466A (zh) 数字通证的处理方法、装置、终端设备及存储介质
KR102302351B1 (ko) 각각이 신원 원장과 디지털 통화 원장을 포함하는 뱅크 노드들을 포함하는 블록체인 시스템과 이의 작동 방법
Nair et al. Blockchain technology for next-generation society: current trends and future opportunities for smart era
Banach Blockchain applications beyond the cryptocurrency casino: The Punishment not Reward blockchain architecture
WO2020162574A1 (fr) Procédé de commande, structure de données, serveur et programme
Sharma et al. Applicability of blockchain technology in healthcare industry: applications, challenges, and solutions
WO2020162573A1 (fr) Procédé de commande, serveur, programme, et structure de données
Han et al. A secure E-coupon service based on blockchain systems
Yuan et al. A tamper-resistant timed secure data transmission protocol based on smart contract
KR102648589B1 (ko) 분산원장 기반의 CBDC(Central Bank Digital Currency)를 관리하는 방법 및 이를 이용한 블록체인 노드
TW202107355A (zh) 基於區塊鏈的狀態機維護方法及裝置
Chen A novel architecture to make anonymous blind signature-based e-coins more efficient and applicable

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020571276

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20752642

Country of ref document: EP

Kind code of ref document: A1