JP7311020B2 - 制御方法、情報処理装置及び制御プログラム - Google Patents

Description

本発明は、制御方法、情報処理装置及び制御プログラム
に関する。

ブロックチェーンを構成するデータとして分散台帳に記録される各ブロックは、一定時間間隔ごと又は一定の取引数ごと等の所定の単位ごとに生成される。したがって、一つのブロック内には、複数の取引に関する情報が含まれうる。

なお、取引とは、例えば、仮想通貨の取引であれば、送金元の取引者から送金先の取引者への送金をいい、送金元の取引者（例えば、ユーザＡ）、送金先の取引者（例えば、ユーザＢ）、送金額等をパラメータとする。このような取引では、各取引者の残高の識別情報（例えば、「Ａの残高」）をキーとし、当該残高を示す数値を値として管理するデータベースが更新される。ユーザＡからユーザＢへの送金の取引であれば、「Ａの残高」キーに対応する値から送金額が減算され、「Ｂの残高」キーに対応する値に送金額が加算される。

国際公開第２０１８／１２４２９７号

同一のブロックに含まれる複数の取引に基づくデータベースの更新は、一括して実行される。したがって、同一のキーに対する値を更新対象とする複数の取引が同一のブロックに含まれている場合、複数の取引の間でコンフリクトが発生し、当該キーの値について、整合性を保持できない可能性が有る。そのため、同一のキーに対する値を更新対象とする複数の取引が同一のブロックに含まれている場合、当該複数の取引のうちの最初の取引のみが実行され、２番目以降の取引はエラーとしてその実行が抑制されている。

この場合、実行が抑制された取引を再実行する必要が生じ、取引の実行が遅延してしまうことになる。さらに、取引を再実行したとしても、再実行時のブロックでも同じ状況になる可能性がある。

そこで、一側面では、本発明は、データベースの更新のコンフリクトを抑制することを目的とする。

一つの案では、ブロックチェーンに記録された取引データに含まれる取引量の集計値を記録する集計項目を含むデータベースの制御方法において、前記ブロックチェーンに記録された複数の前記取引データを取得する処理と、前記集計項目に対応付く第１のユーザとの取引相手である複数の第２のユーザごとに、前記複数の取引データに基づいて前記第１のユーザとの取引時期を特定する処理と、前記取引時期の非類似性に基づいて、前記複数の第２のユーザを複数のグループに分類する処理と、前記グループ別の集計項目を前記データベースに生成する処理と、をコンピュータが実行する。

一態様によれば、データベースの更新のコンフリクトを抑制することができる。

本発明の実施の形態における取引管理システム１の構成例を示す図である。 本発明の実施の形態における取引管理システム１を構成する各ノード１０のハードウェア構成例を示す図である。 本発明の実施の形態における取引管理システム１を構成する各ノード１０の機能構成例を示す図である。 キーの分割処理の処理手順の一例を説明するためのフローチャートである。 取引履歴Ｈに基づく他ユーザ別の単位時間ごとの取引数の時系列の集計結果の一例を示す図である。 他ユーザのクラスタリング結果の一例を示す図である。 他ユーザのグループへの分類例を示す図である。 残高キーの分割後において実行される残高ＤＢ１６１の更新処理の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における取引管理システム１の構成例を示す図である。図１において、複数のユーザ端末２０は、インターネット等のネットワークを介して取引管理システム１に接続される。

ユーザ端末２０は、送金等の各種の取引（以下、単に「取引」という。）の当事者（送金元のユーザ及び送金先のユーザ（以下、単に「ユーザ」という。））が利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等がユーザ端末２０として利用されてもよい。

