JP7410890B2 - 制御方法、サーバおよびプログラム - Google Patents

Description

本発明は、制御方法、サーバ、プログラム、および、データ構造に関する。

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

特開２０１７－１５６９２７号公報

しかしながら、クラウドファンディングの成立までに比較的長い時間を要する場合、または、クラウドファンディングの募集期間を経過しても成立しない場合には、その募集期間中にファンド管理システムが稼働するための消費電力が大きくなるという問題がある。

そこで、本発明は、クラウドファンディングの管理システムの消費電力を削減し得る制御方法などを提供する。

本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記分散台帳には、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されており、前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をし、前記クラウドファンディングの目標条件が満たされたと判定した場合に、前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納する。

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

本発明の制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

図１は、実施の形態１におけるファンド管理システムの構成を模式的に示すブロック図である。 図２は、実施の形態１におけるサーバの構成を模式的に示すブロック図である。 図３は、実施の形態１における報酬情報の第一例を示す説明図である。 図４は、実施の形態１における報酬情報の第二例を示す説明図である。 図５は、実施の形態１における報酬額の記録テーブルの一例を示す説明図である。 図６は、実施の形態１における募集トランザクションデータを模式的に示す説明図である。 図７は、実施の形態１における申込トランザクションデータを模式的に示す説明図である。 図８は、実施の形態１における資金提供トランザクションデータを模式的に示す説明図である。 図９は、実施の形態１における報酬提供トランザクションデータを模式的に示す説明図である。 図１０は、実施の形態１における目標判定トランザクションデータを模式的に示す説明図である。 図１１は、実施の形態１における報酬依頼トランザクションデータを模式的に示す説明図である。 図１２は、実施の形態１におけるサーバの処理の第一例を示すフロー図である。 図１３は、図１２に対応するファンド管理システム全体の処理を示すシーケンス図である。 図１４は、実施の形態１におけるサーバの処理の第二例を示すフロー図である。 図１５は、図１４に対応するファンド管理システム全体の処理を示すシーケンス図である。 図１６は、実施の形態１におけるサーバの処理の第三例を示すフロー図である。 図１７は、図１６に対応するファンド管理システム全体の処理を示すシーケンス図である。 図１８は、実施の形態１におけるサーバの処理の第四例を示すフロー図である。 図１９は、図１８に対応するファンド管理システム全体の処理を示すシーケンス図である。 図２０は、実施の形態２における報酬情報の第一例を示す説明図である。 図２１は、実施の形態２における報酬情報の第二例を示す説明図である。 図２２は、実施の形態２における２つのスマートコントラクトが決定する報酬額を示す説明図である。 図２３は、実施の形態２における２つのスマートコントラクトが報酬額を決定する処理を示すシーケンス図である。 図２４は、各実施の形態の変形例１におけるファンド管理システムの構成を模式的に示すブロック図である。 図２５は、各実施の形態の変形例２におけるファンド管理システムの構成を模式的に示すブロック図である。 図２６は、各実施の形態の変形例３におけるサーバの処理を示すフロー図である。 図２７は、各実施の形態の変形例３におけるサーバの構成を模式的に示すブロック図である。 図２８は、ブロックチェーンのデータ構造を示す説明図である。 図２９は、トランザクションデータのデータ構造を示す説明図である。

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

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

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

しかしながら、クラウドファンディングの成立までに比較的長い時間を要する場合、または、クラウドファンディングの募集期間を経過しても成立しない場合には、その募集期間中にファンド管理システムが稼働するための消費電力が大きくなるという問題がある。ファンド管理システムには、１以上のサーバ、１以上の通信機器およびその他の情報機器が含まれ、これらはそれぞれ、動作のために電力を消費する。

そこで、本発明は、クラウドファンディングの管理システムの消費電力を削減し得る制御方法などを提供する。

このような問題を解決するために、本発明の一態様に係る制御方法は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記分散台帳には、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されており、前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をし、前記クラウドファンディングの目標条件が満たされたと判定した場合に、前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納する。

上記態様によれば、申込者がなるべく多くの額の報酬を得る意図をもつので、より早いタイミングで申し込みをすることを促すことになり、クラウドファンディングを早期に成立させることにつながる。そして、クラウドファンディングが早期に成立すれば、その成立以降、クラウドファンディングの管理に必要なサーバの稼働に要する消費電力を削減することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

また、分散台帳に格納されたトランザクションデータの改ざんが実質的に不可能であることから、クラウドファンディングにおける申込又はトークンの提供等の手続きに関する管理情報が適切に管理される。よって、本発明の一態様に係る制御方法によれば、クラウドファンディングにおける手続きを適切に管理できる効果もある。

例えば、前記１以上の申込者のうちの一の申込者から前記第一トランザクションデータを受信した場合、前記一の申込者についての前記報酬の額の前記決定は、前記第一トランザクションデータを受信してから所定時間以内になされてもよい。

上記態様によれば、申し込みにかかるトランザクションデータを受信してから所定時間以内に報酬額を決定する処理を実行するので、処理タイミングが分散することで、サーバの処理負荷が分散し、瞬間的に消費電力が高い状態をとることを未然に回避することができる。よって、本発明に係る制御方法は、処理負荷を時間的に分散させながら、クラウドファンディングの管理システムの消費電力を削減することができる。

例えば、さらに、前記第一トランザクションデータを受信してから所定時間以内に、前記決定に係る前記報酬の額を前記一の申込者に通知してもよい。

上記態様によれば、申込者に報酬額を通知をするので、申込者は、自身に与えられる報酬の額を認識することができ、申込者が新たに申し込みをする、より一層の動機付けを得られる。これにより、クラウドファンディングの管理に必要なサーバの稼働に要する消費電力を、より一層、削減することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

例えば、前記１以上の申込者についての前記報酬の額の前記決定は、前記クラウドファンディングの目標条件が満たされたと判定した後になされてもよい。

上記態様によれば、クラウドファンディングの成立後に全申込者に対する報酬の額を決定する処理を実行するので、クラウドファンディングの全体の状況を考慮して、より適切に報酬の額を決定することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

例えば、前記報酬情報には、前記１以上の申込者のうち、前記クラウドファンディングの募集期間中の所定タイミング以降に申し込みをした申込者に追加で提供する報酬である追加報酬の額がさらに定められており、前記１以上の申込者のうち、前記所定タイミング以降に申し込みをした申込者に追加報酬を提供することを示すトランザクションデータである第三トランザクションデータを前記分散台帳に格納してもよい。

