Transactional sharding of blockchain transactions

Description

BACKGROUND

Cryptographic coinage and blockchains are growing in usage. As usage grows, however, scalability has become a problem. The number of blockchain transactions has greatly increased, so improved techniques are needed.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments are understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:

FIGS. 1-16 are simplified illustrations of a transactional sharding in a blockchain environment, according to exemplary embodiments;

FIGS. 17-18 are more detailed illustrations of an operating environment, according to exemplary embodiments;

FIGS. 19-21 are more detailed illustrations of indexing a cryptographic coinage transaction, according to exemplary embodiments;

FIG. 22 illustrates the service mechanism, according to exemplary embodiments;

FIGS. 23-25 illustrate a cloud-based blockchain service, according to exemplary embodiments;

FIGS. 26-30 illustrate a blockchain data layer, according to exemplary embodiments;

FIG. 31 further illustrates crypto-payments, according to exemplary embodiments;

FIG. 32 is a flowchart illustrating a method or algorithm for the transactional sharding, according to exemplary embodiments; and

FIGS. 33-34 depict still more operating environments for additional aspects of the exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings. The exemplary embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the exemplary embodiments to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating the exemplary embodiments. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes,” “comprises,” “including,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.

FIGS. 1-16 are simplified illustrations of a transactional sharding 20 in a blockchain environment 22, according to exemplary embodiments. A complex cryptographic coinage transaction 24 is split, or sharded, into two (2) or more simple cryptographic coinage transactions 26. The complex cryptographic coinage transaction 24 has a complex accounting structure 28, meaning that the complex cryptographic coinage transaction 24 involves or references multiple input account addresses 30 and/or multiple output account addresses 32. A sharding server 34, for example, receives the complex cryptographic coinage transaction 24 as an electronic message or data. As the sharding server 34 processes the complex cryptographic coinage transaction 24, the sharding server 34 determines the complex accounting structure 28 based on the presence or specification of either one or both of the multiple input account addresses 30 and/or multiple output account addresses 32. The sharding server 34 may thus authorize and/or implement the transactional sharding 20 of the complex cryptographic coinage transaction 24 into the multiple, simple cryptographic coinage transactions 26. That is, the complex cryptographic coinage transaction 24 is broken up or parsed into the multiple, simple cryptographic coinage transactions 26. Each one of the different simple cryptographic coinage transactions 26 only specifies or involves a single one of the input account addresses 30 and/or a single one of the output account addresses 32.

The simple cryptographic coinage transactions 26 may then be processed and recorded. While the simple cryptographic coinage transactions 26 may be dispersed within the blockchain environment 22 for debit/deposit processing (as later paragraphs will explain), FIG. 1 illustrates a blockchain recordation. That is, for simplicity, the sharding server 34 may itself process a cryptographic coinage debit transaction and a cryptographic coinage deposit transaction, according to the single input account address 30 and the single output account address 32 specified by each one of the simple cryptographic coinage transactions 26. The sharding server 34 may then generate a block 36 of data for recordation in a blockchain 38. The sharding server 34 may even call or invoke a hashing algorithm 40 to generate one or more hash values 42 representing cryptographic proofs of any of the complex cryptographic coinage transaction 24, the simple cryptographic coinage transactions 26, and/or the block 36 of data. The blockchain 38 is thus a distributed ledger 44 that documents the processing of the simple cryptographic coinage transactions 26.

Exemplary embodiments may thus generate point-to-point transactions. Each simple cryptographic coinage transaction 26 only requires information or data specifying one input account address 30 and one output account address 32. Each simple cryptographic coinage transaction 26 is thus a point-to-point component of the more complex cryptographic coinage transaction 24 that originally referenced or specified the multiple input/output address transactions 30 and 32.

FIG. 2 illustrates cryptographic processing fees. In the blockchain environment 22, most cryptographic coinage transactions (such as the complex cryptographic coinage transaction 24 having the complex accounting structure 28) are associated with an input list of input sources (such as the multiple input account addresses 30) and a different or separate output list of output accounts (such as the multiple output account addresses 32). As the simple cryptographic coinage transactions 26 are processed, one or more cryptographic fees (or “crypto-fee”) 50 may be charged, assessed, or debited. As an example, the sharding server 34 may assess or debit the cryptographic fee 50 for authorizing, implementing, or managing the transactional sharding 20 of the complex cryptographic coinage transaction 24. Another cryptographic fee 50 may further be processed for actually sharding the cryptographic coinage transaction 24 into the multiple, simple cryptographic coinage transaction 26, and further cryptographic fees 50 may be paid for processing each one of the simple cryptographic coinage transactions 26. Cryptocurrency funds may thus move from the input sources/accounts (e.g., the input account addresses 30) into the output accounts (e.g., output account addresses 32), and the cryptographic fees 50 may be charged or associated with the processing of the cryptographic coinage transaction 24 and/or performing the simple cryptographic coinage transactions 26. For example, exemplary embodiments may split a cryptographic input deposit across the output accounts based on amounts perhaps specified by the cryptographic coinage transaction 24 and/or any of the simple cryptographic coinage transactions 26. A total amount of a deposit may thus be a sum total of the inputs less the cryptographic processing fees 50. Indeed, some of the simple cryptographic coinage transactions 26 may specify an amount per input source and an amount per output.

As FIG. 3 illustrates, exemplary embodiments may be applied to any accounting scheme. For example, the cryptographic fee 50 may be implemented or charged for any simple cryptographic coinage transaction 26 involving or associated with any of the input account addresses 30. The cryptographic fee 50 may additionally or alternatively be implemented or charged for any simple cryptographic coinage transactions 26 involving or associated with any of the output account addresses 32. The blockchain environment 22 may use account-based accounting 52 in which the cryptographic fees 50 are based on the account address, so in some cases the input source has more crypto-tokens than required for the simple cryptographic coinage transactions 26 and can specify a sub-amount. The blockchain environment 22, however, may use an unspent transactional outputs type accounting 54 that may use all of the balance or funds in the input source account, but the input source account may be broken up into lots of unspent transactional outputs. Exemplary embodiments may thus use an accounting difference between the unspent transactional outputs accounting 54 and the account-based accounting 52 when there are multiple input sources and multiple output destinations for one transaction. Exemplary embodiments may thus be applied to both cryptocurrencies that use unspent transactional outputs accounting 54 and to cryptocurrencies that use the account-based accounting 52.

FIG. 4 further illustrates the transactional sharding 20. Here the sharding server 34 may be a component or portion of a network shard 60 within the blockchain environment 22. As the reader may understand, conventional blockchain sharding slices, or partitions, the blockchain environment 22 into defined, or even separate, network shards 60. Each network shard 60 only processes certain or specified blockchain transactions that occur within the blockchain environment 22, and each network shard 60 maintains its own state and transactional history. Each network shard 60, in other words, may have its own set of servers that are dedicated to processing a particular subset of the blockchain transactions that occur within the overall or entire blockchain environment 22. While the number of network shards 60 may be numerous, for simplicity FIG. 4 only illustrates two network shards 60a and 60b. Each network shard 60a-b may thus be scaled to increase the processing throughput of the blockchain transactions.

Exemplary embodiments may thus have multiple sharding servers 34. FIG. 4, for example, illustrates sharding server 34a dedicated to servicing the network shard 60a, while sharding server 34b services the network shard 60b. Regardless, whenever either network shard 60a or 60b encounters the cryptographic coinage transaction 24 (exhibiting the complex accounting structure 28, as explained with reference to FIG. 1), the corresponding network shard 60a or 60b may call or invoke its corresponding sharding server 34a or 34b to implement the transactional sharding 20. Suppose, for example, that a network server 62a (operating within, or assigned to, the network shard 60a) acts as a gateway and receives the complex cryptographic coinage transaction 24a. The network server 62a inspects the information or data associated with the complex cryptographic coinage transaction 24a and determines or infers the complex accounting structure 28. The network server 62a may thus pass, send, or forward the complex cryptographic coinage transaction 24a to the sharding server 34a for application of the transactional sharding 20. The sharding server 34a thus transactionally shards the complex cryptographic coinage transaction 24a into the simple cryptographic coinage transactions 26a. Again, each one of the different simple cryptographic coinage transactions 26a only specifies or involves a single one of the input account addresses 30 and/or a single one of the output account addresses 32 (as explained with reference to FIGS. 1-2). The sharding server 34a may then perform or conduct each simple cryptographic coinage transactions 26a, and/or the sharding server 34a may disperse or distribute any simple cryptographic coinage transactions 26a to another server within the network shard 60a for processing.

The network shard 60b may also have similar processing functionality. Suppose some component (such as network server 62b) operates within, or assigned to, the network shard 60b receives the complex cryptographic coinage transaction 24b. The network server 62b inspects the information or data associated with the complex cryptographic coinage transaction 24b and determines or infers the complex accounting structure 28. The network server 62b may thus pass, send, or forward the complex cryptographic coinage transaction 24b to the sharding server 34b for application of the transactional sharding 20. The sharding server 34b thus transactionally shards the complex cryptographic coinage transaction 24b into the simple cryptographic coinage transactions 26b. Again, each one of the different simple cryptographic coinage transactions 26b only specifies or involves a single one of the input account addresses 30 and/or a single one of the output account addresses 32 (as explained with reference to FIGS. 1-2). The sharding server 34b may then perform or conduct each simple cryptographic coinage transactions 26b, and/or the sharding server 34b may disperse or distribute any simple cryptographic coinage transactions 26b to another server within the network shard 60b for processing. Of course, the network shards 60a and 60b may share the services of a single sharding server 34, thus passing any complex cryptographic coinage transaction 24 for application of the transactional sharding 20.

The sharding server 34 may have a management role. The sharding server 34 may receive or accept the complex cryptographic coinage transaction 24 as an input and collect or retrieve the processing inputs, as specified by the multiple input account addresses 30. The sharding server 34 may transactionally shard the complex cryptographic coinage transaction 24 and may itself process the multiple, simple cryptographic coinage transactions 26. Preferably, though, the sharding server 34 assigns the processing of the simple cryptographic coinage transactions 26 to other servers (such as 34a and 34b) within the network shard 60a-b. The sharding server 34, in other words, may offload further processing of the simple cryptographic coinage transactions 26 and merely ensure or track processing. As a simple example, because the simple cryptographic coinage transactions 26 may have just one input account address 30 and just one output account address 32, exemplary embodiments may easily shard just by choosing some mathematical function of the input account address 30 (such as a last digit) and send the corresponding simple blockchain transaction(s) 26 to the network resource that is reserved for, dedicated to, or assigned to that last digit. If the input account address 30 has the correct amount of its account balance, then the network shard 60 updates the input account address 30 (e.g., lowering or debiting its cryptofunds) and the network shard 60 sends a deposit transaction to the network resource reserved for the output account address 32. Because deposits always pass (only the input side can fail), this scheme works well for the transactional sharding 20.

FIG. 5 also illustrates the transactional sharding 20. Here, though, the sharding server 34 may be any component or resource within the blockchain environment 22. That is, the sharding server 34 need not be dedicated to serving the network shard 60 (as illustrated in FIG. 4). The sharding server 34, instead, may simply serve the blockchain environment 22. Regardless, when the sharding server 34 receives, or is notified of, the complex cryptographic coinage transaction 24 (perhaps sent from the server 62), the sharding server 34 may identify the multiple input account addresses 30 and/or the multiple output account addresses 32 and infer the complex accounting structure 28. The sharding server 34 may transactionally shard the complex cryptographic coinage transaction 24 and generate the simple cryptographic coinage transactions 26. The sharding server 34 may collect or retrieve the processing inputs (such as the input addresses 30, the output account addresses 32, and any cryptocoinage debits and deposits) and perform or execute the simple cryptographic coinage transactions 26. However, the sharding server 34 may optionally assign the processing of the simple cryptographic coinage transactions 26 to other servers and resources within the blockchain environment 22. The sharding server 34, in other words, may send one of the simple cryptographic coinage transactions 26a to a server 64a operating within the blockchain environment 22 for processing. Another one of the simple cryptographic coinage transactions 26b may be assigned to a server 64b. Again, while exemplary embodiments may use any scheme for processing assignments, any digit in the input account address 30 (such as the last digit) is thought easiest for most readers to understand. The sharding server 34 sends the inputs and the corresponding simple cryptographic coinage transactions 26a-b to the server 64a-b that is reserved for, dedicated to, or assigned to any blockchain transactions having that last digit. If the input account address 30 has the correct amount of its account balance, the simple cryptographic coinage transactions 26 successfully passes/processes, the input account address 30 updates (e.g., lowering or debiting its crypto-funds), and the deposit transaction is sent within the blockchain environment 22 to the server reserved for the output account address 32.