取引管理システム１は、ユーザ端末２０間で行われる取引を管理するＰ２Ｐネットワーク（ブロックチェーンネットワーク）であり、分散型台帳技術が適用された複数のコンピュータ又は情報処理装置（ノード１０）の集合を含む。各ノード１０は、ブロックチェーンネットワークによって接続され、共通の台帳情報を分散して管理する記憶部（以下、「台帳」という。）を有する。台帳には、取引の履歴を示すブロックチェーンが記録される。例えば、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ等のフレームワーク実装が用いられて取引管理システム１が実現されてもよい。

図２は、本発明の実施の形態における取引管理システム１を構成する各ノード１０のハードウェア構成例を示す図である。各ノード１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

ノード１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってノード１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図３は、本発明の実施の形態における取引管理システム１を構成する各ノード１０の機能構成例を示す図である。図３に示されるように、各ノード１０は、台帳１６等の記憶部を利用する。台帳１６は、例えば、補助記憶装置１０２、又はノード１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

台帳１６は、上記したように、各ノード１０が共通の台帳情報を分散して管理するための記憶部である。台帳１６は、ブロックチェーンＣ１及び残高ＤＢ１６１等を格納する。

ブロックチェーンＣ１は、ブロックの順序付けられたリストである。各ブロックには、一定時間間隔ごと又は一定の取引数ごと等の所定の単位ごとに発生した１以上の各取引について、それぞれのパラメータを含むデータ（以下、「取引データ」という。）が格納される。本実施の形態では、ユーザ間の送金を取引の一例として説明する。したがって、例えば、送金日時、送金元のユーザ名、送金先のユーザ名及び送金額等が取引データに含まれる。

残高ＤＢ１６１は、ユーザ間の取引量（取引額）の集計値（ユーザごとの残高）を記録する集計項目を含むデータベースである。各ユーザの残高に対応する集計項目の値（集計値）は、取引の実行によって更新される。すなわち、送金元のユーザの残高から送金額が減算され、送金先のユーザの残高に送金額が加算される。なお、残高ＤＢ１６１において、各ユーザの残高は、キー・バリュー形式で格納される。残高の集計項目は、キーに対応し、集計値はバリューに対応する。すなわち、残高ＤＢ１６１は、ユーザごとに、当該ユーザの残高を識別するためのキー（例えば、「Ａの残高」）に対応付けて、当該残高を示す数値を記憶する。但し、残高ＤＢ１６１は、ＲＤＢ（Relational Database）等、キーバリューストア以外のデータベースであってもよい。例えば、残高ＤＢ１６１がＲＤＢであれば、「Ａの残高」という項目名がキーに対応し、「Ａの残高」という項目の値がバリューに対応する。

ここで、同一キーにアクセスする複数の取引データが一つのブロックに含まれている場合、当該複数の取引データに係る各取引の実行のコンフリクト（衝突）のため、最初の取引データ以外の取引データに係る各取引は失敗してしまう。本実施の形態では、斯かるコンフリクトを回避するため、コンフリクトが発生しやすいキーを複数のキーに分割することを考える。具体的には、キー「Ａの残高」を「Ａの食費残高」及び「Ａの光熱費残高」に分割することを考える。こうすることにより、「Ａの残高」を更新する取引のうち、ユーザＡの食費の残高を更新する取引であれば、「Ａの食費残高」の値を更新対象とし、ユーザＡの食費の光熱費を更新する取引であれば、「Ａの光熱費残高」の値を更新対象とする。その結果、更新対象のキーが分散されるため、同一キーに対するアクセス頻度の低下を期待できる。したがって、同一キーへのアクセスのコンフリクトの回避を期待することができる。

しかしながら、この場合、例えば、そもそも「Ａの残高」に対する取引のほとんどが、「Ａの食費残高」キーに対応する取引であった場合、同一キーへのアクセスのコンフリクトの回数の低減効果は少ないと考えられる。また、ユーザは、分割後のキーに合わせて、取引を分割して行う必要があり、結果として取引数の増加を招いてしまう。