上記態様によれば、申込者に追加報酬を提供するので、募集期間中の所定のタイミング以降であっても、申込者がなるべく多くの額の報酬を得る意図をもってなるべく早いタイミングで申し込みをするので、クラウドファンディングをより一層早期に成立させることができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

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

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

例えば、前記１以上の申込者それぞれに提供する報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行されるスマートコントラクトによりなされてもよい。

上記態様によれば、報酬の額の決定処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

例えば、前記追加報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行されるスマートコントラクトによりなされてもよい。

上記態様によれば、追加報酬の額の決定処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

また、本発明の一態様に係るサーバは、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバであって、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳であって、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されている前記分散台帳に格納する処理部と、前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をする制御部とを備え、前記処理部は、さらに、前記クラウドファンディングの目標条件が満たされたと判定された場合に、前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納する。

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

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

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

また、本発明の一態様に係るデータ構造は、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、前記分散台帳に記録されるデータ構造であって、前記データ構造は、クラウドファンディングの１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報とを含み、前記分散台帳に記録された後に、前記１以上の申込者から前記クラウドファンディングへの申し込みがあった場合、前記報酬情報に基づき前記１以上の申込者それぞれに提供する報酬の額を決定する処理に用いられる。

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

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

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

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

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

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

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

サーバ１０Ａは、ファンド管理システム１によって行われるクラウドファンディングを管理する複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、クラウドファンディングにおける手続または処理（募集、申込、終了判定、報酬提供など）に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、クラウドファンディングにおける手続または処理を受け付ける。なお、プロジェクトにおける資金提供は、一例として、分散台帳により、トークンの提供として管理される。トークンは、分散台帳により管理されている価値情報であり、金銭、商品券またはクーポン等に相当し、又は、交換可能である。

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

ここでは例として、サーバ１０Ａ等のうち、サーバ１０Ａが端末４１等からトランザクションデータを受信したり、端末４１等に通知を送信したりする場合を説明するが、他のサーバ（サーバ１０Ｂまたは１０Ｃ）が上記の処理を行ってもよい。

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

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

端末５０は、申込者が保有する端末装置である。申込者は、資金提供の募集に関する情報を参照し、資金提供の申し込みをする。その後、プロジェクトが成立した場合には、実際に資金が募集者を経て提供者に渡る。また、申込のタイミングに応じた報酬が、クラウドファンディングの管理口座または提供者から申込者に提供される。一方、プロジェクトが成立しなかった場合には、募集者および提供者への資金提供、および、報酬の提供はなされない。

端末５０は、資金提供の申込をする際には、申込のためのトランザクションデータ（申込トランザクションデータ、第一トランザクションデータともいう）を生成し、生成した申込トランザクションデータをサーバ１０Ａに送信する。プロジェクトが成立すると、端末５０は、提供者が提供するコンテンツを取得する。その後、申込者は、コンテンツを利用することができる。

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

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

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

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

処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、ファンド管理システム１内の装置からトランザクションデータを受信した場合、又は、制御部１３が生成したトランザクションデータを取得した場合に、受信又は取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、募集トランザクションデータ、申込トランザクションデータ、資金提供トランザクションデータ、報酬提供トランザクションデータ、目標判定トランザクションデータ、および報酬依頼トランザクションデータが含まれる。各トランザクションデータについては後で詳しく説明する。

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

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

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

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

また、台帳記憶部１６に格納されている分散台帳には、１以上の申込者に提供する報酬の額であって、１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されている。

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

制御部１３は、クラウドファンディングのプロジェクトの目標が達成されたか否かを判定し、資金の提供および報酬の提供に係る処理を制御する処理部である。制御部１３は、クラウドファンディングの目標条件と報酬に関する情報とを、募集トランザクションにより端末４１から受信する。また、制御部１３は、端末５０及び５１からの申込トランザクションにより、資金提供の申し込みを受ける。制御部１３は、クラウドファンディングの目標条件が満たされるか否かを判定し、その判定結果を示す情報を出力する。

また、制御部１３は、上記判定の結果に基づいて、クラウドファンディングに係る処理を制御する。具体的には、制御部１３は、クラウドファンディングのプロジェクトが成立した場合には、各種通知などの処理と、支払トランザクションデータによる資金の支払処理、報酬額の決定処理、報酬の提供のためのトランザクションデータ（報酬提供トランザクションデータ、第二トランザクションデータともいう）による報酬の提供処理をする。

具体的には、制御部１３は、報酬情報を参照し、申込トランザクションデータを受信したタイミングを用いて１以上の申込者それぞれに提供する報酬の額の決定をする。そして、制御部１３は、クラウドファンディングの目標条件が満たされたと判定した場合に、上記決定に従う額の報酬を１以上の申込者それぞれに提供することを示す報酬提供トランザクションデータを処理部１１を介して分散台帳に格納する。

なお、提供される報酬の額を決定するタイミングは、複数あり得る。例えば、制御部１３は、端末５１等からの申し込みごとに報酬の額を決定する。より具体的には、制御部１３は、端末５１等から申込トランザクションデータを受信してから所定時間以内に報酬の額を決定する。所定時間は、例えば、数秒～数分程度である。このとき、申込トランザクションデータを受信してから上記所定時間以内に、上記決定に係る報酬の額を申込者に通知してもよい。これにより、報酬の額の算出処理のタイミングが時間的に分散することで、サーバの処理負荷を分散させる効果がある。

なお、制御部１３は、クラウドファンディングの目標条件が満たされたと判定した後に、報酬の額を決定してもよい。このようにすれば、クラウドファンディングの全体の状況を考慮して報酬情報を変更するなどして、より適切な報酬の額を決定することができる。

なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされ得るが、これに限定されない。例えば、１以上の申込者それぞれに提供する報酬の額の決定は、第一トランザクションデータを分散台帳に格納したことに基づいて実行されるスマートコントラクトによりなされてもよい。

以降において、申込者に提供される報酬について説明する。

申込者に提供される報酬は、募集トランザクションデータに含まれる報酬情報に基づいて、申込者の申し込みのタイミングにより決定される。報酬情報は、例えば、報酬額を規定する関数またはテーブルである。

図３は、本実施の形態における報酬情報の第一例を示す説明図である。図３に示される報酬情報は、報酬額を関数によって規定する報酬情報の例である。

