Method, transaction management device and computer-readable media for facilitating concurrent transactions

Abstract

A method of facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance comprises providing, at a blockchain network, an aggregator account having a token balance; generating a plurality of child accounts of the aggregator account; periodically initiating, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; and concurrently incrementing the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts.

Description

[0001] METHOD, TRANSACTI ON MANAGEM ENT DEVI CE AN D COMPUTER- READABLE MEDI A FOR FACI LI TATI NG CONCURRENT TRANSACTI ONS

[0002] TECH N I CAL FI ELD

[0003] The present disclosure relates to a m ethod, a transaction m anagement device, and com puter-readable media for facilitating concurrent transactions in a blockchain-based transaction system .

[0004] BACKGROUN D

[0005] Blockchains provide an effective m eans for tracking the ownership of digital assets within a distributed ledger. A blockchain data structure is typically im plem ented as a list of records (or "blocks") that are linked and secured using cryptography. Each block contains a cryptographic hash of the previous block in addition to record data defining the block. Managem ent of a blockchain structure involves generating and validating new blocks, and appending each newly generated block to the chain of existing blocks such that data is recorded in a verifiable and permanent way.

[0006] Due to their properties, blockchains are particularly well suited to recording transactions specifying an exchange of assets that has occurred between parties. Transactions are stored in batches within respective blocks of the data structure, thereby providing a perm anent and readily accessible record of transaction activity.

[0007] The security of a blockchain structure, and therefore its suitability as a mechanism for recording transactions, is dependent on the decentralised nature of the system that m aintains and updates the data structure. Specifically, a blockchain transaction processing system includes a plurality of nodes in the form of geographically distributed com puting devices that are configured to maintain a copy of the data structure, and to modify the structure by perform ing the processes of block generation and validation in a distributed way. Conventional blockchain transaction processing systems aim at implem enting a Byzantine fault-tolerant replicated state m achine ( RSM) by totally ordering blocks or sets of transactions that are issued by requesters. Specifically, the total ordering of transactions into blocks is achieved by the generation of new blocks containing transaction data, and a decision process by which each newly generated block is (or is not) added to the chain structure to com m it (or reject) the transaction (i.e. the process of "deciding" the block) . As a consequence of the distributed nature of the blockchain structure, transaction processing requires that consensus be reached between the nodes of the system to determ ine the form and structure of each new block (i.e. which transaction data to include) . Perm issionless blockchains allow any of the nodes of the system to be the deciders of new transaction blocks, while perm issioned system s confine the decision m aking to a predeterm ined fixed set of nodes. The transaction data itself m ust also be verified as correct before being com m itted (i.e. added to the chain within a block) such that the integrity of the chain is m aintained.

[0008] A key feature of blockchain-based transaction system s is the prevention of double-spending. For exam ple, in an Ethereum network, each account has an account nonce, also called a transaction nonce, associated with it. This is a counter which is increm ented every tim e the account requests a transaction. Transaction requests issued by an account are not validated by nodes in the network unless they are unique and consecutive. That is, a transaction request having a nonce of N will not be validated until all requests with nonce up to N- 1 have been validated.

[0009] I n certain applications of blockchain , it m ay be desired to enable participants to transact with each other in non-crypto currencies, but using the blockchain for security and integrity purposes. An issue that m ay arise in this context, particularly for Ethereum-based networks, is in interfacing traditional payment systems or loyalty and rewards systems with the blockchain. I n particular, the transaction speed is typically too slow to be satisfactory for point-of-sales applications. It is desirable therefore to provide a m ethod and system that can assist in facilitating concurrent transactions over a blockchain network.

[0010] SUMMARY

[0011] Disclosed herein is a m ethod of facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance, the method com prising :

[0012] providing, at a blockchain network, an aggregator account having a token balance;

[0013] generating a plurality of child accounts of the aggregator account;

[0014] periodically initiating, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; and

[0015] concurrently increm enting the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts.

[0016] Said child accounts may be generated according to a load on the transaction system .

[0017] The m ethod m ay comprise selecting child accounts for said user top-up transactions in accordance with one or more selection criteria.

