特許 7524066 制御方法、ファンド管理システム、及び、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-07-19

(45)【発行日】2024-07-29

(54)【発明の名称】制御方法、ファンド管理システム、及び、プログラム

(51)【国際特許分類】

   G06Q 40/06 20120101AFI20240722BHJP

【ＦＩ】

G06Q40/06

【請求項の数】 12

(21)【出願番号】P 2020553369

(86)(22)【出願日】2019-10-18

(86)【国際出願番号】 JP2019041228

(87)【国際公開番号】W WO2020085267

(87)【国際公開日】2020-04-30

【審査請求日】2022-08-17

(31)【優先権主張番号】62/748,606

(32)【優先日】2018-10-22

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100109210

【弁理士】

【氏名又は名称】新居 広守

(74)【代理人】

【識別番号】100137235

【弁理士】

【氏名又は名称】寺谷 英作

(74)【代理人】

【識別番号】100131417

【弁理士】

【氏名又は名称】道坂 伸一

(72)【発明者】

【氏名】道山 淳児

(72)【発明者】

【氏名】添田 純一郎

(72)【発明者】

【氏名】海上 勇二

(72)【発明者】

【氏名】廣瀬 雄揮

(72)【発明者】

【氏名】渕上 哲司

(72)【発明者】

【氏名】大森 基司

【審査官】原 忠

(56)【参考文献】

【文献】特開２０１５－１９７９０４（ＪＰ，Ａ）

【文献】渡辺 篤 ，はじめてのブロックチェーン・アプリケーション，第1版，日本，株式会社翔泳社 佐々木 幹夫，2017年08月03日，138-159頁

【文献】渡辺 陽介，ブロックチェーン技術を用いた占有グリッドマップの分散サービス化，第１０回データ工学と情報マネジメントに関するフォーラム （第１６回日本データベース学会年次大会） ［Ｏｎｌｉｎｅ］ ，日本，電子情報通信学会データ工学研究専門委員会 日本データベース学会 情報処理学会データベースシステム研究会，2018年04月17日，1-7頁

【文献】愛敬 真生，文系でもわかるブロックチェーン，日経ソフトウエア，日本，日経ＢＰ社，2017年07月24日，第２０巻 第１０号，77-85頁

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

分散台帳を保有している複数のサーバを備えるファンド管理システムにおける制御方法であって、
クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約に係る予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、
前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、
前記目標条件が満たされたと判定した場合に、前記申込者から前記募集者へ前記トークンを支払う支払処理を実行し、
前記支払処理は、
予め定められた量のトークンを前記１以上の申込者で按分した量のトークンを、前記１以上の申込者それぞれが支払う処理である
制御方法。

【請求項2】

分散台帳を保有している複数のサーバを備えるファンド管理システムにおける制御方法であって、
クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約に係る予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、
前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、
前記目標条件が満たされたと判定した場合に、前記申込者から前記募集者へ前記トークンを支払う支払処理を実行し、
前記トランザクションデータは、前記トランザクションデータを送信した申込者が支払う前記トークンの上限を含み、
前記支払処理において、
予め定められた量のトークンを前記１以上の申込者で按分した量のトークンが、前記１以上の申込者のうちの一の申込者が支払う前記トークンの上限を超える場合には、前記１以上の申込者から前記一の申込者を除外して、前記予め定められた量のトークンを前記１以上の申込者で按分する
制御方法。

【請求項3】

前記目標条件が満たされたか否かの判定は、
前記クラウドファンディングの募集期間が終了したときに、前記募集期間中に受信した前記トランザクションデータに係る前記予約処理によって支払われるトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされる
請求項１または２に記載の制御方法。

【請求項4】

前記目標条件が満たされたか否かの判定は、
前記トランザクションデータの受信をしたときに、前記受信以前に受信した前記トランザクションデータに係る前記予約処理によって支払われるトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされる
請求項１または２に記載の制御方法。

【請求項5】

前記目標条件が満たされたと判定した場合には、さらに、
前記判定の結果を示す情報に基づいて、前記予約処理に係る前記トークンの支払処理をスマートコントラクトにより実行する
請求項１～４のいずれか１項に記載の制御方法。

【請求項6】

前記支払処理は、
予め定められた量のトークンを、前記１以上の申込者それぞれが支払う処理である
請求項１～５のいずれか１項に記載の制御方法。

【請求項7】

さらに、
前記クラウドファンディングの募集者の端末が、前記スマートコントラクトに係るコードを生成し、
生成した前記コードを含めたトランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する
請求項１～６のいずれか１項に記載の制御方法。

【請求項8】

前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納する
請求項１～７のいずれか１項に記載の制御方法。

【請求項9】

前記クラウドファンディングの募集期間内に前記目標条件が満たされた場合、前記クラウドファンディングの募集を終了して、前記支払処理を実行する
請求項１～８のいずれか１項に記載の制御方法。

【請求項10】

分散台帳を保有している複数のサーバを備えるファンド管理システムであって、
クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約に係る予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する処理部と、
前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記目標条件が満たされたと判定した場合に、前記申込者から前記募集者へ前記トークンを支払う支払処理を実行する制御部とを備え、
前記支払処理は、
予め定められた量のトークンを前記１以上の申込者で按分した量のトークンを、前記１以上の申込者それぞれが支払う処理である
ファンド管理システム。

【請求項11】

分散台帳を保有している複数のサーバを備えるファンド管理システムであって、
クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約に係る予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する処理部と、
前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記目標条件が満たされたと判定した場合に、前記申込者から前記募集者へ前記トークンを支払う支払処理を実行する制御部とを備え、
前記トランザクションデータは、前記トランザクションデータを送信した申込者が支払う前記トークンの上限を含み、
前記制御部は、前記支払処理において、
予め定められた量のトークンを前記１以上の申込者で按分した量のトークンが、前記１以上の申込者のうちの一の申込者が支払う前記トークンの上限を超える場合には、前記１以上の申込者から前記一の申込者を除外して、前記予め定められた量のトークンを前記１以上の申込者で按分する
ファンド管理システム。

【請求項12】

請求項１～９のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御方法、ファンド管理システム、プログラム、及び、データ構造に関する。

【背景技術】

【0002】

クラウドファンディングの普及を促進することを目的とした情報処理装置が提案されている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－１５６９２７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、クラウドファンディングにおいて、資金調達を不正に妨げたり、調達された資金を不正に取得したりする行為がなされ得るという問題がある。

【0005】

そこで、本発明は、クラウドファンディングにおける資金調達を適切に管理する制御方法などを提供する。

【課題を解決するための手段】

【0006】

本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する。

【0007】

なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

【発明の効果】

【0008】

本発明の制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【図面の簡単な説明】

【0009】

【図1】図１は、実施の形態１におけるファンド管理システムの構成を模式的に示すブロック図である。

【図2】図２は、実施の形態１におけるサーバの構成を模式的に示すブロック図である。

【図3】図３は、実施の形態１における募集トランザクションデータを模式的に示す説明図である。

