HK1254071B - Systems and methods of secure provenance for distributed transaction databases - Google Patents

Description

System and method for secure tracing of distributed transaction databases

Cross-reference(s) to related application(s)

This application claims the benefit of U.S. patent application No. 62/188,422, filed on July 2, 2015, and U.S. patent application No. 62/270,560, filed on December 21, 2015, the entire contents of each of which are incorporated herein by reference.

Technical Field

The technology herein relates to distributed transaction database computer systems. More specifically, the system herein relates to secure provenance in such systems.

Background Art

Digital provenance is a discipline in computer science that generally deals with the history of digital data stored on computer systems. Electronic data can be easily modified (for example, by simply changing a 1 to a 0), and there are no inherent mechanisms for providing provenance in such environments. In other words, once an electronic record (such as a medical record) is altered, the previous information is overwritten with no inherent ability to recover or interrogate the history of the data. Therefore, someone interested in proving the provenance of digital data can only see the most recent version of the data but may be unable to determine what created (or modified) the data, who or what is responsible for the data, or where and when such creation or modification occurred.

One approach to addressing these vulnerabilities when digital data is stored is to use log files, for example, that record changes to the digital data (e.g., a transaction log in a transaction database). However, traditional implementations offer no guarantee that the log files themselves have not been manipulated. This lack of trustworthy assurance can be problematic in certain situations, where the chain of provenance information can be as valuable as the information itself. Consider a log file containing a record of Alice accessing confidential information. This information could be valuable, but only if the log information being reviewed is not easily modifiable, making the chain of provenance easily alterable after the fact.

Another issue in digital provenance is ensuring the availability of provenance information. This is particularly important in the context of computer science applications and digital data, as it is relatively easy to erase digital information without leaving much (if any) trace of the data's original content (e.g., by deleting log files, etc.). Therefore, it will be appreciated that there is a need in technology to facilitate increased access to certain types of data, such as provenance information.

Another aspect of tracing back is that specific situations or applications may often require that tracing back information or the digital data associated with the tracing back information be confidential. As an example, it may be desirable to show changes to data records, etc., under authorized circumstances, but not to reveal which user authorized the changes. In another example, it may be desirable to hide the real owner (or past owner) of a specific data file. However, at the same time, the tracing back chain can still be used to verify the authenticity of a file or data field (for example, it has not been tampered with or the change is authorized). In other words, the tracing back chain can provide information detailing the tracing back to a third party and involves the exact identity of the past (or current) owner or user associated with the data. Therefore, it will be understood that it is technically necessary to allow an entity to verify the tracing back and/or custody chain without requiring that all past details of the information be available.

These and other problems persist in the disciplines of computer science and digital data storage.Therefore, there is a need in the art for further development of techniques for providing secure provenance—particularly in the context of digital data storage and/or distributed database computer systems.

Summary of the Invention

One or more of the above issues are addressed in certain example embodiments by an electronic resource tracking and storage computer system (computer system). The computer system is adapted or configured to communicate with a distributed blockchain computing system comprising a plurality of computing nodes and a blockchain. The computer system includes storage for blockchain participant identifiers, blockchain resource identifiers, and records corresponding to blockchain transactions. A transceiver is configured to receive an electronic data message (including a first electronic data message) comprising a digital resource issuance request requesting the issuance of a certain amount of a new resource. Upon receiving the new request, the computer system is programmed to generate a blockchain transaction from the blockchain resource identifier (e.g., a blockchain address) to at least one participant identifier (e.g., another blockchain address). The generated transaction also includes the amount of the new resource to be issued or transferred. The generated blockchain transaction is digitally signed using at least one private key associated with the blockchain resource identifier. The blockchain transaction is then sent to the blockchain for confirmation thereon. The computer system stores other information not part of the blockchain transaction in a database or the like. Once the blockchain transaction has been confirmed by the blockchain, the database is updated to reflect that the blockchain transaction is now part of the blockchain and is therefore (for practical purposes) immutable.

Therefore, the cryptographic immutability of records contained in the blockchain provides secure digital provenance for information contained in blockchain transactions. Other information (which may be confidential in nature, for example) is stored outside the blockchain, thus ensuring the security of information related to blockchain transactions on the blockchain. Third parties can verify (e.g., audit) transaction information by reviewing blockchain transactions. This can be accomplished without reviewing supplemental information not stored as part of the blockchain. The availability of records on the blockchain is also enhanced by the distributed nature of the distributed blockchain computing system. Therefore, the failure of a single node (or the corruption of records in a single location) will not result in the loss of digital provenance information.

In certain example embodiments, multiple different party identifiers are included as separate outputs to the generated blockchain transaction. Each identifier is associated with a different party. This allows multiple transactions (e.g., A->B and A->C) to be recorded in the same blockchain transaction.

In certain example embodiments, a first process (e.g., an auction process) is initiated during which participants submit data transaction requests to send or receive a resource quantity associated with a new digital resource identifier. The first process is closed to receive data transaction requests from participants. After the first process is closed, a single blockchain transaction is generated that includes an input corresponding to a source participant identifier and an output corresponding to a target participant identifier. The single blockchain transaction is published to a distributed blockchain computing system for confirmation. Thus, an auction process involving many different transactions can be represented on a blockchain as a single blockchain transaction.

In certain example embodiments, where the outputs for the single blockchain transaction also include source party identifiers of unused resource amounts, those source identifiers that transfer some but not all of their "held" resources will receive a remainder.

In certain example embodiments, the generated blockchain transaction includes a hash of the additional transaction data. Thus, provenance information stored outside the blockchain (e.g., in a separate database) can be represented on the blockchain without being included. This allows for secure digital provenance of the additional information, as the hash of that information becomes part of the immutable blockchain record.

In certain example embodiments, blockchain transactions (including issuance or allocation transactions) are digitally signed using two or more private keys. In certain example embodiments, one of the private keys is stored or maintained by the electronic resource tracking and storage computer system.

In certain example embodiments, a resource allocation request is received to allocate at least some amount associated with a previously generated blockchain transaction to another party identifier. A second blockchain transaction is generated using output data from the previously generated blockchain transaction as input. The output of the second blockchain transaction includes a numerical value for at least some amount to be allocated to the other party identifier. The generated second blockchain transaction is published to the blockchain, and the transaction repository of the electronic resource tracking and storage computer system is updated with a record of the second blockchain transaction. The record includes additional transaction data not included in the second generated blockchain transaction. Thus, the allocation of a resource (such as a private asset) is recorded on the blockchain. Furthermore, a secure chain of custody is ensured from the initial issuance to the further allocation, as auditors or other third parties will be able to verify the amount of the resource (asset) associated with the transaction originating from the initial issuance.

In certain example embodiments, the blockchain is maintained on a private computer system so that only those users or computers authorized to interact with the blockchain can perform blockchain functions (this includes electronic resource tracking and storage computer systems and blockchain nodes controlled by a single entity). In some instances, read-only access to the blockchain can be provided to third parties. This can advantageously allow third parties to directly access the secure digital provenance information stored as part of the blockchain.

Certain example embodiments also relate to a method for operating an electronic resource tracking and storage computer system as described above, and computer program instructions embodied on a non-transitory storage medium.

The features described herein can be combined to form additional embodiments, and sub-embodiments of certain embodiments can form yet further embodiments. This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. On the contrary, this summary is intended to provide an overview of the subject matter described in this document. Therefore, it will be understood that the features described above are merely examples, and other features, aspects, and advantages of the subject matter described herein will become clear from the following detailed description, drawings, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will be better and more fully understood by reference to the following detailed description of exemplary, non-limiting illustrative embodiments taken in conjunction with the accompanying drawings, in which:

FIG1 illustrates a non-limiting example functional block diagram of a digital asset knowledge base computer system interfaced with a blockchain, according to certain example embodiments;

FIG2A illustrates an example digital transaction conducted in a digital asset repository computer system for issuing an asset in digital form recorded on a blockchain, according to certain example embodiments;

FIG2B illustrates an example process for issuing digital-based assets on the system shown in FIG1 ;

FIG2C illustrates an example transaction conducted in connection with the issuance of a digital asset, according to certain example embodiments;

FIG3A illustrates an example process for transferring digital-based assets on the system shown in FIG1 ;

3B and 3C illustrate example transactions involving the transfer of digital assets between parties, according to certain example embodiments;

FIG4 illustrates an example process for registering a party that is subsequently permitted to interact with certain digital-based assets via the example system shown in FIG1 ;

FIG5 is a non-limiting example functional block diagram of a centralized computer system interfacing with a blockchain, according to certain example embodiments;

FIG6 is a signaling diagram of an example blockchain transaction executed between an issuer on a blockchain, a contract on a blockchain, and an investor on a blockchain;

7A-7H are example screenshots of user interfaces illustrating how blockchain transactions and their associated data may be displayed for user consumption, in accordance with certain example embodiments; and

FIG8 is an example computer system according to some example embodiments.

DETAILED DESCRIPTION

In the following description, specific details, such as specific nodes, functional entities, techniques, protocols, etc., are set forth for purposes of explanation rather than limitation in order to provide an understanding of the described technology. It will be apparent to those skilled in the art that other embodiments may be practiced without the specific details described below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc. are omitted so as not to obscure the description with unnecessary detail.

Subsections are used in this detailed description only to refer the reader to the general subject matter of each subsection; as will be seen below, the descriptions of many features are spread across multiple subsections, and the headings should not be read as affecting the meaning of the description included in any subsection.

Overview

In certain example embodiments, a computer system interfaces with a blockchain and provides secure provenance and chain of custody information for transactions stored thereon. The computer system stores additional information related to transactions added to the blockchain and also tracks whether blockchain transactions have been confirmed.

Blockchain technology (sometimes simply referred to as blockchain) is a relatively new database technology. Example implementations and the corresponding blockchain technology are described in Satoshi Nakamoto's 2008 article titled "A Peer-to-Peer Electronic Cash System," which is incorporated herein by reference in its entirety. A blockchain is a distributed database system (sometimes referred to as a public ledger) that records transactions between source and destination identifiers. These identifiers are created using cryptography, such as public-key cryptography. For example, a user can create a destination identifier based on a private key. The relationship between the private key and the destination identifier provides "proof" that the user is associated with the "output" from the corresponding "transaction." The decentralized nature of blockchain is also advantageous because no single node or system effectively holds the "correct" view of what is true. Instead, the decentralized system as a whole uses mathematical techniques to determine what is "correct."