Exemplary embodiments thus overcome problems associated with conventional blockchain sharding. Conventional blockchain sharding techniques use the account number to choose the network shard that processes a blockchain transaction. As long as blockchain transactions of that same type (e.g., account address) are sent to the same network shard and/or computer, that computer will have all the data related to that transaction. The problem with blockchain or cryptocurrency monetary transactions, however, is that they often have the multiple input account addresses 30 and/or the multiple output account addresses 32. Conventional blockchain sharding thus has great difficulty in picking the correct network shard/computer server for processing, as the transactional data is likely stored on multiple computers. There is no throughput advantage of having sent the complex cryptographic coinage transaction 24 (e.g., having the complex accounting structure 28) to some device that only has access to some of the required data. All of a sudden that computer needs to have all of the data for all of the input and/or output accounts, so any change to an account requires notifying all the other network nodal computers to make changes to their respective accounts, and they might simultaneously need to make their own changes to that account. Processing thus becomes very cumbersome and all efficiencies are lost in synchronizing data associated with multiple accounts in order to maintain consistent accounting. Simply put, there was no speed benefit in having network sharded the complex cryptographic coinage transaction 24. But the transactional sharding 20 computationally reduces the complex cryptographic coinage transaction 24 into the point-to-point simple cryptographic coinage transactions 26. A single network device (such as the sharding server 34) may thus store and maintain all the transactional records for any input/output account, thus making processing assignments much simpler and processing updates much faster.

FIG. 6 illustrates a simple example of the transactional sharding 20. Suppose the complex cryptographic coinage transaction 24 (e.g., having the complex accounting structure 28) references or specifies three (3) input account addresses 30 and three (3) output account addresses 32. The complex cryptographic coinage transaction 24 may thus be described as a 3×3 transaction. Exemplary embodiments may thus split or break the complex cryptographic coinage transaction 24 into six (6) simple cryptographic coinage transactions 26 involving a temporary account address 70. That is, exemplary embodiments may establish or generate the temporary account address 70 to simply the transaction details. For example, exemplary embodiments may debit transfer crypto-funds from the three (3) input account addresses 30 into the temporary account address 70. Each input transaction thus only requires a simple debit transaction involving each single input account address 30 and the temporary account address 70 as an output. Once the three input transactions successfully complete, exemplary embodiments may deposit transfer crypto-funds from the temporary account address 70 to the three (3) output account addresses 32. Again, each output transaction only requires the single temporary account address 70 (as a debit input) and the three (3) output account addresses 32 as deposit outputs. Because exemplary embodiments establish the temporary account address 70, exemplary embodiments may split, break, or parse the 3×3 complex cryptographic coinage transaction 24 into six (6) component simple cryptographic coinage transactions 26 that only require a single input account address 30 and/or a single output account address 32. Each simple cryptographic coinage transactions 26 thus has one accounting.

Sequential processing may be preferred. While the simple cryptographic coinage transactions 26 may be processed in any order, the simple cryptographic coinage transactions 26 are preferably processed in a serial fashion. That is, the simple cryptographic coinage transactions 26 may be assigned and/or processed in a sequential order. If there are multiple, simple cryptographic coinage transactions 26 all drawing from the same input account address 30, then debit processing according to the sequential order quickly and easily identifies a failure. If the inputs do not all complete (that is, one of the input account addresses 30 does not have a sufficient balance to fulfil a transactional request), then the server computer (such as the sharding server 34) that is handling the original, complex cryptographic coinage transaction 24, instead of sending out the output transaction, instead sends out transactions that delete crypto-funds to restore the input/output account addresses 30 and 32 to rewind or put back everything before processing started (perhaps according to a timestamp or transaction number identifier).

Refunds may be processed. The computer system that is processing the refund (again, simply illustrated as the sharding server 34) may also be the same device that is handling the temporary account address 70. For example, exemplary embodiments may guarantee that the sharding server 34 collects the input data and also implements the temporary account address 70. Because there may only be one input account address 30 associated with each simple cryptographic coinage transaction 26, then the input and the temporary account address 70, and the sending of any updates to the output account address(es) 32, are all handled by one computer system. In other exemplary embodiments, however, the temporary account address 70 may be handled by a different computer system from the input account address 30, in which the different computer system (perhaps establishing or hosting the temporary account address 70) may collect all the inputs and send out all the updates to the output systems responsible for the output account addresses 32. The same computer server, of course, may collect or retrieve any or all of the inputs, establish the temporary account address 70, and send updates to any output account addresses 32. Exemplary embodiments may be functionally split between any number of servers, or merged into and performed by a single server, as desired for performance, convenience, and revenue.

FIGS. 7-8 illustrate cloud-based services. Here the sharding server 34 may be operated on behalf of a cloud service provider 80. The cloud service provider 80 establishes the temporary account address 70, and perhaps processes the complex cryptographic coinage transaction 24 as a cloud-based blockchain service 82 on behalf of a requesting client 84. While exemplary embodiments may be agnostic to the requesting client 84, FIG. 7 illustrates the server 62 operating within the blockchain environment 22. When the server 62 determines that any electronic wallet 86 is associated with any cryptographic coinage transaction 24 exhibiting the complex accounting structure 28, the server 62 may outsource or subcontract the cryptographic coinage transaction 24 to the sharding server 34 for application of the cloud-based blockchain service 82. For example, the server 62 may generate and send service request 88 for the cloud-based blockchain service 82. The complex cryptographic coinage transaction 24 may be forwarded or sent (perhaps via the Internet) to accompany the service request 88, or the service request 88 may specify any transactional details (such as the multiple input account addresses 30, the multiple output account addresses 32, and any crypto-coinage debits and deposits). The server 62 sends the service request 88 to a network address (e.g., Internet Protocol address) associated with the remote sharding server 34 that provides the cloud-based blockchain service 82. When the sharding server 34 receives the service request 88, the sharding server 34 implements the transactional sharding 20 and performs, or oversees, the processing of the component simple cryptographic coinage transactions 26 as the cloud-based blockchain service 82. Once all the component simple cryptographic coinage transactions 26 are processed, the sharding server 34 may send a service response 90 back to the server 62 (or any other destination), and the service response 90 details the processing results of the simple cryptographic coinage transactions 26. Of course, if any one of the simple cryptographic coinage transactions 26 fails, the service response 90 may detail and/or alert of the failure. Exemplary embodiments may also charge the cryptographic fee 50 for any portion of the cloud-based blockchain service 82.

FIG. 8 further illustrates cloud-based services. Here the requesting client 84 is illustrated as a mobile smartphone 92. As the reader may understand, a user of the mobile smartphone 92 may open or access the electronic wallet 86 and order, request, or specify a transfer of crypto-funds. The mobile smartphone 92 may thus store and/or execute a mobile software application that provides an interface to the electronic wallet 86. Here, then, the mobile smartphone 92 may be programmed to locally infer the complex cryptographic coinage transaction 24. When the user of the mobile smartphone 92 orders or requests any crypto-coinage or blockchain transaction (again perhaps via the electronic wallet 86), the mobile smartphone 92 may determine the presence or specification of the multiple input account addresses 30 and/or the multiple output account addresses 32 and infers the complex accounting structure 28. Because the blockchain transaction involves the complex accounting structure 28, in response the mobile smartphone 92 may generate the service request 88 for the cloud-based blockchain service 82 that specifies either or both of the multiple input account addresses 30 and the multiple output account addresses 32. The mobile smartphone 92 sends the service request 88 to the network address (e.g., Internet Protocol address) associated with the sharding server 34. When the sharding server 34 receives the service request 88, the sharding server 34 implements the transactional sharding 20 and generates, performs, and/or manages the processing of the component simple cryptographic coinage transactions 26. Once all the component simple cryptographic coinage transactions 26 are processed (whether successful or failure), the sharding server 34 may send the service response 90 back to the mobile smartphone 92 detailing the simple cryptographic coinage transactions 26.

FIG. 9 illustrates a local solution. Here the mobile smartphone 92 may be programmed to locally implement and/or process the transactional sharding 20. That is, the mobile smartphone 92 may be programmed to inspect any or all crypto-coinage and blockchain transactions (perhaps generated by or associated with the electronic wallet 86). When any cryptographic coinage transaction 24 specifies the multiple input account addresses 30 and/or the multiple output account addresses 32, the mobile smartphone 92 may itself perform, or manage, the transactional sharding 20 of the complex cryptographic coinage transaction 24. The mobile smartphone 92, as an example, may be programmed to generate the component simple cryptographic coinage transactions 26 and to disperse or distribute the simple cryptographic coinage transactions 26 for processing. The mobile smartphone 92, in other words, may itself be programmed to simplify the complex cryptographic coinage transaction 24 into its component simple cryptographic coinage transactions 26. The mobile smartphone 92 may even have authority to open, establish, and/or coordinate the temporary account address 70.

Exemplary embodiments may also assess the cryptographic fee 50 for any portion of the transactional sharding 20. Cryptographic funds may be paid, or exchanged, for the transactional sharding 20. Any shard handler (that is, any service, device, or entity performing any portion of the transactional sharding 20) may charge additional cryptographic funds for the processing of each component simple cryptographic coinage transactions 26. The processing of each transactional shard (e.g., each simple cryptographic coinage transactions 26) may thus be distributed based on processing load, job backlog, and/or network congestion, especially when multiple servers compete for task assignments. The processing of each transactional shard may optionally be distributed based on account addresses.

Exemplary embodiments may thus include sharding of both blockchain transactions and of the blockchain environment 22 itself. It may be important in a fault tolerant system that the blockchain environment 22 never spread or broadcast any blockchain transaction that does not pass some sort of criterion. For example, in a cryptocurrency environment, the criterion may be that the input account address 30 has enough funds to cover the entire complex cryptographic coinage transaction 24 from the viewpoint of the nodes in the network (e.g., the blockchain environment 22). If the input account address 30 lacks a sufficient balance, then perhaps the nodes in the blockchain environment 22 will not gossip that complex cryptographic coinage transaction 24 (and/or its component simple cryptographic coinage transactions 26) all around the network. Simply put, without adequate funds, the blockchain environment 22 may not propagate any blockchain transaction. Otherwise, if any and/or all blockchain transactions is/are gossiped, then some rogue entity could fraudulently spoof the electronic wallet 86 and spew tons of bad transactions that would never clear and clog the network. Exemplary embodiments, instead, may assign the transactional sharding 20 to whatever server (such as the sharding server 34) and/or whatever slice or network shard 60 is responsible for verifying and validating the first input only. That server and/or network shard 60 thus ensures that there is/are enough funds on the input account address 30 to cover the entire sum of the component simple cryptographic coinage transactions 26 plus any cryptographic fee(s) 50.

FIG. 10 illustrates a refund mechanism 100. Most blockchain transactions are sent within the blockchain environment 22 to other network nodes for processing. Most nodes within the blockchain environment 22 (such as servers 62 and/or 64) may only validate the first input. So, when processing arrives to a final computer system (such as server 64) within the blockchain environment 22, if the entire blockchain transaction validates, then each simple cryptographic coinage transactions (e.g., 26a and 26b) may be recorded to the blockchain 38. But, if any component simple cryptographic coinage transaction 26 fails to process and/or times out (e.g., the blockchain environment 22 needs time for all balances to settle before inferring any transaction will not process or fails), that failure decision may implement the refund mechanism 100. All crypto-funds may be refunded from the temporary account address 70 back to the input account addresses 30, perhaps with the exception of the first input account address 30. Exemplary embodiments may charge the first input account address 30 the cryptographic processing fee 50 for unwinding all the component simple cryptographic coinage transactions 26. That is, any input account address 30 may get a refund of whatever it contributed to the overall cryptographic coinage transaction 24, less the cryptographic processing fee 50 it would have paid had any or all of the simple cryptographic coinage transactions 26 passed. This pay-for-processing refund mechanism 100 ensures that parties to any blockchain transaction pay a penalty for submitting transactions that do not process. Basically, parties may pay crypto-fees for network inspection and processing of transactions, even failures.