【図4】図４は、実施の形態１における予約トランザクションデータを模式的に示す説明図である。

【図5】図５は、実施の形態１における支払トランザクションデータを模式的に示す説明図である。

【図6】図６は、実施の形態１におけるサーバの処理を示すフロー図である。

【図7】図７は、実施の形態１におけるファンド管理システム全体の処理を示すシーケンス図である。

【図8】図８は、実施の形態２におけるサーバの処理を示すフロー図である。

【図9】図９は、実施の形態２におけるファンド管理システム全体の処理を示す第一のシーケンス図である。

【図10】図１０は、実施の形態２におけるファンド管理システム全体の処理を示す第二のシーケンス図である。

【図11】図１１は、実施の形態３における募集トランザクションデータを模式的に示す説明図である。

【図12】図１２は、実施の形態３における予約トランザクションデータを模式的に示す説明図である。

【図13】図１３は、実施の形態３におけるサーバの処理を示すフロー図である。

【図14】図１４は、実施の形態３における制御部による支払額の決定アルゴリズムを示すフロー図である。

【図15】図１５は、実施の形態３における申込者の支払上限額の一例を示す説明図である。

【図16】図１６は、実施の形態３における制御部による支払額の決定アルゴリズムの実行の経過および結果の一例を示す説明図である。

【図17】図１７は、実施の形態３におけるファンド管理システム全体の処理を示すシーケンス図である。

【図18】図１８は、各実施の形態の変形例におけるサーバの処理を示すフロー図である。

【図19】図１９は、各実施の形態の変形例におけるサーバの構成を模式的に示すブロック図である。

【図20】図２０は、ブロックチェーンのデータ構造を示す説明図である。

【図21】図２１は、トランザクションデータのデータ構造を示す説明図である。

【発明を実施するための形態】

【0010】

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、クラウドファンディングに関する技術に関し、以下の問題が生じることを見出した。

【0011】

クラウドファンディングは、インターネット上において、プロジェクト（例えば、新しいコンテンツを作成して提供すること）に対して１以上の者（支援者ともいう）から提供された資金を、コンテンツ提供者に提供する仕組みである。この仕組みによって、コンテンツ提供者は、プロジェクトに係る資金調達をすることができる。

【0012】

クラウドファンディングの普及を促進することを目的とした情報処理装置が提案されている（特許文献１参照）。特許文献１に記載された技術は、クラウドファンディングをライブ会場で行うことで、クラウドファンディングの普及を促進し得る技術である。

【0013】

しかしながら、クラウドファンディングにおいて、資金調達を不正に妨げたり、調達された資金を不正に取得したりする行為がなされ得るという問題がある。具体的には、支援者が資金を提供する意思を提示した後にその意思を撤回することによって、資金調達を不正に妨げる行為がなされ得る。また、提供された資金に関する情報を改ざんすることによって、提供された資金の一部または全部を悪意者が不正に取得する行為がなされ得る。

【0014】

そこで、本発明は、クラウドファンディングにおける資金調達を適切に管理する制御方法などを提供する。

【0015】

このような問題を解決するために、本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する。

【0016】

上記態様によれば、サーバは、クラウドファンディングにおけるトークンの支払いの予約処理に関する情報をトランザクションデータとして分散台帳に格納する。分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、クラウドファンディングにおけるトークンの支払いの予約処理に関する情報が適切に管理される。また、クラウドファンディングの目標条件が満たされたか否かの判定がスマートコントラクトによりなされるので、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0017】

例えば、前記目標条件が満たされたか否かの判定は、前記クラウドファンディングの募集期間が終了したときに、前記募集期間中に受信した前記トランザクションデータに係る前記予約処理によって支払われるトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされてもよい。

【0018】

上記態様によれば、サーバは、クラウドファンディングの予め定められた募集期間が終了したときに、予約処理によって支払われるトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0019】

例えば、前記目標条件が満たされたか否かの判定は、前記トランザクションデータの受信をしたときに、前記受信以前に受信した前記トランザクションデータに係る前記予約処理によって支払われるトークンの合計が、前記クラウドファンディングの目標額以上であるか否かを判定することでなされてもよい。

【0020】

上記態様によれば、サーバは、予約処理に係るトランザクションデータを受信したときに、予約処理によって支払われるトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0021】

例えば、前記目標条件が満たされたと判定した場合には、さらに、前記判定の結果を示す情報に基づいて、前記予約処理に係る前記トークンの支払処理をスマートコントラクトにより実行してもよい。

【0022】

上記態様によれば、サーバは、クラウドファンディングの目標条件が満たされた場合には、トークンの支払処理もスマートコントラクトにより実行する。よって、トークンの支払処理も、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0023】

例えば、前記支払処理は、予め定められた量のトークンを、前記１以上の申込者それぞれが支払う処理であってもよい。

【0024】

上記態様によれば、サーバは、予め定められた量のトークンを１以上の申込者それぞれが支払う支払処理に係る予約処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0025】

例えば、前記支払処理は、予め定められた量のトークンを前記１以上の申込者で按分した量のトークンを、前記１以上の申込者それぞれが支払う処理であってもよい。

【0026】

上記態様によれば、サーバは、予め定められた量のトークンを１以上の申込者で按分した量のトークンを、１以上の申込者それぞれが支払う支払処理に係る予約処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0027】

例えば、前記トランザクションデータは、前記トランザクションデータを送信した申込者が支払う前記トークンの上限を含み、前記支払処理において、前記予め定められた量のトークンを前記１以上の申込者で按分した量のトークンが、前記１以上の申込者のうちの一の申込者が支払う前記トークンの上限を超える場合には、前記１以上の申込者から前記一の申込者を除外して、前記予め定められた量のトークンを前記１以上の申込者で按分してもよい。

【0028】

上記態様によれば、申込者それぞれについて定められた上限を超えないように申込者の支払額が決定される。よって、本発明に係る制御方法は、クラウドファンディングにおいて、上限を超えない範囲に支払額を収めながら、資金調達を適切に管理することができる。

【0029】

例えば、さらに、前記クラウドファンディングの募集者の端末が、前記スマートコントラクトに係るコードを生成し、生成した前記コードを含めたトランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納してもよい。

【0030】

上記態様によれば、目標条件が満たされたか否かの判定処理に用いられるスマートコントラクトのコントラクトコードが、募集者によって生成され得る。よって、募集者の意図を反映したコントラクトコードが生成されることで、募集者の意図をより一層反映した条件判断がなされ得る。よって、本発明に係る制御方法は、募集者の意図をより一層反映可能としながら、クラウドファンディングにおける資金調達を適切に管理することができる。

【0031】

例えば、前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記分散台帳に格納してもよい。

【0032】

上記態様によれば、サーバは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、コンセンサスアルゴリズムの実行を得ることによって、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0033】

また、本発明の一態様に係るファンド管理システムは、分散台帳を保有している複数のサーバを備えるファンド管理システムであって、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納する処理部と、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する制御部とを備える。

