控制方法、基金管理系统、程序及数据结构

技术领域

本发明涉及控制方法、基金管理系统、程序及数据结构。

背景技术

提出了以促进众筹的普及作为目的的信息处理装置(参照专利文献1)。

在先技术文献

专利文献

专利文献1：日本特开2017－156927号公报

发明内容

发明所要解决的课题

但是，在众筹中存在如下问题：可能进行非法地妨碍资金筹措、或者非法地取得被筹措的资金的行为。

于是，本发明提供对众筹中的资金筹措恰当地进行管理的控制方法等。

用于解决课题的手段

本发明的一个方式所涉及的控制方法是在具备拥有分散账本的多个服务器的基金管理系统中由该多个服务器之中的一个服务器执行的控制方法，从众筹的1个以上的申请者接收与向管理账户的通证的支付处理相关的事务数据，将接收的所述事务数据向所述多个服务器各自具备的分散账本存放，通过智能合约来判定所述众筹的目标条件是否被满足，输出表示所述判定的结果的信息。

此外，这些概括性或者具体性的方式也可以由系统、装置、集成电路、计算机程序或者能够由计算机读取的CD－ROM等记录介质来实现，也可以由系统、装置、集成电路、计算机程序及记录介质的任意组合来实现。

发明效果

本发明的控制方法能够对众筹中的资金筹措恰当地进行管理。

附图说明

图1是示意性地表示实施方式1中的基金管理系统的构成的框图。

图2是示意性地表示实施方式1中的服务器的构成的框图。

图3是示意性地表示实施方式1中的募集事务数据的说明图。

图4是示意性地表示实施方式1中的支付事务数据的说明图。

图5是示意性地表示实施方式1中的退还事务数据的说明图。

图6是表示实施方式1中的服务器的处理的流程图。

图7是表示实施方式1中的基金管理系统整体的处理的第一时序图。

图8是表示实施方式1中的基金管理系统整体的处理的第二时序图。

图9是表示实施方式2中的服务器的处理的流程图。

图10是表示实施方式2中的基金管理系统整体的处理的第一时序图。

图11是表示实施方式2中的基金管理系统整体的处理的第二时序图。

图12是示意性地表示实施方式3中的募集事务数据的说明图。

图13是表示实施方式3中的服务器的处理的流程图。

图14是表示实施方式3中的控制部对支付额的决定算法的流程图。

图15是表示实施方式3中的申请者的支付上限额的一例的说明图。

图16是表示实施方式3中的控制部执行支付额的决定算法的经过及结果的一例的说明图。

图17是表示实施方式3中的基金管理系统整体的处理的第一时序图。

图18是表示实施方式3中的基金管理系统整体的处理的第二时序图。

图19是表示各实施方式的变形例中的服务器的处理的流程图。

图20是示意性地表示各实施方式的变形例中的服务器的构成的框图。

图21是表示区块链的数据结构的说明图。

图22是表示事务数据的数据结构的说明图。

具体实施方式

(成为本发明的基础的见识)

本发明人关于在“背景技术”部分中记载的与众筹相关的技术，发现了会发生以下的问题。

众筹是在互联网上将对于项目(例如制作并提供新的内容)从1个以上的人(也称为支援者)提供的资金向内容提供者提供的机制。通过该机制，内容提供者能够进行项目所涉及的资金筹措。

提出了以促进众筹的普及作为目的的信息处理装置(参照专利文献1)。专利文献1所记载的技术通过在现场的会场进行众筹，能够促进众筹的普及。

但是，在众筹中存在如下问题：可能进行非法地妨碍资金筹措、或者非法地取得被筹措的资金的行为。具体而言，支援者通过在提示了提供资金的意愿之后撤回该意愿，能够进行非法地妨碍资金筹措的行为。另外，通过篡改与被提供的资金相关的信息，恶意者能够进行非法地取得被提供的资金的一部分或者全部的行为。

于是，本发明提供对众筹中的资金筹措恰当地进行管理的控制方法等。

为了解决这样的问题，本发明的一个方式所涉及的控制方法是在具备拥有分散账本的多个服务器的基金管理系统中由该多个服务器之中的一个服务器执行的控制方法，从众筹的1个以上的申请者接收与向管理账户的通证的支付处理相关的事务数据，将接收的所述事务数据向所述多个服务器各自具备的分散账本存放，通过智能合约来判定所述众筹的目标条件是否被满足，输出表示所述判定的结果的信息。

根据上述方式，服务器将与众筹中的通证的支付处理相关的信息作为事务数据向分散账本存放。分散账本中存放的事务数据的篡改在实质上是不可能的，因此与众筹中的通证的支付处理相关的信息被恰当地管理。另外，众筹的目标条件是否被满足的判定通过智能合约来进行，因此不经由其他人或者其他系统，而被自动而且安全地执行。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

例如，也可以如下进行所述目标条件是否被满足的判定：在所述众筹的募集期间结束时，判定通过在所述募集期间中接收到的所述事务数据所涉及的所述支付处理而支付的通证的合计，是否为所述众筹的目标额以上。

根据上述方式，服务器在众筹的预定的募集期间结束时，对通过支付处理而支付的通证的合计与目标额进行大小比较，从而判定目标条件是否被满足，因此能够更容易地进行上述判定。因此，本发明所涉及的控制方法能够更容易地对众筹中的资金筹措恰当地进行管理。

例如，也可以如下进行所述目标条件是否被满足的判定：在进行了所述事务数据的接收时，判定通过在所述接收以前接收到的所述事务数据所涉及的所述支付处理而支付的通证的合计，是否为所述众筹的目标额以上。

根据上述方式，服务器在接收了支付处理所涉及的事务数据时，对通过支付处理而支付的通证的合计与目标额进行大小比较，从而判定目标条件是否被满足，因此能够更容易地进行上述判定。因此，本发明所涉及的控制方法能够更容易地对众筹中的资金筹措恰当地进行管理。