In certain example embodiments, a computer system is configured to communicate with a distributed blockchain computing system comprising a plurality of computing nodes. In certain example embodiments, the computer system and the blockchain function as a private certificate repository. The computer system stores (1) identifiers and/or private key information for participants of the computer system; (2) digital asset identifiers used to represent assets on the blockchain; and (3) blockchain transaction records. When a new blockchain transaction is submitted to the distributed blockchain computing system, the computer system waits to determine whether the submitted new blockchain transaction has been confirmed. Once the new blockchain transaction has been confirmed, the computer system updates the record of the blockchain transaction stored by the computer system. The record stored by the computer system includes information that was not included or that is part of the blockchain transaction that was confirmed by the distributed blockchain computing system.

Figure 1 illustrates a non-limiting example functional block diagram of a digital asset repository computer system interfaced with a blockchain, according to certain example embodiments. Figures 2A-2C illustrate the issuance of digital assets using the system shown in Figure 1. Figures 3A-3C illustrate an example of how digital assets may be transferred using the system shown in Figure 1. Figure 4 illustrates an example process for registering a participant with the example computer system shown in Figure 1. Figure 5 is a non-limiting example functional block diagram of a computer system that may be used to implement the features of Figures 1-4 and 6-8. Figure 6 is a signaling diagram illustrating an example blockchain transaction executed between an issuer and an investor for a contract on a blockchain. Figures 7A-7H are example screenshots of a user interface used to visually illustrate the participant aspects of a computer system interfaced with a blockchain. Figure 8 illustrates an example computer system that may be used as a node as part of a blockchain or as a digital asset repository computer system.

Certain example embodiments provide a digital asset repository computer system for connecting buyers and sellers to trade privately issued assets. Privately issued assets can be assets of various security types. These can include, for example, private companies, private commercial enterprises, limited liability companies, partnerships, and their privately issued assets (such assets may include shares, stocks, membership units, membership interests, partnership interests, etc.), as well as equity or debt interests in other corporate entities that are not traded through public trading platforms or stock markets. In certain example embodiments, private companies, limited liability companies (LLCs), partnerships, and other commercial entities (collectively referred to as "private companies" in this disclosure) can participate in secondary sales of their privately issued assets, have at least partial control over how such privately issued assets are traded, have at least partial control over who can sell and/or buy such privately issued assets, set transaction-specific and/or user-specific restrictions, and so on.

Figure 1

FIG1 illustrates a non-limiting example functional block diagram of a computer-implemented digital asset repository computer system (also referred to herein as a digital asset repository computer system) 600 that interfaces with a blockchain 618, according to certain example embodiments. The digital asset repository computer system 600 may include a combination of software and hardware interfaces, programmed business logic, processing resources, and electronically addressable storage. The digital asset repository computer system 600 is responsible for tracking and executing computer programs for the purpose of maintaining an accurate digital ledger of asset ownership.

The digital asset knowledge base computer system 600 references or includes records or data of users, participants, digital assets, and blockchain transactions. Participants are identifiable entities (e.g., they are unique) that can be assigned ownership of digital assets that are also tracked by the system. For example, a company that issues one million shares can be a participant in the system. A user can be a uniquely identifiable entity with permission to view, update, and/or control information within the system. In some instances, users and participants can be the same or different. For example, in the case of a company, the company may have multiple authorized users who interact with the system on its behalf. In another example, an investor can be both a participant and a user in the system.

Digital assets (also referred to herein as resources) are also identifiable entities (e.g., they are unique) that can be tracked, managed, and verified by the computer system 600. For example, when a company first issues shares of Class A stock, the company's Class A stock will be an asset tracked by the system.

FIG7A shows an example screenshot of a user interface illustrating different resources that have been created for a company. The three different resources for the company are "Seed," "Series A," and "Series B." These are all unique resources tracked by computer system 600 and, as described in more detail below, are added as part of the generated and confirmed blockchain transactions.

Transactions for privately issued assets are digital transactions that have been submitted and/or confirmed by the corresponding blockchain (e.g., a public distributed digital ledger) 618.

Blockchain 618 is maintained, stored, and updated by a number of different computer nodes, each of which operates to "mine" and thereby validate transactions submitted to blockchain 618. Typically, only one of these nodes needs to "receive" a transaction submitted from a client (e.g., computer system 600). Once a node receives a transaction, it can propagate it to other nodes within the distributed computer system providing blockchain 618. In some examples, different entities may control the different computer nodes responsible for maintaining the blockchain. For example, the issuer of an asset may have one node, the auditor may have another, a regulator (e.g., the SEC) may have another, and the entity controlling computer system 600 may provide block producer nodes (e.g., dedicated to performing cryptographic computations for the blockchain).

In certain example embodiments, the blockchain may be a private blockchain implementation (e.g., where only authorized parties are allowed to read and/or write to the blockchain). In certain example embodiments, the blockchain 618 may include nodes for issuing assets (resources) and nodes for trading or moving assets/resources between participant identifiers on the blockchain 618.

Issuer nodes may each store one or more private keys and be responsible for creating new assets associated with a specific asset type. In some examples, each node has a private key used to create and/or digitally sign assets to be created by that node (e.g., the same key can be used to create or digitally sign multiple asset types). In other examples, each asset has its own unique private key. In some examples, there is one issuer node per asset type, and the issuer node on the blockchain can be a virtual machine (e.g., so that multiple virtual machines can execute on a single computer system).

Another type of node that is part of or interacts with blockchain 618 may be a manager or transaction node, which is used to move assets from one participant (e.g., an issuing company) to another (e.g., an investor). To allocate shares from, for example, a company to an investor, an allocation blockchain transaction is generated using input from the issuer's address (e.g., an identifier for the company that "holds" the shares). This type of transaction is generated by a manager or transaction node. The transaction is then digitally signed using a private key maintained by the manager node. In some examples, each manager node has a corresponding private key used to digitally sign such allocation transactions (e.g., between participants). Once a transaction is generated, submitted, and confirmed by the blockchain, the amount included with the transaction is effectively "held" by the identifier of the participant that received the transaction (e.g., as an unspent output).

Each transaction (or block of transactions) is added to or included in the blockchain 618 via a proof-of-work mining process. This mining process can involve solving a computationally difficult problem that is also easy to verify. For example, each node can attempt to "mine" a solution to the hash for a block or transaction. A hash (also referred to herein as a "hash function," "cryptographic hash function," etc.) comprises a function that maps an initial input data set to an output data set. The output from a hash function may be referred to herein as a "hash identifier," "hash value," "hashed data set," or simply "hash." Typically, the output values from a given hash function have the same fixed length. Generally, if the same hash function is used on the same input data, it will produce the same output data value. With some hash functions (including those used in the context of blockchain technology and/or the subject matter of this application), it is difficult to computationally determine the input value when only the output value is known. In some examples, the input value to the hash function is supplemented with some additional random data. For example, the input value to the "blockchain" of a hash function may include additional random data such as three random characters. Thus, the hashed data value might be “blockchaina5h” instead of simply “blockchain.” The additional random data is sometimes referred to as a “nonce.”

To validate a new block for inclusion in a blockchain, the proof-of-work process (or hashing process) performed can include finding an input hash value (i.e., a block) that results in an output hash value that satisfies a given condition. Because the data associated with blockchain transactions in a block is fixed, a miner (e.g., a node on the blockchain) modifies the nonce value included as part of the validated block until the output of the hash function satisfies a given condition. For example, the target output value can have five zeros as the first four digits of the hash. This is a computationally difficult problem to determine, but relatively easy to verify. Each node as part of the distributed computer system can also maintain a copy or portion of the blockchain 618 in storage local to the corresponding node (e.g., on disk or in RAM).

The blockchain 618 may thus provide secure data provenance, immutability, protection from double-spending issues, and distributed record keeping (e.g., many different entities may have nodes that are part of a distributed system maintaining the blockchain).

The digital asset repository computer system 600 includes a computer processor (processor) 608 that executes or runs a microservices application programming interface (API) 610 and a user interface 612 (e.g., it generates and provides web pages or other user interface elements that can be rendered into the screens of Figures 7A-7H, which can be shown on a user device such as 614A and 614B). Processor 608 also runs blockchain services 616. Blockchain services 616 may include functionality for both sending and receiving blockchain-related transactions and events. For example, transactions can be submitted to blockchain 618 for confirmation. In addition, confirmed transactions can be detected or received at the digital asset repository computer system 600 via blockchain services 616. It will be understood that processor 608 can be one or more processors. In some examples, processor 608 represents a distributed computing system.

Microservices API 610 is an application programming interface that allows external computing resources to access machine-readable data and interact with the digital asset repository computer system 600. Such interactions can be performed via web services or message-based protocols that allow administrators on computing devices 614B (e.g., mobile devices, PCs, tablets, etc.) to interact with the digital asset repository computer system 600. For example, the microservices API can provide data streams indicating when transactions have been submitted to the blockchain, when they have been confirmed, etc. In some examples, the microservices API 610 can be used to modify, add, or delete information about assets, transactions, users, or parties. In some example embodiments, the microservices API 610 can provide data used to render screenshots 7A-7H.

User interface 612 allows a user to view, update, and/or control a digital ledger via pre-programmed actions via user device 614A. The user can view the digital ledger (an example of which is shown in FIG. 7B , where the user is presented with a screen showing transactions for a given resource or asset) that represents the ownership record of assets defined in asset storage 614, and can interact with the data contained in the digital ledger through a set of pre-programmed actions. A fully auditable record of each interaction with the ledger can be created and stored for subsequent review. In some examples, user interface 612 can take the form of a webpage or a dedicated client application (e.g., as shown in the screenshots in conjunction with FIG. 7A-7H ).

The digital asset knowledge base computer system 600 includes at least three data repositories. These three repositories can be included as part of a single database (e.g., a relational database), can be separate databases, or can be stored using other technologies (e.g., flat files or other data structures). In some examples, the storage repositories of the digital asset knowledge base computer system 600 are located in memory and/or on separate logical or physical devices.

