A unified platform for digital asset registration, tracking and authentication

Abstract

A blockchain-based lending or loan processing platform is provided. The platform comprises a blockchain onboarding system comprising a smart contract execution environment (CEE). The blockchain onboarding system is configured to (1) automatically process loan data from a loan origination system (LOS) for virtual execution of one or more loan agreements within the CEE, the loan data including a plurality of loan-related facts, (2) encrypt the loan-related facts to generate a plurality of encrypted facts associated with one or more loan assets, and (3) generate a plurality of hashes for the encrypted facts. The hashes are recorded on the blockchain, and a combination of each encrypted fact and its corresponding hash is deposited in an encrypted object store (EOS) separate from the blockchain. The platform also comprises a digital asset registration tool (DART) for tracking control, transfer, assignment, and / or ownership of controllable electronic records in substantially real time.

Description

[Technical field]

[0001] cross reference [1] This application claims priority to U.S. Provisional Application No. 63 / 323,665, filed March 25, 2022, which is incorporated by reference in its entirety. [Background technology]

[0002] [2] Blockchain systems are increasingly being used to record digital assets and / or transaction data across distributed computing devices. Blockchain advantageously enables secure distributed storage of event and transaction data that is verifiable and resistant to unauthorized use. However, existing systems of transactions for transacting with others via blockchain or otherwise may not provide sufficient information about one or more counterparties. Furthermore, current blockchain-based systems may not be suitable to support traditional financial services industries where private data integrity is required. For example, current platforms may not be suitable for enabling participating parties (e.g., financial institutions) to use private data on a public blockchain. Summary of the Invention

[0003] [3] There is a need for a platform and system that enables the use of off-chain client-side agreements in conjunction with on-chain data and contracts. The present disclosure relates to systems and methods for financial transactions based on blockchain technology. In particular, the disclosed platform and system may be used to keep sensitive data off the blockchain while still using the blockchain for data integrity (e.g., distributed, immutable, trustless).

[0004] [4] This disclosure provides a platform for authentication, tracking, and registration of digital assets. In some embodiments, the platform may be a blockchain-based lending or loan processing platform. The platform may include a blockchain onboarding system that enables loan originators to integrate their loan origination systems (LOS), management, and services into the blockchain. For example, digital assets may be onboarded to the blockchain by execution of a client-side contract written by the originator to consume origination data that is verified by the platform for its integrity, and the output data may include recorded facts in an encrypted object store (EOS) that is private to and hosted by the originator.

[0005] [5] The blockchain onboarding system may include a smart contract execution environment (CEE) that records documents, data, transactions, and hashed representations of client-side contracts on the blockchain. Data is modified or updated only by further contract execution against a unique predefined data structure (e.g., scope) while checking the input hash of the data from the object store against the blockchain to ensure no external data modifications have been made. In this manner, the truth of the data can be verified without having to trust the data stores of individual originators. The systems and methods disclosed herein advantageously provide portfolio-level credit, performance and related statistics, as well as the ability to drill into single loan packets, view exception reports, payment history, and the like. The blockchain onboarding system advantageously enables the use of off-chain client-side agreements in conjunction with on-chain data and contracts. In particular, the systems and methods herein may advantageously enable participating financial institutions to use private data on a public blockchain.

[0006] [6] In one aspect, a blockchain-based lending or loan processing platform is provided. The platform may include a blockchain onboarding system that includes a smart contract execution environment (CEE). The blockchain onboarding system is configured to (1) automatically process loan data from a loan origination system (LOS) for virtual execution of one or more loan contracts within the CEE, the loan data including a plurality of loan-related facts, (2) encrypt the loan-related facts to generate a plurality of encrypted facts associated with one or more loan assets, and (3) generate a plurality of hashes for the encrypted facts. The hashes are recorded on the blockchain, and a combination of each encrypted fact and its corresponding hash is deposited in an encrypted object store (EOS) that is separate from the blockchain.

[0007] [7] In some embodiments, each fact corresponds to a single or separate piece of data whose hash is to be recorded on the blockchain. In some embodiments, the CEE is configured to keep sensitive data regarding one or more loan assets off the blockchain while preserving the ability to use the blockchain to ensure data integrity. In some cases, hashes of cryptographic facts are recorded on the blockchain and cryptographic facts are not recorded on the blockchain. In some cases, EOS is local to or part of the CEE.

[0008] [8] In some embodiments, the plurality of loan-related facts include credit scores, borrower information or profile, electronic copies of signed security deeds, copies of electronic promissory notes (eNotes), third-party review (TPR) diligence results, and / or loan terms. In some embodiments, the loan data is originated by an origination party, and the platform is configured to enable the origination party to create a unique wallet having a root key pair with a public key and a private key. In some cases, the loan-related facts are encrypted using the origination party's public key. In some cases, a hash of the encrypted facts is recorded on the blockchain along with the origination party's public key and a timestamp. In some cases, the private key is usable by the origination party, or other parties authorized by the origination party, to decrypt the encrypted facts stored on EOS.

[0009] [9] In some embodiments, the blockchain includes a record of all transactions, including loan onboarding and loan asset transfer. In some embodiments, a set of loan-related facts collectively comprise a token. In some cases, the token comprises a non-fungible token (NFT). In some cases, each token is assigned a unique identifier. In some cases, the platform is configured to designate ownership at the token level. In some cases, the platform is configured to bifurcate ownership of the token between a data owner and a value owner. For example, the platform recognizes the value owner as an entity entitled to the monetary value of the loan asset that embodies the token(s) and allows the value owner to transfer rights in the value to other parties. For example, the platform recognizes the data owner as an entity that controls the facts embodied in the token. In some cases, the platform is configured to allow only the data owner to affect the facts in the token by adding one or more facts, modifying one or more facts, or deleting one or more facts. For example, the platform may be configured to allow data owners to freely share ownership so that there may be multiple data owners, each of which must individually approve any subsequent changes to the token data after the token is onboarded to the blockchain. In some cases, the platform may be configured to allow a data owner to allow read-only access to the token data for one or more other non-owner parties. For example, the platform may be configured to allow one or more other non-owner parties to decrypt the token and view / access the facts in the token while not allowing the non-owner parties to make any changes to the token data on the blockchain. In some cases, any attempted changes made by a non-owner party with only read-only access will not be accepted or authorized for recording on the blockchain.

[0010]

[10] In some cases, the platform recognizes the originating party as the entity that creates and onboards the token via the CEE, and the originating party is initially the data owner and value owner of the token by default. In some cases, the platform is configured to assign the originating party a unique public and private key pair. In some instances, the public key can be used by the originating party to create a digital signature on the token. For example, the platform allows the digital signature to be verified and authenticated by a private key that is connected to the public key and associated with the originating party. In some cases, the token is encrypted and the private key can be used to decrypt and view / access the facts in the token. In some cases, the public key is included with the token as well as any subsequent authorized modifications or changes to the token. In some cases, the authorized transfer of ownership of the token is tracked or traced by a unified Digital Asset Registry Tool (DART). In some cases, the platform is configured to allow subsequent authorized modifications or changes to the token to be made only by an entity whose digital signature matches that of the token's current data owner. In some cases, the platform is configured to reject modifications or changes proposed by any entity whose digital signature does not match that of the token's current data owner.

[0011]

[11] In some embodiments, the platform further comprises a Digital Asset Registry Tool (DART) connected to the platform. DART is an integrated registry configured to track the management, transfer, assignment and / or ownership of controllable electronic records, such as promissory notes (eNotes) associated with loan agreements, in substantially real-time. In some cases, DART is designed to eliminate the need for paper assignments, sales slips or other documentation of assignment of security agreements, or physical document delivery. In some cases, DART is designed to eliminate the need for manual registration of eNotes and loans with any additional intermediary system. In some cases, DART is configured to enable intra-party blockchain-based transfer of fully digital tokenized mortgage assets from transferor to transferee, as well as authentication that full super-priority control has been granted to the transferee. In some cases, EOS is configured to share cryptographic facts and metadata with the loan market module, and loan transactions conducted via the loan market module are recorded in substantially real-time using DART.

[0012]

[12] Further aspects and advantages of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, in which merely illustrative embodiments of the present disclosure are shown and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

[0013] INCORPORATION BY REFERENCE

[13] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference.

[0014]

[14] The novel features of the present disclosure are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present disclosure can be obtained by reference to the following detailed description that sets forth illustrative embodiments and the accompanying drawings (also referred to herein as "Figure" and "FIG."). [Brief description of the drawings]

[0015] [Figure 1]

[15] FIG. 1 illustrates an example of a blockchain-based lending or loan processing platform according to some embodiments of the present disclosure. [Diagram 2]

[16] An example of a scope proposed / generated by the Contract Execution Environment (CEE) and processed and recorded on the blockchain. [Diagram 3]

[17] FIG. 1 illustrates a schematic diagram of a Contract Execution Environment (CEE) according to an embodiment of the present disclosure. [Figure 4]

[18] Schematic of a loan onboarding architecture for onboarding loan assets onto the blockchain. [Diagram 5]

[19] Schematically illustrates an application architecture of a platform according to an embodiment of the present disclosure. [Figure 6]

[20] An example of a platform including a Digital Asset Registration Tool (DART) according to an embodiment of the present disclosure is shown. [Figure 7]

[21] An example of a user interface (UI) provided by the portfolio manager is shown. [Figure 8A]

[22] FIG. 1 illustrates a schematic diagram of a platform with blockchain-based loan authorization and integrated eNote registration according to an embodiment of the present disclosure. [Figure 8B]

[23] FIG. 1 illustrates a schematic diagram of a data sharing mechanism within a platform according to an embodiment of the present disclosure. [Figure 9]

[24] FIG. 1 illustrates generally an exemplary computer system programmed or configured to implement one or more of the methods provided herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016]

[25] While various embodiments have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may be made by those skilled in the art without departing from the scope of the present disclosure. It is to be understood that various alternatives to the embodiments described herein may be used.

[0017]