[0018] The one or more selection criteria may include a round-robin selection criterion, selecting a child account that is the least recently used child account, or selecting a child account having the highest balance.

[0019] The method may be executed at least partly at a transaction m anagement device that stores user account data for the users in isolation from a key vault that stores private keys for signing transactions initiated by respective ones of the users.

[0020] Also disclosed herein is a transaction m anagement device for facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance, the transaction m anagem ent device com prising at least one processor and com puter-readable storage in com m unication with the at least one processor, the com puter-readable storage having stored thereon instructions for causing the at least one processor to:

[0021] generate, at a blockchain network, an aggregator account having a token balance;

[0022] generate a plurality of child accounts of the aggregator account;

[0023] periodically initiate, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; and

[0024] concurrently increm ent the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts.

[0025] The computer-readable storage m ay have stored thereon instructions for causing the at least one processor to generate the child accounts according to a load on the transaction system .

[0026] Said instructions may further cause the at least one processor to select child accounts for said user top-up transactions in accordance with one or more selection criteria. The one or m ore selection criteria may include a round-robin selection criterion, selecting a child account that is the least recently used child account, or selecting a child account having the highest balance.

[0027] The transaction m anagem ent device m ay further com prise a user database that stores user account data for the users, and a key vault that stores private keys for signing transactions initiated by respective ones of the users, wherein the user database is isolated from the key vault.

[0028] Also disclosed herein is one or m ore non-transitory com puter-readable media having stored thereon computer-readable instructions that, when executed by at least one processor, cause the at least one processor to perform a method as disclosed herein.

[0029] BRI EF DESCRI PTI ON OF THE DRAWINGS

[0030] Some embodiments of methods and systems for facilitating concurrent blockchain transactions, in accordance with present teachings will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which:

[0031] FIG.1 is a block diagram of a blockchain-based transaction management system;

[0032] FIG.2 schematically illustrates an account generation process in the system of FIG.1 ;

[0033] FIG. 3 is a flow diagram of an exemplary process for facilitating concurrent blockchain transactions;

[0034] FIG.4 is a flow diagram of an account top-up process;

[0035] FIG.5 is a flow diagram of a transaction process;

[0036] FIG. 6 is a block diagram of a user mobile computing device suitable for use with embodiments of the disclosure; and

[0037] FIG. 7 is a block diagram of a transaction management computing device in accordance with certain embodiments.

[0038] DETAI LED DESCRI PTI ON

[0039] Referring to FIG. 1, there is shown a transaction system 10 including a transaction management device 20 that is in communication with a plurality of users 100, 101 over a communications system 110, such as the Internet. Some users 100 are merchants who may offer goods or services for sale, either in a physical store or in an online environment. Other users 101 are consumers who seek to purchase goods and services from the merchants 100, or in some circumstances, to transfer currency to, or receive it from, other users 101. Users 100, 101 each have accounts maintained by transaction managem ent device 20, and the account data m ay be stored in a user database 102. The user database 1 02 m ay be locally stored at transaction m anagem ent device 20 or m ay be a rem otely accessible database.

[0040] The transaction m anagement device 20 is also in com m unication with one or more loyalty systems 104. Each loyalty system 1 04 maintains loyalty program accounts on behalf of users, and users m ay accrue point totals in their accounts according to transactions carried out with merchants, such as m erchants 1 00. Points may accrue at different rates for different loyalty program s. Accordingly, transaction system 1 0 m ay include an exchange com ponent 105 that allows a consum er user 101 to associate loyalty program identifiers with his or her account in user database 102, and to transfer accrued points from their loyalty program accounts to a com mon token that can be used for transactions with merchants 100, including m erchants with which the consumer 101 has not been previously enrolled. The com mon token is a data object representing a m edium of exchange in the system 10.

[0041] Each consum er user 1 01 enrolled with the transaction m anagement device 20 has a digital wallet associated with their account, and which stores tokens for use in transactions with merchants 100. The digital wallet may be accessible via a web browser, or a dedicated application, such as an app 618 ( FI G. 6) executing on a smartphone or other portable com puting device 12. I n addition to transactions with merchants 1 00, the digital wallet m ay include functionality for the consumer 101 to top-up their token account balance by various means, including with loyalty program points, or fiat currency. If loyalty program points are used for top-up, they are first translated to token value according to a prevailing exchange rate, by exchange com ponent 105.