FIG. 11 illustrates a payor account address 102. The payor account address 102 pays for the transactional sharding 20. That is, the payor account address 102 may or may not be one of the multiple input account addresses 30 or the multiple output account addresses 32. For simplicity, FIG. 11 illustrates the payor account address 102 as a separate entry, data, or field from the multiple input account addresses 30 or the multiple output account addresses 32 specified by the complex cryptographic coinage transaction 24. The payor account address 102 may be represented as an entry, data, or field within any or all of the simple cryptographic coinage transactions 26. The payor account address 102 may be represented as one of the hash values 42. If the complex cryptographic coinage transaction 24 and/or the simple cryptographic coinage transactions 26 are packetized according to a packet protocol, the payor account address 102 may be represented as data or information within a header or payload within a data packet. Regardless, the payor account address(es) 102 specifies/specify the cryptocurrency account(s) that pay any or all the cryptographic processing fees 50 charged for the transactional sharding 20. The processing payer, in other words, need not be an input/output pair combination. The processing payer may thus be some party or entity (such as a subscribing financial entity) that pays for batch sharding of many complex cryptographic coinage transactions 24. Simply put, exemplary embodiments may be offered as a subscription service, and the payor account address 102 identifies the account of a subscriber.

FIG. 12 illustrates entry credits 110. Here exemplary embodiments may require one or more entry credits 110 for the transactional sharding 20. That is, exemplary embodiments need not charge or assess the cryptographic processing fee 50 to/from the input account addresses 30 and/or the output account addresses 32. Instead, the entry credits 110 may be paid or redeemed for accessing or using the transactional sharding 20. Similarly, the entry credits 110 may be paid or redeemed for requesting the transactional sharding 20 as the cloud-based blockchain service 82 (as explained with reference to FIGS. 7-8). The entry credits 110 (and the cryptographic processing fees 50) may thus help protect the blockchain environment 22 from spam, numerous failed transactions, and other attacks. As the reader may understand, denial of service attacks can cripple the blockchain environment 22 and jeopardize accurate processing and recording of blockchain transactions. The entry credits 110 (and the cryptographic processing fees 50) help keep rogue entities from attacking the blockchain environment 22.

FIG. 13 illustrates predictive qualities. Here exemplary embodiments may look-ahead and predict whether a particular blockchain transaction will pass or fail. Because exemplary embodiments may transactionally shard the complex cryptographic coinage transaction 24 into the simple cryptographic coinage transactions 26, each simple cryptographic coinage transaction 26 may be assigned to a single computer server for processing (such as the servers 64a-c, as explained with reference to FIGS. 5 & 10). Each simple cryptographic coinage transaction 26, in other words, is a transactional shard of the complex cryptographic coinage transaction 24, and its assigned server 64a-c has access to all of the account data required for processing that transactional shard all at once. The single computer server 64 may thus “look ahead” and quickly generate a prediction 112 as to whether its corresponding simple cryptographic coinage transaction 26 will succeed or fail. Exemplary embodiments may thus disperse or send the prediction 112 back to some processing manager (such as the sharding server 34), without fully processing the simple cryptographic coinage transaction 26. Exemplary embodiments need only compare a current account balance to a debit amount and predict sufficiency. So, when the sharding server 34 assigns the component simple cryptographic coinage transaction 26 to the server 64 for processing, the server 64 may report back its prediction 112. Once the sharding server 34 receives all the predictions 112 associated with all the simple cryptographic coinage transactions 26, the sharding server 34 may then authorize the actual accounting. That is, if all the simple cryptographic coinage transactions 26 are predicted to pass or to successfully process, then the sharding server 34 may approve cryptographic debit transactions from the input account addresses 30 and cryptographic deposit transactions to the output account addresses 32 (according to each debit or deposit amount, as specified by each simple cryptographic coinage transaction 26). The blockchain environment 22 thus processes the simple cryptographic coinage transaction 26, generates and records the block 36 of data in the blockchain ledger 44 of the blockchain 38, and/or generates and records hash values 42 (as explained with reference to FIG. 1). However, if any one or more of the predictions 112 indicates or estimates a failure, the sharding server 34 may be programmed or configured to abandon any or all of the simple cryptographic coinage transactions 26. Because no debit transactions or deposit transactions may have been authorized, no cryptographic funds were transferred and no refunds need be processed. Still, though, exemplary embodiments may charge or recoup the cryptographic processing fee 50 for generating and processing the predictions 112 (such as from any input account address 30 that fails due to a lack of crypto-funds).

The blockchain environment 22 thus creates an immutable ledger. If all the simple cryptographic coinage transactions 26 pass, each one of the simple cryptographic coinage transactions 26 is recorded in one of the blocks 36 of data within the blockchain 38 and perhaps cryptographically hashed. However, if any simple cryptographic coinage transaction 26 fails (whether an actual failure or a predicted failure), the blockchain environment 22 may abandon some or all of the simple cryptographic coinage transactions 26 and perhaps decline to record the failure in the blockchain 38. Exemplary embodiments, however, may implement a ledger policy that also records any failure in the blockchain 38. The sharding server 34, the blockchain 38, and/or the blockchain environment 22 may thus be configured to ledger, or not to ledger, any simple cryptographic coinage transaction 26 that fails.

FIG. 14 illustrates cryptographic holds. Here exemplary embodiments may implement a cryptographic hold order 120 on any of the input account addresses 30. That is, when the sharding server 34 receives, or is informed of, the complex cryptographic coinage transaction 24, the sharding server 34 may place the cryptographic hold order 120 on the cryptographic debit transactions from the input account addresses 30. The cryptographic hold order 120 may thus reserve, wall off, or isolate a debit amount from any of the input account addresses 30, as specified by the complex cryptographic coinage transaction 24. The cryptographic hold order 120 may be implemented for, and associated with, a hold time to ensure debit processing successfully passes. If all the cryptographic hold orders 120 succeed, then transfer orders may be sent to move inputs to outputs. The cryptographic hold order 120 thus ensures that cryptofunds currently available in the input account addresses 30 are dedicated to the complex cryptographic coinage transaction 24. Because blockchain transactions are preferably sequentially processed (perhaps according to time or sequential number), the cryptographic hold order 120 may prevent a subsequent blockchain transaction from debiting crypto-funds previously committed to a prior or preceding blockchain transaction.

Cryptographic holds may also be placed on deposits. When any cryptofunds are actually deposited, or predicted to deposit, into any of the output account addresses 32, exemplary embodiments may place the cryptographic hold order 120 on the cryptographic deposit transactions from the output account addresses 32. The cryptographic hold order 120 may thus reserve, wall off, or isolate a deposit amount into any of the output account addresses 32, as specified by the complex cryptographic coinage transaction 24. The cryptographic hold order 120 may be implemented for, and associated with, the hold time to ensure deposit processing successfully passes. The cryptographic hold order 120 thus ensures that cryptofunds cannot be subsequently overdrawn from the output account address 32. The cryptographic hold order 120 may thus prevent a subsequent blockchain transaction from overdrawing crypto-funds.

FIGS. 15-16 illustrate indexing of blockchain transactions. When the complex cryptographic coinage transaction 24 is transactionally sharded into the simple cryptographic coinage transactions 26 (via the transactional sharding 20, as above explained), exemplary embodiments may then index the input, output, and other transactional details. As a simple example, suppose the sharding server 34 stores, maintains, or access an electronic database 130. The electronic database 130 stores detailed processing records for the simple cryptographic coinage transactions 26. Suppose, for example, that the electronic database 130 has entries that relate, associate, or map each simple cryptographic coinage transaction 26 to its corresponding input account address 30 and its corresponding output account address 32. The entries may further relate each simple cryptographic coinage transaction 26 to its corresponding cryptographic debit amount 132 and cryptographic deposit amount 134. The entries may further relate each simple cryptographic coinage transaction 26 to its corresponding temporary account address 70 (if used or implemented). Moreover, the electronic database 130 may also store associations that relate each simple cryptographic coinage transaction 26 to its assigned processing server 64. For example, the electronic database 130 may relate the entries to the server's Internet protocol address 136, thus uniquely identifying the server 64 that processes the simple cryptographic coinage transaction 26. Exemplary embodiments may thus generate a central repository that indexes all the simple cryptographic coinage transactions 26 (and their respective debiting and depositing), according to the input account address 30, the output account address 32, the temporary account address 70, and/or the server 64.

FIG. 16 also illustrates indexing of blockchain transactions. Here, though, miners or federated servers (and their respective entities) may additionally or alternatively index the simple cryptographic coinage transactions 26. As the reader may understand, blockchain transactions may be processed, recorded, ledgered, and/or cryptographically hashed by one or more federated servers 140. While there may be many federated servers 140, for simplicity FIG. 16 only illustrates one federated server 140. The federated server 140 provides a service (such as processing and/or ledgering the simple cryptographic coinage transaction 26) and, in return, they are compensated according to a compensation or services agreement or scheme. Regardless, the federated server 140 may thus generate and maintain the electronic database 130 that locally indexes the simple cryptographic coinage transactions 26 processed by the federated server 140. The federated server 140 may thus index any simple cryptographic coinage transactions 26 that is receives or is instructed to process. Because every simple cryptographic coinage transaction 26 may be indexed according to amounts 132 and 134 and to account addresses 30, 32, 70, and/or 136, then the blockchain environment 22 has a mechanism to provide a cryptographic proof 142 of a current balance of any account address 30, 32, 70, without revealing, providing, or identifying information regarding other account addresses. In other words, exemplary embodiments may create a cryptographic sub-proof for an account address that does not involve (or hash) all the input account addresses 30 and/or the output account addresses 32 specified by the complex cryptographic coinage transaction 24. Moreover, the cryptographic proof 142 need not involve (or hash) all the data contained within the block 36 of data within the blockchain 38. This indexing capability increases the security of the lightweight electronic wallet 86 on mobile devices (such as the smartphone 92 explained with reference to FIGS. 7-9).

Exemplary embodiments thus present an elegant solution. The electronic wallet 86 allows the user to order or request transactions involving cryptocurrency coins. However, many cryptographic coinage transactions have the complex accounting structure 28, which creates processing complexities. Exemplary embodiments, though, implement an elegant solution that breaks down the complex cryptographic coinage transaction 24 into the simple cryptographic coinage transactions 26 having a point-to-point structure. The simple cryptographic coinage transactions 26 are quicker and easier to process, perhaps only requiring locally stored or accessible accounting information. Simply put, exemplary embodiments allow the electronic wallet 86 to be a thin-client software application that need not have programming or code for processing the cryptographic coinage transaction 24 having the complex accounting structure 28. The results of the simple cryptographic coinage transactions 26 are recorded to the blockchain 38 in a faster fashion with less messaging within the blockchain environment 22.

Exemplary embodiments may also retain current security features. The transactional sharding 20 need not affect conventional blockchain techniques, such as private keys or signs and verification via mining efforts. The transactional sharding 20 may still use a distributed consensus system that confirms pending transactions. The transactional sharding 20 is compatible with chronological/sequential ordering in the blockchain 38, still protects the neutrality of the blockchain environment 22 and network, and still allows miners to agree on the state of the system. The transactional sharding 20 is compatible cryptographic rules imposed on the block 36 of data in the blockchain 38, so verification remains compatible.

FIGS. 17-18 are more detailed illustrations of an operating environment, according to exemplary embodiments. FIG. 17 illustrates the sharding server 34 communicating via a communications network 150 with the other servers 62 and 64 in the blockchain environment 22. The sharding server 34 has a processor 152 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a sharding application 154 stored in a local, solid-state memory device 156. The sharding server 34 and the servers 62 and 64 have a network interface (not shown for simplicity) to the communications network 150, thus allowing two-way, bidirectional communication. The servers 62 and 64 also have processors that execute software applications stored in their local, solid-state memory devices, but these hardware components are also not shown for simplicity. The sharding application 154 includes instructions, code, and/or programs that cause the sharding server 34 to perform operations, such as authorizing and/or implementing the transactional sharding 20 of the cryptographic coinage transaction 24 (illustrated as “crypto-coinage trans”). The sharding application 154 instructs the sharding server 34 to inspect the cryptographic coinage transaction 24 and to initially determine, or to verify the presence of, the complex accounting structure 28. The complex accounting structure 28 may be inferred from any data or information indicating the presence of or specification of, the multiple input account addresses 30 and/or the multiple output account addresses 32. When the sharding server 34 determines the complex accounting structure 28, the sharding server 34 implements or authorizes the transactional sharding 20 of the “complex” cryptographic coinage transaction 24 into the multiple, simple cryptographic coinage transactions 26. The cryptographic coinage transaction 24 may thus be broken, parsed, decomposed, split, or sharded into the simple cryptographic coinage transactions 26 (perhaps using the temporary account address 70). Each one of the simple cryptographic coinage transactions 26 is a point-to-point transaction that only specifies or involves a single one of the input account addresses 30 and/or a single one of the output account addresses 32. The sharding server 34 may then disperse the simple cryptographic coinage transactions 26 via the communications network 150 for processing. That is, the sharding server 34 may itself process the debit/deposit transactions, the sharding server 34 may additionally or alternatively select or assign any processing server within the blockchain environment 22. For example, the sharding server 34 may send the simple cryptographic coinage transaction 26 to the server 64 and/or to the federated server 140.