図３において、横軸は、申込のタイミングｘを示していて、縦軸は、各タイミングｘにおける報酬額Ｆ（ｘ）を示している。なお、タイミングｘは、具体的には、順序（つまり、当該プロジェクトにおける何番目の申込であるか）であり、この場合を例として説明するが、他に、時間（つまり、当該プロジェクトの募集の開始からの経過時間）とすることもできる。

関数Ｆ（ｘ）は、原則として、ｘの増加に対して減少する傾向を有する。言い換えれば、報酬額は、申込のタイミングが遅くなるにつれて減少する傾向を有する。より具体的には、関数Ｆ（ｘ）は、ｘに対して単調減少の関数である。ただし、関数Ｆ（ｘ）は、ｘの変化に対して値を維持する区間を含んでもよい。また、関数Ｆ（ｘ）は、例外的にｘの増加に対して増加することを含んでもよく、後述する実施の形態２で詳しく説明される。

制御部１３は、図３に示される報酬情報である関数Ｆ（ｘ）を用いて以下のように報酬額を算出することで決定する。すなわち、制御部１３は、関数Ｆ（ｘ）を用いて、１番目の申し込みをした申込者の報酬額をＦ（１）つまりＥ１と決定し、２番目の申し込みをした申込者の報酬額をＦ（２）つまりＥ２と決定する。また、制御部１３は、Ｎ番目の申し込みをした申込者の報酬額をＦ（Ｎ）つまりゼロと決定する。

図４は、本実施の形態における報酬情報の第二例を示す説明図である。図４に示される報酬情報は、報酬額をテーブルによって規定する報酬情報の例である。

図４に示されるテーブルでは、申込の順番と、その申込をした申込者の報酬額とが対応付けて示されている。上記テーブルにおいても、原則として、申込の順番が遅くなるほど報酬額が減少する傾向を有する。より具体的には、報酬額は、順序に対して単調減少の関係を有する。ただし、報酬額は、順序の変化に対して値を維持する区間を含んでもよい。また、報酬額は、例外的に、順序が遅くなるときに増加することを含んでもよく、後述する実施の形態２で詳しく説明される。

例えば、１番目の申し込みをした申込者の報酬額がＥ１に対応付けられており、２番目の申し込みをした申込者の報酬額がＥ２に対応付けられている。また、Ｎ番目の申し込みをした申込者の報酬額がゼロに対応付けられている。

制御部１３は、図４に示される報酬情報であるテーブルを用いて以下のように報酬額を決定する。すなわち、制御部１３は、テーブルを用いて、１番目の申し込みをした申込者の報酬額をＥ１と決定し、２番目の申込をした申込者の報酬額をＥ２と決定する。また、制御部１３は、Ｎ番目の申し込みをした申込者の報酬額をゼロと決定する。

図３または図４に示されるように、制御部１３は、申込のタイミングが早いほど高い報酬額を決定する。このようにすることで、申込者に、より早いタイミングでの申込をさせることを促す効果がある。

図５は、本実施の形態における報酬額が記録された記録テーブルの一例を示す説明図である。記録テーブルは、制御部１３が報酬額を決定した場合に、決定した報酬額が記録されるテーブルである。

図５に示される記録テーブルは、図３又は図４に示される報酬情報を用いて決定された報酬額の一例が示されている。

具体的には、図５に示される記録テーブルでは、１番目の申し込みをした申込者であるＡに報酬額としてＥ１が決定され、２番目の申し込みをした申込者であるＢに報酬額としてＥ２が決定されたことが記されている。

なお、端末５１等から申込トランザクションデータを受信したタイミングで報酬の額が決定される場合には、記録テーブルには、申込トランザクションデータを受信するごとに順次に申込者と報酬額とが対応付けて記録されていく。一方、プロジェクトが成立したタイミングで報酬の額が決定される場合には、記録テーブルには、プロジェクトが成立した後ですべての申込者と各申込者の報酬額とが対応付けて記録される。

なお、記録テーブルは、制御部１３が使用するメモリまたはストレージに記録されていてもよいし、分散台帳を利用して記録されていてもよい。分散台帳を利用して記録される場合、初期状態の記録テーブルからの更新内容が履歴として分散台帳に記録される。このとき、さらに、記録テーブルの最新状態をメモリまたはストレージに記録するようにしてもよい。

以降において、処理部１１が分散台帳に格納する各種トランザクションデータである、（１）募集トランザクションデータ、（２）申込トランザクションデータ、（３）資金提供トランザクションデータ、（４）報酬提供トランザクションデータ、（５）目標判定トランザクションデータ、および（６）報酬依頼トランザクションデータについて説明する。

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

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

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

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

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

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

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

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

目標判定コードは、当該プロジェクトの目標が達成されたか否か判定を行うスマートコントラクトのコードである。

報酬決定コードは、当該プロジェクトが成立した場合の報酬額の決定を行うスマートコントラクトのコードである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（４）報酬提供トランザクションデータ
図９は、本実施の形態における報酬提供トランザクションデータを模式的に示す説明図である。報酬提供トランザクションデータは、プロジェクトに係るファンドが成立したことに基づいて、報酬提供の際にサーバ１０Ａ等により生成される。なお、報酬提供トランザクションデータは、募集者Ｕ２の端末４１によって生成されサーバ１０Ａ等に送信されてもよい。

図９に示されるように、報酬提供トランザクションデータは、管理口座ＩＤと、申込者口座ＩＤと、報酬額と、提供日時と、署名とを含む。

管理口座ＩＤは、クラウドファンディングの管理口座を一意に特定し得る識別子である。管理口座ＩＤは、報酬の提供元を示している。

申込者口座ＩＤは、報酬の提供を受ける申込者を一意に特定し得る識別子である。

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

提供日時は、当該報酬提供トランザクションデータが格納されたことで報酬の提供がなされた日時を示す情報である。

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

図９に示される報酬提供トランザクションデータは、管理口座ＩＤが「ｍｏａｑ６８０７９」から、申込者口座ＩＤが「ａａｂ０ａａｂ」である申込者口座へ報酬（トークン）を提供するための報酬提供トランザクションデータである。報酬額が「１」トークンであり、この報酬提供トランザクションデータによる報酬の提供日時が「２０１８．１０．１１ ０７：００：００」である。署名は、管理者の電子署名である。