[0042] Transfers of value in the system 10, including account top-ups and other transactions, are effected via a blockchain network 107. To this end, the transaction m anagem ent device 20 also includes a key vault 103 that stores the private keys of consumers 101 , and m erchants 100. The private keys are used to sign transactions that make use of blockchain network 107, but are never directly accessed by users 100, 101 . I nstead, users 1 00, 101 sign into their account at the transaction managem ent device 20, for exam ple via an account identifier and corresponding password. For exam ple, a user 101 of a loyalty system 104 may create a transaction session by authenticating herself to the loyalty system 104 using a loyalty account identifier and password. Loyalty system 104 then provides an access token to transaction m anagement device 20, which enables transaction managem ent device 20 to access the user's 101 key in key vault 103, and to retrieve wallet details for user 101 , for use in transactions while the user's session is active.

[0043] Advantageously, by m aintaining a key vault 103 that is separate from user database 1 02, and avoiding storage of the user's private key on their device, the system 10 m ay avoid user losses that could otherwise be incurred due to a bad actor obtaining the user's private key.

[0044] The blockchain 1 07 may be a private blockchain, such as a perm issioned Ethereum -based blockchain network. Alternatively, it may be a public blockchain.

[0045] The transaction managem ent device 20 acts as an intermediary layer between merchants 100 and users 101 on the one hand, and blockchain network 107 on the other hand, by receiving input from m erchants 1 00 and users 101 and translating the input into raw transactions that can be subm itted to the blockchain network 107 in appropriate form .

[0046] Referring now to FI G. 2, an exemplary hierarchy of blockchain accounts in the system 10 is shown. The accounts comprise system accounts 200, including an aggregator account 201 , and a series of sub-accounts (child accounts) 202 that are fed by the aggregator account 201 . Three sub-accounts are shown in FI G. 2, but it will be appreciated that the num ber of sub-accounts m ay be as few as two, or m ay be greater than three, for example increasing proportionately to the num ber of users in the system 10.

[0047] The aggregator account 201 holds tokens that are m inted, typically in a one time process at initiation of the system 10 (though additional tokens may be m inted should the number of users and / or loyalty programs increase beyond a certain threshold) , and distributes the tokens to the sub-accounts 202.1 , 202.2, 202.3 (hereafter collectively labelled as 202 for simplicity) such that the sub accounts 202 m ay transact with user accounts 21 0. I n particular, user accounts 210 may buy tokens from one of the sub-accounts 202, by exchanging loyalty points or fiat currency for tokens at an agreed exchange rate. Each user account 210 is associated with a wallet that is topped up with tokens by virtue of such exchanges. Each of the system accounts 200 and user accounts 210 may com prise a 40 character hexadecimal address that is a unique identifier for the account on the blockchain network 107.

[0048] Each request to top up a wallet is a blockchain transaction between a user account 210 and one of the sub-accounts 202. That is, a user request to top up their wallet is subm itted as a request to transaction management system 20, which then forms a transaction request to transfer tokens from one of the sub accounts 202 to the user account 210, and then transm its the transaction request to blockchain network 107.

[0049] Although in principle it is possible for user accounts 210 to buy tokens directly from aggregator account 201 , if there are many users attempting to top up their wallets at the sam e time, this m ay give rise to issues, for example in the case of a blockchain network 107 that uses transaction nonces to avoid double spending. I n such instances, the subm ission of m ultiple concurrent transactions to the blockchain network 107 will likely result in a race condition. By distributing tokens to m ultiple sub-accounts 202, which then act as interm ediaries between loyalty system s 104 and the user accounts 210 on the blockchain network 107, the likelihood of a race condition is lessened or elim inated. Further, since m ultiple top-up transactions m ay be performed in parallel, response tim es for users 101 are greatly im proved.