FIG. 18 illustrates processing of the simple cryptographic coinage transaction 26. Here the sharding server 34 generates the simple cryptographic coinage transactions 26 and then disperses the simple cryptographic coinage transactions 26 for processing. That is, the sharding server 34 selects or assigns any server within the blockchain environment 22 and sends one or more of the simple cryptographic coinage transactions 26 via the communications network 150 to the server for processing. While any server or device node within the blockchain environment 22 may be capable of processing the simple cryptographic coinage transactions 26, FIG. 18 illustrates the federated server 140. The federated server 140 has a processor 160 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a blockchain application 162 stored in a local, solid-state memory device 164. The federated server 140 also has a network interface (not shown for simplicity) to the communications network 150, thus allowing two-way, bidirectional communication. The blockchain application 162 includes instructions, code, and/or programs that cause the federated server 140 to perform operations, such as processing the simple cryptographic coinage transaction (“simple crypto-coinage trans”) 26 having a simple accounting structure 166 (e.g., debit from the single input account address 30 and/or deposit into the single output account address 32, either 30 or 32 of which may be the temporary account address 70). Moreover, the blockchain application 162 may further instruct the federated server 140 to generate the block 36 of data that documents or records the inputs and outputs associated with the simple cryptographic coinage transaction 26. The blockchain application 162 may further instruct the federated server 140 to call or invoke the hashing algorithm 40 to generate the one or more hash values 42 representing the simple cryptographic coinage transaction 26 and/or the block 36 of data. The simple cryptographic coinage transaction 26, the block 36 of data, and/or the hash values 42 may then be published via the blockchain 38 as the blockchain ledger 44.

Compensation may be due. As the simple cryptographic coinage transactions 26 are generated and/or processed, the cryptographic fee 50 may be charged, assessed, or debited. For example, the sharding server 34 may assess or debit the cryptographic fee 50 for authorizing, generating, and/or managing the transactional sharding 20 of the complex cryptographic coinage transaction 24. The cryptographic fee 50 may thus be assessed or charged to any one or more of the input account addresses 30 for the transactional sharding 20 of the complex cryptographic coinage transaction 24. Additional cryptographic fees 50 may be paid for the processing of the simple cryptographic coinage transactions 26. The cryptographic fees 50 may thus transfer to, or be deposited into, a service provider's account address that operates the sharding server 34 and/or the federated server 140 as the cloud-based blockchain service 82 (as explained with reference to FIGS. 7-8). The cryptographic fees 50 may also transfer to, or be deposited into, the payor account address 102 (as explained with reference to FIG. 11).

The entry credits 110 may be required. Exemplary embodiments may impose or require one or more of the entry credits 110 for the transactional sharding 20. The entry credits 110 may be paid or redeemed for accessing the sharding server 34 and/or for using the transactional sharding 20. Similarly, the entry credits 110 may be paid or redeemed for requesting the transactional sharding 20 as the cloud-based blockchain service 82. The entry credits 110 (and the cryptographic processing fees 50) thus protect the blockchain environment 22 from spam, numerous failed/fraudulent transactions, and other attacks. As the reader may understand, denial of service attacks can cripple the blockchain environment 22 and may jeopardize accurate processing and recording of blockchain transactions. The entry credits 110 (and the cryptographic processing fees 50) help keep rogue entities from attacking the blockchain environment 22.

Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to stationary or mobile devices having cellular, wireless local area networking capability (such as WI-FI®), near field, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the radio spectrum and IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).

Exemplary embodiments may utilize any processing component, configuration, or system. Any processor could be multiple processors, which could include distributed processors or parallel processors in a single machine or multiple machines. The processor can be used in supporting a virtual processing environment. The processor could include a state machine, application specific integrated circuit (ASIC), programmable gate array (PGA) including a Field PGA, or state machine. When any of the processors execute instructions to perform “operations,” this could include the processor performing the operations directly and/or facilitating, directing, or cooperating with another device or component to perform the operations.

Exemplary embodiments may packetize. When any device or server communicates via the communications network 150, the device or server may collect, send, and retrieve information. The information may be formatted or generated as packets of data according to a packet protocol (such as the Internet Protocol). The packets of data contain bits or bytes of data describing the contents, or payload, of a message. A header of each packet of data may contain routing information identifying an origination address and/or a destination address.

FIGS. 19-21 are more detailed illustrations of indexing the cryptographic coinage transaction 24, according to exemplary embodiments. When the so-called “complex” cryptographic coinage transaction 24 is transactionally sharded into the simple cryptographic coinage transactions 26 (via the transactional sharding 20, as above explained), exemplary embodiments may generate an electronic relational index 170 that describes the input, output, and other transactional details of each cryptographic coinage transaction 26. FIG. 19, for simplicity, illustrates the sharding server 34 locally storing the electronic database 130 in its memory device 156. The electronic database 130, though, may be remotely located and maintained by any node within the blockchain environment 22 (such as the federated server 140, as this disclosure above explains). As any simple cryptographic coinage transaction 26 is generated and/or processed within the blockchain environment 22, exemplary embodiments may remotely or locally archive its transactional details in the electronic database 130.

FIG. 20 illustrates an example of the electronic database 130. While the electronic database 130 may have any logical structure, a relational database structure is thought easiest to understand. FIG. 20 thus illustrates the index 170 as a table 172 that maps, converts, or translates each simple cryptographic coinage transaction 26 to its corresponding input account address 30, crypto-debit amount 132, temporary account address 70, output account address 32, and crypto-deposit amount 134. The simple cryptographic coinage transaction 26 may optionally be uniquely identified by an alphanumeric transaction identifier 174 and/or one of the hash values 42 generated by the hashing algorithm 40 (as above explained). Moreover, the index 170 may further relate and identify a processing assignment 176 within the blockchain environment 22. The processing assignment 176 identifies the network node or server that processes the simple cryptographic coinage transaction 26. For example, the processing assignment 176 may be the IP address 178 assigned to the servers 62 or 64, the federated server 140, and/or the network shard 60 that processes the simple cryptographic coinage transaction 26. Any of the entries in the index 170 may further relate and identify the electronic wallet 86 (and/or its public/private cryptographic key) that is associated with the simple cryptographic coinage transaction 26. Exemplary embodiments may thus generate a central repository that indexes any data or information associated with the simple cryptographic coinage transaction 26 (and its respective debiting and depositing), according to the input account address 30, the output account address 32, the temporary account address 70, and/or the processing assignment 176. Once any entry is known, exemplary embodiments may then query for any query parameter and identify, and even retrieve, its corresponding entry. Exemplary embodiments may thus perform a database lookup operation to identify and even retrieve related entries. The electronic database 130 may thus function or serve as a historical repository or archive that documents the cryptographic coinage transaction 24, its corresponding simple cryptographic coinage transactions 26, and their transactional details.

FIG. 21 further illustrates indexing of blockchain transactions. Here the electronic database 130 is locally stored and maintained by the federated server 140. Again, should the federated server 140 mine/process any simple cryptographic coinage transaction 26, the federated server 140 may update the index 170 with transactional details. The blockchain application 162, for example, instructs the federated server 140 to add entries that relate the simple cryptographic coinage transaction 26 to its corresponding input account address 30, crypto-debit amount 132, temporary account address 70, output account address 32, and crypto-deposit amount 134. Moreover, the index 170 may further identify the federated server 140 that processes the simple cryptographic coinage transactions 26 (such as its IP address 178 or network shard 60). Moreover, if exemplary embodiments generate the block 36 of data in the blockchain 38, exemplary embodiments may further log the block 36 of data (such as a unique block identifier) and the unique chain identifier 180 that documents the simple cryptographic coinage transaction 26. If the block 36 of data is hashed (using the hashing algorithm 40, as above explained), the index 170 may further log the corresponding hash value 42 as the cryptographic proof representing any of the transactional details.

Miners may index. The miner entities (operating the federated server 140) may process, record, ledger, and/or cryptographically hash the simple cryptographic coinage transactions 26. The miners provide a service (such as processing and/or ledgering the simple cryptographic coinage transactions 26) and, in return, are compensated (perhaps via the cryptographic fee 50 and/or the entry credits 110). Each miner may thus have an incentive to accurately index their mining operations to cryptographically prove processing efforts. Because any simple cryptographic coinage transactions 26 may be indexed according to amount (e.g., the crypto-debit amount 132 and/or the crypto-deposit amount 134, as above explained) and/or according to any account address (e.g., the input account address 30, the temporary account address 70, and/or the output account address 32), then the federated server 140 and the blockchain environment 22 have a mechanism to provide the cryptographic proof of the current balance of the input account address 30, the temporary account address 70, and/or the output account address 32 without revealing, providing, or identifying information regarding other account addresses 30 and 32. In other words, exemplary embodiments may create a cryptographic sub-proof for an account address that does not involve (or hash) all the input account addresses 30 and/or the output account addresses 32 specified by the complex cryptographic coinage transaction 24. Moreover, the cryptographic proof need not involve (or hash) all the data contained within the block 36 of data within the blockchain 38. This indexing capability increases the security of the lightweight electronic wallet 86 on mobile devices (such as the smartphone 92 explained with reference to FIGS. 8-9).

The index 170 may also log data according to the blockchain 38. That is, the entries in the electronic database 130 may be organized according to an identifier of the blockchain 38. A chain identifier, for example, is a unique alphanumeric combination or hash value that differentiates different blockchains. The index 170 may thus log or store entries in relational association with their corresponding chain identifier. Blockchains may thus have entries that relate a device, user, and other entries to its corresponding chain identifier. New and old data in time may be associated with, linked to, identified by, and/or retrieved using the chain identifier. Each chain identifier may thus functionally resemble a directory (e.g., files and folders), as this disclosure explains with reference to FIGS. 23-30.

FIG. 22 illustrates the service mechanism, according to exemplary embodiments. This disclosure above explained how exemplary embodiments may include the cloud-based blockchain service 82 provided by the cloud service provider 80. When the blockchain environment 22 determines that the cryptographic coinage transaction 24 specifies the complex accounting structure 28, any server or device within the blockchain environment 22 may outsource or subcontract the cryptographic coinage transaction 24 to the cloud service provider 80. Suppose, for example, that any resource operating within the blockchain environment 22 (such as the server 62 acting as the requesting client 84) determines that the cryptographic coinage transaction 24 specifies the complex accounting structure 28. The server 62 may then generate and send the service request 88 via the communications network 150 to the network address (such as an Internet protocol address) associated with the sharding server 34. The service request 88 may include or specify the input account addresses 30, the output account addresses 32, the crypto-debit amount(s) 132, and/or the crypto-deposit amount(s) 134 (perhaps all specified by the cryptographic coinage transaction 24). The sharding application 154 acts on information in the service request 88, generates the simple cryptographic coinage transactions 26 (perhaps even selecting or implementing the temporary account address 70), and generates the service response 90. The service response 90 may thus merely include generating the simple cryptographic coinage transactions 26 and returning the simple cryptographic coinage transactions 26 back to the requesting client 84 for processing. The service response 90, however, may be more comprehensive and include processing the simple cryptographic coinage transactions 26, generating the block 36 of data in the blockchain 38, and perhaps generating the cryptographic hash value(s) 42 representing any of the service response 90. The requesting client 84 in the blockchain environment 22 and the sharding server 34 may thus cooperate in a client/server fashion and cooperate to send, receive, and/or generate the service request 88, the service response 90, and/or the block 36 of data in the blockchain 38. The cryptographic fee 50 may then be charged, assessed, or debited.