The participant storage 602 includes a record of all participants who can own or otherwise interact with resources defined within the system. The participant storage 602 may include public keys, private keys, and blockchain addresses or participant identifiers associated with each participant (e.g., derived using a one-way hash of the public key), which can be used to track blockchain transactions conducted by that participant. In some examples, one or more of these elements may be stored (e.g., the private key used to digitally sign transactions may be stored in an encrypted state). In some example embodiments, participants (e.g., computing systems controlled or maintained by those participants) can manage their corresponding private keys independently of the digital asset repository computer system 600. Therefore, when the digital asset repository computer system 600 interacts with the blockchain to create a blockchain transaction to be digitally signed by that participant, the computing system controlled by the participant can provide the private key and/or digitally sign the transaction and transmit the digitally signed transaction back to the digital asset repository computer system 600 for subsequent submission to the blockchain 618 for verification. In some examples, the participant storage 602 includes a digital wallet for each respective participant.

In some examples, each participant's private key is different. Alternatively, each participant's private key can be shared. For example, if a private blockchain is used as the blockchain, the entity controlling the blockchain can use the same private key for all participant identifiers. Thus, a blockchain transaction from A to B can be digitally signed using the same private key as a blockchain transaction from B to C.

A digital wallet is software and hardware (or specially designed hardware) that allows a party or user to generate and/or digitally sign blockchain transactions. A digital wallet may include a private key (e.g., known to the party or user with whom the digital wallet is associated) and a series of identifiers (sometimes referred to as digital wallet identifiers, wallet IDs, blockchain identifiers, etc.) generated based on the private key. These identifiers are used to allow other users to "send" blockchain transactions recorded on the blockchain to these identifiers. Software associated with the digital wallet (e.g., via blockchain service 616) can then query the blockchain to determine what unspent transactions (e.g., transaction outputs that have not been used as inputs in another transaction) are associated with the identifiers in the digital wallet. Such software can then present a comprehensive view of what the holder of the digital wallet "owns." For example, one hundred different transactions for one share of a company on the blockchain (each associated with a different identifier) can be identified and subsequently presented as 100 shares of the company. Thus, the identifiers stored in a party's storage device or corresponding digital wallet can be transparent to the user.

Asset storage 604 (sometimes also referred to as resource storage) includes records of all assets or resources tracked by the digital asset repository computer system 600. For example, each type of share issued by a company may be a separate resource record in asset storage 604. An asset or resource record may include a party identifier associated with the asset (e.g., for the corresponding company), a unique identifier used to uniquely identify the asset on the blockchain (e.g., such as a 160-bit hash value of the public key associated with the asset), a public key that can be used to generate the unique identifier, a private key that can be used to generate the public key (e.g., via elliptic curve cryptography), properties defining the asset type (e.g., asset type, share classification, specific issuance), the number of shares issued for that asset type, the time the asset was created, etc.

Ledger storage 606 interfaces with blockchain 618 in conjunction with blockchain service 616 to store records of confirmed (or pending) blockchain transactions. Records in ledger storage 606 may include source and destination identifiers of the corresponding participants mapped back (e.g., in the participant storage 602), blockchain transaction ID, unique identifier of the asset, asset transaction amount, transaction date (e.g., time the transaction was submitted to the blockchain), confirmation date (e.g., time the transaction was finally confirmed by the blockchain), price per share, and/or price of the asset transaction, etc.

2A illustrates an example digital transaction that occurs in a computer-implemented digital asset repository system when a resource or asset is first issued by system 600. In some examples, as a prerequisite to "issuing" new shares, if Company A has not already been created, it is created as a new company and added to participant storage 602 (see FIG4 ).

If this is the first time shares of a specific asset are being issued, a new asset type will be created corresponding to the transaction. This may include creating new private and public keys and a unique asset identifier for the newly created asset. Thus, for example, a new blockchain address and corresponding private and public keys may be created. This newly created data may be stored in the asset storage 604 along with the asset definition (e.g., share classification, outstanding quantity, etc.).

Figures 2A-2C

In certain example embodiments and as shown in FIG2A , creating a new asset may also involve an initial blockchain transaction in the form of an amount of cryptocurrency “for” the asset’s unique identifier. For example, a blockchain transaction may involve moving an amount of Bitcoin (or other cryptocurrency) from a digital wallet associated with the digital asset repository computer system 600 (e.g., a unique identifier for the digital wallet).

As shown in Figure 2A, after an asset and its corresponding data are created, a blockchain transaction 701 is subsequently generated to initialize and/or enable the issuance of new shares of "asset" 708. Blockchain transaction 701 thus "sends" a certain amount of cryptocurrency from a unique identifier associated with a private exchange 700 to the unique identifier created for asset 708. This transaction 701 includes the public key of private exchange 700 and is digitally signed by the private key of private exchange 701 (e.g., as a normal blockchain transaction). As a result of blockchain transaction 701, a certain amount of cryptocurrency (e.g., satoshis in the case of Bitcoin) is associated with the asset's unique identifier (e.g., as an unspent output). Using the private key associated with the asset, the asset can then "issue" a certain amount of the newly created asset as part of the blockchain transaction by having the cryptocurrency amount "bear" (e.g., as colored coins, etc.) the asset. In certain example embodiments, transaction 701 may be added to ledger storage 606. However, in other embodiments, it is not added to the ledger storage 606 because the transaction does not move assets from one entity or party (eg, a unique identifier associated with the entity) to another.

Once there is an unspent amount of cryptocurrency associated with asset 708, it is then possible to "issue" shares of that asset and have the issuance transaction verified by the blockchain (e.g., as if it originated from asset 708).

Thus, transaction 702 may be generated for 500 shares and represents the creation of shares, which are then distributed from Company A 703 to investors. Transaction 702 is a blockchain transaction from the unique identifier associated with the asset to the unique identifier associated with Company A 703. Transaction 702 also includes the public key of asset 708 and is digitally signed using the private keys of both asset 708 and proprietary trading platform 700. Transaction 702 may then be submitted to the blockchain, verified, and added to ledger storage 606.

Subsequent distributions to Participants 1 and 2 are made in the form of blockchain transactions 706A and 706B for unique identifiers (e.g., blockchain addresses) 705 and 707, respectively, associated with those parties. These transactions (which may be single one-to-many blockchain transactions) are digitally signed using Company A's private key and submitted to the blockchain and recorded in ledger storage 606.

Other example techniques may be used in conjunction with (or in place of) the issuance process described with respect to Figure 7A. For example, transactions 701 and 702 may be one transaction generated for identifier 703 associated with company A (e.g., it may be similar to a coinbase transaction in a conventional Bitcoin implementation).

The constructed issuance transaction can take an asset identifier as input and have as output the asset identifier, the asset amount, a party identifier (e.g., a blockchain address), and in some examples, a script address (e.g., specifying a hash of an unlocking script).

In some examples, each transaction can effectively be digitally signed with (or require the digital signatures of) multiple private keys. For example, one private key (or set of private keys) can be associated with the issuer and/or manager node discussed herein. Alternatively, a key can be controlled by an entity that controls or manages blockchain 618. Another key can be associated with, for example, an entity that controls computing system 600. And a third key can be held in escrow. Each transaction on the blockchain can be digitally signed by or require two of these three keys to ensure smooth transactions. Thus, if, for example, the key associated with computing system 600 is lost, the escrow key and the blockchain key can be used to still consume unspent blockchain transaction outputs.

Thus, T1, T2 (or T1T2 if these are one transaction), T3, and T4 can be digitally signed with and/or require two different private keys, each held by a different computer system and/or entity. This two-key requirement can help ensure that an agreement is reached when a transaction (such as a share allocation) should be generated and confirmed.

FIG7B illustrates an example user interface showing a transaction from Garak and Letta to Weyoun and Dukat. This can show a complete timeline of a given resource, asset, or equity being transferred between the listed parties. This allows auditors or other third parties to more easily understand the transactions that have occurred. As discussed herein, this can be particularly advantageous in areas more specifically dedicated to recording such transfers, such as private equity offerings.

Initially, Garak and Leeta both have 500k of a "seed" asset (e.g., a separate asset type for Series A or Series B). The resulting blockchain transaction uses Garak and Leeta's amounts as inputs and Weyoun, Dukat, Garak, and Leeta's amounts as outputs. This is a many-to-many blockchain transaction. Another one-to-many transaction is shown, from Michael Eddington to Damar, where Michael provides the inputs and the outputs are associated with both Michael (e.g., the balance) and Damar.

In certain example embodiments, many-to-many transactions can be used in conjunction with an auction process that can be executed by computer system 600. FIG7C shows an example view of an ongoing auction with three buyers and eleven sellers. Here, each individual's position or holding can be verified against the blockchain to ensure that both buyers and sellers have what they are putting up for auction. For buyers, this can take the form of verifying that the appropriate amount of money is available. This can be represented by a digital token issued by a third-party escrow or transfer agent that holds the money. Conversely, the position bid by the seller can be verified against the current blockchain transaction record (e.g., Odo actually owns enough to bid the listed amount).

At the end of the auction (e.g., when the auction is live), the transaction price for the auction is determined. The transactions executed as a result of the auction can be included in a single blockchain transaction (e.g., from 11 participants to 3 buyers). This many-to-many blockchain transaction can be visually presented to the user (e.g., on the corresponding user device), as shown in Figure 7D.

Figure 7D, for example, indicates that William Ross has completely zeroed out his initial position of $17.5k, as there is no balance associated with him after the transaction took effect. In contrast, Blackgem now has a position of $337.7k. The other parties have reduced their positions. Figure 7E shows another user interface screenshot that illustrates all parties involved in this many-to-many transaction. This shows the old position (on the left) and the new position (on the right). This type of user interface screen can allow users to track the chain of custody of assets as they move between different parties.

In certain example embodiments, a transaction (e.g., from Company A to another party) can be digitally signed by a private key that is centrally controlled and associated with computer system 600. In other words, an asset can be moved from an address associated with a company (or system, asset, or other party) to another address using a transaction digitally signed by a private/public key combination associated with computer system 600. Indeed, various types of encrypted access to assets can be employed in accordance with the embodiments described herein, including multi-signature embodiments in which both a party and system 600 (or a party and a company) digitally sign a transaction.

FIG. 2B illustrates an example process for issuing digital-based assets on the system shown in FIG. 1 , and FIG. 2C illustrates an example transaction that occurs in connection with issuing digital assets, according to certain example embodiments.