例如，在判定为所述目标条件未被满足的情况下，也可以进而基于表示所述判定的结果的信息，生成与将通过所述支付处理向所述管理账户支付的通证从所述管理账户向所述1个以上的申请者各自退还的退还处理相关的事务数据，并将生成的所述事务数据向所述多个服务器各自具备的分散账本存放。

根据上述方式，服务器在众筹的目标条件未被满足的情况下，通证的退还处理也通过智能合约来执行。因此，通证的退还处理也不经由其他人或者其他系统，而被自动而且安全地执行。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

例如也可以是，与所述支付处理相关的所述事务数据包含所述1个以上的申请者各自应该支付的通证的规定量，所述支付处理是所述1个以上的申请者各自支付所述规定量的通证的处理。

根据上述方式，服务器对与1个以上的申请者各自支付预定的量的通证的支付处理相关的信息恰当地进行管理。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

例如也可以是，所述支付处理是所述1个以上的申请者各自支付所指定的指定量的通证的处理，所述控制方法还包含：在所述支付处理之后，将通过将所述众筹的目标额在所述1个以上的申请者中按比例分配而得到的量的通证从所述指定量的通证中减去而得到的量的通证，向所述1个以上的申请者各自退还的退还处理。

根据上述方式，服务器对与1个以上的申请者各自支付通过将预定的量的通证在1个以上的申请者中按比例分配而得到的量的通证的支付处理相关的信息恰当地进行管理。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

例如也可以是，在所述退还处理中，在通过将所述众筹的目标额在所述1个以上的申请者中按比例分配而得到的量的通证，超过通过所述1个以上的申请者之中的一个申请者的所述支付处理而支付的所述通证的量的情况下，从所述1个以上的申请者中将所述一个申请者除外，并将所述众筹的目标额在所述1个以上的申请者中按比例分配。

根据上述方式，以不超过申请者各自所指定的指定量的方式决定申请者的支付额。因此，本发明所涉及的控制方法能够在众筹中，在不超过上限的范围内收取支付额，并且对资金筹措恰当地进行管理。

例如也可以是，进而，所述众筹的募集者的终端生成所述智能合约所涉及的码，将包含所生成的所述码的事务数据向所述多个服务器各自具备的分散账本存放。

根据上述方式，在目标条件是否被满足的判定处理中使用的智能合约的合约码能够由募集者生成。因此，通过生成反映了募集者的意图的合约码，能够进行更进一步反映了募集者的意图的条件判断。因此，本发明所涉及的控制方法能够更进一步反映募集者的意图，并且能够对众筹中的资金筹措恰当地进行管理。

例如也可以是，在将所述事务数据向所述多个服务器各自具备的分散账本存放时，经过由所述多个服务器各自执行共识算法，向所述分散账本存放。

根据上述方式，服务器经过进行共识算法的执行来存放分散账本。因此，通过经过进行共识算法的执行，能够更容易地对众筹中的资金筹措恰当地进行管理。

另外，本发明的一个方式所涉及的程序是具备拥有分散账本的多个服务器的基金管理系统，具备：处理部，从众筹的1个以上的申请者接收与向管理账户的通证的支付处理相关的事务数据，将接收的所述事务数据向所述多个服务器各自具备的分散账本存放；以及控制部，通过智能合约来判定所述众筹的目标条件是否被满足，输出表示所述判定的结果的信息。

通过上述方式，具有与上述控制方法同样的效果。

另外，本发明的一个方式所涉及的程序是用于使计算机执行上述的控制方法的程序。

通过上述方式，具有与上述控制方法同样的效果。

另外，本发明的一个方式所涉及的数据结构是在具备拥有分散账本的多个服务器的基金管理系统中使用的数据结构，包含：能够唯一地确定众筹的项目的识别信息；在所述项目中支付通证的申请者的账户的标识符；在所述项目中接受通证的支付的管理账户的标识符；表示在所述项目中申请者所支付的通证的量的信息；以及所述申请者的电子签名。

通过上述方式，具有与上述基金管理系统同样的效果。

此外，这些概括性或者具体性的方式也可以通过系统、装置、集成电路、计算机程序或者计算机可读取的CD－ROM等记录介质实现，也可以通过系统、装置、集成电路、计算机程序或者记录介质的任意组合实现。

以下，关于实施方式，参照附图具体进行说明。

此外，以下说明的实施方式均示出概括性或者具体性的例子。以下的实施方式所示的数值、形状、材料、结构要素、结构要素的配置位置及连接方式、步骤、步骤的顺序等是一例，并非意在限定本发明。此外，关于以下的实施方式中的结构要素之中表示最上位概念的独立权利要求中没有记载的结构要素，作为任意的结构要素而被说明。

(实施方式1)

在本实施方式中，关于对众筹中的资金筹措恰当地进行管理的基金管理系统及其控制方法等进行说明。此外，将基金中的资金筹措的单位也称为项目。项目被设想为内容的提供所涉及的项目。关于项目，将提供内容的人称为提供者，将进行针对该内容的资金提供的募集的人称为募集者，将申请提供资金的人称为申请者。一个项目在针对该一个项目决定的募集期间中接受了被决定的目标额的资金提供的申请的情况下，表现为“成立”。

图1是示意性地表示本实施方式中的基金管理系统1的构成的框图。

如图1所示，基金管理系统1具备服务器10A、10B及10C、以及终端40、41、50及51。基金管理系统1所具备的各装置通过网络N以能够相互通信的方式被连接。网络N由何种通信线路或者网络构成皆可，例如包含互联网、便携电话的承载网络等。将服务器10A、10B及10C也称为“服务器10A等”。

服务器10A是对由基金管理系统1进行的众筹进行管理的多个服务器10A、10B及10C之中的1个。服务器10A是拥有分散账本的多个服务器10A、10B及10C之中的1个。在服务器10A所拥有的分散账本中，存放与众筹中的募集、支付及退还相关的各种事务数据。服务器10A通过接收上述事务数据，受理众筹中的募集、支付及退还。此外，项目中的资金提供作为一例，通过分散账本作为通证的提供被管理。