FIGS. 23-25 further illustrate the cloud-based blockchain service 82, according to exemplary embodiments. Here exemplary embodiments may further interface with a data layer server 190. The data layer server 190 generates data records 192 in a blockchain data layer 194. When the sharding server 34 implements and/or performs the transactional sharding 20 of the cryptographic coinage transaction 24 (having the complex accounting structure 28), the data records 192 in the blockchain data layer 194 may specifically describe, perhaps in detail, the transactional sharding 20 of the cryptographic coinage transaction 24 into the simple cryptographic coinage transactions 26. The sharding server 34 and the data layer server 190 may thus cooperate to provide and/or document the cloud-based blockchain service 82. For example, when the sharding server 34 receives the service request 88, the sharding server 34 may inform the data layer server 190 of the service request 88, the input account addresses 30, the output account addresses 32, the crypto-debit amounts 132, the crypto-deposit amounts 134, and/or the temporary account address 70. The sharding server 34 may simply copy and/or forward the service request 88 to the IP address associated with the data layer server 190 (as illustrated), or exemplary embodiments may generate and send a notification message that describes or contains the content of the service request 88. Moreover, the sharding server 34 may further forward or inform the data layer server 190 of the service response 90. In general, the data records 192 in the blockchain data layer 194 describe and document the service request 88 and the service response 90.

FIG. 24 further illustrates the data layer server 190. The data layer server 190 has a processor 196 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a data layer application 198 stored in a local, solid-state memory device 200. The data layer server 190 has a network interface to the communications network 150, thus allowing two-way, bidirectional communication. The data layer application 198 includes instructions, code, and/or programs that cause the data layer server 190 to perform operations, such as generating the data records 192 in the blockchain data layer 194. Moreover, the data layer server 190 may also add an additional layer of cryptographic hashing (using the hashing algorithm 40) to generate one or more cryptographic proofs 202. The cryptographic proofs 202 may then be incorporated into a public blockchain 204. The cloud-based blockchain service 82 may then publicly publish or distribute the public blockchain 204 (such as via the Internet). The public blockchain 204 thus serves or acts as a validation of the cloud-based blockchain service 82 (perhaps described by the data records 192 within the blockchain data layer 194). The public blockchain 204 thus publishes the cryptographic proofs 202 to confirm that the complex cryptographic coinage transaction 24 was transactionally sharded into the simple cryptographic coinage transactions 26 and processed to success or failure. The cryptographic proof 202, in other words, acts as a data anchor in the public blockchain 204 to document the date and time that the cloud-based blockchain service 82 was executed. The public blockchain 204 thus acts as a public blockchain ledger 206 that establishes chains of blocks of immutable evidence. Each cryptographic proof 202 thus provides evidentiary documentation of the cloud-based blockchain service 82.

FIG. 25 illustrates additional publication mechanisms. Once the blockchain data layer 194 is generated, some of the blockchain data layer 194 may be published in a decentralized manner to any destination. The data layer server 190, for example, may generate and distribute the public blockchain 204 (via the communications network 150 illustrated in FIGS. 17-18) to one or more of the federated servers 140. The federated server 140 provides a service and, in return, is compensated according to a compensation or services agreement or scheme.

Exemplary embodiments include still more publication mechanisms. For example, the cryptographic proof 202 and/or the public blockchain 204 may be sent (via the communications network 150 illustrated in FIGS. 17-18) to yet another server 210. The server 210 may then add another, third layer of cryptographic hashing (perhaps using the hashing algorithm 40) and generate another or second public blockchain 212. While the server 210 and/or the second public blockchain 212 may be operated by, or generated for, any entity, exemplary embodiments may integrate another cryptographic coin mechanism. That is, the server 210 and/or the second public blockchain 212 may be associated with BITCOIN®, ETHEREUM®, RIPPLE®, or other cryptographic coin mechanism. The cryptographic proof 202 and/or the second public blockchain 212 may be publicly distributed and/or documented as evidentiary validation. The cryptographic proof 202 and/or the second public blockchain 212 may thus be historically and publicly anchored for public inspection and review.

FIGS. 26-30 further illustrate the blockchain data layer 194, according to exemplary embodiments. The blockchain data layer 194 may chain hashed directory blocks 220 of data into the public blockchain 204. For example, the blockchain data layer 194 accepts input data (such as the service request 88, input account addresses 30, the output account addresses 32, the crypto-debit amounts 132, the crypto-deposit amounts 134, the temporary account address 70, and/or the service response 90, as above explained) within a window of time. While the window of time may be configurable from fractions of seconds to hours, exemplary embodiments use ten (10) minute intervals. FIG. 26 illustrates a simple example of only three (3) directory blocks 220a-c of data, but in practice there may be millions or billions of different blocks. Each directory block 220 of data is linked to the preceding blocks in front and the following or trailing blocks behind. The links are created by hashing all the data within a single directory block 220 and then publishing that hash value within the next directory block. Each directory block 220 of data may further include or reference or specify the privacy parameter 64.

As FIG. 27 illustrates, published data may be organized within chains 222. Each chain 222 is created with an entry that associates a corresponding chain identifier 224. Any device, network node, user, or requesting client, in other words, may have its/her corresponding chain identifier 224a-d. The blockchain data layer 194 may thus track any data associated with the entity with its corresponding chain identifier 224a-d. New and old data in time may be associated with, linked to, identified by, and/or retrieved using the chain identifier 224a-d. Each chain identifier 224a-d thus functionally resembles a directory 226a-d (e.g., files and folders) for organized data entries according to the entity. Each chain 222 and/or each directory 226 may further include or reference or specify the service request 88, input account addresses 30, the output account addresses 32, the crypto-debit amounts 132, the crypto-deposit amounts 134, the temporary account address 70, and/or the service response 90.

FIG. 28 illustrates the data records 192 in the blockchain data layer 194. As data is received as an input (such as the blocks 56 of data, the service request 88, the input account addresses 30, the output account addresses 32, the crypto-debit amounts 132, the crypto-deposit amounts 134, the temporary account address 70, and/or the service response 90), data is recorded within the blockchain data layer 194 as an entry 228. While the data may have any size, small chunks (such as 10 KB) may be pieced together to create larger file sizes. One or more of the entries 228 may be arranged into entry blocks 230 representing each chain 222 according to the corresponding chain identifier 224. New entries for each chain 222 are added to their respective entry block 230 (again perhaps according to the corresponding chain identifier 224). After the entries 228 have been made within the proper entry blocks 230, all the entry blocks 230 are then placed within the directory block 220 generated within or occurring within a window 232 of time. While the window 232 of time may be chosen within any range from seconds to hours, exemplary embodiments may use ten (10) minute intervals. That is, all the entry blocks 230 generated every ten minutes are placed within in the directory block 220. Each entry 228, each entry block 230, and each directory block 220 may further include or reference or specify the service request 88, input account addresses 30, the output account addresses 32, the crypto-debit amounts 132, the crypto-deposit amounts 134, the temporary account address 70, and/or the service response 90.

FIG. 29 illustrates cryptographic hashing. The data layer server 190 executes the data layer application 198 to generate the data records 192 in the blockchain data layer 194. The data layer application 198 may then instruct or cause the data layer server 190 to execute the hashing algorithm 40 on the data records 192 (such as the directory block 220 explained with reference to FIGS. 26-28). The hashing algorithm 40 thus generates the one or more hash values 42 as a result, and the hash values 42 represent the hashed data records 192. As one example, the blockchain data layer 194 may apply a Merkle tree analysis to generate a Merkle root (representing a Merkle cryptographic proof 202) representing each directory block 220. The data layer server 190 may then publish the Merkle proof 202 in the public blockchain 204 (as this disclosure above explains).

FIG. 30 illustrates hierarchical hashing. The sharding server 34 may receive the complex cryptographic coinage transaction 24, implement the transactional sharding 20, and generate the multiple, simple cryptographic coinage transactions 26. The sharding server 34 may then call or execute the hashing algorithm 40 to provide a first layer 240 of cryptographic hashing and then generate a first blockchain 242. Any blocks of data within the first blockchain 242 may be sent to a destination associated with the data layer server 190. The data layer server 190 may thus generate the data records 192 in the blockchain data layer 194. The data layer server 190 may optionally provide a second or intermediate layer 244 of cryptographic hashing to generate the cryptographic proof 202. The data layer server 190 may also publish any of the data records 192 as the public blockchain 204. The cryptographic proof 202 may or may not also be published via the public blockchain 204, perhaps again based on the privacy parameter 64. The public blockchain 204 and/or the cryptographic proof 202 may be optionally sent to the server 210 as an input to yet another public blockchain 212 (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) for a third layer 246 of cryptographic hashing and public publication. The first layer 240 and the second layer 242 thus ride or sit atop a conventional public blockchain 212 (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) and provide additional public and/or private cryptographic proofs.

Exemplary embodiments may use any hashing function. Many readers may be familiar with the SHA-256 hashing algorithm. The SHA-256 hashing algorithm acts on any electronic data or information to generate a 256-bit hash value as a cryptographic key. The key is thus a unique digital signature. There are many hashing algorithms, though, and exemplary embodiments may be adapted to any hashing algorithm.

FIG. 31 further illustrates crypto-payments, according to exemplary embodiments. As this disclosure above explained, when the data layer server 190 generates the data records 192 in the blockchain data layer 194, exemplary embodiments may compensate the cloud-based service provider 80 operating the sharding server 34 and/or the data layer server 190. While the compensation may be a conventional currency, FIG. 31 again illustrates the cryptographic fee 50. Here, though, the cryptographic fee 50 may be based on the data records 192 generated in the blockchain data layer 194. That is, exemplary embodiments may charge, impose, and/or process the cryptographic fee 50 based on the entries 228, entry blocks 230, and/or the directory blocks 220 generated within the blockchain data layer 194. That is, as the data records 192 are generated, exemplary embodiments may sum or count the entries 228, entry blocks 230, and/or the directory blocks 220 that are generated over time (such as per second, per minute, or other interval). The cloud-based blockchain service 82, for example, calls or initializes a counter having an initial value (such as zero). At an initial time, the counter commences or starts counting or summing the number of the entries 228, entry blocks 230, and/or the directory blocks 220 (generated within the blockchain data layer 194) that are commonly associated with or reference the input account address 30, output account address 32, and/or temporary account address 70. The counter stops counting or incrementing at a final time and/or when no more data records 192 are generated. Regardless, exemplary embodiments determine or read the final value or count. Exemplary embodiments may then sum or tally a total number of the data records 192 that were generated and perhaps even a rate 268 of generation (e.g., the sum or count over time). The service provider may then process the cryptographic fee 50 based on the total number of the data records 192 and/or the rate 268 of generation within the blockchain data layer 194.

FIG. 32 is a flowchart illustrating a method or algorithm for the transactional sharding 20, according to exemplary embodiments. The sharding server 34 may receive the complex cryptographic coinage transaction 24 (Block 300), identify and/or verify the complex accounting structure 28 (Block 302), and implement the transactional sharding 20 (Block 304). The multiple, simple cryptographic coinage transactions 26 are generated (Block 306). The data records 192 in the blockchain data layer 194 may be generated (Block 308). The data records 192 may be cryptographically hashed (Block 310) and published in the public blockchain 204 (Block 312).

FIG. 33 is a schematic illustrating still more exemplary embodiments. FIG. 33 is a more detailed diagram illustrating a processor-controlled device 350. As earlier paragraphs explained, the sharding application 154, the blockchain application 162, and/or the data layer application 198 may partially or entirely operate in any mobile or stationary processor-controlled device. FIG. 33, then, illustrates the sharding application 154, the blockchain application 162, and/or the data layer application 198 stored in a memory subsystem of the processor-controlled device 350. One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlled device 350 is well known to those of ordinary skill in the art, no further explanation is needed.

FIG. 34 depicts other possible operating environments for additional aspects of the exemplary embodiments. FIG. 34 illustrates the sharding application 154, the blockchain application 162, and/or the data layer application 198 operating within various other processor-controlled devices 350. FIG. 34, for example, illustrates that the sharding application 154, the blockchain application 162, and/or the data layer application 198 may entirely or partially operate within a set-top box (“STB”) or other media player (352), a personal/digital video recorder (PVR/DVR) 354, a Global Positioning System (GPS) device 356, an interactive television 358, a tablet computer 360, or any computer system, communications device, or processor-controlled device utilizing any of the processors above described and/or a digital signal processor (DP/DSP) 362. Moreover, the processor-controlled device 350 may also include wearable devices (such as watches), radios, vehicle electronics, cameras, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of the various devices 350 are well known, the hardware and software componentry of the various devices 350 are not further shown and described.