[26] This disclosure provides a platform for authentication, tracking, and registration of digital assets. In some cases, assets or items, such as financial assets (e.g., loans), titles, artwork, etc., can be represented on the blockchain as digital assets, such as on-chain assets or non-fungible tokens (NFTs), and blockchain records indicate ownership of such separate digital assets.

[0018]

[27] In some embodiments, the platform may be a blockchain-based lending or loan processing platform for financial assets. The platform may include a blockchain onboarding system that enables loan originators to integrate their loan origination systems (LOS), management, and services in or on a blockchain. For example, digital assets may be onboarded to the blockchain by execution of a client-side contract written by the originator to consume origination data, which is verified by the platform for its integrity, and the output data may include recorded facts in an encrypted object store (EOS) private to and hosted by the originator.

[0019]

[28] The blockchain onboarding system may include a smart contract execution environment (CEE) that records documents, data, transactions, and hashed representations of client-side contracts on the blockchain. Data changes or updates are made only through further contract execution on the data object (e.g., scope), and the input hash of the data from the object store is checked against the blockchain to ensure that no external data changes have been made. In this manner, the truth of the data can be verified without having to trust the data stores of individual originators. The systems and methods provided advantageously provide portfolio-level credit, performance and related statistics, as well as the ability to drill into single loan packets, view exception reports, payment history, and the like. The blockchain onboarding system advantageously enables the use of off-chain client-side agreements in conjunction with on-chain data and contracts. In particular, the systems and methods herein may advantageously enable participating financial institutions to use private data on a public blockchain.

[0020]

[29] Users of the platform may include clients, businesses, organizations, investors, staked token holders, delegators, developers, researchers, maintainers, and various other participants. Participants may include individuals or entities that transact on the blockchain to register, manage, and trade assets. In some cases, participants may pay transaction fees when executing transactions on the blockchain. In some cases, a client contract execution environment (CEE) can help facilitate private communications and processes between participants that are hashed before being included in the immutable record held by the validators.

[0021]

[30] Participants may include validators and delegators, which can be buy-side, sell-side, other financial services firms, or third-party validators that independently host the blockchain. In some cases, any participant can be a validator or delegator. Participants who hold hashes (a hash utility token used to pay for transactions (gas fees), staking, and permissioning) can additionally participate by delegating their stake to a validator to receive rewards. In some cases, any participant may buy or sell hashes directly by visiting any participating hash exchange.

[0022]

[31] A validator may be an authenticating node on a blockchain network. Validators may propose and authenticate transactions on the blockchain network. In some cases, validators may stake hashes to be part of the active validators on the network (e.g., the top 50 validator nodes in the network by total stake are selected as the active validator set), a building block for hash holders who want to delegate and share their stake in rewards generated by the network's fee distribution framework. Blockchains can provide benefits that incentivize authentication. For example, validators may participate in the security and control of the network and may be able to earn additional staking rewards through fees charged as well as bonuses for proposing transactions that are accepted by the network. In some cases, active validators may each be given a turn to propose blocks to be committed using a round-robin allocation. Validators may choose a minimum gas price they are willing to accept to process proposed transactions that allows validators to organically modify their costs to use the network.

[0023]

[32] As used herein, the term "stake" may generally refer to hashes delegated to a validator to share the risks and rewards of participating in the consensus mechanism on a blockchain network. As used herein, the term "delegation" may generally refer to staking hashes with a validator to be used as voting power by that validator. For most holders of hash delegations, it is an easy and relatively secure way to share ownership and rewards of the network.

[0024]

[33] Participants may include asset creators or originators (e.g., loan originators) that put digital assets on the blockchain. Asset creators can use a client-side contract or loan origination system to register and manage digital assets on the blockchain. In some cases, the blockchain client-side contract can take cryptographic data from the asset creator, convert that information into a predefined object structure, and then encrypt the data in the creator's own private encrypted object store (e.g., EOS) with an object hash recorded on the blockchain via a loan scope data module (e.g., loan scope or fact hash), as described later in this specification. In addition to onboarding digital assets, asset creators can fund, finance, sell, and service assets on the blockchain.

[0025]

[34] Participants may include entities that purchase or procure assets on the blockchain (e.g., banks, funds, etc.), entities that securitize assets, investors that purchase bonds, and a variety of other entities, such as omnibus banks that provide a bridge between the licensees and the blockchain.

[0026]

[35] Blockchain Onboarding System

[36] In one aspect, a blockchain-based lending or loan processing platform is provided. The platform may include a blockchain loan onboarding system that includes a smart contract execution environment (CEE). The blockchain onboarding system is configured to (1) automatically process loan data from a loan origination system (LOS) for virtual execution of one or more loan contracts within the CEE, the loan data including a plurality of loan-related facts, (2) encrypt the loan-related facts to generate a plurality of encrypted facts associated with one or more loan assets, and (3) generate a plurality of hashes for the encrypted facts. The hashes are recorded on the blockchain, and a combination of each encrypted fact and its corresponding hash is deposited in an encrypted object store (EOS) that is separate from the blockchain.

[0027]

[37] FIG. 1 illustrates an example of a blockchain-based lending or loan processing platform 100 according to some embodiments of the present disclosure. The platform 100 may include a blockchain onboarding system 120 that allows loan originators to integrate loan origination systems (LOS) 110, management, and services to or with the blockchain 140. In some embodiments, digital assets may be onboarded to the blockchain 140 by execution of a client-side contract in which the originator writes to consume origination data, verify its integrity, and output the data to an encrypted object store (EOS) 130 as recorded facts 125 or as a combination of encrypted facts 125 and fact hashes 123. In some embodiments, the EOS 130 may be private to the loan originator and hosted by the loan originator, thereby enabling increased privacy. The asset's data may include sensitive and / or personal information. Sensitive and / or personal information may be stored off-chain on EOS. On-chain scope metadata may include ownership information of the digital assets, which may be pooled or tokenized using a marker module as described later in this specification.

[0028]

[38] Client-side contracts may differ from blockchain-based smart contracts. Client-side contract execution environments execute only in the contract execution environments of the parties participating in the contract and may operate only with data stored in EOS. Records of contract execution are stored on the blockchain using a blockchain data model (e.g., a scope data model), which records scope data objects for chaining using blockchain-based smart contracts.

[0029]

[39] Client-side contracts may differ from smart contracts in that they keep data private between off-chain parties and allow the structure to record agreed-upon state data on the blockchain. In comparison, smart contracts may run on the blockchain and require validators to access data, which can be problematic for consumer-based transactions due to data privacy concerns.

[0030]

[40] The blockchain onboarding system described herein may be utilized to register new assets on the blockchain as on-chain digital assets. Digital assets may be represented using metadata modules and scope data structures, as described later herein. The metadata modules may be utilized to protect off-chain data privacy (e.g., personally identifiable information (PII)) while allowing the outcome of the asset data state (represented by a data hash) to be recorded on the blockchain. The blockchain onboarding system may be configured to automatically perform operations, thereby simplifying the process of registering new assets on the blockchain (e.g., minting).

[0031]

[41] In some embodiments, the blockchain onboarding system 120 can include a contract execution environment (CEE) 121 that records fact hashes (e.g., hashed representations of all documents, data, transactions, and client-side agreements) 123 on the blockchain 140. The blockchain onboarding system 120 can be configured to (1) automatically process loan data 111 from a loan origination system (LOS) 110 for virtual execution of one or more loan agreements in the CEE 121, the loan data 111 including a plurality of loan-related facts, (2) encrypt the loan-related facts to generate a plurality of encrypted facts 125 related to one or more loan assets, and (3) generate a plurality of hashes 123 for the encrypted facts, the hashes 123 being recorded on the blockchain. The combination of each encrypted fact 125 and its corresponding hash 123 can be deposited in an encrypted object store (EOS) 130 that is separate from the blockchain 140.

[0032]

