WO2020085266A1 - 制御方法、ファンド管理システム、プログラム、及び、データ構造 - Google Patents

制御方法、ファンド管理システム、プログラム、及び、データ構造 Download PDF

Info

Publication number
WO2020085266A1
WO2020085266A1 PCT/JP2019/041227 JP2019041227W WO2020085266A1 WO 2020085266 A1 WO2020085266 A1 WO 2020085266A1 JP 2019041227 W JP2019041227 W JP 2019041227W WO 2020085266 A1 WO2020085266 A1 WO 2020085266A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
amount
crowdfunding
payment
tokens
Prior art date
Application number
PCT/JP2019/041227
Other languages
English (en)
French (fr)
Inventor
淳児 道山
添田　純一郎
勇二 海上
雄揮 廣瀬
哲司 渕上
大森　基司
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN201980046642.6A priority Critical patent/CN112449706A/zh
Priority to JP2020553368A priority patent/JPWO2020085266A1/ja
Publication of WO2020085266A1 publication Critical patent/WO2020085266A1/ja
Priority to US17/157,163 priority patent/US20210142371A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0279—Fundraising management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis

Definitions

  • the present invention relates to a control method, a fund management system, a program, and a data structure.
  • Patent Document 1 An information processing device for promoting the spread of crowdfunding has been proposed (see Patent Document 1).
  • the present invention provides a control method and the like that appropriately manages funding in crowdfunding.
  • a control method is a control method executed by one of the plurality of servers in a fund management system including a plurality of servers that hold a distributed ledger.
  • 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 appropriately manage funding in crowdfunding.
  • FIG. 1 is a block diagram schematically showing the configuration of the fund management 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 recruitment transaction data according to the first embodiment.
  • FIG. 4 is an explanatory diagram schematically showing payment transaction data according to the first embodiment.
  • FIG. 5 is an explanatory diagram schematically showing the refund transaction data according to the first embodiment.
  • FIG. 6 is a flowchart showing the processing of the server according to the first embodiment.
  • FIG. 7 is a first sequence diagram showing the processing of the entire fund management system in the first embodiment.
  • FIG. 8 is a second sequence diagram showing the processing of the entire fund management system in the first embodiment.
  • FIG. 9 is a flowchart showing the processing of the server according to the second embodiment.
  • FIG. 10 is a first sequence diagram showing the processing of the entire fund management system in the second embodiment.
  • FIG. 11 is a second sequence diagram showing the processing of the entire fund management system in the second embodiment.
  • FIG. 12 is an explanatory diagram schematically showing recruitment transaction data according to the third embodiment.
  • FIG. 13 is a flowchart showing the processing of the server according to the third embodiment.
  • FIG. 14 is a flowchart showing a payment amount determination algorithm by the control unit in the third embodiment.
  • FIG. 15 is an explanatory diagram showing an example of the maximum payment amount of the applicant in the third embodiment.
  • FIG. 16 is an explanatory diagram showing an example of the progress and results of execution of the payment amount determination algorithm by the control unit according to the third embodiment.
  • FIG. 17 is a first sequence diagram showing the processing of the entire fund management system in the third embodiment.
  • FIG. 18 is a second sequence diagram showing the processing of the entire fund management system in the third embodiment.
  • FIG. 19 is a flowchart showing the processing of the server in the modification of each embodiment.
  • FIG. 20 is a block diagram schematically showing the configuration of the server in the modification of each embodiment.
  • FIG. 21 is an explanatory diagram showing the data structure of the block chain.
  • FIG. 22 is an explanatory diagram showing the data structure of transaction data.
  • Crowdfunding is a mechanism to provide content providers with funds provided by one or more persons (also called supporters) for projects (for example, creating and providing new content) on the Internet. Is. With this mechanism, the content provider can raise funds for the project.
  • Patent Document 1 An information processing device for promoting the spread of crowdfunding has been proposed (see Patent Document 1).
  • the technique described in Patent Document 1 is a technique that can promote the spread of crowdfunding by performing crowdfunding at a live venue.
  • the present invention provides a control method and the like that appropriately manages funding in crowdfunding.
  • a control method is performed by one of the plurality of servers in a fund management system including a plurality of servers that hold a distributed ledger.
  • the smart contract determines whether or not the crowdfunding target condition is satisfied, and outputs information indicating the result of the determination.
  • the server stores the information regarding the token payment processing in the cloud funding as transaction data in the distributed ledger. Since it is practically impossible to tamper with the transaction data stored in the distributed ledger, the information regarding the token payment process in crowdfunding is properly managed. Further, since it is determined by the smart contract whether or not the target condition for crowdfunding is satisfied, it can be automatically and safely executed without the intervention of another person or another system. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the determination of whether or not the target condition is satisfied is determined by the total number of tokens paid by the payment process related to the transaction data received during the recruitment period when the recruiting period for the crowdfunding ends. However, it may be performed by determining whether or not the amount is equal to or more than the target amount of the crowdfunding.
  • the server determines whether or not the target condition is satisfied by comparing the total amount of the tokens paid by the payment process with the target amount when the predetermined crowdfunding recruitment period ends. Since it is determined, the above determination can be made more easily. Therefore, the control method according to the present invention can more appropriately and appropriately manage the financing in crowdfunding.
  • the target condition is satisfied, when the transaction data is received, the sum of the tokens paid by the payment process related to the transaction data received before the reception is the cloud It may be done by determining whether or not it is equal to or more than the target amount of funding.
  • the server when the server receives the transaction data related to the payment process, the server determines whether or not the target condition is satisfied by comparing the total amount of tokens paid by the payment process with the target amount. Therefore, the above determination can be made more easily. Therefore, the control method according to the present invention can more appropriately and appropriately manage the financing in crowdfunding.
  • the token paid to the management account by the payment process is transferred from the management account to the one or more tokens.
  • Transaction data relating to a refund process for refunding to each applicant may be generated, and the generated transaction data may be stored in a distributed ledger provided in each of the plurality of servers.
  • the server when the target condition of crowdfunding is not satisfied, the server also executes the token withdrawal process by the smart contract. Therefore, the token refund process is also automatically and safely executed without the intervention of another person or another system. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the transaction data relating to the payment process includes a predetermined amount of tokens to be paid by each of the one or more applicants, and the payment process is a process of paying the predetermined amount of tokens to each of the one or more applicants.
  • the server appropriately manages information regarding payment processing in which one or more applicants each pay a predetermined amount of tokens. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the payment process is a process of paying a designated amount of tokens designated by each of the one or more applicants
  • the control method further includes, after the payment process, from the designated amount of tokens to the cloud fan.
  • a refund process may be included in which the amount of tokens obtained by subtracting the amount of tokens proportionally divided by the one or more applicants from the Ding amount is refunded to each of the one or more applicants.
  • the server appropriately manages the information regarding the payment process in which the one or more applicants pay each of the tokens of a predetermined amount proportionally distributed by the one or more applicants. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the amount of tokens proportionally distributed to the crowdfunding target amount by the one or more applicants is paid by the one of the one or more applicants in the payment process.
  • the one applicant may be excluded from the one or more applicants, and the target amount of the crowdfunding may be apportioned among the one or more applicants.
  • the payment amount of the applicant is determined so as not to exceed the specified amount specified by each applicant. Therefore, in the crowdfunding, the control method according to the present invention can appropriately manage the financing while keeping the payment amount within the range not exceeding the upper limit.
  • the terminal of the crowdfunding recruiter may further generate a code related to the smart contract, and store transaction data including the generated code in a distributed ledger provided in each of the plurality of servers. .
  • the contract code of the smart contract used for the determination process of whether the target condition is satisfied can be generated by the recruiter. Therefore, by generating a contract code that reflects the solicitation of the recruiter, it is possible to make a condition judgment that further reflects the solicitation of the recruiter. Therefore, the control method according to the present invention can more appropriately reflect the intention of the recruiter and can appropriately manage the financing in the crowdfunding.
  • the transaction data when storing the transaction data in a distributed ledger provided in each of the plurality of servers, the transaction data may be stored in the distributed ledger after executing a consensus algorithm by each of the plurality of servers.
  • the server stores the distributed ledger with the execution of the consensus algorithm. Therefore, by obtaining the execution of the consensus algorithm, it is possible to appropriately and appropriately manage the financing in crowdfunding.
  • a program is a fund management system including a plurality of servers holding a distributed ledger, and relates to a token payment process from one or more applicants for cloud funding to a management account.
  • a processing unit that receives transaction data, stores the received transaction data in a distributed ledger provided in each of the plurality of servers, and determines whether or not a target condition for the crowdfunding is satisfied by a smart contract, and the determination is performed.
  • a control unit for outputting information indicating the result.
  • 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 used in a fund management system including a plurality of servers holding a distributed ledger, and is identification information that can uniquely identify a crowdfunding project.
  • An identifier of an applicant's account that pays tokens in the project an identifier of a management account that receives the token payment in the project, information indicating the amount of tokens paid by the applicant in the project, and the electronic mail of the applicant. Including signature and.
  • 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.
  • the unit of fund procurement in the fund is also called a project.
  • the project is assumed to be a project related to the provision of contents.
  • the person who provides the content is called a provider
  • the person who seeks funding for the content is called a recruiter
  • the person who applies for the funding is called an applicant.
  • a project is said to be “established” when it is possible to receive an application for funding of a specified target amount during the specified recruitment period for the one project.
  • FIG. 1 is a block diagram schematically showing the configuration of the fund management system 1 in this embodiment.
  • the fund management system 1 includes servers 10A, 10B and 10C and terminals 40, 41, 50 and 51.
  • the devices included in the fund management system 1 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 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 fund management 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 regarding recruitment, payment, and refund in crowdfunding. By receiving the transaction data, the server 10A accepts solicitation, payment, and refund in crowdfunding.
  • the fund provision in the project is managed as the token provision by the distributed ledger, for example.
  • 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.
  • 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 terminal 40 is a terminal device owned by the provider.
  • the content provided by the provider is, for example, a moving image, a still image, music, or electronic data such as software (including application software). It is assumed that the content provided by the provider is created by the provider, and this case will be described, but the content is not limited to this.
  • the terminal 40 provides the applicant with the content related to the project.
  • the terminal 40 is, for example, a personal computer, a smartphone, a tablet, or the like.
  • the terminal 41 is a terminal device owned by a recruiter of a crowdfunding project.
  • the recruiter seeks funding by the applicant so that the total amount of applications for funding by the applicant reaches the target amount of the project.
  • the recruiter may be the same as the provider, the same as the applicant, or different from the provider and the recruiter.
  • the terminal 41 generates transaction data (also referred to as recruitment transaction data) including information regarding the recruitment of funds when transmitting funds, and transmits the generated transaction data to the server 10A or the like.
  • the terminal 50 is a terminal device owned by the applicant.
  • the applicant refers to the information regarding the offer for funding and provides the funding. After that, when the project is completed, the provided funds are transferred to the provider. On the other hand, if the project is not completed, the funds provided will be refunded to the applicant.
  • the terminal 50 When providing funds, the terminal 50 generates transaction data (payment transaction data) for payment of funds, and transmits the generated payment transaction data to the server 10A.
  • transaction data payment transaction data
  • the terminal 50 acquires the content provided by the provider. The applicant can then use the content.
  • 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 the present 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, the CPU executing the program using the memory.
  • 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 fund management system 1 or the transaction data generated by the control unit 13 is acquired. And store it in the distributed ledger.
  • the transaction data includes recruitment transaction data, payment transaction data, and refund 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. Based on the characteristic that it is difficult to tamper with the information recorded in the distributed ledger, the transaction data is managed so as not to be tampered with.
  • 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 unit 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 also 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 the success or failure of a crowdfunding project and controls the provision of funds.
  • the control unit 13 receives the target condition for crowdfunding from the terminal 41 by the recruitment transaction. Further, the control unit 13 receives the payment of the token to the management account by the payment transaction from the terminals 50 and 51.
  • the control unit 13 determines whether or not the target condition for crowdfunding is satisfied, and outputs information indicating the determination result.
  • the management account is an account for managing the token by temporarily storing the token in crowdfunding.
  • control unit 13 controls the processing related to crowdfunding based on the result of the above determination. Specifically, the control unit 13 performs processing such as various notifications when the crowdfunding project is established. When the project is not established, the token paid from the applicant to the management account is controlled to be refunded from the management account to the applicant.
  • the target period when the target period is met, when the crowdfunding recruitment period ends, the total number of tokens paid by the payment process related to the transaction data received during the recruitment period is the crowdfunding This is done by determining whether or not the target amount is greater than or equal to the target amount. In this embodiment, this case will be described as an example.
  • the payment process is a process in which one or more applicants each pay a predetermined amount of tokens.
  • Payment transaction data used in payment processing includes a predetermined amount of tokens to be paid by each of one or more applicants.
  • 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. In the following, a case will be described as an example where all of the above processing of the control unit 13 is performed by a smart contract.
  • FIG. 3 is an explanatory diagram schematically showing recruitment transaction data according to the present embodiment.
  • the recruitment transaction data is generated by the recruiter U2, that is, the terminal 41 when the crowdfunding project is started, and is transmitted to the server 10A or the like.
  • the recruitment transaction data includes recruiter ID, project ID, management account ID, provider account ID, recruitment deadline, target amount, payment amount, contract code, and signature.
  • recruiter ID is an identifier that can uniquely identify a recruiter who is seeking funding for the project.
  • the project ID is an identifier that can uniquely identify the project.
  • the management account ID is an identifier that can uniquely identify the crowdfunding management account.
  • the provider account ID is an identifier that can uniquely identify the provider's account.
  • the application deadline is information indicating the application deadline of the project, that is, the end of the application period.
  • the target amount is information indicating the amount of funds, that is, the amount of tokens, that the recruiter aims to raise in the project.
  • the payment amount is information indicating the amount of tokens paid by each applicant in the project.
  • the contract code is a smart contract code that determines the success or failure of the project.
  • the signature is an electronic signature given by the device or person who generated the solicitation transaction data.
  • the recruitment transaction data shown in FIG. 3 is used when the recruiter with the recruiter ID “aaa001” recruits funds for the project with the project ID “kdfjafjpo34”.
  • the management account ID is “moaq68079”
  • the provider account ID of the provider is “fljad4019”
  • the deadline for recruitment is “2018.10.10 15:00:00”
  • the target amount is “ It is a 100 "token and the payment amount is a" 1 "token.
  • the signature is the electronic signature of the recruiter.
  • FIG. 4 is an explanatory diagram schematically showing payment transaction data in the present embodiment.
  • the payment transaction data is generated by the applicant who makes the payment (for example, the applicant U3, that is, the terminal 50) when the fund is paid in the project, and is transmitted to the server 10A or the like.
  • the payment transaction data includes an applicant account ID, a project ID, a management account ID, a payment amount, a transmission date and time, and a signature.
  • the applicant account ID is an identifier that can uniquely identify the applicant's account for payment of funds.
  • the project ID is an identifier that can uniquely identify the project.
  • the management account ID is an identifier that can uniquely identify the crowdfunding management account.
  • the payment amount is information indicating the amount of tokens that the applicant pays to the management account for the payment.
  • the transmission date and time is information indicating the transmission date and time of the payment transaction data.
  • the signature is an electronic signature given by the device or person who generated the payment transaction data.
  • the payment transaction data shown in FIG. 4 is used when an applicant whose applicant account ID is “aab0aab” pays funds for a project whose project ID is “kdfjafjpo34”.
  • the payment amount is “1” token
  • the transmission date and time of this payment transaction data is “2018.10.11 07:00:00”.
  • the signature is the applicant's electronic signature.
  • the payment transaction data shown in FIG. 4 is a data structure used in a fund management system including a plurality of servers holding a distributed ledger, and has identification information that can uniquely identify a crowdfunding project.
  • An identifier of an applicant's account that pays tokens in the project an identifier of a management account that receives the token payment in the project, information indicating the amount of tokens paid by the applicant in the project, and an electronic signature of the applicant It can also be said to have a data structure including and.
  • FIG. 5 is an explanatory diagram schematically showing the refund transaction data in the present embodiment.
  • the refund transaction data is generated by the server 10A or the like when refunding the funds from the management account to the applicant when the fund related to the project is not established.
  • the refund transaction data includes an applicant account ID, a project ID, a management account ID, a refund amount, a transmission date and time, and a signature.
  • the applicant account ID is an identifier that can uniquely identify the applicant's account to receive the refund of funds.
  • the project ID is an identifier that can uniquely identify the project.
  • the management account ID is an identifier that can uniquely identify the crowdfunding management account.
  • the refund amount is information indicating the amount of tokens to be refunded from the management account to the applicant account in the refund.
  • the transmission date and time is information indicating the transmission date and time of the refund transaction data.
  • the signature is an electronic signature given by the device or person who generated the refund transaction data.
  • the refund transaction data shown in FIG. 5 is used when an applicant whose applicant account ID is “aab0aab” receives a refund of funds for a project whose project ID is “kdfjafjpo34”.
  • the refund amount is “1” token
  • the date and time of transmission of this refund transaction data is “2018.10.31 00:00:00”
  • the signature is the electronic signature of the server 10A.
  • FIG. 6 is a flowchart showing the processing of the server 10A in this embodiment.
  • step S101 the processing unit 11 determines whether or not the recruitment transaction data is received from the recruiter U2, that is, the terminal 41. If the recruitment transaction data is received (Yes in step S101), the process proceeds to step S102, and if not (No in step S101), step S101 is executed again. That is, the processing unit 11 waits in step S101 until receiving the recruitment transaction data.
  • the recruitment transaction data contains the contract code of the smart contract that determines the target condition of the project.
  • step S 102 the processing unit 11 stores the recruitment transaction data received in step S 101 in the distributed ledger by providing it to the ledger management unit 12. Further, the processing unit 11 transmits the recruitment 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 processing unit 11 determines whether payment transaction data has been received from the applicant U3 or the like, that is, the terminal 41 or the like. If payment transaction data is received (Yes in step S103), the process proceeds to step S104, and if not (No in step S103), the process proceeds to step S105.
  • step S104 the processing unit 11 stores the payment transaction data acquired in step S103 in the distributed ledger by providing the payment transaction data to the ledger management unit 12. Further, the processing unit 11 transmits the payment 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 S105 the control unit 13 determines whether the recruitment period has ended. For example, whether or not the offer period has ended is determined based on the payment transaction data stored in step S104. If it is determined that the recruitment period has ended (Yes in step S105), the process proceeds to step S106, and if not (No in step S105), the process proceeds to step S103.
  • step S106 the control unit 13 notifies the terminal 50 or the like of the applicant U3 or the like that the recruitment period has ended. Note that step S106 may not be executed.
  • step S107 the control unit 13 determines whether or not the target conditions of the crowdfunding project are satisfied. The determination of whether or not the target condition is satisfied is made by executing the contract code included in the recruitment transaction data received in step S101. If it is determined that the target condition is satisfied (Yes in step S107), the process proceeds to step S108, and if not (No in step S107), the process proceeds to step S121.
  • step S108 the control unit 13 generates payment transaction data.
  • step S109 the control unit 13 stores the payment transaction data generated in step S108 in the distributed ledger by providing the payment transaction data to the ledger management unit 12. Further, the control unit 13 transmits the payment 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 S110 the control unit 13 sends a notification of payment completion to the provider U1, that is, the terminal 40.
  • the terminal 40 controls the content generated by the provider U1 to be provided to the applicant.
  • step S121 the control unit 13 generates refund transaction data.
  • the withdrawal transaction data generated by the control unit 13 is transaction data indicating that the funds are to be withdrawn from the management account to the applicant.
  • step S122 the control unit 13 provides the refund transaction data generated in step S121 to the ledger management unit 12 to store it in the distributed ledger. Further, the control unit 13 transmits the refund 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 S123 the control unit 13 notifies the applicant U3, that is, the terminal 50 and the like that the project has not been established. Note that step S121 does not have to be executed.
  • step S110 or S123 the series of processes shown in FIG. 6 ends.
  • FIG. 7 is a first sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • FIG. 7 shows the processing of the entire fund management system 1 when the project is established.
  • the same processes as those in the flowchart of FIG. 6 are designated by the same reference numerals as those in FIG.
  • step S201 the terminal 40 of the provider U1 sets conditions related to the crowdfunding project, and sends the set conditions to the terminal 41.
  • the conditions include a deadline for offering, a target amount, and a payment amount.
  • the terminal 41 receives the transmitted condition.
  • step S211 the terminal 41 generates a contract code for determining the target condition of the project based on the condition received in step S201.
  • step S212 the terminal 41 generates recruitment transaction data (see FIG. 3) including the condition received in step S201 and the contract code generated in step S211.
  • the terminal 41 also transmits the generated recruitment transaction data to the server 10A or the like.
  • the terminal 41 may transmit the generated recruitment transaction data to one of the servers 10A or the like, or to a plurality of servers.
  • the server 10A or the like receives the recruitment transaction data transmitted by the terminal 41 and stores it in the distributed ledger (steps S101 and S102).
  • step S221 the terminal 51 generates payment transaction data and sends it to the server 10A or the like. At this time, the terminal 51 may send the generated payment transaction data to one of the servers 10A or the like, or may send it to a plurality of servers.
  • the server 10A or the like receives the transmitted payment transaction data and stores it in the distributed ledger (steps S103 and S104).
  • a notification that the recruitment period has ended is transmitted (steps S105 and S106).
  • the server 10A or the like generates payment transaction data related to payment of funds from the management account to the provider and stores the payment transaction data in the distributed ledger (steps S108 and S109). Then, the fact that the payment is completed is transmitted to the terminal 40 (step S110).
  • step S202 when the terminal 40 receives the notification, the terminal 40 provides the content generated by the provider to the applicant.
  • the provision of the content from the provider to the applicant in step S202 may be performed at any time after it is determined that the target condition is satisfied (step S107).
  • the generation of the payment transaction in step S108 may be performed by the server 10B or the like different from the server 10A or the terminal 41 or the like.
  • FIG. 8 is a second sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • FIG. 8 shows the processing of the entire fund management system 1 when the project is not established.
  • step S201 to step S107 is the same as the processing in FIG. 7, and the determination result in step S107 and the subsequent processing are different from those in FIG.
  • step S107 the server 10A or the like generates refund transaction data relating to refund of funds from the management account to the applicant when the target condition is not achieved, and stores the refund transaction data in the distributed ledger (steps S121 and S122). . Then, the fact that the project has not been established is transmitted to the terminal 40 (step S123).
  • a snapshot or preview image of the content may be provided before the applicant makes an application.
  • a large amount of reward may be provided to those who apply at an earlier timing during the recruitment period.
  • the reward may be a token, or may be a distribution of a larger proportion of the profit when the content created by the provider subsequently makes a profit, It may be that the content is provided sooner.
  • the recruiter may pay the token to the provider.
  • the configuration of the fund management system 1 has been described as an example in which the server 10A and the like and the terminal 40 and the like are independent devices as shown in FIG. 1, but is not limited to this.
  • the server 10A may not exist and the terminals 40, 41, 50, and 51 may have a distributed ledger.
  • the terminal 50 or 51 may have a distributed ledger.
  • some or all of the terminals 40, 41, 50 and 51 may also have the function of the server 10A and the like.
  • the fund management system 1 can appropriately manage the fund procurement in crowdfunding.
  • the configuration of the fund management system 1, the configuration of the server, and the structure of various transaction data in this embodiment are the same as those in the first embodiment (see FIGS. 1 and 2).
  • control unit 13 differs from that of the first embodiment in the timing of determining whether or not the target condition for crowdfunding is satisfied.
  • the target condition is satisfied, when the transaction data is received, the total number of tokens paid by the payment process related to the transaction data received before the reception is the target of the crowdfunding. This is done by determining whether or not the amount is greater than or equal to the amount.
  • FIG. 9 is a flowchart showing the processing of the server 10A in this embodiment.
  • the same processes as those in the first embodiment are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the processing unit 11 receives the recruitment transaction data and the payment transaction data and stores them in the distributed ledger.
  • step S131 the control unit 13 determines whether or not the target condition for crowdfunding is satisfied.
  • the determination of whether or not the target condition is satisfied is made by executing the contract code included in the recruitment transaction data received in step S101. For example, whether or not the target condition is satisfied is determined based on the payment transaction data stored in step S104. If it is determined that the target condition is satisfied (Yes in step S131), the process proceeds to step S132, and if not (No in step S131), the process proceeds to step S141.
  • step S132 the processing unit 11 notifies the terminal 50 or the like of the applicant U3 or the like that the recruitment period has ended. Note that step S132 may not be executed.
  • the control unit 13 performs a process related to payment of funds to the provider (steps S108 to S110), and ends the series of processes shown in FIG.
  • step S141 the control unit 13 determines whether the recruitment period has ended. If it is determined that the recruitment period has ended (Yes in step S141), the process proceeds to step S142, and if not (No in step S141), the process proceeds to step S103.
  • step S142 the control unit 13 notifies the applicant terminal that the recruitment period has ended. Note that step S142 may not be executed. After that, the control unit 13 executes a process (steps S121 to S122) relating to the refund of funds to the applicant. Further, the control unit 13 notifies the applicant U3, that is, the terminal 50 and the like that the project has not been established (step S123), and ends the series of processes shown in FIG.
  • FIG. 10 is a first sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • the sequence diagram shown in FIG. 10 shows a case where the target condition is satisfied during the recruitment period.
  • steps S201 to S104 is the same as the processing in the first embodiment (see FIG. 7).
  • control unit 13 Every time the control unit 13 stores the payment transaction data in the distributed ledger in step S104, the control unit 13 determines whether or not the target condition is satisfied. If the target conditions are not met, wait again to receive payment transaction data. When the target conditions are satisfied, the terminal 50 or the like of the applicant U3 or the like is notified.
  • the generation of the payment transaction data in step S108 may be performed by the server 10B or the like different from the server 10A or the terminal 41 or the like.
  • FIG. 11 is a second sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • the sequence diagram shown in FIG. 11 shows a case where the target condition is not satisfied during the recruitment period.
  • steps S201 to S104 is the same as the processing in the first embodiment (see FIG. 7).
  • control unit 13 Every time the control unit 13 stores the payment transaction data in the distributed ledger in step S104, the control unit 13 determines whether or not the target condition is satisfied. Then, when the target condition is not satisfied and the recruitment period is over, the process related to the refund of the funds to the applicant (steps S121 to S122) is executed, and the fact that the project is not established is notified (step S121). S123).
  • the generation of the refund transaction data in step S121 may be performed by the server 10B or the like different from the server 10A or the terminal 41 or the like.
  • the provider can receive the payment without waiting for the end of the predetermined recruitment period.
  • the target amount is set in advance at the beginning of the recruitment period, and the payment amount per applicant is Suppose you haven't decided. After the applicant pays the specified amount of tokens, the fund management system deducts the target amount of tokens from the specified amount of tokens by apportioning one or more applicants to each applicant. Includes refund processing.
  • the designated amount is the amount of tokens designated by each applicant, and is the upper limit of the amount of tokens that the applicant can pay.
  • the fund management system according to the present embodiment manages a project of this type.
  • the payment amount per applicant when the payment amount per applicant is determined after the applicant pays the token, the payment amount of each applicant is controlled so as not to exceed the designated amount. Therefore, not all applicants who make payments pay the funds. Of the applicants, the applicant who will eventually pay the funds to the provider is also called the payer. The amount paid by the applicant in the payment process is also referred to as the paid-in amount.
  • FIG. 12 is an explanatory diagram schematically showing recruitment transaction data in the present embodiment.
  • the recruitment transaction data includes a recruiter ID, a project ID, a management account ID, a provider account ID, a recruitment deadline, a target amount, a contract code, and a signature.
  • the recruitment transaction data shown in FIG. 12 differs from that in the first embodiment in that it does not include the payment amount in the recruitment transaction data (see FIG. 3) in the first embodiment. This is because the payment amount per applicant has not been decided during the offering period.
  • the payment amount in the payment transaction data (not shown) in the present embodiment is an upper limit value of the token amount that the applicant can pay, which is designated by the applicant.
  • the above payment amount corresponds to the payment amount.
  • FIG. 13 is a flowchart showing the processing of the server 10A in this embodiment.
  • the configuration of the fund management system 1, the configuration of the server, and the structure of various transaction data in this embodiment are the same as those in the first embodiment (see FIGS. 1 and 2).
  • control unit 13 differs from that of the first embodiment in the process of determining the payment amount.
  • steps S101 to S107 is the same as that in the first embodiment (see FIG. 6).
  • step S151 the control unit 13 determines the payment amount and the payer.
  • the payer is determined by the determination algorithm from among the applicants who transmitted the payment transaction data received in step S103. There may be various methods for determining the payer and the payment amount, and an example thereof will be described in detail later.
  • step S152 the control unit 13 determines whether the payment is successful. Whether or not the payment is successful is determined based on the result information of “payment is successful” or “payment is not successful” which is obtained as a result of execution of the payer / payment amount determination algorithm in step S151. Can be done. If it is determined that the payment is successful (Yes in step S152), the process proceeds to step S153, and if not (No in step S152), the process proceeds to step S161.
  • step S153 the control unit 13 calculates the refund amount.
  • the payout amount is the amount obtained by subtracting the amount of tokens proportionally distributed to the target amount by one or more applicants from the paid amount.
  • step S154 the control unit 13 generates a refund transaction for refunding the refund amount calculated in step S153 to the applicant.
  • step S155 the control unit 13 provides the refund transaction data generated in step S154 to the ledger management unit 12 to store it in the distributed ledger. Further, the control unit 13 transmits the refund 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 that, as in the first embodiment, the control unit 13 sends a notification of payment completion to the provider U1, that is, the terminal 40 (step S110).
  • step S161 the control unit 13 generates a refund transaction for refunding the entire amount of the token paid by the payment transaction data received from each applicant in step S103 to the applicant.
  • step S162 the control unit 13 stores the disbursement transaction data generated in step S161 in the distributed ledger by providing it to the ledger management unit 12. Further, the control unit 13 transmits the refund 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 that, the control unit 13 may notify the applicant U3, that is, the terminal 50 or the like that the project has not been established (step S123).
  • FIG. 14 is a flow chart showing an algorithm for determining the payment amount by the control unit 13 in the present embodiment.
  • the flowchart shown in FIG. 14 is an example of the process included in step S151 of FIG.
  • step S301 the control unit 13 determines the payment amount from each applicant to the provider. For example, the control unit 13 determines the payment amount per applicant by apportioning the target amount by the applicant.
  • step S302 the control unit 13 compares, for each applicant, the payment amount determined in step S301 with the payment amount of the applicant. Then, the control unit 13 determines whether there is an applicant whose payment amount is larger than the payment amount. If it is determined that there is an applicant whose payment amount is larger than the payment amount (Yes in step S302), the process proceeds to step S303, and if not (No in step S302), result information that "payment is successful" is made. Then, the series of processing shown in FIG. 14 is finished.
  • step S303 the control unit 13 excludes applicants whose payment amount is larger than the payment amount.
  • step S304 the control unit 13 determines whether the applicant exists. That is, after the exclusion process performed in step S303, it is determined whether or not at least one applicant exists. If it is determined that the applicant exists (Yes in step S304), the process of step S301 is executed for the applicant after the exclusion, and if not (No in step S304), "payment is successful" The series of processing shown in FIG. 14 is ended with the result information "No".
  • control unit 13 repeatedly excludes the applicants who have exceeded the payment amount from among the first one or more applicants, so that the payment amounts of all the applicants are equal to or less than the payment amount. Determine the payment amount for each applicant.
  • FIG. 15 is an explanatory diagram showing an example of the amount paid by the applicant according to the present embodiment.
  • FIG. 16 is an explanatory diagram showing an example of the progress and results of execution of the payment amount determination algorithm by the control unit 13 in the present embodiment.
  • step S301 the payment amount per applicant is calculated to be about 17 tokens. Since the value of 17 tokens is larger than the payment amount of the applicants A and B, the applicants A and B are excluded (step S303), and the applicants C, D, E and F exist.
  • step S301 the payment amount per applicant is calculated to be 25 tokens. Since the value of 25 tokens is larger than the payment amount of the applicants C and D, the applicants C and D are excluded (step S303), and the applicants E and F exist.
  • step S301 the payment amount per applicant is calculated to be 50 tokens. Since the value of 50 tokens is equal to or less than the payment amount of the applicants E and F, the applicants E and F finally become payers.
  • FIG. 17 is a first sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • FIG. 17 shows the processing of the entire fund management system 1 when the payment is successful.
  • steps S201 to S107 is the same as the processing in the first embodiment (see FIG. 7).
  • step S107 the control unit 13 determines the payment amount and the payer, and when the payment is established (steps S151 and S152), the refund amount for each applicant is determined. It is calculated and a refund process is executed (steps S154 and S155). After that, as in the first embodiment, the processes of steps S110 to S202 are executed.
  • the generation of the refund transaction in step S154 may be performed by the server 10B or the like different from the server 10A or the terminal 41 or the like.
  • FIG. 18 is a second sequence diagram showing the processing of the entire fund management system 1 in this embodiment.
  • FIG. 18 shows the processing of the entire fund management system 1 when payment is not successful.
  • steps S201 to S107 is the same as the processing in the first embodiment (see FIG. 7).
  • control unit 13 determines the payment amount and the payer, and when the payment is not established (steps S151 and S152), the refund amount is refunded to the applicant.
  • the process is executed (steps S161 and S162). After that, the control unit 13 may notify the applicant U3, that is, the terminal 50 or the like that the project has not been established (step S123).
  • step S161 may be performed by the server 10B or the like different from the server 10A or the terminal 41 or the like.
  • FIG. 19 is a flow chart showing a server process (also referred to as a server control method) in the modification of each embodiment.
  • a series of processes shown in FIG. 19 is a control method executed by one of the plurality of servers in a fund management system including a plurality of servers holding a distributed ledger.
  • step S601 transaction data regarding payment processing of tokens from one or more applicants for crowdfunding to recruiters is received, and the received transaction data is provided in each of a plurality of servers.
  • a distributed ledger To store.
  • step S602 it is determined by a smart contract whether or not the target condition for crowdfunding is satisfied.
  • step S603 information indicating the result of the judgment is output.
  • FIG. 20 is a block diagram schematically showing the configuration of the fund management system in the modification of each embodiment.
  • the fund management system 2 shown in FIG. 20 includes a plurality of servers 60A, 60B, and 60C that hold a distributed ledger.
  • the fund management system 2 includes a processing unit 61 and a control unit 63.
  • the processing unit 61 receives transaction data relating to token payment processing from one or more applicants for crowdfunding to a recruiter, and stores the received transaction data in a distributed ledger provided in each of a plurality of servers.
  • the control unit 63 determines whether or not the target condition for crowdfunding is satisfied by a smart contract, and outputs information indicating the result of the determination.
  • FIG. 21 is an explanatory diagram showing the data structure of the block chain.
  • a block chain is one in which the blocks that 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 preceding 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.
  • the hash value of the block will be different from the value before the change, and in order to make the altered block look correct, all the subsequent blocks must be recreated. Is very difficult in reality. Using this property, the blockchain is guaranteed to be tamper-proof.
  • FIG. 22 is an explanatory diagram showing the data structure of transaction data.
  • the transaction data shown in FIG. 22 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 server according to the above-described embodiment stores information regarding token payment processing in cloud funding as transaction data in the distributed ledger. Since it is practically impossible to tamper with the transaction data stored in the distributed ledger, the information regarding the token payment process in crowdfunding is properly managed. Further, since it is determined by the smart contract whether or not the target condition for crowdfunding is satisfied, it can be automatically and safely executed without the intervention of another person or another system. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the server determines whether or not the target condition is satisfied by comparing the total amount of tokens paid by the payment process with the target amount when the predetermined recruitment period for crowdfunding ends. Therefore, the above determination can be made more easily. Therefore, the control method according to the present invention can more appropriately and appropriately manage the financing in crowdfunding.
  • the server determines whether or not the target condition is satisfied by comparing the total amount of tokens paid by the payment process with the target amount. Can be done more easily. Therefore, the control method according to the present invention can more appropriately and appropriately manage the financing in crowdfunding.
  • the server also executes token withdrawal processing using smart contracts. Therefore, the token refund process is also automatically and safely executed without the intervention of another person or another system. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the server appropriately manages information regarding payment processing in which one or more applicants pay a predetermined amount of tokens. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the server appropriately manages information related to payment processing in which a predetermined amount of tokens are prorated by one or more applicants and the amount of tokens is paid by each of the one or more applicants. Therefore, the control method according to the present invention can appropriately manage financing in crowdfunding.
  • the payment amount of the applicant is determined so that the amount specified by each applicant does not exceed the specified amount. Therefore, in the crowdfunding, the control method according to the present invention can appropriately manage the financing while keeping the payment amount within the range not exceeding the upper limit.
  • the contract code of the smart contract used for the determination process of whether the target condition is satisfied can be generated by the recruiter. Therefore, by generating a contract code that reflects the solicitation of the recruiter, it is possible to make a condition judgment that further reflects the solicitation of the recruiter. Therefore, the control method according to the present invention can more appropriately reflect the intention of the recruiter and can appropriately manage the financing in the crowdfunding.
  • the server gets the execution of the consensus algorithm and stores the distributed ledger. Therefore, by obtaining the execution of the consensus algorithm, it is possible to appropriately and appropriately manage the financing in crowdfunding.
  • 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 fund management system including a plurality of servers holding a distributed ledger in a computer. Whether the transaction data regarding the payment processing of tokens from the applicant to the management account is received, the received transaction data is stored in the distributed ledger provided in each of the plurality of servers, and the target condition for the crowdfunding is satisfied. It is a program for executing a control method of determining whether or not a smart contract is used and outputting information indicating the result of the determination.
  • the present invention can be used for a fund management system that appropriately manages fund procurement in crowdfunding.