【0034】

上記態様により、上記制御方法と同様の効果を奏する。

【0035】

また、本発明の一態様に係るプログラムは、上記の制御方法をコンピュータに実行させるためのプログラム。

【0036】

上記態様により、上記制御方法と同様の効果を奏する。

【0037】

また、本発明の一態様に係るデータ構造は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて用いられるデータ構造であって、クラウドファンディングのプロジェクトを一意に特定し得る識別情報と、前記プロジェクトによって募集するトークンの量を示す情報と、前記プロジェクトの申込者１人が支払うトークンの量を示す情報と、前記プロジェクトの募集者の電子署名とを含む。

【0038】

上記態様により、上記ファンド管理システムと同様の効果を奏する。

【0039】

なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

【0040】

以下、実施の形態について、図面を参照しながら具体的に説明する。

【0041】

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

【0042】

（実施の形態１）
本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて説明する。なお、ファンドにおける資金調達の単位をプロジェクトともいう。プロジェクトは、コンテンツの提供に係るプロジェクトであることが想定される。プロジェクトについて、コンテンツを提供する者を提供者といい、そのコンテンツについての資金提供の募集をする者を募集者といい、資金提供を申し込む者を申込者という。一のプロジェクトは、当該一のプロジェクトについて定められた募集期間中に、定められた目標額の資金提供の申し込みを受けることができた場合に「成立する」と表現する。

【0043】

図１は、本実施の形態におけるファンド管理システム１の構成を模式的に示すブロック図である。

【0044】

図１に示されるように、ファンド管理システム１は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１、５０および５１とを備える。ファンド管理システム１が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいう。

【0045】

サーバ１０Ａは、ファンド管理システム１によって行われるクラウドファンディングを管理する複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、クラウドファンディングにおける募集、予約および支払に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、クラウドファンディングにおける募集、予約および支払を受け付け、また、必要に応じて申込者に対して支払の指示を送信する。なお、プロジェクトにおける資金提供は、一例として、分散台帳により、トークンの提供として管理される。

【0046】

サーバ１０Ｂ及び１０Ｃは、それぞれ、サーバ１０Ａと同じ機能を有する装置であり、サーバ１０Ａとは独立に動作する。なお、サーバの台数は、３に限られず、複数であればよい。また、サーバ１０Ａ等同士は、通信可能に接続されており、ネットワークＮを介して接続されていてもよい。

【0047】

端末４０は、提供者が保有する端末装置である。提供者が提供するコンテンツは、例えば、動画、静止画、音楽、又は、ソフトウェア（アプリケーションソフトウェアを含む）などの電子データである。提供者が提供するコンテンツは、提供者が作成したものであることが想定され、この場合を説明するがこれに限定されない。端末４０は、プロジェクトが成立した場合に、当該プロジェクトに係るコンテンツを申込者に提供する。端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。

【0048】

端末４１は、クラウドファンディングのプロジェクトの募集者が保有する端末装置である。募集者は、申込者による資金提供の申し込みの合計額が、プロジェクトの目標額に達するように、申込者による資金提供を募集する。なお、募集者は、提供者と同一の者であってもよいし、申込者と同一の者であってもよいし、提供者及び募集者と異なる者であってもよい。端末４１は、資金提供の募集をする際には、資金提供の募集に関する情報を含むトランザクションデータ（募集トランザクションデータともいう）を生成し、生成した募集トランザクションデータをサーバ１０Ａなどに送信する。

【0049】

端末５０は、申込者が保有する端末装置である。申込者は、資金提供の募集に関する情報を参照し、資金を提供することの申込（つまり予約）をする。また、プロジェクトが成立した場合には、成立したプロジェクトの資金提供の募集に関する情報に従って、資金の提供をする。

【0050】

端末５０は、資金を提供することの予約の際には、予約処理のためのトランザクションデータ（予約トランザクションデータ）をサーバ１０Ａに生成し、生成した予約トランザクションデータをサーバ１０Ａ等に送信する。予約処理とは、申込者から募集者への資金つまりトークンの支払の予約に係る処理をいう。

【0051】

また、端末５０は、サーバ１０Ａから支払指示を受信した場合には、資金の支払のためのトランザクションデータ（支払トランザクションデータ）を生成し、生成した支払トランザクションデータをサーバ１０Ａに送信する。支払が完了すると、端末５０は、提供者が提供するコンテンツを取得する。その後、申込者は、コンテンツを利用することができる。

【0052】

端末５１は、ファンドの申込者であって、端末５０を保有する申込者とは異なる申込者が保有する端末装置である。端末５１は、端末５０と同じ機能を有する装置であり、端末５０とは独立に動作する。なお、申込者が保有する端末の台数は、２に限られず、申込者の人数と同じ数だけ存在する。

【0053】

以降において、ファンド管理システム１が備えるサーバ１０Ａ等の構成について詳細に説明する。

【0054】

図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。

【0055】

図２に示されるように、サーバ１０Ａは、処理部１１と、台帳管理部１２と、制御部１３とを備える。サーバ１０Ａが備える上記機能部は、例えばＣＰＵがメモリを用いてプログラムを実行することで実現され得る。

【0056】

処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、ファンド管理システム１内の装置からトランザクションデータを受信した場合に、受信したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、募集トランザクションデータ、予約トランザクションデータおよび支払トランザクションデータが含まれる。各トランザクションデータについては後で詳しく説明する。

【0057】

台帳管理部１２は、分散台帳を管理している処理部である。台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記トランザクションデータが改ざんされないように管理されている。

【0058】

台帳管理部１２は、格納部１５と、台帳記憶部１６とを有する。

【0059】

格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、分散台帳の種別に応じた方式で新しいトランザクションデータを台帳記憶部１６に格納する。また、格納部１５は、サーバ１０Ａ等のうちの他のサーバの格納部１５と通信データを送受信し、他のサーバの台帳記憶部１６にも上記新しいトランザクションデータを格納させる。例えば、格納部１５は、分散台帳がブロックチェーンである場合には、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとったうえで、上記ブロックを台帳記憶部１６に格納する。

【0060】

台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータを記憶しており、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている（後述）。

【0061】

なお、分散台帳は、例えばブロックチェーンであり、この場合を例として説明するが、他の方式の分散台帳（例えば、ＩＯＴＡ又はハッシュグラフ等）を採用することも可能である。なお、分散台帳は、新しいデータの格納の際にコンセンサスアルゴリズム（例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）、ＰｏＷ（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ）又はＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ））を実行するものであってもよいし、実行しないものであってもよい。コンセンサスアルゴリズムを実行しない分散台帳技術の一例としてＨｙｐｅｒｌｅｄｇｅｒ ｆａｂｒｉｃがある。

【0062】