[0050] Once the wallet associated with a user account 210 has been loaded with tokens, the user m ay transact directly with other users who have accounts m aintained at the transaction m anagement device 20, without going via one of the sub accounts 202. For example, a consum er user 101 having account 21 0.1 m ay send tokens to a merchant user 1 00 having account 210.3 by subm itting a transaction request to transaction m anagement system 20, such as via transfer component 106. Transfer com ponent 106 m ay retrieve, from key vault 103, the private key of consum er 101 , and generate a transaction request that includes the account identifier of the consum er 101 , the account identifier of the merchant 100, and the num ber of tokens to transfer. The transaction request is signed by the private key of consum er 101 and subm itted to the blockchain network 107 for validation.

[0051] Referring now to FI G. 3, a process 300 for facilitating concurrent blockchain transactions is shown in m ore detail.

[0052] The process 300 begins at block 310 by the transaction management device 20 generating an aggregator account 201 . The transaction managem ent device 20 may create an entry in user database 1 02 for the aggregator account 201 including an off-chain identifier for the aggregator account 201 , and m ay m ake one or more API calls to blockchain network 107 to generate a blockchain account identifier and private key. The blockchain account identifier and private key m ay be stored in key vault 103. To enable an association of the private key with the aggregator account 201 for processing transaction requests, the blockchain account identifier may also be stored in the user database 102, or the off-chain identifier may be stored in the key vault 103 in association with the blockchain account identifier. At block 320, the process 300 m ints tokens by m aking a m inting API call to the blockchain network 1 07, with the aggregator account 201 being the target account for the m inted tokens to be assigned to.

[0053] At block 330, a plurality of sub-accounts 202 is generated. As for the aggregator account 201 , an off-chain account identifier is stored in user database 102, and a blockchain account identifier and private key are generated via one or m ore API calls to blockchain network 1 07. The sub-account blockchain account identifier and private key are stored in key vault 103. The sub-account blockchain account identifier may also be stored in the user database 102, or the off-chain sub-account identifier may be stored in the key vault in association with the sub-account blockchain account identifier. This is done for each generated sub-account. The number of sub-accounts generated m ay be dependent on the num ber of users initially enrolled with the system 10, and thus the num ber of concurrent transactions that are desired, for example.

[0054] Optionally, during generation of the sub-accounts 202, an initial top-up process may be perform ed, in which at least some of the tokens in the aggregator account 201 are transferred to the sub-accounts. For exam ple, a fixed percentage, such as 10% , of the total num ber of tokens in the aggregator account m ay be equally distributed am ongst the sub-accounts with each sub account receiving an initial top-up amount. The initial top-up process includes a series of blockchain transactions, each respective transaction request including the blockchain identifier of the aggregator account 201 , the blockchain identifier of the respective sub-account 202, and an am ount of tokens to transfer (this being the initial top-up am ount) , and being signed by the private key of the aggregator account 201 .

[0055] At block 340, the transaction m anagement device 20 checks the system load and determ ines, based on the load (e.g. , the num ber of concurrent transactions occurring within a given time window) , whether further child accounts m ay be required (block 350) . I f further accounts are required then the process returns to block 330 to generate further sub-accounts. Otherwise, the process 300 continues to block 360.

[0056] At block 360, the transaction m anagem ent device 20 determ ines whether token balances of the sub-accounts 202 need to be increm ented. The determ ination may be time-based, such that top-ups are triggered periodically (e.g., once per day) , for example. Alternatively, a top-up m ay be triggered once one or more of the sub-accounts 202 falls below a certain balance.

[0057] If the initial top-up process was not performed as part of block 330, the token balances will be zero and thus at block 360, the transaction managem ent device 20 may determ ine as a result that a top-up is required.

[0058] I n the event that a top-up for one or more sub-accounts is required, at block 370 the transaction m anagem ent device 20 performs one or more blockchain transactions to distribute tokens from the aggregator account 201 to the one or more sub-accounts. For example, the transaction m anagem ent device 20 m ay determ ine for each sub-account a top-up amount that is a difference between the initial top-up am ount and a current balance of the sub-account, and request, at blockchain network 107, a transaction that transfers the top-up am ount from the aggregator account to the respective sub-account.