Exemplary embodiments may be applied to any signaling standard. Most readers are thought familiar with the Global System for Mobile (GSM) communications signaling standard. Those of ordinary skill in the art, however, also recognize that exemplary embodiments are equally applicable to any communications device utilizing the Time Division Multiple Access signaling standard, the Code Division Multiple Access signaling standard, the “dual-mode” GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signaling standard. Exemplary embodiments may also be applied to other standards, such as the I.E.E.E. 802 family of standards, the Industrial, Scientific, and Medical band of the electromagnetic spectrum, BLUETOOTH®, and any other.

Exemplary embodiments may be physically embodied on or in a computer-readable non-transitory storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for the transaction sharding 22 in the blockchain environment 22, as the above paragraphs explain.

While the exemplary embodiments have been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the exemplary embodiments are not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the exemplary embodiments.

Claims

1. A non-transitory memory device storing instructions that, when executed by a hardware processor of a sharding server in a sharded blockchain, perform operations, the operations comprising: receiving, by the sharding server, a blockchain-based cryptographic coinage transaction conducted via an internet between a set of computers, wherein the sharded blockchain includes a plurality of blockchain shards, and wherein each blockchain shard of the plurality of blockchain shards is configured to process a different set of simple cryptographic coinage transactions;determining, by the sharding server, that the received blockchain-based cryptographic coinage transaction is a complex transaction;in response to determining that the received blockchain-based cryptographic coinage transaction is a complex transaction,transactionally sharding, by the sharding server, the complex transaction into multiple blockchain-based simple cryptographic coinage transactions, each simple cryptographic coinage transaction being one of(i) a debit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being a temporary account address and a second address of the two account addresses being an input account address, and(ii) a deposit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being the temporary account address, and a second address of the two account addresses being an output account address;assigning, by the sharding server, each blockchain-based simple cryptographic coinage transaction of the multiple blockchain-based simple cryptographic coinage transactions to a corresponding blockchain shard of the plurality of blockchain shards for processing;transmitting, by the sharding server, for debit processing, each debit transaction of the multiple blockchain-based simple cryptographic coinage transactions to the debit transaction's corresponding blockchain shard;determining that all debit transactions of the multiple blockchain-based simple cryptographic coinage transactions debit-processed successfully; andin response to determining that all the debit transactions of the multiple blockchain-based single cryptographic coinage transactions debit-processed successfully, transmitting each deposit transaction of the multiple blockchain-based simple cryptographic coinage transactions, to the deposit transaction's corresponding blockchain shard for credit processing.
2. The non-transitory memory device of claim 1, wherein the operations further comprise recording the multiple blockchain-based simple cryptographic coinage transactions to the sharded blockchain.
3. The non-transitory memory device of claim 1, wherein the operations further comprise transacting a cryptocoinage in response to the transactionally sharding of the complex transaction.
4. The non-transitory memory device of claim 1, wherein, following determining that the blockchain-based cryptographic coinage transaction is a complex transaction, a cryptographic coinage hold is placed against at least one of the blockchain input account addresses associated with the debit transactions of the multiple blockchain-based simple cryptographic coinage transactions, and wherein the cryptographic coinage hold expires after a predetermined time.
5. A system comprising a sharding server in a sharded blockchain, the sharding server including: a hardware processor; anda memory device storing instructions that, when executed by the hardware processor of the sharding server, perform operations, the operations comprising:receiving, by the sharding server, a blockchain-based cryptographic coinage transaction conducted via an internet between a set of computers, wherein the sharded blockchain includes a plurality of blockchain shards, and wherein each blockchain shard of the plurality of blockchain shards is configured to process a different set of simple cryptographic coinage transactions;determining, by the sharding server, that the received blockchain-based cryptographic coinage transaction is a complex transaction;in response to determining that the received blockchain-based cryptographic coinage transaction is a complex transaction,transactionally sharding, by the sharding server, the complex transaction into multiple blockchain-based simple cryptographic coinage transactions, each simple cryptographic coinage transaction being one of (i) a debit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being a temporary account address and a second address of the two account addresses being an input account address, and(ii) a deposit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being the temporary account address, and a second address of the two account addresses being an output account address;assigning, by the sharding server, for debit processing, each blockchain-based simple cryptographic coinage transaction of the multiple blockchain-based simple cryptographic coinage transactions to a corresponding blockchain shard of the plurality of blockchain shards for processing;transmitting, by the sharding server, for debit processing, each debit transaction of the multiple blockchain-based simple cryptographic coinage transactions to the debit transaction's corresponding blockchain shard;determining that all debit transactions of the multiple blockchain-based simple cryptographic coinage transactions debit-processed successfully; andin response to determining that all the debit transactions of the multiple blockchain-based single cryptographic coinage transactions debit-processed successfully, transmitting each deposit transaction of the multiple blockchain-based simple cryptographic coinage transactions, to the deposit transaction's corresponding blockchain shard for credit processing.
6. The system of claim 5, wherein the operations further comprise recording the multiple blockchain-based simple cryptographic coinage transactions to the sharded blockchain.
7. The system of claim 5, wherein the operations further comprise transacting a cryptocoinage in response to the transactionally sharding of the complex transaction.
8. The system of claim 5, wherein, following determining that the blockchain-based cryptographic coinage transaction is a complex transaction, a cryptographic coinage hold is placed against at least one of the blockchain input account addresses associated with the debit transactions of the multiple blockchain-based simple cryptographic coinage transactions, and wherein the cryptographic coinage hold expires after a predetermined time.
9. A method comprising: receiving, by a sharding server in a sharded blockchain, a blockchain-based cryptographic coinage transaction conducted via an internet between a set of computers, wherein the sharded blockchain includes a plurality of blockchain shards, and wherein each blockchain shard of the plurality of blockchain shards is configured to process a different set of simple cryptographic coinage transactions;determining, by the sharding server, that the received blockchain-based cryptographic coinage transaction is a complex transaction;in response to determining that the received blockchain-based cryptographic coinage transaction is a complex transaction, transactionally sharding, by the sharding server, the complex transaction into multiple blockchain-based simple cryptographic coinage transactions, each simple cryptographic coinage transaction being one of(i) a debit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being a temporary account address and a second address of the two account addresses being an input account address, and(ii) a deposit transaction specifying two account addresses on the sharded blockchain, one address of the two account addresses being the temporary account address, and a second address of the two account addresses being an output account address;assigning, by the sharding server, each blockchain-based simple cryptographic coinage transaction of the multiple blockchain-based simple cryptographic coinage transactions to a corresponding blockchain shard of the plurality of blockchain shards for processing;transmitting, by the sharding server, each debit transaction of the multiple blockchain-based simple cryptographic coinage transactions to the debit transaction's corresponding blockchain shard for debit processing;determining that all debit transactions of the multiple blockchain-based simple cryptographic coinage transactions debit-processed successfully; andin response to determining that all the debit transactions of the multiple blockchain-based single cryptographic coinage transactions debit-processed successfully, transmitting each deposit transaction of the multiple blockchain-based simple cryptographic coinage transactions, to the deposit transaction's corresponding blockchain shard for credit processing.
10. The method of claim 9, wherein the operations further comprise recording the multiple blockchain-based simple cryptographic coinage transactions to the sharded blockchain.
11. The method of claim 9, wherein the operations further comprise transacting a cryptocoinage in response to the transactionally sharding of the complex transaction.
12. The method of claim 9, wherein, following determining that the blockchain-based cryptographic coinage transaction is a complex transaction, a cryptographic coinage hold is placed against at least one of the blockchain input account addresses associated with the debit transactions of the multiple blockchain-based simple cryptographic coinage transactions, and wherein the cryptographic coinage hold expires after a predetermined time.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims domestic benefit of U.S. Provisional Application No. 62/714,911 filed Aug. 6, 2018 and incorporated herein by reference in its entirety. This application also claims domestic benefit of U.S. Provisional Application No. 62/714,909 filed Aug. 6, 2018 and incorporated herein by reference in its entirety.

US Referenced Citations (441)