Landscapes

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

Abstract

分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法は、クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信したトランザクションデータを複数のサーバそれぞれが備える分散台帳に格納し（ステップＳ６０１）、クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し（ステップＳ６０２）、判定の結果を示す情報を出力する（ステップＳ６０３）。

Description

制御方法、ファンド管理システム、プログラム、及び、データ構造
　本発明は、制御方法、ファンド管理システム、プログラム、及び、データ構造に関する。
　クラウドファンディングの普及を促進することを目的とした情報処理装置が提案されている（特許文献１参照）。
特開２０１７－１５６９２７号公報
　しかしながら、クラウドファンディングにおいて、資金調達を不正に妨げたり、調達された資金を不正に取得したりする行為がなされ得るという問題がある。
　そこで、本発明は、クラウドファンディングにおける資金調達を適切に管理する制御方法などを提供する。
　本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本発明の制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
図１は、実施の形態１におけるファンド管理システムの構成を模式的に示すブロック図である。 図２は、実施の形態１におけるサーバの構成を模式的に示すブロック図である。 図３は、実施の形態１における募集トランザクションデータを模式的に示す説明図である。 図４は、実施の形態１における支払トランザクションデータを模式的に示す説明図である。 図５は、実施の形態１における払戻トランザクションデータを模式的に示す説明図である。 図６は、実施の形態１におけるサーバの処理を示すフロー図である。 図７は、実施の形態１におけるファンド管理システム全体の処理を示す第一のシーケンス図である。 図８は、実施の形態１におけるファンド管理システム全体の処理を示す第二のシーケンス図である。 図９は、実施の形態２におけるサーバの処理を示すフロー図である。 図１０は、実施の形態２におけるファンド管理システム全体の処理を示す第一のシーケンス図である。 図１１は、実施の形態２におけるファンド管理システム全体の処理を示す第二のシーケンス図である。 図１２は、実施の形態３における募集トランザクションデータを模式的に示す説明図である。 図１３は、実施の形態３におけるサーバの処理を示すフロー図である。 図１４は、実施の形態３における制御部による支払額の決定アルゴリズムを示すフロー図である。 図１５は、実施の形態３における申込者の支払上限額の一例を示す説明図である。 図１６は、実施の形態３における制御部による支払額の決定アルゴリズムの実行の経過および結果の一例を示す説明図である。 図１７は、実施の形態３におけるファンド管理システム全体の処理を示す第一のシーケンス図である。 図１８は、実施の形態３におけるファンド管理システム全体の処理を示す第二のシーケンス図である。 図１９は、各実施の形態の変形例におけるサーバの処理を示すフロー図である。 図２０は、各実施の形態の変形例におけるサーバの構成を模式的に示すブロック図である。 図２１は、ブロックチェーンのデータ構造を示す説明図である。 図２２は、トランザクションデータのデータ構造を示す説明図である。
　（本発明の基礎となった知見）
　本発明者は、「背景技術」の欄において記載した、クラウドファンディングに関する技術に関し、以下の問題が生じることを見出した。
　クラウドファンディングは、インターネット上において、プロジェクト（例えば、新しいコンテンツを作成して提供すること）に対して１以上の者（支援者ともいう）から提供された資金を、コンテンツ提供者に提供する仕組みである。この仕組みによって、コンテンツ提供者は、プロジェクトに係る資金調達をすることができる。
　クラウドファンディングの普及を促進することを目的とした情報処理装置が提案されている（特許文献１参照）。特許文献１に記載された技術は、クラウドファンディングをライブ会場で行うことで、クラウドファンディングの普及を促進し得る技術である。
　しかしながら、クラウドファンディングにおいて、資金調達を不正に妨げたり、調達された資金を不正に取得したりする行為がなされ得るという問題がある。具体的には、支援者が資金を提供する意思を提示した後にその意思を撤回することによって、資金調達を不正に妨げる行為がなされ得る。また、提供された資金に関する情報を改ざんすることによって、提供された資金の一部または全部を悪意者が不正に取得する行為がなされ得る。
　そこで、本発明は、クラウドファンディングにおける資金調達を適切に管理する制御方法などを提供する。
　このような問題を解決するために、本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する。
　上記態様によれば、サーバは、クラウドファンディングにおけるトークンの支払処理に関する情報をトランザクションデータとして分散台帳に格納する。分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、クラウドファンディングにおけるトークンの支払処理に関する情報が適切に管理される。また、クラウドファンディングの目標条件が満たされたか否かの判定がスマートコントラクトによりなされるので、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記目標条件が満たされたか否かの判定は、前記クラウドファンディングの募集期間が終了したときに、前記募集期間中に受信した前記トランザクションデータに係る前記支払処理によって支払われたトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされてもよい。
　上記態様によれば、サーバは、クラウドファンディングの予め定められた募集期間が終了したときに、支払処理によって支払われたトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記目標条件が満たされたか否かの判定は、前記トランザクションデータの受信をしたときに、前記受信以前に受信した前記トランザクションデータに係る前記支払処理によって支払われたトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされてもよい。
　上記態様によれば、サーバは、支払処理に係るトランザクションデータを受信したときに、支払処理によって支払われたトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記目標条件が満たされないと判定した場合には、さらに、前記判定の結果を示す情報に基づいて、前記支払処理によって前記管理口座に支払われたトークンを、前記管理口座から前記１以上の申込者それぞれへ払い戻す払戻処理に関するトランザクションデータを生成し、生成した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納してもよい。
　上記態様によれば、サーバは、クラウドファンディングの目標条件が満たされなかった場合には、トークンの払戻処理もスマートコントラクトにより実行する。よって、トークンの払戻処理も、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記支払処理に関する前記トランザクションデータは、前記１以上の申込者それぞれが支払うべきトークンの所定量を含み、前記支払処理は、前記所定量のトークンを、前記１以上の申込者それぞれが支払う処理であってもよい。
　上記態様によれば、サーバは、予め定められた量のトークンを１以上の申込者それぞれが支払う支払処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記支払処理は、前記１以上の申込者それぞれが指定する指定量のトークンを支払う処理であり、前記制御方法は、さらに、前記支払処理の後に、前記指定量のトークンから、前記クラウドファンディングの目標額を前記１以上の申込者で按分した量のトークンを差し引いた量のトークンを、前記１以上の申込者それぞれに払い戻す払戻処理を含んでもよい。
　上記態様によれば、サーバは、予め定められた量のトークンを１以上の申込者で按分した量のトークンを、１以上の申込者それぞれが支払う支払処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記払戻処理において、前記クラウドファンディングの目標額を前記１以上の申込者で按分した量のトークンが、前記１以上の申込者のうちの一の申込者の前記支払処理によって支払われた前記トークンの量を超える場合には、前記１以上の申込者から前記一の申込者を除外して、前記クラウドファンディングの目標額を前記１以上の申込者で按分してもよい。
　上記態様によれば、申込者それぞれが指定した指定量を超えないように申込者の支払額が決定される。よって、本発明に係る制御方法は、クラウドファンディングにおいて、上限を超えない範囲に支払額を収めながら、資金調達を適切に管理することができる。
　例えば、さらに、前記クラウドファンディングの募集者の端末が、前記スマートコントラクトに係るコードを生成し、生成した前記コードを含めたトランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納してもよい。
　上記態様によれば、目標条件が満たされたか否かの判定処理に用いられるスマートコントラクトのコントラクトコードが、募集者によって生成され得る。よって、募集者の意図を反映したコントラクトコードが生成されることで、募集者の意図をより一層反映した条件判断がなされ得る。よって、本発明に係る制御方法は、募集者の意図をより一層反映可能としながら、クラウドファンディングにおける資金調達を適切に管理することができる。
　例えば、前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納してもよい。
　上記態様によれば、サーバは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、コンセンサスアルゴリズムの実行を得ることによって、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、本発明の一態様に係るプログラムは、分散台帳を保有している複数のサーバを備えるファンド管理システムであって、クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する処理部と、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する制御部とを備える。
　上記態様により、上記制御方法と同様の効果を奏する。
　また、本発明の一態様に係るプログラムは、上記の制御方法をコンピュータに実行させるためのプログラムである。
　上記態様により、上記制御方法と同様の効果を奏する。
　また、本発明の一態様に係るデータ構造は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて用いられるデータ構造であって、クラウドファンディングのプロジェクトを一意に特定し得る識別情報と、前記プロジェクトにおいてトークンを支払う申込者の口座の識別子と、前記プロジェクトにおいてトークンの支払いを受ける管理口座の識別子と、前記プロジェクトにおいて申込者が支払うトークンの量を示す情報と、前記申込者の電子署名とを含む。
　上記態様により、上記ファンド管理システムと同様の効果を奏する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態について、図面を参照しながら具体的に説明する。
　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
　（実施の形態１）
　本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて説明する。なお、ファンドにおける資金調達の単位をプロジェクトともいう。プロジェクトは、コンテンツの提供に係るプロジェクトであることが想定される。プロジェクトについて、コンテンツを提供する者を提供者といい、そのコンテンツについての資金提供の募集をする者を募集者といい、資金提供を申し込む者を申込者という。一のプロジェクトは、当該一のプロジェクトについて定められた募集期間中に、定められた目標額の資金提供の申し込みを受けることができた場合に「成立する」と表現する。
　図１は、本実施の形態におけるファンド管理システム１の構成を模式的に示すブロック図である。
　図１に示されるように、ファンド管理システム１は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１、５０および５１とを備える。ファンド管理システム１が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいう。
　サーバ１０Ａは、ファンド管理システム１によって行われるクラウドファンディングを管理する複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、クラウドファンディングにおける募集、支払および払戻に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、クラウドファンディングにおける募集、支払および払戻を受け付ける。なお、プロジェクトにおける資金提供は、一例として、分散台帳により、トークンの提供として管理される。
　サーバ１０Ｂ及び１０Ｃは、それぞれ、サーバ１０Ａと同じ機能を有する装置であり、サーバ１０Ａとは独立に動作する。なお、サーバの台数は、３に限られず、複数であればよい。また、サーバ１０Ａ等同士は、通信可能に接続されており、ネットワークＮを介して接続されていてもよい。
　端末４０は、提供者が保有する端末装置である。提供者が提供するコンテンツは、例えば、動画、静止画、音楽、又は、ソフトウェア（アプリケーションソフトウェアを含む）などの電子データである。提供者が提供するコンテンツは、提供者が作成したものであることが想定され、この場合を説明するがこれに限定されない。端末４０は、プロジェクトが成立した場合に、当該プロジェクトに係るコンテンツを申込者に提供する。端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
　端末４１は、クラウドファンディングのプロジェクトの募集者が保有する端末装置である。募集者は、申込者による資金提供の申し込みの合計額が、プロジェクトの目標額に達するように、申込者による資金提供を募集する。なお、募集者は、提供者と同一の者であってもよいし、申込者と同一の者であってもよいし、提供者及び募集者と異なる者であってもよい。端末４１は、資金提供の募集をする際には、資金提供の募集に関する情報を含むトランザクションデータ（募集トランザクションデータともいう）を生成し、生成した募集トランザクションデータをサーバ１０Ａなどに送信する。
　端末５０は、申込者が保有する端末装置である。申込者は、資金提供の募集に関する情報を参照し、資金を提供する。その後、プロジェクトが成立した場合には、提供された資金が提供者に渡る。一方、プロジェクトが成立しなかった場合には、提供された資金が申込者に払い戻される。
　端末５０は、資金を提供する際には、資金の支払のためのトランザクションデータ（支払トランザクションデータ）を生成し、生成した支払トランザクションデータをサーバ１０Ａに送信する。プロジェクトが成立すると、端末５０は、提供者が提供するコンテンツを取得する。その後、申込者は、コンテンツを利用することができる。
　端末５１は、ファンドの申込者であって、端末５０を保有する申込者とは異なる申込者が保有する端末装置である。端末５１は、端末５０と同じ機能を有する装置であり、端末５０とは独立に動作する。なお、申込者が保有する端末の台数は、２に限られず、申込者の人数と同じ数だけ存在する。
　以降において、ファンド管理システム１が備えるサーバ１０Ａ等の構成について詳細に説明する。
　図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。
　図２に示されるように、サーバ１０Ａは、処理部１１と、台帳管理部１２と、制御部１３とを備える。サーバ１０Ａが備える上記機能部は、例えばＣＰＵがメモリを用いてプログラムを実行することで実現され得る。
　処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、ファンド管理システム１内の装置からトランザクションデータを受信した、又は、制御部１３が生成したトランザクションデータを取得した場合に、受信又は取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、募集トランザクションデータ、支払トランザクションデータおよび払戻トランザクションデータが含まれる。各トランザクションデータについては後で詳しく説明する。
　台帳管理部１２は、分散台帳を管理している処理部である。台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記トランザクションデータが改ざんされないように管理されている。
　台帳管理部１２は、格納部１５と、台帳記憶部１６とを有する。
　格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、分散台帳の種別に応じた方式で新しいトランザクションデータを台帳記憶部１６に格納する。また、格納部１５は、サーバ１０Ａ等のうちの他のサーバの格納部１５と通信データを送受信し、他のサーバの台帳記憶部１６にも上記新しいトランザクションデータを格納させる。例えば、格納部１５は、分散台帳がブロックチェーンである場合には、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとったうえで、上記ブロックを台帳記憶部１６に格納する。
　台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータを記憶しており、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている（後述）。
　なお、分散台帳は、例えばブロックチェーンであり、この場合を例として説明するが、他の方式の分散台帳（例えば、ＩＯＴＡ又はハッシュグラフ等）を採用することも可能である。なお、分散台帳は、新しいデータの格納の際にコンセンサスアルゴリズム（例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）、ＰｏＷ（Ｐｒｏｏｆ　ｏｆ　Ｗｏｒｋ）又はＰｏＳ（Ｐｒｏｏｆ　ｏｆ　Ｓｔａｋｅ））を実行するものであってもよいし、実行しないものであってもよい。コンセンサスアルゴリズムを実行しない分散台帳技術の一例としてＨｙｐｅｒｌｅｄｇｅｒ　ｆａｂｒｉｃがある。
　制御部１３は、クラウドファンディングのプロジェクトの成否を判定し、資金の提供を制御する処理部である。制御部１３は、クラウドファンディングの目標条件を、募集トランザクションにより端末４１から受信する。また、制御部１３は、端末５０及び５１からの支払トランザクションにより、管理口座へのトークンの支払いを受ける。制御部１３は、クラウドファンディングの目標条件が満たされるか否かを判定し、その判定結果を示す情報を出力する。ここで、管理口座とは、クラウドファンディングにおいて一時的にトークンを保管することで、トークンを管理するための口座である。
　また、制御部１３は、上記判定の結果に基づいて、クラウドファンディングに係る処理を制御する。具体的には、制御部１３は、クラウドファンディングのプロジェクトが成立した場合には、各種通知などの処理をする。また、プロジェクトが成立しなかった場合には、申込者から管理口座に支払われたトークンを、管理口座から申込者に払い戻す払戻処理が行われるように制御する。
　なお、目標条件が満たされたか否かを判定するタイミングは、複数あり得る。
　例えば、目標条件が満たされたか否かの判定は、クラウドファンディングの募集期間が終了したときに、募集期間中に受信したトランザクションデータに係る支払処理によって支払われたトークンの合計が、クラウドファンディングの目標額以上であるか否かを判定することでなされる。本実施の形態では、この場合を例として説明する。
　なお、支払処理は、所定量のトークンを、１以上の申込者それぞれが支払う処理である。支払処理に用いられる支払トランザクションデータは、１以上の申込者それぞれが支払うべきトークンの所定量を含んでいる。
　なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされ得るが、これに限定されない。以降では、制御部１３の上記の処理の全部がスマートコントラクトによりなされる場合を例として説明する。
　以降において、各種トランザクションデータについて説明する。
　図３は、本実施の形態における募集トランザクションデータを模式的に示す説明図である。募集トランザクションデータは、クラウドファンディングのプロジェクトを開始する際に、募集者Ｕ２つまり端末４１によって生成され、サーバ１０Ａ等に送信される。
　図３に示されるように、募集トランザクションデータは、募集者ＩＤと、プロジェクトＩＤと、管理口座ＩＤと、提供者口座ＩＤと、募集期限と、目標額と、支払額と、コントラクトコードと、署名とを含む。
　募集者ＩＤは、当該プロジェクトについての資金提供を募集する募集者を一意に特定し得る識別子である。
　プロジェクトＩＤは、当該プロジェクトを一意に特定し得る識別子である。
　管理口座ＩＤは、クラウドファンディングの管理口座を一意に特定し得る識別子である。
　提供者口座ＩＤは、提供者の口座を一意に特定し得る識別子である。
　募集期限は、当該プロジェクトの募集期限、つまり募集期間の終期を示す情報である。
　目標額は、当該プロジェクトにおいて募集者が調達することを目標としている資金の額、つまりトークンの量を示す情報である。
　支払額は、当該プロジェクトにおいて、申込者それぞれが支払うトークンの量を示す情報である。
　コントラクトコードは、当該プロジェクトの成否の判定を行うスマートコントラクトのコードである。
　署名は、当該募集トランザクションデータを生成した装置又は人が付した電子署名である。
　図３に示される募集トランザクションデータは、募集者ＩＤが「ａａａ００１」である募集者が、プロジェクトＩＤが「ｋｄｆｊａｆｊｐｏ３４」であるプロジェクトについての資金提供の募集をするときに用いられる。このプロジェクトにおいて、管理口座ＩＤが「ｍｏａｑ６８０７９」であり、提供者の提供者口座ＩＤが「ｆｌｊａｄ４０１９」であり、募集期限が「２０１８．１０．１０　１５：００：００」であり、目標額は「１００」トークンであり、支払額は「１」トークンである。署名は、募集者の電子署名である。
　なお、図３における募集期限、目標額、および支払額などの条件は、コントラクトコード内に記載されていてもよい。また、図３において、コントラクトコードの具体的な記載は省略しているが、その処理内容については後で具体的に説明する。
　図４は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。支払トランザクションデータは、プロジェクトにおいて資金の支払いをする際に、当該支払いをする申込者（例えば申込者Ｕ３つまり端末５０）によって生成され、サーバ１０Ａ等に送信される。
　図４に示されるように、支払トランザクションデータは、申込者口座ＩＤと、プロジェクトＩＤと、管理口座ＩＤと、支払額と、送信日時と、署名とを含む。
　申込者口座ＩＤは、資金の支払いをする申込者の口座を一意に特定し得る識別子である。
　プロジェクトＩＤは、当該プロジェクトを一意に特定し得る識別子である。
　管理口座ＩＤは、クラウドファンディングの管理口座を一意に特定し得る識別子である。
　支払額は、当該支払いにおいて、申込者が管理口座に支払うトークンの量を示す情報である。
　送信日時は、当該支払トランザクションデータの送信日時を示す情報である。
　署名は、当該支払トランザクションデータを生成した装置又は人が付した電子署名である。
　図４に示される支払トランザクションデータは、申込者口座ＩＤが「ａａｂ０ａａｂ」である申込者が、プロジェクトＩＤが「ｋｄｆｊａｆｊｐｏ３４」であるプロジェクトについての資金の支払をするときに用いられる。この支払いにおいて、支払額は「１」トークンであり、この支払トランザクションデータの送信日時が「２０１８．１０．１１　０７：００：００」である。署名は、申込者の電子署名である。
　なお、図４に示される支払トランザクションデータは、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて用いられるデータ構造であって、クラウドファンディングのプロジェクトを一意に特定し得る識別情報と、前記プロジェクトにおいてトークンを支払う申込者の口座の識別子と、前記プロジェクトにおいてトークンの支払いを受ける管理口座の識別子と、前記プロジェクトにおいて申込者が支払うトークンの量を示す情報と、前記申込者の電子署名とを含むデータ構造を有するともいえる。
　図５は、本実施の形態における払戻トランザクションデータを模式的に示す説明図である。払戻トランザクションデータは、プロジェクトに係るファンドが成立しなかった場合に、管理口座から申込者への資金の払い戻しの際に、サーバ１０Ａ等により生成される。
　図５に示されるように、払戻トランザクションデータは、申込者口座ＩＤと、プロジェクトＩＤと、管理口座ＩＤと、払戻額と、送信日時と、署名とを含む。
　申込者口座ＩＤは、資金の払い戻しを受ける申込者の口座を一意に特定し得る識別子である。
　プロジェクトＩＤは、当該プロジェクトを一意に特定し得る識別子である。
　管理口座ＩＤは、クラウドファンディングの管理口座を一意に特定し得る識別子である。
　払戻額は、当該払い戻しにおいて、管理口座から申込者口座に払い戻されるトークンの量を示す情報である。
　送信日時は、当該払戻トランザクションデータの送信日時を示す情報である。
　署名は、当該払戻トランザクションデータを生成した装置又は人が付した電子署名である。
　図５に示される払戻トランザクションデータは、申込者口座ＩＤが「ａａｂ０ａａｂ」である申込者が、プロジェクトＩＤが「ｋｄｆｊａｆｊｐｏ３４」であるプロジェクトについての資金の払い戻しを受けるときに用いられる。この払い戻しにおいて、払戻額は「１」トークンであり、この払戻トランザクションデータの送信日時が「２０１８．１０．３１　００：００：００」であり、署名としてサーバ１０Ａの電子署名を有する。
　以上のように構成されたサーバ１０Ａ等の処理を説明する。
　図６は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。
　ステップＳ１０１において、処理部１１は、募集者Ｕ２つまり端末４１から募集トランザクションデータを受信したか否かを判定する。募集トランザクションデータを受信した場合（ステップＳ１０１でＹｅｓ）には、ステップＳ１０２に進み、そうでない場合（ステップＳ１０１でＮｏ）には、ステップＳ１０１を再び実行する。つまり処理部１１は、募集トランザクションデータを受信するまでステップＳ１０１で待機する。なお、募集トランザクションデータには、当該プロジェクトの目標条件の判定をするスマートコントラクトのコントラクトコードが含まれている。
　ステップＳ１０２において、処理部１１は、ステップＳ１０１で受信した募集トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記募集トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１０３において、処理部１１は、申込者Ｕ３等つまり端末４１等から支払トランザクションデータを受信したか否かを判定する。支払トランザクションデータを受信した場合（ステップＳ１０３でＹｅｓ）には、ステップＳ１０４に進み、そうでない場合（ステップＳ１０３でＮｏ）には、ステップＳ１０５に進む。
　ステップＳ１０４において、処理部１１は、ステップＳ１０３で取得した支払トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記支払トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１０５において、制御部１３は、募集期間が終了したか否かを判定する。例えば募集期間が終了したか否かは、ステップＳ１０４で格納された支払トランザクションデータに基づいて判定される。募集期間が終了したと判定した場合（ステップＳ１０５でＹｅｓ）には、ステップＳ１０６に進み、そうでない場合（ステップＳ１０５でＮｏ）には、ステップＳ１０３に進む。
　ステップＳ１０６において、制御部１３は、募集期間が終了したことを申込者Ｕ３等の端末５０等に通知する。なお、ステップＳ１０６は、実行されなくてもよい。
　ステップＳ１０７において、制御部１３は、クラウドファンディングのプロジェクトの目標条件が満たされたか否かを判定する。目標条件が満たされたか否かの判定は、ステップＳ１０１で受信した募集トランザクションデータに含まれるコントラクトコードを実行することによってなされる。目標条件が満たされたと判定された場合（ステップＳ１０７でＹｅｓ）には、ステップＳ１０８に進み、そうでない場合（ステップＳ１０７でＮｏ）には、ステップＳ１２１に進む。
　ステップＳ１０８において、制御部１３は、支払トランザクションデータを生成する。
　ステップＳ１０９において、制御部１３は、ステップＳ１０８で生成した支払トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記支払トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１１０において、制御部１３は、支払完了の通知を提供者Ｕ１つまり端末４０に送信する。端末４０は、当該通知を受信すると、提供者Ｕ１が生成したコンテンツが申込者に提供されるように制御する。
　ステップＳ１２１において、制御部１３は、払戻トランザクションデータを生成する。制御部１３が生成する払戻トランザクションデータは、管理口座から申込者へ資金を払い戻すことを示すトランザクションデータである。
　ステップＳ１２２において、制御部１３は、ステップＳ１２１で生成した払戻トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記払戻トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。
　ステップＳ１２３において、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知する。なお、ステップＳ１２１は、実行されなくてもよい。
　ステップＳ１１０又はＳ１２３のあと、図６に示される一連の処理を終了する。
　以降において、ファンド管理システム１の全体の処理を説明する。
　図７は、本実施の形態におけるファンド管理システム１全体の処理を示す第一のシーケンス図である。図７には、プロジェクトが成立した場合のファンド管理システム１全体の処理が示されている。なお、図６のフロー図と同じ処理を示すものは、図６と同じ符号を付し詳細な説明を省略する。
　ステップＳ２０１において、提供者Ｕ１の端末４０は、クラウドファンディングのプロジェクトに関する条件を設定し、設定した条件を端末４１に送信する。上記条件は、募集期限、目標額、および支払額を含む。端末４１は、送信された条件を受信する。
　ステップＳ２１１において、端末４１は、ステップＳ２０１で受信した条件に基づいて、プロジェクトの目標条件の判定をするためのコントラクトコードを生成する。
　ステップＳ２１２において、端末４１は、ステップＳ２０１で受信した条件と、ステップＳ２１１で生成したコントラクトコードとを含む募集トランザクションデータ（図３参照）を生成する。また、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等に送信する。このとき、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、端末４１により送信された募集トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０１及びＳ１０２）。
　ステップＳ２２１において、端末５１は、支払トランザクションデータを生成してサーバ１０Ａ等に送信する。このとき、端末５１は、生成した支払トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、送信された支払トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０３及びＳ１０４）。また、募集期間が終了した場合には、募集期間が終了したことの通知を送信する（ステップＳ１０５及びＳ１０６）。
　そして、サーバ１０Ａ等は、目標条件が達成された場合には、管理口座から提供者への資金の支払いに係る支払トランザクションデータを生成し、分散台帳に格納する（ステップＳ１０８及びＳ１０９）。そして、支払が完了したことを端末４０に送信する（ステップＳ１１０）。
　ステップＳ２０２において、端末４０は、当該通知を受信すると、提供者が生成したコンテンツを申込者に提供する。
　なお、ステップＳ２０２での提供者から申込者へのコンテンツの提供は、目標条件が満たされたと判定された（ステップＳ１０７）あとのタイミングであれば、いつ行われてもよい。
　また、ステップＳ１０８の支払トランザクションの生成は、サーバ１０Ａと異なるサーバ１０Ｂ等または端末４１等によってなされてもよい。
　図８は、本実施の形態におけるファンド管理システム１全体の処理を示す第二のシーケンス図である。図８には、プロジェクトが成立しない場合のファンド管理システム１全体の処理が示されている。
　図８において、ステップＳ２０１からステップＳ１０７までの処理は、図７における処理と同じであり、ステップＳ１０７における判定の結果、および、それ以降の処理が図７におけるものと異なる。
　ステップＳ１０７において、サーバ１０Ａ等は、目標条件が達成されなかった場合には、管理口座から申込者への資金の払い戻しに係る払戻トランザクションデータを生成し、分散台帳に格納する（ステップＳ１２１及びＳ１２２）。そして、プロジェクトが成立しなかったことを端末４０に送信する（ステップＳ１２３）。
　なお、上記では１人の申込者が１トークンを支払う場合を例として説明したが、１人の申込者が２トークン以上を支払うようにしてもよい。その場合、目標条件として、申込者による資金提供の申し込みの合計額がプロジェクトの目標額に達することに加えて、申込者の人数が所定以上になることを課してもよい。より多くの人にコンテンツを提供するためである。
　また、提供者が悪意あるコンテンツ（例えば偽のコンテンツ）を提供することを防ぐために、申込者が申込をする前に、コンテンツのスナップショット又はプレビュー画像を提供するようにしてもよい。
　また、募集期間のうちでより早いタイミングで申し込みをした者に対して、多めの報酬を提供するようにしてもよい。ここで、報酬とは、トークンであってもよいし、提供者が作成したコンテンツがその後に利益を生んだ場合にその利益のうちのより多い割合の配分を受けることであってもよいし、コンテンツをより早く提供されることであってもよい。
　また、募集者が提供者に対してトークンを支払うようにしてもよい。
　また、ファンド管理システム１の構成は、図１のようにサーバ１０Ａ等と端末４０などとが、それぞれ単独の装置である場合を例として説明したがこれに限られない。例えば、サーバ１０Ａが存在せず、端末４０、４１、５０および５１が分散台帳を保有している構成であってもよい。また、端末５０又は５１が分散台帳を保有している構成であってもよい。言い換えれば、端末４０、４１、５０および５１のうちの一部または全部が、サーバ１０Ａなどの機能を兼ね備えていてもよい。
　以上の一連の処理によって、クラウドファンディングの条件、並びに、トークンの支払い及び払い戻しに関する情報のそれぞれが、トランザクションデータとして分散台帳に格納されるので、上記情報の改ざんが抑制される。特に、トークンの支払処理に関する情報が改ざんされることが抑制されることで、申込者が支払い後に不正にキャンセルすることが回避される。よって、ファンド管理システム１は、クラウドファンディングにおける資金調達を適切に管理することができる。
　（実施の形態２）
　本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて、実施の形態１とは異なる例を説明する。
　本実施の形態におけるファンド管理システム１の構成、サーバの構成、および各種トランザクションデータの構造は、実施の形態１におけるものと同じである（図１、図２参照）。
　本実施の形態におけるサーバ１０Ａにおいて、制御部１３は、クラウドファンディングの目標条件が満たされたか否かを判定するタイミングが、実施の形態１におけるものと異なる。
　一例として、目標条件が満たされたか否かの判定は、トランザクションデータの受信をしたときに、当該受信以前に受信したトランザクションデータに係る支払処理によって支払われたトークンの合計が、クラウドファンディングの目標額以上であるか否かを判定することでなされる。
　以降において、本実施の形態におけるサーバ１０Ａ等の処理を説明する。
　図９は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。なお、フロー図において、実施の形態１と同じ処理については、同じ符号を付し、詳細な説明を省略する。
　ステップＳ１０１からＳ１０４において、処理部１１は、募集トランザクションデータおよび支払トランザクションデータを受信して分散台帳に格納する。
　ステップＳ１３１において、制御部１３は、クラウドファンディングの目標条件が満たされたか否かを判定する。目標条件が満たされたか否かの判定は、ステップＳ１０１で受信した募集トランザクションデータに含まれるコントラクトコードを実行することによってなされる。例えば目標条件が満たされたか否かは、ステップＳ１０４で格納された支払トランザクションデータに基づいて判定される。目標条件が満たされたと判定された場合（ステップＳ１３１でＹｅｓ）には、ステップＳ１３２に進み、そうでない場合（ステップＳ１３１でＮｏ）には、ステップＳ１４１に進む。
　ステップＳ１３２において、処理部１１は、募集期間が終了したことを申込者Ｕ３等の端末５０等に通知する。なお、ステップＳ１３２は、実行されなくてもよい。その後、制御部１３によって提供者への資金の支払いに関する処理がなされ（ステップＳ１０８～Ｓ１１０）、図９に示される一連の処理を終了する。
　ステップＳ１４１において、制御部１３は、募集期間が終了したか否かを判定する。募集期間が終了したと判定した場合（ステップＳ１４１でＹｅｓ）には、ステップＳ１４２に進み、そうでない場合（ステップＳ１４１でＮｏ）には、ステップＳ１０３に進む。
　ステップＳ１４２において、制御部１３は、募集期間が終了したことを申込者の端末に通知する。なお、ステップＳ１４２は、実行されなくてもよい。その後、制御部１３は、申込者への資金の払い戻しに関する処理（ステップＳ１２１～Ｓ１２２）を実行する。また、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知し（ステップＳ１２３）、図９に示される一連の処理を終了する。
　図１０は、本実施の形態におけるファンド管理システム１全体の処理を示す第一のシーケンス図である。図１０に示されるシーケンス図は、募集期間中に目標条件が満たされた場合を示したものである。
　ステップＳ２０１からＳ１０４までの処理は、実施の形態１における処理と同じである（図７参照）。
　制御部１３は、ステップＳ１０４で支払トランザクションデータを分散台帳に格納するたびに、目標条件が満たされたか否かを判定する。目標条件が満たされない場合、再び支払トランザクションデータを受信するまで待機する。目標条件が満たされた場合、申込者Ｕ３等の端末５０等に通知をする。
　その後、実施の形態１と同様に、ステップＳ１０８からＳ２０２までの処理を実行する。
　なお、ステップＳ１０８の支払トランザクションデータの生成は、サーバ１０Ａと異なるサーバ１０Ｂ等または端末４１等によってなされてもよい。
　図１１は、本実施の形態におけるファンド管理システム１全体の処理を示す第二のシーケンス図である。図１１に示されるシーケンス図は、募集期間中に目標条件が満たされない場合を示したものである。
　ステップＳ２０１からＳ１０４までの処理は、実施の形態１における処理と同じである（図７参照）。
　制御部１３は、ステップＳ１０４で支払トランザクションデータを分散台帳に格納するたびに、目標条件が満たされたか否かを判定する。そして、目標条件が満たされず、かつ、募集期間が終了した場合、申込者への資金の払い戻しに関する処理（ステップＳ１２１～Ｓ１２２）を実行し、また、プロジェクトが不成立となったことを通知する（ステップＳ１２３）。
　なお、ステップＳ１２１の払戻トランザクションデータの生成は、サーバ１０Ａと異なるサーバ１０Ｂ等または端末４１等によってなされてもよい。
　このようにすることによって、募集期間の期間中に目標条件が満たされた場合には、募集を終了して支払処理がなされる（図１０参照）。よって、提供者は、予め定められた募集期間の終了を待たずに、支払いを受けることができる。
　一方、募集期間の期間中に目標条件が満たされない場合には、実施の形態１と同様に、提供者への支払いがなされない結果となる（図１１参照）。
　（実施の形態３）
　本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて、実施の形態１及び２とは異なる形態について説明する。
　具体的には、本実施の形態に係るファンド管理システムが管理するクラウドファンディングのプロジェクトでは、募集期間の当初には、目標額が予め定められていて、かつ、申込者１人当たりの支払額が決定していないとする。ファンド管理システムは、申込者が指定量のトークンの支払処理をした後に、指定量のトークンから、目標額を１以上の申込者で按分した量のトークンを差し引いた量のトークンを申込者それぞれに払い戻す払戻処理を含む。ここで、指定量とは、申込者それぞれが指定したトークンの量であって、当該申込者が支払うことが可能であるトークンの量の上限である。本実施の形態に係るファンド管理システムは、このような形態のプロジェクトを管理する。
　本実施の形態のプロジェクトでは、申込者がトークンの支払いをした後に、申込者１人あたりの支払額が決定するとき、各申込者の支払額が指定量を超えないように制御される。そのため、支払いをした申込者すべてが資金を支払うとは限らない。申込者のうち、最終的に提供者に渡る資金を支払うことになる申込者を支払者ともいう。なお、申込者が支払い処理によって支払った額を払込額ともいう。
　例えば、払戻処理において、目標額を申込者で按分した量のトークンが、申込者のうちの一の申込者の支払処理によって支払われたトークンの量を超える場合には、申込者から上記一の申込者を除外して、目標額を申込者で按分する。
　以降において、本実施の形態において用いられる募集トランザクションデータおよび支払トランザクションデータについて説明する。
　図１２は、本実施の形態における募集トランザクションデータを模式的に示す説明図である。
　図１２に示されるように、募集トランザクションデータは、募集者ＩＤと、プロジェクトＩＤと、管理口座ＩＤと、提供者口座ＩＤと、募集期限と、目標額と、コントラクトコードと、署名とを含む。
　図１２に示される募集トランザクションデータは、実施の形態１における募集トランザクションデータ（図３参照）における支払額を含まない点で、実施の形態１におけるものと異なる。申込者１人当たりの支払額が、募集期間中には決定していないからである。
　また、本実施の形態における支払トランザクションデータ（不図示）における支払額は、申込者が指定する、当該申込者が支払うことが可能であるトークンの量の上限値である。上記支払額が払込額に相当する。
　図１３は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。
　本実施の形態におけるファンド管理システム１の構成、サーバの構成、および各種トランザクションデータの構造は、実施の形態１におけるものと同じである（図１、図２参照）。
　本実施の形態におけるサーバ１０Ａにおいて、制御部１３は、支払額を決定する処理などが実施の形態１におけるものと異なる。
　以降において、本実施の形態におけるサーバ１０Ａ等の処理を説明する。
　ステップＳ１０１からＳ１０７までの処理は、実施の形態１におけるものと同じである（図６参照）。
　ステップＳ１５１において、制御部１３は、支払額と支払者とを決定する。ここで、支払者は、ステップＳ１０３で受信した支払トランザクションデータを送信した申込者のうちから、決定アルゴリズムにより定められる。支払者と支払額との決定アルゴリズムについては、さまざまな方法があり得るが、その一例を後で詳細に説明する。
　ステップＳ１５２において、制御部１３は、支払いが成立するか否かを判定する。支払いが成立するか否かは、ステップＳ１５１における支払者と支払額との決定アルゴリズムの実行の結果として得られる、「支払いが成立する」又は「支払いが成立しない」との結果情報に基づいて判定され得る。支払が成立すると判定した場合（ステップＳ１５２でＹｅｓ）には、ステップＳ１５３に進み、そうでない場合（ステップＳ１５２でＮｏ）には、ステップＳ１６１に進む。
　ステップＳ１５３において、制御部１３は、払戻額を算出する。払戻額とは、払込額から、目標額を１以上の申込者で按分した量のトークンを差し引いた量である。
　ステップＳ１５４において、制御部１３は、ステップＳ１５３で算出した払戻額を申込者に払い戻す払戻トランザクションを生成する。
　ステップＳ１５５において、制御部１３は、ステップＳ１５４で生成した払戻トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記払戻トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。その後、実施の形態１と同様に、制御部１３は、支払完了の通知を提供者Ｕ１つまり端末４０に送信する（ステップＳ１１０）。
　ステップＳ１６１において、制御部１３は、ステップＳ１０３で各申込者から受信した支払トランザクションデータにより支払われたトークンの全額を申込者に払い戻す払戻トランザクションを生成する。
　ステップＳ１６２において、制御部１３は、ステップＳ１６１で生成した払戻トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記払戻トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。その後、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知してもよい（ステップＳ１２３）。
　次に、各申込者から提供者への支払における、支払者と支払額との決定アルゴリズムの一例を説明する。
　図１４は、本実施の形態における制御部１３による支払額の決定アルゴリズムを示すフロー図である。図１４に示されるフロー図は、図１３のステップＳ１５１に含まれる処理の一例である。
　ステップＳ３０１において、制御部１３は、各申込者から提供者への支払額を決定する。例えば、制御部１３は、目標額を申込者で按分することで、申込者１人あたりの支払額を決定する。
　ステップＳ３０２において、制御部１３は、申込者それぞれについて、ステップＳ３０１で決定された支払額と、当該申込者の払込額とを比較する。そして、制御部１３は、支払額が払込額より大きい申込者が存在するか否かを判定する。支払額が払込額より大きい申込者が存在すると判定した場合（ステップＳ３０２でＹｅｓ）には、ステップＳ３０３に進み、そうでない場合（ステップＳ３０２でＮｏ）には、「支払いが成立する」という結果情報をもって図１４に示された一連の処理を終了する。
　ステップＳ３０３において、制御部１３は、支払額が払込額より大きい申込者を除外する。
　ステップＳ３０４において、制御部１３は、申込者が存在するか否かを判定する。つまり、ステップＳ３０３で行う除外の処理のあとに、申込者が少なくとも１人は存在するか否かを判定する。申込者が存在すると判定した場合（ステップＳ３０４でＹｅｓ）には、除外のあとの申込者を対象としてステップＳ３０１の処理を実行し、そうでない場合（ステップＳ３０４でＮｏ）には、「支払いが成立しない」という結果情報をもって図１４に示された一連の処理を終了する。
　このように、制御部１３は、最初の１以上の申込者のうち、払込額を超えた申込者を除外することを繰り返しながら、すべての申込者の支払額が払込額以下になるように、各申込者の支払額を決定する。
　決定アルゴリズムの実行の具体例を説明する。
　図１５は、本実施の形態における申込者の払込額の一例を示す説明図である。図１６は、本実施の形態における制御部１３による支払額の決定アルゴリズムの実行の経過および結果の一例を示す説明図である。
　ここでは、図１５に示される申込者Ａ、Ｂ、Ｃ、Ｄ、ＥおよびＦ（申込者Ａ～Ｆともいう）が存在するときに、どの申込者が最終的に支払いを行うことになるかを、決定アルゴリズムの実行の経過とともに説明する。なお、申込者Ａ～Ｆそれぞれの払込額は、図１５に示される通り、１０、５、２０、２４、１００および６０である。なお、以降の説明において、ステップＳ３０１からＳ３０４の処理をはじめて実行することを１ターン目ともいい、上記処理の２回目の実行を２ターン目ともいう。３ターン目以降も同様である。
　図１６の（１）に示されるように、１ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が約１７トークンと算出される。この１７トークンという値は、申込者Ａ及びＢの払込額より大きいので、申込者Ａ及びＢが除外され（ステップＳ３０３）、申込者Ｃ、Ｄ、ＥおよびＦが存在している状態になる。
　次に、図１６の（２）に示されるように、２ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が２５トークンと算出される。この２５トークンという値は、申込者Ｃ及びＤの払込額より大きいので、申込者Ｃ及びＤが除外され（ステップＳ３０３）、申込者ＥおよびＦが存在している状態になる。
　次に、図１６の（３）に示されるように、３ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が５０トークンと算出される。この５０トークンという値は、申込者Ｅ及びＦの払込額以下であるので、最終的に、申込者Ｅ及びＦが支払者となる。
　図１７は、本実施の形態におけるファンド管理システム１全体の処理を示す第一のシーケンス図である。図１７には、支払が成立した場合のファンド管理システム１全体の処理が示されている。
　ステップＳ２０１からＳ１０７までの処理は、実施の形態１における処理と同じである（図７参照）。
　制御部１３は、目標条件が満たされた場合（ステップＳ１０７でＹｅｓ）、支払額と支払者とを決定し、その支払いが成立する場合（ステップＳ１５１、Ｓ１５２）に、申込者ごとの払戻額を算出し、払戻処理を実行する（ステップＳ１５４、Ｓ１５５）。その後、実施の形態１と同様に、ステップＳ１１０からＳ２０２までの処理を実行する。
　なお、ステップＳ１５４の払戻トランザクションの生成は、サーバ１０Ａと異なるサーバ１０Ｂ等または端末４１等によってなされてもよい。
　図１８は、本実施の形態におけるファンド管理システム１全体の処理を示す第二のシーケンス図である。図１８には、支払が成立しなかった場合のファンド管理システム１全体の処理が示されている。
　ステップＳ２０１からＳ１０７までの処理は、実施の形態１における処理と同じである（図７参照）。
　制御部１３は、目標条件が満たされた場合（ステップＳ１０７でＹｅｓ）、支払額と支払者とを決定し、その支払いが成立しない場合（ステップＳ１５１、Ｓ１５２）に、申込者に全額を払い戻す払戻処理を実行する（ステップＳ１６１、Ｓ１６２）。その後、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知してもよい（ステップＳ１２３）。
　なお、ステップＳ１６１の払戻トランザクションの生成は、サーバ１０Ａと異なるサーバ１０Ｂ等または端末４１等によってなされてもよい。
　（各実施の形態の変形例）
　なお、上記各実施の形態のファンド管理システムの制御方法は、以下のようにも記載され得るが、これに限定されない。
　図１９は、各実施の形態の変形例におけるサーバの処理（サーバの制御方法ともいう）を示すフロー図である。
　図１９に示される一連の処理は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法である。
　図１９に示されるように、ステップＳ６０１において、クラウドファンディングの１以上の申込者から募集者へのトークンの支払処理に関するトランザクションデータを受信し、受信したトランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。
　ステップＳ６０２において、クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定する。
　ステップＳ６０３において、判定の結果を示す情報を出力する。
　図２０は、各実施の形態の変形例におけるファンド管理システムの構成を模式的に示すブロック図である。
　図２０に示されるファンド管理システム２は、分散台帳を保有している複数のサーバ６０Ａ、６０Ｂおよび６０Ｃを備える。
　ファンド管理システム２は、処理部６１と、制御部６３とを備える。
　処理部６１は、クラウドファンディングの１以上の申込者から募集者へのトークンの支払処理に関するトランザクションデータを受信し、受信したトランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。
　制御部６３は、クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、判定の結果を示す情報を出力する。
　これにより、クラウドファンディングにおける資金調達を適切に管理することができる。
　上記各実施の形態、又は、変形例におけるブロックチェーンについて補足的に説明する。
　図２１は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。
　図２２は、トランザクションデータのデータ構造を示す説明図である。
　図２２に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。
　トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。
　以上のように、上記の実施の形態のサーバは、クラウドファンディングにおけるトークンの支払処理に関する情報をトランザクションデータとして分散台帳に格納する。分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、クラウドファンディングにおけるトークンの支払処理に関する情報が適切に管理される。また、クラウドファンディングの目標条件が満たされたか否かの判定がスマートコントラクトによりなされるので、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、クラウドファンディングの予め定められた募集期間が終了したときに、支払処理によって支払われたトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、支払処理に係るトランザクションデータを受信したときに、支払処理によって支払われたトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、クラウドファンディングの目標条件が満たされなかった場合には、トークンの払戻処理もスマートコントラクトにより実行する。よって、トークンの払戻処理も、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、予め定められた量のトークンを１以上の申込者それぞれが支払う支払処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、予め定められた量のトークンを１以上の申込者で按分した量のトークンを、１以上の申込者それぞれが支払う支払処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、申込者それぞれが指定した指定量を超えないように申込者の支払額が決定される。よって、本発明に係る制御方法は、クラウドファンディングにおいて、上限を超えない範囲に支払額を収めながら、資金調達を適切に管理することができる。
　また、目標条件が満たされたか否かの判定処理に用いられるスマートコントラクトのコントラクトコードが、募集者によって生成され得る。よって、募集者の意図を反映したコントラクトコードが生成されることで、募集者の意図をより一層反映した条件判断がなされ得る。よって、本発明に係る制御方法は、募集者の意図をより一層反映可能としながら、クラウドファンディングにおける資金調達を適切に管理することができる。
　また、サーバは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、コンセンサスアルゴリズムの実行を得ることによって、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のコンテンツ管理システムなどを実現するソフトウェアは、次のようなプログラムである。
　すなわち、このプログラムは、コンピュータに、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する制御方法を実行させるプログラムである。
　以上、一つまたは複数の態様に係るファンド管理システムなどについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
　本発明は、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムに利用可能である。
　１、２　　ファンド管理システム
　１０Ａ、１０Ｂ、１０Ｃ、６０Ａ、６０Ｂ、６０Ｃ　　サーバ
　１１、６１　　処理部
　１２　　台帳管理部
　１３、６３　　制御部
　１５　　格納部
　１６　　台帳記憶部
　４０、４１、５０、５１　　端末
　Ｂ１、Ｂ２、Ｂ３　　ブロック
　Ｎ　　ネットワーク
　Ｐ１　　トランザクション本体
　Ｐ２　　電子署名
　Ｕ１　　提供者
　Ｕ２　　募集者
　Ｕ３、Ｕ４　　申込者