[42] In some embodiments, the digital assets may include digital loan assets. Loan data 111 may be associated with one or more loan assets. The loan data may include a number of loan-related facts, including, for example, a credit score, borrower information or profile, an electronic copy of a signed security deed, a copy of an electronic promissory note (eNote), a Third Party Review (TPR) diligence results, the terms of the loan, and / or various other transactions (e.g., a particular monthly payment), details (e.g., an applicant's credit score), documents or information related to the loan.

[0033]

[43] In some embodiments, the blockchain onboarding system 120 may process loan data 111 for virtual execution of one or more loan agreements within the CEE 121 and encrypt loan-related facts to generate multiple encrypted facts 125 related to one or more loan assets.

[0034]

[44] In some embodiments, the CEE 121 can convert the loan data 111 to encrypted data and store it in an Encrypted Object Store (EOS) and record the object hash-id (e.g., fact hash in the scope object) on the blockchain. The hash-id can be a cryptographic hash of the content of the fact (e.g., file, document, etc.) in the on-chain immutable transaction. In some cases, a hash value (e.g., fact hash) of the fact (e.g., document content) can be used as a globally unique identifier (URI) or name (URN) for that content. In some cases, the cryptographic data stored in EOS can be a cryptographic fact-fact hash combination that includes both the actual fact data (e.g., PDF of security deed) 125 and a hash of the fact data (e.g., 489sdfkennwoeinv9) 123.

[0035]

[45] In some cases, the CEE may store loan data in EOS in a predefined data object structure. In some cases, the predefined object structure may be defined by a loan data model. These unique object structures may be used to efficiently store state data in the data object store.

[0036]

[46] In some embodiments, the object structure may include scope objects established in EOS that may correspond to sets of loan data facts, i.e., scope datasets. For example, loan data may be ordered and arranged in one or more scope datasets. A scope object in EOS may be a unit of storing loan data. As an example, origination scope may be associated with origination related facts such as all details, documents, and facts of the origination process (e.g., PDF copies of wet-signed documents, applicant's credit score, etc.). In another example, servicing scope may include servicing related facts such as all details, documents, and facts of the servicing process (e.g., loan payments and documents). Depending on the nature of the digital assets, different digital assets may have different types (e.g., loan, title, art, funds, share classes, etc.) and / or many scopes. For example, a mortgage asset may have an eNote scope that may comprise an electronic note record along with associated metadata.

[0037]

[47] In some embodiments, a set of loan-related facts may collectively constitute a scope object established on the blockchain. A blockchain scope object may be a non-fungible token (NFT) that includes a hash of a set of facts. For example, loan-related facts may be bucketed into one or more scope datasets that correspond to one or more blockchain scope objects. Each fact in a scope dataset may be hashed such that a set of fact hashes may be generated for a scope dataset included in the blockchain scope object. A blockchain scope object may record ownership, fact name, fact hash, and various other states of a fact or scope. A blockchain scope object may not include the original loan-related fact. Instead, a scope object may comprise a fact hash 123. The fact hash 123 may be a hash of a subset of the facts or hashes of the scope dataset. A blockchain scope object may also be referred to as a token, which may be utilized or interpreted interchangeably throughout this specification.

[0038]

[48] ​​In some cases, a scope may be created with all the facts at once (e.g., all composition information onboarded at once in the composition scope). Alternatively or additionally, facts may be added over time (e.g., new service information is added to an existing service scope).

[0039]

[49] In some embodiments, a single loan may have a single scope (e.g., all aspects of a loan transaction within one scope). Alternatively, a single loan may have multiple scopes. As an example, a dual-scope loan may include an origination scope and a servicing scope, and an eNote may be included in the origination scope.

[0040]

[50] In some embodiments, the CEE 121 can create one or more loan scopes 123 by hashing one or more scope datasets. In some cases, the LOS 110 can order and organize the loan data 111 into one or more scope datasets and send the scope datasets to the blockchain onboarding system 120. One or more loan scopes 123 can be proposed / generated by the CEE and recorded on the blockchain 140. The proposed loan scopes 123 can be processed by the blockchain layer 140, such as by performing a security authentication check on the proposed loan scope and finalizing and recording the authenticated scope on the blockchain. In some cases, additional information such as a block ID may be included in the scope upon authentication. Other information such as metadata or a timestamp may be added when the scope is recorded on the blockchain.

[0041]

[51] The proposed scope or recorded scope may include a fact hash instead of the original fact or scope dataset. Figure 2 shows an example of a scope 200 proposed by CEE and a corresponding scope 210 that is processed and recorded on the blockchain. As shown in this example, the loan scope may not include the original loan-related fact (e.g., PDF document). The loan scope may include a fact name 203, which may be a name or identifier associated with the fact. For example, if the fact is a PDF security instrument, the fact name for the fact may be "Signed Security Instrument."

[0042]

[52] A scope 200 or 210 may include a fact hash 204. A fact hash may be an algorithmically generated fingerprint of a piece of data (a fact). A fingerprint is a string that represents the data. A hash may be created using a hashing algorithm (e.g., SHA-256), and a hash may be uniquely associated with a piece of data. In some cases, a change to a single character in a data set may result in a different hash value. For example, if the fact is a PDF security certificate, the fact hash may be "adbkel838dfkjlbleisyuyf", which is the set of characters generated by a hashing algorithm to uniquely represent a PDF security certificate.

[0043]

[53] Scopes 200 constructed by CEE can be assigned a unique identifier, such as a scope ID 201. In some embodiments, the loan data model can assign each scope a universal unique identifier (UUID). This can advantageously enable collaborative contract execution and data sharing between various applications (e.g., servicing and portfolio manager applications as shown in FIG. 6).

[0044]

[54] A scope 200 may include information regarding ownership. The system herein may track ownership at the scope level by including the entity that owns the digital asset (e.g., loan data) or the scope data set. Ownership of a scope may include a data owner 202 and / or a value owner 211. In some cases, the platform is configured to split token ownership between the data owner and the value owner.

[0045]

[55] A data owner 202 may refer to an entity that owns and controls a scope dataset (e.g., a subset of facts encompassed by a scope). In some cases, the platform may be configured to allow only the data owner to affect the facts in the token, such as by adding one or more facts, modifying one or more facts, or deleting one or more facts. In some cases, the platform may be configured to allow data owners to freely share ownership so that there can be multiple data owners, each of whom may need to individually approve any subsequent changes to the scope dataset after the scope is recorded on the blockchain. In some cases, the platform may be configured to allow a data owner to grant read-only access to the token data (e.g., actual facts) for one or more other non-owner parties. In some cases, changes attempted by a non-owner party with only read-only access are not accepted or authorized for recording on the blockchain.

[0046]

[56] A value owner 211 may refer to an entity that has a right to the monetary value of a digital asset (e.g., a loan asset) that encompasses a scope(s) or a scope data set(s). A value owner may be permitted to transfer rights in the value to other parties.

[0047]

[57] In some cases, the originating party may be the default or initial data owner and value owner of the scope. The originating party may refer to the entity that creates and onboards the scope through the CEE. In some cases, the platform may allow both data ownership and value ownership to be freely transferred and shared. Variable ownership and authorization structures allow the parties to flexibly address all relationships involved in the digital asset lifecycle, from origination to securitization.

[0048]

[58] A value owner or data owner may control the scope. For example, in a single-scope loan, the data owner may have control pursuant to ESIGN / UETA because that entity is the only entity that can affect the facts within the scope, including the transferable records therein.

[0049]

[59] The proposed scope 200 may include a digital signature that identifies the data owner or proposing entity 202. In the proposed or recorded scope 210, the proposing entity may not be identified by name, thereby maintaining the privacy or PII of the proposing entity. The proposing entity may be identified by a unique public key (e.g., alkdfjlkj23434ienfildf) that serves as a digital signature that confirms the identity of the entity proposing the scope. The originator or originating party (e.g., data owner) may digitally sign the proposed scope using a public key assigned to the originating party. In some cases, each entity participating in the blockchain network may be assigned a unique public-private key pair, and may keep its private key secret. When preparing a scope, the originator may create a digital signature on the scope using the private key. The digital signature may be verified and authenticated by a public key connected to the private key and associated with the signing entity, i.e., the originator. By including the public key of the composer or data owner in the proposed scope (or modifications thereto), it can be advantageously achieved that it is the composer or data owner that is proposing the scope (or modifications).

[0050]

[60] In some cases, to satisfy the digital signature requirement, the data provider may be required to provide the following information: 1) the entity's certificate, 2) the canonicalized original data, and 3) a signature over the data. The entity's certificate allows other third parties to verify that the information was signed using a private key unique to the data provider. For example, the entity registers their certificate in a blockchain certificate registry. The certificate may include any necessary chain of trust to a certificate authority. As an example, the public key may be ASN1OID:prime256v1 and NISTCURVE:P-256. The canonicalized original data may be the original data package transmitted in a standard canonical format. The signature over the data may be the result of the canonical original data transmitted via a checksum (e.g., SHA256) and cryptographically signed with a private key.

[0051]

[61] An example process for generating a signature may include canonicalizing the message, running the canonicalized message through a SHA256 checksum, cryptographically signing the checksum with the certificate private key (e.g., the signature output may be in ASN.1 DER format), encoding the signed checksum (e.g., via Base64), and inserting the encoded signed checksum into the signing response header.

[0052]

[62] To authenticate this signature, the platform can verify the original SHA256 checksum using the certificate's public key, run a checksum on the data used, and compare the results. Unless the underlying data has been altered, both checksums should be identical. The act of using the certificate's public key to view the checksum can verify the source of the data, and the act of comparing the checksums can verify that the data sent from the source is used to generate financial assets.

[0053]

[63] Signature verification operations may be performed by the blockchain after onboarding. In some cases, invalid signatures may not block the service flow. In some cases, if an invalid signature is determined, the signature validator process may provide a warning and update the loan authorization message.

[0054]

[64] In some cases, the platform may be configured to allow permitted subsequent modifications or changes to a scope to be made only by an entity whose digital signature matches that of the scope's current data owner. In some cases, the platform may be configured to reject modifications or changes proposed by any entity whose digital signature does not match that of the scope's current data owner. As previously described, the blockchain layer may receive the proposed / generated scope 200 from the CEE and process the proposed scope, such as by performing a security authentication check on the scope. For example, the blockchain layer may check and verify the validity of the data owner's digital signature to be included in the proposed scope. For example, in the case of the initial creation of a scope, the composer's public key is valid by default because the composer is the default data owner. When modifications to an existing scope are being made, the blockchain layer may check and verify that the proposing entity's digital signature matches the public key of the current data owner of the scope being modified. If the proposing entity's digital signature does not match the current data owner's public key, the blockchain layer may reject the proposed scope change because the proposing entity is not the data owner and does not have the authority to modify the scope data.

[0055]

[65] After authentication, the proposed scope may be finalized, time-stamped, and recorded on the blockchain. In some cases, the final scope 210 may include, in addition to the data in the proposed scope 200, a value owner 211 identified by a public key assigned to the value owner, a block ID 212 identifying the specific location or block on the blockchain where the scope is recorded. The blockchain layer may send a copy of the recorded final scope to the CEE.

[0056]

[66] In some embodiments, the scope 200, 210 may also include a loan ID 205, which is an identifier uniquely associated with the loan asset. In some embodiments, the scope 200 may include a history 206 of contract execution on the scope. Alternatively, the history may be recorded on the blockchain as a metadata scope. In some cases, the history 206 may include contracts executed on the scope, the participants involved (e.g., identified by public keys), data inputs and outputs such as hashes of contract codes, etc.

[0057]

[67] Referring back to FIG. 1, in some embodiments, one or more scope datasets for each onboarding agreement may be created by a loan origination system (LOS) 110. The LOS may order and organize loan assets into one or more scope datasets. The originator may send the relevant scope dataset, commands, and digital signatures to the CEE 121 (e.g., via a LOS-CEE connection). A scope dataset may include a set of facts, such as the borrower's personal information and a PDF of the security document.

[0058]

[68] In some embodiments, the scope data may be sent to the CEE along with a scope command that identifies the proposed scope and action. For example, the command "onboard_new_loan" may be used to create a new loan-related scope. For example, upon execution of the contract, a scope object may be established in EOS 130 that contains a full record of the execution of the contract and the head state of the facts in the scope (data output by the contract), as well as the fact hashes (e.g., fact-fact hash combinations 123, 125). A blockchain scope object may be established substantially simultaneously on the blockchain 140. The blockchain scope object may be the same as that described in FIG. 2. For example, the originator may be designated as the value owner of the assets in the scope.

[0059]

[69] The CEE 121 may be configured to keep confidential data regarding one or more loan assets off the blockchain while maintaining the ability to use the blockchain to ensure data integrity. The CEE 121 may construct one or more loan scopes 123 based on one or more scope data sets, as described above. For example, the CEE may generate a unique identifier for the scope. The CEE may be configured to use a hashing algorithm to generate a fact hash for each fact in the scope data set and associate the fact hash with each fact. As described above, only the hash of the cryptographic fact may be recorded on the blockchain, and the cryptographic fact may not be recorded on the blockchain. The loan scope 123 may also include the originating party's public key. The CEE may then transmit the proposed loan scope 123 to the blockchain 140.

[0060]

[70] The blockchain 140 may process the loan scope by receiving the proposed loan scope 123, performing a security authentication check on the proposed scope, and finally recording the authenticated scope on the blockchain. In some cases, the platform may be configured to allow authorized subsequent modifications or changes to the scope to be made only by an entity whose digital signature matches that of the current data owner of the scope. In some cases, the platform may be configured to reject modifications or changes proposed by any entity whose digital signature does not match that of the current data owner of the scope. For example, a hash of the cryptographic facts may be recorded on the blockchain along with the originating party's public key, a timestamp, a block ID, or other data as described above. The blockchain layer may check and verify the validity of the data owner's digital signature to be included in the proposed scope. For example, in the case of initial creation of a scope, the originator's public key is valid by default since the originator is the default data owner. When modifications to an existing scope are being made, the blockchain layer may check and verify that the proposing entity's digital signature matches the public key of the current data owner of the scope being modified. If the proposing entity's digital signature does not match the current data owner's public key, the blockchain layer can reject the proposed scope change because the proposing entity is not the data owner and has no authority to modify the scope data.

[0061]

[71] After authentication, the blockchain 140 may finalize, timestamp, and record the scope on the blockchain. In some cases, the blockchain 140 may append to the final scope the value owner identified by a public key assigned to the value owner, a block ID identifying a specific location, or a block on the blockchain where the scope is recorded. The blockchain 140 may send a copy of the recorded final scope to the CEE 121. In some cases, value ownership of the scope may be recorded on the blockchain via a marker established on-chain. The marker module provides an ownership structure for managing tokenized value backed by assets or other tokenized units of value represented as units of coins (one or more). The marker may be tokenized, allowing for fractional ownership of the scope.

[0062]

[72] Facts and related data stored in EOS may be encrypted. The encryption may be performed by the CEE 121 or the blockchain onboarding system 120 (e.g., a blockchain software development kit (SDK)). For example, the CEE may encrypt a fact-fact hash combination using the originator's public key and send the encrypted fact-fact hash combination to the Encrypted Object Store (EOS) 130. The CEE may use any suitable encryption method. For example, in some cases, Elliptic Curve Integrated Encryption Scheme (ECIES) may be used to encrypt assets before they are stored in EOS. ECIES is an integrated encryption scheme that uses the following functions: key agreement (a function used to generate a shared secret by two parties), a key derivation function (a mechanism that generates a set of keys from keying material and some optional parameters), encryption such as a symmetric encryption algorithm, a message authentication code (data used to authenticate a message), and a hash (e.g., SHA-256).

[0063]

[73] In some embodiments, loan data may be originated by an origination party, and the platform may be configured to allow the origination party to create a unique wallet with a root key pair comprising a public key and a private key. Loan-related facts may be encrypted using the origination party's public key. The private key may be usable by the origination party, or by other parties authorized by the origination party, to decrypt the encrypted facts stored in EOS.

[0064]

[74] In some cases, if the token / fact hash is encrypted, the private key is available to decrypt the token and view / access the facts in the token. The public key may be included in the token or blockchain scope object, as well as any subsequent authorized modifications or changes to the token. In some cases, subsequent authorized transfers of rights in the token are tracked or traced by an integrated Digital Asset Registry Tool (DART).

[0065]

[75] EOS 130 may receive the encrypted loan facts 125 and fact hashes 123. In some cases, the encrypted loan facts 125 and fact hashes 123 may be arranged as a fact-fact hash combination. The fact-fact hash combination may include both the actual fact data (e.g., a PDF of the security deed) and a hash of the fact data (e.g., 489sdfkennwoeinv9). The fact-fact hash combination may be stored in EOS, which may be a secure repository or vault. In some cases, only the originator may access the encrypted fact-fact hash combination by decrypting the encrypted fact-fact hash combination using the originator's private key.

[0066]

[76] In one example, the borrower signs the eNote in the lender's eClosing system or LOS 110. The loan data 111, including the eNote file, such as a secure XML file with the borrower signature and associated metadata, along with a scope command ("onboard_new_loan") and the lender's digital signature, can be routed by the eClosing system or LOS 110 to the CEE 121 for creation of the eNote scope.

[0067]

[77] The CEE 121 may (i) create a hash of the eNote and send the encrypted fact-fact hash combination (e.g., the encrypted eNote file and the hash of the eNote file) to the EOS vault 130, and (ii) send the proposed eNote scope to the blockchain layer 140.

[0068]

[78] It should be noted that while Figure 1 illustrates the loan scope including the fact hash being sent to both EOS 130 and the blockchain 140, the loan scope data sent to EOS may include the fact hash of the fact (e.g., the hash of the eNote file), while the loan scope data sent and recorded on the blockchain may include other information in addition to the fact name-hash combination as described above, such as the data owner, value owner (e.g., the lender is the default data owner and value owner), block ID, etc. In some cases, the fact-fact hash combination stored on EOS and the loan scope recorded on the blockchain (e.g., the CEE scope database) may be associated by the fact name.

[0069]

[79] The blockchain layer 140 can authenticate, finalize, and record the final eNote scope on the blockchain. The trusted scope or final scope recorded on the blockchain can include a scope ID, data owner(s), value owner, and fact name-hash combination. The encrypted fact-fact hash combination (e.g., the encrypted eNote file and the hash of the eNote file) can be securely maintained in the lender's EOS vault 130 as a trusted eNote file. The term "trusted" can generally refer to a file, such as a scope object, fact, data object, etc. that has been authenticated and / or finalized.

[0070]

[80] Authorized access or modification of encrypted scopes, facts, or fact-fact hash combinations may be controlled by distributing key pairs to entities. In some embodiments, the platform may be configured to allow an origination party of loan data to create a unique wallet with a root key pair comprising a public key and a private key. Loan-related facts may be encrypted using the origination party's public key. The private key may be usable by the origination party, or by other parties authorized by the origination party, to decrypt the encrypted facts stored in EOS. In some cases, the platform may be configured to allow authorized subsequent modifications or changes to the scope to be made only by entities whose digital signature matches that of the scope's current data owner. In some cases, the platform may be configured to reject modifications or changes proposed by any entity whose digital signature does not match that of the scope's current data owner.

[0071]

[81] In some cases, contract execution may operate on a single loan scope consisting of a key-value pair where a value object may be defined, for example, using protocol buffers (e.g., protobufs). In some cases, if the token / fact hash is encrypted, the private key may be used to decrypt the token and view / access the facts within the token. The public key may be included in the token or blockchain scope object as well as subsequent authorized modifications or changes to the token.

[0072]

[82] For example, the encrypted fact-fact hash combination may be securely stored in the EOS 130. The data owner may access the facts (e.g., an XML eNote file) in the EOS via a user interface hosted by the CEE 121 or via another application. The fact-fact hash combination may be encrypted using a public-private key encryption system as described elsewhere herein. The composer's public key may be used to first encrypt the fact-fact hash combination, and the resulting encrypted fact-fact hash combination may be stored in the EOS. In some cases, only the composer's private key may be able to decrypt the encrypted data and allow the composer to view the actual facts (e.g., an XML eNote file) in the fact-fact hash combination.

[0073]

[83] In some cases, data owners may be able to grant read-only access to other parties. For example, a CEE associated with an EOS may copy shared data to the other party's EOS, and the other party may access the data and decrypt it with its private key. In that case, the other party has read-only access in that they can decrypt and view the data, but may not impact the data on the blockchain. As mentioned above, the blockchain can check and verify signatures, and if a party's digital signature on a proposed amendment to the relevant scope does not match the data owner's digital signature, the proposed amendment may not be authorized for recording on the blockchain.

[0074]

[84] In some cases, an authoritative fact set may remain EOS of the data owner, and only the data owner may have the authority to modify the scopes that contain the authoritative fact name-fact hash combinations associated with that fact set.

[0075]

[85] Recorded or trusted scopes may be modified. Modifications may include modifying facts associated with the scope (e.g., facts as a scope dataset), changing the data owner and / or value owner of the scope. In some cases, modifications to trusted scope-related information, such as fact name-fact hash combinations, data owner, or value owner, may be accomplished through the CEE or by interfacing directly with the blockchain layer. In order for a modification to be executed to completion, the proposing entity of the modification may be required to have the appropriate ownership. For example, only the data owner may have the authorization or authority to modify facts in the scope dataset or facts associated with the scope. Similar to the process of creating a scope described above, the data owner may send the relevant scope dataset (including the modified facts), the appropriate scope command, and the data owner's digital signature to the CEE. The CEE may then (i) encrypt and send the appropriate fact-fact hash combination to EOS, and (ii) construct and send the proposed scope to the blockchain layer. Prior to recording the proposed (modified) scope, the blockchain layer may ensure that the proposing entity's digital signature matches the digital signature of the current data owner of the proposed (modified) scope. If the proposing entity's digital signature does not match the current data owner's digital signature, the proposed scope may be rejected because the proposing entity is not the data owner and does not have the authority to modify the scope data.

[0076]

[86] In some cases, the recorded (modified) scope may include metadata about the creation and modification of the scope, for example, metadata may include previous versions of scope commands, contract execution inputs / outputs, and fact-fact hash combinations.

[0077]

[87] In some cases, the current data owner may have the authority to change or modify which entity / person should be designated as the data owner of the scope. In some cases, the current value owner may have the authority to change which individual / entity should be designated as the value owner of the scope. In some cases, if the transaction is a more complex transaction, the value owner may use a "marker" to effect the change. Markers are smart contracts that can be programmed for various uses, including specifying the value owner state of the scope. Markers are controlled by "administs" who can specify which entities are value owners of the marker's assets.

[0078]

[88] In some cases, updates to a scope may be performed in a session with details held in the session. A session may include a context for recording a set of records that links these records to a common process or execution related to a specification indicating permitted and requested values. For example, a session may include a specification detailing constraints on the parties that require signatures, inputs, and outputs that can be recorded. Each scope may include a list of allowable specifications that can be used. The blockchain onboarding system herein provides a service that facilitates referencing sensitive documents by their hash IDs and may encrypt and store those documents in a database where those documents are indexed by their hash IDs. The encryption key is unique to the owner or client of that document. When a contract requires an exchange of such documents, the service may re-encrypt the document with a key associated with the business partner that receives the document.

[0079]

[89] FIG. 3 illustrates a schematic of a Contract Execution Environment (CEE) 300, according to an embodiment of the present disclosure. In some embodiments, the platform and / or the blockchain onboarding system may be implemented in a virtual cloud environment. One or more components or modules may be provided as a container application. The CEE may assist in the complex process of hashing data, maintaining immutable objects, reconciling signatures between multiple parties, and various other services, as described elsewhere herein. For example, loan scope data sets(s) may be transmitted to the CEE 300 and stored and managed via the CEE. The CEE may be a data management system that affiliates (e.g., lenders) use to onboard, update, access, and share in-scope data and facts via a direct interface with the CEE or via a connection between the CEE and another application, such as the LOS or SDK 311.

[0080]

[90] In some embodiments, the CEE may include multiple components including, for example, a client-side contract execution engine 303, a locally hosted encrypted object store (EOS) 301, an index 305 to the encrypted object store, and a communication exchange for coordinating multi-party contract execution with other parties' own CEEs. In a cloud environment, the index 305 may include a distributed search and analysis engine. The CEE may include functionality that allows documents to be easily referenced by their hash IDs and to encrypt and store those documents in the encrypted object store (EOS). These encrypted documents are indexed by their hash IDs and / or by optionally selected document attribute values. The document attribute values ​​may advantageously allow a user to aggregate documents based on common attributes without revealing sensitive content.

[0081]

[91] The Encrypted Object Store (EOS) 301 may be an affiliate (e.g., lender) gateway to the blockchain layer. For example, EOS may be a lender vault of data, facts, and documents. The vault may be self-hosted by the lender or by a third-party data custodian. EOS may store actual replayable cryptographic facts (i.e., data and documents) such as XML eNote records in a secure vault.

[0082]

[92] In some embodiments, each CEE instance can communicate with blockchain nodes to send transactions (contract execution hash records) to the blockchain. Applications can use client-side CEEs and object stores to preserve privacy and confidentiality of information about personally identifiable information (PII), sensitive data, and non-fungible tokens. Hash commitments of information and its state can be captured in a scoped data model as described herein. The CEE provides tools to structure data to store on-chain, and acts as a side-chain information workflow manager with a scoped data model-based database acting as an on-chain state store.

[0083]

[93] The blockchain communication exchange component 330 can manage secure communications between business partners to exchange information necessary to fulfill contracts. This communication can flow via an asynchronous mailbox system and event streams where messages are authenticated and encrypted by the keys of the two parties.

[0084]

[94] Entities and organizations can use the contract execution environment to execute contracts that create single or multi-party agreements. Entity identity and data encryption can utilize public-private key pairs. Entities are known to each other and can share data with each other via their public keys. Contract and asset data can be transferred to all entities participating in the contract by public key identifiers. Entities can provide an implementation of an Encrypted Object Store (EOS) where encrypted data related to their public keys is stored. Contract execution can consume data from the entity EOS, and the results of contract execution can be returned to the execution environment of the submitting entity. In some cases, the hash sum of the contract execution results, i.e., a cryptographic hash of its contents, can be submitted (in the form of a scope data object) to the blockchain 320, where they are authenticated and committed to the blockchain. The blockchain can emit an event to notify the entity that the contract has been committed on the blockchain. The index 305, local to the entity, can be updated with the new contract information. This information is later used for data lookup and querying.

[0085]

[95] The blockchain layer 320 can include a blockchain where scope objects (e.g., proposed scopes including fact hashes) can be transacted and recorded authoritatively by the blockchain, which is an immutable, publicly available source of truth about the existence, history, and timing of any scopes and facts therein.

[0086]

[96] A validator 340 may be an authentication node on a blockchain network. Validators may propose and authenticate transactions on the blockchain network. In some cases, validators may stake hashes to become part of the active validators on the network (e.g., the top 50 validator nodes in the network by total stake are selected as the active validator set) and are the building blocks for hash holders who want to delegate and share their stake in rewards generated by the network's fee distribution framework.

[0087]

[97] Affiliates 310 can use SDK 311 to encrypt data before storing it in encrypted object store 301 before it is used in contract execution. Affiliates 310 can be participants in a transaction and can invoke a contract. An affiliate can be any participant in a transaction.

[0088]

[98] In some cases, the affiliate 310 may use the SDK 311 to encrypt messages or loan data and / or create a set of audience ciphertexts (ApubK[n] ciphertexts) for sharing data and enforcing agreements. An audience ciphertext set is a list of participants who are granted authorization to decrypt messages or loan data. Below is an example process for processing encrypted messages in a client agreement using the EOS encryption method to encrypt messages:

[0089]

[99] The audience ciphertext may be submitted to the contract in a temporary data space. The encrypted message and message metadata may be passed to authorized participants and stored in their encrypted object stores. The client contract execution can use its NpubK to determine if it is in the ApubK[n] ciphertext set. If the contract is not a valid ApubK[n] ciphertext audience participant, the contract throws an exception and the transaction is rejected. The client contract extracts the Tag, EpubK, and encrypted DEK from its ApubK[n] ciphertext into memory. An ECIES shared secret can be generated to decrypt the encrypted DEK.

[0090]

[0100] The same Key Agreement Function (KA) used to encrypt the DEK is followed. During decryption, the KA function generates a secret using the EpubK from the ciphertext and the NprivK of the contract. The Key Derivation Function (KDF) generates a Message Authentication Code Key (MAC Key) and an Encryption Key (ENC Key) using the secret and the EpubK encoded as byte array parameters. A new tag is calculated using the MAC key, the encrypted DEK, and the calling affiliate's UUID and compared to the tag from the ApubK[n] ciphertext. If the tags do not match, the contract throws an exception and the transaction is rejected. Using the ENC key, the encrypted DEK is decrypted to the clear DEK. The encrypted message from DIME (a data instance with metadata and encryption (DIME)) is decrypted using the DEK to obtain the clear message.

[0091]

[0101] The client contract processes clear messages by authenticating messages, modifying messages, reading DIME message metadata (eg, information about the message such as asset ID, key value set), and including or modifying messages based on the metadata.

[0092]

[0102] The client contract executes and processes the clear message, encrypting it with the DEK to obtain a new encrypted message. The DEK is destroyed from memory. The audience ciphertext is processed to obtain a set of audience ciphertexts that include only participants authorized to decrypt the message. The client-side contract wraps the filtered set of ciphertexts along with the message metadata in a message audience DIME. Finally, the client contract wraps the encrypted message and the message metadata in DIME.

[0093]

[0103] The CEE 300 may be used to onboard loan data, as previously described. In some cases, the CEE and its components may be used for onboarding and management of any general document. In an exemplary process of onboarding a loan or document, an affiliate 310 may submit a request to add an agreement (e.g., a document) to the vault 301. The submitter may be the owner and may include its public key with the document. A unique UUID is generated by the CEE engine 303 and assigned to the document. The unique ID may be used when requesting check-out, check-in, or verification of the document. The system 300 may create a digitally altered copy of the document. This copy may be returned to the owner and may be viewed and shared by the owner. The CEE engine 303 may generate keys that may be used to encrypt the trusted copy once the trusted copy is generated. These keys may be retained by the CEE 300 to ensure that only the system can decrypt the trusted copy based on the owner's request. A digitally altered trusted copy of the document is created and encrypted with a key. This copy may be returned to the owner, but only an encrypted version. If the owner does not have multiple copies of the key, they may not be able to decrypt the trusted copy without using the system 300. A record of the document is stored in the blockchain. For example, a recorded loan scope object may contain the following fields, as previously described: UUID, owner's public key, document state (check-in / check-out), hash representation of the original document, value owner, and block ID. The UUID, copy, and the encrypted trusted copy may be returned to the owner.

[0094]

[0104] In the checkout process, the owner of the document may submit a request to check out the document from the vault 301. The owner includes their public key in the request, along with the UUID and encrypted trusted copy that were returned to the owner when the document was added to the vault. The encrypted trusted copy may be hashed and compared to the hash from the blockchain to ensure that the document has not been altered. The state is also checked to ensure that the document is currently checked in. The key used to originally encrypt the document may be retrieved from the vault. Using the key, the trusted copy is decrypted. The state change of the checkout is stored in the blockchain. The decrypted trusted copy is returned to the owner.

[0095]

[0105] In the check-in process, the owner of the document submits a request to check the document back into the vault. The owner again includes their public key in the request, along with the UUID and the decrypted trusted copy. The trusted copy is encrypted using the original key, hashed, and compared to the hash from the blockchain to ensure the document has not been altered. The status is also checked to ensure the document is currently checked out. A new digitally altered copy of the document is created. This copy is returned to the owner, where it can be viewed and shared by the owner. Once the trusted copy is created, new keys are generated that are used to encrypt it. These keys are retained by the system to ensure that only the system can decrypt the trusted copy upon the owner's request. A digitally altered trusted copy of the document is created and encrypted with the new key. This encrypted copy is returned to the owner again. An updated record of the document, including the updated check-in status, is stored in the blockchain. The UUID, copy, and encrypted trusted copy are returned to the owner.

[0096]

[0106] In some embodiments, the software development kit (SDK) 311 provided by the platform herein may be a contract execution SDK consisting of a set of JVM-based libraries that help manage interactions with the blockchain 320. For example, the SDK 311 may process and place data into "scopes" as defined above. In some cases, the SDK includes a dock creation environment that allows for a full local stack to be executed. In some cases, the SDK is responsible for executing contracts between one or more participants. After successful execution of a contract, the result may be a set of blockchain protobuf messages. All records may be encrypted and stored in EOS. At this stage, the messages may be stored in the blockchain using the blockchain HTTP or gRPC interface. Optionally, the blockchain event stream may be read to asynchronously detect changes made to previously submitted scopes. The blockchain 320 or CEE 300 may persist the records in the system for easy retrieval at a later point after execution. For example, a protobuf indexer may achieve this by converting the protobufs into a key-value JSON structure that may be filtered. A custom protobuff descriptor is provided that supports hierarchical whitelisting / blacklisting of nested protobuff messages.

[0097]

[0107] In some cases, the SDK 311 may encrypt all data sent to the Encrypted Object Store (EOS) 301 using some encryption scheme (e.g., ECIES and DIME formats) as described elsewhere herein. If all audience members for the request are present on the owner's EOS, the data may be stored and not replicated to other affiliates' EOS. If there are audience members owned by remote EOSs, the data may be replicated to those other affiliate environments. The DIME standard defines an encryption scheme that ensures that the data cannot be decrypted back to a plaintext version if it falls into the wrong hands. The EOS itself may be the storage and replication mechanism for the data and may not have the keys necessary to decrypt the data.

[0098]

[0108] 4 illustrates a loan onboarding architecture 400 for onboarding loan assets to a blockchain. In some embodiments, the platform and / or the blockchain onboarding system may be implemented in a virtual cloud environment.

[0099]

[0109] In some cases, before initiating onboarding of a loan to the blockchain, the loan originator may create a digital loan packet and digital source documents (e.g., ownership, credit, income, etc.) for authentication purposes. In some cases, the loan data or packet may be digitally signed by the provider. This loan packet may be created via a loan origination system 410 integrated with the blockchain 420. For example, the originator requests the borrower to sign a loan agreement, passes on required disclosures (e.g., money lending laws), and waits for a rescission period (if applicable). If the loan data is off-chain, the originator may define any schema for those loan data. If the loan interacts with other blockchain-driven applications (e.g., portfolio managers or marketplaces), a scope data model as described above may be utilized. For example, the loan data at origination is stored in the encrypted object store 431 as a single scope, and the service data is recorded in a separate scope(s).

[0100]

[0110] Digital assets can be onboarded to the blockchain by execution of a client-side contract in which the originator writes to consume the origination data, verify its integrity, and output the data as facts recorded in an encrypted object store that is private to the originator and hosted by the originator. The blockchain contract execution environment (CEE) 430 records hashed representations of documents, data, transactions, and client-side contracts on the blockchain. Data changes or updates can be made by further contract execution on the scope by authenticating and checking the input hash of the data from the object store against the blockchain to ensure that no external data changes have been made. Various functions may be provided through the CEE API (Application Programming Interface) 433. This beneficially allows for the truth of data to be verified without requiring trust to the data store of the individual originator. For example, a message payload sent to the blockchain API has the sender, audience list, and base identifier in the following structure (e.g., in plaintext form as part of the metadata): The payload may be a ciphertext block containing member information and associated results from the execution of the smart contract.

[0101]

[0111] Platform 400 can provide multiple loan onboarding services. For example, a client-side blockchain contract can be created to require participation by multiple parties, such as an originator and an auditor. For example, an "onboard to service provider" contract may include an originator and a service provider, both of which verify that the data is complete enough to be transferred to the service provider. All parties involved in the execution of the contract can read the data. Any party can reject the contract. If all parties agree, the resulting data facts are copied to each participant's encrypted data store as part of the head of scope state.

[0102]

[0112] Every onboarding contract can create a new scope in EOS431, using the loan UUID as the scope UUID. The onboarding contract can also establish the initial values ​​of the facts in the scope. In some cases, not all facts are established during this onboarding process. For example, the validation_results fact may only be populated after the first execution of the loan validation contract. Additionally, not all facts are established for all loan types. For example, a scope for HELOC loans may include the lien_property fact, but not personal loans.

[0103]

[0113] A validation command (e.g., service loan validation service) can validate the loan as part of the onboarding process. In some cases, the loan validation process can examine the loan's data in EOS 431 and perform several checks to ensure that the system's underwriting guidelines have been met. The validation results may be stored in the validation_results fact and may be available to the originator or portfolio manager for display to interested investors. Performing validation checks in the client-side contract beneficially allows originators to avoid traditional manual validation audits.

[0104]

[0114] The "Servicer Allocation" service ensures that the requirements for fulfilling the loan are met. If the loan data is formatted incorrectly in any way, the servicing application will reject the contract and the responsibility for correcting the problem will fall on the loan origination system 410.

[0105]

[0115] The encrypted object store 431 can operate in several different configurations based on the needs of the CEE. For example, in a "no external multi-party configuration," if the CEE is strictly processing single-party agreements, or multi-party agreements where all parties are within the CEE execution environment, a single privately addressable object store node may be used. Replication features may be disabled. In an "external multi-party configuration," if the CEE execution environment needs to execute multi-party agreements with some parties that are external to EOS 431, the EOS and replication features of the CEE execution environment are enabled. In some cases, EOS requires postgress to persist data. CPU and memory requirements may depend heavily on the amount of data the EOS environment supports.

[0106]

[0116] The blockchain 420 may be accessed through blockchain nodes, which provide the CEE 433 with a means to read events and send transactions to the distributed blockchain network.

[0107]

[0117] 5 illustrates a schematic of the platform's application architecture 500. The application layer 501 may provide a user interface for interacting with one or more blockchain-based applications. For example, marketplace and exchange applications may be provided where users buy, sell, and exchange things of value. The things of value may include, for example, asset-backed securities, cryptocurrencies, or tokenized assets.

[0108]

[0118] The interface layer 501 may include a wallet application. An entity (e.g., an organization, a system, or a user) may need to have an account to conduct business on the blockchain. An account is represented by the public key portion of a public-private key pair. An account may include a uniquely identified address, which may be a string value derived from the entity's public key (e.g., in Bech32 format), thus providing a standard blockchain pseudonym. In an example of a hash transfer transaction where user A is the hash holder and user B is the recipient, user A holds 100 hashes at address tp1kaczxflvhq4700r0ntdnqlxpu80xdp869seh9e (the address is derived from the public key portion of the key pair held by user A). User B has also generated a key pair and address from the public key portion of the key pair tp18839rhfk0ql7mdqgn27eeaesmfr9ckpajssuc4. Before User A sends a transfer transaction request to the blockchain, User A may need to sign the transfer transaction. User A signs the transaction using the private key portion of his or her key pair and sends the transaction to the blockchain. The blockchain authenticates the transfer transaction signature against User A's public key, verifying that the user has an account on the blockchain and that the address holds enough hashes to pay the transaction fee and transfer to User B.

[0109]

[0119] A wallet is where users (e.g., User A and User B) store their key pairs. Wallets are used to manage key pairs, addresses, and token values ​​that the addresses hold. In some cases, when using blockchain wallets, HD wallets may be used. HD wallets allow an entity to create a root mnemonic seed and then derive child keys from the root that can be used to hold values ​​on the blockchain. For example, User A's address tp1kaczxflvhq4700r0ntdnqlxpu80xdp869seh9e is one of many keys in User A's HD wallet. Entities can import, export, or regenerate their wallets (and any subsequent derived addresses) using the root mnemonic seed. The root mnemonic seed is a secret value that the entity controls and never reveals to the blockchain system.

[0110]

[0120] One or more applications may be executable on multiple devices. The multiple devices may include a personal computer (e.g., a portable PC), a slate or tablet PC (e.g., an Apple® iPad®, a Samsung® Galaxy Tab), a phone, a smart phone (e.g., an Apple® iPhone®, an Android-enabled device, a Blackberry®), or a personal digital assistant. The application may include a graphical user interface (GUI) for a user to access, manage, and control various digital assets, and to perform transactions and other functions consistent with those described herein. The GUI may be rendered on one or more devices.

[0111]

[0121] The Contract Execution Environment layer 503 may be configured to onboard and manage private and confidential information. The Contract Execution Environment (CEE) provides the ability for entities to exchange private data, but still leverage the benefits of ownership, immutability, and value provided by the blockchain. The CEE layer is a bridge between the blockchain and financial services business logic. The CEE layer can connect directly to blockchain nodes to invoke transactions, query transactions, and listen for events.

[0112]

[0122] The blockchain layer 500 is a blockchain network, providing a persistent, decentralized, immutable, and replicated deterministic state machine. The blockchain layer 500 can include blockchain networking (blockchain SDK 505) and consensus layer 507, including transaction ordering and consensus. The blockchain layer 500 can include value and ownership marker leveraging middleware business applications, including coins, cryptocurrencies, and tokenization, to enable exchange, trade, and settlement of value markers and bridges to fiat currencies. The blockchain layer 500 provides two-way exchange implementation using smart contracts, and provides blockchain primitives such as account authorization, management, staking, voting, gas and fee processing, telemetry, and node configuration.

[0113]

[0123] The blockchain 510 acts as a ledger, registry, and exchange for digital assets. The blockchain contains a record of all transactions including loan onboarding and loan asset transfers. The blockchain used by the platform may be a proof-of-stake production blockchain. The blockchain combines the distributed, trustless, immutable properties of the blockchain with the functionality of a ledger, registry, and exchange. In some embodiments, the blockchain may use a more flexible proof-of-stake consensus method 507 based on the SDK 505.

[0114]

[0124] In some cases, the blockchain layer 510 may use many different proof-of-stake blockchains connected together to support diverse and scalable workloads. Each blockchain created with the SDK 505 may be fully sovereign and autonomous while maintaining the ability to selectively connect with other chains using IBC (Inter-Blockchain Communication). This additional flexibility means that in cases where a given application requires building an entire public global network using only a single computer / single node, it is possible to build its own dedicated blockchain network according to the requirements of its own application supporting the concept of using many different blockchain instances collectively.

[0115]

[0125] The blockchain layer 510 can support multiple types of integration, both application and smart contract based, offering opportunities for high performance or high flexibility depending on the requirements. In some cases, the SDK 505 can be developed using Protobuf with a state machine model that provides simple message passing and extension points.

[0116]

[0126] This platform 500 may enable a blockchain to maintain its network dominance, facilitate interaction with other blockchains, and improve scalability. A flexible peer-to-peer networking model may significantly streamline the operational aspects of a blockchain network while creating a more fault-tolerant network through the use of redundant network paths in the peer-to-peer architecture. The platform may include a WASM (Web Assembler) environment that allows smart contracts to be created for deployment flexibility at the expense of performance and ease of development, thereby reducing the cost of maintaining and deploying the blockchain and making it more accessible for third parties to integrate while maintaining independence and control.

[0117]

[0127] Digital Asset Registration Tool (DART)

[0128] Transferring loans has been difficult. Traditional loan document management systems can be inefficient. For example, loan data, documents or information may be maintained across disconnected systems (e.g., LOS, servicing systems, investor portfolio management systems, eVaults, etc.). Additionally, manual tracking, such as using spreadsheets for portfolio details, purchasing advice, wire instructions / dates, may add further friction. Traditional systems may require multiple updates to the Mortgage Electronic Registration System (MERS) database for each transfer, which may duplicate quality control costs.

[0118]

[0129] The present disclosure may address the above deficiencies by providing an integrated Digital Asset Registry Tool (DART), which may be an integrated registry configured to track in substantially real-time the control, transfer, assignment, and / or ownership of controllable electronic records, such as promissory notes (eNotes) associated with loan agreements.

[0119]

[0130] In some cases, DART may eliminate the need for paper assignments, sales slips or other security agreements, or other documentation of physical document transfers. In some cases, DART may eliminate the need for manual registration of eNotes and loans in intermediary systems, including the Mortgage Electronic Registration System (MERS). In some cases, DART is configured to enable intra-party blockchain-based transfer of fully digital tokenized mortgage assets from transferor to transferee, with authentication that full super-priority control has been granted to the transferee.

[0120]

[0131] In some cases, EOS is configured to share encrypted facts and metadata with the loan market module. Loan transactions conducted through the loan market module are recorded in substantially real-time using DART.

[0121]

[0132] 6 illustrates an example of a platform 600 that includes a Digital Asset Registry Tool (DART) 610. The DART 610 may be used for an electronic promissory note (eNote) registry. The DART may be configured to track the management, transfer, assignment, and / or ownership of eNotes associated with loan agreements in substantially real time.

[0122]

[0133] In some cases, DART may include eNote registration, tracking, and lien recording services. DART can listen to transactions, thereby eliminating the need to document market transfers in a separate system.

[0123]

[0134] In some cases, the blockchain onboarding system 620, the blockchain 630, the vault 640 (integrated or separate eVault), and the integrated registry application 610 may constitute an ESIGN / UETA Safe Harbor compliant control system.

[0124]

[0135] The platform can include an attestation oracle 660 where attestation results can be digitally signed by the source and added to the blockchain. For example, electronic Reliance Letters and diligence results can be posted in the near future, stored in EOS, and accessible to the loan market. In some cases, diligence data such as due diligence 15E attestations can be sent from the originator to the attestation oracle along with the loan asset (e.g., eNote) to protect the holder in due course in addition to the initial insured. Attestations can be attached once to the asset as close to origination as possible and communicated along with the asset via the investor on the blockchain. In some cases, the final loan attestation, including electronic RL, review results and reports, and indemnification policies, can become attributes of the loan asset on the blockchain. Diligence results and origination data can be encrypted and stored in the encrypted object store 640.

[0125]

[0136] The platform manages and buys and sells its loans in a Portfolio Manager and Marketplace 650. To allow these applications to read the loan data in the encrypted object store, the LOS can share the data by authorizing the public key of the other application. Once the blockchain scope object is authorized to another public key, the CEE 620 can replicate the data to the encrypted object store of the other application. Subsequent modifications or changes to the scope due to contract execution may also be replicated to the encrypted object store and a key may be required to read the scope as described above.

[0126]

[0137] In some cases, the portfolio manager 650 may enable participants (e.g., Investor A, Investor B) to purchase loans via the loan marketplace (portfolio manager). For example, a seller (e.g., originator) may pick loans, pool and pred, sell, and select a counterparty. The counterparty may be notified via the portfolio manager, accept the transaction, and purchase the loan. The loan or eNote may be transferred to the investor upon purchase. The certificate may be attached once to the asset as close to origination as possible and communicated with the asset via the investor on the blockchain. FIG. 7 shows an example of a user interface (UI) provided by the portfolio manager. The UI may provide intuitive tracking or asset management, such as viewing real-time service data (service integration) and current loan data / documents from the blockchain record, providing easy access to counterparties, and providing near real-time asset / fund transfers.

[0127]

[0138] FIG. 8A illustrates a schematic of a platform 800 with blockchain-based loan authorization and integrated eNote registry. The result can be fully digital tokenized assets with the same velocity as the secured capital. DART or registry can beneficially provide an ESIGN / UETA safe harbor compliant system of control, eliminating the need to authenticate security agreements / sales invoices or file UCC funding statements. For example, once the transfer is complete, the new owner can fully perfect “first priority” ownership. The platform can enable members of the USDF consortium to mine / burn 100% fiat-backed digital markers for real-time settlement of market transactions. The platform can also beneficially enable the securities to be traded using real-time markets, providing data to inform pricing in primary and secondary markets.

[0128]

[0139] FIG. 8B illustrates a schematic of a data sharing mechanism in the platform 800. As previously described, the platform's loan scope model may be utilized by various parties. For example, the loan scope model (e.g., loan scope on blockchain, encrypted loan data, etc.) may be used by a service provision application and a portfolio manager to enable joint contract execution and data sharing between these applications. For example, a loan scope constructed by an originator CEE 810 may be assigned a unique identifier, e.g., a scope ID, which may be a universal unique identifier (UUID), and stored in an originator EOS 811. Each participant may have its own key pair and an instance of a contract execution environment and EOS. For example, a portfolio manager may have a key pair uniquely associated with it and own an instance of a PM CEE 820 that includes a PM EOS 821, and a service entity may have a key pair uniquely associated with it and own an instance of a service provider CEE 830 that includes a service provider EOS 831.

[0129]

[0140] Data sharing can be by key-based data sharing and replication in the CEE and / or collaborative agreement execution. In some cases, any of the data sharing methods may include replicating to the other party's EOS (e.g., server EOS 831) and adding the other party as an audience member. An audience can refer to other parties who can decrypt the data but are not the data owner. The data owner of the scope can authorize other parties to have read-only access to the data. Audience members can use their private key to decrypt the data. The encrypted data, along with the audience and key information, can be packaged as a single data structure that is a Data with Metadata and Encryption (DIME) instance.

[0130]

[0141] Data sharing mechanisms and audience information control may be supported by end-to-end encryption within the blockchain protocol as previously described. Submitted data may exist in an unencrypted / viewable state in the submission, processing / authentication, and search context assigned to a specified audience.

[0131]

[0142] A submission context can be assigned to the creator who submits information to the system. Information can be transferred to another owner, but it may not be possible to submit data to the system and not be marked as that owner. Changing ownership of an asset can be the same as above, with the existing owner adding authorization to the new owner, followed by the new owner retrieving the data and resubmitting it to the system to complete the ownership change, etc.

[0132]

[0143] Computer Systems

[0144] In another aspect, the present disclosure provides a computer system programmed or configured to perform the method of the present disclosure. Referring to FIG. 9, a computer system 901 may be programmed or otherwise configured to perform a method for providing a blockchain-based lending or loan processing platform. The computer system 901 may be configured to implement, for example, a blockchain onboarding system, a smart contract execution environment (CEE), or other components of the platform. The computer system 901 may be a user's electronic device or a computer system located remotely relative to the electronic device. The computer system 901 may be a cloud server.

[0133]

[0145] The computer system 901 may include a central processing unit (CPU, also referred to herein as "processor" and "computer processor") 905, which may be a single-core or multi-core processor, or multiple processors for parallel processing. The computer system 901 also includes memory or storage locations 910 (e.g., random access memory, read-only memory, flash memory), an electronic storage unit 915 (e.g., hard disk), a communication interface 920 (e.g., network adapter) for communicating with one or more other systems, and peripherals 925, such as cache, other memory, data storage, and / or electronic display adapters. The memory 910, the storage unit 915, the interface 920, and the peripherals 925 are in communication with the CPU 905 via a communication bus (solid lines), such as a motherboard. The storage unit 915 may be a data storage unit (or data repository) for storing data. The computer system 901 may be operatively coupled to a computer network ("network") 930 with the aid of the communication interface 920. The network 930 can be the Internet, an Internet and / or an extranet, or an intranet and / or an extranet in communication with the Internet. The network 930 is possibly a remote communication and / or data network. The network 930 can include one or more computer servers, which may enable distributed computing, such as cloud computing. The network 930 can possibly implement a peer-to-peer network with the aid of the computer system 901, which allows devices coupled to the computer system 901 to operate as clients or servers.

[0134]

[0146] The CPU 905 can execute a series of machine-readable instructions, which may be embodied in a program or software. The instructions may be stored in a memory location, such as the memory 910. The instructions may be directed to the CPU 905, which may then program or otherwise configure the CPU 905 to perform the methods of the present disclosure. Examples of operations performed by the CPU 905 may include fetch, decode, execute, and writeback.

[0135]

[0147] The CPU 905 may be part of a circuit, such as an integrated circuit. One or more other components of the system 901 may be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[0136]

[0148] The storage unit 915 can store files such as drivers, libraries, and saved programs. The storage unit 915 can store user data, such as user preferences and user programs. The computer system 901 can optionally include one or more further data storage units located outside the computer system 901 (on a remote server in communication with the computer system 901 via an intranet or the Internet).

[0137]

[0149] Computer system 901 can communicate with one or more remote computer systems via network 930. For example, computer system 901 can communicate with a remote computer system of a user (e.g., a merchant or end user). Examples of remote computer systems include a personal computer (e.g., a portable PC), a slate or tablet PC (e.g., Apple® iPad®, Samsung® Galaxy Tab), a phone, a smartphone (e.g., Apple® iPhone®, Android-enabled devices, Blackberry®), or a personal digital assistant. A user can access computer system 901 via network 930.

[0138]

[0150] The methods described herein may be implemented by machine (e.g., computer processor) executable code stored in an electronic storage location of the computer system 901, such as in the memory 910 or the electronic storage unit 915. The machine executable or machine readable code may be provided in the form of software. In use, the code may be executed by the processor 905. In some cases, the code may be retrieved from the storage unit 915 and stored in the memory 910 for immediate access by the processor 905. In some circumstances, the electronic storage unit 915 may be eliminated and the machine executable instructions are stored in the memory 910.

[0139]

[0151] The code may be pre-compiled and configured for use with a machine having a processor adapted to execute the code, or it may be compiled at run-time. The code may be provided in a programming language that may be selected to enable the code to be executed in a pre-compiled or compiled manner.

[0140]

[0152] Aspects of the systems and methods provided herein, such as computer system 901, may be embodied in programming. Various aspects of the technology may be considered as a "product" or "article of manufacture" generally in the form of machine (or processor) executable code and / or associated data held or embodied in some type of machine-readable medium. The machine executable code may be stored in an electronic storage unit, such as a memory (e.g., read-only memory, random access memory, flash memory) or a hard disk. A "storage" type medium may include any or all of the tangible memory of a computer, a processor, etc., or its associated modules, such as various semiconductor memories, tape drives, disk drives, etc., that may provide persistent storage at any time for software programming. All or parts of the software may sometimes be communicated over the Internet or various other remote communication networks. Such communication may enable, for example, loading of the software from one computer or processor to another, for example, from a management server or host computer to a computer platform of an application server. Thus, other types of media that may bear software elements include optical, electrical, and electromagnetic waves, such as those used across physical interfaces between local devices, via wired and optical land line networks, and across various air links. The physical elements that convey such waves, such as wired or wireless links, optical links, etc., may also be considered media bearing software. As used herein, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution, unless limited to persistent, tangible "storage" media.

[0141]

[0153] Thus, a machine-readable medium such as a computer-executable code may take many forms, including but not limited to a tangible storage medium, a carrier wave medium, or a physical transmission medium. For example, non-volatile storage media including optical or magnetic disks, or any storage device in any computer(s), etc. may be used to implement databases, etc., as shown in the figures. Volatile storage media include dynamic memory, such as the main memory of such a computer platform. Tangible transmission media include coaxial cables, copper wire and fiber optics, including the wiring that comprises a bus within a computer system. Carrier wave transmission media may take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Thus, common forms of computer readable media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape, any other magnetic medium, a CD-ROM, a DVD or DVD-ROM, any other optical medium, punch cards paper tape, any other physical storage medium with a pattern of holes, a RAM, a ROM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transmitting data or instructions, a cable or link transmitting such a transmission wave, or any other medium from which a computer can read programming code and / or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0142]