制御部１３は、クラウドファンディングのプロジェクトの成否を判定し、資金の提供を制御する処理部である。制御部１３は、クラウドファンディングの目標条件を、募集トランザクションにより端末４１から受信する。また、制御部１３は、端末５０及び５１からの予約トランザクションにより資金提供の申し込みを受ける。制御部１３は、クラウドファンディングの目標条件が満たされるか否かを判定し、その判定結果を示す情報を出力する。また、制御部１３は、上記判定の結果に基づいて、クラウドファンディングのプロジェクトが成立した場合に、上記予約処理に係る支払処理、つまり、申込者から提供者への資金つまりトークンの支払いに係る処理が行われるように制御する。

【0063】

なお、目標条件が満たされたか否かを判定するタイミングは、複数あり得る。

【0064】

例えば、目標条件が満たされたか否かの判定は、クラウドファンディングの募集期間が終了したときに、募集期間中に受信したトランザクションデータに係る予約処理によって支払われるトークンの合計が、クラウドファンディングの目標額以上であるか否かを判定することでなされる。本実施の形態では、この場合を例として説明する。

【0065】

なお、支払処理は、例えば、予め定められた量のトークンを、１以上の申込者それぞれが支払う処理である。

【0066】

なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされ得るが、これに限定されない。以降では、制御部１３の上記の処理の全部がスマートコントラクトによりなされる場合を例として説明する。

【0067】

以降において、各種トランザクションデータについて説明する。

【0068】

図３は、本実施の形態における募集トランザクションデータを模式的に示す説明図である。募集トランザクションデータは、クラウドファンディングのプロジェクトを開始する際に、募集者Ｕ２つまり端末４１によって生成され、サーバ１０Ａ等に送信される。

【0069】

図３に示されるように、募集トランザクションデータは、募集者ＩＤと、プロジェクトＩＤと、提供者ＩＤと、募集期限と、目標額と、支払額と、コントラクトコードと、署名とを含む。

【0070】

募集者ＩＤは、当該プロジェクトについての資金提供を募集する募集者を一意に特定し得る識別子である。

【0071】

プロジェクトＩＤは、当該プロジェクトを一意に特定し得る識別子である。

【0072】

提供者ＩＤは、提供者を一意に特定し得る識別子である。

【0073】

募集期限は、当該プロジェクトの募集期限、つまり募集期間の終期を示す情報である。

【0074】

目標額は、当該プロジェクトにおいて募集者が調達することを目標としている資金の額、つまりトークンの量を示す情報である。

【0075】

支払額は、当該プロジェクトにおいて、申込者それぞれが支払うトークンの量を示す情報である。

【0076】

コントラクトコードは、当該プロジェクトの成否の判定を行うスマートコントラクトのコードである。

【0077】

署名は、当該募集トランザクションデータを生成した装置又は人が付した電子署名である。

【0078】

図３に示される募集トランザクションデータは、募集者ＩＤが「ａａａ００１」である募集者が、プロジェクトＩＤが「ｋｄｆｊａｆｊｐｏ３４」であるプロジェクトについての資金提供の募集をするときに用いられる。このプロジェクトにおいて、提供者の提供者ＩＤが「ｆｌｊａｄ４０１９」であり、募集期限が「２０１８．１０．１０ １５：００：００」であり、目標額は「１００」トークンであり、支払額は「１」トークンである。署名は、募集者の電子署名である。

【0079】

なお、図３に示される募集トランザクションデータは、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて用いられるデータ構造であって、クラウドファンディングのプロジェクトを一意に特定し得る識別情報と、プロジェクトによって募集するトークンの量を示す情報と、プロジェクトの申込者１人が支払うトークンの量を示す情報と、プロジェクトの募集者の電子署名とを含むデータ構造を有するともいえる。

【0080】

なお、図３における募集期限、目標額、および支払額などの条件は、コントラクトコード内に記載されていてもよい。また、図３において、コントラクトコードの具体的な記載は省略しているが、その処理内容については後で具体的に説明する。

【0081】

図４は、本実施の形態における予約トランザクションデータを模式的に示す説明図である。予約トランザクションデータは、プロジェクトにおいて資金提供の予約をする際に、当該予約をする申込者（例えば申込者Ｕ３つまり端末５０）によって生成され、サーバ１０Ａ等に送信される。

【0082】

図４に示されるように、予約トランザクションデータは、申込者ＩＤと、プロジェクトＩＤと、支払額と、送信日時と、署名とを含む。

【0083】

申込者ＩＤは、資金提供の申込つまり予約をする申込者を一意に特定し得る識別子である。

【0084】

プロジェクトＩＤは、当該予約に係るプロジェクトを一意に特定し得る識別子である。

【0085】

支払額は、当該予約において、申込者が支払うトークンの量を示す情報である。

【0086】

送信日時は、当該予約トランザクションデータの送信日時を示す情報である。

【0087】

署名は、当該予約トランザクションデータを生成した装置又は人が付した電子署名である。

【0088】

図４に示される予約トランザクションデータは、申込者ＩＤが「ａａｂ０００３」である申込者が、プロジェクトＩＤが「ｋｄｆｊａｆｊｐｏ３４」であるプロジェクトについての資金提供の予約をするときに用いられる。この予約において、支払額は「１」トークンであり、この予約トランザクションデータの送信日時が「２０１８．１０．０５ １０：００：００」である。署名は、申込者の電子署名である。

【0089】

図５は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。支払トランザクションデータは、プロジェクトに係るファンドが成立したことに基づいて、申込者から提供者への資金提供の際に、申込者（例えば申込者Ｕ３つまり端末５０）によって生成され、サーバ１０Ａ等に送信される。

【0090】

図５に示されるように、支払トランザクションデータは、申込者口座ＩＤと、提供者口座ＩＤと、支払額と、送信日時と、署名とを含む。

【0091】

申込者口座ＩＤは、資金提供をする申込者を一意に特定し得る識別子である。

【0092】

提供者口座ＩＤは、資金提供を受ける提供者を一意に特定し得る識別子である。

【0093】

支払額は、当該支払トランザクションデータによって提供されるトークン額を示す情報である。

【0094】

送信日時は、当該支払トランザクションデータの送信日時を示す情報である。

【0095】

署名は、当該支払トランザクションデータを生成した装置又は人が付した電子署名である。

【0096】

図５に示される支払トランザクションデータは、申込者口座ＩＤが「ａａｂ０ａａｂ」である申込者口座から、提供者口座ＩＤが「ｍｏａｑ６８０７９」である提供者口座へ資金（トークン）を提供するときに用いられる。支払額が「１」トークンであり、この支払トランザクションデータの送信日時が「２０１８．１０．１１ ０７：００：００」である。署名は、申込者の電子署名である。

【0097】

以上のように構成されたサーバ１０Ａ等の処理を説明する。

【0098】

図６は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。

【0099】

ステップＳ１０１において、処理部１１は、募集者Ｕ２つまり端末４１から募集トランザクションデータを受信したか否かを判定する。募集トランザクションデータを受信した場合（ステップＳ１０１でＹｅｓ）には、ステップＳ１０２に進み、そうでない場合（ステップＳ１０１でＮｏ）には、ステップＳ１０１を再び実行する。つまり処理部１１は、募集トランザクションデータを受信するまでステップＳ１０１で待機する。なお、募集トランザクションデータには、当該プロジェクトの目標条件の判定をするスマートコントラクトのコントラクトコードが含まれている。