（５）目標判定トランザクションデータ
図１０は、本実施の形態における目標判定トランザクションデータを模式的に示す説明図である。目標判定トランザクションデータは、プロジェクトに係るファンドの目標が達成されたか否かを判定するための判定処理を、サーバ１０Ａ等に実行させるときに、端末４１により生成される。

図１０に示されるように、目標判定トランザクションデータは、募集者ＩＤと、実行コードと、送信日時と、署名とを含む。

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

実行コードは、ファンドの目標が達成されたか否かを判定するためのスマートコントラクトのコードを示す情報である。

送信日時は、当該目標判定トランザクションデータが送信された日時を示す情報である。

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

図１０に示される目標判定トランザクションデータは、募集者ＩＤが「ａａａ００１」である募集者が「目標判定コード」によってファンドの目標の達成の判定をサーバ１０Ａ等にさせるための目標判定トランザクションデータである。この目標判定トランザクションデータの送信日時が「２０１８．１０．０５ １０：００：３０」である。署名は、募集者の電子署名である。

（６）報酬依頼トランザクションデータ
図１１は、本実施の形態における報酬依頼トランザクションデータを模式的に示す説明図である。報酬依頼トランザクションデータは、報酬額を決定する処理をサーバ１０Ａ等に実行させるときに、端末４１により生成される。

図１１に示されるように、報酬依頼トランザクションデータは、募集者ＩＤと、実行コードと、送信日時と、署名とを含む。

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

実行コードは、報酬額を決定するためのスマートコントラクトのコードを示す情報である。

送信日時は、当該報酬依頼トランザクションデータが送信された日時を示す情報である。

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

図１１に示される報酬依頼トランザクションデータは、募集者ＩＤが「ａａａ００１」である募集者が「報酬決定コード」によって報酬額を決定する処理をサーバ１０Ａ等にさせるための報酬依頼トランザクションデータである。この目標判定トランザクションデータの送信日時が「２０１８．１０．１１ ０５：００：００」である。署名は、募集者の電子署名である。

以降において、サーバ１０Ａ等の処理と、ファンド管理システム１全体の処理とについて、報酬の額の決定のタイミングと報酬提供の態様とが異なる４つの例を説明する。

（１）申し込みごとに報酬の額の決定をし、報酬として新たなトークンを発行して提供する場合の例。

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

あらかじめ、提供者Ｕ１の端末４０は、クラウドファンディングのプロジェクトに関する条件を設定し、端末４１に送信している。上記条件は、募集期限、目標額、および支払額を含む。端末４１は、上記条件を含む募集トランザクションデータを生成してサーバ１０Ａ等に送信している。

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

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

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

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

ステップＳ１０５において、制御部１３は、ステップＳ１０３で受信した申込トランザクションデータの送信元である申込者に提供する報酬の額を決定する。報酬の額の決定は、ステップＳ１０１で受信した申込トランザクションデータに含まれていた報酬決定コードを実行することでなされる。また、制御部１３は、決定した報酬の額を申込者に通知してもよい。

ステップＳ１０６において、制御部１３は、募集期間が終了したか否かを判定する。募集期間が終了したか否かは、ステップＳ１０１で受信した募集トランザクションデータに含まれる募集期限が到来しているか否かにより判定される。募集期間が終了したと判定した場合（ステップＳ１０６でＹｅｓ）には、ステップＳ１０７に進み、そうでない場合（ステップＳ１０６でＮｏ）には、ステップＳ１０３に進む。

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

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

ステップＳ１０９において、制御部１３は、ファンドが成立したことを申込者Ｕ３等つまり端末５０等に通知する。なお、ステップＳ１０９は、実行されなくてもよい。

ステップＳ１１０において、制御部１３は、資金提供トランザクションデータを生成する。資金提供トランザクションデータは、申込者から提供者に資金が提供されることを示している。

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

ステップＳ１１２において、制御部１３は、報酬提供トランザクションデータを生成する。生成される報酬提供トランザクションデータには、ステップＳ１０５で決定された報酬額が書き込まれる。上記報酬提供トランザクションデータは、ステップＳ１０５で決定された報酬額の報酬として発行されたトークンが、クラウドファンディングの管理口座から申込者に提供されることを示している。

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

ステップＳ１２１において、制御部１３は、ファンドが不成立であったことを申込者Ｕ３の端末５０等に通知する。なお、ステップＳ１２１は、実行されなくてもよい。

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

次に、ファンド管理システム１の全体の処理を説明する。

図１３は、図１２に対応するファンド管理システム１全体の処理を示すシーケンス図である。図１３には、プロジェクトが成立した場合のファンド管理システム１全体の処理が示されている。なお、図１２のフロー図と同じ処理を示すものは、図１２と同じ符号を付し詳細な説明を省略する。

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

ステップＳ２０１において、端末４１は、端末４０から受信した条件に基づいて、募集トランザクションデータを生成する。生成される募集トランザクションデータには、目標判定コードと報酬決定コードとが含まれている（図６参照）。また、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等に送信する。このとき、端末４１は、生成した募集トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。

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

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

サーバ１０Ａ等は、送信された申込トランザクションデータを受信し、分散台帳に格納する（ステップＳ１０３及びＳ１０４）。また、サーバ１０Ａ等は、申込トランザクションデータの送信元である端末５１に係る申込者Ｕ４の報酬額を決定する（ステップＳ１０５）。また、募集期間が終了した場合には、募集期間が終了したことの通知を送信する（ステップＳ１０６及びＳ１０７）。

そして、サーバ１０Ａ等は、目標条件が満たされた場合には、管理口座から提供者への資金の提供に係る資金提供トランザクションデータと、管理口座から申込者への報酬の提供に係る報酬提供トランザクションデータとを生成し、分散台帳に格納する（ステップＳ１１０～１１３）。

（２）申し込みごとに報酬の額の決定をし、報酬として既存のトークンを提供する場合（サーバ１０Ａが自律的に目標判定と報酬提供とをする場合）の例。

図１４は、本実施の形態におけるサーバ１０Ａ等の処理の第二例を示すフロー図である。なお、図１４に示される処理ステップのうち、破線枠ＳＡ内の処理ステップが図１２における処理と異なる。この部分について重点的に説明する。

処理部１１および制御部１３は、募集者Ｕ２（端末４１）から募集トランザクションデータを受信し、その後、ファンドの目標条件が満たされることでファンドが成立すると、資金提供トランザクションデータを分散台帳に格納する（ステップＳ１０１～ステップＳ１１１）。