服务器10B及10C各自是具有与服务器10A相同的功能的装置，与服务器10A独立地动作。此外，服务器的台数不限于3，是多个即可。另外，服务器10A等彼此以能够通信的方式被连接，也可以经由网络N被连接。

终端40是提供者所拥有的终端装置。提供者所提供的内容例如是动态图像、静止图像、音乐或者软件(包含应用软件)等的电子数据。提供者所提供的内容设想为是由提供者制作的内容，说明该情况但不限定于此。终端40在项目成立了的情况下，将该项目所涉及的内容向申请者提供。终端40例如是个人计算机、智能电话、平板电脑等。

终端41是众筹的项目的募集者所拥有的终端装置。募集者对申请者的资金提供进行募集，以使申请者的资金提供的申请的合计额达到项目的目标额。此外，募集者既可以与提供者是相同的人，也可以与申请者是相同的人，也可以是与提供者及募集者不同的人。终端41在进行资金提供的募集时，生成包含与资金提供的募集相关的信息的事务数据(也称为募集事务数据)，并将生成的募集事务数据向服务器10A等发送。

终端50是申请者所拥有的终端装置。申请者参照与资金提供的募集相关的信息，提供资金。其后，在项目成立的情况下，提供的资金被交给提供者。另一方面，在项目不成立的情况下，提供的资金被退还给申请者。

终端50在提供资金时，生成用于资金的支付的事务数据(支付事务数据)，并将生成的支付事务数据向服务器10A发送。如果项目成立，则终端50取得提供者所提供的内容。其后，申请者能够利用内容。

终端51是作为基金的申请者且与拥有终端50的申请者不同的申请者所拥有的终端装置。终端51是具有与终端50相同的功能的装置，与终端50独立地动作。此外，申请者所拥有的终端的台数不限于2，存在与申请者的人数相同的数量。

以下，针对基金管理系统1所具备的服务器10A等的构成详细地进行说明。

图2是示意性地表示本实施方式中的服务器10A的构成的框图。

如图2所示，服务器10A具备处理部11、账本管理部12和控制部13。服务器10A所具备的上述功能部例如能够通过由CPU使用存储器执行程序来实现。

处理部11是通过分散账本进行各种信息的管理的处理部。处理部11在从基金管理系统1内的装置接收了事务数据，或者取得了控制部13所生成的事务数据的情况下，将接收或者取得的事务数据向账本管理部12提供从而向分散账本存放。在事务数据中，包含募集事务数据、支付事务数据及退还事务数据。针对各事务数据在后文详细说明。

账本管理部12是管理着分散账本的处理部。账本管理部12将从处理部11提供的事务数据向分散账本存放。在分散账本中，存放从过去到当前的事务数据。基于分散账本中记录的信息难以篡改的特性，上述事务数据以不被篡改的方式被管理。

账本管理部12具有存放部15和账本存储部16。

存放部15是将应该向分散账本存放的新的事务数据向账本存储部16存放的处理部。存放部15以与分散账本的类别相应的方式将新的事务数据向账本存储部16存放。另外，存放部15与服务器10A等之中的其他服务器的存放部15收发通信数据，使其他服务器的账本存储部16也存放上述新的事务数据。例如，存放部15在分散账本是区块链的情况下，生成包含新的事务数据的区块，并对生成的区块在服务器10A等之间取得同步之后，将上述区块向账本存储部16存放。

账本存储部16是存储着分散账本的存储装置。账本存储部16中存放的分散账本存储着1个以上的事务数据，使用哈希(Hash)值等的特性以难以被篡改的方式被管理(后述)。

此外，分散账本例如是区块链，以该情况为例进行说明，但也能够采用其他方式的分散账本(例如IOTA或者哈希(Hash)图等)。此外，分散账本在存放新的数据时既可以执行也可以不执行共识算法(例如PBFT(实用拜占庭容错算法：Practical Byzantine FaultTolerance)、PoW(工作量证明：Proof of Work)或者PoS(权益证明：Proof of Stake))。作为不执行共识算法的分散账本技术的一例有超级账本结构(Hyperledger fabric)。

控制部13是判定众筹的项目的成立与否，并对资金的提供进行控制的处理部。控制部13通过募集事务从终端41接收众筹的目标条件。另外，控制部13通过来自终端50及51的支付事务，接受向管理账户的通证的支付。控制部13判定众筹的目标条件是否被满足，并输出表示该判定结果的信息。在此，管理账户是用于在众筹中临时对通证进行保管从而对通证进行管理的账户。

另外，控制部13基于上述判定的结果，对众筹所涉及的处理进行控制。具体而言，控制部13在众筹的项目成立的情况下，进行各种通知等处理。另外，在项目不成立的情况下，控制以进行将从申请者向管理账户支付的通证从管理账户向申请者退还的退还处理。

此外，判定目标条件是否被满足的定时能够有多个。

例如，如下进行目标条件是否被满足的判定：在众筹的募集期间结束时，判定通过在募集期间中接收到的事务数据所涉及的支付处理而支付的通证的合计，是否为众筹的目标额以上。在本实施方式中，以该情况为例进行说明。

此外，支付处理是1个以上的申请者各自支付规定量的通证的处理。在支付处理中使用的支付事务数据包含1个以上的申请者各自应该支付的通证的规定量。

此外，控制部13的上述的处理的一部分或者全部能够通过智能合约来进行，但不限定于此，其中智能合约通过执行账本存储部16所存储的合约码被实现。以下，以控制部13的上述的处理全部通过智能合约来进行的情况为例进行说明。

以下，针对各种事务数据进行说明。

图3是示意性地表示本实施方式中的募集事务数据的说明图。募集事务数据在开始众筹的项目时由募集者U2即终端41生成，被向服务器10A等发送。

如图3所示，募集事务数据包含募集者ID、项目ID、管理账户ID、提供者账户ID、募集期限、目标额、支付额、合约码和签名。