Claims (12)

  1. 　分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、
    　クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、
    　前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、
    　前記判定の結果を示す情報を出力する
    　制御方法。
  2. 　前記目標条件が満たされたか否かの判定は、
    　前記クラウドファンディングの募集期間が終了したときに、前記募集期間中に受信した前記トランザクションデータに係る前記支払処理によって支払われたトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされる
    　請求項１に記載の制御方法。
  3. 　前記目標条件が満たされたか否かの判定は、
    　前記トランザクションデータの受信をしたときに、前記受信以前に受信した前記トランザクションデータに係る前記支払処理によって支払われたトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされる
    　請求項１に記載の制御方法。
  4. 　前記目標条件が満たされないと判定した場合には、さらに、
    　前記判定の結果を示す情報に基づいて、前記支払処理によって前記管理口座に支払われたトークンを、前記管理口座から前記１以上の申込者それぞれへ払い戻す払戻処理に関するトランザクションデータを生成し、
    　生成した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する
    　請求項１～３のいずれか１項に記載の制御方法。
  5. 　前記支払処理に関する前記トランザクションデータは、前記１以上の申込者それぞれが支払うべきトークンの所定量を含み、
    　前記支払処理は、
    　前記所定量のトークンを、前記１以上の申込者それぞれが支払う処理である
    　請求項１～４のいずれか１項に記載の制御方法。
  6. 　前記支払処理は、
    　前記１以上の申込者それぞれが指定する指定量のトークンを支払う処理であり、
    　前記制御方法は、さらに、
    　前記支払処理の後に、前記指定量のトークンから、前記クラウドファンディングの目標額を前記１以上の申込者で按分した量のトークンを差し引いた量のトークンを、前記１以上の申込者それぞれに払い戻す払戻処理を含む
    　請求項１～４のいずれか１項に記載の制御方法。
  7. 　前記払戻処理において、
    　前記クラウドファンディングの目標額を前記１以上の申込者で按分した量のトークンが、前記１以上の申込者のうちの一の申込者の前記支払処理によって支払われた前記トークンの量を超える場合には、前記１以上の申込者から前記一の申込者を除外して、前記クラウドファンディングの目標額を前記１以上の申込者で按分する
    　請求項６に記載の制御方法。
  8. 　さらに、
    　前記クラウドファンディングの募集者の端末が、前記スマートコントラクトに係るコードを生成し、
    　生成した前記コードを含めたトランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する
    　請求項１～７のいずれか１項に記載の制御方法。
  9. 　前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納する
    　請求項１～８のいずれか１項に記載の制御方法。
  10. 　分散台帳を保有している複数のサーバを備えるファンド管理システムであって、
    　クラウドファンディングの１以上の申込者から管理口座へのトークンの支払処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する処理部と、
    　前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する制御部とを備える
    　ファンド管理システム。
  11. 　請求項１～９のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。
  12. 　分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて用いられるデータ構造であって、
    　クラウドファンディングのプロジェクトを一意に特定し得る識別情報と、
    　前記プロジェクトにおいてトークンを支払う申込者の口座の識別子と、
    　前記プロジェクトにおいてトークンの支払いを受ける管理口座の識別子と、
    　前記プロジェクトにおいて申込者が支払うトークンの量を示す情報と、
    　前記申込者の電子署名とを含む
    　データ構造。