ステップＳ１３１において、制御部１３は、ステップＳ１０５で決定した報酬額を募集者Ｕ２つまり端末４１に通知する。

ステップＳ１３２において、処理部１１は、募集者Ｕ２の端末４１から報酬提供トランザクションデータを受信したか否かを判定する。報酬提供トランザクションデータを受信した場合（ステップＳ１３２でＹｅｓ）には、ステップＳ１３３に進み、そうでない場合（ステップＳ１３２でＮｏ）には、ステップＳ１３２に進む。つまり処理部１１は、報酬提供トランザクションデータを受信するまでステップＳ１３２で待機する。

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

次に、ファンド管理システム１の全体の処理を説明する。

図１５は、図１４に対応するファンド管理システム１全体の処理を示すシーケンス図である。なお、図１５に示される処理ステップのうち、破線枠ＳＡ内の処理ステップが図１３における処理と異なる。この部分について重点的に説明する。

ファンド管理システム１は、ファンドが成立すると、資金提供トランザクションデータを分散台帳に格納する（ステップＳ１０１～ステップＳ１１１）。

サーバ１０Ａが報酬額を募集者Ｕ２つまり端末４１に通知すると（ステップＳ１３１）、募集者Ｕ２の端末４１は、報酬提供トランザクションデータを生成してサーバ１０Ａに送信する（ステップＳ２０２）。サーバ１０Ａは、送信された報酬提供トランザクションデータを受信し、分散台帳に格納する（ステップＳ１３２～Ｓ１３３）。

（３）申し込みごとに報酬の額の決定をし、報酬として既存のトークンを提供する場合（募集者からの指示により目標判定と報酬提供とをする場合）の例。

図１６は、本実施の形態におけるサーバ１０Ａ等の処理の第三例を示すフロー図である。なお、図１６に示される処理ステップのうち、破線枠ＳＢ内の処理ステップおよび破線枠ＳＣ内の処理ステップが図１２における処理と異なる。この部分について重点的に説明する。

処理部１１および制御部１３は、募集者Ｕ２の端末４１から募集トランザクションデータを受信し、その後、申込トランザクションデータを受信すると、申込者に提供する報酬額を決定する（ステップＳ１０１～Ｓ１０５）。

ステップＳ１４１において、処理部１１は、ステップＳ１０５で決定した報酬額を募集者に通知する。

ステップＳ１４２において、処理部１１は、目標判定トランザクションデータを受信したか否かを判定する。目標判定トランザクションデータを受信したと判定した場合（ステップＳ１４２でＹｅｓ）には、ステップＳ１４３に進み、そうでない場合（ステップＳ１４２でＮｏ）には、ステップＳ１４２を再び実行する。つまり処理部１１は、目標判定トランザクションデータを受信するまでステップＳ１４２で待機する。

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

ステップＳ１４３を実行した後、制御部１３は、クラウドファンディングのプロジェクトの目標条件が満たされたか否かを判定する（ステップＳ１０８）。このとき、ステップＳ１０６と同様に募集期間が終了したか否かを判定してもよい。

また、処理部１１は、ファンドが成立して資金提供トランザクションデータを分散台帳に格納した後に、ステップＳ１５１において報酬額を募集者Ｕ２つまり端末４１に通知する。

ステップＳ１５２において、処理部１１は、報酬依頼トランザクションデータを受信したか否かを判定する。報酬依頼トランザクションデータを受信したと判定した場合（ステップＳ１５２でＹｅｓ）には、ステップＳ１５３に進み、そうでない場合（ステップＳ１５２でＮｏ）には、ステップＳ１５２を再び実行する。つまり処理部１１は、報酬依頼トランザクションデータを受信するまでステップＳ１５２で待機する。

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

ステップＳ１５４において、ステップＳ１５２で受信した報酬依頼トランザクションデータに含まれる報酬額が、ステップＳ１０５で決定した報酬額と整合しているか否かを判定する。整合していると判定した場合（ステップＳ１５４でＹｅｓ）にはステップＳ１５５に進み、そうでない場合（ステップＳ１５４でＮｏ）には、ステップＳ１５７に進む。

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

ステップＳ１５７において、制御部１３は、報酬額が不整合であることを通知する。なお、ステップＳ１５７は、実行されなくてもよい。

次に、ファンド管理システム１の全体の処理を説明する。

図１７は、図１６に対応するファンド管理システム１全体の処理を示すシーケンス図である。なお、図１７に示される処理ステップのうち、破線枠ＳＢ内の処理ステップおよび破線枠ＳＣ内の処理ステップが図１６における処理と異なる。この部分について重点的に説明する。

サーバ１０Ａが報酬額を端末４１に通知する（ステップＳ１４１）と、端末４１は、ステップＳ２３１において、目標判定トランザクションデータを生成し、生成した目標判定トランザクションデータをサーバ１０Ａ等に送信する。サーバ１０Ａは、端末４１から送信された目標判定トランザクションデータを受信し、分散台帳に格納する（ステップＳ１４２～Ｓ１４３）。

また、サーバ１０Ａ等が資金提供トランザクションデータを分散台帳に格納したあと、報酬額を端末４１に通知する（ステップＳ１５１）と、端末４１は、ステップＳ２３２において、報酬依頼トランザクションデータを生成し、生成した報酬依頼トランザクションデータをサーバ１０Ａ等に送信する。サーバ１０Ａは、端末４１から送信された報酬依頼トランザクションデータを受信して分散台帳に格納し（ステップＳ１５２～Ｓ１５３）、また、報酬提供トランザクションデータを分散台帳に格納する。

（４）ファンド成立後に報酬の額の決定する態様である場合の例。

図１８は、本実施の形態におけるサーバ１０Ａ等の処理の第四例を示すフロー図である。図１９は、図１８に対応するファンド管理システム１全体の処理を示すシーケンス図である。図１８および図１９を参照しながら、サーバ１０Ａ等およびファンド管理システム１全体の処理を説明する。なお、図１８および図１９に示される処理ステップのうち、破線枠ＳＤ内の処理ステップが、それぞれ図１２および図１３における処理と異なる。この部分について重点的に説明する。

処理部１１および制御部１３は、募集者Ｕ２の端末４１から募集トランザクションデータを受信し、その後、申込トランザクションデータを受信すると、受信した申込トランザクションデータを分散台帳に格納する（ステップＳ１０１～ステップＳ１０４）。このあと、制御部１３は、報酬額を決定せず、言い換えれば、報酬額を決定することが制限されている。