At S10, a user or system administrator with sufficient authority to act on behalf of a participant (e.g., Company A) provides user input to user device 614A or 614B indicating that a new asset should be issued for the participant. In response to the user input, user device 614A or 614B sends an electronic message to the digital asset repository computer system 600. The electronic message includes a digital resource issuance request to issue a new asset for the participant. The electronic message is received by the transceiver of the digital asset repository computer system 600 and passed to the user interface 612 or microservice interface 610 for processing.

At S12 and as part of the processing, the content of the electronic message is extracted and mapped to a command (or set of commands) corresponding to the request included in the message (e.g., a request to create and issue a new asset). The corresponding command(s) may then be automatically executed by the processor 608 of the digital asset repository computer system 600.

As part of executing the command, at S14, processor 608 identifies the party to be associated with the asset issuance transaction. For example, the private key, public key, and/or unique identifier for the party may be obtained and used to form the blockchain transaction to be subsequently created. In some examples, a new unique identifier and/or public key may be created for this particular transaction and associated with the party's blockchain digital wallet. This new information may be derived using the private key associated with the party. Thus, a party may be associated with multiple different public keys and/or unique identifiers (e.g., blockchain addresses).

At S16, processor 608 creates a new private key that will be used to sign any subsequent issuance of the asset. A public key based on the private key (e.g., its hash) may also be created. The public key may also be hashed to generate a unique identifier (e.g., a blockchain or Bitcoin address) that uniquely identifies the asset in the digital asset repository computer system 600 and on the blockchain 616. The newly created private and public keys, the unique identifier, and other associated information (e.g., the asset type, the number of shares to be issued, the issuance date, and/or other data that may vary based on the type of asset being issued) are stored in the asset storage device 604. The private key for the asset ensures that no other entity can copy an asset created by the digital asset repository computer system 600 and issue a blockchain transaction including the asset. In some examples, this guarantee is achieved because all issuances for a particular asset must originate from a blockchain address associated with the same asset (a unique identifier based on the asset's private key). The initial blockchain transaction includes the asset's public key and is signed by the asset's private key. Thus, a blockchain transaction is created from the unique identifier of the asset to another identifier (e.g., associated with a party). This cryptographic process ensures that only an entity or system (e.g., digital asset repository computer system 600) that controls the private key associated with the asset can issue additional amounts of the asset.

In some examples, a party may not wish to create a new asset, but may instead wish to expand upon an existing asset already defined within the digital asset repository computer system 600. For example, Company A 703 in Figure 2A initially issued 500 shares and now wishes to issue an additional 500 shares. Consequently, data indicating the asset (e.g., a unique identifier for asset 708) may be part of the initial electronic data message sent from user device 614A to the digital asset repository computer system 600. This information may then be used to retrieve the private key for the digital asset and thereby generate a new blockchain transaction (the new blockchain transaction includes the asset's public key and is signed with the asset's private key) that is "from" the unique identifier associated with the asset to the unique identifier associated with the party that issued the asset (e.g., the company). In response to the generation of the new blockchain transaction, the digital asset repository computer system 600 may update the corresponding asset record included in the asset store 604 (e.g., by incrementing or decrementing an amount). Alternatively, a new entry (e.g., a new database record) may be created indicating the details of this particular asset issuance.

In any case, at S18, a new blockchain transaction is created and submitted to the blockchain to record the issuance of new shares to the participant. In certain example embodiments, the shares are issued from the asset's unique identifier to the participant's unique identifier (e.g., its digital wallet). Alternatively, the blockchain transaction is from a unique identifier associated with the entity operating the digital asset repository computer system 600 (e.g., 700 in FIG. 2A ) to a unique identifier of the participant (e.g., 703 in FIG. 2A ).

More specifically, processor 608 can be programmed to create a blockchain transaction (such as the one shown in FIG7B ) consisting of multiple inputs and outputs. Typically, an input can be an unspent output associated with a public address (a unique identifier)—which can be a party identifier or an asset identifier. A transaction can be a combination of an unspent output and a new output directed to a new public address (e.g., the address to which the transaction is being “sent”). The transaction being sent is also “signed” using the private key associated with the address from which the input came (e.g., the party identifier to which the asset in question is associated on the blockchain).

Thus, in the case of an issuance transaction (e.g., transaction 702 in FIG. 2A ), the private key created with the asset is used to sign the transaction. In the case of a regular transaction (e.g., 706A and 706B in FIG. 2A ), a hash of the private key corresponding to the party from which the asset is being transferred is used to sign the blockchain transaction. In some examples, this process can be similar to the creation and submission of blockchain transactions to the blockchain described in FIG. 2 of U.S. Patent Application No. 62/270,560 . In some examples, the amount associated with the transaction is also included in the newly created blockchain transaction. In some examples, the blockchain transaction includes (e.g., as input) an assetID (e.g., a unique identifier for the asset) generated from the private key that uniquely identifies the asset. This assetID is then appended or added to the blockchain transaction.

Referring to FIG2C , a blockchain transaction can be created based on the information represented in fields 709 and 710. The created blockchain transaction is submitted to blockchain 618 via blockchain service 616 for confirmation by blockchain computing nodes that digitally "mine" the transaction. Once confirmed, the submitted transaction becomes part of the immutable record (distributed blockchain ledger) representing the creation of the asset.

In S20, corresponding to the creation and/or submission of the transaction to the blockchain, the output generated from the blockchain transaction is returned to or detected by the system 600, and the transaction is stored in the ledger storage 606. Such output may include a blockchain transaction ID. An example transaction ID is shown in the screenshot of Figure 7G.

The information stored in the ledger storage may include a blockchain transaction ID, references to the source and destination digital wallets (or unique identifiers), an asset identifier, and the amount of the asset associated with the transaction. Other data corresponding to the transaction may be added to the ledger storage 606 and linked to the created blockchain transaction. Such information may include information represented in field 712 shown in FIG2C . For example, whether the transaction has been confirmed on the blockchain, the block in the blockchain to which the confirmation is associated, the rule 144 date of the asset transaction, the price per share of the asset transaction, the investment value of the asset transaction, conditions associated with the asset transaction, and so on. It will be understood that these fields may vary depending on the type of asset being traded and the type of transaction (issue, transfer, reclassification, cancellation, etc.).

At S22, the digital asset knowledge base computer system 600 monitors the blockchain 618 via the processor 608 and the blockchain service 616 to determine when the submitted transaction has been confirmed by the blockchain. In response to determining that the submitted transaction has been confirmed, the ledger storage device 606 is updated to reflect that the transaction stored in S20 has been confirmed by the blockchain. The digital asset knowledge base computer system 600 can determine that the transaction has been confirmed by reviewing the confirmed blocks of the blockchain 618 as they are published.

Figure 2C illustrates that the issuance of shares to investors can be a two-step process, requiring two (or three) separate blockchain transactions. Here, the operator of system 600 (e.g., Nasdaq) issues new shares as described above and explicitly links this issuance to a transaction confirmed via the blockchain. The transaction submitted to the blockchain includes the asset's unique, public identifier and the asset amount. This information is represented by field 710 (e.g., "Company.A: General" can correspond to the unique identifier). As discussed above, this information, along with information 712, is stored in ledger storage 606.

After confirming transaction 702, Company A (a participant in system 600) can issue 300 shares to Participant 1 in the form of transaction 706A. This transaction will be based on the same unique assetID, but have a different amount associated with it.

In certain example embodiments, the digital asset knowledge base computer system 600 can independently verify that the amount of an asset transferred from one participant to another is valid (e.g., that the first participant actually "owns" the transferred asset). In other words, the blockchain can only verify that the underlying cryptocurrency amount used for blockchain transactions is valid, without confirming the asset transaction amount. For example, assume that transactions 706A and 706B are both for 300 shares. The blockchain can verify that both transactions are valid because the original asset issuance is from the asset identifier. However, the cryptographic process may not be able to determine that the sum of the amounts in the two transactions exceeds the initial allocation of 500 shares. Therefore, the digital asset knowledge base computer system 600 can perform independent accounting to verify that the amount traded for a given asset on the blockchain is a valid amount.

Figures 3A-3C

FIG3A illustrates an example process for transferring assets from one party identifier to another party identifier of the system 600 shown in FIG1 .

At S30, a user or system administrator with sufficient authority to act on behalf of a participant (e.g., Investor A) provides user input to user device 614A or 614B, indicating how many shares (or other amounts) to transfer and to whom the shares are to be transferred (e.g., another participant). In some examples, the user also provides a price associated with the transfer (e.g., price per share or total price). In response to the provided user input, user device 614A or 614B sends an electronic message to the digital asset repository computer system 600. The electronic message may include the target participant (e.g., the participant's unique identifier), the source participant (e.g., the source participant's unique identifier), the asset (e.g., the asset identifier), and the amount of the asset. The message is received by a transceiver (e.g., a network interface card) of the digital asset repository computer system 600 and passed to the user interface 610 or microservice interface 612 for processing. In some examples, the assets that the participant can transfer are presented to the user via a webpage or the like. For example, Figure 7F illustrates the number of shares associated with participant Leeta. In this illustration, 500k shares have been "canceled" because this amount is associated with a blockchain output that has already been spent (e.g., as shown in FIG7B ). A new, still valid, 466k share is associated with the blockchain transaction with the unspent output. The user can then select which assets to buy or sell. Based on this selection, an electronic message (e.g., an order) can be generated and submitted to the digital asset repository computer system 600.

For example, Leeta (or a user authorized to act on Leeta's behalf) may enter a user input requesting a transfer of 50,000 shares to Kira Nerys. In response to this input (and a corresponding electronic message sent to the computer system), the computer system will (e.g., automatically) use the blockchain transaction associated with 466,000 shares to conduct two further transactions (combined into one blockchain transaction). The input from the blockchain transaction will be 466,000 shares from Leeta and the output will be 416,000 shares to Leeta and 50,000 shares to Kira.

At S32 , an asset transfer request (eg, as described above) is received and mapped to a pre-programmed function (eg, a software program) executed by the processor 608 .

At S34, processor 608 identifies the parties involved in the transaction. As part of this process, processor 608 accesses party storage 622 to verify the parties and obtain unique identifiers, public keys, and/or private keys. This information will be used to later form and sign the blockchain transaction.

At S36 , the processor 608 extracts the asset that is the subject of the requested transaction from the electronic message submitted by the user device and verifies the asset by accessing the asset store 604 .

At S38 , the processor verifies that the source party to the transaction actually holds the appropriate amount of the asset to complete the transaction. This verification is accomplished by accessing the ledger storage 606 and determining that the source party is associated with an unspent output blockchain transaction linking to a sufficient amount of the asset in question. This process may include summing multiple different blockchain transactions associated with the source party to determine the total amount of the asset "owned" by the source party. In some examples, if the processor determines that the source party does not hold a sufficient amount, the transaction is aborted and the user who submitted the order is notified. In some examples, only confirmed transactions (e.g., those transactions greater than one block deep within the blockchain 618 ) are used to determine the total amount owned by the party. In other examples, unconfirmed transactions are also considered. In some examples, unconfirmed incoming transactions of the asset (e.g., where the party is the recipient) are not considered, but unconfirmed outgoing transfers (e.g., where the party is the sender) are considered. As part of the verification process, at S40 , the processor 608 may also query the blockchain via the blockchain service 616 to verify asset ownership.

After verification, at S42, the processor generates a blockchain transaction based on the private and public keys of the source party and any additional outputs required from the ledger storage 606, thereby forming a further blockchain transaction. In some examples, the blockchain transaction includes the data from fields 806 and 822 of Figures 3B and 3C. The created blockchain transaction is then submitted to the blockchain 618 for confirmation via the blockchain service 616.

At S44, corresponding to the submission of the newly created blockchain transaction to the blockchain, the ledger storage 606 is updated with information related to the submitted transaction. In addition to the data fields 806 and 822 that form part of the created blockchain transaction, this information may also include the data fields shown in 808 and 824.

At S46, the digital asset knowledge base computer system 600 monitors the blockchain 618 via the processor 608 and the blockchain service 616 to determine when the previously submitted transaction has been confirmed by the blockchain 618. In response to determining that the submitted transaction has been confirmed, the ledger storage device is updated to reflect that the stored transaction (from 44) is a confirmed blockchain transaction. The digital asset knowledge base computer system 600 can determine that the transaction has been confirmed by reviewing the confirmed blocks of the blockchain as they are published.

3B and 3C illustrate example transactions that occur with respect to transferring digital assets between parties, according to certain example embodiments.

Figure 3B illustrates an exemplary one-to-many transaction 810 between Party 1 and Parties 2, 3, and 4 (this may represent multiple blockchain transactions or a single blockchain transaction). In some instances, such a transaction is referred to as a distribution transaction. Party 1 is also included as an "output" because a new transaction occurs between Party 1 and Party 1 to reflect the reduction in the amount of Company A common stock "owned" by Party 1. Data field 806 represents information included on the blockchain, and data field 808 represents data stored in ledger storage 606 and linked to the blockchain transaction (although, according to some example embodiments, this information is not directly stored on the blockchain).

Figure 3C illustrates an example of a many-to-one transaction 826. This transaction can represent a share buyback exchange or a purchase of all equity interests in an asset by one party (Party 1) from other stakeholders (Party 2, 3, and 4). Data field 822 is a field that is current and part of the blockchain transaction, while data field 824 is a field that exists independently of the blockchain and is stored in ledger storage 606. Here, Parties 2, 3, and 4 have unspent blockchain transactions associated with 100, 50, and 50 shares of Company A's common stock. Each of these unspent blockchain transactions is used as input to form a transaction for Party 1, which includes 200 shares of Company A's common stock. This newly created transaction is then submitted to the blockchain for verification. In some examples, while the blockchain can verify that the unspent satoshis (or other units used in the blockchain) add up, there may be no blockchain verification that the asset amounts associated with the blockchain transactions add up. Therefore, the digital asset repository computer system 600 may include its own validation procedures to ensure that all inputs for the asset amounts are recorded as outputs of the transaction. Therefore, the digital asset knowledge base computer system 600 verifies that the 100, 50, and 50 shares of common stock are no longer associated with their corresponding participants and that the 200 shares are now associated with participant 1.

As will be appreciated, one-to-many, many-to-one, and many-to-many transfers can be advantageous when disposing of assets in the private equity space. For example, in a traditional system, distributing 20 shares to 100 different employees would require 100 different transactions. However, according to certain example embodiments discussed herein, this type of distribution can be accomplished using a single blockchain transaction with 100 (or 101, if the source has surplus assets) different outputs associated with a different unique identifier for each employee (e.g., which can be a participant in system 100). An example of a many-to-many blockchain transaction can be during an auction process, as shown in the example screens of Figures 7C-7E.

As with other examples, corresponding to submitting a new transaction to the blockchain, one or more new records are created in the ledger storage 606. In some examples, multiple records (e.g., rows in a database table, etc.) linked to the same blockchain transaction are created. In some examples, one blockchain transaction record linked to all three inputs and one output is created and added to the ledger storage 606.

It will be appreciated that other types of blockchain transactions can be created in conjunction with the example techniques described herein. For example, many-to-many transactions (e.g., 2 or more inputs and 2 or more outputs) can be used for transactions.

An example blockchain transaction for a distribution transaction may have inputs including the identifier of the asset subject to the distribution, the identifier of the party to whom some (or all) of the amount being distributed is being distributed, the amount "held" by the party identifier for that asset identifier, the transaction identifier (or its hash) of a previous transaction with unspent outputs, and so on. If the party making the distribution does not distribute all of its holdings, there will be two outputs: one for the recipient and the remainder for the identifier of the transferor. Each of these outputs will be associated with a different blockchain address (e.g., the remainder will be associated with the same party identifier as the source) and the amount of the asset being distributed.

Figure 4

FIG. 4 illustrates an example process for registering a party that is subsequently permitted to interact with certain digital-based assets via the example system shown in FIG. 1 .

At S90, a user or system administrator with sufficient authority (e.g., authority to create a new participant) provides input to a corresponding user device, which sends an electronic message via the user interface 612 or other API, requesting the digital asset knowledge base computer system 600 to create a new participant for the system.

At S92 , in response to receiving the message, the request included in the message is mapped to an appropriate command, which is included as part of the API and subsequently sent to the processor for execution.

At S94, according to the execution of the command by the processor, a new participant will be created in the system. In some example embodiments, a digital wallet or a digital wallet ID (e.g., a Bitcoin address) can be created and assigned to the newly created participant.

Other types of functionality may also be supported by the digital asset repository computer system 600. For example, shares issued to a participant may be withdrawn (e.g., by the issuing company) or destroyed by an operator of the digital asset repository computer system 600. In the event of a withdrawal, a new blockchain transaction may be created that transfers the withdrawn shares from the participant's digital wallet to the company's digital wallet. In the event of share destruction (e.g., due to the company's dissolution), an operator of the digital asset repository computer system 600 may create a blockchain transaction indicating that the shares have been destroyed. In some examples, the digital asset repository computer system 600 may delete an asset type from the asset storage device 604 (or mark it as deleted). This action effectively renders the data included as part of various blockchain transactions irrelevant or meaningless.

It will be understood that such action is possible because the digital asset repository computer system 600 controls the various private keys of each party associated with unspent outputs on the blockchain 618. Accordingly, the digital asset repository computer system 600 can issue a new transaction that moves such outputs to a blockchain address that will effectively remove the asset from the “market.”

In some examples, the digital asset repository computer system 600 may change the share classification associated with a transaction. In some examples, this may include updating the classification in the asset storage device or creating a new share classification. Based on this change, participants who previously owned the "old" type of classification may have their shares canceled (e.g., moved from their digital wallet to the company's digital wallet) and may also have new shares of the "new" classification issued simultaneously (from the company's digital wallet to the participant's digital wallet). In other examples, a new asset may be created as described above (e.g., using a new share classification) and two transactions may be formed. The first may cancel the old share classification, while the second may issue the new share classification. Information associated with such a blockchain transaction may then be recorded in the ledger storage device 606.

In some examples, asset transactions can be corrected by the digital asset repository computer system 600. In some instances, this can involve creating another blockchain transaction that effectively cancels a previously submitted blockchain transaction. In some examples, metadata stored in the ledger storage device can be updated independently of the blockchain transaction with which it is associated. For example, the SEC Rule 144 date can be a data field that exists only in the ledger storage device. Therefore, the Rule 144 date can be updated without reference to the corresponding blockchain transaction. Other fields in the ledger or asset storage device can be similarly updated. In some example embodiments, a hash of information not stored as part of the blockchain transaction can be incorporated into the blockchain transaction. For example, each additional field can be concatenated and then hashed. The resulting hash value can be added to the blockchain transaction. This additional verification can prevent changes to data fields that are not directly incorporated into the blockchain.

Figure 5

Figure 5 is a non-limiting example functional block diagram of a centralized computer system (e.g., centralized because one entity controls the computer and the operations programmed into it) that interfaces with a blockchain, according to certain example embodiments. In certain example embodiments, the centralized computer system 1000 electronically stores (e.g., in a database as part of an electronic storage system) an electronic version 1002 of a contract, such as a stock purchase agreement (SPA) or a stock transfer agreement (STA). In certain example embodiments, the digital asset repository computer system 600 comprises the centralized computer system 100. The created contract can specify pending share allocations, classifications of shares, certain types of investors (or specific investors) eligible to act under the contract (e.g., acquire shares), and so on. In certain examples, other electronic documents (e.g., defining voting rights, transfer agreements, etc.) are associated with and linked to the allocation contract.

An electronic document may have a required number of signatures or signature boxes that must be completed for the document to be considered valid. In the example shown in FIG5 , electronic contract 1002 requires four different signatures. As shown in FIG5 , computers associated with entities 1, 2, 3, and 4 communicate with centralized computer system 1000 (e.g., via electronic data messages) to provide electronic signatures that are applied to electronic contract 1002. In certain example embodiments, the signatures may be actual electronic signatures (e.g., actual electronic signatures may be considered as a contract, where an individual's consent to their signature is expressed via a computer, such as by clicking a button), photocopies of traditional signatures, or encrypted digital signatures.

In certain example embodiments, the created contract is hosted and stored, for example, by a centralized computer system 1000 and can be accessed and viewed by parties or entities that may be parties to the contract. Such access can be provided via a website or other technology that allows entities to remotely access, view, and interact with (e.g., sign) the contract in question. Such access can be provided via a desktop computer or a mobile computing device (e.g., a smartphone, tablet, laptop, etc.).

When the contract is signed by an entity (e.g., by one or more or all of entities 1-4), an electronic version of the document may be created (e.g., as a PDF) and stored along with the provided signatures. In certain example embodiments, in addition to applying the signatures to the electronically stored document, central computer system 1000 may add a verification mark or other symbol indicating that the contract (e.g., upon receipt of all required signatures) has been validated and/or verified by centralized computer system 1000 (or a legal entity controlling the computer system). In certain example embodiments, the verification may include a cryptographic signature (e.g., a digital signature) indicating that the entity has verified and/or authenticated the nature of the document (e.g., that it has been fully validated by the required parties).

In certain example embodiments, a funds transfer process can be initiated when a document or contract becomes effective (e.g., when all required signatories have in fact signed the document). The funds transfer process can be provided and initiated from the centralized computer system 100. In certain examples, the website displaying the contract information (e.g., through which the parties submit their signatures) also provides an interface for triggering the payment process. In certain example embodiments, the payment process becomes available (e.g., visible or triggerable) via the website only when it is determined (e.g., by the centralized computer system) that all required parties have signed the document 1002. For example, the contract may provide a certain number of shares to a given individual in exchange for a certain amount of money.

In certain example embodiments, the payment process may be facilitated by a third-party transfer agent that enables the transfer of money between two different entities. As described herein and unless otherwise specified, a transfer agent generally refers to a computer system that operates on behalf of the transfer agent. In other words, unless otherwise specified, a transfer agent is a computer system that is appropriately programmed (e.g., via an application programming interface or software service) to allow other computers to request the transfer of funds from one account to at least one other computer account.

In the example of FIG5 , entities 3 and 4 are two entities for which funds will be exchanged (e.g., entity 3 issues shares of private equity to be purchased by entity 4 for a certain amount). In this example, entities 3 and 4 may have previously established accounts with agent 1004 (e.g., similar to how a bank account may operate to indicate where money will be withdrawn and where it will be deposited).

In certain example embodiments, the entities may provide their account information to a centralized computer system 1000, which then interfaces with the transfer agent upon contract validation (e.g., via a web service or other application interface provided on the transfer agent), thereby triggering the payment process. The account information provided to the centralized computer system 1000 is transmitted to the transfer agent, which then executes the requested transaction. For example, the centralized computer system 1000 communicates with the transfer agent (e.g., via network 1001 and via a suitably programmed software service) to trigger a transfer of funds from the account of entity 4 associated with transfer agent 1004 to the account of entity 3 associated with the transfer agent. As a result of a successful funds transfer, transfer agent 1004 may generate a secure API token, which is passed back to the centralized computer system 1000. The token may represent a confirmation that the funds transfer was successful. In certain example embodiments, the token is a hash or one or more characteristics of the transfer that occurred.

Alternatively or additionally, and as explained in more detail below, the funds transfer process can occur entirely within the centralized computer system (and the blockchain 1006 to which it interfaces) without relying on or using a third party to transfer funds associated with the electronically stored contract.

Upon receiving a response (e.g., a token) from the transfer agent indicating that the funds transfer has been successfully initiated, the centralized computer system then triggers a process to create a permanent record on the blockchain for the electronically executed contract (e.g., which may be an allocation of private equity shares).

The permanent record is stored as a transaction on the blockchain. The created blockchain transaction may include the following information about the transaction between the issuer and investor entities: 1) the legal names and addresses of the issuer and investor (and potentially any other individuals who signed the electronic document), 2) the number of shares associated with the transaction, 3) the price per share (or the total price of the transaction), 4) the classification of the shares issued or transferred, 5) the effective date (e.g., when the electronic document was effective), 6) the date of the transaction, 7) a hash of all documents associated with the transaction (e.g., there may be more than one signed document per issuance), 8) the data or hash of each effective signature (e.g., the contract name, the signatory, a timestamp, and additional metadata associated with the electronic signature), and 9) data associated with the funds transfer (e.g., account information, a token associated with the transaction, a timestamp, a transaction ID used for the funds transfer process, etc.). This and other information may be included as part of the formed blockchain transaction, which is submitted to the blockchain for verification and incorporation.