そこで、本実施の形態の各ノード１０は、上記の問題も回避可能とするために、取引履歴取得部１１、取引時期特定部１２、ユーザ分類部１３、キー分割部１４及び更新部１５等を有する。これら各部は、ノード１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。例えば、スマートコントラクト（Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃの場合、チェーンコード）がＣＰＵ１０４に実行させる処理により各部が実現されてもよい。

取引履歴取得部１１は、ユーザごとに、直近の過去の一定期間Ｔ１においてブロックチェーンＣ１のいずれかのブロックに格納された取引データ（当該ユーザが送金元又は送金先である取引データ）の集合を取得する。取引時期特定部１２は、一定期間Ｔ１を細分化する単位時間Ｔ２ごとに、各ユーザについて、当該ユーザとの取引相手の各ユーザの取引時期を時系列順に特定する。ユーザ分類部１３は、ユーザごとに、当該ユーザとの取引相手の各ユーザを、当該ユーザとの取引時期の非類似性に基づいて複数のグループに分類する。キー分割部１４は、ユーザごとに、当該ユーザの取引の残高を集計するキー（集計項目）を、当該ユーザについて分類されたグループ別に生成することで、当該キーを実質的に分割する。更新部は、取引データに基づいて残高ＤＢ１６１を更新する。

以下、各ノード１０が実行する処理手順について説明する。図４は、キーの分割処理の処理手順の一例を説明するためのフローチャートである。なお、図４の処理手順は、一定期間Ｔ１間隔で繰り返し実行される。一定期間Ｔ１は、ブロックチェーンＣ１に接続される新たなブロックが生成される周期と同じであってもよい。この場合、図４の処理手順は、新たなブロックの生成に応じて実行されてよい。

まず、取引を行う候補者であるユーザごとに、ステップＳ１０１～Ｓ１１０を含むループ処理Ｌ１が実行される。ループ処理Ｌ１において処理対象とされているユーザを「対象ユーザ」という。

ステップＳ１０１において、取引履歴取得部１１は、直近の過去の一定期間Ｔ１においてブロックチェーンＣ１のいずれかのブロックに格納された取引データのうち、対象ユーザに対応する取引データの集合（以下、「取引履歴Ｈ」という。）をブロックチェーンＣ１から取得する。対象ユーザに対応する取引データとは、対象ユーザを送金先又は送金元とする取引データ（すなわち、対象ユーザの残高の更新の原因となる取引データ）をいう。したがって、例えば、ユーザＡが対象ユーザである場合、ユーザＡが送金先又は送金元であり、直近の一定期間Ｔ１における取引データの集合が取引履歴Ｈとして取得される。

続いて、取引時期特定部１２は、一定期間Ｔ１を細分化する単位時間Ｔ２ごとに、取引履歴Ｈにおける取引データの数（つまり、取引数）を対象ユーザとの取引相手であるユーザ（以下、「他ユーザ」という。）別に時系列に集計する（Ｓ１０２）。

図５は、取引履歴Ｈに基づく他ユーザ別の単位時間ごとの取引数の時系列の集計結果の一例を示す図である。図５において、１行目は、各単位時間が何番目の単位時間であるのかを示すために便宜上付与された行である。図５の例では、一定期間Ｔ１がＭ個の単位時間に区切れられた例が示されている。

２行目以降の各行の各列は、他ユーザ別の各列に対応する各時間帯における取引数の集計結果である。図５の集計結果により、対象ユーザ以外の複数の他ユーザのそれぞれについて、対象ユーザとの取引時期を特定することができる。なお、他ユーザごとの各行は、各単位時間の集計値を要素とし、長さＭのベクトルとみなすことができる。以下、当該ベクトルを「集計値ベクトル」という。