【0100】

ステップＳ１０２において、処理部１１は、ステップＳ１０１で受信した募集トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記募集トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。

【0101】

ステップＳ１０３において、処理部１１は、申込者Ｕ３等つまり端末４１等から予約トランザクションデータを受信したか否かを判定する。予約トランザクションデータを受信した場合（ステップＳ１０３でＹｅｓ）には、ステップＳ１０４に進み、そうでない場合（ステップＳ１０３でＮｏ）には、ステップＳ１０５に進む。

【0102】

ステップＳ１０４において、処理部１１は、ステップＳ１０３で取得した予約トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、処理部１１は、上記予約トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。

【0103】

ステップＳ１０５において、制御部１３は、募集期間が終了したか否かを判定する。例えば募集期間が終了したか否かは、ステップＳ１０４で格納された支払トランザクションデータに基づいて判定される。募集期間が終了したと判定した場合（ステップＳ１０５でＹｅｓ）には、ステップＳ１０６に進み、そうでない場合（ステップＳ１０５でＮｏ）には、ステップＳ１０３に進む。

【0104】

ステップＳ１０６において、制御部１３は、募集期間が終了したことを申込者Ｕ３等の端末５０等に通知する。なお、ステップＳ１０６は、実行されなくてもよい。

【0105】

ステップＳ１０７において、制御部１３は、クラウドファンディングのプロジェクトの目標条件が満たされたか否かを判定する。目標条件が満たされたか否かの判定は、ステップＳ１０１で受信した募集トランザクションデータに含まれるコントラクトコードを実行することによってなされる。目標条件が満たされたと判定された場合（ステップＳ１０７でＹｅｓ）には、ステップＳ１０８に進み、そうでない場合（ステップＳ１０７でＮｏ）には、ステップＳ１２１に進む。

【0106】

ステップＳ１０８において、制御部１３は、申込者Ｕ３等それぞれの支払額を決定する。ここでは、申込者Ｕ３等それぞれの支払額は、募集トランザクションに含まれる支払額（図３の例では１トークン）のとおりに決定される。

【0107】

ステップＳ１０９において、制御部１３は、申込者Ｕ３等それぞれの端末５０等に対して、支払指示を送信する。支払指示の宛先は、ステップＳ１０１で受信した予約トランザクションデータの送信元である、申込者Ｕ３等それぞれの端末５０等である。

【0108】

ステップＳ１１０において、制御部１３は、申込者Ｕ３等つまり端末４１等から支払トランザクションデータを受信したか否かを判定する。支払トランザクションデータを受信した場合（ステップＳ１１０でＹｅｓ）には、ステップＳ１１１に進み、そうでない場合（ステップＳ１１０でＮｏ）には、ステップＳ１１０を再び実行する。つまり処理部１１は、支払トランザクションデータを受信するまでステップＳ１１０で待機する。

【0109】

ステップＳ１１１において、制御部１３は、ステップＳ１１０で受信した支払トランザクションデータを台帳管理部１２に提供することで、分散台帳に格納する。また、制御部１３は、上記支払トランザクションデータを他のサーバ１０Ｂ等に送信し、すべてのサーバ１０Ａ等の分散台帳に格納させる。

【0110】

ステップＳ１１２において、制御部１３は、支払完了の通知を提供者Ｕ１つまり端末４０に送信する。端末４０は、当該通知を受信すると、提供者Ｕ１が生成したコンテンツが申込者に提供されるように制御する。

【0111】

ステップＳ１２１において、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知する。なお、ステップＳ１２１は、実行されなくてもよい。

【0112】

ステップＳ１１２又はＳ１２１のあと、図６に示される一連の処理を終了する。

【0113】

以降において、ファンド管理システム１の全体の処理を説明する。

【0114】

図７は、本実施の形態におけるファンド管理システム１全体の処理を示すシーケンス図である。なお、図６のフロー図と同じ処理を示すものは、図６と同じ符号を付し詳細な説明を省略する。

【0115】

ステップＳ２０１において、提供者Ｕ１の端末４０は、クラウドファンディングのプロジェクトに関する条件を設定し、設定した条件を端末４１に送信する。上記条件は、募集期限、目標額、および支払額を含む。端末４１は、送信された条件を受信する。

【0116】

ステップＳ２１１において、端末４１は、ステップＳ２０１で受信した条件に基づいて、プロジェクトの目標条件の判定をするためのコントラクトコードを生成する。

【0117】

ステップＳ２１２において、端末４１は、ステップＳ２０１で受信した条件と、ステップＳ２１１で生成したコントラクトコードとを含む募集トランザクションデータ（図３参照）を生成する。また、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等に送信する。このとき、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。

【0118】

サーバ１０Ａ等は、端末４１により送信された募集トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０１及びＳ１０２）。

【0119】

ステップＳ２２１において、端末５１は、予約トランザクションデータを生成してサーバ１０Ａ等に送信する。このとき、端末５１は、生成した予約トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。

【0120】

サーバ１０Ａ等は、送信された予約トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０３及びＳ１０４）。また、募集期間が終了した場合には、募集期間が終了したことの通知を送信する（ステップＳ１０５及びＳ１０６）。

【0121】

そして、サーバ１０Ａ等は、目標条件が達成された場合には、各申込者の支払額を決定し、各申込者の端末に支払指示を送信する（ステップＳ１０７～Ｓ１０９）。

【0122】

ステップＳ２２２において、端末５１は、ステップＳ１０９で送信された支払指示に基づいて、支払トランザクションデータを生成し、生成した支払トランザクションデータをサーバ１０Ａ等に送信する。このとき、端末５１は、生成した支払トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。

【0123】

サーバ１０Ａ等は、送信された支払トランザクションデータを受信し、分散台帳に格納する（ステップＳ１１０及びＳ１１１）。そして、支払が完了したことを端末４０に送信する。

【0124】

ステップＳ２０２において、端末４０は、当該通知を受信すると、提供者が生成したコンテンツを申込者に提供する。

【0125】

なお、ステップＳ２０２での提供者から申込者へのコンテンツの提供は、目標条件が満たされたと判定された（ステップＳ１０７）あとのタイミングであれば、いつ行われてもよい。

【0126】

また、上記では１人の申込者が１トークンを支払う場合を例として説明したが、１人の申込者が２トークン以上を支払うようにしてもよい。その場合、目標条件として、申込者による資金提供の申し込みの合計額がプロジェクトの目標額に達することに加えて、申込者の人数が所定以上になることを課してもよい。より多くの人にコンテンツを提供するためである。

【0127】

また、提供者が悪意あるコンテンツ（例えば偽のコンテンツ）を提供することを防ぐために、申込者が申込をする前に、コンテンツのスナップショット又はプレビュー画像を提供するようにしてもよい。