It will be appreciated that the nature of the information included as part of the blockchain can be based on specific application requirements. For example, regulatory or contractual requirements may dictate the specification of certain data fields while excluding others. In some examples, the information included in the blockchain may include a token or unique identifier that acts as a reference to an internal database maintained by the centralized computer system 1000 (e.g., as described above in connection with Figures 1-4). Because information about transactions is part of a publicly accessible, distributed blockchain ledger, independent parties (e.g., auditors, administrative agents) can verify and review the nature of transactions that have occurred.

It will be appreciated that conventional processes for handling such contracts and their validation in the past can be error-prone and/or time-consuming. The computer systems and automated processes (e.g., software programs) described herein enable numerous separate processes to be handled separately as part of a dedicated process under the control of a single computer system (e.g., controlled by one entity). This single computer system provides more centralized and predictable control over the validation and recording of contracts (such as the allocation or transfer of private equity instruments). For example, a funds transfer between two parties may only be permitted if the contract has been signed by all required parties. This validation is programmatically enforced by the centralized computer system 1000 based on, for example, receipt of a provided security token and/or account information. This information, along with details of the validated contract, is included (either explicitly or via a reference token that references an internally provided database) in a blockchain transaction that is generated, submitted, and subsequently validated by the distributed system comprising the blockchain. In short, all the information required for a transaction (e.g., the allocation or issuance of private equity) can be included as part of the blockchain transaction. This aspect may be facilitated, at least in part, by a centralized computer system 1000 that is involved in every aspect of a transaction (eg, from contract creation, to validation, to fulfillment of contract terms, to recording and storage of the contract, etc.).