募集者ID是能够唯一地确定对关于该项目的资金提供进行募集的募集者的标识符。

项目ID是能够唯一地确定该项目的标识符。

管理账户ID是能够唯一地确定众筹的管理账户的标识符。

提供者账户ID是能够唯一地确定提供者的账户的标识符。

募集期限是表示该项目的募集期限、也就是说募集期间的截止期的信息。

目标额是表示该项目中募集者作为目标要筹措的资金额、也就是说通证的量的信息。

支付额是表示该项目中申请者各自支付的通证的量的信息。

合约码是用于判定该项目的成立与否的智能合约的码。

签名是生成了该募集事务数据的装置或者人所附加的电子签名。

图3所示的募集事务数据在由募集者ID为“aaa001”的募集者进行关于项目ID为“kdfjafjpo34”的项目的资金提供的募集时被使用。在该项目中，管理账户ID是“moaq68079”，提供者的提供者账户ID是“fljad4019”，募集期限是“2018.10.10 15：00：00”，目标额是“100”通证，支付额是“1”通证。签名是募集者的电子签名。

此外，图3中的募集期限、目标额及支付额等的条件也可以被记载在合约码内。另外，在图3中，省略了合约码的具体性的记载，但针对其处理内容在后文具体说明。

图4是示意性地表示本实施方式中的支付事务数据的说明图。支付事务数据在项目中进行资金的支付时，由进行该支付的申请者(例如申请者U3即终端50)生成，并被向服务器10A等发送。

如图4所示，支付事务数据包含申请者账户ID、项目ID、管理账户ID、支付额、发送日期时间和签名。

申请者账户ID是能够唯一地确定进行资金的支付的申请者的账户的标识符。

项目ID是能够唯一地确定该项目的标识符。

管理账户ID是能够唯一地确定众筹的管理账户的标识符。

支付额是表示在该支付中申请者向管理账户支付的通证的量的信息。

发送日期时间是表示该支付事务数据的发送日期时间的信息。

签名是生成了该支付事务数据的装置或者人所附加的电子签名。

图4所示的支付事务数据在申请者账户ID为“aab0aab”的申请者进行关于项目ID为“kdfjafjpo34”的项目的资金的支付时被使用。在该支付中，支付额是“1”通证，该支付事务数据的发送日期时间是“2018.10.11 07：00：00”。签名是申请者的电子签名。

此外，图4所示的支付事务数据也可以说具有如下数据结构，该数据结构在具备拥有分散账本的多个服务器的基金管理系统中被使用，包含：能够唯一地确定众筹的项目的识别信息；在所述项目中支付通证的申请者的账户的标识符；在所述项目中接受通证的支付的管理账户的标识符；表示在所述项目中申请者所支付的通证的量的信息；以及所述申请者的电子签名。

图5是示意性地表示本实施方式中的退还事务数据的说明图。退还事务数据在项目所涉及的基金不成立的情况下，在从管理账户向申请者退还资金时，由服务器10A等生成。

如图5所示，退还事务数据包含申请者账户ID、项目ID、管理账户ID、退还额、发送日期时间和签名。

申请者账户ID是能够唯一地确定接受资金的退还的申请者的账户的标识符。

项目ID是能够唯一地确定该项目的标识符。

管理账户ID是能够唯一地确定众筹的管理账户的标识符。

退还额是表示在该退还中从管理账户向申请者账户退还的通证的量的信息。

发送日期时间是表示该退还事务数据的发送日期时间的信息。

签名是生成了该退还事务数据的装置或者人所附加的电子签名。

图5所示的退还事务数据在申请者账户ID为“aab0aab”的申请者接受关于项目ID为“kdfjafjpo34”的项目的资金的退还时被使用。在该退还中，退还额是“1”通证，该退还事务数据的发送日期时间是“2018.10.31 00：00：00”，具有服务器10A的电子签名作为签名。

说明如上构成的服务器10A等的处理。

图6是表示本实施方式中的服务器10A的处理的流程图。

在步骤S101中，处理部11判定是否从募集者U2即终端41接收到募集事务数据。在接收到募集事务数据的情况下(步骤S101：是)，向步骤S102前进，否则(步骤S101：否)再次执行步骤S101。也就是说，处理部11在步骤S101中等待直到接收到募集事务数据。此外，在募集事务数据中，包含用于进行该项目的目标条件的判定的智能合约的合约码。

在步骤S102中，处理部11将在步骤S101中接收的募集事务数据向账本管理部12提供，从而向分散账本存放。另外，处理部11将上述募集事务数据向其他服务器10B等发送，使其向全部服务器10A等的分散账本存放。

在步骤S103中，处理部11判定是否从申请者U3等即终端41等接收到支付事务数据。在接收到支付事务数据的情况下(步骤S103：是)，向步骤S104前进，否则(步骤S103：否)向步骤S105前进。

在步骤S104中，处理部11将在步骤S103中取得的支付事务数据向账本管理部12提供，从而向分散账本存放。另外，处理部11将上述支付事务数据向其他服务器10B等发送，使其向全部服务器10A等的分散账本存放。

在步骤S105中，控制部13判定募集期间是否结束。例如，基于在步骤S104中存放的支付事务数据，判定募集期间是否结束。在判定为募集期间结束的情况下(步骤S105：是)，向步骤S106前进，否则(步骤S105：否)向步骤S103前进。

在步骤S106中，控制部13向申请者U3等的终端50等通知募集期间结束。此外，步骤S106也可以不被执行。

在步骤S107中，控制部13判定众筹的项目的目标条件是否被满足。目标条件是否被满足的判定，通过执行在步骤S101中接收的募集事务数据中包含的合约码来进行。在判定为目标条件被满足的情况下(步骤S107：是)，向步骤S108前进，否则(步骤S107：否)向步骤S121前进。

在步骤S108中，控制部13生成支付事务数据。

