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

制御方法、情報処理装置及び制御プログラム Download PDF

Info

Publication number
WO2021171457A1
WO2021171457A1 PCT/JP2020/007938 JP2020007938W WO2021171457A1 WO 2021171457 A1 WO2021171457 A1 WO 2021171457A1 JP 2020007938 W JP2020007938 W JP 2020007938W WO 2021171457 A1 WO2021171457 A1 WO 2021171457A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
user
users
transaction data
aggregated
Prior art date
Application number
PCT/JP2020/007938
Other languages
English (en)
French (fr)
Inventor
龍 新崎
郁弥 小林
石原　俊
淳也 平松
雄介 口脇
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2020/007938 priority Critical patent/WO2021171457A1/ja
Priority to JP2022502693A priority patent/JP7311020B2/ja
Priority to EP20921354.5A priority patent/EP4113313A4/en
Publication of WO2021171457A1 publication Critical patent/WO2021171457A1/ja
Priority to US17/871,941 priority patent/US20220360458A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key

Definitions

  • the present invention relates to control methods, information processing devices and control programs.
  • Each block recorded in the distributed ledger as data constituting the blockchain is generated for each predetermined unit such as every fixed time interval or every fixed number of transactions. Therefore, one block may contain information about multiple transactions.
  • the transaction means a remittance from a remittance source trader to a remittance destination trader, and a remittance source trader (for example, user A) or a remittance destination trader. (For example, user B), remittance amount, etc. are used as parameters.
  • the database that manages the identification information of the balance of each trader for example, "balance of A" as a key and a numerical value indicating the balance as a value is updated.
  • the remittance amount is subtracted from the value corresponding to the "balance of A” key, and the remittance amount is added to the value corresponding to the "balance of B" key.
  • Database updates based on multiple transactions included in the same block are executed collectively. Therefore, if multiple transactions for which the value for the same key is to be updated are included in the same block, a conflict may occur between the multiple transactions and the value of the key may not be consistent. There is. Therefore, if multiple transactions whose values for the same key are to be updated are included in the same block, only the first transaction of the multiple transactions is executed, and the second and subsequent transactions are regarded as errors. Execution is suppressed.
  • the present invention aims to suppress conflicts in updating the database.
  • One proposal is a process of acquiring a plurality of the transaction data recorded in the blockchain in a database control method including a summary item for recording the aggregated value of the transaction amount included in the transaction data recorded in the blockchain.
  • the computer executes a process of classifying the plurality of second users into a plurality of groups based on the dissimilarity of transaction times and a process of generating aggregate items for each group in the database.
  • FIG. 1 It is a figure which shows the structural example of the transaction management system 1 in embodiment of this invention. It is a figure which shows the hardware configuration example of each node 10 which constitutes the transaction management system 1 in embodiment of this invention. It is a figure which shows the functional configuration example of each node 10 which constitutes the transaction management system 1 in embodiment of this invention. It is a flowchart for demonstrating an example of the processing procedure of the key division processing. It is a figure which shows an example of the time-series aggregation result of the number of transactions for each unit time for each other user based on transaction history H. It is a figure which shows an example of the clustering result of another user. It is a figure which shows the classification example into a group of other users. It is a flowchart for demonstrating an example of the processing procedure of the update process of the balance DB 161 executed after the division of the balance key.
  • FIG. 1 is a diagram showing a configuration example of a transaction management system 1 according to an embodiment of the present invention.
  • a plurality of user terminals 20 are connected to the transaction management system 1 via a network such as the Internet.
  • the user terminal 20 is a terminal used by the parties (hereinafter, simply referred to as "transaction") of various transactions such as remittance (the user of the remittance source and the user of the remittance destination (hereinafter, simply referred to as "user")). ..
  • parties hereinafter, simply referred to as "transaction”
  • user the user of the remittance source and the user of the remittance destination (hereinafter, simply referred to as "user”)).
  • remittance the user of the remittance source and the user of the remittance destination (hereinafter, simply referred to as "user)).
  • PC Personal Computer
  • smartphone a tablet terminal, or the like
  • tablet terminal or the like
  • the transaction management system 1 is a P2P network (blockchain network) that manages transactions performed between user terminals 20, and includes a set of a plurality of computers or information processing devices (nodes 10) to which distributed ledger technology is applied. ..
  • Each node 10 is connected by a blockchain network and has a storage unit (hereinafter, referred to as "ledger") that distributes and manages common ledger information.
  • a blockchain showing the transaction history is recorded in the ledger.
  • the transaction management system 1 may be realized by using a framework implementation such as Hyperledger Fabric.
  • FIG. 2 is a diagram showing a hardware configuration example of each node 10 constituting the transaction management system 1 according to the embodiment of the present invention.
  • Each node 10 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other by a bus B.
  • the program that realizes the processing at the node 10 is provided by the recording medium 101.
  • the recording medium 101 on which the program is recorded is set in the drive device 100, the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100.
  • the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 103 reads and stores the program from the auxiliary storage device 102 when the program is instructed to start.
  • the CPU 104 executes the function related to the node 10 according to the program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • An example of the recording medium 101 is a portable recording medium such as a CD-ROM, a DVD disc, or a USB memory. Further, as an example of the auxiliary storage device 102, an HDD (Hard Disk Drive), a flash memory, or the like can be mentioned. Both the recording medium 101 and the auxiliary storage device 102 correspond to computer-readable recording media.
  • FIG. 3 is a diagram showing a functional configuration example of each node 10 constituting the transaction management system 1 according to the embodiment of the present invention.
  • each node 10 utilizes a storage unit such as a ledger 16.
  • the ledger 16 can be realized by using, for example, an auxiliary storage device 102, a storage device that can be connected to the node 10 via a network, or the like.
  • the ledger 16 is a storage unit for each node 10 to distribute and manage common ledger information.
  • the ledger 16 stores the blockchain C1, the balance DB161, and the like.
  • Blockchain C1 is an ordered list of blocks.
  • data including each parameter (hereinafter, referred to as "transaction data") is stored for each one or more transactions that occur in a predetermined unit such as at regular time intervals or at a fixed number of transactions.
  • NS a predetermined unit
  • remittance between users will be described as an example of a transaction. Therefore, for example, the remittance date and time, the user name of the remittance source, the user name of the remittance destination, the remittance amount, and the like are included in the transaction data.
  • the balance DB 161 is a database including aggregate items for recording the aggregated value (balance for each user) of the transaction volume (transaction amount) between users.
  • the value (aggregated value) of the aggregated item corresponding to the balance of each user is updated by executing the transaction. That is, the remittance amount is subtracted from the balance of the remittance source user, and the remittance amount is added to the balance of the remittance destination user.
  • the balance of each user is stored in the key-value format.
  • the aggregated items of the balance correspond to the keys, and the aggregated values correspond to the values.
  • the balance DB 161 stores a numerical value indicating the balance in association with a key for identifying the balance of the user (for example, "balance of A") for each user.
  • the balance DB 161 may be a database other than the key-value store, such as RDB (Relational Database).
  • RDB Relational Database
  • each node 10 of the present embodiment includes a transaction history acquisition unit 11, a transaction time identification unit 12, a user classification unit 13, a key division unit 14, an update unit 15, and the like.
  • Each of these parts is realized by a process of causing the CPU 104 to execute one or more programs installed on the node 10.
  • each part may be realized by a process of causing the CPU 104 to execute a smart contract (in the case of Hyperledger Fabric, a chain code).
  • the transaction history acquisition unit 11 collects a set of transaction data (transaction data to which the user is the remittance source or remittance destination) stored in any block of the blockchain C1 in the latest past fixed period T1 for each user. get.
  • the transaction time specifying unit 12 specifies, for each user, the transaction time of each user of the transaction partner with the user in chronological order for each unit time T2 that subdivides T1 for a certain period of time.
  • the user classification unit 13 classifies each user of the transaction partner with the user into a plurality of groups based on the dissimilarity of the transaction time with the user.
  • the key dividing unit 14 substantially divides the key by generating a key (aggregation item) for aggregating the transaction balance of the user for each user according to the group classified for the user.
  • the update unit updates the balance DB 161 based on the transaction data.
  • FIG. 4 is a flowchart for explaining an example of the processing procedure of the key division processing.
  • the processing procedure of FIG. 4 is repeatedly executed at T1 intervals for a certain period of time.
  • the fixed period T1 may be the same as the cycle in which a new block connected to the blockchain C1 is generated.
  • the processing procedure of FIG. 4 may be executed in response to the generation of a new block.
  • the loop process L1 including steps S101 to S110 is executed for each user who is a candidate for transaction.
  • the user targeted for processing in the loop processing L1 is referred to as a "target user”.
  • step S101 the transaction history acquisition unit 11 sets the transaction data corresponding to the target user among the transaction data stored in any block of the blockchain C1 in the latest past fixed period T1 (hereinafter, "transaction”).
  • “History H” is acquired from the blockchain C1.
  • the transaction data corresponding to the target user means transaction data whose remittance destination or remittance source is the target user (that is, transaction data that causes the balance of the target user to be updated). Therefore, for example, when the user A is the target user, the user A is the remittance destination or the remittance source, and a set of transaction data in the latest fixed period T1 is acquired as the transaction history H.
  • the transaction time specifying unit 12 sets the number of transaction data (that is, the number of transactions) in the transaction history H for each unit time T2 that subdivides T1 for a certain period of time as a user who is a transaction partner with the target user (hereinafter, the number of transactions). It is referred to as "another user") and aggregated in chronological order (S102).
  • FIG. 5 is a diagram showing an example of a time-series aggregation result of the number of transactions for each unit time for each other user based on the transaction history H.
  • the first line is a line given for convenience to indicate which unit time each unit time is.
  • T1 is divided into M unit times for a certain period is shown.
  • Each column of each row after the second row is the total result of the number of transactions in each time zone corresponding to each column for each other user. From the aggregation result of FIG. 5, it is possible to specify the transaction time with the target user for each of the plurality of other users other than the target user. It should be noted that each row for each other user can be regarded as a vector of length M with the aggregated value of each unit time as an element. Hereinafter, the vector is referred to as an "aggregated value vector".
  • the user classification unit 13 clusters the plurality of other users by a known method based on the similarity of the aggregated value vectors of the plurality of other users to generate N clusters (S103). .. That is, the plurality of other users are classified into a plurality of (N) clusters g1 to gN.
  • the similarity of the aggregated value vector may be evaluated by, for example, the similarity of the aggregated value vector.
  • a known index such as cosine similarity may be used.
  • FIG. 6 is a diagram showing an example of clustering results of other users.
  • FIG. 6 shows an example in which users B and D are classified into cluster g1 and user C is classified into cluster g2. This indicates that the transaction between A and B and the transaction between A and D tend to occur at the same time zone (that is, they are prone to conflict).
  • the key dividing unit 14 generates groups G1 to Gk for the maximum value k of the number of elements of each of the N clusters generated by the user classification unit 13 (S104).
  • the key dividing unit 14 classifies the other users of the i-th (1 ⁇ i ⁇ k) of each cluster into the i-th group Gi (S105). Therefore, other users who do not have similar trends in transaction time are classified into the same group. That is, in step S105, other users are classified into a plurality of groups based on the dissimilarity of transaction time.
  • FIG. 7 is a diagram showing an example of classification of other users into groups.
  • FIG. 7 shows an example in which users B and C are classified into the same group (group G1) and user D is classified into another group (group G2).
  • the key dividing unit 14 determines whether or not the division processing of the key corresponding to the balance of the target user (hereinafter, referred to as “balance key”) has been executed in the past (S106). That is, it is determined whether or not step S107 has been executed for the target user. This determination method will be described later.
  • the key division unit 14 sets the key name of the balance key of the target user in the balance DB 161 to " ⁇ user name of the target user>-. It is replaced with "Balance at the time of split" (S107).
  • the user name of the target user is entered in ⁇ user name of the target user>. Therefore, if the user A is the target user, the key name of the "balance of A" key in the balance DB 161 is replaced with "A-balance at the time of division".
  • the "A-Balance at split” key is a key for holding the value of the balance key at the time of splitting the balance key of user A (that is, how much the balance of user A was at the time of splitting the key). ..
  • the key related to the key name after replacement is referred to as "balance key at the time of division”.
  • the key dividing unit 14 generates a transaction key corresponding to the group in the balance DB 161 for each group generated in step S104 (S110).
  • the value corresponding to each generated transaction key is initialized to 0.
  • the transaction key corresponding to the group means a key whose value is the aggregated value of transactions between the target user and the user belonging to the group.
  • the transaction key corresponding to the group G1 is a key whose value is the aggregated value of the transaction amount between the user A and the user B or the transaction amount between the user A and the user C.
  • the key name of the transaction key corresponding to the group G1 is "AB, C”
  • the key name corresponding to the group G2 is "AD".
  • the key name of the transaction key has a format of "user name of the target user-user name of another user". That is, before the "-" is the user name of the target user, and after the "-" is the user name of one or more other users who are trading partners with the target user.
  • the value of such a transaction key (transaction amount) is deducted by the remittance amount according to the remittance from the user related to the user name before the "-", and becomes the user name after the "-” to the user.
  • the amount of money sent will be added according to the amount of money sent by the user.
  • the transaction key is a key whose value is the aggregated value of the transaction volume after the balance key is divided.
  • which key value is to be updated by each transaction can be identified by the key name. That is, the key name of the transaction key includes the correspondence information between the user involved in the transaction and the key to be updated.
  • a character string that does not include such correspondence information may be used as the key name of the transaction key.
  • the "A transaction 1" key is the key corresponding to the transaction between A and B or A and C
  • the "A transaction 2" key is the key corresponding to the transaction between A and D.
  • Corresponding information indicating that it is a corresponding key may be separately stored in the auxiliary storage device 102 or the like.
  • step S106 determines whether the balance key division process of the target user has been executed (Yes in S106). If it is determined in step S106 that the balance key division process of the target user has been executed (Yes in S106), steps S108 and S109 are executed instead of step S107. As described above, the key name of the balance key of the user for whom step S107 is executed is replaced with " ⁇ user name of target user> -balance at the time of division". Therefore, the determination in step S106 can be performed based on the presence or absence of the split balance key of the target user.
  • step S108 the key division unit 14 updates the value of the balance key at the time of division of the target user according to the value of each transaction key of the target user. Specifically, the key division unit 14 adds the value of each transaction key of the target user to the value of the balance key at the time of division of the target user. For example, when the target user is user A and the transaction key of user A is as described above, the value of the "AB, C" key and the value of the "A" key are compared with the value of the "A-balance at the time of division” key. -The value of the "D" key is added. As a result, the result of the transaction between the user A and another user after the previous generation of the transaction key of the user A is reflected in the balance key at the time of division of the user A.
  • the key dividing unit 14 deletes all the transaction keys of the target user and the values corresponding to the transaction keys from the balance DB 161 (S109). Subsequently, by executing step S110, the balance key of the target user is re-divided.
  • the key for managing the balance of each user can be changed as follows.
  • the key for user A is as follows by re-execution of the processing procedure of FIG. 4 (in this case, S108 and S109 are executed). It will be split again. -"A-Balance at split" key- "AB” key- "AC”key-”AD” key That is, when it is later found that the update of the value of a certain key is likely to collide. However, the key can be subdivided into smaller pieces. Therefore, in the above example, it is possible to suppress the conflict between the transaction between AB and the transaction between AC.
  • the key related to user A is as follows by executing the processing procedure of FIG. 4 again. Is redivided into. -"A-Balance at split" key- "AB, C, D" key That is, when a plurality of keys that are difficult to collide are divided, the keys can be recombined. In the above example, the transaction keys between user A and other users will eventually be combined into one. As a result, the number of readings for totaling the balance of the user A can be reduced, and the average processing time can be suppressed.
  • FIG. 8 is a flowchart for explaining an example of the processing procedure of the update processing of the balance DB 161 executed after the division of the balance key.
  • the update unit 15 When the update unit 15 receives new transaction data (request for updating the key value of the transaction data) (Yes in S201), the update unit 15 is currently generating the transaction data (hereinafter referred to as "target transaction data"). Add to the end of the block (S202). Subsequently, the update unit 15 determines whether or not the target block is completed (S203). For example, it is determined whether or not the target block is completed depending on whether the elapsed time from the start of generation of the target block has reached a certain time or the number of transaction data included in the target block is a certain number or more. NS.
  • the process returns to step 201.
  • the update unit 15 determines whether or not there is an update conflict in the target block (S204). That is, for the target block, it is determined whether or not there is a plurality of transaction data whose update target is the value of the same key.
  • the update unit 15 updates the key value of the balance DB161 based on each transaction data in the target block (S205).
  • the transaction key value (aggregated value) of the sending source user in the transaction data and the transaction key value (aggregated value) of the sending destination user in the transaction data are the transaction data. It will be updated based on the remittance amount (transaction volume) of. Specifically, the remittance amount is subtracted from the value of the transaction key of the user of the remittance source, and the remittance amount is added to the value of the transaction key of the remittance destination.
  • the remittance amount is subtracted from the value of the "AB *" key (* is a user name of 0 or more other than user A), and "BA *".
  • the remittance amount is added to the value of the key (* is a user name of 0 or more other than user B).
  • the update unit 15 determines the key of the balance DB161 based on each transaction data excluding the subsequent transaction data that updates the value of the same key in the target block.
  • the value is updated (S206). That is, the transaction related to the later transaction data that updates the value of the same key fails. Following step S205 or S206, the process returns to step S201.
  • the execution of the processing procedure of FIG. 4 is expected to suppress the conflict of updates, so that the execution of step S206 (that is, the failure of the transaction) can be suppressed.
  • the transaction time is specified for each trading partner with the user based on the past transaction data related to the user, and the transaction time is dissimilar.
  • the trading partners are classified into a plurality of groups, and keys (aggregate items) for each group are generated in the balance DB 161. Therefore, aggregation of transactions between users with similar transaction times will be performed using different keys (aggregation items). As a result, it is possible to suppress the conflict of updating the database (balance DB161).
  • the node 10 is an example of an information processing device.
  • the balance DB 161 is an example of a database.
  • the transaction history acquisition unit 11 is an example of an acquisition unit.
  • the transaction time specifying unit 12 is an example of the specific unit.
  • the user classification unit 13 is an example of the classification unit.
  • the key dividing unit 14 is an example of a generating unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

制御方法、情報処理装置及び制御プログラム
　本発明は、制御方法、情報処理装置及び制御プログラム
に関する。
　ブロックチェーンを構成するデータとして分散台帳に記録される各ブロックは、一定時間間隔ごと又は一定の取引数ごと等の所定の単位ごとに生成される。したがって、一つのブロック内には、複数の取引に関する情報が含まれうる。
　なお、取引とは、例えば、仮想通貨の取引であれば、送金元の取引者から送金先の取引者への送金をいい、送金元の取引者（例えば、ユーザＡ）、送金先の取引者（例えば、ユーザＢ）、送金額等をパラメータとする。このような取引では、各取引者の残高の識別情報（例えば、「Ａの残高」）をキーとし、当該残高を示す数値を値として管理するデータベースが更新される。ユーザＡからユーザＢへの送金の取引であれば、「Ａの残高」キーに対応する値から送金額が減算され、「Ｂの残高」キーに対応する値に送金額が加算される。
国際公開第２０１８／１２４２９７号
　同一のブロックに含まれる複数の取引に基づくデータベースの更新は、一括して実行される。したがって、同一のキーに対する値を更新対象とする複数の取引が同一のブロックに含まれている場合、複数の取引の間でコンフリクトが発生し、当該キーの値について、整合性を保持できない可能性が有る。そのため、同一のキーに対する値を更新対象とする複数の取引が同一のブロックに含まれている場合、当該複数の取引のうちの最初の取引のみが実行され、２番目以降の取引はエラーとしてその実行が抑制されている。
　この場合、実行が抑制された取引を再実行する必要が生じ、取引の実行が遅延してしまうことになる。さらに、取引を再実行したとしても、再実行時のブロックでも同じ状況になる可能性がある。
　そこで、一側面では、本発明は、データベースの更新のコンフリクトを抑制することを目的とする。
　一つの案では、ブロックチェーンに記録された取引データに含まれる取引量の集計値を記録する集計項目を含むデータベースの制御方法において、前記ブロックチェーンに記録された複数の前記取引データを取得する処理と、前記集計項目に対応付く第１のユーザとの取引相手である複数の第２のユーザごとに、前記複数の取引データに基づいて前記第１のユーザとの取引時期を特定する処理と、前記取引時期の非類似性に基づいて、前記複数の第２のユーザを複数のグループに分類する処理と、前記グループ別の集計項目を前記データベースに生成する処理と、をコンピュータが実行する。
　一態様によれば、データベースの更新のコンフリクトを抑制することができる。
本発明の実施の形態における取引管理システム１の構成例を示す図である。 本発明の実施の形態における取引管理システム１を構成する各ノード１０のハードウェア構成例を示す図である。 本発明の実施の形態における取引管理システム１を構成する各ノード１０の機能構成例を示す図である。 キーの分割処理の処理手順の一例を説明するためのフローチャートである。 取引履歴Ｈに基づく他ユーザ別の単位時間ごとの取引数の時系列の集計結果の一例を示す図である。 他ユーザのクラスタリング結果の一例を示す図である。 他ユーザのグループへの分類例を示す図である。 残高キーの分割後において実行される残高ＤＢ１６１の更新処理の処理手順の一例を説明するためのフローチャートである。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における取引管理システム１の構成例を示す図である。図１において、複数のユーザ端末２０は、インターネット等のネットワークを介して取引管理システム１に接続される。
　ユーザ端末２０は、送金等の各種の取引（以下、単に「取引」という。）の当事者（送金元のユーザ及び送金先のユーザ（以下、単に「ユーザ」という。））が利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等がユーザ端末２０として利用されてもよい。
　取引管理システム１は、ユーザ端末２０間で行われる取引を管理するＰ２Ｐネットワーク（ブロックチェーンネットワーク）であり、分散型台帳技術が適用された複数のコンピュータ又は情報処理装置（ノード１０）の集合を含む。各ノード１０は、ブロックチェーンネットワークによって接続され、共通の台帳情報を分散して管理する記憶部（以下、「台帳」という。）を有する。台帳には、取引の履歴を示すブロックチェーンが記録される。例えば、Ｈｙｐｅｒｌｅｄｇｅｒ　Ｆａｂｒｉｃ等のフレームワーク実装が用いられて取引管理システム１が実現されてもよい。
　図２は、本発明の実施の形態における取引管理システム１を構成する各ノード１０のハードウェア構成例を示す図である。各ノード１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
　ノード１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってノード１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　なお、記録媒体１０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
　図３は、本発明の実施の形態における取引管理システム１を構成する各ノード１０の機能構成例を示す図である。図３に示されるように、各ノード１０は、台帳１６等の記憶部を利用する。台帳１６は、例えば、補助記憶装置１０２、又はノード１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
　台帳１６は、上記したように、各ノード１０が共通の台帳情報を分散して管理するための記憶部である。台帳１６は、ブロックチェーンＣ１及び残高ＤＢ１６１等を格納する。
　ブロックチェーンＣ１は、ブロックの順序付けられたリストである。各ブロックには、一定時間間隔ごと又は一定の取引数ごと等の所定の単位ごとに発生した１以上の各取引について、それぞれのパラメータを含むデータ（以下、「取引データ」という。）が格納される。本実施の形態では、ユーザ間の送金を取引の一例として説明する。したがって、例えば、送金日時、送金元のユーザ名、送金先のユーザ名及び送金額等が取引データに含まれる。
　残高ＤＢ１６１は、ユーザ間の取引量（取引額）の集計値（ユーザごとの残高）を記録する集計項目を含むデータベースである。各ユーザの残高に対応する集計項目の値（集計値）は、取引の実行によって更新される。すなわち、送金元のユーザの残高から送金額が減算され、送金先のユーザの残高に送金額が加算される。なお、残高ＤＢ１６１において、各ユーザの残高は、キー・バリュー形式で格納される。残高の集計項目は、キーに対応し、集計値はバリューに対応する。すなわち、残高ＤＢ１６１は、ユーザごとに、当該ユーザの残高を識別するためのキー（例えば、「Ａの残高」）に対応付けて、当該残高を示す数値を記憶する。但し、残高ＤＢ１６１は、ＲＤＢ（Relational Database）等、キーバリューストア以外のデータベースであってもよい。例えば、残高ＤＢ１６１がＲＤＢであれば、「Ａの残高」という項目名がキーに対応し、「Ａの残高」という項目の値がバリューに対応する。
　ここで、同一キーにアクセスする複数の取引データが一つのブロックに含まれている場合、当該複数の取引データに係る各取引の実行のコンフリクト（衝突）のため、最初の取引データ以外の取引データに係る各取引は失敗してしまう。本実施の形態では、斯かるコンフリクトを回避するため、コンフリクトが発生しやすいキーを複数のキーに分割することを考える。具体的には、キー「Ａの残高」を「Ａの食費残高」及び「Ａの光熱費残高」に分割することを考える。こうすることにより、「Ａの残高」を更新する取引のうち、ユーザＡの食費の残高を更新する取引であれば、「Ａの食費残高」の値を更新対象とし、ユーザＡの食費の光熱費を更新する取引であれば、「Ａの光熱費残高」の値を更新対象とする。その結果、更新対象のキーが分散されるため、同一キーに対するアクセス頻度の低下を期待できる。したがって、同一キーへのアクセスのコンフリクトの回避を期待することができる。
　しかしながら、この場合、例えば、そもそも「Ａの残高」に対する取引のほとんどが、「Ａの食費残高」キーに対応する取引であった場合、同一キーへのアクセスのコンフリクトの回数の低減効果は少ないと考えられる。また、ユーザは、分割後のキーに合わせて、取引を分割して行う必要があり、結果として取引数の増加を招いてしまう。
　そこで、本実施の形態の各ノード１０は、上記の問題も回避可能とするために、取引履歴取得部１１、取引時期特定部１２、ユーザ分類部１３、キー分割部１４及び更新部１５等を有する。これら各部は、ノード１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。例えば、スマートコントラクト（Ｈｙｐｅｒｌｅｄｇｅｒ　Ｆａｂｒｉｃの場合、チェーンコード）がＣＰＵ１０４に実行させる処理により各部が実現されてもよい。
　取引履歴取得部１１は、ユーザごとに、直近の過去の一定期間Ｔ１においてブロックチェーンＣ１のいずれかのブロックに格納された取引データ（当該ユーザが送金元又は送金先である取引データ）の集合を取得する。取引時期特定部１２は、一定期間Ｔ１を細分化する単位時間Ｔ２ごとに、各ユーザについて、当該ユーザとの取引相手の各ユーザの取引時期を時系列順に特定する。ユーザ分類部１３は、ユーザごとに、当該ユーザとの取引相手の各ユーザを、当該ユーザとの取引時期の非類似性に基づいて複数のグループに分類する。キー分割部１４は、ユーザごとに、当該ユーザの取引の残高を集計するキー（集計項目）を、当該ユーザについて分類されたグループ別に生成することで、当該キーを実質的に分割する。更新部は、取引データに基づいて残高ＤＢ１６１を更新する。
　以下、各ノード１０が実行する処理手順について説明する。図４は、キーの分割処理の処理手順の一例を説明するためのフローチャートである。なお、図４の処理手順は、一定期間Ｔ１間隔で繰り返し実行される。一定期間Ｔ１は、ブロックチェーンＣ１に接続される新たなブロックが生成される周期と同じであってもよい。この場合、図４の処理手順は、新たなブロックの生成に応じて実行されてよい。
　まず、取引を行う候補者であるユーザごとに、ステップＳ１０１～Ｓ１１０を含むループ処理Ｌ１が実行される。ループ処理Ｌ１において処理対象とされているユーザを「対象ユーザ」という。
　ステップＳ１０１において、取引履歴取得部１１は、直近の過去の一定期間Ｔ１においてブロックチェーンＣ１のいずれかのブロックに格納された取引データのうち、対象ユーザに対応する取引データの集合（以下、「取引履歴Ｈ」という。）をブロックチェーンＣ１から取得する。対象ユーザに対応する取引データとは、対象ユーザを送金先又は送金元とする取引データ（すなわち、対象ユーザの残高の更新の原因となる取引データ）をいう。したがって、例えば、ユーザＡが対象ユーザである場合、ユーザＡが送金先又は送金元であり、直近の一定期間Ｔ１における取引データの集合が取引履歴Ｈとして取得される。
　続いて、取引時期特定部１２は、一定期間Ｔ１を細分化する単位時間Ｔ２ごとに、取引履歴Ｈにおける取引データの数（つまり、取引数）を対象ユーザとの取引相手であるユーザ（以下、「他ユーザ」という。）別に時系列に集計する（Ｓ１０２）。
　図５は、取引履歴Ｈに基づく他ユーザ別の単位時間ごとの取引数の時系列の集計結果の一例を示す図である。図５において、１行目は、各単位時間が何番目の単位時間であるのかを示すために便宜上付与された行である。図５の例では、一定期間Ｔ１がＭ個の単位時間に区切れられた例が示されている。
　２行目以降の各行の各列は、他ユーザ別の各列に対応する各時間帯における取引数の集計結果である。図５の集計結果により、対象ユーザ以外の複数の他ユーザのそれぞれについて、対象ユーザとの取引時期を特定することができる。なお、他ユーザごとの各行は、各単位時間の集計値を要素とし、長さＭのベクトルとみなすことができる。以下、当該ベクトルを「集計値ベクトル」という。
　続いて、ユーザ分類部１３は、複数の他ユーザのそれぞれの集計値ベクトルの類似性に基づいて、当該複数の他ユーザを公知の方法でクラスタリングして、Ｎ個のクラスタを生成する（Ｓ１０３）。すなわち、当該複数の他ユーザが複数（Ｎ個）のクラスタｇ１～ｇＮに分類される。集計値ベクトルの類似性は、例えば、集計値ベクトルの類似度によって評価されてもよい。当該類似度としては、コサイン類似度等、公知の指標が用いられればよい。
　図６は、他ユーザのクラスタリング結果の一例を示す図である。図６では、ユーザＢ及びＤがクラスタｇ１に分類され、ユーザＣがクラスタｇ２に分類された例が示されている。このことは、ＡとＢとの間の取引と、ＡとＤとの間の取引とは同じ時間帯に発生する傾向に有る（すなわち、コンフリクトしやすい）ことを示す。
　続いて、キー分割部１４は、ユーザ分類部１３によって生成されたＮ個の各クラスタの要素数の中での最大値ｋ個分のグループＧ１～Ｇｋを生成する（Ｓ１０４）。図６の例によれば、クラスタｇ１の要素数（ユーザ数）＝２が最大である。したがって、この場合、グループＧ１及びグループＧ２の２つのグループが生成される。
　続いて、キー分割部１４は、各クラスタのｉ番目（１≦ｉ≦ｋ）の他ユーザを、ｉ番目のグループＧｉに分類する（Ｓ１０５）。したがって、取引時期の傾向が類似しない他ユーザ同士が同じグループに分類される。すなわち、ステップＳ１０５では、他ユーザが、取引時期の非類似性に基づいて複数のグループに分類される。
　図７は、他ユーザのグループへの分類例を示す図である。図７では、ユーザＢ及びＣが同一グループ（グループＧ１）に分類され、ユーザＤが別のグループ（グループＧ２）に分類された例が示されている。
　続いて、キー分割部１４は、対象ユーザの残高に対応するキー（以下、「残高キー」という。）の分割処理が過去に実行されたことが有るか否か判定する（Ｓ１０６）。すなわち、対象ユーザについて、ステップＳ１０７が実行されたことが有るか否かが判定される。この判定方法については後述する。
　対象ユーザの残高キーの分割処理が実行されたことが無い場合（Ｓ１０６でＮｏ）、キー分割部１４は、残高ＤＢ１６１における対象ユーザの残高キーのキー名を、「＜対象ユーザのユーザ名＞－分割時残高」に置換する（Ｓ１０７）。ここで、＜対象ユーザのユーザ名＞には、対象ユーザのユーザ名が入る。したがって、ユーザＡが対象ユーザであれば、残高ＤＢ１６１における「Ａの残高」キーのキー名が、「Ａ－分割時残高」に置換される。「Ａ－分割時残高」キーは、ユーザＡの残高キーの分割時における当該残高キーの値（すなわち、キーの分割時にユーザＡの残高がいくらであったのか）を保持するためのキーである。以下、置換後のキー名に係るキーを「分割時残高キー」という。
　続いて、キー分割部１４は、ステップＳ１０４において生成されたグループごとに、当該グループに対応する取引キーを残高ＤＢ１６１に生成する（Ｓ１１０）。この際、生成された各取引キーに対応する値は０に初期化される。ここで、グループに対応する取引キーとは、対象ユーザと当該グループに属するユーザとの取引の集計値を値とするキーをいう。例えば、グループＧ１に対応する取引キーは、ユーザＡとユーザＢとの間の取引額、又はユーザＡとユーザＣとの間の取引額の集計値を値とするキーである。本実施の形態では、グループＧ１に対応する取引キーのキー名を「Ａ－Ｂ，Ｃ」とし、グループＧ２に対応するキー名を「Ａ－Ｄ」とすることとする。すなわち、取引キーのキー名は、「対象ユーザのユーザ名－他ユーザのユーザ名」という形式を有する。すなわち、「－」の前が対象ユーザのユーザ名であり、「―」の後が対象ユーザとの取引相手となる１以上の他ユーザのユーザ名である。このような取引キーの値（取引額）は、「－」の前のユーザ名に係るユーザからの送金に応じて送金額分だけ減算され、当該ユーザへの「－」の後のユーザ名に係るユーザからの送金に応じて送金額分だけ加算される。例えば、「Ａ－Ｄ」キーの値（取引額）であれば、ユーザＡからＤへの送金に応じて送金額が減算され、ユーザＤからＡへの送金に応じて送金額が加算される。すなわち、取引キーとは、残高キーの分割後の取引量の集計値を値とするキーである。また、各取引によっていずれのキーの値が更新対象となるのかについては、キー名によって識別可能である。すなわち、取引キーのキー名には、取引に係るユーザと更新対象のキーとの対応情報が含まれる。但し、このような対応情報が含まれない文字列（例えば、「Ａの取引１」、「Ａの取引２」等）が取引キーのキー名とされてもよい。この場合は、「Ａの取引１」キーが、ＡとＢ又はＡとＣとの間の取引に対応するキーであり、「Ａの取引２」キーが、ＡとＤとの間の取引に対応するキーであることを示す対応情報が、別途、補助記憶装置１０２等に記憶されてもよい。
　一方、ステップＳ１０６において、対象ユーザの残高キーの分割処理が実行されたことが有ると判定された場合（Ｓ１０６でＹｅｓ）、ステップＳ１０７の代わりにステップＳ１０８及びＳ１０９が実行される。なお、上述したように、ステップＳ１０７が実行されたユーザの残高キーのキー名は「＜対象ユーザのユーザ名＞－分割時残高」に置換される。したがって、ステップＳ１０６の判定は、対象ユーザの分割時残高キーの有無に基づいて行うことができる。
　ステップＳ１０８において、キー分割部１４は、対象ユーザの分割時残高キーの値を、対象ユーザの各取引キーの値によって更新する。具体的には、キー分割部１４は、対象ユーザの各取引キーの値を対象ユーザの分割時残高キーの値に加算する。例えば、対象ユーザがユーザＡであり、ユーザＡの取引キーが上記した通りである場合、「Ａ－分割時残高」キーの値に対して、「Ａ－Ｂ，Ｃ」キーの値と「Ａ－Ｄ」キーの値とが加算される。その結果、前回のユーザＡの取引キーの生成後における、ユーザＡと他ユーザとの取引の結果がユーザＡの分割時残高キーに反映される。
　続いて、キー分割部１４は、対象ユーザの全ての取引キー及び当該取引キーに対応する値を残高ＤＢ１６１から削除する（Ｓ１０９）。続けて、ステップＳ１１０が実行されることにより、対象ユーザの残高キーについて、改めて分割がし直されることになる。
　上述したステップＳ１０１～Ｓ１１０が全てのユーザについて実行され、ループ処理Ｌ１が終了すると、図４の処理手順の実行は終了する。
　図４の処理手順が繰り返し（一定期間Ｔごとに）実行されることにより、各ユーザの残高を管理するためのキーは、以下のように変更されうる。
　例えば、上記のように、「Ａの残高」キーが、「Ａ－分割時残高」キー、「Ａ－Ｂ，Ｃ」キー、及び「Ａ－Ｄ」キーに分割された後において、Ａ－Ｂ間の取引とＡ－Ｃ間の取引が衝突しやすくなると、図４の処理手順の再度の実行により（この際は、Ｓ１０８及びＳ１０９が実行される）、ユーザＡに関するキーは、以下のように分割し直される。
－「Ａ－分割時残高」キー
－「Ａ－Ｂ」キー
－「Ａ－Ｃ」キー
－「Ａ－Ｄ」キー
　すなわち、或るキーの値の更新が衝突しやすいことが後から分かった場合でも、当該キーをより細かく分割し直すことができる。したがって、上記の例では、Ａ－Ｂ間の取引とＡ－Ｃ間の取引の衝突を抑制することが可能となる。
　一方、Ａ－Ｂ間の取引、Ａ－Ｃ間の取引、Ａ－Ｄ間の取引が衝突しにくいのであれば、図４の処理手順の再度の実行により、ユーザＡに関するキーは、以下のように分割し直される。
－「Ａ－分割時残高」キー
－「Ａ－Ｂ，Ｃ，Ｄ」キー
　すなわち、衝突しにくいキーが複数の分割されてしまっている場合、当該キーが結合しなおすことができる。上記の例では、ユーザＡと他のユーザとの間の取引キーが結果的に一つにまとめられることになる。その結果、ユーザＡの残高の集計のための読み出し回数を減らすことができ、平均処理時間を抑えることができる。
　続いて、残高キーの分割後において実行される残高ＤＢ１６１の更新処理について説明する。図８は、残高キーの分割後において実行される残高ＤＢ１６１の更新処理の処理手順の一例を説明するためのフローチャートである。
　更新部１５は、新たな取引データ（当該取引データのキーの値の更新要求）を受信すると（Ｓ２０１でＹｅｓ）、当該取引データ（以下、「対象取引データ」という。）を、現在生成途中のブロックの最後尾に追加する（Ｓ２０２）。続いて、更新部１５は、対象ブロックが完成したか否かを判定する（Ｓ２０３）。例えば、対象ブロックの生成開始からの経過時間が一定時間に到達したか、又は対象ブロックに含まれる取引データの数が一定数以上であるか等によって、対象ブロックが完成したか否かが判定される。
　対象ブロックが完成していない場合（Ｓ２０３でＮｏ）、ステップ２０１へ戻る。対象ブロックが完成した場合（Ｓ２０３でＹｅｓ）、更新部１５は、対象ブロック内において更新のコンフリクトが有るか否かを判定する（Ｓ２０４）。すなわち、対象ブロックについて、同一キーの値を更新対象とする複数の取引データの有無が判定される。
　更新のコンフリクトが無い場合（Ｓ２０４でＮｏ）、更新部１５は、対象ブロック内の各取引データに基づいて、残高ＤＢ１６１のキーの値を更新する（Ｓ２０５）。この際、取引データごとに、当該取引データにおいて送金元のユーザの取引キーの値（集計値）と、当該取引データにおいて送金先のユーザの取引キーの値（集計値）とが、当該取引データの送金額（取引量）に基づいて更新とされる。具体的には、送金元のユーザの取引キーの値から送金額が減算され、送金先の取引キーの値に対して送金額が加算される。例えば、ユーザＡからユーザＢへの送金であれば、「Ａ－Ｂ＊」キー（＊は、ユーザＡ以外の０以上のユーザ名）の値から送金額が減算され、「Ｂ－Ａ＊」キー（＊は、ユーザＢ以外の０以上のユーザ名）の値に送金額が加算される。
　一方、更新のコンフリクトが有る場合（Ｓ２０４でＹｅｓ）、更新部１５は、対象ブロック内において、同一キーの値を更新する後発の取引データを除外した各取引データに基づいて、残高ＤＢ１６１のキーの値を更新する（Ｓ２０６）。すなわち、同一キーの値を更新する後発の取引データに係る取引は失敗する。ステップＳ２０５又はＳ２０６に続いて、ステップＳ２０１へ戻る。
　なお、本実施の形態では、図４の処理手順の実行により、更新のコンフリクトの抑制が期待されるため、ステップＳ２０６の実行（すなわち、取引の失敗）を抑制することができる。
　上述したように、本実施の形態によれば、各ユーザについて、過去の当該ユーザに係る取引データに基づいて、当該ユーザとの取引相手ごとに取引時期が特定され、取引時期の非類似性に基づいて取引相手群が複数のグループに分類され、グループ別のキー（集計項目）が残高ＤＢ１６１に生成される。したがって、取引時期が類似するユーザ間の取引に関する集計は、異なるキー（集計項目）によって行われるようになる。その結果、データベース（残高ＤＢ１６１）の更新のコンフリクトを抑制することができる。
　なお、本実施の形態において、ノード１０は、情報処理装置の一例である。残高ＤＢ１６１は、データベースの一例である。取引履歴取得部１１は、取得部の一例である。取引時期特定部１２は、特定部の一例である。ユーザ分類部１３は、分類部の一例である。キー分割部１４は、生成部の一例である。
１　　　　　　取引管理システム
１０　　　　　　ノード
１１　　　　　取引履歴取得部
１２　　　　　取引時期特定部
１３　　　　　ユーザ分類部
１４　　　　　キー分割部
１５　　　　　更新部
１６　　　　　台帳
２０　　　　　ユーザ端末
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
１６１　　　　残高ＤＢ
Ｂ　　　　　　バス
Ｃ１　　　　　ブロックチェーン

Claims (12)

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

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2020/007938 WO2021171457A1 (ja) 2020-02-27 2020-02-27 制御方法、情報処理装置及び制御プログラム
JP2022502693A JP7311020B2 (ja) 2020-02-27 2020-02-27 制御方法、情報処理装置及び制御プログラム
EP20921354.5A EP4113313A4 (en) 2020-02-27 2020-02-27 CONTROL METHOD, INFORMATION PROCESSING DEVICE AND CONTROL PROGRAM
US17/871,941 US20220360458A1 (en) 2020-02-27 2022-07-24 Control method, information processing apparatus, and non-transitory computer-readable storage medium for storing control program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/007938 WO2021171457A1 (ja) 2020-02-27 2020-02-27 制御方法、情報処理装置及び制御プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/871,941 Continuation US20220360458A1 (en) 2020-02-27 2022-07-24 Control method, information processing apparatus, and non-transitory computer-readable storage medium for storing control program

Publications (1)

Publication Number Publication Date
WO2021171457A1 true WO2021171457A1 (ja) 2021-09-02

Family

ID=77491080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/007938 WO2021171457A1 (ja) 2020-02-27 2020-02-27 制御方法、情報処理装置及び制御プログラム

Country Status (4)

Country Link
US (1) US20220360458A1 (ja)
EP (1) EP4113313A4 (ja)
JP (1) JP7311020B2 (ja)
WO (1) WO2021171457A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220230174A1 (en) * 2021-01-21 2022-07-21 Bank Of America Corporation System for analyzing and resolving disputed data records

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018055473A (ja) * 2016-09-29 2018-04-05 富士通株式会社 管理システム、管理方法及び管理プログラム
WO2018124297A1 (ja) 2016-12-28 2018-07-05 株式会社Ｏｋｅｉｏｓ Ｂｃｎ（ブロックチェーンネットワーク）を使用したデータ利用方法、システムおよびそのプログラム
JP2019200580A (ja) * 2018-05-16 2019-11-21 株式会社日立製作所 分散台帳システム、分散台帳サブシステム、および、分散台帳ノード

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190238316A1 (en) 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018055473A (ja) * 2016-09-29 2018-04-05 富士通株式会社 管理システム、管理方法及び管理プログラム
WO2018124297A1 (ja) 2016-12-28 2018-07-05 株式会社Ｏｋｅｉｏｓ Ｂｃｎ（ブロックチェーンネットワーク）を使用したデータ利用方法、システムおよびそのプログラム
JP2019200580A (ja) * 2018-05-16 2019-11-21 株式会社日立製作所 分散台帳システム、分散台帳サブシステム、および、分散台帳ノード

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4113313A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220230174A1 (en) * 2021-01-21 2022-07-21 Bank Of America Corporation System for analyzing and resolving disputed data records
US12014368B2 (en) * 2021-01-21 2024-06-18 Bank Of America Corporation System for analyzing and resolving disputed data records

Also Published As

Publication number Publication date
EP4113313A4 (en) 2023-06-07
JP7311020B2 (ja) 2023-07-19
US20220360458A1 (en) 2022-11-10
JPWO2021171457A1 (ja) 2021-09-02
EP4113313A1 (en) 2023-01-04

Similar Documents

Publication Publication Date Title
US20220335338A1 (en) Feature processing tradeoff management
US10255108B2 (en) Parallel execution of blockchain transactions
US20200356901A1 (en) Target variable distribution-based acceptance of machine learning test data sets
US10713589B1 (en) Consistent sort-based record-level shuffling of machine learning data
US20200050968A1 (en) Interactive interfaces for machine learning model evaluations
US9672474B2 (en) Concurrent binning of machine learning data
US10963810B2 (en) Efficient duplicate detection for machine learning data sets
US10339465B2 (en) Optimized decision tree based models
Yang et al. Implementation of a big data accessing and processing platform for medical records in cloud
CN105074724A (zh) 使用列式数据库中的直方图进行有效查询处理
Fard et al. Vertica-ml: Distributed machine learning in vertica database
Dai et al. An improved task assignment scheme for Hadoop running in the clouds
Osman et al. Towards real-time analytics in the cloud
Ferraro Petrillo et al. Analyzing big datasets of genomic sequences: fast and scalable collection of k-mer statistics
US20090030880A1 (en) Model-Based Analysis
US10552399B2 (en) Predicting index fragmentation caused by database statements
JP2020098388A (ja) 需要予測方法、需要予測プログラムおよび需要予測装置
Manghi et al. Entity deduplication in big data graphs for scholarly communication
Singh et al. Data processing framework using apache and spark technologies in big data
WO2021171457A1 (ja) 制御方法、情報処理装置及び制御プログラム
Benlachmi et al. A comparative analysis of hadoop and spark frameworks using word count algorithm
CN110851515B (zh) 一种基于Spark分布式环境下的大数据ETL模型执行方法及介质
JP5637071B2 (ja) 処理プログラム、処理方法及び処理装置
Tabet et al. Towards a new data replication strategy in mongodb systems
TWI643075B (zh) 雲端頻繁序列型樣資料探勘方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20921354

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022502693

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020921354

Country of ref document: EP

Effective date: 20220927