WO2020162574A1 - 制御方法、データ構造、サーバ、および、プログラム - Google Patents

制御方法、データ構造、サーバ、および、プログラム 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
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/JP2020/004679
Other languages
English (en)
French (fr)
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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN202080011810.0A priority Critical patent/CN113424217A/zh
Priority to JP2020571276A priority patent/JP7524081B2/ja
Publication of WO2020162574A1 publication Critical patent/WO2020162574A1/ja
Priority to US17/385,131 priority patent/US12229757B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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/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 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/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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/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 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
    • 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 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
    • 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 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
    • 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

サービスの申し込みに関する第一トランザクションデータを受信し、受信した第一トランザクションデータを複数のサーバそれぞれが備える分散台帳に格納し（Ｓ４０１）、サービスは、サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、目標条件が満たされたと判定した場合には、サービスについて予め定められたトークンをユーザに提供することを示す第二トランザクションデータを分散台帳に格納し（Ｓ４０４）、第一トランザクションデータを分散台帳に格納してから、目標条件が満たされたか否かを判定（Ｓ４０３）するまでの期間に含まれる所定のタイミングにおいて、サービスについて予め定められた仮のトークンであるデポジットをユーザに提供することを示す第三トランザクションデータを分散台帳に格納する（Ｓ４０２）。

Description