在步骤S109中，控制部13将在步骤S108中生成的支付事务数据向账本管理部12提供，从而向分散账本存放。另外，控制部13将上述支付事务数据向其他服务器10B等发送，并使其向全部服务器10A等的分散账本存放。

在步骤S110中，控制部13将支付完成的通知向提供者U1即终端40发送。终端40如果接收到该通知，则进行控制以使提供者U1所生成的内容被提供给申请者。

在步骤S121中，控制部13生成退还事务数据。控制部13所生成的退还事务数据是表示从管理账户向申请者退还资金的事务数据。

在步骤S122中，控制部13将在步骤S121中生成的退还事务数据向账本管理部12提供，从而向分散账本存放。另外，控制部13将上述退还事务数据向其他服务器10B等发送，使其向全部服务器10A等的分散账本存放。

在步骤S123中，控制部13向申请者U3即终端50等通知项目不成立。此外，步骤S121也可以不被执行。

在步骤S110或者S123之后，结束图6所示的一系列处理。

以下，说明基金管理系统1的整体的处理。

图7是表示本实施方式中的基金管理系统1整体的处理的第一时序图。在图7中，表示了项目成立的情况下的基金管理系统1整体的处理。此外，针对表示与图6的流程图相同的处理的对象，附加与图6相同的标记并省略详细的说明。

在步骤S201中，提供者U1的终端40设定与众筹的项目相关的条件，将设定的条件向终端41发送。上述条件包含募集期限、目标额及支付额。终端41接收被发送的条件。

在步骤S211中，终端41基于在步骤S201中接收的条件，生成用于进行项目的目标条件的判定的合约码。

在步骤S212中，终端41生成包含步骤S201中接收的条件以及在步骤S211中生成的合约码的募集事务数据(参照图3)。另外，终端41将生成的募集事务数据向服务器10A等发送。此时，终端41既可以将生成的募集事务数据向服务器10A等之中的1个服务器发送，也可以向多个服务器发送。

服务器10A等接收由终端41发送的募集事务数据，并向分散账本存放(步骤S101及S102)。

在步骤S221中，终端51生成支付事务数据并向服务器10A等发送。此时，终端51既可以将生成的支付事务数据向服务器10A等之中的1个服务器发送，也可以向多个服务器发送。

服务器10A等接收被发送的支付事务数据，并向分散账本存放(步骤S103及S104)。另外，在募集期间结束的情况下，发送表示募集期间结束的通知(步骤S105及S106)。

然后，服务器10A等在目标条件被达成的情况下，生成从管理账户向提供者的资金的支付所涉及的支付事务数据，并向分散账本存放(步骤S108及S109)。然后，向终端40发送支付已完成的情况(步骤S110)。

在步骤S202中，终端40如果接收到该通知，则将提供者所生成的内容提供给申请者。

此外，在步骤S202中从提供者向申请者的内容的提供，只要是在判定为目标条件被满足(步骤S107)之后的定时，则在何时执行皆可。

另外，步骤S108的支付事务的生成也可以由与服务器10A不同的服务器10B等或者终端41等进行。

图8是表示本实施方式中的基金管理系统1整体的处理的第二时序图。在图8中，表示了项目不成立的情况下的基金管理系统1整体的处理。

在图8中，步骤S201至步骤S107的处理与图7中的处理是相同的，步骤S107中的判定的结果及其后的处理与图7中的不同。

在步骤S107中，服务器10A等在目标条件未被达成的情况下，生成从管理账户向申请者的资金的退还所涉及的退还事务数据，并向分散账本存放(步骤S121及S122)。然后，向终端40发送项目未成立的情况(步骤S123)。

此外，在上述中以1位申请者支付1通证的情况为例进行了说明，但也可以设为1位申请者支付2通证以上。在该情况下，作为目标条件，也可以在申请者的资金提供的申请的合计额达到项目的目标额的基础上，还设立申请者的人数为规定以上。这是为了向更多的人提供内容。

另外，为了防止提供者提供有恶意的内容(例如假的内容)，也可以设为在申请者进行申请之前，提供内容的快照或者预览图像。

另外，也可以设为对于在募集期间之中较早的定时进行了申请的人，提供较多的报酬。在此，报酬既可以是通证，也可以是在提供者所制作的内容在其后产生了利益的情况下接受该利益之中的较多的比例的分配，也可以是较早地被提供内容。

另外，也可以设为募集者对于提供者支付通证。

另外，基金管理系统1的构成以如图1所示服务器10A等与终端40等分别是单独的装置的情况为例进行了说明，但不限于此。例如，也可以构成为：不存在服务器10A，而终端40、41、50及51拥有分散账本。另外，也可以构成为终端50或者51拥有分散账本。换言之，终端40、41、50及51之中的一部分或者全部也可以兼具服务器10A等的功能。

通过以上的一系列处理，与众筹的条件、以及通证的支付及退还相关的信息各自被作为事务数据存放于分散账本，因此抑制了上述信息的篡改。特别是，抑制了与通证的支付处理相关的信息被篡改，从而避免了申请者在支付后非法地取消。因此，基金管理系统1能够对众筹中的资金筹措恰当地进行管理。

(实施方式2)

在本实施方式中，关于对众筹中的资金筹措恰当地进行管理的基金管理系统及其控制方法等，说明与实施方式1不同的例子。

本实施方式中的基金管理系统1的构成、服务器的构成及各种事务数据的结构与实施方式1中的相同(参照图1、图2)。

在本实施方式中的服务器10A中，控制部13判定众筹的目标条件是否被满足的定时与实施方式1中的不同。

作为一例，如下进行目标条件是否被满足的判定：在进行了事务数据的接收时，判定通过在该接收以前接收到的事务数据所涉及的支付处理而支付的通证的合计，是否为众筹的目标额以上。

以下，说明本实施方式中的服务器10A等的处理。

图9是表示本实施方式中的服务器10A的处理的流程图。此外，在流程图中，针对与实施方式1相同的处理，附加相同的标记并省略详细的说明。