続いて、ユーザ分類部１３は、複数の他ユーザのそれぞれの集計値ベクトルの類似性に基づいて、当該複数の他ユーザを公知の方法でクラスタリングして、Ｎ個のクラスタを生成する（Ｓ１０３）。すなわち、当該複数の他ユーザが複数（Ｎ個）のクラスタｇ１～ｇＮに分類される。集計値ベクトルの類似性は、例えば、集計値ベクトルの類似度によって評価されてもよい。当該類似度としては、コサイン類似度等、公知の指標が用いられればよい。

図６は、他ユーザのクラスタリング結果の一例を示す図である。図６では、ユーザＢ及びＤがクラスタｇ１に分類され、ユーザＣがクラスタｇ２に分類された例が示されている。このことは、ＡとＢとの間の取引と、ＡとＤとの間の取引とは同じ時間帯に発生する傾向に有る（すなわち、コンフリクトしやすい）ことを示す。

続いて、キー分割部１４は、ユーザ分類部１３によって生成されたＮ個の各クラスタの要素数の中での最大値ｋ個分のグループＧ１～Ｇｋを生成する（Ｓ１０４）。図６の例によれば、クラスタｇ１の要素数（ユーザ数）＝２が最大である。したがって、この場合、グループＧ１及びグループＧ２の２つのグループが生成される。

続いて、キー分割部１４は、各クラスタのｉ番目（１≦ｉ≦ｋ）の他ユーザを、ｉ番目のグループＧｉに分類する（Ｓ１０５）。したがって、取引時期の傾向が類似しない他ユーザ同士が同じグループに分類される。すなわち、ステップＳ１０５では、他ユーザが、取引時期の非類似性に基づいて複数のグループに分類される。

図７は、他ユーザのグループへの分類例を示す図である。図７では、ユーザＢ及びＣが同一グループ（グループＧ１）に分類され、ユーザＤが別のグループ（グループＧ２）に分類された例が示されている。

続いて、キー分割部１４は、対象ユーザの残高に対応するキー（以下、「残高キー」という。）の分割処理が過去に実行されたことが有るか否か判定する（Ｓ１０６）。すなわち、対象ユーザについて、ステップＳ１０７が実行されたことが有るか否かが判定される。この判定方法については後述する。

対象ユーザの残高キーの分割処理が実行されたことが無い場合（Ｓ１０６でＮｏ）、キー分割部１４は、残高ＤＢ１６１における対象ユーザの残高キーのキー名を、「＜対象ユーザのユーザ名＞－分割時残高」に置換する（Ｓ１０７）。ここで、＜対象ユーザのユーザ名＞には、対象ユーザのユーザ名が入る。したがって、ユーザＡが対象ユーザであれば、残高ＤＢ１６１における「Ａの残高」キーのキー名が、「Ａ－分割時残高」に置換される。「Ａ－分割時残高」キーは、ユーザＡの残高キーの分割時における当該残高キーの値（すなわち、キーの分割時にユーザＡの残高がいくらであったのか）を保持するためのキーである。以下、置換後のキー名に係るキーを「分割時残高キー」という。