次に、制御部１３は、目標条件が満たされたか否かを判定し（ステップＳ１０８）、満たされたと判定した場合には、資金提供トランザクションデータを生成して分散台帳に格納する（ステップＳ１１０、Ｓ１１１）。なお、上記判定の際に、ステップＳ１０６と同様に募集期間が終了したか否かを判定してもよい。

ステップＳ１６１において、制御部１３は、ステップＳ１０３で受信した申込トランザクションデータの送信元である申込者に提供する報酬の額を決定する。報酬の額の決定は、ステップＳ１０１で受信した申込トランザクションデータに含まれていた報酬決定コードを実行することでなされる。

その後、制御部１３は、ステップＳ１６１で決定した報酬額に基づいて報酬提供トランザクションデータを生成して分散台帳に格納する（ステップＳ１１２～Ｓ１１３）。

なお、ステップＳ１１２とＳ１１３との部分（一点鎖線枠ＳＥ内の処理）は、上記（２）のように破線枠ＳＡ内の処理ステップ（つまりステップＳ１３１～Ｓ１３３）に置き換えられてもよいし、又は、上記（３）のように破線枠ＳＣ内の処理ステップ（つまりステップＳ１５１～Ｓ１５７）に置き換えられてもよい。

以上のように、本実施の形態の制御方法によれば、申込者がなるべく多くの額の報酬を得る意図をもつので、より早いタイミングで申し込みをすることを促すことになり、クラウドファンディングを早期に成立させることにつながる。そして、クラウドファンディングが早期に成立すれば、その成立以降、クラウドファンディングの管理に必要なサーバの稼働に要する消費電力を削減することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

また、申し込みにかかるトランザクションデータを受信してから所定時間以内に報酬額を決定する処理を実行するので、処理タイミングが分散することで、サーバの処理負荷が分散し、瞬間的に消費電力が高い状態をとることを未然に回避することができる。よって、本発明に係る制御方法は、処理負荷を時間的に分散させながら、クラウドファンディングの管理システムの消費電力を削減することができる。

また、申込者に報酬額を通知をするので、申込者は、自身に与えられる報酬の額を認識することができ、申込者が新たに申し込みをする、より一層の動機付けを得られる。これにより、クラウドファンディングの管理に必要なサーバの稼働に要する消費電力を、より一層、削減することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

また、クラウドファンディングの成立後に全申込者に対する報酬の額を決定する処理を実行するので、クラウドファンディングの全体の状況を考慮して、より適切に報酬の額を決定することができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を削減することができる。

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

また、報酬の額の決定処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

（実施の形態２）
本実施の形態において、クラウドファンディングの管理システムの消費電力を削減し得るファンド管理システムおよびその制御方法などについて、特に、募集期間のうち終期に比較的近い期間において、より一層早期に成立させ得る技術について説明する。

具体的には、本実施の形態の報酬情報には、１以上の申込者のうち、クラウドファンディングの募集期間中の所定タイミング以降に申込をした申込者に追加で提供する報酬である追加報酬の額がさらに定められている。そして、１以上の申込者のうち、所定タイミング以降に申込をした申込者に追加報酬を提供することを示すトランザクションデータである第三トランザクションデータを分散台帳に格納する。なお、追加報酬の額の決定は、第一トランザクションデータを分散台帳に格納したことに基づいて実行されるスマートコントラクトによりなされてもよい。

本実施の形態にかかるファンド管理システム１およびサーバ１０Ａなどの構成は、実施の形態１におけるものと同じであるが、処理部１１および制御部１３の処理が異なる。

具体的には、制御部１３が受信する募集トランザクションデータに含まれている報酬情報が異なる。また、その報酬情報に基づく報酬の提供方法が異なる。

以降において、報酬情報と、報酬の提供方法について説明する。

（１）報酬情報について
図２０は、本実施の形態における報酬情報の第一例を示す説明図である。図２０に示される報酬情報は、図３と同様に、報酬額を関数によって規定する報酬情報の例である。また、縦軸および横軸の意味は、図３と同様である。

関数Ｆ（ｘ）は、原則として、ｘの増加に対して減少する傾向を有する。言い換えれば、報酬額は、申込のタイミングが遅くなるにつれて減少する傾向を有する。より具体的には、関数Ｆ（ｘ）は、ｘに対して単調減少の関数である。ただし、関数Ｆ（ｘ）は、ｘの変化に対して値を維持する区間を含んでもよい。

また、関数Ｆ（ｘ）は、例外的にｘの増加に対して増加することを含む。具体的には、ｘ＝７の近傍において、ｘの増加に対してＦ（ｘ）が増加する。そして、ｘが７からＮまでの区間では、Ｆ（ｘ）は、図３に示されるＦ（ｘ）より大きな値を有する。

図２０に示される関数Ｆ（ｘ）によれば、１番目の申込をした申込者の報酬額が、Ｆ（１）つまりＥ１と決定され、２番目の申込をした申込者の報酬額が、Ｆ（２）つまりＥ２と決定される。

また、７番目の申込をした申込者の報酬額が、Ｆ（７）つまりＥ７＋Ａ７と決定され、８番目の申込をした申込者の報酬額が、Ｆ（８）つまりＥ８＋Ａ８と決定される。Ｎ番目の申し込みをした申込者の報酬額は、Ｆ（Ｎ）つまりＡＮと決定される。ここで、実施の形態１のＦ（ｘ）に対する本実施の形態のＦ（ｘ）の追加分、例えば、７番目の申込者の報酬額のうちのＡ７、８番目の申込者の報酬額のうちのＡ８などを追加報酬額ともいう。これに対して、実施の形態１のＦ（ｘ）に相当する報酬額を基本報酬額ともいう。

なお、図２０に示される関数Ｆ（ｘ）において、所定タイミングは、ｘ＝７のタイミングに相当する。

図２１は、本実施の形態における報酬情報の第二例を示す説明図である。図２１に示される報酬情報は、図４と同様に、報酬額をテーブルによって規定する報酬情報の例である。

図２１に示されるテーブルでは、申込の順番と、その申込をした申込者の報酬額とが対応付けて示されている。

例えば、１番目の申し込みをした申込者の報酬額がＥ１に対応付けられており、２番目の申し込みをした申込者の報酬額がＥ２に対応付けられている。