[0059] Advantageously, relatively few transactions are required between the aggregator account 201 and the sub-accounts 202, since these need to be conducted only on a sporadic basis to keep the sub-accounts 202 at an adequate balance to allow m ultiple transfers between the sub-accounts 202 and user accounts 210. Accordingly, the top-up process avoids a bottleneck that may occur due to a single blockchain account attem pting to issue m ultiple transaction requests concurrently.

[0060] Turning now to FI G. 4, there is shown an exam ple of a user account top-up process 400 that may be im plem ented by the transaction managem ent device 20, for exam ple by transfer com ponent 106, optionally in conj unction with exchange com ponent 1 05.

[0061] At block 410, the transaction m anagem ent device 20 receives a top-up request from a user 101 , for exam ple from a wallet application executing on the user's mobile device 12. The request may include an am ount of a fiat currency and / or one or more am ounts of loyalty points from respective loyalty program s. Exchange component 1 05 m ay translate the fiat currency and / or loyalty point am ounts to a token value, according to appropriate exchange rates. For example, one loyalty point from a first loyalty system m ay equate to one token, while one loyalty point from a second loyalty system may equate to 0.5 tokens. The total requested token am ount is then passed to transfer component 1 06, together with an identifier of the user, which m ay be provided to transaction managem ent device 20 by the wallet application, for exam ple.

[0062] At block 420, transfer com ponent 106 receives the user identifier and total requested token amount and selects, from sub-accounts 202, a sub-account which will be used to top-up tokens into the user's blockchain account 21 0. For example, the transfer component 106 m ay select a sub-account random ly, or on a round-robin basis. Alternatively, the least recently used sub-account m ay be selected, or the sub-account with the highest current token balance may be selected. Combinations of these selection m ethods may also be used.

[0063] Once a sub-account is selected, transfer component 106 m ay check that the total requested token am ount does not exceed the current balance of the sub account. I f not, then at block 430, transfer component 106 m ay form a transaction request including a blockchain account identifier of the sub-account, a blockchain account identifier of the user (retrieved from user database 102 or key vault 103, for example) and the total requested token am ount, and sign the transaction request with the private key of the selected sub-account. The signed transaction request is then subm itted to the blockchain network 107. On successful validation of the transaction request, a validation response message m ay be sent from transfer component 106 to exchange component 105 to indicate a successful transaction, which in turn prom pts exchange component 105 to decrement account balances (e.g. , bank account balances and / or loyalty system points balances) by any amounts that were subm itted by the user as part of the top-up request. Subsequently, the user's account balance is increm ented by the total requested token am ount, and the sub-account balance is decremented by same.

[0064] Turning now to FI G. 5, an embodiment of a transaction process 500 is shown.

[0065] At block 510, a user device 12, executing a wallet application for exam ple, scans (using a cam era 622) a m erchant QR code in order to obtain a m erchant identifier, a transaction am ount in tokens, and optionally other inform ation, such as product information. The merchant QR code m ay be presented on the screen of a paym ent term inal, for exam ple. I n some embodim ents, the merchant QR code m ay include only a m erchant identifier without encoding the transaction amount, and the user may m anually enter the transaction amount at device 12. I n som e embodim ents, the m erchant and transaction information may instead be encoded in alternative form , such as an NFC tag or other machine-readable com ponent.

[0066] Optionally, at block 515, the wallet application may request the user to confirm the transaction, for example by clicking a confirm button, or entering user identification data (such as a PI N for the device 12, or biometric inform ation such as a fingerprint) .

[0067] At block 520, the wallet application forms a transaction request m essage including at least a user identifier, the merchant identifier, and the transaction am ount. User device 12 then transm its the transaction request message to the transaction m anagem ent device 20. At block 530, the transaction m anagement device 20 receives the transaction request m essage, and at block 535, parses (for example, using transfer component 106) the transaction details to retrieve the user identifier, m erchant identifier and transaction amount. Optionally, the transaction m anagement device 20 may perform validation steps on the transaction details, such as confirm ing that the user identifier and merchant identifier are of the correct form , and are registered in user database 102.