続いて、キー分割部１４は、ステップＳ１０４において生成されたグループごとに、当該グループに対応する取引キーを残高ＤＢ１６１に生成する（Ｓ１１０）。この際、生成された各取引キーに対応する値は０に初期化される。ここで、グループに対応する取引キーとは、対象ユーザと当該グループに属するユーザとの取引の集計値を値とするキーをいう。例えば、グループＧ１に対応する取引キーは、ユーザＡとユーザＢとの間の取引額、又はユーザＡとユーザＣとの間の取引額の集計値を値とするキーである。本実施の形態では、グループＧ１に対応する取引キーのキー名を「Ａ－Ｂ，Ｃ」とし、グループＧ２に対応するキー名を「Ａ－Ｄ」とすることとする。すなわち、取引キーのキー名は、「対象ユーザのユーザ名－他ユーザのユーザ名」という形式を有する。すなわち、「－」の前が対象ユーザのユーザ名であり、「―」の後が対象ユーザとの取引相手となる１以上の他ユーザのユーザ名である。このような取引キーの値（取引額）は、「－」の前のユーザ名に係るユーザからの送金に応じて送金額分だけ減算され、当該ユーザへの「－」の後のユーザ名に係るユーザからの送金に応じて送金額分だけ加算される。例えば、「Ａ－Ｄ」キーの値（取引額）であれば、ユーザＡからＤへの送金に応じて送金額が減算され、ユーザＤからＡへの送金に応じて送金額が加算される。すなわち、取引キーとは、残高キーの分割後の取引量の集計値を値とするキーである。また、各取引によっていずれのキーの値が更新対象となるのかについては、キー名によって識別可能である。すなわち、取引キーのキー名には、取引に係るユーザと更新対象のキーとの対応情報が含まれる。但し、このような対応情報が含まれない文字列（例えば、「Ａの取引１」、「Ａの取引２」等）が取引キーのキー名とされてもよい。この場合は、「Ａの取引１」キーが、ＡとＢ又はＡとＣとの間の取引に対応するキーであり、「Ａの取引２」キーが、ＡとＤとの間の取引に対応するキーであることを示す対応情報が、別途、補助記憶装置１０２等に記憶されてもよい。

一方、ステップＳ１０６において、対象ユーザの残高キーの分割処理が実行されたことが有ると判定された場合（Ｓ１０６でＹｅｓ）、ステップＳ１０７の代わりにステップＳ１０８及びＳ１０９が実行される。なお、上述したように、ステップＳ１０７が実行されたユーザの残高キーのキー名は「＜対象ユーザのユーザ名＞－分割時残高」に置換される。したがって、ステップＳ１０６の判定は、対象ユーザの分割時残高キーの有無に基づいて行うことができる。

ステップＳ１０８において、キー分割部１４は、対象ユーザの分割時残高キーの値を、対象ユーザの各取引キーの値によって更新する。具体的には、キー分割部１４は、対象ユーザの各取引キーの値を対象ユーザの分割時残高キーの値に加算する。例えば、対象ユーザがユーザＡであり、ユーザＡの取引キーが上記した通りである場合、「Ａ－分割時残高」キーの値に対して、「Ａ－Ｂ，Ｃ」キーの値と「Ａ－Ｄ」キーの値とが加算される。その結果、前回のユーザＡの取引キーの生成後における、ユーザＡと他ユーザとの取引の結果がユーザＡの分割時残高キーに反映される。

続いて、キー分割部１４は、対象ユーザの全ての取引キー及び当該取引キーに対応する値を残高ＤＢ１６１から削除する（Ｓ１０９）。続けて、ステップＳ１１０が実行されることにより、対象ユーザの残高キーについて、改めて分割がし直されることになる。

上述したステップＳ１０１～Ｓ１１０が全てのユーザについて実行され、ループ処理Ｌ１が終了すると、図４の処理手順の実行は終了する。

図４の処理手順が繰り返し（一定期間Ｔごとに）実行されることにより、各ユーザの残高を管理するためのキーは、以下のように変更されうる。

例えば、上記のように、「Ａの残高」キーが、「Ａ－分割時残高」キー、「Ａ－Ｂ，Ｃ」キー、及び「Ａ－Ｄ」キーに分割された後において、Ａ－Ｂ間の取引とＡ－Ｃ間の取引が衝突しやすくなると、図４の処理手順の再度の実行により（この際は、Ｓ１０８及びＳ１０９が実行される）、ユーザＡに関するキーは、以下のように分割し直される。
－「Ａ－分割時残高」キー
－「Ａ－Ｂ」キー
－「Ａ－Ｃ」キー
－「Ａ－Ｄ」キー
すなわち、或るキーの値の更新が衝突しやすいことが後から分かった場合でも、当該キーをより細かく分割し直すことができる。したがって、上記の例では、Ａ－Ｂ間の取引とＡ－Ｃ間の取引の衝突を抑制することが可能となる。