制御方法、データ構造、サーバ、および、プログラム
　本発明は、制御方法、データ構造、サーバ、および、プログラムに関する。
　所定の条件を達成した者に対して、その対価として仮想通貨のような価値情報を提供するシステムがある（特許文献１参照）。
特開２０１８－１３６７２９号公報
　しかしながら、所定の条件が達成される前の時点では、ユーザに価値情報を与えることがなく、システムの稼働効率が良くないという問題がある。言い換えれば、システムは、所定の条件が達成されるまでの期間にも電力を消費しているが、その期間においてユーザに価値情報を与える処理をしていないので、電力消費効率が低いという問題がある。
　そこで、本発明は、システムの電力消費効率を改善し得る制御方法などを提供する。
　本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記サービスは、前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本発明の制御方法は、システムの電力消費効率を改善することができる。
図１は、実施の形態１におけるシステムの構成を模式的に示すブロック図である。 図２は、実施の形態１におけるサーバの構成を模式的に示すブロック図である。 図３は、実施の形態１におけるデポジット発行トランザクションデータを模式的に示す説明図である。 図４は、実施の形態１におけるデポジット提供トランザクションデータを模式的に示す説明図である。 図５は、実施の形態１におけるデポジット無効化トランザクションデータを模式的に示す説明図である。 図６は、実施の形態１におけるトークン提供トランザクションデータを模式的に示す説明図である。 図７は、実施の形態１におけるサーバの処理の第一例を示すフロー図である。 図８は、実施の形態１におけるサーバの処理の第二例を示すフロー図である。 図９は、図７に対応するシステム全体の処理を示すシーケンス図である。 図１０は、各実施の形態の変形例１におけるシステムの構成を模式的に示すブロック図である。 図１１は、各実施の形態の変形例２におけるシステムの構成を模式的に示すブロック図である。 図１２は、各実施の形態の変形例３におけるサーバの処理を示すフロー図である。 図１３は、各実施の形態の変形例３におけるサーバの構成を模式的に示すブロック図である。 図１４は、ブロックチェーンのデータ構造を示す説明図である。 図１５は、トランザクションデータのデータ構造を示す説明図である。
　（本発明の基礎となった知見）
　本発明者は、「背景技術」の欄において記載したシステムに関する技術に関し、以下の問題が生じることを見出した。
　従来、所定の条件を達成した場合に、仮想通貨のような価値情報を提供するシステムがある。そのシステムの一例は、クラウドファンディングである。
　クラウドファンディングは、例えば、インターネット上において、複数の申込者から金銭を集め、その金銭を用いて投資等により得た金銭リターンを申込者に提供する仕組みである。
　しかしながら、上記システムは、所定の条件が達成される前の時点では、ユーザに価値情報を与えることがなく、システムの稼働効率が良くないという問題がある。言い換えれば、上記システムは、所定の条件が達成されるまでの期間にも電力を消費しているが、その期間においてユーザに価値情報を与える処理をしていないので、電力消費効率が低いという問題がある。
　そこで、本発明は、システムの電力消費効率を改善し得る制御方法などを提供する。
　このような問題を解決するために、本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記サービスは、前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する。
　上記態様によれば、システムは、目標条件が達成されるまでの期間に、将来に提供する価値情報であるトークンに相当する仮のトークンであるデポジットをユーザに提供する。デポジットは、トークンと同じように、または、トークンに準ずるように使用されるように分散台帳によって管理され得る。よって、システムは、目標条件が達成されるまでの期間にユーザに価値情報を与える処理をすることで電力消費効率が改善し得る。よって、本発明に係る制御方法は、システムの電力消費効率を改善し得る。
　また、分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、システムにより管理されているデポジットの提供に関する管理情報が適切に管理される。仮に、上記管理情報が改ざんされると、デポジットおよびトークンといった価値情報の流通が不適切になる。本発明の一態様に係る制御方法によれば、管理情報が分散台帳に格納され、改ざんが実質的に不可能となるので、デポジットおよびトークンといった価値情報の流通を適切に管理できる効果もある。
　例えば、前記第三トランザクションデータを前記分散台帳に格納した後に、前記デポジットの保有者から、前記デポジットの提供先である被提供者に、前記デポジットを提供することを示すトランザクションデータである第四トランザクションデータを前記分散台帳に格納してもよい。
　上記態様によれば、システムは、さらに、デポジットを被提供者に提供する処理により、申込者に提供した価値情報をユーザ間で流通させることができる。システムは、このように価値情報を流通させる処理をするので、電力消費効率がより一層改善し得る。よって、本発明に係る制御方法は、システムの電力消費効率をより一層改善し得る。
　例えば、前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされたと判定した場合、または、前記目標条件が満たされないと判定した場合には、前記デポジットを無効化するトランザクションデータである第五トランザクションデータを前記分散台帳に格納してもよい。
　上記態様によれば、システムは、目標条件が達成されない場合にデポジットを無効化する処理をするので、デポジットの有効性の制御を適切に行うことができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　例えば、前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされたと判定した場合には、前記デポジットを保有している保有者に、前記デポジットに対応するトークンを提供するトランザクションデータである第六トランザクションデータを分散台帳に格納してもよい。
　上記態様によれば、システムは、目標条件が達成された場合に、デポジットに対応するトークンを提供する処理をするので、目標条件を達成した後にデポジットをトークンに置き換えるように管理することができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理をしながら、システムの電力消費効率をより一層改善し得る。
　例えば、前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされたと判定した場合には、前記デポジットを保有している保有者に通知してもよい。
　上記態様によれば、システムは、目標条件が達成された場合に通知をすることにより、目標条件を達成した後にデポジットをトークンに置き換える行動（つまり両替）を促すことができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　例えば、前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされないと判定した場合には、前記デポジットの保有者が前記申込者でないときには、前記デポジットに相当するトークンを前記申込者から前記保有者に提供するトランザクションデータである第七トランザクションデータを前記分散台帳に格納してもよい。
　上記態様によれば、システムは、目標条件が達成された場合に、申込者ではない保有者が保有しているデポジットを置き換えるトークンが、申込者から提供されたように管理する。仮に、保有者が保有しているデポジットが単に消滅してしまうことになれば、価値情報の流通が不適切になる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　例えば、前記第四トランザクションデータを前記分散台帳に格納する際には、前記デポジットが予め定められた回数を超えて提供されることになる場合には、前記第四トランザクションデータを前記分散台帳に格納することを制限してもよい。
　上記態様によれば、システムは、デポジットが所定回数を超えて提供されないように管理することができる。デポジットは、目標条件が満たされるまでの期間に限定してトークンとして利用されるものであることに鑑み、提供できる範囲を制限するためである。よって、本発明に係る制御方法は、価値情報の流通を一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　例えば、前記第三トランザクションデータを分散台帳に格納する処理は、前記第一トランザクションデータを前記分散台帳に格納したときに実行されるスマートコントラクトによりなされてもよい。
　上記態様によれば、システムは、デポジットの提供の処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、早期かつ安全な処理をしながら、システムの電力消費効率を改善し得る。
　例えば、前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納してもよい。
　上記態様によれば、システムは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、本発明に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、システムの電力消費効率をより一層改善し得る。
　また、本発明の一態様に係るデータ構造は、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて用いられるデータ構造であって、前記サービスについて予め定められた仮のトークンであるデポジットを一意に特定し得る識別情報と、前記デポジットが提供される提供先を一意に特定し得る識別情報と、前記デポジットの量を示す情報と、前記デポジットの発行者の電子署名とを含む。
　上記態様により、上記サービス管理システムと同様の効果を奏する。
　また、本発明の一態様に係るサーバは、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバであって、処理部と、制御部とを備え、前記処理部は、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記サービスは、前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、前記制御部は、前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する。
　上記態様により、上記制御方法と同様の効果を奏する。
　また、本発明の一態様に係るプログラムは、上記の制御方法をコンピュータに実行させるためのプログラムである。
　上記態様により、上記制御方法と同様の効果を奏する。
　また、本発明の一態様に係るデータ構造は、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、前記分散台帳に記録されるデータ構造であって、前記データ構造は、前記サービスについて予め定められた期限までの間のみ有効であって、前記サービスの申込者に対して付与される仮のトークンであるデポジットを示す第１ＩＤと、前記デポジットの額と、前記デポジットの使用条件と、前記申込者を示す第２ＩＤと、を含み、前記分散台帳に記録された後に、前記申込者に対して前記デポジットを付与する処理に用いられる。
　上記態様により、上記サービス管理システムと同様の効果を奏する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態について、図面を参照しながら具体的に説明する。
　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
　（実施の形態１）
　本実施の形態において、システムの電力消費効率を改善し得るシステムおよびその制御方法などについて説明する。
　本システムは、申込者にサービスを提供するシステムである。サービスとは、当該サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対して価値情報を提供するサービスである。ここでは、価値情報の一例としてトークンを用いて説明する。サービスの一例は、クラウドファンディングであり、この場合を例として説明するが、サービスは、預金、保険または投資などの金融商品などであってもよい。
　クラウドファンディングでは、ファンドにおける資金調達の単位をプロジェクトともいう。プロジェクトは、複数の申込者から金銭を集め、その金銭を用いて投資等により得た金銭リターンを申込者に提供するプロジェクトであることが想定される。プロジェクトについて、当該プロジェクトを管理する者を管理者といい、資金提供を申し込む者を申込者という。管理者は、資金提供の募集、および、価値情報の管理をする。プロジェクトは、当該プロジェクトについて定められた募集期間中に、定められた目標額の資金提供の申し込みを受けることができた場合に、「成立する」と表現される。
　図１は、本実施の形態におけるシステム１の構成を模式的に示すブロック図である。
　図１に示されるように、システム１は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、５０および５１とを備える。システム１が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいう。
　サーバ１０Ａは、システム１によって行われるクラウドファンディングを管理する複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、クラウドファンディングにおける手続または処理に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、クラウドファンディングにおけるデポジットおよびトークンに関する手続または処理を受け付ける。
　なお、プロジェクトにおける資金提供は、一例として、分散台帳により、トークンの提供として管理される。トークンは、分散台帳により管理されている価値情報であり、金銭、商品券またはクーポン等に相当し、または、金銭、商品券またはクーポン等に交換可能である。
　また、デポジットとは、目標条件が満たされたことに基づいてトークン（真のトークンともいう）が提供されるまでの間にトークンとして利用され得る仮のトークンを意味する。つまり、デポジットは、発行されてから、トークンが提供されるまでの間に有効であり、トークンが提供された後には無効であるように管理される。デポジットは、システム１からユーザに一時的に預ける価値情報であるといえる。
　サーバ１０Ｂ及び１０Ｃは、それぞれ、サーバ１０Ａと同じ機能を有する装置であり、サーバ１０Ａとは独立に動作する。なお、サーバの台数は、３に限られず、複数であればよい。また、サーバ１０Ａ等同士は、通信可能に接続されており、ネットワークＮを介して接続されていてもよい。
　ここでは例として、サーバ１０Ａ等のうち、サーバ１０Ａが端末４０等からトランザクションデータを受信したり、端末４０等に通知を送信したりする場合を説明するが、他のサーバ（サーバ１０Ｂまたは１０Ｃ）が上記の処理を行ってもよい。
　端末４０は、管理者が保有する端末装置である。管理者は、プロジェクトの募集期間および目標額を決定し、端末４０によりシステム１に登録する。これにより管理者は、申込者による資金提供の申し込みの合計額が目標額に達するように、申込者による資金提供を募集する。端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
　端末５０は、申込者が保有する端末装置である。申込者は、端末５０を用いて、資金提供の募集に関する情報を参照し、資金提供の申し込みをする。申込者は、プロジェクトが成立する前にデポジットを提供される。提供されたデポジットは、申込者から他の者に提供されることもある。デポジットを保有している者（保有者）は、プロジェクトが成立するとトークンを提供される。なお、申し込みの際に申込者から管理者に資金が提供されてもよい。
　端末５１は、ファンドの申込者であって、端末５０を保有する申込者とは異なる申込者が保有する端末装置である。端末５１は、端末５０と同じ機能を有する装置であり、端末５０とは独立に動作する。なお、申込者が保有する端末の台数は、２に限られず、申込者の人数と同じ数だけ存在する。
　以降において、システム１が備えるサーバ１０Ａ等の構成について詳細に説明する。
　図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。
　図２に示されるように、サーバ１０Ａは、処理部１１と、台帳管理部１２と、制御部１３とを備える。サーバ１０Ａが備える上記機能部は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）がメモリを用いてプログラムを実行することで実現され得る。
　処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、システム１内の装置からトランザクションデータを受信した場合、又は、制御部１３が生成したトランザクションデータを取得した場合に、受信又は取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、デポジット発行トランザクションデータ、デポジット提供トランザクションデータ、デポジット無効化トランザクションデータおよびトークン提供トランザクションデータが含まれる。各トランザクションデータについては後で詳しく説明する。
　台帳管理部１２は、分散台帳を管理している処理部である。台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記トランザクションデータが改ざんされないように管理されている。
　台帳管理部１２は、格納部１５と、台帳記憶部１６とを有する。
　格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、分散台帳の種別に応じた方式で新しいトランザクションデータを台帳記憶部１６に格納する。また、格納部１５は、サーバ１０Ａ等のうちの他のサーバの格納部１５と通信データを送受信し、他のサーバの台帳記憶部１６にも上記新しいトランザクションデータを格納させる。例えば、格納部１５は、分散台帳がブロックチェーンである場合には、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとったうえで、上記ブロックを台帳記憶部１６に格納する。
　台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータを記憶しており、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている（後述）。
　なお、分散台帳は、例えばブロックチェーンであり、この場合を例として説明するが、他の方式の分散台帳（例えば、ＩＯＴＡ又はハッシュグラフ等）を採用することも可能である。なお、分散台帳は、新しいデータの格納の際にコンセンサスアルゴリズム（例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）、ＰｏＷ（Ｐｒｏｏｆ　ｏｆ　Ｗｏｒｋ）又はＰｏＳ（Ｐｒｏｏｆ　ｏｆ　Ｓｔａｋｅ））を実行するものであってもよいし、実行しないものであってもよい。コンセンサスアルゴリズムを実行しない分散台帳技術の一例としてＨｙｐｅｒｌｅｄｇｅｒ　ｆａｂｒｉｃがある。
　制御部１３は、クラウドファンディングのプロジェクトの目標条件が達成されたか否かを判定するとともに、デポジットおよびトークンの制御をする処理部である。
　制御部１３は、クラウドファンディングの目標条件を端末４０から受信する。また、制御部１３は、端末５０及び５１から資金提供の申し込みを受ける。制御部１３は、クラウドファンディングの目標条件が満たされるか否かを判定する。
　制御部１３は、目標条件が満たされたと判定した場合には、サービスについて予め定められたトークンを申込者に提供することを示すトランザクションデータであるトークン提供トランザクションデータ（第二トランザクションデータに相当）を分散台帳に格納する。
　また、制御部１３は、デポジットの制御として、デポジットの提供および有効性を制御する。具体的には、制御部１３は、申込トランザクションデータを分散台帳に格納してから、目標条件が満たされたか否かを判定する前の所定のタイミングにおいて、サービスについて予め定められたデポジットを申込者に提供する。デポジットを申込者に提供する際には、デポジットを提供することを示すトランザクションデータであるデポジット発行トランザクションデータ（第三トランザクションデータに相当）を分散台帳に格納する。所定のタイミングは、デポジットを申込者に提供するための条件（デポジット発行条件ともいう）が満たされたと判定したタイミングとすることができる。つまり、デポジットを申込者に提供する際には、あらかじめデポジット発行条件が満たされたか否かを制御部１３が判定し、満たされたと判定した場合にデポジットを申込者に提供するようにしてもよい。なお、デポジットをシステム１から申込者に提供することを「発行」ともいう。
　デポジット発行条件は、例えば、所定数の申込トランザクションデータを受信したこと、または、受信した申込トランザクションデータの個数の増加速度が所定速度を超えたこと、とすることができる。これらの場合、目標条件が満たされると判定される蓋然性が比較的高いからである。
　また、制御部１３は、デポジットの提供の制御として、ユーザから別のユーザへのデポジットの提供を制御することもできる。つまり、制御部１３は、デポジット発行トランザクションデータを分散台帳に格納した後に、デポジットの保有者から、デポジットの提供先である被提供者に、デポジットを提供することを示すトランザクションデータであるデポジット提供トランザクションデータ（第四トランザクションデータに相当）を分散台帳に格納する。
　また、デポジットの有効性の制御とは、デポジットを有効なものとして扱うか、または、無効なものとして扱うかを制御することである。デポジット発行トランザクションデータが分散台帳に格納されたすぐ後には、発行されたデポジットは有効なものとして管理される。そして、目標条件が満たされることによりそのデポジットに対応するトークンが提供されるトークン提供トランザクションデータが分散台帳に格納されるときに、デポジットが無効になるように管理される。
　すなわち、制御部１３は、目標条件が満たされたと判定した場合、または、目標条件が満たされないと判定した場合に、デポジットを無効化する。デポジットの無効化の際には、デポジットを無効化することを示すトランザクションデータであるデポジット無効化トランザクションデータ（第五トランザクションデータに相当）を分散台帳に格納する。
　また、制御部１３は、デポジットを提供した後に目標条件が満たされた場合には、デポジットが真のトークンに置き換えられるように管理する。すなわち、制御部１３は、デポジット発行トランザクションデータを分散台帳に格納した後に、目標条件が満たされたと判定した場合には、デポジットを保有している保有者に、デポジットに相当するトークンを提供するトランザクションデータであるトークン提供トランザクションデータ（第六トランザクションデータ）を分散台帳に格納する。
　なお、制御部１３は、デポジットを提供した後に目標条件が満たされた場合には、デポジットの保有者に対して、通知（より具体的にはデポジットを真のトークンに両替する手続きをすることを促すための通知）をしてもよい。すなわち、制御部１３は、デポジット発行トランザクションデータを分散台帳に格納した後に、目標条件が満たされたと判定した場合には、デポジットを保有している保有者に通知してもよい。
　また、制御部１３は、デポジットを提供した後、申込者とは別のユーザ（保有者ともいう）にデポジットが提供された後に目標条件が満たされない場合には、保有者のデポジットを真のトークンに置き換えられるように管理するとともに、保有者のデポジットに相当するトークンを申込者から徴収するように管理してもよい。つまり、保有者のデポジットに相当するトークンを申込者から保有者に提供するように管理してもよい。すなわち、制御部１３は、デポジット発行トランザクションデータを分散台帳に格納した後に、目標条件が満たされないと判定した場合には、デポジットの保有者が申込者でないときには、デポジットに相当するトークンを申込者から保有者に提供するトランザクションデータであるトークン提供トランザクションデータ（第七トランザクションデータに相当）を分散台帳に格納する。
　なお、制御部１３は、デポジットの提供の回数を制限してもよい。すなわち、制御部１３は、デポジット提供トランザクションデータを分散台帳に格納する際には、デポジットが予め定められた回数を超えて提供されることになる場合には、デポジット提供トランザクションデータを分散台帳に格納することを制限してもよい。
　なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされ得るが、これに限定されない。例えば、デポジットの提供処理は、第一トランザクションデータを分散台帳に格納したことに基づいて実行されるスマートコントラクトによりなされてもよい。
　以降において、各種トランザクションデータについて説明する。
　図３は、本実施の形態におけるデポジット発行トランザクションデータの第一例を模式的に示す説明図である。図３に示されるデポジット発行トランザクションデータは、デポジットの発行の際にサーバ１０Ａ等により生成される。
　図３に示されるデポジット発行トランザクションデータは、デポジットＩＤと、提供先ＩＤと、デポジット額と、発行日時と、残使用回数と、署名とを含む。
　デポジットＩＤは、当該デポジット発行トランザクションデータにより発行されるデポジットを一意に特定し得る識別子である。
　提供先ＩＤは、当該デポジット発行トランザクションデータにより発行されるデポジットの提供先であるユーザを一意に特定し得る識別子である。
　デポジット額は、当該デポジット発行トランザクションデータにより発行されるデポジットの額（またはデポジットの量）を示す情報である。
　発行日時は、当該デポジット発行トランザクションデータによりデポジットが発行される日時を示す情報である。
　残使用回数は、当該デポジット発行トランザクションデータにより発行されるデポジットが使用され得る回数を示す情報である。ここでの「使用」とは、例えばデポジットの提供を意味しており、その場合、残使用回数は、当該デポジットが提供され得る回数を示している。なお、残使用回数は、発行又は提供されるデポジットに付される条件を示す制限情報の一例である。制限情報には、残使用回数の他に、例えば、当該デポジット提供トランザクションデータにより提供されたデポジットのうち、さらに提供されるデポジットの割合を示す情報が含まれ得る。
　署名は、当該デポジット発行トランザクションデータを生成した装置又は人が付した電子署名である。
　図３に示されるデポジット発行トランザクションデータは、デポジットＩＤが「６７ｇ４」であるデポジットを、ユーザａｐａに発行するためのトランザクションデータである。発行されるデポジットは、デポジットの額が「１」であり、発行日時が「２０１８．１０．０５　１０：００：３０」であり、残使用回数が「３回」である。署名は、サーバ１０Ａ等の電子署名である。なお、ユーザＩＤが「Ａ」であるユーザを「ユーザＡ」と表記した。以降でも同様とする。
　なお、図３に示されるデポジット発行トランザクションデータは、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて用いられるデータ構造であって、サービスについて予め定められた仮のトークンであるデポジットを一意に特定し得る識別情報と、デポジットが提供される提供先を一意に特定し得る識別情報と、デポジットの量を示す情報と、デポジットの発行者の電子署名とを含むデータ構造であるともいえる。
　また、図３に示されるデポジット発行トランザクションデータは、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、分散台帳に記録されるデータ構造であって、サービスについて予め定められた期限までの間のみ有効であって、サービスの申込者に対して付与される仮のトークンであるデポジットを示す第１ＩＤと、デポジットの額と、デポジットの使用条件と、申込者を示す第２ＩＤと、を含み、分散台帳に記録された後に、申込者に対してデポジットを付与する処理に用いられるデータ構造であるともいえる。
　図４は、本実施の形態におけるデポジット提供トランザクションデータを模式的に示す説明図である。図４に示されるデポジット提供トランザクションデータは、デポジットの提供の際にサーバ１０Ａ等により生成される。
　図４に示されるデポジット提供トランザクションデータは、デポジットＩＤと、提供元ＩＤと、提供先ＩＤと、デポジット額と、提供日時と、残使用回数と、署名とを含む。
　デポジットＩＤは、当該デポジット提供トランザクションデータにより提供されるデポジットを一意に特定し得る識別子である。
　提供元ＩＤは、当該デポジット提供トランザクションデータにより提供されるデポジットの提供元であるユーザを一意に特定し得る識別子である。
　提供先ＩＤは、当該デポジット提供トランザクションデータにより提供されるデポジットの提供先であるユーザを一意に特定し得る識別子である。
　デポジット額は、当該デポジット提供トランザクションデータにより提供されるデポジットの額（またはデポジットの量）を示す情報である。
　提供日時は、当該デポジット提供トランザクションデータによりデポジットが提供される日時を示す情報である。
　残使用回数は、当該デポジット提供トランザクションデータにより提供されるデポジットが使用され得る回数を示す情報である。残使用回数は、提供されるデポジットに付される条件を示す制限情報の一例である。制限情報には、例えば、当該デポジット提供トランザクションデータにより提供された後に、さらに提供され得る割合を示す情報が含まれ得る。
　署名は、当該デポジット提供トランザクションデータを生成した装置又は人が付した電子署名である。
　図４に示されるデポジット提供トランザクションデータは、デポジットＩＤが「６７ｇ４」であるデポジットを、ユーザａｐａからユーザａｐｂに提供するためのトランザクションデータである。提供されるデポジットは、デポジットの額が「１」であり、提供日時が「２０１８．１０．１４　１５：００：００」であり、残使用回数が「２回」である。署名は、提供元「ａｐａ」の電子署名である。
　図５は、本実施の形態におけるデポジット無効化トランザクションデータを模式的に示す説明図である。図５に示されるデポジット無効化トランザクションデータは、デポジットの無効化の際にサーバ１０Ａ等により生成される。
　図５に示されるデポジット無効化トランザクションデータは、デポジットＩＤと、無効化日時と、署名とを含む。
　デポジットＩＤは、当該デポジット無効化トランザクションデータにより無効化されるデポジットを一意に特定し得る識別子である。
　無効化日時は、当該デポジット無効化トランザクションデータによりデポジットが無効化される日時を示す情報である。
　署名は、当該デポジット無効化トランザクションデータを生成した装置又は人が付した電子署名である。
　図５に示されるデポジット無効化トランザクションデータは、デポジットＩＤが「６７ｇ４」であるデポジットを無効化するためのトランザクションデータである。デポジットが無効化される日時は「２０１８．１０．３０　０５：００：００」である。署名は、サーバ１０Ａ等の電子署名である。
　図６は、本実施の形態におけるトークン提供トランザクションデータを模式的に示す説明図である。図６に示されるトークン提供トランザクションデータは、トークンの提供の際にサーバ１０Ａ等により生成される。
　図６に示されるトークン提供トランザクションデータは、トークンＩＤと、提供元ＩＤと、提供先ＩＤと、トークン額と、提供日時と、署名とを含む。
　トークンＩＤは、当該トークン提供トランザクションデータにより提供されるトークンを一意に特定し得る識別子である。
　提供元ＩＤは、当該トークン提供トランザクションデータにより提供されるトークンの提供元であるユーザを一意に特定し得る識別子である。
　提供先ＩＤは、当該トークン提供トランザクションデータにより提供されるトークンの提供先であるユーザを一意に特定し得る識別子である。
　トークン額は、当該トークン提供トランザクションデータにより提供されるトークンの額（またはトークンの量）を示す情報である。
　提供日時は、当該トークン提供トランザクションデータによりトークンが提供される日時を示す情報である。
　署名は、当該トークン提供トランザクションデータを生成した装置又は人が付した電子署名である。
　図６に示されるトークン提供トランザクションデータは、トークンＩＤが「１００６７ｇ４」であるトークンを、ユーザａｐａからユーザｕｓｘに提供するためのトランザクションデータである。提供されるトークンは、トークン額が「１」であり、提供日時が「２０１８．１０．３０　０５：００：００」である。署名は、サーバ１０Ａ等の電子署名である。
　以上のように構成されたシステム１およびサーバ１０Ａ等の処理を説明する。
　図７は、本実施の形態におけるサーバ１０Ａ等の処理の第一例を示すフロー図である。図７に示されるフロー図の開始の時点で、制御部１３は、既に目標条件を管理者Ｕ１の端末４０から取得済みであるとする。
　図７に示されるように、ステップＳ１０１において、処理部１１は、申込者Ｕ２の端末５０から申込トランザクションデータを受信したか否かを判定する。申込トランザクションデータを受信した場合（ステップＳ１０１でＹｅｓ）には、ステップＳ１０２に進み、そうでない場合（ステップＳ１０１でＮｏ）には、ステップＳ１０３に進む。
　ステップＳ１０２において、処理部１１は、ステップＳ１０１で受信した申込トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記申込トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１０３において、制御部１３は、デポジット発行条件が満たされたか否かを判定する。デポジット発行条件が満たされたと判定した場合（ステップＳ１０３でＹｅｓ）には、ステップＳ１０４に進み、そうでない場合（ステップＳ１０３でＮｏ）には、ステップＳ１０６に進む。
　ステップＳ１０４において、制御部１３は、デポジットを発行するデポジット提供トランザクションデータを生成する。
　ステップＳ１０５において、制御部１３は、ステップＳ１０４で生成したデポジット提供トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記デポジット提供トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。このあと、提供されたデポジットは、他のユーザに提供されることができる。デポジットが他のユーザに提供される処理は後述する。
　ステップＳ１０６において、制御部１３は、募集期間が終了したか否かを判定する。募集期間が終了したか否かは、予め定められている募集期限が到来しているか否かにより判定される。募集期間が終了したと判定した場合（ステップＳ１０６でＹｅｓ）には、ステップＳ１０７に進み、そうでない場合（ステップＳ１０６でＮｏ）には、ステップＳ１０１に進む。
　ステップＳ１０７において、制御部１３は、募集期間が終了したことを申込者Ｕ３等つまり端末５０等に通知する。なお、ステップＳ１０７は、実行されなくてもよい。
　ステップＳ１０８において、制御部１３は、クラウドファンディングのプロジェクトの目標条件が満たされたか否かを判定する。目標条件が満たされたと判定された場合（ステップＳ１０８でＹｅｓ）には、ステップＳ１０９に進み、そうでない場合（ステップＳ１０８でＮｏ）には、ステップＳ１２１に進む。
　ステップＳ１０９において、制御部１３は、目標条件が達成したことを申込者Ｕ３等つまり端末５０等に通知する。なお、ステップＳ１０９は、実行されなくてもよい。
　ステップＳ１１０において、制御部１３は、デポジットを無効化する無効化トランザクションデータを生成する。
　ステップＳ１１１において、制御部１３は、ステップＳ１１０で生成した無効化トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記無効化トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１１２において、制御部１３は、管理者からデポジットの保有者へトークンを提供するトークン提供トランザクションデータを生成する。生成されるトークン提供トランザクションデータにおいて、提供されるトークンの額は、保有者が保有しているデポジットの額に相当する額である。
　ステップＳ１１３において、制御部１３は、ステップＳ１１２で生成したトークン提供トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記トークン提供トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１２１において、制御部１３は、目標条件が達成されなかったことを申込者Ｕ３等つまり端末５０等に通知する。なお、ステップＳ１２１は、実行されなくてもよい。
　ステップＳ１２２において、制御部１３は、デポジットを無効化する無効化トランザクションデータを生成する。
　ステップＳ１２３において、制御部１３は、ステップＳ１２２で生成した無効化トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記無効化トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１２４において、制御部１３は、申込者から被提供者へトークンを提供するトークン提供トランザクションデータを生成する。生成されるトークン提供トランザクションデータにおいて、提供されるトークンの額は、被提供者が保有しているデポジットの額に相当する額である。
　ステップＳ１２５において、制御部１３は、ステップＳ１２４で生成したトークン提供トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記トークン提供トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１１３又はＳ１２５のあと、図７に示される一連の処理を終了する。
　図８は、本実施の形態におけるサーバ１０Ａの処理の第二例を示すフロー図である。
　図８に示される処理は、デポジットが発行された（図７のステップＳ１０５）後、そのデポジットが無効化される（図７のステップＳ１１１又はＳ１２３）までの期間に、図７に示される処理と並行して実行される処理である。
　ステップＳ２０１において、処理部１１は、申込者Ｕ２の端末５０等からデポジット提供トランザクションデータを受信したか否かを判定する。デポジット提供トランザクションデータを受信した場合（ステップＳ２０１でＹｅｓ）には、ステップＳ２０２に進み、そうでない場合（ステップＳ２０１でＮｏ）には、ステップＳ２０１を再び実行する。つまり処理部１１は、デポジット提供トランザクションデータを受信するまでステップＳ２０１で待機する。
　ステップＳ２０２において、制御部１３は、ステップＳ２０１で受信したデポジット提供トランザクションデータに含まれる残使用回数を参照し、残使用回数が１以上であるか否かを判定する。残使用回数が１以上であると判定した場合（ステップＳ２０２でＹｅｓ）には、ステップＳ２０３に進み、そうでない場合（ステップＳ２０２でＮｏ）には、ステップＳ２１１に進む。
　ステップＳ２０３において、処理部１１は、ステップＳ２０１で受信したデポジット提供トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記デポジット提供トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ２０４において、制御部１３は、ステップＳ２０１で受信したデポジット提供トランザクションデータにかかるデポジットの残使用回数を１減算する。ステップＳ２０４の処理を終えたらステップＳ２０１に進む。
　ステップＳ２１１において、制御部１３は、使用回数が制限を超えたことを提供元に通知する。なお、このとき、使用回数が制限を超えたという事実を分散台帳に格納してもよい。ステップＳ２１１の処理を終えたらステップＳ２０１に進む。
　なお、デポジットの回数の制限を管理しない場合には、ステップＳ２０２、ステップＳ２０４およびステップＳ２１１を実行する必要はない。
　次に、システム１の全体の処理を説明する。
　図９は、図７に対応するシステム１全体の処理を示すシーケンス図である。図９には、目標条件が満たされた場合のシステム１全体の処理が示されている。なお、図７のフロー図と同じ処理を示すものは、図７と同じ符号を付し詳細な説明を省略する。
　まず、あらかじめ、管理者Ｕ１の端末４０は、目標条件を生成し、サーバ１０Ａ等に送信している（ステップＳ３０１）。目標条件は、募集期限、目標額などの情報を含む。サーバ１０Ａは、送信された目標条件を受信し、サーバ１０Ａ等の間で共有する（ステップＳ１００）。
　ステップＳ３１１において、端末５０は、申込トランザクションデータを生成してサーバ１０Ａ等に送信する。このとき、端末５１は、生成した申込トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、送信された申込トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０１及びＳ１０２）。また、サーバ１０Ａ等は、デポジット発行条件が満たされたと判定した場合に、申込トランザクションデータの送信元である端末５１に係る申込者Ｕ３にデポジットを発行するデポジット提供トランザクションデータを生成し、分散台帳に格納する（ステップＳ１０３～１０５）。また、募集期間が終了した場合には、募集期間が終了したことの通知を送信する（ステップＳ１０６及びＳ１０７）。
　そして、サーバ１０Ａ等は、目標条件が満たされた場合には、すでに発行したデポジットを無効化する無効化トランザクションデータを生成し、分散台帳に格納する（ステップＳ１１０～Ｓ１１１）。
　また、デポジットを保有している保有者にトークンを提供するトークン提供トランザクションデータを生成し、分散台帳に格納する（ステップＳ１１２～Ｓ１１３）。
　（各実施の形態の変形例１）
　本変形例において、上記各実施の形態のサービス管理システムの別の構成について説明する。
　図１０は、本変形例におけるシステム２の構成を模式的に示すブロック図である。
　図１０に示されるように、システム２は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、５０および５１とを備える。システム２が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
　特に、システム２では、サーバ１０Ａ、１０Ｂ及び１０Ｃが互いにネットワークＮを介して接続されている。また、サーバ１０Ａに端末５１が接続されており、サーバ１０Ｂに端末５０が接続されており、サーバ１０Ｃに端末４０が接続されている。
　このような構成は、例えば、複数の団体がシステム２を運営する場合において、各団体が管理するサーバをネットワークＮを介して接続する場合に利用され得る。例えば、団体Ａにサーバ１０Ａと端末５１とが所属しており、団体Ｂにサーバ１０Ｂと端末５０とが所属しており、団体Ｃにサーバ１０Ｃと端末４０とが所属している。
　サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
　（各実施の形態の変形例２）
　本変形例において、上記各実施の形態のサービス管理システムの別の構成について説明する。
　図１１は、本変形例におけるシステム３の構成を模式的に示すブロック図である。
　図１１に示されるように、システム３は、サーバ１０Ｄと、端末４０、５０および５１とを備える。システム３が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
　特に、システム３では、サーバ１０Ｄ、並びに、端末５０および５１が互いにネットワークＮを介して接続されている。また、サーバ１０Ｄに端末４０が接続されている。この場合、端末５０および５１それぞれが、上記各実施の形態におけるサーバ１０Ａ等の動作をする。
　このような構成は、例えば、１以上の団体と１以上の個人とがシステム３を運営する場合において、各団体又は各個人が管理するサーバ又は端末をネットワークＮを介して接続する場合に利用され得る。例えば、団体Ｄにサーバ１０Ｄと端末４０とが所属しており、団体Ｄと、個人である申込者Ｕ２およびＵ３とがシステム３を運営している。
　サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
　（各実施の形態の変形例３）
　図１２は、本変形例におけるサーバの処理を示すフロー図である。図１２に示されるフロー図は、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法である。
　サーバは、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した第一トランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する（ステップＳ４０１）。ここで、上記サービスは、サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスである。
　サーバは、目標条件が満たされたと判定した場合（ステップＳ４０３でＹｅｓ）には、サービスについて予め定められたトークンをユーザに提供することを示すトランザクションデータである第二トランザクションデータを分散台帳に格納する（ステップＳ４０４）。
　サーバは、第一トランザクションデータを分散台帳に格納してから、目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、サービスについて予め定められた仮のトークンであるデポジットをユーザに提供することを示すトランザクションデータである第三トランザクションデータを分散台帳に格納する（ステップＳ４０２）。
　これにより、サービス管理システムは、システムの電力消費効率を改善することができる。
　図１３は、本変形例におけるサーバの構成を模式的に示すブロック図である。
　図１３に示されるように、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバ６０Ａは、処理部６１と、制御部６３とを備える。
　処理部６１は、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納する。ここで、サービスは、サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスである。
　制御部６３は、目標条件が満たされたと判定した場合には、サービスについて予め定められたトークンをユーザに提供することを示すトランザクションデータである第二トランザクションデータを分散台帳に格納する。
　また、制御部６３は、第一トランザクションデータを分散台帳に格納してから、目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、サービスについて予め定められた仮のトークンであるデポジットをユーザに提供することを示すトランザクションデータである第三トランザクションデータを分散台帳に格納する。
　これにより、サービス管理システムは、システムの電力消費効率を改善することができる。
　（補足）
　上記各実施の形態、又は、変形例におけるブロックチェーンについて補足的に説明する。
　図１４は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。
　図１５は、トランザクションデータのデータ構造を示す説明図である。
　図１５に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。
　トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。
　以上のように、上記の実施の形態のシステムは、目標条件が達成されるまでの期間に、将来に提供する価値情報であるトークンに相当する仮のトークンであるデポジットをユーザに提供する。デポジットは、トークンと同じように、または、トークンに準ずるように使用されるように分散台帳によって管理され得る。よって、システムは、目標条件が達成されるまでの期間にユーザに価値情報を与える処理をすることで電力消費効率が改善し得る。よって、本発明に係る制御方法は、システムの電力消費効率を改善し得る。
　また、分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、システムにより管理されているデポジットの提供に関する管理情報が適切に管理される。仮に、上記管理情報が改ざんされると、デポジットおよびトークンといった価値情報の流通が不適切になる。本発明の一態様に係る制御方法によれば、管理情報が分散台帳に格納され、改ざんが実質的に不可能となるので、デポジットおよびトークンといった価値情報の流通を適切に管理できる効果もある。
　また、システムは、さらに、デポジットを被提供者に提供する処理により、申込者に提供した価値情報をユーザ間で流通させることができる。システムは、このように価値情報を流通させる処理をするので、電力消費効率がより一層改善し得る。よって、本発明に係る制御方法は、システムの電力消費効率をより一層改善し得る。
　また、システムは、目標条件が達成されない場合にデポジットを無効化する処理をするので、デポジットの有効性の制御を適切に行うことができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　また、システムは、目標条件が達成された場合に、デポジットに対応するトークンを提供する処理をするので、目標条件を達成した後にデポジットをトークンに置き換えるように管理することができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理をしながら、システムの電力消費効率をより一層改善し得る。
　また、システムは、目標条件が達成された場合に通知をすることにより、目標条件を達成した後にデポジットをトークンに置き換える行動（つまり両替）を促すことができる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　また、システムは、目標条件が達成された場合に、申込者ではない保有者が保有しているデポジットを置き換えるトークンが、申込者から提供されたように管理する。仮に、保有者が保有しているデポジットが単に消滅してしまうことになれば、価値情報の流通が不適切になる。よって、本発明に係る制御方法は、価値情報の流通をより一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　また、システムは、デポジットが所定回数を超えて提供されないように管理することができる。デポジットは、目標条件が満たされるまでの期間に限定してトークンとして利用されるものであることに鑑み、提供できる範囲を制限するためである。よって、本発明に係る制御方法は、価値情報の流通を一層適切に管理しながら、システムの電力消費効率をより一層改善し得る。
　また、システムは、デポジットの提供の処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、早期かつ安全な処理をしながら、システムの電力消費効率を改善し得る。
　また、システムは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、本発明に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、システムの電力消費効率をより一層改善し得る。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のコンテンツ管理システムなどを実現するソフトウェアは、次のようなプログラムである。
　すなわち、このプログラムは、コンピュータに、分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記サービスは、前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する制御方法を実行させるプログラムである。
　以上、一つまたは複数の態様に係るサービス管理システムなどについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
　本発明は、申込者にトークンを提供するサービスを管理するサービス管理システムに利用可能である。
　１、２、３　　システム
　１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ、６０Ａ　　サーバ
　１１、６１　　処理部
　１２　　台帳管理部
　１３、６３　　制御部
　１５　　格納部
　１６　　台帳記憶部
　４０、５０、５１　　端末
　Ｂ１、Ｂ２、Ｂ３　　ブロック
　Ｎ　　ネットワーク
　Ｐ１　　トランザクション本体
　Ｐ２　　電子署名
　Ｕ１　　管理者
　Ｕ２、Ｕ３　　申込者