在步骤S101至S104中，处理部11接收募集事务数据及支付事务数据并向分散账本存放。

在步骤S131中，控制部13判定众筹的目标条件是否被满足。目标条件是否被满足的判定，通过执行在步骤S101中接收的募集事务数据中包含的合约码来进行。例如，基于在步骤S104中存放的支付事务数据，判定目标条件是否被满足。在判定为目标条件被满足的情况下(步骤S131：是)，向步骤S132前进，否则(步骤S131：否)向步骤S141前进。

在步骤S132中，处理部11向申请者U3等的终端50等通知募集期间结束。此外，步骤S132也可以不被执行。其后，由控制部13进行与向提供者的资金的支付相关的处理(步骤S108～S110)，结束图9所示的一系列处理。

在步骤S141中，控制部13判定募集期间是否结束。在判定为募集期间结束的情况下(步骤S141：是)，向步骤S142前进，否则(步骤S141：否)向步骤S103前进。

在步骤S142中，控制部13向申请者的终端通知募集期间结束。此外，步骤S142也可以不被执行。其后，控制部13执行与向申请者的资金的退还相关的处理(步骤S121～S122)。另外，控制部13向申请者U3即终端50等通知项目不成立(步骤S123)，结束图9所示的一系列处理。

图10是表示本实施方式中的基金管理系统1整体的处理的第一时序图。图10所示的时序图表示了在募集期间中目标条件被满足的情况。

步骤S201至S104的处理与实施方式1中的处理相同(参照图7)。

控制部13每次在步骤S104中将支付事务数据向分散账本存放时，判定目标条件是否被满足。在目标条件未被满足的情况下，等待直到再次接收到支付事务数据。在目标条件被满足的情况下，向申请者U3等的终端50等进行通知。

其后，与实施方式1同样，执行步骤S108至S202的处理。

此外，步骤S108的支付事务数据的生成也可以由与服务器10A不同的服务器10B等或者终端41等进行。

图11是表示本实施方式中的基金管理系统1整体的处理的第二时序图。图11所示的时序图表示了在募集期间中目标条件未被满足的情况。

步骤S201至S104的处理与实施方式1中的处理相同(参照图7)。

控制部13每次在步骤S104中将支付事务数据向分散账本存放时，判定目标条件是否被满足。然后，在目标条件未被满足，而且募集期间结束的情况下，执行与向申请者的资金的退还相关的处理(步骤S121～S122)，另外，通知项目不成立(步骤S123)。

此外，步骤S121的退还事务数据的生成也可以由与服务器10A不同的服务器10B等或者终端41等进行。

通过像这样，在募集期间的期间中目标条件被满足的情况下，结束募集并进行支付处理(参照图10)。因此，提供者不等待预定的募集期间的结束就能够接受支付。

另一方面，在募集期间的期间中目标条件未被满足的情况下，与实施方式1同样，成为不向提供者进行支付的结果(参照图11)。

(实施方式3)

在本实施方式中，关于对众筹中的资金筹措恰当地进行管理的基金管理系统及其控制方法等，针对与实施方式1及2不同的方式进行说明。

具体而言，在本实施方式所涉及的基金管理系统所管理的众筹的项目中，在募集期间的最初，预先决定了目标额，而且，没有决定申请者平均1人的支付额。基金管理系统包含：在申请者进行了指定量的通证的支付处理之后，将通过将目标额在1个以上的申请者中按比例分配而得到的量的通证从指定量的通证中减去而得到的量的通证，向申请者各自退还的退还处理。在此，指定量是指申请者各自所指定的通证的量，而且是该申请者能够支付的通证的量的上限。本实施方式所涉及的基金管理系统对这样的方式的项目进行管理。

在本实施方式的项目中，在申请者进行了通证的支付之后，在决定申请者平均1人的支付额时，控制为各申请者的支付额不超过指定量。因此，不限于进行了支付的申请者全部都支付资金。将申请者之中的最终支付交给提供者的资金的申请者也称为支付者。此外，将申请者通过支付处理而支付的金额也称为缴纳额。

例如，在退还处理中，在通过将目标额在申请者中按比例分配而得到的量的通证，超过通过申请者之中的一个申请者的支付处理而支付的通证的量的情况下，从申请者中将上述一个申请者除外，并将目标额在申请者中按比例分配。

以下，针对在本实施方式中使用的募集事务数据及支付事务数据进行说明。

图12是示意性地表示本实施方式中的募集事务数据的说明图。

如图12所示，募集事务数据包含募集者ID、项目ID、管理账户ID、提供者账户ID、募集期限、目标额、合约码和签名。

图12所示的募集事务数据不包含实施方式1中的募集事务数据(参照图3)中的支付额，这点与实施方式1中的不同。这是因为：申请者平均1人的支付额在募集期间中未被决定。

另外，本实施方式中的支付事务数据(未图示)中的支付额，是申请者所指定的该申请者能够支付的通证的量的上限值。上述支付额相当于缴纳额。

图13是表示本实施方式中的服务器10A的处理的流程图。

本实施方式中的基金管理系统1的构成、服务器的构成及各种事务数据的结构与实施方式1中的相同(参照图1、图2)。

在本实施方式中的服务器10A中，控制部13决定支付额的处理等与实施方式1中的不同。

以下，说明本实施方式中的服务器10A等的处理。

步骤S101至S107的处理与实施方式1中的相同(参照图6)。

在步骤S151中，控制部13决定支付额和支付者。在此，支付者从发送了在步骤S103中接收的支付事务数据的申请者之中，通过决定算法来决定。关于支付者和支付额的决定算法，可以有各种各样的方法，对其一例在后文详细说明。

在步骤S152中，控制部13判定支付是否成立。能够基于作为在步骤S151中执行支付者和支付额的决定算法的结果而得到的“支付成立”或者“支付不成立”的结果信息，判定支付是否成立。在判定为支付成立的情况下(步骤S152：是)，向步骤S153前进，否则(步骤S152：否)，向步骤S161前进。