[0154] The computer system 901 may include or communicate with an electronic display 935, for example, that includes a user interface (UI) 940 to provide a portal through which a user may interact with the platform. The portal may be provided through an application programming interface (API). A user or entity may also interact with various elements within the portal through the UI. Examples of UIs include, but are not limited to, graphical user interfaces (GUIs) and web-based user interfaces.

[0143]

[0155] The methods and systems of the present disclosure may be implemented by one or more algorithms. The algorithms may be implemented via software upon execution by the central processing unit 905. For example, the algorithm may be configured to generate a visual code that indicates or represents a transaction amount of a settlement between a first party and a second party.

[0144]

[0156] While preferred embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will occur to those skilled in the art at this point without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be used in practicing the invention. It is intended that the following claims define the scope of the invention, and that methods and structures within the scope of these claims and their equivalents be covered thereby.

Claims

1. The system includes a blockchain onboarding system equipped with a Smart Contract Execution Environment (CEE), and the blockchain onboarding system is (1) Automatically processes loan data from the Loan Arrangement System (LOS) for the virtual execution of one or more loan agreements within the CEE, and the loan data includes multiple loan-related facts, (2) Encrypt the loan-related facts to generate a plurality of encrypted facts associated with one or more loan assets, (3) Multiple hashes are generated with respect to the encrypted facts, the hashes are recorded on the blockchain, and the combination of each encrypted fact and the hash corresponding to each encrypted fact is deposited in an encrypted object store (EOS) separate from the blockchain. A blockchain-based lending or loan processing platform configured as such.