Number	Name	Date	Kind
4309569	Merkel	Jun 1982	A
5499294	Friedman	Mar 1996	A
5606609	Houser	Feb 1997	A
5862218	Steinberg	Jan 1999	A
5920629	Rosen	Jul 1999	A
5966446	Davis	Oct 1999	A
6363481	Hardjono	Mar 2002	B1
7028263	Maguire	Apr 2006	B2
7212808	Engstrom	May 2007	B2
7272179	Siemens et al.	Sep 2007	B2
7572179	Choi et al.	Aug 2009	B2
7729950	Mendizabal et al.	Jun 2010	B2
7730113	Payette	Jun 2010	B1
8245038	Golle et al.	Aug 2012	B2
8266439	Haber et al.	Sep 2012	B2
8359361	Thornton	Jan 2013	B2
8442903	Zadoorian et al.	May 2013	B2
8560722	Gates et al.	Oct 2013	B2
8612477	Becker	Dec 2013	B2
8706616	Flynn	Apr 2014	B1
8712887	DeGroeve et al.	Apr 2014	B2
8867741	McCorkindale et al.	Oct 2014	B2
8943332	Horne et al.	Jan 2015	B2
8990322	Cai	Mar 2015	B2
9124423	Jennas, II et al.	Sep 2015	B2
9378343	David	Jun 2016	B1
9396006	Kundu et al.	Jul 2016	B2
9398018	MacGregor	Jul 2016	B2
9407431	Bellare et al.	Aug 2016	B2
9411524	O'Hare et al.	Aug 2016	B2
9411976	Irvine	Aug 2016	B2
9411982	Dippenaar et al.	Aug 2016	B1
9424576	Vandervort	Aug 2016	B2
9436923	Sriram	Sep 2016	B1
9436935	Hudon	Sep 2016	B2
9472069	Roskowski	Oct 2016	B2
9489827	Quinn et al.	Nov 2016	B2
9584493	Leavy	Feb 2017	B1
9588790	Wagner	Mar 2017	B1
9647977	Levasseur	May 2017	B2
9722790	Ebrahimi	Aug 2017	B2
9794074	Toll	Oct 2017	B2
9818109	Loh	Nov 2017	B2
9830580	MacGregor	Nov 2017	B2
9875510	Kasper	Jan 2018	B1
9876646	Ebrahimi	Jan 2018	B2
9882918	Ford et al.	Jan 2018	B1
10025941	Griffin	Jul 2018	B1
10046228	Tran	Aug 2018	B2
10102265	Madisetti	Oct 2018	B1
10102526	Madisetti	Oct 2018	B1
10108954	Dunlevy	Oct 2018	B2
10135607	Roets	Nov 2018	B1
10163080	Chow	Dec 2018	B2
10269009	Winklevoss	Apr 2019	B1
10270599	Nadeau	Apr 2019	B2
10346815	Glover	Jul 2019	B2
10355869	Bisti	Jul 2019	B2
10366204	Tanner, Jr.	Jul 2019	B2
10373129	James	Aug 2019	B1
10411897	Paolini-Subramanya	Sep 2019	B2
10419225	Deery	Sep 2019	B2
10438285	Konstantinides	Oct 2019	B1
10476847	Smith	Nov 2019	B1
10532268	Tran	Jan 2020	B2
10586270	Reddy	Mar 2020	B2
10628268	Baruch	Apr 2020	B1
10685399	Snow	Jun 2020	B2
10693652	Nadeau	Jun 2020	B2
10749848	Voell	Aug 2020	B2
10764752	Avetisov	Sep 2020	B1
10783164	Snow	Sep 2020	B2
10817873	Paolini-Subramanya	Oct 2020	B2
10826685	Campagna	Nov 2020	B1
10855446	Ow	Dec 2020	B2
10873457	Beaudoin	Dec 2020	B1
10915895	Fogg	Feb 2021	B1
10929842	Arvanaghi	Feb 2021	B1
10949926	Call	Mar 2021	B1
10956973	Chang	Mar 2021	B1
10958418	Ajoy	Mar 2021	B2
10997159	Iwama	May 2021	B2
11042871	Snow	Jun 2021	B2
11044095	Lynde	Jun 2021	B2
11044097	Snow	Jun 2021	B2
11044100	Deery	Jun 2021	B2
11063770	Peng	Jul 2021	B1
11075744	Tormasov	Jul 2021	B2
11093933	Peng	Aug 2021	B1
11134120	Snow	Sep 2021	B2
11164250	Snow	Nov 2021	B2
11164254	Gordon, III	Nov 2021	B1
11170366	Snow	Nov 2021	B2
11171782	Tang	Nov 2021	B2
11205172	Snow	Dec 2021	B2
11276056	Snow	Mar 2022	B2
11295296	Snow	Apr 2022	B2
11296889	Snow	Apr 2022	B2
11328290	Snow	May 2022	B2
11334874	Snow	May 2022	B2
11347769	Snow	May 2022	B2
11348097	Snow	May 2022	B2
11348098	Snow	May 2022	B2
11423398	Mullins	Aug 2022	B1
20010029482	Tealdi	Oct 2001	A1
20030018563	Kilgour et al.	Jan 2003	A1
20040085445	Park	May 2004	A1
20050206741	Raber	Sep 2005	A1
20060075228	Black et al.	Apr 2006	A1
20060184443	Erez et al.	Aug 2006	A1
20070027787	Tripp	Feb 2007	A1
20070094272	Yeh	Apr 2007	A1
20070174630	Shannon	Jul 2007	A1
20070296817	Ebrahimi et al.	Dec 2007	A1
20080010466	Hopper	Jan 2008	A1
20080028439	Shevade	Jan 2008	A1
20080059726	Rozas	Mar 2008	A1
20090025063	Thomas	Jan 2009	A1
20090287597	Bahar	Nov 2009	A1
20100049966	Kato	Feb 2010	A1
20100058476	Isoda	Mar 2010	A1
20100161459	Kass et al.	Jun 2010	A1
20100228798	Kodama	Sep 2010	A1
20100241537	Kass et al.	Sep 2010	A1
20110061092	Bailloeul	Mar 2011	A1
20110161674	Ming	Jun 2011	A1
20120203670	Piersol	Aug 2012	A1
20120264520	Marsland	Oct 2012	A1
20130142323	Chiarella	Jun 2013	A1
20130222587	Roskowski	Aug 2013	A1
20130275765	Lay	Oct 2013	A1
20130276058	Buldas	Oct 2013	A1
20140022973	Kopikare	Jan 2014	A1
20140201541	Paul	Jul 2014	A1
20140229738	Sato	Aug 2014	A1
20140282852	Vestevich	Sep 2014	A1
20140289802	Lee	Sep 2014	A1
20140297447	O'Brien	Oct 2014	A1
20140344015	Puertolas-Montasnes et al.	Nov 2014	A1
20150052615	Gault	Feb 2015	A1
20150193633	Chida	Jul 2015	A1
20150206106	Yago	Jul 2015	A1
20150242835	Vaughan	Aug 2015	A1
20150244729	Mao	Aug 2015	A1
20150309831	Powers	Oct 2015	A1
20150332256	Minor	Nov 2015	A1
20150363769	Ronca	Dec 2015	A1
20150378627	Kitazawa	Dec 2015	A1
20150379484	McCarthy	Dec 2015	A1
20160002923	Alobily	Jan 2016	A1
20160012240	Smith	Jan 2016	A1
20160021743	Pai	Jan 2016	A1
20160071096	Rosca	Mar 2016	A1
20160098578	Hincker	Apr 2016	A1
20160119134	Hakoda et al.	Apr 2016	A1
20160148198	Kelley	May 2016	A1
20160162897	Feeney	Jun 2016	A1
20160217436	Brama	Jul 2016	A1
20160239653	Loughlin-Mchugh	Aug 2016	A1
20160253663	Clark et al.	Sep 2016	A1
20160260091	Tobias	Sep 2016	A1
20160267472	Lingham et al.	Sep 2016	A1
20160267558	Bonnell et al.	Sep 2016	A1
20160275294	Irvine	Sep 2016	A1
20160283920	Fisher et al.	Sep 2016	A1
20160292396	Akerwall	Oct 2016	A1
20160292672	Fay et al.	Oct 2016	A1
20160292680	Wilson, Jr. et al.	Oct 2016	A1
20160294783	Piqueras Jover	Oct 2016	A1
20160300200	Brown et al.	Oct 2016	A1
20160300234	Moss-Pultz et al.	Oct 2016	A1
20160321675	McCoy et al.	Nov 2016	A1
20160321751	Creighton, IV et al.	Nov 2016	A1
20160321769	McCoy	Nov 2016	A1
20160328791	Parsells et al.	Nov 2016	A1
20160330031	Drego	Nov 2016	A1
20160330244	Denton	Nov 2016	A1
20160337119	Hosaka et al.	Nov 2016	A1
20160342977	Lam	Nov 2016	A1
20160342989	Davis	Nov 2016	A1
20160344737	Anton et al.	Nov 2016	A1
20160371771	Serrano	Dec 2016	A1
20170000613	Lerf	Jan 2017	A1
20170005797	Lanc et al.	Jan 2017	A1
20170005804	Zinder	Jan 2017	A1
20170033933	Haber	Feb 2017	A1
20170053249	Tunnell et al.	Feb 2017	A1
20170061396	Melika et al.	Mar 2017	A1
20170075938	Black	Mar 2017	A1
20170103167	Shah	Apr 2017	A1
20170124534	Savolainen	May 2017	A1
20170124535	Juels et al.	May 2017	A1
20170134162	Code	May 2017	A1
20170148016	Davis	May 2017	A1
20170161439	Raduchel	Jun 2017	A1
20170177898	Dillenberger	Jun 2017	A1
20170178237	Wong	Jun 2017	A1
20170213287	Bruno	Jul 2017	A1
20170221052	Sheng	Aug 2017	A1
20170228731	Sheng	Aug 2017	A1
20170236123	Ali	Aug 2017	A1
20170243208	Kurian et al.	Aug 2017	A1
20170243289	Rufo	Aug 2017	A1
20170244757	Castinado et al.	Aug 2017	A1
20170330279	Ponzone	Nov 2017	A1
20170344983	Muftic	Nov 2017	A1
20170346693	Dix	Nov 2017	A1
20170352031	Collin	Dec 2017	A1
20170353309	Gray	Dec 2017	A1
20170359374	Smith	Dec 2017	A1
20170364642	Bogdanowicz	Dec 2017	A1
20170373859	Shors et al.	Dec 2017	A1
20180005186	Hunn	Jan 2018	A1
20180048599	Arghandiwal	Feb 2018	A1
20180075239	Boutnaru	Mar 2018	A1
20180075527	Nagla et al.	Mar 2018	A1
20180082043	Witchey	Mar 2018	A1
20180088928	Smith	Mar 2018	A1
20180091524	Setty	Mar 2018	A1
20180097779	Karame et al.	Apr 2018	A1
20180101701	Barinov	Apr 2018	A1
20180101842	Ventura	Apr 2018	A1
20180108024	Greco	Apr 2018	A1
20180117446	Tran	May 2018	A1
20180123779	Zhang	May 2018	A1
20180139042	Binning	May 2018	A1
20180144292	Mattingly	May 2018	A1
20180157700	Roberts	Jun 2018	A1
20180158034	Hunt	Jun 2018	A1
20180167201	Naqvi	Jun 2018	A1
20180173906	Rodriguez	Jun 2018	A1
20180176017	Rodriguez	Jun 2018	A1
20180181768	Leporini	Jun 2018	A1
20180182042	Vinay	Jun 2018	A1
20180189333	Childress	Jul 2018	A1
20180189781	McCann	Jul 2018	A1
20180204213	Zappier	Jul 2018	A1
20180219683	Deery	Aug 2018	A1
20180219685	Deery	Aug 2018	A1
20180225640	Chapman	Aug 2018	A1
20180225649	Babar	Aug 2018	A1
20180241565	Paolini-Subramanya	Aug 2018	A1
20180260888	Paolini-Subramanya	Sep 2018	A1
20180260889	Paolini-Subramanya	Sep 2018	A1
20180268162	Dillenberger	Sep 2018	A1
20180268382	Wasserman	Sep 2018	A1
20180268504	Paolini-Subramanya	Sep 2018	A1
20180276270	Bisbee	Sep 2018	A1
20180276668	Li	Sep 2018	A1
20180276745	Paolini-Subramanya	Sep 2018	A1
20180285879	Gadnis	Oct 2018	A1
20180285970	Snow	Oct 2018	A1
20180285971	Rosenoer	Oct 2018	A1
20180288022	Madisetti	Oct 2018	A1
20180315051	Hurley	Nov 2018	A1
20180316502	Nadeau	Nov 2018	A1
20180341930	Moir	Nov 2018	A1
20180356236	Lawrenson	Dec 2018	A1
20180365201	Hunn	Dec 2018	A1
20180365686	Kondo	Dec 2018	A1
20180365764	Nelson	Dec 2018	A1
20180367298	Wright	Dec 2018	A1
20190012637	Gillen	Jan 2019	A1
20190013948	Mercuri	Jan 2019	A1
20190018947	Li	Jan 2019	A1
20190028273	Harras	Jan 2019	A1
20190034459	Qiu	Jan 2019	A1
20190036887	Miller	Jan 2019	A1
20190036957	Smith	Jan 2019	A1
20190043048	Wright	Feb 2019	A1
20190044727	Scott	Feb 2019	A1
20190050855	Martino	Feb 2019	A1
20190057382	Wright	Feb 2019	A1
20190065709	Salomon	Feb 2019	A1
20190073666	Ortiz	Mar 2019	A1
20190080284	Kim	Mar 2019	A1
20190081793	Martino	Mar 2019	A1
20190081796	Chow	Mar 2019	A1
20190087446	Sharma	Mar 2019	A1
20190123889	Schmidt-Karaca	Apr 2019	A1
20190132350	Smith	May 2019	A1
20190188699	Thibodeau	Jun 2019	A1
20190197532	Jayachandran	Jun 2019	A1
20190205563	Gonzales, Jr.	Jul 2019	A1
20190236286	Scriber	Aug 2019	A1
20190251199	Klianev	Aug 2019	A1
20190251557	Jin	Aug 2019	A1
20190253240	Treat	Aug 2019	A1
20190253258	Thekadath	Aug 2019	A1
20190268141	Pandurangan	Aug 2019	A1
20190268163	Nadeau	Aug 2019	A1
20190281259	Palazzolo	Sep 2019	A1
20190287107	Gaur	Sep 2019	A1
20190287199	Messerges	Sep 2019	A1
20190287200	Schuler	Sep 2019	A1
20190288832	Dang	Sep 2019	A1
20190296915	Lancashire	Sep 2019	A1
20190303623	Reddy	Oct 2019	A1
20190303887	Wright	Oct 2019	A1
20190306150	Letz	Oct 2019	A1
20190311357	Madisetti	Oct 2019	A1
20190324867	Tang	Oct 2019	A1
20190332691	Beadles	Oct 2019	A1
20190333054	Cona	Oct 2019	A1
20190334715	Gray	Oct 2019	A1
20190334912	Sloane	Oct 2019	A1
20190340586	Sheng	Nov 2019	A1
20190340607	Lynn	Nov 2019	A1
20190342422	Li	Nov 2019	A1
20190347444	Lowagie	Nov 2019	A1
20190347628	Al-Naji	Nov 2019	A1
20190349190	Smith	Nov 2019	A1
20190349426	Smith	Nov 2019	A1
20190354606	Snow	Nov 2019	A1
20190354607	Snow	Nov 2019	A1
20190354611	Snow	Nov 2019	A1
20190354724	Lowagie	Nov 2019	A1
20190354725	Lowagie	Nov 2019	A1
20190354964	Snow	Nov 2019	A1
20190356733	Snow	Nov 2019	A1
20190361917	Tran	Nov 2019	A1
20190372770	Xu	Dec 2019	A1
20190378128	Moore	Dec 2019	A1
20190385165	Castinado	Dec 2019	A1
20190386940	Hong	Dec 2019	A1
20190391540	Westervelt	Dec 2019	A1
20190391858	Studnicka	Dec 2019	A1
20190394044	Snow	Dec 2019	A1
20190394048	Deery	Dec 2019	A1
20200004263	Dalla Libera	Jan 2020	A1
20200004946	Gilpin	Jan 2020	A1
20200005270	Griffith	Jan 2020	A1
20200005290	Madisetti	Jan 2020	A1
20200019937	Edwards	Jan 2020	A1
20200034571	Fett	Jan 2020	A1
20200034813	Calinog	Jan 2020	A1
20200042635	Douglass	Feb 2020	A1
20200042960	Cook	Feb 2020	A1
20200042982	Snow	Feb 2020	A1
20200042983	Snow	Feb 2020	A1
20200042984	Snow	Feb 2020	A1
20200042985	Snow	Feb 2020	A1
20200042986	Snow	Feb 2020	A1
20200042987	Snow	Feb 2020	A1
20200042988	Snow	Feb 2020	A1
20200042990	Snow	Feb 2020	A1
20200042995	Snow	Feb 2020	A1
20200044827	Snow	Feb 2020	A1
20200044856	Lynde	Feb 2020	A1
20200044857	Snow	Feb 2020	A1
20200065761	Tatchell	Feb 2020	A1
20200067907	Avetisov	Feb 2020	A1
20200075056	Yang	Mar 2020	A1
20200089690	Qiu	Mar 2020	A1
20200099524	Schiatti	Mar 2020	A1
20200099534	Lowagie	Mar 2020	A1
20200104712	Katz	Apr 2020	A1
20200118068	Turetsky	Apr 2020	A1
20200127812	Schuler	Apr 2020	A1
20200134760	Messerges	Apr 2020	A1
20200145219	Sebastian	May 2020	A1
20200167870	Isaacson	May 2020	A1
20200175506	Snow	Jun 2020	A1
20200195441	Suen	Jun 2020	A1
20200211005	Bodorik	Jul 2020	A1
20200211011	Anderson	Jul 2020	A1
20200234386	Blackman	Jul 2020	A1
20200258061	Beadles	Aug 2020	A1
20200279324	Snow	Sep 2020	A1
20200279325	Snow	Sep 2020	A1
20200279326	Snow	Sep 2020	A1
20200280447	Snow	Sep 2020	A1
20200302433	Green	Sep 2020	A1
20200314648	Cao	Oct 2020	A1
20200320097	Snow	Oct 2020	A1
20200320514	Snow	Oct 2020	A1
20200320521	Snow	Oct 2020	A1
20200320522	Snow	Oct 2020	A1
20200320620	Snow	Oct 2020	A1
20200382480	Isaacson	Dec 2020	A1
20200389292	Bartolucci	Dec 2020	A1
20200389294	Soundararajan	Dec 2020	A1
20210035092	Pierce	Feb 2021	A1
20210042758	Durvasula	Feb 2021	A1
20210044976	Avetisov	Feb 2021	A1
20210073212	Conley	Mar 2021	A1
20210073750	Ledford	Mar 2021	A1
20210090076	Wright	Mar 2021	A1
20210097602	Eichel	Apr 2021	A1
20210119785	Ben-Reuven	Apr 2021	A1
20210144149	Simons	May 2021	A1
20210174353	Snow	Jun 2021	A1
20210200653	Jetzfellner	Jul 2021	A1
20210201321	Studnitzer	Jul 2021	A1
20210201328	Gunther	Jul 2021	A1
20210226769	Snow	Jul 2021	A1
20210226773	Snow	Jul 2021	A1
20210234665	Kramer	Jul 2021	A1
20210241282	Gu	Aug 2021	A1
20210248514	Cella	Aug 2021	A1
20210266167	Lohe	Aug 2021	A1
20210266174	Snow	Aug 2021	A1
20210272103	Snow	Sep 2021	A1
20210273807	Wertheim	Sep 2021	A1
20210273810	Lynde	Sep 2021	A1
20210273816	Deery et al.	Sep 2021	A1
20210297397	Bartolucci	Sep 2021	A1
20210326815	Brody	Oct 2021	A1
20210328804	Snow	Oct 2021	A1
20210342836	Cella	Nov 2021	A1
20210366586	Ryan	Nov 2021	A1
20220006641	Snow	Jan 2022	A1
20220012731	Derosa-Grund	Jan 2022	A1
20220019559	Snow	Jan 2022	A1
20220020001	Snow	Jan 2022	A1
20220023742	Tran	Jan 2022	A1
20220027893	Snow	Jan 2022	A1
20220027897	Snow	Jan 2022	A1
20220027994	Snow	Jan 2022	A1
20220027995	Snow	Jan 2022	A1
20220027996	Snow	Jan 2022	A1
20220029805	Snow	Jan 2022	A1
20220030054	Snow	Jan 2022	A1
20220034004	Snow	Feb 2022	A1
20220040557	Tran	Feb 2022	A1
20220043831	Douglass	Feb 2022	A1
20220058622	Snow	Feb 2022	A1
20220058623	Snow	Feb 2022	A1
20220083991	Kemper	Mar 2022	A1
20220103341	Snow	Mar 2022	A1
20220103343	Snow	Mar 2022	A1
20220103344	Snow	Mar 2022	A1
20220103364	Snow	Mar 2022	A1
20220141231	Simons	May 2022	A1
20220156737	Wright	May 2022	A1
20220172207	Cella	Jun 2022	A1
20220173893	Basu	Jun 2022	A1
20220198554	Filter	Jun 2022	A1
20220215389	Balaraman	Jul 2022	A1
20220245626	Sewell	Aug 2022	A1
20230185783	Haddad	Jun 2023	A1