在步骤S153中，控制部13计算退还额。退还额是将通过将目标额在1个以上的申请者中按比例分配而得到的量的通证，从缴纳额中减去而得到的量。

在步骤S154中，控制部13生成将在步骤S153中计算的退还额向申请者退还的退还事务。

在步骤S155中，控制部13将在步骤S154中生成的退还事务数据向账本管理部12提供，从而向分散账本存放。另外，控制部13将上述退还事务数据向其他服务器10B等发送，使其向全部服务器10A等的分散账本存放。其后，与实施方式1同样，控制部13将支付完成的通知向提供者U1即终端40发送(步骤S110)。

在步骤S161中，控制部13生成将通过在步骤S103中从各申请者接收的支付事务数据而支付的通证的全额向申请者退还的退还事务。

在步骤S162中，控制部13将在步骤S161中生成的退还事务数据向账本管理部12提供，从而向分散账本存放。另外，控制部13将上述退还事务数据向其他服务器10B等发送，使其向全部服务器10A等的分散账本存放。其后，控制部13也可以向申请者U3即终端50等通知项目不成立(步骤S123)。

接下来，说明从各申请者向提供者的支付中的支付者和支付额的决定算法的一例。

图14是表示本实施方式中的控制部13对支付额的决定算法的流程图。图14所示的流程图是图13的步骤S151中包含的处理的一例。

在步骤S301中，控制部13决定从各申请者向提供者的支付额。例如，控制部13通过将目标额在申请者中按比例分配，来决定申请者平均1人的支付额。

在步骤S302中，控制部13关于各个申请者，对在步骤S301中决定的支付额与该申请者的缴纳额进行比较。然后，控制部13判定是否存在支付额比缴纳额大的申请者。在判定为存在支付额比缴纳额大的申请者的情况下(步骤S302：是)，向步骤S303前进，否则(步骤S302：否)以“支付成立”这样的结果信息结束图14所示的一系列处理。

在步骤S303中，控制部13将支付额比缴纳额大的申请者除外。

在步骤S304中，控制部13判定是否存在申请者。也就是说，在步骤S303中进行的除外的处理之后，判定是否存在至少1人的申请者。在判定为存在申请者的情况下(步骤S304：是)，以除外之后的申请者作为对象执行步骤S301的处理，否则(步骤S304：否)以“支付不成立”这样的结果信息结束图14所示的一系列处理。

像这样，控制部13反复将最初的1个以上的申请者之中的超过了缴纳额的申请者除外，并且以使全部申请者的支付额成为缴纳额以下的方式，决定各申请者的支付额。

说明决定算法的执行的具体例。

图15是表示本实施方式中的申请者的缴纳额的一例的说明图。图16是表示本实施方式中的控制部13执行支付额的决定算法的经过及结果的一例的说明图。

在此，在存在图15所示的申请者A、B、C、D、E及F(也称为申请者A～F)时，随着决定算法的执行的经过来说明由哪个申请者最终进行支付。此外，申请者A～F各自的缴纳额如图15所示，是10、5、20、24、100及60。此外，在以后的说明中，将最初执行步骤S301至S304的处理也称为第1轮，将上述处理的第2次执行也称为第2轮。第3轮以后也是同样的。

如图16的(1)所示，在第1轮中，在步骤S301中，申请者平均1人的支付额被计算为大致17通证。该17通证的值比申请者A及B的缴纳额大，因此将申请者A及B除外(步骤S303)，成为存在申请者C、D、E及F的状态。

接下来，如图16的(2)所示，在第2轮中，在步骤S301中，申请者平均1人的支付额被计算为25通证。该25通证的值比申请者C及D的缴纳额大，因此将申请者C及D除外(步骤S303)，成为存在申请者E及F的状态。

接下来，如图16的(3)所示，在第3轮中，在步骤S301中，申请者平均1人的支付额被计算为50通证。该50通证的值为申请者E及F的缴纳额以下，因此最终申请者E及F成为支付者。

图17是表示本实施方式中的基金管理系统1整体的处理的第一时序图。在图17中，表示了支付成立的情况下的基金管理系统1整体的处理。

步骤S201至S107的处理与实施方式1中的处理是相同的(参照图7)。

控制部13在目标条件被满足的情况下(步骤S107：是)，决定支付额和支付者，在该支付成立的情况下(步骤S151、S152)，计算每个申请者的退还额，并执行退还处理(步骤S154、S155)。其后，与实施方式1同样，执行步骤S110至S202的处理。

此外，步骤S154的退还事务的生成也可以由与服务器10A不同的服务器10B等或者终端41等进行。

图18是表示本实施方式中的基金管理系统1整体的处理的第二时序图。在图18中，表示了支付未成立的情况下的基金管理系统1整体的处理。

步骤S201至S107的处理与实施方式1中的处理是相同的(参照图7)。

控制部13在目标条件被满足的情况下(步骤S107：是)，决定支付额和支付者，在该支付未成立的情况下(步骤S151、S152)，执行向申请者退还全额的退还处理(步骤S161、S162)。其后，控制部13也可以向申请者U3即终端50等通知项目不成立(步骤S123)。

此外，步骤S161的退还事务的生成也可以由与服务器10A不同的服务器10B等或者终端41等进行。

(各实施方式的变形例)

此外，上述各实施方式的基金管理系统的控制方法也能够如下记载，但不限定于此。

图19是表示各实施方式的变形例中的服务器的处理(也称为服务器的控制方法)的流程图。

图19所示的一系列处理是在具备拥有分散账本的多个服务器的基金管理系统中由该多个服务器之中的一个服务器执行的控制方法。

如图19所示，在步骤S601中，从众筹的1个以上的申请者接收与向募集者的通证的支付处理相关的事务数据，将接收的事务数据向多个服务器各自具备的分散账本存放。

在步骤S602中，通过智能合约来判定众筹的目标条件是否被满足。

在步骤S603中，输出表示判定的结果的信息。