Claims (13)

  1. 　分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、
    　サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、
    　前記サービスは、前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、
    　前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、
    　前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する
    　制御方法。
  2. 　前記第三トランザクションデータを前記分散台帳に格納した後に、前記デポジットの保有者から、前記デポジットの提供先である被提供者に、前記デポジットを提供することを示すトランザクションデータである第四トランザクションデータを前記分散台帳に格納する
    　請求項１に記載の制御方法。
  3. 　前記第三トランザクションデータを前記分散台帳に格納した後に、
    　前記目標条件が満たされたと判定した場合、または、前記目標条件が満たされないと判定した場合には、前記デポジットを無効化するトランザクションデータである第五トランザクションデータを前記分散台帳に格納する
    　請求項１または２に記載の制御方法。
  4. 　前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされたと判定した場合には、前記デポジットを保有している保有者に、前記デポジットに対応するトークンを提供するトランザクションデータである第六トランザクションデータを前記分散台帳に格納する
    　請求項１～３のいずれか１項に記載の制御方法。
  5. 　前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされたと判定した場合には、前記デポジットを保有している保有者に通知する
    　請求項１～３のいずれか１項に記載の制御方法。
  6. 　前記第三トランザクションデータを前記分散台帳に格納した後に、前記目標条件が満たされないと判定した場合には、前記デポジットの保有者が前記申込者でないときには、前記デポジットに相当するトークンを前記申込者から前記保有者に提供するトランザクションデータである第七トランザクションデータを前記分散台帳に格納する
    　請求項３に記載の制御方法。
  7. 　前記第四トランザクションデータを前記分散台帳に格納する際には、前記デポジットが予め定められた回数を超えて提供されることになる場合には、前記第四トランザクションデータを前記分散台帳に格納することを制限する
    　請求項２～６のいずれか１項に記載の制御方法。
  8. 　前記第三トランザクションデータを分散台帳に格納する処理は、
    　前記第一トランザクションデータを前記分散台帳に格納したときに実行されるスマートコントラクトによりなされる
    　請求項１～７のいずれか１項に記載の制御方法。
  9. 　前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納する
    　請求項１～７のいずれか１項に記載の制御方法。
  10. 　分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて用いられるデータ構造であって、
    　前記サービスについて予め定められた仮のトークンであるデポジットを一意に特定し得る識別情報と、
    　前記デポジットが提供される提供先を一意に特定し得る識別情報と、
    　前記デポジットの量を示す情報と、
    　前記デポジットの発行者の電子署名とを含む
    　データ構造。
  11. 　分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、当該複数のサーバのうちの一のサーバであって、
    　処理部と、制御部とを備え、
    　前記処理部は、サービスの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、
    　前記サービスは、
    　前記サービスについて予め定められた目標条件が満たされた場合に、当該サービスに申し込みをしたユーザである申込者に対してトークンを提供するサービスであり、
    　前記制御部は、
    　前記目標条件が満たされたと判定した場合には、前記サービスについて予め定められたトークンを前記ユーザに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納し、
    　前記第一トランザクションデータを前記分散台帳に格納してから、前記目標条件が満たされたか否かを判定するまでの期間に含まれる所定のタイミングにおいて、前記サービスについて予め定められた仮のトークンであるデポジットを前記ユーザに提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納する
    　サーバ。
  12. 　請求項１～９のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。
  13. 　分散台帳を保有している複数のサーバを備えるサービス管理システムにおいて、前記分散台帳に記録されるデータ構造であって、
    　前記データ構造は、
    　　前記サービスについて予め定められた期限までの間のみ有効であって、前記サービスの申込者に対して付与される仮のトークンであるデポジットを示す第１ＩＤと、前記デポジットの額と、前記デポジットの使用条件と、前記申込者を示す第２ＩＤと、を含み、
    　　前記分散台帳に記録された後に、前記申込者に対して前記デポジットを付与する処理に用いられる、
    　データ構造。