例えば、７番目の申し込みをした申込者の報酬額がＥ７＋Ａ７に対応付けられており、８番目の申し込みをした申込者の報酬額がＥ８＋Ａ８に対応付けられている。また、Ｎ番目の申し込みをした申込者の報酬額がＡＮに対応付けられている。

なお、図２１に示されるテーブルにおいて、所定タイミングは、７番目の申し込みのタイミングに相当する。

（２）報酬の提供方法について
上記の報酬情報に基づいて決定される報酬額を提供する方法について２つの例を説明する。

第一例は、サーバ１０Ａ等が実行する単一のスマートコントラクトにより上記報酬額に係る報酬を提供する態様である。

この場合、実施の形態１における制御部１３が実行するスマートコントラクトと同じであるので詳細な説明を省略する。

第二例は、サーバ１０Ａ等が２つのスマートコントラクトを実行し、２つのスマートコントラクトが連携して上記報酬額に係る報酬を提供する態様である。

上記第二例について詳しく説明する。

図２２は、本実施の形態における２つのスマートコントラクトが決定する報酬額を示す説明図である。ここで、上記２つのスマートコントラクトのうち、基本報酬額の決定を行うスマートコントラクトをスマートコントラクト１ともいい、追加報酬額の決定を行うスマートコントラクトをスマートコントラクト２ともいう。

図２２に示されるように、スマートコントラクト１が提供する基本報酬額は、図４に示される報酬額と同様である。

また、スマートコントラクト２が提供する追加報酬額は、１番目の申込者から６番目の申込者までについてはゼロであり、７番目の申込者からＮ番目の申込者までについては、それぞれ、Ａ７、Ａ８、・・・、ＡＮである。

図２３は、本実施の形態における２つのスマートコントラクトが報酬額を決定する処理を示すシーケンス図である。

図２３において、申込者Ａ、Ｂ、・・・、Ｇの端末が順に申込トランザクションデータをサーバ１０Ａに送信する場合を例として説明する。

１番目の申込者である申込者Ａが申込トランザクションデータを送信すると、この申込トランザクションデータがサーバ１０Ａ等の分散台帳に格納され、スマートコントラクト１により報酬額が決定される（ステップＳ１０５）。具体的には、申込者Ａの基本報酬額として報酬額Ｅ１が決定される。このとき、スマートコントラクト２は、申込者Ａの追加報酬額を決定しない。なお、このとき、スマートコントラクト１が基本報酬額を決定したことを知ったスマートコントラクト２が、申込者Ａの追加報酬額をゼロと決定すると考えてもよい。

次に、２番目の申込者である申込者Ｂが申込トランザクションデータを送信すると、この申込トランザクションデータがサーバ１０Ａ等の分散台帳に格納され、スマートコントラクト１により報酬額が決定される（ステップＳ１０５）。具体的には、申込者Ｂの基本報酬額として報酬額Ｅ２が決定される。このとき、スマートコントラクト２は、申込者Ａの追加報酬額を決定しない（または、追加報酬額をゼロと決定する）。

同様に、３番目～６番目の申込者に対してスマートコントラクト１が基本報酬額を決定する。

７番目の申込者である申込者Ｇが申込トランザクションデータを送信すると、この申込トランザクションデータがサーバ１０Ａ等の分散台帳に格納され、スマートコントラクト１により報酬額が決定される（ステップＳ１０５）。具体的には、申込者Ｇの基本報酬額として報酬額Ｅ７が決定される。このとき、スマートコントラクト２は、スマートコントラクト１が基本報酬額を決定した事実を示す通知を取得し、申込者Ｇの追加報酬額をＡ７と決定する（ステップＳ１０５）。

同様に、８番目～Ｎ番目の申込者に対してスマートコントラクト１が基本報酬額を決定し、かつ、スマートコントラクト２が追加報酬額を決定する。

この状態で募集期間が終了し、目標条件が満たされたと判定された場合、スマートコントラクト１により基本報酬額の報酬の提供に係る報酬提供トランザクションデータが生成され、分散台帳に格納される（ステップＳ１１２～Ｓ１１３）。また、スマートコントラクト２により追加報酬額の報酬の提供に係る報酬提供トランザクションデータ（第三トランザクションデータに相当）が生成され、分散台帳に格納される（ステップＳ１１２～Ｓ１１３）。

このようにして、各申込者に基本報酬額および追加報酬額の報酬が提供される。

以上のように、本実施の形態のサーバは、申込者に追加報酬を提供するので、募集期間中の所定のタイミング以降であっても、申込者がなるべく多くの額の報酬を得る意図をもってなるべく早いタイミングで申し込みをするので、クラウドファンディングをより一層早期に成立させることができる。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

また、追加報酬の額の決定処理を、他の人又は他のシステムを介在することなく、早期かつ安全に実行される。よって、本発明に係る制御方法は、クラウドファンディングの管理システムの消費電力を、より一層、削減することができる。

（各実施の形態の変形例１）
本変形例において、上記各実施の形態のファンド管理システムの別の構成について説明する。

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

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

特に、ファンド管理システム２では、サーバ１０Ａ、１０Ｂ及び１０Ｃが互いにネットワークＮを介して接続されている。また、サーバ１０Ａに端末５１が接続されており、サーバ１０Ｂに端末５０が接続されており、サーバ１０Ｃに端末４０及び４１が接続されている。

このような構成は、例えば、複数の団体がファンド管理システム２を運営する場合において、各団体が管理するサーバをネットワークＮを介して接続する場合に利用され得る。例えば、団体Ａにサーバ１０Ａと端末５１とが所属しており、団体Ｂにサーバ１０Ｂと端末５０とが所属しており、団体Ｃにサーバ１０Ｃと端末４０および４１とが所属している。

サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。

（各実施の形態の変形例２）
本変形例において、上記各実施の形態のファンド管理システムの別の構成について説明する。

図２５は、本変形例におけるファンド管理システム３の構成を模式的に示すブロック図である。

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

特に、ファンド管理システム３では、サーバ１０Ｄ、並びに、端末５０および５１が互いにネットワークＮを介して接続されている。また、サーバ１０Ｄに端末４０および４１が接続されている。この場合、端末５０および５１それぞれが、上記各実施の形態におけるサーバ１０Ａ等の動作をする。