图20是示意性地表示各实施方式的变形例中的基金管理系统的构成的框图。

图20所示的基金管理系统2具备拥有分散账本的多个服务器60A、60B及60C。

基金管理系统2具备处理部61和控制部63。

处理部61从众筹的1个以上的申请者接收与向募集者的通证的支付处理相关的事务数据，将接收的事务数据向多个服务器各自具备的分散账本存放。

控制部63通过智能合约来判定众筹的目标条件是否被满足，并输出表示判定的结果的信息。

由此，能够对众筹中的资金筹措恰当地进行管理。

针对上述各实施方式或者变形例中的区块链补充地进行说明。

图21是表示区块链的数据结构的说明图。

区块链通过作为其记录单位的区块被以链(chain)状连接而成。各个区块具有多个事务数据、以及紧前的区块的哈希(Hash)值。具体而言，在区块B2中，包含其之前的区块B1的哈希(Hash)值。另外，根据区块B2中包含的多个事务数据和区块B1的哈希(Hash)值被运算出的哈希(Hash)值，作为区块B2的哈希(Hash)值被包含于区块B3。像这样，将之前的区块的内容作为哈希(Hash)值来包含，并且将区块以链状连接，从而有效地防止被记录的事务数据的篡改。

假设过去的事务数据被变更，则区块的哈希(Hash)值成为与变更前不同的值，要想使篡改后的区块伪装成正确的区块，必须重新制作其后的全部区块，该作业在现实中非常困难。利用该性质，在区块链中确保了篡改困难性。

图22是表示事务数据的数据结构的说明图。

图22所示的事务数据包含事务主体P1和电子签名P2。事务主体P1是该事务数据中包含的数据主体。电子签名P2是通过对于事务主体P1的哈希(Hash)值，由该事务数据的制作者的签名密钥进行签名、更具体而言由制作者的秘密密钥进行加密而生成的签名。

事务数据具有电子签名P2，因此篡改在实质上是不可能的。由此，防止了事务主体的篡改。

如上，上述的实施方式的服务器将与众筹中的通证的支付处理相关的信息作为事务数据向分散账本存放。分散账本中存放的事务数据的篡改在实质上是不可能的，因此与众筹中的通证的支付处理相关的信息被恰当地管理。另外，众筹的目标条件是否被满足的判定通过智能合约来进行，因此不经由其他人或者其他系统，而被自动而且安全地执行。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

另外，服务器在众筹的预定的募集期间结束时，对通过支付处理而支付的通证的合计与目标额进行大小比较，从而判定目标条件是否被满足，因此能够更容易地进行上述判定。因此，本发明所涉及的控制方法能够更容易地对众筹中的资金筹措恰当地进行管理。

另外，服务器在接收了支付处理所涉及的事务数据时，对通过支付处理而支付的通证的合计与目标额进行大小比较，从而判定目标条件是否被满足，因此能够更容易地进行上述判定。因此，本发明所涉及的控制方法能够更容易地对众筹中的资金筹措恰当地进行管理。

另外，服务器在众筹的目标条件未被满足的情况下，通证的退还处理也通过智能合约来执行。因此，通证的退还处理也不经由其他人或者其他系统，而被自动而且安全地执行。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

另外，服务器对与1个以上的申请者各自支付预定的量的通证的支付处理相关的信息恰当地进行管理。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

另外，服务器对与1个以上的申请者各自支付通过将预定的量的通证在1个以上的申请者中按比例分配而得到的量的通证的支付处理相关的信息恰当地进行管理。因此，本发明所涉及的控制方法能够对众筹中的资金筹措恰当地进行管理。

另外，以不超过申请者各自所指定的指定量的方式决定申请者的支付额。因此，本发明所涉及的控制方法能够在众筹中，在不超过上限的范围内收取支付额，并且对资金筹措恰当地进行管理。

另外，在目标条件是否被满足的判定处理中使用的智能合约的合约码能够由募集者生成。因此，通过生成反映了募集者的意图的合约码，能够进行更进一步反映了募集者的意图的条件判断。因此，本发明所涉及的控制方法能够更进一步反映募集者的意图，并且能够对众筹中的资金筹措恰当地进行管理。

另外，服务器经过共识算法的执行来存放分散账本。因此，通过经过进行共识算法的执行，能够更容易地对众筹中的资金筹措恰当地进行管理。

此外，在上述实施方式中，各构成要素既可以由专用的硬件构成，也可以通过执行适于各构成要素的软件程序来实现。各结构要素也可以通过CPU或处理器等程序执行部读出并执行在硬盘或半导体存储器等记录介质中记录的软件程序来实现。在此，用于实现上述实施方式的内容管理系统等的软件是如下的程序。

即，该程序是使计算机执行如下控制方法的程序，该控制方法是在具备拥有分散账本的多个服务器的基金管理系统中由该多个服务器之中的一个服务器执行的控制方法，从众筹的1个以上的申请者接收与向管理账户的通证的支付处理相关的事务数据，将接收的所述事务数据向所述多个服务器各自具备的分散账本存放，通过智能合约来判定所述众筹的目标条件是否被满足，输出表示所述判定的结果的信息。

以上，针对一个或者多个方式所涉及的基金管理系统等，基于实施方式进行了说明，但本发明不限定于该实施方式。只要不脱离本发明的主旨，对本实施方式实施了本领域技术人员想到的各种变形而得到的方式、组合了不同实施方式中的构成要素而构筑的方式，也都包含在一个或者多个方式的范围内。

工业实用性

本发明能够利用于对众筹中的资金筹措恰当地进行管理的基金管理系统。

附图标记说明：

1、2 基金管理系统

10A、10B、10C、60A、60B、60C 服务器

11、61 处理部

12 账本管理部

13、63 控制部

15 存放部

16 账本存储部

40、41、50、51 终端

B1、B2、B3 区块

N 网络

P1 事务主体

P2 电子签名

U1 提供者

U2 募集者

U3、U4 申请者