【0128】

また、募集期間のうちでより早いタイミングで申し込みをした者に対して、多めの報酬を提供するようにしてもよい。ここで、報酬とは、トークンであってもよいし、提供者が作成したコンテンツがその後に利益を生んだ場合にその利益のうちのより多い割合の配分を受けることであってもよいし、コンテンツをより早く提供されることであってもよい。

【0129】

また、募集者が提供者に対してトークンを支払うようにしてもよい。

【0130】

また、ステップＳ１０９の支払指示は、サーバ１０Ａと異なるサーバ１０Ｂ等によって支払トランザクションデータを生成し、生成したトランザクションデータを分散台帳に格納することにより実現されてもよい。

【0131】

また、ファンド管理システム１の構成は、図１のようにサーバ１０Ａ等と端末４０などとが、それぞれ単独の装置である場合を例として説明したがこれに限られない。例えば、サーバ１０Ａが存在せず、端末４０、４１、５０および５１が分散台帳を保有している構成であってもよい。また、端末５０又は５１が分散台帳を保有している構成であってもよい。言い換えれば、端末４０、４１、５０および５１のうちの一部または全部が、サーバ１０Ａなどの機能を兼ね備えていてもよい。

【0132】

以上の一連の処理によって、クラウドファンディングの条件、トークンの支払いの予約、及び、トークンの支払いに関する情報のそれぞれが、トランザクションデータとして分散台帳に格納されるので、上記情報の改ざんが抑制される。特に、トークンの支払いの予約処理に関する情報が改ざんされることが抑制されることで、申込者が予約後に不正にキャンセルすることが回避される。よって、ファンド管理システム１は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0133】

（実施の形態２）
本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて、実施の形態１とは異なる例を説明する。

【0134】

本実施の形態におけるファンド管理システム１の構成、サーバの構成、および各種トランザクションデータの構造は、実施の形態１におけるものと同じである（図１、図２参照）。

【0135】

本実施の形態におけるサーバ１０Ａにおいて、制御部１３は、クラウドファンディングの目標条件が満たされたか否かを判定するタイミングが、実施の形態１におけるものと異なる。

【0136】

一例として、目標条件が満たされたか否かの判定は、トランザクションデータの受信をしたときに、当該受信以前に受信したトランザクションデータに係る予約処理によって支払われるトークンの合計が、クラウドファンディングの目標額以上であるか否かを判定することでなされる。

【0137】

以降において、本実施の形態におけるサーバ１０Ａ等の処理を説明する。

【0138】

図８は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。なお、フロー図において、実施の形態１と同じ処理については、同じ符号を付し、詳細な説明を省略する。

【0139】

ステップＳ１０１からＳ１０４において、処理部１１は、募集トランザクションデータおよび予約トランザクションデータを受信して分散台帳に格納する。

【0140】

ステップＳ１３１において、制御部１３は、クラウドファンディングの目標条件が満たされたか否かを判定する。目標条件が満たされたか否かの判定は、ステップＳ１０１で受信した募集トランザクションデータに含まれるコントラクトコードを実行することによってなされる。例えば目標条件が満たされたか否かは、ステップＳ１０４で格納された支払トランザクションデータに基づいて判定される。目標条件が満たされたと判定された場合（ステップＳ１３１でＹｅｓ）には、ステップＳ１３２に進み、そうでない場合（ステップＳ１３１でＮｏ）には、ステップＳ１４１に進む。

【0141】

ステップＳ１３２において、処理部１１は、募集期間が終了したことを申込者Ｕ３等の端末５０等に通知する。なお、ステップＳ１３２は、実行されなくてもよい。その後、制御部１３によって資金の支払いに関する処理がなされ（ステップＳ１０８～Ｓ１１２）、図８に示される一連の処理を終了する。

【0142】

ステップＳ１４１において、制御部１３は、募集期間が終了したか否かを判定する。募集期間が終了したと判定した場合（ステップＳ１４１でＹｅｓ）には、ステップＳ１４２に進み、そうでない場合（ステップＳ１４１でＮｏ）には、ステップＳ１０３に進む。

【0143】

ステップＳ１４２において、制御部１３は、募集期間が終了したことを申込者の端末に通知する。なお、ステップＳ１４２は、実行されなくてもよい。その後、制御部１３は、プロジェクトが不成立であったことを申込者Ｕ３つまり端末５０等に通知し（ステップＳ１２１）、図８に示される一連の処理を終了する。

【0144】

図９は、本実施の形態におけるファンド管理システム１全体の処理を示す第一のシーケンス図である。図９に示されるシーケンス図は、募集期間中に目標条件が満たされた場合を示したものである。

【0145】

ステップＳ２０１からＳ１０４までの処理は、実施の形態１における処理と同じである（図７参照）。

【0146】

制御部１３は、ステップＳ１０４で予約トランザクションデータを分散台帳に格納するたびに、目標条件が満たされたか否かを判定する。目標条件が満たされない場合、再び予約トランザクションデータを受信するまで待機する。目標条件が満たされた場合、申込者Ｕ３等の端末５０等に通知をする。

【0147】

その後、実施の形態１と同様に、ステップＳ１０８からＳ２０２までの処理を実行する。

【0148】

なお、ステップＳ１０９の支払指示は、サーバ１０Ａと異なるサーバ１０Ｂ等によって支払トランザクションデータを生成し、生成したトランザクションデータを分散台帳に格納することにより実現されてもよい。

【0149】

図１０は、本実施の形態におけるファンド管理システム１全体の処理を示す第二のシーケンス図である。図１０に示されるシーケンス図は、募集期間中に目標条件が満たされない場合を示したものである。

【0150】

ステップＳ２０１からＳ１０４までの処理は、実施の形態１における処理と同じである（図７参照）。

【0151】

制御部１３は、ステップＳ１０４で予約トランザクションデータを分散台帳に格納するたびに、目標条件が満たされたか否かを判定する。そして、目標条件が満たされず、かつ、募集期間が終了した場合、募集期間が終了したことを申込者に通知し（ステップＳ１４２）、また、プロジェクトが不成立となったことを通知する（ステップＳ１２１）。

【0152】

このようにすることによって、募集期間の期間中に目標条件が満たされた場合には、募集を終了して支払処理がなされる（図９参照）。よって、提供者は、予め定められた募集期間の終了を待たずに、支払を受けることができる。

【0153】

一方、募集期間の期間中に目標条件が満たされない場合には、実施の形態１と同様に、提供者への支払いがなされない結果となる（図１０参照）。

【0154】

（実施の形態３）
本実施の形態において、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムおよびその制御方法などについて、実施の形態１及び２とは異なる形態について説明する。

【0155】

具体的には、本実施の形態に係るファンド管理システムが管理するクラウドファンディングのプロジェクトでは、募集期間の当初には、目標額が予め定められていて、かつ、申込者１人当たりの支払額が決定していない。そして、申込者が申し込んだ後に、申込者でその目標額を按分することによって申込者１人あたりの支払額が決定し、当該支払額を申込者が支払う。本実施の形態に係るファンド管理システムは、このような形態のプロジェクトを管理する。