[0068] At block 540, the transaction m anagem ent device 20 generates a blockchain transaction request. The user identifier is m apped to the user's blockchain account identifier, and the m erchant identifier is mapped to the merchant's blockchain account identifier, by database lookups in user database 102. A transaction request m essage including the respective blockchain account identifiers and the transaction am ount is formed, and signed with the user's private key (retrieved by transaction management system 20 from key vault 103) . Next, at block 545, the signed transaction request is subm itted to blockchain network 107. The blockchain network 107 validates the signed transaction request by verifying the signature using the sender's public key.

[0069] At block 550, the transaction m anagement device 20 receives confirmation that the transaction has been validated, and transm its the confirm ation to user device 12. The user device 12 receives the confirmation at block 560, and displays it at block 565. The user device 12 may also display an updated account balance.

[0070] Mobile Computing Device 12

[0071] FI G. 6 is a block diagram showing an exem plary user device 12 in which em bodiments of the invention m ay be practiced. The user device 1 2 m ay be a mobile computing device such as a sm art phone, a personal data assistant ( PDA) , a palm-top computer, or a m ultimedia I nternet enabled cellular telephone. For ease of description, the user device 12 is described below, by way of non-lim iting exam ple, with reference to a m obile device in the form of an iPhone™ manufactured by Apple™, I nc., or one m anufactured by LG™, HTC™ and Sam sung™, for example.

[0072] As shown , the user device 12 includes the following components in electronic com m unication via a bus 606: a display 602;

[0073] non-volatile (non-transitory) m em ory 604;

[0074] random access m em ory ("RAM") 608;

[0075] N processing components 610;

[0076] a transceiver com ponent 612 that includes N transceivers; user controls 614;

[0077] a secure element (SE) 616;

[0078] a NFC controller 620; and

[0079] a camera 622.

[0080] Although the com ponents depicted in FI G. 6 represent physical components, FI G. 6 is not intended to be a hardware diagram . Thus, many of the components depicted in FI G. 6 may be realized by com m on constructs or distributed am ong additional physical components. Moreover, it is certainly contem plated that other existing and yet-to-be developed physical com ponents and architectures may be utilized to implement the functional components described with reference to FI G. 6.

[0081] The display 602 generally operates to provide a presentation of content to a user, and m ay be realized by any of a variety of displays (e.g., CRT, LCD, FIDMI , m icro-projector and OLED displays) .

[0082] I n general, the non-volatile data storage 604 (also referred to as non-volatile memory) functions to store (e.g., persistently store) data and executable code. In some embodiments for example, the non-volatile memory 604 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation components, well known to those of ordinary skill in the art, which are not depicted nor described for simplicity.

[0083] In many implementations, the non-volatile memory 604 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the non-volatile memory 604, the executable code in the non-volatile memory 604 is typically loaded into RAM 608 and executed by one or more of the N processing components 610.

[0084] The N processing components 610 in connection with RAM 608 generally operate to execute the instructions stored in non-volatile memory 604. As one of ordinarily skill in the art will appreciate, the N processing components 610 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.

[0085] The transceiver component 612 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.

[0086] The user device 12 can execute mobile applications. The digital wallet application 618 could be a mobile application, web page application, or computer application. The digital wallet application 618 may be accessed by a computing device such as mobile computer device 12, computing device 20, or a wearable device such as a smartwatch. Although the digital wallet application 618 is shown as being resident on secure element 616, it will be appreciated that it may instead be stored on memory 604.

[0087] It should be recognized that FIG. 6 is merely exemplary and in one or more exemplary embodiments, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be transmitted or stored as one or more instructions or code encoded on a non-transitory computer-readable medium 604. Non-transitory computer-readable medium 604 includes both computer storage medium and communication medium including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a computer.

[0088] Transaction management device 20

[0089] FIG.7 shows an example computing device 20 that is capable of implementing a transaction management device of the system 10. In some embodiments, a transaction management device may comprise multiple such computing devices 20.

[0090] The components of the computing device 20 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, which may communicate over a network. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs) or field programmable gate arrays.