2. The platform according to claim 1, wherein each fact corresponds to a single or individual piece of data whose hash is recorded on the blockchain.

3. The platform according to claim 1, wherein the CEE is configured to keep confidential data relating to the one or more loan assets separate from the blockchain, while maintaining the ability to use the blockchain to ensure data integrity, the hash of the cryptographic fact is recorded on the blockchain, the cryptographic fact is not recorded on the blockchain, and the EOS is local to or part of the CEE.

4. The platform according to claim 1, wherein the aforementioned loan-related facts include credit scores, borrower information or profiles, electronic copies of signed security documents, copies of electronic promissory notes (eNote), third-party review (TPR) diligence results, and / or loan terms.

5. The platform according to claim 1, wherein the loan data is constructed by the constructing party, the platform is configured to enable the constructing party to create a unique wallet having a root key pair comprising a public key and a private key, the loan-related facts are encrypted using the constructing party's public key, and the private key is available to the constructing party or to another party authorized by the constructing party to decrypt the encrypted facts stored in the EOS.

6. The platform according to claim 5, wherein the hash of the encrypted fact is recorded on the blockchain together with the public key and timestamp of the parties involved in the creation.

7. The blockchain is the platform according to claim 1, which includes a record of all transactions, including loan onboarding and loan asset transfers.