このような構成は、例えば、１以上の団体と１以上の個人とがファンド管理システム３を運営する場合において、各団体又は各個人が管理するサーバ又は端末をネットワークＮを介して接続する場合に利用され得る。例えば、団体Ｄにサーバ１０Ｄと端末４０および４１とが所属しており、団体Ｄと、個人である申込者Ｕ４およびＵ３とがファンド管理システム３を運営している。

サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。

（各実施の形態の変形例３）
ここで、各実施の形態の変形例３について説明する。

図２６は、本変形例におけるサーバの処理を示すフロー図である。

図２６に示されるように、ステップＳ６０１において、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した第一トランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。ここで、分散台帳には、１以上の申込者に提供する報酬の額であって、１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されている。

ステップＳ６０２において、報酬情報を参照し、第一トランザクションデータを受信したタイミングを用いて１以上の申込者それぞれに提供する報酬の額の決定をする。

ステップＳ６０３において、クラウドファンディングの目標条件が満たされたと判定した場合に、上記決定に従う額の報酬を１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを分散台帳に格納する。

これにより、クラウドファンディングの管理システムの消費電力を削減することができる。

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

図２７に示されるように、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバは、処理部６１と制御部６３とを備える。

処理部６１は、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した第一トランザクションデータを複数のサーバそれぞれが備える分散台帳に格納する。分散台帳には、１以上の申込者に提供する報酬の額であって、１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されている。

制御部６３は、報酬情報を参照し、第一トランザクションデータを受信したタイミングを用いて１以上の申込者それぞれに提供する報酬の額の決定をする。

処理部６１は、さらに、クラウドファンディングの目標条件が満たされたと判定された場合に、上記決定に従う額の報酬を１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを分散台帳に格納する。

これにより、クラウドファンディングの管理システムの消費電力を削減することができる。

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

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

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

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

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

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

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

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

すなわち、このプログラムは、コンピュータに、分散台帳を保有している複数のサーバを備えるファンド管理システムにおいて、当該複数のサーバのうちの一のサーバが実行する制御方法であって、クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える前記分散台帳に格納し、前記分散台帳には、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されており、前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をし、前記クラウドファンディングの目標条件が満たされたと判定した場合に、前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータを前記分散台帳に格納する制御方法を実行させるプログラムである。

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

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

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

Claims (12)

1. ファンド管理システムにおける制御方法であって、
   クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを分散台帳に格納し、
   前記分散台帳には、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されており、
   前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をし、
   前記クラウドファンディングの目標条件が満たされる前において、前記１以上の申込者のうち、前記クラウドファンディングの募集期間中の所定タイミング以降に申し込みをした申込者に追加報酬の額の決定をし、
   前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータと、前記１以上の申込者のうち、前記所定タイミング以降に申し込みをした申込者に追加報酬を提供することを示すトランザクションデータである第三トランザクションデータとを前記分散台帳に格納する
   制御方法。
2. 前記１以上の申込者のうちの一の申込者から前記第一トランザクションデータを受信した場合、前記一の申込者についての前記報酬の額の前記決定は、前記第一トランザクションデータを受信してから所定時間以内になされる
   請求項１に記載の制御方法。
3. さらに、前記第一トランザクションデータを受信してから所定時間以内に、前記決定に係る前記報酬の額を前記一の申込者に通知する
   請求項２に記載の制御方法。
4. 前記１以上の申込者についての前記報酬の額の前記決定は、前記クラウドファンディングの目標条件が満たされたと判定した後になされる
   請求項１に記載の制御方法。
5. 前記報酬情報には、前記１以上の申込者のうち、前記クラウドファンディングの募集期間中の所定タイミング以降に申し込みをした申込者に追加で提供する報酬である追加報酬の額がさらに定められており、前記報酬情報を参照して、前記追加報酬の額を決定する、
   請求項１～４のいずれか１項に記載の制御方法。
6. 前記トランザクションデータを複数のサーバが備える前記分散台帳に格納する際には、前記複数のサーバそれぞれによるコンセンサスアルゴリズムの実行を経て、前記トランザクションデータを前記分散台帳に格納する
   請求項１～５のいずれか１項に記載の制御方法。
7. 前記１以上の申込者それぞれに提供する報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行される第一スマートコントラクトによりなされる
   請求項１～５のいずれか１項に記載の制御方法。
8. 前記追加報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行される第二スマートコントラクトによりなされる
   請求項５に記載の制御方法。
9. 前記１以上の申込者それぞれに提供する報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行される第一スマートコントラクトによりなされ、
   前記追加報酬の額の前記決定は、前記第一トランザクションデータを前記分散台帳に格納したことに基づいて実行される第二スマートコントラクトによりなされ、
   前記第二スマートコントラクトは、前記第一スマートコントラクトが前記報酬の額を決定した場合に、前記追加報酬の額を決定する、
   請求項５に記載の制御方法。
10. 前記１以上の申込者のうち、１番目から所定の順番までの申込者に対する追加報酬はゼロと決定する、
    請求項１～９のいずれか１項に記載の制御方法。
11. ファンド管理システムにおける複数のサーバのうちの一のサーバであって、
    クラウドファンディングの１以上の申込者からの申し込みに関するトランザクションデータである第一トランザクションデータを受信し、受信した前記第一トランザクションデータを前記複数のサーバそれぞれが備える分散台帳であって、前記１以上の申込者に提供する報酬の額であって、前記１以上の申込者それぞれからの申し込みのタイミングが遅くなるにつれて減少する傾向を有する報酬の額が定められた報酬情報が予め格納されている分散台帳に格納する処理部と、
    前記報酬情報を参照し、前記第一トランザクションデータを受信したタイミングを用いて前記１以上の申込者それぞれに提供する報酬の額の決定をする制御部とを備え、
    前記制御部は、さらに、
    前記クラウドファンディングの目標条件が満たされる前において、前記１以上の申込者のうち、前記クラウドファンディングの募集期間中の所定タイミング以降に申し込みをした申込者に追加報酬の額の決定をし、
    前記決定に従う前記額の前記報酬を前記１以上の申込者それぞれに提供することを示すトランザクションデータである第二トランザクションデータと、前記１以上の申込者のうち、前記所定タイミング以降に申し込みをした申込者に追加報酬を提供することを示すトランザクションデータである第三トランザクションデータとを前記分散台帳に格納する
    サーバ。
12. 請求項１～１０のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。

Images