Storing all of this information in a repository (e.g., a blockchain) is advantageous because, for example, an auditor can reference this information without having to search for it in different locations (e.g., by visiting different law firms, companies, or individuals). In some examples, a subset of the information associated with a transaction can be stored on the blockchain, and a superset can be stored in a database on centralized computer system 1000. These two sets of information data can be linked together using a token or other key (e.g., a pointer) stored in the blockchain transaction, providing a reference back to the internally maintained database. In such instances, an auditor (or other individual) may still find this embodiment advantageous because the required data is contained on the blockchain and/or the central computing system.

In certain example embodiments, smart contracts can be (e.g., fully) integrated into a blockchain system. In this type of implementation, a "contract" can be associated with a blockchain address capable of receiving and storing assets. Assets (e.g., digital tokens, shares, digital currency) can be released or transferred upon meeting specific conditions defined in the contract. In other words, it is an autonomous, programmatic construct that can function like a third-party escrow agent.

Figure 6

Figure 6 is a signaling diagram of an exemplary (e.g., atomic) blockchain transaction executed between an issuer identifier on the blockchain, a contract address on the blockchain, and an investor address on the blockchain. Here, three distinct blockchain entities (e.g., distinct blockchain addresses as described herein) are used to validate a smart contract. Blockchain issuer 1102 may be associated with a company issuing private equity shares, etc. Blockchain investor 1106 may be a person interested in investing in the company. And, as discussed above, blockchain contract 1104 is an autonomous agent that holds shares issued by the company until certain defined, programmatic conditions are met.

In step 1110, the blockchain issuer creates a Share Transfer Agreement (STA) and, in step 1112, allocates shares to a blockchain address associated with a contract (i.e., blockchain contract 1104). The contract includes a programmatic script that must be satisfied in order for the shares assigned to blockchain contract address 1104 to be released (e.g., to an investor). The contract may include all the shares, prices, terms, and other details associated with owning the shares. An example contract is shown in Figure 7H. Once a share is assigned to blockchain contract 1104 (e.g., 1 in the scenario of Figure 1H), the share becomes available and cannot be removed without satisfying the programmatic terms of the STA. In some examples, there may be additional terms or options that allow blockchain issuer 1102 to cancel the contract (e.g., before blockchain investor 1106 takes effect). For example, a contract (e.g., an offer to purchase shares) may be automatically canceled after seven days.

It will be appreciated that the issuance of the contract in step 1112 is not merely a record of the nature of the contract, but rather an expression of legal intent regarding the submitted asset (e.g., the offered shares). In other words, if the conditions of the blockchain transaction are met, the asset is legally transferred when the blockchain transaction associated with the asset is effected. Therefore, blockchain contract address 1104 can function similarly to an escrow.

Once the contract and shares are associated with blockchain contract 1104, investors associated with the blockchain investor can review the terms of the contract in step 114 (e.g., via a webpage such as shown in FIG. 7H ). In some examples, for blockchain contract 1104, the terms of the contract (e.g., payment of digital or other currency to the address of blockchain issuer 1102) must be satisfied in order for the shares to be released to blockchain investor 1106. Here, the terms of the contract can be embodied in a programmatic script associated with the blockchain transaction that holds the purchased shares. Only when the terms of the script (or, more specifically, the terms set forth in the programmatic script) are satisfied will the shares be transferred to another blockchain address.

After reviewing the terms of the STA in step 1114, if the investor is still interested, he can create a blockchain transaction to accept the deal or allocation. For this process, the investor creates a blockchain transaction that includes the following inputs: (1) digital currency from the blockchain investor 1106 (this can also be a token of real money), and (2) the share of the contract from the blockchain contract 1104; and the following outputs: (1) currency going to the blockchain issuer 1102 in 1116 (this can also be a token of real money), and (2) the share going to the blockchain investor 1106 in 1118. This blockchain transaction (two inputs and two outputs) is a single atomic transaction 1115 that is submitted to the blockchain for verification thereby.

The transfer is confirmed (e.g., programmatically) against confirmation logic associated with the contract (e.g., a script associated with the transaction). In some examples, blockchain contract 1104 may require the transaction to be digitally co-signed to release the shares, and may only do so if appropriate conditions are met (e.g., if the amount of currency provided by the investor equals the value of the shares to be obtained). For example, the confirmation may include confirming the existence of a sufficient amount of digital currency to authorize the transfer of the requested number of shares. The nature of the confirmation of the blockchain transaction submitted by the investor is determined by programmatic logic that is part of the assigned contract. Essentially, the confirmation is "controlled" by the autonomous blockchain contract address (e.g., via scripted rules associated with the contract). In some examples, the confirmation can be performed by having a third-party custodian also digitally sign the transaction to indicate that the requested amount of funds has been deposited and is ready for transfer to the issuer.