PCT/JP2020/004679 2019-02-08 2020-02-06 制御方法、データ構造、サーバ、および、プログラム Ceased WO2020162574A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080011810.0A CN113424217A (zh) 2019-02-08 2020-02-06 控制方法、数据结构、服务器、以及程序
JP2020571276A JP7524081B2 (ja) 2019-02-08 2020-02-06 制御方法、サービス管理システム、および、プログラム
US17/385,131 US12229757B2 (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 US12229757B2 (en) 2019-02-08 2021-07-26 Control method, data structure, server, and recording medium

Publications (1)

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

Family

ID=71947784

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/004679 Ceased WO2020162574A1 (ja) 2019-02-08 2020-02-06 制御方法、データ構造、サーバ、および、プログラム

Country Status (4)

Country Link
US (1) US12229757B2 (ja)
JP (1) JP7524081B2 (ja)
CN (1) CN113424217A (ja)
WO (1) WO2020162574A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム

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 (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6425808B2 (ja) * 2014-07-11 2018-11-21 ロイヤル コーポレイション 取引型および非取引型の商業を奨励する分散型台帳プロトコル
WO2017027484A1 (en) * 2015-08-09 2017-02-16 Ramasamy Celambarasan System and method for microshare based content funding and distribution
US20170140408A1 (en) * 2015-11-16 2017-05-18 Bank Of America Corporation Transparent self-managing rewards program using blockchain and smart contracts
WO2018140963A1 (en) * 2017-01-30 2018-08-02 Dais Technology, Inc. System for creating and utilizing smart policies on a blockchain
JP6828890B2 (ja) 2017-02-22 2021-02-10 日新ビジネス開発株式会社 仮想通貨付与システム
CN110770723A (zh) * 2017-05-18 2020-02-07 科德克斯有限公司 使用区块链优先级信息的分散式数字内容分发系统和过程
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 株式会社ウインライト 活動資金のための出資公募システム
WO2019226489A1 (en) * 2018-05-23 2019-11-28 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 엔에이치엔 주식회사 블록체인 기반의 게임 제작을 위한 크라우드펀딩 시스템의 동작 방법 및 서비스 환경을 구현하기 위한 시스템
KR20200042149A (ko) * 2018-10-15 2020-04-23 주식회사 모카테크 블록체인 기반의 기업투자 시스템 및 그 제어방법
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 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム

Also Published As

Publication number Publication date
JP7524081B2 (ja) 2024-07-29
US12229757B2 (en) 2025-02-18
CN113424217A (zh) 2021-09-21
JPWO2020162574A1 (ja) 2021-12-16
US20210350365A1 (en) 2021-11-11

Similar Documents

Publication Publication Date Title
JP7385706B2 (ja) ブロックチェーンに登録されたデジタルアセットを分配する方法及び自律計算エージェント
CN109325747B (zh) 基于区块链的汇款方法及装置
US11785079B2 (en) Free storage protocol for blockchain platform
CN109155036B (zh) 用于经由区块链控制资产有关的动作的系统及方法
Nair et al. Blockchain technology for next-generation society: current trends and future opportunities for smart era
KR102302351B1 (ko) 각각이 신원 원장과 디지털 통화 원장을 포함하는 뱅크 노드들을 포함하는 블록체인 시스템과 이의 작동 방법
WO2020019798A1 (zh) 权益分配方法及装置、电子设备
Hwang et al. InfiniteChain: A multi-chain architecture with distributed auditing of sidechains for public blockchains
US11522670B2 (en) Pyramid construct with trusted score validation
CN112819466A (zh) 数字通证的处理方法、装置、终端设备及存储介质
JP7625068B2 (ja) 仮想通貨の有効期限を可能にする電子ウォレット
Xu et al. Design process for applications on blockchain
Banach Blockchain applications beyond the cryptocurrency casino: The Punishment not Reward blockchain architecture
Han et al. A secure E-coupon service based on blockchain systems
CN113439285A (zh) 控制方法、服务器、程序、以及数据结构
Davelis et al. Emerging technologies: blockchain and smart contracts
CN110458538B (zh) 基于区块链的状态机维护方法及装置、电子设备、存储介质
Yuan et al. A tamper-resistant timed secure data transmission protocol based on smart contract
JP7524081B2 (ja) 制御方法、サービス管理システム、および、プログラム
CN111597264A (zh) 一种区块链记账方法及装置
CN116508290A (zh) 计算机实现的系统和方法
US20250307926A1 (en) Custom private ledger for multiple entities, multiple coin types
US20230179403A1 (en) Pyramid construct with trusted score validation
WO2026042324A1 (ja) 制御方法、装置、及び、プログラム
HK40039770A (en) Remittance method and device based on block chain

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