8. The platform according to claim 1, wherein a group of loan-related facts collectively constitute a token recorded on the blockchain.

9. The platform according to claim 8, wherein the tokens to which unique identifiers are assigned include non-fungible tokens (NFTs), and a group of such tokens collectively constitute a loan asset.

10. The platform according to claim 9, wherein the platform is configured to specify ownership at the token level.

11. The platform according to claim 10, wherein the platform is configured to divide ownership of the tokens between a data owner and a value owner, the platform recognizes the value owner as an entity entitled to receive the monetary value of the loan asset comprising (one or more) the tokens, and enables the value owner to transfer the right to the value to the other party, and the platform recognizes the data owner as an entity controlling the facts encompassed in the tokens.

12. The platform according to claim 11, wherein the platform is configured to allow only the data owner to influence the facts in the token by adding, changing, or deleting one or more facts, and / or the platform is configured to allow the data owner to grant read-only access to the token for one or more other non-owner parties.

13. The platform according to claim 12, wherein the platform is configured to allow multiple data owners to freely share ownership, and each of the multiple data owners is required to individually approve any subsequent changes to the token after the token has been onboarded to the blockchain.

14. The platform according to claim 12, configured to allow one or more other non-owner parties to decrypt the token and view / access the facts within the token, while preventing the non-owner party from making any changes to the token on the blockchain, and any attempt to make changes by the non-owner party having only read-only access is neither accepted nor authenticated for recording on the blockchain.