The flexibility of this approach can mean that different types of information may be required to confirm or satisfy the terms of a contract (e.g., beyond simply sending sufficient funds). For example, a hashed value of an electronic contract can be created and submitted to a blockchain contract address. A portion of the scripted logic can be used to check whether the hashed value received from the investor matches the hashed value originally used from the issuer. In other words, the input from blockchain investor 1106 can include a hash of the contract document (e.g., to indicate that the investor has read and understood the contract terms), which is checked against the hash of the contract used by the issuer. Thus, different types of rules (e.g., logic) can be part of a "contract" to automatically enforce the contract.

At step 1120, the contract is marked as valid, and a certificate (eg, for the newly acquired shares) is created for the investor at step 1122. Example certificates and information associated therewith that may be displayed to the user are shown in Figures 7G and 7H.

The scheme described in Figure 6 can make all relevant information available on the blockchain by default, because both the blockchain contract address and the parties involved are entities on the blockchain network. Therefore, no steps occur outside the blockchain.

Figure 8

FIG8 is a block diagram of an exemplary computing system 800 according to certain example embodiments (e.g., a digital asset knowledge base computer system as described in FIG1-6 , a user device as shown in FIG1 , 2B, 3A, or 4 , a computing node as part of a distributed computing system for processing and maintaining a blockchain, one of multiple computing systems comprising a computer system such as the digital asset knowledge base computer system described herein, etc.). Computing system 1300 includes a processing system 1302 having CPUs 1, 2, 3, and 4, a system bus 1304 in communication with RAM 1306, and storage 1308. Storage 1308 can be magnetic, flash-based (e.g., for mobile client devices), solid-state, or other storage technologies. System bus 1304 communicates with a user input adapter 1310 (e.g., a PS/2, USB interface, etc.), which allows a user to enter commands into computing system 1300 via a user input device 1312 (e.g., a keyboard, mouse, touchpad, etc.). The processed results may be displayed to the user on a display 1316 (eg, LCD) via a display interface 1314 (eg, a video card, etc.).

Computing system 1300 may also include a network interface 1318 (e.g., a transceiver) to facilitate wired (e.g., Ethernet—802.3x) and/or wireless (WiFi/802.11x protocols, cellular technologies, etc.) communication with external systems 1322, databases 1320, and other systems via a network 1324. External systems 1322 may include other processing systems, systems providing third-party services, computing nodes such as miners for blockchains, and the like. External systems 1322 may be client devices or server systems.

External systems 1322 may also include network-attached storage (NAS) for storing large amounts of data. Together with internal storage and memory, these external systems may form a storage system for storing and maintaining information (e.g., blockchain information, asset information, order information, routing policies, etc.). Such a system may communicate with users and/or other computing systems that process electronic order data messages. Database 1320 may include a relational, object-oriented, or other type of database for storing information (e.g., supplemental data associated with blockchain transactions, digital assets or resources represented on the blockchain, order information for financial instruments).

In various embodiments, the computer system can be arranged in many different ways. As just one example, the computing system can be arranged such that the processor includes: a multi-core (or single-core) processor; a first network interface device (which, for example, implements WiFi, Bluetooth, NFC, etc.); a second network interface device that implements one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.); and a memory or storage device (e.g., RAM, flash memory, or a hard disk). The processor, the first network interface device, the second network interface device, and the memory device can be integrated as part of the same SOC (e.g., an integrated circuit chip or "system on a chip"). As another example, the computing system can be arranged such that: the processor includes two, three, four, five, or more multi-core processors; the network interface devices include a first network interface device that implements Ethernet and a second network interface device that implements WiFi and/or Bluetooth; and the memory device includes RAM and flash memory or a hard disk.

In other words, the processes, techniques, etc. described herein (for client devices, servers, switching platforms, and/or controller systems) can be implemented on a computing system. Such an implementation can then configure or program the processing system to implement aspects according to certain example embodiments. It will be understood that other architecture types can be used. For example, a single CPU can be used instead of multiple CPUs. Alternatively, the processing system can include multiple CPU "cores." In addition, the various elements shown in conjunction with Figure 8 can be included in a polymer physical structure (e.g., such as a tablet computer device). The components and functions shown in Figures 1-7H can be implemented on or in conjunction with the example computing system shown in Figure 8 (e.g., to create a special-purpose computing machine or a new use for an existing machine).

As described herein, when a software module or software process performs any action, the action is actually performed by the underlying hardware elements according to the instructions comprising the software module. In various embodiments, the computing system 600, user devices 614A and 614B, blockchain 618, centralized computer system 1000, blockchain 1006, storage devices 602, 604 and 606, blockchain service 616, user interface 612, microservice API 610, etc. (each of which is individually referred to as a "component" in the remainder of this paragraph for clarity) is implemented using the example of the computing system 1300 of Figure 8. In such implementations, the following applies to each component: (a) the elements of the computing system 1300 shown in FIG8 (i.e., one or more processors 1302, one or more memory devices 1306 or 1308, one or more network interface devices 1318, one or more display interfaces 1314, and one or more user input adapters 1310, or appropriate combinations or subsets thereof) are configured, adapted, and/or programmed to implement each or any combination of actions, activities, or features described herein as being performed by the component and/or by any software modules described herein as being included within the component; and (b) alternatively or in addition, to the extent one or more software modules described herein are present within the component, in some embodiments, such software modules (and any data described herein as being handled and/or used by the software modules) are stored in the memory devices 1306 and/or 1308 (e.g., in various embodiments, in a volatile memory device such as RAM, in an instruction register, and/or in a non-volatile memory device such as flash memory or a hard disk), and all actions described herein as being performed by the software modules are performed by the processor 1302, as appropriate, in conjunction with the computing device. (c) alternatively or in addition to, to the extent that components described herein process and/or otherwise handle data, in some embodiments, such data is stored in a memory device (e.g., in a volatile memory device such as RAM, and/or in a non-volatile memory device such as flash memory or a hard disk) and/or is processed by the processor 1302, as appropriate, in conjunction with the computer. (d) alternatively or in addition, in some embodiments, the memory device stores instructions that, when executed by the processor 1302, cause the processor 1302 to perform, as appropriate, in conjunction with other elements within and/or connected to the computing system 1300, each or any combination of the actions described herein as being performed by the component and/or by any software modules described herein as being included within the component.

Technical advantages of the described subject matter

In certain example embodiments, provenance and chain of custody information is provided via a blockchain, and blockchain transactions are individually associated with corresponding records stored in separate computer systems. Provenance and chain of custody information is secured using cryptographically verifiable operations that form the blockchain.

In certain example embodiments, a user interface (e.g., via a website, etc.) is provided that allows participants to view transactions associated with a particular asset or resource. This allows participants to visualize provenance and chain of custody information.

In certain example embodiments, a data transaction request may be submitted to a computer system. The data transaction request may be associated with the creation or issuance of an asset, the allocation of an asset to different parties, a request to conduct an electronic auction process, a request to execute a transaction, and/or a settlement with a third-party agent.

Selected terms

Whenever a given item is described herein as occurring in “some embodiments,” “various embodiments,” “certain embodiments,” “certain example embodiments,” “some example embodiments,” “exemplary embodiments,” or whenever any other similar language is used, it is understood that the given item occurs in at least one embodiment, but not necessarily in all embodiments. Consistent with the foregoing, whenever an action is described herein as “may,” “can,” or “can” be performed, a feature, element, or component “may,” “can,” or “can” be included in or applicable to a given context, a given item “may,” “can,” or “can” possess a given property, or whenever any similar phrases involving the terms “may,” “can,” or “can” are used, it is understood that the given action, feature, element, component, property, etc. occurs in at least one embodiment, but not necessarily in all embodiments. Unless expressly stated otherwise, the terms and phrases used herein, and their various variations, are to be understood as open-ended and non-restrictive. As an example of the foregoing: "and/or" includes any and all combinations of one or more of the associated listed items (e.g., a and/or b means a, b, or a and b); the singular forms "a," "an," and "the" should be interpreted as meaning "at least one," "one or more," etc.; the term "example" is used to provide an example of the subject matter being discussed, rather than an exhaustive or limiting listing thereof; the terms "include" and "comprising" (and their other verb conjugations and other variations) specify the presence of the associated listed items, but do not preclude the presence or addition of one or more other items; and if an item is described as "optional," such description should not be understood to indicate that the other items are also not optional.

As used herein, the term "non-transitory computer-readable storage medium" includes registers, cache memory, ROM, semiconductor memory devices (such as D-RAM, S-RAM or other RAM), magnetic media such as flash memory, hard disk, magneto-optical media, optical media such as CD-ROM, DVD or Blu-ray Disc, or other types of devices for non-transitory electronic data storage. The term "non-transitory computer-readable storage medium" does not include transient, propagating electromagnetic signals.

Additional Applications of the Described Subject Matter

Although process steps, algorithms, and the like, including but not limited to those with reference to Figures 1-6, may be described or claimed in a particular sequential order, such processes may be configured to operate in a different order. In other words, any order or sequence of steps that may be explicitly described or claimed herein does not necessarily indicate a requirement that the steps be performed in that order; rather, the steps of the processes described herein may be performed in any possible order. In addition, although described or implied as occurring non-simultaneously (e.g., because one step is described after another step), some steps may be performed simultaneously (or in parallel). Furthermore, the illustration of a process by its drawing in the accompanying drawings does not imply that the illustrated process excludes other variations and modifications thereto, that the illustrated process or any of its steps are necessary, or that the illustrated process is preferred.

For each embodiment described herein in which blockchain technology is used for a particular purpose or feature, it should be understood that blockchain technology is only one example of a technology that may be used for such purpose/feature; in various other embodiments, other types of distributed ledger technology, distributed database technology, and/or smart contract technology may be used in place of and/or in combination with blockchain technology for such purpose/feature.

Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above descriptions should be interpreted as implying that any particular element, step, range, or function is necessary. All structural or functional equivalents of the elements of the preferred embodiment described above that are known to those skilled in the art are expressly incorporated herein by reference and are intended to be included therein. Furthermore, it is not necessary for an apparatus or method to solve each and every problem sought to be solved by the present invention in order for the apparatus or method to be encompassed by the present invention. No embodiment, feature, component, or step in this specification is intended to serve the public.

Claims (20)