【0156】

本実施の形態のプロジェクトでは、申込者が支払うことができる支払額の上限を定める。申込者が申し込んだ後に、申込者１人あたりの支払額が決定するとき、申込者の支払額の上限を超えないように制御される。そのため、申込をした申込者すべてが資金を支払うとは限らない。申込者のうち、資金を支払うことになる申込者を支払者ともいう。

【0157】

例えば、予約トランザクションデータが、当該予約トランザクションデータを送信した申込者が支払うトークンの上限を含んでいる。そして、支払処理において、予め定められた量のトークンを１以上の申込者で按分した量のトークンが、１以上の申込者のうちの一の申込者が支払うトークンの上限を超える場合には、１以上の申込者から上記一の申込者を除外して、予め定められた量のトークンを１以上の申込者で按分する。

【0158】

以降において、本実施の形態において用いられる募集トランザクションデータおよび予約トランザクションデータについて説明する。

【0159】

図１１は、本実施の形態における募集トランザクションデータを模式的に示す説明図である。

【0160】

図１１に示されるように、募集トランザクションデータは、募集者ＩＤと、プロジェクトＩＤと、提供者ＩＤと、募集期限と、目標額と、コントラクトコードと、署名とを含む。

【0161】

図１１に示される募集トランザクションデータは、実施の形態１における募集トランザクションデータ（図３参照）における支払額を含まない点で、実施の形態１におけるものと異なる。申込者１人当たりの支払額が、募集期間中には決定していないからである。

【0162】

図１２は、本実施の形態における予約トランザクションデータを模式的に示す説明図である。

【0163】

図１２に示されるように、予約トランザクションデータは、申込者ＩＤと、プロジェクトＩＤと、支払可能額と、送信日時と、署名とを含む。

【0164】

図１２に示される予約トランザクションデータは、実施の形態１における予約トランザクションデータにおける支払額を含まず、また、新たに支払可能額を含む点で、実施の形態１におけるものと異なる。

【0165】

支払上限額は、当該予約トランザクションデータを送信した申込者が支払うことができる支払額の上限値である。

【0166】

図１３は、本実施の形態におけるサーバ１０Ａの処理を示すフロー図である。

【0167】

本実施の形態におけるファンド管理システム１の構成、サーバの構成、および各種トランザクションデータの構造は、実施の形態１におけるものと同じである（図１、図２参照）。

【0168】

本実施の形態におけるサーバ１０Ａにおいて、制御部１３は、支払額を決定する処理などが実施の形態１におけるものと異なる。

【0169】

以降において、本実施の形態におけるサーバ１０Ａ等の処理を説明する。

【0170】

ステップＳ１０１からＳ１０７までの処理は、実施の形態１におけるものと同じである（図６参照）。

【0171】

ステップＳ１５１において、制御部１３は、支払額と支払者とを決定する。ここで、支払者は、ステップＳ１０３で受信した予約トランザクションデータを送信した申込者のうちから、決定アルゴリズムにより定められる。支払者と支払額との決定アルゴリズムについては、さまざまな方法があり得るが、その一例を後で詳細に説明する。

【0172】

ステップＳ１５２において、制御部１３は、支払いが成立するか否かを判定する。支払いが成立するか否かは、ステップＳ１５１における支払者と支払額との決定アルゴリズムの実行の結果として得られる、「支払いが成立する」又は「支払いが成立しない」との結果情報に基づいて判定され得る。支払が成立すると判定した場合（ステップＳ１５２でＹｅｓ）には、ステップＳ１０９に進み、そうでない場合（ステップＳ１５２でＮｏ）には、ステップＳ１２１に進む。

【0173】

ステップＳ１０９～Ｓ１１２、及び、ステップＳ１２１の処理は、原則として実施の形態１におけるものと同じである。ただし、ステップＳ１１０において、支払トランザクションデータを申込者から受信する点が実施の形態１におけるものと異なる。

【0174】

次に、支払者と支払額との決定アルゴリズムの一例を説明する。

【0175】

図１４は、本実施の形態における制御部１３による支払額の決定アルゴリズムを示すフロー図である。図１４に示されるフロー図は、図１３のステップＳ１５１に含まれる処理の一例である。

【0176】

ステップＳ３０１において、制御部１３は、申込者１人当たりの支払額を決定する。例えば、制御部１３は、目標額を申込者で按分することで、申込者１人あたりの支払額を決定する。

【0177】

ステップＳ３０２において、制御部１３は、申込者それぞれについて、ステップＳ３０１で決定された支払額と、当該申込者の支払可能額とを比較する。そして、制御部１３は、支払額が支払可能額より大きい申込者が存在するか否かを判定する。支払額が支払可能額より大きい申込者が存在すると判定した場合（ステップＳ３０２でＹｅｓ）には、ステップＳ３０３に進み、そうでない場合（ステップＳ３０２でＮｏ）には、「支払いが成立する」という結果情報をもって図１４に示された一連の処理を終了する。

【0178】

ステップＳ３０３において、制御部１３は、支払額が支払可能額より大きい申込者を除外する。

【0179】

ステップＳ３０４において、制御部１３は、申込者が存在するか否かを判定する。つまり、ステップＳ３０３で行う除外の処理のあとに、申込者が少なくとも１人は存在するか否かを判定する。申込者が存在すると判定した場合（ステップＳ３０４でＹｅｓ）には、除外のあとの申込者を対象としてステップＳ３０１の処理を実行し、そうでない場合（ステップＳ３０４でＮｏ）には、「支払いが成立しない」という結果情報をもって図１４に示された一連の処理を終了する。

【0180】

このように、制御部１３は、最初の１以上の申込者のうち、支払上限額を超えた申込者を除外することを繰り返しながら、すべての申込者の支払額が支払上限額以下になるように、各申込者の支払額を決定する。

【0181】

決定アルゴリズムの実行の具体例を説明する。

【0182】

図１５は、本実施の形態における申込者の支払上限額の一例を示す説明図である。図１６は、本実施の形態における制御部１３による支払額の決定アルゴリズムの実行の経過および結果の一例を示す説明図である。

【0183】

ここでは、図１５に示される申込者Ａ、Ｂ、Ｃ、Ｄ、ＥおよびＦ（申込者Ａ～Ｆともいう）が存在するときに、どの申込者が最終的に支払いを行うことになるかを、決定アルゴリズムの実行の経過とともに説明する。なお、申込者Ａ～Ｆそれぞれの支払上限額は、図１５に示される通り、１０、５、２０、２４、１００および６０である。なお、以降の説明において、ステップＳ３０１からＳ３０４の処理をはじめて実行することを１ターン目ともいい、上記処理の２回目の実行を２ターン目ともいう。３ターン目以降も同様である。

【0184】