[0091] In the example shown in FIG. 7, the computing device 20 is a commercially available server computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and / or methods executed or performed by the computing device 20 are implemented in the form of programming instructions of one or more software components or modules 722 stored on non-volatile (e.g., hard disk) computer-readable storage 724 associated with the computing device 20. At least parts of the software modules 722 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and / or field programmable gate arrays (FPGAs). The computing device 20 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 735:

[0092] • random access memory (RAM) 726;

[0093] • at least one computer processor 728, and

[0094] • external computer interfaces 730:

[0095] o universal serial bus (USB) interfaces 730a (at least one of which is connected to one or more user-interface devices, such as a keyboard, a pointing device (e.g., a mouse 732 or touchpad), o a network interface connector (NIC) 730b which connects the computer device 20 to a data communications network such as the Internet 110; and

[0096] o a display adapter 730c, which is connected to a display device 734 such as a liquid-crystal display (LCD) panel device.

[0097] The computing device 20 includes a plurality of standard software modules, including:

[0098] • an operating system (OS) 736 (e.g., Linux or Microsoft Windows); and

[0099] • structured query language (SQL) modules 742 (e.g., MySQL, available from http: / / www.mysql.com), which allow data to be stored in and retrieved / accessed from an SQL database 102.

[0100] The computing device 20 also includes a key vault 103 that stores the private keys of users 101 (and merchants 100) that are used to sign transactions that make use of blockchain network 107. The key vault 103 is isolated from user database 102, such that a separate set of access credentials is required to access data in the key vault 103. Advantageously, the user database 102 forms part of the computer readable data storage 724. Alternatively, the user database 102 is located remote from the transaction management device 20 shown in FIG.7.

[0101] The boundaries between the modules and components in the software modules 722 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable / programmable devices, the configuration of a field-programmable gate array (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC), or the like.

[0102] Each of the blocks of the flow diagrams of the processes of the computing device 20 may be executed by a module (of software modules 722) or a portion of a module. The processes may be embodied in a non-transient machine-readable and / or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and / or transmitted to a computer system memory to configure the computer system to perform the functions of the module. Software modules 722 may comprise the exchange component 105 and transfer component 106, for example. Software modules 722 may also comprise a cryptographic module for encrypting, decrypting and validating encrypted data in processes executed by the computing device 20, and for accessing data stored in key vault 103. I n some em bodim ents, the key vault 103 may only be accessible by processes executing in a secured environm ent. For example, the key vault 103 may only be accessible by the cryptographic m odule, or part thereof, that executes in a dedicated secure cryptoprocessor of the one or m ore processors 728, _or a trusted execution environment (TEE) of the one or more processors 728.

[0103] The computing device 20 norm ally processes inform ation according to a program (a list of internally stored instructions such as a particular application program and / or an operating system) and produces resultant output inform ation via input / output ( I / O) devices 730. A computer process typically includes an executing (running) program or portion of a program , current program values and state information , and the resources used by the operating system to m anage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being perform ed by the parent process.

[0104] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention.

[0105] Throughout this specification, unless the context requires otherwise, the word "com prise", and variations such as "comprises" and "com prising" , will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

Claims

A method of facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance, the method comprising:providing, at a blockchain network, an aggregator account having a token balance;generating a plurality of child accounts of the aggregator account, wherein the plurality of child accounts and the aggregator account are system accounts, and the system accounts are different from the user blockchain accounts; periodically initiating, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; receiving a plurality of user top-up requests from the user blockchain accounts corresponding to the plurality of users; andconcurrently incrementing the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts, wherein the plurality of child accounts of the system accounts is configured to perform the plurality of user top-up transactions with the user blockchain accounts corresponding to the plurality of users, in parallel,wherein the generating the plurality of child accounts of the aggregator account comprises: checking a number of concurrent transactions occurring on the transaction system within a given time window; determining, based on the number of concurrent transactions occurring on the transaction system within the given time window, whether one or more additional child accounts are required; and generating, based on the determination that the one or more additional child-accounts are required, the one or more additional child-accounts. A method according to claim 1, wherein said number of concurrent transactions occurring on the transaction system corresponds to a load on the transaction system.A method according to claim 1, comprising selecting child accounts for said user top-up transactions in accordance with one or more selection criteria.A method according to claim 3, wherein the one or more selection criteria include a round-robin selection criterion, selecting a child account that is the least recently used child account, or selecting a child account having the highest balance.A method according to claim 1, wherein the method is executed at least partly at a transaction management device that stores user account data for the users separately from a key vault that stores private keys for signing transactions initiated by respective ones of the users.A transaction management device for facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance, the transaction management device comprising at least one processor and computer-readable storage in communication with the at least one processor, the computer-readable storage having stored thereon instructions for causing the at least one processor to:generate, at a blockchain network, an aggregator account having a token balance;generate a plurality of child accounts of the aggregator account, wherein the plurality of child accounts and the aggregator account are system accounts, and the system accounts are different from the user blockchain accounts; periodically initiate, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; receive a plurality of user top-up requests from the user blockchain accounts corresponding to the plurality of users; andconcurrently increment the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts, wherein the plurality of child accounts of the system accounts is configured to perform the plurality of user top-up transactions with the user blockchain accounts corresponding to the plurality of users, in parallel,wherein the generating the plurality of child accounts of the aggregator account comprises: checking a number of concurrent transactions occurring on the transaction system within a given time window; determining, based on the number of concurrent transactions occurring on the transaction system within the given time window, whether one or more additional child accounts are required; and generating, based on the determination that the one or more additional child-accounts are required, the one or more additional child-accounts. A transaction management device according to claim 6, wherein said number of concurrent transactions occurring on the transaction system corresponds to a load on the transaction system.A transaction management device according to claim 6, wherein said instructions further cause the at least one processor to select child accounts for said user top-up transactions in accordance with one or more selection criteria.A transaction management device according to claim 8, wherein the one or more selection criteria include a round-robin selection criterion, selecting a child account that is the least recently used child account, or selecting a child account having the highest balance. A transaction management device according to claim 6, further comprising a user database that stores user account data for the users, and a key vault that stores private keys for signing transactions initiated by respective ones of the users, wherein the user database is isolated from the key vault.Non-transitory computer-readable storage having stored thereon computer-readable instructions that, when executed by at least one processor, cause the at least one processor to perform a method of facilitating concurrent blockchain transactions for a plurality of users in a transaction system having respective user blockchain accounts each having a token balance, the method comprising:providing, at a blockchain network, an aggregator account having a token balance;generating a plurality of child accounts of the aggregator account, wherein the plurality of child accounts and the aggregator account are system accounts, and the system accounts are different from the user blockchain accounts; periodically initiating, at the blockchain network, a plurality of top-up transactions to transfer tokens from the aggregator account to the plurality of child accounts; receiving a plurality of user top-up requests from the user blockchain accounts corresponding to the plurality of users; andconcurrently incrementing the respective token balances for the plurality of users by initiating, at the blockchain network, a plurality of user top-up transactions to transfer tokens from the plurality of child accounts to the user blockchain accounts, wherein the plurality of child accounts of the system accounts is configured to perform the plurality of user top-up transactions with the user blockchain accounts corresponding to the plurality of users, in parallel,wherein the generating the plurality of child accounts of the aggregator account comprises: checking a number of concurrent transactions occurring on the transaction system within a given time window; determining, based on the number of concurrent transactions occurring on the transaction system within the given time window, whether one or more additional child accounts are required; and generating, based on the determination that the one or more additional child-accounts are required, the one or more additional child-accounts. Non-transitory computer-readable storage according to claim 11, wherein said number of concurrent transactions occurring on the transaction system corresponds to a load on the transaction system.Non-transitory computer-readable storage according to claim 11, wherein the method comprises selecting child accounts for said user top-up transactions in accordance with one or more selection criteria.Non-transitory computer-readable storage according to claim 13, wherein the one or more selection criteria include a round-robin selection criterion, selecting a child account that is the least recently used child account, or selecting a child account having the highest balance.Non-transitory computer-readable storage according to claim 11, wherein the method is executed at least partly at a transaction management device that stores user account data for the users separately from a key vault that stores private keys for signing transactions initiated by respective ones of the users.

Images