特許 7144490 システム及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2022-09-20

(45)【発行日】2022-09-29

(54)【発明の名称】システム及びプログラム

(51)【国際特許分類】

   G06Q 20/10 20120101AFI20220921BHJP

   G06F 9/46 20060101ALI20220921BHJP

   G06F 16/182 20190101ALI20220921BHJP

   G06Q 20/38 20120101ALI20220921BHJP

   H04L 9/32 20060101ALI20220921BHJP

【ＦＩ】

G06Q20/10 320

G06F9/46 430

G06F16/182

G06Q20/38 370

H04L9/32 200Z

【請求項の数】 6

(21)【出願番号】P 2020132607

(22)【出願日】2020-08-04

(65)【公開番号】P2022029319

(43)【公開日】2022-02-17

【審査請求日】2020-08-05

【審判番号】

【審判請求日】2021-07-12

【早期審査対象出願】

(73)【特許権者】

【識別番号】598049322

【氏名又は名称】株式会社三菱ＵＦＪ銀行

(74)【代理人】

【識別番号】110000408

【氏名又は名称】弁理士法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】尾根田 倫太郎

(72)【発明者】

【氏名】秋田 佳紀

(72)【発明者】

【氏名】宮澤 勇貴

(72)【発明者】

【氏名】小倉 拓人

【合議体】

【審判長】角田 慎治

【審判官】林 毅

【審判官】富澤 哲生

(56)【参考文献】

【文献】中国特許出願公開第１１０９３０１４９（ＣＮ，Ａ）

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

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

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

G06Q20/10

G06F9/46

G06F16/182

G06Q20/38

H04L9/32

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

【請求項1】

分散された台帳に口座情報を記録する複数のノードのうち１つの第１ノードが、クライアント端末から、前記台帳への口座情報の更新を要求する複数のトランザクションを、前記複数のトランザクションを含むブロック単位で受信するシステムであって、
前記ブロックに含まれる前記複数のトランザクションの各々は、異なる口座間の取引の処理を要求する処理要求データであって、一体不可分の処理単位として扱われ、互いに関連又は依存する複数の処理要求データを含み、前記複数のトランザクションの各々に対して、前記クライアント端末によって付された識別子であって、前記複数のトランザクションが属するブロックを特定する識別子が付される、システム。

【請求項2】

前記第１ノードは、前記第１ノードと前記クライアント端末との１回の通信の確立で、前記複数のトランザクションを受信する、請求項１に記載のシステム。

【請求項3】

前記第１ノードは、前記ブロック単位で前記複数のトランザクションの処理内容及び順序を記録した複数のログを前記台帳に記録する、請求項１に記載のシステム。

【請求項4】

分散された台帳に口座情報を記録する複数のノードのうち１つの第１ノードに、クライアント端末から、前記台帳への口座情報の更新を要求する複数のトランザクションを、前記複数のトランザクションを含むブロック単位で受信することを実行させるためのプログラムであって、
前記ブロックに含まれる前記複数のトランザクションの各々は、異なる口座間の取引の処理を要求する処理要求データであって、一体不可分の処理単位として扱われ、互いに関連又は依存する複数の処理要求データを含み、前記複数のトランザクションの各々に対して、前記クライアント端末によって付された識別子であって、前記複数のトランザクションが属するブロックを特定する識別子を付す、プログラム。

【請求項5】

前記第１ノードと前記クライアント端末との１回の通信の確立で、前記複数のトランザクションを受信することを前記第１ノードに実行させるための、請求項４に記載のプログラム。

【請求項6】

前記第１ノードは、前記ブロック単位で前記複数のトランザクションの処理内容及び順序を記録した複数のログを前記台帳に記録する、請求項４に記載のプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、分散型台帳技術に関するシステム、端末、及びプログラムに関する。

【背景技術】

【0002】

ブロックチェーンを用いた分散型台帳技術が、ビットコイン等の暗号資産（仮想通貨）を管理する方法として用いられている。近年では、これらの技術は、このような暗号資産だけではなく、様々な資産を管理したり移動したりする方法として用いることも検討されている（例えば、特許文献１）。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

特許文献１に示した分散型台帳技術では、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって接続された複数のノード（１つのリーダノード及びその他の複数のフォロワノード）によって分散台帳ネットワークが形成され、当該分散台帳ネットワークにおける複数のノードによって台帳が分散して記録される。

【0005】

上記のような従来の分散型台帳技術においては、クライアント端末からの取引要求に対する処理の高速化及び複数のノード間における整合性の確保は重要な課題である。

【0006】

本発明の目的の一つは、分散型台帳技術において、取引要求に対する処理の高速化又は複数のノード間において整合性を確保することである。

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

【0007】

本発明の一実施形態に係るシステムは、台帳を分散して記録する複数のノードのうち１つの第１ノードが、クライアント端末から複数のトランザクションを、前記複数のトランザクションを含むブロック単位で受信する。

【0008】

前記第１ノードは、前記第１ノードと前記クライアント端末との１回の通信の確立で、前記複数のトランザクションを受信してもよい。

【0009】

前記第１ノードは、前記複数のトランザクションの各々に対して、前記複数のトランザクションが属するブロックを特定する識別子を付してもよい。

【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】

【図1】本発明の一実施形態に係る分散型台帳システムの概要を示す図である。

【図2】本発明の一実施形態に係る分散型台帳システムの概要を示す図である。

【図3】本発明の一実施形態に係る分散型台帳システムの概要を示す図である。

【図4】本発明の一実施形態に係る分散型台帳システムにおけるブロックの概念図である。

【図5】本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。

【図6】本発明の一実施形態に係る分散型台帳システムにおけるトランザクション及びログの具体例を示す図である。

【図7】本発明の一実施形態に係る分散型台帳システムに用いられるクライアント端末の機能構成を示すブロック図である。

【図8】本発明の一実施形態に係る分散型台帳システムに用いられるフォロワノードの機能構成を示すブロック図である。

【図9】本発明の一実施形態に係る分散型台帳システムの動作を示すシーケンスを示す図である。

【図10】本発明の一実施形態に係る分散型台帳システムの動作を示すフローチャートを示す図である。

【図11】本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。

【図12】本発明の一実施形態に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。

【図13】本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。

【図14】本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。

【図15】本発明の一実施形態に係る分散型台帳システムにおけるデータ同期アルゴリズムの動作を示すフローチャートを示す図である。

【図16】本発明の一実施形態に係る分散型台帳システムにおけるグループの概念図である。

【図17】本発明の一実施形態に係る分散型台帳システムにおけるグループの概念図である。

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

【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】

１０：分散型台帳システム、 ３１～３８：台帳、 ４１～４７：クライアント端末、 １００～１０３：ノード、 １１０～１１３：サーバ、 １２０～１２３：データベース、 ２００：リーダノード、 ２２０：受信部、 ２３０：整列処理部、 ２３１Ａ：排他制御機能、 ２４０：ログ生成部、 ２５０：分散処理部、 ２５１Ａ：データ同期アルゴリズム機能、 ２６０：データ更新部、 ２９０：通信バス、 ３００～３０４：フォロワノード、 ３１０：ログ受信部、 ３２０：ログ格納部、 ３３０：合意形成部、 ３４０：データ更新部、 ３９０：通信バス、 ４００～４０４：クライアント端末、 ４１０～４１４：クライアントプロセス、 ４２０：取引要求受信部、 ４３０：生成部、 ４４０：バッファリング部、 ４５０：通信部、 ４６０：送信部、 ４９０：通信バス、 ５００：ネットワーク、 ６００：専用ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】