一方、Ａ－Ｂ間の取引、Ａ－Ｃ間の取引、Ａ－Ｄ間の取引が衝突しにくいのであれば、図４の処理手順の再度の実行により、ユーザＡに関するキーは、以下のように分割し直される。
－「Ａ－分割時残高」キー
－「Ａ－Ｂ，Ｃ，Ｄ」キー
すなわち、衝突しにくいキーが複数の分割されてしまっている場合、当該キーが結合しなおすことができる。上記の例では、ユーザＡと他のユーザとの間の取引キーが結果的に一つにまとめられることになる。その結果、ユーザＡの残高の集計のための読み出し回数を減らすことができ、平均処理時間を抑えることができる。

続いて、残高キーの分割後において実行される残高ＤＢ１６１の更新処理について説明する。図８は、残高キーの分割後において実行される残高ＤＢ１６１の更新処理の処理手順の一例を説明するためのフローチャートである。

更新部１５は、新たな取引データ（当該取引データのキーの値の更新要求）を受信すると（Ｓ２０１でＹｅｓ）、当該取引データ（以下、「対象取引データ」という。）を、現在生成途中のブロックの最後尾に追加する（Ｓ２０２）。続いて、更新部１５は、対象ブロックが完成したか否かを判定する（Ｓ２０３）。例えば、対象ブロックの生成開始からの経過時間が一定時間に到達したか、又は対象ブロックに含まれる取引データの数が一定数以上であるか等によって、対象ブロックが完成したか否かが判定される。

対象ブロックが完成していない場合（Ｓ２０３でＮｏ）、ステップ２０１へ戻る。対象ブロックが完成した場合（Ｓ２０３でＹｅｓ）、更新部１５は、対象ブロック内において更新のコンフリクトが有るか否かを判定する（Ｓ２０４）。すなわち、対象ブロックについて、同一キーの値を更新対象とする複数の取引データの有無が判定される。

更新のコンフリクトが無い場合（Ｓ２０４でＮｏ）、更新部１５は、対象ブロック内の各取引データに基づいて、残高ＤＢ１６１のキーの値を更新する（Ｓ２０５）。この際、取引データごとに、当該取引データにおいて送金元のユーザの取引キーの値（集計値）と、当該取引データにおいて送金先のユーザの取引キーの値（集計値）とが、当該取引データの送金額（取引量）に基づいて更新とされる。具体的には、送金元のユーザの取引キーの値から送金額が減算され、送金先の取引キーの値に対して送金額が加算される。例えば、ユーザＡからユーザＢへの送金であれば、「Ａ－Ｂ＊」キー（＊は、ユーザＡ以外の０以上のユーザ名）の値から送金額が減算され、「Ｂ－Ａ＊」キー（＊は、ユーザＢ以外の０以上のユーザ名）の値に送金額が加算される。

一方、更新のコンフリクトが有る場合（Ｓ２０４でＹｅｓ）、更新部１５は、対象ブロック内において、同一キーの値を更新する後発の取引データを除外した各取引データに基づいて、残高ＤＢ１６１のキーの値を更新する（Ｓ２０６）。すなわち、同一キーの値を更新する後発の取引データに係る取引は失敗する。ステップＳ２０５又はＳ２０６に続いて、ステップＳ２０１へ戻る。

なお、本実施の形態では、図４の処理手順の実行により、更新のコンフリクトの抑制が期待されるため、ステップＳ２０６の実行（すなわち、取引の失敗）を抑制することができる。

上述したように、本実施の形態によれば、各ユーザについて、過去の当該ユーザに係る取引データに基づいて、当該ユーザとの取引相手ごとに取引時期が特定され、取引時期の非類似性に基づいて取引相手群が複数のグループに分類され、グループ別のキー（集計項目）が残高ＤＢ１６１に生成される。したがって、取引時期が類似するユーザ間の取引に関する集計は、異なるキー（集計項目）によって行われるようになる。その結果、データベース（残高ＤＢ１６１）の更新のコンフリクトを抑制することができる。