Foreign Referenced Citations (25)

Number	Date	Country
107392618	Nov 2017	CN
110392052	Oct 2019	CN
110599147	Dec 2019	CN
112329041	Feb 2021	CN
10128728	Jan 2003	DE
3726438	Oct 2020	EP
3862947	Aug 2021	EP
5383297	Jan 2014	JP
2021152931	Sep 2021	JP
100653512	Dec 2006	KR
1747221	May 2017	KR
101747221	Jun 2017	KR
WO 0049797	Aug 2000	WO
WO 2007069176	Jun 2007	WO
WO 2015077378	May 2015	WO
2017190795	Nov 2017	WO
WO 2018013898	Jan 2018	WO
WO 2018109010	Jun 2018	WO
WO-2018116106	Jun 2018	WO
2018127923072018	Jul 2018	WO
WO 2018127923	Jul 2018	WO
WO-2018189667	Oct 2018	WO
WO 2019180702	Sep 2019	WO
WO 2019207504	Oct 2019	WO
2020125839	Jun 2020	WO

Non-Patent Literature Citations (39)

Entry
Davide Frey, Dietcoin: shortcutting the Bitcoin verification process for your smartphone, Mar. 2018, obtained from https://arxiv.org/pdf/1803.10494.pdf (Year: 2018).
Haarmann, et al., “DMN Decision Execution on the Ethereum Blockchain,” Hasso Plattner Institute, University of Potsdam, 15 pages.
Kim et al., “A Perspective on Blockchain Smart Contracts,” Schulich School of Business, York University, Toronto, Canada, 6 pages.
Watanabe, Hiroki, et al. “Blockchain contract: Securing a blockchain applied to smart contracts.” 2016 IEEE International Conference on Consumer Electronics (ICCE). IEEE, 2016.
“BlockChain Technology”, Berkeley Engineering.
Alsolami, Fahad, and Terrance E. Boult. “CloudStash: using secret-sharing scheme to secure data, not keys, in multi-clouds.” Information Technology: New Generations (ITNG), 2014 11th International Conference on. IEEE, 2014.
“Midex”, https://promo.midex.com/Midex_EN.pdf.
Xtrade White Paper, https://xtrade1-9649.kxcdn.com/wp-content/uploads/2017/09/xtrade-whitepaper.pdf.
Chakravorty, Antorweep, and Chunming Rong. “Ushare: user controlled social media based on blockchain.” Proceedings of the 11th International Conference on Ubiquitous Information Management and Communication. ACM, 2017.
Chen, Zhixong, and Yixuan Zhu. “Personal Archive Service System using Blockchain Technology: Case Study, Promising and Challenging.” AI & Mobile Services (AIMS), 2017 IEEE International Conference on. IEEE, 2017.
Unkown, “Federated Learning: Collaborative Machine Learning without Centralized Training Data” Apr. 6, 2017, 11 pages.
Casey, “BitBeat: Factom Touts Blockchain Tool for Keeping Record Keepers Honest”, Wall Street Journal, Nov. 5, 2014.
Crosby, Michael et al., “BlockChain Technology, Beyond Bitcoin”, Sutardja Center for Entrepreneurship & Technology, Berkeley Engineering, Oct. 16, 2015, 35 pages.
Al-Naji, Nader et al., “Basis: A Price-Stable Cryptocurrency with an Algorithmic Central Bank” www.basis.io Jun. 20, 2017, 27 pages.
Written Opinion in PCT/US2021/040207, Snow, dated Oct. 7, 2021.
Menezes, Alfred. J., et al. “Handbook of Applied Cryptography,” 1997, CRC Press, p. 527-28.
White, Ron, “How Computers Work,” Oct. 2003, QUE, Seventh Edition (Year: 2003), 23 pages.
Luu et al., Making Smart Contracts Smarter, 2016.
Feng and Luo, “Evaluating Memory-Hard Proof-of-Work Algorithms on Three Processors,” PVLDB, 13(6): 898-911, 2020.
Luther, “Do We Need a “Fedcoin” Cryptocurrency?,” ValueWalk, Newstex Global Business Blogs, Dec. 30, 2015 (Year: 2015).
Iddo Bentov, Bitcoin and Secure Computation with Money, May 2016 (Year: 2016).
United States: New Generation cryptocurrency, USDX Protocol, Offers Crypto Advantages and Fiat Pegging, Apr. 2, 2018 (Year: 2018).
Ana Reyna et al.; “On blockchain and its integration with IoT. Challenges and opportunities.” Future Generation Computer Systems. vol. 88, Nov. 2018, pp. 173-190. https://www.sciencedirect.com/science/article/pii/S0167739X17329205 (Year: 2018).
Krol, Michal et al., “SPOC: Secure Payments for Outsourced Computations” https://arxiv.org/pdf/1807.06462.pdf. (Year: 2018).
Dai et al., “TrialChain: A Blockchain-Based Platform to Validate Data Integrity in Large, Biomedical Research Studies,” arXiv:1807.03662, Jul. 10, 2018 (Year: 2018).
Eberhardt et al., “ZoKrates—Scalable Privacy-Preserving Off-Chain Computations,” https://ieeeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8726497. (Year:2018).
Fernandez-Carames et al.; A Review on the Use of Blockchain for the Internet of Things. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8370027 (Year: 2018). 23 pages.
Kroeger, T. et al., The Case for Distributed Data Archival Using Secret Splitting with Percival, 6th International Symposium on Resilient Control Systems (available at IEEE Xplore), p. 204-209 (Year: 2013).
Muhamed et al. EduCTX: A Blockchain-Based Higher Education Credit Platform, https://ieeexplore.ieee.org/stamp/ stamp.jsp?arnumber=8247166. (Year: 2017). 16 pages.
Sokolowski, R. (2011). Signed, sealed, delivered: EMortgages are protected from unauthorized alteration by something called a tamper seal. Mortgage Banking, 71(6), 108(4). Retrieved from https://dialog.proquest.com/professional/docview/1068158815? accountid=131444 (Year: 2011).
Why offchain storage is needed for blockchain_V4_1 Final (Year: 2018), by IBM, 13 pages.
ZoKrates—Scalable Privacy-Preserving Off-Chain Computations, by Jacob Eberhardt, Stefan Tai , 8 pages, Nov. 3, 2011 (Year: 2011).
Merkle Mountain Ranges (MMRs)-Grin Documentation, https://quentinlesceller.github.io/grin-docs/technical/building-blocks/merkle-mountain-ranges/, 5 pages, printed Jun. 1, 2022.
Merkle Mountain Ranges, https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md, 3 pages, printed Jun. 1, 2022.
Michelson, Kyle, et al., “Accumulate: An identity-based blockchain protocol with cross-chain support, human-readable addresses, and key management capabilities”, Accumulate Whitepaper, v1.0, Jun. 12, 2022, 28 pages.
MOF-BC: A Memory Optimized and Flexible BlockChain for Large Scale Networks. Ile:///C:/Users/eoussir/Documents/e-Red® 20Folder/16905961/NPL_MOF_BC_A%20Memory%20Optimized%20and%20Flexible%20Blockchain.pdf (Year:2018).
On blockchain and its integration with IoT. Challenges and opportunities. file:///C:/Users/eoussir/Downloads/1-s2.0S0167739X17329205-main%20(1). pdf (Year: 2018).
Office Action (Non-Final Rejection) dated Apr. 1, 2024 for U.S. Appl. No. 17/981,435 (pp. 1-22).
P. Sood, P. Palsania, S. Ahuja, S. Kumar, K. Khatter and A. Mishra, “Decentralised & Collaborative DocuPad Using Blockchain,” 2022 IEEE Delhi Section Conference (DELCON), New Delhi, India, 2022, pp. 1-8, doi: 10.1109/DELCON54057.2022.9752853. (Year: 2022).

Related Publications (1)

	Number	Date	Country
	20200042635 A1	Feb 2020	US

Provisional Applications (2)

	Number	Date	Country
	62714909	Aug 2018	US
	62714911	Aug 2018	US

Transactional sharding of blockchain transactions

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

CPC

International Classifications

Abstract