1. An electronic resource tracking and storage computer system, the electronic resource tracking and storage computer system being configured to communicate with a distributed blockchain computing system comprising multiple computing nodes, each computing node storing a copy of the blockchain of the distributed blockchain computing system, the distributed blockchain computing system being separate from the resource tracking and storage computer system, the electronic resource tracking and storage computer system comprising: Computer storage system, the computer storage system being configured to store: Multiple blockchain participant identifiers, each associated with at least one private key, wherein each of the multiple blockchain participant identifiers is associated with a corresponding one of multiple different participants; A resource knowledge base including multiple blockchain resource identifiers, wherein each of the multiple blockchain resource identifiers identifies a corresponding resource being tracked on the blockchain, and each of the multiple blockchain resource identifiers is associated with at least one resource private key; A transaction knowledge base including multiple blockchain transaction identifiers corresponding to blockchain transactions submitted to the distributed blockchain computing system; A transceiver configured to receive from a remote computing device electronic data messages, each including at least one data transaction request, wherein a first electronic data message in the electronic data messages includes a digital resource issuance request. A processing system, comprising at least one hardware processor coupled to the computer storage system and the transceiver, the processing system being configured to: The transceiver receives the digital resource issuance request to issue new resources for the first participant among the plurality of different participants; In response to receiving the digital resource issuance request, a new blockchain resource identifier is created and added to the resource knowledge base. The new blockchain resource identifier identifies the new resource and is associated with a corresponding private key. Generate a blockchain transaction for the first participant's blockchain participant identifier, the generated blockchain transaction including a new blockchain resource identifier and a value of a new resource identified by the new blockchain resource identifier; The generated blockchain transaction is signed using the private key associated with the new blockchain resource identifier; The generated blockchain transactions are published to the distributed blockchain computing system for confirmation. Corresponding to publishing the generated blockchain transactions to the distributed blockchain computing system, new transaction records are created and added to the transaction knowledge base. The new transaction records include at least some data included in the generated blockchain transactions and additional transaction data not included in the generated blockchain transactions. It is determined that the distributed blockchain computing system has confirmed the submitted blockchain transaction; and In response to the confirmation, the new transaction record is updated to indicate that the generated transaction has been confirmed by the distributed blockchain computing system. 2. The electronic resource tracking and storage computer system according to claim 1, wherein the blockchain participant identifier is a plurality of different blockchain participant identifiers, wherein the output for the generated transaction is associated with a corresponding blockchain participant identifier among the plurality of different blockchain participant identifiers. 3. The electronic resource tracking and storage computer system according to claim 1, wherein the processing system is further configured to: The first process begins, during which participants submit data transaction requests to send or receive a quantity of resources associated with a new blockchain resource identifier; The first process is closed to receive data transaction requests from the participants; Generate a single-blockchain transaction, the single-blockchain transaction including inputs corresponding to source blockchain participant identifiers and outputs corresponding to target blockchain participant identifiers; and The single-blockchain transaction is published to the distributed blockchain computing system for confirmation. 4. The electronic resource tracking and storage computer system of claim 3, wherein the output also includes source blockchain participant identifiers for the unused amount of the resource. 5. The electronic resource tracking and storage computer system of claim 1, wherein the generated blockchain transaction includes a hash value of additional transaction data. 6. The electronic resource tracking and storage computer system of claim 1, wherein the generated blockchain transactions are also signed with another private key. 7. The electronic resource tracking and storage computer system of claim 6, wherein the other private key is associated with the electronic resource tracking and storage computer system. 8. The electronic resource tracking and storage computer system according to claim 1, wherein the processing system is further configured to: Receive a resource allocation request, the resource allocation request identifying at least one second participant, the at least one second participant to be allocated as at least a portion of the value of the unused output of the generated blockchain transaction; and Generate a second blockchain transaction, the second blockchain transaction including data from the output of the generated blockchain transaction which is the input of the second blockchain transaction, and the portion of the said magnitude and a second blockchain participant identifier associated with the second participant as the output of the second blockchain transaction; The generated second blockchain transaction is published to the distributed blockchain computing system for confirmation. Corresponding to publishing the generated second blockchain transaction to the distributed blockchain computing system, a second transaction record is created and added to the transaction knowledge base. The second transaction record includes at least some data included in the generated second blockchain transaction and additional transaction data not included in the generated second blockchain transaction. 9. The electronic resource tracking and storage computer system according to claim 1, further comprising: The distributed blockchain computing system, wherein the blockchain is a private blockchain. 10. A method for electronic resource tracking using an electronic resource tracking and storage computer system, the electronic resource tracking and storage computer system being configured to communicate with a distributed blockchain computing system comprising multiple computing nodes, each computing node storing a copy of the blockchain of the distributed blockchain computing system, the distributed blockchain computing system being separate from the resource tracking and storage computer system, the electronic resource tracking and storage computer system storing: (a) a plurality of blockchain participant identifiers, each associated with at least one private key, each of the plurality of blockchain participant identifiers being associated with a corresponding one of a plurality of different participants; (b) a resource knowledge base comprising a plurality of blockchain resource identifiers, each of the plurality of blockchain resource identifiers being used for a corresponding resource tracked on the blockchain; and (c) a transaction knowledge base comprising a plurality of blockchain transaction identifiers corresponding to blockchain transactions submitted to the distributed blockchain computing system, the method comprising: Receive a resource issuance request to issue new resources for the first participant among the plurality of different participants; In response to receiving the resource issuance request, a new blockchain resource identifier is created and added to the resource knowledge base. The new blockchain resource identifier identifies the new resource and is associated with a corresponding private key. Generate a blockchain transaction for the first participant's blockchain participant identifier, the generated blockchain transaction including a new blockchain resource identifier and a value of a new resource identified by the new blockchain resource identifier; Blockchain transactions generated using a private key associated with the new blockchain resource identifier; The generated blockchain transactions are published to the distributed blockchain computing system for confirmation. Corresponding to publishing the generated blockchain transactions to the distributed blockchain computing system, new transaction records are created and added to the transaction knowledge base. The new transaction records include at least some data included in the generated blockchain transactions and additional transaction data not included in the generated blockchain transactions. It is determined that the distributed blockchain computing system has confirmed the submitted blockchain transaction; and In response to the confirmation, the new transaction record is updated to indicate that the generated transaction has been confirmed by the distributed blockchain computing system. 11. The method of claim 10, further comprising: The first process begins, during which participants submit data transaction requests to send or receive a quantity of resources associated with a new blockchain resource identifier; The first process is closed to receive data transaction requests from the participants; Generate a single-blockchain transaction, the single-blockchain transaction including an input corresponding to a source participant identifier and an output corresponding to a target participant identifier; and The single-blockchain transaction is published to the distributed blockchain computing system for confirmation. 12. The method of claim 10, wherein the generated blockchain transaction includes a hash value of additional transaction data. 13. The method of claim 10, wherein the generated blockchain transaction is also signed with another private key. 14. The method of claim 13, wherein the other private key is associated with the electronic resource tracking and storage computer system. 15. The method of claim 10, further comprising: Receive a resource allocation request, the resource allocation request identifying at least one second participant, the at least one second participant being allocated as at least a portion of the value of the unused output of the generated blockchain transaction; and Generate a second blockchain transaction, the second blockchain transaction including data from the output of the generated blockchain transaction which is the input of the second blockchain transaction, and the portion of the said magnitude and a second blockchain participant identifier associated with the second participant as the output of the second blockchain transaction; The generated second blockchain transaction is published to the distributed blockchain computing system for confirmation. Corresponding to publishing the generated second blockchain transaction to the distributed blockchain computing system, a second transaction record is created and added to the transaction knowledge base. The second transaction record includes at least some data included in the generated second blockchain transaction and additional transaction data not included in the generated second blockchain transaction. 16. A non-transient computer-readable storage medium having computer-readable instructions stored thereon for use by an electronic resource tracking and storage computer system, the electronic resource tracking and storage computer system comprising at least one processor, a memory, and a transceiver, the electronic resource tracking and storage computer system being configured to communicate with a distributed blockchain computing system comprising a plurality of computing nodes, each computing node storing a copy of a blockchain of the distributed blockchain computing system, the distributed blockchain computing system being separate from the resource tracking and storage computer system, the memory being configured to store: (a) a plurality of blockchain participant identifiers, each associated with at least one private key, each of the plurality of blockchain participant identifiers being associated with a corresponding one of a plurality of different participants; (b) a resource knowledge base comprising a plurality of blockchain resource identifiers, each of the plurality of blockchain resource identifiers being used for a corresponding resource tracked on the blockchain; and (c) a transaction knowledge base comprising a plurality of blockchain transaction identifiers corresponding to blockchain transactions submitted to the distributed blockchain computing system, the stored computer-readable instructions comprising instructions that, when executed by the at least one processor, cause the computer system to: Receive resource issuance request to issue new resources for the first participant among the plurality of different participants; In response to receiving the resource issuance request, a new blockchain resource identifier is created and added to the resource knowledge base. The new blockchain resource identifier identifies the new resource and is associated with a corresponding private key. Generate a blockchain transaction for the first participant's blockchain participant identifier, the generated blockchain transaction including a new blockchain resource identifier and a value of a new resource identified by the new blockchain resource identifier; The generated blockchain transaction is signed using the private key associated with the new blockchain resource identifier; The generated blockchain transactions are published to the distributed blockchain computing system for confirmation. Corresponding to publishing the generated blockchain transactions to the distributed blockchain computing system, new transaction records are created and added to the transaction knowledge base. The new transaction records include at least some data included in the generated blockchain transactions and additional transaction data not included in the generated blockchain transactions. It is determined that the distributed blockchain computing system has confirmed the submitted blockchain transaction; and In response to the confirmation, the new transaction record is updated to indicate that the generated transaction has been confirmed by the distributed blockchain computing system. 17. The non-transient computer-readable storage medium of claim 16, wherein the stored computer-readable instructions include additional instructions that, when executed by the at least one processor, cause the computer system to: The first process begins, during which participants submit data transaction requests to send or receive a quantity of resources associated with a new blockchain resource identifier; The first process is closed to receive data transaction requests from the participants; Generate a single-blockchain transaction, the single-blockchain transaction including an input corresponding to a source participant identifier and an output corresponding to a target participant identifier; and The single-blockchain transaction is published to the distributed blockchain computing system for confirmation. 18. The non-transient computer-readable storage medium of claim 16, wherein the generated blockchain transaction includes a hash value of additional transaction data. 19. The non-transient computer-readable storage medium of claim 16, wherein the generated blockchain transactions are also signed with another private key. 20. The non-transient computer-readable storage medium of claim 19, wherein the other private key is associated with the electronic resource tracking and storage computer system.