15. The platform according to claim 11, wherein the platform recognizes the composing party as an entity that creates and onboards the token via the CEE, the composing party is by default initially the data owner and value owner of the token, and the platform is configured to assign the composing party a unique public key and private key pair, the public key being available to the composing party to create a digital signature on the token.

16. The platform enables the verification and authentication of the digital signature by the private key which is connected to the public key and associated with the party creating the signature, and / or The platform according to claim 15, wherein the token is encrypted and the private key is available for decrypting and viewing / accessing the facts contained in the token.

17. The platform according to claim 15, wherein the public key is included in the token and any subsequent authorized modification or alteration of the token, and any authorized transfer of ownership of the token is tracked or traced by the Integrated Digital Asset Registration Tool (DART).

18. The platform according to claim 17, wherein the platform is configured to allow any subsequent authorized modifications or alterations to the token only by entities whose digital signature matches that of the current data owner of the token, and the platform is configured to reject any modifications or alterations proposed by any entity whose digital signature does not match that of the current data owner of the token.

19. The platform according to claim 1, further comprising a Digital Asset Registration Tool (DART) connected to the platform, wherein the DART is an integrated registry configured to track the control, transfer, assignment and / or ownership of controllable electronic records such as promissory notes (eNotes) associated with the loan agreement in substantially real time, the DART is designed to eliminate the need for paper assignments, other documentation of the transfer of sales vouchers or security agreements, or physical document delivery, and / or the DART is designed to eliminate the need for manual registration of eNotes and loans using any additional intermediary system.

20. The platform according to claim 19, wherein the DART is configured to enable an intra-party blockchain-based transfer of a fully digitally tokenized mortgage asset from the assignor to the assignee, and to authenticate that full, ultra-priority control has been granted to the assignee.

21. The platform according to claim 19, wherein the EOS is configured to share the encrypted facts and metadata with the loan market module, and loan transactions conducted through the loan market module are recorded substantially in real time using the DART.

Images