なお、本実施の形態において、ノード１０は、情報処理装置の一例である。残高ＤＢ１６１は、データベースの一例である。取引履歴取得部１１は、取得部の一例である。取引時期特定部１２は、特定部の一例である。ユーザ分類部１３は、分類部の一例である。キー分割部１４は、生成部の一例である。

１ 取引管理システム
１０ ノード
１１ 取引履歴取得部
１２ 取引時期特定部
１３ ユーザ分類部
１４ キー分割部
１５ 更新部
１６ 台帳
２０ ユーザ端末
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１６１ 残高ＤＢ
Ｂ バス
Ｃ１ ブロックチェーン

Claims (6)

1. ブロックチェーンに記録された取引データに含まれる取引量の集計値を記録する集計項目を含むデータベースの制御方法において、
   前記ブロックチェーンに記録された複数の前記取引データを取得する処理と、
   前記集計項目に対応付く第１のユーザとの取引相手である複数の第２のユーザごとに、前記複数の取引データに基づいて前記第１のユーザとの取引時期を特定する処理と、
   前記取引時期の非類似性に基づいて、前記複数の第２のユーザを複数のグループに分類する処理と、
   前記グループ別の集計項目を前記データベースに生成する処理と、
   をコンピュータが実行することを特徴とする制御方法。
2. 前記分類する処理は、前記取引時期の類似性に基づいて、前記複数の第２のユーザを複数のクラスタに分類し、同一の前記クラスタに分類された前記第２のユーザ同士が同一のグループに含まれないように、前記第２のユーザを複数のグループに分類する、
   ことを特徴とする請求項１記載の制御方法。
3. 前記特定する処理は、前記第２のユーザごとに、前記複数の取引データに基づいて時系列順に単位時間ごとの前記第１のユーザとの取引数を集計し、
   前記分類する処理は、前記単位時間ごとの取引数の集計結果の類似性に基づいて、前記複数の第２のユーザを複数のクラスタに分類する、
   ことを特徴とする請求項２記載の制御方法。
4. 前記グループ別の集計項目の生成後に前記ブロックチェーンに記録される取引データに含まれる取引量に基づいて、当該取引データにおいて前記第１のユーザとの取引相手である前記第２のユーザが属するグループに対応する集計項目の集計値を更新する処理、
   をコンピュータが実行することを特徴とする請求項１乃至３いずれか一項記載の制御方法。
5. ブロックチェーンに記録された取引データに含まれる取引量の集計値を記録する集計項目を含むデータベースを制御する情報処理装置であって、
   前記ブロックチェーンに記録された複数の前記取引データを取得する取得部と、
   前記集計項目に対応付く第１のユーザとの取引相手である複数の第２のユーザごとに、前記複数の取引データに基づいて前記第１のユーザとの取引時期を特定する特定部と、
   前記取引時期の非類似性に基づいて、前記複数の第２のユーザを複数のグループに分類する分類部と、
   前記グループ別の集計項目を前記データベースに生成する生成部と、
   を有することを特徴とする情報処理装置。
6. ブロックチェーンに記録された取引データに含まれる取引量の集計値を記録する集計項目を含むデータベースの制御をコンピュータに実行させる制御プログラムであって、
   前記ブロックチェーンに記録された複数の前記取引データを取得する処理と、
   前記集計項目に対応付く第１のユーザとの取引相手である複数の第２のユーザごとに、前記複数の取引データに基づいて前記第１のユーザとの取引時期を特定する処理と、
   前記取引時期の非類似性に基づいて、前記複数の第２のユーザを複数のグループに分類する処理と、
   前記グループ別の集計項目を前記データベースに生成する処理と、
   をコンピュータに実行させることを特徴とする制御プログラム。

Images