PCT/JP2019/041227 2018-10-22 2019-10-18 制御方法、ファンド管理システム、プログラム、及び、データ構造 WO2020085266A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201980046642.6A CN112449706A (zh) 2018-10-22 2019-10-18 控制方法、基金管理系统、程序及数据结构
JP2020553368A JPWO2020085266A1 (ja) 2018-10-22 2019-10-18 制御方法、ファンド管理システム、プログラム、及び、データ構造
US17/157,163 US20210142371A1 (en) 2018-10-22 2021-01-25 Control method, fund management system, recording medium, and data structure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862748616P 2018-10-22 2018-10-22
US62/748,616 2018-10-22

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/157,163 Continuation US20210142371A1 (en) 2018-10-22 2021-01-25 Control method, fund management system, recording medium, and data structure

Publications (1)

Publication Number Publication Date
WO2020085266A1 true WO2020085266A1 (ja) 2020-04-30

Family

ID=70331796

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/041227 WO2020085266A1 (ja) 2018-10-22 2019-10-18 制御方法、ファンド管理システム、プログラム、及び、データ構造

Country Status (4)

Country Link
US (1) US20210142371A1 (ja)
JP (1) JPWO2020085266A1 (ja)
CN (1) CN112449706A (ja)
WO (1) WO2020085266A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111985920A (zh) * 2020-08-20 2020-11-24 深圳市网绘科技有限公司 基于互联网的分布式记账方法
US11227282B2 (en) * 2018-08-20 2022-01-18 Probloch LLC Time-bounded activity chains with multiple authenticated agent participation bound by distributed single-source-of-truth networks that can enforce automated value transfer

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017045160A1 (zh) * 2015-09-16 2017-03-23 深圳市银信网银科技有限公司 一种数据交互处理方法、装置以及线上筹资方法
CN107306183B (zh) * 2016-04-22 2021-12-21 索尼公司 客户端、服务端、方法和身份验证系统
CN107395353B (zh) * 2017-04-24 2020-01-31 阿里巴巴集团控股有限公司 一种区块链共识方法及装置
JP2020521257A (ja) * 2017-05-18 2020-07-16 コデックス エルエルシーＣｏｄｅｘ Ｌｌｃ ブロックチェーンを使用した分散型デジタルコンテンツ配信システムおよびプロセス
WO2019127532A1 (zh) * 2017-12-29 2019-07-04 深圳前海达闼云端智能科技有限公司 基于区块链的众筹信息处理方法、装置、存储介质及电子设备
US20200160408A1 (en) * 2018-11-15 2020-05-21 Capital One Services, Llc Systems and methods for secure distributed crowdfunding

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
NIKKEI SOFTWARE ET AL.: "A blockchain that can be understood even by the liberal arts", NIKKEI SOFTWARE, vol. 20, no. 10, 24 July 2017 (2017-07-24), pages 77 - 85 *
WATANABE, ATSUSHI ET AL., FIRST BLOCKCHAIN APPLICATION: INTRODUCTION TO SMART CONTRACT DEVELOPMENT WITH ETHEREUM, 3 August 2017 (2017-08-03), pages 138 - 159 *
WATANABE, YOSUKE: "Distribution service of occupancy grid map using blockchain technology", THE 10TH FORUM ON DATA ENGINEERING AND INFORMATION MANAGEMENT (THE 16TH ANNUAL CONFERENCE OF THE DATABASE SOCIETY OF JAPAN, 6 March 2018 (2018-03-06) *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11227282B2 (en) * 2018-08-20 2022-01-18 Probloch LLC Time-bounded activity chains with multiple authenticated agent participation bound by distributed single-source-of-truth networks that can enforce automated value transfer
CN111985920A (zh) * 2020-08-20 2020-11-24 深圳市网绘科技有限公司 基于互联网的分布式记账方法
CN111985920B (zh) * 2020-08-20 2023-08-29 深圳市网绘科技有限公司 基于互联网的分布式记账方法

Also Published As

Publication number Publication date
JPWO2020085266A1 (ja) 2021-09-16
US20210142371A1 (en) 2021-05-13
CN112449706A (zh) 2021-03-05

Similar Documents

Publication Publication Date Title
JP7204231B2 (ja) 信頼度が低い、または信頼度が皆無の当事者間での価値転送を円滑化する装置、システム、または方法
CN109478997B (zh) 区块链实现的系统和方法
US20230117907A1 (en) Methods and systems for the efficient transfer of entities on a blockchain
TWI829626B (zh) 用於指定電子通訊之接收者的基於區塊鏈之方法及系統
CN108885761B (zh) 用于区块链上的安全点对点通信的方法
JP2019506074A (ja) ブロックチェーンを使用してピアツーピア分散型台帳におけるエンティティを効率的な移転のための方法およびシステム
JP2019508948A (ja) ブロックチェーンベースにおけるエンティティのセキュアな移転のための方法およびシステム
AU2016203205A1 (en) Resource transfer system
CN111309745B (zh) 虚拟资源处理方法、装置、电子设备及存储介质
CN110275925B (zh) 基于区块链的虚拟资源分配方法和装置
EP3595241A1 (en) Distributed blockchain with delayed transaction
WO2020085266A1 (ja) 制御方法、ファンド管理システム、プログラム、及び、データ構造
WO2020085267A1 (ja) 制御方法、ファンド管理システム、プログラム、及び、データ構造
JPWO2020162515A1 (ja) 制御方法、サーバ、および、プログラム
JP2020087102A (ja) プログラム及び生成装置
WO2020162573A1 (ja) 制御方法、サーバ、プログラム、および、データ構造
CN112016114A (zh) 基于加密货币的智能合约生成方法、相关设备及存储介质
US20230289779A1 (en) System and method for automatically validating users to access blockchain based applications
US20230368293A1 (en) Fiat payment based on a cryptocurrency blockchain transaction
CN115471224A (zh) 版权授权费用的支付方法及装置
WO2024054665A1 (en) Targeted blockchain transactions based on specialized non-fungible token tracking, minting, and transaction system
CN114930374A (zh) 用于在区块链上提供原子交易的方法和设备
CN118052638A (zh) 基于区块链的虚拟资源转移方法以及相关设备

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020553368

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

Country of ref document: EP

Kind code of ref document: A1