図１６の（１）に示されるように、１ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が約１７トークンと算出される。この１７トークンという値は、申込者Ａ及びＢの支払上限額より大きいので、申込者Ａ及びＢが除外され（ステップＳ３０３）、申込者Ｃ、Ｄ、ＥおよびＦが存在している状態になる。

【0185】

次に、図１６の（２）に示されるように、２ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が２５トークンと算出される。この２５トークンという値は、申込者Ｃ及びＤの支払上限額より大きいので、申込者Ｃ及びＤが除外され（ステップＳ３０３）、申込者ＥおよびＦが存在している状態になる。

【0186】

次に、図１６の（３）に示されるように、３ターン目には、ステップＳ３０１において、申込者１人当たりの支払額が５０トークンと算出される。この５０トークンという値は、申込者Ｅ及びＦの支払上限額以下であるので、最終的に、申込者Ｅ及びＦが支払者となる。

【0187】

図１７は、本実施の形態におけるファンド管理システム１全体の処理を示すシーケンス図である。

【0188】

ステップＳ２０１からＳ１０７までの処理は、実施の形態１における処理と同じである（図６参照）。

【0189】

制御部１３は、目標条件が満たされた場合（ステップＳ１０７でＹｅｓ）、支払額と支払者とを決定し、その支払いが成立する場合（ステップＳ１５１、Ｓ１５２）に、申込者に支払指示を送信する（ステップＳ１０９）。その後、実施の形態１と同様に、ステップＳ２２２からＳ２０２までの処理を実行する。

【0190】

なお、ステップＳ１０９の支払指示は、サーバ１０Ａと異なるサーバ１０Ｂ等によって支払トランザクションデータを生成し、生成したトランザクションデータを分散台帳に格納することにより実現されてもよい。

【0191】

（各実施の形態の変形例）
なお、上記各実施の形態のファンド管理システムの制御方法は、以下のようにも記載され得るが、これに限定されない。

【0192】

図１８は、各実施の形態の変形例におけるサーバの処理（サーバの制御方法ともいう）を示すフロー図である。

【0193】

図１８に示される一連の処理は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法である。

【0194】

図１８に示されるように、ステップＳ６０１において、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信したトランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。

【0195】

ステップＳ６０２において、クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定する。

【0196】

ステップＳ６０３において、判定の結果を示す情報を出力する。

【0197】

図１９は、各実施の形態の変形例におけるファンド管理システムの構成を模式的に示すブロック図である。

【0198】

図１９に示されるファンド管理システム２は、分散台帳を保有している複数のサーバ６０Ａ、６０Ｂおよび６０Ｃを備える。

【0199】

ファンド管理システム２は、処理部６１と、制御部６３とを備える。

【0200】

処理部６１は、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信したトランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。

【0201】

制御部６３は、クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、判定の結果を示す情報を出力する。

【0202】

これにより、クラウドファンディングにおける資金調達を適切に管理することができる。

【0203】

上記各実施の形態、又は、変形例におけるブロックチェーンについて補足的に説明する。

【0204】

図２０は、ブロックチェーンのデータ構造を示す説明図である。

【0205】

ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。

【0206】

仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。

【0207】

図２１は、トランザクションデータのデータ構造を示す説明図である。

【0208】

図２１に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。

【0209】

トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。

【0210】

以上のように、上記の実施の形態のサーバは、クラウドファンディングにおけるトークンの支払いの予約処理に関する情報をトランザクションデータとして分散台帳に格納する。分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、クラウドファンディングにおけるトークンの支払いの予約処理に関する情報が適切に管理される。また、クラウドファンディングの目標条件が満たされたか否かの判定がスマートコントラクトによりなされるので、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0211】

また、サーバは、クラウドファンディングの予め定められた募集期間が終了したときに、予約処理によって支払われるトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0212】

また、サーバは、予約処理に係るトランザクションデータを受信したときに、予約処理によって支払われるトークンの合計と目標額との大小比較により、目標条件が満たされたか否かを判定するので、上記判定がより容易になされ得る。よって、本発明に係る制御方法は、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0213】

また、サーバは、クラウドファンディングの目標条件が満たされた場合には、トークンの支払処理もスマートコントラクトにより実行する。よって、トークンの支払処理も、他の人又は他のシステムを介在することなく、自動的かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0214】

また、サーバは、予め定められた量のトークンを１以上の申込者それぞれが支払う支払処理に係る予約処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0215】

また、サーバは、予め定められた量のトークンを１以上の申込者で按分した量のトークンを、１以上の申込者それぞれが支払う支払処理に係る予約処理に関する情報を適切に管理する。よって、本発明に係る制御方法は、クラウドファンディングにおける資金調達を適切に管理することができる。

【0216】

また、申込者それぞれについて定められた上限を超えないように申込者の支払額が決定される。よって、本発明に係る制御方法は、クラウドファンディングにおいて、上限を超えない範囲に支払額を収めながら、資金調達を適切に管理することができる。

【0217】

また、目標条件が満たされたか否かの判定処理に用いられるスマートコントラクトのコントラクトコードが、募集者によって生成され得る。よって、募集者の意図を反映したコントラクトコードが生成されることで、募集者の意図をより一層反映した条件判断がなされ得る。よって、本発明に係る制御方法は、募集者の意図をより一層反映可能としながら、クラウドファンディングにおける資金調達を適切に管理することができる。

【0218】

また、サーバは、コンセンサスアルゴリズムの実行を得て分散台帳を格納する。よって、コンセンサスアルゴリズムの実行を得ることによって、より容易に、クラウドファンディングにおける資金調達を適切に管理することができる。

【0219】

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のコンテンツ管理システムなどを実現するソフトウェアは、次のようなプログラムである。

【0220】

すなわち、このプログラムは、コンピュータに、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者から募集者へのトークンの支払いの予約処理に関するトランザクションデータを受信し、受信した前記トランザクションデータを前記複数のサーバそれぞれが備える分散台帳に格納し、前記クラウドファンディングの目標条件が満たされたか否かをスマートコントラクトにより判定し、前記判定の結果を示す情報を出力する制御方法を実行させるプログラムである。

【0221】

以上、一つまたは複数の態様に係るファンド管理システムなどについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

【産業上の利用可能性】

【0222】

本発明は、クラウドファンディングにおける資金調達を適切に管理するファンド管理システムに利用可能である。

【符号の説明】

【0223】

１、２ ファンド管理システム
１０Ａ、１０Ｂ、１０Ｃ、６０Ａ、６０Ｂ、６０Ｃ サーバ
１１、６１ 処理部
１２ 台帳管理部
１３、６３ 制御部
１５ 格納部
１６ 台帳記憶部
４０、４１、５０、５１ 端末
Ｂ１、Ｂ２、Ｂ３ ブロック
Ｎ ネットワーク
Ｐ１ トランザクション本体
Ｐ２ 電子署名
Ｕ１ 提供者
Ｕ２ 募集者
Ｕ３、Ｕ４ 申込者

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】